Tile-Based GPUs: Lade- und Speicheroperationen von Attachments bewusst wählen

Ein Attachment als Daten mit Lebensdauer behandeln

Eine Tile-Based GPU verarbeitet kleine Bereiche des Framebuffers in lokalem Speicher. Wird alter Attachment-Inhalt wiederhergestellt oder werden Zwischenergebnisse herausgeschrieben, kann Datenverkehr auf den externen Speicher entstehen. Über die Lade- und Speicheroperationen eines Attachments erfährt die Implementierung, welche Inhalte an den Grenzen des Renderings relevant sind. Die Erläuterung von Arm für Entwickler zeigt, warum diese Wahl die Bandbreite auf mobilen GPUs spürbar beeinflussen kann. [1]

Für jedes Color-, Depth- und Stencil-Attachment ist zu klären, wer den Anfangsinhalt erzeugt und wer das Endergebnis benötigt. Ein Depth-Buffer, der nur innerhalb eines einzelnen Rendering-Intervalls verwendet wird, stellt andere Anforderungen als eine Tiefe, die spätere Effekte samplen.

Den Anfangszustand anhand der tatsächlichen Lesezugriffe wählen

LOAD verwenden, wenn der bisherige Inhalt erhalten bleiben muss. CLEAR verwenden, wenn ein definierter, einheitlicher Anfangswert nötig ist. DONT_CARE nur verwenden, wenn der bisherige Inhalt nicht gebraucht wird und jeder später gelesene Wert angemessen initialisiert wird. Vulkan definiert den verworfenen Anfangsinhalt innerhalb der Render Area als undefiniert. [2]

Ein Draw, der wie ein Vollbild-Draw aussieht, belegt nicht, dass alles überschrieben wurde: Depth-Rejection, Scissors, Schreibmasken oder Blending können weiterhin Abhängigkeiten vom früheren Inhalt erhalten. Auf geeigneter Tile-Hardware kann ein Clear über die Attachment-Operation den lokalen Tile-Speicher initialisieren, ohne dass das vorherige Bild wiederhergestellt wird. [1]

Durchgerechnetes Beispiel: Grössenordnung des Transfers abschätzen

Ein beispielhaftes Attachment mit 1920 mal 1080 Pixeln und 4 Bytes pro Pixel umfasst 1920 * 1080 * 4 = 8294400 Bytes. Ein vollständiger Ladevorgang plus ein vollständiger Speichervorgang übertragen in einem unkomprimierten Rechenmodell 16588800 Bytes.

Bei 60 Frames pro Sekunde ergibt das 16588800 * 60 = 995328000 Bytes pro Sekunde, rund 0,995 GB/s. Das ist weder gemessene Bandbreite noch eine zugesicherte Einsparung: Kompression, Caches, partielle Render Areas und Implementierungsentscheide verändern den tatsächlichen Datenverkehr. Die Rechnung zeigt, warum ein an sich unnötiger Hin-und-zurück-Transfer eines Attachments eine Untersuchung verdient.

Endinhalte nur dort erhalten, wo es nötig ist

Ergebnisse speichern, die für die Präsentation, späteres Rendering oder einen Readback gebraucht werden. Wird der Inhalt eines Attachments nicht mehr benötigt, kann eine verwerfende Store-Operation vermeiden, dass er erhalten bleibt. Der DONT_CARE-Store von Vulkan macht diese Inhalte undefiniert. Die Operation NONE hat eine andere Semantik und darf nicht als Weg verstanden werden, frisch geschriebene Daten für einen späteren Pass zu erhalten. [3]

Bei geeigneten temporären Attachments sind Transient Usage und, soweit unterstützt, Lazy Allocation zu prüfen. Kompatible Arbeit zusammenhalten, wenn dies lokale Wiederverwendung erlaubt; dabei die tatsächliche Ausführung verifizieren, statt anzunehmen, dass jeder logische Pass zusammengeführt wird. Lesezugriffe auf benachbarte Pixel können einen anderen Speicherpfad erfordern. [1]

Korrektheit prüfen, bevor Zähler interpretiert werden

Nach Änderungen an den Attachment-Operationen sind partielle Abdeckung, Overlays, Depth-Konsumenten und abweichende Ausgabegrössen zu testen. Das Endbild und alle Zwischendaten, die spätere Passes verwenden, sind zu kontrollieren. Anschliessend werden auf dem Zielgerät externe Lese- und Schreibzugriffe zusammen mit der GPU-Zeit verglichen. Geringerer Datenverkehr ist ein wertvoller Hinweis, doch Geometrie, Shading oder Synchronisation können den Frame weiterhin dominieren. Die Entscheide zur Lebensdauer sollten dokumentiert bleiben, damit ein neu hinzugefügter Konsument sich nicht unbemerkt auf verworfene Inhalte verlässt.

Quellen

• [1] Picking the Most Efficient Load/Store Operations — Attilio Provenzano, Arm.
• [2] VkAttachmentLoadOp — Khronos Group, Vulkan-Spezifikation.
• [3] VkAttachmentStoreOp — Khronos Group, Vulkan-Spezifikation.