• [supprimé]

  • Modifié
information : ce tuto a été initiallement créé sous F15 / Mesa 7.11 mais il est toujours d'actualité pour F16/17 avec Mesa 8/9.
Une version plus récente (Fedora 20+) de ce tuto est disponible ici : http://forums.fedora-fr.org/viewtopic.php?pid=532589



Je suis en train de tester le pilote r600g sur mon système (RV770 - HD4850), notamment pour tester les dernières nouveautés (S3TC en particulier) avec Enemy Territory: QUAKE Wars.
Et donc je me suis dis que j'allais faire un petit tuto pour que n'importe qui puisse le faire également, sachant que c'est très simple mais que parfois ça peut faire peur de compiler... et surtout de foutre le bordel dans son système.

Que va-t-on faire ici ?
- Compilation du pilote r600g sur la version de développement de Mesa (http://cgit.freedesktop.org/mesa/mesa/)
- Compilation du module S3TC 1.0.0 (http://cgit.freedesktop.org/~mareko/libtxc_dxtn/) : optionnel car la lib est déjà packagée dans RPM Fusion.
- Le tuto ne touchera pas aux libs du système de Fedora, donc pour n'importe qu'elle application vous pourrez soit utiliser le pilote de Fedora ou bien celui que nous allons compiler ici.
- Système 32 bits ou 64 bits. Sur un système 64 bits il faudra en fait compiler une version 32 bits de r600g car ETQW est 32 bits.

Bien sûr vous pouvez adapter à r300g.

ÉTAPE 1
*******
Récupérer tout le nécessaire pour compiler (commande valable pour 32 et 64 bits) :
# yum install gcc automake autoconf make makedepend gcc-c++ glibc-devel.i686 glibc-devel.x86_64 libX11-devel.i686 libdrm-devel.i686 libXfixes-devel.i686
# yum install expat-devel.i686 libudev-devel.i686 libXt-devel.i686 libXi-devel.i686 libXmu-devel.i686 udis86-devel.i686 libXdamage-devel.i686
# yum install libtool libxcb-devel.i686 libxcb.i686 libXxf86vm.i686 libXxf86vm-devel.i686 flex bison git libXext-devel.i686
Remarque : depuis quelques semaines Mesa nécessite une version de libdrm 2.4.39+. Sur Fedora 17, vous pouvez l'installer depuis le dépôt updates-testing.

ÉTAPE 2
*******
1. Récupérer la version de développement de Mesa :
$ git clone git://anongit.freedesktop.org/mesa/mesa
Note : lorsque vous voudrez récupérer les Màj du git de Mesa, il vous suffira d'aller dans le dossier "mesa" et de faire un "git pull" :
$ cd mesa
$ git pull
2. Installer la libtxc_dxtn (S3TC) depuis RPM Fusion (recommandé) :
# yum install libtxc_dxtn.i686 libtxc_dxtn.x86_64
Ça installera la version 32 et 64 bits de la lib.

3. Récupérer la libtxc_dxtn (S3TC) si vous voulez la compiler (non recommandé) :
$ urlgrabber http://cgit.freedesktop.org/~mareko/libtxc_dxtn/snapshot/libtxc_dxtn-1.0.0.tar.gz
Décompresser libtxc_dxtn-1.0.0.tar.gz

ÉTAPE 3
*******
Allons donc compiler Mesa, placez-vous dans le répertoire mesa :
$ cd mesa
Préparer la compilation (Mesa 32 bits sur un système 64 bits) :
$ ./autogen.sh --with-gallium-drivers=r600 --with-dri-drivers= --enable-32-bit CFLAGS="-O2 -m32" CXXFLAGS="-O2 -m32" --libdir=/usr/lib
Ou (Mesa 32 bits sur un système 32 bits) :
$ ./autogen.sh --with-gallium-drivers=r600 --with-dri-drivers= CFLAGS="-O2" CXXFLAGS="-O2"
puis on compile (pour tous) :
$ make -j2
et enfin pour installer les libs :
# make install
Avertissement : désormais les libs sont installées dans /usr/local/lib pour les système 32 bits. Par contre pour les systèmes 64 bits, c'est dans /usr/lib. Cela signifie donc que les libs 32 bits de Fedora seront écrasées par les votre. En revanche les libs 64 bits de Fedora ne sont pas touchées.
Et le pilote r600g dans /usr/local/lib/dri (pour système 32 bits) ou /usr/lib/dri (pour système 64 bits).

Note :
Avant de recompiler il vaut mieux effectuer un "make clean" et relancer l'autogen.sh

Note 2 :
Si vous voulez voir toutes les options disponibles pour la compilation (compiler un autre driver, activer certaines fonctions, etc.) :
$ ./autogen.sh --help
[h]
ÉTAPE 4 (sautez cette étape si vous avez installé le paquet de RPM Fusion)[/h]
*******
Compiler S3TC :
$ cd libtxc_dxtn-1.0.0
Nous allons modifier un peu le Makefile avant de compiler :
- vous pouvez adapter CFLAGS et OPT_CFLAGS selon vos désirs
- modifier les 2 dernières lignes pour installer la lib dans /usr/local/lib au lieu de /usr/lib par défaut
Compilation & installation :
$ make
# make install
Désormais vous avez la libtxc_dxtn.so dans /usr/local/lib


ÉTAPE 5 - VÉRIFICATION
*******
Cette étape de vérification n'est pas possible sur 64 bits. Il vous faudrait une glxinfo 32 bits pour ça.

Si vous lancez :
$ glxinfo |grep "OpenGL version string"
vous devriez voir la version de lib de Fedora.

Maintenant si vous voulez tester le pilote fraichement compilé, il faut passer une variable d'environnement. Personnellement je préfère le faire à chaque fois donc comme ceci :
$ LD_LIBRARY_PATH="/usr/local/lib" LIBGL_DRIVERS_PATH="/usr/local/lib/dri" glxinfo |grep "OpenGL version string"
Le passage qui suit n'est plus d'actualité si vous avez un noyau 2.6.39 ou supérieur :
En revanche si vous faites un :
$ glewinfo | grep s3tc
vous devriez avoir malheureusement "GL_EXT_texture_compression_s3tc: MISSING"
En fait, d'après le patch apportant S3TC pour r600g (http://cgit.freedesktop.org/mesa/mesa/commit/?id=8e0437914bb786d0b05be8f95e4ff37bf5a19f44) je cite : "Still requires R600_ENABLE_S3TC until the kernel fixes are in."
Donc avec :
$ R600_ENABLE_S3TC=1 LD_LIBRARY_PATH="/usr/local/lib" LIBGL_DRIVERS_PATH="/usr/local/lib/dri" glewinfo | grep s3tc
nous obtenons bien "GL_EXT_texture_compression_s3tc: OK"


ÉTAPE 6 - TEST
*******
Pour lancer ETQW avec le Mesa fraîchement compilé :
$ LD_LIBRARY_PATH="/usr/lib" LIBGL_DRIVERS_PATH="/usr/lib/dri" vblank_mode=0 /usr/local/games/etqw/etqw
Noter le "vblank_mode=0" qui sert à désactiver le Vsync.

En revanche ETQW ne fonctionne pas.
$ R600_ENABLE_S3TC=1 LD_LIBRARY_PATH="/usr/local/lib" LIBGL_DRIVERS_PATH="/usr/local/lib/dri" /usr/local/games/etqw/etqw
Si S3TC n'est pas présent j'ai bien le menu du jeu qui est fonctionnel mais le jeu ne peut pas se lancer. Si j'active S3TC j'ai la planète en fond de menu qui apparait plutôt correctement mais aucun menu...


edit : Le kernel 2.6.39 supporte les textures S3TC pour r600g, donc à partir de ce kernel il n'est plus nécessaire d'indiquer R600_ENABLE_S3TC=1

[h]
CONCLUSION[/h]
*******
C'est très simple de tester les dernières versions de Mesa, même quand on n'y connaît rien en compilation ou quoi que ce soit. Et ce sans toucher au système.
ETQW ne marche pas encore avec r600g, mais il y a des progrès indéniables de semaines en semaines.

edit: suite aux dernières mises à jours, ETQW fonctionne à peu près correctement maintenant. Plus d'informations dans la suite du fil.
edit2: suite aux dernières mises à jours (bis), ETQW ne fonctionne plus du tout. Peut-être une nouvelle fonctionnalité qui a été ajoutée, que donc ETQW utilise mais qui ne marche pas correctement ?
edit3: je suis désormais avec un etqw qui fonctionne sans corruption graphique, à 20 fps de moyenne en 1680*1050 et détails sur faible. Et 12 fps en détail élevé.
edit4 (août 2012) : je suis désormais avec un etqw qui fonctionne sans corruption graphique, à 40 fps de moyenne en 1680*1050 et détails sur faible.


ANNEXE (Si vous modifiez du code)
*******
Si vous voulez soumettre un patch, une commande très simple permet de générer le patch à envoyer à la mailing-list mesa-dev :
$ git diff > le_nom_de_mon_amelioration.patch
Si vous avez effectué des changements dans le code et que vous faites un git pull ultérieurement pour récupérer les dernières modifs, git risque de gueuler. Pour supprimer toutes vos modifications et revenir avec la base upstream :
$ git stash
Le patch pour S3TC sera intégré dans la version final de fedora 15 ?
  • [supprimé]

Non je ne crois pas.
Mais je ne sais pas bien de quand date le paquet mesa de F15. Il indique Mesa 7.10-devel, mais c'est vague... d'autant que Mesa 7.10 est en version finale depuis quelques temps déjà.
S3TC c'est bien dans mesa 7.11, cela devrait arriver sous peut sur koji pour la branche de Fedora 16.

la 7.10-devel intègre des patchs en plus, c'est une version intermédiaire avec la 7.11.

Sachant qu'en dehors des ajouts, actuellement c'est la stabilisation et des optimisations de performances qui sont inclus dans la 7.10 pour Fedora 15.

Pour info que te retourne la commande suivante :
cat /proc/bus/pci/devices | 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;
Sinon pour info : http://koji.fedoraproject.org/koji/packageinfo?packageID=184
  • [supprimé]

  • Modifié
Merci pour ces précisions VINDICATORs.
0.0 VGA compatible controller: ATI Technologies Inc RV770 [Radeon HD 4850]
model name    : Genuine Intel(R) CPU            2160  @ 1.80GHz
cpu MHz        : 1800.000
model name    : Genuine Intel(R) CPU            2160  @ 1.80GHz
cpu MHz        : 1800.000
  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: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RV770
OpenGL version string: 2.1 Mesa 7.11-devel
Linux 2.6.38-0.rc8.git0.1.fc15.i686
  • [supprimé]

  • Modifié
Ce que je peut noter à présent c'est que r600g est maintenant un peu plus performant que r600c, du moins dans le seul benchmark que j'ai pu effectuer (Nexuiz).

Nexuiz 2.5.0 via phoronix 1.8 (1680*1050, pas de HDR, pas de son), voici les résultats :

Mesa 7.9 r600c (32 bits) : 10,25 FPS
Mesa 7.9 r600c (64 bits) : 11,15 FPS
Mesa 7.10-devel r600g (F15@stock) (32 bits) : 0 FPS (le test plante peu après le début)
Mesa 7.11-devel r600g (git Mesa) (32 bits) : 12,50 FPS

À noter quand même qu'à 12 FPS c'est injouable, mais c'est le benchmark qui met des paramètres ultra sûrement. Car sinon Nexuiz en "élevé" est parfaitement jouable.
J'ai suivi le tuto, mais je ne pense pas que le résulta de la derniére cmd soi normale
barthes@localhost libtxc_dxtn-1.0.0]$ glxinfo | grep "OpenGL version string"
OpenGL version string: 2.1 Mesa 7.10-devel
[barthes@localhost libtxc_dxtn-1.0.0]$ LD_LIBRARY_PATH="/usr/local/lib" LIBGL_DRIVERS_PATH="/usr/local/lib/dri" glxinfo | grep "OpenGL version string"
OpenGL version string: 2.1 Mesa 7.11-devel
[barthes@localhost libtxc_dxtn-1.0.0]$ glxinfo | grep "OpenGL version string"OpenGL version string: 2.1 Mesa 7.10-devel
lecbee wrote:Ce que je peut noter à présent c'est que r600g est maintenant un peu plus performant que r600c, du moins dans le seul benchmark que j'ai pu effectuer (Nexuiz).

Nexuiz 2.5.0 via phoronix 1.8 (1680*1050, pas de HDR, pas de son), voici les résultats :

Mesa 7.9 r600c (32 bits) : 10,25 FPS
Mesa 7.9 r600c (64 bits) : 11,15 FPS
Mesa 7.10-devel r600g (F15@stock) (32 bits) : 0 FPS (le test plante peu après le début)
Mesa 7.11-devel r600g (git Mesa) (32 bits) : 12,50 FPS

À noter quand même qu'à 12 FPS c'est injouable, mais c'est le benchmark qui met des paramètres ultra sûrement. Car sinon Nexuiz en "élevé" est parfaitement jouable.
Au passage jouer en 1680x1050...
VINDICATORs wrote:Au passage jouer en 1680x1050...
C'est quoi le problème ?
Je joue dans cette résolution à nexuiz et c'est fluide.
Le ration performance/qualité n'est pas toujours au rendez vous, surtout avec les pilotes libres et mesa qui ne sont pas encore au top niveau performance.

Après tout dépend aussi du matos que l'on a, sachant que plus on monte en résolution, plus il faut de la puissance.

Après il faut trouver le bon compromis avec ce dont on dispose actuellement et effectuer les réglages qu'il faut.

Perso les tests phoronix mettent aussi à genoux la machine alors qu'en jeux normale cela passe très bien, donc on peut en déduire ce que dit lecbee est valable avec de meilleurs réglages sans trop pousser.

Chez moi aussi nexuiz est très fluide avec au moins dans les 30i/s de moyenne avec un bon niveau, mais en 1280x1024 vu que je n'ai pas d'écran qui supporte plus. Cela devrait changer d'ici quelques temps vu que je vais sans doute passer au bi-écran 19" couplé avec un 27"...

Pour en revenir à mesa, nous devrions voir arriver rapidement des avancées dans la prise en charge de l'opengl plus récent, mais pas de date définitive. Peut être pour la 7.12... Sachant que l'on dispose des quelques ajouts de la 3.1, mais sans changement de version...
ok, maintenant les améliorations commence à être plus visible.

C'est vrai que le support de opengl 3 serait un plus surtout pour les jeux.
  • [supprimé]

ben51 wrote:J'ai suivi le tuto, mais je ne pense pas que le résulta de la derniére cmd soi normale
barthes@localhost libtxc_dxtn-1.0.0]$ glxinfo | grep "OpenGL version string"
OpenGL version string: 2.1 Mesa 7.10-devel
[barthes@localhost libtxc_dxtn-1.0.0]$ LD_LIBRARY_PATH="/usr/local/lib" LIBGL_DRIVERS_PATH="/usr/local/lib/dri" glxinfo | grep "OpenGL version string"
OpenGL version string: 2.1 Mesa 7.11-devel
[barthes@localhost libtxc_dxtn-1.0.0]$ glxinfo | grep "OpenGL version string"OpenGL version string: 2.1 Mesa 7.10-devel
Qu'est-ce que tu trouves anormal ?
  • [supprimé]

VINDICATORs wrote:Au passage jouer en 1680x1050...
Ben c'est ma résolution d'écran.

Je regarderais plus précisément la config utilisé par Phoronix pour le benchmark, mais effectivement en "jeu normal" (même en élevé) c'est fluide.
  • [supprimé]

ben51 wrote:ok, maintenant les améliorations commence à être plus visible.

C'est vrai que le support de opengl 3 serait un plus surtout pour les jeux.
Mis à part peut-être OilRush (que j'ai précommandé d'ailleurs), il n'y a pas grand chose qui tourne avec OpenGL 3 sur Linux actuellement. Personnellement je préférerais avoir un très bon support d'OpenGL 2.1 avec prise en charge matérielle.
Oui justement j'ai OilRush, et je crois que pour le jeux amnesia c'est aussi de l'opengl 3 (je relance le jeux ce soire pour vérifier)

Mais je suis d'accord avec toi déjà un bon support de opengl 2.
lecbee wrote:
ben51 wrote:J'ai suivi le tuto, mais je ne pense pas que le résulta de la derniére cmd soi normale
barthes@localhost libtxc_dxtn-1.0.0]$ glxinfo | grep "OpenGL version string"
OpenGL version string: 2.1 Mesa 7.10-devel
[barthes@localhost libtxc_dxtn-1.0.0]$ LD_LIBRARY_PATH="/usr/local/lib" LIBGL_DRIVERS_PATH="/usr/local/lib/dri" glxinfo | grep "OpenGL version string"
OpenGL version string: 2.1 Mesa 7.11-devel
[barthes@localhost libtxc_dxtn-1.0.0]$ glxinfo | grep "OpenGL version string"
OpenGL version string: 2.1 Mesa 7.10-devel
Qu'est-ce que tu trouves anormal ?
Pour quoi su la dernière ligne je suis toujours avec la 7.10 ?
Si je lance un jeux normalement je serait avec mesa 7.11 ?
  • [supprimé]

  • Modifié
En fait, en suivant mon tuto, on a le Mesa de F15 de base (Mesa 7.10-devel), et celui qu'on a compilé (Mesa 7.11-devel). Ils sont à 2 endroits différents. Par défaut c'est celui de F15 qui se lance tout le temps. Si on veut indiquer un autre emplacement, il faut alors spécifier 2 variables d'environnement (qui sont LD_LIBRARY_PATH et LIBGL_DRIVERS_PATH).

On pourrait très bien le faire avec
$ export LD_LIBRARY_PATH="/usr/local/lib"
et
$ export LIBGL_DRIVERS_PATH="/usr/local/lib/dri"
mais cela signifierai que toutes les applications se lanceront avec le nouveau Mesa compilé.

En l'occurrence, moi je préfère choisir individuellement quelle application doit tourner sur le Mesa compilé. Donc pour ça j'indique ces variables d'environnement à chaque lancement de programme (devant le nom de l'application). Il faut le faire à chaque fois donc.
ok je n'avais pas bien compris l'utilisation de la commande.

Bon maintenant OilRush ce lance bien.
Mais si je rajoute le patch S3TC l'écran reste noir 🙂
  • [supprimé]

  • Modifié
ben51 wrote:Mais si je rajoute le patch S3TC l'écran reste noir 🙂
Ouai j'ai plus ou moins ce problème avec ETQW. En fait je crois qu'il faille utiliser le kernel de la branche d-r-t (drm-radeon-testing) ou bien drm-next, je n'ai pas bien compris.

Quand tu fais un
# tail /var/log/messages
après avoir lancé OilRush avec S3TC, est-ce que tu as des messages d'erreur radeon en rapport avec les textures ?
Oui j'ai bien cela
Mar 15 20:33:30 localhost kernel: [ 2527.469203] radeon 0000:01:00.0: r600_check_texture_resource:1214 texture invalid format 53
  • [supprimé]

Ok j'ai la même chose avec ETQW, sauf que les numéros sont 49 ou 51 selon le mode de compression que je paramètre dans le fichier de conf d'ETQW.