minigbm/cros_gralloc handle struct (Was: Re: [drm_hwc] PSA: drm_hwc submissions via gitlab)

From: Tomasz Figa <tfiga@chromium.org>
To: Mauro Rossi <issor.oruam@gmail.com>,
	astrachan@google.com, Sean Paul <seanpaul@chromium.org>,
	Gurchetan Singh <gurchetansingh@chromium.org>
Cc: "robert.foss" <robert.foss@collabora.com>,
	alexandru-cosmin.gheorghe@arm.com, liviu.dudau@arm.com,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"Stefan Schake" <stschake@gmail.com>,
	"Isaac Simha" <isimha@nvidia.com>,
	"Shih-hsin Li" <seasonl@nvidia.com>,
	rhyskidd@gmail.com, "Puneet Kumar" <puneetster@google.com>,
	ghartman@google.com, "Chih-Wei Huang" <cwhuang@linux.org.tw>,
	"Stéphane Marchesin" <marcheu@chromium.org>,
	"Kondapally, Kalyan" <kalyan.kondapally@intel.com>,
	"Thierry Reding" <treding@nvidia.com>,
	danalbert@google.com, "Niranjan Artal" <nartal@nvidia.com>,
	dimitrysh@google.com, salidoa@google.com,
	"Allen Martin" <amartin@nvidia.com>,
	david.hanna11@gmail.com, "Zach Reizner" <zachr@chromium.org>,
	matt.szczesiak@arm.com, marissaw@google.com,
	"David Ung" <davidu@nvidia.com>
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	[thread overview]
Message-ID: <CAAFQd5B_HfFWnsuE8WHi0bjdQLFFaWobrRcLk5odTvaDdFjS0Q@mail.gmail.com> (raw)
In-Reply-To: <CAEQFVGb7mLt2AvBoxU2q4jk6U8MHNb7n3J7=+DvuYrzzafmJzw@mail.gmail.com>

[-- Attachment #1.1: Type: text/plain, Size: 2067 bytes --]

[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:

>
> Il 04 mag 2018 19:51, "Alistair Strachan" <astrachan@google.com> ha
> scritto:
>
> On Fri, May 4, 2018 at 10:35 AM Sean Paul <seanpaul@chromium.org> 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

[-- Attachment #1.2: Type: text/html, Size: 3582 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel