Si les lecteurs de LinuxFr.org sont généralement bien au fait de l'état de prise en charge des puces graphiques de leur PC (Intel HD Graphics, AMD Radeon, NVIDIA GeForce) par les pilotes libres, il n'en est pas toujours de même s'agissant de la prise en charge des puces graphiques embarquées dans les SoC (« System on Chip », système sur puce, contenant en général processeur, mémoire, stockage et périphériques).
Or ces SoC, principalement basés sur l'architecture ARM actuellement. sont devenus omniprésents depuis l’avènement des ordiphones et des tablettes, et le problème de l'existence ou non de pilotes libres devient de plus en plus aigu, spécialement si on souhaite pouvoir tourner une distribution GNU/Linux sur ces engins sans s'embêter.
Sommaire
Panorama
Les SoC embarquent généralement l'une des puces graphiques suivantes :
PowerVR Series 5 (SGX) d'Imagination
Les PowerVR Series 5 (SGX) sont conçus par Imagination qui est réputé pour ne pas être enclin à l'ouverture (c'est un euphémisme) : ni spécifications ni pilotes libres.
Ces cœurs graphiques se retrouvent notamment dans les SoC TI OMAP 3 et 4 qui équipent respectivement les carte Beagleboard et PandaBoard mais aussi en combinaison avec des processeurs x86 Atom dans certains chipsets Intel. À noter que les puces PowerVR équipent les iPhone d'Apple et sont donc largement répandues.
Compte tenu de l'architecture alambiquée de la puce, il est peu probable qu'un pilote libre voie le jour et ce, malgré le souhait de la FSF.
VideoCore de Broadcom
Le VideoCore est conçu par Broadcom.
Il équipe le SoC ARM du Rapsberry Pi par exemple.
Malgré l'annonce qui en a été faite, Broadcom ne propose pas de pilote libre. Cependant, et malgré l'architecture alambiquée de la puce, une initiative de pilote libre est actuellement menée par Herman H Hermitage : videocoreiv. Le projet en est à ses débuts (initialisation du cœur).
GeForce ULP (Tegra) de NVIDIA
Le GeForce ULP (pour Ultra Low Power) est conçu par NVIDIA dont il équipe les SoC ARM Tegra.
On retrouve le Tegra dans de nombreux appareils comme Samsung Galaxy Tab 10.1, Microsoft Surface, Nexus 7, Ouya…
Un pilote libre 2D/3D est en cours de développement par rétro-ingénierie à l'initiative de Erik Faye-Lund alias kusma (site web) et, exceptionnellement, avec l'aide de NVIDIA : grate.
Mali d'ARM
Les cœurs graphiques Mali sont conçus par ARM sur la base d'une technologie brevetée initialement développée et licenciée par Mediatek.
Ils se retrouvent dans certains SoC Exynos de Samsung (appareils Samsung Galaxy S II, Samsung Galaxy Note 10.1, Samsung Galaxy Note 8.0, cartes Hardkernel O-DROID…), les A1X de AllWinner Technology (tablettes à bas prix type Carrefour CMP4708T mais aussi carte Cubieboard…), certains SoC WonderMedia de VIA, certains SoC AMLogic ou Rockchip.
ARM n'a pas réalisé de pilote libre, mais un pilote 2D/3D libre Gallium3D est activement développé, pour les modèles Mali 200 et Mali 400 pour commencer, par rétro-ingénierie sous l’impulsion de la société Codethink (au sein de laquelle principalement Luc Verhaegen alias libv – blogue) depuis début 2011 et est bien avancé : Lima. Les résultats sont encourageants et le pilote libre peut s'avérer plus rapide que son pendant non-libre au final.
Adreno de Qualcomm
Adreno est conçu par Qualcomm dont il équipe les SoC ARM Snapdragon. Pour l'anecdote, la partie 3D est dérivée des puces Radeon d'AMD (dont Adreno est un anagramme).
On retrouve le Snapdragon dans de nombreux appareils comme HTC Legend, HTC Desire, Nexus One, HP TouchPad, Sony Xperia E/T/J/Z, Nexus 4, Nokia Lumia 520/620/720/820/920, Samsung Galaxy S4…
Qualcomm n'a pas réalisé de pilote libre, mais un pilote 2D/3D libre Gallium3D est activement développé par rétro-ingénierie notamment par Rob Clark (blogue), développeur actuellement chez Red Hat et précédemment chez Texas Instrument, sur son temps libre : freedreno. Le projet semble bien avancer et concerne tant les a2xx que les a3xx.
Vivante de Vivante Corp
Le cœur graphique Vivante est conçu par Vivante Corp.
Il est largement répandu et se retrouve par exemple dans de nombreux SoC Marvell (Cubox…), la série i.MX6 de Freescale ou le Rockchip RK2918.
Vivante Corp a publié un pilote libre partiel (la partie noyau seulement, sous licence GPL, mais rien concernant le pilote en espace utilisateur) qui est actuellement complété à l'initiative de Wladimir J. van der Laan (blogue) qui travaille sur un pilote Gallium3D : etna_viv. Le travail pour les GC600/800 semble bien avancer, et celui sur GC880 ne serait pas loin. Le travail sur GC2000 viendrait plus tard.
À venir : HD Graphics (Valley View) d'Intel
Vous aurez remarqué que ce panorama de SoC est jusqu'ici très largement dominé par l'architecture ARM – ce qui n'est pas une nouveauté, Intel s'étant engagé tardivement dans la course à la consommation électrique.
Intel a fini par annoncer Valley View, un SoC à base de processeur Atom (architecture x86) qui utilisera pour la première fois une solution graphique propre puisqu'il s'agira d'un cœur HD Graphics de septième génération (la même que celle que l'on trouve dans les actuels processeurs Ivy Bridge et les futurs Haswell) pour lequel le fondeur fournit directement un pilote libre.
La date de sortie de ce SoC n'est toutefois pas connue à ce jour.
Remarques finales
Quel cœur graphique privilégier dans l'optique d'un pilote libre ? Les quatre prétendants (bientôt cinq)
Si les cœurs graphiques PowerVR d'Imagination sont à fuir comme la peste, les GeForce ULP (Tegra), Mali (200/400), Adreno et Vivante sont à privilégier pour qui espère un pilote libre à court ou moyen terme (Adreno semblant faire la course en tête). Il n'est pas interdit d'imaginer un jour un pilote libre pour les VideoCore, mais l'architecture alambiquée de la puce – tout comme celle des PowerVR – incite à la prudence.
Enfin, une fois le SoC Valley View d'Intel sorti, on pourra l'ajouter à la liste qui totalisera ainsi cinq prétendants.
Pilote libre : merci qui ?
Il est regrettable de constater qu'à de rares exceptions près (Intel et, dans une moindre mesure, NVIDIA et Vivante Corp), les concepteurs de solutions graphiques pour SoC refusent (pour l'instant ?) de jouer le jeu de l'Open Source en libérant leurs pilotes ou, au moins, en publiant les spécifications de leur matériel (toutefois certains concepteurs peuvent ne pas avoir tous les droits sur leur technologie compte tenu des brevets tiers qu'ils peuvent exploiter sous licence).
Les pilotes libres en cours de développement le sont donc par des tiers qui pratiquent la rétro-ingénierie : sacrée perte de temps (cela dit, la lecture des brevets sur le matériel a parfois pu faire office de documentation en permettant aux développeurs de progresser dans leur travail de compréhension des mécanismes mis en œuvre par le matériel…).
Et encore : les développeurs compétents dans ce domaine étant déjà employés par des sociétés travaillant sur certaines de ces solutions graphiques sous accord de non-divulgation, ils ne peuvent écrire du code pour des pilotes libres concernant ces matériels. Du coup on assiste à un jeu de participations croisées : Luc Verhaegen alias libv et Rob Clark ne pouvant coder sur PowerVR, le premier se rabat alors sur Mali, lequel Rob Clark ainsi que Erik Faye-Lund alias kusma ne pouvant de leur côté coder sur Mali, se rabattent respectivement sur Adreno et Tegra…
Aller plus loin
- Open source drivers for SoC GPUs - Emmanuel Deloget (176 clics)
- The SoC GPU driver interview - Emmanuel Deloget (131 clics)
# wouhouuuu
Posté par deasy . Évalué à 4.
Je trouvrais que l'article sur le noyau 3.9 manquait d'infos comparativement aux autres, voilà qui ajoute des infos même si c'est indirect!
Je propose un nouvel article: l'état du support des SoC ARM.
[^] # Re: wouhouuuu
Posté par antistress (site web personnel) . Évalué à 5. Dernière modification le 04 mai 2013 à 12:28.
Je suis d'accord, la dépêche sur le noyau Linux 3.9 n'était pas folichonne : manque de nouveautés j'ai trouvé (d'ailleurs j'ai dû modifier la structure de la dépêche par rapport aux précédentes car j'ai trouvé qu'il n'y avait pas de quoi faire une vraie partie sur les nouveautés), le fait que je manque malheureusement de compétence pour comprendre certaines choses du noyau et en parler, et puis patrick_g qui nous délectait d'anecdotes…
J'en profite pour passer un message : j'ai passé la main pour la prochaine dépêche (Linux 3.10) car j'ai des examens à préparer à cette date, avis aux amateurs !
# Bravo
Posté par patrick_g (site web personnel) . Évalué à 9.
Superbe dépêche. Merci antistress et merci aussi à Emmanuel Deloget pour sa méga-interview (second lien de la news) qui apporte des tonnes d'infos.
[^] # Re: Bravo
Posté par antistress (site web personnel) . Évalué à 3.
merci :-)
[^] # Re: Bravo
Posté par Nÿco (site web personnel) . Évalué à 3.
Le maître congratule le padawan… snif, c'est beau ! Mais tu vas faire aussi des padawans ! ;-)
# On part de loin...
Posté par Meku (site web personnel) . Évalué à 7.
Eh ben, on a l'impression de repartir de zéro dans le domaine des pilotes graphiques… C'est un peu triste quelque part.
Du coup je me demandais, tous ces constructeurs qui ne veulent ni publier de spec, ni fournir de pilote pour Linux, pour quel(s) OS ils distribuent leurs pilotes alors ?
[^] # Re: On part de loin...
Posté par Anonyme . Évalué à 4.
Vu l'article, il s'agit de pilotes pour des appareils sous Android, et donc Linux. Il faut juste différencier pilote libre et « blob », qui est un pilote fournit en temps que binaire. Maintenant il y a peut-être une autre façon : le code du pilote est fourni à qui achète le matériel (par contrat quoi), avec l'impossibilité de le diffuser.
[^] # Re: On part de loin...
Posté par antistress (site web personnel) . Évalué à 4.
Il ne veulent/peuvent pas distribuer de pilote libre
[^] # Re: On part de loin...
Posté par karteum59 . Évalué à 2.
Au delà de la partie graphique des SoC (pour lesquels un palliatif sous-optimal serait peut-être d'écrire un wrapper entre un pseudo-driver X générique et le driver Android/SufaceFlinger fourni sous forme binaire. N.B. on me fait signe que Wayland tournerait désormais avec les drivers Android), un gros souci est que les fabricants de devices (notamment asiatiques) ne fournissent souvent ni le code-source du noyau Linux, ni le device-tree, ni les specs. Je suis en train de me battre avec un fabricant taiwanais de smartphones android pour tenter de récupérer les sources du noyau afin de faire un diff avec le kernel vanilla et recompiler un noyau plus récent… En l'absence d'ACPI, de device-tree, de fichiers mach-*/board-* et de specs, il n'est pas possible de recompiler un autre noyau et faire évoluer nos bébètes. On ne le voit pas tant que ça car en Europe les smartphones proviennent généralement de grands constructeurs pour lesquels les sources sont disponibles, mais je suis consterné de voir à quel points certains ODMs asiatiques font du "jetable".
[^] # Re: On part de loin...
Posté par Anonyme . Évalué à 2. Dernière modification le 06 mai 2013 à 19:05.
Le jetable c'est profitable. Pour une poignée de personnes qui se fout bien du reste du monde, tant qu'il achète.
[^] # Re: On part de loin...
Posté par cedric . Évalué à 2.
Ah la comprehension des licenses en Asie. Tout un programme ! Si c'est un mtk, peut etre que ce que tu trouveras sur : http://www.wikogeek.com/ pourra t'aider. J'ai pas encore regarde, mais enormement de telephone asiatique utilise cette puce et il n'y a quasiment jamais de difference au niveau hard entre ces telephones.
# Prise en charge des Tegra
Posté par Dreamkey . Évalué à 2.
Je copie-colle une question que j'avais posté sur la news du noyau 3.9 qui en parlait aussi.
D'après cette dépêche et celle sur les puces graphiques, la prise en charge s'améliore.
Donc est-ce que cela veut dire qu'à terme, cela remplacera efficacement le driver binaire de Nvidia ?
Dans mon cas, j'ai un LG Optimus 2X avec un Tegra 2. J'en suis très content, seulement le suivi de LG sur ses téléphones (alors que c'était son fer de lance, premier smartphone dual-core, Guiness Book…) est catastrophique. Il leur a fallu un an pour sortir Android 4.0 ; CyanogenMod l'avait déjà porté depuis longtemps, mais sans l'accélération matérielle impossible de lire et enregistrer des vidéos.
Dès que LG a sorti la 4.0.4, Cyanogen a sorti 2 jours plus tard la 4.1.X, et aujourd'hui je profite de la 4.2.2.
Donc ma principale inquiétude vient que si Google sort Android 5.0 (apparemment ils sont sur la 4.3 actuellement), mon téléphone n'en profitera jamais à cause d'un problème de driver, alors que sur le papier il sera encore dans la course.
[^] # Re: Prise en charge des Tegra
Posté par antistress (site web personnel) . Évalué à 3. Dernière modification le 04 mai 2013 à 12:33.
D'après ce que je lis, les 4 prétendants ont un design propre, on peut espérer (mais ça reste à voir) que les développeurs parviendront à produire un driver libre complet et performant (par exemple le développeur de Mali explique que toutes les optimisations sont prévues par la puce donc il n'y a pas besoin de bidouiller le pilote pour en tirer profit, il suffit que le pilote couvre bien les caractéristiques de la puce). Dans le même ordre d'idée, je crois aussi que les GeForce ULV n'ont de GeForce que le nom et que c'est une architecture spécifique (à vérifier).
[^] # Re: Prise en charge des Tegra
Posté par antistress (site web personnel) . Évalué à 4.
"L'architecture GeForce ULP est souvent décrite comme dérivée des GeForce 6/7, mais ce n'est pas correct. En réalité elle n'est dérivée d'aucune architecture GeForce précédente, celles-ci n'étant pas adaptées aux économies d'énergie" : Nvidia Tegra 4 et 4i : tout savoir de leur architecture (hardware.fr)
# Videocore et Beagleboard/Pandaboard
Posté par PaulK (site web personnel) . Évalué à 4.
Il s'agit d'une erreur: la Pandaboard a un SoC OMAP4 et la Beagleboard un SoC OMAP3 et non un SoC Broadcom avec Videocore, que seul le Raspberry Pi utilise.
De plus, le Raspberry Pi nécessite des composants non-libres (bootloaders et autres) pour démarrer la carte. Pire encore, c'est le Videocore qui est démarré le premier et qui va initialiser et passer la main au processeur ARM !
[^] # Re: Videocore et Beagleboard/Pandaboard
Posté par antistress (site web personnel) . Évalué à 2.
Ah en effet je vois que ces deux boards sont en PowerVR merci !
[^] # Re: Videocore et Beagleboard/Pandaboard
Posté par claudex . Évalué à 4.
Corrigé, merci.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Date du SoC Intel Valley View : fin 2013
Posté par antistress (site web personnel) . Évalué à 3.
Source : http://www.hardware.fr/news/13055/soc-atom-22nm-avances-fin-2013.html
[^] # Re: Date du SoC Intel Valley View : fin 2013
Posté par Aissen . Évalué à 2. Dernière modification le 07 mai 2013 à 15:06.
Haha, c’est assez comique, moi qui tablait sur une sortie fin 2012 (bon en même temps ma source c’était phoronix, ça m’apprendra):
https://linuxfr.org/users/aissen/journaux/attention-aux-derniers-intel-atom
Sinon, la grosse question c’est est-ce que Silvermont d’Intel va rester comme sur Saltwell sur du GPU PowerVR d’Imagination (qui risque d’être boudé par les fabricants de processeur depuis qu’ils ont racheté de MIPS Technologies), ou est-ce qu’ils vont passer sur une solution maison à la ValleyView:
http://www.realworldtech.com/silvermont/8/
http://www.extremetech.com/computing/155082-intels-silvermont-revealed-after-a-five-year-snooze-intel-is-finally-ready-to-crush-arm
Dans le second cas ça serait révolutionnaire, car on aurait dans des smartphones et tablettes une stack graphique 100% libre. À noter aussi, la frénésie d’embauche de développeurs graphique Linux d’Intel n’est peut-être pas un hasard…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.