GPU sharing architecture

The Shared GPU and Display framework enables guests running in virtual machines (VMs) to access GPU resources on the host system.

Guest applications that render graphics must use a rendering library and windowing system supported by the guest OS. For example, for a QNX Neutrino guest, the rendering library can be OpenGL and the windowing system must be Screen.

Note: The interaction between the rendering library and the virtio-gpu vdev isn't applicable if your hardware supports, and you're using, the capability of GPU splitting so that both the guest and host have designated GPU resources.

GPU sharing between the host and guests

The host manages interactions between guests and the GPU. The guest must be aware that it's running in a virtualized environment, and its rendering library and windowing system must use an appropriate driver to talk to the virtio-gpu vdev.

For guest or host applications that render graphics, there is no change to how they use their native graphics middleware (i.e., rendering library and windowing system)—the GPU sharing is transparent to these applications. The graphics commands from guest applications go through the middleware to the guest driver, which forwards them to the vdev. The guest driver and the vdev use virtqueues to communicate with each other. The vdev works with the configured virtual rendering library to generate image content; for more details, see below.

The graphics commands from host applications go through the graphics middleware to the driver for the physical GPU.

The diagram below illustrates the interaction between guest components, the virtio-gpu vdev, host components, and the GPU hardware.

Figure 1. GPU sharing architecture

Note: For more information on device sharing in the QNX Hypervisor, see the section on “Devices” in the “Understanding QNX Virtual Environments” chapter of the QNX Hypervisor User's Guide.

Graphics virtualization

When guest applications execute API calls in their rendering library (i.e., graphics commands), these calls are forwarded to a library on the host that does the actual rendering. This feature is known as graphics virtualization, and is supported by the following components:

virtio-gpu vdev

The virtio-gpu vdev is a para-virtualized device that enables graphics commands from the guest to be executed on the host. This vdev runs in a hypervisor VM, but doesn't emulate the GPU. In the configuration for this vdev, you can specify which virtual rendering library you want to use to execute these commands. For more information, see the vdev virtio-gpu reference.

Virtual rendering libraries

The framework includes the following libraries that handle graphics API calls and do 3D rendering on the host:

The Graphics Streaming Kit (GFXStream) library, libgfxstream.so, which supports both Vulkan and OpenGL.
The VirGL library, libvirglrenderer.so, which supports only OpenGL.

The library you select in the vdev configuration receives the graphics commands through the vdev and interacts with the GPU driver to generate the 3D image content. This content can then be shown on a physical display attached to the host.

For Android guests, you must use one of these libraries because Android can't operate in 2D mode. For guests that can operate in 2D mode, using one of these libraries is optional.

You also need the right middleware components in the guest, and to configure them to use these host-side rendering libraries.

Example

The following example shows the interaction between an Android guest, a QNX guest, and the GPU, managed by the host:

Figure 2. GPU sharing example