2010/2/12 Ian Romanick <i...@freedesktop.org>: > -----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.
Yes, the plan is to add more entry points to the __DRIimage extension, along the lines of createImageForRenderbuffer, createImageForTexture2D etc. I want to do that before pushing the patches, but I wanted to get what I had now out to get some feedback. >> 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. Well, the pixmap doesn't have a "format". A window has a visual we can look at, but a pixmap only has depth. As I wrote to Chia-I, I'll do that and infer the format (RGB or RGBA) based on whether the depth of the pixmap, and drop the extension for now. There's still the possibility that somebody will want to bind a depth 32 pixmap as an RGB texture, which won't be possible without this extension. Whether or not that's useful, I'm not sure, but it's worth noting that the EGLBindTexImage() function allows a similar thing. You can pass an attribute/value pair to specify the texture format, so that a pbuffer EGLSurface with EGL_ALPHA_SIZE == 8 can still be bound with a texture format of RGB. Maybe it's something you can bring up with Khronos? >> 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. Well I called it that because I'd like somebody (hint hint :) to propose it to Khronos and get it approved that way. Don't worry, I wont commit it with that name. > >> 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. Cool. I guess I wasn't looking for a detailed review, mostly just an OK on the overall direction and some guidance on the pixmap format extension issue. Oh, does adding the GL_OES_EGL_image as a GL extension require anything from Khronos and does it look right to you? I guess I need to add the tokens and prototypes to glext.h as well... thanks, Kristian ------------------------------------------------------------------------------ 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
