<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 19/11/2013, Zhigang Gong wrote : </div> <blockquote cite="mid:20131119073542.GK3252@gongzg-ivb" type="cite"> <pre wrap="">On Mon, Nov 18, 2013 at 10:52:22PM +0100, Axel Davy wrote: </pre> <blockquote type="cite"> <pre wrap="">This implements glamor_egl_create_textured_pixmap_from_gbm_bo, which is similar to glamor_egl_create_textured_pixmap, except it takes a gbm_bo as argument. Signed-off-by: Axel Davy <a class="moz-txt-link-rfc2396E" href="mailto:axel.davy@ens.fr"><axel.davy@ens.fr></a> --- The goal of this patch is to enable create textured pixmaps from bo without using gem names, which are forbidden on render-nodes. Since wlglamor xwayland DDX can potentially run under a render-node, it is required (and wlglamor uses gbm_bo). A gbm_bo can be created from an EGLImage, so this function can be used to implement dri3 support (and avoiding gem names): the DDX would use the Mesa extension to create an EGLImage from an fd, then import it as a gbm_bo, and pass it to glamor. Converting a gbm_bo to EGLImage and vice-versa is quite straightforward for Mesa. If it is planned that glamor would give functions to implement dri3 (get fd from pixmap, get pixmap from fd), then this patch is useless. </pre> </blockquote> <pre wrap="">There is no plan for DRI3 support currently. If you have any proposal which could support DIR3 in glamor, you are welcome to submit it here for discussion. For now, this patch LGTM. will push it latter.</pre> </blockquote> eglCreateImageKHR allows to create an image from a texture (this is only supported on intel currently). Glamor could then import the image as gbm_bo, get an handle from it, and use the correct ioctl to get an fd. To convert an fd into pixmap, it could use the eglCreateImageKHR extension to import an fd as an image (only supported on intel currently), and import it as a texture. That said, it would mean the DDX has less control over the bo format used by pixmaps, since it would never allocate the bo itself (tiling, etc, would be under the control of Mesa) That can be a problem for using the pixmap bo as scanout buffer. <blockquote cite="mid:20131119073542.GK3252@gongzg-ivb" type="cite"> <blockquote type="cite"> <pre wrap=""> The patch doesn't use 'struct gbm_bo *' but 'void *' to avoid compilation issues if glamor doesn't have gbm support. I've tested this patch on wlglamor with an intel card and a radeon card. The intel card produces correctly the image, but has an issue when rendering. I reported the bug. I have no issues with my radeon card. </pre> </blockquote> <pre wrap=""> Could you give a pointer to that bug with intel card? Thanks, Zhigang.</pre> </blockquote> Yes: <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> <a href="https://bugs.freedesktop.org/show_bug.cgi?id=71759">https://bugs.freedesktop.org/show_bug.cgi?id=71759</a> Axel Davy </body> </html>