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

[Pekka Paalanen]

On Thu, 16 Jun 2016 10:40:51 -0400
Rob Clark <robdclark at gmail.com> 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 at arm.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160617/b682eabc/attachment-0001.sig>