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

[Chad Versace]

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.

An implementation has to draw the line somewhere. And Topi, Anholt, and
I carefully decided where that line would initially lie for i965.

If real users demand more features from dma-buf-images, then it makes
sense to implement them. Until then, supporting them leads to
a maintenance burden. Frankly, the Intel guys did not want to deal with
headache of correctly orphaning 2d textures backed by dma-buf-EGLImages.

(FYI. The only real world user of EGL_EXT_image_dma_buf_import I'm aware
of is Chrome on ARM. If iirc, it exclusively uses the extension to
import YUV data).

-Chad