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

[Brian Paul]

Jakob Bornecrantz wrote:
> 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.


What's the use-case for a scanout buffer that's used as a texture? 
That seems like an unusual case.

-Brian