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

[Rob Clark]

Tom,

hmm, I wonder if it was a bug/oversight for the YUV capabilities of
this extension to not depend on OES_EGL_image_external (which
unfortunately, doesn't seem to have a GL counterpart)?

I think this currently implies that you could sample from an imported
YUV eglimg using (for example) sampler2D in GL or GLES, which I think
was not the intention.

BR,
-R

On Mon, Feb 25, 2013 at 6:54 AM, Tom Cooksey  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.
>
>
> Cheers,
>
> Tom
>
>
>
>> -Original Message-
>> From: mesa-dev-bounces+tom.cooksey=arm.com at lists.freedesktop.org 
>> [mailto:mesa-dev-
>> bounces+tom.cooksey=arm.com at lists.freedesktop.org] On Behalf Of Tom 
>> Cooksey
>> Sent: 04 October 2012 13:10
>> To: mesa-dev at lists.freedesktop.org; linaro-mm-sig at lists.linaro.org; 
>> dri-
>> devel at lists.freedesktop.org; linux-media at vger.kernel.org
>> Subject: [Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - New draft!
>>
>> Hi All,
>>
>> After receiving a fair bit of feedback (thanks!), I've updated the
>> EGL_EXT_image_dma_buf_import spec
>> and expanded it to resolve a number of the issues. Please find the latest 
>> draft below and let
>> me
>> know any additional feedback you might have, either on the lists or by 
>> private e-mail - I
>> don't mind
>> which.
>>
>> I think the only remaining issue now is if we need a mechanism whereby an 
>> application can
>> query
>> which drm_fourcc.h formats EGL supports or if just failing with 
>> EGL_BAD_MATCH when the
>> application
>> has use one EGL doesn't support is sufficient. Any thoughts?
>>
>>
>> Cheers,
>>
>> Tom
>>
>>
>> 8<
>>
>>
>> Name
>>
>> EXT_image_dma_buf_import
>>
>> Name Strings
>>
>> EGL_EXT_image_dma_buf_import
>>
>> Contributors
>>
>> Jesse Barker
>> Rob Clark
>> Tom Cooksey
>>
>> Contacts
>>
>> Jesse Barker (jesse 'dot' barker 'at' linaro 'dot' org)
>> Tom Cooksey (tom 'dot' cooksey 'at' arm 'dot' com)
>>
>> Status
>>
>> DRAFT
>>
>> Version
>>
>> Version 4, October 04, 2012
>>
>> Number
>>
>> EGL Extension ???
>>
>> Dependencies
>>
>> EGL 1.2 is required.
>>
>> EGL_KHR_image_base is required.
>>
>> The EGL implementation must be running on a Linux kernel supporting the
>> dma_buf buffer sharing mechanism.
>>
>> This extension is written against the wording of the EGL 1.2 
>> Specification.
>>
>> Overview
>>
>> This extension allows creating an EGLImage from a Linux dma_buf file
>> descriptor or multiple file descriptors in the case of multi-plane YUV
>> images.
>>
>> New Types
>>
>> None
>>
>> New Procedures and Functions
>>
>> None
>>
>> New Tokens
>>
>> Accepted by the  parameter of eglCreateImageKHR:
>>
>> EGL_LINUX_DMA_BUF_EXT
>>
>> Accepted as an attribute in the  parameter of
>> eglCreateImageKHR:
>>
>> EGL_LINUX_DRM_FOURCC_EXT
>> EGL_DMA_BUF_PLANE0_FD_EXT
>> EGL_DMA_BUF_PLANE0_OFFSET_EXT
>> EGL_DMA_BUF_PLANE0_PITCH_EXT
>> EGL_DMA_BUF_PLANE1_FD_EXT
>> EGL_DMA_BUF_PLANE1_OFFSET_EXT
>> EGL_DMA_BUF_PLANE1_PITCH_EXT
>> EGL_DMA_BUF_PLANE2_FD_EXT
>> EGL_DMA_BUF_PLANE2_OFFSET_EXT
>> EGL_DMA_BUF_PLANE2_PITCH_EXT
>> EGL_YUV_COLOR_SPACE_HINT_EXT
>> EGL_SAMPLE_RANGE_HINT_EXT
>> EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT
>> EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT
>>
>> Accepted as the value for the EGL_YUV_COLOR_SPACE_HINT_EXT attribute:
>>
>> EGL_ITU_REC601_EXT
>> EGL_ITU_REC709_EXT
>> EGL_ITU_REC2020_EXT
>>
>> Accepted as the value for the EGL_SAMPLE_RANGE_HINT_EXT attribute:
>>
>> EGL_YUV_FULL_RANGE_EXT
>> EGL_YUV_NARROW_RANGE_EXT
>>
>> Accepted as the value for the EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT &
>> EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT attributes:
>>
>> EGL_YUV_CHROMA_SITING_0_EXT
>> EGL_YUV_CHROMA_SITING_0_5_EXT
>>
>>
>> Additions to Chapter 2 of the EGL 1.2 Specification (EGL Operation)
>>
>> Add to section 2.5.1 "EGLImage Specification" (as defined by the
>> EGL_KHR_image_base specification), in the description of
>> eglCreateImageKHR:
>>
>>"Values accepted for  are listed in Table aaa, below.
>>
>>   
>> +-++
>>   | |  Notes 
>> |
>>   
>> +-++
>>   |  EGL_LINUX_DMA_BUF_EXT  |   Used for EGLImages imported from Linux   
>> |
>>   | |   dma_buf file descriptors 
>> |
>>   
>> 

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

[Pekka Paalanen]

On Mon, 20 Jun 2016 09:45:26 -0400
Rob Clark  wrote:

> On Mon, Jun 20, 2016 at 8:37 AM, Pekka Paalanen  
> wrote:
> > On Fri, 17 Jun 2016 11:44:34 -0400
> > Rob Clark  wrote:
> >  
> >> On Fri, Jun 17, 2016 at 9:31 AM, Pekka Paalanen  
> >> wrote:  
> >> > On Fri, 17 Jun 2016 08:26:04 -0400
> >> > Rob Clark  wrote:
> >> >  
> >> >> On Fri, Jun 17, 2016 at 3:59 AM, Pekka Paalanen  >> >> gmail.com> wrote:  
> >> >> > On Thu, 16 Jun 2016 10:40:51 -0400
> >> >> > Rob Clark  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.  
> >> >
> >> > Indeed.
> >> >  
> >> >> > 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  >> >> >> 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.  
> >> >
> >> > In that case importing dmabuf works differently than importing a
> >> > wl_buffer (wl_drm), because for the latter, the y-invert flag is
> >> > returned such that the orientation will match GL. And the direct
> >> > scanout path goes through GBM since you have to import a wl_buffer, and
> >> > I haven't looked what GBM does wrt. y-flip if anything.
> >> >  
> >> >> 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?  
> >> >
> >> > That specific sentence implies nothing about orientation to me.
> >> > Furthermore, the 

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

[Pekka Paalanen]

On Fri, 17 Jun 2016 11:44:34 -0400
Rob Clark  wrote:

> On Fri, Jun 17, 2016 at 9:31 AM, Pekka Paalanen  
> wrote:
> > On Fri, 17 Jun 2016 08:26:04 -0400
> > Rob Clark  wrote:
> >  
> >> On Fri, Jun 17, 2016 at 3:59 AM, Pekka Paalanen  
> >> wrote:  
> >> > On Thu, 16 Jun 2016 10:40:51 -0400
> >> > Rob Clark  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.  
> >
> > Indeed.
> >  
> >> > 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  
> >> >> 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.  
> >
> > In that case importing dmabuf works differently than importing a
> > wl_buffer (wl_drm), because for the latter, the y-invert flag is
> > returned such that the orientation will match GL. And the direct
> > scanout path goes through GBM since you have to import a wl_buffer, and
> > I haven't looked what GBM does wrt. y-flip if anything.
> >  
> >> 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?  
> >
> > That specific sentence implies nothing about orientation to me.
> > Furthermore, the paragraph continues:
> >
> > "Although the intended purpose is sharing 2D image data, the
> > underlying interface makes no assumptions about the format or
> > purpose of the resource being shared, leaving those decisions
> > to the application and associated client APIs."
> >
> > Might "format" include orientation?
> >
> > How does "native orientation" connect with "GL texture coordinates"?
> > The latter have explicitly defined orientation and origin. For use in
> > GL, the right way 

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

[Pekka Paalanen]

On Fri, 17 Jun 2016 11:44:34 -0400
Rob Clark  wrote:

> On Fri, Jun 17, 2016 at 9:31 AM, Pekka Paalanen  
> wrote:
> > On Fri, 17 Jun 2016 08:26:04 -0400
> > Rob Clark  wrote:
> >  
> >> On Fri, Jun 17, 2016 at 3:59 AM, Pekka Paalanen  
> >> wrote:  
> >> > On Thu, 16 Jun 2016 10:40:51 -0400
> >> > Rob Clark  wrote:
> >> >  

> >> >> On Mon, Feb 25, 2013 at 6:54 AM, Tom Cooksey  
> >> >> 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.  
> >
> > In that case importing dmabuf works differently than importing a
> > wl_buffer (wl_drm), because for the latter, the y-invert flag is
> > returned such that the orientation will match GL. And the direct
> > scanout path goes through GBM since you have to import a wl_buffer, and
> > I haven't looked what GBM does wrt. y-flip if anything.
> >  
> >> 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?  
> >
> > That specific sentence implies nothing about orientation to me.
> > Furthermore, the paragraph continues:
> >
> > "Although the intended purpose is sharing 2D image data, the
> > underlying interface makes no assumptions about the format or
> > purpose of the resource being shared, leaving those decisions
> > to the application and associated client APIs."
> >
> > Might "format" include orientation?
> >
> > How does "native orientation" connect with "GL texture coordinates"?
> > The latter have explicitly defined orientation and origin. For use in
> > GL, the right way up image is having the origin in the bottom-left
> > corner. An image right way up is an image right way up, regardless
> > which corner is the origin. The problem comes when you start using
> > coordinates.
> >  
> >> 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.  
> >
> > Intel, yes, but since this happens *only* for the GL import path and
> > direct scanout is fine without y-flipping, I bet people just flipped y
> > and did not think twice, if there even was a problem. I just have a
> > habit of asking "why". ;-)  
> 
> well, if possible, try with one of the gallium drivers?

A good idea, I just need to do it at home with nouveau... which means I
probably won't be getting there any time soon.

> I'm honestly not 100% sure what it is supposed to be according to the
> spec, but I do know some of the linaro folks were doing v4l2dec ->
> glimagesink with dmabuf with both mali (I think some ST platform?) and
> freedreno (snapdragon db410c), and no one complained to me that the
> video was upside down for one or the other.  So I guess at least
> gallium and mali are doing the same thing.  No idea if that is the
> same thing that i965 does.


Thanks,
pq

> 
> BR,
> -R
> 
> > After all, using GL with windows and FBOs and stuff you very often find
> > yourself upside down, and I suspect people have got the habit of just
> > flipping it if it does not look right the first time. See e.g. the
> > row-order of data going into glTexImage2D...
> >
> > If the answer is "oops, well, dmabuf import is semantically y-flipping
> > when it should not, but we cannot fix it because that would break
> > everyone", I would be happy with that. I just want confirmation before
> > flipping the flip flag. :-)
> >
> >
> > 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: 

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

[Rob Clark]

On Mon, Jun 20, 2016 at 8:37 AM, Pekka Paalanen  wrote:
> On Fri, 17 Jun 2016 11:44:34 -0400
> Rob Clark  wrote:
>
>> On Fri, Jun 17, 2016 at 9:31 AM, Pekka Paalanen  
>> wrote:
>> > On Fri, 17 Jun 2016 08:26:04 -0400
>> > Rob Clark  wrote:
>> >
>> >> On Fri, Jun 17, 2016 at 3:59 AM, Pekka Paalanen  
>> >> wrote:
>> >> > On Thu, 16 Jun 2016 10:40:51 -0400
>> >> > Rob Clark  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.
>> >
>> > Indeed.
>> >
>> >> > 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  
>> >> >> 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.
>> >
>> > In that case importing dmabuf works differently than importing a
>> > wl_buffer (wl_drm), because for the latter, the y-invert flag is
>> > returned such that the orientation will match GL. And the direct
>> > scanout path goes through GBM since you have to import a wl_buffer, and
>> > I haven't looked what GBM does wrt. y-flip if anything.
>> >
>> >> 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?
>> >
>> > That specific sentence implies nothing about orientation to me.
>> > Furthermore, the paragraph continues:
>> >
>> > "Although the intended purpose is sharing 2D image data, the
>> > underlying interface makes no assumptions about the format or
>> > purpose of the resource being shared, leaving those decisions
>> > to the application and associated client APIs."
>> >
>> > Might "format" include orientation?
>> >
>> > How does 

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

[Pekka Paalanen]

On Fri, 17 Jun 2016 08:26:04 -0400
Rob Clark  wrote:

> On Fri, Jun 17, 2016 at 3:59 AM, Pekka Paalanen  
> wrote:
> > On Thu, 16 Jun 2016 10:40:51 -0400
> > Rob Clark  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.

Indeed.

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

In that case importing dmabuf works differently than importing a
wl_buffer (wl_drm), because for the latter, the y-invert flag is
returned such that the orientation will match GL. And the direct
scanout path goes through GBM since you have to import a wl_buffer, and
I haven't looked what GBM does wrt. y-flip if anything.

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

That specific sentence implies nothing about orientation to me.
Furthermore, the paragraph continues:

"Although the intended purpose is sharing 2D image data, the
underlying interface makes no assumptions about the format or
purpose of the resource being shared, leaving those decisions
to the application and associated client APIs."

Might "format" include orientation?

How does "native orientation" connect with "GL texture coordinates"?
The latter have explicitly defined orientation and origin. For use in
GL, the right way up image is having the origin in the bottom-left
corner. An image right way up is an image right way up, regardless
which corner is the origin. The problem comes when you start using
coordinates.

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

Intel, yes, but since this happens *only* for the GL import path 

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

[Rob Clark]

On Fri, Jun 17, 2016 at 9:31 AM, Pekka Paalanen  wrote:
> On Fri, 17 Jun 2016 08:26:04 -0400
> Rob Clark  wrote:
>
>> On Fri, Jun 17, 2016 at 3:59 AM, Pekka Paalanen  
>> wrote:
>> > On Thu, 16 Jun 2016 10:40:51 -0400
>> > Rob Clark  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.
>
> Indeed.
>
>> > 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  
>> >> 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.
>
> In that case importing dmabuf works differently than importing a
> wl_buffer (wl_drm), because for the latter, the y-invert flag is
> returned such that the orientation will match GL. And the direct
> scanout path goes through GBM since you have to import a wl_buffer, and
> I haven't looked what GBM does wrt. y-flip if anything.
>
>> 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?
>
> That specific sentence implies nothing about orientation to me.
> Furthermore, the paragraph continues:
>
> "Although the intended purpose is sharing 2D image data, the
> underlying interface makes no assumptions about the format or
> purpose of the resource being shared, leaving those decisions
> to the application and associated client APIs."
>
> Might "format" include orientation?
>
> How does "native orientation" connect with "GL texture coordinates"?
> The latter have explicitly defined orientation and origin. For use in
> GL, the right way up image is having the origin in the bottom-left
> corner. An image right way up is an image right way up, regardless
> which corner is the origin. The problem comes when you start using
> coordinates.
>
>> Do you just get that w/ i965?  I know some linaro folks have been
>> using this extension to 

[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  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  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: 

[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  wrote:
> On Thu, 16 Jun 2016 10:40:51 -0400
> Rob Clark  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  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

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

[Rob Clark]

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

BR,
-R

On Mon, Feb 25, 2013 at 6:54 AM, Tom Cooksey  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.
>
>
> Cheers,
>
> Tom
>
>
>
>> -Original Message-
>> From: mesa-dev-bounces+tom.cooksey=arm.com at lists.freedesktop.org 
>> [mailto:mesa-dev-
>> bounces+tom.cooksey=arm.com at lists.freedesktop.org] On Behalf Of Tom 
>> Cooksey
>> Sent: 04 October 2012 13:10
>> To: mesa-dev at lists.freedesktop.org; linaro-mm-sig at lists.linaro.org; 
>> dri-
>> devel at lists.freedesktop.org; linux-media at vger.kernel.org
>> Subject: [Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - New draft!
>>
>> Hi All,
>>
>> After receiving a fair bit of feedback (thanks!), I've updated the
>> EGL_EXT_image_dma_buf_import spec
>> and expanded it to resolve a number of the issues. Please find the latest 
>> draft below and let
>> me
>> know any additional feedback you might have, either on the lists or by 
>> private e-mail - I
>> don't mind
>> which.
>>
>> I think the only remaining issue now is if we need a mechanism whereby an 
>> application can
>> query
>> which drm_fourcc.h formats EGL supports or if just failing with 
>> EGL_BAD_MATCH when the
>> application
>> has use one EGL doesn't support is sufficient. Any thoughts?
>>
>>
>> Cheers,
>>
>> Tom
>>
>>
>> 8<
>>
>>
>> Name
>>
>> EXT_image_dma_buf_import
>>
>> Name Strings
>>
>> EGL_EXT_image_dma_buf_import
>>
>> Contributors
>>
>> Jesse Barker
>> Rob Clark
>> Tom Cooksey
>>
>> Contacts
>>
>> Jesse Barker (jesse 'dot' barker 'at' linaro 'dot' org)
>> Tom Cooksey (tom 'dot' cooksey 'at' arm 'dot' com)
>>
>> Status
>>
>> DRAFT
>>
>> Version
>>
>> Version 4, October 04, 2012
>>
>> Number
>>
>> EGL Extension ???
>>
>> Dependencies
>>
>> EGL 1.2 is required.
>>
>> EGL_KHR_image_base is required.
>>
>> The EGL implementation must be running on a Linux kernel supporting the
>> dma_buf buffer sharing mechanism.
>>
>> This extension is written against the wording of the EGL 1.2 
>> Specification.
>>
>> Overview
>>
>> This extension allows creating an EGLImage from a Linux dma_buf file
>> descriptor or multiple file descriptors in the case of multi-plane YUV
>> images.
>>
>> New Types
>>
>> None
>>
>> New Procedures and Functions
>>
>> None
>>
>> New Tokens
>>
>> Accepted by the  parameter of eglCreateImageKHR:
>>
>> EGL_LINUX_DMA_BUF_EXT
>>
>> Accepted as an attribute in the  parameter of
>> eglCreateImageKHR:
>>
>> EGL_LINUX_DRM_FOURCC_EXT
>> EGL_DMA_BUF_PLANE0_FD_EXT
>> EGL_DMA_BUF_PLANE0_OFFSET_EXT
>> EGL_DMA_BUF_PLANE0_PITCH_EXT
>> EGL_DMA_BUF_PLANE1_FD_EXT
>> EGL_DMA_BUF_PLANE1_OFFSET_EXT
>> EGL_DMA_BUF_PLANE1_PITCH_EXT
>> EGL_DMA_BUF_PLANE2_FD_EXT
>> EGL_DMA_BUF_PLANE2_OFFSET_EXT
>> EGL_DMA_BUF_PLANE2_PITCH_EXT
>> EGL_YUV_COLOR_SPACE_HINT_EXT
>> EGL_SAMPLE_RANGE_HINT_EXT
>> EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT
>> EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT
>>
>> Accepted as the value for the EGL_YUV_COLOR_SPACE_HINT_EXT attribute:
>>
>> EGL_ITU_REC601_EXT
>> EGL_ITU_REC709_EXT
>> EGL_ITU_REC2020_EXT
>>
>> Accepted as the value for the EGL_SAMPLE_RANGE_HINT_EXT attribute:
>>
>> EGL_YUV_FULL_RANGE_EXT
>> EGL_YUV_NARROW_RANGE_EXT
>>
>> Accepted as the value for the EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT &
>> EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT attributes:
>>
>> EGL_YUV_CHROMA_SITING_0_EXT
>> EGL_YUV_CHROMA_SITING_0_5_EXT
>>
>>
>> Additions to Chapter 2 of the EGL 1.2 Specification (EGL Operation)
>>
>> Add to section 2.5.1 "EGLImage Specification" (as defined by the
>> EGL_KHR_image_base specification), in the description of
>> eglCreateImageKHR:
>>
>>"Values accepted for  are listed in Table aaa, below.
>>
>>   
>> +-++
>>   | |  Notes 
>> |
>>   
>> +-++
>>   |  EGL_LINUX_DMA_BUF_EXT  |   Used for EGLImages imported from Linux   
>> |
>>   | |   dma_buf file descriptors 
>> |
>>   
>> +-++
>>Table aaa.  Legal values for eglCreateImageKHR  parameter
>>
>> ...
>>
>> 

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

[Tom Cooksey]

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.


Cheers,

Tom



> -Original Message-
> From: mesa-dev-bounces+tom.cooksey=arm.com at lists.freedesktop.org 
> [mailto:mesa-dev-
> bounces+tom.cooksey=arm.com at lists.freedesktop.org] On Behalf Of Tom Cooksey
> Sent: 04 October 2012 13:10
> To: mesa-dev at lists.freedesktop.org; linaro-mm-sig at lists.linaro.org; dri-
> devel at lists.freedesktop.org; linux-media at vger.kernel.org
> Subject: [Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - New draft!
> 
> Hi All,
> 
> After receiving a fair bit of feedback (thanks!), I've updated the
> EGL_EXT_image_dma_buf_import spec
> and expanded it to resolve a number of the issues. Please find the latest 
> draft below and let
> me
> know any additional feedback you might have, either on the lists or by 
> private e-mail - I
> don't mind
> which.
> 
> I think the only remaining issue now is if we need a mechanism whereby an 
> application can
> query
> which drm_fourcc.h formats EGL supports or if just failing with EGL_BAD_MATCH 
> when the
> application
> has use one EGL doesn't support is sufficient. Any thoughts?
> 
> 
> Cheers,
> 
> Tom
> 
> 
> 8<
> 
> 
> Name
> 
> EXT_image_dma_buf_import
> 
> Name Strings
> 
> EGL_EXT_image_dma_buf_import
> 
> Contributors
> 
> Jesse Barker
> Rob Clark
> Tom Cooksey
> 
> Contacts
> 
> Jesse Barker (jesse 'dot' barker 'at' linaro 'dot' org)
> Tom Cooksey (tom 'dot' cooksey 'at' arm 'dot' com)
> 
> Status
> 
> DRAFT
> 
> Version
> 
> Version 4, October 04, 2012
> 
> Number
> 
> EGL Extension ???
> 
> Dependencies
> 
> EGL 1.2 is required.
> 
> EGL_KHR_image_base is required.
> 
> The EGL implementation must be running on a Linux kernel supporting the
> dma_buf buffer sharing mechanism.
> 
> This extension is written against the wording of the EGL 1.2 
> Specification.
> 
> Overview
> 
> This extension allows creating an EGLImage from a Linux dma_buf file
> descriptor or multiple file descriptors in the case of multi-plane YUV
> images.
> 
> New Types
> 
> None
> 
> New Procedures and Functions
> 
> None
> 
> New Tokens
> 
> Accepted by the  parameter of eglCreateImageKHR:
> 
> EGL_LINUX_DMA_BUF_EXT
> 
> Accepted as an attribute in the  parameter of
> eglCreateImageKHR:
> 
> EGL_LINUX_DRM_FOURCC_EXT
> EGL_DMA_BUF_PLANE0_FD_EXT
> EGL_DMA_BUF_PLANE0_OFFSET_EXT
> EGL_DMA_BUF_PLANE0_PITCH_EXT
> EGL_DMA_BUF_PLANE1_FD_EXT
> EGL_DMA_BUF_PLANE1_OFFSET_EXT
> EGL_DMA_BUF_PLANE1_PITCH_EXT
> EGL_DMA_BUF_PLANE2_FD_EXT
> EGL_DMA_BUF_PLANE2_OFFSET_EXT
> EGL_DMA_BUF_PLANE2_PITCH_EXT
> EGL_YUV_COLOR_SPACE_HINT_EXT
> EGL_SAMPLE_RANGE_HINT_EXT
> EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT
> EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT
> 
> Accepted as the value for the EGL_YUV_COLOR_SPACE_HINT_EXT attribute:
> 
> EGL_ITU_REC601_EXT
> EGL_ITU_REC709_EXT
> EGL_ITU_REC2020_EXT
> 
> Accepted as the value for the EGL_SAMPLE_RANGE_HINT_EXT attribute:
> 
> EGL_YUV_FULL_RANGE_EXT
> EGL_YUV_NARROW_RANGE_EXT
> 
> Accepted as the value for the EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT &
> EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT attributes:
> 
> EGL_YUV_CHROMA_SITING_0_EXT
> EGL_YUV_CHROMA_SITING_0_5_EXT
> 
> 
> Additions to Chapter 2 of the EGL 1.2 Specification (EGL Operation)
> 
> Add to section 2.5.1 "EGLImage Specification" (as defined by the
> EGL_KHR_image_base specification), in the description of
> eglCreateImageKHR:
> 
>"Values accepted for  are listed in Table aaa, below.
> 
>   +-++
>   | |  Notes |
>   +-++
>   |  EGL_LINUX_DMA_BUF_EXT  |   Used for EGLImages imported from Linux   |
>   | |   dma_buf file descriptors |
>   +-++
>Table aaa.  Legal values for eglCreateImageKHR  parameter
> 
> ...
> 
> If  is EGL_LINUX_DMA_BUF_EXT,  must be a valid display, 
> must be EGL_NO_CONTEXT, and  must be NULL, cast into the type
> EGLClientBuffer. The details of the image is specified by the attributes
> passed into eglCreateImageKHR. Required attributes and their values are as
> follows:
> 
> * EGL_WIDTH & EGL_HEIGHT: The logical dimensions of the buffer in 
> pixels
> 
> * EGL_LINUX_DRM_FOURCC_EXT: The pixel format of the buffer, as 
> specified
> 

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

[Tom Cooksey]

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.


Cheers,

Tom



 -Original Message-
 From: mesa-dev-bounces+tom.cooksey=arm@lists.freedesktop.org 
 [mailto:mesa-dev-
 bounces+tom.cooksey=arm@lists.freedesktop.org] On Behalf Of Tom Cooksey
 Sent: 04 October 2012 13:10
 To: mesa-...@lists.freedesktop.org; linaro-mm-...@lists.linaro.org; dri-
 de...@lists.freedesktop.org; linux-me...@vger.kernel.org
 Subject: [Mesa-dev] [RFC] New dma_buf - EGLImage EGL extension - New draft!
 
 Hi All,
 
 After receiving a fair bit of feedback (thanks!), I've updated the
 EGL_EXT_image_dma_buf_import spec
 and expanded it to resolve a number of the issues. Please find the latest 
 draft below and let
 me
 know any additional feedback you might have, either on the lists or by 
 private e-mail - I
 don't mind
 which.
 
 I think the only remaining issue now is if we need a mechanism whereby an 
 application can
 query
 which drm_fourcc.h formats EGL supports or if just failing with EGL_BAD_MATCH 
 when the
 application
 has use one EGL doesn't support is sufficient. Any thoughts?
 
 
 Cheers,
 
 Tom
 
 
 8
 
 
 Name
 
 EXT_image_dma_buf_import
 
 Name Strings
 
 EGL_EXT_image_dma_buf_import
 
 Contributors
 
 Jesse Barker
 Rob Clark
 Tom Cooksey
 
 Contacts
 
 Jesse Barker (jesse 'dot' barker 'at' linaro 'dot' org)
 Tom Cooksey (tom 'dot' cooksey 'at' arm 'dot' com)
 
 Status
 
 DRAFT
 
 Version
 
 Version 4, October 04, 2012
 
 Number
 
 EGL Extension ???
 
 Dependencies
 
 EGL 1.2 is required.
 
 EGL_KHR_image_base is required.
 
 The EGL implementation must be running on a Linux kernel supporting the
 dma_buf buffer sharing mechanism.
 
 This extension is written against the wording of the EGL 1.2 
 Specification.
 
 Overview
 
 This extension allows creating an EGLImage from a Linux dma_buf file
 descriptor or multiple file descriptors in the case of multi-plane YUV
 images.
 
 New Types
 
 None
 
 New Procedures and Functions
 
 None
 
 New Tokens
 
 Accepted by the target parameter of eglCreateImageKHR:
 
 EGL_LINUX_DMA_BUF_EXT
 
 Accepted as an attribute in the attrib_list parameter of
 eglCreateImageKHR:
 
 EGL_LINUX_DRM_FOURCC_EXT
 EGL_DMA_BUF_PLANE0_FD_EXT
 EGL_DMA_BUF_PLANE0_OFFSET_EXT
 EGL_DMA_BUF_PLANE0_PITCH_EXT
 EGL_DMA_BUF_PLANE1_FD_EXT
 EGL_DMA_BUF_PLANE1_OFFSET_EXT
 EGL_DMA_BUF_PLANE1_PITCH_EXT
 EGL_DMA_BUF_PLANE2_FD_EXT
 EGL_DMA_BUF_PLANE2_OFFSET_EXT
 EGL_DMA_BUF_PLANE2_PITCH_EXT
 EGL_YUV_COLOR_SPACE_HINT_EXT
 EGL_SAMPLE_RANGE_HINT_EXT
 EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT
 EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT
 
 Accepted as the value for the EGL_YUV_COLOR_SPACE_HINT_EXT attribute:
 
 EGL_ITU_REC601_EXT
 EGL_ITU_REC709_EXT
 EGL_ITU_REC2020_EXT
 
 Accepted as the value for the EGL_SAMPLE_RANGE_HINT_EXT attribute:
 
 EGL_YUV_FULL_RANGE_EXT
 EGL_YUV_NARROW_RANGE_EXT
 
 Accepted as the value for the EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT 
 EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT attributes:
 
 EGL_YUV_CHROMA_SITING_0_EXT
 EGL_YUV_CHROMA_SITING_0_5_EXT
 
 
 Additions to Chapter 2 of the EGL 1.2 Specification (EGL Operation)
 
 Add to section 2.5.1 EGLImage Specification (as defined by the
 EGL_KHR_image_base specification), in the description of
 eglCreateImageKHR:
 
Values accepted for target are listed in Table aaa, below.
 
   +-++
   |  target   |  Notes |
   +-++
   |  EGL_LINUX_DMA_BUF_EXT  |   Used for EGLImages imported from Linux   |
   | |   dma_buf file descriptors |
   +-++
Table aaa.  Legal values for eglCreateImageKHR target parameter
 
 ...
 
 If target is EGL_LINUX_DMA_BUF_EXT, dpy must be a valid display, ctx
 must be EGL_NO_CONTEXT, and buffer must be NULL, cast into the type
 EGLClientBuffer. The details of the image is specified by the attributes
 passed into eglCreateImageKHR. Required attributes and their values are as
 follows:
 
 * EGL_WIDTH  EGL_HEIGHT: The logical dimensions of the buffer in 
 pixels
 
 * EGL_LINUX_DRM_FOURCC_EXT: The pixel format of the buffer, as 
 specified
   by drm_fourcc.h and used as the pixel_format parameter of the
   drm_mode_fb_cmd2 ioctl.
 
 *