Au passage, si j'ai le temps, je vais entamer quelques tests sur les sections du xorg.conf dispatché en autant de fichiers. Comme cela à l'air de fonctionner comme cela maintenant (répertoire xorg.conf.d/).

Sinon le xorg.conf est toujours pris en compte prioritairement.

Par contre tu te passe de l'accélération matériel dans pas mal de cas.

  • [supprimé]

  • Message #33
VINDICATORs wrote:Au passage, si j'ai le temps, je vais entamer quelques tests sur les sections du xorg.conf dispatché en autant de fichiers. Comme cela à l'air de fonctionner comme cela maintenant (répertoire xorg.conf.d/).
Ah ouai ça sera cool parce que je pense que quasiment personne ne doit savoir comment cela fonctionne maintenant (moi le premier).
En fait c'est juste que normalement tout est séparé, mais faut que je confirme, parce que cela à l'air complexe dans un certain sens...
VINDICATORs wrote:Enfin bref... Tout cela ne dépend pas que du noyau.
Ma compréhension est que le driver xorg et mesa qui s'exécutent tous les deux en user space utilisent tous les deux les fonctionnalités drm du kernel au travers de libdrm.

Pour preuve, libdrm fait partie des dépendances requises :
$ rpm -qpR mesa-dri-drivers-7.9-0.1.fc14.x86_64.rpm
---/---
libdrm.so.2()(64bit)
libdrm_intel.so.1()(64bit)
libdrm_radeon.so.1()(64bit)
---/---
$ rpm -qpR xorg-x11-drv-ati-6.13.1-0.20100519git428125c09.fc14.x86_64.rpm
---/---
libdrm >= 2.4.17-0.1
libdrm.so.2()(64bit)
libdrm_radeon.so.1()(64bit)
---/---
A partir de là, tant que drm qui est inclut dans le kernel ne supporte pas complètement les r8xx j'ai du mal à voir comment ça peut fonctionner avec les cartes pourvues de ce GPU...
Oui mais seul cela ne fait pas tout. Après il faut voir comme ils vont faire et comment cela vas sortir. Mesa pousse pour que ce soit implanté dans Mesa 7.9 le plus rapidement possible, donc le reste devrait suivre aussi. Fedora/redhat est souvent en avance à ce sujet par rapport à la version "stable" officiel.

Les travaux de gallium3D avance rapidement à ce sujet et seront rapidement intégré à Mesa si tout vas bien.

De plus à la vitesse que sortent les RC du noyau, il faudra voir comment cela se présente.

Pour changer de sujet, j'aimerais bien pouvoir avoir accès aux versions Bétâ du pilote propriétaire, mais il faut se ubuntoutiser pour cela... Donc c'est rapé...
Je crois qu'il faut télécharger la version du noyau concernée, exécuter le patch grâce à la commande éponyme et compiler le tout :hammer:
J'allais le dire. Tu peux déjà passer à ce qui est indiqué sur le sujet principal.

De plus, encore une fois, ce patch est principalement à utiliser avec des cartes qui respectent les spécifications officiel de l'atombios, ce que certains équipementiers ne font pas à 100%... C'est souvent un beau bordel et la cause des problèmes à ce niveau! Demandé à certains qui ne passe pas par le pilote préparé par l'équipementier et qui est souvent, très vite, abandonné après quelques temps...

A ce sujet le top, au niveau de la gestion de la vitesse du ventilateur, serait de pouvoir avoir du semi-automatique. Une gestion automatique couplé à une mollette pour ajusté au mieux le niveau bruit/efficacité. Ce serait déjà une bonne idée... Ce qui ne peut se faire sur les ventilateurs d'origine.

Comme dit friandise, tu peux te construire un noyau avec ce patch, il faudrait voir du coté de la documentation pour cela : http://doc.fedora-fr.org/wiki/Recompilation_du_noyau_Fedora

A ce sujet, en cas de problèmes, tu pourra toujours relancer ta machine sur une version fonctionnel du noyau, vu que Fedora garde les 3 derniers et donc au moins un qui fonctionne...

N'oublie pas de nous faire un compte rendu de tes "expérimentations" à ce sujet si tu te lance dedans.
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 !