Les contenus liés au tag GPGPU

Lors de l'annonce d'une nouvelle gamme de Quadro cet été, nous nous étions étonnés de ne pas voir arriver un modèle haut de gamme basé sur un nouveau "gros" GPU Kepler : le GK210. Ce dernier n'est cependant pas passé à la trappe et vient d'être introduit au travers de la nouvelle carte accélératrice Tesla K80.

Après les Tesla K10, K20, K20X et K40, Nvidia introduit le Tesla K80 qui est le second modèle bi-GPU de la famille. Elle embarque en effet deux GK210, une petite évolution des GK110/GK110B exploités sur différents segments depuis deux ans. De quoi pousser les performances un cran plus haut tout en restant sur un même format, mais bien entendu en revoyant les demandes énergétiques à la hausse.

La Tesla K80

La Tesla K80 se contente de GPU partiellement fonctionnels, seules 2496 unités de calcul sur 2880 sont actives, ce qui permet de limiter quelque peu la consommation. De quoi atteindre de 5.6 à 8.7 Tflops en simple précision et de 1.9 à 2.9 Tflops en double précision. Pour le reste, le bus mémoire est complet avec 384-bit par GPU pour une bande passante totale qui atteint 480 Go/s.


Comme pour les Tesla K40, chaque GPU de la Tesla K80 profite de 12 Go de GDDR5 avec une protection ECC optionnelle qui réduit la bande passante et la quantité de mémoire réellement disponible. Elle est alors réduite de 1/16ème et passe à 11.25 Go par GPU.

Le TDP de cet accélérateur bi-GPU est de 300W, contre 235W pour les Tesla mono-GPU. Une augmentation plutôt contenue liée au fait que le GK210 est un petit peu plus efficace sur le plan énergétique mais surtout à la mise en place d'un turbo dynamique et d'une fréquence de base relativement faible.

Les Tesla précédentes profitaient déjà d'un mode turbo, dénommé GPU Boost comme sur GeForce, mais il était statique et le TDP était défini par Nvidia comme la consommation moyenne du GPU à sa fréquence de base lors de l'exécution d'un algorithme gourmand finement optimisé pour exploiter au mieux le GPU : DGEMM. Si le GPU était exploité pour faire tourner des tâches moins lourdes, ou s'il était particulièrement bien refroidi, il était possible à travers une API spécifique de faire passer manuellement le GPU à un niveau de fréquence supérieur. Par exemple le GPU de la Tesla K40 est cadencé par défaut à 745 MHz, mais il peut être configuré en mode 810 ou 875 MHz et voir sa puissance de calcul bondir de 17%.

Nvidia justifiait l'utilisation d'un turbo statique par la nécessité de proposer un niveau de performances stable et un comportement déterministe, notamment parce que certains clusters font travailler les GPU en parallèle de manière synchrone. Un autre élément était probablement que valider un turbo dynamique était plus complexe dans le monde professionnel que grand public.

Avec la Tesla K80 cela change et par défaut c'est un turbo dynamique qui est activé et qui fonctionne de la même manière que sur les GeForce récentes à ceci près que pour des raisons de sécurité, le GPU débute à sa fréquence de base et accélère progressivement si les limites de consommation (150W par GPU) et de température n'ont pas été atteintes (il part de la fréquence maximale et la réduit sur GeForce). La plage pour ce turbo dynamique est particulièrement élevée, de 562 à 875 MHz, ce qui représente jusqu'à 55% de performances supplémentaires lorsque les tâches ne sont pas très lourdes. C'est bien entendu dans ce type de cas que cette Tesla K80 se démarquera le plus d'une K40. A noter que Nvidia propose toujours, optionnellement, la sélection de manière statique d'un certain niveau de fréquence.


Il s'agit d'un format dédié au serveur et donc passif, pour cette carte de 267mm de long, qui semble reprendre le même PCB que celui de la GeForce GTX Titan Z. Petite nouveauté, la Tesla K80 n'est pas alimentée via des connecteurs PCI Express mais bien via un seul connecteur d'alimentation CPU 8 broches, plus adapté aux serveurs et qui simplifie le câblage (les traces pour ce connecteur sont présentes sur la GTX Titan Z mais il n'a pas été utilisé).

La Tesla K80 est disponible dès à présent à un tarif de 5300$ et a été validée par Cray (CS-Storm, 8 K80 par nœud 2U), Dell (C4130, 4 K80 par nœud 1U), HP (SL270, 8 K80 par nœud 4U half-width) et Quanta (S2BV, 4 K80 par nœud 1U). De quoi pousser à la hausse la densité des capacités de calcul et atteindre de 7.5 à 11.6 Tflops en double précision par U suivant la tâche.

A noter que la concurrence n'est pas pour autant larguée. AMD a implémenté une proportion plus élevée d'unités de calcul double précision dans son dernier GPU haut de gamme (Hawaii), ce qui permet à la FirePro S9150 d'afficher un débit similaire à celui de la Tesla K80 et une densité de 10.1 Tflops par U dans le même type de serveurs.

La Tesla K8

En octobre Nvidia a discrètement lancé un autre membre dans la famille Tesla : la K8. Celle-ci est en fait équipée d'un GPU Kepler GK104, non-adapté au calcul en double précision. Grossièrement il s'agit de l'équivalent Tesla d'une GeForce GTX 770/680. Le design proposé par Nvidia a la particularité d'être single slot et actif mais est prévu exclusivement pour l'intégration dans un serveur et non dans une station de travail.


Le GPU, qui affiche de 1.4 à 2.5 Tflops en simple précision, est associé à 8 Go de mémoire. Par défaut, il est cadencé à 693 MHz (2.1 Tflops) et affiche un TDP de 100W. Pour les tâches légères il peut être poussé à 811 MHz et il est également possible d'activer un mode 70W dans lequel la fréquence tombe alors à 445 MHz. Par ailleurs, l'interface PCI Express de ce GPU est limitée au PCI Express 2.0 dans le monde professionnel.

GK210, quoi de neuf ?

Alors que la génération de GPU Maxwell a pris place dans le haut de gamme grand public, c'est un nouveau GPU de la famille Kepler que Nvidia vient d'introduire dans sa gamme Tesla. Nvidia ne communique que peu de détails sur les évolutions apportées par le GK210 qui reste fabriqué en 28 nanomètres et présente une configuration globale similaire à celle du GK110. Nvidia se contente de préciser que le fichier registre et la mémoire partagée ont été doublés, ce qui dans les deux cas permet de mieux alimenter les unités de calcul du GPU et donc son rendement.

[ GK110 ]  [ GK210 ]  

Plus en détail, sur le GK110 comme sur tous les autres GPU Kepler, les unités de calcul sont intégrées dans les SMX, les blocs fondamentaux de l'architecture Kepler. Chaque SMX est subdivisé en 4 partitions qui se partagent l'accès aux unités de calcul, dont 192 FMA simple précision et 64 FMA double précision dans le cas des GPU GK110 et GK210. Chacune de ces partitions dispose d'un ordonnanceur et d'un fichier registres indépendant de 64 Ko, ce qui équivaut à 16384 registres 32-bit ou 8192 registres 64-bit. Le GPU étant une machine optimisée pour le débit, ces imposants fichiers registres sont exploités pour s'assurer que suffisamment d'éléments ("threads") puissent résider en interne de manière à ce que leur traitement successif puisque masquer la latence qui peut être très élevée pour certaines opérations.

Bien qu'imposants, ces fichiers registres ne sont pas sans limite et lorsqu'elle est atteinte, le taux d'utilisation des unités de calcul peut chuter fortement. Cela peut arriver quand le code à exécuter a besoin d'un nombre important de registres, quand de nombreuses opérations à latence élevée sont exécutées ou encore en 64-bit, mode deux fois plus gourmand sur ce point. Il peut ainsi s'agir d'un facteur limitant dans le cadre du calcul massivement parallèle et avec le GK210, Nvidia fait évoluer ces fichiers registres qui passent pour chaque partition de 64 Ko à 128 Ko (soit de 256 à 512 Ko par SMX et 7.5 Mo au total à l'échelle du GPU). De quoi s'assurer un taux de remplissage moyen plus élevé et donc de meilleures performances.

Le principe est le même pour le bloc qui regroupe la mémoire partagée et le cache L1. Chaque groupe d'éléments à traiter peut se voir attribuer une certaine quantité de mémoire partagée. Plus la quantité de mémoire partagée nécessaire est élevée, moins de groupes peuvent résider en même temps dans le GPU : la latence peut alors ne plus être totalement masquée ou un algorithme moins efficace, mais exigeant moins de mémoire partagée doit être utilisé, ce qui fait chuter les performances dans les deux cas.

Avec le GK210, Nvidia fait donc évoluer cette mémoire de 64 Ko à 128 Ko par SMX, mais, détail important, la totalité de la mémoire supplémentaire est attribuée à la mémoire partagée. Ainsi, alors que la répartition L1/mémoire partagée pouvait être sur GK110 de 16/48 Ko, 32/32 Ko ou 48/16 Ko, elle pourra être soit de 16/112 Ko, soit 32/96 Ko, soit de 48/80 Ko sur GK210 (suivant la quantité de L1 jugée nécessaire par le compilateur). En d'autres termes, la mémoire partagée sera en pratique de 2.33x à 5x supérieure sur ce nouveau GPU, ce qui pourra apporter un net gain de performances pour certaines tâches. Pour rappel sur les GPU Maxwell de seconde génération, la mémoire partagée n'est plus liée au L1 et est de 96 Ko.

Contrairement à ce que nous supposions au départ face à l'absence de réponse de Nvidia à cette question, le GK210 ne reprend pas la modification apportée aux autres GPU de la lignée GK2xx par rapport à la lignée GK1xx : la réduction de moitié du nombre d'unités de texturing. Un compromis qui permet de réduire la taille des SMX avec un impact sur les performances lors du rendu 3D, mais qui n'a pas été retenu dans le cas du GK210 qui conserve ses 240 unités de texturing, soit 16 par SMX. De quoi lui permettre de conserver l'ensemble de 4 petits caches de 12 Ko spécifiques aux unités de texturing (48 Ko par SMX). Ces derniers peuvent être déviés de leur rôle principal pour faire office de cache en lecture très performant.

Du côté grand public, ce GPU GK210 n'aura peut-être aucune existence et dans tous les cas un intérêt limité étant donné que les GPU de la nouvelle génération Maxwell y sont déjà commercialisés et sont plus performants et plus évolués sur le plan des fonctionnalités. Il permet par contre à Nvidia de proposer un GPU plus efficace dans le domaine du calcul massivement parallèle et pourrait bien être le premier GPU conçu spécialement pour cet usage. Dans tous les cas, Nvidia a de toute évidence stoppé la production de puces GK110B et, si nécessaire, pourra simplement remplacer le GK110/110B par un GK210 sur n'importe lequel de ses produits.

Reste que le timing de son arrivée peut évidemment sembler étrange. Pourquoi concevoir et introduire fin 2014 un nouveau GPU de l'ancienne architecture Kepler, alors que l'architecture Maxwell est déjà disponible ? Et qu'un plus gros GPU Maxwell, le GM200, est attendu ? Il peut y avoir plusieurs raisons à cela et deux d'entre elles nous paraissent les plus probables : soit le GM200 est très loin d'être prêt à être commercialisé, soit le GM200 n'est pas un GPU adapté au monde du HPC, par exemple parce qu'il ne serait pas équipé pour le calcul double précision.

Rien ne dit qu'il faille y voir une quelconque confirmation, mais cette seconde possibilité ne serait pas incompatible avec les roadmaps présentées par Nvidia. En mars 2013, la roadmap faisait état de l'évolution du rendement énergétique en double précision en passant de Kepler à Maxwell et enfin à Volta. En mars 2014, l'unité utilisée par Nvidia était cette fois du calcul en simple précision… et une architecture Pascal, clairement pensée pour le monde du HPC, a été intercalée entre Maxwell et Volta. Ceci dit, il nous semble difficile d'imaginer Nvidia se contenter du GK210 en 2015, et de patienter jusqu'à l'arrivée de Pascal en 2016 pour proposer une évolution plus importante sur ce marché…

Le département de l'énergie américain a tranché il y a quelques jours : les prochains supercalculateurs qu'il finance seront mis en place par IBM sur base d'une plateforme OpenPower équipée de ses futurs CPU Power9 et des GPU Volta de Nvidia associés via l'interconnexion NVLink.

Cinq années, cela semble être la durée de vie des supercalculateurs pour lesquels le département de l'énergie américain (DoE) met la main à la poche. Délivré mi-2012 sur base d'une plateforme IBM Blue Gene/Q et de CPU Power8 à l'administration nationale pour la sécurité nucléaire, Sequoia et ses 20 petaFlops (17 petaFlops mesurés) prendra sa retraite en 2017. Il en ira de même pour le supercalculateur Titan exploité par le laboratoire national d'Oak Ridge qui affiche 27 petaFlops au compteur (17.5 petaFlops mesurés). Pour rappel, ce dernier est basé sur une plateforme Cray XK7 équipée d'Opteron 6274 et d'accélérateurs Tesla K20X.

La course à la puissance ne s'arrête jamais, d'autant plus que la Chine a volé la première place du podium aux Etats-Unis avec Tianhe-2, une plateforme 100% Intel qui affiche 55 petaFlops au compteur (34 petaFlops mesurés) à travers ses Xeon E5-2692 et ses Xeon Phi 31S1P. Si ce dernier est plus performant, à noter cependant que sa consommation explose pour atteindre près de 18 mégawatts là où les actuels supercalculateurs américains se contentent de 8 à 9 mégawatts.


Ce détail est en fait très important. Nul doute en effet que le cahier des charges du DoE pour ses futurs supercalculateurs, baptisés Sierra et Summit, exigeait de ne pas trop augmenter le budget énergétique de ses futures installations, en plus bien entendu de pousser la puissance de calcul vers le haut en attendant l'arrivée des systèmes exaFlops, prévus pour la génération suivante.

Pour les deux systèmes, une même plateforme de plus de 100 petaFlops a cette fois été retenue et c'est IBM qui a reçu ce contrat de 325 millions de $. La plateforme proposée par IBM a pour particularité de s'efforcer de rapprocher les données de la puissance de calcul pour réduire les déplacements coûteux tant en performances qu'en énergie. Un argument important à l'heure où la quantité de données à traiter explose.

Alors que l'actuel Sequoia était de type 100% CPU IBM, le DoE a favorisé une solution hétérogène, étant visiblement satisfait des résultats du Titan, et a renouvelé sa confiance dans les GPU Nvidia et l'écosystème CUDA. Une étape cruciale pour Nvidia qui voit donc sa place de fournisseur de puissance de calcul confirmée sur un marché dans lequel il est difficile de percer.


Les raisons du choix du couple IBM/Nvidia sont bien entendu nombreuses et ne sont pas dues au hasard. Les deux acteurs travaillent ensemble depuis quelques temps déjà, Nvidia ayant annoncé en mars dernier une interconnexion NVLink développée en partenariat avec IBM. Pour rappel, celle-ci permet de s'affranchir du PCI Express et de ses limitations pour proposer une voie de communication plus performante entre les GPU mais également entre les GPU et les CPU. Cela implique des changements importants, notamment au niveau du format physique qui passera à un socket de type mezzanine.

Ce support de NVLink est une évolution logique du côté d'IBM qui propose déjà sur ses CPU Power8 une interface CAPI (Coherent Accelerator Processor Interface) dédiée au support d'accélérateurs spécifiques basés sur des modules FPGA interconnectés en PCI Express. De toute évidence IBM a étendu l'interface CAPI de manière à y intégrer le support de NVLink mais les spécificités à ce niveau restent inconnues.


Chaque lien NVLink est constitué d'un certain nombre de couples de lignes point-à-point et dans le cas de la première version de NVLink il est question d'une bande passante de 20 Go/s par lien (16 Go/s effectifs). Nvidia prend pour exemple un GPU équipé de 4 de ces liens qui pourrait ainsi profiter au total de 64 Go/s pour ses voies de communications vers les autres GPU et vers le CPU auquel il est rattaché, contre seulement 12 Go/s en PCI Express 3.0. De quoi booster les performances sur certains algorithmes : dans sa documentation Nvidia met en avant des projections avec +20% à +400% de mieux suivant les algorithmes observés.

Toujours au niveau de la mémoire, avec Volta, chaque GPU pourra alors être équipé d'une quantité importante de mémoire haute performances grâce à la technologie HBM. Pas question cependant de tester tout cela lors de la mise en place de ces supercalculateurs, ces technologies devront être éprouvées avant. C'est ce qu'a prévu Nvidia. En 2016, le GPU Pascal sera le premier à supporter NVLink, la mémoire HBM et le nouveau format. De quoi être prêt pour 2017 et le GPU Volta qui profitera de la version 2.0 de NVLink dont l'évolution principale sera la possibilité de supporter un espace mémoire totalement cohérent entre le ou les CPU et le ou les GPU. Pour en profiter une bande passante élevée sera nécessaire, elle pourra monter jusqu'à 200 Go/s à travers l'ensemble des liens NVLink (5 liens à 40 Go/s ?). De quoi permettre de revoir en profondeur l'architecture des supercalculateurs.

Alors que Titan par exemple est un ensemble de 18688 nœuds équipés chacun d'un Opteron 16 cœurs avec 32 Go de DDR3 et d'une Tesla K20X avec 6 Go de GDDR5, Sierra et Summit se contenteront de beaucoup moins de nœuds mais bien plus costauds et chacun équipé d'une zone de stockage locale.

Les informations concernant Sierra restent actuellement limitées, puisqu'il remplacera Sequoia dans le domaine sensible de la sécurité nucléaire. Par contre plus de détails ont été communiqués au sujet de Summit, qui remplacera Titan avec une puissance de calcul théorique qui se situera entre 150 et 300 petaFlops pour une consommation qui ne devrait augmenter que de 10% alors que l'encombrement sera nettement réduit.


Summit sera constitué de plus de 3400 nœuds, chacun présenté avec une puissance de calcul théorique de plus de 40 teraFlops (probablement bien plus puisque cela ne représente que 136 petaFlops). Chacun de ces nœuds sera équipé de plusieurs CPU Power9 et de plusieurs accélérateurs Tesla dérivés du GPU Volta. Nous pouvons raisonnablement supposer qu'il s'agira de 4 à 8 composants de chaque type par nœud. Ils seront accompagnés par un ensemble de plus de 512 Go de mémoire DDR4 (côté CPU) et HBM (côté GPU) qui formeront un seul et unique espace cohérent, même si les accès mémoire resteront optimisés pour des usages différents de part et d'autre. Par ailleurs 800 Go supplémentaires de mémoire flash seront installés, de quoi par exemple faire office de buffer pour le système de stockage de 120 petaOctets qui devra se "contenter" d'une bande passante de 1 To/s.

Ce type de contrat est très important en terme d'image de marque pour un acteur tel que Nvidia, mais il lui restera à démontrer de l'intérêt, en pratique, d'une plateforme basée autour de NVLink dans les plus petits systèmes qui représentent le gros du marché. Si seul le Power9 d'IBM et le Volta de Nvidia supportent NVLink, ils resteront dépendants l'un de l'autre pour être exploités au maximum de leurs capacités. Un pari risqué ? Sans commenter le fond de cette question, Nvidia précise qu'un petit ensemble de 4 nœuds similaires à ceux développés par IBM pour Summit suffirait à placer la machine dans la liste Top500 des supercalculateurs actuels.

Pour en savoir plus, vous pourrez retrouver deux whitepapers chez Nvidia , l'un tourné autour de ces supercalculateurs, l'autre autour de NVLink et de ses promesses (sans prendre en compte le support CPU).

La semaine passée, à l'occasion du SC13 (Supercomputing 2013), Nvidia a annoncé deux nouveautés liées au calcul haute performance : l'accélérateur Tesla K40 et la version 6 de CUDA.

Pour rappel, c'est la gamme Tesla qui a été la première à profiter du plus gros GPU de la famille Kepler, le GK110. Contrairement aux Quadro K6000 et GeForce GTX 780 Ti plus récentes, cette gamme Tesla n'accueillait cependant toujours pas de version complète du GK110, c'est-à-dire avec l'ensemble de ses unités d'exécution actives. Une configuration facilitée par l'arrivée de la révision B1 du GPU.

La Tesla K40 profite ainsi de 15 SMX, de 2880 unités de calcul FMA 32-bit et de 960 unités FMA 64-bit pour afficher une puissance de calcul en hausse de près de 10% par rapport à la Tesla K20X. Par ailleurs, comme pour le Quadro K6000, Nvidia profite de la disponibilité effective de la GDDR5 4 Gbits pour faire passer la mémoire dédiée de son accélérateur de 6 à 12 Go. Sa fréquence est par ailleurs revue à la hausse ce qui profite à la bande passante mémoire en hausse de 15%.

Si la fréquence GPU ne progresse que très peu pour la Tesla K40, c'est uniquement pour garantir que l'enveloppe thermique ne soit pas atteinte dans les tâches de type calcul, sachant que, contrairement aux GeForce, Nvidia ne propose pas de turbo pour ces cartes afin d'éviter que leurs performances soient variables. Par contre, pour la Tesla K40, Nvidia propose 2 modes avec des fréquences GPU différentes : optionnellement, il sera ainsi possible de passer le GPU de 745 à 810 ou 875 MHz. Il ne s'agit pas d'un overclocking dans le sens où ces fréquences sont validées par Nvidia, ni d'un turbo automatique, même si Nvidia place cette possibilité sous l'appellation GPU Boost, marque du turbo des GeForce... Si la personne qui exploite ces Tesla K40 constate qu'elles restent loin de leur TDP dans une certaine situation, elle aura la possibilité de passer à un de ces modes de fréquence supérieure. De quoi profiter 9% voire 17% de puissance supplémentaire.


A noter que la Tesla K40 sera proposée autant avec un refroidissement actif, comme la K20, qu'avec un refroidissement passif en vue d'intégration dans un serveur, comme la K20X. Enfin, le PCI Express 3.0 est activé sur la K40 contrairement aux K20/X.

Nvidia ne communique pas au niveau de la tarification, mais elle devrait rester inférieure à celle de la Quadro K6000, probablement passer à 5000$ alors que les K20/X devraient voir leur tarif baisser. Il faut cependant garder en tête que sur ce marché de niche, les prix sont fortement variables, les grossistes n'hésitant pas à se réserver des marges conséquentes. Ainsi pour des tarifs annoncés par Nvidia de 3200$ et de 5000$ pour les K20 et K20X, en pratique, il fallait en général compter plutôt 4000$ et 7500$, la même chose en euros.


Parallèlement à l'arrivée de cette nouvelle Tesla, Nvidia a annoncé CUDA 6 qui apporte une nouveauté majeure et très attendue : la prise en charge d'une mémoire unifiée. Une fonctionnalité qui donne l'impression d'être annoncée et réannoncée régulièrement, AMD et Nvidia ayant régulièrement joué sur les mots à ce niveau. Pour rappel, depuis quelques temps, CUDA supporte un adressage de mémoire virtuelle unifié, qui facilite quelque peu le développement mais n'était qu'un premier pas. La mémoire unifiée, représente cette fois une abstraction totale de la gestion de la mémoire : il n'est plus nécessaire que le développeur gère les transferts de données de la mémoire centrale vers la mémoire de l'accélérateur.

Une gestion manuelle de la mémoire restera possible, étant donné qu'aussi bénéfique soit cette simplification, elle peut avoir un coût sur le plan des performances et de l'efficacité puisqu'il reviendra aux pilotes et/ou aux compilateurs d'essayer de placer automatiquement les données au bon endroit.


Confiant dans l'avenir, Nvidia termine par annoncer que l'ouverture par IBM, cet été, de sa plateforme serveur POWERn, va permettre d'y intégrer des accélérateurs Tesla dès 2014. Des accélérateurs qui seront ainsi exploités non plus uniquement sur x86 mais également sur architectures POWER et ARMv8.

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 .