[cite]
Kevin Kofler (./15) :
GoldenCrystal (./13) :
N'importe quoi, AIGLX permet de faire fonctionner l'extension, et pas l'inverse, trouve toi de meilleures sources que wikipedia.
Source? Moi j'en ai cité une, alors j'attends la tienne...
http://www.freesoftwaremagazine.com/articles/accelerated_x?page=0%2C0 C'est à la fois la plus complète et la plus superficielle que j'ai trouvé je pense pas qu'il y ait beaucoup mieux, surtout pour quelqu'un qui n'y connait rien au fonctionnement de l'OpenGL sous Linux...
Mais je le répète: NON, le format des DRI de fglrx < 8.42.3 n'est PAS compatible AIGLX et ne donne AUCUNE d'accélération 3D lorsque celui-ci est activé.
Ce que tu dis là est une évidence, mais ça ne contredit en rien ce que j'ai dit: les mêmes versions de X.Org X11 (les mêmes binaires, sans aucune recompilation) qui gèrent l'AIGLX permettent aussi d'utiliser le 3D (sans AIGLX évidemment ) avec les pilotes qui ne gèrent pas l'AIGLX.
Oui ce que je dis est une évidence, alors pourquoi tu viens me contredire quand je dis la me^me chose dans mon post précédent ?
Et donc "Et puis si, nVidia supporte AIGLX puisque leur driver fonctionne avec un Xorg par défaut" est incorrect comme logique.
Les driver de NVIDIA supportent AIGLX puisque leur interface DRI ets compatible avec le DRI "AIGLX-compatible" que veux tu que je te dise de plus. Si ils ne le supportaient pas on aurait le même résultat qu'avec les anciens driver ATI... "
(EE) AIGLX: Screen 0 is not DRI capable"
Et puis de toute façon, on se bat sur de la nomenclature, on est bien d'accord que nVidia propose les fonctionnalités de AIGLX, avec une implémentation différente de celle des pilotes libres. Que tu appelles cette implémentation "AIGLX" ou autrement n'a au final aucune importance.
Non car celà n'a rien à voir. Tout le monde tend à mélanger AIGLX et GLX_EXT_texture_from_pixmap... Parce que tout ça tourne autour de compiz et que les gens n'ont que ça en tête... Pourtant même si les deux choses sont liés à leur origine elles n'ont pratiquement rien à voir.
Je fais un résumé du fonctionnement historique de l'accélération 3D avec X: (On est dans le passé, AIGLX n'existe pas)
Sur un système X disposant de drivers 3d, tu as deux modes de rendu OpenGL: Le mode indirect, et le mode direct. (Au passage,
http://dri.sourceforge.net/doc/dri_control_flow.html -> joli schéma)
1 - Le mode direct (d'où DRI pour Direct Rendering Infrastructure) passe ses commandes OpenGL directement au driver (oui je ne dis pas au matériel car tu risquerait encore de ne pas comprendre...) graphique, et la surface de rendu n'est
pas gérée par le serveur X. (Grossièrement, tu dessiness
par dessus le rendu de X, sans qu'il soit au courant (En fait même si il l'est il ne peut rien y faire))
2 - Le mode indirect (d'où le Indirect GLX de AIGLX) passe ses commandes OpenGL au serveur X. Le rendu indirect est effectué de manière logicielle (Mesa dispose d'une implémentation 100% logicielle d'OpenGL, tout en intégrant aussi des drivers opensource qui fonctionnent avec le dri, et donc actuellement aussi avec AIGLX). Pas grand chose à dire ici si ce n'est que c'est lent
Ce que t'apporte AIGLX c'est l'accélération matérielle (via un driver compatible évidemment) du rendu indirect. ça veut dire que tu pourras par exemple lancer plusieurs glxgears en même temps et les regarder tourner ensemble: les ressources sont partagées entre les applications.
Enfin bien évidemment c'est une conséquence... Car AIGLX a été créé
pour GLX_EXT_texture_from_pixmap... Pourquoi ?
(Ici ça s'applique aussi bien à XGL que AIGLX: )
Pour créer un bureau graphique, il fallait un moyen de passer d'un pixmap X (contenant a priori l'intérieur d'une fenêtre
) à une texture OpenGL qui pourrait être affichée et transformée à souhait par le matériel. Donc il faut faire sous-traiter le rendu de la fenêtre à X (après tout c'est comme ça que fonctionnent toutes les applications linux, elles envoient leur commande à X... Enfin c'est plutôt le toolkit qui s'en charge mais bon
), puis le récupérer dans le WM (hop un changement de contexte, plus le même processus), et le transformer en texture (et hop un peu plus de changements de contexte, on aime ça), ça implique quelque "légers" transferts de données inutiles.
La solution était donc de ne pas faire sortir les données du serveur X. Donc il faut faire rentrer dans le serveur tout ce qui ne rentrait pas auparavant: les commandes OpenGL. Malheureusement le serveur X de base ne permettait pas d'accélérer le rendu indirect. Ce qui a donné naissance à Xgl, et à AIGLX.
D'un côté tu abstrait tout ton serveur au dessus de OpenGL, ce qui permet de rediriger XVideo vers des textures de manière automatique, et également de rediriger les applications 3d vers des textures (Mais bon, cette partie là laissait encore à désirer quand je l'utilisais), donc d'intégrer le rendu 3d dans des fenêtres déformées avec Compiz (à tout hasard).
De l'autre côté tu accélérais le rendu indirect... Ce qui revient plus ou moins au même puisque dans les deux cas ton serveur X devient "opengl-aware". Avec AIGLX l'accélération matérielle est fonctionelle (ce qui demande(ait ?) plus de boulot pour Xgl ^^) pour n'importe quelle application, mais en revanche, le serveur n'a toujours aucune liaison avec les surfaces OpenGL qui ne lui appartiennent pas (c'est à dire tout ce qui n'est pas rendu par Compiz), donc tu verras bien tes bordures se déformer mais le contenu, lui restera bien carré. (Ce qui n'était pas le cas sous Xgl ^^)
Enfin bref, texture_from_pixmap a "besoin" de AIGLX pour la plupart des driver, c'est pour ça que Compiz ne fonctionne qu'en mode indirect sur les cartes ATI, Intel, etc...
Voilà je crois pas avoir dit trop de conneries (enfin y'en aura forcément vu que je vais pas me relire mais si ça t'amuse de rebondir dessus je ne répondrai pas
)
)
) mais tu dois en bénéficier au moins en partie 
