Mesh shaders et meshlets : organiser la géométrie pour un traitement coopératif

Traiter la géométrie comme une charge de travail coopérative

Un mesh shader permet à un workgroup de construire un ensemble borné de sommets et de primitives destiné à la rasterisation. Les threads peuvent coopérer pour le décodage, la transformation et la sélection des primitives avant d'émettre le résultat. Un étage task optionnel peut décider du nombre de workgroups mesh à lancer et leur transmettre un payload. La conception de la fonctionnalité Vulkan décrit ces responsabilités et leurs limites. [1]

Les meshlets sont une organisation d'assets courante pour ce modèle : de petits clusters de triangles avec un ensemble de sommets local. Cela n'impose pas que tout mesh shader consomme un format précalculé identique ; la géométrie procédurale est un autre cas d'usage.

Construire des clusters avec un objectif précis

Une meshlet a typiquement besoin d'indices de triangles locaux, d'une table de correspondance vers les données de sommets et de métadonnées telles que les volumes englobants. Des indices locaux compacts peuvent réduire l'espace occupé par la topologie, tandis que des clusters spatialement cohérents peuvent rendre le rejet collectif utile. L'exemple de NVIDIA expose des statistiques sur la construction des meshlets, leur taux d'utilisation et le culling. [2]

Il faut choisir les critères de clustering conjointement. Maximiser uniquement le remplissage en triangles peut produire des volumes englobants lâches ou une mauvaise réutilisation des sommets. Des clusters très petits augmentent les métadonnées et le surcoût d'ordonnancement ; des clusters très grands consomment davantage de ressources et peuvent contenir beaucoup de géométrie qui n'est conservée que parce qu'une partie du cluster est visible.

Exemple détaillé : tenir compte de la table de remappage

Supposons un format de stockage, donné à titre d'illustration, qui représente un cluster de 48 sommets uniques et 80 triangles. Un octet par indice de triangle local coûte 80 * 3 = 240 octets. Une table de remappage contenant un indice global de sommet sur 32 bits par sommet local coûte 48 * 4 = 192 octets. Ensemble, ces tableaux occupent 432 octets.

Une liste conventionnelle utilisant des indices globaux sur 32 bits pour chaque coin de triangle coûte 80 * 3 * 4 = 960 octets. Cette comparaison exclut les en-têtes, l'alignement, les volumes englobants et les attributs de sommet. Elle ne tient pas non plus compte des références de sommets dupliquées entre clusters. Elle illustre un calcul de format, et non une disposition imposée par l'API ni un gain de performance mesuré.

Valider d'abord la géométrie émise

Commencer avec un maillage connu et désactiver le rejet. Colorer les clusters de façon distincte et comparer les positions, le sens d'enroulement (winding), l'affectation des matériaux et les attributs interpolés avec ceux d'un chemin de rendu conventionnel. Vérifier que les maxima déclarés, le nombre réel de sorties et les indices de primitives concordent. Interroger les fonctionnalités, les limites et les préférences d'implémentation supportées par le périphérique plutôt que de coder en dur la taille de cluster préférée d'un seul fabricant. [1][2]

Ajouter ensuite progressivement le rejet coopératif et les optimisations de chargement des attributs. Tester des maillages déformés, des clusters en bordure et des scènes où presque toutes les primitives sont conservées. Garder explicites la synchronisation et la propriété des données partagées au sein du workgroup.

Évaluer le coût total

Le mesh shading peut déplacer le travail et en modifier la granularité ; il ne garantit pas une image plus rapide. Les attributs de sortie, la mémoire partagée, la pression sur les registres et le surcoût de l'étage task peuvent compenser les gains. [2] Comparer des matériaux et des schémas de visibilité représentatifs, y compris des objets de faible complexité. Conserver un chemin de rendu adapté lorsque la fonctionnalité n'est pas disponible, et considérer le temps de génération des clusters et la mémoire des assets comme des éléments du budget d'implémentation.

Sources

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