2016-06-27 10:39 GMT+02:00 Pekka Paalanen <[email protected]>: > On Sat, 25 Jun 2016 21:20:59 +0200 > Eugen Friedrich <[email protected]> wrote: > >> Von: "Eugen Friedrich" <[email protected]> >> Datum: 24.06.2016 10:59 nachm. >> Betreff: Re: How to create client in child thread >> An: "Pekka Paalanen" <[email protected]> >> 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 _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
