In this blog post Corentin Noël, Dmitrii Osipenko, Igor Torrente, and Gert Wollny look at the latest updates around the different approaches to GFX virtualization with virglrenderer.

GFX virtualization aims at providing support for hardware accelerated 3D graphics in virtual machines. Unlike GPU-passthrough, with GFX virtualization the host and all VM guests can access the host GPU simultaneously.

Vulkan and OpenGL are supported by virglrenderer using various approaches: Venus offers virtualized support for Vulkan, OpenGL can make use of VirGL or Zink, the latter of which translates to Vulkan to be handled by Venus. These approaches have the advantage that the guest OS doesn't need to provide specific drivers for the used host hardware. Instead Mesa 3D provides the virgl and zink gallium drivers for the respective OpenGL drivers, and the Vulkan driver named virtio that is also known as Venus.

The requirements for the guest OS are that it runs a kernel that has VirtIO enabled and Mesa 3D with the respective drivers compiled in.

As an alternative, there are relatively new Virtual DRM contexts (vDRM) that expose a direct interface to the host hardware. Consequently, in this case the guest must use hardware specific GFX drivers.

Below we will discuss the different approaches and their availability in detail.

Venus

Venus can be seen as a transport layer for the Vulkan API. In this sense, it forwards Vulkan calls to the host driver and delivers the results back to the application. Forwarding of the calls can often be done with very little overhead to map between the resources as seen on the host and the guest, for example shaders are simply passed as SPIR-V binary and can be consumed directly be the host driver. As a result, Venus is a rather thin layer and often an application can reach a performance that is close to running it directly on the host. The main factor that might limit performance can usually be found in host-guest synchronization.

Currently, Venus is only available when the virtual machine manager (VMM) supports blob resources. As of now this is the case with CrosVM; support for Qemu is tagged for stable. In addition, Venus requires support for the VK_EXT_image_drm_format_modifier extension which is not available on pre-GFX9 AMD GPUs. We still have some issues issues with the NVIDIA proprietary driver (#524), which are expected to be addressed by NVIDIA in future versions of their driver. Venus is the only virglrenderer context type that runs in an isolated process on the host for hardened security and reliability, i.e. Vulkan crashing on the host won't take down the whole VMM.

Venus has been supporting all extensions required by DXVK and Zink for a considerable period of time and has already been tagged to stable in May/2023.

For the beginning of 2025, Venus supports Vulkan API versions up to v1.3.

VirGL

VirGL implements support for OpenGL. Unlike Venus, it uses an approach where the guest emits command and resource handling calls that need considerable extra work to be run on the host. For example, shaders are compiled and linked in the guest, emitted to the host in an intermediate format (TGSI), and then translated to GLSL so that the host driver has to compile and link the shaders again. In essence VirGL requires most work to be done twice: once in the guest and once on the host, significantly impacting performance. In addition, the guest-host communication is serialized across all guest OpenGL applications, so that the host receives just one command stream that is decoded in just one thread on the host. Because of this, running more than one OpenGL application in the guest results in a significantly lower performance for all OpenGL applications involved.

There are however some benefits. Given it's architecture, certain features that are not supported by the host driver can be emulated resulting in a guest that is able to run most OpenGL applications, even though the host may only support GLES.

In its current state, VirGL supports OpenGL 4.3 and GLES 3.2 in Qemu when the host supports it or if the host supports GLES 3.2. In the latter case a few rarely used features of OpenGL will not work correctly though. VirGL can support up to OpenGL 4.6, but OpenGL 4.4 and above require that the VMM supports blob resources, so the same limitations as with Venus apply. In summary, VirGL is basically feature complete. The current focus is only on fixing bugs, and here we put a special focus on using fuzzing to uncover remaining security issues.

Zink/Venus as alternative to VirGL

As an alternative to VirGL one can use Zink+Venus to provide support for OpenGL in the VM guest. This has the advantage that some limitations of VirGL are no longer relevant: For instance running multiple OpenGL applications at the same time without severe loss of performance becomes possible. Currently, work is ongoing to get Zink to work at least as well as VirGL when running just one OpenGL application. As of now this is already the case for many work loads, but some bugs still need fixing, and in some cases especially the Zink-Venus interaction leads to severe performance degradation. Fixing these issues continues apace, especially when running Zink+Venus with Sommelier. There are still some issues when running Weston on Zink+Venus.

Virtual DRM context

Virtual DRM context (vDRM) is a mediated method of Linux graphics virtualization which operates on the level of the Linux kernel driver UAPI, making a host GPU appear in a guest like a native one.

In comparison to VirGL and Venus, the main advantages of mediating lower level graphics APIs are better performance, lower resource usage, and lower code complexity. These all come with a price of lacking portability: A new vDRM driver needs to be created for every GPU driver and supporting new GPU cards may require updating vDRM drivers. In practice, this disadvantage is minor because the number of GPU vendors is limited.

Since vDRM is a much thinner layer compared to VirGL and Venus for the majority of applications it is able to achieve native GPU performance, where VirGL and Venus may struggle to overcome expensive host/guest synchronizations mandated by OpenGL and Vulkan APIs. The main performance obstacle observed for vDRM is the performance of guest memory management, in particular mapping GPU memory in a VM takes much more time compared to host native. While vDRM utilizes the same optimization tricks as VirGL and Venus to overcome memory management overhead, certain applications may still see a loss in performance.

As of today, at the beginning of 2025, vDRM is partially supported by crosvm. With crosvm you'll be using Sommelier because KMS display isn't yet supported for vDRM. The work on adding vDRM support to Qemu is in progress too.

Known problems with regards to supporting blob memory

Because of the way KVM and TTM interact within the Linux kernel, blob support is not supported by all drivers. The latest patches that resolve the issue can be found in the upcoming Linux kernel version 6.13.

Summary

With VirGL, Venus, and vDRM, virglrenderer offers three approaches to obtain access to accelerated GFX in a virtual machine. VirGL offers only OpenGL support and has its performance limitations, especially if one wants to run multiple concurrent OpenGL applications. Nevertheless, it has the advantage that it only requires host support for OpenGL, enabling it to run on older hardware that doesn't support Vulkan. Venus on the other hand provides all the advantages of Vulkan and OpenGL support (via Zink), but it requires host support for Vulkan, and certain aspects like synchronization still need some work to become fully stable.

Neither VirGL nor Venus require a guest driver that is aware of the specific host hardware, they simply query the host features by using the public OpenGL or Vulkan interface of the host driver, and offer a corresponding level of support in the guest.

Virtual DRM context (vDRM) on the other hand requires a driver in the guest OS that is tailored to the host hardware. While work on vDRM is still in progress it is expected to offer the best performance.

Conclusion

With this article we only gave a birds-eye view on the possibilities of GFX virtualization with virglrenderer. Once the missing pieces for Venus and vDRM are about to be merged we will follow up with an article on how to run these three variants using Qemu and CrosVM, and also provide and discuss some performance numbers.