ATI Radeon X800 XT et X800 Pro

Publié le 04/05/2004 par et
Imprimer
Un nouveau GPU, une vieille architecture
Une nouvelle génération de GPU est habituellement accompagnée d´une nouvelle architecture ce qui permet au GPU de passer à un pallier supérieur et d´offrir de nouvelles possibilités. Avec les X800, ATI déroge à cette règle. Dès lors, pouvons-nous réellement qualifier les Radeon X800 de "nouvelle génération" ? Nous sommes tentés de répondre à cette question par la négative. Les Radeon X800 correspondent plutôt à une simple évolution des Radeon 9700/9800. Simple ... mais pas inintéressante et encore moins transparente !

Cette évolution que nous qualifions de "simple" consiste principalement en un dédoublement du nombre de pixel pipelines. Ainsi, ATI ne leur a pas apporté de modification importante mais en a placé 16 dans les Radeon X800 au lieu de 8 dans les Radeon 9700/9800. Ensuite ATI a augmenté la puissance géométrique en ajoutant 2 unités de vertex shader, ce qui en porte le nombre à 6. Pour parfaire ce gain de puissance, ATI est passé à une gravure de fabrication en 0.13µ, ce qui permet de plus hautes fréquences. Au final, le X800 XT avec 160 millions de transistors à plus de 500 MHz ne consomme et ne chauffe pas beaucoup plus qu´un Radeon 9800 avec 117 millions de transistors à 412 MHz.


Il faut noter que seul le X800 XT est doté de 16 pixel pipeline : tout en utilisant la même puce, le X800 Pro, qui sera moins cher, ne dispose de 12 pixel pipeline actives.

Autour de ces ajouts de blocs de calcul, ATI a optimisé légèrement le GPU pour les hautes résolutions en apportant quelques modifications mineures à l´Hyper Z qui du coup passe en version HD. Par exemple ATI a légèrement augmenté la taille des buffers utilisés par le Hierarchical Z (système d´éjection des blocs de pixels masqués) afin qu´il puisse fonctionner correctement en très haute résolution, ce qui n´était pas le cas avant selon le fabricant.
Augmenter la qualité à moindre coût : 3Dc
ATI profite du lancement du X800 pour introduire une nouveauté particulièrement intéressante bien qu´en partie d´ordre logiciel. Elle se nomme 3Dc et concerne la compression des textures, mais pas de n´importe quelles textures. Une texture est avant tout un tableau de données qui peut contenir des couleurs (un dessin comme c´est le cas habituellement) ou d´autres informations. La complexité d´un objet tel que nous la percevons dépend en grande partie de la manière dont il interagit avec la lumière. Plus un objet contient de polygones, plus la lumière renvoyée sera précise et plus l´objet semblera complexe. Malheureusement, il n´est pas possible d´afficher des objets extrêmement complexes car les performances en souffriraient trop et ils prendraient trop de place en mémoire. Une astuce est d´utiliser une texture (appelée "normal map") qui contient (ou peut être utilisée pour calculer) de fausses informations sur la manière dont l´objet va interagir avec la lumière. Il s´agit de bump mapping.


Ainsi, au lieu de calculer la manière dont la lumière doit être traitée par rapport au nombre réduit de polygones de l´objet, il suffit d´extraire la réponse précalculée dans la texture. L´illusion est souvent impressionnante car ces textures sont générées par les développeurs à partir d´objets de très haute complexité. Le problème est que ces textures peuvent prendre beaucoup de place en mémoire et ne peuvent pas être compressées par les méthodes habituelles sans produire d´artéfacts visuels. C´est ici qu´intervient le 3Dc.


Le 3Dc est une variante optimisée d´une technique similaire qu´ATI réalisait avec le format de compression standard DXT5 et quelques petites astuces. Grossièrement, le 3Dc permet de faire proprement ce qui était du bricolage avec le DXT5. Il permet de réduire par 4 la taille de ces textures sans entraîner une perte visible de qualité. Le 3Dc a un coût, léger mais présent, sur les performances. Une normal map contient des vecteurs qui appartiennent à un espace à 3 dimensions. Ils ont donc chacun 3 coordonnées : x, y et z. En 3Dc, la composante z n´est pas encodée dans la texture mais calculée dans le pixel shader. Cette opération nécessite 2 instructions qui peuvent profiter du co-issue (traitement en parallèle), ce qui signifie que le coût du 3Dc est de 1 cycle. Son influence dépend donc de la taille du pixel shader. Plus il sera complexe plus le coût du 3Dc tendra à disparaître.
Vos réactions

Top articles