With Vulkan 1.1 It's Technically Possible To Write A Pure Wayland Compositor
Going back two years has been feature request #294 about Wayland compositor-side extensions for Vulkan for basically trying to write a Vulkan compositor back-end. That feature request was closed today as with Vulkan 1.1 it's technically possible, but we have yet to see anyone attempt this feat.
James Jones of NVIDIA's driver team who has also been involved in the company's EGLStreams and Unix device memory allocator proposal wrote the following on that feature request today (:
The Vulkan external objects extensions (external memory, external semaphores, and external fences) are now part of the Vulkan 1.1 specification. They enable the implementation of all the Vulkan WSI mechanisms/extensions on top of core Vulkan + the OS-specific parts of external objects (E.g., VK_KHR_external_memory_fd). In other words, if someone were so inclined, they could write a complete vendor-agnostic wayland compositor and wayland vulkan WSI client on top of nothing but Vulkan 1.1 APIs. VK_KHR_display support would be required to actually get such a wayland compositor to display on a monitor/output. The WSI integration could be implemented as a Vulkan implicit layer, such that its presence would be invisible to applications and look just like any other Vulkan wayland WSI implementation. Therefore, the Vulkan functionality requested when this issue was filed is complete, so I'll mark this issue closed.
My work to design and prototype new allocation mechanisms for Linux and other POSIX or POSIX-like systems (code hosted at https://github.com/cubanismo/allocator as pointed out above) is outside the scope of Vulkan and this issue, though it could prove useful to a wayland compositor making use of Vulkan for graphics and/or display. Further work by others to better integrate the Vulkan external memory mechanisms with native Linux constructs like dma-bufs and DRM format modifiers is ongoing, and much of the progress on that can be tracked publicly on the dri-devel or mesa-dev mailing lists on freedesktop.org.
Longtime open-source graphics driver contributor and Collabora graphics lead, Daniel Stone, then chimed in with some additions:
On the backend, it should be possible to use GBM as a buffer allocators as an alternative to VK_KHR_display, as an easier transition path for compositors using EGL/GBM/KMS. (Or, if running nested, you can of course continue to use the Wayland/X11 WSI swapchain extensions.)
On the compositor side, you'll want to be implementing the zwp_linux_dmabuf_v1 Wayland interface, using this new Vulkan extension to import the resulting buffers to texture from them. For Mesa-based drivers, this will allow clients using the Wayland WSI swapchain extensions to work; for the NVIDIA proprietary drivers, you would need to support the EGLStreams paths.
The latest work on modifiers is @chadversary's VK_EXT_image_drm_format_modifier, which allows advertisement and import of buffers with modifiers, similar to EGL_EXT_image_dma_buf_import_modifiers.
There is a proposed zwp_linux_explicit_synchronization_v1 Wayland extension which allows exchanging dma-fence FDs (which you could export from the client rendering signal semaphore, and import to use as a wait semaphore for compositor texturing), but the implementation for this has not yet been merged.
It will be interesting to see if/when someone tries writing a pure Wayland compositor using the modern Vulkan extensions.
But for those hoping it would magically clear up the confusing state of driver support for Wayland compositors with GBM vs. EGLStreams, etc, that's unlikely to get rectified anytime soon. Writing this Vulkan-powered Wayland compositor would be great for the past few generations of GPU hardware, but still wouldn't work well for pre-Broadwell, pre-Kepler, pre-GCN graphics processors lacking Vulkan... Meaning you would still need at least a secondary code-path for the existing Wayland compositor support. Those that have been against supporting EGLStreams in their Wayland compositors have based their arguments against it on needing to support multiple code paths: until Vulkan-enabled GPUs can be assumed everywhere (still several years out), they would still be in the situation of having to support multiple back-ends. Anyhow, would certainly be interesting to see some Wayland Vulkan compositor experiments as these related extensions materialize and mature.
54 Comments
