Para-virtualized high-performance computing and GDI acceleration

The present invention extends to methods, systems, and computer program products for para-virtualized GPGPU computation and GDI acceleration. Some embodiments provide a compute shader to a guest application within a para-virtualized environment. A vGPU in a child partition presents compute shader DDIs for performing GPGPU computations to a guest application. A render component in a root partition receives compute shader commands from the vGPU and schedules the commands for execution at the physical GPU. Other embodiments provide GPU-accelerated GDI rendering capabilities to a guest application within a para-virtualized environment. A vGPU in a child partition provides an API for receiving GDI commands, and sends GDI commands and data to a render component in a root partition. The render component schedules the GDI commands on a 3D rendering device. The 3D rendering device executes the GDI commands at the physical GPU using a sharable GDI surface.

CROSS-REFERENCE TO RELATED APPLICATIONS

Not Applicable.

BACKGROUND

Background and Relevant Art

Computer systems and related technology affect many aspects of society. Indeed, the computer system's ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, accounting, etc.) that prior to the advent of the computer system were performed manually. More recently, computer systems have been coupled to one another and to other electronic devices to form both wired and wireless computer networks over which the computer systems and other electronic devices can transfer electronic data. Accordingly, the performance of many computing tasks is distributed across a number of different computer systems and/or a number of different computing environments.

Some computer systems are configured to provide para-virtualized execution environments, which allow guest software to share hardware devices of a single computer system in an isolated manner. Generally, para-virtualized execution environments provide a plurality of partitions, supported by a hypervisor. The partitions provide isolation between different guest software. The partitions generally include a root partition and one or more child partitions. The root partition runs a host operating system and manages a virtualization stack. The root partition may gain access to physical devices. Each child partition hosts guest software (e.g., guest operating systems and guest applications). Child partitions are provided access to physical devices through virtual devices and software interfaces of the hypervisor.

Some para-virtualized execution environments provide child partitions (and guest software executing therein) with para-virtualized access to one or more physical graphics processing units (“GPUs”). Generally, each implementation of para-virtualized access to physical GPUs supports particular three-dimensional rendering framework(s). As such, guest software may be unable to access capabilities of a physical GPU if that guest software is executing within a para-virtualized execution environment that does not support those capabilities. In some cases, the guest software may rely on using a virtualized CPU to perform tasks not supported para-virtualized access to a physical GPU, incurring a potentially significant performance penalty.

BRIEF SUMMARY

The present invention extends to methods, systems, and computer program products for providing high-performance computing and graphics device interface (“GDI”) acceleration in a para-virtualized environment.

Some embodiments include a method for providing graphics processing unit (“GPU”) accelerated computing functionality to a guest application executing in a child partition of a para-virtualized execution environment. A virtual machine session is instantiated. A hypervisor in the virtual machine session provides (i) a root partition (which has access to a physical GPU), and (ii) the child partition (which executes the guest application).

A virtualized graphics processing unit (“vGPU”) executing within the child partition is presented to the guest application. A user-mode driver (“UMD”) of the vGPU presents compute shader device driver interfaces (“DDIs”) to the guest application. The compute shader DDIs provide an application programming interface (“API”) that enables the guest application to send compute shader commands to the vGPU. The compute shader commands are used to perform general-purpose graphics processing unit (“GPGPU”) computations at the physical GPU using a compute shader. A render component executing within the root partition receives a physical GPU-specific compute shader command from the vGPU, and schedules the command for execution at the physical GPU.

Additional embodiments include a method for providing GPU-accelerated GDI functionality to a guest application executing in a child partition of a para-virtualized execution environment. A virtual machine session is instantiated. A hypervisor in the virtual machine session provides (i) a root partition having access to a physical GPU, and (ii) the child partition which executes the guest application.

A vGPU, which executes within the child partition, is presented to the guest application. An API of a kernel-mode driver (“KMD”) of the vGPU enables the guest operating system to accelerate GDI rendering commands submitted by a guest application. These commands are then processed by the KMD of the vGPU.

A render component executing within the root partition receives a GDI acceleration rendering command from the vGPU. In response, the render component schedules the GDI acceleration rendering command on a GDI composition device within the root partition. The GDI composition device is configured to execute the GDI acceleration rendering command at the physical GPU. The GDI composition device marks a GDI surface corresponding for the GDI command as sharable for composition by the desktop.

DETAILED DESCRIPTION

The present invention extends to methods, systems, and computer program products for providing high-performance computing and graphics device interface (“GDI”) acceleration in a para-virtualized environment.

Some embodiments include a method for providing graphics processing unit (“GPU”) accelerated computing functionality to a guest application executing in a child partition of a para-virtualized execution environment. A virtual machine session is instantiated. A hypervisor in the virtual machine session provides (i) a root partition (which has access to a physical GPU), and (ii) the child partition (which executes the guest application).

A virtualized graphics processing unit (“vGPU”) executing within the child partition is presented to the guest application. A user-mode driver (“UMD”) of the vGPU presents compute shader device driver interfaces (“DDIs”) to the guest application. The compute shader DDIs provide an application programming interface (“API”) that enables the guest application to send compute shader commands to the vGPU. The compute shader commands are used to perform general-purpose graphics processing unit (“GPGPU”) computations at the physical GPU using a compute shader. A render component executing within the root partition receives a physical GPU-specific compute shader command from the vGPU, and schedules the command for execution at the physical GPU.

Additional embodiments include a method for providing GPU-accelerated GDI functionality to a guest application executing in a child partition of a para-virtualized execution environment. A virtual machine session is instantiated. A hypervisor in the virtual machine session provides (i) a root partition having access to a physical GPU, and (ii) the child partition which executes the guest application.

A vGPU, which executes within the child partition, is presented to the guest application. An API of a kernel-mode driver (“KMD”) of the vGPU enables the guest operating system to accelerate GDI rendering commands submitted by a guest application. These commands are then processed by the KMD of the vGPU.

A render component executing within the root partition receives a GDI acceleration rendering command from the vGPU. In response, the render component schedules the GDI acceleration rendering command on a GDI composition device within the root partition. The GDI composition device is configured to execute the GDI acceleration rendering command at the physical GPU. The GDI composition device marks a GDI surface corresponding for the GDI command as sharable for composition by the desktop.

FIG. 1Aillustrates an example computer architecture100athat enables para-virtualized access to compute shader functionality of physical GPU hardware. Referring toFIG. 1A, computer architecture100aincludes physical hardware101. Physical hardware101can include any appropriate hardware devices, such as one or more general purpose processors, system memory, and the like. As depicted, physical hardware includes at least one physical GPU101a.

Physical GPU101ais a processing device configured to perform parallel processing tasks, such as graphics rendering. Physical GPU101aincludes support for executing a compute shader, which enables physical GPU101ato perform general-purpose (i.e., non-graphics rendering) calculations. In other words, physical GPU101asupports GPGPU computation on a compute shader device.

Computer architecture100aalso includes hypervisor102. Hypervisor102executes on top of physical hardware101and supports a virtualization platform. The virtualization platform provides a plurality of partitions. Each partition provides a logical unit of isolation, in which guest software can be executed. For example, computer architecture100aincludes root partition103and child partition104.

Root partition103executes a host operating system, and has direct access to physical hardware101(as depicted by root partition103appearing over physical hardware101). Each child partition provides an execution environment for executing guest software (e.g., operating systems and/or applications) and may access physical hardware101indirectly in a para-virtualized manner. That is, through hypervisor102, each child partition provides one or more software interfaces (e.g., virtualized hardware) to guest software. The guest software, in turn, uses the software interface(s) to access physical hardware101. Hypervisor102can provide support for a plurality of child partitions.

As depicted, guest software105executes within child partition104. Guest software105comprises any appropriate guest software, such as an operating system and/or an application program executing within an operating system. Guest software105includes or uses graphics runtime105a. Graphics runtime105aprovides a framework (e.g., APIs) for rendering graphics and/or performing GPGPU computation.

Child partition104provides guest software105access to vGPU106. vGPU105virtualizes physical GPU101a, enabling guest software105to indirectly access physical GPU101a. As such, vGPU106is configured to expose all, or a subset, of the functionality of at least one rendering framework (corresponding to graphics runtime105a) to guest software105, along with any corresponding functionality of physical GPU101a.

In particular, vGPU106is configured to expose one or more software interfaces that enable guest software105to call vGPU106to access compute shader functionality of physical GPU101afor performing GPGPU computation at physical GPU101a. vGPU106, in turn, works in conjunction with a render component in root partition103to perform compute shader functionality on physical GPU101a. As depicted, for example, root partition103includes render component112. Render component112, in turn, includes compute shader component113for handing compute shader commands and data. vGPU106remotes compute shader commands and data117to render component112to perform the rendering on physical GPU101a.

Render component112schedules any graphics commands received from vGPU106for execution on physical GPU101a. Render component112also creates proper context for executing those commands. As such, render component112is configured to use compute shader component113to schedule execution of compute shader-related commands that are received from vGPU106in child partition104on physical GPU101a.

As depicted, vGPU106includes user-mode driver106aexecuting in a user-mode of child partition104and kernel-mode driver109executing in a kernel-mode of child partition104. User-mode driver106aexposes device driver interfaces (“DDIs”) of at least one rendering framework, including DDIs related to compute shader (GPGPU) functionality, depicted as compute shader DDIs107. Compute shader DDIs107enable guest software105to make calls to vGPU106for performance of GPGPU computations.

In some embodiments, user-mode driver106bexposes DDIs of a rendering framework that supports compute shader functionality (e.g., DirectX® versions 10 and/or 11 from Microsoft® Corporation). For example, in embodiments when user-mode driver106aexposes compute shader functionality of DirectX® versions 10 and 11, user-mode driver106amay expose the one or more of the following DDIs as part of compute shader DDIs107:

In some embodiments, vGPU106may also include legacy user-mode driver106bexecuting in user-mode of child partition104. Legacy user-mode driver106bmay expose DDIs of a legacy version of one or more rendering frameworks. For example, legacy user-mode driver106bmay support a legacy version of DirectX® (e.g., DirectX® version 9), or a legacy version any other rendering framework (e.g., OpenGL® from Silicon Graphics, Inc.).

Generally, user-mode driver106ais configured to construct hardware contexts and command buffers. In particular, user-mode driver106aconverts graphic commands issued by guest software105(or graphics runtime105aof guest software105) into hardware-specific commands. For example, user-mode driver106amay receive graphics commands115relating to GPGPU computations using a compute shader from guest software105. User-mode driver106ais configured to convert graphics commands115into hardware-specific commands (i.e., commands that are specific to physical GPU101a). As part of the conversion, user-mode driver106amaintains proper hardware context for physical GPU101a. For example, user-mode driver106atranslates logical values for settings affecting a graphics pipeline into values and corresponding physical settings. User-mode driver106ais also configured to store converted hardware-specific commands in command buffer116and send command buffer115to kernel-mode driver109.

In addition, vGPU106includes kernel-mode driver109executing in kernel-mode of child partition104, which includes compute shader component110. Kernel-mode driver109is configured to receive command buffers (e.g., command buffer116) and to construct corresponding direct memory access (“DMA”) buffers. When it is time for a DMA buffer to be processed, a GPU scheduler calls kernel-mode driver109. Kernel-mode driver109then handles the specifics of actually submitting the DMA buffer to physical GPU101a.

FIG. 2Aillustrates a flow chart of an example method200afor providing GPU-accelerated computing functionality to a guest application executing in a child partition of a para-virtualized execution environment. Method200awill be described with respect to the components and data of computer architecture100a.

Method200aincludes an act of instantiating a virtual machine session, including instantiating a hypervisor that provides (i) a root partition having access to the physical GPU, and (ii) the child partition which executes the guest application (act201). For example, computing environment100acan instantiate hypervisor102as part of instantiating a virtual machine session. Hypervisor102provides root partition103and child partition104. Root partition103has access to physical GPU101a. Child partition104executes one or more guest applications, including guest application105, and has indirect access to physical GPU101a.

Method200aalso includes an act of presenting a vGPU to the guest application, the vGPU executing within the child partition, including presenting a plurality of compute shader DDIs to the guest application as part of a UMD of the vGPU, the plurality of compute shader DDIs providing an API that enables the guest application to send compute shader commands to the vGPU for performing GPGPU computations at the physical GPU using a compute shader (act202). For example, child partition104can present vGPU106to guest software105. vGPU106includes user-mode driver106a. User-mode driver106apresents compute shader DDIs107, which enable guest software105to call vGPU106to perform compute shader GPGPU calculations at physical GPU101a. For example, guest software105(or graphics runtime105a) can send graphics commands115to vGPU106for performance of GPGPU calculations at physical GPU101a.

User-mode driver106aconverts received graphics commands115to physical-hardware specific commands (e.g., as part of command buffer116). vGPU106then remotes compute shader commands and data117(including physical-hardware specific commands) to render component112.

Method200aalso includes an act of a render component executing within the root partition receiving a physical GPU-specific compute shader command from the vGPU (act203). For example, render component112, which executes in root partition103, can receive compute shader commands and data117, including a physical GPU-specific compute shader command, from vGPU106.

Method200aalso includes an act of the render component scheduling the physical GPU-specific compute shader command for execution at the physical GPU (act204). For example, compute shader component113can schedule the received physical GPU-specific compute shader command for execution on a compute shader device at physical GPU101a. In doing so, compute shader component113can configure and maintain appropriate context for execution of the physical GPU-specific compute shader command.

In addition to providing guest software para-virtualized compute shader access to physical GPU101a(i.e., GPGPU computational ability), embodiments extend to providing guest software para-virtualized GDI acceleration at a physical GPU.FIG. 1Billustrates an alternate computer architecture100bthat enables para-virtualized GDI acceleration by physical GPU hardware. Thus, computer architecture100benables guest software to request GDI command acceleration using a physical GPU, as opposed to handling GDI commands with a physical or virtual central processing unit.

Within child partition104′, computer architecture100bprovides components that enable accelerated rendering of GDI commands on physical GPU101a′ when those commands are issued by guest software105′. As depicted, for example, child partition104′ includes GDI interface108, which is configured to communicate with graphics runtime105a′ (e.g., a graphics runtime that is part of a guest operating system). Furthermore, vGPU106′ is configured to process GDI acceleration commands120received from GDI interface108at GDI component111of kernel-mode driver109′.

GDI interface108is configured to expose one or more GDI command interfaces to graphics runtime105a′, and to forward GDI accelerated commands received from graphics runtime105a′ to kernel-mode driver109′ of vGPU′. Thus, at the request of guest software105′, graphics runtime105a′ is enabled to send GDI accelerated graphics commands120to kernel-mode driver109′ of vGPU106′ via GDI interface108to accelerate GDI command execution at physical GPU101a′.

GDI component111of kernel-mode driver109′ is configured to implement one or more GDI command interfaces, along with corresponding hardware rendering operation(s). In some embodiments, vGPU106′ implements and exposes GDI commands corresponding to a particular version of DirectX® (e.g., DirectX® versions 10 and/or 11). For example, GDI component111may expose and implement a ‘DxgkDdiRenderKm’ interface, along with corresponding hardware rendering operations. While GDI component111may implement any appropriate GDI operations, in some embodiments GDI component111implements the following operations:

Kernel-mode driver109′ is configured to send GDI commands and data118to render component112′ within root partition103′. GDI commands and data118include information relating to 3D rendering devices and contexts for executing GDI acceleration commands. Render component112′ includes GDI component114, which is configured to receive GDI commands and data118and to execute received GDI acceleration commands at physical GPU101a′.

In particular, GDI component114is configured to create a GDI surface and a corresponding 3D rendering (or composition) device (e.g., a D3D device). The 3D rendering device is configured to provide appropriate context for executing GDI accelerated commands. The GDI surface can comprise any appropriate GDI surface, such as any of the following GDI surface types:

FIG. 2Billustrates a flow chart of an example method200bfor providing GPU-accelerated GDI functionality to a guest application executing in a child partition of a para-virtualized execution environment. Method200bwill be described with respect to the components and data of computer architecture100b.

Method200bincludes an act of instantiating a virtual machine session, including instantiating a hypervisor that provides (i) a root partition having access to the physical GPU, and (ii) the child partition which executes the guest application (act205). For example, computing environment100bcan instantiate hypervisor102′ as part of instantiating a virtual machine session. Hypervisor102′ provides root partition103′ and child partition104′. Root partition103′ has access to physical GPU101a′. Child partition104′ executes one or more guest applications, including guest application105′, and has indirect access to physical GPU101a′.

Method200balso includes an act of presenting a vGPU to the guest application, the vGPU executing within the child partition, including presenting an API of a KMD of the vGPU that enables a guest operating system to accelerate GDI rendering commands used by the guest application to the vGPU for processing by the KMD of the vGPU (act206). For example, child partition104′ presents vGPU106′ and GDI interface108to guest software105′. GDI interface108enables graphics runtime105a′ (e.g., a graphics runtime of an operating system) to accelerate GDI rendering commands used by guest software105′ to vGPU106′ for processing by kernel-mode driver109′ and for acceleration by physical GPU101a′. For example, graphics runtime105a′ can send graphics commands120to kernel-mode driver109′ through GDI interface108for performance of GDI acceleration commands. vGPU106′ uses GDI component111of kernel-mode driver109′ to process received GDI commands and to send GDI commands and data118to render component112′ in root partition103′.

Method200balso includes an act of a render component executing within the root partition receiving a GDI acceleration rendering command from the vGPU (act207). For example, render component112′, which executes in root partition103′, can receive GDI commands and data118from vGPU106′.

Method200balso includes an act of the render component scheduling the GDI acceleration rendering command on a GDI composition device within the root partition, the GDI composition device being configured to execute the at least one GDI acceleration rendering command at the physical GPU, the GDI composition device also being configured to mark a GDI surface corresponding to the at least one GDI acceleration rendering command as sharable for composition by a desktop (act208). For example, GDI component114can create a 3D rendering (composition) device and a GDI surface for execution of GDI acceleration commands and can schedule the GDI acceleration commands for execution on the 3D rendering (composition) device. The GDI surface can be marked as sharable for composition at the desktop.

In some embodiments, a single computer architecture can provide both compute shader (GPGPU) functionality and para-virtualized GDI acceleration.FIG. 1Cillustrates an example computer architecture100cthat enables para-virtualized access to compute shader functionality and para-virtualized GDI acceleration by physical GPU hardware. For example, computer architecture100cincludes GDI interface108and vGPU106″. vGPU106″contains user-mode driver106a″, which includes compute shader DDIs107. vGPU106″ also contains kernel-mode driver109″ that includes both compute shader component110aand GDI component111.

vGPU106″ (executing in child partition104″), can communicate both compute shader commands and data and GDI commands and data to render component112″ executing in root partition103″. Render component112″ includes both compute shader component113and GDI component114for executing compute shader and GDI commands at GPU101a″. It will be appreciated that computer architecture100c, by including both compute shader and GDI functionality, can provide increased functionality and greater compatibility with particular rendering frameworks.