[PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1

[Tomek Bury]

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.

> 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.

Cheers,
Tomek





On Tue, 27 Nov 2018 at 13:10, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Tue, 27 Nov 2018 10:56:39 +0000
> Tomek Bury <tomek.bury at gmail.com> wrote:
>
> > Hi Pekka,
> >
> > > I suppose that applies to the opaque EGL buffers only?
> > Sort of. As far as I understand it, the divide is between wl_surface
> > managed by EGL/WSI vs. wl_surface managed directly by the client
> > application. For EGL case the wl_surface managed by EGL would be set-up
> > more or less like this:
> > struct wl_egl_window *window = wl_egl_window_create(surface, w, h);
> > EGLDisplay dpy = eglGetPlatformDisplay(EGL_PLATFORM_WAYLAND_EXT, ...);
> > EGLSurface surface = eglCreatePlatformWindowSurface(dpy, config, window);
> > With this setup EGL becomes responsible for managing the swapchain
> buffers,
> > keeping up with window resizes, sending wl_buffers to compositor when
> > client app calls eglSwapBuffers() etc. This is how weston-simple-egl
> works.
>
> Hi Tomek,
>
> that is how most apps work, but nothing is forbidding a client from
> switching.
>
> 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.
>
> I cannot point to any example of such client, but it is not forbidden
> anywhere. If apps start supporting GPU hotplug, then I imagine such
> switching would become useful.
>
> > > Otherwise, a client could use e.g. EGL in a different way to get
> dmabuf,
> > > send those manually to the compositor and set up fences manually as
> > > well. weston-simple-dmabuf-egl in the MR is one variant of that. Of
> > > course, it depends on the EGL stack supporting dmabuf to begin with, so
> > > if yours doesn't then it's not possible.
> > Yes, exactly. This is the example where the application manages the
> Wayland
> > window directly and the EGL driver is not involved. EGL is only used to
> set
> > up rendering into an off-screen buffer(s) of some description.
> >
> > In both cases the compositor receives a wl_buffer and has to figure out
> how
> > to render the contents of such buffer. In both cases the wl_buffer could
> > encapsulate dma-buf and the compositor wouldn't be able to tell whether
> it
> > came directly from application (weston-simple-dmabuf-egl) or from the EGL
> > driver (weston-simple-egl). in fact the Waylad client could choose
> dma-buf,
> > prime, flink, shm, something else, regardless of how the wl_surface is
> > managed, whether it's done directly by the application, by the EGL or
> > Vulkan driver. And some of those wl_buffer types will be known to the
> > compositor, some to the 3D driver and perhaps some to both. At least
> that's
> > my understanding.
>
> Sure. I'm not sure how that is relevant though, or what we are debating
> about.
>
> A compositor cares about how it will access a buffer: is the access
> off-loaded somewhere which can or cannot import acquire fences, or does it
> need to read the buffer with CPU directly. I would like to avoid
> requiring fence support from compositors when they do not have a way to
> off-load the fence wait.
>
> Is it possible to have some variant of glTexImage2D wait for an EGLSync
> before it actually reads from the source? If there is, then I'll
> reconsider about the buffer type requirements.
>
> It is a happy coincidence, that in the cases where a compositor does
> not have a way to off-load a fence wait, it would also be very hard for
> a client to arrange a fence to be waited on in the first place. But,
> the protocol specification cannot rely on such practicalities, instead
> it needs to set clear expectations on what should work.
>
> Saying, that if a compositor supports the fence extension and opaque EGL
> buffers then it needs to support opaque EGL buffers with acquire
> fences, seems like a good idea. Neither condition needs to be written
> out explicitly: it is the fence extension spec and a compositor either
> supports all of it or none of it; whether it is possible to have opaque
> EGL buffers depends on the compositor initializing the support which is
> well discoverable to clients. 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.
>
>
> Thanks,
> pq
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20181127/1dd70049/attachment-0001.html>