<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#c5">Comment # 5</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#c2">comment #2</a>) > As far as I can tell several 3D drivers put read-write synchronisation in > user space so it works across contexts within one process but not across > processes. Nokia had this problem, Boroadcom driver is another example. Nokia didn't have this problem in PowerVR; PVR has had kernel-side sync objects, portable between contexts, for a long time. And the ability to use them as fences for submission. > It's not impossible to implement but the only possible implementation that > doesn't involve blocking CPU in the compositor I can think of is rather > ugly: create a parallel synchronisation mechanism and deal with 2 of them: > regular one in user pace for most things and Wayland special in kernel with > an extra kernel round-trip for each read from or write to wl_buffer. I'm not sure what you mean here. If you can build these things into the kernel, then why would you not just build implicit fencing in the first place? Conceptually it's no leap at all from what Android and ChromeOS already require today.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>