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

Jakob Bornecrantz wallbraker at gmail.com
Thu Jun 3 10:00:41 PDT 2010


2010/6/3 Chia-I Wu <olvaffe at gmail.com>:
> 2010/6/3 Kristian Høgsberg <krh at bitplanet.net>:
>> 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.
>>
>> There is really only a handful of formats that we care about and
>> having all this query machinery to go through just to get to the
>> equivalent of MESA_FORMAT_ARGB8888 seems awkward.
>>
>>>> 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.
>>
>> I don't want to create an full EGLSurface when all I need is an
>> EGLImage.  I know I can create an EGLImage from the surface and then
>> destroy the surface, but don't you think that's backwards?  We can add
>> an extension that lets you create an EGL pbuffer surface from an
>> EGLImage if you need a surface for VG.  What is your concern about
>> eglQueryImage exactly?
> Existing EGLImage extensions create an EGLImage from an existing resource.
> eglQueryImage is needed in the new extension because it does not follow this
> practice.  That bothers me.
>
> There are other ways to achieve the same goal while not breaking the practice.
> Pbuffer is one example.  Using an alternative entry point such as
>
>  img = eglCreateDRMImageKHR(dpy, &name, &stride, ...);
>
> is another.  I do prefer these two approaches over eglQueryImage.

Currently these extensions try to address two use cases. Creating
Images to be shared between processes. Creating resources to be used
as a scanout target. Leaving the sharing aside until later. Lets look
at some of the problems associated with that.

Resources suitable for scanout can be used as a render target and as a
sampling source. So renderbuffer and/or texture is a good
representation of it, it is also how we want to operate on it, but
they are both GL objects. A EGL image however can be both of these
objects and more and is far more flexible then a EGL surface. So lets
use EGL image as the sharing object.

The problem is that we just can't go from a any texture that happens
to be large enough to a scanout buffer. Most hardware have stricter
limitations on stride, tiling, placement, etc on scanout buffers then
textures/rendertargets or those limitation make certain uses slower or
use more memory compared to normal textures/renderbuffers. So we can't
just go around creating all texture and renderbuffer as suitable for
scanout just because sometime we might use it as a scanout, because it
would be slower and use more memory. Now we don't have a way to say a
texture/renderbuffer should be scanoutable in GL. And creating a EGL
image from a texture/rendertarget and then mutating it into a
scanoutable format is bad, it would effectively orphan the original
resource unless we do major hacking in the driver which I don't want
to do. Enter MESA_create_image and MESA_image_syste_use to solve this
problem. Ok now we have a EGL image that can be used as a scanout and
be shared to all the API's we want to use to render to it.

Now lets move on and try and get that image into KMS. If KMS had been
a normal Khronos API we would have added a extension to that API that
exported the function looking something like this "int
drmModeAddFBFromEGLImage(EGLImage img, unsigned *out)", this is in
line with how EGL image integration works with all other Khronos
API's. Now adding that function to the KMS API is a bit tricky. We
could just add it to the EGL API and I guess thats is what you
suggests. But it is awfully specific to just this use case. It would
be nice if we could also use this for the sharing use case and any
other for that matter. Enter MESA_get_image_attrib and MESA_drm_image.
The former being completely generic. And latter covering both the
scanout and shareing uses with very little effort.

Cheers Jakob.


More information about the mesa-dev mailing list