On est pas obligé de le faire exhaustif aussi 😉
essai de l'option radeon.dynpm=1 avec résultats mitigés :
- je suis a peu près tranquille niveau bruit avec le ventilo qui se calme
- mais kms est désactivé sur le noyau et le DRI est désactivé (peu plus activer compiz)

donc il y a toujours un problème !
geygey wrote:essai de l'option radeon.dynpm=1 avec résultats mitigés :
- je suis a peu près tranquille niveau bruit avec le ventilo qui se calme
- mais kms est désactivé sur le noyau et le DRI est désactivé (peu plus activer compiz)
Pourrais tu passer la commande après avoir démarrer ton système

$ sudo mount -t debugfs none /sys/kernel/debug/

Puis ensuite passer la commande

$ cat /sys/kernel/debug/dri/0/radeon_pm_info

- au démarrage juste après la commande précédente
- quand tu utilises intensivement ta carte graphique
- après avoir laisser ton système inactif quelques minutes
le fichier /0/radeon_pm_info n'existe pas (le dossier /0 n'existe pas)
geygey wrote:le fichier /0/radeon_pm_info n'existe pas (le dossier /0 n'existe pas)
Il faut faire le mount avant....
$ sudo mount -t debugfs none /sys/kernel/debug
[sudo] password for azerty:

$ cd /sys/kernel/debug/dri/0

$ pwd
/sys/kernel/debug/dri/0

$ ll
total 0
-r--r--r--. 1 root root 0 17 mai 2010 bufs
-r--r--r--. 1 root root 0 17 mai 2010 clients
-r--r--r--. 1 root root 0 17 mai 2010 gem_names
-r--r--r--. 1 root root 0 17 mai 2010 gem_objects
-r--r--r--. 1 root root 0 17 mai 2010 name
-r--r--r--. 1 root root 0 17 mai 2010 queues
-r--r--r--. 1 root root 0 17 mai 2010 radeon_fence_info
-r--r--r--. 1 root root 0 17 mai 2010 radeon_gtt_mm
-r--r--r--. 1 root root 0 17 mai 2010 radeon_pm_info
-r--r--r--. 1 root root 0 17 mai 2010 radeon_vram_mm
-r--r--r--. 1 root root 0 17 mai 2010 vm
-r--r--r--. 1 root root 0 17 mai 2010 vma

$ cat radeon_pm_info
default engine clock: 850000 kHz
current engine clock: 849970 kHz
default memory clock: 1200000 kHz
current memory clock: 1200000 kHz
je l'ai deja monté mais le dossier n'existe pas :
[root@PC-GEOFFREY-FEDORA dri]# mount -t debugfs none /sys/kernel/debug
mount: none est déjà monté ou /sys/kernel/debug est occupé
mount: selon mtab none est déjà monté sur /sys/kernel/debug
[root@PC-GEOFFREY-FEDORA dri]# cd /sys/kernel/debug/dri/0
bash: cd: /sys/kernel/debug/dri/0: Aucun fichier ou dossier de ce type
problème en partie réglé : je suis passé sur la branche .34 du noyau (via koji) et le paramètre radeon.dynpm=1 ne cause plus de désactivation de kms et du dri, avec en prime un power management amélioré.

mais je suis encore une fois sur un noyau rawhide ! xD
Au passage ici c'est le sujet pour fedora 12... et .34 c'est pas encore pour Fedora 13, qui je rappel dispose des avancées significatives à ce niveau.

Je pense qu'il devrait être disponible rapidement sous Fedora 13, mais c'est mort pour fedora 12.
ok, excuses pour la digression 😉
il faudrait penser à ouvrir un topic pour fedora 13 (je sais je suis pressé :p)
c'est une très bonne nouvelle si le .34 va être intégré prochainement à fédora 13
Sur ma config les effets du paramètre radeon.dynpm=1 ne sont pas évidents :
Linux azerty 2.6.33.4-96.fc13.x86_64 #1 SMP Mon May 17 06:41:32 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
SANS le paramètre radeon.dynpm=1
[ 9.818] Kernel command line: ro root=/dev/mapper/vg_lxdidier00-lv_root rd_LVM_LV=vg_lxdidier00/lv_root rd_LVM_LV=vg_lxdidier/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=fr_FR.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=fr-latin9 rhgb quiet

[ 9.835] (II) Primary Device is: PCI 01@00:00:0
[ 9.835] (II) [KMS] Kernel modesetting enabled.
AVEC le paramètre radeon.dynpm=1
[ 9.509] Kernel command line: ro root=/dev/mapper/vg_lxdidier00-lv_root rd_LVM_LV=vg_lxdidier00/lv_root rd_LVM_LV=vg_lxdidier/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=fr_FR.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=fr-latin9 rhgb quiet radeon.dynpm=1

[ 9.527] (II) Primary Device is: PCI 01@00:00:0
[ 9.527] (II) [KMS] drm report modesetting isn't supported.

[ 9.806] (II) RADEON(0): Dynamic Power Management Disabled
enfin AVEC le paramètre radeon.dynpm=0
[ 9.459] Kernel command line: ro root=/dev/mapper/vg_lxdidier00-lv_root rd_LVM_LV=vg_lxdidier00/lv_root rd_LVM_LV=vg_lxdidier/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=fr_FR.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=fr-latin9 rhgb quiet radeon.dynpm=0

[ 9.478] (II) Primary Device is: PCI 01@00:00:0
[ 9.478] (II) [KMS] drm report modesetting isn't supported.

[ 9.749] (II) RADEON(0): Dynamic Power Management Disabled
Donc dès que je spécifie radeon.dynpm dans mes paramètres de boot KMS est disabled.

Edit: https://bugzilla.redhat.com/show_bug.cgi?id=593225
Bonjour

Suite à une discution sur le channel irc fedora-fr, je peux juste vous dire que les pilotes propriétaires de chez ati sont fonctionnels sur ma config.
uname -r : 2.6.32.11-99.fc12.x86_64
ati-driver-installer-10-4-x86.x86_64.run
xorg-x11-server-Xorg-1.7.6-4.fc12.x86_64

glxgears : 12000

J'ai une ati HD5780
Normalement ils sont fonctionnel aussi avec la version rpmfusion qui reste préférable à la version .run en utilisant la méthode d'installation de Fedora 11 (voir documentation). Je ne l'ai pas confirmé par manque de temps, c'est pour cela que la doc ne l'intègre pas.

Au passage de fedora 13, il faudra attendre que Ubuntu supporte xorg-x11-server-Xorg 1.8 pour que cela soit fonctionnel, ce qui n'arrivera pas avant plusieurs versions. Donc nous retomberons sur le même problème...

Je rappel que la version de rpmfusion est préférable à la version .run, car ce n'est pas parce qu'elle s'installe bien aujourd'hui, que ce sera toujours le cas demain.
VINDICATORs wrote:Au passage de fedora 13, il faudra attendre que Ubuntu supporte xorg-x11-server-Xorg 1.8 pour que cela soit fonctionnel, ce qui n'arrivera pas avant plusieurs versions. Donc nous retomberons sur le même problème...
Et là on atteint les limites du système..... Linux est-il viable au quotidien dans ces conditions ?
  • [supprimé]

didierg wrote:
VINDICATORs wrote:Au passage de fedora 13, il faudra attendre que Ubuntu supporte xorg-x11-server-Xorg 1.8 pour que cela soit fonctionnel, ce qui n'arrivera pas avant plusieurs versions. Donc nous retomberons sur le même problème...
Et là on atteint les limites du système..... Linux est-il viable au quotidien dans ces conditions ?
Les limites du système on les connait, ce sont les logiciels propriétaires.
lecbee wrote:Les limites du système on les connait, ce sont les logiciels propriétaires.
Là on n'est pas dans le cas de logiciel mais de driver intimement lié au matériel :

- Soit je boote sur Linux et j'ai un ventilo qui fait un bruit d'enfer et pas d'accélération 3D
- Soit je boote sur Windows 7 et j'ai une machine beaucoup plus silencieuse et l'accélération 3D

Le problème est que cette situation perdure et risque de perdurer assez longtemps....
  • [supprimé]

  • Modifié
Je pensais que tu parlais du problème de synchro de fglrx avec xorg. Enfin c'est ce que tu citais.
didierg wrote:
lecbee wrote:Les limites du système on les connait, ce sont les logiciels propriétaires.
Là on n'est pas dans le cas de logiciel mais de driver intimement lié au matériel :

- Soit je boote sur Linux et j'ai un ventilo qui fait un bruit d'enfer et pas d'accélération 3D
- Soit je boote sur Windows 7 et j'ai une machine beaucoup plus silencieuse et l'accélération 3D

Le problème est que cette situation perdure et risque de perdurer assez longtemps....
pareil pour moi et je pense aussi que tant qu'AMD se focalisera sur Ubuntu, ce sera pas demain la veille.

Concernant le paramètre radeon.dynpm=1 sous un noyau .33, le KMS est désactivé et plus d'accélération matérielle. Il faut passer sur la branche .34 (mails là on n'est plus dans le cadre du topic ^^)
xorg-x11-server-Xorg 1.8 est en stable, la 1.7 est en stable depuis plusieurs mois et cela vient juste d'être supporté par le pilote qui sort généralement entre 1 et 2 mois après la conception de la version. Ubuntu est plus conservatrice que Fedora qui vas toujours de l'avant. ATI se basant sur Ubuntu prend donc du retard, même si noyau/serveur graphique et autres sortent en version stable. Et je ne parle pas des versions suivante, car c'est peut être trop en demander.

Le pilote libre suit les sorties du noyau et du serveur graphique vu qu'il est développé au même rythme ou presque. Fedora vas encore plus vite comme par exemple la série des 6..13 alors que la version courante était la 6.12 du pilote libre. Comme tout est séparé, cela permet au noyau de se développer à son rythme, la librairie graphique à la sienne, le serveur graphique...

Nvidia est moins dépendant de tout cela, ce qui explique qu'ils ont moins de problème à ce niveau vu qu'ils intègres leur propre routines ou autres. Par contre on profite plus difficilement des avancés qu'apporte le reste.

Le pilote libre permettra de ne plus être dépendant de cette longue, voir très très longue, attente.

Gagner des points à GLXGEAR ne veut pas dire que tout fonctionne parfaitement, en 2D et vidéo le pilote proprio se fait atomiser par le pilote libre. Sans compter qu'il faut souvent passer par d'autres outils, etc...

De plus le pilote proprio se focalise maintenant principalement sur les R8xx, avec encore le support des R6xx/R7xx vu que la base est la même pour ces trois générations (beaucoup moins pour le R8xx, mais quand même). Donc il n'y a pas de pérennité à rester sur cette solution.

Reste le cas des mobility et autres ajouts que font les fabricants, même le pilote propriétaire n'est pas sur de tout supporter! Voir les problèmes lorsque AMD à voulu remettre de l'ordre dans tout cela. Même Nvidia c'est pris une engueulade quand ils ont voulus remettre les pendules à l'heure. J'espère que ça ira mieux à l'avenir vu qu'ils veulent en finir avec cette dispersion et ces puces "spécial" qui n'apporte pas plus de chose que cela.

Pour l'histoire de l'overcloking, pour un peut déborder, actuellement très peut de choses peuvent le justifier sous GNU/linux. Le GPGPU n'est pas encore du niveau de Nvidia et de son CUDA, donc on ne peut non plus l'inclure à l'heure actuel. Dès que les optimisations seront lancé, on pourra en reparler. Actuellement on attend le support d'openGL 3.2 et +, ainsi que le reste.

Et oui ici c'est le forum de Fedora 12, sans compter que le noyau 2.6.34 n'est pas encore là, ni officiellement pour Fedora stable, ni sur koji pour Fedora 12 ou 13. Pour l'histoire de la gestion d'énergie, vitesse de ventilo et autres, on en revient au même problème que pour les mobility et puces "spécial" avec une intégration et gestion qui est souvent différentes selon la marque, le fabricant, le modèle, etc... C'est pour cela que ce n'est pas simple à implanter, même si les docs officiels de chez AMD l'explique pour ce qu'ils ont développés et non spécifiquement selon ce que j'ai dit plus haut.
Bizarre

je viens de tester, pour voir, le pilote 10.3 de ATI/AMD sur fedora 12.
Installation nickel, création du module kernel par dkms aussi, création d'un fichier /etc/modprobe.d/blacklist-radeon

Je reboote, on ne sait jamais

sous user lambda, fgl_glxgears donne 240 FPS en gros
sous root, 1400 !

sans compter les petites imperfections au démarrage. Par contre curieusement, radeon a l'air encore chargé, lsmod le laisse apparaître. Peut être faudrait-il refaire un initramfs ?
Euh.... on est à la 10.4... Tu peux aussi voir la doc avec les changements...

La 10.3 ne supportant pas xorg-x11-server-xorg 1.7.