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