La pile graphique de Linux démystifiée

Jamais deux sans trois. Après un billet technique sur les SSD sous Linux publié ici même, et un autre sur les processeurs Intel Sandy Bridge sous Linux publié sur LinuxFr.org, je vous propose un nouveau billet technique expliquant, cette fois, le fonctionnement de la pile graphique sous Linux.

Historique

Traditionnellement le serveur X.Org avait en charge notamment tout le travail graphique.

Il s'est avéré que, si le serveur X était un outil très puissant, ce n'était pas un outil très performant. Différentes méthodes ont été explorées pour pallier cette carence :

• court-circuiter le serveur X lorsqu'il n'était pas utile, pour supprimer un intermédiaire : ainsi DRI permet à Mesa d'adresser le matériel sans passer par le serveur X (Mesa ne peut s'adresser lui-même au matériel, étant en espace utilisateur) (voir le paragraphe Composition d'un pilote graphique libre sous Linux ci-après),
• des extensions ont été ajoutées au serveur X : XRender, XRandR, et Composite notamment.

Par ailleurs, un certain nombre de choses qui étaient gérées par X.Org ont été réaffectées au noyau (evdev, GEM et KMS) ou à des bibliothèques dédiées (Cairo, pixman, FreeType, Fontconfig, Pango etc.).

De X.Org à Wayland

Avec l'avènement des compositeurs (permettant des effets de transparence, d'ombre portée etc.), le fonctionnement de X.Org pour la gestion graphique ne semble plus optimal car il constitue une étape supplémentaire entre l'application et le compositeur ainsi qu'entre le compositeur et le matériel.

Wayland a été proposé pour succéder à X.Org : un serveur Wayland joue à la fois le rôle de compositeur, de gestionnaire de fenêtres et de serveur d'affichage. Wayland s'appuie pour cela sur une partie de l'infrastructure existante : pilotes DRI, GEM et KMS.

Wayland est en plein développement et n'est pas encore proposé par défaut dans nos distributions GNU/Linux.

Composition d'un pilote graphique libre sous Linux

Dans la dépêche parue sur LinuxFr.org, j'expliquais que, pour pouvoir utiliser la partie graphique des derniers processeurs Intel Core i3/i5/i7 (famille Sandy Bridge) sous Linux, il fallait au mimimum :

• un noyau Linux 2.6.38,
• Mesa 7.11,
• le pilote xf86-video-intel 2.15.0.

Mais pourquoi faudrait-il donc vérifier la présence de ces trois composants : un pilote graphique à jour ne suffirait donc t-il pas ?

Sous Linux, un pilote libre pour carte graphique se décompose distinctement en trois parties :

• DDX, le pilote d'affichage du serveur X
• DRI, le pilote Mesa
• DRM, le pilote du noyau

Quand on parle couramment de pilote graphique libre sous Linux, on évoque généralement le pilote DDX. C'est un pilote spécifique à chaque matériel (nommé « radeon » pour les cartes AMD, « nouveau » pour les cartes Nvidia, « intel » pour les IGP Intel...) utilisé par le serveur X pour gérer la 2D, c'est-à-dire essentiellement pour les effets de composition et l'accélération vidéo (via les procédés d'accélération 2D du serveur X comme EXA et ses dérivés (UXA, SNA) ou encore Xv).

Mesa est l'implémentation libre d'OpenGL pour Linux (OpenGL étant un procédé d'accélération 3D). Précisément, Mesa se décompose en deux parties : la bibliothèque Mesa 3D proprement dite, et les pilotes DRI chargés de traduire les fonctions gérées par la bibliothèque Mesa 3D en instructions compréhensibles par la carte graphique. Le résultat est envoyé à la carte graphique via DRM, le pilote du noyau correspondant qui gère seul dorénavant les accès au matériel (DDX avait également accès au matériel avant que KMS ne permette de transférer la gestion des modes d'affichage au noyau). L'accélération 3D requiert donc une prise en charge à la fois par Mesa et le noyau.

Mesa 3D ou Gallium3D

Gallium3D est présenté comme le successeur de Mesa 3D : il consiste à proposer un plus grand niveau d'abstraction du matériel afin de mutualiser au maximum les ressources au sein de cette bibliothèque et de simplifier corrélativement le développement des pilotes de cartes graphiques. Toutefois à ce jour seuls les pilotes libres pour cartes Nvidia (projet Nouveau) et AMD (lire sur phoronix ici et là) l'utilisent, tandis qu'Intel (qui développe lui-même les pilotes libres pour ses puces) n'a pas souhaité investir dans ce changement et continue de proposer des pilotes Mesa classiques. Cependant Google développe actuellement des pilotes Gallium3D pour les IGP Intel que l'on trouve dans les chipsets i915 (série GMA).

Voilà, j'espère que c'est plus clair pour vous à présent. Moi, en tout cas, ça m'a permis de mieux comprendre le mille-feuille graphique sous Linux...

Pour en apprendre plus :

• (Re)Architecture of the X Window System par James Gettys et Keith Packard le 15 juin 2004
• Le point sur le traitement graphique sous Linux par Jon Smirl le 30 août 2005
• 4 Years Later par Pavel Rojtberg le 1er juillet 2009
• Linux Graphics Driver Stack Explained par Yang Zhao le 15 octobre 2009

L'illustration en tête de ce billet est une composition réalisée par mes soins à partir de cette photographie et placée sous licence CC BY-SA.