Render Hardware Interface (RHI)

Hinweis: Stand: Unreal Engine 5.8. Dieser Artikel fasst die aktuelle offizielle Epic-Dokumentation zusammen.

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.

Artikelstatus

Bezugsstand	Unreal Engine 5.8
Letzte Aktualisierung	2. September 2026
Modul	RHI
Zentrale Header	DynamicRHI.h, RHICommandList.h, RHIResources.h

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

Spiel- und Engine-Systeme
        |
Renderer / Render Dependency Graph
        |
RHI-Befehle und RHI-Ressourcen
        |
plattformabhängiges RHI-Backend
        |
Direct3D 12 / Vulkan / Metal
        |
GPU und Treiber

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

FDynamicRHI 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 FRHIBuffer ist nicht selbst ein ID3D12Resource; das D3D12-Backend verwaltet darunter das native Objekt.

RHI-Ressourcen

Viele GPU-Objekte werden als von FRHIResource abgeleitete Typen dargestellt.

RHI-Typ	Aufgabe
FRHIBuffer	Allgemeiner GPU-Buffer mit Größe, Stride und Nutzungsflags
FRHITexture	Texturressource einschließlich Format, Ausdehnung und Mip-Struktur
FRHIShaderResourceView (SRV)	Lesende Sicht auf eine Ressource für Shader
FRHIUnorderedAccessView (UAV)	Schreibende beziehungsweise ungeordnet lesend-schreibende Sicht
FRHIUniformBuffer	Gebündelte konstante Shader-Parameter
FRHIGPUFence	GPU-seitiger Synchronisationspunkt
FRHIGPUBufferReadback	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

• FRHIComputeCommandList stellt die gemeinsame Compute-Schnittstelle bereit.
• FRHICommandList erweitert diese um Grafikbefehle, beispielsweise Render Passes und Draw-Aufrufe.
• FRHICommandListImmediate ist die unmittelbare Haupt-Command-List. Sie sollte nicht ohne Not verwendet werden, wenn parallele Ausführung erhalten bleiben soll.
• FRHICommandListExecutor 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:

1. Der Game Thread aktualisiert die Spielwelt und stößt Rendering-Arbeit an.
2. Der Render Thread verarbeitet die Render-Szene und zeichnet plattformunabhängige RHI-Befehle auf.
3. Der RHI Thread kann diese Befehle für das aktive Backend übersetzen und an die Grafik-API weitergeben.
4. 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:

• FRHIGraphicsPipelineState für Grafik-Pipelines
• FRHIComputePipelineState für Compute-Pipelines
• FRHIRayTracingPipelineState 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:

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 ID3D12Device mit eigener Direct Command Queue, eigenen Command Lists und eigener Fence-Synchronisation angesprochen.

UE-Renderer
    |
    +-- reguläres D3D12-RHI --> RTX 5060 (Primary)
    |
    +-- ExperimentalMultiGPU --> separates ID3D12Device
                                  --> Intel UHD (Worker)

Dieser Worker-Pfad ist nicht automatisch Bestandteil von GDynamicRHI. 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

• Graphics Programming Overview – Epic Games, UE 5.8
• RHI API Reference – Epic Games, UE 5.8
• FDynamicRHI – API-Referenz, Epic Games, UE 5.8
• FRHICommandList – API-Referenz, Epic Games, UE 5.8
• FRHIBuffer – API-Referenz, Epic Games, UE 5.8
• FRHITexture – API-Referenz, Epic Games, UE 5.8
• 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.