Graphics processing unit partitioning for virtualization

Abstract

Technologies for virtualized graphics processing unit (GPU) partitioning are described herein. In one or more implementations, a GPU partition manager of a host device receives a request for a virtual machine with GPU functionality. Specifically, the request specifies GPU functionality based on different GPU capabilities. These different capabilities correspond to segments of a GPU model that represents GPU functionality and is used to manage interactions between the virtual machine and the GPU. The GPU partition manager determines whether the host device's GPU is available to fulfill the request based on the specified capabilities. If so, the GPU partition manager allocates a portion of the determined available GPU to the virtual machine to configure the virtual machine with a GPU partition with the functionality. The virtual machine configured with the GPU partition can then be exposed to provide GPU-processed data to the GPU partition requester.

Description

[0001] This application is a divisional application of Chinese invention patent application No. 201880009743.1. Background Art

[0002] Typically, virtualization technology breaks the one-to-one link between physical computing devices and operating systems by abstracting physical resources into virtualized resources. Virtualization allows multiple operating system instances or application instances to coexist on the same physical machine and be isolated from each other. Virtualization also enables multiple operating system instances to share resources of physical devices, such as shared storage devices, processing devices (e.g., graphics processing units (GPUs)), network devices, etc. These advances have led to the centralization of many computing resources, enabling various computing tasks to be performed "through the cloud."

[0003] As an example, individuals associated with an enterprise can be given accounts that allow them to access a desktop interface configured by the enterprise—the desktop interface can be configured to provide productivity tools selected by the enterprise, storage hosted by the enterprise, and so on. The desktop interface associated with a given individual can also be accessible via multiple different computing devices, such as a desktop device at work, a laptop device at home, a tablet device when traveling, and so on. Although accessible from these multiple different computing devices, the functionality provided by the desktop interface can be primarily provided using the processing and storage resources of the enterprise's servers rather than the resources of the computing device directly interacting with the individual. In addition, virtualization technology enables the processing and storage resources of these servers to be further used to provide personalized desktop interfaces to multiple individuals in the enterprise simultaneously. Advances in virtualization technology continue to be made, such as increasing the speed at which computing tasks can be completed using virtual machines or reducing the cost of implementing systems by adopting virtual machines. Despite this, some traditional technologies used to implement virtualization can be expensive, vulnerable to security vulnerabilities, or associated with specific host device hardware configurations. Therefore, many applications may not be able to take advantage of virtualization. Summary of the Invention

[0004] This summary introduces some concepts in a simplified form, which will be further described in the detailed description below. As such, this summary is not intended to identify the essential features of the claimed technical solution, nor is it intended to be used to help determine the scope of the claimed technical solution.

[0005] Technologies for virtualized graphics processing unit (GPU) partitioning are described herein. In one or more implementations, a GPU partition manager of a host device receives a request for a virtual machine with GPU functionality. Specifically, the request specifies the GPU functionality based on different GPU capabilities. These different capabilities correspond to segments of a GPU model that represents the GPU functionality and is used to manage interactions between the virtual machine and the GPU. The GPU partition manager determines whether a GPU of the host device is available to fulfill the request based on the specified GPU capabilities. If available, the GPU partition manager allocates at least a portion of the determined available GPU to the virtual machine to configure the virtual machine with a GPU partition with the functionality. The virtual machine configured with the GPU partition can then be exposed to the partitioned requestor and provide GPU-processed data. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The detailed description is described with reference to the accompanying drawings. In the drawings, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference number in different instances in the description and the drawings may indicate similar or identical items. An entity shown in a drawing may refer to one or more entities, and thus, singular or plural forms of entities may be referred to interchangeably in the discussion.

[0007] Figure 1 is an illustration of an environment in an example implementation that is operable to employ the techniques described herein.

[0008] Figure 2 is a diagram depicting an example abstract model of a graphics processing unit (GPU) to partition the GPU for virtualization according to one or more implementations.

[0009] Figure 3 is a diagram depicting an example scenario in which a host's GPU is assigned to a virtual machine to deliver requested GPU processing in accordance with one or more implementations.

[0010] Figure 4A and Figure 4B is a diagram depicting an example configuration of GPU partition requests and completion notifications according to one or more implementations.

[0011] Figure 5 is a flow diagram depicting an example process for assigning a host's GPU to a virtual machine according to one or more implementations.

[0012] Figure 6 is a flow diagram depicting an example process to provision GPU functionality to a virtual machine via a virtual device in accordance with one or more implementations.

[0013] Figure 7An example system is illustrated that includes various components of an example device that can be used for one or more implementations of the techniques described herein. DETAILED DESCRIPTION

[0014] Overview

[0015] Advances continue to be made in virtualization technology, for example, to increase the speed at which computing tasks can be completed using virtual machines, to reduce the cost of implementing a system by employing virtual machines, or to decouple functionality from a specific host hardware configuration. Despite this, some traditional techniques for implementing virtualization may not allow for wider adoption. In some scenarios, virtualization can be implemented by a host device that supplies a host operating system. Under the host operating system, multiple guest operating systems can be instantiated. These guest operating systems can be referred to as "virtual machines," which can emulate a computing device and provide the functionality of a physical computer. However, in many scenarios, virtualization is implemented without a host operating system. Instead, a hosted system is implemented using a virtualization manager (e.g., a type 1 hypervisor) that is configured with modules for controlling resources and access to the resources of the corresponding host device.

[0016] In connection with providing the functionality of a physical computer, a virtual machine typically utilizes the physical devices of a corresponding host device to some extent. A host device configured according to conventional techniques may include a variety of different physical devices to supply the virtual machine with various desired functions. Examples of such physical devices include storage devices, networking devices, and processing devices (graphics processing units (GPUs)). In many scenarios, a virtual machine may utilize the host device's GPU to provide rendered scenes (e.g., for cloud-hosted video games, high-definition (HD) three-dimensional (3D) images, or virtual reality environments), video encoding and decoding, data processing, large-scale computing, and the like. However, conventional techniques that enable virtual machines to utilize GPUs may be associated with the specific GPU configured on the host device. For example, using conventional techniques, a virtual machine requesting GPU processing may have to configure the request in a format specific to the provider of the corresponding host's onboard GPU. Without a provider-independent method for requesting GPU processing, it may be difficult to update the host machine's hardware, the host provider may be associated with a specific GPU provider, and the virtual machine may need to configure requests for the GPU to indicate the values ​​of a large number of different parameters, etc.

[0017] Thus, GPU partitioning for virtualization is described. In one or more implementations, requesting and providing partitions to perform GPU processing associated with a virtual machine is based on a partition abstraction model for the GPU. Specifically, the abstraction model is divided into segments representing a predetermined set of GPU capabilities. Thus, the abstraction model can be used to express the capabilities of a given GPU or the desired capabilities of a GPU, for example, when requesting partitions of one or more GPUs to handle GPU processing. According to the described techniques, the GPU abstraction model can include segments for video encoding, video decoding, GPU random access memory (RAM), and GPU compute. Typically, video encoding refers to the GPU's ability to generate encoded video (e.g., MP4) from raw video files, video decoding refers to the GPU's ability to play encoded video and video files (e.g., raw video files), GPU RAM refers to the set of working memory available to the GPU, and GPU compute refers to the amount of work the GPU can perform (e.g., the number of gigaflops of floating-point performance). However, as described below, the described techniques can also be implemented based on a partition abstraction model with different segments, such as a larger number of segments, fewer segments, or segments representing different GPU capabilities.

[0018] Requesting and completing GPU processing can be based at least in part on this model, as requests for GPU partitions and completion notifications are configured based on segments. As an example, a request can be made for a virtual machine configured with a GPU partition that has at least a certain amount of GPU encoding for the virtual machine, at least a certain amount of GPU decoding for the virtual machine, at least a certain amount of GPU RAM for the virtual machine, and at least a certain amount of GPU compute for the virtual machine. Similarly, the host device can notify the requestor (e.g., another virtual machine or client device making the request) of the completion of the same segments provided to the virtual machine by the assigned GPU partition, e.g., a completion notification indicating a certain amount of GPU encoding, GPU decoding, GPU RAM, and GPU compute. The amounts requested and provided in the completion can be constrained by the service agreement. For example, if the requestor has paid for 2.5 gigabytes (GB) of GPU RAM, the host can provide the requestor with a virtual machine with a GPU partition with 2.5 GB of GPU RAM and indicate this in the completion notification. Thus, this example model simplifies the number of GPU processing-related attributes of interest to GPU requesters and providers to four.

[0019] The technology described herein allows a virtual machine to utilize the functionality of a host's GPU via a device driver configured according to a partition abstraction model. To this end, the host maintains device drivers corresponding to the host's GPU. These device drivers are used to determine whether the host's GPU can provide the functionality requested by the client, for example, whether the host's GPU can provide the requested minimum video encoding, video decoding, GPU RAM, and GPU computing. As an example, the device driver can convert a request configured based on the above model into a command specific to the corresponding GPU. Once it is determined that the host's GPU can provide GPU processing that meets the requested capabilities, the virtual machine can be configured with the functionality of the determined GPU. The configured virtual machine can then be exposed to the requesting virtual machine or requesting client.

[0020] Using the techniques described herein, configuring a host device can be simplified because a host provider can select any of a variety of GPUs to configure the host device. This can bring significant efficiencies to systems employing GPU partitioning for virtualization, such as reducing costs (because a host provider can select between different GPU providers), simplifying the interface between a GPU partition requester and the host, reducing device footprint, reducing power consumption, or increasing the speed at which a virtual machine can deliver functionality to a GPU partition requester.

[0021] In the following discussion, an example environment is first described in which the techniques described herein may be employed. Example procedures and implementation details are then described, which may be performed in the example environment as well as other environments. Therefore, performance of the example procedures and details is not limited to the example environment, and the example environment is not limited to performance of the example procedures and details.

[0022] Sample Environment

[0023] Figure 1 An operating environment according to one or more embodiments is generally illustrated at 100. Environment 100 includes a client device 102, a host device 104, and another host device 106. The environment also includes a network 108. Although the illustrated environment 100 includes a client device 102, in some implementations, the described techniques can be used for applications that do not involve client devices. Alternatively, virtual machines 110 of host device 104 can interact with each other (or with virtual machines 110 of another host device 106) via command queues. Such interactions can involve pushing and / or pulling data to a service running locally on one of virtual machines 110.

[0024] In scenarios involving client devices, the client device 102 can be implemented as any suitable device, such as a desktop computer, a smart phone, a tablet computer, a portable computer (e.g., a laptop), a desktop computer, a set-top box, a game console, or a wearable device. Thus, computing devices can range from full resource devices with large amounts of memory and processor resources (e.g., a personal computer, a game console) to low resource devices with limited memory and / or processing resources (e.g., a traditional set-top box, a handheld game console). In addition, although a single computing device is shown, in some cases the computing device can represent multiple different devices, such as multiple servers of a service provider used by a business to perform operations, provide a data center, and the like. Other examples of computing systems and devices suitable for implementing the techniques described herein are described below in conjunction with Figure 7 describe.

[0025] Host device 104 and another host device 106 can be implemented by one or more computing devices, such as one or more servers in a data center, and can also represent one or more entities. According to one or more implementations, host device 104 and another host device 106 can represent the functionality of a service provider to provide one or more services to client device 102 and / or to each other via network 108. Generally, a service provider can make various resources (e.g., content and services) available via network 108. Generally, the resources accessible by a service provider can include any suitable combination of services and / or content that are typically made available by one or more providers via a network. Some examples of services include online gaming services, accelerated rendering services, virtual networking services (e.g., cloud computing), streaming content services, data storage services, search services, email services, instant messaging services, online productivity suites, and authentication services for controlling client access to resources. Content can include various combinations of text, multimedia streams, documents, application files, photos, audio / video files, animations, images, web pages, web applications, device applications, content displayed by a browser or other client application, etc.

[0026] Although network 108 is shown as the Internet, networks can take a variety of configurations. For example, network 108 can include a wide area network (WAN), a local area network (LAN), a wireless network, a public telephone network, and / or an intranet. In addition, although a single network 108 is shown, network 108 can be configured to include multiple networks.

[0027] Host device 104 and another host device 106 are each illustrated as including a virtual machine 110. Virtual machine 110 may be implemented as part of providing the aforementioned services. In addition, virtual machine 110 may be implemented by a virtual machine manager (not shown) of host device 104 and another host device 106. Typically, a virtual machine manager may be capable of managing the creation (referred to herein as "instantiation"), operation, and termination of virtual machine 110. In at least some implementations, the virtual machine manager is configured as an instance of a hypervisor running on the respective host device. Furthermore, virtual machine 110 represents an instance of a virtual machine hosted by the respective host device.

[0028] To enable interaction between the client device 102 and the virtual machine 110, the client device 102 includes an interface 112, which represents functionality for enabling the client device 102 to interface with the host device 104 and / or another host device 106 and with the virtual machine 110. For example, the interface 112 supports functionality for requesting the virtual machine manager to instantiate one of the virtual machines 110 for the client device 102, such as a virtual machine configured with a GPU partition having a requested amount of GPU encoding, GPU decoding, GPU random access memory (RAM), and GPU compute. The interface 112 may also provide other functionality to the client device 102, such as enabling the completion status of a GPU partition request to be determined and / or enabling the request to be manipulated. The interface 112 may also provide a virtual machine graphical interface, for example, which indicates the status of different virtual machines that are visible to the client device 102.

[0029] At some level, the functionality and / or services provided via virtual machine 110 are provided, at least in part, using the actual physical devices of host device 104 and another host device 106. Although device 114 may include a variety of different physical devices to provide a range of functionality, device 114 also includes a GPU 116. GPU 116 represents functionality for processing GPU input data, such as for rendering complex graphics (e.g., high-definition (HD) scenes, three-dimensional (3D) scenes), encoding and decoding video, learning models and neural networks from deep learning datasets, and the like. Thus, GPU 116 represents functionality for performing processing for both rendering and non-rendering scenarios. According to the described techniques, the capabilities of GPU 116 can be described according to a partitioned abstract model. In some implementations, for example, these capabilities can be described by an abstract model that is segmented into a GPU encoding segment, a GPU decoding segment, a GPU RAM segment, and a GPU compute segment.

[0030] In other words, the GPUs 116 can be described in terms of the amount of GPU encoding they can handle, the amount of GPU decoding they can handle, the amount of GPU RAM available, and the amount of GPU compute they can handle. As used herein, the term "GPU encoding" refers to the GPU's ability to generate encoded video (e.g., MP4) from a raw video file. The term "GPU decoding" refers to the GPU's ability to play encoded video and video files (e.g., raw video files). Additionally, the term "GPU RAM" refers to the set of working memory available to the GPU. Finally, the term "GPU compute" refers to the amount of work the GPU is capable of performing, e.g., the number of gigaflops of floating-point performance. Although the technology herein is primarily described with respect to this 4-segment abstract model, a different model with different segments for describing the capabilities of a GPU may also be used without departing from the spirit or scope of the described technology.

[0031] Host device 104 and another host device 106 are each also illustrated as having a GPU partition manager 118. In one or more implementations, GPU partition manager 118 is part of the aforementioned virtual machine manager. According to the described techniques, GPU partition manager 118 can receive a request from a GPU partition requestor (such as one of virtual machines 110 or client device 102) for a GPU partition capable of performing a requested amount of GPU processing. As described above and below, the request can be configured according to a partition abstraction model for GPUs. Continuing with the model being defined as an example with GPU encode, GPU decode, GPU RAM, and GPU compute partitions, the request can be configured to request a certain amount of these capabilities. In one or more implementations, host device 104 and another host device 106 include a GPU driver (not shown), which GPU partition manager 118 utilizes to determine whether one of GPUs 116 with the requested capabilities is available. If GPU partition manager 118 determines that a GPU with the requested capabilities is available, GPU partition manager 118 can configure one of virtual machines 110 to utilize a GPU partition with functionality corresponding to at least a portion of the determined GPU.

[0032] The virtual machine 110 may also be configured with a corresponding driver, or may be configured to identify a corresponding driver, so that the virtual machine 110 can provide data for processing to the assigned partition of the determined GPU. In addition, the corresponding driver enables the virtual machine to manipulate the assigned partition of the GPU to process data and generate data processed by the GPU (e.g., rendered scenes, encoded videos, decoded videos, learned models and neural networks). The GPU partition manager 118 can expose the virtual machine to which the GPU partition is assigned to the GPU partition requester. In some scenarios, the GPU partition manager 118 configures the virtual machine 110 to have a partition with a single GPU 116 as a complete virtual device, so that the functionality of the GPU can be shared between multiple virtual machines 110.

[0033] According to one or more implementations, host device 104 and / or another host device 106 may be configured with a virtual peripheral component interconnect (PCI) infrastructure. In such a scenario, GPU partition manager 118 may use the virtual PCI infrastructure to expose the partitions of GPU 116 to virtual machines 110 in a manner that appears to be a physical GPU (because the partitions are attached to PCI). In doing so, GPU partition manager 118 may expose the partitions of the GPU by presenting virtual devices in a manner that emulates PCI Express (PCIe) devices. Furthermore, this allows the same operating system infrastructure to be utilized for configuration and driver loading associated with utilizing GPU partitions.

[0034] By accessing GPU functionality according to the described partition abstraction model for GPUs, virtual machines 110 can utilize different GPUs 116. For example, this allows GPU-processed workloads to be mapped to different GPUs and / or differently configured partitions of the same GPU. In addition, virtual machines 110 are not associated with any specific GPU of a host provided by a specific GPU provider, and the host is also not associated with a GPU from a specific GPU provider. This enables virtual machines 110 to switch between different GPUs and different partitions of a GPU, for example, based on the availability of GPU capabilities.

[0035] Having described an example operating environment, consider now example details and techniques associated with one or more implementations.

[0036] Graphics processing unit partitioning for virtualization

[0037] For further illustration, consider the discussion in this section of example scenarios, components, and processes that can be used to partition a graphics processing unit (GPU) for virtualization. Generally, the functions, features, and concepts described with respect to the above and following examples can be employed in the context of the example processes described below. Furthermore, the functions, features, and concepts described with respect to the different figures and examples in this document are interchangeable with each other and are not limited to implementation in the context of a particular figure or process. Furthermore, the blocks associated with the different representative processes and corresponding figures herein can be applied together and / or combined in different ways. Therefore, the individual functions, features, and concepts described with respect to the different example environments, devices, components, figures, and processes herein can be used in any suitable combination and are not limited to the specific combinations represented by the examples listed in this specification.

[0038] Example partitioning abstraction model for GPUs

[0039] Figure 2 An example abstract model of a graphics processing unit (GPU) for partitioning the GPU for virtualization according to one or more implementations is depicted generally at 200. Example 200 depicts a GPU abstract model 202 including segments for video encoding 204, video decoding 206, GPU RAM 208, and GPU compute 210.

[0040] In general, GPU abstraction model 202 is used to describe the capabilities of a GPU. Given the depicted GPU abstraction model 202, for example, a GPU is described in terms of video encoding and decoding capabilities, the amount of GPU RAM, and GPU compute capabilities. Furthermore, GPU abstraction model 202 governs how requests for GPU processing and completion notifications are configured. By way of example, GPU abstraction model 202 defines parameters that a GPU partition requester may specify when requesting GPU processing associated with one of virtual machines 110. Referring to the depicted GPU abstraction model 202, for example, a request for GPU processing may be configured to request a GPU partition with a specified amount of video encoding capability, a specified amount of video decoding capability, a specified amount of GPU RAM, and a specified amount of GPU compute capabilities. In addition to allowing requests for values ​​of specified parameters, host device 104 or another host device 106 may specify values ​​that define the GPU partitions that may be requested. By way of example, host device 104 may define a "GPU 1" partition that may be requested. For example, rather than forming a request with specific capabilities, a GPU partition requester may simply configure the request with an identifier corresponding to GPU 1. Host device 104 may define the requestable GPU partitions, for example, by specifying the amount of GPU encoding capability, the amount of video decoding capability, the amount of GPU RAM, and the amount of GPU compute capability to be allocated to the GPU.

[0041] Although in one or more implementations Figure 2 The model depicted in

[0045] can manage the assignment of GPU 116 partitions to virtual machines 110, but GPU partition assignment can also be managed based on a different GPU abstraction model without departing from the spirit or scope of the techniques described herein. For example, a GPU abstraction model with 5 segments, 32 segments, or segments representing different capabilities can be used to manage GPU partition assignment to virtual machines.

[0042] Regardless of the specific segments specified for the GPU abstraction model 202, the segments of the GPU abstraction model 202 can also be used to configure the driver corresponding to the GPU 116. Specifically, the GPU abstraction model 202 provides GPU developers with an indication of the inputs to be received by their corresponding GPU drivers in connection with GPU processing (e.g., the format of requests). The GPU abstraction model 202 also provides GPU developers with an indication of the outputs expected from their corresponding GPU drivers in connection with GPU processing (e.g., the format of completion notifications).

[0043] In an implementation where the depicted abstract model is used to define interactions between client devices, host devices, virtual machines, GPUs, and GPU partition manager 118, the depicted segments can represent the capabilities of the GPU in a manner similar to that discussed above. Specifically, the video encoding 204 segment can represent the GPU's ability to generate encoded video (e.g., MP4) from a raw video file. The video decoding 206 segment can represent the GPU's ability to play both encoded video and video files (e.g., raw video files). The GPU RAM 208 segment can represent the amount of working memory available to the GPU. Furthermore, the GPU compute 210 segment can represent the amount of work the GPU is capable of performing (e.g., the number of floating-point operations per second). Furthermore, a GPU partition can be configured with GPU resources per segment such that the GPU partition has a certain amount of video encoding capability, video decoding capability, GPU RAM, and GPU compute capability.

[0044] Example scenario

[0045] Figure 3 An example scenario is generally depicted at 300 in which a host's GPU is assigned to a virtual machine to deliver requested GPU processing according to one or more implementations. Example scenario 300 includes Figure 1 The virtual machine 110, GPU 116 and GPU partition manager 118 are configured as follows.

[0046] The example scenario 300 also includes a GPU partition request 302, which represents a request from a GPU partition requester (e.g., one of the virtual machines 110 or a client device 102) for one of the virtual machines 110 to be configured with a GPU partition capable of performing the requested amount of GPU processing. In particular, the GPU partition request 302 requests GPU partitioning from the perspective of the GPU abstraction model 202, as described with respect to FIG. Figure 4A 106 . As described in more detail, a GPU partition request 302 may be received by the GPU partition manager 118 from a GPU partition requester. Based on the GPU partition request 302, the GPU partition manager 118 may query 304 a GPU driver 306 to determine whether one of the virtual machines can utilize any GPU 116 (or portions thereof) to satisfy the request. The GPU driver 306 is illustrated as being stored in a storage device 308, which may be included as part of the host device 104, another host device 106, or a trusted remote storage service, for example. When queried by the GPU partition manager 118, the GPU driver 306 is configured to execute in memory, for example, of the host device 104 or another host device 106.

[0047] The GPU driver 306 represents functionality for receiving GPU partition requests configured according to the GPU abstraction model 202. The GPU driver 306 also represents functionality for converting the parameters of those requests into a format specific to the corresponding GPU 116 for use in determining whether the corresponding GPU has the requested capabilities available or whether a partition of the corresponding GPU can be configured with the requested capabilities. The GPU driver 306 is also configured to convert availability information provided by the corresponding GPU into completion information configured according to the GPU abstraction model 202. In addition, the GPU driver 306 enables a partition of the corresponding GPU to provide GPU processing when determined to be available and assigned to a virtual machine.

[0048] In any case, based on query 304, GPU partition manager 118 determines which GPUs 116, if any, are available to satisfy GPU partition request 302. If one or more of GPUs 116 are determined to be available, GPU partition manager 118 allocates GPU partitions corresponding to at least a portion of the available GPUs to virtual machine 110 to be exposed to the GPU partition requester. This allocation is represented by VM allocation 310. VM allocation 310 may involve configuring virtual machine 110 with GPU partitions corresponding to the allocated GPUs 116, including configuring the virtual machine with corresponding GPU drivers 306 to enable interaction between virtual machine 110 and the GPU partitions.

[0049] In one or more implementations, VM allocation 310 may involve allocating less than an entire single GPU 116 to a virtual machine as a GPU partition. Consider an example in which GPU partition request 302 requests a virtual machine with a GPU partition of at least 2.5 gigabytes (GB) of GPU RAM, but in which each GPU 116 has at least 10 GB of GPU RAM. In this example, GPU partition manager 118 may allocate a portion of one of GPUs 116 (e.g., one-quarter of one of GPUs 116) for the GPU partition and configure virtual machine 110 to utilize the partition. GPU partition manager 118 may do this by generating a virtual device with the GPU partition that emulates a full physical GPU device to virtual machine 110. The virtual device allows multiple virtual machines 110 to simultaneously utilize the functionality of a single GPU 116. Exposing the functionality of GPU 116 to virtual machines 110 as a virtual device also allows GPU partition manager 118 to configure the virtual machine with functionality provided by partitions of multiple GPUs 116, e.g., multiple GPUs of a single host or multiple GPUs of different hosts.

[0050] In conjunction with the VM allocation 310, the GPU partition manager 118 is configured to provide a GPU completion notification 312 to the GPU partition requester. The GPU completion notification 312 is configured to indicate to the GPU partition requester the extent to which the GPU partition request 302 can be satisfied. As an example, if the GPU partition request 302 requests a virtual machine with a GPU partition that has at least 2.5 GB of GPU RAM, and if the GPU partition manager 118 determines that a GPU with 5 GB of GPU RAM is available and allocates at least a portion of that GPU to the partition to fulfill the request, the GPU completion notification 312 may indicate that the virtual machine was exposed with a GPU partition that has at least 2.5 GB of GPU RAM and up to 5 GB of RAM. As described above, the requested capabilities and the capabilities used to fulfill the GPU partition request 302 may be governed by a service agreement. For example, if a user of the client device 102 has paid for a service that includes 2.5 GB of GPU RAM, the GPU partition manager 118 allocates the resources of the GPU 116 corresponding to the 2.5 GB of GPU RAM regardless of the amount of GPU RAM requested. As described with respect to Figure 4B As discussed, the format of the GPU completion notification 312 may also be based on the GPU abstraction model 202 .

[0051] Based on the allocation of GPU 118 (or at least a portion of the GPU) to configure the virtual machine with a GPU partition, the GPU partition can be used to process GPU input data for the virtual machine. GPU input data 314 represents data provided to the partition of GPU 116 for GPU processing. As an example, GPU input data 314 can represent a video data stream received via network 108, which will be processed for output via the virtual machine and ultimately via client device 102. Examples of GPU input data include streaming television data streams, streaming movie streams, data for cloud-hosted video game environments, raw video, and deep learning datasets. The illustrated scene 300 also includes GPU-processed data 316, which represents data output by the partition of GPU 116 based on processing GPU input data 314. In some cases, GPU-processed data 316 may include information that can be output for display. However, GPU-processed data 316 may also be configured as non-graphical data. Examples of GPU-processed data 316 include television programs, movies, and video game scenes, as well as models and neural networks learned from deep learning datasets, encoded video, and data that is processed at an accelerated rate by GPU 116 relative to other processors. The interaction between a partition of GPU 116 and virtual machine 110 can involve the transfer of various information and / or instructions without departing from the spirit or scope of the techniques described herein.

[0052] Example GPU partition request and completion notification

[0053] Figure 4A and Figure 4B An example of a configuration for GPU partition request and completion notification according to one or more implementations is depicted generally at 400. In particular, Figure 4A depicts a GPU partition request 302, and Figure 4B A GPU completion notification 312 is depicted. In the illustrated example, the GPU partition request 302 and the GPU completion notification 312 are based on Figure 2 The GPU abstract model 202 is formatted.

[0054] The GPU partition request 302 is formatted according to the GPU abstract model 202, including video encoding parameters 402, video decoding parameters 404, GPU RAM parameters 406, and GPU compute parameters 408. According to one or more implementations, the GPU partition requester may specify, for each capability represented by the abstract model, a minimum requested amount, a maximum requested amount, and a preferred amount of that capability. For example, one of the virtual machines 110 or the client device 102 may request, via the GPU partition request 302, a virtual machine 110 with a GPU partition having at least 2.5 GB of GPU RAM, but no more than 10 GB of GPU RAM, and preferably 5 GB of GPU RAM. Thus, each parameter of the GPU partition 302 request is depicted as having a minimum, preferred, and maximum requested value.

[0055] The video encoding parameters 402 of the GPU partition request 302 include a minimum requested video encoding 410, a preferred requested video encoding 412, and a maximum requested video encoding 414. The video decoding parameters 404 of the GPU partition request 302 include a minimum requested video decoding 416, a preferred requested video decoding 418, and a maximum requested video decoding 420. The GPU RAM parameters 406 of the GPU partition request 302 include a minimum requested RAM 422, a preferred requested RAM 424, and a maximum requested RAM 426. The GPU compute parameters 408 of the GPU partition request 302 include a minimum requested compute 428, a preferred requested compute 430, and a maximum requested compute 432.

[0056] Similar to GPU partition request, Figure 4B The GPU completion notification 312 depicted in FIG is formatted according to the GPU abstract model, including video encoding parameters 434, video decoding parameters 436, GPU RAM parameters 438, and GPU compute parameters 440. According to one or more implementations, values ​​are specified to indicate the extent to which each capability represented by the abstract model is configured to be completed by the assigned GPU partition. The extent of completion is expressed in terms of a minimum amount of the capability to be completed, a preferred amount of the capability to be completed, and a maximum amount of the capability to be completed. For example, the parameters may indicate that a virtual machine configured with a GPU partition having at least 2.5 GB of GPU RAM, but no more than 10 GB of GPU RAM, and preferably 5 GB of GPU RAM, will be provided to the partition requester. As described above, the extent to which the GPU partition request 302 is completed may be governed by a service agreement. Thus, the minimum amount, maximum amount, and preferred amount may be predetermined. In particular, the minimum amount and maximum amount may have the same value.

[0057] The video encoding parameters 434 of the GPU completion notification 312 include minimum completed video encoding 442, preferred completed video encoding 444, and maximum completed video encoding 446. The video decoding parameters 436 of the GPU completion notification 312 include minimum completed video decoding 448, preferred completed video decoding 450, and maximum completed video decoding 452. The GPU RAM parameters 438 of the GPU completion notification 312 include minimum completed RAM 454, preferred completed RAM 456, and maximum completed RAM 458. The GPU compute parameters 440 of the GPU completion notification 312 include minimum completed compute 460, preferred completed compute 462, and maximum completed compute 464.

[0058] Figure 4A and Figure 4B The example configuration depicted in the example is specific to Figure 2 . In implementations where the GPU abstract model 202 is segmented differently to represent the capabilities of the GPU, the GPU partition request 302 and the GPU completion notification 312 can be configured differently depending on how the model is segmented. Furthermore, in scenarios where the GPU abstract model 202 is used, the GPU partition request 302 and the GPU completion notification 312 can include additional information without departing from the spirit or scope of the techniques described herein. In some implementations, the values ​​of the parameters can be indicated in the form of a vector. Additional examples and details are discussed with respect to the example procedures below.

[0059] Example Process

[0060] about Figure 5 and Figure 6 Other aspects of GPU partitioning for virtualization are discussed in detail in the example procedures of FIG. 1 . These procedures are represented as a set of blocks that specify operations performed by one or more devices and are not necessarily limited to the order shown for performing the operations by the respective blocks. Aspects of these procedures may be implemented in hardware, firmware, or software, or a combination thereof. Some aspects of these procedures may be implemented via one or more host devices, such as host device 104 and / or another host device 106, which maintains and provides access to GPU partition manager 118.

[0061] Figure 5 Depicted is an example process 500 for assigning a GPU of a host machine to a virtual machine according to one or more implementations.

[0062] At 502, a request is obtained from a client device for a virtual machine configured with a GPU partition. In accordance with the principles discussed herein, the request requests a virtual machine with a GPU partition having capabilities specified according to a partition abstraction model. As an example, the GPU partition manager 118 obtains the GPU partition request 302 from a GPU partition requester (e.g., one of the virtual machines 110 or the client device 102). In addition, the GPU partition request requests one of the virtual machines 110 configured with a partition having the functionality of one of the GPUs 116 or at least a portion of one of the GPUs 116. The GPU partition request 302 is also configured according to the GPU abstraction model 202. For example, referring to Figure 4A , the GPU partition request 302 specifies minimum, preferred, and maximum values ​​for each of the video encoding parameters 402 , the video decoding parameters 404 , the GPU RAM parameters 406 , and the GPU compute parameters 408 .

[0063] At 504, the host's GPU driver is queried to determine whether any of the host's GPUs are available to satisfy the request. As an example, GPU partition manager 118 queries 304 GPU driver 306 to determine whether any of the GPUs 116 of host device 104 or another host device 106 are available to satisfy GPU partition request 302. In one or more implementations, this involves passing GPU partition request 302 to GPU driver 306 so that GPU driver 306 can determine whether the corresponding GPU 116 is capable of providing the requested capabilities.

[0064] At 506, in response to determining that at least a portion of the GPU is available to satisfy the request, the determined portion of the GPU is allocated to the virtual machine. For example, GPU partition manager 118 determines at 504 that at least a portion of one of GPUs 116 is available to satisfy GPU partition request 302. In response to this determination, GPU partition manager 118 allocates the determined available portion of the GPU to a GPU partition. One of virtual machines 110 is then configured with the GPU partition. As described above, a GPU partition can correspond to a portion of one of GPUs 116, the entire GPU 116, at least a portion of multiple GPUs 116, and so on. A GPU partition can also correspond to multiple GPUs 116 across host device 104 and another host device 106.

[0065] At 508, a completion notification is transmitted to the client device, indicating the extent to which the request was completed. In accordance with the principles discussed herein, the completion notification is formatted based on the partition abstraction model. As an example, the GPU partition manager 118 transmits a GPU completion notification 312 to the GPU partition requester. As described above, the GPU completion notification 312 indicates the extent to which the GPU partition request 302 was completed. The GPU completion notification 312 is also formatted based on the GPU abstraction model 202. For example, the GPU completion notification 312 specifies the minimum, preferred, and maximum capacity amounts to be provided, such as the amount of capacity required for the GPU partition request 302 to be completed. Figure 4B 16. As described in more detail below, it should also be understood that in some scenarios, a portion of GPU 116 may not be available to fulfill a request. Regardless of whether GPU 116 is able to fulfill the requested capacity, a completion notification may be transmitted to the client device—in the case where the GPU may not be available to fulfill the request, the completion notification may indicate that the request could not be completed at all or that the GPU partition may be configured to partially complete the request.

[0066] At 510, the virtual machine configured with the allocated portion of the GPU is exposed to the GPU partition requester. As an example, at 506, one of the virtual machines 110 configured with a GPU partition having the functionality of one (or at least a portion) of the GPUs 116 is exposed to a different one of the virtual machines 110 or the client device 102.

[0067] Figure 6 Depicted is an example process 600 for a virtual machine to utilize a virtual device to take advantage of functionality provided by an allocated portion of a host GPU in accordance with one or more implementations.

[0068] At 602, a request is received at a virtual device input from a virtual machine. According to the principles discussed herein, the request requests GPU processing provided by a GPU partition corresponding to a portion of a host GPU assigned to the virtual machine. As an example, a request is received at an input of a virtual device (not shown) from one of the virtual machines 110. The received request requests GPU processing provided by a GPU 116 of a portion of a host device 104 or another host device 106 assigned to the virtual machine 110 as a GPU partition.

[0069] At 604, a data input / output (I / O) hardware workqueue of the GPU associated with the virtual device input is determined. According to the principles discussed herein, the data I / O hardware workqueue of the GPU is determined based on a mapping of the virtual device inputs and outputs to the corresponding inputs and outputs of the GPU's data I / O hardware workqueue. As an example, one of the GPU drivers 306 determines a data I / O hardware workqueue of a partition of the GPU 116 associated with the virtual device input. The device driver makes this determination by referencing the mapping of the virtual device's inputs and outputs to the corresponding data I / O hardware workqueues of the GPU partition. As used herein, a "data I / O hardware workqueue" refers to a hardware connection of the GPU 116 that accepts GPU input data 314 to perform graphics processing. Some of these hardware connections can also output GPU-processed data 316. In any case, the data I / O hardware workqueue is distinct from the control workqueue, which controls the operation of the GPU 116, such as resetting it due to a detected error.

[0070] At 606, the data included with the request is provided to the allocated portion of the GPU via the determined data I / O hardware work queue. This enables the GPU partition to use the provided data for GPU processing, in accordance with the principles discussed herein. As an example, GPU input data 314 is included with the request obtained at 602. In this example, GPU input data 314 is provided to the data I / O hardware work queue determined at 604. This allows the partition of GPU 116 to process GPU input data 314.

[0071] At 608, the virtual device retrieves GPU-processed data from the GPU. GPU-processed data is generated as a result of GPU processing, according to the principles discussed herein. For example, the GPU 116 corresponding to the GPU partition processes GPU input data 314 to generate GPU-processed data 316. GPU-processed data 316 may correspond to a television program, a movie, video game graphics, a model or neural network learned from a deep learning dataset, accelerated rendering, and the like. In any case, the virtual device retrieves GPU-processed data 316 from the GPU partition. At 610, the GPU-processed data is output from the virtual device to the virtual machine. For example, the GPU-processed data 316 retrieved at 608 is output by the virtual device to one of the virtual machines 110.

[0072] Having described example procedures and details in accordance with one or more implementations, consider now a discussion of example systems and devices that can be used to implement the various techniques described herein.

[0073] Example systems and devices

[0074] Figure 7 An example system 700 is illustrated that includes an example computing device 702, which represents one or more computing systems and / or devices that can implement the various techniques described herein. Computing device 702 can be, for example, a server of a service provider, a device associated with a client (e.g., a client device), a system on a chip, and / or any other suitable computing device or computing system.

[0075] The example computing device 702 shown in the figure includes a processing system 704, one or more computer-readable media 706, and one or more I / O interfaces 708 coupled to each other in communication. Although not shown, the computing device 702 may also include a system bus or other data and command transmission system that couples various components to each other. The system bus may include any one or a combination of different bus structures utilizing any of the various bus architectures, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and / or a processor or local bus. Various other examples are also contemplated, such as control and data lines.

[0076] Processing system 704 represents functionality that performs one or more operations using hardware. Thus, processing system 704 is illustrated as including hardware elements 710 that may be configured as processors, functional blocks, and the like. This may include hardware implementations as application-specific integrated circuits or other logic devices formed using one or more semiconductors. Hardware elements 710 are not limited by the materials from which they are formed or the processing mechanisms employed therein. For example, a processor may include (a plurality of) semiconductors and / or transistors (e.g., an electronic integrated circuit (IC)). In such a context, processor-executable instructions may be electronically executable instructions.

[0077] Computer-readable media 706 is illustrated as including memory / storage 712. Memory / storage 712 represents memory / storage capacity associated with one or more computer-readable media. Memory / storage 712 can include volatile media (such as random access memory (RAM)) and / or non-volatile media (such as read-only memory (ROM), flash memory, optical disks, or magnetic disks). Memory / storage 712 can include fixed media (e.g., RAM, ROM, fixed hard drive) and removable media (e.g., flash memory, removable hard drive, or optical disk). Computer-readable media 706 can be configured in various other ways, as further described below.

[0078] (Multiple) input / output interface(s) 708 represent functionality that allows a user to input commands and information to the computing device 702 and also allows information to be presented to the user and / or other components or devices using various input / output devices. Examples of input devices include a keyboard, a cursor control device (e.g., a mouse), a microphone for voice operation, a scanner, touch functionality (e.g., a capacitive or other sensor configured to detect physical touch), and a camera (e.g., which may employ visible or invisible wavelengths such as infrared frequencies to detect movement that does not involve touch as a gesture). Examples of output devices include a display device (e.g., a monitor or projector), a speaker, a printer, a network card, and a tactile response device. Thus, the computing device 702 can be configured in various ways, as further described below, to support user interaction.

[0079] Various techniques may be described herein in the general context of software, hardware elements, or program modules. Typically, such modules include routines, programs, objects, elements, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The terms "module," "function," and "component" as used herein generally refer to software, firmware, hardware, or a combination thereof. The techniques described herein are characterized as platform-independent, meaning that these techniques can be implemented on a variety of commercial computing platforms with a variety of processors.

[0080] The implementation of the described modules and techniques may be stored on or transmitted via some form of computer-readable media. Computer-readable media may include various media that can be accessed by the computing device 702. By way of example, computer-readable media may include “computer-readable storage media” and “communication media.”

[0081] "Computer-readable storage media" refers to media and / or devices capable of storing information, as opposed to mere signal transmissions, carrier waves, or the signals themselves. Computer-readable storage media do not include signal-bearing media, transient signals, or the signals themselves. Computer-readable storage media include hardware implemented in a method or technology suitable for storing information such as computer-readable instructions, data structures, program modules, logic elements / circuits, or other data, such as volatile and non-volatile, removable and non-removable media and / or storage devices. Examples of computer-readable storage media may include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, hard disks, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other storage devices, tangible media, or articles of manufacture suitable for storing desired information and which can be accessed by a computer.

[0082] "Communication media" may refer to signal-bearing media configured to transmit instructions to the hardware of computing device 702, such as via a network. Communication media typically may contain computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave, data signal, or other transport mechanism. Communication media also includes any information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media.

[0083] As previously mentioned, hardware element 710 and computer-readable medium 706 represent instructions, modules, programmable device logic and / or fixed device logic implemented in hardware form that can be used to implement at least some aspects of the technology described herein in some embodiments. Hardware element can include components of other implementations of integrated circuits or systems on a chip, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs) and silicon or other hardware devices. In this context, hardware element can be used as a processing device for performing program tasks defined by instructions, modules and / or logic implemented by hardware element and a hardware device (e.g., computer-readable storage medium described previously) for storing instructions for execution.

[0084] Combinations of the foregoing may also be employed to implement the various techniques and modules described herein. Thus, software, hardware, or program modules, including the GPU partition manager 118 and interface 112, and other program modules, may be implemented as one or more instructions and / or logic implemented on some form of computer-readable storage medium and / or implemented by one or more hardware elements 710. The computing device 702 may be configured to implement specific instructions and / or functionality corresponding to the software and / or hardware modules. Thus, an implementation of a module as a module executable by the computing device 702 as software may be at least partially implemented in hardware, for example, by using a computer-readable storage medium and / or hardware elements 710 of a processing system. The instructions and / or functionality may be executable / operable by one or more articles of manufacture (e.g., one or more computing devices 702 and / or processing systems 704) to implement the techniques, modules, and examples described herein.

[0085] like Figure 7 As further shown in the example system 700, a ubiquitous environment enables a seamless user experience when running applications on a personal computer (PC), a television device, and / or a mobile device. Services and applications run substantially similarly in all three environments, so that a common user experience is achieved when transitioning from one device to the next when using an application, playing a video game, watching a video, etc.

[0086] In the example system 700, multiple devices are interconnected through a central computing device. The central computing device can be local to the multiple devices or can be remote from the multiple devices. In one embodiment, the central computing device can be a cloud of one or more server computers connected to the multiple devices via a network, the Internet, or other data communication link.

[0087] In one embodiment, this interconnected architecture enables functionality to be delivered across multiple devices to provide a common and seamless experience to users of the multiple devices. Each of the multiple devices may have different physical requirements and capabilities, and the central computing device uses the platform to deliver an experience to the devices that is both device-specific and common to all devices. In one embodiment, a class of target devices is created, and the experience is customized for a general class of devices. A class of devices can be defined by physical characteristics, usage type, or other common characteristics of the devices.

[0088] In various implementations, computing device 702 can be implemented in a variety of different configurations, such as different configurations for use with a computer 714, a mobile device 716, and a television 718. Each of these configurations includes devices that can have generally different builds and capabilities, and thus computing device 702 can be configured according to one or more different device classes. For example, computing device 702 can be implemented as a device in the computer 714 class, which includes personal computers, desktop computers, multi-screen computers, laptop computers, and netbooks.

[0089] The computing device 702 may also be implemented as a mobile device 716 class device, including mobile devices such as mobile phones, portable music players, portable gaming devices, tablet computers, or multi-screen computers. The computing device 702 may also be implemented as a television 718 class device, which includes devices with or connected to generally larger screens in casual viewing environments. These devices include televisions, set-top boxes, and game consoles.

[0090] The techniques described herein can be supported by these various configurations of computing device 702 and are not limited to the specific examples of the techniques described herein. For example, the functionality of GPU partition manager 118 and other modules can also be implemented in whole or in part using a distributed system, such as through the "cloud" 720 via platform 722, as described below. GPU partition manager 118 can also be implemented by a host device of platform 722, such as one or more servers in a data center. GPU partition manager 118 can also be implemented by an individual computing device 702 or host as described herein.

[0091] The cloud 720 includes and / or represents a platform 722 for resources 724. The platform 722 abstracts the underlying functionality of the hardware (e.g., servers) and software resources of the cloud 720. The resources 724 may include applications and / or data that can be utilized while computer processing is executed on a server remote from the computing device 702. The resources 724 may also include services provided over the Internet and / or over a subscriber network (such as a cellular or Wi-Fi network). The services may include virtualized services implemented via a suitably configured virtual machine manager module (such as a virtual machine manager module including the GPU partition manager 118).

[0092] The platform 722 can abstract resources and functionality to connect the computing device 702 with other computing devices. The platform 722 can also be used to abstract the scaling of resources to provide corresponding levels of scale to meet the needs of resources 724 implemented via the platform 722. Therefore, in an interconnected device embodiment, the implementation of the functionality described herein can be distributed throughout the system 700. For example, the functionality can be implemented partially on the computing device 702 and via the platform 722 that abstracts the functionality of the cloud 720.

[0093] Example Implementation

[0094] Example implementations of the techniques described herein include, but are not limited to, one or any combination of the following examples:

[0095] Example 1. A method implemented by a host device, the method comprising: obtaining a request for a virtual machine having a graphics processing unit (GPU) function from a GPU partition requester, the GPU function being represented by a model having multiple segments representing different GPU capabilities, and the request requesting the GPU function by specifying the different GPU capabilities; in response to determining that at least a portion of the GPU is available for providing the GPU function, allocating the determined available portion of the GPU to the virtual machine to configure the virtual machine as having a GPU partition with the GPU function; and exposing the virtual machine having the GPU partition with the GPU function to the GPU partition requester.

[0096] Example 2. A method as described in Example 1, wherein the plurality of segments include at least one of: a video encoding segment representing the GPU's ability to generate encoded video from raw video; a video decoding segment representing the GPU's ability to play encoded video and video files; a GPU random access memory (RAM) segment representing the amount of memory available to the GPU; or a GPU compute segment representing the amount of GPU processing that the GPU can perform.

[0097] Example 3. The method as described in Example 1, wherein the request specifies at least one of: a minimum amount for each of the different GPU capabilities; a preferred amount for each of the different GPU capabilities; or a maximum amount for each of the different GPU capabilities.

[0098] Example 4. The method of Example 1 further comprises transmitting a completion notification to the GPU partition requestor, the completion notification indicating the extent to which the GPU partition meets the specified GPU capabilities.

[0099] Example 5. A method as described in Example 4, wherein the completion notification specifies at least one of the following: a minimum amount of each of the different GPU capabilities to be provided with the GPU partition; a preferred amount of each of the different GPU capabilities to be provided with the GPU partition; and a maximum amount of each of the different GPU capabilities to be provided with the GPU partition.

[0100] Example 6. The method as described in Example 1, wherein configuring the virtual machine to have GPU partitioning enables the virtual machine to provide GPU input data to the allocated portion of the GPU, and enables the allocated portion of the GPU to process the GPU input data to provide GPU-processed data to the virtual machine.

[0101] Example 7. The method of example 6, wherein configuring the virtual machine to have GPU partitioning includes generating a virtual device to provision the GPU functionality of the allocated portion of the GPU to the virtual machine.

[0102] Example 8. The method of Example 6, further comprising mapping inputs and outputs of the virtual device to corresponding data input / output (I / O) hardware work queues of the allocated portion of the GPU.

[0103] Example 9. The method of Example 1, wherein the GPU partition requesters include different virtual machines or client devices.

[0104] Example 10. The method of example 1, wherein determining comprises querying a GPU driver maintained by the host device whether the corresponding GPU meets the specified GPU capabilities.

[0105] Example 11. The method of example 1, wherein the allocation is based on a service agreement that defines an amount of different GPU capabilities that the GPU partition requestor is allowed, and the allocated portion of the GPU provides GPU functionality to the GPU partition in the defined amount.

[0106] Example 12. A host device comprising: a graphics processing unit (GPU) to supply GPU functionality; a GPU model to represent GPU functionality using multiple segments indicating different GPU capabilities; a GPU driver to indicate GPU functionality provided by a corresponding GPU based on different GPU capabilities; a processor; and a computer-readable medium storing instructions executable by the processor to implement a GPU partition manager to perform operations including: determining whether at least a portion of the GPU is capable of processing a request for GPU functionality by querying the GPU driver whether the corresponding GPU has different GPU capabilities specified in the request; allocating the determined portion of the GPU to a virtual machine to configure the virtual machine to have a GPU partition with GPU functionality; and exposing the virtual machine to a GPU partition requester that sent the request.

[0107] Example 13. The host device of Example 12, wherein the operations further comprise transmitting a completion notification to the GPU partition requestor, the completion notification indicating the extent to which the GPU partition has the different GPU capabilities specified in the request.

[0108] Example 14. The host device of Example 12, wherein the operations further comprise: determining that the GPU cannot process the additional request for the GPU function; and transmitting a completion notification to the device GPU partition requestor that sent the additional request, the completion notification indicating that the additional request was not completed.

[0109] Example 15. A host device as described in Example 12, wherein the plurality of segments include: a video encoding segment representing the GPU's ability to generate encoded video from raw video; a video decoding segment representing the GPU's ability to play encoded video and video files; a GPU random access memory (RAM) segment representing the amount of memory available to the GPU; and a GPU compute segment representing the amount of GPU processing that the GPU is capable of performing.

[0110] Example 16. A host device as described in Example 12, wherein the request specifies: a minimum amount for each of the different GPU capabilities; a preferred amount for each of the different GPU capabilities; and a maximum amount for each of the different GPU capabilities.

[0111] Example 17. A method implemented by a host device, the method comprising: receiving, at an input of a virtual device, a request from a virtual machine requesting a GPU function supplied by a portion of a GPU assigned to the virtual machine; determining, based on a mapping of the virtual device input to the data input / output (I / O) hardware work queues of the GPU portion, a data I / O hardware work queue of the GPU portion associated with the input of the virtual device; providing GPU input data included with the request to the GPU portion via the determined data I / O hardware work queue, so that the GPU portion can use the provided GPU input data to supply the requested GPU function; obtaining, by the virtual device, GPU-processed data from the GPU portion, the GPU-processed data being generated by the GPU function supplied by the GPU portion; and outputting, by the virtual device, the GPU-processed data to the virtual machine.

[0112] Example 18. The method of Example 17, further comprising allocating the GPU portion to the virtual machine to supply at least the requested GPU functionality to the virtual machine.

[0113] Example 19. The method of Example 17, wherein the GPU portion is allocated to the virtual machine based on a GPU request identifying a GPU partition defined by the host device according to a model having a plurality of segments representing different GPU capabilities.

[0114] Example 20. The method of Example 17, wherein the GPU-processed data is provided to a GPU partition requestor to which the virtual machine is exposed.

[0115] in conclusion

[0116] Although the technology has been described in language specific to structural features and / or methodological acts, it should be understood that the technical solutions defined in the appended claims are not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the claimed technical solutions.

Claims

1. A method implemented by a host device having a graphics processing unit (GPU), the method comprising: receiving, at the host device, a request for a virtual machine having a GPU capability, the request including data indicating a requested amount of GPU capability of the GPU capability, the GPU capability being one of a video encoding capability, a video decoding capability, or a GPU compute capability; upon receiving the request, determining whether the GPU of the host device is available to provide the requested amount of the GPU power; In response to determining that the GPU of the host device is available to provide the requested amount of GPU capability, allocating an available portion of the GPU functionality of the GPU of the host device to the virtual machine, and configuring the virtual machine with a GPU partition having the requested amount of GPU capability; as well as In response to the received request, access to the virtual machine of the GPU partition having the requested amount of the GPU capability is provided.

2. The method according to claim 1, wherein: Receiving the request includes receiving a request including data indicating requested amounts of at least two of the video encoding capability, the video decoding capability, or the GPU compute capability; as well as Determining whether the GPU of the host device is available includes determining whether the GPU of the host device is available to provide the requested amount of at least two of the video encoding capability, the video decoding capability, or the GPU computing capability.

3. The method of claim 1 , wherein the data of the request specifies: The minimum amount of individual GPU power; The preferred amount of individual GPU power; or The maximum amount of individual GPU capabilities. 4 . The method of claim 1 , further comprising transmitting a completion notification indicating the extent to which the GPU partition satisfied the requested GPU capabilities.

5. The method of claim 4, wherein the completion notification specifies at least one of the following: the minimum amount of individual GPU power to be provided to the GPU partition; a preferred amount of individual GPU power to provide to the GPU partition; or The maximum amount of individual GPU power to provide to this GPU partition.

6. The method of claim 1 , further comprising providing GPU input data from the virtual machine to the allocated portion of the GPU functionality of the GPU, and receiving GPU-processed data at the virtual machine, the GPU-processed data generated by the GPU processing the GPU input data. 7 . The method of claim 6 , wherein configuring the virtual machine with the GPU partition comprises generating a virtual device to supply the allocated portion of the GPU functionality of the GPU to the virtual machine.

8. The method of claim 6, further comprising mapping inputs and outputs of virtual devices to corresponding data input / output (I / O) hardware work queues of the allocated portion of the GPU function of the GPU.

9. The method of claim 1, wherein receiving the requested amount of the GPU capability comprises a requested amount of video encoding capability.

10. The method of claim 1, wherein the GPU capability of receiving the requested amount of the GPU function comprises a requested amount of video decoding capability.

11. The method of claim 1, wherein receiving the requested amount of the GPU capability comprises a requested amount of GPU compute capability.

12. A host device, comprising: A graphics processing unit (GPU) configured to provide one or more GPU capabilities to the GPU function; a GPU driver for indicating the GPU function provided by the GPU based on the one or more GPU capabilities; processor; as well as a memory having instructions stored thereon, the instructions being executable by the processor to cause the host device to: upon receiving a request specifying an amount of the individual one or more GPU capabilities of the GPU function, determining whether the GPU can service the request by querying the GPU driver as to whether the GPU has a sufficient amount of the one or more GPU capabilities specified in the request; After determining that the GPU is capable of servicing the request, allocating a portion of the GPU functionality of the GPU to a virtual machine, and configuring the virtual machine with the GPU partition having the allocated portion of the GPU functionality; as well as In response to the request, access to the virtual machine having the GPU partition is provided.

13. The host device of claim 12, wherein the memory has additional instructions executable by the processor to cause the host device to: transmit a completion notification indicating the extent to which the GPU partition has the requested amount of the one or more GPU capabilities.

14. The host device of claim 12, wherein the memory has additional instructions executable by the processor to cause the host device to: determine that the GPU cannot service the request; and transmit a completion notification indicating that the request was not satisfied.

15. The host device of claim 12, wherein the one or more GPU capabilities include: The video encoding capability of the GPU is used to generate encoded video from the original video; The GPU's video decoding capability is used to play encoded videos or video files; or GPU computing capability represents the amount of GPU processing that the GPU can perform.

16. The host device of claim 12, wherein the request specifies: a minimum amount of the individual GPU or GPUs' capabilities; the preferred amount of the individual's one or more GPU capabilities; or The maximum amount of capability of the individual GPU or GPUs.

17. The host device of claim 12, wherein the memory has additional instructions executable by the processor to cause the host device to: GPU input data is provided from the virtual machine to the allocated portion of the GPU functionality of the GPU, and GPU-processed data is received at the virtual machine, the GPU-processed data being generated by the GPU processing the GPU input data.

18. The host device of claim 17, wherein configuring the virtual machine with the GPU partition comprises generating a virtual device to supply the allocated portion of the GPU functionality of the GPU to the virtual machine.

19. The host device of claim 17, wherein the memory has additional instructions executable by the processor to cause the host device to: Inputs and outputs of the virtual devices are mapped to corresponding data input / output (I / O) hardware work queues of the allocated portion of the GPU function of the GPU.

20. A method implemented by a host device having a graphics processing unit (GPU) and hosting a virtual machine and a virtual device, the method comprising: receiving, at an input of the virtual device, from the virtual machine a request for GPU functionality to be supplied by the GPU, the request having data indicating a requested amount of video encoding capability, video decoding capability, or GPU compute capability of the GPU functionality; determining a data input / output (I / O) hardware work queue of the GPU associated with the input of the virtual device; providing GPU input data to the GPU via the determined data I / O hardware work queue, so that the GPU can supply the requested GPU function using the provided GPU input data; obtaining, by the virtual device, GPU-processed data from the GPU, the data being generated by the GPU function supplied by the GPU to the virtual machine; as well as The virtual device outputs the GPU-processed data to the virtual machine.

21. The method of claim 20, further comprising assigning the GPU to the virtual machine to supply at least the requested GPU functionality to the virtual machine.

22. The method of claim 20, wherein the GPU is assigned to the virtual machine based on a GPU request identifying a GPU partition defined by the host device according to a model having a plurality of segments each representing a different GPU capability. 23 . The method of claim 20 , wherein the GPU-processed data is provided to a GPU partition requester, and the virtual machine is exposed to the GPU partition requester.

Images