Bon et bien je vais tenté de recompiler tous ça, je vous tiens ferai un feedback (si j'y arrive)
[RADEON] Expérimentation :
4 jours plus tard
- Modifié
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 :
Par défaut sans l'option activée :
le fichier power_method
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 :
Il est possible vérifier la prise en compte de cette option en examinant les message drm du boot :* 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.)
Par défaut sans l'option activée :
Avec 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
Si je regarde dans le répertoire /sys/class/drm/card0/device j'ai# 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
le fichier power_method
et le fichier power_profileprofile
Par contre toujours aucun effect visible :default
# 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
- Modifié
Kernel 2.6.34-40 et power managemnt
Un nouveau kernel disponible sur koji inclut certains changements au niveau gestion de l'alimentation
Un nouveau kernel disponible sur koji inclut certains changements au niveau gestion de l'alimentation
Avec ce nouveau kernel 2.6.34-40 une nouvelle indication dans /sys/kernel/debug/dri/0/radeon_pm_info* 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.
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
- Modifié
A mon humble avis, il vas sans doute falloir coupler tout cela avec les options du pilote suivantes comme décrit plus haut :
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 😉.
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.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)
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) :
radeon.pm=1# dmesg | grep drm | grep power
[drm] radeon: power management initialized# echo low > /sys/class/drm/card0/device/power_profileMais 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- Modifié
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.
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).
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
Après avoir fait un
Il y a bien abaissement de la fréquence ce qui entraine une réduction du bruit du ventilateur :# echo auto > /sys/class/drm/card0/device/power_profile
$ 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 mVPlus 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...
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 !
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 !
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.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...
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 :
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/etc/rc.local6 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 :
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.class.drm.card0.device.power_profile = low
Que retourne la commandeBouska 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
en spécifiant le paramètre dans /etc/sysctl.conf ?cat /sys/class/drm/card0/device/power_profile
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.
- Modifié
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 🙂
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
xorg-x11-drv-ati-6.13.1-0.20100705git37b348059.fc14 est disponible sur koji http://koji.fedoraproject.org/koji/buildinfo?buildID=181560
Il y a aussi une version actualisée de libdrm http://koji.fedoraproject.org/koji/buildinfo?buildID=181559
Il y a aussi une version actualisée de libdrm http://koji.fedoraproject.org/koji/buildinfo?buildID=181559
Il faut aussi mettre à jour xorg-x11-server, vu que c'est fait pour la 1.9 cette mise à jour du pilote...
- Modifié
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
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
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
la dernière version de xorg-x11-server disponible sur koji étant : xorg-x11-server-Xorg-1.8.99.904-1.20100702.fc14update to latest git snapshot with 1.9 server support
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
Ma config fonctionnelle actuelle est donc :---/---
[ 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]
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
- Modifié
Tiens , qu'elle sont les nouveautés de cette version ? Si quelqu'un a testé et qu'il peut nous donner les premiers retour ce serait intéressant . 🙂didierg wrote: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
la dernière version de xorg-x11-server disponible sur koji étant : xorg-x11-server-Xorg-1.8.99.904-1.20100702.fc14update to latest git snapshot with 1.9 server support
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
Ma config fonctionnelle actuelle est donc :---/---
[ 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]
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
ok, mais il faut le précisé.
Pour les nouveautés il faut suivre un peut le git du pilote : http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/
Sinon il faut voir les notes qui nous disent qu'il est recompiler pour supporter la version 1.9 du serveur graphique....
Pour les nouveautés il faut suivre un peut le git du pilote : http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/
Sinon il faut voir les notes qui nous disent qu'il est recompiler pour supporter la version 1.9 du serveur graphique....
Bonjour,
J'aimerai savoir si quelqu'un à tester une crossfire de HD48XX sur F13. Car j'ai des problèmes sous F12 et j'attends de savoir pour passer sous F13.
J'ai 2 HD4850, quand une seule est branchée tout va bien accélération 3D, compiz (la neige qui tombe, la pluie ... enfin tout les trucs inutiles qui font bien 😃). Par contre quand je branche les 2 pouf pastèque ça marche plus.
Ça viendrait de la version 7.5.X de xorg.
Donc j'aimerai savoir si quelqu'un a un crossfire de carte de la génération 48XX pour savoir si ça marche.
merci.
J'aimerai savoir si quelqu'un à tester une crossfire de HD48XX sur F13. Car j'ai des problèmes sous F12 et j'attends de savoir pour passer sous F13.
J'ai 2 HD4850, quand une seule est branchée tout va bien accélération 3D, compiz (la neige qui tombe, la pluie ... enfin tout les trucs inutiles qui font bien 😃). Par contre quand je branche les 2 pouf pastèque ça marche plus.
Ça viendrait de la version 7.5.X de xorg.
Donc j'aimerai savoir si quelqu'un a un crossfire de carte de la génération 48XX pour savoir si ça marche.
merci.
Là il faudrait passer par le pilote proprio, c'est préférable.
Par contre un crossfire ne se justifie pas encore sous gnu/linux, car il n'y a pas vraiment de jeux qui peuvent l'exploiter à fond.
Pour cela je te rapporte à la documentation sur le pilote propriétaire pour Fedora 12 qui dispose du dernier xorg-x11-server à être supporter par le pilote propriétaire, même si ce n'est pas la version la plus récente.
Petit à petit le pilote libre commence à intégré les avancées des différentes architectures des GPU Radeon, mais cela ne peut se faire en un jour.
Par contre un crossfire ne se justifie pas encore sous gnu/linux, car il n'y a pas vraiment de jeux qui peuvent l'exploiter à fond.
Pour cela je te rapporte à la documentation sur le pilote propriétaire pour Fedora 12 qui dispose du dernier xorg-x11-server à être supporter par le pilote propriétaire, même si ce n'est pas la version la plus récente.
Petit à petit le pilote libre commence à intégré les avancées des différentes architectures des GPU Radeon, mais cela ne peut se faire en un jour.
Effectivement le crossfire n'a pas encore de réelle utilité sous linux, mais j'ai un double boot avec windows pour les jeux.
Il me semblait que l'installation des driver proprio sous F12 ne marchait pas, en même temps ça fait longtemps que je me suis fait a l'idée et que je n'ai pas regardé la doc.
merci pour les précisions.
Il me semblait que l'installation des driver proprio sous F12 ne marchait pas, en même temps ça fait longtemps que je me suis fait a l'idée et que je n'ai pas regardé la doc.
merci pour les précisions.
Sous f12 oui, voir la doc...
Vu que ubuntu supporte en fin la version du serveur graphique 1.7.
Vu que ubuntu supporte en fin la version du serveur graphique 1.7.
- Modifié
Suite au rapport BZ 611753 le problème a été corrigé: https://bugzilla.redhat.com/show_bug.cgi?id=611753didierg wrote: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
Pour tester le dernier pilote opensource pour ATI avec Xorg 1.9 Beta il faut donc installer à partir de Koji :
libXfont-1.4.2-1.fc14.x86_64.rpm
xorg-x11-drv-ati-6.13.1-1.20100705git37b348059.fc14.x86_64.rpm
xorg-x11-drv-evdev-2.4.0-3.20100406.fc14.x86_64.rpm
xorg-x11-server-common-1.8.99.904-3.20100702.fc14.x86_64.rpm
xorg-x11-server-Xorg-1.8.99.904-3.20100702.fc14.x86_64.rpm
Par contre, ça ne bouge pas vite du coté de Mesa et donc toujours pas de 3D en vue pour les cartes HD 5xxx Evergreen...
Je vois que tu as un souci de "gel" d'écran, que je constate aussi avec le pilote radeon et une carte ATI 36XX. Il n'est pas possible de reproduire le bug. Ce que je constate, c'est que de manière aléatoire, l'écran s'éteint, j'ai un message de l'OSD qui indique que la configuration d'affichage n'est pas optimale, qu'il faut passer en 1920x1080, puis le moniteur s'éteint, et il n'y a aucune autre solution que le reboot sauvage.
- Modifié
Pourtant ça bouge pas mal chez mesa ( http://cgit.freedesktop.org/mesa/mesa ), mais il est vrai qu'ils ce concentrent pas sur les R8xx...
L'analyse des docs est quand même récente, donc il ne faut pas trop leurs en vouloir. Sans compter que toutes les docs ne doivent pas être encore disponible chez ATI.
Enfin bref, j'espère que ce noyau vas commencer à être optimisé, parce que par moment c'est un peut la cata niveau performance dans certains cas...
Au sujet de mesa, une nouvelle version vient de sortir avec une resynchronisation avec le git...
L'analyse des docs est quand même récente, donc il ne faut pas trop leurs en vouloir. Sans compter que toutes les docs ne doivent pas être encore disponible chez ATI.
Enfin bref, j'espère que ce noyau vas commencer à être optimisé, parce que par moment c'est un peut la cata niveau performance dans certains cas...
Au sujet de mesa, une nouvelle version vient de sortir avec une resynchronisation avec le git...
Je pense qu'au retour des vacances si rien n'a bougé je bazarderais la seule carte ATI que j'ai et la je remplacerais par une nVidia avec driver propriétaire comme sur mes autres machines.....VINDICATORs wrote:Pourtant ça bouge pas mal chez mesa ( http://cgit.freedesktop.org/mesa/mesa ), mais il est vrai qu'ils ce concentrent pas sur les R8xx...
Ca fait 9 mois que cette carte est sortie et il n'y a toujours pas de driver 3D, ça commence à faire un peu long....
Euh.... En pilote libre, sinon tu peux remettre F12,le pilote proprio est fonctionnel dessus.
Le problème étant qu'ils se basent sur ubuntu qui est plus conservatrice que fedora. D'où le retard.
Pour le pilote libre et la bibliothèque MESA, j'ai déjà dit le pourquoi du comment...
Une nouvelle architecture demande souvent beaucoup de travail pour être supporté, comme le R8xx est très différents par rapport au R6xx et au R7xx (qui n'est qu'un R6xx très améliorer).
Maintenant... ne vas pas croire que tu n'aura aucun problème avec les nvidia, à voir les sujets à son sujet ce n'est pas toujours tout rose.
Après tu fais comme tu veux, chacu'un est libre de faire ce qu'il veut.
Le problème étant qu'ils se basent sur ubuntu qui est plus conservatrice que fedora. D'où le retard.
Pour le pilote libre et la bibliothèque MESA, j'ai déjà dit le pourquoi du comment...
Une nouvelle architecture demande souvent beaucoup de travail pour être supporté, comme le R8xx est très différents par rapport au R6xx et au R7xx (qui n'est qu'un R6xx très améliorer).
Maintenant... ne vas pas croire que tu n'aura aucun problème avec les nvidia, à voir les sujets à son sujet ce n'est pas toujours tout rose.
Après tu fais comme tu veux, chacu'un est libre de faire ce qu'il veut.
- Modifié
C'est vrai que ça peut ce comprendre , moi j'ai la 3d avec le pilote libre même si encore ça demande à être améliorer , le support de la vidéo HD manque aussi . Mais je ne suis pas à plaindre comparer à certains .VINDICATORs wrote:Euh.... En pilote libre, sinon tu peux remettre F12,le pilote proprio est fonctionnel dessus.
Le problème étant qu'ils se basent sur ubuntu qui est plus conservatrice que fedora. D'où le retard.
Pour le pilote libre et la bibliothèque MESA, j'ai déjà dit le pourquoi du comment...
Une nouvelle architecture demande souvent beaucoup de travail pour être supporté, comme le R8xx est très différents par rapport au R6xx et au R7xx (qui n'est qu'un R6xx très améliorer).
Maintenant... ne vas pas croire que tu n'aura aucun problème avec les nvidia, à voir les sujets à son sujet ce n'est pas toujours tout rose.
Après tu fais comme tu veux, chacu'un est libre de faire ce qu'il veut.
De plus , j'ai un double boot avec F11 et avec le pilote proprio je ne suis même pas sure que ma carte tourne à pleine capacité , un glxgearx me donne 65 FPS au lieu de 8500 FPS sur une centOS . Les jeux ont l'aire de tourner correctement , c'est pourquoi je ne sais pas si mon pilote fonctionne ou non . Au final on ce retrouve avec un pilote proprio non prévu pour fedora et un pilote libre en cours de développement . Je pense quand même qu'ATI pourrait faire un effort et trouver une solution à la Nvidia pour que ses pilotes soient un maximum compatible avec les dernières version de Xorg.
Bonjour
@VINDIC' en particulier:
Y a-t-il une raison connue pour laquelle la machine freeze lorqu'on exécute un fgl_glxgears sur F12 avec le pilote catallyst installé à partir de rpmfusion, selon la doc ?
merci d'avance
@VINDIC' en particulier:
Y a-t-il une raison connue pour laquelle la machine freeze lorqu'on exécute un fgl_glxgears sur F12 avec le pilote catallyst installé à partir de rpmfusion, selon la doc ?
merci d'avance
- Modifié
Euh... Au passage glxgear actuellement est bloqué sur la fréquence maximale de l'écran... Donc rien à voir à ce niveau... :
Pour fgl... Vu que je préfère faire de vrais test par rapport à celui ci... Utilise phoronix-test-suite disponible dans les dépôts. Sinon la dernière fois que je l'ai testé je n'ai pas eu de problème de ce genre... Au passage c'est la même chose pour glxgear...
Un test avec nexuiz ou urban terror par exemple?
glxgears
[b]Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.[/b]Pour fgl... Vu que je préfère faire de vrais test par rapport à celui ci... Utilise phoronix-test-suite disponible dans les dépôts. Sinon la dernière fois que je l'ai testé je n'ai pas eu de problème de ce genre... Au passage c'est la même chose pour glxgear...
Un test avec nexuiz ou urban terror par exemple?
J'essaie, mais 50 paquets de dépendances à installer je suis moyennement enthousiaste...
glxgears me rend un bon chiffre de l'ordre de 4500 FPS. Pour info fgl_glxgears plante aussi avec le pilote téléchargé du site AMD
glxgears me rend un bon chiffre de l'ordre de 4500 FPS. Pour info fgl_glxgears plante aussi avec le pilote téléchargé du site AMD
- Modifié
Bonne idée j'ai commencé à faire des test avec phoronix test suite qui fonctionne vraiment bien .Ce qui est bizarre c'est qu'un glxgears donne sur F12 1500 FPS avec le pilote libre. Avec F11 et le pilote propriétaire 65 FPS et sur F11 sans aucune mise à jour du système et toujours avec le pilote proprio 8500 FPS.. Il n'y a que le bon vieux benchmark auquel on peut ce fier on dirait.. J'ai lu aussi que le CPU était largement exploité avec glxgears.VINDICATORs wrote:Euh... Au passage glxgear actuellement est bloqué sur la fréquence maximale de l'écran... Donc rien à voir à ce niveau... :La réponse était dans le lancement de la commande...glxgears [b]Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate.[/b]
Pour fgl... Vu que je préfère faire de vrais test par rapport à celui ci... Utilise phoronix-test-suite disponible dans les dépôts. Sinon la dernière fois que je l'ai testé je n'ai pas eu de problème de ce genre... Au passage c'est la même chose pour glxgear...
Un test avec nexuiz ou urban terror par exemple?
EDIT:
Quand je lance le test nexuiz de phoronix le jeu est plus qu'au ralenti . Est ce que la version d'OpenGL utilisé peut avoir de grosse répercussion sur les performance 3D des test réalisé ?
- Modifié
Re ,
J'ai fais des tests sur différentes distributions avec le pilote libre sur ma F12 , et le pilote proprio sur une F11 et une Ubuntu .
Je voulais savoir à qu'elle point le pilote libre était moins performant en 3D que le pilote proprio et aussi s'il existait une différence de performance entre F11 et Ubuntu en utilisant le pilote proprio.
Voici les résultats de mes tests avec le benchmark de phoronix en version 2.6.1 sur les 3 distributions avec nexuiz :
http://global.phoronix-test-suite.com/index.php?k=profile&u=brain-5879-13832-7597
On s'aperçoit que le pilote proprio est environ 5 fois plus rapide que le pilote libre avec ma HD 4770. Et surtout le plus important pour moi était de savoir si le pilote proprio fonctionnait mieux sur Ubuntu que sur une Fedora 11 .
Ce n'est pas le cas les résultats ce valent largement entre les deux distributions , quelques fois les résultats sont même très légèrement inférieur à F11 en refaisant le test plusieurs fois , donc ça ce vaut.
Si on pouvait avoir d'autres comparatif ce serait bien. Même si officiellement le pilote ATI ne supporte pas les nouvelles versions de Xorg il semble toutefois fonctionner plus que correctement et certainement de la même façon sur F12.
Est on sure que le pilote proprio ne fonctionne pas sous F13? On ne peut plus vraiment ce fier aux versions de Xorg supporté officiellement par ATI je crois..
Est ce que quelqu'un a fait des tests benchmark avec le pilote libre sur F13 ? Je serais curieux de savoir ce que ça donne avec le pilote libre et une autre carte sur F13.
J'ai fais des tests sur différentes distributions avec le pilote libre sur ma F12 , et le pilote proprio sur une F11 et une Ubuntu .
Je voulais savoir à qu'elle point le pilote libre était moins performant en 3D que le pilote proprio et aussi s'il existait une différence de performance entre F11 et Ubuntu en utilisant le pilote proprio.
Voici les résultats de mes tests avec le benchmark de phoronix en version 2.6.1 sur les 3 distributions avec nexuiz :
http://global.phoronix-test-suite.com/index.php?k=profile&u=brain-5879-13832-7597
On s'aperçoit que le pilote proprio est environ 5 fois plus rapide que le pilote libre avec ma HD 4770. Et surtout le plus important pour moi était de savoir si le pilote proprio fonctionnait mieux sur Ubuntu que sur une Fedora 11 .
Ce n'est pas le cas les résultats ce valent largement entre les deux distributions , quelques fois les résultats sont même très légèrement inférieur à F11 en refaisant le test plusieurs fois , donc ça ce vaut.
Si on pouvait avoir d'autres comparatif ce serait bien. Même si officiellement le pilote ATI ne supporte pas les nouvelles versions de Xorg il semble toutefois fonctionner plus que correctement et certainement de la même façon sur F12.
Est on sure que le pilote proprio ne fonctionne pas sous F13? On ne peut plus vraiment ce fier aux versions de Xorg supporté officiellement par ATI je crois..
Est ce que quelqu'un a fait des tests benchmark avec le pilote libre sur F13 ? Je serais curieux de savoir ce que ça donne avec le pilote libre et une autre carte sur F13.
Bon... A force de répéter cela devrait un peut rentrer...
Le pilote proprio est plus performant actuellement, car plus travaillé avec les sources etc... Pourquoi il tourne sur F12 et pas sur F13? à cause du serveur graphique qui est en version 1.8 sur F13 alors que le pilote ne supporte (enfin parce qu'il lui en a fallu du temps...) que le 1.7.
Pourquoi plus performant sous Ubuntu que sur Fedora? parce que le pilote est testé par Ubuntu et optimisé Ubuntu!
Pour le pilote libre, actuellement on recherche le support en fonctionnalité, la performance viendra petit à petit.
Pourquoi ce n'est pas au niveau du pilote proprio? parce qu'un gpu est très très très (vous m'arrêtez quand vous en avez marre!)très très.... complexe et touche énormément de domaine. il a fallut énormément de travail pour que tout fonctionne, comme ils ne ce concentrent pas non plus que sur un gpu, ni sur une marque, ni sur un modèle, cela prend pas mal de temps.
Pourquoi privilégié un pilote libre par rapport à un pilote propriétaire? parce que cela est développé au rythme des avancées du noyau, serveur graphique, etc... Vu que le pilote propriétaire suit le développement de Ubuntu qui est plus en retard que Fedora, cela entraine énormément de retard dans le support. La faute à Fedora? à ATI?? en fait à ATI qui ne suit pas les versions stabilisés tant du noyau, que du serveur graphique! La faute en partie à Ubuntu qui monopolise beaucoup de choses...
Si l'on suit l'avancement du développement de Mesa/pilote graphique, cela avance très rapidement en étant presque reparti de zéro. Sans compter que c'est généralement fonctionnel plus rapidement que le pilote proprio.
Pourquoi la HD5xxx R8xx evergreen n'est pas encore supporté? parce que l'architecture est quasiment toute nouvelle et que cela prend du temps de supporter. Sans compter que toutes les docs ne sont pas toujours disponible.
Il ne faut pas croire que pilote proprio = pilote libre et que ce n'est pas normal que ce ne soit pas au niveau, le code n'est pas à l'identique et cela prend quand même pas mal de temps, même en ayant digéré les docs disponible.
Enfin bref, je te rappel qu'en 2D le pilote proprio est ridicule et souvent en vidéo...
Le pilote proprio est plus performant actuellement, car plus travaillé avec les sources etc... Pourquoi il tourne sur F12 et pas sur F13? à cause du serveur graphique qui est en version 1.8 sur F13 alors que le pilote ne supporte (enfin parce qu'il lui en a fallu du temps...) que le 1.7.
Pourquoi plus performant sous Ubuntu que sur Fedora? parce que le pilote est testé par Ubuntu et optimisé Ubuntu!
Pour le pilote libre, actuellement on recherche le support en fonctionnalité, la performance viendra petit à petit.
Pourquoi ce n'est pas au niveau du pilote proprio? parce qu'un gpu est très très très (vous m'arrêtez quand vous en avez marre!)très très.... complexe et touche énormément de domaine. il a fallut énormément de travail pour que tout fonctionne, comme ils ne ce concentrent pas non plus que sur un gpu, ni sur une marque, ni sur un modèle, cela prend pas mal de temps.
Pourquoi privilégié un pilote libre par rapport à un pilote propriétaire? parce que cela est développé au rythme des avancées du noyau, serveur graphique, etc... Vu que le pilote propriétaire suit le développement de Ubuntu qui est plus en retard que Fedora, cela entraine énormément de retard dans le support. La faute à Fedora? à ATI?? en fait à ATI qui ne suit pas les versions stabilisés tant du noyau, que du serveur graphique! La faute en partie à Ubuntu qui monopolise beaucoup de choses...
Si l'on suit l'avancement du développement de Mesa/pilote graphique, cela avance très rapidement en étant presque reparti de zéro. Sans compter que c'est généralement fonctionnel plus rapidement que le pilote proprio.
Pourquoi la HD5xxx R8xx evergreen n'est pas encore supporté? parce que l'architecture est quasiment toute nouvelle et que cela prend du temps de supporter. Sans compter que toutes les docs ne sont pas toujours disponible.
Il ne faut pas croire que pilote proprio = pilote libre et que ce n'est pas normal que ce ne soit pas au niveau, le code n'est pas à l'identique et cela prend quand même pas mal de temps, même en ayant digéré les docs disponible.
Enfin bref, je te rappel qu'en 2D le pilote proprio est ridicule et souvent en vidéo...
On s'en tape un peu..... Ce que voit l'utilisateur c'est qu'une carte ATI HD5xxx sortie en octobre 2009 n'est toujours pas supportée totalement en juillet 2010.....VINDICATORs wrote:Pourquoi la HD5xxx R8xx evergreen n'est pas encore supporté? parce que l'architecture est quasiment toute nouvelle et que cela prend du temps de supporter. Sans compter que toutes les docs ne sont pas toujours disponible.
Si le même utilisateur avait acheté une carte nVidia de même génération à la même époque, il aurait une carte totalement supportée par le driver propriétaire....
A lire les différentes mailing lists qui traitent du développement du driver Radeon, je suis convaincu que de nombreux problèmes viennent de la volonté d'avoir un driver unique pour toutes les générations de processeurs graphiques ce qui pose de nombreux problèmes de régression....
nVidia a de son coté fait le choix d'avoir différents drivers en fonction des générations de processeurs graphiques et cela n'a jamais posé de problème...
- Modifié
Pour Rappel , voici mon précédent message:
Je crois que tu te méprends sur mes intentions. Les tests montrent si tu les as bien regardé, que justement sur une F11 avec un serveur graphique équivalent à Ubuntu la vitesse est identique ou quasi identique .
Que les pilotes soient développé pour Ubuntu et testé par eux même est une chose ,mais qu'ils fonctionnent aussi bien sur une Fedora disposant du même serveur graphique qu'Ubuntu en est une autre.
Je ne fais pas du "Pilote libre VS Pilote Proprio" , ce n'est évidemment pas le but et ce serait stupide . Je me suis simplement amusé à mesurer et à comparer la 3D sur chacun de ces deux pilotes. Je suis content du pilote libre et j'espère le voir encore progresser et intégrer de nouvelle génération de carte ainsi que la lecture de la vidéo HD. En aucun cas , je ne le discrédite par ces tests et si je l'utilise sur ma distribution principal c'est que je suis convaincu de son utilité. J'ai même choisi une ATI uniquement pour pouvoir utiliser ce pilote libre ATI , dont je salue d'ailleurs la participation d'ATI.
Toutefois ce que dit didierg n'est pas sot à savoir :
Je cherche donc à clarifier les choses en utilisant le benchmark.brain71 wrote:Bonne idée j'ai commencé à faire des test avec phoronix test suite qui fonctionne vraiment bien .Ce qui est bizarre c'est qu'un glxgears donne sur F12 1500 FPS avec le pilote libre. Avec F11 et le pilote propriétaire 65 FPS et sur F11 sans aucune mise à jour du système et toujours avec le pilote proprio 8500 FPS.. Il n'y a que le bon vieux benchmark auquel on peut ce fier on dirait.. J'ai lu aussi que le CPU était largement exploité avec glxgears.
EDIT:
Quand je lance le test nexuiz de phoronix le jeu est plus qu'au ralenti . Est ce que la version d'OpenGL utilisé peut avoir de grosse répercussion sur les performance 3D des test réalisé ?
Salut ,VINDICATORs wrote:Bon... A force de répéter cela devrait un peut rentrer...
Pourquoi plus performant sous Ubuntu que sur Fedora? parce que le pilote est testé par Ubuntu et optimisé Ubuntu!
Pour le pilote libre, actuellement on recherche le support en fonctionnalité, la performance viendra petit à petit.
Pourquoi privilégié un pilote libre par rapport à un pilote propriétaire? parce que cela est développé au rythme des avancées du noyau, serveur graphique, etc... Vu que le pilote propriétaire suit le développement de Ubuntu qui est plus en retard que Fedora, cela entraine énormément de retard dans le support. La faute à Fedora? à ATI?? en fait à ATI qui ne suit pas les versions stabilisés tant du noyau, que du serveur graphique! La faute en partie à Ubuntu qui monopolise beaucoup de choses...
Si l'on suit l'avancement du développement de Mesa/pilote graphique, cela avance très rapidement en étant presque reparti de zéro. Sans compter que c'est généralement fonctionnel plus rapidement que le pilote proprio.
Il ne faut pas croire que pilote proprio = pilote libre et que ce n'est pas normal que ce ne soit pas au niveau, le code n'est pas à l'identique et cela prend quand même pas mal de temps, même en ayant digéré les docs disponible.
Enfin bref, je te rappel qu'en 2D le pilote proprio est ridicule et souvent en vidéo...
Je crois que tu te méprends sur mes intentions. Les tests montrent si tu les as bien regardé, que justement sur une F11 avec un serveur graphique équivalent à Ubuntu la vitesse est identique ou quasi identique .
Que les pilotes soient développé pour Ubuntu et testé par eux même est une chose ,mais qu'ils fonctionnent aussi bien sur une Fedora disposant du même serveur graphique qu'Ubuntu en est une autre.
Je ne fais pas du "Pilote libre VS Pilote Proprio" , ce n'est évidemment pas le but et ce serait stupide . Je me suis simplement amusé à mesurer et à comparer la 3D sur chacun de ces deux pilotes. Je suis content du pilote libre et j'espère le voir encore progresser et intégrer de nouvelle génération de carte ainsi que la lecture de la vidéo HD. En aucun cas , je ne le discrédite par ces tests et si je l'utilise sur ma distribution principal c'est que je suis convaincu de son utilité. J'ai même choisi une ATI uniquement pour pouvoir utiliser ce pilote libre ATI , dont je salue d'ailleurs la participation d'ATI.
Toutefois ce que dit didierg n'est pas sot à savoir :
Personne ne souhaite dire de mal du pilote libre , toutefois , on peut comprendre que pour les possesseurs d'ATI en R8xx le non support de la 3D peut être embêtant voir frustrant, même s'il y a toujours des raisons valables. Ce qui est certain , et tout le monde le reconnait je crois , c'est qu'ATI a encore des progrès à faire pour contenter un maximum d'utilisateurs . On saluera toutefois la participation d'ATI en rendant disponible les documentations. Soyons optimiste , le pilote libre aura un grand rôle à jouer pour les possesseurs d'ATI sous Fedora..A lire les différentes mailing lists qui traitent du développement du driver Radeon, je suis convaincu que de nombreux problèmes viennent de la volonté d'avoir un driver unique pour toutes les générations de processeurs graphiques ce qui pose de nombreux problèmes de régression....
nVidia a de son coté fait le choix d'avoir différents drivers en fonction des générations de processeurs graphiques et cela n'a jamais posé de problème...