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

[Chia-I Wu]

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.

-- 
olv at LunarG.com