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

[Rob Clark]

On Fri, Jun 17, 2016 at 3:59 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 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.

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 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.

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