Wayland client library thread safety

[Pekka Paalanen]

On Tue, 24 Apr 2012 11:03:29 -0700
Bill Spitzak <spitzak at gmail.com> wrote:

> On 04/24/2012 09:15 AM, Arnaud Vrac wrote:
> 
> >> Sorry for probably wasting your time, but why does "EGL make this
> >> impossible"?
> >
> > Because eglSwapBuffers is unfortunately a blocking call.
> 
> After reading all these emails a bunch more times, I *think* I 
> understand the problem.
> 
> First of all, this is for "EGL atop Wayland" (an EGL implementation that 
> uses Wayland), not "Wayland atop EGL" (a Wayland compositor that uses 
> EGL to do all it's work). That is mostly what confused me.

Yes, a Wayland client using EGL to render with GL and post its buffers
to a Wayland server. The Wayland EGL platform essentially allows to
create an EGLSurface from a Wayland surface, and then one can call
eglSwapBuffers to post it.

> The EGL spec says that after eglSwapBuffers returns the former back 
> buffer is not being used for display and can be drawn on. Unless an 
> otherwise unnecessary copy is done, the only way to do this in Wayland 
> is to do an attach and then wait for Wayland to respond that the old 
> buffer is not attached any more. This is the blocking, correct?

Yes, I think that is the blocking referred to here.

> This is less than ideal. If a thread wants to update two EGL surfaces, 
> it cannot start the swap on the second one until the first one finishes 
> swapping, and can't draw anything in the second one while waiting for 
> the swap of the first. Therefore I would expect a non-EGL workaround to 
> be added that allows this, perhaps a client can call wl_egl_start_swap() 
> and later wl_egl_wait_for_swap(). eglSwapBuffers would just do these two 
> in a row.

There was some talk about an alternative implementation: to let
eglSwapBuffers never block, instead block when a rendering operation is
about to use a buffer that should have already been made available by
swapBuffers, but didn't actually happen yet. The DRM architecture
should allow this. I wonder if this idea was forgotten or deemed to
have problems...

Of course, that only solves the single thread, multiple surfaces
serialisation case.

Related to the above idea, the "buffer is now ready to be drawn to
again" event could be delivered out-of-band, i.e. not in Wayland
protocol stream, but e.g. via DRM. This is alternative to the DRM
automatically blocking the client process on a rendering command.

But all this still leaves the problem: eglSwapBuffers must send a
Wayland attach request, and it may happen in a different thread than
where the wl_display is being used. I believe this is the primary
reason for "EGL makes [the old design] impossible".

That's just my view of the (some?) problem(s). I don't think I've heard
of all the issues, and didn't look at the proposed patch, sorry.

In any case, an EGL call, like eglSwapBuffers in Mesa AFAIK still does,
dispatching all kinds of Wayland events is a bug.


Thanks,
pq