Hi Gunnar, Thanks for your replay.
I've spend quite some time on #wayland IRC channel yesterday discussing this matter. It turns out that the compositor implementation assumes implicit synchronisation. The "submit" operation assumes that whatever dependencies were present on the client side are carried over to the server side. This way there's no need for an explicit CPU-GPU synchronisation on either side. Of course in order to do that one needs some sort of cross-process synchronisation either implicitly provided by the driver or via some sort of sync objects that can safely travel between client and server hidden in the Wayland platform implementation. The "release" operation is trickier and it's based on a specific implementation detail. Here's the wording from the spec ( https://www.khronos.org/registry/gles/extensions/OES/OES_EGL_image_external.txt ): Sampling an external texture which has been modified since it was bound will return samples which may correspond to image values either before, during, or after the modification. Binding (or re-binding if already bound) an external texture by calling BindTexture after all modifications are complete guarantees that sampling done in future draw calls will return values corresponding to the values in the buffer at or after the time that BindTexture is called. Now, spec says "at or after" while Weston (and QtWayland as far as I can tell) assume that it's always "at" and never "after". If the driver honours that assumption it's safe to release the buffer to the client without waiting for the GL pipeline to finish drawing. Of course GL drivers are not required to honour that assumption and it's perfectly valid for the client to start updating the released buffer while compositor still uses it. The biggest problem is that there's no cross process synchronisation available in GL/EGL so the Wayland would have to take a performance hit if it wanted to be perfectly compliant with the GL spec. So technically it is a bug, but cost of fixing it is to high. The explicit synchronisation is in the works for quite some time now but don't hold your breath. Cheers, Tomek >
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
