Avec la DGF SuperCompression, AMD cherche à concilier foisonnement visuel et légèreté des assets

Il y a sept mois, une équipe d’AMD publiait un papier esquissant un nouveau format graphique 3D : le Dense Geometry Format (DGF). Cette technologie vise à augmenter le niveau de détail géométrique en 3D, au-delà des méthodes de rastérisation actuelles comme la tessellation, en réduisant l’empreinte mémoire des données géométriques.

Une illustration NVIDIA RTX Mega Geometry, mais 1. AMD ne propose que des schémas peu ragoûtants 2. au Comptoir, on aime les lapins.

Concrètement, elle regroupe de petits éléments de maillage — jusqu’à 64 sommets et 64 triangles — dans des blocs de 128 octets servant de conteneurs compacts pour la géométrie, les positions des sommets et une topologie de lumière simplifiée.

Dans l’esprit, elle se rapproche de la Mega Geometry de NVIDIA, même si l’approche diffère : NVIDIA cible surtout le ray tracing via une structure hiérarchique, tandis que DGF s’applique aussi bien au raster qu’au ray tracing.

Côté matériel, aucune architecture AMD actuelle ne propose d’accélération matérielle spécifique au DGF. Dans le papier de septembre, la technologie semblait donc pensée pour de futures générations comme RDNA 5 ou UDNA. En attendant, une exécution via shaders reste possible, au prix d’un léger surcoût en performances.

En fin de semaine dernière, AMD a dévoilé la DGF SuperCompression (DGFS). Comme son nom l’indique, il s’agit d’une technique de compression intégrée à la pile DGF. Selon les mesures de l’entreprise, elle permet de réduire jusqu’à 22 % la taille des fichiers de géométrie des jeux par rapport au DGF standard.

TLAS, CLAS, BLAS, BLAST

Le document, rédigé par Josh Barczak, est assez jargonneux. L’auteur revient notamment sur la présentation initiale du DGF pour apporter une précision importante :

Les moteurs de rendu sont de plus en plus conçus autour de petits clusters de triangles autonomes. Ces clusters (également appelés "Meshlets") servent à construire des pipelines de rendu pilotés par le GPU ou des systèmes de niveau de détail très fins. Les clusters de triangles constituent une unité de travail logique pour le culling, l’animation, le LOD et le streaming de géométrie. Pour cette raison, nous utilisons un système de compression à granularité par cluster pour DGFS, dans lequel chaque cluster de triangles est compressé et décodé de manière indépendante.

Certains observateurs ont décrit DGF comme une "réponse" au développement des CLAS. Il est facile de comprendre d’où vient cette idée, mais elle est inexacte. DGF n’est pas une réponse aux structures CLAS, mais une technologie orthogonale et complémentaire. Une BLAS peut être construite à partir de tableaux de données de sommets et d’indices, ou à partir d’un ensemble de blocs DGF. De la même manière, une CLAS peut être constituée de tableaux beaucoup plus petits des mêmes types de données.

Dans les deux cas, de la géométrie précompressée peut être utilisée, avec les mêmes avantages. Le flux DGFS est conçu de manière à pouvoir être facilement décodé soit en maillage indexé, soit en tableau de blocs DGF, comme illustré ci-dessous [pour vous aussi, c'est ci-dessous, mais un peu plus loin, après quelques explications]. Avec DGFS, une application stocke en pratique deux représentations de la géométrie pour le prix d’une seule, ce qui permet à un jeu de cibler facilement à la fois les appareils compatibles DGF et ceux qui ne le sont pas, via un format de stockage commun ».

Josh Barczak fait ici référence aux CLAS pour éviter de citer explicitement le NVIDIA Mega Geometry, mais le lien est évident : NVIDIA décrit les CLAS comme un composant clé de cette approche, le levier pour réutiliser des motifs de clusters afin d’accélérer la reconstruction des structures d’accélération — des cartes de tri optimisées qui déterminent quels objets ou triangles peuvent être touchés par un rayon. Mega Geometry dépasse toutefois ce seul mécanisme en englobant l’ensemble du pipeline de gestion de la géométrie.

Intercalons quelques explications. La construction des structures d’accélération peut devenir un frein en ray tracing lorsqu’il y a beaucoup de géométrie dynamique (streaming d’assets, objets animés, LOD, tessellation dynamique). La géométrie clusterisée répond à ce défi en permettant aux applications de construire des structures d’accélération autour de clusters compacts de primitives, puis de les utiliser comme blocs de construction pour créer des structures d’accélération de bas niveau. Cette répartition du travail permet des temps de construction nettement plus rapides qu'en partant d’un ensemble de triangles non structuré (une triangle soup).

© Microsoft

Dans cet organigramme, tout en haut, se trouve le TLAS (Top-Level Acceleration Structure) chargé d’organisé les instances d’objets dans la scène. Chaque instance correspond ensuite à un objet complet, lui-même décrit par une BLAS (Bottom-Level Acceleration Structure), qui organise la géométrie de cet objet, c’est-à-dire ses triangles. Dans ce modèle, le TLAS sert donc à positionner les objets dans la scène, tandis que la BLAS décrit leur structure interne.

Un exemple de panneau de visualisation TLAS © AMD

Les CLAS (Cluster-Level Acceleration Structures) introduisent une organisation différente et optionnelle. Elles ne remplacent pas la hiérarchie TLAS/BLAS, mais proposent un regroupement intermédiaire de la géométrie sous forme de clusters de triangles. L’objectif est d’améliorer l’efficacité des opérations de ray tracing en traitant des ensembles de triangles spatialement proches plutôt que des primitives isolées. Pour simplifier avec une analogie urbaine, le TLAS serait la carte de la ville, les BLAS les bâtiments, les CLAS des regroupements de pièces ou de zones cohérentes à l’intérieur des bâtiments, et les triangles les petites briques de tout ceci.

C’est maintenant que nous raccrochons le wagon. Rappelez-vous : « Une BLAS peut être construite à partir de tableaux de données de sommets et d’indices, ou à partir d’un ensemble de blocs DGF ».

Il y a cependant un loup. Josh Barczak explique que si « le DGF a été conçu avant tout comme un format matériel efficace » et que « sa conception garantit que toutes les informations nécessaires pour un triangle donné puissent être récupérées via une seule lecture mémoire alignée de 128 octets, cette propriété, essentielle en ray tracing, a toutefois des conséquences qui rendent le format moins attractif comme format de stockage. Les positions des sommets et les paramètres de compression doivent être dupliqués entre plusieurs blocs, et des bits de remplissage doivent être ajoutés pour assurer l’alignement des données, notamment lorsque les blocs ne sont pas entièrement utilisés ».

Pour y remédier, AMD mise donc sur la DGFS, une couche de compression qui réduit le coût de stockage du DGF. La géométrie compressée n’est plus directement exploitable, mais peut être reconstruite par décodage, ou reconvertie en buffers classiques (sommets/indices) pour assurer la compatibilité avec des GPU ne supportant pas la DGF. Josh Barczak fait l’analogie suivante : « DGFS pour DGF joue le même rôle que Basis Universal pour DXT ».

© AMD

Dans la pratique, sur une configuration équipée d’un Ryzen 9 7950X, de 64 Go de DDR5-6000 et d’une Radeon RX 9070 XT, AMD annonce jusqu’à 22 % de réduction de la taille des ressources de jeu.

Reste que les données DGFS doivent être décompressées en temps réel lors du chargement des assets. Ce traitement est actuellement assuré par le CPU. AMD allègue que le processus est suffisamment rapide et fournit quelques valeurs pour un unique cœur CPU. Dans le pire des cas, celui d'une Statuette de 10 millions de triangles, elle est décodée en meshlets en 0,15 seconde, tandis que le décodage des blocs DGF prend 0,22 seconde. L'entreprise n’écarte pas des solutions de décompression côté GPU à l’avenir.