Journal Pilotes ATI libres, voici venu le temps du Glamour

Posté par (page perso) . Licence CC by-sa
31
19
mar.
2013

Bonjour à tous,

C'est à l'occasion d'une mise à jour des pilotes ATI sous Archlinux, et d'une nouvelle dépendance ajoutée, que j'ai vu que Glamor venait d'être totalement implémenté (bon, ça date de janvier quand même…).

Pour faire court, Glamor est un effort pour éviter de développer un système d'accélération 2D pour les nouvelles cartes ATI. L'idée est simplement d'utiliser le moteur OpenGL de la carte pour ça.

La bonne nouvelle, c'est que c'est aussi compatible avec les anciennes cartes.

Pour l'essayer, et après avoir mis à jour votre pilote ATI, il va falloir changer l' AccelMethod de votre fichier Xorg pour lui demander de l'utiliser (valeur SI).

Pour ma part, ayant une carte de la série des r600, j'ai noté une bonne amélioration des performances 2D. C'est la bonne nouvelle de la journée !

  • # Sans xorg.conf…

    Posté par . Évalué à  2 .

    Cool,

    Mais si on a pas de Xorg.conf pour configurer sa carte, on fait comment ?

    Il y a peut-être un moyen de le mettre dans le xorg.conf.d ? Sous quel forme ?

    Si quelqu'un sait :)

  • # AccelMethod

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

    D'après le Changelog il faut mettre "glamor" comme AccelMethod. D'ailleurs ce paramètre a bien un effet puisqu'il fait freezer mon système. À noter que XV n'est pas supporté avec Glamor.

  • # Pas toutes les vieilles cartes

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

    La bonne nouvelle, c'est que c'est aussi compatible avec les anciennes cartes.

    D'après http://www.x.org/wiki/RadeonFeature glamor n'est accessible qu'à partir des r300.

    S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.

    • [^] # Re: Pas toutes les vieilles cartes

      Posté par . Évalué à  3 .

      En effet Glamor semble nécessiter OpenGL 2.1, et les cartes r100 et r200 n'en sont pas capables (matériellement et logiciellement)

  • # Au passage

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

    J'en profite pour savoir si parmi-vous des personnes connaîtraient l'avancé des travaux sur les pilotes 3D de Southern Island ?

    Je vois bien sur la page idoine que c'est ou TODO ou WIP, mais enfin, ça ne me dit pas si on peut s'attendre à un truc dans 2, 5 ou 30 ans ;)

    • [^] # Re: Au passage

      Posté par . Évalué à  6 .

      Les drivers actuel en gros supporte gl 2.1 ++ 3.0 ds 2-3 mois, puis 3.1, … ca fait deja bcp d'app 3d aka jeux qui marche avec

      • [^] # Re: Au passage

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

        Heu, c'était pas vraiment la question.

        Pour les puces Southern Island il n'y actuellement pas d'accélération OpenGL au sens propre. En fait OpenGL passe par Gallium, donc par le CPU (si j'ai bien compris).

        Ce qui fait que même pour un usage bureautique j'ai une grosse consommation CPU (cela dit c'est un Core i7 donc ça passe très bien), puisque les bureaux sont en 3D maintenant.

        Sans parler de Blender et compagnie.

        Donc pour le moment j'utilise les drivers proprio car les drivers libres pour les puces Southern Island ne sont pas au point.

        • [^] # Re: Au passage

          Posté par . Évalué à  6 .

          En fait OpenGL passe par Gallium, donc par le CPU (si j'ai bien compris).

          Je n'y connais pas grand chose, je ne pense pas que passer par Gallium veuille dire que cela passe par le CPU. Gallium3D est juste un moyen d'abstraction pour ne pas avoir a développer les API 3D (OpenGL, Direct3D, …) pour chaque architectures.
          C'est notamment utilisé par nouveau et les pilotes libres ATI r300-r900.

          • [^] # Re: Au passage

            Posté par . Évalué à  4 .

            Oui Gallium est une interface entre la gestion des API (OpenGL, OpenCL, etc) et les drivers spécifiques au matériel.
            Parmit les différents drivers compatible Gallium il y en a un basé sur llvm qui s'exécute sur le CPU, mais il y a aussi les drivers r300g, r600g, si, nouveau, … qui sont implémentés pour utiliser gallium.

            Pour en revenir à Southern Island il me semble que ça a pas mal avancé, que tout est en place, et que ça fonctionne à peu près. Sauf que tout n'est pas forcement la/actif dans les versions stable/inclue dans les distributions des composants (Kernel, Mesa, divers X.Org, glamors, …).

            • [^] # Re: Au passage

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

              Parmit les différents drivers compatible Gallium il y en a un basé sur llvm qui s'exécute sur le CPU

              Oui, c'est ça.

              Pour en revenir à Southern Island il me semble que ça a pas mal avancé, que tout est en place, et que ça fonctionne à peu près

              Bonnes nouvelles, merci.

        • [^] # Re: Au passage

          Posté par . Évalué à  6 .

          Je sais pas dans qu'elle langue je dois parler. Le driver open source sur southern island supporte OpenGL 2.1 ++ (++ avec des extension en plus). Donc ca marche aussi bien que les générations précédentes seulement ca n'a pas encore toute les fonctionalités OpenGL supporté par les générations précédentes. OpenGL 2.1 en gros ca te donne un desktop comme gnome-shell qui marche sans problème et des applications jusqu'à doom III et similaire. Autre formulation OpenGL est accéléré par le GPU avec southern island et le driver open source.

          Maintenant ce support n'est activé dans aucune distribution courante à ma connaissance (mis à part les rolling release distribution). Mais la prochaine vague de distribution devrait l'avoir (mis à part debian je suppose).

          • [^] # Re: Au passage

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

            Je sais pas dans qu'elle langue je dois parler. Le driver open source sur southern island supporte OpenGL 2.1 ++ (++ avec des extension en plus). Donc ca marche aussi bien que les générations précédentes seulement ca n'a pas encore toute les fonctionalités OpenGL supporté par les générations précédentes. OpenGL 2.1 en gros ca te donne un desktop comme gnome-shell qui marche sans problème et des applications jusqu'à doom III et similaire. Autre formulation OpenGL est accéléré par le GPU avec southern island et le driver open source.

            Maintenant ce support n'est activé dans aucune distribution courante à ma connaissance (mis à part les rolling release distribution). Mais la prochaine vague de distribution devrait l'avoir (mis à part debian je suppose).

            Je suis sous Arch et aux dernières nouvelles (une dizaine de jours), gnome-shell tournait toujours en llvm-pipe (donc sur CPU).

            Problème de conf ?

            Je viens de relire le tableau et je n'avais pas repéré la ligne OpenGL Compliance (Driver/Hardware), mais tout le reste (dans la section 3D) est en TODO et en WIP. Que faut-il comprendre ?

            Je ne suis pas un pro de la 3D moi :(

            • [^] # Re: Au passage

              Posté par . Évalué à  5 .

              Ca n'est pas automatique sur arch il faut un fichier xorg.conf ou un fichier ds xorg.conf.d qui demande l'accel glamor comme ce journal l'indique.

              • [^] # Re: Au passage

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

                Merci, c'est effectivement ce que je viens de découvrir en fouillant sur le web, et ça fonctionne !

    • [^] # Re: Au passage

      Posté par . Évalué à  2 .

      Il n'est pas impossible que les développeurs chez AMD qui bossaient dessus
      n'ai pas mal souffert de la dernière vague de réduction des effectifs…

      • [^] # Re: Au passage

        Posté par . Évalué à  7 .

        Au contraire l'équipe open source GPU est probablement l'une des rares qui continue à grossir dans amd.

        • [^] # Re: Au passage

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

          Bonne nouvelle, ça, vous visez un pilote open source seulement au long-terme chez AMD?
          Quand je vois les problèmes du pilote Intel avec VAAPI (jamais pu voir de manière fluide le flux Freebox HD par exemple), je me demande si le décodage vidéo s'avère plus complexe à développer sur GPU en dédié que la partie OpenGL.
          en tout cas, merci pour l'info Jerôme.

          ⚓ À g'Auch TOUTE! http://agauch.fr

          • [^] # Re: Au passage

            Posté par . Évalué à  2 .

            Je ne travail pas pour AMD donc je ne peux pas dire qu'elles sont les objectifs d'AMD, mais je pense que le driver closed source continuera a exister pour plusieurs années. Cela étant dit, les contributeurs open source travail tous pour améliorer le driver dans l'espoir de rendre inutile le driver closed source.

            Pour l'accélération video le problème viens plutôt des API, entre VAAPI, VDPAU XV XVBA …. il y a pléthor et l'accélération ne peut être utilisé que si le logiciel qui lit le flux utilise la librairie qui va bien (VAAPI VDPAU XVBA …). Le fait est que pratiquement aucun logiciel à part les les players comme mplayer ou vlc … utilise ces librairies, les choses comme flash (proprio) n'utilise pas correctement ces librairies iirc only VDPAU mais pas tous les profils donc très peux de video sont accéléré. Sous windows/osx c'est beaucoup plus simple un seul API est tout le monde l'utilise.

Suivre le flux des commentaires

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