On Tue, Apr 29, 2014 at 01:21:11PM -0700, Eric Anholt wrote: > Chad Versace <chad.vers...@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.pohjolai...@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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev