Updated: April 19, 2023 |
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.
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 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.