FR3057083A1

FR3057083A1 - Procede de gestion de cartes graphiques dans un systeme informatique

Info

Publication number: FR3057083A1
Application number: FR1659446A
Authority: FR
Inventors: Acher Criou
Original assignee: Individual
Current assignee: Individual
Priority date: 2016-09-30
Filing date: 2016-09-30
Publication date: 2018-04-06
Anticipated expiration: 2036-09-30
Also published as: US20180095799A1; EP3301574A1; FR3057083B1; EP3301574B1

Abstract

L'invention concerne un procédé de gestion de cartes graphiques (GC) dans un système informatique (2) comprenant : au moment de la mise en marche d'une machine virtuelle (3) dans le système informatique (2), l'attribution d'au moins une carte graphique virtuelle (VGC) et d'une carte graphique physique (GC) à la machine virtuelle (3) afin de procéder au traitement des instructions graphiques ; la déconnexion de la carte graphique physique (GC) de la machine virtuelle (3) afin de la libérer au profit d'un pool de cartes graphiques (51) disponibles ; la détection du besoin de la machine virtuelle (3) de traiter des instructions graphiques avancées et, au moment de la détection, la sélection d'une carte graphique (GC) disponible dans le pool (51) d'unités de traitement graphiques disponibles ; la connexion de la carte graphique (GC) disponible à la machine virtuelle (3) afin de procéder au traitement des instructions graphiques avancées.

Description

DOMAINE DE L'INVENTION

La présente invention concerne, d'une manière générale, un procédé de gestion de cartes graphiques et/ou d'unités de traitement graphique dans un système informatique.

ARRIERE-PLAN TECHNOLOGIQUE DE L'INVENTION

Les avancées de la technologie informatique ont rendu plus économique pour les utilisateurs de posséder leur propre système informatique, ce qui a provoqué la prolifération des Ordinateurs Personnels (PC) . L'utilisation des PC personnels est très diversifiée et va des opérations de bureau standards ou de lanavigation Internet à l'utilisation d'un ordinateur pour regarder des vidéos de haute qualité ou pour jouer...

La poursuite de ces avancées de la technologie informatique fait que ces ordinateurs personnels sont de plus en plus puissants, mais également de plus en plus complexes, et de plus en plus difficiles à gérer. Pour cette raison, ainsi que pour d'autres plus spécifiquement liées au partage de ressources qui permettent une réduction de la consommation d'électricité pour les utilisateurs individuels, on note un intérêt grandissant pour la séparation des dispositifs d'interface utilisateurs, y compris l'affichage et le clavier, d'avec les parties de traitement des applications du système informatique.

Dans ce cas, les dispositifs d'interface utilisateur sont situés physiquement au niveau du bureau de l'utilisateur, alors que les composants de traitement et de stockage de l'ordinateur se trouvent dans un emplacement d'hébergement distant. Les dispositifs d'interface utilisateur ont alors accès, au niveau de l'ordinateur hôte, à une machine virtuelle dédiée par l'intermédiaire d'un réseau (la plupart du temps Internet), la machine virtuelle émulant le traitement, le stockage requis, ainsi que d'autres ressources informatiques.

Les dispositifs d'interface utilisateur, également dénommés abonnés « Zéro » ou « Légers », sont donc extrêmement dépendants de l'ordinateur hôte qui remplit les rôles computationnels pour les abonnés.

Dans de telles configurations, l'ordinateur hôte héberge le système d'exploitation et les applications logicielles utilisées par les abonnés « légers » ou « zéro », en limitant ainsi les ressources de traitement du coté des abonnés.

L'ordinateur hôte est habituellement constitué d'une pluralité de systèmes informatiques physiques (serveurs) qui hébergent, chacun, une pluralité de machines virtuelles. Chaque machine virtuelle est connectée à un abonné, et fournit un environnement virtuel dédié pour émuler les fonctions d'un ordinateur personnel physique, comprenant le traitement de données graphiques afin d'afficher des informations sur l'écran de l'abonné. Les données devant être affichées sont transférées sur le réseau jusqu'à l'abonné. L'abonné possède des ressources informatiques suffisantes pour recevoir le flux de données et afficher celles-ci. L'abonné possède également des dispositifs d'entrée/de sortie (clavier, souris....) pour échanger des informations ou des instructions avec la machine virtuelle, via le réseau. La virtualisation permet la création d'autant de machines virtuelles qu'il est nécessaire pour s'adapter au nombre d'abonnés, et au partage des ressources informatiques physiques du côté du serveur.

Dans ce contexte, il existe des technologies différentes qui sont employées pour virtualiser la/les carte(s) graphique(s) et/ou l'Unité ou les Unités de Traitement Graphique (GPU) d'un système informatique physique permettant de restituer et de délivrer, à distance, des bureaux graphiques à hautes performances aux abonnés.

Selon une première approche, dénommée « adaptateur graphique direct » ou « intercommunication directe par GPU », une GPU physique est intégralement attribuée à une machine virtuelle. Bien que cette approche puisse sembler satisfaisante, du point de vue de l'utilisateur (puisque chaque abonné bénéficie d'un accès intégral et permanent à une GPU physique dédiée) , elle néces-site de fournir autant de GPU dans le système informatique qu'il y a d'abonnés, ce qui n'est pas favorable, d'un point de vue économique.

Selon une autre approche, dénommée « partage GPU logiciel », un matériel GPU est partagé par de nombreuses machines virtuelles concurrentes. L'exécution du logiciel sur le système informatique physique intercepte les appels d'interface de programme d'application des processus exécutés par les machines virtuelles, les traduit et/ou les fait passer au pilote GPU. L'algorithme de partage peut être préétabli, par exemple, la GPU peut être attribuée à une machine virtuelle sur la base du partage du temps. Cependant, le partage d'une GPU via l'interception IPA logicielle est préjudiciable pour les performances globales et peut ne pas être compatible avec toutes les applications exécutées sur une machine virtuelle. De même, l'algorithme préétabli de partage du temps ne correspond pas nécessairement aux ressources réelles qui sont requises par chaque machine virtuelle.

Selon une nouvelle approche, le matériel de la carte graphique comprend des circuits de virtualisation pour créer des GPU virtuelles, qui permettent à des machines virtuelles concurrentes de partager le matériel GPU sans interception logicielle des appels d'interface IPA. Cependant, dans cette configuration également, un matériel GPU unique est partagé par des machines virtuelles concurrentes sans souci de leurs besoins réels, et les performances du système global ne sont pas optimisées.

OBJET DE L'INVENTION

La présente invention vise à surmonter tout ou partie des inconvénients mentionnés ci-dessus.

RESUME DE L'INVENTION

Pour ce faire, l'invention concerne un procédé de gestion de cartes graphiques dans un système informatique comprenant :

au moment de la mise en marche d'une machine virtuelle dans le système informatique, l'attribution d'au moins une carte graphique virtuelle et d'une carte graphique physique à la machine virtuelle afin de procéder au traitement des instructions graphiques ;

la déconnexion de la carte graphique physique de la machine virtuelle afin de la libérer au profit d'un pool de cartes graphiques disponibles ;

la détection du besoin de la machine virtuelle de traiter des instructions graphiques avancées et, au moment de la détection, la sélection d'une carte graphique disponible dans le pool d'unités de traitement graphiques disponibles ;

la connexion de la carte graphique disponible à la machine virtuelle afin de procéder au traitement des instructions graphiques avancées.

Les cartes graphiques physiques sont attribuées dynamiquement, â partir d'un pool de cartes graphiques disponibles, à une machine virtuelle en fonction de ses besoins pour le traitement d'instructions graphiques avancées. La carte graphique physique connectée est alors totalement disponible pour la machine virtuelle, afin d'assurer des performances améliorées. D'autres instructions graphiques ou requêtes de la machine virtuelle peuvent être traitées par une carte graphique virtuelle, libérant les cartes graphiques pour le pool afin de les rendre disponibles pour les autres machines virtuelles.

Selon d'autres caractéristiques non restrictives de l'invention, qu'elles soient prises seules ou dans toutes les combinaisons techniquement réalisables :

les instructions graphiques de base provenant de la machine virtuelle sont traitées par la carte graphique virtuelle ;

le procédé comprend en outre la déconnexion de la carte graphique physique de la machine virtuelle afin de la libérer au profit du pool une fois que les instructions graphiques avancées ont été traitées ;

l'étape de déconnexion comprend : donner l'ordre à la machine virtuelle 3 d'utiliser la carte graphique virtuelle VGC ;

. fermer, dans la machine virtuelle 3, le pilote de la carte graphique physique GC ;

supprimer l'attribution de la carte graphique physique GC à la machine virtuelle 3 afin de la libérer au profit du pool de cartes graphiques 51 disponibles

- l'étape de déconnexion comprend :

- l'identification d'un motif de communication échangé entre la machine virtuelle et la carte graphique physique, le motif de communication comprenant une requête répétée auprès de la carte graphique physique et une réponse répétée provenant de la carte graphique physique ;

- l'émulation de la présence de la carte graphique physique par l'envoi de la réponse répétée à la machine virtuelle au moment de la réception de la requête répétée.

les instructions graphiques avancées comprennent une commande DirectX, une commande OpenGL, une requête d'accélération matérielle, ou un mode plein écran.

- le besoin de la machine virtuelle de procéder au traitement des instructions graphiques avancées est détecté par la réception d'une instruction graphique avancée au niveau de la carte graphique virtuelle.

- le besoin de l'ordinateur virtuel de procéder au traitement des instructions graphiques avancées est détecté par l'identification d'une instruction graphique avancée pendant un processus d'exécution dans la machine virtuelle.

le besoin de l'ordinateur virtuel de procéder au traitement des instructions graphiques avancées est détecté par la réception, au niveau de la carte graphique physique émulée, d'une requête qui diffère de la requête répétée.

FIGURES

De nombreux autres avantages et caractéristiques 10 de la présente invention apparaîtront à la lecture de la description détaillée suivante, prise conjointement avec les dessins joints, sur lesquels :

- la Figure 1 représente une architecture informatique permettant de mettre en œuvre la présente invention ;

la Figure 2 représente un exemple d'une architecture de carte mère d'un système informatique physique d'un ordinateur hôte ;

- la Figure 3 représente les éléments d'un adaptateur vidéo ;

- la Figure 4 représente les éléments d'une carte graphique ;

- la Figure 5 est une vue conceptuelle de processus exécutés sur un système informatique physique.

DESCRIPTION DETAILLEE DE MODES DE REALISATION

SPECIFIQUES DE L'INVENTION

Dans la description suivante, les descriptions détaillées de fonctions et d'éléments connus qui pourraient rendre inutilement obscure l'essence même de la présente invention seront omises.

De même, un élément « virtuel » doit être compris comme ' étant un logiciel émulant cet élément ; le logiciel étant exécuté sur un dispositif de traitement physique, tel qu'une Unité Centrale (CPU) ou une GPU. Par exemple, une « GPU virtuelle » est un logiciel émulant les fonctions d'une GPU, le logiciel · étant exécuté sur une Unité Centrale ou une GPU physique, ou un autre dispositif de traitement physique. Un dispositif de traitement physique peut piloter une pluralité de ces éléments virtuels et/ou être utilisé pour tout autre type de traitement.

Sur la Figure 1, une architecture informatique comprend un ordinateur hôte 1 qui présente une pluralité de systèmes informatiques physiques 2. Comme cela est bien connu, les systèmes informatiques physiques 2 peuvent être configurés pour héberger une ou une pluralité de machine(s) virtuelle (s) 3, en même temps que son/leur système d'exploitation et applications ou processus. La virtualisation permet qu'une pluralité de machines virtuelles 3 soient hébergées dans chaque système informatique physique 2 tout en fournissant une pluralité d'environnements virtuels complètement isolés au sein d'un système informatique physique 2 unique. Des technologies bien connues de virtualisation incluent Citrix XenServer,

Microsolt Hyper-V, VMware ESXi, Oracle Virtual box, Quick Emulator (QEMU) basée sur la licence GNU Open, etc.

L'ordinateur hôte 1 comprend habituellement un serveur dit « serveur maître » qui fonctionne dans un système informatique physique 2 dédié ou sur une machine virtuelle privilégiée hébergée par un système informatique physique 2 afin de superviser le fonctionnement de l'ordinateur hôte 1. Par exemple, le serveur maître sélectionne, en fonction des ressources disponibles, le système informatique physique 2 sur lequel une nouvelle machine virtuelle 3 doit être mise en marche. Le serveur maître peut également décider de déplacer une machine virtuelle hébergée d'un dispositif informatique physique 2 vers un autre afin de mieux équilibrer l'utilisation des ressources de l'ordinateur hôte 1.

Chacune des machines virtuelles 3 dans l'ordinateur hôte 1 peut être dédiée à un utilisateur en particulier. Les utilisateurs interagissent avec leur machine virtuelle 3 dédiée avec des abonnés distants 4, 4', chacun étant connecté à l'ordinateur hôte 1 par l'intermédiaire du réseau comme Internet. Etant donné que la majeure partie, si ce n'est l'intégralité, du traitement est réalisée au niveau de l'ordinateur hôte 1, les abonnés distants 4, 4' peuvent rester très simples, et peuvent comprendre, par exemple, un simple terminal, un connecteur de réseau et des dispositifs d'entrée/de sortie de base (clavier, souris, ...) comme représenté par l'abonné distant 4 sur la figure 1. Selon une autre solution, il peut s'agir d'un ordinateur personnel standard, avec sa propre Unité Centrale, sa carte graphique, ses périphériques, ... tels que représentés par l'abonné distant 4'.

Pour afficher des images sur le terminal de l'abonné, l'ordinateur hôte 1 restitue et fournit, sur le réseau, au système distant 4, 4', des données d'affichage (et éventuellement un son ou des données de commande supplémentaires pour les dispositifs d'entrée/de sortie, au niveau du site distant 21).

A l'inverse, les abonnés distants 4, 4' fournissent à l'ordinateur hôte 1 des données de commande provenant des dispositifs d'entrée/de sortie situés au niveau du site distant (clavier, souris), et éventuellement d'autres formes de données telles que des données d'affichage ou sonores fournies par une USB ou une caméra et un microphone intégrés de l'abonné distant 4, 4', ou des dispositifs de réseau sur des sites d'abonné distant, comme des imprimantes.....

Des données échangées entre l'ordinateur hôte 1 et les abonnés distants 4, 4' peuvent être compressées afin de limiter l'utilisation de la largeur de bande du réseau.

Dans un mode de réalisation préféré, chaque système informatique physique 2 cinquante machines virtuelles 3, moins de dix machines virtuelles permet d'assurer des ressources informatiques suffisantes pour chaque machine virtuelle afin héberge au maximum et, de préférence, 3. Cette limitation d'exécuter des applications de pointe avec un niveau de service suffisant. Comme cela sera expliqué plus en détails dans la description suivante, chaque machine virtuelle 3 est mise en marche au moment de la connexion de l'abonné 4, 4' et inclut une Unité Centrale virtuelle, une mémoire principale virtuelle, une carte graphique virtuelle ainsi que d'autres ressources physiques ou virtuelles. Chaque machine virtuelle fournit un ordinateur personnel de pointe qui est sous le contrôle d'un abonné distant 4, 4'.

La Figure 2 représente un exemple d'architecture de carte-mère 5 d'un système informatique physique 2 compatible avec l'invention. La carte-mère 5 comprend une Unité Centrale 6. L'Unité Centrale 6 figure, de préférence, des jeux d'instructions multimédia, et peut abriter plusieurs cœurs. Par exemple, l'Unité Centrale 6 est un processeur informatique, tel un Intel Core™. L'Unité Centrale 6 est connectée à une mémoire principale 7 par l'intermédiaire d'un bus de mémoire 8 (qui peut, par exemple, fonctionner suivant les normes PCI, PCI Express ou AGP). La mémoire principale 7 propose, de préférence, au moins 64 GB et a une latence extrêmement faible, inférieure à 14 ns. Le bus de mémoire autorise un débit de transfert de données très élevé, par exemple supérieur à 1200 Mhz. Pour ce faire, le bus de mémoire 8 peut être constitué de lignes conductrices plaquées or.

L'Unité Centrale 6 est également connectée à un jeu de circuits SB 9 par l'intermédiaire du bus 12e. Le jeu de circuits SB 9 est connecté à des périphériques lia à lld, comme des disques dures, des contrôleurs réseau, des contrôleurs E/S.... Les données peuvent passer d'un dispositif sur la carte-mère 5 à un autre dispositif par l'intermédiaire des différents bus, comme le bus mémoire 8, les bus d'extension 12a à 12e, qui connectent les appareils ensemble. Les bus d'extension 12a à 12e peuvent être de nature différente. Par exemple, le jeu de circuits SB 9 peut être connecté à un périphérique sous forme d'un disque dur, par l'intermédiaire d'un bus SATA. Le jeu de circuits SB 9 peut être connecté à d'autres périphériques 11b à lld par l'intermédiaire de bus PCI ou PCIE 12b, 12c, 12e. Le jeu de circuits SB 9 assure l'interface logique nécessaire pour permettre le transfert des données entre les périphériques lia à lld, et entre les périphériques lia, 11b, 11c, lld et l'Unité Centrale 6, et d'autres appareils connectés à l'Unité Centrale 6, comme la mémoire principale 7. Le nombre de périphériques n'est pas limité au nombre présenté sur la Figure 2, et le système informatique physique réel 2 peut présenter plus ou moins de ces périphériques, selon les cas.

Selon l'invention, chaque système informatique physique 2 de l'ordinateur hôte 1 comprend au moins une carte graphique sur la carte-mère 5. Par exemple, comme le montre la Figure 2, l'Unité Centrale 6 est connectée à quatre cartes graphiques GC par l'intermédiaire du bus de carte graphique 13.

Dans certains exemples, une autre carte graphique peut être connectée au jeu de circuits SB 9 ou directement à l'Unité Centrale 6 afin d'afficher des informations au niveau de l'hôte. La carte graphique peut être un simple adaptateur vidéo, permettant de connecter directement un moniteur au système informatique physique 2. Comme le montre la Figure 3, l'adaptateur vidéo comprend typiquement une mémoire vidéo 31, un circuit de conversion 32 et au moins un port de sortie vidéo 33. L'adaptateur vidéo ne comprend généralement pas de processeur graphique dédié, tel un accélérateur 2D/3D ou un décodeur audio/vidéo, mais l'invention n'exclut pas que l'adaptateur vidéo comprenne ce processeur graphique dédié.

directement passer par

Si l'on se réfère à nouveau au mode de réalisation représenté sur la Figure 2, la carte-mère 5 du système informatique physique 2 comprend au moins une carte graphique GC, de préférence connectée à l'Unité Centrale 6 (c'est-à-dire sans le jeu de circuits SB 9) . 4 cartes graphiques GC sont représentées sur la Figure 2. Contrairement à l'adaptateur vidéo, cette au moins une carte graphique GC constitue les ressources informatiques dédiées aux machines virtuelles qui fonctionneront dans le système informatique physique 2.

Comme le montre la Figure 4, chaque carte graphique GC comprend une mémoire de carte graphique 41 d'au moins 2 GB de préférence, destinée à stocker les données d'affichage. Elle comprend également un processeur graphique (GPU) 42 qui reçoit des instructions, des commandes et des données, par exemple, en provenance de l'Unité Centrale 6, par l'intermédiaire du bus de carte graphique 13.

Le processeur graphique (GPU) 42 assure le traitement des instructions et des données reçues et fournit les données d'affichage correspondantes dans la mémoire de carte graphique 41. La GPU 42 peut également donner comme instruction de transférer les données d'affichage stockées dans la mémoire principale 7 vers la mémoire de carte graphique 41, grâce au bus de carte graphique 13 et au bus de mémoire 8.

La carte graphique GC comprend généralement également un codeur/décodeur 43 permettant de transformer, par exemple, des données vidéo (et/ou audio) codées (comme des fichiers H.264) en données d'affichage destinées au stockage dans la mémoire de carte graphique 41. Ces données vidéo (et/ou audio) codées peuvent être fournies par un lecteur de DVD, un disque dur, ou tout autre périphérique connecté au jeu de circuits SB 9.

Une unité de conversion de carte graphique 44 traite les données d'affichage stockées dans la mémoire de carte graphique 41 et les délivre au niveau du port de sortie vidéo de la carte graphique 45. Cependant, comme les données d'affichage sont destinées à être envoyées à un abonné distant 4, 4' par le réseau, une unité de conversion 44 n'est pas une caractéristique nécessaire . de la carte graphique GC et ne sera généralement pas connectée à un écran, au niveau de 1'hôte.

Le bus de carte graphique 13 connecte directement l'Unité Centrale 6 aux cartes graphiques GC afin d'autoriser un transfert rapide des données. Si le nombre de connexions disponibles ou de voies disponibles sur l'Unité Centrale 6 n'est pas suffisant pour la connexion du nombre souhaité de cartes graphiques, le bus 13 peut être muni d'un ou d'une pluralité de commutateur(s) de bus 13a qui permet(tent) de partager les connexions ou les voies de l'Unité Centrale 6 parmi une pluralité de cartes graphiques.

Les cartes graphiques GC sur la carte-mère 5 n'ont pas besoin d'être identiques, ou du même type, ou du même niveau de performances (tel que mesuré par le nombre d'instructions exécutées par la GPU 42 par seconde). Par exemple, dans le mode de réalisation représenté sur la Figure 2, une carte graphique pourrait avoir une capacité faible, une deuxième carte graphique une capacité moyenne, et des troisième et quatrième cartes graphiques une capacité élevée.

Dans une autre configuration possible de cartemère 5 du système informatique physique 2, l'Unité Centrale 6 n'inclut pas le matériel nécessaire pour assurer une connexion directe à la mémoire principale 7 et aux cartes graphiques GC. Dans ce cas, la carte-mère 5 peut comprendre un jeu de circuits NB supplémentaire, connectés à l'Unité Centrale 6, au jeu de circuits SB 9, à la mémoire principale 7 et aux cartes graphiques GC respectivement. Ce jeu de circuits NB redirige le trafic de données parmi les différents éléments auxquels il est connecté.

informatique informatique

La Figure 5' est une représentation schématique des processus exécutés sur un système informatique physique 2 de l'ordinateur hôte 1. Dans cette représentation donnée à titre d'exemple, deux machines virtuelles 3 sont hébergées dans un système

2. Comme mentionné ci-dessus, le système 2 peut héberger plus de deux machines virtuelles, mais, pour assurer un niveau satisfaisant machine, le système préférence, moins de est munie des comme une Unité de performances de chaque informatique 2 héberge, de cinquante, ou, plus préférablement de dix machines virtuelles 3.

Chaque machine virtuelle 3 ressources virtuelles nécessaires,

Centrale virtuelle, une mémoire virtuelle, une carte graphique virtuelle vGC. Comme cela sera expliqué plus en détails ci-dessous, chaque machine virtuelle 3 peut également être connectée à tout moment à au moins une carte graphique physique GC. Chaque machine virtuelle 3 exécute l'application et les processus P sous le contrôle d'un système d'exploitation OS utilisateur,, situé du coté de l'abonné 4, représenté sur la Figure 5).

et d'un 4' (non

Le système d'exploitation OS est configuré pour coordonner la fonction de toutes les ressources virtuelles qui forment la machine virtuelle comme si elles étaient des ressources physiques réelles. Pour ce faire, le système informatique 2 pilote un moteur virtuel 52, mappe les demandes d'une machine virtuelle et/ou d'un système d'exploitation OS pour utiliser les ressources virtuelle vers les appareils physiques sousjacents (Unité Centrale, mémoire, cartes graphiques,...) qui émulent ces ressources virtuelles.

En ce qui concerne les capacités graphiques, le système d'exploitation OS est soit configuré pour diriger les instructions graphiques, données et commandes vers la carte graphique virtuelle vGC, soit configuré pour diriger les instructions graphiques, données et commandes vers les au moins une carte graphique GC du système informatique 2.

Les cartes graphiques GC des systèmes informatiques physiques 2 forment un pool 51 de cartes graphiques disponibles dont les capacités de traitement, comme cela sera expliqué plus en détails ci-dessous, sont mises à la disposition des machines virtuelles 3. Le pool 51 est constitué des cartes graphiques GC de la carte-mère 5, qui contiennent, chacune, une GPU 42, un codeur/décodeur 43 et d'autres ressources, comme celle décrite en faisant référence à la Figure 4. Le pool 51 comprend au moins une carte graphique et le pool 51 comprend, de préférence, une pluralité de cartes graphiques ayant différents niveaux de performances.

Pour gérer le pool 51 de cartes graphiques, le système informatique physique 2 pilote également un gestionnaire de pool de cartes graphiques 53. Dans une autre mise en œuvre, le gestionnaire de pool de cartes graphiques peut appartenir à un serveur maitre qui officie dans différents systèmes informatiques 2 de l'ordinateur hôte 1. Une fonction du gestionnaire de pool de cartes graphiques consiste à attribuer, de manière dynamique, une capacité de traitement graphique délivrée par le pool 51 vers la machine virtuelle 3 selon leurs besoins.

En d'autres termes, le gestionnaire de pool de cartes graphiques 53 gère le pool de cartes graphiques GC, en attribuant chacune d'elles à la/aux machine(s) virtuelle(s) 3 qui fonctionne(nt) dans le système informatique 2, et de manière transparente à la machine virtuelle 3. A partir d'une machine virtuelle et d'un système opérationnel, au moins une carte graphique physique GC est totalement dédiée à ses besoins de calculs graphiques.

Selon l'invention, la gestion du pool 51 de cartes graphiques GC peut comprendre les étapes suivantes, prises seules, ou en combinaison :

- déconnexion de la carte graphique GC attribuée à une machine virtuelle 3 pour la remettre dans le pool 51 de cartes graphiques GC disponibles ;

- dès la détection du besoin de traiter des instructions graphiques avancées, sélection d'une carte graphique GC disponible dans le pool 51 de processeurs graphiques disponibles ;

- connexion d'une carte graphique GC disponible à la machine virtuelle 3 afin de traiter les instructions graphiques avancées.

Sous le contrôle du système d'exploitation OS et/ou du moteur virtuel 52, des instructions graphiques de base en provenance d'une machine virtuelle 3 sont traitées par leurs cartes graphiques virtuelles vGC respectives. Une instruction graphique de base fait référence à toute instruction graphique qui peut être traitée par la carte graphique virtuelle vGC sans monopoliser une puissance de traitement excessive du système informatique physique 2. Ceci correspond typiquement à des tâches qui requièrent le niveau le plus basique de capacités graphiques, comme l'affichage de bureau, le traitement de texte, l'envoi d'e-mails, les présentations commerciales simples. Les instructions graphiques avancées en provenance des machines virtuelles 3 sont dirigées par le système d'exploitation OS et/ou le moteur virtuel 52 vers les cartes graphiques physiques attribuées (ou considérées comme étant attribuées).

Lorsque le moteur virtuel 52 détecte le besoin, pour un ordinateur virtuel 3 qui est déconnecté d'une carte graphique physique, de traiter des instructions graphiques avancées, il notifie le gestionnaire de pool de cartes graphiques 53. Le gestionnaire de pool de cartes graphiques sélectionne une GPU disponible dans le pool 51 et connecte directement (éventuellement avec l'assistance du moteur virtuel 52) la GPU disponible avec l'ordinateur virtuel 3 qui a fait la demande. Ceci permet d'effectuer les traitements avec une grande efficacité, et sans imposer une charge quelconque à l'ordinateur virtuel 3 instructions graphiques avancées. Ces de travail suite aux instructions graphiques avancées peuvent correspondre des commandes directX ou OpenGL, des demandes d'accélération ou d'utilisation du mode plein écran. Par exemple, une carte graphique GC disponible, une fois qu'elle est connectée à la machine virtuelle 3 qui a fait la demande, peut recevoir des instructions et des données, restituer les données d'affichage qui sont tout d'abord stockées dans la mémoire de carte graphique 41 correspondante, et ensuite transférées dans la mémoire principale 7 lorsqu'elle est mise à la disposition de la machine virtuelle 3 qui a fait la demande. Une fois que le besoin de la machine virtuelle 3 de traiter des instructions graphiques avancées a été satisfait, le moteur virtuel 52 notifie le gestionnaire de pool de cartes graphiques qui restitue la carte graphique GC au pool 51.

De préférence, l'étape de sélection de la détermination d'une GPU disponible dans le pool 51, comprend l'évaluation du niveau de performances de la demande et la sélection d'une carte graphique appropriée, dans le pool 51, qui affiche un niveau de performances suffisant. De cette manière, les ressources informatiques graphiques du système informatique physique 2 sont utilisées avec efficacité.

Certains environnements de virtualisation et informatiques, c'est-à-dire une configuration matérielle de carte-mère, de pilotes logiciels et des caractéristiques de système d'exploitation peuvent, à l'origine, permettre de connecter et déconnecter, sélectivement, une carte graphique GC physique à/d'une machine virtuelle 3 particulière, et pendant que la machine virtuelle 3 fonctionne. Ceci peut être réalisé, par exemple, sous le contrôle du moteur virtuel 52 du système informatique physique 2. Et l'invention peut tirer profit de cette caractéristique afin de gérer, de manière dynamique, l'attribution et la libération de la GPU aux/des machines virtuelles.

Cette caractéristique de déconnexion d'une carte graphique GC physique d'une machine virtuelle comprend, typiquement, les étapes consistant à :

- donner l'ordre au système d'exploitation OS ou à la machine virtuelle 3 d'utiliser une autre carte graphique. Dans le contexte de la présente invention, l'autre carte graphique est une carte graphique virtuelle ;

- fermer ou désactiver le pilote de la carte graphique physique qui doit être déconnectée ;

- donner comme instruction au moteur virtuel de désassigner la carte graphique physique de la machine virtuelle et de la réaffecter au pool

51.

La connexion d'une carte graphique GC physique à une machine virtuelle comprend la séquence contraire :

- sélectionner la carte graphique GC physique appropriée dans le pool 51, et donner l'ordre au moteur virtuel 51 d'assigner la carte graphique physique sélectionnée à la machine virtuelle 3 ;

- lancer ou activer le pilote de la carte graphique physique dans la machine virtuelle ^{3 ;}

- donner l'ordre au système d'exploitation OS de la machine virtuelle 3 d'utiliser la carte graphique qui vient d'être attribuée.

Mais l'invention ne nécessite pas la disponibilité de cette caractéristique avancée.

Une caractéristique importante de l'invention est 10 la capacité du moteur virtuel 52 d'attribuer, de manière dynamique, une carte graphique GC à une machine virtuelle 3 et de la réaffecter au pool 51, pendant que la machine virtuelle 3 fonctionne, et indépendamment de l'environnement informatique et de virtualisation de l'ordinateur hôte 1. Dans la plupart des environnements de virtualisation connus, les ressources graphiques virtuelles et physiques sont attribuées en permanence à une machine virtuelle au moment de sa mise en marche, soit intégralement (comme dans l'approche par transfert par GPU), soit partiellement (comme dans l'approche par partage par GPU du logiciel). Dans ces cas, lorsqu'une machine virtuelle 3 n'a pas besoin de traiter des instructions graphiques avancées, les ressources GPU qui lui sont attribuées ou partiellement attribuées sont gaspillées.

Selon la présente invention, au moment de la mise en marche d'une machine virtuelle 3 dans le système informatique physique 2 (c'est-à-dire au moment de sa création), au moins une carte graphique virtuelle vGC et une carte graphique physique GC lui sont attribuées pour traiter des instructions graphiques. Si le système informatique physique 2 est muni de plusieurs cartes graphiques physiques, chaque carte graphique, ou une pluralité de cartes graphiques peut/peuvent être attribuée (s) à la machine virtuelle 3 au moment de sa mise en marche. Exactement comme dans l'approche par partage par GPU, les cartes graphiques GC apparaîtront aux machines virtuelles comme étant intégralement attribuées.

La mise en marche d'une machine virtuelle 3 comprend généralement l'affichage de l'environnement de bureau et d'autres activités qui ne sont pas gourmandes en ressource graphique. Par conséquent, au moment de la mise en marche, la carte graphique virtuelle vGC est choisie comme étant la carte graphique par défaut et fournit une puissance de traitement suffisante pour restituer les données d'affichage qui seront fournies à l'abonné 4, 4', sans altérer les performances globales du système informatique physique 2.

Pendant ce temps, et alors que les cartes graphiques physiques ne sont pas sollicitées, le système d'exploitation OS et/ou la machine virtuelle 3 mise en marche peuvent communiquer avec la/les carte(s) graphique(s) physique(s) GC qui lui a/ont été attribuée(s).

Cette communication comprend l'émission de demandes émanant du système d'exploitation OS ou de la machine virtuelle 3 à destination de la/les carte(s) graphique(s) physique(s) GC attribuée(s), et comprend les réponses correspondantes de la/les carte(s) graphique(s) physique(s) GC attribuée(s) à la machine virtuelle 3. Ces demandes et réponses correspondent habituellement aux signaux de commande et aux instructions qui sont échangées, de manière répétée, entre les unités, par exemple sur le bus de carte graphique 13, afin de s'assurer de leur disponibilité et de leur fonctionnalité. La répétition des demandes et des réponses constitue un motif de communication.

Selon un mode de réalisation de l'invention, le moteur virtuel 52 surveille les communications qui ont lieu entre la machine virtuelle 3 qui vient juste d'être mise en marche et la carte graphique physique attribuée. Le moteur virtuel 52 identifie le motif de communication constitué de demandes et de réponses répétées. Au moment de l'identification du motif de communication, le moteur virtuel 52 restitue la carte graphique physique attribuée au pool 51, en la déconnectant de la machine virtuelle 3. A partir de cet instant, le moteur virtuel 52 émule la présence de la carte graphique physique attribuée à l'origine à la machine virtuelle 3, en envoyant les réponses répétées au moment de la réception des demandes répétées.

Du point de vue de la machine virtuelle 3, la carte graphique physique GC est présente et totalement disponible. Cependant, la carte graphique physique GC a été entièrement restituée au pool 51 et peut être utilisée par n'importe quelle autre machine virtuelle 3 qui a besoin d'un traitement d'instructions graphiques avancées.

Différents procédés peuvent être utilisés simultanément pour détecter le besoin d'une machine virtuelle 3 de traiter des instructions graphiques avancées, et de connecter et/ou déconnecter une carte graphique GC disponible au/du pool 51.

Selon un premier procédé, un tel besoin est détecté quand le moteur virtuel 52 reçoit une demande provenant de la machine virtuelle 3 qui diffère de la demande répétée. Dans ce cas, le moteur virtuel 52 notifie au gestionnaire de pool de cartes graphiques 53 qu' il est en train de sélectionner une carte graphique disponible dans le pool 51 comme cela a été expliqué en détails ci-dessus, et de l'attribuer à la machine virtuelle 3 qui a fait la demande.

Selon un deuxième procédé, le besoin est détecté grâce à la réception d'une instruction graphique avancée au niveau de la carte graphique virtuelle vGC. Du fait que le traitement efficace de ladite instruction graphique nécessiterait une puissance de traitement par le système informatique physique 2 trop importante, il est préférable de réattribuer une carte graphique physique GC, comme décrit en détail cidessus, et de rediriger l'instruction vers cet appareil.

Selon un autre procédé, le besoin est détecté grâce à l'identification, à l'avance, d'une instruction graphique avancée pendant l'exécution d'un processus P dans la machine virtuelle 3. Ce processus P peut être arrêté pendant le laps de temps où une carte graphique physique GC est réattribuée à la machine virtuelle 3, et exécuté à nouveau une fois que réalisée.

cette attribution est

Dans l'hypothèse où il n'y aurait aucune carte graphique GC disponible dans le pool 51 du système informatique 2, et où il ne pourrait pas être répondu immédiatement à la demande provenant d'une machine virtuelle 3, le gestionnaire de pool de cartes graphiques 53 peut notifier le serveur maître. Le serveur maître peut alors réagir pour déplacer la machine virtuelle 3 (ou plus généralement, toute machine virtuelle 3 hébergée dans le système informatique 2 qui est connectée à une carte graphique physique) vers un autre système informatique 2 de l'ordinateur hôte 1, plus disponible.

Claims

REVENDICATIONS

1. Procédé de gestion de cartes graphiques (GC) dans un système informatique (2) comprenant :

- au moment de la mise en marche d'une machine virtuelle (3) dans le système informatique (2), l'attribution d'au moins une carte graphique virtuelle (VGC) et d'une carte graphique physique (GC) à la machine virtuelle (3) afin de • procéder au traitement des instructions graphiques ;

- la déconnexion de la carte graphique physique (GC) de la machine virtuelle (3) afin de la libérer au profit d'un pool de cartes graphiques (51) disponibles ;

- la détection du besoin de la machine virtuelle (3) de traiter des instructions graphiques avancées et, au moment de la détection, la sélection d'une carte graphique (GC) disponible dans le pool (51) d'unités de traitement graphiques disponibles ;

- la connexion de la carte graphique (GC) disponible à la machine virtuelle (3) afin de procéder au traitement des instructions graphiques avancées.
2. Procédé selon la revendication 1, dans lequel les instructions graphiques de base provenant de la machine virtuelle (3) sont traitées par la carte graphique virtuelle (VGC).
3. Procédé selon la revendication 1 ou 2, comprenant en outre la déconnexion de la carte graphique physique (GC) de la machine virtuelle (3) afin de la libérer au profit du pool (51) une fois que

5 les instructions graphiques avancées ont été traitées.
4. Procédé selon l'une quelconque des revendications précédentes, dans lequel l'étape de déconnexion comprend :

. donner l'ordre à la machine virtuelle (3) 10 d'utiliser la carte graphique virtuelle (VGC) ;

fermer, dans la machine virtuelle (3), le pilote de la carte graphique physique (GC) ;

. supprimer l'attribution de la carte graphique physique (GC) à la machine virtuelle (3) afin de

15 la libérer au profit du pool de cartes graphiques (51) disponibles.
5. Procédé selon l'une quelconque des revendications 1 à 3, dans lequel l'étape de déconnexion comprend :

20 - l'identification d'un motif de communication échangé entre la machine virtuelle (3) et la carte graphique physique (GC), le motif de communication comprenant une requête répétée auprès de la carte graphique physique (GC) et

25 une réponse répétée provenant de la carte graphique physique (GC) ;

- l'émulation de la présence de la carte graphique physique (GC) par l'envoi de la réponse répétée à la machine virtuelle (3) au moment de la réception de la requête répétée.
6. Procédé selon l'une quelconque des revendications précédentes, dans lequel les

5 instructions graphiques avancées comprennent une commande DirectX, une commande OpenGL, une requête d'accélération matérielle, ou un mode plein écran.
7. Procédé selon l'une quelconque des revendications précédentes, dans lequel le besoin de la

10 machine virtuelle (3) de procéder au traitement des instructions graphiques avancées est détecté par la réception d'une instruction graphique avancée au niveau de la carte graphique virtuelle (VGC).
8. Procédé selon l'une quelconque des

15 revendications 1 à 6, dans lequel le besoin de l'ordinateur virtuel (3) de procéder au traitement des instructions graphiques avancées est détecté par l'identification d'une instruction graphique avancée pendant un processus (P) d'exécution dans la machine

20 virtuelle (3).
9. Procédé selon l'une quelconque des revendications 4 à 6, dans lequel le besoin de l'ordinateur virtuel (3) de procéder au traitement des instructions graphiques avancées est détecté par la

25 réception, au niveau de la carte graphique physique émulée, d'une requête qui diffère de la requête répétée.

1 /4

CN

2/4