sylware a écrit 284 commentaires

Aux dernières nouvelles, il semble que le pb n'est pas là.
C'est pour la bande de p'tit gars qui va bosser pour nous fournir "libdvdHDcss" que je me fais du soucis, car quand elle va publier son code sur le net en GPL... ahem...

Tout le problème est qu'un groupe de travail s'attaque à la décompilation des drivers NVIDIA.
Au delà de la décompilation, il faut que MESA-DRI-DRM soit mis à jour pour supporter les specifications 2.0 et ES/EGL (pour Xegl).
Bref, pour dire qu'il y a beaucoup de travail, et que dans le meilleur des mondes NVIDIA aurait développer un driver ouvert intégré à MESA-DRI-DRM... rendant tout ce travail inutile.

Derrière ce sujet trolleur se cache une vraie inquiétude pour Gnome.

En effet, dans sa dernière version, le bureau gnome standard est maintenant dépendant de python (attention je n'ai rien contre python, bien au contraire), et on voit qu'il y a une force qui veut en faire de même avec .NET(mono). En effet, il ne s'agit pas ici d'avoir des "applications additionnelles" gnome dépendantes de tel ou tel (bloat&&useless)ware mais bien d'en obliger l'installation pour le déploiement d'un bureau gnome de base.

Ca sent vraiment pas bon.

Il n'y a pas à favoriser tel ou tel langage de haut niveau en forçant la dépendance sur une couche additionnelle (dont une statégiquement pilotée par qui... allez un peu de bon sens messieurs et mesdames...) du bureau de base.

Bref... comme je l'ai déjà dit, maintenant le libre attire les convoitisent et des entreprises vont tenter de se rendre indispensables à son fonctionnement de base... et si la communauté se laisse faire, le libre n'aura plus que de libre des licences.

Je n'ai absolument rien contre python, tout au contraire.

Je suis par contre complètement opposé à toutes les dépendances sur des langages de haut niveau du bureau gnome de base. Il n'y a pas à favoriser un langage de haut niveau plus qu'un autre, surtout qu'il y en a une plétore.
Mais je ne vois pas d'inconvénients à ce que les applications additionnelles soient faites en langages de haut niveau, tant que leur installation reste à la discrétion de l'utilisateur.

Mais ce que je voulais mettre en évidence sur ce fil de discussion, c'est qu'il semble qu'il y ait une récupération du bureau de Gnome, un peu comme une récupération politique, avec des méthodes qui me rappellent celles d'une grosse boîte bien connue.

A priori, Xegl sera entièrement OpenGL ES/EGL accéléré (poubelle EXA et XAA).
Les applications, donc côté client, devraient être basées sur OpenGL GLX (c'est pour la transparence réso).

Je suis inquiet pour Gnome.

En effet, dans sa dernière version, le bureau gnome standard est maintenant dépendant de python, et on voit qu'il y a une force qui veut en faire de même avec .NET(mono). En effet, il ne s'agit pas ici d'avoir des "applications additionnelles" gnome dépendantes de tel ou tel (bloat&&useless)ware mais bien d'en d'obliger l'installation pour le déploiement d'un bureau gnome de base.

Ca sent vraiment pas bon.

Il n'y a pas à favoriser tel ou tel language de haut niveau en forçant la dépendance sur une couche additionnelle (statégiquement pilotée par qui... allez un peu de bon sens messieurs et mesdames...) du bureau de base.

Bref... que je l'ai déjà dit, maintenant le libre attire les convoitisent et des entreprises vont tenter de se rendre indispensables à son fonctionnement de base... et si la communauté se laisse faire, le libre n'aura plus que de libre des licences.

Perso, je n'ai aucun soucis sur le fonctionnement de Mozilla dans sa version firefox.

Par contre, je suis me suis intéressé au système de compilation de Mozilla... et bien là... ouch! Je pense qu'il serait bon que Mozilla fasse comme X.org, c'est à dire une modularistion propre avec un support correct des GNU autotools. Pour le moment, il faut avouer que c'est quand même bordélique.

Tiens? tu as un code snippet d'OpenGL qui n'a pas besoin de X11?

Effectivement, comme avec le plus grand des hasards, il va dans une entreprise proxy de M$... Oups! pardon! Il va dans une entreprise complètement indépendante de M$ bien sûr!

C'est vrai que maintenant, quasiment n'importe quel GPU a une puissance à peine exploitée par les applications graphiques. L'idée est de "passer le cap" en n'hésitant plus à écrire des applications graphiques qui en tirent partie. La seule API permettant de vraiment le faire est OpenGL... mais il faut savoir à quelle sauce le manger: GLX,EGL,AGL...

Conceptuellement parlant OpenGL/GLX est dans X11. Cela signifie qu'il faut déjà un serveur X11 qui tournent pour pouvoir utiliser OpenGL/GLX (Il te faut un display etc...). Donc Xgl doit avoir un serveur X11 derrière!

C'est OpenGL ES/EGL qui devrait nous permettre de se débarraser de ce serveur X11 "en tâche de fond"... et là on parle de Xegl. Cela veut dire que OpenGL ES/EGL n'a pas besoin de X11. C'est indépendant. La séparation entre la couche X11 et la couche OpenGL est nette et précise, et ça c'est bon.
De ce que j'ai compris, les modifications de David Reveman sur Mesa apportent un début de support EGL pour les drivers du radeon. Mais bon, il faut avouer que je n'ai pas encore lu les specifications OpenGL ES/EGL pour voir de quoi il en retourne vraiment.

Je n'ai jamais mis en doute les performances des GPUs modernes. Ce que je mets en doute c'est leur capacité à gérer en même temps toutes les façons d'accéder à cette puissance.

Admettons que tu as un serveur Xegl qui tourne. Sur ce serveur X11 tu as des applications X11 qui utilise aussi de la 3D, via OpenGL/GLX. Donc tu as le window manager qui bosse avec OpenGL EGL et des applications qui utilisent les xlibs implémentés en OpenGL/EGL(xegl!) mais qui utilisent spécifiquement de OpenGL/GLX pour accélérer des effets "à la 3D" que ne peuvent lui fournir les xlibs ou encore des couples cairo/glitz/OpenGL GLX ou EGL. Le GPU doit gérer l'ensemble de ces contextes (EGL/GLX) non indépendants de manière cohérente et performante: la difficulté est là.
Bon... si on veut conserver la transparence réseau: le serveur X11 pourra être implémenter sur OpenGL EGL, mais toutes les applications (y compris le window manager) devront rester en OpenGL GLX.

Il paraît qu'il ne faut pas confondre la division software de Sun avec la division hardware de Sun...

Il est vrai qu'il paraît que le middleware de gnome devrait passer de corba à dbus... mais y a le temps! Il faudra redéfinir toutes les interfaces "à la dbus", et très proche ou pas de corba, il y aura du boulot pour re-écrire les parties middleware de pas mal de logiciels (chantier prévu pour gnome 3 si tout va bien dans le meilleur des mondes). Et cela reste une interface. Celles de EOG et gThumb sont très simples.
Le but est d'expérimenter l'accélération avec OpenGL de ce genre de soft. EOB et gThumb sont des terrains propices.

Pour ce qui est d'XGL:
Bon il faut voir la date:Mon Nov 8 12:43:55 PST 2004 et ça:

Cairo's glitz backend can't provide the same quality as the xlib/xcb backends
right now, but that should be made possible in the future..

On est aujourd'hui dans le futur de cairo/glitz. Ce que je sais c'est que glitz et une forme de xrender en OpenGL (GLX,EGL ou AGL). Et au dernières nouvelles, sur ma machine je n'ai pas pu faire la différence entre cairo/glitz ou cairo/xlibs avec ou sans antialising. Le meilleur moyen est de regarder le code source de cairo pour voir comment glitz et xrender sont utilisés.

Donc si j'ai bien compris, se contenter de re-écrire un serveur X11 sur OpenGL résulterait en des applications plus rapides... hum... pas convaincu du tout sur ce point. A la rigueur, ce mode pourrait permettre de normaliser une extension de X11 pour un "accés bas niveau" aux objets OpenGL correspondants. En fait cela reviendrait à normaliser la façon d'implémenter X11 avec OpenGL. Du très costo donc, car une erreur de design peut se payer très chère.

Xgl est basé sur OpenGL comme glitz. Les primitives OpenGL utilisées sont les mêmes, donc il n'y a à priori pas de raison pour glitz de ne pas antialiser au même niveau que Xgl.

Je suis décidement super curieux de connaître les raisons de David Reveman sur le sujet.

Perso, je trouve que tu n'as pas tord. Si il y quelque qui devrait être intégré au gestionnaire de fichier c'est bien ça. Avec Nautilus c'est fait avec un composant corba: EOG (il me semble que gThumb en est un aussi). Ils peuvent servir de terrain d'expérimentation pour ces fameux zooms et autres traitements.

...une visualisation des photos et des videos en zoomant depuis le gestionnaire de fichier...

C'est une bonne idée. Il y a EOG et gThumb des visualiseurs/éditeur d'images. Il faudrait travailler sur l'utilisation d'OpenGL pour leur interface et faire des effets intéressants. Je pense dans un premier jet faire le zoom/lissage/etc à coup d'OpenGL. Quelqu'un est partant?

Tiens, moi je me souviens d'un commentaire de l'auteur de Glitz/Xgl sur la ml freedesktop disant que Xgl donnerait de meilleur résultat que Glitz pour l'acceleration de Cairo.

Est-ce que tu peux me donner plus d'indications pour ce commentaire de David Reveman ou Peter Nilsson, ça m'intéresse (ML exacte avec mot clés pour le retrouver dans l'archive)?

Cairo utilise Glitz qui utilise OpenGL (en fait OpenGL GLX pour la majoirté des cas). Donc glitz utilise déjà OpenGL. Je ne vois pas où XGL va apporter quelque chose de plus dans la chaîne cairo/glitz/openGL GLX puisqu'a ce niveau là, c'est orthogonal.
On peut accélérer les choses en faisant sauter des couches: GTK directement en OpenGL ou Cairo avec une backend directement en OpenGL.

Ce que je voulais mettre en évidence dans mon message précédent c'est que les drivers OpenGL vont vraiment être poussés trés loin. Si toutes les applications se mettent à utiliser OpenGL pour faire des effets et de l'accélération, il suffit d'imaginer les switchs de contextes du GPU entre les applications (arbre de surfaces 2D dans de la 3D où le compositing va se faire aggressivement). Pour l'exemple, je parlais de gThumb un visualiseur/editeur d'image qui se prête bien à des essais d'accélération matériel à la opengl (il est en C et il est propre). Mélangé avec XGL... je suis curieux de savoir quel driver opengl va encaisser sans broncher.

Cario à une backend Glitz qui lui-même a plusieurs backends: OpenGL GLX, OpenGL EGL, OpenGL AGL etc... Glitz accélère des opérations de dessin avec un sémantique 2D et non 3D.
Pour l'instant, les heureux possésseurs de cartes graphiques qui assurent un peu avec GLX, on vraiment de l'accélération matériel de leur applications 2D!
Mais les vrais pbs vont venir des drivers: en effet, on peut déjà le constater avec les drivers nvidia (ils ont des soucis avec le mix compositing/GLX).
Imaginez: vous avez window manager sur OpenGL ES/EGL à la compiz (sur Xegl quoi) . Votre application de gestion d'images (ex: gThumb) dans son viewport (qui est dans l'univers 3D du window manager!) a decider qu'il va utiliser des textures OpenGL pour faire le rendu des images: zooms et autres effets croustillant avec les shaders OpenGL. Et puis pas de bol, mozilla a décidé que Gecko tape directos dans OpenGL aussi pour faire des effets accélérés par des shaders aussi. Et là, vraiment pas de bol, car toutes vos applications ont décidé d'utiliser les shaders de votre GPU. Et puis, parci parla, par sur la totalité de leur viewport bien sûr.
Et bin, je pense pas trop m'avancer en disant qu'on a mieux intérêt à avoir des drivers ouverts parce que stabiliser des drivers avec un tel niveau de flexibilité... ouch! Rien qu'imaginer les changements de context du GPU me fait peur!

En effet, j'ai jeté un oeil à son code et au code de glitz/cairo.

Il n'y a nul part un moyen d'accéder aux objets OpenGL/EGL/GLX/... sous-jacents pour des applications graphiques utilisant cairo/GTK.

Donc, c'est bien d'avoir un window manager qui fait des effets aguichants, mais si il n'y a que lui que ait le droit d'accèder à toute la puissance des GPUs modernes... humhum...

La vraie difficultée est de fournir l'accès à la puissance de nos GPUs aux applications et je ne pense pas trop m'avancer que cela sera bien plus compliqué qu'un window manager.

Normalement, des applications GTK/cairo/glitz(egl) pour OpenGL ES/EGL devraient y arriver après du travail fait sur l'abstraction de X11(input, message loop? etc.). Mais je ne sais pas si EGL permette de récupérer le niveau de contrôle de X11(par ex: Xinerama). Si quelqu'un a lu les specs EGL, il est le bienvenu pour éclaircir le sujet.

Le PIM arrive cette année, normalement par une mise à jour. Le PIM sous gnome est supposé être géré par l'evolution-data-server. J'avoue que je ne sais pas quelle solution Nokia va adopter (evolution-data-server est peut-être un peu bloatware pour des petites machines: chez moi le processus fait 60Mo en virtual size et 7Mo en résident).
Il me semble qu'il y a une tentative de normalisation avec SyncML, ou du moins un truc dans le genre.
Au fait est-ce quelqu'un sait ou avoir un filtre ogg-vorbis pour que rhythmbox pour Nokia puisse les lire?

J'ai jeté un oeil sur glitz, donc on peut effectivement constuire une surface cairo à partir d'une surface glitz. Mais je ne vois pas à quel moment de la contruction de la surface glitz je peux récupérer un objet me permettant d'accéder directement à l'API opengl pour cette surface. Il semblerait que glitz offre la semantique de l'extension X11 render, mais ne permettent pas d'accéder à la couche inférieure (GLX, EGL, AGL, PIXMAN etc...) pour les applications qui le désirent.

Toute la difficulté est là. Il faut pouvoir exposer de manière plus ou moins standard la puissance des GPUs modernes à ces applications. Il faudrait une extension de cairo ou GTK qui nous permette de récupérer ce "contexte" bas niveau, ici un truc à la OpenGL ou EGL, ou je sais quoi encore.

Perso, je pense que c'est une évolution naturelle du desktop et je ne pense pas qu'on puisse parler de véritable innovation. En tout cas c'est bien que Nat F. ait donné un coup de projo sur le sujet, maintenant que les gars de X.org ont finit le refactoring modulaire, ils vont surement avoir plus de temps à consacrer à cet épineux défi.

D'ailleurs, je me demande bien quelles API les demos de Nat F. utilisent: uniquement des extensions de X11 ou des trucs batards? Pour faire ce que fait son window manager, il doit utiliser OpenGL comme API racine. Est-ce que quelqu'un est rentré dans son code pour voir? (j'ai la flemme).

Merci! Je ne savais pas que cela existait!

Cette norme de shaders fait partie d'OpenGL 2.0. Mais ce n'est pas là où je voulais en venir. Je suis développeur d'une application graphique, j'utilise gtk/cairo pour dessiner mon application: à partir de gtk/cairo, comment je fais pour récupérer un "context" ou je ne sais quoi pour pouvoir programmer les shaders ou autre chose de mon GPU "à la opengl" sur un widget?

Perso, je pense qu'il ne faudrait plus plier les commentaires passés en négatif. J'irai même plus loin jusqu'à retirer le système de pertinence.

A la rigueur un filtre sur la profondeur des commentaires réglable par l'utilisateur devrait suffir. Mais bon, faut une bonne âme pour le coder... pas gagné.

Il est tout à fait marchand pour une certaine entreprise d'avoir des zealots sillionnant le web afin de faire pencher la balance en leur faveur... surtout sur les sites consacrés à linux et aux logiciels libres.

C'est de la communication: il s'agit de manière permanente (harcelante?) d'évoquer certains produits avec un maximum de bonnes vibrations et le reste avec un maximum de mauvaises vibrations. J'ai un pote qui a une boîte spécialisé dans le "buzz marketing"... donc des gens peuvent être payés à plein temps pour faire ce genre de choses.

Il faut détecter ce genre de zealots, ou du moins ce qu'ils produisent, afin de prendre du recul et en faire abstraction. Certains sont plus fins que d'autres et c'est vrai que souvent cela tourne à la pollution de site.

Le libre attire les convoitises... il est tout à fait marchand de voir des entreprises tenter de se l'approprier... doucement... par des moyens plus ou moins subtiles. Perso je vois d'un très mauvais oeil le cheval de .net/mono dans GNOME.