Von: "Eugen Friedrich" <<a href="mailto:friedrix@gmail.com">friedrix@gmail.com</a>> Datum: 24.06.2016 10:59 nachm. Betreff: Re: How to create client in child thread An: "Pekka Paalanen" <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> 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. > > On Thu, 16 Jun 2016 09:54:54 +0800 (CST) > > 袁嘉伟 <<a href="mailto:yuanjw1025@163.com">yuanjw1025@163.com</a>> wrote: > > > >> Yes, I want to achieve that drawing the client from a thread but not > >> the main thread. Before I have tested that creating display and > >> drawing surface from main thread, and I try to call the > >> functions(xdg_surface_xxxx) of wayland to control the client from > >> child thread, but failed. The reason is function blocked. Through > >> referring some websites, I thought the drawing and control might be > >> in the same thread. I continue to test that drawing the client in > >> child thread, but it still block in function eglGetDisplay(&display). > >> I don't know why. Because of HMI framework, I must call the function > >> to control the client in child thread. My test code is sample-egl.c. > >> Thanks. > >> > >> > >> > >> > >> 在 2016-06-16 04:24:19，"Benoit Gschwind" <<a href="mailto:gschwind@gnu-log.net">gschwind@gnu-log.net</a>> > >> 写道： > >> >Hello, > >> > > >> >The reply from Pekka is about compositor using a client to make the > >> >rendering, but I not sure this is what you asking for. > >> > > >> >Are you talking about building a compositor ? It look like you are > >> >making a wayland client that try to delegate the drawing to a > >> >thread. Is it what you want to do ? > >> > > >> >Best regards > >> > > > > > Oh indeed, sorry for my confusion. First, some general background > > information: > > > > 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? 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. 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. > > 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 > > <a href="https://bugs.freedesktop.org/show_bug.cgi?id=91769">https://bugs.freedesktop.org/show_bug.cgi?id=91769</a> , > > particularly <a href="https://bugs.freedesktop.org/show_bug.cgi?id=91273">https://bugs.freedesktop.org/show_bug.cgi?id=91273</a> which > > also requires a fix in the EGL implementation (for Mesa, see > > <a href="https://lists.freedesktop.org/archives/mesa-dev/2016-May/115617.html">https://lists.freedesktop.org/archives/mesa-dev/2016-May/115617.html</a> > > 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 > > > > You say you are blocked in eglGetDisplay(). I have not heard of that > > before. Which EGL implementation is that? If it is not Mesa, and you > > cannot reproduce the problem with Mesa, then I suspect you have to > > contact your EGL vendor about it. > > > > > > Thanks, > > pq > > > > _______________________________________________ > > wayland-devel mailing list > > <a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a> > > <a href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> > >