GNOME Aims To Get Mutter-Wayland Running With LLVMpipe

There's a set of new Mesa patches for turning Mesa's swrast driver into supporting DRI2 with GBM/DRM support in order to support running GNOME's Mutter-Wayland compositor on a software-based graphics stack within virtual machines.

GNOME's Mutter-Wayland compositor requires EGL/KMS rendering back-end support and this currently isn't supported by software-based drivers that aren't backed by an actual GPU with hardware acceleration. However, developers are working to allow the swrast driver and LLVMpipe to work with this back-end rather than adding any FBdev/Pixman support to Mutter-Wayland. The primary use-case is to get Mutter-Wayland running in virtual machines where there is no accelerated GPU driver with DRM/KMS support (i.e. mainly outside of VMware's VMWgfx world).

Besides being useful for those using GNOME Boxes or Virt-Manager for running a GNOME Linux distribution with KVM or Xen, this work is mostly being tackled to allow for testing of Mutter-Wayland inside a VM. There's the GNOME Continuous project as a functional research effort for high-speed, integration testing of the GNOME stack and it uses VMs with OpenEmbedded inside virt-manager and gnome-boxes.

A GNOME bug report opened by Matthias Clasen confirms interest in having a way to test Wayland sessions to avoid Wayland support regressions within GNOME, but is currently blocked by the lack of VM driver support for QXL. Giovanni Campagna commented today on the post, "After discussion with David Herrmann, qxl will support for PageFlip will come, and we have fallbacks in cogl anyway. What is missing is mesa support."

Giovanni sent out a set of two patches today for turning swrast into DRI2 drivers. "Some time ago I sent patches to enable the swrast driver on GBM/DRM, and I did them in the dumbest way possible (that is, having GBM implement the dri-swrast interface), to make sure it would work without kernel support. This patch series is a little smarter, in that it creates more than one KMS buffer and has llvmpipe render directly into the KMS buffer, so we don't need to copy from the back to the shadow (before the kernel copies from the shadow to the front)." LLVMpipe rendering directly into a KMS buffer should also yield a small performance win compared to the current code.

We'll see soon if this Mesa code gets approved by upstream developers and picked up for improving the Mutter-Wayland experience within VMs.