Reprise du message précédent :

Et bien écoute, avec mythtv qui s'appuie sur mplayer, mon X2 4850BE, sans le support du gpu saccade à mort sur la tnt HD, c'est tout ce que je peux te dire... Avec vdpau actif, là par contre il ne fou plus rien et c'est totalement fluide...
 
Donc il y a forcément des filtres qui sont en cause de mon côté.  

Mais lesquels?

Le désentrelacement je pense c'est le plus gourmand pour la tnt.

Dites, depuis quelque temps mon ecran s'eteind pendant quelque secondes avant de se rallumer (j'ai l'impression qu'il se rallume plus vite si je bouge la souris ou utilises le clavier, ce qui me fait penser qu'il se met en veille sans raison mais je ne suis pas sur...).

Je n'ai pas eu ce soucis quand j'utilise XBMC plein ecran.

Une idee de quoi regarder?

3.0 avec rv730

ce problème est arrivé comment ?

brutalement après la mise à jour d'un paquet ?

il faudrait se souvenir de la manip qui a provoqué ce problème et tu trouveras alors le coupable,

peut-être un mauvais fichier xorg.conf mal configuré,

essaie d'utiliser l'utilitaire xset pour désactiver les options de veille de l'écran ( faire un man xset pour connaitre les options )

A vrai dire je ne sais plus trop quand c'est arrive...
 
Vu le nombre de nouveautes pour ati / xorg dernierement je me suis dit que c'etait un bug de plus de passage mais en fait non...
 
je vais tester xset et voir ce qui se passe, merci
 
(c'est possible que ca soit mon ecran qui lache aussi... )

Dites moi, y a du neuf au niveau du support des gpu ati libre niveau HD?
 
J'ai cru comprendre qu'ils avaient trouvé un contournement via les shaders en utilisant va-api.
 
Mais concrètement ça donne quoi? Genre le support de la TNT HD avec un gpu ati récent et va-api c'est ok ou concrètement on pas du tout?

TNT HD ca roule avec un fusion (AMD 6310 de mémoire), en tout cas sous openlec (je ne sais pas trop si il utilise le driver libre ou proprio).

J'avais hésité à prendre un "fusion" justement, mais j'ai préféré pendre un pentium 630T pour pouvoir quand même avoir un peu plus de puissance (et surtout d'évolution).  
 
Après me reste l'emplacement dispo en pci-express pour plus tard.
 
Pour l'instant je n'ai pas besoin de la hd, mais quand ça arrivera, j'aurais le choix entre l'igp intégré à sandy (donc ça sera forcément mon tout premier test), et entre un gpu nvidia avec vdpau qui est assez éprouvé ou un gpu ati.
 
D'ou mon questionnement avec va-api sur le drivers libre. Si jamais vous avez des infos précises sur ça je suis preneur. Avec le pilote proprio ça doit marcher de toute façon, mais sous linux j'ai pas de bon souvenir avec le pilote proprio niveau upgrade...

J'ai testé rapidement le driver proprio vs driver libre quand j'ai déballé mon zotac AD10.
 
pilote proprio = ramage sous debian sid (sur le bureau, en vidéo c'est encore pire)
pilote libre = ok, ca roule impec.

Vouep mais c'est plus le support HD qui est aussi important.
 
Enfin bref j'aurais le temps d'ici là de reposer la question. Le jour ou j'aurais l'intérêt de la HD.

Un article intéressant de phoronix sur le sujet:
http://www.phoronix.com/scan.php?p [...] px=MTA2ODk

Crosspost du topic ubuntu:  
 
J'ai installé ubuntu 12.04 sur un vieux portable ACER (aspire 3023) lequel est équipé d'une carte graphique ATI Mobility Radeon X700.  
 
A priori, mon système tourne assez bien, graphiquement parlant, et je n'utilise pas de 3D. Je ne sais même pas quels drivers sont en fait utilisés. Est-il utile/judicieux d'installer les drivers binaires d'ATI (package fglrx) ?
 
Un élément supplémentaire. Quand je fais un system testing, j'ai ça:

 
Et l'utilitaire de drivers additionels ne me propose rien en terme de carte graphique.

Si t'as pas de ralentissements pour ton utilisation, autant ne pas changer.
 
J'ai testé quelques minutes fglrx sur un adm E350, c'est pas folichon. C'est bien plus fluide avec les drivers libres.

actuellement, tu utilises le pilote CPU (llvmpipe) pour gérer la 3D, pas le pilote 3D radeon.

bonsoir,
 
pour une ati hd6130 de netbook quel est le meilleur driver pour la moindre chauffe et la moindre consommation d'énergie?
 
Le pilote libre est-il meilleur que Catalyst?
 
edit: en 2D et en 3D (avec mesa)
 
merci

Les radeon 6xxx chauffent beaucoup avec le pilote libre.

il y a pas une option dans le pilote libre qui permet de réduire automatiquement la fréquence du GPU quand il est peu sollicité ?

les spécifications des cartes ati/amd étant rendues publiques on aurait pu croire que les développeurs du pilote libre avaient intégré cette fonctionnalité,

il y a peut-être une option à configurer dans un fichier texte ou un module à installer pour activer les économies d’énergie pour la carte graphique

 
http://www.x.org/wiki/RadeonFeatur [...] nt_Options
 
ça réduit bien le bruit déja sur ma HD4850    
 

attention il y a un bug dans la dernière version de Mesa 8.x.x et qui semble toucher certains possesseurs de cartes ati d'ancienne génération ( pilote Mesa DRI R200 (RV280 5961) x86/MMX/SSE2 TCL DRI2 ), par exemple un possesseur d'une carte agp ati radeon 9000, 9200

ça se traduit par une mauvaise exécution d'une fonction openGL, le logiciel le plus touché est "blender", il plante au lancement avec ce message :

http://lists.freedesktop.org/archi [...] 20050.html

http://projects.blender.org/tracke [...] 9&atid=498

un moyen de contourner le bug est d'utiliser le rendu software pour l'openGL, une variable d'environnement à modifier dans une console :

export LIBGL_ALWAYS_SOFTWARE=1

puis lancer ensuite blender dans la console

3 mois déjà que ce bug n'est pas corrigé, pour l'instant seul le logiciel blender semble touché mais cela entraine peut-être d'autres problèmes mineurs dans tous les logiciels qui utilisent la fonction qui merde de cette version 8.x.x de mesa

Quelqu'un a testé avec le git pour voir si ça fonctionnait ? ou bisecté pour trouver le commit coupable ?
 

comme ça ne semble toucher que les possesseurs de vieilles cartes ati alors c'est pas sûr qu'il y ai beaucoup du monde attelé à corriger ce bug,
 
moi je suis sous archlinux qui est censé avoir les paquets les plus frais ( en version release ) et avec la dernière version de mesa le bug n'est pas corrigé ( j'ai une ati radeon agp 9000 )

 
La dernière version releasé peut être différente voire très différente de la version de dev, d'où ma question. SI la version de dev corrige le soucis, il est possible de pointer le commit qui va bien pour qu'il soit inclus dans la prochaine version stable.

je vais peut-être essayer de compiler la dernière version béta de mesa et d'installer ça dans /opt et faire un export LD_LIBRARY_PATH vers ces librairies beta de mesa pour voir si ça résout le problème de blender

il faut un peu plus que ld library path, je suis pas sur le fixe mais je te donne mes raccourcis ce soit quand je teste des versions de mesa (et pas besoin d'installer, tu peux executer sur place)

voilà ce que j'utilise pour compiler et tester le git de mesa.
 
après avoir cloné l'arbre git (git clone git://anongit.freedesktop.org/mesa/mesa), je configure  
./autogen.sh --with-dri-drivers=r200,radeon --with-gallium-drivers=  
 
options à vérifier, ça doit être les bonnes pour compiler le pilote r200 mais un configure--help ne fera pas de mal.
On installe les dépendances et on n'oublie pas flex et bison.
 
on compile avec make, pas la peine d'installer après, on va utiliser la version directement depuis l'arbre des sources.
 
Pour ça, je me suis fait un alias qui utilise le truc compilé :
alias rdgl='LD_LIBRARY_PATH="/home/jules/ati/mesa/lib/" LIBGL_DRIVERS_PATH="/home/jules/ati/mesa/lib/gallium/" vblank_mode=0'
 
et je lance les softs avec ça :
rdgl nom_du_soft

 
cette partie m'inquiète un peu car je ne voudrais pas surcharger le système avec des éléments nouveaux, surtout que j'installe que via les paquets de ma distribution,
 
l'idéal serait de compiler tout dans un dossier et de ne rien n'installer de nouveau dans /usr

les dépendances sont fournies par ta distribution, en tout cas, c'est le cas pour moi (les paquets -dev ou -devel).

je suis en train de lancer la compilation, on va donc voir si la version béta règle le problème

voilà j'ai fait le test avec la version de développement de mesa et ça plante toujours au lancement de blender
 

 
voilà ce que je vois avec glxinfo, c'est bien la version de développement de mesa que j'ai compilé qui est utilisée :
 

 
du coup blender ne peut se lancer qu'en forçant le mode de rendu "software" à cause de ce bug de mesa pour le pilote r200,
 
une solution que j'ai trouvée consiste à compiler une ancienne version de mesa non buguée : mesa-7.11.2, puis d'utiliser ces libs via un export sur les variables LD_LIBRARY_PATH et LIBGL_DRIVERS_PATH avant de lancer blender,  
 
cela permet d'avoir l'acceleration matérielle opengl avec blender, j'ai crée un script avec ces commandes pour lancer blender, mais j'espère que ce bug sera quand même corrigé dans la prochaine version de mesa

si tu veux faire avancer le bugreport, tu peux essayer de faire une bisection, i.e. pointer vers le commit fautif.
 
pour cela tu utilises git bisect :
 
git bisect start
git bisect good mesa-7.11
git bisect bad mesa-8.0
 
git va alors parcourir l'arbre des révisions et t'en proposer une à peu près au milieu de l'intervalle, tu compiles/testes et ensuite, git bisect good si la révision est bonne, git bisect bad si elle a le bug. git bisect va alors te proposer une deuxième révision que tu testes puis marques bonne ou mauvaise et ainsi de proche en proche jusqu'à atteindre la révision (le commit) fautif que tu pourras alors indiquer sur le rapport de bug.  
 
le nombre d'étapes est généralement très raisonnable même entre 2 versions très différentes. Et ccache est une bonne idée pour accélérer les compilations répétées.
 
c'est parfois un peu long mais tu peux automatiser un peu plus avec git bisect run :
https://lwn.net/Articles/317154/

ok merci pour ces infos
 
je ne vais pas le faire tout de suite mais si j'ai le temps pourquoi pas

sortie de mesa 8.0.4 :
 

 
malheureusement le bug "blender" avec le driver r200 n'a toujours pas été corrigé, il s'agit du bug 47375 :
 
https://bugs.freedesktop.org/show_bug.cgi?id=47375

Bonjour ça fait un baille que ce topic ne vie pas, ça donne quoi le support des gpu récents comme  sous linux en pilote libre?
Radeon HD 5450

Je parle de va-api etc? Pas des pilotes proprios tout ça.

tu trouveras un tableau détaillé de ce qui est supporté ( en vert sur le tableau ) :

http://xorg.freedesktop.org/wiki/RadeonFeature/

il faut faire la conversion entre le nom commercial de la carte ( HDxxxx ) et le nom de la puce utilisée, tu auras alors la liste des fonctionnalités supportées par le pilote libre, pour une HD5450 il s'agit de la puce "Evergreen",

il me semble que le support est assez bon pour les cartes amd récentes,

le support de la décompression H264 par le GPU est Ok, personnellement j'utilise vdpau pour ma carte HD4650,

le site phoronix fait souvent des tests de performance avec le pilote libre, ça se rapproche de plus en plus des performances des pilotes propriétaires :

http://www.phoronix.com/scan.php?p [...] cs%20Cards

Merci pour ton message, j'avais vu un peu tout ça.
 
Je vais pouvoir faire un comparatif, je me suis pris une 720GT et une HD5450.
Mon but serait de rester en pilote libre (j'ai l'igp intel à l'intérieur mais j'ai quelques pbs je veux voir si c'est les pilotes intels qui sont en cause ou pas...).
 
Du coup sur du décodage de la TNT Hd/SD je vais pouvoir faire le test intel hd vs 54050 vs 720GT.
 
Nul doute que la 720GT avec les pilotes proprio doit bien s'en sortir, mais j'aimerais rester avec les pilotes libres si possible donc j'ai des espoirs sur la HD5450.

ça marchera pour la prise en charge de l'acceleration graphique h264 avec le pilote libre avec ton ati HD5450,

si tu utilises mplayer il sera capable d'utiliser vdpau si le paquet correspondant est installé sur ta distribution,

j'ai remarqué que vdpau était beaucoup plus fiable avec les cartes amd que le paquet va-api,

pour la TNT il y a le logiciel kaffeine qui est le plus abouti pour la réception TNT sur linux, c'est très complet,

je me méfie des pilotes propriétaires, car souvent ça risque de poser problème si tu utilises une distribution de type "rolling release" qui utilise les paquets systèmes les plus récents ( Xorg, noyau ), car le pilote propriétaire peut avoir un temps de retard et ne pas être compatible avec la dernière version du noyau ou de Xorg,

avec le pilote libre tu n'auras pas ce souci

La tnt HD c'est du mpeg4 pas du h264 non?

Pour la TNT j'utilise mythtv.

Pour les pilotes proprio, je sais, mais force est de constater jusque là, qu'avec nvidia en distrib non rolling release, genre sur du ubuntu LTS, ou du debian, on trouve difficilement plus efficace niveau support graphique et VDPAU.

Maintenant forcément, j'ai une préférence pour rester sur un pilote libre si possible donc je verrais bien ce qu'il en est au final.

la TNT HD utilise du h264 comme codec de compression,

le codec h264 c'est en fait du "mpeg4 AVC", les 2 termes indiquent la même chose,

et le codec xvid/divx c'est du "mpeg4 ASP",

la TNT SD utilise du mpeg2 ( le même codec utilisé par les DVD vidéo ),

et la future TNT ultra-hd utilisera probablement le h265, qui est appelé aussi "High Efficiency Video Coding (HEVC)",

pour le support de VDPAU les pilotes libres ont un niveau de performance quasi équivalent aux pilotes propriétaires ( chez moi le %CPU est très bas quand l’accélération GPU est activée pour la lecture du h264 ),

le vrai intérêt des pilotes propriétaire c'est pour les jeux 3D récents, les gros gamers qui veulent à tout prix avoir des FPS très élevés dans les benchmarks,

si tu n'es pas un hardcore gamer alors le pilote libre radeon devrait suffire

Vu que le pc est dédié à un affichage de mythtv (openGl très léger...) + la tnt HD dans mythtv, les perfs 3D...
 
Du coup ça devrait le faire, je pourrais donc comparer en pilote libre intel vs ati.

Un petit comparatif avec le pilote libre et l'utilisation d'uvd:
http://www.phoronix.com/scan.php?p [...] dpau&num=1