Patent Application
20180095799
This application claims the benefit of the filing date of French Patent Application Serial No. 16/59446, filed Sep. 30, 2016, for “Method for Managing Graphic Cards in a Computing System.”
The present invention generally relates to a method for managing graphics cards and/or graphic processing units in a computer system.
Advances in computer technology have made it economical for individual users to have their own computing system, which caused the proliferation of the Personal Computer (PC). Individual PC usage is very diversified, ranging from standard office operations or Internet surfing to high-quality video watching or gaming.
Continued advances of this computer technology make these personal computers more and more powerful but also complex and difficult to manage. For this and other reasons especially related to sharing of resources for enabling lower power consumption for the individual user, there is a growing interest to separate the user interface devices, including the display and keyboard, from the application processing parts of the computing system. In this case, the user interface devices are physically located at the desktop of the user, while the processing and storage components of the computer are placed in a remote hosting location. The user interface devices then have access, at the host computer, to a dedicated virtual machine through a network (most commonly the Internet), the virtual machine emulating the required processing, storage, and other computing resources.
The user interface devices, also called “zero” or “thin” clients, are therefore heavily dependent on the host computer that fulfills the computational roles for the clients. In such configurations, the host computer hosts the operating system and software applications utilized by the “thin” or “zero” clients, thus limiting processing requirements on the clients.
The host computer is usually constituted of a plurality of physical computing systems (servers) each hosting a plurality of virtual machines. Each virtual machine is connected to a client, and provides a dedicated virtual environment to emulate the functions of a physical personal computer, including graphic data processing to display information on the client screen. The data to be displayed is transferred through the network to the client. The client possesses sufficient computing resources to receive the data flow and display them on the client screen. The client is also provided with input/output devices (keyboard, mouse, etc.) to exchange information or instructions with the virtual machine, via the network. Virtualization enables the creation of as much virtual machines as necessary to match the number of clients, and the sharing of the physical computing resources on the server side.
In this context, there are different technologies employed to virtualize the graphic card(s) and/or Graphics Processing Unit(s) (GPU) of a physical computing system to remotely render and deliver high performance graphics desktops to clients.
According to a first approach, referred to in the art as “direct graphics adaptor” or “GPU pass-through,” a physical GPU is entirely assigned to a virtual machine. Although this approach may be seen as satisfactory from a user perspective (since each client benefits from a full and permanent access to a dedicated physical GPU), this requires providing as many GPUs in the computing system as clients, which is not favorable from an economical standpoint.
In an alternative approach, referred to in the art as “software GPU sharing,” a GPU hardware is shared among many concurrent virtual machines. Software running on the physical computing system intercepts the application program interface calls of processes running in the virtual machines, translates them and/or passes them to the GPU driver. The sharing algorithm can be pre-established, for instance the GPU can be assigned to a virtual machine on a time slice basis. However, sharing a GPU via software API intercept is detrimental to the overall performance and may not be compatible with all applications running on a virtual machine. Also, a pre-established time slice sharing algorithm may not necessarily match the actual resources needed by each virtual machine.
In a further approach, the graphic card hardware comprises virtualization circuits that create virtual GPUs, allowing concurrent virtual machines to share the GPU hardware without software intercept of API interface calls. However, in this configuration, a single GPU hardware is also shared among concurrent virtual machines without concern for their actual needs, and performance of the overall system may be less than optimal.
The present disclosure aims at overcoming all or parts of the aforementioned drawbacks.
To this effect, the disclosure relates to a method for managing graphic cards in a computing system comprising:
Physical graphic cards are dynamically assigned from a pool of available graphic cards to a virtual machine according to its needs in processing advanced graphical instructions. The connected physical graphic card is then fully available to the virtual machine, to provide enhanced performance. Other graphical instructions or requests of the virtual machine can be treated by a virtual graphic card, releasing the physical graphic cards to the pool and to render them available to other virtual machines.
According to further non-limiting features of the disclosure, either taken alone or in all technically feasible combinations:
Many other features and advantages of the present disclosure will become apparent from reading the following detailed description, when considered in conjunction with the accompanying drawings, in which:
In the following description, detailed descriptions of functions and elements know to those of ordinary skill in the art that may unnecessarily obscure the gist of the present disclosure are omitted.
Also, a “virtual” element should be understood as a software emulating this element, the software being executed on a physical processing device, such as a CPU or a GPU. For instance, a “virtual GPU” is a software emulating the functions of a GPU, the software being executed on a physical CPU or GPU, or an other physical processing device. A physical processing device may execute a plurality of such virtual elements and/or be used for other processing purposes.
Referring to
Host computer 1 usually comprises a so called “master server” that is executing on a dedicated physical computing system 2 or in a privileged virtual machine hosted in a physical computing system 2 to supervise the operation of host computer 1. For instance, the master server selects, according to available resources, on which physical computing system 2 a new virtual machine 3 should be initiated. The master server may also decide to move a hosted virtual machine from one physical computing device 2 to another, to better balance utilization of resources of the host computer 1.
Each of the virtual machines 3 in host computer 1 may be dedicated to one particular user. The users interact with their dedicated virtual machine 3 from remote clients 4, 4′, each of which is connected to the host computer 1 through a network such as the Internet. Since most, if not all, of the processing is performed at host computer 1, the remote clients 4, 4′ may be kept very simple and may comprise, for instance, a simple terminal, network connector and basic input/output devices (keyboard, mouse, etc.) such as represented by remote client 4 on
To display images on the client terminal, the host computer 1 renders and provides over the network the remote system 4, 4′ with display data (and possibly with additional sound or control data for input/output devices located at the remote system 4, 4′).
Conversely, the remote clients 4, 4′ are providing to the host computer 1 control data from input/output devices located at the at the remote system 4, 4′ (keyboard, mouse, etc.), and possibly other forms of data such as display and sound data provided by a USB or built in camera and microphone of the remote client 4, 4′, or network devices at the remote client locations, such as printers.
Data exchanged between the host computer 1 and the remote clients 4, 4′ may be compressed in order to limit bandwidth usage of the network.
In a preferred embodiment, each physical computing system 2 is hosting at most fifty virtual machines 3, and preferably, less than ten virtual machines 3. This limitation provides sufficient computing resources to each virtual machine for executing high-end applications with a sufficient level of service. As this will be explained in greater detail later in this description, each virtual machine 3 is initiated upon client 4, 4′ connection and includes a virtual CPU, a virtual main memory, a virtual graphic card and other physical or virtual resources. Each virtual machine provides a virtual high-end personal computer that is under control of a remote client 4, 4′.
CPU 6 is also connected to southbridge (SB) chipset 9 through bus 12e. SB chipset 9 connects to peripheral devices 11a to 11d, such as hard drives, network controllers, I/O controllers, etc. Data may flow from one device on the motherboard 5 to another through the different buses, such as the memory bus 8, extension buses 12a to 12e, which connects the devices together. Extension buses 12a to 12e can be of different nature. For instance, SB chipset 9 may be connected to a peripheral hard drive 11a through a SATA bus. SB chipset 9 may be connected to other peripherals 11b to 11d through PCI or PCIE buses 12b, 12c, 12e. SB chipset 9 provides the necessary logic interface for permitting data transfer between peripheral devices 11a to 11d, and between peripheral devices 11a, 11b, 11c, 11d and CPU 6, and further devices connected to CPU 6 such as the main memory 7. The number of peripheral devices is not limited to the number presented on
According to the disclosure, each physical computing system 2 of host computer 1 comprises at least one graphic card on a motherboard 5. For instance, as shown in
In some instances, one further graphic card may be connected to SB chipset 9 or directly to the CPU 6 to display information at the host location. The graphic card can be a simple video adapter, for directly connecting a monitor to the physical computing system 2. As represented on
Referring back to the embodiment represented in
As represented in
Graphic Processing Unit 42 is processing the instruction and data received and provides corresponding display data into the graphic card memory 41. The GPU 42 may also instruct the transfer of the display data stored into the main memory 7 to the graphic card memory 41, through graphic card bus 13 and memory bus 8.
Graphic card GC also usually comprises an encoder/decoder 43 to transform for instance encoded video (and/or audio) data (such as H.264 files) into display data for storage into the graphic card memory 41. Such encoded video (and/or audio) data may be provided by a DVD player, a hard disk, or any other peripheral connected to SB chipset 9.
A graphic card conversion unit 44 processes the display data stored into the graphic card memory 41 and provide them at graphic card video output port 45. However, since display data are intended to be sent to remote client 4, 4′ over a network, conversion unit 44 is not a necessary feature of the graphic card GC and usually will not be connected at the host location to a screen.
Graphic card bus 13 connects CPU 6 directly to the graphic cards GC for allowing fast data transfer. If the number of available connections or lanes available on CPU 6 is not sufficient for connecting the desired number of graphic cards, bus 13 may be provided with one or more bus switches 13a that allow sharing of CPU 6 connections or lanes among a plurality of graphic cards.
Graphics cards GC on the motherboard 5 do not need to be identical, or of the same type, or of the same performance level (as measured by the number of instructions performed by the GPU 42 per second). For instance, in the embodiment represented in
In an alternative possible configuration of motherboard 5 of the physical computing system 2, CPU 6 does not include the necessary hardware for connecting directly to main memory 7 and graphic cards GC. In that case, the motherboard 5 may comprise an additional northbridge (NB) chipset, connected to, respectively, the CPU 6, the SB chipset 9, the main memory 7 and graphic cards GC. This NB chipset redirects the data traffic among the various elements connected to the NB chipset.
Each virtual machine 3 is provided with the necessary virtual resources such as a virtual CPU, virtual memory, a virtual graphic card vGC, etc., to provide the virtual machine 3. As will be explained in greater detail herein, each virtual machine 3 may also be connected at any time to at least one physical graphic card GC. Each virtual machine 3 is running application and processes P under control of an operating system OS, and of a user located on a client side 4, 4′ (not represented on
The operating system OS is configured to coordinate the function of all virtual resources that form the virtual machine as if they were actual physical resources. To this effect, computing system 2 is executing a virtual engine 52, mapping the requests of a virtual machine and/or operating system OS to use virtual resources toward the underlying physical devices (CPU, memory, graphic cards, etc.) emulating those virtual resources.
When it comes to graphics capability, the operating system OS is either configured to direct graphical instructions, data and controls to the virtual graphic card vGC or configured to direct graphical instruction, data and controls to the at least one graphic cards GC of computing system 2.
The graphic cards GC of the physical computing systems 2 form a pool 51 of available graphic cards whose processing capacities, as it will be explained below in details, are made available to the virtual machines 3. The pool 51 is constituted of the graphics cards GC of motherboard 5 each featuring a GPU 42, encoder/decoder 43 and other resources, such as the one described with reference to
To manage the pool 51 of graphic cards, physical computing system 2 is also running a graphic card pool manager 53. In an alternative implementation, graphic card pool manager may be part of the master server running in a different computing system 2 of the host computer 1. One function of the graphic card pool manager 53 is to dynamically allocate graphics processing capacity from the pool 51 to the virtual machine 3 according to their needs.
In other words, graphic card pool manager 53 is managing the pool of graphic cards GC, allocating each of them to the running virtual machine(s) 3 in the computing system 2, and transparently to the virtual machine 3. From a virtual machine and operating system perspective, at least one physical graphic card GC is fully dedicated to its graphical computation needs.
According to the invention, managing the pool 51 of graphic cards GC may comprise the following steps, taken alone or in combination:
Under the control of operating system OS and/or of virtual engine 52, basic graphical instructions originating from a virtual machine 3 are processed by their respective virtual graphic card VGC. Basic graphical instruction refers to any graphical instruction that can be processed by the virtual graphic card VGC without monopolizing excessive processing power of the physical computer system 2. This typically corresponds to tasks that require the most basic level of graphic capabilities, such as desktop display, word processing, emailing, simple business presentation. Advanced graphical instructions originating from the virtual machines 3 are directed by the operating system OS and/or virtual engine 52 to the assigned (or deemed to be assigned) physical graphic cards.
When the virtual engine 52 detects the need for a virtual computer 3 that is disconnected from a physical graphic card to process advanced graphical instructions, the virtual engine 52 notifies the graphic card pool manager 53. Graphic card pool manager selects an available GPU in the pool 51 and directly connects (possibly with the assistance of virtual engine 52) the available GPU to the requesting virtual computer 3. This allows processing with great efficiency, and without imposing any workload associated with the advanced graphical instructions to the virtual computer 3. Such advanced graphical instructions can correspond to directX or OpenGL commands, acceleration requests or use of full screen mode. For instance, an available graphic card GC, once connected to the requesting virtual machine 3, may receive instructions and data, render display data that are first stored into the corresponding graphic card memory 41, and then transferred into main memory 7 where it is made available to the requesting virtual machine 3. Once the need of the virtual machine 3 to process advanced graphical instructions has been fulfilled, the virtual engine 52 notifies the graphic card pool manager, which releases the graphic card GC back to the pool 51.
Preferably, the selection step of determining an available GPU in the pool 51, comprises the performance level evaluation of the request and the selection of an appropriate graphic card in the pool 51 that exhibits sufficient performance level. In this way, the graphical computing resources of the physical computing system 2 are used efficiently.
Some virtualization and computing environments, i.e., mother board hardware configuration, software drivers and operating system features may natively allow to selectively connect and disconnect a physical graphic card GC to a particular virtual machine 3, even while the virtual machine 3 is running. This may be achieved, for instance, under the control of the virtual engine 52 of the computing system 2. Embodiments of the present disclosure may employ this feature to dynamically manage the allocation and release of a GPU to the virtual machines.
Such feature to disconnect a physical graphic card GC from a virtual machine may comprise the steps of:
The connection of a physical graphic card GC to a virtual machine would comprises the opposite sequence:
Embodiments of the present disclosure do not, however, require the availability of this advanced feature.
An important feature of the disclosure is the ability of the virtual engine 52 to dynamically assign a graphic card GC to a virtual machine 3 and release it to the pool 51, while the virtual machine is running, and independently of the computing and virtualization environment of host computer 1. In most known virtualization environments, physical and virtual graphic resources are assigned permanently to a virtual machine upon its initiation, either entirely (as in the GPU pass-through approach) or partly (as in the software GPU sharing approach). In such cases, when a virtual machine 3 does not need to process advanced graphics instructions, the GPU resources assigned or partly assigned to it are wasted.
According to embodiments of the present disclosure, upon initiation of a virtual machine 3 in the physical computing system 2 (i.e., at its creation), at least a virtual graphic card vGC and a physical graphic card GC may be assigned to the virtual machine 3 for processing graphical instructions. If the physical computing system 2 is provided with more than one physical graphic cards, each graphic card or a plurality of graphic cards may be assigned to the virtual machine 3 upon its initiation. Just like in the GPU pass-through approach, the graphic cards GC will appear to the virtual machines as entirely assigned.
The initiation of a virtual machine 3 generally includes the displaying of the desktop environment and other activities that are not graphic intensive. Therefore, upon initiation, the virtual graphic card vGC is selected as the default graphic card and provide sufficient processing power to render the display data that will be provided to the client 4, 4′, without degrading overall performance of the physical computer system 2.
During this time, and while the assigned physical graphic cards are not solicited, the operating system OS and/or initiated virtual machine 3 may communicate with the physical graphic card(s) GC that has or have been assigned to it.
This communication comprises the emission of requests from the operating system OS or virtual machine 3 to the assigned graphic card(s) GC, and comprises the corresponding replies of the assigned graphic card(s) GC to the virtual machine 3. Those requests and replies usually correspond to control signals and instructions that are repeatedly exchanged between the units, for instance on the graphic card bus 13, to make sure of their availability and functionality. The repetition of the requests and replies forms a communication pattern.
According to one embodiment of the disclosure, the virtual engine 52 monitors the communications taking place between the just initiated virtual machine 3 and the assigned physical graphic card. The virtual engine 52 identifies the communication pattern formed of repeated requests and replies. Upon identification of the communication pattern, the virtual engine 52 releases the assigned physical graphic card to the pool 51, disconnecting it from the virtual machine 3. From this time on, the virtual engine 52 is emulating the presence of the originally assigned physical graphic card to the virtual machine 3, by sending the repeated replies upon reception of the repeated requests.
From the virtual machine 3 perspective, the physical graphic card GC is present and fully available. However, the graphic card GC has been fully released to the pool 51 and can be used by any other virtual machine 3 that is in need of processing advanced graphical instructions.
Different methods can be concurrently used to detect the need of a virtual machine 3 to process advanced graphical instructions, and connect and/or disconnect an available graphic card GC from/to the pool 51.
According to a first method, such a need is detected when the virtual engine 52 is receiving a request from the virtual machine 3 that differs from the repeated request. In such a case, the virtual engine 52 notifies the graphic card pool manger 53, which then selects an available graphic card in the pool 51 as previously described, and assigns it to the requesting virtual machine 3.
According to a second method, the need is detected by receiving an advanced graphical instruction at the virtual graphic card vGC. Since the efficient processing of such a graphical instruction would require too much processing power of the physical computing system 2, it is preferable to reassign a physical graphic card GC as detailed above and redirect the instruction to the physical graphic card GC.
According to another method, the need is detected by identifying, in advance, an advanced graphical instruction in a process P being executed in the virtual machine 3. This process P can be halted during the time a physical graphic card GC is reassigned to the virtual machine 3, and executed once reassignment is complete.
According to a further method, the need is detected by reference to a database or a reference file that establishes advanced graphic usage and processing power required for a list of named processes. Upon execution of a particular process in the virtual machine 3, the database or file can be consulted to determine the physical graphic card GC or the virtual graphic card vGC that is most adapted to the particular process. The database or reference file may be constructed from information collected from past execution of the processes.
In the event there are no available graphic cards GC in the pool 51 of the computing system 2, and the request of a virtual machine 3 cannot immediately be fulfilled, graphic card pool manager 53 may notify the master server. Master server may then take action to move virtual machine 3 (or, more generally, any virtual machine 3 hosted in computing system 2 that is connected to a physical graphic card) to another computing system 2 of host computer 1 with more availability.
| Number | Date | Country | Kind |
|---|---|---|---|
| 1659446 | Sep 2016 | FR | national |
