NVIDIA est connue pour opérer une segmentation forte entre ses GeForce et ses solutions pour entreprises (Quadro, Tesla, etc.), réservant de nombreuses fonctionnalités à ces dernières. Ce n'est plus le cas du passthrough GPU, ce qui ouvre la voie à de nombreux usages, dont le jeu depuis Linux.
Hier, NVIDIA mettait en ligne le premier pilote de la branche 465 destiné à ses GeForce. Il comporte les améliorations habituelles et le Resizable BAR pour l'ensemble des RTX de série 30 (Ampere). Une fonctionnalité permettant de grapiller quelques points de performances en améliorant l'accès à la mémoire graphique par le CPU.
Les GeForce servent aussi aux professionnels
Mais la grande nouveauté était ailleurs, évoquée en seulement quelques lignes dans le billet de blog d'annonce : ce pilote signait la fin de la limitation du passthrough GPU pour les cartes graphiques grand public. Une possibilité attendue de pied ferme par les adeptes de la virtualisation mais aussi de nombreux joueurs sous Linux.
Le constructeur dit avoir identifié plusieurs cas d'usage légitimes ces dernières années. C'est d'autant plus vrai depuis qu'il pousse à l'utilisation de ses GeForce par un public semi-professionnel comme les « créateurs », notamment via sa gamme RTX. Mais les développeurs sont aussi nombreux à les utiliser au quotidien.
NVIDIA l'a sans doute bien compris en voyant tout l'intérêt qu'il y avait à proposer l'accès à ses GPU pour du calcul depuis le sous-système Linux de Windows 10 (WSL), qui utilise désormais une couche de virtualisation. Une possibilité qui lui ouvre de nombreux avantages et qui n'aurait pas forcément profité aux Quadro/Tesla.
Dès lors, leur réserver le passthrough GPU n'avait guère d'intérêt. Mais dans la pratique, qu'est-ce qui change ? Et comment tirer parti de cette « nouvelle » fonctionnalité au quotidien ? On vous l'explique, via différentes solutions.
Le GPU Passthrough ce n'est pas nouveau chez NVIDIA, mais c'était jusqu'à maintenant réservé aux entreprises
Passthrough GPU : kesako ?
Commençons par le commencement : qu'est-ce que le passthrough dans un contexte de virtualisation ? Il s'agit tout simplement d'associer un composant matériel à une machine virtuelle (VM) pour qu'elle l'utilise de manière dédiée.
C'est par exemple ce qu'utilise Blade pour son service de PC dans le cloud Shadow. Chaque serveur dispose de deux processeurs mais de trois ou quatre cartes graphiques, et autant de machines virtuelles auxquelles peuvent se connecter les clients. Certaines ressources y sont partagées entre plusieurs clients (CPU, mémoire, stockage), mais le GPU est dédié. Chacun peut donc l'utiliser à sa pleine puissance, comme si elle était dans un vrai PC.
Cette fonctionnalité est aussi utilisée à d'autres fin dans le domaine de la virtualisation, pour le stockage ou le réseau par exemple. On peut ainsi associer des HDD/SSD physiques à une machine virtuelle pour éviter de perdre en performances. C'est ce que propose QNAP depuis peu via son service QuTScloud.
Notez d'ailleurs que ses NAS peuvent intégrer des cartes graphiques et les utiliser en passthrough pour différents besoins via Virtualization Station, comme n'importe quel système Linux. C'était d'ailleurs un usage mis en avant dans la vidéo de présentation de ses derniers modèles desktop équipés de processeurs Ryzen (TS-x73A).
Qu'est-ce qui change exactement ?
Le passthrough GPU est gérée de longue date par NVIDIA, notamment via ses solutions GRID. Mais si jamais vous tentiez d'associer une GeForce physique à une machine virtuelle, vous rencontriez une erreur à l'installation du pilote. C'est le fameux code 43, connu de tous les adeptes de virtualisation.
Il était affiché tant via une installation classique que lorsque vous passez par Windows Update. Cette méthode affiche encore une telle erreur, les derniers pilotes n'y étant pas proposés. Nous l'avons expérimenté hier soir :
En passant par Windows Update, l'erreur 43 est toujours présente, il faut installer un pilote plus récent manuellement
À partir de la branche 465, le pilote des GeForce ne renverra plus le code d'erreur 43 lorsqu'il détectera une installation depuis une VM. Il faut dire que ce « blocage » avait été depuis longtemps contourné, que ce soit via un paramètre à intégrer dans les hyperviseurs de VMWare ou des lignes de commande sous Linux.
Des étapes désormais inutiles. Notez que s'il faut que le pilote utilisé dans la machine virtuelle soit le dernier en date, vous n'avez pas à vous préoccuper de celui de l'hôte puisque la carte graphique n'y est pas utilisée.
Quelles sont les conditions et limitations ?
Pour le moment, le passthrough GPU est indiqué comme une fonctionnalité « Beta ». Mais lors de nos différents tests nous n'avons rencontré aucun problème particulier. NVIDIA se réserve sans doute la possibilité de pouvoir la faire évoluer dans ses conditions d'accès, qui répondent aux besoins principaux mais affichent quelques limites.
La première est que le système hôte, qui sert à gérer la virtualisation, doit être sous Linux (désolé macOS). Cela peut être une distribution classique ou des hyperviseurs divers (VMware ESXi/vSphere, Proxmox). Nous avons effectué des essais via Unraid, qui s'est notamment fait connaître en facilitant le passthrough GPU, sans problème.
Autre point d'importance : chaque GeForce ne doit être utilisée que par une VM à la fois. Il est impossible de la partager entre plusieurs systèmes virtualisés, ce qui reste une fonctionnalité réservée aux cartes d'entreprises (comme chez AMD), notamment via la génération Ampere gérant SR-IOV et le Multi-Instances GPU (MIG).
Un outil non officiel permet néanmoins de virtualiser un GPU grand public dans certains cas, pour les plus courageux (merci Tchyo). On peut par contre associer plusieurs cartes graphiques à une même machine virtuelle.
Un GPU pour l'hôte et un autre pour le passthrough
Le cas d'usage le plus évident est celui des utilisateurs sous Linux, que ce soit par goût, conviction ou besoin. NVIDIA évoque notamment les développeurs, qui sont souvent dans ce cas. Ils optent le plus souvent pour un multi-boot afin de jouer à tous leurs jeux ou pour simplement tester une application Windows nécessitant la carte graphique.
Désormais, ce n'est plus nécessaire puisque l'on peut simplement utiliser un hyperviseur comme KVM pour créer une machine virtuelle, lui attacher une GeForce et l'utiliser sous Windows 10 sans quitter Linux. Attention tout de même, il y a un prérequis technique qui n'est pas anodin : la GeForce étant attachée à la VM comme s'il s'agissait d'une machine physique, elle renvoie son affichage via sa sortie vidéo et ne peut être utilisée pour le système hôte.
Il faut donc disposer d'une solution graphique principale pour ce dernier. Cela peut être la partie graphique intégrée du processeur (IGP) ou une seconde carte graphique. Les CPU Ryzen d'AMD, qui ont beaucoup de cœurs mais pas d'IGP sont ici désavantagés par rapport aux puces d'Intel qui en ont le plus souvent une.
Une carte mère ASRock Rack TRX40D8-2N2T et sa puce grapique ASPEED AST2500
Il y a néanmoins une solution pour éviter d'occuper un port PCIe avec une carte graphique consacrée à l'hôte : les cartes mères pour serveur avec IPMI/BMC. Ce dispositif de gestion distante passe par la présence d'une solution graphique sur le PCB qui peut être utilisée par le système. Il existe notamment des modèles ASRock Rack pour Ryzen (Threadripper) qui proposent un tel dispositif. Nous en avions d'ailleurs testé la X470D4U vendue 246 euros.
- Construisons un premier serveur 1U à base de Core i7-6700K, avec gestion distante (IPMI/iKVM)
- ASRock Rack dévoile deux serveurs AMD, une carte mère B550 et sa TOMMY
Comment en profiter pour jouer sous Linux ?
Pour notre premier essai nous avons opté pour une configuration assez simple, représentative de l'équipement d'un PC de joueur : une carte mère grand public et un processeur à partie graphique intégrée. Il s'agit ici de notre configuration de test Intel LGA1200 avec un Core i7-11700 sur une carte mère ASUS ProArt Z490-Creator 10G.
Pensez à activer dans le BIOS/UEFI les paramètres liés à la virtualisation (SVM chez AMD, VT-x/d chez Intel) et à indiquer la partie graphique intégrée du CPU comme sortie vidéo principale. Nous avons opté pour Ubuntu 20.10. Une fois installé il faut mettre à jour le système puis installer KVM et son gestionnaire de machines virtuelles :
sudo apt update && sudo apt full-upgrade
sudo apt install qemu-kvm virt-manager
Redémarrez ensuite la machine. Vous pouvez alors vérifier que vous avez bien activé toutes les fonctionnalités de votre CPU liées à la virtualisation dans le BIOS/UEFI avec la commande suivante :
kvm-ok
Il faut alors trouver l'identifiant de votre carte graphique au sein de votre système :
lspci | grep VGA
nvidia-smi
La première liste les périphériques graphiques, la seconde permet de détecter le statut des GeForce. Attention, elle ne fonctionne que si le pilote propriétaire du constructeur est installé. Cela peut être utile pour associer plus facilement l'identifiant indiqué plus haut à tel ou tel modèle de carte graphiques si vous en avez plusieurs :
L'identifiant de la GeForce RTX 3070 se termine par 01:00.0, celui de la RTX 3060 Ti par 4e:00.0, celui de la GTX 1650 par 4d:00.0
Le reste de la procédure est classique puisqu'il suffit de créer une machine virtuelle sous Windows 10 : lui indiquer où trouver l'ISO, les paramètres pour le CPU, la mémoire, le stockage, etc.
Il faudra néanmoins demander à personnaliser la configuration avant de lancer l'installation pour attribuer une carte graphique au système. Vous pourrez alors demander à ajouter un « périphérique hôte PCI » à la VM et sélectionner celui correspondant à votre carte graphique. Deux seront proposés, l'un finissant par 00.0 (le GPU), l'autre par 00.1 (son contrôleur audio). Ajouter les deux peut être utile, c'est à vous de voir selon votre besoin.
Notez que cette attribution de composants physiques à la VM peut être fait pour la plupart de ceux présents au sein de la machine, qu'il s'agisse des ports USB, du réseau, stockage, etc. Cela ne se limite pas à la carte graphique. Vous pouvez ainsi lui faire profiter d'un duo clavier souris spécial, d'un port réseau à 10 Gb/s, etc.
Une fois votre choix effectué, lancez l'installation de la machine virtuelle et de Windows 10. Téléchargez-y les pilotes de la branche 465 ou plus. Ils s'installeront sans erreur 43. Vous pourrez alors exploiter la carte graphique directement au sein de l'OS. Cela peut se faire de différentes manières. Localement le gestionnaire de machines virtuelles ou à distance avec le partage d'écran intégré de Windows (par exemple).
Ces outils ne gérant pas l'accélération 3D pour les jeux, le GPU ne peut être utilisé qu'à des fins de calcul via CUDA ou OptiX pour le rendu 3D par exemple. Une autre solution consiste à brancher un écran à la GeForce et à attribuer un duo clavier/souris en passthrough USB à la machine virtuelle. Vous obtenez alors un second PC !
Dernière option : opter pour une gestion distante exploitant l'accélération 3D, comme Parsec. L'outil est gratuit, simple à prendre en main, mais nécessite un compte pour être utilisé.
Trois PC dans un PC, c'est possible
Pour éviter d'avoir à maintenir un système complet si vous ne voulez que virtualiser des PC, il existe des hyperviseurs prêts à l'emploi. Nous avons ici utilisé ESXi/VSphere 7.0 de VMWare, simple à prendre en main et peut être utilisé gratuitement dans la limite de 8 cœurs CPU par VM. Un compte VMWare est nécessaire.
Un Ryzen Threadripper, trois GeForce... désormais plein de possibilités
Pour le tester, nous avons monté une carte mère TRX40D8-2N2T d'ASRock Rack (vendue 700 euros) avec un processeur Ryzen Threadipper 3960X (1 550 euros) doté de 24 coeurs et 32 Go de DDR4. Nous y avons connecté une GeForce RTX 3070, une RTX 3060 et une GTX 1650 pour monter jusqu'à trois VM avec GPU dédié.
Ici, il faut se rendre dans les paramètres matériels de l'hôte et cocher les case correspondant à chacune des cartes graphiques pour activer la fonction de relais. Un redémarrage sera nécessaire. Une fois active, cette fonctionnalité permet de distinguer les composants qui peuvent être attachés à une machine virtuelle.
La liste des composants pour lesquels le relais peut être activé (à gauche) et l'attribution à une VM (à droite)
Lors de la création de cette dernière, il faut ainsi demander l'ajout d'un périphérique PCI. Les cartes pour lesquelles le relais aura été activé seront présentes. Notez que vous pouvez faire pareil pour des ports USB, solutions réseau et autres composants connectés à l'hôte. Ils pourront ainsi les utiliser directement.
Vous devrez indiquer une quantité de mémoire réservée équivalente à celle attribuée à la VM. Pensez également à lui attribuer des cœurs principaux plutôt que ceux issus du multi-threading (0, 2, 4, 6, etc. en général), cela maximisera les performances. Nous avons ainsi pu créer trois VM chacune avec son GPU :
Les poupées russes, version PC pour joueur
Comme précédemment, la sortie vidéo de chaque carte graphique renvoie l'affichage de la machine virtuelle. Vous pouvez donc les connecter chacune à un écran et les utiliser localement. Mais avec autant de PC et si peu de ports USB, il est préférable d'utiliser un dispositif de contrôle à distance, avec ou sans accélération 3D selon le besoin.
Notez que nous avons effectué des essais similaires avec Unraid, sans rencontrer de problème particulier. Là aussi il suffit d'identifier la carte graphique afin de pouvoir ensuite l'attribuer à une VM :
Unraid permet de ne pas charger la carte graphique dans le système hôte puis de l'utiliser dans la VM
