ARM : les Cortex-A12 et Mali-T622 pour renouveler l'offre de milieu de gamme

ARM : les Cortex-A12 et Mali-T622 pour renouveler l’offre de milieu de gamme

Paré pour le Galaxy S6 Mini !

Avatar de l'auteur
David Legrand

Publié dans

Sciences et espace

05/06/2013 3 minutes
10

ARM : les Cortex-A12 et Mali-T622 pour renouveler l'offre de milieu de gamme

ARM n'a pas annoncé que le Mali V-500 pendant le Computex. Il a aussi été question d'un CPU et d'un GPU, les Cortex A-12 et Mali-T622, qui visent le segment du milieu de gamme et annoncent disposer d'un meilleur rendement énergétique. De quoi équiper les smartphones qui arriveront sur le marché d'ici 2014 / 2015.

Après les très populaires Cortex-A9, que l'on retrouve encore dans de très nombreux SoC comme les Exynos 4, chez Samsung, les Tegra 3 et 4i chez NVIDIA, ou le RK3066 chez RockChip, ARM vient de dévoiler leur remplaçant : le Cortex-A12. Cette nouvelle génération est annoncée comme 40 % plus performante, mais elle se placera tout de même sous les Cortex-A15. La finesse de gravure des puces passera à 28 nm contre 40 nm précédemment.

CPU Cortex-A12 : consommation en baisse, big.LITTLE possible

ARM Cortex-A12

 

L'un des points intéressants est que ce CPU s'avère compatible avec la technologie big.LITTLE. Pour rappel, cette dernière permet de faire fonctionner deux architectures différentes au sein d'une même puce tant qu'elles s'appuient sur le même jeu d'instruction (ARMv7 en l'occurrence). L'une gère les tâches basiques et consomme peu alors que l'autre intervient lorsque le besoin de puissance se fait ressentir. Actuellement, il est possible de mixer du Cortex-A7 et A15, mais l'on pourra désormais mélanger Cortex-A7 et A12. Il sera intéressant de voir les résultats dans la pratique.

 

Orientée pour le milieu de gamme, cette solution n'en est pas moins complète. Son architecture est de type OoO, la gestion de la virtualisation et de TrustZone sont de la partie, et l'on retrouve un contrôleur mémoire capable d'adresser jusqu'à 1 To (LPAE) comme les Cortex-A53 / A57 pensés pour les serveurs. Un à quatre cœurs pourront être présents, mais il faudra au final être patient puisque l'on ne devrait rien voir sur le marché avant la fin 2014 ou le début 2015 selon nos confrères d'Anandtech.

Mali-T622 : un nouveau GPU nettement moins gourmand

Mali-T622

 

En outre, la société anglaise développe aussi ses propres GPU et indique qu'elle vient d'ajouter le Mali-T622 à sa gamme. Il est annoncé comme 50 % plus efficace en terme de gestion de l'énergie que le Mali-T604 que l'on retrouve par exemple au sein de l'Exynos 5 Dual de la Nexus 10 ou du Chromebook de Samsung. Moins performant que les T624 et T628, il sera par contre plus accessible et vise donc lui aussi les futurs smartphones de milieu de gamme.

 

Le support de l'OpenGL ES 3.0 est de la partie, tout comme DirectX 11 et OpenCL 1.1.  Reste à voir si cela suffira à convaincre les constructeurs. En effet, sur la dernière génération de puces disponibles sur le marché, on retrouve plutôt des Adreno 300 chez Qualcomm ou du PowerVR de ST Microelectronics (Exynos Octa chez Samsung, Atom Z2760 d'Intel, ...).

Écrit par David Legrand

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

CPU Cortex-A12 : consommation en baisse, big.LITTLE possible

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Fermer

Commentaires (10)


DDReaper
Le 05/06/2013 à 20h 26

Le galaxy S5 avec 12 coeur (4A7,4A12,4*A15) <img data-src=" />


levhieu
Le 06/06/2013 à 09h 04

Question aux INPACTicients en (bon) rapport avec ARM:



Quel est l’intérêt du big.little avec un A12 si il consomme vraiment moins qu’un A15?



On pourrait pas, en cas d’activitté réduite, se contenter de jouer avec la fréquence (si jamais c’est possible) ou bien de ne garder actif que le ou les cœurs suffisant à la charge et d’arrêter les autres ?








levhieu a écrit :



Question aux INPACTicients en (bon) rapport avec ARM:



Quel est l’intérêt du big.little avec un A12 si il consomme vraiment moins qu’un A15?





Heu… c’est moi ou j’ai l’impression que la réponse est dans la question ? <img data-src=" />

Un big.LITTLE A12/A7 consommera moins qu’un A15/A7, mais sera aussi moins puissant. Question de positionnement de gamme, ni plus ni moins.







levhieu a écrit :



On pourrait pas, en cas d’activitté réduite, se contenter de jouer avec la fréquence (si jamais c’est possible) ou bien de ne garder actif que le ou les cœurs suffisant à la charge et d’arrêter les autres ?







Le changement de fréquence INpacte moins que le changement d’architecture sur le rapport perfs/conso.



Le big.LITTLE permet de basculer sur une archi faite et pensée pour la basse conso en cas de faible charge, et ensuite basculer sur une archi faite et pensée pour les perfs en cas de forte charge.



Hélas, pour l’INstant, une archi orientée perfs aurait un rendement totalement pourri à très faible fréquence (OoO, pipeline long, etc…), donc ce n’est pas INtéressant, en terme de rapport perfs/conso, de faire tourner trop bas en fréquence un A15 par exemple.



levhieu
Le 06/06/2013 à 11h 40







levhieu a écrit :



Question aux INPACTicients en (bon) rapport avec ARM:

Quel est l’intérêt du big.little avec un A12 si il consomme vraiment moins qu’un A15?

/quote]

[quote:4615084:lolomatic]

Heu… c’est moi ou j’ai l’impression que la réponse est dans la question ? <img data-src=" />

Un big.LITTLE A12/A7 consommera moins qu’un A15/A7, mais sera aussi moins puissant. Question de positionnement de gamme, ni plus ni moins.







Non, la réponse n’est pas dans la question, mais on peut dire que ma question nétait pas claire. J’essaye d’être plus explicite: On nous annonce un A12 qui consomme beaucoup moins qu’un A15. Je demande donc si la consommation du-dit A12 est tant que ça au dessus de celle de l’A7 ?







levhieu a écrit :



On pourrait pas, en cas d’activitté réduite, se contenter de jouer avec la fréquence (si jamais c’est possible) ou bien de ne garder actif que le ou les cœurs suffisant à la charge et d’arrêter les autres ?











lolomatic a écrit :



Le changement de fréquence INpacte moins que le changement d’architecture sur le rapport perfs/conso.



Le big.LITTLE permet de basculer sur une archi faite et pensée pour la basse conso en cas de faible charge, et ensuite basculer sur une archi faite et pensée pour les perfs en cas de forte charge.



Hélas, pour l’INstant, une archi orientée perfs aurait un rendement totalement pourri à très faible fréquence (OoO, pipeline long, etc…), donc ce n’est pas INtéressant, en terme de rapport perfs/conso, de faire tourner trop bas en fréquence un A15 par exemple.







Merci de cette réponse. C’est clair, net et précis (me coucherai moins bête aujourd’hui).



Toutefois à la relecture je constate que ça ne réponds qu’à une de mes 2 «propositions».

Reste à traiter (des volontaires?) le cas de l’arrêt de cœur(s) en cas de baisse de charge de travail.









levhieu a écrit :



Non, la réponse n’est pas dans la question, mais on peut dire que ma question nétait pas claire. J’essaye d’être plus explicite: On nous annonce un A12 qui consomme beaucoup moins qu’un A15. Je demande donc si la consommation du-dit A12 est tant que ça au dessus de celle de l’A7 ?







Ha d’accord, je comprends mieux la question.

L’A12 étant, pour catégoriser grossièrement, une archi orientée perfs, il aura fatalement une différence significative de consommation, à fréquence égale à un A7.

Ensuite, je suppose que c’est aux constructeurs d’avoir une certaine cohérence dans leur conception, en mettant un A7 faiblement cadencé en tandem avec un A12 dans un SoC ; puis un A7 plus fortement cadencé avec un A15 dans un SoC positionné dans la gamme supérieure.



J’avoue que j’apprécierais moi-même des démonstrations (davantage) chiffrées de ces théories sur les consos, mais ce genre de démonstrations ne court pas le net.







levhieu a écrit :



Merci de cette réponse. C’est clair, net et précis (me coucherai moins bête aujourd’hui).



Toutefois à la relecture je constate que ça ne réponds qu’à une de mes 2 «propositions».

Reste à traiter (des volontaires?) le cas de l’arrêt de cœur(s) en cas de baisse de charge de travail.







Ha, je vois que tu as remarqué mon (pas si) habile bottage en touche sur cette question ? <img data-src=" />

J’avoue manquer d’éléments de réponse sur ces aspects.

A ma modeste connaissance, il est techniquement possible d’activer indépendamment les coeurs d’une architecture big.LITTLE, mais ça engendre des complications/situations délicates à gérer :

Avec un big.LITTLE A7/A15 en 4*4, tels que les derniers Exynos de Samsung, sous Linux, la fréquence de l’A7 est augmentée en fonction de la charge jusqu’au maximum, puis l’A15 prend le relais si la charge augmente, et les fréquences de l’A15 évoluent à leur tour.

Le passage est transparent et rapide pour l’OS.



Si on est dans le cas de figure, à priori pas impossible techniquement, où les deux A7 et A15 sont activés, on est plus dans un SMP (Symetrical Multi Processing) que l’OS sait gérer. En effet, les noyaux actuels (courants, du moins) ont un scheduler qui répartissent les tâches indépendamment de la nature du core qui les exécute.



Je ne sais pas ce qui se fait actuellement en support AMP (Asymetrical Multi Processing), ou si le noyau Linux sait le gérer.



Concernant l’activation ou non indépendante de cores, j’ignore aussi quelles limitations rendent peu courante (impossible ?) la pratique.



fausse manip…


levhieu
Le 06/06/2013 à 14h 47







lolomatic a écrit :



…conversation…







Intéressante remarque sur la cohérence des décisions au moment du choix des modèles de CPUs.



En ce qui concerne le choix de faire du big.LITTLE plutôt que d’arrêter des cœurs au vol, deux élèments qui comptent (et que mon esprit de l’escalier me souffle tardivement):




  • ARM déclare qu’ajouter un cœur A7 n’augmente pas beaucoup la surface consommée quand on a déjà un cœur A15.

  • Côté logiciel, l’utilisation du big.LITTLE est «facile», parce que les passages A1[25] A7 peuvent être gérés comme: je sauvegarde un contexte, j’écris quelques valeurs bien choisies dans un/des registres du SoC, et voilà. Alors que qu’éteindre/allumer des cœurs dynamiquement nécessite que la gestion des threads de l’OS en tienne compte.









levhieu a écrit :



Intéressante remarque sur la cohérence des décisions au moment du choix des modèles de CPUs.



En ce qui concerne le choix de faire du big.LITTLE plutôt que d’arrêter des cœurs au vol, deux élèments qui comptent (et que mon esprit de l’escalier me souffle tardivement):




  • ARM déclare qu’ajouter un cœur A7 n’augmente pas beaucoup la surface consommée quand on a déjà un cœur A15.

  • Côté logiciel, l’utilisation du big.LITTLE est «facile», parce que les passages A1[25] A7 peuvent être gérés comme: je sauvegarde un contexte, j’écris quelques valeurs bien choisies dans un/des registres du SoC, et voilà. Alors que qu’éteindre/allumer des cœurs dynamiquement nécessite que la gestion des threads de l’OS en tienne compte.







    Comme d’habitude alors, le nerf de la guerre, ça reste le soft <img data-src=" />

    Effectivement, on se rend compte que la solution a l’élégance de s’adapter parfaitement aux principaux OS/noyaux existants.



    Il y a bien un cas particulier que j’ai oublié : le Tegra 3 et 4 avec leur core compagnon. Il ne fonctionne pas en 44 mais en 41 (oui, ou 1*4). J’imagine que ça doit être plus tendu, car là il y a bien diminution/augmentation de cores en cours de vol.



    Je serais curieux d’en savoir plus sur tout ça.



levhieu
Le 06/06/2013 à 16h 01







lolomatic a écrit :



Comme d’habitude alors, le nerf de la guerre, ça reste le soft <img data-src=" />

Effectivement, on se rend compte que la solution a l’élégance de s’adapter parfaitement aux principaux OS/noyaux existants.



Il y a bien un cas particulier que j’ai oublié : le Tegra 3 et 4 avec leur core compagnon. Il ne fonctionne pas en 44 mais en 41 (oui, ou 1*4). J’imagine que ça doit être plus tendu, car là il y a bien diminution/augmentation de cores en cours de vol.



Je serais curieux d’en savoir plus sur tout ça.







Je vais me renseigner pour le Tegra…



levhieu
Le 07/06/2013 à 10h 09







levhieu a écrit :



Je vais me renseigner pour le Tegra…







Pour le Tegra, le core companion est attaché au cœur 0, uniquement.

Donc, si l’OS sait arrêter des cœurs sélectivement (comme Linux sait le faire par exemple), il ne reste plus qu’à décider ensuite de basculer le cœur 0 entre «principal» et companion.