How to create client in child thread, egl behavior

Sat Jun 25 19:20:59 UTC 2016

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.
> > On Thu, 16 Jun 2016 09:54:54 +0800 (CST)
> > 袁嘉伟 <yuanjw1025 at 163.com> 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" <gschwind at gnu-log.net>
> >> 写道：
> >> >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
> >   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

> >
> > 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
> > wayland-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160625/b38ce4f7/attachment.html>