2010/2/11 Chia-I Wu <olva...@gmail.com>: > 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.
Good to hear. This was one of the more tricky things to piece together in this series. I'm pretty happy with how it worked out with the two DRI extensions, but this was something I was hoping to get a second opinion on. >> 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? True, GL_OES_EGL_image should show up in the GL or GLES extension strings, but the EGL_KHR_image etc extensions should show up in the EGL extension string. I don't expect it's a big deal, I just need to enable the extensions somewhere. >> 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? It's to know whether to bind it as RGB or RGBA when using the EGLImage as a texture. We can get the pixmap depth and make an educated guess; 15,16 or 24 -> RGB, 32 -> RGBA, and I think that should work. On the other hand eglBindTexImage() lets you specify whether to bind the pbuffer surface as RGB or RGBA by specifying the texture format using the EGL_TEXTURE_FORMAT create surface attribute. That way you can bind an RGBA pbuffer as an RGB texture. Also, we added a glXBindTexImage attribute to do the exact same thing, but I'm not sure why that was necessary... >> 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. Have fun! I'll add the get_geometry request to get the pixmap depth at creation time and use that to infer a texture format and hold off on the EGL_KHR_image_pixmap_format extension for now. Maybe some of the Khronos guys can have a look and see if it's needed. ------------------------------------------------------------------------------ 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
