<div dir="ltr"><div>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.</div><div><br></div><div>--Jason<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 17, 2018 at 11:25 AM Tomek Bury <<a href="mailto:tomek.bury@gmail.com">tomek.bury@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Thanks! That looks better than my patch.</div><br><div class="gmail_quote"><div dir="ltr">On Mon, 17 Dec 2018 at 15:37, Alexandros Frantzis <<a href="mailto:alexandros.frantzis@collabora.com" target="_blank">alexandros.frantzis@collabora.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Monday, December 17, 2018 12:44 GMT, Tomek Bury <<a href="mailto:tomek.bury@gmail.com" target="_blank">tomek.bury@gmail.com</a>> wrote: <br>
> On Wed, 28 Nov 2018 at 14:35, Tomek Bury <<a href="mailto:tomek.bury@gmail.com" target="_blank">tomek.bury@gmail.com</a>> wrote:<br>
> > Hi Pekka,<br>
> ><br>
> > > I suppose the compositor-side copy of buffers you mentioned is for the<br>
> > > lack of release fences, not acquire fences?<br>
> > Yes, the lack of release fences is the very reason for the copy. I could<br>
> > cook something up for the acquire fence, but that wouldn't synchronise the<br>
> > buffer access anyway. The only way I can be sure the client doesn't<br>
> > overwrite a buffer still in use by the GPU was to texture from a copy and<br>
> > let the compositor release the original without waiting for the GPU and<br>
> > without a fence.<br>
> ><br>
> > Cheers,<br>
> > Tomek<br>
> ><br>
> Hi Pekka, Alexandros,<br>
> <br>
> Here's a patch containing all I had to do in order to test the explicit<br>
> sync support Alexandros has implemented in Weston.<br>
> <br>
> Thanks,<br>
> Tomek<br>
<br>
Hi Tomek,<br>
<br>
I have now updated the weston explicit-sync gitlab MR [1] to support,<br>
among other things, minor version 2 of the protocol. Instead of<br>
completely removing the checks, I have updated them to check for and<br>
accept all non-SHM buffers, which is adequate for current needs. There<br>
are other ways to deal with these checks if we think we need a more<br>
versatile approach (e.g., asking the renderer to tell us if it support fences<br>
for a particular buffer). Please see the MR comments for more info and<br>
discussion.<br>
<br>
Thanks,<br>
Alexandros<br>
<br>
[1] <a href="https://gitlab.freedesktop.org/wayland/weston/merge_requests/32" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/wayland/weston/merge_requests/32</a><br>
<br>
</blockquote></div>
</div>
_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
</blockquote></div>