[Mesa-dev] [PATCH 0/6] RFC: DRM Image extensions

[Chia-I Wu]

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