Les derniers contenus liés au tag HSA

Afficher sous forme de : Titre | Flux Filtrer avec un second tag : AFDS; AMD; APU; ARM; GPGPU; Imagination Technologies; Kaveri; Samsung; Steamroller; Trinity;

ARM annonce le Cortex-A73 et le Mali-G71

Publié le 31/05/2016 à 18:15 par Guillaume Louel

ARM vient d'annoncer de nouveaux blocs disponibles pour ses partenaires. Pour rappel, ARM développe en parallèle des architectures (ARMv8-A pour la dernière version 64 bits, le pendant du x86-64 dans le monde du PC) et propose aussi ses propres implémentations de coeurs qui peuvent être utilisés par ses partenaires sous licence (l'équivalent dans le monde PC serait Intel qui autorise ses partenaires à faire des versions "custom" de Skylake).

Certains des partenaires d'ARM disposent d'une licence dite "architecture" (Apple, Qualcomm, Samsung, Nvidia...) qui leur permet de réaliser leurs propres implémentations (de la même manière qu'AMD et Intel proposent des processeurs compatibles, mais différents derrière la même architecture x86-64), même si ces derniers proposent parfois les deux. Qualcomm propose par exemple des puces utilisant les Cortex (implémentation ARM) et ses propres Snapdragon.

La nomenclature des implémentations d'ARM a toujours été compliquée à comprendre, pour ne pas dire autre chose, et autant dire qu'aujourd'hui ARM n'arrange pas son cas avec l'A73. Il fait suite sur le papier au Cortex-A72 qui avait été annoncé en février 2015 même si d'un point de vue technique les puces sont différentes.

Ce diagramme permet d'y voir un tout petit peu plus clair. Après l'époque "simple" de l'A9, ARM a proposé d'un côté des cores de grande taille, visant les hautes performances (A15, A57 et A72), également appelés big. Il s'agit de designs "Out of Order" (le processeur peut changer l'ordre des instructions pour optimiser leur exécution).

En parallèle des coeurs de plus petite tailles ont été présentés (les coeurs LITTLE comme l'A7 et l'A53). Ils utilisent un design dit "In Order" (pas de changement d'ordre) qui simplifie l'implémentation, et réduit donc la consommation de la puce. Leur niveau de performance est plus bas, mais ils disposent d'un meilleur rapport performance/watts que les coeurs big. Leur intérêt théorique est de les mélanger pour créer une architecture asymétrique (big.LITTLE, voir la présentation ici) même si en pratique, ce n'est pas toujours ce qui s'est passé.

Les deux familles sont développées par des équipes différentes (Austin pour les big et Cambridge pour les LITTLE) et au milieu de tout cela, on retrouvait les A12 et A17, mélangés sur ce graph (par une troisième équipe a Sophia-Antipolis). Il s'agissait là aussi de designs "Out of Order" mais un peu plus optimisés pour un meilleur rapport performances/watts.

Si en théorie ces puces étaient présentées comme dédiées au milieu de gamme, en pratique elles proposaient surtout une alternative aux gros coeurs ARM dont la consommation était trop élevée, obligeant de limiter fortement les fréquences pour rester dans l'enveloppe thermique d'un smartphone. On a pu voir un certain nombre de retards lors de la génération A57, particulièrement chez Qualcomm, et une surconsommation importante par rapport à ce qu'espérait ARM. Une situation qui a même poussé certains des partenaires d'ARM a proposer des puces n'utilisant que les coeurs LITTLE, un comble.

Cortex A73 : 10nm

Le Cortex A73 est présenté par ARM comme son nouveau coeur big. Il fait suite à l'A72 (16nm) et sera proposé pour les processus de fabrication 10nm. Mais contrairement à ses prédécesseurs big 64 bits (A57 et A72, c'est dur à suivre !), il s'agit sur le papier du successeur des A12/A17 (qui eux n'étaient disponibles qu'en 32 bits).

Contrairement aux A57/A72 qui pouvaient décoder trois instructions par cycle, on se limite cette fois ci à deux sur l'A73. En contrepartie, le pipeline (le nombre d'étapes par lequel les instructions passent) est significativement réduit, passant de 15 à 11 étapes. C'est au niveau du front end (récupération des instructions, décodage, changement d'ordre) que la réduction se fait. On retiendra deux changements importants, d'abord le fait que les instructions en virgules flottantes/NEON (l'équivalent des instructions vectorielles type SSE dans les architectures x86) soient traitées séparément via un décodeur distinct. La seconde est un changement au niveau des instructions arithmétiques entières avec des unités moins nombreuses mais plus performantes.

 
 

Bien que décodant une instruction par cycle en moins, l'A73 permet sur le papier au final de dispatcher 6 micro-instructions par cycle, contre 5 pour l'A72. Si l'on ajoute toutes les autres optimisations (le sous système mémoire, point faible historique des Cortex semble avoir évolué), l'A73 est annoncé comme 10% plus performant que l'A72, à fréquence/process égal.

Dans le détail, ARM annonce plus spécifiquement 15% de gains sur les copies mémoire, et 5% sur un encodage FFMPEG utilisant les instructions vectorielles NEON. Notez qu'a process égal, un coeur A73 est 25% plus petit qu'un coeur A72 et consomme 20% d'énergie en moins. En 10nm, un coeur A73 ne mesure que 0.65mm2.

Pour les puces que l'on retrouvera dans le commerce, ARM annonce 30% de performances en plus par rapport aux A72 en profitant du 10nm et de la baisse de consommation pour augmenter la fréquence. Un autre gain significatif mis en avant par le constructeur est que ses puces ne devraient plus voir leur fréquence chuter drastiquement lorsque l'on utilise tous les coeurs en simultanée.

Sur le papier l'A73 est un meilleur compromis côté architecture que ses prédécesseurs, ce qui devrait ravir les partenaires d'ARM, assez peu heureux des A57. Si ARM vise le 10nm, en pratique il propose à ses partenaires des designs A73 en 28, 16 et 10nm. D'ici la fin de l'année, des SoC 16nm devraient faire leur apparition et c'est probablement là qu'on les trouvera en masse (le 10nm sera probablement, pour rappel, réservé au moins dans un premier temps aux gros acteurs du marché comme Qualcomm et Apple à l'image de ce que l'on avait vu avec le 20nm).

Mali-T71 et Bifrost

L'autre annonce d'ARM concerne les GPU. En plus de blocs CPU, ARM propose également à ses partenaires des blocs graphiques qu'ils peuvent utiliser ou non (d'autres sociétés comme Imagination Technologies proposent par exemple leur PowerVR) pour créer leurs SoC.

La nouvelle puce est baptisée T71 et vient faire suite aux GPU T800 dont nous vous avions parlé l'année dernière. Le changement de nomenclature annonce en réalité un changement d'architecture, on passe de l'architecture Midgard à la bien nommée Bifrost.

La transition est importante avec un changement complet de philosophie, passant d'un modèle VLIW (Very Long Instruction Word) à un modèle scalaire... soit exactement la transition qu'avait effectué AMD avec GCN !

 
 

La transition aux unités scalaires change en pratique l'ordre dans lequel les données sont traitées, en simplifiant la compilation des shaders (le parallélisme étant extrait des threads, et non d'assemblage d'instructions par le compilateur).

 
 

Les threads - clauses dans le langage ARM - sont particulièrement optimisées avec des caches a tous les niveaux (sous la forme de register file) pour s'assurer que les accès mémoires soient optimisés au mieux. Cumulé à tout les autres changements architecturaux (le tiler a également été modifié pour réduire sa consommation mémoire), ARM annonce 50% de gains de performances avec Bifrost.

En pratique le Mali-T71 est le premier GPU ARM utilisant Bifrost, il regroupera jusqu'à 32 shader cores (qui comptent chacun 12 unités scalaires) et reste compatible comme ses prédécesseurs avec OpenGL ES 3.x, OpenCL 2.0 et Vulkan. On rajoutera un dernier mot sur l'interconnexion puisque l'on a droit à un accès au cache fully coherent, ce qui signifie que CPU et GPU peuvent partager la même mémoire cache en opérant en parallèle sans blocage (à la manière de Kaveri chez AMD qui utilisait cependant deux bus distincts), ce qui pourra être utile pour des tâches compute ou l'on fait travailler de concert CPU et GPU (ce qui n'est pas forcément la majorité des usages sur les plateformes mobiles).

AMD et HPC: nouveaux outils, support de CUDA

Tags : AMD; CUDA; GPGPU; HSA;
Publié le 16/11/2015 à 14:30 par Damien Triolet

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.

 
 

La spécification HSA 1.0 disponible

Publié le 19/03/2015 à 11:51 par Guillaume Louel

La fondation HSA (Heterogenous System Architecture) a annoncé cette semaine la publication de la version 1.0 de sa spécification. Pour rappel, le but de cette technologie est de proposer des solutions pour les problèmes d'hétérogénéité des plateformes de calcul - CPU et GPU – qui diffèrent fondamentalement dans leur fonctionnement et dans leur programmation. HSA tente de résoudre certains de ces problèmes, notamment autour de la manière de collaborer autour d'un espace mémoire unique.

Trois documents ont été publiés, ciblant respectivement le matériel, les développeurs bas niveau (ceux qui réalisent les outils, compilateurs, etc) et les développeurs d'applications (avec notamment un support de C++, Java et Python). Toutes ces spécifications sont téléchargeables librement sur le site de la fondation .

Lancé (et toujours présidé) par AMD, l'effort HSA regroupe désormais d'autres sociétés, particulièrement dans le monde de la mobilité. La fondation compte désormais parmi ses membres ARM, Imagination Technologies (PowerVR), LG, Mediatek, Qualcomm et Samsung.

CES: AMD en dit plus sur les APU A10 Kaveri

Publié le 07/01/2014 à 04:16 par Damien Triolet


Alors que le lancement de l'APU Kaveri, qui inaugure le 28nm de GlobalFoundries, est confirmé pour mardi prochain, AMD profite du CES pour lever un coin du voile sur les deux premiers modèles desktop, les APU A10-7850K et A10-7700K. Leurs spécifications de base avaient pour rappel fuité le mois passé. Concernant ces spécifications, nous apprenons en plus aujourd'hui que la fréquence de base de l'A10-7850K est de 3.7 GHz contre 4.0 GHz pour sa fréquence turbo maximale.

AMD confirme également que le GPU intégré portera la marque Radeon R7 alors que nous aurions pu penser qu'AMD opterait par exemple pour Radeon R5 de manière à réserver Radeon R7 et R9 aux GPU dédiés.



Avec Kaveri, AMD introduit le concept de Compute Cores, qui ne manquera pas de générer de nombreuses discussions. Un Compute Core est défini par AMD comme un bloc capable d'exécuter des tâches à travers la HSA : soit un "core" CPU (la moitié d'un module) soit un "core" GPU (une compute unit incluant 4 unités vectorielles 16-way).

Si représenter de la sorte le GPU est bien plus pertinent et honnête que de faire passer chaque ligne d'une unité vectorielle pour un core (et ainsi en porter le nombre à 512), nous ne sommes pas convaincus qu'il soit très évident pour le consommateur de comprendre la qualification d'un A10-7850K en APU 12 cores (4 cores CPU + 8 cores GPU)… Nous espérons donc qu'AMD n'abuse pas de cette simplification.

Sur le plan technique, AMD avance toujours un gain maximal de 20% au niveau de l'IPC pour les cores Steamroller, insiste sur le support de la HSA qui ouvre de nouvelles possibilités, l'intégration du moteur TrueAudio et rappelle que le GPU de type GCN supporte Mantle pour une efficacité supérieure en se débarrassant du surcoût de l'API DirectX, si les développeurs acceptent de faire cet effort.

Pour les APU Kaveri desktop, le TDP variera entre 45 et 95W suivant les modèles. AMD précise que ces APU supporteront un TDP configurable, c'est-à-dire qu'il sera possible via le bios d'adapter le TDP, que ce soit pour l'overclocking ou pour réduire température et nuisances sonores.

AMD présente également quelques chiffres de performances, probablement histoire de compenser quelque peu les premiers résultats moins encourageants qui ont circulé sur le net :


Ces chiffres fournis par AMD indiquent clairement la tendance, les gains seront à chercher du côté du GPU intégré et pas vraiment du côté des cores CPU.

APU13: HSA: nouveaux membres, Oracle, Java...

Tags : AFDS; AMD; GPGPU; HSA;
Publié le 13/11/2013 à 21:39 par Damien Triolet

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.

Top articles