UnrealWiki - Benutzerbeiträge [de]

DLSS5ForUE5

2026-09-17T19:37:41Z

Elaina:

{{Hinweis|Projektstand: 17. September 2026, Engine-Checkpoint <code>1fc0d24</code>. DLSS5ForUE5 ist ein inoffizielles Community-Projekt und nicht mit NVIDIA oder Epic Games verbunden. Die Integration ist experimentell.}}

'''DLSS5ForUE5''' ist ein Plugin, das NVIDIA NGX Neural Rendering in den Unreal Editor integriert. Es stellt Einstellungen, Szenendaten und Diagnosefunktionen für DLSS 5 bereit. Der Fork des Projekts wird im GitHub-Repository '''[https://github.com/jan1009/DLSS5ForUE5 jan1009/DLSS5ForUE5]''' gepflegt.

== Unterstützte Versionen ==

Das Repository enthält einen gemeinsamen, versionsabhängigen Quellcode für:

* Unreal Engine 5.5
* Unreal Engine 5.6
* Unreal Engine 5.7
* Unreal Engine 5.8

Getestet wurde die Integration unter Windows mit DirectX 12 und einer NVIDIA-RTX-Grafikkarte. Das offizielle NVIDIA-DLSS-Plugin muss für dieselbe Unreal-Engine-Version installiert und aktiviert sein. Der Stand vom 17. September 2026 wurde in Unreal Engine 5.8 sowohl im Editor als auch in einem Development-Package und im eigentlichen Spielprojekt validiert.

== Funktionen ==

* eigenes Werkzeugfenster unter ''Tools → DLSS 5 for UE5''
* Natural- und Cinematic-Stile
* Regler für Preset, Intensität, Local Tone, Local Structure und Skin Structure
* Scene-Depth- und Motion-Vector-Guides
* zeitliche Daten wie Jitter, Pre-Exposure, Camera Cut und History Reset
* ein bis vier aufeinanderfolgende Neural-Rendering-Durchläufe
* Live-Diagnose für Laufzeit, NGX, Szenendaten und zeitlichen Zustand
* Safe Mode zur Wiederherstellung
* Konsolenbefehle unter <code>DLSS5.*</code> und <code>r.DLSS5.*</code>

== Runtime-Architektur ==

Das Plugin verwendet den bereits durch das offizielle NVIDIA-DLSS-Plugin initialisierten NGX-Core. Es eröffnet keine zweite konkurrierende NGX-Application-Session.

{| class="wikitable"
! Schicht
! Aufgabe
|-
| <code>UDLSS5NRSettings</code>
| Projektkonfiguration, Übernahme in Konsolenvariablen und Diagnose
|-
| View Extension
| Post-Process-/RDG-Integration sowie Übergabe von Color, Depth, Motion und Passzahl
|-
| <code>FDLSS5NRRuntime</code>
| NGX-Core-Parameter, Feature-Lifecycle, Create, Evaluate, Release und Telemetrie
|-
| <code>DLSS5ForUE5_nvngx.dll</code>
| Native Bridge für den NVIDIA-Caller-Gate
|-
| <code>nvngx_dlssnr.dll</code>
| Proprietäre NVIDIA-Neural-Rendering-Runtime; nicht Bestandteil des Git-Checkpoints
|}

== Projektkonfiguration und Safe Boot ==

Die Einstellungen werden explizit in <code>Config/DLSS5ForUE5.ini</code> gespeichert. Die Datei enthält 20 projektbezogene Werte für Neural Rendering, Bildstruktur, Scene Guides, temporales Verhalten und Diagnose und wird beim Cook in das Paket übernommen.

Im Editor deaktiviert der Safe Boot Neural Rendering, Scene Guides, Guide Feeding und Motion Vectors zunächst nur für die laufende Session. Die Abschaltung ist auf <code>WITH_EDITOR</code> begrenzt und schreibt die Projektwerte nicht zurück. Ein Packaged Build lädt dagegen die gespeicherte Konfiguration und startet mit den dort hinterlegten Einstellungen.

== Packaged Runtime und Caller-Gate ==

Im Editor kommt der NGX-Aufruf aus <code>UnrealEditor-DLSS5ForUE5_nvngx.dll</code>. In einem monolithischen Packaged Game wurde derselbe Code zunächst in die Spiel-EXE gelinkt; die NVIDIA-Runtime lehnte <code>Init_Ext</code> deshalb mit <code>0xBAD00002</code> ab.

Die Lösung ist eine native <code>DLSS5ForUE5_nvngx.dll</code>, die als Runtime Dependency zusammen mit <code>nvngx_dlssnr.dll</code> gestaged wird. Sie forwardet die benötigten NGX-Entry-Points und bleibt als unmittelbarer Windows-DLL-Caller im Stack. Dabei musste zusätzlich eine MSVC-Tail-Call-Optimierung verhindert werden: Ein bloßer Sprung in die NVIDIA-Runtime ließ weiterhin die Spiel-EXE als Caller erscheinen. Ein echter <code>call</code> mit Post-Call-Operation und erhaltenem Bridge-Stackframe beseitigte den Fehler.

Der validierte Packaged Build meldete NGX-Core, Parameter, Runtime, Snippet und Caller-Gate erfolgreich. Depth und Motion waren jeweils angefordert, verfügbar und verwendet. In einem Lauf wurden '''2036 von 2036 Evaluierungen erfolgreich''' abgeschlossen, ohne Fehler.

== Supportstatus und Fallback ==

{| class="wikitable"
! Status
! Bedeutung
|-
| <code>AVAILABLE</code>
| Aktiver D3D12-NVIDIA-Pfad ist nutzbar; Neural Rendering darf initialisieren und evaluieren.
|-
| <code>UNAVAILABLE</code>
| Noch kein nutzbarer NGX-Core oder transienter Startzustand; ein späterer Versuch bleibt möglich.
|-
| <code>UNSUPPORTED</code>
| Nicht-D3D12 oder aktiver AMD-/Intel-Renderadapter; einmalige Fallback-Meldung statt wiederholter Init-Versuche.
|-
| <code>WAITING</code>
| Editor-Safe-Boot oder Neural Rendering noch nicht aktiviert; kein Fehlerzustand.
|}

Auf dem Hybrid-Testsystem mit RTX 5060 und Intel UHD blieb der Status nach <code>r.DLSS5.Enable 1</code> korrekt <code>AVAILABLE</code>. Entscheidend ist der aktive Renderadapter, nicht die bloße Anwesenheit einer zusätzlichen Intel-GPU.

== Installation ==

# Das zur verwendeten Unreal-Engine-Version passende Plugin-Paket herunterladen.
# Den Ordner <code>DLSS5ForUE5</code> nach <code>Projekt/Plugins/</code> entpacken.
# Das Projekt öffnen und die Plugins ''DLSS'' sowie ''DLSS 5 for UE5'' aktivieren.
# Den Editor neu starten.
# Das Werkzeug über ''Tools → DLSS 5 for UE5'' öffnen.

Bei einem passenden vorkompilierten Paket ist für die normale Installation keine eigene Übersetzung mit Visual Studio erforderlich.

== Verwendung und Grenzen ==

Die Anzahl der Durchläufe lässt sich von eins bis vier einstellen. Jeder weitere Durchlauf verarbeitet das Ergebnis des vorherigen Durchlaufs und erhöht die GPU-Last deutlich. Ein Durchlauf ist deshalb ein sinnvoller Ausgangspunkt.

Scene Depth und erzeugte Bewegungsvektoren können die zeitliche Stabilität verbessern. Die Verarbeitung der Motion Vectors ist jedoch weiterhin experimentell, da Unreal Engine in einigen Render-Hook-Zuständen keine direkt nutzbare Objektgeschwindigkeit liefert. Bekannte Probleme und Workarounds sind in der Repository-Dokumentation beschrieben.

== Performance-Messungen ==

Eine frühe Messreihe lief im eigentlichen Spielprojekt in einer schweren Wald-/Wasserszene auf der RTX 5060 Laptop GPU. Verwendet wurden Epic Scalability und 83,4 % Render Resolution, ungefähr 1404×715 Pixel im Viewport. Die Werte sind Momentaufnahmen und kein allgemeiner Benchmark.

{| class="wikitable"
! Zustand
! FPS
! Framezeit
! GPU-Zeit
! Zusatz gegenüber aus
|-
| Neural Rendering aus
| 41,68
| 23,99 ms
| 17,19 ms
| –
|-
| 1 Pass
| 30,87
| 32,38 ms
| 26,75 ms
| +9,56 ms
|-
| 2 Passes
| 23,16
| 43,05 ms
| 35,84 ms
| +18,65 ms
|-
| 4 Passes
| 16,07
| 62,27 ms
| 54,19 ms
| +37,00 ms
|-
| 2 Passes mit Depth und Motion
| 23,52
| 42,39 ms
| 35,99 ms
| +18,80 ms
|}

In dieser Reihe kostete ein Neural-Pass ungefähr 9 bis 9,5 ms zusätzliche GPU-Zeit. Depth und Motion erhöhten die GPU-Zeit bei zwei Passes nur um ungefähr 0,15 ms und lagen damit im Bereich der Messschwankung. Spätere Versuche mit Preset 3 und vier Passes lagen in einer anderen Szeneneinstellung deutlich niedriger, beispielsweise bei ungefähr 26 ms GPU-Zeit. Die Kosten hängen damit stark von Preset, Passzahl, Szene, Feature-Vertrag und Auflösung ab; künftige Vergleiche müssen diese Parameter mitprotokollieren.

== Bekannte Grenzen ==

* Neural Rendering ist aktuell auf Win64, Direct3D 12 und einen aktiven NVIDIA-Renderadapter begrenzt.
* Depth und Motion funktionieren technisch, benötigen aber weitere Qualitäts- und Stabilitätsprüfung in Bewegung.
* Direktes Umschalten von <code>r.DLSS5.PassCount</code> war im Editor zeitweise nicht zuverlässig; der Settings-Slider setzte denselben Wert korrekt.
* Mehrere Spatial Upscaler dürfen nicht gleichzeitig aktiv konfiguriert werden.
* Die proprietäre NVIDIA-Runtime wird nicht im Git-Checkpoint versioniert.
* Die in [[UE5 Heterogeneous Multi-GPU]] untersuchte Worker-Auslagerung ist noch nicht implementiert. Neural Rendering läuft derzeit auf der Primary-NVIDIA-GPU.

== Repository und Dokumentation ==

* '''[https://github.com/jan1009/DLSS5ForUE5 Unser GitHub-Repository]'''
* [https://github.com/jan1009/DLSS5ForUE5/blob/main/docs/INSTALLATION.md Installation]
* [https://github.com/jan1009/DLSS5ForUE5/blob/main/docs/USAGE.md Verwendung]
* [https://github.com/jan1009/DLSS5ForUE5/blob/main/docs/COMMANDS.md Befehle und Konsolenvariablen]
* [https://github.com/jan1009/DLSS5ForUE5/blob/main/docs/KNOWN_ISSUES.md Bekannte Probleme]
* [https://github.com/jan1009/DLSS5ForUE5/blob/main/docs/TROUBLESHOOTING.md Fehlerbehebung]
* [https://github.com/jan1009/DLSS5ForUE5/blob/main/docs/ARCHITECTURE.md Architektur]

== Siehe auch ==

* [[Deep Learning Super Sampling]]
* [[UE5 Heterogeneous Multi-GPU]]

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Grafik]]
[[Kategorie:NVIDIA]]
[[Kategorie:Plugin]]

UE5 Heterogeneous Multi-GPU

2026-09-17T19:37:35Z

Elaina:

{{Hinweis|Projektstand: 17. September 2026. Aktueller Engine-Checkpoint: <code>1fc0d24</code> (<code>Add DLSS5 NR integration and packaged shader support</code>) auf Branch <code>mgpu-experimental</code>. Der vorherige Checkpoint <code>37c6d02</code> bleibt die Grundlage des Worker-, Workload- und GPU-Timing-Pfads. Neu sind cook-fähige ExperimentalMultiGPU-Global-Shader sowie die Integration von [[DLSS5ForUE5]] als realer Neural-Rendering-Workload. 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.

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 Aufgaben, Lifecycle-Daten und echte Worker-GPU-Zeiten; automatische Scheduling-Entscheidungen trifft sie noch nicht. Seit Commit <code>1fc0d24</code> funktioniert der ExperimentalMultiGPU-Shaderpfad außerdem in Development-Packages. Parallel liefert DLSS5 Neural Rendering einen ersten realen, klar messbaren Kandidaten für eine spätere grobe Worker-Auslagerung; aktuell läuft dieser Workload noch vollständig auf der Primary-NVIDIA-GPU.

{| class="wikitable"
|+ Projektstatus
|-
! Engine / Plattform
| Unreal Engine 5.8 Source Build / Windows / Direct3D 12
|-
! Testsystem
| Lenovo LOQ 17IRX10
|-
! Primary
| NVIDIA GeForce RTX 5060 Laptop GPU
|-
! Worker
| Intel UHD Graphics
|-
! Zusätzliche Testhardware
| Intel Arc A750 und Arc A380 als zusätzliche dGPU-Worker-Gegenchecks vorgesehen; später außerdem RX 6900 XT ↔ Intel
|-
! Git-Stand
| Commit <code>1fc0d24</code> auf Branch <code>mgpu-experimental</code>; vorheriger Checkpoint <code>37c6d02</code>; Working Tree nach dem Commit ohne ausstehende versionierte Änderungen
|-
! 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
|-
! Mess- und Workload-Schicht
| Generische Workload-Registry, Runtime Metrics V1 und echte D3D12-Timestamp-Messungen des Worker-Rasterabschnitts implementiert
|-
! Packaged Build
| Alle neun ExperimentalMultiGPU-Global-Shader nach RenderCore verlagert, beim Cook registriert und im Development-Package erfolgreich gestartet
|-
! Neural Rendering
| [[DLSS5ForUE5]] in Source-Engine, Editor und Packaged Game integriert; Project-Config, native Caller-Gate-Bridge, Depth-/Motion-Guides und robuster Support-Fallback validiert
|-
! Gesamtvision
| etwa 30–35 % (Kostenmodell, Scheduler, weitere echte Workloads, N-GPU und Vulkan noch offen)
|}

== Grundprinzip ==

<pre>
Intel Worker GPU
-> MainTextureCS + PatternPhase
-> persistente Worker-Textur
-> persistenter Shared Cross-Adapter Buffer
-> monotone Shared Fence / Queue Wait
-> persistente UE-eigene FTextureRHIRef
-> stabile UExperimentalMultiGPUTexture

RTX Primary GPU
-> normales UE5-Rendering
-> TPS-Material zeigt das Worker-Ergebnis sichtbar an
</pre>

Pro Worker ist maximal ein Runtime-Job gleichzeitig in flight. Backpressure lehnt weitere Requests als <code>Busy</code> ab, bis der Slot nach der Primary-Completion wieder sicher verwendbar ist.

Jeder Worker besitzt ein eigenes <code>ID3D12Device</code>, eigene Queues, Command Lists und Ressourcen. Ein späterer Scheduler soll Rechenleistung, Fähigkeiten, Transferkosten und gewünschte Aktualisierungsrate bewerten. Vorgesehene Aufgaben sind beispielsweise SceneCapture2D, Spiegel, CCTV, Minimap, Compute oder Niagara.

== Verifizierter Entwicklungsstand ==

=== Worker-Compute ===

Ein echter, von Unreal kompilierter Global Compute Shader läuft auf der Intel UHD, während Unreal regulär über die RTX rendert. Der Test verdoppelt 64 Ganzzahlen auf dem Worker; '''64 von 64 Ergebnissen wurden korrekt verifiziert'''. Damit ist echte GPU-Arbeit auf einem zweiten, herstellerfremden Device nachgewiesen.

Zusätzlich läuft <code>MainTextureCS</code> auf der Intel-GPU. Der synchrone Debugtest erzeugt eine 64 × 64 Pixel große RGBA8-Textur; '''alle 4096 shader-generierten Pixel wurden korrekt verifiziert'''. Der normale Runtime-Pfad verwendet inzwischen einen asynchronen 128×96-Test. Der Shader liest seine Dimensionen mit <code>GetDimensions()</code>, schützt überhängende Threads durch einen Bounds-Check und wird mit <code>Dispatch(16,12,1)</code> ausgeführt. <code>PatternPhase</code> erzeugt für jeden akzeptierten Submit deterministisch einen neuen sichtbaren Inhalt. Abgewiesene Busy-Requests erhöhen die Phase nicht und erzeugen daher keine Lücken.

=== Cross-Adapter-Speicher und Synchronisation ===

* RTX und Intel öffnen denselben D3D12 Cross-Adapter Heap.
* Ein gemeinsamer Buffer wurde mit 64 Testwerten erfolgreich geprüft.
* Ein persistenter Shared Fence synchronisiert die Queues direkt von GPU zu GPU. Seine Werte steigen pro Job monoton: WorkerReady/PrimaryComplete verwenden die Paare 1/2, 3/4, 5/6 und so weiter.
* Die CPU vermittelt die GPU-Abhängigkeit nicht; Worker- und Primary-Queue verwenden <code>Signal</code> und <code>Wait</code> direkt auf der GPU.
* Der separate Readback-Verifikationstest darf weiterhin blockieren. Der normale Runtime-Pfad wartet dagegen nicht auf GPU-Leerlauf.

=== Texturtransport ===

Direkte Cross-Adapter-Texturen sind auf dem Testsystem nicht beidseitig verfügbar: Die Intel UHD meldet Unterstützung für Row-Major Cross-Adapter Textures, die RTX 5060 Laptop GPU nicht. Deshalb verwendet das Projekt einen allgemeineren Buffer-Fallback.

<pre>
Intel MainTextureCS
-> persistente Worker-Textur
-> CopyTextureRegion
-> persistenter Shared Cross-Adapter Buffer
-> Worker signalisiert WorkerReady (1, 3, 5, ...)
-> UE-Primary-Queue wartet auf WorkerReady
-> direkte Kopie in persistente UE-eigene FTextureRHIRef
-> Primary signalisiert PrimaryComplete (2, 4, 6, ...)
</pre>

Der robuste Normal-Pfad kopiert die Worker-Textur über den Shared Buffer direkt in eine von Unreal erzeugte <code>FTextureRHIRef</code>. Breite, Höhe und Row Pitch werden dynamisch aus Worker-Ressource und Transport-Metadaten übernommen. Der erfolgreiche 128×96-RGBA8-Test verwendet 512 Byte Row Pitch und 49.152 Byte Transfergröße. Die Output Registry trennt Persistent-, Pending- und Ready-Zustände sowie Inhaltsgeneration und Texturidentität. Dadurch kann eine verspätete Completion keinen neueren Output zurückrollen.

=== Non-blocking Runtime-Pfad ===

Die produktive Testlogik ist aus dem Konsolenkommando in eine gekapselte NormalPath-API verschoben. <code>SubmitWorkerTextureComputeJob()</code> reicht den Worker-Dispatch ohne CPU-Wait ein. <code>QueueNormalTextureTransfer()</code> reiht Wait, Kopie und Completion-Signal in Unreals D3D12-Kontext ein. Der normale MainTextureCS-Pfad enthält weder CPU-Fence-Waits noch Readback, <code>Map</code> oder Pixelvergleich. <code>TickNormalTextureTransfers()</code> prüft die Primary-Completion non-blocking über einen Runtime-Pump; <code>RHIEndFrame()</code> bleibt als Fallback erhalten.

Eine passende Primary-<code>FTextureRHIRef</code> wird pro Worker und Konfiguration persistent gehalten. Nach PrimaryComplete kann der nächste Job dieselbe Resource erneut verwenden; dabei führt Unreal die Übergänge <code>SRVMask -> CopyDest -> SRVMask</code> aus. Eine backend-neutrale RHI-Provider-API reicht die Ready-Textur an die Engine weiter. <code>UExperimentalMultiGPUTexture</code> hält eine stabile <code>UTexture</code> samt TextureReference und bindet die persistente <code>FTextureRHIRef</code> ohne zusätzlichen Pixel-Copy. Eine native D3D12-Resource wird weiterhin nicht blind als UE-Textur gewrappt, weil Unreals Resource-State-Buchhaltung den tatsächlichen nativen Zustand sonst nicht sicher kennt.

=== Sichtbarer TPS-Consumer ===

<code>AExperimentalMultiGPUDisplayActor</code> zeigt die Worker-Ausgabe im Third-Person-Testlevel über den Materialparameter <code>MultiGPUTexture</code> an. Damit ist der Output nicht mehr nur über Logs oder Readback nachgewiesen: Die Intel UHD erzeugt fortlaufend die Texturinhalte, während die RTX die Spielwelt und das Material rendert. <code>TextureConsumerCS</code> kann Ready-Ausgaben auf der Primary zusätzlich als SRV lesen und fünf quantisierte Samples im Debugpfad prüfen.

=== Lebensdauer und automatisches Cleanup ===

Der Normal-Pfad verwendet pro Worker genau einen persistenten Runtime-Slot. Worker-Textur, Root Signature, PSO, Descriptor Heap, Command Allocator/List und Worker-Fence werden nach der ersten kompatiblen Initialisierung wiederverwendet. Dasselbe gilt für Shared Heap/Buffer/Fence und die Transport-Command-Objekte. Der In-Flight-Job trägt nur noch die nötigen Job-, Generation- und Fence-Metadaten.

<pre>
Runtime Request
-> Completion non-blocking prüfen
-> falls Slot frei: Worker Dispatch
-> WorkerReady-Fence signalisieren
-> Primary Wait, SafeCopy und PrimaryComplete-Signal
-> Output Pending
-> Runtime-Pump oder RHIEndFrame prüft GetCompletedValue()
-> Output Ready publizieren
-> Slot wiederverwendbar
</pre>

Backpressure erlaubt maximal einen echten In-Flight-Job pro Worker. Ein Busy-Request setzt keine GPU-Arbeit ab, setzt keine Ressourcen zurück und erhöht <code>PatternPhase</code> nicht. Worker-Fence-Werte steigen mit jedem akzeptierten Submit 1, 2, 3 und so weiter; der persistente Shared Fence verwendet fortlaufend die Paare 1/2, 3/4, 5/6. Fehler nach Übergabe von Ressourcen an die GPU führen zu sicherem Retire beziehungsweise Retention statt zu vorzeitigem Reuse.

=== Texture Stream und Benchmarking ===

Der projektseitige Texture Stream akzeptiert eine beliebige positive, endliche Zielrate. Punkt und Komma sind als Dezimaltrenner möglich. Optional lässt sich die Zahl erfolgreicher Submits begrenzen; Busy- oder Failed-Versuche verbrauchen dieses Limit nicht. Der Quiet-Modus unterdrückt per-Job-Ausgaben, behält aber Start, echte Fehler und die Abschlussstatistik bei.

Die Statistik unterscheidet Timer-Ticks, angenommene Submits, Busy/Failed, Ready, In-Flight und die jeweiligen effektiven Raten. Diagnosezeitpunkte erfassen unter anderem RequestAccepted, RenderCommandExecution, WorkerSubmit, NormalTransferQueued und ReadyObserved.

{| class="wikitable"
! Test
! Ergebnis
! Aussage
|-
| 5 Hz, 20 Submits
| etwa 5 Ready/s, 20/20, kein Busy
| Entspannter Single-Slot-Betrieb
|-
| 1000 Hz, 100 Submits, quiet
| 100/100 Ready, 0 Fehler, etwa 58 Ready/s
| Backpressure begrenzt den Durchsatz sicher
|-
| 1000 Hz bei <code>t.MaxFPS 30</code>
| etwa 28–29 Ready/s trotz rund 982 Timer-Ticks/s
| Primary-/SafeCopy-/Ready-Kette ist effektiv framegekoppelt
|}

Ein zusätzlicher non-blocking Aufruf von <code>ImmediateFlush(DispatchToRHIThread)</code> erreicht hohe Render-Command-Raten, hebt die gemessene Frame-Kopplung aber nicht auf. Im 30-FPS-Test lag der RHIEndFrame-spezifische Completion-Takt praktisch exakt bei 30 Hz. Das aktuelle Problem ist damit eingegrenzt: Nicht der Stream-Timer, sondern die Primary-RHI-/D3D12-Submission der SafeCopy-Kette bestimmt die sichtbare Ready-Rate.

=== Queue-Submission-Diagnose ===

<code>MultiGPUD3D12QueueProbe</code> untersucht die Submission unabhängig vom sichtbaren Texturpfad. Neben <code>full</code>, <code>waitonly</code> und <code>signalonly</code> existieren inzwischen die Diagnosemodi <code>computeonly</code>, <code>commandonly</code>, <code>barrieronly</code>, <code>barrierprivate</code> und <code>copybuffer</code>. Als Queues stehen <code>graphics</code>, <code>copy</code>, <code>native</code>, <code>worker</code>, <code>worker-copy</code> und <code>worker-high</code> zur Verfügung. Graphics und Copy verwenden <code>RHIRunOnQueue(..., false)</code> auf UE-verwalteten Primary-Queues; die übrigen Varianten isolieren private beziehungsweise bereits vorhandene native D3D12-Queues.

Der Probe misst Request, Worker-Submit, <code>RHIRunOnQueue</code>-Aufruf und -Callback, Primary-Execute, Fence-Completion sowie Ready bis zum nächsten akzeptierten Submit. Er fügt keine CPU-Waits, Readbacks, Maps oder <code>BlockUntilGPUIdle</code> ein und beschreibt keine Textur des sichtbaren Normal-Pfads.

{| class="wikitable"
! Test
! Ergebnis
! Befund
|-
| UE Graphics, signal-only, 30 FPS
| 33,319 ms PrimaryExecute bis Ready
| UE-verwaltete Graphics-Submission skaliert mit der Frame-Dauer
|-
| UE Copy, signal-only, 30 FPS
| 32,593 ms PrimaryExecute bis Ready
| Auch die UE-verwaltete Copy Queue ist framegekoppelt
|-
| Private Primary-DIRECT-Queue, signal-only
| etwa 0,014 ms Queue/Fence-Latenz; nach Lifecycle-Fix rund 999 Ready/s bei 30 FPS
| Native Queue und Scheduler sind vollständig vom Frame entkoppelt
|-
| Worker signal-only / leere Command List
| jeweils rund 1000 Ready/s bei 30 FPS
| Worker-Queue, Fence und reine Submission sind nicht framegekoppelt
|-
| Worker <code>CopyBufferRegion</code>, 30 / 60 / 120 FPS
| 29,41 / 58,25 / 113,08 Ready/s
| Bereits eine echte 256-Byte-GPU-Kopie folgt im UE-Prozess dem Frame-Raster
|-
| Worker COPY Queue / HIGH Priority, 30 FPS
| jeweils rund 29,42 Ready/s
| Queue-Typ und Priorität beseitigen die Kopplung nicht
|-
| Standalone-D3D12 auf derselben Intel UHD
| 92.956 Copy-Jobs/s; 0,007 ms durchschnittliche Fence-Latenz
| Die Kopplung ist UE-Prozess-/Scheduling-spezifisch, keine allgemeine Intel-, WDDM- oder D3D12-Grenze
|}

Der <code>RHIRunOnQueue</code>-Callback selbst erreicht den D3D12-Submission-Thread typischerweise bereits nach etwa 0,02–0,05 ms; die Verzögerung entsteht danach in der verwalteten Queue-/Submission-Reihenfolge. <code>SubmitCommandsHint()</code> ist in UE 5.8 nur ein veralteter Alias für <code>ImmediateFlush(DispatchToRHIThread)</code> und stellt daher keinen stärkeren Submission-Mechanismus dar.

Der native Test ist ein '''Architekturbeweis, noch kein Experimental- oder Direct-Modus'''. Die zunächst gemessene Verzögerung von rund 32 ms lag zwischen der In-Flight-Freigabe und dem nächsten Request auf dem Render Thread. Für <code>signalonly/native</code> wurde der sichere Completion-/Submit-Lifecycle deshalb in den frameunabhängigen Scheduler verlegt. Danach erreichten zwei 100-Job-Läufe bei <code>t.MaxFPS 30</code> rund 999 bis 1029 Ready/s, ohne Busy oder Fehler.

Der anschließende <code>full native</code>-Test lokalisierte die verbleibende Kopplung auf echte Worker-GPU-Arbeit: WorkerSubmit bis WorkerReady benötigte bei 30, 60 und 120 FPS ungefähr 33,29, 16,93 und 8,45 ms; WorkerReady bis PrimaryReady war danach praktisch sofort. Signal-only und eine leere Command List waren schnell, Resource Barriers und eine 256-Byte-Kopie dagegen framegebunden. Ein eigenständiger D3D12-Microbenchmark auf derselben Intel UHD erreichte außerhalb von Unreal bei derselben Kopie rund 92.956 Jobs/s mit 0,007 ms mittlerer Fence-Latenz. Die genaue Ursache im UE-Prozess beziehungsweise dessen GPU-Scheduling-Kontext bleibt offen und wird vorerst bis zum Gegencheck mit der vorhandenen Intel Arc A380 geparkt.

=== Worker-Rasterpfad und RasterStream ===

<code>ExperimentalMultiGPU.TestRasterWorker</code> weist erstmals echte Rasterizer-Arbeit auf der Intel-Worker-GPU nach. <code>RasterWorkerVS</code> und <code>RasterWorkerPS</code> werden über Unreals Global-Shader-Pfad kompiliert und für ein natives Worker-Graphics-PSO verwendet. Ein persistentes 128×96-RGBA8-RenderTarget besitzt RTV, leere Root Signature und eine DIRECT-Command-List. Der Vertex Shader erzeugt drei Vertices über <code>SV_VertexID</code>; der Pixel Shader schreibt interpolierte RGB-Farben.

Der Job wechselt das RenderTarget von <code>COPY_SOURCE</code> nach <code>RENDER_TARGET</code>, führt Clear und <code>DrawInstanced(3,1,0,0)</code> aus und wechselt anschließend zurück nach <code>COPY_SOURCE</code>. Danach verwendet er unverändert den robusten Normalpfad aus Cross-Adapter-Shared-Buffer, Primary SafeCopy, persistenter <code>FTextureRHIRef</code>, <code>UExperimentalMultiGPUTexture</code> und DisplayActor. Der Runtime-Test meldete einen akzeptierten Submit und <code>RasterWorker READY</code> für Generation 1; die 128×96-UTexture wurde erfolgreich gebunden.

Der einmalige Test wurde außerdem zu einem frei konfigurierbaren RasterStream ausgebaut. Ein sichtbarer Lauf mit 10 Hz und 50 erfolgreichen Submits endete mit 50 Ready-Ausgaben, 0 Busy und 0 Fehlern bei etwa 9,90 Ready/s. Primary-Textur und Materialbindung blieben dabei persistent.

=== Raster3D mit echten Vertex- und Indexbuffern ===

Der Worker besitzt inzwischen einen kleinen eigenständigen 3D-Rasterpfad mit perspektivischer Kamera, Model-View-Projection-Matrix als Root Constants, D32_FLOAT-Depth-Buffer und Depth-Test. Der finale Testwürfel verwendet 24 POSITION/COLOR-Vertices, 36 <code>uint16</code>-Indices und <code>DrawIndexedInstanced(36,1,0,0,0)</code>; sechs getrennte Seitenfarben machen Ausrichtung und Rotation sichtbar nachvollziehbar.

Die statischen Meshdaten werden einmalig über private Upload-Buffer in DEFAULT-Heaps übertragen. Der Init-Fence wird non-blocking über <code>GetCompletedValue()</code> beobachtet. Der eigentliche Runtime-Renderpfad enthält weiterhin keine CPU-Waits und keine Maps.

=== UE-Static-Meshes auf der Worker-GPU ===

<code>StaticMeshWorker</code> extrahiert echte LOD0-Geometrie aus <code>UStaticMesh</code>-Assets. POSITION und NORMAL sowie <code>uint32</code>-Indices werden in POD-Daten überführt, einmalig asynchron in eigene Worker-VB/IB hochgeladen und anschließend per <code>DrawIndexedInstanced</code> gerendert. Assetpfade sind dynamisch; Auto-Fit richtet Kamera beziehungsweise Modellmaßstab an den Bounds aus.

Sichtbar korrekt getestet wurden:

{| class="wikitable"
! Asset
! Vertices
! Indices
|-
| Sphere
| 559
| 2880
|-
| Cube
| 54
| 144
|-
| Cylinder
| 334
| 1536
|}

=== Multi-Mesh Worker-Szene ===

<code>StaticMeshScene</code> rendert Sphere, Cube und Cylinder gemeinsam in einen Color-/Depth-Frame. Der verifizierte Test umfasst insgesamt 947 Vertices und 4560 Indices, drei <code>DrawIndexedInstanced</code>-Aufrufe und nur einen anschließenden Cross-Adapter-/Normal-SafeCopy-Transfer. Damit ist nicht mehr nur ein synthetisches Primitive, sondern mehrere echte UE-Meshes mit gemeinsamer Tiefenprüfung im Worker-Frame sichtbar nachgewiesen.

=== WorldStaticMeshScene ===

<code>ExperimentalMultiGPUWorldStaticMeshScene.cpp</code> sammelt im Engine-Layer bis zu acht sichtbare <code>UStaticMeshComponent</code>s von Actors mit dem Tag <code>MultiGPUWorker</code>. Meshdaten und World-Transforms werden im Game Thread in reine POD-Strukturen und 4×4-Matrizen kopiert. D3D12RHI erhält keine <code>UObject</code>-Pointer. Mehrere Instanzen desselben Meshes teilen den persistenten Worker-Mesh-Cache und unterscheiden sich nur durch Modelmatrix und Draw Call.

Der Pfad wurde inzwischen sichtbar im PIE-Level verifiziert. Drei getaggte Static-Mesh-Actors erschienen mit ihren tatsächlichen relativen Positionen, Rotationen und Skalierungen im Worker-Bild. Die zentrale Koordinatenumrechnung lautet:

<pre>Worker (X, Y, Z) = (UE Y, UE X, -UE Z)</pre>

Die Transformation besitzt die Determinante +1 und ist damit keine Spiegelung. Das notwendige horizontale Spiegeln erfolgt ausschließlich auf der Presentation-Plane, nicht im Worker-Renderpfad.

=== Kontinuierlicher WorldStaticMeshSceneStream ===

<code>StartWorldStaticMeshSceneStream</code> erfasst die getaggte Szene fortlaufend im Game Thread. Reine Änderungen an Transform oder Kamera lösen keinen erneuten Mesh-Upload aus. Hinzugekommene, entfernte, unsichtbare oder umgetaggte Components werden im nächsten Snapshot berücksichtigt. Single-Slot-Backpressure verhindert einen wachsenden Rückstau.

Ein verifizierter 30-Hz-Lauf endete nach 31,184 Sekunden mit 835 Ticks, 691 angenommenen Submits, 144 Busy, 0 Fehlern und 691 Ready-Frames. Die effektive Ready-Rate betrug 22,16 Hz. Dieser Test belegt die funktionale Live-Aktualisierung; die Rate war noch kein Optimierungsziel.

=== SceneCapture2D als Worker-Kamera ===

<code>TestSceneCaptureStaticMeshScene</code> verwendet eine echte <code>ASceneCapture2D</code> beziehungsweise <code>USceneCaptureComponent2D</code> aus der laufenden PIE-Welt als Kameraquelle. Der empfohlene Editor-Weg ist das Component Tag <code>MultiGPUWorkerCamera</code> auf der <code>CaptureComponent2D</code>; ein gleichnamiges Actor-Tag bleibt nur als Legacy-Fallback.

Ausgelesen werden World Location, Rotation, Forward/Right/Up, <code>FOVAngle</code> und <code>ProjectionType</code>. Orthografische Projektion wird derzeit sauber abgelehnt. Die SceneCapture2D liefert ausschließlich Kameradaten: Ihr UE-RenderTarget wird weder gelesen noch kopiert. Die Intel-Worker-GPU rendert die Geometrie selbst. Kamera und Actors werden gemeinsam mit <code>SceneScale = 0.01</code> in Worker-Koordinaten überführt; Auto-Fit und Scene-Recentering sind in diesem Modus deaktiviert.

Die 128×96-Worker-Projektion verwendet ein Seitenverhältnis von 4:3 und interpretiert <code>FOVAngle</code> als horizontales FOV. Nach den Orientierungstests wird nur die Anzeige über <code>SetRelativeScale3D(FVector(-4.0f, -3.0f, 1.0f))</code> korrigiert; dies entspricht <code>U' = 1-U</code> und <code>V' = 1-V</code>.

=== Live SceneCaptureStaticMeshSceneStream ===

<code>StartSceneCaptureStaticMeshSceneStream</code> liest Kamera-Transform, Kamerabasis, FOV und aktuelle Actor-Transforms pro Snapshot neu im Game Thread. Der Worker erhält weiterhin ausschließlich POD-Daten, verwendet den persistenten Mesh-Cache sowie ein gemeinsames Color- und D32-Depth-Target und führt pro akzeptiertem Frame genau einen Cross-Adapter-/Normal-SafeCopy-Transfer aus.

Der Quiet-Test

<pre>ExperimentalMultiGPU.StartSceneCaptureStaticMeshSceneStream 30 300 quiet</pre>

lieferte in 10,084 Sekunden 301 Ticks, 300 Submits, 1 Busy, 0 Fehler und 300 Ready-Frames. Die effektive Ready-Rate betrug 29,75 Hz. Bewegungen der Kamera und Actors sowie FOV-Änderungen erschienen live auf der Display-Plane. Damit ist erstmals ein kleiner SceneCapture-/CCTV-artiger Worker-Kanal vollständig funktional nachgewiesen.

=== Dynamische SceneCapture-Auflösung ===

Die SceneCapture-Ausgabe ist nicht mehr fest auf 128×96 Pixel begrenzt. <code>ExperimentalMultiGPU.SetSceneCaptureResolution <Width> <Height></code> setzt ganzzahlige Dimensionen von 1 bis 4096; <code>GetSceneCaptureResolution</code> zeigt die aktive Einstellung. 128×96 bleibt der Standard. Während ein SceneCapture-Stream läuft, wird ein Auflösungswechsel absichtlich abgelehnt, damit keine In-Flight-Ressourcen ausgetauscht werden.

Color Target, D32-Depth-Buffer, Row Pitch, Shared-Buffer-Transport, SafeCopy, persistente Primary-Textur und <code>UExperimentalMultiGPUTexture</code> übernehmen die gewählten Dimensionen. Projektion und Display-Plane verwenden das echte Seitenverhältnis. Die bestätigte Anzeigeorientierung <code>U' = 1-U</code> und <code>V' = 1-V</code> bleibt eine reine Presentation-Korrektur; Worker-Basis und Kameramathematik ändern sich nicht.

=== Scheduler-Korrektur bei SceneCapture ===

Ein 1920×1080-Test mit 25 Hz erreichte zunächst trotz fehlerfreier Frames nur 13,90 Ready-Hz und erzeugte 222 Busy-Ticks. Ursache war kein GPU-Limit, sondern ein Polling-Aliasing: Eine frühe Game-Thread-Prüfung konnte den Timer-Slot verwerfen, obwohl die Completion kurz darauf im CoreTicker/RHI-Pump sichtbar geworden wäre.

Die frühe <code>IsRuntimeTextureUpdateInFlight()</code>-Prüfung wurde für diesen Stream entfernt. Der Pending-Request bleibt als Backpressure-Gate erhalten; die maßgebliche Busy-Entscheidung fällt nun erst im Render Command nach <code>TickNormalTextureTransfers(nullptr, true)</code>. Single-Slot, POD-Snapshots und non-blocking <code>GetCompletedValue()</code> bleiben erhalten. Es wurden weder CPU-Waits noch zusätzliche Threads eingeführt.

Nach der Korrektur erreicht 1080p bei 25 Hz 24,79 Ready-Hz mit 1 Busy; bei 30 Hz sind es 29,43 Ready-Hz mit 4 Busy.

=== Skalierung bis 4K60 ===

Die Pipeline wurde von 640×360 bis 3840×2160 getestet. Bei 640×360/30 Hz und 1280×720/30 Hz wurden 29,85 beziehungsweise 29,82 Ready-Hz ohne Busy erreicht. 1920×1080/60 Hz lieferte 59,40 Ready-Hz ohne Busy, 2560×1440/60 Hz 59,21 Ready-Hz mit 1 Busy und 3840×2160/60 Hz 59,02 Ready-Hz mit 2 Busy.

Ein zusätzlicher 4K60-Stresstest mit acht Static-Mesh-Instanzen und drei gecachten Unique Meshes erreichte in 5,049 Sekunden '''300 von 300 Ready-Frames, 0 Busy, 0 Fehler und 59,42 effektive Ready-Hz'''. Acht Draw Calls, gemeinsamer Depth Buffer, Cross-Adapter-Transport und SafeCopy liefen dabei im vorhandenen Single-Slot. Das ist ein Stabilitätsnachweis der aktuellen Mini-Szene, kein allgemeiner GPU-Benchmark.

=== Skeletal Mesh in Reference Pose ===

<code>ExperimentalMultiGPU.TestSkeletalMeshWorker</code> erweitert den Geometriepfad auf <code>USkeletalMeshComponent</code>. Der Engine-Layer sucht deterministisch die erste sichtbare, getaggte Komponente und extrahiert LOD0-Positionen, Normalen, Indices und Render Sections. D3D12RHI erhält wie bisher ausschließlich POD-Geometrie und Modelmatrizen.

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. Skeletal Skinning ist erst vorgesehen, wenn ein echter Worker-Workload wie CCTV oder Spiegel animierte Figuren in seiner eigenen Ansicht benötigt.

=== Generische Workload-Registry ===

Commit <code>37c6d02</code> führt erstmals eine backend-neutrale Workload-Schicht ein. Sie beschreibt Aufgaben unabhängig vom konkreten Grafik-Backend und bildet die Grundlage für einen späteren Scheduler, trifft selbst aber noch keine GPU-Entscheidung.

{| class="wikitable"
! Bestandteil
! Inhalt
|-
| Workload-Typ
| <code>Unknown</code>, <code>SceneCapture</code>, <code>Compute</code> oder <code>Raster</code>
|-
| Gewünschte Zuweisung
| <code>Primary</code>, <code>Worker</code> oder <code>Auto</code>; <code>Auto</code> ist derzeit nur Metadatum
|-
| Priorität
| <code>Low</code>, <code>Normal</code> oder <code>High</code>
|-
| Descriptor
| Sessionweit monotone ID, Typ, Zuweisung, Priorität, Auflösung, Zielrate, Debugname und Running-Status
|}

Die Registry stellt <code>RegisterWorkload</code>, <code>UpdateWorkload</code>, <code>UnregisterWorkload</code>, <code>GetWorkload</code> und <code>GetActiveWorkloads</code> bereit und schützt ihre Daten per <code>FCriticalSection</code>. Descriptoren enthalten weder <code>UObject</code>- noch D3D12-Pointer. Der SceneCapture-Stream registriert genau einen Worker-Workload mit normaler Priorität und entfernt ihn bei Stop oder Auto-Stop wieder vollständig.

<code>ExperimentalMultiGPU.ListWorkloads</code> zeigt die aktiven Descriptoren und ihre Laufzeitwerte an.

=== Runtime Metrics V1 ===

Descriptor und Laufzeitstatistik sind getrennt. Pro Workload werden Ticks, angenommene Submits, Busy- und Fehlerfälle, fertige Frames, aktuell ausstehende Jobs, Laufzeit sowie effektive Tick-, Submit- und Ready-Raten erfasst. Der SceneCapture-Pfad spiegelt dafür seine vorhandenen Stream-Zähler in die Registry, statt eine zweite Statistiklogik aufzubauen. Die Messwerte werden derzeit nur beobachtet und ändern weder Zuweisung noch Auflösung oder Zielrate.

Editor-Fokus und Background-Throttling können die Lifecycle-Raten deutlich verfälschen. In einem sauberen 1280×720-Referenzlauf wurden 1000/1000 Ready-Frames ohne Busy bei 29,84 Ready-Hz gemessen; bei wechselndem Fensterfokus entstanden dagegen 459 Busy-Ticks und nur 16,69 Ready-Hz, ohne dass die Worker-GPU-Zeit entsprechend einbrach. Solche Raten sind daher kein verlässlicher Ersatz für echte GPU-Kostenmessungen.

=== Worker GPU Timing V1 ===

Der SceneCapture-Worker verwendet persistente native D3D12-Timestamp-Queries auf seiner vorhandenen DIRECT-Queue: einen Query Heap mit zwei Slots, einen kleinen Readback-Buffer und die per <code>GetTimestampFrequency()</code> ermittelte Zeitbasis. Das Ergebnis wird erst nach non-blocking geprüftem Fence-Abschluss gelesen; CPU-Waits entstehen nicht. Die Workload-ID wird als POD bis zum Worker mitgeführt, während einmalige Tests die ID 0 verwenden.

Gemessen wird ausschließlich der Worker-Rasterabschnitt:

<pre>
Start Timestamp
-> COPY_SOURCE nach RENDER_TARGET
-> Color- und Depth-Clear
-> alle DrawIndexedInstanced-Aufrufe
-> RENDER_TARGET nach COPY_SOURCE
End Timestamp
-> ResolveQueryData
</pre>

Nicht enthalten sind der Cross-Adapter-Transfer, die Primary-SafeCopy und die Integration auf der Primary-GPU. Erfasst werden Sample-Anzahl sowie letzter, mittlerer, minimaler und maximaler Messwert.

{| class="wikitable"
! Auflösung
! Samples
! Mittelwert
! Minimum
! Maximum
|-
| 1280×720
| 845
| 0,166 ms
| 0,165 ms
| 0,181 ms
|-
| 3840×2160
| 599
| 0,683 ms
| 0,594 ms
| 0,751 ms
|}

Bei identischem, bewusst einfachem Szeneninhalt mit sieben Draw Calls steigt die gemessene Worker-Rasterzeit damit ungefähr um Faktor 4,1. Die Pixelzahl allein erklärt die Skalierung nicht vollständig. Für ein belastbares Kostenmodell müssen als Nächstes Transfer und Primary-Integration separat gemessen werden.

=== Cook- und Packaged-Support der Multi-GPU-Shader ===

Vor Commit <code>1fc0d24</code> startete ein Packaged Build nicht, weil unter anderem die Permutation von <code>FExperimentalMultiGPUStaticMeshPS</code> in der cooked Global Shader Map fehlte. Die Shader selbst waren korrekt; ihre neun <code>FGlobalShader</code>-Typen wurden jedoch im D3D12RHI registriert, das beim Cook zu diesem Zeitpunkt noch nicht geladen war.

Die Deklarationen liegen nun im RenderCore-Header <code>ExperimentalMultiGPUShaders.h</code>, die zugehörigen <code>IMPLEMENT_GLOBAL_SHADER</code>-Registrierungen in <code>ExperimentalMultiGPUShaders.cpp</code>. D3D12RHI verwendet nur noch die exportierten RenderCore-Typen. Shaderpfade, Entry Points und die bestehende Shader-Blob-Erkennung bleiben unverändert. Der Cook kompilierte die ExperimentalMultiGPU-Shader nachweislich; das anschließende Development-Package startete ohne den früheren <code>Missing global shader</code>-Fatal. Damit ist der Worker-Pfad shaderseitig nicht mehr auf den Editor beschränkt.

=== DLSS5 Neural Rendering als späterer Worker-Kandidat ===

Der Branch enthält nun auch [[DLSS5ForUE5]] als quelltextbasierte Win64-/D3D12-Integration für NVIDIA Neural Rendering. Das Plugin verwendet den bereits vom offiziellen NVIDIA-DLSS-Plugin initialisierten NGX-Core und eröffnet keine konkurrierende NGX-Application-Session. Neural Rendering läuft derzeit auf der Primary-NVIDIA-GPU; ein Multi-GPU-Offload ist noch nicht implementiert.

Die Integration umfasst:

* eine eigene <code>Config/DLSS5ForUE5.ini</code> mit 20 projektbezogenen Einstellungen,
* einen ausschließlich im Editor wirksamen Safe Boot, der Neural Rendering und Scene Guides nur für die aktuelle Session deaktiviert,
* eine native <code>DLSS5ForUE5_nvngx.dll</code> als unmittelbaren Caller für den NVIDIA-Caller-Gate,
* Depth- und Motion-Guides aus der laufenden UE-Szene,
* die Supportzustände <code>AVAILABLE</code>, <code>UNAVAILABLE</code>, <code>UNSUPPORTED</code> und <code>WAITING</code> mit sauberem Fallback statt wiederholtem Init-Logspam.

Im monolithischen Packaged Game wurde der NGX-Init zunächst mit <code>0xBAD00002</code> abgelehnt, weil der Aufruf aus der Spiel-EXE kam. Eine native Bridge löst dieses Problem. Zusätzlich musste die MSVC-Tail-Call-Optimierung verhindert werden: Erst ein echter <code>call</code> mit erhaltenem Bridge-Stackframe ließ die DLL als unmittelbaren Caller sichtbar bleiben. Danach meldete die Runtime Caller Gate, NGX-Core, Parameter und Initialisierung erfolgreich. In einem Packaged-Lauf waren 2036 von 2036 Evaluierungen erfolgreich; Depth und Motion waren jeweils angefordert, verfügbar und verwendet.

Der Pfad wurde sowohl im kleinen <code>UpscalerTest</code> als auch im eigentlichen Spielprojekt mit vorhandenen DLSS-, FSR- und XeSS-Plugins validiert. Auf dem Hybrid-Laptop blieb der Support trotz zusätzlicher Intel UHD korrekt <code>AVAILABLE</code>, weil der aktive Renderadapter statt der bloßen Existenz eines Intel-Adapters ausgewertet wird.

==== Gemessene Kosten ====

Eine bewusst schwere Wald-/Wasserszene auf der RTX 5060 Laptop GPU wurde bei Epic Scalability und 83,4 % Render Resolution, ungefähr 1404×715 Pixel im Viewport, gemessen. Die Ergebnisse sind Momentaufnahmen und kein allgemeiner Leistungswert.

{| class="wikitable"
! Zustand
! FPS
! Framezeit
! GPU-Zeit
! Zusätzliche GPU-Zeit gegenüber aus
|-
| Neural Rendering aus
| 41,68
| 23,99 ms
| 17,19 ms
| –
|-
| 1 Pass
| 30,87
| 32,38 ms
| 26,75 ms
| +9,56 ms
|-
| 2 Passes
| 23,16
| 43,05 ms
| 35,84 ms
| +18,65 ms
|-
| 4 Passes
| 16,07
| 62,27 ms
| 54,19 ms
| +37,00 ms
|-
| 2 Passes mit Depth/Motion
| 23,52
| 42,39 ms
| 35,99 ms
| +18,80 ms
|}

In dieser frühen Testreihe kostete ein Neural-Pass ungefähr 9 bis 9,5 ms zusätzliche GPU-Zeit. Depth und Motion erhöhten den Zwei-Pass-Wert nur um etwa 0,15 ms und lagen damit im Bereich der Messschwankung. Spätere Läufe mit Preset 3 und vier Passes lagen deutlich niedriger, beispielsweise bei ungefähr 26 ms GPU-Zeit in einer anderen Szeneneinstellung. Preset, Feature-Vertrag, Szene und Viewport müssen deshalb bei künftigen Benchmarks immer mitprotokolliert werden. Gerade der große, klar abgrenzbare Evaluierungsblock macht Neural Rendering zu einem interessanten späteren Scheduler-Workload.

== Test- und Diagnosebefehle ==

Die vorhandenen Compute-, Texture-, Raster-, StaticMesh-, World- und QueueProbe-Kommandos bleiben bestehen. Neu hinzugekommen ist:

{| class="wikitable"
! Befehl
! Zweck
|-
| <code>ExperimentalMultiGPU.ListWorkloads</code>
| Listet aktive Workloads mit ID, Typ, gewünschter Zuweisung, Priorität, Auflösung, Zielrate, Lifecycle-Statistik und Worker-GPU-Timing auf.
|}

Für den aktuellen Hauptpfad sind außerdem besonders relevant:

<pre>
ExperimentalMultiGPU.SetSceneCaptureResolution <Width> <Height>
ExperimentalMultiGPU.GetSceneCaptureResolution
ExperimentalMultiGPU.TestSceneCaptureStaticMeshScene
ExperimentalMultiGPU.StartSceneCaptureStaticMeshSceneStream [Hz] [MaxSuccessfulSubmits] [quiet]
ExperimentalMultiGPU.StopSceneCaptureStaticMeshSceneStream
ExperimentalMultiGPU.TestSkeletalMeshWorker
ExperimentalMultiGPU.ListWorkloads
</pre>

=== Texture Stream ===

Grundsyntax:

<pre>ExperimentalMultiGPU.StartTextureStream [Hz] [MaxSuccessfulSubmits] [quiet]</pre>

Die Hz-Angabe ist eine Ziel- beziehungsweise Request-Frequenz. <code>MaxSuccessfulSubmits</code> zählt nur angenommene Submits; Busy- und Failed-Versuche verbrauchen das Limit nicht. <code>quiet</code> unterdrückt Per-Job- und Busy-Logspam.

=== QueueProbe ===

Grundsyntax:

<pre>ExperimentalMultiGPU.StartQueueProbe <Hz> <MaxSubmits> [quiet] <Mode> <Queue></pre>

Die Diagnosemodi <code>full</code>, <code>waitonly</code>, <code>signalonly</code>, <code>commandonly</code>, <code>barrieronly</code>, <code>barrierprivate</code> und <code>copybuffer</code> bleiben verfügbar. Als Queue können <code>graphics</code>, <code>copy</code>, <code>native</code>, <code>worker</code>, <code>worker-copy</code> und <code>worker-high</code> gewählt werden. Private native Queues dienen weiterhin nur der Diagnose und bilden keinen fertigen Experimental-/Direct-Modus.

=== Benchmark-CVars ===

<code>r.VSync 0</code> deaktiviert VSync. <code>t.MaxFPS 30</code>, <code>60</code> oder <code>120</code> erzeugt reproduzierbare Frame-Coupling-Tests; <code>t.MaxFPS 0</code> entfernt das normale Framerate-Limit.

== Aktueller nächster Schritt ==

Als Nächstes wird die Source-Engine auf dem Desktop-System mit AMD RX 6900 XT und Intel Arc validiert. DLSS5 soll dort sauber <code>UNSUPPORTED</code> melden und das normale Rendering nicht beeinflussen. Parallel 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 ==

Die Grundidee heterogener Multi-GPU-Nutzung ist nicht neu. Bereits mit der Einführung von Direct3D 12 entstanden mehrere Versuche, integrierte und dedizierte GPUs gemeinsam zu verwenden. Eine allgemein einsetzbare Lösung für moderne UE5-Spiele hat sich daraus jedoch nicht entwickelt.

=== Microsoft und Epic: UE4 Elemental Demo (2015) ===

Microsoft zeigte eine angepasste Unreal-Engine-4-Version der Elemental-Demo, bei der eine NVIDIA-GPU und eine Intel-iGPU gemeinsam arbeiteten. Das erklärte Ziel war, ansonsten ungenutzte Grafikleistung in Hybrid-Systemen zu verwenden. Dieser Versuch ist der Grundidee des Projekts besonders ähnlich, blieb aber eine technische Demonstration.

=== Intel: D3D12 Multi-Adapter Sample (2015) ===

Intels Beispiel kombinierte eine GeForce 840M mit Intel HD Graphics 5500. Beide GPUs berechneten getrennte Teile einer einfach parallelisierbaren Raytracing-Szene. Cross-Adapter-Ressourcen und Shared Fences führten die Ergebnisse anschließend zusammen. Intel berichtete in diesem Test von nahezu halbierter Framezeit, warnte jedoch ausdrücklich davor, das Ergebnis unmittelbar auf reale Spiele zu übertragen.

=== Ashes of the Singularity ===

Die Nitrous Engine von ''Ashes of the Singularity'' setzte Direct3D-12-Explicit-Multiadapter in einem veröffentlichten Spiel ein. Dabei konnten auch unterschiedliche GPU-Modelle und Hersteller zusammenarbeiten. Das war ein wichtiger Praxisnachweis, blieb in der Spielebranche aber eine seltene Ausnahme.

=== Weitere verwandte Ansätze ===

* ''Rise of the Tomb Raider'' erhielt explizite Direct3D-12-Multi-GPU-Unterstützung, vor allem für klassische Kombinationen ähnlicher GPUs.
* NVIDIA VR SLI wies bei Virtual Reality jeder GPU ein Auge zu. Das verteilt unabhängige Ansichten, bleibt jedoch NVIDIA-spezifisch.
* Unreal nDisplay kann Viewports oder Frustums auf weitere GPUs beziehungsweise Prozesse auslagern und das fertige Bild zur Ausgabe-GPU zurückführen. Der Einsatzbereich ist hauptsächlich Virtual Production.
* Forschung und High-Performance Computing verwenden seit Jahren Scheduler für heterogene GPUs, allerdings überwiegend für Compute- und Datenverarbeitungsaufgaben statt für einen allgemeinen UE5-Echtzeitrenderer.

=== Abgrenzung dieses Projekts ===

Das Projekt erfindet Direct3D-12-Explicit-Multiadapter nicht neu. Sein eigener Ansatz liegt in der Kombination aus tiefer UE5.8-RHI-Integration, UE-kompilierten Shadern auf unabhängigen Worker-Devices, frei wählbaren Spiel- und Compute-Workloads, Capability- und Performance-Scheduler, mehreren Fallback-Pfaden sowie dem langfristigen Ziel beliebiger Hersteller und mehrerer Worker.

== Vergleich mit anderen Multi-GPU-Verfahren ==

{| class="wikitable"
! Verfahren
! Arbeitsweise
! Verhältnis zu diesem Projekt
|-
| SLI / CrossFire
| Treiber- beziehungsweise Verbundlösung für meist ähnliche GPUs; häufig wird die Bildarbeit verteilt.
| Dieses Projekt benötigt keinen herstellerspezifischen GPU-Verbund und weist Aufgaben ausdrücklich selbst zu.
|-
| AFR (Alternate Frame Rendering)
| GPU 1 rendert einen Frame, GPU 2 den nächsten.
| Das Projekt verteilt unabhängige Aufgaben statt aufeinanderfolgender Frames. Dadurch werden Frame-Abhängigkeiten und typisches AFR-Pacing vermieden.
|-
| SFR (Split Frame Rendering)
| Mehrere GPUs bearbeiten Bereiche desselben Frames.
| Erfordert enge Lastverteilung und viel Datenaustausch. Das Projekt bevorzugt vollständig abgrenzbare Workloads und überträgt deren Ergebnis.
|-
| Direct3D 12 Linked Multiadapter
| Mehrere vom Treiber verbundene GPUs erscheinen als Knoten eines logischen Adapters.
| Eignet sich eher für eng kompatible GPUs. Das Projekt verwendet unabhängige Devices (Unlinked/Explicit Multiadapter) und unterstützt dadurch heterogene Herstellerkombinationen.
|-
| Direct3D 12 Unlinked / Explicit Multiadapter
| Die Anwendung verwaltet getrennte Adapter, Ressourcen und Synchronisation selbst.
| Das ist die technische Familie des Projekts. Hinzu kommen die eigene UE5-RHI-Integration, Workload-Ziele, Fallbacks und der geplante Scheduler.
|-
| UE nDisplay mGPU / Multi-Process
| Separate GPUs rendern bestimmte Viewports oder Frustums, vor allem für Virtual Production; Ergebnisse werden zur Ausgabe-GPU kopiert.
| Ähnliche Idee der aufgabenweisen Trennung, aber für einen anderen Einsatzbereich. Dieses Projekt zielt auf allgemeine Spiel- und Compute-Workloads innerhalb der Engine.
|-
| Vulkan Device Groups
| Ähnliche physische GPUs können ein gemeinsames logisches Device bilden.
| Für beliebige heterogene GPUs meist ungeeignet, da Geräte einer Gruppe nahezu gleiche Eigenschaften besitzen müssen. Eine spätere Vulkan-Portierung benötigt daher wahrscheinlich getrennte Devices und External Memory/Semaphores.
|}

SLI und CrossFire bezeichnen den Verbund; AFR und SFR beschreiben mögliche Verteilungsmethoden innerhalb solcher Systeme. Sie sind deshalb nicht vollständig getrennte Kategorien.

== Vorteile der geplanten Variante ==

* '''Herstellerunabhängig:''' NVIDIA, AMD und Intel können grundsätzlich kombiniert werden.
* '''Vorhandene Hardware nutzen:''' Auch eine sonst wenig genutzte integrierte GPU kann geeignete Nebenaufgaben übernehmen.
* '''Aufgaben statt Frames verteilen:''' Spiegel, Minimap oder Compute können mit eigener Auflösung und Aktualisierungsrate laufen.
* '''Keine identischen GPUs erforderlich:''' Unterschiedliche Fähigkeiten können gezielt genutzt werden.
* '''Kontrollierter Datenaustausch:''' Nur das benötigte Ergebnis muss zurück zur Primary-GPU.
* '''Robuste Fallback-Idee:''' Wenn direkte Texturen nicht gemeinsam nutzbar sind, bleibt der Shared-Buffer-Pfad.
* '''Erweiterbar:''' Scheduler, manuelles Mapping und mehrere Worker sind als spätere Stufen vorgesehen.

== Nachteile und technische Risiken ==

* '''Hoher Entwicklungsaufwand:''' Geräte, Ressourcen, Zustände, Fences, Fehlerfälle und UE-Lebenszyklen müssen selbst verwaltet werden.
* '''Transfer kann den Gewinn aufzehren:''' Cross-Adapter Heaps liegen laut D3D12 nicht automatisch im schnellen lokalen VRAM. Bandbreite und Latenz müssen für jeden Workload gemessen werden.
* '''VRAM wird nicht einfach addiert:''' Benötigte Ressourcen können auf mehreren GPUs vorliegen und zusätzlichen Speicher verbrauchen.
* '''Langsame Worker können bremsen:''' Eine Aufgabe lohnt sich nur, wenn Rechengewinn größer als Übergabe-, Warte- und Kopierkosten ist.
* '''Nicht jeder Workload ist unabhängig:''' Hauptansicht, Lumen, Nanite und stark gekoppelte Renderpässe besitzen viele Abhängigkeiten und sind schwieriger auszulagern.
* '''Hardwareunterschiede:''' Formate, Shader-Funktionen, Queue-Fähigkeiten und Cross-Adapter-Support müssen pro GPU geprüft werden.
* '''Wartungsrisiko:''' Eingriffe in private D3D12RHI-Dateien können bei Engine-Updates angepasst werden müssen.
* '''Produktionsreife fehlt noch:''' Ressourcenpools, Timeouts, Device-Lost-Wiederherstellung, Scheduler und echte Szenentests sind offen.

== Wann die Variante sinnvoll ist ==

Am aussichtsreichsten sind Aufgaben mit viel eigener Rechenarbeit, einem relativ kleinen Endergebnis und wenigen Abhängigkeiten zur Hauptszene. Gute frühe Kandidaten sind unabhängige Compute-Aufgaben sowie Scene Captures, die nicht in jedem Frame aktualisiert werden müssen. Weniger geeignet sind winzige Aufgaben mit großem Transfer oder Renderpässe, die ständig auf Ressourcen der Primary-GPU zugreifen.

Die entscheidende Regel für den späteren Scheduler lautet daher:

<pre>
Worker-Gewinn > Vorbereitung + Datentransfer + Synchronisation + Rückintegration
</pre>

== Bekannte Grenzen des Proof of Concepts ==

* 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 sichtbarer Runtime-Slot. Mehrere parallele In-Flight-Jobs und Ringbuffer fehlen noch.
* Praktisch getestet ist Primary plus ein Worker. Mehrere Worker sind architektonisch vorgesehen, aber noch nicht praktisch validiert.
* World- und SceneCapture-Pfade verarbeiten pro Snapshot höchstens acht sichtbare <code>UStaticMeshComponent</code>s.
* 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.
* <code>USkeletalMesh</code> ist bislang ein LOD0-ReferencePose-Proof. Bone-Skinning, Animation, Morph Targets und Cloth fehlen.
* Die Workload-Registry sammelt Metadaten und Messwerte, führt aber noch keine automatische Zuweisung, Auflösungsänderung oder Ratenanpassung aus.
* Worker GPU Timing V1 misst nur den Rasterabschnitt. Cross-Adapter-Transfer und Primary-SafeCopy fehlen noch im Kostenmodell.
* 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.
* QueueProbe und private native Queues bleiben Diagnosepfade; Experimental/Direct ist noch nicht implementiert.
* 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.
* DLSS5 Neural Rendering ist aktuell auf Win64, D3D12 und einen aktiven NVIDIA-Renderadapter beschränkt. Der Workload läuft noch auf der Primary-GPU und ist nicht an den heterogenen Worker-Pfad angebunden.
* Depth- und Motion-Guides funktionieren technisch; Bildqualität und temporale Stabilität in Bewegung benötigen weitere Bewertung.
* Direktes Umschalten von <code>r.DLSS5.PassCount</code> war im Editor zeitweise nicht zuverlässig, während der Settings-Slider den Wert korrekt setzte.
* Die Kosten von Neural Rendering hängen stark von Preset, Passzahl, Szene, Feature-Vertrag und Auflösung ab. Einzelmessungen dürfen nicht als feste Kosten pro Pass verallgemeinert werden.
* Linux/Vulkan mit getrennten Devices, External Memory und externer Synchronisation ist noch nicht implementiert.

== Roadmap ==

# Cross-Adapter Transfer Timing V1: Worker-ColorTarget → Shared Buffer separat messen.
# Primary SafeCopy Timing ergänzen und die Integrationskosten getrennt halten.
# Kostenmodell V1 aus Worker-Raster, Transfer und Primary-Integration pro Workload ableiten.
# D3D12-Pfade mit Intel Arc A750/A380 und RX 6900 XT in unterschiedlichen Primary-/Worker-Rollen gegenprüfen; DLSS5 muss auf AMD/Intel sauber zurückfallen.
# Weitere echte Workload-Klassen wie CCTV, Spiegel, Minimap und Compute anbinden.
# Neural Rendering als groben Worker-Workload untersuchen: zuerst Datenpfad, Ressourcenbedarf und Synchronisation modellieren, danach erst den Offload implementieren.
# DLSS5-Benchmarks nach Preset, Passzahl, Scene Guides, Szene und Auflösung standardisieren; direktes <code>PassCount</code>-CVar-Verhalten vereinheitlichen.
# Scheduler und Autotuner auf GPU-Eignung und gemessene Nettokosten statt Auslastungsprozent aufbauen.
# Material-, Textur- und Culling-Pfade für realistischere Worker-Szenen ergänzen.
# Skeletal Skinning mit Bone-Matrizen und Skin Weights erst bei einem echten animierten Worker-Workload ausbauen.
# 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 ==

Der aktuelle Engine-Checkpoint <code>1fc0d24</code> trägt die Nachricht <code>Add DLSS5 NR integration and packaged shader support</code> und folgt auf <code>37c6d02</code> (<code>Extend worker capture and workload instrumentation</code>). Der Diff umfasst 29 Dateien mit 4037 Einfügungen und 281 Löschungen. Versioniert wurden gezielt relevante Source-, Build- und Plugin-Dateien; <code>Intermediate</code>, <code>Saved</code>, DDC sowie EXE-, DLL-, LIB- und PDB-Dateien und die proprietäre <code>nvngx_dlssnr.dll</code> blieben ausgeschlossen. Nach dem Commit bestanden keine ausstehenden versionierten Änderungen.

== Quellen ==

* Interner Entwicklungsstand und verifizierte Testprotokolle vom 17. September 2026; Commit <code>1fc0d24</code> auf Branch <code>mgpu-experimental</code>. Neu belegt sind cook-fähige ExperimentalMultiGPU-Global-Shader, DLSS5-NR-Integration, Packaged-Runtime, Caller-Gate-Bridge, Scene Guides, Support-Fallback und Performance-Messungen im eigentlichen Spielprojekt.
* [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/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://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://www.intel.com/content/dam/develop/external/us/en/documents/multi-adapter-support-in-directx-12-594015.pdf Intel: Multi-Adapter Support in DirectX 12]
* [https://devblogs.microsoft.com/directx/ashes-of-the-singularity-makes-gaming-history-with-directx-12/ Microsoft: Ashes of the Singularity und heterogene Adapter]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/nvidia-sli-alternative-frame-rendering-in-unreal-engine Epic: NVIDIA SLI Alternate Frame Rendering]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/multi-process-rendering-with-unreal-engine Epic: Multi-Process Rendering]
* [https://registry.khronos.org/vulkan/specs/latest/pdf/vkspec.pdf Khronos: Vulkan Specification – Device Groups]

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Multi-GPU]]
[[Kategorie:Direct3D 12]]
[[Kategorie:Experimentell]]

DLSS5ForUE5

2026-09-16T06:07:13Z

Elaina: Die Seite wurde neu angelegt: „{{Hinweis|DLSS5ForUE5 ist ein inoffizielles Community-Projekt und nicht mit NVIDIA oder Epic Games verbunden. Die Integration ist experimentell.}} '''DLSS5ForUE5''' ist ein Plugin, das NVIDIA NGX Neural Rendering in den Unreal Editor integriert. Es stellt Einstellungen, Szenendaten und Diagnosefunktionen für DLSS 5 bereit. Der Fork des Projekts wird im GitHub-Repository '''[https://github.com/jan1009/DLSS5ForUE5 jan1009/DLSS5ForUE5]''' gepflegt. == Unt…“

{{Hinweis|DLSS5ForUE5 ist ein inoffizielles Community-Projekt und nicht mit NVIDIA oder Epic Games verbunden. Die Integration ist experimentell.}}

'''DLSS5ForUE5''' ist ein Plugin, das NVIDIA NGX Neural Rendering in den Unreal Editor integriert. Es stellt Einstellungen, Szenendaten und Diagnosefunktionen für DLSS 5 bereit. Der Fork des Projekts wird im GitHub-Repository '''[https://github.com/jan1009/DLSS5ForUE5 jan1009/DLSS5ForUE5]''' gepflegt.

== Unterstützte Versionen ==

Das Repository enthält einen gemeinsamen, versionsabhängigen Quellcode für:

* Unreal Engine 5.5
* Unreal Engine 5.6
* Unreal Engine 5.7
* Unreal Engine 5.8

Getestet wurde die Integration unter Windows mit DirectX 12 und einer NVIDIA-RTX-Grafikkarte. Das offizielle NVIDIA-DLSS-Plugin muss für dieselbe Unreal-Engine-Version installiert und aktiviert sein.

== Funktionen ==

* eigenes Werkzeugfenster unter ''Tools → DLSS 5 for UE5''
* Natural- und Cinematic-Stile
* Regler für Preset, Intensität, Local Tone, Local Structure und Skin Structure
* Scene-Depth- und Motion-Vector-Guides
* zeitliche Daten wie Jitter, Pre-Exposure, Camera Cut und History Reset
* ein bis vier aufeinanderfolgende Neural-Rendering-Durchläufe
* Live-Diagnose für Laufzeit, NGX, Szenendaten und zeitlichen Zustand
* Safe Mode zur Wiederherstellung
* Konsolenbefehle unter <code>DLSS5.*</code> und <code>r.DLSS5.*</code>

== Installation ==

# Das zur verwendeten Unreal-Engine-Version passende Plugin-Paket herunterladen.
# Den Ordner <code>DLSS5ForUE5</code> nach <code>Projekt/Plugins/</code> entpacken.
# Das Projekt öffnen und die Plugins ''DLSS'' sowie ''DLSS 5 for UE5'' aktivieren.
# Den Editor neu starten.
# Das Werkzeug über ''Tools → DLSS 5 for UE5'' öffnen.

Bei einem passenden vorkompilierten Paket ist für die normale Installation keine eigene Übersetzung mit Visual Studio erforderlich.

== Verwendung und Grenzen ==

Die Anzahl der Durchläufe lässt sich von eins bis vier einstellen. Jeder weitere Durchlauf verarbeitet das Ergebnis des vorherigen Durchlaufs und erhöht die GPU-Last deutlich. Ein Durchlauf ist deshalb ein sinnvoller Ausgangspunkt.

Scene Depth und erzeugte Bewegungsvektoren können die zeitliche Stabilität verbessern. Die Verarbeitung der Motion Vectors ist jedoch weiterhin experimentell, da Unreal Engine in einigen Render-Hook-Zuständen keine direkt nutzbare Objektgeschwindigkeit liefert. Bekannte Probleme und Workarounds sind in der Repository-Dokumentation beschrieben.

== Repository und Dokumentation ==

* '''[https://github.com/jan1009/DLSS5ForUE5 Unser GitHub-Repository]'''
* [https://github.com/jan1009/DLSS5ForUE5/blob/main/docs/INSTALLATION.md Installation]
* [https://github.com/jan1009/DLSS5ForUE5/blob/main/docs/USAGE.md Verwendung]
* [https://github.com/jan1009/DLSS5ForUE5/blob/main/docs/COMMANDS.md Befehle und Konsolenvariablen]
* [https://github.com/jan1009/DLSS5ForUE5/blob/main/docs/KNOWN_ISSUES.md Bekannte Probleme]
* [https://github.com/jan1009/DLSS5ForUE5/blob/main/docs/TROUBLESHOOTING.md Fehlerbehebung]
* [https://github.com/jan1009/DLSS5ForUE5/blob/main/docs/ARCHITECTURE.md Architektur]

== Siehe auch ==

* [[Deep Learning Super Sampling]]

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Grafik]]
[[Kategorie:NVIDIA]]
[[Kategorie:Plugin]]

UE5 Heterogeneous Multi-GPU

2026-09-14T18:25:07Z

Elaina: Projektstand auf 14.09.2026 und Commit 37c6d02 aktualisiert

{{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.

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"
|+ Projektstatus
|-
! Engine / Plattform
| Unreal Engine 5.8 Source Build / Windows / Direct3D 12
|-
! Testsystem
| Lenovo LOQ 17IRX10
|-
! Primary
| NVIDIA GeForce RTX 5060 Laptop GPU
|-
! Worker
| Intel UHD Graphics
|-
! Zusätzliche Testhardware
| Intel Arc A750 und Arc A380 als zusätzliche dGPU-Worker-Gegenchecks vorgesehen; später außerdem RX 6900 XT ↔ Intel
|-
! Git-Stand
| Commit <code>37c6d02</code> auf Branch <code>mgpu-experimental</code>; vorheriger Checkpoint <code>45d5c27</code>; nicht gepusht
|-
! 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
|-
! Mess- und Workload-Schicht
| Generische Workload-Registry, Runtime Metrics V1 und echte D3D12-Timestamp-Messungen des Worker-Rasterabschnitts implementiert
|-
! Gesamtvision
| etwa 30–35 % (Kostenmodell, Scheduler, weitere echte Workloads, N-GPU und Vulkan noch offen)
|}

== Grundprinzip ==

<pre>
Intel Worker GPU
-> MainTextureCS + PatternPhase
-> persistente Worker-Textur
-> persistenter Shared Cross-Adapter Buffer
-> monotone Shared Fence / Queue Wait
-> persistente UE-eigene FTextureRHIRef
-> stabile UExperimentalMultiGPUTexture

RTX Primary GPU
-> normales UE5-Rendering
-> TPS-Material zeigt das Worker-Ergebnis sichtbar an
</pre>

Pro Worker ist maximal ein Runtime-Job gleichzeitig in flight. Backpressure lehnt weitere Requests als <code>Busy</code> ab, bis der Slot nach der Primary-Completion wieder sicher verwendbar ist.

Jeder Worker besitzt ein eigenes <code>ID3D12Device</code>, eigene Queues, Command Lists und Ressourcen. Ein späterer Scheduler soll Rechenleistung, Fähigkeiten, Transferkosten und gewünschte Aktualisierungsrate bewerten. Vorgesehene Aufgaben sind beispielsweise SceneCapture2D, Spiegel, CCTV, Minimap, Compute oder Niagara.

== Verifizierter Entwicklungsstand ==

=== Worker-Compute ===

Ein echter, von Unreal kompilierter Global Compute Shader läuft auf der Intel UHD, während Unreal regulär über die RTX rendert. Der Test verdoppelt 64 Ganzzahlen auf dem Worker; '''64 von 64 Ergebnissen wurden korrekt verifiziert'''. Damit ist echte GPU-Arbeit auf einem zweiten, herstellerfremden Device nachgewiesen.

Zusätzlich läuft <code>MainTextureCS</code> auf der Intel-GPU. Der synchrone Debugtest erzeugt eine 64 × 64 Pixel große RGBA8-Textur; '''alle 4096 shader-generierten Pixel wurden korrekt verifiziert'''. Der normale Runtime-Pfad verwendet inzwischen einen asynchronen 128×96-Test. Der Shader liest seine Dimensionen mit <code>GetDimensions()</code>, schützt überhängende Threads durch einen Bounds-Check und wird mit <code>Dispatch(16,12,1)</code> ausgeführt. <code>PatternPhase</code> erzeugt für jeden akzeptierten Submit deterministisch einen neuen sichtbaren Inhalt. Abgewiesene Busy-Requests erhöhen die Phase nicht und erzeugen daher keine Lücken.

=== Cross-Adapter-Speicher und Synchronisation ===

* RTX und Intel öffnen denselben D3D12 Cross-Adapter Heap.
* Ein gemeinsamer Buffer wurde mit 64 Testwerten erfolgreich geprüft.
* Ein persistenter Shared Fence synchronisiert die Queues direkt von GPU zu GPU. Seine Werte steigen pro Job monoton: WorkerReady/PrimaryComplete verwenden die Paare 1/2, 3/4, 5/6 und so weiter.
* Die CPU vermittelt die GPU-Abhängigkeit nicht; Worker- und Primary-Queue verwenden <code>Signal</code> und <code>Wait</code> direkt auf der GPU.
* Der separate Readback-Verifikationstest darf weiterhin blockieren. Der normale Runtime-Pfad wartet dagegen nicht auf GPU-Leerlauf.

=== Texturtransport ===

Direkte Cross-Adapter-Texturen sind auf dem Testsystem nicht beidseitig verfügbar: Die Intel UHD meldet Unterstützung für Row-Major Cross-Adapter Textures, die RTX 5060 Laptop GPU nicht. Deshalb verwendet das Projekt einen allgemeineren Buffer-Fallback.

<pre>
Intel MainTextureCS
-> persistente Worker-Textur
-> CopyTextureRegion
-> persistenter Shared Cross-Adapter Buffer
-> Worker signalisiert WorkerReady (1, 3, 5, ...)
-> UE-Primary-Queue wartet auf WorkerReady
-> direkte Kopie in persistente UE-eigene FTextureRHIRef
-> Primary signalisiert PrimaryComplete (2, 4, 6, ...)
</pre>

Der robuste Normal-Pfad kopiert die Worker-Textur über den Shared Buffer direkt in eine von Unreal erzeugte <code>FTextureRHIRef</code>. Breite, Höhe und Row Pitch werden dynamisch aus Worker-Ressource und Transport-Metadaten übernommen. Der erfolgreiche 128×96-RGBA8-Test verwendet 512 Byte Row Pitch und 49.152 Byte Transfergröße. Die Output Registry trennt Persistent-, Pending- und Ready-Zustände sowie Inhaltsgeneration und Texturidentität. Dadurch kann eine verspätete Completion keinen neueren Output zurückrollen.

=== Non-blocking Runtime-Pfad ===

Die produktive Testlogik ist aus dem Konsolenkommando in eine gekapselte NormalPath-API verschoben. <code>SubmitWorkerTextureComputeJob()</code> reicht den Worker-Dispatch ohne CPU-Wait ein. <code>QueueNormalTextureTransfer()</code> reiht Wait, Kopie und Completion-Signal in Unreals D3D12-Kontext ein. Der normale MainTextureCS-Pfad enthält weder CPU-Fence-Waits noch Readback, <code>Map</code> oder Pixelvergleich. <code>TickNormalTextureTransfers()</code> prüft die Primary-Completion non-blocking über einen Runtime-Pump; <code>RHIEndFrame()</code> bleibt als Fallback erhalten.

Eine passende Primary-<code>FTextureRHIRef</code> wird pro Worker und Konfiguration persistent gehalten. Nach PrimaryComplete kann der nächste Job dieselbe Resource erneut verwenden; dabei führt Unreal die Übergänge <code>SRVMask -> CopyDest -> SRVMask</code> aus. Eine backend-neutrale RHI-Provider-API reicht die Ready-Textur an die Engine weiter. <code>UExperimentalMultiGPUTexture</code> hält eine stabile <code>UTexture</code> samt TextureReference und bindet die persistente <code>FTextureRHIRef</code> ohne zusätzlichen Pixel-Copy. Eine native D3D12-Resource wird weiterhin nicht blind als UE-Textur gewrappt, weil Unreals Resource-State-Buchhaltung den tatsächlichen nativen Zustand sonst nicht sicher kennt.

=== Sichtbarer TPS-Consumer ===

<code>AExperimentalMultiGPUDisplayActor</code> zeigt die Worker-Ausgabe im Third-Person-Testlevel über den Materialparameter <code>MultiGPUTexture</code> an. Damit ist der Output nicht mehr nur über Logs oder Readback nachgewiesen: Die Intel UHD erzeugt fortlaufend die Texturinhalte, während die RTX die Spielwelt und das Material rendert. <code>TextureConsumerCS</code> kann Ready-Ausgaben auf der Primary zusätzlich als SRV lesen und fünf quantisierte Samples im Debugpfad prüfen.

=== Lebensdauer und automatisches Cleanup ===

Der Normal-Pfad verwendet pro Worker genau einen persistenten Runtime-Slot. Worker-Textur, Root Signature, PSO, Descriptor Heap, Command Allocator/List und Worker-Fence werden nach der ersten kompatiblen Initialisierung wiederverwendet. Dasselbe gilt für Shared Heap/Buffer/Fence und die Transport-Command-Objekte. Der In-Flight-Job trägt nur noch die nötigen Job-, Generation- und Fence-Metadaten.

<pre>
Runtime Request
-> Completion non-blocking prüfen
-> falls Slot frei: Worker Dispatch
-> WorkerReady-Fence signalisieren
-> Primary Wait, SafeCopy und PrimaryComplete-Signal
-> Output Pending
-> Runtime-Pump oder RHIEndFrame prüft GetCompletedValue()
-> Output Ready publizieren
-> Slot wiederverwendbar
</pre>

Backpressure erlaubt maximal einen echten In-Flight-Job pro Worker. Ein Busy-Request setzt keine GPU-Arbeit ab, setzt keine Ressourcen zurück und erhöht <code>PatternPhase</code> nicht. Worker-Fence-Werte steigen mit jedem akzeptierten Submit 1, 2, 3 und so weiter; der persistente Shared Fence verwendet fortlaufend die Paare 1/2, 3/4, 5/6. Fehler nach Übergabe von Ressourcen an die GPU führen zu sicherem Retire beziehungsweise Retention statt zu vorzeitigem Reuse.

=== Texture Stream und Benchmarking ===

Der projektseitige Texture Stream akzeptiert eine beliebige positive, endliche Zielrate. Punkt und Komma sind als Dezimaltrenner möglich. Optional lässt sich die Zahl erfolgreicher Submits begrenzen; Busy- oder Failed-Versuche verbrauchen dieses Limit nicht. Der Quiet-Modus unterdrückt per-Job-Ausgaben, behält aber Start, echte Fehler und die Abschlussstatistik bei.

Die Statistik unterscheidet Timer-Ticks, angenommene Submits, Busy/Failed, Ready, In-Flight und die jeweiligen effektiven Raten. Diagnosezeitpunkte erfassen unter anderem RequestAccepted, RenderCommandExecution, WorkerSubmit, NormalTransferQueued und ReadyObserved.

{| class="wikitable"
! Test
! Ergebnis
! Aussage
|-
| 5 Hz, 20 Submits
| etwa 5 Ready/s, 20/20, kein Busy
| Entspannter Single-Slot-Betrieb
|-
| 1000 Hz, 100 Submits, quiet
| 100/100 Ready, 0 Fehler, etwa 58 Ready/s
| Backpressure begrenzt den Durchsatz sicher
|-
| 1000 Hz bei <code>t.MaxFPS 30</code>
| etwa 28–29 Ready/s trotz rund 982 Timer-Ticks/s
| Primary-/SafeCopy-/Ready-Kette ist effektiv framegekoppelt
|}

Ein zusätzlicher non-blocking Aufruf von <code>ImmediateFlush(DispatchToRHIThread)</code> erreicht hohe Render-Command-Raten, hebt die gemessene Frame-Kopplung aber nicht auf. Im 30-FPS-Test lag der RHIEndFrame-spezifische Completion-Takt praktisch exakt bei 30 Hz. Das aktuelle Problem ist damit eingegrenzt: Nicht der Stream-Timer, sondern die Primary-RHI-/D3D12-Submission der SafeCopy-Kette bestimmt die sichtbare Ready-Rate.

=== Queue-Submission-Diagnose ===

<code>MultiGPUD3D12QueueProbe</code> untersucht die Submission unabhängig vom sichtbaren Texturpfad. Neben <code>full</code>, <code>waitonly</code> und <code>signalonly</code> existieren inzwischen die Diagnosemodi <code>computeonly</code>, <code>commandonly</code>, <code>barrieronly</code>, <code>barrierprivate</code> und <code>copybuffer</code>. Als Queues stehen <code>graphics</code>, <code>copy</code>, <code>native</code>, <code>worker</code>, <code>worker-copy</code> und <code>worker-high</code> zur Verfügung. Graphics und Copy verwenden <code>RHIRunOnQueue(..., false)</code> auf UE-verwalteten Primary-Queues; die übrigen Varianten isolieren private beziehungsweise bereits vorhandene native D3D12-Queues.

Der Probe misst Request, Worker-Submit, <code>RHIRunOnQueue</code>-Aufruf und -Callback, Primary-Execute, Fence-Completion sowie Ready bis zum nächsten akzeptierten Submit. Er fügt keine CPU-Waits, Readbacks, Maps oder <code>BlockUntilGPUIdle</code> ein und beschreibt keine Textur des sichtbaren Normal-Pfads.

{| class="wikitable"
! Test
! Ergebnis
! Befund
|-
| UE Graphics, signal-only, 30 FPS
| 33,319 ms PrimaryExecute bis Ready
| UE-verwaltete Graphics-Submission skaliert mit der Frame-Dauer
|-
| UE Copy, signal-only, 30 FPS
| 32,593 ms PrimaryExecute bis Ready
| Auch die UE-verwaltete Copy Queue ist framegekoppelt
|-
| Private Primary-DIRECT-Queue, signal-only
| etwa 0,014 ms Queue/Fence-Latenz; nach Lifecycle-Fix rund 999 Ready/s bei 30 FPS
| Native Queue und Scheduler sind vollständig vom Frame entkoppelt
|-
| Worker signal-only / leere Command List
| jeweils rund 1000 Ready/s bei 30 FPS
| Worker-Queue, Fence und reine Submission sind nicht framegekoppelt
|-
| Worker <code>CopyBufferRegion</code>, 30 / 60 / 120 FPS
| 29,41 / 58,25 / 113,08 Ready/s
| Bereits eine echte 256-Byte-GPU-Kopie folgt im UE-Prozess dem Frame-Raster
|-
| Worker COPY Queue / HIGH Priority, 30 FPS
| jeweils rund 29,42 Ready/s
| Queue-Typ und Priorität beseitigen die Kopplung nicht
|-
| Standalone-D3D12 auf derselben Intel UHD
| 92.956 Copy-Jobs/s; 0,007 ms durchschnittliche Fence-Latenz
| Die Kopplung ist UE-Prozess-/Scheduling-spezifisch, keine allgemeine Intel-, WDDM- oder D3D12-Grenze
|}

Der <code>RHIRunOnQueue</code>-Callback selbst erreicht den D3D12-Submission-Thread typischerweise bereits nach etwa 0,02–0,05 ms; die Verzögerung entsteht danach in der verwalteten Queue-/Submission-Reihenfolge. <code>SubmitCommandsHint()</code> ist in UE 5.8 nur ein veralteter Alias für <code>ImmediateFlush(DispatchToRHIThread)</code> und stellt daher keinen stärkeren Submission-Mechanismus dar.

Der native Test ist ein '''Architekturbeweis, noch kein Experimental- oder Direct-Modus'''. Die zunächst gemessene Verzögerung von rund 32 ms lag zwischen der In-Flight-Freigabe und dem nächsten Request auf dem Render Thread. Für <code>signalonly/native</code> wurde der sichere Completion-/Submit-Lifecycle deshalb in den frameunabhängigen Scheduler verlegt. Danach erreichten zwei 100-Job-Läufe bei <code>t.MaxFPS 30</code> rund 999 bis 1029 Ready/s, ohne Busy oder Fehler.

Der anschließende <code>full native</code>-Test lokalisierte die verbleibende Kopplung auf echte Worker-GPU-Arbeit: WorkerSubmit bis WorkerReady benötigte bei 30, 60 und 120 FPS ungefähr 33,29, 16,93 und 8,45 ms; WorkerReady bis PrimaryReady war danach praktisch sofort. Signal-only und eine leere Command List waren schnell, Resource Barriers und eine 256-Byte-Kopie dagegen framegebunden. Ein eigenständiger D3D12-Microbenchmark auf derselben Intel UHD erreichte außerhalb von Unreal bei derselben Kopie rund 92.956 Jobs/s mit 0,007 ms mittlerer Fence-Latenz. Die genaue Ursache im UE-Prozess beziehungsweise dessen GPU-Scheduling-Kontext bleibt offen und wird vorerst bis zum Gegencheck mit der vorhandenen Intel Arc A380 geparkt.

=== Worker-Rasterpfad und RasterStream ===

<code>ExperimentalMultiGPU.TestRasterWorker</code> weist erstmals echte Rasterizer-Arbeit auf der Intel-Worker-GPU nach. <code>RasterWorkerVS</code> und <code>RasterWorkerPS</code> werden über Unreals Global-Shader-Pfad kompiliert und für ein natives Worker-Graphics-PSO verwendet. Ein persistentes 128×96-RGBA8-RenderTarget besitzt RTV, leere Root Signature und eine DIRECT-Command-List. Der Vertex Shader erzeugt drei Vertices über <code>SV_VertexID</code>; der Pixel Shader schreibt interpolierte RGB-Farben.

Der Job wechselt das RenderTarget von <code>COPY_SOURCE</code> nach <code>RENDER_TARGET</code>, führt Clear und <code>DrawInstanced(3,1,0,0)</code> aus und wechselt anschließend zurück nach <code>COPY_SOURCE</code>. Danach verwendet er unverändert den robusten Normalpfad aus Cross-Adapter-Shared-Buffer, Primary SafeCopy, persistenter <code>FTextureRHIRef</code>, <code>UExperimentalMultiGPUTexture</code> und DisplayActor. Der Runtime-Test meldete einen akzeptierten Submit und <code>RasterWorker READY</code> für Generation 1; die 128×96-UTexture wurde erfolgreich gebunden.

Der einmalige Test wurde außerdem zu einem frei konfigurierbaren RasterStream ausgebaut. Ein sichtbarer Lauf mit 10 Hz und 50 erfolgreichen Submits endete mit 50 Ready-Ausgaben, 0 Busy und 0 Fehlern bei etwa 9,90 Ready/s. Primary-Textur und Materialbindung blieben dabei persistent.

=== Raster3D mit echten Vertex- und Indexbuffern ===

Der Worker besitzt inzwischen einen kleinen eigenständigen 3D-Rasterpfad mit perspektivischer Kamera, Model-View-Projection-Matrix als Root Constants, D32_FLOAT-Depth-Buffer und Depth-Test. Der finale Testwürfel verwendet 24 POSITION/COLOR-Vertices, 36 <code>uint16</code>-Indices und <code>DrawIndexedInstanced(36,1,0,0,0)</code>; sechs getrennte Seitenfarben machen Ausrichtung und Rotation sichtbar nachvollziehbar.

Die statischen Meshdaten werden einmalig über private Upload-Buffer in DEFAULT-Heaps übertragen. Der Init-Fence wird non-blocking über <code>GetCompletedValue()</code> beobachtet. Der eigentliche Runtime-Renderpfad enthält weiterhin keine CPU-Waits und keine Maps.

=== UE-Static-Meshes auf der Worker-GPU ===

<code>StaticMeshWorker</code> extrahiert echte LOD0-Geometrie aus <code>UStaticMesh</code>-Assets. POSITION und NORMAL sowie <code>uint32</code>-Indices werden in POD-Daten überführt, einmalig asynchron in eigene Worker-VB/IB hochgeladen und anschließend per <code>DrawIndexedInstanced</code> gerendert. Assetpfade sind dynamisch; Auto-Fit richtet Kamera beziehungsweise Modellmaßstab an den Bounds aus.

Sichtbar korrekt getestet wurden:

{| class="wikitable"
! Asset
! Vertices
! Indices
|-
| Sphere
| 559
| 2880
|-
| Cube
| 54
| 144
|-
| Cylinder
| 334
| 1536
|}

=== Multi-Mesh Worker-Szene ===

<code>StaticMeshScene</code> rendert Sphere, Cube und Cylinder gemeinsam in einen Color-/Depth-Frame. Der verifizierte Test umfasst insgesamt 947 Vertices und 4560 Indices, drei <code>DrawIndexedInstanced</code>-Aufrufe und nur einen anschließenden Cross-Adapter-/Normal-SafeCopy-Transfer. Damit ist nicht mehr nur ein synthetisches Primitive, sondern mehrere echte UE-Meshes mit gemeinsamer Tiefenprüfung im Worker-Frame sichtbar nachgewiesen.

=== WorldStaticMeshScene ===

<code>ExperimentalMultiGPUWorldStaticMeshScene.cpp</code> sammelt im Engine-Layer bis zu acht sichtbare <code>UStaticMeshComponent</code>s von Actors mit dem Tag <code>MultiGPUWorker</code>. Meshdaten und World-Transforms werden im Game Thread in reine POD-Strukturen und 4×4-Matrizen kopiert. D3D12RHI erhält keine <code>UObject</code>-Pointer. Mehrere Instanzen desselben Meshes teilen den persistenten Worker-Mesh-Cache und unterscheiden sich nur durch Modelmatrix und Draw Call.

Der Pfad wurde inzwischen sichtbar im PIE-Level verifiziert. Drei getaggte Static-Mesh-Actors erschienen mit ihren tatsächlichen relativen Positionen, Rotationen und Skalierungen im Worker-Bild. Die zentrale Koordinatenumrechnung lautet:

<pre>Worker (X, Y, Z) = (UE Y, UE X, -UE Z)</pre>

Die Transformation besitzt die Determinante +1 und ist damit keine Spiegelung. Das notwendige horizontale Spiegeln erfolgt ausschließlich auf der Presentation-Plane, nicht im Worker-Renderpfad.

=== Kontinuierlicher WorldStaticMeshSceneStream ===

<code>StartWorldStaticMeshSceneStream</code> erfasst die getaggte Szene fortlaufend im Game Thread. Reine Änderungen an Transform oder Kamera lösen keinen erneuten Mesh-Upload aus. Hinzugekommene, entfernte, unsichtbare oder umgetaggte Components werden im nächsten Snapshot berücksichtigt. Single-Slot-Backpressure verhindert einen wachsenden Rückstau.

Ein verifizierter 30-Hz-Lauf endete nach 31,184 Sekunden mit 835 Ticks, 691 angenommenen Submits, 144 Busy, 0 Fehlern und 691 Ready-Frames. Die effektive Ready-Rate betrug 22,16 Hz. Dieser Test belegt die funktionale Live-Aktualisierung; die Rate war noch kein Optimierungsziel.

=== SceneCapture2D als Worker-Kamera ===

<code>TestSceneCaptureStaticMeshScene</code> verwendet eine echte <code>ASceneCapture2D</code> beziehungsweise <code>USceneCaptureComponent2D</code> aus der laufenden PIE-Welt als Kameraquelle. Der empfohlene Editor-Weg ist das Component Tag <code>MultiGPUWorkerCamera</code> auf der <code>CaptureComponent2D</code>; ein gleichnamiges Actor-Tag bleibt nur als Legacy-Fallback.

Ausgelesen werden World Location, Rotation, Forward/Right/Up, <code>FOVAngle</code> und <code>ProjectionType</code>. Orthografische Projektion wird derzeit sauber abgelehnt. Die SceneCapture2D liefert ausschließlich Kameradaten: Ihr UE-RenderTarget wird weder gelesen noch kopiert. Die Intel-Worker-GPU rendert die Geometrie selbst. Kamera und Actors werden gemeinsam mit <code>SceneScale = 0.01</code> in Worker-Koordinaten überführt; Auto-Fit und Scene-Recentering sind in diesem Modus deaktiviert.

Die 128×96-Worker-Projektion verwendet ein Seitenverhältnis von 4:3 und interpretiert <code>FOVAngle</code> als horizontales FOV. Nach den Orientierungstests wird nur die Anzeige über <code>SetRelativeScale3D(FVector(-4.0f, -3.0f, 1.0f))</code> korrigiert; dies entspricht <code>U' = 1-U</code> und <code>V' = 1-V</code>.

=== Live SceneCaptureStaticMeshSceneStream ===

<code>StartSceneCaptureStaticMeshSceneStream</code> liest Kamera-Transform, Kamerabasis, FOV und aktuelle Actor-Transforms pro Snapshot neu im Game Thread. Der Worker erhält weiterhin ausschließlich POD-Daten, verwendet den persistenten Mesh-Cache sowie ein gemeinsames Color- und D32-Depth-Target und führt pro akzeptiertem Frame genau einen Cross-Adapter-/Normal-SafeCopy-Transfer aus.

Der Quiet-Test

<pre>ExperimentalMultiGPU.StartSceneCaptureStaticMeshSceneStream 30 300 quiet</pre>

lieferte in 10,084 Sekunden 301 Ticks, 300 Submits, 1 Busy, 0 Fehler und 300 Ready-Frames. Die effektive Ready-Rate betrug 29,75 Hz. Bewegungen der Kamera und Actors sowie FOV-Änderungen erschienen live auf der Display-Plane. Damit ist erstmals ein kleiner SceneCapture-/CCTV-artiger Worker-Kanal vollständig funktional nachgewiesen.

=== Dynamische SceneCapture-Auflösung ===

Die SceneCapture-Ausgabe ist nicht mehr fest auf 128×96 Pixel begrenzt. <code>ExperimentalMultiGPU.SetSceneCaptureResolution <Width> <Height></code> setzt ganzzahlige Dimensionen von 1 bis 4096; <code>GetSceneCaptureResolution</code> zeigt die aktive Einstellung. 128×96 bleibt der Standard. Während ein SceneCapture-Stream läuft, wird ein Auflösungswechsel absichtlich abgelehnt, damit keine In-Flight-Ressourcen ausgetauscht werden.

Color Target, D32-Depth-Buffer, Row Pitch, Shared-Buffer-Transport, SafeCopy, persistente Primary-Textur und <code>UExperimentalMultiGPUTexture</code> übernehmen die gewählten Dimensionen. Projektion und Display-Plane verwenden das echte Seitenverhältnis. Die bestätigte Anzeigeorientierung <code>U' = 1-U</code> und <code>V' = 1-V</code> bleibt eine reine Presentation-Korrektur; Worker-Basis und Kameramathematik ändern sich nicht.

=== Scheduler-Korrektur bei SceneCapture ===

Ein 1920×1080-Test mit 25 Hz erreichte zunächst trotz fehlerfreier Frames nur 13,90 Ready-Hz und erzeugte 222 Busy-Ticks. Ursache war kein GPU-Limit, sondern ein Polling-Aliasing: Eine frühe Game-Thread-Prüfung konnte den Timer-Slot verwerfen, obwohl die Completion kurz darauf im CoreTicker/RHI-Pump sichtbar geworden wäre.

Die frühe <code>IsRuntimeTextureUpdateInFlight()</code>-Prüfung wurde für diesen Stream entfernt. Der Pending-Request bleibt als Backpressure-Gate erhalten; die maßgebliche Busy-Entscheidung fällt nun erst im Render Command nach <code>TickNormalTextureTransfers(nullptr, true)</code>. Single-Slot, POD-Snapshots und non-blocking <code>GetCompletedValue()</code> bleiben erhalten. Es wurden weder CPU-Waits noch zusätzliche Threads eingeführt.

Nach der Korrektur erreicht 1080p bei 25 Hz 24,79 Ready-Hz mit 1 Busy; bei 30 Hz sind es 29,43 Ready-Hz mit 4 Busy.

=== Skalierung bis 4K60 ===

Die Pipeline wurde von 640×360 bis 3840×2160 getestet. Bei 640×360/30 Hz und 1280×720/30 Hz wurden 29,85 beziehungsweise 29,82 Ready-Hz ohne Busy erreicht. 1920×1080/60 Hz lieferte 59,40 Ready-Hz ohne Busy, 2560×1440/60 Hz 59,21 Ready-Hz mit 1 Busy und 3840×2160/60 Hz 59,02 Ready-Hz mit 2 Busy.

Ein zusätzlicher 4K60-Stresstest mit acht Static-Mesh-Instanzen und drei gecachten Unique Meshes erreichte in 5,049 Sekunden '''300 von 300 Ready-Frames, 0 Busy, 0 Fehler und 59,42 effektive Ready-Hz'''. Acht Draw Calls, gemeinsamer Depth Buffer, Cross-Adapter-Transport und SafeCopy liefen dabei im vorhandenen Single-Slot. Das ist ein Stabilitätsnachweis der aktuellen Mini-Szene, kein allgemeiner GPU-Benchmark.

=== Skeletal Mesh in Reference Pose ===

<code>ExperimentalMultiGPU.TestSkeletalMeshWorker</code> erweitert den Geometriepfad auf <code>USkeletalMeshComponent</code>. Der Engine-Layer sucht deterministisch die erste sichtbare, getaggte Komponente und extrahiert LOD0-Positionen, Normalen, Indices und Render Sections. D3D12RHI erhält wie bisher ausschließlich POD-Geometrie und Modelmatrizen.

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. Skeletal Skinning ist erst vorgesehen, wenn ein echter Worker-Workload wie CCTV oder Spiegel animierte Figuren in seiner eigenen Ansicht benötigt.

=== Generische Workload-Registry ===

Commit <code>37c6d02</code> führt erstmals eine backend-neutrale Workload-Schicht ein. Sie beschreibt Aufgaben unabhängig vom konkreten Grafik-Backend und bildet die Grundlage für einen späteren Scheduler, trifft selbst aber noch keine GPU-Entscheidung.

{| class="wikitable"
! Bestandteil
! Inhalt
|-
| Workload-Typ
| <code>Unknown</code>, <code>SceneCapture</code>, <code>Compute</code> oder <code>Raster</code>
|-
| Gewünschte Zuweisung
| <code>Primary</code>, <code>Worker</code> oder <code>Auto</code>; <code>Auto</code> ist derzeit nur Metadatum
|-
| Priorität
| <code>Low</code>, <code>Normal</code> oder <code>High</code>
|-
| Descriptor
| Sessionweit monotone ID, Typ, Zuweisung, Priorität, Auflösung, Zielrate, Debugname und Running-Status
|}

Die Registry stellt <code>RegisterWorkload</code>, <code>UpdateWorkload</code>, <code>UnregisterWorkload</code>, <code>GetWorkload</code> und <code>GetActiveWorkloads</code> bereit und schützt ihre Daten per <code>FCriticalSection</code>. Descriptoren enthalten weder <code>UObject</code>- noch D3D12-Pointer. Der SceneCapture-Stream registriert genau einen Worker-Workload mit normaler Priorität und entfernt ihn bei Stop oder Auto-Stop wieder vollständig.

<code>ExperimentalMultiGPU.ListWorkloads</code> zeigt die aktiven Descriptoren und ihre Laufzeitwerte an.

=== Runtime Metrics V1 ===

Descriptor und Laufzeitstatistik sind getrennt. Pro Workload werden Ticks, angenommene Submits, Busy- und Fehlerfälle, fertige Frames, aktuell ausstehende Jobs, Laufzeit sowie effektive Tick-, Submit- und Ready-Raten erfasst. Der SceneCapture-Pfad spiegelt dafür seine vorhandenen Stream-Zähler in die Registry, statt eine zweite Statistiklogik aufzubauen. Die Messwerte werden derzeit nur beobachtet und ändern weder Zuweisung noch Auflösung oder Zielrate.

Editor-Fokus und Background-Throttling können die Lifecycle-Raten deutlich verfälschen. In einem sauberen 1280×720-Referenzlauf wurden 1000/1000 Ready-Frames ohne Busy bei 29,84 Ready-Hz gemessen; bei wechselndem Fensterfokus entstanden dagegen 459 Busy-Ticks und nur 16,69 Ready-Hz, ohne dass die Worker-GPU-Zeit entsprechend einbrach. Solche Raten sind daher kein verlässlicher Ersatz für echte GPU-Kostenmessungen.

=== Worker GPU Timing V1 ===

Der SceneCapture-Worker verwendet persistente native D3D12-Timestamp-Queries auf seiner vorhandenen DIRECT-Queue: einen Query Heap mit zwei Slots, einen kleinen Readback-Buffer und die per <code>GetTimestampFrequency()</code> ermittelte Zeitbasis. Das Ergebnis wird erst nach non-blocking geprüftem Fence-Abschluss gelesen; CPU-Waits entstehen nicht. Die Workload-ID wird als POD bis zum Worker mitgeführt, während einmalige Tests die ID 0 verwenden.

Gemessen wird ausschließlich der Worker-Rasterabschnitt:

<pre>
Start Timestamp
-> COPY_SOURCE nach RENDER_TARGET
-> Color- und Depth-Clear
-> alle DrawIndexedInstanced-Aufrufe
-> RENDER_TARGET nach COPY_SOURCE
End Timestamp
-> ResolveQueryData
</pre>

Nicht enthalten sind der Cross-Adapter-Transfer, die Primary-SafeCopy und die Integration auf der Primary-GPU. Erfasst werden Sample-Anzahl sowie letzter, mittlerer, minimaler und maximaler Messwert.

{| class="wikitable"
! Auflösung
! Samples
! Mittelwert
! Minimum
! Maximum
|-
| 1280×720
| 845
| 0,166 ms
| 0,165 ms
| 0,181 ms
|-
| 3840×2160
| 599
| 0,683 ms
| 0,594 ms
| 0,751 ms
|}

Bei identischem, bewusst einfachem Szeneninhalt mit sieben Draw Calls steigt die gemessene Worker-Rasterzeit damit ungefähr um Faktor 4,1. Die Pixelzahl allein erklärt die Skalierung nicht vollständig. Für ein belastbares Kostenmodell müssen als Nächstes Transfer und Primary-Integration separat gemessen werden.

== Test- und Diagnosebefehle ==

Die vorhandenen Compute-, Texture-, Raster-, StaticMesh-, World- und QueueProbe-Kommandos bleiben bestehen. Neu hinzugekommen ist:

{| class="wikitable"
! Befehl
! Zweck
|-
| <code>ExperimentalMultiGPU.ListWorkloads</code>
| Listet aktive Workloads mit ID, Typ, gewünschter Zuweisung, Priorität, Auflösung, Zielrate, Lifecycle-Statistik und Worker-GPU-Timing auf.
|}

Für den aktuellen Hauptpfad sind außerdem besonders relevant:

<pre>
ExperimentalMultiGPU.SetSceneCaptureResolution <Width> <Height>
ExperimentalMultiGPU.GetSceneCaptureResolution
ExperimentalMultiGPU.TestSceneCaptureStaticMeshScene
ExperimentalMultiGPU.StartSceneCaptureStaticMeshSceneStream [Hz] [MaxSuccessfulSubmits] [quiet]
ExperimentalMultiGPU.StopSceneCaptureStaticMeshSceneStream
ExperimentalMultiGPU.TestSkeletalMeshWorker
ExperimentalMultiGPU.ListWorkloads
</pre>

=== Texture Stream ===

Grundsyntax:

<pre>ExperimentalMultiGPU.StartTextureStream [Hz] [MaxSuccessfulSubmits] [quiet]</pre>

Die Hz-Angabe ist eine Ziel- beziehungsweise Request-Frequenz. <code>MaxSuccessfulSubmits</code> zählt nur angenommene Submits; Busy- und Failed-Versuche verbrauchen das Limit nicht. <code>quiet</code> unterdrückt Per-Job- und Busy-Logspam.

=== QueueProbe ===

Grundsyntax:

<pre>ExperimentalMultiGPU.StartQueueProbe <Hz> <MaxSubmits> [quiet] <Mode> <Queue></pre>

Die Diagnosemodi <code>full</code>, <code>waitonly</code>, <code>signalonly</code>, <code>commandonly</code>, <code>barrieronly</code>, <code>barrierprivate</code> und <code>copybuffer</code> bleiben verfügbar. Als Queue können <code>graphics</code>, <code>copy</code>, <code>native</code>, <code>worker</code>, <code>worker-copy</code> und <code>worker-high</code> gewählt werden. Private native Queues dienen weiterhin nur der Diagnose und bilden keinen fertigen Experimental-/Direct-Modus.

=== Benchmark-CVars ===

<code>r.VSync 0</code> deaktiviert VSync. <code>t.MaxFPS 30</code>, <code>60</code> oder <code>120</code> erzeugt reproduzierbare Frame-Coupling-Tests; <code>t.MaxFPS 0</code> entfernt das normale Framerate-Limit.

== Aktueller nächster Schritt ==

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 ==

Die Grundidee heterogener Multi-GPU-Nutzung ist nicht neu. Bereits mit der Einführung von Direct3D 12 entstanden mehrere Versuche, integrierte und dedizierte GPUs gemeinsam zu verwenden. Eine allgemein einsetzbare Lösung für moderne UE5-Spiele hat sich daraus jedoch nicht entwickelt.

=== Microsoft und Epic: UE4 Elemental Demo (2015) ===

Microsoft zeigte eine angepasste Unreal-Engine-4-Version der Elemental-Demo, bei der eine NVIDIA-GPU und eine Intel-iGPU gemeinsam arbeiteten. Das erklärte Ziel war, ansonsten ungenutzte Grafikleistung in Hybrid-Systemen zu verwenden. Dieser Versuch ist der Grundidee des Projekts besonders ähnlich, blieb aber eine technische Demonstration.

=== Intel: D3D12 Multi-Adapter Sample (2015) ===

Intels Beispiel kombinierte eine GeForce 840M mit Intel HD Graphics 5500. Beide GPUs berechneten getrennte Teile einer einfach parallelisierbaren Raytracing-Szene. Cross-Adapter-Ressourcen und Shared Fences führten die Ergebnisse anschließend zusammen. Intel berichtete in diesem Test von nahezu halbierter Framezeit, warnte jedoch ausdrücklich davor, das Ergebnis unmittelbar auf reale Spiele zu übertragen.

=== Ashes of the Singularity ===

Die Nitrous Engine von ''Ashes of the Singularity'' setzte Direct3D-12-Explicit-Multiadapter in einem veröffentlichten Spiel ein. Dabei konnten auch unterschiedliche GPU-Modelle und Hersteller zusammenarbeiten. Das war ein wichtiger Praxisnachweis, blieb in der Spielebranche aber eine seltene Ausnahme.

=== Weitere verwandte Ansätze ===

* ''Rise of the Tomb Raider'' erhielt explizite Direct3D-12-Multi-GPU-Unterstützung, vor allem für klassische Kombinationen ähnlicher GPUs.
* NVIDIA VR SLI wies bei Virtual Reality jeder GPU ein Auge zu. Das verteilt unabhängige Ansichten, bleibt jedoch NVIDIA-spezifisch.
* Unreal nDisplay kann Viewports oder Frustums auf weitere GPUs beziehungsweise Prozesse auslagern und das fertige Bild zur Ausgabe-GPU zurückführen. Der Einsatzbereich ist hauptsächlich Virtual Production.
* Forschung und High-Performance Computing verwenden seit Jahren Scheduler für heterogene GPUs, allerdings überwiegend für Compute- und Datenverarbeitungsaufgaben statt für einen allgemeinen UE5-Echtzeitrenderer.

=== Abgrenzung dieses Projekts ===

Das Projekt erfindet Direct3D-12-Explicit-Multiadapter nicht neu. Sein eigener Ansatz liegt in der Kombination aus tiefer UE5.8-RHI-Integration, UE-kompilierten Shadern auf unabhängigen Worker-Devices, frei wählbaren Spiel- und Compute-Workloads, Capability- und Performance-Scheduler, mehreren Fallback-Pfaden sowie dem langfristigen Ziel beliebiger Hersteller und mehrerer Worker.

== Vergleich mit anderen Multi-GPU-Verfahren ==

{| class="wikitable"
! Verfahren
! Arbeitsweise
! Verhältnis zu diesem Projekt
|-
| SLI / CrossFire
| Treiber- beziehungsweise Verbundlösung für meist ähnliche GPUs; häufig wird die Bildarbeit verteilt.
| Dieses Projekt benötigt keinen herstellerspezifischen GPU-Verbund und weist Aufgaben ausdrücklich selbst zu.
|-
| AFR (Alternate Frame Rendering)
| GPU 1 rendert einen Frame, GPU 2 den nächsten.
| Das Projekt verteilt unabhängige Aufgaben statt aufeinanderfolgender Frames. Dadurch werden Frame-Abhängigkeiten und typisches AFR-Pacing vermieden.
|-
| SFR (Split Frame Rendering)
| Mehrere GPUs bearbeiten Bereiche desselben Frames.
| Erfordert enge Lastverteilung und viel Datenaustausch. Das Projekt bevorzugt vollständig abgrenzbare Workloads und überträgt deren Ergebnis.
|-
| Direct3D 12 Linked Multiadapter
| Mehrere vom Treiber verbundene GPUs erscheinen als Knoten eines logischen Adapters.
| Eignet sich eher für eng kompatible GPUs. Das Projekt verwendet unabhängige Devices (Unlinked/Explicit Multiadapter) und unterstützt dadurch heterogene Herstellerkombinationen.
|-
| Direct3D 12 Unlinked / Explicit Multiadapter
| Die Anwendung verwaltet getrennte Adapter, Ressourcen und Synchronisation selbst.
| Das ist die technische Familie des Projekts. Hinzu kommen die eigene UE5-RHI-Integration, Workload-Ziele, Fallbacks und der geplante Scheduler.
|-
| UE nDisplay mGPU / Multi-Process
| Separate GPUs rendern bestimmte Viewports oder Frustums, vor allem für Virtual Production; Ergebnisse werden zur Ausgabe-GPU kopiert.
| Ähnliche Idee der aufgabenweisen Trennung, aber für einen anderen Einsatzbereich. Dieses Projekt zielt auf allgemeine Spiel- und Compute-Workloads innerhalb der Engine.
|-
| Vulkan Device Groups
| Ähnliche physische GPUs können ein gemeinsames logisches Device bilden.
| Für beliebige heterogene GPUs meist ungeeignet, da Geräte einer Gruppe nahezu gleiche Eigenschaften besitzen müssen. Eine spätere Vulkan-Portierung benötigt daher wahrscheinlich getrennte Devices und External Memory/Semaphores.
|}

SLI und CrossFire bezeichnen den Verbund; AFR und SFR beschreiben mögliche Verteilungsmethoden innerhalb solcher Systeme. Sie sind deshalb nicht vollständig getrennte Kategorien.

== Vorteile der geplanten Variante ==

* '''Herstellerunabhängig:''' NVIDIA, AMD und Intel können grundsätzlich kombiniert werden.
* '''Vorhandene Hardware nutzen:''' Auch eine sonst wenig genutzte integrierte GPU kann geeignete Nebenaufgaben übernehmen.
* '''Aufgaben statt Frames verteilen:''' Spiegel, Minimap oder Compute können mit eigener Auflösung und Aktualisierungsrate laufen.
* '''Keine identischen GPUs erforderlich:''' Unterschiedliche Fähigkeiten können gezielt genutzt werden.
* '''Kontrollierter Datenaustausch:''' Nur das benötigte Ergebnis muss zurück zur Primary-GPU.
* '''Robuste Fallback-Idee:''' Wenn direkte Texturen nicht gemeinsam nutzbar sind, bleibt der Shared-Buffer-Pfad.
* '''Erweiterbar:''' Scheduler, manuelles Mapping und mehrere Worker sind als spätere Stufen vorgesehen.

== Nachteile und technische Risiken ==

* '''Hoher Entwicklungsaufwand:''' Geräte, Ressourcen, Zustände, Fences, Fehlerfälle und UE-Lebenszyklen müssen selbst verwaltet werden.
* '''Transfer kann den Gewinn aufzehren:''' Cross-Adapter Heaps liegen laut D3D12 nicht automatisch im schnellen lokalen VRAM. Bandbreite und Latenz müssen für jeden Workload gemessen werden.
* '''VRAM wird nicht einfach addiert:''' Benötigte Ressourcen können auf mehreren GPUs vorliegen und zusätzlichen Speicher verbrauchen.
* '''Langsame Worker können bremsen:''' Eine Aufgabe lohnt sich nur, wenn Rechengewinn größer als Übergabe-, Warte- und Kopierkosten ist.
* '''Nicht jeder Workload ist unabhängig:''' Hauptansicht, Lumen, Nanite und stark gekoppelte Renderpässe besitzen viele Abhängigkeiten und sind schwieriger auszulagern.
* '''Hardwareunterschiede:''' Formate, Shader-Funktionen, Queue-Fähigkeiten und Cross-Adapter-Support müssen pro GPU geprüft werden.
* '''Wartungsrisiko:''' Eingriffe in private D3D12RHI-Dateien können bei Engine-Updates angepasst werden müssen.
* '''Produktionsreife fehlt noch:''' Ressourcenpools, Timeouts, Device-Lost-Wiederherstellung, Scheduler und echte Szenentests sind offen.

== Wann die Variante sinnvoll ist ==

Am aussichtsreichsten sind Aufgaben mit viel eigener Rechenarbeit, einem relativ kleinen Endergebnis und wenigen Abhängigkeiten zur Hauptszene. Gute frühe Kandidaten sind unabhängige Compute-Aufgaben sowie Scene Captures, die nicht in jedem Frame aktualisiert werden müssen. Weniger geeignet sind winzige Aufgaben mit großem Transfer oder Renderpässe, die ständig auf Ressourcen der Primary-GPU zugreifen.

Die entscheidende Regel für den späteren Scheduler lautet daher:

<pre>
Worker-Gewinn > Vorbereitung + Datentransfer + Synchronisation + Rückintegration
</pre>

== Bekannte Grenzen des Proof of Concepts ==

* 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 sichtbarer Runtime-Slot. Mehrere parallele In-Flight-Jobs und Ringbuffer fehlen noch.
* Praktisch getestet ist Primary plus ein Worker. Mehrere Worker sind architektonisch vorgesehen, aber noch nicht praktisch validiert.
* World- und SceneCapture-Pfade verarbeiten pro Snapshot höchstens acht sichtbare <code>UStaticMeshComponent</code>s.
* 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.
* <code>USkeletalMesh</code> ist bislang ein LOD0-ReferencePose-Proof. Bone-Skinning, Animation, Morph Targets und Cloth fehlen.
* Die Workload-Registry sammelt Metadaten und Messwerte, führt aber noch keine automatische Zuweisung, Auflösungsänderung oder Ratenanpassung aus.
* Worker GPU Timing V1 misst nur den Rasterabschnitt. Cross-Adapter-Transfer und Primary-SafeCopy fehlen noch im Kostenmodell.
* 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.
* QueueProbe und private native Queues bleiben Diagnosepfade; Experimental/Direct ist noch nicht implementiert.
* 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.
* Linux/Vulkan mit getrennten Devices, External Memory und externer Synchronisation ist noch nicht implementiert.

== Roadmap ==

# Cross-Adapter Transfer Timing V1: Worker-ColorTarget → Shared Buffer separat messen.
# Primary SafeCopy Timing ergänzen und die Integrationskosten getrennt halten.
# Kostenmodell V1 aus Worker-Raster, Transfer und Primary-Integration pro Workload ableiten.
# Weitere echte Workload-Klassen wie CCTV, Spiegel, Minimap und Compute anbinden; später Post Process oder neuronale Aufgaben untersuchen.
# D3D12-Pfade mit Intel Arc A750/A380 und RX 6900 XT in unterschiedlichen Primary-/Worker-Rollen gegenprüfen.
# Scheduler und Autotuner auf GPU-Eignung und gemessene Nettokosten statt Auslastungsprozent aufbauen.
# Material-, Textur- und Culling-Pfade für realistischere Worker-Szenen ergänzen.
# Skeletal Skinning mit Bone-Matrizen und Skin Weights erst bei einem echten animierten Worker-Workload ausbauen.
# 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 ==

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 ==

* 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/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://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://www.intel.com/content/dam/develop/external/us/en/documents/multi-adapter-support-in-directx-12-594015.pdf Intel: Multi-Adapter Support in DirectX 12]
* [https://devblogs.microsoft.com/directx/ashes-of-the-singularity-makes-gaming-history-with-directx-12/ Microsoft: Ashes of the Singularity und heterogene Adapter]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/nvidia-sli-alternative-frame-rendering-in-unreal-engine Epic: NVIDIA SLI Alternate Frame Rendering]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/multi-process-rendering-with-unreal-engine Epic: Multi-Process Rendering]
* [https://registry.khronos.org/vulkan/specs/latest/pdf/vkspec.pdf Khronos: Vulkan Specification – Device Groups]

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Multi-GPU]]
[[Kategorie:Direct3D 12]]
[[Kategorie:Experimentell]]

UE5 Heterogeneous Multi-GPU

2026-09-14T18:25:01Z

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

{{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.}}

'''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.

{| class="wikitable"
|+ Projektstatus
|-
! Engine / Plattform
| Unreal Engine 5.8 Source Build / Windows / Direct3D 12
|-
! Testsystem
| Lenovo LOQ 17IRX10
|-
! Primary
| NVIDIA GeForce RTX 5060 Laptop GPU
|-
! Worker
| Intel UHD Graphics
|-
! Zusätzliche Testhardware
| Intel Arc A750 und Arc A380 als zusätzliche dGPU-Worker-Gegenchecks vorgesehen; belastbare Messwerte liegen noch nicht vor
|-
! 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
|-
! 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
|-
! Gesamtvision
| etwa 30–35 % (Scheduler, echte Workloads, N-GPU und Vulkan noch offen)
|}

== Grundprinzip ==

<pre>
Intel Worker GPU
-> MainTextureCS + PatternPhase
-> persistente Worker-Textur
-> persistenter Shared Cross-Adapter Buffer
-> monotone Shared Fence / Queue Wait
-> persistente UE-eigene FTextureRHIRef
-> stabile UExperimentalMultiGPUTexture

RTX Primary GPU
-> normales UE5-Rendering
-> TPS-Material zeigt das Worker-Ergebnis sichtbar an
</pre>

Pro Worker ist maximal ein Runtime-Job gleichzeitig in flight. Backpressure lehnt weitere Requests als <code>Busy</code> ab, bis der Slot nach der Primary-Completion wieder sicher verwendbar ist.

Jeder Worker besitzt ein eigenes <code>ID3D12Device</code>, eigene Queues, Command Lists und Ressourcen. Ein späterer Scheduler soll Rechenleistung, Fähigkeiten, Transferkosten und gewünschte Aktualisierungsrate bewerten. Vorgesehene Aufgaben sind beispielsweise SceneCapture2D, Spiegel, CCTV, Minimap, Compute oder Niagara.

== Verifizierter Entwicklungsstand ==

=== Worker-Compute ===

Ein echter, von Unreal kompilierter Global Compute Shader läuft auf der Intel UHD, während Unreal regulär über die RTX rendert. Der Test verdoppelt 64 Ganzzahlen auf dem Worker; '''64 von 64 Ergebnissen wurden korrekt verifiziert'''. Damit ist echte GPU-Arbeit auf einem zweiten, herstellerfremden Device nachgewiesen.

Zusätzlich läuft <code>MainTextureCS</code> auf der Intel-GPU. Der synchrone Debugtest erzeugt eine 64 × 64 Pixel große RGBA8-Textur; '''alle 4096 shader-generierten Pixel wurden korrekt verifiziert'''. Der normale Runtime-Pfad verwendet inzwischen einen asynchronen 128×96-Test. Der Shader liest seine Dimensionen mit <code>GetDimensions()</code>, schützt überhängende Threads durch einen Bounds-Check und wird mit <code>Dispatch(16,12,1)</code> ausgeführt. <code>PatternPhase</code> erzeugt für jeden akzeptierten Submit deterministisch einen neuen sichtbaren Inhalt. Abgewiesene Busy-Requests erhöhen die Phase nicht und erzeugen daher keine Lücken.

=== Cross-Adapter-Speicher und Synchronisation ===

* RTX und Intel öffnen denselben D3D12 Cross-Adapter Heap.
* Ein gemeinsamer Buffer wurde mit 64 Testwerten erfolgreich geprüft.
* Ein persistenter Shared Fence synchronisiert die Queues direkt von GPU zu GPU. Seine Werte steigen pro Job monoton: WorkerReady/PrimaryComplete verwenden die Paare 1/2, 3/4, 5/6 und so weiter.
* Die CPU vermittelt die GPU-Abhängigkeit nicht; Worker- und Primary-Queue verwenden <code>Signal</code> und <code>Wait</code> direkt auf der GPU.
* Der separate Readback-Verifikationstest darf weiterhin blockieren. Der normale Runtime-Pfad wartet dagegen nicht auf GPU-Leerlauf.

=== Texturtransport ===

Direkte Cross-Adapter-Texturen sind auf dem Testsystem nicht beidseitig verfügbar: Die Intel UHD meldet Unterstützung für Row-Major Cross-Adapter Textures, die RTX 5060 Laptop GPU nicht. Deshalb verwendet das Projekt einen allgemeineren Buffer-Fallback.

<pre>
Intel MainTextureCS
-> persistente Worker-Textur
-> CopyTextureRegion
-> persistenter Shared Cross-Adapter Buffer
-> Worker signalisiert WorkerReady (1, 3, 5, ...)
-> UE-Primary-Queue wartet auf WorkerReady
-> direkte Kopie in persistente UE-eigene FTextureRHIRef
-> Primary signalisiert PrimaryComplete (2, 4, 6, ...)
</pre>

Der robuste Normal-Pfad kopiert die Worker-Textur über den Shared Buffer direkt in eine von Unreal erzeugte <code>FTextureRHIRef</code>. Breite, Höhe und Row Pitch werden dynamisch aus Worker-Ressource und Transport-Metadaten übernommen. Der erfolgreiche 128×96-RGBA8-Test verwendet 512 Byte Row Pitch und 49.152 Byte Transfergröße. Die Output Registry trennt Persistent-, Pending- und Ready-Zustände sowie Inhaltsgeneration und Texturidentität. Dadurch kann eine verspätete Completion keinen neueren Output zurückrollen.

=== Non-blocking Runtime-Pfad ===

Die produktive Testlogik ist aus dem Konsolenkommando in eine gekapselte NormalPath-API verschoben. <code>SubmitWorkerTextureComputeJob()</code> reicht den Worker-Dispatch ohne CPU-Wait ein. <code>QueueNormalTextureTransfer()</code> reiht Wait, Kopie und Completion-Signal in Unreals D3D12-Kontext ein. Der normale MainTextureCS-Pfad enthält weder CPU-Fence-Waits noch Readback, <code>Map</code> oder Pixelvergleich. <code>TickNormalTextureTransfers()</code> prüft die Primary-Completion non-blocking über einen Runtime-Pump; <code>RHIEndFrame()</code> bleibt als Fallback erhalten.

Eine passende Primary-<code>FTextureRHIRef</code> wird pro Worker und Konfiguration persistent gehalten. Nach PrimaryComplete kann der nächste Job dieselbe Resource erneut verwenden; dabei führt Unreal die Übergänge <code>SRVMask -> CopyDest -> SRVMask</code> aus. Eine backend-neutrale RHI-Provider-API reicht die Ready-Textur an die Engine weiter. <code>UExperimentalMultiGPUTexture</code> hält eine stabile <code>UTexture</code> samt TextureReference und bindet die persistente <code>FTextureRHIRef</code> ohne zusätzlichen Pixel-Copy. Eine native D3D12-Resource wird weiterhin nicht blind als UE-Textur gewrappt, weil Unreals Resource-State-Buchhaltung den tatsächlichen nativen Zustand sonst nicht sicher kennt.

=== Sichtbarer TPS-Consumer ===

<code>AExperimentalMultiGPUDisplayActor</code> zeigt die Worker-Ausgabe im Third-Person-Testlevel über den Materialparameter <code>MultiGPUTexture</code> an. Damit ist der Output nicht mehr nur über Logs oder Readback nachgewiesen: Die Intel UHD erzeugt fortlaufend die Texturinhalte, während die RTX die Spielwelt und das Material rendert. <code>TextureConsumerCS</code> kann Ready-Ausgaben auf der Primary zusätzlich als SRV lesen und fünf quantisierte Samples im Debugpfad prüfen.

=== Lebensdauer und automatisches Cleanup ===

Der Normal-Pfad verwendet pro Worker genau einen persistenten Runtime-Slot. Worker-Textur, Root Signature, PSO, Descriptor Heap, Command Allocator/List und Worker-Fence werden nach der ersten kompatiblen Initialisierung wiederverwendet. Dasselbe gilt für Shared Heap/Buffer/Fence und die Transport-Command-Objekte. Der In-Flight-Job trägt nur noch die nötigen Job-, Generation- und Fence-Metadaten.

<pre>
Runtime Request
-> Completion non-blocking prüfen
-> falls Slot frei: Worker Dispatch
-> WorkerReady-Fence signalisieren
-> Primary Wait, SafeCopy und PrimaryComplete-Signal
-> Output Pending
-> Runtime-Pump oder RHIEndFrame prüft GetCompletedValue()
-> Output Ready publizieren
-> Slot wiederverwendbar
</pre>

Backpressure erlaubt maximal einen echten In-Flight-Job pro Worker. Ein Busy-Request setzt keine GPU-Arbeit ab, setzt keine Ressourcen zurück und erhöht <code>PatternPhase</code> nicht. Worker-Fence-Werte steigen mit jedem akzeptierten Submit 1, 2, 3 und so weiter; der persistente Shared Fence verwendet fortlaufend die Paare 1/2, 3/4, 5/6. Fehler nach Übergabe von Ressourcen an die GPU führen zu sicherem Retire beziehungsweise Retention statt zu vorzeitigem Reuse.

=== Texture Stream und Benchmarking ===

Der projektseitige Texture Stream akzeptiert eine beliebige positive, endliche Zielrate. Punkt und Komma sind als Dezimaltrenner möglich. Optional lässt sich die Zahl erfolgreicher Submits begrenzen; Busy- oder Failed-Versuche verbrauchen dieses Limit nicht. Der Quiet-Modus unterdrückt per-Job-Ausgaben, behält aber Start, echte Fehler und die Abschlussstatistik bei.

Die Statistik unterscheidet Timer-Ticks, angenommene Submits, Busy/Failed, Ready, In-Flight und die jeweiligen effektiven Raten. Diagnosezeitpunkte erfassen unter anderem RequestAccepted, RenderCommandExecution, WorkerSubmit, NormalTransferQueued und ReadyObserved.

{| class="wikitable"
! Test
! Ergebnis
! Aussage
|-
| 5 Hz, 20 Submits
| etwa 5 Ready/s, 20/20, kein Busy
| Entspannter Single-Slot-Betrieb
|-
| 1000 Hz, 100 Submits, quiet
| 100/100 Ready, 0 Fehler, etwa 58 Ready/s
| Backpressure begrenzt den Durchsatz sicher
|-
| 1000 Hz bei <code>t.MaxFPS 30</code>
| etwa 28–29 Ready/s trotz rund 982 Timer-Ticks/s
| Primary-/SafeCopy-/Ready-Kette ist effektiv framegekoppelt
|}

Ein zusätzlicher non-blocking Aufruf von <code>ImmediateFlush(DispatchToRHIThread)</code> erreicht hohe Render-Command-Raten, hebt die gemessene Frame-Kopplung aber nicht auf. Im 30-FPS-Test lag der RHIEndFrame-spezifische Completion-Takt praktisch exakt bei 30 Hz. Das aktuelle Problem ist damit eingegrenzt: Nicht der Stream-Timer, sondern die Primary-RHI-/D3D12-Submission der SafeCopy-Kette bestimmt die sichtbare Ready-Rate.

=== Queue-Submission-Diagnose ===

<code>MultiGPUD3D12QueueProbe</code> untersucht die Submission unabhängig vom sichtbaren Texturpfad. Neben <code>full</code>, <code>waitonly</code> und <code>signalonly</code> existieren inzwischen die Diagnosemodi <code>computeonly</code>, <code>commandonly</code>, <code>barrieronly</code>, <code>barrierprivate</code> und <code>copybuffer</code>. Als Queues stehen <code>graphics</code>, <code>copy</code>, <code>native</code>, <code>worker</code>, <code>worker-copy</code> und <code>worker-high</code> zur Verfügung. Graphics und Copy verwenden <code>RHIRunOnQueue(..., false)</code> auf UE-verwalteten Primary-Queues; die übrigen Varianten isolieren private beziehungsweise bereits vorhandene native D3D12-Queues.

Der Probe misst Request, Worker-Submit, <code>RHIRunOnQueue</code>-Aufruf und -Callback, Primary-Execute, Fence-Completion sowie Ready bis zum nächsten akzeptierten Submit. Er fügt keine CPU-Waits, Readbacks, Maps oder <code>BlockUntilGPUIdle</code> ein und beschreibt keine Textur des sichtbaren Normal-Pfads.

{| class="wikitable"
! Test
! Ergebnis
! Befund
|-
| UE Graphics, signal-only, 30 FPS
| 33,319 ms PrimaryExecute bis Ready
| UE-verwaltete Graphics-Submission skaliert mit der Frame-Dauer
|-
| UE Copy, signal-only, 30 FPS
| 32,593 ms PrimaryExecute bis Ready
| Auch die UE-verwaltete Copy Queue ist framegekoppelt
|-
| Private Primary-DIRECT-Queue, signal-only
| etwa 0,014 ms Queue/Fence-Latenz; nach Lifecycle-Fix rund 999 Ready/s bei 30 FPS
| Native Queue und Scheduler sind vollständig vom Frame entkoppelt
|-
| Worker signal-only / leere Command List
| jeweils rund 1000 Ready/s bei 30 FPS
| Worker-Queue, Fence und reine Submission sind nicht framegekoppelt
|-
| Worker <code>CopyBufferRegion</code>, 30 / 60 / 120 FPS
| 29,41 / 58,25 / 113,08 Ready/s
| Bereits eine echte 256-Byte-GPU-Kopie folgt im UE-Prozess dem Frame-Raster
|-
| Worker COPY Queue / HIGH Priority, 30 FPS
| jeweils rund 29,42 Ready/s
| Queue-Typ und Priorität beseitigen die Kopplung nicht
|-
| Standalone-D3D12 auf derselben Intel UHD
| 92.956 Copy-Jobs/s; 0,007 ms durchschnittliche Fence-Latenz
| Die Kopplung ist UE-Prozess-/Scheduling-spezifisch, keine allgemeine Intel-, WDDM- oder D3D12-Grenze
|}

Der <code>RHIRunOnQueue</code>-Callback selbst erreicht den D3D12-Submission-Thread typischerweise bereits nach etwa 0,02–0,05 ms; die Verzögerung entsteht danach in der verwalteten Queue-/Submission-Reihenfolge. <code>SubmitCommandsHint()</code> ist in UE 5.8 nur ein veralteter Alias für <code>ImmediateFlush(DispatchToRHIThread)</code> und stellt daher keinen stärkeren Submission-Mechanismus dar.

Der native Test ist ein '''Architekturbeweis, noch kein Experimental- oder Direct-Modus'''. Die zunächst gemessene Verzögerung von rund 32 ms lag zwischen der In-Flight-Freigabe und dem nächsten Request auf dem Render Thread. Für <code>signalonly/native</code> wurde der sichere Completion-/Submit-Lifecycle deshalb in den frameunabhängigen Scheduler verlegt. Danach erreichten zwei 100-Job-Läufe bei <code>t.MaxFPS 30</code> rund 999 bis 1029 Ready/s, ohne Busy oder Fehler.

Der anschließende <code>full native</code>-Test lokalisierte die verbleibende Kopplung auf echte Worker-GPU-Arbeit: WorkerSubmit bis WorkerReady benötigte bei 30, 60 und 120 FPS ungefähr 33,29, 16,93 und 8,45 ms; WorkerReady bis PrimaryReady war danach praktisch sofort. Signal-only und eine leere Command List waren schnell, Resource Barriers und eine 256-Byte-Kopie dagegen framegebunden. Ein eigenständiger D3D12-Microbenchmark auf derselben Intel UHD erreichte außerhalb von Unreal bei derselben Kopie rund 92.956 Jobs/s mit 0,007 ms mittlerer Fence-Latenz. Die genaue Ursache im UE-Prozess beziehungsweise dessen GPU-Scheduling-Kontext bleibt offen und wird vorerst bis zum Gegencheck mit der vorhandenen Intel Arc A380 geparkt.

=== Worker-Rasterpfad und RasterStream ===

<code>ExperimentalMultiGPU.TestRasterWorker</code> weist erstmals echte Rasterizer-Arbeit auf der Intel-Worker-GPU nach. <code>RasterWorkerVS</code> und <code>RasterWorkerPS</code> werden über Unreals Global-Shader-Pfad kompiliert und für ein natives Worker-Graphics-PSO verwendet. Ein persistentes 128×96-RGBA8-RenderTarget besitzt RTV, leere Root Signature und eine DIRECT-Command-List. Der Vertex Shader erzeugt drei Vertices über <code>SV_VertexID</code>; der Pixel Shader schreibt interpolierte RGB-Farben.

Der Job wechselt das RenderTarget von <code>COPY_SOURCE</code> nach <code>RENDER_TARGET</code>, führt Clear und <code>DrawInstanced(3,1,0,0)</code> aus und wechselt anschließend zurück nach <code>COPY_SOURCE</code>. Danach verwendet er unverändert den robusten Normalpfad aus Cross-Adapter-Shared-Buffer, Primary SafeCopy, persistenter <code>FTextureRHIRef</code>, <code>UExperimentalMultiGPUTexture</code> und DisplayActor. Der Runtime-Test meldete einen akzeptierten Submit und <code>RasterWorker READY</code> für Generation 1; die 128×96-UTexture wurde erfolgreich gebunden.

Der einmalige Test wurde außerdem zu einem frei konfigurierbaren RasterStream ausgebaut. Ein sichtbarer Lauf mit 10 Hz und 50 erfolgreichen Submits endete mit 50 Ready-Ausgaben, 0 Busy und 0 Fehlern bei etwa 9,90 Ready/s. Primary-Textur und Materialbindung blieben dabei persistent.

=== Raster3D mit echten Vertex- und Indexbuffern ===

Der Worker besitzt inzwischen einen kleinen eigenständigen 3D-Rasterpfad mit perspektivischer Kamera, Model-View-Projection-Matrix als Root Constants, D32_FLOAT-Depth-Buffer und Depth-Test. Der finale Testwürfel verwendet 24 POSITION/COLOR-Vertices, 36 <code>uint16</code>-Indices und <code>DrawIndexedInstanced(36,1,0,0,0)</code>; sechs getrennte Seitenfarben machen Ausrichtung und Rotation sichtbar nachvollziehbar.

Die statischen Meshdaten werden einmalig über private Upload-Buffer in DEFAULT-Heaps übertragen. Der Init-Fence wird non-blocking über <code>GetCompletedValue()</code> beobachtet. Der eigentliche Runtime-Renderpfad enthält weiterhin keine CPU-Waits und keine Maps.

=== UE-Static-Meshes auf der Worker-GPU ===

<code>StaticMeshWorker</code> extrahiert echte LOD0-Geometrie aus <code>UStaticMesh</code>-Assets. POSITION und NORMAL sowie <code>uint32</code>-Indices werden in POD-Daten überführt, einmalig asynchron in eigene Worker-VB/IB hochgeladen und anschließend per <code>DrawIndexedInstanced</code> gerendert. Assetpfade sind dynamisch; Auto-Fit richtet Kamera beziehungsweise Modellmaßstab an den Bounds aus.

Sichtbar korrekt getestet wurden:

{| class="wikitable"
! Asset
! Vertices
! Indices
|-
| Sphere
| 559
| 2880
|-
| Cube
| 54
| 144
|-
| Cylinder
| 334
| 1536
|}

=== Multi-Mesh Worker-Szene ===

<code>StaticMeshScene</code> rendert Sphere, Cube und Cylinder gemeinsam in einen Color-/Depth-Frame. Der verifizierte Test umfasst insgesamt 947 Vertices und 4560 Indices, drei <code>DrawIndexedInstanced</code>-Aufrufe und nur einen anschließenden Cross-Adapter-/Normal-SafeCopy-Transfer. Damit ist nicht mehr nur ein synthetisches Primitive, sondern mehrere echte UE-Meshes mit gemeinsamer Tiefenprüfung im Worker-Frame sichtbar nachgewiesen.

=== WorldStaticMeshScene ===

<code>ExperimentalMultiGPUWorldStaticMeshScene.cpp</code> sammelt im Engine-Layer bis zu acht sichtbare <code>UStaticMeshComponent</code>s von Actors mit dem Tag <code>MultiGPUWorker</code>. Meshdaten und World-Transforms werden im Game Thread in reine POD-Strukturen und 4×4-Matrizen kopiert. D3D12RHI erhält keine <code>UObject</code>-Pointer. Mehrere Instanzen desselben Meshes teilen den persistenten Worker-Mesh-Cache und unterscheiden sich nur durch Modelmatrix und Draw Call.

Der Pfad wurde inzwischen sichtbar im PIE-Level verifiziert. Drei getaggte Static-Mesh-Actors erschienen mit ihren tatsächlichen relativen Positionen, Rotationen und Skalierungen im Worker-Bild. Die zentrale Koordinatenumrechnung lautet:

<pre>Worker (X, Y, Z) = (UE Y, UE X, -UE Z)</pre>

Die Transformation besitzt die Determinante +1 und ist damit keine Spiegelung. Das notwendige horizontale Spiegeln erfolgt ausschließlich auf der Presentation-Plane, nicht im Worker-Renderpfad.

=== Kontinuierlicher WorldStaticMeshSceneStream ===

<code>StartWorldStaticMeshSceneStream</code> erfasst die getaggte Szene fortlaufend im Game Thread. Reine Änderungen an Transform oder Kamera lösen keinen erneuten Mesh-Upload aus. Hinzugekommene, entfernte, unsichtbare oder umgetaggte Components werden im nächsten Snapshot berücksichtigt. Single-Slot-Backpressure verhindert einen wachsenden Rückstau.

Ein verifizierter 30-Hz-Lauf endete nach 31,184 Sekunden mit 835 Ticks, 691 angenommenen Submits, 144 Busy, 0 Fehlern und 691 Ready-Frames. Die effektive Ready-Rate betrug 22,16 Hz. Dieser Test belegt die funktionale Live-Aktualisierung; die Rate war noch kein Optimierungsziel.

=== SceneCapture2D als Worker-Kamera ===

<code>TestSceneCaptureStaticMeshScene</code> verwendet eine echte <code>ASceneCapture2D</code> beziehungsweise <code>USceneCaptureComponent2D</code> aus der laufenden PIE-Welt als Kameraquelle. Der empfohlene Editor-Weg ist das Component Tag <code>MultiGPUWorkerCamera</code> auf der <code>CaptureComponent2D</code>; ein gleichnamiges Actor-Tag bleibt nur als Legacy-Fallback.

Ausgelesen werden World Location, Rotation, Forward/Right/Up, <code>FOVAngle</code> und <code>ProjectionType</code>. Orthografische Projektion wird derzeit sauber abgelehnt. Die SceneCapture2D liefert ausschließlich Kameradaten: Ihr UE-RenderTarget wird weder gelesen noch kopiert. Die Intel-Worker-GPU rendert die Geometrie selbst. Kamera und Actors werden gemeinsam mit <code>SceneScale = 0.01</code> in Worker-Koordinaten überführt; Auto-Fit und Scene-Recentering sind in diesem Modus deaktiviert.

Die 128×96-Worker-Projektion verwendet ein Seitenverhältnis von 4:3 und interpretiert <code>FOVAngle</code> als horizontales FOV. Nach den Orientierungstests wird nur die Anzeige über <code>SetRelativeScale3D(FVector(-4.0f, -3.0f, 1.0f))</code> korrigiert; dies entspricht <code>U' = 1-U</code> und <code>V' = 1-V</code>.

=== Live SceneCaptureStaticMeshSceneStream ===

<code>StartSceneCaptureStaticMeshSceneStream</code> liest Kamera-Transform, Kamerabasis, FOV und aktuelle Actor-Transforms pro Snapshot neu im Game Thread. Der Worker erhält weiterhin ausschließlich POD-Daten, verwendet den persistenten Mesh-Cache sowie ein gemeinsames Color- und D32-Depth-Target und führt pro akzeptiertem Frame genau einen Cross-Adapter-/Normal-SafeCopy-Transfer aus.

Der Quiet-Test

<pre>ExperimentalMultiGPU.StartSceneCaptureStaticMeshSceneStream 30 300 quiet</pre>

lieferte in 10,084 Sekunden 301 Ticks, 300 Submits, 1 Busy, 0 Fehler und 300 Ready-Frames. Die effektive Ready-Rate betrug 29,75 Hz. Bewegungen der Kamera und Actors sowie FOV-Änderungen erschienen live auf der Display-Plane. Damit ist erstmals ein kleiner SceneCapture-/CCTV-artiger Worker-Kanal vollständig funktional nachgewiesen.

=== Dynamische SceneCapture-Auflösung ===

Die SceneCapture-Ausgabe ist nicht mehr fest auf 128×96 Pixel begrenzt. <code>ExperimentalMultiGPU.SetSceneCaptureResolution <Width> <Height></code> setzt ganzzahlige Dimensionen von 1 bis 4096; <code>GetSceneCaptureResolution</code> zeigt die aktive Einstellung. 128×96 bleibt der Standard. Während ein SceneCapture-Stream läuft, wird ein Auflösungswechsel absichtlich abgelehnt, damit keine In-Flight-Ressourcen ausgetauscht werden.

Color Target, D32-Depth-Buffer, Row Pitch, Shared-Buffer-Transport, SafeCopy, persistente Primary-Textur und <code>UExperimentalMultiGPUTexture</code> übernehmen die gewählten Dimensionen. Projektion und Display-Plane verwenden das echte Seitenverhältnis. Die bestätigte Anzeigeorientierung <code>U' = 1-U</code> und <code>V' = 1-V</code> bleibt eine reine Presentation-Korrektur; Worker-Basis und Kameramathematik ändern sich nicht.

=== Scheduler-Korrektur bei SceneCapture ===

Ein 1920×1080-Test mit 25 Hz erreichte zunächst trotz fehlerfreier Frames nur 13,90 Ready-Hz und erzeugte 222 Busy-Ticks. Ursache war kein GPU-Limit, sondern ein Polling-Aliasing: Eine frühe Game-Thread-Prüfung konnte den Timer-Slot verwerfen, obwohl die Completion kurz darauf im CoreTicker/RHI-Pump sichtbar geworden wäre.

Die frühe <code>IsRuntimeTextureUpdateInFlight()</code>-Prüfung wurde für diesen Stream entfernt. Der Pending-Request bleibt als Backpressure-Gate erhalten; die maßgebliche Busy-Entscheidung fällt nun erst im Render Command nach <code>TickNormalTextureTransfers(nullptr, true)</code>. Single-Slot, POD-Snapshots und non-blocking <code>GetCompletedValue()</code> bleiben erhalten. Es wurden weder CPU-Waits noch zusätzliche Threads eingeführt.

Nach der Korrektur erreicht 1080p bei 25 Hz 24,79 Ready-Hz mit 1 Busy; bei 30 Hz sind es 29,43 Ready-Hz mit 4 Busy.

=== Skalierung bis 4K60 ===

Die Pipeline wurde von 640×360 bis 3840×2160 getestet. Bei 640×360/30 Hz und 1280×720/30 Hz wurden 29,85 beziehungsweise 29,82 Ready-Hz ohne Busy erreicht. 1920×1080/60 Hz lieferte 59,40 Ready-Hz ohne Busy, 2560×1440/60 Hz 59,21 Ready-Hz mit 1 Busy und 3840×2160/60 Hz 59,02 Ready-Hz mit 2 Busy.

Ein zusätzlicher 4K60-Stresstest mit acht Static-Mesh-Instanzen und drei gecachten Unique Meshes erreichte in 5,049 Sekunden '''300 von 300 Ready-Frames, 0 Busy, 0 Fehler und 59,42 effektive Ready-Hz'''. Acht Draw Calls, gemeinsamer Depth Buffer, Cross-Adapter-Transport und SafeCopy liefen dabei im vorhandenen Single-Slot. Das ist ein Stabilitätsnachweis der aktuellen Mini-Szene, kein allgemeiner GPU-Benchmark.

=== Skeletal Mesh in Reference Pose ===

<code>ExperimentalMultiGPU.TestSkeletalMeshWorker</code> erweitert den Geometriepfad auf <code>USkeletalMeshComponent</code>. Der Engine-Layer sucht deterministisch die erste sichtbare, getaggte Komponente und extrahiert LOD0-Positionen, Normalen, Indices und Render Sections. D3D12RHI erhält wie bisher ausschließlich POD-Geometrie und Modelmatrizen.

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. Skeletal Skinning ist erst vorgesehen, wenn ein echter Worker-Workload wie CCTV oder Spiegel animierte Figuren in seiner eigenen Ansicht benötigt.

=== Generische Workload-Registry ===

Commit <code>37c6d02</code> führt erstmals eine backend-neutrale Workload-Schicht ein. Sie beschreibt Aufgaben unabhängig vom konkreten Grafik-Backend und bildet die Grundlage für einen späteren Scheduler, trifft selbst aber noch keine GPU-Entscheidung.

{| class="wikitable"
! Bestandteil
! Inhalt
|-
| Workload-Typ
| <code>Unknown</code>, <code>SceneCapture</code>, <code>Compute</code> oder <code>Raster</code>
|-
| Gewünschte Zuweisung
| <code>Primary</code>, <code>Worker</code> oder <code>Auto</code>; <code>Auto</code> ist derzeit nur Metadatum
|-
| Priorität
| <code>Low</code>, <code>Normal</code> oder <code>High</code>
|-
| Descriptor
| Sessionweit monotone ID, Typ, Zuweisung, Priorität, Auflösung, Zielrate, Debugname und Running-Status
|}

Die Registry stellt <code>RegisterWorkload</code>, <code>UpdateWorkload</code>, <code>UnregisterWorkload</code>, <code>GetWorkload</code> und <code>GetActiveWorkloads</code> bereit und schützt ihre Daten per <code>FCriticalSection</code>. Descriptoren enthalten weder <code>UObject</code>- noch D3D12-Pointer. Der SceneCapture-Stream registriert genau einen Worker-Workload mit normaler Priorität und entfernt ihn bei Stop oder Auto-Stop wieder vollständig.

<code>ExperimentalMultiGPU.ListWorkloads</code> zeigt die aktiven Descriptoren und ihre Laufzeitwerte an.

=== Runtime Metrics V1 ===

Descriptor und Laufzeitstatistik sind getrennt. Pro Workload werden Ticks, angenommene Submits, Busy- und Fehlerfälle, fertige Frames, aktuell ausstehende Jobs, Laufzeit sowie effektive Tick-, Submit- und Ready-Raten erfasst. Der SceneCapture-Pfad spiegelt dafür seine vorhandenen Stream-Zähler in die Registry, statt eine zweite Statistiklogik aufzubauen. Die Messwerte werden derzeit nur beobachtet und ändern weder Zuweisung noch Auflösung oder Zielrate.

Editor-Fokus und Background-Throttling können die Lifecycle-Raten deutlich verfälschen. In einem sauberen 1280×720-Referenzlauf wurden 1000/1000 Ready-Frames ohne Busy bei 29,84 Ready-Hz gemessen; bei wechselndem Fensterfokus entstanden dagegen 459 Busy-Ticks und nur 16,69 Ready-Hz, ohne dass die Worker-GPU-Zeit entsprechend einbrach. Solche Raten sind daher kein verlässlicher Ersatz für echte GPU-Kostenmessungen.

=== Worker GPU Timing V1 ===

Der SceneCapture-Worker verwendet persistente native D3D12-Timestamp-Queries auf seiner vorhandenen DIRECT-Queue: einen Query Heap mit zwei Slots, einen kleinen Readback-Buffer und die per <code>GetTimestampFrequency()</code> ermittelte Zeitbasis. Das Ergebnis wird erst nach non-blocking geprüftem Fence-Abschluss gelesen; CPU-Waits entstehen nicht. Die Workload-ID wird als POD bis zum Worker mitgeführt, während einmalige Tests die ID 0 verwenden.

Gemessen wird ausschließlich der Worker-Rasterabschnitt:

<pre>
Start Timestamp
-> COPY_SOURCE nach RENDER_TARGET
-> Color- und Depth-Clear
-> alle DrawIndexedInstanced-Aufrufe
-> RENDER_TARGET nach COPY_SOURCE
End Timestamp
-> ResolveQueryData
</pre>

Nicht enthalten sind der Cross-Adapter-Transfer, die Primary-SafeCopy und die Integration auf der Primary-GPU. Erfasst werden Sample-Anzahl sowie letzter, mittlerer, minimaler und maximaler Messwert.

{| class="wikitable"
! Auflösung
! Samples
! Mittelwert
! Minimum
! Maximum
|-
| 1280×720
| 845
| 0,166 ms
| 0,165 ms
| 0,181 ms
|-
| 3840×2160
| 599
| 0,683 ms
| 0,594 ms
| 0,751 ms
|}

Bei identischem, bewusst einfachem Szeneninhalt mit sieben Draw Calls steigt die gemessene Worker-Rasterzeit damit ungefähr um Faktor 4,1. Die Pixelzahl allein erklärt die Skalierung nicht vollständig. Für ein belastbares Kostenmodell müssen als Nächstes Transfer und Primary-Integration separat gemessen werden.

== Test- und Diagnosebefehle ==

Die vorhandenen Compute-, Texture-, Raster-, StaticMesh-, World- und QueueProbe-Kommandos bleiben bestehen. Neu hinzugekommen ist:

{| class="wikitable"
! Befehl
! Zweck
|-
| <code>ExperimentalMultiGPU.ListWorkloads</code>
| Listet aktive Workloads mit ID, Typ, gewünschter Zuweisung, Priorität, Auflösung, Zielrate, Lifecycle-Statistik und Worker-GPU-Timing auf.
|}

Für den aktuellen Hauptpfad sind außerdem besonders relevant:

<pre>
ExperimentalMultiGPU.SetSceneCaptureResolution <Width> <Height>
ExperimentalMultiGPU.GetSceneCaptureResolution
ExperimentalMultiGPU.TestSceneCaptureStaticMeshScene
ExperimentalMultiGPU.StartSceneCaptureStaticMeshSceneStream [Hz] [MaxSuccessfulSubmits] [quiet]
ExperimentalMultiGPU.StopSceneCaptureStaticMeshSceneStream
ExperimentalMultiGPU.TestSkeletalMeshWorker
ExperimentalMultiGPU.ListWorkloads
</pre>

=== Texture Stream ===

Grundsyntax:

<pre>ExperimentalMultiGPU.StartTextureStream [Hz] [MaxSuccessfulSubmits] [quiet]</pre>

Die Hz-Angabe ist eine Ziel- beziehungsweise Request-Frequenz. <code>MaxSuccessfulSubmits</code> zählt nur angenommene Submits; Busy- und Failed-Versuche verbrauchen das Limit nicht. <code>quiet</code> unterdrückt Per-Job- und Busy-Logspam.

=== QueueProbe ===

Grundsyntax:

<pre>ExperimentalMultiGPU.StartQueueProbe <Hz> <MaxSubmits> [quiet] <Mode> <Queue></pre>

Die Diagnosemodi <code>full</code>, <code>waitonly</code>, <code>signalonly</code>, <code>commandonly</code>, <code>barrieronly</code>, <code>barrierprivate</code> und <code>copybuffer</code> bleiben verfügbar. Als Queue können <code>graphics</code>, <code>copy</code>, <code>native</code>, <code>worker</code>, <code>worker-copy</code> und <code>worker-high</code> gewählt werden. Private native Queues dienen weiterhin nur der Diagnose und bilden keinen fertigen Experimental-/Direct-Modus.

=== Benchmark-CVars ===

<code>r.VSync 0</code> deaktiviert VSync. <code>t.MaxFPS 30</code>, <code>60</code> oder <code>120</code> erzeugt reproduzierbare Frame-Coupling-Tests; <code>t.MaxFPS 0</code> entfernt das normale Framerate-Limit.

== Aktueller nächster Schritt ==

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 ==

Die Grundidee heterogener Multi-GPU-Nutzung ist nicht neu. Bereits mit der Einführung von Direct3D 12 entstanden mehrere Versuche, integrierte und dedizierte GPUs gemeinsam zu verwenden. Eine allgemein einsetzbare Lösung für moderne UE5-Spiele hat sich daraus jedoch nicht entwickelt.

=== Microsoft und Epic: UE4 Elemental Demo (2015) ===

Microsoft zeigte eine angepasste Unreal-Engine-4-Version der Elemental-Demo, bei der eine NVIDIA-GPU und eine Intel-iGPU gemeinsam arbeiteten. Das erklärte Ziel war, ansonsten ungenutzte Grafikleistung in Hybrid-Systemen zu verwenden. Dieser Versuch ist der Grundidee des Projekts besonders ähnlich, blieb aber eine technische Demonstration.

=== Intel: D3D12 Multi-Adapter Sample (2015) ===

Intels Beispiel kombinierte eine GeForce 840M mit Intel HD Graphics 5500. Beide GPUs berechneten getrennte Teile einer einfach parallelisierbaren Raytracing-Szene. Cross-Adapter-Ressourcen und Shared Fences führten die Ergebnisse anschließend zusammen. Intel berichtete in diesem Test von nahezu halbierter Framezeit, warnte jedoch ausdrücklich davor, das Ergebnis unmittelbar auf reale Spiele zu übertragen.

=== Ashes of the Singularity ===

Die Nitrous Engine von ''Ashes of the Singularity'' setzte Direct3D-12-Explicit-Multiadapter in einem veröffentlichten Spiel ein. Dabei konnten auch unterschiedliche GPU-Modelle und Hersteller zusammenarbeiten. Das war ein wichtiger Praxisnachweis, blieb in der Spielebranche aber eine seltene Ausnahme.

=== Weitere verwandte Ansätze ===

* ''Rise of the Tomb Raider'' erhielt explizite Direct3D-12-Multi-GPU-Unterstützung, vor allem für klassische Kombinationen ähnlicher GPUs.
* NVIDIA VR SLI wies bei Virtual Reality jeder GPU ein Auge zu. Das verteilt unabhängige Ansichten, bleibt jedoch NVIDIA-spezifisch.
* Unreal nDisplay kann Viewports oder Frustums auf weitere GPUs beziehungsweise Prozesse auslagern und das fertige Bild zur Ausgabe-GPU zurückführen. Der Einsatzbereich ist hauptsächlich Virtual Production.
* Forschung und High-Performance Computing verwenden seit Jahren Scheduler für heterogene GPUs, allerdings überwiegend für Compute- und Datenverarbeitungsaufgaben statt für einen allgemeinen UE5-Echtzeitrenderer.

=== Abgrenzung dieses Projekts ===

Das Projekt erfindet Direct3D-12-Explicit-Multiadapter nicht neu. Sein eigener Ansatz liegt in der Kombination aus tiefer UE5.8-RHI-Integration, UE-kompilierten Shadern auf unabhängigen Worker-Devices, frei wählbaren Spiel- und Compute-Workloads, Capability- und Performance-Scheduler, mehreren Fallback-Pfaden sowie dem langfristigen Ziel beliebiger Hersteller und mehrerer Worker.

== Vergleich mit anderen Multi-GPU-Verfahren ==

{| class="wikitable"
! Verfahren
! Arbeitsweise
! Verhältnis zu diesem Projekt
|-
| SLI / CrossFire
| Treiber- beziehungsweise Verbundlösung für meist ähnliche GPUs; häufig wird die Bildarbeit verteilt.
| Dieses Projekt benötigt keinen herstellerspezifischen GPU-Verbund und weist Aufgaben ausdrücklich selbst zu.
|-
| AFR (Alternate Frame Rendering)
| GPU 1 rendert einen Frame, GPU 2 den nächsten.
| Das Projekt verteilt unabhängige Aufgaben statt aufeinanderfolgender Frames. Dadurch werden Frame-Abhängigkeiten und typisches AFR-Pacing vermieden.
|-
| SFR (Split Frame Rendering)
| Mehrere GPUs bearbeiten Bereiche desselben Frames.
| Erfordert enge Lastverteilung und viel Datenaustausch. Das Projekt bevorzugt vollständig abgrenzbare Workloads und überträgt deren Ergebnis.
|-
| Direct3D 12 Linked Multiadapter
| Mehrere vom Treiber verbundene GPUs erscheinen als Knoten eines logischen Adapters.
| Eignet sich eher für eng kompatible GPUs. Das Projekt verwendet unabhängige Devices (Unlinked/Explicit Multiadapter) und unterstützt dadurch heterogene Herstellerkombinationen.
|-
| Direct3D 12 Unlinked / Explicit Multiadapter
| Die Anwendung verwaltet getrennte Adapter, Ressourcen und Synchronisation selbst.
| Das ist die technische Familie des Projekts. Hinzu kommen die eigene UE5-RHI-Integration, Workload-Ziele, Fallbacks und der geplante Scheduler.
|-
| UE nDisplay mGPU / Multi-Process
| Separate GPUs rendern bestimmte Viewports oder Frustums, vor allem für Virtual Production; Ergebnisse werden zur Ausgabe-GPU kopiert.
| Ähnliche Idee der aufgabenweisen Trennung, aber für einen anderen Einsatzbereich. Dieses Projekt zielt auf allgemeine Spiel- und Compute-Workloads innerhalb der Engine.
|-
| Vulkan Device Groups
| Ähnliche physische GPUs können ein gemeinsames logisches Device bilden.
| Für beliebige heterogene GPUs meist ungeeignet, da Geräte einer Gruppe nahezu gleiche Eigenschaften besitzen müssen. Eine spätere Vulkan-Portierung benötigt daher wahrscheinlich getrennte Devices und External Memory/Semaphores.
|}

SLI und CrossFire bezeichnen den Verbund; AFR und SFR beschreiben mögliche Verteilungsmethoden innerhalb solcher Systeme. Sie sind deshalb nicht vollständig getrennte Kategorien.

== Vorteile der geplanten Variante ==

* '''Herstellerunabhängig:''' NVIDIA, AMD und Intel können grundsätzlich kombiniert werden.
* '''Vorhandene Hardware nutzen:''' Auch eine sonst wenig genutzte integrierte GPU kann geeignete Nebenaufgaben übernehmen.
* '''Aufgaben statt Frames verteilen:''' Spiegel, Minimap oder Compute können mit eigener Auflösung und Aktualisierungsrate laufen.
* '''Keine identischen GPUs erforderlich:''' Unterschiedliche Fähigkeiten können gezielt genutzt werden.
* '''Kontrollierter Datenaustausch:''' Nur das benötigte Ergebnis muss zurück zur Primary-GPU.
* '''Robuste Fallback-Idee:''' Wenn direkte Texturen nicht gemeinsam nutzbar sind, bleibt der Shared-Buffer-Pfad.
* '''Erweiterbar:''' Scheduler, manuelles Mapping und mehrere Worker sind als spätere Stufen vorgesehen.

== Nachteile und technische Risiken ==

* '''Hoher Entwicklungsaufwand:''' Geräte, Ressourcen, Zustände, Fences, Fehlerfälle und UE-Lebenszyklen müssen selbst verwaltet werden.
* '''Transfer kann den Gewinn aufzehren:''' Cross-Adapter Heaps liegen laut D3D12 nicht automatisch im schnellen lokalen VRAM. Bandbreite und Latenz müssen für jeden Workload gemessen werden.
* '''VRAM wird nicht einfach addiert:''' Benötigte Ressourcen können auf mehreren GPUs vorliegen und zusätzlichen Speicher verbrauchen.
* '''Langsame Worker können bremsen:''' Eine Aufgabe lohnt sich nur, wenn Rechengewinn größer als Übergabe-, Warte- und Kopierkosten ist.
* '''Nicht jeder Workload ist unabhängig:''' Hauptansicht, Lumen, Nanite und stark gekoppelte Renderpässe besitzen viele Abhängigkeiten und sind schwieriger auszulagern.
* '''Hardwareunterschiede:''' Formate, Shader-Funktionen, Queue-Fähigkeiten und Cross-Adapter-Support müssen pro GPU geprüft werden.
* '''Wartungsrisiko:''' Eingriffe in private D3D12RHI-Dateien können bei Engine-Updates angepasst werden müssen.
* '''Produktionsreife fehlt noch:''' Ressourcenpools, Timeouts, Device-Lost-Wiederherstellung, Scheduler und echte Szenentests sind offen.

== Wann die Variante sinnvoll ist ==

Am aussichtsreichsten sind Aufgaben mit viel eigener Rechenarbeit, einem relativ kleinen Endergebnis und wenigen Abhängigkeiten zur Hauptszene. Gute frühe Kandidaten sind unabhängige Compute-Aufgaben sowie Scene Captures, die nicht in jedem Frame aktualisiert werden müssen. Weniger geeignet sind winzige Aufgaben mit großem Transfer oder Renderpässe, die ständig auf Ressourcen der Primary-GPU zugreifen.

Die entscheidende Regel für den späteren Scheduler lautet daher:

<pre>
Worker-Gewinn > Vorbereitung + Datentransfer + Synchronisation + Rückintegration
</pre>

== Bekannte Grenzen des Proof of Concepts ==

* 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 sichtbarer Runtime-Slot. Mehrere parallele In-Flight-Jobs und Ringbuffer fehlen noch.
* Praktisch getestet ist Primary plus ein Worker. Mehrere Worker sind architektonisch vorgesehen, aber noch nicht praktisch validiert.
* World- und SceneCapture-Pfade verarbeiten pro Snapshot höchstens acht sichtbare <code>UStaticMeshComponent</code>s.
* 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.
* <code>USkeletalMesh</code> ist bislang ein LOD0-ReferencePose-Proof. Bone-Skinning, Animation, Morph Targets und Cloth fehlen.
* Die Workload-Registry sammelt Metadaten und Messwerte, führt aber noch keine automatische Zuweisung, Auflösungsänderung oder Ratenanpassung aus.
* Worker GPU Timing V1 misst nur den Rasterabschnitt. Cross-Adapter-Transfer und Primary-SafeCopy fehlen noch im Kostenmodell.
* 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.
* QueueProbe und private native Queues bleiben Diagnosepfade; Experimental/Direct ist noch nicht implementiert.
* 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.
* Linux/Vulkan mit getrennten Devices, External Memory und externer Synchronisation ist noch nicht implementiert.

== Roadmap ==

# Cross-Adapter Transfer Timing V1: Worker-ColorTarget → Shared Buffer separat messen.
# Primary SafeCopy Timing ergänzen und die Integrationskosten getrennt halten.
# Kostenmodell V1 aus Worker-Raster, Transfer und Primary-Integration pro Workload ableiten.
# Weitere echte Workload-Klassen wie CCTV, Spiegel, Minimap und Compute anbinden; später Post Process oder neuronale Aufgaben untersuchen.
# D3D12-Pfade mit Intel Arc A750/A380 und RX 6900 XT in unterschiedlichen Primary-/Worker-Rollen gegenprüfen.
# Scheduler und Autotuner auf GPU-Eignung und gemessene Nettokosten statt Auslastungsprozent aufbauen.
# Material-, Textur- und Culling-Pfade für realistischere Worker-Szenen ergänzen.
# Skeletal Skinning mit Bone-Matrizen und Skin Weights erst bei einem echten animierten Worker-Workload ausbauen.
# 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 ==

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 ==

* 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/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://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://www.intel.com/content/dam/develop/external/us/en/documents/multi-adapter-support-in-directx-12-594015.pdf Intel: Multi-Adapter Support in DirectX 12]
* [https://devblogs.microsoft.com/directx/ashes-of-the-singularity-makes-gaming-history-with-directx-12/ Microsoft: Ashes of the Singularity und heterogene Adapter]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/nvidia-sli-alternative-frame-rendering-in-unreal-engine Epic: NVIDIA SLI Alternate Frame Rendering]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/multi-process-rendering-with-unreal-engine Epic: Multi-Process Rendering]
* [https://registry.khronos.org/vulkan/specs/latest/pdf/vkspec.pdf Khronos: Vulkan Specification – Device Groups]

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Multi-GPU]]
[[Kategorie:Direct3D 12]]
[[Kategorie:Experimentell]]

UE5 Heterogeneous Multi-GPU

2026-09-14T18:24:56Z

Elaina: Befehlsreferenz um ListWorkloads ergänzt und gestrafft

{{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.}}

'''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.

{| class="wikitable"
|+ Projektstatus
|-
! Engine / Plattform
| Unreal Engine 5.8 Source Build / Windows / Direct3D 12
|-
! Testsystem
| Lenovo LOQ 17IRX10
|-
! Primary
| NVIDIA GeForce RTX 5060 Laptop GPU
|-
! Worker
| Intel UHD Graphics
|-
! Zusätzliche Testhardware
| Intel Arc A750 und Arc A380 als zusätzliche dGPU-Worker-Gegenchecks vorgesehen; belastbare Messwerte liegen noch nicht vor
|-
! 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
|-
! 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
|-
! Gesamtvision
| etwa 30–35 % (Scheduler, echte Workloads, N-GPU und Vulkan noch offen)
|}

== Grundprinzip ==

<pre>
Intel Worker GPU
-> MainTextureCS + PatternPhase
-> persistente Worker-Textur
-> persistenter Shared Cross-Adapter Buffer
-> monotone Shared Fence / Queue Wait
-> persistente UE-eigene FTextureRHIRef
-> stabile UExperimentalMultiGPUTexture

RTX Primary GPU
-> normales UE5-Rendering
-> TPS-Material zeigt das Worker-Ergebnis sichtbar an
</pre>

Pro Worker ist maximal ein Runtime-Job gleichzeitig in flight. Backpressure lehnt weitere Requests als <code>Busy</code> ab, bis der Slot nach der Primary-Completion wieder sicher verwendbar ist.

Jeder Worker besitzt ein eigenes <code>ID3D12Device</code>, eigene Queues, Command Lists und Ressourcen. Ein späterer Scheduler soll Rechenleistung, Fähigkeiten, Transferkosten und gewünschte Aktualisierungsrate bewerten. Vorgesehene Aufgaben sind beispielsweise SceneCapture2D, Spiegel, CCTV, Minimap, Compute oder Niagara.

== Verifizierter Entwicklungsstand ==

=== Worker-Compute ===

Ein echter, von Unreal kompilierter Global Compute Shader läuft auf der Intel UHD, während Unreal regulär über die RTX rendert. Der Test verdoppelt 64 Ganzzahlen auf dem Worker; '''64 von 64 Ergebnissen wurden korrekt verifiziert'''. Damit ist echte GPU-Arbeit auf einem zweiten, herstellerfremden Device nachgewiesen.

Zusätzlich läuft <code>MainTextureCS</code> auf der Intel-GPU. Der synchrone Debugtest erzeugt eine 64 × 64 Pixel große RGBA8-Textur; '''alle 4096 shader-generierten Pixel wurden korrekt verifiziert'''. Der normale Runtime-Pfad verwendet inzwischen einen asynchronen 128×96-Test. Der Shader liest seine Dimensionen mit <code>GetDimensions()</code>, schützt überhängende Threads durch einen Bounds-Check und wird mit <code>Dispatch(16,12,1)</code> ausgeführt. <code>PatternPhase</code> erzeugt für jeden akzeptierten Submit deterministisch einen neuen sichtbaren Inhalt. Abgewiesene Busy-Requests erhöhen die Phase nicht und erzeugen daher keine Lücken.

=== Cross-Adapter-Speicher und Synchronisation ===

* RTX und Intel öffnen denselben D3D12 Cross-Adapter Heap.
* Ein gemeinsamer Buffer wurde mit 64 Testwerten erfolgreich geprüft.
* Ein persistenter Shared Fence synchronisiert die Queues direkt von GPU zu GPU. Seine Werte steigen pro Job monoton: WorkerReady/PrimaryComplete verwenden die Paare 1/2, 3/4, 5/6 und so weiter.
* Die CPU vermittelt die GPU-Abhängigkeit nicht; Worker- und Primary-Queue verwenden <code>Signal</code> und <code>Wait</code> direkt auf der GPU.
* Der separate Readback-Verifikationstest darf weiterhin blockieren. Der normale Runtime-Pfad wartet dagegen nicht auf GPU-Leerlauf.

=== Texturtransport ===

Direkte Cross-Adapter-Texturen sind auf dem Testsystem nicht beidseitig verfügbar: Die Intel UHD meldet Unterstützung für Row-Major Cross-Adapter Textures, die RTX 5060 Laptop GPU nicht. Deshalb verwendet das Projekt einen allgemeineren Buffer-Fallback.

<pre>
Intel MainTextureCS
-> persistente Worker-Textur
-> CopyTextureRegion
-> persistenter Shared Cross-Adapter Buffer
-> Worker signalisiert WorkerReady (1, 3, 5, ...)
-> UE-Primary-Queue wartet auf WorkerReady
-> direkte Kopie in persistente UE-eigene FTextureRHIRef
-> Primary signalisiert PrimaryComplete (2, 4, 6, ...)
</pre>

Der robuste Normal-Pfad kopiert die Worker-Textur über den Shared Buffer direkt in eine von Unreal erzeugte <code>FTextureRHIRef</code>. Breite, Höhe und Row Pitch werden dynamisch aus Worker-Ressource und Transport-Metadaten übernommen. Der erfolgreiche 128×96-RGBA8-Test verwendet 512 Byte Row Pitch und 49.152 Byte Transfergröße. Die Output Registry trennt Persistent-, Pending- und Ready-Zustände sowie Inhaltsgeneration und Texturidentität. Dadurch kann eine verspätete Completion keinen neueren Output zurückrollen.

=== Non-blocking Runtime-Pfad ===

Die produktive Testlogik ist aus dem Konsolenkommando in eine gekapselte NormalPath-API verschoben. <code>SubmitWorkerTextureComputeJob()</code> reicht den Worker-Dispatch ohne CPU-Wait ein. <code>QueueNormalTextureTransfer()</code> reiht Wait, Kopie und Completion-Signal in Unreals D3D12-Kontext ein. Der normale MainTextureCS-Pfad enthält weder CPU-Fence-Waits noch Readback, <code>Map</code> oder Pixelvergleich. <code>TickNormalTextureTransfers()</code> prüft die Primary-Completion non-blocking über einen Runtime-Pump; <code>RHIEndFrame()</code> bleibt als Fallback erhalten.

Eine passende Primary-<code>FTextureRHIRef</code> wird pro Worker und Konfiguration persistent gehalten. Nach PrimaryComplete kann der nächste Job dieselbe Resource erneut verwenden; dabei führt Unreal die Übergänge <code>SRVMask -> CopyDest -> SRVMask</code> aus. Eine backend-neutrale RHI-Provider-API reicht die Ready-Textur an die Engine weiter. <code>UExperimentalMultiGPUTexture</code> hält eine stabile <code>UTexture</code> samt TextureReference und bindet die persistente <code>FTextureRHIRef</code> ohne zusätzlichen Pixel-Copy. Eine native D3D12-Resource wird weiterhin nicht blind als UE-Textur gewrappt, weil Unreals Resource-State-Buchhaltung den tatsächlichen nativen Zustand sonst nicht sicher kennt.

=== Sichtbarer TPS-Consumer ===

<code>AExperimentalMultiGPUDisplayActor</code> zeigt die Worker-Ausgabe im Third-Person-Testlevel über den Materialparameter <code>MultiGPUTexture</code> an. Damit ist der Output nicht mehr nur über Logs oder Readback nachgewiesen: Die Intel UHD erzeugt fortlaufend die Texturinhalte, während die RTX die Spielwelt und das Material rendert. <code>TextureConsumerCS</code> kann Ready-Ausgaben auf der Primary zusätzlich als SRV lesen und fünf quantisierte Samples im Debugpfad prüfen.

=== Lebensdauer und automatisches Cleanup ===

Der Normal-Pfad verwendet pro Worker genau einen persistenten Runtime-Slot. Worker-Textur, Root Signature, PSO, Descriptor Heap, Command Allocator/List und Worker-Fence werden nach der ersten kompatiblen Initialisierung wiederverwendet. Dasselbe gilt für Shared Heap/Buffer/Fence und die Transport-Command-Objekte. Der In-Flight-Job trägt nur noch die nötigen Job-, Generation- und Fence-Metadaten.

<pre>
Runtime Request
-> Completion non-blocking prüfen
-> falls Slot frei: Worker Dispatch
-> WorkerReady-Fence signalisieren
-> Primary Wait, SafeCopy und PrimaryComplete-Signal
-> Output Pending
-> Runtime-Pump oder RHIEndFrame prüft GetCompletedValue()
-> Output Ready publizieren
-> Slot wiederverwendbar
</pre>

Backpressure erlaubt maximal einen echten In-Flight-Job pro Worker. Ein Busy-Request setzt keine GPU-Arbeit ab, setzt keine Ressourcen zurück und erhöht <code>PatternPhase</code> nicht. Worker-Fence-Werte steigen mit jedem akzeptierten Submit 1, 2, 3 und so weiter; der persistente Shared Fence verwendet fortlaufend die Paare 1/2, 3/4, 5/6. Fehler nach Übergabe von Ressourcen an die GPU führen zu sicherem Retire beziehungsweise Retention statt zu vorzeitigem Reuse.

=== Texture Stream und Benchmarking ===

Der projektseitige Texture Stream akzeptiert eine beliebige positive, endliche Zielrate. Punkt und Komma sind als Dezimaltrenner möglich. Optional lässt sich die Zahl erfolgreicher Submits begrenzen; Busy- oder Failed-Versuche verbrauchen dieses Limit nicht. Der Quiet-Modus unterdrückt per-Job-Ausgaben, behält aber Start, echte Fehler und die Abschlussstatistik bei.

Die Statistik unterscheidet Timer-Ticks, angenommene Submits, Busy/Failed, Ready, In-Flight und die jeweiligen effektiven Raten. Diagnosezeitpunkte erfassen unter anderem RequestAccepted, RenderCommandExecution, WorkerSubmit, NormalTransferQueued und ReadyObserved.

{| class="wikitable"
! Test
! Ergebnis
! Aussage
|-
| 5 Hz, 20 Submits
| etwa 5 Ready/s, 20/20, kein Busy
| Entspannter Single-Slot-Betrieb
|-
| 1000 Hz, 100 Submits, quiet
| 100/100 Ready, 0 Fehler, etwa 58 Ready/s
| Backpressure begrenzt den Durchsatz sicher
|-
| 1000 Hz bei <code>t.MaxFPS 30</code>
| etwa 28–29 Ready/s trotz rund 982 Timer-Ticks/s
| Primary-/SafeCopy-/Ready-Kette ist effektiv framegekoppelt
|}

Ein zusätzlicher non-blocking Aufruf von <code>ImmediateFlush(DispatchToRHIThread)</code> erreicht hohe Render-Command-Raten, hebt die gemessene Frame-Kopplung aber nicht auf. Im 30-FPS-Test lag der RHIEndFrame-spezifische Completion-Takt praktisch exakt bei 30 Hz. Das aktuelle Problem ist damit eingegrenzt: Nicht der Stream-Timer, sondern die Primary-RHI-/D3D12-Submission der SafeCopy-Kette bestimmt die sichtbare Ready-Rate.

=== Queue-Submission-Diagnose ===

<code>MultiGPUD3D12QueueProbe</code> untersucht die Submission unabhängig vom sichtbaren Texturpfad. Neben <code>full</code>, <code>waitonly</code> und <code>signalonly</code> existieren inzwischen die Diagnosemodi <code>computeonly</code>, <code>commandonly</code>, <code>barrieronly</code>, <code>barrierprivate</code> und <code>copybuffer</code>. Als Queues stehen <code>graphics</code>, <code>copy</code>, <code>native</code>, <code>worker</code>, <code>worker-copy</code> und <code>worker-high</code> zur Verfügung. Graphics und Copy verwenden <code>RHIRunOnQueue(..., false)</code> auf UE-verwalteten Primary-Queues; die übrigen Varianten isolieren private beziehungsweise bereits vorhandene native D3D12-Queues.

Der Probe misst Request, Worker-Submit, <code>RHIRunOnQueue</code>-Aufruf und -Callback, Primary-Execute, Fence-Completion sowie Ready bis zum nächsten akzeptierten Submit. Er fügt keine CPU-Waits, Readbacks, Maps oder <code>BlockUntilGPUIdle</code> ein und beschreibt keine Textur des sichtbaren Normal-Pfads.

{| class="wikitable"
! Test
! Ergebnis
! Befund
|-
| UE Graphics, signal-only, 30 FPS
| 33,319 ms PrimaryExecute bis Ready
| UE-verwaltete Graphics-Submission skaliert mit der Frame-Dauer
|-
| UE Copy, signal-only, 30 FPS
| 32,593 ms PrimaryExecute bis Ready
| Auch die UE-verwaltete Copy Queue ist framegekoppelt
|-
| Private Primary-DIRECT-Queue, signal-only
| etwa 0,014 ms Queue/Fence-Latenz; nach Lifecycle-Fix rund 999 Ready/s bei 30 FPS
| Native Queue und Scheduler sind vollständig vom Frame entkoppelt
|-
| Worker signal-only / leere Command List
| jeweils rund 1000 Ready/s bei 30 FPS
| Worker-Queue, Fence und reine Submission sind nicht framegekoppelt
|-
| Worker <code>CopyBufferRegion</code>, 30 / 60 / 120 FPS
| 29,41 / 58,25 / 113,08 Ready/s
| Bereits eine echte 256-Byte-GPU-Kopie folgt im UE-Prozess dem Frame-Raster
|-
| Worker COPY Queue / HIGH Priority, 30 FPS
| jeweils rund 29,42 Ready/s
| Queue-Typ und Priorität beseitigen die Kopplung nicht
|-
| Standalone-D3D12 auf derselben Intel UHD
| 92.956 Copy-Jobs/s; 0,007 ms durchschnittliche Fence-Latenz
| Die Kopplung ist UE-Prozess-/Scheduling-spezifisch, keine allgemeine Intel-, WDDM- oder D3D12-Grenze
|}

Der <code>RHIRunOnQueue</code>-Callback selbst erreicht den D3D12-Submission-Thread typischerweise bereits nach etwa 0,02–0,05 ms; die Verzögerung entsteht danach in der verwalteten Queue-/Submission-Reihenfolge. <code>SubmitCommandsHint()</code> ist in UE 5.8 nur ein veralteter Alias für <code>ImmediateFlush(DispatchToRHIThread)</code> und stellt daher keinen stärkeren Submission-Mechanismus dar.

Der native Test ist ein '''Architekturbeweis, noch kein Experimental- oder Direct-Modus'''. Die zunächst gemessene Verzögerung von rund 32 ms lag zwischen der In-Flight-Freigabe und dem nächsten Request auf dem Render Thread. Für <code>signalonly/native</code> wurde der sichere Completion-/Submit-Lifecycle deshalb in den frameunabhängigen Scheduler verlegt. Danach erreichten zwei 100-Job-Läufe bei <code>t.MaxFPS 30</code> rund 999 bis 1029 Ready/s, ohne Busy oder Fehler.

Der anschließende <code>full native</code>-Test lokalisierte die verbleibende Kopplung auf echte Worker-GPU-Arbeit: WorkerSubmit bis WorkerReady benötigte bei 30, 60 und 120 FPS ungefähr 33,29, 16,93 und 8,45 ms; WorkerReady bis PrimaryReady war danach praktisch sofort. Signal-only und eine leere Command List waren schnell, Resource Barriers und eine 256-Byte-Kopie dagegen framegebunden. Ein eigenständiger D3D12-Microbenchmark auf derselben Intel UHD erreichte außerhalb von Unreal bei derselben Kopie rund 92.956 Jobs/s mit 0,007 ms mittlerer Fence-Latenz. Die genaue Ursache im UE-Prozess beziehungsweise dessen GPU-Scheduling-Kontext bleibt offen und wird vorerst bis zum Gegencheck mit der vorhandenen Intel Arc A380 geparkt.

=== Worker-Rasterpfad und RasterStream ===

<code>ExperimentalMultiGPU.TestRasterWorker</code> weist erstmals echte Rasterizer-Arbeit auf der Intel-Worker-GPU nach. <code>RasterWorkerVS</code> und <code>RasterWorkerPS</code> werden über Unreals Global-Shader-Pfad kompiliert und für ein natives Worker-Graphics-PSO verwendet. Ein persistentes 128×96-RGBA8-RenderTarget besitzt RTV, leere Root Signature und eine DIRECT-Command-List. Der Vertex Shader erzeugt drei Vertices über <code>SV_VertexID</code>; der Pixel Shader schreibt interpolierte RGB-Farben.

Der Job wechselt das RenderTarget von <code>COPY_SOURCE</code> nach <code>RENDER_TARGET</code>, führt Clear und <code>DrawInstanced(3,1,0,0)</code> aus und wechselt anschließend zurück nach <code>COPY_SOURCE</code>. Danach verwendet er unverändert den robusten Normalpfad aus Cross-Adapter-Shared-Buffer, Primary SafeCopy, persistenter <code>FTextureRHIRef</code>, <code>UExperimentalMultiGPUTexture</code> und DisplayActor. Der Runtime-Test meldete einen akzeptierten Submit und <code>RasterWorker READY</code> für Generation 1; die 128×96-UTexture wurde erfolgreich gebunden.

Der einmalige Test wurde außerdem zu einem frei konfigurierbaren RasterStream ausgebaut. Ein sichtbarer Lauf mit 10 Hz und 50 erfolgreichen Submits endete mit 50 Ready-Ausgaben, 0 Busy und 0 Fehlern bei etwa 9,90 Ready/s. Primary-Textur und Materialbindung blieben dabei persistent.

=== Raster3D mit echten Vertex- und Indexbuffern ===

Der Worker besitzt inzwischen einen kleinen eigenständigen 3D-Rasterpfad mit perspektivischer Kamera, Model-View-Projection-Matrix als Root Constants, D32_FLOAT-Depth-Buffer und Depth-Test. Der finale Testwürfel verwendet 24 POSITION/COLOR-Vertices, 36 <code>uint16</code>-Indices und <code>DrawIndexedInstanced(36,1,0,0,0)</code>; sechs getrennte Seitenfarben machen Ausrichtung und Rotation sichtbar nachvollziehbar.

Die statischen Meshdaten werden einmalig über private Upload-Buffer in DEFAULT-Heaps übertragen. Der Init-Fence wird non-blocking über <code>GetCompletedValue()</code> beobachtet. Der eigentliche Runtime-Renderpfad enthält weiterhin keine CPU-Waits und keine Maps.

=== UE-Static-Meshes auf der Worker-GPU ===

<code>StaticMeshWorker</code> extrahiert echte LOD0-Geometrie aus <code>UStaticMesh</code>-Assets. POSITION und NORMAL sowie <code>uint32</code>-Indices werden in POD-Daten überführt, einmalig asynchron in eigene Worker-VB/IB hochgeladen und anschließend per <code>DrawIndexedInstanced</code> gerendert. Assetpfade sind dynamisch; Auto-Fit richtet Kamera beziehungsweise Modellmaßstab an den Bounds aus.

Sichtbar korrekt getestet wurden:

{| class="wikitable"
! Asset
! Vertices
! Indices
|-
| Sphere
| 559
| 2880
|-
| Cube
| 54
| 144
|-
| Cylinder
| 334
| 1536
|}

=== Multi-Mesh Worker-Szene ===

<code>StaticMeshScene</code> rendert Sphere, Cube und Cylinder gemeinsam in einen Color-/Depth-Frame. Der verifizierte Test umfasst insgesamt 947 Vertices und 4560 Indices, drei <code>DrawIndexedInstanced</code>-Aufrufe und nur einen anschließenden Cross-Adapter-/Normal-SafeCopy-Transfer. Damit ist nicht mehr nur ein synthetisches Primitive, sondern mehrere echte UE-Meshes mit gemeinsamer Tiefenprüfung im Worker-Frame sichtbar nachgewiesen.

=== WorldStaticMeshScene ===

<code>ExperimentalMultiGPUWorldStaticMeshScene.cpp</code> sammelt im Engine-Layer bis zu acht sichtbare <code>UStaticMeshComponent</code>s von Actors mit dem Tag <code>MultiGPUWorker</code>. Meshdaten und World-Transforms werden im Game Thread in reine POD-Strukturen und 4×4-Matrizen kopiert. D3D12RHI erhält keine <code>UObject</code>-Pointer. Mehrere Instanzen desselben Meshes teilen den persistenten Worker-Mesh-Cache und unterscheiden sich nur durch Modelmatrix und Draw Call.

Der Pfad wurde inzwischen sichtbar im PIE-Level verifiziert. Drei getaggte Static-Mesh-Actors erschienen mit ihren tatsächlichen relativen Positionen, Rotationen und Skalierungen im Worker-Bild. Die zentrale Koordinatenumrechnung lautet:

<pre>Worker (X, Y, Z) = (UE Y, UE X, -UE Z)</pre>

Die Transformation besitzt die Determinante +1 und ist damit keine Spiegelung. Das notwendige horizontale Spiegeln erfolgt ausschließlich auf der Presentation-Plane, nicht im Worker-Renderpfad.

=== Kontinuierlicher WorldStaticMeshSceneStream ===

<code>StartWorldStaticMeshSceneStream</code> erfasst die getaggte Szene fortlaufend im Game Thread. Reine Änderungen an Transform oder Kamera lösen keinen erneuten Mesh-Upload aus. Hinzugekommene, entfernte, unsichtbare oder umgetaggte Components werden im nächsten Snapshot berücksichtigt. Single-Slot-Backpressure verhindert einen wachsenden Rückstau.

Ein verifizierter 30-Hz-Lauf endete nach 31,184 Sekunden mit 835 Ticks, 691 angenommenen Submits, 144 Busy, 0 Fehlern und 691 Ready-Frames. Die effektive Ready-Rate betrug 22,16 Hz. Dieser Test belegt die funktionale Live-Aktualisierung; die Rate war noch kein Optimierungsziel.

=== SceneCapture2D als Worker-Kamera ===

<code>TestSceneCaptureStaticMeshScene</code> verwendet eine echte <code>ASceneCapture2D</code> beziehungsweise <code>USceneCaptureComponent2D</code> aus der laufenden PIE-Welt als Kameraquelle. Der empfohlene Editor-Weg ist das Component Tag <code>MultiGPUWorkerCamera</code> auf der <code>CaptureComponent2D</code>; ein gleichnamiges Actor-Tag bleibt nur als Legacy-Fallback.

Ausgelesen werden World Location, Rotation, Forward/Right/Up, <code>FOVAngle</code> und <code>ProjectionType</code>. Orthografische Projektion wird derzeit sauber abgelehnt. Die SceneCapture2D liefert ausschließlich Kameradaten: Ihr UE-RenderTarget wird weder gelesen noch kopiert. Die Intel-Worker-GPU rendert die Geometrie selbst. Kamera und Actors werden gemeinsam mit <code>SceneScale = 0.01</code> in Worker-Koordinaten überführt; Auto-Fit und Scene-Recentering sind in diesem Modus deaktiviert.

Die 128×96-Worker-Projektion verwendet ein Seitenverhältnis von 4:3 und interpretiert <code>FOVAngle</code> als horizontales FOV. Nach den Orientierungstests wird nur die Anzeige über <code>SetRelativeScale3D(FVector(-4.0f, -3.0f, 1.0f))</code> korrigiert; dies entspricht <code>U' = 1-U</code> und <code>V' = 1-V</code>.

=== Live SceneCaptureStaticMeshSceneStream ===

<code>StartSceneCaptureStaticMeshSceneStream</code> liest Kamera-Transform, Kamerabasis, FOV und aktuelle Actor-Transforms pro Snapshot neu im Game Thread. Der Worker erhält weiterhin ausschließlich POD-Daten, verwendet den persistenten Mesh-Cache sowie ein gemeinsames Color- und D32-Depth-Target und führt pro akzeptiertem Frame genau einen Cross-Adapter-/Normal-SafeCopy-Transfer aus.

Der Quiet-Test

<pre>ExperimentalMultiGPU.StartSceneCaptureStaticMeshSceneStream 30 300 quiet</pre>

lieferte in 10,084 Sekunden 301 Ticks, 300 Submits, 1 Busy, 0 Fehler und 300 Ready-Frames. Die effektive Ready-Rate betrug 29,75 Hz. Bewegungen der Kamera und Actors sowie FOV-Änderungen erschienen live auf der Display-Plane. Damit ist erstmals ein kleiner SceneCapture-/CCTV-artiger Worker-Kanal vollständig funktional nachgewiesen.

=== Dynamische SceneCapture-Auflösung ===

Die SceneCapture-Ausgabe ist nicht mehr fest auf 128×96 Pixel begrenzt. <code>ExperimentalMultiGPU.SetSceneCaptureResolution <Width> <Height></code> setzt ganzzahlige Dimensionen von 1 bis 4096; <code>GetSceneCaptureResolution</code> zeigt die aktive Einstellung. 128×96 bleibt der Standard. Während ein SceneCapture-Stream läuft, wird ein Auflösungswechsel absichtlich abgelehnt, damit keine In-Flight-Ressourcen ausgetauscht werden.

Color Target, D32-Depth-Buffer, Row Pitch, Shared-Buffer-Transport, SafeCopy, persistente Primary-Textur und <code>UExperimentalMultiGPUTexture</code> übernehmen die gewählten Dimensionen. Projektion und Display-Plane verwenden das echte Seitenverhältnis. Die bestätigte Anzeigeorientierung <code>U' = 1-U</code> und <code>V' = 1-V</code> bleibt eine reine Presentation-Korrektur; Worker-Basis und Kameramathematik ändern sich nicht.

=== Scheduler-Korrektur bei SceneCapture ===

Ein 1920×1080-Test mit 25 Hz erreichte zunächst trotz fehlerfreier Frames nur 13,90 Ready-Hz und erzeugte 222 Busy-Ticks. Ursache war kein GPU-Limit, sondern ein Polling-Aliasing: Eine frühe Game-Thread-Prüfung konnte den Timer-Slot verwerfen, obwohl die Completion kurz darauf im CoreTicker/RHI-Pump sichtbar geworden wäre.

Die frühe <code>IsRuntimeTextureUpdateInFlight()</code>-Prüfung wurde für diesen Stream entfernt. Der Pending-Request bleibt als Backpressure-Gate erhalten; die maßgebliche Busy-Entscheidung fällt nun erst im Render Command nach <code>TickNormalTextureTransfers(nullptr, true)</code>. Single-Slot, POD-Snapshots und non-blocking <code>GetCompletedValue()</code> bleiben erhalten. Es wurden weder CPU-Waits noch zusätzliche Threads eingeführt.

Nach der Korrektur erreicht 1080p bei 25 Hz 24,79 Ready-Hz mit 1 Busy; bei 30 Hz sind es 29,43 Ready-Hz mit 4 Busy.

=== Skalierung bis 4K60 ===

Die Pipeline wurde von 640×360 bis 3840×2160 getestet. Bei 640×360/30 Hz und 1280×720/30 Hz wurden 29,85 beziehungsweise 29,82 Ready-Hz ohne Busy erreicht. 1920×1080/60 Hz lieferte 59,40 Ready-Hz ohne Busy, 2560×1440/60 Hz 59,21 Ready-Hz mit 1 Busy und 3840×2160/60 Hz 59,02 Ready-Hz mit 2 Busy.

Ein zusätzlicher 4K60-Stresstest mit acht Static-Mesh-Instanzen und drei gecachten Unique Meshes erreichte in 5,049 Sekunden '''300 von 300 Ready-Frames, 0 Busy, 0 Fehler und 59,42 effektive Ready-Hz'''. Acht Draw Calls, gemeinsamer Depth Buffer, Cross-Adapter-Transport und SafeCopy liefen dabei im vorhandenen Single-Slot. Das ist ein Stabilitätsnachweis der aktuellen Mini-Szene, kein allgemeiner GPU-Benchmark.

=== Skeletal Mesh in Reference Pose ===

<code>ExperimentalMultiGPU.TestSkeletalMeshWorker</code> erweitert den Geometriepfad auf <code>USkeletalMeshComponent</code>. Der Engine-Layer sucht deterministisch die erste sichtbare, getaggte Komponente und extrahiert LOD0-Positionen, Normalen, Indices und Render Sections. D3D12RHI erhält wie bisher ausschließlich POD-Geometrie und Modelmatrizen.

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.

== Test- und Diagnosebefehle ==

Die vorhandenen Compute-, Texture-, Raster-, StaticMesh-, World- und QueueProbe-Kommandos bleiben bestehen. Neu hinzugekommen ist:

{| class="wikitable"
! Befehl
! Zweck
|-
| <code>ExperimentalMultiGPU.ListWorkloads</code>
| Listet aktive Workloads mit ID, Typ, gewünschter Zuweisung, Priorität, Auflösung, Zielrate, Lifecycle-Statistik und Worker-GPU-Timing auf.
|}

Für den aktuellen Hauptpfad sind außerdem besonders relevant:

<pre>
ExperimentalMultiGPU.SetSceneCaptureResolution <Width> <Height>
ExperimentalMultiGPU.GetSceneCaptureResolution
ExperimentalMultiGPU.TestSceneCaptureStaticMeshScene
ExperimentalMultiGPU.StartSceneCaptureStaticMeshSceneStream [Hz] [MaxSuccessfulSubmits] [quiet]
ExperimentalMultiGPU.StopSceneCaptureStaticMeshSceneStream
ExperimentalMultiGPU.TestSkeletalMeshWorker
ExperimentalMultiGPU.ListWorkloads
</pre>

=== Texture Stream ===

Grundsyntax:

<pre>ExperimentalMultiGPU.StartTextureStream [Hz] [MaxSuccessfulSubmits] [quiet]</pre>

Die Hz-Angabe ist eine Ziel- beziehungsweise Request-Frequenz. <code>MaxSuccessfulSubmits</code> zählt nur angenommene Submits; Busy- und Failed-Versuche verbrauchen das Limit nicht. <code>quiet</code> unterdrückt Per-Job- und Busy-Logspam.

=== QueueProbe ===

Grundsyntax:

<pre>ExperimentalMultiGPU.StartQueueProbe <Hz> <MaxSubmits> [quiet] <Mode> <Queue></pre>

Die Diagnosemodi <code>full</code>, <code>waitonly</code>, <code>signalonly</code>, <code>commandonly</code>, <code>barrieronly</code>, <code>barrierprivate</code> und <code>copybuffer</code> bleiben verfügbar. Als Queue können <code>graphics</code>, <code>copy</code>, <code>native</code>, <code>worker</code>, <code>worker-copy</code> und <code>worker-high</code> gewählt werden. Private native Queues dienen weiterhin nur der Diagnose und bilden keinen fertigen Experimental-/Direct-Modus.

=== Benchmark-CVars ===

<code>r.VSync 0</code> deaktiviert VSync. <code>t.MaxFPS 30</code>, <code>60</code> oder <code>120</code> erzeugt reproduzierbare Frame-Coupling-Tests; <code>t.MaxFPS 0</code> entfernt das normale Framerate-Limit.

== Aktueller nächster Schritt ==

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 ==

Die Grundidee heterogener Multi-GPU-Nutzung ist nicht neu. Bereits mit der Einführung von Direct3D 12 entstanden mehrere Versuche, integrierte und dedizierte GPUs gemeinsam zu verwenden. Eine allgemein einsetzbare Lösung für moderne UE5-Spiele hat sich daraus jedoch nicht entwickelt.

=== Microsoft und Epic: UE4 Elemental Demo (2015) ===

Microsoft zeigte eine angepasste Unreal-Engine-4-Version der Elemental-Demo, bei der eine NVIDIA-GPU und eine Intel-iGPU gemeinsam arbeiteten. Das erklärte Ziel war, ansonsten ungenutzte Grafikleistung in Hybrid-Systemen zu verwenden. Dieser Versuch ist der Grundidee des Projekts besonders ähnlich, blieb aber eine technische Demonstration.

=== Intel: D3D12 Multi-Adapter Sample (2015) ===

Intels Beispiel kombinierte eine GeForce 840M mit Intel HD Graphics 5500. Beide GPUs berechneten getrennte Teile einer einfach parallelisierbaren Raytracing-Szene. Cross-Adapter-Ressourcen und Shared Fences führten die Ergebnisse anschließend zusammen. Intel berichtete in diesem Test von nahezu halbierter Framezeit, warnte jedoch ausdrücklich davor, das Ergebnis unmittelbar auf reale Spiele zu übertragen.

=== Ashes of the Singularity ===

Die Nitrous Engine von ''Ashes of the Singularity'' setzte Direct3D-12-Explicit-Multiadapter in einem veröffentlichten Spiel ein. Dabei konnten auch unterschiedliche GPU-Modelle und Hersteller zusammenarbeiten. Das war ein wichtiger Praxisnachweis, blieb in der Spielebranche aber eine seltene Ausnahme.

=== Weitere verwandte Ansätze ===

* ''Rise of the Tomb Raider'' erhielt explizite Direct3D-12-Multi-GPU-Unterstützung, vor allem für klassische Kombinationen ähnlicher GPUs.
* NVIDIA VR SLI wies bei Virtual Reality jeder GPU ein Auge zu. Das verteilt unabhängige Ansichten, bleibt jedoch NVIDIA-spezifisch.
* Unreal nDisplay kann Viewports oder Frustums auf weitere GPUs beziehungsweise Prozesse auslagern und das fertige Bild zur Ausgabe-GPU zurückführen. Der Einsatzbereich ist hauptsächlich Virtual Production.
* Forschung und High-Performance Computing verwenden seit Jahren Scheduler für heterogene GPUs, allerdings überwiegend für Compute- und Datenverarbeitungsaufgaben statt für einen allgemeinen UE5-Echtzeitrenderer.

=== Abgrenzung dieses Projekts ===

Das Projekt erfindet Direct3D-12-Explicit-Multiadapter nicht neu. Sein eigener Ansatz liegt in der Kombination aus tiefer UE5.8-RHI-Integration, UE-kompilierten Shadern auf unabhängigen Worker-Devices, frei wählbaren Spiel- und Compute-Workloads, Capability- und Performance-Scheduler, mehreren Fallback-Pfaden sowie dem langfristigen Ziel beliebiger Hersteller und mehrerer Worker.

== Vergleich mit anderen Multi-GPU-Verfahren ==

{| class="wikitable"
! Verfahren
! Arbeitsweise
! Verhältnis zu diesem Projekt
|-
| SLI / CrossFire
| Treiber- beziehungsweise Verbundlösung für meist ähnliche GPUs; häufig wird die Bildarbeit verteilt.
| Dieses Projekt benötigt keinen herstellerspezifischen GPU-Verbund und weist Aufgaben ausdrücklich selbst zu.
|-
| AFR (Alternate Frame Rendering)
| GPU 1 rendert einen Frame, GPU 2 den nächsten.
| Das Projekt verteilt unabhängige Aufgaben statt aufeinanderfolgender Frames. Dadurch werden Frame-Abhängigkeiten und typisches AFR-Pacing vermieden.
|-
| SFR (Split Frame Rendering)
| Mehrere GPUs bearbeiten Bereiche desselben Frames.
| Erfordert enge Lastverteilung und viel Datenaustausch. Das Projekt bevorzugt vollständig abgrenzbare Workloads und überträgt deren Ergebnis.
|-
| Direct3D 12 Linked Multiadapter
| Mehrere vom Treiber verbundene GPUs erscheinen als Knoten eines logischen Adapters.
| Eignet sich eher für eng kompatible GPUs. Das Projekt verwendet unabhängige Devices (Unlinked/Explicit Multiadapter) und unterstützt dadurch heterogene Herstellerkombinationen.
|-
| Direct3D 12 Unlinked / Explicit Multiadapter
| Die Anwendung verwaltet getrennte Adapter, Ressourcen und Synchronisation selbst.
| Das ist die technische Familie des Projekts. Hinzu kommen die eigene UE5-RHI-Integration, Workload-Ziele, Fallbacks und der geplante Scheduler.
|-
| UE nDisplay mGPU / Multi-Process
| Separate GPUs rendern bestimmte Viewports oder Frustums, vor allem für Virtual Production; Ergebnisse werden zur Ausgabe-GPU kopiert.
| Ähnliche Idee der aufgabenweisen Trennung, aber für einen anderen Einsatzbereich. Dieses Projekt zielt auf allgemeine Spiel- und Compute-Workloads innerhalb der Engine.
|-
| Vulkan Device Groups
| Ähnliche physische GPUs können ein gemeinsames logisches Device bilden.
| Für beliebige heterogene GPUs meist ungeeignet, da Geräte einer Gruppe nahezu gleiche Eigenschaften besitzen müssen. Eine spätere Vulkan-Portierung benötigt daher wahrscheinlich getrennte Devices und External Memory/Semaphores.
|}

SLI und CrossFire bezeichnen den Verbund; AFR und SFR beschreiben mögliche Verteilungsmethoden innerhalb solcher Systeme. Sie sind deshalb nicht vollständig getrennte Kategorien.

== Vorteile der geplanten Variante ==

* '''Herstellerunabhängig:''' NVIDIA, AMD und Intel können grundsätzlich kombiniert werden.
* '''Vorhandene Hardware nutzen:''' Auch eine sonst wenig genutzte integrierte GPU kann geeignete Nebenaufgaben übernehmen.
* '''Aufgaben statt Frames verteilen:''' Spiegel, Minimap oder Compute können mit eigener Auflösung und Aktualisierungsrate laufen.
* '''Keine identischen GPUs erforderlich:''' Unterschiedliche Fähigkeiten können gezielt genutzt werden.
* '''Kontrollierter Datenaustausch:''' Nur das benötigte Ergebnis muss zurück zur Primary-GPU.
* '''Robuste Fallback-Idee:''' Wenn direkte Texturen nicht gemeinsam nutzbar sind, bleibt der Shared-Buffer-Pfad.
* '''Erweiterbar:''' Scheduler, manuelles Mapping und mehrere Worker sind als spätere Stufen vorgesehen.

== Nachteile und technische Risiken ==

* '''Hoher Entwicklungsaufwand:''' Geräte, Ressourcen, Zustände, Fences, Fehlerfälle und UE-Lebenszyklen müssen selbst verwaltet werden.
* '''Transfer kann den Gewinn aufzehren:''' Cross-Adapter Heaps liegen laut D3D12 nicht automatisch im schnellen lokalen VRAM. Bandbreite und Latenz müssen für jeden Workload gemessen werden.
* '''VRAM wird nicht einfach addiert:''' Benötigte Ressourcen können auf mehreren GPUs vorliegen und zusätzlichen Speicher verbrauchen.
* '''Langsame Worker können bremsen:''' Eine Aufgabe lohnt sich nur, wenn Rechengewinn größer als Übergabe-, Warte- und Kopierkosten ist.
* '''Nicht jeder Workload ist unabhängig:''' Hauptansicht, Lumen, Nanite und stark gekoppelte Renderpässe besitzen viele Abhängigkeiten und sind schwieriger auszulagern.
* '''Hardwareunterschiede:''' Formate, Shader-Funktionen, Queue-Fähigkeiten und Cross-Adapter-Support müssen pro GPU geprüft werden.
* '''Wartungsrisiko:''' Eingriffe in private D3D12RHI-Dateien können bei Engine-Updates angepasst werden müssen.
* '''Produktionsreife fehlt noch:''' Ressourcenpools, Timeouts, Device-Lost-Wiederherstellung, Scheduler und echte Szenentests sind offen.

== Wann die Variante sinnvoll ist ==

Am aussichtsreichsten sind Aufgaben mit viel eigener Rechenarbeit, einem relativ kleinen Endergebnis und wenigen Abhängigkeiten zur Hauptszene. Gute frühe Kandidaten sind unabhängige Compute-Aufgaben sowie Scene Captures, die nicht in jedem Frame aktualisiert werden müssen. Weniger geeignet sind winzige Aufgaben mit großem Transfer oder Renderpässe, die ständig auf Ressourcen der Primary-GPU zugreifen.

Die entscheidende Regel für den späteren Scheduler lautet daher:

<pre>
Worker-Gewinn > Vorbereitung + Datentransfer + Synchronisation + Rückintegration
</pre>

== Bekannte Grenzen des Proof of Concepts ==

* 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 sichtbarer Runtime-Slot. Mehrere parallele In-Flight-Jobs und Ringbuffer fehlen noch.
* Praktisch getestet ist Primary plus ein Worker. Mehrere Worker sind architektonisch vorgesehen, aber noch nicht praktisch validiert.
* World- und SceneCapture-Pfade verarbeiten pro Snapshot höchstens acht sichtbare <code>UStaticMeshComponent</code>s.
* 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.
* <code>USkeletalMesh</code> ist bislang ein LOD0-ReferencePose-Proof. Bone-Skinning, Animation, Morph Targets und Cloth fehlen.
* Die Workload-Registry sammelt Metadaten und Messwerte, führt aber noch keine automatische Zuweisung, Auflösungsänderung oder Ratenanpassung aus.
* Worker GPU Timing V1 misst nur den Rasterabschnitt. Cross-Adapter-Transfer und Primary-SafeCopy fehlen noch im Kostenmodell.
* 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.
* QueueProbe und private native Queues bleiben Diagnosepfade; Experimental/Direct ist noch nicht implementiert.
* 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.
* Linux/Vulkan mit getrennten Devices, External Memory und externer Synchronisation ist noch nicht implementiert.

== Roadmap ==

# Cross-Adapter Transfer Timing V1: Worker-ColorTarget → Shared Buffer separat messen.
# Primary SafeCopy Timing ergänzen und die Integrationskosten getrennt halten.
# Kostenmodell V1 aus Worker-Raster, Transfer und Primary-Integration pro Workload ableiten.
# Weitere echte Workload-Klassen wie CCTV, Spiegel, Minimap und Compute anbinden; später Post Process oder neuronale Aufgaben untersuchen.
# D3D12-Pfade mit Intel Arc A750/A380 und RX 6900 XT in unterschiedlichen Primary-/Worker-Rollen gegenprüfen.
# Scheduler und Autotuner auf GPU-Eignung und gemessene Nettokosten statt Auslastungsprozent aufbauen.
# Material-, Textur- und Culling-Pfade für realistischere Worker-Szenen ergänzen.
# Skeletal Skinning mit Bone-Matrizen und Skin Weights erst bei einem echten animierten Worker-Workload ausbauen.
# 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 ==

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 ==

* 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/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://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://www.intel.com/content/dam/develop/external/us/en/documents/multi-adapter-support-in-directx-12-594015.pdf Intel: Multi-Adapter Support in DirectX 12]
* [https://devblogs.microsoft.com/directx/ashes-of-the-singularity-makes-gaming-history-with-directx-12/ Microsoft: Ashes of the Singularity und heterogene Adapter]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/nvidia-sli-alternative-frame-rendering-in-unreal-engine Epic: NVIDIA SLI Alternate Frame Rendering]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/multi-process-rendering-with-unreal-engine Epic: Multi-Process Rendering]
* [https://registry.khronos.org/vulkan/specs/latest/pdf/vkspec.pdf Khronos: Vulkan Specification – Device Groups]

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Multi-GPU]]
[[Kategorie:Direct3D 12]]
[[Kategorie:Experimentell]]

UE5 Heterogeneous Multi-GPU

2026-09-14T18:24:51Z

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

{{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.}}

'''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.

{| class="wikitable"
|+ Projektstatus
|-
! Engine / Plattform
| Unreal Engine 5.8 Source Build / Windows / Direct3D 12
|-
! Testsystem
| Lenovo LOQ 17IRX10
|-
! Primary
| NVIDIA GeForce RTX 5060 Laptop GPU
|-
! Worker
| Intel UHD Graphics
|-
! Zusätzliche Testhardware
| Intel Arc A750 und Arc A380 als zusätzliche dGPU-Worker-Gegenchecks vorgesehen; belastbare Messwerte liegen noch nicht vor
|-
! 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
|-
! 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
|-
! Gesamtvision
| etwa 30–35 % (Scheduler, echte Workloads, N-GPU und Vulkan noch offen)
|}

== Grundprinzip ==

<pre>
Intel Worker GPU
-> MainTextureCS + PatternPhase
-> persistente Worker-Textur
-> persistenter Shared Cross-Adapter Buffer
-> monotone Shared Fence / Queue Wait
-> persistente UE-eigene FTextureRHIRef
-> stabile UExperimentalMultiGPUTexture

RTX Primary GPU
-> normales UE5-Rendering
-> TPS-Material zeigt das Worker-Ergebnis sichtbar an
</pre>

Pro Worker ist maximal ein Runtime-Job gleichzeitig in flight. Backpressure lehnt weitere Requests als <code>Busy</code> ab, bis der Slot nach der Primary-Completion wieder sicher verwendbar ist.

Jeder Worker besitzt ein eigenes <code>ID3D12Device</code>, eigene Queues, Command Lists und Ressourcen. Ein späterer Scheduler soll Rechenleistung, Fähigkeiten, Transferkosten und gewünschte Aktualisierungsrate bewerten. Vorgesehene Aufgaben sind beispielsweise SceneCapture2D, Spiegel, CCTV, Minimap, Compute oder Niagara.

== Verifizierter Entwicklungsstand ==

=== Worker-Compute ===

Ein echter, von Unreal kompilierter Global Compute Shader läuft auf der Intel UHD, während Unreal regulär über die RTX rendert. Der Test verdoppelt 64 Ganzzahlen auf dem Worker; '''64 von 64 Ergebnissen wurden korrekt verifiziert'''. Damit ist echte GPU-Arbeit auf einem zweiten, herstellerfremden Device nachgewiesen.

Zusätzlich läuft <code>MainTextureCS</code> auf der Intel-GPU. Der synchrone Debugtest erzeugt eine 64 × 64 Pixel große RGBA8-Textur; '''alle 4096 shader-generierten Pixel wurden korrekt verifiziert'''. Der normale Runtime-Pfad verwendet inzwischen einen asynchronen 128×96-Test. Der Shader liest seine Dimensionen mit <code>GetDimensions()</code>, schützt überhängende Threads durch einen Bounds-Check und wird mit <code>Dispatch(16,12,1)</code> ausgeführt. <code>PatternPhase</code> erzeugt für jeden akzeptierten Submit deterministisch einen neuen sichtbaren Inhalt. Abgewiesene Busy-Requests erhöhen die Phase nicht und erzeugen daher keine Lücken.

=== Cross-Adapter-Speicher und Synchronisation ===

* RTX und Intel öffnen denselben D3D12 Cross-Adapter Heap.
* Ein gemeinsamer Buffer wurde mit 64 Testwerten erfolgreich geprüft.
* Ein persistenter Shared Fence synchronisiert die Queues direkt von GPU zu GPU. Seine Werte steigen pro Job monoton: WorkerReady/PrimaryComplete verwenden die Paare 1/2, 3/4, 5/6 und so weiter.
* Die CPU vermittelt die GPU-Abhängigkeit nicht; Worker- und Primary-Queue verwenden <code>Signal</code> und <code>Wait</code> direkt auf der GPU.
* Der separate Readback-Verifikationstest darf weiterhin blockieren. Der normale Runtime-Pfad wartet dagegen nicht auf GPU-Leerlauf.

=== Texturtransport ===

Direkte Cross-Adapter-Texturen sind auf dem Testsystem nicht beidseitig verfügbar: Die Intel UHD meldet Unterstützung für Row-Major Cross-Adapter Textures, die RTX 5060 Laptop GPU nicht. Deshalb verwendet das Projekt einen allgemeineren Buffer-Fallback.

<pre>
Intel MainTextureCS
-> persistente Worker-Textur
-> CopyTextureRegion
-> persistenter Shared Cross-Adapter Buffer
-> Worker signalisiert WorkerReady (1, 3, 5, ...)
-> UE-Primary-Queue wartet auf WorkerReady
-> direkte Kopie in persistente UE-eigene FTextureRHIRef
-> Primary signalisiert PrimaryComplete (2, 4, 6, ...)
</pre>

Der robuste Normal-Pfad kopiert die Worker-Textur über den Shared Buffer direkt in eine von Unreal erzeugte <code>FTextureRHIRef</code>. Breite, Höhe und Row Pitch werden dynamisch aus Worker-Ressource und Transport-Metadaten übernommen. Der erfolgreiche 128×96-RGBA8-Test verwendet 512 Byte Row Pitch und 49.152 Byte Transfergröße. Die Output Registry trennt Persistent-, Pending- und Ready-Zustände sowie Inhaltsgeneration und Texturidentität. Dadurch kann eine verspätete Completion keinen neueren Output zurückrollen.

=== Non-blocking Runtime-Pfad ===

Die produktive Testlogik ist aus dem Konsolenkommando in eine gekapselte NormalPath-API verschoben. <code>SubmitWorkerTextureComputeJob()</code> reicht den Worker-Dispatch ohne CPU-Wait ein. <code>QueueNormalTextureTransfer()</code> reiht Wait, Kopie und Completion-Signal in Unreals D3D12-Kontext ein. Der normale MainTextureCS-Pfad enthält weder CPU-Fence-Waits noch Readback, <code>Map</code> oder Pixelvergleich. <code>TickNormalTextureTransfers()</code> prüft die Primary-Completion non-blocking über einen Runtime-Pump; <code>RHIEndFrame()</code> bleibt als Fallback erhalten.

Eine passende Primary-<code>FTextureRHIRef</code> wird pro Worker und Konfiguration persistent gehalten. Nach PrimaryComplete kann der nächste Job dieselbe Resource erneut verwenden; dabei führt Unreal die Übergänge <code>SRVMask -> CopyDest -> SRVMask</code> aus. Eine backend-neutrale RHI-Provider-API reicht die Ready-Textur an die Engine weiter. <code>UExperimentalMultiGPUTexture</code> hält eine stabile <code>UTexture</code> samt TextureReference und bindet die persistente <code>FTextureRHIRef</code> ohne zusätzlichen Pixel-Copy. Eine native D3D12-Resource wird weiterhin nicht blind als UE-Textur gewrappt, weil Unreals Resource-State-Buchhaltung den tatsächlichen nativen Zustand sonst nicht sicher kennt.

=== Sichtbarer TPS-Consumer ===

<code>AExperimentalMultiGPUDisplayActor</code> zeigt die Worker-Ausgabe im Third-Person-Testlevel über den Materialparameter <code>MultiGPUTexture</code> an. Damit ist der Output nicht mehr nur über Logs oder Readback nachgewiesen: Die Intel UHD erzeugt fortlaufend die Texturinhalte, während die RTX die Spielwelt und das Material rendert. <code>TextureConsumerCS</code> kann Ready-Ausgaben auf der Primary zusätzlich als SRV lesen und fünf quantisierte Samples im Debugpfad prüfen.

=== Lebensdauer und automatisches Cleanup ===

Der Normal-Pfad verwendet pro Worker genau einen persistenten Runtime-Slot. Worker-Textur, Root Signature, PSO, Descriptor Heap, Command Allocator/List und Worker-Fence werden nach der ersten kompatiblen Initialisierung wiederverwendet. Dasselbe gilt für Shared Heap/Buffer/Fence und die Transport-Command-Objekte. Der In-Flight-Job trägt nur noch die nötigen Job-, Generation- und Fence-Metadaten.

<pre>
Runtime Request
-> Completion non-blocking prüfen
-> falls Slot frei: Worker Dispatch
-> WorkerReady-Fence signalisieren
-> Primary Wait, SafeCopy und PrimaryComplete-Signal
-> Output Pending
-> Runtime-Pump oder RHIEndFrame prüft GetCompletedValue()
-> Output Ready publizieren
-> Slot wiederverwendbar
</pre>

Backpressure erlaubt maximal einen echten In-Flight-Job pro Worker. Ein Busy-Request setzt keine GPU-Arbeit ab, setzt keine Ressourcen zurück und erhöht <code>PatternPhase</code> nicht. Worker-Fence-Werte steigen mit jedem akzeptierten Submit 1, 2, 3 und so weiter; der persistente Shared Fence verwendet fortlaufend die Paare 1/2, 3/4, 5/6. Fehler nach Übergabe von Ressourcen an die GPU führen zu sicherem Retire beziehungsweise Retention statt zu vorzeitigem Reuse.

=== Texture Stream und Benchmarking ===

Der projektseitige Texture Stream akzeptiert eine beliebige positive, endliche Zielrate. Punkt und Komma sind als Dezimaltrenner möglich. Optional lässt sich die Zahl erfolgreicher Submits begrenzen; Busy- oder Failed-Versuche verbrauchen dieses Limit nicht. Der Quiet-Modus unterdrückt per-Job-Ausgaben, behält aber Start, echte Fehler und die Abschlussstatistik bei.

Die Statistik unterscheidet Timer-Ticks, angenommene Submits, Busy/Failed, Ready, In-Flight und die jeweiligen effektiven Raten. Diagnosezeitpunkte erfassen unter anderem RequestAccepted, RenderCommandExecution, WorkerSubmit, NormalTransferQueued und ReadyObserved.

{| class="wikitable"
! Test
! Ergebnis
! Aussage
|-
| 5 Hz, 20 Submits
| etwa 5 Ready/s, 20/20, kein Busy
| Entspannter Single-Slot-Betrieb
|-
| 1000 Hz, 100 Submits, quiet
| 100/100 Ready, 0 Fehler, etwa 58 Ready/s
| Backpressure begrenzt den Durchsatz sicher
|-
| 1000 Hz bei <code>t.MaxFPS 30</code>
| etwa 28–29 Ready/s trotz rund 982 Timer-Ticks/s
| Primary-/SafeCopy-/Ready-Kette ist effektiv framegekoppelt
|}

Ein zusätzlicher non-blocking Aufruf von <code>ImmediateFlush(DispatchToRHIThread)</code> erreicht hohe Render-Command-Raten, hebt die gemessene Frame-Kopplung aber nicht auf. Im 30-FPS-Test lag der RHIEndFrame-spezifische Completion-Takt praktisch exakt bei 30 Hz. Das aktuelle Problem ist damit eingegrenzt: Nicht der Stream-Timer, sondern die Primary-RHI-/D3D12-Submission der SafeCopy-Kette bestimmt die sichtbare Ready-Rate.

=== Queue-Submission-Diagnose ===

<code>MultiGPUD3D12QueueProbe</code> untersucht die Submission unabhängig vom sichtbaren Texturpfad. Neben <code>full</code>, <code>waitonly</code> und <code>signalonly</code> existieren inzwischen die Diagnosemodi <code>computeonly</code>, <code>commandonly</code>, <code>barrieronly</code>, <code>barrierprivate</code> und <code>copybuffer</code>. Als Queues stehen <code>graphics</code>, <code>copy</code>, <code>native</code>, <code>worker</code>, <code>worker-copy</code> und <code>worker-high</code> zur Verfügung. Graphics und Copy verwenden <code>RHIRunOnQueue(..., false)</code> auf UE-verwalteten Primary-Queues; die übrigen Varianten isolieren private beziehungsweise bereits vorhandene native D3D12-Queues.

Der Probe misst Request, Worker-Submit, <code>RHIRunOnQueue</code>-Aufruf und -Callback, Primary-Execute, Fence-Completion sowie Ready bis zum nächsten akzeptierten Submit. Er fügt keine CPU-Waits, Readbacks, Maps oder <code>BlockUntilGPUIdle</code> ein und beschreibt keine Textur des sichtbaren Normal-Pfads.

{| class="wikitable"
! Test
! Ergebnis
! Befund
|-
| UE Graphics, signal-only, 30 FPS
| 33,319 ms PrimaryExecute bis Ready
| UE-verwaltete Graphics-Submission skaliert mit der Frame-Dauer
|-
| UE Copy, signal-only, 30 FPS
| 32,593 ms PrimaryExecute bis Ready
| Auch die UE-verwaltete Copy Queue ist framegekoppelt
|-
| Private Primary-DIRECT-Queue, signal-only
| etwa 0,014 ms Queue/Fence-Latenz; nach Lifecycle-Fix rund 999 Ready/s bei 30 FPS
| Native Queue und Scheduler sind vollständig vom Frame entkoppelt
|-
| Worker signal-only / leere Command List
| jeweils rund 1000 Ready/s bei 30 FPS
| Worker-Queue, Fence und reine Submission sind nicht framegekoppelt
|-
| Worker <code>CopyBufferRegion</code>, 30 / 60 / 120 FPS
| 29,41 / 58,25 / 113,08 Ready/s
| Bereits eine echte 256-Byte-GPU-Kopie folgt im UE-Prozess dem Frame-Raster
|-
| Worker COPY Queue / HIGH Priority, 30 FPS
| jeweils rund 29,42 Ready/s
| Queue-Typ und Priorität beseitigen die Kopplung nicht
|-
| Standalone-D3D12 auf derselben Intel UHD
| 92.956 Copy-Jobs/s; 0,007 ms durchschnittliche Fence-Latenz
| Die Kopplung ist UE-Prozess-/Scheduling-spezifisch, keine allgemeine Intel-, WDDM- oder D3D12-Grenze
|}

Der <code>RHIRunOnQueue</code>-Callback selbst erreicht den D3D12-Submission-Thread typischerweise bereits nach etwa 0,02–0,05 ms; die Verzögerung entsteht danach in der verwalteten Queue-/Submission-Reihenfolge. <code>SubmitCommandsHint()</code> ist in UE 5.8 nur ein veralteter Alias für <code>ImmediateFlush(DispatchToRHIThread)</code> und stellt daher keinen stärkeren Submission-Mechanismus dar.

Der native Test ist ein '''Architekturbeweis, noch kein Experimental- oder Direct-Modus'''. Die zunächst gemessene Verzögerung von rund 32 ms lag zwischen der In-Flight-Freigabe und dem nächsten Request auf dem Render Thread. Für <code>signalonly/native</code> wurde der sichere Completion-/Submit-Lifecycle deshalb in den frameunabhängigen Scheduler verlegt. Danach erreichten zwei 100-Job-Läufe bei <code>t.MaxFPS 30</code> rund 999 bis 1029 Ready/s, ohne Busy oder Fehler.

Der anschließende <code>full native</code>-Test lokalisierte die verbleibende Kopplung auf echte Worker-GPU-Arbeit: WorkerSubmit bis WorkerReady benötigte bei 30, 60 und 120 FPS ungefähr 33,29, 16,93 und 8,45 ms; WorkerReady bis PrimaryReady war danach praktisch sofort. Signal-only und eine leere Command List waren schnell, Resource Barriers und eine 256-Byte-Kopie dagegen framegebunden. Ein eigenständiger D3D12-Microbenchmark auf derselben Intel UHD erreichte außerhalb von Unreal bei derselben Kopie rund 92.956 Jobs/s mit 0,007 ms mittlerer Fence-Latenz. Die genaue Ursache im UE-Prozess beziehungsweise dessen GPU-Scheduling-Kontext bleibt offen und wird vorerst bis zum Gegencheck mit der vorhandenen Intel Arc A380 geparkt.

=== Worker-Rasterpfad und RasterStream ===

<code>ExperimentalMultiGPU.TestRasterWorker</code> weist erstmals echte Rasterizer-Arbeit auf der Intel-Worker-GPU nach. <code>RasterWorkerVS</code> und <code>RasterWorkerPS</code> werden über Unreals Global-Shader-Pfad kompiliert und für ein natives Worker-Graphics-PSO verwendet. Ein persistentes 128×96-RGBA8-RenderTarget besitzt RTV, leere Root Signature und eine DIRECT-Command-List. Der Vertex Shader erzeugt drei Vertices über <code>SV_VertexID</code>; der Pixel Shader schreibt interpolierte RGB-Farben.

Der Job wechselt das RenderTarget von <code>COPY_SOURCE</code> nach <code>RENDER_TARGET</code>, führt Clear und <code>DrawInstanced(3,1,0,0)</code> aus und wechselt anschließend zurück nach <code>COPY_SOURCE</code>. Danach verwendet er unverändert den robusten Normalpfad aus Cross-Adapter-Shared-Buffer, Primary SafeCopy, persistenter <code>FTextureRHIRef</code>, <code>UExperimentalMultiGPUTexture</code> und DisplayActor. Der Runtime-Test meldete einen akzeptierten Submit und <code>RasterWorker READY</code> für Generation 1; die 128×96-UTexture wurde erfolgreich gebunden.

Der einmalige Test wurde außerdem zu einem frei konfigurierbaren RasterStream ausgebaut. Ein sichtbarer Lauf mit 10 Hz und 50 erfolgreichen Submits endete mit 50 Ready-Ausgaben, 0 Busy und 0 Fehlern bei etwa 9,90 Ready/s. Primary-Textur und Materialbindung blieben dabei persistent.

=== Raster3D mit echten Vertex- und Indexbuffern ===

Der Worker besitzt inzwischen einen kleinen eigenständigen 3D-Rasterpfad mit perspektivischer Kamera, Model-View-Projection-Matrix als Root Constants, D32_FLOAT-Depth-Buffer und Depth-Test. Der finale Testwürfel verwendet 24 POSITION/COLOR-Vertices, 36 <code>uint16</code>-Indices und <code>DrawIndexedInstanced(36,1,0,0,0)</code>; sechs getrennte Seitenfarben machen Ausrichtung und Rotation sichtbar nachvollziehbar.

Die statischen Meshdaten werden einmalig über private Upload-Buffer in DEFAULT-Heaps übertragen. Der Init-Fence wird non-blocking über <code>GetCompletedValue()</code> beobachtet. Der eigentliche Runtime-Renderpfad enthält weiterhin keine CPU-Waits und keine Maps.

=== UE-Static-Meshes auf der Worker-GPU ===

<code>StaticMeshWorker</code> extrahiert echte LOD0-Geometrie aus <code>UStaticMesh</code>-Assets. POSITION und NORMAL sowie <code>uint32</code>-Indices werden in POD-Daten überführt, einmalig asynchron in eigene Worker-VB/IB hochgeladen und anschließend per <code>DrawIndexedInstanced</code> gerendert. Assetpfade sind dynamisch; Auto-Fit richtet Kamera beziehungsweise Modellmaßstab an den Bounds aus.

Sichtbar korrekt getestet wurden:

{| class="wikitable"
! Asset
! Vertices
! Indices
|-
| Sphere
| 559
| 2880
|-
| Cube
| 54
| 144
|-
| Cylinder
| 334
| 1536
|}

=== Multi-Mesh Worker-Szene ===

<code>StaticMeshScene</code> rendert Sphere, Cube und Cylinder gemeinsam in einen Color-/Depth-Frame. Der verifizierte Test umfasst insgesamt 947 Vertices und 4560 Indices, drei <code>DrawIndexedInstanced</code>-Aufrufe und nur einen anschließenden Cross-Adapter-/Normal-SafeCopy-Transfer. Damit ist nicht mehr nur ein synthetisches Primitive, sondern mehrere echte UE-Meshes mit gemeinsamer Tiefenprüfung im Worker-Frame sichtbar nachgewiesen.

=== WorldStaticMeshScene ===

<code>ExperimentalMultiGPUWorldStaticMeshScene.cpp</code> sammelt im Engine-Layer bis zu acht sichtbare <code>UStaticMeshComponent</code>s von Actors mit dem Tag <code>MultiGPUWorker</code>. Meshdaten und World-Transforms werden im Game Thread in reine POD-Strukturen und 4×4-Matrizen kopiert. D3D12RHI erhält keine <code>UObject</code>-Pointer. Mehrere Instanzen desselben Meshes teilen den persistenten Worker-Mesh-Cache und unterscheiden sich nur durch Modelmatrix und Draw Call.

Der Pfad wurde inzwischen sichtbar im PIE-Level verifiziert. Drei getaggte Static-Mesh-Actors erschienen mit ihren tatsächlichen relativen Positionen, Rotationen und Skalierungen im Worker-Bild. Die zentrale Koordinatenumrechnung lautet:

<pre>Worker (X, Y, Z) = (UE Y, UE X, -UE Z)</pre>

Die Transformation besitzt die Determinante +1 und ist damit keine Spiegelung. Das notwendige horizontale Spiegeln erfolgt ausschließlich auf der Presentation-Plane, nicht im Worker-Renderpfad.

=== Kontinuierlicher WorldStaticMeshSceneStream ===

<code>StartWorldStaticMeshSceneStream</code> erfasst die getaggte Szene fortlaufend im Game Thread. Reine Änderungen an Transform oder Kamera lösen keinen erneuten Mesh-Upload aus. Hinzugekommene, entfernte, unsichtbare oder umgetaggte Components werden im nächsten Snapshot berücksichtigt. Single-Slot-Backpressure verhindert einen wachsenden Rückstau.

Ein verifizierter 30-Hz-Lauf endete nach 31,184 Sekunden mit 835 Ticks, 691 angenommenen Submits, 144 Busy, 0 Fehlern und 691 Ready-Frames. Die effektive Ready-Rate betrug 22,16 Hz. Dieser Test belegt die funktionale Live-Aktualisierung; die Rate war noch kein Optimierungsziel.

=== SceneCapture2D als Worker-Kamera ===

<code>TestSceneCaptureStaticMeshScene</code> verwendet eine echte <code>ASceneCapture2D</code> beziehungsweise <code>USceneCaptureComponent2D</code> aus der laufenden PIE-Welt als Kameraquelle. Der empfohlene Editor-Weg ist das Component Tag <code>MultiGPUWorkerCamera</code> auf der <code>CaptureComponent2D</code>; ein gleichnamiges Actor-Tag bleibt nur als Legacy-Fallback.

Ausgelesen werden World Location, Rotation, Forward/Right/Up, <code>FOVAngle</code> und <code>ProjectionType</code>. Orthografische Projektion wird derzeit sauber abgelehnt. Die SceneCapture2D liefert ausschließlich Kameradaten: Ihr UE-RenderTarget wird weder gelesen noch kopiert. Die Intel-Worker-GPU rendert die Geometrie selbst. Kamera und Actors werden gemeinsam mit <code>SceneScale = 0.01</code> in Worker-Koordinaten überführt; Auto-Fit und Scene-Recentering sind in diesem Modus deaktiviert.

Die 128×96-Worker-Projektion verwendet ein Seitenverhältnis von 4:3 und interpretiert <code>FOVAngle</code> als horizontales FOV. Nach den Orientierungstests wird nur die Anzeige über <code>SetRelativeScale3D(FVector(-4.0f, -3.0f, 1.0f))</code> korrigiert; dies entspricht <code>U' = 1-U</code> und <code>V' = 1-V</code>.

=== Live SceneCaptureStaticMeshSceneStream ===

<code>StartSceneCaptureStaticMeshSceneStream</code> liest Kamera-Transform, Kamerabasis, FOV und aktuelle Actor-Transforms pro Snapshot neu im Game Thread. Der Worker erhält weiterhin ausschließlich POD-Daten, verwendet den persistenten Mesh-Cache sowie ein gemeinsames Color- und D32-Depth-Target und führt pro akzeptiertem Frame genau einen Cross-Adapter-/Normal-SafeCopy-Transfer aus.

Der Quiet-Test

<pre>ExperimentalMultiGPU.StartSceneCaptureStaticMeshSceneStream 30 300 quiet</pre>

lieferte in 10,084 Sekunden 301 Ticks, 300 Submits, 1 Busy, 0 Fehler und 300 Ready-Frames. Die effektive Ready-Rate betrug 29,75 Hz. Bewegungen der Kamera und Actors sowie FOV-Änderungen erschienen live auf der Display-Plane. Damit ist erstmals ein kleiner SceneCapture-/CCTV-artiger Worker-Kanal vollständig funktional nachgewiesen.

=== Dynamische SceneCapture-Auflösung ===

Die SceneCapture-Ausgabe ist nicht mehr fest auf 128×96 Pixel begrenzt. <code>ExperimentalMultiGPU.SetSceneCaptureResolution <Width> <Height></code> setzt ganzzahlige Dimensionen von 1 bis 4096; <code>GetSceneCaptureResolution</code> zeigt die aktive Einstellung. 128×96 bleibt der Standard. Während ein SceneCapture-Stream läuft, wird ein Auflösungswechsel absichtlich abgelehnt, damit keine In-Flight-Ressourcen ausgetauscht werden.

Color Target, D32-Depth-Buffer, Row Pitch, Shared-Buffer-Transport, SafeCopy, persistente Primary-Textur und <code>UExperimentalMultiGPUTexture</code> übernehmen die gewählten Dimensionen. Projektion und Display-Plane verwenden das echte Seitenverhältnis. Die bestätigte Anzeigeorientierung <code>U' = 1-U</code> und <code>V' = 1-V</code> bleibt eine reine Presentation-Korrektur; Worker-Basis und Kameramathematik ändern sich nicht.

=== Scheduler-Korrektur bei SceneCapture ===

Ein 1920×1080-Test mit 25 Hz erreichte zunächst trotz fehlerfreier Frames nur 13,90 Ready-Hz und erzeugte 222 Busy-Ticks. Ursache war kein GPU-Limit, sondern ein Polling-Aliasing: Eine frühe Game-Thread-Prüfung konnte den Timer-Slot verwerfen, obwohl die Completion kurz darauf im CoreTicker/RHI-Pump sichtbar geworden wäre.

Die frühe <code>IsRuntimeTextureUpdateInFlight()</code>-Prüfung wurde für diesen Stream entfernt. Der Pending-Request bleibt als Backpressure-Gate erhalten; die maßgebliche Busy-Entscheidung fällt nun erst im Render Command nach <code>TickNormalTextureTransfers(nullptr, true)</code>. Single-Slot, POD-Snapshots und non-blocking <code>GetCompletedValue()</code> bleiben erhalten. Es wurden weder CPU-Waits noch zusätzliche Threads eingeführt.

Nach der Korrektur erreicht 1080p bei 25 Hz 24,79 Ready-Hz mit 1 Busy; bei 30 Hz sind es 29,43 Ready-Hz mit 4 Busy.

=== Skalierung bis 4K60 ===

Die Pipeline wurde von 640×360 bis 3840×2160 getestet. Bei 640×360/30 Hz und 1280×720/30 Hz wurden 29,85 beziehungsweise 29,82 Ready-Hz ohne Busy erreicht. 1920×1080/60 Hz lieferte 59,40 Ready-Hz ohne Busy, 2560×1440/60 Hz 59,21 Ready-Hz mit 1 Busy und 3840×2160/60 Hz 59,02 Ready-Hz mit 2 Busy.

Ein zusätzlicher 4K60-Stresstest mit acht Static-Mesh-Instanzen und drei gecachten Unique Meshes erreichte in 5,049 Sekunden '''300 von 300 Ready-Frames, 0 Busy, 0 Fehler und 59,42 effektive Ready-Hz'''. Acht Draw Calls, gemeinsamer Depth Buffer, Cross-Adapter-Transport und SafeCopy liefen dabei im vorhandenen Single-Slot. Das ist ein Stabilitätsnachweis der aktuellen Mini-Szene, kein allgemeiner GPU-Benchmark.

=== Skeletal Mesh in Reference Pose ===

<code>ExperimentalMultiGPU.TestSkeletalMeshWorker</code> erweitert den Geometriepfad auf <code>USkeletalMeshComponent</code>. Der Engine-Layer sucht deterministisch die erste sichtbare, getaggte Komponente und extrahiert LOD0-Positionen, Normalen, Indices und Render Sections. D3D12RHI erhält wie bisher ausschließlich POD-Geometrie und Modelmatrizen.

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.

== Test- und Diagnosebefehle ==

{| class="wikitable"
! Befehl
! Zweck
|-
| <code>ExperimentalMultiGPU.TestComputeShader</code>
| Führt den vollständigen Worker-Compute-Testpfad aus. Er enthält auch ältere Debug- und Regressionstests mit CPU-Readback und ist daher nicht mit dem reinen asynchronen Runtime-Pfad gleichzusetzen.
|-
| <code>ExperimentalMultiGPU.TestTextureConsumer</code>
| Testet <code>TextureConsumerCS</code> auf der Primary-GPU. Die aktuelle Ready-Textur wird über UE-RHI gelesen und anhand ausgewählter Testpixel per Debug-Readback geprüft.
|-
| <code>ExperimentalMultiGPU.TestTextureBridge</code>
| Prüft die Bridge von der fertigen <code>FTextureRHIRef</code> zu <code>UExperimentalMultiGPUTexture</code> und damit den UE- und materialtauglichen Texturpfad.
|-
| <code>ExperimentalMultiGPU.SpawnDisplayActor</code>
| Spawnt den Test-Actor mit Plane im Spiel. Das Material zeigt darauf die vom Worker erzeugte Textur an.
|-
| <code>ExperimentalMultiGPU.TestRasterWorker</code>
| Rasterisiert auf der Worker-GPU ein echtes RGB-Dreieck per Vertex- und Pixel-Shader und transportiert das Ergebnis über den normalen SafeCopy-Pfad bis zum DisplayActor.
|-
| <code>ExperimentalMultiGPU.StartRasterStream</code> / <code>ExperimentalMultiGPU.StopRasterStream</code>
| Startet beziehungsweise stoppt den kontinuierlichen RGB-Dreieck-RasterStream mit frei wählbarer Zielrate, optionalem Submit-Limit und Quiet-Modus.
|-
| <code>ExperimentalMultiGPU.TestRaster3DWorker</code>
| Rendert einmalig den perspektivischen 3D-Testwürfel mit Depth Buffer und echten Vertex-/Indexbuffern.
|-
| <code>ExperimentalMultiGPU.StartRaster3DStream</code> / <code>ExperimentalMultiGPU.StopRaster3DStream</code>
| Startet beziehungsweise stoppt den kontinuierlichen Raster3D-Test.
|-
| <code>ExperimentalMultiGPU.TestStaticMeshWorker [AssetPath]</code>
| Extrahiert und rendert LOD0-Geometrie eines UE-Static-Mesh-Assets; ohne optionalen Pfad wird das konfigurierte Testasset verwendet.
|-
| <code>ExperimentalMultiGPU.TestStaticMeshScene</code>
| Rendert Sphere, Cube und Cylinder gemeinsam mit drei Draw Calls und einem anschließenden Transfer.
|-
| <code>ExperimentalMultiGPU.TestWorldStaticMeshScene</code>
| Rendert einen einmaligen POD-Snapshot der sichtbaren, mit <code>MultiGPUWorker</code> getaggten StaticMeshComponents aus der laufenden World. Der sichtbare PIE-Nachweis ist erfolgreich.
|-
| <code>ExperimentalMultiGPU.StartWorldStaticMeshSceneStream [Hz] [MaxSuccessfulSubmits] [quiet]</code> / <code>StopWorldStaticMeshSceneStream</code>
| Startet beziehungsweise stoppt den kontinuierlichen Stream der getaggten UE-Welt mit Live-Transforms und persistentem Mesh-Cache.
|-
| <code>ExperimentalMultiGPU.SetSceneCaptureResolution <Width> <Height></code> / <code>GetSceneCaptureResolution</code>
| Setzt beziehungsweise zeigt die gemeinsame SceneCapture-Auflösung. Erlaubt sind ganzzahlige Werte von 1 bis 4096 je Achse; Änderungen während eines laufenden Streams werden abgelehnt.
|-
| <code>ExperimentalMultiGPU.TestSceneCaptureStaticMeshScene</code>
| Rendert einen einmaligen Worker-Snapshot aus Sicht der mit <code>MultiGPUWorkerCamera</code> markierten SceneCapture2D-Kamera.
|-
| <code>ExperimentalMultiGPU.StartSceneCaptureStaticMeshSceneStream [Hz] [MaxSuccessfulSubmits] [quiet]</code> / <code>StopSceneCaptureStaticMeshSceneStream</code>
| Startet beziehungsweise stoppt den Live-Worker-Kanal mit fortlaufend aktualisierten Kamera-, FOV- und Actor-Daten.
|-
| <code>ExperimentalMultiGPU.TestSkeletalMeshWorker</code>
| Rendert das erste sichtbare, getaggte Skeletal Mesh in LOD0 und Reference Pose sectionsweise auf der Worker-GPU.
|-
| <code>ExperimentalMultiGPU.StartTextureStream</code>
| Startet den sichtbaren Normal-Pfad: Worker-Textur → Cross-Adapter-Transfer → SafeCopy → UE-Textur → Material.
|-
| <code>ExperimentalMultiGPU.StopTextureStream</code>
| Verhindert weitere Submits des laufenden Streams. Ein bereits eingereichter GPU-Job darf noch sicher fertig werden.
|-
| <code>ExperimentalMultiGPU.StartQueueProbe</code>
| Startet den Diagnose-Benchmark für Primary-Queue-, Fence- und Submission-Verhalten. Der Probe verändert die sichtbare Textur nicht.
|}

=== Texture Stream ===

Grundsyntax:

<pre>
ExperimentalMultiGPU.StartTextureStream [Hz] [MaxSuccessfulSubmits] [quiet]
</pre>

{| class="wikitable"
! Beispiel
! Wirkung
|-
| <code>ExperimentalMultiGPU.StartTextureStream</code>
| Standardmäßig etwa 5 Hz, ohne Submit-Limit.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 37.5</code>
| Fordert 37,5 Hz ohne Submit-Limit an. Sowohl <code>37.5</code> als auch <code>37,5</code> werden akzeptiert.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 1000 100</code>
| Fordert 1000 Hz an und stoppt nach exakt 100 erfolgreichen Submits.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 1000 100 quiet</code>
| Wie zuvor, unterdrückt aber Per-Job- und Busy-Logspam.
|}

Die Hz-Angabe ist eine '''Ziel- beziehungsweise Request-Frequenz'''. <code>1000</code> bedeutet daher nicht automatisch 1000 fertige Texturen pro Sekunde. Die tatsächliche Rate hängt unter anderem von Timer, Submission, Backpressure, Queue-Latenz und Slot-Lifecycle ab. <code>MaxSuccessfulSubmits</code> zählt nur angenommene Submits; Busy- und Failed-Versuche verbrauchen das Limit nicht.

=== QueueProbe ===

Grundsyntax:

<pre>
ExperimentalMultiGPU.StartQueueProbe <Hz> <MaxSubmits> [quiet] [Mode] [Queue]
</pre>

{| class="wikitable"
! Modus
! Ausgeführter Pfad
|-
| <code>full</code>
| Worker Compute → Cross-Adapter-Transfer → Primary Wait → Copy → Completion Fence.
|-
| <code>waitonly</code>
| Worker Compute → Cross-Adapter-Transfer → Primary wartet auf WorkerReadyFence → Completion Fence. Es findet keine Texturkopie statt.
|-
| <code>signalonly</code>
| Keine Textur, kein Worker-Wait und keine Kopie; nur Queue und Fence. Dieser Modus isoliert das Queue-Verhalten.
|-
| <code>commandonly</code>
| Reicht eine leere echte Worker-Command-List ein und trennt Command-Submission von GPU-Arbeit.
|-
| <code>barrieronly</code> / <code>barrierprivate</code>
| Isoliert Resource-Barriers auf Worker-Ressourcen beziehungsweise einer privaten Testtextur.
|-
| <code>copybuffer</code>
| Führt eine minimale echte <code>CopyBufferRegion</code>-Operation über 256 Byte aus.
|}

{| class="wikitable"
! Queue
! Bedeutung
|-
| <code>graphics</code>
| Vorhandene UE Primary Graphics-/Direct-Queue über <code>RHIRunOnQueue</code>.
|-
| <code>copy</code>
| Vorhandene UE Primary Copy Queue über <code>RHIRunOnQueue</code>.
|-
| <code>native</code>
| Vollständig private native D3D12-DIRECT-Queue auf der Primary; reine Diagnose, kein fertiger Experimental-Modus.
|-
| <code>worker</code>
| Vorhandene native Worker-DIRECT-Queue.
|-
| <code>worker-copy</code>
| Separate native Worker-COPY-Queue.
|-
| <code>worker-high</code>
| Separate Worker-DIRECT-Queue mit hoher Priorität.
|}

Typische Beispiele:

<pre>
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet full graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet waitonly graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly copy
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly native
</pre>

Der letzte Befehl ist aktuell die wichtigste isolierte Gegenprobe. Mit der privaten nativen Queue wurde bei 30 FPS eine durchschnittliche Latenz <code>primaryExecuteToReadyAvgMs = 0.014 ms</code> gemessen.

=== Benchmark-CVars ===

{| class="wikitable"
! CVar
! Zweck
|-
| <code>r.VSync 0</code>
| Deaktiviert VSync, damit es die Messung nicht begrenzt.
|-
| <code>t.MaxFPS 30</code> <code>t.MaxFPS 60</code> <code>t.MaxFPS 120</code>
| Setzt die Engine-Framerate für reproduzierbare Frame-Coupling-Tests.
|-
| <code>t.MaxFPS 0</code>
| Entfernt das normale <code>t.MaxFPS</code>-Limit. Dieser Lauf ist als zusätzliche Diagnose-Gegenprobe vorgesehen.
|}

== Aktueller nächster Schritt ==

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 ==

Die Grundidee heterogener Multi-GPU-Nutzung ist nicht neu. Bereits mit der Einführung von Direct3D 12 entstanden mehrere Versuche, integrierte und dedizierte GPUs gemeinsam zu verwenden. Eine allgemein einsetzbare Lösung für moderne UE5-Spiele hat sich daraus jedoch nicht entwickelt.

=== Microsoft und Epic: UE4 Elemental Demo (2015) ===

Microsoft zeigte eine angepasste Unreal-Engine-4-Version der Elemental-Demo, bei der eine NVIDIA-GPU und eine Intel-iGPU gemeinsam arbeiteten. Das erklärte Ziel war, ansonsten ungenutzte Grafikleistung in Hybrid-Systemen zu verwenden. Dieser Versuch ist der Grundidee des Projekts besonders ähnlich, blieb aber eine technische Demonstration.

=== Intel: D3D12 Multi-Adapter Sample (2015) ===

Intels Beispiel kombinierte eine GeForce 840M mit Intel HD Graphics 5500. Beide GPUs berechneten getrennte Teile einer einfach parallelisierbaren Raytracing-Szene. Cross-Adapter-Ressourcen und Shared Fences führten die Ergebnisse anschließend zusammen. Intel berichtete in diesem Test von nahezu halbierter Framezeit, warnte jedoch ausdrücklich davor, das Ergebnis unmittelbar auf reale Spiele zu übertragen.

=== Ashes of the Singularity ===

Die Nitrous Engine von ''Ashes of the Singularity'' setzte Direct3D-12-Explicit-Multiadapter in einem veröffentlichten Spiel ein. Dabei konnten auch unterschiedliche GPU-Modelle und Hersteller zusammenarbeiten. Das war ein wichtiger Praxisnachweis, blieb in der Spielebranche aber eine seltene Ausnahme.

=== Weitere verwandte Ansätze ===

* ''Rise of the Tomb Raider'' erhielt explizite Direct3D-12-Multi-GPU-Unterstützung, vor allem für klassische Kombinationen ähnlicher GPUs.
* NVIDIA VR SLI wies bei Virtual Reality jeder GPU ein Auge zu. Das verteilt unabhängige Ansichten, bleibt jedoch NVIDIA-spezifisch.
* Unreal nDisplay kann Viewports oder Frustums auf weitere GPUs beziehungsweise Prozesse auslagern und das fertige Bild zur Ausgabe-GPU zurückführen. Der Einsatzbereich ist hauptsächlich Virtual Production.
* Forschung und High-Performance Computing verwenden seit Jahren Scheduler für heterogene GPUs, allerdings überwiegend für Compute- und Datenverarbeitungsaufgaben statt für einen allgemeinen UE5-Echtzeitrenderer.

=== Abgrenzung dieses Projekts ===

Das Projekt erfindet Direct3D-12-Explicit-Multiadapter nicht neu. Sein eigener Ansatz liegt in der Kombination aus tiefer UE5.8-RHI-Integration, UE-kompilierten Shadern auf unabhängigen Worker-Devices, frei wählbaren Spiel- und Compute-Workloads, Capability- und Performance-Scheduler, mehreren Fallback-Pfaden sowie dem langfristigen Ziel beliebiger Hersteller und mehrerer Worker.

== Vergleich mit anderen Multi-GPU-Verfahren ==

{| class="wikitable"
! Verfahren
! Arbeitsweise
! Verhältnis zu diesem Projekt
|-
| SLI / CrossFire
| Treiber- beziehungsweise Verbundlösung für meist ähnliche GPUs; häufig wird die Bildarbeit verteilt.
| Dieses Projekt benötigt keinen herstellerspezifischen GPU-Verbund und weist Aufgaben ausdrücklich selbst zu.
|-
| AFR (Alternate Frame Rendering)
| GPU 1 rendert einen Frame, GPU 2 den nächsten.
| Das Projekt verteilt unabhängige Aufgaben statt aufeinanderfolgender Frames. Dadurch werden Frame-Abhängigkeiten und typisches AFR-Pacing vermieden.
|-
| SFR (Split Frame Rendering)
| Mehrere GPUs bearbeiten Bereiche desselben Frames.
| Erfordert enge Lastverteilung und viel Datenaustausch. Das Projekt bevorzugt vollständig abgrenzbare Workloads und überträgt deren Ergebnis.
|-
| Direct3D 12 Linked Multiadapter
| Mehrere vom Treiber verbundene GPUs erscheinen als Knoten eines logischen Adapters.
| Eignet sich eher für eng kompatible GPUs. Das Projekt verwendet unabhängige Devices (Unlinked/Explicit Multiadapter) und unterstützt dadurch heterogene Herstellerkombinationen.
|-
| Direct3D 12 Unlinked / Explicit Multiadapter
| Die Anwendung verwaltet getrennte Adapter, Ressourcen und Synchronisation selbst.
| Das ist die technische Familie des Projekts. Hinzu kommen die eigene UE5-RHI-Integration, Workload-Ziele, Fallbacks und der geplante Scheduler.
|-
| UE nDisplay mGPU / Multi-Process
| Separate GPUs rendern bestimmte Viewports oder Frustums, vor allem für Virtual Production; Ergebnisse werden zur Ausgabe-GPU kopiert.
| Ähnliche Idee der aufgabenweisen Trennung, aber für einen anderen Einsatzbereich. Dieses Projekt zielt auf allgemeine Spiel- und Compute-Workloads innerhalb der Engine.
|-
| Vulkan Device Groups
| Ähnliche physische GPUs können ein gemeinsames logisches Device bilden.
| Für beliebige heterogene GPUs meist ungeeignet, da Geräte einer Gruppe nahezu gleiche Eigenschaften besitzen müssen. Eine spätere Vulkan-Portierung benötigt daher wahrscheinlich getrennte Devices und External Memory/Semaphores.
|}

SLI und CrossFire bezeichnen den Verbund; AFR und SFR beschreiben mögliche Verteilungsmethoden innerhalb solcher Systeme. Sie sind deshalb nicht vollständig getrennte Kategorien.

== Vorteile der geplanten Variante ==

* '''Herstellerunabhängig:''' NVIDIA, AMD und Intel können grundsätzlich kombiniert werden.
* '''Vorhandene Hardware nutzen:''' Auch eine sonst wenig genutzte integrierte GPU kann geeignete Nebenaufgaben übernehmen.
* '''Aufgaben statt Frames verteilen:''' Spiegel, Minimap oder Compute können mit eigener Auflösung und Aktualisierungsrate laufen.
* '''Keine identischen GPUs erforderlich:''' Unterschiedliche Fähigkeiten können gezielt genutzt werden.
* '''Kontrollierter Datenaustausch:''' Nur das benötigte Ergebnis muss zurück zur Primary-GPU.
* '''Robuste Fallback-Idee:''' Wenn direkte Texturen nicht gemeinsam nutzbar sind, bleibt der Shared-Buffer-Pfad.
* '''Erweiterbar:''' Scheduler, manuelles Mapping und mehrere Worker sind als spätere Stufen vorgesehen.

== Nachteile und technische Risiken ==

* '''Hoher Entwicklungsaufwand:''' Geräte, Ressourcen, Zustände, Fences, Fehlerfälle und UE-Lebenszyklen müssen selbst verwaltet werden.
* '''Transfer kann den Gewinn aufzehren:''' Cross-Adapter Heaps liegen laut D3D12 nicht automatisch im schnellen lokalen VRAM. Bandbreite und Latenz müssen für jeden Workload gemessen werden.
* '''VRAM wird nicht einfach addiert:''' Benötigte Ressourcen können auf mehreren GPUs vorliegen und zusätzlichen Speicher verbrauchen.
* '''Langsame Worker können bremsen:''' Eine Aufgabe lohnt sich nur, wenn Rechengewinn größer als Übergabe-, Warte- und Kopierkosten ist.
* '''Nicht jeder Workload ist unabhängig:''' Hauptansicht, Lumen, Nanite und stark gekoppelte Renderpässe besitzen viele Abhängigkeiten und sind schwieriger auszulagern.
* '''Hardwareunterschiede:''' Formate, Shader-Funktionen, Queue-Fähigkeiten und Cross-Adapter-Support müssen pro GPU geprüft werden.
* '''Wartungsrisiko:''' Eingriffe in private D3D12RHI-Dateien können bei Engine-Updates angepasst werden müssen.
* '''Produktionsreife fehlt noch:''' Ressourcenpools, Timeouts, Device-Lost-Wiederherstellung, Scheduler und echte Szenentests sind offen.

== Wann die Variante sinnvoll ist ==

Am aussichtsreichsten sind Aufgaben mit viel eigener Rechenarbeit, einem relativ kleinen Endergebnis und wenigen Abhängigkeiten zur Hauptszene. Gute frühe Kandidaten sind unabhängige Compute-Aufgaben sowie Scene Captures, die nicht in jedem Frame aktualisiert werden müssen. Weniger geeignet sind winzige Aufgaben mit großem Transfer oder Renderpässe, die ständig auf Ressourcen der Primary-GPU zugreifen.

Die entscheidende Regel für den späteren Scheduler lautet daher:

<pre>
Worker-Gewinn > Vorbereitung + Datentransfer + Synchronisation + Rückintegration
</pre>

== Bekannte Grenzen des Proof of Concepts ==

* 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 sichtbarer Runtime-Slot. Mehrere parallele In-Flight-Jobs und Ringbuffer fehlen noch.
* Praktisch getestet ist Primary plus ein Worker. Mehrere Worker sind architektonisch vorgesehen, aber noch nicht praktisch validiert.
* World- und SceneCapture-Pfade verarbeiten pro Snapshot höchstens acht sichtbare <code>UStaticMeshComponent</code>s.
* 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.
* <code>USkeletalMesh</code> ist bislang ein LOD0-ReferencePose-Proof. Bone-Skinning, Animation, Morph Targets und Cloth fehlen.
* Die Workload-Registry sammelt Metadaten und Messwerte, führt aber noch keine automatische Zuweisung, Auflösungsänderung oder Ratenanpassung aus.
* Worker GPU Timing V1 misst nur den Rasterabschnitt. Cross-Adapter-Transfer und Primary-SafeCopy fehlen noch im Kostenmodell.
* 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.
* QueueProbe und private native Queues bleiben Diagnosepfade; Experimental/Direct ist noch nicht implementiert.
* 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.
* Linux/Vulkan mit getrennten Devices, External Memory und externer Synchronisation ist noch nicht implementiert.

== Roadmap ==

# Cross-Adapter Transfer Timing V1: Worker-ColorTarget → Shared Buffer separat messen.
# Primary SafeCopy Timing ergänzen und die Integrationskosten getrennt halten.
# Kostenmodell V1 aus Worker-Raster, Transfer und Primary-Integration pro Workload ableiten.
# Weitere echte Workload-Klassen wie CCTV, Spiegel, Minimap und Compute anbinden; später Post Process oder neuronale Aufgaben untersuchen.
# D3D12-Pfade mit Intel Arc A750/A380 und RX 6900 XT in unterschiedlichen Primary-/Worker-Rollen gegenprüfen.
# Scheduler und Autotuner auf GPU-Eignung und gemessene Nettokosten statt Auslastungsprozent aufbauen.
# Material-, Textur- und Culling-Pfade für realistischere Worker-Szenen ergänzen.
# Skeletal Skinning mit Bone-Matrizen und Skin Weights erst bei einem echten animierten Worker-Workload ausbauen.
# 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 ==

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 ==

* 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/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://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://www.intel.com/content/dam/develop/external/us/en/documents/multi-adapter-support-in-directx-12-594015.pdf Intel: Multi-Adapter Support in DirectX 12]
* [https://devblogs.microsoft.com/directx/ashes-of-the-singularity-makes-gaming-history-with-directx-12/ Microsoft: Ashes of the Singularity und heterogene Adapter]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/nvidia-sli-alternative-frame-rendering-in-unreal-engine Epic: NVIDIA SLI Alternate Frame Rendering]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/multi-process-rendering-with-unreal-engine Epic: Multi-Process Rendering]
* [https://registry.khronos.org/vulkan/specs/latest/pdf/vkspec.pdf Khronos: Vulkan Specification – Device Groups]

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Multi-GPU]]
[[Kategorie:Direct3D 12]]
[[Kategorie:Experimentell]]

UE5 Heterogeneous Multi-GPU

2026-09-14T18:24:46Z

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

{{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.}}

'''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.

{| class="wikitable"
|+ Projektstatus
|-
! Engine / Plattform
| Unreal Engine 5.8 Source Build / Windows / Direct3D 12
|-
! Testsystem
| Lenovo LOQ 17IRX10
|-
! Primary
| NVIDIA GeForce RTX 5060 Laptop GPU
|-
! Worker
| Intel UHD Graphics
|-
! Zusätzliche Testhardware
| Intel Arc A750 und Arc A380 als zusätzliche dGPU-Worker-Gegenchecks vorgesehen; belastbare Messwerte liegen noch nicht vor
|-
! 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
|-
! 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
|-
! Gesamtvision
| etwa 30–35 % (Scheduler, echte Workloads, N-GPU und Vulkan noch offen)
|}

== Grundprinzip ==

<pre>
Intel Worker GPU
-> MainTextureCS + PatternPhase
-> persistente Worker-Textur
-> persistenter Shared Cross-Adapter Buffer
-> monotone Shared Fence / Queue Wait
-> persistente UE-eigene FTextureRHIRef
-> stabile UExperimentalMultiGPUTexture

RTX Primary GPU
-> normales UE5-Rendering
-> TPS-Material zeigt das Worker-Ergebnis sichtbar an
</pre>

Pro Worker ist maximal ein Runtime-Job gleichzeitig in flight. Backpressure lehnt weitere Requests als <code>Busy</code> ab, bis der Slot nach der Primary-Completion wieder sicher verwendbar ist.

Jeder Worker besitzt ein eigenes <code>ID3D12Device</code>, eigene Queues, Command Lists und Ressourcen. Ein späterer Scheduler soll Rechenleistung, Fähigkeiten, Transferkosten und gewünschte Aktualisierungsrate bewerten. Vorgesehene Aufgaben sind beispielsweise SceneCapture2D, Spiegel, CCTV, Minimap, Compute oder Niagara.

== Verifizierter Entwicklungsstand ==

=== Worker-Compute ===

Ein echter, von Unreal kompilierter Global Compute Shader läuft auf der Intel UHD, während Unreal regulär über die RTX rendert. Der Test verdoppelt 64 Ganzzahlen auf dem Worker; '''64 von 64 Ergebnissen wurden korrekt verifiziert'''. Damit ist echte GPU-Arbeit auf einem zweiten, herstellerfremden Device nachgewiesen.

Zusätzlich läuft <code>MainTextureCS</code> auf der Intel-GPU. Der synchrone Debugtest erzeugt eine 64 × 64 Pixel große RGBA8-Textur; '''alle 4096 shader-generierten Pixel wurden korrekt verifiziert'''. Der normale Runtime-Pfad verwendet inzwischen einen asynchronen 128×96-Test. Der Shader liest seine Dimensionen mit <code>GetDimensions()</code>, schützt überhängende Threads durch einen Bounds-Check und wird mit <code>Dispatch(16,12,1)</code> ausgeführt. <code>PatternPhase</code> erzeugt für jeden akzeptierten Submit deterministisch einen neuen sichtbaren Inhalt. Abgewiesene Busy-Requests erhöhen die Phase nicht und erzeugen daher keine Lücken.

=== Cross-Adapter-Speicher und Synchronisation ===

* RTX und Intel öffnen denselben D3D12 Cross-Adapter Heap.
* Ein gemeinsamer Buffer wurde mit 64 Testwerten erfolgreich geprüft.
* Ein persistenter Shared Fence synchronisiert die Queues direkt von GPU zu GPU. Seine Werte steigen pro Job monoton: WorkerReady/PrimaryComplete verwenden die Paare 1/2, 3/4, 5/6 und so weiter.
* Die CPU vermittelt die GPU-Abhängigkeit nicht; Worker- und Primary-Queue verwenden <code>Signal</code> und <code>Wait</code> direkt auf der GPU.
* Der separate Readback-Verifikationstest darf weiterhin blockieren. Der normale Runtime-Pfad wartet dagegen nicht auf GPU-Leerlauf.

=== Texturtransport ===

Direkte Cross-Adapter-Texturen sind auf dem Testsystem nicht beidseitig verfügbar: Die Intel UHD meldet Unterstützung für Row-Major Cross-Adapter Textures, die RTX 5060 Laptop GPU nicht. Deshalb verwendet das Projekt einen allgemeineren Buffer-Fallback.

<pre>
Intel MainTextureCS
-> persistente Worker-Textur
-> CopyTextureRegion
-> persistenter Shared Cross-Adapter Buffer
-> Worker signalisiert WorkerReady (1, 3, 5, ...)
-> UE-Primary-Queue wartet auf WorkerReady
-> direkte Kopie in persistente UE-eigene FTextureRHIRef
-> Primary signalisiert PrimaryComplete (2, 4, 6, ...)
</pre>

Der robuste Normal-Pfad kopiert die Worker-Textur über den Shared Buffer direkt in eine von Unreal erzeugte <code>FTextureRHIRef</code>. Breite, Höhe und Row Pitch werden dynamisch aus Worker-Ressource und Transport-Metadaten übernommen. Der erfolgreiche 128×96-RGBA8-Test verwendet 512 Byte Row Pitch und 49.152 Byte Transfergröße. Die Output Registry trennt Persistent-, Pending- und Ready-Zustände sowie Inhaltsgeneration und Texturidentität. Dadurch kann eine verspätete Completion keinen neueren Output zurückrollen.

=== Non-blocking Runtime-Pfad ===

Die produktive Testlogik ist aus dem Konsolenkommando in eine gekapselte NormalPath-API verschoben. <code>SubmitWorkerTextureComputeJob()</code> reicht den Worker-Dispatch ohne CPU-Wait ein. <code>QueueNormalTextureTransfer()</code> reiht Wait, Kopie und Completion-Signal in Unreals D3D12-Kontext ein. Der normale MainTextureCS-Pfad enthält weder CPU-Fence-Waits noch Readback, <code>Map</code> oder Pixelvergleich. <code>TickNormalTextureTransfers()</code> prüft die Primary-Completion non-blocking über einen Runtime-Pump; <code>RHIEndFrame()</code> bleibt als Fallback erhalten.

Eine passende Primary-<code>FTextureRHIRef</code> wird pro Worker und Konfiguration persistent gehalten. Nach PrimaryComplete kann der nächste Job dieselbe Resource erneut verwenden; dabei führt Unreal die Übergänge <code>SRVMask -> CopyDest -> SRVMask</code> aus. Eine backend-neutrale RHI-Provider-API reicht die Ready-Textur an die Engine weiter. <code>UExperimentalMultiGPUTexture</code> hält eine stabile <code>UTexture</code> samt TextureReference und bindet die persistente <code>FTextureRHIRef</code> ohne zusätzlichen Pixel-Copy. Eine native D3D12-Resource wird weiterhin nicht blind als UE-Textur gewrappt, weil Unreals Resource-State-Buchhaltung den tatsächlichen nativen Zustand sonst nicht sicher kennt.

=== Sichtbarer TPS-Consumer ===

<code>AExperimentalMultiGPUDisplayActor</code> zeigt die Worker-Ausgabe im Third-Person-Testlevel über den Materialparameter <code>MultiGPUTexture</code> an. Damit ist der Output nicht mehr nur über Logs oder Readback nachgewiesen: Die Intel UHD erzeugt fortlaufend die Texturinhalte, während die RTX die Spielwelt und das Material rendert. <code>TextureConsumerCS</code> kann Ready-Ausgaben auf der Primary zusätzlich als SRV lesen und fünf quantisierte Samples im Debugpfad prüfen.

=== Lebensdauer und automatisches Cleanup ===

Der Normal-Pfad verwendet pro Worker genau einen persistenten Runtime-Slot. Worker-Textur, Root Signature, PSO, Descriptor Heap, Command Allocator/List und Worker-Fence werden nach der ersten kompatiblen Initialisierung wiederverwendet. Dasselbe gilt für Shared Heap/Buffer/Fence und die Transport-Command-Objekte. Der In-Flight-Job trägt nur noch die nötigen Job-, Generation- und Fence-Metadaten.

<pre>
Runtime Request
-> Completion non-blocking prüfen
-> falls Slot frei: Worker Dispatch
-> WorkerReady-Fence signalisieren
-> Primary Wait, SafeCopy und PrimaryComplete-Signal
-> Output Pending
-> Runtime-Pump oder RHIEndFrame prüft GetCompletedValue()
-> Output Ready publizieren
-> Slot wiederverwendbar
</pre>

Backpressure erlaubt maximal einen echten In-Flight-Job pro Worker. Ein Busy-Request setzt keine GPU-Arbeit ab, setzt keine Ressourcen zurück und erhöht <code>PatternPhase</code> nicht. Worker-Fence-Werte steigen mit jedem akzeptierten Submit 1, 2, 3 und so weiter; der persistente Shared Fence verwendet fortlaufend die Paare 1/2, 3/4, 5/6. Fehler nach Übergabe von Ressourcen an die GPU führen zu sicherem Retire beziehungsweise Retention statt zu vorzeitigem Reuse.

=== Texture Stream und Benchmarking ===

Der projektseitige Texture Stream akzeptiert eine beliebige positive, endliche Zielrate. Punkt und Komma sind als Dezimaltrenner möglich. Optional lässt sich die Zahl erfolgreicher Submits begrenzen; Busy- oder Failed-Versuche verbrauchen dieses Limit nicht. Der Quiet-Modus unterdrückt per-Job-Ausgaben, behält aber Start, echte Fehler und die Abschlussstatistik bei.

Die Statistik unterscheidet Timer-Ticks, angenommene Submits, Busy/Failed, Ready, In-Flight und die jeweiligen effektiven Raten. Diagnosezeitpunkte erfassen unter anderem RequestAccepted, RenderCommandExecution, WorkerSubmit, NormalTransferQueued und ReadyObserved.

{| class="wikitable"
! Test
! Ergebnis
! Aussage
|-
| 5 Hz, 20 Submits
| etwa 5 Ready/s, 20/20, kein Busy
| Entspannter Single-Slot-Betrieb
|-
| 1000 Hz, 100 Submits, quiet
| 100/100 Ready, 0 Fehler, etwa 58 Ready/s
| Backpressure begrenzt den Durchsatz sicher
|-
| 1000 Hz bei <code>t.MaxFPS 30</code>
| etwa 28–29 Ready/s trotz rund 982 Timer-Ticks/s
| Primary-/SafeCopy-/Ready-Kette ist effektiv framegekoppelt
|}

Ein zusätzlicher non-blocking Aufruf von <code>ImmediateFlush(DispatchToRHIThread)</code> erreicht hohe Render-Command-Raten, hebt die gemessene Frame-Kopplung aber nicht auf. Im 30-FPS-Test lag der RHIEndFrame-spezifische Completion-Takt praktisch exakt bei 30 Hz. Das aktuelle Problem ist damit eingegrenzt: Nicht der Stream-Timer, sondern die Primary-RHI-/D3D12-Submission der SafeCopy-Kette bestimmt die sichtbare Ready-Rate.

=== Queue-Submission-Diagnose ===

<code>MultiGPUD3D12QueueProbe</code> untersucht die Submission unabhängig vom sichtbaren Texturpfad. Neben <code>full</code>, <code>waitonly</code> und <code>signalonly</code> existieren inzwischen die Diagnosemodi <code>computeonly</code>, <code>commandonly</code>, <code>barrieronly</code>, <code>barrierprivate</code> und <code>copybuffer</code>. Als Queues stehen <code>graphics</code>, <code>copy</code>, <code>native</code>, <code>worker</code>, <code>worker-copy</code> und <code>worker-high</code> zur Verfügung. Graphics und Copy verwenden <code>RHIRunOnQueue(..., false)</code> auf UE-verwalteten Primary-Queues; die übrigen Varianten isolieren private beziehungsweise bereits vorhandene native D3D12-Queues.

Der Probe misst Request, Worker-Submit, <code>RHIRunOnQueue</code>-Aufruf und -Callback, Primary-Execute, Fence-Completion sowie Ready bis zum nächsten akzeptierten Submit. Er fügt keine CPU-Waits, Readbacks, Maps oder <code>BlockUntilGPUIdle</code> ein und beschreibt keine Textur des sichtbaren Normal-Pfads.

{| class="wikitable"
! Test
! Ergebnis
! Befund
|-
| UE Graphics, signal-only, 30 FPS
| 33,319 ms PrimaryExecute bis Ready
| UE-verwaltete Graphics-Submission skaliert mit der Frame-Dauer
|-
| UE Copy, signal-only, 30 FPS
| 32,593 ms PrimaryExecute bis Ready
| Auch die UE-verwaltete Copy Queue ist framegekoppelt
|-
| Private Primary-DIRECT-Queue, signal-only
| etwa 0,014 ms Queue/Fence-Latenz; nach Lifecycle-Fix rund 999 Ready/s bei 30 FPS
| Native Queue und Scheduler sind vollständig vom Frame entkoppelt
|-
| Worker signal-only / leere Command List
| jeweils rund 1000 Ready/s bei 30 FPS
| Worker-Queue, Fence und reine Submission sind nicht framegekoppelt
|-
| Worker <code>CopyBufferRegion</code>, 30 / 60 / 120 FPS
| 29,41 / 58,25 / 113,08 Ready/s
| Bereits eine echte 256-Byte-GPU-Kopie folgt im UE-Prozess dem Frame-Raster
|-
| Worker COPY Queue / HIGH Priority, 30 FPS
| jeweils rund 29,42 Ready/s
| Queue-Typ und Priorität beseitigen die Kopplung nicht
|-
| Standalone-D3D12 auf derselben Intel UHD
| 92.956 Copy-Jobs/s; 0,007 ms durchschnittliche Fence-Latenz
| Die Kopplung ist UE-Prozess-/Scheduling-spezifisch, keine allgemeine Intel-, WDDM- oder D3D12-Grenze
|}

Der <code>RHIRunOnQueue</code>-Callback selbst erreicht den D3D12-Submission-Thread typischerweise bereits nach etwa 0,02–0,05 ms; die Verzögerung entsteht danach in der verwalteten Queue-/Submission-Reihenfolge. <code>SubmitCommandsHint()</code> ist in UE 5.8 nur ein veralteter Alias für <code>ImmediateFlush(DispatchToRHIThread)</code> und stellt daher keinen stärkeren Submission-Mechanismus dar.

Der native Test ist ein '''Architekturbeweis, noch kein Experimental- oder Direct-Modus'''. Die zunächst gemessene Verzögerung von rund 32 ms lag zwischen der In-Flight-Freigabe und dem nächsten Request auf dem Render Thread. Für <code>signalonly/native</code> wurde der sichere Completion-/Submit-Lifecycle deshalb in den frameunabhängigen Scheduler verlegt. Danach erreichten zwei 100-Job-Läufe bei <code>t.MaxFPS 30</code> rund 999 bis 1029 Ready/s, ohne Busy oder Fehler.

Der anschließende <code>full native</code>-Test lokalisierte die verbleibende Kopplung auf echte Worker-GPU-Arbeit: WorkerSubmit bis WorkerReady benötigte bei 30, 60 und 120 FPS ungefähr 33,29, 16,93 und 8,45 ms; WorkerReady bis PrimaryReady war danach praktisch sofort. Signal-only und eine leere Command List waren schnell, Resource Barriers und eine 256-Byte-Kopie dagegen framegebunden. Ein eigenständiger D3D12-Microbenchmark auf derselben Intel UHD erreichte außerhalb von Unreal bei derselben Kopie rund 92.956 Jobs/s mit 0,007 ms mittlerer Fence-Latenz. Die genaue Ursache im UE-Prozess beziehungsweise dessen GPU-Scheduling-Kontext bleibt offen und wird vorerst bis zum Gegencheck mit der vorhandenen Intel Arc A380 geparkt.

=== Worker-Rasterpfad und RasterStream ===

<code>ExperimentalMultiGPU.TestRasterWorker</code> weist erstmals echte Rasterizer-Arbeit auf der Intel-Worker-GPU nach. <code>RasterWorkerVS</code> und <code>RasterWorkerPS</code> werden über Unreals Global-Shader-Pfad kompiliert und für ein natives Worker-Graphics-PSO verwendet. Ein persistentes 128×96-RGBA8-RenderTarget besitzt RTV, leere Root Signature und eine DIRECT-Command-List. Der Vertex Shader erzeugt drei Vertices über <code>SV_VertexID</code>; der Pixel Shader schreibt interpolierte RGB-Farben.

Der Job wechselt das RenderTarget von <code>COPY_SOURCE</code> nach <code>RENDER_TARGET</code>, führt Clear und <code>DrawInstanced(3,1,0,0)</code> aus und wechselt anschließend zurück nach <code>COPY_SOURCE</code>. Danach verwendet er unverändert den robusten Normalpfad aus Cross-Adapter-Shared-Buffer, Primary SafeCopy, persistenter <code>FTextureRHIRef</code>, <code>UExperimentalMultiGPUTexture</code> und DisplayActor. Der Runtime-Test meldete einen akzeptierten Submit und <code>RasterWorker READY</code> für Generation 1; die 128×96-UTexture wurde erfolgreich gebunden.

Der einmalige Test wurde außerdem zu einem frei konfigurierbaren RasterStream ausgebaut. Ein sichtbarer Lauf mit 10 Hz und 50 erfolgreichen Submits endete mit 50 Ready-Ausgaben, 0 Busy und 0 Fehlern bei etwa 9,90 Ready/s. Primary-Textur und Materialbindung blieben dabei persistent.

=== Raster3D mit echten Vertex- und Indexbuffern ===

Der Worker besitzt inzwischen einen kleinen eigenständigen 3D-Rasterpfad mit perspektivischer Kamera, Model-View-Projection-Matrix als Root Constants, D32_FLOAT-Depth-Buffer und Depth-Test. Der finale Testwürfel verwendet 24 POSITION/COLOR-Vertices, 36 <code>uint16</code>-Indices und <code>DrawIndexedInstanced(36,1,0,0,0)</code>; sechs getrennte Seitenfarben machen Ausrichtung und Rotation sichtbar nachvollziehbar.

Die statischen Meshdaten werden einmalig über private Upload-Buffer in DEFAULT-Heaps übertragen. Der Init-Fence wird non-blocking über <code>GetCompletedValue()</code> beobachtet. Der eigentliche Runtime-Renderpfad enthält weiterhin keine CPU-Waits und keine Maps.

=== UE-Static-Meshes auf der Worker-GPU ===

<code>StaticMeshWorker</code> extrahiert echte LOD0-Geometrie aus <code>UStaticMesh</code>-Assets. POSITION und NORMAL sowie <code>uint32</code>-Indices werden in POD-Daten überführt, einmalig asynchron in eigene Worker-VB/IB hochgeladen und anschließend per <code>DrawIndexedInstanced</code> gerendert. Assetpfade sind dynamisch; Auto-Fit richtet Kamera beziehungsweise Modellmaßstab an den Bounds aus.

Sichtbar korrekt getestet wurden:

{| class="wikitable"
! Asset
! Vertices
! Indices
|-
| Sphere
| 559
| 2880
|-
| Cube
| 54
| 144
|-
| Cylinder
| 334
| 1536
|}

=== Multi-Mesh Worker-Szene ===

<code>StaticMeshScene</code> rendert Sphere, Cube und Cylinder gemeinsam in einen Color-/Depth-Frame. Der verifizierte Test umfasst insgesamt 947 Vertices und 4560 Indices, drei <code>DrawIndexedInstanced</code>-Aufrufe und nur einen anschließenden Cross-Adapter-/Normal-SafeCopy-Transfer. Damit ist nicht mehr nur ein synthetisches Primitive, sondern mehrere echte UE-Meshes mit gemeinsamer Tiefenprüfung im Worker-Frame sichtbar nachgewiesen.

=== WorldStaticMeshScene ===

<code>ExperimentalMultiGPUWorldStaticMeshScene.cpp</code> sammelt im Engine-Layer bis zu acht sichtbare <code>UStaticMeshComponent</code>s von Actors mit dem Tag <code>MultiGPUWorker</code>. Meshdaten und World-Transforms werden im Game Thread in reine POD-Strukturen und 4×4-Matrizen kopiert. D3D12RHI erhält keine <code>UObject</code>-Pointer. Mehrere Instanzen desselben Meshes teilen den persistenten Worker-Mesh-Cache und unterscheiden sich nur durch Modelmatrix und Draw Call.

Der Pfad wurde inzwischen sichtbar im PIE-Level verifiziert. Drei getaggte Static-Mesh-Actors erschienen mit ihren tatsächlichen relativen Positionen, Rotationen und Skalierungen im Worker-Bild. Die zentrale Koordinatenumrechnung lautet:

<pre>Worker (X, Y, Z) = (UE Y, UE X, -UE Z)</pre>

Die Transformation besitzt die Determinante +1 und ist damit keine Spiegelung. Das notwendige horizontale Spiegeln erfolgt ausschließlich auf der Presentation-Plane, nicht im Worker-Renderpfad.

=== Kontinuierlicher WorldStaticMeshSceneStream ===

<code>StartWorldStaticMeshSceneStream</code> erfasst die getaggte Szene fortlaufend im Game Thread. Reine Änderungen an Transform oder Kamera lösen keinen erneuten Mesh-Upload aus. Hinzugekommene, entfernte, unsichtbare oder umgetaggte Components werden im nächsten Snapshot berücksichtigt. Single-Slot-Backpressure verhindert einen wachsenden Rückstau.

Ein verifizierter 30-Hz-Lauf endete nach 31,184 Sekunden mit 835 Ticks, 691 angenommenen Submits, 144 Busy, 0 Fehlern und 691 Ready-Frames. Die effektive Ready-Rate betrug 22,16 Hz. Dieser Test belegt die funktionale Live-Aktualisierung; die Rate war noch kein Optimierungsziel.

=== SceneCapture2D als Worker-Kamera ===

<code>TestSceneCaptureStaticMeshScene</code> verwendet eine echte <code>ASceneCapture2D</code> beziehungsweise <code>USceneCaptureComponent2D</code> aus der laufenden PIE-Welt als Kameraquelle. Der empfohlene Editor-Weg ist das Component Tag <code>MultiGPUWorkerCamera</code> auf der <code>CaptureComponent2D</code>; ein gleichnamiges Actor-Tag bleibt nur als Legacy-Fallback.

Ausgelesen werden World Location, Rotation, Forward/Right/Up, <code>FOVAngle</code> und <code>ProjectionType</code>. Orthografische Projektion wird derzeit sauber abgelehnt. Die SceneCapture2D liefert ausschließlich Kameradaten: Ihr UE-RenderTarget wird weder gelesen noch kopiert. Die Intel-Worker-GPU rendert die Geometrie selbst. Kamera und Actors werden gemeinsam mit <code>SceneScale = 0.01</code> in Worker-Koordinaten überführt; Auto-Fit und Scene-Recentering sind in diesem Modus deaktiviert.

Die 128×96-Worker-Projektion verwendet ein Seitenverhältnis von 4:3 und interpretiert <code>FOVAngle</code> als horizontales FOV. Nach den Orientierungstests wird nur die Anzeige über <code>SetRelativeScale3D(FVector(-4.0f, -3.0f, 1.0f))</code> korrigiert; dies entspricht <code>U' = 1-U</code> und <code>V' = 1-V</code>.

=== Live SceneCaptureStaticMeshSceneStream ===

<code>StartSceneCaptureStaticMeshSceneStream</code> liest Kamera-Transform, Kamerabasis, FOV und aktuelle Actor-Transforms pro Snapshot neu im Game Thread. Der Worker erhält weiterhin ausschließlich POD-Daten, verwendet den persistenten Mesh-Cache sowie ein gemeinsames Color- und D32-Depth-Target und führt pro akzeptiertem Frame genau einen Cross-Adapter-/Normal-SafeCopy-Transfer aus.

Der Quiet-Test

<pre>ExperimentalMultiGPU.StartSceneCaptureStaticMeshSceneStream 30 300 quiet</pre>

lieferte in 10,084 Sekunden 301 Ticks, 300 Submits, 1 Busy, 0 Fehler und 300 Ready-Frames. Die effektive Ready-Rate betrug 29,75 Hz. Bewegungen der Kamera und Actors sowie FOV-Änderungen erschienen live auf der Display-Plane. Damit ist erstmals ein kleiner SceneCapture-/CCTV-artiger Worker-Kanal vollständig funktional nachgewiesen.

=== Dynamische SceneCapture-Auflösung ===

Die SceneCapture-Ausgabe ist nicht mehr fest auf 128×96 Pixel begrenzt. <code>ExperimentalMultiGPU.SetSceneCaptureResolution <Width> <Height></code> setzt ganzzahlige Dimensionen von 1 bis 4096; <code>GetSceneCaptureResolution</code> zeigt die aktive Einstellung. 128×96 bleibt der Standard. Während ein SceneCapture-Stream läuft, wird ein Auflösungswechsel absichtlich abgelehnt, damit keine In-Flight-Ressourcen ausgetauscht werden.

Color Target, D32-Depth-Buffer, Row Pitch, Shared-Buffer-Transport, SafeCopy, persistente Primary-Textur und <code>UExperimentalMultiGPUTexture</code> übernehmen die gewählten Dimensionen. Projektion und Display-Plane verwenden das echte Seitenverhältnis. Die bestätigte Anzeigeorientierung <code>U' = 1-U</code> und <code>V' = 1-V</code> bleibt eine reine Presentation-Korrektur; Worker-Basis und Kameramathematik ändern sich nicht.

=== Scheduler-Korrektur bei SceneCapture ===

Ein 1920×1080-Test mit 25 Hz erreichte zunächst trotz fehlerfreier Frames nur 13,90 Ready-Hz und erzeugte 222 Busy-Ticks. Ursache war kein GPU-Limit, sondern ein Polling-Aliasing: Eine frühe Game-Thread-Prüfung konnte den Timer-Slot verwerfen, obwohl die Completion kurz darauf im CoreTicker/RHI-Pump sichtbar geworden wäre.

Die frühe <code>IsRuntimeTextureUpdateInFlight()</code>-Prüfung wurde für diesen Stream entfernt. Der Pending-Request bleibt als Backpressure-Gate erhalten; die maßgebliche Busy-Entscheidung fällt nun erst im Render Command nach <code>TickNormalTextureTransfers(nullptr, true)</code>. Single-Slot, POD-Snapshots und non-blocking <code>GetCompletedValue()</code> bleiben erhalten. Es wurden weder CPU-Waits noch zusätzliche Threads eingeführt.

Nach der Korrektur erreicht 1080p bei 25 Hz 24,79 Ready-Hz mit 1 Busy; bei 30 Hz sind es 29,43 Ready-Hz mit 4 Busy.

=== Skalierung bis 4K60 ===

Die Pipeline wurde von 640×360 bis 3840×2160 getestet. Bei 640×360/30 Hz und 1280×720/30 Hz wurden 29,85 beziehungsweise 29,82 Ready-Hz ohne Busy erreicht. 1920×1080/60 Hz lieferte 59,40 Ready-Hz ohne Busy, 2560×1440/60 Hz 59,21 Ready-Hz mit 1 Busy und 3840×2160/60 Hz 59,02 Ready-Hz mit 2 Busy.

Ein zusätzlicher 4K60-Stresstest mit acht Static-Mesh-Instanzen und drei gecachten Unique Meshes erreichte in 5,049 Sekunden '''300 von 300 Ready-Frames, 0 Busy, 0 Fehler und 59,42 effektive Ready-Hz'''. Acht Draw Calls, gemeinsamer Depth Buffer, Cross-Adapter-Transport und SafeCopy liefen dabei im vorhandenen Single-Slot. Das ist ein Stabilitätsnachweis der aktuellen Mini-Szene, kein allgemeiner GPU-Benchmark.

=== Skeletal Mesh in Reference Pose ===

<code>ExperimentalMultiGPU.TestSkeletalMeshWorker</code> erweitert den Geometriepfad auf <code>USkeletalMeshComponent</code>. Der Engine-Layer sucht deterministisch die erste sichtbare, getaggte Komponente und extrahiert LOD0-Positionen, Normalen, Indices und Render Sections. D3D12RHI erhält wie bisher ausschließlich POD-Geometrie und Modelmatrizen.

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.

== Test- und Diagnosebefehle ==

{| class="wikitable"
! Befehl
! Zweck
|-
| <code>ExperimentalMultiGPU.TestComputeShader</code>
| Führt den vollständigen Worker-Compute-Testpfad aus. Er enthält auch ältere Debug- und Regressionstests mit CPU-Readback und ist daher nicht mit dem reinen asynchronen Runtime-Pfad gleichzusetzen.
|-
| <code>ExperimentalMultiGPU.TestTextureConsumer</code>
| Testet <code>TextureConsumerCS</code> auf der Primary-GPU. Die aktuelle Ready-Textur wird über UE-RHI gelesen und anhand ausgewählter Testpixel per Debug-Readback geprüft.
|-
| <code>ExperimentalMultiGPU.TestTextureBridge</code>
| Prüft die Bridge von der fertigen <code>FTextureRHIRef</code> zu <code>UExperimentalMultiGPUTexture</code> und damit den UE- und materialtauglichen Texturpfad.
|-
| <code>ExperimentalMultiGPU.SpawnDisplayActor</code>
| Spawnt den Test-Actor mit Plane im Spiel. Das Material zeigt darauf die vom Worker erzeugte Textur an.
|-
| <code>ExperimentalMultiGPU.TestRasterWorker</code>
| Rasterisiert auf der Worker-GPU ein echtes RGB-Dreieck per Vertex- und Pixel-Shader und transportiert das Ergebnis über den normalen SafeCopy-Pfad bis zum DisplayActor.
|-
| <code>ExperimentalMultiGPU.StartRasterStream</code> / <code>ExperimentalMultiGPU.StopRasterStream</code>
| Startet beziehungsweise stoppt den kontinuierlichen RGB-Dreieck-RasterStream mit frei wählbarer Zielrate, optionalem Submit-Limit und Quiet-Modus.
|-
| <code>ExperimentalMultiGPU.TestRaster3DWorker</code>
| Rendert einmalig den perspektivischen 3D-Testwürfel mit Depth Buffer und echten Vertex-/Indexbuffern.
|-
| <code>ExperimentalMultiGPU.StartRaster3DStream</code> / <code>ExperimentalMultiGPU.StopRaster3DStream</code>
| Startet beziehungsweise stoppt den kontinuierlichen Raster3D-Test.
|-
| <code>ExperimentalMultiGPU.TestStaticMeshWorker [AssetPath]</code>
| Extrahiert und rendert LOD0-Geometrie eines UE-Static-Mesh-Assets; ohne optionalen Pfad wird das konfigurierte Testasset verwendet.
|-
| <code>ExperimentalMultiGPU.TestStaticMeshScene</code>
| Rendert Sphere, Cube und Cylinder gemeinsam mit drei Draw Calls und einem anschließenden Transfer.
|-
| <code>ExperimentalMultiGPU.TestWorldStaticMeshScene</code>
| Rendert einen einmaligen POD-Snapshot der sichtbaren, mit <code>MultiGPUWorker</code> getaggten StaticMeshComponents aus der laufenden World. Der sichtbare PIE-Nachweis ist erfolgreich.
|-
| <code>ExperimentalMultiGPU.StartWorldStaticMeshSceneStream [Hz] [MaxSuccessfulSubmits] [quiet]</code> / <code>StopWorldStaticMeshSceneStream</code>
| Startet beziehungsweise stoppt den kontinuierlichen Stream der getaggten UE-Welt mit Live-Transforms und persistentem Mesh-Cache.
|-
| <code>ExperimentalMultiGPU.SetSceneCaptureResolution <Width> <Height></code> / <code>GetSceneCaptureResolution</code>
| Setzt beziehungsweise zeigt die gemeinsame SceneCapture-Auflösung. Erlaubt sind ganzzahlige Werte von 1 bis 4096 je Achse; Änderungen während eines laufenden Streams werden abgelehnt.
|-
| <code>ExperimentalMultiGPU.TestSceneCaptureStaticMeshScene</code>
| Rendert einen einmaligen Worker-Snapshot aus Sicht der mit <code>MultiGPUWorkerCamera</code> markierten SceneCapture2D-Kamera.
|-
| <code>ExperimentalMultiGPU.StartSceneCaptureStaticMeshSceneStream [Hz] [MaxSuccessfulSubmits] [quiet]</code> / <code>StopSceneCaptureStaticMeshSceneStream</code>
| Startet beziehungsweise stoppt den Live-Worker-Kanal mit fortlaufend aktualisierten Kamera-, FOV- und Actor-Daten.
|-
| <code>ExperimentalMultiGPU.TestSkeletalMeshWorker</code>
| Rendert das erste sichtbare, getaggte Skeletal Mesh in LOD0 und Reference Pose sectionsweise auf der Worker-GPU.
|-
| <code>ExperimentalMultiGPU.StartTextureStream</code>
| Startet den sichtbaren Normal-Pfad: Worker-Textur → Cross-Adapter-Transfer → SafeCopy → UE-Textur → Material.
|-
| <code>ExperimentalMultiGPU.StopTextureStream</code>
| Verhindert weitere Submits des laufenden Streams. Ein bereits eingereichter GPU-Job darf noch sicher fertig werden.
|-
| <code>ExperimentalMultiGPU.StartQueueProbe</code>
| Startet den Diagnose-Benchmark für Primary-Queue-, Fence- und Submission-Verhalten. Der Probe verändert die sichtbare Textur nicht.
|}

=== Texture Stream ===

Grundsyntax:

<pre>
ExperimentalMultiGPU.StartTextureStream [Hz] [MaxSuccessfulSubmits] [quiet]
</pre>

{| class="wikitable"
! Beispiel
! Wirkung
|-
| <code>ExperimentalMultiGPU.StartTextureStream</code>
| Standardmäßig etwa 5 Hz, ohne Submit-Limit.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 37.5</code>
| Fordert 37,5 Hz ohne Submit-Limit an. Sowohl <code>37.5</code> als auch <code>37,5</code> werden akzeptiert.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 1000 100</code>
| Fordert 1000 Hz an und stoppt nach exakt 100 erfolgreichen Submits.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 1000 100 quiet</code>
| Wie zuvor, unterdrückt aber Per-Job- und Busy-Logspam.
|}

Die Hz-Angabe ist eine '''Ziel- beziehungsweise Request-Frequenz'''. <code>1000</code> bedeutet daher nicht automatisch 1000 fertige Texturen pro Sekunde. Die tatsächliche Rate hängt unter anderem von Timer, Submission, Backpressure, Queue-Latenz und Slot-Lifecycle ab. <code>MaxSuccessfulSubmits</code> zählt nur angenommene Submits; Busy- und Failed-Versuche verbrauchen das Limit nicht.

=== QueueProbe ===

Grundsyntax:

<pre>
ExperimentalMultiGPU.StartQueueProbe <Hz> <MaxSubmits> [quiet] [Mode] [Queue]
</pre>

{| class="wikitable"
! Modus
! Ausgeführter Pfad
|-
| <code>full</code>
| Worker Compute → Cross-Adapter-Transfer → Primary Wait → Copy → Completion Fence.
|-
| <code>waitonly</code>
| Worker Compute → Cross-Adapter-Transfer → Primary wartet auf WorkerReadyFence → Completion Fence. Es findet keine Texturkopie statt.
|-
| <code>signalonly</code>
| Keine Textur, kein Worker-Wait und keine Kopie; nur Queue und Fence. Dieser Modus isoliert das Queue-Verhalten.
|-
| <code>commandonly</code>
| Reicht eine leere echte Worker-Command-List ein und trennt Command-Submission von GPU-Arbeit.
|-
| <code>barrieronly</code> / <code>barrierprivate</code>
| Isoliert Resource-Barriers auf Worker-Ressourcen beziehungsweise einer privaten Testtextur.
|-
| <code>copybuffer</code>
| Führt eine minimale echte <code>CopyBufferRegion</code>-Operation über 256 Byte aus.
|}

{| class="wikitable"
! Queue
! Bedeutung
|-
| <code>graphics</code>
| Vorhandene UE Primary Graphics-/Direct-Queue über <code>RHIRunOnQueue</code>.
|-
| <code>copy</code>
| Vorhandene UE Primary Copy Queue über <code>RHIRunOnQueue</code>.
|-
| <code>native</code>
| Vollständig private native D3D12-DIRECT-Queue auf der Primary; reine Diagnose, kein fertiger Experimental-Modus.
|-
| <code>worker</code>
| Vorhandene native Worker-DIRECT-Queue.
|-
| <code>worker-copy</code>
| Separate native Worker-COPY-Queue.
|-
| <code>worker-high</code>
| Separate Worker-DIRECT-Queue mit hoher Priorität.
|}

Typische Beispiele:

<pre>
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet full graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet waitonly graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly copy
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly native
</pre>

Der letzte Befehl ist aktuell die wichtigste isolierte Gegenprobe. Mit der privaten nativen Queue wurde bei 30 FPS eine durchschnittliche Latenz <code>primaryExecuteToReadyAvgMs = 0.014 ms</code> gemessen.

=== Benchmark-CVars ===

{| class="wikitable"
! CVar
! Zweck
|-
| <code>r.VSync 0</code>
| Deaktiviert VSync, damit es die Messung nicht begrenzt.
|-
| <code>t.MaxFPS 30</code> <code>t.MaxFPS 60</code> <code>t.MaxFPS 120</code>
| Setzt die Engine-Framerate für reproduzierbare Frame-Coupling-Tests.
|-
| <code>t.MaxFPS 0</code>
| Entfernt das normale <code>t.MaxFPS</code>-Limit. Dieser Lauf ist als zusätzliche Diagnose-Gegenprobe vorgesehen.
|}

== 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.

== Historische Vorläufer ==

Die Grundidee heterogener Multi-GPU-Nutzung ist nicht neu. Bereits mit der Einführung von Direct3D 12 entstanden mehrere Versuche, integrierte und dedizierte GPUs gemeinsam zu verwenden. Eine allgemein einsetzbare Lösung für moderne UE5-Spiele hat sich daraus jedoch nicht entwickelt.

=== Microsoft und Epic: UE4 Elemental Demo (2015) ===

Microsoft zeigte eine angepasste Unreal-Engine-4-Version der Elemental-Demo, bei der eine NVIDIA-GPU und eine Intel-iGPU gemeinsam arbeiteten. Das erklärte Ziel war, ansonsten ungenutzte Grafikleistung in Hybrid-Systemen zu verwenden. Dieser Versuch ist der Grundidee des Projekts besonders ähnlich, blieb aber eine technische Demonstration.

=== Intel: D3D12 Multi-Adapter Sample (2015) ===

Intels Beispiel kombinierte eine GeForce 840M mit Intel HD Graphics 5500. Beide GPUs berechneten getrennte Teile einer einfach parallelisierbaren Raytracing-Szene. Cross-Adapter-Ressourcen und Shared Fences führten die Ergebnisse anschließend zusammen. Intel berichtete in diesem Test von nahezu halbierter Framezeit, warnte jedoch ausdrücklich davor, das Ergebnis unmittelbar auf reale Spiele zu übertragen.

=== Ashes of the Singularity ===

Die Nitrous Engine von ''Ashes of the Singularity'' setzte Direct3D-12-Explicit-Multiadapter in einem veröffentlichten Spiel ein. Dabei konnten auch unterschiedliche GPU-Modelle und Hersteller zusammenarbeiten. Das war ein wichtiger Praxisnachweis, blieb in der Spielebranche aber eine seltene Ausnahme.

=== Weitere verwandte Ansätze ===

* ''Rise of the Tomb Raider'' erhielt explizite Direct3D-12-Multi-GPU-Unterstützung, vor allem für klassische Kombinationen ähnlicher GPUs.
* NVIDIA VR SLI wies bei Virtual Reality jeder GPU ein Auge zu. Das verteilt unabhängige Ansichten, bleibt jedoch NVIDIA-spezifisch.
* Unreal nDisplay kann Viewports oder Frustums auf weitere GPUs beziehungsweise Prozesse auslagern und das fertige Bild zur Ausgabe-GPU zurückführen. Der Einsatzbereich ist hauptsächlich Virtual Production.
* Forschung und High-Performance Computing verwenden seit Jahren Scheduler für heterogene GPUs, allerdings überwiegend für Compute- und Datenverarbeitungsaufgaben statt für einen allgemeinen UE5-Echtzeitrenderer.

=== Abgrenzung dieses Projekts ===

Das Projekt erfindet Direct3D-12-Explicit-Multiadapter nicht neu. Sein eigener Ansatz liegt in der Kombination aus tiefer UE5.8-RHI-Integration, UE-kompilierten Shadern auf unabhängigen Worker-Devices, frei wählbaren Spiel- und Compute-Workloads, Capability- und Performance-Scheduler, mehreren Fallback-Pfaden sowie dem langfristigen Ziel beliebiger Hersteller und mehrerer Worker.

== Vergleich mit anderen Multi-GPU-Verfahren ==

{| class="wikitable"
! Verfahren
! Arbeitsweise
! Verhältnis zu diesem Projekt
|-
| SLI / CrossFire
| Treiber- beziehungsweise Verbundlösung für meist ähnliche GPUs; häufig wird die Bildarbeit verteilt.
| Dieses Projekt benötigt keinen herstellerspezifischen GPU-Verbund und weist Aufgaben ausdrücklich selbst zu.
|-
| AFR (Alternate Frame Rendering)
| GPU 1 rendert einen Frame, GPU 2 den nächsten.
| Das Projekt verteilt unabhängige Aufgaben statt aufeinanderfolgender Frames. Dadurch werden Frame-Abhängigkeiten und typisches AFR-Pacing vermieden.
|-
| SFR (Split Frame Rendering)
| Mehrere GPUs bearbeiten Bereiche desselben Frames.
| Erfordert enge Lastverteilung und viel Datenaustausch. Das Projekt bevorzugt vollständig abgrenzbare Workloads und überträgt deren Ergebnis.
|-
| Direct3D 12 Linked Multiadapter
| Mehrere vom Treiber verbundene GPUs erscheinen als Knoten eines logischen Adapters.
| Eignet sich eher für eng kompatible GPUs. Das Projekt verwendet unabhängige Devices (Unlinked/Explicit Multiadapter) und unterstützt dadurch heterogene Herstellerkombinationen.
|-
| Direct3D 12 Unlinked / Explicit Multiadapter
| Die Anwendung verwaltet getrennte Adapter, Ressourcen und Synchronisation selbst.
| Das ist die technische Familie des Projekts. Hinzu kommen die eigene UE5-RHI-Integration, Workload-Ziele, Fallbacks und der geplante Scheduler.
|-
| UE nDisplay mGPU / Multi-Process
| Separate GPUs rendern bestimmte Viewports oder Frustums, vor allem für Virtual Production; Ergebnisse werden zur Ausgabe-GPU kopiert.
| Ähnliche Idee der aufgabenweisen Trennung, aber für einen anderen Einsatzbereich. Dieses Projekt zielt auf allgemeine Spiel- und Compute-Workloads innerhalb der Engine.
|-
| Vulkan Device Groups
| Ähnliche physische GPUs können ein gemeinsames logisches Device bilden.
| Für beliebige heterogene GPUs meist ungeeignet, da Geräte einer Gruppe nahezu gleiche Eigenschaften besitzen müssen. Eine spätere Vulkan-Portierung benötigt daher wahrscheinlich getrennte Devices und External Memory/Semaphores.
|}

SLI und CrossFire bezeichnen den Verbund; AFR und SFR beschreiben mögliche Verteilungsmethoden innerhalb solcher Systeme. Sie sind deshalb nicht vollständig getrennte Kategorien.

== Vorteile der geplanten Variante ==

* '''Herstellerunabhängig:''' NVIDIA, AMD und Intel können grundsätzlich kombiniert werden.
* '''Vorhandene Hardware nutzen:''' Auch eine sonst wenig genutzte integrierte GPU kann geeignete Nebenaufgaben übernehmen.
* '''Aufgaben statt Frames verteilen:''' Spiegel, Minimap oder Compute können mit eigener Auflösung und Aktualisierungsrate laufen.
* '''Keine identischen GPUs erforderlich:''' Unterschiedliche Fähigkeiten können gezielt genutzt werden.
* '''Kontrollierter Datenaustausch:''' Nur das benötigte Ergebnis muss zurück zur Primary-GPU.
* '''Robuste Fallback-Idee:''' Wenn direkte Texturen nicht gemeinsam nutzbar sind, bleibt der Shared-Buffer-Pfad.
* '''Erweiterbar:''' Scheduler, manuelles Mapping und mehrere Worker sind als spätere Stufen vorgesehen.

== Nachteile und technische Risiken ==

* '''Hoher Entwicklungsaufwand:''' Geräte, Ressourcen, Zustände, Fences, Fehlerfälle und UE-Lebenszyklen müssen selbst verwaltet werden.
* '''Transfer kann den Gewinn aufzehren:''' Cross-Adapter Heaps liegen laut D3D12 nicht automatisch im schnellen lokalen VRAM. Bandbreite und Latenz müssen für jeden Workload gemessen werden.
* '''VRAM wird nicht einfach addiert:''' Benötigte Ressourcen können auf mehreren GPUs vorliegen und zusätzlichen Speicher verbrauchen.
* '''Langsame Worker können bremsen:''' Eine Aufgabe lohnt sich nur, wenn Rechengewinn größer als Übergabe-, Warte- und Kopierkosten ist.
* '''Nicht jeder Workload ist unabhängig:''' Hauptansicht, Lumen, Nanite und stark gekoppelte Renderpässe besitzen viele Abhängigkeiten und sind schwieriger auszulagern.
* '''Hardwareunterschiede:''' Formate, Shader-Funktionen, Queue-Fähigkeiten und Cross-Adapter-Support müssen pro GPU geprüft werden.
* '''Wartungsrisiko:''' Eingriffe in private D3D12RHI-Dateien können bei Engine-Updates angepasst werden müssen.
* '''Produktionsreife fehlt noch:''' Ressourcenpools, Timeouts, Device-Lost-Wiederherstellung, Scheduler und echte Szenentests sind offen.

== Wann die Variante sinnvoll ist ==

Am aussichtsreichsten sind Aufgaben mit viel eigener Rechenarbeit, einem relativ kleinen Endergebnis und wenigen Abhängigkeiten zur Hauptszene. Gute frühe Kandidaten sind unabhängige Compute-Aufgaben sowie Scene Captures, die nicht in jedem Frame aktualisiert werden müssen. Weniger geeignet sind winzige Aufgaben mit großem Transfer oder Renderpässe, die ständig auf Ressourcen der Primary-GPU zugreifen.

Die entscheidende Regel für den späteren Scheduler lautet daher:

<pre>
Worker-Gewinn > Vorbereitung + Datentransfer + Synchronisation + Rückintegration
</pre>

== Bekannte Grenzen des Proof of Concepts ==

* 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 sichtbarer Runtime-Slot. Mehrere parallele In-Flight-Jobs und Ringbuffer fehlen noch.
* Praktisch getestet ist Primary plus ein Worker. Mehrere Worker sind architektonisch vorgesehen, aber noch nicht praktisch validiert.
* World- und SceneCapture-Pfade verarbeiten pro Snapshot höchstens acht sichtbare <code>UStaticMeshComponent</code>s.
* 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.
* <code>USkeletalMesh</code> ist bislang ein LOD0-ReferencePose-Proof. Bone-Skinning, Animation, Morph Targets und Cloth fehlen.
* Die Workload-Registry sammelt Metadaten und Messwerte, führt aber noch keine automatische Zuweisung, Auflösungsänderung oder Ratenanpassung aus.
* Worker GPU Timing V1 misst nur den Rasterabschnitt. Cross-Adapter-Transfer und Primary-SafeCopy fehlen noch im Kostenmodell.
* 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.
* QueueProbe und private native Queues bleiben Diagnosepfade; Experimental/Direct ist noch nicht implementiert.
* 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.
* Linux/Vulkan mit getrennten Devices, External Memory und externer Synchronisation ist noch nicht implementiert.

== Roadmap ==

# Cross-Adapter Transfer Timing V1: Worker-ColorTarget → Shared Buffer separat messen.
# Primary SafeCopy Timing ergänzen und die Integrationskosten getrennt halten.
# Kostenmodell V1 aus Worker-Raster, Transfer und Primary-Integration pro Workload ableiten.
# Weitere echte Workload-Klassen wie CCTV, Spiegel, Minimap und Compute anbinden; später Post Process oder neuronale Aufgaben untersuchen.
# D3D12-Pfade mit Intel Arc A750/A380 und RX 6900 XT in unterschiedlichen Primary-/Worker-Rollen gegenprüfen.
# Scheduler und Autotuner auf GPU-Eignung und gemessene Nettokosten statt Auslastungsprozent aufbauen.
# Material-, Textur- und Culling-Pfade für realistischere Worker-Szenen ergänzen.
# Skeletal Skinning mit Bone-Matrizen und Skin Weights erst bei einem echten animierten Worker-Workload ausbauen.
# 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 ==

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 ==

* 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/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://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://www.intel.com/content/dam/develop/external/us/en/documents/multi-adapter-support-in-directx-12-594015.pdf Intel: Multi-Adapter Support in DirectX 12]
* [https://devblogs.microsoft.com/directx/ashes-of-the-singularity-makes-gaming-history-with-directx-12/ Microsoft: Ashes of the Singularity und heterogene Adapter]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/nvidia-sli-alternative-frame-rendering-in-unreal-engine Epic: NVIDIA SLI Alternate Frame Rendering]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/multi-process-rendering-with-unreal-engine Epic: Multi-Process Rendering]
* [https://registry.khronos.org/vulkan/specs/latest/pdf/vkspec.pdf Khronos: Vulkan Specification – Device Groups]

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Multi-GPU]]
[[Kategorie:Direct3D 12]]
[[Kategorie:Experimentell]]

UE5 Heterogeneous Multi-GPU

2026-09-14T18:24:40Z

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

{{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.}}

'''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.

{| class="wikitable"
|+ Projektstatus
|-
! Engine / Plattform
| Unreal Engine 5.8 Source Build / Windows / Direct3D 12
|-
! Testsystem
| Lenovo LOQ 17IRX10
|-
! Primary
| NVIDIA GeForce RTX 5060 Laptop GPU
|-
! Worker
| Intel UHD Graphics
|-
! Zusätzliche Testhardware
| Intel Arc A750 und Arc A380 als zusätzliche dGPU-Worker-Gegenchecks vorgesehen; belastbare Messwerte liegen noch nicht vor
|-
! 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
|-
! 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
|-
! Gesamtvision
| etwa 30–35 % (Scheduler, echte Workloads, N-GPU und Vulkan noch offen)
|}

== Grundprinzip ==

<pre>
Intel Worker GPU
-> MainTextureCS + PatternPhase
-> persistente Worker-Textur
-> persistenter Shared Cross-Adapter Buffer
-> monotone Shared Fence / Queue Wait
-> persistente UE-eigene FTextureRHIRef
-> stabile UExperimentalMultiGPUTexture

RTX Primary GPU
-> normales UE5-Rendering
-> TPS-Material zeigt das Worker-Ergebnis sichtbar an
</pre>

Pro Worker ist maximal ein Runtime-Job gleichzeitig in flight. Backpressure lehnt weitere Requests als <code>Busy</code> ab, bis der Slot nach der Primary-Completion wieder sicher verwendbar ist.

Jeder Worker besitzt ein eigenes <code>ID3D12Device</code>, eigene Queues, Command Lists und Ressourcen. Ein späterer Scheduler soll Rechenleistung, Fähigkeiten, Transferkosten und gewünschte Aktualisierungsrate bewerten. Vorgesehene Aufgaben sind beispielsweise SceneCapture2D, Spiegel, CCTV, Minimap, Compute oder Niagara.

== Verifizierter Entwicklungsstand ==

=== Worker-Compute ===

Ein echter, von Unreal kompilierter Global Compute Shader läuft auf der Intel UHD, während Unreal regulär über die RTX rendert. Der Test verdoppelt 64 Ganzzahlen auf dem Worker; '''64 von 64 Ergebnissen wurden korrekt verifiziert'''. Damit ist echte GPU-Arbeit auf einem zweiten, herstellerfremden Device nachgewiesen.

Zusätzlich läuft <code>MainTextureCS</code> auf der Intel-GPU. Der synchrone Debugtest erzeugt eine 64 × 64 Pixel große RGBA8-Textur; '''alle 4096 shader-generierten Pixel wurden korrekt verifiziert'''. Der normale Runtime-Pfad verwendet inzwischen einen asynchronen 128×96-Test. Der Shader liest seine Dimensionen mit <code>GetDimensions()</code>, schützt überhängende Threads durch einen Bounds-Check und wird mit <code>Dispatch(16,12,1)</code> ausgeführt. <code>PatternPhase</code> erzeugt für jeden akzeptierten Submit deterministisch einen neuen sichtbaren Inhalt. Abgewiesene Busy-Requests erhöhen die Phase nicht und erzeugen daher keine Lücken.

=== Cross-Adapter-Speicher und Synchronisation ===

* RTX und Intel öffnen denselben D3D12 Cross-Adapter Heap.
* Ein gemeinsamer Buffer wurde mit 64 Testwerten erfolgreich geprüft.
* Ein persistenter Shared Fence synchronisiert die Queues direkt von GPU zu GPU. Seine Werte steigen pro Job monoton: WorkerReady/PrimaryComplete verwenden die Paare 1/2, 3/4, 5/6 und so weiter.
* Die CPU vermittelt die GPU-Abhängigkeit nicht; Worker- und Primary-Queue verwenden <code>Signal</code> und <code>Wait</code> direkt auf der GPU.
* Der separate Readback-Verifikationstest darf weiterhin blockieren. Der normale Runtime-Pfad wartet dagegen nicht auf GPU-Leerlauf.

=== Texturtransport ===

Direkte Cross-Adapter-Texturen sind auf dem Testsystem nicht beidseitig verfügbar: Die Intel UHD meldet Unterstützung für Row-Major Cross-Adapter Textures, die RTX 5060 Laptop GPU nicht. Deshalb verwendet das Projekt einen allgemeineren Buffer-Fallback.

<pre>
Intel MainTextureCS
-> persistente Worker-Textur
-> CopyTextureRegion
-> persistenter Shared Cross-Adapter Buffer
-> Worker signalisiert WorkerReady (1, 3, 5, ...)
-> UE-Primary-Queue wartet auf WorkerReady
-> direkte Kopie in persistente UE-eigene FTextureRHIRef
-> Primary signalisiert PrimaryComplete (2, 4, 6, ...)
</pre>

Der robuste Normal-Pfad kopiert die Worker-Textur über den Shared Buffer direkt in eine von Unreal erzeugte <code>FTextureRHIRef</code>. Breite, Höhe und Row Pitch werden dynamisch aus Worker-Ressource und Transport-Metadaten übernommen. Der erfolgreiche 128×96-RGBA8-Test verwendet 512 Byte Row Pitch und 49.152 Byte Transfergröße. Die Output Registry trennt Persistent-, Pending- und Ready-Zustände sowie Inhaltsgeneration und Texturidentität. Dadurch kann eine verspätete Completion keinen neueren Output zurückrollen.

=== Non-blocking Runtime-Pfad ===

Die produktive Testlogik ist aus dem Konsolenkommando in eine gekapselte NormalPath-API verschoben. <code>SubmitWorkerTextureComputeJob()</code> reicht den Worker-Dispatch ohne CPU-Wait ein. <code>QueueNormalTextureTransfer()</code> reiht Wait, Kopie und Completion-Signal in Unreals D3D12-Kontext ein. Der normale MainTextureCS-Pfad enthält weder CPU-Fence-Waits noch Readback, <code>Map</code> oder Pixelvergleich. <code>TickNormalTextureTransfers()</code> prüft die Primary-Completion non-blocking über einen Runtime-Pump; <code>RHIEndFrame()</code> bleibt als Fallback erhalten.

Eine passende Primary-<code>FTextureRHIRef</code> wird pro Worker und Konfiguration persistent gehalten. Nach PrimaryComplete kann der nächste Job dieselbe Resource erneut verwenden; dabei führt Unreal die Übergänge <code>SRVMask -> CopyDest -> SRVMask</code> aus. Eine backend-neutrale RHI-Provider-API reicht die Ready-Textur an die Engine weiter. <code>UExperimentalMultiGPUTexture</code> hält eine stabile <code>UTexture</code> samt TextureReference und bindet die persistente <code>FTextureRHIRef</code> ohne zusätzlichen Pixel-Copy. Eine native D3D12-Resource wird weiterhin nicht blind als UE-Textur gewrappt, weil Unreals Resource-State-Buchhaltung den tatsächlichen nativen Zustand sonst nicht sicher kennt.

=== Sichtbarer TPS-Consumer ===

<code>AExperimentalMultiGPUDisplayActor</code> zeigt die Worker-Ausgabe im Third-Person-Testlevel über den Materialparameter <code>MultiGPUTexture</code> an. Damit ist der Output nicht mehr nur über Logs oder Readback nachgewiesen: Die Intel UHD erzeugt fortlaufend die Texturinhalte, während die RTX die Spielwelt und das Material rendert. <code>TextureConsumerCS</code> kann Ready-Ausgaben auf der Primary zusätzlich als SRV lesen und fünf quantisierte Samples im Debugpfad prüfen.

=== Lebensdauer und automatisches Cleanup ===

Der Normal-Pfad verwendet pro Worker genau einen persistenten Runtime-Slot. Worker-Textur, Root Signature, PSO, Descriptor Heap, Command Allocator/List und Worker-Fence werden nach der ersten kompatiblen Initialisierung wiederverwendet. Dasselbe gilt für Shared Heap/Buffer/Fence und die Transport-Command-Objekte. Der In-Flight-Job trägt nur noch die nötigen Job-, Generation- und Fence-Metadaten.

<pre>
Runtime Request
-> Completion non-blocking prüfen
-> falls Slot frei: Worker Dispatch
-> WorkerReady-Fence signalisieren
-> Primary Wait, SafeCopy und PrimaryComplete-Signal
-> Output Pending
-> Runtime-Pump oder RHIEndFrame prüft GetCompletedValue()
-> Output Ready publizieren
-> Slot wiederverwendbar
</pre>

Backpressure erlaubt maximal einen echten In-Flight-Job pro Worker. Ein Busy-Request setzt keine GPU-Arbeit ab, setzt keine Ressourcen zurück und erhöht <code>PatternPhase</code> nicht. Worker-Fence-Werte steigen mit jedem akzeptierten Submit 1, 2, 3 und so weiter; der persistente Shared Fence verwendet fortlaufend die Paare 1/2, 3/4, 5/6. Fehler nach Übergabe von Ressourcen an die GPU führen zu sicherem Retire beziehungsweise Retention statt zu vorzeitigem Reuse.

=== Texture Stream und Benchmarking ===

Der projektseitige Texture Stream akzeptiert eine beliebige positive, endliche Zielrate. Punkt und Komma sind als Dezimaltrenner möglich. Optional lässt sich die Zahl erfolgreicher Submits begrenzen; Busy- oder Failed-Versuche verbrauchen dieses Limit nicht. Der Quiet-Modus unterdrückt per-Job-Ausgaben, behält aber Start, echte Fehler und die Abschlussstatistik bei.

Die Statistik unterscheidet Timer-Ticks, angenommene Submits, Busy/Failed, Ready, In-Flight und die jeweiligen effektiven Raten. Diagnosezeitpunkte erfassen unter anderem RequestAccepted, RenderCommandExecution, WorkerSubmit, NormalTransferQueued und ReadyObserved.

{| class="wikitable"
! Test
! Ergebnis
! Aussage
|-
| 5 Hz, 20 Submits
| etwa 5 Ready/s, 20/20, kein Busy
| Entspannter Single-Slot-Betrieb
|-
| 1000 Hz, 100 Submits, quiet
| 100/100 Ready, 0 Fehler, etwa 58 Ready/s
| Backpressure begrenzt den Durchsatz sicher
|-
| 1000 Hz bei <code>t.MaxFPS 30</code>
| etwa 28–29 Ready/s trotz rund 982 Timer-Ticks/s
| Primary-/SafeCopy-/Ready-Kette ist effektiv framegekoppelt
|}

Ein zusätzlicher non-blocking Aufruf von <code>ImmediateFlush(DispatchToRHIThread)</code> erreicht hohe Render-Command-Raten, hebt die gemessene Frame-Kopplung aber nicht auf. Im 30-FPS-Test lag der RHIEndFrame-spezifische Completion-Takt praktisch exakt bei 30 Hz. Das aktuelle Problem ist damit eingegrenzt: Nicht der Stream-Timer, sondern die Primary-RHI-/D3D12-Submission der SafeCopy-Kette bestimmt die sichtbare Ready-Rate.

=== Queue-Submission-Diagnose ===

<code>MultiGPUD3D12QueueProbe</code> untersucht die Submission unabhängig vom sichtbaren Texturpfad. Neben <code>full</code>, <code>waitonly</code> und <code>signalonly</code> existieren inzwischen die Diagnosemodi <code>computeonly</code>, <code>commandonly</code>, <code>barrieronly</code>, <code>barrierprivate</code> und <code>copybuffer</code>. Als Queues stehen <code>graphics</code>, <code>copy</code>, <code>native</code>, <code>worker</code>, <code>worker-copy</code> und <code>worker-high</code> zur Verfügung. Graphics und Copy verwenden <code>RHIRunOnQueue(..., false)</code> auf UE-verwalteten Primary-Queues; die übrigen Varianten isolieren private beziehungsweise bereits vorhandene native D3D12-Queues.

Der Probe misst Request, Worker-Submit, <code>RHIRunOnQueue</code>-Aufruf und -Callback, Primary-Execute, Fence-Completion sowie Ready bis zum nächsten akzeptierten Submit. Er fügt keine CPU-Waits, Readbacks, Maps oder <code>BlockUntilGPUIdle</code> ein und beschreibt keine Textur des sichtbaren Normal-Pfads.

{| class="wikitable"
! Test
! Ergebnis
! Befund
|-
| UE Graphics, signal-only, 30 FPS
| 33,319 ms PrimaryExecute bis Ready
| UE-verwaltete Graphics-Submission skaliert mit der Frame-Dauer
|-
| UE Copy, signal-only, 30 FPS
| 32,593 ms PrimaryExecute bis Ready
| Auch die UE-verwaltete Copy Queue ist framegekoppelt
|-
| Private Primary-DIRECT-Queue, signal-only
| etwa 0,014 ms Queue/Fence-Latenz; nach Lifecycle-Fix rund 999 Ready/s bei 30 FPS
| Native Queue und Scheduler sind vollständig vom Frame entkoppelt
|-
| Worker signal-only / leere Command List
| jeweils rund 1000 Ready/s bei 30 FPS
| Worker-Queue, Fence und reine Submission sind nicht framegekoppelt
|-
| Worker <code>CopyBufferRegion</code>, 30 / 60 / 120 FPS
| 29,41 / 58,25 / 113,08 Ready/s
| Bereits eine echte 256-Byte-GPU-Kopie folgt im UE-Prozess dem Frame-Raster
|-
| Worker COPY Queue / HIGH Priority, 30 FPS
| jeweils rund 29,42 Ready/s
| Queue-Typ und Priorität beseitigen die Kopplung nicht
|-
| Standalone-D3D12 auf derselben Intel UHD
| 92.956 Copy-Jobs/s; 0,007 ms durchschnittliche Fence-Latenz
| Die Kopplung ist UE-Prozess-/Scheduling-spezifisch, keine allgemeine Intel-, WDDM- oder D3D12-Grenze
|}

Der <code>RHIRunOnQueue</code>-Callback selbst erreicht den D3D12-Submission-Thread typischerweise bereits nach etwa 0,02–0,05 ms; die Verzögerung entsteht danach in der verwalteten Queue-/Submission-Reihenfolge. <code>SubmitCommandsHint()</code> ist in UE 5.8 nur ein veralteter Alias für <code>ImmediateFlush(DispatchToRHIThread)</code> und stellt daher keinen stärkeren Submission-Mechanismus dar.

Der native Test ist ein '''Architekturbeweis, noch kein Experimental- oder Direct-Modus'''. Die zunächst gemessene Verzögerung von rund 32 ms lag zwischen der In-Flight-Freigabe und dem nächsten Request auf dem Render Thread. Für <code>signalonly/native</code> wurde der sichere Completion-/Submit-Lifecycle deshalb in den frameunabhängigen Scheduler verlegt. Danach erreichten zwei 100-Job-Läufe bei <code>t.MaxFPS 30</code> rund 999 bis 1029 Ready/s, ohne Busy oder Fehler.

Der anschließende <code>full native</code>-Test lokalisierte die verbleibende Kopplung auf echte Worker-GPU-Arbeit: WorkerSubmit bis WorkerReady benötigte bei 30, 60 und 120 FPS ungefähr 33,29, 16,93 und 8,45 ms; WorkerReady bis PrimaryReady war danach praktisch sofort. Signal-only und eine leere Command List waren schnell, Resource Barriers und eine 256-Byte-Kopie dagegen framegebunden. Ein eigenständiger D3D12-Microbenchmark auf derselben Intel UHD erreichte außerhalb von Unreal bei derselben Kopie rund 92.956 Jobs/s mit 0,007 ms mittlerer Fence-Latenz. Die genaue Ursache im UE-Prozess beziehungsweise dessen GPU-Scheduling-Kontext bleibt offen und wird vorerst bis zum Gegencheck mit der vorhandenen Intel Arc A380 geparkt.

=== Worker-Rasterpfad und RasterStream ===

<code>ExperimentalMultiGPU.TestRasterWorker</code> weist erstmals echte Rasterizer-Arbeit auf der Intel-Worker-GPU nach. <code>RasterWorkerVS</code> und <code>RasterWorkerPS</code> werden über Unreals Global-Shader-Pfad kompiliert und für ein natives Worker-Graphics-PSO verwendet. Ein persistentes 128×96-RGBA8-RenderTarget besitzt RTV, leere Root Signature und eine DIRECT-Command-List. Der Vertex Shader erzeugt drei Vertices über <code>SV_VertexID</code>; der Pixel Shader schreibt interpolierte RGB-Farben.

Der Job wechselt das RenderTarget von <code>COPY_SOURCE</code> nach <code>RENDER_TARGET</code>, führt Clear und <code>DrawInstanced(3,1,0,0)</code> aus und wechselt anschließend zurück nach <code>COPY_SOURCE</code>. Danach verwendet er unverändert den robusten Normalpfad aus Cross-Adapter-Shared-Buffer, Primary SafeCopy, persistenter <code>FTextureRHIRef</code>, <code>UExperimentalMultiGPUTexture</code> und DisplayActor. Der Runtime-Test meldete einen akzeptierten Submit und <code>RasterWorker READY</code> für Generation 1; die 128×96-UTexture wurde erfolgreich gebunden.

Der einmalige Test wurde außerdem zu einem frei konfigurierbaren RasterStream ausgebaut. Ein sichtbarer Lauf mit 10 Hz und 50 erfolgreichen Submits endete mit 50 Ready-Ausgaben, 0 Busy und 0 Fehlern bei etwa 9,90 Ready/s. Primary-Textur und Materialbindung blieben dabei persistent.

=== Raster3D mit echten Vertex- und Indexbuffern ===

Der Worker besitzt inzwischen einen kleinen eigenständigen 3D-Rasterpfad mit perspektivischer Kamera, Model-View-Projection-Matrix als Root Constants, D32_FLOAT-Depth-Buffer und Depth-Test. Der finale Testwürfel verwendet 24 POSITION/COLOR-Vertices, 36 <code>uint16</code>-Indices und <code>DrawIndexedInstanced(36,1,0,0,0)</code>; sechs getrennte Seitenfarben machen Ausrichtung und Rotation sichtbar nachvollziehbar.

Die statischen Meshdaten werden einmalig über private Upload-Buffer in DEFAULT-Heaps übertragen. Der Init-Fence wird non-blocking über <code>GetCompletedValue()</code> beobachtet. Der eigentliche Runtime-Renderpfad enthält weiterhin keine CPU-Waits und keine Maps.

=== UE-Static-Meshes auf der Worker-GPU ===

<code>StaticMeshWorker</code> extrahiert echte LOD0-Geometrie aus <code>UStaticMesh</code>-Assets. POSITION und NORMAL sowie <code>uint32</code>-Indices werden in POD-Daten überführt, einmalig asynchron in eigene Worker-VB/IB hochgeladen und anschließend per <code>DrawIndexedInstanced</code> gerendert. Assetpfade sind dynamisch; Auto-Fit richtet Kamera beziehungsweise Modellmaßstab an den Bounds aus.

Sichtbar korrekt getestet wurden:

{| class="wikitable"
! Asset
! Vertices
! Indices
|-
| Sphere
| 559
| 2880
|-
| Cube
| 54
| 144
|-
| Cylinder
| 334
| 1536
|}

=== Multi-Mesh Worker-Szene ===

<code>StaticMeshScene</code> rendert Sphere, Cube und Cylinder gemeinsam in einen Color-/Depth-Frame. Der verifizierte Test umfasst insgesamt 947 Vertices und 4560 Indices, drei <code>DrawIndexedInstanced</code>-Aufrufe und nur einen anschließenden Cross-Adapter-/Normal-SafeCopy-Transfer. Damit ist nicht mehr nur ein synthetisches Primitive, sondern mehrere echte UE-Meshes mit gemeinsamer Tiefenprüfung im Worker-Frame sichtbar nachgewiesen.

=== WorldStaticMeshScene ===

<code>ExperimentalMultiGPUWorldStaticMeshScene.cpp</code> sammelt im Engine-Layer bis zu acht sichtbare <code>UStaticMeshComponent</code>s von Actors mit dem Tag <code>MultiGPUWorker</code>. Meshdaten und World-Transforms werden im Game Thread in reine POD-Strukturen und 4×4-Matrizen kopiert. D3D12RHI erhält keine <code>UObject</code>-Pointer. Mehrere Instanzen desselben Meshes teilen den persistenten Worker-Mesh-Cache und unterscheiden sich nur durch Modelmatrix und Draw Call.

Der Pfad wurde inzwischen sichtbar im PIE-Level verifiziert. Drei getaggte Static-Mesh-Actors erschienen mit ihren tatsächlichen relativen Positionen, Rotationen und Skalierungen im Worker-Bild. Die zentrale Koordinatenumrechnung lautet:

<pre>Worker (X, Y, Z) = (UE Y, UE X, -UE Z)</pre>

Die Transformation besitzt die Determinante +1 und ist damit keine Spiegelung. Das notwendige horizontale Spiegeln erfolgt ausschließlich auf der Presentation-Plane, nicht im Worker-Renderpfad.

=== Kontinuierlicher WorldStaticMeshSceneStream ===

<code>StartWorldStaticMeshSceneStream</code> erfasst die getaggte Szene fortlaufend im Game Thread. Reine Änderungen an Transform oder Kamera lösen keinen erneuten Mesh-Upload aus. Hinzugekommene, entfernte, unsichtbare oder umgetaggte Components werden im nächsten Snapshot berücksichtigt. Single-Slot-Backpressure verhindert einen wachsenden Rückstau.

Ein verifizierter 30-Hz-Lauf endete nach 31,184 Sekunden mit 835 Ticks, 691 angenommenen Submits, 144 Busy, 0 Fehlern und 691 Ready-Frames. Die effektive Ready-Rate betrug 22,16 Hz. Dieser Test belegt die funktionale Live-Aktualisierung; die Rate war noch kein Optimierungsziel.

=== SceneCapture2D als Worker-Kamera ===

<code>TestSceneCaptureStaticMeshScene</code> verwendet eine echte <code>ASceneCapture2D</code> beziehungsweise <code>USceneCaptureComponent2D</code> aus der laufenden PIE-Welt als Kameraquelle. Der empfohlene Editor-Weg ist das Component Tag <code>MultiGPUWorkerCamera</code> auf der <code>CaptureComponent2D</code>; ein gleichnamiges Actor-Tag bleibt nur als Legacy-Fallback.

Ausgelesen werden World Location, Rotation, Forward/Right/Up, <code>FOVAngle</code> und <code>ProjectionType</code>. Orthografische Projektion wird derzeit sauber abgelehnt. Die SceneCapture2D liefert ausschließlich Kameradaten: Ihr UE-RenderTarget wird weder gelesen noch kopiert. Die Intel-Worker-GPU rendert die Geometrie selbst. Kamera und Actors werden gemeinsam mit <code>SceneScale = 0.01</code> in Worker-Koordinaten überführt; Auto-Fit und Scene-Recentering sind in diesem Modus deaktiviert.

Die 128×96-Worker-Projektion verwendet ein Seitenverhältnis von 4:3 und interpretiert <code>FOVAngle</code> als horizontales FOV. Nach den Orientierungstests wird nur die Anzeige über <code>SetRelativeScale3D(FVector(-4.0f, -3.0f, 1.0f))</code> korrigiert; dies entspricht <code>U' = 1-U</code> und <code>V' = 1-V</code>.

=== Live SceneCaptureStaticMeshSceneStream ===

<code>StartSceneCaptureStaticMeshSceneStream</code> liest Kamera-Transform, Kamerabasis, FOV und aktuelle Actor-Transforms pro Snapshot neu im Game Thread. Der Worker erhält weiterhin ausschließlich POD-Daten, verwendet den persistenten Mesh-Cache sowie ein gemeinsames Color- und D32-Depth-Target und führt pro akzeptiertem Frame genau einen Cross-Adapter-/Normal-SafeCopy-Transfer aus.

Der Quiet-Test

<pre>ExperimentalMultiGPU.StartSceneCaptureStaticMeshSceneStream 30 300 quiet</pre>

lieferte in 10,084 Sekunden 301 Ticks, 300 Submits, 1 Busy, 0 Fehler und 300 Ready-Frames. Die effektive Ready-Rate betrug 29,75 Hz. Bewegungen der Kamera und Actors sowie FOV-Änderungen erschienen live auf der Display-Plane. Damit ist erstmals ein kleiner SceneCapture-/CCTV-artiger Worker-Kanal vollständig funktional nachgewiesen.

=== Dynamische SceneCapture-Auflösung ===

Die SceneCapture-Ausgabe ist nicht mehr fest auf 128×96 Pixel begrenzt. <code>ExperimentalMultiGPU.SetSceneCaptureResolution <Width> <Height></code> setzt ganzzahlige Dimensionen von 1 bis 4096; <code>GetSceneCaptureResolution</code> zeigt die aktive Einstellung. 128×96 bleibt der Standard. Während ein SceneCapture-Stream läuft, wird ein Auflösungswechsel absichtlich abgelehnt, damit keine In-Flight-Ressourcen ausgetauscht werden.

Color Target, D32-Depth-Buffer, Row Pitch, Shared-Buffer-Transport, SafeCopy, persistente Primary-Textur und <code>UExperimentalMultiGPUTexture</code> übernehmen die gewählten Dimensionen. Projektion und Display-Plane verwenden das echte Seitenverhältnis. Die bestätigte Anzeigeorientierung <code>U' = 1-U</code> und <code>V' = 1-V</code> bleibt eine reine Presentation-Korrektur; Worker-Basis und Kameramathematik ändern sich nicht.

=== Scheduler-Korrektur bei SceneCapture ===

Ein 1920×1080-Test mit 25 Hz erreichte zunächst trotz fehlerfreier Frames nur 13,90 Ready-Hz und erzeugte 222 Busy-Ticks. Ursache war kein GPU-Limit, sondern ein Polling-Aliasing: Eine frühe Game-Thread-Prüfung konnte den Timer-Slot verwerfen, obwohl die Completion kurz darauf im CoreTicker/RHI-Pump sichtbar geworden wäre.

Die frühe <code>IsRuntimeTextureUpdateInFlight()</code>-Prüfung wurde für diesen Stream entfernt. Der Pending-Request bleibt als Backpressure-Gate erhalten; die maßgebliche Busy-Entscheidung fällt nun erst im Render Command nach <code>TickNormalTextureTransfers(nullptr, true)</code>. Single-Slot, POD-Snapshots und non-blocking <code>GetCompletedValue()</code> bleiben erhalten. Es wurden weder CPU-Waits noch zusätzliche Threads eingeführt.

Nach der Korrektur erreicht 1080p bei 25 Hz 24,79 Ready-Hz mit 1 Busy; bei 30 Hz sind es 29,43 Ready-Hz mit 4 Busy.

=== Skalierung bis 4K60 ===

Die Pipeline wurde von 640×360 bis 3840×2160 getestet. Bei 640×360/30 Hz und 1280×720/30 Hz wurden 29,85 beziehungsweise 29,82 Ready-Hz ohne Busy erreicht. 1920×1080/60 Hz lieferte 59,40 Ready-Hz ohne Busy, 2560×1440/60 Hz 59,21 Ready-Hz mit 1 Busy und 3840×2160/60 Hz 59,02 Ready-Hz mit 2 Busy.

Ein zusätzlicher 4K60-Stresstest mit acht Static-Mesh-Instanzen und drei gecachten Unique Meshes erreichte in 5,049 Sekunden '''300 von 300 Ready-Frames, 0 Busy, 0 Fehler und 59,42 effektive Ready-Hz'''. Acht Draw Calls, gemeinsamer Depth Buffer, Cross-Adapter-Transport und SafeCopy liefen dabei im vorhandenen Single-Slot. Das ist ein Stabilitätsnachweis der aktuellen Mini-Szene, kein allgemeiner GPU-Benchmark.

=== Skeletal Mesh in Reference Pose ===

<code>ExperimentalMultiGPU.TestSkeletalMeshWorker</code> erweitert den Geometriepfad auf <code>USkeletalMeshComponent</code>. Der Engine-Layer sucht deterministisch die erste sichtbare, getaggte Komponente und extrahiert LOD0-Positionen, Normalen, Indices und Render Sections. D3D12RHI erhält wie bisher ausschließlich POD-Geometrie und Modelmatrizen.

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.

== Test- und Diagnosebefehle ==

{| class="wikitable"
! Befehl
! Zweck
|-
| <code>ExperimentalMultiGPU.TestComputeShader</code>
| Führt den vollständigen Worker-Compute-Testpfad aus. Er enthält auch ältere Debug- und Regressionstests mit CPU-Readback und ist daher nicht mit dem reinen asynchronen Runtime-Pfad gleichzusetzen.
|-
| <code>ExperimentalMultiGPU.TestTextureConsumer</code>
| Testet <code>TextureConsumerCS</code> auf der Primary-GPU. Die aktuelle Ready-Textur wird über UE-RHI gelesen und anhand ausgewählter Testpixel per Debug-Readback geprüft.
|-
| <code>ExperimentalMultiGPU.TestTextureBridge</code>
| Prüft die Bridge von der fertigen <code>FTextureRHIRef</code> zu <code>UExperimentalMultiGPUTexture</code> und damit den UE- und materialtauglichen Texturpfad.
|-
| <code>ExperimentalMultiGPU.SpawnDisplayActor</code>
| Spawnt den Test-Actor mit Plane im Spiel. Das Material zeigt darauf die vom Worker erzeugte Textur an.
|-
| <code>ExperimentalMultiGPU.TestRasterWorker</code>
| Rasterisiert auf der Worker-GPU ein echtes RGB-Dreieck per Vertex- und Pixel-Shader und transportiert das Ergebnis über den normalen SafeCopy-Pfad bis zum DisplayActor.
|-
| <code>ExperimentalMultiGPU.StartRasterStream</code> / <code>ExperimentalMultiGPU.StopRasterStream</code>
| Startet beziehungsweise stoppt den kontinuierlichen RGB-Dreieck-RasterStream mit frei wählbarer Zielrate, optionalem Submit-Limit und Quiet-Modus.
|-
| <code>ExperimentalMultiGPU.TestRaster3DWorker</code>
| Rendert einmalig den perspektivischen 3D-Testwürfel mit Depth Buffer und echten Vertex-/Indexbuffern.
|-
| <code>ExperimentalMultiGPU.StartRaster3DStream</code> / <code>ExperimentalMultiGPU.StopRaster3DStream</code>
| Startet beziehungsweise stoppt den kontinuierlichen Raster3D-Test.
|-
| <code>ExperimentalMultiGPU.TestStaticMeshWorker [AssetPath]</code>
| Extrahiert und rendert LOD0-Geometrie eines UE-Static-Mesh-Assets; ohne optionalen Pfad wird das konfigurierte Testasset verwendet.
|-
| <code>ExperimentalMultiGPU.TestStaticMeshScene</code>
| Rendert Sphere, Cube und Cylinder gemeinsam mit drei Draw Calls und einem anschließenden Transfer.
|-
| <code>ExperimentalMultiGPU.TestWorldStaticMeshScene</code>
| Rendert einen einmaligen POD-Snapshot der sichtbaren, mit <code>MultiGPUWorker</code> getaggten StaticMeshComponents aus der laufenden World. Der sichtbare PIE-Nachweis ist erfolgreich.
|-
| <code>ExperimentalMultiGPU.StartWorldStaticMeshSceneStream [Hz] [MaxSuccessfulSubmits] [quiet]</code> / <code>StopWorldStaticMeshSceneStream</code>
| Startet beziehungsweise stoppt den kontinuierlichen Stream der getaggten UE-Welt mit Live-Transforms und persistentem Mesh-Cache.
|-
| <code>ExperimentalMultiGPU.SetSceneCaptureResolution <Width> <Height></code> / <code>GetSceneCaptureResolution</code>
| Setzt beziehungsweise zeigt die gemeinsame SceneCapture-Auflösung. Erlaubt sind ganzzahlige Werte von 1 bis 4096 je Achse; Änderungen während eines laufenden Streams werden abgelehnt.
|-
| <code>ExperimentalMultiGPU.TestSceneCaptureStaticMeshScene</code>
| Rendert einen einmaligen Worker-Snapshot aus Sicht der mit <code>MultiGPUWorkerCamera</code> markierten SceneCapture2D-Kamera.
|-
| <code>ExperimentalMultiGPU.StartSceneCaptureStaticMeshSceneStream [Hz] [MaxSuccessfulSubmits] [quiet]</code> / <code>StopSceneCaptureStaticMeshSceneStream</code>
| Startet beziehungsweise stoppt den Live-Worker-Kanal mit fortlaufend aktualisierten Kamera-, FOV- und Actor-Daten.
|-
| <code>ExperimentalMultiGPU.TestSkeletalMeshWorker</code>
| Rendert das erste sichtbare, getaggte Skeletal Mesh in LOD0 und Reference Pose sectionsweise auf der Worker-GPU.
|-
| <code>ExperimentalMultiGPU.StartTextureStream</code>
| Startet den sichtbaren Normal-Pfad: Worker-Textur → Cross-Adapter-Transfer → SafeCopy → UE-Textur → Material.
|-
| <code>ExperimentalMultiGPU.StopTextureStream</code>
| Verhindert weitere Submits des laufenden Streams. Ein bereits eingereichter GPU-Job darf noch sicher fertig werden.
|-
| <code>ExperimentalMultiGPU.StartQueueProbe</code>
| Startet den Diagnose-Benchmark für Primary-Queue-, Fence- und Submission-Verhalten. Der Probe verändert die sichtbare Textur nicht.
|}

=== Texture Stream ===

Grundsyntax:

<pre>
ExperimentalMultiGPU.StartTextureStream [Hz] [MaxSuccessfulSubmits] [quiet]
</pre>

{| class="wikitable"
! Beispiel
! Wirkung
|-
| <code>ExperimentalMultiGPU.StartTextureStream</code>
| Standardmäßig etwa 5 Hz, ohne Submit-Limit.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 37.5</code>
| Fordert 37,5 Hz ohne Submit-Limit an. Sowohl <code>37.5</code> als auch <code>37,5</code> werden akzeptiert.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 1000 100</code>
| Fordert 1000 Hz an und stoppt nach exakt 100 erfolgreichen Submits.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 1000 100 quiet</code>
| Wie zuvor, unterdrückt aber Per-Job- und Busy-Logspam.
|}

Die Hz-Angabe ist eine '''Ziel- beziehungsweise Request-Frequenz'''. <code>1000</code> bedeutet daher nicht automatisch 1000 fertige Texturen pro Sekunde. Die tatsächliche Rate hängt unter anderem von Timer, Submission, Backpressure, Queue-Latenz und Slot-Lifecycle ab. <code>MaxSuccessfulSubmits</code> zählt nur angenommene Submits; Busy- und Failed-Versuche verbrauchen das Limit nicht.

=== QueueProbe ===

Grundsyntax:

<pre>
ExperimentalMultiGPU.StartQueueProbe <Hz> <MaxSubmits> [quiet] [Mode] [Queue]
</pre>

{| class="wikitable"
! Modus
! Ausgeführter Pfad
|-
| <code>full</code>
| Worker Compute → Cross-Adapter-Transfer → Primary Wait → Copy → Completion Fence.
|-
| <code>waitonly</code>
| Worker Compute → Cross-Adapter-Transfer → Primary wartet auf WorkerReadyFence → Completion Fence. Es findet keine Texturkopie statt.
|-
| <code>signalonly</code>
| Keine Textur, kein Worker-Wait und keine Kopie; nur Queue und Fence. Dieser Modus isoliert das Queue-Verhalten.
|-
| <code>commandonly</code>
| Reicht eine leere echte Worker-Command-List ein und trennt Command-Submission von GPU-Arbeit.
|-
| <code>barrieronly</code> / <code>barrierprivate</code>
| Isoliert Resource-Barriers auf Worker-Ressourcen beziehungsweise einer privaten Testtextur.
|-
| <code>copybuffer</code>
| Führt eine minimale echte <code>CopyBufferRegion</code>-Operation über 256 Byte aus.
|}

{| class="wikitable"
! Queue
! Bedeutung
|-
| <code>graphics</code>
| Vorhandene UE Primary Graphics-/Direct-Queue über <code>RHIRunOnQueue</code>.
|-
| <code>copy</code>
| Vorhandene UE Primary Copy Queue über <code>RHIRunOnQueue</code>.
|-
| <code>native</code>
| Vollständig private native D3D12-DIRECT-Queue auf der Primary; reine Diagnose, kein fertiger Experimental-Modus.
|-
| <code>worker</code>
| Vorhandene native Worker-DIRECT-Queue.
|-
| <code>worker-copy</code>
| Separate native Worker-COPY-Queue.
|-
| <code>worker-high</code>
| Separate Worker-DIRECT-Queue mit hoher Priorität.
|}

Typische Beispiele:

<pre>
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet full graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet waitonly graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly copy
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly native
</pre>

Der letzte Befehl ist aktuell die wichtigste isolierte Gegenprobe. Mit der privaten nativen Queue wurde bei 30 FPS eine durchschnittliche Latenz <code>primaryExecuteToReadyAvgMs = 0.014 ms</code> gemessen.

=== Benchmark-CVars ===

{| class="wikitable"
! CVar
! Zweck
|-
| <code>r.VSync 0</code>
| Deaktiviert VSync, damit es die Messung nicht begrenzt.
|-
| <code>t.MaxFPS 30</code> <code>t.MaxFPS 60</code> <code>t.MaxFPS 120</code>
| Setzt die Engine-Framerate für reproduzierbare Frame-Coupling-Tests.
|-
| <code>t.MaxFPS 0</code>
| Entfernt das normale <code>t.MaxFPS</code>-Limit. Dieser Lauf ist als zusätzliche Diagnose-Gegenprobe vorgesehen.
|}

== 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.

== Historische Vorläufer ==

Die Grundidee heterogener Multi-GPU-Nutzung ist nicht neu. Bereits mit der Einführung von Direct3D 12 entstanden mehrere Versuche, integrierte und dedizierte GPUs gemeinsam zu verwenden. Eine allgemein einsetzbare Lösung für moderne UE5-Spiele hat sich daraus jedoch nicht entwickelt.

=== Microsoft und Epic: UE4 Elemental Demo (2015) ===

Microsoft zeigte eine angepasste Unreal-Engine-4-Version der Elemental-Demo, bei der eine NVIDIA-GPU und eine Intel-iGPU gemeinsam arbeiteten. Das erklärte Ziel war, ansonsten ungenutzte Grafikleistung in Hybrid-Systemen zu verwenden. Dieser Versuch ist der Grundidee des Projekts besonders ähnlich, blieb aber eine technische Demonstration.

=== Intel: D3D12 Multi-Adapter Sample (2015) ===

Intels Beispiel kombinierte eine GeForce 840M mit Intel HD Graphics 5500. Beide GPUs berechneten getrennte Teile einer einfach parallelisierbaren Raytracing-Szene. Cross-Adapter-Ressourcen und Shared Fences führten die Ergebnisse anschließend zusammen. Intel berichtete in diesem Test von nahezu halbierter Framezeit, warnte jedoch ausdrücklich davor, das Ergebnis unmittelbar auf reale Spiele zu übertragen.

=== Ashes of the Singularity ===

Die Nitrous Engine von ''Ashes of the Singularity'' setzte Direct3D-12-Explicit-Multiadapter in einem veröffentlichten Spiel ein. Dabei konnten auch unterschiedliche GPU-Modelle und Hersteller zusammenarbeiten. Das war ein wichtiger Praxisnachweis, blieb in der Spielebranche aber eine seltene Ausnahme.

=== Weitere verwandte Ansätze ===

* ''Rise of the Tomb Raider'' erhielt explizite Direct3D-12-Multi-GPU-Unterstützung, vor allem für klassische Kombinationen ähnlicher GPUs.
* NVIDIA VR SLI wies bei Virtual Reality jeder GPU ein Auge zu. Das verteilt unabhängige Ansichten, bleibt jedoch NVIDIA-spezifisch.
* Unreal nDisplay kann Viewports oder Frustums auf weitere GPUs beziehungsweise Prozesse auslagern und das fertige Bild zur Ausgabe-GPU zurückführen. Der Einsatzbereich ist hauptsächlich Virtual Production.
* Forschung und High-Performance Computing verwenden seit Jahren Scheduler für heterogene GPUs, allerdings überwiegend für Compute- und Datenverarbeitungsaufgaben statt für einen allgemeinen UE5-Echtzeitrenderer.

=== Abgrenzung dieses Projekts ===

Das Projekt erfindet Direct3D-12-Explicit-Multiadapter nicht neu. Sein eigener Ansatz liegt in der Kombination aus tiefer UE5.8-RHI-Integration, UE-kompilierten Shadern auf unabhängigen Worker-Devices, frei wählbaren Spiel- und Compute-Workloads, Capability- und Performance-Scheduler, mehreren Fallback-Pfaden sowie dem langfristigen Ziel beliebiger Hersteller und mehrerer Worker.

== Vergleich mit anderen Multi-GPU-Verfahren ==

{| class="wikitable"
! Verfahren
! Arbeitsweise
! Verhältnis zu diesem Projekt
|-
| SLI / CrossFire
| Treiber- beziehungsweise Verbundlösung für meist ähnliche GPUs; häufig wird die Bildarbeit verteilt.
| Dieses Projekt benötigt keinen herstellerspezifischen GPU-Verbund und weist Aufgaben ausdrücklich selbst zu.
|-
| AFR (Alternate Frame Rendering)
| GPU 1 rendert einen Frame, GPU 2 den nächsten.
| Das Projekt verteilt unabhängige Aufgaben statt aufeinanderfolgender Frames. Dadurch werden Frame-Abhängigkeiten und typisches AFR-Pacing vermieden.
|-
| SFR (Split Frame Rendering)
| Mehrere GPUs bearbeiten Bereiche desselben Frames.
| Erfordert enge Lastverteilung und viel Datenaustausch. Das Projekt bevorzugt vollständig abgrenzbare Workloads und überträgt deren Ergebnis.
|-
| Direct3D 12 Linked Multiadapter
| Mehrere vom Treiber verbundene GPUs erscheinen als Knoten eines logischen Adapters.
| Eignet sich eher für eng kompatible GPUs. Das Projekt verwendet unabhängige Devices (Unlinked/Explicit Multiadapter) und unterstützt dadurch heterogene Herstellerkombinationen.
|-
| Direct3D 12 Unlinked / Explicit Multiadapter
| Die Anwendung verwaltet getrennte Adapter, Ressourcen und Synchronisation selbst.
| Das ist die technische Familie des Projekts. Hinzu kommen die eigene UE5-RHI-Integration, Workload-Ziele, Fallbacks und der geplante Scheduler.
|-
| UE nDisplay mGPU / Multi-Process
| Separate GPUs rendern bestimmte Viewports oder Frustums, vor allem für Virtual Production; Ergebnisse werden zur Ausgabe-GPU kopiert.
| Ähnliche Idee der aufgabenweisen Trennung, aber für einen anderen Einsatzbereich. Dieses Projekt zielt auf allgemeine Spiel- und Compute-Workloads innerhalb der Engine.
|-
| Vulkan Device Groups
| Ähnliche physische GPUs können ein gemeinsames logisches Device bilden.
| Für beliebige heterogene GPUs meist ungeeignet, da Geräte einer Gruppe nahezu gleiche Eigenschaften besitzen müssen. Eine spätere Vulkan-Portierung benötigt daher wahrscheinlich getrennte Devices und External Memory/Semaphores.
|}

SLI und CrossFire bezeichnen den Verbund; AFR und SFR beschreiben mögliche Verteilungsmethoden innerhalb solcher Systeme. Sie sind deshalb nicht vollständig getrennte Kategorien.

== Vorteile der geplanten Variante ==

* '''Herstellerunabhängig:''' NVIDIA, AMD und Intel können grundsätzlich kombiniert werden.
* '''Vorhandene Hardware nutzen:''' Auch eine sonst wenig genutzte integrierte GPU kann geeignete Nebenaufgaben übernehmen.
* '''Aufgaben statt Frames verteilen:''' Spiegel, Minimap oder Compute können mit eigener Auflösung und Aktualisierungsrate laufen.
* '''Keine identischen GPUs erforderlich:''' Unterschiedliche Fähigkeiten können gezielt genutzt werden.
* '''Kontrollierter Datenaustausch:''' Nur das benötigte Ergebnis muss zurück zur Primary-GPU.
* '''Robuste Fallback-Idee:''' Wenn direkte Texturen nicht gemeinsam nutzbar sind, bleibt der Shared-Buffer-Pfad.
* '''Erweiterbar:''' Scheduler, manuelles Mapping und mehrere Worker sind als spätere Stufen vorgesehen.

== Nachteile und technische Risiken ==

* '''Hoher Entwicklungsaufwand:''' Geräte, Ressourcen, Zustände, Fences, Fehlerfälle und UE-Lebenszyklen müssen selbst verwaltet werden.
* '''Transfer kann den Gewinn aufzehren:''' Cross-Adapter Heaps liegen laut D3D12 nicht automatisch im schnellen lokalen VRAM. Bandbreite und Latenz müssen für jeden Workload gemessen werden.
* '''VRAM wird nicht einfach addiert:''' Benötigte Ressourcen können auf mehreren GPUs vorliegen und zusätzlichen Speicher verbrauchen.
* '''Langsame Worker können bremsen:''' Eine Aufgabe lohnt sich nur, wenn Rechengewinn größer als Übergabe-, Warte- und Kopierkosten ist.
* '''Nicht jeder Workload ist unabhängig:''' Hauptansicht, Lumen, Nanite und stark gekoppelte Renderpässe besitzen viele Abhängigkeiten und sind schwieriger auszulagern.
* '''Hardwareunterschiede:''' Formate, Shader-Funktionen, Queue-Fähigkeiten und Cross-Adapter-Support müssen pro GPU geprüft werden.
* '''Wartungsrisiko:''' Eingriffe in private D3D12RHI-Dateien können bei Engine-Updates angepasst werden müssen.
* '''Produktionsreife fehlt noch:''' Ressourcenpools, Timeouts, Device-Lost-Wiederherstellung, Scheduler und echte Szenentests sind offen.

== Wann die Variante sinnvoll ist ==

Am aussichtsreichsten sind Aufgaben mit viel eigener Rechenarbeit, einem relativ kleinen Endergebnis und wenigen Abhängigkeiten zur Hauptszene. Gute frühe Kandidaten sind unabhängige Compute-Aufgaben sowie Scene Captures, die nicht in jedem Frame aktualisiert werden müssen. Weniger geeignet sind winzige Aufgaben mit großem Transfer oder Renderpässe, die ständig auf Ressourcen der Primary-GPU zugreifen.

Die entscheidende Regel für den späteren Scheduler lautet daher:

<pre>
Worker-Gewinn > Vorbereitung + Datentransfer + Synchronisation + Rückintegration
</pre>

== 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.
* Pro Worker existiert absichtlich nur ein persistenter Runtime-Slot. Mehrere parallele In-Flight-Jobs sowie Double-, Triple- oder Ring-Buffering fehlen noch.
* Die Primary-/SafeCopy-/Ready-Kette bleibt trotz zusätzlichem non-blocking <code>DispatchToRHIThread</code> effektiv an den Frame-/Submission-Zyklus gekoppelt.
* 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.
* QueueProbe ist reine Diagnose. Private native Queues sind noch kein Experimental-/Direct-Modus und beschreiben keine UE-eigene sichtbare Textur.
* Es gibt noch keine Umschaltung zwischen Normal und Experimental sowie keinen automatischen Session-Fallback.
* Raw-D3D12-Shared-Ressourcen sind noch nicht vollständig in Unreals Residency-Management eingebunden.
* Praktisch getestet ist Primary plus ein Worker. Die Architektur ist auf mehrere Worker ausgelegt, N-GPU ist aber noch nicht praktisch validiert.
* 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.
* <code>USkeletalMesh</code> ist bislang ein LOD0-ReferencePose-Proof. Bone-Skinning, Animation, Morph Targets und Cloth fehlen noch.
* 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.
* 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.

== Roadmap ==

# Cross-Adapter Transfer Timing V1: Worker-ColorTarget → Shared Buffer separat messen.
# Primary SafeCopy Timing ergänzen und die Integrationskosten getrennt halten.
# Kostenmodell V1 aus Worker-Raster, Transfer und Primary-Integration pro Workload ableiten.
# Weitere echte Workload-Klassen wie CCTV, Spiegel, Minimap und Compute anbinden; später Post Process oder neuronale Aufgaben untersuchen.
# D3D12-Pfade mit Intel Arc A750/A380 und RX 6900 XT in unterschiedlichen Primary-/Worker-Rollen gegenprüfen.
# Scheduler und Autotuner auf GPU-Eignung und gemessene Nettokosten statt Auslastungsprozent aufbauen.
# Material-, Textur- und Culling-Pfade für realistischere Worker-Szenen ergänzen.
# Skeletal Skinning mit Bone-Matrizen und Skin Weights erst bei einem echten animierten Worker-Workload ausbauen.
# 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 ==

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 ==

* 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/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://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://www.intel.com/content/dam/develop/external/us/en/documents/multi-adapter-support-in-directx-12-594015.pdf Intel: Multi-Adapter Support in DirectX 12]
* [https://devblogs.microsoft.com/directx/ashes-of-the-singularity-makes-gaming-history-with-directx-12/ Microsoft: Ashes of the Singularity und heterogene Adapter]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/nvidia-sli-alternative-frame-rendering-in-unreal-engine Epic: NVIDIA SLI Alternate Frame Rendering]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/multi-process-rendering-with-unreal-engine Epic: Multi-Process Rendering]
* [https://registry.khronos.org/vulkan/specs/latest/pdf/vkspec.pdf Khronos: Vulkan Specification – Device Groups]

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Multi-GPU]]
[[Kategorie:Direct3D 12]]
[[Kategorie:Experimentell]]

UE5 Heterogeneous Multi-GPU

2026-09-14T18:24:35Z

Elaina: Git-Checkpoint 37c6d02 dokumentiert

{{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.}}

'''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.

{| class="wikitable"
|+ Projektstatus
|-
! Engine / Plattform
| Unreal Engine 5.8 Source Build / Windows / Direct3D 12
|-
! Testsystem
| Lenovo LOQ 17IRX10
|-
! Primary
| NVIDIA GeForce RTX 5060 Laptop GPU
|-
! Worker
| Intel UHD Graphics
|-
! Zusätzliche Testhardware
| Intel Arc A750 und Arc A380 als zusätzliche dGPU-Worker-Gegenchecks vorgesehen; belastbare Messwerte liegen noch nicht vor
|-
! 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
|-
! 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
|-
! Gesamtvision
| etwa 30–35 % (Scheduler, echte Workloads, N-GPU und Vulkan noch offen)
|}

== Grundprinzip ==

<pre>
Intel Worker GPU
-> MainTextureCS + PatternPhase
-> persistente Worker-Textur
-> persistenter Shared Cross-Adapter Buffer
-> monotone Shared Fence / Queue Wait
-> persistente UE-eigene FTextureRHIRef
-> stabile UExperimentalMultiGPUTexture

RTX Primary GPU
-> normales UE5-Rendering
-> TPS-Material zeigt das Worker-Ergebnis sichtbar an
</pre>

Pro Worker ist maximal ein Runtime-Job gleichzeitig in flight. Backpressure lehnt weitere Requests als <code>Busy</code> ab, bis der Slot nach der Primary-Completion wieder sicher verwendbar ist.

Jeder Worker besitzt ein eigenes <code>ID3D12Device</code>, eigene Queues, Command Lists und Ressourcen. Ein späterer Scheduler soll Rechenleistung, Fähigkeiten, Transferkosten und gewünschte Aktualisierungsrate bewerten. Vorgesehene Aufgaben sind beispielsweise SceneCapture2D, Spiegel, CCTV, Minimap, Compute oder Niagara.

== Verifizierter Entwicklungsstand ==

=== Worker-Compute ===

Ein echter, von Unreal kompilierter Global Compute Shader läuft auf der Intel UHD, während Unreal regulär über die RTX rendert. Der Test verdoppelt 64 Ganzzahlen auf dem Worker; '''64 von 64 Ergebnissen wurden korrekt verifiziert'''. Damit ist echte GPU-Arbeit auf einem zweiten, herstellerfremden Device nachgewiesen.

Zusätzlich läuft <code>MainTextureCS</code> auf der Intel-GPU. Der synchrone Debugtest erzeugt eine 64 × 64 Pixel große RGBA8-Textur; '''alle 4096 shader-generierten Pixel wurden korrekt verifiziert'''. Der normale Runtime-Pfad verwendet inzwischen einen asynchronen 128×96-Test. Der Shader liest seine Dimensionen mit <code>GetDimensions()</code>, schützt überhängende Threads durch einen Bounds-Check und wird mit <code>Dispatch(16,12,1)</code> ausgeführt. <code>PatternPhase</code> erzeugt für jeden akzeptierten Submit deterministisch einen neuen sichtbaren Inhalt. Abgewiesene Busy-Requests erhöhen die Phase nicht und erzeugen daher keine Lücken.

=== Cross-Adapter-Speicher und Synchronisation ===

* RTX und Intel öffnen denselben D3D12 Cross-Adapter Heap.
* Ein gemeinsamer Buffer wurde mit 64 Testwerten erfolgreich geprüft.
* Ein persistenter Shared Fence synchronisiert die Queues direkt von GPU zu GPU. Seine Werte steigen pro Job monoton: WorkerReady/PrimaryComplete verwenden die Paare 1/2, 3/4, 5/6 und so weiter.
* Die CPU vermittelt die GPU-Abhängigkeit nicht; Worker- und Primary-Queue verwenden <code>Signal</code> und <code>Wait</code> direkt auf der GPU.
* Der separate Readback-Verifikationstest darf weiterhin blockieren. Der normale Runtime-Pfad wartet dagegen nicht auf GPU-Leerlauf.

=== Texturtransport ===

Direkte Cross-Adapter-Texturen sind auf dem Testsystem nicht beidseitig verfügbar: Die Intel UHD meldet Unterstützung für Row-Major Cross-Adapter Textures, die RTX 5060 Laptop GPU nicht. Deshalb verwendet das Projekt einen allgemeineren Buffer-Fallback.

<pre>
Intel MainTextureCS
-> persistente Worker-Textur
-> CopyTextureRegion
-> persistenter Shared Cross-Adapter Buffer
-> Worker signalisiert WorkerReady (1, 3, 5, ...)
-> UE-Primary-Queue wartet auf WorkerReady
-> direkte Kopie in persistente UE-eigene FTextureRHIRef
-> Primary signalisiert PrimaryComplete (2, 4, 6, ...)
</pre>

Der robuste Normal-Pfad kopiert die Worker-Textur über den Shared Buffer direkt in eine von Unreal erzeugte <code>FTextureRHIRef</code>. Breite, Höhe und Row Pitch werden dynamisch aus Worker-Ressource und Transport-Metadaten übernommen. Der erfolgreiche 128×96-RGBA8-Test verwendet 512 Byte Row Pitch und 49.152 Byte Transfergröße. Die Output Registry trennt Persistent-, Pending- und Ready-Zustände sowie Inhaltsgeneration und Texturidentität. Dadurch kann eine verspätete Completion keinen neueren Output zurückrollen.

=== Non-blocking Runtime-Pfad ===

Die produktive Testlogik ist aus dem Konsolenkommando in eine gekapselte NormalPath-API verschoben. <code>SubmitWorkerTextureComputeJob()</code> reicht den Worker-Dispatch ohne CPU-Wait ein. <code>QueueNormalTextureTransfer()</code> reiht Wait, Kopie und Completion-Signal in Unreals D3D12-Kontext ein. Der normale MainTextureCS-Pfad enthält weder CPU-Fence-Waits noch Readback, <code>Map</code> oder Pixelvergleich. <code>TickNormalTextureTransfers()</code> prüft die Primary-Completion non-blocking über einen Runtime-Pump; <code>RHIEndFrame()</code> bleibt als Fallback erhalten.

Eine passende Primary-<code>FTextureRHIRef</code> wird pro Worker und Konfiguration persistent gehalten. Nach PrimaryComplete kann der nächste Job dieselbe Resource erneut verwenden; dabei führt Unreal die Übergänge <code>SRVMask -> CopyDest -> SRVMask</code> aus. Eine backend-neutrale RHI-Provider-API reicht die Ready-Textur an die Engine weiter. <code>UExperimentalMultiGPUTexture</code> hält eine stabile <code>UTexture</code> samt TextureReference und bindet die persistente <code>FTextureRHIRef</code> ohne zusätzlichen Pixel-Copy. Eine native D3D12-Resource wird weiterhin nicht blind als UE-Textur gewrappt, weil Unreals Resource-State-Buchhaltung den tatsächlichen nativen Zustand sonst nicht sicher kennt.

=== Sichtbarer TPS-Consumer ===

<code>AExperimentalMultiGPUDisplayActor</code> zeigt die Worker-Ausgabe im Third-Person-Testlevel über den Materialparameter <code>MultiGPUTexture</code> an. Damit ist der Output nicht mehr nur über Logs oder Readback nachgewiesen: Die Intel UHD erzeugt fortlaufend die Texturinhalte, während die RTX die Spielwelt und das Material rendert. <code>TextureConsumerCS</code> kann Ready-Ausgaben auf der Primary zusätzlich als SRV lesen und fünf quantisierte Samples im Debugpfad prüfen.

=== Lebensdauer und automatisches Cleanup ===

Der Normal-Pfad verwendet pro Worker genau einen persistenten Runtime-Slot. Worker-Textur, Root Signature, PSO, Descriptor Heap, Command Allocator/List und Worker-Fence werden nach der ersten kompatiblen Initialisierung wiederverwendet. Dasselbe gilt für Shared Heap/Buffer/Fence und die Transport-Command-Objekte. Der In-Flight-Job trägt nur noch die nötigen Job-, Generation- und Fence-Metadaten.

<pre>
Runtime Request
-> Completion non-blocking prüfen
-> falls Slot frei: Worker Dispatch
-> WorkerReady-Fence signalisieren
-> Primary Wait, SafeCopy und PrimaryComplete-Signal
-> Output Pending
-> Runtime-Pump oder RHIEndFrame prüft GetCompletedValue()
-> Output Ready publizieren
-> Slot wiederverwendbar
</pre>

Backpressure erlaubt maximal einen echten In-Flight-Job pro Worker. Ein Busy-Request setzt keine GPU-Arbeit ab, setzt keine Ressourcen zurück und erhöht <code>PatternPhase</code> nicht. Worker-Fence-Werte steigen mit jedem akzeptierten Submit 1, 2, 3 und so weiter; der persistente Shared Fence verwendet fortlaufend die Paare 1/2, 3/4, 5/6. Fehler nach Übergabe von Ressourcen an die GPU führen zu sicherem Retire beziehungsweise Retention statt zu vorzeitigem Reuse.

=== Texture Stream und Benchmarking ===

Der projektseitige Texture Stream akzeptiert eine beliebige positive, endliche Zielrate. Punkt und Komma sind als Dezimaltrenner möglich. Optional lässt sich die Zahl erfolgreicher Submits begrenzen; Busy- oder Failed-Versuche verbrauchen dieses Limit nicht. Der Quiet-Modus unterdrückt per-Job-Ausgaben, behält aber Start, echte Fehler und die Abschlussstatistik bei.

Die Statistik unterscheidet Timer-Ticks, angenommene Submits, Busy/Failed, Ready, In-Flight und die jeweiligen effektiven Raten. Diagnosezeitpunkte erfassen unter anderem RequestAccepted, RenderCommandExecution, WorkerSubmit, NormalTransferQueued und ReadyObserved.

{| class="wikitable"
! Test
! Ergebnis
! Aussage
|-
| 5 Hz, 20 Submits
| etwa 5 Ready/s, 20/20, kein Busy
| Entspannter Single-Slot-Betrieb
|-
| 1000 Hz, 100 Submits, quiet
| 100/100 Ready, 0 Fehler, etwa 58 Ready/s
| Backpressure begrenzt den Durchsatz sicher
|-
| 1000 Hz bei <code>t.MaxFPS 30</code>
| etwa 28–29 Ready/s trotz rund 982 Timer-Ticks/s
| Primary-/SafeCopy-/Ready-Kette ist effektiv framegekoppelt
|}

Ein zusätzlicher non-blocking Aufruf von <code>ImmediateFlush(DispatchToRHIThread)</code> erreicht hohe Render-Command-Raten, hebt die gemessene Frame-Kopplung aber nicht auf. Im 30-FPS-Test lag der RHIEndFrame-spezifische Completion-Takt praktisch exakt bei 30 Hz. Das aktuelle Problem ist damit eingegrenzt: Nicht der Stream-Timer, sondern die Primary-RHI-/D3D12-Submission der SafeCopy-Kette bestimmt die sichtbare Ready-Rate.

=== Queue-Submission-Diagnose ===

<code>MultiGPUD3D12QueueProbe</code> untersucht die Submission unabhängig vom sichtbaren Texturpfad. Neben <code>full</code>, <code>waitonly</code> und <code>signalonly</code> existieren inzwischen die Diagnosemodi <code>computeonly</code>, <code>commandonly</code>, <code>barrieronly</code>, <code>barrierprivate</code> und <code>copybuffer</code>. Als Queues stehen <code>graphics</code>, <code>copy</code>, <code>native</code>, <code>worker</code>, <code>worker-copy</code> und <code>worker-high</code> zur Verfügung. Graphics und Copy verwenden <code>RHIRunOnQueue(..., false)</code> auf UE-verwalteten Primary-Queues; die übrigen Varianten isolieren private beziehungsweise bereits vorhandene native D3D12-Queues.

Der Probe misst Request, Worker-Submit, <code>RHIRunOnQueue</code>-Aufruf und -Callback, Primary-Execute, Fence-Completion sowie Ready bis zum nächsten akzeptierten Submit. Er fügt keine CPU-Waits, Readbacks, Maps oder <code>BlockUntilGPUIdle</code> ein und beschreibt keine Textur des sichtbaren Normal-Pfads.

{| class="wikitable"
! Test
! Ergebnis
! Befund
|-
| UE Graphics, signal-only, 30 FPS
| 33,319 ms PrimaryExecute bis Ready
| UE-verwaltete Graphics-Submission skaliert mit der Frame-Dauer
|-
| UE Copy, signal-only, 30 FPS
| 32,593 ms PrimaryExecute bis Ready
| Auch die UE-verwaltete Copy Queue ist framegekoppelt
|-
| Private Primary-DIRECT-Queue, signal-only
| etwa 0,014 ms Queue/Fence-Latenz; nach Lifecycle-Fix rund 999 Ready/s bei 30 FPS
| Native Queue und Scheduler sind vollständig vom Frame entkoppelt
|-
| Worker signal-only / leere Command List
| jeweils rund 1000 Ready/s bei 30 FPS
| Worker-Queue, Fence und reine Submission sind nicht framegekoppelt
|-
| Worker <code>CopyBufferRegion</code>, 30 / 60 / 120 FPS
| 29,41 / 58,25 / 113,08 Ready/s
| Bereits eine echte 256-Byte-GPU-Kopie folgt im UE-Prozess dem Frame-Raster
|-
| Worker COPY Queue / HIGH Priority, 30 FPS
| jeweils rund 29,42 Ready/s
| Queue-Typ und Priorität beseitigen die Kopplung nicht
|-
| Standalone-D3D12 auf derselben Intel UHD
| 92.956 Copy-Jobs/s; 0,007 ms durchschnittliche Fence-Latenz
| Die Kopplung ist UE-Prozess-/Scheduling-spezifisch, keine allgemeine Intel-, WDDM- oder D3D12-Grenze
|}

Der <code>RHIRunOnQueue</code>-Callback selbst erreicht den D3D12-Submission-Thread typischerweise bereits nach etwa 0,02–0,05 ms; die Verzögerung entsteht danach in der verwalteten Queue-/Submission-Reihenfolge. <code>SubmitCommandsHint()</code> ist in UE 5.8 nur ein veralteter Alias für <code>ImmediateFlush(DispatchToRHIThread)</code> und stellt daher keinen stärkeren Submission-Mechanismus dar.

Der native Test ist ein '''Architekturbeweis, noch kein Experimental- oder Direct-Modus'''. Die zunächst gemessene Verzögerung von rund 32 ms lag zwischen der In-Flight-Freigabe und dem nächsten Request auf dem Render Thread. Für <code>signalonly/native</code> wurde der sichere Completion-/Submit-Lifecycle deshalb in den frameunabhängigen Scheduler verlegt. Danach erreichten zwei 100-Job-Läufe bei <code>t.MaxFPS 30</code> rund 999 bis 1029 Ready/s, ohne Busy oder Fehler.

Der anschließende <code>full native</code>-Test lokalisierte die verbleibende Kopplung auf echte Worker-GPU-Arbeit: WorkerSubmit bis WorkerReady benötigte bei 30, 60 und 120 FPS ungefähr 33,29, 16,93 und 8,45 ms; WorkerReady bis PrimaryReady war danach praktisch sofort. Signal-only und eine leere Command List waren schnell, Resource Barriers und eine 256-Byte-Kopie dagegen framegebunden. Ein eigenständiger D3D12-Microbenchmark auf derselben Intel UHD erreichte außerhalb von Unreal bei derselben Kopie rund 92.956 Jobs/s mit 0,007 ms mittlerer Fence-Latenz. Die genaue Ursache im UE-Prozess beziehungsweise dessen GPU-Scheduling-Kontext bleibt offen und wird vorerst bis zum Gegencheck mit der vorhandenen Intel Arc A380 geparkt.

=== Worker-Rasterpfad und RasterStream ===

<code>ExperimentalMultiGPU.TestRasterWorker</code> weist erstmals echte Rasterizer-Arbeit auf der Intel-Worker-GPU nach. <code>RasterWorkerVS</code> und <code>RasterWorkerPS</code> werden über Unreals Global-Shader-Pfad kompiliert und für ein natives Worker-Graphics-PSO verwendet. Ein persistentes 128×96-RGBA8-RenderTarget besitzt RTV, leere Root Signature und eine DIRECT-Command-List. Der Vertex Shader erzeugt drei Vertices über <code>SV_VertexID</code>; der Pixel Shader schreibt interpolierte RGB-Farben.

Der Job wechselt das RenderTarget von <code>COPY_SOURCE</code> nach <code>RENDER_TARGET</code>, führt Clear und <code>DrawInstanced(3,1,0,0)</code> aus und wechselt anschließend zurück nach <code>COPY_SOURCE</code>. Danach verwendet er unverändert den robusten Normalpfad aus Cross-Adapter-Shared-Buffer, Primary SafeCopy, persistenter <code>FTextureRHIRef</code>, <code>UExperimentalMultiGPUTexture</code> und DisplayActor. Der Runtime-Test meldete einen akzeptierten Submit und <code>RasterWorker READY</code> für Generation 1; die 128×96-UTexture wurde erfolgreich gebunden.

Der einmalige Test wurde außerdem zu einem frei konfigurierbaren RasterStream ausgebaut. Ein sichtbarer Lauf mit 10 Hz und 50 erfolgreichen Submits endete mit 50 Ready-Ausgaben, 0 Busy und 0 Fehlern bei etwa 9,90 Ready/s. Primary-Textur und Materialbindung blieben dabei persistent.

=== Raster3D mit echten Vertex- und Indexbuffern ===

Der Worker besitzt inzwischen einen kleinen eigenständigen 3D-Rasterpfad mit perspektivischer Kamera, Model-View-Projection-Matrix als Root Constants, D32_FLOAT-Depth-Buffer und Depth-Test. Der finale Testwürfel verwendet 24 POSITION/COLOR-Vertices, 36 <code>uint16</code>-Indices und <code>DrawIndexedInstanced(36,1,0,0,0)</code>; sechs getrennte Seitenfarben machen Ausrichtung und Rotation sichtbar nachvollziehbar.

Die statischen Meshdaten werden einmalig über private Upload-Buffer in DEFAULT-Heaps übertragen. Der Init-Fence wird non-blocking über <code>GetCompletedValue()</code> beobachtet. Der eigentliche Runtime-Renderpfad enthält weiterhin keine CPU-Waits und keine Maps.

=== UE-Static-Meshes auf der Worker-GPU ===

<code>StaticMeshWorker</code> extrahiert echte LOD0-Geometrie aus <code>UStaticMesh</code>-Assets. POSITION und NORMAL sowie <code>uint32</code>-Indices werden in POD-Daten überführt, einmalig asynchron in eigene Worker-VB/IB hochgeladen und anschließend per <code>DrawIndexedInstanced</code> gerendert. Assetpfade sind dynamisch; Auto-Fit richtet Kamera beziehungsweise Modellmaßstab an den Bounds aus.

Sichtbar korrekt getestet wurden:

{| class="wikitable"
! Asset
! Vertices
! Indices
|-
| Sphere
| 559
| 2880
|-
| Cube
| 54
| 144
|-
| Cylinder
| 334
| 1536
|}

=== Multi-Mesh Worker-Szene ===

<code>StaticMeshScene</code> rendert Sphere, Cube und Cylinder gemeinsam in einen Color-/Depth-Frame. Der verifizierte Test umfasst insgesamt 947 Vertices und 4560 Indices, drei <code>DrawIndexedInstanced</code>-Aufrufe und nur einen anschließenden Cross-Adapter-/Normal-SafeCopy-Transfer. Damit ist nicht mehr nur ein synthetisches Primitive, sondern mehrere echte UE-Meshes mit gemeinsamer Tiefenprüfung im Worker-Frame sichtbar nachgewiesen.

=== WorldStaticMeshScene ===

<code>ExperimentalMultiGPUWorldStaticMeshScene.cpp</code> sammelt im Engine-Layer bis zu acht sichtbare <code>UStaticMeshComponent</code>s von Actors mit dem Tag <code>MultiGPUWorker</code>. Meshdaten und World-Transforms werden im Game Thread in reine POD-Strukturen und 4×4-Matrizen kopiert. D3D12RHI erhält keine <code>UObject</code>-Pointer. Mehrere Instanzen desselben Meshes teilen den persistenten Worker-Mesh-Cache und unterscheiden sich nur durch Modelmatrix und Draw Call.

Der Pfad wurde inzwischen sichtbar im PIE-Level verifiziert. Drei getaggte Static-Mesh-Actors erschienen mit ihren tatsächlichen relativen Positionen, Rotationen und Skalierungen im Worker-Bild. Die zentrale Koordinatenumrechnung lautet:

<pre>Worker (X, Y, Z) = (UE Y, UE X, -UE Z)</pre>

Die Transformation besitzt die Determinante +1 und ist damit keine Spiegelung. Das notwendige horizontale Spiegeln erfolgt ausschließlich auf der Presentation-Plane, nicht im Worker-Renderpfad.

=== Kontinuierlicher WorldStaticMeshSceneStream ===

<code>StartWorldStaticMeshSceneStream</code> erfasst die getaggte Szene fortlaufend im Game Thread. Reine Änderungen an Transform oder Kamera lösen keinen erneuten Mesh-Upload aus. Hinzugekommene, entfernte, unsichtbare oder umgetaggte Components werden im nächsten Snapshot berücksichtigt. Single-Slot-Backpressure verhindert einen wachsenden Rückstau.

Ein verifizierter 30-Hz-Lauf endete nach 31,184 Sekunden mit 835 Ticks, 691 angenommenen Submits, 144 Busy, 0 Fehlern und 691 Ready-Frames. Die effektive Ready-Rate betrug 22,16 Hz. Dieser Test belegt die funktionale Live-Aktualisierung; die Rate war noch kein Optimierungsziel.

=== SceneCapture2D als Worker-Kamera ===

<code>TestSceneCaptureStaticMeshScene</code> verwendet eine echte <code>ASceneCapture2D</code> beziehungsweise <code>USceneCaptureComponent2D</code> aus der laufenden PIE-Welt als Kameraquelle. Der empfohlene Editor-Weg ist das Component Tag <code>MultiGPUWorkerCamera</code> auf der <code>CaptureComponent2D</code>; ein gleichnamiges Actor-Tag bleibt nur als Legacy-Fallback.

Ausgelesen werden World Location, Rotation, Forward/Right/Up, <code>FOVAngle</code> und <code>ProjectionType</code>. Orthografische Projektion wird derzeit sauber abgelehnt. Die SceneCapture2D liefert ausschließlich Kameradaten: Ihr UE-RenderTarget wird weder gelesen noch kopiert. Die Intel-Worker-GPU rendert die Geometrie selbst. Kamera und Actors werden gemeinsam mit <code>SceneScale = 0.01</code> in Worker-Koordinaten überführt; Auto-Fit und Scene-Recentering sind in diesem Modus deaktiviert.

Die 128×96-Worker-Projektion verwendet ein Seitenverhältnis von 4:3 und interpretiert <code>FOVAngle</code> als horizontales FOV. Nach den Orientierungstests wird nur die Anzeige über <code>SetRelativeScale3D(FVector(-4.0f, -3.0f, 1.0f))</code> korrigiert; dies entspricht <code>U' = 1-U</code> und <code>V' = 1-V</code>.

=== Live SceneCaptureStaticMeshSceneStream ===

<code>StartSceneCaptureStaticMeshSceneStream</code> liest Kamera-Transform, Kamerabasis, FOV und aktuelle Actor-Transforms pro Snapshot neu im Game Thread. Der Worker erhält weiterhin ausschließlich POD-Daten, verwendet den persistenten Mesh-Cache sowie ein gemeinsames Color- und D32-Depth-Target und führt pro akzeptiertem Frame genau einen Cross-Adapter-/Normal-SafeCopy-Transfer aus.

Der Quiet-Test

<pre>ExperimentalMultiGPU.StartSceneCaptureStaticMeshSceneStream 30 300 quiet</pre>

lieferte in 10,084 Sekunden 301 Ticks, 300 Submits, 1 Busy, 0 Fehler und 300 Ready-Frames. Die effektive Ready-Rate betrug 29,75 Hz. Bewegungen der Kamera und Actors sowie FOV-Änderungen erschienen live auf der Display-Plane. Damit ist erstmals ein kleiner SceneCapture-/CCTV-artiger Worker-Kanal vollständig funktional nachgewiesen.

=== Dynamische SceneCapture-Auflösung ===

Die SceneCapture-Ausgabe ist nicht mehr fest auf 128×96 Pixel begrenzt. <code>ExperimentalMultiGPU.SetSceneCaptureResolution <Width> <Height></code> setzt ganzzahlige Dimensionen von 1 bis 4096; <code>GetSceneCaptureResolution</code> zeigt die aktive Einstellung. 128×96 bleibt der Standard. Während ein SceneCapture-Stream läuft, wird ein Auflösungswechsel absichtlich abgelehnt, damit keine In-Flight-Ressourcen ausgetauscht werden.

Color Target, D32-Depth-Buffer, Row Pitch, Shared-Buffer-Transport, SafeCopy, persistente Primary-Textur und <code>UExperimentalMultiGPUTexture</code> übernehmen die gewählten Dimensionen. Projektion und Display-Plane verwenden das echte Seitenverhältnis. Die bestätigte Anzeigeorientierung <code>U' = 1-U</code> und <code>V' = 1-V</code> bleibt eine reine Presentation-Korrektur; Worker-Basis und Kameramathematik ändern sich nicht.

=== Scheduler-Korrektur bei SceneCapture ===

Ein 1920×1080-Test mit 25 Hz erreichte zunächst trotz fehlerfreier Frames nur 13,90 Ready-Hz und erzeugte 222 Busy-Ticks. Ursache war kein GPU-Limit, sondern ein Polling-Aliasing: Eine frühe Game-Thread-Prüfung konnte den Timer-Slot verwerfen, obwohl die Completion kurz darauf im CoreTicker/RHI-Pump sichtbar geworden wäre.

Die frühe <code>IsRuntimeTextureUpdateInFlight()</code>-Prüfung wurde für diesen Stream entfernt. Der Pending-Request bleibt als Backpressure-Gate erhalten; die maßgebliche Busy-Entscheidung fällt nun erst im Render Command nach <code>TickNormalTextureTransfers(nullptr, true)</code>. Single-Slot, POD-Snapshots und non-blocking <code>GetCompletedValue()</code> bleiben erhalten. Es wurden weder CPU-Waits noch zusätzliche Threads eingeführt.

Nach der Korrektur erreicht 1080p bei 25 Hz 24,79 Ready-Hz mit 1 Busy; bei 30 Hz sind es 29,43 Ready-Hz mit 4 Busy.

=== Skalierung bis 4K60 ===

Die Pipeline wurde von 640×360 bis 3840×2160 getestet. Bei 640×360/30 Hz und 1280×720/30 Hz wurden 29,85 beziehungsweise 29,82 Ready-Hz ohne Busy erreicht. 1920×1080/60 Hz lieferte 59,40 Ready-Hz ohne Busy, 2560×1440/60 Hz 59,21 Ready-Hz mit 1 Busy und 3840×2160/60 Hz 59,02 Ready-Hz mit 2 Busy.

Ein zusätzlicher 4K60-Stresstest mit acht Static-Mesh-Instanzen und drei gecachten Unique Meshes erreichte in 5,049 Sekunden '''300 von 300 Ready-Frames, 0 Busy, 0 Fehler und 59,42 effektive Ready-Hz'''. Acht Draw Calls, gemeinsamer Depth Buffer, Cross-Adapter-Transport und SafeCopy liefen dabei im vorhandenen Single-Slot. Das ist ein Stabilitätsnachweis der aktuellen Mini-Szene, kein allgemeiner GPU-Benchmark.

=== Skeletal Mesh in Reference Pose ===

<code>ExperimentalMultiGPU.TestSkeletalMeshWorker</code> erweitert den Geometriepfad auf <code>USkeletalMeshComponent</code>. Der Engine-Layer sucht deterministisch die erste sichtbare, getaggte Komponente und extrahiert LOD0-Positionen, Normalen, Indices und Render Sections. D3D12RHI erhält wie bisher ausschließlich POD-Geometrie und Modelmatrizen.

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.

== Test- und Diagnosebefehle ==

{| class="wikitable"
! Befehl
! Zweck
|-
| <code>ExperimentalMultiGPU.TestComputeShader</code>
| Führt den vollständigen Worker-Compute-Testpfad aus. Er enthält auch ältere Debug- und Regressionstests mit CPU-Readback und ist daher nicht mit dem reinen asynchronen Runtime-Pfad gleichzusetzen.
|-
| <code>ExperimentalMultiGPU.TestTextureConsumer</code>
| Testet <code>TextureConsumerCS</code> auf der Primary-GPU. Die aktuelle Ready-Textur wird über UE-RHI gelesen und anhand ausgewählter Testpixel per Debug-Readback geprüft.
|-
| <code>ExperimentalMultiGPU.TestTextureBridge</code>
| Prüft die Bridge von der fertigen <code>FTextureRHIRef</code> zu <code>UExperimentalMultiGPUTexture</code> und damit den UE- und materialtauglichen Texturpfad.
|-
| <code>ExperimentalMultiGPU.SpawnDisplayActor</code>
| Spawnt den Test-Actor mit Plane im Spiel. Das Material zeigt darauf die vom Worker erzeugte Textur an.
|-
| <code>ExperimentalMultiGPU.TestRasterWorker</code>
| Rasterisiert auf der Worker-GPU ein echtes RGB-Dreieck per Vertex- und Pixel-Shader und transportiert das Ergebnis über den normalen SafeCopy-Pfad bis zum DisplayActor.
|-
| <code>ExperimentalMultiGPU.StartRasterStream</code> / <code>ExperimentalMultiGPU.StopRasterStream</code>
| Startet beziehungsweise stoppt den kontinuierlichen RGB-Dreieck-RasterStream mit frei wählbarer Zielrate, optionalem Submit-Limit und Quiet-Modus.
|-
| <code>ExperimentalMultiGPU.TestRaster3DWorker</code>
| Rendert einmalig den perspektivischen 3D-Testwürfel mit Depth Buffer und echten Vertex-/Indexbuffern.
|-
| <code>ExperimentalMultiGPU.StartRaster3DStream</code> / <code>ExperimentalMultiGPU.StopRaster3DStream</code>
| Startet beziehungsweise stoppt den kontinuierlichen Raster3D-Test.
|-
| <code>ExperimentalMultiGPU.TestStaticMeshWorker [AssetPath]</code>
| Extrahiert und rendert LOD0-Geometrie eines UE-Static-Mesh-Assets; ohne optionalen Pfad wird das konfigurierte Testasset verwendet.
|-
| <code>ExperimentalMultiGPU.TestStaticMeshScene</code>
| Rendert Sphere, Cube und Cylinder gemeinsam mit drei Draw Calls und einem anschließenden Transfer.
|-
| <code>ExperimentalMultiGPU.TestWorldStaticMeshScene</code>
| Rendert einen einmaligen POD-Snapshot der sichtbaren, mit <code>MultiGPUWorker</code> getaggten StaticMeshComponents aus der laufenden World. Der sichtbare PIE-Nachweis ist erfolgreich.
|-
| <code>ExperimentalMultiGPU.StartWorldStaticMeshSceneStream [Hz] [MaxSuccessfulSubmits] [quiet]</code> / <code>StopWorldStaticMeshSceneStream</code>
| Startet beziehungsweise stoppt den kontinuierlichen Stream der getaggten UE-Welt mit Live-Transforms und persistentem Mesh-Cache.
|-
| <code>ExperimentalMultiGPU.SetSceneCaptureResolution <Width> <Height></code> / <code>GetSceneCaptureResolution</code>
| Setzt beziehungsweise zeigt die gemeinsame SceneCapture-Auflösung. Erlaubt sind ganzzahlige Werte von 1 bis 4096 je Achse; Änderungen während eines laufenden Streams werden abgelehnt.
|-
| <code>ExperimentalMultiGPU.TestSceneCaptureStaticMeshScene</code>
| Rendert einen einmaligen Worker-Snapshot aus Sicht der mit <code>MultiGPUWorkerCamera</code> markierten SceneCapture2D-Kamera.
|-
| <code>ExperimentalMultiGPU.StartSceneCaptureStaticMeshSceneStream [Hz] [MaxSuccessfulSubmits] [quiet]</code> / <code>StopSceneCaptureStaticMeshSceneStream</code>
| Startet beziehungsweise stoppt den Live-Worker-Kanal mit fortlaufend aktualisierten Kamera-, FOV- und Actor-Daten.
|-
| <code>ExperimentalMultiGPU.TestSkeletalMeshWorker</code>
| Rendert das erste sichtbare, getaggte Skeletal Mesh in LOD0 und Reference Pose sectionsweise auf der Worker-GPU.
|-
| <code>ExperimentalMultiGPU.StartTextureStream</code>
| Startet den sichtbaren Normal-Pfad: Worker-Textur → Cross-Adapter-Transfer → SafeCopy → UE-Textur → Material.
|-
| <code>ExperimentalMultiGPU.StopTextureStream</code>
| Verhindert weitere Submits des laufenden Streams. Ein bereits eingereichter GPU-Job darf noch sicher fertig werden.
|-
| <code>ExperimentalMultiGPU.StartQueueProbe</code>
| Startet den Diagnose-Benchmark für Primary-Queue-, Fence- und Submission-Verhalten. Der Probe verändert die sichtbare Textur nicht.
|}

=== Texture Stream ===

Grundsyntax:

<pre>
ExperimentalMultiGPU.StartTextureStream [Hz] [MaxSuccessfulSubmits] [quiet]
</pre>

{| class="wikitable"
! Beispiel
! Wirkung
|-
| <code>ExperimentalMultiGPU.StartTextureStream</code>
| Standardmäßig etwa 5 Hz, ohne Submit-Limit.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 37.5</code>
| Fordert 37,5 Hz ohne Submit-Limit an. Sowohl <code>37.5</code> als auch <code>37,5</code> werden akzeptiert.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 1000 100</code>
| Fordert 1000 Hz an und stoppt nach exakt 100 erfolgreichen Submits.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 1000 100 quiet</code>
| Wie zuvor, unterdrückt aber Per-Job- und Busy-Logspam.
|}

Die Hz-Angabe ist eine '''Ziel- beziehungsweise Request-Frequenz'''. <code>1000</code> bedeutet daher nicht automatisch 1000 fertige Texturen pro Sekunde. Die tatsächliche Rate hängt unter anderem von Timer, Submission, Backpressure, Queue-Latenz und Slot-Lifecycle ab. <code>MaxSuccessfulSubmits</code> zählt nur angenommene Submits; Busy- und Failed-Versuche verbrauchen das Limit nicht.

=== QueueProbe ===

Grundsyntax:

<pre>
ExperimentalMultiGPU.StartQueueProbe <Hz> <MaxSubmits> [quiet] [Mode] [Queue]
</pre>

{| class="wikitable"
! Modus
! Ausgeführter Pfad
|-
| <code>full</code>
| Worker Compute → Cross-Adapter-Transfer → Primary Wait → Copy → Completion Fence.
|-
| <code>waitonly</code>
| Worker Compute → Cross-Adapter-Transfer → Primary wartet auf WorkerReadyFence → Completion Fence. Es findet keine Texturkopie statt.
|-
| <code>signalonly</code>
| Keine Textur, kein Worker-Wait und keine Kopie; nur Queue und Fence. Dieser Modus isoliert das Queue-Verhalten.
|-
| <code>commandonly</code>
| Reicht eine leere echte Worker-Command-List ein und trennt Command-Submission von GPU-Arbeit.
|-
| <code>barrieronly</code> / <code>barrierprivate</code>
| Isoliert Resource-Barriers auf Worker-Ressourcen beziehungsweise einer privaten Testtextur.
|-
| <code>copybuffer</code>
| Führt eine minimale echte <code>CopyBufferRegion</code>-Operation über 256 Byte aus.
|}

{| class="wikitable"
! Queue
! Bedeutung
|-
| <code>graphics</code>
| Vorhandene UE Primary Graphics-/Direct-Queue über <code>RHIRunOnQueue</code>.
|-
| <code>copy</code>
| Vorhandene UE Primary Copy Queue über <code>RHIRunOnQueue</code>.
|-
| <code>native</code>
| Vollständig private native D3D12-DIRECT-Queue auf der Primary; reine Diagnose, kein fertiger Experimental-Modus.
|-
| <code>worker</code>
| Vorhandene native Worker-DIRECT-Queue.
|-
| <code>worker-copy</code>
| Separate native Worker-COPY-Queue.
|-
| <code>worker-high</code>
| Separate Worker-DIRECT-Queue mit hoher Priorität.
|}

Typische Beispiele:

<pre>
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet full graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet waitonly graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly copy
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly native
</pre>

Der letzte Befehl ist aktuell die wichtigste isolierte Gegenprobe. Mit der privaten nativen Queue wurde bei 30 FPS eine durchschnittliche Latenz <code>primaryExecuteToReadyAvgMs = 0.014 ms</code> gemessen.

=== Benchmark-CVars ===

{| class="wikitable"
! CVar
! Zweck
|-
| <code>r.VSync 0</code>
| Deaktiviert VSync, damit es die Messung nicht begrenzt.
|-
| <code>t.MaxFPS 30</code> <code>t.MaxFPS 60</code> <code>t.MaxFPS 120</code>
| Setzt die Engine-Framerate für reproduzierbare Frame-Coupling-Tests.
|-
| <code>t.MaxFPS 0</code>
| Entfernt das normale <code>t.MaxFPS</code>-Limit. Dieser Lauf ist als zusätzliche Diagnose-Gegenprobe vorgesehen.
|}

== 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.

== Historische Vorläufer ==

Die Grundidee heterogener Multi-GPU-Nutzung ist nicht neu. Bereits mit der Einführung von Direct3D 12 entstanden mehrere Versuche, integrierte und dedizierte GPUs gemeinsam zu verwenden. Eine allgemein einsetzbare Lösung für moderne UE5-Spiele hat sich daraus jedoch nicht entwickelt.

=== Microsoft und Epic: UE4 Elemental Demo (2015) ===

Microsoft zeigte eine angepasste Unreal-Engine-4-Version der Elemental-Demo, bei der eine NVIDIA-GPU und eine Intel-iGPU gemeinsam arbeiteten. Das erklärte Ziel war, ansonsten ungenutzte Grafikleistung in Hybrid-Systemen zu verwenden. Dieser Versuch ist der Grundidee des Projekts besonders ähnlich, blieb aber eine technische Demonstration.

=== Intel: D3D12 Multi-Adapter Sample (2015) ===

Intels Beispiel kombinierte eine GeForce 840M mit Intel HD Graphics 5500. Beide GPUs berechneten getrennte Teile einer einfach parallelisierbaren Raytracing-Szene. Cross-Adapter-Ressourcen und Shared Fences führten die Ergebnisse anschließend zusammen. Intel berichtete in diesem Test von nahezu halbierter Framezeit, warnte jedoch ausdrücklich davor, das Ergebnis unmittelbar auf reale Spiele zu übertragen.

=== Ashes of the Singularity ===

Die Nitrous Engine von ''Ashes of the Singularity'' setzte Direct3D-12-Explicit-Multiadapter in einem veröffentlichten Spiel ein. Dabei konnten auch unterschiedliche GPU-Modelle und Hersteller zusammenarbeiten. Das war ein wichtiger Praxisnachweis, blieb in der Spielebranche aber eine seltene Ausnahme.

=== Weitere verwandte Ansätze ===

* ''Rise of the Tomb Raider'' erhielt explizite Direct3D-12-Multi-GPU-Unterstützung, vor allem für klassische Kombinationen ähnlicher GPUs.
* NVIDIA VR SLI wies bei Virtual Reality jeder GPU ein Auge zu. Das verteilt unabhängige Ansichten, bleibt jedoch NVIDIA-spezifisch.
* Unreal nDisplay kann Viewports oder Frustums auf weitere GPUs beziehungsweise Prozesse auslagern und das fertige Bild zur Ausgabe-GPU zurückführen. Der Einsatzbereich ist hauptsächlich Virtual Production.
* Forschung und High-Performance Computing verwenden seit Jahren Scheduler für heterogene GPUs, allerdings überwiegend für Compute- und Datenverarbeitungsaufgaben statt für einen allgemeinen UE5-Echtzeitrenderer.

=== Abgrenzung dieses Projekts ===

Das Projekt erfindet Direct3D-12-Explicit-Multiadapter nicht neu. Sein eigener Ansatz liegt in der Kombination aus tiefer UE5.8-RHI-Integration, UE-kompilierten Shadern auf unabhängigen Worker-Devices, frei wählbaren Spiel- und Compute-Workloads, Capability- und Performance-Scheduler, mehreren Fallback-Pfaden sowie dem langfristigen Ziel beliebiger Hersteller und mehrerer Worker.

== Vergleich mit anderen Multi-GPU-Verfahren ==

{| class="wikitable"
! Verfahren
! Arbeitsweise
! Verhältnis zu diesem Projekt
|-
| SLI / CrossFire
| Treiber- beziehungsweise Verbundlösung für meist ähnliche GPUs; häufig wird die Bildarbeit verteilt.
| Dieses Projekt benötigt keinen herstellerspezifischen GPU-Verbund und weist Aufgaben ausdrücklich selbst zu.
|-
| AFR (Alternate Frame Rendering)
| GPU 1 rendert einen Frame, GPU 2 den nächsten.
| Das Projekt verteilt unabhängige Aufgaben statt aufeinanderfolgender Frames. Dadurch werden Frame-Abhängigkeiten und typisches AFR-Pacing vermieden.
|-
| SFR (Split Frame Rendering)
| Mehrere GPUs bearbeiten Bereiche desselben Frames.
| Erfordert enge Lastverteilung und viel Datenaustausch. Das Projekt bevorzugt vollständig abgrenzbare Workloads und überträgt deren Ergebnis.
|-
| Direct3D 12 Linked Multiadapter
| Mehrere vom Treiber verbundene GPUs erscheinen als Knoten eines logischen Adapters.
| Eignet sich eher für eng kompatible GPUs. Das Projekt verwendet unabhängige Devices (Unlinked/Explicit Multiadapter) und unterstützt dadurch heterogene Herstellerkombinationen.
|-
| Direct3D 12 Unlinked / Explicit Multiadapter
| Die Anwendung verwaltet getrennte Adapter, Ressourcen und Synchronisation selbst.
| Das ist die technische Familie des Projekts. Hinzu kommen die eigene UE5-RHI-Integration, Workload-Ziele, Fallbacks und der geplante Scheduler.
|-
| UE nDisplay mGPU / Multi-Process
| Separate GPUs rendern bestimmte Viewports oder Frustums, vor allem für Virtual Production; Ergebnisse werden zur Ausgabe-GPU kopiert.
| Ähnliche Idee der aufgabenweisen Trennung, aber für einen anderen Einsatzbereich. Dieses Projekt zielt auf allgemeine Spiel- und Compute-Workloads innerhalb der Engine.
|-
| Vulkan Device Groups
| Ähnliche physische GPUs können ein gemeinsames logisches Device bilden.
| Für beliebige heterogene GPUs meist ungeeignet, da Geräte einer Gruppe nahezu gleiche Eigenschaften besitzen müssen. Eine spätere Vulkan-Portierung benötigt daher wahrscheinlich getrennte Devices und External Memory/Semaphores.
|}

SLI und CrossFire bezeichnen den Verbund; AFR und SFR beschreiben mögliche Verteilungsmethoden innerhalb solcher Systeme. Sie sind deshalb nicht vollständig getrennte Kategorien.

== Vorteile der geplanten Variante ==

* '''Herstellerunabhängig:''' NVIDIA, AMD und Intel können grundsätzlich kombiniert werden.
* '''Vorhandene Hardware nutzen:''' Auch eine sonst wenig genutzte integrierte GPU kann geeignete Nebenaufgaben übernehmen.
* '''Aufgaben statt Frames verteilen:''' Spiegel, Minimap oder Compute können mit eigener Auflösung und Aktualisierungsrate laufen.
* '''Keine identischen GPUs erforderlich:''' Unterschiedliche Fähigkeiten können gezielt genutzt werden.
* '''Kontrollierter Datenaustausch:''' Nur das benötigte Ergebnis muss zurück zur Primary-GPU.
* '''Robuste Fallback-Idee:''' Wenn direkte Texturen nicht gemeinsam nutzbar sind, bleibt der Shared-Buffer-Pfad.
* '''Erweiterbar:''' Scheduler, manuelles Mapping und mehrere Worker sind als spätere Stufen vorgesehen.

== Nachteile und technische Risiken ==

* '''Hoher Entwicklungsaufwand:''' Geräte, Ressourcen, Zustände, Fences, Fehlerfälle und UE-Lebenszyklen müssen selbst verwaltet werden.
* '''Transfer kann den Gewinn aufzehren:''' Cross-Adapter Heaps liegen laut D3D12 nicht automatisch im schnellen lokalen VRAM. Bandbreite und Latenz müssen für jeden Workload gemessen werden.
* '''VRAM wird nicht einfach addiert:''' Benötigte Ressourcen können auf mehreren GPUs vorliegen und zusätzlichen Speicher verbrauchen.
* '''Langsame Worker können bremsen:''' Eine Aufgabe lohnt sich nur, wenn Rechengewinn größer als Übergabe-, Warte- und Kopierkosten ist.
* '''Nicht jeder Workload ist unabhängig:''' Hauptansicht, Lumen, Nanite und stark gekoppelte Renderpässe besitzen viele Abhängigkeiten und sind schwieriger auszulagern.
* '''Hardwareunterschiede:''' Formate, Shader-Funktionen, Queue-Fähigkeiten und Cross-Adapter-Support müssen pro GPU geprüft werden.
* '''Wartungsrisiko:''' Eingriffe in private D3D12RHI-Dateien können bei Engine-Updates angepasst werden müssen.
* '''Produktionsreife fehlt noch:''' Ressourcenpools, Timeouts, Device-Lost-Wiederherstellung, Scheduler und echte Szenentests sind offen.

== Wann die Variante sinnvoll ist ==

Am aussichtsreichsten sind Aufgaben mit viel eigener Rechenarbeit, einem relativ kleinen Endergebnis und wenigen Abhängigkeiten zur Hauptszene. Gute frühe Kandidaten sind unabhängige Compute-Aufgaben sowie Scene Captures, die nicht in jedem Frame aktualisiert werden müssen. Weniger geeignet sind winzige Aufgaben mit großem Transfer oder Renderpässe, die ständig auf Ressourcen der Primary-GPU zugreifen.

Die entscheidende Regel für den späteren Scheduler lautet daher:

<pre>
Worker-Gewinn > Vorbereitung + Datentransfer + Synchronisation + Rückintegration
</pre>

== 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.
* Pro Worker existiert absichtlich nur ein persistenter Runtime-Slot. Mehrere parallele In-Flight-Jobs sowie Double-, Triple- oder Ring-Buffering fehlen noch.
* Die Primary-/SafeCopy-/Ready-Kette bleibt trotz zusätzlichem non-blocking <code>DispatchToRHIThread</code> effektiv an den Frame-/Submission-Zyklus gekoppelt.
* 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.
* QueueProbe ist reine Diagnose. Private native Queues sind noch kein Experimental-/Direct-Modus und beschreiben keine UE-eigene sichtbare Textur.
* Es gibt noch keine Umschaltung zwischen Normal und Experimental sowie keinen automatischen Session-Fallback.
* Raw-D3D12-Shared-Ressourcen sind noch nicht vollständig in Unreals Residency-Management eingebunden.
* Praktisch getestet ist Primary plus ein Worker. Die Architektur ist auf mehrere Worker ausgelegt, N-GPU ist aber noch nicht praktisch validiert.
* 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.
* <code>USkeletalMesh</code> ist bislang ein LOD0-ReferencePose-Proof. Bone-Skinning, Animation, Morph Targets und Cloth fehlen noch.
* 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.
* 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.

== Roadmap ==

# Einen echten Nutzlast-Proof als CCTV, Spiegel oder Minimap aufbauen.
# Skeletal Skinning mit Bone-Matrizen und Skin Weights anbinden und Quinn von der Reference Pose zur laufenden Animation bringen.
# Mehrere Mesh-Sections, Material-/Textur-Bindings und anschließend Culling ergänzen.
# D3D12-Adapter-, Raster- und SceneCapture-Pfade auf Intel Arc A750/A380 und später mit RX 6900 XT als Primary gegenprüfen.
# Microbenchmarks und echte Workloads zu einem Autotuner für sinnvolle GPU-Paare und Jobzahlen ausbauen.
# Experimental-/Direct-Architektur mit State-Tracking, Residency, Hazards, Capability-Selftest und automatischem Fallback entwerfen.
# Mehrere Runtime-Slots beziehungsweise einen Ringbuffer erst bei echtem Workload-Bedarf ergänzen.
# Langfristig einen Engine-eigenen Multi-Tier Resource Manager für Primary-VRAM, Worker-VRAM und RAM untersuchen; kein transparenter gemeinsamer Hardware-VRAM.
# Linux/Vulkan mit External Memory und externen Semaphoren/Fences untersuchen.

== Git-Checkpoint ==

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 ==

* 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/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://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://www.intel.com/content/dam/develop/external/us/en/documents/multi-adapter-support-in-directx-12-594015.pdf Intel: Multi-Adapter Support in DirectX 12]
* [https://devblogs.microsoft.com/directx/ashes-of-the-singularity-makes-gaming-history-with-directx-12/ Microsoft: Ashes of the Singularity und heterogene Adapter]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/nvidia-sli-alternative-frame-rendering-in-unreal-engine Epic: NVIDIA SLI Alternate Frame Rendering]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/multi-process-rendering-with-unreal-engine Epic: Multi-Process Rendering]
* [https://registry.khronos.org/vulkan/specs/latest/pdf/vkspec.pdf Khronos: Vulkan Specification – Device Groups]

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Multi-GPU]]
[[Kategorie:Direct3D 12]]
[[Kategorie:Experimentell]]

UE5 Heterogeneous Multi-GPU

2026-09-14T18:24:29Z

Elaina: Quellenstand auf Commit 37c6d02 aktualisiert

{{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.}}

'''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.

{| class="wikitable"
|+ Projektstatus
|-
! Engine / Plattform
| Unreal Engine 5.8 Source Build / Windows / Direct3D 12
|-
! Testsystem
| Lenovo LOQ 17IRX10
|-
! Primary
| NVIDIA GeForce RTX 5060 Laptop GPU
|-
! Worker
| Intel UHD Graphics
|-
! Zusätzliche Testhardware
| Intel Arc A750 und Arc A380 als zusätzliche dGPU-Worker-Gegenchecks vorgesehen; belastbare Messwerte liegen noch nicht vor
|-
! 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
|-
! 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
|-
! Gesamtvision
| etwa 30–35 % (Scheduler, echte Workloads, N-GPU und Vulkan noch offen)
|}

== Grundprinzip ==

<pre>
Intel Worker GPU
-> MainTextureCS + PatternPhase
-> persistente Worker-Textur
-> persistenter Shared Cross-Adapter Buffer
-> monotone Shared Fence / Queue Wait
-> persistente UE-eigene FTextureRHIRef
-> stabile UExperimentalMultiGPUTexture

RTX Primary GPU
-> normales UE5-Rendering
-> TPS-Material zeigt das Worker-Ergebnis sichtbar an
</pre>

Pro Worker ist maximal ein Runtime-Job gleichzeitig in flight. Backpressure lehnt weitere Requests als <code>Busy</code> ab, bis der Slot nach der Primary-Completion wieder sicher verwendbar ist.

Jeder Worker besitzt ein eigenes <code>ID3D12Device</code>, eigene Queues, Command Lists und Ressourcen. Ein späterer Scheduler soll Rechenleistung, Fähigkeiten, Transferkosten und gewünschte Aktualisierungsrate bewerten. Vorgesehene Aufgaben sind beispielsweise SceneCapture2D, Spiegel, CCTV, Minimap, Compute oder Niagara.

== Verifizierter Entwicklungsstand ==

=== Worker-Compute ===

Ein echter, von Unreal kompilierter Global Compute Shader läuft auf der Intel UHD, während Unreal regulär über die RTX rendert. Der Test verdoppelt 64 Ganzzahlen auf dem Worker; '''64 von 64 Ergebnissen wurden korrekt verifiziert'''. Damit ist echte GPU-Arbeit auf einem zweiten, herstellerfremden Device nachgewiesen.

Zusätzlich läuft <code>MainTextureCS</code> auf der Intel-GPU. Der synchrone Debugtest erzeugt eine 64 × 64 Pixel große RGBA8-Textur; '''alle 4096 shader-generierten Pixel wurden korrekt verifiziert'''. Der normale Runtime-Pfad verwendet inzwischen einen asynchronen 128×96-Test. Der Shader liest seine Dimensionen mit <code>GetDimensions()</code>, schützt überhängende Threads durch einen Bounds-Check und wird mit <code>Dispatch(16,12,1)</code> ausgeführt. <code>PatternPhase</code> erzeugt für jeden akzeptierten Submit deterministisch einen neuen sichtbaren Inhalt. Abgewiesene Busy-Requests erhöhen die Phase nicht und erzeugen daher keine Lücken.

=== Cross-Adapter-Speicher und Synchronisation ===

* RTX und Intel öffnen denselben D3D12 Cross-Adapter Heap.
* Ein gemeinsamer Buffer wurde mit 64 Testwerten erfolgreich geprüft.
* Ein persistenter Shared Fence synchronisiert die Queues direkt von GPU zu GPU. Seine Werte steigen pro Job monoton: WorkerReady/PrimaryComplete verwenden die Paare 1/2, 3/4, 5/6 und so weiter.
* Die CPU vermittelt die GPU-Abhängigkeit nicht; Worker- und Primary-Queue verwenden <code>Signal</code> und <code>Wait</code> direkt auf der GPU.
* Der separate Readback-Verifikationstest darf weiterhin blockieren. Der normale Runtime-Pfad wartet dagegen nicht auf GPU-Leerlauf.

=== Texturtransport ===

Direkte Cross-Adapter-Texturen sind auf dem Testsystem nicht beidseitig verfügbar: Die Intel UHD meldet Unterstützung für Row-Major Cross-Adapter Textures, die RTX 5060 Laptop GPU nicht. Deshalb verwendet das Projekt einen allgemeineren Buffer-Fallback.

<pre>
Intel MainTextureCS
-> persistente Worker-Textur
-> CopyTextureRegion
-> persistenter Shared Cross-Adapter Buffer
-> Worker signalisiert WorkerReady (1, 3, 5, ...)
-> UE-Primary-Queue wartet auf WorkerReady
-> direkte Kopie in persistente UE-eigene FTextureRHIRef
-> Primary signalisiert PrimaryComplete (2, 4, 6, ...)
</pre>

Der robuste Normal-Pfad kopiert die Worker-Textur über den Shared Buffer direkt in eine von Unreal erzeugte <code>FTextureRHIRef</code>. Breite, Höhe und Row Pitch werden dynamisch aus Worker-Ressource und Transport-Metadaten übernommen. Der erfolgreiche 128×96-RGBA8-Test verwendet 512 Byte Row Pitch und 49.152 Byte Transfergröße. Die Output Registry trennt Persistent-, Pending- und Ready-Zustände sowie Inhaltsgeneration und Texturidentität. Dadurch kann eine verspätete Completion keinen neueren Output zurückrollen.

=== Non-blocking Runtime-Pfad ===

Die produktive Testlogik ist aus dem Konsolenkommando in eine gekapselte NormalPath-API verschoben. <code>SubmitWorkerTextureComputeJob()</code> reicht den Worker-Dispatch ohne CPU-Wait ein. <code>QueueNormalTextureTransfer()</code> reiht Wait, Kopie und Completion-Signal in Unreals D3D12-Kontext ein. Der normale MainTextureCS-Pfad enthält weder CPU-Fence-Waits noch Readback, <code>Map</code> oder Pixelvergleich. <code>TickNormalTextureTransfers()</code> prüft die Primary-Completion non-blocking über einen Runtime-Pump; <code>RHIEndFrame()</code> bleibt als Fallback erhalten.

Eine passende Primary-<code>FTextureRHIRef</code> wird pro Worker und Konfiguration persistent gehalten. Nach PrimaryComplete kann der nächste Job dieselbe Resource erneut verwenden; dabei führt Unreal die Übergänge <code>SRVMask -> CopyDest -> SRVMask</code> aus. Eine backend-neutrale RHI-Provider-API reicht die Ready-Textur an die Engine weiter. <code>UExperimentalMultiGPUTexture</code> hält eine stabile <code>UTexture</code> samt TextureReference und bindet die persistente <code>FTextureRHIRef</code> ohne zusätzlichen Pixel-Copy. Eine native D3D12-Resource wird weiterhin nicht blind als UE-Textur gewrappt, weil Unreals Resource-State-Buchhaltung den tatsächlichen nativen Zustand sonst nicht sicher kennt.

=== Sichtbarer TPS-Consumer ===

<code>AExperimentalMultiGPUDisplayActor</code> zeigt die Worker-Ausgabe im Third-Person-Testlevel über den Materialparameter <code>MultiGPUTexture</code> an. Damit ist der Output nicht mehr nur über Logs oder Readback nachgewiesen: Die Intel UHD erzeugt fortlaufend die Texturinhalte, während die RTX die Spielwelt und das Material rendert. <code>TextureConsumerCS</code> kann Ready-Ausgaben auf der Primary zusätzlich als SRV lesen und fünf quantisierte Samples im Debugpfad prüfen.

=== Lebensdauer und automatisches Cleanup ===

Der Normal-Pfad verwendet pro Worker genau einen persistenten Runtime-Slot. Worker-Textur, Root Signature, PSO, Descriptor Heap, Command Allocator/List und Worker-Fence werden nach der ersten kompatiblen Initialisierung wiederverwendet. Dasselbe gilt für Shared Heap/Buffer/Fence und die Transport-Command-Objekte. Der In-Flight-Job trägt nur noch die nötigen Job-, Generation- und Fence-Metadaten.

<pre>
Runtime Request
-> Completion non-blocking prüfen
-> falls Slot frei: Worker Dispatch
-> WorkerReady-Fence signalisieren
-> Primary Wait, SafeCopy und PrimaryComplete-Signal
-> Output Pending
-> Runtime-Pump oder RHIEndFrame prüft GetCompletedValue()
-> Output Ready publizieren
-> Slot wiederverwendbar
</pre>

Backpressure erlaubt maximal einen echten In-Flight-Job pro Worker. Ein Busy-Request setzt keine GPU-Arbeit ab, setzt keine Ressourcen zurück und erhöht <code>PatternPhase</code> nicht. Worker-Fence-Werte steigen mit jedem akzeptierten Submit 1, 2, 3 und so weiter; der persistente Shared Fence verwendet fortlaufend die Paare 1/2, 3/4, 5/6. Fehler nach Übergabe von Ressourcen an die GPU führen zu sicherem Retire beziehungsweise Retention statt zu vorzeitigem Reuse.

=== Texture Stream und Benchmarking ===

Der projektseitige Texture Stream akzeptiert eine beliebige positive, endliche Zielrate. Punkt und Komma sind als Dezimaltrenner möglich. Optional lässt sich die Zahl erfolgreicher Submits begrenzen; Busy- oder Failed-Versuche verbrauchen dieses Limit nicht. Der Quiet-Modus unterdrückt per-Job-Ausgaben, behält aber Start, echte Fehler und die Abschlussstatistik bei.

Die Statistik unterscheidet Timer-Ticks, angenommene Submits, Busy/Failed, Ready, In-Flight und die jeweiligen effektiven Raten. Diagnosezeitpunkte erfassen unter anderem RequestAccepted, RenderCommandExecution, WorkerSubmit, NormalTransferQueued und ReadyObserved.

{| class="wikitable"
! Test
! Ergebnis
! Aussage
|-
| 5 Hz, 20 Submits
| etwa 5 Ready/s, 20/20, kein Busy
| Entspannter Single-Slot-Betrieb
|-
| 1000 Hz, 100 Submits, quiet
| 100/100 Ready, 0 Fehler, etwa 58 Ready/s
| Backpressure begrenzt den Durchsatz sicher
|-
| 1000 Hz bei <code>t.MaxFPS 30</code>
| etwa 28–29 Ready/s trotz rund 982 Timer-Ticks/s
| Primary-/SafeCopy-/Ready-Kette ist effektiv framegekoppelt
|}

Ein zusätzlicher non-blocking Aufruf von <code>ImmediateFlush(DispatchToRHIThread)</code> erreicht hohe Render-Command-Raten, hebt die gemessene Frame-Kopplung aber nicht auf. Im 30-FPS-Test lag der RHIEndFrame-spezifische Completion-Takt praktisch exakt bei 30 Hz. Das aktuelle Problem ist damit eingegrenzt: Nicht der Stream-Timer, sondern die Primary-RHI-/D3D12-Submission der SafeCopy-Kette bestimmt die sichtbare Ready-Rate.

=== Queue-Submission-Diagnose ===

<code>MultiGPUD3D12QueueProbe</code> untersucht die Submission unabhängig vom sichtbaren Texturpfad. Neben <code>full</code>, <code>waitonly</code> und <code>signalonly</code> existieren inzwischen die Diagnosemodi <code>computeonly</code>, <code>commandonly</code>, <code>barrieronly</code>, <code>barrierprivate</code> und <code>copybuffer</code>. Als Queues stehen <code>graphics</code>, <code>copy</code>, <code>native</code>, <code>worker</code>, <code>worker-copy</code> und <code>worker-high</code> zur Verfügung. Graphics und Copy verwenden <code>RHIRunOnQueue(..., false)</code> auf UE-verwalteten Primary-Queues; die übrigen Varianten isolieren private beziehungsweise bereits vorhandene native D3D12-Queues.

Der Probe misst Request, Worker-Submit, <code>RHIRunOnQueue</code>-Aufruf und -Callback, Primary-Execute, Fence-Completion sowie Ready bis zum nächsten akzeptierten Submit. Er fügt keine CPU-Waits, Readbacks, Maps oder <code>BlockUntilGPUIdle</code> ein und beschreibt keine Textur des sichtbaren Normal-Pfads.

{| class="wikitable"
! Test
! Ergebnis
! Befund
|-
| UE Graphics, signal-only, 30 FPS
| 33,319 ms PrimaryExecute bis Ready
| UE-verwaltete Graphics-Submission skaliert mit der Frame-Dauer
|-
| UE Copy, signal-only, 30 FPS
| 32,593 ms PrimaryExecute bis Ready
| Auch die UE-verwaltete Copy Queue ist framegekoppelt
|-
| Private Primary-DIRECT-Queue, signal-only
| etwa 0,014 ms Queue/Fence-Latenz; nach Lifecycle-Fix rund 999 Ready/s bei 30 FPS
| Native Queue und Scheduler sind vollständig vom Frame entkoppelt
|-
| Worker signal-only / leere Command List
| jeweils rund 1000 Ready/s bei 30 FPS
| Worker-Queue, Fence und reine Submission sind nicht framegekoppelt
|-
| Worker <code>CopyBufferRegion</code>, 30 / 60 / 120 FPS
| 29,41 / 58,25 / 113,08 Ready/s
| Bereits eine echte 256-Byte-GPU-Kopie folgt im UE-Prozess dem Frame-Raster
|-
| Worker COPY Queue / HIGH Priority, 30 FPS
| jeweils rund 29,42 Ready/s
| Queue-Typ und Priorität beseitigen die Kopplung nicht
|-
| Standalone-D3D12 auf derselben Intel UHD
| 92.956 Copy-Jobs/s; 0,007 ms durchschnittliche Fence-Latenz
| Die Kopplung ist UE-Prozess-/Scheduling-spezifisch, keine allgemeine Intel-, WDDM- oder D3D12-Grenze
|}

Der <code>RHIRunOnQueue</code>-Callback selbst erreicht den D3D12-Submission-Thread typischerweise bereits nach etwa 0,02–0,05 ms; die Verzögerung entsteht danach in der verwalteten Queue-/Submission-Reihenfolge. <code>SubmitCommandsHint()</code> ist in UE 5.8 nur ein veralteter Alias für <code>ImmediateFlush(DispatchToRHIThread)</code> und stellt daher keinen stärkeren Submission-Mechanismus dar.

Der native Test ist ein '''Architekturbeweis, noch kein Experimental- oder Direct-Modus'''. Die zunächst gemessene Verzögerung von rund 32 ms lag zwischen der In-Flight-Freigabe und dem nächsten Request auf dem Render Thread. Für <code>signalonly/native</code> wurde der sichere Completion-/Submit-Lifecycle deshalb in den frameunabhängigen Scheduler verlegt. Danach erreichten zwei 100-Job-Läufe bei <code>t.MaxFPS 30</code> rund 999 bis 1029 Ready/s, ohne Busy oder Fehler.

Der anschließende <code>full native</code>-Test lokalisierte die verbleibende Kopplung auf echte Worker-GPU-Arbeit: WorkerSubmit bis WorkerReady benötigte bei 30, 60 und 120 FPS ungefähr 33,29, 16,93 und 8,45 ms; WorkerReady bis PrimaryReady war danach praktisch sofort. Signal-only und eine leere Command List waren schnell, Resource Barriers und eine 256-Byte-Kopie dagegen framegebunden. Ein eigenständiger D3D12-Microbenchmark auf derselben Intel UHD erreichte außerhalb von Unreal bei derselben Kopie rund 92.956 Jobs/s mit 0,007 ms mittlerer Fence-Latenz. Die genaue Ursache im UE-Prozess beziehungsweise dessen GPU-Scheduling-Kontext bleibt offen und wird vorerst bis zum Gegencheck mit der vorhandenen Intel Arc A380 geparkt.

=== Worker-Rasterpfad und RasterStream ===

<code>ExperimentalMultiGPU.TestRasterWorker</code> weist erstmals echte Rasterizer-Arbeit auf der Intel-Worker-GPU nach. <code>RasterWorkerVS</code> und <code>RasterWorkerPS</code> werden über Unreals Global-Shader-Pfad kompiliert und für ein natives Worker-Graphics-PSO verwendet. Ein persistentes 128×96-RGBA8-RenderTarget besitzt RTV, leere Root Signature und eine DIRECT-Command-List. Der Vertex Shader erzeugt drei Vertices über <code>SV_VertexID</code>; der Pixel Shader schreibt interpolierte RGB-Farben.

Der Job wechselt das RenderTarget von <code>COPY_SOURCE</code> nach <code>RENDER_TARGET</code>, führt Clear und <code>DrawInstanced(3,1,0,0)</code> aus und wechselt anschließend zurück nach <code>COPY_SOURCE</code>. Danach verwendet er unverändert den robusten Normalpfad aus Cross-Adapter-Shared-Buffer, Primary SafeCopy, persistenter <code>FTextureRHIRef</code>, <code>UExperimentalMultiGPUTexture</code> und DisplayActor. Der Runtime-Test meldete einen akzeptierten Submit und <code>RasterWorker READY</code> für Generation 1; die 128×96-UTexture wurde erfolgreich gebunden.

Der einmalige Test wurde außerdem zu einem frei konfigurierbaren RasterStream ausgebaut. Ein sichtbarer Lauf mit 10 Hz und 50 erfolgreichen Submits endete mit 50 Ready-Ausgaben, 0 Busy und 0 Fehlern bei etwa 9,90 Ready/s. Primary-Textur und Materialbindung blieben dabei persistent.

=== Raster3D mit echten Vertex- und Indexbuffern ===

Der Worker besitzt inzwischen einen kleinen eigenständigen 3D-Rasterpfad mit perspektivischer Kamera, Model-View-Projection-Matrix als Root Constants, D32_FLOAT-Depth-Buffer und Depth-Test. Der finale Testwürfel verwendet 24 POSITION/COLOR-Vertices, 36 <code>uint16</code>-Indices und <code>DrawIndexedInstanced(36,1,0,0,0)</code>; sechs getrennte Seitenfarben machen Ausrichtung und Rotation sichtbar nachvollziehbar.

Die statischen Meshdaten werden einmalig über private Upload-Buffer in DEFAULT-Heaps übertragen. Der Init-Fence wird non-blocking über <code>GetCompletedValue()</code> beobachtet. Der eigentliche Runtime-Renderpfad enthält weiterhin keine CPU-Waits und keine Maps.

=== UE-Static-Meshes auf der Worker-GPU ===

<code>StaticMeshWorker</code> extrahiert echte LOD0-Geometrie aus <code>UStaticMesh</code>-Assets. POSITION und NORMAL sowie <code>uint32</code>-Indices werden in POD-Daten überführt, einmalig asynchron in eigene Worker-VB/IB hochgeladen und anschließend per <code>DrawIndexedInstanced</code> gerendert. Assetpfade sind dynamisch; Auto-Fit richtet Kamera beziehungsweise Modellmaßstab an den Bounds aus.

Sichtbar korrekt getestet wurden:

{| class="wikitable"
! Asset
! Vertices
! Indices
|-
| Sphere
| 559
| 2880
|-
| Cube
| 54
| 144
|-
| Cylinder
| 334
| 1536
|}

=== Multi-Mesh Worker-Szene ===

<code>StaticMeshScene</code> rendert Sphere, Cube und Cylinder gemeinsam in einen Color-/Depth-Frame. Der verifizierte Test umfasst insgesamt 947 Vertices und 4560 Indices, drei <code>DrawIndexedInstanced</code>-Aufrufe und nur einen anschließenden Cross-Adapter-/Normal-SafeCopy-Transfer. Damit ist nicht mehr nur ein synthetisches Primitive, sondern mehrere echte UE-Meshes mit gemeinsamer Tiefenprüfung im Worker-Frame sichtbar nachgewiesen.

=== WorldStaticMeshScene ===

<code>ExperimentalMultiGPUWorldStaticMeshScene.cpp</code> sammelt im Engine-Layer bis zu acht sichtbare <code>UStaticMeshComponent</code>s von Actors mit dem Tag <code>MultiGPUWorker</code>. Meshdaten und World-Transforms werden im Game Thread in reine POD-Strukturen und 4×4-Matrizen kopiert. D3D12RHI erhält keine <code>UObject</code>-Pointer. Mehrere Instanzen desselben Meshes teilen den persistenten Worker-Mesh-Cache und unterscheiden sich nur durch Modelmatrix und Draw Call.

Der Pfad wurde inzwischen sichtbar im PIE-Level verifiziert. Drei getaggte Static-Mesh-Actors erschienen mit ihren tatsächlichen relativen Positionen, Rotationen und Skalierungen im Worker-Bild. Die zentrale Koordinatenumrechnung lautet:

<pre>Worker (X, Y, Z) = (UE Y, UE X, -UE Z)</pre>

Die Transformation besitzt die Determinante +1 und ist damit keine Spiegelung. Das notwendige horizontale Spiegeln erfolgt ausschließlich auf der Presentation-Plane, nicht im Worker-Renderpfad.

=== Kontinuierlicher WorldStaticMeshSceneStream ===

<code>StartWorldStaticMeshSceneStream</code> erfasst die getaggte Szene fortlaufend im Game Thread. Reine Änderungen an Transform oder Kamera lösen keinen erneuten Mesh-Upload aus. Hinzugekommene, entfernte, unsichtbare oder umgetaggte Components werden im nächsten Snapshot berücksichtigt. Single-Slot-Backpressure verhindert einen wachsenden Rückstau.

Ein verifizierter 30-Hz-Lauf endete nach 31,184 Sekunden mit 835 Ticks, 691 angenommenen Submits, 144 Busy, 0 Fehlern und 691 Ready-Frames. Die effektive Ready-Rate betrug 22,16 Hz. Dieser Test belegt die funktionale Live-Aktualisierung; die Rate war noch kein Optimierungsziel.

=== SceneCapture2D als Worker-Kamera ===

<code>TestSceneCaptureStaticMeshScene</code> verwendet eine echte <code>ASceneCapture2D</code> beziehungsweise <code>USceneCaptureComponent2D</code> aus der laufenden PIE-Welt als Kameraquelle. Der empfohlene Editor-Weg ist das Component Tag <code>MultiGPUWorkerCamera</code> auf der <code>CaptureComponent2D</code>; ein gleichnamiges Actor-Tag bleibt nur als Legacy-Fallback.

Ausgelesen werden World Location, Rotation, Forward/Right/Up, <code>FOVAngle</code> und <code>ProjectionType</code>. Orthografische Projektion wird derzeit sauber abgelehnt. Die SceneCapture2D liefert ausschließlich Kameradaten: Ihr UE-RenderTarget wird weder gelesen noch kopiert. Die Intel-Worker-GPU rendert die Geometrie selbst. Kamera und Actors werden gemeinsam mit <code>SceneScale = 0.01</code> in Worker-Koordinaten überführt; Auto-Fit und Scene-Recentering sind in diesem Modus deaktiviert.

Die 128×96-Worker-Projektion verwendet ein Seitenverhältnis von 4:3 und interpretiert <code>FOVAngle</code> als horizontales FOV. Nach den Orientierungstests wird nur die Anzeige über <code>SetRelativeScale3D(FVector(-4.0f, -3.0f, 1.0f))</code> korrigiert; dies entspricht <code>U' = 1-U</code> und <code>V' = 1-V</code>.

=== Live SceneCaptureStaticMeshSceneStream ===

<code>StartSceneCaptureStaticMeshSceneStream</code> liest Kamera-Transform, Kamerabasis, FOV und aktuelle Actor-Transforms pro Snapshot neu im Game Thread. Der Worker erhält weiterhin ausschließlich POD-Daten, verwendet den persistenten Mesh-Cache sowie ein gemeinsames Color- und D32-Depth-Target und führt pro akzeptiertem Frame genau einen Cross-Adapter-/Normal-SafeCopy-Transfer aus.

Der Quiet-Test

<pre>ExperimentalMultiGPU.StartSceneCaptureStaticMeshSceneStream 30 300 quiet</pre>

lieferte in 10,084 Sekunden 301 Ticks, 300 Submits, 1 Busy, 0 Fehler und 300 Ready-Frames. Die effektive Ready-Rate betrug 29,75 Hz. Bewegungen der Kamera und Actors sowie FOV-Änderungen erschienen live auf der Display-Plane. Damit ist erstmals ein kleiner SceneCapture-/CCTV-artiger Worker-Kanal vollständig funktional nachgewiesen.

=== Dynamische SceneCapture-Auflösung ===

Die SceneCapture-Ausgabe ist nicht mehr fest auf 128×96 Pixel begrenzt. <code>ExperimentalMultiGPU.SetSceneCaptureResolution <Width> <Height></code> setzt ganzzahlige Dimensionen von 1 bis 4096; <code>GetSceneCaptureResolution</code> zeigt die aktive Einstellung. 128×96 bleibt der Standard. Während ein SceneCapture-Stream läuft, wird ein Auflösungswechsel absichtlich abgelehnt, damit keine In-Flight-Ressourcen ausgetauscht werden.

Color Target, D32-Depth-Buffer, Row Pitch, Shared-Buffer-Transport, SafeCopy, persistente Primary-Textur und <code>UExperimentalMultiGPUTexture</code> übernehmen die gewählten Dimensionen. Projektion und Display-Plane verwenden das echte Seitenverhältnis. Die bestätigte Anzeigeorientierung <code>U' = 1-U</code> und <code>V' = 1-V</code> bleibt eine reine Presentation-Korrektur; Worker-Basis und Kameramathematik ändern sich nicht.

=== Scheduler-Korrektur bei SceneCapture ===

Ein 1920×1080-Test mit 25 Hz erreichte zunächst trotz fehlerfreier Frames nur 13,90 Ready-Hz und erzeugte 222 Busy-Ticks. Ursache war kein GPU-Limit, sondern ein Polling-Aliasing: Eine frühe Game-Thread-Prüfung konnte den Timer-Slot verwerfen, obwohl die Completion kurz darauf im CoreTicker/RHI-Pump sichtbar geworden wäre.

Die frühe <code>IsRuntimeTextureUpdateInFlight()</code>-Prüfung wurde für diesen Stream entfernt. Der Pending-Request bleibt als Backpressure-Gate erhalten; die maßgebliche Busy-Entscheidung fällt nun erst im Render Command nach <code>TickNormalTextureTransfers(nullptr, true)</code>. Single-Slot, POD-Snapshots und non-blocking <code>GetCompletedValue()</code> bleiben erhalten. Es wurden weder CPU-Waits noch zusätzliche Threads eingeführt.

Nach der Korrektur erreicht 1080p bei 25 Hz 24,79 Ready-Hz mit 1 Busy; bei 30 Hz sind es 29,43 Ready-Hz mit 4 Busy.

=== Skalierung bis 4K60 ===

Die Pipeline wurde von 640×360 bis 3840×2160 getestet. Bei 640×360/30 Hz und 1280×720/30 Hz wurden 29,85 beziehungsweise 29,82 Ready-Hz ohne Busy erreicht. 1920×1080/60 Hz lieferte 59,40 Ready-Hz ohne Busy, 2560×1440/60 Hz 59,21 Ready-Hz mit 1 Busy und 3840×2160/60 Hz 59,02 Ready-Hz mit 2 Busy.

Ein zusätzlicher 4K60-Stresstest mit acht Static-Mesh-Instanzen und drei gecachten Unique Meshes erreichte in 5,049 Sekunden '''300 von 300 Ready-Frames, 0 Busy, 0 Fehler und 59,42 effektive Ready-Hz'''. Acht Draw Calls, gemeinsamer Depth Buffer, Cross-Adapter-Transport und SafeCopy liefen dabei im vorhandenen Single-Slot. Das ist ein Stabilitätsnachweis der aktuellen Mini-Szene, kein allgemeiner GPU-Benchmark.

=== Skeletal Mesh in Reference Pose ===

<code>ExperimentalMultiGPU.TestSkeletalMeshWorker</code> erweitert den Geometriepfad auf <code>USkeletalMeshComponent</code>. Der Engine-Layer sucht deterministisch die erste sichtbare, getaggte Komponente und extrahiert LOD0-Positionen, Normalen, Indices und Render Sections. D3D12RHI erhält wie bisher ausschließlich POD-Geometrie und Modelmatrizen.

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.

== Test- und Diagnosebefehle ==

{| class="wikitable"
! Befehl
! Zweck
|-
| <code>ExperimentalMultiGPU.TestComputeShader</code>
| Führt den vollständigen Worker-Compute-Testpfad aus. Er enthält auch ältere Debug- und Regressionstests mit CPU-Readback und ist daher nicht mit dem reinen asynchronen Runtime-Pfad gleichzusetzen.
|-
| <code>ExperimentalMultiGPU.TestTextureConsumer</code>
| Testet <code>TextureConsumerCS</code> auf der Primary-GPU. Die aktuelle Ready-Textur wird über UE-RHI gelesen und anhand ausgewählter Testpixel per Debug-Readback geprüft.
|-
| <code>ExperimentalMultiGPU.TestTextureBridge</code>
| Prüft die Bridge von der fertigen <code>FTextureRHIRef</code> zu <code>UExperimentalMultiGPUTexture</code> und damit den UE- und materialtauglichen Texturpfad.
|-
| <code>ExperimentalMultiGPU.SpawnDisplayActor</code>
| Spawnt den Test-Actor mit Plane im Spiel. Das Material zeigt darauf die vom Worker erzeugte Textur an.
|-
| <code>ExperimentalMultiGPU.TestRasterWorker</code>
| Rasterisiert auf der Worker-GPU ein echtes RGB-Dreieck per Vertex- und Pixel-Shader und transportiert das Ergebnis über den normalen SafeCopy-Pfad bis zum DisplayActor.
|-
| <code>ExperimentalMultiGPU.StartRasterStream</code> / <code>ExperimentalMultiGPU.StopRasterStream</code>
| Startet beziehungsweise stoppt den kontinuierlichen RGB-Dreieck-RasterStream mit frei wählbarer Zielrate, optionalem Submit-Limit und Quiet-Modus.
|-
| <code>ExperimentalMultiGPU.TestRaster3DWorker</code>
| Rendert einmalig den perspektivischen 3D-Testwürfel mit Depth Buffer und echten Vertex-/Indexbuffern.
|-
| <code>ExperimentalMultiGPU.StartRaster3DStream</code> / <code>ExperimentalMultiGPU.StopRaster3DStream</code>
| Startet beziehungsweise stoppt den kontinuierlichen Raster3D-Test.
|-
| <code>ExperimentalMultiGPU.TestStaticMeshWorker [AssetPath]</code>
| Extrahiert und rendert LOD0-Geometrie eines UE-Static-Mesh-Assets; ohne optionalen Pfad wird das konfigurierte Testasset verwendet.
|-
| <code>ExperimentalMultiGPU.TestStaticMeshScene</code>
| Rendert Sphere, Cube und Cylinder gemeinsam mit drei Draw Calls und einem anschließenden Transfer.
|-
| <code>ExperimentalMultiGPU.TestWorldStaticMeshScene</code>
| Rendert einen einmaligen POD-Snapshot der sichtbaren, mit <code>MultiGPUWorker</code> getaggten StaticMeshComponents aus der laufenden World. Der sichtbare PIE-Nachweis ist erfolgreich.
|-
| <code>ExperimentalMultiGPU.StartWorldStaticMeshSceneStream [Hz] [MaxSuccessfulSubmits] [quiet]</code> / <code>StopWorldStaticMeshSceneStream</code>
| Startet beziehungsweise stoppt den kontinuierlichen Stream der getaggten UE-Welt mit Live-Transforms und persistentem Mesh-Cache.
|-
| <code>ExperimentalMultiGPU.SetSceneCaptureResolution <Width> <Height></code> / <code>GetSceneCaptureResolution</code>
| Setzt beziehungsweise zeigt die gemeinsame SceneCapture-Auflösung. Erlaubt sind ganzzahlige Werte von 1 bis 4096 je Achse; Änderungen während eines laufenden Streams werden abgelehnt.
|-
| <code>ExperimentalMultiGPU.TestSceneCaptureStaticMeshScene</code>
| Rendert einen einmaligen Worker-Snapshot aus Sicht der mit <code>MultiGPUWorkerCamera</code> markierten SceneCapture2D-Kamera.
|-
| <code>ExperimentalMultiGPU.StartSceneCaptureStaticMeshSceneStream [Hz] [MaxSuccessfulSubmits] [quiet]</code> / <code>StopSceneCaptureStaticMeshSceneStream</code>
| Startet beziehungsweise stoppt den Live-Worker-Kanal mit fortlaufend aktualisierten Kamera-, FOV- und Actor-Daten.
|-
| <code>ExperimentalMultiGPU.TestSkeletalMeshWorker</code>
| Rendert das erste sichtbare, getaggte Skeletal Mesh in LOD0 und Reference Pose sectionsweise auf der Worker-GPU.
|-
| <code>ExperimentalMultiGPU.StartTextureStream</code>
| Startet den sichtbaren Normal-Pfad: Worker-Textur → Cross-Adapter-Transfer → SafeCopy → UE-Textur → Material.
|-
| <code>ExperimentalMultiGPU.StopTextureStream</code>
| Verhindert weitere Submits des laufenden Streams. Ein bereits eingereichter GPU-Job darf noch sicher fertig werden.
|-
| <code>ExperimentalMultiGPU.StartQueueProbe</code>
| Startet den Diagnose-Benchmark für Primary-Queue-, Fence- und Submission-Verhalten. Der Probe verändert die sichtbare Textur nicht.
|}

=== Texture Stream ===

Grundsyntax:

<pre>
ExperimentalMultiGPU.StartTextureStream [Hz] [MaxSuccessfulSubmits] [quiet]
</pre>

{| class="wikitable"
! Beispiel
! Wirkung
|-
| <code>ExperimentalMultiGPU.StartTextureStream</code>
| Standardmäßig etwa 5 Hz, ohne Submit-Limit.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 37.5</code>
| Fordert 37,5 Hz ohne Submit-Limit an. Sowohl <code>37.5</code> als auch <code>37,5</code> werden akzeptiert.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 1000 100</code>
| Fordert 1000 Hz an und stoppt nach exakt 100 erfolgreichen Submits.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 1000 100 quiet</code>
| Wie zuvor, unterdrückt aber Per-Job- und Busy-Logspam.
|}

Die Hz-Angabe ist eine '''Ziel- beziehungsweise Request-Frequenz'''. <code>1000</code> bedeutet daher nicht automatisch 1000 fertige Texturen pro Sekunde. Die tatsächliche Rate hängt unter anderem von Timer, Submission, Backpressure, Queue-Latenz und Slot-Lifecycle ab. <code>MaxSuccessfulSubmits</code> zählt nur angenommene Submits; Busy- und Failed-Versuche verbrauchen das Limit nicht.

=== QueueProbe ===

Grundsyntax:

<pre>
ExperimentalMultiGPU.StartQueueProbe <Hz> <MaxSubmits> [quiet] [Mode] [Queue]
</pre>

{| class="wikitable"
! Modus
! Ausgeführter Pfad
|-
| <code>full</code>
| Worker Compute → Cross-Adapter-Transfer → Primary Wait → Copy → Completion Fence.
|-
| <code>waitonly</code>
| Worker Compute → Cross-Adapter-Transfer → Primary wartet auf WorkerReadyFence → Completion Fence. Es findet keine Texturkopie statt.
|-
| <code>signalonly</code>
| Keine Textur, kein Worker-Wait und keine Kopie; nur Queue und Fence. Dieser Modus isoliert das Queue-Verhalten.
|-
| <code>commandonly</code>
| Reicht eine leere echte Worker-Command-List ein und trennt Command-Submission von GPU-Arbeit.
|-
| <code>barrieronly</code> / <code>barrierprivate</code>
| Isoliert Resource-Barriers auf Worker-Ressourcen beziehungsweise einer privaten Testtextur.
|-
| <code>copybuffer</code>
| Führt eine minimale echte <code>CopyBufferRegion</code>-Operation über 256 Byte aus.
|}

{| class="wikitable"
! Queue
! Bedeutung
|-
| <code>graphics</code>
| Vorhandene UE Primary Graphics-/Direct-Queue über <code>RHIRunOnQueue</code>.
|-
| <code>copy</code>
| Vorhandene UE Primary Copy Queue über <code>RHIRunOnQueue</code>.
|-
| <code>native</code>
| Vollständig private native D3D12-DIRECT-Queue auf der Primary; reine Diagnose, kein fertiger Experimental-Modus.
|-
| <code>worker</code>
| Vorhandene native Worker-DIRECT-Queue.
|-
| <code>worker-copy</code>
| Separate native Worker-COPY-Queue.
|-
| <code>worker-high</code>
| Separate Worker-DIRECT-Queue mit hoher Priorität.
|}

Typische Beispiele:

<pre>
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet full graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet waitonly graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly copy
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly native
</pre>

Der letzte Befehl ist aktuell die wichtigste isolierte Gegenprobe. Mit der privaten nativen Queue wurde bei 30 FPS eine durchschnittliche Latenz <code>primaryExecuteToReadyAvgMs = 0.014 ms</code> gemessen.

=== Benchmark-CVars ===

{| class="wikitable"
! CVar
! Zweck
|-
| <code>r.VSync 0</code>
| Deaktiviert VSync, damit es die Messung nicht begrenzt.
|-
| <code>t.MaxFPS 30</code> <code>t.MaxFPS 60</code> <code>t.MaxFPS 120</code>
| Setzt die Engine-Framerate für reproduzierbare Frame-Coupling-Tests.
|-
| <code>t.MaxFPS 0</code>
| Entfernt das normale <code>t.MaxFPS</code>-Limit. Dieser Lauf ist als zusätzliche Diagnose-Gegenprobe vorgesehen.
|}

== 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.

== Historische Vorläufer ==

Die Grundidee heterogener Multi-GPU-Nutzung ist nicht neu. Bereits mit der Einführung von Direct3D 12 entstanden mehrere Versuche, integrierte und dedizierte GPUs gemeinsam zu verwenden. Eine allgemein einsetzbare Lösung für moderne UE5-Spiele hat sich daraus jedoch nicht entwickelt.

=== Microsoft und Epic: UE4 Elemental Demo (2015) ===

Microsoft zeigte eine angepasste Unreal-Engine-4-Version der Elemental-Demo, bei der eine NVIDIA-GPU und eine Intel-iGPU gemeinsam arbeiteten. Das erklärte Ziel war, ansonsten ungenutzte Grafikleistung in Hybrid-Systemen zu verwenden. Dieser Versuch ist der Grundidee des Projekts besonders ähnlich, blieb aber eine technische Demonstration.

=== Intel: D3D12 Multi-Adapter Sample (2015) ===

Intels Beispiel kombinierte eine GeForce 840M mit Intel HD Graphics 5500. Beide GPUs berechneten getrennte Teile einer einfach parallelisierbaren Raytracing-Szene. Cross-Adapter-Ressourcen und Shared Fences führten die Ergebnisse anschließend zusammen. Intel berichtete in diesem Test von nahezu halbierter Framezeit, warnte jedoch ausdrücklich davor, das Ergebnis unmittelbar auf reale Spiele zu übertragen.

=== Ashes of the Singularity ===

Die Nitrous Engine von ''Ashes of the Singularity'' setzte Direct3D-12-Explicit-Multiadapter in einem veröffentlichten Spiel ein. Dabei konnten auch unterschiedliche GPU-Modelle und Hersteller zusammenarbeiten. Das war ein wichtiger Praxisnachweis, blieb in der Spielebranche aber eine seltene Ausnahme.

=== Weitere verwandte Ansätze ===

* ''Rise of the Tomb Raider'' erhielt explizite Direct3D-12-Multi-GPU-Unterstützung, vor allem für klassische Kombinationen ähnlicher GPUs.
* NVIDIA VR SLI wies bei Virtual Reality jeder GPU ein Auge zu. Das verteilt unabhängige Ansichten, bleibt jedoch NVIDIA-spezifisch.
* Unreal nDisplay kann Viewports oder Frustums auf weitere GPUs beziehungsweise Prozesse auslagern und das fertige Bild zur Ausgabe-GPU zurückführen. Der Einsatzbereich ist hauptsächlich Virtual Production.
* Forschung und High-Performance Computing verwenden seit Jahren Scheduler für heterogene GPUs, allerdings überwiegend für Compute- und Datenverarbeitungsaufgaben statt für einen allgemeinen UE5-Echtzeitrenderer.

=== Abgrenzung dieses Projekts ===

Das Projekt erfindet Direct3D-12-Explicit-Multiadapter nicht neu. Sein eigener Ansatz liegt in der Kombination aus tiefer UE5.8-RHI-Integration, UE-kompilierten Shadern auf unabhängigen Worker-Devices, frei wählbaren Spiel- und Compute-Workloads, Capability- und Performance-Scheduler, mehreren Fallback-Pfaden sowie dem langfristigen Ziel beliebiger Hersteller und mehrerer Worker.

== Vergleich mit anderen Multi-GPU-Verfahren ==

{| class="wikitable"
! Verfahren
! Arbeitsweise
! Verhältnis zu diesem Projekt
|-
| SLI / CrossFire
| Treiber- beziehungsweise Verbundlösung für meist ähnliche GPUs; häufig wird die Bildarbeit verteilt.
| Dieses Projekt benötigt keinen herstellerspezifischen GPU-Verbund und weist Aufgaben ausdrücklich selbst zu.
|-
| AFR (Alternate Frame Rendering)
| GPU 1 rendert einen Frame, GPU 2 den nächsten.
| Das Projekt verteilt unabhängige Aufgaben statt aufeinanderfolgender Frames. Dadurch werden Frame-Abhängigkeiten und typisches AFR-Pacing vermieden.
|-
| SFR (Split Frame Rendering)
| Mehrere GPUs bearbeiten Bereiche desselben Frames.
| Erfordert enge Lastverteilung und viel Datenaustausch. Das Projekt bevorzugt vollständig abgrenzbare Workloads und überträgt deren Ergebnis.
|-
| Direct3D 12 Linked Multiadapter
| Mehrere vom Treiber verbundene GPUs erscheinen als Knoten eines logischen Adapters.
| Eignet sich eher für eng kompatible GPUs. Das Projekt verwendet unabhängige Devices (Unlinked/Explicit Multiadapter) und unterstützt dadurch heterogene Herstellerkombinationen.
|-
| Direct3D 12 Unlinked / Explicit Multiadapter
| Die Anwendung verwaltet getrennte Adapter, Ressourcen und Synchronisation selbst.
| Das ist die technische Familie des Projekts. Hinzu kommen die eigene UE5-RHI-Integration, Workload-Ziele, Fallbacks und der geplante Scheduler.
|-
| UE nDisplay mGPU / Multi-Process
| Separate GPUs rendern bestimmte Viewports oder Frustums, vor allem für Virtual Production; Ergebnisse werden zur Ausgabe-GPU kopiert.
| Ähnliche Idee der aufgabenweisen Trennung, aber für einen anderen Einsatzbereich. Dieses Projekt zielt auf allgemeine Spiel- und Compute-Workloads innerhalb der Engine.
|-
| Vulkan Device Groups
| Ähnliche physische GPUs können ein gemeinsames logisches Device bilden.
| Für beliebige heterogene GPUs meist ungeeignet, da Geräte einer Gruppe nahezu gleiche Eigenschaften besitzen müssen. Eine spätere Vulkan-Portierung benötigt daher wahrscheinlich getrennte Devices und External Memory/Semaphores.
|}

SLI und CrossFire bezeichnen den Verbund; AFR und SFR beschreiben mögliche Verteilungsmethoden innerhalb solcher Systeme. Sie sind deshalb nicht vollständig getrennte Kategorien.

== Vorteile der geplanten Variante ==

* '''Herstellerunabhängig:''' NVIDIA, AMD und Intel können grundsätzlich kombiniert werden.
* '''Vorhandene Hardware nutzen:''' Auch eine sonst wenig genutzte integrierte GPU kann geeignete Nebenaufgaben übernehmen.
* '''Aufgaben statt Frames verteilen:''' Spiegel, Minimap oder Compute können mit eigener Auflösung und Aktualisierungsrate laufen.
* '''Keine identischen GPUs erforderlich:''' Unterschiedliche Fähigkeiten können gezielt genutzt werden.
* '''Kontrollierter Datenaustausch:''' Nur das benötigte Ergebnis muss zurück zur Primary-GPU.
* '''Robuste Fallback-Idee:''' Wenn direkte Texturen nicht gemeinsam nutzbar sind, bleibt der Shared-Buffer-Pfad.
* '''Erweiterbar:''' Scheduler, manuelles Mapping und mehrere Worker sind als spätere Stufen vorgesehen.

== Nachteile und technische Risiken ==

* '''Hoher Entwicklungsaufwand:''' Geräte, Ressourcen, Zustände, Fences, Fehlerfälle und UE-Lebenszyklen müssen selbst verwaltet werden.
* '''Transfer kann den Gewinn aufzehren:''' Cross-Adapter Heaps liegen laut D3D12 nicht automatisch im schnellen lokalen VRAM. Bandbreite und Latenz müssen für jeden Workload gemessen werden.
* '''VRAM wird nicht einfach addiert:''' Benötigte Ressourcen können auf mehreren GPUs vorliegen und zusätzlichen Speicher verbrauchen.
* '''Langsame Worker können bremsen:''' Eine Aufgabe lohnt sich nur, wenn Rechengewinn größer als Übergabe-, Warte- und Kopierkosten ist.
* '''Nicht jeder Workload ist unabhängig:''' Hauptansicht, Lumen, Nanite und stark gekoppelte Renderpässe besitzen viele Abhängigkeiten und sind schwieriger auszulagern.
* '''Hardwareunterschiede:''' Formate, Shader-Funktionen, Queue-Fähigkeiten und Cross-Adapter-Support müssen pro GPU geprüft werden.
* '''Wartungsrisiko:''' Eingriffe in private D3D12RHI-Dateien können bei Engine-Updates angepasst werden müssen.
* '''Produktionsreife fehlt noch:''' Ressourcenpools, Timeouts, Device-Lost-Wiederherstellung, Scheduler und echte Szenentests sind offen.

== Wann die Variante sinnvoll ist ==

Am aussichtsreichsten sind Aufgaben mit viel eigener Rechenarbeit, einem relativ kleinen Endergebnis und wenigen Abhängigkeiten zur Hauptszene. Gute frühe Kandidaten sind unabhängige Compute-Aufgaben sowie Scene Captures, die nicht in jedem Frame aktualisiert werden müssen. Weniger geeignet sind winzige Aufgaben mit großem Transfer oder Renderpässe, die ständig auf Ressourcen der Primary-GPU zugreifen.

Die entscheidende Regel für den späteren Scheduler lautet daher:

<pre>
Worker-Gewinn > Vorbereitung + Datentransfer + Synchronisation + Rückintegration
</pre>

== 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.
* Pro Worker existiert absichtlich nur ein persistenter Runtime-Slot. Mehrere parallele In-Flight-Jobs sowie Double-, Triple- oder Ring-Buffering fehlen noch.
* Die Primary-/SafeCopy-/Ready-Kette bleibt trotz zusätzlichem non-blocking <code>DispatchToRHIThread</code> effektiv an den Frame-/Submission-Zyklus gekoppelt.
* 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.
* QueueProbe ist reine Diagnose. Private native Queues sind noch kein Experimental-/Direct-Modus und beschreiben keine UE-eigene sichtbare Textur.
* Es gibt noch keine Umschaltung zwischen Normal und Experimental sowie keinen automatischen Session-Fallback.
* Raw-D3D12-Shared-Ressourcen sind noch nicht vollständig in Unreals Residency-Management eingebunden.
* Praktisch getestet ist Primary plus ein Worker. Die Architektur ist auf mehrere Worker ausgelegt, N-GPU ist aber noch nicht praktisch validiert.
* 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.
* <code>USkeletalMesh</code> ist bislang ein LOD0-ReferencePose-Proof. Bone-Skinning, Animation, Morph Targets und Cloth fehlen noch.
* 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.
* 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.

== Roadmap ==

# Einen echten Nutzlast-Proof als CCTV, Spiegel oder Minimap aufbauen.
# Skeletal Skinning mit Bone-Matrizen und Skin Weights anbinden und Quinn von der Reference Pose zur laufenden Animation bringen.
# Mehrere Mesh-Sections, Material-/Textur-Bindings und anschließend Culling ergänzen.
# D3D12-Adapter-, Raster- und SceneCapture-Pfade auf Intel Arc A750/A380 und später mit RX 6900 XT als Primary gegenprüfen.
# Microbenchmarks und echte Workloads zu einem Autotuner für sinnvolle GPU-Paare und Jobzahlen ausbauen.
# Experimental-/Direct-Architektur mit State-Tracking, Residency, Hazards, Capability-Selftest und automatischem Fallback entwerfen.
# Mehrere Runtime-Slots beziehungsweise einen Ringbuffer erst bei echtem Workload-Bedarf ergänzen.
# Langfristig einen Engine-eigenen Multi-Tier Resource Manager für Primary-VRAM, Worker-VRAM und RAM untersuchen; kein transparenter gemeinsamer Hardware-VRAM.
# Linux/Vulkan mit External Memory und externen Semaphoren/Fences untersuchen.

== 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.

== Quellen ==

* 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/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://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://www.intel.com/content/dam/develop/external/us/en/documents/multi-adapter-support-in-directx-12-594015.pdf Intel: Multi-Adapter Support in DirectX 12]
* [https://devblogs.microsoft.com/directx/ashes-of-the-singularity-makes-gaming-history-with-directx-12/ Microsoft: Ashes of the Singularity und heterogene Adapter]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/nvidia-sli-alternative-frame-rendering-in-unreal-engine Epic: NVIDIA SLI Alternate Frame Rendering]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/multi-process-rendering-with-unreal-engine Epic: Multi-Process Rendering]
* [https://registry.khronos.org/vulkan/specs/latest/pdf/vkspec.pdf Khronos: Vulkan Specification – Device Groups]

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Multi-GPU]]
[[Kategorie:Direct3D 12]]
[[Kategorie:Experimentell]]

UE5 Heterogeneous Multi-GPU

2026-09-12T19:38:40Z

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

{{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.}}

'''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.

{| class="wikitable"
|+ Projektstatus
|-
! Engine / Plattform
| Unreal Engine 5.8 Source Build / Windows / Direct3D 12
|-
! Testsystem
| Lenovo LOQ 17IRX10
|-
! Primary
| NVIDIA GeForce RTX 5060 Laptop GPU
|-
! Worker
| Intel UHD Graphics
|-
! Zusätzliche Testhardware
| Intel Arc A750 und Arc A380 als zusätzliche dGPU-Worker-Gegenchecks vorgesehen; belastbare Messwerte liegen noch nicht vor
|-
! 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
|-
! 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
|-
! Gesamtvision
| etwa 30–35 % (Scheduler, echte Workloads, N-GPU und Vulkan noch offen)
|}

== Grundprinzip ==

<pre>
Intel Worker GPU
-> MainTextureCS + PatternPhase
-> persistente Worker-Textur
-> persistenter Shared Cross-Adapter Buffer
-> monotone Shared Fence / Queue Wait
-> persistente UE-eigene FTextureRHIRef
-> stabile UExperimentalMultiGPUTexture

RTX Primary GPU
-> normales UE5-Rendering
-> TPS-Material zeigt das Worker-Ergebnis sichtbar an
</pre>

Pro Worker ist maximal ein Runtime-Job gleichzeitig in flight. Backpressure lehnt weitere Requests als <code>Busy</code> ab, bis der Slot nach der Primary-Completion wieder sicher verwendbar ist.

Jeder Worker besitzt ein eigenes <code>ID3D12Device</code>, eigene Queues, Command Lists und Ressourcen. Ein späterer Scheduler soll Rechenleistung, Fähigkeiten, Transferkosten und gewünschte Aktualisierungsrate bewerten. Vorgesehene Aufgaben sind beispielsweise SceneCapture2D, Spiegel, CCTV, Minimap, Compute oder Niagara.

== Verifizierter Entwicklungsstand ==

=== Worker-Compute ===

Ein echter, von Unreal kompilierter Global Compute Shader läuft auf der Intel UHD, während Unreal regulär über die RTX rendert. Der Test verdoppelt 64 Ganzzahlen auf dem Worker; '''64 von 64 Ergebnissen wurden korrekt verifiziert'''. Damit ist echte GPU-Arbeit auf einem zweiten, herstellerfremden Device nachgewiesen.

Zusätzlich läuft <code>MainTextureCS</code> auf der Intel-GPU. Der synchrone Debugtest erzeugt eine 64 × 64 Pixel große RGBA8-Textur; '''alle 4096 shader-generierten Pixel wurden korrekt verifiziert'''. Der normale Runtime-Pfad verwendet inzwischen einen asynchronen 128×96-Test. Der Shader liest seine Dimensionen mit <code>GetDimensions()</code>, schützt überhängende Threads durch einen Bounds-Check und wird mit <code>Dispatch(16,12,1)</code> ausgeführt. <code>PatternPhase</code> erzeugt für jeden akzeptierten Submit deterministisch einen neuen sichtbaren Inhalt. Abgewiesene Busy-Requests erhöhen die Phase nicht und erzeugen daher keine Lücken.

=== Cross-Adapter-Speicher und Synchronisation ===

* RTX und Intel öffnen denselben D3D12 Cross-Adapter Heap.
* Ein gemeinsamer Buffer wurde mit 64 Testwerten erfolgreich geprüft.
* Ein persistenter Shared Fence synchronisiert die Queues direkt von GPU zu GPU. Seine Werte steigen pro Job monoton: WorkerReady/PrimaryComplete verwenden die Paare 1/2, 3/4, 5/6 und so weiter.
* Die CPU vermittelt die GPU-Abhängigkeit nicht; Worker- und Primary-Queue verwenden <code>Signal</code> und <code>Wait</code> direkt auf der GPU.
* Der separate Readback-Verifikationstest darf weiterhin blockieren. Der normale Runtime-Pfad wartet dagegen nicht auf GPU-Leerlauf.

=== Texturtransport ===

Direkte Cross-Adapter-Texturen sind auf dem Testsystem nicht beidseitig verfügbar: Die Intel UHD meldet Unterstützung für Row-Major Cross-Adapter Textures, die RTX 5060 Laptop GPU nicht. Deshalb verwendet das Projekt einen allgemeineren Buffer-Fallback.

<pre>
Intel MainTextureCS
-> persistente Worker-Textur
-> CopyTextureRegion
-> persistenter Shared Cross-Adapter Buffer
-> Worker signalisiert WorkerReady (1, 3, 5, ...)
-> UE-Primary-Queue wartet auf WorkerReady
-> direkte Kopie in persistente UE-eigene FTextureRHIRef
-> Primary signalisiert PrimaryComplete (2, 4, 6, ...)
</pre>

Der robuste Normal-Pfad kopiert die Worker-Textur über den Shared Buffer direkt in eine von Unreal erzeugte <code>FTextureRHIRef</code>. Breite, Höhe und Row Pitch werden dynamisch aus Worker-Ressource und Transport-Metadaten übernommen. Der erfolgreiche 128×96-RGBA8-Test verwendet 512 Byte Row Pitch und 49.152 Byte Transfergröße. Die Output Registry trennt Persistent-, Pending- und Ready-Zustände sowie Inhaltsgeneration und Texturidentität. Dadurch kann eine verspätete Completion keinen neueren Output zurückrollen.

=== Non-blocking Runtime-Pfad ===

Die produktive Testlogik ist aus dem Konsolenkommando in eine gekapselte NormalPath-API verschoben. <code>SubmitWorkerTextureComputeJob()</code> reicht den Worker-Dispatch ohne CPU-Wait ein. <code>QueueNormalTextureTransfer()</code> reiht Wait, Kopie und Completion-Signal in Unreals D3D12-Kontext ein. Der normale MainTextureCS-Pfad enthält weder CPU-Fence-Waits noch Readback, <code>Map</code> oder Pixelvergleich. <code>TickNormalTextureTransfers()</code> prüft die Primary-Completion non-blocking über einen Runtime-Pump; <code>RHIEndFrame()</code> bleibt als Fallback erhalten.

Eine passende Primary-<code>FTextureRHIRef</code> wird pro Worker und Konfiguration persistent gehalten. Nach PrimaryComplete kann der nächste Job dieselbe Resource erneut verwenden; dabei führt Unreal die Übergänge <code>SRVMask -> CopyDest -> SRVMask</code> aus. Eine backend-neutrale RHI-Provider-API reicht die Ready-Textur an die Engine weiter. <code>UExperimentalMultiGPUTexture</code> hält eine stabile <code>UTexture</code> samt TextureReference und bindet die persistente <code>FTextureRHIRef</code> ohne zusätzlichen Pixel-Copy. Eine native D3D12-Resource wird weiterhin nicht blind als UE-Textur gewrappt, weil Unreals Resource-State-Buchhaltung den tatsächlichen nativen Zustand sonst nicht sicher kennt.

=== Sichtbarer TPS-Consumer ===

<code>AExperimentalMultiGPUDisplayActor</code> zeigt die Worker-Ausgabe im Third-Person-Testlevel über den Materialparameter <code>MultiGPUTexture</code> an. Damit ist der Output nicht mehr nur über Logs oder Readback nachgewiesen: Die Intel UHD erzeugt fortlaufend die Texturinhalte, während die RTX die Spielwelt und das Material rendert. <code>TextureConsumerCS</code> kann Ready-Ausgaben auf der Primary zusätzlich als SRV lesen und fünf quantisierte Samples im Debugpfad prüfen.

=== Lebensdauer und automatisches Cleanup ===

Der Normal-Pfad verwendet pro Worker genau einen persistenten Runtime-Slot. Worker-Textur, Root Signature, PSO, Descriptor Heap, Command Allocator/List und Worker-Fence werden nach der ersten kompatiblen Initialisierung wiederverwendet. Dasselbe gilt für Shared Heap/Buffer/Fence und die Transport-Command-Objekte. Der In-Flight-Job trägt nur noch die nötigen Job-, Generation- und Fence-Metadaten.

<pre>
Runtime Request
-> Completion non-blocking prüfen
-> falls Slot frei: Worker Dispatch
-> WorkerReady-Fence signalisieren
-> Primary Wait, SafeCopy und PrimaryComplete-Signal
-> Output Pending
-> Runtime-Pump oder RHIEndFrame prüft GetCompletedValue()
-> Output Ready publizieren
-> Slot wiederverwendbar
</pre>

Backpressure erlaubt maximal einen echten In-Flight-Job pro Worker. Ein Busy-Request setzt keine GPU-Arbeit ab, setzt keine Ressourcen zurück und erhöht <code>PatternPhase</code> nicht. Worker-Fence-Werte steigen mit jedem akzeptierten Submit 1, 2, 3 und so weiter; der persistente Shared Fence verwendet fortlaufend die Paare 1/2, 3/4, 5/6. Fehler nach Übergabe von Ressourcen an die GPU führen zu sicherem Retire beziehungsweise Retention statt zu vorzeitigem Reuse.

=== Texture Stream und Benchmarking ===

Der projektseitige Texture Stream akzeptiert eine beliebige positive, endliche Zielrate. Punkt und Komma sind als Dezimaltrenner möglich. Optional lässt sich die Zahl erfolgreicher Submits begrenzen; Busy- oder Failed-Versuche verbrauchen dieses Limit nicht. Der Quiet-Modus unterdrückt per-Job-Ausgaben, behält aber Start, echte Fehler und die Abschlussstatistik bei.

Die Statistik unterscheidet Timer-Ticks, angenommene Submits, Busy/Failed, Ready, In-Flight und die jeweiligen effektiven Raten. Diagnosezeitpunkte erfassen unter anderem RequestAccepted, RenderCommandExecution, WorkerSubmit, NormalTransferQueued und ReadyObserved.

{| class="wikitable"
! Test
! Ergebnis
! Aussage
|-
| 5 Hz, 20 Submits
| etwa 5 Ready/s, 20/20, kein Busy
| Entspannter Single-Slot-Betrieb
|-
| 1000 Hz, 100 Submits, quiet
| 100/100 Ready, 0 Fehler, etwa 58 Ready/s
| Backpressure begrenzt den Durchsatz sicher
|-
| 1000 Hz bei <code>t.MaxFPS 30</code>
| etwa 28–29 Ready/s trotz rund 982 Timer-Ticks/s
| Primary-/SafeCopy-/Ready-Kette ist effektiv framegekoppelt
|}

Ein zusätzlicher non-blocking Aufruf von <code>ImmediateFlush(DispatchToRHIThread)</code> erreicht hohe Render-Command-Raten, hebt die gemessene Frame-Kopplung aber nicht auf. Im 30-FPS-Test lag der RHIEndFrame-spezifische Completion-Takt praktisch exakt bei 30 Hz. Das aktuelle Problem ist damit eingegrenzt: Nicht der Stream-Timer, sondern die Primary-RHI-/D3D12-Submission der SafeCopy-Kette bestimmt die sichtbare Ready-Rate.

=== Queue-Submission-Diagnose ===

<code>MultiGPUD3D12QueueProbe</code> untersucht die Submission unabhängig vom sichtbaren Texturpfad. Neben <code>full</code>, <code>waitonly</code> und <code>signalonly</code> existieren inzwischen die Diagnosemodi <code>computeonly</code>, <code>commandonly</code>, <code>barrieronly</code>, <code>barrierprivate</code> und <code>copybuffer</code>. Als Queues stehen <code>graphics</code>, <code>copy</code>, <code>native</code>, <code>worker</code>, <code>worker-copy</code> und <code>worker-high</code> zur Verfügung. Graphics und Copy verwenden <code>RHIRunOnQueue(..., false)</code> auf UE-verwalteten Primary-Queues; die übrigen Varianten isolieren private beziehungsweise bereits vorhandene native D3D12-Queues.

Der Probe misst Request, Worker-Submit, <code>RHIRunOnQueue</code>-Aufruf und -Callback, Primary-Execute, Fence-Completion sowie Ready bis zum nächsten akzeptierten Submit. Er fügt keine CPU-Waits, Readbacks, Maps oder <code>BlockUntilGPUIdle</code> ein und beschreibt keine Textur des sichtbaren Normal-Pfads.

{| class="wikitable"
! Test
! Ergebnis
! Befund
|-
| UE Graphics, signal-only, 30 FPS
| 33,319 ms PrimaryExecute bis Ready
| UE-verwaltete Graphics-Submission skaliert mit der Frame-Dauer
|-
| UE Copy, signal-only, 30 FPS
| 32,593 ms PrimaryExecute bis Ready
| Auch die UE-verwaltete Copy Queue ist framegekoppelt
|-
| Private Primary-DIRECT-Queue, signal-only
| etwa 0,014 ms Queue/Fence-Latenz; nach Lifecycle-Fix rund 999 Ready/s bei 30 FPS
| Native Queue und Scheduler sind vollständig vom Frame entkoppelt
|-
| Worker signal-only / leere Command List
| jeweils rund 1000 Ready/s bei 30 FPS
| Worker-Queue, Fence und reine Submission sind nicht framegekoppelt
|-
| Worker <code>CopyBufferRegion</code>, 30 / 60 / 120 FPS
| 29,41 / 58,25 / 113,08 Ready/s
| Bereits eine echte 256-Byte-GPU-Kopie folgt im UE-Prozess dem Frame-Raster
|-
| Worker COPY Queue / HIGH Priority, 30 FPS
| jeweils rund 29,42 Ready/s
| Queue-Typ und Priorität beseitigen die Kopplung nicht
|-
| Standalone-D3D12 auf derselben Intel UHD
| 92.956 Copy-Jobs/s; 0,007 ms durchschnittliche Fence-Latenz
| Die Kopplung ist UE-Prozess-/Scheduling-spezifisch, keine allgemeine Intel-, WDDM- oder D3D12-Grenze
|}

Der <code>RHIRunOnQueue</code>-Callback selbst erreicht den D3D12-Submission-Thread typischerweise bereits nach etwa 0,02–0,05 ms; die Verzögerung entsteht danach in der verwalteten Queue-/Submission-Reihenfolge. <code>SubmitCommandsHint()</code> ist in UE 5.8 nur ein veralteter Alias für <code>ImmediateFlush(DispatchToRHIThread)</code> und stellt daher keinen stärkeren Submission-Mechanismus dar.

Der native Test ist ein '''Architekturbeweis, noch kein Experimental- oder Direct-Modus'''. Die zunächst gemessene Verzögerung von rund 32 ms lag zwischen der In-Flight-Freigabe und dem nächsten Request auf dem Render Thread. Für <code>signalonly/native</code> wurde der sichere Completion-/Submit-Lifecycle deshalb in den frameunabhängigen Scheduler verlegt. Danach erreichten zwei 100-Job-Läufe bei <code>t.MaxFPS 30</code> rund 999 bis 1029 Ready/s, ohne Busy oder Fehler.

Der anschließende <code>full native</code>-Test lokalisierte die verbleibende Kopplung auf echte Worker-GPU-Arbeit: WorkerSubmit bis WorkerReady benötigte bei 30, 60 und 120 FPS ungefähr 33,29, 16,93 und 8,45 ms; WorkerReady bis PrimaryReady war danach praktisch sofort. Signal-only und eine leere Command List waren schnell, Resource Barriers und eine 256-Byte-Kopie dagegen framegebunden. Ein eigenständiger D3D12-Microbenchmark auf derselben Intel UHD erreichte außerhalb von Unreal bei derselben Kopie rund 92.956 Jobs/s mit 0,007 ms mittlerer Fence-Latenz. Die genaue Ursache im UE-Prozess beziehungsweise dessen GPU-Scheduling-Kontext bleibt offen und wird vorerst bis zum Gegencheck mit der vorhandenen Intel Arc A380 geparkt.

=== Worker-Rasterpfad und RasterStream ===

<code>ExperimentalMultiGPU.TestRasterWorker</code> weist erstmals echte Rasterizer-Arbeit auf der Intel-Worker-GPU nach. <code>RasterWorkerVS</code> und <code>RasterWorkerPS</code> werden über Unreals Global-Shader-Pfad kompiliert und für ein natives Worker-Graphics-PSO verwendet. Ein persistentes 128×96-RGBA8-RenderTarget besitzt RTV, leere Root Signature und eine DIRECT-Command-List. Der Vertex Shader erzeugt drei Vertices über <code>SV_VertexID</code>; der Pixel Shader schreibt interpolierte RGB-Farben.

Der Job wechselt das RenderTarget von <code>COPY_SOURCE</code> nach <code>RENDER_TARGET</code>, führt Clear und <code>DrawInstanced(3,1,0,0)</code> aus und wechselt anschließend zurück nach <code>COPY_SOURCE</code>. Danach verwendet er unverändert den robusten Normalpfad aus Cross-Adapter-Shared-Buffer, Primary SafeCopy, persistenter <code>FTextureRHIRef</code>, <code>UExperimentalMultiGPUTexture</code> und DisplayActor. Der Runtime-Test meldete einen akzeptierten Submit und <code>RasterWorker READY</code> für Generation 1; die 128×96-UTexture wurde erfolgreich gebunden.

Der einmalige Test wurde außerdem zu einem frei konfigurierbaren RasterStream ausgebaut. Ein sichtbarer Lauf mit 10 Hz und 50 erfolgreichen Submits endete mit 50 Ready-Ausgaben, 0 Busy und 0 Fehlern bei etwa 9,90 Ready/s. Primary-Textur und Materialbindung blieben dabei persistent.

=== Raster3D mit echten Vertex- und Indexbuffern ===

Der Worker besitzt inzwischen einen kleinen eigenständigen 3D-Rasterpfad mit perspektivischer Kamera, Model-View-Projection-Matrix als Root Constants, D32_FLOAT-Depth-Buffer und Depth-Test. Der finale Testwürfel verwendet 24 POSITION/COLOR-Vertices, 36 <code>uint16</code>-Indices und <code>DrawIndexedInstanced(36,1,0,0,0)</code>; sechs getrennte Seitenfarben machen Ausrichtung und Rotation sichtbar nachvollziehbar.

Die statischen Meshdaten werden einmalig über private Upload-Buffer in DEFAULT-Heaps übertragen. Der Init-Fence wird non-blocking über <code>GetCompletedValue()</code> beobachtet. Der eigentliche Runtime-Renderpfad enthält weiterhin keine CPU-Waits und keine Maps.

=== UE-Static-Meshes auf der Worker-GPU ===

<code>StaticMeshWorker</code> extrahiert echte LOD0-Geometrie aus <code>UStaticMesh</code>-Assets. POSITION und NORMAL sowie <code>uint32</code>-Indices werden in POD-Daten überführt, einmalig asynchron in eigene Worker-VB/IB hochgeladen und anschließend per <code>DrawIndexedInstanced</code> gerendert. Assetpfade sind dynamisch; Auto-Fit richtet Kamera beziehungsweise Modellmaßstab an den Bounds aus.

Sichtbar korrekt getestet wurden:

{| class="wikitable"
! Asset
! Vertices
! Indices
|-
| Sphere
| 559
| 2880
|-
| Cube
| 54
| 144
|-
| Cylinder
| 334
| 1536
|}

=== Multi-Mesh Worker-Szene ===

<code>StaticMeshScene</code> rendert Sphere, Cube und Cylinder gemeinsam in einen Color-/Depth-Frame. Der verifizierte Test umfasst insgesamt 947 Vertices und 4560 Indices, drei <code>DrawIndexedInstanced</code>-Aufrufe und nur einen anschließenden Cross-Adapter-/Normal-SafeCopy-Transfer. Damit ist nicht mehr nur ein synthetisches Primitive, sondern mehrere echte UE-Meshes mit gemeinsamer Tiefenprüfung im Worker-Frame sichtbar nachgewiesen.

=== WorldStaticMeshScene ===

<code>ExperimentalMultiGPUWorldStaticMeshScene.cpp</code> sammelt im Engine-Layer bis zu acht sichtbare <code>UStaticMeshComponent</code>s von Actors mit dem Tag <code>MultiGPUWorker</code>. Meshdaten und World-Transforms werden im Game Thread in reine POD-Strukturen und 4×4-Matrizen kopiert. D3D12RHI erhält keine <code>UObject</code>-Pointer. Mehrere Instanzen desselben Meshes teilen den persistenten Worker-Mesh-Cache und unterscheiden sich nur durch Modelmatrix und Draw Call.

Der Pfad wurde inzwischen sichtbar im PIE-Level verifiziert. Drei getaggte Static-Mesh-Actors erschienen mit ihren tatsächlichen relativen Positionen, Rotationen und Skalierungen im Worker-Bild. Die zentrale Koordinatenumrechnung lautet:

<pre>Worker (X, Y, Z) = (UE Y, UE X, -UE Z)</pre>

Die Transformation besitzt die Determinante +1 und ist damit keine Spiegelung. Das notwendige horizontale Spiegeln erfolgt ausschließlich auf der Presentation-Plane, nicht im Worker-Renderpfad.

=== Kontinuierlicher WorldStaticMeshSceneStream ===

<code>StartWorldStaticMeshSceneStream</code> erfasst die getaggte Szene fortlaufend im Game Thread. Reine Änderungen an Transform oder Kamera lösen keinen erneuten Mesh-Upload aus. Hinzugekommene, entfernte, unsichtbare oder umgetaggte Components werden im nächsten Snapshot berücksichtigt. Single-Slot-Backpressure verhindert einen wachsenden Rückstau.

Ein verifizierter 30-Hz-Lauf endete nach 31,184 Sekunden mit 835 Ticks, 691 angenommenen Submits, 144 Busy, 0 Fehlern und 691 Ready-Frames. Die effektive Ready-Rate betrug 22,16 Hz. Dieser Test belegt die funktionale Live-Aktualisierung; die Rate war noch kein Optimierungsziel.

=== SceneCapture2D als Worker-Kamera ===

<code>TestSceneCaptureStaticMeshScene</code> verwendet eine echte <code>ASceneCapture2D</code> beziehungsweise <code>USceneCaptureComponent2D</code> aus der laufenden PIE-Welt als Kameraquelle. Der empfohlene Editor-Weg ist das Component Tag <code>MultiGPUWorkerCamera</code> auf der <code>CaptureComponent2D</code>; ein gleichnamiges Actor-Tag bleibt nur als Legacy-Fallback.

Ausgelesen werden World Location, Rotation, Forward/Right/Up, <code>FOVAngle</code> und <code>ProjectionType</code>. Orthografische Projektion wird derzeit sauber abgelehnt. Die SceneCapture2D liefert ausschließlich Kameradaten: Ihr UE-RenderTarget wird weder gelesen noch kopiert. Die Intel-Worker-GPU rendert die Geometrie selbst. Kamera und Actors werden gemeinsam mit <code>SceneScale = 0.01</code> in Worker-Koordinaten überführt; Auto-Fit und Scene-Recentering sind in diesem Modus deaktiviert.

Die 128×96-Worker-Projektion verwendet ein Seitenverhältnis von 4:3 und interpretiert <code>FOVAngle</code> als horizontales FOV. Nach den Orientierungstests wird nur die Anzeige über <code>SetRelativeScale3D(FVector(-4.0f, -3.0f, 1.0f))</code> korrigiert; dies entspricht <code>U' = 1-U</code> und <code>V' = 1-V</code>.

=== Live SceneCaptureStaticMeshSceneStream ===

<code>StartSceneCaptureStaticMeshSceneStream</code> liest Kamera-Transform, Kamerabasis, FOV und aktuelle Actor-Transforms pro Snapshot neu im Game Thread. Der Worker erhält weiterhin ausschließlich POD-Daten, verwendet den persistenten Mesh-Cache sowie ein gemeinsames Color- und D32-Depth-Target und führt pro akzeptiertem Frame genau einen Cross-Adapter-/Normal-SafeCopy-Transfer aus.

Der Quiet-Test

<pre>ExperimentalMultiGPU.StartSceneCaptureStaticMeshSceneStream 30 300 quiet</pre>

lieferte in 10,084 Sekunden 301 Ticks, 300 Submits, 1 Busy, 0 Fehler und 300 Ready-Frames. Die effektive Ready-Rate betrug 29,75 Hz. Bewegungen der Kamera und Actors sowie FOV-Änderungen erschienen live auf der Display-Plane. Damit ist erstmals ein kleiner SceneCapture-/CCTV-artiger Worker-Kanal vollständig funktional nachgewiesen.

=== Dynamische SceneCapture-Auflösung ===

Die SceneCapture-Ausgabe ist nicht mehr fest auf 128×96 Pixel begrenzt. <code>ExperimentalMultiGPU.SetSceneCaptureResolution <Width> <Height></code> setzt ganzzahlige Dimensionen von 1 bis 4096; <code>GetSceneCaptureResolution</code> zeigt die aktive Einstellung. 128×96 bleibt der Standard. Während ein SceneCapture-Stream läuft, wird ein Auflösungswechsel absichtlich abgelehnt, damit keine In-Flight-Ressourcen ausgetauscht werden.

Color Target, D32-Depth-Buffer, Row Pitch, Shared-Buffer-Transport, SafeCopy, persistente Primary-Textur und <code>UExperimentalMultiGPUTexture</code> übernehmen die gewählten Dimensionen. Projektion und Display-Plane verwenden das echte Seitenverhältnis. Die bestätigte Anzeigeorientierung <code>U' = 1-U</code> und <code>V' = 1-V</code> bleibt eine reine Presentation-Korrektur; Worker-Basis und Kameramathematik ändern sich nicht.

=== Scheduler-Korrektur bei SceneCapture ===

Ein 1920×1080-Test mit 25 Hz erreichte zunächst trotz fehlerfreier Frames nur 13,90 Ready-Hz und erzeugte 222 Busy-Ticks. Ursache war kein GPU-Limit, sondern ein Polling-Aliasing: Eine frühe Game-Thread-Prüfung konnte den Timer-Slot verwerfen, obwohl die Completion kurz darauf im CoreTicker/RHI-Pump sichtbar geworden wäre.

Die frühe <code>IsRuntimeTextureUpdateInFlight()</code>-Prüfung wurde für diesen Stream entfernt. Der Pending-Request bleibt als Backpressure-Gate erhalten; die maßgebliche Busy-Entscheidung fällt nun erst im Render Command nach <code>TickNormalTextureTransfers(nullptr, true)</code>. Single-Slot, POD-Snapshots und non-blocking <code>GetCompletedValue()</code> bleiben erhalten. Es wurden weder CPU-Waits noch zusätzliche Threads eingeführt.

Nach der Korrektur erreicht 1080p bei 25 Hz 24,79 Ready-Hz mit 1 Busy; bei 30 Hz sind es 29,43 Ready-Hz mit 4 Busy.

=== Skalierung bis 4K60 ===

Die Pipeline wurde von 640×360 bis 3840×2160 getestet. Bei 640×360/30 Hz und 1280×720/30 Hz wurden 29,85 beziehungsweise 29,82 Ready-Hz ohne Busy erreicht. 1920×1080/60 Hz lieferte 59,40 Ready-Hz ohne Busy, 2560×1440/60 Hz 59,21 Ready-Hz mit 1 Busy und 3840×2160/60 Hz 59,02 Ready-Hz mit 2 Busy.

Ein zusätzlicher 4K60-Stresstest mit acht Static-Mesh-Instanzen und drei gecachten Unique Meshes erreichte in 5,049 Sekunden '''300 von 300 Ready-Frames, 0 Busy, 0 Fehler und 59,42 effektive Ready-Hz'''. Acht Draw Calls, gemeinsamer Depth Buffer, Cross-Adapter-Transport und SafeCopy liefen dabei im vorhandenen Single-Slot. Das ist ein Stabilitätsnachweis der aktuellen Mini-Szene, kein allgemeiner GPU-Benchmark.

=== Skeletal Mesh in Reference Pose ===

<code>ExperimentalMultiGPU.TestSkeletalMeshWorker</code> erweitert den Geometriepfad auf <code>USkeletalMeshComponent</code>. Der Engine-Layer sucht deterministisch die erste sichtbare, getaggte Komponente und extrahiert LOD0-Positionen, Normalen, Indices und Render Sections. D3D12RHI erhält wie bisher ausschließlich POD-Geometrie und Modelmatrizen.

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.

== Test- und Diagnosebefehle ==

{| class="wikitable"
! Befehl
! Zweck
|-
| <code>ExperimentalMultiGPU.TestComputeShader</code>
| Führt den vollständigen Worker-Compute-Testpfad aus. Er enthält auch ältere Debug- und Regressionstests mit CPU-Readback und ist daher nicht mit dem reinen asynchronen Runtime-Pfad gleichzusetzen.
|-
| <code>ExperimentalMultiGPU.TestTextureConsumer</code>
| Testet <code>TextureConsumerCS</code> auf der Primary-GPU. Die aktuelle Ready-Textur wird über UE-RHI gelesen und anhand ausgewählter Testpixel per Debug-Readback geprüft.
|-
| <code>ExperimentalMultiGPU.TestTextureBridge</code>
| Prüft die Bridge von der fertigen <code>FTextureRHIRef</code> zu <code>UExperimentalMultiGPUTexture</code> und damit den UE- und materialtauglichen Texturpfad.
|-
| <code>ExperimentalMultiGPU.SpawnDisplayActor</code>
| Spawnt den Test-Actor mit Plane im Spiel. Das Material zeigt darauf die vom Worker erzeugte Textur an.
|-
| <code>ExperimentalMultiGPU.TestRasterWorker</code>
| Rasterisiert auf der Worker-GPU ein echtes RGB-Dreieck per Vertex- und Pixel-Shader und transportiert das Ergebnis über den normalen SafeCopy-Pfad bis zum DisplayActor.
|-
| <code>ExperimentalMultiGPU.StartRasterStream</code> / <code>ExperimentalMultiGPU.StopRasterStream</code>
| Startet beziehungsweise stoppt den kontinuierlichen RGB-Dreieck-RasterStream mit frei wählbarer Zielrate, optionalem Submit-Limit und Quiet-Modus.
|-
| <code>ExperimentalMultiGPU.TestRaster3DWorker</code>
| Rendert einmalig den perspektivischen 3D-Testwürfel mit Depth Buffer und echten Vertex-/Indexbuffern.
|-
| <code>ExperimentalMultiGPU.StartRaster3DStream</code> / <code>ExperimentalMultiGPU.StopRaster3DStream</code>
| Startet beziehungsweise stoppt den kontinuierlichen Raster3D-Test.
|-
| <code>ExperimentalMultiGPU.TestStaticMeshWorker [AssetPath]</code>
| Extrahiert und rendert LOD0-Geometrie eines UE-Static-Mesh-Assets; ohne optionalen Pfad wird das konfigurierte Testasset verwendet.
|-
| <code>ExperimentalMultiGPU.TestStaticMeshScene</code>
| Rendert Sphere, Cube und Cylinder gemeinsam mit drei Draw Calls und einem anschließenden Transfer.
|-
| <code>ExperimentalMultiGPU.TestWorldStaticMeshScene</code>
| Rendert einen einmaligen POD-Snapshot der sichtbaren, mit <code>MultiGPUWorker</code> getaggten StaticMeshComponents aus der laufenden World. Der sichtbare PIE-Nachweis ist erfolgreich.
|-
| <code>ExperimentalMultiGPU.StartWorldStaticMeshSceneStream [Hz] [MaxSuccessfulSubmits] [quiet]</code> / <code>StopWorldStaticMeshSceneStream</code>
| Startet beziehungsweise stoppt den kontinuierlichen Stream der getaggten UE-Welt mit Live-Transforms und persistentem Mesh-Cache.
|-
| <code>ExperimentalMultiGPU.SetSceneCaptureResolution <Width> <Height></code> / <code>GetSceneCaptureResolution</code>
| Setzt beziehungsweise zeigt die gemeinsame SceneCapture-Auflösung. Erlaubt sind ganzzahlige Werte von 1 bis 4096 je Achse; Änderungen während eines laufenden Streams werden abgelehnt.
|-
| <code>ExperimentalMultiGPU.TestSceneCaptureStaticMeshScene</code>
| Rendert einen einmaligen Worker-Snapshot aus Sicht der mit <code>MultiGPUWorkerCamera</code> markierten SceneCapture2D-Kamera.
|-
| <code>ExperimentalMultiGPU.StartSceneCaptureStaticMeshSceneStream [Hz] [MaxSuccessfulSubmits] [quiet]</code> / <code>StopSceneCaptureStaticMeshSceneStream</code>
| Startet beziehungsweise stoppt den Live-Worker-Kanal mit fortlaufend aktualisierten Kamera-, FOV- und Actor-Daten.
|-
| <code>ExperimentalMultiGPU.TestSkeletalMeshWorker</code>
| Rendert das erste sichtbare, getaggte Skeletal Mesh in LOD0 und Reference Pose sectionsweise auf der Worker-GPU.
|-
| <code>ExperimentalMultiGPU.StartTextureStream</code>
| Startet den sichtbaren Normal-Pfad: Worker-Textur → Cross-Adapter-Transfer → SafeCopy → UE-Textur → Material.
|-
| <code>ExperimentalMultiGPU.StopTextureStream</code>
| Verhindert weitere Submits des laufenden Streams. Ein bereits eingereichter GPU-Job darf noch sicher fertig werden.
|-
| <code>ExperimentalMultiGPU.StartQueueProbe</code>
| Startet den Diagnose-Benchmark für Primary-Queue-, Fence- und Submission-Verhalten. Der Probe verändert die sichtbare Textur nicht.
|}

=== Texture Stream ===

Grundsyntax:

<pre>
ExperimentalMultiGPU.StartTextureStream [Hz] [MaxSuccessfulSubmits] [quiet]
</pre>

{| class="wikitable"
! Beispiel
! Wirkung
|-
| <code>ExperimentalMultiGPU.StartTextureStream</code>
| Standardmäßig etwa 5 Hz, ohne Submit-Limit.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 37.5</code>
| Fordert 37,5 Hz ohne Submit-Limit an. Sowohl <code>37.5</code> als auch <code>37,5</code> werden akzeptiert.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 1000 100</code>
| Fordert 1000 Hz an und stoppt nach exakt 100 erfolgreichen Submits.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 1000 100 quiet</code>
| Wie zuvor, unterdrückt aber Per-Job- und Busy-Logspam.
|}

Die Hz-Angabe ist eine '''Ziel- beziehungsweise Request-Frequenz'''. <code>1000</code> bedeutet daher nicht automatisch 1000 fertige Texturen pro Sekunde. Die tatsächliche Rate hängt unter anderem von Timer, Submission, Backpressure, Queue-Latenz und Slot-Lifecycle ab. <code>MaxSuccessfulSubmits</code> zählt nur angenommene Submits; Busy- und Failed-Versuche verbrauchen das Limit nicht.

=== QueueProbe ===

Grundsyntax:

<pre>
ExperimentalMultiGPU.StartQueueProbe <Hz> <MaxSubmits> [quiet] [Mode] [Queue]
</pre>

{| class="wikitable"
! Modus
! Ausgeführter Pfad
|-
| <code>full</code>
| Worker Compute → Cross-Adapter-Transfer → Primary Wait → Copy → Completion Fence.
|-
| <code>waitonly</code>
| Worker Compute → Cross-Adapter-Transfer → Primary wartet auf WorkerReadyFence → Completion Fence. Es findet keine Texturkopie statt.
|-
| <code>signalonly</code>
| Keine Textur, kein Worker-Wait und keine Kopie; nur Queue und Fence. Dieser Modus isoliert das Queue-Verhalten.
|-
| <code>commandonly</code>
| Reicht eine leere echte Worker-Command-List ein und trennt Command-Submission von GPU-Arbeit.
|-
| <code>barrieronly</code> / <code>barrierprivate</code>
| Isoliert Resource-Barriers auf Worker-Ressourcen beziehungsweise einer privaten Testtextur.
|-
| <code>copybuffer</code>
| Führt eine minimale echte <code>CopyBufferRegion</code>-Operation über 256 Byte aus.
|}

{| class="wikitable"
! Queue
! Bedeutung
|-
| <code>graphics</code>
| Vorhandene UE Primary Graphics-/Direct-Queue über <code>RHIRunOnQueue</code>.
|-
| <code>copy</code>
| Vorhandene UE Primary Copy Queue über <code>RHIRunOnQueue</code>.
|-
| <code>native</code>
| Vollständig private native D3D12-DIRECT-Queue auf der Primary; reine Diagnose, kein fertiger Experimental-Modus.
|-
| <code>worker</code>
| Vorhandene native Worker-DIRECT-Queue.
|-
| <code>worker-copy</code>
| Separate native Worker-COPY-Queue.
|-
| <code>worker-high</code>
| Separate Worker-DIRECT-Queue mit hoher Priorität.
|}

Typische Beispiele:

<pre>
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet full graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet waitonly graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly copy
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly native
</pre>

Der letzte Befehl ist aktuell die wichtigste isolierte Gegenprobe. Mit der privaten nativen Queue wurde bei 30 FPS eine durchschnittliche Latenz <code>primaryExecuteToReadyAvgMs = 0.014 ms</code> gemessen.

=== Benchmark-CVars ===

{| class="wikitable"
! CVar
! Zweck
|-
| <code>r.VSync 0</code>
| Deaktiviert VSync, damit es die Messung nicht begrenzt.
|-
| <code>t.MaxFPS 30</code> <code>t.MaxFPS 60</code> <code>t.MaxFPS 120</code>
| Setzt die Engine-Framerate für reproduzierbare Frame-Coupling-Tests.
|-
| <code>t.MaxFPS 0</code>
| Entfernt das normale <code>t.MaxFPS</code>-Limit. Dieser Lauf ist als zusätzliche Diagnose-Gegenprobe vorgesehen.
|}

== 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.

== Historische Vorläufer ==

Die Grundidee heterogener Multi-GPU-Nutzung ist nicht neu. Bereits mit der Einführung von Direct3D 12 entstanden mehrere Versuche, integrierte und dedizierte GPUs gemeinsam zu verwenden. Eine allgemein einsetzbare Lösung für moderne UE5-Spiele hat sich daraus jedoch nicht entwickelt.

=== Microsoft und Epic: UE4 Elemental Demo (2015) ===

Microsoft zeigte eine angepasste Unreal-Engine-4-Version der Elemental-Demo, bei der eine NVIDIA-GPU und eine Intel-iGPU gemeinsam arbeiteten. Das erklärte Ziel war, ansonsten ungenutzte Grafikleistung in Hybrid-Systemen zu verwenden. Dieser Versuch ist der Grundidee des Projekts besonders ähnlich, blieb aber eine technische Demonstration.

=== Intel: D3D12 Multi-Adapter Sample (2015) ===

Intels Beispiel kombinierte eine GeForce 840M mit Intel HD Graphics 5500. Beide GPUs berechneten getrennte Teile einer einfach parallelisierbaren Raytracing-Szene. Cross-Adapter-Ressourcen und Shared Fences führten die Ergebnisse anschließend zusammen. Intel berichtete in diesem Test von nahezu halbierter Framezeit, warnte jedoch ausdrücklich davor, das Ergebnis unmittelbar auf reale Spiele zu übertragen.

=== Ashes of the Singularity ===

Die Nitrous Engine von ''Ashes of the Singularity'' setzte Direct3D-12-Explicit-Multiadapter in einem veröffentlichten Spiel ein. Dabei konnten auch unterschiedliche GPU-Modelle und Hersteller zusammenarbeiten. Das war ein wichtiger Praxisnachweis, blieb in der Spielebranche aber eine seltene Ausnahme.

=== Weitere verwandte Ansätze ===

* ''Rise of the Tomb Raider'' erhielt explizite Direct3D-12-Multi-GPU-Unterstützung, vor allem für klassische Kombinationen ähnlicher GPUs.
* NVIDIA VR SLI wies bei Virtual Reality jeder GPU ein Auge zu. Das verteilt unabhängige Ansichten, bleibt jedoch NVIDIA-spezifisch.
* Unreal nDisplay kann Viewports oder Frustums auf weitere GPUs beziehungsweise Prozesse auslagern und das fertige Bild zur Ausgabe-GPU zurückführen. Der Einsatzbereich ist hauptsächlich Virtual Production.
* Forschung und High-Performance Computing verwenden seit Jahren Scheduler für heterogene GPUs, allerdings überwiegend für Compute- und Datenverarbeitungsaufgaben statt für einen allgemeinen UE5-Echtzeitrenderer.

=== Abgrenzung dieses Projekts ===

Das Projekt erfindet Direct3D-12-Explicit-Multiadapter nicht neu. Sein eigener Ansatz liegt in der Kombination aus tiefer UE5.8-RHI-Integration, UE-kompilierten Shadern auf unabhängigen Worker-Devices, frei wählbaren Spiel- und Compute-Workloads, Capability- und Performance-Scheduler, mehreren Fallback-Pfaden sowie dem langfristigen Ziel beliebiger Hersteller und mehrerer Worker.

== Vergleich mit anderen Multi-GPU-Verfahren ==

{| class="wikitable"
! Verfahren
! Arbeitsweise
! Verhältnis zu diesem Projekt
|-
| SLI / CrossFire
| Treiber- beziehungsweise Verbundlösung für meist ähnliche GPUs; häufig wird die Bildarbeit verteilt.
| Dieses Projekt benötigt keinen herstellerspezifischen GPU-Verbund und weist Aufgaben ausdrücklich selbst zu.
|-
| AFR (Alternate Frame Rendering)
| GPU 1 rendert einen Frame, GPU 2 den nächsten.
| Das Projekt verteilt unabhängige Aufgaben statt aufeinanderfolgender Frames. Dadurch werden Frame-Abhängigkeiten und typisches AFR-Pacing vermieden.
|-
| SFR (Split Frame Rendering)
| Mehrere GPUs bearbeiten Bereiche desselben Frames.
| Erfordert enge Lastverteilung und viel Datenaustausch. Das Projekt bevorzugt vollständig abgrenzbare Workloads und überträgt deren Ergebnis.
|-
| Direct3D 12 Linked Multiadapter
| Mehrere vom Treiber verbundene GPUs erscheinen als Knoten eines logischen Adapters.
| Eignet sich eher für eng kompatible GPUs. Das Projekt verwendet unabhängige Devices (Unlinked/Explicit Multiadapter) und unterstützt dadurch heterogene Herstellerkombinationen.
|-
| Direct3D 12 Unlinked / Explicit Multiadapter
| Die Anwendung verwaltet getrennte Adapter, Ressourcen und Synchronisation selbst.
| Das ist die technische Familie des Projekts. Hinzu kommen die eigene UE5-RHI-Integration, Workload-Ziele, Fallbacks und der geplante Scheduler.
|-
| UE nDisplay mGPU / Multi-Process
| Separate GPUs rendern bestimmte Viewports oder Frustums, vor allem für Virtual Production; Ergebnisse werden zur Ausgabe-GPU kopiert.
| Ähnliche Idee der aufgabenweisen Trennung, aber für einen anderen Einsatzbereich. Dieses Projekt zielt auf allgemeine Spiel- und Compute-Workloads innerhalb der Engine.
|-
| Vulkan Device Groups
| Ähnliche physische GPUs können ein gemeinsames logisches Device bilden.
| Für beliebige heterogene GPUs meist ungeeignet, da Geräte einer Gruppe nahezu gleiche Eigenschaften besitzen müssen. Eine spätere Vulkan-Portierung benötigt daher wahrscheinlich getrennte Devices und External Memory/Semaphores.
|}

SLI und CrossFire bezeichnen den Verbund; AFR und SFR beschreiben mögliche Verteilungsmethoden innerhalb solcher Systeme. Sie sind deshalb nicht vollständig getrennte Kategorien.

== Vorteile der geplanten Variante ==

* '''Herstellerunabhängig:''' NVIDIA, AMD und Intel können grundsätzlich kombiniert werden.
* '''Vorhandene Hardware nutzen:''' Auch eine sonst wenig genutzte integrierte GPU kann geeignete Nebenaufgaben übernehmen.
* '''Aufgaben statt Frames verteilen:''' Spiegel, Minimap oder Compute können mit eigener Auflösung und Aktualisierungsrate laufen.
* '''Keine identischen GPUs erforderlich:''' Unterschiedliche Fähigkeiten können gezielt genutzt werden.
* '''Kontrollierter Datenaustausch:''' Nur das benötigte Ergebnis muss zurück zur Primary-GPU.
* '''Robuste Fallback-Idee:''' Wenn direkte Texturen nicht gemeinsam nutzbar sind, bleibt der Shared-Buffer-Pfad.
* '''Erweiterbar:''' Scheduler, manuelles Mapping und mehrere Worker sind als spätere Stufen vorgesehen.

== Nachteile und technische Risiken ==

* '''Hoher Entwicklungsaufwand:''' Geräte, Ressourcen, Zustände, Fences, Fehlerfälle und UE-Lebenszyklen müssen selbst verwaltet werden.
* '''Transfer kann den Gewinn aufzehren:''' Cross-Adapter Heaps liegen laut D3D12 nicht automatisch im schnellen lokalen VRAM. Bandbreite und Latenz müssen für jeden Workload gemessen werden.
* '''VRAM wird nicht einfach addiert:''' Benötigte Ressourcen können auf mehreren GPUs vorliegen und zusätzlichen Speicher verbrauchen.
* '''Langsame Worker können bremsen:''' Eine Aufgabe lohnt sich nur, wenn Rechengewinn größer als Übergabe-, Warte- und Kopierkosten ist.
* '''Nicht jeder Workload ist unabhängig:''' Hauptansicht, Lumen, Nanite und stark gekoppelte Renderpässe besitzen viele Abhängigkeiten und sind schwieriger auszulagern.
* '''Hardwareunterschiede:''' Formate, Shader-Funktionen, Queue-Fähigkeiten und Cross-Adapter-Support müssen pro GPU geprüft werden.
* '''Wartungsrisiko:''' Eingriffe in private D3D12RHI-Dateien können bei Engine-Updates angepasst werden müssen.
* '''Produktionsreife fehlt noch:''' Ressourcenpools, Timeouts, Device-Lost-Wiederherstellung, Scheduler und echte Szenentests sind offen.

== Wann die Variante sinnvoll ist ==

Am aussichtsreichsten sind Aufgaben mit viel eigener Rechenarbeit, einem relativ kleinen Endergebnis und wenigen Abhängigkeiten zur Hauptszene. Gute frühe Kandidaten sind unabhängige Compute-Aufgaben sowie Scene Captures, die nicht in jedem Frame aktualisiert werden müssen. Weniger geeignet sind winzige Aufgaben mit großem Transfer oder Renderpässe, die ständig auf Ressourcen der Primary-GPU zugreifen.

Die entscheidende Regel für den späteren Scheduler lautet daher:

<pre>
Worker-Gewinn > Vorbereitung + Datentransfer + Synchronisation + Rückintegration
</pre>

== 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.
* Pro Worker existiert absichtlich nur ein persistenter Runtime-Slot. Mehrere parallele In-Flight-Jobs sowie Double-, Triple- oder Ring-Buffering fehlen noch.
* Die Primary-/SafeCopy-/Ready-Kette bleibt trotz zusätzlichem non-blocking <code>DispatchToRHIThread</code> effektiv an den Frame-/Submission-Zyklus gekoppelt.
* 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.
* QueueProbe ist reine Diagnose. Private native Queues sind noch kein Experimental-/Direct-Modus und beschreiben keine UE-eigene sichtbare Textur.
* Es gibt noch keine Umschaltung zwischen Normal und Experimental sowie keinen automatischen Session-Fallback.
* Raw-D3D12-Shared-Ressourcen sind noch nicht vollständig in Unreals Residency-Management eingebunden.
* Praktisch getestet ist Primary plus ein Worker. Die Architektur ist auf mehrere Worker ausgelegt, N-GPU ist aber noch nicht praktisch validiert.
* 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.
* <code>USkeletalMesh</code> ist bislang ein LOD0-ReferencePose-Proof. Bone-Skinning, Animation, Morph Targets und Cloth fehlen noch.
* 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.
* 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.

== Roadmap ==

# Einen echten Nutzlast-Proof als CCTV, Spiegel oder Minimap aufbauen.
# Skeletal Skinning mit Bone-Matrizen und Skin Weights anbinden und Quinn von der Reference Pose zur laufenden Animation bringen.
# Mehrere Mesh-Sections, Material-/Textur-Bindings und anschließend Culling ergänzen.
# D3D12-Adapter-, Raster- und SceneCapture-Pfade auf Intel Arc A750/A380 und später mit RX 6900 XT als Primary gegenprüfen.
# Microbenchmarks und echte Workloads zu einem Autotuner für sinnvolle GPU-Paare und Jobzahlen ausbauen.
# Experimental-/Direct-Architektur mit State-Tracking, Residency, Hazards, Capability-Selftest und automatischem Fallback entwerfen.
# Mehrere Runtime-Slots beziehungsweise einen Ringbuffer erst bei echtem Workload-Bedarf ergänzen.
# Langfristig einen Engine-eigenen Multi-Tier Resource Manager für Primary-VRAM, Worker-VRAM und RAM untersuchen; kein transparenter gemeinsamer Hardware-VRAM.
# Linux/Vulkan mit External Memory und externen Semaphoren/Fences untersuchen.

== 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.

== 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.
* [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/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://www.intel.com/content/dam/develop/external/us/en/documents/multi-adapter-support-in-directx-12-594015.pdf Intel: Multi-Adapter Support in DirectX 12]
* [https://devblogs.microsoft.com/directx/ashes-of-the-singularity-makes-gaming-history-with-directx-12/ Microsoft: Ashes of the Singularity und heterogene Adapter]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/nvidia-sli-alternative-frame-rendering-in-unreal-engine Epic: NVIDIA SLI Alternate Frame Rendering]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/multi-process-rendering-with-unreal-engine Epic: Multi-Process Rendering]
* [https://registry.khronos.org/vulkan/specs/latest/pdf/vkspec.pdf Khronos: Vulkan Specification – Device Groups]

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Multi-GPU]]
[[Kategorie:Direct3D 12]]
[[Kategorie:Experimentell]]

UE5 Heterogeneous Multi-GPU

2026-09-09T23:58:32Z

Elaina: Entwicklungsstand 10.09.2026: Live-World- und SceneCapture-Workerpfad, Commit 45d5c27

{{Hinweis|Projektstand: 10. September 2026. Engine-Checkpoint: <code>45d5c27</code> (<code>Add live SceneCapture worker rendering pipeline</code>) auf Branch <code>mgpu-experimental</code>; der Engine-Working-Tree war danach sauber, 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.}}

'''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.

{| class="wikitable"
|+ Projektstatus
|-
! Engine / Plattform
| Unreal Engine 5.8 Source Build / Windows / Direct3D 12
|-
! Testsystem
| Lenovo LOQ 17IRX10
|-
! Primary
| NVIDIA GeForce RTX 5060 Laptop GPU
|-
! Worker
| Intel UHD Graphics
|-
! Zusätzliche Testhardware
| Intel Arc A380 als zusätzlicher dGPU-Worker-Gegencheck vorgesehen
|-
! Git-Stand
| Commit <code>45d5c27</code> auf Branch <code>mgpu-experimental</code>; Engine-Working-Tree danach sauber, nicht gepusht
|-
! Windows/D3D12-Proof-of-Concept
| Durchgängiger sichtbarer Worker-Rasterpfad von der laufenden UE-Welt über getaggte Static Meshes und eine echte SceneCapture2D-Kamera bis zur persistenten UE-Textur; Live-Stream mit 300/300 Ready-Frames nachgewiesen
|-
! Gesamtvision
| etwa 30–35 % (Scheduler, echte Workloads, N-GPU und Vulkan noch offen)
|}

== Grundprinzip ==

<pre>
Intel Worker GPU
-> MainTextureCS + PatternPhase
-> persistente Worker-Textur
-> persistenter Shared Cross-Adapter Buffer
-> monotone Shared Fence / Queue Wait
-> persistente UE-eigene FTextureRHIRef
-> stabile UExperimentalMultiGPUTexture

RTX Primary GPU
-> normales UE5-Rendering
-> TPS-Material zeigt das Worker-Ergebnis sichtbar an
</pre>

Pro Worker ist maximal ein Runtime-Job gleichzeitig in flight. Backpressure lehnt weitere Requests als <code>Busy</code> ab, bis der Slot nach der Primary-Completion wieder sicher verwendbar ist.

Jeder Worker besitzt ein eigenes <code>ID3D12Device</code>, eigene Queues, Command Lists und Ressourcen. Ein späterer Scheduler soll Rechenleistung, Fähigkeiten, Transferkosten und gewünschte Aktualisierungsrate bewerten. Vorgesehene Aufgaben sind beispielsweise SceneCapture2D, Spiegel, CCTV, Minimap, Compute oder Niagara.

== Verifizierter Entwicklungsstand ==

=== Worker-Compute ===

Ein echter, von Unreal kompilierter Global Compute Shader läuft auf der Intel UHD, während Unreal regulär über die RTX rendert. Der Test verdoppelt 64 Ganzzahlen auf dem Worker; '''64 von 64 Ergebnissen wurden korrekt verifiziert'''. Damit ist echte GPU-Arbeit auf einem zweiten, herstellerfremden Device nachgewiesen.

Zusätzlich läuft <code>MainTextureCS</code> auf der Intel-GPU. Der synchrone Debugtest erzeugt eine 64 × 64 Pixel große RGBA8-Textur; '''alle 4096 shader-generierten Pixel wurden korrekt verifiziert'''. Der normale Runtime-Pfad verwendet inzwischen einen asynchronen 128×96-Test. Der Shader liest seine Dimensionen mit <code>GetDimensions()</code>, schützt überhängende Threads durch einen Bounds-Check und wird mit <code>Dispatch(16,12,1)</code> ausgeführt. <code>PatternPhase</code> erzeugt für jeden akzeptierten Submit deterministisch einen neuen sichtbaren Inhalt. Abgewiesene Busy-Requests erhöhen die Phase nicht und erzeugen daher keine Lücken.

=== Cross-Adapter-Speicher und Synchronisation ===

* RTX und Intel öffnen denselben D3D12 Cross-Adapter Heap.
* Ein gemeinsamer Buffer wurde mit 64 Testwerten erfolgreich geprüft.
* Ein persistenter Shared Fence synchronisiert die Queues direkt von GPU zu GPU. Seine Werte steigen pro Job monoton: WorkerReady/PrimaryComplete verwenden die Paare 1/2, 3/4, 5/6 und so weiter.
* Die CPU vermittelt die GPU-Abhängigkeit nicht; Worker- und Primary-Queue verwenden <code>Signal</code> und <code>Wait</code> direkt auf der GPU.
* Der separate Readback-Verifikationstest darf weiterhin blockieren. Der normale Runtime-Pfad wartet dagegen nicht auf GPU-Leerlauf.

=== Texturtransport ===

Direkte Cross-Adapter-Texturen sind auf dem Testsystem nicht beidseitig verfügbar: Die Intel UHD meldet Unterstützung für Row-Major Cross-Adapter Textures, die RTX 5060 Laptop GPU nicht. Deshalb verwendet das Projekt einen allgemeineren Buffer-Fallback.

<pre>
Intel MainTextureCS
-> persistente Worker-Textur
-> CopyTextureRegion
-> persistenter Shared Cross-Adapter Buffer
-> Worker signalisiert WorkerReady (1, 3, 5, ...)
-> UE-Primary-Queue wartet auf WorkerReady
-> direkte Kopie in persistente UE-eigene FTextureRHIRef
-> Primary signalisiert PrimaryComplete (2, 4, 6, ...)
</pre>

Der robuste Normal-Pfad kopiert die Worker-Textur über den Shared Buffer direkt in eine von Unreal erzeugte <code>FTextureRHIRef</code>. Breite, Höhe und Row Pitch werden dynamisch aus Worker-Ressource und Transport-Metadaten übernommen. Der erfolgreiche 128×96-RGBA8-Test verwendet 512 Byte Row Pitch und 49.152 Byte Transfergröße. Die Output Registry trennt Persistent-, Pending- und Ready-Zustände sowie Inhaltsgeneration und Texturidentität. Dadurch kann eine verspätete Completion keinen neueren Output zurückrollen.

=== Non-blocking Runtime-Pfad ===

Die produktive Testlogik ist aus dem Konsolenkommando in eine gekapselte NormalPath-API verschoben. <code>SubmitWorkerTextureComputeJob()</code> reicht den Worker-Dispatch ohne CPU-Wait ein. <code>QueueNormalTextureTransfer()</code> reiht Wait, Kopie und Completion-Signal in Unreals D3D12-Kontext ein. Der normale MainTextureCS-Pfad enthält weder CPU-Fence-Waits noch Readback, <code>Map</code> oder Pixelvergleich. <code>TickNormalTextureTransfers()</code> prüft die Primary-Completion non-blocking über einen Runtime-Pump; <code>RHIEndFrame()</code> bleibt als Fallback erhalten.

Eine passende Primary-<code>FTextureRHIRef</code> wird pro Worker und Konfiguration persistent gehalten. Nach PrimaryComplete kann der nächste Job dieselbe Resource erneut verwenden; dabei führt Unreal die Übergänge <code>SRVMask -> CopyDest -> SRVMask</code> aus. Eine backend-neutrale RHI-Provider-API reicht die Ready-Textur an die Engine weiter. <code>UExperimentalMultiGPUTexture</code> hält eine stabile <code>UTexture</code> samt TextureReference und bindet die persistente <code>FTextureRHIRef</code> ohne zusätzlichen Pixel-Copy. Eine native D3D12-Resource wird weiterhin nicht blind als UE-Textur gewrappt, weil Unreals Resource-State-Buchhaltung den tatsächlichen nativen Zustand sonst nicht sicher kennt.

=== Sichtbarer TPS-Consumer ===

<code>AExperimentalMultiGPUDisplayActor</code> zeigt die Worker-Ausgabe im Third-Person-Testlevel über den Materialparameter <code>MultiGPUTexture</code> an. Damit ist der Output nicht mehr nur über Logs oder Readback nachgewiesen: Die Intel UHD erzeugt fortlaufend die Texturinhalte, während die RTX die Spielwelt und das Material rendert. <code>TextureConsumerCS</code> kann Ready-Ausgaben auf der Primary zusätzlich als SRV lesen und fünf quantisierte Samples im Debugpfad prüfen.

=== Lebensdauer und automatisches Cleanup ===

Der Normal-Pfad verwendet pro Worker genau einen persistenten Runtime-Slot. Worker-Textur, Root Signature, PSO, Descriptor Heap, Command Allocator/List und Worker-Fence werden nach der ersten kompatiblen Initialisierung wiederverwendet. Dasselbe gilt für Shared Heap/Buffer/Fence und die Transport-Command-Objekte. Der In-Flight-Job trägt nur noch die nötigen Job-, Generation- und Fence-Metadaten.

<pre>
Runtime Request
-> Completion non-blocking prüfen
-> falls Slot frei: Worker Dispatch
-> WorkerReady-Fence signalisieren
-> Primary Wait, SafeCopy und PrimaryComplete-Signal
-> Output Pending
-> Runtime-Pump oder RHIEndFrame prüft GetCompletedValue()
-> Output Ready publizieren
-> Slot wiederverwendbar
</pre>

Backpressure erlaubt maximal einen echten In-Flight-Job pro Worker. Ein Busy-Request setzt keine GPU-Arbeit ab, setzt keine Ressourcen zurück und erhöht <code>PatternPhase</code> nicht. Worker-Fence-Werte steigen mit jedem akzeptierten Submit 1, 2, 3 und so weiter; der persistente Shared Fence verwendet fortlaufend die Paare 1/2, 3/4, 5/6. Fehler nach Übergabe von Ressourcen an die GPU führen zu sicherem Retire beziehungsweise Retention statt zu vorzeitigem Reuse.

=== Texture Stream und Benchmarking ===

Der projektseitige Texture Stream akzeptiert eine beliebige positive, endliche Zielrate. Punkt und Komma sind als Dezimaltrenner möglich. Optional lässt sich die Zahl erfolgreicher Submits begrenzen; Busy- oder Failed-Versuche verbrauchen dieses Limit nicht. Der Quiet-Modus unterdrückt per-Job-Ausgaben, behält aber Start, echte Fehler und die Abschlussstatistik bei.

Die Statistik unterscheidet Timer-Ticks, angenommene Submits, Busy/Failed, Ready, In-Flight und die jeweiligen effektiven Raten. Diagnosezeitpunkte erfassen unter anderem RequestAccepted, RenderCommandExecution, WorkerSubmit, NormalTransferQueued und ReadyObserved.

{| class="wikitable"
! Test
! Ergebnis
! Aussage
|-
| 5 Hz, 20 Submits
| etwa 5 Ready/s, 20/20, kein Busy
| Entspannter Single-Slot-Betrieb
|-
| 1000 Hz, 100 Submits, quiet
| 100/100 Ready, 0 Fehler, etwa 58 Ready/s
| Backpressure begrenzt den Durchsatz sicher
|-
| 1000 Hz bei <code>t.MaxFPS 30</code>
| etwa 28–29 Ready/s trotz rund 982 Timer-Ticks/s
| Primary-/SafeCopy-/Ready-Kette ist effektiv framegekoppelt
|}

Ein zusätzlicher non-blocking Aufruf von <code>ImmediateFlush(DispatchToRHIThread)</code> erreicht hohe Render-Command-Raten, hebt die gemessene Frame-Kopplung aber nicht auf. Im 30-FPS-Test lag der RHIEndFrame-spezifische Completion-Takt praktisch exakt bei 30 Hz. Das aktuelle Problem ist damit eingegrenzt: Nicht der Stream-Timer, sondern die Primary-RHI-/D3D12-Submission der SafeCopy-Kette bestimmt die sichtbare Ready-Rate.

=== Queue-Submission-Diagnose ===

<code>MultiGPUD3D12QueueProbe</code> untersucht die Submission unabhängig vom sichtbaren Texturpfad. Neben <code>full</code>, <code>waitonly</code> und <code>signalonly</code> existieren inzwischen die Diagnosemodi <code>computeonly</code>, <code>commandonly</code>, <code>barrieronly</code>, <code>barrierprivate</code> und <code>copybuffer</code>. Als Queues stehen <code>graphics</code>, <code>copy</code>, <code>native</code>, <code>worker</code>, <code>worker-copy</code> und <code>worker-high</code> zur Verfügung. Graphics und Copy verwenden <code>RHIRunOnQueue(..., false)</code> auf UE-verwalteten Primary-Queues; die übrigen Varianten isolieren private beziehungsweise bereits vorhandene native D3D12-Queues.

Der Probe misst Request, Worker-Submit, <code>RHIRunOnQueue</code>-Aufruf und -Callback, Primary-Execute, Fence-Completion sowie Ready bis zum nächsten akzeptierten Submit. Er fügt keine CPU-Waits, Readbacks, Maps oder <code>BlockUntilGPUIdle</code> ein und beschreibt keine Textur des sichtbaren Normal-Pfads.

{| class="wikitable"
! Test
! Ergebnis
! Befund
|-
| UE Graphics, signal-only, 30 FPS
| 33,319 ms PrimaryExecute bis Ready
| UE-verwaltete Graphics-Submission skaliert mit der Frame-Dauer
|-
| UE Copy, signal-only, 30 FPS
| 32,593 ms PrimaryExecute bis Ready
| Auch die UE-verwaltete Copy Queue ist framegekoppelt
|-
| Private Primary-DIRECT-Queue, signal-only
| etwa 0,014 ms Queue/Fence-Latenz; nach Lifecycle-Fix rund 999 Ready/s bei 30 FPS
| Native Queue und Scheduler sind vollständig vom Frame entkoppelt
|-
| Worker signal-only / leere Command List
| jeweils rund 1000 Ready/s bei 30 FPS
| Worker-Queue, Fence und reine Submission sind nicht framegekoppelt
|-
| Worker <code>CopyBufferRegion</code>, 30 / 60 / 120 FPS
| 29,41 / 58,25 / 113,08 Ready/s
| Bereits eine echte 256-Byte-GPU-Kopie folgt im UE-Prozess dem Frame-Raster
|-
| Worker COPY Queue / HIGH Priority, 30 FPS
| jeweils rund 29,42 Ready/s
| Queue-Typ und Priorität beseitigen die Kopplung nicht
|-
| Standalone-D3D12 auf derselben Intel UHD
| 92.956 Copy-Jobs/s; 0,007 ms durchschnittliche Fence-Latenz
| Die Kopplung ist UE-Prozess-/Scheduling-spezifisch, keine allgemeine Intel-, WDDM- oder D3D12-Grenze
|}

Der <code>RHIRunOnQueue</code>-Callback selbst erreicht den D3D12-Submission-Thread typischerweise bereits nach etwa 0,02–0,05 ms; die Verzögerung entsteht danach in der verwalteten Queue-/Submission-Reihenfolge. <code>SubmitCommandsHint()</code> ist in UE 5.8 nur ein veralteter Alias für <code>ImmediateFlush(DispatchToRHIThread)</code> und stellt daher keinen stärkeren Submission-Mechanismus dar.

Der native Test ist ein '''Architekturbeweis, noch kein Experimental- oder Direct-Modus'''. Die zunächst gemessene Verzögerung von rund 32 ms lag zwischen der In-Flight-Freigabe und dem nächsten Request auf dem Render Thread. Für <code>signalonly/native</code> wurde der sichere Completion-/Submit-Lifecycle deshalb in den frameunabhängigen Scheduler verlegt. Danach erreichten zwei 100-Job-Läufe bei <code>t.MaxFPS 30</code> rund 999 bis 1029 Ready/s, ohne Busy oder Fehler.

Der anschließende <code>full native</code>-Test lokalisierte die verbleibende Kopplung auf echte Worker-GPU-Arbeit: WorkerSubmit bis WorkerReady benötigte bei 30, 60 und 120 FPS ungefähr 33,29, 16,93 und 8,45 ms; WorkerReady bis PrimaryReady war danach praktisch sofort. Signal-only und eine leere Command List waren schnell, Resource Barriers und eine 256-Byte-Kopie dagegen framegebunden. Ein eigenständiger D3D12-Microbenchmark auf derselben Intel UHD erreichte außerhalb von Unreal bei derselben Kopie rund 92.956 Jobs/s mit 0,007 ms mittlerer Fence-Latenz. Die genaue Ursache im UE-Prozess beziehungsweise dessen GPU-Scheduling-Kontext bleibt offen und wird vorerst bis zum Gegencheck mit der vorhandenen Intel Arc A380 geparkt.

=== Worker-Rasterpfad und RasterStream ===

<code>ExperimentalMultiGPU.TestRasterWorker</code> weist erstmals echte Rasterizer-Arbeit auf der Intel-Worker-GPU nach. <code>RasterWorkerVS</code> und <code>RasterWorkerPS</code> werden über Unreals Global-Shader-Pfad kompiliert und für ein natives Worker-Graphics-PSO verwendet. Ein persistentes 128×96-RGBA8-RenderTarget besitzt RTV, leere Root Signature und eine DIRECT-Command-List. Der Vertex Shader erzeugt drei Vertices über <code>SV_VertexID</code>; der Pixel Shader schreibt interpolierte RGB-Farben.

Der Job wechselt das RenderTarget von <code>COPY_SOURCE</code> nach <code>RENDER_TARGET</code>, führt Clear und <code>DrawInstanced(3,1,0,0)</code> aus und wechselt anschließend zurück nach <code>COPY_SOURCE</code>. Danach verwendet er unverändert den robusten Normalpfad aus Cross-Adapter-Shared-Buffer, Primary SafeCopy, persistenter <code>FTextureRHIRef</code>, <code>UExperimentalMultiGPUTexture</code> und DisplayActor. Der Runtime-Test meldete einen akzeptierten Submit und <code>RasterWorker READY</code> für Generation 1; die 128×96-UTexture wurde erfolgreich gebunden.

Der einmalige Test wurde außerdem zu einem frei konfigurierbaren RasterStream ausgebaut. Ein sichtbarer Lauf mit 10 Hz und 50 erfolgreichen Submits endete mit 50 Ready-Ausgaben, 0 Busy und 0 Fehlern bei etwa 9,90 Ready/s. Primary-Textur und Materialbindung blieben dabei persistent.

=== Raster3D mit echten Vertex- und Indexbuffern ===

Der Worker besitzt inzwischen einen kleinen eigenständigen 3D-Rasterpfad mit perspektivischer Kamera, Model-View-Projection-Matrix als Root Constants, D32_FLOAT-Depth-Buffer und Depth-Test. Der finale Testwürfel verwendet 24 POSITION/COLOR-Vertices, 36 <code>uint16</code>-Indices und <code>DrawIndexedInstanced(36,1,0,0,0)</code>; sechs getrennte Seitenfarben machen Ausrichtung und Rotation sichtbar nachvollziehbar.

Die statischen Meshdaten werden einmalig über private Upload-Buffer in DEFAULT-Heaps übertragen. Der Init-Fence wird non-blocking über <code>GetCompletedValue()</code> beobachtet. Der eigentliche Runtime-Renderpfad enthält weiterhin keine CPU-Waits und keine Maps.

=== UE-Static-Meshes auf der Worker-GPU ===

<code>StaticMeshWorker</code> extrahiert echte LOD0-Geometrie aus <code>UStaticMesh</code>-Assets. POSITION und NORMAL sowie <code>uint32</code>-Indices werden in POD-Daten überführt, einmalig asynchron in eigene Worker-VB/IB hochgeladen und anschließend per <code>DrawIndexedInstanced</code> gerendert. Assetpfade sind dynamisch; Auto-Fit richtet Kamera beziehungsweise Modellmaßstab an den Bounds aus.

Sichtbar korrekt getestet wurden:

{| class="wikitable"
! Asset
! Vertices
! Indices
|-
| Sphere
| 559
| 2880
|-
| Cube
| 54
| 144
|-
| Cylinder
| 334
| 1536
|}

=== Multi-Mesh Worker-Szene ===

<code>StaticMeshScene</code> rendert Sphere, Cube und Cylinder gemeinsam in einen Color-/Depth-Frame. Der verifizierte Test umfasst insgesamt 947 Vertices und 4560 Indices, drei <code>DrawIndexedInstanced</code>-Aufrufe und nur einen anschließenden Cross-Adapter-/Normal-SafeCopy-Transfer. Damit ist nicht mehr nur ein synthetisches Primitive, sondern mehrere echte UE-Meshes mit gemeinsamer Tiefenprüfung im Worker-Frame sichtbar nachgewiesen.

=== WorldStaticMeshScene ===

<code>ExperimentalMultiGPUWorldStaticMeshScene.cpp</code> sammelt im Engine-Layer bis zu acht sichtbare <code>UStaticMeshComponent</code>s von Actors mit dem Tag <code>MultiGPUWorker</code>. Meshdaten und World-Transforms werden im Game Thread in reine POD-Strukturen und 4×4-Matrizen kopiert. D3D12RHI erhält keine <code>UObject</code>-Pointer. Mehrere Instanzen desselben Meshes teilen den persistenten Worker-Mesh-Cache und unterscheiden sich nur durch Modelmatrix und Draw Call.

Der Pfad wurde inzwischen sichtbar im PIE-Level verifiziert. Drei getaggte Static-Mesh-Actors erschienen mit ihren tatsächlichen relativen Positionen, Rotationen und Skalierungen im Worker-Bild. Die zentrale Koordinatenumrechnung lautet:

<pre>Worker (X, Y, Z) = (UE Y, UE X, -UE Z)</pre>

Die Transformation besitzt die Determinante +1 und ist damit keine Spiegelung. Das notwendige horizontale Spiegeln erfolgt ausschließlich auf der Presentation-Plane, nicht im Worker-Renderpfad.

=== Kontinuierlicher WorldStaticMeshSceneStream ===

<code>StartWorldStaticMeshSceneStream</code> erfasst die getaggte Szene fortlaufend im Game Thread. Reine Änderungen an Transform oder Kamera lösen keinen erneuten Mesh-Upload aus. Hinzugekommene, entfernte, unsichtbare oder umgetaggte Components werden im nächsten Snapshot berücksichtigt. Single-Slot-Backpressure verhindert einen wachsenden Rückstau.

Ein verifizierter 30-Hz-Lauf endete nach 31,184 Sekunden mit 835 Ticks, 691 angenommenen Submits, 144 Busy, 0 Fehlern und 691 Ready-Frames. Die effektive Ready-Rate betrug 22,16 Hz. Dieser Test belegt die funktionale Live-Aktualisierung; die Rate war noch kein Optimierungsziel.

=== SceneCapture2D als Worker-Kamera ===

<code>TestSceneCaptureStaticMeshScene</code> verwendet eine echte <code>ASceneCapture2D</code> beziehungsweise <code>USceneCaptureComponent2D</code> aus der laufenden PIE-Welt als Kameraquelle. Der empfohlene Editor-Weg ist das Component Tag <code>MultiGPUWorkerCamera</code> auf der <code>CaptureComponent2D</code>; ein gleichnamiges Actor-Tag bleibt nur als Legacy-Fallback.

Ausgelesen werden World Location, Rotation, Forward/Right/Up, <code>FOVAngle</code> und <code>ProjectionType</code>. Orthografische Projektion wird derzeit sauber abgelehnt. Die SceneCapture2D liefert ausschließlich Kameradaten: Ihr UE-RenderTarget wird weder gelesen noch kopiert. Die Intel-Worker-GPU rendert die Geometrie selbst. Kamera und Actors werden gemeinsam mit <code>SceneScale = 0.01</code> in Worker-Koordinaten überführt; Auto-Fit und Scene-Recentering sind in diesem Modus deaktiviert.

Die 128×96-Worker-Projektion verwendet ein Seitenverhältnis von 4:3 und interpretiert <code>FOVAngle</code> als horizontales FOV. Nach den Orientierungstests wird nur die Anzeige über <code>SetRelativeScale3D(FVector(-4.0f, -3.0f, 1.0f))</code> korrigiert; dies entspricht <code>U' = 1-U</code> und <code>V' = 1-V</code>.

=== Live SceneCaptureStaticMeshSceneStream ===

<code>StartSceneCaptureStaticMeshSceneStream</code> liest Kamera-Transform, Kamerabasis, FOV und aktuelle Actor-Transforms pro Snapshot neu im Game Thread. Der Worker erhält weiterhin ausschließlich POD-Daten, verwendet den persistenten Mesh-Cache sowie ein gemeinsames Color- und D32-Depth-Target und führt pro akzeptiertem Frame genau einen Cross-Adapter-/Normal-SafeCopy-Transfer aus.

Der Quiet-Test

<pre>ExperimentalMultiGPU.StartSceneCaptureStaticMeshSceneStream 30 300 quiet</pre>

lieferte in 10,084 Sekunden 301 Ticks, 300 Submits, 1 Busy, 0 Fehler und 300 Ready-Frames. Die effektive Ready-Rate betrug 29,75 Hz. Bewegungen der Kamera und Actors sowie FOV-Änderungen erschienen live auf der Display-Plane. Damit ist erstmals ein kleiner SceneCapture-/CCTV-artiger Worker-Kanal vollständig funktional nachgewiesen.

== Test- und Diagnosebefehle ==

{| class="wikitable"
! Befehl
! Zweck
|-
| <code>ExperimentalMultiGPU.TestComputeShader</code>
| Führt den vollständigen Worker-Compute-Testpfad aus. Er enthält auch ältere Debug- und Regressionstests mit CPU-Readback und ist daher nicht mit dem reinen asynchronen Runtime-Pfad gleichzusetzen.
|-
| <code>ExperimentalMultiGPU.TestTextureConsumer</code>
| Testet <code>TextureConsumerCS</code> auf der Primary-GPU. Die aktuelle Ready-Textur wird über UE-RHI gelesen und anhand ausgewählter Testpixel per Debug-Readback geprüft.
|-
| <code>ExperimentalMultiGPU.TestTextureBridge</code>
| Prüft die Bridge von der fertigen <code>FTextureRHIRef</code> zu <code>UExperimentalMultiGPUTexture</code> und damit den UE- und materialtauglichen Texturpfad.
|-
| <code>ExperimentalMultiGPU.SpawnDisplayActor</code>
| Spawnt den Test-Actor mit Plane im Spiel. Das Material zeigt darauf die vom Worker erzeugte Textur an.
|-
| <code>ExperimentalMultiGPU.TestRasterWorker</code>
| Rasterisiert auf der Worker-GPU ein echtes RGB-Dreieck per Vertex- und Pixel-Shader und transportiert das Ergebnis über den normalen SafeCopy-Pfad bis zum DisplayActor.
|-
| <code>ExperimentalMultiGPU.StartRasterStream</code> / <code>ExperimentalMultiGPU.StopRasterStream</code>
| Startet beziehungsweise stoppt den kontinuierlichen RGB-Dreieck-RasterStream mit frei wählbarer Zielrate, optionalem Submit-Limit und Quiet-Modus.
|-
| <code>ExperimentalMultiGPU.TestRaster3DWorker</code>
| Rendert einmalig den perspektivischen 3D-Testwürfel mit Depth Buffer und echten Vertex-/Indexbuffern.
|-
| <code>ExperimentalMultiGPU.StartRaster3DStream</code> / <code>ExperimentalMultiGPU.StopRaster3DStream</code>
| Startet beziehungsweise stoppt den kontinuierlichen Raster3D-Test.
|-
| <code>ExperimentalMultiGPU.TestStaticMeshWorker [AssetPath]</code>
| Extrahiert und rendert LOD0-Geometrie eines UE-Static-Mesh-Assets; ohne optionalen Pfad wird das konfigurierte Testasset verwendet.
|-
| <code>ExperimentalMultiGPU.TestStaticMeshScene</code>
| Rendert Sphere, Cube und Cylinder gemeinsam mit drei Draw Calls und einem anschließenden Transfer.
|-
| <code>ExperimentalMultiGPU.TestWorldStaticMeshScene</code>
| Rendert einen einmaligen POD-Snapshot der sichtbaren, mit <code>MultiGPUWorker</code> getaggten StaticMeshComponents aus der laufenden World. Der sichtbare PIE-Nachweis ist erfolgreich.
|-
| <code>ExperimentalMultiGPU.StartWorldStaticMeshSceneStream [Hz] [MaxSuccessfulSubmits] [quiet]</code> / <code>StopWorldStaticMeshSceneStream</code>
| Startet beziehungsweise stoppt den kontinuierlichen Stream der getaggten UE-Welt mit Live-Transforms und persistentem Mesh-Cache.
|-
| <code>ExperimentalMultiGPU.TestSceneCaptureStaticMeshScene</code>
| Rendert einen einmaligen Worker-Snapshot aus Sicht der mit <code>MultiGPUWorkerCamera</code> markierten SceneCapture2D-Kamera.
|-
| <code>ExperimentalMultiGPU.StartSceneCaptureStaticMeshSceneStream [Hz] [MaxSuccessfulSubmits] [quiet]</code> / <code>StopSceneCaptureStaticMeshSceneStream</code>
| Startet beziehungsweise stoppt den Live-Worker-Kanal mit fortlaufend aktualisierten Kamera-, FOV- und Actor-Daten.
|-
| <code>ExperimentalMultiGPU.StartTextureStream</code>
| Startet den sichtbaren Normal-Pfad: Worker-Textur → Cross-Adapter-Transfer → SafeCopy → UE-Textur → Material.
|-
| <code>ExperimentalMultiGPU.StopTextureStream</code>
| Verhindert weitere Submits des laufenden Streams. Ein bereits eingereichter GPU-Job darf noch sicher fertig werden.
|-
| <code>ExperimentalMultiGPU.StartQueueProbe</code>
| Startet den Diagnose-Benchmark für Primary-Queue-, Fence- und Submission-Verhalten. Der Probe verändert die sichtbare Textur nicht.
|}

=== Texture Stream ===

Grundsyntax:

<pre>
ExperimentalMultiGPU.StartTextureStream [Hz] [MaxSuccessfulSubmits] [quiet]
</pre>

{| class="wikitable"
! Beispiel
! Wirkung
|-
| <code>ExperimentalMultiGPU.StartTextureStream</code>
| Standardmäßig etwa 5 Hz, ohne Submit-Limit.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 37.5</code>
| Fordert 37,5 Hz ohne Submit-Limit an. Sowohl <code>37.5</code> als auch <code>37,5</code> werden akzeptiert.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 1000 100</code>
| Fordert 1000 Hz an und stoppt nach exakt 100 erfolgreichen Submits.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 1000 100 quiet</code>
| Wie zuvor, unterdrückt aber Per-Job- und Busy-Logspam.
|}

Die Hz-Angabe ist eine '''Ziel- beziehungsweise Request-Frequenz'''. <code>1000</code> bedeutet daher nicht automatisch 1000 fertige Texturen pro Sekunde. Die tatsächliche Rate hängt unter anderem von Timer, Submission, Backpressure, Queue-Latenz und Slot-Lifecycle ab. <code>MaxSuccessfulSubmits</code> zählt nur angenommene Submits; Busy- und Failed-Versuche verbrauchen das Limit nicht.

=== QueueProbe ===

Grundsyntax:

<pre>
ExperimentalMultiGPU.StartQueueProbe <Hz> <MaxSubmits> [quiet] [Mode] [Queue]
</pre>

{| class="wikitable"
! Modus
! Ausgeführter Pfad
|-
| <code>full</code>
| Worker Compute → Cross-Adapter-Transfer → Primary Wait → Copy → Completion Fence.
|-
| <code>waitonly</code>
| Worker Compute → Cross-Adapter-Transfer → Primary wartet auf WorkerReadyFence → Completion Fence. Es findet keine Texturkopie statt.
|-
| <code>signalonly</code>
| Keine Textur, kein Worker-Wait und keine Kopie; nur Queue und Fence. Dieser Modus isoliert das Queue-Verhalten.
|-
| <code>commandonly</code>
| Reicht eine leere echte Worker-Command-List ein und trennt Command-Submission von GPU-Arbeit.
|-
| <code>barrieronly</code> / <code>barrierprivate</code>
| Isoliert Resource-Barriers auf Worker-Ressourcen beziehungsweise einer privaten Testtextur.
|-
| <code>copybuffer</code>
| Führt eine minimale echte <code>CopyBufferRegion</code>-Operation über 256 Byte aus.
|}

{| class="wikitable"
! Queue
! Bedeutung
|-
| <code>graphics</code>
| Vorhandene UE Primary Graphics-/Direct-Queue über <code>RHIRunOnQueue</code>.
|-
| <code>copy</code>
| Vorhandene UE Primary Copy Queue über <code>RHIRunOnQueue</code>.
|-
| <code>native</code>
| Vollständig private native D3D12-DIRECT-Queue auf der Primary; reine Diagnose, kein fertiger Experimental-Modus.
|-
| <code>worker</code>
| Vorhandene native Worker-DIRECT-Queue.
|-
| <code>worker-copy</code>
| Separate native Worker-COPY-Queue.
|-
| <code>worker-high</code>
| Separate Worker-DIRECT-Queue mit hoher Priorität.
|}

Typische Beispiele:

<pre>
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet full graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet waitonly graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly copy
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly native
</pre>

Der letzte Befehl ist aktuell die wichtigste isolierte Gegenprobe. Mit der privaten nativen Queue wurde bei 30 FPS eine durchschnittliche Latenz <code>primaryExecuteToReadyAvgMs = 0.014 ms</code> gemessen.

=== Benchmark-CVars ===

{| class="wikitable"
! CVar
! Zweck
|-
| <code>r.VSync 0</code>
| Deaktiviert VSync, damit es die Messung nicht begrenzt.
|-
| <code>t.MaxFPS 30</code> <code>t.MaxFPS 60</code> <code>t.MaxFPS 120</code>
| Setzt die Engine-Framerate für reproduzierbare Frame-Coupling-Tests.
|-
| <code>t.MaxFPS 0</code>
| Entfernt das normale <code>t.MaxFPS</code>-Limit. Dieser Lauf ist als zusätzliche Diagnose-Gegenprobe vorgesehen.
|}

== Aktueller nächster Schritt ==

Der Live-SceneCapture-Kanal ist funktional nachgewiesen. Als nächstes soll die feste 128×96-Ausgabe durch eine konfigurierbare Capture-Auflösung ersetzt werden. Danach folgt ein erster echter Nutzlast-Proof als CCTV, Spiegel oder Minimap. Parallel bleiben mehrere Mesh-Sections, Material-/Textur-Bindings und späteres Culling offen. QueueProbe bleibt ein Diagnosewerkzeug; Experimental/Direct, Nanite, Lumen und automatische Workload-Verteilung sind spätere eigenständige Ausbaustufen.

== Historische Vorläufer ==

Die Grundidee heterogener Multi-GPU-Nutzung ist nicht neu. Bereits mit der Einführung von Direct3D 12 entstanden mehrere Versuche, integrierte und dedizierte GPUs gemeinsam zu verwenden. Eine allgemein einsetzbare Lösung für moderne UE5-Spiele hat sich daraus jedoch nicht entwickelt.

=== Microsoft und Epic: UE4 Elemental Demo (2015) ===

Microsoft zeigte eine angepasste Unreal-Engine-4-Version der Elemental-Demo, bei der eine NVIDIA-GPU und eine Intel-iGPU gemeinsam arbeiteten. Das erklärte Ziel war, ansonsten ungenutzte Grafikleistung in Hybrid-Systemen zu verwenden. Dieser Versuch ist der Grundidee des Projekts besonders ähnlich, blieb aber eine technische Demonstration.

=== Intel: D3D12 Multi-Adapter Sample (2015) ===

Intels Beispiel kombinierte eine GeForce 840M mit Intel HD Graphics 5500. Beide GPUs berechneten getrennte Teile einer einfach parallelisierbaren Raytracing-Szene. Cross-Adapter-Ressourcen und Shared Fences führten die Ergebnisse anschließend zusammen. Intel berichtete in diesem Test von nahezu halbierter Framezeit, warnte jedoch ausdrücklich davor, das Ergebnis unmittelbar auf reale Spiele zu übertragen.

=== Ashes of the Singularity ===

Die Nitrous Engine von ''Ashes of the Singularity'' setzte Direct3D-12-Explicit-Multiadapter in einem veröffentlichten Spiel ein. Dabei konnten auch unterschiedliche GPU-Modelle und Hersteller zusammenarbeiten. Das war ein wichtiger Praxisnachweis, blieb in der Spielebranche aber eine seltene Ausnahme.

=== Weitere verwandte Ansätze ===

* ''Rise of the Tomb Raider'' erhielt explizite Direct3D-12-Multi-GPU-Unterstützung, vor allem für klassische Kombinationen ähnlicher GPUs.
* NVIDIA VR SLI wies bei Virtual Reality jeder GPU ein Auge zu. Das verteilt unabhängige Ansichten, bleibt jedoch NVIDIA-spezifisch.
* Unreal nDisplay kann Viewports oder Frustums auf weitere GPUs beziehungsweise Prozesse auslagern und das fertige Bild zur Ausgabe-GPU zurückführen. Der Einsatzbereich ist hauptsächlich Virtual Production.
* Forschung und High-Performance Computing verwenden seit Jahren Scheduler für heterogene GPUs, allerdings überwiegend für Compute- und Datenverarbeitungsaufgaben statt für einen allgemeinen UE5-Echtzeitrenderer.

=== Abgrenzung dieses Projekts ===

Das Projekt erfindet Direct3D-12-Explicit-Multiadapter nicht neu. Sein eigener Ansatz liegt in der Kombination aus tiefer UE5.8-RHI-Integration, UE-kompilierten Shadern auf unabhängigen Worker-Devices, frei wählbaren Spiel- und Compute-Workloads, Capability- und Performance-Scheduler, mehreren Fallback-Pfaden sowie dem langfristigen Ziel beliebiger Hersteller und mehrerer Worker.

== Vergleich mit anderen Multi-GPU-Verfahren ==

{| class="wikitable"
! Verfahren
! Arbeitsweise
! Verhältnis zu diesem Projekt
|-
| SLI / CrossFire
| Treiber- beziehungsweise Verbundlösung für meist ähnliche GPUs; häufig wird die Bildarbeit verteilt.
| Dieses Projekt benötigt keinen herstellerspezifischen GPU-Verbund und weist Aufgaben ausdrücklich selbst zu.
|-
| AFR (Alternate Frame Rendering)
| GPU 1 rendert einen Frame, GPU 2 den nächsten.
| Das Projekt verteilt unabhängige Aufgaben statt aufeinanderfolgender Frames. Dadurch werden Frame-Abhängigkeiten und typisches AFR-Pacing vermieden.
|-
| SFR (Split Frame Rendering)
| Mehrere GPUs bearbeiten Bereiche desselben Frames.
| Erfordert enge Lastverteilung und viel Datenaustausch. Das Projekt bevorzugt vollständig abgrenzbare Workloads und überträgt deren Ergebnis.
|-
| Direct3D 12 Linked Multiadapter
| Mehrere vom Treiber verbundene GPUs erscheinen als Knoten eines logischen Adapters.
| Eignet sich eher für eng kompatible GPUs. Das Projekt verwendet unabhängige Devices (Unlinked/Explicit Multiadapter) und unterstützt dadurch heterogene Herstellerkombinationen.
|-
| Direct3D 12 Unlinked / Explicit Multiadapter
| Die Anwendung verwaltet getrennte Adapter, Ressourcen und Synchronisation selbst.
| Das ist die technische Familie des Projekts. Hinzu kommen die eigene UE5-RHI-Integration, Workload-Ziele, Fallbacks und der geplante Scheduler.
|-
| UE nDisplay mGPU / Multi-Process
| Separate GPUs rendern bestimmte Viewports oder Frustums, vor allem für Virtual Production; Ergebnisse werden zur Ausgabe-GPU kopiert.
| Ähnliche Idee der aufgabenweisen Trennung, aber für einen anderen Einsatzbereich. Dieses Projekt zielt auf allgemeine Spiel- und Compute-Workloads innerhalb der Engine.
|-
| Vulkan Device Groups
| Ähnliche physische GPUs können ein gemeinsames logisches Device bilden.
| Für beliebige heterogene GPUs meist ungeeignet, da Geräte einer Gruppe nahezu gleiche Eigenschaften besitzen müssen. Eine spätere Vulkan-Portierung benötigt daher wahrscheinlich getrennte Devices und External Memory/Semaphores.
|}

SLI und CrossFire bezeichnen den Verbund; AFR und SFR beschreiben mögliche Verteilungsmethoden innerhalb solcher Systeme. Sie sind deshalb nicht vollständig getrennte Kategorien.

== Vorteile der geplanten Variante ==

* '''Herstellerunabhängig:''' NVIDIA, AMD und Intel können grundsätzlich kombiniert werden.
* '''Vorhandene Hardware nutzen:''' Auch eine sonst wenig genutzte integrierte GPU kann geeignete Nebenaufgaben übernehmen.
* '''Aufgaben statt Frames verteilen:''' Spiegel, Minimap oder Compute können mit eigener Auflösung und Aktualisierungsrate laufen.
* '''Keine identischen GPUs erforderlich:''' Unterschiedliche Fähigkeiten können gezielt genutzt werden.
* '''Kontrollierter Datenaustausch:''' Nur das benötigte Ergebnis muss zurück zur Primary-GPU.
* '''Robuste Fallback-Idee:''' Wenn direkte Texturen nicht gemeinsam nutzbar sind, bleibt der Shared-Buffer-Pfad.
* '''Erweiterbar:''' Scheduler, manuelles Mapping und mehrere Worker sind als spätere Stufen vorgesehen.

== Nachteile und technische Risiken ==

* '''Hoher Entwicklungsaufwand:''' Geräte, Ressourcen, Zustände, Fences, Fehlerfälle und UE-Lebenszyklen müssen selbst verwaltet werden.
* '''Transfer kann den Gewinn aufzehren:''' Cross-Adapter Heaps liegen laut D3D12 nicht automatisch im schnellen lokalen VRAM. Bandbreite und Latenz müssen für jeden Workload gemessen werden.
* '''VRAM wird nicht einfach addiert:''' Benötigte Ressourcen können auf mehreren GPUs vorliegen und zusätzlichen Speicher verbrauchen.
* '''Langsame Worker können bremsen:''' Eine Aufgabe lohnt sich nur, wenn Rechengewinn größer als Übergabe-, Warte- und Kopierkosten ist.
* '''Nicht jeder Workload ist unabhängig:''' Hauptansicht, Lumen, Nanite und stark gekoppelte Renderpässe besitzen viele Abhängigkeiten und sind schwieriger auszulagern.
* '''Hardwareunterschiede:''' Formate, Shader-Funktionen, Queue-Fähigkeiten und Cross-Adapter-Support müssen pro GPU geprüft werden.
* '''Wartungsrisiko:''' Eingriffe in private D3D12RHI-Dateien können bei Engine-Updates angepasst werden müssen.
* '''Produktionsreife fehlt noch:''' Ressourcenpools, Timeouts, Device-Lost-Wiederherstellung, Scheduler und echte Szenentests sind offen.

== Wann die Variante sinnvoll ist ==

Am aussichtsreichsten sind Aufgaben mit viel eigener Rechenarbeit, einem relativ kleinen Endergebnis und wenigen Abhängigkeiten zur Hauptszene. Gute frühe Kandidaten sind unabhängige Compute-Aufgaben sowie Scene Captures, die nicht in jedem Frame aktualisiert werden müssen. Weniger geeignet sind winzige Aufgaben mit großem Transfer oder Renderpässe, die ständig auf Ressourcen der Primary-GPU zugreifen.

Die entscheidende Regel für den späteren Scheduler lautet daher:

<pre>
Worker-Gewinn > Vorbereitung + Datentransfer + Synchronisation + Rückintegration
</pre>

== Bekannte Grenzen des Proof of Concepts ==

* Der asynchrone 128×96-End-to-End-Pfad ist über Dimensionen, Dispatch, Transfer, Fences, Pending/Ready und Reuse verifiziert; ein eigener 128×96-Pixel-Readback fehlt noch. Der synchrone 64×64-Debugtest prüft weiterhin alle 4096 Pixel.
* Der sichtbare Worker-Output ist derzeit auf 128×96 Pixel in <code>DXGI_FORMAT_R8G8B8A8_UNORM</code> mit Sample Count 1 begrenzt. Konfigurierbare Auflösung, weitere Formate, Mips, Arrays, Slices und MSAA sind offen.
* Pro Worker existiert absichtlich nur ein persistenter Runtime-Slot. Mehrere parallele In-Flight-Jobs sowie Double-, Triple- oder Ring-Buffering fehlen noch.
* Die Primary-/SafeCopy-/Ready-Kette bleibt trotz zusätzlichem non-blocking <code>DispatchToRHIThread</code> effektiv an den Frame-/Submission-Zyklus gekoppelt.
* 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.
* QueueProbe ist reine Diagnose. Private native Queues sind noch kein Experimental-/Direct-Modus und beschreiben keine UE-eigene sichtbare Textur.
* Es gibt noch keine Umschaltung zwischen Normal und Experimental sowie keinen automatischen Session-Fallback.
* Raw-D3D12-Shared-Ressourcen sind noch nicht vollständig in Unreals Residency-Management eingebunden.
* Praktisch getestet ist Primary plus ein Worker. Die Architektur ist auf mehrere Worker ausgelegt, N-GPU ist aber noch nicht praktisch validiert.
* Raster3D, einzelne UE-Static-Meshes, die Drei-Mesh-Szene sowie WorldStaticMeshScene sind sichtbar nachgewiesen. World- und SceneCapture-Pfade besitzen inzwischen laufende Streams; pro Snapshot werden weiterhin höchstens acht sichtbare StaticMeshComponents verarbeitet.
* Der Worker übernimmt weiterhin nur LOD0-POSITION/NORMAL-Daten und Indices. Materialien, Texturen, Mesh-Sections, Beleuchtung, Schatten, Skeletal Meshes, Nanite, Lumen sowie Frustum-/Occlusion-Culling fehlen. Für Cooked/Shipping muss der Zugriff auf benötigte Geometrie über einen eigenen Cache oder Build-Schritt abgesichert werden.
* 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 von Commit <code>0719998</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.

== Roadmap ==

# Worker-Target und Transport auf frei wählbare SceneCapture-Auflösungen erweitern.
# CCTV, Spiegel oder Minimap als ersten realen, unabhängigen Worker-Workload umsetzen.
# Mehrere Mesh-Sections, Material-/Textur-Bindings und später Culling ergänzen, ohne die POD-/Worker-Trennung aufzugeben.
# D3D12-Adapter-, Raster- und SceneCapture-Pfade auf der Intel Arc A380 und später mit RX 6900 XT als Primary gegenprüfen.
# Microbenchmarks und reale Workloads zu einem Benchmark-/Autotuner ausbauen, der den Netto-Nutzen pro GPU-Paar bewertet.
# Nach Portierung des eigentlichen Projekts schwere UE-Demos wie Electric Dreams und später Lumen in the Land of Nanite als Stresstest verwenden.
# Einen Multi-Tier Resource Manager für Primary-VRAM, Worker-VRAM und RAM mit Cache, Prefetch und Duplizierung untersuchen; dies ist keine transparente gemeinsame Hardware-VRAM-Lösung.
# Experimental-/Direct nur mit State-Tracking, Residency, Queue-Reihenfolge, Capability-Selbsttest und Session-Fallback auf Normal entwickeln.
# Weitere Runtime-Slots oder Ringbuffer erst bei echtem Bedarf und mit gelöstem Generation-, Fence-, Reuse- und Consumer-Hazard-Modell ergänzen.
# Capability-Matrix, Scheduler, manuelle Overrides und mehrere Worker-GPUs entwickeln.
# Linux/Vulkan mit getrennten Devices, External Memory und externer Synchronisation untersuchen.

== Git-Checkpoint ==

Der 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. Der Engine-Working-Tree war nach dem Commit sauber; ein Push erfolgte nicht.

== Quellen ==

* Interner Entwicklungsstand und verifizierte Testprotokolle vom 10. September 2026; Commit <code>45d5c27</code>. WorldStaticMeshScene, WorldStaticMeshSceneStream und der SceneCaptureStaticMeshSceneStream sind sichtbar im PIE-Level getestet.
* [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/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://www.intel.com/content/dam/develop/external/us/en/documents/multi-adapter-support-in-directx-12-594015.pdf Intel: Multi-Adapter Support in DirectX 12]
* [https://devblogs.microsoft.com/directx/ashes-of-the-singularity-makes-gaming-history-with-directx-12/ Microsoft: Ashes of the Singularity und heterogene Adapter]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/nvidia-sli-alternative-frame-rendering-in-unreal-engine Epic: NVIDIA SLI Alternate Frame Rendering]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/multi-process-rendering-with-unreal-engine Epic: Multi-Process Rendering]
* [https://registry.khronos.org/vulkan/specs/latest/pdf/vkspec.pdf Khronos: Vulkan Specification – Device Groups]

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Multi-GPU]]
[[Kategorie:Direct3D 12]]
[[Kategorie:Experimentell]]

Seitliches Rutschen nach dem Sprint beheben

2026-09-09T23:49:49Z

Elaina: Die Seite wurde neu angelegt: „Beim Wechsel vom Sprint zurück zur normalen Laufgeschwindigkeit kann ein Charakter in Kurven kurz seitlich über den Boden rutschen. Diese Anleitung zeigt, wie sich die Bewegungsrichtung während des Abbremsens korrigieren lässt, ohne Sprünge oder die Schwerkraft zu beeinflussen. == Das Problem == Im beschriebenen Blueprint wird die Laufgeschwindigkeit mit einer Timeline weich verändert: * normale Laufgeschwindigkeit: <code>500 cm/s</code> * Sprint…“

Beim Wechsel vom Sprint zurück zur normalen Laufgeschwindigkeit kann ein Charakter in Kurven kurz seitlich über den Boden rutschen. Diese Anleitung zeigt, wie sich die Bewegungsrichtung während des Abbremsens korrigieren lässt, ohne Sprünge oder die Schwerkraft zu beeinflussen.

== Das Problem ==

Im beschriebenen Blueprint wird die Laufgeschwindigkeit mit einer Timeline weich verändert:

* normale Laufgeschwindigkeit: <code>500 cm/s</code>
* Sprintgeschwindigkeit: <code>820 cm/s</code>
* Abbremszeit: <code>1 Sekunde</code>

Geradeaus fällt der Fehler kaum auf. Wird die Sprinttaste jedoch während einer Kurve losgelassen, zeigt der Character bereits in die neue Richtung, während seine tatsächliche [[Vector|Velocity]] noch einen seitlichen Anteil aus der alten Bewegungsrichtung besitzt. Dadurch entsteht ein sichtbarer Drift- oder „Eislauf“-Effekt.

Die Timeline ist dabei nicht die eigentliche Ursache. Sie verlängert den Übergang lediglich und macht den Richtungsunterschied deutlicher sichtbar.

== Ursache mit Debug-Pfeilen prüfen ==

Zum Prüfen können zwei Debug-Pfeile gezeichnet werden:

* '''Rot:''' <code>Get Velocity</code> – die tatsächliche Bewegungsrichtung.
* '''Grün:''' <code>Get Actor Forward Vector</code> – die Blick- beziehungsweise Vorwärtsrichtung des Characters.

Tritt der Fehler auf, zeigt der grüne Pfeil bereits in die Kurve, während der rote Pfeil noch schräg in die vorherige Richtung weist. Damit lässt sich erkennen, dass es sich nicht nur um ein Animationsproblem handelt.

== Lösung im Blueprint ==

Die horizontale Geschwindigkeit bleibt erhalten, ihre Richtung wird während der Abbrems-Timeline jedoch auf die Vorwärtsrichtung des Characters ausgerichtet.

=== 1. Horizontale Geschwindigkeit ermitteln ===

# Eine Referenz auf den '''Character''' verwenden. Nicht die Velocity des Player Controllers abfragen.
# Am Character <code>Get Velocity</code> aufrufen.
# Das Ergebnis mit <code>Vector Length XY</code> verbinden.

<code>Vector Length XY</code> liefert die aktuelle Geschwindigkeit auf der X/Y-Ebene als Float. Die vertikale Z-Bewegung wird dabei nicht in den Geschwindigkeitsbetrag eingerechnet.

=== 2. Neue Bewegungsrichtung berechnen ===

# Am Character <code>Get Actor Forward Vector</code> aufrufen.
# Den von <code>Vector Length XY</code> ausgegebenen Speed mit <code>Make Vector</code> zu <code>(Speed, Speed, Speed)</code> zusammensetzen.
# <code>Get Actor Forward Vector</code> mit diesem Vector multiplizieren.

Der beschriebene Blueprint verwendet dafür einen als <code>Vector × Vector</code> typisierten Multiply-Node. Bei einem passend typisierten <code>Vector × Float</code>-Node kann der Float auch direkt als Faktor verwendet werden.

Die Berechnung lautet:

<pre>Neue Velocity = Actor Forward Vector × aktuelle XY-Geschwindigkeit</pre>

Beispiel:

<pre>Speed = 735 cm/s
Forward = (0.80, 0.60, 0.00)
Velocity ≈ (588, 441, 0) cm/s</pre>

Die Geschwindigkeit bleibt dadurch gleich, aber der seitliche Anteil relativ zur Charakterausrichtung verschwindet.

=== 3. Velocity nur am Boden setzen ===

# <code>Get Character Movement</code> aufrufen.
# Vom Character Movement Component <code>Is Moving on Ground</code> abfragen.
# Zwischen <code>Update</code> der Abbrems-Timeline und <code>Set Velocity</code> einen [[Boolean#Branch|Branch]] setzen.
# <code>Is Moving on Ground</code> mit der <code>Condition</code> des Branch verbinden.
# Nur den Ausgang <code>True</code> mit <code>Set Velocity</code> verbinden. <code>False</code> bleibt leer.
# Das Ergebnis der Richtungsberechnung an <code>New Velocity</code> von <code>Set Velocity</code> anschließen.

Der vollständige Ablauf sieht vereinfacht so aus:

<pre>DATEN:
Get Velocity → Vector Length XY → Make Vector(Speed, Speed, Speed)
Get Actor Forward Vector ────────────────┐
├→ Multiply → Set Velocity (New Velocity)
Make Vector ─────────────────────────────┘

AUSFÜHRUNG:
Timeline Update → Branch → True → Set Velocity
Is Moving on Ground ─────→ Condition
False → keine Aktion</pre>

== Warum die Bodenprüfung wichtig ist ==

Der neu berechnete Forward Vector besitzt in diesem Fall einen Z-Wert von <code>0</code>. Würde <code>Set Velocity</code> auch in der Luft bei jedem Timeline-Update ausgeführt, würde die vertikale Geschwindigkeit ständig auf null gesetzt. Der Character könnte dann kurz schweben, weil Character Movement und Schwerkraft keine normale Fallgeschwindigkeit aufbauen können.

Die Abfrage <code>Is Moving on Ground</code> begrenzt den Fix deshalb auf das Laufen am Boden:

* <code>True</code>: Richtungsanpassung ausführen.
* <code>False</code>: nichts setzen; Sprung, Fallbewegung und Schwerkraft bleiben vollständig beim Character Movement Component.

== Einstellungen des getesteten Setups ==

Der Fix wurde mit folgenden Ausgangswerten getestet:

{| class="wikitable"
! Einstellung
! Wert
|-
| <code>Ground Friction</code>
| <code>8.0</code>
|-
| <code>Max Acceleration</code>
| <code>1500</code>
|-
| <code>Braking Deceleration Walking</code>
| <code>2000</code>
|-
| <code>Braking Friction Factor</code>
| <code>1.0</code>
|-
| <code>Use Separate Braking Friction</code>
| aktiviert
|-
| <code>Braking Friction</code>
| <code>0</code>
|-
| <code>Orient Rotation to Movement</code>
| aktiviert
|-
| <code>Rotation Rate Z</code>
| <code>360°/s</code>
|}

Änderungen an <code>Braking Friction</code>, <code>Braking Deceleration Walking</code> und <code>Rotation Rate</code> allein haben den Fehler im getesteten Projekt nicht beseitigt.

== Testen ==

Nach dem Umbau sollten diese Fälle einzeln geprüft werden:

# Normal laufen und enge Kurven drehen.
# Sprint starten und bereits während des Sprints lenken.
# Die Sprinttaste in einem weiten und anschließend in einem engen Bogen loslassen. Der Character darf nicht mehr seitlich rutschen.
# Den roten Velocity-Pfeil mit dem grünen Forward-Pfeil vergleichen. Während der Korrektur am Boden sollten beide nahezu dieselbe Richtung anzeigen.
# Während des Abbremsens springen oder über ein Objekt laufen. Flugbahn und Schwerkraft müssen normal bleiben.

Im dokumentierten Projekt wurden Kurvendrift und Schweben mit diesen Tests behoben.

== Grenzen und mögliche Nebenwirkungen ==

* Die Korrektur ist bewusst nur für Bodenbewegung gedacht. Sie sollte nicht ungeprüft für <code>Falling</code>, <code>Swimming</code> oder <code>Flying</code> übernommen werden.
* <code>Set Velocity</code> kann gleichzeitig aktive Effekte wie Knockback, Dash, externe Kräfte oder Root Motion überschreiben.
* Für Multiplayer und Dedicated Server müssen Replikation und Movement Prediction gesondert auf Client und Server getestet werden.
* Bei größerer Spiellogik empfiehlt es sich, die Berechnung aus dem Player Controller in eine eigene Character-Funktion auszulagern.
* Nach erfolgreichem Test können die Debug-Pfeile entfernt oder über eine Debug-Variable ein- und ausgeschaltet werden.

== Kurzfassung ==

Während die Sprint-Timeline abbremst, wird die aktuelle horizontale Geschwindigkeit auf <code>Actor Forward</code> ausgerichtet. Ein Branch mit <code>Is Moving on Ground</code> verhindert, dass <code>Set Velocity</code> in der Luft die Fallgeschwindigkeit löscht. So folgt der Character Kurven sauber, während Sprünge und Schwerkraft unverändert funktionieren.

== Quellen ==

* Projektinterne Bugfix-Dokumentation: „UE5.8 Bugfix – Seitliches Rutschen beim Abbremsen in Kurven“, Stand 09.09.2026.
* [https://dev.epicgames.com/documentation/unreal-engine/API/Runtime/Engine/UCharacterMovementComponent UCharacterMovementComponent]
* [https://dev.epicgames.com/documentation/unreal-engine/BlueprintAPI/AI/Components/NavMovement/IsMovingonGround Is Moving on Ground]
* [https://dev.epicgames.com/documentation/unreal-engine/API/Runtime/Engine/UMovementComponent UMovementComponent und Velocity]
* [https://dev.epicgames.com/documentation/unreal-engine/movement-components-in-unreal-engine Movement Components]
* [https://dev.epicgames.com/documentation/unreal-engine/understanding-networked-movement-in-the-character-movement-component-for-unreal-engine Networked Character Movement]

[[Category:Blueprint]]
[[Category:Character Movement]]
[[Category:Tutorial]]
[[Category:Bugfix]]

UE5 Heterogeneous Multi-GPU

2026-09-08T11:07:35Z

Elaina:

{{Hinweis|Projektstand: 8. September 2026. Letzter Commit: <code>0719998</code>; RasterStream, Raster3D, StaticMeshWorker, StaticMeshScene und WorldStaticMeshScene liegen danach noch uncommitted im lokalen Working Tree. 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.

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.

{| class="wikitable"
|+ Projektstatus
|-
! Engine / Plattform
| Unreal Engine 5.8 Source Build / Windows / Direct3D 12
|-
! Testsystem
| Lenovo LOQ 17IRX10
|-
! Primary
| NVIDIA GeForce RTX 5060 Laptop GPU
|-
! Worker
| Intel UHD Graphics
|-
! Zusätzliche Testhardware
| Intel Arc A380 vorhanden; separater Worker-Test wartet auf das passende Stromkabel
|-
! Git-Stand
| Basis-Commit <code>0719998</code> auf Branch <code>mgpu-experimental</code> plus uncommitted Working Tree
|-
! Windows/D3D12-Proof-of-Concept
| Sichtbarer 128×96-Worker-Texture-Stream, isolierte Queue-/Scheduling-Diagnose sowie kleiner Worker-Renderer mit Raster3D, Depth Buffer, echten UE-Static-Meshes und mehreren Draw Calls nachgewiesen
|-
! Gesamtvision
| etwa 30–35 % (Scheduler, echte Workloads, N-GPU und Vulkan noch offen)
|}

== Grundprinzip ==

<pre>
Intel Worker GPU
-> MainTextureCS + PatternPhase
-> persistente Worker-Textur
-> persistenter Shared Cross-Adapter Buffer
-> monotone Shared Fence / Queue Wait
-> persistente UE-eigene FTextureRHIRef
-> stabile UExperimentalMultiGPUTexture

RTX Primary GPU
-> normales UE5-Rendering
-> TPS-Material zeigt das Worker-Ergebnis sichtbar an
</pre>

Pro Worker ist maximal ein Runtime-Job gleichzeitig in flight. Backpressure lehnt weitere Requests als <code>Busy</code> ab, bis der Slot nach der Primary-Completion wieder sicher verwendbar ist.

Jeder Worker besitzt ein eigenes <code>ID3D12Device</code>, eigene Queues, Command Lists und Ressourcen. Ein späterer Scheduler soll Rechenleistung, Fähigkeiten, Transferkosten und gewünschte Aktualisierungsrate bewerten. Vorgesehene Aufgaben sind beispielsweise SceneCapture2D, Spiegel, CCTV, Minimap, Compute oder Niagara.

== Verifizierter Entwicklungsstand ==

=== Worker-Compute ===

Ein echter, von Unreal kompilierter Global Compute Shader läuft auf der Intel UHD, während Unreal regulär über die RTX rendert. Der Test verdoppelt 64 Ganzzahlen auf dem Worker; '''64 von 64 Ergebnissen wurden korrekt verifiziert'''. Damit ist echte GPU-Arbeit auf einem zweiten, herstellerfremden Device nachgewiesen.

Zusätzlich läuft <code>MainTextureCS</code> auf der Intel-GPU. Der synchrone Debugtest erzeugt eine 64 × 64 Pixel große RGBA8-Textur; '''alle 4096 shader-generierten Pixel wurden korrekt verifiziert'''. Der normale Runtime-Pfad verwendet inzwischen einen asynchronen 128×96-Test. Der Shader liest seine Dimensionen mit <code>GetDimensions()</code>, schützt überhängende Threads durch einen Bounds-Check und wird mit <code>Dispatch(16,12,1)</code> ausgeführt. <code>PatternPhase</code> erzeugt für jeden akzeptierten Submit deterministisch einen neuen sichtbaren Inhalt. Abgewiesene Busy-Requests erhöhen die Phase nicht und erzeugen daher keine Lücken.

=== Cross-Adapter-Speicher und Synchronisation ===

* RTX und Intel öffnen denselben D3D12 Cross-Adapter Heap.
* Ein gemeinsamer Buffer wurde mit 64 Testwerten erfolgreich geprüft.
* Ein persistenter Shared Fence synchronisiert die Queues direkt von GPU zu GPU. Seine Werte steigen pro Job monoton: WorkerReady/PrimaryComplete verwenden die Paare 1/2, 3/4, 5/6 und so weiter.
* Die CPU vermittelt die GPU-Abhängigkeit nicht; Worker- und Primary-Queue verwenden <code>Signal</code> und <code>Wait</code> direkt auf der GPU.
* Der separate Readback-Verifikationstest darf weiterhin blockieren. Der normale Runtime-Pfad wartet dagegen nicht auf GPU-Leerlauf.

=== Texturtransport ===

Direkte Cross-Adapter-Texturen sind auf dem Testsystem nicht beidseitig verfügbar: Die Intel UHD meldet Unterstützung für Row-Major Cross-Adapter Textures, die RTX 5060 Laptop GPU nicht. Deshalb verwendet das Projekt einen allgemeineren Buffer-Fallback.

<pre>
Intel MainTextureCS
-> persistente Worker-Textur
-> CopyTextureRegion
-> persistenter Shared Cross-Adapter Buffer
-> Worker signalisiert WorkerReady (1, 3, 5, ...)
-> UE-Primary-Queue wartet auf WorkerReady
-> direkte Kopie in persistente UE-eigene FTextureRHIRef
-> Primary signalisiert PrimaryComplete (2, 4, 6, ...)
</pre>

Der robuste Normal-Pfad kopiert die Worker-Textur über den Shared Buffer direkt in eine von Unreal erzeugte <code>FTextureRHIRef</code>. Breite, Höhe und Row Pitch werden dynamisch aus Worker-Ressource und Transport-Metadaten übernommen. Der erfolgreiche 128×96-RGBA8-Test verwendet 512 Byte Row Pitch und 49.152 Byte Transfergröße. Die Output Registry trennt Persistent-, Pending- und Ready-Zustände sowie Inhaltsgeneration und Texturidentität. Dadurch kann eine verspätete Completion keinen neueren Output zurückrollen.

=== Non-blocking Runtime-Pfad ===

Die produktive Testlogik ist aus dem Konsolenkommando in eine gekapselte NormalPath-API verschoben. <code>SubmitWorkerTextureComputeJob()</code> reicht den Worker-Dispatch ohne CPU-Wait ein. <code>QueueNormalTextureTransfer()</code> reiht Wait, Kopie und Completion-Signal in Unreals D3D12-Kontext ein. Der normale MainTextureCS-Pfad enthält weder CPU-Fence-Waits noch Readback, <code>Map</code> oder Pixelvergleich. <code>TickNormalTextureTransfers()</code> prüft die Primary-Completion non-blocking über einen Runtime-Pump; <code>RHIEndFrame()</code> bleibt als Fallback erhalten.

Eine passende Primary-<code>FTextureRHIRef</code> wird pro Worker und Konfiguration persistent gehalten. Nach PrimaryComplete kann der nächste Job dieselbe Resource erneut verwenden; dabei führt Unreal die Übergänge <code>SRVMask -> CopyDest -> SRVMask</code> aus. Eine backend-neutrale RHI-Provider-API reicht die Ready-Textur an die Engine weiter. <code>UExperimentalMultiGPUTexture</code> hält eine stabile <code>UTexture</code> samt TextureReference und bindet die persistente <code>FTextureRHIRef</code> ohne zusätzlichen Pixel-Copy. Eine native D3D12-Resource wird weiterhin nicht blind als UE-Textur gewrappt, weil Unreals Resource-State-Buchhaltung den tatsächlichen nativen Zustand sonst nicht sicher kennt.

=== Sichtbarer TPS-Consumer ===

<code>AExperimentalMultiGPUDisplayActor</code> zeigt die Worker-Ausgabe im Third-Person-Testlevel über den Materialparameter <code>MultiGPUTexture</code> an. Damit ist der Output nicht mehr nur über Logs oder Readback nachgewiesen: Die Intel UHD erzeugt fortlaufend die Texturinhalte, während die RTX die Spielwelt und das Material rendert. <code>TextureConsumerCS</code> kann Ready-Ausgaben auf der Primary zusätzlich als SRV lesen und fünf quantisierte Samples im Debugpfad prüfen.

=== Lebensdauer und automatisches Cleanup ===

Der Normal-Pfad verwendet pro Worker genau einen persistenten Runtime-Slot. Worker-Textur, Root Signature, PSO, Descriptor Heap, Command Allocator/List und Worker-Fence werden nach der ersten kompatiblen Initialisierung wiederverwendet. Dasselbe gilt für Shared Heap/Buffer/Fence und die Transport-Command-Objekte. Der In-Flight-Job trägt nur noch die nötigen Job-, Generation- und Fence-Metadaten.

<pre>
Runtime Request
-> Completion non-blocking prüfen
-> falls Slot frei: Worker Dispatch
-> WorkerReady-Fence signalisieren
-> Primary Wait, SafeCopy und PrimaryComplete-Signal
-> Output Pending
-> Runtime-Pump oder RHIEndFrame prüft GetCompletedValue()
-> Output Ready publizieren
-> Slot wiederverwendbar
</pre>

Backpressure erlaubt maximal einen echten In-Flight-Job pro Worker. Ein Busy-Request setzt keine GPU-Arbeit ab, setzt keine Ressourcen zurück und erhöht <code>PatternPhase</code> nicht. Worker-Fence-Werte steigen mit jedem akzeptierten Submit 1, 2, 3 und so weiter; der persistente Shared Fence verwendet fortlaufend die Paare 1/2, 3/4, 5/6. Fehler nach Übergabe von Ressourcen an die GPU führen zu sicherem Retire beziehungsweise Retention statt zu vorzeitigem Reuse.

=== Texture Stream und Benchmarking ===

Der projektseitige Texture Stream akzeptiert eine beliebige positive, endliche Zielrate. Punkt und Komma sind als Dezimaltrenner möglich. Optional lässt sich die Zahl erfolgreicher Submits begrenzen; Busy- oder Failed-Versuche verbrauchen dieses Limit nicht. Der Quiet-Modus unterdrückt per-Job-Ausgaben, behält aber Start, echte Fehler und die Abschlussstatistik bei.

Die Statistik unterscheidet Timer-Ticks, angenommene Submits, Busy/Failed, Ready, In-Flight und die jeweiligen effektiven Raten. Diagnosezeitpunkte erfassen unter anderem RequestAccepted, RenderCommandExecution, WorkerSubmit, NormalTransferQueued und ReadyObserved.

{| class="wikitable"
! Test
! Ergebnis
! Aussage
|-
| 5 Hz, 20 Submits
| etwa 5 Ready/s, 20/20, kein Busy
| Entspannter Single-Slot-Betrieb
|-
| 1000 Hz, 100 Submits, quiet
| 100/100 Ready, 0 Fehler, etwa 58 Ready/s
| Backpressure begrenzt den Durchsatz sicher
|-
| 1000 Hz bei <code>t.MaxFPS 30</code>
| etwa 28–29 Ready/s trotz rund 982 Timer-Ticks/s
| Primary-/SafeCopy-/Ready-Kette ist effektiv framegekoppelt
|}

Ein zusätzlicher non-blocking Aufruf von <code>ImmediateFlush(DispatchToRHIThread)</code> erreicht hohe Render-Command-Raten, hebt die gemessene Frame-Kopplung aber nicht auf. Im 30-FPS-Test lag der RHIEndFrame-spezifische Completion-Takt praktisch exakt bei 30 Hz. Das aktuelle Problem ist damit eingegrenzt: Nicht der Stream-Timer, sondern die Primary-RHI-/D3D12-Submission der SafeCopy-Kette bestimmt die sichtbare Ready-Rate.

=== Queue-Submission-Diagnose ===

<code>MultiGPUD3D12QueueProbe</code> untersucht die Submission unabhängig vom sichtbaren Texturpfad. Neben <code>full</code>, <code>waitonly</code> und <code>signalonly</code> existieren inzwischen die Diagnosemodi <code>computeonly</code>, <code>commandonly</code>, <code>barrieronly</code>, <code>barrierprivate</code> und <code>copybuffer</code>. Als Queues stehen <code>graphics</code>, <code>copy</code>, <code>native</code>, <code>worker</code>, <code>worker-copy</code> und <code>worker-high</code> zur Verfügung. Graphics und Copy verwenden <code>RHIRunOnQueue(..., false)</code> auf UE-verwalteten Primary-Queues; die übrigen Varianten isolieren private beziehungsweise bereits vorhandene native D3D12-Queues.

Der Probe misst Request, Worker-Submit, <code>RHIRunOnQueue</code>-Aufruf und -Callback, Primary-Execute, Fence-Completion sowie Ready bis zum nächsten akzeptierten Submit. Er fügt keine CPU-Waits, Readbacks, Maps oder <code>BlockUntilGPUIdle</code> ein und beschreibt keine Textur des sichtbaren Normal-Pfads.

{| class="wikitable"
! Test
! Ergebnis
! Befund
|-
| UE Graphics, signal-only, 30 FPS
| 33,319 ms PrimaryExecute bis Ready
| UE-verwaltete Graphics-Submission skaliert mit der Frame-Dauer
|-
| UE Copy, signal-only, 30 FPS
| 32,593 ms PrimaryExecute bis Ready
| Auch die UE-verwaltete Copy Queue ist framegekoppelt
|-
| Private Primary-DIRECT-Queue, signal-only
| etwa 0,014 ms Queue/Fence-Latenz; nach Lifecycle-Fix rund 999 Ready/s bei 30 FPS
| Native Queue und Scheduler sind vollständig vom Frame entkoppelt
|-
| Worker signal-only / leere Command List
| jeweils rund 1000 Ready/s bei 30 FPS
| Worker-Queue, Fence und reine Submission sind nicht framegekoppelt
|-
| Worker <code>CopyBufferRegion</code>, 30 / 60 / 120 FPS
| 29,41 / 58,25 / 113,08 Ready/s
| Bereits eine echte 256-Byte-GPU-Kopie folgt im UE-Prozess dem Frame-Raster
|-
| Worker COPY Queue / HIGH Priority, 30 FPS
| jeweils rund 29,42 Ready/s
| Queue-Typ und Priorität beseitigen die Kopplung nicht
|-
| Standalone-D3D12 auf derselben Intel UHD
| 92.956 Copy-Jobs/s; 0,007 ms durchschnittliche Fence-Latenz
| Die Kopplung ist UE-Prozess-/Scheduling-spezifisch, keine allgemeine Intel-, WDDM- oder D3D12-Grenze
|}

Der <code>RHIRunOnQueue</code>-Callback selbst erreicht den D3D12-Submission-Thread typischerweise bereits nach etwa 0,02–0,05 ms; die Verzögerung entsteht danach in der verwalteten Queue-/Submission-Reihenfolge. <code>SubmitCommandsHint()</code> ist in UE 5.8 nur ein veralteter Alias für <code>ImmediateFlush(DispatchToRHIThread)</code> und stellt daher keinen stärkeren Submission-Mechanismus dar.

Der native Test ist ein '''Architekturbeweis, noch kein Experimental- oder Direct-Modus'''. Die zunächst gemessene Verzögerung von rund 32 ms lag zwischen der In-Flight-Freigabe und dem nächsten Request auf dem Render Thread. Für <code>signalonly/native</code> wurde der sichere Completion-/Submit-Lifecycle deshalb in den frameunabhängigen Scheduler verlegt. Danach erreichten zwei 100-Job-Läufe bei <code>t.MaxFPS 30</code> rund 999 bis 1029 Ready/s, ohne Busy oder Fehler.

Der anschließende <code>full native</code>-Test lokalisierte die verbleibende Kopplung auf echte Worker-GPU-Arbeit: WorkerSubmit bis WorkerReady benötigte bei 30, 60 und 120 FPS ungefähr 33,29, 16,93 und 8,45 ms; WorkerReady bis PrimaryReady war danach praktisch sofort. Signal-only und eine leere Command List waren schnell, Resource Barriers und eine 256-Byte-Kopie dagegen framegebunden. Ein eigenständiger D3D12-Microbenchmark auf derselben Intel UHD erreichte außerhalb von Unreal bei derselben Kopie rund 92.956 Jobs/s mit 0,007 ms mittlerer Fence-Latenz. Die genaue Ursache im UE-Prozess beziehungsweise dessen GPU-Scheduling-Kontext bleibt offen und wird vorerst bis zum Gegencheck mit der vorhandenen Intel Arc A380 geparkt.

=== Worker-Rasterpfad und RasterStream ===

<code>ExperimentalMultiGPU.TestRasterWorker</code> weist erstmals echte Rasterizer-Arbeit auf der Intel-Worker-GPU nach. <code>RasterWorkerVS</code> und <code>RasterWorkerPS</code> werden über Unreals Global-Shader-Pfad kompiliert und für ein natives Worker-Graphics-PSO verwendet. Ein persistentes 128×96-RGBA8-RenderTarget besitzt RTV, leere Root Signature und eine DIRECT-Command-List. Der Vertex Shader erzeugt drei Vertices über <code>SV_VertexID</code>; der Pixel Shader schreibt interpolierte RGB-Farben.

Der Job wechselt das RenderTarget von <code>COPY_SOURCE</code> nach <code>RENDER_TARGET</code>, führt Clear und <code>DrawInstanced(3,1,0,0)</code> aus und wechselt anschließend zurück nach <code>COPY_SOURCE</code>. Danach verwendet er unverändert den robusten Normalpfad aus Cross-Adapter-Shared-Buffer, Primary SafeCopy, persistenter <code>FTextureRHIRef</code>, <code>UExperimentalMultiGPUTexture</code> und DisplayActor. Der Runtime-Test meldete einen akzeptierten Submit und <code>RasterWorker READY</code> für Generation 1; die 128×96-UTexture wurde erfolgreich gebunden.

Der einmalige Test wurde außerdem zu einem frei konfigurierbaren RasterStream ausgebaut. Ein sichtbarer Lauf mit 10 Hz und 50 erfolgreichen Submits endete mit 50 Ready-Ausgaben, 0 Busy und 0 Fehlern bei etwa 9,90 Ready/s. Primary-Textur und Materialbindung blieben dabei persistent.

=== Raster3D mit echten Vertex- und Indexbuffern ===

Der Worker besitzt inzwischen einen kleinen eigenständigen 3D-Rasterpfad mit perspektivischer Kamera, Model-View-Projection-Matrix als Root Constants, D32_FLOAT-Depth-Buffer und Depth-Test. Der finale Testwürfel verwendet 24 POSITION/COLOR-Vertices, 36 <code>uint16</code>-Indices und <code>DrawIndexedInstanced(36,1,0,0,0)</code>; sechs getrennte Seitenfarben machen Ausrichtung und Rotation sichtbar nachvollziehbar.

Die statischen Meshdaten werden einmalig über private Upload-Buffer in DEFAULT-Heaps übertragen. Der Init-Fence wird non-blocking über <code>GetCompletedValue()</code> beobachtet. Der eigentliche Runtime-Renderpfad enthält weiterhin keine CPU-Waits und keine Maps.

=== UE-Static-Meshes auf der Worker-GPU ===

<code>StaticMeshWorker</code> extrahiert echte LOD0-Geometrie aus <code>UStaticMesh</code>-Assets. POSITION und NORMAL sowie <code>uint32</code>-Indices werden in POD-Daten überführt, einmalig asynchron in eigene Worker-VB/IB hochgeladen und anschließend per <code>DrawIndexedInstanced</code> gerendert. Assetpfade sind dynamisch; Auto-Fit richtet Kamera beziehungsweise Modellmaßstab an den Bounds aus.

Sichtbar korrekt getestet wurden:

{| class="wikitable"
! Asset
! Vertices
! Indices
|-
| Sphere
| 559
| 2880
|-
| Cube
| 54
| 144
|-
| Cylinder
| 334
| 1536
|}

=== Multi-Mesh Worker-Szene ===

<code>StaticMeshScene</code> rendert Sphere, Cube und Cylinder gemeinsam in einen Color-/Depth-Frame. Der verifizierte Test umfasst insgesamt 947 Vertices und 4560 Indices, drei <code>DrawIndexedInstanced</code>-Aufrufe und nur einen anschließenden Cross-Adapter-/Normal-SafeCopy-Transfer. Damit ist nicht mehr nur ein synthetisches Primitive, sondern mehrere echte UE-Meshes mit gemeinsamer Tiefenprüfung im Worker-Frame sichtbar nachgewiesen.

=== WorldStaticMeshScene ===

Der nächste Integrationsschritt ist implementiert, aber noch nicht sichtbar im Level verifiziert. <code>ExperimentalMultiGPUWorldStaticMeshScene.cpp</code> sammelt im Engine-Layer bis zu acht sichtbare <code>UStaticMeshComponent</code>s von Actors mit dem Tag <code>MultiGPUWorker</code>. Meshdaten und World-Transforms werden in POD-Strukturen beziehungsweise Matrizen kopiert und ohne <code>UObject</code>-Pointer über eine backend-neutrale RHI-Schnittstelle an D3D12RHI übergeben. Der Build ist erfolgreich; offen ist der sichtbare PIE-/Game-Test mit tatsächlich getaggten Actors.

== Test- und Diagnosebefehle ==

{| class="wikitable"
! Befehl
! Zweck
|-
| <code>ExperimentalMultiGPU.TestComputeShader</code>
| Führt den vollständigen Worker-Compute-Testpfad aus. Er enthält auch ältere Debug- und Regressionstests mit CPU-Readback und ist daher nicht mit dem reinen asynchronen Runtime-Pfad gleichzusetzen.
|-
| <code>ExperimentalMultiGPU.TestTextureConsumer</code>
| Testet <code>TextureConsumerCS</code> auf der Primary-GPU. Die aktuelle Ready-Textur wird über UE-RHI gelesen und anhand ausgewählter Testpixel per Debug-Readback geprüft.
|-
| <code>ExperimentalMultiGPU.TestTextureBridge</code>
| Prüft die Bridge von der fertigen <code>FTextureRHIRef</code> zu <code>UExperimentalMultiGPUTexture</code> und damit den UE- und materialtauglichen Texturpfad.
|-
| <code>ExperimentalMultiGPU.SpawnDisplayActor</code>
| Spawnt den Test-Actor mit Plane im Spiel. Das Material zeigt darauf die vom Worker erzeugte Textur an.
|-
| <code>ExperimentalMultiGPU.TestRasterWorker</code>
| Rasterisiert auf der Worker-GPU ein echtes RGB-Dreieck per Vertex- und Pixel-Shader und transportiert das Ergebnis über den normalen SafeCopy-Pfad bis zum DisplayActor.
|-
| <code>ExperimentalMultiGPU.StartRasterStream</code> / <code>ExperimentalMultiGPU.StopRasterStream</code>
| Startet beziehungsweise stoppt den kontinuierlichen RGB-Dreieck-RasterStream mit frei wählbarer Zielrate, optionalem Submit-Limit und Quiet-Modus.
|-
| <code>ExperimentalMultiGPU.TestRaster3DWorker</code>
| Rendert einmalig den perspektivischen 3D-Testwürfel mit Depth Buffer und echten Vertex-/Indexbuffern.
|-
| <code>ExperimentalMultiGPU.StartRaster3DStream</code> / <code>ExperimentalMultiGPU.StopRaster3DStream</code>
| Startet beziehungsweise stoppt den kontinuierlichen Raster3D-Test.
|-
| <code>ExperimentalMultiGPU.TestStaticMeshWorker [AssetPath]</code>
| Extrahiert und rendert LOD0-Geometrie eines UE-Static-Mesh-Assets; ohne optionalen Pfad wird das konfigurierte Testasset verwendet.
|-
| <code>ExperimentalMultiGPU.TestStaticMeshScene</code>
| Rendert Sphere, Cube und Cylinder gemeinsam mit drei Draw Calls und einem anschließenden Transfer.
|-
| <code>ExperimentalMultiGPU.TestWorldStaticMeshScene</code>
| Sammelt sichtbare, mit <code>MultiGPUWorker</code> getaggte StaticMeshComponents aus der laufenden World und reicht deren POD-Snapshot an den Worker weiter. Sichtbarer Level-Nachweis noch offen.
|-
| <code>ExperimentalMultiGPU.StartTextureStream</code>
| Startet den sichtbaren Normal-Pfad: Worker-Textur → Cross-Adapter-Transfer → SafeCopy → UE-Textur → Material.
|-
| <code>ExperimentalMultiGPU.StopTextureStream</code>
| Verhindert weitere Submits des laufenden Streams. Ein bereits eingereichter GPU-Job darf noch sicher fertig werden.
|-
| <code>ExperimentalMultiGPU.StartQueueProbe</code>
| Startet den Diagnose-Benchmark für Primary-Queue-, Fence- und Submission-Verhalten. Der Probe verändert die sichtbare Textur nicht.
|}

=== Texture Stream ===

Grundsyntax:

<pre>
ExperimentalMultiGPU.StartTextureStream [Hz] [MaxSuccessfulSubmits] [quiet]
</pre>

{| class="wikitable"
! Beispiel
! Wirkung
|-
| <code>ExperimentalMultiGPU.StartTextureStream</code>
| Standardmäßig etwa 5 Hz, ohne Submit-Limit.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 37.5</code>
| Fordert 37,5 Hz ohne Submit-Limit an. Sowohl <code>37.5</code> als auch <code>37,5</code> werden akzeptiert.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 1000 100</code>
| Fordert 1000 Hz an und stoppt nach exakt 100 erfolgreichen Submits.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 1000 100 quiet</code>
| Wie zuvor, unterdrückt aber Per-Job- und Busy-Logspam.
|}

Die Hz-Angabe ist eine '''Ziel- beziehungsweise Request-Frequenz'''. <code>1000</code> bedeutet daher nicht automatisch 1000 fertige Texturen pro Sekunde. Die tatsächliche Rate hängt unter anderem von Timer, Submission, Backpressure, Queue-Latenz und Slot-Lifecycle ab. <code>MaxSuccessfulSubmits</code> zählt nur angenommene Submits; Busy- und Failed-Versuche verbrauchen das Limit nicht.

=== QueueProbe ===

Grundsyntax:

<pre>
ExperimentalMultiGPU.StartQueueProbe <Hz> <MaxSubmits> [quiet] [Mode] [Queue]
</pre>

{| class="wikitable"
! Modus
! Ausgeführter Pfad
|-
| <code>full</code>
| Worker Compute → Cross-Adapter-Transfer → Primary Wait → Copy → Completion Fence.
|-
| <code>waitonly</code>
| Worker Compute → Cross-Adapter-Transfer → Primary wartet auf WorkerReadyFence → Completion Fence. Es findet keine Texturkopie statt.
|-
| <code>signalonly</code>
| Keine Textur, kein Worker-Wait und keine Kopie; nur Queue und Fence. Dieser Modus isoliert das Queue-Verhalten.
|-
| <code>commandonly</code>
| Reicht eine leere echte Worker-Command-List ein und trennt Command-Submission von GPU-Arbeit.
|-
| <code>barrieronly</code> / <code>barrierprivate</code>
| Isoliert Resource-Barriers auf Worker-Ressourcen beziehungsweise einer privaten Testtextur.
|-
| <code>copybuffer</code>
| Führt eine minimale echte <code>CopyBufferRegion</code>-Operation über 256 Byte aus.
|}

{| class="wikitable"
! Queue
! Bedeutung
|-
| <code>graphics</code>
| Vorhandene UE Primary Graphics-/Direct-Queue über <code>RHIRunOnQueue</code>.
|-
| <code>copy</code>
| Vorhandene UE Primary Copy Queue über <code>RHIRunOnQueue</code>.
|-
| <code>native</code>
| Vollständig private native D3D12-DIRECT-Queue auf der Primary; reine Diagnose, kein fertiger Experimental-Modus.
|-
| <code>worker</code>
| Vorhandene native Worker-DIRECT-Queue.
|-
| <code>worker-copy</code>
| Separate native Worker-COPY-Queue.
|-
| <code>worker-high</code>
| Separate Worker-DIRECT-Queue mit hoher Priorität.
|}

Typische Beispiele:

<pre>
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet full graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet waitonly graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly copy
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly native
</pre>

Der letzte Befehl ist aktuell die wichtigste isolierte Gegenprobe. Mit der privaten nativen Queue wurde bei 30 FPS eine durchschnittliche Latenz <code>primaryExecuteToReadyAvgMs = 0.014 ms</code> gemessen.

=== Benchmark-CVars ===

{| class="wikitable"
! CVar
! Zweck
|-
| <code>r.VSync 0</code>
| Deaktiviert VSync, damit es die Messung nicht begrenzt.
|-
| <code>t.MaxFPS 30</code> <code>t.MaxFPS 60</code> <code>t.MaxFPS 120</code>
| Setzt die Engine-Framerate für reproduzierbare Frame-Coupling-Tests.
|-
| <code>t.MaxFPS 0</code>
| Entfernt das normale <code>t.MaxFPS</code>-Limit. Dieser Lauf ist als zusätzliche Diagnose-Gegenprobe vorgesehen.
|}

== Aktueller nächster Schritt ==

Der kleine 3D-Workload mit Geometrie, Kamera und Depth ist inzwischen umgesetzt und bis zur Multi-Mesh-Szene sichtbar nachgewiesen. Der nächste unmittelbare Nachweis ist der sichtbare PIE-/Game-Test des WorldStaticMeshScene-Snapshots mit tatsächlich als <code>MultiGPUWorker</code> getaggten Actors. Danach sollen SceneCapture-nahe Aufgaben wie CCTV, Spiegel oder Minimap folgen. Der robuste Normal-/SafeCopy-Pfad bleibt dabei der sichtbare Referenztransport. Die vorhandene Intel Arc A380 dient nach Eintreffen des Stromkabels als nächster Hardware-Gegencheck; ein privater Experimental-Fast-Path wird erst weiterverfolgt, wenn State-Tracking, Residency, Queue-Reihenfolge, Read-vs-Write-Hazards und automatischer Session-Fallback sauber gelöst sind.

== Historische Vorläufer ==

Die Grundidee heterogener Multi-GPU-Nutzung ist nicht neu. Bereits mit der Einführung von Direct3D 12 entstanden mehrere Versuche, integrierte und dedizierte GPUs gemeinsam zu verwenden. Eine allgemein einsetzbare Lösung für moderne UE5-Spiele hat sich daraus jedoch nicht entwickelt.

=== Microsoft und Epic: UE4 Elemental Demo (2015) ===

Microsoft zeigte eine angepasste Unreal-Engine-4-Version der Elemental-Demo, bei der eine NVIDIA-GPU und eine Intel-iGPU gemeinsam arbeiteten. Das erklärte Ziel war, ansonsten ungenutzte Grafikleistung in Hybrid-Systemen zu verwenden. Dieser Versuch ist der Grundidee des Projekts besonders ähnlich, blieb aber eine technische Demonstration.

=== Intel: D3D12 Multi-Adapter Sample (2015) ===

Intels Beispiel kombinierte eine GeForce 840M mit Intel HD Graphics 5500. Beide GPUs berechneten getrennte Teile einer einfach parallelisierbaren Raytracing-Szene. Cross-Adapter-Ressourcen und Shared Fences führten die Ergebnisse anschließend zusammen. Intel berichtete in diesem Test von nahezu halbierter Framezeit, warnte jedoch ausdrücklich davor, das Ergebnis unmittelbar auf reale Spiele zu übertragen.

=== Ashes of the Singularity ===

Die Nitrous Engine von ''Ashes of the Singularity'' setzte Direct3D-12-Explicit-Multiadapter in einem veröffentlichten Spiel ein. Dabei konnten auch unterschiedliche GPU-Modelle und Hersteller zusammenarbeiten. Das war ein wichtiger Praxisnachweis, blieb in der Spielebranche aber eine seltene Ausnahme.

=== Weitere verwandte Ansätze ===

* ''Rise of the Tomb Raider'' erhielt explizite Direct3D-12-Multi-GPU-Unterstützung, vor allem für klassische Kombinationen ähnlicher GPUs.
* NVIDIA VR SLI wies bei Virtual Reality jeder GPU ein Auge zu. Das verteilt unabhängige Ansichten, bleibt jedoch NVIDIA-spezifisch.
* Unreal nDisplay kann Viewports oder Frustums auf weitere GPUs beziehungsweise Prozesse auslagern und das fertige Bild zur Ausgabe-GPU zurückführen. Der Einsatzbereich ist hauptsächlich Virtual Production.
* Forschung und High-Performance Computing verwenden seit Jahren Scheduler für heterogene GPUs, allerdings überwiegend für Compute- und Datenverarbeitungsaufgaben statt für einen allgemeinen UE5-Echtzeitrenderer.

=== Abgrenzung dieses Projekts ===

Das Projekt erfindet Direct3D-12-Explicit-Multiadapter nicht neu. Sein eigener Ansatz liegt in der Kombination aus tiefer UE5.8-RHI-Integration, UE-kompilierten Shadern auf unabhängigen Worker-Devices, frei wählbaren Spiel- und Compute-Workloads, Capability- und Performance-Scheduler, mehreren Fallback-Pfaden sowie dem langfristigen Ziel beliebiger Hersteller und mehrerer Worker.

== Vergleich mit anderen Multi-GPU-Verfahren ==

{| class="wikitable"
! Verfahren
! Arbeitsweise
! Verhältnis zu diesem Projekt
|-
| SLI / CrossFire
| Treiber- beziehungsweise Verbundlösung für meist ähnliche GPUs; häufig wird die Bildarbeit verteilt.
| Dieses Projekt benötigt keinen herstellerspezifischen GPU-Verbund und weist Aufgaben ausdrücklich selbst zu.
|-
| AFR (Alternate Frame Rendering)
| GPU 1 rendert einen Frame, GPU 2 den nächsten.
| Das Projekt verteilt unabhängige Aufgaben statt aufeinanderfolgender Frames. Dadurch werden Frame-Abhängigkeiten und typisches AFR-Pacing vermieden.
|-
| SFR (Split Frame Rendering)
| Mehrere GPUs bearbeiten Bereiche desselben Frames.
| Erfordert enge Lastverteilung und viel Datenaustausch. Das Projekt bevorzugt vollständig abgrenzbare Workloads und überträgt deren Ergebnis.
|-
| Direct3D 12 Linked Multiadapter
| Mehrere vom Treiber verbundene GPUs erscheinen als Knoten eines logischen Adapters.
| Eignet sich eher für eng kompatible GPUs. Das Projekt verwendet unabhängige Devices (Unlinked/Explicit Multiadapter) und unterstützt dadurch heterogene Herstellerkombinationen.
|-
| Direct3D 12 Unlinked / Explicit Multiadapter
| Die Anwendung verwaltet getrennte Adapter, Ressourcen und Synchronisation selbst.
| Das ist die technische Familie des Projekts. Hinzu kommen die eigene UE5-RHI-Integration, Workload-Ziele, Fallbacks und der geplante Scheduler.
|-
| UE nDisplay mGPU / Multi-Process
| Separate GPUs rendern bestimmte Viewports oder Frustums, vor allem für Virtual Production; Ergebnisse werden zur Ausgabe-GPU kopiert.
| Ähnliche Idee der aufgabenweisen Trennung, aber für einen anderen Einsatzbereich. Dieses Projekt zielt auf allgemeine Spiel- und Compute-Workloads innerhalb der Engine.
|-
| Vulkan Device Groups
| Ähnliche physische GPUs können ein gemeinsames logisches Device bilden.
| Für beliebige heterogene GPUs meist ungeeignet, da Geräte einer Gruppe nahezu gleiche Eigenschaften besitzen müssen. Eine spätere Vulkan-Portierung benötigt daher wahrscheinlich getrennte Devices und External Memory/Semaphores.
|}

SLI und CrossFire bezeichnen den Verbund; AFR und SFR beschreiben mögliche Verteilungsmethoden innerhalb solcher Systeme. Sie sind deshalb nicht vollständig getrennte Kategorien.

== Vorteile der geplanten Variante ==

* '''Herstellerunabhängig:''' NVIDIA, AMD und Intel können grundsätzlich kombiniert werden.
* '''Vorhandene Hardware nutzen:''' Auch eine sonst wenig genutzte integrierte GPU kann geeignete Nebenaufgaben übernehmen.
* '''Aufgaben statt Frames verteilen:''' Spiegel, Minimap oder Compute können mit eigener Auflösung und Aktualisierungsrate laufen.
* '''Keine identischen GPUs erforderlich:''' Unterschiedliche Fähigkeiten können gezielt genutzt werden.
* '''Kontrollierter Datenaustausch:''' Nur das benötigte Ergebnis muss zurück zur Primary-GPU.
* '''Robuste Fallback-Idee:''' Wenn direkte Texturen nicht gemeinsam nutzbar sind, bleibt der Shared-Buffer-Pfad.
* '''Erweiterbar:''' Scheduler, manuelles Mapping und mehrere Worker sind als spätere Stufen vorgesehen.

== Nachteile und technische Risiken ==

* '''Hoher Entwicklungsaufwand:''' Geräte, Ressourcen, Zustände, Fences, Fehlerfälle und UE-Lebenszyklen müssen selbst verwaltet werden.
* '''Transfer kann den Gewinn aufzehren:''' Cross-Adapter Heaps liegen laut D3D12 nicht automatisch im schnellen lokalen VRAM. Bandbreite und Latenz müssen für jeden Workload gemessen werden.
* '''VRAM wird nicht einfach addiert:''' Benötigte Ressourcen können auf mehreren GPUs vorliegen und zusätzlichen Speicher verbrauchen.
* '''Langsame Worker können bremsen:''' Eine Aufgabe lohnt sich nur, wenn Rechengewinn größer als Übergabe-, Warte- und Kopierkosten ist.
* '''Nicht jeder Workload ist unabhängig:''' Hauptansicht, Lumen, Nanite und stark gekoppelte Renderpässe besitzen viele Abhängigkeiten und sind schwieriger auszulagern.
* '''Hardwareunterschiede:''' Formate, Shader-Funktionen, Queue-Fähigkeiten und Cross-Adapter-Support müssen pro GPU geprüft werden.
* '''Wartungsrisiko:''' Eingriffe in private D3D12RHI-Dateien können bei Engine-Updates angepasst werden müssen.
* '''Produktionsreife fehlt noch:''' Ressourcenpools, Timeouts, Device-Lost-Wiederherstellung, Scheduler und echte Szenentests sind offen.

== Wann die Variante sinnvoll ist ==

Am aussichtsreichsten sind Aufgaben mit viel eigener Rechenarbeit, einem relativ kleinen Endergebnis und wenigen Abhängigkeiten zur Hauptszene. Gute frühe Kandidaten sind unabhängige Compute-Aufgaben sowie Scene Captures, die nicht in jedem Frame aktualisiert werden müssen. Weniger geeignet sind winzige Aufgaben mit großem Transfer oder Renderpässe, die ständig auf Ressourcen der Primary-GPU zugreifen.

Die entscheidende Regel für den späteren Scheduler lautet daher:

<pre>
Worker-Gewinn > Vorbereitung + Datentransfer + Synchronisation + Rückintegration
</pre>

== Bekannte Grenzen des Proof of Concepts ==

* Der asynchrone 128×96-End-to-End-Pfad ist über Dimensionen, Dispatch, Transfer, Fences, Pending/Ready und Reuse verifiziert; ein eigener 128×96-Pixel-Readback fehlt noch. Der synchrone 64×64-Debugtest prüft weiterhin alle 4096 Pixel.
* Der Normal-Transport unterstützt derzeit <code>DXGI_FORMAT_R8G8B8A8_UNORM</code> mit Sample Count 1; weitere Formate, Mips, Arrays, Slices und MSAA sind offen.
* Pro Worker existiert absichtlich nur ein persistenter Runtime-Slot. Mehrere parallele In-Flight-Jobs sowie Double-, Triple- oder Ring-Buffering fehlen noch.
* Die Primary-/SafeCopy-/Ready-Kette bleibt trotz zusätzlichem non-blocking <code>DispatchToRHIThread</code> effektiv an den Frame-/Submission-Zyklus gekoppelt.
* 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.
* QueueProbe ist reine Diagnose. Private native Queues sind noch kein Experimental-/Direct-Modus und beschreiben keine UE-eigene sichtbare Textur.
* Es gibt noch keine Umschaltung zwischen Normal und Experimental sowie keinen automatischen Session-Fallback.
* Raw-D3D12-Shared-Ressourcen sind noch nicht vollständig in Unreals Residency-Management eingebunden.
* Praktisch getestet ist Primary plus ein Worker. Die Architektur ist auf mehrere Worker ausgelegt, N-GPU ist aber noch nicht praktisch validiert.
* Raster3D, einzelne echte UE-Static-Meshes und eine Drei-Mesh-Szene sind sichtbar nachgewiesen. Der WorldStaticMeshScene-POD-Snapshot ist implementiert und erfolgreich gebaut, sein sichtbarer Test mit getaggten Actors steht jedoch noch aus.
* Die aktuelle Worker-Szene übernimmt nur LOD0-POSITION/NORMAL-Daten und höchstens acht sichtbare StaticMeshComponents; vollständige Materialien, Texturen, Beleuchtung, Skeletal Meshes, Nanite und eine allgemeine SceneCapture-Pipeline fehlen.
* 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 von Commit <code>0719998</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.

== Roadmap ==

# WorldStaticMeshScene mit tatsächlich als <code>MultiGPUWorker</code> getaggten Actors im laufenden PIE-/Game-Level sichtbar testen und Snapshot-, Transform- und Auswahlverhalten verifizieren.
# Den Worker-Szenepfad schrittweise um weitere echte Szenendaten und robuste Cache-/Lifetime-Regeln erweitern.
# SceneCapture-nahe Workloads wie CCTV, Spiegel oder Minimap als erste praktisch nützliche unabhängige Raster-Aufgaben aufbauen.
# QueueProbe und <code>full native</code> auf der Intel Arc A380 wiederholen, um Laptop-iGPU-Sonderverhalten von der allgemeinen Architektur zu trennen.
# Experimental-Architektur nur mit Capability-Selbsttest, sauberem State-Tracking, Residency, Queue-Reihenfolge, Hazard-Modell und automatischem Session-Fallback definieren.
# Nur bei nachgewiesenem Workload-Bedarf einen zweiten Slot oder Ringbuffer mit Generation-, Fence-, Reuse- und Consumer-Hazard-Modell ergänzen.
# Formate, Mips, Arrays/Slices und gegebenenfalls MSAA capability-basiert erweitern.
# Capability-Matrix, Benchmark-Wizard, Scheduler und manuelle Overrides entwickeln.
# Mehrere Worker-GPUs unterstützen.
# Fallback-Matrix aus Normal Shared Buffer, System-RAM/Staging und einem späteren Experimental Fast Path ergänzen.
# Linux/Vulkan mit getrennten Devices, External Memory und externer Synchronisation untersuchen.

== Quellen ==

* Interner Entwicklungsstand und verifizierte Testprotokolle vom 8. September 2026; Basis-Commit <code>0719998</code> plus uncommitted Working Tree. WorldStaticMeshScene ist gebaut, aber noch nicht sichtbar getestet.
* [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/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://www.intel.com/content/dam/develop/external/us/en/documents/multi-adapter-support-in-directx-12-594015.pdf Intel: Multi-Adapter Support in DirectX 12]
* [https://devblogs.microsoft.com/directx/ashes-of-the-singularity-makes-gaming-history-with-directx-12/ Microsoft: Ashes of the Singularity und heterogene Adapter]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/nvidia-sli-alternative-frame-rendering-in-unreal-engine Epic: NVIDIA SLI Alternate Frame Rendering]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/multi-process-rendering-with-unreal-engine Epic: Multi-Process Rendering]
* [https://registry.khronos.org/vulkan/specs/latest/pdf/vkspec.pdf Khronos: Vulkan Specification – Device Groups]

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Multi-GPU]]
[[Kategorie:Direct3D 12]]
[[Kategorie:Experimentell]]

UE5 Heterogeneous Multi-GPU

2026-09-07T10:20:32Z

Elaina:

{{Hinweis|Projektstand: 7. September 2026, Commit <code>0719998</code>. 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.

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.

{| class="wikitable"
|+ Projektstatus
|-
! Engine / Plattform
| Unreal Engine 5.8 Source Build / Windows / Direct3D 12
|-
! Testsystem
| Lenovo LOQ 17IRX10
|-
! Primary
| NVIDIA GeForce RTX 5060 Laptop GPU
|-
! Worker
| Intel UHD Graphics
|-
! Git-Stand
| Commit <code>0719998</code> auf Branch <code>mgpu-experimental</code>
|-
! Windows/D3D12-Proof-of-Concept
| Sichtbarer 128×96-Worker-Texture-Stream, isolierte Queue-/Scheduling-Diagnose und erster echter Worker-Rasterpfad nachgewiesen
|-
! Gesamtvision
| etwa 30–35 % (Scheduler, echte Workloads, N-GPU und Vulkan noch offen)
|}

== Grundprinzip ==

<pre>
Intel Worker GPU
-> MainTextureCS + PatternPhase
-> persistente Worker-Textur
-> persistenter Shared Cross-Adapter Buffer
-> monotone Shared Fence / Queue Wait
-> persistente UE-eigene FTextureRHIRef
-> stabile UExperimentalMultiGPUTexture

RTX Primary GPU
-> normales UE5-Rendering
-> TPS-Material zeigt das Worker-Ergebnis sichtbar an
</pre>

Pro Worker ist maximal ein Runtime-Job gleichzeitig in flight. Backpressure lehnt weitere Requests als <code>Busy</code> ab, bis der Slot nach der Primary-Completion wieder sicher verwendbar ist.

Jeder Worker besitzt ein eigenes <code>ID3D12Device</code>, eigene Queues, Command Lists und Ressourcen. Ein späterer Scheduler soll Rechenleistung, Fähigkeiten, Transferkosten und gewünschte Aktualisierungsrate bewerten. Vorgesehene Aufgaben sind beispielsweise SceneCapture2D, Spiegel, CCTV, Minimap, Compute oder Niagara.

== Verifizierter Entwicklungsstand ==

=== Worker-Compute ===

Ein echter, von Unreal kompilierter Global Compute Shader läuft auf der Intel UHD, während Unreal regulär über die RTX rendert. Der Test verdoppelt 64 Ganzzahlen auf dem Worker; '''64 von 64 Ergebnissen wurden korrekt verifiziert'''. Damit ist echte GPU-Arbeit auf einem zweiten, herstellerfremden Device nachgewiesen.

Zusätzlich läuft <code>MainTextureCS</code> auf der Intel-GPU. Der synchrone Debugtest erzeugt eine 64 × 64 Pixel große RGBA8-Textur; '''alle 4096 shader-generierten Pixel wurden korrekt verifiziert'''. Der normale Runtime-Pfad verwendet inzwischen einen asynchronen 128×96-Test. Der Shader liest seine Dimensionen mit <code>GetDimensions()</code>, schützt überhängende Threads durch einen Bounds-Check und wird mit <code>Dispatch(16,12,1)</code> ausgeführt. <code>PatternPhase</code> erzeugt für jeden akzeptierten Submit deterministisch einen neuen sichtbaren Inhalt. Abgewiesene Busy-Requests erhöhen die Phase nicht und erzeugen daher keine Lücken.

=== Cross-Adapter-Speicher und Synchronisation ===

* RTX und Intel öffnen denselben D3D12 Cross-Adapter Heap.
* Ein gemeinsamer Buffer wurde mit 64 Testwerten erfolgreich geprüft.
* Ein persistenter Shared Fence synchronisiert die Queues direkt von GPU zu GPU. Seine Werte steigen pro Job monoton: WorkerReady/PrimaryComplete verwenden die Paare 1/2, 3/4, 5/6 und so weiter.
* Die CPU vermittelt die GPU-Abhängigkeit nicht; Worker- und Primary-Queue verwenden <code>Signal</code> und <code>Wait</code> direkt auf der GPU.
* Der separate Readback-Verifikationstest darf weiterhin blockieren. Der normale Runtime-Pfad wartet dagegen nicht auf GPU-Leerlauf.

=== Texturtransport ===

Direkte Cross-Adapter-Texturen sind auf dem Testsystem nicht beidseitig verfügbar: Die Intel UHD meldet Unterstützung für Row-Major Cross-Adapter Textures, die RTX 5060 Laptop GPU nicht. Deshalb verwendet das Projekt einen allgemeineren Buffer-Fallback.

<pre>
Intel MainTextureCS
-> persistente Worker-Textur
-> CopyTextureRegion
-> persistenter Shared Cross-Adapter Buffer
-> Worker signalisiert WorkerReady (1, 3, 5, ...)
-> UE-Primary-Queue wartet auf WorkerReady
-> direkte Kopie in persistente UE-eigene FTextureRHIRef
-> Primary signalisiert PrimaryComplete (2, 4, 6, ...)
</pre>

Der robuste Normal-Pfad kopiert die Worker-Textur über den Shared Buffer direkt in eine von Unreal erzeugte <code>FTextureRHIRef</code>. Breite, Höhe und Row Pitch werden dynamisch aus Worker-Ressource und Transport-Metadaten übernommen. Der erfolgreiche 128×96-RGBA8-Test verwendet 512 Byte Row Pitch und 49.152 Byte Transfergröße. Die Output Registry trennt Persistent-, Pending- und Ready-Zustände sowie Inhaltsgeneration und Texturidentität. Dadurch kann eine verspätete Completion keinen neueren Output zurückrollen.

=== Non-blocking Runtime-Pfad ===

Die produktive Testlogik ist aus dem Konsolenkommando in eine gekapselte NormalPath-API verschoben. <code>SubmitWorkerTextureComputeJob()</code> reicht den Worker-Dispatch ohne CPU-Wait ein. <code>QueueNormalTextureTransfer()</code> reiht Wait, Kopie und Completion-Signal in Unreals D3D12-Kontext ein. Der normale MainTextureCS-Pfad enthält weder CPU-Fence-Waits noch Readback, <code>Map</code> oder Pixelvergleich. <code>TickNormalTextureTransfers()</code> prüft die Primary-Completion non-blocking über einen Runtime-Pump; <code>RHIEndFrame()</code> bleibt als Fallback erhalten.

Eine passende Primary-<code>FTextureRHIRef</code> wird pro Worker und Konfiguration persistent gehalten. Nach PrimaryComplete kann der nächste Job dieselbe Resource erneut verwenden; dabei führt Unreal die Übergänge <code>SRVMask -> CopyDest -> SRVMask</code> aus. Eine backend-neutrale RHI-Provider-API reicht die Ready-Textur an die Engine weiter. <code>UExperimentalMultiGPUTexture</code> hält eine stabile <code>UTexture</code> samt TextureReference und bindet die persistente <code>FTextureRHIRef</code> ohne zusätzlichen Pixel-Copy. Eine native D3D12-Resource wird weiterhin nicht blind als UE-Textur gewrappt, weil Unreals Resource-State-Buchhaltung den tatsächlichen nativen Zustand sonst nicht sicher kennt.

=== Sichtbarer TPS-Consumer ===

<code>AExperimentalMultiGPUDisplayActor</code> zeigt die Worker-Ausgabe im Third-Person-Testlevel über den Materialparameter <code>MultiGPUTexture</code> an. Damit ist der Output nicht mehr nur über Logs oder Readback nachgewiesen: Die Intel UHD erzeugt fortlaufend die Texturinhalte, während die RTX die Spielwelt und das Material rendert. <code>TextureConsumerCS</code> kann Ready-Ausgaben auf der Primary zusätzlich als SRV lesen und fünf quantisierte Samples im Debugpfad prüfen.

=== Lebensdauer und automatisches Cleanup ===

Der Normal-Pfad verwendet pro Worker genau einen persistenten Runtime-Slot. Worker-Textur, Root Signature, PSO, Descriptor Heap, Command Allocator/List und Worker-Fence werden nach der ersten kompatiblen Initialisierung wiederverwendet. Dasselbe gilt für Shared Heap/Buffer/Fence und die Transport-Command-Objekte. Der In-Flight-Job trägt nur noch die nötigen Job-, Generation- und Fence-Metadaten.

<pre>
Runtime Request
-> Completion non-blocking prüfen
-> falls Slot frei: Worker Dispatch
-> WorkerReady-Fence signalisieren
-> Primary Wait, SafeCopy und PrimaryComplete-Signal
-> Output Pending
-> Runtime-Pump oder RHIEndFrame prüft GetCompletedValue()
-> Output Ready publizieren
-> Slot wiederverwendbar
</pre>

Backpressure erlaubt maximal einen echten In-Flight-Job pro Worker. Ein Busy-Request setzt keine GPU-Arbeit ab, setzt keine Ressourcen zurück und erhöht <code>PatternPhase</code> nicht. Worker-Fence-Werte steigen mit jedem akzeptierten Submit 1, 2, 3 und so weiter; der persistente Shared Fence verwendet fortlaufend die Paare 1/2, 3/4, 5/6. Fehler nach Übergabe von Ressourcen an die GPU führen zu sicherem Retire beziehungsweise Retention statt zu vorzeitigem Reuse.

=== Texture Stream und Benchmarking ===

Der projektseitige Texture Stream akzeptiert eine beliebige positive, endliche Zielrate. Punkt und Komma sind als Dezimaltrenner möglich. Optional lässt sich die Zahl erfolgreicher Submits begrenzen; Busy- oder Failed-Versuche verbrauchen dieses Limit nicht. Der Quiet-Modus unterdrückt per-Job-Ausgaben, behält aber Start, echte Fehler und die Abschlussstatistik bei.

Die Statistik unterscheidet Timer-Ticks, angenommene Submits, Busy/Failed, Ready, In-Flight und die jeweiligen effektiven Raten. Diagnosezeitpunkte erfassen unter anderem RequestAccepted, RenderCommandExecution, WorkerSubmit, NormalTransferQueued und ReadyObserved.

{| class="wikitable"
! Test
! Ergebnis
! Aussage
|-
| 5 Hz, 20 Submits
| etwa 5 Ready/s, 20/20, kein Busy
| Entspannter Single-Slot-Betrieb
|-
| 1000 Hz, 100 Submits, quiet
| 100/100 Ready, 0 Fehler, etwa 58 Ready/s
| Backpressure begrenzt den Durchsatz sicher
|-
| 1000 Hz bei <code>t.MaxFPS 30</code>
| etwa 28–29 Ready/s trotz rund 982 Timer-Ticks/s
| Primary-/SafeCopy-/Ready-Kette ist effektiv framegekoppelt
|}

Ein zusätzlicher non-blocking Aufruf von <code>ImmediateFlush(DispatchToRHIThread)</code> erreicht hohe Render-Command-Raten, hebt die gemessene Frame-Kopplung aber nicht auf. Im 30-FPS-Test lag der RHIEndFrame-spezifische Completion-Takt praktisch exakt bei 30 Hz. Das aktuelle Problem ist damit eingegrenzt: Nicht der Stream-Timer, sondern die Primary-RHI-/D3D12-Submission der SafeCopy-Kette bestimmt die sichtbare Ready-Rate.

=== Queue-Submission-Diagnose ===

<code>MultiGPUD3D12QueueProbe</code> untersucht die Submission unabhängig vom sichtbaren Texturpfad. Neben <code>full</code>, <code>waitonly</code> und <code>signalonly</code> existieren inzwischen die Diagnosemodi <code>computeonly</code>, <code>commandonly</code>, <code>barrieronly</code>, <code>barrierprivate</code> und <code>copybuffer</code>. Als Queues stehen <code>graphics</code>, <code>copy</code>, <code>native</code>, <code>worker</code>, <code>worker-copy</code> und <code>worker-high</code> zur Verfügung. Graphics und Copy verwenden <code>RHIRunOnQueue(..., false)</code> auf UE-verwalteten Primary-Queues; die übrigen Varianten isolieren private beziehungsweise bereits vorhandene native D3D12-Queues.

Der Probe misst Request, Worker-Submit, <code>RHIRunOnQueue</code>-Aufruf und -Callback, Primary-Execute, Fence-Completion sowie Ready bis zum nächsten akzeptierten Submit. Er fügt keine CPU-Waits, Readbacks, Maps oder <code>BlockUntilGPUIdle</code> ein und beschreibt keine Textur des sichtbaren Normal-Pfads.

{| class="wikitable"
! Test
! Ergebnis
! Befund
|-
| UE Graphics, signal-only, 30 FPS
| 33,319 ms PrimaryExecute bis Ready
| UE-verwaltete Graphics-Submission skaliert mit der Frame-Dauer
|-
| UE Copy, signal-only, 30 FPS
| 32,593 ms PrimaryExecute bis Ready
| Auch die UE-verwaltete Copy Queue ist framegekoppelt
|-
| Private Primary-DIRECT-Queue, signal-only
| etwa 0,014 ms Queue/Fence-Latenz; nach Lifecycle-Fix rund 999 Ready/s bei 30 FPS
| Native Queue und Scheduler sind vollständig vom Frame entkoppelt
|-
| Worker signal-only / leere Command List
| jeweils rund 1000 Ready/s bei 30 FPS
| Worker-Queue, Fence und reine Submission sind nicht framegekoppelt
|-
| Worker <code>CopyBufferRegion</code>, 30 / 60 / 120 FPS
| 29,41 / 58,25 / 113,08 Ready/s
| Bereits eine echte 256-Byte-GPU-Kopie folgt im UE-Prozess dem Frame-Raster
|-
| Worker COPY Queue / HIGH Priority, 30 FPS
| jeweils rund 29,42 Ready/s
| Queue-Typ und Priorität beseitigen die Kopplung nicht
|-
| Standalone-D3D12 auf derselben Intel UHD
| 92.956 Copy-Jobs/s; 0,007 ms durchschnittliche Fence-Latenz
| Die Kopplung ist UE-Prozess-/Scheduling-spezifisch, keine allgemeine Intel-, WDDM- oder D3D12-Grenze
|}

Der <code>RHIRunOnQueue</code>-Callback selbst erreicht den D3D12-Submission-Thread typischerweise bereits nach etwa 0,02–0,05 ms; die Verzögerung entsteht danach in der verwalteten Queue-/Submission-Reihenfolge. <code>SubmitCommandsHint()</code> ist in UE 5.8 nur ein veralteter Alias für <code>ImmediateFlush(DispatchToRHIThread)</code> und stellt daher keinen stärkeren Submission-Mechanismus dar.

Der native Test ist ein '''Architekturbeweis, noch kein Experimental- oder Direct-Modus'''. Die zunächst gemessene Verzögerung von rund 32 ms lag zwischen der In-Flight-Freigabe und dem nächsten Request auf dem Render Thread. Für <code>signalonly/native</code> wurde der sichere Completion-/Submit-Lifecycle deshalb in den frameunabhängigen Scheduler verlegt. Danach erreichten zwei 100-Job-Läufe bei <code>t.MaxFPS 30</code> rund 999 bis 1029 Ready/s, ohne Busy oder Fehler.

Der anschließende <code>full native</code>-Test lokalisierte die verbleibende Kopplung auf echte Worker-GPU-Arbeit: WorkerSubmit bis WorkerReady benötigte bei 30, 60 und 120 FPS ungefähr 33,29, 16,93 und 8,45 ms; WorkerReady bis PrimaryReady war danach praktisch sofort. Signal-only und eine leere Command List waren schnell, Resource Barriers und eine 256-Byte-Kopie dagegen framegebunden. Ein eigenständiger D3D12-Microbenchmark auf derselben Intel UHD erreichte außerhalb von Unreal bei derselben Kopie rund 92.956 Jobs/s mit 0,007 ms mittlerer Fence-Latenz. Die genaue Ursache im UE-Prozess beziehungsweise dessen GPU-Scheduling-Kontext bleibt offen und wird vorerst bis zum Gegencheck mit einer Intel Arc A750 geparkt.

=== Erster Worker-Rasterpfad ===

<code>ExperimentalMultiGPU.TestRasterWorker</code> weist erstmals echte Rasterizer-Arbeit auf der Intel-Worker-GPU nach. <code>RasterWorkerVS</code> und <code>RasterWorkerPS</code> werden über Unreals Global-Shader-Pfad kompiliert und für ein natives Worker-Graphics-PSO verwendet. Ein persistentes 128×96-RGBA8-RenderTarget besitzt RTV, leere Root Signature und eine DIRECT-Command-List. Der Vertex Shader erzeugt drei Vertices über <code>SV_VertexID</code>; der Pixel Shader schreibt interpolierte RGB-Farben.

Der Job wechselt das RenderTarget von <code>COPY_SOURCE</code> nach <code>RENDER_TARGET</code>, führt Clear und <code>DrawInstanced(3,1,0,0)</code> aus und wechselt anschließend zurück nach <code>COPY_SOURCE</code>. Danach verwendet er unverändert den robusten Normalpfad aus Cross-Adapter-Shared-Buffer, Primary SafeCopy, persistenter <code>FTextureRHIRef</code>, <code>UExperimentalMultiGPUTexture</code> und DisplayActor. Der Runtime-Test meldete einen akzeptierten Submit und <code>RasterWorker READY</code> für Generation 1; die 128×96-UTexture wurde erfolgreich gebunden. Ein eigener Screenshot des sichtbaren Dreiecks wurde noch nicht als Nachweis archiviert.

== Test- und Diagnosebefehle ==

{| class="wikitable"
! Befehl
! Zweck
|-
| <code>ExperimentalMultiGPU.TestComputeShader</code>
| Führt den vollständigen Worker-Compute-Testpfad aus. Er enthält auch ältere Debug- und Regressionstests mit CPU-Readback und ist daher nicht mit dem reinen asynchronen Runtime-Pfad gleichzusetzen.
|-
| <code>ExperimentalMultiGPU.TestTextureConsumer</code>
| Testet <code>TextureConsumerCS</code> auf der Primary-GPU. Die aktuelle Ready-Textur wird über UE-RHI gelesen und anhand ausgewählter Testpixel per Debug-Readback geprüft.
|-
| <code>ExperimentalMultiGPU.TestTextureBridge</code>
| Prüft die Bridge von der fertigen <code>FTextureRHIRef</code> zu <code>UExperimentalMultiGPUTexture</code> und damit den UE- und materialtauglichen Texturpfad.
|-
| <code>ExperimentalMultiGPU.SpawnDisplayActor</code>
| Spawnt den Test-Actor mit Plane im Spiel. Das Material zeigt darauf die vom Worker erzeugte Textur an.
|-
| <code>ExperimentalMultiGPU.TestRasterWorker</code>
| Rasterisiert auf der Worker-GPU ein echtes RGB-Dreieck per Vertex- und Pixel-Shader und transportiert das Ergebnis über den normalen SafeCopy-Pfad bis zum DisplayActor.
|-
| <code>ExperimentalMultiGPU.StartTextureStream</code>
| Startet den sichtbaren Normal-Pfad: Worker-Textur → Cross-Adapter-Transfer → SafeCopy → UE-Textur → Material.
|-
| <code>ExperimentalMultiGPU.StopTextureStream</code>
| Verhindert weitere Submits des laufenden Streams. Ein bereits eingereichter GPU-Job darf noch sicher fertig werden.
|-
| <code>ExperimentalMultiGPU.StartQueueProbe</code>
| Startet den Diagnose-Benchmark für Primary-Queue-, Fence- und Submission-Verhalten. Der Probe verändert die sichtbare Textur nicht.
|}

=== Texture Stream ===

Grundsyntax:

<pre>
ExperimentalMultiGPU.StartTextureStream [Hz] [MaxSuccessfulSubmits] [quiet]
</pre>

{| class="wikitable"
! Beispiel
! Wirkung
|-
| <code>ExperimentalMultiGPU.StartTextureStream</code>
| Standardmäßig etwa 5 Hz, ohne Submit-Limit.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 37.5</code>
| Fordert 37,5 Hz ohne Submit-Limit an. Sowohl <code>37.5</code> als auch <code>37,5</code> werden akzeptiert.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 1000 100</code>
| Fordert 1000 Hz an und stoppt nach exakt 100 erfolgreichen Submits.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 1000 100 quiet</code>
| Wie zuvor, unterdrückt aber Per-Job- und Busy-Logspam.
|}

Die Hz-Angabe ist eine '''Ziel- beziehungsweise Request-Frequenz'''. <code>1000</code> bedeutet daher nicht automatisch 1000 fertige Texturen pro Sekunde. Die tatsächliche Rate hängt unter anderem von Timer, Submission, Backpressure, Queue-Latenz und Slot-Lifecycle ab. <code>MaxSuccessfulSubmits</code> zählt nur angenommene Submits; Busy- und Failed-Versuche verbrauchen das Limit nicht.

=== QueueProbe ===

Grundsyntax:

<pre>
ExperimentalMultiGPU.StartQueueProbe <Hz> <MaxSubmits> [quiet] [Mode] [Queue]
</pre>

{| class="wikitable"
! Modus
! Ausgeführter Pfad
|-
| <code>full</code>
| Worker Compute → Cross-Adapter-Transfer → Primary Wait → Copy → Completion Fence.
|-
| <code>waitonly</code>
| Worker Compute → Cross-Adapter-Transfer → Primary wartet auf WorkerReadyFence → Completion Fence. Es findet keine Texturkopie statt.
|-
| <code>signalonly</code>
| Keine Textur, kein Worker-Wait und keine Kopie; nur Queue und Fence. Dieser Modus isoliert das Queue-Verhalten.
|-
| <code>commandonly</code>
| Reicht eine leere echte Worker-Command-List ein und trennt Command-Submission von GPU-Arbeit.
|-
| <code>barrieronly</code> / <code>barrierprivate</code>
| Isoliert Resource-Barriers auf Worker-Ressourcen beziehungsweise einer privaten Testtextur.
|-
| <code>copybuffer</code>
| Führt eine minimale echte <code>CopyBufferRegion</code>-Operation über 256 Byte aus.
|}

{| class="wikitable"
! Queue
! Bedeutung
|-
| <code>graphics</code>
| Vorhandene UE Primary Graphics-/Direct-Queue über <code>RHIRunOnQueue</code>.
|-
| <code>copy</code>
| Vorhandene UE Primary Copy Queue über <code>RHIRunOnQueue</code>.
|-
| <code>native</code>
| Vollständig private native D3D12-DIRECT-Queue auf der Primary; reine Diagnose, kein fertiger Experimental-Modus.
|-
| <code>worker</code>
| Vorhandene native Worker-DIRECT-Queue.
|-
| <code>worker-copy</code>
| Separate native Worker-COPY-Queue.
|-
| <code>worker-high</code>
| Separate Worker-DIRECT-Queue mit hoher Priorität.
|}

Typische Beispiele:

<pre>
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet full graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet waitonly graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly copy
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly native
</pre>

Der letzte Befehl ist aktuell die wichtigste isolierte Gegenprobe. Mit der privaten nativen Queue wurde bei 30 FPS eine durchschnittliche Latenz <code>primaryExecuteToReadyAvgMs = 0.014 ms</code> gemessen.

=== Benchmark-CVars ===

{| class="wikitable"
! CVar
! Zweck
|-
| <code>r.VSync 0</code>
| Deaktiviert VSync, damit es die Messung nicht begrenzt.
|-
| <code>t.MaxFPS 30</code> <code>t.MaxFPS 60</code> <code>t.MaxFPS 120</code>
| Setzt die Engine-Framerate für reproduzierbare Frame-Coupling-Tests.
|-
| <code>t.MaxFPS 0</code>
| Entfernt das normale <code>t.MaxFPS</code>-Limit. Dieser Lauf ist als zusätzliche Diagnose-Gegenprobe vorgesehen.
|}

== Aktueller nächster Schritt ==

Nach Abschluss der Queue-/Scheduling-Diagnose rückt wieder der eigentliche Workload in den Vordergrund. Der RasterWorker soll vom synthetischen Dreieck zu einem kleinen 3D-Workload mit Geometrie, Transformation, Kamera und später Depth erweitert werden. Darauf sollen SceneCapture-nahe Aufgaben wie CCTV, Spiegel oder Minimap folgen. Der robuste Normal-/SafeCopy-Pfad bleibt dabei der sichtbare Referenztransport. Die Arc A750 dient als nächster wichtiger Hardware-Gegencheck; ein privater Experimental-Fast-Path wird erst weiterverfolgt, wenn State-Tracking, Residency, Queue-Reihenfolge, Read-vs-Write-Hazards und automatischer Session-Fallback sauber gelöst sind.

== Historische Vorläufer ==

Die Grundidee heterogener Multi-GPU-Nutzung ist nicht neu. Bereits mit der Einführung von Direct3D 12 entstanden mehrere Versuche, integrierte und dedizierte GPUs gemeinsam zu verwenden. Eine allgemein einsetzbare Lösung für moderne UE5-Spiele hat sich daraus jedoch nicht entwickelt.

=== Microsoft und Epic: UE4 Elemental Demo (2015) ===

Microsoft zeigte eine angepasste Unreal-Engine-4-Version der Elemental-Demo, bei der eine NVIDIA-GPU und eine Intel-iGPU gemeinsam arbeiteten. Das erklärte Ziel war, ansonsten ungenutzte Grafikleistung in Hybrid-Systemen zu verwenden. Dieser Versuch ist der Grundidee des Projekts besonders ähnlich, blieb aber eine technische Demonstration.

=== Intel: D3D12 Multi-Adapter Sample (2015) ===

Intels Beispiel kombinierte eine GeForce 840M mit Intel HD Graphics 5500. Beide GPUs berechneten getrennte Teile einer einfach parallelisierbaren Raytracing-Szene. Cross-Adapter-Ressourcen und Shared Fences führten die Ergebnisse anschließend zusammen. Intel berichtete in diesem Test von nahezu halbierter Framezeit, warnte jedoch ausdrücklich davor, das Ergebnis unmittelbar auf reale Spiele zu übertragen.

=== Ashes of the Singularity ===

Die Nitrous Engine von ''Ashes of the Singularity'' setzte Direct3D-12-Explicit-Multiadapter in einem veröffentlichten Spiel ein. Dabei konnten auch unterschiedliche GPU-Modelle und Hersteller zusammenarbeiten. Das war ein wichtiger Praxisnachweis, blieb in der Spielebranche aber eine seltene Ausnahme.

=== Weitere verwandte Ansätze ===

* ''Rise of the Tomb Raider'' erhielt explizite Direct3D-12-Multi-GPU-Unterstützung, vor allem für klassische Kombinationen ähnlicher GPUs.
* NVIDIA VR SLI wies bei Virtual Reality jeder GPU ein Auge zu. Das verteilt unabhängige Ansichten, bleibt jedoch NVIDIA-spezifisch.
* Unreal nDisplay kann Viewports oder Frustums auf weitere GPUs beziehungsweise Prozesse auslagern und das fertige Bild zur Ausgabe-GPU zurückführen. Der Einsatzbereich ist hauptsächlich Virtual Production.
* Forschung und High-Performance Computing verwenden seit Jahren Scheduler für heterogene GPUs, allerdings überwiegend für Compute- und Datenverarbeitungsaufgaben statt für einen allgemeinen UE5-Echtzeitrenderer.

=== Abgrenzung dieses Projekts ===

Das Projekt erfindet Direct3D-12-Explicit-Multiadapter nicht neu. Sein eigener Ansatz liegt in der Kombination aus tiefer UE5.8-RHI-Integration, UE-kompilierten Shadern auf unabhängigen Worker-Devices, frei wählbaren Spiel- und Compute-Workloads, Capability- und Performance-Scheduler, mehreren Fallback-Pfaden sowie dem langfristigen Ziel beliebiger Hersteller und mehrerer Worker.

== Vergleich mit anderen Multi-GPU-Verfahren ==

{| class="wikitable"
! Verfahren
! Arbeitsweise
! Verhältnis zu diesem Projekt
|-
| SLI / CrossFire
| Treiber- beziehungsweise Verbundlösung für meist ähnliche GPUs; häufig wird die Bildarbeit verteilt.
| Dieses Projekt benötigt keinen herstellerspezifischen GPU-Verbund und weist Aufgaben ausdrücklich selbst zu.
|-
| AFR (Alternate Frame Rendering)
| GPU 1 rendert einen Frame, GPU 2 den nächsten.
| Das Projekt verteilt unabhängige Aufgaben statt aufeinanderfolgender Frames. Dadurch werden Frame-Abhängigkeiten und typisches AFR-Pacing vermieden.
|-
| SFR (Split Frame Rendering)
| Mehrere GPUs bearbeiten Bereiche desselben Frames.
| Erfordert enge Lastverteilung und viel Datenaustausch. Das Projekt bevorzugt vollständig abgrenzbare Workloads und überträgt deren Ergebnis.
|-
| Direct3D 12 Linked Multiadapter
| Mehrere vom Treiber verbundene GPUs erscheinen als Knoten eines logischen Adapters.
| Eignet sich eher für eng kompatible GPUs. Das Projekt verwendet unabhängige Devices (Unlinked/Explicit Multiadapter) und unterstützt dadurch heterogene Herstellerkombinationen.
|-
| Direct3D 12 Unlinked / Explicit Multiadapter
| Die Anwendung verwaltet getrennte Adapter, Ressourcen und Synchronisation selbst.
| Das ist die technische Familie des Projekts. Hinzu kommen die eigene UE5-RHI-Integration, Workload-Ziele, Fallbacks und der geplante Scheduler.
|-
| UE nDisplay mGPU / Multi-Process
| Separate GPUs rendern bestimmte Viewports oder Frustums, vor allem für Virtual Production; Ergebnisse werden zur Ausgabe-GPU kopiert.
| Ähnliche Idee der aufgabenweisen Trennung, aber für einen anderen Einsatzbereich. Dieses Projekt zielt auf allgemeine Spiel- und Compute-Workloads innerhalb der Engine.
|-
| Vulkan Device Groups
| Ähnliche physische GPUs können ein gemeinsames logisches Device bilden.
| Für beliebige heterogene GPUs meist ungeeignet, da Geräte einer Gruppe nahezu gleiche Eigenschaften besitzen müssen. Eine spätere Vulkan-Portierung benötigt daher wahrscheinlich getrennte Devices und External Memory/Semaphores.
|}

SLI und CrossFire bezeichnen den Verbund; AFR und SFR beschreiben mögliche Verteilungsmethoden innerhalb solcher Systeme. Sie sind deshalb nicht vollständig getrennte Kategorien.

== Vorteile der geplanten Variante ==

* '''Herstellerunabhängig:''' NVIDIA, AMD und Intel können grundsätzlich kombiniert werden.
* '''Vorhandene Hardware nutzen:''' Auch eine sonst wenig genutzte integrierte GPU kann geeignete Nebenaufgaben übernehmen.
* '''Aufgaben statt Frames verteilen:''' Spiegel, Minimap oder Compute können mit eigener Auflösung und Aktualisierungsrate laufen.
* '''Keine identischen GPUs erforderlich:''' Unterschiedliche Fähigkeiten können gezielt genutzt werden.
* '''Kontrollierter Datenaustausch:''' Nur das benötigte Ergebnis muss zurück zur Primary-GPU.
* '''Robuste Fallback-Idee:''' Wenn direkte Texturen nicht gemeinsam nutzbar sind, bleibt der Shared-Buffer-Pfad.
* '''Erweiterbar:''' Scheduler, manuelles Mapping und mehrere Worker sind als spätere Stufen vorgesehen.

== Nachteile und technische Risiken ==

* '''Hoher Entwicklungsaufwand:''' Geräte, Ressourcen, Zustände, Fences, Fehlerfälle und UE-Lebenszyklen müssen selbst verwaltet werden.
* '''Transfer kann den Gewinn aufzehren:''' Cross-Adapter Heaps liegen laut D3D12 nicht automatisch im schnellen lokalen VRAM. Bandbreite und Latenz müssen für jeden Workload gemessen werden.
* '''VRAM wird nicht einfach addiert:''' Benötigte Ressourcen können auf mehreren GPUs vorliegen und zusätzlichen Speicher verbrauchen.
* '''Langsame Worker können bremsen:''' Eine Aufgabe lohnt sich nur, wenn Rechengewinn größer als Übergabe-, Warte- und Kopierkosten ist.
* '''Nicht jeder Workload ist unabhängig:''' Hauptansicht, Lumen, Nanite und stark gekoppelte Renderpässe besitzen viele Abhängigkeiten und sind schwieriger auszulagern.
* '''Hardwareunterschiede:''' Formate, Shader-Funktionen, Queue-Fähigkeiten und Cross-Adapter-Support müssen pro GPU geprüft werden.
* '''Wartungsrisiko:''' Eingriffe in private D3D12RHI-Dateien können bei Engine-Updates angepasst werden müssen.
* '''Produktionsreife fehlt noch:''' Ressourcenpools, Timeouts, Device-Lost-Wiederherstellung, Scheduler und echte Szenentests sind offen.

== Wann die Variante sinnvoll ist ==

Am aussichtsreichsten sind Aufgaben mit viel eigener Rechenarbeit, einem relativ kleinen Endergebnis und wenigen Abhängigkeiten zur Hauptszene. Gute frühe Kandidaten sind unabhängige Compute-Aufgaben sowie Scene Captures, die nicht in jedem Frame aktualisiert werden müssen. Weniger geeignet sind winzige Aufgaben mit großem Transfer oder Renderpässe, die ständig auf Ressourcen der Primary-GPU zugreifen.

Die entscheidende Regel für den späteren Scheduler lautet daher:

<pre>
Worker-Gewinn > Vorbereitung + Datentransfer + Synchronisation + Rückintegration
</pre>

== Bekannte Grenzen des Proof of Concepts ==

* Der asynchrone 128×96-End-to-End-Pfad ist über Dimensionen, Dispatch, Transfer, Fences, Pending/Ready und Reuse verifiziert; ein eigener 128×96-Pixel-Readback fehlt noch. Der synchrone 64×64-Debugtest prüft weiterhin alle 4096 Pixel.
* Der Normal-Transport unterstützt derzeit <code>DXGI_FORMAT_R8G8B8A8_UNORM</code> mit Sample Count 1; weitere Formate, Mips, Arrays, Slices und MSAA sind offen.
* Pro Worker existiert absichtlich nur ein persistenter Runtime-Slot. Mehrere parallele In-Flight-Jobs sowie Double-, Triple- oder Ring-Buffering fehlen noch.
* Die Primary-/SafeCopy-/Ready-Kette bleibt trotz zusätzlichem non-blocking <code>DispatchToRHIThread</code> effektiv an den Frame-/Submission-Zyklus gekoppelt.
* 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.
* QueueProbe ist reine Diagnose. Private native Queues sind noch kein Experimental-/Direct-Modus und beschreiben keine UE-eigene sichtbare Textur.
* Es gibt noch keine Umschaltung zwischen Normal und Experimental sowie keinen automatischen Session-Fallback.
* Raw-D3D12-Shared-Ressourcen sind noch nicht vollständig in Unreals Residency-Management eingebunden.
* Praktisch getestet ist Primary plus ein Worker. Die Architektur ist auf mehrere Worker ausgelegt, N-GPU ist aber noch nicht praktisch validiert.
* Der RasterWorker zeichnet bislang nur ein synthetisches RGB-Dreieck. Eine echte 3D-Szene, SceneCapture2D, CCTV, Spiegel oder Minimap ist noch nicht umgesetzt.
* 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 von Commit <code>0719998</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.

== Roadmap ==

# RasterWorker zu einem kleinen 3D-Workload mit Geometrie, Transformation, Kamera und später Depth erweitern.
# SceneCapture-nahe Workloads wie CCTV, Spiegel oder Minimap als erste praktisch nützliche unabhängige Raster-Aufgaben aufbauen.
# QueueProbe und <code>full native</code> auf der Intel Arc A750 wiederholen, um Laptop-iGPU-Sonderverhalten von der allgemeinen Architektur zu trennen.
# Experimental-Architektur nur mit Capability-Selbsttest, sauberem State-Tracking, Residency, Queue-Reihenfolge, Hazard-Modell und automatischem Session-Fallback definieren.
# Nur bei nachgewiesenem Workload-Bedarf einen zweiten Slot oder Ringbuffer mit Generation-, Fence-, Reuse- und Consumer-Hazard-Modell ergänzen.
# Formate, Mips, Arrays/Slices und gegebenenfalls MSAA capability-basiert erweitern.
# Capability-Matrix, Benchmark-Wizard, Scheduler und manuelle Overrides entwickeln.
# Mehrere Worker-GPUs unterstützen.
# Fallback-Matrix aus Normal Shared Buffer, System-RAM/Staging und einem späteren Experimental Fast Path ergänzen.
# Linux/Vulkan mit getrennten Devices, External Memory und externer Synchronisation untersuchen.

== Quellen ==

* Interner Entwicklungsstand und verifizierte Testprotokolle vom 7. September 2026, Commit <code>0719998</code>; vorheriger dokumentierter Checkpoint <code>43a5c07</code>
* [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/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://www.intel.com/content/dam/develop/external/us/en/documents/multi-adapter-support-in-directx-12-594015.pdf Intel: Multi-Adapter Support in DirectX 12]
* [https://devblogs.microsoft.com/directx/ashes-of-the-singularity-makes-gaming-history-with-directx-12/ Microsoft: Ashes of the Singularity und heterogene Adapter]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/nvidia-sli-alternative-frame-rendering-in-unreal-engine Epic: NVIDIA SLI Alternate Frame Rendering]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/multi-process-rendering-with-unreal-engine Epic: Multi-Process Rendering]
* [https://registry.khronos.org/vulkan/specs/latest/pdf/vkspec.pdf Khronos: Vulkan Specification – Device Groups]

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Multi-GPU]]
[[Kategorie:Direct3D 12]]
[[Kategorie:Experimentell]]

UE5 Heterogeneous Multi-GPU

2026-09-06T23:45:54Z

Elaina:

{{Hinweis|Projektstand: 7. September 2026, Commit <code>43a5c07</code>. 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.

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.

{| class="wikitable"
|+ Projektstatus
|-
! Engine / Plattform
| Unreal Engine 5.8 Source Build / Windows / Direct3D 12
|-
! Testsystem
| Lenovo LOQ 17IRX10
|-
! Primary
| NVIDIA GeForce RTX 5060 Laptop GPU
|-
! Worker
| Intel UHD Graphics
|-
! Git-Stand
| Commit <code>43a5c07</code> auf Branch <code>mgpu-experimental</code>
|-
! Windows/D3D12-Proof-of-Concept
| Sichtbarer 128×96-Worker-Texture-Stream im TPS sowie isolierte Diagnose der Primary-Queue-/Submission-Latenz nachgewiesen
|-
! Gesamtvision
| etwa 30–35 % (Scheduler, echte Workloads, N-GPU und Vulkan noch offen)
|}

== Grundprinzip ==

<pre>
Intel Worker GPU
-> MainTextureCS + PatternPhase
-> persistente Worker-Textur
-> persistenter Shared Cross-Adapter Buffer
-> monotone Shared Fence / Queue Wait
-> persistente UE-eigene FTextureRHIRef
-> stabile UExperimentalMultiGPUTexture

RTX Primary GPU
-> normales UE5-Rendering
-> TPS-Material zeigt das Worker-Ergebnis sichtbar an
</pre>

Pro Worker ist maximal ein Runtime-Job gleichzeitig in flight. Backpressure lehnt weitere Requests als <code>Busy</code> ab, bis der Slot nach der Primary-Completion wieder sicher verwendbar ist.

Jeder Worker besitzt ein eigenes <code>ID3D12Device</code>, eigene Queues, Command Lists und Ressourcen. Ein späterer Scheduler soll Rechenleistung, Fähigkeiten, Transferkosten und gewünschte Aktualisierungsrate bewerten. Vorgesehene Aufgaben sind beispielsweise SceneCapture2D, Spiegel, CCTV, Minimap, Compute oder Niagara.

== Verifizierter Entwicklungsstand ==

=== Worker-Compute ===

Ein echter, von Unreal kompilierter Global Compute Shader läuft auf der Intel UHD, während Unreal regulär über die RTX rendert. Der Test verdoppelt 64 Ganzzahlen auf dem Worker; '''64 von 64 Ergebnissen wurden korrekt verifiziert'''. Damit ist echte GPU-Arbeit auf einem zweiten, herstellerfremden Device nachgewiesen.

Zusätzlich läuft <code>MainTextureCS</code> auf der Intel-GPU. Der synchrone Debugtest erzeugt eine 64 × 64 Pixel große RGBA8-Textur; '''alle 4096 shader-generierten Pixel wurden korrekt verifiziert'''. Der normale Runtime-Pfad verwendet inzwischen einen asynchronen 128×96-Test. Der Shader liest seine Dimensionen mit <code>GetDimensions()</code>, schützt überhängende Threads durch einen Bounds-Check und wird mit <code>Dispatch(16,12,1)</code> ausgeführt. <code>PatternPhase</code> erzeugt für jeden akzeptierten Submit deterministisch einen neuen sichtbaren Inhalt. Abgewiesene Busy-Requests erhöhen die Phase nicht und erzeugen daher keine Lücken.

=== Cross-Adapter-Speicher und Synchronisation ===

* RTX und Intel öffnen denselben D3D12 Cross-Adapter Heap.
* Ein gemeinsamer Buffer wurde mit 64 Testwerten erfolgreich geprüft.
* Ein persistenter Shared Fence synchronisiert die Queues direkt von GPU zu GPU. Seine Werte steigen pro Job monoton: WorkerReady/PrimaryComplete verwenden die Paare 1/2, 3/4, 5/6 und so weiter.
* Die CPU vermittelt die GPU-Abhängigkeit nicht; Worker- und Primary-Queue verwenden <code>Signal</code> und <code>Wait</code> direkt auf der GPU.
* Der separate Readback-Verifikationstest darf weiterhin blockieren. Der normale Runtime-Pfad wartet dagegen nicht auf GPU-Leerlauf.

=== Texturtransport ===

Direkte Cross-Adapter-Texturen sind auf dem Testsystem nicht beidseitig verfügbar: Die Intel UHD meldet Unterstützung für Row-Major Cross-Adapter Textures, die RTX 5060 Laptop GPU nicht. Deshalb verwendet das Projekt einen allgemeineren Buffer-Fallback.

<pre>
Intel MainTextureCS
-> persistente Worker-Textur
-> CopyTextureRegion
-> persistenter Shared Cross-Adapter Buffer
-> Worker signalisiert WorkerReady (1, 3, 5, ...)
-> UE-Primary-Queue wartet auf WorkerReady
-> direkte Kopie in persistente UE-eigene FTextureRHIRef
-> Primary signalisiert PrimaryComplete (2, 4, 6, ...)
</pre>

Der robuste Normal-Pfad kopiert die Worker-Textur über den Shared Buffer direkt in eine von Unreal erzeugte <code>FTextureRHIRef</code>. Breite, Höhe und Row Pitch werden dynamisch aus Worker-Ressource und Transport-Metadaten übernommen. Der erfolgreiche 128×96-RGBA8-Test verwendet 512 Byte Row Pitch und 49.152 Byte Transfergröße. Die Output Registry trennt Persistent-, Pending- und Ready-Zustände sowie Inhaltsgeneration und Texturidentität. Dadurch kann eine verspätete Completion keinen neueren Output zurückrollen.

=== Non-blocking Runtime-Pfad ===

Die produktive Testlogik ist aus dem Konsolenkommando in eine gekapselte NormalPath-API verschoben. <code>SubmitWorkerTextureComputeJob()</code> reicht den Worker-Dispatch ohne CPU-Wait ein. <code>QueueNormalTextureTransfer()</code> reiht Wait, Kopie und Completion-Signal in Unreals D3D12-Kontext ein. Der normale MainTextureCS-Pfad enthält weder CPU-Fence-Waits noch Readback, <code>Map</code> oder Pixelvergleich. <code>TickNormalTextureTransfers()</code> prüft die Primary-Completion non-blocking über einen Runtime-Pump; <code>RHIEndFrame()</code> bleibt als Fallback erhalten.

Eine passende Primary-<code>FTextureRHIRef</code> wird pro Worker und Konfiguration persistent gehalten. Nach PrimaryComplete kann der nächste Job dieselbe Resource erneut verwenden; dabei führt Unreal die Übergänge <code>SRVMask -> CopyDest -> SRVMask</code> aus. Eine backend-neutrale RHI-Provider-API reicht die Ready-Textur an die Engine weiter. <code>UExperimentalMultiGPUTexture</code> hält eine stabile <code>UTexture</code> samt TextureReference und bindet die persistente <code>FTextureRHIRef</code> ohne zusätzlichen Pixel-Copy. Eine native D3D12-Resource wird weiterhin nicht blind als UE-Textur gewrappt, weil Unreals Resource-State-Buchhaltung den tatsächlichen nativen Zustand sonst nicht sicher kennt.

=== Sichtbarer TPS-Consumer ===

<code>AExperimentalMultiGPUDisplayActor</code> zeigt die Worker-Ausgabe im Third-Person-Testlevel über den Materialparameter <code>MultiGPUTexture</code> an. Damit ist der Output nicht mehr nur über Logs oder Readback nachgewiesen: Die Intel UHD erzeugt fortlaufend die Texturinhalte, während die RTX die Spielwelt und das Material rendert. <code>TextureConsumerCS</code> kann Ready-Ausgaben auf der Primary zusätzlich als SRV lesen und fünf quantisierte Samples im Debugpfad prüfen.

=== Lebensdauer und automatisches Cleanup ===

Der Normal-Pfad verwendet pro Worker genau einen persistenten Runtime-Slot. Worker-Textur, Root Signature, PSO, Descriptor Heap, Command Allocator/List und Worker-Fence werden nach der ersten kompatiblen Initialisierung wiederverwendet. Dasselbe gilt für Shared Heap/Buffer/Fence und die Transport-Command-Objekte. Der In-Flight-Job trägt nur noch die nötigen Job-, Generation- und Fence-Metadaten.

<pre>
Runtime Request
-> Completion non-blocking prüfen
-> falls Slot frei: Worker Dispatch
-> WorkerReady-Fence signalisieren
-> Primary Wait, SafeCopy und PrimaryComplete-Signal
-> Output Pending
-> Runtime-Pump oder RHIEndFrame prüft GetCompletedValue()
-> Output Ready publizieren
-> Slot wiederverwendbar
</pre>

Backpressure erlaubt maximal einen echten In-Flight-Job pro Worker. Ein Busy-Request setzt keine GPU-Arbeit ab, setzt keine Ressourcen zurück und erhöht <code>PatternPhase</code> nicht. Worker-Fence-Werte steigen mit jedem akzeptierten Submit 1, 2, 3 und so weiter; der persistente Shared Fence verwendet fortlaufend die Paare 1/2, 3/4, 5/6. Fehler nach Übergabe von Ressourcen an die GPU führen zu sicherem Retire beziehungsweise Retention statt zu vorzeitigem Reuse.

=== Texture Stream und Benchmarking ===

Der projektseitige Texture Stream akzeptiert eine beliebige positive, endliche Zielrate. Punkt und Komma sind als Dezimaltrenner möglich. Optional lässt sich die Zahl erfolgreicher Submits begrenzen; Busy- oder Failed-Versuche verbrauchen dieses Limit nicht. Der Quiet-Modus unterdrückt per-Job-Ausgaben, behält aber Start, echte Fehler und die Abschlussstatistik bei.

Die Statistik unterscheidet Timer-Ticks, angenommene Submits, Busy/Failed, Ready, In-Flight und die jeweiligen effektiven Raten. Diagnosezeitpunkte erfassen unter anderem RequestAccepted, RenderCommandExecution, WorkerSubmit, NormalTransferQueued und ReadyObserved.

{| class="wikitable"
! Test
! Ergebnis
! Aussage
|-
| 5 Hz, 20 Submits
| etwa 5 Ready/s, 20/20, kein Busy
| Entspannter Single-Slot-Betrieb
|-
| 1000 Hz, 100 Submits, quiet
| 100/100 Ready, 0 Fehler, etwa 58 Ready/s
| Backpressure begrenzt den Durchsatz sicher
|-
| 1000 Hz bei <code>t.MaxFPS 30</code>
| etwa 28–29 Ready/s trotz rund 982 Timer-Ticks/s
| Primary-/SafeCopy-/Ready-Kette ist effektiv framegekoppelt
|}

Ein zusätzlicher non-blocking Aufruf von <code>ImmediateFlush(DispatchToRHIThread)</code> erreicht hohe Render-Command-Raten, hebt die gemessene Frame-Kopplung aber nicht auf. Im 30-FPS-Test lag der RHIEndFrame-spezifische Completion-Takt praktisch exakt bei 30 Hz. Das aktuelle Problem ist damit eingegrenzt: Nicht der Stream-Timer, sondern die Primary-RHI-/D3D12-Submission der SafeCopy-Kette bestimmt die sichtbare Ready-Rate.

=== Queue-Submission-Diagnose ===

<code>MultiGPUD3D12QueueProbe</code> untersucht die Submission unabhängig vom sichtbaren Texturpfad. Der Probe besitzt die Modi <code>full</code>, <code>waitonly</code> und <code>signalonly</code> sowie die Queue-Auswahl <code>graphics</code>, <code>copy</code> und <code>native</code>. Graphics und Copy verwenden <code>RHIRunOnQueue(..., false)</code> auf UE-verwalteten Queues. Native verwendet derzeit ausschließlich im Signal-only-Modus eine eigene persistente D3D12-DIRECT-Queue auf dem Primary-Device.

Der Probe misst Request, Worker-Submit, <code>RHIRunOnQueue</code>-Aufruf und -Callback, Primary-Execute, Fence-Completion sowie Ready bis zum nächsten akzeptierten Submit. Er fügt keine CPU-Waits, Readbacks, Maps oder <code>BlockUntilGPUIdle</code> ein und beschreibt keine Textur des sichtbaren Normal-Pfads.

{| class="wikitable"
! Signal-only-Test
! PrimaryExecute bis Ready
! Befund
|-
| UE Graphics Queue, 30 FPS
| 33,319 ms
| skaliert praktisch mit der Frame-Dauer
|-
| UE Graphics Queue, 60 FPS
| 16,377 ms
| skaliert praktisch mit der Frame-Dauer
|-
| UE Graphics Queue, 120 FPS
| 8,712 ms
| skaliert praktisch mit der Frame-Dauer
|-
| UE Copy Queue, 30 / 120 FPS
| 32,593 / 8,206 ms
| Copy Queue ist ebenfalls framegekoppelt
|-
| Private native DIRECT Queue, 30 FPS
| durchschnittlich 0,014 ms; 0,001–0,037 ms
| D3D12, Treiber und Primary-GPU sind nicht an die Frame-Dauer gebunden
|}

Der <code>RHIRunOnQueue</code>-Callback selbst erreicht den D3D12-Submission-Thread typischerweise bereits nach etwa 0,02–0,05 ms; die Verzögerung entsteht danach in der verwalteten Queue-/Submission-Reihenfolge. <code>SubmitCommandsHint()</code> ist in UE 5.8 nur ein veralteter Alias für <code>ImmediateFlush(DispatchToRHIThread)</code> und stellt daher keinen stärkeren Submission-Mechanismus dar.

Der native Test ist ein '''Architekturbeweis, noch kein Experimental- oder Direct-Modus'''. Er signalisiert nur einen privaten Fence und verwendet weder WorkerReady-Wait noch Cross-Adapter-Copy, UE-eigene Textur oder Engine-State-Tracking. Obwohl sein Fence nach rund 0,014 ms fertig ist, erreicht der gesamte Probe bei 30 FPS nur etwa 30,75 Ready/s; <code>Ready -> NextSubmit</code> dauert im Mittel 32,403 ms. Damit ist als nächster Engpass der Lifecycle beziehungsweise die Freigabe des Single Slots isoliert.

== Test- und Diagnosebefehle ==

{| class="wikitable"
! Befehl
! Zweck
|-
| <code>ExperimentalMultiGPU.TestComputeShader</code>
| Führt den vollständigen Worker-Compute-Testpfad aus. Er enthält auch ältere Debug- und Regressionstests mit CPU-Readback und ist daher nicht mit dem reinen asynchronen Runtime-Pfad gleichzusetzen.
|-
| <code>ExperimentalMultiGPU.TestTextureConsumer</code>
| Testet <code>TextureConsumerCS</code> auf der Primary-GPU. Die aktuelle Ready-Textur wird über UE-RHI gelesen und anhand ausgewählter Testpixel per Debug-Readback geprüft.
|-
| <code>ExperimentalMultiGPU.TestTextureBridge</code>
| Prüft die Bridge von der fertigen <code>FTextureRHIRef</code> zu <code>UExperimentalMultiGPUTexture</code> und damit den UE- und materialtauglichen Texturpfad.
|-
| <code>ExperimentalMultiGPU.SpawnDisplayActor</code>
| Spawnt den Test-Actor mit Plane im Spiel. Das Material zeigt darauf die vom Worker erzeugte Textur an.
|-
| <code>ExperimentalMultiGPU.StartTextureStream</code>
| Startet den sichtbaren Normal-Pfad: Worker-Textur → Cross-Adapter-Transfer → SafeCopy → UE-Textur → Material.
|-
| <code>ExperimentalMultiGPU.StopTextureStream</code>
| Verhindert weitere Submits des laufenden Streams. Ein bereits eingereichter GPU-Job darf noch sicher fertig werden.
|-
| <code>ExperimentalMultiGPU.StartQueueProbe</code>
| Startet den Diagnose-Benchmark für Primary-Queue-, Fence- und Submission-Verhalten. Der Probe verändert die sichtbare Textur nicht.
|}

=== Texture Stream ===

Grundsyntax:

<pre>
ExperimentalMultiGPU.StartTextureStream [Hz] [MaxSuccessfulSubmits] [quiet]
</pre>

{| class="wikitable"
! Beispiel
! Wirkung
|-
| <code>ExperimentalMultiGPU.StartTextureStream</code>
| Standardmäßig etwa 5 Hz, ohne Submit-Limit.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 37.5</code>
| Fordert 37,5 Hz ohne Submit-Limit an. Sowohl <code>37.5</code> als auch <code>37,5</code> werden akzeptiert.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 1000 100</code>
| Fordert 1000 Hz an und stoppt nach exakt 100 erfolgreichen Submits.
|-
| <code>ExperimentalMultiGPU.StartTextureStream 1000 100 quiet</code>
| Wie zuvor, unterdrückt aber Per-Job- und Busy-Logspam.
|}

Die Hz-Angabe ist eine '''Ziel- beziehungsweise Request-Frequenz'''. <code>1000</code> bedeutet daher nicht automatisch 1000 fertige Texturen pro Sekunde. Die tatsächliche Rate hängt unter anderem von Timer, Submission, Backpressure, Queue-Latenz und Slot-Lifecycle ab. <code>MaxSuccessfulSubmits</code> zählt nur angenommene Submits; Busy- und Failed-Versuche verbrauchen das Limit nicht.

=== QueueProbe ===

Grundsyntax:

<pre>
ExperimentalMultiGPU.StartQueueProbe <Hz> <MaxSubmits> [quiet] [Mode] [Queue]
</pre>

{| class="wikitable"
! Modus
! Ausgeführter Pfad
|-
| <code>full</code>
| Worker Compute → Cross-Adapter-Transfer → Primary Wait → Copy → Completion Fence.
|-
| <code>waitonly</code>
| Worker Compute → Cross-Adapter-Transfer → Primary wartet auf WorkerReadyFence → Completion Fence. Es findet keine Texturkopie statt.
|-
| <code>signalonly</code>
| Keine Textur, kein Worker-Wait und keine Kopie; nur Queue und Fence. Dieser Modus isoliert das Queue-Verhalten.
|}

{| class="wikitable"
! Queue
! Bedeutung
|-
| <code>graphics</code>
| Vorhandene UE Primary Graphics-/Direct-Queue über <code>RHIRunOnQueue</code>.
|-
| <code>copy</code>
| Vorhandene UE Primary Copy Queue über <code>RHIRunOnQueue</code>.
|-
| <code>native</code>
| Vollständig private native D3D12-DIRECT-Queue auf der Primary. Derzeit nur für die Signal-only-Diagnose vorgesehen und kein fertiger Experimental-Modus.
|}

Typische Beispiele:

<pre>
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet full graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet waitonly graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly copy
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly native
</pre>

Der letzte Befehl ist aktuell die wichtigste isolierte Gegenprobe. Mit der privaten nativen Queue wurde bei 30 FPS eine durchschnittliche Latenz <code>primaryExecuteToReadyAvgMs = 0.014 ms</code> gemessen.

=== Benchmark-CVars ===

{| class="wikitable"
! CVar
! Zweck
|-
| <code>r.VSync 0</code>
| Deaktiviert VSync, damit es die Messung nicht begrenzt.
|-
| <code>t.MaxFPS 30</code> <code>t.MaxFPS 60</code> <code>t.MaxFPS 120</code>
| Setzt die Engine-Framerate für reproduzierbare Frame-Coupling-Tests.
|-
| <code>t.MaxFPS 0</code>
| Entfernt das normale <code>t.MaxFPS</code>-Limit. Dieser Lauf ist als zusätzliche Diagnose-Gegenprobe vorgesehen.
|}

== Aktueller nächster Schritt ==

Der nächste Schritt ist, den '''QueueProbe-Lifecycle nach der bereits abgeschlossenen nativen Fence-Operation''' zu entkoppeln: Warum bleibt der Slot nach einer etwa 0,014 ms schnellen Fence-Completion noch durchschnittlich rund 32,4 ms bis zum nächsten erfolgreichen Submit belegt? Danach soll eine private native Queue WorkerReady-Wait und Cross-Adapter-Copy zunächst ausschließlich mit privaten Ressourcen testen. Erst auf dieser Grundlage wird entschieden, wie ein sicherer Experimental-Modus mit Capability-Selbsttest und automatischem Fallback auf den robusten Normal-Pfad aussehen kann.

== Historische Vorläufer ==

Die Grundidee heterogener Multi-GPU-Nutzung ist nicht neu. Bereits mit der Einführung von Direct3D 12 entstanden mehrere Versuche, integrierte und dedizierte GPUs gemeinsam zu verwenden. Eine allgemein einsetzbare Lösung für moderne UE5-Spiele hat sich daraus jedoch nicht entwickelt.

=== Microsoft und Epic: UE4 Elemental Demo (2015) ===

Microsoft zeigte eine angepasste Unreal-Engine-4-Version der Elemental-Demo, bei der eine NVIDIA-GPU und eine Intel-iGPU gemeinsam arbeiteten. Das erklärte Ziel war, ansonsten ungenutzte Grafikleistung in Hybrid-Systemen zu verwenden. Dieser Versuch ist der Grundidee des Projekts besonders ähnlich, blieb aber eine technische Demonstration.

=== Intel: D3D12 Multi-Adapter Sample (2015) ===

Intels Beispiel kombinierte eine GeForce 840M mit Intel HD Graphics 5500. Beide GPUs berechneten getrennte Teile einer einfach parallelisierbaren Raytracing-Szene. Cross-Adapter-Ressourcen und Shared Fences führten die Ergebnisse anschließend zusammen. Intel berichtete in diesem Test von nahezu halbierter Framezeit, warnte jedoch ausdrücklich davor, das Ergebnis unmittelbar auf reale Spiele zu übertragen.

=== Ashes of the Singularity ===

Die Nitrous Engine von ''Ashes of the Singularity'' setzte Direct3D-12-Explicit-Multiadapter in einem veröffentlichten Spiel ein. Dabei konnten auch unterschiedliche GPU-Modelle und Hersteller zusammenarbeiten. Das war ein wichtiger Praxisnachweis, blieb in der Spielebranche aber eine seltene Ausnahme.

=== Weitere verwandte Ansätze ===

* ''Rise of the Tomb Raider'' erhielt explizite Direct3D-12-Multi-GPU-Unterstützung, vor allem für klassische Kombinationen ähnlicher GPUs.
* NVIDIA VR SLI wies bei Virtual Reality jeder GPU ein Auge zu. Das verteilt unabhängige Ansichten, bleibt jedoch NVIDIA-spezifisch.
* Unreal nDisplay kann Viewports oder Frustums auf weitere GPUs beziehungsweise Prozesse auslagern und das fertige Bild zur Ausgabe-GPU zurückführen. Der Einsatzbereich ist hauptsächlich Virtual Production.
* Forschung und High-Performance Computing verwenden seit Jahren Scheduler für heterogene GPUs, allerdings überwiegend für Compute- und Datenverarbeitungsaufgaben statt für einen allgemeinen UE5-Echtzeitrenderer.

=== Abgrenzung dieses Projekts ===

Das Projekt erfindet Direct3D-12-Explicit-Multiadapter nicht neu. Sein eigener Ansatz liegt in der Kombination aus tiefer UE5.8-RHI-Integration, UE-kompilierten Shadern auf unabhängigen Worker-Devices, frei wählbaren Spiel- und Compute-Workloads, Capability- und Performance-Scheduler, mehreren Fallback-Pfaden sowie dem langfristigen Ziel beliebiger Hersteller und mehrerer Worker.

== Vergleich mit anderen Multi-GPU-Verfahren ==

{| class="wikitable"
! Verfahren
! Arbeitsweise
! Verhältnis zu diesem Projekt
|-
| SLI / CrossFire
| Treiber- beziehungsweise Verbundlösung für meist ähnliche GPUs; häufig wird die Bildarbeit verteilt.
| Dieses Projekt benötigt keinen herstellerspezifischen GPU-Verbund und weist Aufgaben ausdrücklich selbst zu.
|-
| AFR (Alternate Frame Rendering)
| GPU 1 rendert einen Frame, GPU 2 den nächsten.
| Das Projekt verteilt unabhängige Aufgaben statt aufeinanderfolgender Frames. Dadurch werden Frame-Abhängigkeiten und typisches AFR-Pacing vermieden.
|-
| SFR (Split Frame Rendering)
| Mehrere GPUs bearbeiten Bereiche desselben Frames.
| Erfordert enge Lastverteilung und viel Datenaustausch. Das Projekt bevorzugt vollständig abgrenzbare Workloads und überträgt deren Ergebnis.
|-
| Direct3D 12 Linked Multiadapter
| Mehrere vom Treiber verbundene GPUs erscheinen als Knoten eines logischen Adapters.
| Eignet sich eher für eng kompatible GPUs. Das Projekt verwendet unabhängige Devices (Unlinked/Explicit Multiadapter) und unterstützt dadurch heterogene Herstellerkombinationen.
|-
| Direct3D 12 Unlinked / Explicit Multiadapter
| Die Anwendung verwaltet getrennte Adapter, Ressourcen und Synchronisation selbst.
| Das ist die technische Familie des Projekts. Hinzu kommen die eigene UE5-RHI-Integration, Workload-Ziele, Fallbacks und der geplante Scheduler.
|-
| UE nDisplay mGPU / Multi-Process
| Separate GPUs rendern bestimmte Viewports oder Frustums, vor allem für Virtual Production; Ergebnisse werden zur Ausgabe-GPU kopiert.
| Ähnliche Idee der aufgabenweisen Trennung, aber für einen anderen Einsatzbereich. Dieses Projekt zielt auf allgemeine Spiel- und Compute-Workloads innerhalb der Engine.
|-
| Vulkan Device Groups
| Ähnliche physische GPUs können ein gemeinsames logisches Device bilden.
| Für beliebige heterogene GPUs meist ungeeignet, da Geräte einer Gruppe nahezu gleiche Eigenschaften besitzen müssen. Eine spätere Vulkan-Portierung benötigt daher wahrscheinlich getrennte Devices und External Memory/Semaphores.
|}

SLI und CrossFire bezeichnen den Verbund; AFR und SFR beschreiben mögliche Verteilungsmethoden innerhalb solcher Systeme. Sie sind deshalb nicht vollständig getrennte Kategorien.

== Vorteile der geplanten Variante ==

* '''Herstellerunabhängig:''' NVIDIA, AMD und Intel können grundsätzlich kombiniert werden.
* '''Vorhandene Hardware nutzen:''' Auch eine sonst wenig genutzte integrierte GPU kann geeignete Nebenaufgaben übernehmen.
* '''Aufgaben statt Frames verteilen:''' Spiegel, Minimap oder Compute können mit eigener Auflösung und Aktualisierungsrate laufen.
* '''Keine identischen GPUs erforderlich:''' Unterschiedliche Fähigkeiten können gezielt genutzt werden.
* '''Kontrollierter Datenaustausch:''' Nur das benötigte Ergebnis muss zurück zur Primary-GPU.
* '''Robuste Fallback-Idee:''' Wenn direkte Texturen nicht gemeinsam nutzbar sind, bleibt der Shared-Buffer-Pfad.
* '''Erweiterbar:''' Scheduler, manuelles Mapping und mehrere Worker sind als spätere Stufen vorgesehen.

== Nachteile und technische Risiken ==

* '''Hoher Entwicklungsaufwand:''' Geräte, Ressourcen, Zustände, Fences, Fehlerfälle und UE-Lebenszyklen müssen selbst verwaltet werden.
* '''Transfer kann den Gewinn aufzehren:''' Cross-Adapter Heaps liegen laut D3D12 nicht automatisch im schnellen lokalen VRAM. Bandbreite und Latenz müssen für jeden Workload gemessen werden.
* '''VRAM wird nicht einfach addiert:''' Benötigte Ressourcen können auf mehreren GPUs vorliegen und zusätzlichen Speicher verbrauchen.
* '''Langsame Worker können bremsen:''' Eine Aufgabe lohnt sich nur, wenn Rechengewinn größer als Übergabe-, Warte- und Kopierkosten ist.
* '''Nicht jeder Workload ist unabhängig:''' Hauptansicht, Lumen, Nanite und stark gekoppelte Renderpässe besitzen viele Abhängigkeiten und sind schwieriger auszulagern.
* '''Hardwareunterschiede:''' Formate, Shader-Funktionen, Queue-Fähigkeiten und Cross-Adapter-Support müssen pro GPU geprüft werden.
* '''Wartungsrisiko:''' Eingriffe in private D3D12RHI-Dateien können bei Engine-Updates angepasst werden müssen.
* '''Produktionsreife fehlt noch:''' Ressourcenpools, Timeouts, Device-Lost-Wiederherstellung, Scheduler und echte Szenentests sind offen.

== Wann die Variante sinnvoll ist ==

Am aussichtsreichsten sind Aufgaben mit viel eigener Rechenarbeit, einem relativ kleinen Endergebnis und wenigen Abhängigkeiten zur Hauptszene. Gute frühe Kandidaten sind unabhängige Compute-Aufgaben sowie Scene Captures, die nicht in jedem Frame aktualisiert werden müssen. Weniger geeignet sind winzige Aufgaben mit großem Transfer oder Renderpässe, die ständig auf Ressourcen der Primary-GPU zugreifen.

Die entscheidende Regel für den späteren Scheduler lautet daher:

<pre>
Worker-Gewinn > Vorbereitung + Datentransfer + Synchronisation + Rückintegration
</pre>

== Bekannte Grenzen des Proof of Concepts ==

* Der asynchrone 128×96-End-to-End-Pfad ist über Dimensionen, Dispatch, Transfer, Fences, Pending/Ready und Reuse verifiziert; ein eigener 128×96-Pixel-Readback fehlt noch. Der synchrone 64×64-Debugtest prüft weiterhin alle 4096 Pixel.
* Der Normal-Transport unterstützt derzeit <code>DXGI_FORMAT_R8G8B8A8_UNORM</code> mit Sample Count 1; weitere Formate, Mips, Arrays, Slices und MSAA sind offen.
* Pro Worker existiert absichtlich nur ein persistenter Runtime-Slot. Mehrere parallele In-Flight-Jobs sowie Double-, Triple- oder Ring-Buffering fehlen noch.
* Die Primary-/SafeCopy-/Ready-Kette bleibt trotz zusätzlichem non-blocking <code>DispatchToRHIThread</code> effektiv an den Frame-/Submission-Zyklus gekoppelt.
* QueueProbe ist reine Diagnose. Der native Modus verwendet bisher nur QueueSignal und Fence, keine Textur oder Cross-Adapter-Ressource.
* Es gibt noch keine Umschaltung zwischen Normal und Experimental sowie keinen automatischen Session-Fallback.
* Raw-D3D12-Shared-Ressourcen sind noch nicht vollständig in Unreals Residency-Management eingebunden.
* Praktisch getestet ist Primary plus ein Worker. Die Architektur ist auf mehrere Worker ausgelegt, N-GPU ist aber noch nicht praktisch validiert.
* Der sichtbare TPS-Nachweis zeigt eine Worker-Compute-Textur, noch keine auf dem Worker gerenderte 3D-Szene. Echte UE-Szenen-Workloads, Benchmark-Wizard und Scheduler fehlen weiterhin.
* Die projektseitigen UpscalerTest-Dateien mit DisplayActor und Texture Stream liegen außerhalb des Engine-Git-Repositories und sind nicht Bestandteil von Commit <code>43a5c07</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.

== Roadmap ==

# QueueProbe-Lifecycle entkoppeln und die verzögerte Slot-Freigabe nach schneller nativer Fence-Completion erklären.
# WorkerReady-Wait und Cross-Adapter-Copy auf einer privaten Primary-Ressource über die native Queue testen.
# Experimental-Architektur mit Capability-Selbsttest, Normal/Experimental-Einstellung und automatischem Session-Fallback definieren.
# Erst danach eine UE-sichtbare Experimental-Textur mit korrektem State-Tracking, Residency, Queue-Reihenfolge und Consumer-Synchronisation untersuchen.
# Nur bei nachgewiesenem Bedarf einen zweiten Slot oder Ringbuffer mit Generation-, Fence-, Reuse- und Consumer-Hazard-Modell ergänzen.
# Ersten echten UE-Offload wie SceneCapture2D, CCTV, Spiegel, Minimap, Niagara oder unabhängigen Compute integrieren.
# Formate, Mips, Arrays/Slices und gegebenenfalls MSAA capability-basiert erweitern.
# Capability-Matrix, Benchmark-Wizard, Scheduler und manuelle Overrides entwickeln.
# Mehrere Worker-GPUs unterstützen.
# Fallback-Matrix aus Normal Shared Buffer, System-RAM/Staging und einem späteren Experimental Fast Path ergänzen.
# Linux/Vulkan mit getrennten Devices, External Memory und externer Synchronisation untersuchen.

== Quellen ==

* Interner Entwicklungsstand und verifizierte Testprotokolle vom 7. September 2026, Commit <code>43a5c07</code>; vorheriger Checkpoint <code>cbf56c2</code>
* [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/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://www.intel.com/content/dam/develop/external/us/en/documents/multi-adapter-support-in-directx-12-594015.pdf Intel: Multi-Adapter Support in DirectX 12]
* [https://devblogs.microsoft.com/directx/ashes-of-the-singularity-makes-gaming-history-with-directx-12/ Microsoft: Ashes of the Singularity und heterogene Adapter]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/nvidia-sli-alternative-frame-rendering-in-unreal-engine Epic: NVIDIA SLI Alternate Frame Rendering]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/multi-process-rendering-with-unreal-engine Epic: Multi-Process Rendering]
* [https://registry.khronos.org/vulkan/specs/latest/pdf/vkspec.pdf Khronos: Vulkan Specification – Device Groups]

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Multi-GPU]]
[[Kategorie:Direct3D 12]]
[[Kategorie:Experimentell]]

UE5 Heterogeneous Multi-GPU

2026-09-06T23:32:14Z

Elaina:

{{Hinweis|Projektstand: 7. September 2026, Commit <code>43a5c07</code>. 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.

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.

{| class="wikitable"
|+ Projektstatus
|-
! Engine / Plattform
| Unreal Engine 5.8 Source Build / Windows / Direct3D 12
|-
! Testsystem
| Lenovo LOQ 17IRX10
|-
! Primary
| NVIDIA GeForce RTX 5060 Laptop GPU
|-
! Worker
| Intel UHD Graphics
|-
! Git-Stand
| Commit <code>43a5c07</code> auf Branch <code>mgpu-experimental</code>
|-
! Windows/D3D12-Proof-of-Concept
| Sichtbarer 128×96-Worker-Texture-Stream im TPS sowie isolierte Diagnose der Primary-Queue-/Submission-Latenz nachgewiesen
|-
! Gesamtvision
| etwa 30–35 % (Scheduler, echte Workloads, N-GPU und Vulkan noch offen)
|}

== Grundprinzip ==

<pre>
Intel Worker GPU
-> MainTextureCS + PatternPhase
-> persistente Worker-Textur
-> persistenter Shared Cross-Adapter Buffer
-> monotone Shared Fence / Queue Wait
-> persistente UE-eigene FTextureRHIRef
-> stabile UExperimentalMultiGPUTexture

RTX Primary GPU
-> normales UE5-Rendering
-> TPS-Material zeigt das Worker-Ergebnis sichtbar an
</pre>

Pro Worker ist maximal ein Runtime-Job gleichzeitig in flight. Backpressure lehnt weitere Requests als <code>Busy</code> ab, bis der Slot nach der Primary-Completion wieder sicher verwendbar ist.

Jeder Worker besitzt ein eigenes <code>ID3D12Device</code>, eigene Queues, Command Lists und Ressourcen. Ein späterer Scheduler soll Rechenleistung, Fähigkeiten, Transferkosten und gewünschte Aktualisierungsrate bewerten. Vorgesehene Aufgaben sind beispielsweise SceneCapture2D, Spiegel, CCTV, Minimap, Compute oder Niagara.

== Verifizierter Entwicklungsstand ==

=== Worker-Compute ===

Ein echter, von Unreal kompilierter Global Compute Shader läuft auf der Intel UHD, während Unreal regulär über die RTX rendert. Der Test verdoppelt 64 Ganzzahlen auf dem Worker; '''64 von 64 Ergebnissen wurden korrekt verifiziert'''. Damit ist echte GPU-Arbeit auf einem zweiten, herstellerfremden Device nachgewiesen.

Zusätzlich läuft <code>MainTextureCS</code> auf der Intel-GPU. Der synchrone Debugtest erzeugt eine 64 × 64 Pixel große RGBA8-Textur; '''alle 4096 shader-generierten Pixel wurden korrekt verifiziert'''. Der normale Runtime-Pfad verwendet inzwischen einen asynchronen 128×96-Test. Der Shader liest seine Dimensionen mit <code>GetDimensions()</code>, schützt überhängende Threads durch einen Bounds-Check und wird mit <code>Dispatch(16,12,1)</code> ausgeführt. <code>PatternPhase</code> erzeugt für jeden akzeptierten Submit deterministisch einen neuen sichtbaren Inhalt. Abgewiesene Busy-Requests erhöhen die Phase nicht und erzeugen daher keine Lücken.

=== Cross-Adapter-Speicher und Synchronisation ===

* RTX und Intel öffnen denselben D3D12 Cross-Adapter Heap.
* Ein gemeinsamer Buffer wurde mit 64 Testwerten erfolgreich geprüft.
* Ein persistenter Shared Fence synchronisiert die Queues direkt von GPU zu GPU. Seine Werte steigen pro Job monoton: WorkerReady/PrimaryComplete verwenden die Paare 1/2, 3/4, 5/6 und so weiter.
* Die CPU vermittelt die GPU-Abhängigkeit nicht; Worker- und Primary-Queue verwenden <code>Signal</code> und <code>Wait</code> direkt auf der GPU.
* Der separate Readback-Verifikationstest darf weiterhin blockieren. Der normale Runtime-Pfad wartet dagegen nicht auf GPU-Leerlauf.

=== Texturtransport ===

Direkte Cross-Adapter-Texturen sind auf dem Testsystem nicht beidseitig verfügbar: Die Intel UHD meldet Unterstützung für Row-Major Cross-Adapter Textures, die RTX 5060 Laptop GPU nicht. Deshalb verwendet das Projekt einen allgemeineren Buffer-Fallback.

<pre>
Intel MainTextureCS
-> persistente Worker-Textur
-> CopyTextureRegion
-> persistenter Shared Cross-Adapter Buffer
-> Worker signalisiert WorkerReady (1, 3, 5, ...)
-> UE-Primary-Queue wartet auf WorkerReady
-> direkte Kopie in persistente UE-eigene FTextureRHIRef
-> Primary signalisiert PrimaryComplete (2, 4, 6, ...)
</pre>

Der robuste Normal-Pfad kopiert die Worker-Textur über den Shared Buffer direkt in eine von Unreal erzeugte <code>FTextureRHIRef</code>. Breite, Höhe und Row Pitch werden dynamisch aus Worker-Ressource und Transport-Metadaten übernommen. Der erfolgreiche 128×96-RGBA8-Test verwendet 512 Byte Row Pitch und 49.152 Byte Transfergröße. Die Output Registry trennt Persistent-, Pending- und Ready-Zustände sowie Inhaltsgeneration und Texturidentität. Dadurch kann eine verspätete Completion keinen neueren Output zurückrollen.

=== Non-blocking Runtime-Pfad ===

Die produktive Testlogik ist aus dem Konsolenkommando in eine gekapselte NormalPath-API verschoben. <code>SubmitWorkerTextureComputeJob()</code> reicht den Worker-Dispatch ohne CPU-Wait ein. <code>QueueNormalTextureTransfer()</code> reiht Wait, Kopie und Completion-Signal in Unreals D3D12-Kontext ein. Der normale MainTextureCS-Pfad enthält weder CPU-Fence-Waits noch Readback, <code>Map</code> oder Pixelvergleich. <code>TickNormalTextureTransfers()</code> prüft die Primary-Completion non-blocking über einen Runtime-Pump; <code>RHIEndFrame()</code> bleibt als Fallback erhalten.

Eine passende Primary-<code>FTextureRHIRef</code> wird pro Worker und Konfiguration persistent gehalten. Nach PrimaryComplete kann der nächste Job dieselbe Resource erneut verwenden; dabei führt Unreal die Übergänge <code>SRVMask -> CopyDest -> SRVMask</code> aus. Eine backend-neutrale RHI-Provider-API reicht die Ready-Textur an die Engine weiter. <code>UExperimentalMultiGPUTexture</code> hält eine stabile <code>UTexture</code> samt TextureReference und bindet die persistente <code>FTextureRHIRef</code> ohne zusätzlichen Pixel-Copy. Eine native D3D12-Resource wird weiterhin nicht blind als UE-Textur gewrappt, weil Unreals Resource-State-Buchhaltung den tatsächlichen nativen Zustand sonst nicht sicher kennt.

=== Sichtbarer TPS-Consumer ===

<code>AExperimentalMultiGPUDisplayActor</code> zeigt die Worker-Ausgabe im Third-Person-Testlevel über den Materialparameter <code>MultiGPUTexture</code> an. Damit ist der Output nicht mehr nur über Logs oder Readback nachgewiesen: Die Intel UHD erzeugt fortlaufend die Texturinhalte, während die RTX die Spielwelt und das Material rendert. <code>TextureConsumerCS</code> kann Ready-Ausgaben auf der Primary zusätzlich als SRV lesen und fünf quantisierte Samples im Debugpfad prüfen.

=== Lebensdauer und automatisches Cleanup ===

Der Normal-Pfad verwendet pro Worker genau einen persistenten Runtime-Slot. Worker-Textur, Root Signature, PSO, Descriptor Heap, Command Allocator/List und Worker-Fence werden nach der ersten kompatiblen Initialisierung wiederverwendet. Dasselbe gilt für Shared Heap/Buffer/Fence und die Transport-Command-Objekte. Der In-Flight-Job trägt nur noch die nötigen Job-, Generation- und Fence-Metadaten.

<pre>
Runtime Request
-> Completion non-blocking prüfen
-> falls Slot frei: Worker Dispatch
-> WorkerReady-Fence signalisieren
-> Primary Wait, SafeCopy und PrimaryComplete-Signal
-> Output Pending
-> Runtime-Pump oder RHIEndFrame prüft GetCompletedValue()
-> Output Ready publizieren
-> Slot wiederverwendbar
</pre>

Backpressure erlaubt maximal einen echten In-Flight-Job pro Worker. Ein Busy-Request setzt keine GPU-Arbeit ab, setzt keine Ressourcen zurück und erhöht <code>PatternPhase</code> nicht. Worker-Fence-Werte steigen mit jedem akzeptierten Submit 1, 2, 3 und so weiter; der persistente Shared Fence verwendet fortlaufend die Paare 1/2, 3/4, 5/6. Fehler nach Übergabe von Ressourcen an die GPU führen zu sicherem Retire beziehungsweise Retention statt zu vorzeitigem Reuse.

=== Texture Stream und Benchmarking ===

Der projektseitige Texture Stream akzeptiert eine beliebige positive, endliche Zielrate. Punkt und Komma sind als Dezimaltrenner möglich. Optional lässt sich die Zahl erfolgreicher Submits begrenzen; Busy- oder Failed-Versuche verbrauchen dieses Limit nicht. Der Quiet-Modus unterdrückt per-Job-Ausgaben, behält aber Start, echte Fehler und die Abschlussstatistik bei.

<pre>
ExperimentalMultiGPU.StartTextureStream 37,5
ExperimentalMultiGPU.StartTextureStream 37,5 25
ExperimentalMultiGPU.StartTextureStream 1000 100 quiet
ExperimentalMultiGPU.StopTextureStream
</pre>

Die Statistik unterscheidet Timer-Ticks, angenommene Submits, Busy/Failed, Ready, In-Flight und die jeweiligen effektiven Raten. Diagnosezeitpunkte erfassen unter anderem RequestAccepted, RenderCommandExecution, WorkerSubmit, NormalTransferQueued und ReadyObserved.

{| class="wikitable"
! Test
! Ergebnis
! Aussage
|-
| 5 Hz, 20 Submits
| etwa 5 Ready/s, 20/20, kein Busy
| Entspannter Single-Slot-Betrieb
|-
| 1000 Hz, 100 Submits, quiet
| 100/100 Ready, 0 Fehler, etwa 58 Ready/s
| Backpressure begrenzt den Durchsatz sicher
|-
| 1000 Hz bei <code>t.MaxFPS 30</code>
| etwa 28–29 Ready/s trotz rund 982 Timer-Ticks/s
| Primary-/SafeCopy-/Ready-Kette ist effektiv framegekoppelt
|}

Ein zusätzlicher non-blocking Aufruf von <code>ImmediateFlush(DispatchToRHIThread)</code> erreicht hohe Render-Command-Raten, hebt die gemessene Frame-Kopplung aber nicht auf. Im 30-FPS-Test lag der RHIEndFrame-spezifische Completion-Takt praktisch exakt bei 30 Hz. Das aktuelle Problem ist damit eingegrenzt: Nicht der Stream-Timer, sondern die Primary-RHI-/D3D12-Submission der SafeCopy-Kette bestimmt die sichtbare Ready-Rate.

=== Queue-Submission-Diagnose ===

<code>MultiGPUD3D12QueueProbe</code> untersucht die Submission unabhängig vom sichtbaren Texturpfad. Der Probe besitzt die Modi <code>full</code>, <code>waitonly</code> und <code>signalonly</code> sowie die Queue-Auswahl <code>graphics</code>, <code>copy</code> und <code>native</code>. Graphics und Copy verwenden <code>RHIRunOnQueue(..., false)</code> auf UE-verwalteten Queues. Native verwendet derzeit ausschließlich im Signal-only-Modus eine eigene persistente D3D12-DIRECT-Queue auf dem Primary-Device.

<pre>
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly graphics
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly copy
ExperimentalMultiGPU.StartQueueProbe 1000 100 quiet signalonly native
</pre>

Der Probe misst Request, Worker-Submit, <code>RHIRunOnQueue</code>-Aufruf und -Callback, Primary-Execute, Fence-Completion sowie Ready bis zum nächsten akzeptierten Submit. Er fügt keine CPU-Waits, Readbacks, Maps oder <code>BlockUntilGPUIdle</code> ein und beschreibt keine Textur des sichtbaren Normal-Pfads.

{| class="wikitable"
! Signal-only-Test
! PrimaryExecute bis Ready
! Befund
|-
| UE Graphics Queue, 30 FPS
| 33,319 ms
| skaliert praktisch mit der Frame-Dauer
|-
| UE Graphics Queue, 60 FPS
| 16,377 ms
| skaliert praktisch mit der Frame-Dauer
|-
| UE Graphics Queue, 120 FPS
| 8,712 ms
| skaliert praktisch mit der Frame-Dauer
|-
| UE Copy Queue, 30 / 120 FPS
| 32,593 / 8,206 ms
| Copy Queue ist ebenfalls framegekoppelt
|-
| Private native DIRECT Queue, 30 FPS
| durchschnittlich 0,014 ms; 0,001–0,037 ms
| D3D12, Treiber und Primary-GPU sind nicht an die Frame-Dauer gebunden
|}

Der <code>RHIRunOnQueue</code>-Callback selbst erreicht den D3D12-Submission-Thread typischerweise bereits nach etwa 0,02–0,05 ms; die Verzögerung entsteht danach in der verwalteten Queue-/Submission-Reihenfolge. <code>SubmitCommandsHint()</code> ist in UE 5.8 nur ein veralteter Alias für <code>ImmediateFlush(DispatchToRHIThread)</code> und stellt daher keinen stärkeren Submission-Mechanismus dar.

Der native Test ist ein '''Architekturbeweis, noch kein Experimental- oder Direct-Modus'''. Er signalisiert nur einen privaten Fence und verwendet weder WorkerReady-Wait noch Cross-Adapter-Copy, UE-eigene Textur oder Engine-State-Tracking. Obwohl sein Fence nach rund 0,014 ms fertig ist, erreicht der gesamte Probe bei 30 FPS nur etwa 30,75 Ready/s; <code>Ready -> NextSubmit</code> dauert im Mittel 32,403 ms. Damit ist als nächster Engpass der Lifecycle beziehungsweise die Freigabe des Single Slots isoliert.

== Aktueller nächster Schritt ==

Der nächste Schritt ist, den '''QueueProbe-Lifecycle nach der bereits abgeschlossenen nativen Fence-Operation''' zu entkoppeln: Warum bleibt der Slot nach einer etwa 0,014 ms schnellen Fence-Completion noch durchschnittlich rund 32,4 ms bis zum nächsten erfolgreichen Submit belegt? Danach soll eine private native Queue WorkerReady-Wait und Cross-Adapter-Copy zunächst ausschließlich mit privaten Ressourcen testen. Erst auf dieser Grundlage wird entschieden, wie ein sicherer Experimental-Modus mit Capability-Selbsttest und automatischem Fallback auf den robusten Normal-Pfad aussehen kann.

== Historische Vorläufer ==

Die Grundidee heterogener Multi-GPU-Nutzung ist nicht neu. Bereits mit der Einführung von Direct3D 12 entstanden mehrere Versuche, integrierte und dedizierte GPUs gemeinsam zu verwenden. Eine allgemein einsetzbare Lösung für moderne UE5-Spiele hat sich daraus jedoch nicht entwickelt.

=== Microsoft und Epic: UE4 Elemental Demo (2015) ===

Microsoft zeigte eine angepasste Unreal-Engine-4-Version der Elemental-Demo, bei der eine NVIDIA-GPU und eine Intel-iGPU gemeinsam arbeiteten. Das erklärte Ziel war, ansonsten ungenutzte Grafikleistung in Hybrid-Systemen zu verwenden. Dieser Versuch ist der Grundidee des Projekts besonders ähnlich, blieb aber eine technische Demonstration.

=== Intel: D3D12 Multi-Adapter Sample (2015) ===

Intels Beispiel kombinierte eine GeForce 840M mit Intel HD Graphics 5500. Beide GPUs berechneten getrennte Teile einer einfach parallelisierbaren Raytracing-Szene. Cross-Adapter-Ressourcen und Shared Fences führten die Ergebnisse anschließend zusammen. Intel berichtete in diesem Test von nahezu halbierter Framezeit, warnte jedoch ausdrücklich davor, das Ergebnis unmittelbar auf reale Spiele zu übertragen.

=== Ashes of the Singularity ===

Die Nitrous Engine von ''Ashes of the Singularity'' setzte Direct3D-12-Explicit-Multiadapter in einem veröffentlichten Spiel ein. Dabei konnten auch unterschiedliche GPU-Modelle und Hersteller zusammenarbeiten. Das war ein wichtiger Praxisnachweis, blieb in der Spielebranche aber eine seltene Ausnahme.

=== Weitere verwandte Ansätze ===

* ''Rise of the Tomb Raider'' erhielt explizite Direct3D-12-Multi-GPU-Unterstützung, vor allem für klassische Kombinationen ähnlicher GPUs.
* NVIDIA VR SLI wies bei Virtual Reality jeder GPU ein Auge zu. Das verteilt unabhängige Ansichten, bleibt jedoch NVIDIA-spezifisch.
* Unreal nDisplay kann Viewports oder Frustums auf weitere GPUs beziehungsweise Prozesse auslagern und das fertige Bild zur Ausgabe-GPU zurückführen. Der Einsatzbereich ist hauptsächlich Virtual Production.
* Forschung und High-Performance Computing verwenden seit Jahren Scheduler für heterogene GPUs, allerdings überwiegend für Compute- und Datenverarbeitungsaufgaben statt für einen allgemeinen UE5-Echtzeitrenderer.

=== Abgrenzung dieses Projekts ===

Das Projekt erfindet Direct3D-12-Explicit-Multiadapter nicht neu. Sein eigener Ansatz liegt in der Kombination aus tiefer UE5.8-RHI-Integration, UE-kompilierten Shadern auf unabhängigen Worker-Devices, frei wählbaren Spiel- und Compute-Workloads, Capability- und Performance-Scheduler, mehreren Fallback-Pfaden sowie dem langfristigen Ziel beliebiger Hersteller und mehrerer Worker.

== Vergleich mit anderen Multi-GPU-Verfahren ==

{| class="wikitable"
! Verfahren
! Arbeitsweise
! Verhältnis zu diesem Projekt
|-
| SLI / CrossFire
| Treiber- beziehungsweise Verbundlösung für meist ähnliche GPUs; häufig wird die Bildarbeit verteilt.
| Dieses Projekt benötigt keinen herstellerspezifischen GPU-Verbund und weist Aufgaben ausdrücklich selbst zu.
|-
| AFR (Alternate Frame Rendering)
| GPU 1 rendert einen Frame, GPU 2 den nächsten.
| Das Projekt verteilt unabhängige Aufgaben statt aufeinanderfolgender Frames. Dadurch werden Frame-Abhängigkeiten und typisches AFR-Pacing vermieden.
|-
| SFR (Split Frame Rendering)
| Mehrere GPUs bearbeiten Bereiche desselben Frames.
| Erfordert enge Lastverteilung und viel Datenaustausch. Das Projekt bevorzugt vollständig abgrenzbare Workloads und überträgt deren Ergebnis.
|-
| Direct3D 12 Linked Multiadapter
| Mehrere vom Treiber verbundene GPUs erscheinen als Knoten eines logischen Adapters.
| Eignet sich eher für eng kompatible GPUs. Das Projekt verwendet unabhängige Devices (Unlinked/Explicit Multiadapter) und unterstützt dadurch heterogene Herstellerkombinationen.
|-
| Direct3D 12 Unlinked / Explicit Multiadapter
| Die Anwendung verwaltet getrennte Adapter, Ressourcen und Synchronisation selbst.
| Das ist die technische Familie des Projekts. Hinzu kommen die eigene UE5-RHI-Integration, Workload-Ziele, Fallbacks und der geplante Scheduler.
|-
| UE nDisplay mGPU / Multi-Process
| Separate GPUs rendern bestimmte Viewports oder Frustums, vor allem für Virtual Production; Ergebnisse werden zur Ausgabe-GPU kopiert.
| Ähnliche Idee der aufgabenweisen Trennung, aber für einen anderen Einsatzbereich. Dieses Projekt zielt auf allgemeine Spiel- und Compute-Workloads innerhalb der Engine.
|-
| Vulkan Device Groups
| Ähnliche physische GPUs können ein gemeinsames logisches Device bilden.
| Für beliebige heterogene GPUs meist ungeeignet, da Geräte einer Gruppe nahezu gleiche Eigenschaften besitzen müssen. Eine spätere Vulkan-Portierung benötigt daher wahrscheinlich getrennte Devices und External Memory/Semaphores.
|}

SLI und CrossFire bezeichnen den Verbund; AFR und SFR beschreiben mögliche Verteilungsmethoden innerhalb solcher Systeme. Sie sind deshalb nicht vollständig getrennte Kategorien.

== Vorteile der geplanten Variante ==

* '''Herstellerunabhängig:''' NVIDIA, AMD und Intel können grundsätzlich kombiniert werden.
* '''Vorhandene Hardware nutzen:''' Auch eine sonst wenig genutzte integrierte GPU kann geeignete Nebenaufgaben übernehmen.
* '''Aufgaben statt Frames verteilen:''' Spiegel, Minimap oder Compute können mit eigener Auflösung und Aktualisierungsrate laufen.
* '''Keine identischen GPUs erforderlich:''' Unterschiedliche Fähigkeiten können gezielt genutzt werden.
* '''Kontrollierter Datenaustausch:''' Nur das benötigte Ergebnis muss zurück zur Primary-GPU.
* '''Robuste Fallback-Idee:''' Wenn direkte Texturen nicht gemeinsam nutzbar sind, bleibt der Shared-Buffer-Pfad.
* '''Erweiterbar:''' Scheduler, manuelles Mapping und mehrere Worker sind als spätere Stufen vorgesehen.

== Nachteile und technische Risiken ==

* '''Hoher Entwicklungsaufwand:''' Geräte, Ressourcen, Zustände, Fences, Fehlerfälle und UE-Lebenszyklen müssen selbst verwaltet werden.
* '''Transfer kann den Gewinn aufzehren:''' Cross-Adapter Heaps liegen laut D3D12 nicht automatisch im schnellen lokalen VRAM. Bandbreite und Latenz müssen für jeden Workload gemessen werden.
* '''VRAM wird nicht einfach addiert:''' Benötigte Ressourcen können auf mehreren GPUs vorliegen und zusätzlichen Speicher verbrauchen.
* '''Langsame Worker können bremsen:''' Eine Aufgabe lohnt sich nur, wenn Rechengewinn größer als Übergabe-, Warte- und Kopierkosten ist.
* '''Nicht jeder Workload ist unabhängig:''' Hauptansicht, Lumen, Nanite und stark gekoppelte Renderpässe besitzen viele Abhängigkeiten und sind schwieriger auszulagern.
* '''Hardwareunterschiede:''' Formate, Shader-Funktionen, Queue-Fähigkeiten und Cross-Adapter-Support müssen pro GPU geprüft werden.
* '''Wartungsrisiko:''' Eingriffe in private D3D12RHI-Dateien können bei Engine-Updates angepasst werden müssen.
* '''Produktionsreife fehlt noch:''' Ressourcenpools, Timeouts, Device-Lost-Wiederherstellung, Scheduler und echte Szenentests sind offen.

== Wann die Variante sinnvoll ist ==

Am aussichtsreichsten sind Aufgaben mit viel eigener Rechenarbeit, einem relativ kleinen Endergebnis und wenigen Abhängigkeiten zur Hauptszene. Gute frühe Kandidaten sind unabhängige Compute-Aufgaben sowie Scene Captures, die nicht in jedem Frame aktualisiert werden müssen. Weniger geeignet sind winzige Aufgaben mit großem Transfer oder Renderpässe, die ständig auf Ressourcen der Primary-GPU zugreifen.

Die entscheidende Regel für den späteren Scheduler lautet daher:

<pre>
Worker-Gewinn > Vorbereitung + Datentransfer + Synchronisation + Rückintegration
</pre>

== Bekannte Grenzen des Proof of Concepts ==

* Der asynchrone 128×96-End-to-End-Pfad ist über Dimensionen, Dispatch, Transfer, Fences, Pending/Ready und Reuse verifiziert; ein eigener 128×96-Pixel-Readback fehlt noch. Der synchrone 64×64-Debugtest prüft weiterhin alle 4096 Pixel.
* Der Normal-Transport unterstützt derzeit <code>DXGI_FORMAT_R8G8B8A8_UNORM</code> mit Sample Count 1; weitere Formate, Mips, Arrays, Slices und MSAA sind offen.
* Pro Worker existiert absichtlich nur ein persistenter Runtime-Slot. Mehrere parallele In-Flight-Jobs sowie Double-, Triple- oder Ring-Buffering fehlen noch.
* Die Primary-/SafeCopy-/Ready-Kette bleibt trotz zusätzlichem non-blocking <code>DispatchToRHIThread</code> effektiv an den Frame-/Submission-Zyklus gekoppelt.
* QueueProbe ist reine Diagnose. Der native Modus verwendet bisher nur QueueSignal und Fence, keine Textur oder Cross-Adapter-Ressource.
* Es gibt noch keine Umschaltung zwischen Normal und Experimental sowie keinen automatischen Session-Fallback.
* Raw-D3D12-Shared-Ressourcen sind noch nicht vollständig in Unreals Residency-Management eingebunden.
* Praktisch getestet ist Primary plus ein Worker. Die Architektur ist auf mehrere Worker ausgelegt, N-GPU ist aber noch nicht praktisch validiert.
* Der sichtbare TPS-Nachweis zeigt eine Worker-Compute-Textur, noch keine auf dem Worker gerenderte 3D-Szene. Echte UE-Szenen-Workloads, Benchmark-Wizard und Scheduler fehlen weiterhin.
* Die projektseitigen UpscalerTest-Dateien mit DisplayActor und Texture Stream liegen außerhalb des Engine-Git-Repositories und sind nicht Bestandteil von Commit <code>43a5c07</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.

== Roadmap ==

# QueueProbe-Lifecycle entkoppeln und die verzögerte Slot-Freigabe nach schneller nativer Fence-Completion erklären.
# WorkerReady-Wait und Cross-Adapter-Copy auf einer privaten Primary-Ressource über die native Queue testen.
# Experimental-Architektur mit Capability-Selbsttest, Normal/Experimental-Einstellung und automatischem Session-Fallback definieren.
# Erst danach eine UE-sichtbare Experimental-Textur mit korrektem State-Tracking, Residency, Queue-Reihenfolge und Consumer-Synchronisation untersuchen.
# Nur bei nachgewiesenem Bedarf einen zweiten Slot oder Ringbuffer mit Generation-, Fence-, Reuse- und Consumer-Hazard-Modell ergänzen.
# Ersten echten UE-Offload wie SceneCapture2D, CCTV, Spiegel, Minimap, Niagara oder unabhängigen Compute integrieren.
# Formate, Mips, Arrays/Slices und gegebenenfalls MSAA capability-basiert erweitern.
# Capability-Matrix, Benchmark-Wizard, Scheduler und manuelle Overrides entwickeln.
# Mehrere Worker-GPUs unterstützen.
# Fallback-Matrix aus Normal Shared Buffer, System-RAM/Staging und einem späteren Experimental Fast Path ergänzen.
# Linux/Vulkan mit getrennten Devices, External Memory und externer Synchronisation untersuchen.

== Quellen ==

* Interner Entwicklungsstand und verifizierte Testprotokolle vom 7. September 2026, Commit <code>43a5c07</code>; vorheriger Checkpoint <code>cbf56c2</code>
* [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/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://www.intel.com/content/dam/develop/external/us/en/documents/multi-adapter-support-in-directx-12-594015.pdf Intel: Multi-Adapter Support in DirectX 12]
* [https://devblogs.microsoft.com/directx/ashes-of-the-singularity-makes-gaming-history-with-directx-12/ Microsoft: Ashes of the Singularity und heterogene Adapter]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/nvidia-sli-alternative-frame-rendering-in-unreal-engine Epic: NVIDIA SLI Alternate Frame Rendering]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/multi-process-rendering-with-unreal-engine Epic: Multi-Process Rendering]
* [https://registry.khronos.org/vulkan/specs/latest/pdf/vkspec.pdf Khronos: Vulkan Specification – Device Groups]

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Multi-GPU]]
[[Kategorie:Direct3D 12]]
[[Kategorie:Experimentell]]

UE5 Heterogeneous Multi-GPU

2026-09-06T18:19:08Z

Elaina:

{{Hinweis|Projektstand: 6. September 2026, Commit <code>cbf56c2</code>. 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.

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.

{| class="wikitable"
|+ Projektstatus
|-
! Engine / Plattform
| Unreal Engine 5.8 Source Build / Windows / Direct3D 12
|-
! Testsystem
| Lenovo LOQ 17IRX10
|-
! Primary
| NVIDIA GeForce RTX 5060 Laptop GPU
|-
! Worker
| Intel UHD Graphics
|-
! Git-Stand
| Commit <code>cbf56c2</code> auf Branch <code>mgpu-experimental</code>
|-
! Windows/D3D12-Proof-of-Concept
| Sichtbarer 128×96-Worker-Texture-Stream im TPS, persistenter Single Runtime Slot, stabile UTexture-Bridge und Benchmark-Diagnostik nachgewiesen
|-
! Gesamtvision
| etwa 30–35 % (Scheduler, echte Workloads, N-GPU und Vulkan noch offen)
|}

== Grundprinzip ==

<pre>
Intel Worker GPU
-> MainTextureCS + PatternPhase
-> persistente Worker-Textur
-> persistenter Shared Cross-Adapter Buffer
-> monotone Shared Fence / Queue Wait
-> persistente UE-eigene FTextureRHIRef
-> stabile UExperimentalMultiGPUTexture

RTX Primary GPU
-> normales UE5-Rendering
-> TPS-Material zeigt das Worker-Ergebnis sichtbar an
</pre>

Pro Worker ist maximal ein Runtime-Job gleichzeitig in flight. Backpressure lehnt weitere Requests als <code>Busy</code> ab, bis der Slot nach der Primary-Completion wieder sicher verwendbar ist.

Jeder Worker besitzt ein eigenes <code>ID3D12Device</code>, eigene Queues, Command Lists und Ressourcen. Ein späterer Scheduler soll Rechenleistung, Fähigkeiten, Transferkosten und gewünschte Aktualisierungsrate bewerten. Vorgesehene Aufgaben sind beispielsweise SceneCapture2D, Spiegel, CCTV, Minimap, Compute oder Niagara.

== Verifizierter Entwicklungsstand ==

=== Worker-Compute ===

Ein echter, von Unreal kompilierter Global Compute Shader läuft auf der Intel UHD, während Unreal regulär über die RTX rendert. Der Test verdoppelt 64 Ganzzahlen auf dem Worker; '''64 von 64 Ergebnissen wurden korrekt verifiziert'''. Damit ist echte GPU-Arbeit auf einem zweiten, herstellerfremden Device nachgewiesen.

Zusätzlich läuft <code>MainTextureCS</code> auf der Intel-GPU. Der synchrone Debugtest erzeugt eine 64 × 64 Pixel große RGBA8-Textur; '''alle 4096 shader-generierten Pixel wurden korrekt verifiziert'''. Der normale Runtime-Pfad verwendet inzwischen einen asynchronen 128×96-Test. Der Shader liest seine Dimensionen mit <code>GetDimensions()</code>, schützt überhängende Threads durch einen Bounds-Check und wird mit <code>Dispatch(16,12,1)</code> ausgeführt. <code>PatternPhase</code> erzeugt für jeden akzeptierten Submit deterministisch einen neuen sichtbaren Inhalt. Abgewiesene Busy-Requests erhöhen die Phase nicht und erzeugen daher keine Lücken.

=== Cross-Adapter-Speicher und Synchronisation ===

* RTX und Intel öffnen denselben D3D12 Cross-Adapter Heap.
* Ein gemeinsamer Buffer wurde mit 64 Testwerten erfolgreich geprüft.
* Ein persistenter Shared Fence synchronisiert die Queues direkt von GPU zu GPU. Seine Werte steigen pro Job monoton: WorkerReady/PrimaryComplete verwenden die Paare 1/2, 3/4, 5/6 und so weiter.
* Die CPU vermittelt die GPU-Abhängigkeit nicht; Worker- und Primary-Queue verwenden <code>Signal</code> und <code>Wait</code> direkt auf der GPU.
* Der separate Readback-Verifikationstest darf weiterhin blockieren. Der normale Runtime-Pfad wartet dagegen nicht auf GPU-Leerlauf.

=== Texturtransport ===

Direkte Cross-Adapter-Texturen sind auf dem Testsystem nicht beidseitig verfügbar: Die Intel UHD meldet Unterstützung für Row-Major Cross-Adapter Textures, die RTX 5060 Laptop GPU nicht. Deshalb verwendet das Projekt einen allgemeineren Buffer-Fallback.

<pre>
Intel MainTextureCS
-> persistente Worker-Textur
-> CopyTextureRegion
-> persistenter Shared Cross-Adapter Buffer
-> Worker signalisiert WorkerReady (1, 3, 5, ...)
-> UE-Primary-Queue wartet auf WorkerReady
-> direkte Kopie in persistente UE-eigene FTextureRHIRef
-> Primary signalisiert PrimaryComplete (2, 4, 6, ...)
</pre>

Der robuste Normal-Pfad kopiert die Worker-Textur über den Shared Buffer direkt in eine von Unreal erzeugte <code>FTextureRHIRef</code>. Breite, Höhe und Row Pitch werden dynamisch aus Worker-Ressource und Transport-Metadaten übernommen. Der erfolgreiche 128×96-RGBA8-Test verwendet 512 Byte Row Pitch und 49.152 Byte Transfergröße. Die Output Registry trennt Persistent-, Pending- und Ready-Zustände sowie Inhaltsgeneration und Texturidentität. Dadurch kann eine verspätete Completion keinen neueren Output zurückrollen.

=== Non-blocking Runtime-Pfad ===

Die produktive Testlogik ist aus dem Konsolenkommando in eine gekapselte NormalPath-API verschoben. <code>SubmitWorkerTextureComputeJob()</code> reicht den Worker-Dispatch ohne CPU-Wait ein. <code>QueueNormalTextureTransfer()</code> reiht Wait, Kopie und Completion-Signal in Unreals D3D12-Kontext ein. Der normale MainTextureCS-Pfad enthält weder CPU-Fence-Waits noch Readback, <code>Map</code> oder Pixelvergleich. <code>TickNormalTextureTransfers()</code> prüft die Primary-Completion non-blocking über einen Runtime-Pump; <code>RHIEndFrame()</code> bleibt als Fallback erhalten.

Eine passende Primary-<code>FTextureRHIRef</code> wird pro Worker und Konfiguration persistent gehalten. Nach PrimaryComplete kann der nächste Job dieselbe Resource erneut verwenden; dabei führt Unreal die Übergänge <code>SRVMask -> CopyDest -> SRVMask</code> aus. Eine backend-neutrale RHI-Provider-API reicht die Ready-Textur an die Engine weiter. <code>UExperimentalMultiGPUTexture</code> hält eine stabile <code>UTexture</code> samt TextureReference und bindet die persistente <code>FTextureRHIRef</code> ohne zusätzlichen Pixel-Copy. Eine native D3D12-Resource wird weiterhin nicht blind als UE-Textur gewrappt, weil Unreals Resource-State-Buchhaltung den tatsächlichen nativen Zustand sonst nicht sicher kennt.

=== Sichtbarer TPS-Consumer ===

<code>AExperimentalMultiGPUDisplayActor</code> zeigt die Worker-Ausgabe im Third-Person-Testlevel über den Materialparameter <code>MultiGPUTexture</code> an. Damit ist der Output nicht mehr nur über Logs oder Readback nachgewiesen: Die Intel UHD erzeugt fortlaufend die Texturinhalte, während die RTX die Spielwelt und das Material rendert. <code>TextureConsumerCS</code> kann Ready-Ausgaben auf der Primary zusätzlich als SRV lesen und fünf quantisierte Samples im Debugpfad prüfen.

=== Lebensdauer und automatisches Cleanup ===

Der Normal-Pfad verwendet pro Worker genau einen persistenten Runtime-Slot. Worker-Textur, Root Signature, PSO, Descriptor Heap, Command Allocator/List und Worker-Fence werden nach der ersten kompatiblen Initialisierung wiederverwendet. Dasselbe gilt für Shared Heap/Buffer/Fence und die Transport-Command-Objekte. Der In-Flight-Job trägt nur noch die nötigen Job-, Generation- und Fence-Metadaten.

<pre>
Runtime Request
-> Completion non-blocking prüfen
-> falls Slot frei: Worker Dispatch
-> WorkerReady-Fence signalisieren
-> Primary Wait, SafeCopy und PrimaryComplete-Signal
-> Output Pending
-> Runtime-Pump oder RHIEndFrame prüft GetCompletedValue()
-> Output Ready publizieren
-> Slot wiederverwendbar
</pre>

Backpressure erlaubt maximal einen echten In-Flight-Job pro Worker. Ein Busy-Request setzt keine GPU-Arbeit ab, setzt keine Ressourcen zurück und erhöht <code>PatternPhase</code> nicht. Worker-Fence-Werte steigen mit jedem akzeptierten Submit 1, 2, 3 und so weiter; der persistente Shared Fence verwendet fortlaufend die Paare 1/2, 3/4, 5/6. Fehler nach Übergabe von Ressourcen an die GPU führen zu sicherem Retire beziehungsweise Retention statt zu vorzeitigem Reuse.

=== Texture Stream und Benchmarking ===

Der projektseitige Texture Stream akzeptiert eine beliebige positive, endliche Zielrate. Punkt und Komma sind als Dezimaltrenner möglich. Optional lässt sich die Zahl erfolgreicher Submits begrenzen; Busy- oder Failed-Versuche verbrauchen dieses Limit nicht. Der Quiet-Modus unterdrückt per-Job-Ausgaben, behält aber Start, echte Fehler und die Abschlussstatistik bei.

<pre>
ExperimentalMultiGPU.StartTextureStream 37,5
ExperimentalMultiGPU.StartTextureStream 37,5 25
ExperimentalMultiGPU.StartTextureStream 1000 100 quiet
ExperimentalMultiGPU.StopTextureStream
</pre>

Die Statistik unterscheidet Timer-Ticks, angenommene Submits, Busy/Failed, Ready, In-Flight und die jeweiligen effektiven Raten. Diagnosezeitpunkte erfassen unter anderem RequestAccepted, RenderCommandExecution, WorkerSubmit, NormalTransferQueued und ReadyObserved.

{| class="wikitable"
! Test
! Ergebnis
! Aussage
|-
| 5 Hz, 20 Submits
| etwa 5 Ready/s, 20/20, kein Busy
| Entspannter Single-Slot-Betrieb
|-
| 1000 Hz, 100 Submits, quiet
| 100/100 Ready, 0 Fehler, etwa 58 Ready/s
| Backpressure begrenzt den Durchsatz sicher
|-
| 1000 Hz bei <code>t.MaxFPS 30</code>
| etwa 28–29 Ready/s trotz rund 982 Timer-Ticks/s
| Primary-/SafeCopy-/Ready-Kette ist effektiv framegekoppelt
|}

Ein zusätzlicher non-blocking Aufruf von <code>ImmediateFlush(DispatchToRHIThread)</code> erreicht hohe Render-Command-Raten, hebt die gemessene Frame-Kopplung aber nicht auf. Im 30-FPS-Test lag der RHIEndFrame-spezifische Completion-Takt praktisch exakt bei 30 Hz. Das aktuelle Problem ist damit eingegrenzt: Nicht der Stream-Timer, sondern die Primary-RHI-/D3D12-Submission der SafeCopy-Kette bestimmt die sichtbare Ready-Rate.

== Aktueller nächster Schritt ==

Der nächste Schritt ist, die '''Frame-Kopplung der Primary-/SafeCopy-/Ready-Kette''' weiter zu zerlegen, ohne einen blockierenden Flush einzuführen. Erst danach sollte erneut gemessen werden, welche reale Worker- und Transferlatenz der Single Slot erreicht. Ein zweiter Slot oder Ringbuffer ist nur sinnvoll, wenn diese Messung echten Pipeline-Bedarf zeigt und der Read-vs-Write-Hazard zwischen Render-Consumer und erneut beschriebener Primary-Textur sauber modelliert ist.

== Historische Vorläufer ==

Die Grundidee heterogener Multi-GPU-Nutzung ist nicht neu. Bereits mit der Einführung von Direct3D 12 entstanden mehrere Versuche, integrierte und dedizierte GPUs gemeinsam zu verwenden. Eine allgemein einsetzbare Lösung für moderne UE5-Spiele hat sich daraus jedoch nicht entwickelt.

=== Microsoft und Epic: UE4 Elemental Demo (2015) ===

Microsoft zeigte eine angepasste Unreal-Engine-4-Version der Elemental-Demo, bei der eine NVIDIA-GPU und eine Intel-iGPU gemeinsam arbeiteten. Das erklärte Ziel war, ansonsten ungenutzte Grafikleistung in Hybrid-Systemen zu verwenden. Dieser Versuch ist der Grundidee des Projekts besonders ähnlich, blieb aber eine technische Demonstration.

=== Intel: D3D12 Multi-Adapter Sample (2015) ===

Intels Beispiel kombinierte eine GeForce 840M mit Intel HD Graphics 5500. Beide GPUs berechneten getrennte Teile einer einfach parallelisierbaren Raytracing-Szene. Cross-Adapter-Ressourcen und Shared Fences führten die Ergebnisse anschließend zusammen. Intel berichtete in diesem Test von nahezu halbierter Framezeit, warnte jedoch ausdrücklich davor, das Ergebnis unmittelbar auf reale Spiele zu übertragen.

=== Ashes of the Singularity ===

Die Nitrous Engine von ''Ashes of the Singularity'' setzte Direct3D-12-Explicit-Multiadapter in einem veröffentlichten Spiel ein. Dabei konnten auch unterschiedliche GPU-Modelle und Hersteller zusammenarbeiten. Das war ein wichtiger Praxisnachweis, blieb in der Spielebranche aber eine seltene Ausnahme.

=== Weitere verwandte Ansätze ===

* ''Rise of the Tomb Raider'' erhielt explizite Direct3D-12-Multi-GPU-Unterstützung, vor allem für klassische Kombinationen ähnlicher GPUs.
* NVIDIA VR SLI wies bei Virtual Reality jeder GPU ein Auge zu. Das verteilt unabhängige Ansichten, bleibt jedoch NVIDIA-spezifisch.
* Unreal nDisplay kann Viewports oder Frustums auf weitere GPUs beziehungsweise Prozesse auslagern und das fertige Bild zur Ausgabe-GPU zurückführen. Der Einsatzbereich ist hauptsächlich Virtual Production.
* Forschung und High-Performance Computing verwenden seit Jahren Scheduler für heterogene GPUs, allerdings überwiegend für Compute- und Datenverarbeitungsaufgaben statt für einen allgemeinen UE5-Echtzeitrenderer.

=== Abgrenzung dieses Projekts ===

Das Projekt erfindet Direct3D-12-Explicit-Multiadapter nicht neu. Sein eigener Ansatz liegt in der Kombination aus tiefer UE5.8-RHI-Integration, UE-kompilierten Shadern auf unabhängigen Worker-Devices, frei wählbaren Spiel- und Compute-Workloads, Capability- und Performance-Scheduler, mehreren Fallback-Pfaden sowie dem langfristigen Ziel beliebiger Hersteller und mehrerer Worker.

== Vergleich mit anderen Multi-GPU-Verfahren ==

{| class="wikitable"
! Verfahren
! Arbeitsweise
! Verhältnis zu diesem Projekt
|-
| SLI / CrossFire
| Treiber- beziehungsweise Verbundlösung für meist ähnliche GPUs; häufig wird die Bildarbeit verteilt.
| Dieses Projekt benötigt keinen herstellerspezifischen GPU-Verbund und weist Aufgaben ausdrücklich selbst zu.
|-
| AFR (Alternate Frame Rendering)
| GPU 1 rendert einen Frame, GPU 2 den nächsten.
| Das Projekt verteilt unabhängige Aufgaben statt aufeinanderfolgender Frames. Dadurch werden Frame-Abhängigkeiten und typisches AFR-Pacing vermieden.
|-
| SFR (Split Frame Rendering)
| Mehrere GPUs bearbeiten Bereiche desselben Frames.
| Erfordert enge Lastverteilung und viel Datenaustausch. Das Projekt bevorzugt vollständig abgrenzbare Workloads und überträgt deren Ergebnis.
|-
| Direct3D 12 Linked Multiadapter
| Mehrere vom Treiber verbundene GPUs erscheinen als Knoten eines logischen Adapters.
| Eignet sich eher für eng kompatible GPUs. Das Projekt verwendet unabhängige Devices (Unlinked/Explicit Multiadapter) und unterstützt dadurch heterogene Herstellerkombinationen.
|-
| Direct3D 12 Unlinked / Explicit Multiadapter
| Die Anwendung verwaltet getrennte Adapter, Ressourcen und Synchronisation selbst.
| Das ist die technische Familie des Projekts. Hinzu kommen die eigene UE5-RHI-Integration, Workload-Ziele, Fallbacks und der geplante Scheduler.
|-
| UE nDisplay mGPU / Multi-Process
| Separate GPUs rendern bestimmte Viewports oder Frustums, vor allem für Virtual Production; Ergebnisse werden zur Ausgabe-GPU kopiert.
| Ähnliche Idee der aufgabenweisen Trennung, aber für einen anderen Einsatzbereich. Dieses Projekt zielt auf allgemeine Spiel- und Compute-Workloads innerhalb der Engine.
|-
| Vulkan Device Groups
| Ähnliche physische GPUs können ein gemeinsames logisches Device bilden.
| Für beliebige heterogene GPUs meist ungeeignet, da Geräte einer Gruppe nahezu gleiche Eigenschaften besitzen müssen. Eine spätere Vulkan-Portierung benötigt daher wahrscheinlich getrennte Devices und External Memory/Semaphores.
|}

SLI und CrossFire bezeichnen den Verbund; AFR und SFR beschreiben mögliche Verteilungsmethoden innerhalb solcher Systeme. Sie sind deshalb nicht vollständig getrennte Kategorien.

== Vorteile der geplanten Variante ==

* '''Herstellerunabhängig:''' NVIDIA, AMD und Intel können grundsätzlich kombiniert werden.
* '''Vorhandene Hardware nutzen:''' Auch eine sonst wenig genutzte integrierte GPU kann geeignete Nebenaufgaben übernehmen.
* '''Aufgaben statt Frames verteilen:''' Spiegel, Minimap oder Compute können mit eigener Auflösung und Aktualisierungsrate laufen.
* '''Keine identischen GPUs erforderlich:''' Unterschiedliche Fähigkeiten können gezielt genutzt werden.
* '''Kontrollierter Datenaustausch:''' Nur das benötigte Ergebnis muss zurück zur Primary-GPU.
* '''Robuste Fallback-Idee:''' Wenn direkte Texturen nicht gemeinsam nutzbar sind, bleibt der Shared-Buffer-Pfad.
* '''Erweiterbar:''' Scheduler, manuelles Mapping und mehrere Worker sind als spätere Stufen vorgesehen.

== Nachteile und technische Risiken ==

* '''Hoher Entwicklungsaufwand:''' Geräte, Ressourcen, Zustände, Fences, Fehlerfälle und UE-Lebenszyklen müssen selbst verwaltet werden.
* '''Transfer kann den Gewinn aufzehren:''' Cross-Adapter Heaps liegen laut D3D12 nicht automatisch im schnellen lokalen VRAM. Bandbreite und Latenz müssen für jeden Workload gemessen werden.
* '''VRAM wird nicht einfach addiert:''' Benötigte Ressourcen können auf mehreren GPUs vorliegen und zusätzlichen Speicher verbrauchen.
* '''Langsame Worker können bremsen:''' Eine Aufgabe lohnt sich nur, wenn Rechengewinn größer als Übergabe-, Warte- und Kopierkosten ist.
* '''Nicht jeder Workload ist unabhängig:''' Hauptansicht, Lumen, Nanite und stark gekoppelte Renderpässe besitzen viele Abhängigkeiten und sind schwieriger auszulagern.
* '''Hardwareunterschiede:''' Formate, Shader-Funktionen, Queue-Fähigkeiten und Cross-Adapter-Support müssen pro GPU geprüft werden.
* '''Wartungsrisiko:''' Eingriffe in private D3D12RHI-Dateien können bei Engine-Updates angepasst werden müssen.
* '''Produktionsreife fehlt noch:''' Ressourcenpools, Timeouts, Device-Lost-Wiederherstellung, Scheduler und echte Szenentests sind offen.

== Wann die Variante sinnvoll ist ==

Am aussichtsreichsten sind Aufgaben mit viel eigener Rechenarbeit, einem relativ kleinen Endergebnis und wenigen Abhängigkeiten zur Hauptszene. Gute frühe Kandidaten sind unabhängige Compute-Aufgaben sowie Scene Captures, die nicht in jedem Frame aktualisiert werden müssen. Weniger geeignet sind winzige Aufgaben mit großem Transfer oder Renderpässe, die ständig auf Ressourcen der Primary-GPU zugreifen.

Die entscheidende Regel für den späteren Scheduler lautet daher:

<pre>
Worker-Gewinn > Vorbereitung + Datentransfer + Synchronisation + Rückintegration
</pre>

== Bekannte Grenzen des Proof of Concepts ==

* Der asynchrone 128×96-End-to-End-Pfad ist über Dimensionen, Dispatch, Transfer, Fences, Pending/Ready und Reuse verifiziert; ein eigener 128×96-Pixel-Readback fehlt noch. Der synchrone 64×64-Debugtest prüft weiterhin alle 4096 Pixel.
* Der Normal-Transport unterstützt derzeit <code>DXGI_FORMAT_R8G8B8A8_UNORM</code> mit Sample Count 1; weitere Formate, Mips, Arrays, Slices und MSAA sind offen.
* Pro Worker existiert absichtlich nur ein persistenter Runtime-Slot. Mehrere parallele In-Flight-Jobs sowie Double-, Triple- oder Ring-Buffering fehlen noch.
* Die Primary-/SafeCopy-/Ready-Kette bleibt trotz zusätzlichem non-blocking <code>DispatchToRHIThread</code> effektiv an den Frame-/Submission-Zyklus gekoppelt.
* Raw-D3D12-Shared-Ressourcen sind noch nicht vollständig in Unreals Residency-Management eingebunden.
* Praktisch getestet ist Primary plus ein Worker. Die Architektur ist auf mehrere Worker ausgelegt, N-GPU ist aber noch nicht praktisch validiert.
* Der sichtbare TPS-Nachweis zeigt eine Worker-Compute-Textur, noch keine auf dem Worker gerenderte 3D-Szene. Echte UE-Szenen-Workloads, Benchmark-Wizard und Scheduler fehlen weiterhin.
* Die projektseitigen UpscalerTest-Dateien mit DisplayActor und Texture Stream liegen außerhalb des Engine-Git-Repositories und sind nicht Bestandteil von Commit <code>cbf56c2</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.

== Roadmap ==

# Primary-RHI-/D3D12-Submission untersuchen und die Frame-Kopplung ohne blockierende Flushes auflösen.
# Danach Quiet-Benchmarks wiederholen und die reale Single-Slot-Latenz bestimmen.
# Nur bei nachgewiesenem Bedarf einen zweiten Slot oder Ringbuffer mit Generation-, Fence-, Reuse- und Consumer-Hazard-Modell ergänzen.
# Ersten echten UE-Offload wie SceneCapture2D, CCTV, Spiegel, Minimap, Niagara oder unabhängigen Compute integrieren.
# Formate, Mips, Arrays/Slices und gegebenenfalls MSAA capability-basiert erweitern.
# Capability-Matrix, Benchmark-Wizard, Scheduler und manuelle Overrides entwickeln.
# Mehrere Worker-GPUs unterstützen.
# Fallback-Matrix aus Normal Shared Buffer, System-RAM/Staging und einem späteren Experimental Fast Path ergänzen.
# Linux/Vulkan mit getrennten Devices, External Memory und externer Synchronisation untersuchen.

== Quellen ==

* Interner Entwicklungsstand und verifizierte Testprotokolle vom 6. September 2026, Commit <code>cbf56c2</code>
* [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/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://www.intel.com/content/dam/develop/external/us/en/documents/multi-adapter-support-in-directx-12-594015.pdf Intel: Multi-Adapter Support in DirectX 12]
* [https://devblogs.microsoft.com/directx/ashes-of-the-singularity-makes-gaming-history-with-directx-12/ Microsoft: Ashes of the Singularity und heterogene Adapter]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/nvidia-sli-alternative-frame-rendering-in-unreal-engine Epic: NVIDIA SLI Alternate Frame Rendering]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/multi-process-rendering-with-unreal-engine Epic: Multi-Process Rendering]
* [https://registry.khronos.org/vulkan/specs/latest/pdf/vkspec.pdf Khronos: Vulkan Specification – Device Groups]

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Multi-GPU]]
[[Kategorie:Direct3D 12]]
[[Kategorie:Experimentell]]

Render Hardware Interface (RHI) in Unreal Engine 5

2026-09-06T09:37:54Z

Elaina: Elaina verschob die Seite Render Hardware Interface (RHI) in Unreal Engine 5 nach Render Hardware Interface (RHI): Redundanten Titelzusatz entfernt

#WEITERLEITUNG [[Render Hardware Interface (RHI)]]

Render Hardware Interface (RHI)

2026-09-06T09:37:54Z

Elaina: Elaina verschob die Seite Render Hardware Interface (RHI) in Unreal Engine 5 nach Render Hardware Interface (RHI): Redundanten Titelzusatz entfernt

{{Hinweis|Stand: Unreal Engine 5.8. Dieser Artikel fasst die aktuelle offizielle Epic-Dokumentation zusammen.}}

Das '''Render Hardware Interface (RHI)''' ist die hardwarenahe Abstraktionsschicht des Unreal-Renderers. Rendering-Code arbeitet über ein gemeinsames Unreal-Interface, während das jeweils aktive Backend die Befehle auf eine konkrete Grafik-API wie Direct3D 12, Vulkan oder Metal abbildet.

{| class="wikitable"
|+ Artikelstatus
|-
! Bezugsstand
| Unreal Engine 5.8
|-
! Letzte Aktualisierung
| 2. September 2026
|-
! Modul
| <code>RHI</code>
|-
! Zentrale Header
| <code>DynamicRHI.h</code>, <code>RHICommandList.h</code>, <code>RHIResources.h</code>
|}

== Aufgabe des RHI ==

Das RHI bildet eine gemeinsame Schnittstelle zwischen Unreals Renderer und den plattformspezifischen Grafik-APIs. Es abstrahiert unter anderem:

* Grafik- und Compute-Pipelines
* Buffer und Texturen
* Shader und Shader-Parameter
* Render Passes
* Command Lists und Command Contexts
* Ressourcenübergänge und Synchronisation
* Queries, Fences und Readbacks
* Raytracing-Ressourcen und -Pipelines

Die Abstraktion ist bewusst hardwarenah. Sie soll plattformunabhängigen Rendering-Code ermöglichen, ohne die Eigenschaften moderner Low-Level-APIs vollständig zu verbergen.

== Grobe Einordnung im Renderer ==

<pre>
Spiel- und Engine-Systeme
|
Renderer / Render Dependency Graph
|
RHI-Befehle und RHI-Ressourcen
|
plattformabhängiges RHI-Backend
|
Direct3D 12 / Vulkan / Metal
|
GPU und Treiber
</pre>

High-Level-Rendering-Code wird in modernen UE-Versionen häufig über den [[Render Dependency Graph]] beschrieben. Bei der Ausführung werden daraus RHI-Befehle, die das aktive Backend anschließend in native API-Kommandos übersetzt.

== Dynamisches RHI und Backends ==

<code>FDynamicRHI</code> ist die zentrale Schnittstelle des zur Laufzeit gebundenen RHI-Backends. Konkrete Implementierungen stellen die Verbindung zur jeweiligen Grafik-API her. Dazu gehören beispielsweise Schnittstellen für Direct3D 12 und Vulkan.

Das ausgewählte Backend wird während des Engine-Starts initialisiert. Welches RHI verwendet wird, hängt von Plattform, Projektkonfiguration und Startparametern ab. Das aktive Backend stellt die tatsächlichen Ressourcen, Command Contexts und Submit-Pfade bereit.

Wichtig: RHI-Objekte sind Unreal-Abstraktionen. Ein <code>FRHIBuffer</code> ist nicht selbst ein <code>ID3D12Resource</code>; das D3D12-Backend verwaltet darunter das native Objekt.

== RHI-Ressourcen ==

Viele GPU-Objekte werden als von <code>FRHIResource</code> abgeleitete Typen dargestellt.

{| class="wikitable"
! RHI-Typ
! Aufgabe
|-
| <code>FRHIBuffer</code>
| Allgemeiner GPU-Buffer mit Größe, Stride und Nutzungsflags
|-
| <code>FRHITexture</code>
| Texturressource einschließlich Format, Ausdehnung und Mip-Struktur
|-
| <code>FRHIShaderResourceView</code> (SRV)
| Lesende Sicht auf eine Ressource für Shader
|-
| <code>FRHIUnorderedAccessView</code> (UAV)
| Schreibende beziehungsweise ungeordnet lesend-schreibende Sicht
|-
| <code>FRHIUniformBuffer</code>
| Gebündelte konstante Shader-Parameter
|-
| <code>FRHIGPUFence</code>
| GPU-seitiger Synchronisationspunkt
|-
| <code>FRHIGPUBufferReadback</code>
| Hilfsobjekt für asynchrones Zurücklesen eines Buffers
|}

Ressourcen besitzen Beschreibungen und Nutzungsflags. Diese Informationen sind wichtig, weil moderne APIs Speicher, Bindung und erlaubte Zugriffe explizit behandeln.

== Command Lists ==

Rendering- und Compute-Arbeit wird über RHI Command Lists aufgezeichnet. Sie enthalten keine beliebige Spiellogik, sondern eine geordnete Folge grafischer Befehle.

=== Wichtige Typen ===

* <code>FRHIComputeCommandList</code> stellt die gemeinsame Compute-Schnittstelle bereit.
* <code>FRHICommandList</code> erweitert diese um Grafikbefehle, beispielsweise Render Passes und Draw-Aufrufe.
* <code>FRHICommandListImmediate</code> ist die unmittelbare Haupt-Command-List. Sie sollte nicht ohne Not verwendet werden, wenn parallele Ausführung erhalten bleiben soll.
* <code>FRHICommandListExecutor</code> koordiniert Übersetzung und Übermittlung aufgezeichneter Command Lists.

Typische Befehle umfassen:

* Render Pass beginnen und beenden
* Grafik- oder Compute-PSO setzen
* Shader-Parameter binden
* Vertex- und Index-Buffer setzen
* Draw oder Dispatch auslösen
* Ressourcen kopieren
* Ressourcenübergänge einleiten
* GPU-Fences schreiben

== Threads und Befehlsfluss ==

Unreals Rendering arbeitet über mehrere Ebenen. Vereinfacht gilt:

# Der '''Game Thread''' aktualisiert die Spielwelt und stößt Rendering-Arbeit an.
# Der '''Render Thread''' verarbeitet die Render-Szene und zeichnet plattformunabhängige RHI-Befehle auf.
# Der '''RHI Thread''' kann diese Befehle für das aktive Backend übersetzen und an die Grafik-API weitergeben.
# Das Backend übermittelt native Command Lists an die GPU-Queues.

Diese Trennung erlaubt Parallelisierung. Renderer-Code sollte deshalb nicht unnötig blockieren oder voraussetzen, dass ein aufgezeichneter Befehl sofort auf der GPU ausgeführt wurde.

== Pipeline State Objects ==

Moderne Grafik-APIs bündeln viele Zustände in '''Pipeline State Objects''' (PSOs). Unreal unterscheidet unter anderem:

* <code>FRHIGraphicsPipelineState</code> für Grafik-Pipelines
* <code>FRHIComputePipelineState</code> für Compute-Pipelines
* <code>FRHIRayTracingPipelineState</code> für Raytracing

Ein Grafik-PSO beschreibt beispielsweise Shader-Stufen, Blend-, Rasterizer- und Depth-Stencil-Zustand sowie Render-Target-Formate. Ein Compute-PSO benötigt vor allem den Compute Shader und die zum Backend gehörende Bindungsstruktur.

Häufig wechselnde oder erst während des Spiels kompilierte PSOs können Ruckler verursachen. Deshalb sind PSO-Caching und eine frühzeitige Vorbereitung wichtiger Zustände für reale Projekte relevant.

== Ressourcenstatus und Barriers ==

In Direct3D 12 und Vulkan müssen Ressourcenzugriffe explizit synchronisiert werden. Eine Ressource kann beispielsweise als Kopierziel, Shader-Eingabe oder UAV-Ausgabe verwendet werden. Der Status muss vor der jeweiligen Nutzung passen.

Das RHI beschreibt Zugriffe unter anderem über RHI-Zustände und Übergänge. Bei RDG-Ressourcen übernimmt der Render Dependency Graph einen großen Teil der Planung, sofern alle Ressourcen korrekt als Pass-Parameter angegeben wurden.

Fehlerhafte Übergänge können zu Validierungsfehlern, beschädigten Ergebnissen oder GPU-Hängern führen. Besondere Vorsicht ist nötig, wenn Ressourcen außerhalb von RDG manuell verwaltet oder zwischen unabhängigen Queues ausgetauscht werden.

== Synchronisation und Readback ==

CPU und GPU arbeiten asynchron. Ein Submit bedeutet deshalb nicht, dass die GPU-Arbeit bereits beendet ist.

Typische Werkzeuge sind:

* '''GPU-Fence:''' signalisiert das Erreichen eines Punkts in einer GPU-Queue
* '''Queue- beziehungsweise Pipeline-Übergänge:''' koordinieren Graphics- und Async-Compute-Arbeit
* '''Readback-Ressourcen:''' übertragen Ergebnisse in CPU-lesbaren Speicher
* '''Staging-Buffer:''' dienen als Zwischenspeicher für Upload oder Readback

Die CPU sollte nur dann auf Readback-Daten zugreifen, wenn der zugehörige Fence abgeschlossen ist. Häufige synchrone Wartezeiten zerstören die Parallelität und sollten im normalen Frame-Pfad vermieden werden.

== RHI und Render Dependency Graph ==

RHI und RDG erfüllen unterschiedliche Aufgaben:

{| class="wikitable"
! Ebene
! Verantwortung
|-
| RDG
| Beschreibung von Passes und Abhängigkeiten, Ressourcenlebenszeiten, Culling, Planung und Parallelisierung
|-
| RHI
| Hardwarenahe Befehle, Ressourcen und Pipeline-Zustände für das aktive Grafik-Backend
|-
| Plattform-RHI
| Übersetzung in native Direct3D-12-, Vulkan- oder Metal-Objekte und -Kommandos
|}

Für neuen High-Level-Rendering-Code ist RDG meist der bevorzugte Einstieg. Direkter RHI-Code bleibt wichtig, wenn hardwarenahe Kontrolle nötig ist oder ein System unterhalb beziehungsweise außerhalb des normalen Render Graphs arbeitet.

== Debugging und Diagnose ==

Bei RHI-Problemen helfen unter anderem:

* aussagekräftige Namen für Ressourcen und Render-Passes
* Grafik-API-Debug-Layer und GPU-basierte Validierung in Entwicklungsumgebungen
* RHI- und RDG-Validierung
* Unreal Insights sowie RDG Insights
* GPU-Captures mit Werkzeugen wie RenderDoc oder PIX, sofern die Konfiguration dies unterstützt
* Prüfung von Nutzungsflags, Ressourcenstatus und Queue-Zugehörigkeit
* Kontrolle der Lebensdauer nativer und abstrahierter Ressourcen
* Fences und Readback-Zeitpunkte protokollieren

== Bezug zum Heterogeneous-Multi-GPU-Projekt ==

Das Projekt [[UE5 Heterogeneous Multi-GPU]] verwendet für die Primary GPU weiterhin Unreals regulären D3D12-RHI-Pfad. Die Intel-Worker-GPU wird dagegen aktuell über ein separat erzeugtes <code>ID3D12Device</code> mit eigener Direct Command Queue, eigenen Command Lists und eigener Fence-Synchronisation angesprochen.

<pre>
UE-Renderer
|
+-- reguläres D3D12-RHI --> RTX 5060 (Primary)
|
+-- ExperimentalMultiGPU --> separates ID3D12Device
--> Intel UHD (Worker)
</pre>

Dieser Worker-Pfad ist nicht automatisch Bestandteil von <code>GDynamicRHI</code>. Dadurch ergeben sich besondere Aufgaben:

* native Ressourcen des Worker-Devices dürfen nicht wie normale RHI-Ressourcen der Primary GPU behandelt werden
* Shader-Bytecode muss mit dem Zielgerät und dessen Fähigkeiten kompatibel sein
* Root Signature und PSO müssen für das Worker-Device erzeugt werden
* Command Allocator, Command List, Queue und Fence benötigen eine eigene Lebensdauerverwaltung
* Datenübertragung zwischen Primary und Worker muss ausdrücklich geplant werden
* Cross-Adapter-Ressourcen benötigen passende Heap- und Ressourcenflags; andernfalls ist ein Transfer über System-RAM erforderlich
* Fehler- und Device-Removal-Behandlung muss pro Device erfolgen

Langfristig kann geprüft werden, welche Teile sinnvoll als eigene Unreal-Abstraktion oberhalb der nativen Devices modelliert werden. Eine direkte Erweiterung des regulären RHI um heterogene unabhängige Devices wäre dagegen ein erheblich größerer Eingriff in Engine-Annahmen, Ressourcenverwaltung und Scheduling.

== Praktische Merksätze ==

* RHI abstrahiert die Grafik-API, aber nicht die grundlegenden Regeln moderner GPUs.
* Command-Aufzeichnung und GPU-Ausführung finden zeitlich getrennt statt.
* Ressourcenstatus, Queue-Zugehörigkeit und Lebensdauer müssen immer eindeutig sein.
* RDG ist für neuen High-Level-Code meist geeigneter als manuelle Immediate-RHI-Befehle.
* Native Objekte verschiedener D3D12-Devices sind nicht beliebig austauschbar.
* Für einen unabhängigen Worker-Pfad müssen Synchronisation und Transfers ausdrücklich entworfen werden.

== Quellen und weiterführende Dokumentation ==

* [https://dev.epicgames.com/documentation/unreal-engine/graphics-programming-overview-for-unreal-engine Graphics Programming Overview] – Epic Games, UE 5.8
* [https://dev.epicgames.com/documentation/unreal-engine/API/Runtime/RHI RHI API Reference] – Epic Games, UE 5.8
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/API/Runtime/RHI/FDynamicRHI FDynamicRHI] – API-Referenz, Epic Games, UE 5.8
* [https://dev.epicgames.com/documentation/unreal-engine/API/Runtime/RHI/FRHICommandList FRHICommandList] – API-Referenz, Epic Games, UE 5.8
* [https://dev.epicgames.com/documentation/unreal-engine/API/Runtime/RHI/FRHIBuffer FRHIBuffer] – API-Referenz, Epic Games, UE 5.8
* [https://dev.epicgames.com/documentation/unreal-engine/API/Runtime/RHI/FRHITexture FRHITexture] – API-Referenz, Epic Games, UE 5.8
* [https://dev.epicgames.com/documentation/unreal-engine/parallel-rendering-overview-for-unreal-engine Parallel Rendering Overview] – Epic Games, UE 5.8

''Dieser Artikel ist eine eigenständige deutschsprachige Zusammenfassung mit Projektbezug und keine vollständige Übersetzung der Epic-Dokumentation.''

[[Kategorie:Unreal Engine 5]]
[[Kategorie:RHI]]
[[Kategorie:Rendering]]
[[Kategorie:Direct3D 12]]
[[Kategorie:Grafikprogrammierung]]

Render Dependency Graph (RDG) in Unreal Engine 5

2026-09-06T09:37:44Z

Elaina: Elaina verschob die Seite Render Dependency Graph (RDG) in Unreal Engine 5 nach Render Dependency Graph (RDG): Redundanten Titelzusatz entfernt

#WEITERLEITUNG [[Render Dependency Graph (RDG)]]

Render Dependency Graph (RDG)

2026-09-06T09:37:43Z

Elaina: Elaina verschob die Seite Render Dependency Graph (RDG) in Unreal Engine 5 nach Render Dependency Graph (RDG): Redundanten Titelzusatz entfernt

{{Hinweis|Stand: Unreal Engine 5.8. Dieser Artikel fasst die aktuelle offizielle Epic-Dokumentation zusammen.}}

Der '''Render Dependency Graph''' ('''RDG''', auch Render Graph) organisiert Renderarbeit als Graph aus ''Passes'' und Ressourcen. Ein Pass ist ein Arbeitsschritt auf CPU/GPU; Ressourcen sind vor allem Texturen und Buffer. Statt Übergänge, Lebensdauer und Synchronisation überall von Hand zu steuern, beschreibt der Code, welche Ressourcen ein Pass liest oder schreibt. RDG leitet daraus die Reihenfolge ab.

== Warum RDG? ==

RDG kann unbenutzte Passes entfernen, temporäre Ressourcen nur so lange wie nötig halten, Speicher zwischen nicht gleichzeitig lebenden Ressourcen wiederverwenden und Barrieren automatisch setzen. Es unterstützt außerdem Async Compute und paralleles Aufzeichnen von Command Lists. Das senkt Fehlergefahr und kann CPU-, GPU- und Speicherarbeit besser überlappen.

== Das Grundmodell ==

# Ein <code>FRDGBuilder</code> sammelt Passes und Ressourcen für den Graphen.
# Texturen oder Buffer werden im Graphen erzeugt oder als externe Ressourcen registriert.
# Parameterstrukturen nennen die Eingaben und Ausgaben eines Passes. Daraus erkennt RDG echte Abhängigkeiten.
# <code>AddPass</code> fügt die auszuführende Arbeit hinzu.
# <code>Execute()</code> kompiliert den Graphen, entfernt tote Arbeit und führt die verbleibenden Passes aus.

Ein RDG-Handle wie <code>FRDGTextureRef</code> ist kein dauerhaft frei nutzbares RHI-Objekt. Seine Gültigkeit richtet sich nach dem Graphen. Soll ein Ergebnis außerhalb weiterleben, muss es über die dafür vorgesehenen Extract-/External-Mechanismen übergeben werden.

== Kleines C++-Muster ==

<syntaxhighlight lang="cpp">
FRDGTextureDesc Desc = FRDGTextureDesc::Create2D(
Extent, PF_FloatRGBA, FClearValueBinding::Black,
TexCreate_ShaderResource | TexCreate_UAV);

FRDGTextureRef Output = GraphBuilder.CreateTexture(Desc, TEXT("MyOutput"));

FMyShader::FParameters* Parameters =
GraphBuilder.AllocParameters<FMyShader::FParameters>();
Parameters->Output = GraphBuilder.CreateUAV(Output);

FComputeShaderUtils::AddPass(
GraphBuilder,
RDG_EVENT_NAME("MyComputePass"),
ComputeShader,
Parameters,
GroupCount);
</syntaxhighlight>

Entscheidend ist nicht die genaue Shaderlogik, sondern dass <code>Parameters</code> den Schreibzugriff auf <code>Output</code> sichtbar macht. Versteckte Ressourcen-Zugriffe außerhalb der Parameterstruktur verhindern korrekte Planung und Validierung.

== Praxisregeln ==

* Ressourcen-Zugriffe vollständig in den Passparametern deklarieren.
* RDG-Ressourcen nicht über ihre vorgesehene Lebensdauer hinaus speichern.
* Pass-Lambdas nur mit Daten füttern, die bei ihrer späteren Ausführung noch gültig sind.
* Seiteneffekte vermeiden: Ein Pass ohne sichtbaren Beitrag kann entfernt werden. Notwendige Sonderfälle müssen bewusst mit passenden Pass-Flags modelliert werden.
* Ereignisnamen mit <code>RDG_EVENT_NAME</code> vergeben; das macht Captures und RDG Insights lesbar.
* Erst messen, dann optimieren. RDG Insights visualisiert Graph, Abhängigkeiten und Ressourcenlebensdauer.

== Bezug: UE5 Heterogeneous Multi-GPU ==

Für Jans Projekt ist RDG die passende Ebene, um Abhängigkeiten zwischen GPU-Arbeit explizit zu machen. Das ist eine Voraussetzung für kontrollierte Überlappung und Synchronisation. RDG verteilt einen Pass jedoch '''nicht automatisch''' auf unterschiedliche oder heterogene GPUs.

Die GPU-Auswahl liegt tiefer in RHI und Multi-GPU-Code, unter anderem über <code>FRHIGPUMask</code>. Für einen Prototyp sollten deshalb drei Fragen getrennt geprüft werden:

* Ist der RDG-Graph fachlich korrekt und frei von versteckten Abhängigkeiten?
* Welche Passes und Ressourcen dürfen auf welcher GPU liegen?
* Wo entstehen explizite Cross-GPU-Kopien und Synchronisationskosten?

RDG Insights hilft bei der ersten Frage. Für GPU-Zuordnung, Transfers und Adapter-Fähigkeiten sind zusätzlich RHI-Quellcode, Plattform-RHI und GPU-Captures nötig.

== Quellen ==

* [https://dev.epicgames.com/documentation/en-us/unreal-engine/render-dependency-graph-in-unreal-engine?application_version=5.8 Epic: Render Dependency Graph (UE 5.8)]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/API/Runtime/RenderCore/FRDGBuilder?application_version=5.8 Epic API: FRDGBuilder (UE 5.8)]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/API/Runtime/RenderCore/FComputeShaderUtils__AddPass?application_version=5.8 Epic API: FComputeShaderUtils::AddPass (UE 5.8)]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/API/Runtime/RHI/FRHIGPUMask?application_version=5.8 Epic API: FRHIGPUMask (UE 5.8)]

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Rendering]]
[[Kategorie:Multi-GPU]]

Paralleles Rendering und RHI-Thread in Unreal Engine 5

2026-09-06T09:37:33Z

Elaina: Elaina verschob die Seite Paralleles Rendering und RHI-Thread in Unreal Engine 5 nach Paralleles Rendering und RHI-Thread: Redundanten Titelzusatz entfernt

#WEITERLEITUNG [[Paralleles Rendering und RHI-Thread]]

Paralleles Rendering und RHI-Thread

2026-09-06T09:37:33Z

Elaina: Elaina verschob die Seite Paralleles Rendering und RHI-Thread in Unreal Engine 5 nach Paralleles Rendering und RHI-Thread: Redundanten Titelzusatz entfernt

{{Hinweis|Stand: Unreal Engine 5.8. Dieser Artikel fasst die aktuelle offizielle Epic-Dokumentation zusammen.}}

'''Paralleles Rendering''' verteilt die CPU-Arbeit des Renderers auf mehrere Threads. Der '''RHI Thread''' ist dabei der Thread, der Unreal-Befehle über das ''Render Hardware Interface'' (RHI) in Aufrufe der jeweiligen Grafik-API wie DirectX 12 oder Vulkan übersetzt. Das ist CPU-Parallelität und nicht automatisch Multi-GPU-Rendering.

== Die beteiligten Stufen ==

; Game Thread
: Aktualisiert Spielwelt, Actors und UObjects und übergibt Renderzustand asynchron an den Renderer.
; Render Thread
: Baut aus der Szene plattformunabhängige Renderbefehle und Command Lists auf. Eine Command List ist eine geordnete Liste von Grafikbefehlen.
; RHI Thread
: Übersetzt bzw. führt diese Listen im Backend für die konkrete Grafik-API aus.
; GPU
: Arbeitet die eingereichten Grafik- und Compute-Kommandos ab.

Diese Stufen können an verschiedenen Frames arbeiten. Unreal bewahrt dabei die Einreichungsreihenfolge, die auch ein serieller Renderer hätte. Synchronisationspunkte und Fences sorgen dafür, dass ein Verbraucher nicht vor seinem Produzenten läuft.

== Wo die Parallelität entsteht ==

Der Render Thread kann Command Lists in parallelen Aufgaben vorbereiten. Auf geeigneten Plattformen kann auch das RHI-Backend mehrere Listen parallel übersetzen. Der getrennte RHI Thread verhindert, dass die Übersetzung aller API-Aufrufe den Render Thread direkt blockiert.

Nicht jeder Vorgang passt in dieses Modell. Bestimmte Lock-/Unlock- oder Ressourcenoperationen können einen Flush erzwingen oder Daten kopieren und später einreihen. Häufige erzwungene Synchronisation nimmt den Threads den möglichen Zeitgewinn.

== Thread-Sicherheit in eigenem Code ==

Rendercode darf nicht einfach auf veränderliche <code>UObject</code>- oder Actor-Daten des Game Threads zugreifen. Sonst entsteht eine ''Race Condition'': Das Ergebnis hängt vom zufälligen zeitlichen Ablauf der Threads ab.

Das übliche Muster ist:

# Der Game Thread besitzt Gameplay-Daten.
# Benötigte Werte werden in eine renderseitige Struktur oder einen Scene Proxy kopiert.
# Ein Render Command übergibt diese Kopie an den Render Thread.
# Ressourcen werden erst freigegeben, wenn Fence oder vorgesehener Cleanup-Mechanismus ihre Nutzung abgeschlossen meldet.

<code>FlushRenderingCommands</code> blockiert den Game Thread bis der Renderer aufgeholt hat. Das kann für seltene Editor-/Offline-Operationen sinnvoll sein, sollte aber nicht zum normalen Gameplay-Pfad werden.

== Prüfen und eingrenzen ==

Unreal Insights zeigt Game-, Render- und RHI-Thread getrennt in Timing Insights. Verglichen werden sollten identische, reproduzierbare Szenen und mehrere Frames.

Nützliche Diagnosevariablen aus der Epic-Dokumentation:

* <code>r.RHIThread.Enable 0</code> deaktiviert den separaten RHI Thread.
* <code>r.RHICmdUseDeferredContexts 0</code> deaktiviert die Backend-Parallelisierung.
* <code>r.RHICmdUseParallelAlgorithms 0</code> deaktiviert die Frontend-Parallelisierung.
* <code>r.RHICmdBypass 1</code> umgeht Command Lists; dies wird nur berücksichtigt, wenn der RHI Thread deaktiviert ist.

Diese Schalter sind Diagnosewerkzeuge, keine pauschalen Performance-Tipps. Wirkung und Standard können von Plattform und RHI abhängen. Für belastbare Aussagen immer in der Zielkonfiguration messen.

== Typische Befunde ==

* '''Render Thread voll ausgelastet, RHI Thread wartet:''' Engpass eher beim Aufbau der Renderarbeit.
* '''RHI Thread voll ausgelastet:''' Übersetzung oder Treiberarbeit begrenzt die CPU-Seite.
* '''Viele Flushes/Fences:''' Zu enge Synchronisation oder ungeeignete Ressourcenpfade untersuchen.
* '''GPU voll ausgelastet, CPU-Threads mit Luft:''' Parallelisierung der CPU behebt den eigentlichen GPU-Engpass nicht.

== Bezug: UE5 Heterogeneous Multi-GPU ==

Für Jans Projekt müssen zwei Achsen getrennt betrachtet werden:

* Parallel Rendering und RHI Thread verteilen hauptsächlich '''CPU-Arbeit'''.
* Heterogeneous Multi-GPU verteilt '''GPU-Arbeit und Ressourcen''' auf mehrere Adapter.

Eine zweite GPU hilft daher nicht automatisch bei einem RHI-Thread-Limit. Umgekehrt kann ein langsamer serieller CPU-Pfad mehrere GPUs unterfüttern. Die offizielle RHI-API beschreibt Fähigkeiten wie Multithreading und parallele RHI-Ausführung; <code>FRHIGPUMask</code> repräsentiert aktive GPU-Indizes. Ob heterogene Adapter einen konkreten Pfad unterstützen, muss jedoch für D3D12/Vulkan, Treiber, Speicherfreigabe und Kopierpfad separat validiert werden.

Praktischer Messplan: zuerst Single-GPU-Baseline in Unreal Insights, dann RHI Thread und Parallelalgorithmen einzeln vergleichen, anschließend erst Multi-GPU aktivieren und CPU-Zeiten, GPU-Zeiten sowie Transferkosten getrennt erfassen.

== Quellen ==

* [https://dev.epicgames.com/documentation/en-us/unreal-engine/parallel-rendering-overview-for-unreal-engine?application_version=5.8 Epic: Parallel Rendering Overview (UE 5.8)]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/threaded-rendering-in-unreal-engine?application_version=5.8 Epic: Threaded Rendering (UE 5.8)]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/unreal-insights-in-unreal-engine?application_version=5.8 Epic: Unreal Insights (UE 5.8)]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/API/Runtime/RHI/FRHIGlobals?application_version=5.8 Epic API: FRHIGlobals (UE 5.8)]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/API/Runtime/RHI/FRHIGPUMask?application_version=5.8 Epic API: FRHIGPUMask (UE 5.8)]

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Rendering]]
[[Kategorie:Multi-GPU]]

Multi-Process Rendering und Multi-GPU in Unreal Engine 5

2026-09-06T09:37:23Z

Elaina: Elaina verschob die Seite Multi-Process Rendering und Multi-GPU in Unreal Engine 5 nach Multi-Process Rendering und Multi-GPU: Redundanten Titelzusatz entfernt

#WEITERLEITUNG [[Multi-Process Rendering und Multi-GPU]]

Multi-Process Rendering und Multi-GPU

2026-09-06T09:37:23Z

Elaina: Elaina verschob die Seite Multi-Process Rendering und Multi-GPU in Unreal Engine 5 nach Multi-Process Rendering und Multi-GPU: Redundanten Titelzusatz entfernt

{{Hinweis|Stand: Unreal Engine 5.8. Dieser Artikel beschreibt Epics offiziell dokumentierte nDisplay-Verfahren.}}

'''Multi-Process Rendering''' und '''Multi-GPU (mGPU)''' verteilen bei nDisplay Rendering-Arbeit auf mehrere Grafikkarten. Sie benutzen ähnliche Hardware, arbeiten intern aber unterschiedlich. Beide Verfahren sind auf virtuelle Produktion und große, synchronisierte Anzeigeflächen ausgerichtet.

== Begriffe kurz erklärt ==

* '''nDisplay''' verteilt Unreal-Ausgaben auf einen Verbund aus Rechnern, Displays und Render-Viewports.
* Ein '''Viewport''' ist der zu rendernde Bildausschnitt.
* Beim '''Inner Frustum''' rendert eine ICVFX-Kamera den für die reale Kamera sichtbaren Bereich; das '''Outer Frustum''' füllt den übrigen LED-Hintergrund.
* Ein '''Prozess''' ist eine laufende Instanz der Unreal-Anwendung.

== Multi-Process Rendering ==

Multi-Process startet pro Render-Rechner zwei getrennte Unreal-Prozesse:

# Der '''Onscreen-Knoten''' läuft auf der primären GPU, rendert beispielsweise das Outer Frustum, setzt das Endbild zusammen und gibt es aus.
# Der '''Offscreen-Knoten''' läuft headless, also ohne sichtbares Fenster, auf der zweiten GPU und rendert beispielsweise das Inner Frustum.
# Zwischen den Prozessen wird nur die fertig gerenderte Textur über CPU und Mainboard übertragen. Der Onscreen-Knoten fügt sie in sein Bild ein.

Epic bezeichnet Multi-Process für die meisten Szenen als schneller als das ältere mGPU-Verfahren. Es ist außerdem Epics empfohlener Weg für mehrere NVIDIA-Ada-Lovelace-GPUs, weil diese kein NVLink unterstützen.

=== Voraussetzungen und Einrichtung ===

* Mindestens zwei GPUs; SLI muss deaktiviert sein. Premium Mosaic ist ungeeignet, weil es SLI aktiviert.
* Im nDisplay Config Asset erhält der Onscreen-Knoten typischerweise '''Graphics Adapter 0'''. Der zusätzliche Offscreen-Knoten erhält typischerweise '''Graphics Adapter 1''' und '''Headless Rendering'''. Die tatsächliche Nummerierung muss am Rechner geprüft werden.
* Für die ICVFX-Kamera werden Media Output und Media Input mit demselben eindeutigen, groß-/kleinschreibungssensitiven Namen verbunden.
* Der Eingang wird '''Framelocked''', damit die Textur zum richtigen Frame gehört. Epic verwendet im Beispiel außerdem '''Zero Latency'''.
* Beide Knoten werden in Switchboard verbunden und gemeinsam gestartet; pro Rechner genügt ein Switchboard Listener.

== Klassisches nDisplay Multi-GPU ==

Beim mGPU-Modus läuft grundsätzlich eine Unreal-Instanz auf dem Rechner. Ein Viewport oder Inner Frustum wird über seinen '''GPUIndex''' einer GPU zugewiesen. Das Ergebnis wird zur ausgebenden GPU kopiert und dort zusammengesetzt.

Mit NVIDIA NVLink kann die Übertragung direkt von GPU zu GPU erfolgen. Ohne NVLink beschreibt Epic einen Peer-to-Peer-Transfer, der über CPU und PCIe langsamer sein kann. Zur Aktivierung:

# Im nDisplay Config Asset '''Configuration > Render Frame Settings > Multi GPU Mode''' einschalten.
# Am Viewport oder an der ICVFX-Kamera den gewünschten '''GPUIndex''' setzen.
# In Switchboard '''Number of GPUs''' auf die vorhandene GPU-Anzahl setzen.

== Direkter Vergleich ==

{| class="wikitable"
! Punkt !! Multi-Process !! nDisplay mGPU
|-
| Unreal-Instanzen pro Rechner || Zwei getrennte Prozesse || Eine Instanz
|-
| Typische Aufteilung || Onscreen- und Offscreen-Knoten || Viewport/Inner Frustum per GPUIndex
|-
| Austausch || Fertige Textur über CPU/Mainboard || GPU-Ressourcen bzw. Bildtransfer; NVLink ist vorteilhaft
|-
| Epics Einordnung || In den meisten Fällen empfohlen und schneller, abhängig von der Szene || Älteres Verfahren; sinnvoll, wenn die konkrete Anlage davon profitiert
|-
| Wichtig || SLI deaktivieren || Multi GPU Mode und GPU-Anzahl konfigurieren
|}

== Abgrenzung zu UE5 Heterogeneous Multi-GPU ==

Jans Projekt [[UE5 Heterogeneous Multi-GPU]] ist '''keines dieser nDisplay-Verfahren'''. Es verfolgt explizites Direct3D-12-Unlinked-Multiadapter-Compute mit unterschiedlichen GPUs, derzeit Intel UHD als Worker neben einer NVIDIA RTX 5060. Arbeit, Cross-Adapter-Ressourcen und Synchronisation werden im eigenen Code gesteuert.

Die entscheidenden Unterschiede:

* Epic verteilt bei nDisplay fertige Renderaufgaben wie Viewports oder Frustums. Jans Ansatz will einzelne Compute-Arbeiten innerhalb einer angepassten Engine-/RHI-Pipeline auslagern.
* Multi-Process benötigt zwei Unreal-Prozesse; Jans Ansatz arbeitet nicht nach dem Onscreen-/Offscreen-Muster.
* nDisplay mGPU ist nicht automatisch herstellerheterogen und nicht gleichbedeutend mit explizitem D3D12-Unlinked-Multiadapter.
* Aus Epics Empfehlung für Multi-Process folgt daher keine Aussage über die Leistung oder Machbarkeit von Jans Forschungsansatz. Beide lösen verschiedene Probleme.

== Praxisentscheidung ==

* Für LED-Wände und ICVFX mit klar trennbarem Inner/Outer Frustum zuerst Multi-Process testen.
* Wenn eine bestehende nDisplay-Anlage mit Viewport-Zuweisung und passender Transferhardware arbeitet, mGPU gezielt benchmarken.
* Für allgemeine Spiele- oder Compute-Lastverteilung auf unterschiedlichen GPUs ist keiner der beiden nDisplay-Wege ein fertiger Ersatz für Jans eigene Multiadapter-Implementierung.

== Quellen ==

* [https://dev.epicgames.com/documentation/unreal-engine/multi-process-rendering-with-unreal-engine?lang=en-US Epic: Multi-Process Rendering] (UE 5.8, abgerufen am 4. September 2026)
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/getting-started-with-multi-process-rendering-in-unreal-engine Epic: Getting Started with Multi-Process Rendering] (UE 5.8, abgerufen am 4. September 2026)
* [https://dev.epicgames.com/documentation/unreal-engine/ndisplay-overview-for-unreal-engine?lang=en-US Epic: nDisplay Overview – Multi-GPU Support] (UE 5.8, abgerufen am 4. September 2026)

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Multi-GPU]]
[[Kategorie:nDisplay]]

Global Shaders und Compute Shader in Unreal Engine 5

2026-09-06T09:37:13Z

Elaina: Elaina verschob die Seite Global Shaders und Compute Shader in Unreal Engine 5 nach Global Shaders und Compute Shader: Redundanten Titelzusatz entfernt

#WEITERLEITUNG [[Global Shaders und Compute Shader]]

Global Shaders und Compute Shader

2026-09-06T09:37:13Z

Elaina: Elaina verschob die Seite Global Shaders und Compute Shader in Unreal Engine 5 nach Global Shaders und Compute Shader: Redundanten Titelzusatz entfernt

{{Hinweis|Stand: Unreal Engine 5.8. Dieser Artikel fasst die aktuelle offizielle Epic-Dokumentation zusammen.}}

'''Global Shaders''' sind Shader, die in Unreal Engine direkt über C++ registriert und verwendet werden. Sie sind nicht an ein Material oder ein bestimmtes Mesh gebunden und eignen sich deshalb für allgemeine Rendering- und Compute-Aufgaben wie Post-Processing, Bildoperationen, Buffer-Verarbeitung oder eigene Render-Passes.

{| class="wikitable"
|+ Artikelstatus
|-
! Bezugsstand
| Unreal Engine 5.8
|-
! Letzte Aktualisierung
| 2. September 2026
|-
! Zentrale Klassen und Hilfen
| <code>FGlobalShader</code>, <code>FComputeShaderUtils</code>, <code>FRDGBuilder</code>
|-
! Shader-Dateityp
| <code>.usf</code> (Unreal Shader File)
|}

== Einsatzgebiete ==

Global Shaders kommen zum Einsatz, wenn eine Aufgabe nicht sinnvoll über den Material Editor abgebildet werden kann oder bewusst unabhängig von Materialien und Meshes bleiben soll. Typische Beispiele sind:

* Compute-Berechnungen auf Buffern oder Texturen
* eigene Post-Processing-Schritte
* Fullscreen-Passes
* Erzeugen, Kopieren oder Umwandeln von GPU-Daten
* Debug- und Visualisierungs-Passes
* experimentelle Rendering-Pipelines

Ein Compute Shader ist dabei ein möglicher Shader-Typ. Er verarbeitet Daten in frei definierbaren Thread-Gruppen und erzeugt nicht unmittelbar Rastergrafik.

== Bausteine eines Global Shaders ==

Ein Global Shader besteht in der Regel aus mehreren Teilen:

# einer Shader-Datei mit HLSL-Code (<code>.usf</code>)
# einer von <code>FGlobalShader</code> abgeleiteten C++-Klasse
# einer Parameterstruktur für Eingaben und Ausgaben
# einem Registrierungs-Makro, das Klasse, Datei, Einstiegspunkt und Shader-Stufe verbindet
# Code, der den Shader auswählt, Parameter bindet und den Dispatch oder Draw-Aufruf ausführt

=== Speicherort der Shader-Dateien ===

Engine-eigene Shader liegen unter <code>Engine/Shaders</code>. Shader eines Plugins gehören in dessen <code>Shaders</code>-Verzeichnis. Die Trennung hält experimentellen Code von den Engine-Dateien fern und erleichtert Updates sowie Versionsverwaltung.

== Minimaler Compute Shader ==

Das folgende vereinfachte Beispiel verdoppelt jeden Wert eines Eingabebuffers. Es dient der Orientierung und muss an die konkrete Modul- und Ressourcenstruktur angepasst werden.

<syntaxhighlight lang="hlsl">
StructuredBuffer<uint> InputValues;
RWStructuredBuffer<uint> OutputValues;
uint ElementCount;

[numthreads(64, 1, 1)]
void MainCS(uint3 DispatchThreadId : SV_DispatchThreadID)
{
const uint Index = DispatchThreadId.x;
if (Index >= ElementCount)
{
return;
}

OutputValues[Index] = InputValues[Index] * 2;
}
</syntaxhighlight>

<code>numthreads(64, 1, 1)</code> legt fest, dass jede Thread-Gruppe 64 Threads in X-Richtung enthält. Die Gesamtzahl der Gruppen muss auf der CPU-Seite passend zur Elementzahl berechnet werden.

== C++-Repräsentation ==

Die C++-Klasse beschreibt den Shader gegenüber Unreal und definiert seine Parameter. Ein typisches Grundmuster sieht so aus:

<syntaxhighlight lang="cpp">
class FExampleComputeShader : public FGlobalShader
{
DECLARE_GLOBAL_SHADER(FExampleComputeShader);
SHADER_USE_PARAMETER_STRUCT(FExampleComputeShader, FGlobalShader);

BEGIN_SHADER_PARAMETER_STRUCT(FParameters, )
SHADER_PARAMETER(uint32, ElementCount)
SHADER_PARAMETER_SRV(StructuredBuffer<uint32>, InputValues)
SHADER_PARAMETER_UAV(RWStructuredBuffer<uint32>, OutputValues)
END_SHADER_PARAMETER_STRUCT()
};

IMPLEMENT_GLOBAL_SHADER(
FExampleComputeShader,
"/Plugin/Example/Private/ExampleCompute.usf",
"MainCS",
SF_Compute
);
</syntaxhighlight>

Wichtige Punkte:

* <code>DECLARE_GLOBAL_SHADER</code> deklariert den Shader-Typ.
* <code>SHADER_USE_PARAMETER_STRUCT</code> aktiviert die strukturierte Parameterbindung.
* <code>BEGIN_SHADER_PARAMETER_STRUCT</code> beschreibt Konstanten, SRVs und UAVs.
* <code>IMPLEMENT_GLOBAL_SHADER</code> verbindet C++-Klasse, virtuellen Shader-Pfad, Einstiegspunkt und Shader-Stufe.
* <code>SF_Compute</code> kennzeichnet den Shader als Compute Shader.

Je nach Modulgrenze kann statt <code>DECLARE_GLOBAL_SHADER</code> eine exportierte Shader-Deklaration nötig sein.

== Kompilierungsbedingungen ==

Nicht jeder Shader sollte für jede Plattform oder jedes Feature Level gebaut werden. Dafür kann die Klasse eine Kompilierungsbedingung definieren. So lässt sich beispielsweise verhindern, dass ein Compute Shader für eine Plattform ohne die benötigten Fähigkeiten kompiliert wird.

Auch Compile-Time-Definitionen können aus C++ an den Shader übergeben werden. Das ist nützlich für feste Gruppengrößen, optionale Codepfade oder plattformspezifische Varianten.

Das Modul, das einen neuen Shader-Typ registriert, muss früh genug geladen werden. Wird der Typ erst nach der Initialisierung der Engine bekannt, kann Unreal die Registrierung mit einem Assert ablehnen. Für Shader-Module ist deshalb eine frühe Ladephase wie <code>PostConfigInit</code> relevant.

== Dispatch über das RHI ==

<code>FComputeShaderUtils::Dispatch</code> sendet einen Compute Shader mit Parametern und Gruppenzahl an eine <code>FRHIComputeCommandList</code>. Das ist die direkte Variante auf RHI-Ebene.

<syntaxhighlight lang="cpp">
const FIntVector GroupCount =
FComputeShaderUtils::GetGroupCount(ElementCount, 64);

FComputeShaderUtils::Dispatch(
RHICmdList,
ComputeShader,
Parameters,
GroupCount
);
</syntaxhighlight>

Die Hilfsfunktion <code>GetGroupCount</code> rundet die benötigte Gruppenzahl passend auf. Der Bounds-Check im Shader bleibt trotzdem notwendig, weil die letzte Gruppe mehr Threads als verbleibende Elemente enthalten kann.

== Dispatch über den Render Dependency Graph ==

Für regulären High-Level-Rendering-Code empfiehlt Unreal den Render Dependency Graph (RDG). Ein Compute-Pass kann dort über <code>FComputeShaderUtils::AddPass</code> registriert werden.

RDG kennt dadurch die beteiligten Ressourcen und kann unter anderem:

* Abhängigkeiten zwischen Passes bestimmen
* Ressourcenübergänge und Barriers verwalten
* ungenutzte Passes entfernen
* Lebenszeiten temporärer Ressourcen optimieren
* geeignete Arbeit parallelisieren
* Async-Compute-Passes synchronisieren

Die Parameter müssen alle verwendeten RDG-Ressourcen korrekt deklarieren. Innerhalb des Passes darf nur auf Ressourcen zugegriffen werden, die über die Parameterstruktur als Abhängigkeit bekannt sind.

== Shader-Entwicklung und Fehlersuche ==

Für die Entwicklung sind folgende Maßnahmen hilfreich:

* <code>r.ShaderDevelopmentMode=1</code> in <code>ConsoleVariables.ini</code> aktivieren, um ausführlichere Shader-Compile-Logs zu erhalten.
* Einstiegspunkt, virtuellen Shader-Pfad und Shader-Stufe kontrollieren.
* Sicherstellen, dass das Plugin und alle benötigten Module als Abhängigkeiten eingetragen sind.
* Modul-Ladephase prüfen, wenn Unreal meldet, dass ein Shader-Typ zu spät registriert wurde.
* Parameterstruktur zwischen HLSL und C++ sorgfältig abgleichen.
* Thread-Gruppengröße und Bounds-Checks prüfen.
* Ressourcenstatus, SRV-/UAV-Bindung und Synchronisation kontrollieren.
* Bei RDG-Passes aussagekräftige Event-Namen verwenden und bei Bedarf RDG Insights einsetzen.

== Bezug zum Heterogeneous-Multi-GPU-Projekt ==

Für das Projekt [[UE5 Heterogeneous Multi-GPU]] ist der Global-Shader-Weg besonders interessant: Unreal kann den Shader wie gewohnt kompilieren und das resultierende Shader-Bytecode-Blob bereitstellen. Dieses Blob kann anschließend als Grundlage für eine Compute Pipeline State auf dem separaten Worker-Device dienen.

Der geplante erste Test lässt sich in folgende Schritte zerlegen:

# einfachen Global Compute Shader in einem früh geladenen Modul registrieren
# Shader über Unreals reguläre Shader-Pipeline kompilieren lassen
# kompilierten Bytecode für den gewählten Worker-Adapter prüfen
# passende Root Signature und Compute Pipeline State auf dem Worker-<code>ID3D12Device</code> erzeugen
# Input- und Output-Buffer auf dem Worker-Device bereitstellen
# Compute Dispatch auf der eigenen Worker-Command-Queue ausführen
# Ergebnis über Readback zurückholen und auf der CPU verifizieren

Dabei ist wichtig, zwischen zwei Ebenen zu unterscheiden: Unreal übernimmt zunächst Registrierung und Kompilierung des Shaders; die Ausführung auf dem unabhängigen Worker-Device folgt im experimentellen Projekt über den eigenen D3D12-Pfad und nicht automatisch über Unreals normales RHI oder RDG.

== Quellen und weiterführende Dokumentation ==

* [https://dev.epicgames.com/documentation/en-us/unreal-engine/adding-global-shaders-to-unreal-engine Adding Global Shaders to Unreal Engine] – Epic Games, UE 5.8
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/overview-of-shaders-in-plugins-unreal-engine Overview of Shaders in Plugins] – Epic Games, UE 5.8
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/shader-development-in-unreal-engine Shader Development in Unreal Engine] – Epic Games, UE 5.8
* [https://dev.epicgames.com/documentation/unreal-engine/API/Runtime/RenderCore/FComputeShaderUtils__Dispatch FComputeShaderUtils::Dispatch] – API-Referenz, Epic Games, UE 5.8
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/API/Runtime/RenderCore/FComputeShaderUtils__AddPass FComputeShaderUtils::AddPass] – API-Referenz, Epic Games, UE 5.8
* [https://dev.epicgames.com/documentation/unreal-engine/render-dependency-graph-in-unreal-engine Render Dependency Graph] – Epic Games, UE 5.8

''Dieser Artikel ist eine eigenständige deutschsprachige Zusammenfassung mit Projektbezug und keine vollständige Übersetzung der Epic-Dokumentation.''

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Shader]]
[[Kategorie:Compute Shader]]
[[Kategorie:Rendering]]
[[Kategorie:Direct3D 12]]

Direct3D 12, Shader Model 6 und Windows-RHI in Unreal Engine 5

2026-09-06T09:37:03Z

Elaina: Elaina verschob die Seite Direct3D 12, Shader Model 6 und Windows-RHI in Unreal Engine 5 nach Direct3D 12, Shader Model 6 und Windows-RHI: Redundanten Titelzusatz entfernt

#WEITERLEITUNG [[Direct3D 12, Shader Model 6 und Windows-RHI]]

Direct3D 12, Shader Model 6 und Windows-RHI

2026-09-06T09:37:03Z

Elaina: Elaina verschob die Seite Direct3D 12, Shader Model 6 und Windows-RHI in Unreal Engine 5 nach Direct3D 12, Shader Model 6 und Windows-RHI: Redundanten Titelzusatz entfernt

{{Hinweis|Stand: Unreal Engine 5.8 unter Windows. Bezeichnungen in der Oberfläche können bei lokalisierten Editor-Versionen leicht abweichen.}}

'''Direct3D 12 (D3D12)''' ist Microsofts moderne Grafikschnittstelle. Unreal Engine greift nicht direkt aus jedem Spielsystem darauf zu, sondern über das '''Rendering Hardware Interface (RHI)'''. Das RHI vereinheitlicht verschiedene Grafik-APIs wie Direct3D 11, Direct3D 12 und Vulkan.

'''Shader Model 6 (SM6)''' bezeichnet die neuere Shader-Funktionsstufe und den zugehörigen Compilerpfad. D3D12 und SM6 sind verschiedene Einstellungen: D3D12 wählt die Grafik-API, SM6 das Shader-Ziel innerhalb des D3D12-Pfads.

== Warum D3D12 und SM6? ==

Epic empfiehlt D3D12 für die meisten Spiele. In UE 5.8 benötigen mehrere moderne Rendering-Funktionen SM6:

* Lumen und MegaLights unter Windows setzen D3D12 und aktiviertes SM6 voraus; Lumen Hardware Ray Tracing benötigt SM6.
* Nanite und Virtual Shadow Maps benötigen unter Windows D3D12 mit SM6; für Nanite nennt Epic D3D12 mit Shader-Model-6.6-Atomics sowie aktuelle Treiber.
* Temporal Super Resolution läuft grundsätzlich auch mit SM5, kann unter D3D12/SM6 aber 16-Bit-Typen nutzen. Der SM5-Pfad ist unter anderem durch acht UAVs pro Shader eingeschränkt. Ein UAV ist eine Shader-Ressource mit ungeordnetem Lese-/Schreibzugriff.

SM6 macht eine GPU nicht automatisch schneller. Es schaltet Fähigkeiten frei; Nutzen und Kosten hängen von Renderer, Shadern, Treiber und Hardware ab.

== Windows-RHI im Editor einstellen ==

# '''Edit > Project Settings > Platforms > Windows''' öffnen.
# Unter '''Targeted RHIs''' die benötigten Ziele aktivieren. Für den modernen Windows-Pfad '''DirectX 12 (SM6)''' einschalten.
# '''Default RHI''' auf '''DirectX 12''' setzen. Epic weist darauf hin, dass das ausgewählte Standard-RHI auch als Targeted RHI aktiviert sein muss.
# Den Editor neu starten. Eine RHI-Änderung wird erst danach wirksam; geänderte Shaderziele können eine längere Shader-Kompilierung auslösen.

'''DirectX 11 & 12 (SM5)''' ist ein separater Kompatibilitätspfad. Wer SM5 zusätzlich aktiviert, erzeugt weitere Shader-Varianten und vergrößert damit typischerweise Cook- und Build-Aufwand. Für eine klar definierte D3D12-/SM6-Zielhardware sollte nur der tatsächlich benötigte Satz gepflegt werden; bei breiter Hardwareunterstützung muss der Fallback bewusst getestet werden.

== Kurzzeitig über die Kommandozeile testen ==

Die UE-5.8-Referenz dokumentiert folgende Startparameter:

* <code>-dx12</code> erzwingt das D3D12-RHI.
* <code>-dx11</code> erzwingt das D3D11-RHI.
* <code>-sm6</code> beziehungsweise <code>-sm5</code> erzwingt das Shader Model.
* <code>-forcedisablesm6</code> deaktiviert SM6 für einen Vergleichstest.

Beispiel:

<syntaxhighlight lang="powershell">
UnrealEditor.exe MeinProjekt.uproject -dx12 -sm6
</syntaxhighlight>

Erzwungene Parameter eignen sich für Diagnose und A/B-Tests. Sie ersetzen keine korrekt gepflegten Targeted RHIs. Eine nicht unterstützte erzwungene Kombination kann den Start verhindern.

== Praktische Prüfliste ==

# Windows-Version, GPU-Funktionsumfang und aktuellen stabilen Herstellertreiber prüfen.
# D3D12 als Default RHI und D3D12 SM6 als Ziel aktivieren.
# Nach dem Neustart das Startprotokoll kontrollieren: verwendetes RHI, gewählter Adapter und Shader-Plattform müssen zur Erwartung passen.
# Benötigte Funktionen einzeln prüfen: Nanite, Virtual Shadow Maps, Lumen oder Hardware Ray Tracing.
# Einen Development- oder Test-Build auf der schwächsten unterstützten Ziel-GPU ausführen. Ein erfolgreicher Editorstart allein beweist keine vollständige Kompatibilität.
# D3D11/SM5 nur behalten, wenn dieser Pfad wirklich unterstützt, gekocht und getestet wird.

== Typische Stolperfallen ==

* '''D3D12 aktiviert, SM6 vergessen:''' Das RHI stimmt, moderne Funktionen bleiben dennoch nicht verfügbar.
* '''Default RHI ohne passendes Target:''' Epic verlangt, dass das Standard-RHI zugleich als Ziel ausgewählt ist.
* '''Altes Windows oder alter Treiber:''' Besonders Nanite und Virtual Shadow Maps benötigen geeignete Windows-Builds, D3D12 Agility SDK-Unterstützung und aktuelle Treiber.
* '''Shader-Neukompilierung unterschätzt:''' Ein Wechsel des Shaderziels kann viele Shader neu erzeugen.
* '''Nur auf einer GPU getestet:''' D3D12/SM6-Unterstützung und Stabilität sind Eigenschaften der gesamten Kombination aus Betriebssystem, Treiber und Hardware.

== Bezug zu UE5 Heterogeneous Multi-GPU ==

Für [[UE5 Heterogeneous Multi-GPU]] ist D3D12 nicht nur ein Renderer-Schalter, sondern die Grundlage des expliziten Unlinked-Multiadapter-Prototyps. Die Windows-RHI-Einstellungen bestimmen zunächst den regulären Unreal-D3D12-Pfad und die Shaderplattform. Sie aktivieren jedoch '''nicht automatisch''':

* eine zweite, heterogene GPU,
* Cross-Adapter Heaps oder gemeinsam nutzbare Ressourcen,
* Shared Fences zur Synchronisation,
* die Auswahl eines Worker-Adapters oder die Verteilung von Compute-Arbeit.

Diese Funktionen müssen Jans Engine-Anpassungen ausdrücklich auf D3D12-Ebene implementieren. Ein sauberer D3D12-/SM6-Basiszustand ist trotzdem wichtig: Er trennt allgemeine RHI- oder Shaderprobleme von Fehlern im Multiadapter-Code.

== Quellen ==

* [https://dev.epicgames.com/documentation/unreal-engine/windows-settings-in-the-unreal-engine-project-settings?lang=en-US Epic: Windows Settings in Project Settings] (UE 5.8, abgerufen am 4. September 2026)
* [https://dev.epicgames.com/documentation/unreal-engine/hardware-and-software-specifications-for-unreal-engine?lang=en-US Epic: Hardware and Software Specifications] (UE 5.8, abgerufen am 4. September 2026)
* [https://dev.epicgames.com/documentation/unreal-engine/unreal-engine-command-line-arguments-reference?lang=en-US Epic: Command-Line Arguments Reference] (UE 5.8, abgerufen am 4. September 2026)

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Direct3D 12]]
[[Kategorie:Shader]]
[[Kategorie:Windows]]

Race Condition

2026-09-06T09:26:34Z

Elaina: Die Seite wurde neu angelegt: „Eine '''Race Condition''' (deutsch etwa '''Wettlaufsituation''') entsteht, wenn das Ergebnis eines Programms davon abhängt, in welcher zeitlichen Reihenfolge mehrere nebenläufige Vorgänge ausgeführt werden. Da Threads, Prozesse oder GPU-Queues nicht bei jedem Lauf exakt gleich geplant werden, kann derselbe Code scheinbar korrekt funktionieren und später sporadisch falsche Ergebnisse liefern. Race Conditions treten besonders häufig auf, wenn mehrere…“

Eine '''Race Condition''' (deutsch etwa '''Wettlaufsituation''') entsteht, wenn das Ergebnis eines Programms davon abhängt, in welcher zeitlichen Reihenfolge mehrere nebenläufige Vorgänge ausgeführt werden. Da Threads, Prozesse oder GPU-Queues nicht bei jedem Lauf exakt gleich geplant werden, kann derselbe Code scheinbar korrekt funktionieren und später sporadisch falsche Ergebnisse liefern.

Race Conditions treten besonders häufig auf, wenn mehrere Ausführungseinheiten gemeinsamen Zustand lesen und verändern, ohne den Zugriff ausreichend zu koordinieren.<ref name="MSRace">Microsoft: [https://learn.microsoft.com/en-us/archive/msdn-magazine/2008/june/tools-and-techniques-to-identify-concurrency-issues Tools and Techniques to Identify Concurrency Issues]. Abgerufen am 6. September 2026.</ref>

== Einfaches Beispiel ==

Zwei Threads erhöhen denselben Zähler. Die scheinbar einzelne Operation <code>Zaehler++</code> besteht intern aus mehreren Schritten:

# aktuellen Wert lesen,
# Wert erhöhen,
# neuen Wert zurückschreiben.

Lesen beide Threads gleichzeitig den Wert 10, berechnen beide 11 und schreiben anschließend 11 zurück. Erwartet wurde 12, tatsächlich ging jedoch eine Erhöhung verloren. Welcher Ablauf eintritt, hängt vom Timing ab.

== Race Condition und Data Race ==

Die Begriffe werden oft gleich verwendet, sind aber nicht vollständig identisch:

* Eine '''Race Condition''' ist allgemein ein Fehler, bei dem das Verhalten von einer unerwünschten Reihenfolge nebenläufiger Ereignisse abhängt. Das kann auch Dateien, Netzwerkvorgänge oder GPU-Arbeit betreffen.
* Ein '''Data Race''' beziehungsweise '''Datenrennen''' bezeichnet enger gefasst unkoordinierte, gleichzeitig stattfindende Speicherzugriffe auf dieselben Daten, wobei mindestens ein Zugriff schreibt.

Ein Data Race ist somit eine häufige Form der Race Condition. Nicht jede Race Condition muss jedoch durch denselben Speicherort verursacht werden.

== Typische Ursachen ==

* mehrere Threads verändern dieselbe Variable oder Datenstruktur;
* ein Objekt wird benutzt, bevor seine Initialisierung abgeschlossen ist;
* ein asynchroner Auftrag veröffentlicht ein Ergebnis zu früh;
* eine Ressource wird freigegeben, obwohl ein anderer Auftrag sie noch verwendet;
* zwei GPU-Queues oder Adapter greifen ohne passende Fence-Abhängigkeit auf zusammengehörige Daten zu;
* die Reihenfolge von Prüfung und anschließender Änderung ist nicht atomar, etwa bei „prüfen, ob frei“ und „reservieren“.

== Vermeidung ==

Race Conditions lassen sich unter anderem verhindern durch:

* '''Mutexe, Critical Sections und Locks''', die einen kritischen Abschnitt nur für einen Ausführungspfad gleichzeitig zugänglich machen;
* '''atomare Operationen''' für einfache, unteilbare Änderungen;
* '''Events, Semaphore und Condition Variables''' zur geregelten Reihenfolge von Arbeiten;
* '''Fences und Barriers''' zur Synchronisation von GPU-Queues, Ressourcenübergängen und Speicherzugriffen;
* unveränderliche Daten, getrennte Zuständigkeiten und Message Queues, wodurch gemeinsam beschreibbarer Zustand reduziert wird.

Windows stellt dafür sowohl Synchronisationsobjekte als auch leichtgewichtige Primitive wie Critical Sections und SRW Locks bereit.<ref name="MSSync">Microsoft: [https://learn.microsoft.com/en-us/windows/win32/procthread/synchronizing-execution-of-multiple-threads Synchronizing Execution of Multiple Threads]. Abgerufen am 6. September 2026.</ref> Synchronisation muss jedoch zur tatsächlich geschützten Ressource passen. Ein GPU-Fence ordnet beispielsweise GPU-Arbeit, ersetzt aber nicht automatisch den Schutz gemeinsam veränderter CPU-Daten.

== Erkennung ==

Race Conditions sind oft schwer reproduzierbar, weil Debug-Ausgaben, Breakpoints oder eine andere Auslastung bereits das Timing verändern können. Hinweise sind seltene falsche Werte, beschädigte Daten, flackernde Ausgaben, sporadische Abstürze oder Fehler, die nur auf Mehrkernsystemen auftreten.

Hilfreich sind Stress- und Wiederholungstests, Thread- und GPU-Debugger, Race-Detector-Werkzeuge sowie klar protokollierte Zustandsübergänge. Die eigentliche Lösung besteht nicht darin, das Timing künstlich zu verändern, sondern die erforderliche Reihenfolge ausdrücklich zu synchronisieren. Auch Speicherreihenfolge und Sichtbarkeit zwischen Prozessorkernen müssen berücksichtigt werden.<ref name="MSOrdering">Microsoft: [https://learn.microsoft.com/en-us/windows/win32/sync/synchronization-and-multiprocessor-issues Synchronization and Multiprocessor Issues]. Abgerufen am 6. September 2026.</ref>

== Abgrenzung zum Deadlock ==

Bei einer Race Condition laufen mehrere Vorgänge weiter, aber ihre unkontrollierte Reihenfolge erzeugt möglicherweise ein falsches Ergebnis. Bei einem '''Deadlock''' warten Vorgänge dagegen dauerhaft aufeinander und kommen nicht mehr voran. Übermäßig oder inkonsistent eingesetzte Locks können Race Conditions beseitigen, zugleich aber neue Deadlocks verursachen.

== Siehe auch ==

* [[UE5 Heterogeneous Multi-GPU]]
* [[Rendering Hardware Interface (RHI) in Unreal Engine 5]]
* [[Render Dependency Graph in Unreal Engine 5]]

== Einzelnachweise ==

<references />

[[Kategorie:Programmierung]]
[[Kategorie:Parallelverarbeitung]]
[[Kategorie:Unreal Engine 5]]

Subsurface Scattering

2026-09-05T15:17:49Z

Elaina: Die Seite wurde neu angelegt: „'''Subsurface Scattering''' (kurz '''SSS''', deutsch etwa '''Streuung unterhalb der Oberfläche''') beschreibt, wie Licht in ein Material eindringt, im Inneren mehrfach gestreut und an einer anderen Stelle wieder austritt. Dadurch wirken Materialien wie Haut, Wachs, Marmor, Jade, Milch, Schnee oder Fruchtfleisch weich und leicht durchleuchtet. Ohne SSS sehen solche Oberflächen häufig zu hart, trocken oder plastikartig aus. In der Computergrafik ist SSS…“

'''Subsurface Scattering''' (kurz '''SSS''', deutsch etwa '''Streuung unterhalb der Oberfläche''') beschreibt, wie Licht in ein Material eindringt, im Inneren mehrfach gestreut und an einer anderen Stelle wieder austritt. Dadurch wirken Materialien wie Haut, Wachs, Marmor, Jade, Milch, Schnee oder Fruchtfleisch weich und leicht durchleuchtet. Ohne SSS sehen solche Oberflächen häufig zu hart, trocken oder plastikartig aus.

In der Computergrafik ist SSS ein Teil der Lichttransportberechnung. Eine physikalisch genaue Simulation ist aufwendig, weshalb Echtzeit-Engines wie [[Unreal Engine 5]] spezialisierte Shading-Modelle und Näherungsverfahren verwenden.

== Physikalisches Prinzip ==

Bei einer ideal undurchsichtigen Oberfläche wird Licht vereinfacht am Auftreffpunkt reflektiert oder absorbiert. Bei einem streuenden Material läuft der Vorgang anders ab:

# Licht trifft auf die Oberfläche und ein Teil davon wird direkt reflektiert.
# Ein weiterer Teil dringt durch die Materialgrenze ein.
# Im Inneren wird das Licht an mikroskopischen Strukturen mehrfach abgelenkt.
# Bestimmte Wellenlängen werden stärker absorbiert als andere.
# Das verbleibende Licht verlässt das Material an derselben oder an einer benachbarten Stelle.

Deshalb sind Eintritts- und Austrittspunkt des Lichts nicht identisch. Diese räumliche Verteilung ist der entscheidende Unterschied zur gewöhnlichen diffusen Reflexion. In einer vollständigen Lichttransportbeschreibung wird sie mit einer '''BSSRDF''' (''Bidirectional Surface Scattering Reflectance Distribution Function'') modelliert. Eine BRDF beschreibt nur Reflexion an einem einzelnen Oberflächenpunkt; eine BSSRDF kann verschiedene Eintritts- und Austrittspunkte berücksichtigen.<ref name="Jensen2001">Henrik Wann Jensen u. a.: [https://graphics.stanford.edu/papers/bssrdf/bssrdf.pdf A Practical Model for Subsurface Light Transport]. SIGGRAPH 2001.</ref>

== Streuung, Absorption und Farbe ==

Das Erscheinungsbild hängt hauptsächlich von zwei Vorgängen ab:

* '''Streuung''' ändert die Richtung des Lichts. Starke Streuung verteilt Beleuchtung über eine größere Fläche und macht harte Helligkeitsübergänge weicher.
* '''Absorption''' entfernt bestimmte Wellenlängen aus dem Licht. Dadurch verändert sich die Farbe auf dem Weg durch das Material.

Die mittlere Weglänge eines Photons bis zur nächsten Wechselwirkung wird als '''Mean Free Path''' bezeichnet. Sie kann für Rot, Grün und Blau unterschiedlich sein. Bei menschlicher Haut dringt rotes Licht im Allgemeinen weiter ein als blaues oder grünes Licht. Das erzeugt unter anderem den warmen roten Schimmer an dünnen, von hinten beleuchteten Bereichen wie Ohren oder Nasenflügeln.

Die sichtbare Wirkung hängt außerdem von Materialdicke, Beleuchtungsrichtung, Oberflächenform und Maßstab ab. Ein SSS-Radius, der bei einem Kopf glaubwürdig aussieht, ist bei einem kleinen Modell oder einem meterhohen Objekt nicht automatisch korrekt.

== Abgrenzung zu ähnlichen Effekten ==

SSS wird leicht mit Transparenz oder einfacher Lichtdurchlässigkeit verwechselt:

{| class="wikitable"
! Effekt
! Kennzeichen
! Typische Beispiele
|-
| '''Subsurface Scattering'''
| Licht dringt ein, wird im Material räumlich verteilt und tritt an anderer Stelle wieder aus.
| Haut, Wachs, Marmor, Jade
|-
| '''Transparenz'''
| Hinter dem Material liegende Objekte bleiben direkt erkennbar.
| Klarglas, sauberes Wasser
|-
| '''Transluzenz'''
| Licht gelangt hindurch, Details dahinter erscheinen jedoch unscharf oder gar nicht.
| Milchglas, dünnes Papier
|-
| '''Transmission'''
| Oberbegriff für Licht, das ein Material durchquert; kann gerichtet oder gestreut sein.
| Blätter, Stoff, Hautränder
|-
| '''Diffuse Reflexion'''
| Licht wird am betrachteten Oberflächenpunkt verteilt; kein räumlicher Transport unter der Oberfläche.
| Kreide, matte Farbe
|}

Ein Material kann mehrere dieser Eigenschaften gleichzeitig besitzen. Haut hat beispielsweise direkte Reflexion an der öligen Oberfläche, diffuse Anteile, Streuung in mehreren Gewebeschichten und sichtbare Transmission an dünnen Stellen.

== Warum Echtzeit-SSS nur eine Näherung ist ==

Physikalisch korrekter Untergrund-Lichttransport würde viele Lichtwege im Volumen verfolgen. Offline-Renderer und Path Tracer können dafür aufwendige Random-Walk-, Diffusions- oder BSSRDF-Verfahren einsetzen. In einem Echtzeit-Renderer müssen hingegen Millionen Pixel innerhalb weniger Millisekunden berechnet werden.

Gebräuchliche Näherungen sind:

* '''Screen-Space-Filterung:''' Bereits berechnete Beleuchtung wird in Abhängigkeit von Profil, Tiefe und Materialkennung über benachbarte Bildpunkte verteilt.
* '''Vorgefaltete oder vorintegrierte Modelle:''' Ein Teil der Lichtantwort wird vorab berechnet und während des Renderns günstig nachgeschlagen.
* '''Wrap Lighting und Backscattering:''' Beleuchtung wird um die Silhouette herum erweitert und bei Gegenlicht ergänzt, um den Eindruck innerer Streuung zu erzeugen.
* '''Dickenmasken:''' Dünne Bereiche erhalten stärkere Transmission als dicke Bereiche.

Diese Methoden können sehr überzeugend aussehen, bilden aber nicht jeden Lichtweg geometrisch korrekt ab. Screen-Space-Verfahren kennen beispielsweise nur Informationen, die im aktuellen Kamerabild vorhanden sind.

== Subsurface Scattering in Unreal Engine 5 ==

Unreal Engine stellt mehrere Shading-Modelle für unterschiedliche Materialklassen und Qualitätsziele bereit.<ref name="EpicModels">Epic Games: [https://dev.epicgames.com/documentation/en-us/unreal-engine/shading-models-in-unreal-engine Shading Models in Unreal Engine]. Abgerufen am 5. September 2026.</ref>

=== Subsurface ===

Das Shading Model '''Subsurface''' ist eine vergleichsweise günstige Lösung für opake Materialien wie Wachs, Jade oder stilisierte Haut. Es kombiniert eine um die Oberfläche herumgreifende Beleuchtung mit einem Gegenlichtanteil. Epic beschreibt es als preiswerter, aber qualitativ schwächer als die speziell für Haut vorgesehene Lösung.<ref name="EpicSubsurface">Epic Games: [https://dev.epicgames.com/documentation/en-us/unreal-engine/subsurface-shading-model-in-unreal-engine Subsurface Shading Model in Unreal Engine]. Abgerufen am 5. September 2026.</ref>

Wichtige Materialeingänge sind:

* '''Base Color:''' sichtbare Grundfarbe der Oberfläche.
* '''Subsurface Color:''' Farbe des unter der Oberfläche gestreuten Lichts.
* '''Opacity:''' steuert bei diesem opaken Shading-Modell nicht die gewöhnliche Durchsichtigkeit. Der Wert beeinflusst unter anderem Dichte, Streuweite, Normaleneinfluss und Schattenweichheit. Ein kleinerer Wert lässt Licht weiter durch das Material gelangen.<ref name="EpicSubsurface" />
* '''Roughness, Specular und Normal:''' bestimmen die normale Oberflächenreflexion, die zusätzlich zum SSS-Eindruck erhalten bleibt.

=== Subsurface Profile ===

'''Subsurface Profile''' ist Unreals hochwertigeres Shading-Modell für realistische Haut und ähnliche Materialien. Die Streueigenschaften werden in einem wiederverwendbaren '''Subsurface Profile Asset''' gespeichert und können bearbeitet werden, ohne das Material neu zu kompilieren. Die Berechnung arbeitet überwiegend im Screen Space und verteilt die Beleuchtung über benachbarte Pixel.<ref name="EpicProfile">Epic Games: [https://dev.epicgames.com/documentation/en-us/unreal-engine/subsurface-profile-shading-model-in-unreal-engine Subsurface Profile Shading Model in Unreal Engine]. Abgerufen am 5. September 2026.</ref>

Zu den wichtigsten Profilparametern gehören:<ref name="EpicProfile" />

* '''Surface Albedo:''' diffuse Grundreflexion; sollte zur Base Color des Materials passen.
* '''Mean Free Path Color und Distance:''' legen fest, wie weit die roten, grünen und blauen Lichtanteile im Material gelangen.
* '''World Unit Scale:''' verbindet die Streuweite mit dem Maßstab in Unreal Units beziehungsweise Zentimetern.
* '''Transmission:''' steuert durch das Material gelangendes Licht, einschließlich Extinktion, Brechungsindex und Farbtönung.
* '''Dual Specular:''' kombiniert zwei Glanzkeulen unterschiedlicher Rauheit und kann dadurch die mehrschichtige, mikrostrukturierte Reflexion von Haut glaubwürdiger darstellen.

Beim Subsurface-Profile-Modell maskiert der Materialeingang '''Opacity''' den SSS-Anteil: 0 bedeutet keine Streuung, 1 die volle Wirkung. Das Material bleibt dabei opak. Der Metallic-Eingang steht im klassischen Deferred-Pfad nicht normal zur Verfügung, weil der entsprechende GBuffer-Speicher für Profildaten verwendet wird.<ref name="EpicProfile" />

=== Preintegrated Skin ===

'''Preintegrated Skin''' ist eine ältere beziehungsweise günstigere, speziell auf Haut zugeschnittene Näherung. Sie verwendet ebenfalls den Eingang Subsurface Color, bietet aber weniger Kontrolle und physikalische Tiefe als Subsurface Profile. Für hochwertige menschliche Haut empfiehlt sich in der Regel Subsurface Profile; Preintegrated Skin kann bei einfacheren Figuren oder knapperem Leistungsbudget sinnvoll sein.<ref name="EpicModels" />

=== Two Sided Foliage ===

'''Two Sided Foliage''' ist für dünne, beidseitig sichtbare Flächen wie Blätter gedacht. Hier repräsentiert Subsurface Color vor allem das Licht, das durch das Blatt gelangt. Masken können Adern, Stiele und unterschiedlich dicke Bereiche voneinander trennen. Das ist keine vollständige Volumensimulation, sondern eine auf dünne Vegetation zugeschnittene Transmission-Näherung.<ref name="EpicModels" />

=== Substrate ===

Bei Verwendung von '''Substrate''' werden Materialien aus Schichten beziehungsweise sogenannten Slabs aufgebaut. Für streuende Materialien existieren eigene interne Subsurface-Varianten, unter anderem auf Basis der Mean Free Path. Das Grundprinzip bleibt gleich: Farbe und Weglänge der Streuung müssen zur realen Größe und zum Aufbau des Materials passen. Da sich Substrate und der klassische Materialpfad in Bedienung und Funktionsumfang unterscheiden, sollten konkrete Einstellungen immer für die eingesetzte UE-Version geprüft werden.

== Praktischer Aufbau eines Hautmaterials in UE5 ==

Ein typischer Arbeitsablauf für hochwertige Haut sieht so aus:

# Material anlegen und '''Shading Model = Subsurface Profile''' wählen.
# Ein Subsurface-Profile-Asset erstellen und dem Material zuweisen.
# Physikalisch plausible Base-Color-, Roughness- und Normal-Maps anschließen.
# Eine SSS-Maske über '''Opacity''' einspeisen. Lippen, Ohren und weiche Wangenbereiche dürfen meist stärker streuen; Augenbrauen, Bartstoppeln oder stark verhornte Bereiche schwächer.
# Mean Free Path und World Unit Scale bei neutraler Beleuchtung auf den tatsächlichen Modellmaßstab abstimmen.
# Gegenlicht testen, um Ohren und dünne Partien zu beurteilen.
# Verschiedene Kameradistanzen, Hauttöne und Lichtgrößen prüfen. SSS darf Details weichzeichnen, aber nicht das ganze Gesicht wie selbstleuchtendes Gummi erscheinen lassen.

Epic weist darauf hin, dass das Profil nur ein Bestandteil glaubwürdiger Haut ist. Geometrie, Texturen, Mikronormalen, Rauheit, Spiegelreflexion und Beleuchtung bleiben ebenso wichtig.<ref name="EpicProfile" />

== Typische Fehler ==

* '''Zu große Streuweite:''' Das Gesicht verliert Poren und Formen und wirkt wie Wachs.
* '''Falscher Maßstab:''' Ein in Zentimetern gedachtes Profil wird auf ein falsch skaliertes Mesh angewendet.
* '''Zu gesättigte Streufarbe:''' Haut wird unnatürlich rot oder Wachs leuchtet farbig statt Licht nur zu verteilen.
* '''SSS als Transparenzersatz:''' Subsurface-Materialien zeigen nicht automatisch klar erkennbare Objekte hinter der Oberfläche.
* '''Gleiche Stärke auf dem ganzen Modell:''' Zähne, Lippen, Ohren, Bart, Nägel und Hornschichten benötigen unterschiedliche Maskierung oder eigene Materialien.
* '''Nur Frontlicht beurteilt:''' Viele Probleme werden erst in Seiten- und Gegenlicht sichtbar.
* '''Diffuse Textur mit eingebranntem Licht:''' Schatten oder Glanz in der Base Color konkurrieren mit der dynamischen Beleuchtung und verfälschen das Profil.
* '''Fehlende Qualitätsprüfung:''' Screen-Space-SSS kann abhängig von Auflösung, Anti-Aliasing, Sichtbarkeit und Plattform anders wirken.

== Leistung und Grenzen ==

SSS ist teurer als gewöhnliches Default-Lit-Shading, weil zusätzliche Materialdaten gespeichert und Beleuchtung räumlich gefiltert oder separat ausgewertet werden muss. Die tatsächlichen Kosten hängen von Auflösung, Bildschirmfläche der SSS-Objekte, Qualitätsstufe, Plattform und Shading-Pfad ab.

Für die Optimierung helfen typischerweise:

* SSS nur auf Materialien verwenden, die sichtbar davon profitieren.
* Hochwertiges Subsurface Profile auf wichtige Figuren beschränken.
* Masken nutzen, statt die gesamte Oberfläche maximal streuen zu lassen.
* GPU-Profiler und verschiedene Zielauflösungen verwenden.
* Auf Zielhardware testen; Editor-Ansicht und finale Laufzeit können sich unterscheiden.

Screen-Space-Methoden besitzen prinzipbedingte Grenzen an Bildrändern und bei verdeckten Geometriedetails. Außerdem ersetzt SSS keine echte volumetrische Darstellung großer, durchsichtiger Körper. Für Glas, klare Flüssigkeiten oder tief einsehbare Medien sind Translucency-, Refraction- oder Volumenverfahren geeigneter.

== Bedeutung für realistisches Rendering ==

SSS liefert nicht einfach einen dekorativen „Glow“. Es verändert die räumliche Lichtantwort eines Materials und ist deshalb für organische oder mineralische Stoffe oft entscheidend. Besonders bei Haut sorgt die Mischung aus scharfer Oberflächenreflexion und weicher Streuung darunter dafür, dass Form, Feuchtigkeit und Gewebetiefe gleichzeitig erkennbar bleiben.

Für ein glaubwürdiges Ergebnis ist nicht die maximal sichtbare Wirkung das Ziel, sondern ein zum Materialmaßstab passender, meist subtiler Lichttransport. Gutes SSS fällt häufig erst dann deutlich auf, wenn es abgeschaltet wird.

== Siehe auch ==

* [[Unreal Engine 5]]
* [[Rendering Hardware Interface (RHI) in Unreal Engine 5]]
* [[Render Dependency Graph in Unreal Engine 5]]
* [[Shader Model 6 und Direct3D 12 in Unreal Engine 5]]

== Einzelnachweise ==

<references />

[[Kategorie:Computergrafik]]
[[Kategorie:Rendering]]
[[Kategorie:Unreal Engine 5]]
[[Kategorie:Materialien]]

UE5 Heterogeneous Multi-GPU

2026-09-05T14:53:56Z

Elaina: Projektstand 05.09.2026: asynchroner 128x96-Texture-Job, Pending/Ready und persistentes Target

{{Hinweis|Projektstand: 5. September 2026. 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.

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.

{| class="wikitable"
|+ Projektstatus
|-
! Engine / Plattform
| Unreal Engine 5.8 Source Build / Windows / Direct3D 12
|-
! Testsystem
| Lenovo LOQ 17IRX10
|-
! Primary
| NVIDIA GeForce RTX 5060 Laptop GPU
|-
! Worker
| Intel UHD Graphics
|-
! Git-Stand
| Commit <code>30202f7</code> auf Branch <code>mgpu-experimental</code>
|-
! Windows/D3D12-Proof-of-Concept
| Asynchroner 128×96-Worker-Texture-Job, GPU-Transfer, Pending/Ready-Ausgabe und persistente UE-Textur nachgewiesen
|-
! Gesamtvision
| etwa 30–35 % (Scheduler, echte Workloads, N-GPU und Vulkan noch offen)
|}

== Grundprinzip ==

<pre>
Intel Worker GPU
-> MainTextureCS
-> lokale Worker-Textur
-> Shared Cross-Adapter Buffer
-> Shared Fence / Queue Wait
-> UE-eigene FTextureRHIRef auf der Primary

RTX Primary GPU
-> normales UE5-Rendering
-> übernimmt und verwendet das Worker-Ergebnis
</pre>

Jeder Worker besitzt ein eigenes <code>ID3D12Device</code>, eigene Queues, Command Lists und Ressourcen. Ein späterer Scheduler soll Rechenleistung, Fähigkeiten, Transferkosten und gewünschte Aktualisierungsrate bewerten. Vorgesehene Aufgaben sind beispielsweise SceneCapture2D, Spiegel, CCTV, Minimap, Compute oder Niagara.

== Verifizierter Entwicklungsstand ==

=== Worker-Compute ===

Ein echter, von Unreal kompilierter Global Compute Shader läuft auf der Intel UHD, während Unreal regulär über die RTX rendert. Der Test verdoppelt 64 Ganzzahlen auf dem Worker; '''64 von 64 Ergebnissen wurden korrekt verifiziert'''. Damit ist echte GPU-Arbeit auf einem zweiten, herstellerfremden Device nachgewiesen.

Zusätzlich läuft <code>MainTextureCS</code> auf der Intel-GPU. Der synchrone Debugtest erzeugt eine 64 × 64 Pixel große RGBA8-Textur; '''alle 4096 shader-generierten Pixel wurden korrekt verifiziert'''. Der normale Runtime-Pfad verwendet inzwischen einen asynchronen 128×96-Test. Der Shader liest seine Dimensionen mit <code>GetDimensions()</code>, schützt überhängende Threads durch einen Bounds-Check und wird mit <code>Dispatch(16,12,1)</code> ausgeführt. Ein fester 64×64-Divisor ist damit aus dem produktiven Testpfad entfernt.

=== Cross-Adapter-Speicher und Synchronisation ===

* RTX und Intel öffnen denselben D3D12 Cross-Adapter Heap.
* Ein gemeinsamer Buffer wurde mit 64 Testwerten erfolgreich geprüft.
* Ein Shared Fence synchronisiert die Queues direkt von GPU zu GPU.
* Die CPU vermittelt die GPU-Abhängigkeit nicht; Worker- und Primary-Queue verwenden <code>Signal</code> und <code>Wait</code> direkt auf der GPU.
* Der separate Readback-Verifikationstest darf weiterhin blockieren. Der normale Runtime-Pfad wartet dagegen nicht auf GPU-Leerlauf.

=== Texturtransport ===

Direkte Cross-Adapter-Texturen sind auf dem Testsystem nicht beidseitig verfügbar: Die Intel UHD meldet Unterstützung für Row-Major Cross-Adapter Textures, die RTX 5060 Laptop GPU nicht. Deshalb verwendet das Projekt einen allgemeineren Buffer-Fallback.

<pre>
Intel MainTextureCS
-> Worker-Textur
-> CopyTextureRegion
-> Shared Cross-Adapter Buffer
-> Worker signalisiert Shared Fence 1
-> UE-Primary-Queue wartet auf Fence 1
-> direkte Kopie in UE-eigene FTextureRHIRef
-> Primary signalisiert Completion Fence 2
</pre>

Der robuste Normal-Pfad kopiert die Worker-Textur über den Shared Buffer direkt in eine von Unreal erzeugte <code>FTextureRHIRef</code>. Breite, Höhe und Row Pitch werden dynamisch aus Worker-Ressource und Transport-Metadaten übernommen. Der erfolgreiche 128×96-RGBA8-Test verwendet 512 Byte Row Pitch und 49.152 Byte Transfergröße. Das Ergebnis wird pro Worker in einer Output Registry veröffentlicht und kann über <code>GetNormalTextureOutputForWorker()</code> abgerufen werden.

=== Non-blocking Runtime-Pfad ===

Die produktive Testlogik ist aus dem Konsolenkommando in eine gekapselte NormalPath-API verschoben. <code>SubmitWorkerTextureComputeJob()</code> reicht den Worker-Dispatch ohne CPU-Wait ein. <code>QueueNormalTextureTransfer()</code> reiht Wait, Kopie und Completion-Signal in Unreals D3D12-Kontext ein. Der normale MainTextureCS-Pfad enthält weder CPU-Fence-Waits noch Readback, <code>Map</code> oder Pixelvergleich. Erst <code>TickNormalTextureTransfers()</code> prüft die Primary-Completion in <code>RHIEndFrame()</code> non-blocking.

Eine passende Primary-<code>FTextureRHIRef</code> wird pro Worker und Konfiguration persistent gehalten. Nach Fence 2 kann der nächste Job dieselbe Resource erneut verwenden; dabei führt Unreal die Übergänge <code>SRVMask -> CopyDest -> SRVMask</code> aus. Pending- und Ready-Zustand hängen von Inhaltsgeneration und Fence ab, nicht von der Pointer-Identität. Eine native D3D12-Resource wird weiterhin nicht blind als UE-Textur gewrappt, weil Unreals Resource-State-Buchhaltung den tatsächlichen nativen Zustand sonst nicht sicher kennt.

=== Lebensdauer und automatisches Cleanup ===

Da die CPU nicht blockierend wartet, hält der Normal-Pfad einen vollständigen In-Flight-Job: Worker-Textur, Root Signature, PSO, Descriptor Heap, Allocator, Command List, Worker-Fence, Cross-Adapter-Transport, Shared-Ressourcen und Primary-Textur bleiben bis zum sicheren Abschluss erhalten. Die Completion wird automatisch in <code>FD3D12DynamicRHI::RHIEndFrame()</code> geprüft:

<pre>
Worker-Fence vor dem Submit erzeugen
-> Dispatch und UAV->COPY_SOURCE auf Worker-Queue
-> Worker-Kopie in Shared Buffer
-> Fence 1: Shared Buffer fertig
-> Primary Wait, Copy und Signal Fence 2
-> Output ist Pending
-> RHIEndFrame prüft GetCompletedValue()
-> Fence 2 erreicht: aktuelle Generation wird Ready
-> Job sicher freigeben; persistentes Target bleibt erhalten
</pre>

Mehrere Jobs können lifetime-sicher gleichzeitig in flight sein. Im aktuellen Stand besitzt jeder Transport eine eigene Shared Fence sowie eigene Shared Heaps und Buffer; die Werte 1 und 2 sind daher transportlokal. Generationen verhindern, dass ein älterer Job einen neueren Pending- oder Ready-Output zurückrollt. Ein persistentes Target wird nicht erneut beschrieben, solange es noch in flight ist; dann wird vorläufig eine neue Textur erzeugt. Backpressure und ein echter Ressourcenpool fehlen noch.

== Aktueller nächster Schritt ==

Der nächste qualitative Schritt ist ein '''erster sichtbarer Consumer''': Das Worker-Ergebnis soll kontrolliert in einem UE-Material oder Compositing-Pfad erscheinen. Dabei muss insbesondere die Synchronisation stimmen, wenn dieselbe persistente Textur gelesen und später mit einer neuen Generation beschrieben wird. Danach folgen Backpressure, Ressourcenpooling, Messungen und echte Offload-Workloads.

== Historische Vorläufer ==

Die Grundidee heterogener Multi-GPU-Nutzung ist nicht neu. Bereits mit der Einführung von Direct3D 12 entstanden mehrere Versuche, integrierte und dedizierte GPUs gemeinsam zu verwenden. Eine allgemein einsetzbare Lösung für moderne UE5-Spiele hat sich daraus jedoch nicht entwickelt.

=== Microsoft und Epic: UE4 Elemental Demo (2015) ===

Microsoft zeigte eine angepasste Unreal-Engine-4-Version der Elemental-Demo, bei der eine NVIDIA-GPU und eine Intel-iGPU gemeinsam arbeiteten. Das erklärte Ziel war, ansonsten ungenutzte Grafikleistung in Hybrid-Systemen zu verwenden. Dieser Versuch ist der Grundidee des Projekts besonders ähnlich, blieb aber eine technische Demonstration.

=== Intel: D3D12 Multi-Adapter Sample (2015) ===

Intels Beispiel kombinierte eine GeForce 840M mit Intel HD Graphics 5500. Beide GPUs berechneten getrennte Teile einer einfach parallelisierbaren Raytracing-Szene. Cross-Adapter-Ressourcen und Shared Fences führten die Ergebnisse anschließend zusammen. Intel berichtete in diesem Test von nahezu halbierter Framezeit, warnte jedoch ausdrücklich davor, das Ergebnis unmittelbar auf reale Spiele zu übertragen.

=== Ashes of the Singularity ===

Die Nitrous Engine von ''Ashes of the Singularity'' setzte Direct3D-12-Explicit-Multiadapter in einem veröffentlichten Spiel ein. Dabei konnten auch unterschiedliche GPU-Modelle und Hersteller zusammenarbeiten. Das war ein wichtiger Praxisnachweis, blieb in der Spielebranche aber eine seltene Ausnahme.

=== Weitere verwandte Ansätze ===

* ''Rise of the Tomb Raider'' erhielt explizite Direct3D-12-Multi-GPU-Unterstützung, vor allem für klassische Kombinationen ähnlicher GPUs.
* NVIDIA VR SLI wies bei Virtual Reality jeder GPU ein Auge zu. Das verteilt unabhängige Ansichten, bleibt jedoch NVIDIA-spezifisch.
* Unreal nDisplay kann Viewports oder Frustums auf weitere GPUs beziehungsweise Prozesse auslagern und das fertige Bild zur Ausgabe-GPU zurückführen. Der Einsatzbereich ist hauptsächlich Virtual Production.
* Forschung und High-Performance Computing verwenden seit Jahren Scheduler für heterogene GPUs, allerdings überwiegend für Compute- und Datenverarbeitungsaufgaben statt für einen allgemeinen UE5-Echtzeitrenderer.

=== Abgrenzung dieses Projekts ===

Das Projekt erfindet Direct3D-12-Explicit-Multiadapter nicht neu. Sein eigener Ansatz liegt in der Kombination aus tiefer UE5.8-RHI-Integration, UE-kompilierten Shadern auf unabhängigen Worker-Devices, frei wählbaren Spiel- und Compute-Workloads, Capability- und Performance-Scheduler, mehreren Fallback-Pfaden sowie dem langfristigen Ziel beliebiger Hersteller und mehrerer Worker.

== Vergleich mit anderen Multi-GPU-Verfahren ==

{| class="wikitable"
! Verfahren
! Arbeitsweise
! Verhältnis zu diesem Projekt
|-
| SLI / CrossFire
| Treiber- beziehungsweise Verbundlösung für meist ähnliche GPUs; häufig wird die Bildarbeit verteilt.
| Dieses Projekt benötigt keinen herstellerspezifischen GPU-Verbund und weist Aufgaben ausdrücklich selbst zu.
|-
| AFR (Alternate Frame Rendering)
| GPU 1 rendert einen Frame, GPU 2 den nächsten.
| Das Projekt verteilt unabhängige Aufgaben statt aufeinanderfolgender Frames. Dadurch werden Frame-Abhängigkeiten und typisches AFR-Pacing vermieden.
|-
| SFR (Split Frame Rendering)
| Mehrere GPUs bearbeiten Bereiche desselben Frames.
| Erfordert enge Lastverteilung und viel Datenaustausch. Das Projekt bevorzugt vollständig abgrenzbare Workloads und überträgt deren Ergebnis.
|-
| Direct3D 12 Linked Multiadapter
| Mehrere vom Treiber verbundene GPUs erscheinen als Knoten eines logischen Adapters.
| Eignet sich eher für eng kompatible GPUs. Das Projekt verwendet unabhängige Devices (Unlinked/Explicit Multiadapter) und unterstützt dadurch heterogene Herstellerkombinationen.
|-
| Direct3D 12 Unlinked / Explicit Multiadapter
| Die Anwendung verwaltet getrennte Adapter, Ressourcen und Synchronisation selbst.
| Das ist die technische Familie des Projekts. Hinzu kommen die eigene UE5-RHI-Integration, Workload-Ziele, Fallbacks und der geplante Scheduler.
|-
| UE nDisplay mGPU / Multi-Process
| Separate GPUs rendern bestimmte Viewports oder Frustums, vor allem für Virtual Production; Ergebnisse werden zur Ausgabe-GPU kopiert.
| Ähnliche Idee der aufgabenweisen Trennung, aber für einen anderen Einsatzbereich. Dieses Projekt zielt auf allgemeine Spiel- und Compute-Workloads innerhalb der Engine.
|-
| Vulkan Device Groups
| Ähnliche physische GPUs können ein gemeinsames logisches Device bilden.
| Für beliebige heterogene GPUs meist ungeeignet, da Geräte einer Gruppe nahezu gleiche Eigenschaften besitzen müssen. Eine spätere Vulkan-Portierung benötigt daher wahrscheinlich getrennte Devices und External Memory/Semaphores.
|}

SLI und CrossFire bezeichnen den Verbund; AFR und SFR beschreiben mögliche Verteilungsmethoden innerhalb solcher Systeme. Sie sind deshalb nicht vollständig getrennte Kategorien.

== Vorteile der geplanten Variante ==

* '''Herstellerunabhängig:''' NVIDIA, AMD und Intel können grundsätzlich kombiniert werden.
* '''Vorhandene Hardware nutzen:''' Auch eine sonst wenig genutzte integrierte GPU kann geeignete Nebenaufgaben übernehmen.
* '''Aufgaben statt Frames verteilen:''' Spiegel, Minimap oder Compute können mit eigener Auflösung und Aktualisierungsrate laufen.
* '''Keine identischen GPUs erforderlich:''' Unterschiedliche Fähigkeiten können gezielt genutzt werden.
* '''Kontrollierter Datenaustausch:''' Nur das benötigte Ergebnis muss zurück zur Primary-GPU.
* '''Robuste Fallback-Idee:''' Wenn direkte Texturen nicht gemeinsam nutzbar sind, bleibt der Shared-Buffer-Pfad.
* '''Erweiterbar:''' Scheduler, manuelles Mapping und mehrere Worker sind als spätere Stufen vorgesehen.

== Nachteile und technische Risiken ==

* '''Hoher Entwicklungsaufwand:''' Geräte, Ressourcen, Zustände, Fences, Fehlerfälle und UE-Lebenszyklen müssen selbst verwaltet werden.
* '''Transfer kann den Gewinn aufzehren:''' Cross-Adapter Heaps liegen laut D3D12 nicht automatisch im schnellen lokalen VRAM. Bandbreite und Latenz müssen für jeden Workload gemessen werden.
* '''VRAM wird nicht einfach addiert:''' Benötigte Ressourcen können auf mehreren GPUs vorliegen und zusätzlichen Speicher verbrauchen.
* '''Langsame Worker können bremsen:''' Eine Aufgabe lohnt sich nur, wenn Rechengewinn größer als Übergabe-, Warte- und Kopierkosten ist.
* '''Nicht jeder Workload ist unabhängig:''' Hauptansicht, Lumen, Nanite und stark gekoppelte Renderpässe besitzen viele Abhängigkeiten und sind schwieriger auszulagern.
* '''Hardwareunterschiede:''' Formate, Shader-Funktionen, Queue-Fähigkeiten und Cross-Adapter-Support müssen pro GPU geprüft werden.
* '''Wartungsrisiko:''' Eingriffe in private D3D12RHI-Dateien können bei Engine-Updates angepasst werden müssen.
* '''Produktionsreife fehlt noch:''' Ressourcenpools, Timeouts, Device-Lost-Wiederherstellung, Scheduler und echte Szenentests sind offen.

== Wann die Variante sinnvoll ist ==

Am aussichtsreichsten sind Aufgaben mit viel eigener Rechenarbeit, einem relativ kleinen Endergebnis und wenigen Abhängigkeiten zur Hauptszene. Gute frühe Kandidaten sind unabhängige Compute-Aufgaben sowie Scene Captures, die nicht in jedem Frame aktualisiert werden müssen. Weniger geeignet sind winzige Aufgaben mit großem Transfer oder Renderpässe, die ständig auf Ressourcen der Primary-GPU zugreifen.

Die entscheidende Regel für den späteren Scheduler lautet daher:

<pre>
Worker-Gewinn > Vorbereitung + Datentransfer + Synchronisation + Rückintegration
</pre>

== Bekannte Grenzen des Proof of Concepts ==

* Der asynchrone 128×96-End-to-End-Pfad ist über Dimensionen, Dispatch, Transfer, Fences, Pending/Ready und Reuse verifiziert; ein eigener 128×96-Pixel-Readback fehlt noch. Der synchrone 64×64-Debugtest prüft weiterhin alle 4096 Pixel.
* Der Normal-Transport unterstützt derzeit <code>DXGI_FORMAT_R8G8B8A8_UNORM</code> mit Sample Count 1; weitere Formate, Mips, Arrays, Slices und MSAA sind offen.
* Shared Heaps, Buffer, Fences und Worker-Command-Objekte werden noch pro Job erzeugt. Backpressure, Pooling sowie Double-, Triple- oder Ring-Buffering fehlen.
* Raw-D3D12-Shared-Ressourcen sind noch nicht vollständig in Unreals Residency-Management eingebunden.
* Praktisch getestet ist Primary plus ein Worker. Die Architektur ist auf mehrere Worker ausgelegt, N-GPU ist aber noch nicht praktisch validiert.
* Ein sichtbarer Material-/Renderer-Consumer, echte UE-Szenen-Workloads, Benchmark-Wizard und Scheduler fehlen weiterhin.
* 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.

== Roadmap ==

# Worker-Ergebnis als ersten sichtbaren Consumer in Material, Compositing oder Render Graph einbinden.
# Consumer-Synchronisation für Updates derselben persistenten Textur absichern.
# Backpressure sowie Pools für Shared Heaps, Buffer, Fences und Command Objects einführen.
# Formate, Mips, Arrays/Slices und gegebenenfalls MSAA capability-basiert erweitern.
# Latenz, Bandbreite, Größen, Update-Raten und Synchronisationskosten messen.
# Ersten echten UE-Offload wie SceneCapture2D, CCTV, Spiegel, Minimap, Niagara oder unabhängigen Compute integrieren.
# Capability-Matrix, Benchmark-Wizard, Scheduler und manuelle Overrides entwickeln.
# Mehrere Worker-GPUs unterstützen.
# Fallback-Matrix aus Normal Shared Buffer, System-RAM/Staging und einem späteren Experimental Fast Path ergänzen.
# Linux/Vulkan mit getrennten Devices, External Memory und externer Synchronisation untersuchen.

== Quellen ==

* Interner Entwicklungsstand und verifizierte Testprotokolle vom 5. September 2026, Commit <code>30202f7</code>
* [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/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://www.intel.com/content/dam/develop/external/us/en/documents/multi-adapter-support-in-directx-12-594015.pdf Intel: Multi-Adapter Support in DirectX 12]
* [https://devblogs.microsoft.com/directx/ashes-of-the-singularity-makes-gaming-history-with-directx-12/ Microsoft: Ashes of the Singularity und heterogene Adapter]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/nvidia-sli-alternative-frame-rendering-in-unreal-engine Epic: NVIDIA SLI Alternate Frame Rendering]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/multi-process-rendering-with-unreal-engine Epic: Multi-Process Rendering]
* [https://registry.khronos.org/vulkan/specs/latest/pdf/vkspec.pdf Khronos: Vulkan Specification – Device Groups]

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Multi-GPU]]
[[Kategorie:Direct3D 12]]
[[Kategorie:Experimentell]]

DirectX 12 Multiadapter – UE4 Elemental Demo

2026-09-05T05:46:42Z

Elaina: Die Seite wurde neu angelegt: „{{Hinweis|Historische Technikdemonstration: Microsoft zeigte diesen Prototyp am 30. April 2015 auf der Entwicklerkonferenz Build 2015. Die Demonstration war kein allgemein aktivierbarer Unreal-Engine-Modus und keine serienreife Produktfunktion.}} Die '''DirectX-12-Multiadapter-Demonstration mit Unreal Engine 4''' war ein gemeinsamer Technikversuch von Microsoft und Epic Games aus dem Jahr 2015. Eine angepasste DirectX-12-Version der '''UE4 Elemental Demo…“

{{Hinweis|Historische Technikdemonstration: Microsoft zeigte diesen Prototyp am 30. April 2015 auf der Entwicklerkonferenz Build 2015. Die Demonstration war kein allgemein aktivierbarer Unreal-Engine-Modus und keine serienreife Produktfunktion.}}

Die '''DirectX-12-Multiadapter-Demonstration mit Unreal Engine 4''' war ein gemeinsamer Technikversuch von Microsoft und Epic Games aus dem Jahr 2015. Eine angepasste DirectX-12-Version der '''UE4 Elemental Demo''' nutzte gleichzeitig eine diskrete NVIDIA-Grafikkarte und eine integrierte Intel-GPU. Microsoft wollte damit zeigen, dass Direct3D 12 auch sehr unterschiedliche Grafikprozessoren desselben PCs gezielt zusammenarbeiten lassen kann.

Anders als bei klassischem NVIDIA SLI oder AMD CrossFire verteilte nicht der Grafikkartentreiber vollständige Frames auf ähnliche GPUs. Die Anwendung verwaltete beide Adapter ausdrücklich selbst und gab der schwächeren Intel-iGPU eine klar abgegrenzte Post-Processing-Aufgabe. Dadurch wurde die NVIDIA-GPU früher frei und konnte bereits mit dem nächsten Frame beginnen.

Im gezeigten Test stieg die durchschnittliche Bildrate von '''35,9 FPS auf 39,7 FPS'''. Das entspricht rund '''10,6 Prozent Mehrleistung'''. Der Prototyp war ein wichtiger Machbarkeitsnachweis für heterogene Multi-GPU-Systeme, entwickelte sich jedoch nicht zu einer allgemeinen Funktion von Unreal Engine 4 oder späteren Engine-Versionen.

== Hintergrund ==

Viele PCs und Notebooks besaßen 2015 gleichzeitig eine integrierte GPU im Prozessor und eine deutlich leistungsfähigere diskrete Grafikkarte. Beim Spielen arbeitete normalerweise nur die dGPU; die iGPU blieb weitgehend ungenutzt oder diente lediglich als Display-Ausgabe. Microsoft bezeichnete diese brachliegende Rechenleistung als '''dormant silicon'''.

Direct3D 11 konnte mehrere GPUs nur eingeschränkt und meist über herstellerspezifische Treiberlösungen verwenden. SLI und CrossFire erwarteten typischerweise ähnliche Grafikkarten desselben Herstellers. Wie Frames oder Bildbereiche verteilt wurden, bestimmte weitgehend der Treiber.

Direct3D 12 verlagerte mehr Verantwortung in die Anwendung. Mit '''Explicit Multiadapter''' konnte eine Engine:

* verfügbare Adapter selbst erkennen,
* für jede GPU eigene Geräte, Queues und Ressourcen verwalten,
* verschiedene Aufgaben passend zur Leistungsfähigkeit verteilen,
* Daten ausdrücklich zwischen Adaptern austauschen,
* die Ausführung mit Fences und Queue-Abhängigkeiten synchronisieren.

Damit wurde eine Kombination aus Intel-iGPU und NVIDIA-dGPU technisch möglich, obwohl beide Geräte unterschiedliche Leistung, Speicherbereiche und Treiber besaßen.

== Die UE4 Elemental Demo ==

'''Elemental''' ist eine von Epic Games entwickelte Echtzeitdemonstration für Unreal Engine 4. Die Szene zeigt eine große, aus Lava und Gestein bestehende Figur in einer aufwendig beleuchteten Umgebung. Epic hatte sie ursprünglich zur Präsentation der damaligen UE4-Renderingtechnik erstellt.

Microsoft verwendete eine angepasste DirectX-12-Fassung dieser Demo als realistische Testlast. Die beiden verglichenen Konfigurationen sollten jeweils genau '''635 Frames''' so schnell wie möglich rendern:

{| class="wikitable"
! Konfiguration
! Durchschnittliche Bildrate
! Ergebnis
|-
| NVIDIA-dGPU allein
| 35,9 FPS
| Ausgangswert
|-
| NVIDIA-dGPU + Intel-iGPU
| 39,7 FPS
| rund 10,6 % schneller
|}

Die genauen Modelle der NVIDIA- und Intel-GPU wurden in Microsofts veröffentlichtem Beitrag nicht genannt. Die Messung war deshalb kein allgemein übertragbarer Hardwarebenchmark, sondern ein Nachweis, dass eine zusätzliche, deutlich schwächere und herstellerfremde GPU einen realen Leistungsgewinn erzielen konnte.

== Aufteilung der Arbeit ==

Die Demo verteilte nicht die gesamte Szene oder abwechselnde Frames auf beide GPUs. Stattdessen wurde ein '''separierbarer Post-Processing-Abschnitt''' auf die Intel-iGPU ausgelagert.

Vereinfacht sah die Pipeline so aus:

<pre>
NVIDIA-dGPU
-> Hauptszene rendern
-> benötigte Bilddaten für den zweiten Adapter bereitstellen

Intel-iGPU
-> ausgelagertes Post-Processing ausführen
-> bearbeitetes Ergebnis zurückgeben

NVIDIA-dGPU
-> währenddessen früher mit dem nächsten Frame beginnen
-> Ergebnisse zusammenführen und ausgeben
</pre>

Der Gewinn entstand durch '''Überlappung''': Arbeit, die zuvor auf der NVIDIA-GPU lag, lief nun parallel auf der Intel-GPU. Die dGPU musste nicht bis zum Abschluss dieses Post-Processing-Schritts warten, bevor sie die nächste geeignete Aufgabe beginnen konnte.

Microsoft zeigte eine zeitlich maßstäbliche GPU-Timeline. Darin liefen Kopieroperationen auf einer eigenen Copy Engine der NVIDIA-GPU parallel zu Arbeit auf deren 3D-Engine. Der Prototyp kombinierte somit zwei Direct3D-12-Konzepte:

* '''Multiadapter:''' parallele Arbeit auf verschiedenen GPUs,
* '''Multiengine:''' parallele Nutzung verschiedener Engines beziehungsweise Queues innerhalb einer GPU.

== Ressourcenübertragung und Synchronisation ==

Unabhängige GPUs besitzen normalerweise getrennte Speicherbereiche. Eine Ressource im lokalen VRAM der NVIDIA-GPU kann nicht ohne Weiteres von der Intel-GPU gelesen werden. Die Anwendung muss deshalb einen ausdrücklich unterstützten Austauschpfad verwenden.

Direct3D 12 stellt dafür '''Cross-Adapter Shared Heaps''' und '''Cross-Adapter-Ressourcen''' bereit. Beide Geräte können einen gemeinsam freigegebenen Speicherbereich öffnen. Die CPU muss die Bilddaten dadurch nicht selbst lesen und erneut hochladen. GPU-Kopien, Resource Barriers und gemeinsam nutzbare Fences koordinieren Besitz, Sichtbarkeit und Ausführungsreihenfolge.

Ein typischer Ablauf besteht aus:

# Haupt-GPU rendert das benötigte Zwischenbild.
# Die Daten werden in eine Cross-Adapter-Ressource kopiert.
# Ein Fence signalisiert, dass die zweite GPU darauf zugreifen darf.
# Die Worker-GPU führt ihren Effekt aus.
# Das Ergebnis wird über einen geeigneten Austauschpuffer zurückgegeben.
# Die Ausgabe-GPU wartet nur dort, wo das Ergebnis tatsächlich benötigt wird.

Die 2015 veröffentlichte Beschreibung nennt nicht jede konkrete Ressource und jeden einzelnen API-Aufruf des internen UE4-Prototyps. Der Ablauf darf daher nicht mit Microsofts später veröffentlichtem, eigenständigem D3D12-Heterogeneous-Multiadapter-Sample gleichgesetzt werden. Beide beruhen aber auf derselben technischen Familie aus getrennten Adaptern, geteilten Ressourcen, GPU-Kopien und expliziter Synchronisation.

== Gemessene Auslastung ==

Microsoft veröffentlichte für den Test folgende durchschnittliche GPU-Auslastungen:

* '''NVIDIA-GPU:''' ungefähr 100 Prozent,
* '''Intel-GPU:''' ungefähr 70 Prozent.

Die dGPU blieb damit der vollständig ausgelastete Hauptprozessor. Die iGPU ersetzte sie nicht, sondern arbeitete als zusätzlicher Worker. Microsoft deutete die nur etwa 70-prozentige iGPU-Auslastung als Hinweis auf weiteres Optimierungspotenzial.

Eine höhere Auslastung hätte allerdings nicht automatisch proportional mehr Bildrate bedeutet. Der Nutzen wird durch Abhängigkeiten, Übertragungskosten, Synchronisation und die Frage begrenzt, ob weitere Aufgaben unabhängig genug für eine parallele Ausführung sind.

== Warum Post-Processing geeignet war ==

Post-Processing ist für einen frühen Multiadapter-Versuch vergleichsweise attraktiv:

* Der Arbeitsschritt besitzt einen klaren Anfang und ein klar definiertes Ergebnis.
* Er kann nach dem eigentlichen Szenenrendering ausgeführt werden.
* Viele Effekte arbeiten bildschirmraumbezogen und benötigen weniger komplexe Szenendaten.
* Das Ergebnis ist eine Textur beziehungsweise ein begrenzter Satz von Bildressourcen.
* Die Haupt-GPU kann parallel bereits Arbeit für den nächsten Frame vorbereiten.

Schlechter geeignet wären eng gekoppelte Renderpässe, die ständig auf große Mengen lokaler Geometrie-, Material-, Tiefen- und Beleuchtungsdaten der Haupt-GPU zugreifen. Werden zu viele Ressourcen übertragen, kann die Kommunikation den Rechengewinn vollständig aufzehren.

== Abgrenzung zu SLI und CrossFire ==

{| class="wikitable"
! Merkmal
! SLI / CrossFire
! DX12 Explicit Multiadapter der Demo
|-
| Steuerung
| überwiegend Treiber
| Anwendung beziehungsweise Engine
|-
| GPU-Kombination
| typischerweise ähnliche GPUs desselben Herstellers
| Intel-iGPU und NVIDIA-dGPU
|-
| Arbeitsverteilung
| häufig ganze Frames oder Bildbereiche
| gezielte Auslagerung eines Post-Processing-Workloads
|-
| Ressourcenverwaltung
| weitgehend durch Treiber abstrahiert
| getrennte Geräte und expliziter Datenaustausch
|-
| Entwicklungsaufwand
| geringerer Eingriff in die Engine
| deutlich höher; Engine muss alle Abhängigkeiten selbst verwalten
|}

Der Vorteil des expliziten Ansatzes ist die freie Aufgabenwahl. Sein Nachteil ist, dass die Engine Hardwareunterschiede, Speicher, Zustände, Fences, Fehlerpfade und Performanceentscheidungen selbst beherrschen muss.

== Warum daraus keine allgemeine UE4-Funktion wurde ==

Microsoft beschrieb die Demo ausdrücklich als frühen Prototyp und als Einladung an Entwickler, neue Möglichkeiten zu erforschen. Eine universelle Funktion entstand daraus nicht. Wesentliche Hürden waren:

* '''Hoher Integrationsaufwand:''' Jeder ausgelagerte Renderpass benötigt passende Ressourcen- und Synchronisationspfade.
* '''Stark unterschiedliche Hardware:''' Leistung, Speicherarchitektur, unterstützte Formate und Übertragungswege variieren zwischen Systemen.
* '''Transferkosten:''' Cross-Adapter-Ressourcen liegen nicht automatisch im schnellen lokalen VRAM der dGPU und können ungünstige Layouts erfordern.
* '''Begrenzte Parallelisierbarkeit:''' Viele moderne Renderpässe hängen eng voneinander und von Daten der Haupt-GPU ab.
* '''Schwierige Skalierung:''' Ein sinnvoller Scheduler muss pro System entscheiden, ob eine Auslagerung tatsächlich schneller ist.
* '''Test- und Wartungsaufwand:''' Kombinationen verschiedener Hersteller, Treiber und Leistungsstufen vervielfachen die Fehlerfälle.
* '''Andere Optimierungswege:''' Asynchronous Compute, leistungsfähigere Einzel-GPUs und später neue Rekonstruktionsverfahren boten oft ein besseres Verhältnis aus Aufwand und Nutzen.

Direct3D 12 behielt seine Multiadapter-Fähigkeiten. Einzelne Anwendungen wie ''Ashes of the Singularity'' bewiesen 2015 sogar die gemeinsame Nutzung von AMD- und NVIDIA-GPUs. In der breiten Spieleentwicklung blieb heterogenes Explicit Multiadapter dennoch eine Ausnahme.

== Bedeutung für UE5 Heterogeneous Multi-GPU ==

Microsofts Elemental-Demo ist ein direkter historischer Vorläufer des Projekts [[UE5 Heterogeneous Multi-GPU]]. Beide Ansätze verfolgen dieselbe Grundidee: Eine leistungsfähige GPU rendert die Hauptansicht, während ein anderer Adapter eine klar abgegrenzte Aufgabe übernimmt.

Die Projekte unterscheiden sich jedoch im Ziel und Entwicklungsstand:

{| class="wikitable"
! Punkt
! Microsoft/Epic 2015
! UE5 Heterogeneous Multi-GPU
|-
| Engine
| angepasste Unreal Engine 4
| Unreal Engine 5.8 Source Build
|-
| Gezeigte Aufgabe
| Post-Processing
| zunächst Compute- und Texturtransport-Proofs; später frei wählbare Worker-Aufgaben
|-
| Hardwarebeispiel
| nicht benannte NVIDIA-dGPU + Intel-iGPU
| RTX 5060 Laptop GPU + Intel UHD
|-
| Hauptziel
| DX12-Fähigkeit und messbaren FPS-Gewinn demonstrieren
| allgemeine UE5-RHI-Integration, Scheduler, Fallbacks und mehrere Workload-Typen
|-
| Veröffentlichung
| Technikdemo, kein allgemeines UE4-Feature
| experimentelles Entwicklungsprojekt
|}

Die wichtigste Lehre aus dem Versuch von 2015 bleibt aktuell: Eine zweite GPU ist nur dann nützlich, wenn der Rechengewinn größer ist als Vorbereitung, Datentransfer, Synchronisation und Rückintegration.

<pre>
Nutzen des Worker-Workloads
> Übertragung + Synchronisation + Integrationskosten
</pre>

== Fazit ==

Die UE4-Elemental-Multiadapter-Demo zeigte 2015 glaubhaft, dass eine Intel-iGPU und eine NVIDIA-dGPU gemeinsam an aufeinanderfolgenden Bildern arbeiten können. Durch das Auslagern von Post-Processing stieg die Bildrate im konkreten Prototyp um gut zehn Prozent. Das war weder SLI noch CrossFire und auch kein automatisches Zusammenlegen zweier Grafikkarten. Es war ein ausdrücklich programmierter, workload-basierter Multi-GPU-Pfad.

Technisch war der Versuch erfolgreich. Als allgemeines Produktmodell scheiterte er am hohen Engine-Aufwand, an Hardwareunterschieden und an den Kosten des Datenaustauschs. Gerade deshalb ist er für heutige heterogene Multi-GPU-Experimente wertvoll: Er zeigt sowohl das mögliche Leistungsplus als auch die Notwendigkeit, kleine, unabhängige und transferarme Aufgaben auszuwählen.

== Quellen ==

* [https://devblogs.microsoft.com/directx/directx-12-multiadapter-lighting-up-dormant-silicon-and-making-it-work-for-you/ Microsoft DirectX Developer Blog: DirectX 12 Multiadapter – UE4 Elemental Demo, Messwerte, Auslastung und Ablauf]
* [https://devblogs.microsoft.com/directx/ashes-of-the-singularity-makes-gaming-history-with-directx-12/ Microsoft DirectX Developer Blog: früher Prototyp, Leistungsplus über zehn Prozent und späterer Spieleinsatz]
* [https://learn.microsoft.com/en-us/windows/win32/direct3d12/multi-engine Microsoft Learn: Direct3D 12 Multi-adapter systems]
* [https://learn.microsoft.com/en-us/windows/win32/direct3d12/shared-heaps Microsoft Learn: Cross-Adapter Shared Heaps, Ressourcen und Einschränkungen]
* [https://learn.microsoft.com/en-us/samples/microsoft/directx-graphics-samples/d3d12-heterogeneous-multiadapter-sample-win32/ Microsoft: D3D12 Heterogeneous Multiadapter Sample]
* [https://github.com/microsoft/DirectX-Graphics-Samples Microsoft: DirectX Graphics Samples]
* [https://www.pcgameshardware.de/DirectX-Software-255525/News/Windows-10-iGPU-und-Grafikarte-arbeiten-an-einem-Frame-1157931/ PC Games Hardware: dokumentierte Benchmarkwerte 35,9 und 39,7 FPS]

[[Kategorie:Unreal Engine 4]]
[[Kategorie:Multi-GPU]]
[[Kategorie:Direct3D 12]]
[[Kategorie:Microsoft]]
[[Kategorie:Experimentell]]

Microsoft Talisman

2026-09-05T05:38:42Z

Elaina: Die Seite wurde neu angelegt: „{{Hinweis|Historisches Projekt: Microsoft Talisman wurde 1996 öffentlich vorgestellt, erreichte jedoch nie den Markt. Der Begriff „Hybrid“ bezeichnet hier die Verbindung aus klassischer 3D-Berechnung, wiederverwendeten 2D-Bildebenen und Multimedia-Verarbeitung – nicht ein heutiges Notebook-System aus iGPU und dGPU.}} '''Microsoft Talisman''' war der Codename einer experimentellen 3D-Grafik- und Multimedia-Architektur von Microsoft Research aus der…“

{{Hinweis|Historisches Projekt: Microsoft Talisman wurde 1996 öffentlich vorgestellt, erreichte jedoch nie den Markt. Der Begriff „Hybrid“ bezeichnet hier die Verbindung aus klassischer 3D-Berechnung, wiederverwendeten 2D-Bildebenen und Multimedia-Verarbeitung – nicht ein heutiges Notebook-System aus iGPU und dGPU.}}

'''Microsoft Talisman''' war der Codename einer experimentellen 3D-Grafik- und Multimedia-Architektur von Microsoft Research aus der Mitte der 1990er-Jahre. Microsoft wollte hochwertige Echtzeitgrafik auf bezahlbaren PCs ermöglichen, obwohl damalige Prozessoren, Grafikspeicher und Speicherbusse für komplexe 3D-Szenen noch sehr begrenzt waren.

Talisman sollte dieses Problem nicht allein mit mehr Rechenleistung lösen. Statt eine vollständige Szene in jedem Bild neu zu rendern, zerlegte das System sie in unabhängig aktualisierbare '''Bildebenen''' – vergleichbar mit Sprites oder Folien. Bereits berechnete Objektbilder konnten über mehrere Frames gespeichert, verschoben, skaliert, gedreht, verzerrt und anschließend wieder zur fertigen Szene zusammengesetzt werden. Nur sichtbar veränderte Inhalte mussten erneut als echte 3D-Geometrie gerendert werden.

Damit war Talisman ein ungewöhnlicher Hybrid aus 3D-Rendering, bildbasierter Darstellung, 2D-Compositing und programmierbarer Medienverarbeitung. Das Projekt beeinflusste Forschung und Diskussionen über bandbreiteneffiziente Grafik, setzte sich gegen die schnell besser werdenden konventionellen 3D-Beschleuniger jedoch nicht durch.

== Ausgangslage und Ziel ==

Mitte der 1990er-Jahre waren Echtzeit-3D-Grafik und Multimedia auf dem PC teuer. Ein konventioneller Renderer musste Geometrie transformieren, Polygone rasterisieren, Texturen lesen, Tiefentests ausführen und ein vollständiges Framebuffer-Bild schreiben. Speicherbandbreite war knapp, dedizierter Grafikspeicher teuer und viele Arbeitsschritte lagen noch auf der CPU.

Microsofts Ziel war deshalb eine Grafiklösung im Bereich von ungefähr '''200 bis 300 US-Dollar''', deren wahrgenommene Bildqualität und Komplexität an damalige 3D-Workstations heranreichen sollte. Die Architektur sollte außerdem nicht nur Spiele beschleunigen, sondern mehrere zuvor getrennte PC-Komponenten zusammenführen: 2D- und 3D-Grafik, Audio, MPEG-Wiedergabe, Videokonferenzen und sogar Modemfunktionen.

Die grundlegende Idee lautete:

<pre>
3D-Objekte nur bei Bedarf neu rendern
↓
Objektbilder als komprimierte Ebenen speichern
↓
Ebenen pro Bild günstig transformieren
↓
Ebenen mit Transparenz zum Ausgabebild zusammensetzen
</pre>

Talisman nutzte damit sowohl '''räumliche Kohärenz''' – benachbarte Bildbereiche ähneln sich – als auch '''zeitliche Kohärenz''' – viele Inhalte verändern sich zwischen zwei Frames nur wenig.

== Das Ebenenprinzip ==

Bei Talisman wurde ein bewegliches Objekt zunächst aus Polygonen in eine eigene zweidimensionale Bildebene gerendert. Zu dieser Ebene gehörten Farb-, Transparenz- und Tiefeninformationen. Solange sich Form, Beleuchtung oder Blickwinkel nicht zu stark änderten, konnte das gespeicherte Bild weiterverwendet werden.

Der Image Layer Compositor setzte die Ebenen mit hoher Rate zum sichtbaren Bild zusammen. Eine affine Transformation erlaubte dabei:

* Verschieben,
* Skalieren,
* Rotation innerhalb der Bildebene,
* Spiegeln und Scheren,
* Filtern und Alpha-Compositing.

Eine solche Transformation kann bestimmte Bewegungen überzeugend vortäuschen, ohne alle Polygone erneut zu berechnen. Dreht sich ein dreidimensionales Objekt stark, werden zuvor verdeckte Flächen sichtbar oder verändert sich seine Beleuchtung, muss seine Ebene dagegen neu gerendert werden.

Microsofts Forschungsarbeiten ergänzten das Konzept um Qualitätsmaße, sogenannte '''Fiducials'''. Sie sollten abschätzen, wann eine wiederverwendete Ebene sichtbar vom korrekten Ergebnis abweicht. Auf dieser Grundlage konnten Aktualisierungsrate, Auflösung und andere Qualitätsparameter je Ebene angepasst werden. Wichtige Objekte ließen sich häufiger oder höher aufgelöst aktualisieren als kleine Hintergrundelements.

== Chunking, Kompression und Mehrfachdurchläufe ==

Talisman verarbeitete Ebenen nicht nur als große rechteckige Bilder. Sie wurden in kleinere Bereiche oder '''Chunks''' zerlegt. Dadurch musste das System nur jene Teile lesen und bearbeiten, die für den aktuellen Bildausschnitt tatsächlich benötigt wurden.

Bild- und Texturdaten sollten breit komprimiert werden, um Speicherbedarf und Bandbreite zu senken. Die geplante Hardware konnte diese Daten während der Ausgabe wieder entpacken. Das war entscheidend, weil Talisman zwischen gespeicherten Ebenen, Texturen und dem Compositor große Datenmengen bewegen musste.

Außerdem setzte die Architektur auf '''Multi-Pass-Rendering'''. Komplexe Material- und Beleuchtungseffekte konnten in mehreren Durchläufen berechnet und anschließend kombiniert werden. Dieser Ansatz war für die damalige PC-Hardware ungewöhnlich ambitioniert, erhöhte allerdings auch die Anforderungen an Software, Speicherverwaltung und Synchronisation.

== Geplante Referenzhardware ==

Microsoft entwickelte Talisman als Architektur und Referenzentwurf, nicht als eigene serienreife Microsoft-Grafikkarte. Mehrere Halbleiterhersteller sollten Komponenten oder kompatible Umsetzungen liefern.

Eine frühe Referenzimplementierung war als PCI-Erweiterungskarte vorgesehen. Dokumentiert sind unter anderem:

* ein '''Media Signal Processor''' von Samsung mit einem ARM-RISC-Kern und einem programmierbaren Vektor-Coprozessor,
* spezialisierte Logik für Polygon- beziehungsweise Bildverarbeitung,
* ein '''Image Layer Compositor''' für Transformation, Filterung und Zusammensetzen der Ebenen,
* lokaler Speicher für Grafik- und Mediendaten,
* ein kleines Betriebssystem auf der Karte, das Module und Treiber vom Windows-PC laden konnte.

Der ARM-Kern übernahm Steuerungs- und Betriebssystemaufgaben. Der SIMD-artige Vektorprozessor war für rechenintensive Medienoperationen vorgesehen. Microsoft Research untersuchte sogar ein asymmetrisches Scheduling: Der ARM-Kern konnte normal präemptiv zwischen Threads wechseln, während der große Zustand des Vektorprozessors nur an vorbereiteten Kontrollpunkten gewechselt wurde.

Die geplante Karte war daher mehr als ein reiner 3D-Beschleuniger. In heutiger Sprache ähnelte sie teilweise einer Mischung aus GPU, programmierbarem Medienprozessor, Audio-DSP und eigenständigem Subsystem.

== Software und DirectX ==

Talisman benötigte eine enge Zusammenarbeit zwischen Anwendung, Grafiktreiber und Hardware. Eine Engine musste Objekte sinnvoll in Ebenen zerlegen, deren Gültigkeit bewerten und entscheiden, wann echtes Neurendern erforderlich war. Ohne diese Informationen konnte die Hardware ihren wichtigsten Vorteil – die Wiederverwendung bereits berechneter Bilder – nur eingeschränkt ausspielen.

Microsoft wollte Talisman-Funktionen über seine Windows-Grafikschnittstellen zugänglich machen und verband dabei Ideen aus DirectDraw und Direct3D. Für bestehende Spiele blieb jedoch ein Kompatibilitätspfad nötig. Wenn eine Anwendung nur eine gewöhnliche unmittelbare 3D-Pipeline erwartete, konnte sie die spezielle Layer-Architektur nicht automatisch optimal nutzen.

Genau darin lag ein strategisches Problem: Talisman versprach den größten Gewinn bei speziell angepassten Anwendungen, während Entwickler gleichzeitig bereits Direct3D, OpenGL und herstellerspezifische APIs bedienen mussten.

== Demonstration „Chicken Crossing“ ==

Auf der SIGGRAPH 1996 zeigte Microsoft den animierten Kurzfilm '''Chicken Crossing'''. Er demonstrierte Talisman-Techniken in einer für damalige PCs aufwendigen Szene und sollte zeigen, dass die Kombination aus Ebenen, Wiederverwendung und Compositing workstationähnliche Darstellung zu deutlich geringeren Kosten ermöglichen könnte.

Die Vorführung belegte, dass das Grundprinzip funktionierte. Sie war jedoch kein Nachweis für eine allgemein verfügbare Grafikkarte oder dafür, dass beliebige Spiele ohne Anpassung gleich gut profitiert hätten.

== Warum Talisman scheiterte ==

Talisman wurde nie als Endkundenprodukt veröffentlicht. Dafür kamen mehrere technische und wirtschaftliche Gründe zusammen:

* '''Der Markt entwickelte sich schneller als erwartet:''' 3dfx, NVIDIA, ATI, S3 und weitere Anbieter steigerten Rasterleistung und Speicherbandbreite konventioneller 3D-Beschleuniger sehr schnell.
* '''Spezialbehandlung in Anwendungen:''' Die besten Ergebnisse erforderten eine bewusste Zerlegung der Szene in wiederverwendbare Ebenen.
* '''Begrenzte Wiederverwendbarkeit:''' Starke Perspektivänderungen, Verdeckungen, dynamische Beleuchtung, Schatten und komplexe Überschneidungen konnten ein Neurendern erzwingen oder sichtbare Näherungsfehler erzeugen.
* '''Komplexe Gesamtarchitektur:''' Programmierbarer Medienprozessor, Spezialchips, Kompression, eigenes Scheduling und neue Softwarepfade mussten gemeinsam zuverlässig funktionieren.
* '''Schwieriger Kompatibilitätspfad:''' Ein gewöhnliches Direct3D-Spiel konnte auf Talisman laufen, nutzte die besonderen Fähigkeiten aber nicht automatisch vollständig aus.
* '''Sinkende Preise klassischer GPUs:''' Als entsprechende Referenzdesigns produktionsnah wurden, boten konventionelle Beschleuniger eine einfachere und zunehmend günstigere Lösung.

Das Scheitern bedeutet daher nicht, dass die technischen Ideen wirkungslos waren. Vielmehr verlor eine stark spezialisierte Architektur ihr wirtschaftliches Zeitfenster, bevor Hardware, Werkzeuge und ein breites Software-Ökosystem gleichzeitig bereitstanden.

== Abgrenzung zu heutigen Hybrid-Grafiksystemen ==

Talisman darf nicht mit modernen '''Hybrid-GPU-Systemen''' wie NVIDIA Optimus oder einer Windows-Konfiguration aus integrierter und diskreter GPU verwechselt werden. Dort rendern zwei weitgehend vollständige Grafikprozessoren je nach Leistungs- oder Energiebedarf; häufig erzeugt die dGPU ein Bild, das über die iGPU ausgegeben wird.

Talisman kombinierte dagegen verschiedene Arten der Bildberechnung innerhalb einer neuen Architektur:

{| class="wikitable"
! System
! Grundidee
! Ziel
|-
| Microsoft Talisman
| 3D-Objekte in wiederverwendbare 2D-Bildebenen rendern und per Compositor zusammensetzen
| Rechen- und Speicheraufwand hochwertiger Grafik senken
|-
| Modernes iGPU/dGPU-Hybridsystem
| Zwischen vollständigen GPUs umschalten oder das fertige Bild zwischen ihnen übertragen
| Akkulaufzeit und Leistung ausbalancieren
|-
| Direct3D-12-Explicit-Multiadapter
| Eine Anwendung verteilt eigene Aufgaben auf mehrere unabhängige GPUs
| Mehrere vorhandene Adapter parallel nutzen
|}

== Bedeutung aus heutiger Sicht ==

Talisman war keine Vorstufe moderner GPUs im geradlinigen Sinn. Heutige Grafikprozessoren folgen weiterhin überwiegend einer konventionellen, massiv parallelen Raster- und Compute-Architektur. Mehrere Talisman-Gedanken wirken aus heutiger Sicht dennoch erstaunlich vertraut:

* temporale Wiederverwendung statt vollständiger Neuberechnung,
* unterschiedliche Aktualisierungsraten für Bildbestandteile,
* Rekonstruktion und Transformation bereits gerenderter Informationen,
* Kachelung und Verarbeitung kleiner Bildbereiche,
* Kompression zur Verringerung von Speicherbandbreite,
* Trennung von 3D-Rendering und späterem Compositing,
* programmierbare Prozessoren für Grafik-, Audio- und Videoaufgaben.

Moderne temporale Upscaler, Frame Generation, reprojizierte VR-Bilder, variable Shading-Raten und komprimierte Renderziele sind keine direkten Talisman-Nachfolger. Sie beruhen jedoch auf einem ähnlichen Grundgedanken: Ein glaubwürdiges neues Bild muss nicht in jedem Teil vollständig von Grund auf neu berechnet werden.

== Fazit ==

Microsoft Talisman war der Versuch, die Grenzen damaliger PC-Hardware mit einer radikal anderen Aufteilung der Grafikarbeit zu umgehen. Echte 3D-Berechnung erzeugte Objektbilder; ein schneller 2D-Compositor verwandelte und kombinierte sie über mehrere Frames hinweg. Ergänzt um Kompression und programmierbare Multimedia-Verarbeitung sollte daraus eine günstige Allzweckkarte für Grafik, Ton und Video entstehen.

Technisch war das Konzept vorausschauend, praktisch aber zu spezialisiert und vom schnellen Fortschritt klassischer 3D-Grafikkarten überholt. Talisman blieb deshalb ein Forschungs- und Referenzprojekt – ein faszinierender Seitenweg der GPU-Geschichte, dessen zentrale Idee der zeitlichen Wiederverwendung heute aktueller wirkt als in den 1990er-Jahren.

== Quellen ==

* [https://www.microsoft.com/en-us/research/publication/talisman-commodity-realtime-3d-graphics-for-the-pc/ Microsoft Research: Jay Torborg und Jim Kajiya – Talisman: Commodity Realtime 3D Graphics for the PC (1996)]
* [https://news.microsoft.com/source/1996/08/06/microsoft-research-displays-latest-innovations-at-siggraph-96/ Microsoft: Vorstellung von Talisman und „Chicken Crossing“ auf der SIGGRAPH 1996]
* [https://www.microsoft.com/en-us/research/people/johnsny/other-research/ Microsoft Research: Rendering with Coherent Layers und verwandte Arbeiten]
* [https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-98-09.pdf Microsoft Research: Asymmetric Real Time Scheduling on a Multimedia Processor – Referenzhardware, MSP und Scheduling]
* [https://history.siggraph.org/wp-content/uploads/2022/11/SIGGRAPH-1997-Visual-Proceedings.pdf SIGGRAPH 1997 Visual Proceedings: Delivering High Quality 3D to Every Desk]
* [https://www.electronicdesign.com/technologies/embedded/article/21131674/jon-peddie-research-microsofts-talisman-the-graphics-chip-that-never-was Electronic Design / Jon Peddie Research: Microsoft’s Talisman – The Graphics Chip That Never Was]

[[Kategorie:Grafik]]
[[Kategorie:Microsoft]]
[[Kategorie:Hardware]]
[[Kategorie:Historische Technik]]
[[Kategorie:Experimentell]]

XeSS Intel Xe Super Sampling

2026-09-05T00:18:26Z

Elaina:

{{Hinweis|Stand: 5. September 2026. Aktuell ist das XeSS 3 SDK 3.0.2. Das offizielle Unreal-Engine-Plugin 3.1.0 unterstützt Unreal Engine bis Version 5.8; bei UE 5.8.0 und 5.8.1 besteht eine bekannte Einschränkung für Xe Low Latency.}}

'''Intel Xe Super Sampling''' ('''XeSS''') ist eine Familie KI-gestützter Grafikverfahren für Spiele. XeSS kann ein intern niedriger aufgelöstes Bild rekonstruieren, zusätzliche Zwischenbilder erzeugen und die Eingabelatenz begrenzen. Die einzelnen Funktionen heißen '''XeSS Super Resolution''' (XeSS-SR), '''XeSS Frame Generation''' (XeSS-FG) und '''Xe Low Latency''' (XeLL).

XeSS wurde zusammen mit Intel Arc eingeführt, ist aber nicht grundsätzlich auf Intel-GPUs beschränkt. Für kompatible Grafikkarten anderer Hersteller existieren herstellerübergreifende Ausführungspfade. Funktionsumfang und Leistung unterscheiden sich jedoch je nach GPU und Grafikschnittstelle.

== Die Bestandteile von XeSS 3 ==

* '''XeSS Super Resolution (XeSS-SR):''' rekonstruiert aus einem niedriger aufgelösten, zeitlich versetzten Eingabebild ein höher aufgelöstes und geglättetes Ausgabebild.
* '''XeSS Frame Generation (XeSS-FG):''' berechnet zusätzliche Zwischenbilder zwischen regulär gerenderten Frames.
* '''Xe Low Latency (XeLL):''' steuert das CPU-Timing anhand von Markierungen aus der Engine, um die Eingabe-zu-Anzeige-Latenz zu verringern. XeSS-FG setzt eine XeLL-Integration voraus.

Die drei Komponenten können passend zum Spiel kombiniert werden. Super Resolution und XeLL lassen sich auch ohne Frame Generation verwenden. Die Bezeichnung '''XeSS 3''' steht für das gemeinsame Paket dieser Technologien einschließlich Multi Frame Generation.

== Entwicklung der XeSS-Versionen ==

* '''XeSS 1.0:''' erste Version von XeSS-SR mit einem für Intel XMX optimierten Pfad und einer herstellerübergreifenden DP4a-Variante.
* '''XeSS 1.1 und 1.2:''' Verbesserungen an zeitlicher Stabilität, automatischer Belichtung, Leistung und Fehlerbehandlung.
* '''XeSS 1.3:''' neue Modelle und Qualitätsmodi. Hinzu kamen Native Anti-Aliasing, Ultra Quality Plus und Ultra Performance; außerdem änderten sich mehrere Skalierungsfaktoren.
* '''XeSS 2:''' ergänzte XeSS-FG und XeLL. Spätere 2.x-Versionen erweiterten Frame Generation auf kompatible Nicht-Intel-GPUs und fügten XeSS-SR-Unterstützung für Vulkan sowie auf Intel Arc für DirectX 11 hinzu.
* '''XeSS 3:''' führte Multi Frame Generation mit zwei oder drei erzeugten Zwischenbildern auf unterstützter Intel-Arc-Hardware ein. Verbesserte Frame-Generation-Modelle sollen außerdem die Darstellung von Benutzeroberflächen stabilisieren.
* '''XeSS 3.0.2:''' aktueller SDK-Stand. Diese Wartungsversion aktualisiert XeLL, behebt unter anderem einen Speicherverlust auf Nicht-Intel-GPUs und verbessert die Zusammenarbeit mit Streamline-Proxys.

== Super Resolution ==

XeSS-SR ist ein temporales Upscaling- und Anti-Aliasing-Verfahren. Es wird als Folge von Compute-Shader-Durchläufen vor späteren Post-Processing-Schritten ausgeführt. Typische Eingaben sind:

* ein niedrig aufgelöstes Farbbild,
* Bewegungsvektoren von Kamera und Objekten,
* ein Tiefenpuffer,
* Kamerajitter,
* Belichtungsinformationen,
* optional eine Responsive Mask für schwer rekonstruierbare Bereiche.

Aus diesen Daten rekonstruiert XeSS-SR ein Bild in der Zielauflösung. Fehlerhafte Bewegungsvektoren, falsche Jitter-Skalierung, ungeeignete Masken oder unpassende Farbräume können Ghosting, Flimmern, Schlieren und Detailverlust verursachen. Die Qualität hängt deshalb stark von der Integration im jeweiligen Spiel ab.

Auf Intel Arc und Intel Iris Xe kann eine für Intel-Hardware optimierte Implementierung verwendet werden. Der herstellerübergreifende HLSL-Pfad setzt Shader Model 6.4 voraus; DP4a oder eine gleichwertige Beschleunigung wird empfohlen.

== Qualitätsmodi von XeSS-SR ==

{| class="wikitable"
! Modus
! Skalierungsfaktor pro Bilddimension
! Beispiel für 4K-Ausgabe
|-
| Native Anti-Aliasing
| 1,0×
| 3840 × 2160
|-
| Ultra Quality Plus
| 1,3×
| ungefähr 2954 × 1662
|-
| Ultra Quality
| 1,5×
| 2560 × 1440
|-
| Quality
| 1,7×
| ungefähr 2259 × 1271
|-
| Balanced
| 2,0×
| 1920 × 1080
|-
| Performance
| 2,3×
| ungefähr 1670 × 939
|-
| Ultra Performance
| 3,0×
| 1280 × 720
|}

Ein größerer Faktor bedeutet eine niedrigere interne Renderauflösung und normalerweise mehr Leistung. Gleichzeitig stehen dem Rekonstruktionsverfahren weniger Ausgangsinformationen zur Verfügung. Native Anti-Aliasing arbeitet dagegen bei nativer Auflösung und nutzt XeSS nur zur Kantenglättung und zeitlichen Stabilisierung.

== Frame Generation und Multi Frame Generation ==

XeSS-FG interpoliert zusätzliche Bilder zwischen zwei regulär gerenderten Frames. Dafür verwendet es unter anderem Bewegungsinformationen, Tiefendaten und Bilddaten aus der Engine. Eine Proxy-Swapchain übernimmt die zusätzlichen Present-Aufrufe und das Frame Pacing.

XeSS 3 unterstützt auf geeigneter Intel-Arc-Hardware folgende Multiplikatoren:

* '''2×:''' ein regulär gerenderter und ein erzeugter Frame,
* '''3×:''' ein regulär gerenderter und zwei erzeugte Frames,
* '''4×:''' ein regulär gerenderter und drei erzeugte Frames.

Auf kompatiblen Nicht-Intel-GPUs ist höchstens ein erzeugtes Zwischenbild vorgesehen. Die Funktion steigert die angezeigte Bildrate, verkürzt aber nicht automatisch die Renderzeit eines echten Frames. Für eine gute Reaktionsfähigkeit ist deshalb XeLL vorgeschrieben. Intel empfiehlt mindestens ungefähr 40 regulär gerenderte FPS als Eingang und etwa 60 FPS für das beste Latenz- und Bewegungsgefühl.

Benutzeroberflächen benötigen besondere Behandlung: Idealerweise liefert die Engine ein Bild ohne HUD und eine separate UI-Textur. Andernfalls können Schrift, Fadenkreuz oder halbtransparente Elemente in erzeugten Frames flimmern oder verzerrt erscheinen.

== Xe Low Latency ==

XeLL verringert Warteschlangen zwischen CPU und GPU. Die Engine markiert wichtige Zeitpunkte eines Frames; XeLL berechnet daraus, wann die CPU mit dem nächsten Frame beginnen sollte. Dadurch soll nicht unnötig früh gerendert und zusätzliche Eingabelatenz aufgebaut werden.

XeLL kann auf unterstützter Intel-Hardware eigenständig eingesetzt werden. Auf Nicht-Intel-GPUs wird es im XeSS-SDK im Zusammenhang mit XeSS-FG verwendet. Andere Latenzlösungen sollen laut Intel nicht gleichzeitig mit XeSS-FG verwendet werden, weil unerwartetes Verhalten möglich ist.

== Hardware- und API-Kompatibilität ==

{| class="wikitable"
! Funktion
! Intel-Hardware
! Andere Hersteller
! Schnittstellen
|-
| XeSS-SR
| Intel Arc A/B, integrierte Arc-Grafik und unterstützte Iris-Xe-GPUs; optimierter Intel-Pfad
| GPUs mit Shader Model 6.4 und geeignetem DP4a- oder vergleichbarem Pfad
| DirectX 12; Vulkan; DirectX 11 auf Intel Arc
|-
| XeSS-FG
| diskrete und integrierte Intel-Arc-Grafik; auf geeigneter Hardware bis zu drei erzeugte Frames
| GPUs mit Shader Model 6.4; höchstens ein erzeugter Frame
| DirectX 12
|-
| XeLL
| unterstützte Intel Arc und Core-Ultra-Plattformen
| zusammen mit XeSS-FG auf kompatibler Hardware
| DirectX 12 im aktuellen FG-Pfad
|}

Die genaue Unterstützung hängt zusätzlich von Treiber, SDK-Version, Spielintegration und Betriebssystem ab. Für XeSS-FG nennt Intel Windows 10 oder 11, DirectX 12, eine aktuelle Laufzeitbibliothek und auf Intel-GPUs einen ausreichend neuen Grafiktreiber.

== Unreal Engine 5 ==

Intel stellt ein offizielles XeSS-Plugin für Unreal Engine bereit. Das Plugin '''3.1.0''' basiert auf dem XeSS SDK 3.0.2 und integriert:

* XeSS-SR,
* XeSS-FG einschließlich Multi Frame Generation,
* XeLL,
* Konsolenbefehle sowie Blueprint- und C++-Schnittstellen,
* vorgefertigte Pakete für mehrere Versionen von UE 4 und UE 5 bis einschließlich '''UE 5.8'''.

Für UE 5.8.0 und 5.8.1 nennt Intel eine bekannte Einschränkung: XeLL funktioniert dort ohne eine entsprechende Unreal-Engine-Korrektur nicht. Entwickler sollen auf ein Engine-Update warten oder den von Intel verlinkten Epic-Patch in einen Source Build übernehmen. XeSS-SR und die übrige Plugin-Funktionalität müssen davon getrennt bewertet werden.

Für UE 5.1 und neuer muss bei direkter Steuerung über Konsolenvariablen auch die Screen Percentage zum gewählten Qualitätsmodus passen. Die Blueprint-Schnittstelle übernimmt diese Anpassung automatisch.

== Offenheit und Verteilung ==

Intel stellt das XeSS SDK, Dokumentation, Header, Beispiele und Unreal-Plugin öffentlich auf GitHub bereit. Die optimierten Laufzeitkomponenten werden jedoch teilweise als vorgefertigte Bibliotheken ausgeliefert. Deshalb ist „vollständig Open Source“ als pauschale Beschreibung ungenau. Entwickler müssen außerdem die jeweiligen Lizenz- und Verteilungsbedingungen der SDK-Bestandteile beachten.

== Vorteile ==

* Super Resolution, Frame Generation und Latenzsteuerung in einem gemeinsamen SDK.
* Herstellerübergreifender XeSS-SR-Pfad für kompatible GPUs.
* Frame Generation unterstützt inzwischen auch kompatible Nicht-Intel-GPUs.
* Multi Frame Generation mit bis zu drei Zwischenbildern auf unterstützter Intel-Hardware.
* Native-AA-Modus sowie viele Qualitätsstufen.
* DirectX-12- und Vulkan-Unterstützung für XeSS-SR; zusätzlicher DirectX-11-Pfad auf Intel Arc.
* Offizielles Unreal-Engine-Plugin bis UE 5.8 und ein XeSS Inspector zur Integrationsprüfung.

== Nachteile und Grenzen ==

* Funktionsumfang und maximaler Frame-Multiplikator unterscheiden sich zwischen Intel- und Nicht-Intel-GPUs.
* XeSS-FG und XeLL besitzen strengere Plattformanforderungen als XeSS-SR.
* Frame Generation erhöht die angezeigte Bildrate, aber nicht im gleichen Maß die Reaktionsfähigkeit.
* Fehlerhafte Bewegungsvektoren, Masken oder UI-Trennung können sichtbare Artefakte verursachen.
* Sehr niedrige Eingangsbildraten verschlechtern Bewegungsqualität und Latenz von Frame Generation.
* Nicht alle Laufzeitbestandteile liegen als vollständig offener Quellcode vor.
* XeLL benötigt in UE 5.8.0 und 5.8.1 derzeit eine Engine-Korrektur.

== Quellen ==

* [https://www.intel.com/content/www/us/en/developer/topic-technology/gamedev/xess.html Intel: XeSS 3 für Entwickler]
* [https://github.com/intel/xess Intel: offizielles XeSS SDK]
* [https://github.com/intel/xess/releases Intel: XeSS-SDK-Versionen und Änderungsprotokoll]
* [https://github.com/intel/xess/blob/main/doc/xess_sr_developer_guide_english.md Intel: XeSS-SR Developer Guide]
* [https://github.com/intel/xess/blob/main/doc/xess_fg_developer_guide_english.md Intel: XeSS-FG Developer Guide]
* [https://github.com/intel/xess/blob/main/doc/xell_developer_guide_english.md Intel: XeLL Developer Guide]
* [https://github.com/GameTechDev/XeSSUnrealPlugin Intel: XeSS-Plugin für Unreal Engine]
* [https://github.com/GameTechDev/XeSSUnrealPlugin/releases Intel: Releases des Unreal-Engine-Plugins]

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Grafik]]
[[Kategorie:Intel]]
[[Kategorie:Künstliche Intelligenz]]

FidelityFX™ Super Resolution

2026-09-04T23:42:25Z

Elaina:

{{Hinweis|Stand: 4. September 2026. AMD hat FSR 4 inzwischen in „FSR Upscaling“ umbenannt. Aktuell ist FSR Upscaling 4.1.1 im FSR SDK 2.3.0.}}

'''AMD FidelityFX Super Resolution''' ('''FSR''') ist eine Familie von Verfahren zur Bildrekonstruktion und Leistungssteigerung in Spielen. Je nach Version skaliert FSR ein intern niedriger aufgelöstes Bild hoch, glättet Kanten oder erzeugt zusätzliche Zwischenbilder. Dadurch kann die Bildrate steigen, ohne dass das Spiel vollständig in der Ausgabeauflösung gerendert werden muss.

FSR ist nicht mit '''Radeon Super Resolution''' (RSR) zu verwechseln: FSR wird in ein Spiel integriert und kann Bewegungsvektoren, Tiefeninformationen und weitere Engine-Daten verwenden. RSR arbeitet als Treiberfunktion ohne eine solche Spielintegration.

== Entwicklung der FSR-Versionen ==

* '''FSR 1:''' räumliches Upscaling eines einzelnen Frames. Es benötigt keine Bewegungsvektoren, kann feine Details aber schlechter rekonstruieren.
* '''FSR 2:''' temporales Upscaling. Informationen aus mehreren Frames, Bewegungsvektoren, Tiefe und Kamerajitter verbessern Detailrekonstruktion und zeitliche Stabilität.
* '''FSR 3:''' erweitert das temporale Upscaling um optionale '''Frame Generation'''. Upscaling und Zwischenbilder sind getrennte Funktionen und können unabhängig voneinander verwendet werden.
* '''FSR 3.1:''' trennt Upscaling und Frame Generation technisch deutlicher, verbessert die Bildqualität und erleichtert den Austausch einzelner Komponenten.
* '''FSR Upscaling 4 / 4.1:''' nutzt ein Machine-Learning-Modell zur temporalen Bildrekonstruktion. Der ursprüngliche Name '''FSR 4''' wurde später in '''FSR Upscaling''' geändert, um die Funktion von den übrigen Bestandteilen der Redstone-Suite abzugrenzen.

== FSR Upscaling 4 und 4.1 ==

FSR Upscaling 4 analysiert räumliche und zeitliche Informationen mehrerer Frames mit einem Machine-Learning-Modell. Es rekonstruiert daraus ein höher aufgelöstes Ausgabebild. Gegenüber FSR 3.1 zielt das Verfahren insbesondere auf bessere Detailerhaltung, weniger Ghosting und stabilere Darstellung in Bewegung.

FSR Upscaling 4.1 verbessert unter anderem die Schärfe in Bewegung, den Ultra-Performance-Modus und die dynamische Auflösung. Die aktuelle Version 4.1.1 erweitert das ML-Upscaling auf diskrete Radeon-RX-7000-Grafikkarten.

Das ML-Upscaling ist nicht dasselbe wie Frame Generation: Upscaling rekonstruiert einen bereits gerenderten Frame in höherer Auflösung. Frame Generation erzeugt zusätzliche Zwischenbilder zwischen regulär gerenderten Frames.

== FSR „Redstone“ ==

'''FSR „Redstone“''' bezeichnet eine Suite aus mehreren Funktionen:

* '''FSR Upscaling:''' ML-gestützte Rekonstruktion eines höher aufgelösten Frames; früher FSR 4 genannt.
* '''FSR Frame Generation:''' erzeugt Zwischenbilder zur Erhöhung der angezeigten Bildrate.
* '''FSR Ray Regeneration:''' rekonstruiert und entrauscht Raytracing-Ergebnisse aus einer kleineren Zahl berechneter Strahlen.
* '''FSR Radiance Caching:''' ML-gestützte Vorhersage der Lichtausbreitung für globale Beleuchtung; derzeit als Vorschau geführt.

Diese Funktionen sind eigenständige Bausteine. Ein Spiel kann deshalb beispielsweise FSR Upscaling verwenden, ohne Frame Generation oder Ray Regeneration einzusetzen.

== Benötigte Engine-Daten ==

Für eine hochwertige temporale Rekonstruktion muss die Spiel-Engine korrekte Eingaben bereitstellen. Dazu gehören insbesondere:

* das niedrig aufgelöste Farbbild,
* Bewegungsvektoren von Kamera und Objekten,
* ein Tiefenpuffer,
* Kamerajitter für die zeitlich versetzten Abtastpositionen,
* Belichtungsinformationen,
* bei Bedarf eine Reactive Mask für transparente oder schwer rekonstruierbare Bildbereiche.

Fehlerhafte Bewegungsvektoren, ungeeignete Masken oder falsche Farbräume können Ghosting, Flimmern, Schlieren und Detailverlust verursachen. Die Qualität hängt daher nicht nur vom Algorithmus, sondern stark von der Integration im jeweiligen Spiel ab.

== Qualitätsmodi ==

{| class="wikitable"
! Modus
! Skalierungsfaktor pro Bilddimension
! Beispiel für 4K-Ausgabe
|-
| Native AA
| 1,0×
| 3840 × 2160
|-
| Quality
| 1,5×
| 2560 × 1440
|-
| Balanced
| 1,7×
| ungefähr 2259 × 1271
|-
| Performance
| 2,0×
| 1920 × 1080
|-
| Ultra Performance
| 3,0×
| 1280 × 720
|}

Ein größerer Faktor bedeutet eine niedrigere interne Renderauflösung und normalerweise mehr Leistung, stellt die Rekonstruktion aber vor eine schwierigere Aufgabe. Native AA verwendet keine niedrigere Renderauflösung und setzt das Verfahren nur zur Kantenglättung und Bildstabilisierung ein.

== Hardware und Plattformen ==

* '''FSR Upscaling 4.1.1:''' diskrete Radeon RX 7000 sowie Radeon RX 9000 und neuer.
* '''Weitere ML-Funktionen von Redstone:''' FSR Frame Generation 4, Ray Regeneration und Radiance Caching sind auf Radeon RX 9000 und neuer ausgerichtet.
* '''Fallback:''' Auf nicht unterstützter Hardware können Anwendungen analytische FSR-2-/FSR-3-Verfahren anbieten. Welche Funktion tatsächlich verfügbar ist, hängt von SDK-Version, Spiel und Hardware ab.
* '''Grafikschnittstellen:''' Das FSR SDK 2.3.0 dokumentiert DirectX 12 und Vulkan. Einzelne Effekte und Plugins können strengere Anforderungen besitzen.
* '''Betriebssystem:''' Die PC-Integration richtet sich primär an Windows 10 und Windows 11; bestimmte Redstone-Funktionen setzen Windows 11 voraus.

Die früher oft genannte Aussage „FSR funktioniert auf praktisch jeder GPU“ gilt damit weiterhin für ältere, analytische FSR-Versionen, aber nicht pauschal für die ML-Funktionen von FSR Upscaling 4 und Redstone.

== Unreal Engine 5 ==

AMD stellt ein offizielles FSR-Plugin für Unreal Engine 5 bereit. Das Plugin in Version 4.1.1 unterstützt '''Unreal Engine 5.3 bis 5.8''' und basiert auf dem '''FSR SDK 2.3.0'''. Es enthält FSR Upscaling 4.1.1 sowie FSR Frame Generation 4.0.1.

Auf passender Hardware wählt das Plugin die ML-Varianten. Für ältere oder nicht unterstützte Hardware stehen analytische Fallbacks bereit. Eine produktive Integration sollte außerdem Bewegungsvektoren, transparente Materialien, World Position Offset, Kameraschnitte, dynamische Auflösung und die Zusammenarbeit mit anderen Upscalern testen.

== Treiber-Upgrade und native Integration ==

FSR Upscaling kann auf zwei Arten verfügbar sein:

* '''Native Integration:''' Das Spiel bindet die passende FSR-Version direkt ein und bietet sie im Grafikmenü an.
* '''Treiber-Upgrade:''' Bei ausgewählten DirectX-12-Spielen mit geeigneter FSR-3.1-Integration kann AMD Software die verwendete Upscaling-Komponente durch eine ML-Version ersetzen. Für Frame Generation gelten eigene Mindestversionen und Voraussetzungen.

Die Kompatibilität ist nicht für jedes FSR-Spiel automatisch gegeben. AMD führt deshalb eine eigene, laufend aktualisierte Liste unterstützter Titel.

== Offenheit und Lizenzierung ==

„FSR ist Open Source“ lässt sich nicht mehr unterschiedslos auf alle Generationen und Komponenten übertragen. Teile des SDK, Beispiele und ältere Verfahren sind mit offenem Quellcode verfügbar. Die ML-basierten FSR-Komponenten werden dagegen als vorgefertigte und signierte Binärdateien ausgeliefert. Entwickler binden sie über die FSR-API ein. Diese Trennung ermöglicht AMD, Modelle und Implementierungen zu aktualisieren, ohne dass jedes Spiel den vollständigen Algorithmus selbst mitliefern muss.

== Vorteile ==

* Höhere Bildrate durch niedrigere interne Renderauflösung.
* ML-Upscaling bietet bessere Detailrekonstruktion und zeitliche Stabilität als frühere FSR-Generationen.
* Native-AA-Modus ohne Verringerung der Renderauflösung.
* Getrennte Module für Upscaling, Frame Generation und weitere Redstone-Funktionen.
* Offizielle Integration für Unreal Engine 5.3 bis 5.8.
* Analytische Fallbacks ermöglichen eine breitere Hardwareabdeckung als die ML-Funktionen allein.

== Nachteile und Grenzen ==

* Die ML-Varianten unterstützen nicht alle GPUs, auf denen ältere FSR-Versionen laufen.
* Die Bildqualität hängt stark von Bewegungsvektoren, Masken und der Integration des Spiels ab.
* Niedrige interne Auflösungen können feine Geometrie, Partikel, Transparenzen und UI-Elemente schwieriger rekonstruierbar machen.
* Frame Generation erhöht die angezeigte Bildrate, verbessert aber nicht im gleichen Maß die Eingabelatenz und kann eigene Artefakte erzeugen.
* Nicht alle Redstone-Funktionen stehen auf RX-7000-Grafikkarten zur Verfügung.
* Die ML-Laufzeit wird als signierte Binärkomponente und nicht vollständig als Quellcode verteilt.

== Quellen ==

* [https://www.amd.com/en/products/graphics/technologies/fidelityfx/super-resolution.html AMD: FSR-Technologien, Redstone, Hardware und Umbenennung von FSR 4]
* [https://gpuopen.com/manuals/fsr_sdk/ AMD GPUOpen: FSR SDK 2.3.0]
* [https://gpuopen.com/manuals/fsr_sdk/techniques/super-resolution-ml/ AMD GPUOpen: FSR Upscaling 4.1.1 – Integration, Qualitätsmodi und Voraussetzungen]
* [https://gpuopen.com/learn/ue-fsr/ AMD GPUOpen: Unreal Engine FSR Plugin]
* [https://gpuopen.com/manuals/fsr_sdk/samples/getting-started/ AMD GPUOpen: SDK-Inhalt, Plattformen und Open-Source-Hinweise]
* [https://www.amd.com/en/products/graphics/technologies/fidelityfx/supported-games.html AMD: laufend aktualisierte Liste unterstützter Spiele]

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Grafik]]
[[Kategorie:AMD]]
[[Kategorie:Künstliche Intelligenz]]

UE5 Heterogeneous Multi-GPU

2026-09-04T20:28:33Z

Elaina:

{{Hinweis|Projektstand: 4. September 2026. 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.

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.

{| class="wikitable"
|+ Projektstatus
|-
! Engine / Plattform
| Unreal Engine 5.8 Source Build / Windows / Direct3D 12
|-
! Testsystem
| Lenovo LOQ 17IRX10
|-
! Primary
| NVIDIA GeForce RTX 5060 Laptop GPU
|-
! Worker
| Intel UHD Graphics
|-
! Git-Stand
| Commit <code>4808b5b</code> auf Branch <code>mgpu-experimental</code>
|-
! Windows/D3D12-Proof-of-Concept
| Worker-Compute, Texturtransport und non-blocking UE-Runtime-Ausgabe grundsätzlich nachgewiesen
|-
! Gesamtvision
| etwa 30–35 % (Scheduler, echte Workloads, N-GPU und Vulkan noch offen)
|}

== Grundprinzip ==

<pre>
Intel Worker GPU
-> MainTextureCS
-> lokale Worker-Textur
-> Shared Cross-Adapter Buffer
-> Shared Fence / Queue Wait
-> UE-eigene FTextureRHIRef auf der Primary

RTX Primary GPU
-> normales UE5-Rendering
-> übernimmt und verwendet das Worker-Ergebnis
</pre>

Jeder Worker besitzt ein eigenes <code>ID3D12Device</code>, eigene Queues, Command Lists und Ressourcen. Ein späterer Scheduler soll Rechenleistung, Fähigkeiten, Transferkosten und gewünschte Aktualisierungsrate bewerten. Vorgesehene Aufgaben sind beispielsweise SceneCapture2D, Spiegel, CCTV, Minimap, Compute oder Niagara.

== Verifizierter Entwicklungsstand ==

=== Worker-Compute ===

Ein echter, von Unreal kompilierter Global Compute Shader läuft auf der Intel UHD, während Unreal regulär über die RTX rendert. Der Test verdoppelt 64 Ganzzahlen auf dem Worker; '''64 von 64 Ergebnissen wurden korrekt verifiziert'''. Damit ist echte GPU-Arbeit auf einem zweiten, herstellerfremden Device nachgewiesen.

Zusätzlich läuft inzwischen <code>MainTextureCS</code> auf der Intel-GPU. Der Shader erzeugt selbstständig eine 64 × 64 Pixel große RGBA8-Textur mit einem aus den Pixelkoordinaten berechneten Farbmuster. '''Alle 4096 shader-generierten Pixel wurden gegen das erwartete Ergebnis geprüft.''' Das frühere Zwischenziel, eine Textur direkt auf dem Worker zu erzeugen, ist damit erreicht.

=== Cross-Adapter-Speicher und Synchronisation ===

* RTX und Intel öffnen denselben D3D12 Cross-Adapter Heap.
* Ein gemeinsamer Buffer wurde mit 64 Testwerten erfolgreich geprüft.
* Ein Shared Fence synchronisiert die Queues direkt von GPU zu GPU.
* Die CPU vermittelt die GPU-Abhängigkeit nicht; Worker- und Primary-Queue verwenden <code>Signal</code> und <code>Wait</code> direkt auf der GPU.
* Der separate Readback-Verifikationstest darf weiterhin blockieren. Der normale Runtime-Pfad wartet dagegen nicht auf GPU-Leerlauf.

=== Texturtransport ===

Direkte Cross-Adapter-Texturen sind auf dem Testsystem nicht beidseitig verfügbar: Die Intel UHD meldet Unterstützung für Row-Major Cross-Adapter Textures, die RTX 5060 Laptop GPU nicht. Deshalb verwendet das Projekt einen allgemeineren Buffer-Fallback.

<pre>
Intel MainTextureCS
-> Worker-Textur
-> CopyTextureRegion
-> Shared Cross-Adapter Buffer
-> Worker signalisiert Shared Fence 1
-> UE-Primary-Queue wartet auf Fence 1
-> direkte Kopie in UE-eigene FTextureRHIRef
-> Primary signalisiert Completion Fence 2
</pre>

Der robuste Normal-Pfad kopiert die Worker-Textur über den Shared Buffer direkt in eine von Unreal erzeugte <code>FTextureRHIRef</code>. Der ältere Umweg über eine zusätzliche native RTX-Zwischentextur ist im Normal-Runtime-Test entfallen. Das Ergebnis wird pro Worker in einer Output Registry veröffentlicht und kann über <code>GetNormalTextureOutputForWorker()</code> abgerufen werden.

=== Non-blocking Runtime-Pfad ===

Die produktive Testlogik ist aus dem Konsolenkommando in eine gekapselte NormalPath-API verschoben. <code>QueueNormalTextureTransfer()</code> reiht Wait, Kopie und Completion-Signal in Unreals D3D12-Kontext ein. Ein <code>SubmitAndBlockUntilGPUIdle</code> ist im normalen Ablauf nicht mehr erforderlich.

Eine native D3D12-Resource wird dabei bewusst nicht blind als UE-Textur gewrappt. Unreal könnte sonst einen anderen Ressourcenstatus annehmen als den tatsächlich vorhandenen. Ein späterer direkter Fast Path bleibt experimentell und muss auf den sicheren Normal-Pfad zurückfallen können.

=== Lebensdauer und automatisches Cleanup ===

Da die CPU nicht mehr blockierend auf das Ergebnis wartet, müssen Heap, Buffer und Fence bis zum tatsächlichen Abschluss der Primary-Kopie am Leben bleiben. Eine In-Flight Registry hält deshalb jeden Transport über mehrere Frames und prüft ihn automatisch in <code>FD3D12DynamicRHI::RHIEndFrame()</code>:

<pre>
Transport anlegen und registrieren
-> Worker Fence 1: Worker-Kopie abgeschlossen
-> Primary Fence 2: UE-Zieltextur fertig beschrieben
-> RHIEndFrame prüft GetCompletedValue()
-> erst ab Fence 2 Ressourcen freigeben
</pre>

Mehrere Transporte können gleichzeitig in flight sein. Im aktuellen Stand besitzt jeder Transport eine eigene Shared Fence sowie eigene Shared Heaps und Buffer; die Werte 1 und 2 sind daher transportlokal. Bei einem späteren Fence-Pool müssen Fence-Werte pro Fence monoton steigen. Ein gepoolter Buffer-Slot darf erst nach Abschluss der Primary-Kopie wiederverwendet werden, nicht bereits nach der Worker-Kopie.

== Aktueller nächster Schritt ==

Breite und Höhe werden am Cross-Adapter-Transport bereits aus <code>WorkerTexture->GetDesc()</code> gelesen. Der SafeCopy-Zielpfad enthält jedoch noch Annahmen des verifizierten 64×64-Falls. Als nächster Test ist deshalb bewusst eine '''nicht quadratische 128×96-RGBA8-Textur''' vorgesehen. Sie deckt vertauschte Dimensionen und ungewollte Quadratannahmen früh auf.

Erst nach dieser Dimensions-Generalierung folgen weitere Formate, Mips, Arrays oder Slices sowie persistente Ressourcenpools, belastbare Benchmarks und ein erster echter UE-Szenen-Workload.

== Historische Vorläufer ==

Die Grundidee heterogener Multi-GPU-Nutzung ist nicht neu. Bereits mit der Einführung von Direct3D 12 entstanden mehrere Versuche, integrierte und dedizierte GPUs gemeinsam zu verwenden. Eine allgemein einsetzbare Lösung für moderne UE5-Spiele hat sich daraus jedoch nicht entwickelt.

=== Microsoft und Epic: UE4 Elemental Demo (2015) ===

Microsoft zeigte eine angepasste Unreal-Engine-4-Version der Elemental-Demo, bei der eine NVIDIA-GPU und eine Intel-iGPU gemeinsam arbeiteten. Das erklärte Ziel war, ansonsten ungenutzte Grafikleistung in Hybrid-Systemen zu verwenden. Dieser Versuch ist der Grundidee des Projekts besonders ähnlich, blieb aber eine technische Demonstration.

=== Intel: D3D12 Multi-Adapter Sample (2015) ===

Intels Beispiel kombinierte eine GeForce 840M mit Intel HD Graphics 5500. Beide GPUs berechneten getrennte Teile einer einfach parallelisierbaren Raytracing-Szene. Cross-Adapter-Ressourcen und Shared Fences führten die Ergebnisse anschließend zusammen. Intel berichtete in diesem Test von nahezu halbierter Framezeit, warnte jedoch ausdrücklich davor, das Ergebnis unmittelbar auf reale Spiele zu übertragen.

=== Ashes of the Singularity ===

Die Nitrous Engine von ''Ashes of the Singularity'' setzte Direct3D-12-Explicit-Multiadapter in einem veröffentlichten Spiel ein. Dabei konnten auch unterschiedliche GPU-Modelle und Hersteller zusammenarbeiten. Das war ein wichtiger Praxisnachweis, blieb in der Spielebranche aber eine seltene Ausnahme.

=== Weitere verwandte Ansätze ===

* ''Rise of the Tomb Raider'' erhielt explizite Direct3D-12-Multi-GPU-Unterstützung, vor allem für klassische Kombinationen ähnlicher GPUs.
* NVIDIA VR SLI wies bei Virtual Reality jeder GPU ein Auge zu. Das verteilt unabhängige Ansichten, bleibt jedoch NVIDIA-spezifisch.
* Unreal nDisplay kann Viewports oder Frustums auf weitere GPUs beziehungsweise Prozesse auslagern und das fertige Bild zur Ausgabe-GPU zurückführen. Der Einsatzbereich ist hauptsächlich Virtual Production.
* Forschung und High-Performance Computing verwenden seit Jahren Scheduler für heterogene GPUs, allerdings überwiegend für Compute- und Datenverarbeitungsaufgaben statt für einen allgemeinen UE5-Echtzeitrenderer.

=== Abgrenzung dieses Projekts ===

Das Projekt erfindet Direct3D-12-Explicit-Multiadapter nicht neu. Sein eigener Ansatz liegt in der Kombination aus tiefer UE5.8-RHI-Integration, UE-kompilierten Shadern auf unabhängigen Worker-Devices, frei wählbaren Spiel- und Compute-Workloads, Capability- und Performance-Scheduler, mehreren Fallback-Pfaden sowie dem langfristigen Ziel beliebiger Hersteller und mehrerer Worker.

== Vergleich mit anderen Multi-GPU-Verfahren ==

{| class="wikitable"
! Verfahren
! Arbeitsweise
! Verhältnis zu diesem Projekt
|-
| SLI / CrossFire
| Treiber- beziehungsweise Verbundlösung für meist ähnliche GPUs; häufig wird die Bildarbeit verteilt.
| Dieses Projekt benötigt keinen herstellerspezifischen GPU-Verbund und weist Aufgaben ausdrücklich selbst zu.
|-
| AFR (Alternate Frame Rendering)
| GPU 1 rendert einen Frame, GPU 2 den nächsten.
| Das Projekt verteilt unabhängige Aufgaben statt aufeinanderfolgender Frames. Dadurch werden Frame-Abhängigkeiten und typisches AFR-Pacing vermieden.
|-
| SFR (Split Frame Rendering)
| Mehrere GPUs bearbeiten Bereiche desselben Frames.
| Erfordert enge Lastverteilung und viel Datenaustausch. Das Projekt bevorzugt vollständig abgrenzbare Workloads und überträgt deren Ergebnis.
|-
| Direct3D 12 Linked Multiadapter
| Mehrere vom Treiber verbundene GPUs erscheinen als Knoten eines logischen Adapters.
| Eignet sich eher für eng kompatible GPUs. Das Projekt verwendet unabhängige Devices (Unlinked/Explicit Multiadapter) und unterstützt dadurch heterogene Herstellerkombinationen.
|-
| Direct3D 12 Unlinked / Explicit Multiadapter
| Die Anwendung verwaltet getrennte Adapter, Ressourcen und Synchronisation selbst.
| Das ist die technische Familie des Projekts. Hinzu kommen die eigene UE5-RHI-Integration, Workload-Ziele, Fallbacks und der geplante Scheduler.
|-
| UE nDisplay mGPU / Multi-Process
| Separate GPUs rendern bestimmte Viewports oder Frustums, vor allem für Virtual Production; Ergebnisse werden zur Ausgabe-GPU kopiert.
| Ähnliche Idee der aufgabenweisen Trennung, aber für einen anderen Einsatzbereich. Dieses Projekt zielt auf allgemeine Spiel- und Compute-Workloads innerhalb der Engine.
|-
| Vulkan Device Groups
| Ähnliche physische GPUs können ein gemeinsames logisches Device bilden.
| Für beliebige heterogene GPUs meist ungeeignet, da Geräte einer Gruppe nahezu gleiche Eigenschaften besitzen müssen. Eine spätere Vulkan-Portierung benötigt daher wahrscheinlich getrennte Devices und External Memory/Semaphores.
|}

SLI und CrossFire bezeichnen den Verbund; AFR und SFR beschreiben mögliche Verteilungsmethoden innerhalb solcher Systeme. Sie sind deshalb nicht vollständig getrennte Kategorien.

== Vorteile der geplanten Variante ==

* '''Herstellerunabhängig:''' NVIDIA, AMD und Intel können grundsätzlich kombiniert werden.
* '''Vorhandene Hardware nutzen:''' Auch eine sonst wenig genutzte integrierte GPU kann geeignete Nebenaufgaben übernehmen.
* '''Aufgaben statt Frames verteilen:''' Spiegel, Minimap oder Compute können mit eigener Auflösung und Aktualisierungsrate laufen.
* '''Keine identischen GPUs erforderlich:''' Unterschiedliche Fähigkeiten können gezielt genutzt werden.
* '''Kontrollierter Datenaustausch:''' Nur das benötigte Ergebnis muss zurück zur Primary-GPU.
* '''Robuste Fallback-Idee:''' Wenn direkte Texturen nicht gemeinsam nutzbar sind, bleibt der Shared-Buffer-Pfad.
* '''Erweiterbar:''' Scheduler, manuelles Mapping und mehrere Worker sind als spätere Stufen vorgesehen.

== Nachteile und technische Risiken ==

* '''Hoher Entwicklungsaufwand:''' Geräte, Ressourcen, Zustände, Fences, Fehlerfälle und UE-Lebenszyklen müssen selbst verwaltet werden.
* '''Transfer kann den Gewinn aufzehren:''' Cross-Adapter Heaps liegen laut D3D12 nicht automatisch im schnellen lokalen VRAM. Bandbreite und Latenz müssen für jeden Workload gemessen werden.
* '''VRAM wird nicht einfach addiert:''' Benötigte Ressourcen können auf mehreren GPUs vorliegen und zusätzlichen Speicher verbrauchen.
* '''Langsame Worker können bremsen:''' Eine Aufgabe lohnt sich nur, wenn Rechengewinn größer als Übergabe-, Warte- und Kopierkosten ist.
* '''Nicht jeder Workload ist unabhängig:''' Hauptansicht, Lumen, Nanite und stark gekoppelte Renderpässe besitzen viele Abhängigkeiten und sind schwieriger auszulagern.
* '''Hardwareunterschiede:''' Formate, Shader-Funktionen, Queue-Fähigkeiten und Cross-Adapter-Support müssen pro GPU geprüft werden.
* '''Wartungsrisiko:''' Eingriffe in private D3D12RHI-Dateien können bei Engine-Updates angepasst werden müssen.
* '''Produktionsreife fehlt noch:''' Ressourcenpools, Timeouts, Device-Lost-Wiederherstellung, Scheduler und echte Szenentests sind offen.

== Wann die Variante sinnvoll ist ==

Am aussichtsreichsten sind Aufgaben mit viel eigener Rechenarbeit, einem relativ kleinen Endergebnis und wenigen Abhängigkeiten zur Hauptszene. Gute frühe Kandidaten sind unabhängige Compute-Aufgaben sowie Scene Captures, die nicht in jedem Frame aktualisiert werden müssen. Weniger geeignet sind winzige Aufgaben mit großem Transfer oder Renderpässe, die ständig auf Ressourcen der Primary-GPU zugreifen.

Die entscheidende Regel für den späteren Scheduler lautet daher:

<pre>
Worker-Gewinn > Vorbereitung + Datentransfer + Synchronisation + Rückintegration
</pre>

== Bekannte Grenzen des Proof of Concepts ==

* Der SafeCopy-Zielpfad ist trotz dynamisch gelesener Worker-Dimensionen noch auf den verifizierten 64×64-Testfall zugeschnitten.
* Der Normal-Transport unterstützt derzeit <code>DXGI_FORMAT_R8G8B8A8_UNORM</code> mit Sample Count 1; weitere Formate, Mips, Arrays, Slices und MSAA sind offen.
* Shared Heaps, Buffer, Fences, Worker Allocators und Command Lists werden noch pro Transfer erzeugt. Für Produktion braucht es Pooling sowie Double-, Triple- oder Ring-Buffering.
* Raw-D3D12-Shared-Ressourcen sind noch nicht vollständig in Unreals Residency-Management eingebunden.
* Praktisch getestet ist Primary plus ein Worker. Die Architektur ist auf mehrere Worker ausgelegt, N-GPU ist aber noch nicht praktisch validiert.
* Ein echter UE-Szenen-Workload, Benchmark-Wizard und Scheduler fehlen weiterhin.
* 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.

== Roadmap ==

# SafeCopy-Dimensionen vollständig generalisieren und 128×96 RGBA8 testen.
# Danach Formate, Mips, Arrays/Slices und gegebenenfalls MSAA capability-basiert erweitern.
# Shared Heaps, Buffer, Fences und Command Objects persistent halten; Ring- beziehungsweise Mehrfachpuffer einführen.
# Latenz, Bandbreite, Größen, Update-Raten und Synchronisationskosten messen.
# Ersten echten UE-Offload integrieren und das Worker-Ergebnis in Material, Compositing oder Render Graph verwenden.
# Capability-Matrix, Benchmark-Wizard, Scheduler und manuelle Overrides entwickeln.
# Mehrere Worker-GPUs unterstützen.
# Fallback-Matrix aus Normal Shared Buffer, System-RAM/Staging und einem späteren Experimental Fast Path ergänzen.
# Linux/Vulkan mit getrennten Devices, External Memory und externer Synchronisation untersuchen.

== Quellen ==

* Interner Entwicklungsstand und verifizierte Testprotokolle vom 4. September 2026, Commit <code>4808b5b</code>
* [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/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://www.intel.com/content/dam/develop/external/us/en/documents/multi-adapter-support-in-directx-12-594015.pdf Intel: Multi-Adapter Support in DirectX 12]
* [https://devblogs.microsoft.com/directx/ashes-of-the-singularity-makes-gaming-history-with-directx-12/ Microsoft: Ashes of the Singularity und heterogene Adapter]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/nvidia-sli-alternative-frame-rendering-in-unreal-engine Epic: NVIDIA SLI Alternate Frame Rendering]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/multi-process-rendering-with-unreal-engine Epic: Multi-Process Rendering]
* [https://registry.khronos.org/vulkan/specs/latest/pdf/vkspec.pdf Khronos: Vulkan Specification – Device Groups]

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Multi-GPU]]
[[Kategorie:Direct3D 12]]
[[Kategorie:Experimentell]]

Direct3D 12, Shader Model 6 und Windows-RHI

2026-09-04T13:03:14Z

Elaina: Die Seite wurde neu angelegt: „{{Hinweis|Stand: Unreal Engine 5.8 unter Windows. Bezeichnungen in der Oberfläche können bei lokalisierten Editor-Versionen leicht abweichen.}} '''Direct3D 12 (D3D12)''' ist Microsofts moderne Grafikschnittstelle. Unreal Engine greift nicht direkt aus jedem Spielsystem darauf zu, sondern über das '''Rendering Hardware Interface (RHI)'''. Das RHI vereinheitlicht verschiedene Grafik-APIs wie Direct3D 11, Direct3D 12 und Vulkan. '''Shader Model 6 (SM6)'…“

Multi-Process Rendering und Multi-GPU

2026-09-04T13:02:56Z

Elaina: Die Seite wurde neu angelegt: „{{Hinweis|Stand: Unreal Engine 5.8. Dieser Artikel beschreibt Epics offiziell dokumentierte nDisplay-Verfahren.}} '''Multi-Process Rendering''' und '''Multi-GPU (mGPU)''' verteilen bei nDisplay Rendering-Arbeit auf mehrere Grafikkarten. Sie benutzen ähnliche Hardware, arbeiten intern aber unterschiedlich. Beide Verfahren sind auf virtuelle Produktion und große, synchronisierte Anzeigeflächen ausgerichtet. == Begriffe kurz erklärt == * '''nDisplay''…“

UE5 Heterogeneous Multi-GPU

2026-09-04T00:47:46Z

Elaina:

{{Hinweis|Projektstand: 4. September 2026. 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.

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.

{| class="wikitable"
|+ Projektstatus
|-
! Engine / Plattform
| Unreal Engine 5.8 Source Build / Windows / Direct3D 12
|-
! Testsystem
| Lenovo LOQ 17IRX10
|-
! Primary
| NVIDIA GeForce RTX 5060 Laptop GPU
|-
! Worker
| Intel UHD Graphics
|-
! Windows/D3D12-Proof-of-Concept
| etwa 75–80 % (grobe Projekteinschätzung)
|-
! Gesamtvision
| etwa 30–35 % (Scheduler, echte Workloads, N-GPU und Vulkan noch offen)
|}

== Grundprinzip ==

<pre>
Intel Worker GPU
-> eigener UE-Compute-Shader / später eigenständiger Workload
-> lokale Worker-Ressource
-> Shared Cross-Adapter Buffer
-> Shared Fence
-> lokale RTX-Ressource

RTX Primary GPU
-> normales UE5-Rendering
-> übernimmt und verwendet das Worker-Ergebnis
</pre>

Jeder Worker besitzt ein eigenes <code>ID3D12Device</code>, eigene Queues, Command Lists und Ressourcen. Ein späterer Scheduler soll Rechenleistung, Fähigkeiten, Transferkosten und gewünschte Aktualisierungsrate bewerten. Vorgesehene Aufgaben sind beispielsweise SceneCapture2D, Spiegel, CCTV, Minimap, Compute oder Niagara.

== Verifizierter Entwicklungsstand ==

=== Worker-Compute ===

Ein echter, von Unreal kompilierter Global Compute Shader läuft auf der Intel UHD, während Unreal regulär über die RTX rendert. Der Test verdoppelt 64 Ganzzahlen auf dem Worker; '''64 von 64 Ergebnissen wurden korrekt verifiziert'''. Damit ist echte GPU-Arbeit auf einem zweiten, herstellerfremden Device nachgewiesen.

=== Cross-Adapter-Speicher und Synchronisation ===

* RTX und Intel öffnen denselben D3D12 Cross-Adapter Heap.
* Ein gemeinsamer Buffer wurde mit 64 Testwerten erfolgreich geprüft.
* Ein Shared Fence synchronisiert die Queues direkt von GPU zu GPU.
* Die CPU wartet im Test nur noch für die abschließende Ergebnisprüfung, nicht als Vermittler der GPU-Abhängigkeit.

=== Texturtransport ===

Direkte Cross-Adapter-Texturen sind auf dem Testsystem nicht beidseitig verfügbar: Die Intel UHD meldet Unterstützung für Row-Major Cross-Adapter Textures, die RTX 5060 Laptop GPU nicht. Deshalb verwendet das Projekt einen allgemeineren Buffer-Fallback.

<pre>
Intel-Textur
-> CopyTextureRegion
-> Shared Cross-Adapter Buffer
-> Shared Fence / RTX Queue Wait
-> lokale RTX-Textur
-> Readback und Prüfung
</pre>

Eine 64 × 64 Pixel große RGBA8-Testtextur wurde auf diesem Weg vollständig übertragen und auf der RTX als echte lokale Textur rekonstruiert. '''4096 von 4096 Pixeln waren korrekt.'''

== Aktueller nächster Schritt ==

Der zweite Global Shader <code>MainTextureCS</code> ist registriert und wird bereits als RHI-Shader erzeugt. Als Nächstes soll er die Testtextur direkt auf der Intel-GPU erzeugen. Danach folgt der bereits verifizierte Transportweg zur RTX:

<pre>
MainTextureCS -> Intel-Textur -> Shared Buffer -> Shared Fence -> RTX-Textur
</pre>

Erst danach folgen persistente Ressourcenpools, Double- oder Triple-Buffering, belastbare Benchmarks und ein erster echter UE-Szenen-Workload.

== Historische Vorläufer ==

Die Grundidee heterogener Multi-GPU-Nutzung ist nicht neu. Bereits mit der Einführung von Direct3D 12 entstanden mehrere Versuche, integrierte und dedizierte GPUs gemeinsam zu verwenden. Eine allgemein einsetzbare Lösung für moderne UE5-Spiele hat sich daraus jedoch nicht entwickelt.

=== Microsoft und Epic: UE4 Elemental Demo (2015) ===

Microsoft zeigte eine angepasste Unreal-Engine-4-Version der Elemental-Demo, bei der eine NVIDIA-GPU und eine Intel-iGPU gemeinsam arbeiteten. Das erklärte Ziel war, ansonsten ungenutzte Grafikleistung in Hybrid-Systemen zu verwenden. Dieser Versuch ist der Grundidee des Projekts besonders ähnlich, blieb aber eine technische Demonstration.

=== Intel: D3D12 Multi-Adapter Sample (2015) ===

Intels Beispiel kombinierte eine GeForce 840M mit Intel HD Graphics 5500. Beide GPUs berechneten getrennte Teile einer einfach parallelisierbaren Raytracing-Szene. Cross-Adapter-Ressourcen und Shared Fences führten die Ergebnisse anschließend zusammen. Intel berichtete in diesem Test von nahezu halbierter Framezeit, warnte jedoch ausdrücklich davor, das Ergebnis unmittelbar auf reale Spiele zu übertragen.

=== Ashes of the Singularity ===

Die Nitrous Engine von ''Ashes of the Singularity'' setzte Direct3D-12-Explicit-Multiadapter in einem veröffentlichten Spiel ein. Dabei konnten auch unterschiedliche GPU-Modelle und Hersteller zusammenarbeiten. Das war ein wichtiger Praxisnachweis, blieb in der Spielebranche aber eine seltene Ausnahme.

=== Weitere verwandte Ansätze ===

* ''Rise of the Tomb Raider'' erhielt explizite Direct3D-12-Multi-GPU-Unterstützung, vor allem für klassische Kombinationen ähnlicher GPUs.
* NVIDIA VR SLI wies bei Virtual Reality jeder GPU ein Auge zu. Das verteilt unabhängige Ansichten, bleibt jedoch NVIDIA-spezifisch.
* Unreal nDisplay kann Viewports oder Frustums auf weitere GPUs beziehungsweise Prozesse auslagern und das fertige Bild zur Ausgabe-GPU zurückführen. Der Einsatzbereich ist hauptsächlich Virtual Production.
* Forschung und High-Performance Computing verwenden seit Jahren Scheduler für heterogene GPUs, allerdings überwiegend für Compute- und Datenverarbeitungsaufgaben statt für einen allgemeinen UE5-Echtzeitrenderer.

=== Abgrenzung dieses Projekts ===

Das Projekt erfindet Direct3D-12-Explicit-Multiadapter nicht neu. Sein eigener Ansatz liegt in der Kombination aus tiefer UE5.8-RHI-Integration, UE-kompilierten Shadern auf unabhängigen Worker-Devices, frei wählbaren Spiel- und Compute-Workloads, Capability- und Performance-Scheduler, mehreren Fallback-Pfaden sowie dem langfristigen Ziel beliebiger Hersteller und mehrerer Worker.

== Vergleich mit anderen Multi-GPU-Verfahren ==

{| class="wikitable"
! Verfahren
! Arbeitsweise
! Verhältnis zu diesem Projekt
|-
| SLI / CrossFire
| Treiber- beziehungsweise Verbundlösung für meist ähnliche GPUs; häufig wird die Bildarbeit verteilt.
| Dieses Projekt benötigt keinen herstellerspezifischen GPU-Verbund und weist Aufgaben ausdrücklich selbst zu.
|-
| AFR (Alternate Frame Rendering)
| GPU 1 rendert einen Frame, GPU 2 den nächsten.
| Das Projekt verteilt unabhängige Aufgaben statt aufeinanderfolgender Frames. Dadurch werden Frame-Abhängigkeiten und typisches AFR-Pacing vermieden.
|-
| SFR (Split Frame Rendering)
| Mehrere GPUs bearbeiten Bereiche desselben Frames.
| Erfordert enge Lastverteilung und viel Datenaustausch. Das Projekt bevorzugt vollständig abgrenzbare Workloads und überträgt deren Ergebnis.
|-
| Direct3D 12 Linked Multiadapter
| Mehrere vom Treiber verbundene GPUs erscheinen als Knoten eines logischen Adapters.
| Eignet sich eher für eng kompatible GPUs. Das Projekt verwendet unabhängige Devices (Unlinked/Explicit Multiadapter) und unterstützt dadurch heterogene Herstellerkombinationen.
|-
| Direct3D 12 Unlinked / Explicit Multiadapter
| Die Anwendung verwaltet getrennte Adapter, Ressourcen und Synchronisation selbst.
| Das ist die technische Familie des Projekts. Hinzu kommen die eigene UE5-RHI-Integration, Workload-Ziele, Fallbacks und der geplante Scheduler.
|-
| UE nDisplay mGPU / Multi-Process
| Separate GPUs rendern bestimmte Viewports oder Frustums, vor allem für Virtual Production; Ergebnisse werden zur Ausgabe-GPU kopiert.
| Ähnliche Idee der aufgabenweisen Trennung, aber für einen anderen Einsatzbereich. Dieses Projekt zielt auf allgemeine Spiel- und Compute-Workloads innerhalb der Engine.
|-
| Vulkan Device Groups
| Ähnliche physische GPUs können ein gemeinsames logisches Device bilden.
| Für beliebige heterogene GPUs meist ungeeignet, da Geräte einer Gruppe nahezu gleiche Eigenschaften besitzen müssen. Eine spätere Vulkan-Portierung benötigt daher wahrscheinlich getrennte Devices und External Memory/Semaphores.
|}

SLI und CrossFire bezeichnen den Verbund; AFR und SFR beschreiben mögliche Verteilungsmethoden innerhalb solcher Systeme. Sie sind deshalb nicht vollständig getrennte Kategorien.

== Vorteile der geplanten Variante ==

* '''Herstellerunabhängig:''' NVIDIA, AMD und Intel können grundsätzlich kombiniert werden.
* '''Vorhandene Hardware nutzen:''' Auch eine sonst wenig genutzte integrierte GPU kann geeignete Nebenaufgaben übernehmen.
* '''Aufgaben statt Frames verteilen:''' Spiegel, Minimap oder Compute können mit eigener Auflösung und Aktualisierungsrate laufen.
* '''Keine identischen GPUs erforderlich:''' Unterschiedliche Fähigkeiten können gezielt genutzt werden.
* '''Kontrollierter Datenaustausch:''' Nur das benötigte Ergebnis muss zurück zur Primary-GPU.
* '''Robuste Fallback-Idee:''' Wenn direkte Texturen nicht gemeinsam nutzbar sind, bleibt der Shared-Buffer-Pfad.
* '''Erweiterbar:''' Scheduler, manuelles Mapping und mehrere Worker sind als spätere Stufen vorgesehen.

== Nachteile und technische Risiken ==

* '''Hoher Entwicklungsaufwand:''' Geräte, Ressourcen, Zustände, Fences, Fehlerfälle und UE-Lebenszyklen müssen selbst verwaltet werden.
* '''Transfer kann den Gewinn aufzehren:''' Cross-Adapter Heaps liegen laut D3D12 nicht automatisch im schnellen lokalen VRAM. Bandbreite und Latenz müssen für jeden Workload gemessen werden.
* '''VRAM wird nicht einfach addiert:''' Benötigte Ressourcen können auf mehreren GPUs vorliegen und zusätzlichen Speicher verbrauchen.
* '''Langsame Worker können bremsen:''' Eine Aufgabe lohnt sich nur, wenn Rechengewinn größer als Übergabe-, Warte- und Kopierkosten ist.
* '''Nicht jeder Workload ist unabhängig:''' Hauptansicht, Lumen, Nanite und stark gekoppelte Renderpässe besitzen viele Abhängigkeiten und sind schwieriger auszulagern.
* '''Hardwareunterschiede:''' Formate, Shader-Funktionen, Queue-Fähigkeiten und Cross-Adapter-Support müssen pro GPU geprüft werden.
* '''Wartungsrisiko:''' Eingriffe in private D3D12RHI-Dateien können bei Engine-Updates angepasst werden müssen.
* '''Produktionsreife fehlt noch:''' Ressourcenpools, Timeouts, Device-Lost-Wiederherstellung, Scheduler und echte Szenentests sind offen.

== Wann die Variante sinnvoll ist ==

Am aussichtsreichsten sind Aufgaben mit viel eigener Rechenarbeit, einem relativ kleinen Endergebnis und wenigen Abhängigkeiten zur Hauptszene. Gute frühe Kandidaten sind unabhängige Compute-Aufgaben sowie Scene Captures, die nicht in jedem Frame aktualisiert werden müssen. Weniger geeignet sind winzige Aufgaben mit großem Transfer oder Renderpässe, die ständig auf Ressourcen der Primary-GPU zugreifen.

Die entscheidende Regel für den späteren Scheduler lautet daher:

<pre>
Worker-Gewinn > Vorbereitung + Datentransfer + Synchronisation + Rückintegration
</pre>

== Roadmap ==

# <code>MainTextureCS</code> auf der Worker-GPU ausführen und Ergebnis übertragen.
# Shared Heaps, Buffer und Fences persistent halten; Ring- beziehungsweise Mehrfachpuffer einführen.
# Latenz und Bandbreite für verschiedene Größen und Update-Raten messen.
# Ersten echten UE-Offload integrieren und als Primary-RHI-Textur bereitstellen.
# Capability-Matrix, Benchmark-Wizard, Scheduler und manuelle Overrides entwickeln.
# Mehrere Worker-GPUs unterstützen.
# Fallback über System-RAM ergänzen.
# Linux/Vulkan mit getrennten Devices, External Memory und externer Synchronisation untersuchen.

== Quellen ==

* Interner Entwicklungsstand und verifizierte Testprotokolle vom 4. September 2026
* [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/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://www.intel.com/content/dam/develop/external/us/en/documents/multi-adapter-support-in-directx-12-594015.pdf Intel: Multi-Adapter Support in DirectX 12]
* [https://devblogs.microsoft.com/directx/ashes-of-the-singularity-makes-gaming-history-with-directx-12/ Microsoft: Ashes of the Singularity und heterogene Adapter]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/nvidia-sli-alternative-frame-rendering-in-unreal-engine Epic: NVIDIA SLI Alternate Frame Rendering]
* [https://dev.epicgames.com/documentation/en-us/unreal-engine/multi-process-rendering-with-unreal-engine Epic: Multi-Process Rendering]
* [https://registry.khronos.org/vulkan/specs/latest/pdf/vkspec.pdf Khronos: Vulkan Specification – Device Groups]

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Multi-GPU]]
[[Kategorie:Direct3D 12]]
[[Kategorie:Experimentell]]

UE5 Heterogeneous Multi-GPU

2026-09-04T00:38:48Z

Elaina:

Deep Learning Super Sampling

2026-09-04T00:38:39Z

Elaina:

{{Hinweis|Stand: 4. September 2026. DLSS 5 ist neu; unabhängige Praxistests und unterstützte Spiele sind noch begrenzt.}}

'''Deep Learning Super Sampling''' ('''DLSS''') ist eine Sammlung KI-gestützter Grafikverfahren von NVIDIA. Je nach Funktion rekonstruiert DLSS ein höher aufgelöstes Bild, verbessert Raytracing-Ergebnisse, erzeugt zusätzliche Frames oder ergänzt mit DLSS 5 das endgültige Erscheinungsbild eines Frames.

== Die wichtigsten Bestandteile ==

* '''Super Resolution:''' rekonstruiert aus einer niedrigeren Renderauflösung ein höher aufgelöstes Bild.
* '''DLAA:''' nutzt das Modell zur Kantenglättung bei nativer Auflösung.
* '''Ray Reconstruction:''' ersetzt mehrere klassische Denoiser für Ray- und Pathtracing.
* '''Frame Generation:''' erzeugt Zwischenbilder; NVIDIA Reflex soll die zusätzliche Latenz begrenzen.
* '''Multi Frame Generation:''' erzeugt mehrere Zwischenbilder pro regulär gerendertem Frame.
* '''3D-Guided Neural Rendering:''' ergänzt mit DLSS 5 Beleuchtung und Materialwirkung im finalen Bild.

== DLSS 4 und 4.5 ==

DLSS 4 führte Transformer-Modelle für Super Resolution, DLAA und Ray Reconstruction ein. Transformer können Bildbereiche und zeitliche Zusammenhänge umfangreicher auswerten als die zuvor verwendeten Netze. Auf RTX-50-Grafikkarten kam außerdem Multi Frame Generation hinzu: DLSS 4 kann bis zu drei zusätzliche Frames zwischen zwei regulär gerenderten Frames erzeugen.

DLSS 4.5 erweitert dies um ein leistungsfähigeres Transformer-Modell und '''Dynamic Multi Frame Generation'''. Dabei kann der Multiplikator automatisch angepasst werden. Maximal werden fünf zusätzliche Frames pro regulär gerendertem Frame erzeugt (6X-Anzeigeausgabe).

== Was DLSS 5 verändert ==

DLSS 5 ist kein bloßer Nachfolger des Upscalers. Die neue Funktion heißt '''3D-Guided Neural Rendering''' und arbeitet als zusätzliche Stufe am Ende der Renderpipeline. Ein einstufiges Diffusionsmodell erhält unter anderem das gerenderte Ausgangsbild, Bewegungsvektoren, zeitlichen Zustand und Engine-Informationen. Daraus ergänzt es schwer in Echtzeit darstellbare Erscheinungsdetails, beispielsweise:

* Lichtstreuung in Haut,
* Lichtdurchlässigkeit bei Haaren und Blättern,
* Materialreaktionen und Reflexionen,
* Kontakt- und Umgebungsschatten,
* Teile der globalen Beleuchtungswirkung.

Geometrie, grundlegende Szene und künstlerische Gestaltung stammen weiterhin aus dem Spiel. Das Modell soll deterministisch arbeiten und von Frame zu Frame stabil bleiben. Entwickler können Modellvarianten wählen, Struktur- und Tonwirkung einstellen und Objekte über semantische oder Engine-Masken von der Bearbeitung ausnehmen.

== Vergleich: DLSS 4/4.5 und DLSS 5 ==

{| class="wikitable"
! Punkt
! DLSS 4 / 4.5
! DLSS 5
|-
| Hauptziel
| Mehr Bildqualität und Bildrate aus vorhandenen Renderdaten
| Realistischere Beleuchtung und Materialwirkung erzeugen
|-
| Arbeitsweise
| Rekonstruktion, Denoising und Frame-Interpolation
| Generative, durch 3D- und Engine-Daten geführte Bildveredelung
|-
| Erzeugt zusätzliche Frames?
| Ja, über Frame beziehungsweise Multi Frame Generation
| Nicht selbst; kann mit Multi Frame Generation kombiniert werden
|-
| Verändert die Erscheinung?
| Überwiegend Rekonstruktion bereits vorhandener Informationen
| Ergänzt sichtbar neue Erscheinungsdetails im finalen Frame
|-
| Hardware
| Funktionsabhängig; viele Teile laufen auf älteren RTX-Generationen, Multi Frame Generation auf RTX 50
| Zum Start nur GeForce RTX 50 und entsprechende Laptop-GPUs
|-
| Unreal Engine
| Offizielles NVIDIA-DLSS-Plugin
| Integration über NVIDIA Streamline oder ein UE5-Plugin
|}

DLSS 5 ersetzt DLSS 4/4.5 daher nicht vollständig. Ein Spiel kann Super Resolution, Ray Reconstruction, Multi Frame Generation und DLSS 5 gemeinsam verwenden.

== Vorteile von DLSS 5 ==

* Komplexe Licht- und Materialeffekte können mit geringerem klassischen Renderaufwand sichtbar werden.
* Künstler können Intensität, Ton und Masken steuern.
* Rasterisierung, Raytracing und Pathtracing können als Ausgangsbasis dienen.
* Die Berechnung läuft lokal auf der GPU und ist an die vom Spiel vorgegebene Szene gebunden.

== Nachteile und offene Fragen ==

* Zum Start ist eine RTX-50-GPU erforderlich.
* Das Verfahren kann den beabsichtigten Grafikstil verändern, wenn Modelle und Regler unpassend gewählt werden.
* Kleine Fehler können als erfundene Materialdetails, instabile Kanten oder zeitliche Artefakte sichtbar werden.
* Die Qualität hängt stark vom Ausgangsbild und den gelieferten Engine-Daten ab.
* Die zusätzliche Renderstufe kostet Rechenzeit; hohe beworbene FPS entstehen meist erst zusammen mit Super Resolution und Multi Frame Generation.
* SDK, Modelle und Laufzeit sind proprietär.
* Kurz nach Veröffentlichung fehlen noch breite unabhängige Vergleiche in unterschiedlichen Spielszenen.

== Verfügbarkeit ==

Der erste angekündigte Titel ist ''NBA 2K27''. Weitere genannte Spiele sind unter anderem ''Starfield'', ''Hogwarts Legacy'', ''Assassin’s Creed Shadows'', ''Resident Evil Requiem'' und ''The Elder Scrolls IV: Oblivion Remastered''. Unterstützung muss vom jeweiligen Spielentwickler integriert und abgestimmt werden.

== Quellen ==

* [https://research.nvidia.com/labs/adlr/DLSS5/ NVIDIA Research: DLSS 5 – Generative Neural Rendering]
* [https://www.nvidia.com/en-us/geforce/news/dlss-5-3d-guided-neural-rendering/ NVIDIA: DLSS 5 und 3D-Guided Neural Rendering]
* [https://research.nvidia.com/labs/adlr/DLSS4/ NVIDIA Research: DLSS 4]
* [https://developer.nvidia.com/rtx/dlss NVIDIA Developer: DLSS-Technologien und Unreal-Plugin]

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Grafik]]
[[Kategorie:NVIDIA]]
[[Kategorie:Künstliche Intelligenz]]

Render Hardware Interface (RHI)

2026-09-03T14:19:45Z

Elaina:

Global Shaders und Compute Shader

2026-09-03T14:19:36Z

Elaina:

UE5 Heterogeneous Multi-GPU

2026-09-03T14:19:28Z

Elaina:

{{Hinweis|Stand: Unreal Engine 5.8. Dieser Artikel fasst die aktuelle offizielle Epic-Dokumentation zusammen.}}

'''UE5 Heterogeneous Multi-GPU''' ist ein experimentelles Projekt zur herstellerunabhängigen Nutzung mehrerer unterschiedlicher Grafikkarten in [[Unreal Engine 5]]. NVIDIA-, AMD- und Intel-GPUs sollen gleichzeitig verschiedene, voneinander unabhängige Aufgaben übernehmen können.

{| class="wikitable"
|+ Projektstatus
|-
! Stand
| 2. September 2026
|-
! Engine-Version
| Unreal Engine 5.8
|-
! Status
| '''Proof of Concept erfolgreich'''
|-
! Primary GPU
| NVIDIA GeForce RTX 5060 Laptop GPU
|-
! Worker GPU
| Intel(R) UHD Graphics
|}

== Projektziel ==

Ziel ist eine Multi-GPU-Erweiterung für Unreal Engine 5, die weder identische GPUs noch einen Linked-Adapter-Verbund voraussetzt. Vorgesehen sind unter anderem Kombinationen wie:

* NVIDIA + Intel
* NVIDIA + AMD
* langfristig NVIDIA + AMD + Intel

Die Architektur soll grundsätzlich '''N GPUs''' unterstützen und nicht fest auf zwei Grafikkarten beschränkt sein.

== Grundprinzip ==

Unreal Engine verwendet weiterhin eine normale Grafikkarte als '''Primary GPU''' für das reguläre Rendering. Weitere erkannte Grafikkarten werden als '''Worker GPUs''' registriert. Jeder Worker erhält ein unabhängiges Grafik-Device und eigene Arbeitswarteschlangen.

* '''Primary GPU:''' normales Unreal-Rendering über das reguläre D3D12-RHI
* '''Worker GPUs:''' separate Devices für gezielt ausgelagerte Aufgaben
* '''Geplante Workloads:''' Scene Captures, Spiegel, CCTV-Kameras, Minimap-Rendering, Compute-Aufgaben und weitere unabhängige Render-Workloads
* '''Automatische Verteilung:''' Ein späterer Benchmark soll GPUs und Transferwege bewerten und eine sinnvolle Aufgabenverteilung empfehlen.
* '''Manuelle Kontrolle:''' Konfiguration und Overrides sollen weiterhin möglich bleiben.

== Aktuelles Testsystem ==

{| class="wikitable"
! Rolle
! GPU
|-
| Primary
| NVIDIA GeForce RTX 5060 Laptop GPU
|-
| Worker
| Intel(R) UHD Graphics
|}

== Aktueller Entwicklungsstand ==

* Unreal erkennt beide physischen D3D12-Adapter und filtert den Microsoft Basic Render Driver heraus.
* Die RTX 5060 wird als Primary GPU und die Intel UHD als Worker GPU erkannt.
* Für die Intel-GPU wird unabhängig vom normalen Unreal-RHI ein eigenes <code>ID3D12Device</code> erzeugt.
* Für das Worker-Device wird eine eigene D3D12 Direct Command Queue erstellt.
* Eigene Command Lists können auf der Intel-GPU ausgeführt und über einen Fence erfolgreich bestätigt werden.
* Ein realer Datentest kopiert 256 Byte Testdaten über den Pfad Upload → GPU Buffer → Readback.
* Die zurückgelesenen Daten stimmen vollständig mit dem ursprünglichen Testmuster überein. Der Worker-Buffer-Copy-Test meldet '''PASSED'''.

Damit läuft UE5.8 regulär auf der RTX 5060, während die Intel UHD gleichzeitig über einen vollständig separaten D3D12-Ausführungspfad angesprochen und tatsächlich für GPU-Arbeit verwendet wird.

== Aktuelle Architektur ==

<pre>
UE5.8
|
+-- normales UE-D3D12-RHI
| +-- RTX 5060 (Primary)
|
+-- ExperimentalMultiGPU
+-- Intel UHD (Worker)
+-- eigenes ID3D12Device
+-- eigene Direct Command Queue
+-- eigene Command Lists
+-- Fence-Synchronisation
+-- Buffer-Copy / Readback
</pre>

== Modulare Code-Struktur ==

Der experimentelle Code ist bewusst in kleine, klar abgegrenzte Komponenten aufgeteilt. Das erleichtert die Weiterentwicklung, Fehlersuche und spätere Portierung.

<pre>
ExperimentalMultiGPU/
+-- MultiGPUAdapterRegistry.*
+-- MultiGPUD3D12Device.*
+-- MultiGPUD3D12Queue.*
+-- MultiGPUD3D12Command.*
+-- MultiGPUD3D12Transfer.*
</pre>

== Nächste Entwicklungsstufe ==

Als nächster Meilenstein soll die Worker-GPU erstmals eine echte Compute-Berechnung durchführen. Dafür soll ein von Unreals normaler Shader-Pipeline kompilierter Compute Shader auf dem unabhängigen Worker-Device ausgeführt werden.

# UE-Shader-Blob verwenden, statt einen separaten DXC-Hack einzubauen
# Root Signature für das Worker-Device erzeugen
# Compute Pipeline State auf der Worker-GPU erstellen
# Testdaten verarbeiten, zurücklesen und auf der CPU verifizieren
# Ressourcen- und Transfer-Benchmarks durchführen
# Cross-Adapter-Datenaustausch erproben

== Langfristige Ziele ==

* Automatische Erkennung und Bewertung beliebiger GPU-Kombinationen
* Benchmarks für Raster-, Compute-, Raytracing- und Transferleistung
* Automatische Empfehlung für Primary- und Worker-Rollen
* Manuelle Zuweisung einzelner Workloads zu bestimmten GPUs
* Unterstützung mehrerer Worker mit unterschiedlichen Update-Raten
* Direkte Cross-Adapter-Transfers, sofern möglich, mit Fallback über den System-RAM
* Vulkan-Implementierung für Linux
* Gleichzeitiger Betrieb von NVIDIA-, AMD- und Intel-GPUs in einem UE-Projekt

== Versionsverwaltung und Backup ==

Die Änderungen werden separat in einem kleinen Git-Repository dokumentiert. Zusätzlich existiert ein vollständiges NAS-Backup der gebauten UE5.8-Engine als Rücksprungpunkt.

<pre>
Z:\03 Development\UE\UE5.8-MGPU\
+-- Git\
+-- FullBackup\
</pre>

'''Zusammenfassung:''' Der Proof of Concept ist erfolgreich. Eine heterogene Worker-GPU führt bereits echte D3D12-Datenarbeit über ein vom regulären Unreal-RHI unabhängiges Device aus.

[[Kategorie:Unreal Engine 5]]
[[Kategorie:Multi-GPU]]
[[Kategorie:Direct3D 12]]
[[Kategorie:Experimentell]]

Vorlage:Hinweis

2026-09-03T14:19:19Z

Elaina: Die Seite wurde neu angelegt: „<div style="border-left: 4px solid #36c; background: #f8f9fa; padding: 0.7em 1em; margin: 0 0 1em 0;"> '''Hinweis:''' {{{1|}}} </div><noinclude> Diese Vorlage stellt einen kurzen Hinweis optisch hervorgehoben dar. == Verwendung == <pre>{{Hinweis|Text des Hinweises}}</pre> </noinclude>“

<div style="border-left: 4px solid #36c; background: #f8f9fa; padding: 0.7em 1em; margin: 0 0 1em 0;">
'''Hinweis:''' {{{1|}}}
</div><noinclude>
Diese Vorlage stellt einen kurzen Hinweis optisch hervorgehoben dar.

== Verwendung ==
<pre>{{Hinweis|Text des Hinweises}}</pre>
</noinclude>

Paralleles Rendering und RHI-Thread

2026-09-03T13:02:55Z

Elaina: Die Seite wurde neu angelegt: „{{Hinweis|Stand: Unreal Engine 5.8. Dieser Artikel fasst die aktuelle offizielle Epic-Dokumentation zusammen.}} '''Paralleles Rendering''' verteilt die CPU-Arbeit des Renderers auf mehrere Threads. Der '''RHI Thread''' ist dabei der Thread, der Unreal-Befehle über das ''Render Hardware Interface'' (RHI) in Aufrufe der jeweiligen Grafik-API wie DirectX 12 oder Vulkan übersetzt. Das ist CPU-Parallelität und nicht automatisch Multi-GPU-Rendering. == Die…“

Render Dependency Graph (RDG)

2026-09-03T13:02:37Z

Elaina: Die Seite wurde neu angelegt: „{{Hinweis|Stand: Unreal Engine 5.8. Dieser Artikel fasst die aktuelle offizielle Epic-Dokumentation zusammen.}} Der '''Render Dependency Graph''' ('''RDG''', auch Render Graph) organisiert Renderarbeit als Graph aus ''Passes'' und Ressourcen. Ein Pass ist ein Arbeitsschritt auf CPU/GPU; Ressourcen sind vor allem Texturen und Buffer. Statt Übergänge, Lebensdauer und Synchronisation überall von Hand zu steuern, beschreibt der Code, welche Ressourcen ein…“