Quelltext der Seite DirectX 12 Multiadapter – 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]]