Journal Xgl, la suite

Posté par (page perso) .
Tags : aucun
0
10
fév.
2006
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
  • # Raaaah

    Posté par (page perso) . Évalué à 10.

    Ce truc là est une bombe.
    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 (page perso) . Évalué à 3.

      Génial, tout le monde va demander des drivers proprios, c'est la fête. Triste dommage collatéral.

      (Personnellement, j'ai toujours une vieille Radeon 7500)
      • [^] # Re: Raaaah

        Posté par (page perso) . Évalué à 10.

        Génial, tout le monde va demander des drivers libres, c'est la fête. Merveilleux dommage collatéral.

        (Personnellement, j'ai une vieille nvidia Geforce3 )
        • [^] # Re: Raaaah

          Posté par . Évalué à 2.

          Que dire moi et ma rage 128 pro?
          • [^] # Re: Raaaah

            Posté par . Évalué à 5.

            Que tu vas devoir t'acheter une carte graphique un peu plus récente...
            • [^] # Re: Raaaah

              Posté par . Évalué à -1.

              Euh, et pour ma Trio 64V+, il se passe quoi ? Sans parler de ma Matrox Millenium ... :-/
          • [^] # Re: Raaaah

            Posté par (page perso) . Évalué à 6.

            Que tu ne va pas activer les effets graphiques.
  • # Si on y réfléchit bien, c'est Cegetel qu'on choisit !

    Posté par . Évalué à 6.

    > Voila! Reste toujours le problème pour les drivers libres :(

    Et encore pour longtemps, surtout si la 3D devient une partie vitale du bureau ...

    Au passage, j'en profite pour signaler que ce qui me fait marrer ici, c'est les kékos qui se moquent de MSN et ses images fonds, ses sons, ses wizz, ses wozz et autres zigouïgouïs visuels, et qui après viennent jouer les analystes visionnaires du desktop en bavant comme des limaces devant la luxure visuelle sur ce genre de vidéo.

    « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

    • [^] # Re: Si on y réfléchit bien, c'est Cegetel qu'on choisit !

      Posté par . Évalué à 9.

      Sauf que ce genre de chose est tout de même nettement plus classe, hype et in que de vulgaires grossiéretés de smilies et autres conneries kikoolesques. C'est aussi potentiellement plus utile pour le geek moyen : par exemple, regarder un film et grâce à la transparence, chatter sur IRC, surfer sur internet, travailler, coder...

      Et puis personnellement, je refuse que l'on puisse comparer des hauteurs Appleliennes à toute cette fange MSNesque.
      • [^] # Re: Si on y réfléchit bien, c'est Cegetel qu'on choisit !

        Posté par . Évalué à 10.

        > C'est aussi potentiellement plus utile pour le geek moyen

        Voilà, tu as bien résumé ma pensée en deux mots : potentiellement, geek.

        > regarder un film et grâce à la transparence

        Entièrement d'accord : quelle utilité d'exiger des films DVD haute définition avec son Dolby Surround THX High Control à double raisonnance réverbérante quand on peut regarder ces mêmes films sur un PC via une transparence avec des écouteurs de radio FM à 1 euros.

        > regarder un film grâce à la transparence, chatter sur IRC, surfer sur internet, travailler, coder...

        On doit chercher l'intrus ? Au hasard : travailler ? /o\

        « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

      • [^] # Re: Si on y réfléchit bien, c'est Cegetel qu'on choisit !

        Posté par . Évalué à 10.

        Et puis personnellement, je refuse que l'on puisse comparer des hauteurs Appleliennes à toute cette fange MSNesque.


        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 (page perso) . Évalué à 9.

      Bingo ! On aura attendu seulement le deuxieme thread de ce journal pour avoir ce genre de commentaire facile et stupide où l'auteur place allègrement sur le même plan les effets visuels de MSN avec les avancées ergonomiques de Mac OSX. Ah ça, on allait pas y échapper bien longtemps, ha ha ha.
      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 (page perso) . Évalué à 2.

      > Voila! Reste toujours le problème pour les drivers libres :(

      Et encore pour longtemps, surtout si la 3D devient une partie vitale du bureau ...


      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 (page perso) . Évalué à 10.

      Sans prendre en considération les "effets graphiques" que tu considères comme des gadgets, le fait de laisser le boulot à la carte graphique de gérer l'affichage est tout de même beaucoup plus logique que les hacks actuels pour gérer des pseudos-ombres, de la pseudo-transparence, des pseudos preview d'applications en info-bulles, des pseudos-exposé,....

      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

  • # mais l'install...

    Posté par (page perso) . Évalué à 3.

    Je suis tout a fait prêt pour le grand saut et tester tester tester, rapporter les bugs et tout et tout...
    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 . Évalué à 2.

      Meuuuh si tu peux faire une install à côté, tu crois qu'ils codent tous sous vim dans une console texte ?
      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 . Évalué à 1.

        J'ai pas compris le rapport avec vim et les consoles texte.
        • [^] # Re: mais l'install...

          Posté par (page perso) . Évalué à 5.

          Les développeurs ont probablement un serveur X stable avec leur environnement de développement, et lancent Xgl pour le test sans tout faire planter. Ceci dit, ils peuvent aussi avoir plusieurs machines.
    • [^] # Re: mais l'install...

      Posté par (page perso) . Évalué à 2.

      Pour ubuntu : passe sur Dapper, télécharge les pré-compilés ou compile toi-même le CVS de freedesktop.org.
      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 . Évalué à 2.

        avec ce même tuto, j'ai fait marcher le bouzin sur ma SID, bon j'ai un peu tricher parce que j'ai utiliséles paquets ubuntu listés sur le site pour XGL & co. (j'ai du aussi aller piquer libGL dans le paquet mesa d'ubuntu, parce que ça voulait pas marcher avec celui de ma SID. C'est beau la compatibilité binaire :D

        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 (page perso) . Évalué à 2.

          Moi, ca ne rame pas du tout (Nvidia) par contre tous les effets ne marche pas.
          Notamment cube, expose, zoom, rien ne se passe quand j'utilise les raccourcis clavier :(.
          • [^] # Re: mais l'install...

            Posté par . Évalué à 1.

            en utilisant gconf-editor et en mettant +une touche ou un bouton pour chaque action, j'ai tout qui marche

            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 (page perso) . Évalué à 2.

              Oui wobble est terriblement fluide et justement, je m'amuse avec les infobulles de Kde...
              J'ai une geforce3 ti200, xp2500. Ce qui n'est pas la meilleure des architectures.
      • [^] # Re: mais l'install...

        Posté par (page perso) . Évalué à 2.

        Ce tuto utilise glxcompmgr et pas compiz qui n'est pas encore disponibles.

        Pour ma part, je n'arrive pas à initialiser les modules zoom, cube, expose ni rotate. Je ne peux jouer qu'avec wobbly et shadow en fait. Pas cool :(
        • [^] # Re: mais l'install...

          Posté par (page perso) . Évalué à 3.

          J'ai oublié de lire le petit PS du howto :

          "Compiz is released. Lets get it testet and included in the howto."

          Bonne nouvelle :)
          • [^] # Re: mais l'install...

            Posté par (page perso) . Évalué à 2.

            Maintenant le tutorial explique aussi comment compiler et utiliser compiz.

            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...
            • [^] # Re: mais l'install...

              Posté par (page perso) . Évalué à 2.

              Salut,

              Oui, moi aussi j'y suis arrivé. J'ai d'ailleur laissé un commentaire sur le thread. Pour les décoration de fenêtre, c'est certainement une bogue car le module existe, mais il ne se charge pas. Pareil pour shadow, je crois.

              Sinon, wobbly est aussi très préliminaire, on n'a l'éffet à la création de fenêtre, pas au déplacement, ni à la réduction, bref, c'est pas étonnnant.

              Chez moi, cube, rotate, zoom, etc. ont bien fonctionné :) j'ai sans doute modifié pour Zoom.

              J'ai testé avec une vidéo, et même deux. Faut dire que la video fait tout de suis grimper le proco. Avec totem, le changement de video créer un gros lag ! (j'avais utilisé la liste de video ogg d'Ubuntu).

              Faut noter qu'on ne peut pas encore utilise gksu ou gksudo. M'enfin, c'est pas trop grave :)

              Franchement, c'est drôlement prometteur.
              • [^] # Re: mais l'install...

                Posté par . Évalué à 2.

                > Faut noter qu'on ne peut pas encore utilise gksu ou gksudo. M'enfin, c'est pas trop grave :)

                Ça devrait venir de la manière utilisée par ses programmes pour "grabber" (comprendre "demander l'exclusivité") le clavier au moment de la saisie du mot de passe. Comme alternative, tu peux utiliser gnomesu qui s'utilise aussi simplement que :

                $ gnomesu -u <USER> -c <COMMAND> <ARGUMENTS>

                USER es le nom d'utilisateur sous lequel on souhaite exécuter la commande COMMAND en lui passant les arguments ARGUMENTS.

                « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

  • # Joli mais dangereux...

    Posté par . Évalué à 3.

    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.
    • [^] # Re: Joli mais dangereux...

      Posté par (page perso) . Évalué à 1.

      >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.

      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 . Évalué à 5.

        Euhh... non. XGL récupère la "texture" de la fenêtre qui, quant à elle, est dessinée en software (enfin ça dépend du toolkit utilisé: Gtk peux faire du software ou passer par OpenGl avec Glitz). Donc il n'y a pas d'accélération au niveau du rendu du contenu de la fenêtre. Et ensuite cette texture est affichée avec OpenGL ce qui permet de rendre la fenetre transparente, ou de la déformer.
        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 . Évalué à 2.

          Je vais peut-être, voire sûrement, dire une connerie, mais c'est pas Glitz qui est censé permettre à une application GTK+ d'accéder, via l'API Cairo, à l'accélération matérielle ? Ce qui signifierait que XGL est à Xorg ce que Glitz est à Cairo: une implémentation de ses APIs utilisant le GPU plus que le CPU.
          Mais encore une fois, j'ai pas une connaissance profonde du sujet, donc je peux me tromper...
        • [^] # Re: Joli mais dangereux...

          Posté par (page perso) . Évalué à 2.

          T'aurais pu aller voir mes liens quand meme:

          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 . Évalué à 5.

            Encore une fois, le rendu du contenu même de la fenêtre n'est pas accéléré. Tu prends une appli GTK, une appli QT ou une appli evas, le rendu ne sera pas accéléré. Si tu veux un widget semi transparent, ou si tu veux agrandir (scalé) une image tout se fera encore par le CPU. Par contre comme tu le dis à la fin, il est possible de passer par Glitz pour accélérer Cairo (et donc GTK) en utilisant OpenGL.
            Mais non, tout le monde n'en profite pas!
            • [^] # Re: Joli mais dangereux...

              Posté par . Évalué à 2.

              Le monsieur te dit que tout ce qui utilise Cairo profitera de l'accélération permise par XGL. Sachant que GTK+ utilise maintenant Cairo pour le rendu, le rendu du contenu de la fenêtre aussi sera accéléré. Par contre, je ne sais pas pour Qt et autres, mais dans tout les cas, il existe au moins une API de haut niveau (Cairo) qui permet aux applications de tirer elles aussi avantage de XGL, ce qui était, si je ne m'abuse, ton point de départ.
              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.
              • [^] # Re: Joli mais dangereux...

                Posté par (page perso) . Évalué à 3.

                Salut,

                cairo utilise glitz pour accélérer le rendu. mais il peut utilise un autre backend. (sans accélération).

                Ave.
              • [^] # Re: Joli mais dangereux...

                Posté par . Évalué à 3.

                Cairo (et donc GTK) peut en effet être accéléré en utilisant le backend Glitz qui se sert d'OpenGL, et ça c'est pas nouveau. XGL n'a rien à voir la dedans. La seul nouveauté, c'est qu'XGL permet de faire du composite sur une fenêtre contenant de l'OpenGL, ce qui n'était pas possible avec les précédents composite managers. Ca permet par exemple comme la vidéo le montre de jouer à Quake III dans une fenêtre transparente. Mais il n'y aura pas d'accélération entre un GTk tournant avec Glitz sur XGL et un GTK tournant avec Glitz sur un serveur X normal (plutôt une décélaration même)
                • [^] # Re: Joli mais dangereux...

                  Posté par . Évalué à 2.

                  Je savais bien pour Glitz, puisque j'en parle un peu plus haut.
                  Xgl accelerates Cairo

                  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 . Évalué à 1.

                    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!
                    • [^] # Re: Joli mais dangereux...

                      Posté par (page perso) . Évalué à 1.

                      >Cario à une backend Glitz qui lui-même a plusieurs backends: OpenGL GLX,
                      >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 . Évalué à 2.

                        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.
                        • [^] # Re: Joli mais dangereux...

                          Posté par (page perso) . Évalué à 2.

                          Je n'ai plus le lien...

                          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 . Évalué à 2.

                            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.
                            • [^] # Re: Joli mais dangereux...

                              Posté par (page perso) . Évalué à 3.

                              Il ne faut pas oublier qu'un processeur graphique est décomposé en (en gros) 3 sous systèmes :
                              - 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 . Évalué à 3.

                                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.
                                • [^] # Re: Joli mais dangereux...

                                  Posté par (page perso) . Évalué à 2.

                                  Oups, c''est vrai que tout mon raisonnement se basait sur le client X générique et non sur un client plus spécifique comme Xgl =)

                                  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 . Évalué à 3.

                                    Tiens? tu as un code snippet d'OpenGL qui n'a pas besoin de X11?
                                    • [^] # Re: Joli mais dangereux...

                                      Posté par (page perso) . Évalué à 1.

                                      Non, je dis juste que les specs d'OpenGL n'impose aucunes dépendances à quoi que ce soit. C'est à GLX de faire le lien entre les primitives de X11 et OpenGL et non à OpenGL d'utiliser directement X11. Ceci étant, entre théorie et pratique, y'a souvent une belle différence ;)
  • # xgl + enlightenment ?

    Posté par (page perso) . Évalué à 1.

    J'imagine le bureau du geek : xgl couplé avec enlightenment dr17...

    j'attend de voir les screenshots !
  • # Configuration requise

    Posté par . Évalué à 5.

    J'avoue avoir été impressionné par la démo, tout semble extrêmement réactif. Ceci dit, quelqu'un aurait-t'il une idée de la configuration utilisée/requise pour faire fonctionner ça si bien ?

    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 . Évalué à 2.

    J'ai un portable Samsung v20 dont la carte graphique intel me permet de jouer à Tuxracer / afficher les écrans de veilles opengl pas trop poussés en utilisant les pilotes libres fournis avec ma ubuntu.

    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 . Évalué à 2.

      Je pense que cela a quand même beaucoup de chances de ramouiller sévèrement pour une carte graphique intégrée qui ne gère même pas les pixels shaders. Maintenant, je n'ai pas essayé et peut-être que ça va tourner très bien.
    • [^] # Re: Question matos : sur un portable faisant tourner tuxracer ?

      Posté par . Évalué à 4.

      D'après http://en.opensuse.org/Xgl
      Intel / open source driver "i810"
      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.
      XVideo YV12 surfaces are hardware accelerated, but due to a bug in the driver the video will miss one of the color channels, leading to false greenish/orange colors. This has to be investigated.

      Donc en attendant un peu, ça ira mieux je crois.
      • [^] # Re: Question matos : sur un portable faisant tourner tuxracer ?

        Posté par . Évalué à 2.

        ahhhh bien répondu... bon bah je ferais pas ca ce soir comme prévu.
        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 . Évalué à 2.

          Bon j'ai testé. Ca marche pas. Je ne me plains pas, c'est pour informer :

          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.
  • # Avancées ergonomiques ?

    Posté par (page perso) . Évalué à 10.

    Salut à tous,

    Il faut rendre à César ce qui est à César et saluer l'anticipation exceptionnelle d'Apple sur les interfaces graphiques accéléré.

    Cependant, je trouve que le bureau présenté par Novel n'est pas qu'un clone de Mac OS X. Je trouve qu'ils ont notablement amélioré l'ergonomie et la perception de l'envirronement.

    Concrètement, je suis très interressé par l'effet magnétique des fenêtres, extrêmement fluide et appréciable, ce qui augmente nettement l'utilisabilité de ce genre de fonctionnalité. Souvent, le magnétisme des fenêtres peut faire penser à une bogue : "bah, elle bouge plus".

    Il en est de même pour la réduction des fenêtres, Le déplacement des fenêtres comme une feuille de papier.

    Amha, c'ests là que l'accélération n'est pas un joujou de MSNiens, mais un potentiel d'ergonomie épatant. Bien qu'actuellement, les effets sont souvent exagéré, avec le temps et suivant les distributions, les effets seront certainement plus sobre, et personne ne regrettera le temps des trainés de fenêtre, etc.

    Ave.
  • # Interfacable ?

    Posté par . Évalué à 2.

    Compiz, le système d'effets à base de greffons interfaçable avec n'importe quel gestionnaire de fenêtres.


    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 (page perso) . Évalué à 2.

      C'est plutôt Glxcompmgr, le système d'effets à base de greffons interfaçable avec n'importe quel gestionnaire de fenêtres.

      Et plutôt Compiz, gestionnaire de fenêtres incluant un système d'effets à base de greffons.
  • # live cd ?

    Posté par (page perso) . Évalué à 9.

    y a pas un live cd qqpart qui permettrait de tester ça, bien ficelé ?
    • [^] # Re: live cd ?

      Posté par . Évalué à 2.

      moi j'aimerais bien déjà même que des binaires, j'ai tenté de compiler tout ça pendant plusieurs heures mais je suis arrivé à rien.
  • # compatibilité avec les autres wm ?

    Posté par (page perso) . Évalué à 3.

    Je trouve étrange que personne n'ai demander ca avant moi....

    Pour ma part j'utilise FVWM et j'aimeré bien savoir si je peux adapaté XGL a mon petit bureau ?

    Merci ;)
  • # Retour,

    Posté par (page perso) . Évalué à 10.

    Salut à tous,

    J'ai installé compiz et j'ai réussi à activer tout les modules dans le bon ordre. C'est tout simplement époustouflant. Objectivement, je n'ai jamais vu l'accélération graphique autant modifier la perception de son bureau !

    évidemment, les réglages sont encore trop excessifs, mais c'est pour régaler les yeux des alpha-testeurs, avant de retourner à un truc plus sobre.

    Le cube en 3D est extrêmement bien rendu, ça va attirer les utilisateur vers l'utilisation des bureaux virtuels. L'effet élastique des fenêtre augmente nettement la perception des mouvements et notemment du magnétismes aux bords. Le "switcher" entre fenêtre avec aperçu dynamique est vraiment bon, c'est agréable de naviguer entre des fenêtre et pas entre 3 icônes de firefox, d'autant que toutes les fenêtres sont transparentes sauf celle avec le focus, bref, c'est vraiment un plus en terme d'ergonomie.

    On savait que Novell travaillais beaucoup l'ergonomie (cf leurs vastes enquêtes, etc.), mais là, ils ont vraiment montré l'amélioration de l'ergonomie grâce à l'accélération matériel, bien plus qu'Apple ou MS.

    Vraiment épaté 8O
    • [^] # Re: Retour,

      Posté par . Évalué à 2.

      Pareil pour moi, je suis scotché.
      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 . Évalué à 2.

    Xgl est un serveur X qui utilise OpenGL donc toutes applications X qui se connectent à un serveur Xgl utilisera OpenGL (sans le savoir) et pourra donc être accéléré (cairo ou pas cairo dès que celà utilise le protocol X c'est accéléré).

    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 à ceux qui les ont postés. Nous n'en sommes pas responsables.