Reprise du message précédent :
http://www.phoronix.com/scan.php?p [...] open&num=1
Mesa VS drivers proprio

 
 
http://wiki.archlinux.org/index.ph [...] _.28KMS.29

J'imagine que ça dépend de la distribution.

Bonjour
 
Je viens de monter mon pc contenant une Ati 5770, et j'éprouve des difficultés pour avoir un affichage.
Je suis sous Archlinux, j'ai installé le groupe de paquets xorg, ainsi que les pilotes libres xf86-video-ati.
 
J'ai bien démarré hal, et lorsque je lance kdm sans avoir de fichier xorg.conf, j'ai l'écran de login avec toutes les couleurs de l'arc en ciel, et si j'entre mon pass, kde commence à se charger mais se coupe aussitôt et revient à l'écran de login.
 
Avec le xorg.conf suivant, en démarrant X j'ai les messages d'erreurs :
(EE) No devices detected.
Fatal server error:
no screens found
 
xorg :

 
J'ai cherché sur google mais rien n'a pu m'aider u__u, merci d'avance à vous.

si tu utilises les pilotes libres il faut savoir que le support *basic* (en gros 2D sans accélération, sans gestion des tty) n'apparait qu'avec les 6.12.191.
J'imagines que Arch dispose uniquement de la version « stable » des pilotes (aka les 6. 12) ce qui entraîne les problèmes que tu rencontres.
Tu as donc trois solutions :
-) compiler une version plus récente du pilote ati  
-) opter pour le pilote propriétaire fglrx ( les catalyst 10.3) sous réserve de rester sur une version de x-server 1.7 ou inférieure
-) prendre une distribution réellement plus réactive dans la pratique et pas uniquement dans l'affichage publicitaire (au hasard la version cooker de mandriva ).

Les drivers libres sont en version 6.12.4 sur arch. Rien d'autre en testing.
 
Pour les drivers proprios j'ai effectivement testé, j'arrive à avoir le kdm esthétique, mais j'ai le même probleme lorsque j'essaie de me logguer, à savoir un leger début de chargement de kde, puis retour à l'écran de login.
J'avais aussi le même message d'erreur :
(EE) No devices detected.  
Fatal server error:  
no screens found  
 
Quant à la solution de changement de distrib, je l'élimine direct

Pour moi c'est un problème de deviceID dans le xorg.conf.

Dans ce cas compile toi même une version git des pilotes ou fait un enieme rapport de bug sur le bugzilla de archlinux.
 

Il me semble que les pilotes propriétaires ne supportent pas ta version de xserver.
Tu es sur qu'il s'agit des Catalyst 10.3 ou fglrx 8.721 ?
Dans le changelog sur mandriva il ne semble pas y avoir de patch appliqué pour supporter x-server 1.7, juste un patch pour le kernel 2.6.33

c'est un choix.
(le post initial était simplement pour mettre en exergue que l'argument principal d'Arch Linux d'une *superbe réactivité* était simplement battu en brèche très très simplement, mais tu l'avais compris)

Ce n'est pas «l'argument principal», ce n'est pas un but de la distribution, la ligne directrice étant plutôt le principe KISS.

c'était de l'ironie...

http://www.archlinux.org/packages/ [...] video-ati/
La version RC est dans testing, sinon il y a un PKGBUILD pour la version git dans AUR.

Le driver libre xf86-video-ati est taggué en version 6.13.
http://cgit.freedesktop.org/xorg/d [...] o-ati/log/
 
Il sera surement bientot dispo dans nos distribs favorites

En plus de la 6.13, une version 6.12.7 est dispo en téléchargement.  
http://cgit.freedesktop.org/xorg/d [...] video-ati/

yep.
Et a priori la gestion des tty a été corrigé \o/
le temps qu'il arrive sur les mémoires je vais tester avec kms

Hello,
 
C'est moi ou bien il y a des problèmes liés au fait que DRI se dispute avec KMS en ce moment?
J'ai plus d'accélération (sur Debian Sid). J'ai vu que des gens sur le net on pris les sources sur les différents git et ont recompilé le tout à la main mais j'aimerais éviter de risquer de pourrir mon install.

 
c'est toi (ou les paquets que tu utilises).

Ce problème pourrait se poser si KMS est activé dans le noyau. Mais sous debian, je serais étonné qu'il soit activé. C'est très expérimentale.
 
Dans /boot, il y a un fichier config du noyau. Si tu fais un  
grep CONFIG_DRM_RADEON_KMS config<numero>
tu peux savoir si il est activé.

Ah bon
ça suffit pas d'utiliser ceux de unstable et de mettre modeset=1 dans grub et comme opion pour radeon dans modprobe.d ?

# CONFIG_DRM_RADEON_KMS is not set

Par contre, sauf erreur, KMS est activé par defaut sur Lenny

Je viens d'apprendre un truc: on peut forcer l'activation. Ça peut être utile pour ceux qui ont Arch et veulent le désactiver.
 
Sinon si tu veux la 3D sans bousiller ta debian, je pense que tu sais faire. Non?

Justement, à part suivre un des tutos que j'ai trouvé sur le net, qui expliquent comment récupérer les différents composants (driver radeon, lib dri, ...) et les recompiler avec support KMS, je vois pas trop non

Il te suffit simplement d'enlever la ligne radeon.modeset=1 de grub et t'as à nouveau la 3D.

Si j'enlève cette ligne, le DRI reste non activé

message d'erreur dans les log (dmseg, xorg.log) ?
 
tu as bien les firmwares adhoc, notamment celui pour prendre en charge les irq.

Dans les log de Xorg :
 

 
J'ai vu sur le site officiel qu'il faut ajouter la ligne "modeset=1", ce que j'ai fait, mais sans aucune amélioration malheureusement.

 
il y a un des éléments pas à jour. donc version du noyau, de la libdrm, du pilote DDX et de mesa

Noyau : 2.6.32-3-amd64
libdrm : 2.4.18-5
xserver-xorg-video-radeon : 6.13.0-1
libgl1-mesa-dri : 7.7.1-1
 
Merci

les versions semblent bonne. le message n'est pas inconnu :
http://www.x.org/wiki/radeonBuildH [...] MSproblems

Oui je sais, c'est que je disais plus haut.. Le problème c'est que j'ai bien fait ce qu'ils disent et ça persiste

Là t'as essayé avec modeset=1? ou rien?
 
Tu peux également faire un test avec  modeset=0 pour voir comment ça réagi.

Bon, tout le monde lit phoronix mais spagrave, le pilote gallium pour les R600 a été inclus dans la branche principale de Mesa, et la gestion des voltages est en train d'arriver pour ces mêmes cartes \o/

Et ben ça avance pas trop mal.

Quelqu'un sait-il comment activer les gestion d'énergie avec les drivers radeon et ralentir la carte, sa fréquence, sa température et donc son ventilo ?
 
Peut-on lire ces valeurs (fréquences, température) ?
 
Merci !

pour activer ça sur une R6xx/R7xx/evergreen, il te faut compiler une branche spéciale (drm-radeon-testing) du noyau, utiliser KMS et jouer avec une valeur dans sysfs (faut voir les commits, je sais plus où c'est de tête). Pour lire les valeurs, les patchs ont été postés hier ou aujourd'hui et devraient être dans ladite branche d'ici à quelques jours.

Accessoirement, je te conseille aussi d'avoir une libdrm à jour et un DDX à jour aussi.

ladite branche (elle suit les noyaux sortis et ajoutent les patchs expérimentaux du DRM radeon) :
http://git.kernel.org/?p=linux/ker [...] on-testing

J'ai pleuré en lisant ta réponse tu sais

 
Oui à part être motivé, vaut mieux attendre l'inclusion dans le noyau et distribution  

Vous savez s'il l'inclusion OpenCL est prévue ? Je crois que c'est possible via Gallium3D mais avec des performances de tetraplégiques.

Petit bench absolument non scientifique (qui corrobore tout de même les résultats d'autres personnes et répété plusieurs fois), sur l'intérêt du tiling :
 
mesa 7.8 / tiling non
840 frames 7.8 seconds 107.9 fps 3.0/9.3/38.0/3.2 ms
mesa 7.9 / tiling non
840 frames 7.7 seconds 108.8 fps 3.0/9.2/33.0/3.0 ms
mesa 7.9 / tiling oui
840 frames 6.1 seconds 138.6 fps 3.0/7.2/37.0/2.9 ms
 
 
Résultats obtenus avec openarena (http://dri.freedesktop.org/wiki/Benchmarking)

Quelques autres tests amusants (mesa 7.9, tiling activé).

Fréquences au maximum :
840 frames 6.3 seconds 133.6 fps 3.0/7.5/33.0/3.0 ms

Fréquences au minimum :
840 frames 8.6 seconds 97.1 fps 3.0/10.3/34.0/3.2 ms

Fréquences dynamiques :
840 frames 6.4 seconds 130.3 fps 3.0/7.7/49.0/3.6 ms

De quoi as t'on besoin pour reproduire les tests :

un noyau custom issu de la branche drm-radeon-testing
http://git.kernel.org/?p=linux/ker [...] on-testing

auquel généralement, il faut ajouter le patch
drm/radeon/kms: fix regressions in CS checker due to r6xx tiling changes
http://lists.freedesktop.org/archi [...] 01010.html

une libdrm à jour
http://cgit.freedesktop.org/mesa/drm

un pilote DDX à jour :
http://cgit.freedesktop.org/xorg/d [...] video-ati/

auquel il faut ajouter les patchs :
http://lists.freedesktop.org/archi [...] 00845.html
http://lists.freedesktop.org/archi [...] 00846.html

Une version de mesa à jour :
http://cgit.freedesktop.org/mesa/mesa/

à laquelle il faut ajouter :
http://lists.freedesktop.org/archi [...] 00841.html
http://lists.freedesktop.org/archi [...] 00842.html
http://lists.freedesktop.org/archi [...] 00843.html

Je vous déconseille de remplacer la version que vous avez avec celle de dev, pour l'utiliser, il est préférable de fixer les variables LIBGL_DRIVERS_PATH et LD_LIBRARY_PATH. Elles devront pointer vers le dossier qui contient les pilotes et bibliothèques, généralement, le sous dossier lib des sources de mesa.

Et pour activer le tiling, il faut ajouter l'option Colortiling on à la section device de xorg.conf (cf man radeon). Evidemment, si vous essayer de lancer un programme utilisant un mesa non patché avec le tiling activé les résultats vont être... surprenants...

EDIT : j'ai oublié de préciser que tout ça ne marche qu'avec KMS.

Petit point sur la 3D chez phoronix:
http://www.phoronix.com/scan.php?p [...] june&num=1

Quels nouvelles :
 
Le tiling sera là pour le noyau 2.6.36 pour les r6xx et plus (c'est déjà le cas pour les précédentes cartes).
le pilote gallium pour les R6xx/R7xx voit des commits tous le jours ce qui est plutôt encourageant, depuis 2 jours, il permet de faire tourner Openarena (bon, 2.5x moins vite que le pilote R600c et 6x moins que fglrx )
le pilote r300g n'est pas en reste et pas mal d'optimisation/corrections sont incluses chaque jour.
 
L'accélération 2D et 3D pour les cartes evergreen (R8xx, les 5xxx) est fonctionnelle en interne chez AMD depuis quelques jours et ça devrait arriver publiquement d'ici quelques semaines au plus.