Normal, experimental est pour nouveau maintenant... (voir doc...)
VINDICATORs wrote:Et oui sans distinctions, les R8xx devraient être supporté d'ici peut (toujours d'après les rapports de développement et phoronix).
Un certain nombre d'échanges sur la kernel mailing list me rendent modérément optimiste sur la disponibilité rapide du support des R8xx avant le kernel 2.6.36.

Il semble en effet qu'il y ait un peu de flottement entre Dave Airlie et Linus Torvalds, ce dernier souhaitant avant tout au niveau drm que toutes les régressions soient fixées et non que de nouvelles fonctionnalités soient supportées :
Date Mon, 7 Jun 2010 11:00:51 -0700 (PDT)
From Linus Torvalds <>
Subject Re: [git pull] drm fixes



On Mon, 7 Jun 2010, Dave Airlie wrote:
>
> 3 regressions fixes, one radeon loading on IGP, one i865 loading, one and
> an evergreen userspace interaction workaround.

This is:

26 files changed, 372 insertions(+), 66 deletions(-)

and there are apparently several reports of known problems (the problem
with modesetting) that isn't even addressed.

See my -rc2 announcement. I absolutely do NOT want any new code. I want
regression fixes, fixes for security issues, and fixes for oopses. Nothing
else. I'm going to be hardassed about this, because quite frankly, if I'm
not, people will just continue with the same-old, same-old, and send me
random stuff without thinking hard about it.

So please. Just make me a tree that has regression fixes _only_. I'm not
AT ALL interested in "it is useful to report the gpu temp". If it was so
useful, and if it was ready before the merge window, it should hav gone in
then. That clearly wasn't the case, so it's not going in now either.

Linus
http://lkml.org/lkml/2010/6/7/240

Appliqué à la lettre, cela signifie que les nouveaux développements pour les R8xx ne seront pas intégrés dans le kernel dans l'immédiat...

Je pense personnellement qu'il ne faut pas se précipiter pour acheter une carte HD5xxx à base de R8xx et qu'il peut être intéressant d'acheter d'une carte de génération précédente.
Le support sera effectif avec Mesa au travers des développements de Gallium3D.

Après quand je parle rapidement cela ne veux pas non plus dire dans la minute qui suit cette information. Sans compter que ce n'est pas parce que ce n'est pas intégré officiellement dans le noyau officiel que cela ne sera pas le cas dans le noyau préparé par Fedora. Comme ce fut le cas avec nouveau et "radeon" pendant un moment (voir les discutions enflammés à ce sujet entre linus et les développeurs de nouveau...).

Par contre je ne pige pas cette histoire de "nouvelles fonctionnalité" à ce niveau. L'architecture R8xx "evergreen" commence à avoir de l'âge, donc il ne faudrait pas non plus attendre la saint glinglin pour être supporté.

Enfin bref... Tout cela ne dépend pas que du noyau.
Sur le pourquoi du nomodeset, man radeon en dit plus :
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 perfor-
mance. 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 ma faible utilisation de la carte graphique (Compiz, WoG), l'activation des deux dernières options étaient plus que bénéfique : diminution de 10°C de la température du GPU, avec le ventilateur toujours au minimum, une batterie qui durait plus longtemps. Malheureusement, ce n'est pas vraiment supporté par le Projet, donc avec les bugs dû à l'UMS, j'ai du fait un choix cornélien.
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).