2010/6/3 Kristian Høgsberg <k...@bitplanet.net>: >> But it is less flexible IMHO. Also, I am not convinced that EGLImageKHR to >> be >> queryable, which is stemmed from using EGLImageKHR to represent >> pipe_resource. >> Using an EGLImageKHR also implies that an implementation must implement >> EGLImage in EGL/GLES/VG, where the latter seems to still miss a way to render >> into an EGLImage. Therefore, my idea is to use pbuffer to represent >> pipe_resource. This is in line with eglCreatePbufferFromClientBuffer. To be >> precise, > No, EGLImage is the right abstraction for this. An EGLImage is a > two-dimensional pixel array, which is exactly what we need here, since > it corresponds directly with what a DRM buffer is. A pbuffer has more > state, such as depth and stencil buffers. The whole point of this > extension was to be able to use a DRM buffer as an FBO renderbuffer. > My eglkms example doesn't demonstrate the main use case I have in mind > with the EGLImage/DRM integration, which is page flipping and giving > the application control over buffers. The idea is that the > application can allocate two EGLImages for double buffering and > alternate between attaching the two EGLImages as render buffers for an > FBO. The extensions I proposed, and also the patches, allow creating EGLImages from pbuffers. Pbuffers have more states and this allows them to be used with eglMakeCurrent, other than as FBO attachments. > The application is free to allocate more buffers for triple buffering > or to discard the back buffer and depth buffer if rendering goes idle. > The lifecycle of the EGLImage isn't tied to the lifecycle of the FBO > the way the pbuffer colorbuffer lifecycle is tied to the pbuffers. Creating an EGLImage from a pbuffer would extend the lifetime of the pbuffer the way an EGLImage extends the lifetime of a native pixmap or a texture object. > Also, using EGLConfig to describe the pixel format doesn't actaully > describe the layout of the pixels. We need a precise description, > similar to the MESA_FORMAT_* tokens. The idea is to use EGLConfig for creation, and add querys for orthogonal attributes of a pixel format such as the channel sizes, channel order, and etc. The precise description may be derived from the querying results. This is to avoid listing each format, but I do not have a strong opinion here. > If VG is an important use case for you and the lack of EGLImage > integration is a problem, I suggest defining an extension to specify > EGLImage use in VG instead. Or we can add both, but just the pbuffer > approach isn't sufficient. Pbuffer approach is like applying s/EGLImage/EGLSurface/ on EGLImage approach, plus allowing an EGLImage to be created from a pbuffer. This makes it a superset instead.
-- o...@lunarg.com _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
