2010/6/3 Chia-I Wu <olva...@gmail.com>: > 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. How about
#ifndef EGL_MESA_drm_buffer #define EGL_MESA_drm_buffer /* EGL will update the fields. If name == 0, a new buffer is allocated. */ typedef struct { EGLint config_id; EGLint width, height; khronos_uint32_t name; EGLint pitch; EGLint bpp; EGLint pad[4]; } EGLDRMBufferMESA, *EGLDRMBufferPtrMESA; #define EGL_DRM_BUFFER_MESA 0x3200 /* eglCreateImageKHR and eglCreatePbufferFromClientBuffer */ #define EGL_IMAGE_USE_MESA 0x3201 /* eglCreateImageKHR attribute */ #define EGL_IMAGE_USE_SHARED_MESA 0x1 /* EGL_IMAGE_USE_MESA bitfield */ #define EGL_IMAGE_USE_SCANOUT_MESA 0x2 /* EGL_IMAGE_USE_MESA bitfield */ #endif /* EGL_MESA_drm_buffer */ It allows a DRM buffer to be created for EGLImage or pbuffer, and to be exchanged across process boundary. It eliminates eglQueryImage that I have a little opinion about. Finally, it uses config_id to describe the format. It is precise to EGL, though imprecise to an app. Maybe adding {rgba}_mask help? If the struct is ever run out, we can always define EGL_MESA_drm_buffer2. -- o...@lunarg.com _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev