Entretien avec Jean-Sébastien Pédron à pied d'œuvre pour porter KMS pour Radeon dans FreeBSD

76
1
sept.
2013
FreeBSD

Nous avons la chance d'avoir quelques développeurs qui fréquentent LinuxFR.org (what else ?), dont Jean-Sébastien Pédron (alias dumbbell) qui contribue au système d'exploitation libre FreeBSD (dont dérivent notamment PC-BSD, GhostBSD, FreeNAS…).

Alors que FreeBSD vient de fêter ses vingt ans, que l'on apprenait récemment qu'il serait au cœur de la future PlayStation 4 et que la version 9.2 pointe le bout de son nez, nous revenons avec Jean-Sébastien Pédron sur son travail en cours, de portage du Kernel-based mode-setting (KMS) dans FreeBSD pour les GPU Radeon.

Dans la mesure où les dernières versions du pilote libre radeon (à partir de la version 7.0 du pilote xf86-video-ati publiée le 6 novembre 2012, précisément) et Weston, le compositeur de référence du projet Wayland, nécessitent KMS, ce port revêt une importance particulière pour le projet FreeBSD (rappelons que depuis FreeBSD 9.1, le pilote Intel prend en charge KMS).

Jean-Sébastien a accepté de répondre à quelques questions pour LinuxFR.org ; nous le remercions chaleureusement à la fois pour le temps consacré à cet entretien et pour son implication dans FreeBSD !

À noter que les hyperliens ont été ajoutés après coup par les contributeurs à cette dépêche pour en faciliter la lecture.

Pourrais-tu te présenter en quelques mots ?

J'ai 32 ans. J'ai obtenu un DUT en Informatique à Vannes (56) en 2000 et je suis actuellement employé par Yakaz pour du développement Erlang et C côté backend.

Après avoir utilisé Linux pendant plusieurs années, surtout Slackware, je suis passé à FreeBSD 4.3 sur un serveur puis sur mon poste client (desktop).

J'ai commencé à contribuer à FreeBSD par un portage de ReiserFS. Ce travail a été inclus dans FreeBSD 6.0. Par la suite, j'ai assez peu contribué : des améliorations au support des touchpads Synaptics ou à dhclient, des corrections de bugs, quelques packages. Je continue bien sûr à utiliser ce système sur mon desktop (au travail ou à la maison) et sur quelques serveurs (FreeBSD normal ou NanoBSD).

Entre deux kernel panics, je fais beaucoup de roller et de musique (batterie et autres percussions dans un groupe de Jazz), un peu de photographie et de l'astronomie quand je rentre dans ma Bretagne natale, au club d'astronomie Voyager 3.

Comment définirais‐tu ton rapport au logiciel libre, et comment es‐tu entré en contact avec lui ?

C'est un ami, Sébastien Millet, qui m'a fait découvrir Linux, avec la distribution Slackware, et le Logiciel Libre, en 1998 alors que nous étions à l'IUT. C'est grâce à lui que j'ai pu apprendre la programmation C (seul le Java nous était enseigné) et à me servir d'un Linux en tant que poste de travail. Par la suite, grâce au Libre, j'ai pu continuer par moi-même, bien souvent en rencontrant un problème avec un logiciel et en le rapportant auprès des développeurs avec, si possible, un patch.

J'ai trouvé ça génial d'avoir cette possibilité de lire et modifier le code d'un logiciel puis de pouvoir communiquer avec les gens derrière un projet. Et c'est aussi très gratifiant de voir qu'un rapport de bug ou un patch a aidé ces personnes.

Parlons de ta contribution en cours au projet FreeBSD, consistant à porter KMS pour les GPU Radeon. Dans quel contexte ce projet a-t-il démarré ?

Ces dernières années, la pile graphique libre a beaucoup évolué avec d'abord la modularisation de X.Org puis l'arrivée des pilotes KMS (pour « Kernel Modesetting », c'est-à-dire que le noyau pilote la carte graphique et les applications lui demandent gentiment ce qu'elles voudraient). Toute cette transformation s'est faite autour de Linux. C'est grâce à ça qu'on a vu arriver l'accélération 3D, du calcul parallèle sur la carte graphique (GPGPU), une meilleure gestion d'énergie, etc.

Du côté de FreeBSD, les choses ont peu bougé. La modularisation de X.Org a bien sûr été intégrée à l'arbre des ports (le système de packages non-binaires), mais les pilotes UMS (pour « User Modesetting », la solution historique où le serveur X pilote entièrement le matériel) ont continué à être les seuls utilisés.

Pour les possesseurs de cartes NVIDIA, le fabricant fournit un pilote propriétaire depuis longtemps, comme pour Linux.

Mais le développement de ces pilotes UMS a été progressivement abandonné, laissant les utilisateurs de cartes récentes avec comme seule option le mode VESA (définition limitée, aucune accélération matérielle même 2D, etc.) ou le pilote propriétaire NVIDIA. Au départ, ça voulait dire que beaucoup devaient se contenter d'un environnement graphique spartiate et peu réactif. Mais avec Wayland qui semble être le successeur de X.Org, ça pouvait signifier la fin de FreeBSD sur une station de travail.

La Fondation FreeBSD a donc sponsorisé un développeur, Konstantin Belousov, pour qu'il porte de Linux vers FreeBSD le code commun (DRM), le gestionnaire de mémoire GEM et le pilote KMS Intel. Ce travail a abouti en 2012 et est disponible dans FreeBSD 9.1. D'autres systèmes d'exploitation, dont les autres *BSD ont fait de même.

Pour les cartes AMD, le problème restait entier. Konstantin n'a pas souhaité faire ce travail mais a promis de faire le portage du gestionnaire de mémoire TTM si quelqu'un s'occupait du pilote radeon.

Comme de nombreux utilisateurs, j'attendais que Quelqu'un™ se lance puisque j'étais coincé avec une Mobility Radeon HD 5870 : même l'extension Xv, qui permet un affichage optimisé des vidéos, n'était pas supportée, rendant la lecture d'un film en FullHD saccadée. Mais en janvier 2013, j'ai décidé de me rendre un peu plus utile, même si je n'y connaissais rien dans les pilotes et la pile graphique. J'ai contacté Konstantin pour savoir si quelqu'un avait commencé et comment je pouvais aider : Alexander Kabaev avait fait une première ébauche, basée sur Linux 3.4, qu'il n'avait pas terminée. Et personne n'avait touché à TTM encore. J'ai donc repris le travail d'Alexander en me basant cette fois sur Linux 3.8-rc3, et Konstantin a porté TTM en 15 jours.

Où en est le port à l'heure actuelle ?

Le travail est bien avancé : il permet déjà à quelques aventuriers d'afficher leur bureau favori, de lire des vidéos sans que le PC ne prenne feu, de jouer à OpenArena, de regarder Piglit dessiner des trucs, de faire un peu de WebGL.

Par contre, le suspend/resume n'est pas testé, le support du VT-switch est instable et il reste beaucoup de travail à faire, notamment sur Mesa, pour permettre des choses comme OpenCL.

Le pilote est maintenant intégré à la branche de développement (« HEAD ») depuis le dimanche 25 août, et j'ai fait une annonce sur la liste de discussion freebsd-x11@FreeBSD.org le mardi 27 août. Le pilote sera donc bien présent dans FreeBSD 10.0-RELEASE, prévu pour fin 2013 ou début 2014.

Quelles difficultés rencontres-tu ?

La principale difficulté est mon manque de connaissance dans la pile graphique et le fonctionnement des cartes graphiques. Même chose concernant la gestion de mémoire, sujet auquel je n'avais jamais touché jusque là.

Il y a très peu de documentation sur la pile graphique. Mais ce n'est pas un reproche : je comprends qu'elle serait impossible à maintenir, vu le rythme élevé des changements.

Le travail préliminaire de Konstantin et Alexander m'a énormément aidé. C'est bien grâce à ça que le projet est aussi avancé après 8 mois.

Et puis il y a le problème classique de tout développement de pilote : l'accès au matériel. Mais avec l'intégration du pilote dans la branche de développement, davantage de personnes vont pouvoir l'essayer avec leur matériel et nous dire si ça fonctionne ou pas. Mon employeur me prête aussi une machine avec une carte Radeon et un contributeur m'a déjà envoyé trois autres cartes.

Quels sont les prochains sujets et même les futurs enjeux pour FreeBSD ?

Côté noyau, nous avons plusieurs tâches :

  • Le pilote radeon va demander une maintenance permanente bien sûr. Pour l'instant, il correspond à celui de Linux 3.8. Mais Linux 3.10 et 3.11 apportent respectivement l'accélération matérielle du décodage des vidéos et une meilleure gestion d'énergie, deux grosses fonctionnalités très intéressantes.

  • Même tarif pour le pilote Intel qui n'a pas été mis à jour depuis son inclusion dans FreeBSD 9, et la partie commune DRM (GEM et TTM compris). Par exemple, nous ne supportons pas bien les tous derniers CPU et Mesa 9.2 repose sur une fonctionnalité du pilote côté noyau que nous n'avons pas. Mais je ne connais pas bien ce pilote. Dans tous les cas, ça devient urgent de s'en occuper à nouveau.

  • Tous pilotes confondus, nous n'avons encore rien fait concernant le support des cartes qui se partagent un unique ensemble de ports de sortie (technologie connue sous les noms « Optimus » chez NVIDIA ou « ATI Hybrid Graphics » chez AMD). Il nous faut donc travailler sur la prise en charge de « PRIME », une brique dans DRM qui permet de prendre un buffer rendu par la carte n°1 pour le transférer à la carte n°2 pour l'affichage (NDLA : voir la dépêche consacrée à la sortie du noyau Linux 3.9).

  • Le support de la console (« VT switching »). L'actuelle console de FreeBSD ne gère pas KMS, donc aujourd'hui, quand un utilisateur charge un pilote KMS, il ne peut plus utiliser la console, ni pendant sa session X en tapant Ctrl-Alt-Fx, ni après la fermeture du serveur. C'est une regression importante et Aleksandr Rybalko travaille en ce moment dessus pour corriger ça.

Il y a également les autres pilotes (nouveau, qxl et virgl pour la virtualisation et la ribambelle de pilotes pour l'embarqué qui sont déjà disponibles sous Linux). Mais pour l'instant, ce n'est pas à l'ordre du jour.

Côté userland, le morceau principal est Mesa. J'ai déjà travaillé sur plusieurs patchs pour que Mesa compile sous FreeBSD out-of-the-box, avec l'aide précieuse de Jonathan Gray d'OpenBSD. Et Koop Mast a déjà préparé la mise à jour de Mesa (9.1.6) dans les ports. Mais Mesa a aussi une dépendance forte à udev pour certains de ses composants ; composants qui sont eux-mêmes obligatoires pour le support d'OpenCL. FreeBSD a depuis longtemps un système similaire mais il va falloir ajouter des API pour offrir les fonctionnalités manquantes.

On doit aussi se pencher sur Wayland pour ne pas se retrouver le bec dans l'eau. Koop Mast et Pierre-Emmanuel Pédron (hep, frangin, si tu lis ces lignes, retourne travailler !) travaillent sur le sujet.

Pour l'instant, nous sommes quelques développeurs à s'intéresser à cette pile graphique : ça fait très peu de monde pour s'occuper de la maintenance des pilotes KMS, l'ajout de fonctionnalités, la maintenance des très nombreux packages, etc. Surtout qu'il faut se former en même temps.

Beaucoup d'encre a déjà coulé sur le sujet de la responsabilité dans le support de la pile graphique sur les non-Linux. Certains disent que les développeurs X.Org/Linux auraient dû penser aux autres noyaux, en les intégrant au processus de décisions et de design. D'autres disent que c'était à chaque communauté de s'intéresser au sujet et de participer. Mais vouloir trouver des responsables n'est absolument pas constructif et constitue une perte de temps. C'est à nous de raccrocher le wagon et de participer à la suite.

Nous sommes une petite équipe mais tous très motivés et je suis confiant que la situation du desktop sous FreeBSD va s'améliorer. D'ailleurs, si des gens sur LinuxFR souhaitent venir donner un coup de main, ce sera avec plaisir :)

Échanges‐tu avec les développeurs des autres *BSD sur ta partie ?

De manière générale, il y a une bonne collaboration entre les *BSDs. Même si les objectifs sont différents, pas mal de code circule, que ce soit pour des bibliothèques et des outils (comme make(1) qui vient de NetBSD), ou des morceaux de noyau (exemple : le firewall pf, venant d'OpenBSD).

Concernant la pile graphique, Jonathan Gray et Mark Kettenis d'OpenBSD m'ont envoyé quelques patchs pour le pilotes radeon et on a échangé quelques patchs pour Mesa. J'ai aussi profité de leur expérience plus grande.

Je suis également en contact avec François Tigeot, de DragonFly, qui s'est occupé du pilote Intel chez eux. Je pense qu'on va travailler de plus en plus ensemble, parce qu'on a sans doute moyen de se répartir le boulot.

Je ne sais pas pourquoi il n'y a pas eu davantage de collaboration plus tôt sur ce sujet. Peut-être à cause de différences trop importantes dans la gestion de la mémoire ou les primitives de locking. Je ne connais pas les autres *BSD suffisamment pour juger de tout ça.

As‐tu d’autres projets relatifs à Linux ou au Libre en général ?

Je participe un peu à darktable, un outil de développement de photos, principalement pour m'assurer que le logiciel compile et fonctionne sous FreeBSD. Les autres développeurs testent surtout pour les distributions Linux qu'ils utilisent au quotidien. Et de temps en temps, ça casse à cause d'une différence de version de la GLib ou à cause du compilateur (certains utilisateurs de FreeBSD préfèrent utiliser le compilateur par défaut, GCC 4.2.1 dans FreeBSD 9, plutôt que d'installer une version plus moderne).

À part ça, ce sont quelques patches pour divers logiciels quand je rencontre des problèmes et que j'ai le temps et l'envie de corriger, ou pour des logiciels que j'utilise au travail, notamment Erlang ou DuckDuckGo.

J'ai aussi écrit plusieurs articles sur Wikipédia dans la partie astronomie, il y a quelques années, mais plus trop maintenant.

Quels distribution et environnement graphique utilises‐tu ?

J'ai surtout utilisé Slackware et Linux From Scratch à titre personnel. La première parce que c'est celle qu'on m'a présenté et j'ai beaucoup aimé. La seconde, parce que ça me permettait de connaître encore mieux le fonctionnement d'une distribution. J'ai utilisé une Debian pendant mon passage chez Cegetel puisque c'était aussi l'environnement de developpement et de production. Aujourd'hui, j'ai une Ubuntu en dual-boot, parce qu'elle me permet avant tout de vérifier, quand un truc ne fonctionne pas, si ça vient de FreeBSD ou d'autre chose.

Côté environnement graphique, j'utilise Awesome comme gestionnaire de fenêtres. Donc un environnement minimaliste et efficace pour faire tourner XTerm/Firefox/Thunderbird.

Quel est ton avis sur les évolutions en cours de la pile graphique ?

Mes connaissances sont encore trop limitées pour me permettre de juger de la direction prise par la pile graphique libre. Mais tout ça me laisse l'impression que ça avance très bien grâce à des gens qui savent ce qu'ils font. Il y a des décisions difficiles à prendre qui sont prises, des chantiers énormes qui sont entrepris. Beaucoup de gens se décarcassent pour améliorer et moderniser la pile graphique libre et j'ai le sentiment que c'est une réussite jusque là.

Bon, mon entourage a toujours peur des xterms sur mon écran et ça donne une mauvaise image de FreeBSD/Linux, mais je suis en mesure maintenant de leur faire une démo avec un environnement de bureau moderne pour qu'ils voient comme c'est classe !

  • # BSD

    Posté par (page perso) . Évalué à 10.

    Merci pour cette dépêche, c'est le genre de lecture que j'aime (comme l'itw de Jérôme Glisse sur radeon sur linux).

    J'ai moi même une carte radeon (hd 6310 dans un sony vaio), et bien que cela fonctionne plutot bien depuis quelques années sur du linux, j'avais vraiment du mal sur du free/openbsd, et le fait de rester en vesa m'était insupportable (et très peu utilisable).

    Il y a quelques semaines le support de KMS pour radeon a été mergé dans openbsd (dispo en snapshot, http://undeadly.org/cgi?action=article&sid=20130812135734 ), et cela tourne maintenant quasi parfaitement, l'affiche est fluide, je n'ai plus d'écran qui devient tout blanc ou le switch VT qui foire (à priori cela ne fonctionne pas encore sur fbsd ? :)).
    Ça fait plaisir que la pile graphique avance coté *bsd, et que des gens avec des "connaissances encore trop limitées" (?!?) fasse un travail si important !

    • [^] # Re: BSD

      Posté par (page perso) . Évalué à 6.

      Il y a quelques semaines le support de KMS pour radeon a été mergé dans openbsd

      Ouais, ils ont fait du super boulot ! Le driver Intel puis le driver Radeon ont été intégrés très rapidement.

      switch VT (…) à priori cela ne fonctionne pas encore sur fbsd ?

      En effet, c'est en cours. Un premier patch incomplet a circulé et ça devrait être prêt pour FreeBSD 10, puis mergé dans FreeBSD 9.

  • # Et que se passera-t-il quand le travail sera terminé ?

    Posté par (page perso) . Évalué à 2.

    Car il ne semble pas qu’AMD ou Intel contribuent directement à ce travail, cela voudra dire qu’il faudra des personnes motivées pour continuer à mettre à jour, améliorer, nettoyer ces pilotes et intégrations.

    Love – bépo

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.