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

[Chia-I Wu]

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,

  * use EGLSurface to represent the pipe_resource
  * Use attrib_list of eglCreatePbufferSurface to describe the resource
    template (same tokens as defined by EGL_MESA_image_system_use).  Use
    EGLConfig to describe the pipe_format.
  * use eglQuerySuface to query the pipe_resource.  Borrow the tokens from
    glGetFramebufferAttachmentParameteriv in GL 3.0 to query the exact pixel
    format

And for EGL_MESA_drm_image substitute,

  * use eglCreatePbufferFromClientBuffer to create a pipe_resource from a
    winsys_handle.  Describe the winsys_handle using the attrib_list.
    (Or personally, I prefer to add eglCreatePbufferFromBO)
  * use eglQuerySurface again to query the pipe_resource.

This allows the DRM BO to be drawn without using FBO (OpenVG!), provides more
flexibility in describing the pixel format, and remove the dependency on
EGLImage.  Another extension similar to EGL_KHR_image_pixmap may be added to
support creation of an EGLImageKHR from a pbuffer.  All color/depth buffer
issues are resolved as they are in eglCreatePbufferFromClientBuffer or
EGL_KHR_image_pixmap.

-- 
olv at LunarG.com