Les processeurs graphiques - les différentes architectures

Matériel informatique
1

:hello: Bienvenue dans ce topic traitant de l’architecture des processeurs graphiques! :hello:

Ce sujet détaille les différents éléments d’un processeur graphique, depuis l’avènement des processeurs graphiques DirectX9.0 (nvidia GeForce Fx et Ati R300), jusqu’aux derniers processeurs graphiques DirectX10 (nvidia G80 et futur Ati R600)

Notez que ce sujet est volontairement simplifié afin de le rendre accessible au plus grand nombre :jap:

Notez également que ce sujet est encore en construction, la plupart des sections sont encore en développement, des schémas sont prévus etc…

Vous pouvez bien entendu laisser vos impressions, donner votre opinion, signaler des erreurs, etc…

En revanche, ce sujet ne doit pas se transformer en guerre stérile du style “nvidia c’est mieux, ati c’est de la daube …” (ou l’inverse). Merci d’argumenter vos avis lorsqu’ils doivent l’être.

Bonne lecture :jap:

Sommaire

[b]Section 1: L’architecture des “anciens” Gpu DirectX 9.0(GeForce Fx, Ati R300 et R400)

Section 2: L’architecture des Gpu DirectX9.0c (Nvidia Geforce 6 et 7)

Section 3: L’architecture de l’Ati R500, le début de la révolution

Section 4: L’architecture du nvidia G80, … la révolution est en marche…

Section 5: Le R600 d’Ati…[/b]
Edité le 15/08/2007 à 09:05

2

Section 1: L’architecture des “anciens” Gpu DirectX 9.0(GeForce Fx, Ati R300 et R400)

Commençons notre tour d’horizon par les processeurs graphiques Directx 9.0, les Nvidia GeForce FX, Ati R 300, et Ati R500. Bien entendu il existe des différences entre ces différents GPU, mais il existe un point commun que j’ai choisi pour classer les GPU: La compatibilité DirectX9.0.

Ces Gpu supportent tous les trois DirectX 9.0 et donc les Pixel Shaders et Vertex Shaders dans leur version 2.0.

Notez que ma description se concentrera principalement sur le Pixel Pipeline et les unités destinées au traitement des Pixels Shaders, les Pixels Engines (PE).

1.1) Composition générale d’un GPU DirectX 9.0

Je passerai rapidement sur la partie gérant les calculs géométriques, les Vertex Engines, en effet la partie la plus importante pour les performances est la partie “Pixelx Pipelines”. Les architectures de ces GPU n’étant plus d’actualité aujourd’hui, leur description sera réduite dans un premier temps, les détails viendront plus tard. :jap:

1.2) Le pixel Pipeline: notions générales

Le Pixel Pipeline est composé des diverses unités assurant le traitement des Pixel Shader, du plaquage de textures et de la rasterisation (rendu)

Les pixels pipelines des GeForce FX et des Radeon R300 et R400 étant différents, nous allons les voir séparément.

1.3) ATI R300 et R400

Les pixels pipelines des Ati R300 et R400 sont très proches.

Ils sont relativement simples:

Chaque pipeline est équipé d’une unité capable de traiter une adresse de texture en 32 bit et de piloter la seule unité de texturing du pipeline.
On trouve ensuite une unité arithmétique FP24 (précision de 24Bit sur les nombres flottants - à virgule-). Cette unité prend en charge la co-issue (l’unité peut calculer soit 4 composantes - rouge, vert, bleu, transparence - d’un pixel, soit 3 composantes d’un pixel et 1 d’un autre pixel). Cette technique permet d’augmenter les performances (pouvant doubler dans certains cas, en pratique les performances ne sont jamais doublées bien entendu).
En plus de cette grosse unité arithmétique on trouve une unité de calcul plus petite elle aussi FP 24, cette unité permet d’exécuter des traitement simples comme des déplacement de données ou des modifiers. Les modifiers sont des opérations simples du type x2, x4, etc… La présence de cette unité de calcul permet de délester la grosse unité de calcul des calculs simples, la laissant s’occuper des calculs plus complexes.

Il faut noter que la co-issue et les modifiers ne sont presque plus utilisé depuis les pixels shaders 2.0, du coup il revient aux drivers d’optimiser le code à la volée pour tirer le meilleur parti de cette architecture relativement simple, mais très efficace.

A noter que les Radeon 9700 / 9800 Pro disposent de 8 pixels pipelines et que les Radeon X800 / X850 en embarquent 16. :jap:

A la sortie des pixels pipelines on a bien entendu les unité de rasterisation (rendu) s’occupant entres autres du Full Scene Anti Aliasing (Anti crénelage plein écran, adoucissant les effets d’escalier sur le bord des objets.) Ces unités ne seront pas détaillées dans un premier temps, nous nous concentrerons sur les unités principales des pixels pipelines (détaillées elles.)

1.4) Nvidia GeForce FX (aussi appelé nv30)

[center]http://chezjuju.123.fr/to/archis_gpus/dawn_640.jpg

Dawn - démo technologique pour le GeForce FX,
affiché ici par une Radeon X1600 Pro avec FSAA 6x et filtrage anistropique 16x
(cliquer sur l’image pour l’agrandir)[/center]

Les pixels pipelines du GeForce Fx sont bien plus complexes que ceux des Ati R300 / R400:

On trouve tout d’abord une énorme unité de calcul FP 32 (précision de 32Bit sur les nombres flottants) qui peut soit piloter deux unités de texturing, soit effectuer une opération définie par les pixels shaders. Cette unité de calcul est capable de traiter des instructions complexes, comme SINCOS en une seule passe.
A la suite de cette unité principale, on trouve deux petites unités arithmétiques, plus complexes que les combiners utilisé par ATI. ces unités sont capables de traiter les opérations de base.

A noter que le GeForce Fx 5800 / 590ne comportait que 4 Pixels Pipeline en revanche il comportait deux unité de texturing par pixel pipe, soit 8 comme le Radeon R300.

Le GeForce Fx supporte DirectX 9.0 et donc les shaders 2.0, il excede même les spécifications imposées par DirectX9.0: Précision de calcul 32 bits, au lieu de 24, support de Shaders plus complexe que ce qui est nécessaire)

1.5) Les Gpu DirectX 9.0: Synthèse

Le Geforce Fx n’a pas tenu ses promesses face au Radeon R300 (le R400 étant sorti en même temps que le GeForce 6, je ne le comparerai pas au GeForce FX :jap:) et pourtant sur le papier il faisait montre de très grandes qualités: Support de pixels shaders plus complexes que ce qu’imposait DirectX9.0, précision de calcul FP 32, alors que le Radeon supportait une précision de 24 bit.

Pourquoi alors le GeForce FX n’a jamais pu réellement rivaliser face aux Radeon R300?

Tout d’abord parce que la très complexe architecture de nvidia était moins efficace que l’architecture Ati de l’époque: A chaque passage dans le pixel pipeline le radeon R300 peut effectuer une opération sur les pixels shaders (je négligerai ici la présence de l’unité de Combiners pour rendre les explications plus simples) et un accès aux textures, alors que le GeForce Fx peut soit effectuer une opération sur les pixels shaders soit deux accès à une texture (ou un accès à deux textures différentes).
Etant donné que les unités de texturing et la grosse unité de calcul FP32 ne peuvent pas fonctionner en même temps, l’efficacité du pixel pipeline baisse.
De plus il ne faut pas oublier quelque chose de très important: La précision de calcul des pixels shaders sous DirectX9.0: Il s’agit d’une précision 24 bit, bien entendu les développeurs de jeu ont utilisé les spécifications Directx pour que leurs jeux tournent sur le matériel Directx9.0 sans problème.
Du coup, cela pose un problème au GeForce Fx: Ses unités de calcul conçue pour fonctionner en 32 bit (elles peuvent également fonctionner avec une précision de 16 bit, cela améliorant les performances, mais dégradant, c’est logique la qualité finale.) sont inadaptées au calcul en 24 bit, du coup nvidia a jonglé avec ces drivers entre les modes 32 et 16 bit pour maximiser les performances tout en limitant au maximum la déperdition de qualité.
De plus (cela ne concerne que le GeForce Fx 5800) nvidia a commit une très grosse erreur stratégique en utilisant un bus mémoire DDR2 (cette mémoire fonctionnant à hautes fréquences participait d’une manière importante au dégagement thermique élevé) 128Bit. Le fait d’utiliser un contrôleur mémoire 128Bit bridait la bande passante de la mémoire graphique. (le Radeon R300 utilisait lui de la mémoire DDR1, avec un bus 256 bit.)

Conclusion: En dépit de son architecture permettant de faire face à des calculs très complexe, le GeForce FX n’a jamais pu réellement distancer son concurrent, le Radeon R300, qui avec son architecture plus simple était tout bonnement plus efficace, les jeux utilisaient massivement des shaders faisant appels à des calculs simples, l’architecture du GeForce FX n’était pas exploiter de manière optimale. :jap:
Edité le 16/09/2007 à 22:46

3

Section 2: L’architecture des Gpu DirectX9.0c (Nvidia Geforce 6 et 7)

2.1) Le GeForce 6 (GeForce 6800Ultra, aussi appelé: nv40)

[center]http://chezjuju.123.fr/to/archis_gpus/nalu_640.jpg

Nalu - démo technologique pour le GeForce 6,
affiché ici par une GeForce 6800Gt (merci à SanYohan pour cette capture :jap: )
(cliquer sur l’image pour l’agrandir)[/center]

Partant du constat que l’architecture du GeForce FX n’était pas pleinement efficace, nvidia a décidé de sortir l’artillerie lourde pour rattraper son retard!
Le Ge Force 6800Ultra est composé de pas moins de 16 Pixels Pipelines(!) arrangés en 4 groupes de Quad pipelines de type SIMD (Single Instruction Multiple Data): les 4 pixel pipelines exécutent la même instruction sur des pixels différents.
Notez également que le GeForce 6 supporte DirectX9.0c (les Pixel et Vertex Shaders 3.0).

Commençons notre tour d’horizon par le Pixel Pipeline du GeForce 6800Ultra (nv 40):

Sachez que vu le manque d’efficacité du pixel pipeline du nv30, on aurait pu penser que nvidia allait concevoir des pipelines plus simples sur le nv40. Il n’en est rien, nvidia utilisant ici des pipelines encore plus complexes que ceux du GeForce FX.

Pour bien comprendre, il y a un petit schéma :stuck_out_tongue:

http://chezjuju.123.fr/to/archis_gpus/archi_nv40.png

Les pixels pipelines du Nv40 disposent comme ceux du GeForceFX d’une unité arithmétique (ALU 1)contrôlant la seule unité de texturing par pixel (exit donc la possibilité de faire du dual texturing.). Cependant il y a une différence avec l’unité de calcul du GeForce FX, contrairement à ce qui se passe dans ce dernier, l’ALU 1 du NV 40 peut à la fois exécuter certaines instructions des pixels shaders tout en contrôlant l’unité de texturing. De plus lorsque l’Alu n’effectue pas de texturing elle est capable d’effectuer des instructions en co-issue amélioré (l’unité peut calculer soit 4 composantes - rouge, vert, bleu, transparence - d’un pixel, soit 3 composantes d’un pixel et 1 d’un autre pixel, soit , ici 2composantes d’un 1 pixels et 2composantes d’un autre pixel)

L’unité ALU1 perd la possibilité d’effectuer en une passe l’instruction SINCOS, selon nvidia le traitement de cette instruction n’apportait des gain que dans les démos technologiques.

On retrouve ensuite une unité mini ALU, cette unité n’est plus aussi complexe que dans le GeForce FX, elle se rapproche des petites unités du R300, du coup elle n’exécute ici que des tâches simples, comme des déplacement de données ou des modifiers. (Les modifiers sont des opérations simples du type x2, x4, etc… La présence de cette unité de calcul permet de délester la grosse unité de calcul des calculs simples, la laissant s’occuper des calculs plus complexes.)

Vient ensuite une nouvelle unité FP 32 (ALU 2) identique à la précédente (ALU 1) à ceci près que cette unité ne peut ici pas piloter d’unité de texturing. Notez que comme l’ALU 1 elle peut fonctionner en CO-Issue, et ce de manière indépendante (par exemple, l’ALU 1 peut être en train de traiter 3+1 composantes - 3 sur un pixel et 1 pur un autre -, alors que l’ALu sera entrain de traiter 2+2 Pixels)
Pour terminer on retrouve une unité mini Alu. Notez que dans le cas du NV 40 les unités mini ALu ne peuvent être exploités efficacement que grâce à une recompilation dynamique (lors de l’exécution, invisible pour l’utilisateur) du Pixel Shader par le pilote.

Je l’ai déjà dit, le NV 40 supporte le Shaders Model 3.0 et donc les pixel Shader 3.0. Evidemment le Shader Model 3.0 permet de gérer plus d’instructions. Mais la plus grosse nouveauté c’est l’apparition du branchement dynamique (Dynamic Branching).

Le branchement dynamique késako?

C’est très simple à comprendre: Il s’agit simplement d’un test, voici un petit exemple:
Si le Pixel P n’est pas blanc,
alors on le colore en blanc,
sinon, on le laisse comme il est sans le traiter.

Bien entendu mon exemple est très simple, le but du branchement dynamique est donc de n’effectuer certaines opérations que lorsque c’est nécessaire, ainsi le GPu n’est pas obligé d’effectuer les calculs pour tous les pixels… D’où le gain de temps … théorique, car il subsiste un problème:
Chaque groupe de 4 Pixel Pieplines ne peuvent utiliser qu’une instruction pour plusieurs pixels, en clair si au sein du même quad pipe les pixels doivent être traité différemment, ils doivent repasser dans le pipe afin de subir les différents traitements!
Il faut savoir également qu’un test de branchement nécessite du temps pour être exécuté, du coup le branchement dynamique , mal utilisé peut être une manière de ruiner les performances (attention ce n’est pas propres au GeForce 6, mais à tous les GPU, même si le processeur de nvidia est particulièrement sensible à ce phénomène)

Je n’en ai pas parlé jusque là (pour éviter une complication inutile), mais il faut savoir que dans un GPU, les pixels sont traités par blocs (à cause de l’architecture SIMD et des Quads, mais pas seulement), dans le cas des GeForce 6, les pixels sont traités par blocs d’environ 1000 pixels.
Cela signifie que si un seul pixel doit recevoir un traitement différent des autres, les 1000 pixels doivent repasser dans le pipeline! Bien entendu seul les pixels qui doivent être traités le seront, mais ça ne fait rien: si un shader emploie des branchements dynamiques mal conçus, les performances du GeForce 6 peuvent tout bonnement dégringoler.
En pratique toutefois le résultat n’est pas aussi dramatique: le compilateur intégré aux pilotes va optimiser au mieux les traitements.

Le moteur géométrique (Vertex Engine)

Lors du passage au nv40, nvidia a également amélioré les unités de calcul géométrique. Ces unités voient leur nombre augmenter: 3 dans les GeForce FX et 6 dans le GeForce 6.
Les unités géométriques du nv40 fonctionnent en mode MIMD (Multiples Instructions, Multiples Datas), cela permet à chaque unité de fonctionner en co-issue. (l’unité peut calculer soit 4 composantes - rouge, vert, bleu, transparence - d’un vertex, soit 3 composantes d’un pixel et 1 d’un autre vertex).

Bien entendu les unités de Vertex Shading du GeForce 6 supportent les Vertex Shaders en version 3.0, du coup cela permet au Ge Force 6 de gérer 2 nouvelles fonctionnalités de DirectX 9.0C:

Le Geometry Instancing

Le Geometry Instancing permet de traiter des ensemble de polygone en une seule passe. Plus les ensemble (batchs) de polygones sont gros, moins les ressources du processeur central sont solicité pour afficher le même nombre d’objets.

Un exemple simple, dans un jeu qui utiliserait les mêmes objets (jeu de stratégie par exemple), il suffit d’envoyer au GPU, en une fois tous les polygones composants ces objets (véhicules par exemple.) pour les afficher. Cela permet de ne pas avoir a éxecuter plusieurs fois les mêmes commandes au niveau du processeur central, le gain de performances peut être important.

Le Vertex Texturing

Comme son nom l’indique le Vertex Texturing permet aux unités de Vertex (unités géométriques) d’accéder aux textures. dans ce cas, il faut voir les textures non pas comme une “simple” image, mais comme un tableau de données.
Ces textures peuvent ici permettre au GPU d’effectuer via ses unité de vertex des déformations par exemple sur une géométrie existante (Displacement Mapping) (il n’est ici pas possible de créer des polygones à partir du Vertex Texturing).
Il est par exemple possible d’utiliser le displacement mapping pourafficher un sol qui se déforme lorsque le personnage marche dessus (sol enneigé, terrain détrempé etc…)
Sur le NV40 chaque unité de Vertex dispose de sa propre unité de texurting. En revanche il faut bien garder à l’esprit que contrairement aux unités de texturing du pixel pipeline, les unités de texturing du Vertex Engine ne sont pas optimisées pour masquer la latence de l’accès mémoire (eh oui, un accès mémoire est lent par rapport à la vitesse du GPU), utiliser le Vertex Tenxturing peut donc se réveler couteux en terme de performances.

Le Nv40 supporte bien entendu le bien connu effet High Dynamic Range (HDR) qui permet de rendre de manière plus réaliste les effets d’éblouissement et de fort éclairage. Notez qu’à cause d’une limitation matérielle, les GeForce6 ne supportent pas l’effet HDR et l’Antialiasing en même temps, cette limitation est également présent sur les GeForce7.

l’Antialiasing

Au niveau de l’Antialising (Anti crénelage, le filtre supprimant, ou réduisant fortement les effets d’escalier sur les objets 3d), si le mode 2X fonctionne de manière relativement similaire à celui du GeForce FX, le résultat visuel est donc comparable à celui obtenu avec un GeForce FX.
En revanche pour le mode 4X nvidia a revu le placement des points de réference, afin d’offrir un rendu bien plus proche de celui qu’offrent les cartes ATI Radeon R300 / R400, bien plus flatteur que le rendu des carte GeForce FX.

L’Anisotropic Filtering (filtrage anisotrope)

Le filtrage anistrope est un filtrage travaillant sur les textures permettant de réduire l’effet de flou qui se créé sur les textures les plus éloignées.

Peu de choses à dire dans ce domaine, si ce n’est que la qualité de filtrage anisotropique est un brin inférieure sur le Nv40 par rapport aux cartes Ati R300 / R400.

Le tour d’horizon du GeForce6 s’arrête la pour l’instant.
Etant donné que le GeForce 7 a une architecture proche de celle du GeForce 6, je me consacrerait dans un premier temps à la réalisation de la partie traitant de l’architecture Ati X1000.
Edité le 15/08/2007 à 09:04

4

Section 3: L’architecture de l’Ati R500, le début de la révolution

[center]http://chezjuju.123.fr/to/archis_gpus/ruby_assassin_640.jpg

Ruby - The Assassin, l’une des démos technologiques Ati du R5xx (cliquer sur l’image pour l’agrandir)[/center]

L’architecture du Radeon X1800 (l’architecture de tous les Radeon x1k est basé sur cette architecture, vous trouverez plus loin les différences.)

Plongeons nous sans plus attendre, au coeur du sujet, avec un document graphique présentant l’architecture X1000.

http://chezjuju.123.fr/to/archis_gpus/archi_x1k.jpg

(le schéma montre l’architecture du X1800, mes explications seront donc basées sur cette puce, sauf indications contraires de ma part.)

Comme nous pouvons le voir d’entrée de jeu, il n’y à pas de pixel pipeline avec l’organisation que nous connaissions jusqu’alors.

L’architecture du X1000 a été conçu pour obtenir des performances optimales avec le shader model 3.0, ati a fortement optimisé son processeur graphique et ce à tous les niveaux, comme nous allons le voir:

Le pixel shader engine

Même si le pixel shader engine des Radeon 9700 / 9800 / X800 était très efficace, force est de constater que les puces d’Ati avaient pris du retard sur les GeForce 6 / 7, en effet, l’architecture R300 / R400 d’ati ne supporte pas le shader model 3.0, donc les branchements dynamique, l’une des grosses nouveautés des pixels shaders en version 3.0 ne sont pas pris en charge.
Il faut rappeler toutefois que l’architecture Nv40 / G70 de nvidia n’est pas pleinement efficace sur ce type d’instructions, notamment à cause de la disposition du pixel pipeline et du fait que les pixels sont traités par blocs d’environ 1000 pixels (voir la partie sur le GeForce 6 pour plus de détails.)
Bien entendu, le Radeon X1000 supporte le Shader Model 3.0 et donc les branchements dynamiques dans les pixels shaders et ici les branchements dynamiques sont gérés d’une manière bien plus efficace que sur l’architecture, du Nv40 / G70.

Comme on peut le voir sur l’illustration on trouve au milieu du pixel shader engine (car il ne s’agit pas ici d’un pixel pipeline complet comme on a pu le voir jusqu’a maintenant) une unité appelée “Ultra threading dispatch processor”. Cette unité, comme son nom le laisse supposer se dédie exclusivement à la découpe des shaders en threads qui seront traités par les Quad pixels shaders core.
Ici la taille des threads est très petites, 12 pixels (48 sur les Radeon X1900 / X 1600 etc… mais l’augmentation de taille du thread ne nuit en rien au performances.), à comparer aux threads de 1000 pixels que doit traiter le nv40 / G70.

Lorsqu’un thread de pixels arrive dans l’un des quad shaders core (qui dispose de 4 unité de texturing et de 4 unités de calcul des shaders), le pixel shader est exécuté, jusqu’à ce qu’une instruction impliquant une latence, typiquement, une opération sur une texture, dès lors pour ne pas perdre du temps, le thread de pixels est envoyé au bloc de texturing,le résultat temporaire restant lui dans les registres temporaires (“General Purpose Register Arrays” sur le document graphique), une fois que le thread est entré dans l’unité de texturing, un nouveau thread de pixel entre dans le Quad pixel shader core, pendant ce temps, bien entendu, le résultat de l’opération de texturing sur le premier thread est en cours de calcul, une fois celui connu, il repasse dans le quad pixel shader core, jusqu’à ce qu’une nouvelle instruction impliquant une latence soit exécutée, à ce moment là, le thread repasse dans l’unité de texturing. Et ainsi de suite, pour tous les threads de pixels traités.
En clair, au lieu “simplement” masquer la latence comme le fait nvidia avec ses nv40 / G70, l’architecture utilisée par ati pour son pixel shader engine permet d’utiliser un nombre élevé de thread de pixels, ceci garantissant une efficacité élevée dans le traitement des pixels shaders.

Pour revenir plus spécifiquement sur les branchements dynamiques, le fait qu’ati utilise de petits threads de pixel évite que le GPU ait a calculer 2 fois de grands threads de pixels, ce qui permet bien sur de gagner un temps précieux, toujours à ce sujet, notez qu’ati a inclus dans le X1000 une unité qui traite en parallèle les instructions de branchements, du coup le traitement de ces instructions n’ont pas vraiment d’impact (en dehors de l’impact du recalcul éventuel qu’implique un branchement dynamique pour un groupe de pixels) contrairement au nv 40 / G 70 qui prend plusieurs cycles d’horloge pour traiter ces instructions.

Notez toutefois qu’ati n’a pas apporté de grosses amélioration aux unité de calcul proprement dites, on retrouve toujours une grosse unité de calcul et une plus petite capable de fonctionner en co-issue, l’unité la plus petite traite toujours uniquement des instructions simples comme les modifiers (voir les section précédentes pour l’explication détaillé de “co-issue” et de “modifiers”).
Les ingénieurs d’Ati ont bien entendu apporté des modifications aux unités de calcul pour les rendre plus efficaces, notamment en apportant le support native de l’instruction sincos, ainsi cette instruction peut être calculée sans devoir tout d’abord être décomposée.
Au final, nvidia semble conserver avec ses Nv40 et surtout G70 un léger avantage sur ati au niveau de la puissance de calcul brute.
En revanche, là ou la nouvelle architecture d’ati reprend l’avantage c’est au niveau de l’efficacité, la puissance de calcul étant probablement mieux exploité que dans l’architecture des nv40 / G70.

Pour terminer avec le pixel shader engine du radeon x1000, il faut signaler que ce dernier supporte une fonction originale, appellé “scatering” qui permet de sauvegarder à n’importe quel moment une valeur dans la mémoire de la carte graphique et non pas dans les registres du GPU (dont l’espace est relativement faible). ceci est rendu possible ici par la très bonne optimisation du contrôleur mémoire (détaillé un peu plus loin). Concrètement cette fonction permet d’utiliser la mémoire vidéo comme des registres GPU, en nombre quasi illimité, du coup, il est ici possible d’utiliser le GPU comme si le GPU était un processeur central! On appelle ça le GPGPU (Genral Purpose Graphics Processing Unit: Processeur graphique à usage général).

Le vertex shader engine

Ca passage sera relativement bref, le X1800 embarque 8 unités de calcul géométrique, contre 6 pour le X800, les performances géométriques fond bien entendu un bond en avant. Le X1000, supporte bien entendu les vertex shaders 3.0, avec toutefois une exception notable: Le vertex texturing! en effet, le Radeon X1k ne supporte pas le Vertex texturing, même si quelques rares jeux utilisent le Vertex texturing, le vertex texturing est très peu utilisé en pratique, car limité et couteux en performances (les unités de vertex n’étant pas conçues pour masquer l’inévitable latence mémoire.)

Le render to Vertex Buffer (R2VB)

Le X1k ne prend certes pas en charge le Vertex Texturing, en revanche, il supporte parfaitement le R2VB (que ne supporte pas les nv40 / G70 en revanche (du moins les pilotes ne le permettent pas).
Pour faire simple le R2VB permet d’utiliser un résultat issu des pixels pipelines en entrée du vertex shader engine, cela permet notamment de ne pas perdre de temps lors des opérations de texturing étant donné que les unité de texturing sont conçues pour ne pas perdre de temps lors de l’accès au textures. Je ne détaillerai pas plus cette technique , car elle n’a été utilisée, à ma connaissance que sur des démos technologiques. Sachez pour terminer que cette technique est théoriquement utilisable sur toutes les puces directx 9, tant que les pilotes le permettent.

Le High Dynamic Range (HDR)

Ici, Ati rattrape son retard sur nvidia et creuse même l’écart, en effet le x1k supporte sans soucis le HDR et supporte même le HDR avec le FSAA activé chose impossible sur nv40 / G70

L’antialisaing

A venir

Le filtrage anisotropique

A venir

Le contrôleur mémoire

Le contrôleur mémoire du X1000 est une des parties de la puce qui a été le plus optimisées.
Dorénavant les accès mémoire se font sur 8x32 bits (bus mémoire 256bits sur x1800 et x1900 et non plus 4x64bits, cela permet d’optimiser les transferts, de plus, comme vous pouvez le voir sur l’infographie, le contrôleur mémoire utilise un bus dit “Ring Bus”. Ce bus permet de simplifier l’accès à la mémoire pour le GPU, de plus les données accédées peuvent être renvoyés aux unités qui en ont besoin sans repasser par le contrôleur mémoire.

http://chezjuju.123.fr/to/archis_gpus/ctrlmem_x1k.jpg

Notez aussi que le bus mémoire se décompose en 2 voies de 256 bits chacune, une étant réservée à la lecture et l’autre à l’écriture.
Toujours au sujet du contrôleur mémoire, ce dernier peut changer l’ordre des requêtes d’accès mémoire selon l’impact sur les performances, du coup des accès “critiques” pour les performances seront effectués en priorité. De plus ce contrôleur est paramétrable en partie via les pilotes ati, du coup, ati se réserve la possibilité d’améliorer certains algorithmes mémoires via de nouveaux pilotes graphiques.
Pour améliorer encore les performances mémoire ati a également revu le Hierarchical Z (procédé permettant de ne charger en mémoire et de ne calculer que ce qui sera visible sur l’image finale) bien plus précis que sur les générations précédentes ce procédé permet selon ati un gain de 60% face au même procédé du R400.
Edité le 28/08/2007 à 22:16

5

Section 4: L’architecture du nvidia G80, … la révolution est en marche…

Section en cours de réalisation :jap:

6

Section 5: Le futur R600…

Cette section n’est pas encore en réalisation … Il faut d’abord que la puce R600 d’ATI soit disponible :jap:

7

Post de réserve :jap:

8

Post de réserve :jap:

9

Post de réserve :jap:

10

Post de réserve :jap:

11

Topic ouvert

Pour le moment seule la section 1 est disponible, les autres sont en cours de réalisation.

Le titre du sujet n’est pas forcément définitif.

J’espère que ce topic aura du succès, étant donné le travail nécessaire pour le terminer. :jap:

C’est à vous :jap:

12

Bravo, t’as posté trop vite! :paf: :pt1cable:

13

est-ce que tu peux donner des exemples de nvidia GeForce Fx et Ati R300, genre la x1650 de chez ati ou la 7900GS chez nvidia.
car j’ai aucune idée de quelle sorte de carte tu parles … :jap:

14

GeForce FX:

GeForce 5800 / 5900 / 5600 / 5200, puis: 5900 / 5950 / 5700 / 5500

(je passe sur les XT, LE , SE, etc…

Chez Ati:
R300: Radeon 9700 (pro) / 9800(pro) / 9500(pro) / 9600.

R400: X800 / X850

Je passe sur les déclinaisons (genre les GeForce 5600 / 5700 n’avaient plus qu’une seule unité de texturing par pixel pipe.) etc… :jap:

15

:jap:

16

Excellent début pour un topic très prometteur. :super:

Je me permets de poser une question dont je ne comprendrais peut être pas la réponse. :ane:

Il y a de cela bien longtemps les calculs d’affichage étaient dévolus au processeur central si je ne m’abuse. On a cherché à économiser leur puissance alors très limitée en créant les cartes graphiques.
Actuellement les processeurs graphiques sur les cartes haut de gamme sont très puissant.

Avec la création des architectures multicoeurs chez AMD et INTEL, peut on penser que dans le futur il serait techniquement possible de réintégrer à la charge du processeur central les calculs graphiques ?
Par exemple dans un octocoeur : 4 coeurs pour l’OS et les programmes, 2 coeurs pour les graphismes et 2 autres pour le son et la physique.

Ou alors va t’on voir les mêmes technologies que les CPUs intégrer les GPU : en gros une sorte de core 2 duo version graphisme.

Les systèmes juxtapposant 2 cartes graphiques (7950x2) ou le SLI/CROSSFIRE sont ils les prémices de cartes devenant en quelque sorte un ordinateur dans l’ordinateur dédié à l’esthétisme ?

Je sais que tu n’es pas devin mais le fait de t’être plongé dans une histoire des architectures graphiques en quelque sorte t’a t’il donné une intuition de ce que pourrait être l’informatique du futur ?

:slight_smile:

17

Tout d’abord il va être difficile de te répondre précisément sans aller dans des détails très technique et sortir un un pavé indigérrable :ane: Je vais essayer de faire au mieux:

  1. Il faut bien comprendre une chose:
    Même si les processeurs centraux et les processeurs graphiques sont des processeurs (sans blagues :ane: ), il existe une différence fondamentale entre les deux:
    Un processeur central se doit d’être généraliste, cela signifie qu’il doit pouvoir traiter tous (ou presque) les types de calculs, que ce soient des calculs simples, ou très complexes et surtout, il peut s’agir de calculs financiers, sonores, etc…
    De plus les cpu doivent intégrer des unités de gestion (découpage des données, prédiction de branchement etc…)

Les processeurs graphiques, sont eux des processeurs spécialisés, ils intègrent donc des unités de calcul relativement (comparées à celles des cpus) simples et monstrueusement efficace dans leur domaine parce qu’elles n’ont a gérer que des données “prévues” (ce que je veux dire c’est qu’il est impossible dans un cpu de savoir quel type de données on va traiter, alors que pour un GPu, au final traitent toujours des données graphiques et de la même façon.)

Autre différences très importantes:

  1. Les GPU sont déja multicore :ane:

Enfin plus exactement, on peut voir les pixels pipelines (et les unités unifiées de calcul des shaders des GPU DirectX10) comme étant des processeurs indépendants travaillant en parallèle. (ce sera détaillé lorsque la partie sur les ati R500 / R600 et nvidia G80 sera terminée.)
Or dans un cpu, a l’intérieur même d’un coeur seules certaines instructions peuvent être traitées en parralèle.

  1. J’ai déjà plus ou moins répondu: On peut voir la carte graphique comme étant un ordinateur dans le sens elles comportent un GPU et de la mémoire vive dédiée.

  2. Le futur, difficile à dire.

Surement tout d’abord l’apparition de GPU entièrement programmable (notamment la partie assurant le rendu, qui est encore “fixe” (bien que paramétrable) dans les Gpu d’aujourd’hui. Et l’apparition de pas mal d’applications GP-GPU par exemple.

Application GP-GPU: ce sont des applications conçues pour lancer certains calculs pouvant être exécutés en parallèle sur les processeurs graphiques.

Voila j’espère t’avoir répondu, de manière compréhensible :jap:

18

Ca c’est de la réponse de chez réponse. :super:

Merci beaucoup. :slight_smile:

J’ai tout compris (enfin je pense). :ane:

19

Ajout de l’architecture du pixel pipeline du GeForce6.

Le reste de l’architecture du GF6 suivra ainsi que les améliorations apporté à l’architecture par le GeForce 7 :jap:

20

C’était prévu comme ça :lol:

On verra si ça fait vraiment trop gros je changerai l’organisation :wink:

Mais c’est logique, car le GF7 n’est que la “suite” du GF6 :wink: Il y a relativement peu de différences entre les deux. :smiley: