Bon et bien je vais tenté de recompiler tous ça, je vous tiens ferai un feedback (si j'y arrive)
4 jours plus tard
Kernel 2.6.34-38 et power management

Suite à une demande faite dans la kernel mailing list - http://lists.fedoraproject.org/pipermail/kernel/2010-June/002493.html - la version 2.6.34-38 du kernel disponible sur koji dispose désormais d'une option permettant d'activer la gestion d'alimentation du pilote radeon qui est inactivée par défaut :
* Sun Jun 13 2010 Kyle McMartin <kyle@redhat.com> 2.6.34-34 - Provide a knob to enable radeon_pm to allow users to test that functionality. Add radeon.pm=1 to your kernel cmdline in order to enable it. (It still defaults to off though.)
Il est possible vérifier la prise en compte de cette option en examinant les message drm du boot :

Par défaut sans l'option activée :
# uname -r
2.6.34-38.fc14.x86_64

# dmesg | grep -i drm
[drm] Initialized drm 1.1.0 20060810
[drm] radeon defaulting to kernel modesetting.
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (JUNIPER 0x1002:0x68B8).
---/---
[drm] Loading JUNIPER Microcode
---/---
[drm] Internal thermal controller with fan control
---/---
[drm] Initialized radeon 2.4.0 20080528 for 0000:01:00.0 on minor 0
Avec l'option activée
# dmesg | grep -i drm
[drm] Initialized drm 1.1.0 20060810
[drm] radeon defaulting to kernel modesetting.
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (JUNIPER 0x1002:0x68B8).
---/---
[drm] Loading JUNIPER Microcode
---/---
[drm] Internal thermal controller with fan control
[drm] radeon: power management initialized
---/---
[drm] Initialized radeon 2.4.0 20080528 for 0000:01:00.0 on minor 0
Si je regarde dans le répertoire /sys/class/drm/card0/device j'ai

le fichier power_method
profile
et le fichier power_profile
default
Par contre toujours aucun effect visible :
# mount -t debugfs none /sys/kernel/debug

# cat /sys/kernel/debug/dri/0/radeon_pm_info
default engine clock: 850000 kHz
current engine clock: 849970 kHz
default memory clock: 1200000 kHz
current memory clock: 1200000 kHz
Kernel 2.6.34-40 et power managemnt

Un nouveau kernel disponible sur koji inclut certains changements au niveau gestion de l'alimentation
* Wed Jun 16 2010 Kyle McMartin <kyle@redhat.com> 2.6.34-40 - Snag some more DRM commits into drm-next.patch that I missed the first time. - Fix up radeon_pm toggle to work with the upstream code.
Avec ce nouveau kernel 2.6.34-40 une nouvelle indication dans /sys/kernel/debug/dri/0/radeon_pm_info
sudo cat /sys/kernel/debug/dri/0/radeon_pm_info
default engine clock: 850000 kHz
current engine clock: 849970 kHz
default memory clock: 1200000 kHz
current memory clock: 1200000 kHz
voltage: 1125 mV
A mon humble avis, il vas sans doute falloir coupler tout cela avec les options du pilote suivantes comme décrit plus haut :
Option "ClockGating" "boolean"
              Enable dynamic clock gating.  This can help reduce heat and increase battery life by reducing power usage.
              Some users report reduced 3D performance with this enabled.  The default is off.

       Option "ForceLowPowerMode" "boolean"
              Enable  a  static  low  power mode.  This can help reduce heat and increase battery life by reducing power
              usage at the expense of performance. The default is off.

       Option "DynamicPM" "boolean"
              Enable dynamic power mode switching.  This can help reduce heat and  increase  battery  life  by  reducing
              power usage when the system is idle (DPMS active). The default is off.
Vu que par défaut tout est à OFF.

La dernière option "DynamicPM" est la meilleur candidate.

EDIT : Alors... Chez moi l'option radeon.pm=1 plante l'affichage au moment de la fin du lancement des services... Sans doute parce que ma carte est autogéré par elle même...

PS : Au passage on préfèrera utiliser "su -c 'commande'" que sudo sous Fedora 😉.
Dans « /boot/grub/grub.conf », j'ai rajouté : (comme l'a indiqué vindicators) 
radeon.pm=1
J'ai donc redémarré et puis vérifié que le power management a bien été initialisé, (ce n'était pas le cas avant).
# dmesg | grep drm | grep power
[drm] radeon: power management initialized
Puis j'ai forcé le profil utilisé : 
# echo low > /sys/class/drm/card0/device/power_profile
Et plus de bruit ! Le ventilateur s'est enfin calmé, je ne l'entends plus.

Mais quand j'utilise la mollette de la souris, ça lag un peu, j'ai donc opté pour le profil "auto" (je ne sais pas si c'est juste, mais en tous cas, ça marche bien :p) : 
# echo auto > /sys/class/drm/card0/device/power_profile
Avec en contrepartie, une très légères augmentation du bruit, maintenant, il s'agit d'affiner ces réglages.
Je test actuellement le noyau 2.6.35 en développement disponible sur koji (voir le sujet principal).

Le système est bien plus réactif que ce soit l'environnement qu'en jeux.

Par contre glxgear est réglé pour être synchro avec l'écran, donc on obtiens que 60i/s si l'écran est en 60Hz. Il faut régler cela normalement avec le programme driconf. Cela ne me dérange pas plus que ça vu que le pilote ne permet pas d'atteindre un nombre aussi important d'i/s dans les jeux de manière stable. Cela devrait permettre justement d'en proposer autant plus régulièrement.

Blender aussi est plus stable à ce niveau, surtout la 2.5.2 svn/trunk.

Je vais lancer un test avec urbanTerror pour voir si c'est meilleurs qu'avant.

Plus d'information à venir.

http://global.phoronix-test-suite.com/index.php?k=profile&u=anon-4798-851-17564

29.5i/s de moyenne en 1024x768... je m'attendais à mieux... enfin faut que je retrouve l'ancien test, c'était dans les 21i/s de moyenne... et un autre à 36.45i/s en 1280... http://global.phoronix-test-suite.com/index.php?k=profile&u=werner34-7198-28266-27343

Je vais revoir tout cela quand même, parce qu'à l'écran cela me parait quand même plus...

En 1280x1024 32bits http://global.phoronix-test-suite.com/index.php?k=profile&u=anon-29238-17060-1173
... Il faudra revoir les réglages de driconf pour voir si cela peut influer et voir un test avec tremulous.
Fais attention, plus la résolution est basse et moins la carte graphique est utilisée !
Il faut essayer avec de grandes résolutions (1680*1050 par exemple).
Avec le kernel-2.6.35-0.2.rc3.git0.fc14.x86_64 il n'y pas plus lieu d'ajouter radeon.pm=1 qui n'est plus supporté.

Après avoir fait un
# echo auto > /sys/class/drm/card0/device/power_profile
Il y a bien abaissement de la fréquence ce qui entraine une réduction du bruit du ventilateur :
$ sudo mount -t debugfs none /sys/kernel/debug
$ cat /sys/kernel/debug/dri/0/radeon_pm_info
default engine clock: 850000 kHz
current engine clock: 599950 kHz
default memory clock: 1200000 kHz
current memory clock: 1200000 kHz
voltage: 1000 mV
Je préfère quand même le profile low, plus aucun bruit ! 
# cat /sys/kernel/debug/dri/0/radeon_pm_info 
default engine clock: 625000 kHz
current engine clock: 159760 kHz
default memory clock: 993000 kHz
current memory clock: 250000 kHz
voltage: 1046 mV
Plus aucun bruit, mais la carte doit quand même se trainer non?

Perso pas de différence notable vu que c'est automatisé par la carte elle même...
Le silence, enfin =))))) avec le profile low
Maintenant reste à obtenir un profile automatique correct quand on n'utilise pas la 3D ou autres.
Depuis le temps que j'attendais cela. Merci le kernel 2.6.35 !
VINDICATORs wrote:Plus aucun bruit, mais la carte doit quand même se trainer non?

Perso pas de différence notable vu que c'est automatisé par la carte elle même...
Pas sur ce que j'en fais, en fait c'était une extension chromium qui faisait saccader les mouvements de molette dans ce même navigateur.

J'ai installé le kernel 2.6.35 et j'ai dû revenir à l'avant dernière version, plymouth ne se lance plus et je n'ai plus d'accélération pour compiz...
Tiens... plymouth se lance sans problème chez moi... compiz pas de problème, ta mis le mesa de F14? la libdrm de F14? et le pilote xorg-x11-drv-ati de F14?
J'ai en effet oublié de mettre à jour xorg-x11-drv-ati, le vrai problème venait du fait que j'ai oublié d'enlever `radeon.pm=1` dans les paramètres de lancement du noyau.
Au temps pour moi.

Sinon, une autre question, je dois à chaque fois exécuter cette commande : 
# echo low > /sys/class/drm/card0/device/power_profile
Je l'ai donc mise dans : 
/etc/rc.local
Est-ce la bonne méthode ? Ou existe-t-il quelque chose de plus "propre" ?
6 jours plus tard
@périclès : Il y a bien plus propre comme méthode ! Ajoute plutôt la ligne suivante au fichier /etc/sysctl.conf :
class.drm.card0.device.power_profile = low
Je suis aussi en train d'utiliser le noyau .35 de F14, mais je ne suis que moyennement convaincu (j'ai juste testé avec auto). Même si j'ai perdu 2-3°C et que le ventilo tourne un peu moins vite, ça reste bien supérieur à ce que j'avais quand j'utilisais les bonnes options avec le pilote en UMS.
Bouska wrote:@périclès : Il y a bien plus propre comme méthode ! Ajoute plutôt la ligne suivante au fichier /etc/sysctl.conf :
class.drm.card0.device.power_profile = low
Que retourne la commande
cat /sys/class/drm/card0/device/power_profile
en spécifiant le paramètre dans /etc/sysctl.conf ?

Sur ma machine en spécifiant le paramètre auto dans /etc/sysctl.conf je suis toujours en default quand je regarde dans /sys/class/drm/card0/device/power_profile

En revanche, si je le spécifie par un echo...... dans /etc/rc.local il est bien pris en compte.
Arf, j'ai rien dit... :-? /etc/sysctl.conf sert à modifier des paramètres dans /proc/sys ; ça n'a aucun effet sur /sys. Donc la meilleure solution, reste bien la ligne de commande dans le /etc/rc.local

Edit : Je viens de tester avec "low", et là, c'est le retour du bonheur ! Je regrette néanmoins que ça fasse quand même lagguer la 2D simple tel qu'un déplacement de fenêtre, mais ça reste utilisable au jour le jour 🙂
4 jours plus tard
Il faut aussi mettre à jour xorg-x11-server, vu que c'est fait pour la 1.9 cette mise à jour du pilote...
La dernière version du pilote est effectivement compatible avec xorg-x11-server 1.9 mais elle fonctionne sans problème avec la version 1.8
update to latest git snapshot with 1.9 server support
la dernière version de xorg-x11-server disponible sur koji étant : xorg-x11-server-Xorg-1.8.99.904-1.20100702.fc14

Edit:

Sur mon système X ne démarre pas avec xorg-x11-server-Xorg-1.8.99.904-1.20100702. J'ai dû réinstallé xorg-x11-server-Xorg-1.8.2-1 et xorg-x11-server-common-1.8.2-1
---/---
[ 23.582] Build ID: xorg-x11-server 1.8.99.904-1.20100702.fc14
---/---
[ 23.598] (II) Loading extension XFree86-DRI
[ 23.598] (II) LoadModule: "dri2"
[ 23.600] (II) Loading /usr/lib64/xorg/modules/extensions/libdri2.so
[ 23.600] (II) Module dri2: vendor="X.Org Foundation"
[ 23.600] compiled for 1.8.99.904, module version = 1.2.0
[ 23.600] ABI class: X.Org Server Extension, version 4.0
[ 23.600] (II) Loading extension DRI2
[ 23.600] (II) LoadModule: "radeon"
[ 23.601] (II) Loading /usr/lib64/xorg/modules/drivers/radeon_drv.so
[ 23.601] dlopen: /usr/lib64/xorg/modules/drivers/radeon_drv.so: undefined symbol: miEmptyData
[ 23.601] (EE) Failed to load /usr/lib64/xorg/modules/drivers/radeon_drv.so
[ 23.601] (II) UnloadModule: "radeon"
[ 23.601] (EE) Failed to load module "radeon" (loader failed, 7)
[ 23.601] (EE) No drivers available.
[ 23.601]
Fatal server error:
[ 23.601] no screens found
[ 23.601]
Ma config fonctionnelle actuelle est donc :

kernel-2.6.35-0.24.rc3.git7.fc14.x86_64
libdrm-2.4.21-3.fc14.x86_64
xorg-x11-drv-ati-6.13.1-0.20100705git37b348059.fc14.x86_64
xorg-x11-server-Xorg-1.8.2-1.fc13.x86_64
mesa-dri-drivers-7.9-0.2.fc14.x86_64