Les derniers contenus liés au tag Nvidia

Afficher sous forme de : Titre | Flux Filtrer avec un second tag : AMD; ASUS; Fermi; GeForce; GeForce 500; GeForce 600; GPGPU; GTC; Kepler; Pilotes GeForce;

Pilotes GeForce 337.50 beta

Publié le 07/04/2014 à 15:30 par Guillaume Louel
Commentaires (73) RéactionsEnvoyer Imprimer

Nvidia avait profité de la GDC la semaine dernière pour parler d'optimisations à venir dans son pilote DirectX 11 pour Windows. Le constructeur évoquait ainsi avoir ré implémenté les « deferred contexts » et améliorer la latence de certaines instructions DirectX, indiquant que ce pilote serait rapidement rendu disponible. C'est aujourd'hui le cas avec le lancement de ces pilotes 337.50, en version beta.


Côté gains de performances, si le constructeur évoque des gains en mono et multi GPU, à l'image de ce que l'on a vu avec Mantle, c'est avant tout dans les configurations, jeux et situations ou le CPU est le facteur limitant que l'on observera les plus gros gains. Le constructeur met ainsi en avant des résultats avec un SLI de 780 Ti ou il évoque 20% de gains dans Call of Duty : Black Ops 2 et un peu plus de 40% dans Sniper Elite V2 ou Total War : Rome 2, sans précision sur les réglages et résolutions utilisés.

En mono GPU avec une 780 Ti, le constructeur indique un gain de 2% sous Battlefield 4 en 1920 par 1080 ultra, et un peu plus de 4% sous Thief dans la même résolution (mode high) avec les nouveaux pilotes, par rapport aux pilotes précédents.

Le téléchargement des pilotes s'effectue sur le site du constructeur en français :

GTC: Quelques détails de plus sur le GPU Pascal

Tags : GTC; Nvidia; NVLink; Pascal;
Publié le 28/03/2014 à 02:00 par Damien Triolet
Commentaires (52) RéactionsEnvoyer Imprimer

Durant la GTC, nous avons pu poser quelques questions à Nvidia et en apprendre un peu plus sur le GPU Pascal qui a été introduit entre les générations Maxwell et Volta.

Si Nvidia se refuse à parler de process de fabrication, nous supposons que la raison du retard de Volta est à chercher de ce côté. Pascal devra donc se contenter du 20 nanomètres de TSMC, ce qui limitera quelque peu les possibilités de Nvidia par rapport à ses plans originaux pour la même période. Pour aller plus loin que les GPU Maxwell qui seront fabriqués en 20nm, Nvidia devra poursuivre la progression de l'efficacité énergétique, mais ce n'est pas tout.

Nvidia explique que certains développements entrepris pour Volta étaient prêts et pourront être proposés comme prévus à travers les GPU Pascal. C'est le cas des technologies NVLink et du DRAM stacking. NVLink, qui a été développé en partenariat avec IBM, devrait dans un premier temps rester spécifique au marché professionnel, mais le DRAM stacking fera son apparition du côté des dérivés grand public. Probablement uniquement dans le très haut de gamme au départ, mais Nvidia insiste sur le fait que la technique est utile pour tous les segments de marché. En dehors du coût et d'un travail important nécessaire pour assurer un assemblage fiable, ce recours au DRAM stacking ne présente que des avantages, aucun inconvénient selon Nvidia. Son implémentation généralisée n'est donc qu'une question de temps et de réduction progressive des coûts.


Concernant le prototype de Pascal qui a été présenté, il s'agit d'un "mechanical sample" qui n'est pas encore fonctionnel mais qui est utilisé par Nvidia pour développer un nouveau format de module "carte graphique". Sur ce module Pascal, nous pouvons observer le GPU avec ses 4 assemblages de puces mémoire qui prennent place sur le même packaging et sont connectés via un "interposer". Sur les côtés du module sont visibles les VRM nécessaires pour alimenter un GPU haut de gamme tel que devrait l'être Pascal. Nvidia précise que ce module n'aura pas de problème à délivrer au moins 300W.

Si aucun connecteur n'est visible au premier abord c'est parce qu'ils se situent en fait au dos, Nvidia ayant opté pour un format de type mezzanine qui consiste à superposer 2 PCB, avec un ou plusieurs connecteurs entre ceux-ci. Sur le module actuel, Nvidia précise que 2 connecteurs sont exploités.


Un exemple de connecteur mezzanine, SpeedStack de Molex, capable de supporter des débits de 40 Gbps par paire.

Pourquoi ce changement de format ? Pour faciliter l'implémentation de NVLink, qui pourrait être exclusive au format mezzanine, mais également parce que ce dernier est plus fiable, notamment lorsqu'il est question de laisser les assembleurs de serveurs monter leur propre radiateur. Nvidia n'abandonne cependant pas le format "carte PCI Express" pour Pascal, il restera également disponible, même sur le marché professionnel.

Nvidia a également publié des schémas un peu plus détaillés de systèmes NVLink :


Sur ces schémas nous pouvons clairement observer 4 liens NVLink. Nvidia nous a précisé qu'il s'agissait d'un minimum et que certains modules Pascal, ou ses successeurs, pourraient en offrir plus, 8, 16… Il n'est d'ailleurs pas impossible que Nvidia en profite à l'avenir pour segmenter sa gamme professionnelle comme le fait aujourd'hui Intel avec les Xeon 2P/4P/8P. A noter que tous les liens peuvent être combinés pour former un très large bus de communication vers le CPU et/ou exploités pour connecter plusieurs GPU entre eux.

Chaque lien NVLink correspond à un bloc de 8 paires de lignes bidirectionnelles de type point-à-point. Une approche similaire à celle de l'HyperTransport et du QPI. Là où le bus PCI Express 3.0 16x apporte 16 Go/s dans chaque direction, l'ensemble NVLink pourra atteindre entre 80 et 200 Go/s. Nvidia indique par ailleurs que les déplacements de données à travers NVLink seront plus efficaces sur le plan énergétique que le PCI Express. Les premiers composants autres que Pascal qui supporteront NVLink seront de futurs CPU Power d'IBM. Nvidia précise par contre être en discussion avec d'autres fabricants de CPU, autres qu'Intel, mais sans en dire plus.

Enfin, nous avons interrogé Nvidia par rapport au recul du support complet de la mémoire unifiée qui était initialement prévu pour Maxwell mais est dorénavant annoncé pour Pascal. Ses responsables nous ont répondu que ce support avait bien été repoussé mais qu'il était présent partiellement depuis Kepler, reposant en partie sur une implémentation logicielle. Ils nous promettent que cette fois ce sera la bonne et que le dernier bloc nécessaire à la prise en charge matérielle complète de la mémoire unifiée fera enfin son apparition avec Pascal et NVLink.

GDC: Mantle, Direct3D 12, l'œuf et la poule

Publié le 27/03/2014 à 09:45 par Damien Triolet
Commentaires (61) RéactionsEnvoyer Imprimer

S'il y a bien un mot qui était tabou lors de toutes les sessions de la GDC consacrées à Direct3D 12, c'était Mantle. Microsoft, Nvidia et même AMD ont tout fait pour éviter de devoir mentionner cette autre API de bas niveau. Direct3D 12 est-il le résultat de la sortie de Mantle ? Voici ce qui nous semble être la meilleure actuelle théorie sur le sujet…


Durant la GDC, seul Oxide a osé un timide acte de rébellion en déclarant que "porter leur moteur depuis d'autres API modernes était plus simple que de porter de Direct3D 11 vers Direct3D 12". A chacune de ces sessions pourtant, la première question qui était posée était systématiquement la suivante : "comment se compare Direct3D 12 à Mantle ?". Eclats de rire assurés dans la salle mais aucune réponse en retour.


Nvidia, de son côté, explique travailler avec Microsoft sur DirectX 12 depuis plus de 4 ans et en collaboration rapprochée depuis un an. C'est sans aucun doute autant la réalité qu'un baratin énorme pour éviter d'admettre avoir été poussé dans cette direction par l'API Mantle d'AMD.

Microsoft travaille constamment avec ses partenaires au sujet de possibles évolutions de ses API. La machine ne s'arrête pas quand DirectX 11 sort, les discussions et autres phases de recherche continuent. Quand Nvidia indique travailler depuis plus de 4 ans avec Microsoft sur DirectX 12, cela veut simplement dire que Nvidia a poursuivi sa collaboration avec Microsoft au-delà de DirectX 11, comme tous les autres fabricants de GPU. Cela ne veut pas dire que Nvidia travaille depuis 4 ans sur le Direct3D 12 qui est présenté aujourd'hui.

Nous ne pensons pas que le fait que la démonstration de Microsoft d'un prototype de portage vers Direct3D 12 de Forza Motorsport ait été réalisée sur un GPU Nvidia, la GeForce GTX Titan Black, soit un élément significatif. Il est logique que Microsoft opte pour un GPU Nvidia pour mettre en avant l'aspect universel de sa solution. Une démonstration sur un GPU AMD aurait entraîné plus de liens vers Mantle et l'architecture d'AMD puisque le code de base de Forza Motorsport provient de la Xbox One équipée en GPU AMD.

Après de très nombreuses discussions avec tous les acteurs impliqués, à la GDC mais également auparavant, nous sommes convaincus que Mantle a été le déclencheur et l'accélérateur de la direction retenue pour Direct3D 12, quoi qu'en dise Nvidia. Cela ne veut pas dire que Direct3D 12 est un clone de Mantle, mais qu'il semble bel et bien avoir été bâti sur les mêmes bases ou tout du moins fortement tiré dans la même direction. Des bases qui impliquent de transférer une partie significative de la responsabilité des performances et des optimisations du pilote vers le moteur du jeu. Bien sûr, ce n'est pas un monde en noir et blanc, tout le pouvoir ne passe du pilote au moteur de jeu, les deux restent importants mais l'équilibre est modifié en faveur du second.

C'est selon nous la clé pour comprendre la position de chacun et la chronologie des évènements. Il ne faut pas être naïfs, AMD et Nvidia n'opèrent pas de virage important par pure conviction technologique, tous ces choix se font également avec une bonne dose de politique et de stratégie.

Pourquoi AMD a-t-il sorti Mantle ? Parce que Nvidia dispose de la meilleure équipe de développement des pilotes. Pourquoi Nvidia aurait-il été réticent jusqu'alors à faire évoluer Direct3D vers un niveau d'abstraction plus bas ? Parce que Nvidia dispose de la meilleure équipe de développement des pilotes.

Plus une API graphique est complexe, prend des chemins torturés et accuse un surcoût ou overhead élevé, plus les fabricants de GPU ont d'opportunités de se démarquer de la concurrence via leurs pilotes. Cela ne veut pas spécialement dire qu'AMD et Nvidia font ou ont fait volontairement en sorte de complexifier les API, mais que les simplifier et transférer une plus grosse part de la responsabilité de l'optimisation vers les développeurs pose des questions stratégiques importantes qui peuvent les inciter à trainer des pieds face à certaines évolutions.


Les avantages d'une API de plus haut niveau, selon Nvidia.

Le travail important nécessaire pour obtenir des performances de premier plan, que ce soit globalement au niveau des pilotes ou spécifiquement au cas par cas pour chaque application, a permis à AMD et Nvidia de bénéficier de la sécurité d'un marché difficilement accessible à d'autres acteurs. Des sociétés telles que S3, Matrox, XGI etc. s'y sont cassé les dents, en partie pour cette raison. C'est également ce qui a permis à AMD et Nvidia de tenir Intel à l'écart.

Au cours de ses années les plus difficiles, AMD a dû se séparer de nombreux ingénieurs qui travaillaient sur ses pilotes alors même que Nvidia renforçait ses rangs. Même si AMD a récemment revu à la hausse ses investissements auprès du support des développeurs, il est évident que Nvidia dispose d'une force de frappe nettement plus importante sur le plan du développement des pilotes. AMD a probablement fini par prendre conscience du danger que cela pouvait représenter et revu sa stratégie en conséquence. Le réflexe qui pouvait être de trainer des pieds par rapport à un transfert de pouvoir des pilotes vers l'application n'avait plus lieu d'être. Au contraire, il a fini par devenir évident que pousser le marché dans cette direction serait utile pour la compétitivité de la société.

Pas facile cependant de convaincre tout le monde de bouger dans ce sens... Il nous semble évident que stratégiquement Nvidia n'avait au premier abord aucune raison d'abonder dans le sens d'AMD, et préférait opter pour d'autres approches de réduction du surcoût CPU, peut-être moins ambitieuses, qui lui auraient évité d'abandonner autant de contrôle sur les optimisations. Du côté de Microsoft il y avait probablement du pour et du contre, pas mal d'hésitation et d'avis contradictoires.

En développant et en concrétisant Mantle, avec le support de développeurs très enthousiastes, nous pouvons supposer qu'AMD a décidé de donner un coup de pied dans cette fourmilière. Le risque était limité. Dans le pire des cas, AMD pourrait bénéficier d'un mode spécifique dans quelques jeux, et dans le meilleur des cas, en profiter pour forcer la main des acteurs réticents de manière à pousser l'industrie dans une direction plus intéressante pour la société d'un point de vue compétitif.

De premiers résultats encourageants, l'engouement instantané de plusieurs développeurs pour les principes de Mantle (pas spécialement pour l'utilisation d'une API propriétaire !), la position délicate de la Xbox One, la menace de Steam OS, …, tout cela a mis en place une atmosphère qui a permis à tout le monde d'accepter d'aller vers un changement plus radical que certains ne le voulaient au départ pour Direct3D 12. Au final, avec Mantle, AMD a pu influencer significativement Direct3D 12, en plus d'apporter un bonus dans quelques jeux pour les utilisateurs de Radeon, ce qui est toujours bienvenu sur le plan commercial.

Sur la base de la même réflexion, nous pouvons supposer qu'OpenGL ES va évoluer rapidement vers une version à overhead réduit, alors qu'il sera beaucoup plus lent et difficile de faire évoluer OpenGL dont l'importance dans le monde professionnel en fait un élément stratégique crucial. Un responsable du développement d'un des moteurs de jeux majeurs nous a d'ailleurs confirmé qu'un tel OpenGL ES était déjà sur la table.

Nous pouvons par contre supposer que Nvidia sera extrêmement prudent par rapport à une évolution d'OpenGL qui pourrait impacter son très rentable marché professionnel. Même si la tendance va de plus en plus vers une exploitation de toute la puissance des GPU, de nombreuses applications professionnelles liées à la 3D restent fortement limitées par le CPU et les performances du pilote. Une caractéristique qui, comme vous pourrez l'imaginer, fait bien les affaires de Nvidia.

GTC: Volta & Parker retardés, le 16nm TSMC responsable?

Publié le 26/03/2014 à 07:22 par Damien Triolet
Commentaires (27) RéactionsEnvoyer Imprimer

Les roadmaps présentées par Nvidia à la GTC ont semé pas mal de confusion en introduisant de nouveaux noms de codes, le GPU Pascal et le SoC Erista, à la place des anciens GPU Volta et SoC Parker. Nous avons pu confirmer avec Nvidia qu'en réalité les premiers, annoncés auparavant pour 2015, ont en fait été repoussés mais n'ont pas été annulés ou remplacés. Nvidia ne précise pas quelle est la raison de ce retard mais de nouvelles solutions ont dû être mises en place pour occuper le terrain et éviter que ses produits ne stagnent pendant trop longtemps.

Si Nvidia ne précise pas la raison de ce retard, un indice se trouve probablement dans les quelques informations communiquées l'an passé au sujet du SoC Parker. Nvidia parlait alors de l'utilisation d'un procédé de fabrication qui ferait appel aux FinFET, vraisemblablement le 16nm de TSMC. Nous pouvons supposer que c'était également le cas pour le GPU Volta.


La roadmap des SoC Nvidia, version 2013.

Il semblerait donc que ce process 16nm FinFET ait posé problème, que ce soit en termes de timing, de volumes, de tarification et/ou de performances. Avec Pascal et Erista, Nvidia a dans tous les cas décidé d'introduire une génération intermédiaire en 20 nanomètres, ce qui explique ces changements sur les roadmaps.

GTC: Tegra: Kit Jetson TK1, SoC Erista en 2015

Publié le 25/03/2014 à 21:03 par Damien Triolet
Commentaires (10) RéactionsEnvoyer Imprimer

L'intégration d'un GPU Kepler dans le SoC Tegra K1 lui permet de débarquer dans l'univers de CUDA et du calcul massivement parallèle. Avec la plateforme Kayla annoncée l'an passé, Nvidia avait clairement annoncé la couleur et son ambition d'amener CUDA dans le monde de l'embarqué.


La version finale de cette initiative se nomme Jetson TK1 et correspond à un kit de développement articulé autour du SoC Tegra K1 et de son GPU qui propose 192 unités de calcul FMA 32-bit pour une puissance de calcul de 326 Gflops. Nvidia ne précise pas de quelle version du Tegra K1 il s'agit, mais nous pouvons supposer qu'il est question de la v1, qui repose sur des cores Cortex-A15, et que la v2 équipée de 2 cores Denver ARMv8 ne viendra que plus tard.


Cette plateforme intègre 2 Go de mémoire, de l'USB 3.0, du HDMI 1.4, du Gigabit Ethernet, de l'audio, du SATA, du mini-PCIe et un emplacement pour carte SD. Notez qu'en pratique un ventirad est placé sur le SoC, mais il était absent des photos officielles et de l'échantillon présenté lors de la keynote.

De quoi proposer un kit de développement relativement polyvalent et potentiellement ouvrir de nouvelles portes à Nvidia dans l'embarqué, principalement pour des solutions mobiles, compactes et/ou peu gourmandes. Ce kit Jetson K1 sera disponible sous peu (il est en précommande à partir de ce jour) à un tarif de 192$. En Europe, il sera distribué par Zotac, SECO et Avionic Design.

Comme d'habitude, le passage Tegra de la keynote principale de GTC a été l'occasion pour le CEO de Nvidia de présenter une roadmap mise à jour :


Nous n'apprendrons cependant que très peu de détails si ce n'est que le prochain SoC Tegra, qui succèdera au Tegra K1 (nom de code Logan), intégrera un GPU Maxwell, augmentera le rendement énergétique d'un peu plus de 50% et se prénommera Erista. Encore une fois il s'agit d'une référence aux superhéros de l'univers Marvel puisque Erista y représente le fils de Logan, alias Wolverine. A voir s'il disposera également de quelques pouvoirs…

Tout comme pour le GPU Volta, le SoC Parker, annoncé l'an passé par Nvidia, a été repoussé et Erista est une solution intermédiaire. Parker était pour rappel prévu pour 2015 avec un GPU Maxwell, des cores Denver et l'exploitation d'un procédé de fabrication à base de FinFET. Nous ne savons pas à l'heure actuelle quelle est la différence entre ce le projet Parker et ce nouveau projet Erista.


Top articles