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 Victor . É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 :)
[^] # Re: Sans xorg.conf…
Posté par Jiehong (site web personnel) . Évalué à 6.
Si, bien-sûr. Sous Archlinux, tu peux le mettre dans cette section :
/etc/X11/xorg.conf.d/20-radeon.conf
Et puis je te conseille également d'aller jeter un œil sur le Wiki.
# AccelMethod
Posté par paulez (site web personnel) . É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.
[^] # Re: AccelMethod
Posté par Victor . Évalué à 2.
Ouais, pareil pour moi, X ne se lance pas, et les logs n'indiquent aucune erreur, ça se pause juste…
[^] # Re: AccelMethod
Posté par paulez (site web personnel) . Évalué à 1.
À priori il faut aussi ajouter le chargement du module dans la conf. cf https://wiki.archlinux.org/index.php/Ati#Glamor
[^] # Re: AccelMethod
Posté par Victor . Évalué à 2.
Bah il a l'air de le charger, mais j'ai testé au cas où et ça ne marche pas non plus…
# Pas toutes les vieilles cartes
Posté par Olivier Esver (site web personnel) . Évalué à 5.
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 Strash . É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 jbbourgoin (site web personnel) . É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 glisse . É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 jbbourgoin (site web personnel) . É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 Strash . Évalué à 6.
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 xoddark . É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 jbbourgoin (site web personnel) . Évalué à 2.
Oui, c'est ça.
Bonnes nouvelles, merci.
[^] # Re: Au passage
Posté par glisse . É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 jbbourgoin (site web personnel) . Évalué à 4.
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 glisse . É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 jbbourgoin (site web personnel) . É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 mdlh . É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 glisse . É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 ʭ ☯ . É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://afdgauch.online.fr
[^] # Re: Au passage
Posté par glisse . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.