[Mesa-dev] intel, dma-buf import and egl image external
Axel Davy
axel.davy at ens.fr
Sat Mar 22 20:58:51 PDT 2014
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 argb8888 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140322/ec894182/attachment.html>
More information about the mesa-dev
mailing list