[PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1

[Pekka Paalanen]

On Tue, 27 Nov 2018 14:57:07 +0000
Tomek Bury <tomek.bury at gmail.com> wrote:

> Hi Pekka,
> 
> I'm just trying to figure out how to use this extension in a driver.
> Without this extension the only option I have is to take a copy if each
> wl_buffer on the compositor-side. I can't really do implicit sync so I'm
> really happy with anything that allows for explicit sync.

Ah, ok. So for both acquire and release fences:

In your client-side implementation of EGL or Vulkan, in the case where
you, the implementation, will be calling wl_surface.attach and
wl_surface.commit, you will be the exclusive user of the explicit sync
extension on that wl_surface. Go wild. :-)

If the sync extension is not available from the compositor, then you
have to do without on the client-side.

In the server-side implementation, you don't need to do anything. The
compositor will implement the explicit sync protocol and translate it
into EGL etc. calls.

I suppose in the server-side implementation you *cannot* do anything
unless you can infer whether the compositor is actually supporting the
explicit sync extension or not.

> > Is it possible to have some variant of glTexImage2D wait for an EGLSync
> > before it actually reads from the source?  
> I don't think so. The glTexImage2D mustn't hold onto any client pointers.
> GLES3 buffers require mmap and CPU copy. Pixmaps are unsupported so EGL
> images are the only remaining thing I can think of.
> 
> >  It would be enough for the fence spec to
> > define what "opaque EGL buffer" is and then say that they also work in
> > addition to zwp_linux_dmabuf buffers.  
> Yup, that works for me.
> 
> > If a client wants to, it could start with wl_shm and CPU-rendered
> > content, then switch to EGL managed surface, then shut down EGL and
> > switch back to wl_shm all on the very same wl_surface, for example.  
> Hmmm, perhaps the set_acquire_fence() should be a buffer operation, not a
> surface operation then? What you wrote means to me that the compositor
> knows of every buffer the client created but doesn't know which buffer the
> client is going to attach next. The earliest moment the compositor learns
> about the buffer for the next frame is when the attach request reaches the
> compositor. And that would be most likely after the attach/damage/commit
> gets flushed at the end of frame by the client. But that's a battle for
> another day.

Correct, the compositor cannot know which buffer a client might attach
to which surface at any time. There is absolutely no connection between
which buffer goes with which surface, there has never been, and from
protocol perspective clients could use the same buffer on multiple
surfaces too.

For technical reasons, we cannot add any wl_buffer requests or events.
It would have to be done with another interface that takes the
wl_buffer as an argument. I guess that would be possible, but I'm not
sure what the difference would be.

Your EGL implementation cannot expose the same interface as the
compositor does for dmabufs. So you would have buffer-type specific
interfaces for adding acquire fences. Maybe that's not actually a bad
idea, given that the acquire fences are so closely related to buffer
types. It would also allow to split the release event and fence into
their own extension, to be shared across all buffer types including
wl_shm. OTOH, it's more typing to implement.

If we did the buffer-type specific explicit sync interfaces design,
then a compositor itself would implement set_acquire_fence for dmabufs,
and a compositor-side EGL implementation could implement
set_acquire_fence for opaque EGL buffers which would be proprietary to
the EGL implementation, but that is ok because the client-side of the
same is too.

In fact, you could have implemented an explicit sync extension for
acquire fences inside your EGL implementation since day one. It is just
the release fence side which probably wouldn't work out too well as
hidden inside EGL.

I suppose the compositor-side copy of buffers you mentioned is for the
lack of release fences, not acquire fences?


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20181128/107abe98/attachment.sig>