EGL Wayland platform specifications and conformance (Re: How to create client in child thread, egl behavior)

[Eugen Friedrich]

2016-06-27 10:39 GMT+02:00 Pekka Paalanen <ppaalanen at gmail.com>:
> On Sat, 25 Jun 2016 21:20:59 +0200
> Eugen Friedrich <friedrix at gmail.com> wrote:
>
>> Von: "Eugen Friedrich" <friedrix at gmail.com>
>> Datum: 24.06.2016 10:59 nachm.
>> Betreff: Re: How to create client in child thread
>> An: "Pekka Paalanen" <ppaalanen at gmail.com>
>> Cc:
>>
>> Hello Pekka,
>> you mentions some interesting points for me in this email not really
>> related to the original topic,
>> therefore I'm just jumping in  between.
>
> Hi Eugen!
>
>
>> > > eglSwapBuffers() counts as a Wayland protocol call, because it is
>> > > guaranteed to call wl_surface.commit before it returns and with the
>>
>> totally agree with that, but is there any official specification for this?
>
> Unfortunately no. It has been a dream for a good while, and one idea
> was that it might be possible to write the text into
> EGL_KHR_platform_wayland.
>
> Even better would be to write a EGL Wayland platform conformance test
> suite. I think it will need to excercise both server- and client-side
> at the same time, so that it can trigger the possible races, corner
> cases and detect bad shortcuts like calling wl_surface.commit from
> another thread as reliably as possible. But that would be a huge
> undertaking.
>
>> Argument: because it is implemented in Mesa is not always accepted by
>> suppliers. Also if compositor and clients use different hardware for
>> rendering synchronization might become difficult.
>
> Sync is a two-fold problem. Certainly EGL Wayland platform spec should
> say something about it, even if just for the same-device case. Syncing
> between different devices is only emerging on the FOSS side. There is a
> lot of work already done in the kernel, but we also need a lot of work
> in other places. I am very much looking forward to explicit fencing.

I see, wayland EGL is a special one and would be really good to define
this special behavior somewhere,
but it is how it is.
Thanks a lot for your open opinion!
>
>> I already know two different EGL providers where wl_surface.commit is
>> not called during eglSwapBuffer execution, there is a thread inside
>> the EGL which is doing this.
>
> Yes, I have heard of that, it is horribly broken. You can quote me on
> that, in lack of any better references.

thanks :-)
>
> Applications *must* be able to rely on eglSwapBuffers() issuing a
> wl_surface.commit *before* it returns, so that the surface state
> submission can be reliable.
>
> That can cause performance issues when you do not have the implicit
> fencing we have with FOSS drivers for the same-device case, we know
> that. The proper fix will be found through the work on fences.
>
>> > > newly rendered buffer attached, and it will also wait for
>> > > wl_buffer.release events if necessary, and by default it also waits for
>> > > wl_surface.frame callbacks to return.
>> > >
>> > > Here is what I wrote about EGL elsewhere:
>> > >
>> > >         eglSwapBuffers will be waiting for the previous eglSwapBuffers'
>> > >         frame callback and only if it has not arrived already for the
>> > >         particular surface. If you call eglSwapBuffers as a response to
>> > >         receiving your own copy of the frame callback or later,
>> > >         eglSwapBuffers will never block.
>> > >
>> > >         To be more precise, wait for the frame callback happens on the
>> > >         eglSwapBuffers *after* the current one as I explained above,
>> > >         and waits for wl_buffer.releases happen at the first draw call
>> > >         that would need a buffer to draw into if necessary.
>> > >
>> > >         Those are the two orthogonal throttling mechanisms in Mesa.
>> > >         Setting swap interval to 0 will prevent waits for the frame
>> > >         callbacks, but not for buffer releases, because Mesa does not
>> > >         want to potentially allocate an unlimited number of buffers in
>> > >         case the server is slow to send out releases (which would imply
>> > >         your whole system is already hosed anyway, so putting even more
>> > >         pressure to it would only make things worse).
>> > >
>> > > The above describes the expected behaviour of EGL. Bugs, which we know
>> > > to be around, are another matter.
>> > >
>> > > Do note, that I am only talking about Mesa and what a proper EGL
>> > > implementation would do. If you are using any properietary EGL
>> > > implementation, especially Vivante, you might be in trouble.
>> > >
>> > > Other things you must take care of are:
>> > >
>> > > - every thread where you want Wayland events dispatched must have its
>> > >   own wl_event_queue (Mesa EGL creates one for itself)
>> > >
>> > > - you must use the wl_display_prepare_read() API of libwayland-client
>> > >   in all callers of libwayland-client properly
>> > >
>> > > - Pay attention to all bugs linked from
>> > >   https://bugs.freedesktop.org/show_bug.cgi?id=91769 ,
>> > >   particularly https://bugs.freedesktop.org/show_bug.cgi?id=91273 which
>> > >   also requires a fix in the EGL implementation (for Mesa, see
>> > >   https://lists.freedesktop.org/archives/mesa-dev/2016-May/115617.html
>> > >   for a patch that does not seem to have been even merged yet).
>> > >
>> > > In general, Wayland functions are *not* meant for controlling things
>> > > across thread boundaries. It is safe to send requests from multiple
>> > > threads, but you are still responsible for ordering them correctly
>> > > yourself in cases where the order matters.
>> > >
>> > > If this gives you the impression that using threads with EGL/Wayland in
>> > > particular is rare and not really tested, you are right. I do not know
>> > > of any good code examples, maybe others have some?
>>
>> don't have an example by hand but I think with wayland 1.11 there is a
>> proper way to implement thread save handling, right?
>> important points are already mentioned above only one to add:
>>       - use proxy wrappers for creation of wayland objects
>
> We have thought we got the thread-safeness right several times, until
> someone found one more case that explodes painfully.
>
> I hope for the best, but will not be surprised if there are still some
> corner cases left.
>
>
> Thanks,
> pq