Récemment, grâce à l'amélioration des performances et des logiciels du GPU, il est devenu possible de démontrer des performances suffisantes même sous Windows dans un environnement virtuel s'il s'agit d'un jeu 3D général. Cependant, pour ce faire, vous devez toucher le GPU directement à partir du système d'exploitation dans l'environnement virtuel. Cette technologie est appelée pass-through GPU. L'intercommunication est possible avec les séries GeForce de NVIDIA et Radeon d'AMD, mais Radeon semble être plus facile à faire pour diverses raisons.
Cet article concerne la Radeon 5700XT. Cela peut être vrai pour d'autres produits, mais cela peut ne pas l'être. L'utilisation des informations est à vos propres risques.
En gros, [article Arch Linux](https://wiki.archlinux.jp/index.php/OVMF_%E3%81%AB%E3%82%88%E3%82%8B_PCI_%E3%83%91 % E3% 82% B9% E3% 82% B9% E3% 83% AB% E3% 83% BC) Ce n'est pas grave si vous suivez la rue, alors veuillez d'abord lire l'article.
Voici quelques conseils non mentionnés dans l'article.
Au moment d'écrire ces lignes (octobre 2020), un correctif est nécessaire pour le noyau Linux. Ceci est nécessaire pour contourner le bogue qui existe dans la série Radeon, communément appelé bogue de réinitialisation PCIe. Normalement, une réinitialisation est envoyée à l'appareil lorsque la machine virtuelle est fermée, mais la série Radeon semble avoir un bogue qui se verrouille dans un état étrange lors de la réception de cette commande. Dans une vraie machine, l'alimentation du PCIe est coupée, donc cela n'a pas d'importance, mais dans le cas d'une machine virtuelle, l'alimentation est coupée virtuellement (BACO), donc cela devient un problème. Pour éviter ce phénomène, vous devez effectuer une procédure spéciale pour réinitialiser l'appareil. Patch pour cela est fourni par des bénévoles. En appliquant ce correctif, vous pouvez redémarrer (terminer, démarrer le cycle) la machine virtuelle.
Le pilote Radeon vous invite à redémarrer votre machine immédiatement après l'installation. Il lance également un compte à rebours et tente automatiquement de redémarrer la machine virtuelle. À ce stade, redémarrez l'hôte (probablement parce que le matériel doit être réinitialisé). Il semble que le pilote ne puisse pas être installé avec succès simplement en redémarrant la machine virtuelle. Il n'y a pas d'avertissement particulier, mais une fois qu'il échoue, vous devrez réinstaller le pilote.
Il a cessé de bien fonctionner après la mise à jour du pilote vers le printemps 2020. La sortie de l'écran vers l'affichage n'est pas effectuée correctement et l'affichage la traite comme un état sans signal. Il y a une possibilité de ce phénomène et un dysfonctionnement du pilote, donc je l'ai laissé pendant un moment, mais rien n'indique qu'il sera corrigé même après plusieurs mises à jour, alors j'ai sérieusement cherché une solution.
Après de nombreux essais et erreurs, il semble que le pilote du GPU doive être trompé.
Si vous utilisiez llbvirt, vous deviez ajouter quelque chose comme <vendor_id state =" on "value =" 101 "/> à / domain / features / hyperv dans le fichier XML de votre machine. Si vous utilisez QEMU tel quel, il semble que vous deviez ajouter une option considérable.
Article Arch Linux
Il semble que presque la même opération que nécessaire. Cependant, <hidden state = 'on' /> n'était pas nécessaire.
Cela vous permet d'utiliser le GPU comme auparavant. De plus, la fonction d'enregistrement (Radeon ReLive), qui n'était auparavant pas disponible car l'élément n'apparaissait pas dans l'utilitaire du pilote, peut désormais être utilisée. Il y a aussi des choses comme ça ...
La zone autour du GPU est solidifiée avec propla, et maintenant cela fonctionne normalement, donc je suis satisfait de cet endroit.
Recommended Posts