Re: [Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - Final spec published!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 16 Jun 2016 10:40:51 -0400
Rob Clark <robdclark@xxxxxxxxx> wrote:

> So, if we wanted to extend this to support the fourcc-modifiers that
> we have on the kernel side for compressed/tiled/etc formats, what
> would be the right approach?
> 
> A new version of the existing extension or a new
> EGL_EXT_image_dma_buf_import2 extension, or ??

Hi Rob,

there are actually several things it might be nice to add:

- a fourth plane, to match what DRM AddFB2 supports

- the 64-bit fb modifiers

- queries for which pixel formats are supported by EGL, so a display
  server can tell the applications that before the application goes and
  tries with a random bunch of them, shooting in the dark

- queries for which modifiers are supported for each pixel format, ditto

I discussed these with Emil in the past, and it seems an appropriate
approach might be the following.

Adding the 4th plane can be done as revising the existing
EGL_EXT_image_dma_buf_import extension. The plane count is tied to
pixel formats (and modifiers?), so the user does not need to know
specifically whether the EGL implementation could handle a 4th plane or
not. It is implied by the pixel format.

Adding the fb modifiers needs to be a new extension, so that users can
tell if they are supported or not. This is to avoid the following false
failure: if user assumes modifiers are always supported, it will (may?)
provide zero modifiers explicitly. If EGL implementation does not
handle modifiers this would be rejected as unrecognized attributes,
while if the zero modifiers were not given explicitly, everything would
just work.

The queries obviously(?) need a new extension. It might make sense
to bundle both modifier support and the queries in the same new
extension.

We have some rough old WIP code at
https://git.collabora.com/cgit/user/lfrb/mesa.git/log/?h=T1410-modifiers
https://git.collabora.com/cgit/user/lfrb/egl-specs.git/log/?h=T1410


> On Mon, Feb 25, 2013 at 6:54 AM, Tom Cooksey <tom.cooksey@xxxxxxx> wrote:
> > Hi All,
> >
> > The final spec has had enum values assigned and been published on Khronos:
> >
> > http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
> >
> > Thanks to all who've provided input.

May I also pull your attention to a detail with the existing spec and
Mesa behaviour I am asking about in
https://lists.freedesktop.org/archives/mesa-dev/2016-June/120249.html
"What is EGL_EXT_image_dma_buf_import image orientation as a GL texture?"
Doing a dmabuf import seems to imply an y-flip AFAICT.


Thanks,
pq

Attachment: pgpcenNNnR1cZ.pgp
Description: OpenPGP digital signature

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

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux