On Tue, 27 Nov 2018 10:56:39 +0000 Tomek Bury <tomek.b...@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
pgpQedd2R3H7y.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel