If you are following the Linux graphics development it should be no news to you that MESA 17.2 and Weston 3.0 have been released in the last weeks. While those carry the usual improvements and bugfixes for a lot of graphics hardware, they are a pretty important milestone for the Etnaviv project: we finally have fully working Wayland support!

While Etnaviv, being just another hardware driver within MESA, inherited all common support code like GBM and the Wayland EGL platform, which got the compositor side working right with the initial merge, Wayland applications haven't worked correctly up until now. While they technically did work already, they were unusable as the window content was only a scrambled mess. The reason for this is the tiled memory layout the GPU is using for texturing and rendering. This article Gives a nice in-depth explanation for those interested in the details.

That's actually a very common thing in 3D rendering with all modern GPUs using this technique. So why didn't things work with Etnaviv? The "old" protocols for sharing graphics buffers between application and compositor/server, like DRI2 and wl_drm, did not include any way to include buffer metadata like the used tiling layout, so all the mature DRM drivers like Radeon, Nouveau and Intel have a side-channel to share this information between different processes. Those drivers are attaching the buffer metadata to the kernel side graphics buffers, which works well as long as the userspace side and kernel buffers have a direct 1:1 relationship. Modern graphics uses like Vulkan increasingly move in a direction where a kernel side buffers are sub-divided into several userspace buffers. As this means a single kernel buffer can carry buffers with differing buffer metadata the side-channel starts to breaks down.

As attaching the buffer metadata to the kernel side buffers seems to have limited value in a modern graphics stack and would increase the API between the Etnaviv kernel and userspace driver (which we would have to support until the end of time due to the Linux kernel no regressions rule), we decided against adding such a kernel-based solution for Etnaviv. Instead we decided to piggy-back on the efforts undertaken by Intel and Collabora to allow sharing the tiling information entirely in userspace. This is done through so called "modifiers", which are basically just 64bit enum values. The registry for the available modifiers is located in the kernel, which makes it possible to use them not only in the 3D stack, but also on the display side. Ben Widawsky talked about how this used for end-to-end compression in the Intel graphics stack at XDC a few days ago.

So what changed with Weston 3.0 and MESA 17.2?

Weston now implements the zwp_linux_dmabuf protocol in addition to the wl_drm protocol. This allows to share buffers between the Wayland application and the compositor using standard dma-buf file descriptors and push all sorts of metadata describing the buffer content over the Wayland protocol.

MESA uses this protocol when available to implement the buffer sharing in the Wayland EGL platform.

Most of the work to enable this in Weston and MESA common code was done by Collabora's Daniel Stone. Varad Gautam (also at Collabora) added support for the modifiers at the Gallium interface level. As part of my job at Pengutronix I helped to review the Gallium changes and added all the necessary bits to the Etnaviv driver, which makes Etnaviv the first Gallium driver to support the new way of sharing buffer metadata over the Wayland protocol.

So those changes combined provide a fully working Wayland stack on the platforms supported by the Etnaviv driver. And the best thing about that? All the driver level support is being used unchanged to enable the Android graphics stack on top of Etnaviv.