[Development] QtWayland synchronisation between GL and compositor

[Gunnar Sletta]

Hi Tomek,

You're not really missing anything :)

In the case of an asynchronous swapBuffers, there is a slight chance the wl_buffer release on the next draw pass will be premature, because there is nothing the qtwayland module that catches when the GPU is done with a frame. 

In stack that I'm familiar with, the Sailfish OS compositor, we've tackled this either by making sure the GPU completes the copy into its framebuffer during swap (which is the case for the Jolla Phone), or by sitting on the buffer until the GPU is actually done with it and only sending wl_release back to the client once the GPU is actually done (which is the case for the cancelled Jolla Tablet). If the compositor is a QtQuick compositor running on the render thread, sitting on the wl_release for that extra time make for an especially fun coding exercise :)

On the client side, the EGL library will make sure that the client is blocked when rendering kicks in (some time after the first GL draw call, but typically during the client's eglSwapBuffers) if there are no wl_buffers available for rendering, so there is no writes to buffers currently in use on the compositor side there. 

cheers,
Gunnar


> On 26 May 2016, at 11:45, Tomek Bury <tomek.bury at gmail.com> wrote:
> 
> Hi all,
> 
> Is there any mechanism that that synchronises wl_buffer release by the compositor to the GL driver's pipeline?
> 
> I can't figure out how this synchronisation is supposed to work. My initial thought was that the sequence of actions will be something like this. The client sends a new frame to the compositor, in response the compositor would:
> 
> * create EGL image from wl_buffer
> * create GL texture from the EGL image
> * draw client's buffer somewhere 
> * CREATE SYNC OBJECT
> * destroy texture
> * destry image
> * swap buffers
> 
> and perhaps in a different thread:
> * WAIT ON SYNC OBJECT
> * release wl_buffer back to the client
> 
> But I can't see any sync objects created or waited on. 
> 
> Simply depending on eglSwapBuffers() can't work, especially for a tripple-buffered compositor. Let's say GL driver uses buffers called A, B and C in the compositor process. Buffer A is visible now, B is already finished in terms of GL API calls and the compositor has just finished issuing draw commands to buffer C and calls eglSwapBuffers(). In response the GL/EGL driver has to wait until hardware completes all drawing associated with buffer B, hide A ,show B and start using A as a new back buffer. Buffer C can still be in the making.
> 
> Releasing client's wl_buffer only because eglSwapBuffers() was called by the compositor will create a race between compositor's GL driver completing frame C in a background and client's GL driver reusing it's buffer. What am I missing?
> 
> Cheers,
> Tomek
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development