Les derniers contenus liés aux tags AMD et GPGPU

Pour répondre au GameWorks propriétaire de Nvidia, AMD renforce sa stratégie open source avec l'ouverture prochaine d'un portail dédié : GPUOpen. Au menu, des samples et des outils distribués sans restrictions dans l'optique de favoriser un partage de connaissances bénéfique pour l'évolution des techniques de rendu.

Lors de l'introduction de ses nouveaux pilotes, Radeon Software Crimson Edition, le Radeon Technology Group d'AMD avait annoncé que ceux-ci ne représentaient qu'un pan de sa stratégie au niveau software et que d'autres éléments suivraient. C'est le cas aujourd'hui avec GPUOpen, une remise en forme de sa stratégie à destination des développeurs. Comme le nom de cette initiative l'indique, AMD mise sur l'open source, tout d'abord dans le monde du jeu vidéo pour lequel les spécialistes du GPU fournissent samples, librairies et autres outils destinés à aider les développeurs à améliorer le rendu graphique et/ou les performances.

Et sans directement citer son concurrent, c'est bien entendu à l'aspect fermé de GameWorks qu'entend s'attaquer AMD. Nvidia préfère en effet conserver un contrôle total sur certaines librairies et dans certains cas les exploiter en priorité de manière à dégager un avantage compétitif direct plutôt qu'à simplement mettre dans les mains des développeurs de quoi les aider à améliorer leurs jeux. Si la philosophie d'AMD est en général tournée vers l'ouverture, il ne faut pas oublier que ces orientations sont également dictées par la force de chacun sur le marché. Nvidia peut profiter du poids de ses parts de marchés énormes pour imposer une stratégie agressive, ce que pourrait difficilement faire AMD dans sa situation actuelle.


A la base de GPUOpen se trouve une philosophie relativement simple : les meilleures innovations découlent du partage des connaissances. L'évolution du rendu graphique dans les jeux est progressive et se fait par petites améliorations successives apportées par différents développeurs. AMD entend donc faire en sorte que sa contribution ne puisse pas entraver cette évolution et pour cela le passage par l'open source est évidemment préférable aux boîtes noires que peuvent représenter certaines librairies concurrentes.


AMD entend ainsi lancer le portail GPUOpen avec un ensemble de contenu open source distribué sur GitHub (via une licence MIT qui offre une exploitation du code sans restrictions). Des effets graphiques directement exploitables, des outils, des bibliothèques et des SDK seront proposés sur ce portail qui sera ouvert dans le courant du mois de janvier. Le succès de cette initiative dépendra bien entendu de la capacité d'AMD à enrichir régulièrement son portail avec de nouvelles choses et avec le niveau de qualité requis pour convaincre un maximum de développeurs, notamment dans le cadre des nouvelles API de bas niveau.


Parallèlement, AMD rappelle que Linux profite depuis quelques temps d'efforts supplémentaires avec AMDGPU, un pilote qui unifie des pans ouverts et fermés/propriétaires avec une même structure, ce qui facilite leur exploitation et leur évolution. A la base d'AMDGPU se trouve un pilote open source (en kernel space) qui peut recevoir des modules ouverts ou fermés suivant les besoins. De quoi permettre à AMD de proposer, sur une même base, un pilote full open source et un autre optimisé pour les performances dans le cadre du jeu et des applications professionnelles. Typiquement, le module OpenGL fermé reste plus performant par exemple mais AMD a pour objectif de passer en open source dès que possible le module OpenCL/Vulkan du pilote "fermé".


L'open source ne concerne évidemment pas que le jeu vidéo et AMD insiste sur son infrastructure open source complète pour le GPU computing ce qui englobe ces nouveaux pilotes Linux et les compilateurs pour lesquels des nouveautés avaient été dévoilées il y a peu. Un ensemble qui permet aux développeurs de mieux comprendre comment leur code est interprété et éventuellement de faciliter l'optimisation et le débogage. Ce qui ne remplace bien entendu pas le besoin pour AMD, avant toute chose, de fournir des outils de qualité et de proposer un écosystème robuste pour convaincre le monde du HPC d'accorder sa confiance dans ses solutions.


Vous retrouverez la présentation complète ci-dessous :

AMD profite du forum SC15 pour annoncer l'initiative Boltzmann, un ensemble de nouveaux outils dédiés à renforcer sa présence dans le HPC, notamment via un portage du code CUDA.

Il y a quelques semaines, le départ de Phil Rogers d'AMD pour rejoindre Nvidia a pu soulever quelques inquiétudes. Cet ingénieur émérite était la figure de proue de la HSA, la plateforme ouverte dédiée au calcul hétérogène ("CPU + GPU"), poussée par AMD avec le support du monde ARM. Une perte incontestable pour AMD qui mise beaucoup sur la HSA, que ce soit au niveau du HPC (calcul haute performances) ou du grand public.

A l'occasion du SC15 (SuperComputing), AMD tient cependant à rassurer quant à l'avenir de la HSA et de son écosystème dédié au calcul hétérogène. De nombreux développements, dédiés initialement au monde professionnel, sont en cours de finalisation et, avec une bonne dose de pragmatisme, ont pour objectif commun d'apporter aux développeurs et aux clients potentiels les outils dont ils ont besoin. AMD regroupe cet ensemble de développements sous le nom de code "Initiative Boltzmann", en référence au physicien Ludwig Eduard Boltzmann dont les équations profitent aujourd'hui de la puissance de calcul des GPU.


Sans donner de précisions liées au hardware, les annonces sont concentrées sur le software, AMD annonce tout d'abord l'extension du support de la HSA des APU (Kaveri) vers les GPU dédiés. Pour cela, AMD proposera un nouveau pilote Linux headless, c'est-à-dire totalement dédié au calcul, allégé du support des parties graphiques et vidéo. De quoi proposer plus facilement un adressage mémoire unifié entre les CPU et les GPU (et rattraper Nvidia sur ce point crucial), réduire la latence des transferts PCIe et de l'envoi des commandes, mieux exploiter tout le sous-système mémoire des GPU etc. Des systèmes de gestion spécifique des GPU (fréquences turbo etc.) seront également proposés ainsi qu'un support étendu de la communication P2P, y compris pour des GPU présents dans des nœuds différents dans le cadre des supercalculateurs.


Ensuite, AMD annonce un nouveau compilateur : HCC pour Heterogeneous Compute Compiler. Il s'agit d'un compilateur de type source unique, c'est-à-dire qu'il traite autant le code CPU que le code GPU mis en avant à l'aide de directives (à la manière de C++ AMP de Microsoft). HCC est compatible C++ 11/14, C11 et OpenMP 4.0. Il propose par ailleurs un support alpha de la Parallel Standard Template Library de C++17 (C++1z), la prochaine révision de C++ attendue pour 2017. AMD annonce différentes optimisations qui devraient profiter aux performances tels qu'une meilleure gestion de la mémoire et le support de l'exécution asynchrone des kernels (et concomitante).


Enfin, AMD fait face à la réalité : CUDA de Nvidia est bien implanté dans le monde du HPC. Suffisamment pour que sa seule stratégie à ce niveau ne puisse plus se résumer à essayer de nier cet état de fait avec des statistiques d'utilisation d'OpenCL chez les développeurs. Avec pragmatisme, AMD annonce ainsi l'interface HIP (Heterogeneous-compute Interface for Portability) dont le but est de permettre au code CUDA de tourner sur ses propres GPU.

Cela se fera de manière indirecte bien entendu, avec des outils qui porteront le code source CUDA vers un language C++ commun (cudaMemcpy -> hipMemCpy). Après conversion, le code pourra ensuite tourner aussi bien sur les GPU Nvidia via le compilateur NVCC que sur les GPU AMD via le compilateur HCC. AMD indique que d'après ses tests, 90% du code CUDA peut être automatiquement porté alors que les 10% restants doivent être traités manuellement mais en C++ standard. AMD estime que cela devrait répondre aux demandes du marché qui appréciera l'ouverture de l'offre matérielle pour une bonne partie des systèmes amenés à faire tourner du code CUDA. A voir par contre si Nvidia appréciera cette initiative de la même manière...

A noter que ce support du code CUDA reste partiel et ne concerne que l'ensemble de plus haut niveau, soit le code C/C++ CUDA pour l'API runtime. Le code qui vise l'API driver ainsi que le code PTX ne seront pas supportés, tout du moins initialement.

AMD fera la démonstration de ces outils durant le SC15 et une première version beta sera mise dans les mains des développeurs au premier trimestre 2016.

AMD profite de l'été pour annoncer l'arrivée d'une nouvelle carte accélératrice dédiée aux serveurs : la FirePro S9170. Outre une puissance de calcul importante, celle-ci a la particularité d'embarquer pas moins de 32 Go de mémoire.

AMD propose pour rappel deux gammes principales de cartes professionnelles hautes performances. D'un côté la série W dédiée aux workstations et d'un autre la série S dédiée aux serveurs. AMD ne différencie par contre pas directement ses solutions en fonctions des usages comme peut le faire Nvidia avec les Quadro dédiées au graphisme professionnel et les Tesla au calcul haute performance (HPC).

Au niveau logiciel, les FirePro S peuvent ainsi profiter de toutes les optimisations logicielles et autres validations spécifiques aux applications graphiques. Les FirePro S se distinguent par contre au niveau du format. Elles sont refroidies passivement et dépourvues de sorties vidéo et sont donc en pratique plutôt orientées vers le HPC bien qu'elles puisse également être exploitées pour fournir des stations de travail virtuelles à travers le cloud ou un réseau interne.

Après la FirePro S9150 16 Go lancée l'été passé, AMD propose aujourd'hui une FirePro S9170 similaire si ce n'est qu'elle est cette fois équipée de plus de mémoire :


Avec une petite hausse de la fréquence du GPU Hawaii (exploité sur les Radeon R9 290X/390X), la puissance de calcul progresse de 3% et s'aligne sur celle de la FirePro W9100. Un changement plus pour la forme qu'autre chose, la seule réelle nouveauté étant à chercher du côté de l'espace mémoire qui est doublé. AMD profite pour cela de l'arrivée de la mémoire GDDR5 avec une densité de 8 Gb, soit 1 Go par puce. Un bus 512-bit couplé au mode clamshell de la GDDR5 (association de puces mémoire par paires) permet d'adresser 32 de ces puces pour un total de 32 Go, un nouveau record.

Nvidia annoncera probablement une évolution similaire avec la mémoire 8 Gb, mais ne pourra pas aller au-delà de 24 Go, son gros GPU actuel dédié au monde professionnel, le GK210 devant se contenter d'un bus 384-bit.

Si AMD ne fait pas appel à son dernier GPU en date, Fiji, c'est parce que celui-ci est actuellement limité à 4 Go de mémoire HBM, insuffisant sur le marché professionnel. Par ailleurs, le GPU Fiji est relativement lent en calcul double précision (1/16ème de la simple précision), un point qui est la force du GPU Hawaii, capable de traiter ces calculs à demi vitesse. De quoi proposer plus de 2.5 Tflops là où la Tesla K40 de Nvidia se contente plutôt de +/- 1.5 Tflops suivant le mode de Turbo qui a été activé (manuellement sur cette carte).

AMD précise par ailleurs qu'il ne s'agit pas que de gros chiffres théoriques et que le rendement est assez élevé avec 79% en DGEMM (multiplication de matrices), ce qui permet d'atteindre 2 Tflops sur les FirePro S9150 et S9170.

Ces débits soutenus sont également autorisés par un TDP très élevé. Il passe d'ailleurs de 235W pour la S9150 à 275W pour la S9170, ce qui demandera une capacité de refroidissement importante au niveau du serveur. Si cela pose problème, ou tout simplement pour gagner en efficacité énergétique, la S9170 pourra être configurée en mode 235W mais aura alors plus de mal à maintenir sa fréquence maximale lors du traitement de tâches lourdes.

Outre la puissance de calcul et la quantité de mémoire embarquée, AMD met en avant son support des standards ouverts tels qu'OpenCL 2.0 ou encore OpenMP 4.0 et OpenACC à travers un partenariat avec PathScale.

AMD annonce une disponibilité de la FirePro S9170 pour cet été avec une tarification proche de celle de la FirePro S9150 qui devrait donc tourner autour de 4000$. En plus de s'opposer aux solutions de Nvidia, elle devra également lutter contre les Xeon Phi d'Intel dont le prometteur Knights Landing ne devrait plus tarder.

Il y a un peu plus d'un an, AMD inaugurait la HSA Foundation en partenariat avec ARM, Imagination Technologies, MediaTek et Texas Instruments. Rapidement, Samsung et Qualcomm ont rejoint le groupe de fondateurs de ce consortium qui a pour rappel comme objectif de concevoir des standards dédiés au calcul hétérogène, qu'ils concernent l'aspect programmation ou l'implémentation matérielle.

Petit à petit, la liste de membres qui ont rejoint la HSA Foundation à un niveau ou à un autre s'est allongée et à l'occasion du Developer Summit 2013, AMD annonce avoir à nouveau renforcé les rangs du consortium :

Broadcom
Canonical Limited
Electronics and Telecommunications Research Institute (ETRI)
Huawei
Industrial Technology Res. Institute
Kishonti
Lawrence Livermore National Laboratory
Linaro
Oak Ridge National Laboratory
Oracle
Synopsys
TEI of Crete
UChicago Argonne, LLC. Operator of Argonne National Laboratory
VIA Technologies

Parmi les nouvelles arrivées notons le géant chinois des télécoms Huawei, Kishonti (GLBenchmark), Oak Ridge (qui a mis en place le supercalculateur Titan équipé en Tesla Kepler de Nvidia), Oracle (qui a pour rappel racheté Sun et donc Java) et VIA/S3 Graphics. De quoi donner progressivement de plus en plus d'influence à la HSA.

Son support s'étend également au niveau des langages de programmation. L'implémentation du support de la HSA est actuellement en cours pour Python, OpenMP, C++ AMP et Java :



Annoncé lors de l'AFDS de 2011 par Microsoft, C++ AMP sera, comme nous pouvions alors le supposer, étendu pour supporter la HSA en plus d'un mode OpenCL générique. La différenciation se fera au moment de la compilation où il sera possible de viser le langage intermédiaire HSAIL pour la HSA ou SPIR 1.2 pour les périphériques compatibles OpenCL. Par ailleurs, bien qu'initiative de Microsoft, AMD annonce que C++ AMP sera disponible également sous Linux et que ce support sera mis en place autant pour ses APU que pour ses GPU.

Depuis quelques temps, AMD travaille avec Oracle pour intégrer le support de la HSA dans Java 9 Sumatra et rendre l'utilisation des cores massivement parallèles aussi simple que possible. Un projet ambitieux et en attendant que cela soit finalisé et disponible, APARAPI initialement limitée à OpenCL dans Java 7 va supporter la HSA dans Java 8 (Project Lambda). Oracle a d'ailleurs réalisé une première démonstration sur base d'une simulation de type N-Body, qui, vous vous en doutez, était nettement plus rapide une fois accélérée par un GPU.

Il y a près de 2 ans, AMD avait dévoilé ses plans concernant l'évolution de la plateforme GPU computing pour une exploitation en symbiose plus simple et plus efficace des cores GPU et CPU. Cette plateforme dénommée HSA (Heterogeneous System Architecture) a pour rappel été ouverte par AMD et transférée à un consortium chargé d'en finaliser les spécifications et de poursuivre son développement tant logiciel que matériel. Une approche qui a permis de rallier de nombreux acteurs importants, issus du monde ARM, à la cause d'AMD.

Si en pratique AMD reste le pilote au niveau de la HSA, en finaliser les spécifications à plusieurs a entraîné plusieurs retards, notamment sur la publication des différentes documentations et des premiers outils complets à destination des développeurs. Tout cela semble cependant commencer à se préciser.

AMD a récemment donné un nom commercial à l'une des évolutions les plus importantes qui seront apportées par la HSA : l'unification de l'espace mémoire entre CPU et GPU pour simplifier le travail des développeurs et améliorer les performances notamment en supprimant des déplacement de données inutiles.

Pour représenter l'unification de la mémoire entre le CPU et le GPU, AMD s'est inspiré des acronymes tirés du SMP : UMA (Uniform Memory Architecture), une seule mémoire physique partagées par les cores CPU, et son évolution NUMA (Non Uniform Memory Architecture), plusieurs mémoires physiques partagées par les cores CPU. Dans un système multi-socket, NUMA permet à chaque CPU de disposer de son propre contrôleur mémoire et de sa propre mémoire, tout en gardant un espace mémoire unifié mais bien entendu sans garantir des performances homogènes sur l'ensemble de celui-ci.

Préparée et annoncée (voire réannoncée régulièrement) par AMD, Nvidia et même Intel, l'unification de l'espace mémoire entre les CPU et les GPU est une évolution logique et primordiale de (N)UMA vers le GPU computing. AMD a ainsi décidé de la nommer hUMA pour Heterogeneous Uniform Memory Architecture. Notez qu'en principe, dans le cas d'un GPU non-intégré, il serait plus correct de parler de hNUMA, puisque la mémoire est non-uniforme, mais nous ne savons pas si AMD prévoit de faire cette distinction.

En réalité, nous ne savons pas grand chose sur les détails, AMD n'ayant strictement rien dévoilé de neuf en dehors de l'acronyme hUMA. Si les aspects pratiques d'une mémoire virtuelle unifiée sont logiques dans le cas d'un APU ou de tout CPU avec GPU intégré, de nombreuses questions se posent par rapport aux GPU externes. Le support au niveau des OS est également un point important puisque leurs gestionnaires mémoire devront être revus pour la supporter.

Pour que la HSA et les produits qui l'implémenteront puissent réellement ouvrir de nouvelles portes et trouver un certain succès, il est important qu'AMD fournisse dès que possible tous les outils et toute la documentation nécessaires aux développeurs. Inutile de dire que cela demandera plus que de faire de la communication pour de la communication autour d'un nouvel acronyme pour représenter l'espace mémoire unifié.

Notez qu'AMD a récemment reporté son forum technologique dédié au GPU Computing de juin à septembre. Il change au passage de nom pour abandonner sa composante Fusion et devenir l'AMD Developer Summit (APU13 en abrégé). Il devrait laisser plus de visibilité aux autres membres de la HSA Foundation et enfin être le lieu de la concrétisation de cette plateforme.

Si vous désirez en savoir plus concernant la HSA et la mémoire unifiée, c'est un whitepaper de l'été 2012 qui reste le plus complet. Vous pourrez le consulter ici .