Apple Silicon TBDR: Was App-Entwickler tatsächlich bekommen

Apple-Silicon-GPUs rendern nicht so, wie andere GPUs rendern. Apples Metal-Dokumentation beschreibt die Architektur namentlich: „Die GPUs in Apple Silicon implementieren eine Rendering-Technik namens Tile-Based Deferred Rendering (TBDR), die Leistung und Energieeffizienz optimiert.”¹ Die TBDR-Form ist der Grund, warum die Metal-4-API, der On-Device-ML-Stack und das Imageblock-und-Tile-Shader-Programmiermodell so existieren, wie sie existieren.

Die folgenden Abschnitte gehen die vier von Apple dokumentierten Features durch, die TBDR ermöglicht, und was jedes davon einer App bringt: Imageblocks, Tile-Shader, Raster Order Groups und die erweiterte Multisample-Antialiasing-Implementierung. Der frühere Beitrag zu Metal 4 Essentials behandelte die zentrale API-Oberfläche; der Fokus liegt hier auf dem GPU-Substrat, auf das diese Oberfläche zielt.

TL;DR

• TBDR teilt das Render-Ziel in Tiles auf, lässt viele davon parallel auf separaten GPU-Cores laufen und verzögert das Shading, bis die gesamte Geometrie für jedes Tile ausgewertet wurde.¹
• Tile-Speicher hat eine Bandbreite, die um ein Vielfaches schneller ist als Device-Memory, eine um ein Vielfaches geringere Latenz und deutlich niedrigere Energiekosten.¹
• A11 und neuere Apple-GPUs ergänzen Imageblocks, Tile-Shading, Raster Order Groups und Imageblock-Sample-Coverage-Control. Apps erreichen all das über Metal.¹
• Mit Imageblocks kann eine App benutzerdefinierte Per-Pixel-Datenstrukturen im Tile-Speicher definieren, Daten über Draws und Dispatches hinweg persistieren und Render- mit Compute-Arbeit in einem einzigen Pass mischen.¹
• Raster Order Groups synchronisieren Fragment-Threads, die auf dasselbe Pixel zielen, und beseitigen den Read-Modify-Write-Race, der reihenfolgeabhängiges Blending bricht.¹

Was TBDR tatsächlich ist

Apples Formulierung, wörtlich: „Die GPU teilt das Render-Ziel in ein Raster aus kleineren Regionen auf, die Tiles genannt werden. Sie verarbeitet jedes Tile mit einem ihrer GPU-Cores, oft viele gleichzeitig. Die GPU verzögert oder verschiebt die Rendering-Phase für jedes Tile so lange, bis sie die gesamte Geometrie für dieses Tile ausgewertet hat.”¹

Der Kontrast zu Immediate-Mode-(IM)-GPUs ist ebenfalls Apples Formulierung: „Eine IM-GPU verarbeitet Primitive wie Linien und Dreiecke vollständig, unabhängig davon, ob sie im Rendering sichtbar sind oder nicht.”¹ TBDR vermeidet diese Arbeit, indem zunächst die gesamte Geometrie für ein Tile gesammelt wird und dann nur das geshadet wird, was die Verdeckung übersteht. Apple stellt den Gewinn direkt fest: „Eine TBDR-GPU vermeidet unnötige Arbeit, indem sie die gesamte Geometrie eines Render-Passes gleichzeitig verarbeitet und nur die sichtbaren Primitive shadet.”¹

Tile-Speicher ist die Belohnung. Apple beschreibt seine Vorteile gegenüber Device-Memory:¹

• „Bandbreite, die um ein Vielfaches schneller ist als Device-Memory”
• „Zugriffslatenz, die um ein Vielfaches geringer ist als bei Device-Memory”
• „Energieverbrauch, der deutlich geringer ist als der Zugriff auf Device-Memory”

Zwei Render-Passes können sich auf der Hardware auch überlappen. Apple merkt an: „Während die GPU die letzten Phasen eines Render-Passes in den Tile-Speicher ausführt, kann sie die Vertex-Phase eines zukünftigen Render-Passes starten. Die GPU kann mehr Hardware-Blöcke gleichzeitig nutzen, indem sie beide Phasen parallel ausführt, weil sie tendenziell unterschiedliche Compute- und Speicherkomponenten verwenden.”¹

Das ist das Substrat. Alles Folgende baut darauf auf.

Imageblocks: Benutzerdefinierte Per-Pixel-Daten im Tile-Speicher

Apples Definition eines Imageblocks: „Imageblocks sind Tiles strukturierter Bilddaten, die im lokalen Speicher abgelegt sind und es Ihnen ermöglichen, Bilddaten im Tile-Speicher zu beschreiben, die Apple-GPUs effizient manipulieren können.”¹ Es handelt sich um 2D-Datenstrukturen mit Breite, Höhe und Pixeltiefe, und „jedes Pixel in einem Imageblock kann aus mehreren Komponenten bestehen, und Sie können jede Komponente als eigenen Bild-Slice adressieren.”¹ Apples Beispiel: ein Imageblock, der drei Bild-Slices für Albedo-, Specular- und Normal-Komponenten enthält.

Die Form, die Apple dokumentiert:¹

• Sowohl für Kernel- als auch für Fragment-Funktionen verfügbar.
• Persistieren über die Lebensdauer eines Tiles, über Draws und Dispatches hinweg.
• Bestehender Render-Code erstellt automatisch Imageblocks, die zu den Render-Attachment-Formaten passen.
• Apps können benutzerdefinierte Imageblocks in Shadern mit zusätzlichen Channels, Arrays und verschachtelten Strukturen definieren.
• Ein Fragment-Shader sieht nur die Imageblock-Daten an der Position dieses Fragments; ein Thread einer Compute-Funktion kann auf den gesamten Imageblock zugreifen.

Persistenz über Draws und Dispatches hinweg ist der operativ interessante Teil. Apples Formulierung: „Imageblock-Persistenz bedeutet, dass Sie Render- und Compute-Operationen in einem einzigen Rendering-Pass mit Tile-Shadern mischen können, wobei beide auf denselben lokalen Speicher zugreifen können. Sie können anspruchsvolle Algorithmen erstellen, die im lokalen GPU-Speicher verbleiben, indem mehrere Operationen innerhalb eines Tiles gehalten werden.”¹

Für eine App, die eine mehrstufige Rendering-Pipeline ausliefert (Deferred Shading, Screen-Space-Effekte, benutzerdefiniertes Blending), ist das Halten von Zwischenergebnissen im Tile-Speicher anstelle des Round-Trips durch Device-Memory das Per-Frame-Budget, das TBDR zurückgibt.

Tile-Shader: Render und Compute, derselbe Pass

Apples Formulierung von Tile-Shadern: „Tile-Shader sind Compute- oder Fragment-Funktionen, die als Teil eines Render-Passes ausgeführt werden. Sie ermöglichen Ihrer App, Daten zu berechnen und in Tile-Speicher zu speichern, der zwischen Render-Passes auf der GPU persistent ist.”¹

Das traditionelle GPU-Modell ist das, was Tile-Shader umgehen. Apples Worte: „Traditionelle GPUs trennen Rendering- und Compute-Befehle in unterschiedliche Passes. Diese Passes können typischerweise nicht direkt miteinander kommunizieren. Apps umgehen diese Einschränkung, indem sie die Ergebnisse eines Passes in Device-Memory speichern und diese Daten dann für den nächsten Pass zurückladen. In manchen Szenarien, etwa bei einem mehrphasigen Rendering-Algorithmus, kopieren Apps Zwischendaten viele Male in Device-Memory.”¹

Tile-Shader verlagern diese Zwischendaten in den Tile-Speicher. Apples dokumentierter Gewinn: „Apps, die Tile-Shader verwenden, können das Speichern von Zwischenergebnissen in Device-Memory vermeiden und Zeit sparen, indem sie Daten im schnelleren Tile-Speicher ablegen.”¹

Für Metal-4-Apps passen Tile-Shader zum vereinheitlichten MTL4ComputeCommandEncoder-Design, das im Metal 4 Essentials Beitrag behandelt wird. Die Encoder-Vereinheitlichung und das Tile-Shader-Programmiermodell sind dieselbe Architekturentscheidung, gelesen auf zwei Ebenen: Render-vs.-Compute-Grenzen aufzulösen, die auf traditionellen GPUs existieren, weil die Apple-GPU-Hardware sie nicht braucht.

Raster Order Groups: Reihenfolge nebenläufiger Fragment-Threads

Das Problem, das Raster Order Groups lösen, in Apples Worten: „Metal garantiert, dass die GPU in Draw-Call-Reihenfolge blendet, was die Illusion erzeugt, dass die GPU die Szene sequenziell rendert. … Die Fragment-Shader für jedes Dreieck laufen nebenläufig auf eigenen Threads. Der Fragment-Shader für das hintere Dreieck wird möglicherweise nicht vor dem Fragment-Shader für das vordere Dreieck ausgeführt, was für einen Shader problematisch sein kann, der die Ergebnisse aus dem Shader eines anderen Dreiecks für seine benutzerdefinierte Blending-Funktion benötigt. Aufgrund der Nebenläufigkeit kann diese Read-Modify-Write-Sequenz eine Race Condition erzeugen.”¹

Der Mechanismus: „Raster Order Groups überwinden diesen Zugriffskonflikt, indem sie Threads synchronisieren, die auf dieselben Pixelkoordinaten und dasselbe Sample zielen (wenn Sie Per-Sample-Shading aktivieren).”¹

Die Implementierungsoberfläche: „Um Raster Order Groups zu implementieren, annotieren Sie Pointer auf Speicher mit einem Attribut-Qualifier. Shader, die über diese Pointer auf Pixel zugreifen, laufen in Per-Pixel-Submission-Reihenfolge. Die Hardware wartet darauf, dass alle älteren Fragment-Shader-Threads, die sich mit dem aktuellen Thread überschneiden, fertig werden, bevor der aktuelle Thread fortfährt.”¹

Aktuelle Apple-GPUs erweitern den Mechanismus. Apples Worte: „Metal auf aktuellen Apple-GPUs erweitert Raster Order Groups um zusätzliche Fähigkeiten. Sie ermöglichen es Ihnen, einzelne Channels eines Imageblocks und Threadgroup-Memory zu synchronisieren. Sie können auch mehrere Order Groups erstellen, die Ihnen feinkörnigere Synchronisation bieten und minimieren, wie oft Ihre Threads auf Zugriff warten.”¹

Apples ausgearbeitetes Beispiel ist Deferred Shading. Der traditionelle zweiphasige Ansatz schreibt einen G-Buffer mehrerer Texturen in Device-Memory und liest sie dann für die Lighting-Phase zurück. Apples Formulierung: „Sie können den Bedarf an Zwischentexturen eliminieren, indem Sie mehrere Order Groups verwenden, um beide Render-Phasen zu einer zusammenzuführen. Halten Sie dazu den Geometry-Buffer in Tile-großen Stücken, damit sie im lokalen Imageblock-Speicher verbleiben können.”¹

Die Aufteilung, die Apple empfiehlt:¹

• Erste Order Group: die drei G-Buffer-Felder (Albedo, Normal, Depth).
• Zweite Order Group: das akkumulierte Lighting-Ergebnis.
• „Apple-GPUs können die beiden Gruppen separat ordnen, sodass ausstehende Schreibvorgänge in die zweite Gruppe die Lesevorgänge aus der ersten Gruppe nicht behindern.”¹

Zwei Threads synchronisieren sich am Ende der Ausführung weiterhin, um die Lichter zu akkumulieren. Der Gewinn ist, dass die nicht konfliktierenden Lesevorgänge nebenläufig statt seriell laufen.

MSAA, das einzigartige Samples pro Pixel verfolgt

Apples dokumentierte MSAA-Implementierung auf A11+-GPUs unterscheidet sich von der Lehrbuchbeschreibung. Apples Formulierung: „Die Hardware verfolgt, ob jedes Pixel die Kante eines Primitivs enthält, sodass sie Per-Sample-Blending nur dann ausführt, wenn nötig. Wenn ein anderes Primitiv die Samples innerhalb eines Pixels abdeckt, blendet die GPU nur einmal für das gesamte Pixel.”¹

Apples Beispiel zeigt die Optimierung. Ein Pixel, das von zwei sich überlappenden Dreieckskanten bedeckt wird, hat drei einzigartige Farben an vier Sample-Positionen. Apples Worte: „Apple-GPUs vor A11 blenden jedes der drei abgedeckten Samples des Pixels. Ab A11 blenden Apple-GPUs nur zweimal, weil zwei Samples dieselbe Farbe teilen.”¹

Die Farbreduktion geht weiter. Apple: „Apple-GPUs können die Anzahl einzigartiger Farben in einem Pixel reduzieren. Wenn die GPU beispielsweise ein opakes Dreieck über die früheren Dreiecke rendert, repräsentiert sie das Pixel durch eine einzige Farbe.”¹

Apps können die Implementierung mit Tile-Shadern erweitern. Apples dokumentierter Anwendungsfall: „Sie können einen benutzerdefinierten Resolve-Algorithmus implementieren, indem Sie die Sample-Coverage-Daten in den Tile-Shadern modifizieren. Betrachten Sie beispielsweise eine komplexe Szene, die separate Render-Phasen für opake und transluzente Geometrie enthält. Sie können einen Tile-Shader hinzufügen, der die Sample-Daten für die opake Geometrie auflöst, bevor die transluzente Geometrie geblendet wird.”¹

Der Tile-Shader läuft auf Daten im lokalen Speicher und kann Teil der Phase opaker Geometrie sein, sodass das Resolve im Tile-Speicher bleibt, anstatt einen separaten Pass zu durchlaufen.

Was das für die App-Architektur bedeutet

Drei Erkenntnisse, die sich aus Apples dokumentierter Oberfläche ergeben.

1. Tile-Speicher ist das Budget. Die vier obigen Features (Imageblocks, Tile-Shader, Raster Order Groups, Sample Coverage) existieren alle, um Arbeit im Tile-Speicher zu halten und aus dem Device-Memory herauszuhalten. Apples dokumentierte Zahlen: Bandbreite um ein Vielfaches schneller als Device-Memory, Latenz um ein Vielfaches geringer, Energie deutlich niedriger.¹ Eine App-Architektur, die dieses Budget respektiert, läuft schneller und kühler als eine, die es nicht tut.

2. Render und Compute sind keine getrennten Welten. Apples GPU trennt Render und Compute nicht in unterschiedliche Passes, wie es traditionelle GPUs tun. Imageblock-Persistenz und Tile-Shader ermöglichen es einer App, mehrphasige Algorithmen innerhalb eines einzigen Render-Passes auszuführen. Der vereinheitlichte Compute-Encoder von Metal 4 ist der API-seitige Ausdruck derselben architektonischen Tatsache.

3. Nebenläufigkeit ist der Standard; Reihenfolge ist das Opt-in. Raster Order Groups sind der Weg, mit dem eine App sagt: „Diese Read-Modify-Write-Sequenz hängt von der Reihenfolge ab.” Der Standard ist ungeordnete Nebenläufigkeit, was der natürlichen Form der GPU entspricht. Apps, die geordneten Zugriff für Blending, Transparenz oder G-Buffer-Schreibvorgänge benötigen, annotieren die spezifischen Pointer und lassen die Hardware die Threads sequenzieren.

Der vollständige Apple-Ecosystem-Cluster: die Metal-4-Kern-API für die parallele API-Oberfläche, die auf diese Hardware zielt; das Foundation Models On-Device LLM für das Framework, das ML auf demselben Silizium ausführt; Core ML On-Device-Inferenz für den breiteren ML-Stack. Der Hub befindet sich in der Apple Ecosystem Series.

FAQ

Ist TBDR spezifisch für Metal 4?

Nein. Apple-Silicon-GPUs haben TBDR über viele GPU-Generationen hinweg implementiert; Metal 4 ist die neue Kern-API-Oberfläche, die auf sie zielt. Die hier dokumentierten TBDR-Features (Imageblocks, Tile-Shader, Raster Order Groups, A11+-Sample-Coverage-Control) funktionieren über Metal sowohl mit den ursprünglichen MTL-präfixierten API-Typen als auch mit den MTL4-präfixierten Metal-4-Typen.¹

Was ist der Unterschied zwischen einem Imageblock und Threadgroup-Memory?

Apples dokumentierte Unterscheidung: „Threadgroup-Memory ist für unstrukturierte Daten geeignet, aber ein Imageblock ist für Bilddaten besser geeignet.”¹ Imageblocks tragen eine 2D-Struktur mit Breite, Höhe, Pixeltiefe und benannten Per-Pixel-Komponenten; Threadgroup-Memory ist eine flache Allokation. Apps, die strukturierte Bilddaten mit adressierbaren Slices benötigen, verwenden Imageblocks; Apps, die Scratch-Buffer für Compute-Kernels benötigen, verwenden Threadgroup-Memory.

Warum existieren Raster Order Groups, wenn Metal bereits Draw-Call-Order-Blending garantiert?

Metal garantiert das Erscheinungsbild sequenziellen Blendings, aber die GPU führt Fragment-Shader nebenläufig aus. Apples Formulierung: Ein Shader, der sein eigenes benutzerdefiniertes Blending gegen die Ergebnisse eines anderen Dreiecks ausführt, trifft auf eine Race Condition, weil die beiden Threads tatsächlich nicht sequenziell sind. Raster Order Groups sind der Mechanismus, der nur die Threads synchronisiert, die auf dasselbe Pixel zielen, und den Rest nebenläufig lässt.¹

Wann sollte ich meinen eigenen MSAA-Resolve-Algorithmus schreiben?

Apple dokumentiert einen konkreten Fall: eine Szene mit getrennten Phasen für opake und transluzente Geometrie, bei der das Resolve nach der opaken Phase, aber vor dem transluzenten Blending läuft.¹ Für die meisten Apps erledigt die in der Hardware eingebaute MSAA-Implementierung die Arbeit; benutzerdefinierte Resolves sind ein Werkzeug für die spezifischen Grenzfälle, die Apples Dokumentation beschreibt.

Wie spart Apples MSAA-Optimierung Arbeit?

Apples Hardware verfolgt die Anzahl einzigartiger Samples pro Pixel, während sie neue Primitive rendert. Apples Beispiel: Ein Pixel, das von zwei Dreieckskanten bedeckt wird, hat drei einzigartige Farben an vier Sample-Positionen; A11+-GPUs blenden zweimal statt dreimal, weil zwei Samples eine Farbe teilen, und ein späteres opakes Dreieck reduziert das Pixel zurück auf eine einzige Farbe.¹ Die Optimierung läuft auf Hardware-Ebene; Apps erhalten sie ohne API-Änderungen.

Ist die Apple-GPU-Architektur außerhalb der TBDR-Seite irgendwo dokumentiert?

Apples „Apple silicon”-Thema in der Metal-Dokumentation verlinkt auf die TBDR-Seite, die diesem Beitrag zugrunde liegt. Apples WWDC-Sessions zu Metal behandeln ebenfalls GPU-Architekturdetails, und die Metal Shading Language Specification deckt die Shader-Ebene ab. Apple hat die zugrunde liegenden Silizium-Details (Cluster-Anzahlen, ALU-Breiten, Spezifika der Raster-Engine) für eine bestimmte Apple-GPU-Generation nicht in der Entwicklerdokumentation veröffentlicht; behandeln Sie jede solche Zahl, die außerhalb von developer.apple.com gefunden wird, als unbestätigt.

Referenzen