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

[Kristian Høgsberg]

On Sat, May 29, 2010 at 6:35 PM, Chia-I Wu <olvaffe at gmail.com> wrote:
> Hi Jakob,
>
> I like the way the extensions are separated and presented.  But I have some
> thoughts about the entrypoints and EGL types to use.
>
> To begin with, I think the goal of this series of extensions is to export a
> subset of pipe_screen->resource_create, pipe_screen->resource_from_handle, and
> pipe_screen->resource_get_handle.  That is, to allow an app to create a
> single-leveled PIPE_TEXTURE_2D pipe_resource from a winsys handle or nowhere,
> and to query the pipe_resource and its winsys handle.
>
> For pipe_screen->resource_create, we need
>
>  * an EGL type to represent the pipe_resource
>  * a way to describe the resource template for resource creation
>  * a way to query the fields of a pipe_resource
>
> For pipe_screen->resource_from_handle and pipe_screen->resource_get_handle, we
> need
>
>  * a way to describe a (DRM) winsys_handle
>  * a way to query the winsys_handle of a pipe_resource
>
>
> With this view, EGL_MESA_create_image, EGL_MESA_get_image_attrib, and
> EGL_MESA_image_system_use
>
>  * use EGLImageKHR to represent the pipe_resource
>  * use attrib_list of eglCreateImageKHR to describe the resource template
>    (missing description of the pipe format)
>  * adds a function to query the width/height of a pipe_resource
>
> and EGL_MESA_drm_image
>
>  * uses attrib_list of eglCreateImageKHR to describe a DRM winsys_handle
>  * uses eglGetImageAttribMESA for querying
>
> The missing part is, if I did not overlook anything, a way to represent a
> pipe_format and to query the pipe_format, which can be as simple as exporting
> some of the pipe formats.
>
> 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 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.

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.

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.

Kristian