URL: https://linuxfr.org/news/entretien-avec-jerome-glisse-developpeur-des-pilotes-graphiques-radeon-pour-red-hat
Title: Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat
Authors: antistress
remjg, glisse, Davy Defaud, Ontologia, feth, Pascal Terjan, patrick_g, rpnpif, Jarvis, Martin Peres, ʭ ☯ , Petit_Scarabee, djibb, palm123, Olivier Esver, Atacama, Benoît Sibaud, reno, Nicolas Casanova et Nonolapéro
Date: 2013-07-26T19:40:18+02:00
License: CC By-SA
Tags: entretien, glisse, radeon, amd, gallium3d, coulisses et red_hat
Score: 132
Nous avons la chance d’avoir quelques développeurs qui fréquentent _LinuxFr.org_ (_what else?_), dont Jérôme Glisse (alias [_glisse_](http://linuxfr.org/users/glisse)) qui travaille au sein de la société [Red Hat](http://fr.wikipedia.org/wiki/Red_Hat) sur le pilote graphique libre pour cartes graphiques ATI/AMD Radeon.
Pour cet entretien, j'ai invité les membres de _LinuxFr.org_ en [tribune de rédaction](http://linuxfr.org/redaction) (il faut être inscrit !) à venir compléter mon questionnaire avec leurs propres questions, et Jérôme a bien voulu se prêter au jeu : un grand merci à lui.
À noter que les hyperliens ont été ajoutés après coup par les contributeurs à cette dépêche pour en faciliter la lecture.
----
[Blogue de Jérôme Glisse](http://jglisse.livejournal.com/)
[Wiki officiel du projet radeon](http://www.x.org/wiki/radeon/)
[Page Wikipédia du projet radeon](http://fr.wikipedia.org/wiki/Radeon_%28logiciel%29)
[Page Wikipédia de la pile graphique Linux](http://fr.wikipedia.org/wiki/Pile_graphique_Linux)
----
**_1. Bonjour Jérôme, peux‐tu te présenter s’il te plaît ?_**
Bonjour, que dire : je travaille chez Red Hat sur tout ce qui touche aux cartes graphiques. Je suis impliqué dans le logiciel libre depuis plusieurs années : tout d'abord comme un hobby, puis de nos jours de manière professionnelle. J'aime [les croissants](http://www.bootsnall.com/articles/wp-content/uploads/2010/10/criossant.jpg), [les fraises](http://www.flickr.com/photos/lo275/3689930142/), [les chouquettes](http://www.flickr.com/photos/sifu_renka/4013640370/), [le couscous](http://upload.wikimedia.org/wikipedia/commons/f/f7/Moroccan_cuisine-Couscous_lamb_berber.jpg), la bonne bière et les bon vins ;). Que dire de plus ?
**_2. Comment définirais‐tu ton rapport au logiciel libre, et comment es‐tu entré en contact avec lui ?_**
J'ai toujours été curieux, je suis toujours curieux, je suis très fier d'avoir gardé ma curiosité d'enfant qui me pousse toujours à chercher à comprendre, découvrir... Je suis toujours triste de voir ô combien les adultes perdent trop souvent cette curiosité, se satisfont du parce-que-c'est-comme-ça. Naturellement on ne peut pas être expert en tout. Mais bon je reste optimiste, [[Wikipédia]] donne un second souffle à tous ceux qui sont intrigués par les choses qui les entourent.
Au delà de ma curiosité, c'est mon passé de [[demomaker]] qui m'a également conduit vers le libre. Un système d'exploitation dont on a les sources, je ne pouvais pas ignorer cela. Par la suite je me suis posé des questions sur le partage des connaissances, et je me suis donc rapproché de la philosophie du libre à laquelle je tiens beaucoup.
**_3. Qu’est‐ce qui t’a conduit à devenir développeur professionnel ?_**
Mon sens aigu de l'observation m'a conduit à réaliser que l'on pouvait obtenir des fraises ou de la bière contre de l'argent. Ce fut un tournant dans ma vie, il me fallait obtenir de l'argent pour parvenir à ces choses que j'aime.
Sinon dans la vraie vie, c'est tout simplement qu'il me fallait un travail et qu'à la fin de ma thèse je ne souhaitais pas continuer dans mon domaine (surtout que j'étais à contre-courant). J'ai énormément aimé le monde de la recherche, j'y ai énormément appris et me suis considérablement enrichi (au sens figuré, parce qu'au sens propre, c'est plutôt l'inverse ;)).
**_4. Tu travailles actuellement sur le pilote libre pour les cartes graphiques AMD Radeon (projet radeon), que faisais‐tu avant ?_**
Avant j'ai réalisé une thèse en biologie. Mais je n'ai pas débarqué comme ça dans le projet _radeon_, j'y contribue depuis fort longtemps, depuis le [reverse engineering](http://fr.wikipedia.org/wiki/R%C3%A9tro-ing%C3%A9nierie) des [R300](http://fr.wikipedia.org/wiki/Radeon_R300) (_aka_ Radeon 9600, Radeon 9800). Je suis simplement un touche-à-tout.
**_5. Quelles contributions as‐tu apportées au pilote radeon, sur quoi travailles‐tu maintenant, et sur quoi comptes‐tu travailler ?_**
Je vais essayer de remonter le temps avec ma mémoire. J'ai commencé par écrire le _driver_ [AGP](http://fr.wikipedia.org/wiki/Accelerated_Graphics_Port) pour les Apple G5 (PPC) avec l'aide de Benjamin Herrenschmidt, qui m'a tenu la main pour mes premiers [patchs](http://fr.wikipedia.org/wiki/Patch_%28informatique%29) [[kernel]] il y a de ça dix ans. J'avais effectivement un G5 à l'époque et je voulais faire marcher la radeon 9600 dessus. J'ai donc également travaillé sur le reverse engineering de la famille R300 (le plus gros de ce travail a été réalisé par Vladimir Dergachev, Nicolai Haehnle, Aapo Tahkola, et d'autres que j'oublie).
Une de mes contributions à cette époque qui m'a rendu « célèbre », c'est libsegfault (j'en garde un très bon souvenir). J'ai repris une idée présentée dans une release du magazine [[Phrack]], pour abuser du [segfault](http://fr.wikipedia.org/wiki/Erreur_de_segmentation) pour tracer un programme. L'idée est de se placer entre le programme et le _kernel_ (LD_PRELOAD), d'intercepter les appels système mmap, unmap et de placer un signal handler pour intercepter les segfaults. Sur le segment que l'on cherche à écouter on fait alors en sorte de changer le mapping pour provoquer un segfault. Dans le signal handler, on récupère ensuite l'adresse du code qui a levé le segfault, on décode l'instruction, on recupère l'adresse exacte (offset complet) ainsi que le type d'opération (écriture ou lecture).
Pour faire simple c'est le [[Valgrind]] du pauvre. Je ne me souviens plus pourquoi je n'ai pas utilisé Valgrind à l'époque mais je ne regrette pas, j'ai beaucoup appris. J'ai réalisé ce hack pour pouvoir voir ce que faisait le _driver_ X propriétaire sur un GPU particulier, les Radeon 9800. Effectivement, on finissait toujours par avoir un _lockup_ (voir ci dessous pour une explication) sur les Radeon 9800, mais on avait remarqué que si on chargeait en premier le _driver_ propriétaire, alors tout marchait correctement. Le _driver_ propriétaire devait par conséquent écrire un registre que nous n'écrivions pas. J'ai fini par trouver après une année (d'une partie de mon temps libre).
Un _lockup_ pour un GPU, ou de manière plus générale pour n'importe quel matériel, c'est lorsque le matériel se bloque. Pour faire une analogie, le matériel reste coincé dans une boucle d'une de ses fonctions. Plus un matériel est complexe, plus il peut y avoir de raisons pour qu'il se bloque. Sous Windows, cela donne souvent droit au _blue screen of death_. Les GPU sont les pires cas car c'est probablement le matériel le plus complexe qui existe dans un ordinateur. En effet, le GPU est quasiment un ordinateur à lui tout seul : il possède son propre contrôleur mémoire, ses propres unités de calcul, parfois sa propre mémoire.
Les _lockups_ sur GPU sont ainsi des plus variés, on peut identifier plusieurs grandes catégories. Le GPU essaie de lire ou d'écrire à une adresse invalide en mémoire (plusieurs raisons : le _driver_ à oublié d'éteindre un bloc du GPU, l'update de la pagetable du GPU n'a pas été fait correctement...). Le GPU fait face à des données qui provoquent un cas dégénéré (des sommets donnent un triangle mal formé ...). Le GPU rencontre un problème interne de synchronisation (par exemple un des blocs du GPU attend le signal d'un autre bloc mais ce signal est perdu par exemple parce qu'il est arrivé trop tôt).
Naïvement, on pourrait penser que tout cela est documenté, mais c'est très loin d'être le cas. Les GPU ont tellement de blocs (un bloc c'est par exemple le contrôleur mémoire, l'unité qui transforme un triangle en pixel, ou l'unité qui envoie les pixels à l'écran...) qui ont chacun énormément d'inter-connections que des problèmes non triviaux de propagation des signaux se posent. Au final, il est impossible de tester tous les cas lors du développement du GPU, beaucoup des bugs sont découverts seulement lorsque le GPU est finalement dans les mains des utilisateurs.
On pourrait également penser naïvement qu'il est simple de faire un _reset_ du GPU ou de le redémarrer, mais c'est loin d'être le cas. Idéalement, les nouvelles normes [PCIe](http://fr.wikipedia.org/wiki/PCI_Express) qui permettent un vrai _reset hard_ (comme lorsqu'on redémarre l'ordinateur) vont aider dans cette direction. Mais actuellement, il est possible pour un GPU (ou pour tout autre périphérique PCI/PCIe) de conduire le système à se bloquer complètement.
Et comme il y a une infinité de raisons pour un _lockup_, il n'y a pas, par conséquent, de recette à suivre pour les déboguer. Il s'agit de deviner ce qui peut mal tourner et surtout de trouver un cas qui permet de reproduire facilement le _lockup_ et de réduire ce cas au minimum possible.
Pour en revenir à mes contributions, pour la famille R300, j'ai touché un peu à tout, du _kernel_, au _driver_ X en passant par Mesa et libdrm (je suis le genre à coller mes doigts dans tous les pots de confitures, je ne peux pas m'en empêcher). J'ai acquis une vision globale de la pile graphique sous Linux. Après le R300, j'ai travaillé au reverse engineering de la famille R500 (la famille R400 étant très proche des R300, il y avait moins de travail). J'ai réalisé ce travail de reverse engineering avec Daniel Stone et Matthew Garrett, on a sorti ensemble le _driver_ [avivo](http://cgit.freedesktop.org/avivo/xf86-video-avivo/). (Pour ceux qui ont trop regardé Jurassic Park... J'ai dépensé sans compter !)
Alors que nous étions en train de travailler sur avivo, [AMD](http://fr.wikipedia.org/wiki/Advanced_Micro_Devices) et [[SUSE]] étaient en train de travailler sur [[radeonHD]] le nouvel effort open source impulsé par AMD. Cela a malheureusement conduit à une guerre larvée entre plusieurs personnes (avec moi au milieu en train de jouer innocemment).
À la même période, j'ai écrit un premier _driver_ [[Gallium3D]] pour R300, _driver_ qui sera ensuite réécrit par Corbin Simpson. Pour éviter de me retrouver sur le champ de bataille entre xf86-video-ati et xf86-video-radeonhd, je me suis orienté vers le [kernel modesetting](http://fr.wikipedia.org/wiki/Kernel-based_mode-setting) (KMS). J'avais participé au design de [DRI2](http://fr.wikipedia.org/wiki/Direct_rendering_infrastructure), conduit par [Kristian Høgsberg](https://archive.fosdem.org/2012/interview/kristian-hogsberg.html), et je ne voulais pas faire DRI2 sur l'ancien _driver_ noyau. J'ai donc écrit un premier _driver_ KMS pour Radeon, qui n'était vraiment pas terrible. Dave Airlie en a écrit un second, qui reprennait le modesetting du ddx alors que j'avais tout réécrit dans le mien. Dave voulait réutiliser les mêmes [ioctls](http://fr.wikipedia.org/wiki/Ioctl) (si mes souvenirs sont exacts) et je n'aimais pas cela. J'ai donc écrit un troisième _driver_ KMS, qui reprenait également le code modesetting du ddx (considéré comment possédant plusieurs [workarounds](http://fr.wikipedia.org/wiki/Workaround) accumulés au cours des années). Dans le même temps, j'ai corrigé et adapté au dernier noyau TTM (nécessaire pour _radeon_), j'ai également participé au design de [GEM](http://fr.wikipedia.org/wiki/Graphics_Execution_Manager). Enfin j'ai réalisé le design de l'ioctl pour soumettre les commandes (CS ioctl).
Toutes les pièces du puzzle étaient donc là, j'avais mon dernier code KMS pour Radeon, un code TTM que j'avais longuement débuggué, et une interface GEM qui me satisfaisait plus ou moins. Mon _driver_ KMS fut donc inclus dans le noyau, laissant le soin à Thomas Hellström de poster ma version débugguée de TTM. Le pilote _radeon_ devint ainsi le _driver_ noyau le plus gros (et il l'est toujours le bougre).
Pendant ce temps là, AMD avait écrit un _driver_ Mesa classique pour la génération [R600](http://fr.wikipedia.org/wiki/Radeon_R600), et qui plus est fonctionnant sans le KMS. Horreur ! Infamie ! Il me fallait laver l'affront, et donc écrire un _driver_ Gallium, et c'est ce que j'ai fait. J'ai écrit le _driver_ r600g pour les Radeon R600/[R700](http://fr.wikipedia.org/wiki/Radeon_R700), attirant très vite d'autres contributeurs.
La suite, c'est plein de contributions à droite, à gauche : texture/color tilling support (R600, R700, [Evergreen](http://fr.wikipedia.org/wiki/Radeon_R800), [Northern Islands](http://fr.wikipedia.org/wiki/Radeon_R900)), hyperz support (R600, R700, Evergreen, Northern Islands), texture/color tiling support ([Southern Islands](http://fr.wikipedia.org/wiki/Radeon_R1000)/[Sea Islands](http://fr.wikipedia.org/wiki/Radeon_R1100))... Dernièrement j'ai écrit un autre _driver_ X pour les Southern Islands, en utilisant le state tracker XA pour lequel j'ai réalisé plusieurs patchs. Ce travail n'a pas porté ses fruits dans le temps imparti, néanmoins mes patchs pour XA sont aujourd'hui utiles au projet [Freedreno](http://freedreno.github.io/) (Rob Clark).
Voilà, j'en oublie, j'ai des contributions à droite et à gauche dans des petits projets et des plus importantes, en fonction des bugs qui ont eu l'outrecuidance de se mettre sur ma route.
**_6. Concernant le projet radeon, comment se passe concrètement ton travail : au sein de Red Hat ; au sein de la communauté ?_**
Je suis assez libre chez Red Hat, mes grosses obligations concernent l'intégration du travail [upstream](http://en.wikipedia.org/wiki/Upstream_%28software_development%29) dans les _releases_ [RHEL](http://fr.wikipedia.org/wiki/Red_Hat_Enterprise_Linux). C'est tout un travail, souvent silencieux et invisible, qui implique beaucoup plus de personnes dans Red Hat qu'il n'y paraît. Il y a un gros travail d'assurance qualité, de vérification et d'audit, travail réalisé en collaboration avec plusieurs équipes.
Au sein de la communauté c'est un peu la métaphore de la cathédrale et du bazar. Chacun travaille plus ou moins sur ce qu'il veut et on essaye de communiquer suffisamment pour ne pas se marcher sur les pieds. Naturellement les personnes travaillant pour AMD font aujourd'hui beaucoup plus de contributions : ils ont accès au matériel et à la documentation bien avant moi. Souvent quand je leur pose une question, c'est plus simple pour eux de faire le patch que de me répondre.
**_7. Combien êtes‐vous à travailler sur cette partie ?_**
Je ne sais pas si j'aurais assez de doigts ! Parlons d'abord des bénévoles ! Nous avons donc Vadim Girlin, Vincent Lejeune, Sylvain Bertrand, ... (et d'autres que j'oublie, désolé). Il n'y a pas de petites contributions. Chez AMD, de visibles, ils sont cinq : Michel Dänzer, Alexander Deucher ([blog](http://www.botchco.com/agd5f/)), Christian König, Marek Olšák et Tom Stellard ([blog](http://www.stellard.net/tom/blog/)). Enfin, sur _radeon_, à Red Hat, nous sommes deux : Dave Airlie ([blog](http://airlied.livejournal.com/)) et moi. Alors avec l'aide de mes doigts de pieds, ça nous fait neuf personnes (oui je me suis emmêlé des doigts).
**_8. As‐tu une spécificité ou une façon de travailler inhabituelle ?_**
Je travaille avec mes deux mains, je ne sais pas si c'est inhabituel, sinon j'aime aussi beaucoup travailler sur papier ou sur un tableau. Poser mes idées à plat comme on dit. Bref je ne pense pas qu'il y ait grand chose d'inhabituel chez moi.
**_9. Déboguer les fréquents lockups doit prendre une large partie de ton temps, arrives-tu à aussi faire des choses intéressantes ?_**
Qui a bien pu poser cette question ? Je laisse le soin d'enquêter à d'autres. J'ai fini par avoir la réputation de spécialiste des _lockups_ suite à mon année passée à corriger mon premier _lockup_ sur Radeon 9800. Il peut m'arriver de passer plusieurs mois sur un _lockup_ et d'écrire beaucoup de code utile seulement pour débugger un cas précis. Il m'arrive aussi d'insulter copieusement et de maudire sur plusieurs générations les ingénieurs qui ont conçu le circuit. Dans tous les cas, je refuse de travailler uniquement sur un _lockup_ car c'est souvent très frustrant et très ingrat, je fais toujours quelque chose de plus intéressant en parallèle.
**_10. Échangez‐vous beaucoup avec les développeurs de Nouveau et des pilotes graphiques libres d’Intel ?_**
Oui nous partageons déjà énormément de code, notamment au travers de Mesa ou du code commun DRM dans le noyau. Par ailleurs, nous avons souvent les mêmes problèmes et donc nous cogitons souvent ensemble. C'est très agréable. Globalement, tous, quelque soit le GPU sur lequel nous travaillons, nous voulons améliorer la pile graphique Linux et par conséquent nous voyons toute coopération comme bénéfique.
**_11. Quels efforts AMD pourrait encore faire pour que les pilotes libres soient encore meilleurs ?_**
J'aimerais avoir accès aux informations plus tôt pour avoir un support au moment du lancement du GPU et pas après. J'aimerais aussi employer plus de personnes pour travailler sur le pilote libre... Mais il faut être réaliste, il y a dans l'équation le coût et le gain qui entrent en jeu. Malheureusement la taille des équipes entre le _driver_ open source et le _driver_ propriétaire est sans commune mesure (plusieurs centaines sur le _driver_ propriétaire).
M'envoyer visiter les îles qui servent de noms au GPU (Hawaii, Maui, Cayman ...) ?
**_12. Quel est l'intérêt pour AMD de développer des pilotes propriétaires ?_**
Pour les pilotes propriétaires c'est tout simplement de pouvoir supporter leur matériel sous Linux de manière satisfaisante pour leurs clients professionnels. Cela nécessite un _driver_ qui supporte toutes les fonctionnalités OpenGL mais aussi qui est certifié avec les gros logiciels ([[CATIA]], [Maya](http://fr.wikipedia.org/wiki/Maya_%28logiciel%29) ...). Si AMD voulait faire cela avec les _drivers_ libres il leur faudrait embaucher plusieurs centaines de personnes pour travailler sur le _driver_ libre (on ne peut pas partager les équipes entre le _driver_ propriétaire et le _driver_ libre). Il faudrait donc un investissement considérable pour AMD pour un retour nul ou presque. Leurs clients professionnels ne s'intéressent pas de savoir si le _driver_ est libre ou pas, ils veulent juste une solution rapide et à un prix raisonnable.
En utilisant le _driver_ propriétaire sous Linux, AMD peut utiliser le même _driver_ que sous Windows et donc utiliser les mêmes équipes de développement. Il y a une forte mutualisation des coûts à procéder ainsi, au final l'équipe qui travaille sur la partie Linux pour le _driver_ propriétaire est assez restreinte. Elle s'occupe seulement d'implémenter l'API nécessaire pour faire l'interface entre le cœur du _driver_ et les parties spécifiques au système d'exploitation.
Il est malheureusement très probablement impossible de réaliser un _driver_ open source pour les systèmes d'exploitation de Microsoft, particulièrement avec tout ce qui touche aux protections vidéo ([[HDCP]] et autres). Les compagnies craignent par ailleurs de s'exposer à une fragmentation du _driver_ et de voir des _forks_ plus ou moins réussis conduire éventuellement à une mauvaise expérience utilisateur. Même si personnellement, je pense que l'on pourrait voir des contributions intéressantes aux _drivers_ et que cela ne ferait qu'améliorer l'expérience utilisateur.
On peut alors se demander pourquoi AMD s'embête également avec un _driver_ open source pour Linux. Je pense qu'il y a plusieurs intérêts. D'abord, un meilleur support pour Linux, une expérience _out of the box_ supérieure. Ensuite, pouvoir avoir la certification de leur matériel avec les distributions professionnelles. En effet, pour certifier les cartes graphiques avec RHEL, seuls les _drivers_ open source sont autorisés, c'est une des autres contributions de Red Hat au monde du libre. Malheureusement, assez peu de fabricants de _laptops_ certifient leur matériel avec RHEL, et cela concerne uniquement les lignes professionnelles de leurs ordinateurs portables (assez peu sexy et souvent gros et lourds). Enfin sur Android/ChromeOS, avoir un _driver_ open source et _upstream_ est beaucoup plus simple même si malheureusement Google ne fait rien pour encourager les _drivers_ open source. Il y a d'autres raisons mais qui ne sont pas forcément publiques et je préfère laisser votre imagination travailler.
**_13. Que penses‐tu de l’attitude d’Intel, qui s’implique plus que quiconque dans le développement de ses pilotes graphiques libres, mais qui, dans le même temps, persiste à ne pas s’intégrer à l’architecture commune Gallium3D ?_**
Intel réalise un travail énorme sur l'infrastructure graphique de Linux, nous n'en serions pas où nous en sommes sans eux. J'apprécie donc tout particulièrement leurs nombreuses contributions.
En ce qui concerne Gallium, j'ai eu plusieurs discussions, avec plusieurs d'entre eux. Ils ont des arguments valides et d'autres beaucoup moins. Gallium a été conçu dans l'optique d'écrire un _driver_ graphique une fois et de pouvoir avoir par dessus plusieurs [API](http://fr.wikipedia.org/wiki/Interface_de_programmation) (ce qu'on nomme le _state tracker_ dans la terminologie Gallium) qui utilisent le _driver_ (OpenGL, OpenCL, OpenVG, DirectX, XA, ...).
Pendant longtemps il n'y avait qu'OpenGL et par conséquent pas beaucoup de justifications à Gallium. Car il faut reconnaître une chose, Gallium rajoute une couche et par conséquent un _overhead_. Mesa est connu pour son _overhead_ parfois pathologique, mais ces dernières années, grâce notamment au travail d'Intel, c'est beaucoup moins le cas. Les développeurs de chez Intel n'ont donc pas voulu rajouter un boulet à leur béquille. Il me semble que c'est aujourd'hui beaucoup moins valide et justifié.
Après il y a aussi des aspects de goût (on aime ou pas, c'est le _ou pas_ qui est important), de familiarité (plusieurs années à travailler avec Mesa classique)... Par exemple il est beaucoup plus facile dans le cadre de Mesa classique d'implémenter son propre compilateur de bout en bout en s'interfaçant correctement avec le cœur de Mesa. Ce qui est autrement beaucoup plus difficile pour un _driver_ Gallium. Effectivement dans le paradigme Gallium les shaders contiennent une partie importante des informations nécessaires au code commun (_texture unit_, _sampler_, nombre d'inputs, de constantes ...), ce qui rend nécessaire d'utiliser une représentation intermédiaire commune pour les shaders même si cette représentation intermédiaire est particulièrement mal adaptée pour y effectuer des passes d'optimisations.
Bref si un _driver_ Gallium désire améliorer cela il doit d'abord implémenter une nouvelle représentation interḿediaire pour tout le monde et convertir tout les _drivers_ Gallium. Une tâche bien plus compliquée que de travailler sur un seul _driver_ mais qui a l'avantage de profiter à tout le monde (enfin à tout les _drivers_ Gallium).
**_14. Que penses‐tu de la technologie AMD Dynamic Switchable Graphics (équivalent à Optimus de NVIDIA) ? Avez vous toute la documentation ? Est-ce facile à intégrer ?_**
Je n'aime pas. C'est très difficile à intégrer proprement d'abord parce que Xorg était jusqu'à récemment pas du tout équipé, et encore moins pensé, pour ce genre de configurations. Mais depuis le travail de Dave Airlie nous avons grandement avancé sur le front Xorg. La documentation est comme souvent problématique, et comme toujours entre la documentation et la réalité il y a un abysse insondable. Ces technologies impliquent presque toujours le BIOS système (ACPI) et par conséquent tous les bugs qui vont avec. Et comme toujours, il n'y pas de test pour les BIOS. L'unique test est le _driver_ propriétaire sous Windows : si ca marche, alors c'est que c'est bon, et tant pis si l'API est implémenté à moitié.
Bref, il y avait un manque sur l'infrastructure X. Et il reste des difficultés dues aux larges variations entre chaque vendeur. Les solutions à la Bumblebee sont des hacks qui permettent néanmoins de se servir en partie de ces solutions. Et aujourd'hui, Prime (_NDLA : voir [la dépêche consacrée à la sortie du noyau Linux 3.9](http://linuxfr.org/news/sortie-du-noyau-linux-3-9#toc_14)_) permet d'utiliser de manière plus correcte ce genre de configuration mais c'est encore loin d'être transparent pour l'utilisateur.
**_15. Quels sont les défis techniques, les objectifs déjà atteints et les évolutions du projet ? (notamment : relations avec AMD ? et relations Red Hat/reste de la communauté ?)_**
Vieille série française ? Je crois que le plus gros défi, c'est de résoudre les bugs. Contrairement à Apple, le monde PC ressemble à une jungle : il y a une combinatoire pas possible entre les différentes cartes mère, différents GPU, différentes barrettes mémoire (l'informatique c'est beaucoup moins déterministe qu'il n'y paraît). Il y a toujours des combinaisons problématiques et elle sont seulement testées avec les _drivers_ propriétaires sous Windows.
J'aimerais donc voir une plus grande part de [QA](http://fr.wikipedia.org/wiki/Assurance_qualit%C3%A9) sur le design et la finition des ordinateurs avec Linux. Pour le moment, seul Google avec ses Chromebooks fait cela. Et c'est un travail ingrat et fastidieux.
Concernant les objectifs, je pense que nous les avons déjà atteints : avoir un _driver_ qui marche sur un large panel de configurations et qui a des performances respectables. Il nous reste encore à supporter plusieurs centaines de fonctionnalités du matériel (OpenGL 4, OpenCL 1.2...).
En ce qui concerne les relations, je ne suis probablement pas bien placé pour répondre à cela. Je trouve énormément d'animosité et de violences dans les propos de certains utilisateurs à l'encontre d'AMD (et parfois aussi de Red Hat, mais rarement sur la partie graphique), ignorant souvent l'énorme travail qui est derrière le _driver_ open source ; s'imaginant à tort que si l'on a un bug alors forcément tout le monde l'a aussi et donc que les développeurs sont des incapables. Il y a beaucoup de naïveté sur la réalité de l'informatique, cette certitude que tout est prévisible et documenté, et que par conséquent aucune situation n'est imprévisible.
Dans une expérience, je suis du côté d'Einstein: « La théorie, c'est quand on sait tout et que rien ne fonctionne. La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi. Ici, nous avons réuni théorie et pratique : rien ne fonctionne... et personne ne sait pourquoi ! ».
Je comprends néanmoins la frustration que cela peut provoquer chez les utilisateurs. Quand nous achetons un ordinateur nous voulons le voir fonctionner, nous voulons pouvoir en utiliser toutes les fonctionnalités. Le _driver_ open source est loin de pouvoir satisfaire tout le monde, mais comme je le disais cela vient d'une incompréhension des gens. Seul un produit pensé pour Linux fonctionnera bien avec Linux, et ce tant qu'il n'y aura pas des millions de personnes capable de débugger chaque combinaison de matériel.
**_16. Au sujet des firmwares non-libres requis par le pilote libre pour faire fonctionner la carte..._**
J'aimerais voir des gens faire de l'ingénierie inversée de ces [[firmwares]]. Ce n'est pas si compliqué, d'autant plus que l'on sait exactement ce qu'ils font. Bref on connaît le contenu de la fonction, mais on ne connait pas le jeu d'instructions utilisé pour l'implémenter.
**_17. Justement, à quoi servent-ils ? Leur existence est-elle inhérente à tout GPU (il me semble par exemple que les puces graphiques Intel ne nécessitent pas de tels firmwares) ? Je lis parfois que ces firmwares ne font rien d'évolué, qu'ils sont « bêtes » et qu'ils ne peuvent donc être malicieux... Pourtant le firmware nécessaire à l’accélération vidéo via les unités dédiées UVD [a l’air énorme](http://people.freedesktop.org/~agd5f/radeon_ucode) par exemple..._**
Ils servent à réaliser des tâches simples, principalement ils écrivent et lisent différents registres du GPU, ils s'occupent également de la synchronisation entre différent blocs du GPU. Ainsi sur les anciennes générations de Radeon ils est tout a fait possible de faire un _driver_ libre qui n'utilise pas le _command processor_ (abréviation _CP_) et donc de n'utiliser aucun firmware mais tout le travail doit alors être fait sur le CPU : le CPU devrait lire en boucle certains registres et, en fonction du statut, écrire ou pas les registres en attente. Bref le _driver_ consommerait d'un coup énormément de temps processeur.
Sur les nouvelles générations c'est probablement impossible, un certains nombre de registres ne sont certainement plus accessible directement depuis le CPU et seul le CP ou les autres micro-contrôleurs y ont accès. De plus le micro-contrôleur est indispensable pour la gestion de l'énergie, il effectue des tâches qui demandent du temps réel avec une précision que l'on ne pourrait pas atteindre depuis le CPU. Ainsi, changer les fréquences mémoire demande plusieurs centaines de micro-secondes et il faut couper certains blocs dans le laps de temps et les réactiver après.
Pour les firmwares video je ne connais pas leur contenu, mais j'imagine qu'il s'agit de l'implémentation du codec, c'est à dire que si l'on savait écrire le firmware on pourrait ajouter le support d'autres codecs comme VP9 ou [Daala](http://xiphmont.livejournal.com/60113.html)… Par exemple les firmwares pour R600 et R700 sont énormes également mais c'est parce qu'ils font l'émulation de vieilles commandes 2D en utilisant le bloc 3D.
Pour Intel il me semble qu'ils ont aussi un firmware mais qu'il est caché dans le BIOS, par exemple les APU AMD n'ont pas besoin des mêmes firmwares pour le GPU parce qu'une partie est dans le BIOS système. Enfin je ne suis pas très sûr de tout cela, c'est mon _educated guess_.
L'avantage d'un firmware c'est que c'est beaucoup plus polyvalent et évolutif, par exemple on peut contourner des bugs hardware dans le firmware du GPU. De plus il existe beaucoup de cores de micro-contrôleur déjà largement éprouvés, donc pour la conception du circuit ils savent qu'ils ne peuvent pas avoir de bug dans le micro-contrôleur et que si bug il y a alors c'est dans le firmware. Au contraire s'ils avaient implémenté le firmware en dur, les bugs ne seraient pas corrigeables sans un nouveau _tapeout_ (et tout les coûts qui vont avec, par exemple il me semble qu'imprimer un masque processeur 28nm c'est de l'ordre du million de dollars).
**_18. Quelles sont les prochaines avancées à attendre du projet radeon ?_**
Probablement [HSA](http://developer.amd.com/resources/heterogeneous-computing/what-is-heterogeneous-system-architecture-hsa/), sinon comme toujours : corrections de bugs, support de nouveau matériel, améliorations diverses, support de plus d'extensions OpenGL, plus rapide, meilleurs compilateurs, ... J'aimerais également voir le support du moteur de compression vidéo même si l'intérêt est probablement limité (h.264 seulement et pas un codec libre).
**_19. Quelle carte graphique conseillerais‐tu d’acheter pour utiliser Linux ?_**
Facile comme question, la réponse, Jean-Pierre, c'est Obi-Wan Kenobi ! Et c'est mon dernier mot !
Après, je dirais qu'il faut d'abord définir l'usage. Si c'est pour LibreOffice, le Web, et des petits jeux, AMD ou Intel avec leurs GPU intégrés. Pour jouer à des gros jeux la réponse est plus ardue. NVIDIA a encore, me semble-t-il, un avantage dans ce genre d'usages : leur _driver_ graphique propriétaire se comporte mieux avec un plus large éventail de jeux.
Pour des applications professionnelles, j'ai de bons retours que cela soit pour AMD ou NVIDIA (avec probablement un avantage pour AMD au niveau du prix), mais je parle ici de l'utilisation d'une distribution professionnelle, qui est certifiée pour le logiciel utilisé avec les _drivers_ propriétaires.
**_20. As‐tu d’autres projets relatifs à Linux ou au Libre en général ?_**
Oui, comme beaucoup de passionnés du libre, j'ai des tonnes de projets :) Le plus important étant le convecteur temporel de ma DeLorean.
**_21. Les deux dernières questions ont essentiellement pour but de mettre de l’animation dans les commentaires : quels distribution et environnement graphique utilises‐tu ?_**
Fedora et GNOME. Je suis assis à côté des gnomeux comme je dis, ils sont plus nombreux et certains plus grands que moi ;) J'ai par ailleurs la chance de voir tout le travail que requiert un environnement graphique, et le souci du détail va loin. Après, je comprends que certains paradigmes choquent et dérangent. L'humain est un animal qui aime trop ses habitudes, qui se complaît trop dans la routine et se braque facilement contre le changement. C'est difficile d'aller contre ça et peut-être pas nécessaire. Mais dans tous les cas, je connais la passion et l'énergie qu'ils mettent dans leur travail. Je leur en suis profondément reconnaissant. Ils me facilitent la vie plus de fois qu'ils ne m'énervent, mais on fait moins attention aux choses qui marchent qu'à celles qui nous dérangent.
J'ai envie de dire Captain Obvious tu sais ce qu'il te reste à affronter !
Pour ceux qui répondront qu'il faut des logiciels et une interface intuitifs, je répondrai que l'intuition de tout humain est avant tout la somme de ses expériences. Par conséquent, pour que cela soit intuitif il faut que cela ressemble à une expérience déjà familière.
**_22. Ton avis sur la pile graphique de GNU/Linux et ses récentes évolutions (Wayland, Mir, mais pas que) ?_**
D'abord, je ne parle ici que pour moi, il ne s'agit que de mon opinion et elle ne reflète pas nécessairement la position de Red Hat.
Enfin sur la question troll, la réponse est Obi-Wan Kenobi ! Sinon je pense que la pile graphique Linux a largement progressé comme je l'ai expliqué plus haut. X reste a mes yeux l'étoile noire qu'il faut détruire ! Plusieurs présentations sur Wayland expliquent bien mieux que je ne le ferais tout cela.
Il y a des aspects que je n'aime pas dans Wayland, comme cette erreur, à mon avis, de ne pas encoder le format précis des surfaces dans le protocole (ARGB565, 8888, ..., storage pattern, ...). Mais globalement c'est un pas de géant dans la bonne direction en comparaison d'X.
Mir est plus politique me semble t-il. Il n'y a aucune bonne raison technique à Mir si ce n'est le refus d'utiliser une API stable. Je ne nie pas les avantages à l'absence d'API. On peut facilement corriger les choses, les changer. Il me semble que Canonical ne visera une API stable que pour les couches supérieures, c'est à dire l'API de programmation des applications. Les applications ne parleront pas avec Mir directement mais utiliseront un toolkit qui lui, aura une API stable.
C'est d'ailleurs me semble t-il la force d'Android : offrir une API stable pour écrire des applications. Mais dans Android, les couches de base sont bien trop instables, il s'agit souvent d'énormes hacks pour faire marcher un produit, c'est l'horrible mantra du "ship and forget". Bref, le bas niveau change pour un oui ou pour un non et est souvent customisé par les intégrateurs (Samsung, HTC, ...).
Mais ce qui importe, c'est que l'API pour programmer une application soit stable. A mon avis, c'est une des raisons de l'échec de Linux sur le _desktop_. Nous avons une API X stable mais ce n'est pas le niveau auquel une application est écrite. Je ne suis pas un expert sur les toolkits, mais il me semble que leur API/ABI a changé plus souvent que les saisons.
Pour en revenir à Mir, si on admet que l'absence d'API peut être intéressante, je ne crois pas qu'elle était pour autant nécessaire. Enfin, et c'est le point qui me gêne le plus, la [CLA](http://en.wikipedia.org/wiki/Contributor_License_Agreement) de Canonical crée une relation asymétrique qui va à l'encontre du libre. C'est à mon goût une trahison. La pseudo-justification de pouvoir ainsi faire une release fermée pour ne pas faire peur au gentil _driver_ propriétaire ne tient pas. Il aurait été tout aussi simple d'utiliser une licence MIT ou BSD. Mais là encore, il s'agit de pouvoir garder le contrôle et d'être le seul à pouvoir profiter du retour sur investissement. Bref contraire au libre.
Voila je m'arrête là j'ai déjà bien papoté.
Les photes d'orthofrages sont la preuve de l'authenticité de cette interview. C'est mon certificat a moi (_NDLA : des fautes ont été débusquées avant publication par les contributeurs à cette dépêche_).