From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 64450C48BE5 for ; Tue, 22 Jun 2021 04:03:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4EA16611CE for ; Tue, 22 Jun 2021 04:03:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229739AbhFVEGE (ORCPT ); Tue, 22 Jun 2021 00:06:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44038 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229675AbhFVEGA (ORCPT ); Tue, 22 Jun 2021 00:06:00 -0400 Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1EA14C061756 for ; Mon, 21 Jun 2021 21:03:44 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id g6so15402786pfq.1 for ; Mon, 21 Jun 2021 21:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=igel-co-jp.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=fDlc9TgaOD99jTxAWrDaocLPhWL0A0Lj9SHYh7Mvk9o=; b=o0yFPlq7pxYmbagKCCg+kimNiPNQn/TmmpLhgBCc4+gKAdI7guTaFh2HLcqRgOS+Y2 N31G1dYSTwJFSZONsIs6aTmlvFyMWs7sUSs6w5r2lIeIl7U7eAi64P51JFyLNIVopMIe clgwoPZrwBAPqe177UXF7XDOkjJEPcpxs/DLMSjcqe+emsSTFic8ZBcNj2+ZCBmsRZSL pIaW4QYUGKMmZVLpKimMt2ZiXi24RBko8/fxW56iwZZhUKa4Z5Yz0RJB7pLrd6CGGysv 4XFfuEt1cuayw5S6wYtqWNXLKq10QMJK/uZ2WyJulx4ckrvePNwDHZkP4e9ANEJGr9uu 3nLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fDlc9TgaOD99jTxAWrDaocLPhWL0A0Lj9SHYh7Mvk9o=; b=pc1XiA6g0dMrSbN6LPKQo0aisNno1wNGFfoQJR7l7eUDUP6AR5aqeqHbt2HxqNuOq7 5jbXG6Fm9GPaojak1WjqtSTI3SQEWp8iPz/Nfyqu2JLsKdCmPYVLbF1SXSs7d4+1tNRn 0LmQ2KZDG9+8Nb56d9DJFlxycK/jWRZJ3G2IZzM6zK54eAg9QbMljF4vu7tdcSo5yiV3 v0x3YwA1iS/znJb1TiTPgBZ5i9SansJBefrK51FU1zdIp9cRo0jtVKshLokhtfbl6+u9 YOEzfP7LaziWfc/STJZBF+7tK2bUrtUFEDlQ1fdw1ZN+TDZ2PZl+xvJZp0qY3P4Lox0r LkCA== X-Gm-Message-State: AOAM531z8+TAKiCTfIYiBMueUlVTP1rvUitxkxm8xZhIOMriuLAq7Y42 LgO2nHyI0AGC2eYmBetUQZmWJw== X-Google-Smtp-Source: ABdhPJyDcxIlsiXjWflxT5mU0F4cuX1u87XCPF+dYg++suxUBJdfPBs1yWMuqJH0lAgAd7Abm8KHjA== X-Received: by 2002:a62:b618:0:b029:2f9:f3b1:8afd with SMTP id j24-20020a62b6180000b02902f9f3b18afdmr1572467pff.81.1624334623646; Mon, 21 Jun 2021 21:03:43 -0700 (PDT) Received: from ?IPv6:240b:10:c9a0:ca00:5192:32ad:e5be:23cd? ([240b:10:c9a0:ca00:5192:32ad:e5be:23cd]) by smtp.gmail.com with ESMTPSA id 20sm16946099pfi.170.2021.06.21.21.03.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Jun 2021 21:03:43 -0700 (PDT) Subject: Re: [PATH 0/4] [RFC] Support virtual DRM To: "Enrico Weigelt, metux IT consult" Cc: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , Laurent Pinchart , Kieran Bingham , dri-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-doc@vger.kernel.org, Damian Hobson-Garcia , Takanari Hayama References: <20210621062742.26073-1-etom@igel.co.jp> <7cde82a9-c60c-e527-eeac-eaad0c5842a1@metux.net> From: Esaki Tomohito Message-ID: <1cfab5f9-f275-aa53-00de-5da3fcea71c5@igel.co.jp> Date: Tue, 22 Jun 2021 13:03:39 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <7cde82a9-c60c-e527-eeac-eaad0c5842a1@metux.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Enrico Weigelt Thank you for reply. On 2021/06/22 1:05, Enrico Weigelt, metux IT consult wrote: > On 21.06.21 08:27, Tomohito Esaki wrote: > > Hi, > >> Virtual DRM splits the overlay planes of a display controller into multiple >> virtual devices to allow each plane to be accessed by each process. >> >> This makes it possible to overlay images output from multiple processes on a >> display. For example, one process displays the camera image without compositor >> while another process overlays the UI. > > Are you attempting to create an simple in-kernel compositor ? I think the basic idea is the same as DRMlease. We want to separate the resources from the master in units of planes, so we proposed virtual DRM. I think the advantage of vDRM is that you can use general DRM APIs in userland. > I don't think that's not the way to go, at least not by touching each > single display driver, and not hardcoding the planes in DT. Thank you for comment. I will reconsider about DT. > What's the actual use case you're doing that for ? Why not using some > userland compositor ? I think when latency is important (e.g., AR, VR, for displaying camera images in IVI systems), there may be use cases where the compositor cannot be used. Normally, when the image is passed through the compositor, it is displayed after 2 VSYNC at most, because the compositor combines the image with VSYNC synchronization. On the other hand, if we use vDRM, the image will be displayed at the next VSYNC, so it will be displayed after 1 VSYNC at most. Also, since the compositor is a single point of failure, we may not want to make it dependent on it. Best regards Tomohito Esaki From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 33A5AC48BDF for ; Tue, 22 Jun 2021 04:03:46 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F08E76128C for ; Tue, 22 Jun 2021 04:03:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F08E76128C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=igel.co.jp Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 5D61189ABA; Tue, 22 Jun 2021 04:03:45 +0000 (UTC) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0B8FC89ABA for ; Tue, 22 Jun 2021 04:03:44 +0000 (UTC) Received: by mail-pf1-x436.google.com with SMTP id p13so15434882pfw.0 for ; Mon, 21 Jun 2021 21:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=igel-co-jp.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=fDlc9TgaOD99jTxAWrDaocLPhWL0A0Lj9SHYh7Mvk9o=; b=o0yFPlq7pxYmbagKCCg+kimNiPNQn/TmmpLhgBCc4+gKAdI7guTaFh2HLcqRgOS+Y2 N31G1dYSTwJFSZONsIs6aTmlvFyMWs7sUSs6w5r2lIeIl7U7eAi64P51JFyLNIVopMIe clgwoPZrwBAPqe177UXF7XDOkjJEPcpxs/DLMSjcqe+emsSTFic8ZBcNj2+ZCBmsRZSL pIaW4QYUGKMmZVLpKimMt2ZiXi24RBko8/fxW56iwZZhUKa4Z5Yz0RJB7pLrd6CGGysv 4XFfuEt1cuayw5S6wYtqWNXLKq10QMJK/uZ2WyJulx4ckrvePNwDHZkP4e9ANEJGr9uu 3nLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fDlc9TgaOD99jTxAWrDaocLPhWL0A0Lj9SHYh7Mvk9o=; b=n3gCvWngsnDWp74K6Rj99AMirjFvgoeBjNezkoeUB6M/3QUW/JSlayPrsMFh94pTPx nvmljsXWEGBEJ5ST2Nd9mVSquKFN79K6Z1elz93d0WH549PoCQupvRBWZ5B4dcZObWRL oiUlM1OUjtCvjvEKdr0p3eqbUDI2CvdY9Du9suwSUT5WvGvGk8KjuX8t79a46krlaFmx uvzqzt3dC/IUqUDlOGh6uKleUKxzGGI545sW/HlAfqK+jFQq/KkaTfawiRVvBWIts8wU paTMLUfgzC5Z5yyDiA0kf/xpUp0DCv4jyLXg1rfkTSRL1sUtZX1PxYYnKBJ43ORiL0cz 3RpQ== X-Gm-Message-State: AOAM531bWgrjuHdivtdeJ+R06IzHLlm2xBRbYxMG+U5u1fk79K4gm5fH ay5Pc5GZZAyl6aewnZLY7Yld1Q== X-Google-Smtp-Source: ABdhPJyDcxIlsiXjWflxT5mU0F4cuX1u87XCPF+dYg++suxUBJdfPBs1yWMuqJH0lAgAd7Abm8KHjA== X-Received: by 2002:a62:b618:0:b029:2f9:f3b1:8afd with SMTP id j24-20020a62b6180000b02902f9f3b18afdmr1572467pff.81.1624334623646; Mon, 21 Jun 2021 21:03:43 -0700 (PDT) Received: from ?IPv6:240b:10:c9a0:ca00:5192:32ad:e5be:23cd? ([240b:10:c9a0:ca00:5192:32ad:e5be:23cd]) by smtp.gmail.com with ESMTPSA id 20sm16946099pfi.170.2021.06.21.21.03.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Jun 2021 21:03:43 -0700 (PDT) Subject: Re: [PATH 0/4] [RFC] Support virtual DRM To: "Enrico Weigelt, metux IT consult" References: <20210621062742.26073-1-etom@igel.co.jp> <7cde82a9-c60c-e527-eeac-eaad0c5842a1@metux.net> From: Esaki Tomohito Message-ID: <1cfab5f9-f275-aa53-00de-5da3fcea71c5@igel.co.jp> Date: Tue, 22 Jun 2021 13:03:39 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <7cde82a9-c60c-e527-eeac-eaad0c5842a1@metux.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, Takanari Hayama , Thomas Zimmermann , linux-doc@vger.kernel.org, David Airlie , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, Kieran Bingham , Laurent Pinchart , Damian Hobson-Garcia Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi, Enrico Weigelt Thank you for reply. On 2021/06/22 1:05, Enrico Weigelt, metux IT consult wrote: > On 21.06.21 08:27, Tomohito Esaki wrote: > > Hi, > >> Virtual DRM splits the overlay planes of a display controller into multiple >> virtual devices to allow each plane to be accessed by each process. >> >> This makes it possible to overlay images output from multiple processes on a >> display. For example, one process displays the camera image without compositor >> while another process overlays the UI. > > Are you attempting to create an simple in-kernel compositor ? I think the basic idea is the same as DRMlease. We want to separate the resources from the master in units of planes, so we proposed virtual DRM. I think the advantage of vDRM is that you can use general DRM APIs in userland. > I don't think that's not the way to go, at least not by touching each > single display driver, and not hardcoding the planes in DT. Thank you for comment. I will reconsider about DT. > What's the actual use case you're doing that for ? Why not using some > userland compositor ? I think when latency is important (e.g., AR, VR, for displaying camera images in IVI systems), there may be use cases where the compositor cannot be used. Normally, when the image is passed through the compositor, it is displayed after 2 VSYNC at most, because the compositor combines the image with VSYNC synchronization. On the other hand, if we use vDRM, the image will be displayed at the next VSYNC, so it will be displayed after 1 VSYNC at most. Also, since the compositor is a single point of failure, we may not want to make it dependent on it. Best regards Tomohito Esaki