• # released ?

    Posté par  (site web personnel) . Évalué à 3.

    La page chez novell contient des videos et un lien vers le cvs ou c'était déja présent.

    Both projects are being hosted on freedesktop.org and the latest code can be found in the CVS repository. Link to source code and tarballs for public download: http://cvs.freedesktop.org/xorg/xserver/xorg/hw/xgl/?only_wi(...) (The latest Xgl source code can be found in the xg-0-0-1 branch of the Xorg tree).

    C'est quoi qu'ils appellent releaser ? Avoir mis une page page sur leur site (http://www.novell.com/linux/xglrelease/ ) qui pointe vers les CVS et le poster sur des blogs ?

    • [^] # Re: released ?

      Posté par  (site web personnel) . Évalué à 1.

      il y a déja un package de Xgl dans dapper. je ne l'ai pas testé pensant que sur la carte graphique de mon portable (une intel i915) ca ne donnerait pas grand chose et n'ayant pas non plus trouvé d'info sur les modifs a faire dans la conf de X.

      mais bon le package existe ...... (et les libs qui vont avec aussi)

      • [^] # Re: released ?

        Posté par  . Évalué à 5.

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

    • [^] # Re: released ?

      Posté par  (site web personnel) . Évalué à 3.

      Si tu lisais le lien fourni dans le journal t'aurais trouvé :
      "Xgl has already been checked into the public repositories, Compiz will be checked in after David Reveman's presentation at the X conference."
      ;)

    • [^] # Re: released ?

      Posté par  . Évalué à 3.

      Un autre point de vue sur leur manière de travailler:
      http://aseigo.blogspot.com/2005/12/bit-more-on-xgl.html

      Tout ça ne me dit toujours pas à quoi ça sert.

    • [^] # Re: released ?

      Posté par  (site web personnel) . Évalué à -3.

      Il faut quand même préciser que sur les captures du site de novell, si c'est moche, c'est parce que c'est gnome :d.

      Pas que les winwins pensent que même Vista sera moins moche que ce qui se fait sous Linux quoi ;).

  • # Pas facile...

    Posté par  (site web personnel) . Évalué à 5.

    C'est magnifique, mais ça paraît toujours être des trucs de fou, que seuls les développeurs peuvent installer, après en chier pendant des WE entiers.
    Je me demande quand est-ce que pourrait avoir ça de base, à l'issue d'une installation normale.

    • [^] # Re: Pas facile...

      Posté par  . Évalué à 2.

      Novell (Nat Friedman en fait) a fait une démo de la NLD (Novell Linux Desktop) qui sortira bientôt (dans 5, 6 mois). Elle sera basée sur Xgl. On pouvait aussi voir la démo sur le stand Novell.

      Tristan Nitot en parlait sur son blog :
      http://standblog.org/blog/2006/02/02/93114634-why-you-should(...)

    • [^] # Re: Pas facile...

      Posté par  . Évalué à 2.

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

      • [^] # Re: Pas facile...

        Posté par  . Évalué à 3.

        Pour simple info, il y a effectivement un paquet Xgl dans l'OpenSuSE 10.1 bêta 3, dans le dépôt par défaut. Donc pas de raison que ce soit absent de la version finale (qui devrait arriver d'ici quelques semaines à en croire la feuille de route).

    • [^] # Re: Pas facile...

      Posté par  . Évalué à 1.

      A priori, une personne a fait marcher une ancienne version sur kubuntu:

      http://img148.imageshack.us/my.php?image=xgl7uk.png

      http://img95.imageshack.us/my.php?image=xgl22bc.png

      Donc d'ici peut de temps, on devrait trouver de beaux paquets ( peut-etre pas officiel ) pour les distro majeurs.

  • # autres info :

    Posté par  (site web personnel) . Évalué à 5.

    http://www.internetnews.com/dev-news/article.php/3583191

    ce qui me semble intéressant :

    - Novell has already garnered the interest of the principal graphics chips vendors, Intel, ATI and Nvidia.
    et :
    "Intel, ATI and Nvidia, we have engineering co-operation from each of those companies they've each seen XGL and have responded very positively.

    donc des drivers certes proprio devraient sortir pour chacun de ces constructeurs et ca c'est un bon point!

    - And think that adoption of Xgl into the mainstream X.org release will happen sooner than most would expect
    Ca serait pas si lointain que ce qu'on pense! ce qui en gros veut tout dire et rien dire a la fois ...

    ca c'est moins bon :
    Friedman explained that Xgl relies on the drivers to already be on the users systems and if the users don't already have the video drivers none of this stuff will work

    donc si les constructeurs ne sortent pas de drivers pour les anciens modéles ceux ci l'ont dans le baba!

    PS : tout ceci est sujet aux erreurs de traduction que je pourrais avoir fait.

    • [^] # Re: autres info :

      Posté par  . Évalué à 2.

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

  • # Flashy mais...

    Posté par  . Évalué à 5.

    ... est-ce les APIs pour accèder aux services opengl des GPU modernes seront proprement "normalisées"?
    Bon, j'avoue ne pas avoir regardé dans le code source pour voir comment ça marche mais il faut faire attention à la manière d'exposer la puissance des GPU modernes aux applications graphiques.
    De ce que j'ai compris, il semble que la vrai "normalisation" soit liée à OpenGL ES et EGL (remplacement de GLU et GLX et cela explique Xegl).
    Prenons un cas concret: je suis dèveloppeur d'une application graphique, j'utilise gtk/cairo pour dessiner et je voudrais faire des effets en programmant les shaders de mon GPU sur un widget particulier. Quelle API je vais utiliser?
    De tout ça, je pense ne pas trop m'avancer en prédisant une complexification significative des drivers des GPUs. Une ouverture du code de ces drivers serait plus qu'utile pour aider à leur stabilisation.

    • [^] # Re: Flashy mais...

      Posté par  (site web personnel) . Évalué à 0.

      De tout ça, je pense ne pas trop m'avancer en prédisant une complexification significative des drivers des GPUs. Une ouverture du code de ces drivers serait plus qu'utile pour aider à leur stabilisation.
      Ca c'est l'idéal. En étant plus pragmatique et plus réaliste, je penses qu'un changement important va effectivement aider à stabiliser et standardiser les APIs des cartes graphiques... ce n'est pas le code source des dits drivers, mais... DirectX. En effet le prochain DirectX de Windows Vista ne proposera plus d'accéder directement aux spécificités du matériel, c'est tout le monde à la même enseigne.
      "L’idée principale de DirectX 10 est l’uniformisation du matériel. L’idéal serait à terme de faire disparaître la notion de CAPS qui, sur les versions actuelles de DirectX, permet d’interroger les cartes pour en connaître leurs possibilités. Les capacités graphiques deviendraient identiques quelque que soit la marque de la carte graphique et la différence se ferait donc uniquement sur les performances."

      • [^] # Re: Flashy mais...

        Posté par  (site web personnel) . Évalué à 3.

        J'oubliais ma source :
        http://www.pcinpact.com/articles/a/172/0.htm?pge=8
        (dossier fort intéressant à lire au passage)

      • [^] # Re: Flashy mais...

        Posté par  . Évalué à 10.

        L'dée principale de DirectX 10 est l'uniformisation du matériel. L'idéal serait à terme de faire disparaître la notion de CAPS qui, sur les versions actuelles de DirectX, permet d'interroger les cartes pour en connaître leurs possibilités. Les capacités graphiques deviendraient identiques quelque que soit la marque de la carte graphique et la différence se ferait donc uniquement sur les performances.

        OpenGL fait ça depuis le début, modulo la gestion des extensions. Il suffit de se rappeler ce qu'a été l'introduction du 'Texture and lighting' dans les 2 API. Dans OpenGL, tous les progs l'ont utilisés sans le savoir, dans DirectX, il fallait interroger les CAPS du matériel pour savoir si c'était disponible, pour les utiliser. C'est quand même le but d'une API que de masquer les différences entre les matériels.

        • [^] # Re: Flashy mais...

          Posté par  (site web personnel) . Évalué à 1.

          OpenGL fait ça depuis le début, modulo la gestion des extensions.
          Tout est dans le modulo :) Une couche d'abstraction fait entièrement abstraction ou n'en est pas une. DirectX le faisait en parti aussi si tu veux. Peut êtes pas aussi bien que OpenGL mais faisait aussi de l'abstraction. Cela dit il y avait toujours une porte dérobée, que ce soit en OpenGL ou DirectX pour exploiter spécifiquement tel ou tel matos, bref la course aux fonctionnalités non standardisées. DirectX 10 se propose d'être une vraie couche d'abstraction (en tout cas sur le papier), d'où tout l'intérêt.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à -10.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Commentaire supprimé

              Posté par  . Évalué à -10.

              Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Commentaire supprimé

                Posté par  . Évalué à 1.

                Ce commentaire a été supprimé par l’équipe de modération.

                • [^] # Re: Flashy mais...

                  Posté par  (site web personnel) . Évalué à 3.

                  Y'a humour et humour, visiblement l'humour sarcastique répétitif et sans rapport avec la choucroute n'est pas vu comme pertinent :)

                  • [^] # Commentaire supprimé

                    Posté par  . Évalué à 1.

                    Ce commentaire a été supprimé par l’équipe de modération.

                    • [^] # Re: Flashy mais...

                      Posté par  (site web personnel) . Évalué à 2.

                      Ben oui, un personne disait que ca serait bien que les API des cartes graphiques soient standardisés, parcque justement avec XGL ca va pas marcher chez tout le monde. Moi j'ai précisé qu'on avait de forte chance de voir les APIs des cartes graphiques se stabiliser avec le prochain DirectX. Et forcé de constater que MS et DirectX ont beaucoup plus d'impact sur nVidia et Ati que l'OpenGL ou même Novell avec XGL. Bref, je pense que DirectX profitera aussi à nous linuxien de manière indirect.

                      • [^] # Re: Flashy mais...

                        Posté par  (site web personnel) . Évalué à 1.

                        MS et DirectX ont beaucoup plus d'impact sur nVidia et Ati

                        Ah bon ? et tu tiens cette information de qui ? quoi ? quel article ?

                        • [^] # Re: Flashy mais...

                          Posté par  (site web personnel) . Évalué à -1.

                          Toi t'es un gros malin.
                          J'emploi impact dans le sens d'une "influence". Par définition l'influence est un phénomène intellectuel et moral que chacun est à même d'apprécier à sa façon. Je te laisse donc toi même te documenter sur les "faits", sur l'importance des relations entre ATI/nVidia et MS, pour en juger toi même.

                      • [^] # Commentaire supprimé

                        Posté par  . Évalué à 1.

                        Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: Flashy mais...

            Posté par  (site web personnel) . Évalué à 2.

            Et qu'est-ce qui empèchera un constructeur de rajouter des api perso en sus de directx ? parce que bon, si nvidia/ati et consort sorte une carte avec une fonctionnalité non prise en charge dans le directx courant, ben pour l'utiliser il faudra bien passer par une extension constructeur...

            Et je ne pense pas que les dev se priveront d'utiliser une extension constructeur (comme il ne s'en prive pas actuellement), donc à part par un moyen inconnu microsoft enmpêche de créer une extension quelconque (voir lib à part qui gère ça), je vois mal comment les "extensions" disparaîtront.

            • [^] # Re: Flashy mais...

              Posté par  (site web personnel) . Évalué à 1.

              Et qu'est-ce qui empèchera un constructeur de rajouter des api perso en sus de directx ?
              Des pilotes signés numériquement par Microsoft par exemple.

              • [^] # Re: Flashy mais...

                Posté par  (site web personnel) . Évalué à 7.

                Et ouais et tu crois qu'ils vont pas signer un driver de monsieur nvidia car monsieur nvidia a rajouté une dll pour accéder a des fonctionnalités non prises en charge par directx ? je crois que tu rêves.

          • [^] # Re: Flashy mais...

            Posté par  (site web personnel) . Évalué à 3.

            Bon je vais sureemnt sortir une connerie (qui a dit comme d'habitude?), mais l'émulation logiciel Mesa n'est pas "partiellement utilisable"?
            Traduction:
            Pour les vieilles cartes qui supportent que opengl 1.2 et pas 2.0, c'est pas possible de combler les lacunes en utilisant la libMesa pour ce que la carte sait pas faire? (au prix de performances desastreuses mais bon c'est mieux que rien)
            (Maintenant que j'y penses, Mesa c'est pas seulement opengl 1.2?)

            • [^] # Re: Flashy mais...

              Posté par  . Évalué à 3.

              Maintenant que j'y penses, Mesa c'est pas seulement opengl 1.2?

              Mesa 6.x supporte OpenGL 1.5:
              http://www.mesa3d.org/RELNOTES-6.0
              http://www.mesa3d.org/VERSIONS

              Evidemment, pour tout ce qui est pixel/vertex shader/program/choucroute, ca passe par des extensions (GL_ARB_vertex_program, GL_ARB_vertex_shader) jusqu'à intégration dans le core pour la prochaine version. Par contre, pour ce qui est du support matériel de ceux-ci dans Mesa, cela dépend du driver.

    • [^] # Re: Flashy mais...

      Posté par  . Évalué à 3.

      Prenons un cas concret: je suis dèveloppeur d'une application graphique, j'utilise gtk/cairo pour dessiner et je voudrais faire des effets en programmant les shaders de mon GPU sur un widget particulier. Quelle API je vais utiliser?

      GLSL( http://www.opengl.org/documentation/oglsl.html ) est pas l'API standard pour faire ce genre de truc normallement ?

      • [^] # Re: Flashy mais...

        Posté par  . Évalué à 2.

        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?

        • [^] # Re: Flashy mais...

          Posté par  (site web personnel) . Évalué à 2.

          A mon avis ca va être difficilement possible parce que dans ce cas ton application va dépendre de OpenGL... hors gtk/cairo ne dépendent pas de OpenGL et heureusement d'ailleurs. Alors peut être un jour il y aura moyen de rajouter des effets ( optionnels ) OpenGL mais pas dans l'immédiat. XGL n'est qu'un serveur X !

          • [^] # Re: Flashy mais...

            Posté par  . Évalué à 4.

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

    • [^] # Re: Flashy mais...

      Posté par  . Évalué à 2.

      alors tu utilises une surface glitz avec cairo

      • [^] # Re: Flashy mais...

        Posté par  . Évalué à 2.

        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.

  • # ....

    Posté par  (site web personnel) . Évalué à 4.

    J'attends avec envie les how to' sur comment compiler cela de manière claire...

    • [^] # Re: ....

      Posté par  (site web personnel) . Évalué à 4.

      + Les instructions de compilation sont sur : http://www.freedesktop.org/Software/Xgl

      + l'installation et la configuration sur OpenSuse + compatibilité matérielle ( statut des drivers ) : http://en.opensuse.org/Xgl

      + vidéo de la démonstration lors du Salon Solutions Linux à Paris : http://www.linux-wizard.net/index.php?id_blog=58
      C'est plus complet que les vidéos sur le site de Novell.

      Pour d'autres liens : http://www.linux-wizard.net/index.php?id_blog=59

      Le lien le plus intéressant est celui d'OpenSuse, on y voit que le driver libre nv n'a aucune accélération 3D. En gros en drivers libre cela va se jouer entre : radeon, i810. Par contre pas d'infos concernant les drivers S3.

      • [^] # Re: ....

        Posté par  (site web personnel) . Évalué à 4.

        Et compiz on y a pas le droit?
        Parce que xgl sans compiz c'est comme Xorg sans composite manager

      • [^] # Re: ....

        Posté par  (site web personnel) . Évalué à 2.

        j'ai testé Xgl il y a 2 jours, mais je n'ai pas de bonne performance.

        J'utilise les drivers proprio nvidia, mais quand je lance Xgl, et qu'ensuite je lance glxinfo dans un terminal, il me dit que qu'il utilise le glx de SGI, alors que dans mon serveur X classique qui fonctionne en parralèlle (F7 pour Xorg et F8 pour Xgl) il utilise bien le glx de nvidia.

        Et si je remplace le libglx.so dans mon installation de Xgl par celui fourni avec les drivers Nvidia, j'ai le droit au message suivant :
        undefined symbol : xf86fprintf

        est ce que quelqu'un aurai une petite idée?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.