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
