From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomasz Figa Subject: minigbm/cros_gralloc handle struct (Was: Re: [drm_hwc] PSA: drm_hwc submissions via gitlab) Date: Mon, 07 May 2018 04:07:07 +0000 Message-ID: References: <20180503150409.GD73214@art_vandelay> <20180503191255.GG73214@art_vandelay> <20180504173541.GL73214@art_vandelay> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0139109845==" Return-path: Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) by gabe.freedesktop.org (Postfix) with ESMTPS id 175F06E078 for ; Mon, 7 May 2018 04:07:21 +0000 (UTC) Received: by mail-ua0-x22b.google.com with SMTP id e8so15278394uam.13 for ; Sun, 06 May 2018 21:07:21 -0700 (PDT) Received: from mail-ua0-f179.google.com (mail-ua0-f179.google.com. [209.85.217.179]) by smtp.gmail.com with ESMTPSA id o14-v6sm8290109vkb.29.2018.05.06.21.07.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 May 2018 21:07:18 -0700 (PDT) Received: by mail-ua0-f179.google.com with SMTP id i3so17501237uad.4 for ; Sun, 06 May 2018 21:07:18 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Mauro Rossi , astrachan@google.com, Sean Paul , Gurchetan Singh Cc: "robert.foss" , alexandru-cosmin.gheorghe@arm.com, liviu.dudau@arm.com, dri-devel , Stefan Schake , Isaac Simha , Shih-hsin Li , rhyskidd@gmail.com, Puneet Kumar , ghartman@google.com, Chih-Wei Huang , =?UTF-8?Q?St=C3=A9phane_Marchesin?= , "Kondapally, Kalyan" , Thierry Reding , danalbert@google.com, Niranjan Artal , dimitrysh@google.com, salidoa@google.com, Allen Martin , david.hanna11@gmail.com, Zach Reizner , matt.szczesiak@arm.com, marissaw@google.com, David Ung List-Id: dri-devel@lists.freedesktop.org --===============0139109845== Content-Type: multipart/alternative; boundary="f4030435b7a84020e5056b95cecd" --f4030435b7a84020e5056b95cecd Content-Type: text/plain; charset="UTF-8" [Really taking this to another thread. Leaving CC as is for the time being.] On Sat, May 5, 2018 at 4:16 AM Mauro Rossi wrote: > > Il 04 mag 2018 19:51, "Alistair Strachan" ha > scritto: > > On Fri, May 4, 2018 at 10:35 AM Sean Paul wrote: > >> On Fri, May 04, 2018 at 05:19:50PM +0000, Mauro Rossi wrote: > > [snip] > >> > Another question is for Intel and Chromeos developers: are you planning >> to >> > > update your minigbm projects to the new common gralloc_handle.h handle >> > structure in latest libdrm? >> > >> >> I assume yes, but I'm not hooked in to what's happening with minigbm. >> > > +1. We can take this to another thread. The main issue is that minigbm > assumes a 1:1 planes to handles paradigm, the new generic handle does not. > > > Thanks for the info > I'm personally skeptical about this, but adding Gurchetan, who is a better person to comment on this. My biggest concern is that it might not be possible to define a common handle that is really good for everyone. Also, since the handle would effectively be a stable ABI between independent components, changing it to accommodate for future features (or discovered issues ) would be problematic. Generally we designed our graphics stack in Chrome OS / ARC++ in a way that does not rely on the handle struct at all, so that we are free to change the struct in any way we want in the future, without any compatibility concerns (such as plane layout isssue mentioned before). For the needs of EGL and most of other consumers, we are doing well without any API extensions (most of the time we get some more complete struct, such as ANativeWindow(Buffer) and for ambiguous formats we adopted lock_ycbcr method). Our hwcomposer is the only exception for which we added some perform calls to retrieve data such as HAL pixel format, width, height, stride and backing store (unique ID within some private namespace of the gralloc instance, having similar properties to GEM handle within one DRI FD). Best regards, Tomasz --f4030435b7a84020e5056b95cecd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[Really taking this to another thread. Leaving CC as = is for the time being.]

On Sat, May 5, 2018 at 4:16 AM Mauro Rossi <issor.oruam@gmail.com> wrote:


=

For the needs of EGL and most of other consumers, we ar= e doing well without any API extensions (most of the time we get some more = complete struct, such as ANativeWindow(Buffer) and for ambiguous formats we= adopted lock_ycbcr method).

Our hwcomposer is the= only exception for which we added some perform calls to retrieve data such= as HAL pixel format, width, height, stride and backing store (unique ID wi= thin some private namespace of the gralloc instance, having similar propert= ies to GEM handle within one DRI FD).

Best regards= ,
Tomasz

--f4030435b7a84020e5056b95cecd-- --===============0139109845== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0139109845==--