Alors... pour les 1300 etc... de FPS (même sur une HD4850 c'est à peine mieux...) avec glxgear, faut pas trop y faire attention, ni confiance, actuellement le pilote est surtout en cours de stabilisation et d'ajout de fonctionnalités avant la recherche de performance (qui devrait décoller d'ici peut). Donc à ce moment là tout était bon.

Par contre d'être passé à 0.8...FPS... là c'est un problème. Avec effets ou non?

Avez vous aussi testé avec l'astuce au sujet de récupérer certains paquets de koji? parce qu'en plus il semble qu'il y est des problèmes avec ceux dans updates/updates-testing et la dernière mise à jour du noyau...

Comme le serveur de koji était un peut dans les choux ce week end, vous pouvez de nouveau vous servir de l'astuce de la doc pour avoir plus de stabilité graphique.

Pour l'AGP il ne devrait pas y avoir ce genre de problème, ayant eu un rapport de quelqu'un ayant une 9700pro fonctionnel. Après il se peut que ce "riatlo" (si je me souviens bien...) posent des problèmes (pour changer), je regarde si ce genre de problème est rapporté sur le bugzilla -> https://bugs.freedesktop.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=xorg&component=Driver/Radeon

Merci de me dire ce que rapporte ceci :
cat /proc/pci | grep VGA || lspci | grep VGA | colrm 1 4 ; cat /proc/cpuinfo | egrep "model name|MHz" ; xdpyinfo | egrep "version:|dimensions|depth of" ; glxinfo | egrep -A2 "direct rendering|OpenGL vendor" ; uname -sr;
En dehors de /proc/pci que je dois corriger, cela devrait vous donnez ce genre de résultat :
cat: /proc/pci: Aucun fichier ou dossier de ce type
0.0 VGA compatible controller: ATI Technologies Inc RV770 [Radeon HD 4850]
model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 4600+
cpu MHz         : 1000.000
model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 4600+
cpu MHz         : 1000.000
  dimensions:    2560x1024 pixels (677x270 millimeters)
  depth of root window:    24 planes
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
--
OpenGL vendor string: Advanced Micro Devices, Inc.
OpenGL renderer string: Mesa DRI R600 (RV770 9442) 20090101  TCL DRI2
OpenGL version string: 1.5 Mesa 7.7-devel
Linux 2.6.31.6-166.fc12.x86_64
Bonjour.

Tout d'abord, merci VINDICATORs pour ta réponse rapide.

Qu'entends-tu par "avec effets ou non" ? Si c'est de compiz dont tu parles, je ne sais pas exactement ce dont il s'agit, mais si j'ai bien compris, c'est des effets 3D sur le bureau. Moi, je suis plutôt style "vieux de la vieille", et je me contente du thème le plus simple possible : Mist. Je sais que ça ne veut pas dire forcément que compiz n'est pas activé - d'ailleurs, je viens de vérifier : des paquetages comportant le nom de "compiz" sont installées sur la machine. Une fois de plus, cela ne veut pas dire forcément qu'il est activé. Donc : Je sais ça comment, si il y a des effets ou non ?

Je ne me souviens pas avoir vu une histoire de paquets de "koji". Je suis allé voir la documentation sur l'installation des pilotes libres, et je ne vois pas de "koji" non plus. De quoi s'agit-il ?

Si il n'y a pas de problèmes spécifique avec l'AGP, alors je vais essayer la migration FC11->FC12 sur mes deux autres machines (mais pas tout de suite sur le serveur)... Il y aura un retour d'expérience sur une HD3650 et une Mobility 9700 d'ici quelques heures 🙂

Je suis allé voir sur freedesktop - aucun bug ne semble correspondre : les bugs glxgears sont des hangs, pas des problèmes de performance. Le seul problème de performance noté ne semble pas correspondre, mais sa lecture m'a quand même donné l'idée de faire ceci :
<jm@xaleia:tmp> grep -i Accel /var/log/Xorg.0.log
(II) RADEON(0): Render acceleration enabled for R300/R400/R500 type cards.
(II)         Composite (RENDER acceleration)
(II) RADEON(0): Acceleration enabled
(**) Macintosh mouse button emulation: (accel) keeping acceleration scheme 1
(**) Macintosh mouse button emulation: (accel) acceleration profile 0
(**) Logitech USB-PS/2 Optical Mouse: (accel) keeping acceleration scheme 1
(**) Logitech USB-PS/2 Optical Mouse: (accel) acceleration profile 0
<jm@xaleia:tmp>
... donc l'accélération graphique semble bien activée.

Sinon, pour la commande en question :
<root@xaleia:~> cat /proc/pci | grep VGA || lspci | grep VGA | colrm 1 4 ; cat /proc/cpuinfo | egrep "model name|MHz" ; xdpyinfo | egrep "version:|dimensions|depth of" ; glxinfo | egrep -A2 "direct rendering|OpenGL vendor" ; uname -sr;
cat: /proc/pci: Aucun fichier ou dossier de ce type
0.0 VGA compatible controller: ATI Technologies Inc RV570 [Radeon X1950 Pro] (rev 9a)
model name    : AMD Engineering Sample 00
cpu MHz        : 2411.834
X.Org version: 1.7.1
  dimensions:    1680x1050 pixels (444x277 millimeters)
  depth of root window:    24 planes
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
--
OpenGL vendor string: DRI R300 Project
OpenGL renderer string: Mesa DRI R300 (RV560 7280) 20090101  TCL DRI2
OpenGL version string: 1.5 Mesa 7.7-devel
Linux 2.6.31.6-166.fc12.x86_64
<root@xaleia:~>
J'ai le même problème sur /proc/pci.

Ceci dit, je ne vois rien de choquant dans ce retour... Il ressemble beaucoup au résultat donné en exemple.

Quelque chose de remarquable qui pourrait donner une piste ?

Merci d'avance,
Merci pour l'information. J'étais passé par dessus cette suggestion, d'une part car elle était taggée expérimentale, et d'autre part parce que je ne voyais pas mon problème comme un problème graphique, mais comme un problème de performance. Mais c'est vrai qu'à ce niveau de désastre là, c'est plus juste de la perf...

J'ai donc téléchargé les modules suivants :
<root@xaleia:~> ls /home/jm/tmp/fedora-fr/
glx-utils-7.6-0.18.fc12.x86_64.rpm
mesa-debuginfo-7.6-0.18.fc12.x86_64.rpm
mesa-demos-7.6-0.18.fc12.x86_64.rpm
mesa-dri-drivers-7.6-0.18.fc12.x86_64.rpm
mesa-dri-drivers-experimental-7.6-0.18.fc12.x86_64.rpm
mesa-libGL-7.6-0.18.fc12.x86_64.rpm
mesa-libGL-devel-7.6-0.18.fc12.x86_64.rpm
mesa-libGLU-7.6-0.18.fc12.x86_64.rpm
mesa-libGLU-devel-7.6-0.18.fc12.x86_64.rpm
mesa-libOSMesa-7.6-0.18.fc12.x86_64.rpm
mesa-libOSMesa-devel-7.6-0.18.fc12.x86_64.rpm
xorg-x11-drv-ati-6.13.0-0.15.20091127gita8dbf7c23.fc12.x86_64.rpm
xorg-x11-drv-ati-debuginfo-6.13.0-0.15.20091127gita8dbf7c23.fc12.x86_64.rpm
<root@xaleia:~>
Et j'ai lancé la commande suivante :
<root@xaleia:~> yum --nogpgcheck localupdate mesa* glx* xorg-x11-drv-ati*
(J'ai ajouté un --nogpgcheck et quelques '*' dans la ligne donnée en instructions pour que cela fonctionne sans problème. J'espère que ça n'en a pas causé plus que ce que ça en aura résolu...)

Je reboote.

Je lance glxgears :
<jm@xaleia:~> glxgears
91 frames in 6.1 seconds = 14.937 FPS
62 frames in 6.0 seconds = 10.297 FPS
65 frames in 6.0 seconds = 10.797 FPS
33 frames in 6.0 seconds =  5.495 FPS
53 frames in 6.0 seconds =  8.791 FPS
56 frames in 6.3 seconds =  8.891 FPS
99 frames in 6.0 seconds = 16.408 FPS
105 frames in 6.0 seconds = 17.406 FPS
109 frames in 6.0 seconds = 18.031 FPS
55 frames in 6.0 seconds =  9.143 FPS
27 frames in 6.0 seconds =  4.498 FPS
30 frames in 6.0 seconds =  4.994 FPS
^C
<jm@xaleia:~>
Il y a effectivement une amélioration. Mais d'une part, elle est assez faible, surtout pour une 1950 Pro, et ensuite le framerate est tout sauf stable (rapport x4 entre le min et le max...).
En 2D, j'ai toujours le même problème de scrolling sur Firefox...

Une question : comment se fait-il qu'il faille faire un update "local" des paquetages ? ceux-là sont plus récents ?

Ah si, autre info qui peut être pertinente : que ce soit sous glxgears ou sous Firefox quand je scrolle, j'ai la souris qui se bloque (temporairement, évidemment)...
Parce qu'ils sont sur ton disque et pas sur un repo.

Fait un "yum remove mesa-drivers-experimental" il ne sert à rien.

Tu devrais être dans les 1500 à 2000FPS, je me demande si le problème n'est pas ailleurs...

Regarde avec top si tu n'a pas un processus qui te mange tout...


Le problème de scroling peut être dut aussi à flashplayer et à la balise <video>, de plus je conseil de désactiver le défilement doux.
> Parce qu'ils sont sur ton disque et pas sur un repo.
Euh, oui, certes. Ma question était en fait : pourquoi ne sont-ils pas sur le repo ? Est-ce qu'ils sont trop récents ? Packagés par quelqu'un qui n'a pas autorité pour le faire ?
Est-ce que je peux par la suite faire des "yum update" normalement sans qu'il n'écrase les paquets que je viens d'installer ?

Pour les drivers expérimentaux, je ne les avais pas mis. J'ai quand même vérifié :
<root@xaleia:~> yum remove mesa-dri-drivers-experimental
Modules complémentaires chargés : presto, refresh-packagekit
Configuration du processus de suppression
Aucune correspondance pour l'argument : mesa-dri-drivers-experimental
Paquet(s) mesa-dri-drivers-experimental disponible(s), mais non installé(s).
Aucun paquet marqué pour suppression
<root@xaleia:~>
Je n'ai pas de processus qui phagocyte le CPU (vérifié sous top) - Dans tous les cas, j'ai toujours un moniteur système qui tourne dans mon tableau de bord inférieur pour être averti de ce genre de problèmes.

En 2D, pour Firefox, effectivement, le problème venait du défilement doux qui avait été réactivé à l'insu de mon plein gré :-x C'est pourtant un des premiers trucs que je désactive, mais les paramètres n'ont visiblement pas tous suivi la migration FC11->FC12. Merci beaucoup pour l'idée ! :-D
Re-bonjour

Comme promis, premier retour d'expérience sur mes autres installations de la FC12:
Config : AMD Athlon XP 3200+ / nForce 2 Ultra 400 / Radeon HD3650 sur AGP

Avant mesa-dri-drivers-experimental : ~50 FPS
Après mesa-dri-drivers-experimental : ~1560 FPS

Au moins, le fiston me forcera pas à rebooter sous Windaube pour jouer à ses jeux...

Allez, j'upgrade la machine suivante... Y'a rien de mieux à faire les jours de neige sur la campagne toulousaine...:-?
Koji est le logiciel qui construit les paquets pour Fedora. Pour télécharger le code source, signaler les bogues etc...

C'est souvent plus en avance que les paquets disponibles dans updates-testing/rawhide.

Pour l'histoire du défilement doux cela à l'air d'être un problème récupéré des codes apportés par ATI, car c'est le même type de bogue que le pilote propriétaire... Mais comme je l'ai déjà dit tout cela est encore en plein développement...
Re-bonjour

Second retour d'expérience sur mes installations de la FC12:
Config : Pentium M 765 (2.1 GHz) / Intel 855PM + ICH4-M / Mobility Radeon 9700 (M10)

Avant l'installation de la FC12 : ~700 FPS
Après l'installation de la FC12 : ~750 FPS

En gros : pas de soucis. Tout s'installe out-of-the-box. Une petite amélioration, pas forcément notable, des performances mais au moins : ça fonctionne. On ne peut pas vraiment en attendre plus d'un chipset pour portable qui a plus de 5 ans d'âge. Ça permet déjà de jouer à Diablo II et à Neverwinter Nights, c'est amplement suffisant 🙂
Pour informations, on parle de l'arrivé des Blitters dans Gallium3D pour R300 http://translate.google.fr/translate?u=http%3A%2F%2Fold.nabble.com%2Fgallium%253A-add-blitter-td26770907.html&sl=en&tl=fr&hl=&ie=UTF-8 pour une traduction approximative, http://old.nabble.com/gallium%3A-add-blitter-td26770907.html texte original...

http://fr.wikipedia.org/wiki/Blitter

A force ils vont nous faire aller sur mars avant la NASA bouarf...:pint::pint::pint::pint:

A mon avis les histoires d'accélérer le défilement/affichage des pages internet avec Direct2D, donc par le GPU, pour les navigateurs ne sont pas étrangères à cette apport...
Allez, juste pour rigoler :

Troisième retour d'expérience sur mes installations de la FC12:
Config : Athlon XP 1800+ / VIA KLE133 / 3D Rage II+ 215GTB (en PCI, et pas Express évidemment...)
glxgears : ~30 FPS (pilote = mach64, mais je ne pense pas qu'il gère beaucoup d'accélération 3D...)
Ben là, je suis content du résultat, même ridicule :lol: Bon, c'est la machine d'une association que j'héberge, c'est tout...

Bon, plus sérieusement, pour revenir à mon problème de X1950 Pro AGP à 10 FPS, étant donné que la souris bloque presque (0.5 déplacements seconde max), je me demande s'il ne s'agit pas d'un problème d'IT attendue et non reçue de la part de la carte ou du contrôleur AGP, étant donné que ça me freeze tout le système pendant quelques bons laps de temps... Et quand le timeout pète, ben... le système reprendrait la main quelques fractions de secondes, le temps de traiter les IT en attente. Ou alors un verrou logiciel interbloqué, et idem timeout.

Est-ce que ce genre de chose évoque quelque chose à quelqu'un ?

Je jette un œil à mon /var/log/messages ce soir, histoire de voir si il y aurait des traces dans le noyau pour corroborer cette hypothèse...
Oui, par moment ça le fait ici aussi, mais c'est juste de temps à autres... je vais voir si avec le dernier noyau sur koji c'est toujours le cas.

Il y a aussi une mise à jour de xorg-x11-server qui résout les bogues avec le clavier, comme cela il ne se met plus à délirer en maintenant aléatoirement des touches enfoncées...

Ne me demandez pas quand est ce que cela sera inclus dans le dépôt updates! Mouha y en a pas savoir!
igx31 wrote:Re-bonjour

Comme promis, premier retour d'expérience sur mes autres installations de la FC12:
Config : AMD Athlon XP 3200+ / nForce 2 Ultra 400 / Radeon HD3650 sur AGP

Avant mesa-dri-drivers-experimental : ~50 FPS
Après mesa-dri-drivers-experimental : ~1560 FPS
C'est avec glxgears que tu a fait ton teste ?
Avec ma carte je fais ~1214 FPS avec compiz, soi ma carte est pas si mauvaise que sa 8-), soi c'est les pilotes qui sont pas/peut optimisé.
Le pilote n'est pas optimisé pour les différentes cartes, il plafonne pour le moment! Ce qui vas changer au fur et à mesure des apports et optimisations future...

Actuellement je cherche la solution pour l'histoire des résolutions.

J'ai trouvé une méthode qui devrait aller, maintenant... à voir si c'est fonctionnel chez tout le monde.

Doc mise à jour, n'hésitez pas à faire des critiques pour l'améliorer. http://doc.fedora-fr.org/wiki/Carte_graphique_ATI_:_Probl%C3%A8mes_et_solutions_des_pilotes_libre#Toutes_versions

Il y a moyen de forcer une résolution même si votre écran ne le supporte pas en natif, mais je le déconseille! généralement les bon modeline étant indiqué par
 cat /var/log/Xorg.0.log | grep Modeline
C'est pour éviter des risques que je ne mettrais pas la méthode! Car cela risque d'endommager votre matériel!
Bon...

Pas de traces de nouveaux messages dans /var/log/messages quand je lance le fatidique glxgears qui rame. Pas plus dans /var/log/Xorg.0.log.

Bon, sinon, j'ai quand même fait un downgrade sur les paquets de koji : j'avais des crashes du kernel et des soucis sur le desktop.

Ah oui, aussi : j'ai essayé le pilote radeonhd, à tout hasard : 200 FPS mais freeze de X environ 0.5 secondes tous les 15 secondes (même sans 3D). C'était pénible. Je vais attendre patiemment quelques releases du pilote radeon que ce bug soit résolu... Pour l'instant : 2D only. Le gamin rebootera sous Windaube pour jouer à ses jeux quand il sera sur cette machine. Na.

@ben51 : Yep, c'est sous glxgears. Tout le monde sait que "glxgears n'est pas un test", mais quand il renvoie 0.8 au lieu de 2000, on se dit que y'a de l'eau dans le gaz, quand même...
Juste un petit retour d'expérience, après avoir installé mesa-dri-drivers-experimental tout fonctionne nickel, 3D, Compiz, Cairo-dock ...

Aucun bruit de ventilateur avec une HD 4870.
Au passage la 1950 c'était quand même du haut de gamme, donc vouloir la brider avec un convertisseur et un bus agp...

Enfin bref... cela fait un mauvais équilibre.

Sinon si quelqu'un sait comme fixer un nouveau mode avec xrandr, il est le bienvenu!
Bonjour,

Avez-vous des nouvelles au sujet du "kmod-catalyst"...
Normalement aujourd'hui officiellement si fonctionnel, il arrivera plus tard pour Fedora! Et pour Fedora 12 si il est compatible.

Pour information, le support audio HDMI arrive dans le noyau 2.6.33, à voir si Fedora l'apportera directement (le support, pas le noyau!)...
le noyau 2.6.32 est il prévu pour Fedora 12 avant de parler du 33?