Microsoft lance Shader Model 6.10 et AgilitySDK 720 Preview avec des nouveautés DX12 pour l’ère du rendu neuronal

Microsoft met à disposition en préversion Shader Model 6.10 et l’AgilitySDK 1.720 pour DirectX 12. Cette mise à jour apporte de nouvelles API d’algèbre linéaire, un index de vague par groupe, de la mémoire partagée variable et des intrinsics pour le ray tracing. Les développeurs gagnent en contrôle fin sur l’exécution GPU et peuvent optimiser plus facilement leurs moteurs et leurs jeux.

Microsoft DX12 : API d’algèbre linéaire « Matrix », Group Wave Index, intrinsics de ray tracing et plus avec Shader Model 6.10 et AgilitySDK 1.720 en préversion

La sortie du jour prolonge les ajouts de Shader Model 6.9, DXR 1.2 et autres améliorations arrivés avec l’AgilitySDK 1.619. Avec l’aperçu AgilitySDK 1.720, Shader Model 6.10 et les fonctionnalités ci-dessous rejoignent l’API DX12 :

• Shader Model 6.10 (via DXC 1.10.2605.2):
  • linalg::Matrix
  • Group Wave Index
  • Variable Group Shared Memory
  • Intrinsics de ray tracing
    • TriangleObjectPositions
    • ClusterID

inalg::Matrix

Shader Model 6.10 introduit un ensemble d’API Matrix couvrant un large éventail de cas d’usage. L’ensemble est regroupé sous l’appellation LinAlg (pour Linear Algebra).

Group Wave Index

Shader Model 6.10 ajoute deux intrinsics, GetGroupWaveIndex() et GetGroupWaveCount(), qui donnent aux compute, mesh, amplification et node shaders une visibilité directe de la structure au niveau des waves dans un thread group. GetGroupWaveIndex() renvoie l’index de la wave courante (0 à N-1), et GetGroupWaveCount() renvoie le nombre total de waves exécutées dans le groupe. Cela permet une spécialisation et une coopération au niveau des waves sans recourir à des contournements risqués comme la division de SV_GroupIndex par WaveGetLaneCount(), qui n’est pas garantie sur tout le matériel. Un seul chemin de code fonctionne désormais de manière portable, quelle que soit la taille des waves.

Variable Group Shared Memory

Shader Model 6.10 lève l’ancienne limite de 32 KB (28 KB pour les mesh shaders) sur la mémoire groupshared en exposant la vraie limite matérielle via une nouvelle requête à l’exécution, MaxGroupSharedMemoryPerGroup. Les auteurs de shaders peuvent utiliser un nouvel attribut d’entrée [GroupSharedLimit()] pour déclarer la mémoire partagée maximale requise par leur shader, offrant au compilateur une vérification de portabilité à la compilation tout en donnant accès à la capacité complète des GPU modernes. Les shaders sans attribut continuent d’être validés contre les limites héritées, sans impact sur l’existant. Cela débloque des algorithmes comme le culling à gros tiles, les bacs de rastérisation logicielle et les charges matricielles volumineuses auparavant bridées par la spécification plutôt que par le matériel.

Fonctionnalités D3D12 :

Batched Asynchronous Command List APIs

Les commandes historiques de D3D12 comme CopyBufferRegion, ClearUnorderedAccessViewFloat/Uint, ResolveSubresource et consorts s’exécutent strictement en série, car l’ancien modèle ResourceBarrier n’exprime pas de dépendance entre deux opérations du même type (par exemple, copy-dest vers copy-dest). Résultat : le GPU marque un arrêt entre chaque copie ou clear successif, même quand les opérations manipulent des zones de mémoire totalement indépendantes. La fonctionnalité Batched Async Commands introduit de nouvelles méthodes de command list qui suppriment ce contrat de sérialisation implicite, autorisant pilote et matériel à superposer les travaux indépendants au sein d’un même appel batch. Les développeurs optent pour une synchronisation explicite via des barrières améliorées uniquement lorsqu’un vrai risque de conflit de données existe, par exemple si deux copies écrivent dans des régions qui se chevauchent d’un même buffer ; tout le reste s’exécute en parallèle.

Tous les grands fournisseurs matériels, dont NVIDIA, AMD et Intel, prennent en charge ces préversions :