vignette|300px|alt=Flowchart with Tux, the Linux penguin|Les données et instructions sont envoyées au GPU pour traitement. Les résultats rendus sont enregistrés dans un framebuffer, dont le contenu est scanné par le display controller et envoyé à l'écran.
Un pilote open source de carte graphique est un logiciel ou un ensemble de logiciels qui contrôle la carte graphique d'un ordinateur et prend en charge le rendu graphique de l'affichage, l'interface de programmations (dite API) et qui est livré avec une licence de type logiciel libre. Le pilote de carte graphique est écrit pour une gamme de matérielpouvant éventuellement correspondre à une marque, un fabricant ou un GPU) pour laquelle il est capable de gérer divers matériels (ou cartes) spécifiques. Il prend en charge en ensemble de sous-parties de l'API utilisé par les applications pour accéder à la carte graphique. Il fonctionne avec un système d'exploitation spécifique, et dans le cas de Linux, soit dans un noyau spécifique soit dans un Loadable Kernel Module.
Il permet aussi de contrôler la sortie sur l'affichage quand le display driver fait partie du matériel graphique. La plupart des pilotes en source ouvert de carte graphique sont développés par le projet Mesa. Le pilote est constitué d'un compilateur, une liste de rendering API, et du logiciel qui gère le matériel graphique.
Pilotes open source et binary drivers
Dans l'écosystème des distributions de logiciel libre, un pilote binaire peut ne pas résister à une mise à niveau de la distribution de logiciels ce qui conduit à l'arrêt de fonctionnement de l'écran tant que le problème ne peut pas être résolu. Une des causes possibles de ce dysfonctionnement, dans le cas de Nvidia, tient à deux faits incompatibles.: un pilote binaire est dépendant d'une version binaire du noyau du système d'exploitation; la mise à niveau d'une distribution peut conduire à un nouveau binaire du noyau du système d'exploitation remplaçant l'ancienne.
Support matériel La suppression de firmware propriétaire présent dans le noyau Linux cause des pertes de fonctionnalités pour certains matériels qui n'ont pas d'équivalent open source. Cela affecte certaines cartes vidéo telles que des cartes graphiques Nvidia. Lorsque c'est possible, un substitut libre au firmware est fourni. .
Microcode Linux-libre ne suggère pas la mise à jour de microcode de processeur, puisque ce code est propriétaire. Les mises à jour de microcode sont proposées dans la branche principale du noyau Linux entre autres raisons pour mitiger les vulnérabilités matérielles.
Histoire
Dans les débuts des PC, le fonctionnement des cartes VGA a été standardisé, notamment autour des différents modes d'affichages et du système d'interruptions logicielles, notamment sous DOS.
Dans les années 1986, sur les PC grands publics, en raison de la complexité d'écriture de drivers, Windows a apporté des drivers Windows génériques et encouragé les fabricants de matériel à les utiliser.. Toutefois, ces drivers n'étant pas open source, ils n'ont pas pu être réutilisés pour d'autres systèmes d'exploitation.
En 2009 et 2011, des drivers open sources sous Ubuntu supportent l'accélération matérielle 3D car Intel et ATI ont mis à disposition open source ces drivers. Par ailleurs, Linux dispose d'excellents graphiques 2D...
évolution des couches open source Dans l'environnement Unix et Linux, de nouveaux drivers open-source sont apparus.
Principe initial du système X-Window
gauche|vignette|alt=Diagramme des premières couches graphiques des distributions Linux|Pilotes 2D du serveur X Les couches de logiciels et pilotes graphiques utilisées dans les distributions Linux ont évolué, à partir du protocole cœur du X Window System. Il s'agit à l'origine d'affichage de l'image des écrans en deux dimensions, dite 2D.
Cet affichage était optionnel puisque le lancement de X Window System dépend du Run level (comme expliqué plus bas). En principe, ceci assure que l'affichage fonctionne correctement en mode texte, sans défaut possible, avant le lancement du X Window System.
API GLX (1992-2012)
gauche|vignette|alt=Autre diagramme des premières couches graphiques des distributions Linux|Rendu indirect sur GLX utilisant Utah GLX
L'API API GLX est une « Extension OpenGL pour le serveur X ». Elle est créée en 1992 et fournissant la connexion entre OpenGL et le serveur X : elle permet aux programmes qui souhaitent utiliser OpenGL de le faire dans une fenêtre fournie par le serveur X.
La dernière version est la version 1.4, sortie le . Elle a été proposée à la déprécation en ce qui concerne X.org en 2012 par Ian Romanick en faveur d'EGL
Suite
Noyau Linux 3.12, depuis 2013
gauche|vignette|alt=Diagramme du noyau Linux, avec Wayland utilisant EGL|Dans le noyau Linux 3.12, les nœuds de rendu sont fusionnés et le mode setting est extrait à part. Wayland implémente le direct rendering sur EGL.
L'interface de programmation (API) EGL fait le lien entre ses API de rendu et le système de fenêtrage du système d'exploitation sous-jacent. EGL est une option moins dépendante de la plate-forme que GLX ou WGL. Les spécifications d'EGL lui permettent de s'interfacer avec X11, avec une API très similaire à celle de GLX, la remplaçant ainsi avantageusement. EGL prend en charge la gestion des contextes graphiques, les relations entre les surfaces de dessin et les tampons mémoire, ainsi que la synchronisation du rendu. EGL permet ainsi la gestion efficace de rendu graphique mixte (2D et 3D) accéléré matériellement EGL Overview.
La bibliothèque logicielle libre Mesa, utilisée sous X.org, est compatible avec les versions 1.1 et 2.0 d'OpenGL ES. Séquence de démarrage graphique Linux
Séquence initiale
Sous Linux, différentes classes de pilotes graphiques open source fonctionnent de manière très similaire. Le démarrage d'une distribution Linux pour PC, peut fonctionner sans recourir à aucun pilote spécifique à la puce graphique, car le gestionnaire de démarrage utilise des fonctionnélités génériques pour afficher des images, comme le Graphics Output Protocol (GOP) de l'UEFI, les pilotes d'extension du BIOS VESA (VBE) ou le mode texte VGA. Ce mode texte VGA est le même que celui qu'utilisait déjà le système DOS à la fin des années 1980.
Au travers des technologies VGA ou GOP le noyau affiche les premiers messages émis. Sur des systèmes modernes dotés de pilotes open source, le pilote graphique peut déjà être chargé en mémoire à partir du système de fichier initramfs chargé dès le démarrage du noyau, c'est-à-dire avant de pouvoir accéder au système de fichiers racine et donc avant tous les traitements suivants. Les distributions Linux modernes pratiquent généralement ce chargement précoce du pilote graphique du noyau depuis ce système de fichier initramfs. Ce module du noyau s'appelle i915 pour le matériel Intel. Il prend en charge l'initialisation du matériel, la gestion de la mémoire et la validation des commandes qui envoient les pilotes OpenGL ou vidéo à la puce graphique.
Au démarrage, le pilote du noyau définit une résolution supposée optimale pour l'écran de sortie. Cette résolution est déduite des informations obtenues à partir d'une structure de données appelée EDID (Extended Display Identifier Data), obtenue de l'écran au travers du PPC (ou DDC?) (Display Data Channel).
La définition des paramètres d'écran par le noyau est appelée paramètre de mode basé sur le noyau (KMS). Les pilotes graphiques du noyau sont donc parfois également appelés pilotes KMS. Cependant, le terme « pilote DRM » est plus approprié quand les pilotes et la fonction KMS appartiennent au Direct Rendering Manager (DRM) du noyau Linux. Ce pilote DRM est créé à la fin des années 1990, environ une décennie avant le KMSc't Linux 2015, Server-Sicherheit, Distributionen mit Langzeit-Support, c't-Redaktion, 2015, 3957880467, page 77 sur 156, édition Heise Medien.
Séquence d'apparition
Lorsque le KMS définit la résolution de l'écran, l'écran s'assombrit brièvement et tous les messages émis jusqu'à ce point par le gestionnaire de démarrage ou le noyau disparaissent. Certaines distributions affichent une animation de démarrage à ce stade pour améliorer l'apparence de l'initialisation du système. Ceci est souvent pris en charge par le programme « Plymouth », qui utilise KMS, qui propose des fonctions de sortie d'images.
A ce stade, les capacités disponibles ne suffisent pas aux interfaces de bureau et aux programmes graphiques. Pour cette raison, le serveur X de X.Org démarre après l'initialisation de base du système. Il implémente le système X-Window (X11) et propose des fonctions et des interfaces avec lesquelles les applications peuvent créer une interface utilisateur et la transférer vers le serveur X. Il prend en charge la sortie via le matériel graphique et transmet les entrées, notamment souris et clavier, aux applications.
Précisions sur les pilotes de X-Windows Les distributions Linux ont toujours utilisé un serveur X sur PC comme base pour les interfaces utilisateur graphiques. La configuration X auparavant requise et souvent fastidieuse est désormais pratiquement inutile, car les serveurs X modernes chargent automatiquement tous les pilotes requis pour les périphériques d'entrée et le matériel graphique lors de leur démarrage. Sur Intel, il s'agit du pilote X intel_drv.so, qui sur Ubuntu se trouve dans le répertoire xorg/modules/drivers/ sous /usr/lib ; sur un Fedora x86-64, le répertoire se trouve dans /usr/lib64/.
A l'origine, les pilotes X couramment utilisés sur les PC contenaient tout le nécessaire pour définir la résolution de l'écran. De nos jours, ce n'est plus le cas: Ils ne contrôlent plus ce paramètre de mode utilisateur. Au lieu de cela, ils doivent demander au pilote DRM via les fonctions KMS de configurer l'écran comme le spécifie l'utilisateur; par exemple via les paramètres d'affichage des bureaux ou l'outil de ligne de commande xrandr, qui transmettent leurs souhaits au serveur X et aux pilotes via l'extension X Resize, Rotate and Reflect (RandR).
Le pilote X est également responsable de l'accélération vidéo via l'extension X Video (XVideo ou XV en abrégé) et la compensation de mouvement X-Video (XvMC). Cependant, ces deux fonctions sont rarement utilisées car elles ne sont pas adaptées aux formats vidéo HD modernes.
La fonction principale restante du pilote X est l'accélération 2D, grâce à laquelle le pilote délègue le mouvement du contenu de la fenêtre à la puce graphique. Ces dernières années, EXA (mais UXA chez Intel) a été principalement utilisé à cette fin. Glamour, utilisé depuis un certain temps par le pilote Radeon X, est plus récent et utilise le pilote 3D pour l'accélération 2D.
Cette approche prive les pilotes X de leur dernière tâche essentielle. Elle facilite la conception de pilotes spécifiques au matériel et peut même les rendre inutiles. Elle attire ainsi d'autres développeurs.
En , dans ce contexte, Glamour a été intégré à X-Server version 1.16.
Architecture logicielle thumb|alt=Illustration of differences between Gallium3D and Direct Rendering Infrastructure models|Mesa (DRI) and Gallium3D have different driver models, but they share free and open-source code. thumb|alt=Driver example matrix|An example matrix of the Gallium3D driver model. With the introduction of the Gallium3D tracker and WinSys interfaces, 18 modules are required instead of 36. Each WinSys module can work with each Gallium3D device driver module and each State Tracker module.
Un pilote open source de carte graphique est principalement développé pour des distributions Linux et fonctionnent sur des noyaux Linux. Ils sont développés par des tiers développeurs enthousiastes et des employés de sociétés comme Advanced Micro Devices. chaque pilote est composé de cinq parties: Un composant DRM dans le noyau Linux Un composant KMS driver (pour Kernel Mode Setting) dans le noyau Linux (le display controller driver)