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
