Pinaraf a écrit 3682 commentaires

Les GeForce 2 MX semblent être encore supportées... Cf le readme : ftp://download.nvidia.com/XFree86/Linux-x86/1.0-8756/README/(...)

Ben c'est la même extension, avec le même code peut-être, mais avec strictement la même syntaxe.

Ça n'empêche pas d'utiliser xglx hein.
Ça empêche par contre l'utilisation d'aiglx.
Et avant que ça ne trolle sur les pilotes nVidia, les raisons pour la non implémentation de l'extension : c'est qu'elle est pas stable. La spécification est en cours de rédaction/finalisation. Quand ça sera stable, ça sera implémenté normalement.

Y'en a un qui est merdique, et l'autre qui est ...
ben une merde quoi.


Zut, c'est pas une différence.
En fait, y'a windows messenger qui est fourni avec windows et qui utilise pas le protocole msn je crois, et msn messenger qui est pas fourni avec windows et qui utilise le protocole msn.

Je pense que certains geeks solitaires préfèreraient un autre genre de mannequin virtuel...

Encore raté.
Dans Xorg ce qui pêche c'est l'implémentation de XRender, pas l'implémentation de Composite. XRender est très lent, avec EXA ça va beaucoup mieux si les pilotes le supportent, sinon le RenderAccel des pilotes nvidia devrait être bien meilleur pour la prochaine version (au point d'être activé par défaut apparemment)

Ha oui y'a aussi ce changement, mais ce n'est pas lui qui change les traînées. L'OpenGL était d'ailleurs utilisable comme ça dans Java5, mais c'était pas par défaut (c'était pas prêt).
Ce qui change les traînées, c'est surtout l'ajout du double buffering récemment.

Je me suis amusé à tester quelques applications pour les traînées, pour que vous puissez comparer sur une machine sans avoir besoin de logiciels propriétaires. Le test est simple : ouvrir le dialogue à propos, et le déplacer partout pour voir si ça fait des traînées, et jusqu'à quel point.
1- KWord : pas de traînée (en tout cas j'en ai pas vu)
2- OpenOffice.org2 writer : traînées moyennes, pouvant aller jusqu'à saturer la fenêtre en allant vite
3- Firefox : traînées importantes, saturant facilement la fenêtre (thème Noia)
4- Synaptic (histoire d'avoir une appli Gtk sans thème) : traînées moyennes, sans saturation

Ma config : kubuntu dapper sur un Athlon XP 2000+, 512Mo de Ram, nVidia Geforce FX 5600

Au fait, j'ai testé Xgl dernièrement sur ma machine. Autant il est vrai que les effets 3D sont fluides (à condition de ne pas être en train de compiler qqc à côté ! ;-) ) et que les fenêtres sont rafraichies immédiatement (plus de trainées quand on déplace une fenêtre comme sous un serveur X classique).
C'est d'un lourd cette incompréhension...

Je te suggère une expérience : prenons une application Java qui consomme comme Netbeans. Prenons Java 5 et Java 6 (http://mustang.dev.java.net). C'est propriétaire hélas, mais j'ai pas mieux comme éléments pour le test (application égale, toolkits quasiment égaux à un détail : la version). Lance netbeans avec Java5. Ouvre la fenêtre à propos par exemple. Déplace là... Ho une traînée énorme...
Maintenant, lance netbeans avec Java 6. Ouvre la fenêtre à propos, déplace là... Mais... où est la traînée ? Ben y'en a plus (ou de quelques pixels seulement). Les traînées, ce n'est pas du à X, c'est du aux applications ! Il suffirait d'un système de double-buffering dans Qt3 pour que toutes les applications Qt3 arrêtent de faire des traînées (Qt4.1 a ça par défaut il me semble, java6 mustang l'a et donc supprime les traînées car il est assez rapide pour redessiner). Pareil pour Gtk.

Vous me direz : oui mais Xgl il est super fort et moderne et tout et tout, et il arrive à éviter les traînées. Bon, déjà Xgl ça fait plus d'un an qu'il existe. Il a eu un coup de punch tant marketing que fonctionnel grâce à novell. Ensuite, Xgl n'apporte rien niveau graphique qui ne soit pas faisable avec un serveur X classique, utilisant aiglx par exemple. Sans aiglx, les performances sont moindres, mais ça reste faisable. Dans Looking Glass, les fenêtres "woobly" nous pourrions les avoir depuis deux ans bientôt... Mais personne n'y a pensé, ou personne n'a eu le temps, ou personne n'a proposé de les coder. Et on n'utilise pas Xgl ni aiglx. On utilise Composite et cie, tout comme compiz utilise composite et cie + un petit truc dans la libGL supporté par aiglx ou Xgl. Ce petit truc d'ailleurs, Looking Glass devrait l'utiliser prochainement.
Maintenant, reprenons nos chères traînées avec netbeans sur Java5. Il existe une possibilité pour les supprimer : utiliser Composite. C'est l'une des possibilités d'un composite manager. Avec kompmgr activé, je n'ai plus aucune traînée sur aucune application.

Bref, reconnaissons les mérites des uns et des autres, sans exagération !
Merci à Xgl de proposer une implémentation originale d'un serveur X, en utilisant l'OpenGL pour tout dessiner. Merci d'implémenter *texture_from_pixmap.
Mais merci à aiglx d'implémenter *texture_from_pixmap pour X.org. Et merci, merci à X.org d'avoir intégré dans la version 6.8 l'extension Composite. C'est un geste courageux car même si l'extension était alors très bugguée, cela a probablement encouragé le développement de nombreux outils liés.

Un conseil :désactive l'IPoT...
sur http://www.mesa3d.org, la dernière nouvelle que je vois date de février 2006 !
Et mesa bouge pas mal, avec notamment les recherches concernant l'accélération et le rendu off-screen.

Je pense qu'il en faudrait un extrêmement bien écrit, très modulaire et tout capable d'utiliser Qt/KDE OU Gtk/Gnome, ou deux : un pour KDE, un pour Gnome. Il y a tellement de technologies chez KDE pour l'intégration... DCOP par exemple : ça serait vraiment un plus d'avoir un client qui supporte DCOP, afin de pouvoir, depuis n'importe quelle application ou script, accéder facilement aux informations...

Ceci dit, je comprends tout à fait la crainte des artistes devant cette proposition de taxe forfaitaire qui légaliserait le piratage.
Il est légal, aujourd'hui en France, de télécharger de la musique sur Internet. Ce qui est illégal, c'est le partage, la diffusion. Cette taxe, si mes souvenirs sont bons, ne vise pas la légalisation de cette diffusion.

Si tu parles de la campagne "Téléchargez nous légalement", Renaud a déjà expliqué à plusieurs reprises s'être fait embobiné, qu'il était en plus en dépression à cette époque là et donc qu'il n'en avait rien à foutre. Tu devrais retrouver ça sur le HLM des fans de Renaud, dans le forum (que Renaud fréquente (ou a fréquenté ?)).
Si tu parles de la pétition récente sur la licence globale, j'ai demandé sans réponse pour l'instant vu qu'apparemment il vient plus sur le forum. Mais cette pétition me gêne : 10000 signatures en deux mois ça me semble trop gros. Ça fait 5000 par mois, soit 166 par jour !

Et pendant ce temps là, que fait milou ?

Xgl (peut marcher)/marche au dessus d'un serveur X normal. Il n'y a donc pas besoin de mettre à jour les pilotes. Toute carte et tout pilote supportant la 3D seront à priori capables de faire tourner Xgl (sauf bugs des pilotes bien sûr)

La OpenSuse 10.1 devrait l'avoir en paquet optionnel, ou dans un dépôt supplémentaire. La 10.2 l'aura de base. De même je pense pour pas mal de distributions grand public qui ne pourront s'en priver (ubuntu par exemple)

Il n'est pas du tout à jour dans dapper : c'est toujours le même que dans breezy.

Le support de Composite avec les pilotes intel sera mieux quand X.org 7.1 sera là : le patch pour qu'ils supportent EXA n'est pas intégré dans X.org 6.9/7.0, donc à moins que ta distrib ne personnalise son X.org et ajoute des patchs comme ça ...

http://xorg.freedesktop.org/wiki/ExaStatus

Encore faut-il que les pilotes supportent DKMS !
Ce n'est pas automagique apparemment.

Il faut dire que le support de XVideo et de l'OpenGL avec Composite (et un *ompmgr qui tourne bien sûr) n'est pas une mince affaire, rien que d'un point de vue "logique".
Dans le cas d'OpenGL, la carte graphique se charge de calculer et d'effectuer le rendu d'une scène (je suis pas très au point sur le vocabulaire 3D, mais bon le principe est compréhensible). Lorsqu'on fait du rendu direct (Direct Rendering), l'affichage est fait par la carte graphique, il n'y a pas un nouveau passage par X qui se charge alors d'afficher une image. En effet, ce passage coûte cher.
Le principe pour avoir des fenêtres transparentes, c'est que les fenêtres sont affichées "off-screen", dans des images, pour ensuite être modifiées et affichées.
Il faudrait donc que la carte graphique effectue le rendu de l'application OpenGL dans une texture ou une image, et il faudrait ensuite afficher cette image après modification... Bref c'est très lourd, et on perd énormément en performances, rendant donc le tout inutile.

La seule solution actuellement, c'est de couper le *ompmgr lorsqu'on souhaite lancer une application OpenGL. Si on utilise KDE et kompmgr, il suffit d'exécuter la commande dcop kwin KWinInterface stopKompmgr

Je sais pas pour vous, mais moi je trouve ça vraiment pas très joli.
Et si on l'adaptait à toutes les sauces en plus, ça serait sûrement pas plaisant à voir (je vois mal un logo de KDE ou gnome entouré de ce machin)

Je vois pas non plus l'intérêt d'une standardisation des sigles des associations francophones : l'homogénéité pour les sigles n'apporte rien, et n'est pas une nécessité.

C'est un avis purement personnel hein.

Malheureusement, toutes les cartes avec un chipset r300 ne fonctionnent pas encore (et à mon plus grand regret, les radeon X700 ne sont pas accélérées...)
De plus, le support d'EXA pour les cartes à chipset r300 est encore assez limité : pas d'accélération de Render notamment...
Mais on peut espérer que X.org 7.1 aura un support bien meilleur de ces cartes :)

J'ai d'autres critiques vis-à-vis des pilotes nVidia. Notamment le fait qu'ils se foutent complètement de la façon dont sont faits les pilotes X habituels.
Par exemple les pilotes nVidia sont les seuls que je connaisse à ne pas passer par DRI. Un truc désagréable semble en découler : si le module noyau n'est pas là, X ne se lancera pas. Super pour les newbies.
Ce genre d'horreurs n'arrivent pas avec les pilotes ATI propriétaires, ni avec les pilotes libres.

D'autres points à ne pas oublier :
1- Support d'autres architectures matérielles. Je ne pense pas que nVidia compilera un jour son pilote pour PowerPC par exemple.
2- Support de nouveaux noyaux. Si quelqu'un veut utiliser le noyau 2.7 quand il sort mais qu'il y a des incompatibilités avec le pilote nVidia, alors il y aura deux choix : pas de 3D, ou pas de noyau 2.7... Ce qui est très agréable.

Rappel : c'est nVidia qui développe le pilote libre actuellement...
Cf http://cvs.freedesktop.org/xorg/driver/xf86-video-nv/ChangeL(...)
Résultat faut pas espérer le voir supporter l'accélération 3D rapidement ...

Avec quels pilotes autres que les pilotes nVidia arrivez vous à accélérer l'OpenGL avec Composite activé ??
Ça m'intéresse énormément.
Pour info, pour les pilotes nVidia il faut activer l'option AllowGLXWithComposite afin d'avoir cette accélération.