Nvidia GeForce GTX 280 & 260 - version imprimable

Nvidia GeForce GTX 280 & 260
Cartes Graphiques
Publié le Lundi 16 Juin 2008 par Damien Triolet

URL: /articles/723-1/nvidia-geforce-gtx-280-260.html

Page 1 - Introduction

Enfin ! Après de très longs mois d'attentes, un nouveau "gros" GPU débarque. Ce GT200 développé par Nvidia pousse plus loin l'architecture GeForce 8 et promet de pouvoir remplacer une GeForce 9800 GX2 par une carte équipée d'un seul GPU.

Un énorme GPU : pas facile

Jen Hsun Huang a régulièrement réaffirmé l'engagement de Nvidia à continuer le développement de solutions graphiques haut de gamme monolithiques, entendez par là équipées d'un seul gros GPU et non de 2 puces plus modestes. Un discours qui tranche avec ce qui semblait se dessiner : GeForce 9800 GX2, Radeon HD 3870 X2… Si cette stratégie convient à AMD qui ne dispose malheureusement que de ressources limitées, Nvidia voit les choses différemment.

Jen Hsun Huang, CEO de Nvidia, n'a pas peur de financer le développement d'énormes GPUs.
Un gros GPU est rentable pour Nvidia, tout d'abord parce que la marque GeForce a le vent en poupe et donc se vend bien, ensuite parce que Nvidia peut exploiter ces gros GPUs sur d'autres marchés très rentables avec les Quadro et si tout se passe bien avec les cartes Tesla, c'est tout du moins le pari de Nvidia. Du coup, pourquoi se priver ?

Le GT200 fait ainsi dans la démesure. Il s'agit du plus gros GPU jamais fabriqué avec ses 1.4 milliards de transistors gravés en 65 nanomètres. Un challenge pour TSMC. La taille de la puce doit avoisiner les 600 mm², du jamais vu, alors que la précédent monstre en terme de taille était le G80 des premières GeForce 8 avec pas loin de 500 mm².

Le die du GT200 est énorme.
Concevoir un tel GPU n'est pas aisé, du coup il a pris du retard. Jen Hsun Huang, l'avait indirectement annoncé pour la fin de l'année 2007, c'est donc seulement 6 mois plus tard qu'il est prêt à être commercialisé. Ce GT200 n'est donc pas une réaction au RV770 d'AMD comme certains ont pu le dire même si il arrive à point nommé pour ne pas laisser AMD reprendre temporairement les devants. Le retard de ce GT200 explique en partie le désordre dans la gamme Nvidia GeForce 8 et 9 puisqu'il semble évident que son absence ait posé problème.

Du coup Nvidia entend faire table rase sur les précédentes dénominations de ses GPUs. Le nom de code du GT200 a lui aussi changé plusieurs fois (vous remarquerez d'ailleurs qu'il est écrit G200 sur la puce et non il ne s'agit pas d'une puce Matrox). Les cartes graphiques qui l'embarqueront seront nommées GeForce GTX 200, avec des modèles 280 et 260 au départ.

Mais que peut-on faire avec 1.4 milliards de transistors et la base de l'architecture GeForce 8 ?

Page 2 - Architecture : SIMT vs MIMD, GeForce 8,9

SIMT vs SIMD vs MIMD

Avec les GeForce 8, Nvidia a introduit une architecture en rupture totale avec le passé. Ainsi, fini les énormes unités vectorielles MIMD dont il est parfois difficile de tirer le maximum. Le choix a été fait pour des unités scalaires. Si au niveau de l'implémentation il s'agit d'unités SIMD (comme le SSE) larges de 256 bits (8 x 32 bits), sur le plan fonctionnel, ce n'est pas une instruction de 8 opérations 32 bits qui est appliquée sur 1 thread/élément à chaque cycle, mais bien 1 opération 32 bits sur 8 threads/éléments. Du coup en pratique, pour l'extérieur, ces unités se comportent comme des unités scalaires.

Pour marquer cette différence avec le SIMD (Single Instruction Multiple Data), Nvidia parle de SIMT (Single Instruction Multiple Threads). Si les unités sont similaires, le SIMT permet de maximiser l'utilisation des unités naturellement si la tâche à accomplir est massivement parallèle, comme c'est le cas pour le rendu 3D. L'intérêt étant qu'en SIMT, le programmeur n'a rien à faire pour que ce soit le cas, alors qu'en SIMD, le programmeur et le compilateur doivent s'efforcer de remplir l'unité vectorielle, ce qui n'est pas toujours simple. Le MIMD (Multiple Instructions Multiple Data), tel qu'exploité par AMD dans les Radeon HD 2000/3000 souffre du même problème, même s'il est plus flexible.

Le SIMT n'est bien entendu pas la solution ultime, puisqu'il s'agit toujours de compromis. Plus efficace il est aussi plus gourmand en termes de transistors, de surface sur la puce et de consommation puisqu'il a besoin d'une logique de gestion plus complexe. Le SIMD et le MIMD permettent par contre de placer plus d'unités de calcul dans le GPU, au prix d'une efficacité moindre.

Les GeForce 8 sont ainsi nées avec seulement 128 unités scalaires alors qu'une Radeon HD 3870 contient 64 unités vec5, soit l'équivalent de 320 unités scalaires. L'efficacité supérieure du SIMT n'est bien entendu pas suffisante par rapport à cette différence. Par contre, Nvidia est parvenu à implémenter des unités de calcul de type double pumped, c'est-à-dire fonctionnant à une vitesse double par rapport au scheduler. De quoi cette fois compenser largement, mais au prix d'une réduction de l'efficacité dans les branchements, nous en parleront dans la section qui y est dédiée.

Architecture GeForce 8/9 et GTX 200

Les GeForce 8 et 9 sont équipées d'un certain nombre de blocs d'unités de traitement ou de partitions. Chacune de ces partitions contient 2 multiprocesseurs et 1 bloc d'unités de texturing. Le multiprocesseur est composé d'un scheduler, d'un espace de 8192 registres 32 bits, d'une unité SIMT composée de 8 processeurs scalaires de type FMAD (multiplication et addition flottantes en un seul cycle) et de 2 unités dédiées aux fonctions spéciales (SFU) telles que sin, cos, log… (qui sont donc 4x plus lentes que les instructions simples). Ces 2 unités peuvent également fonctionner à la manière d'un processeur SIMT composé de 8 processeurs scalaires de type FMUL.

Les 2 groupes d'unités (FMAD et SFU/FMUL) peuvent travailler en parallèle puisque les GeForce 8/9 supportent le dual issue. Par contre des limitations semblent exister et il n'est pas facile d'exploiter les unités FMAD et FMUL en même temps. Il est en effet difficile pour le compilateur et pour le scheduler de les utiliser en même temps puisqu'il faut alors que les instructions soient indépendantes et pouvoir accéder à tous les registres nécessaires en même temps. Du coup, la plupart du temps, c'est l'unité FMAD qui se charge des instructions FMUL, seules les fonctions spéciales étant exécutées en dual issue. Cela a évolué avec les pilotes au fil du temps ceci dit.

Sur le plan des unités de texturing, au départ il y avait 4 unités d'adressages et 8 unités de filtrage par partition, capables donc de débiter 4 texels avec filtrage bilinéaire, trilinéaire ou anisotrope 2x. Après le G80, Nvidia a cependant mis à jour légèrement ses puces en rajoutant 4 unités d'adressage supplémentaires. Du coup, les partitions des GeForce 8 suivantes et des GeForce 9 sont capables de débiter 8 texels avec filtrage bilinéaire ou 4 texels avec filtrage trilinéaire ou anisotrope 2x.

Page 3 - Architecture : GeForce GTX 200

GeForce GTX 200

Avec le GT200 qui équipe les GeForce GTX 200, Nvidia s'était bien entendu fixé comme objectif de proposer un GPU plus performant. Que faire donc sur base de l'architecture GeForce 8 ? Mettre 2 G80 sur une même puce ? 256 processeurs scalaires au total, 128 unités de texturing. Simple, non ?

Ce n'est jamais aussi simple. Doubler l'existant résulte rarement en des performances doublées, d'autant plus que des inconvénients tels que la consommation et donc la chaleur dégagée peuvent devenir tels qu'ils vont pousser à réduire les fréquences à la baisse, et donc réduire le gain de performances.

Nvidia a donc tout d'abord cherché à savoir ce qui était le facteur limitant sur GeForce 8/9 et essayer d'estimer ce qui le serait à l'avenir. La conclusion en a visiblement été qu'il fallait plus de puissance de calcul et plus de registres et que les unités de texturing ne devaient pas obligatoirement croître énormément en nombre.

Les partitions du GT200 recoivent un multiprocesseur de plus par rapport à celles des GeForce 8 et 9, portant leur nombre à 3.
Du coup, Nvidia a ajouté un multiprocesseur par partition, qui en contiennent maintenant 3 et a doublé le nombre de registres de chaque multiprocesseur qui passe à 16384. Plus de registres veut dire que le compilateur a plus de flexibilité pour produire une suite d'instructions optimale et que le GPU peut masquer plus efficacement les divers latences, par exemple lors de l'accès aux textures. Pour rappel, le GPU jongle avec de nombreux threads (pixels, vertices etc) pour masquer la latence et les données de tous ceux-ci doivent rester dans les registres. Ensuite, Nvidia est passé de 8 partitions à 10, pour un total donc de 240 processeurs scalaires. Au niveau des registres généraux, sur l'ensemble du GPU, on passe de 131072 à 393216 x 32 bits !

L'architecture du GT200.
Une unité supplémentaire vient prendre place dans les multiprocesseurs du GT200 : un FMAD 64 bits. Cette unité permet au GT200 de supporter la précision de calcul sur 64 bits en flottant. Etant donné qu'une seule unité est présente, le débit est 8x moindre par rapport à l'unité SIMT composée de 8 processeurs scalaires 32 bits. Qui plus est, en 64 bits, 2 registres 32 bits doivent être utilisés, ce qui limite encore un petit peu plus les performances. Ce support n'est donc pas destiné à être le plus efficace possible, mais avant tout à être là pour les développeurs qui en ont besoin avec CUDA.

Pas de changements pour les unités de texturing qui profitent simplement du passage à 10 partitions. Par contre Nvidia a indiqué avoir amélioré le scheduler et quelques autres détails de manière à maximiser l'utilisation de ces unités.

Les petits changements de cette nature sont par ailleurs nombreux. La dual issue a été améliorée et il est maintenant plus facile d'exploiter en parallèle FMADs et FMULs. Les ROPs sont maintenant capables de faire du blending à pleine vitesse sur les formats 32 bits (4x 8 bits), alors qu'ils le faisaient à demi vitesse auparavant.

Le buffer de sortie des geometry shaders a été agrandi et est maintenant 6x plus gros. Pour rappel il s'agissait d'un des points faibles des GeForce 8 et 9 qui voyaient leurs performances s'écraser lorsqu'un geometry shader était utilisé pour créer beaucoup de géométrie, par exemple en faisant de la tesselation.

Le GT200 dispose tout comme les Radeon HD 2000 et 3000 d'un processeur dédié à la gestion des transferts PCI Express, il peut donc recevoir ou envoyer des données en même temps qu'il travaille au rendu 3D ou sur un programme divers via CUDA.

Enfin le bus mémoire à été étendu à 512 bits avec 8 contrôleurs 64 bits. De quoi permettre d'alimenter le GPU avec beaucoup de bande passante, sans pour autant devoir utiliser de la mémoire très chère.

Par contre, là où Nvidia n'innove pas, c'est en se bornant à ne pas supporter DirectX 10.1. Comme nous l'avons expliqué à plusieurs reprises il y a un aspect stratégique dans ce choix qui est de ne pas dévaloriser ses autres GPUs par rapport à la concurrence. Un autre aspect est que, si Nvidia supporte certaines parties de DirectX 10.1 (telles que l'accès direct au depth buffer quand l'antialiasing est utilisé) et aide les développeurs à contourner DirectX 10 pour y accéder, d'autres points requièrent des changements plus importants. Par exemple, Nvidia ne dispose pas de grille programmable pour la position des samples en multisampling, ce qui est obligatoire pour supproter DirectX 10.1 et demanderait de revoir en profondeur la partie antialiasing de ses GPUs.

Page 4 - Performances Pixel, Vertex et Geometry Shaders

Performances Pixel Shader

Nous avons testé 2 shaders d’éclairage relativement simples qui représentent un bon compromis entre des débits théoriques et pratiques :

La GeForce GTX 280 est ici 40 à 50% plus véloce.

Nous avons bien entendu cherché à en savoir plus sur les performances dans des situations nettement plus complexes. Nos tests étaient principalement tournés autour de la dual issue. Nous avons ainsi pu constater que effectivement celle-ci était utilisable plus facilement et avons noté par exemple un débit de 1.5 FMUL par cycle, ce qui signifie que les unités FMADs et les unités FMULs fonctionnent bien en parallèle. Par contre ces dernières ne semblent être utilisées qu'un cycle sur 2, nous n'en connaissons pas la raison. Peut-être une limitation liée à l'accès aux registres. La puissance de calcul maximale que nous avons obtenue, avec un shader composé de 2000 FMADs et de 2000 FMULs, est de 664.4 Gflops, soit 70% de la puissance de calcul maximale annoncée de 933.12 Gflops.

Performances Vertex Shader

Nous avons testé les performances en T&L, VS 1.1, VS 2.0 et VS 3.0 dans RightMark :

L’architecture unifiée permet aux GPUs récents d’attribuer toutes les ressources au traitement des vertex shader, ce qui entraîne un gain qui peut être conséquent. Il pourrait d’ailleurs être plus important mais est limité par le débit en triangle des GPUs qui sur toutes les GeForce testées ici est de 1 triangle par cycle. Par contre il est de 0.5 par cycle pour la Radeon HD 3870, alors qu'il était de 1 par cycle sur la Radeon HD 2900 XT. La fréquence plus élevée de la GeForce 9800 GTX joue donc ici en son avantage et fait de ce GPU le plus puissant que nous ayons pu avoir entre nos mains en matière de traitement géométrique (simple).

Performances Geometry Shader

Contrairement à Nvidia, AMD a intégré un cache généralisé pour les lectures/écritures en mémoire à partir du shader core. Celui-ci peut être utilisé d'une manière classique pour le Stream Output qui consiste, comme le requiert DirectX 10 à pouvoir écrire les données qui sortent du shader core sans passer par les ROPs. Il permet également de virtualiser les registres généraux qui peuvent ainsi être illimités.

Une autre utilité est d'utiliser la mémoire vidéo à travers ce cache pour stocker temporairement la masse potentiellement énorme de données créées par les Geometry Shaders lors d'amplification de la géométrie sans quoi les unités de calcul pourraient être bloquées par impossibilité de placer le résultat dans les registres généraux ce qui poserait un problème et à priori un plantage puisque les données géométriques doivent pouvoir rester dans le bon ordre. Par exemple imaginez les triangles 1 et 2 en train d'être décomposés. Le triangle 1 doit être rendu avant le triangle 2. Un GPU étant parallèle, ces 2 triangles peuvent être traités en même temps par le geometry shader qui va les décomposer en une série de plus petits triangles. A la sortie, tous les pixels issus du triangle 1 devront être rendus avant les autres. C'est bien s'il y a assez de mémoire pour tout stocker, il suffit d'attendre que le tout soit terminé et de contrôler que le rendu se fasse dans le bon ordre. Mais si le GPU tombe à court de mémoire alors que les triangles 1 et 2 sont toujours en train d'être décomposés, il est calé.

AMD évite ainsi ce problème. Nvidia doit bien entendu l'éviter également, il n'y a pas d'autre solution. Par contre l'approche de Nvidia est très différente. Nvidia prendrait ainsi le problème dans l'autre sens et au lieu de proposer plus de mémoire pour rétablir l'ordre après, Nvidia réduirait le nombre d'éléments traités en parallèles à un nombre qui permette toujours d'avoir assez de mémoire dans le GPU. Autrement dit au lieu de pouvoir utiliser 128 ou 240 processeurs pour traiter un geometry shader, si Nvidia détecte qu'il peut y avoir un problème ce nombre doit être réduit. Nous ne savons pas exactement à quel point Nvidia doit réduire le traitement en parallèle, mais il est évident qu'il y a là une grosse différence entre Nvidia et AMD, à l'avantage de ce dernier, même si les développeurs font attention à ne pas utiliser de cas problématique.

Pour compenser cela, Nvidia a augmenté fortement la taille de son cache en sortie des geometry shaders : x6. Qu'est-ce que ça donne en pratique ? Nous avons observé les performances à travers une démo de tesselation à base de geometry shader fournie par AMD au lancement des Radeon HD 2900 XT :

Comme vous pouvez le constater, même si les Radeon HD conservent leur avantage, les GeForce GTX 200 améliorent grandement les performances par rapport aux GeForce 8 et 9. Nvidia indique avoir augmenté son cache en correspondance avec ce que les développeurs utilisent et vont utiliser à moyen terme.

Page 5 - Performances Texturing et ROPs

Performances accès aux textures

Nous avons mesuré les performances lors de l’accès à des textures de différents formats en filtrage bilinéaire et en filtrage trilinéaire. Nous avons conservé les résultats en 32 bits classique (8x INT8), en 64 bits "HDR" (4x FP16) et en 128 bits (4x FP32). Nous avons ajouté pour information les performances en 32 bits RGB9E5, un nouveau format HDR introduit par DirectX 10 qui permet de stocker des textures HDR en 32 bits avec quelques compromis. Ces tests ont été réalisés avec un outil fourni par nos confrères et amis de Beyond 3D .

Tout d'abord, en filtrage bilinéaire, vous remarquerez la différence évidente entre la GeForce 8800 Ultra et la GeForce 9800 GTX capable de filtrer les textures 32 bits 2x plus rapidement grâce à la présence de plus d'unités d'adressage. La GeForce GTX 280 est nettement devant la GeForce 9800 GTX alors qui si nous regardons les débits théoriques, ils sont très proches avec respectivement 43.2 GTexels/s et 48.2 GTexels/s. Autrement dit, Nvidia a bel et bien amélioré le rendement de ses unités de texturing puisque nous passons d'un rendement de 78% à 98%. Pas mal.

Ensuite, nous passons au filtrage trilinéaire avec ce second tableau. Ici, le doublement des unités d'adressage des textures n'est d'aucune utilité, et le rendement était déjà très bon, du coup les performances sont sans surprise. Notez que le test n'a pas donné de résultats corrects sur la Radeon HD 3870, mais ses débits sont censés être +/- divisés par 2 par rapport aux débits en filtrage bilinéaire.

Performances des ROPs

Le GeForce GTX 280 dispose de 32 ROPs, contre 24 pour le GeForce 8800 Ultra et 16 pour le GeForce 9800 GTX. Pour rappel les ROPs sont les unités chargées des derniers traitements à effectuer sur les pixels (mélange des couleurs, antialiasing, compression des données et écriture de celles-ci en mémoire). La taille du bus mémoire est en partie liée à cette augmentation.

Pour rappel, non content d’en avoir augmenté le nombre, Nvidia en a amélioré l’efficacité sur GeForce 8 lors des passes qui n’écrivent que la valeur Z en mémoire. AMD est très loin en terme de débit à ce niveau :

Les GeForce sont ici très véloces, nettement plus que la Radeon HD 3870, tout du moins jusqu'en antialiasing 4x. En mode 8x, la Radeon HD 3870 conserve un débit similaire alors qu'il se réduit sur les GeForce, probablement par manque de bande passante mémoire. Le bus 512 bits de la GeForce GTX 280 lui permet cependant de rester devant.

Nous avons ensuite, ici aussi à l'aide d'un outil fourni par nos confrères de Beyond 3D , testé le débit des ROPs quand ils écrivent des pixels en mémoire, d'une manière classique tout d'abord et ensuite avec mélange des couleurs (blending), notamment utilisé pour les effets de transparence.

A l'exception d'un débit plus bas que prévu sur le GeForce GTX 280 en FP32x1, les résultats sont logiques et collent au nombre de ROPs. Le 64 bits est 2x plus lent que le 32 bits et le 128 bits encore 2x plus lent. Quant au 32 bits "FP10", il est géré de la même manière que le FP16 et donc ne profite malheureusement pas d'un débit plus élevé.

Une fois le blending utilisé, nous pouvons constater un net gain pour la GeForce GTX 280 qui profite d'une implémentation à pleine vitesse de cette fonction.

Page 6 - Performances Branchements

Performances branchements

L’une des principales nouveautés qui a été introduite avec l'évolution de la programmabilité des GPUs est le branchement dynamique. Cela permet de rendre l’écriture de certains shaders plus naturelle et d’augmenter l’efficacité d’autres shaders en évitant de calculer une partie de ceux-ci sur les pixels qui n’en ont pas besoin. Par exemple pourquoi appliquer le filtrage très coûteux de l’adoucissement de bordure d’une ombre si le pixel est au milieu de l’ombre ? Un branchement dynamique permet de détecter si le pixel en a besoin ou pas.

Mais tout n’est pas si rose puisque ceux-ci ne sont efficaces que dans des cas bien précis. Les branchements ont une réputation d'être difficile à gérer, c'est particulièrement le cas dans les CPU qui doivent prédire le résultat du branchement à l'avance pour masquer la latence du calcul de celui-ci. Dans un GPU, les pixels sont traités par groupes de dizaines, de centaines voire de milliers de pixels, ce qui permet de masquer automatiquement cette latence. Le problème des CPUs n'existe donc pas réellement. Par contre un autre problème se pose. Les GPUs exécutent leurs instructions sur des groupes d'éléments ou threads. Lors d’un branchement, tous les threads doivent prendre la même branche sans quoi les 2 branches doivent être calculées pour tous, avec des masques pour n’écrire que le résultat de la branche requise.

Dans le cas des GeForce 8, 9 et GTX 200, le GPU travaille sur des groupes de 16 ou 32 threads (vertices, pixels etc.). Pourquoi ces 2 possibilités ? Tout d'abord ce sont des unités SIMT 8-way qui sont utilisées. Il faut donc des groupes d'au moins 8 threads. Ensuite rappelez-vous que les unités de calcul sont double pumped et fonctionnent à la fréquence double du scheduler. Il ne peut donc envoyer une commande qu'un cycle sur 2 du point de vue des unités de calcul. Travailler sur des groupes de 16 threads permet aux unités de calcul d'avoir assez de travail et de ne pas attendre un scheduler plus lent qu'elles. Enfin, travailler sur 32 threads autorise la dual issue. Un coup le scheduler va envoyer une instruction à l'unité SIMT 8-way, un autre coup il va envoyer une instruction aux unités spéciales. Il peut gérer les 2 en alternance et à plein débit grâce aux groupes de 32 threads.

Nvidia peut configurer ses GPUs pour 16 ou 32 threads. Dans le premier cas, les performances en branchement sont améliorées, dans le second cas la puissance de calcul est améliorée grâce à la dual issue. Les groupes de 16 sont activés pour les vertex et geometry shader alors que les groupes de 32 le sont pour les pixel shaders et pour CUDA.

Nous avons développé un petit test qui nous permet de modifier la granularité du branchement, c'est-à-dire le nombre moyen, dans notre exemple, de pixels consécutifs qui vont prendre une même branche. Nous spécifions la branche à prendre par colonne de pixels, une colonne sur 2 doit afficher un shader complexe et l'autre peut passer cette partie du rendu. Des triangles de taille moyenne en mouvement sont affichés à l'écran et traversent ces zones qui utilisent différentes branches, ce qui implique que tant les triangles et leur position que la taille de la colonne influent sur l'efficacité du branchement ce qui est proche d'une situation réelle.

Avec des colonnes étroites, les GPUs ne peuvent pas profiter du branchement pour éviter la partie complexe sur la moitié des pixels, mais par contre doivent traiter les instructions de branchement, ce qui fait baisser légèrement les performances au lieu de les augmenter. Tout du moins sur les GeForce 8, 9 et GTX 280. Tous ces GPUs disposent d'une unité dédiée aux branchements qui travaille en parallèle et masque le coût des instructions de branchement. La Radeon HD 3870 semble cependant la seule à masquer complètement la latence des branchements.

La taille des groupes de pixels sur le GeForce 8800 est de 32 contre 64 pour le Radeon HD 3870, ce qui permet aux puces de Nvidia de prendre les devants. Nous avons mis en évidence une différence surprenante entre le GeForce 9800 GTX et le GeForce GTX 280 qui avec une colonne de 8 pixels est beaucoup plus efficace. Il est probable que le découpage des triangles en pixels se fassent de manière à mieux grouper les pixels proches (et donc susceptibles de prendre la même branche) entre eux, ce qui est bénéfique dans ce cas.

Page 7 - Les spécifications, les cartes

Les spécifications

Notez une fois de plus que les cartes graphiques bi-GPU testées ici sont l'équivalent d'une carte 512 Mo et pas d'une carte 1 Go telle que la GeForce GTX 280 !

Les GeForce GTX 260 et 280 se différencient principalement par le nombre de partitions actives. Si tout le GPU est fonctionnel sur la GTX 280, seulement 8 partitions sur les 10 le sont pour le modèle 260. Le bus mémoire est, lui, ramené à 448 bits avec 28 ROPs contre 512 bits et 32 ROPs pour le nouveau ultra haut de gamme. La différence de prix entre ces 2 cartes est conséquente, puis si la GeForce GTX 280 est lancée à un classique 550€, Nvidia annonce 310€ pour la GeForce GTX 260, une bonne affaire en vue ?

Les cartes

Pour ce test, nous avons reçu des GeForce GTX 280 et 260 de référence de la part de Nvidia. Les cartes reprennent un design complètement fermé comme sur la GeForce 9800 GX2, mais avec un système de refroidissement proche de celui de la GeForce 9800 GTX. La couleur noire ou blanche du logo Nvidia permet de différencier respectivement les GeForce GTX 280 et 260 qui ont une taille similaire aux autres cartes haut de gamme.

Autre petit différence externe : les connecteurs d'alimentation. La GeForce GTX 260 se contente de 2x 6pins contre 1x6 et 1x8 pour la GeForce GTX 280. Mais pourquoi ne pas avoir laissé le connecteur 8 pins sur la GeForce GTX 260 malgré tout, de manière à ce que lui seul puisse être utilisé ???

Vous noterez la présence d'une puce dédiée à la gestion des sorties vidéos, le NVIO2, comme c'était le cas sur les GeForce 8800 GTS, GTX et Ultra.

La GeForce GTX 260 voyant son bus mémoire revu à la baisse, à 448 bits, une puce mémoire (32 bits) disparaît de chaque coté du PCB. Notez qu'il s'agit de puces Hynix 0.8 ns sur les 2 cartes.

Page 8 - Consommation, le test

Consommation et bruit

Nous avons mesuré la consommation des différentes cartes. Ces données sont obtenues à partir des mesures effectuées à la sortie de la prise de courant : il s’agit donc de la consommation totale de l’alimentation de la machine, ici une Cooler Master Real Power M1000 (1000 watts).

L'utilisation du 55 nanomètre et du PowerPlay pour réduire la consommation permet à la Radeon HD 3870 ainsi qu'au modèle X2 de rester très économes au repos. Mais en charge PowerPlay ne permet plus aux Radeon de disposer de cet avantage.

Les GeForce GTX 260 et 280 exploitent maintenant des technologies similaires, pour elles aussi être très économes au repos. Bien entendu, la taille du GPU et l'utilisation du 65 nanomètres fait que les Radeon gardent un avantage, mais Nvidia est bien revenu à ce niveau.

En charge une GeForce GTX 260 affiche une consommation proche de celle de la GeForce 9800 GTX avec pourtant une puissance supérieure et un même procédé de fabrication, pas mal. La GeForce GTX 280 engouffre quant à elle 50 watts de moins que la GeForce 9800 GX2 sur notre système.

Notez que les GeForce GTX 200, tout comme les GeForce 9800 GTX et GX2, sont compatibles Hybrid Power et pourront donc être complètement éteintes une fois utilisées dans un système compatible avec cette technologie tel que le futur nForce 780a pour processeurs AMD. Il faudra attendre cet été pour voir débarquer une possibilité similaire pour les Core 2.

Au niveau du bruit, si les GeForce GTX 260 et 280 sont bien dans la catégorie silencieuses, la GeForce 8800 Ultra reste la référence.

Le test

Pour ce test, nous avons fait appel à 10 jeux dont 4 supportent DirectX 10. Les tests ont été exécutés en 1920x1200 uniquement, parce qu'une résolution plus faible n'est en général pas adaptée à un produit haut de gamme. DirectX 10, le filtrage anisotrope ainsi que le HDR ont été activés dans tous les cas où ils sont disponibles dans le jeu. Enfin, le transparency / adaptive antialiasing était activé en mode multisampling.

Toutes les mises à jour pour Windows Vista disponibles à ce jour en plus du SP1 étaient installées.

Configuration

Intel Core 2 Extreme QX9770
Asus Striker II
4 Go DDR3 1066
Windows Vista SP1
Forceware 177.34
Catalyst 8.5

Page 9 - Vidéo HD, Folding@Home

Video HD

Nous n'avons pas testé les performances en décodage de video HD sur ces cartes puisqu'il n'y a rien de neuf. Le GT200 reprend le VP2, déjà présent dans les derniers produits Nvidia. Pour rappel, celui-ci prend totalement en charge le décodage des vidéos h.264, mais seulement partiellement celui des vidéos au format VC-1.

Précisons que Nvidia a ajouté un profil vidéo HD à son système d'économie d'énergie. Le GPU n'entre donc pas en pleine vitesse lors de leur lecture et se limite au minimum nécessaire, de manière à réduire la consommation tout en garantissant les performances requises.

Pour ce test, Nvidia nous a fourni une version beta de Badaboom, un outil de conversion de vidéo qui exploite le GPU à travers CUDA pour un traitement extrêmement rapide. Nous n'avons pas inclus de test de performances basés sur ce logiciel, celui-ci étant encore trop limité dans sa version beta actuelle. Par contre nul doute qu'il est très rapide et très prometteur.

Folding@Home

Enfin ! Le client GPU de Folding@Home supporte les GPUs Nvidia à partir des GeForce 8. Ce support se fait à travers CUDA et si ce client n'est pas encore publique, il ne saurait tarder à débarquer. Nous en avons testé une version beta, en comparant les résultats obtenus sur la Radeon HD 3870 avec son propre client et les Catalyst 8.3 :

Les GeForce sont ici nettement plus performantes ! Difficile de dire cependant si cela est lié à leur architecture ou à CUDA qui facilite la bonne exploitation du GPU. Il s'agit probablement d'un peu des 2.

Page 10 - Enemy Territory : Quake Wars et Half Life 2 Episode 2

Enemy Territory : Quake Wars

Si Quake Wars est basé sur le moteur de Doom 3, celui-ci a subi quelques évolutions telles que le megatexturing qui permet de faciliter le travail des artistes mais entraîne un surcoût au niveau du "décodage" et de l'accès aux megatextures. Quake Wars est donc un petit peu plus gourmand que Doom 3 et Quake 4.

Nous avons enregistré une démo lors d'une partie contre 8 bots. L'intelligence artificielle n'étant pas reproduite lors du timedemo, elle ne limite pas les résultats qui sont donc moins limités par le CPU qu'en situation réelle, tout du moins contre des bots.

Toutes les options sont poussées au maximum dans le jeu, ce qui inclus un filtrage anisotrope 16x. Le patch 1.4 est utilisé.

Dans ce premier jeu testé, la GeForce GTX 280 se place au niveau de la GeForce 9800 GX2 et est plus ou moins 30% plus rapide qu'une GeForce 8800 Ultra ou qu'une Radeon HD 3870 X2.

Half Life 2 Episode 2

Toujours basé sur le Source Engine, Half Life 2 Episode 2 n'apporte pas de réelle nouveauté sur le plan technique et se contente de mieux utiliser et d'utiliser plus souvent ce dont est capable le moteur, ce qui rend le jeu plus gourmand que ses prédécesseurs. Nous exécutons une démo et toutes les options du jeu sont poussées au maximum, y compris le filtrage anisotrope qui est donc en 16x.

Sous Half Life 2 Episode 2, c'est la GeForce GTX 260 qui est au niveau de la GeForce 9800 GX2, la GTX 280 étant un cran devant. Sans antialiasing, le gain apporté par les nouvelles venues est modeste par rapport aux GeForce 8800 Ultra et 9800 GTX, probablement parce que le moteur d'Half Life 2 Episode 2 repose sur beaucoup d'accès aux textures.

Page 11 - S.T.A.L.K.E.R. et Rainbow Six : Vegas

S.T.A.L.K.E.R.

Nous effectuons un déplacement toujours identique et mesurons le framerate avec fraps. Nous testons le jeu avec un niveau de qualité élevé, éclairage dynamique complet, détails maximums (avec filtrage anisotrope 16x) et ombres des herbes. S.T.A.L.K.E.R. utilise un moteur à base de rendu différé ce qui est fondamentalement incompatible avec du MSAA classique, ce qui rend l'utilisation de l'antialiasing impossible, tout du moins c'est ce que nous pensions, Nvidia ayant fini par trouver une astuce pour l'appliquer malgré tout ! Le patch 1.00006 est utilisé.

La GeForce GTX 280 est ici devancée par la GeForce 9800 GX2 et se retrouve au niveau de la Radeon HD 3870 X2, le multi-GPU étant visiblement plutôt efficace du côté d'AMD dans ce jeu. Cette GeForce GTX 280 est cependant 40% plus performante que la GeForce 9800 GTX et 70% plus performante que la GeForce 8800 Ultra, ce qui est plutôt pas mal.

Une fois l'antialiasing activé les cartes équipées de seulement 512 Mo sont larguées et les Radeon sont absentes du combat, AMD n'ayant pas fait l'effort d'intégrer le support de l'antialiasing.

Rainbow Six : Vegas

Premier jeu PC basé sur l'Unreal Engine 3.0, Rainbow Six : Vegas reste un jeu très gourmand. Nous mesurons les performances sur la scène d'introduction. Le mode HDR est activé, et est plus ou moins obligatoire sans quoi le banding est très présent. Les ombres sont réglées sur "bas", les modes supérieurs entraînant une trop forte baisse de performances dans certains endroits.

Portage de la Xbox 360, le jeu semble naturellement bien aimer les Radeon HD qui partagent une architecture similaire à celle de la puce graphique de la console. C'est donc la Radeon HD 3870 X2 qui domine, même par rapport aux nouvelles GeForce. Tout du moins sans antialiasing puisque avec cet effet activé, les Radeon souffrent d'une grosse chute de performances.
Rappelons que le jeu ne supporte pas l'antialiasing mais que Nvidia et AMD l'ont implémenté dans leurs drivers.

Page 12 - Oblivion et RaceDriver GRID

Oblivion

Nous effectuons un déplacement précisément défini afin qu’il soit toujours identique et que le test soit reproductible. Le HDR est bien entendu de la partie et les détails très élevés ont été sélectionnés.

Dans Oblivion, les cartes bi-GPU s'en tirent bien, surtout la Radeon HD 3870 X2 qui profite de très bonnes performances avec antialiasing. Si la GeForce GTX 280 parvient à afficher 40% de mieux par rapport aux GeForce 8800 Ultra et 9800 GTX avec antialiasing, elle est limitée par le CPU sans ce filtre.

RaceDriver GRID

Pour tester le dernier opus de Codemaster, nous réalisons un déplacement bien défini en mode qualité élevée. Il est basé sur une évolution du moteur de Colin McRae DIRT qui fait disparaître le côté usine à gaz. Le patch 1.1 est appliqué.

C'est la GeForce 9800 GX2 qui l'emporte ici. La GeForce GTX 280 n'est cependant pas très loin. Les Radeon HD 3870 sont larguées, phénomène amplifié par le fait que le multigpu ne semble pas fonctionnel sur la version X2.

Page 13 - Bioshock et Company of Heroes

Bioshock

Premier jeu basé sur l'Unreal Engine 3.0 à supporter DirectX 10, Bioshock est un jeu très réussi graphiquement et ce même en mode DirectX 9 alors qu'il est moins gourmand que Rainbow Six : Vegas. Nous effectuons un déplacement bien défini et toutes les options sont poussées au maximum, en mode DirectX 10.

Sans antialiasing, la GeForce 9800 GX2 domine nettement, l'UE3 appréciant le multigpu. Avec antialiasing, par contre elle fait jeu égal avec la GeForce GTX 280. La GeForce GTX 260 est comme dans beaucoup d'autres jeux, plus ou moins 15% devant les précédentes GeForce simple GPU.

Notez qu'il n'est pas encore possible d'activer d'antialiasing en mode DirectX 10 chez AMD.

Company of Heroes

Company of Heroes ayant reçu un patch DirectX 10 qui apporte un réel plus sur le plan graphique, nous avons décidé de l'ajouter à notre protocole de test. Toutes les options sont poussées à leur maximum.

Nous exécutons le test intégré sur la version 1.72.

Sous ce jeu en mode DirectX 10 la puissance de calcul est très importante et du coup les GeForce GTX s'en donnent à cœur joie. Même la GeForce 9800 GX2 ne peut lutter.

Page 14 - World in Conflict et Crysis

World in Conflict

Très réussi visuellement et très gourmand, il était logique de voir World in Conflict joindre notre suite de tests. Nous exécutons le test interne avec le patch 1.0002. Toutes les options sont poussées au maximum ce qui inclus le mode DirectX 10 et le filtrage anisotrope 16x.

Dans ce jeu, où les Radeon ne brillent guère, les GeForce GTX peuvent profiter de leur surplus de mémoire, surtout avec antialiasing activé. Le jeu est en effet très gourmand en mémoire ce qui pose problème à la GeForce 9800 GX2 une fois l'antialiasing activé.

Crysis

Jeu incontournable, Crysis a été testé avec son patch en version 1.21 (optimisé pour le multi-GPU). Nous exécutons notre propre démo enregistrée sur Harbor. Le test est effectué en mode "High" et en DirectX 10.

Si le succès de Crysis est plutôt mitigé, il reste le jeu le plus gourmand à l'heure actuelle, le jeu pour lequel nous avons besoin de plus de puissance graphique. La GeForce GTX 280 fait ici mieux que la GeForce 9800 GX2, surtout avec antialiasing puisque cette dernière n'a pas assez de mémoire. La GeForce GTX 260 s'en tire elle aussi très bien. Si le jeu devient jouable en 1920x1200 en High avec la GTX 280, cela reste malgré tout limite dans les passages chargés. Par rapport aux précédents GPUs, les performances progressent presque de 50%, ce qui est bien entendu déjà pas mal.

Page 15 - Récapitulatif des performances

Récapitulatif

Bien que les résultats de chaque jeu aient tous un intérêt, nous avons calculé un indice de performances en se basant sur l'ensemble de résultats et en donnant le même poids à chacun des jeux. L'indice 100 a été attribué à la GeForce 9800 GTX en 1920x1200.

L'indice représente très bien les résultats obtenus dans de nombreux jeux : la GeForce GTX 280 est en moyenne 40% plus performante que les GeForce 8800 Ultra et 9800 GTX, sans antialiasing, soit au niveau de la GeForce 9800 GX2. La GeForce GTX 260 est pour sa part au niveau de la Radeon HD 3870 X2 et donc un peu plus de 15% devant les précédentes GeForce.

Avec antialiasing, les écarts se creusent et les nouvelles venues se montrent très à l'aise grâce entre autre à leur mémoire importante. La GeForce GTX 280 fait ainsi 70% de mieux que la GeForce 9800 GTX et 15% de mieux que la GeForce 9800 GX2 avec laquelle la GeForce GTX 260 est au coude à coude.

Notez que pour la partie antialiasing (uniquement) les résultats obtenus sous Bioshock et S.T.A.L.K.E.R. ne sont pas pris en compte, les Radeon ne supportant pas ce filtre dans ces jeux. Vous pouvez cependant consulter le graphe qui les prend en compte ici.

Page 16 - Conclusion

Conclusion

Avec le lancement des GeForce GTX 200, Nvidia réaffirme son leadership sur le haut de gamme et son intention de continuer à fabriquer de gros GPUs puisque le GT200 qui les anime embarque pas moins de 1.4 milliard de transistors.

En retouchant légèrement l'architecture GeForce 8, de manière à améliorer tous les petits détails qui coincent ou qui devraient devenir bientôt une limitation, Nvidia peut maintenant remplacer la GeForce 9800 GX2 avec une carte équipée d'une seule puce : la GeForce GTX 280. Certes dans certains cas elle est devancée par le précédant haut de gamme, mais dans d'autres elle est devant avec une meilleure constance puisqu'elle ne souffre pas des aléas du multi-GPU.

Elle profite également d'une mémoire locale revue à la hausse, qui passe, enfin, à 1 Go, ce qui est utile dans certaines situations complexes, amenées à devenir de plus en plus courantes. Proposée à 550€, cette carte est sans concurrence et n'aura donc aucun mal à se faire sa place chez les amateurs de performances extrêmes qui pourront bien entendu les coupler en SLI ou en triple SLI pour les plus fortunés.

Sa petite sœur, la GeForce GTX 260 est un cran derrière en termes de performances, mais reste malgré tout devant la GeForce 9800 GTX. Son prix fixé à 309€ est particulièrement intéressant et témoigne d'une compétition à venir avec la Radeon HD 4870… Mieux vaut donc attendre la semaine prochaine pour savoir qui l'emporte. En réalité, vous n'avez pas le choix, elle ne sera disponible qu'à partir du 26 juin et, à ce moment là, la comparaison entre les 2 aura été faite.

Vous l'aurez compris, si le GT200 qui anime ces cartes est en retard, si l'architecture de base reste la même, si augmenter de 50% les performances en près de 2 ans n'a rien d'extraordinaire, si le fait que Nvidia se borne à ignorer DirectX 10.1 agace, nous somme malgré tout séduits par ce GPU qui semble très bien équilibré et paré pour l'avenir qui s'annonce animé pour les cartes graphiques, en témoigne l'arrivée de logiciels capables d'en tirer partie à travers CUDA, tels que Badaboom en encodage vidéo et Folding@Home, mais également l'API PhysX en version GPU.