[Ati]Pilotes open source pour radéon récentes (>9200)

[_droop_]

Introduction
Salut à tous,

J'ai rédigé ce how to dans le but d'aider les gens à utiliser les pilotes open source pour les cartes ati récentes. En effet, les pilotes ati propriétaires ont de bonnes performances en 3d. Ils comportent néanmoins des défauts :
- utilisation de la transparence
- problème lors de la mise à jour du noyau et/ou de xorg
- logiciel propriétaires : ati peut à tout moment décider d'arreter de supporter votre modèle de cartes (ce qui est le cas de certaine geforce chez nvidia). pilotes non disponibles pour toutes les architectures (ppc...).

Je possède une radéon 9550 et j'utilises ces drivers open sources depuis plus de 2 semaines... J'ai acheté cette carte à la suite d'une mort en cours de ma geforce 2 ti (l'ordinateur bloquait au boot 19 fois sur 20, ce qui est pas très pratique).

Il existe dans X.org un pilote open source pour les cartes radéon. Celui ci essaie de contourner ces difficultés. Dans les versions actuelles de X.org, celui-ci ne couvrait les cartes radéons que jusque le 9200. Dans le nouvel X.org, ce driver a été amélioré pour prendre en charge les cartes plus récentes (projet r300 : http://r300.sourceforge.net/R300.php).

Cet how-to est une compilation de plusieurs sujet de ce forum (avec adaptations) :
- The modular X server bugs, annoyances and solutions thread :http://forums.gentoo.org/viewtopic-t-37 ... r-asc.html
- HOWTO: Radeon 9600 (and newer) with DRI : http://forums.gentoo.org/viewtopic-t-37 ... -r300.html

Prérequis :
- un xorg déjà fonctionnel (çà simplifie l'étape de configuration de portage).
- connaissance : configuration, installation de noyau, portage (overlay, /etc/portage/package.*)

Avertissements
Ces pilotes sont expérimentals (voir très). Je les utilise depuis 2 semaines environ sans gros problèmes. Néanmoins, ils sont susceptibles de provoquer:
- des problèmes graphiques (lags, couleurs qui flashent...).
- des crash de X.org (segmentation fault).
- des blocages de X (reset matériel obligatoire).
- des destructions de carte graphique (ca fait peur non ? ).
En bref, ces pilotes sont expérimentales et ne couvriront peut être pas toutes vos attentes (c'est même quasiment sûr). Ils sont néanmoins utilisables... Si vous avez envie d'essayer liser la suite

Plan :
I - Introduction, Avertissements (vous venez de le lire non ?)
II - Noyau
III - Installation de Xorg 7.0.0 rc2
IV - Installation complémentaires
V - Configuration
VI - Vérification, tests
VII - Installation Pilotes CVS (optionnel et non recommandé)
VIII - Conclusion
IX - Mise à jour

[_droop_]

II - noyau

Les pilotes pour fonctionner nécessite un module dans le noyau. Le module mis à jour est présent à partir du 2.6.14. Il faut donc installer au moins un 2.6.14 pour que l'accéleration matérielle fonctionne (2.6.14 de votre choix : gentoo-sources, vanilla, ck, love...).

Voici les options à sélectionner :

Code: Select all

Device Drivers  ---> Character devices  --->
<M> /dev/agpgart (AGP Support)
<M>   VIA chipset support
<M> Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)
<M>   ATI Radeon

Il faut bien sur mettre le chipset correspondant à votre carte à la place de "VIA chipset support".
Ces drivers peuvent être mis en dur mais celà sera moins pratique pour :
- tester qu'ils sont bien utilisés (lsmod).
- eventuellement tester la version cvs.

[_droop_]

III - Installation de X.org 7.0.0 rc2

Voilà le gros morceaux. Cette version est encore "hard" masquée, Il va falloir jouer avec /etc/portage/package.use et /etc/portage/package.unmask. Cette version est modulaire : contrairement à l'ancien X.org où on installait un seul paquet qui contenait tout le nécessaire, il faut maintenant installer pleins de paquets...

Avant cela commencons par le plus simple : /etc/portage/package.use

Code: Select all

x11-base/xorg-server dri
media-libs/mesa -motif
x11-drivers/xf86-video-ati dri

Le flag "dri" sert à activer le support pour l'accèleration matérielle. Le flag "-motif" évites une erreur de compilation (problèmes d'en tête manquant, problème peut être déjà réglé...).

Pour démasquer, on va utiliser la version des paquets. Avantage : on ne sera pas toujours sur la dernière version des paquets (enfin au début si), ca permet de garder une certaine stabilité. Inconvénient : la liste de version proposée maintenant ne sera peut être plus à jour dans quelques semaines et il faudra jouer avec "equery list" pour trouver une version qui convient.

D'abord il faut désinstaller l'ancien X.org (on va en faire une archive pour pouvoir le réinstaller plus vite en cas de problèmes):

Code: Select all

quickpkg xorg-x11
emerge -aC xorg-x11

Bon, une bonne âme (UB|K pour ne pas le citer) a proposé un autre how to concernant l'installation de X : http://forums.gentoo.org/viewtopic-t-414155.html. Ca devrait le faire...

A la fin de la compilation, n'oubliez pas le "etc-update"... (et pas de -3 ou -5 )

Il faut aussi utiliser les fonctions opengl de xorg :

Code: Select all

eselect opengl set xorg-x11

[_droop_]

IV - Installations Complémentaires
Cette étape est importante surtout concernant les drivers X.org

Si vous avez suivi UB|K (à l'étape précédente et mis VIDEO_CARDS="ati" INPUT_DEVICES ce qu'il faut dans make.conf). Il n'y a plus rien à faire ici.

Je laisse quand même au cas où.

Il manque quelques trucs : des drivers pour X.org.

Pour les drivers :
- Si vous utilisez un clavier ( ) :

Code: Select all

emerge -av xf86-input-keyboard

- Si vous utilisez une souris :

Code: Select all

emerge -av xf86-input-mouse

Ou

Code: Select all

emerge -av xf86-input-evdev

(pour gérer vos 50 boutons de souris).
- Si vous utilisez une ati (c'est un peu le sujet du how to, mais bon...) :

Code: Select all

emerge -av xf86-video-ati

Voilà cà devrait suffir pour le moment.

[_droop_]

V - Configuration

On va modifier /etc/X11/xorg.conf.

Tout d'abord. Les chemins dans xorg ont changés. Par conséquent si vous avez une ligne

Code: Select all

ModulePath   "..."

. Supprimer là ou mettez "/usr/lib/xorg/modules" comme chemin.

Ensuite on va modifier votre fichier xorg.conf (je suppose que xorg fonctionnait avant) pour activer dri:

Code: Select all

Section "Module"
        ...
        Load  "glx"
        Load  "dri"
	Load  "drm"
        ...
EndSection

Pour la carte vous devriez avoir quelque chose de ce genre (remplacer les ??? par ce qui correspond) :

Code: Select all

Section "Device"
	Identifier ???
	Driver "radeon"
	Option "AGPMode" "???"
	Option "RenderAccel" "on"
	Option "EnablePageFlip" "true"
	#Option "AccelMethod" "EXA"
	# This two lines are needed to prevent fonts from being scrambled
	Option "XaaNoScanlineImageWriteRect"
	Option "XaaNoScanlineCPUToScreenColorExpandFill"
	# Misc
	BusID  "???"
	Screen ???
EndSection

C'est dans cette section que l'on peut activer EXA, la nouvelle architecture d'accéleration pour X.org. Néanmoins, ca ne semble pas stable pour le moment sur les radéons supérieurs à la 9200 (hard freeze de X (si quelqu'un veut bien traduire çà en français correct...).

Enfin, n'oubliez pas d'ajouter :

Code: Select all

Section "dri"
	Mode    0666
EndSection

Si vous voulez essayer la transparence (avec kde 3.5 par exemple), vous devez ajouter la section suivante :

Code: Select all

Section "Extensions"
       Option "Composite" "Enable"
EndSection

Encore, une fois, ça ne semble pas encore au point (c'est joli mais ça rame un peu et surtout ça plante de temps en temps (seg fault pas de hard freeze...)

[_droop_]

VI - Vérification, tests

Maintenant xorg doit démarrer... (en passant par xdm ou directement dans la console avec startx...). Si ce n'est pas le cas, il faut aller voir le fichier de log /var/log/Xorg.?.log.

En cas de symbole non résolu, on lance un revdep-rebuild qui devrait réussir à trouver ce qui ne va pas. En cas de problème de configuration, il faut corriger /etc/X11/xorg.conf (trop d'erreurs possibles pas vraiment en rapport avec ce how to).

Une fois X démarré. On vérifie que dri est utilisé avec lsmod :

Code: Select all

lsmod
Module                  Size         Used by
radeon                  103616  1
drm                        64980    2        radeon

La colonne intéressante est la colonne Used.

Ensuite, on va vérifier que OpenGL fonctionne :

Code: Select all

glxinfo | grep direct
*********************************WARN_ONCE*********************************
File r300_state.c function r300Enable line 456
TODO - double side stencil !
***************************************************************************
No ctx->FragmentProgram._Current!!
direct rendering: Yes

Donc ça marche, on remarque tout de même des avertissements... S'il y a des gens qui se sentent chaud pour faire de la programmation de driver 3d...

Voilà, c'est le moment :

Code: Select all

glxgears
*********************************WARN_ONCE*********************************
File r300_state.c function r300Enable line 456
TODO - double side stencil !
***************************************************************************
No ctx->FragmentProgram._Current!!
*********************************WARN_ONCE*********************************
File r300_render.c function r300_get_num_verts line 188
user error: Need more than 2 vertices to draw primitive QS !
***************************************************************************
4582 frames in 5.0 seconds = 916.183 FPS
4555 frames in 5.0 seconds = 910.965 FPS
4547 frames in 5.0 seconds = 909.294 FPS

Je rappelle que glxgears n'est pas un bench (il ne fait pas une utilisation très exhaustive des fonctions opengl), néanmoins c'est un bon indicateur du bon fonctionnement de l'opengl. On remarque aussi que le nombre de fps sur ma carte est quand même assez bas. N'hésitez pas à compléter avec vos résultats.

[_droop_]

VII - Installation Pilotes CVS

Il n'est pas du tout nécessaire de faire cette installation, les pilotes présent avec xorg 7.0.0 étant fonctionnelle. Néanmoins, s'il y a des gens qui ont envie d'aller encore plus loin...

Installation du module noyau :

Code: Select all

mkdir /usr/src/r300
cd /usr/src/r300
export CVSROOT=":pserver:anonymous@cvs.freedesktop.org:/cvs/dri"
cvs checkout drm
cd drm
rm -rf shared
ln -s shared-core shared
cd linux-core
DRM_MODULES="radeon" make
cp *.ko /lib/modules/{kernel_version}/kernel/drivers/char/drm
modules-update 

Installation du driver xorg :

Code: Select all

cd /usr/src/r300
export CVSROOT=":pserver:anonymous@cvs.freedesktop.org:/cvs/mesa"
cvs checkout Mesa
cd Mesa
echo 'DRM_SOURCE_PATH=/usr/src/r300/drm' >> configs/linux-dri
make linux-dri-x86  # on AMD64 this should be: make linux-dri-x86-64
cp -a lib/r300_dri.so /usr/lib/modules/dri/       # on xorg-x11
cp -a lib/r300_dri.so /usr/lib/xorg/modules/dri/  # on xorg-server
mkdir -p /usr/lib/opengl/mesa-cvs
ln -s /usr/src/r300/Mesa/lib /usr/lib/opengl/mesa-cvs/lib
ln -s /usr/src/r300/Mesa/include /usr/lib/opengl/mesa-cvs/include
eselect opengl set mesa-cvs

[_droop_]

VIII - Conclusion

Après 2 semaines (peut être 3) d'utilisation de ces drivers, ils me semblent bien prometteurs. L'accélération 2d est bien présente (avec entre l'overlay (pratique pour les vidéos). L'acceleration 3d fonctionne aussi, les performances affichés par glxgears sont assez modestes (moins de fps qu'avec le driver proprio), néanmoins ceratains jeux (j'en ai pas testé beaucoup en fait) sont utilisables sans gros problèmes : neverwinter nights, quake3... Pour la transparence, je n'ai pas vraiment testé mais sans EXA, les performances risquent d'être un peu faibles...

Bon, il y a quand même des bugs :
- impossible de lire 2 vidéos en même temps -> seg fault de X systématique (après plusieurs secondes, possibilités d'arrêter le massacre).

Il y aussi quelques problèmes mineurs :
- l'eau dans nwn n'est pas rendu correctement.
- quand on lance un lecteur vidéo, la première image affichée vient souvent d'un autre programme, ca peut surprendre. (exemple : je visite plein de sites avec firefox, je lance xine qui m'affiche un morceau de page que j'ai vu y a 10 minutes. conclusion eviter les sites pervers avant de montrer des vidéos à vos soeurs (non, ca n'est pas arrivé )).

note : je n'ai mis que ce que dont je me rappelle, je compte compléter cette page peu à peu.

[_droop_]

IX - Mise à jour
15/01/2006 : ajout d'une note sur composite, ajout d'une note sur glxgears.

[spider312]

Waou, chapeau, je n'ai aps encore eu le temps de lire tout ça en détail, mais ça a l'air d'être du beau boulot

Par contre, une petite remarque, ce serait pas mieux de mettre ça sur le wiki de gentoo plutôt que sur le forum ? Niveau mise en page, c'est quand même plus simple, et au moins ce serait un peu plus "participatif"

[_droop_]

Merci pour le commentaire...

Comme tu as pu le constater, je n'ai pas tout à fait fini (Le très gros est fait, mais il doit manquer des commentaires et surtout de la relecture). Je vais me forcer à le faire avant la fin de la semaine, pour le wiki, je regarderais demain comment ça marche...

Bon je me sauve...

Bonne soirée.

[_droop_]

J'ai modifié la partie concernant l'installation de X. Il faut se reporter au sujet de UB|K (merci à lui) : celà evitera de faire la même chose en double...

[dapsaille]

Bravo Droop et merci ca fonctionnes pour moi (tout du moins la 2d pas encore testé la 3d)

[anigel]

Très beau travail _droop_ ! Merci pour tes efforts !

[El_Goretto]

En voilà une initiative qu'elle est bonne.
J'avais déjà regardé de ce côté là, mais la mention "peut détruire votre matériel", et les pépins inexpliqués avec les 9800 pro m'ont découragé.

Juste, je serais d'avis de rendre encore plus évident l'avertissement, parce que c'est pas rien (et que "peut détruire votre matos" est un peu caché dans un "peut bugger" dont tu avoueras que peu d'entre nous tiennent compte )

[dapsaille]

Peut détruire votre matériel me parrait un peu forcé non ?? :p


Des exemples ? des liens ? des morts? :p

[_droop_]

Peut détruire votre matériel me parrait un peu forcé non ?? :p

C'est sûr...

Un exemple : sur la plupart des cartes moderne tu peux faire varier la frequence à chaud avec des programmes spéciaux (Je ne parle pas des drivers de X qui ne doivent pas faire celà). Maintenant imagines que le driver mal codé envoie l'ordre fréquence trop élevée...

Enfin, ca a pas du arriver souvent...

[kwenspc]

Des exemples ? des liens ? des morts? :p

un exemple parfait du voyeurisme ambiant de notre société

enfin, moi aussi en fait ça m'interesserais de savoir ce que peuvent causer comme dégats exactement ces drivers...ça m'étonne un peu.

[El_Goretto]

The source code on this website may damage your hardware.
It is *UNTESTED* and *BROKEN* !

Fait: il est impossible de passer du driver radeon à fglrx sans rebooter (ou vice versa).
Hypothèse: les drivers imposent des modifications à la cartes (registres? firmware?) qu'ils ne sont pas tous en état de détecter ou de correctement gérer.
Rien qu'en parlant du firmware/BIOS de la CG, il est possible de la saboter, alors si je prends en compte tous ce que je ne connais pas sur ma 9800 et/ou qui n'est pas documenté...

[_droop_]

The source code on this website may damage your hardware.
It is *UNTESTED* and *BROKEN* !

Fait: il est impossible de passer du driver radeon à fglrx sans rebooter (ou vice versa).
Hypothèse: les drivers imposent des modifications à la cartes (registres? firmware?) qu'ils ne sont pas tous en état de détecter ou de correctement gérer.
Rien qu'en parlant du firmware/BIOS de la CG, il est possible de la saboter, alors si je prends en compte tous ce que je ne connais pas sur ma 9800 et/ou qui n'est pas documenté...

Merci pour la précision intéressante.

Si j'ai mis mon avertissement c'est bien à cause de ce message sur r300.sf.net...

Vous avez pas vu récemment (sur le forum) cette histoire de carte réseau qui ne marchait plus sous windows après avoir été utilisée sous gentoo ? Elle nécessitait de débrancher la prise de l'ordinateur pour refonctionner correctement sous windows...

Bon sinon, sur les mailings lists r300, j'ai pas trouvé de trace de déstruction de cartes...

Bonne journée.

[_droop_]

En activant une petite option dans le noyau :

Code: Select all

Processor type and features  --->
[*] Use register arguments (EXPERIMENTAL)

Il y a moyen de gagner ~5% de fps dans glxgears

(940 fps maintenant).

[_droop_]

note : Pour VIDEO_CARDS (dans make.conf), il faut maintenant mettre "radeon" et non "ati".

Les ati ont été séparées : radeon, mach64 et r128.

[synss]

Alternative : ne pas utiliser le module du kernel:

Code: Select all

< > Direct Rendering Manager

mais

Code: Select all

USE="radeon" ACCEPT_KEYWORDS="~x86" emerge x11-base/x11-drm

j'ai mis a jour le wiki en anglais la dessus http://gentoo-wiki.com/HOWTO_DRI_with_A ... ce_Drivers

Et il serait bienvenu de traduire tout cela en francais ! (je sais, je sais, je pourrais le faire )

[EDIT] Laptop 1.6GHz, Radeon Mobility 9700, 128MB, glxgears done ~1633 FPS ce qui n'est pas si mal, environ 100FPS dans supertux, tres jouable (mais maintenant, je joue a fish-fillets)

[SuperDindon]

Un petit up pour annoncer que les Radeon 9800 ne crashent plus depuis une semaine, le correctif est dans l'arbre git de xf86-video-ati.
Le driver pour r3xx/r4xx a globalement beaucoup progressé : fp/vp, brouillard, correctifs en tout genre, plus de détails ici : http://megahurts.dk/rune/r300_status.html et ici : http://sourceforge.net/mailarchive/foru ... m_id=33172 . Pour ceux qui veulent tester il vous faut Xorg et le paquet x11-drm en ~arch ( celle du noyau 2.6.17 est un peu vieille ), et les versions actuelles de Mesa et xf86-video-ati ( CVS et git ).

Bon moi je ne pourrais malheureusement pas en profiter, ayant sacrifié mes 2 9800 Pro pour aider les devs ( nb : rien à voir le driver cependant )