Mesh Shader und Meshlets: Geometrie für kooperative Verarbeitung organisieren

Geometrie als kooperative Arbeitslast behandeln

Ein Mesh Shader lässt eine Workgroup eine begrenzte Menge an Vertices und Primitives für die Rasterisierung aufbauen. Die Threads können beim Dekodieren, Transformieren und Auswählen von Primitives zusammenarbeiten, bevor das Ergebnis ausgegeben wird. Eine optionale Task-Stufe kann festlegen, wie viele Mesh-Workgroups gestartet werden, und gibt ihnen eine Payload mit. Das Vulkan-Feature-Design beschreibt diese Aufgaben und ihre Grenzen. [1]

Meshlets sind eine verbreitete Organisationsform für Assets in diesem Modell: kleine Dreiecks-Cluster mit einer lokalen Vertexmenge. Es ist nicht Voraussetzung, dass jeder Mesh Shader ein identisches vorgefertigtes Format verarbeitet; prozedurale Geometrie ist ein weiterer Anwendungsfall.

Cluster gezielt aufbauen

Ein Meshlet benötigt typischerweise lokale Dreiecksindizes, eine Zuordnung zu den Vertexdaten und Metadaten wie Bounds. Kompakte lokale Indizes können den Speicherbedarf der Topologie senken, und räumlich kohärente Cluster können kollektives Verwerfen sinnvoll machen. Das NVIDIA-Sample liefert Statistiken zu Meshlet-Aufbau, Auslastung und Culling. [2]

Die Clustering-Kriterien sind gemeinsam zu wählen. Wer allein die Dreiecksbelegung maximiert, erhält unter Umständen lose Bounds oder eine schlechte Wiederverwendung von Vertices. Sehr kleine Cluster erhöhen den Overhead für Metadaten und Scheduling; sehr grosse Cluster verbrauchen mehr Ressourcen und enthalten womöglich viel Geometrie, die nur deshalb nicht verworfen wird, weil ein Teil des Clusters sichtbar ist.

Rechenbeispiel: die Remap-Tabelle einrechnen

Angenommen, ein illustratives Speicherformat beschreibt einen Cluster mit 48 eindeutigen Vertices und 80 Dreiecken. Bei einem Byte pro lokalem Dreiecksindex ergeben sich 80 * 3 = 240 Bytes. Ein Remap mit einem 32-Bit-Index auf globale Vertices pro lokalem Vertex kostet 48 * 4 = 192 Bytes. Zusammen belegen diese Arrays 432 Bytes.

Eine herkömmliche Liste mit 32-Bit-Indizes auf globale Vertices für jede Dreiecksecke kostet 80 * 3 * 4 = 960 Bytes. Dieser Vergleich lässt Header, Alignment, Bounds und Vertexattribute ausser Acht. Auch doppelte Vertexverweise zwischen Clustern sind nicht berücksichtigt. Der Vergleich veranschaulicht eine Formatberechnung – kein von der API vorgeschriebenes Layout und keinen gemessenen Performancegewinn.

Zuerst die ausgegebene Geometrie validieren

Am Anfang steht ein bekanntes Mesh bei deaktiviertem Verwerfen. Die Cluster werden unterschiedlich eingefärbt, und Positionen, Winding, Materialzuordnung und interpolierte Attribute werden mit einem herkömmlichen Pfad verglichen. Zu prüfen ist, ob deklarierte Maxima, tatsächliche Ausgabezahlen und Primitive-Indizes übereinstimmen. Unterstützte Features, Limits und Implementierungspräferenzen des Geräts sind abzufragen, statt die bevorzugte Clustergrösse eines einzelnen Herstellers fest einzucodieren. [1][2]

Danach werden kooperatives Verwerfen und Optimierungen beim Laden von Attributen schrittweise ergänzt. Zu testen sind verformte Meshes, Cluster an Objektgrenzen und Szenen, in denen fast alle Primitives erhalten bleiben. Synchronisierung und Besitz gemeinsam genutzter Daten innerhalb der Workgroup sind explizit zu halten.

Die Gesamtkosten beurteilen

Mesh Shading kann Arbeit verlagern und deren Granularität verändern; ein schnelleres Frame ist damit nicht garantiert. Ausgabeattribute, Shared Memory, Registerdruck und der Overhead der Task-Stufe können die Einsparungen aufzehren. [2] Zu vergleichen sind repräsentative Materialien und Sichtbarkeitsmuster, auch bei Objekten geringer Komplexität. Wo das Feature nicht verfügbar ist, ist ein geeigneter Rendering-Pfad beizubehalten; Zeit für die Cluster-Erzeugung und Speicherbedarf der Assets sind als Teil des Implementierungsbudgets zu betrachten.

Quellen

• [1] VK_EXT_mesh_shader Feature Proposal — Khronos Group, Vulkan feature design.
• [2] Mesh Shader CAD Scene Sample — NVIDIA nvpro-samples, original implementation.