[Mesa-dev] intel, dma-buf import and egl image external

[Chad Versace]

On Tue, Apr 29, 2014 at 01:21:11PM -0700, Eric Anholt wrote:
> Chad Versace <chad.versace at linux.intel.com> writes:
> 
> > On Mon, Mar 24, 2014 at 09:07:32AM +1000, Dave Airlie wrote:
> >> On Sat, Mar 8, 2014 at 12:13 AM, Pohjolainen, Topi
> >> <topi.pohjolainen at intel.com> wrote:
> >> > On Mon, Mar 03, 2014 at 01:19:48PM +1000, Dave Airlie wrote:
> >> >> There is a comment and two checks in the i965 dma-buf importer,
> >> >>
> >> >> * Images originating via EGL_EXT_image_dma_buf_import can be used only
> >> >> * with GL_OES_EGL_image_external only.
> >> >>
> >> >> however I can't find any reference to this in the spec txt, and
> >> >> removing the checks make my test app run fine using TEXTURE_2D.
> >> >
> >> > You are correct that there is nothing in the spec about this, but it also leaves
> >> > it open for the driver to choose on which buffers it allows the external
> >> > sampling.
> >> > After quite a bit of debate on when/where it would be safe to use dma-buffers,
> >> > it was decided that we simply allow dma-buffers for external sampling only -
> >> > that extension already restricts the use for single-miplevel and read-only
> >> > which is exactly what we wanted.
> >> > The same time it wasn't clear what kind of sources we should allow for external
> >> > sampling (besides dma), and hence we simply kept things as they were before -
> >> > none other. Note that before the introduction of dma-buffers the image external
> >> > extension wasn't enabled at all on i965.
> >> >
> >> 
> >> This is a really bad idea, since it means you can't use dma-buf
> >> imported things with standard shader programs, if I want to import a
> >> dma-buf I shouldn't have to write specific shader programs or use
> >> special bindings, unless the spec says so.
> >
> > Bringing your request to its logical conclusion...
> >
> >> Either the spec should be more restrictive, or the implementation
> >> shouldn't have arbitrary differences from what other implementations
> >> could do.
> >
> > ...leads to disaster.  It's naive to expect each implementation to support
> > what other implementations *could*, or even *currently* do.
> >
> > Are you prepared to impelement support for these horrorshows?
> >
> > A. Import a YUV EGLImage backed by two dma_bufs (Y in the first, UV in
> >    the second) as a GL_TEXTURE_EXTERNAL_OES and transparently handle the
> >    YUV->RGB transcode in your shader code generator? Because, iirc, ARM's
> >    EGL/GLES2 stack supports that for Chrome.
> >
> > B. Same idea as A, but support importing the image as a GL_TEXTURE_2D
> >    and again transparently handle the YUV->RGB transcode. 
> >    Because, for all we know, ARM's stack may support that too.
> 
> Ignore YUV for now.  YUV is the thing that image_external is for, with
> all of its weird requirements and unspecifiedness and making your images
> undefined on import.
> 
> What airlied wants (I think) and what I definitely want, is to import
> normal ARGB dma_bufs and use them with GL_TEXTURE_2D.  I think we can do
> this, and it's just a matter of making some solid tests to make sure
> we're not screwing up sibling management, and that the offset/stride/etc
> handling all works.

Adding support for GL_TEXTURE_2D from ARGB dma_bufs sounds genuinely
useful and a good idea, as long as orphaning is magaged correctly.

What I'm opposed to is a blanket policy of "if Mesa driver xyz can do
abc with dma_buf EGLImages, then i965 must do abc too".

That's how I interpreted arlied's "the implementation shouldn't have
arbitrary differences from what other implementations could do". Looks
like I interpreted him incorrectly.