HSA pour les développeurs : l'informatique hétérogène pour les masses

Qu'est-ce que les fabricants de puces comme AMD, ARM, Samsung, MediaTek, Qualcomm et Texas Instruments ont en commun ? Eh bien, mis à part les similitudes évidentes entre ces géants de la fabrication de puces, ils se trouvent également être les fondateurs de la Fondation HSA. Qu'est-ce que la HSA et pourquoi a-t-elle besoin d'une fondation soutenue par des poids lourds de l'industrie ?

Dans cet article, je vais essayer d'expliquer pourquoi le HSA pourrait être un gros problème dans un avenir proche, donc je vais commencer par les bases : qu'est-ce que le HSA et pourquoi devriez-vous vous en soucier ?

HSA signifie Heterogeneous System Architecture, ce qui semble un peu ennuyeux, mais croyez-moi, cela pourrait devenir très excitant, en effet. HSA est essentiellement un ensemble de normes et de spécifications conçues pour permettre une intégration plus poussée des CPU et des GPU sur le même bus. Ce n'est pas un concept entièrement nouveau; Les processeurs de bureau et les SoC mobiles utilisent des graphiques intégrés et utilisent un seul bus depuis des années, mais HSA passe au niveau supérieur.

Plutôt que d'utiliser simplement le même bus et la même mémoire partagée pour le CPU et le GPU, HSA permet également à ces deux architectures très différentes de fonctionner en tandem et de partager des tâches . Cela peut ne pas sembler être un gros problème, mais si vous y regardez de plus près et examinez les effets potentiels à long terme de cette approche, cela commence à sembler très « doux » au sens technique.

Oh non! Voici un autre standard stupide que les développeurs doivent implémenter

Oui et non.

L'idée de partager le même bus n'est pas nouvelle, pas plus que l'idée d'utiliser des GPU hautement parallélisés pour certaines tâches de calcul (qui n'impliquent pas le rendu de headshots). Cela a déjà été fait, et je suppose que la plupart de nos lecteurs sont déjà familiarisés avec les normes GPGPU telles que CUDA et OpenCL.

Cependant, contrairement à l'approche CUDA ou OpenCL, HSA éliminerait efficacement le développeur de l'équation, du moins lorsqu'il s'agit d'attribuer différentes charges à différents cœurs de traitement. Le matériel déciderait quand décharger les calculs du CPU vers le GPU et vice versa. HSA n'est pas censé remplacer les langages de programmation GPGPU établis comme OpenCL, car ils peuvent également être implémentés sur du matériel HSA.

C'est tout l'intérêt de HSA : il est censé rendre l'ensemble du processus facile, voire transparent. Les développeurs n'auront pas nécessairement à penser à décharger les calculs sur le GPU. Le matériel le fera automatiquement.

Pour ce faire, HSA devra bénéficier du soutien de plusieurs fabricants de puces et de fournisseurs de matériel. Alors que la liste des partisans de HSA est impressionnante, Intel est visiblement absent de ce véritable who's who de l'industrie des puces. Compte tenu de la part de marché d'Intel sur les marchés des processeurs de bureau et de serveur, c'est un gros problème. Un autre nom que vous ne trouverez pas sur la liste est Nvidia, qui se concentre sur CUDA et est actuellement le leader du marché du calcul GPU.

Cependant, HSA n'est pas conçu uniquement pour les systèmes et applications hautes performances, sur du matériel qui arbore généralement un autocollant Intel Inside . HSA peut également être utilisé dans les appareils mobiles économes en énergie, où Intel détient une part de marché négligeable.

Alors, HSA est censé rendre la vie plus facile, mais est-ce encore pertinent ? Va-t-il s'accrocher? Ce n'est pas une question technologique, mais une question économique. Cela dépendra de la main invisible du marché. Donc, avant de continuer, commençons par examiner de plus près où en sont les choses en ce moment et comment nous en sommes arrivés là.

Développement HSA, problèmes de démarrage et problèmes d'adoption

Comme je l'ai dit dans l'introduction, HSA n'est pas exactement un nouveau concept. Il a été initialement envisagé par Advanced Micro Devices (AMD), qui avait tout intérêt à le faire décoller. Il y a dix ans, AMD a acheté les spécialistes graphiques ATI, et depuis lors, la société tente de tirer parti de son accès à la technologie GPU de pointe pour augmenter les ventes globales.

À première vue, l'idée était assez simple : AMD continuerait non seulement à développer et à fabriquer des GPU discrets de pointe, mais intégrerait également la technologie GPU d'ATI dans ses processeurs. Le service marketing d'AMD a appelé l'idée «Fusion» et HSA était appelé Fusion System Architecture (FSA). Ça sonne bien, non ? Obtenir un processeur x86 décent avec de bons graphiques intégrés semblait être une bonne idée, et ça l'était.

Malheureusement, AMD a rencontré un certain nombre de problèmes en cours de route. Je vais en citer quelques-uns :

• Toute bonne idée en matière de technologie est destinée à être reprise par des concurrents, en l'occurrence Intel.
• AMD a perdu l'avantage technologique au profit d'Intel et a eu de plus en plus de mal à être compétitif sur le marché des processeurs en raison de l'avance technologique d'Intel en matière de fonderie.
• L'exécution d'AMD était problématique et bon nombre des nouveaux processeurs étaient en retard sur le marché. D'autres ont été entièrement abandonnés.
• L'effondrement économique de 2008 et la révolution mobile qui a suivi n'ont pas aidé.

Ces facteurs, ainsi qu'un certain nombre d'autres, ont contribué à émousser l'avantage d'AMD et à empêcher l'adoption par le marché de ses produits et technologies. AMD a commencé à déployer des processeurs avec la nouvelle génération de graphiques Radeon intégrés à la mi-2011, et il a commencé à les appeler des unités de traitement accélérées (APU) au lieu de CPU.

Marketing mis à part, la première génération d'APU d'AMD (nom de code Llano) a été un flop. Les puces étaient en retard et ne pouvaient pas suivre les offres d'Intel. Les fonctionnalités HSA sérieuses n'étaient pas non plus incluses, mais AMD a commencé à les ajouter dans sa plate-forme 2012 (Trinity, qui était essentiellement Llano bien fait). L'étape suivante est venue en 2014, avec l'introduction des APU Kaveri, qui prenaient en charge la gestion de la mémoire hétérogène (le GPU IOMMU et le CPU MMU partageaient le même espace d'adressage). Kaveri a également apporté une plus grande intégration architecturale, permettant une mémoire cohérente entre le CPU et le GPU (AMD l'appelle hUMA, qui signifie Heterogeneous Unified Memory Access). L'actualisation ultérieure de Carizzo a ajouté encore plus de fonctionnalités HSA, permettant au processeur de changer de contexte les tâches de calcul sur le GPU et de faire quelques astuces supplémentaires.

La prochaine architecture de processeur Zen et les APU construits dessus promettent d'en offrir encore plus, si et quand elle apparaîtra sur le marché.

Donc quel est le problème?

AMD n'était pas le seul fabricant de puces à réaliser le potentiel des GPU intégrés. Intel a également commencé à les ajouter à ses processeurs Core, tout comme les fabricants de puces ARM, de sorte que les GPU intégrés sont actuellement utilisés dans pratiquement tous les SoC de smartphone, ainsi que dans la grande majorité des PC/Mac. Entre-temps, la position d'AMD sur le marché des processeurs s'est érodée. La chute des parts de marché a rendu les plates-formes d'AMD moins attrayantes pour les développeurs, les entreprises et même les consommateurs. Il n'y a tout simplement pas beaucoup de PC basés sur AMD sur le marché, et Apple n'utilise pas du tout de processeurs AMD (bien qu'il ait utilisé des graphiques AMD, principalement en raison de la compatibilité OpenCL).

AMD n'est plus en concurrence avec Intel sur le marché des processeurs haut de gamme, mais même si c'était le cas, cela ne ferait pas beaucoup de différence à cet égard. Les gens n'achètent pas des postes de travail ou des PC de jeu à 2 000 $ pour utiliser des graphiques intégrés. Ils utilisent des graphiques coûteux et discrets et ne se soucient pas beaucoup de l'efficacité énergétique.

Que diriez-vous de certains HSA pour les smartphones et les tablettes ?

Mais attendez. Qu'en est-il des plateformes mobiles ? AMD ne pourrait-il pas simplement déployer des solutions similaires pour les puces de smartphone et de tablette ? Eh bien, non, pas vraiment.

Vous voyez, quelques années après l'acquisition d'ATI, AMD s'est retrouvé dans une situation financière difficile, aggravée par la crise économique, il a donc décidé de vendre sa division Imageon GPU mobile à Qualcomm. Qualcomm a renommé les produits Adreno (anagramme de Radeon), et est devenu l'acteur dominant sur le marché des processeurs pour smartphones, utilisant des GPU maison fraîchement repeints.

Comme certains d'entre vous l'ont peut-être remarqué, vendre une tenue graphique pour smartphone juste au moment où la révolution des smartphones était sur le point de démarrer, ne ressemble pas à une décision commerciale brillante, mais je suppose que le recul est toujours de 20/20.

HSA était autrefois associé uniquement à AMD et à ses processeurs x86, mais ce n'est plus le cas. En fait, si tous les membres de la Fondation HSA commençaient à expédier des processeurs pour smartphones ARM compatibles HSA, ils vendraient plusieurs fois plus que les processeurs x86 d'AMD, à la fois en termes de revenus et d'unités expédiées. Alors que se passe-t-il s'ils le font ? Qu'est-ce que cela signifierait pour l'industrie et les développeurs ?

Eh bien, pour commencer, les processeurs des smartphones reposent déjà sur l'informatique hétérogène, en quelque sorte. L'informatique hétérogène fait généralement référence au concept d'utilisation de différentes architectures dans une seule puce, et compte tenu de tous les composants trouvés sur les SoC hautement intégrés d'aujourd'hui, cela pourrait être une définition très large. En conséquence, presque chaque SoC peut être considéré comme une plate-forme informatique hétérogène, selon ses normes. Parfois, les gens se réfèrent même à différents processeurs basés sur le même jeu d'instructions en tant que plate-forme hétérogène (par exemple, des puces mobiles avec des cœurs ARM Cortex-A57 et A53, tous deux basés sur le jeu d'instructions ARMv8 64 bits).

De nombreux observateurs s'accordent à dire que la plupart des processeurs basés sur ARM peuvent désormais être considérés comme des plates-formes hétérogènes, notamment les puces Apple de la série A, les SoC Samsung Exynos et les processeurs similaires d'autres fournisseurs, à savoir de grands acteurs comme Qualcomm et MediaTek.

Mais pourquoi quelqu'un aurait- il besoin de HSA sur les processeurs de smartphone ? L'intérêt d'utiliser des GPU pour l'informatique générale n'est-il pas de gérer des charges de travail professionnelles, pas Angry Birds et Uber ?

Oui, mais cela ne signifie pas qu'une approche presque identique ne peut pas être utilisée pour augmenter l'efficacité, ce qui est une priorité dans la conception de processeurs mobiles. Ainsi, au lieu de traiter d'innombrables tâches parallèles sur une station de travail haut de gamme, HSA pourrait également être utilisé pour rendre les processeurs mobiles plus efficaces et polyvalents.

Peu de gens regardent de près ces processeurs, ils vérifient généralement la fiche technique lorsqu'ils achètent un nouveau téléphone et c'est tout : ils regardent les numéros et les marques. Ils ne regardent généralement pas la matrice SoC elle-même, ce qui nous en dit long, et voici pourquoi : les GPU sur les processeurs de smartphone haut de gamme occupent plus d'espace en silicium que les CPU. Considérant qu'ils sont déjà là, ce serait bien de les utiliser à bon escient dans des applications autres que les jeux, n'est-ce pas ?

Un processeur de smartphone hypothétique entièrement compatible HSA pourrait permettre aux développeurs d'exploiter ce potentiel sans trop augmenter les coûts de production globaux, de mettre en œuvre plus de fonctionnalités et d'augmenter l'efficacité.

Voici ce que HSA pourrait faire pour les processeurs de smartphone, en théorie du moins :

• Améliorez l'efficacité en transférant les tâches appropriées au GPU.
• Améliorez les performances en déchargeant le processeur dans certaines situations.
• Utilisez le bus mémoire plus efficacement.
• Réduisez potentiellement les coûts de fabrication des puces en exploitant plus de silicium à la fois.
• Introduisez de nouvelles fonctionnalités qui ne pourraient pas être gérées par les cœurs de processeur de manière efficace.
• Rationaliser le développement grâce à la standardisation.

Cela semble bien, surtout si l'on considère que les développeurs ne perdront probablement pas beaucoup de temps sur la mise en œuvre. C'est la théorie, mais nous devrons attendre pour le voir en action, et cela peut prendre un certain temps.

Comment fonctionne HSA de toute façon?

J'ai déjà décrit les bases dans l'introduction, et j'hésite à entrer dans trop de détails pour plusieurs raisons : personne n'aime les romans publiés sur un blog technique, et les implémentations HSA peuvent différer.

Par conséquent, je vais essayer de décrire le concept en quelques centaines de mots.

Sur un système standard, une application déchargerait les calculs GPU en transférant les tampons vers le GPU, ce qui impliquerait un appel CPU avant la mise en file d'attente. Le CPU planifierait alors le travail et le transmettrait au GPU, qui le retransmettrait au CPU une fois terminé. Ensuite, l'application obtiendrait le tampon, qui devrait à nouveau être mappé par le CPU avant qu'il ne soit prêt. Comme vous pouvez le constater, cette approche implique de nombreux allers-retours.

Sur un système HSA, l'application mettait le travail en file d'attente, le processeur HSA prenait le relais, le transmettait au GPU, le récupérait et le transmettait à l'application. Terminé.

Ceci est rendu possible par le partage de la mémoire système directement entre le CPU et le GPU, bien que d'autres unités de calcul puissent également être impliquées (DSP par exemple). Pour atteindre ce niveau d'intégration de la mémoire, HSA utilise un espace d'adressage virtuel pour les périphériques de calcul. Cela signifie que les cœurs CPU et GPU peuvent accéder à la mémoire sur un pied d'égalité , tant qu'ils partagent des tables de pages, permettant à différents appareils d'échanger des données via des pointeurs.

C'est évidemment excellent pour l'efficacité, car il n'est plus nécessaire d'allouer de la mémoire au GPU et au CPU en utilisant de la mémoire virtuelle pour chacun. Grâce à la mémoire virtuelle unifiée, les deux peuvent accéder à la mémoire système en fonction de leurs besoins, assurant une utilisation supérieure des ressources et une plus grande flexibilité.

Imaginez un système basse consommation avec 4 Go de RAM, dont 512 Mo sont alloués au GPU intégré. Ce modèle n'est généralement pas flexible et vous ne pouvez pas modifier la quantité de mémoire GPU à la volée. Vous êtes coincé avec 256 Mo ou 512 Mo, et c'est tout. Avec HSA, vous pouvez faire ce que vous voulez : si vous déchargez beaucoup de choses sur le GPU et avez besoin de plus de RAM pour le GPU, le système peut l'allouer. Ainsi, dans les applications liées aux graphiques, avec de nombreux actifs haute résolution, le système pourrait finir par allouer 1 Go ou plus de RAM au GPU, de manière transparente.

Toutes choses étant égales par ailleurs, les systèmes HSA et non HSA partageront la même bande passante mémoire , auront accès à la même quantité de mémoire , mais le système HSA pourrait finir par l'utiliser beaucoup plus efficacement, améliorant ainsi les performances et réduisant la consommation d'énergie. Il s'agit d'obtenir plus pour moins.

À quoi servirait l'informatique hétérogène ?

La réponse simple ? L'informatique hétérogène, ou HSA comme l'une de ses implémentations, devrait être un bon choix pour toutes les tâches de calcul mieux adaptées aux GPU qu'aux CPU. Mais qu'est-ce que cela signifie exactement, à quoi servent les GPU de toute façon ?

Les GPU intégrés modernes ne sont pas très puissants par rapport aux graphiques discrets (en particulier les cartes graphiques de jeu haut de gamme et les solutions de station de travail), mais ils sont beaucoup plus puissants que leurs prédécesseurs.

Si vous n'avez pas suivi, vous pourriez supposer que ces GPU intégrés sont une blague, et pendant des années, ils n'étaient que cela : des graphiques pour la maison et les boîtes de bureau bon marché. Cependant, cela a commencé à changer au tournant de la décennie lorsque les GPU intégrés sont passés du chipset au package CPU et meurent, devenant véritablement intégrés .

Bien qu'ils soient encore terriblement sous-alimentés par rapport aux GPU phares, même les GPU intégrés offrent beaucoup de potentiel. Comme tous les GPU, ils excellent dans les chargements à instruction unique, données multiples (SIMD) et à instruction unique, plusieurs threads (SIMT). Si vous avez besoin de traiter de nombreux chiffres dans des charges répétitives et parallélisées, les GPU devraient vous aider. Les processeurs, en revanche, sont toujours meilleurs pour les charges de travail lourdes et ramifiées.

C'est pourquoi les processeurs ont moins de cœurs, généralement entre deux et huit, et les cœurs sont optimisés pour le traitement série séquentiel. Les GPU ont tendance à avoir des dizaines, des centaines et, dans les cartes graphiques discrètes phares, des milliers de cœurs plus petits et plus efficaces. Les cœurs GPU sont conçus pour gérer plusieurs tâches simultanément, mais ces tâches individuelles sont beaucoup plus simples que celles gérées par le CPU. Pourquoi alourdir le CPU avec de telles charges, si le GPU peut les gérer avec une efficacité et/ou des performances supérieures ?

Mais si les GPU sont si bons dans ce domaine, pourquoi n'avons-nous pas commencé à les utiliser comme appareils informatiques généraux il y a des années ? Eh bien, l'industrie a essayé, mais les progrès ont été lents et limités à certaines niches. Le concept était à l'origine appelé General Purpose Computing on Graphics Processing Units (GPGPU). Auparavant, le potentiel était limité, mais le concept GPGPU était solide et a ensuite été adopté et standardisé sous la forme de CUDA de Nvidia et d'OpenCL d'Apple/Khronos Group.

CUDA et OpenCL ont fait une énorme différence puisqu'ils ont permis aux programmeurs d'utiliser les GPU d'une manière différente et beaucoup plus efficace. Cependant, ils étaient spécifiques au fournisseur. Vous pouviez utiliser CUDA sur du matériel Nvidia, tandis qu'OpenCL était réservé au matériel ATI (et a été adopté par Apple). L'API DirectCompute de Microsoft a été publiée avec DirectX 11 et permettait une approche limitée et indépendante du fournisseur (mais était limitée à Windows).

Résumons en énumérant quelques applications pour le calcul GPU :

• Calcul traditionnel à haute performance (HPC) sous la forme de grappes HPC, de superordinateurs, de grappes GPU pour les charges de calcul, de calcul GRID, d'équilibrage de charge.

• Les charges qui nécessitent de la physique , qui peuvent, mais ne doivent pas nécessairement, impliquer des jeux ou des graphiques en général. Ils peuvent également être utilisés pour gérer les calculs de dynamique des fluides, la physique statistique et quelques équations et algorithmes exotiques.

• Géométrie , presque tout ce qui concerne la géométrie, y compris les calculs de transparence, les ombres, la détection de collision, etc.

• Traitement audio , utilisant un GPU au lieu de DSP, traitement de la parole, traitement du signal analogique et plus encore.

• Le traitement d'image numérique est ce pour quoi les GPU sont conçus (évidemment), afin qu'ils puissent être utilisés pour accélérer le post-traitement et le décodage d'images et de vidéos. Si vous avez besoin de décoder un flux vidéo et d'appliquer un filtre, même un GPU d'entrée de gamme essuiera le sol avec un CPU.

• Calcul scientifique , y compris la recherche sur le climat, l'astrophysique, la mécanique quantique, la modélisation moléculaire, etc.

• Autres tâches de calcul intensives , à savoir le chiffrement/déchiffrement. Que vous ayez besoin de « miner » des cryptomonnaies, de chiffrer ou de déchiffrer vos données confidentielles, de déchiffrer des mots de passe ou de détecter des virus, le GPU peut vous aider.

Il ne s'agit pas d'une liste complète des applications de calcul GPU potentielles, mais les lecteurs non familiarisés avec le concept devraient avoir une idée générale de ce qui rend le calcul GPU différent. J'ai également laissé de côté des applications évidentes, telles que les jeux et les graphismes professionnels.

De toute façon, une liste complète n'existe pas, car le calcul GPU peut être utilisé pour toutes sortes de choses, allant de la finance et de l'imagerie médicale aux charges de bases de données et de statistiques. Vous êtes limité par votre propre imagination. La soi-disant vision par ordinateur est une autre application en plein essor. Un GPU performant est une bonne chose à avoir si vous avez besoin «d'apprendre» à un drone ou à une voiture sans conducteur à éviter les arbres, les piétons et les autres véhicules.

N'hésitez pas à insérer votre blague Lindsay Lohan préférée ici.

Développer pour HSA : l'heure des mauvaises nouvelles

C'est peut-être mon opinion personnelle plutôt qu'un fait, mais je suis un partisan de HSA. Je pense que le concept a beaucoup de potentiel, à condition qu'il soit correctement mis en œuvre et qu'il bénéficie d'un soutien suffisant parmi les fabricants de puces et les développeurs. Cependant, les progrès ont été douloureusement lents, ou peut-être que c'est juste mon sentiment, avec une pincée de vœu pieux. J'aime juste voir les nouvelles technologies en action, et je suis tout sauf patient.

Le problème avec HSA, c'est qu'il n'est pas encore là . Cela ne veut pas dire qu'il ne décollera pas, mais cela peut prendre un certain temps. Après tout, nous ne parlons pas seulement de nouvelles piles logicielles ; HSA nécessite un nouveau matériel pour faire sa magie. Le problème avec cela est qu'une grande partie de ce matériel est encore sur la planche à dessin, mais nous y arrivons. Lentement.

Cela ne signifie pas que les développeurs ne travaillent pas sur des projets liés à HSA, mais il n'y a pas beaucoup d'intérêt ou de progrès, d'ailleurs. Voici quelques ressources que vous devriez consulter si vous souhaitez essayer HSA :

• HSA Foundation @ GitHub est, évidemment, l'endroit pour les ressources liées à HSA. La Fondation HSA publie et gère un certain nombre de projets sur GitHub, notamment des débogueurs, des compilateurs, des outils HSAIL vitaux et bien plus encore. La plupart des ressources sont conçues pour le matériel AMD.

• Les ressources HSAIL fournies par AMD vous permettent d'avoir une meilleure idée de la spécification HSAIL. HSAIL signifie HSA Intermediate Language, et c'est essentiellement l'outil clé pour les rédacteurs de compilateurs back-end et les rédacteurs de bibliothèques qui souhaitent cibler les périphériques HSA.

• Le manuel de référence du programmeur HSA (PDF) comprend la spécification HSAIL complète, ainsi qu'une explication complète du langage intermédiaire.

• Les ressources de la Fondation HSA sont limitées pour le moment et le programme pour développeurs de la fondation "arrive bientôt", mais il existe un certain nombre d'outils de développement officiels à découvrir. Plus important encore, ils vous donneront une bonne idée de la pile dont vous aurez besoin pour commencer.

• Le blog officiel d'AMD propose également du contenu HSA utile.

Cela devrait être suffisant pour vous aider à démarrer, à condition que vous soyez du genre curieux. La vraie question est de savoir si vous devriez ou non vous donner la peine de commencer.

L'avenir de l'informatique HSA et GPU

Chaque fois que nous couvrons une technologie émergente, nous sommes confrontés au même dilemme : devons-nous dire aux lecteurs d'y consacrer du temps et des ressources, ou de rester à l'écart, en adoptant une approche attentiste ?

J'ai déjà précisé que je suis quelque peu biaisé parce que j'aime le concept général de l'informatique GPU, mais la plupart des développeurs peuvent s'en passer, pour l'instant. Même s'il décolle, HSA aura un attrait limité et ne concernera pas la plupart des développeurs. Cependant, cela pourrait être important sur la route. Malheureusement pour AMD, il est peu probable que cela change la donne sur le marché des processeurs x86, mais cela pourrait s'avérer plus important dans les processeurs mobiles basés sur ARM. C'était peut-être l'idée d'AMD, mais des entreprises telles que Qualcomm et MediaTek sont mieux placées pour proposer du matériel compatible HSA à des centaines de millions d'utilisateurs.

Il doit s'agir d'une symbiose parfaite entre logiciel et matériel. Si les fabricants de puces mobiles deviennent fous de HSA, ce serait un gros problème. Une nouvelle génération de puces HSA brouillerait la frontière entre les cœurs CPU et GPU. Ils partageraient le même bus mémoire sur un pied d'égalité, et je pense que les entreprises commenceront à les commercialiser différemment. Par exemple, AMD commercialise déjà ses APU en tant que « dispositifs de calcul » composés de différents « cœurs de calcul » (CPU et GPU).

Les puces mobiles pourraient finir par utiliser une approche similaire. Au lieu de commercialiser une puce à huit ou dix cœurs CPU, et tel ou tel GPU, les fabricants de puces pourraient commencer à parler de clusters, de modules et d'unités. Ainsi, un processeur avec quatre petits et quatre gros cœurs de processeur serait un processeur "double cluster" ou "double module", ou une conception "tri-cluster" ou "quad-cluster", s'ils prennent en compte les cœurs GPU . De nombreuses spécifications techniques ont tendance à perdre leur sens avec le temps, par exemple, le DPI sur votre imprimante de bureau ou le nombre de mégapixels sur l'appareil photo de votre smartphone bon marché.

Ce n'est pas seulement du marketing. Si les GPU deviennent aussi flexibles que les cœurs de CPU et capables d'accéder aux ressources système dans les mêmes conditions que le CPU, pourquoi devrions-nous même prendre la peine de les appeler par leur vrai nom ? Il y a deux décennies, l'industrie a cessé d'utiliser des coprocesseurs mathématiques dédiés (FPU) lorsqu'ils sont devenus un composant indispensable de chaque CPU. Quelques cycles de produits plus tard, nous avons oublié leur existence.

Gardez à l'esprit que HSA n'est pas le seul moyen d'exploiter les GPU pour le calcul.

Intel et Nvidia ne sont pas de la partie et leur approche est différente. Intel a discrètement augmenté ses investissements en R&D GPU ces dernières années, et ses dernières solutions graphiques intégrées sont plutôt bonnes. À mesure que les GPU intégrés deviennent plus puissants et occupent plus d'espace en silicium, Intel devra trouver des moyens plus ingénieux de les utiliser pour l'informatique générale.

Nvidia, en revanche, s'est retiré du marché des graphiques intégrés il y a des années (quand il a cessé de produire des chipsets PC), mais il a tenté sa chance sur le marché des processeurs ARM avec ses processeurs de la série Tegra. Ils n'ont pas été un énorme succès, mais ils sont toujours utilisés dans certains matériels, et Nvidia concentre ses efforts sur les systèmes embarqués, à savoir l'automobile. Dans ce cadre, le GPU intégré tire son propre poids car il peut être utilisé pour la détection de collision, la navigation intérieure, la cartographie 3D, etc. Vous vous souvenez du Project Tango de Google ? Une partie du matériel était basée sur des puces Tegra, permettant une détection de profondeur et quelques autres astuces intéressantes. À l'opposé du spectre, la gamme de produits Tesla de Nvidia couvre le marché du calcul GPU haut de gamme et assure la domination de Nvidia dans ce créneau pour les années à venir.

En bout de ligne ? Sur le papier, l'informatique GPU est un excellent concept avec beaucoup de potentiel, mais l'état actuel de la technologie laisse beaucoup à désirer. HSA devrait faire beaucoup pour résoudre la plupart de ces problèmes. De plus, il n'est pas pris en charge par tous les acteurs de l'industrie, ce qui ne manquera pas de ralentir davantage l'adoption.

Cela peut prendre quelques années, mais je suis convaincu que les GPU finiront par prendre la place qui leur revient dans le domaine informatique général, même dans les puces mobiles. La technologie est presque prête et l'économie fera le reste. Comment? Eh bien, voici un exemple simple. Les processeurs Atom de la génération actuelle d'Intel comportent 12 à 16 unités d'exécution GPU (EU), alors que leurs prédécesseurs n'avaient que quatre EU, basés sur une architecture plus ancienne. À mesure que les GPU intégrés deviennent plus gros et plus puissants, et que leur surface de matrice augmente, les fabricants de puces n'auront d'autre choix que de les utiliser pour améliorer les performances et l'efficacité globales. Ne pas le faire serait mauvais pour les marges et les actionnaires.

Ne vous inquiétez pas, vous pourrez toujours profiter du jeu occasionnel sur cette nouvelle génération de GPU. Cependant, même lorsque vous ne jouez pas, le GPU fera beaucoup de choses en arrière-plan, déchargeant le CPU pour améliorer les performances et l'efficacité.

Je pense que nous pouvons tous convenir que ce serait un gros problème, en particulier sur les appareils mobiles bon marché.