Comment marche X11/xorg et toute la clique ? 4° partie, composite et XGL
Par Mjules le dimanche 12 novembre 2006, 17:27 - General - Lien permanent
Plan général
- Les bases, le rendu 2D
- Le rendu 3D direct
- Le rendu 3D indirect
- Composite et XGL
- AIGLX
- Suite et fin (ou comment ne plus avoir d'idée pour le titre)
Préambule
Cet article est basé sur ce que je comprend du fonctionnement de X11. Il est loin d'être parfait et comporte peut-être des erreurs. si c'est le cas, j'apprécierais qu'on me les signale pour pouvoir améliorer le tout.
Où en est t'on ?
Dans les billets précédents, on a vu comment Xorg se débrouillait pour afficher des choses sur l'écran en 2D et en 3D. Ça fonctionne très bien mais ce mode de fonctionnement comporte des limitations qui rendent difficile l'évolution de l'affichage. En particulier, avec ce mode de fonctionnement, il est très complexe de faire des choses comme des ombres derrières les fenêtres, ou tout bonnement des fenêtres transparentes. C'est pourquoi le protocole X11 a été encore étendu avec l'extension Composite. Celle-ci va permettre de modifier le comportement du rendu. En effet, au lieu que le serveur envoie directement les informations sur chaque fenêtre à la carte graphique ; celles-ci sont envoyées dans un espace de la mémoire où elles peuvent être ensuite manipulées par un gestionnaire de composition avant que le résultat soit rendu par la carte graphique.
L'énorme avantage, c'est qu'avec cette méthode, il devient très simple de faire, par exemple, une fenêtre réellement transparente. Le gestionnaire de composition possédant toutes les infos pour celà (il sait exactement quelle fenêtre est au dessus de quelle autres etc).
L'énorme inconvénient, c'est que ça nécessite beaucoup de puissance graphique et donc, pour pouvoir faire ça sans que l'affichage rame atrocement, il faut de l'accélération par la carte graphique.
Cette accélération est disponible avec la partie 2D de la carte via les extensions XAA ou plus récemment EXA. Néanmoins, l'accélération 2D pose quelques problèmes qui rendent son utilisation peu intéressante :
- XAA était difficile à implémenter dans les pilotes et n'accélérait que peu de fonctions 2D
- EXA est plus simple à implémenter mais il ne l'est toujours pas dans un grand nombre de pilotes
- la partie 2D des cartes graphiques se réduit de plus en plus au profit de la partie 3D
- la partie 2D des cartes graphiques est nettement moins performante que la partie 3D
Bref, la conclusion s'imposait d'elle même, il fallait trouver un moyen d'accélerer tout ça en utilisant la partie 3D de la carte graphique.
2 solutions ont alors été développées qui répondent à cette problématique : XGL par Novell/Suse et AIGLX par Fedora/RedHat.
XGL
XGL a été la première solution présentée par Novell au tout début de l'année 2006. Son développement a fait l'objet de quelques critiques, en effet, il a principalement été réalisé de manière non-ouverte. Les craintes quand a la fermeture du projet ou du code ont depuis été levées.
Le schéma de principe :
Le schéma ci-dessus présente XGL dans son implémentation Xglx, c'est à dire utilisant 2 serveurs X. Il existe une autre implémentation, Xegl, encore à l'état de projet, qui se baserait sur les EGL, des bibliothèques openGL censées parler directement à la carte graphique.
Comme on le voit sur le schéma, Xgl va donc jouer un double rôle, il est simultanément un client X pour les applications et un serveur X utilisant openGL. Au démarrage, Il va dialoguer avec libGL (et donc le serveur X sous-jacent) et obtenir un rendu 3D direct. Ainsi, toutes les opérations du serveur XGL sont susceptibles d'être accélérées par la carte graphique et en particulier par sa partie 3D. En particulier, toutes les opérations d'un gestionnaire de composition (compiz, beryl par exemple) seront accélérées du moment que celui-ci utilise openGL.
Cela fonctionne très bien mais à quand même quelques défauts relativement gênant : comme pour tout rendu direct, on dit au revoir à la transparence réseau ; la nécessité d'avoir 2 serveurs X tournant simultanément augmente la mémoire occupée ainsi que la complexité du système ; enfin, et c'est le plus gênant, il est impossible pour les autres applications 3D (les jeux par exemple) d'obtenir un rendu direct vers la carte graphique. Elles n'obtiennent au mieux qu'un rendu indirect par le serveur XGL, ce qui pose un problème de performance.
Les 2 derniers problèmes sont liés à l'implémentation Xglx et devrait disparaitre avec Xegl. Mais cette dernière n'est encore que théorique.