Ma vie rêvée

Plan général

1. Les bases, le rendu 2D
2. Le rendu 3D direct
3. Le rendu 3D indirect
4. Composite et XGL
5. AIGLX
6. 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.

De quoi on va causer

Nous avons vu dans la première partie, l'architecture client/serveur du système X11. Evidemment, il n'a pas échappé à votre oeil de lynx que le schéma ne mentionnait que la 2D et ne faisait qu'une vague référence à la 3D. C'est tout à fait normal, au moment où X11 a été inventé (vers 1984), la 3D n'était pas particulièrement développé et l'architecture n'en a pas forcément tenu compte d'emblée.
Heureusement pour nous, cette lacune a été comblée depuis et X peut maintenant gérer la 3D. C'est ce que nous allons voir maintenant (tout au moins une partie).

Comment ça marche donc ?

Avec X, la gestion de la 3D au niveau des applications repose sur une API (interface de programmation) assez connue nommée OpenGL. Cette API offre aux application un ensemble de fonctions qui permettent de dessiner en 3D (Direct3D fait de même sous MS-Windows).
Sous GNU/linux (et les autres), c'est le projet Mesa3D qui implémente OpenGL et founis la bibliothèque qui va bien aux applications, la libGL.

A ce stade, on est encore au niveau de l'application et pas encore de la carte graphique, et le problème, c'est que celle-ci ne comprend pas directement l'OpenGL. On va donc avoir forcément une transformation quelque part. C'est ce qu'on appellera le rendu 3D et suivant la méthode il pourra être direct ou indirect.

Le rendu direct

Il est représenté dans le schéma ci-dessus. Dans le rendu direct, l'application 3D va s'adresser à la libGL pour son affichage. La libGL va alors communiquer directement avec le serveur X, demander et obtenir l'autorisation d'accéder à la partie 3D de la carte graphique.
Une fois le droit d'accès donné, la libGL va convertir les commandes OpenGL en commandes compréhensibles par la carte et les envoyer directement à la carte 3D. Ces 2 dernières étapes mettent en jeu le pilote 3D lequel est fortement intriqué avec la libGL.

Dit comme ça, on voit pas trop l'intérêt ; mais en réalité, celà signifie que le traitement 3D est directement effectué par la carte (d'où son nom ), aucun passage par le serveur X et donc nettement moins de traitement au niveau du CPU. On a donc une accélération 3D complète de l'application.

L'inconvénient majeur de cette méthode, c'est qu'il faut dire au revoir à la transparence réseau, en effet, l'application accède à la libGL au niveau client X et cette dernière accède directement au matériel ; il est donc impossible d'avoir de l'affichage déporté avec cette méthode.

Pendant ce temps là, les applis non-3D continuent bien sur à utiliser le rendu 2D classique que nous avons déjà vu.