Pour rappel, Xgl est le serveur X basé sur OpenGL livré par Novell dernièrement, accompagné de Compiz, le système d'effets à base de greffons interfaçable avec n'importe quel gestionnaire de fenêtres.
On trouve sur ce site http://www.linuxedge.org/?q=node/58 une nouvelle vidéo ainsi que la présentation de David Reveman (auteur du projet) lors que le XDevconf cette semaine.
On y apprend que Xgl supporte maintenant Xrandr, GLX, Xvideo et EGL (un remplacant à GLX).
Il manque toujours le support pour la rotation, par contre il semblerait que Xgl puisse offrir un bien meilleur support pour les configurations multi écrans.
Sur la vidéo, beaucoup de déjà vu mais on notera quand même quelques effets sympatiques, un quake3 transparent ainsi que l'outil indispensable à la secrétaire: si en exclu à la fin de la vidéo :)
Voila! Reste toujours le problème pour les drivers libres :(
http://www.freedesktop.org/~davidr/xgl-demo1.xvid.avi
Journal Xgl, la suite
10
fév.
2006
# Raaaah
Posté par Guillaume Denry (site web personnel) . Évalué à 10.
Si en plus, ça demande pas une machine trop haut de gamme, ça va faire très très mal.
Je crois qu'on est à l'aube de quelque chose là.
[^] # Re: Raaaah
Posté par Fabimaru (site web personnel) . Évalué à 3.
(Personnellement, j'ai toujours une vieille Radeon 7500)
[^] # Re: Raaaah
Posté par kahal (site web personnel) . Évalué à 10.
(Personnellement, j'ai une vieille nvidia Geforce3 )
[^] # Re: Raaaah
Posté par Donk . Évalué à 2.
[^] # Re: Raaaah
Posté par Mark Havel . Évalué à 5.
[^] # Re: Raaaah
Posté par lasher . Évalué à -1.
[^] # Re: Raaaah
Posté par Sufflope (site web personnel) . Évalué à 8.
[^] # Re: Raaaah
Posté par Guillaume Knispel . Évalué à -1.
[^] # Re: Raaaah
Posté par kahal (site web personnel) . Évalué à 6.
# Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Si on y réfléchit bien, c'est Cegetel qu'on choisit !
Posté par Mark Havel . Évalué à 9.
Et puis personnellement, je refuse que l'on puisse comparer des hauteurs Appleliennes à toute cette fange MSNesque.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Si on y réfléchit bien, c'est Cegetel qu'on choisit !
Posté par xof . Évalué à 10.
Mouarf! des «Hauteurs Appleliennes», non mais qu'est-ce qu'il ne faut pas entendre...
[^] # Re: Si on y réfléchit bien, c'est Cegetel qu'on choisit !
Posté par Guillaume Denry (site web personnel) . Évalué à 9.
Attention à ne pas jeter le bébé avec l'eau du bain.
Moi la transparence des fenêtres, j'en ai rien à foutre. Par contre rien que l'ombrage, je trouve ça pratique et agréable à l'usage, car ça donne de la distinction et de la profondeur aux fenêtres.
Pareil, tourner un cube, je m'en cogne, je vais plus vite à switcher d'écran virtuel avec un raccourci-clavier, par contre l'expose like là, il m'intéresse carrément, ainsi que le ctrl-tab "temps-réel".
[^] # Re: Si on y réfléchit bien, c'est Cegetel qu'on choisit !
Posté par Ludovic F (site web personnel) . Évalué à 2.
On est tous d'accord sur ce point, si c'est libre c'est mieux. Mais le marché de la 3D est ce qu'il est, de grosses sociétés qui ne sont pas près de divulguer leur code source (et ca peut tout à fait se comprendre).
Maintenant voyons le bon côté des choses, celà risque de faire fortement pencher la balance de notre côté. A défaut d'avoir des drivers libres, nous aurons sans doute des drivers qui marchent. Un meilleur respect des standards, ...
[^] # Re: Si on y réfléchit bien, c'est Cegetel qu'on choisit !
Posté par Infernal Quack (site web personnel) . Évalué à 10.
Bref aujourd'hui les cartes graphiques sous linux foutaient pas grand chose et c'est le processeur qui faisait tout. Ok, ça a un avantage: le fait que les drivers des cartes graphiques ne soient pas toujours à la hauteur e souvent proprios. Mais bon si X peut encore fonctionner comme avant avec le choix d'utiliser XGL ou pas, je ne vois pas où est le problème.
C'est un peu comme raler sur KDE et Gnome parce que ça demande des ressources. Bin dans ce cas il y a blackbox, rox, icewm,...
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Si on y réfléchit bien, c'est Cegetel qu'on choisit !
Posté par Guillaume Knispel . Évalué à 0.
???
L'avantage c'est que les drivers de CG sont pourrav et proprio ?
Où il est le LSD ?
[^] # Re: Si on y réfléchit bien, c'est Cegetel qu'on choisit !
Posté par Victor . Évalué à 1.
ca a un avantage, car les drivers des cartes graphiques ne sont pas toujours à la hauteur et souvent proprios, donc ne pas les utiliser etait obligatoire presque.
donc ste pas un avantage mais une obligation en fait :]
# mais l'install...
Posté par djibb (site web personnel) . Évalué à 3.
Mais... sans déconner... ca s'installe comment ? Sans bousiller le serveur actuel ?
J'ai suivi un tuto d'ubuntu mais il n'est plus au gout du jour (manque des trucs), la page de freedesktop : http://www.freedesktop.org/Software/Xgl
est intéressante mais part d'une installation existante et non pas d'une install a cote (j'ai aps super envie que ca pourrisse mon Xorg actuel)
Bref. Si quelqu'un avait trouvé ce tuto extratordinaire que je cherche depuis qques jours...
NB : si un bon samaritain met les sources dans cooker je suis pas contre non plus ;)
[^] # Re: mais l'install...
Posté par Anonyme . Évalué à 2.
Ton arme est le --préfix, et l'initialisation de variables d'environnement qui vont bien.
Moi aussi j'ai cherché le tuto, et quand tu te tente l'install à la main tu comprend très vite pourquoi il n'y en a pas : tu fait face à une myriade de petits soucis, mais tous un peu cons donc tu le résouds tout de suite, mais il y en a tellement, ca vaut pas le coup de faire un tutorial qui ne sera plus valide dans deux mois.
[^] # Re: mais l'install...
Posté par Guillaume Knispel . Évalué à 1.
[^] # Re: mais l'install...
Posté par Matthieu Moy (site web personnel) . Évalué à 5.
[^] # Re: mais l'install...
Posté par kahal (site web personnel) . Évalué à 2.
Tout est expliqué là : http://www.ubuntuforums.org/showthread.php?t=127090 .
Depuis que j'ai fais un tour sur ce lien, mes fênetres sont devenues folles :)
Le plus chaud, c'est le passage sur Dapper étant donné que ce n'est pas cencé être stable. Mais a priori, chez moi, pas de plantages, ca marche très bien.
[^] # Re: mais l'install...
Posté par Aiua . Évalué à 2.
Au final j'ai tous les plugins listés qui marchent sauf le fade, mais ça rame qd même pas mal
[^] # Re: mais l'install...
Posté par kahal (site web personnel) . Évalué à 2.
Notamment cube, expose, zoom, rien ne se passe quand j'utilise les raccourcis clavier :(.
[^] # Re: mais l'install...
Posté par Aiua . Évalué à 1.
par contre le wobble il est fluide chez toi ?
Sur le "popup" de kde aussi ça se voit bien que la fluidité c'est pas encore ça :D
Sinon, j'ai juste expose qui bug un peu, les fenetres qui sont à l'écran avant de se faire exposifier laisse une ombre sur toute leur surface.
Mais qd ça tournera bien, ça sera vraiment agréable, surtout zoom et expose, le reste j'en vois plus difficilement l'utilité à part de faire joli. (bon expose aussi c'est parce qu'il est joli, parce que sinon y a déjà des équivalents)
[^] # Re: mais l'install...
Posté par kahal (site web personnel) . Évalué à 2.
J'ai une geforce3 ti200, xp2500. Ce qui n'est pas la meilleure des architectures.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: mais l'install...
Posté par kahal (site web personnel) . Évalué à 2.
D'ailleurs je l'ai utiliser, mais bizarrement, l'effet wobbly (fenetre tremblante) rame.
Et de plus, il n'y a que les décorations de fenêtres pour gnome, les décorations pour kde
sont en cours de développement.
Sinon pour activer les effets cube et autre, utilise gconf-editor (apps/gnome-composite) pour utiliser d'autre touches. Et pis chez moi faut que je désactive Num-lock...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# Joli mais dangereux...
Posté par sylware . Évalué à 3.
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.
[^] # Re: Joli mais dangereux...
Posté par gnumdk (site web personnel) . Évalué à 1.
>pour des applications graphiques utilisant cairo/GTK.
Bien sur que si, pour preuve le plugins qui fait faire un truc chelou aux menu 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...
Tout est affiché par OpenGL, c'est un serveur X qui utilise OpenGL, donc tout le monde en profite, sans rien faire...
Plus d'explications ici:
http://news.com.com/Novell+seeks+to+boost+Linux+graphics/210(...)
http://news.com.com/Novell+seeks+to+boost+Linux+graphics+-+p(...)
[^] # Re: Joli mais dangereux...
Posté par Simon TRENY . Évalué à 5.
L'effet appliqué sur les menus est effectué par Compiz qui détecte lorsqu'une fenêtre du type "menu" est affichée, et la déforme à ce moment là.
Donc il peux y avoir accélération au niveau de l'affichage "globale" de la fenêtre, mais XGL n'accélère pas le rendu du contenu de la fenêtre (c'est ce qui est le plus lent). Par contre, on pourra voir une accélaration de ce côté là grâce à une utilisation de Glitz pour les applications GTK, ou du moteur OpenGL d'evas pour les applications d'e17 par exemple.
[^] # Re: Joli mais dangereux...
Posté par lesensei . Évalué à 2.
Mais encore une fois, j'ai pas une connaissance profonde du sujet, donc je peux me tromper...
[^] # Re: Joli mais dangereux...
Posté par gnumdk (site web personnel) . Évalué à 2.
Xgl steps in to handle much of the X server's work--to draw a line or fill a rectangle with white, for instance. The use of OpenGL commands lets the graphics hardware manage many operations that otherwise would require constant coordination between the X server and its applications, Friedman said.
"We're offloading a lot of the work to the hardware," Friedman said. "The result is things look and feel a lot smoother."
For example, the video hardware can store whatever information is contained in windows that have been hidden by other windows. That means the contents of the hidden panes can be redrawn quickly when an upper window is moved and the window underneath is revealed. In contrast, with regular X servers, the text underneath must be retrieved by numerous requests by the X server.
Xgl accelerates Cairo, so its future use will benefit from hardware acceleration, Friedman said.
"If you're using Cairo, all your Cairo operations are accelerated--fonts, windows, special effects," Friedman said. "In terms of vectorizing the desktop, this moves us way ahead."
[^] # Re: Joli mais dangereux...
Posté par Simon TRENY . Évalué à 5.
Mais non, tout le monde n'en profite pas!
[^] # Re: Joli mais dangereux...
Posté par lesensei . Évalué à 2.
Par contre, personnellement, je croyais que Cairo utilisait déjà partiellement l'accélération matérielle lorsque celle-ci était disponible, je suis donc un peu perdu.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Joli mais dangereux...
Posté par Simon TRENY . Évalué à 3.
[^] # Re: Joli mais dangereux...
Posté par lesensei . Évalué à 2.
Maintenant, je n'ai pas les compétences requises pour juger de la véracité de cette annonce, mais tant qu'on ne me prouve pas le contraire, je vois pas pourquoi ce serait impossible. Genre si ils ont créé un autre backend cairo, qui utilise directement XGL.
Toujours est-il, avec XGL, le contenant des fenêtres est accéléré, et le contenu l'est toujours, je vois pas de raison de râler tant que les autres serveurs X et les autres backend Cairo restent à jour. À moins qu'on ne veuille surtout rien changer, et à ce moment, le bureau Linux, il va pas rester intéressant longtemps...
[^] # Re: Joli mais dangereux...
Posté par sylware . Évalué à 1.
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!
[^] # Re: Joli mais dangereux...
Posté par gnumdk (site web personnel) . Évalué à 1.
>OpenGL EGL, OpenGL AGL etc...
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.
[^] # Re: Joli mais dangereux...
Posté par sylware . Évalué à 2.
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.
[^] # Re: Joli mais dangereux...
Posté par gnumdk (site web personnel) . Évalué à 2.
De tete, je me souviens que David disait que Glitz avait été écrit dans une optique de performance, pas de qualité.
Xgl lui est capable d'offrir une qualité optimale (plus lent que glitz mais avec anti aliasing bien mieux que glitz).
Bon, je dis ca de tete, je suis pas un expert....
En tout cas, une chose sur dont je me souviens:
Il y'a Cairo, glitz, OpenGL d'un coté et Cairo, xlib, XGL de l'autre.
Et il semblait que Cairo -> xlib -> Xgl soit capable d'avoir de bonne perf et c'est pour ca que depuis le début je persiste et signe: Xgl accelere cairo comme le dit lui meme David dans le lien ci dessus...
Je te donnerai le lien via le site si je le retrouve...
[^] # Re: Joli mais dangereux...
Posté par sylware . Évalué à 2.
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.
[^] # Re: Joli mais dangereux...
Posté par Rémi Hérilier . Évalué à 3.
- une unité 2D (exploitée pour le dessin des interfaces anté MacOSX, Xgl, Vista)
- une unité 3D (exploitée par OpenGL ou Direct3D)
- une unité de traitement vidéo (overlay, (dé)compression, etc.)
Si les 2 dernières sont améliorées au fil du temps, la première en revanche ne l'est plus du tout. Il suffit de voir le battage que font Nvidia & consort sur les nouvelles GPU qu'ils sortent tous les 6 mois/1 an, ça ne parle que de vidéo et de 3D. On aura donc beau dire mais les GPU "modernes" savent afficher plus rapidement une simple ligne avec l'unité 3D qu'avec la 2D (et il en est de même pour toutes les primitives 2D).
L'extension que tu décris pour normaliser les "accès bas niveau" existe déjà, c'est le couple OpenGL/GLX. Je ne pense pas d'ailleurs qu'une extension soit le plus efficace (c'est une extension, donc un comportement rajouté). Permettre le choix entre un rendu 2D et un rendu 3D (au sens utilisation de l'unité 2D ou 3D) serait, selon moi, plus pertinent (et j'y vois aussi une facilité lors de la configuration de X:)
Pour pour le backend 2D, on aurait par exemple :
toolkit <-> API de X <-> backend X 2D <-> pilote <-> matériel
et pour le backend 3D :
toolkit <-> API de X <-> backend X 3D <-> OpenGL/GLX <-> pilote <-> matériel
On peut d'ailleurs faire le rapprochement avec le
toolkit <-> API vectoriel <-> backend 3D <-> OpenGL/GLX <-> pilote <-> matériel
qu'ont Gtk+2.8 et Qt4.
Après, j'suis pas dev chez Xorg/Novell/autre, alors mon avis me pèse pas lourd =)
Il est d'ailleurs intéressant de voir que Xgl utilise glitz, on retombe sur le
toolkit <-> API de X <-> "backend 3D" <-> OpenGL/GLX <-> pilote <-> matériel
Peut-être qu'à terme, on verra glitz intégré à X =)
On parle des effets de compositions que permettent la transparence et les textures mais d'autres mécanismes tels que les VBO (Vertex Buffer Object) peuvent apporter d'autres avantages comme réduire l'empreinte d'un programme en mémoire centrale en stockant des informations dans la mémoire graphique. Cela permet ainsi de minimiser l'envoi d'information sur le bus graphique.
Après, on peut se permettre de rêver. Pour la simple page de rédaction que j'utilise actuellement, les éléments statiques tel le bouton "Vérifier" n'auraient plus besoin d'être redessiné entièrement mais juste à donner un ordre comme "desssine le widget XXyyZZ_0324 à telle position". Comparé à "dessine le rectangle plein P1 P2 P3 P4 - dessine le rectangle vide P1 P2 P3 P3 - écrit 'Vérifier' avec tels paramètres", le gain serait énorme.
Pour revenir sur la surcharge de la GPU à cause de l'abus d'effets (que tu évoques dans un post précédent), le problème est autre. Si tu veux jouer à Doom3, tu as une grosse machine, si c'est pour faire du bureautique/web/mp3^Wvorbis, une configuration plus modeste est plus que suffisante. Après, si ça laggue car il y a trop d'effets, c'est le problème de l'utilisateur pas celui des développeurs (enfin si, l'optimisation est de leur ressort mais c'est encore un autre problème;)
D'ailleurs, à ce que j'en ai compris, Xgl n'utilise que :
- des textures pour stocker le contenu des fenêtres (widgets ?)
- des polygones pour faire un support aux textures
- du rendu dans une texture pour manipuler 2D, 3D et vidéo dans un tout cohérent
- la transparence pour aider à l'appréhension du bureau
- des effets de couleur comme la désaturation
- un peu de physique empirique pour les effets sur les fenêtres
Somme toute des trucs implémentés dans les GPU depuis belle lurette (je ne sais plus quelle démo a été faite sur un celeron avec un proc graphique genre i810).
Toutefois, une utilisation des shaders pour améliorer le filtrage d'image (comme les summed area) serait une utilisation saine comparé à afficher tout le texte visible à l'écran avec un effet de bumpmapping /o\
Je ne pense pas que l'utilisation directe d'OpenGL dans une application pour faire des effets soit maline. D'ailleurs, les travaux actuels portent plus sur la vectorisation (et donc aussi la simplification) de l'affichage (Cf Cairo et Arthur pour ne pas les citer). Le but est de ressortir des cartons un concept assez vieux : avoir la même API d'affichage quelque soit le support (écran, imprimante, pdf, image ou que sais-je encore). Un fois ces mécanismes stables et éprouvés, ils pourront se pencher sur la suite (utilisation de shader et de toutes autres joyeusetés futures). Mais pour l'instant, Qt4 n'est pas encore majoritairement utilisé et les backends de Cairo sont en cours de finalisation. Donc attendons de voir avant de prendre peur ;)
les 2¢ d'un réinventeur de roue chevronné /o\
[^] # Re: Joli mais dangereux...
Posté par sylware . Évalué à 3.
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.
[^] # Re: Joli mais dangereux...
Posté par Rémi Hérilier . Évalué à 2.
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!
il n'y a que GLX qui est dans X, OpenGL est indépendant de tous "système de fenêtrage" (après, qu'ATI ou Nvidia fasse des gros hacks qui lient OpenGL à X, c'est leur problèmes, on verra leur rapidité à s'adapter à EGL).
Ceci étant, en parcourant les specs d'EGL, j'ai eu l'impression de lire les specs de GLX, surtout dans la manière de découper une contexte en un état client et un état serveur (ce que fait GLX pour permettre d'encapsuler OpenGL dans le protocole X). Au final, EGL m'apparait comme une API unifiant GLX/WGL/AGL et pouvant reposer sur un système de fenêtrage. Avoir un EGL marchant sur X ou sur le framebuffer de Linux ne changera rien pour le toolkit utilisé (graphiquement parlant).
Le contexte de l'unité 3D (en supposant qu'il n'y a pas une contexte unique pour toute la GPU) n'est pas énorme au point d'atteindre plusieurs Mo : Il y a les piles de matrices de transformations (la plus grande pile doit faire 32 éléments), les états comme le mode de remplissage des polygones (quelques champs de bits) , les sources de lumières (8 grand max), etc. Les textures, shaders et autre VBO sont déjà en VRAM. De plus, des infos sont stockées côté pilotes, pas côté GPU. Comparé à une map de TuxRacer, un contexte doit être insignifiant.
Il faut aussi garder en tête qu'OpenGL est un flux de données et c'est le pilotes qui se charge de le gèrer (pour t'en convaincre regarde l'utilité de glFinish). Si glXMakeCurrent (et son équivalent eglMakeCurrent) doit attendre la fin du traitement d'une autre application 3D, il attendra avant de prendre la main. Le fait que Xgl soit fonctionnel sur un Celeron et un proc graphique i810 montre qu'il n'y a pas trop de soucis à se faire de ce côté là (je garde une réserve car on n'a pas vu de vidéos de Xgl/Compiz avec des oo.org et autres grosses applications, ça se trouve, c'est catastrophique):
Avant on trouvait que le WM/DM se trainait le bit avec un petit proc, il faudra être conscient que la GPU peut en faire de même ...
Rem
[^] # Re: Joli mais dangereux...
Posté par sylware . Évalué à 3.
[^] # Re: Joli mais dangereux...
Posté par Rémi Hérilier . Évalué à 1.
# xgl + enlightenment ?
Posté par chimrod (site web personnel) . Évalué à 1.
j'attend de voir les screenshots !
[^] # Re: xgl + enlightenment ?
Posté par Jean Roc Morreale . Évalué à 5.
# Configuration requise
Posté par Alex . Évalué à 5.
J'ai lu ceci sur la page d'openSuse :
( http://en.opensuse.org/Xgl )
ATI / open source driver "radeon"
* Driver does not accelerate blits from back buffer to front buffer which makes it very slow. The driver will soon be updated and should then work OK.
Ce qui semble vouloir dire qu'une Radeon 8500 ou 9000 (supportée par les pilotes libres, assez performante dans le cas de la 8500/9100, et pas chère en occasion) serait à même d'être une bonne candidate une fois le bug corrigé ?
Que sont les "blits" dont il est question ?
# Question matos : sur un portable faisant tourner tuxracer ?
Posté par plagiats . Évalué à 2.
P4 1.7Ghz, 256M PC-133, carte graphique : Intel 845GL
Pensez-vous que XGL peut fonctionner sur ce type de config ?
Merci :)
Note : A priori je vais m'installer une dapper sur une partition à part et tester je vous tiendrai au courant.
[^] # Re: Question matos : sur un portable faisant tourner tuxracer ?
Posté par Mark Havel . Évalué à 2.
[^] # Re: Question matos : sur un portable faisant tourner tuxracer ?
Posté par Uvoguine . Évalué à 4.
Donc en attendant un peu, ça ira mieux je crois.
[^] # Re: Question matos : sur un portable faisant tourner tuxracer ?
Posté par plagiats . Évalué à 2.
je vais attendre la sortie de dapper et voir si à ce moment là, el bugo é résoluto.
[^] # Re: Question matos : sur un portable faisant tourner tuxracer ?
Posté par plagiats . Évalué à 2.
Dès que je remplace Xorg par X et que je relance GDM mon écran devient inutilisable (couleurs dans tous les sens, illisibles, on tape à l'aveugle). Une fois que je lance compiz, boum je n'ai plus que la fenetre de terminal d'affichée. Le reste de l'écran est noir. Le cube tourne mais pas dans tout l'écran, seulement dans un coin.
Par contre en remettant Xorg en place, dapper fonctionne "normalement".
Bref tout ça pour dire que : Attention les enfants, le message d'avertissement n'est pas là pour rien, ce n'est pas encore stable et ca tourne pas encore avec les cartes graphiques intel.
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
# Interfacable ?
Posté par MsK` . Évalué à 2.
Heu sur ? parce que quand j'ai voulu lancer Kwin il a refusé rouspettant qu'il y avait déjà un WM en route.
[^] # Re: Interfacable ?
Posté par kahal (site web personnel) . Évalué à 2.
Et plutôt Compiz, gestionnaire de fenêtres incluant un système d'effets à base de greffons.
# live cd ?
Posté par manatlan (site web personnel) . Évalué à 9.
[^] # Re: live cd ?
Posté par z a . Évalué à 2.
# compatibilité avec les autres wm ?
Posté par efyx (site web personnel) . Évalué à 3.
Pour ma part j'utilise FVWM et j'aimeré bien savoir si je peux adapaté XGL a mon petit bureau ?
Merci ;)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Retour,
Posté par deelight . Évalué à 2.
En plus je pensais installer ça dans un coin et ne le lancer qu'occasionellement pour épater les copains... et finalement ça s'avère super utilisable et pratique (et je n'ai pas encore eu de problemes de stabilité). Du coup c'est mon serveur X "classique" que je vais laisser dans un coin !
# Informations complémentaire
Posté par Markov . Évalué à 2.
Pour la remarque de David sur cairo->xlib->xgl plus rapide/correct que cairo->glitz l'explication c'est que cairo->xlib utilise l'extension XRender pour le rendu. Hors il me semble que le backend XRender est bcp plus mature que glitz et comme Xgl accelere XRender en OpenGL au final là chaîne cairo->xlib->xgl est mieux que cairo->glitz.
Voilà la manière dont je comprends les choses. Suivre celà c'est un peu techniques et on se perd vite entre les differents niveaux. Un petit schéma peut aider :)
http://www.freedesktop.org/wiki/Xegl
De plus EGL ne remplace pas GLX. GLX c'est l'encapsulation de command OpenGL dans le protocol X et EGL c'est une implementation stand-alone d'OpenGL (voir le lien ci-dessus). Donc avec xgl on aura toujours GLX voir même bientôt AIGLX (le truc de redhat qui au final est complémentaire de xgl) et tout sera accéléré.
Reste à se battre pour des drivers libre. Avoir un OS libre avec des drivers propriétaire, personnelement, je considére ca comme un paradoxe. Vous perdez le contrôl de l'OS...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.