En attendant les cartes, l'architecture R520...

NVIDIA a lancé sa GeForce 7800 GTX le 21 juin. Pour la première fois, les cartes étaient disponibles immédiatement au lendemain de l’annonce… Moins de deux mois plus tard, le constructeur californien a remis le couvert avec la GeForce 7800 GT. Pour le plus grand plaisir des « geeks », la petite nouvelle a conservé la ponctualité de sa grande sœur… Contrairement à NVIDIA qui a lancé des produits séparément, ATI a attendu le 5 octobre pour annoncer une nouvelle gamme complète. Afin de ne pas faire pâle figure face à son concurrent, le fondeur canadien a également parlé de disponibilité immédiate. Plus de deux semaines après le lancement et malgré les belles promesses, les cartes ne sont toujours pas dans les boutiques. En attendant des Radeon X1800 XT et XL pour des tests concrets, nous devons nous contenter d’examiner l’architecture des nouvelles venues…

Retard ou pas ?

Il est amusant de constater qu’au fur et à mesure du temps, ce sont presque les news de certains sites – mieux que les constructeurs – qui fixeraient les dates de sortie des produits ! S’il est vrai que les R520 étaient attendus par la majorité bien avant le 5 octobre, ATI n’avait jamais donné de date officielle. Quoi qu’il en soit, on ne lance pas une nouvelle architecture, qui plus est en passant à une technologie de gravure plus avancée, sans d’éventuels retards de dernière minute. Le basculement au 90nm a conduit ATI à faire deux révisions de plus qu’initialement prévu… Il faut reconnaître que contrairement à ses habitudes – à savoir tester une nouvelle technologie de gravure sur des produits matures dans le cadre de versions économiques – ATI a introduit le premier processeur graphique en 90nm. Le canadien n’a pas fait dans le détail vu que le R520 comporte quand même 321 millions de transistors sur seulement 272mm² contre 302 millions pour le G70 (333mm²). Même si l’accouchement a été difficile, ATI a passé un double cap qui devrait être s’avérer bénéfique pour l’avenir…


Manque à combler…

Avec le NV40 et ses dérivés, NVIDIA a d’emblée supporté les Shaders Model 3.0 alors qu’ATI avec ses Radeon X800 et X850 s’en tenait toujours à la version 2.0 depuis sa très réussie Radeon 9700 Pro… Mais face au puissant marketing de NVIDIA et à l’arrivée des jeux utilisant les Shaders 3.0, ATI ne pouvait plus se permettre de faire l’impasse sur cette technologie. Ce sont surtout les consoles de jeux qui ont joué les moteurs pour imposer le passage aux Shaders Model 3.0. En effet, les prochaines générations y feront massivement appel et les développeurs de jeux ne prendront certainement plus leur temps à écrire un path code pour le modèle 2.0… L’exemple de Splinter Cell Chaos Theory est parlant. Le jeu est sorti dans un premier temps en supportant les shaders 3.0 et il a fallu attendre un patch pour prendre en charge la version 2.0. A l’avenir, ce genre de développement risque de ne plus se faire. Les circuits graphiques limités aux shaders 2.0 devront se contenter des shaders 1.x qui – vu la base existante – devraient encore bénéficier d’un certain support. Autre détail, pour signer des gros contrats sur des millions de petits VPU, il faut que les modèles phares soient au top. Quel constructeur n’a pas envie de pouvoir mettre ses petits autocollants « support des shader 3.0 » sur ses cartes ?
Outre ces considérations un peu marketing, les shaders 3.0 permettent de faire simplement, rapidement et bien mieux ce qui était grosso modo réalisable avec la version 2.0. Les branchements dynamiques y sont pour quelque chose ainsi que la précision qui découle des calculs en FP32.


La réponse : Fudo !
Sous le nom de code Fudo se cache la nouvelle architecture d’ATI. Le 90nm mis à part, elle apporte plusieurs innovations : un contrôleur mémoire inédit, des shaders engines mis à niveau et la technologie vidéo AVIVO. Comme toutes les architectures récentes, celle du R520 est modulaire. Concrètement, cela signifie qu’en jouant sur les unités et les fréquences, on peut créer une gamme complète de cartes graphiques. ATI a poursuivi plusieurs autres objectifs : performances, rendement élevé et rendu de très haute qualité.
ATI ne s’est pas contenté de rattraper son retard sur NVIDIA. Le R520 supporte le HDR mais il va plus loin en supportant la combinaison HDR et anti-aliasing. Les images issues des démonstrations sont d’ailleurs du plus bel effet… « Fudo » hérite aussi de la prise en charge de la compression non destructrice de la normal map 3Dc introduite par la génération précédente. Dans le cas qui nous occupe, elle évolue vers la version 3Dc+ en supportant également les textures à un seul canal (utiles pour les maps d’ombre, d’éclairage et les textures HDR). ATI a également présenté l’Adaptive AA qui combine les avantages du supersampling avec ceux du multisampling tout en fonctionnant sur les textures avec des zones transparentes comme les grillages, les feuillages, etc.
Pour sa dernière architecture, ATI évoque aussi un filtrage anisotropique de très haut niveau (16x) exploitable avec au choix un mode performances et un mode qualité.


Le contrôleur mémoire

Une pour ne pas dire la plus grande innovation de l’architecture R520 est le contrôleur mémoire. Dans les générations précédentes, le contrôleur mémoire communique avec la mémoire en 256bits via 4 canaux de 64bits, chacun relié à deux puces de mémoire. Cette solution introduite par les GeForce3 se retrouve dans la majorité des processeurs graphiques. Auparavant, le bus était en 256bits d’un seul bloc. Un transfert ne demandant que 32bits mobilisait tout le contrôleur et toute la largeur du bus… Pour disposer d’une bande passante toujours plus importante avec un contrôleur conventionnel, il faut augmenter soit la largeur du bus, soit la fréquence de la mémoire, soit le data rate, voire combiner plusieurs de ces éléments. Une autre approche consiste à utiliser au mieux la bande passante existante (compression des données) et à éviter les gaspillages (éviter les traitements inutiles). Selon ATI, l’approche actuelle semble montrer ses limites lors des accès incessants à la mémoire notamment pour l’application de l’AA et de l’AF ainsi que dans les hautes résolutions. Le contrôleur « Ring Bus Architecture » est la solution apportée par ATI au problème critique de la bande passante. Le contrôleur gère toujours un bus 256bits mais via 8 canaux de 32bits et un bus périphérique 512bits divisé en deux anneaux de 256bits « tournant » dans le sens inverse et de quatre « Ring Stop » reliés aux puces de mémoire. Dans une architecture conventionnelle, si le contrôleur reçoit une demande de données d’un « client » (par exemple une unité du VPU), il organise et exécute la requête. Ensuite, il reçoit les informations demandées et les dirige vers le client qui a réalisé la demande. Avec le contrôleur « Ring Bus », seule la demande transite par le contrôleur lui-même. L’information est envoyée via le ring (par le sens le plus court) et le client la récupère lui-même. Cette manière de procéder permet de disposer au mieux d’une grande bande passante brute.


Mais quand le VPU est en pleine activité, ce sont des dizaines de requêtes qui se font de front. Pour éviter que la latence engendrée par l’impossibilité de répondre immédiatement à toutes les demandes, des caches sont nécessaires ainsi que des algorithmes pour déterminer les priorités de traitement. Autre innovation du R520, ces caches sont de type Fully Associative et plus Direct Mapped ou N-Way Set Associative comme dans les anciens VPU. La gestion est plus complexe vu que chaque partie peut mapper n’importe quelle zone de la mémoire mais le hit ratio d’un tel cache est bien plus élevé.


Enfin, toujours dans le but d’optimiser la bande passante, certaines données subissent une compression très légèrement destructrice (texture) alors que d’autres comme les couleurs, données Z et les stencil buffers passent par un procédé non dégradant.


Enter this way

Comme nous l’avions déjà fait avec les Radeon X800 et GeForce 6800, nous allons cheminer de l’entrée du VPU à la sortie. Le R520 est nativement PCI-Express. Après leur arrivée dans le processeur graphique, les données géométriques sont prises en charge par le Vertex Shader Engine composé de 8 Vertex Pipelines. Ils disposent chacun d’une unité vectorielle en 128bits et d’une unité scalaire en 32bits capables de traiter tous deux une instruction par cycle. Un contrôle du flux nécessaire aux branchements dynamiques a fait son apparition. S’ils supportent bien les Shaders Model 3.0, un grand flou subsiste quant à la gestion du Vertex Texturing qui semble pratiquement absente. ATI ne communique pas beaucoup à ce sujet. Ce manquement est loin d’être critique étant donné le faible usage fait de cette fonction. Avec 8 vertex pipelines et sa fréquence de 625MHz, le Radeon X1800 XT dispose d’une puissance géométrique peu commune : 1250Mver/s ! Le Radeon X1800 XL est quant à lui tout aussi impressionnant avec 1000Mver/s. A titre de rappel, le GeForce 7800 GTX n’affiche qu’un « petit » 936Mver/s (766Mver/s pour la version GT).

Les données géométriques subissent ensuite différentes opérations : backface cull, clipping, perspective divide et viewport transform. Il s’agit de mettre la scène à l’échelle et de la cadrer suivant le point de vue en laissant tomber toutes les données relatives aux parties non visibles des objets.
Dans le Setup Engine, différents tests sont réalisés pour éviter de traiter les polygones masqués par d’autres via le Hierarchical Z. Il a été optimisé et selon ATI, les algorithmes plus fins du R520 permettent de détecter jusqu’à 50% de zones masquées et ainsi éviter des calculs inutiles. On remarque aussi sur le diagramme du chip que les données Z sont conservées de manière compressée (ratio 8:1) via un algorithme non destructeur. ATI conserve sa technologie Fast Z Clear qui permet d’effacer très rapidement les Z buffer et Stencil buffer. C’est donc un minimum de données « 3D » qui seront aplaties avant de prendre le chemin de la sortie au travers du Pixel Shader Engine.


Way out !


L’Ultra-Threading Dispatch Processor distribue les données (sous forme de groupes de pixels appelés threads) vers les 4 quads pixel shader core. Ils se composent tous les quatre de Pixel Shader Processor (soit un total de 16 « pixel pipelines »). Dans chacun, on retrouve deux unités scalaires, deux unités vectorielles et une unité de contrôle du flux. Le contrôle de flux piloté par une unité dédiée est une première et permet d’après ATI d’économiser six cycles pour se consacrer directement aux branches du shader lui-même. Habituellement, cette tâche incombe à une ALU. Par contre, avec une grosse unité vectorielle + scalaire (3+1) et une petite unité vectorielle + scalaire (3+1) pour des modifiers, le R520 n’évolue guère par rapport à la génération précédente.

ATI a choisi des Threads de petite taille : seulement 16 pixels. L’intérêt de ce choix est évident. En effet, si tous les pixels d’un Thread ne suivent pas la même branche du shader, les deux branches doivent obligatoirement être calculées. Il y a statistiquement plus de chance que tous les pixels d’un petit groupe ne suivent qu’une des branches. A l’inverse, plus le Thread est gros, plus il est probable de trouver des pixels de chaque branche, ce qui impose le calcul des deux options. Ceci est très bien illustré par l’exemple fourni par ATI.


D’un autre côté, il ne doit pas être bien compliqué de démontrer que dans d’autres cas, un gros Thread est plus avantageux. Mais tout est souvent idyllique dans les documents PDF… Trêve de plaisanterie, la juste taille du Thread est fonction de la conception du shader core. Et dans le cas qui nous occupe, la solution d’ATI tient parfaitement la route ! En effet, quand un Thread (appelons-le « A ») est en cours de traitement, il peut nécessiter une opération lente comme l’accès à une texture. A ce moment, le Thread « A » est envoyé à l’unité de texture et le shader core se met immédiatement à traiter un autre Thread « B ». Si celui-ci est simple, il peut directement être traité et quitter le shader core qui fera soit entrer un nouveau Thread « C » soit terminera le traitement du Thread « B ». Si ce Thread « B » est complexe, il devra peut-être aller lui aussi à l’unité de texture. Pendant qu’elle s’occupera du Thread « B », elle retournera le Thread « A » au shader core. Les possibilités sont multiples pour ne pas dire infinies et ne manquent pas de rappeler l’HyperThreading des Pentium 4. En pratique, le Pixel Shader Engine du R520 ne cesse de jongler avec de très nombreux Threads (un maximum de 512) afin d’occuper au mieux les unités de traitement qui le composent. Ces nombreux basculements entre Threads nécessitent une volée de zones de stockage temporaires, les General Purpose Register Arrays.


L’avant-dernière étape est le Render Back-End totalement comparable aux ROP des GeForce. Il s’agit d’unités dédiées à l'anti-aliasing, à la compression des couleurs, les filtrages, etc. Ensuite, direction le frame buffer et l’écran !


HDR

Le HDR ou High Dynamic Range définit un rapport entre la plus haute et la plus faible valeur qui peuvent être affichées. Plus la précision, c’est-à-dire le nombre de bits, est élevée, plus le Dynamic Range est élevé. Avec une précision de 8bits integer, le DR est de 256 :1, il grimpe à 65 536:1 en 16bits integer et à 2,2 trillions:1 en 16bits FP. On peut alors franchement parler de High Dynamic Range. Les Radeon X1800 supportent donc le HDR en 64bits via 4 canaux en 16bits FP comme les GeForce 6800 et 7800. Les 4 composantes sont logées dans un buffer 64bits comme des textures et l’assemblage se fait par blending. Pour finaliser l’affichage d’un rendu HDR, il doit être converti en 32bits via le tone mapping. L’AVIVO peut appliquer ce fameux tone mapping mais cette unité n’est pas accessible directement via DirectX. Pour contourner le problème, ATI passe par un format de texture FourCC et le pilote se charge alors de faire appel à l’unité AVIVO afin de rendre finalement l’image. Si les Radeon X1800 prennent en charge le blending en FP16, elles font l’impasse sur le filtrage en FP16 comme leurs concurrentes.


Par contre, ATI propose une belle innovation avec le support de l’Anti-Aliasing et du HDR en même temps ! Avec l'Adaptative Anti-Aliasing qui active un anticrénelage de type SuperSampling sur les textures avec une transparence (feuilles, grillages) et un de type MultiSampling sur le reste de la scène. Les résultats sont particulièrement probants…


AVIVO

Il est amusant de constater qu’ATI qui a été un des pionniers en intégrant une assistance à la décompression vidéo MPEG2 utilisée dans les DVD-Vidéo n’a jamais (contrairement à NVIDIA et à son PureVidéo) communiqué sur le sujet. Le Canadien n’a même jamais pensé à donner un nom à l’ensemble de ces fonctions. Le tir est à présent corrigé avec AVIVO même si fondamentalement peu de choses ont changé. On retrouve l’aide à la décompression MPEG2 et WMV9 HD mais la fonction semble actuellement poser des problèmes. Très à la mode, le nouveau codec H.264 est aussi pris partiellement en charge par les nouveaux Radeon. Par contre, comme la (dé)compression MPEG4 annoncée avec les GeForce 6800 et Radeon X800, cette fonctionnalité n’est en l’état actuel des choses… pas fonctionnelle ! Affaire à suivre…


Bilan théorique

C’est le nouveau contrôleur mémoire qui nous a le plus impressionné. Sur le papier, ce système est réellement impressionnant et nous semble clairement une bonne base pour l’avenir. Les prochaines générations de VPU devraient toujours y faire appel et ne devraient donc pas avoir de problèmes de bande passante mémoire. Des surprises sont certainement à attendre notamment avec les prochaines générations de puces mémoire…
Les Vertex Engines ont augmenté en nombre et supportent les Shaders 3.0 mais font l’impasse sur le Vertex Texturing. Outre une puissance géométrique très élevée liée à la fréquence des Radeon, les unités de Vertex Shader du R520 n’ont « rien de spécial ». Par contre, le nouveau Pixel Shader Engine et son Ultra-Threading Dispatch Processor permettent une bien plus grande souplesse au niveau de l’architecture que les pixel pipelines plus rigides des X800/X850. L’Ultra-Threading nous semble très bien adapté à une utilisation intensive des shaders model 3.0.
ATI ne s’est pas contenté de seulement intégrer le HDR puisqu’il a implémenté le HDR avec support de l’anticrénelage. Il en va de même pour le moteur vidéo qui hérite enfin d’un nom commercial et du support des codecs WMV9 (buggé) et H.264 (non fonctionnel).
Dans l’attente des cartes pour réaliser nos tests, la nouvelle architecture d’ATI nous paraît très porteuse… Enfin, la situation actuelle n’est pas sans rappeler la sortie des NVIDIA Riva TnT et des ATI Rage 128. On retrouve ATI en retard mais avec une architecture tout en finesse et NVIDIA déjà présent avec beaucoup de puissance brute.