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:

1. Der Onscreen-Knoten läuft auf der primären GPU, rendert beispielsweise das Outer Frustum, setzt das Endbild zusammen und gibt es aus.
2. Der Offscreen-Knoten läuft headless, also ohne sichtbares Fenster, auf der zweiten GPU und rendert beispielsweise das Inner Frustum.
3. 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:

1. Im nDisplay Config Asset Configuration > Render Frame Settings > Multi GPU Mode einschalten.
2. Am Viewport oder an der ICVFX-Kamera den gewünschten GPUIndex setzen.
3. In Switchboard Number of GPUs auf die vorhandene GPU-Anzahl setzen.

Direkter Vergleich

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

• Epic: Multi-Process Rendering (UE 5.8, abgerufen am 4. September 2026)
• Epic: Getting Started with Multi-Process Rendering (UE 5.8, abgerufen am 4. September 2026)
• Epic: nDisplay Overview – Multi-GPU Support (UE 5.8, abgerufen am 4. September 2026)