DirectX 10 et GPUs

Spécifications

Que savons-nous donc du reste des spécifications ? Celles-ci n’ont pas encore été affichées d’une manière complète par Microsoft dans un document marketing mais ont été disséminées dans les différentes documentations destinées aux développeurs. Nous avons regroupé dans un tableau un maximum de ces spécifications auxquelles nous avons ajoutées celles de DirectX 9, de son évolution en SM 3.0 et des 2 architectures qui les supportent ainsi que ce que Microsoft a annoncé au sujet de DirectX 10.1.


Comme à chaque nouvelle version de DirectX, nous avons droit à plus de tout : instructions, registres etc. Le but est d’éviter que les développeurs soient limités par les possibilités du Shader Model, ici en version 4.0, sans pour autant imposer une complexité au niveau du GPU inutilement coûteuse. Comme vous pouvez le remarquer, les spécifications de base sont maintenant similaires (tout comme le jeu d’instructions) entre les pixel shaders et les vertex shaders (et les geometry shaders bien entendu) contrairement aux différences actuelles. C’est dans ce sens que Microsoft parle d’unification des shaders et pas au niveau matériel !


L’unité de calcul d’exécution D3D 10 type vue par Microsoft.

En détail…

Le nombre d’instructions passe de 512 à 65536 (soit 128x plus) alors que le nombre d’instructions exécutées peut maintenant atteindre l’infini. Pour rappel, le nombre d’instructions exécutées peut être plus élevé à cause des boucles qui font répéter une série d’instructions. Le nombre de registres temporaires fait un bond énorme de 32 à 4096, mais bien entendu, comme c’est déjà le cas avec 32, les fabricants de GPU n’auront pas à devoir en intégrer autant en hardware, tout du moins avec des performances optimales. Le driver devra cependant pouvoir gérer un shader qui en utilise autant et le modifier de manière à prendre en compte les limitations matérielles.

L’une des évolutions les plus importantes de ce DirectX concerne les constantes ainsi que leur mise à jour. Le tout à été entièrement revu de manière à rendre leur utilisation plus flexible tout en réduisant le coût CPU de leur gestion, sans toucher aux performances de leur accès. Les constantes et les textures représentent un accès à la mémoire et auraient donc pu être unifiées mais les contraintes au niveau de leur accès et des performances restent très différentes et justifient donc encore leur séparation.

Chaque élément, qu’il soit pixel ou vertex dispose au départ d’un maximum de 16 registres contre 10 pour les pixels avec DirectX 9. Dans le cas d’un vertex il s’agit des données de base utilisées pour le rendu qui proviennent du CPU et des objets à rendre et qui sont organisées par l’Input Assembler qui est une version améliorée de ce qui se fait actuellement avec le Geometry Instancing. Dans le cas d’un pixel, il s’agit principalement de données interpolées, couleurs et adresses de textures. Les choses se compliquent légèrement avec les geometry shaders puisqu’ils travaillent, eux, sur des primitives. Ils doivent donc pouvoir accepter en entrée les données de 3 vertices (triangle) mais également des vertices adjacentes, ce qui fait donc 6x 16 registres 4x FP32, ce qui est énorme. Les geometry shaders peuvent transférer jusqu’à 32 registres aux pixels soit 16 de plus que sans leur utilisation, mais nous ne savons pas encore avec certitude si les geometry shader peuvent modifier ces 32 registres ou doivent laisser passer les 16 données originales qui viennent des vertex shaders et éventuellement y ajouter jusqu’à 16 autres valeurs.

L’accès aux textures a lui évolué. Aujourd’hui, le nombre d’instructions de texturing est déjà infini (mais limité par le nombre d’instructions maximal) mais pas le nombre de textures gérées et le mode d’accès aux textures (= nombre de samplers) qui sont fixés à 16. Par exemple, texture1 et filtrage trilinéaire représente une des 16 possibilités d’accès. Si on veut accéder à la même texture mais avec un filtrage différent, cela consomme un autre de ces 16 accès. Avec DirectX 10, les textures et les samplers sont séparés. Les samplers restent au nombre de 16 (autrement dit un shader peut utiliser 16 modes de filtrage) mais le nombre de textures passe de 16 à 128, chiffre qui est également valable pour les vertex shader (4 actuellement sur les GPU qui respectent les spécifications des shaders 3.0) et les geometry shader. Ces textures devront pouvoir atteindre la taille de 8192x8192 pixels contre 2048x2048 demandés actuellement bien que les GPU récents supportent tous des textures de 4096x4096 (cette taille pose parfois un problème si le GPU n’arrive pas à trouver un bloc mémoire libre suffisamment grand que pour accueillir la texture, ce qui est particulièrement le cas en FP32). Le filtrage FP16 devient enfin obligatoire (les GeForce 6 et 7 le supportent mais pas les Radeon X1000) ainsi que l’accès et le filtrage des shadow map (PCF, percentage closer filtering, supporté uniquement par Nvidia) ce qui vaut pour tous les types de shaders (pas de filtrage dans les vertex shaders actuellement). Ce n’est pas tout puisqu’un nouveau type d’accès fait son apparition : load. Le sampling d’une texture consiste à prendre le texel le plus proche d’une certaine valeur (point sampling) ou le groupe de texels proches de cette valeur (filtrage bilinéaire ou anisotrope). Load consiste à récupérer un texel bien précis, ce qui facilite l’utilisation de textures pour le stockage de données autres que des images.

La précision de calcul reste en FP32 mais a malgré tout évolué. Actuellement, les fabricants de GPUs peuvent supporter le FP32 comme ils l’entendent : précisions des arrondis, support des nombres spéciaux (NaN, +/-Inf etc.)… Cela peut poser des problèmes aux développeurs qui voient des shaders se comporter différemment d’un GPU à l’autre. Par exemple une implémentation actuelle peut remplacer un NaN (par exemple 0/0 = NaN) par 0 ce qui simplifie le design des unités de calcul et facilite aussi le rendu 3D basique qui peut plus facilement gérer un 0 concret qu’un NaN mais cela ne correspond pas au calcul flottant habituel et Microsoft a décidé que pour faciliter l’évolution il était préférable d’obliger la gestion de ces nombres spéciaux. Plusieurs autres points similaires ont été fixés de manière à se rapprocher de l’IEEE 754 que l’on retrouve dans les CPU sans toutefois respecter complètement les spécifications de l’IEEE 754, ce qui aurait eu un coût inutile. L’erreur relative peut ainsi être plus importante qu’en IEEE 754. Notez que Microsoft n’a pas définit le comportement des unités qui traitent les nombres flottants uniquement au niveau des unités de calcul mais également pour les unités de filtrage de textures et de blending.

Autre grosse nouveauté de Direct 3D 10, l’intégration du support complet des entiers 32 bits, en plus des flottants. La gestion des entiers est utile dans de nombreuses situations comme c’est le cas en développement en général, et s’accompagne du support des opérateurs binaires. Un outil précieux pour les développeurs qui se retrouvent maintenant avec un jeu d’opérations de plus en plus proche de ce que l’on retrouve sur un CPU.

Le nombre de render targets passe à 8, ce qui signifie qu’un GPU DirectX 10 pourra écrire 8 valeurs en mémoire, en plus de la donnée de profondeur, contre 4 actuellement. Le blending en FP32 devient obligatoire alors que le blending FP16 ne l’était pas dans DirectX 9 bien que supporté sur la majorité des cartes SM 3.0 (à l’exception des GeForce 6200). La gestion de l’antialiasing de type multisample reste toujours optionnelle. Par contre lorsqu’il est supporté, les fabricants doivent maintenant rendre possible la lecture d’un render target multisamplé comme une texture classique alors qu’avec les GPU actuels, c’est impossible et un tel render target doit être downsamplé avant de pouvoir être réutilisé. Ce support est rendu très complexe par les algorithmes de compression des données qui donnent tout son sens au MSAA.


Direct 3D 10 n’est pas encore là que Microsoft parle déjà de son successeur ! Notez que le matériel Direct 3D 10 fonctionnera dans Direct 3D 10.1 même s’il ne pourra pas en exploiter toutes les possibilités, comme c’est le cas d’un GPU DX8 dans DX9. Par contre, les GPU DX9 ne fonctionneront pas avec DX10 et les jeux D3D 10 devront donc intégrer un rendu D3D 9 pour les supporter. Direct 3D 10.1 rendra obligatoire le support du MSAA 4x (tous les GPUs ATI et Nvidia le supportent mais ce ne l’est pas le cas chez Intel, S3 etc). Cette nouvelle mouture de Direct 3D sera d’ailleurs pour Microsoft l’occasion d’enfin spécifier en détail le fonctionnement de l’antialiasing et de donner plus de contrôle aux développeurs à ce niveau, ce qui n’a pas été encore été fait par manque de temps probablement et pour ne pas retarder trop DirectX 10. Il est possible que cette gestion plus avancée de l’antialiasing soit supportée sur certains GPU Direct 3D 10 (notez à ce sujet que le G80 de Nvidia disposera d’ailleurs, enfin, d’un moteur d’antialiasing tout neuf).

La gestion du filtrage FP32 des textures sera obligatoire et Microsoft parle d’une précision de calcul accrue sans que l’on sache s’il s’agit d’un FP32 encore plus proche de l’IEEE 754 ou d’un autre format. Le blending évoluera aussi pour gagner plus de flexibilité. Grossièrement on peut supposer que Direct 3D 10.1 représentera une évolution des unités fixes restantes des GPU. Avant de les rendre complètement programmables elles aussi dans une future version ?