Le point sur le traitement graphique sous Linux

Document original : « The State of Linux Graphics »

Après avoir arrêté le travail sur Xgl j'ai reçu beaucoup de courriers et j'ai lu beaucoup de billets. Ma conclusion est que la plupart des personnes ne savent pas vraiment comment se passe le traitement graphique sur Linux. Il est compréhensible que les gens n'aient pas une vue complète. Le traitement graphique est un secteur vaste et complexe avec beaucoup de composants logiciels et de groupes de développeurs en concurrence. J'ai écrit ceci dans une tentative d'expliquer comment toutes les pièces s'ajustent ensemble.

Historique

Cette année c'est le vingt et unième anniversaire du serveur X. Commencé en 1984 le projet Athéna a bien servi la communauté Unix au cours des années. X est largement utilisé et équipe aujourd'hui la plupart des bureaux Linux. L'article de Wikipedia donne beaucoup plus de détails mais les deux principales innovations de X sont l'open source, qui a permis le support multiplates-formes, et la transparence réseau.

Cependant, il s'est écoulé vingt ans depuis la conception de X et le matériel vidéo a changé. Si vous regardez le plan d'implantation d'une puce vidéo moderne, vous noterez une petite section marquée 2D. C'est parce que 90 % de la puce est consacré au pipeline 3D. Vous avez uniquement payé pour du matériel 3D alors ne serait-il pas bien si le bureau l'utilisait ? Un bon nombre de gens ne se rendent pas compte que le matériel 3D peut dessiner la 2D du bureau. Regardez votre écran, c'est une surface 2D plate, non ? Toutes les images générées par le matériel 3D terminent sur un écran 2D plat. Ceci devrait vous mener à la conclusion qu'une programmation appropriée du matériel 3D peut dessiner des bureaux 2D.

Les fabricants de puces graphiques

Il y a quelques années les fabricants de puces graphiques étaient fiers de communiquer les fiches techniques et de l'information sur la programmation de leurs matériels. Mais, pendant que les bibliothèques de brevets se développaient, la crainte de poursuites pour contrefaçon s'est aussi développée. Maintenant les fabricants de puces graphiques cachent toutes les informations sur leurs puces de manière à rendre plus difficile la recherche de contrefaçon par le titulaire d'un brevet. Du moins c'est le récit donné par les fabricants comme raison pour garder secrètes les spécifications de programmation. Ils prétendent également que des spécifications secrètes rendent plus difficile aux concurrents l'ingénierie inverse des puces, mais j'ai mes doutes à ce sujet aussi. Toutes ces spécifications secrètes rendent très difficile l'écriture de pilotes de périphériques open source pour ces puces. Au lieu de cela nous sommes forcés de compter sur les pilotes fournis par le fabricant pour les derniers matériels. Juste au cas où vous ne le sauriez pas, notez que les fabricants de puces graphiques ne s'intéressent vraiment qu'à MS Windows donc ils font le minimum qu'ils peuvent pour le support des pilotes sous Linux. Il y a des exceptions. Intel fourni des pilotes open source pour certaines de leurs puces. NVidia/ATI fournissent des pilotes propriétaires mais ils sont en retard sur les versions Windows. Globalement nous avons un ensemble très mitigé de pilotes allant d'une qualité décente à inexistante.

Les bureaux alternatifs

Les bureaux alternatifs, Windows et Mac, ont tous les deux des bureaux accélérés par le GPU. Ils sont manifestement, visiblement meilleurs que leurs prédécesseurs. Dans certains cas ces nouveaux bureaux accélérés peuvent afficher plus de cent fois plus rapidement que sur un ancien modèle. À un certain moment dans le futur les fabricants de puces graphiques vont supprimer cette partie minuscule étiquetée 2D et nous laisser uniquement avec du matériel 3D. Microsoft et Apple semblent avoir déjà reçu le message que la 3D est le chemin à suivre et ont fait la transition. D'autre part, plusieurs développeurs de X m'ont dit de cesser de parler du paysage concurrentiel. Ils disent que tout ce qu'ils veulent faire c'est rendre X meilleur. Alors que les développeurs de X ne se sentent pas concernés, je suis certain que des cadres de chez Red Hat et Novell ne seront pas d'accord avec cela quand ils commenceront à perdre du chiffre d'affaires à cause d'une interface utilisateur graphique non compétitive.

Utiliser la 3D pour le bureau n'est pas simplement fait pour le plaisir des yeux. Beaucoup d'effets plaisants produits par la 3D peuvent juste être superficiels mais il y a également des raisons valables pour l'usage de la 3D. La 3D est simplement plus rapide que la 2D, personne ne rend ses fonctions 2D plus rapides, toute la technologie silicium entre dans la 3D. Vous pouvez faire plus rapidement, par exemple, du traitement d'image pour des choses comme la color space conversion, des étirements rétrécissements/déformations, etc. J'ai vu du filtrage extrêmement complexe fait en temps réel avec du matériel shader qui prendrait au CPU principal plusieurs secondes par image à faire. La 3D permet aussi le support de fenêtres de profondeurs hétérogènes (des fenêtres 8, 16, 24 bits simultanées) avec des palettes de couleurs aléatoires, le flipping/rotation à la volée pour les appareils de projection, et la mise à l'échelle d'un écran entier pour les malvoyants, etc. L'indépendance de la résolution permet à des objets d'être rendus à une résolution/taille aléatoire et d'être sur/sous échantillonnés lorsqu'ils sont montrés à l'écran. Des applications plus intéressantes sont décrites plus tard dans la section fenêtrage.

Le serveur X.org actuel

X.org est sur le point de diffuser X11R7. La fonctionnalité primordiale de cette version est la modularisation du code source de X. Bien que la modularisation ne signifie rien à la plupart des utilisateurs, elle facilitera beaucoup le travail sur le code source de X. Avant la modularisation, l'arbre des sources de X renfermait environ 16 millions de ligne de code, toutes compilées dans un unique projet. Après la modularisation, l'arbre sera découpé en des douzaines de parties indépendantes, rendant le projet beaucoup plus facile à compiler et à comprendre.

X, le système d'exploitation

X est-il une application ou un système d'exploitation ? Une bonne référence pour comprendre comment est fait un serveur X se trouve ici, ça a 8 ans mais pour la majeure partie c'est encore pertinent. Lisez çà si vous ne savez pas ce que DIX, MI, DDX, CFB, etc. signifient. Un peu près à la séparation de X11R6.3 et Xfree86 la conception du serveur X a changé pour devenir extrêmement multiplates-formes. Les divers systèmes d'exploitation ciblés par X ont différents niveaux de support des choses comme la vérification du matériel. Pour traiter cela, X a ajouté du code pour sonder le bus PCI et trouver le matériel, du code pour trouver les ROM vidéo et les exécuter pour réinitialiser le matériel, trouver les souris et les claviers et fournir les pilotes, gérer les problèmes de périphériques VGA multiples pour finalement même fournir son propre chargeur de module. C'est à ce moment que X a commencé à brouiller la limite entre l'application et le système d'exploitation. Alors que certains environnements avaient éperdument besoin de ce support de type système d'exploitation, implémenter ces fonctionnalités sur un système d'exploitation qui fournissait les mêmes services, comme Linux, se résultait en fin de compte par les conflits actuels entre X et le système d'exploitation. Naturellement les systèmes d'exploitation ont changé leurs objectifs qui avaient un sens il y a dix ans et n'ont aucun sens aujourd'hui.

Le noyau Linux offre des sous-ensembles comme le PCI et le framebuffer qui ne sont pas présents sur BSD et quelques autres plates-formes. Dans l'intérêt du support multiplates-formes, le serveur X a réalisé des implémentations parallèles de ces sous-ensembles. Dans le passé il y en avait besoin mais sur les systèmes Linux actuels ceci a aboutit à ce que deux logiciels différents essayent de piloter le même matériel. Linux a de nombreux utilisateurs non-X du matériel vidéo dont le seul point d'interaction avec X est le noyau. Le noyau fournit beaucoup de mécanismes pour la coordination de ces utilisateurs ; les choses comme le sous-ensemble PCI, les pilotes d'entrée, la détection des connexions à chaud, et les pilotes de périphériques. Dans l'intérêt d'une coordination sur Linux, la meilleure solution est se servir des fonctionnalités offertes par le noyau et d'exécuter ces bibliothèques en doublon uniquement sur les autres plates-formes. Les pilotes fbdev et XAA sont un exemple typique des pilotes en doublon.

Linux a un excellent système pour les connexions à chaud et le système de traitement graphique doit vraiment commencer à l'utiliser. Les écrans peuvent être connectés à chaud depuis plusieurs sources. Il y a la connexion à chaud traditionnelle ; quelqu'un branche une nouvelle carte vidéo dans un châssis de connexion à chaud. Mais il y a d'autres manières non traditionnelles d'obtenir une connexion à chaud. Un autre utilisateur pourrait utiliser un écran que vous voulez attacher à votre groupe d'écran et quand il se déconnecte vous obtenez une connexion à chaud. Vous pourriez attacher un moniteur externe à un ordinateur portable et produire une connexion à chaud. Vous pourriez vous connecter sans fil à un mur d'affichage avec quelque chose comme DMX ou Chromium. L'USB est également une source de beaucoup de connexions à chaud. Un utilisateur peut connecter à chaud souris, tablettes, claviers, périphériques audio et même des adaptateurs graphiques. Le serveur X actuel n'en manipule aucun puisqu'il ne communique pas avec le système de connexion à chaud du noyau.

Un bureau Linux standard utilise un X rooted. Rooted signifie que X contrôle l'affichage au niveau supérieur du bureau et les fenêtres situées dessus. Cygwin/X, Directfb et Apple Darwin utilisent tous X en rootless. Ces environnements ont un autre système de fenêtrage s'occupant de l'affichage. Ces systèmes de fenêtrage hôte affichent le bureau principal et implémentent leurs propres API de fenêtrage. X peut être intégré dans un système de fenêtrage hôte comme ceux-ci en s'exécutant en mode rootless. Dans le mode rootless les applications X sont dessinées dans des tampons mémoire système. Aux moments adéquats, les fenêtres X sont synchronisées avec le système de fenêtrage hôte et leurs contenus sont affichés. X en rootless fournit également des protocoles pour transmettre les événements souris et clavier entre les deux environnements.

X Render

L'extension X Render. Au cours de l'année 2000 KeithP a déclaré le serveur X actuel incapable d'afficher clairement, du texte anticrénelé et a proposé l'extension X Render pour traiter le problème. X Render est la fonctionnalité coeur de X permettant des choses comme des polices attrayantes et à Cairo d'être implémenté sur le serveur X. X Render ajoute des opérateurs Porter-Duff au serveur X. Ces opérateurs permettent à des surfaces d'être combinées de manières diverses. Ils sont très similaires aux concepts d'OpenGL de textures et d'opérations sur les textures, mais ils sont similaires et ne sont pas exactement équivalent.

XAA

XAA, X Acceleration Architecture a été introduit dans XFree86 4.0. Pour parvenir à une portabilité multiplates-formes XAA implémente des pilotes 2D dans l'espace utilisateur sans utiliser les pilotes de périphériques du noyau. Les pilotes de l'espace utilisateur fonctionnent mais puisqu'il n'y a aucun pilote noyau le noyau Linux n'a aucune manière de dépister ce que X fait au matériel. X ne commence à fonctionner qu'une fois que votre système a démarré. Vous voudriez avoir un affichage pendant le processus d'initialisation au cas où quelque chose irait mal au démarrage de X, non ? L'initialisation de l'affichage sous Linux est implémentée avec des pilotes en mode texte (console), le plus connu étant VGAcon. Ainsi sous Linux vous finissez avec deux pilotes de périphériques, X et la console, tous deux essayant de contrôler le même matériel. La combinaison de XAA, de la console et des fonctionnalités du noyau Linux des terminaux virtuels peut provoquer un tas de conflits, mais davantage de précisions viendront par la suite.

EXA

EXA remplace les pilotes XAA 2D permettant au modèle actuel du serveur de fonctionner encore un moment. Il accélère l'extension X Render en fournissant de nombreux pilotes plus avancés et une API de gestion mémoire. EXA a été à l'origine présenté comme étant une solution pour tout matériel incluant le vieux matériel. Mais ce n'est pas vrai. Si le vieux matériel est sans matériel alpha blending requis pour accélérer le coeur du rendu il n'y a rien que vous puissiez faire, bien qu'EXA puisse pouvoir aider à améliorer les performances sur ces puces par une meilleure gestion de la mémoire vidéo. Ainsi finalement, le matériel EXA fonctionne un peu près sur le même matériel pour lequel nous avons des pilotes OpenGL existants. Des exceptions existent comme le nv et l'i128 où le matériel a des capacités 3D mais où aucun pilote OpenGL n'existe. Il y a également la préoccupation que EXA continuera à grossir et pour exploiter plus des capacités des puces 3D. Le sparadrap EXA fonctionnera pendant un moment mais ce n'est pas une solution à long terme. Un point essentiel à se souvenir est qu'EXA/Render reste uniquement un sous-ensemble de l'API générique OpenGL Mesa et dans quelque temps nous allons vouloir de plus en plus de fonctionnalités.

Cairo

L'objectif de Cairo est d'être une API de dessin 2D de qualité qui soit aussi bonne pour l'impression que pour les écrans. Il est conçu en gardant à l'esprit l'extension X Render et en implémentant le modèle d'imagerie du PDF 1.4. Les opérations intéressantes incluent le traçage et le remplissage de courbes de Bézier cubiques, la transformation et la composition d'images translucides, et le rendu des textes anticrénelés. La conception de Cairo est portable et permet des backends graphiques enfichables comme image, Glitz, PNG, PS, PDF, SVG, Quartz, GDI et la Xlib. Cairo a été en développement pendant environ deux ans maintenant et devrait voir son déploiement dans les prochaines versions de GDK et Mozilla. Le principal objectif de Cairo est de faciliter aux développeurs la production de graphiques 2D sophistiqués à l'écran pour ensuite pouvoir les imprimer facilement. Les backends enfichables permettent à une application d'utiliser le même code pour dessiner et imprimer.

Un des backends de Cairo, appelé Glitz, implémente Cairo en utilisant OpenGL. Il y a un bon article qui explique Glitz en détail. Puisque Cairo implémente le backend Xlib et OpenGL une comparaison des performances peut être faite directement entre la Xlib et l'OpenGL. Dans les tests de performance qui ont été publiés, OpenGL bat XAA dans tous les cas de figure allant de dix à cent fois plus vite. Cette grande différence de performance provient du fait que Glitz/OpenGL utilise le matériel 3D des puces graphiques. Comparer Cairo au-dessus de Glitz et de la Xlib est une bonne manière d'illustrer que le matériel 3D est parfaitement capable de dessiner des écrans 2D.

DRI et OpenGL

DRI, Direct Rendering Infrastructure, implémente OpenGL en coopération avec le serveur X. DRI a quatre composants fondamentaux. D'abord, libGL qui fournit l'API OpenGL et agit en aiguillage entre les multiples pilotes. Ensuite il y a la bibliothèque DRI spécifique au matériel qui programme les puces graphiques. Pour les fonctionnalités d'OpenGL non fournies par le pilote DRI vous avez besoin de l'implémentation d'un logiciel de rechange (fallback). La solution de rechange est fournie par Mesa. Notez que Mesa est une implémentation logicielle complète d'OpenGL. Une carte qui ne fournit aucune accélération peut encore implémenter OpenGL en se rabattant sur Mesa pour chaque fonction. Finalement, il y a DRM, le Direct Rendering Manager. Les pilotes DRM sont exécutés dans le noyau, gérant le matériel et assurant la protection de sécurité nécessaire.

Un aspect intéressant de DRI est la partie « direct » du nom. Chaque application utilisant DRI programme directement le matériel vidéo. C'est différent de X où vous envoyez des commandes de dessin au serveur et où le serveur programme le matériel pour vous. Le pilote noyau DRM coordonne les multiples utilisateurs pour empêcher les interférences. L'avantage de ce modèle est que l'affichage OpenGL peut avoir lieu sans temps système de permutation des processus et de transmission de données à un serveur de contrôle. Un inconvénient est que la carte graphique peut avoir à traiter beaucoup de changements de contexte graphiques. Les cartes des stations de travail semblent faire un travail décent avec cela, mais certaines cartes du commerce ne le font pas. Microsoft a déjà rencontré ce problème et exige un support du changement de contexte matériel poussé pour un matériel DirectX 10 efficace.

DRM implémente également le concept d'utilisateur maître avec plus de capacités que des utilisateurs normaux. Ces capacités supplémentaires permettent au périphérique graphique d'être initialisé et à la consommation des ressources du GPU d'être contrôlée. Le serveur X actuel, qui est exécuté en root, fonctionne comme le maître DRM. Il n'y a en réalité aucune réelle exigence que le maître DRM soit exécuté en root, et il y a une rustine préliminaire qui supprime cette exigence.

Quand une fonctionnalité manque au matériel, Mesa implémente la fonctionnalité en logiciel. Ceci s'appelle un software fallback. Les gens sont embrouillés avec ceci. Ils disent que leur OpenGL n'est pas entièrement accéléré et que leur serveur X l'est. Pensez à ça. Les deux pilotes fonctionnent sur le même matériel. OpenGL n'est pas entièrement accéléré parce qu'il offre beaucoup de fonctionnalités pouvant être accélérées alors que X en offre seulement quelques unes. Si vous recueillez les fonctionnalités qui sont dans les deux API des pilotes, elles seront probablement accélérées toutes les deux. Si elles ne le sont pas, commencez à programmer et allez corriger le pilote approprié.

Sécurité et root

Le noyau Linux contient environ 10 millions de lignes de code qui fonctionnent en root. Le serveur X contient 16 millions de lignes de code dont certaines sont exécutées en root. Si vous recherchez des trous de sécurité, où avez-vous le plus de chance ? Il n'y a aucune raison technique exigeant du serveur X de fonctionner en root. Au nom de la compatibilité multiplates-formes, le serveur X actuel fonctionne comme root afin de programmer le matériel vidéo depuis l'espace utilisateur. Linux a une solution pour çà. Vous placez le code privilégié dans un pilote de périphérique et exécutez l'application depuis l'espace utilisateur sans privilège. Le pilote de périphérique privilégié pour une carte vidéo moyenne s'exécute dans environ 100 Ko. C'est dans l'ensemble moins de code à auditer que 16 millions de lignes de code.

L'ancien matériel

N'importe quel matériel vidéo, même un bête adaptateur VGA, peut exécuter le serveur X, et par chance Mesa implémentera la totalité de l'API OpenGL en logiciel. La question est de savoir à quelle vitesse. Aucune programmation ne va transformer une carte VGA en ATI X850. Ce vieux matériel est bien servi par le serveur X actuel, mais de nouveaux systèmes sont conçus autour du nouveau matériel et ils peuvent mal s'exécuter sur du vieux matériel. Vous pourriez envisager d'améliorer votre matériel vidéo ; des cartes graphiques avec des performances OpenGL décentes peuvent être achetées neuves à 40 dollars et pour même moins d'occasion. Sinon, vous pouvez choisir de ne pas l'améliorer et de continuer à exécuter le même logiciel qui vous a bien servi dans le passé.

Le support du traitement graphique par le noyau

Dès que le noyau commence à s'initialiser, vous voyez la console d'initialisation. Sur x86, la console d'initialisation la plus courante est VGAcon. VGAcon utilise le support du matériel VGA historique de votre carte graphique. Puisque la majorité des cartes graphiques x86 supportent VGA, VGAcon fournit une console universelle pour cette plate-forme. Sur les plates-formes non-x86 vous ne pouvez pas avoir le support du matériel VGA. Sur ces plates-formes, vous chargez généralement un pilote framebuffer spécifique à la puce. Le noyau propose de nombreux pilotes fbdev ainsi une gamme très large de matériel est supporté.

Le VGA historique

La conception originale du PC d'IBM a quelque peu limité la localisation de l'ensemble des périphériques à des adresses fixes et bien connues, par exemple COM1 à 0x3F8. Malheureusement, le support du VGA de la plupart des cartes graphiques est l'un de ces périphériques historiques localisés à une adresse fixe. Aussi longtemps que vous n'avez qu'une seule carte graphique sur votre système, VGA n'est pas un problème. Branchez en une seconde et maintenant vous avez deux matériels voulant tous les deux occuper le même bus d'adresse.

Le serveur X actuel possède du code pour le traitement de nombreux adaptateurs VGA. Mais ce code du serveur X n'a pas conscience des autres utilisateurs de ces périphériques et il les vira tous. Virer ces autres programmes n'est pas convenable, ainsi nous avons besoin d'une méthode pour coordonner plusieurs utilisateurs de périphériques VGA. Sur Linux la meilleure solution pour ceci est d'ajouter un mécanisme d'arbitrage du VGA au noyau. BenH avait travaillé sur celui qui avait été discuté au OLS.

Un autre problème est l'initialisation de plusieurs cartes vidéo. Les cartes vidéo ont des ROM, souvent désignées sous le nom de VBIOS, qui sont exécutées au démarrage pour l'initialisation du matériel. En raison de problèmes historiques, plusieurs de ces initialisations se servent du support VGA. Puisque nous ne pouvons avoir qu'un unique périphérique VGA historique, le BIOS système se débarrasse du problème et initialise uniquement la première carte vidéo. Il est possible d'initialiser les cartes secondaires à un moment ultérieur du démarrage. Ceci est réalisé en exécutant le VBIOS secondaire en utilisant le mode vm86 et en combinant l'utilisation d'un seul périphérique VGA historique. Pour rendre le sujet plus compliqué il existe deux formats de ROM répandus le code x86 de et l'Open Firmware. Puisque les fabricants facturent beaucoup plus leurs modèles Open Firmware il est courant à des personnes d'utiliser du matériel vidéo x86 sur des machines non-x86. Pour faire ce travail le VBIOS doit être exécuté en utilisant un émulateur x86. BenH travaille à une solution pour ce problème également.

Fbdev, est également désigné sous le nom du framebuffer. Sous Linux, le framebuffer est principalement responsable : d'initialiser le matériel, de détecter les attached displays, leurs modes valides, de régler le mode et la configuration du scanout (ndt : le scanout est l'envoi du tampon graphique VRAM au moniteur via un CRTC), du curseur matériel, des intervalles de trame (blanking), de la table des fausses couleurs, du panning (ndt : changement de l'origine de l'écran en modifiant le pointeur de la mémoire vidéo) et de l'interruption-reprise (suspend-resume). Il y a beaucoup de pilotes framebuffer dans le noyau et ils implémentent divers états du support de ces fonctionnalités. Notez que tandis que l'interface vers fbdev s'appuie sur le noyau, il n'y a rien qui empêche le support de fbdev d'avoir des applications auxiliaires dans l'espace utilisateur. Des applications auxiliaires pourraient être utilisées pour faire des appels au VBIOS dans des situations où le code source n'est pas disponible.

Quand vous exécutez un VBIOS il crée un ensemble de points d'entrée à un niveau très bas qui peut être utilisé pour commander l'affichage. Cela devient très détaillé et je n'expliquerai pas toutes les différences entre VGA, Int10 et VESA. Pour donner un aperçu,VGA donne les des registres matériels de base standards établis par IBM. Int10 se réfère à l'utilisation d'interruptions logicielles pour exécuter les sorties d'affichage. Les interruptions logicielles fonctionnent uniquement en mode réel x86, et ne sont généralement plus utilisées excepté par des choses comme GRUB. Le code pour supporter Int10 vient du VBIOS et est installé quand la ROM est exécutée. Il peut seulement y avoir un pilote Int10 installé. VESA a pris le modèle Int10 et l'a étendu pour fonctionner en mode protégé. En configurant le noyau il existe trois pilotes : VGA et VESA fbdev, qui a également besoin que fbconsole soit chargé pour fonctionner, et VGAcon qui est toujours inclus. Sur un non-x86 vous avez généralement besoin de fbdev et de fbconsole.

Faire fonctionner le multiutilisateur

Linux est un système d'exploitation multiutilisateur. Cela toujours été le cas. Mais la seule manière de connecter plusieurs utilisateurs a été par lignes séries et réseau. Que se produit-il si vous installez plusieurs cartes vidéo et exécutez plusieurs utilisateurs localement ? Cela ne fonctionne pas. Il y a eu des rustines pour essayer et réaliser cette fonction comme le projet console Linux et divers hacks de X. Le problème est que le système de terminal virtuel de la console Linux contrôle les cartes vidéo locales et ne supporte efficacement et uniquement qu'un seul utilisateur. Notez que fbdev fonctionne très bien lorsqu'il est utilisé par plusieurs utilisateurs, c'est le système de terminal virtuel qui est mono-utilisateur.

Plusieurs utilisateurs locaux ont une application dans des endroits comme des écoles, systèmes de surveillance, Web cafés et également à la maison. La demande passée du support de plusieurs cartes vidéo n'a pas été très forte dû au fait qu'un PC ordinaire ne supportait qu'un slot AGP. De nombreuses cartes vidéo PCI peuvent fonctionner mais leurs performances ne sont pas élevées. Il y a des machines haut de gamme avec plusieurs slots AGP mais elles ne sont pas très répandues. Le PCI express va changer cela. Avec le PCI express, toutes les slots sont fonctionnellement équivalents. La seule chose qui change est le nombre liens attribués à chaque slot. Ce changement de matériel facilite la réalisation de systèmes avec plusieurs cartes vidéo à haute performance. On prévoit des puces PCIe qui pourront autoriser jusqu'à seize cartes vidéo dans un seul système.

Fractionner la console

En analysant le système de console vous remarquerez aussitôt qu'il y a deux niveaux différents d'utilisation de la console. La console système, qui donne l'affichage au démarrage et est utilisée pour le rapport des erreurs systèmes, la remise en état et la maintenance. Et la console utilisateur, un affichage normal dans lequel un utilisateur ouvre une session et exécute ses activités en ligne de commande ou d'édition. Dans le système de console de Linux actuel, les deux utilisations sont desservies par le même code de la console.

Il est possible de fractionner le code de la console selon le type d'utilisation et de corriger beaucoup des problèmes actuels de la console Linux. Pour commencer, la console système devrait être totalement fiable et inviolable. Elle ne doit pas être rapide. Elle doit être implémentée avec le code le plus simple possible et elle doit fonctionner pendant le temps d'interruption et depuis les kernel panics. Des utilisations incluent des techniques de remise en état du système et un mode utilisateur simple. L'affichage pendant le démarrage et le support d'un kdbg sont également possibles. La console système devrait fournir SAK et l'ouverture de sessions sécurisées. Pour supporter des utilisateurs indépendants connectés à chaque head d'une carte vidéo elle doit être implémentée indépendamment sur chaque head. Une façon d'accéder à la nouvelle console système serait d'utiliser les combinaisons de touches d'appel système (SysReq), la console recouvrira votre affichage en cours et utilisera votre mode vidéo courant. Le débogueur noyau de Novell fonctionne de cette façon. La console système ne supporte pas les terminaux virtuels et il n'y a pas de permutation de console. Puisqu'elle connaît votre mode vidéo, elle peut s'approprier votre affichage en cas d'urgence, par exemple un oops fatal du noyau.

La conception de la console système utilise fbdev pour dépister le mode et où est localisé le tampon scanout. Pour la rendre aussi fiable que possible, tout support d'accélération est enlevé. Fbconsole utilise alors le CPU du système pour manipuler directement le framebuffer. La console est affichée en dessinant directement dans le tampon scanout en utilisant le support de la police bitmap existante dans la fbconsole.

La console utilisateur est à l'opposé de la console système, elle doit avoir des performances élevées et doit être facile à utiliser. Une implémentation dans l'espace utilisateur facilite le traitement de plusieurs utilisateurs en créant un processus pour chaque utilisateur. L'espace utilisateur permet la pleine accélération basée sur le GPU par l'intermédiaire du fbdev et du DRM. Vous avez également un accès facile à Xft/FreeType pour le support complet de l'Unicode. Avec une conception appropriée la console peut même permettre différents utilisateurs sur chaque head. En codant les raccourcis-clavier appropriés, elle peut être faite pour se comporter comme les VT existants et supporter la permutation des consoles.

Puisque les consoles actuelles sont combinées, quand vous permutez de VT vous obtenez les deux types. Dans le nouveau modèle de VT, les touches de permutation vous donneraient des consoles de l'espace utilisateur. SysReq activerait la console système. Le processus shell attaché à la console système pourra fonctionner en haute-priorité facilitant la reprise de contrôle depuis un processus errant.

Grouper le matériel

Le support de plusieurs utilisateurs locaux suppose que Linux implémentera le concept des groupes de consoles pour les périphériques dédiés aux interfaces utilisateurs. Les groupes de consoles sont des collections de matériel qui vont, ensemble, former une console d'ouverture de session. Un exemple de groupe inclurait un affichage, une souris, un clavier et un périphérique audio. À l'ouverture de la session, PAM assigne la possession de ces périphériques à l'utilisateur connecté. Une adjonction intéressante à ce concept serait d'inclure un hub ou un port USB en tant qu'élément du groupe de consoles. Tant que l'utilisateur est connecté, quelque chose branché au port USB lui appartient également. À la déconnexion tout retourne dans le pool non affecté.

Solutions de rechange possibles

Les petits gars de : directfb, svglib, Fresco, Y Windows, FBUI, etc. Linux attire un bon nombre de gens qui veulent s'expérimenter avec le code d'affichage. Dans le modèle des VT actuels ces autres systèmes affichage provoquent beaucoup de problèmes dans la permutation des VT. Après la permutation d'un VT, le système d'affichage nouvellement activé est autorisé à faire tout ce qu'il veut au matériel. Cela inclut le réinitialiser, le reprogrammer et effacer sa VRAM. Quand vous permutez à nouveau, le système original s'attend à retrouver en état un matériel modifié. Il n'y a pas simplement les petits gars qui peuvent poser des problèmes avec la permutation des VT. Vous pouvez permuter entre la console système et X ou même entre deux bureaux comme X et Xegl. C'était probablement un modèle satisfaisant pour des adaptateurs VGA avec 14 registres et 32 Ko de VRAM. Ce n'est pas un bon modèle pour une carte vidéo avec 300 registres, 512 Mo de VRAM et un coprocesseur GPU indépendant.

Coopérer efficacement

Je crois que la meilleure solution à ce problème est que le noyau fournisse un pilote de périphérique simple et complet pour chaque matériel vidéo. Ceci signifie que des pilotes en conflit comme fbdev et DRM doivent être fusionnés dans un système de coopération. Cela signifie également qu'accéder en écriture à un matériel depuis l'espace utilisateur alors qu'un pilote de périphérique du noyau est chargé ne devra plus être possible. Je suspecte que si Linux offrait des pilotes complets pour les diverses cartes vidéo, une grande partie du désir de réaliser encore une autre version du pilote Radeon disparaisse.

Ceci ne signifie pas que des projets comme Fresco ne peuvent pas développer leurs propres pilotes de périphériques pour le matériel vidéo. Tout cela signifie que vous devrez décharger le pilote standard et puis charger votre pilote spécifique avant d'exécuter le nouveau programme. Ce comportement de décharger/charger n'est pas différent de celui de chaque autre pilote noyau. L'utilisation d'un raccourci-clavier pour sauter (permuter de VT) entre deux pilotes de périphériques vidéo actifs pour le même matériel ne serait plus supporté. Si un pilote de base n'a pas les fonctionnalités nécessaires une meilleure approche serait de soumettre des rustines au pilote standard. En implémentant les extensions nécessaires dans le pilote standard tous les programmes peuvent les partager et il serait facile de permuter entre les applications en les utilisant avec le système de console de l'espace d'utilisateur.

Si nous tenons à garder dans la conception des VT un raccourci-clavier pour sauter entre les pilotes vidéo, je pense qu'il serait juste d'implémenter un raccourci clavier pour sauter entre les pilotes disque et réseau.

OpenGL|ES

Le groupe Khronos est un nouveau groupe de normalisation constitué par plus d'une centaine de sociétés membres. Le standard le plus réussi du groupe Khronos est OpenGL ES. OpenGL ES définit un sous-ensemble très utile d'OpenGL dédié aux systèmes avec peu de mémoire. Il définit également EGL lequel est un équivalent indépendant de la plate-forme aux API OpenGL GLX/AGL/WGL. « EGL fournit des mécanismes pour créer des surfaces de rendu sur lesquelles des API clientes comme OpenGL ES et OpenVG peuvent dessiner, créer des contextes graphiques pour des API clientes, et synchroniser le dessin par des API clientes aussi bien que pour des API de rendu native à la plate-forme. Ceci donne une solution intégrée de rendu utilisant à la fois OpenGL ES et OpenVG pour un rendu accéléré de haute performance des modes 2D et 3D combinés. »

EGL assume l'existence d'un système de fenêtrage fourni par d'autres parties du système d'exploitation. Mais la conception d'EGL est indépendante de la plate-forme et rien dans l'API EGL n'est spécifique à un système de fenêtrage contrairement à GLX/AGL/WGL. Toutes les références à un système local de fenêtrage sont manipulées avec des pointeurs opaques.

Les développeurs de Mesa ont échafaudé une proposition pour étendre EGL de sorte qu'un système de fenêtrage puisse être implémenté au-dessus d'EGL. Le coeur de cette extension fournit une API pour énumérer les écrans disponibles, initialiser les modes et les configurations framebuffer d'un écran, déplacer l'écran, et interroger des attributs. Deux secteurs qui doivent toujours être traités par des extensions EGL incluent le support du curseur matériel et la palette de couleur. Ajouter ces extensions à EGL fournit assez de contrôle matériel pour implémenter un serveur et un système de fenêtrage comme Xegl. OpenGL plus EGL et les extensions Mesa fournissent une API véritablement portable pour accéder à plusieurs classes de matériels graphiques allant des téléphones cellulaires actuels aux Playstation 3, des PC aux superordinateurs graphiques.

L'API EGL étendue corresponds bien à Linux. Elle fournit une base solide pour construire des systèmes de fenêtrage ou des applications embarquées. Il est facile de l'employer pour en faire une plate-forme amusante pour la R & D et l'expérimentation. Elle vous laisse vous concentrer sur votre nouvelle application ou système de fenêtrage et oublier toutes les complexités du traitement avec le matériel.

Je crois que le groupe Khronos représente une opportunité inexploitée majeure pour les communautés X.org et du traitement graphique sous Linux. La plupart des normes Khronos sont dépourvues d'implémentations de référence en open source, de support de système de développement, et de tests de conformité. Plusieurs alliés du groupe Khronos vendent des systèmes de production basés sur Linux. Si X.org devait augmenter sa charte, il pourrait approcher le groupe Khronos pour être un vecteur neutre sans but lucratif pour réaliser des implémentations en open source de référence et des systèmes de développement basés sur Linux et les standards Khronos. L'association permettrait aux membres du groupe Khronos de faire un don de charité à X.org similaire à IBM et à la fondation Eclipse.

Le pixel parfait

L'exactitude parfaite du pixel est un mythe. Tout ce que vous pouvez faire doit réaliser des degrés d'exactitude. Les sources des erreurs sont partout. La régularité du rétroéclairage de votre écran à cristaux liquides, la consistance de l'encre de l'imprimante, la qualité des DAC, le pouvoir réfléchissant du papier, les problèmes avec le contretypage des couleurs, les différents algorithmes de dessin implémentés dans les GPU, etc. OpenGL ne garantit pas l'exactitude parfaite du pixel entre les implémentations. Le plus proche que vous pouvez obtenir dans la perfection du pixel est d'utiliser exactement la même version du logiciel Mesa sur chacune de vos cibles. D'ailleurs, le serveur X n'est pas précis au pixel non plus. Mon principe de base est que s'il faut prendre une loupe pour voir la différence alors c'est assez fidèle. Les gens s'y perdent à ce point. Si vous remettez à OpenGL un bitmap à afficher il va copier ces pixels à l'écran sans changement à moins que vous lui disiez de les changer. L'argument de la précision du dessin des pixels s'applique plus aux choses vectorielles à taille variable comme des lignes.

L'anticrénelage amélioré des polices n'est pas un problème, OpenGL offre plusieurs solutions pour afficher l'anticrénelage amélioré des polices. Si vous le choisissez, OpenGL est capable d'utiliser exactement le même mécanisme pour l'affichage des glyphes que le serveur X utilise aujourd'hui. Puisque c'est le même mécanisme, les glyphes sembleront identiques. Il est également indésirable de verrouiller le dessin à un algorithme spécifié, le faire est entraver la progression vers l'avant. Par exemple, cet article (vidéo) explore une manière complètement nouvelle de produire des polices avec le GPU. Il existe un autre papier intéressant, « Resolution Independent Curve Rendering using Programmable Graphics Hardware » par Loop et Blinn, compte-rendu du SIGGRAPH 2005. Si le dessin des polices était spécifié avec une précision parfaite au pixel, il serait probablement impossible d'utiliser ces nouvelles techniques. Ces glyphes sont produits par le GPU et utilisent des algorithmes qui sont élaborés dans le matériel et ne sont pas modifiables par l'utilisateur. Convertir les contours des glyphes en pixels afin de les rendre comme des images fondues est simplement une manière d'afficher des glyphes. Les GPU programmables fournissent de nouvelles solutions de rechange. N'importe quelle API qui a une longue durée de vie devrait tenir compte de ceci.

Trois générations de fenêtres

Dans le serveur X actuel et beaucoup d'autres systèmes de fenêtrage, des fenêtres sont dessinées à l'écran dans des régions de cadrage (clip regions) en utilisant l'algorithme du peintre. L'algorithme du peintre fonctionne simplement comme de la vraie peinture — chaque couche successive obscurcit la couche précédente. Vous dessinez d'abord le fond et dessinez ensuite chaque fenêtre dans l'ordre Z inversé. S'il n'y a aucune translucidité et que vous savez où vont toutes les fenêtres, vous pouvez optimiser cet algorithme (comme X) avec des rectangles de cadrage de sorte que chaque pixel à l'écran soit seulement affiché une fois. Les performances peuvent être améliorées par le pistage des dommages. Seules les fenêtres dans la surface endommagée doivent être redessinées et le reste de l'écran est protégé par des régions de cadrage. D'autres gains sont faits par la « sauvegarde du fond ». Le système de fenêtrage remarque que des choses comme des fenêtres contextuelles affichent le même contenu à l'écran une fois écartées. Une « sauvegarde du fond » sauve l'écran sous ces fenêtres contextuelles et le remplace une fois fait.

Le mode composite tire profit des améliorations de performance du matériel récent. Avec le mode composite, des fenêtres sont dessinées en dehors de l'écran, dans la mémoire vidéo non visible. La composition d'images utilise toujours l'algorithme du peintre, mais puisque le gestionnaire de fenêtre a toujours tous les contenus des fenêtres, il est possible d'implémenter les fenêtres translucides. La translucidité est créée en mélangeant le contenu de l'écran sous la fenêtre avec le contenu de la fenêtre précédente pendant qu'elle est copiée dans la mémoire tampon scanout. Ceci s'appelle alpha blending. La plupart du matériel moderne le supporte. On élimine également le clignotement de dessin par double tampon. Dans ce modèle, tout est toujours en 2D et a un ordre Z simple.

Un matériel multitexture plus haut de gamme peut éviter d'utiliser totalement l'algorithme du peintre. Chaque fenêtre en intersection avec la région concernée de l'écran serait confinée dans une texture indépendante. Vous dessineriez alors des polygones à l'écran représentant les fenêtres. Ces polygones auraient des coordonnées de texture appropriées aux sommets des polygones de chaque fenêtre/texture, puis le matériel combinateur des textures combinerait toutes les fenêtres/textures ensemble et produirait le résultat attendu. Dans un cas extrême, l'écran entier pourrait être redessiné en faisant le rendu d'un seul rectangle multi-texturé ! Cette technique est extrêmement rapide, vous ne devriez même pas avoir besoin de double tampon puisque le clignotement est minimal. La multi-texturation d'un bureau complet est probablement au-delà du matériel d'aujourd'hui, mais c'est un secteur qui s'améliore rapidement à chaque génération de matériel.

Xgl implémente le modèle du mode composite. Bien que non requis, Xgl se servira d'une nouvelle fonctionnalité d'OpenGL, les objets framebuffer. Avec une extension d'OpenGL, les FBO permettraient le partage très efficace des offscreen des fenêtres des applications avec le gestionnaire de fenêtres. L'extension n'est pas sorcière, nous partageons déjà des pbuffers à travers des processus. À une application, un FBO a l'apparence d'une fenêtre de dessin normale. Au gestionnaire de fenêtres, les fenêtres ressemblent à des textures et peuvent être manipulées avec des commandes de dessin normales comme le multitexture. Dans ce modèle les fenêtres des applications sont toujours en 2D, mais maintenant il est possible d'écrire un gestionnaire de fenêtres basé sur OpenGL comme Luminosity. Un gestionnaire de fenêtres basé sur OpenGL peut combiner des fenêtres en utilisant un z-buffer et supprimer les limites de l'ordre Z strictement 2D. Par exemple, une fenêtre peut être transformée en vague et à plusieurs reprises entrecroiser une autre fenêtre.

Enfin, vous pouvez supprimer les limitations 2D des fenêtres des applications et leur donner une épaisseur ou d'autres formes 3D. Par exemple, un menu contextuel pourrait vraiment instantanément avoir les coordonnées 3D les plus élevées. Quand vous combinez ceci avec une source lumineuse, les ombres portées apparaissent naturellement au lieu d'être construites artificiellement comme en 2D. Le projet Looking Glass de Sun est ce type de gestionnaire de fenêtres. L'épaisseur des fenêtres est démontrée dans la vidéo démo de Looking Glass. Looking Glass exécute des applications existantes de X à l'aide d'un serveur X en rootless. Les fenêtres et l'épaisseur alors donnée en combinaison avec de vraies applications 3D comme la démo du changeur de CD.

Le concept d'un bureau 3D n'est pas si insolite. Nous avons eu un bureau 3D depuis que nous sommes passés des fenêtres en mosaïque de Windows 1.0 à celles en chevauchement — une fois la profondeur introduite le bureau est devenu un espace 3D sans perspective. Les concepts 3D sont partout sur le bureau, regardez les menus et les fenêtres contextuelles. Une excellente raison d'implémenter le mode composite était de fournir les ombres portées, qui sont évidemment une représentation 2D d'un espace 3D. Même des commandes comme des boutons sont faites pour sembler être en 3D via une simulation 2D. Pourquoi ne pas dessiner cela en 3D et ne pas laisser l'utilisateur placer la source lumineuse ? La translucidité des fenêtres implique évidemment des concepts 3D. Pourquoi n'admettons-nous pas simplement que le bureau est un espace 3D et utiliser le traitement graphique 3D pour le dessiner ?

Tracer la frontière

Il y a eu quelques débats à ce sujet. Linux n'a réellement qu'une seule option pour faire une transition open source à un bureau basé sur le GPU — l'implémentation OpenGL de Mesa. Nous pourrions certainement reproduire DirectX, mais qui va écrire tout ce code et les pilotes ? OpenGL n'est pas un mauvais choix. Il nécessite de l'avoir sur Linux peu importe ce que nous réalisons. Il est normalisé et contrôlé par un ARB. Il est bien conçu et bien documenté. Il est largement diffusé et utilisé. Les universités l'enseignent et beaucoup de livres ont été écrits à son sujet. D'excellentes applications et jeux fonctionnent avec OpenGL.

À quelle hauteur doit-on tracer la frontière du pilote de périphérique graphique ? XAA et fbdev tracent la frontière à un niveau bas. Ces API s'occupent elles-mêmes des pixels dans le framebuffer, des opérations sur les zones des images bitmap, et peut-être du tracé de lignes. Toutes les fonctionnalités offertes par les puces graphiques à ce niveau ne sont pas non plus accessibles ou nécessitent des échappatoires à l'API spécifiques à la puce pour y accéder. L'implémentation de Xgl trace la frontière d'une manière très différente. La frontière est tracée à un niveau extrêmement élevé de l'API OpenGL elle-même. Je crois que l'approche Xgl est le meilleur choix. Vous avez besoin de tracer la frontière au-dessus du jeu des fonctionnalités actuellement implémenté dans le silicium afin de permettre à la pièce de silicium d'évoluer sans perturber l'API. Je ne crois pas que Linux tirerait avantage à exécuter un bon nombre d'API comme DirectX. Le meilleur modèle doit commencer à un niveau vraiment élevé, fournir l'implémentation logicielle de référence, Mesa, et puis remplacer des parties de Mesa par des implémentations accélérées par le matériel, DRI. Nous avons également plusieurs implémentations d'OpenGL : Mesa, Nvidia et ATI. Ce que vous utilisez dépends de votre choix, croyez le ou non certaines personnes apprécient les pilotes propriétaires.

Xgl a été conçu comme une solution de transition à court terme. Le modèle de Xgl devait remplacer d'une manière transparente le système de tracé du serveur X existant avec un serveur compatible s'appuyant sur l'utilisation d'OpenGL comme pilote de périphérique. Xgl maintient toutes les API X existantes en tant qu'API primaires. Aucune nouvelle API X n'a été proposée et aucune n'a été désapprouvée. Xgl se fonde sur un code mutli-plate-forme de haut niveau. C'est est un code générique et il doit être porté sur un environnement OpenGL spécifique. Un port, Xglx, existe pour l'API GLX. Un autre port, Xegl fonctionne sur l'API multiplates-formes EGL. Notez qu'EGL est une manière indépendante de la plate-forme d'exprimer les API GLX, AGL et WGL. Avec les extensions Mesa, EGL peut contrôler le framebuffer de bas niveau. Cette combinaison fournit tout le nécessaire pour implémenter un système de fenêtrage (comme le serveur X actuel) sur du matériel vidéo dépouillé. Mais Xgl était une conception de transition à court terme, en retardant le besoin de Xgl le sparadrap EXA enlève une grande partie de sa nécessité.

Un argument qui est avancé encore et encore est que nous ne devrions pas utiliser OpenGL en raison de tout l'ancien matériel en service dans les pays en voie de développement. Il y a deux solutions à ce problème. D'abord, OpenGL est une API extensible. Par l'intermédiaire de solutions de rechange logicielle (fallbacks) elle est capable de fonctionner sur le plus petit matériel. OpenGL ES fournit également des profils d'API. Les profils sont des sous-ensembles bien définis de l'API OpenGL. Si nécessaire nous pourrions définir un profil minimum couvrant la plus petite API OpenGL possible. La taille du code ne devrait pas être un problème, une implémentation propriétaire d'OpenGL ES de 100 Ko est disponible. Un profil OpenGL supplémentaire ne nécessite pas un support de la virgule flottante. Rien n'empêche de réaliser des équivalents en open source si nous choisissons d'y consacrer les ressources.

L'autre argument est simplement d'exécuter du logiciel qui a été conçu pour fonctionner sur le matériel en service. Personne ne s'attend à ce qu'un IBM PC fasse fonctionner Windows Longhorn mais le même PC continue à faire fonctionner DOS sans problème.

Le point essentiel ici est qu'OpenGL est plus extensible qu'EXA. L'extensibilité d'EXA est incomplète au plus haut point, elle ne couvre pas des fonctionnalités avancées du GPU comme la 3D et la programmabilité. Avec OpenGL il est possible d'avoir une seule API pour tout : du téléphone cellulaire au superordinateur.

L'empilement des blocs

C'est beaucoup d'acronymes à digérer d'un seul trait. Que diriez-vous de quelques exemples sur la façon dont les bibliothèques fonctionnent ensemble :: App -> GTK+ -> X -> XAA -> hw
C'est le serveur X actuel. L'application parle au toolkit qui utilise l'API Xlib du serveur X. Le serveur X dessine sur le matériel avec les pilotes XAA actuels. X et l'application sont dans deux processus différents.: App -> GTK+ -> Cairo -> X Render -> X -> XAA/EXA -> hw
Le toolkit utilise la nouvelle bibliothèque Cairo. Cairo dépend de X Render. Si EXA est disponible X Render est accéléré. X et l'application sont dans deux processus différents.: App -> QT -> Arthur -> X Render -> X -> XAA/EXA -> hw
Arthur est l'équivalent de Trolltech de Cairo, il se comporte à peu près de la même manière.: App -> GTK+ -> Cairo -> Glitz -> GL -> hw
Le toolkit utilise la nouvelle bibliothèque Cairo. Cairo sélectionne le backend Glitz pour OpenGL qui s'appuie sur un rendu direct. Tout est accéléré et tracé par un simple processus dû à un rendu direct en OpenGL.: App -> GTK+ -> Cairo -> X Render -> Xgl -> EGL (autonome) -> GL -> hw
Dans ce cas-ci, le toolkit sélectionne le backend Xlib de Cairo qui parle au serveur Xegl via X Render. Xegl utilise Glitz pour fournir sa propre implémentation du rendu. Glitz sera rendu directement par le matériel. Xegl et l'application sont dans deux processus différents. Notez que le toolkit aurait pu choisir d'utiliser Glitz directement et de faire un rendu direct depuis un seul processus.: App -> GTK+ -> Cairo -> X Render -> Xgl - > GLX (X) -> GL -> hw
Le toolkit parle encore X Render au serveur Xglx. Xglx n'est pas un serveur autonome, c'est un serveur imbriqué. Xglx n'est pas un serveur imbriqué normal, il utilise l'imbrication pour les entrées mais il dessine la totalité de son bureau à l'intérieur d'une seule fenêtre OpenGL fournie par le serveur parent. Si vous passez en plein écran, vous ne verrez plus le serveur parent. Il y a trois processus, l'application, Xglx et le serveur X. Le tracé se produit entre l'application et Xglx dus à Xglx qui utilise le rendu direct. Le troisième processus, le serveur X est impliqué puisqu'il fournit la fenêtre et les entrées. Il accueille également l'application Xglx.

Une future direction

Linux est maintenant garanti d'être le dernier bureau majeur à implémenter une interface utilisateur graphique de bureau qui tire pleinement avantage du GPU. Étant donné qu'il n'y a plus de contrainte de temps, peut-être qu'une solution à plus long terme est appropriée. Nous pourrions concevoir un nouveau serveur basé autour d'OpenGL et de Cairo.

Généralement, l'intégralité du concept de matériel graphique programmable n'est pas traité par les API comme la Xlib et Cairo. C'est un point très important. Une nouvelle fonctionnalité importante de la GPU, la programmabilité, n'est simplement pas accessible avec les API actuelles de X. OpenGL expose cette programmabilité par l'intermédiaire de son langage Shader.

Dans le cas d'un nouveau serveur soyez sûr de séparer le modèle conceptuel en deux composants : le spécifique à la plate-forme et l'indépendant de la plate-forme. Les pilotes de périphériques sont spécifiques à la plate-forme, dans le modèle proposé OpenGL est considéré comme un pilote de périphérique donc il aura une implémentation spécifique à la plate-forme. Tous les problèmes de l'intégration avec d'autres sous-ensembles de Linux seront cachés à l'intérieur des pilotes appropriés. Le serveur principal sera implémenté en utilisant des API multi-plates-formes comme les sockets, OpenGL et EGL. Une API muti-plate-forme pour des périphériques connectables à chaud devra être spécifiée. Le serveur n'aura pas besoin d'être conçu à partir de zéro. D'importantes portions de code pourront être réutilisées d'autres projets et être combinées d'une nouvelle manière. De ce que je peux voir, 95 % du code nécessaire à un nouveau serveur existe déjà.

La modularisation est essentielle à la réalisation d'un bon serveur. La conception devrait être séparée en bibliothèques isolées qui communiquent par l'intermédiaire d'interfaces standard. Séparer les choses de cette manière facilite le remplacement d'une bibliothèque. Vous pouvez avoir des implémentations complètement différentes d'une bibliothèque sur diverses plates-formes, ou il peut y avoir différentes manières d'implémenter la bibliothèque sur une seule plate-forme. Naturellement, le code multiplates-formes a ses avantages. Des choses comme la bibliothèque Mesa peuvent être partagées par tous les systèmes cibles.

Vous souvenez-vous de la manière dont DirectFB utilise X en rootless ? Le nouveau serveur pourrait exécuter X en rootless avec un rendu logiciel pour garder la compatibilité historique. Le modèle de rendu direct de DRI est une bonne conception et devrait être retenu dans de futurs serveurs. Migrer X dans un mode historique permet une liberté complète dans une nouvelle conception d'un serveur.

Par exemple, le nouveau serveur peut concevoir un nouveau protocole réseau. Le récent article du Linux Journal sur No Machine et le protocole NX prouve que le protocole X peut être compressé à 200:1 ou plus. Le nouveau protocole serait basé sur OpenGL et serait conçu pour éviter des latences aller-retour et fournir une mémoire cache image persistante. Chromium est un système intéressant qui supporte l'affichage OpenGL en mosaïque sur plusieurs moniteurs connectés à un réseau. Leur bibliothèque réseau fait le suivi de l'état d'OpenGL (OpenGL state tracking) pour éviter du trafic réseau.

La mémoire cache glyphe devrait également être analysée. Dans le serveur X actuel, le client produit les bitmaps glyphes et les envoie au serveur où elles sont placées en mémoire cache. Ce modèle exclut les glyphes produits par le GPU décrits dans le papier donné en référence précédemment. Les polices côté client sont une bonne idée. L'application devrait à coup sûr être responsable de la mise en page. Mais il n'y a aucun vrai besoin de générer des bitmaps glyphes côté client. Dans le cas de polices à taille variable générées par un GPU, on doit faire parvenir au serveur plus de données qu'un simple bitmap.

Un nouveau serveur pourrait viser les insuffisances actuelles dans le son et l'impression réseau. Il pourrait supporter un mandatement (proxying) approprié requis pour rattacher des sessions. Il devrait certainement être conçu pour supporter plusieurs utilisateurs dès le début.

La gestion des événements est un bon exemple de la réalisation de choses avec des bibliothèques. Linux a Evdev, la connexion à chaud du noyau, HAL et le D-BUS. Ces sous-ensembles n'existent pas sur la plupart des autres plates-formes. Pour cette raison, un sous-ensemble de la gestion des entrées sur BSD semblerait très différent de celui conçu pour Linux. Rendre les principaux sous-ensembles modulaires les laisse être adaptés et utilisés pleinement aux besoins de l'environnement sur lesquels ils fonctionnent. C'est une approche différente que de concevoir pour le plus petit dénominateur commun des environnements.

X est utilisé par de diverses agences de renseignement à travers du monde. Le serveur X actuel est connu pour ne pas être assez sécurisé pour une utilisation sur des documents sensibles. Si un travail de conception majeur devait arriver, il pourrait être réalisé de la base au sommet en gardant à l'esprit la sécurité. Un financement approprié suffirait à s'assurer que les bonnes fonctionnalités sont implémentées.

À court terme, il y a de grandes choses qui doivent être faites et le récent développement a commencé à aborder ces questions. La première chose est un gestionnaire de mémoire pour DRM et le remaniement nécessaire pour permettre les FBO (framebuffer objects) dans les pilotes DRI. La seconde chose est de nettoyer les pilotes fbdev correspondant aux matériels pour lesquels nous avons des pilotes DRM. Une fois les bases en place, le travail sur une nouvelle conception de serveur pourrait commencer.

Conclusion

Mon expérience avec l'échec de Xegl m'a enseigné que réaliser un sous-système graphique est un travail important et compliqué, de loin trop compliqué pour qu'une ou deux personnes l'abordent. Dans l'ensemble, la communauté X.org a à peine assez de ressources pour construire un seul serveur. Diviser ces ressources dans plusieurs directions à la seule conséquence d'empiler des projets à moitié finis. Je sais que les développeurs préfèrent travailler sur ce qui les intéresse, au lieu de donner des ressources disponibles à X.org, cette approche n'apportera pas à un nouveau serveur ou même un bureau pleinement compétitif basé sur le vieux serveur à court terme. Peut-être qu'il est temps à X.org d'établir une feuille de route que tout le monde devra suivre.

Jon Smirl

30 août 2005

L'autorisation de traduire et de reproduire librement ce document est accordée.

Si vous trouvez des erreurs d'orthographe, des erreurs de traduction, ou bien si vous avez des remarques n'hésitez pas à les formuler à travers ce formulaire.
Traduction française par Bruno Ethvignot le 30 septembre 2005
Version française mise à jour le : vendredi 14 octobre 2005
Relecteurs : Tuiu Pol, Phil'sFree, Vincent Rubiolo, thechaman, FReEDoM