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

[Jakob Bornecrantz]

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

And also because the use case for it was solved in another way. But in
defence of my create_image extension, its quite small and limited in
scope. But in Chia-I the fact that we lack configs to say which
formats we support is a bit sad. But I can also see how this thing can
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.

By Knuth's calculator, no! You have two operations create a image and
getting information, you do not combine it one gigantic function just
because you happen to not like generality. I mean why have a
eglShareDRMImageMESA function when it should clearly be baked into the
same function.

eglCreateDRMImageAndShareItAndGetStrideAndGetHandles(dpy, &kms_name,
&shared_handle, &stride, attrib_list);

If eglGetImageAttrib is so bad I guess we can add eglShareDRMImageMESA
and eglCreateFBFromImageMESA. But I still prefer to add a get
function.

Cheers Jakob.