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

[Daniel Stone]

Hi,

On 3 March 2015 at 23:26, Kristian Høgsberg <krh at bitplanet.net> wrote:
> On Tue, Mar 3, 2015 at 10:43 AM, Chad Versace <chad.versace at intel.com> wrote:
>> 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.

Which is all fair enough, but I think it's worth noting that
SurfaceFlinger, when confronted with the exact same problem space,
decided that the same answer was the best way forward. So we've got
some precedent established there.

Given the various interesting and creative ways in which people have
broken their EGLImage implementations, I'm not really sure that I want
to leave them to chance another, much less standard, spec, which has
less of a precedent around it.

Cheers,
Daniel