-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kristian Høgsberg wrote: > Hello, > > 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.
is this mechanism extensible to support creating EGLImages *from* GL textures? It seems like it should in principle. I can see some utility in implementing EGL_KHR_gl_texture_2D_image and friends. This would probably be useful to glamor, for example. > 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. > > 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 I think the intention is that it just uses the format of the pixmap. If the pixmap is RGB, the image will be RGB. If the pixmap is RGBA, the image will be RGBA. The ability to ignore the alpha component of RGBA pixmaps is indeed missing. > 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 Don't call it that. "KHR" is kind of like "ARB". It means that it was voted on and approved by Khronos. Maybe call it EGL_MESA_image_pixmap_format. > attribute, EGL_NATIVE_PIXMAP_FORMAT_KHR that takes two values: > > EGL_NATIVE_PIXMAP_RGB_KHR > EGL_NATIVE_PIXMAP_RGBA_KHR > > Pretty straightforward. > > 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. Other than the few comments above, the description sounds good. It may take me a bit to get through all of the patches. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt1sKUACgkQX1gOwKyEAw+eowCfcxNRR7/Lbw9q+C/KIIE2JyNT IvsAoIb2g0V3wEhXSiafrjLms6gBlhAZ =Aj5X -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ 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
