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

[Kristian Høgsberg]

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.

Ok, yes, I see your point.

> 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.

I actually like this much better.  The other thing I didn't like about
overloading eglCreateImageKHR (and this becomes even more evident the
way Jakob split up the extension) is that it's a big new generic
mechanism, and I'd really like to keep it simple and specific.  As far
as I understand, the khronos create_image extension was abandoned
because it grew out of control - feature creep.

How do you feel about going with eglCreateDRMImageMESA(dpy, &name,
&stride, attrib_list), where attrib list has EGL_WIDTH, EGL_HEIGHT,
EGL_IMAGE_FORMAT_MESA (with format tokens) and EGL_IMAGE_USE_MESA
flags for scanout/share.  And eglShareDRMImageMESA(dpy, image, &name)
to create a global name for the image?  And we can add an enum so we
can use an EGLImage with eglCreatePbufferFromClientBuffer.

Kristian