Les contenus liés aux tags Nvidia et Kepler

Lors du lancement de la famille de GeForce 600M, nous déplorions l'absence de nouveauté dans le haut de gamme, principalement constitué de renommages de la famille 500M. Nvidia avant cependant laissé une place pour une GeForce 680M qui est dévoilée aujourd'hui et basée sur l'architecture Kepler.

Il s'agit en équivalent desktop d'une GeForce GTX 670 (largement) sous-cadencée pour tenir dans une enveloppe thermique de 100W destinée au format "transportable". Par rapport aux modèles de bureau, la technologie GPU Boost est passée à la trappe, puisque dans le cas d'une solution mobile elle serait contreproductive : si ce type de turbo consiste bien à maximiser les performances dans une enveloppe thermique donnée, il réduit en réalité le rendement énergétique, chaque augmentation de la fréquence GPU ayant une incidence plus que proportionnelle sur la consommation.


Ses spécifications nous laissent envisager un match très serré avec la Radeon HD 7970M, dérivée de la Radeon HD 7870 de bureau. Par rapport à la génération précédente, la GeForce GTX 580 maintenant dénommée GTX 675, la GeForce GTX 680 devrait afficher un gain significatif de l'ordre de 50%. Nvidia profite ici du rendement énergétique relativement élevé de la génération Kepler.

Alienware, Clevo et MSI seront les permiers à proposer cette nouvelle carte graphique mobile dans des machines de 17 ou 18" en général, bien que Clevo ait un modèle 15.6" de prévu.

Déjà décliné sur portables (GTX660M, GT650M, GT640M et GT630M) ou sur des cartes en version OEM (GT640, GT630), le GPU GK107 doté de l'architecture Kepler débarque sur les cartes graphiques classiques avec la GeForce GT 640. Cette version destinée à l'entrée de gamme n'a toutefois pas grand-chose à voir avec le GK104 puisque le nombre d'unités de calcul passe de 1536 à 384.

Cette déclinaison desktop fait appel à de la DDR3 en 128 bits cadencée à 891 MHz, comme c'est le cas de la GT640 OEM DDR3, mais le GPU passe à 900 MHz contre 797 MHz pour la version OEM. Le GT650M GDDR3 utilise une configuration proche avec un GPU à 950 MHz et de la GDDR3 à 900 MHz.

On notera que la version OEM la plus rapide, la GT 640 GDDR5 qui dispose d'un GPU à 950 MHz et de GDDR5 à 1,25 GHz (soit 2.8x plus de bande passante mémoire), n'est pas encore déclinée. C'est un peu dommage car avec son TDP de 65 watts et un prix conseillé de 99$, la GeForce GT 640 DDR3 devrait se positionner aux alentours de la Radeon HD 6670 GDDR5 en termes de performances, soit assez loin d'une Radeon HD 7750 qui n'est que 10$ plus onéreuse mais 40 à 50% plus rapide pour un TDP de 75 watts.

Avec la famille de GPU Kepler, Nvidia vise un nouveau marché : cloud computing. Nous vous avons déjà parlé du pan professionnel de cette stratégie avec VGX dédié à la virtualisation et nous abordons aujourd'hui l'autre partie : le cloud gaming.

Jouer à travers le cloud revient à transformer n'importe quel périphérique connecté en une combinaison écran / contrôleur de jeu. Toutes les informations de contrôle sont envoyées vers un serveur distant sur lequel le jeu va en réalité tourner. Chaque image calculée par ce serveur est renvoyée vers le client à travers un flux H.264. Les avantages sont multiples : plus besoin d'une puissance de calcul importante du côté du joueur, plus besoin de mettre à jour son matériel pour les nouveaux jeux, possibilité de jouer facilement depuis n'importe quel endroit et périphérique. De quoi révolutionner le petit monde du jeu vidéo.


En contrepartie, cela demande une infrastructure importante du côté des fournisseurs de service et surtout, jouer depuis le cloud augmente significativement la latence. Deux points noirs auxquels Nvidia indique s'attaquer avec GeForce GRID.

Au niveau de l'infrastructure, il faut savoir qu'en règle générale, actuellement, il faut un système/serveur par joueur connecté. Nvidia donne ainsi un exemple actuel de plateforme dédiée au cloud gaming pour laquelle chaque baie accueille 28 serveurs (1 CPU + un GPU) et permet donc de gérer jusqu'à 28 flux de jeu. GeForce GRID permet de faire grimper cette densité en intégrant 4 GPU par serveur. Avec 21 de ces serveurs par baie il est ainsi possible de supporter jusqu'à 84 flux de jeu. Ce n'est pas tout puisque cette approche permet selon Nvidia de faire baisser la consommation typique de 150 à 75W par flux de jeu, un exemple probablement d'un jeu pas trop lourd rendu en 720p.


Comment cela est-il possible ? Tout d'abord au niveau matériel, Nvidia commercialise une carte GeForce GRID qui est en réalité identique à la Tesla K10. Il s'agit d'une version serveur de la GeForce GTX 690, avec des fréquences revues à la baisse pour tenir dans un TDP de 250W, configurable en 225W si nécessaire. Une seule de ces cartes peut ainsi gérer 2 flux de jeu. Nvidia propose d'en placer une seconde dans chaque serveur et probablement d'utiliser sa couche logicielle de virtualisation pour gérer efficacement jusqu'à 4 flux. La présence d'un encodeur H.264 dédié dans les GPU Kepler permet par ailleurs à GeForce GRID de gérer d'un bout à l'autre la récupération des images dans le framebuffer et leur encodage dans un flux H.264, déchargeant totalement le système de cette tâche et libérant le ou les CPU pour gérer ces flux de jeu supplémentaires.


Et pour la latence ? Nvidia nous donne ici aussi un exemple : 166ms pour une console, 286ms pour le cloud gaming actuel et 161ms pour GeForce GRID, en précisant que la latence typique d'un PC récent dans ce cas serait de 75ms.


GeForce GRID gagne sur 3 points : le rendu, l'encodage et le réseau. Pour le rendu, Nvidia suppose qu'avec son GPU, les fournisseurs de service vont traiter les jeux à 60fps au lieu de 30fps, ce qui fait gagner 50ms de latence. Concernant l'encodage il passerait de 30 à 10ms alors que le décodage serait lui aussi plus rapide… sur un composant Tegra.

Enfin, le réseau deviendrait lui aussi beaucoup plus rapide. En creusant un peu, Nvidia précise cependant ne rien pouvoir faire à ce niveau, mais supposer que GeForce GRID grâce à sa densité plus élevée et son attrait supérieur par rapport au cloud gaming actuel, va inciter les fournisseurs à mettre en place de plus en plus de serveurs. En d'autres termes, Nvidia présume que la probabilité d'en trouver un près de chez vous va augmenter et que la latence sera ainsi réduite.

Derrière ces affirmations se cache en réalité le fait que la latence du réseau est un problème et que Nvidia ne peut rien y faire actuellement, mais espère qu'elle se réduira à l'avenir. Ce ne sont cependant que des projections. Nvidia indique explorer d'autres voies telles que d'inciter les fabricants de TV à proposer une entrée ethernet à faible latence d'affichage, celle-ci étant en général relativement très élevée sur les TV, notamment à cause des différents traitements d'image.

Lors d'une démonstration sur TV, un autre problème saute aux yeux : la qualité de l'encodage H.264. Comme nous l'avons expliqué dans cet article dédié, NVENC, l'encodeur matériel de Kepler, s'il est très rapide, ne brille pas spécialement par sa qualité en comparaison de solutions CPU. Dans une scène de combat très rapide cela donne rapidement une bouillie de pixel passable sur un smartphone mais indigne d'un grand écran.

Vous l'aurez compris, nous ne sommes pas encore convaincus par le cloud gaming, en dehors du jeu occasionnel sur petit écran. Latence et qualité sont encore loin de pouvoir concurrencer ce bon vieux PC et Nvidia doit utiliser quelques artifices pour mettre en avant sa solution GeForce GRID : comparaison à des consoles qui commencent à dater et suppositions sur une amélioration future de la latence des réseaux.

Les mauvaises langues diront que faute d'avoir pu obtenir une place dans une des futures consoles pour l'un de ses GPU, Nvidia tente une autre approche pour ne pas être exclu de votre TV. D'autres, plus optimistes, insisteront sur le fait qu'il ne s'agit que d'un premier pas, qui a l'intérêt de trouver un nouveau débouché pour les GPU haut de gamme qui en ont bien besoin. De quoi pérenniser leur existence… sur PC ?

Pour vous faire une idée sur le cloug gaming actuel, Gaikai  propose gratuitement l'accès à des démos de quelques jeux PC, exécutées sur ses serveurs (classiques, sans GeForce GRID) et visualisées à travers un plugin pour votre navigateur internet. Le but étant à terme de proposer des jeux complets et de migrer vers des solutions plus efficaces telles que ce que promet Nvidia avec GeForce GRID.

Lors d'une session technique sur l'architecture du GK110, nous avons pu apprendre quelques détails de plus à son sujet par rapport aux premières informations d'hier. Des détails bien entendu concentrés sur la partie compute de ce GPU. Tout d'abord, Nvidia propose cette fois un schéma de l'architecture qui montre sans ambiguïté que le GK110 est composé de 15 SMX de 192 unités de calcul, soit un total de 2880, et d'un bus mémoire de 384 bits.

On apprend par ailleurs que le cache L2 passe à 256 Ko par contrôleur mémoire 64 bits, soit un total de 1.5 Mo contre 768 Ko pour le GF1x0 et 512 Ko pour le GK104. Tout comme pour le GK104, chaque portion de cache L2 affiche une bande passante doublée par rapport à la génération Fermi.

Les blocs fondamentaux d'unités de calcul, appelés SMX dans la génération Kepler, sont similiaires pour le GK110 ceux du GK104 :


Le nombre d'unités de calcul simple précision est identique, tout comme le nombre d'unités dédiées aux fonctions spéciales, aux lectures/écritures, au texturing… Les caches sont également identiques que ce soit les registres, le L1/mémoire partagée, les caches dédiés aux texturing.

La seule différence fondamentale réside dans la multiplication des unités de calcul en double précision qui passent de 8 pour le GK104 à 64 pour le GK110. Alors que le premier est 24x plus lent dans ce mode qu'en simple précision, le GK110 n'y sera que 3x plus lent. Couplé à l'augmentation du nombre de SMX, cela nous donne un GK110 capable de traiter 15x plus de ces instructions par cycle ! Par rapport au GF1x0 il s'agit d'un gain direct de 87.5% à fréquence égale.

Dans le GK110, tout comme dans le GK104, chaque SMX est alimenté par 4 schedulers, chacun capable d'émettre 2 instructions. Toutes les unités d'exécution ne sont cependant pas accessibles à tous les schedulers et un SMX est en pratique séparé en 2 parties symétriques à l'intérieur desquelles une paire de schedulers se partage les différentes unités. Chaque scheduler dispose de son propre lot de registres : 16384 registres de 32 bits (512 registres généraux de 32x32 bits en réalité). Par ailleurs chaque scheduler dispose d'un bloc dédié de 4 unités de texturing accompagnées d'un cache de 12 Ko.

Contrairement à ce à quoi nous nous attendions, l'ensemble cache L1 / mémoire partagée n'évolue pas dans le GK110 par rapport au GK104 et reste proportionnellement inférieur à ce qui était proposé sur la génération Fermi. Nvidia introduit par contre trois petites évolutions qui peuvent entraîner des gains importants :

Tout d'abord, chaque thread peut se voir attribuer jusqu'à 256 registres contre 64 auparavant. Quel intérêt quand le nombre de registres physiques n'augmente pas ? Il s'agit de donner plus de flexibilité au développeur et surtout au compilateur pour jongler entre le nombre de thread en vol et la quantité de registres allouée à chacun pour maximiser les performances. C'est particulièrement important dans le cas des calculs en double précision qui consomment le double de registres et qui étaient auparavant limités à 32 registres par thread. Passer à 128 permet des gains impressionnants dans certains cas selon Nvidia.


Ensuite, la seconde petite évolution consiste à autoriser l'accès direct aux caches dédiés au texturing. Auparavant il était possible d'en profiter manuellement en bricolant un accès à travers les unités de texturing, mais ce n'était pas pratique. Avec le GK110, ces caches de 12 Ko peuvent être exploités directement depuis les SMX mais uniquement dans le cas d'accès à des données en lecture seule. Ils ont l'avantage de disposer d'un accès royal au sous-système mémoire du GPU, de souffrir moins en cas de cache miss et de mieux supporter les accès non alignés. C'est le compilateur (via une directive) qui se charge d'y avoir recours lorsque c'est utile.


Enfin, une nouvelle instruction fait son apparition : SHFL. Elle permet un échange de donnée de 32 bits par thread à l'intérieur d'un warp (bloc de 32 threads). Son utilité est similaire à celle de la mémoire partagée et cette instruction vient donc en quelque sorte compenser sa quantité relativement faible, proportionnellement au nombre d'unités de calcul. Dans le cas d'un échange de données simple il sera donc possible d'une part de gagner du temps (un transfert direct à la place d'une écriture puis d'une lecture) et d'autre part d'économiser la mémoire partagée.

D'autres petits détails évoluent également tels que l'ajout des quelques instructions atomiques manquantes en 64 bits (min/max et opérations logiques) et une réduction de 66% du surcoût lié à la mémoire ECC.

Au final, avec la génération Kepler, Nvidia a bien pris une direction différente de celle de la génération Fermi. Le gros GPU Fermi, le GF100/110, disposait d'une organisation interne différente de celle des autres GPU de la famille, de manière à augmenter la logique de contrôle au détriment de la densité des unités de calcul et du rendement énergétique.

Avec le GK110, Nvidia n'a pas voulu faire de compromis sur ce dernier point ou plutôt devrions nous dire "n'a pas pu". Il s'agit dorénavant de faire un maximum dans une enveloppe thermique qui n'est plus extensible. C'est la raison pour laquelle le GK110 reprend la même organisation interne que celle du GK104, en dehors de la capacité de calcul en double précision qui a été revue nettement à la hausse.

Ainsi, Nvidia n'a pas cherché à complexifier son architecture pour soutenir les performances en GPU computing et s'est attaché à essayer de faire un maximum avec les ressources disponibles en se contentant d'évolutions mineures mais qui peuvent avoir un impact énorme. C'est également la raison pour laquelle le processeur de commandes a été revu pour permettre de maximiser l'utilisation du GPU avec les technologies Hyper-Q et Dynamic Parallelism que nous avons décrites brièvement hier et sur lesquelles nous reviendront dès que possible avec quelques détails de plus.