[Discussion] La technique et les smartphones/tablettes (ex-topic Cortex A15)

[Alex98]

Je veux bien jetter un oeil si tu as un lien voor.ce qu'il est possible de faire avec ce système.

Sinon, j'ai jeté un oeil tout à l'heure et on perd quand même entre 35% et 78% de perfs par rapport à du code natif avec le java sur Android (sur des instructions simples).

[Infernus]

En direct de chez ARM : http://blogs.arm.com...ve-development/

Si j'ai bien lu, il est possible de faire pratiquement sans Java. Faudrait que j’expérimente à l'occasion.

Edit : Un article intéressant sur Tegra 4/4i et les archis sous-jacentes (A15/A9r4)

Modifié 4 mars 2013 par Infernus

[lolobarjo]

Rien que le début est très intéressant, je prendrait le temps de le lire a tête reposer. Merci pour le partage

Envoyé avec mon SGS2 Citizy accro à CM10.1 -> Tapatalk

[Alex98]

L'article est effectivement intéressant mais malheureusement ressemble plus à du PR qu'autre chose. Les données de Nvidia sont reprises presque sans contestation.

Les scores GLBenchmark par exemple, sont repris tel quelle alors qu'on sait que pour obtenir ce score Nvidia a utilisé une version modifié de l'app pour forcer l'usage d'un format de compression des textures moins lourd sur le T4.

Idem avec le facteur 10 avancé par Nvidia pour le gain de conso du core companion. C'est au mieux sortie du contexte (genre situation d'overdrive des A15 vs fréquence minimum pour le companion), au pire complètement irréaliste.

Quand aux performances GPU je suggère de jeter un oeil à la documentation fournies par Nvidia :

Le passage sur les core compagnon est vraiment une reprise de l'argumentaire de Nvidia sans comparaison avec le fonctionnement réel des architectures en fait... Nvidia se garde bien de dire que l'usage d'architecture asymétrique augmente le besoin en virtualisation et qu'au final il ont besoin de tout compenser via software (raison pour laquelle les core compagnon ne marchent pas sous windows RT). De même que les architectures big.LITTLE ne fonctionne pas selon le principe du "on switch à fréquence égale" mais du "on switch à perfs égales" (le switch se fait d'un A7 @ 1.2Ghz vers un A15 @ 800Mhz sur les devboard).

[Infernus]

Je ne suis pas arrivé à la partie parlant des résultats sur les benchs.

Pour la partie consommation c'est clair que le rapport de 10 semble un peu fou.

Pour les coeurs compagnon je dois avouer que je me posais justement la question.

J'ai commencé à lire les diapos d'ARM sur la technologie big.LITTLE, et justement ils appuyaient le fait qu'une archi avec un même nombre de coeurs est bien plus facile à gérer.

C'est la même idée ici ?

[Alex98]

Je pense que le mieux c'est de voir comment fonctionne les deux architectures.

Disons que tu es obligé de dire à l'OS combien de coeurs a ton CPU (pour des raisons évidente de répartition des instructions). Dans le cas des Tegra, tu déclare 4 cores. De fait, quand tu tourne sur le core compagnon, il t'en manque 3 du point de vu de l'OS. Du coup, on passe par la virtualisation pour faire commd si on en avait 4.

Du côté d'ARM tu as un nombre symétrique de cores supportant les mêmes instructions. Que tu sois sur les A7 ou les A15, les apps s'executent exactement pareil mais plus ou moins lentement. A cela il faut aussi ajouter le fait que le switch n'est pas géré par l'OS mais dans un hypervisor ce qui signifie que pour l'OS, il n'y a jamais de changement d'architecture.

[Infernus]

Et la virtualisation augmente tant que ça les latences et la consommation ?

Parce que sinon effectivement l'argumentaire se tient.

En ajoutant à cela que lorsque l'on repasse sur les 4 gros il faille faire des transferts entre le cache du companion et le L2 unifié.

[Alex98]

D'après ARM, le switch prend 20.000 cycles. À 200Mhz c'est 10-20 fois plus rapide que les Tegra.

A voir en vrai

[Infernus]

Comme d'hab, entre la théorie et la pratique...

Une question que je me pose cependant pour l'archi big.LITTLE, et plus particulièrement dans l'implémentation de l'octa.

On a 4 clusters ? chacun composé d'un combo A7/A15 ? et on n'active qu'un des 2 coeurs de chaque cluster ? c'est ce que j'ai conclu de la vidéo de présentation de Samsung sur la tablette octa.

Parce que l'implémentation qui traîne dans les diapos d'ARM (en tout cas celles que je lis), c'est 2 clusters, un de 2 A15 et un autre de 2 A7.

Bien entendu, un seul des 2 clusters tourne à la fois.

Et pour finir (si je peux me permettre autant de questions). Le CCI (Cache Coherent Interconnect), est une sorte de cache L3 communs aux clusters, c'est ça ? (après ce cache n'existe peut être que sur l'implémentation exemple que j'ai sous le nez)

[Alex98]

Alors dans l'octa c'est 2 cluster, un de 4 A15 et un de 4 A7. Je ne pense pas qu'il soit possible de faire des clusters mixtes d'ailleurs car chaque cluster a son propre cache adapté aux types de cores. Or les A15 demandent beaucoup plus de cache.

Le CCI-400, quant à lui, est plutôt une unité chargé de transférer le cache L2 d'un cluster à l'autre et éventuellement de le remettre dans l'état adéquat. Il assure aussi la cohérence des IO

[Infernus]

Ok...du coup le power gate permet de couper chaque coeur indépendamment des autres ? (si j'ai bien suivi)

Du coup quel est l'intérêt de parler de cluster ? excepté pour le fait que chaque cluster à un L2 commun entre ses coeurs.

Merci de tes explications !

[Alex98]

Alors oui, dans l'architecture de Samsung, chaque coeur est power gated. Mais ce n'est pas un pré requis de l'architecture.

Après, on parle de clusters car les deux entités sont bien séparé dans le design. D'ailleurs c'est une obligation car lzs actuels designs ARM ne supportent pas plus de 4 cores par cluster. Les design 8 cores sont en fait des designs big.big acec 2 clusters de 4 A15.

La notion de cluster a aussi un intérêt terminologique à être conservé puisque le mode de fonctionnement de base du big.LITTLE est justement un switch entre cluster et non entre CPU.

[Infernus]

Donc l'implémentation de Samsung est vraiment maline, c'est un peu l'idée de Qualcomm avec l'asynchrone. On ne démarre qu'un certains nombre de coeurs A15 suivant les besoins.

Une autre question encore pour le moment (tant que ça me viens), est-il possible de mélanger les process de gravure ?

Par exemple graver les A7 en LP (si je me trompe pas), comme le but est rarement de les utiliser à fond.

Et de graver les A15 en HPM comme ceux-ci tourneront plus souvent à "haute" fréquence.

[Alex98]

A priori, Samsung aurait confirmé à l'ISSCC n'utiliser que du 28nm HP with HKMG pour les Exynos 5 Octa.

Avant ils utilisaient le HPL (en 32nm) mais ils vont apparemment l'abandonner.

Modifié 4 mars 2013 par Alex98

[Infernus]

Je parlais de carrément mélanger les process sur un même waffer, même si j'ai des gros doutes sur la faisabilité de l'idée.

[Alex98]

Selon TSMC ce n'est pas possible. Du moins pas actuellement.

[Infernus]

Ce sera tout pour ce soir en ce qui me concerne, je n'ai rien d'autre qui me vienne à l'esprit.

Je te remercie encore du tout et du soin que tu apportes à me répondre =)

[Alex98]

Ce topic est là pour ça =p. Au contraire, c'est sympa que les posent des questions qui, en plus, ne doivent pas intéresser que toi.

En tout cas le design circuit t'intéresse toujours autant on dirait =p

[Infernus]

C'est un peu des légos, et puis j'ai mon cours d'archi derrière moi maintenant (d'ailleurs faudrait que je relise la partie sur les pipelines).

Toujours intéressant d'apprendre par plus calé que soi !

[Alex98]

Ce qui est dommage c'est que TI aillant disparu, Qualcomm, Nvidia et Intel ne souhaitant pas donner de détail sur leur architectures et Apple qui... fait son Apple, il ne reste plus grand chose à quoi s'intéresser.

[Infernus]

C'est vraiment dommage que TI ait disparu oui... surtout qu'ils s'amusaient bien à communiquer (voir même trop)

[Alex98]

Parlant de TI, je me rappel que les OMAP5 équipés de PowerVR SGX544MP2 @ 532Mhz tapaient 45Fps à Egypt HD 1080p offscreen.

[lolobarjo]

Sauf qu'on a toujours pas de nouvelle sur leur sortie de l'OMAP 5

Envoyé avec mon SGS2 Citizy accro à CM10.1 -> Tapatalk

[Alex98]

Non. On parle de Q2 2013 de façon officieuse. Il y aurait aussi une devboard mais le silence total de TI le fait dire qu'ils ne sortiront même pas les modèles développés.

Mais mon commentaire été lié au fait que l'Exynos 5 Octa utilise le même GPU mais en version MP3 au lieu du MP2.

[Infernus]

Je sais pas si ça veut dire grand chose, c'est surtout que TI parlait très tôt de ses technos.