ATI Radeon HD 2900 XT

Performances DirectX 10

Comment vont se comporter les GPUs avec cette nouvelle API ? Voilà une question à laquelle nous aimerions tous avoir une réponse. Autant être clair, nous ne vous la donnerons pas dans ce test. Il est encore trop tôt pour en juger. Différentes démos technologiques sont disponibles mais elles sont destinées uniquement à exposer des méthodes de rendu ou de nouveaux algorithmes. Elles ne représentent pas des tests fiables prises telles qu'elles, cela demanderait une analyse minutieuse de la manière dont ces démos utilisent les différentes fonctions de DirectX 10 et des raisons pour lesquelles les résultats sont ce qu'ils sont.

Les drivers DirectX 10 sont encore jeunes, tout comme l'API et ces démos. Qui plus est il est très facile d'optimiser une démo technologique pour mettre un avant son produit. En bref vous donner les résultats sous ces différentes démos serait plus de la désinformation qu'autre chose.

Nous pouvons par contre vous donner un début d'analyse de l'implémentation de cette API. Contrairement à Nvidia, AMD a intégré un cache généralisé pour les lectures/écritures en mémoire à partir du shader core. Celui-ci peut être utilisé d'une manière classique pour le Stream Output qui consiste, comme le requiert DirectX 10 à pouvoir écrire les données qui sortent du shader core sans passer par les ROPs. Il permet également de virtualiser les registres généraux qui peuvent ainsi être illimités.


Une autre utilité est d'utiliser la mémoire vidéo à travers ce cache pour stocker temporairement la masse potentiellement énorme de données créées par les Geometry Shaders lors d'amplification de la géométrie sans quoi les unités de calcul pourraient être bloquées par impossibilité de placer le résultat dans les registres généraux ce qui poserait un problème et à priori un plantage puisque les données géométriques doivent pouvoir rester dans le bon ordre. Par exemple imaginez les triangles 1 et 2 en train d'être décomposés. Le triangle 1 doit être rendu avant le triangle 2. Un GPU étant par définition parallèle, ces 2 triangles peuvent être traités en même temps par le geometry shader qui va les décomposer en une série de plus petits triangles. A la sortie, tous les triangles issus du triangle 1 devront être rendu avant les autres. Pas de problème s'il y a assez de mémoire pour tout stocker, il suffit d'attendre que le tout soit terminé et de contrôler que le rendu se fasse dans le bon ordre. Mais si le GPU tombe à court de mémoire alors que les triangles 1 et 2 sont toujours en train d'être décomposés, il est callé. Il ne peut pas encore traiter les petits triangles puisque la décomposition n'est pas terminée ce qui veut dire que l'ordre ne peut pas être contrôlé avec fiabilité, mais ne peut plus continuer la décomposition. Nous sommes donc dans une impasse.

AMD évite ce problème grâce à cet accès caché à la mémoire vidéo. Nvidia doit bien entendu l'éviter également, il n'y a pas d'autre solution. Par contre l'approche d'après notre interprétation des explications de Nvidia est très différente. Nvidia prendrait ainsi le problème dans l'autre sens et au lieu de proposer plus de mémoire pour stocker les données avant de rétablir l'ordre, Nvidia réduirait le nombre d'éléments traités en parallèles à un nombre qui permette toujours d'avoir assez de mémoire dans le GPU. Autrement dit au lieu de pouvoir utiliser les 128 processeurs en parallèle pour traiter un geometry shader, si Nvidia détecte qu'il peut y avoir un problème ce nombre doit être réduit. Quel est le cas le moins favorable ? 16 processeurs ? 8 processeurs ? 1 processeur ? Et les autres processeurs peuvent-ils travailler à une autre tâche pendant ce temps ou sont ils en attente ? Difficile de répondre à ces question pour le moment, mais il semble évident qu'il y a là une grosse différence entre Nvidia et AMD, à l'avantage de ce dernier. Reste bien entendu à voir ce que les développeurs feront des geometry shaders.

Call of Juarez

A mi chemin entre premier jeu DirectX 10 et démo technologique, le benchmark de Call of Juarez (fourni par AMD) va nous faire déroger à la règle de ne pas donner de résultats de démo DirectX 10, puisque c'est un peu plus que cela. Notez que Nvidia nous a fourni un nouveau driver (158.42), optimisé pour ce test, augmentant de 20% les performances. Ces résultats sont à prendre avec des pincettes puisqu'il ne s'agit pas de la version finale du benchmark et du patch pour le jeu qui ira avec, comme le démontre d’ailleurs le rendu de la végétation qui pose des soucis quelque soit la carte graphique.

Tesselation

Comme nous vous l'avons indiqué au début de cet article, le Radeon HD 2900 reprend l'unité de tesselation programmable du GPU de la Xbox 360. Le retour du Truform en d'autres mots et ce n'est pas qu'une boutade puisque les clés Truform sont de retour dans la base des registres bien que pas activées.


Malheureusement, la tesselation ne fait pas partie des spécifications de DirectX 10. Cela sera probablement le cas dans une future évolution, mais quand ? En attendant, il faut utiliser de nouveau une détection spéciale via un format de texture pour détecter la présence de cette unité et en quelque sorte tromper l'API, le driver se chargeant alors d'adresser sa tâche à l'unité de tesselation. Cela tranche quelque peu avec l'esprit "les caps c'est fini" de DirectX 10, mais en contrepartie cela permet des portages faciles à partir de jeu Xbox 360. Que feront les développeurs ? Rien dans l'immédiat puisque la tesselation ne fait pas encore partie des drivers et AMD ne sait pas quand ce sera le cas. Cet été ? Dans 6 mois ? Dans 1 an ? Jamais ? AMD ne peut pas répondre à cette question et annonce donc une fonction qui restera virtuelle jusqu'à nouvel ordre. Dommage.


Le futur de DirectX 10 passe par l'intégration d'une unité de tesselation. Mais quand ?

Notez que les geometry shader permettent de faire de la tesselation, mais avec des performances bien trop faibles que pour pouvoir généraliser son utilisation comme le permet une unité dédiée.