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
Commentaires (63)
#1
C’est génial !! Fini l’erreur 42 😎
#2
43 #RTFN ;)
#3
Cool ça !
Avant que je me lance, les vieilles génération de carte graphiques sont-elles prisent en charge ? Faut-il nécessairement que le driver nvidia soit installé sur l’hôte pour la CG qui sera utilisé par la VM ?
Je demande car ma seconde CG est très ancienne (GT620 ou GT710 sait plus) et le driver nvidia le plus récent ne prend plus en charge cette carte (et j’en ai besoin pour ma principal…)
#4
Oups en effet j’ai hésité x), juste une question, comment vous avez determiné que les processeurs impairs sont ceux du SMT ?
Merci pour le super article.
#5
A noter qu’il existe des solutions pour ne pas avoir à switcher de clavier+souris+écran.
J’ai perdu le nom et c’était assez confidentiel, je me demande ou ça en est rendu maintenant tien.
#6
Tout ce qui est pris en charge par les pilotes 465.x peut en bénéficier
C’est la règle en général, mais bon au pire il suffit de tester, la différence de performances est notable
#7
J’ai retrouvé, c’était
https://looking-glass.io/
Mais je ne sais pas si c’était la seule solution?
#8
La limitation était dans le pilote NVidia, donc un passthrough pour un invité Linux ne devait pas présenter de problème si on utilisait le pilote open source, non?
Par ailleurs, je ne sais pas si la procédure marche dans tous les cas, car d’habitude je dois indiquer au système de ne pas charger les pilotes des cartes que je mets en passthrough (notamment les cartes Wifi/réseau). Là comme la carte principale est celle intégrée au CPU, ubuntu ne charge pas les pilotes NVidia, c’est cela?
Si tu as un PC en intel et en dual channel, la CG intégrée au CPU sera certainement proche voire meilleure que ces cartes NVidia (à partir de la HD 520⁄530, Intel fait généralement mieux que la Geforce - avant c’est très variable). Et le passthrough marche très bien.
#9
Pas de CG intégré sur mon Xeon E5-2690
#10
L’intérêt est impressionnant mais peu utile pour les gamers. Honnêtement je dois avoir un seul jeu qui ne tourne pas sous linux. Merci a Steam et lutris
#11
La dernière fois que j’ai regardé c’était assez laborieux à l’installation (tout du moins bien plus qu’un parsec). Je ne sais pas trop si ça a évolué depuis (de ce que j’ai regardé sur le dépôt rapidement, ça semble maintenu sans avoir trop évolué sur ce point).
Oui après Lutris dans certains cas tu es sur du Wine, donc avec une couche entre l’OS et le jeu qui impacte sur le rendu/performances. Dans tous les cas, c’est une alternative en plus, à chacun de faire comme il souhaite selon ses besoins (surtout que du coup on peut avoir un client léger pour le jeu tout en continuant d’avoir le PC qui tourne sur autre chose).
#12
Sur la plateforme epic, chez moi rare sont les jeux qui veulent bien ce lancer ou fonctionner avec lutris. :(
#13
Je viens de regarder une vidéo qui explique le truc, ça ne semble pas énorme.
En gros le client à compiler.
Et 2 pilotes à installer côté HOST.
Ok ce n’est pas aussi “simple” que parsec, mais pas besoin de compte, et on reste en interne.
A tester pour voir ce que ça donne de nos jours?
#14
Le petit problème pour les gamers vient majoritairement du problème des anti-cheats.
Beaucoup de jeux dispo que sur Windows et pas jouable sur Linux même via Proton ou Wine ont un AC très chiant. Et ils tirent a vu sur les VM, qui plus est. Donc une bonne idée pour jouer, mais pas a tout les jeux possible quoi.
#15
Oui et donc toutes les dépendances de compilations à récupérer, etc
Après c’est la limite des projets fait dans un coin sans prise en compte du besoin utilisateur.
En général j’essaie de trouver quand même des solutions un peu plus user-friendly. Je comprends que la dépendance au compte de parsec rebute, mais tant qu’à regarder du côté d’une alternative, je préfère avoir une solution moins bidouille du dimanche à proposer.
Oui c’était un des soucis de shadow, qui a du bosser avec les éditeurs pour éviter de voir ses clients se faire jeter des plateformes en ligne.
#16
Ubuntu charge les pilotes de tous les GPU présents, et ça peut être un problème selon le matériel, le reset PCI n’est pas forcément bien supporté par toutes les cartes graphiques (c’était un gros soucis chez AMD jusqu’aux Navi par exemple) et il vaut mieux binder ces périphériques sur le pilote vfio pour éviter les problèmes. Ça se fait dans un fichier modprobe.d
Sinon pour un retour plus global, perso je joue comme ça en VM Windows depuis plus de trois ans, c’est un projet intéressant si vous voulez découvrir un peu la virtualisation, qemu et KVM, mais entre les jeux qui refusent de se lancer en VM, les soucis de performances pas toujours simples à comprendre, et le glissement de l’optimisation où on rajoute de plus en plus de matériel dédié à la VM (GPU, disque, USB, réseau), on se retrouve facilement avec un PC qui coûte le prix de deux configs standards. Je conseillerais pas ça pour économiser du temps ou de l’argent. Et encore, ça s’est pas mal amélioré, il y a encore quelques années fallait patcher qemu pour que son driver Pulseaudio fonctionne correctement et autres joyeusetées
#17
Petit rappel, il est possible d’activer directx sur le GPU via RDP:
RemoteFX (Tuto pour faire une VM windows avec GPU sur un laptop)
Et depuis peu NVIDIA propose un patch pour ses drivers “gamer” pour faire pareil avec OpenGL:
News Khronos (Vulkan) qui en parle
Pour le premier je l’utilise depuis plusieurs années au bureau, ça marche nickel.
Le deuxième ça fait un mois, et ça marche aussi bien qu’avec une Quadro.
(Fedora + VM windows pour le dev de traitement d’images médicales)
#18
Oui, d’expérience il est quand même préférable d’utiliser un hyperviseur dédié plutôt qu’un OS classique avec QEMU/KVM si on veut utiliser ça de manière régulière et importante.
#19
La dernière fois que moi aussi j’ai testé c’était assez facile : installation depuis le gestionnaire de paquet (merci Aur), 2 lignes dans la conf de la vm et un exe à lancer au démarrage de la session Windows sur la VM.
Hélas le support des cartes nVidia a été retiré car l’usage est interdit sur les cartes grand public.
Gageons qu’avec ce mini revirement, cela change.
#20
C’est plus propre et simple ouais, mais la bonne solution va varier selon les goûts, le matériel et le cas d’usage. J’ai fini sur une Debian sid avec libvirt un peu par affinité, mais ça me permet de garder un setup encore un peu raisonnable en gardant mon OS principal sur l’hôte. Dans un setup idéal, je suppose que j’aurais deux GPU, deux disques NVMe, un pour Linux, un pour Windows, les deux virtualisés, mais c’est le genre de montage qui risque de demander des plateformes type Threadripper pour bien fonctionner, autrement on se frotte assez vite aux limites de pistes PCI, sans parler du coût de la machine.
Avoir un Linux en hôte a aussi quelques avantages fonctionnels, par exemple ça me permet de facilement mélanger le son des VM avec celui de l’hôte à travers le pilote Pulseaudio de QEMU, y compris quand je change les sources de l’écran et coupe donc le canal audio HDMI de la VM. Sachant que ça marche dans les deux sens, la VM peut facilement aller taper sur le micro si j’ai besoin de voice chat directement dans un jeu.
Je sais pas si VMware ou Proxmox permettent facilement de mixer le son des invités, j’ai un peu peur que ça risque de partir dans des montages hardware compliqués utilisant le canal audio HDMI ou des cartes son dédiées en PCI ou USB. Ou alors impose un outil avec stream audio bidirectionnel à travers le réseau, type Parsec.
#21
ça dépend si un paquet compilé existe ou pas quoi.
Or dispo dans AUR chez ARCH.
Dispo compilé chez openSuse: https://software.opensuse.org/package/looking-glass-client
Faut voir pour les autres distribs mais ce n’est pas non plus aussi rébarbatif.
Même à compiler ce n’est pas non plus la mort.
Surtout qu’on peut le compiler dans une vm si on veut ne pas pourrir son pc de dépendances etc.
#22
Un bon vieux KVM physique ? ^^
Ah ba non ça va pas marcher pour les USB…
#23
#24
Oui mais la en l’occurrence c’est pour swaper d’une machine a une autre sans changer de prise USB source. Un KVM au niveau de l’hyperviseur si j’ai a peu près compris. A la rigueur il faudrait utiliser une carte contrôleur USB dédié sur la seconde machine pour qu’un KVM classique fonctionne.
Mais j’ai du mal a saisir l’utilité de Looking Glass… ou plutôt dans quel cas de figure on aurait besoin de ça.
#25
#26
Mmmmh… du RDP et puis hop non ?
Ou alors le compromis, KVM logiciel. Sharemouse, Synergy ou autre mais avec un écran par OS.
J’ai bien compris l’idée en fait mais je vois pas bien un cas concret d’un réel besoin de cette solution.
#27
question du débutant : ça marche aussi avec les pilotes Studio Driver ? Ou seulement avec les pilotes Game Ready Driver ? (Précision pour une RTX 2070 Super en version Desktop)
#28
Il n’y a pas encore de pilote Studio en branche 465
#29
T’as déjà essayé de jouer ou regarder des vidéos via RDP?
Le but de l’article ici c’est de pouvoir jouer ou utiliser un gpu dédié sur une vm, comme si c’est natif.
IL semble y avoir DDA mais encore une fois c’est pour un host windows.
Je ne connais pas bien ce que permet de faire RDP mais perso dans tout ce que j’ai pu voir ça ne rendait jamais comme du natif. Ne pas oublier non plus que le guest est un windows 10, donc voir ce que permet aussi windows 10 comme prise en main.
LE cas est simple:
Je veux jouer ou utiliser une application 3D avec des perfs natives, sans avoir à rebooter, ou sans avoir à dédier un écran + clavier souris à une vm.
Bref comme tu le ferais avec une vm standard.
#30
RemoteFX va être remplacé effectivement. Mais oui c’est dégueu sans.
Oké, ba je cherchais des applications professionnelles (imagerie médicale, cinéma, …) mais oui en fait quand on parle de jeu ça match
Chui’ déjà fatigué et on est que mercredi…
#31
cf mon commentaire d’avant, le tuto RemoteFX montre les perfs, je m’en sert tout les jours au boulot, a part un tout petit peu de tearing, ça se voit pas (réseau 10gb en interne donc pas besoin de compression)
sinon une autre solution c’est de mettre un dongle HDMI a 5 euro et d’utiliser nomachine
#32
C’est une bonne nouvelle tout ça, en espérant qu’on arrive un jour à avoir à nouveau assez de CG disponibles pour acheter la deuxième
#33
Remotefx est obsolète et désactivé depuis le 1er février dans les nouveaux Windows, en attendant d’être remplacé par DGA (si je ne me trompe pas)
#34
Bah tout ce qui est création 3D, montage vidéo. Il y a moultes possibilités.
Mais bon les jeux vidéos ça parle souvent facilement et rapidement.
#35
Ok, mais sur le principe… Sais-tu si ça devrait marcher ou pas aussi avec les Pilotes Studio ? Dans la note de blog, je ne vois rien à ce sujet.
#36
Un pilote Studio n’a rien de spécial, il a juste des branches d’optimisations différentes dans le temps par rapport aux Game Ready. Comme dit, tous les pilotes 465+ sont concernés par cette annonce.
#37
Merci très intéressant et bien détaillé
J’ai appris récemment qu’on ne pouvait pas faire de GPU passthrough sur un PC Portable. C’est bien dommage. Est-ce qu’on peut envisager un futur proche ou le GPU passthrough fonctionnerait sur un pc portable ?
#38
Oui et non :)
RemoteFx contient 3 technos, celle qui est deprecated est celle du vGPU.
Celle dont je parle c’est le codec: https://en.wikipedia.org/wiki/RemoteFX
#39
Tu peux mais sous certaines conditions matérielles. Y’as un tuto dans mon premier commentaire.
#40
Tu as vu ça où (la spécificité sur les portables) ? En tous cas ici c’est précisé comme fonctionnel sur les GPU mobiles tant qu’ils sont supportés par les pilotes 465+.
#41
Bien que Steam a atteint les 50 % de jeu Platinium avec Proton, il reste quand même un sacré paquet de jeu en Bronze ou borked, donc ça peux être utile.
Il faut aussi noter que le single-GPU passthrough est quelque chose de possible mais un peu compliqué à mettre en place.
#42
Article très intéressant.
Le noob que je suis s’était renseigné sur la possibilité de jouer dans une VM Windows derrière un hyperviseur. (pour ma passer du dual boot “traditionnel” et ses reboot intempestifs)
C’est à cette occasion que j’avais découvert le principe du GPU Passthrough mais dans mes souvenirs c’était compliqué et un peu trop velu pour moi.
Je vais peut être me replonger la dedans…
#43
J’essaie de comprendre donc au quotidien t’as une carte graphique sur laquelle rien n’est branché (il faut utiliser l’IGP)
Quand tu démarres la VM il faut utiliser RDP avec Remote FX ou solution équivalente pour récupérer le flux ou utiliser un KVM hardware et tout brancher en double sur la bécane (note: certains écrans USB-C font KVM)
Question, quand la VM est éteinte le GPU est utilisable par l’hyperviseur ? Peut-on affecter un même GPU dans 2 VM (à condition de pas les faire tourner en même temps)
J’ai quand même du mal à voir un cas d’usage sur un PC : s’il faut dupliquer presque tout le hardware autant simplement prendre un boitier double-configs.
#44
Tu peux brancher ce que tu veux à la carte graphique renvoyée à la VM, elle envoie les images calculées à sa sortie vidéo comme si de rien n’était. Donc un écran affichera le résultat. Tu peux aussi opter pour une gestion distante, avec ou sans rendu 3D selon les cas.
Je ne comprends pas trop ta question par contre. Si la VM est éteinte, le GPU n’est pas lié à une VM, donc elle peut être utilisée autrement. Pour les cas d’usages, comme je dis souvent : si tu n’en vois pas, c’est que ça ne t’est sans doute pas utile. Ce qui ne veut pas dire pour autant que ça ne sert à rien.
PS : la différence principale avec une solution double configuration, c’est justement de ne pas avoir besoin de deux configurations. Seul le GPU est dédié dans cet usage, le reste peut être mutualisé.
#45
merci de penser aux autres gamers et il y a pas que Steam dans la vie ;)
#46
ça dépend les versions d’optimus, il y a des versions d’optimus ou c’est difficile voir non réalisable.
Il me semble que c’est la version d’optimus ou le gpu nvidia est branché via le gpu intel (c’est le cas sur mon clevo à base de intel 4600hd + 960gtx).
Il faut vraiment pouvoir dissocier les deux pour que ça puisse marcher et il faut que la sortie HDMI soit rattachée au gpu nvidia pour que ça marche si je ne me trompe pas. (or dans mon cas elle est rattachée à l’igp)
#47
Oui là ça peut jouer sans doute, je ferai de toutes façons quelques essais pour voir, vu que je vais reparler d’optimus sous peu
#48
Le PCIe passthrough fonctionne sur portables, mais ce sont les mêmes restrictions que sur un PC fixe: chipset qui le supporte, CPU qui le supporte, et BIOS qui te donne accès aux bonnes options.
#49
De toute façon c’est simple OPTIMUS “ça pue c’est pas libre”!
Blague à part, je n’ai jamais compris l’intéret d’optimus et des solutions igp sur pc portable (sauf l’ultra compact). :/
Même niveau consommation ça ne gagne pratiquement rien voir même en pratique dans mes tests c’était l’inverse. :/
Difficile de faire un test poussé, mais quand j’ai fais le test sur un intel 4570S Vs une 5400hd, ben en idle, avec l’igp intel ça consommait plus que IGP Intel off + 5400hd. (mesure à la sortie de l’onduleur).
C’est le genre de tests qui ne sont plus fait, mais je suis persuadé qu’un gpu récent avec un cpu sans igp, consomme au pire presque rien de plus pour des perfs énormément supérieures. :(
(pas de bride de TDP commun entre les deux, pas bride de la DDR4, diffusion de la chaleur répartie etc).
En dehors du cas des machines extrêmement compact ou on peut se dire ok restons “juste” sur un igp, dès que c’est possible je trouve toujours ça largement mieux d’avoir un gpu dédié même d’entrée de gamme. :( Il “suffirait” de pouvoir brider le gpu à l’équivalent de ce qu’apporte un igp pour avoir les mêmes conso maximale.
Malheureusement ça n’existe même plus à chaque fois on se tape un igp + un gpu dédié dans un pc portable. :(
#50
Pourtant c’est simple : tu as une seule sortie vidéo, mais tu peux alterner entre l’IGP et le GPU à la volée, pour adapter aux usages, besoins de conso, etc. Après le souci d’Optimus a longtemps été son intégration douteuse dans certains design. Pour le reste c’est plutôt pratique.
PS : un GPU même récent consomme plus qu’un IGP. Et on ne peut de toutes façons pas comparer desktop et laptop comme tu sembles le faire (surtout su de si vieux composants, vu les optimisations ces dernières années).
#51
Je comprends bien le principe et l’intéret en théorie.
Mais en pratique la différence de consommation est négligeable en usage léger au détriment de tous les emmerdements en découlant.
Je compare ce que j’avais pour comparer, pour pouvoir comparer sur pc portable il faudrait être sûr qu’en étant sur le gpu dédié l’igp soit TOTALEMENT éteint, et je n’ai pas trop suivi comment c’était branché récemment mais jusqu’à récemment il y avait forcément l’igp de toujours allumé au mieux faussant forcément totalement la comparaison.
Donc oui le seul test que j’ai pu faire c’est:
IGP de 4560S vs HD5400, et bien en idle et charge légère contrairement à ce qu’on peut croire c’est le couple CPU 4560S + GPU dédié qui consomme le moins, l’igp consomme donc plus que le gpu dédié…
Il n’existe plus de “petits” gpu récents ce qui complexifie grandement la chose pour comparer de nos jours, mais perso je n’ai JAMAIS vu de réel gain ou au mieux négligeable.
Les seuls tests fait c’était toujours en jeu tout ça. Mais forcément si tu compares un truc qui est 2 ou 3 fois plus perf que l’igp…
#52
Tu imagines bien que si les constructeurs de GPU font ça, c’est que l’utilité pour l’implémentation dans les portables n’est pas anodine. Pour le support dans les OS, ça c’est tout de même bien amélioré avec les années et les nouvelles intégrations.
#53
“oui et non”, s’il n’y avait que des choses n’étaient qu’en notre faveur ça se saurait….
Comme dit, je ne critique pas l’igp dans le cadre de l’ultra compact, ou de l’autonomie maximale.
(quoi que comme dit niveau autonomie maximale je demande à voir réellement avec un gpu moderne pensé dans cet optique d’autonomie…)
Je dis juste que dans une grande majorité de cas, le gain est négligeable, et que dans énormément de cas, à partir du moment ou on rajoute un gpu dédié, les solutions optimus and co apporte très peu de choses voir rien du tout. Le ratio emmerdement/inconvénients/gain se retrouve franchement à chaque fois en faveur d’un simple gpu dédié. (ça n’est que mon simple avis mais par rapport à tout ce que j’ai pu tester comme pc portable ça reste ce que je constate)
Je critique donc le fait que sur pc portable on n’a le choix que avec un full IGP, ou (IGP + GPU dédié).
Il n’y a plus de choix de CPU + GPU dédié seul avec un panel de GPU dédié.
Et si ce choix est fait, c’est principalement par “facilité”. Il n’existe plus de gpu d’entrée de gamme récent (coup de développement etc) , c’est plus simple à monter un systême de ventilation basique avec ça, on se fait pas chier à essayer d’optimiser à fond le gpu pour qu’il soit économe en usage léger etc.
Il en est de même sur pc fixe, même pour un usage “bureautique simple”, je mets toujours un gpu dédié même d’entrée de gamme tout simplement parce que le TDP se retrouve trop souvent trop limite pour que les deux puissent être bien exploités.
Mais je suis hs sur ce topic.
#54
Attention avec la notion de “négligeable” dans un portable, ça fait vite un effet côté autonomie où les constructeurs grapillent parfois au watts près sur la consommation au repos. Sinon il y a des PC avec processeurs sans partie graphique sur portable aussi, ça répond sans doute à ton besoin.
Pour les GPU d’entrée de gamme, il y en a des récents, mais leur architecture est en décalage de phase avec le reste du marché, forcément. Surtout que les IGP sont aussi performants désormais dans certains cas. Voir le cas d’Intel qui a décidé d’intégrer deux Xe plutôt que de faire un GPU spécifique.
#55
Des cpu sans igp sur pc portable tu n’en as presque plus.
Il doit exister quelques “transportables” mais je ne parle pas de portable réellement.
Les gpu d’entrée de gamme tu as très peu de vrais récent.
La 1030 est ce qui serait le plus récent mais avant ça il s’est passé de nombreuses années sans voir de gpu. Toujours les mêmes gpu renommés… Chez amd rien de récent. :/
La solution à chaque fois pour avoir un moteur vidéo correcte, taper sur le milieu de gamme de la gamme précédente.
Comme dit, il faudrait voir l’impact réel, mais le gros problème des igp restera toujours la mémoire vive qui le bride un max (il suffit justement de voir les Perfs de l’intel XE avec de la ddr… Il n’arrive à commencer à se démarquer qu’avec de la LPDDR4X. (donc encore un bordel soudé, on reste encore dans le cas d’utilité de l’ultra compact)
Mais même là, tu vois très vite que le TDP bride le tout ou la température.
Je suis persuadé qu’un gpu récent “bridé” (et pas poussé à fond pour sortir quelques mhz de plus comme on fait souvent maintenant) pour avoir un bon ratio perf/conso pourrait permettre d’avoir un truc beaucoup plus perf qu’un igp, avec une consommation négligeable sup en usage léger.
Oui la notion de “négligeable” est subjectif, mais je demande vraiment à voir.
Encore une fois ça n’est que mon avis, mais par rapport à tout ce que j’ai testé en pc portable, pu voir niveau tests etc, c’est à chaque fois ce que je me dis.
Mais cela reste de toute façon ultra compliqué de se faire un avis récent, puisque plus rien ne permet de faire cette comparaison.
#56
Je ce conseille ce lien qui résume à peu près tout ce qu’il est possible de trouver sur la question.
#57
il reste plus que parsec accepte de fonctionner sur avec un serveur headless et ce sera parfait.
#58
les IGP AMD sont basé sur Vega, ce sont donc des modèles “castrés” de leurs cartes graphiques, pareil pour Xe qui est la base technologique des futures cartes Intel.
#59
Je sais.
Je parlais d’avoir l’équivalent en gpu dédié. Un peu plus gros sans tomber sur du vega 56⁄64. (d’ailleurs navi se porte mieux à la chose car plus économe, donc plutôt un gpu navi 6400/6200M)
Car comme dit le gros problème des IGP étant la bande passante vers la mémoire vive sauf à accepter la LPDDR4X donc mémoire vive soudée et même là on est vite limité.
#60
En vrai la bonne question est : pourquoi faire un GPU au niveau des IGP ?
Le but des IGP est d’apporter une base stable pour le quotidien et un tout petit peu plus si possible. Qu’apporterait un GPU avec sa bande passante meilleure ? Les performances 3D resteraient trop faible pour être une vraie station de travail/jeu et le décodage/encodage vidéo est déjà délégué à des circuits dédiés pour augmenter l’efficacité. En plus une puce supplémentaire demande effectivement un câblage supplémentaire sur la carte mère et donc des composants électroniques, mécaniques et de refroidissements, supplémentaires. l’IGP apporte des avantages incontestables pour le design de la carte mère et le refroidissement de la machine pour une perte de performances limité vis à vis d’un petit GPU.
Si le but est d’avoir un GPU dédié capable de se brider tout seul au niveau d’un IGP et de se débloquer au besoin je pense que les constructeurs doivent plancher dessus depuis un moment mais que ça reste hors de portée pour l’instant.
En tout cas Optimus j’en vois l’intérêt au taf. Une personne qui fait de la CAO a un portable équipé d’un GPU, la différence d’autonomie quand il lance son soft avec l’IGP ou le GPU n’est pas négligeable, il gagne facile une heure avec l’IGP.
#61
On va essayer de le faire simple.
Ce que je déplore c’est qu’on a rien “entre” l’igp et (IGP + GROS GPU de jeu).
Ce que je disais c’est qu’il manquait un truc au milieu, qui aurait un poil moins d’autonomie (de pas grand chose je parie si c’est bien travaillé) mais qui serait un poil plus perf niveau gpu.
La question ne se pose pas quand tu veux mettre une 3060 ou un gros truc.
Mais il y a un gouffre entre un IGP et une 3060.
Par exemple, j’aurais bien aimé avoir un 4800H sans IGP avec une RX 6400 4go un truc réglé pour pas trop consommer. ET je ne suis pas persuadé qu’en usage basique il y aurait une grosse dif de conso. Elle serait là mais pas non plus énorme surtout avec un mode basse conso pour brider le gpu si vraiment on veut faire au mieux.
C’est le compromis qui manque, compromis que je trouve bien plus judicieux que l’igp.
Analogie merdique, c’est comme dire t’as:
Bah t’as la voiture citadine.
Et si tu veux plus de place ben t’as la citadine + remorque ça va très bien.
Bah non, je préfère prendre une compact, ça me convient mieux comme compromis.
Malheureusement on parle dans le vide car aucun test récent ne fait ce genre de chose pour voir l’évolution des consos avec ou sans igp voir ce que consomme des cartes modernes.
Cartes qui ne sont pas pensées pour consommer peu, mais souvent conçue pour sortir le maximum de perf.
#62
Merci c’était bien ma question : donc la carte n’est pas “bloquée” par le superviseur si la VM est éteinte. Et donc je suppose qu’il est possible d’affecter une unique carte à deux VM (tant qu’elles ne tournent pas en même temps), du coup, c’est pas trop mal (même si je ne suis probablement pas le public visé :) )
#63
Il faut essayer Heroic Game Launcher alors :)
https://github.com/Heroic-Games-Launcher/HeroicGamesLauncher
(pas compatible avec les jeux utilisant EAC par contre)