Comme chaque année, Nvidia profite du CES de Las Vegas pour dévoiler au nouveau SoC. Pour cette édition 2015, c'est le Tegra X1 qui est mis en avant. Au menu, ...
Lire la suite ...

Probablement une bonne puce à venir . Reste à voir les réactions de Qualcomm et consort.
 
Le codage différentiel du framebuffer, c'est pas ce qui a été introduit par AMD avec Tonga aussi?

Oui c'est bien ça. Mais il n'a pas été introduit, il a été amélioré.

Donc décodage du 10-bit en H265 mais pas H264 ? jamais on ne pourra le lire sur un appareil mobile j'ai l'impression

« 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. »
 
Ça fait un petit moment que big.LITTLE supporte le mode HMP (Heterogenous Multi-Processing) qui permet justement d'utiliser les petits cores et les gros simultanément. Ce mode serait-il absent sur Tegra X1 ?

Merci pour cette news très complète comme d'habitude

 
Le mode HMP est optionnel à l'implémentation de big.LITTLE et est basé sur l'interconnexion ARM CCI-400 qui n'est pas ce qui se fait de mieux niveau énergétique. Nvidia utilise sa propre interconnexion et n'a pas cherché à implémenter du HMP.

Merci pour ces informations Damien !

 
Ah, d'accord, merci ! Aurais-tu des données précises sur les performances énergétiques du CCI-400, et éventuellement de la version de NVIDIA pour comparer ?
 
D'ailleurs, penses-tu que la consommation excessive du CCI-400 soit due au support du HMP ou à autre chose ? Si c'est le HMP, c'est peut-être une idée à jeter à la poubelle……

 
Je pense simplement qu'à la base un bus flexible et cohérent c'est gourmand. Je n'ai pas de données précises ceci dit.

Si ils ont dû passer de leur 4+1 à un 4+4, il est plutôt probable qu'ils utilisent une interconnexion basique en provenance d'ARM...
 
D'ailleurs, je me demande quand ils vont abandonner cette manie de tout scinder à haut niveau alors qu'il devient évident qu'il va falloir passer à un niveau plus bas (comme avec un certain Mantle...) de façon à profiter du meilleur des 2 mondes. Depuis le Pentium Pro, il n'y a quand même pas eu des masses d'évolutions de ce côté, à part chez IBM...
 
Sinon, trop gros TDP, ce SoC est juste bon à équiper une chaîne multimedia auto ou une TV connectée.

Il me semble qu'en particulier le 4+1 n'était pas très bien supporté par les systèmes d'exploitation (linux, Android ; pour Windows je ne sais pas). Les noyaux et leur scheduler gèrent mieux le 4+4, ne serait-ce que parce que tout le monde fait du 4+4.
De plus les cores semblent être en bloc de quatre avec un L2 partagé.
 
Pour l'interconnexion c'est un peu leur métier, en tant que fabricant de GPU à x teraflops. Ce sont de grands experts en transit des données sur une puce de même que Intel et AMD.

 
Mais ils ont déjà exposé encore plus bas niveau que Mantle : Cuda.

Pour la suite ce sera OpenGL "Next" qui concurrence les Mantle et DX12.

 
Sauf que Cuda n'a rien à voir avec Mantle.
 
Sinon avec un TDP pareil, je pense qu'il y a aucune chance de trouver ce Tegra X1 ne serait-ce que dans une tablette, la cible semble clairement être les voitures, donc je me demande à quoi ça sert à Nvidia de le comparer à l'A8X et autres Exynos.

Le TDP est similaire à celui du Tegra K1 donc c'est adapté aux tablettes. Ils sortiront probablement une nouvelle Shield en X1, avec une variante G-Sync ?

 
J'ai relu un peu des news du Tegra K1 de l'époque, on parlait de 5W sur le papier et de 10W réel. Actuellement le Tegra K1 est dans trois tablettes, un smartphone de jeu(OBOX W3D), le projet ara et une "console de salon"(Obox).

 
C'est bien ce que dit mon commentaire ^^

 
Ah d'accord, je pensais pas que le K1 avais aussi un aussi gros TDP. Du coup pourquoi pas effectivement.

Il n'y a pas de PCI express? ou bien c'est omis du diagramme.
 
Si c'est un SoC sans PCIe comme le fut le Tegra 4, ce sera donc réservé aux tablettes ou petits appareils façon Apple TV, "micro-consoles" etc.
Le/les Tegra K1 serait plutôt positionné sur les automobiles, avions etc. en attendant le modèle qui fait tout à la fois (Maxwell, Denver, 16FF)
 
 
 
Le TDP est au choix, je pense que la démo avec le TDP restreint à moins de 2 watts le montre bien.
 
/edit : c'était assez bête mon commentaire puisque nvidia annonce le "Drive CX Digital Cockpit Computer" et le "Drive PX Auto-Pilot platform"
http://hothardware.com/news/nvidia [...] -platforms
 

Attention pour la démo, il s'agit de la consommation isolée de la partie GPU et non de la consommation totale du SoC !

Déjà, je parlais de CPU...
 
BIG.little, c'est beau sur le papier, le HMP encore plus, mais le casse-tête que ça représente n'est pas franchement justifié. Il est difficilement envisageable d'exploiter la puissance de calcul de 2*4 cores aux perfs sensiblement différentes, idem pour le switch des "little" aux "BIG" (on se base sur quoi? Une estimation de la conso au vu de l'occupation des pipelines du petit core sur les dernières n millisecondes écoulées? On attend la saturation?)
 
Qu'est-ce qui empêche de concevoir un core CPU superscalaire très large partageant certaines unités, genre au hasard les SIMD? Si on les décompose, multiplie les "ports" (1 port MUL, 1 port ADD...) et mutualise (du "SIMT" donc), c'est tout benef.
 
Le seul frein à ce type d'archi est supposé être la fréquence, mais vu ce qu'IBM a pondu ces dernières années et le plafonnement des autres archis en terme de fréquence, c'est loin d'être un souci.
 
Au lieu de ça, on a donc des propositions franchement hasardeuses, avec plusieurs variations qu'on peut difficilement maîtriser.

En espérant qu'Nvidia fasse une maj de sa tablette Shield avec son X1 cette année

 
C'est aussi assez incompréhensible ce dont tu parles

Ben quand même, on parlait de CPU, pas d'API... ;-)
Sinon, j'ai quand même l'impression que les CPU mobile se dirigent vers plus d'intelligence et de modularité. Le out of order me semble un bon pas en ce sens.

tegra x1 vs snapdragon 810 ???

"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"
 
J'avais déjà survolé l'article mais je n'avais pas lu ça. Pour quelle raison les 64 supplémentaires n'apportent autant de gain ?
 

Il y a plusieurs raisons, l'une d'elle est que la bande passante du fichier registre est limitée et ne permet d'alimenter toutes les unités que dans certaines conditions. Ensuite ces 64 unités supplémentaires sont partagées entre plusieurs schedulers, ce qui complique la tâche du compilateur qui du coup dans bien des cas ne les exploite pas.

Merci pour cette réponse détaillée