Quelltext der Seite Paralleles Rendering und RHI-Thread

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