Les derniers contenus liés au tag Denver

Hot Chips : M1, SVE, Parker, InFo et Skylake !

Publié le 29/08/2016 à 18:34 par Guillaume Louel

La conférence Hot Chips qui se tenait la semaine dernière a donné lieu a d'autres annonces intéressantes que nous avons essayé de regrouper dans cette actualité !

Rajouter des tiers de mémoire côté serveur

On avait déjà noté un peu plus tôt la volonté de rajouter de la mémoire HBM à divers endroits, et même la volonté de Samsung de travailler sur une version moins onéreuse, mais l'on rajoutera ce slide issu d'une présentation d'AMD qui rappelle les objectifs de la société côté serveurs, prenant pour le coup l'exemple du big data

On s'attardera sur le graphique à droite qui pointe l'ajout d'une mémoire intermédiaire côté CPU, type HBM ou HMC (AMD misera plutôt sur la HBM pour les déclinaisons serveurs de Zen), et aussi l'utilisation de NVDIMM pour s'intercaler avant un SSD. Il faudra attendre encore un peu pour voir comment seront déclinées ces technologies, mais il est intéressant de noter la manière dont les avancées côté mémoire sont mises en avant, parfois un peu trop tôt comme l'a fait Intel avec 3D XPoint, dans toute l'industrie.

Quelques détails de plus sur SVE

Chez ARM, outre une présentation de Bifrost côté GPU dont on vous avait déjà parlé, l'annonce principale concernait SVE, la nouvelle extension vectorielle introduite par la société.

Le premier partenaire annoncé par ARM est Fujitsu, qui mettra au point des processeurs ARMv8 avec extension SVE pour le futur supercalculateur japonais Post-K. Fujitsu a donné quelques détails, indiquant par exemple que les unités vectorielles auraient une largeur de 512 bits sur ses puces.

 
 

Chez ARM, le constructeur présente plusieurs benchmarks assez théoriques, on notera surtout sur les barres grises les améliorations qui ont été effectuées côté auto-vectorisation, c'est a dire la capacité du compilateur à utiliser des instructions vectorielles pour extraire du parallélisme. ARM devrait proposer dans les semaines qui viennent des patchs pour les différents compilateurs open source, incluant LLVM et GCC.

Le Samsung M1, un timide premier pas

La particularité de l'écosystème d'ARM est que les partenaires peuvent soit utiliser des coeurs "clefs en main", développés par ARM (les gammes Cortex, comme par exemple le Cortex A57), ou créer leurs propres implémentations de l'architecture ARM (qui restent compatibles, tout en étant différentes, à l'image des processeurs d'AMD et d'Intel qui diffèrent bien que restant compatibles). Plusieurs sociétés disposent de licences "architecture" qui permettent de créer ces puces, Apple étant jusqu'ici la société la plus à la pointe sur armv8 même si de nombreuses sociétés proposent tour à tour leurs architectures.

Parmi les nouveaux venus, il y a Samsung qui s'est lancé lui aussi dans le design d'une architecture armv8 custom pour ses Exynos M1. A la tête du projet, on retrouve Brad Burgess qui était architecte chez AMD pour les Bobcat. Il aura même été rejoint un court instant par Jim Keller (K8 chez AMD, A7 chez Apple, puis Zen chez AMD), qui n'est cependant pas resté très longtemps chez Samsung et qui n'aura probablement pas eu un grand impact. Le projet aura nécessité trois années, et en soit arriver a produire quoique ce soit du premier coup en un temps si court est un exploit.

Côté architecture, Samsung indique utiliser un perceptron  (un réseau de neurones simple) au niveau de ses mécanismes de prédiction de branches. Deux branches sont considérées par cycle, mais il est difficile d'estimer quoique ce soit sur l'éventuelle efficacité.

Quatre instructions peuvent être décodées/dispatchées par cycle aux unités d'exécutions qui sont regroupées sur sept files. On note deux files dédiées aux écritures mémoires, trois aux opérations mathématiques simple (avec un port sur lequel sont ajoutés les multiplications/divisions) et une aux branchements. Les opérations en virgules flottantes sont regroupées séparément avec un scheduler unique pour deux files. Samsung annonce 5 cycles pour effectuer une opération FMA.

Dans une configuration quatre coeurs, le M1 dispose de 2 Mo de cache L2 coupé en quatre blocs, les coeurs accèdent au L2 via une interface commune. On appréciera aussi les schémas très spécifiques que propose Samsung, pas vraiment avare de détails techniques.

Reste qu'en pratique, les benchmarks mis en avant par Samsung ne sont pas forcément très convaincants. Avec 200 MHz de plus, sur un coeur, un M1 propose 10% de performances en plus qu'un Cortex A57 à consommation égale, ce qui est tout de même très peu. Samsung fait beaucoup mieux sur les opérations mémoires (c'est relativement facile, on l'a évoqué de nombreuses fois, les contrôleurs mémoires ARM ne sont pas particulièrement véloces/adaptés aux hautes performances), mais n'en tire pas particulièrement profit hors des benchmarks théoriques.

La présentation se termine en indiquant que ce n'est qu'un premier pas pour Samsung et que d'autres designs sont en cours d'élaboration. En soit si les performances ne vont pas révolutionner le monde des SoC ARM, Samsung a au moins une base de travail qu'ils pourront faire évoluer par la suite. A condition évidemment que Samsung continue d'investir sur le sujet dans les années à venir !

Les curieux pourront retrouver la présentation en intégralité ci dessous :

 
 

Parker/Denver 2 : design asymétrique

Nvidia était également présent à Hot Chips, donnant quelques détails sur son futur SoC baptisé Parker. Ce dernier est annoncé comme crée spécifiquement pour le marché automobile avec des fonctionnalités dédiées à ce marché. On ne sait pas si le constructeur le déclinera en d'autres versions plus génériques.

Les détails techniques ne sont pas particulièrement nombreux, on notera côté SoC que l'encodage 4K est désormais accéléré à 60 FPS, que l'on peut contrôler jusque trois écrans en simultanée, et que le contrôleur mémoire passe sur 128 bits (contre 64 précédemment). Côté GPU, Parker utilisera une version dérivée de son architecture Pascal.

 
 

C'est du côté CPU que les choses sont les plus originales, après avoir utilisé son architecture Denver sur les TK1, puis être revenu aux Cortex A57 sur les TX1, Nvidia propose une architecture asymétrique avec deux coeurs "Denver 2" (sur lesquels aucun détail n'aura été donné, à part un gain performance/watts de 30% donné sans précision sur les process comparés) et quatre coeurs Cortex A57. Ce n'est pas la première fois que l'on voit des configurations originales, durant Hot Chips, le taiwannais MediaTek présentait un SoC 10 coeurs avec quatre coeurs Cortex A53 à 1.4 GHz, quatre coeurs Cortex A53 à 2 GHz, et deux coeurs Cortex A72 à 2.5 GHz !

Dans le cas de MediaTek, l'idée est de proposer différentes options à différents niveaux de consommation. Pour ce qui est de Nvidia, le choix est différent, le Cortex A57 étant "haute performance" contrairement aux A53 de MediaTek. Il faut dire surtout que le marché visé, l'automobile, n'a pas les mêmes contraintes de consommation que le marché mobile. Reste que Nvidia se doit de gérer cette asymétrie avec un scheduler qui doit décider sur quel coeur placer les threads, ce qui n'est pas particulièrement simple. On notera que chaque groupe de coeurs dispose de son propre cache L2 de 2 Mo.

Côté performances, Nvidia avec ses 6 coeurs se présente comme moitié plus rapide qu'un A9X d'Apple en deux coeurs. Le graphique mélangeant des puces à TDP différents (on y retrouve des puces pour smartphones et pour tablettes), on admettra que la comparaison n'est pas faite à TDP identique.

TSMC parle de ses packages InFo

Une des nouveautés présentées cette année par TSMC est la disponibilité d'un nouveau type de packaging, l'InFo-WLP. L'idée est de permettre de relier plusieurs dies en les "moulant" dans un substrat commun très fin qui contient également les interconnexions entre les puces. Il s'agit d'une version à cout beaucoup plus faible que les interposer (utilisés par exemple par AMD pour Fiji).

La présentation de TSMC est dédiée aux interconnexions entre les puces, et présente une puce 16nm reliant un SOC à une puce mémoire avec une bande passante de 89.6 Go/s sur 256 bits, le tout avec une consommation très réduite.

En plus de la solution présentée qui évoque le cas simple d'une puce mémoire et d'un Soc, TSMC évoque la solution comme permettant un jour de relier également plusieurs dies de logique, par exemple des groupes de coeurs séparés, pour réduire le coût de fabrication des puces (qui augmentent exponentiellement avec la taille des dies).

 
 

La présentation est technique mais reste intéressante, l'InFo-WLP ouvre des opportunités supplémentaires pour réaliser des produits qui mélangent processeur et mémoire. Le coût réduit et la finesse de l'interconnexion fait qu'on pourrait retrouver assez rapidement cette technique utilisée, y compris sur le marché mobile. Les prochains SoC d'Apple pourraient par exemple utiliser un tel package.

Et Skylake !

Juste avant la présentation de Zen, Intel proposait aussi une présentation de son architecture Skylake, lancée l'année dernière. Si la majorité du contenu est déjà connu, on aura noté un détail intéressant : un diagramme sur les unités d'exécution de Skylake. On rappellera que l'année dernière durant l'IDF, Intel nous avait promis plus de détails sur le sujet, sans jamais nous les donner !

Pour rappel, voici la répartition sur Haswell :


Récapitulatif des ports/unités d'exécution sur Haswell

Un an après, voici enfin un diagramme similaire pour Skylake :

Conformément à ce que nous avaient indiqué les ingénieurs d'Intel l'année dernière, le nombre d'unité a bel et bien augmenté. Le nombre de ports reste constant, à 8, mais l'on compte... une nouvelle unité. Sur le port 1, Intel a en effet ajouté une unité de shift vectorielle. Pour le reste, la répartition reste similaire à celle d'Haswell. Un mystère enfin élucidé !

Nvidia présente Denver

Publié le 13/08/2014 à 13:10 par Guillaume Louel

Après une annonce quelque peu confuse au CES d'un Tegra K1 en deux versions, Nvidia a profité de la conférence Hotchips pour donner quelques petits détails sur son architecture processeur Denver.


Pour rappel, Denver est une implémentation customisée de l'architecture 64 bits ARMv8. Il s'agira des premiers cores ARM custom proposés par Nvidia qui utilisait jusqu'ici des cœurs génériques ARM (Cortex-A9 dans Tegra 3, Cortex-A15 dans Tegra 4, etc…) dans ses puces Tegra. Il s'agit de la seconde architecture ARMv8 custom présentée pour l'instant, la première étant celle d'Apple (Cyclone) utilisée dans les ses SoC A7. En pratique, une version spéciale des Tegra K1 sera disponible avec deux cœurs Denver (contre quatre cœurs Cortex-A15 pour la version 32 bits du Tegra K1).

La présentation de Nvidia ne rentre pas forcément dans un très haut niveau de détails, mais l'on y trouve quelques grandes lignes intéressantes. D'abord sur les unités d'exécution :


Nvidia présente ce slide qui met face à face les unités d'exécution d'un cœur Cortex-A15 et d'un cœur Denver. On retrouve certains changements liés à ARMv8 comme le passage des unités Neon/FP (les instructions SIMD d'ARM) de 64 à 128 bits, et d'autres plus intéressants. On retrouve sept ports qui incluent un plus grand nombre d'unités, par exemple au lieu d'un seul port pour les Load et les Stores, les deux ports sont capables d'effectuer les deux types d'opération, et aussi des instructions entières. Le détail le plus important concerne surement le décodeur qui indique une phase de « prédécodage ».

De manière classique sur les Cortex-A, les instructions ARM sont décodés, réordonnées, (le principe de l'OoO, Out of Order), les registres sont renommés, puis les instructions sont dispatchées aux unités d'exécution. A l'inverse chez Intel, le jeu d'instruction x86 étant très large, les instructions x86 sont traduites en micro opérations - une sorte de jeu d'instruction réduit, interne aux unités d'exécutions – avant de subir les mêmes opérations de changement d'ordre, renommage de registres et de dispatch. Le prédécodage laisse penser que Denver utilise lui aussi un jeu d'instruction interne différent. Plus surprenant, Denver pourrait être une architecture hardware in-order.

C'est en tout cas ce que laisse penser la fonctionnalité la plus originale de Denver, ce que Nvidia appelle « Dynamic Code Optimization ». En pratique, il s'agit d'une couche logicielle qui fonctionne dans un espace mémoire (128 Mo) protégé, géré directement par le firmware et qui n'est pas accessible au système d'exploitation. Ce code logiciel fait tourner des threads cachés du reste du système dans ce que Nvidia appelle des « hidden time slices », on suppose qu'il s'agit d'un contexte dédié à l'utilisation de DCO. Que fait donc cet optimiseur ?


La liste des opérations ne trompe pas, on retrouve ici toutes les opérations effectuées par les frontend des processeurs Out of Order modernes, comme le réordonnancement d'instructions ou le renommage de registre. On trouve même quelques fonctionnalités un peu plus avancées que l'on a déjà vues chez Intel et AMD comme le dépliage de boucles.


En pratique le fonctionnement est – d'après les informations que nous avons - ainsi : le code ARM est décodé en micro instructions puis envoyé directement aux unités d'exécution. En parallèle, ce code est envoyé aux threads cachés DCO qui vont effectuer un décodage « OoO » optimisé du code ARM en micro instructions (l'optimisation est effectuée en profitant d'informations de profilage statique récupérées par l'exécution du code). Ce code est ensuite stocké dans le cache en mémoire principale de 128 Mo que nous évoquions plus tôt. La prochaine fois que ce segment de code se représentera, le code optimisé en micro instructions est récupéré du cache mémoire et exécuté directement à la place du code décodé en hardware.

Pour résumer tout cela en une phrase, Denver implémente de manière logicielle l'OoO d'habitude implémentée de manière matérielle dans les autres processeurs. Si cela vous dit quelque chose, c'est probablement parce que ce type de design avait été utilisé par Transmeta pour ses Crusoe. Une différence notable avec les Crusoe est que Denver peut exécuter directement le code ARM via un décodeur matériel (de manière moins performante, et nous le supposons, in-order). En supprimant un frontend couteux en transistors, on peut sur le papier disposer d'une plus grande marge de transistors à placer ailleurs (unités d'exécution ou même GPU), ou réduire la consommation. A l'inverse, une architecture « in-order » n'est pas, lorsqu'elle est en fonctionnement, particulièrement efficace d'un point de vue énergétique lorsqu'elle doit attendre après des instructions mémoires.

Reste que si ce genre d'architecture peut être très efficace dans des benchmarks arithmétiques, en pratique tout dépendra de la variété de code utilisée et de l'efficacité de cet « OoO » logiciel. DCO semble capable de travailler sur des blocs de taille variables pouvant aller jusqu'à 1000 micro opérations. Nvidia a ajouté un cache d'instruction de niveau 1 de 128 Ko qui peut contenir les blocs les plus utilisés, tandis que les autres seront stockés en mémoire (beaucoup plus lente) en attente d'être exécutés de nouveau.


Nvidia donne un exemple du fonctionnement en pratique. Sur ce schéma, on peut voir en haut en vert le « type » d'exécutions qui ont lieu sur les cœurs Denver durant le début d'un benchmark SpecINT 2k. Malheureusement, il n'y a pas d'échelle de temps mais l'on note en vert les instructions optimisées, en vert pale les instructions décodées en hard, et en pourpre/violet les instructions exécutées par DCO. Leur nombre est non négligeable particulièrement en début de benchmark. La proportion d'instructions issues du décodeur matériel décroit au fur et à mesure, remplacées au fur et à mesure par des instructions « optimisées ». On peut voir l'augmentation de l'IPC au fur et à mesure en bas.

L'architecture de Denver est pour le moins originale et les quelques détails donnés durant la conférence Hot Chips ne permettent pas vraiment de se faire une idée des performances réelles de la puce. Nvidia avance quelques benchmarks ou il place, dans des tests arithmétiques (et donc répétitifs, le cas le plus avantageux pour ce type d'architecture), Denver au niveau d'un Celeron Haswell 2955U (1.4 GHz, 15 watts) sans préciser le TDP ou la fréquence du Denver utilisé. Les performances dans un environnement réel ou cohabitent de multiples applications dont le code n'est pas forcément fait de traitements répétitifs dépendront de l'efficacité de cet OoO logiciel. La taille du cache d'instruction et sa rapidité pouvant devenir une ressource critique pour les performances.

La disponibilité des K1 Denver n'a pas été précisée, indiquée simplement à « plus tard cette année » par le constructeur.

Focus : Nvidia Tegra K1 et son GPU Kepler : les details

Publié le 06/01/2014 à 15:20 par Damien Triolet

Enfin, après plusieurs générations de SoC basés sur un GPU à l'architecture vieillissante, Nvidia intègre un GPU digne de ce nom. Exit le GeForce ULP et place à Kepler pour le futur Tegra K1 !

Le Tegra K1 v1

Il a souvent été fait référence au nouveau SoC de Nvidia, nom de code Logan, en tant que Tegra 5, succession logique au Tegra 4. Nvidia a cependant décidé que la rupture d'architecture qui l'accompagne devait se refléter dans le nom du produit qui sera ainsi officiellement...

[+] Lire la suite

CES: Nvidia annonce Tegra K1, avec Denver en option

Publié le 06/01/2014 à 07:48 par Damien Triolet

A chaque CES son nouveau Tegra. L'édition 2014 du salon ne déroge pas à la règle et Nvidia y annonce officiellement son nouveau SoC précédemment connu sous le nom de code Logan. Destiné aux tablettes, aux gros smartphones et autres consoles mobiles, le Tegra K1 se démarque des précédents Tegra par l'arrivée, enfin d'un GPU Kepler, à l'architecture identique à celle des GeForce GTX 600 et GTX 700.


Nous vous avons déjà parlé de Logan à plusieurs reprises, Nvidia ayant dévoilé ses caractéristiques principales en mars lors de sa conférence GTC et cet été lors du Siggraph :

4+1 cores Cortex-A15 32-bit
GPU Kepler 192 "cores" (1 SMX)
Interface mémoire 64-bit

Grossièrement Tegra K1 est donc un SoC Tegra 4 dont le GPU de classe DirectX 9 à l'architecture vieillissante a été remplacé par un GPU Kepler de classe DirectX 11 qui correspond à une demi GeForce GT 740M. Une évolution attendue depuis longtemps qui permet à Nvidia, enfin de proposer pour son SoC une composante graphique à la hauteur de sa réputation sur PC.


Nvidia parle de 365 Gflops soit une puissance de calcul au niveau des pixels supérieure à celle des consoles PS3 et Xbox 360. De quoi afficher des performances qui seraient plus que doublées par rapport à celle du SoC Apple A7.

En dehors du nom commercial du SoC, l'autre grosse annonce concerne l'arrivée d'une seconde version de Tegra K1… équipée avec 2 cores Denver. Pour rappel il s'agit du premier core ARMv8 64-bit développé en interne par Nvidia, qui promet pour celui-ci des performances de premier plan tant en single thread qu'en multi thread.


Les premiers prototypes de cette version de Tegra K1 viennent tout juste de sortir des usines de TSMC et étaient déjà fonctionnel, ce que nous avons pu observer lors d'une démonstration très limitée qui n'incluait malheureusement aucun aperçu de ses performances. Il est encore trop tôt pour cela et Nvidia est probablement très optimiste en parlant de l'arrivée de premiers produits au second semestre. Nous tablons plutôt sur fin 2014 pour que ce Tegra K1 v2 débarque dans le commerce.


Nvidia en a profité pour dévoiler les grandes lignes de ses spécifications. Contrairement au Cortex-A15 qui est de type superscalaire 3 voies, Denver passe à 7 voies. Une architecture beaucoup plus large qui s'annonce effectivement bien plus performante en single thread. Pour le reste, Nvidia parle de fréquences jusqu'à 2.5 GHz, de caches L1D et L1I qui passent à 128 Ko et 64 Ko ainsi que d'un GPU Kepler identique à celui de Tegra K1 v1. Les deux versions de Tegra K1 seront compatibles pin-to-pin, ce qui permettra aux fabricants de passer assez facilement de l'un à l'autre, et ce qui indique que l'interface mémoire reste identique à 64-bit (double canal 32-bit).

Computex: Rencontre avec JH Huang, CEO de Nvidia

Publié le 04/06/2013 à 21:24 par Damien Triolet

Juste avant l'ouverture du Computex, Nvidia a organisé autour d'un petit déjeuner une table ronde avec quelques journalistes et son CEO, Jen-Hsun Huang. Un espace de discussion toujours aussi intéressant que frustrant tant le discours parfaitement rodé et maîtrisé de Jen-Hsun Huang, ainsi qu'une durée très limitée rendent difficile de rentrer en profondeur dans les différents sujets qui concernent Nvidia (d'autant plus quand son CEO doit prendre le temps d'expliquer à un journaliste technique ce qu'est Steam).


S'il n'y aura pas eu de révélation tonitruante durant cette entrevue, Jen-Hsun Huang a malgré tout quelque peu précisé sa vision pour l'avenir de Nvidia. Tout d'abord en insistant clairement sur le fait que le graphique et l'évolution des GPU GeForce restent très importants pour la société, avec de nombreux développements en préparation. Un point qui n'est pas sans intérêt puisque depuis quelques temps, dans ses discours aux investisseurs, Jen-Hsun Huang place le GPU en retrait pour mettre en avant le marché potentiel pour les SoC Tegra.

Pragmatique, Jen-Hsun Huang admet également que Nvidia aura encore besoin du x86 pendant de longues années, certains marchés n'étant pas prêts de changer. C'est le cas par exemple des stations de travail et des applications liées, Nvidia ne les voit pas pouvoir se passer du x86 avant une dizaine d'années et ne compte bien entendu pas abandonner ce marché.

Dans d'autres domaines par contre, tels que les PC portables et même de bureau destinés au grand public ou aux joueurs, les barrières seront plus simples à franchir, et Jen-Hsun Huang ne prend pas de détour pour nous faire comprendre que Nvidia entend bien être prêt lorsque l'occasion se présentera, en précisant par exemple que de plus en plus de nouveaux développement en cours de jeux vidéo qui visent le PC prévoient également une version Android.

D'une manière subtile, Jen-Hsun Huang a également clarifié le positionnement des futurs cores ARMv8 maison, nom de code Denver. Il les destine à prendre le relai là où les cores ARM actuels montrent leurs limites, notamment face au x86. En d'autres termes, il faut comprendre qu'ils n'ont pas vocation à remplacer les cores ARM classiques dans tous les produits Nvidia, notamment dans les SoC Tegra ultra basse consommation. Il ne fait aucun doute que Nvidia ambitionne de pouvoir rivaliser avec les cores x86 d'Intel et d'AMD sur des marchés qui demandent des niveaux de performances plus élevés. Un pari risqué mais probablement pas complètement fou pour l'avenir de la société.

Top articles