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

D

Daniel [Karl_Pedross]

New Member
Sep 14, 2026
12
2
3
Hallo zusammen,

Seit kurzem haben wir Proxmox 9.2 auf einem DL385 Gen 10 Plus laufen.
Ziel dieses Servers ist unter anderem Terminalserver Windows 2022 mit GPU auszuführen.
Jetzt haben wir aber bemerkt, dass bereits ein einzelner Benutzer in der Lage ist mit etwas so trivialem wie scrollen in einer text-PDF die Grafikkartenauslastung auf 100% zu treiben. Die Performance ist dann entsprechend für alle Benutzer auf diesem Server entsprechend schlecht.

Dieser Server ist mit einer Intel Arc Pro B50 ausgestattet welche mittels SR-IOV an die VM durchgereicht wird.
Aktuell wird die GPU in zwei virtuelle Instanzen aufgeteilt, es wird jedoch nur eine Instanz genutzt.

Was ich bisher herausfinden konnte:
- Die Grafikkartenauslastung scheint rein vom Prozess WUDFHost zu kommen(screenshot unten).
- Die übermäßige Auslastung der 3D Engine bei gleichzeitiger 0% Nutzung der restlichen Grafikkartenmodule deutet auf ein Problem bei der Kommunikation zwischen VM und Grafikkarte hin.
- Es gab in den letzten zwei Wochen auch 2 Bluescreen "KERNEL SECURITY CHECK FAILURE" welche laut Journalctl mit einem reset der virtuellen Grafikkarte korrelieren
Die Fehlermeldungen im Log waren: kernel: vfio-pci 0000:05:00.2: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0054 address=0x182e0de82000 flags=0x>
und kernel: vfio-pci 0000:05:00.2: resetting


Hat jemand von euch eine Intel GPU mittels SR-IOV korrekt zum laufen bekommen?
Welche Schritte könnt Ihr mir empfehlen um das Problem zu lösen?

Vielen Dank für eure Hilfe

1789541285545.png
1789541308138.png
1789541595027.png
 
Ich hab hier so eine Karte liegen und auch schon ein paar rudimentäre Tests damit gemacht.
Wenn du aktuell nur die "halbe" Karte nutzt würde ich erst mal vorschlagen zum Test die Karte nicht aufzuteilen und als ganzes durch zu reichen.
Damit könnte man einfach mal testen ob es vielleicht ein Treiber Problem ist.
 
Das x-vga=1 an der VF würd ich als erstes rausnehmen. Das ist für klassisches Primär-Passthrough mit Legacy-VGA gedacht, eine SR-IOV-VF hat sowas gar nicht, und mit OVMF brauchst du es ohnehin nicht. Kann gut sein dass da ein Teil der Resets herkommt.

Die IO_PAGE_FAULTs und das resetting sind sowieso das eigentliche Thema, die 100% auf der 3D-Engine sind eher Folge als Ursache. Welcher Kernel läuft bei dir (uname -r) und wie legst du die VFs an, über sriov_numvfs am xe-Treiber oder per DKMS-Modul? Da hat sich neulich viel getan und B50-SR-IOV ist noch ziemlich frisch. Firmware/BIOS vom DL385 auch mal auf aktuellen Stand prüfen, IOMMU-Page-Faults auf EPYC kommen erstaunlich oft aus dem Firmware-Stand und nicht aus dem Gast.

Zum WUDFHost: das ist der Indirect-Display-Treiber von RDP, die Last kommt also aus dem Session-Composing/Encoding, nicht vom PDF-Viewer. Auffällig finde ich dass im Taskmanager gar keine Video-Encode-Engine auftaucht, nur Decode und Processing. Wenn die VF kein Encode rausreicht, läuft der komplette RDP-Pfad über 3D plus CPU, und dann reicht schon Scrollen aus. Spiel mal per GPO mit Use hardware graphics adapters for all Remote Desktop Services sessions und AVC444 (an/aus), das verschiebt die Last spürbar. Und wenn eh nur eine Instanz genutzt wird, würd ich die VF-Anzahl auf 1 stellen.
 
  • Like
Reactions: Sim0n
Bu66as said:
x-vga=1

Welcher Kernel läuft bei dir (uname -r) und wie legst du die VFs an. Firmware/BIOS vom DL385 auch mal auf aktuellen Stand prüfen, IOMMU-Page-Faults auf EPYC kommen erstaunlich oft aus dem Firmware-Stand und nicht aus dem Gast.

Spiel mal per GPO mit Use hardware graphics adapters for all Remote Desktop Services sessions und AVC444 (an/aus), das verschiebt die Last spürbar. Und wenn eh nur eine Instanz genutzt wird, würd ich die VF-Anzahl auf 1 stellen.
Click to expand...

x-vga ist jetzt deaktiviert, am Verhalten ändert dies jedoch nichts.
Kernel ist 7.0.14-12-pve.

Die VFs habe ich über sriov_numvfs angelegt

Firmware vom Server müsste recht aktuell sein: System ROM: A42 v3.92 (11/27/2025). Gerade lädt die HP Seite nicht ich würde später nochmal checken ob es etwas aktuelleres gibt.

Bezüglich der GPOs:
Use hardware graphics auf "disabled" bewirkt, dass der WUDFHost Prozess keine Grafikleistung verbraucht, wahrscheinlich weil die Benutzersitzung die Grafikkarte überhaupt nicht nutzt. Bei allen weiteren Tests war diese GPO deswegen auf "ein"
AVC 444 an/aus scheint nichts zu verändern
H.264/AVC hardware encoding an/aus scheint auch nichts zu bewirken

Das Rückstellen der sriov_numvfs = 1 kann ich leider erst am Abend testen.

Eine durchreichen der kompletten GPU per PCI ist daran gescheitert, dass bei einem Neustart der VM der komplette Server mit der Fehlermeldung "Uncorrectable Machine Check Exception" abstürzt neu bootet.
Rein konzeptionell hätte ich auch dahingehend geplant, dass sich zwei RDS Server eine GPU teilen.
 
Die Virtualization Options auf dem Screenshot passen so, würde ich nichts dran drehen. Interessanter ist das Above-4G-Decoding bzw. Resizable BAR bei der PCIe Device Configuration für den Slot. Arc-Karten mögen es gar nicht wenn sie nur den kleinen BAR-Bereich kriegen, und mit SR-IOV muss der Adressraum für alle VFs reichen. Schau mal mit lspci -vvs 05:00.2 wie groß die BARs an der VF tatsächlich sind. Den MCE beim kompletten Durchreichen würde ich nicht als Hardware-Defekt sehen, sowas kommt beim Passthrough fast immer vom Bus-Reset oder der BAR-Zuweisung, nicht von kaputtem RAM.

Beim fehlenden Encode: check mal im Host-dmesg nach GuC/HuC (dmesg | grep -iE 'guc|huc'). Wenn die HuC nicht geladen ist, gibt's kein Hardware-Encode, dann läuft genau das was du siehst – alles über 3D plus CPU. Das erklärt auch warum die GPO-Schalterei nichts bewirkt.

Zieh mal den Kernel hoch, 7.0.14-12 ist nicht mehr der neueste, hier läuft 7.0.14-15. Am xe-SR-IOV wird aktuell viel gefixt, das kann durchaus den Unterschied machen. Welchen Arc-Treiber hast du im Gast drin?
 
Intel listet die Arc Pro B50 bzw. den aktuellen Arc-Pro-Windows-Treiber offiziell nur für Windows 10/11, nicht für Windows Server 2022. RDSH 2022 kann GPU/H.264 grundsätzlich, aber die konkrete B50-Treiberkombination ist damit offenbar außerhalb der von Intel gelisteten OS-Unterstützung.

Ich würde deshalb als nächsten Test exakt dieselbe VF einmal an eine Windows-11-VM hängen. Wenn dort PDF-Scrolling/D3D/QSV sauber läuft und keine AMD-Vi-Faults entstehen, würde ich nicht mehr bei Proxmox suchen, sondern bei Server 2022 + Intel-Treiber/RDP.

Zusätzlich bitte einmal die genaue Intel-Treiberversion/Firmware und lspci -vv -s 05:00.2 posten. Intel spezifiziert für den aktuellen B50-SR-IOV-Stack zwei VFs mit jeweils 8 GB Local-Memory-BAR. Interessant wäre, ob die VF den BAR auf dem DL385 tatsächlich sauber zugewiesen bekommt.
 
ReBAR beim DL385 Gen10 plus würde mich auch sehr interessieren da mein Testsystem auf einem DL380 Gen10 läuft und bei dem funktioniert ReBAR definitiv noch nicht...

Zum EFI: Das "Workload Profile" unter "BIOS/Platform Configuration Options" soll auf jeden fall auf "Virtualization" stehen, HP Stellt da im Hintergrund einiges um, je nach Profil.

Was mir ins Auge springt ist die PCI-Option "PCIe Error Control" ich denke die sollte wohl auf OS Control stehen, weil ja Geräte durchaus Fehler produzieren wenn eine Gast-VM mit aus geht und das gerät wieder am Host verfügbar wird.
Das ist aber nur ein verdacht meinerseits, vielleicht weis da jemand genaueres darüber.
 
Bu66as said:
lspci -vvs 05:00.2
Click to expand...

Das VVS Objekt scheint kein BAR zu besitzen:

05:00.2
IOMMU group: 80
Region 0: Memory at 67701000000 (64-bit, prefetchable) [disabled] [size=16M]
Region 2: Memory at 67200000000 (64-bit, prefetchable) [virtual] [size=8G]

Schaue ich auf das Physische gerät sehe ich BAR Konfigurationen
05:00.0

Region 0: Memory at 67707000000 (64-bit, prefetchable) [size=16M]
Region 2: Memory at 66c00000000 (64-bit, prefetchable) [size=16G]

Capabilities: [420 v1] Physical Resizable BAR
BAR 2: current size: 16GB, supported: 256MB 512MB 1GB 2GB 4GB 8GB 16GB
Capabilities: [220 v1] Virtual Resizable BAR
BAR 2: current size: 8GB, supported: 256MB 512MB 1GB 2GB 4GB 8GB 16GB
Capabilities: [320 v1] Single Root I/O Virtualization (SR-IOV)
Kernel driver in use: xe
Kernel modules: xe



Was mir noch komisch vorkommt ist, dass beide Objekte melden über ein x1 Interface angebunden zu sein obwohl die Grafikkarte an einem 16x PCIe hängt:
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <64ns, L1 <1us
Bu66as said:
(dmesg | grep -iE 'guc|huc').
Click to expand...
Ausgabe ist:
[ 5.440239] xe 0000:05:00.0: [drm] Tile0: GT0: Using GuC firmware from xe/bmg_guc_70.bin version 70.72.1
[ 5.754783] xe 0000:05:00.0: [drm] Tile0: GT1: Using GuC firmware from xe/bmg_guc_70.bin version 70.72.1
[ 5.766019] xe 0000:05:00.0: [drm] Tile0: GT1: Using HuC firmware from xe/bmg_huc.bin version 8.2.10
[ 6.883947] xe 0000:05:00.0: [drm] PF: Tile0: GT0: VF1..VF2 provisioned with 16384 GuC context IDs
[ 6.884432] xe 0000:05:00.0: [drm] PF: Tile0: GT0: VF1..VF2 provisioned with 64 GuC doorbell IDs
[ 6.885026] xe 0000:05:00.0: [drm] PF: Tile0: GT1: VF1..VF2 provisioned with 16384 GuC context IDs
[ 6.885602] xe 0000:05:00.0: [drm] PF: Tile0: GT1: VF1..VF2 provisioned with 64 GuC doorbell IDs
[ 44.536025] xe_guc_relay: 3 callbacks suppressed
[ 44.536836] xe_guc_relay: 3 callbacks suppressed


Bu66as said:
Zieh mal den Kernel hoch, 7.0.14-12 ist nicht mehr der neueste, hier läuft 7.0.14-15. Am xe-SR-IOV wird aktuell viel gefixt, das kann durchaus den Unterschied machen. Welchen Arc-Treiber hast du im Gast drin?
Click to expand...
Kernel habe ich auf die aktuellste Version gebracht (7.0.14-17).
Dies hat auch etwas gebracht, jetzt scheint die Decode Engine minimal mitzuarbeiten.
Jedoch ist das Problem, dass beim scrollen in einer PDF der WUDFHost >25% der 3D Engine verbraucht immer noch präsent.
Der ARC Treiber ist 32.0.101.8805
1789639577464.png
 
cwt said:
Intel listet die Arc Pro B50 bzw. den aktuellen Arc-Pro-Windows-Treiber offiziell nur für Windows 10/11, nicht für Windows Server 2022. RDSH 2022 kann GPU/H.264 grundsätzlich, aber die konkrete B50-Treiberkombination ist damit offenbar außerhalb der von Intel gelisteten OS-Unterstützung.

Ich würde deshalb als nächsten Test exakt dieselbe VF einmal an eine Windows-11-VM hängen. Wenn dort PDF-Scrolling/D3D/QSV sauber läuft und keine AMD-Vi-Faults entstehen, würde ich nicht mehr bei Proxmox suchen, sondern bei Server 2022 + Intel-Treiber/RDP.

Zusätzlich bitte einmal die genaue Intel-Treiberversion/Firmware und lspci -vv -s 05:00.2 posten. Intel spezifiziert für den aktuellen B50-SR-IOV-Stack zwei VFs mit jeweils 8 GB Local-Memory-BAR. Interessant wäre, ob die VF den BAR auf dem DL385 tatsächlich sauber zugewiesen bekommt.
Click to expand...

Ja das mit dem Treiber ist so eine sache.
Ich habe jetzt die VF an eine Windows 11 VM gehängt. Jedoch bekomme ich da den Fehler 43 und die GPU bleibt deaktiviert.

Die Intel Version ist 32.0.101.8805

BAR scheint nur an Physischen GPU erkannt zu werden (siehe vorheriger Post)

Hier der komplette Output vom VF objekt

05:00.1 VGA compatible controller: Intel Corporation Battlemage G21 [Intel Graphics] (prog-if 00 [VGA controller])
Subsystem: Sparkle Computer Co., Ltd. Device 0209
Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin ? routed to IRQ 497
NUMA node: 0
IOMMU group: 79
Region 0: Memory at 67700000000 (64-bit, prefetchable) [disabled] [size=16M]
Region 2: Memory at 67000000000 (64-bit, prefetchable) [virtual] [size=16G]
Capabilities: [70] Express (v2) Endpoint, IntMsgNum 0
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 0W TEE-IO-
DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- FLReset-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <64ns, L1 <1us
ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+
LnkCtl: ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed unknown (downgraded), Width x0 (downgraded)
TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range B, TimeoutDis+ NROPrPrP- LTR+
10BitTagComp+ 10BitTagReq+ OBFF Not Supported, ExtFmt+ EETLPPrefix-
EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
FRS- TPHComp- ExtTPHComp-
AtomicOpsCap: 32bit- 64bit- 128bitCAS-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
AtomicOpsCtl: ReqEn-
IDOReq- IDOCompl- LTR- EmergencyPowerReductionReq-
10BitTagReq- OBFF Disabled, EETLPPrefixBlk-
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1-
EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest-
Retimer- 2Retimers- CrosslinkRes: unsupported
Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable+ 64bit+
Address: 00000000fee00000 Data: 0000
Masking: 00000000 Pending: 00000000
Capabilities: [100 v1] Alternative Routing-ID Interpretation (ARI)
ARICap: MFVC- ACS-, Next Function: 2
ARICtl: MFVC- ACS-, Function Group: 0
Capabilities: [200 v1] Address Translation Service (ATS)
ATSCap: Invalidate Queue Depth: 00
ATSCtl: Enable+, Smallest Translation Unit: 00
Kernel driver in use: vfio-pci
Kernel modules: xe
 
Sim0n said:
Zum EFI: Das "Workload Profile" unter "BIOS/Platform Configuration Options" soll auf jeden fall auf "Virtualization" stehen, HP Stellt da im Hintergrund einiges um, je nach Profil.
Click to expand...
Das Workload Profile ist bei mir "Virtualization - Max Performance"

Sim0n said:
Was mir ins Auge springt ist die PCI-Option "PCIe Error Control" ich denke die sollte wohl auf OS Control stehen, weil ja Geräte durchaus Fehler produzieren wenn eine Gast-VM mit aus geht und das gerät wieder am Host verfügbar wird.
Das ist aber nur ein verdacht meinerseits, vielleicht weis da jemand genaueres darüber.
Click to expand...
Leider scheint es bei mir den Menüpunkt PCIe Error Control nicht zu geben...laut HP giude sollte das im Pfad >System Configuration > BIOS/Platform Configuration (RBSU) > PCIe Device Configuration Options sein....
1789645823815.png
 
Die 8,0 GB dedizierter GPU-Speicher aus dem Taskmanager würde ich für die BAR-Frage nicht heranziehen, den Wert meldet Windows aus den Treiberangaben, unabhängig davon wie die BARs tatsächlich gemappt sind. Die Treiberversion steht immerhin drin, 32.0.101.8805 vom 07.07.2026. Dein lspci zeigt die Antwort aber schon: Region 2 der VF steht mit 8G als [virtual] da, das ist der erwartete VF-Anteil, den der Host aus dem 16G-BAR der PF zuteilt, und er wird nicht klassisch vom BIOS gemappt sondern vom Treiber über die Virtual Resizable BAR Capability vergeben. Das [disabled] an Region 0 heißt nur, dass der Memory-Decode der VF zu dem Zeitpunkt aus war, also die VM das Gerät gerade nicht in Betrieb hatte. Zu kleine BARs sind damit vom Tisch, das ReBAR-Thema kannst du für die VF abhaken.

Der Win11-Gegentest von @cwt ist ne gute Idee. Schau dabei, obs sich im Gast flüssiger anfühlt, und lass parallel dmesg -w auf dem Host mitlaufen. Kommen die AMD-Vi-Faults und das resetting auch unter Win11, liegt der Fehler am Host- bzw. VF-Stack. Dann kannst du dir Treiber-Gefrickel im Gast komplett sparen und musst an Kernel/Firmware ran.
 
ich habe mich daran abgemüht die Karte als VF in Windows 11 zum laufen zu kriegen, aber ohne Erfolg. Es erscheint immer die Fehlermeldung 43.
Ich prüfe heute Nachmittag ob es:
a) beim physischen durchreichen der GPU besser funktioniert
Sollte das nicht funktionieren, dann
b) transplantieren der GPU in eine Bare-Metal Installation on Windows 11, teste dort die Treiberinstallation und transferiere die GPU anschließend zurück.

Laut meinen Nachforschungen könnte es sein, dass der Intel Treiber die Firmware der Karte aktualisieren möchte, das durch den Hypervisor aber nicht schafft.
 
  • Like
Reactions: Sim0n
Bevor du die Karte ausbaust, das komplette Durchreichen hattest du ja in #4 schon probiert, da ist dir der Host mit MCE komplett weggeflogen. Wenn du das nochmal machst, dann bitte im Wartungsfenster und mit den anderen Gästen vorher runter, sonst reißt dir der Test die produktiven VMs mit.

Zur Firmware-Theorie: GuC und HuC lädt bei SR-IOV der Host-Treiber, dein dmesg zeigt bmg_guc_70.bin und bmg_huc.bin sauber geladen. Ein Gast kommt über eine VF nicht an die Karten-Firmware ran, das blockt der PF-Treiber ab. Vom Bare-Metal-Umweg würd ich mir wenig versprechen, aber schaden tuts auch nicht wenn du die Karte eh schon draußen hast.

Zum Code 43 an der Win11-VM: vergleich mal qm config von beiden VMs nebeneinander, BIOS-Typ, Maschinentyp, CPU-Typ. Und hast du der Win11-VM die zweite VF gegeben oder dieselbe wie dem 2022er? Zwei VMs an derselben VF geht nicht, die zweite kriegt dann genau sowas. Lief bei dem Versuch eigentlich dmesg -w auf dem Host mit, kamen da auch AMD-Vi-Faults?

Die x1 und 2.5GT/s an der VF kannst du ignorieren, VFs melden da Dummy-Werte weil die keinen eigenen Link haben. Relevant ist nur die LnkSta an 05:00.0.
 
Konntest du die anderen Probleme beheben?
Der Fehler 43 ist ein Intel Treiber Fehler!
Hier im Level1 Tech Forum wird seit ner weile darüber Diskutiert.
Intel ist leider mehr als langsam beim beheben des Fehlers, hat ihn aber immerhin schon aufgegriffen: Intel Support Artikel


EDIT: Hier noch mein Testaufbau, der code 43 verschwindet mit einem CPU-Typ der eindeutig Virtuell ist!
Es ist hier die gesamte Karte durchgereicht, Host Fehler bekomme ich keine, aber der DL380Gen10 kann kein ReBAR, daher die Warnung im Treiber.
Ich muss hier erst mit Hardware jonglieren um an einen neueren host zum Testen zu kommen...
1790065921327.png
 
Last edited:
  • Like
Reactions: ThoSo
Guter Fund mit dem CPU-Typ. Was mir noch auffällt @Sim0n: du fährst Treiber 32.0.101.6979 vom 19.08.2025, @Karl_Pedross hat 32.0.101.8805 drauf. Das ist halt die zweite Variable beim Win11-Test: einmal CPU-Typ auf was eindeutig Virtuelles (bei dir also QEMU Virtual CPU 2.5+, qemu64) und dazu den älteren Treiber-Branch. Wenn Code 43 damit weg ist, weiß man wenigstens woran man dreht. Die ganze Karte statt nur einer VF dürfte für die Treiber-Erkennung im Gast aber keine Rolle spielen.

Aus der Engine-Liste im Taskmanager würde ich nichts ableiten, Intel führt Encode-Last dort unter "Video Processing", eine eigene Encode-Zeile gibt es bei den Karten gar nicht. Fehlender Hardware-Encoder würde sich ohnehin anders zeigen: RDP fiele auf Software-Encoding zurück, das schlägt dann auf die CPU und nicht auf 3D. Dass Scrollen in einem PDF über RDP so viel 3D kostet, muss also eine andere Ursache haben.
 
Hab mal aktualisiert!
Mit aktueller FW und Treiber Version startet die VM mit CPU-Typ 'host' gar nicht mehr... Keine Fehler in den logs, aber die VM kommt nicht online, aber ich denke der GPU Treiber legt sich bei mir wegen fehlendem ReBAR quer.

Mit Qemu CPU Startet die VM und die Karte lässt sich auch verwenden und belasten. (Auch das neue Leistungslimit ab 60°C sieht man hier.)
1790079169511.png

An dieser stelle kann ich hier aber nicht mehr viel helfen, da ich vorerst an der alten Host Hardware limitiert bin.
Achja, der Host ist auf Version 'pve-manager/9.2.20/49318c671b82f31e (running kernel: 7.0.14-17-pve)' also aktuell.
 
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

1790149237427.png​



Nachgereicht: mein Test mit Furmark auf server 2022
1790151451831.png
 
Last edited:
You must log in or register to reply here.
Top Bottom
Back