[Mesa-dev] [PATCH 0/6] RFC: DRM Image extensions
Chia-I Wu
olvaffe at gmail.com
Wed Jun 2 22:01:00 PDT 2010
2010/6/3 Kristian Høgsberg <krh at 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.
--
olv at LunarG.com
More information about the mesa-dev
mailing list