[PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1

[Pekka Paalanen]

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 --------------
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/20181127/361aec99/attachment.sig>