[Mesa-dev] egl dma-buf export extension again

[Kristian Høgsberg]

On Tue, Mar 3, 2015 at 10:43 AM, Chad Versace <chad.versace at intel.com> wrote:
> On 03/02/2015 09:36 PM, Dave Airlie wrote:
>> On 3 March 2015 at 13:57, Dave Airlie <airlied at gmail.com> wrote:
>>>
>>> Okay I've revised this to add some more info to the interface,
>>> essentially I need to get the fourcc back so I can later pass
>>> it across the "wire" to the EGL_EXT_image_dma_buf_import, also
>>> the number of planes (though for my usecase I don't care so much).
>>>
>>> The problem with EGL_MESA_drm_image is that I've no idea how to retrieve
>>> the internal format of an image so I know what to tell the other side,
>>> since I just create a normal 2D texture and want to export it,
>>> I need to know what format mesa internally picked for it. This works
>>> out the fourcc and returns it.
>>>
>>
>> While talking to krh on irc he mentioned that maybe I should skip egl images
>>
>> and go straight to the texture id->dma-buf extension,
>>
>> again any opinions from anyone in the area would be useful.
>
> Please use EGLImages as the import/export object. That provides
> consistency with existing similar EGL APIs. And it allows a clean
> separation between EGL-aware code and GL-aware code in applications
> and compositors.
>
> For what it's worth, extensions in this area being developed by Google's
> Chrome OS team also use EGLImages as the transport object.

We can't both implement EGLImages in a compliant way *and* use them
for cross-process sharing like we do.  The spec language around
orphaning and siblings is obscure, but the idea is that whenever you
add a sibling (another client API object, eg a texture or a vg
renderbuffer) the contents become invalid.  The intended use case is
that you create all siblings up front and then start using them.  For
example, to share an image between VG and GL, you create the VG
buffer, then the EGLImage and then the GL texture.  Implementations
will defer allocation until all the siblings are set up and then only
once you start rendering allocate the memory.  This allows the
implementation to accommodate constraints from all siblings. If you
add another sibling, the implementation may have to reallocate storage
to satisfy new constraints.  This clearly isn't compatible with how we
create and share EGLImages left and right across process boundaries.
Khronos specifically developed EGLStreams as a cross-process color
buffer sharing mechanism without pulling in EGLImage as a dependency.

Anyway, the damage is done and we can continue digging ourselves
deeper into this hole, but we should at least 1) have a good reason
why the extra EGLImage indirection is necessary (it also rules out GLX
usage) and 2) acknowledge that we're going to continue to rely on our
broken EGLImage semantics.

Kristian