Les derniers contenus liés aux tags Nvidia et ARMv8

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é !

CES: Nvidia Tegra X1: Maxwell + Cortex A57/53

Publié le 05/01/2015 à 09:30 par Damien Triolet

Comme chaque année, Nvidia profite du CES de Las Vegas pour dévoiler un nouveau SoC. Pour cette édition 2015, c'est le Tegra X1 qui est mis en avant. Au menu, le passage au 20nm, un GPU Maxwell de seconde génération optimisé pour le monde mobile et un ensemble de cœurs Cortex-A57 et A53 pour former le CPU.


Après les Tegra K1 32-bits et 64-bits, Nvidia passera dans le courant de 2015 au Tegra X1, connu précédemment sous le nom de code Erista. Une évolution qui était attendue mais qui réserve quelques surprises, notamment au niveau de sa partie CPU qui ne fait pas appel aux cœurs ARMv8 maison (nom de code Denver) exploités dans le Tegra K1 64-bits. A la place, Nvidia reprend, comme Qualcomm et Samsung, les cœurs ARM 64-bits "standards", des Cortex-A57 et des Cortex-A53.


Des cœurs ARM 64-bits standards en 20nm
Nvidia explique ce choix par le fait que le développement du Tegra K1 64-bits et du Tegra X1 s'est fait en parallèle en visant des procédés de fabrication différents. Il n'aurait ainsi pas été possible de profiter de l'expérience du développement du premier avec les cœurs Denver pour mettre au point le second. Dans ce sens il faut voir le Tegra X1 comme le successeur du Tegra K1 32-bits alors qu'une variante équipée des cœurs Denver sera dévoilée plus tard (Parker ?).


Cette approche permet à Nvidia de réduire les risques lors du passage au 20 nanomètres puisque, en amont, ARM s'est assuré de proposer un design adapté à cette technologie du fondeur TSMC. Pour son implémentation, Nvidia a d'ailleurs abandonné l'approche 4+1 des précédents Tegra qui consistait à associer un unique cœur optimisé basse consommation à un ensemble de 4 cœurs similaires mais orientés performances. L'an passé, Nvidia nous expliquait que ce mode 4+1 était beaucoup plus efficace que ce que faisait la concurrence qui avait opté pour une approche 4+4 mais avec 2 types de cœurs différents.

Changement de discours cette année, probablement parce que Nvidia n'a pas eu le choix, l'implémentation proposée par ARM a été optimisée pour du 4+4. Nvidia a donc opté pour 4 Cortex-A57 (en version cache L1 I/D de 48/32 Ko) associés à 4 Cortex-A53 (avec cache L1 I/D de 32/32 Ko). Contrairement à ce que le marketing essayera de vous vendre, cela n'en fait cependant pas un SoC octocore. Le Tegra X1 reste un SoC quadcore puisque ces 2 groupes de cœurs ne peuvent en aucun cas être exploités simultanément. Au repos ou à très faible charge CPU, les Cortex-A53 sont exploités et dès qu'une charge CPU plus lourde est initiée, ils passent au repos et les Cortex-A57 entrent en action.


Nvidia indique que son implémentation est cependant plus efficace sur le plan énergétique que celle d'autres fabricants, notamment Samsung, qui ont fait un choix similaire. Il est question d'une réduction de moitié de la consommation à performances égales et d'un gain de performances de 40% à consommation égale. Nvidia explique cela d'une part par l'expérience acquise lors du design de puces 4+1 qui lui a donné une bonne maîtrise de l'exploitation des possibilités des process de TSMC pour intégrer sur une même puce deux ensembles de cœurs CPU au profil énergétique très différent. D'autre part, Nvidia exploite sa propre interconnexion, moins gourmande que celle proposée par ARM (CCI-400).

Au niveau du sous-système mémoire, l'ensemble de Cortex-A57 profite d'un cache L2 de 2 Mo, comme les précédents Tegra, alors que les Cortex-A53 se contentent de 512 Ko. Le bus mémoire reste large de 64-bit mais passe de la LPDDR3-1866 (au départ il était question de LPDDR3-2133 mais Nvidia n'en parle plus) à la LPDDR4-3200 (jusqu'à 4 Go) pour offrir un gain de bande passante de 70%. De quoi permettre notamment d'alimenter le GPU plus musclé.


Un GPU Maxwell de seconde génération avec support du FP16
Rappelons que là où Kepler avait été portée dans le monde Tegra alors que Nvidia était déjà très avancé dans le développement de cette architecture, Maxwell est la première qui a été pensée dès le départ pour le monde mobile. Ce qui participe au fait que Nvidia ait fait un effort supplémentaire au niveau de son efficacité énergétique. Alors que de nombreux fabricants de SoC ont opté pour les mêmes cœurs CPU que ceux exploités par le Tegra X1, le GPU est bien entendu l'élément principal qui permet à Nvidia de se démarquer.


Le Tegra X1 fait ainsi appel à un GPU Maxwell de seconde génération, le GM20B, similaire au GM204 qui équipe les GeForce GTX 980 et GTX 970, mais bien entendu équipé de moins d'unités de calcul. Vous pourrez retrouver les détails à son sujet dans le dossier que nous avions consacré à ces cartes graphiques et à l'architecture Maxwell.

Là où le GM204 desktop embarque 16 blocs de 128 unités de calculs, appelés SMM, le GM20A s'en contente de 2. Le nombre d'unités de calcul principal passe donc de 2048 à 256, soit 1/8ème de la puissance de calcul du GPU le plus performant du moment, ce qui reste impressionnant pour un petit SoC. A noter que les Tegra K1 se contentaient d'un seul SMX, mais de 192 unités de calcul. Cependant sur cet ensemble, seules 128 unités était exploitables efficacement et les 64 supplémentaires n'offraient qu'un gain minime. En passant à 2 SMM avec le Tegra X1 et à une fréquence légèrement supérieure, Nvidia n'est pas loin de doubler la puissance de calcul pratique de son GPU.


Mais ce n'est pas tout. Les 256 unités de calcul du Tegra X1 évoluent pour supporter de nouvelles instructions qui vont pouvoir doubler la puissance de calcul dans certains cas. Ces instructions sont des opérations FP16 vectorielles pour les FMA, les multiplications et les additions. De plus faible précision, le format de calcul FP16 est suffisant pour bien des usages, notamment pour les jeux mobiles, et alors que la concurrence y a massivement recours pour booster les performances et l'efficacité énergétique, il était devenu inévitable pour Nvidia d'en profiter également.

Pour les GPU Nvidia précédents, aucune précision inférieure au FP32 n'est supportée directement par les unités de calcul. Si celles-ci doivent traiter une opération basse précision en FP16, elles doivent donc les traiter comme des opérations FP32 avec un débit identique et uniquement quelques petites optimisations mineures.

Pour le Tegra X1, l'ajout d'instructions vec2 permet à chaque unité de calcul FP32 de traiter deux opérations FP16 simultanément et donc de doubler le débit. Ces unités restent alimentées par des registres 32-bits classiques dans lesquels sont placées deux valeurs 16-bits. Une implémentation basique qui implique une modification mineure de l'architecture mais qui transpose tout le travail de l'exploitation du FP16 au compilateur qui devra faire en sorte de trouver des opérations vec2 dans le code et parvenir à optimiser l'utilisation du fichier registres entre les valeurs FP32 et FP16.

Cela permet de doubler la puissance de calcul théorique, qui atteint 1 TFlops à 1 GHz, mais en pratique le taux d'utilisation sera rarement optimal. Ceci étant dit il s'agit dans tous les cas d'un gain performances appréciable qui profitera notamment aux jeux mobiles friands de FP16.


Nvidia a également implémenté la dernière itération de sa technologie de compression des couleurs, et plus spécifiquement du codage différentiel. Son principe de base consiste à ne pas enregistrer directement les couleurs mais leur différence par rapport à une autre qui fait office de repère. Suivant les spécificités de chaque scène, cette technique de compression sans perte permet d'économiser une part significative de la bande passante mémoire, ce qui profite aux performances.

L'ensemble de la chaine d'affichage supporte ces méthodes de compression, ce qui permet de réduire la bande passante à tous les niveaux, jusqu'au moteur d'affichage qui ne décompresse qu'au moment de l'envoi vers l'interface de l'écran. Le cache L2 passe par ailleurs de 128 à 256 Ko, de quoi également d'éviter certains accès à la mémoire centrale. Au final, les techniques de cache et de compressions sans perte permettent par exemple de réduire la bande passante nécessaire de moitié dans Half-Life avec un gain de 30% par rapport au Tegra K1 qui était pourtant déjà plutôt efficace de ce côté.

Pour le reste, toutes les technologies supportées par les gros GPU de bureau le sont par le Tegra X1 : Direct3D 12, OpenGL ES 3.1, AEP, OpenGL 4.5, CUDA 6.0, MFAA, VXGI…


4K et 60 Hz
Le moteur vidéo, cette fois spécifique au SoC Tegra, a été lui aussi revu pour le X1. Nvidia s'est particulièrement penché sur le support de la 4K, qui lui permettra de se différencier par rapport à la concurrence sur un autre plan que la 3D. Tout le pipeline vidéo a ainsi été optimisé pour la lecture du contenu 4K à 60 fps, qui devrait être proposé notamment par le service de streaming de Netflix même s'il faut bien avouer que cela ne concernera qu'une minorité de vidéos et d'utilisateurs.


Cela passe bien entendu par un moteur de décodage 100% matériel. Il supporte la 4K à 60 fps en H.264, en H.265 (HEVC) ainsi qu'en VP9, avec un débit maximal non précisé. La profondeur des couleurs de 10-bit est également supportée en H.265 en 4K et 60 fps. Au niveau de l'encodage, Nvidia se "contente" par contre de la 4K à 30 fps en H.264 et H.265 et du 1080 à 60 Hz en VP8.

Deux écrans peuvent être supportés par le moteur d'affichage, compatible HDMI 2.0 et HDCP 2.2. Il supporte par ailleurs la technologie DSC de VESA qui permet de transmettre une image compressée à l'écran.

Le support de l'Adaptive Sync qui permettrait d'améliorer la fluidité dans le monde mobile de manière standardisée n'est par contre pas au menu. A cette question, Nvidia répond par son attachement à G-Sync accompagné d'un traditionnel "wait & see", de quoi nous laisser penser que cette technique d'affichage, ou un dérivé, pourrait être supporté sur le Tegra X1.


L'efficacité énergétique en démo
Pour mettre en avant les capacités de son SoC, Nvidia avait préparé quelques démos basées sur une plateforme de développement. Celle-ci est relativement compacte et se contente d'un dissipateur en aluminium relativement fin, censé représenter les capacités de refroidissement d'une tablette.

 
 

Quel est le TDP de ce SoC Tegra X1 ? Question délicate à laquelle il est toujours difficile d'obtenir une réponse directe. Pour ses démos, Nvidia parle d'environ 5W, mais lors de la présentation globale réalisée par son CEO, il était plutôt mentionné 10W.

 
 

Comme à son habitude, Nvidia exploite des comparaisons "isoperf" (à performances égales) pour mettre en avant l'efficacité énergétique de ses futurs SoC face aux solutions actuelles déjà sur le marché. Des données qui ont selon nous un intérêt limité puisque cette approche consiste à réduire drastiquement les fréquences et tensions du SoC le plus performant. Un calcul du rendement énergétique sur base des conditions d'utilisation réelles des puces est plus pertinent, mais cela ne permet pas d'aller chercher le fameux 2x, un must pour mettre en avant les nouveautés.

L'exemple le plus parlant est le test Manhattan, dans lequel le Tegra X1 se comporte très bien en doublant les performances par rapport au Tegra K1 et à l'A8x d'Apple. En réduisant les fréquences du Tegra X1, Nvidia observe un rendement énergétique supérieur de 77% (1.51W pour le GPU du Tegra X1, 2.68W pour celui de l'A8x). Nvidia nous indique par contre qu'à pleines performances (64 contre 33 fps), la consommation du GM20B se situe plutôt à environ 3.5W. Un petit calcul montre cette fois un gain du rendement énergétique de 48%. Un chiffre plus réaliste, mais qui reste un excellent résultat.


Le Tegra X1 face à la Xbox One ?
Souvenez-vous, lors de l'introduction du Tegra K1, il avait été comparé à la Xbox 360. Nvidia poursuit dans cette voie et pour terminer la présentation du Tegra X1, nous avons eu droit à la démo de l'Unreal Engine qui avait été utilisée pour mettre en avant les consoles de "nouvelle génération", la PS4 et la Xbox One.


Il est sans aucun doute quelque peu exagéré de dire qu'un SoC Tegra X1 dispose de capacité CPU et GPU identique à celles de ces consoles, mais le fait que cette démo (ou même une version allégée) tourne correctement sur une telle puce, montre bien les progrès qui ont été accomplis.

Si Nvidia annonce donc une fois de plus un SoC prometteur au CES, la question du timing de sa disponibilité n'a pas été abordée. Ce sera plus tard dans l'année et la concurrence proposera probablement des évolutions d'ici-là. Nvidia estime cependant que son nouveau bébé gardera la tête au niveau des capacités et des performances de son GPU. De quoi proposer une évolution de sa tablette Shield dans le courant de l'été ? Avec fonction G-Sync ?

Restera ensuite à voir quand une variante à base de cœurs Denver pourra être proposée mais l'absence totale d'information ou de démos à son niveau laisse penser qu'elle n'arrivera pas avant fin 2015 ou 2016.

GTC: Le futur de Tegra: CUDA, Logan, Parker

Publié le 19/03/2013 à 20:27 par Damien Triolet

Après la roadmap GeForce, Nvidia nous en a dit un peu plus sur la roadmap des SoC Tegra. Si certains ont été quelque peu déçus de ne pas retrouver un GPU plus moderne dans Tegra 4, cela est en passe de changer. Jen-Hsun Huang a ainsi confirmé que la prochaine architecture Tegra, Logan, intégrerait enfin une évolution GPU majeure qui fera le pont avec les technologies qui nous retrouvons dans la gamme GeForce traditionnelles.


Ainsi, le GPU de Logan sera dérivé de l'architecture Kepler avec un support complet d'OpenGL 4.3 et surtout de CUDA 5 pour permettre d'exploiter la puissance de calcul du GPU d'une manière plus flexible, par exemple pour le traitement d'images. En plus de sa plateforme propriétaire CUDA, nul doute que Nvidia supportera également la plateforme ouverte OpenCL, qui, dernièrement, a enfin reçu un support clair de la part de Google en ce qui concerne Android.

Pour le reste, il est probable que Logan reprenne les mêmes cores Cortex-A15 que Tegra 4 et soit fabriqué en 20 nanomètres. Jen-Hsun Huang a précisé que si Tegra 4 est arrivé en retard, Tegra 4i est de son côté arrivé légèrement en avance alors que Logan devrait être à l'heure avec des premiers prototypes à la fin de l'année et une production qui débutera début 2014. Vous pouvez donc vous attendre à une annonce de Tegra 5 au CES 2014.

Tout ceci n'est cependant qu'une confirmation de ce que nous supposions déjà. La nouveauté est l'arrivée de quelques premières informations sur le successeur de Logan : Parker. Ce dernier arrivera en 2015 et intègrera les premiers cores ARM conçus en interne par Nvidia et basés sur l'architecture ARMv8 qui supporte le 64-bit, nom de code Denver. Au niveau du GPU, Parker passera à la génération Maxwell, avec seulement une année de décalage par rapport aux gros GPU dekstop, les architectures GPU étant dorénavant unifiées entre les différentes divisions de Nvidia.

Parker devrait également être la première puce conçue par Nvidia en vue de l'utilisation d'un procédé de fabrication de type FinFET ("transistors 3D) et nous pouvons supposer qu'il s'agira alors du 14nm.

Top articles