Depuis la fin du mois d’octobre, Google a publié sur son site Internet une annonce concernant un (ou plusieurs) poste d’ingénieur spécialisé dans la conception de puces multimédia. On pensait alors à un coprocesseur dédié aux tâches multimédias, comme un ISP (Image Signal Processor) en charge de traiter le flux provenant du capteur du téléphone. Finalement, il semblerait que Google souhaite aller plus loin, en concevant ses propres puces mobiles, à l’image d’Apple.
Une puce conçue en interne de A à Z ?
Google serait actuellement à la recherche d’un partenaire pour co-développé au moins une puce mobile. Mais peu de détails ont encore filtré même si beaucoup pensent que la stratégie sera similaire à celle employée par Apple : concevoir ses propres puces (et ses propres cœurs processeur) puis les faire fabriquer par un fondeur. Sur le court terme, une autre stratégie semble toutefois plus probable : faire appel à des cœurs existants comme les Cortex d’ARM pour créer une puce unique, pas encore disponible sur le marché.
Google pourrait ensuite intégrer au SoC des composants différenciants, à l’image d’un coprocesseur destiné à traiter le flux des capteurs afin de tirer parti du nouveau Android Sensor Hub, comme Apple avec ses puces M ou Huawei qui a intégré le i5 a son dernier Kirin 950. Sur le long terme, il semble pourtant évident que Google souhaite développer de A à Z son SoC mobile, mais cela demandera énormément de temps et de compétences.
Une puce unique pour éviter la fragmentation
Une puce conçue par Google permettrait d’éviter quelque peu la fragmentation des différents composants dans l’écosystème Android puisque certains pensent que Google pourrait obliger les constructeurs à utiliser son propre processeur sur la gamme Nexus par exemple. À la base, Google souhaite développer sa propre puce pour l’intégrer au sein d’un appareil productif. On imagine que l’idée était donc de pouvoir l’utiliser pour la tablette Pixel C dévoilée au mois de septembre dernier. Il faudra encore attendre un peu avant de voir cette puce se concrétiser : pour les Nexus de l’année prochaine ?
Pour ne rater aucun bon plan, rejoignez notre nouveau channel WhatsApp Frandroid Bons Plans, garanti sans spam !
Qui le fait ? Juste savoir ^^
Oki merci pour ces détails.
Sur le pixel phone si il y en a un!
Redondance "concevoir le processeur en interne et le faire concevoir par un fondeur"
Pour ça que ART à vue le jour. Maintenant le bytecode java est transformé en instructions CPU à l'installation. Du coup, niveau performances, Android n'est plus un problème.
Ben si un liveCD peut le faire, les ingénieurs en charge du déploiement OTA peuvent très bien le faire (ce qui est déjà le cas).
:-) je tape pas... Sauf les fesses des demoiselles quand elles le demandent Disons qu'Apple intégrera plus tardivement les fonctions qui font vieillir... Ça a été le cas avec le multitâche sur iOS 7
iOS ne gère pas mieux mais les couches d'Android sont plus nombreuses (dont la machine virtuelle) pour lui permettre de fonctionner sur une multitude de smartphone ce qui alourdit et demande plus qu'iOS et son implémentation plus profonde. Google ne chercherait-il pas à améliorer cela ?
Si l'installation est faites intelligemment pourquoi pas, mais comment remplacer le LiveCD lors des mise à jour OTA ?
Cette optimisation est surévaluée... J'explique sur un autre commentaire que matériellement du fait des ipc différentes, tu peux multiplier les fréquences des cœurs Apple (depuis apple A7) par 2 avant de les comparer aux cœurs Android... Une fois cette multiplication faite, tu cernes un peu mieux le potentiel de leurs puces... Mais du coup, affirmer que l'OS est mieux optimisé devient plus difficile.
Yes! D'où l'idée de créer des protocoles qui permettraient de conserver les modules lors d'une mise à jour système... C'était le cas pour certains modules sous Android 4.0, tu prenais un éditeur hexadécimal, tu modifiais le numéro de kernel du module et il étais reparti pour un tour... Pour d'autres, ça ne fonctionnait pas Sur certaines rom Android 4.0, tu fouillais un peu, tu arrivais à retrouver les modules caméra ou ton touch-screen... Maintenant tu retrouves que dalle.
Comme je le dis souvent iOS ne gère pas mieux ses coeurs qu'Android, ce sont les cœurs qui sont devenus surpuissants depuis apple A7 et le système qui était castré avant iOS 7, on voit ce que sont devenus les iPhone 4 et 4s depuis cette mise à jour : pas meilleurs que les appareils Android de la même époque qui disposaient déjà d'un vrai multitâche... Le dual-core Cortex A9 d'Apple A5 marche même plutôt moins bien que des cœurs identiques fonctionnant sous Android. C'est simple, les cœurs apple gérant 6 instructions par cycles d'horloge contre 3 pour la plupart des cœurs Android haut de gamme (2 pour les cœurs basse consommation), matériellement tu peux multiplier leur fréquence par 2... Un coeur Apple Cyclone à 1.3ghz gèrera autant d'instructions par secondes qu'un cortex A57 à 2.6ghz (les plus rapides tournent à 2.1ghz sur l'exynos, il me semble). Le raisonnement Moins de cœurs, fréquence inférieur, machine plus rapide=OS mieux optimisé est donc potentiellement faux. De plus linux est stable... Il manque certes un certains nombre de pilotes. Ce que je critique c'est par exemple sur une vieille allwinner A10, puce pas terrible, mais avec un décodeur vidéo exceptionnel pour l'époque (CedarX de son ptit nom), le passage d'Android 4.0 à 4.1 a rendu ce décodeur inutilisable sans réécriture de son module. Ce qui est souhaitable, c'est que tu puisses changer ton system.img sans avoir à modifier ton kernel.img et tes modules .ko... Ainsi les corrections de failles système seraient disponibles simultanement sur tous les appareils...
Les modules ajoutés inutilement sont inactif, et ne consomme que de la RAM (soit rien du tout, vue la nombre de RAM que l'on a). De plus dans le cas de ubuntu, tout les modules sont chargés dans le liveCD, mais il n'installe que les modules nécessaire. Ce qui est tout à fait faisable avec Android. Mais le gros problème avec les processeurs de smartphone c'est qu'ils sont trop récent, et change trop vite, pour que des alternatives open source des drivers soient viable. Google ne peux pas donc pas adapter les drivers, et les constructeurs des soc, prennent leur temps.
Vue la relativement bonne conception des acteurs déjà en place, je ne vois pas très bien pourquoi google développerait en interne sa propre puce. A moins que ce soit pour des projets très particuliers, comme le projet tango, mais surtout pour le projet Area
Une énorme erreur, déjà que leur telephones sont une catastrophe de pauvreté... comment prendre la vision pitoyable de l'appoule à contre sens.
Oui mais un OS qui intègre les drivers de multiples processeurs pour le rendre facilement installable le rend moins stable non ? Une Centos installée pour un matériel propre reste stable à long terme et a l'avantage de mieux gérer les performances. On en revient à l'avantage d'Apple avec ses processeurs mieux gérés et qui arrivent à concurrencer des Exynos 8 coeurs. Bon je banalise peut-être car je ne suis pas un expert :)
Concernant la fragmentation, cette puce Google aurait à mon avis un effet contre-productif... On voit bien que l'intégration de puce Qualcomm sur l'immense majorité des nexus conduit à fragmenter les mises à jour...kirin, mediatek, exynos, Intel, broadcom sont mis à jour moins rapidement. Cette puce créerait un exclu de l'aide Google en plus : Qualcomm. Par principe, je suis contre l'uniformisation et par conséquent peu réjoui par la nouvelle. Si Google veut lutter contre le fragmentation, il y a 2 pistes : - offrir un support à tous les fabricants de puces - établir des protocoles fixes dans le temps qui permettent à un noyau qui les respecterait de supporter plusieurs mises à jour sans avoir à être réécrit...bref un système qui se mettrait à jour sans forcément que le noyau ait à le faire. Quand tu installes une nouvelle versions ubuntu sur ton PC, elle s'installe quel que soit ton PC. Non? Pourquoi Android ne fonctionnerait pas ainsi ? J'ai l'impression qu'Android prends exactement le chemin inverse... Là où quand tu tapais lsmod sur ton terminal sous Android 4.0, tu avais un joli listing de modules, sous lollipop, tu n'as plus grand chose. Google semble rendre les mises à jour de plus en plus complexes à réaliser pour se plaindre ensuite que les constructeurs ne les fassent pas. Créer une puce en plus et prétendre que c'est pour lutter contre la fragmentation, c'est complètement contradictoire.
"co-développer" et non "co-développé"...
Ce contenu est bloqué car vous n'avez pas accepté les cookies et autres traceurs. Ce contenu est fourni par Disqus.
Pour pouvoir le visualiser, vous devez accepter l'usage étant opéré par Disqus avec vos données qui pourront être utilisées pour les finalités suivantes : vous permettre de visualiser et de partager des contenus avec des médias sociaux, favoriser le développement et l'amélioration des produits d'Humanoid et de ses partenaires, vous afficher des publicités personnalisées par rapport à votre profil et activité, vous définir un profil publicitaire personnalisé, mesurer la performance des publicités et du contenu de ce site et mesurer l'audience de ce site (en savoir plus)
En cliquant sur « J’accepte tout », vous consentez aux finalités susmentionnées pour l’ensemble des cookies et autres traceurs déposés par Humanoid et ses partenaires.
Vous gardez la possibilité de retirer votre consentement à tout moment. Pour plus d’informations, nous vous invitons à prendre connaissance de notre Politique cookies.
Gérer mes choix