August 28, 2019
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.
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.
The games, in the order of appearance, are:
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.
The games, in the order of appearance, are:
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).
Panfrost's ES 3.0 support has landed in upstream Mesa and works with a mainline Linux kernel. The support is still early, but if you're…
When a bug surprises you when doing Apertis packaging of a typical vendor code signing tool, it's time to debug it using the compiler's…
From KernelCI's new home, the latest on Zink (OpenGL on Vulkan), OpenXR & Monado, PipeWire in the automotive industry, JPEG2000, and GStreamer…
If you have a device with a Mali T720 or T820 GPU, you’re in luck – your device is now supported in upstream Mesa at feature parity with…
PipeWire, the new and emerging open source framework that aims to greatly improve the exchange and management of audio and video streams…
With the advent of meson and gst-build, it is now possible to set up a GStreamer Windows development environment that rivals the finest…