Quelltext der Seite Render Hardware Interface (RHI)

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