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

Chia-I Wu olvaffe at gmail.com
Thu Jun 3 00:09:44 PDT 2010


2010/6/3 Chia-I Wu <olvaffe at gmail.com>:
> 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.
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.

-- 
olv at LunarG.com


More information about the mesa-dev mailing list