[PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1

[Jason Ekstrand]

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.bury at gmail.com> wrote:

> Thanks! That looks better than my patch.
>
> On Mon, 17 Dec 2018 at 15:37, Alexandros Frantzis <
> alexandros.frantzis at collabora.com> wrote:
>
>> On Monday, December 17, 2018 12:44 GMT, Tomek Bury <tomek.bury at gmail.com>
>> wrote:
>> > On Wed, 28 Nov 2018 at 14:35, Tomek Bury <tomek.bury at 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20200203/004e9db1/attachment.htm>