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.
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).
The screen recordings were done by using simplescreenrecorder and the videos were cut by using Kdenlive.
08/10/2024
Having multiple developers work on pre-merge testing distributes the process and ensures that every contribution is rigorously tested before…
15/08/2024
After rigorous debugging, a new unit testing framework was added to the backend compiler for NVK. This is a walkthrough of the steps taken…
01/08/2024
We're reflecting on the steps taken as we continually seek to improve Linux kernel integration. This will include more detail about the…
27/06/2024
With each board running a mainline-first Linux software stack and tested in a CI loop with the LAVA test framework, the Farm showcased Collabora's…
26/06/2024
WirePlumber 0.5 arrived recently with many new and essential features including the Smart Filter Policy, enabling audio filters to automatically…
12/06/2024
Part 3 of the cmtp-responder series with a focus on USB gadgets explores several new elements including a unified build environment with…
Whether writing a line of code or shaping a longer-term strategic software development plan, we'll help you navigate the ever-evolving world of Open Source.
한국어 버전의 Collabora.com 보기
Acesse Collabora.com em Português
Comments (15)
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
Gert Wollny:
Sep 02, 2019 at 01:40 PM
Currently, windows guests are not supported.
Reply to this comment
Reply to this comment
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
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
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
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
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
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
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
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
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
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
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.
Thanks,
Mike
Reply to this comment
Reply to this comment
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
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.
Sincerely,
Mike
Reply to this comment
Reply to this comment
Add a Comment