UE5 Heterogeneous Multi-GPU - Versionsgeschichte

Elaina am 17. September 2026 um 19:37 Uhr

2026-09-17T19:37:35Z

Elaina: Projektstand auf 14.09.2026 und Commit 37c6d02 aktualisiert

2026-09-14T18:25:07Z

Projektstand auf 14.09.2026 und Commit 37c6d02 aktualisiert

← Nächstältere Version		Version vom 14. September 2026, 18:25 Uhr
Zeile 1:		Zeile 1:
	{{Hinweis\|Projektstand: 12. September 2026. ~~Letzter~~ Engine-Checkpoint: <code>~~45d5c27~~</code> (<code>~~Add live SceneCapture~~ worker ~~rendering pipeline~~</code>) auf Branch <code>mgpu-experimental</code>. ~~Dynamische~~ SceneCapture-Auflösung, Scheduler-Korrektur ~~und~~ SkeletalMesh-ReferencePose ~~gehören zum neueren~~, ~~noch nicht als eigener Commit dokumentierten Working State~~. ~~Der Commit~~ wurde ~~noch~~ nicht ~~gepusht~~. Die beschriebenen Ergebnisse sind ein experimenteller Proof of Concept für Unreal Engine 5.8 unter Windows und Direct3D 12.}}		{{Hinweis\|Projektstand: 14. September 2026. Aktueller Engine-Checkpoint: <code>37c6d02</code> (<code>Extend worker capture and workload instrumentation</code>) auf Branch <code>mgpu-experimental</code>. Der Commit umfasst die dynamische SceneCapture-Auflösung, die Scheduler-/Polling-Korrektur, den SkeletalMesh-ReferencePose-Proof, die generische Workload-Registry, Runtime Metrics V1 und Worker GPU Timing V1. Ein Push wurde in diesem Dokumentationsschritt nicht ausgeführt. Die beschriebenen Ergebnisse sind ein experimenteller Proof of Concept für Unreal Engine 5.8 unter Windows und Direct3D 12.}}

	'''UE5 Heterogeneous Multi-GPU''' ist ein experimentelles Projekt zur gemeinsamen Nutzung unterschiedlicher Grafikkarten in [[Unreal Engine 5]]. Eine leistungsfähige GPU übernimmt das normale Rendering. Weitere NVIDIA-, AMD- oder Intel-GPUs sollen als unabhängige Worker klar abgegrenzte Aufgaben bearbeiten.		'''UE5 Heterogeneous Multi-GPU''' ist ein experimentelles Projekt zur gemeinsamen Nutzung unterschiedlicher Grafikkarten in [[Unreal Engine 5]]. Eine leistungsfähige GPU übernimmt das normale Rendering. Weitere NVIDIA-, AMD- oder Intel-GPUs sollen als unabhängige Worker klar abgegrenzte Aufgaben bearbeiten.

	Das Ziel ist ausdrücklich '''kein klassisches SLI oder CrossFire'''. Die Anwendung verteilt Arbeit selbst und tauscht nur benötigte Ergebnisse zwischen den GPUs aus.		Das Ziel ist ausdrücklich '''kein klassisches SLI oder CrossFire'''. Die Anwendung verteilt Arbeit selbst und tauscht nur benötigte Ergebnisse zwischen den GPUs aus. Der Proof of Concept besitzt inzwischen einen durchgängigen Worker-Rasterpfad aus echten UE-Weltdaten bis zur zweiten physischen GPU und zurück in eine persistente UE-Textur. Eine backend-neutrale Workload-Schicht erfasst dabei erstmals Aufgaben, Lifecycle-Daten und echte Worker-GPU-Zeiten; automatische Scheduling-Entscheidungen trifft sie noch nicht.

	{\| class="wikitable"		{\| class="wikitable"
Zeile 21:		Zeile 21:
	\|-		\|-
	! Zusätzliche Testhardware		! Zusätzliche Testhardware
	\| Intel Arc A750 und Arc A380 als zusätzliche dGPU-Worker-Gegenchecks vorgesehen; ~~belastbare Messwerte liegen noch nicht vor~~		\| Intel Arc A750 und Arc A380 als zusätzliche dGPU-Worker-Gegenchecks vorgesehen; später außerdem RX 6900 XT ↔ Intel
	\|-		\|-
	! Git-Stand		! Git-Stand
	\| ~~Letzter~~ Commit <code>~~45d5c27~~</code> auf Branch <code>mgpu-experimental</code>; ~~neuerer Working State mit Dynamic Resolution, Scheduler-Fix und SkeletalMesh-ReferencePose~~; nicht gepusht		\| Commit <code>37c6d02</code> auf Branch <code>mgpu-experimental</code>; vorheriger Checkpoint <code>45d5c27</code>; nicht gepusht
	\|-		\|-
	! Windows/D3D12-Proof-of-Concept		! Windows/D3D12-Proof-of-Concept
	\| Durchgängiger sichtbarer Worker-Rasterpfad von der laufenden UE-Welt über getaggte Static und Skeletal Meshes sowie eine echte SceneCapture2D-Kamera bis zur persistenten UE-Textur; dynamisch bis 3840×2160 und 4K60 mit 300/300 Ready-Frames nachgewiesen		\| Durchgängiger sichtbarer Worker-Rasterpfad von der laufenden UE-Welt über getaggte Static und Skeletal Meshes sowie eine echte SceneCapture2D-Kamera bis zur persistenten UE-Textur; dynamisch bis 3840×2160 und 4K60 mit 300/300 Ready-Frames nachgewiesen
			\|-
			! Mess- und Workload-Schicht
			\| Generische Workload-Registry, Runtime Metrics V1 und echte D3D12-Timestamp-Messungen des Worker-Rasterabschnitts implementiert
	\|-		\|-
	! Gesamtvision		! Gesamtvision
	\| etwa 30–35 % (Scheduler, echte Workloads, N-GPU und Vulkan noch offen)		\| etwa 30–35 % (Kostenmodell, Scheduler, weitere echte Workloads, N-GPU und Vulkan noch offen)
	\|}		\|}

Elaina: Workload-Registry, Runtime Metrics und Worker GPU Timing dokumentiert

2026-09-14T18:25:01Z

Workload-Registry, Runtime Metrics und Worker GPU Timing dokumentiert

@@ Zeile 288: / Zeile 288: @@
 Der sichtbare Test mit <code>SKM_Quinn_Simple</code> rendert Quinn in der Reference Pose mit '''45.993 Vertices, 261.840 Indices, zwei Sections und zwei Draw Calls'''. Die beiden Sections umfassen 35.612 und 51.668 Dreiecke. Worker-VB/IB, gemeinsamer D32-Depth-Buffer, dynamische Auflösung, Cross-Adapter-Transport und Normal/SafeCopy werden wiederverwendet.
-Eine Reference Pose ist die unverformte Ausgangshaltung des Skeletal Meshes. Bone-Matrizen, Skin Weights, laufende Animationen, Morph Targets und Cloth sind noch nicht angebunden. Der nächste Geometrieschritt ist daher echtes Worker-Skinning.
+Eine Reference Pose ist die unverformte Ausgangshaltung des Skeletal Meshes. Bone-Matrizen, Skin Weights, laufende Animationen, Morph Targets und Cloth sind noch nicht angebunden. Skeletal Skinning ist erst vorgesehen, wenn ein echter Worker-Workload wie CCTV oder Spiegel animierte Figuren in seiner eigenen Ansicht benötigt.
 == Test- und Diagnosebefehle ==

Elaina: Befehlsreferenz um ListWorkloads ergänzt und gestrafft

2026-09-14T18:24:56Z

Befehlsreferenz um ListWorkloads ergänzt und gestrafft

Änderungen zeigen

Elaina: Nächsten Schritt auf Transfer- und SafeCopy-Timing gesetzt

2026-09-14T18:24:51Z

Nächsten Schritt auf Transfer- und SafeCopy-Timing gesetzt

← Nächstältere Version		Version vom 14. September 2026, 18:24 Uhr
Zeile 465:		Zeile 465:
	== Aktueller nächster Schritt ==		== Aktueller nächster Schritt ==

	~~Der Live~~-~~SceneCapture~~-~~Kanal ist funktional nachgewiesen, frei von 1×1 bis 4096×4096 konfigurierbar und sichtbar bis 3840×2160 geprüft. Der nächste Produktmeilenstein ist ein echter Nutzlast~~-~~Proof als CCTV, Spiegel oder Minimap~~. ~~Beim Skeletal Mesh folgen Bone~~-~~Matrizen, Skin Weights und Animation~~. ~~Parallel bleiben Material~~-~~/Textur-Bindings, Culling~~, Cross-~~Vendor~~-~~Tests~~ und ein ~~späterer Autotuner offen~~. ~~QueueProbe bleibt ein Diagnosewerkzeug; Experimental~~/~~Direct, Nanite, Lumen und automatische Workload~~-~~Verteilung sind eigenständige Ausbaustufen~~.		Als Nächstes wird die GPU-Zeit des Transfers vom Worker-ColorTarget in den Shared Cross-Adapter Buffer separat gemessen. Danach folgt das Timing der Primary-SafeCopy. Erst aus den getrennten Blöcken Worker-Raster, Cross-Adapter-Transfer und Primary-Integration soll ein belastbares Kostenmodell V1 entstehen. Dieses bildet anschließend die Grundlage für automatische Primary-/Worker-Zuweisungen; die aktuelle Registry plant bewusst noch nichts selbst.

	== Historische Vorläufer ==		== Historische Vorläufer ==

Elaina: Bekannte Grenzen an Workload- und Timing-Stand angepasst

2026-09-14T18:24:46Z

Bekannte Grenzen an Workload- und Timing-Stand angepasst

← Nächstältere Version		Version vom 14. September 2026, 18:24 Uhr
Zeile 565:		Zeile 565:
	== Bekannte Grenzen des Proof of Concepts ==		== Bekannte Grenzen des Proof of Concepts ==

	* ~~Der synchrone 64×64~~-~~Debugtest prüft weiterhin alle 4096 Pixel. Der sichtbare Runtime~~-~~Pfad ist über dynamische Dimensionen, Dispatch, Transfer, Fences, Pending~~/Ready und ~~Reuse verifiziert; ein vollständiger Pixel~~-~~Readback für jede dynamische Größe~~ ist ~~kein Bestandteil des Normal-Pfads~~.		* Die sichtbare Normal-/SafeCopy-/Ready-Kette bleibt an Unreals Submission- und Frame-System gekoppelt. Für sichtbare Outputs ist das akzeptabel; hochfrequente Hintergrundjobs benötigen weitere Architekturtests.
	* Pro Worker existiert absichtlich nur ein persistenter Runtime-Slot. Mehrere parallele In-Flight-Jobs ~~sowie Double-, Triple- oder Ring-Buffering~~ fehlen noch.		* Pro Worker existiert absichtlich nur ein persistenter sichtbarer Runtime-Slot. Mehrere parallele In-Flight-Jobs und Ringbuffer fehlen noch.
	* Die Primary-/SafeCopy-/Ready-Kette bleibt trotz zusätzlichem non-blocking <code>DispatchToRHIThread</code> effektiv an den Frame-/Submission-Zyklus gekoppelt.		* Praktisch getestet ist Primary plus ein Worker. Mehrere Worker sind architektonisch vorgesehen, aber noch nicht praktisch validiert.
	* Echte Intel-Worker-GPU-Arbeit skaliert im aktuellen UE-Prozess mit 30/60/120 FPS. Der Standalone-Test widerlegt eine allgemeine Intel-/WDDM-/D3D12-Grenze; die genaue UE-spezifische Ursache bleibt offen.		* World- und SceneCapture-Pfade verarbeiten pro Snapshot höchstens acht sichtbare <code>UStaticMeshComponent</code>s.
	* QueueProbe ist reine Diagnose. Private native Queues sind noch kein Experimental-/Direct-Modus und beschreiben keine UE-eigene sichtbare Textur.		* Der Static-Mesh-Pfad verwendet LOD0-Positionen, Normalen und Indices ohne UE-Materialien, Texturen, Beleuchtung, Schatten, Nanite, Lumen oder Culling. Für Cooked/Shipping wird ein eigener Geometrie-Cache oder Build-Schritt benötigt.
	* Es gibt noch keine Umschaltung zwischen Normal und Experimental sowie keinen automatischen Session-Fallback.		* <code>USkeletalMesh</code> ist bislang ein LOD0-ReferencePose-Proof. Bone-Skinning, Animation, Morph Targets und Cloth fehlen.
	* Raw-D3D12-Shared-Ressourcen sind noch nicht vollständig in Unreals Residency-Management eingebunden.		* Die Workload-Registry sammelt Metadaten und Messwerte, führt aber noch keine automatische Zuweisung, Auflösungsänderung oder Ratenanpassung aus.
	* Praktisch getestet ist Primary plus ein Worker. ~~Die Architektur ist auf mehrere~~ Worker ~~ausgelegt~~, ~~N-GPU ist~~ aber noch nicht praktisch validiert.		* Worker GPU Timing V1 misst nur den Rasterabschnitt. Cross-Adapter-Transfer und Primary-SafeCopy fehlen noch im Kostenmodell.
	* ~~Raster3D, einzelne UE-Static-Meshes, die Drei-Mesh-Szene sowie WorldStaticMeshScene sind sichtbar nachgewiesen.~~ World- und SceneCapture-Pfade ~~besitzen laufende Streams;~~ pro Snapshot ~~werden weiterhin~~ höchstens acht sichtbare <code>UStaticMeshComponent</code>s ~~verarbeitet.~~		* Lifecycle-Raten können im Editor durch Fensterfokus und Background-Throttling verfälscht werden. Für Kostenentscheidungen sind echte GPU-Timestamps und geglättete Mehrfachmessungen maßgeblich.
	* <code>USkeletalMesh</code> ist bislang ein LOD0-ReferencePose-Proof. Bone-Skinning, Animation, Morph Targets und Cloth fehlen noch.		* QueueProbe und private native Queues bleiben Diagnosepfade; Experimental/Direct ist noch nicht implementiert.
	* Der Static-Mesh-Pfad ~~verarbeitet weiterhin~~ LOD0-~~POSITION/NORMAL-Daten~~ und Indices ohne UE-Materialien, Texturen, Beleuchtung, Schatten, Nanite, Lumen oder ~~Frustum-/Occlusion-~~Culling~~. Mehrere Sections sind bislang nur im Skeletal-Mesh-Proof gezeigt~~. Für Cooked/Shipping ~~muss der Zugriff auf benötigte~~ Geometrie ~~über einen eigenen~~ Cache oder Build-Schritt ~~abgesichert werden~~.		* Raw-D3D12-Shared-Ressourcen sind noch nicht vollständig in Unreals Residency-Management eingebunden. Device Lost, Timeouts, Speicherdruck und die vollständige Fallback-Matrix müssen vor produktiver Nutzung gehärtet werden.
	* ~~Der SceneCapture~~-~~Output ist von 1×1 bis 4096×4096 konfigurierbar und sichtbar bis 3840×2160 getestet~~. ~~RGBA8 ist fest; andere Formate~~, ~~MSAA~~ und ~~produktive Resolution~~-~~Policies fehlen~~ noch.
	* ~~Ein explizites Read~~-vs-~~Write-Hazard-Modell für die persistente~~ Primary-~~Textur fehlt~~ noch und ~~muss vor mehreren Slots oder einem nativen Experimental~~-~~Texturpfad gelöst~~ werden.
	* ~~Die projektseitigen UpscalerTest~~-~~Dateien mit DisplayActor und Texture Stream liegen außerhalb des Engine~~-~~Git~~-~~Repositories und~~ sind nicht ~~Bestandteil des Engine~~-~~Commits <code>45d5c27</code>~~.
	* Device Lost, Timeouts, Speicherdruck und die vollständige Fallback-Matrix müssen vor produktiver Nutzung gehärtet werden.
	* Linux/Vulkan mit getrennten Devices, External Memory und externer Synchronisation ist noch nicht implementiert.		* Linux/Vulkan mit getrennten Devices, External Memory und externer Synchronisation ist noch nicht implementiert.

Elaina: Roadmap um getrennte Timing-Blöcke und Kostenmodell ergänzt

2026-09-14T18:24:40Z

Roadmap um getrennte Timing-Blöcke und Kostenmodell ergänzt

← Nächstältere Version		Version vom 14. September 2026, 18:24 Uhr
Zeile 584:		Zeile 584:
	== Roadmap ==		== Roadmap ==

	# ~~Einen echten Nutzlast~~-~~Proof als CCTV, Spiegel oder Minimap aufbauen~~.		# Cross-Adapter Transfer Timing V1: Worker-ColorTarget → Shared Buffer separat messen.
	# ~~Skeletal Skinning mit Bone-Matrizen~~ und ~~Skin Weights anbinden und Quinn von der Reference Pose zur laufenden Animation bringen~~.		# Primary SafeCopy Timing ergänzen und die Integrationskosten getrennt halten.
	# ~~Mehrere Mesh~~-~~Sections~~, ~~Material~~-~~/Textur~~-~~Bindings~~ und ~~anschließend Culling ergänzen~~.		# Kostenmodell V1 aus Worker-Raster, Transfer und Primary-Integration pro Workload ableiten.
	# D3D12~~-Adapter-, Raster- und SceneCapture~~-Pfade ~~auf~~ Intel Arc A750/A380 und ~~später mit~~ RX 6900 XT ~~als~~ Primary gegenprüfen.		# Weitere echte Workload-Klassen wie CCTV, Spiegel, Minimap und Compute anbinden; später Post Process oder neuronale Aufgaben untersuchen.
	# ~~Microbenchmarks~~ und ~~echte Workloads zu einem~~ Autotuner ~~für sinnvolle~~ GPU-~~Paare~~ und ~~Jobzahlen ausbauen~~.		# D3D12-Pfade mit Intel Arc A750/A380 und RX 6900 XT in unterschiedlichen Primary-/Worker-Rollen gegenprüfen.
	# ~~Experimental~~-~~/Direct~~-~~Architektur mit State~~-~~Tracking, Residency, Hazards, Capability~~-~~Selftest und automatischem Fallback entwerfen~~.		# Scheduler und Autotuner auf GPU-Eignung und gemessene Nettokosten statt Auslastungsprozent aufbauen.
	# ~~Mehrere Runtime~~-~~Slots beziehungsweise einen Ringbuffer~~ erst bei ~~echtem~~ Workload~~-Bedarf ergänzen~~.		# Material-, Textur- und Culling-Pfade für realistischere Worker-Szenen ergänzen.
	# ~~Langfristig einen Engine-eigenen~~ Multi-Tier Resource Manager für Primary-VRAM, Worker-VRAM und ~~RAM~~ untersuchen~~; kein transparenter gemeinsamer Hardware~~-~~VRAM~~.		# Skeletal Skinning mit Bone-Matrizen und Skin Weights erst bei einem echten animierten Worker-Workload ausbauen.
	# Linux/Vulkan mit External Memory und externen Semaphoren/Fences untersuchen.		# Einen softwareseitigen Multi-Tier Resource Manager für Primary-VRAM, Worker-VRAM, RAM und später Storage untersuchen.
			# Experimental-/Direct-Fast-Path nur mit State-Tracking, Residency, Hazards und sicherem Fallback entwickeln.
			# Linux/Vulkan mit getrennten Devices, External Memory und externen Semaphoren/Fences untersuchen.

	== Git-Checkpoint ==		== Git-Checkpoint ==

Elaina: Git-Checkpoint 37c6d02 dokumentiert

2026-09-14T18:24:35Z

Git-Checkpoint 37c6d02 dokumentiert

← Nächstältere Version		Version vom 14. September 2026, 18:24 Uhr
Zeile 596:		Zeile 596:
	== Git-Checkpoint ==		== Git-Checkpoint ==

	Der ~~letzte~~ Engine-Checkpoint <code>~~45d5c27~~</code> ~~mit der~~ Nachricht <code>~~Add live SceneCapture~~ worker ~~rendering pipeline~~</code> folgt auf <code>~~0719998~~</code>. Er umfasst 13 Dateien mit ~~4443~~ Einfügungen und 11 Löschungen. Enthalten sind ~~Raster3D, StaticMesh-, Multi-Mesh-, WorldScene- und Live~~-SceneCapture-~~Enginepfade. Die projektseitige Datei <code>UpscalerTest/Private/ExperimentalMultiGPUDisplayActor.cpp</code> liegt außerhalb des Engine-Repositories und ist daher nicht Teil des Commits. Binaries~~, ~~Intermediate-, Cache-, Saved- und Log-Dateien wurden nicht aufgenommen. Seit diesem Checkpoint wurden Dynamic Resolution, der SceneCapture-~~Scheduler-/Polling-~~Fix~~, ~~der 4K60-Stresstest und der~~ SkeletalMesh-ReferencePose-~~Proof weiterentwickelt; diese Änderungen sind zum Stand vom 12. September 2026 noch nicht als neuer Engine-Commit dokumentiert~~. Ein Push ~~erfolgte~~ nicht.		Der aktuelle Engine-Checkpoint <code>37c6d02</code> trägt die Nachricht <code>Extend worker capture and workload instrumentation</code> und folgt auf <code>45d5c27</code> (<code>Add live SceneCapture worker rendering pipeline</code>). Er umfasst acht Dateien mit 877 Einfügungen und 26 Löschungen. Enthalten sind der seit dem vorherigen Checkpoint weiterentwickelte Engine-Stand mit dynamischer SceneCapture-Auflösung, Scheduler-/Polling-Korrektur, SkeletalMesh-ReferencePose, generischer Workload-Registry, Runtime Metrics V1 und Worker GPU Timing V1. Ein Push wurde in diesem Dokumentationsschritt nicht ausgeführt.

	== Quellen ==		== Quellen ==

Elaina: Quellenstand auf Commit 37c6d02 aktualisiert

2026-09-14T18:24:29Z

Quellenstand auf Commit 37c6d02 aktualisiert

← Nächstältere Version		Version vom 14. September 2026, 18:24 Uhr
Zeile 600:		Zeile 600:
	== Quellen ==		== Quellen ==

	* Interner Entwicklungsstand und verifizierte Testprotokolle vom 12. September 2026; ~~letzter~~ Commit <code>~~45d5c27~~</code> ~~plus neuerer Working State~~. ~~WorldStaticMeshScene~~, ~~dynamische SceneCapture-Auflösung bis 4K60~~ und ~~der SkeletalMesh~~-~~ReferencePose~~-~~Pfad sind sichtbar im PIE~~-~~Level getestet~~.		* Interner Entwicklungsstand und verifizierte Testprotokolle vom 14. September 2026; Commit <code>37c6d02</code> auf Branch <code>mgpu-experimental</code>. Neu belegt sind Workload-Registry, Runtime Metrics V1 und native D3D12-Timestamp-Messungen des Worker-Rasterabschnitts.
	* [https://learn.microsoft.com/en-us/windows/win32/direct3d12/multi-engine Microsoft: Direct3D 12 Multi-adapter systems]		* [https://learn.microsoft.com/en-us/windows/win32/direct3d12/multi-engine Microsoft: Direct3D 12 Multi-adapter systems]
	* [https://learn.microsoft.com/en-us/windows/win32/direct3d12/shared-heaps Microsoft: Shared heaps]		* [https://learn.microsoft.com/en-us/windows/win32/direct3d12/shared-heaps Microsoft: Shared heaps]
			* [https://learn.microsoft.com/en-us/windows/win32/direct3d12/timing Microsoft: Timing und Timestamp Queries in Direct3D 12]
	* [https://learn.microsoft.com/en-us/samples/microsoft/directx-graphics-samples/d3d12-heterogeneous-multiadapter-sample-win32/ Microsoft: D3D12 Heterogeneous Multiadapter Sample]		* [https://learn.microsoft.com/en-us/samples/microsoft/directx-graphics-samples/d3d12-heterogeneous-multiadapter-sample-win32/ Microsoft: D3D12 Heterogeneous Multiadapter Sample]
	* [https://devblogs.microsoft.com/directx/directx-12-multiadapter-lighting-up-dormant-silicon-and-making-it-work-for-you/ Microsoft: UE4 Elemental Demo mit heterogenem Multiadapter]		* [https://devblogs.microsoft.com/directx/directx-12-multiadapter-lighting-up-dormant-silicon-and-making-it-work-for-you/ Microsoft: UE4 Elemental Demo mit heterogenem Multiadapter]

Elaina: Entwicklungsstand 12.09.2026: Dynamic Resolution, Scheduler-Fix, 4K60 und SkeletalMesh-ReferencePose

2026-09-12T19:38:40Z

Entwicklungsstand 12.09.2026: Dynamic Resolution, Scheduler-Fix, 4K60 und SkeletalMesh-ReferencePose

Änderungen zeigen