On Fri, Jun 17, 2016 at 3:59 AM, Pekka Paalanen <ppaalanen@xxxxxxxxx> wrote: > 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. hmm, if we design it as "not passing modifier" == "zero modifier", and "never explicitly pass a zero modifier" then modifiers could be added without a new extension. Although I agree that queries would need a new extension.. so perhaps not worth being clever. > 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. I would have expected that *any* egl external image (dma-buf or otherwise) should have native orientation rather than gl orientation. It's somewhat useless otherwise. I didn't read it carefully yet (would need caffeine first ;-)) but EGL_KHR_image_base does say "This extension defines a new EGL resource type that is suitable for sharing 2D arrays of image data between client APIs" which to me implies native orientation. So that just sounds like a mesa bug somehow? Do you just get that w/ i965? I know some linaro folks have been using this extension to import buffers from video decoder with freedreno/gallium and no one mentioned the video being upside down. BR, -R > > Thanks, > pq -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
