HardWare.fr


Nvidia Tegra K1 et son GPU Kepler : les details
Smartphones / Tablettes
Publié le Lundi 6 Janvier 2014 par Damien Triolet

URL: /focus/94/.html


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 connu en tant que Tegra K1, en référence à l'architecture de son GPU Kepler, l'élément central de ce SoC.

 

 

D'un point de vue global, le Tegra K1 peut être vu comme un Tegra 4 amputé de son "vieux" GPU GeForce ULP, remplacé par un nouveau GPU Kepler "192 cores". En dehors de cette évolution majeure, la structure du SoC évolue peu. Nvidia conserve ainsi les cores Cortex-A15 d'ARM, mais ils passent en version r3 (qui autorise des optimisations supplémentaires pour réduire la consommation) et, grâce au process 28nm HPM, gagnent quelque MHz puisqu'ils pourront atteindre 2.3 GHz contre 1.9 GHz pour Tegra 4.

La technologie vSMP (variable Symmetric MultiProcessing) également dénommée "core compagnon" ou "4+1", reste de la partie. Elle consiste pour rappel à donner le contrôle, au repos et en charge faible, à un 5ème core identique aux 4 principaux, un Cortex-A15 dans le cas présent, mais synthétisé dans l'optique d'une implémentation plus économe en énergie. En contrepartie, il est limité en fréquence. Nvidia conserve également le cache L2 partagé de 2 Mo et le bus mémoire 64-bit LPDDR3-2133.

 


Comme d'habitude pour les Tegra, il ne s'agit pas du die réel mais d'un montage destiné à représenter une vue artistique du SoC.


Parmi les autres "petites" évolutions, citons de nouveaux processeurs d'images et des interfaces vidéo remises au goût du jour. Si le Tegra 4 supportait déjà la 4K via sortie HDMI, ce n'était pas le cas pour la dalle du périphérique dont la résolution était "limitée" au 3200x2000. Cette limitation disparaît avec le Tegra K1 qui pourra piloter directement les dalles 4K. Au train où les choses évoluent, cette résolution ne devrait plus tarder à arriver dans le monde des tablettes voire même des smartphones.

 

Le Tegra K1 v2

Un second Tegra K1 est également en préparation, identique à l'exception des cores CPU. Il s'agit cette fois de 2 cores Denver en lieu et place de la configuration 4+1 en Cortex-A15.


Pour rappel, Denver est le 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. Pour y parvenir, Nvidia a conçu un core relativement large, capable d'alimenter les unités d'exécutions jusqu'à hauteur de 7 opérations par cycle contre 3 pour un Cortex-A15. Chaque core profite également de caches L1 revus à la hausse, 128 Ko pour le L1D et 64 Ko pour le L1I contre 32 et 32 Ko le Cortex-A15 tel qu'il est configuré dans Tegra 4.

Pour ces "gros" cores ARM 64-bit, Nvidia n'a pas négligé la fréquence puisqu'il est prévu qu'elle atteigne 2.5 GHz. Il semble évident que ces 2 cores Denver seront préférables aux 4 cores Cortex-A15 sur le plan des performances. Restera à voir s'il en est de même sur le plan de la consommation.

 

Cortex-A15 r3 et 28nm HPM

Pour le Tegra K1 v1, Nvidia reprend les cores Cortex-A15 de Tegra 4, mais ils passent de la version r2p1 à la révision r3p3, plus récente. Il n'y a pas de réelle différence en termes de performances, principalement des corrections de bugs mineures. Le changement le plus notable est l'introduction de plus de flexibilité au niveau du clock gating, l'une des techniques qui permettent d'économiser de l'énergie, dans ce cas en stoppant la distribution de signal d'horloge. Cette flexibilité supplémentaire permet par exemple d'appliquer le clock gating par petites zones, de quoi pouvoir en profiter dans plus de cas.

La variante HPM du 28nm de TSMC permet de son côté, pour rappel, un compromis différent : moins de consommation dynamique et plus de consommation statique. Le premier point facilite la montée en fréquence à consommation fixe alors que l'impact du second, s'il peut être problématique dans le cas de grosses puces, peut être compensé par une utilisation poussée du power gating et du clock gating.

 


Au final, Nvidia parle soit d'une réduction de 55% de la consommation à performances égales ou d'un gain de performances en hausse de 40% à consommation égale. Bien entendu Nvidia se base ici sur les points de la courbe de fréquences qui l'arrangent le mieux, mais en gain notable devrait cependant se faire sentir en pratique. Nvidia estime avoir l'implémentation la plus efficace du Cortex-A15 sur le plan énergétique

 

Double processeur d'image boosté

Le processeur d'images de Tegra K1 a été mis à jour lui aussi. Il supporte toujours la Chimera Computational Photography Architecture, un ensemble d'API qui permet d'exploiter le GPU, le CPU et l'ISP (Image Signal Processor) main dans la main pour améliorer l'aspect prise de vue, que ce soit pour des photos ou des vidéos. Le GPU plus évolué et plus puissant lui ouvre de nouvelles possibilités.

 



L'ISP en lui-même évolue d'une manière assez nette. Nous devrions plutôt dire les ISP puisque Nvidia en a placé deux dans le Tegra K1, chacun capable de prendre en charge un débit de 600 megapixels. Nvidia a voulu prévoir large et va jusqu'à supporter des capteurs photo de 100 megapixels et jusqu'à 4096 points de focus. Nvidia compte proposer un support logiciel avancé et complet à ce niveau, pour essayer de se démarquer de la concurrence, également très active sur l'aspect photo.

 

Un GPU Kepler, un vrai !

Par rapport aux GPU des précédents SoC Tegra, nous avons toujours eu l'impression que Nvidia se contentait du strict minimum, tablant d'une part sur l'image positive de la marque GeForce pour faire illusion d'une suprématie technique dans le monde des GPU ultra mobiles, et d'autre part sur son expertise sur le plan logiciel pour rester compétitif en termes de performances.

Les GeForce ULP des Tegra 2, 3 et 4 n'étaient pas de mauvais GPU, mais ils restaient pauvres au niveau des fonctionnalités supportées et manquaient un peu de punch alors même que la concurrence (PowerVR et Qualcomm) progressait très rapidement.

Pour rappel, les GeForce ULP sont basés sur une architecture plutôt rigide, de classe DirectX 9. Il est souvent dit qu'ils sont dérivés des GeForce 6/7, mais ce n'est pas correct. Il s'agit d'une architecture totalement différente, prévue pour le monde ultra mobile, et plus proche en réalité des Radeon proposées il y a une dizaine d'années. Dans le cas de Tegra 4, le GPU GeForce ULP intègre 6 unités vec4 de traitement de la géométrie, de 12 unités vec4 de traitement des pixels (limité en précision au FP20) et de 4 unités de texturing. Soit 72 cores en langages marketing. Vous pourrez retrouver plus de détails ce sujet par ici.


Nvidia a probablement essayé de tirer sur la corde aussi longtemps que possible pour pouvoir se contenter de cette architecture GPU en attendant qu'exploiter sa technologie GPU classique devienne réaliste dans le monde ultra mobile. Enfin, à mi-chemin durant le développement de l'architecture Kepler, soit il y a +/- 3 ans, Nvidia a décidé que le moment était venu d'opérer cette transition. D'après les estimations de ses ingénieurs et de différentes simulations, porter Kepler dans l'ultra mobile était possible. Notez que Nvidia parle de Kepler "discrete" (GPU classique) et de Kepler "mobile" (SoC).

Nvidia a alors tout misé sur Kepler et stoppé le développement des GeForce ULP. Un risque, mais qui était calculé. Mais s'agit-il vraiment du vrai Kepler ou d'une version au rabais ? Avec le GPU GK208 (GeForce GT 630, GT 740M), Nvidia a revu à la baisse les spécifications des blocs fondamentaux de Kepler, les SMX. Ainsi les 2 SMX du GK208 se contentent de 8 unités de texturing chacun, contre 16 pour les autres GPU Kepler. Nous estimions alors probable que Nvidia passe à 4 unités de texturing pour Kepler mobile, car celles-ci peuvent être très gourmandes, et simplifie d'autres aspects de l'architecture.


Lorsque nous avons eu l'opportunité de rencontrer les architectes de Logan, et donc du GPU Kepler mobile (GK20A), nous avons déroulés bon nombre de questions qui partaient du principe qu'il y aurait des différences. A notre grande surprise, il s'est cependant avéré que Kepler mobile dans Tegra K1 est composé d'un SMX identique à l'un de ceux du GK208. Nvidia n'a revu à la baisse aucune de ses capacités, que ce soit sur le plan du texturing ou du calcul. Le Tegra K1 intègre ainsi un SMX qui est capable, par cycle, de :

192 opérations FMA 32-bit
8 opérations FMA 64-bit
32 opérations spéciales 32-bit
8 filtrages bilinéaires FP16
32 loads/stores

Ce SMX est accompagné de 4 ROP pour l'écriture des pixels en mémoire, dont les capacités sont également identiques à celles des autres GPU Kepler. Un nombre de ROP qui correspond au nombre de pixels qu'est capable de débiter le SMX à chaque cycle. Ce dernier a par ailleurs un débit de 0.5 triangle par cycle (1 par cycle en Z only). Point important à noter, étant donné que le GPU Kepler n'est constitué que d'un seul SMX, Nvidia n'a pas la possibilité d'en proposer une version lowcost comme c'est le cas pour le GeForce ULP du Tegra 4i puisque l'architecture est déjà à son niveau minimum.

 



Un vrai Kepler donc qui amène dans le monde ultra mobile le support de DirectX 11.x au niveau matériel 11_0, d'OpenGL 4.4 et de CUDA 6. OpenGL ES 3.0 est évidemment de la partie lui aussi et est d'ailleurs actuellement utilisés sous Android avec des extensions propriétaires pour se rapprocher d'OpenGL 4.4, qui n'est pas proposé directement par l'OS de Google.

A noter sur le plan du GPU computing que le processeur de commandes de Kepler mobile est du niveau de celui des GK104, GK106 et GK107. Il ne supporte donc pas le Dynamic Parallelism comme c'est le cas pour les GK110 et GK208, une fonction qui permet au GPU d'auto-générer des tâches pour éviter des allers-retours vers le CPU. En dehors de ce point, Kepler mobile est bel et bien un demi GK208.

 

Mais comment cela peut-il passer en moins de 2W ?

Nvidia annonce une consommation inférieure à 2W pour Kepler mobile. Comment cela est-il possible ? Jonah Alben, SVP GPU Engineering, nous explique qu'il est en fait "presque" très simple d'y parvenir, en partant de l'exemple du GPU GK208 de la GeForce GT 740M :

- sa consommation de base est de 19W
- une fois amputé de la partie IO (connectique bus mémoire, PCI Express…), il tombe à 16W
- ce GPU dans cette configuration voit 6W partir en courant de fuite, sans quoi il passe à 10W
- il contient 2 SMX contre 1 pour Kepler mobile, soit 5W
- avec des fréquences/tensions plus faibles, nous passons à +/- 2W
- quelques optimisations plus tard et Kepler mobile peut se contenter de 1.2 à 2W

Passer de 2 à 1 SMX permet de réduire la consommation d'une manière directe mais également indirecte puisque tout le système de communication entre les différents SMX du GPU n'a plus lieu d'être. De quoi réaliser des économies substantielles. Nvidia précise ensuite avoir poussé ses ingénieurs à optimiser chaque petite unité du GPU de manière à optimiser l'efficacité énergétique et effacer les derniers mW qui étaient de trop. Un travail de longue haleine mais qui aurait fini par porter ses fruits et permettre de concrétiser l'arrivé de Kepler dans un SoC Tegra.


Si faire passer Kepler sous la barre des 2W est plutôt remarquable, cela reste malgré tout un niveau de consommation élevé pour un SoC destiné au monde ultra mobile. Il est donc important de faire en sorte de rester autant que possible à une consommation inférieure. Nvidia compte pour cela sur plusieurs choses, à commencer par sa longue expérience qui lui permet d'atteindre un niveau d'efficacité très élevé et donc de ne gaspiller que très peu de ressources. Les pilotes jouent pour cela un rôle important, mais quelques subtilités architecturelles sont également importantes. C'est le cas de tous les systèmes d'éjections des pixels masqués ou encore du mode 3DPFM qui permet de passer outre les unités de calcul principales quand aucune opération n'est nécessaire.

Nvidia insiste ensuite sur toute la partie compression de données. C'est le cas tout d'abord de la tessellation, qui peut être exploitée dans ce sens en utilisant une géométrie de base simplifiée pour réduire les transferts de données, gourmands en énergie. Ensuite, Nvidia a intégré le support du format de textures compressées ASTC. Celui-ci est a été finalisé trop tard pour être intégré aux GPU Kepler classiques, mais a pu prendre part à Kepler mobile.


  [ Sans compression ]  [ Avec compression ]


Enfin, cette fois par rapport à la concurrence directe, Nvidia estime disposer d'un gros avantage au niveau de la compression lossless du framebuffer, fonctionnelle d'une part quand un groupe de pixels adjacents a la même couleur et d'autres part sur certains dégradés réguliers. De quoi économiser énormément de bande passante mémoire dans certains cas, ce qui est bénéfique sur le plan des performances et permet des économies d'énergies importantes.


Tout cela permet selon Nvidia d'afficher des performances par watt 50% supérieures à celles des SoC A7 et S800 d'Apple et Qualcomm. Attention cependant, Nvidia limite ici fréquence et tension pour s'aligner sur les performances de ces derniers. A pleine vitesse, cet avantage sera en toute logique moindre.

 

192 cores pour surpasser les consoles "old gen" ?

S'il y a bien un point litigieux dans le monde des GPU, c'est l'utilisation du mot cœur ou core. Depuis les GeForce 8800, Nvidia a décidé de compter comme "core" chaque ligne d'une unité vectorielle. De quoi sortir de gros chiffres pour s'opposer au CPU et insuffler un sentiment de puissance aux néophytes. Cette notion de core a fini par prendre des proportions ridicules dans certains cas et le Tegra K1 n'échappe pas à cette règle.

En pratique, le GPU de Tegra K1 devrait plutôt être qualifié de monocore équipé de plusieurs très larges unités vectorielles qui représentent l'équivalent de 192 unités de calcul, mais c'est bien entendu moins vendeur. Malheureusement, Nvidia semble avoir l'intention de mettre fortement en avant l'argument "192 cores", ce que nous déplorons.



365 GFlops pour Tegra K1 sur base de la prévision d'un GPU cadencé à 950 MHz.


L'autre point mis en avant par Nvidia est une comparaison avec les consoles précédentes dont la puissance de calcul au niveau du GPU est inférieure, tout comme la quantité de mémoire les fonctionnalités graphiques. Nvidia estime ainsi avoir surpassé ces références avec Tegra K1. Difficile de confirmer ou d'infirmer la validité de cette comparaison tant de nombreux éléments entrent en compte dans les performances. Il semble cependant évident que Tegra K1 est parvenu globalement à un niveau du même ordre de grandeur que celui de ces consoles, ce qui permet de prendre la mesure de l'évolution fulgurante des SoC et de leurs GPU.

 

Le support développeur

Tout comme pour ses GPU classiques, l'un des points forts de Nvidia est son support logiciel que ce soit à travers les pilotes ou les outils proposés aux développeurs. Kepler oblige, les pilotes sont déjà optimisés et beaucoup de développeurs de jeux vidéo sont déjà habitués à cette architecture. Qu'il s'agisse d'un portage de jeu PC d'il y a quelques années ou d'un jeu récent adapté au monde ultra mobile, Nvidia compte en tirer un avantage compétitif.


Epic, généralement proche de Nvidia, propose déjà une version fonctionnelle de l'UE4 pour Tegra K1 et le résultat est plutôt réussi même si nous avons l'impression que certaines démos font appel à beaucoup de précalcul au niveau de l'éclairage, ce qui n'est pas spécialement adapté à des environnements de jeux plus dynamiques.

Reste que pour que Tegra K1 soit exploité au niveau de son plein potentiel par un maximum de jeux, il faudra qu'il représente des parts de marché significatives. Et pour cela Nvidia va devoir convaincre un maximum de partenaires de lui faire confiance. Si Nvidia semble sur le papier, enfin disposer d'un SoC à la hauteur des attentes que l'on peut avoir d'un spécialiste du GPU, il lui reste à confirmer dans la pratique cette impression positive, à démontrer que la consommation est réellement bien maîtrisée et à éviter tout retard. La concurrence n'est pas très loin et Qualcomm, avec le Snapdragon S805 par exemple, dispose également d'une solution intéressante sur le papier.


A noter qu'en attendant l'arrivée de plus de produits en Tegra K1, il est probable que la tablette Tegra Note proposée par Nvidia ainsi que la console Shield soient mises à jour, peut-être cet hiver ou au début du printemps.

 

Une orientation nouvelle pour le développement des GPU Nvidia ?

Kepler est la première architecture de Nvidia pensée autant pour les GPU classiques qu'ultra mobiles. Développer une seule architecture unifiée permet à Nvidia d'utiliser ses ressources plus efficacement tant au niveau hardware que software. Comme nous l'avons dit plus haut, le choix de passer à Kepler pour un futur SoC Tegra a été fait en plein milieu du développement de cette architecture.

C'est donc la suivante, Maxwell, qui sera la première à avoir été pensée dès le départ pour ces deux mondes. Nvidia explique d'ailleurs qu'un certain nombre d'optimisations mises en place spécialement pour Kepler mobile vont être intégrées d'une manière général pour Maxwell puisqu'elles profitent à toutes les déclinaisons de l'architecture.


Est-ce que cette unification des architectures ne va pas limiter les GPU plus haut de gamme ? Il y aura des compromis à faire, ou plutôt il y a eu des compromis de faits, ce que ne nie pas Emmett Kilgariff, l'ancien responsable de l'architecture de 3dfx qui est actuellement l'un des architectes principaux des GPU Nvidia et qui était en charge de Kepler mobile. Il ajoute cependant que la 3D temps réel a toujours été une histoire de compromis et que la plupart des décisions faites en faveur d'une meilleure efficacité énergétique profitent également au final aux plus gros GPU qui sont limités par leur consommation.



Copyright © 1997-2020 HardWare.fr. Tous droits réservés.