We're hiring!

Virglrenderer and the state of virtualized virtual worlds

Gert Wollny avatar

Gert Wollny
August 28, 2019

Share this post:

Reading time:

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 (15)

  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

  5. Mathieu Tournier:
    Jan 05, 2021 at 07:40 AM

    Hi Gert,
    Thanks you so much for all the work that was done concerning GPU virtualization via virgl.
    I'm currently on ChromeOS on a lenovo Duet, and according to your blog post and virglRenderer source code, it seems i could have Opengl >= 3.0 running on the device.
    Unfortunatly, virgl driver only return a 2.1 valid context (although host can do GLES 3.2)
    More infos here : https://www.reddit.com/r/Crostini/comments/kppwwt/lenovo_duet_opengl_30_is_not_available_on_r87_r88/

    Any idea ?

    Thanks a lot again for all your and collabora team work !

    Reply to this comment

    Reply to this comment

    1. Gert:
      Jan 05, 2021 at 02:18 PM

      Could you post the output of glxinfo including the supported extensions? - and maybe also the list of supported extension on the host? - Especially GL_NV_conditional_render is of interest, since this is an GLES extension that is needed on the host to support OpenGL 3.0 in the guest.

      Reply to this comment

      Reply to this comment

  6. Mathieu Tournier:
    Jan 05, 2021 at 03:51 PM

    Hi Gert, here is all the info i have on the host (including GL extensions).
    It seems that GL_NV_conditional_render is not here... is virgl 3.0 support nvidia vendor only ?


    Here is a complete glxinfo on the linux container :

    Thanks again !

    Reply to this comment

    Reply to this comment

    1. Gert Wollny:
      Jan 06, 2021 at 09:23 AM

      The name of the extension NV_conditional_rendering only means that NVidia proposed the extension. It's functionality is supported by all Hardware that supports OpenGL 3.0, but since it is not part of any GLES version and only provided as extension there, some vendors may not support it on GLES only hardware.

      Reply to this comment

      Reply to this comment

      1. Mathieu Tournier:
        Jan 06, 2021 at 04:08 PM

        Hello Gert,
        Seems G72 hardware is able to handle NV_conditional_rendering, according to panfrost source code.
        Let's hope that being implemented in the Arm closed source driver, or that Google switch from Arm driver to Panfrost !


        Reply to this comment

        Reply to this comment

  7. Mike Stein:
    Jan 09, 2022 at 02:09 AM

    Hi, Gert.

    I had corresponded with you before about some similar OpenGL difficulties while using QEMU and VirglRenderer on iOS (iPAD) via the UTM app but hadn't previously seen your comments to Mathieu about the host needing certain extensions to render Open GL 3.0. My M1 iPad Pro says it is at the OpenGL ES 3.0 standard but may not also have those extensions you mentioned since inside the Virtual Machine, it says it only has the capacity for Open GL 2.1 the same as Mathieu's machine. However, inside the Virtual Machines for users using the QEMU/UTM/VirglRenderer port on their Macs show an Open GL 3.x capacity. I suspect that might then be due to the Mac OSX having more extensions then the iPAD OS does.

    My follow-up question then is whether you think the Angle-Metal interface will overcome the limitation of not being able to render OpenGL 3.x content in the QEMU Virtual Machine on my iPAD (i.e. will Metal have all the extensions needed to support Open GL 3.x in the Virtual Machine)? If so, do you think the Angle-Metal interface is mature enough to try with VirglRenderer? It hadn't been previously when the UTM developer tried it, but it looks like it now might be on the Angle website.

    I appreciate your follow-up thoughts.


    Reply to this comment

    Reply to this comment

  8. Gert Wollny:
    Mar 15, 2022 at 03:37 PM

    There is a developer from Japan, Akihiko Odaki https://gitlab.freedesktop.org/akihiko.odaki, who is actively contributing to fix running virgl on top of Angle. It's probably best to talk to him.

    Reply to this comment

    Reply to this comment

    1. Mike Stein:
      Jul 14, 2022 at 08:03 AM

      Thanks, Gert! Sorry I didn't notice your reply earlier.

      I wrote him this evening, and he promptly wrote back some very helpful suggestions.

      Have a good rest of the week.


      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

Re-converging control flow on NVIDIA GPUs - What went wrong, and how we fixed it


While I managed to land support for two extensions, implementing control flow re-convergence in NVK did not go as planned. This is the story…

Automatic regression handling and reporting for the Linux Kernel


In continuation with our series about Kernel Integration we'll go into more detail about how regression detection, processing, and tracking…

Almost a fully open-source boot chain for Rockchip's RK3588!


Now included in our Debian images & available via our GitLab, you can build a complete, working BL31 (Boot Loader stage 3.1), and replace…

What's the latest with WirePlumber?


Back in 2022, after a series of issues were found in its design, I made the call to rework some of WirePlumber's fundamentals in order to…

DRM-CI: A GitLab-CI pipeline for Linux kernel testing


Continuing our Kernel Integration series, we're excited to introduce DRM-CI, a groundbreaking solution that enables developers to test their…

Persian Rug, Part 4 - The limitations of proxies


This is the fourth and final part in a series on persian-rug, a Rust crate for interconnected objects. We've touched on the two big limitations:…

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-2024. All rights reserved. Privacy Notice. Sitemap.