L'actualité est riche pour les bureaux 3D, Annonce de AIGLX [1], Ouverture de compiz par Novell [2]et je vais tâcher de vous expliquer comment ces bureaux fonctionnent et leur différences, bonne lecture :)
Déjà le terme de bureau que j'utilise est faux, En fait je devrais plutôt dire qu'on a trois ensemble WM <-> serveur X modifié, mais bon je trouve bureau plus approprié, faites un sed s/bureau(|x)/WM/g de mon article si ça vous convient mieux.
En fait ces bureaux ne fournissent aucune application, et sont "justes" des serveurs X, qui affichent des clients X (de manière spéciale certes). Pour ce faire il y a deux choses à faire comparé à un serveur X normal:
1.Mettre le contenu de toutes les fenêtres en mémoire d'un client X un peu spécial (au même titre que le gestionnaire de fenêtres)
2.Calculer le rendu du touillage de toutes ces fenêtres (sur certaines démo ça tien vraiment du touillage ;)
Ces deux étapes se mettent donc à la place du rendu habituel.
Globalement la méthode utilisée est la même dans les deux cas
Xglx et AIGLX qui utilisent l'extension maintenant connue (en partie pour ses bogues) appelée "Composite".
Cette extension consiste en l'envoi à un client X spécial du contenu de toutes les fenêtres ce client X est appelée le composite manager.
Une fois que le composite manager a ces informations il en fait ce qu'il en veut, mais il doit renvoyer au serveur X un rendu. Pour les composite manager habituels le rendu, c'est l'affichage des fenêtres telles qu'elles devraient l'être avec de la transparence et des ombres et ce de manière accélérée par Xrender qui est une extension de calcul rapide sur des images (de ce que j'ai compris) , mais ils font strictement ce qu'ils veulent, vous pouvez coder un composite manager, qui met les fenêtres la tête à l'envers si vous voulez, qui fait des miniatures, etc. Mais ils peuvent faire le rendu comme ils veulent, pas seulement avec XRender, et donc Xgl et AIGLX font le rendu.... par OpenGL?! (Tant qu'à faire) Et donc on a le droit au fameux cube ou tout ce que vous voulez.
Mais alors pourquoi Compiz|Xgl et AIGLX ont eu besoin de modifier le serveur X?
La seule raison que j'ai trouvé est qu'il est nécessaire (bon grandement plus optimisé et simple du moins), d'avoir une extension OpenGL? ce coup ci (et plus Xorg, vous suivez ? :) qui permettent de définir une texture OpenGL? directement à partir du contenu de la fenêtre fourni par le serveur X, et dans aussi bien pour Xglx que pour AIGLX. Une fois cette extension (répondant au doux nom de GLX_EXT_texture_from_pixmap) ajoutée, les différents composite manager 3D marchent, aussi bien compiz que glxcompmgr que metacity donc compiz peut marcher sur AIGLX, metacity sur xgl (modulo les bogues comme toujours). Fait à noter, NVIDIA à annoncé à l'équipe de AIGLX qu'ils ajouteraient le support de GLX_EXT_texture_from_pixmap, ce qui si vous avez tout suivi (on ne sait jamais tout peut arriver), vous dit qu'on pour avoir des bureaux 3D sans rien faire à part installer le composite manager (un configure && make install suffit dans la plupart des cas).
Maintenant pourquoi deux projets distincts, pourquoi des désaccords de toute part ?
Le but premier de Xgl N'est PAS de faire un bureau 3D, il vient principalement de vous là ! oui le petit qui râle tout le temps! Ceux qui râlent que X est lent, ceux qui détaillent pourquoi ils râlent, disent que X est trop complexe et qu'il faudrait s'appuyer sur une couche OpenGL? qui est accélérée, alors que la couche 2D ne l'est pas (Qu'ils disent ! Car c'est faux (je précise quand même au cas où)), et aussi ceux qui disent que développer un driver X est compliqué et que X devrait se baser sur OpenGL?.
En clair, Xgl est un serveur X qui tire son accélération 2D de l'OpenGL? (de la 3D avec z=0 quoi).
Xgl n'est pas exactement un serveur, c'est une architecture avec 2 grandes variantes, Xglx et Xegl, je reparlais de ce dernier plus loin, mais d'abord Xglx, le serveur dont on parle le plus souvent
Xglx est un client X et a donc besoin d'un serveur X pour fonctionner, hors le but d'un serveur X se basant sur OpenGL? c'est de ne pas à avoir à écrire de driver X.... vous comprenez la connerie ?
Alors pour certain c'est intelligent, mais bon l'égout les couleurs ...
Sinon à côté de Xglx on entend parlé de Xegl, et que Mandriva ne supporterait officiellement que Xegl et pas Xglx, on a vu que ne pas supporter Xgxl ou le supporter.... ça changeait pas grand chose à la vie en somme, Xegl est parait-il son petit frère donc tout aussi inutile ? Pas tout à fait, la différence entre Xegl et Xglx est que Xegl ne s'appuie pas sur X mais sur OpenGL? ES, je vous vois venir "C'est quoi ce monstre?" c'est juste une API OpenGL? pour l'embarqué, de sorte que l'application n'ait pas de serveur X ou équivalent, on pourait le comparer au framebuffer linux.
On a donc ici un OpenGL? ES et pas de driver X et on en sort un serveur X accéléré aussi bien pour la 2D que la 3D sans autre effort, le but est donc atteint, mais ce n'est pas forcement une solution comme l'explique NVIDIA dans [3] (ca commence sérieusement page4)
[1] http://linuxfr.org/~etb/20923.html
[2] De nombreux journaux et une news que je retrouve pas
[3] http://download.nvidia.com/developer/presentations/2006/xdev(...)
Vous avez réussi à me lire jusqu'au bout? Et bien je vous remercie et vous dis bravo :)
PS Au début je voulais parler de metisse et de lg3d mais bon ce journal est déjà bien long :)
Enfin on pourra signaler l'ouverture d'un CVS public de metisse (la dernière release commençant à dater)
Journal Le point sur les bureaux 3D
22
fév.
2006
# et ati ?
Posté par manatlan (site web personnel) . Évalué à 7.
Un moment tu parles de nvidia et du fameux GLX_EXT_texture_from_pixmap ...
toi qui a l'air de savoir, sais tu, si moi avec ma pauvre ati9200, je pourrai profiter de compiz a cie ... bref si GLX_EXT_texture_from_pixmap est dispo dans les fglrx (drivers proprio) ou le driver 3D libre (qui fonctionne pour ma 9200) ...
sais tu ?
[^] # Re: et ati ?
Posté par Ph Husson (site web personnel) . Évalué à 8.
Le jour où j'oublierais rien et que je serais clair...
Donc en fait pour la plupart des drivers libres Xorg, c'est AIGLX qui s'en charge
AIGLX côté serveur n'est que une série de patchs pour Xorg et Mesa pour supporter GLX_EXT_texure_from_pixmap
Donc avec quelques patchs ca marche :)
Il parait que c'est déjà intégré dans ubuntu
et je penses que vu la facilité d'intégration de nombreuses distributions l'intégreront
Bon par contre fgflrx j'en doute et de toutes facons vu le niveau des drivers libres je penses que ca devient inutile
[^] # Re: et ati ?
Posté par ccomb (site web personnel) . Évalué à 2.
Après, savoir si les drivers ATI suivent, je sais pas, quelqu'un a-t-il testé ?
[^] # Re: et ati ?
Posté par Mark Havel . Évalué à 1.
[^] # Re: et ati ?
Posté par xumelc . Évalué à 3.
# hum.
Posté par Nicolas Blanco (site web personnel) . Évalué à 6.
Mais Xegl est basé sur Xgl, n'est-ce pas ?
Alors pourquoi Mandriva ne veut pas supporter Xgl et pourquoi Redhat critique Xgl en dehors du fait que Novell l'a utilisé comme coup publicitaire ?
Ca sera bien qu'on arrive a quelque chose de fonctionnel rapidement parce que ça fait 5 ans que je vois tourner Mac OS X et dans 6 mois ça sera Vista.
[^] # Re: hum.
Posté par un_brice (site web personnel) . Évalué à 5.
Je trouve qu'aiglx, qui permet une transation plus en douceur en suivant le système classique d'extensions, et en se basant sur du code (Composite), qui bien que pas très au point à déjà quelque mois d'existence derrière lui, est beaucoup plus prometeur.
Sinon je pense pas qu'il y ait une "course aux effets 3d" au pire si y'a un retard là dessus par rapport à vista ça seras que pour quelque mois, voir un an. Du court terme quoi (pbmt avant même que les PCs courants soient assez puissants pour faire tourner vista). Décider dans l'urgence un système mal conçu ferait perdre beaucoup plus.
Et de toutes manières, vu l'utilité du truc je pense pas que beaucoup de personne feront la transition linux <-> windows juste pour en bénéficier. À l'heure actuelle je trouve mon bureau (KDE) plus joli qu'un macosX "out of the box" et pourtant j'ai pas d'opengl partout.
[^] # Re: hum.
Posté par Matthieu Duchemin (site web personnel) . Évalué à 6.
J'ai pu tester Xglx, et il offre de loin de meilleurs performances que composite seul alors qu'il propose bien plus d'effet. Bref ça tourne très bien chez moi sur mon athlon 550Mhz avec ma Geforce FX 5200, que j'ai acheté il y a à peu près 2 ans et qui était à l'époque le premier prix de chez Nvidia, qui ne fonctionne qu'en AGP 1x parce que ma carte mère elle est buggué. Je rajouterais qu'actuellement avec les cartes Nvidia, on ne peux pas utiliser le rendu direct qui devrait être disponible avec une prochaine version des drivers nvidia, et que l'on ne peut pas non pus utiliser le buffer glx. En conclusion ça tourne très bien, et pourtant on ne peut pas dire que ce soit dans des conditions optimales.
[^] # Re: hum.
Posté par Matthieu Duchemin (site web personnel) . Évalué à 1.
ce n'est pas le buffer de glx qui n'est actuellement pas disponible pour les cartes nvidia mais le buffer xv (donc quand on li une vidéo)
[^] # Re: hum.
Posté par dawar (site web personnel) . Évalué à 5.
# ?
Posté par Ludovic F (site web personnel) . Évalué à 10.
Si tu pouvais nous écrire tout cela en ~300 lignes, je suis persuadé que ce serai bien plus clair et intéressant. Y'a matière c'est évident mais c'est super mal formaté, faut pas rater un mot sinon tu perds immédiatement le fil ;-)
[^] # Re: ?
Posté par Mark Havel . Évalué à 4.
[^] # Re: ?
Posté par BAud (site web personnel) . Évalué à 5.
# Bon, c'est pas tout ça....
Posté par ナイコ (site web personnel) . Évalué à 2.
Ceci dit, c'est pas le tout, mais ça ne met pas *X*gl (Ou autre) sur mon bureau, ça !
J'ai passé une semaine à essayer de compiler Xgl en m'inspirant de plusieurs documentations, et surtout, au final, de celle de le liste cooker [1], que j'ai suivi _a_la_lettre_ ! J'ai buté plusieurs jours sur `fbSetVisualTypesAndMasks', puis ça a fini par passer, au gré des mises à jour du cvs.
Alors voilà, au bout de 5 jours d'efforts, j'ai enfin compilé tout, sans erreur aucune !!!
Tiens, fume : Ce n'est pas Xgl, qui est compilé, mais un Xorg normal. Pas de binaire Xgl. Douloureux, non ? J'ai pourtant respecté à la lettre toute la procedure...
Voilà, des idées ? Pour quoi la commande suivante me compile Xorg et pas Xgl ?
[1] http://archives.mandrivalinux.com/cooker/2006-02/msg01446.ph(...) (J'utilise cooker sur ma machine de test, donc, hein...)
[^] # Re: Bon, c'est pas tout ça....
Posté par Matthieu Duchemin (site web personnel) . Évalué à 2.
[^] # Re: Bon, c'est pas tout ça....
Posté par ナイコ (site web personnel) . Évalué à 2.
[^] # Re: Bon, c'est pas tout ça....
Posté par Ph Husson (site web personnel) . Évalué à 3.
make
cp Xglx /usr/bin
Qui a dit grouik?
[^] # Re: Bon, c'est pas tout ça....
Posté par Matthieu Duchemin (site web personnel) . Évalué à 2.
# Ah ah ah
Posté par gnumdk (site web personnel) . Évalué à 4.
"to driver developers to expose vendor-specific features"
Et oui, avec Xegl, tout le monde sera logé à la meme enseigne et la différence se fera vraiment sur la qualité du matériel à executer des requetes OpenGL.
On comprend mieux ce qui les fait chier...
[^] # Re: Ah ah ah
Posté par gnumdk (site web personnel) . Évalué à 3.
Le gros probleme qui se pose à Nvidia est donc comment fournir des extension si ils n'ont plus de control sur le driver X (pas celui du kernel).
En particulier tout ce qui est TwinView et autres spécificité des cartes Nvidia. Il leur semble que Xgl ne permet pas de permettre à ce genre de fonctionnalité d'être implémtenté proprement (voir d'être implémenté tout cours).
On notera qu'il ne s'agit que de suppositions (we believe).
Ensuite, ils essayent de démontrer que tout ce qui est faisable avec Xgl est faisable avec l'architecture actuelle.
Il serait tres interessant d'avoir une réponse de David Reveman afin d'avoir d'autres arguments que ceux de Nvidia.
Il n'empeche que Novell est en mauvaise position pour imposer sa technologie si les constructeurs de cartes graphiques ne sont pas prêt à les suivre...
# quelques clarifications et méditations
Posté par Rémi Hérilier . Évalué à 9.
Pourquoi modifier le client Xorg ? Tout simplement parce que son architecture ne permet pas de faire ce qu'apporte AIGLX et Xgl : l'utilisation d'OpenGL pour la composition. Il faut l'extension GLX_EXT_texture_from_pixmap.
L'approche de Xgl est de rediriger les primitives 2D vers glitz (et donc OpenGL) alors que celle de AIGLX est de mettre au même niveau OpenGL et les pilotes graphiques du client X (puisqu'ils peuvent partager des XPixmaps). AIGLX est plus léger en terme de modification mais une vieille application en Xaw ne fera que de la 2D (au niveau du pilote graphique) alors que Xgl remet à plat beaucoup de choses mais permet d'avoir une utilisation de la 3D à tous les niveaux (même si certains toolkits ont moins d'intermédiaire que d'autres). Mais d'une manière générale, Xgl et AIGLX permettent bien de faire exactement la même chose. Personnellement, je ne vote ni pour Xgl ni pour AIGLX car je pense qu'un mélange des 2 est possible =)
X est lent car :
- la Xlib a des appels synchrones que les specs disent asynchrones (voir Xcb pour la réécrire de la Xlib pour corriger ce problème).
- certaines extensions sont exécutées par le processeur (donc besoin d'un processeur puissant puisqu'on a les applications *et* le client X qui le solicitent).
- autres problèmes dus à des pilotes buggués et/ou à code fermés.
Tu as entièrement raison, Xgl est un client X qui utilise OpenGL pour l'affichage. En revanche, je ne comprend pas ta phrase suivante :
Xglx est un client X et a donc besoin d'un serveur X pour fonctionner, hors le but d'un serveur X se basant sur OpenGL? c'est de ne pas à avoir à écrire de driver X.... vous comprenez la connerie ?
Tu confonds un peu tout. où est la "connerie" d'utiliser OpenGL dans le client X ? Le serveur X ne fait que gérer les communications entre application X et client X. Utiliser à distance une application Gtk+ (Gtk+ 2.8 avec glitz pour l'affichage) est toujours possible. Bref, tout va bien et rien n'a changé pour l'utilisateur. Et pourquoi ? Tout simplement parce que la couche basse (du toolkit ou Xglx lui même) à appelé GLX pour ouvrir un contexte GLX sur la machine cliente.
Pour EGL, c'est encore autre chose. EGL est une uniformisation de GLX/WGL/AGL (et d'autres s'ils existent). Donc on a une unique API pour gérer des contextes OpenGL (et donc le rendu). Après, que l'implémentation utilise X, MacOSX ou Ms Windows pour permettre leurs interactions, ce n'est plus un problème puisqu'une unique API permet de s'abstraire de l'environnement dans lequel on utilise l'application.
Si mon raisonnement etait erroné - càd qu'EGL est une couche à peine moins basse qu'OpenGL mais totalement indépendante de tout système de fenêtrage - il serait donc possible à X de s'appuyer dessus pour l'affichage mais le problème de l'absence de tranparence réseau impliquerait le développement d'une couche dans X pour le permettre ... on vient de réinventer GLX sauf qu'il s'appelerait EGLX \o/
Pour s'en convaincre, il suffit de comparer les specs de GLX et d'EGL ... elles se ressemblent beaucoup trop pour ne pas permettre les mêmes possibilités (la transparence réseau entre autre). En l'occurrence la même séparation entre un "état client" et un "état serveur" qui permet justement à GLX d'encapsuler les appels OpenGL dans le protocole X.
OpenGL/ES apparait effectivement comme étant une version pour embarqué d'OpenGL. Personnellement, je vois surtout une "remise à plat" d'OpenGL - ou plutôt une correspondance entre OpenGL/ES 1.0 et une version OpenGL 1.x donnée (je n'ai pas lu en profondeur les specs d'OpenGL/ES) - De plus, OpenGL/ES est montré comme étant une API 2D/3D totalement indépendante ... OpenGL l'est à l'origine (et ça doit remonter à IrisGL son ancêtre). D'ailleurs, pourquoi la libGL est-elle dans /usr/lib et non dans /usr/X11R6/lib ?
ayé, fini ^_^
ps: j'espère ne pas trop faire écho avec d'autres posts ... il y a presque 3h entre le début et la fin de mon roman /o\
[^] # Re: quelques clarifications et méditations
Posté par gnumdk (site web personnel) . Évalué à 2.
C'est toi qui aurait du faire un journal ;)
>Xglx est un client X et a donc besoin d'un serveur X pour fonctionner, hors le
>but d'un serveur X se basant sur OpenGL? c'est de ne pas à avoir à écrire de
>driver X.... vous comprenez la connerie ?
Sur ce point, je pense que l'auteur du journal n'a pas compris que Xgl est avant tout une architecture et que Xglx est juste un moyen de tester rapidement cette architecture, mais Xglx a toujours été condamné à disparaitre. Mais Xegl et Xglx sont deux implémentation de la même architecture, l'une coté serveur, l'autre coté client.
Je pense surtout que ce qui va faire la différence entre les deux approches (traditionnel ou X sur OpenGL) va surtout être au niveau des perfs. Pour le moment, Xglx semble montrer que les perfs sont bien meilleurs qu'avec un serveur X normal (surtout que auncun driver ne supporte encore la fameuse extension et que c'est donc toujours fait en software par mesa).
[^] # Re: quelques clarifications et méditations
Posté par Ph Husson (site web personnel) . Évalué à 4.
Sinon la terminologie serveur X qui gere les communications, client X qui s'occupe des I/O c'est bien la première fois que j'entends ça
Xorg est un serveur X et il s'occupe d'afficher ce que les clients X lui envoient, en choisissant qui va ou .....
Quelle étape tu veux rajouter dans le fonctionnement X normal?
Sinon dans le cas ici de Composite, y a le composite manager qui se greffe on va dire au serveur X
C'est peut etre pour ca que tu définis serveur X et client X comme ca ? Pour pouvoir intégrer le concept de composite manager facilement? Ou bien?
Bon sinon dire que mes explications sont pas claires ça c'est pas nouveau, mais bon apparement beaucoup de monde se trompait sur ce qu'était Xgl et personne pour corriger donc j'ai voulu corrigé ca, mais bon mes talents de correcteurs valant ce qu'ils valent voilà le résultat.... (oui mes problèmes de rédactions me posent de nombreux problèmes, donc j'essaye d'écrire plus mais bon le résultat est pas évident....)
[^] # Re: quelques clarifications et méditations
Posté par gnumdk (site web personnel) . Évalué à 2.
Non, c'etait juste pour apporter une précision à ca:
>c'est une architecture avec 2 grandes variantes
Ce qui n'est pas vrai, il n'y pas deux variantes de l'architecture Xgl, il y'a juste deux implémentations(l'une coté client: xglx et l'autre coté serveur xgl).
C'est tout ce que je voulais dire meme si xglx est à la fois client et serveur si j'ai bien compris.
[^] # Re: quelques clarifications et méditations
Posté par Rémi Hérilier . Évalué à 1.
Donc l'errata de mon roman est le suivant : remplacer "application(s) X" par "client(s) X", "serveur X" par "Xlib" et "client X" par "serveur X".
source : http://fr.wikipedia.org/wiki/X_Window
[^] # Re: quelques clarifications et méditations
Posté par Rémi Hérilier . Évalué à 2.
La véracité des perfs, ça se discutent ;)
Mais dans l'absolu, Xgl doit effectivement être plus rapide puisqu'il redirige tout vers OpenGL. Par contre, quand les devs de AIGLX trouveront l'idée permettant de balancer le rendu 2D vers OpenGL, on devrait retrouver sensiblement les même perfs mais avec le client Xorg générique et non un client spécifique.
\o/ ça ne m'a pas pris 3h \o/
[^] # Re: quelques clarifications et méditations
Posté par gnumdk (site web personnel) . Évalué à 2.
>spécifique.
Nan, c'est serveur Xorg, les clients ce sont les applications :)
Oui, je sais, avec Xglx, c'est moins évident à differencier :)
[^] # Re: quelques clarifications et méditations
Posté par Rémi Hérilier . Évalué à 1.
/me qui retourne se cacher
# ouille...
Posté par Seazor . Évalué à 2.
Qqun se dévoue pour faire un schéma des différentes couches ?
Ca en fait beaucoup qd même, qui peuvent se remplacer/compléter l'une l'autre...
(qui s'insère où ? qui est client/serveur de qui ?)
Voire à m' indiquer un schéma existant sur le web si ca existe déjà.
Bounty : Un verre au fosdem à celui qui m'aidera à y voir plus clair :)
[^] # Re: ouille...
Posté par gnumdk (site web personnel) . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.