GBV-Start: CPU-Arbeit im NVIDIA-Compiler

Stand: 17.09.2026, Auswertung der gültigen CPU-Snapshots bei 35, 119 und 129 Sekunden Prozesslaufzeit. Der Launcher beendete den Beobachtungslauf an der 180-Sekunden-Grenze mit insufficient-render-coverage, ohne verwertbares GPU-Validierungsergebnis. Sein Abschlussbericht meldet keine Treiberereignisse, wiederhergestellte Testprofile, unveränderte Produktionsprofile und eine leere Prozessgruppe.

Der aktuelle D3D12-GBV-Lauf bleibt vor dem ersten protokollierten Hauptkamera-Frame stehen, während der Unity-Grafikthread nahezu einen CPU-Kern im NVIDIA-Compiler auslastet. Das belegt CPU-Arbeit im Compilerpfad; es belegt weder deren erfolgreichen Fortschritt noch die Ursache der vorherigen Abstürze im normalen Rennbetrieb.

Belege liegen in 20260917-005021-fresh-gbv. module-proof.json bestätigt den tatsächlich geladenen lokalen D3D12Core.dll und D3D12SDKLayers.dll, beide Version 1.618.1.0.20250923.2. invocation.json enthält die D3D12-Debug-/GBV-Startparameter und die separate 180-Sekunden-Grenze. Ein RenderDoc-Replay fand für diese Untersuchung nicht statt.

Zwischen den ersten beiden Zeitentabellen erhält derselbe Grafikthread 78,375 Sekunden User-CPU in 84,109 Sekunden Wandzeit (rund 93 % eines CPU-Kerns). Der Hauptthread erhält keine zusätzliche User-CPU. Snapshot 1 benennt den Grafikthread als UnityGfxDeviceWorker; dessen Stack enthält nvgpucomp64 über nvwgf2umx. Der Hauptthread wartet in WaitOnAddress, die vier D3D-Hintergrundthreads in SleepConditionVariableSRW.

Snapshot 5 wählt den Grafikthread ausdrücklich anhand seiner stabilen TID mit ~~[4cb0]s und erfasst den vollständigen Aufrufpfad: UnityPlayer → D3D12SDKLayers / d3d12 → D3D12Core → nvwgf2umx → nvgpucomp64. Der aktuelle Compiler-Codepunkt und die oberen Stackframes unterscheiden sich von Snapshot 1. Das spricht gegen einen ausschließlich schlafenden Prozess. Es entscheidet nicht zwischen einer sehr aufwendigen Kompilierung, mehreren Kompilierungen oder einem Compilerpfad ohne erfolgreichen Abschluss. Ohne passende PDBs sind Bezeichnungen wie nvGetCompilerInterface+0x3b14440 nur nächste Exportsymbole mit großem Offset, keine identifizierten internen Funktionen. Der konkrete Shader, PSO und Shaderstage sind damit nicht bestimmt.

Die Flight-Recorder-Datei enthält zu diesem Auswertungszeitpunkt nur eine CPU-Probe bei 3,369 Sekunden: Home, frame=1, mainCameraFrames=0, renderCallbacks=0, kein Spieler und raceSeconds=0. Das ist keine Renn-, Rundenwechsel- oder Stabilitätsabdeckung. Aus fehlenden Kamera-Callbacks folgt auch nicht, dass überhaupt keine GPU-Arbeit stattgefunden hat. Die hier belegte Kompilierung beim instrumentierten Start darf nicht als bewiesene Ursache der normalen Vulkan-/D3D11-/D3D12-TDRs nach längerer Fahrt ausgegeben werden.

Methodische Grenzen: CDB wurde nichtinvasiv mit -pv verwendet; die Zielthreads waren während der gültigen Snapshots kurz suspendiert. Es wurde kein Speicherabbild geschrieben und keine GPU-Wiedergabe gestartet. Snapshots 2 und 3 enthalten keine gültigen Stacks und gehen nicht in den Befund ein; ihre genaue Fehlerursache ist ungeklärt. In Snapshot 4 war der numerische Debuggerindex inzwischen von 101 auf 98 gewechselt: Seine !runaway-Tabelle ist gültig, der anschließend mit ~101s gewählte Einzelstack gehört jedoch nicht zum untersuchten Grafikthread. Snapshot 5 korrigiert das durch die TID-Auswahl.

Die Beobachtung rechtfertigt keinen weiteren langen GBV-Lauf allein aufgrund steigender CPU-Zeit. Für die Zuordnung zu einer konkreten Reparatur fehlt die Identität des kompilierten Shaders/PSOs beziehungsweise eine hinreichend symbolisierte Zuordnung des Aufrufs. Die fehlenden Treiberereignisse in diesem Startversuch sind kein Stabilitätsnachweis: Die gewünschte frühe Rennabdeckung wurde nicht erreicht.