[Mesa-dev] [RFC libdrm 0/5] Move alloc_handle_t from gralloc impls.
Robert Foss
robert.foss at collabora.com
Fri Dec 15 10:48:55 UTC 2017
+Kalyan Kondapally
On Wed, 2017-12-13 at 15:02 -0800, Gurchetan Singh wrote:
> Hi Robert,
>
> Thanks for looking into this! We need to decide if we want:
>
> (1) A common struct that implementations can subclass, i.e:
>
> struct blah_gralloc_handle {
> alloc_handle_t alloc_handle;
> int x, y, z;
> ....
> }
>
> (2) An accessor library that vendors can implement, i.e:
>
> struct drmAndroidHandleInfo {
> uint32_t (*get_fourcc)(buffer_handle_t handle);
> uint32_t (*get_stride)(buffer_handle_t handle, uint32_t plane);
> uint32_t (*get_offsets)(buffer_handle_t handle, uint32_t plane);
> uint64_t (*get_modifier)(buffer_handle_t handle);
> };
>
> From my perspective as someone who has to maintain the minigbm
> gralloc implementation, (2) is preferable since:
>
> a) We really don't have a need for fields like data_owner, void
> *data, etc. Also, minigbm puts per plane fds, strides, offsets into
> the handle. Separating the information for the first plane (for
> the alloc_handle_t) and then rest of the planes would be annoying.
>
> b) we can avoid the struct within a struct that happens when we
> subclass, since alignment/padding issues often pop up during
> serialization/de-serialization. Using __attribute__((aligned(xx)))
> is less portable than maintaining a POD struct.
>
> c) IMO creating the handle should be left to the gralloc
> implementation. Having accessor functions clearly defines what we
> need from libdrm -- to make up for shortcomings of the gralloc API
> for DRM/KMS use cases.
>
To me that is pretty persuasive, however I maintain 0 of these
implementations, so I'd like to get some input from Rob Herring
(gbm_gralloc) and Kalyan Kondapally (intel-minigbm) too.
The previous related discussion can be found here:
https://patchwork.freedesktop.org/patch/190406/
Rob.
>
> On Wed, Dec 13, 2017 at 9:30 AM, Robert Foss <robert.foss at collabora.c
> om> wrote:
> > This series moves {gbm,drm,cros}_gralloc_handle_t struct to libdrm,
> > since at least 4 implementations exist, and share a lot of
> > contents.
> > The idea is to keep the common stuff defined in one place, and
> > libdrm
> > is the common codebase to all of these platforms.
> >
> > Additionally, having this struct defined in libdrm will make it
> > easier for mesa and grallocs to communicate.
> >
> > Curretly missing is:
> > - Planar formats
> > - Get/Set functions
> >
> >
> > Planar formats
> > --------------
> > Support for planar formats is needed, but has not been added
> > yet, mostly since this was not already implemented in
> > {gbm,drm}_gralloc
> > and the fact the having at least initial backwards compatability
> > would
> > be nice. Anonymous unions can of course be used later on to provide
> > backwards compatability if so desired.
> >
> >
> > Get/Set functions
> > -----------------
> > During the previous discussion[1] one suggestion was to add
> > accessor
> > functions. In this RFC I've only provided a alloc_handle_create()
> > function.
> >
> > The Get/Set functions have not been added yet, I was hoping for
> > some
> > conclusive arguments for them being adeded.
> >
> > Lastly it was suggested by Rob Herring that having a fourcc<-
> > >android
> > pixel format conversion function would be useful.
> >
> >
> > [1] https://lists.freedesktop.org/archives/mesa-dev/2017-November/1
> > 78199.html
> >
> > Robert Foss (5):
> > android: Move gralloc handle struct to libdrm
> > android: Add version variable to alloc_handle_t
> > android: Mark alloc_handle_t magic variable as const
> > android: Remove member name from alloc_handle_t
> > android: Change alloc_handle_t format from Android format to
> > fourcc
> >
> > Android.mk | 8 +++-
> > Makefile.sources | 3 ++
> > android/alloc_handle.h | 87
> > ++++++++++++++++++++++++++++++++++++++++++++
> > android/gralloc_drm_handle.h | 1 +
> > 4 files changed, 97 insertions(+), 2 deletions(-)
> > create mode 100644 android/alloc_handle.h
> > create mode 120000 android/gralloc_drm_handle.h
> >
> > --
> > 2.14.1
> >
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20171215/0bdd94f3/attachment.sig>
More information about the mesa-dev
mailing list