SR-IOV - Intel Arc Pro B50 - Hohe 3D Auslastung, aber stockender Desktop

[Daniel [Karl_Pedross]]

Den Test von @Sim0n konnte ich bei mir nachstellen und bin zum selben Resultat gekommen. - GPU nur bei Virtueller CPU+ Bereitstellung des gesamten PCI Geräts an die VM.
In dieser Konstellation ist die Performance der Karte besser, der WUDFHost Prozess benötigt aber auch in Windows 11 immer noch ca. 12% GPU bei normalen Abläufen wie das scrollen durch einer größeren PDF-Datei.
Der Nachteil ist halt wie erwähnt, dass die VM beim reboot oder Problemen mit der Grafikkarte gerne mal den physischen Server abschießt.

@Bu66as ich hatte immer mit unterschiedlichen VFs pro VM getestet.
qm config war für die Windows Server und Windows 11 VM bei meinen vorherigen Tests identisch.
AMD-Vi-Faults kommen nur wenn ich die Physische GPU an eine VM durchreiche.
Der Test mit dem Treiberinstall auf einem Windows 11 PC hat wie von dir vermutet nichts verändert.

Also zusammengefasst:
Windows 11 funktioniert mit GPU nur wenn eine virtuelle CPU mit physischer GPU mitgegeben wird (bis Intel seine Treiberprobleme löst)
Windows Server 2022 funktioniert die GPU nur wenn die CPU von Typ "host" ist. Hier kann die GPU eine VF sein.
RBAR scheint im Intel Tool bei beiden Varianten als "Not Supported" auf

​

Nachgereicht: mein Test mit Furmark auf server 2022

 

[Bu66as]

Danke für die Erklärung. Für dein Ziel sieht das gar nicht schlecht aus: Server 2022 mit VF und CPU-Typ host läuft, Furmark bringt gute FPS, und nach dem was du sagst kommen die AMD-Vi-Faults nur noch beim kompletten Durchreichen. Am Anfang kamen die Faults und das resetting aber an der VF (05:00.2). Das hat wahrscheinlich das Kernel-Update auf 7.0.14-17 gebracht. Bei dir kamen die Bluescreens ja nur alle paar Tage. Würde die Logs noch 1-2 Wochen checken, bevor ich das abhake.

Das komplette Durchreichen würde ich sein lassen, wenn dir dabei regelmäßig der Server absäuft. Die Win11-Geschichte mit der virtuellen CPU ist der Intel-Treiberbug von @Sim0n und spielt für RDS eh keine Rolle.

Das "Resizable BAR: Not Supported" im Intel-Tool kannst du ignorieren. QEMU gibt die ReBAR-Capability dem Gast nicht durch, deshalb sieht der Treiber da immer "nicht unterstützt". Die 8 GB der VF sind trotzdem vollständig gemappt, siehe dein lspci.

Bei 12-20 % WUDFHost wäre ich nicht zu streng. Der Indirect-Display-Treiber rendert mit der GPU und encodiert jede Session, das kostet eben 3D-Last. Wichtig ist, ob der Desktop für die User jetzt flüssig läuft. Test mit mehreren Sessions parallel, die gleichzeitig scrollen. Stockt es dann noch wie am Anfang, oder war das mit dem Kernel-Update gelöst?