<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Wayland lacks cross-process synchronisation" href="https://bugs.freedesktop.org/show_bug.cgi?id=97353#c16">Comment # 16</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Wayland lacks cross-process synchronisation" href="https://bugs.freedesktop.org/show_bug.cgi?id=97353">bug 97353</a> from <a class="email" href="mailto:daniel@fooishbar.org" title="Daniel Stone <daniel@fooishbar.org>"> Daniel Stone</a> <pre>(In reply to Tomek Bury from <a href="show_bug.cgi?id=97353#c14">comment #14</a>) > (In reply to Daniel Stone from <a href="show_bug.cgi?id=97353#c13">comment #13</a>) > > (In reply to Kristian Høgsberg from <a href="show_bug.cgi?id=97353#c12">comment #12</a>) > > > Which compositor is this? > > QtWayland as of Qt 5.7. OK, that's demonstrably broken, and I believe on some real-world drivers as well. Regardless of whether or not it's documented, it just won't work ... > > I'd equally consider any compositor which doesn't do this to be broken. > > Weston to the best of my knowledge (and a quick check) does destroy and > > recreate. > > Again, I don't know. I didn't see anywhere such requirement or promise that > EGL image wrapping wl_buffer is guaranteed to be destroyed before buffer > release. If that was the case "release" would be a responsibility of a > platform implementation, the same way the "attach" is. To my untrained eye > wl_buffer_release() and eglImageDestroy() over 2 independent and > asynchronous channels looks like asking for trou^H^H^H^H race condition. The wl_display is one communication channel, and EGL implementations can specify their own extensions to communicate over that. wl_drm is one, mali_buffer_sharing is another; anyone could create their own extension which posted a fence event back when an EGLImage created from a wl_buffer was destroyed. This would be guaranteed to be delivered in order. > > You're very right that this should be documented better. I'm not sure if the > > Khronos specs are the best place, or a document in the Wayland repository > > itself. Can we take this bug as one request for explicit fencing support > > (being actively pursued), and another one to document the EGL platform > > requirements for both driver implementations and compositors? > > Thanks. Would you like me to create 2 dependent Mozilla tickets? Sure! (In reply to Tomek Bury from <a href="show_bug.cgi?id=97353#c15">comment #15</a>) > With regards to documenting requirements: EGL spec explicitly limits sharing > and synchronisation to a single "address space" so Wayland requirement for > cross-process synchronisation needs an extension if you want to go with > Khrons. It doesn't give you standardised cross-process primitives, but EGL platforms and winsys mostly require working across process boundaries. It's entirely legitimate to place requirements on how they operate, without having to specify an entire generic mechanism for external fencing.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>