The Shared GPU and Display framework enables guests running in virtual machines (VMs) to show content on a display that's attached to the host system.
The framework supports the sharing of virtual displays only in the direction from guest to host. Guests can send multiple windows associated with an application to a physical display on the host. There may be specific displays and/or pipelines dedicated to guests. By using this framework, a guest can offload the work of drawing to the framebuffer or compositing a final scene for the display to the host.
Guest applications that render graphics use the rendering library and windowing system supported by the guest OS. For example, for a QNX Neutrino guest, the rendering library is OpenGL and the windowing system is Screen.
Display sharing from guests to host
The host manages interactions between guests, the GPU, and the display controller. The guest must be aware that it's running in a virtualized environment, and its rendering library and windowing system must use the appropriate driver to communicate with the virtio-gpu vdev. This vdev provides both GPU functionality and display-sharing capabilities.
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 display sharing is transparent to these applications. For information on how graphics commands from guest applications are forwarded to and handled by the vdev, see “GPU sharing architecture”.
When guest operations are entirely hardware-accelerated, the graphics tasks of rendering and displaying are performed on the host. The content is then available only on the host. If the guest needs to perform a CPU operation, then the content has to be uploaded (transferred) to the guest. The transfer operation has a CPU cost; less content to be transferred means better performance of the graphics virtualization.
On the host, the virtual display output is accessible as a native Screen window. The user can do what they want with the window by using the Screen API. By default, virtio-gpu will post the content on the default host display; this can be configured in the vdev's options.
The GPU commands from host applications go through the graphics middleware to the GPU driver. When host applications receive the resulting image buffers from this driver, they send them to Screen, which interacts with the display controller to render the image content onto a physical display. This hardware does the final scene compositing across all rendering pipelines, which entails displaying the various windows containing guest and host content.
Figure 1. Display sharing architecture
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. For an explanation of how this works, see “Graphics virtualization”.
Example
Figure 2. Display sharing example
In this example, the Android guest is configured with one virtual display whose content is to be shown on Display 1 on the host. The Linux guest is configured with two virtual displays, both of which will have their content also shown on Display 1. The guest applications generate and render image content through their own graphics middleware (not shown), and use an appropriate driver to send the content to their virtual displays. This content is accessible on the host as Screen windows.
This example also shows a host application producing content in a Screen window. On the host, all Screen windows that have content destined for the physical display are composited either onto a framebuffer and then to a pipeline, or directly onto a pipeline. When the image content is put onto the appropriate pipeline of the display hardware, the final scene is shown on the display (Display 1).