Les derniers contenus liés aux tags CUDA et GTC
Les 2 contenus précédentsGTC: Le futur de Tegra: CUDA, Logan, Parker
GTC: CUDA s'ouvre officiellement à Python
GTC: Nvidia annonce CUDA 8, prêt pour Pascal
GTC: Les Tesla K20X dans le Piz Daint suisse
GTC: Performances GPU de Logan = GT 640M ?
GTC: CUDA on ARM: Tegra 3 + Tesla K20
GTC: CUDA on ARM: Kayla, Tegra 3 et GK208
GTC: Nvidia annonce CUDA 8, prêt pour Pascal
(0) Réaction
Comme souvent, l'arrivée d'une nouvelle architecture est associée à une révision majeure de CUDA, l'environnement logiciel de Nvidia destiné au calcul massivement parallèle. Ce sera évidemment le cas pour les GPU Pascal qui pourront profiter dès cet été d'un CUDA 8 taillé sur mesure. Au menu : un support plus évolué de la mémoire unifiée, un profilage plus efficace et un compilateur plus rapide.
La principale nouveauté de CUDA 8 sera le support complet de l'architecture Pascal et particulièrement du GP100 qui équipe l'accélérateur Tesla P100. Déjà introduit avec CUDA 7.5 pour permettre aux développeurs de s'y préparer, le support de la demi-précision (FP16) sera finalisé et pourra permettre des gains conséquents pour les algorithmes qui peuvent s'en contenter. Dans le cas du GP100, CUDA 8 ajoutera évidemment le pilotage des accès mémoire à travers les liens NVLink.
La plus grosse évolution est cependant à chercher du côté de la mémoire unifiée qui va faire un bond en avant avec Pascal, ou tout du moins avec le GP100 puisque nous ne sommes pas certains que les autres GPU Pascal en proposeront un même niveau de support. Si vous avez l'impression qu'on vous a annoncé le support de cette mémoire unifiée avec chaque nouveau GPU, ne vous inquiétez pas, vous n'avez pas rêvé, nous avons la même impression.
Elle est en fait supportée depuis CUDA 6 pour les GPU Kepler et Maxwell mais de façon limitée, que nous pourrions qualifier d'émulée. Pour ces GPU, l'espace de mémoire unifié est en fait dédoublé dans la mémoire centrale et dans la mémoire physiquement associée au GPU. L'ensemble logiciel CUDA se charge de piloter et de synchroniser ces deux espaces mémoires pour qu'ils n'en représentent qu'un seul du point de vue du développeur. De quoi faciliter sa tâche mais au prix de sérieuses limitations : la zone de mémoire unifiée ne peut dépasser la quantité de mémoire rattachée au GPU, le CPU et le GPU ne peuvent y accéder simultanément et de nombreuses synchronisations systématiques sont nécessaires pour forcer la cohérence entre les copies CPU et GPU de cette mémoire.
Pour proposer un support plus avancé de la mémoire unifiée, des modifications matérielles étaient nécessaires au niveau du GPU, ce qui explique pourquoi nous estimons possible que cela soit spécifique au GP100. Tout d'abord l'extension de l'espace mémoire adressable à 49-bit pour permettre de couvrir l'espace de 48-bit des CPU ainsi que la mémoire propre à chaque GPU du système. Ensuite la prise en charge des erreurs de page qui permet d'éviter les coûteuses synchronisations systématiques. Si un kernel essaye d'accéder à une page qui ne réside pas dans la mémoire physique du GPU, il va produire une erreur qui va permettre suivant les cas soit de rapatrier localement la page en question, soit d'y accéder directement à travers le bus PCI Express ou un lien NVLink.
La cohérence peut ainsi être garantie automatiquement, ce qui permet aux CPU et aux GPU d'accéder simultanément à la zone de mémoire unifiée. Sur certaines plateformes, la mémoire allouée par l'allocateur de l'OS sera par défaut de la mémoire unifiée, et il ne sera plus nécessaire d'allouer une zone mémoire spécifique. Nvidia indique travailler à l'intégration de ce support avec Red Hat et la communauté Linux. Par ailleurs, CUDA 8 étend également le support de la mémoire unifiée à Mac OS X.
Ce support plus avancé de la mémoire unifiée va faciliter le travail des développeurs et surtout rendre plus abordable leurs premiers pas sur les GPU tout en maintenant un relativement bon niveau de performances. Tout du moins si le pilote et le runtime CUDA font leur travail correctement puisque c'est à ce niveau que tout va se jouer. A noter que les développeurs plus expérimentés conservent la possibilité de gérer explicitement la mémoire.
Parmi les autres nouveautés, Nvidia introduit une première version de la librairie nvGRAPH (limitée au mono GPU) qui fournit des routines destinées à accélérer certains algorithmes spécifiques au traitement des graphes. Traiter rapidement les opérations sur ces structures mathématique prend de plus en plus d'importance, que ce soit pour les moteurs de recherche, la publicité ciblée, l'analyse des réseaux ou encore la génomique. Faciliter l'exécution de ces opérations sur le GPU est donc important pour leur ouvrir la porte à de nouveaux marchés potentiels.
Une autre évolution importante est à chercher du côté des outils de profilages qui vont dorénavant fournir une analyse des dépendances. De quoi par exemple permettre de mieux détecter que les performances sont limitées par un kernel qui bloque le CPU trop longtemps. Ces outils revus prennent également en compte NVLink et la bande passante utilisée à ce niveau.
Enfin, le compilateur NVCC 8.0 a reçu de nombreuses optimisations pour réduire le temps de compilation. Nvidia annonce qu'il serait réduit de moitié, voire plus, dans de nombreux cas. Ce compilateur étend également le support expérimental des expressions lambda de C++11.
La sortie de CUDA 8.0 est prévue pour le mois d'août mais une release candidate devrait être proposée dès le mois de juin.
GTC: Les Tesla K20X dans le Piz Daint suisse
Après le supercalculateur Titan du Laboratoire national d'Oak Ridge, Nvidia a annoncé qu'un second supercalculateur venait de faire le choix de CUDA et de l'accélérateur Tesla K20X. Ce supercalculateur se nomme Piz Daint et est construit par le Centre national Suisse de Calcul Scientifique (CSCS) en collaboration avec MeteoSwiss. Bien que plus modeste que Titan, il devrait devenir le supercalculateur le plus puissant d'Europe avec une puissance de calcul supérieure au pétaflop. Il sera destiné à la recherche et à la modélisation météorologique.
Détail important concernant Piz Daint, il est basé sur la plateforme XC30 de Cray, qui repose sur des Xeon E5 et supporte l'accélérateur Xeon Phi en plus du Tesla K20X. Une double victoire donc pour Nvidia qui en plus de pouvoir fournir un nouveau supercalculateur, le fait en battant le concurrent direct proposé par Intel.
GTC: Performances GPU de Logan = GT 640M ?
Durant la GTC 2013, nous avons pu nous entretenir avec Ian Buck qui est à l'origine de la première version de CUDA et actuellement General Manager chez Nvidia pour les technologies du GPU Computing. Interrogé au sujet de Kayla, la plateforme de développement CUDA on ARM équipée d'un GPU GK208, Ian Buck nous a indiqué que les performances GPU, au niveau de CUDA, étaient bel et bien représentatives de celles de Logan, sans vouloir en dire plus.
Bien que ce niveau de performances représente le bas de gamme sur PC, il s'agit d'une évolution énorme pour un SoC Tegra. Si le passage au 20nm et sans aucun doute plusieurs évolutions de l'architecture (avec probablement une réduction du nombre d'unités de texturing), faciliteront l'arrivée de l'architecture Kepler et de CUDA dans le monde ultra-mobile, il est difficile d'imaginer que ces 384 cores (ou équivalents) flexibles ne consommeront pas plus que les 72 cores avec pipeline fixe de Tegra 4.
De quoi nous laisser spéculer qu'avec Logan, Nvidia devra se contenter de versions bridées (en termes d'unités actives ou de fréquences) pour les "petites" tablettes et les superphones, mais compte par contre revoir ses prétentions à la hausse avec un SoC capable de monter en gamme pour viser les "grosses" tablettes voire des ultra-portables et bien entendu le successeur de Shield.
Parallèlement à cela, Ian Buck nous a indiqué que CUDA devrait progressivement devenir "power aware" et devenir capable de prendre en compte l'aspect consommation ou tout du moins de permettre aux développeurs de le faire. Cela se fera tout d'abord au niveau des outils tels que Nsight (et sa version Tegra) qui d'ici quelques temps reporteront des informations liées à la consommation.
Il est possible qu'à terme, les compilateurs CUDA, permettent optionnellement d'améliorer le rendement énergétique, mais cela est encore à l'état de recherche et prendra encore plusieurs années avant d'éventuellement se concrétiser. Globalement, la meilleure stratégie reste d'exécuter le plus rapidement une tâche pour retourner au repos dès que possible mais ce n'est pas toujours vrai, d'autant plus dans le cas d'une tâche continue telle que le rendu 3D sur GPU. Par exemple, calculer une valeur au lieu de la lire en mémoire peut avoir un léger impact sur les performances mais augmenter le rendement énergétique.
En plus de préparer le futur avec CUDA, dans l'immédiat, le plus important pour Nvidia est probablement d'arriver à convaincre un maximum de développeurs que faire l'effort nécessaire pour arriver à utiliser 2 threads ou plus à fréquence modérée offre un meilleur rendement que se contenter d'un seul thread mais des performances de la fréquence CPU maximale.
Correction du 01/07/2013: le nom du GPU que nous pensions être GK117 est en réalité GK208.
GTC: CUDA on ARM: Tegra 3 + Tesla K20
En plus des plateformes CUDA on ARM destinées à simuler de futurs SoC que ce soit pour une utilisation de type périphérique mobile grand public ou de type micro-serveur, des développements se font également autour d'accélérateurs très puissants tels que les Tesla K20.
C'est le cas chez l'européen PRACE qui développe des systèmes dédiés au supercomputing et s'intéresse à CUDA on ARM depuis quelques temps. En collaboration avec le Barcelona Supercomputing Center, PRACE est en train de mettre au point une plateforme ARM équipée en GK110 : Pedraforca v2. Celle-ci est composée d'une carte mini-ITX sur laquelle prend place un module Q7 Tegra 3 dont 4 des lignes PCI Express 2.0 sont connectées à un switch PLX PCI Express 3.0 sur lequel vont venir se greffer un accélérateur Tesla K20 et une carte contrôleur InfiniBand 40 Gbps.
Cette plateforme a la particularité de ne pas rechercher la complémentarité entre les cores CPU et GPU. Grossièrement, le but est d'utiliser le SoC ARM uniquement pour activer un système CUDA plus ou moins indépendant. C'est la raison pour laquelle le Tesla K20 est associé à un contrôleur InfiniBand sur un même switch PCI Express 3.0 : ils peuvent ainsi communiquer très rapidement avec les accélérateurs d'autres nœuds en ignorant autant que possible la communication avec les SoC et leurs mémoires.
Les développeurs de Pedraforca v2 sont bien conscients qu'une telle approche n'est pas une solution de remplacement générale à un système CUDA classique et se contentera de répondre avantageusement à un sous-ensemble de problématiques : si un problème massivement parallèle peut être résolu sans CPU, autant réduire l'encombrement et la consommation de celui-ci.
Une telle solution permet par ailleurs de simuler le comportement de futurs GPU haut de gamme qui pourraient intégrer un ou plusieurs cores ARMv8 Denver pour gagner en indépendance. De quoi commencer à préparer des algorithmes qui leur seront adaptés ?
GTC: CUDA on ARM: Kayla, Tegra 3 et GK208
Nvidia l'a enfin confirmé, CUDA arrivera enfin dans les SoC Tegra avec Logan. Cela ne veut pas dire pour autant que CUDA sur plateforme ARM doit attendre. Il s'agit d'un point important de la stratégie de Nvidia pour son futur autant dans le monde professionnel que grand public. C'est la raison pour laquelle, depuis quelques temps déjà, Nvidia s'est associé à SECO pour proposer un kit de développement dénommé CARMA. Pour 529€, la plateforme propose un connecteur Q7 qui reçoit un SoC Tegra 3 (T30 à 1.3 GHz) et un connecteur MXM sur lequel prend place une Quadro 1000M de génération Fermi (GF108 avec 96 cores).
Tout cela va évoluer à partir du mois de mai, d'une part avec une couche logicielle qui supportera Ubuntu 12.04 et CUDA 5.0, et d'autre part avec la plateforme KAYLA, toujours développée en partenariat avec SECO, et qui existera en 2 versions : connecteur MXM ou PCI Express (câblés en 4x dans les 2 cas). Si nous aurions pu supposer que le SoC passerait en version Tegra 4, c'est bel et bien le Tegra 3 T30 qui reste exploité pour la simple et bonne raison que ses successeurs ne disposent plus de liens PCI Express. La différence (unique ?) entre les 2 cartes concerne les GPU supportés. La version PCI Express en supporte un large choix et la version MXM est annoncée être équipée d'un GPU Kepler de next generation.
Nvidia indique à ce sujet que ce GPU dispose de 2 SMX (384 cores), supporte les compute capabilities 3.5 (Dynamic Parallelism etc.) et est très proche du niveau de fonctionnalité du futur SoC Logan. Nous apprenons ainsi que le GPU de cette plateforme et celui de Logan disposent d'un processeur de commande plus évolué que sur les premiers GPU de la génération Kepler, dérivé de celui du GK110 (Tesla K20 et GTX Titan).
De toute évidence ce GPU est ainsi le GK208 qui prendra place dans les GeForce 700 d'entrée de gamme. Une supposition renforcée par un panneau de contrôle des pilotes Linux que Nvidia a malencontreusement oublié de masquer pendant quelques secondes et qui fait référence à un nom de code produit : D15M2-20. Cela correspond à la famille GeForce 700 desktop (D12 = GeForce 400, D13 = GeForce 500, D14 = GeForce 600…).
Cette plateforme CUDA on ARM continuera bien entendu à évoluer, tout d'abord avec CUDA 5.5 qui intégrera un compilateur CUDA pour l'architecture ARM, et plus tard avec l'arrivée de Logan et de Parker.
Correction du 01/07/2013: le nom du GPU que nous pensions être GK117 est en réalité GK208.
Les 2 contenus précédents
