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

Qemu

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 LIBGL_ALWAYS_SOFTWARE=1 
  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)

Summary

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.

Acknowledgements

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

  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 ?

    https://gist.github.com/Samt43/e7b40d2f727a82526b735bc91a58e3f6

    Here is a complete glxinfo on the linux container :
    https://gist.github.com/Samt43/959fffb06f460ad06e2bec1a216e7b42

    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 !

        Cheers,
        Mathieu

        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

Implementing a performance boosting algorithm in Coccinelle

21/01/2021

Last year, from June to September, I worked on the kernel development tool Coccinelle under Collabora. I implemented a performance boosting…

Desktop OpenGL 3.1 on Mali GPUs with Panfrost

13/01/2021

The open source Panfrost driver for Arm Mali Midgard and Bifrost GPUs now provides non-conformant OpenGL ES 3.0 on Bifrost and desktop OpenGL…

Empathy first: Driving growth through people leadership

30/11/2020

This year, the global pandemic has put a strain on us all. Motivation can become hard to maintain, worries can cloud our minds. Now more…

Developing Wayland Color Management and High Dynamic Range

19/11/2020

Wayland is still lacking proper consideration for color management & support for high dynamic range (HDR) imagery. However, a group of developers…

A summer sprint: bringing near-native performance to Zink

06/11/2020

This week marks two years since the OpenGL implementation on Vulkan was initially announced. Since then, and especially over the past few…

From Panfrost to production, a tale of Open Source graphics

03/11/2020

Since our previous update on Panfrost, the open source stack for Arm's Mali Midgard and Bifrost GPUs, we've focused on taking our driver…

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