Hi Jason, I use it in Broadcom EGL and Vulkan WSI implementations and "It Just Works (TM)". I've asked to include the opaque EGL buffers as a valid type of buffer that can be explicitly synchronised and this change was merged too, quite some time ago. Weston 6.0.0 definitely has it, not sure about earlier version.
Cheers, Tomek On Tue, 4 Feb 2020 at 05:27, Jason Ekstrand <ja...@jlekstrand.net> wrote: > Sorry to drag up ancient threads, but what's the status of this? I see > rumors that it's in Weston. Is it stable? Is it implemented anywhere > else? It'd be great, for the sake of Vulkan, if we could get this stable > and everywhere. > > --Jason > > On Mon, Dec 17, 2018 at 11:25 AM Tomek Bury <tomek.b...@gmail.com> wrote: > >> Thanks! That looks better than my patch. >> >> On Mon, 17 Dec 2018 at 15:37, Alexandros Frantzis < >> alexandros.frant...@collabora.com> wrote: >> >>> On Monday, December 17, 2018 12:44 GMT, Tomek Bury <tomek.b...@gmail.com> >>> wrote: >>> > On Wed, 28 Nov 2018 at 14:35, Tomek Bury <tomek.b...@gmail.com> wrote: >>> > > Hi Pekka, >>> > > >>> > > > I suppose the compositor-side copy of buffers you mentioned is for >>> the >>> > > > lack of release fences, not acquire fences? >>> > > Yes, the lack of release fences is the very reason for the copy. I >>> could >>> > > cook something up for the acquire fence, but that wouldn't >>> synchronise the >>> > > buffer access anyway. The only way I can be sure the client doesn't >>> > > overwrite a buffer still in use by the GPU was to texture from a >>> copy and >>> > > let the compositor release the original without waiting for the GPU >>> and >>> > > without a fence. >>> > > >>> > > Cheers, >>> > > Tomek >>> > > >>> > Hi Pekka, Alexandros, >>> > >>> > Here's a patch containing all I had to do in order to test the explicit >>> > sync support Alexandros has implemented in Weston. >>> > >>> > Thanks, >>> > Tomek >>> >>> Hi Tomek, >>> >>> I have now updated the weston explicit-sync gitlab MR [1] to support, >>> among other things, minor version 2 of the protocol. Instead of >>> completely removing the checks, I have updated them to check for and >>> accept all non-SHM buffers, which is adequate for current needs. There >>> are other ways to deal with these checks if we think we need a more >>> versatile approach (e.g., asking the renderer to tell us if it support >>> fences >>> for a particular buffer). Please see the MR comments for more info and >>> discussion. >>> >>> Thanks, >>> Alexandros >>> >>> [1] https://gitlab.freedesktop.org/wayland/weston/merge_requests/32 >>> >>> _______________________________________________ >> wayland-devel mailing list >> wayland-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/wayland-devel >> >
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
