Une architecture radicalement différente

Avec le R520, ATI inaugure une toute nouvelle architecture, beaucoup plus flexible que ce que nous connaissions jusqu'alors. Par rapport aux R4xx (Radeon X800/850), ATI fait en effet un grand saut. La partie traitant les pixels au sein de la puce graphique se décompose dorénavant en divers noyaux d'exécution, dont certains, à la manière d'un jeu de construction Lego, peuvent se réadapter afin d'exécuter une tâche donnée avec le maximum d'efficacité. Pour que cela fonctionne, l'architecture du pipeline 3D a été largement revue et la notion de pixels pipelines, telle que nous la connaissions par le passé, est aujourd'hui tout simplement dépassée. Attention toutefois il n'est pas encore question d'un pipeline unifié capable de traiter aussi bien les vertex que les pixels shaders même si l'on s'en rapproche inexorablement.


Commençons notre tour d'horizon du moteur 3D du R5xx par la partie réservée à l'exécution des vertex. Cet élément qui gère principalement les calculs géométriques comporte huit unités d'exécution et non plus six comme avec les Radeon X800. Chaque unité de vertex peut ici traiter deux instructions par cycle d'horloge ce qui confère à la puce une puissance théorique brute de 10 milliards d'instructions à la seconde. Opérant selon les spécifications du Shader Model 3.0, les unités de vertex peuvent exécuter un maximum de 1024 instructions, mais grâce au contrôle dynamique de flux le R520 peut en vérité aller beaucoup plus loin. Sans rentrer dans trop de détails, une unité de vertex du R520 se compose d'une sous unité arithmétique vectorielle de 128 bits et d'une unité scalaire de 32 bits. Petite subtilité, les unités de vertex du R5xx n'ont pas accès au moteur de textures, cette fonction n'étant pas rendue obligatoire par les spécifications du Shader Model 3.0. Du coup, cela peut poser problème et rendre les opérations de Displacement Mapping à partir des textures impossibles. ATI a ici pris soin de ne pas exposer la fonction de Displacement Mapping dans les pilotes même si elle reste fonctionnelle lorsqu'elle n'est pas liée aux textures (en utilisant un pixel shader comme point d'entrée dans les vertex shaders). Généralement c'est cette dernière variante que les développeurs utilisent, le Displacement Mapping à partir d'une texture étant trop coûteux en terme de performances.


Ce qui constituait autrefois le pipeline 3D est dorénavant chapeauté par un processeur multithreadé. Si ce processeur apparaît physiquement sur le schéma de l'architecture du R520, il s'agit plus d'une représentation conceptuelle que d'un véritable noyau au sein de la puce. Quoi qu'il en soit, celui-ci a pour tâche de répartir les données dans les différents Processeurs de shaders qui lui sont connectés, mais aussi dans les seize unités d'adressage de textures. Ce processeur multithreadé, baptisé Ultra-Threading Dispatch Processor, a été intégré afin d'obtenir la meilleure efficacité possible. Le crédo d'ATI étant de réduire la latence et d'éviter au maximum le gaspillage de cycles. Comme c'est le cas dans le monde des CPU, l'intérêt premier de cet « Ultra-Threading » est de paralléliser au mieux les tâches en alimentant le plus possible les autres unités de la puce. Pour cela, le R520 peut gérer jusqu'à 512 processus en parallèle (les RV515 et RV530 se contenteront quant à eux de 128 processus) et c'est précisément l'un de ses points forts.

En outre, ATI offre une granularité jusqu'alors inégalée en éclatant le traitement des pixels nécessaires au rendu d'une image en un large nombre de petits processus. Avec le R520 la taille minimum d'un processus 3D peut être de 16 pixels soit un carré de 4x4. En face, le pipeline de NVIDIA travaille de manière un peu plus grossière avec une taille de threads plus élevée de 64x16. Ceci permet d'assurer une alimention quasi-perpétuelle du pipeline et si jamais l'un des cores a terminé une tâche ou est en attente de données pour achever l'exécution d'un shader, le processeur Ultra-Threading est capable de suspendre un processus en attente, jusqu'à ce que les données soient disponibles, pour faire travailler le noyau sur une autre tâche. Le processeur a également recours à un algorithme de séquencage pour réarranger le code des shaders. Dès lors le taux d'utilisation du pipeline 3D est particulièrement élevé garantissant ainsi un maximum d'efficacité. Il est également question d'accélérer le contrôle dynamique de flux grâce aux fonctions décrites précédemment et ayant trait à la gestion des processus. Rappelons que le contrôle de flux est une fonction introduite par le Shader Model 3.0 qui propose le branchement, les boucles et autres conditions dans les shaders afin, par exemple, d'exécuter une autre branche du programme en fonction du résultat obtenu. Ceci est particulièrement utile notamment pour les effets d'éclairage qui peuvent ainsi varier en fonction d'un algorithme et sans nécessité de changement de shaders. On peut encore tirer profit des branchements pour sauter certaines parties du shader qui n'ont plus besoin d'être exécutées pour telle ou telle raison.



Placé en amont, le processeur multithreadé est relié à l'unité de pixels qui comporte pour sa part quatre processeurs de shaders pouvant traiter chacun quatre pixels en parallèle pour six instructions différentes par processus et par cycle d'horloge. Les quads d'ATI sont chacun munis de quatre unités arithmétiques ; deux en scalaire et deux en vectoriel en plus d'une unité de branchement. Cette dernière est une petite nouveauté dont le rôle n'est pas négligeable puisque des unités dédiées sont mises à la disposition des contrôles de flux afin de ne pas avoir d'impact sur les unités arithmétiques. Le but ? Réduire les délais liés aux opérations de branchement en permettant aux programmes qui y font appel de s'exécuter en un nombre réduit de cycles d'horloge. D'autre part, les registres à usage général du R520 sont au nombre de 32, contre 12 pour les Radeon X800 même si l'on pouvait en adresser 32 avec l'architecture R4xx. Comparativement à une architecture traditionnelle, le R520 peut donc être catalogué comme une puce disposant de 16 pixels pipelines chacun disposant de sa propre unité de texture. En fin de pipeline, on retrouve 16 unités ROP.