Virtualized GPU access is becoming common in the containerized and virtualized application space. Let’s have a look at why and how.
By Robert Foss, Senior Software Engineer at Collabora.
For the past few years a clear trend of containerization of applications and services has emerged. Having processes containerized is beneficial in a number of ways. It both improves portability and strengthens security, and if done properly the performance penalty can be low.
In order to further improve security containers are commonly run in virtualized environments. This provides some new challenges in terms of supporting the accelerated graphics usecase.
OpenGL ES implementation
Currently Collabora and Google are implementing OpenGL ES 2.0 support. OpenGL ES 2.0 is the lowest common denominator for many mobile platforms and as such is a requirement for Virgil3D to be viable on the those platforms.
That is is the motivation for making Virgil3D work on OpenGL ES hosts.
How does this work?
This stack is commonly referred to as Virgil3D, since all of the parts originated from a project with that name.
There are a few parts to this implementation.
QEMU, virglrenderer and virtio-gpu. They way it works is by letting the guest applications speak unmodified OpenGL to the Mesa. But instead of Mesa handing commands over to the hardware it is channeled through virtio-gpu on the guest to QEMU on the host.
QEMU then receives the raw graphics stack state (Gallium state) and interprets it using virglrenderer from the raw state into an OpenGL form, which can be executed as entirely normal OpenGL on the host machine.
The host OpenGL stack does not even have to be Mesa, and could for example be the proprietary nvidia stack.
Continue reading on Collabora’s blog.
