Graphics Virtualization Late Synchronization for VM Exit Reduction
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
API forwarding techniques in graphics virtualization trigger frequent VM exits, leading to a significant performance penalty due to the need for frequent interactions between the VM guest OS and the host to execute OpenGL commands that require return values, resulting in inefficient resource utilization and reduced server performance.
Innovation Solution
Implementing late synchronization by using an execution engine front end that captures and persists graphics commands locally, generating virtual resource IDs, and triggering a limited number of VM exits only when necessary, such as during frame display, to reduce the frequency of host interactions and optimize command execution.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If API forwarding is used to enable graphics virtualization, then multiple VMs can access graphics resources through a Hypervisor, but frequent VM exits occur resulting in high performance penalty
Solution Approach 1:
The execution engine front end captures and persists graphics commands locally in advance, preparing command buffers before actual execution is needed. This preliminary action allows the system to reduce the frequency of VM exits by batching commands, thereby maintaining graphics resource sharing capability while improving server performance.
Solution Approach 2:
An execution engine front end is introduced as an intermediary component between the VM guest OS and the host. This intermediary captures graphics commands locally and manages when to trigger VM exits to the host, reducing the frequency of interactions while maintaining the virtualization benefit of shared graphics resources.
2Reliability
If OpenGL commands requiring return values are executed in the VM guest OS, then complete command execution is achieved, but frequent VM exits are triggered increasing latency
Solution Approach 1:
The execution engine front end performs preliminary capture and persistence of graphics commands locally, preparing command buffers in advance. This allows the system to execute commands without frequent VM exits, reducing latency while maintaining complete command execution through the persisted command buffer mechanism.
Solution Approach 2:
The execution engine front end serves itself by capturing and persisting commands locally, enabling autonomous command execution within the VM without requiring continuous host interaction. This self-service approach reduces the time lost to frequent VM exits while ensuring complete command execution.
3Reliability
If frequent VM exits are used for command execution, then host interaction is ensured for commands needing return values, but overall system efficiency is reduced
Solution Approach 1:
The execution engine front end performs preliminary capture and persistence of graphics commands locally, preparing command buffers before execution. This preliminary action reduces the frequency of VM exits to the host, improving resource utilization efficiency while maintaining reliable host interaction only when necessary for commands requiring return values.
Solution Approach 2:
The execution engine front end acts as an intermediary that manages host interaction by capturing commands locally and batched triggering VM exits only when necessary. This intermediary approach improves resource utilization efficiency while ensuring reliable host interaction for commands that require it, reducing the trade-off between these two requirements.
Data Source
AI summary
An apparatus and method are described for graphics virtualization with late synchronization. For example, a virtualized graphics execution environment is implemented on a host, including a hypervisor to virtualize graphics processing resources for one or more virtual machines (VMs). A plurality of graphics commands are received responsive to execution of a graphics application in one of the VMs. The graphics commands are persisted until a frame triggering event is detected. Upon detection of a frame triggering event, the persisted graphics commands are submitted to the host.