De la 3D sur un bureau ?

L'idée de base est assez ancienne. D'un côté la fascination pour la 3D donnait des envies de longue date à certain de transporter ces concepts sur nos bureau. Il existe de nombreux projets, assez anciens, qui reposent sur une exploitation des métaphore 3D pour simplifier l'espace de travail comme le projet looking glass ou encore metisse (un projet Français ! .

Mais au-delà des effets 3D, une réalité a rendu plus concret ces bureaux en 3D, il s'agit de l'énorme montée en puissance des GPU. En effet, la prolifération des jeux en 3D a tellement dopé le marché que la moindre carte graphique possède aujourd'hui d'énormes capacités de calcul capacités qui, si l'on n'est pas joueur, sont absolument inutilisées. Nous étions dans le paradoxe d'un CPU qui travail pour afficher des fenêtres alors que le GPU, lui, se tournait les pouces... L'idée est alors venue d'utiliser massivement le moteur de textures des GPU pour dessiner boutons et autres fenêtre.

Mais une fois l'idée posée, d'autres ont pu germer. En effet, pourquoi se limiter à cela et ne pas en profiter pour faire un peu remuer tout ce vieux bureau hérité de cette non moins vénérable Lisa (cf. ihm en photo de gauche).

En quête de la fonction TFP

Ainsi est né, en gros, l'idée de Xgl du côté de Novel (éditeur de la distribution Suse) et un peu plus tard, et en réaction ) Xgl, Aiglx par redhat. Pour mieux comprendre (très rapidement) la différence entre ces deux architectures, il faut se rappeler que X est un serveur. A ce titre une application graphique est un client réseau d'un serveur X qui seul dialogue avec la carte graphique. La 3D quant à elle est gérée par OpenGL à travers une extension du serveur X appelée GLX. C'est cette extension qui dialogue avec les drivers propriétaires de la Nvidia (par exemple).

Pour rendre visuellement une fenêtre à l'aide d'un moteur 3D, il faut utiliser le moteur de texture de la carte graphique en transformant le rendu 2D de la fenêtre, une image (ou pixmap) en une texture exploitable par le GPU. Il faut pour cela, d'une manière ou d'une autre, avoir accès à une fonction que l'on appelle "texture from pixmap" alias tfp pour les intimes. Aiglx et XGL s'opposent justement sur la manière de fournir ce service.

AIGLX (pour Accelerated Indirect GLX) se place comme une extension de GLX en permettant l'accès aux fonctions hardware 3D de manière indirecte, c'est à dire en respectant la philosophie de transparence réseau des serveur X. Ainsi, une application peut utiliser "à distance" les capacités graphiques 3D d'un serveur X disposant d'AIGLX. La fonction tfp est donc disponible à travers le réseau mais demande une modification du driver pour être appelée sur la carte graphique.

XGL (ou plutôt XglX) a une philosophie radicalement différente. Il ne s'agit pas là d'une extension d'un serveur X existant mais d'un serveur compatible X11 qui se place au dessus de X.org dont il est le client unique. Une fois lancé, Xgl ne fait alors qu'une chose, ouvrir sur le serveur X.org une fenêtre en plein écran dédiée à l'affichage d'objets OpenGL, un peu comme un jeu vidéo. Xgl devient alors le serveur (DISPLAY=:93) pour toute les autres applications dont il fait le rendu visuel sur la fenêtre OpenGL plein écran. On comprendra donc qu'Xgl est structurellement plus rapide qu'AIGLX. En effet, les commandes 3D sont directement passées à la carte graphique via les API OpenGL. De plus, Xgl propose sa propre implémentation de la fameuse fonction tfp ce qui le rends indépendant de sa présence ou nom dans le driver de la carte. Xgl fonctionne donc sur toutes les cartes du marché disposant d'un driver OpenGL, sans modification (contrairement à AIGLX). La suite d'XglX s'appelle Xegl qui se passe complètement du serveur X.org.

Une expérience amusante à faire chez soi pour se convaincre de la nature "fenêtre plein écran" de XglX. Ouvrez une console et de taper les commandes suivantes :

Ce qui nous donne quelque chose comme ceci :

On comprends ainsi parfaitement que XglX est une simple fenêtre sur le bureau d'un premier serveur X (:0).

Il y a de grands débats pour savoir laquelle des deux options est la plus pérenne. RedHat reproche à Novel d'avoir développé Xgl "dans son coin", les puristes voient en Xgl la fin de la philosophie X et les détracteurs d'AIGLX pointe la nécessité de modifier les drivers pour que l'extension puisse fonctionner, d'autres encore trouve que Xgl représente trop de travail par rapport au simple ajout d'une couche à X. Bref, il y a fort à parier que les deux options se retrouveront ensemble dans les prochaines versions du serveur X.

Dans tous les cas, les performances d'AIGLX sont simplement en dessous d'XGL. Ce qui est logique de par la nature même d'accès indirecte d'Xgl. Mais nous allons le voire, il existe une troisième car certains Beryl, le composition manager, peut aussi utiliser directement la fonction TFP du driver nVidia pour les meilleurs performances. Une sorte de troisième voie

La discrète extension COMPOSITE

Mais quoi qu'il en soit, cette fonctionnalité de rendu 3D ne serait que bien peu de chose sans une extension des serveurs X apparue, elle, il y a déjà deux ans : COMPOSITE. Cette extension permet à une application spéciale appelée gestionnaire de composition (CM pour composite manager), de provoquer le rendu d'une arborescence de fenêtres en mémoire et non plus directement à l'écran. le gestionnaire de composition peut ainsi modifier cette image en mémoire, puis de la renvoyer au serveur X pour son affichage final. Lorsqu'elle est apparue, cette extension a déjà permis de très jolis effets de transparence et d'ombres de fenêtres.

On comprend à ce stade que les bases du bureau full-3D sont posées avec les briques COMPOSITE et TFP via XGL/AIGLX. Il ne manque dorénavant plus qu'un chef d'orchestre pour que la magie s'opère, un gestionnaire de composition très spécial qui prendrait en charge la fonction TFP. Et ce n'est pas tout car si nous n'avions qu'un gestionnaire de composition, nous aurions une uniformité des effets sur toutes les fenêtres, par exemple une ombre ou une transparence. Pour aller plus loin, il fallait donc aussi un nouveau gestionnaire de fenêtres (WM pour Windows Manager) pour le comportement (placement, déplacements, réduction, etc.) et, fin du fin, un nouveau décorateur de fenêtres (WD ou Windows Decorator) chargé de dessiner les bords et les barres de titre.

La magie de Compiz

Les équipes Novel ont donc développé compiz, un gestionnaire de fenêtres ET de composition utilisant la fonction TFP pour ses effets. Il a été aussi développé (par novel ?) cgwd, un décorateur de fenêtre exploitant lui aussi la fonction TFP. Et C'est à ce stade que les fenêtres gigotent lorsqu'on les déplace, bondissent ou s'enfuient sur une combinaison de touche, se mettent à plat lorsque la souris touche un coin de l'écran ou que les bureaux virtuelles deviennent les faces d'un cube dont la rotation fait baver les windowsiens de jalousies à défaut d'être réellement très utile Et tout ceci avec XGL comme AIGLX.

compiz se repose sur une architecture de type "plugins". C'est à dire que chaque effet (redimensionnement, changement de bureau, etc...) est un plugin indépendant, paramétrage et désactivable à loisir. Cela permet à des développeurs indépendants de mettre au point leurs propres effets (une fenêtre qui explose par exemple lorsqu'on la ferme).

Mais l'histoire ne se termine pas là, loin de là... Le Sieur Quinn Storm, un des développeurs, plutôt pas mauvais, de compiz avait depuis un temps déjà développé sa propre branche appelée compiz-quinn. Plus d'effets, plus novateur, plus rapide aussi... Et ce qui devait arriver arriva, la branche est devenue un nouveau projet appelé beryl accompagné d'un renommage de cgwd en emerald. Et il faut bien avouer que le couple Beryl-Emerald fait des merveilles. C'est plus rapide, mais surtout c'est beaucoup plus beau ! Le projet est fournit avec des outils de choix de thèmes pour emerald et de paramétrage fin des effets pour beryl.. Un must qui m'a fait jeter à la poubelle le "vieux" compiz intégré à la Mandriva 2007 pour me lancer dans la compilation de beryl...

Installation de Beryl et Emerald

D'après la publicité, Mandriva 2007 est déjà en 3D, non ? bein non, car cela ne marche pas... En effet, si Mandriva annonce un support XGL/AIGLX cela ne concerne en réalité que les versions payantes qui contiennent les "bons" drivers, pas les driver libre qui généralement ne disposent pas de l'accélération OpenGL/3D. Conclusion, il faut installer les drivers propriétaire Nvidia qui fournissent la fonction TFP (depuis la version 9629) pour AIGLX et les librairies OpenGL accélérées pour XglX (quelle que soit la version).

Cette installation est faite pour ceux qui veulent avoir les dernières versions de beryl et des drivers nVidia. Pour les autres qui préférerais une version plus "clef en main", je conseil la page wiki de l'installation de beryl via urpmi.

Pour ceux qui possède une i86_64, pensez à chaque fois qu'un librairie est à installer à prendre la version 64 bits. Par exemple, libxorg-x11-devel devient dans votre cas lib64xorg-x11-devel

Installation des drivers NVidia

Allez dans la section Drivers linux du site de nVidia et télécharger le driver correspondant à votre processeur (i32, 64, etc..). Une fois le fichier télécharger, il faut sortir de X, pour cela, presser CTRL-ALT-F1 et loggez vous en root.

Il faut que X soit arrêté, donc tapez un violent pkill kdm. On va aussi en profiter pour installer les paquets de développement de X11, les sources du kernel (si ce n'est déjà fait) ainsi qu'enlever les anciens artefacts 3D de la mandriva puis lancer l'install des drivers :

Une fois que l'installeur a terminé son travail, acceptez qu'il modifie votre fichier /etc/X11/xorg.conf. Une fois de retour en ligne de commande, éditez ce fichier pour vérifier que vous avez les points suivant, sinon, les ajouter :

Maintenant, il nous reste à compiler beryl, autant ne pas relancer X pour l'instant...

Compilation de beryl

Bery s'installe donc très facilement en téléchargeant les sources avec subversion :

Une fois les sources téléchargé, passer en root pour installer quelques petits paquets de développement :

Enfin, pour éviter un petit soucis qui m'est arrivé avec libapr et libapr-util :

Ensuite, les développeurs de beryl ont eu le bon goût de mettre un script qui compile l'ensemble. Pour que ce script fonctionne, il faut que vous ayez paramétré votre sudo pour qu'il vous autorise le lancement d'un make install, ensuite il suffit d'aller dans le dossier beryl créé par svn et de lancer ./makeall. Au bout d'un temps la compilation c'est normalement déroulé sans problème... Du moins je l'espère pour vous

Pour les processeur i86_64, il faut modifier le script makeall et modifier la ligne comme suite :
if ./autogen.sh --libdir=/usr/lib64 --prefix=$MYPREFIX && make && sudo make install

Pour bien comprendre la suite, il est nécessaire de s'arrêter sur la manière dont Beryl trouve SA fonction TFP. Basiquement Beryl recherche le maximum de performance/stabilité, ce qui nous donne dans l'ordre : Xgl (performant et stable), natif nVidia (très performant et moins stable) puis AIGLX (moins performant et stable). Ceci implique que si Xgl n'est pas chargé, c'est le driver nVidia qui sera utilisé. Hors ce dernier est buggé et les grandes fenêtres s'affichent en noir sur certaines cartes. AIGLX n'apportant rien en terme de performance, je conseille donc de garder Xgl pour le moment en paramétrant le fichier /etc/sysconfig/xgl pour indiquer XGL=yes. Mettez non pour tester si driver nVidia fonctionne chez vous.

Nous pouvons maintenant, redémarrer X en tapant kdm. Lorsque vous êtres reconnecté, si vous tapez dans une console echo $DISPLAY vous devez avoir un :93.0 qui apparaît, preuve que XGL est actif. Ensuite, vous n'avez qu'à lancer beryl-manager pour que la magie s'opère.

Gagner en vitesse

La machine que j'utilise pour tester beryl est très modeste en comparaison de certain, un Sempro 2400+ et une carte vidéo nVidia FX5200 avec 64mo. Il y a un plugin bien utile permettant d'afficher le nombre de frame par secondes. Il s'active via beryl-settings, pensez à désactiver le limiteur de vitesse et y associer un raccourcis clavier (ici F12). A l'activation du raccourcis, une jauge s'affiche pour indiquer les performances, soit 50 fps et mon CPU était à fond... Un peu inquiet, j'ai modifié modifié les options suivantes :

• Options générales/Choix/Synchronisation avec VBlank. J'ai enlevé, c'est un peu idiot lorsqu'on a un écran LCD (y'a pas beaucoup de canons à électron dans ce type d'écran, surtout en DVI...)
• Blur Fx à désactiver (je n'ai pas bien compris ce que cela faisait) mais il prends du CPU.
• Gestion des crashs à désactiver, gros gain de vitesse.
• TailFocus à désactiver, très gros gain de vitesse mais on y perd un peu

Une fois ces "optimisation" réalisée, je passe à 120 fps (au lieu de 50, ça valait le coup

Un autre conseil, dans le paramétrage du plugin "Animations", onglet "Valeurs Numériques", descendez le temps des animations montantes (ouvertures, maximisation, etc..) à 0.5s et les descendantes (fermetures, minimisation, etc..) à 1s. En effet, c'est agaçant d'avoir à "attendre" 1 seconde quelque chose que l'on doit utiliser, il vaut mieux, à mon sens, laisser plus de temps aux animations qui se font sans gène (je peux faire autre chose en admirant un fenêtre qui se minimise). Ainsi, on n'est plus gêné par les effets d'un point de vue ergonomique. My 2 cents opinion.

Conclusion

Voilà, fin donc de l'aventure Beryl. En tout cas une chose est sure, je suis aujourd'hui incapable de m'en passer. Les effets sont tellement "organiques" qu'il rendent tout autre système lourd et cartonneux en comparaison...