Render Graphs: Abhängigkeiten deklarieren und Ressourcenlebensdauern steuern

Den Frame als Datenfluss beschreiben

Ein Renderer lässt sich schwer ändern, wenn die Zuständigkeit für Ressourcen nur implizit festgelegt ist. Ein Post-Processing-Pass liest womöglich ein Image, das ein anderes Feature unerwartet überschreibt, oder hält eine temporäre Textur für den gesamten Frame am Leben. Deshalb zuerst für jeden Pass die Eingaben, Ausgaben und nach aussen sichtbaren Effekte beschreiben. Dieser Vertrag macht die Abhängigkeiten eines neuen Features prüfbar, bevor dessen Befehle ausgeführt werden.

Deklaration und Ausführung trennen

Ein Render Graph erfasst Passes und Ressourcennutzung und leitet daraus einen Ausführungsplan ab. Der RDG von Unreal kann ungenutzte Arbeit auslassen (Culling), transiente Ressourcen verwalten und die Synchronisation planen. Er unterscheidet zwischen Ressourcen, deren Lebensdauer innerhalb des Graphen bleibt, und externen Ressourcen, die darüber hinaus bestehen. [1] Das Deklarieren eines Lese- oder Schreibzugriffs ist eine Korrektheitspflicht: Ein nicht deklarierter Zugriff gibt dem Planer ein unvollständiges Bild des Frames.

Ein Aliasing-Beispiel durchrechnen

Angenommen seien vier Passes in fester Reihenfolge. Der erste schreibt eine temporäre Maske von 8 MiB, der zweite liest deren endgültigen Inhalt. Erst danach legt der dritte ein Blur-Zwischenergebnis von 16 MiB an, das der vierte verarbeitet. Sind die Speicheranforderungen kompatibel und stellt die Ausführung sicher, dass sich die Nutzung nicht überschneidet, können sich die beiden temporären Ressourcen im Idealfall einen Speicherbereich von 16 MiB teilen, statt getrennte Bereiche mit zusammen 24 MiB zu belegen.

Diese Rechnung lässt den Allokations-Overhead und alle übrigen Frame-Ressourcen ausser Acht. Liest der vierte Pass zusätzlich die ursprüngliche Maske, überlappen sich die Lebensdauern, und die vorgesehene Wiederverwendung ist ungültig. Die Reihenfolge beim Aufzeichnen der Befehle auf der CPU beweist allein nicht, dass GPU-Zugriffe abgeschlossen sind. Stattdessen die tatsächliche Ressourcen-Timeline und die Abhängigkeiten prüfen.

Den Ressourcenvertrag validieren

Ressourcen nach ihrem Zweck benennen. Lese- und Schreibzugriffe sowie die betroffenen Subressourcen präzise deklarieren und festlegen, ob ein neu allokiertes Image gelöscht (cleared) oder vollständig überschrieben werden muss. Temporale History und andere persistente Daten unter ausdrücklich externer Zuständigkeit halten.

Graph-Visualisierung und API-Validierung nutzen und dabei Effekte einzeln aktivieren. Der Synchronisationsleitfaden von Vulkan beschreibt Pipeline-Barriers als Mittel, um festzulegen, welche Stages auf frühere Stages warten müssen. [2] Der Graph muss letztlich eine Synchronisation erzeugen, die zur zugrunde liegenden API passt. Zur Diagnose von Bildfehlern die Ausgabe mit einer Variante vergleichen, in der Aliasing oder asynchrones Scheduling deaktiviert ist; dieser Vergleich dient als Beleg, nicht als dauerhafte Lösung.

Den Scheduling-Kompromiss messen

Asynchrones Compute kann unabhängige Arbeit überlappen, doch gleichzeitig laufende Passes können um Ausführungskapazität oder Speicherbandbreite konkurrieren. Ihre überlappenden Lebensdauern können zudem die Möglichkeiten zur Speicherwiederverwendung verringern. GPU-Dauer, Spitzenwert der transienten Allokation und CPU-Aufzeichnungskosten am Ziel-Workload vergleichen.

Ressourcen-Historien aus einem normalen Frame, einem Auflösungswechsel und dem Übergang zu einem deaktivierten Effekt aufbewahren. Ein Graph, der einen Screenshot korrekt rendert, kann auf einem anderen Pfad dennoch einen Lesezugriff auf nicht initialisierte Daten oder eine unbeabsichtigte Verlängerung einer Lebensdauer enthalten. Erst optimieren, wenn für diese Pfade eine klare Regelung zu Zuständigkeit und Initialisierung besteht.

Quellen

[1] Render Dependency Graph — Epic Games.

[2] Vulkan synchronization guide — Khronos Group.