Recently, due to improvements in GPU performance and software, it has become possible to demonstrate sufficient performance even in Windows under a virtual environment if it is about a general 3D game. However, to do so, you need to touch the GPU directly from the OS in the virtual environment. This technology is called GPU passthrough. Pass-through is possible with both NVIDIA's GeForce series and AMD's Radeon series, but Radeon seems to be easier to do due to various circumstances.
This article is about Radeon 5700XT. This may be true for other products, but it may not be. Use of information is at your own risk.
Basically, [Arch Linux article](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) It's OK if you follow the street, so please read the article first.
Here are some tips not mentioned in the article.
As of this writing (October 2020), a patch is needed for the Linux kernel. This is necessary to bypass the bug that exists in the Radeon series, commonly called the PCIe reset bug. Normally, it sends a reset to the device when the virtual machine is closed, but the Radeon series seems to have a bug that locks to a strange state when receiving this command. In a real machine, the PCIe power is turned off, so this is not a problem, but in the case of a virtual machine, the power is cut off virtually (BACO), so it becomes a problem. To avoid this phenomenon, you need to perform a special procedure to reset the device. Patch for that is provided by volunteers. By applying this patch, you can restart the virtual machine (termination, boot cycle).
The Radeon driver will prompt you to restart your machine immediately after installation. It also starts a countdown and automatically tries to restart the virtual machine. At this time, reboot the host (probably because you need to reset the hardware). It seems that the driver cannot be installed successfully just by restarting the virtual machine. There are no particular warnings, but once it fails, you will need to reinstall the driver.
It stopped working well after the driver update around the spring of 2020. The screen output to the display is not performed well, and the display treats it as a no-signal state. There is a possibility of this phenomenon, driver malfunction, etc., so I left it for a while, but there is no sign that it will be fixed even after multiple updates, so I seriously searched for a solution.
As a result of various trials and errors, it seems that it is necessary to deceive the GPU driver.
If you were using llbvirt, you had to add something like <vendor_id state =" on "value =" 101 "/> to the / domain / features / hyperv in your machine's XML file. If you are using QEMU as it is, it seems that you need to add a considerable option.
Arch Linux Article
It seems that almost the same operation as is required. However, <hidden state ='on' /> was not needed.
This allows you to use the GPU as before. In addition, the recording function (Radeon ReLive), which was previously unavailable because the item did not appear in the driver utility, can now be used. There are also things like this ...
The GPU area is solidified with proprietary software, and now it works normally, so I'm satisfied with this place.
Recommended Posts