We're hiring!

Virglrenderer and the state of virtualized virtual worlds

Gert Wollny avatar

Gert Wollny
August 28, 2019

Share this post:

With the release of virglrenderer 0.8.0, getting accelerated OpenGL within a virtual machine (VM) made a big leap forward. Since virglrenderer-0.7.0, the code base has seen ~600 commits, and by providing more than 80% of these contributions, Collabora took the lead in this development cycle.

On the technical side the work has been focusing on more conformance, and performance. One specific aim was to support hosts that support only OpenGL ES to a point that within the VM guest also OpenGL 4.3 applications can be run, an aim that was fully acheived as we can now run games like Alien Isolation (tm) within qemu on certain devices that support only OpenGL ES 3.2 and a number of extension. On the performance side, thanks to the excellent work by done by Alexandros (Collabora), and Gurchetan and Chia-I Wu (Google ChromeOS team) on buffer transfers we can now run many games at a decent speed.

Virglrenderer not only provides the means to provide hardware acceleration to VM guests. With virgl_server and the virgl/vtest mesa driver it offers also a lightweight separation of host hardware and client software that was originally only conceived for testing purposes, but may find applications of its own.

Showcasing virglrenderer


Last Elie Tournier presented our advances with virgl hardware accelerated OpenGL in a virtual machine (VM) and played a 3D game at XDC 2018, and now we can present a bit more on that front.

A general guide on how to set up Qemu with virglrenderer was already posted earlier by Robert Foss. One point to consider is that that games use the mouse in a certain ways that result in erratic mouse behaviour; disabling the emulated PS/2 mouse and using the USB mouse is the way forward. This has the disadvantage that the mouse is grabbed by the Qemu window though, and one has to manually release it (Ctrl-Alt-g).

Now, to run Qemu the following command line was used:

 qemu-system-x86_64 -enable-kvm  \
     -smp 5 -M q35 -m 8G \
     -drive format=raw,file=ubuntu-19.04.raw,if=virtio \
     -net nic,model=virtio \
     -net user,hostfwd=tcp::2222-:22 \
     -soundhw hda \
     -audiodev id=pa,driver=pa,server= \
     -vga virtio \
     -display sdl,gl=on \
     -fsdev local,id=test_dev,path=$HOME/.local/share/Steam/,security_model=none \
     -device virtio-9p-pci,fsdev=test_dev,mount_tag=test_mount

Here ubuntu-19.04.raw contains an Ubuntu 19.04 installation, but with an linux kernel updated to 5.2 because of some bug in the 5.0 kernel. Any recent Linux installation should work though.

The virtio-9p-pci devices are used to mount directories of the host file system as plan9 partitions within the virtual machine, e.g. in order to share the steam library between host and VM. Note that not all games work correctly by doing so. At least Half Life 2 didn't run properly and had to be download onto the virtual disk.

For the video shown below the virtual machine was executed on a Desktop computer running Gentoo Linux (CPU: AMD FX(tm)-6300, RAM: 32 GB , GPU: Radeon RX 580) with Mesa master @a478e56fbd and virglrenderer @e272472d72. The guest OS Ubuntu 19.04, X-server was configured to run at a a resolution of 1600x900, the same mesa version was used like on the host.

Gaming within a QEMU session

The games, in the order of appearance, are:

  • Tomb Raider 2013 (Crystal Dynamics - Linux port by Feral, 2013)
  • Alien Isolation (Creative Assembly - Linux port by Feral, 2014)
  • Outlast (Red Barrels, 2013)
  • Metro Last Light Redux (4A Games, 2014)
  • The Talos Principle Legacy (Croteam, 2014)
  • Shadow Warrior (Flying Wild Hog, 2013)
  • Portal (Valve, 2007)

Vtest - a lightweight separation of client software and host hardware

If for some reason one wants to run OpenGL software not directly on the host hardware but without going through full virtualization, vtest provides an option to do so. Here the interface to the OpenGL hardware is provided by server "virgl_test_server", and the client software uses virgl as a software renderer.

To prepare the client environment one has to run "virgl_test_server" in the background and prepare the client environment by defining:

  export GALLIUM_DRIVER=virpipe

Then OpenGL software will use virgl as driver, virgl_test_server takes care of the rendering, reads back the rendering output from the hardware and sends it as bitmap to the client where it is displayed.

Gaming via vtest

The games, in the order of appearance, are:

  • Half Life 2 - (Valve, 2004)
  • Metro Last Ligh (4A Games, 2013)
  • Portal 2 (Valve, 2011)
  • Antichamber (Demruth, 2013)
  • World of Goo (2D Boy, 2008)
  • Dead Space (EA Redwood Shores, 2008) - runs on Linux via Steam/Proton
  • SOMA (Friktional Games, 2015)


Both, qemu with virglrenderer and vtest, provide means to separate 3D software from the hardware and its drivers beyond of what the normal OpenGL interface offers, and it still offers accelerated rendering. Loading times, used for texture upload et al, were not taken into account in the videos above nor did we present very demanding games for which we are still working on optimization. Still as shown in the videos, older games can be played very well with the virtualization in place. Newer games, that are graphically more demanding, are somewhat playable, but work is still needed to further improve performance there.


Special thanks go to Dave Airlie from Red Hat for getting the ball rolling, without him the project wouldn't even be close to were it is now. Much of this work is done in close cooperation between the Collabora Graphics team (@afrantzis, @elie, @evelikov, @gerddie, @kusma, @tomeu) and the Google Chrome OS team (especially @gurchetansingh and @olv).

The screen recordings were done by using simplescreenrecorder and the videos were cut by using Kdenlive.

Comments (7)

  1. Elvis Stansvik:
    Aug 29, 2019 at 07:42 AM

    Very interesting. How about Windows guests, are there Windows GPU drivers available?

    I could see this being very useful solution at work. Having VM guests with OpenGL available in our CI setup would allow us to run some OpenGL graphics-requiring tests that we currently can not run. We use VirtualBox + Windows for the Windows CI builds currently, but its OpenGL support is too poor.

    Reply to this comment

    Reply to this comment

    1. Gert Wollny:
      Sep 02, 2019 at 01:40 PM

      Currently, windows guests are not supported.

      Reply to this comment

      Reply to this comment

      1. Elvis Stansvik:
        Sep 02, 2019 at 04:16 PM

        Alright, thanks. Through some digging after I first posted the question, I found that there was some preliminary work done by a GSoC student to make drivers for Windows, but that the work is not finished.

        Reply to this comment

        Reply to this comment

  2. Jay Sanders:
    Aug 30, 2019 at 05:49 PM

    A virtualized virtual world. What the heck is that? A virtual world in a virtual world. Or just another buzzword?

    Reply to this comment

    Reply to this comment

    1. Gert Wollny:
      Sep 02, 2019 at 01:41 PM

      It's just a play of words (virtual worlds like games run inside a virtual machine).

      Reply to this comment

      Reply to this comment

  3. champ:
    Sep 02, 2019 at 02:52 PM

    The "Chau-i Wu" in this article should be "Chia-I Wu".

    Reply to this comment

    Reply to this comment

  4. Leo Cheng:
    Sep 03, 2019 at 12:53 PM

    I'm glad to hear this news. Virtualization is good, except something touching 3d graphcis. Great move on.

    Reply to this comment

    Reply to this comment

Add a Comment

Allowed tags: <b><i><br>Add a new comment:

Search the newsroom

Latest Blog Posts

Building GStreamer text rendering and overlays on Windows with gst-build


GStreamer relies on various 2D font rendering and layout libraries such as Pango and Cairo to generate text for the Pango plugin, which…

Initcalls, part 2: Digging into implementation


In this second part of this blog post series on Linux kernel initcalls, we'll go deeper into implementation, with a look at the colorful…

Open Source meets Super Resolution, part 1


Introducing an accurate and light-weight deep network for video super-resolution upscaling, running on a completely open source software…

Integrating libcamera into PipeWire


PipeWire continues to evolve with the recent integration of libcamera, a library to support complex cameras. In this blog post, I'll explain…

Pushing pixels to your Chromebook


A high-level introduction of the Linux graphics stack, how it is used within ChromeOS, and the work done to improve software rendering (while…

Using the Linux kernel's Case-insensitive feature in Ext4


Last year, a (controversial) feature was added to the Linux kernel to support optimized case-insensitive file name lookups in the Ext4 filesystem.…

Open Since 2005 logo

We use cookies on this website to ensure that you get the best experience. By continuing to use this website you are consenting to the use of these cookies. To find out more please follow this link.

Collabora Ltd © 2005-2020. All rights reserved. Privacy Notice. Sitemap.