Re: [Mesa-dev] intel, dma-buf import and egl image external
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
Re: [Mesa-dev] intel, dma-buf import and egl image external
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. Either the spec should be more restrictive, or the implementation shouldn't have arbitrary differences from what other implementations could do. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] intel, dma-buf import and egl image external
On Fri, Mar 07, 2014,Topi Pohjolainen 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. / /I must say this has been a problem when implementing dri3 support in glamor. We need to import fds (from argb buffers) and convert to a pixmap (which we might write to later.). This extension is the only way to import/ /fds a device independant way (gbm doesn't have that yet). The trick I had to use when writing the code is to convert to gbm_bo the EGLImage, then convert back the gbm_bo to EGLImage. The new EGLImage has no restrictions. Axel Davy ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] intel, dma-buf import and egl image external
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. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] intel, dma-buf import and egl image external
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. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
