Great work! 2010/2/12 Kristian Høgsberg <k...@bitplanet.net>: > Here's a patch series to implement a handful of EGLImage extensions in > the DRI2 EGL driver: > EGL_KHR_image_base > EGL_KHR_image_pixmap > GL_OES_EGL_image > The implementation is a little tricky, since the EGLImage is an EGL > (binding layer) type, but it's passed to client API functions such as > void glEGLImageTargetTexture2DOES (GLenum target, > GLeglImageOES image); > void glEGLImageTargetRenderbufferStorageOES (GLenum target, > GLeglImageOES image); > The image argument is an EGLImage and the binding agnostic GL > implementation can't do anything with it. So what I've done is to > pass the image argument all the way into the backend driver, which is > then expected to have some interface provided from the loader to map > the opaque EGLImage to a type the driver understands. > In the DRI case, I make this work with two new DRI extensions: DRI > image and DRI imageLookup. The DRI image extensions is implemented by > the driver and the loader (that is, src/egl/drivers/dri2) uses it to > create a __DRIimage from the GEM/TTM handle for a pixmap, or possibly > some other source. This is how EGL_KHR_image_pixmap is done. The DRI > imageLookup extension is implemented by the loader and passed to the > DRI driver at initialization time. The driver uses this extension to > map the opaque EGLImage handles back to a __DRIimage struct. Yeah, there is no other way around for this. st/egl will use lock_resource and unlock_resource in st_api for the same purpose, FWIW. I totally back this approach. > With this in place, I have implemented GL_OES_EGL_image. I added the > glapi specification for it and I've added it as a GL extension as > well. This is mostly boilerplate extension work, and it adds > dd_function_table hooks for the driver to implement. There still some > details I need to figure out here, for example, the extensions don't > show up in the EGL extension string. How come the GL extension needs to show up in EGL extension string? > Looking though the EGL_KHR_image_pixmap and GL_OES_EGL_image > extensions, there seems to be no way to specify the format of the > pixmap. With GLX_EXT_texture_from_pixmap, we can specifiy the format > as either RGB or RGBA through the attribute list passed to > glXBindTexImageEXT(). In the EGLImage model, there's no way to > specify this, so I've proposed an extension in patch 11: > EGL_KHR_image_pixmap_format. This adds an eglCreateImageKHR > attribute, EGL_NATIVE_PIXMAP_FORMAT_KHR that takes two values: > EGL_NATIVE_PIXMAP_RGB_KHR > EGL_NATIVE_PIXMAP_RGBA_KHR > Pretty straightforward. I don't quite understand this extension. egl_dri2 should be able to figure out the format of the pixmap (not entirely true with X pixmaps, but no entity has better knowledge than egl_dri2 does). Or is it to specify the desired internal format of the pixmap when bound to a texture object? To bind an RGBA pixmap as an RGB texture? > Finally I added a few new options to xeglgears: -pbuffer-texture, > which renders to an EGL pbuffer surface and textures using > eglBindTexImage() and -pixmap-texture, which renders to a EGL pixmap > surface and textures from that by creating an EGLImage from the > underlying X pixmap and binding that using GL_OES_EGL_image. > > Let me know what you think, I only had a quick look and the patches look good to me except for EGL_KHR_image_pixmap_format. I am leaving town for Chinese New Year. I won't be available until next Wednesday. Feel free to go ahead with the EGL related patches.
-- o...@lunarg.com ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
