Quelltext der Seite Multi-Process Rendering und Multi-GPU

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