Les bases de la 3D sous Linux

Transcription

1 créé le 11/04/2008 par Antoine Schellenberger. dernière mise à jour le 11/04/2010. Cet article présente les rouages des environnements 3D sous linux. Nous abordons d'abord quelques généralités concernant X Window et OpenGL, puis nous détaillons précisément le fonctionnement des architectures sous-jacentes aux bureaux 3D sous linux en les comparant à l'implémentation X.Org traditionnelle. I - Le système X Window ou X11 a) Généralités Le système d'affichage sous linux est basé sur X window system ou X11. Ce système est multios et a également été porté sous Mac OS X et windows. Sous linux, I'implémentation X11 la plus utilisée est X.Org. X11 repose sur une architecture client / serveur comme l'illustre la figure 1. Ecouter sur un port logiciel les requêtes d'affichage émanant de ses clients afin d'effectuer le rendu correspondant via un ou plusieurs display. Pour fonctionner un serveur X aura donc besoin d'au moins une souris, un écran(display) et un clavier. Un client X a les responsabilités suivantes: Ecouter les événements utilisateurs(mouvements souris, frappes clavier) que le serveur X lui transmet après capture; effectuer le traitement métier des entrées utilisateurs qu'il vient de recevoir (ex. calculer le carré d'un nombre qui a été tapé); ecrire le résultat du traitement dans un contexte graphique afin d'être rendu à l'utilisateur. Cette dernière étape s'appuie sur la Xlib (ou libgl dans le cas particulier d'un contexte graphique OpenGL). Illustration 1: Architecture X11 Dans ce contexte, le serveur X a principalement deux responsabilités: Illustration 2: Diagramme d'activités des composants de X11 Détecter les entrées utilisateurs pour les rediriger vers ses clients(x) via un protocole particulier. La Xlib(libX11 ou libx) se charge d'encapsuler la requête d'affichage et de la transmettre au serveur X (via le protocole X) pour qu'il en effectue le rendu: 1

2 on dit que l'affichage est rendu indirectement (indirect rendering ou I.R). L'implémentation X.Org actuelle (7.1) utilise toujours le rendu indirect pour servir les primitives d'affichages qui lui ont été transmises par la Xlib. Nous verrons que le serveur X peut aussi écouter d'autres types de requêtes d'affichage via l'extension GLX (libglx). Les clients X se basant sur la Xlib(comme certains gestionnaires de fenêtres (WM)) ne la manipulent presque jamais directement: il est plutôt d'usage d'utiliser des «toolkits» permettant d'abstraire la Xlib. (cf. figure 3). Les plus connus sous linux sont Qt et GTK+. Illustration 4: Répartition MVC au sein de X11 Cette architecture client/serveur repose sur un protocole de communication basé sur IPV4 et IPV6, ce qui permet la distribution des clients et du serveur à travers un réseau. En partant du principe que l'ensemble des clients X encapsule le modèle (qui englobe à son tour la logique métier), on parle de couche métier distribuée (à l'image des web services via SOAP ou de CORBA via IIOP), donc derrière cette architecture client / serveur se trouve une notion forte d'interopérabilité. Illustration 3: Les surcouches usuelles à la Xlib Les responsabilités attribuées entre clients et serveur X suivent une conception de type MVC (Modèle Vue Controleur) (cf. figure 4): Le client X a les responsabilités du modèle car c'est lui qui encapsule la logique métier; le serveur X a les responsabilités d'une vue car il développe la représentation du modèle; le serveur X a également les responsabilités d'un contrôleur car il capture les évènements utilisateurs pour les rediriger vers le modèle (le client X); la Xlib intervient également en tant que contrôleur car elle permet de synchroniser d'une part les évènements utilisateurs entre serveur et clients, et d'autre part les requêtes d'affichage entre clients et serveur. Cette distribution via un réseau soulève un problème de sécurité car il est possible toutefois de capturer les paquets X circulant sur le réseau et de les analyser pour connaître par exemple toutes les opérations clavier d'un utilisateur; c'est pourquoi il est nécessaire quelquefois de tunneliser les paquets X11 dans un protocole plus sécure comme celui de SSH. Des outils de gestion de la sécurité sous X11 sont livrés systématiquement avec le système. b) Accélération matérielle et contexte graphique direct Précédemment, nous avons sommairement abordé le concept de «rendu indirect» qui rappellons-le, est intégré au fonctionnement classique de X.Org. Cependant, quand client et serveur sont sur la même machine, pourquoi le client ne transmettrait-il pas directement les requêtes d'affichage au driver de la carte graphique? On aurait alors un contexte graphique direct... Le rendu direct de l'affichage permet de n'utiliser le serveur X que pour la capture des évènements utilisateurs (click,etc..) et laisse le GPU (processeur de la carte graphique) traiter les opérations graphiques. Quand les opérations sont traitées par le GPU on parle d' «accélération matérielle». 2

3 Il est évident que l'accélération matérielle libère fortement la charge du CPU. On estime que l'indirection de l'affichage vers le serveur X n'influe que très peu sur la latence à l'affichage, par contre l'accélération matérielle est primordiale. Dans X.Org le serveur X utilise déjà l'accélération matérielle pour son affichage 2D via ses «driver X» (DDX, EXA/XAA) qui dialoguent avec le secteur 2D des cartes graphiques. (cf. figure 2). Nous nous permettons d'insister sur le fait que dans X.Org quand un client X utilise la Xlib pour son affichage, le contexte graphique qu'il manipule est toujours indirect mais contrairement à ce que beaucoup pensent, il est tout de même «accéléré matériellement» coté serveur via les drivers 2D. De plus, il est important de rappeller que : Tout rendu direct implique explicitement qu'il n'y a pas de retour au serveur X mais implicitement que l'accélération matérielle soit présente; Comme nous venons de le voir une accélération matérielle n'implique pas un rendu direct c'est à dire qu'elle peut être présente coté serveur comme c'est le cas pour X.Org qui accélère toutes ses opérations 2D. En résumé, dans X.Org, tout contexte graphique 2D indirect fournit par la Xlib est toujours accéléré matériellement coté serveur, mais qu'en est-il des contextes 3D? II - 3D et OpenGL a) Généralités Les drivers X de X.Org ne savent utiliser que le secteur 2D des cartes graphiques (nous l'avons déjà évoqué). Dans un univers 3D, les coordonnées d'un objet ont toujours 3 composantes (x,y,z), cependant un écran restant une surface plane, il faudra pour afficher ces objets les «plaquer» sur un espace 2D. Cette projection 3D->2D implique évidemment des calculs qui seront pris en charge par un processeur (CPU ou GPU). La librairie 3D la plus répandue sous linux est OpenGL. OpenGL est une spécification qui permet de définir une interface commune d'utilisation pour ses clients. Dans le monde objet, une spécification est représentable par le concept fort d'interface où un client utilise l'interface d'un objet par polymorphisme sans en connaître les détails d'implémentation. On retrouve encore derrière la notion de spécification une volonté d'interopérabilité c'est à dire d'indépendance vis à vis du media: c'est ce qui a permis à OpenGL d'être porté sur plusieurs plateformes et systèmes d'exploitation. Note: le concurrent direct d'opengl sous Windows est direct3d OpenGL est une librairie qui permet de fournir un contexte graphique 3D à ses clients pour leur permettre de manipuler des objets dans un univers tridimensionnel en abstrayant les calculs de projections et autres. Une implémentation libre compatible OpenGL sous linux est MESA3D. ( Attention: MESA3D n'est pas une implémentation strictement conforme aux specifications d'opengl! Dans le cadre d'opengl, l'accélération matérielle permet de déléguer l'ensemble des calculs (projections, rotations,...) au GPU ce qui nécessite : Des drivers qui savent discuter avec le secteur 3D de votre carte graphique (qu'on nommera driver 3D par la suite); une implémentation OpenGL qui sache discuter avec votre driver 3D; Il se présente alors plusieurs cas de figures: Soit le code source du driver 3D de la carte est libre (c'est le cas des intel depuis 2006 qui sont sous GPL) et dans ce cas le développement de l'implémentation OpenGL est ouvert à la communauté (souvent récupéré par MESA); soit le code source n'est pas libre, auquel cas le constructeur de la carte fournit directement l'implémentation OpenGL,le driver 3D et le module kernel de la plateforme et de l'os correspondant. (Il existe des projets libres de rétro-ingénierie pour certains drivers propriétaires, mais rien de très concluant à ce jour.) L'accélération matérielle nécessite l'accès direct aux ressources graphiques ce qui relate une gestion complexe de la sécurité et de la concurrence. Quand le rendu est traité indirectement, c'est le serveur X qui se charge de créer des queues de traitement (lilo) pour accéder aux routines 2D de votre carte via ses drivers 2D, par contre quand le D.R est 3

4 actif, l'accès concurrentiel doit être géré par un système tierce. le projet D.R.I (direct rendering infrastructure) implémente un protocole sécurisé d'accès direct aux matériels graphiques. Certaines implémentations d'opengl comme celles d'intel ou d'ati repose sur DRI pour effectuer leur rendu direct tandis que d'autres dialoguent directement avec le driver 3D (nvidia). D.R.I embarque MESA3D dans ces drivers 3D, et la libglcore utilisé coté serveur est aussi de MESA. Passer par D.R.I présente l'avantage de pouvoir s'affranchir de l'implémentation OpenGL propriétaire pour activer le D.R. Quand l'accélération matérielle est activé (avec ou sans D.R.I) la gestion de l'accés au matériel graphique se fait par un module du noyau dénommé D.R.M (Direct Rendering Manager). Illustration 6: Répartition des 3 composants de GLX dans X.Org GLX est formé de 3 composants principaux (cf. figure 6): Une interface applicative(libgl.so) qui fournit aux clients X un contexte graphique GL leur permettant d'utiliser les fonctions GL, et si nécessaire d'encapsuler les requêtes d'affichage de ces fonctions dans le protocole X pour un rendu indirect. une extension au protocole X, qui permet l'encapsulation des requêtes GL pour les transmettre au serveur X. Une extension du serveur X(libglx.so) qui recevra les appels précédents et effectuera le rendu. Il se présente alors 2 cas de figures (cf. figure 7): Illustration 5: Traitement du Direct Rendering sous X.Org Sous linux l'implémentation opengl est accessible par la libgl.so. C'est généralement un lien symbolique qui pointe vers un fichier en dur ce qui permet la cohabitation de plusieurs implémentations d'opengl sur une même machine) b) GLX : OpenGL et X11 OpenGL étant multiplateforme, il lui faut un «adaptateur» à X Window: c'est GLX (OpenGL extension to the X window system). Illustration 7: Diagramme d'activités des composants GLX 4

5 Si le contexte GL que GLX présente au client X est indirect alors les 3 éléments de GLX sont sollicités et l'affichage sera traité par le serveur X (c'est le cas classique) Si ce contexte graphique est direct alors seul le premier élément de GLX sera sollicité (libgl.so) puis il passera la main à la librairie qui dialoguera directement avec le driver 3D. Cette librairie peut être la libdri (intel, Matrox, ATI) dans le cas de MESA3D, sinon ce sera une implémentation OpenGL propriétaire qui s'en chargera (nvidia). Notez que même si le rendu direct et l'accélération matérielle sont actifs, les clients X ne faisant pas appel à un contexte GL(libGL.so), mais à un contexte graphique standard (Xlib), auront toujours un rendu 2D indirect (ex. gestionnaires de fenêtres). ii) L'implémentation AIGLX III - Les bureaux 3D Il existe 3 architectures différentes de serveur X qui traitent la 3D via GLX: L'implémentation classique de X.Org; l'implémentation AIGLX; l'implémentation XGL. a) X.Org, AIGLX et XGL i) L'implémentation classique X.Org Illustration 9: Diagramme d'activités du rendu GL avec l'extension AIGLX de X.Org 7.1 AIGLX signifie Accelerated indirect GL X. AIGLX ne modifie en rien l'architecture de Xorg. Comme nous l'avons vu précédemment X.Org traite coté serveur les opérations 3D, ces opérations ne profitent pas de l'accélération matérielle car elles sont traitées par le CPU. AIGLX est une «extension» à X.Org permettant justement d'activer l' accélération matérielle 3D coté serveur (donc dans un contexte indirect). Nous verrons par la suite quel intérêt cela présente dans le cadre des gestionnaires de fenêtres composites comme compiz. iii) L'implémentation XGL Illustration 8: Diagramme d'activités du rendu GL avec X.Org. Si l'accélération matérielle 3D est installée alors le client X recevra un contexte GL direct délivré par la libgl.so, et le rendu 3D sera traité par le GPU sans passer par le serveur X. Si l'accélération matérielle 3D n'est pas installée alors le client X recevra un contexte GL indirect, et le rendu 3D sera délégué au serveur X (via les composants 2 et 3 de GLX - cf figure 6) qui traitera les opérations 3D via le CPU pour transmettre le rendu final au driver X(2D). Seul le secteur 2D du GPU est alors sollicité. 5

6 par la suite, XGL ayant son propre GLX (alias X GLX), il utilisera celui-ci pour servir les futurs clients X demandeurs de contexte GL. Ainsi quand un client demande un contexte GL à X GLX, celui-ci lui fournit systématiquement un contexte indirect afin que toutes les requêtes d'affichage GL soient transmises au serveur Xglx qui à son tour les retransmet à l' implémentation OpenGL sous-jacente configurée avec le X.Org initial. Eglx sera la version «propre» de XGL en remplacement de Xglx. Eglx suivra la même philosophie, avec en plus le traitement des primitives d'affichage vectorielles comme Cairo, et autres. Contrairement à AIGLX qui n'est qu'une extension à X.Org, XGL est un véritable serveur X. XGL manipule une surcouche à OpenGL denommée Glitz. XGL étant un serveur X complet: en plus de fournir l'accélération matérielle 3D coté serveur (comme AIGLX), il retransmet aussi à la Glitz les requêtes d'affichage de la Xlib. De ce fait le driver 3D traitera indifféremment les opérations 2D et 3D ce qui permet de n'avoir plus qu'un driver pour l'affichage. Il existe actuellement deux implémentations de XGL: Xglx et Eglx. Xglx est un «hack» pour prouver la faisabilité du concept XGL, il démarre en surcouche à X.Org (le «hack» est là!) et intercepte l'ensemble des requêtes provenant de la Xlib et libgl (GLX) afin de tout retransmettre à une implémentation OpenGL sousjacente. Il coexiste donc sur une même machine 2 versions de GLX: Celle de Xglx qui capture tous les appels opengl provenant des clients X pour les transmettre au serveur Xglx; celle de X.Org qui permet à Xglx d'avoir un contexte GL direct. En bref, Xglx n'est qu'un client X OpenGL car: Au démarrage Xglx demande au GLX de X.Org de lui fournir un contexte GL, GLX lui fournit alors un contexte direct si l'accélération matérielle 3D est active; b) Les C.W.M (Composite Window Manager) AIGLX et XGL sont forcés de passer par de l'i.r à cause de l'extension GLX_EXT_texture_from_pixmaps. L'ajout de fonctionnalités à OpenGL se fait sous forme d'extension et GLX_EXT_texture_from_pixmaps est une extension définie par le créateur de compiz (David Reveman). Les systèmes de fenêtrages composites (composite window manager ou CWM) sont la combinaison d'un système de fenêtrage utilisant l'extension composite de X.Org(qui permet d'ajouter de la transparence, de l'ombre, etc...). Les CWM les plus connus sont compiz et beryl (branche de compiz). Les CWM font usage justement de l'extension OpenGL GLX_EXT_texture_from_pixmaps, ce qui leur permet d'effectuer des opérations 3D sur les objets d'un bureau en transformant au préalable leur pixmaps en texture. Quand cette extension n'est pas embarquée dans le driver 3D, la libgl en cours délègue le rendu et la création de la texture au serveur X(Xorg+Aiglx ou XGL) ce qui induit inéluctablement un rendu indirect. Naturellement la création de la texture sollicite le CPU tandis que le restant des requêtes GLX seront accélérées via le GPU. nvidia embarque désormais l'extension GLX_EXT_texture_from_pixmap dans leur implémentation d'opengl et leur drivers 3D de la série 9xxx: les détenteurs de ce type de carte peuvent donc utiliser compiz et beryl sans AIGLX ni XGL. IV - Conclusion 6

7 Nous avons vu que X Window, OpenGL et accélération matérielle sont au coeur de la technologie des bureaux 3D. L'implémentation actuelle de X.Org a montré ses limites dans le cadre du traitement des primitives GL, d'où la nécessité d'étendre X.Org avec AIGLX. Certaines personnes pensent de ce fait que AIGLX est «une rustine» à X.Org et que l'avenir du serveur X sous linux est XGL. Contrairement à AIGLX, XGL est un serveur X complet qui n'utilise que le secteur 3D des cartes vidéos pour rendre ses affichages 2D(Xlib) et 3D(GLX). Hélas, XGL souffre de son jeune âge, de sa naissance obscure et de ses développements encore incomplets. D'une manière générale l'intéret pour les bureaux 3D a permis de remettre en cause les architectures actuelles, mais aussi de nous questionner sur l'utilité des drivers 2D, l'avenir des drivers 3D et leur ouvertures possibles à la communauté. Connaitrons-nous le moment où les cartes graphiques ne se différencieront que par leur efficacités matérielle?... La révolution de l'ergonomie 3D est encore à ses débuts et linux nous promet sûrement de belles choses dans le domaine

8 Table des matières I - Le système X Window ou X11...p. 1 a) Généralités... p. 1 b) Accélération matérielle et contexte graphique direct...p. 2 II - 3D et OpenGL...p. 3 a) Généralités... p. 3 b) GLX : OpenGL et X11... p. 4 III - Les bureaux 3D... p. 5 a) X.Org, AIGLX et XGL... p. 5 i) L'implémentation classique X.Org... p. 5 ii) L'implémentation AIGLX... p. 5 iii) L'implémentation XGL... p. 5 b) Les C.W.M (Composite Window Manager)... p. 6 IV - Conclusion... p. 6