Mercredi a été lancé le G80 ou GeForce
8800, nouveau GPU de chez NVidia. Il s’agit du premier GPU supportant les
nouvelles fonctionnalités de DirectX 10 Il est doté pour cela d’une
architecture totalement nouvelle sur laquelle très peu d’informations n’avaient
filtré jusqu’a sa sortie officielle.
Je vais faire une petite review de ce GPU en commençant par décrire
rapidement l’architecture du GPU. Ensuite je présenterai ce qui me semble
intéressant et ce que j’ai pour l’instant découvert dans les nouvelles
extensions OpenGL que NVidia propose avec.
Architecture.
L’une de ses caractéristiques
principales, et surtout l’une des grosses surprises de cette architecture, est
l’unification des unités de shaders. Alors que ATI avait annoncé depuis de
nombreux mois que le R600 (la prochaine génération de GPU ATI supportant
DirectX 10) serait doté de ce type d’architecture (qu’il avait déjà expérimenté
sur le Xenos, le processeur de la
XBox 360), NVidia avait toujours affirmé que ce type
d’architecture n’était pas encore viable et qu’il en développerait une quand
cela aurait un sens. Finalement il semblerait que NVidia travaillait en secret
sur cette architecture depuis 4 ans…
Les étapes de Vertex Shaders, Fragments
Shaders et maintenant de Géométrie Shader (je reviendrais dessus un peu plus
loin) sont donc mises en œuvre matériellement par un ensemble de 128 unités de
traitement de flux (« Streaming Processor » ou SP) identiques et
« génériques » pouvant être allouées dynamiquement à chacune des
étapes (Vertex, Fragment ou Geometry). Ceci permet ainsi d’équilibrer la charge
de calcul de ces étapes sur l’ensemble des unités de traitement.
Ces unités ne sont plus vectorielles à
4 composantes comme l’étaient les unités de traitement de sommets ou de
fragments mais sont maintenant scalaires. Ceci permet ainsi de traiter à pleine
vitesse aussi bien les algorithmes vectoriels (ou vectorisés) que les
algorithmes sur des scalaires. La nécessitée de vectoriser les opérations
scalaires disparaît donc.
Les 128 unités (SP) sont regroupées en
8 groupes de 16 unités fonctionnant de manière synchronisée ce qui fournit
ainsi un parallélisme MIMD de largeur 8 dont chaque voie fonctionne en SIMD de
largeur 16.
Les SP disposent de plus d’une zone de
mémoire partagée permettant l’échange rapide d’informations entre elles. Ceci
rappel ainsi énormément l’architecture des processeurs Cell d’IBM/Sony/Toshiba dont
la particularité des SPE par rapport aux unités de fragment shaders des GPU
était justement cette capacité à s’échanger très rapidement des informations et
ainsi permettre un streaming en pipeline. Ceci est extrêmement intéressent en
particulier pour les calculs de collisions et de dynamique (pour l’optimisation
du lancer de rayons également) et c’est sans doute en grande partie dans
l’optique de l’accélération physique que NVidia à fait ce choix. Il n’est pas
sur que le R600, prochaine puce ATI, dispose de cette fonctionnalité.
D’ailleurs à ce sujet une des
étrangetés du G80 est la séparation des fonctions de traitement des signaux de
sorties vidéo dans une puce séparée du GPU. Je me demande si ce choix n’a
pas été fait dans l’optique de proposer une déclinaison du G80 dédié
exclusivement au GPGPU/Stream Precessing (ou a la physique en particulier) dépourvue
de sortie vidéo, sur le même modèle que la FireStream 2U d’ATI.
Les architectures précédentes
alimentaient en parallèle les fragment programs via un pipelining très profond,
dans le but de recouvrir au maximum les latences d’accès aux textures (les
unités de textures étant totalement liées aux unités de shaders). Mais ce
pipelining ne suffisait généralement pas a recouvrir totalement les accès
textures (principalement à cause de la limite en nombre de registres
disponibles, plus un programme utilise de registre et plus la hauteur du
pipeline se trouve limité). Il nécessitait de plus un traitement identique pour
un grand nombre de fragments.
Sur le G80, ces unités passent à un
mode de fonctionnement totalement threadé (sur le même modèle que le R520
d’ATI). Les unités de textures sont entièrement désynchronisées des unités de
shaders (elles tournent même physiquement à une fréquence d’horloge différente)
ce qui permet un recouvrement total des accès par des calculs. Un ordonnanceur
est ainsi capable de suspendre l’exécution d’un processus (shader) le temps du
chargement de données de textures et d’en activer un autre pour des calculs.
Les opérations de branchement
dynamiques sont ainsi largement plus efficaces sur cette architecture et
nécessitent beaucoup moins de cohérence spatiale des données.
Avec cette unification et ce threading,
c’est en fait tout le pipeline matériel qui disparaît au profit d’une
architecture de processeur multi-threadé. De ce fait, ceci rend possible la
récupération de données issues de toutes les étapes de shaders (Vertex,
Fragment et Geometry) via ce qui est appelé « stream outputs » dans
Direct X. Il est également possible de désactiver des étapes du pipeline, comme
la rasterisation par exemple pour n’utiliser simplement que les vertex et
geometry shaders pour transformer un maillage que l’on souhaite ensuite
récupérer.
Dernières petites choses le filtrage de
textures (et le blending) FP32 est maintenant totalement supporté, 8 render
targets (MRT) sont disponibles (contre 4 précédemment), un early-depth plus
performant est fournit et un depth buffer flottant est présent.
Reste maintenant à voir les
performances de tout ca, il semblerait en tout cas d’après les tests effectués
sur les jeux (basés sur le pipeline OpenGL classique et DirectX9 et n’utilisant
donc pas encore les nouvelles fonctionnalités) que cette architecture soit déjà
deux fois plus puissante que le haut de gamme précédent.
Des review et plus de détails sur
l’architecture et les nouvelles fonctionnalités peuvent être trouvés dans les
tests de ces magazines en ligne :
- http://www.beyond3d.com/reviews/nvidia/g80-arch/index.php?p=01
- http://www.hardware.fr/articles/644-1/nvidia-geforce-8800-gtx-8800-gts.html
- http://www.clubic.com/article-61974-1-nvidia-g80-geforce-8800-gts-gtx.html
- http://www.presence-pc.com/tests/geforce-8-496/
|
Written by Visiteur on 2008-05-15 23:03:40
 |
Powered by AkoComment 2.0! |
