[PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
ppaalanen at gmail.com
Wed Nov 28 14:09:03 UTC 2018
On Tue, 27 Nov 2018 18:25:04 +0200
Alexandros Frantzis <alexandros.frantzis at collabora.com> wrote:
> On Tue, Nov 27, 2018 at 05:17:40PM +0200, Alexandros Frantzis wrote:
> > On Tue, Nov 27, 2018 at 10:53:45AM +0200, Pekka Paalanen wrote:
> > > Yes, we probably should have some wording that if a client is letting
> > > something like EGL to commit the buffers, it must not attempt to use
> > > the fence extension on that wl_surface itself because EGL will probably
> > > be using the extension already.
> > >
> > > Alf?
> > Hi Pekka and Tomek,
> > I will send a patch with a proposal for the discussed wording updates to
> > the list soon (probably tomorrow).
> > I agree it's fine for the spec to be relaxed for the opaque EGL buffers.
> > As Pekka mentioned, we explicitly limited the spec to support only
> > zwp_linux_dmabuf to avoid the problem of having to deal with unsupported
> > buffer/fence combinations, and opaque EGL buffers are not likely to pose
> > problems in this regard.
> Note that this will require a v2 of this protocol since we will be
> requiring more from implementations compared to v1 (unless we can cheat
> and not bump?). The current protocol says:
It's not a backwards incompatible change, so I think there is no need
for a major bump. You can do a minor bump if you want, it would be
> "Explicit synchronization is guaranteed to be supported only for buffers
> created with any version of the wp_linux_dmabuf buffer factory."
> which upon rereading isn't clear enough about if implementations are
> required to support *only* linux_dmabuf, or if implementations need
> to support *at least* linux_dmabuf.
I think the "guaranteed" makes it "at least".
> If we don't want to commit to general opaque EGL buffer support,
> perhaps an option here would be to change this to the more clear:
> "Explicit synchronization is only guaranteed to be supported for buffers
> created with any version of the wp_linux_dmabuf buffer factory, but
> implementations are free to also support it for other buffer types."
> This allows us to stay at v1 without explicitly naming out opaque EGL
> buffers, while still allowing Weston to support opaque EGL buffers.
It would not help clients to know what they can use though. It would
leave them in the dark even after the protocol was stabilized.
The fence support for opaque EGL buffers depends on the compositor
implementation, not on EGL implementation. So it varies across
compositors even on the same platform or system.
> I guess it depends if we think the explicit sync + opaque EGL buffer
> case will be interesting enough to be used outside of environments with
> a controlled compositor and clients.
I believe it is.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the wayland-devel