GPU-gesteuertes Indirect Rendering: Draw-Workloads auf dem Gerät erzeugen

Draw-Entscheidungen nahe an die Szenendaten verlegen

GPU-gesteuertes Indirect Rendering lässt Compute-Arbeit bestimmen, welche Draws oder Instanzen die Grafikpipeline verarbeitet. Die CPU bereitet weiterhin Ressourcen vor, wählt kompatible Pipeline-Zustände aus und übergibt die Arbeit. Der eigentliche Gewinn: Sichtbarkeitsentscheidungen und Draw-Parameter können auf dem Gerät bleiben, sodass vor dem Zeichnen kein Readback zur CPU nötig ist. Khronos und Microsoft stellen Originalbeispiele für diese Anordnung bereit. [1][2]

Zwei Muster zur Befehlserzeugung

Ein Ansatz reserviert feste Command-Slots und setzt die Instanzanzahl eines unsichtbaren Draws auf null. Ein anderer verdichtet sichtbare Instanzkennungen oder Draw-Commands in einem Ausgabepuffer (Compaction) und erzeugt eine Anzahl. Die Compaction bedeutet zusätzlichen Verwaltungsaufwand, erspart aber die Verarbeitung leerer Einträge. Commands nach dem Zustand gruppieren, den der gewählte Indirect-Mechanismus gemeinsam nutzen kann; ein beliebiger Material- oder Pipeline-Wechsel wird von einem gewöhnlichen Draw-Command nicht automatisch abgebildet. [1][2]

Rechenbeispiel: Die Kapazität richtet sich nach der Kandidatenmenge

Angenommen, eine beispielhafte Szene hat 10000 Kandidaten-Instanzen. Ein Puffer für sichtbare Kennungen mit 4 Bytes pro Kennung benötigt 40000 Bytes, rund 39,1 KiB, falls jeder Kandidat sichtbar werden kann. Darin nicht enthalten sind Commands, Zähler und Alignment.

Zeigt der aktuelle Frame 3500 Instanzen, schreibt Compute diese Kennungen und die passenden Draw-Anzahlen. Nur für 3500 Einträge zu allokieren, weil das gestern das Maximum war, ist unsicher. Einen Schreibzugriff ausserhalb der Puffergrenzen zu verhindern, indem spätere Einträge verworfen werden, führt trotzdem zu fehlender Geometrie. Stattdessen die benötigte Kapazität reservieren, begrenzte Chunks verarbeiten oder einen vollständigen Fallback bereitstellen. Es handelt sich um Kapazitätsberechnungen, nicht um Leistungsmessungen.

Pipeline aufbauen und validieren

Mit CPU-Sichtbarkeitsergebnissen als Referenz beginnen. Sichtbare Kennungen und fertige Bilder vergleichen, bevor Occlusion oder mehrere Materialgruppen hinzukommen. Command-Layout, Index-Offsets, Base Vertices, Instanz-Lookup und das Zurücksetzen der Zähler prüfen. Leere Sichtbarkeit, volle Sichtbarkeit und die Kapazitätsgrenze gezielt testen.

Compute-Schreibzugriffe müssen sowohl für das Lesen der Indirect-Commands als auch für jede Shader-Stufe verfügbar gemacht werden, die die erzeugten Instanzdaten verwendet. Eine Abhängigkeit, die nur die Indirect-Argumente abdeckt, erfasst keine davon unabhängigen Shader-Lesezugriffe. Getrennte Queues erfordern zudem eine passende Synchronisation zwischen den Queues und gegebenenfalls einen Ownership-Transfer. Khronos dokumentiert die relevanten Zugriffsmuster von Producer und Consumer. [3]

Ressourcen am Leben halten und keinen Puffer überschreiben, der noch von einem früheren Frame verwendet wird. In einem GPU-Capture die erzeugten Anzahlen und die tatsächlich ausgeführten Commands prüfen.

Gesamte Frame-Kosten bewerten

Die CPU-Submission-Zeit zusammen mit GPU-Culling, Compaction und Rendering messen. Zusätzliche Compute-Arbeit und Speichertraffic können den geringeren Submission-Aufwand übersteigen, besonders in kleinen Szenen. Indirect Drawing beseitigt weder aufwendiges Shading, noch löst es die Reihenfolge bei Transparenz, noch garantiert es eine effiziente Materialgruppierung. Geräte-Features und Limits für die Command-Anzahl prüfen und einen unterstützten Fallback beibehalten. Das Design einsetzen, wenn das gemessene Frame-Verhalten die Komplexität rechtfertigt.

Quellen

• [1] GPU Rendering and Multi-Draw Indirect — Khronos Group, Vulkan Samples.
• [2] Indirect drawing and GPU culling — Microsoft, Direct3D-Dokumentation und Beispiel.
• [3] Synchronization Examples — Khronos Group, Vulkan-Dokumentation.