Pilotes accélérés NVIDIA pour Linux - LISEZMOI et Guide d'installation Dernière mise à jour : $ 16 juillet 2003 $ Dernière version du pilote : 1.0-4496 Les pilotes accélérés NVIDIA pour Linux fournissent à Linux x86 une accélération 2D et un support OpenGL haute performance avec l'utilisation de processeurs graphiques (GPU) NVIDIA. Ces pilotes optimisent l'accélération matérielle des applications OpenGL via un Serveur X de rendu direct et prennent en charge presque tous les processeurs graphiques NVIDIA (vous trouverez la liste complète des processeurs pris en charge dans l'APPENDICE A). Ils supportent également TwinView, TV-Out et les écrans plats. Ce fichier LISEZMOI explique comment installer, configurer et utiliser les pilotes accélérés NVIDIA pour Linux. Ce fichier est disponible sur le site web de NVIDIA (www.nvidia.com) et est installé dans /usr/share/doc/nvidia_GLX-1.0/. __________________________________________________________________________ TABLE DES MATIÈRES : (sec-01) CHOIX DES PACKAGES NVIDIA APPROPRIÉS À VOTRE SYSTÈME (sec-02) INSTALLATION DU PILOTE NVIDIA (sec-03) ÉDITION DE VOTRE FICHIER XF86CONFIG (sec-04) FAQ (sec-05) COMMENT NOUS CONTACTER (sec-06) AUTRES RESSOURCES (app-a) APPENDICE A: PROCESSEURS GRAPHIQUES NVIDIA PRIS EN CHARGE (app-b) APPENDICE B: CONFIGURATION LOGICIELLE REQUISE (app-c) APPENDICE C: COMPOSANTS INSTALLÉS (app-d) APPENDICE D: OPTIONS DE XF86CONFIG (app-e) APPENDICE E: DÉFINITION DES VARIABLES D'ENVIRONNEMENT OPENGL (app-f) APPENDICE F: CONFIGURATION D'AGP (app-g) APPENDICE G: PROBLÈMES SPÉCIFIQUES AUX SYSTÈMES ALI (app-h) APPENDICE H: PROBLÈMES SPÉCIFIQUES AUX SYSTÈMES TNT (app-i) APPENDICE I: CONFIGURATION DE TWINVIEW (app-j) APPENDICE J: CONFIGURATION DE TV-OUT (app-k) APPENDICE K: CONFIGURATION D'UN ORDINATEUR PORTABLE (app-l) APPENDICE L: MODES DE PROGRAMMATION (app-m) APPENDICE M: PAGE FLIPPING, WINDOW FLIPPING ET UBB (app-n) APPENDICE N: PROBLÈMES CONNUS (app-o) APPENDICE O: INTERFACE PROC (app-p) APPENDICE P: PRISE EN CHARGE DE XVMC (app-q) APPENDICE Q: PRISE EN CHARGE DE GLX (app-r) APPENDICE R: CONFIGURATION D'ÉCRANS X MULTIPLES SUR UNE CARTE (app-s) APPENDICE S: SYSTEME DE GESTION D'ENERGIE Pour éviter de surcharger les instructions d'installation, la plupart des problèmes fréquemment rencontrés ne sont pas détaillées dans ces explications, mais sont traités dans les FAQ. Il est toutefois conseillé de lire entièrement le fichier LISEZMOI avant de passer à l'une quelconque des étapes décrites. __________________________________________________________________________ (sec-01) CHOIX DES PACKAGES NVIDIA APPROPRIÉS À VOTRE SYSTÈME __________________________________________________________________________ NVIDIA a une architecture de pilotes unifiée, ce qui signifie qu'un ensemble de pilotes peut être utilisé avec tous les processeurs graphiques NVIDIA pris en charge. Vous trouverez une liste des processeurs graphiques NVIDIA pris en charge par les pilotes actuels dans l'Appendice A. La version 1.0-4349 des pilotes introduit un nouveau package et mécanisme d'installation, qui simplifie considérablement l'installation. Désormais, vous ne devrez télécharger qu'un seul fichier : NVIDIA-Linux-x86-1.0-1.0-4496-pkg1.run. Ce fichier regroupe tout ce qui se trouvait précédemment dans les anciens packages NVIDIA_kernel et NVIDIA_GLX. La version 1.0-4496 des pilotes ajoute un nouveau suffixe ("-pkg#")de package au fichier . run. Cela permet de distinguer les packages contenant des pilotes identiques, mais des interfaces de noyaux précompilées différentes. Pour éviter toute confusion, téléchargez le fichier .run ayant le plus grand nombres de pkg. __________________________________________________________________________ (sec-02) INSTALLATION DU PILOTE NVIDIA __________________________________________________________________________ AVANT DE COMMENCER L'INSTALLATION DU PILOTE Vous devez quitter le serveur X avant de commencer l'installation du pilote. De plus, vous devez définir votre niveau d'exécution par défaut de manière à faire le boot sur une console VGA et non directement dans X (consultez la documentation fournie avec votre distribution Linux si vous ne savez pas comment procéder ; normalement, vous devez modifier votre fichier /etc/inittab). Cette opération facilitera la restauration en cas de problèmes au cours de l'installation. Une fois le pilote installé, vous devez modifier votre fichier XF86Config avant de pouvoir l'utiliser. Reportez-vous à la section ÉDITION DE VOTRE FICHIER XF86CONFIG, ci-après. PRÉSENTATION DU NOUVEL UTILITAIRE D'INSTALLATION DES PILOTES NVIDIA Après avoir téléchargé NVIDIA-Linux-x86-1.0-4496.run, commencez l'installation en quittant X, accédez à l'aide de la commande cd au répertoire contenant le fichier téléchargé, et exécutez : sh NVIDIA-Linux-x86-1.0-4496-pkg1.run Le fichier .run est auto-extractible. Par conséquent, lorsque vous lancez le fichier .run, il extrait le contenu de l'archive et exécute l'utilitaire `nvidia-installer` qui vous guidera pour l'installation du pilote NVIDIA. Le fichier .run accepte de nombreuses options de ligne de commande, parmi lesquelles : --info Imprime des infos sur le fichier .run et quitte. --check Vérifie l'intégrité de l'archive et quitte. --extract-only Extrait uniquement le contenu de ./nvidia-Linux-x86-1.0-4496.run, mais ne lance pas 'nvidia-installer'. --help Imprime des informations sur l'utilisation des options de ligne de commande les plus courantes et quitte. --advanced-options Imprime des informations sur l'utilisation des options de ligne de commande courantes et avancées puis quitte. Installation installe également l'utilitaire `nvidia-installer`, qui pourra ensuite servir pour désinstaller les pilotes, télécharger automatiquement les mises à jours des pilotes, etc. INTERFACES KERNEL Le module de noyau NVIDIA a une couche d'interface kernel qui doit être spécifiquement compilée pour la configuration et la version du noyau que vous utilisez. NVIDIA distribue le code source à cette couche d'interface kernel, ainsi qu'une version précompilée pour grand nombre de noyaux distribués par certaines distributions populaires. Au cours de son exécution, l'utilitaire d'installation contrôlera s'il possède une interface kernel précompilée pour le noyau que vous utilisez. En son absence, il en cherchera une sur le site ftp de NVIDIA et la téléchargera(à condition, bien sûr, que vous ayez une connexion Internet). S'il trouve une interface kernel précompilée correspondant à votre noyau, elle sera reliée [1] à la portion binaire du module du noyau NVIDIA, de manière à avoir un module de noyau approprié à votre noyau. S'il ne trouve aucune interface kernel précompilée convenant à votre noyau, il compilera l'interface kernel pour vous. Toutefois, il vérifiera d'abord que les fichiers d'en-tête correspondant à votre noyau sont bien installés sur votre système. Si le programme d'installation compile l'interface kernel, vous devrez installer le package kernel-sources pour votre noyau. [1] REMARQUE : un éditeur de liens doit être installé sur votre système pour permettre l'installation. L'éditeur de liens (habituellement '/usr/bin/ld') fait partie du package binutils ; vérifiez que binutils est installé avant de passer à l'installation du pilote NVIDIA. CARACTÉRISTIQUES DE NVIDIA-INSTALLER o Uninstall : l'installation du pilote fera une copie des fichiers à l'origine de conflits et enregistrera les nouveaux fichiers installés sur le système. Vous pouvez exécuter : nvidia-installer --uninstall pour désinstaller le pilote actuel ; cette commande supprimera tous les fichiers installés sur le système et restaurera les copies de sauvegarde des fichiers. L'installation de nouveaux pilotes désinstalle implicitement tout pilote précédent. o Auto-Updating : Si vous exécutez : nvidia-installer --latest l'utilitaire se connectera au site FTP de NVIDIA et affichera la dernière version du pilote ainsi que l'url où trouver le fichier de cette dernière version. Si vous exécutez : nvidia-installer -update l'utilitaire se connectera au site FTP de NVIDIA, téléchargera le fichier du pilote le plus récent et l'installera. o Multiple user interfaces : l'utilitaire d'installation utilisera une interface utilisateur sous ncurses s'il trouve la librairie ncurses correcte, sinon il passera à une interface à ligne de commande. Pour désactiver l'interface utilisateur ncurses, utilisez l'option '--ui=none'. o Updated Interfaces kernel : l'utilitaire d'installation peut télécharger des interfaces de noyau précompilées depuis le site FTP de NVIDIA (pour les noyaux sortis après la version du pilote NVIDIA). FAQ CONCERNANT NVIDIA-INSTALLER Q: Comment puis-je extraire le contenu du fichier .run sans installer le pilote ? R: Utilisez la commande : sh NVIDIA-Linux-x86-1.0-4496.pkg1.run --extract-only Vous créerez ainsi le répertoire NVIDIA-Linux-x86-1.0-4496-pkg1, qui contient le fichier .run décompressé. Q: Comment puis-je voir le code source de la couche d'interface kernel ? R: Les fichiers source de la couche d'interface kernel se trouvent dans le répertoire usr/src/nv du fichier .run décompressé. Pour accéder à ces sources, exécutez : sh NVIDIA-Linux-x86-1.0-4496-pkg1.run --extract-only cd NVIDIA-Linux-x86-1.0-4496-pkg1/usr/src/nv/ Q: Je viens de mettre mon noyau à jour et je n'arrive pas à charger le module du noyau NVIDIA. Qu'est-ce qui ne va pas ? R: La couche d'interface kernel du module du noyau NVIDIA doit être compilée spécifiquement pour la configuration et la version de votre noyau. Si vous mettez votre noyau à jour, la meilleure solution est de réinstaller le pilote. ADVANCED : Vous pouvez installer le module du noyau NVIDIA pour un noyau non utilisé (par exemple : si vous venez de construire et d'installer un nouveau noyau sans l'avoir encore rebooté) avec une ligne de commande du type suivant : sh NVIDIA-Linux-x86-1.0-4496-pkg1.run --kernel-name='KERNEL_NAME' Où 'KERNEL_NAME' est le nom que `uname -r` afficherait si le noyau cible était utilisé. Q: Pourquoi NVIDIA ne fournit-elle plus de rpm ? R: Les distributions Linux n'utilisent pas toutes des rpm et NVIDIA voulait une seule solution pour toutes les distributions Linux. Comme précisé dans la licence d'utilisation des logiciels NVIDIA, les distributions Linux peuvent redistribuer le pilote NVIDIA pour Linux dans un format de package quelconque. Q: nvidia-installer ne fonctionne pas sur mon ordinateur. Comment puis-je installer le pilote contenu dans le fichier .run ? R: Pour installer le pilote NVIDIA contenu dans le fichier .run sans utiliser nvidia-installer, vous pouvez utiliser le Makefile inclus : sh ./nvidia-Linux-x86-1.0-4496-pkg1.run --extract-only cd NVIDIA-Linux-x86-1.0-4496-pkg1 make install Cette méthode d'installation est toutefois déconseillée et ne doit être utilisée qu'en dernier ressort si nvidia-installer ne fonctionne pas correctement sur votre système. Q: nvidia-installer peut-il utiliser un serveur proxy ? R: Oui, parce que le support ftp inclus dans nvidia-installer est basé sur snarf et accepte les variables d'environnement FTP_PROXY, NARF_PROXY et PROXY. Q: Quelle est l'importance du suffixe "pkg#" par rapport au fichier .run ? R: Le suffixe "pkg#" permet de distinguer des fichiers .run contenant le même pilote, mais des interfaces de noyau précompilées distinctes. Si un nouveau noyau est fourni dans une distribution après la publication d'un pilote NVIDIA, le pilote NVIDIA actuel peut être modifié de manière à inclure une interface de noyau précompilée correspondant à ce nouveau noyau (en plus de toutes les interfaces de noyau précompliées figurant dans le précédent package du pilote). Les fichiers .run ayant le même numéro de version, mais des nombres de pkg différents, ne diffèrent que par les interfaces de noyau précompilées qu'ils contiennent. En outre, les fichiers .run ayant un plus grand nombre de pkg ont le même contenu que les fichiers .run ayant un plus petit nombre de .pkg. Q: J'ai déjà installé NVIDIA-Linux-x86-1.0-4496-pkg1.run, mais je constate que NVIDIA-Linux-x86-1.0-4496-pkg2.run vient d'être proposé dans la page de téléchargement des pilotes NVIDIA Linux. Dois-je télécharger et installer NVIDIA-Linux-x86-1.0-4496-pkg2.run? R: Ce n'est pas nécesaire. Le pilote fourni dans tous les fichiers 1.0-4496 .run est identique. Il n'est donc pas nécessaire d'effectuer une réinstallation. Q: Puis-je ajouter mes propres interfaces de noyau précompilée au fichier .run ? R: Oui. L'option "--add-this-kernel" du fichier .run décompactera le fichier .run, créera une interface de noyau précompilée pour le noyau en cours d'exécution, reconstituera le fichier .run en ajoutant "-custom" au nom du fichier. Cette opération peut s'avérer nécessaire, si vous gérez plusieurs machines Linux exécutant le même noyau.une distribution fournit Q: Où puis-je trouver le code source de l'utilitaire nvidia-installer ? R: L'utilitaire nvidia-installer est fourni sous le GPL. Le dernier code source est disponible sur : ftp://download.NVIDIA.com/XFree86/nvidia-installer/ REMERCIEMENTS POUR NVIDIA-INSTALLER nvidia-installer s'est inspiré de l'outil loki_update : (http://www.lokigames.com/development/loki_update.php3.) Le support ftp et http dans nvidia-installer est basé sur snarf 7.0 : (http://www.xach.com/snarf/). L'archive auto-extractible (aka "fichier .run") est générée en utilisant makeself.sh: (http://www.megastep.org/makeself/) __________________________________________________________________________ (sec-03) ÉDITION DE VOTRE FICHIER XF86CONFIG __________________________________________________________________________ Dans la version 4.0 de XFree86, la syntaxe du fichier XF86Config était légèrement différente de celle des versions 3.x. Pour permettre la coexistence des versions 3.x et 4.x de XFree86 sur le même système, XFree86 4.x utilise le fichier de configuration "/etc/X11/XF86Config-4" s'il existe, sinon (seulement si ce fichier n'existe pas), il utilise le fichier "/etc/X11/XF86Config" (il s'agit en fait d'une sur-simplification du critère de recherche ; consultez la man page XF86Config pour une description complète de chemin de recherche). Vérifiez quel est le fichier de configuration XFree86 utilisé. Si vous avez des doutes, recherchez une ligne commençant par "(==) Using config file:" dans votre fichier journal XFree86 ("/var/log/XFree86.0.log"). Dans ce LISEZMOI, on suppose que votre fichier de configuration est nommé "XF86Config". Si vous ne disposez pas d'un fichier XF86Config fonctionnant, vous pouvez démarrer de plusieurs manières : un modèle de fichier de configuration est fourni avec XFree86 et un autre modèle de fichier de configuration est inclus avec le package du pilote NVIDIA (ce fichier est installé dans /usr/share/doc/nvidia_GLX-1.0/). Vous pouvez également utiliser un programme, tel que 'xf86config' ; certaines distributions fournissent des outils permettant de générer un fichier XF86Config. Pour de plus amples informations sur la syntaxe du fichier XF86Config, reportez-vous à la man page. Si vous utilisez déjà un fichier XF86Config avec un autre pilote (par exemple, le pilote 'nv' ou 'vesa'), il vous suffira de rechercher la section Device correspondante et de remplacer la ligne : Driver "nv" (ou Driver "vesa") par Driver "nvidia" Dans la section Module , vérifiez que vous avez : Load "glx" Vous devez également supprimer les lignes suivantes : Load "dri" Load "GLcore" si elles sont présentes. De nombreuses options peuvent également être ajoutées au fichier XF86Config pour un réglage fin du pilote XFree86 NVIDIA. Vous trouverez une liste complète de ces options dans l'Appendice D. Après avoir terminé la configuration de votre fichier XF86Config, vous pouvez redémarrer X et commencer à utiliser les librairies accélérées OpenGL. Après le redémarrage de X, vous devriez pouvoir exécuter une application OpenGL quelconque et utiliser les nouvelles librairies NVIDIA. Si vous rencontrez des problèmes, reportez-vous aux FAQ ci-dessous. __________________________________________________________________________ (sec-04) FAQ __________________________________________________________________________ Q: Par où dois-je commencer pour le diagnostic de problèmes d'affichage ? R: L'un des outils les plus efficaces pour le diagnostic de problèmes est le fichier journal de XFree86 qui se trouve dans /var/log (ce fichier est "/var/log/XFree86.<#>.log", où "<#>" est le numéro du serveur - généralement 0). Les lignes qui commencent par "(II)" sont des informations, par "(WW)" des avertissements et par "(EE)" des erreurs. Vous devez vous assurer que le fichier de configuration utilisé est le bon (c'est-à-dire le fichier de configuration que vous avez modifié) ; recherchez la ligne commençant par : "(==) Using config file:". Vérifiez également que vous utilisez le pilote NVIDIA et non le pilote 'nv' ou 'vesa' ; pour cela, recherchez : "(II) LoadModule: "nvidia"" et vérifiez que les lignes à partir du pilote commencent par : "(II) NVIDIA(0)". Q: Comment puis-je augmenter la quantité de données imprimées dans le fichier journal XFree86 ? R: Par défaut, le pilote NVIDIA de X imprime un nombre relativement faible de messages dans stderr et le fichier journal XFree86. En cas d'erreur, il peut être utile d'activer les options de ligne de commande de XFree86 "-verbose" et "-logverbose" pour obtenir un niveau d'affichage plus complet des messages stderr et du fichier journal. Le pilote X de NVIDIA affichera davantage de messages si le mode verbose a été initialisé à 5 ou plus (par défaut, le niveau d'affichage de XFree86 est à 1 pour stderr et à 3 pour le fichier journal). Si vous voulez activer le mode verbose depuis le pilote X de NVIDIA pour le fichier journal et stderr, vous pouvez démarrer X à entrant : 'startx -- -verbose 5 -logverbose 5'. Q: Mon serveur X ne démarre pas et mon fichier journal XFree86 contient l'erreur: "(EE) NVIDIA(0): Failed to initialize the kernel module NVIDIA!" R: Rien ne fonctionnera si le module du noyau NVIDIA ne fonctionne pas correctement. Si le fichier journal de X contient un message du type "(EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module!", vous avez très probablement un problème avec le module du noyau NVIDIA. Si vous avez effectué l'installation à partir de rpm, vous devez d'abord vérifier que le rpm a été spécifiquement construit pour le noyau que vous utilisez. Contrôlez également que le module est chargé ('/sbin/lsmod'); s'il ne l'est pas, essayez de le charger explicitement à l'aide de 'insmod' ou 'modprobe' (n'oubliez pas de quitter le serveur X avant d'installer un nouveau module de noyau). Si vous recevez des erreurs concernant des symboles non résolus, le module de noyau a probablement été construit à l'aide de fichiers d'en-tête correspondant à une version de noyau autre que celle utilisée. Vous pouvez contrôler explicitement quels fichiers d'en-tête du noyau ont été utilisés pendant la construction du module du noyau NVIDIA à l'aide de l'option --kernel-include-dir (pour plus de détails, reportez-vous à `sh NVIDIA-Linux-x86-1.0-4496-pkg1.run --advanced-options`. La convention relative à l'emplacement des fichiers d'en-tête du noyau a changé à peu près au moment de la sortie de la version 2.4.0 du noyau, en même temps que l'emplacement du module de noyaux. Si le chargement du module du noyau échoue, il est probable que modprobe/insmod essaie de charger un module de noyau précédent (si vous avez effectué la mise à jour). Il peut être utile de d'accéder au répertoire contenant le nouveau module de noyau et de taper 'insmod ./nvidia.o'. L'échec peut également être dû aux fichiers des périphériques /dev/nvidia* manquants. Enfin, le module du noyau NVIDIA peut générer des messages d'erreur indiquant un problème -- pour voir ces messages, accédez à /var/log/messages ou à tous les endroits où syslog dirige les messages concernant le noyau. Ces messages sont précédés par "NVRM". Q: X démarre mais les applications OpenGL s'arrêtent immédiatement. R: Si X démarre mais qu'OpenGL cause des problèmes, vous avez probablement un problème avec d'autres librairies ou avec des liens symboliques. Pour plus de détails, consultez l'Appendice C. Il suffit parfois de réexécuter 'ldconfig'. Vous devez également contrôler la présence des bonnes extensions ; 'xdpyinfo' doit renvoyer les extensions "GLX", "NV-GLX" et "NVIDIA-GLX". Si ces trois extensions sont absentes, le module glx ne se chargera probablement pas ou sera incapable de charger implicitement GLcore. Contrôlez votre fichier XF86Config et assurez-vous de charger glx (reportez-vous au point "Édition de votre Fichier XF86Config" ci-avant). Si votre Fichier XF86Config est correct, contrôlez si le fichier journal de XFree86 contient des messages d'avertissement ou d'erreur relatifs à GLX. Vérifiez également si tous les liens symboliques nécessaires sont en place (reportez-vous à l'Appendice C). Q: L'installation du module de noyau NVIDIA génère un message d'erreur du type : #error Modules should never use kernel-headers system headers #error but headers from an appropriate kernel-source R: Vous devez installer la source pour le noyau Linux. Dans la plupart des cas, il suffit d'installer le package des sources de noyau de votre distribution pour résoudre le problème. Q: Les applications OpenGL se ferment en générant le message d'erreur suivant : Error: Could not open /dev/nvidiactl because the permissions are too restrictive. Please see the FREQUENTLY ASKED QUESTIONS section of /usr/share/doc/nvidia_GLX-1.0/README for steps to correct. R: Un module de sécurité du système PAM a probablement modifié les autorisations sur les fichiers des périphériques NVIDIA. Ce système de sécurisation fonctionne généralement bien, mais peut parfois poser un problème. Pour corriger ce problème, il est conseillé de désactiver la fonction de sécurité. Les distributions Linux utilisent différents fichiers pour effectuer ce contrôle ; demandez à votre distributeur comment désactiver cette fonction de sécurité. Par exemple, si votre système contient le fichier /etc/security/console.perms vous devez modifier ce fichier et supprimer la ligne commençant par "" (il nous a également été signalé que d'autres références à doivent être supprimées dans console.perms, mais ceci n'a pas été vérifié par NVIDIA). Par contre, si votre système contient le fichier /etc/logindevperms vous devez modifier ce fichier et supprimer la ligne contenant /dev/nvidiactl. Ces opérations empêcheront au système de sécurité PAM de modifier les autorisations sur les fichiers des périphériques NVIDIA. Ensuite, vous devrez réinitialiser les autorisations sur les fichiers des périphériques pour retourner aux autorisations et utilisateurs d'origine. Pour cela, vous pouvez utiliser les commandes : chmod 0666 /dev/nvidia* chown root /dev/nvidia* Q: Les applications OpenGL plantent et génèrent l'avertissement suivant : WARNING: Your system is running with a buggy dynamic loader. This may cause crashes in certain applications. If you experience crashes you can try setting the environment variable __GL_SINGLE_THREADED to 1. For more information please consult the FREQUENTLY ASKED QUESTIONS section in the file /usr/share/doc/nvidia_GLX-1.0/README. R: Le chargeur dynamique sur votre système a un bogue qui cause le plantage des applications liées avec pthreads et qui utilisent dlopen() pour charger les libGL. Ce bogue est présent dans les anciennes versions du chargeur dynamique. Les distributions fournies avec ce chargeur comprennent, entres autres, Red Hat Linux 6.2 et Mandrake Linux 7.1. Les versions 2.2 et suivantes du chargeur dynamique fonctionnent correctement. Si l'application qui se plante a un seul thread, il suffit de régler la variable d'environnement __GL_SINGLE_THREADED à 1 pour résoudre le problème. Dans le shell bash, entrez : export __GL_SINGLE_THREADED=1 et dans csh et dérivés, utilisez : setenv __GL_SINGLE_THREADED 1 Les versions précédentes des pilotes accélérés NVIDIA pour Linux tentaient de remédier à ce problème, mais la solution causait des problèmes dans d'autres applications et a été supprimée après la version 1.0-1541. Q: Lorsque j'utilise Quake3, il plante quand je change de modes vidéo. Qu'est-ce qui ne va pas ? R: Vous avez probablement rencontré le problème décrit ci-dessus. Contrôlez si vous recevez le message d'avertissement cité ci-dessus. Pour corriger le problème, réglez __GL_SINGLE_THREADED à 1 comme décrit ci-dessus). Q: Mon système fonctionne mais il est instable. Qu'est-ce qui ne va pas ? R: Vos problèmes de stabilité pourraient être liés à l'AGP. Pour plus de détails, reportez-vous à l'Appendice F. Q: Le module du noyau n'est pas chargé dynamiquement au démarrage de X. Je dois toujours exécuter d'abord 'modprobe nvidia'. Qu'est-ce qui ne va pas ? R: Contrôler si la ligne "alias char-major-195 nvidia" apparaît dans votre fichier de configuration du module ; il s'agit généralement de "/etc/conf.modules", "/etc/modules.conf" ou "/etc/modutils/alias". Pour plus de détails, consultez la documentation fournie avec votre distribution. Q: Je n'arrive pas à construire le module du noyau NVIDIA ou j'arrive à le construire mais modprobe/insmod ne charge pas le module dans mon noyau. Qu'est-ce qui ne va pas ? R: Ces problèmes surviennent généralement lorsque les fichiers d'en-tête utilisés pour la construction ne correspondent pas au noyau (par ex., les fichiers d'en-tête se réfèrent à une version du noyau différente de celle utilisée). La convention précédente prévoyait l'enregistrement des fichiers d'en-tête du noyau dans "/usr/include/Linux/", mais elle a été supprimée en faveur de "/lib/modules/`uname -r`/build/include". L'utilitaire nvidia-installer devrait déterminer l'emplacement de ces fichiers sur votre système ; toutefois, en cas de problème, vous pouvez forcer l'utilisation de certains fichiers d'en-tête pour la construction à l'aide de l'option --kernel-include-dir. Pour cela, les fichiers d'en-tête du noyau doivent évidemment être installés sur votre système. Consultez la documentation fournie avec votre distribution ; certaines distributions n'installent pas par défaut les fichiers d'en-tête du noyau ou elles installent des fichiers d'en-tête qui ne conviennent pas au noyau utilisé. Q: Pourquoi les applications OpenGL sont elles si lentes ? R: L'application n'utilise probablement pas la librairie OpenGL fournie par NVIDIA, mais une autre librairie restée sur votre système. Pour de plus amples informations, reportez-vous à l'APPENDICE C. Q: Quake2 ne fonctionne pas correctement. R: Pour fonctionner correctement, Quake2 a besoin de quelques petits réglages. D'abord, l'installation crée dans le répertoire Quake2 un lien symbolique vers libMesaGL.so, appelé libGL.so. Ce lien symbolique doit être supprimé ou renommé. Ensuite, pour exécuter Quake2 en mode OpenGL, vous devez taper : 'quake2 +set vid_ref glx +set gl_driver libGL.so'. Quake2 semble ne pas prendre en charge tous les modes plein-écran, mais vous pouvez utiliser votre serveur X avec une résolution supportée par Quake2 pour l'émulation du mode plein-écran. Q: Heretic II ne fonctionne pas correctement. R: Heretic II installe également par défaut un lien symbolique appelé libGL.so dans le répertoire de l'application . Vous pouvez supprimer ou renommer ce lien symbolique, puisque le système trouvera le libGL.so par défaut (que vos pilotes installent dans /usr/lib). Dans Heretic II, vous pouvez régler votre mode de rendu sur OpenGL dans le menu video. Vous pouvez également télécharger un patch pour Heretic II depuis le site de Lokigames à l'adresse : http://www.lokigames.com/products/heretic2/updates.php3 Q: Où puis-je trouver gl.h ou glx.h pour compiler les programmes OpenGL ? R: Ces fichiers d'en-tête sont déjà installés sur la plupart des systèmes. Toutefois, NVIDIA fournit ses propres fichiers gl.h et glx.h, qui sont installés dans /usr/share/doc/NVIDIA_GLX-1.0/include/GL. Pour utiliser ces fichiers, vous devez d'abord les copier manuellement dans /usr/include/GL ou instruire l'utilitaire de les installer dans /usr/include/GL en passant l'option '-opengl headers' dans le fichier NVDIA-Linux-x86-1.0-4496-pkg1.run pendant l'installation. Q: Puis-je être informé par e-mail de la sortie de nouvelles versions de pilotes accélérés NVIDIA pour Linux ? R: Oui. Il suffit de remplir la fiche d'inscription à l'adresse : http://www.nvidia.com/view.asp?FO=pilote_update Q: Mon système décroche quand j'effectue une commutation VT si rivafb est activé. R: Actuellement, il n'est pas possible d'utiliser rivafb en même temps que le module du noyau NVIDIA. En général, il est déconseillé d'utiliser deux pilotes logiciels indépendants pour le même composant matériel. Q: La compilation du module du noyau NVIDIA génère l'erreur suivante : You appear to be compiling the NVIDIA kernel module with a compiler different from the one that was used to compile the running kernel. This may be perfectly fine, but there are cases where this can lead to unexpected behaviour and system crashes. If you know what you are doing and want to override this check, you can do so by setting IGNORE_CC_MISMATCH. In any other case, set the CC environment variable to the name of the compiler that was used to compile the kernel. R: Vous devez compiler le module du noyau NVIDIA en utilisant la même version du compilateur que celle utilisée pour la compilation de votre noyau. Certaines structures de données du noyau Linux dépendent de la version de gcc utilisée pour sa compilation ; par exemple, dans include/Linux/spinlock.h: ... ... * Most gcc versions have a nasty bug with empty initializers. */ #if (__GNUC__ > 2) typedef struct { } rwlock_t; #define RW_LOCK_UNLOCKED (rwlock_t) { } #else typedef struct { int gcc_is_buggy; } rwlock_t; #define RW_LOCK_UNLOCKED (rwlock_t) { 0 } #endif Si le noyau est compilé avec gcc 2.x, mais que gcc 3.x est utilisé pour la compilation de l'interface du noyau (ou vice versa), la taille de rwlock_t changera et causera l'échec de fonctions telles que ioremap. Pour connaître la version de gcc utilisée pour compiler votre noyau, observez ce que vous renvoie la commande : cat /proc/version Pour connaître la version de gcc qui se trouve dans votre $PATH, utilisez : gcc -v Q: X échoue en générant l'erreur "Failed to allocate LUT context DMA" R: Ce type d'erreur est l'une des conséquences possibles de la compilation de l'interface du noyau NVIDIA en utilisant une version de gcc différente de celle utilisée pour compiler le noyau Linux (voir ci-dessus). Q: Quelle est la politique de NVIDIA en ce qui concerne les noyaux de la série de développement de Linux ? R: NVIDIA ne supporte pas officiellement les noyaux de la série de développement de Linux. Toutefois, le code source de tous les modules de noyau qui s'interfacent avec le noyau Linux est disponible dans le répertoire usr/src/nv/ du fichier .run. NVIDIA encourage les membres de la communauté Linux à développer des patchs pour ces fichiers source de manière à pouvoir prendre en charge les noyaux de la série de développement. Une recherche dans Google permettra probablement de trouver plusieurs patchs. Q: J'ai récemment mis à jour plusieurs librairies sur mon système à l'aide de l'utilitaire de mise à jour distribué par Linux et le pilote graphique NVIDIA ne fonctionne plus. Qu'est-ce qui ne va pas ? R: Votre utilitaire de mise à jour Linux a probablement installé des librairies entrant en conflit ; pour le diagnostic du problème, reportez-vous à l'APPENDICE C: COMPOSANTS INSTALLÉS. Q: `rpm --rebuild` donne une erreur "unknown option" R: De récentes versions de rpm ne prennent plus en charge l'option "--rebuild" ; si vous possédez l'une de ces versions de rpm, vous devez utiliser la commande `rpmbuild --rebuild`. L'exécutable `rpmbuild` est fourni par le package rpm-build. Q: J'utilise les processeurs graphiques internes nForce et nForce2 et mon fichier journal XFree86.0 contient des avertissements du type : Not using mode "1600x1200" (exceeds valid memory bandwidth usage) R: Les processeurs graphiques intégrés ont une bande passante mémoire limitée qui restreint la résolution et la vitesse de rafraîchissement des modes demandés. Pour corriger ce problème, vous pouvez réduire la vitesse de rafraîchissement maximum en diminuant la valeur supérieure de la plage "VertRefresh" dans la section Monitor de votre fichier XF86Config. Vous pouvez également désactiver le test de la bande passante mémoire à l'aide de l'option "NoBandWidthTest" du fichier XF86Config, bien que cette solution soit déconseillée. Q: J'ai reconstruit le module du noyau NVIDIA, mais quand j'essaie de l'introduire, je reçois un message disant que des symboles sont irrésolus. A. Si vous avez des symboles irrésolus, il est probable que vos sources du noyau ne correspondent pas au noyau utilisé. Les sources doivent correspondre au module du noyau NVIDIA. Vérifiez que vos sources du noyau sont installées et configurées pour le noyau utilisé. Q: Comment puis-je savoir si mes sources du noyau sont installées ? R: Si vous tournez sur une distribution au format RPM (Red Hat, Mandrake, SuSE, etc), vous pouvez utiliser RPM pour le savoir. A une invite du shell, tapez : `rpm -qa | grep kernel` et observez la réponse. Vous devriez voir un package correspondant à votre noyau (dont le nom est souvent du type kernel-2.4.18-3) et un package des sources du noyau de la même version (dont le nom est souvent du type kernel-source-2.4.18-3). Si aucune des lignes ne correspond à un package de sources, il vous faudra probablement l'installer. Si les versions listées ne correspondent pas (par ex. : kernel-2.4.18-10 et kernel-source-2.4.18-3), vous devrez mettre à jour le package des sources du noyau pour qu'il corresponde au noyau installé. Si vous avez plusieurs noyaux sur votre système, vous devez installer le package des sources du noyau correspondant au noyau *utilisé* (ou vous assurer que le package des sources installé correspond bien au noyau utilisé). Pour cela, vous pouvez utiliser 'uname -r' et observer si les versions correspondent. Q: Pourquoi m'est-il impossible de charger le module du noyau NVIDIA que j'ai compilé pour le noyau Red Hat Linux 7.3 2.4.18-3bigmem ? R: Les fichiers d'en-tête du noyau Red Hat que Linux distribue pour le noyau Red Hat Linux 7.3 2.4.18-3bigmem sont mal configurés. Il est possible de charger le module du noyau NVIDIA précompilé pour le noyau, mais si vous souhaitez compiler vous même les fichiers d'interface du noyau NVIDIA pour ce noyau, vous devez taper ce qui suit : cd /lib/modules/`uname -r`/build/ cp configs/kernel-2.4.18-i686-bigmem.config .config make mrproper oldconfig dep Remarque : Red Hat Linux fournit des fichiers d'en-tête du noyau qui sont simultanément configurés pour TOUS les noyaux d'une version de distribution particulière. Un fichier d'en-tête généré au moment de l'initialisation configure certains paramètres qui sélectionnent la bonne configuration. La reconstruction des en-têtes de noyau à l'aide des commandes ci-dessus créera uniquement des fichiers d'en-tête pour la configuration du noyau Red Hat Linux 7.3 2.4.18-3bigmem, en éliminant les fichiers d'en-tête pour les autres configurations. Q: X met longtemps (plusieurs minutes)à démarrer. Que puis-je faire ? R: La plupart des problèmes de lenteur du démarrage du serveur X sont dus à des données inexactes dans les BIOS vidéo concernant les types d'écrans pouvant être connectés ou le port i2c à utiliser pour la détection. Vous pouvez éliminer ces problèmes en utilisant l'option "IgnoreDisplayDevices" de XF86Config (reportez-vous à la description dans(app-d) APPENDICE D: OPTIONS DE XF86Config). Q: Pourquoi le serveur X utilise-t-il autant de mémoire ? R: Lorsque vous mesurez la quantité de mémoire utilisée par une application, vous devez faire une distinction entre la RAM physique du système et les mappages virtuels des ressources partagées. Par exemple, la plupart des librairies partagées ne sont présentes qu'une seule fois dans la mémoire physique, mais sont mappées dans plusieurs processus. Cette mémoire ne doit être comptée qu'une seule fois dans le calcul de la mémoire totale utilisée. De même, la mémoire vidéo d'une carte graphique ou la mémoire registre d'un périphérique quelconque peut être mappée dans plusieurs processus. Ces mappages ne consomment pas la RAM physique du système. Cette question a fréquemment fait l'objet de discussions dans les mailing lists sur XFree86 ; allez, par exemple à : http://marc.theaimsgroup.com/?l=xfree-xpert&m=96835767116567&w=2 L'utilitaire `pmap` décrit sur cette page et disponible à l'adresse : http://web.hexapodia.org/~adi/pmap.c est un outil qui permet de faire la distinction entre les types de mappage de la mémoire. Par exemple, si `top` indique que X utilise plusieurs centaines de Mo de mémoire, la dernière ligne générée par pmap : mapped: 287020 KB writable/private: 9932 KB shared: 264656 KB indique que X utilise effectivement moins de 10 Mo de RAM système (la valeur "writable/private"). Remarquez également que X doit affecter des ressources pour le compte des clients X (le gestionnaire de fenêtres, votre navigateur Internet, etc) ; l'utilisation de la mémoire de X augmente quand davantage de clients demandent des ressources, telles que pixmaps, et diminue à mesure que vous fermez des applications X. Q: Les applications OpenGL causent une fuite de mémoire considérable sur mon système! R: Si votre noyau utilise la VM -rmap, vous pouvez avoir une fuite de mémoire en raison de l'optimisation de la gestion de la mémoire introduite dans -rmap14a. La VM -rmap a été adoptée par plusieurs distributions courantes et des fuites de mémoire ont été observées dans certains noyaux de distributions. Le problème a été corrigé dans -rmap15e. Si vous pensez que votre système a ce problème, essayez de mettre à jour votre noyau ou faites appel au vendeur de la distribution. Q: Certains applications OpenGL (telles que Quake3 Arena) plantent quand je les démarre sur Red Hat Linux 9. R: Certaines versions du package glibc livrées par Red Hat qui prennent en charge TLS ne gèrent pas correctement l'accès via dlopen() aux librairies utilisant certains modèles TLS. Ce problème se manifeste, par exemple, quand Quake3 Arena utilise dlopen() pour charger la librairie libGL de NVIDIA. Vous devez utilisez au moins glibc-2.3.2-11.9 qui est fournie comme mise à jour par Red Hat. Q: J'ai installé le pilote, mais la case 'Enable 3D Acceleration' est grisée ! Qu'est-ce qui ne va pas ? R: La plupart des applications de configuration fournies avec les distributions ne reconnaissent le pilote accéléré de NVIDIA et ne se mettent donc pas en jour lorsque vous installez le pilote. Si votre pilote a été correctement installé, il devrait fonctionner sans problèmes. Q: Où puis-trouver les tarballs ? R: Sur le site ftp://download.nvidia.com/XFree86/1.0-4496/. Q: Où puis-trouver des anciennes versions de pilotes ? R: Sur le site ftp://download.nvidia.com/XFree86_40/. Q: X ne restaure pas la console VGA lorsqu'il est exécuté sur un téléviseur. Le message d'erreur suivant apparaît dans mon fichier-journal XFree86 : Unable to initialize the XFree86 int10 module; the console may not be restored correctly on your TV. R: Le pilote NVIDIA XFree86 utilise le module XFree86 Int10 pour enregistrer et restaurer l'état de la console sur un téléviseur éteint et ne pourra pas restaurer correctement la console s'il ne peut pas utiliser le module Int10. Si vous créez vous-même XFree86, assurez-vous que le module Int10 a été créé. Si vous utilisez une version de XFree86 fournie par un distributeur Linux et que le module Int10 est manquant, contactez votre distributeur __________________________________________________________________________ (sec-05) COMMENT NOUS CONTACTER __________________________________________________________________________ Un forum de discussion sur les pilotes NVIDIA pour Linux est disponible sur Internet. Pour y accédez, allez à l'adresse www.nvnews.net et suivez les liens "Forum" et "Linux Discussion Area". Vous y trouverez de précieuses informations. Vous pouvez également poser vos questions, répondre aux questions d'autres utilisateurs et consulter les questions et réponses précédentes. Si vous n'y trouvez pas tout ce dont vous avez besoin, vous pouvez contacter NVIDIA à l'adresse : Linux-bugs@NVIDIA.com. Nous vous prions cependant de lire attentivement les FAQ figurant dans ce fichier LISEZMOI et de demander de l'aide au forum de discussion nvnews.net avant de nous envoyer un e-mail. __________________________________________________________________________ (sec-06) AUTRES RESSOURCES __________________________________________________________________________ Linux OpenGL ABI http://oss.sgi.com/projects/ogl-sample/ABI/ NVIDIA Linux HowTo http://www.tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/index.html OpenGL www.opengl.org Le projet XFree86 www.xfree86.org #nvidia (irc.openprojects.net) __________________________________________________________________________ (app-a) APPENDICE A: PROCESSEURS GRAPHIQUES NVIDIA PRIS EN CHARGE __________________________________________________________________________ NOM DU PROCESSEUR NVIDIA ID PCI o RIVA TNT 0x0020 o RIVA TNT2 0x0028 o RIVA TNT2 Ultra 0x0029 o Vanta 0x002C o RIVA TNT2 Modèle 64 0x002D o Aladdin TNT2 0x00A0 o GeForce 256 0x0100 o GeForce DDR 0x0101 o Quadro 0x0103 o GeForce2 MX/MX 400 0x0110 o GeForce2 MX 100/200 0x0111 o GeForce2 Go 0x0112 o Quadro2 MXR/EX/Go 0x0113 o GeForce2 GTS 0x0150 o GeForce2 Ti 0x0151 o GeForce2 Ultra 0x0152 o Quadro2 Pro 0x0153 o GeForce4 MX 460 0x0170 o GeForce4 MX 440 0x0171 o GeForce4 MX 420 0x0172 o GeForce4 MX 440-SE 0x0173 o GeForce4 440 Go 0x0174 o GeForce4 420 Go 0x0175 o GeForce4 420 Go 32M 0x0176 o GeForce4 460 Go 0x0177 o Quadro4 550 XGL 0x0178 o GeForce4 440 Go 64M 0x0179 o Quadro4 NVS 0x017A o Quadro4 500 GoGL 0x017C o GeForce4 410 Go 16M 0x017D o GeForce4 MX 440 avec AGP8X 0x0181 o GeForce4 MX 440SE avec AGP8X 0x0182 o GeForce4 MX 420 avec AGP8X 0x0183 o Quadro4 580 XGL 0x0188 o Quadro4 280 NVS 0x018A o Quadro4 380 XGL 0x018B o GeForce4 448 Go 0x0186 o GeForce4 488 Go 0x0187 o GeForce2 Integrated GPU 0x01A0 o GeForce4 MX Integrated GPU 0x01F0 o GeForce3 0x0200 o GeForce3 Ti 200 0x0201 o GeForce3 Ti 500 0x0202 o Quadro DCC 0x0203 o GeForce4 Ti 4600 0x0250 o GeForce4 Ti 4400 0x0251 o GeForce4 Ti 4200 0x0253 o Quadro4 900 XGL 0x0258 o Quadro4 750 XGL 0x0259 o Quadro4 700 XGL 0x025B o GeForce4 Ti 4800 0x0280 o GeForce4 Ti 4200 avec AGP8X 0x0281 o GeForce4 Ti 4800 SE 0x0282 o GeForce4 4200 Go 0x0286 o Quadro4 980 XGL 0x0288 o Quadro4 780 XGL 0x0289 o Quadro4 700 GoGL 0x028C o GeForce FX 5800 Ultra 0x0301 o GeForce FX 5800 0x0302 o GeForce FX 5600 Ultra 0x0311 o GeForce FX 5600 0x0312 o GeForce FX 5200 Ultra 0x0321 o GeForce FX 5200 0x0322 o Quadro FX 2000 0x0308 o Quadro FX 1000 0x0309 o Quadro FX 500 0x032B Notez que les chips RIVA 128/128ZX sont pris en charge par le pilote open source 'nv' pour XFree86, mais pas par l'ensemble de pilotes accélérés NVIDIA pour Linux. Si vous voulez contrôler les ID de vos PCI et les comparer avec le tableau ci-dessus, utilisez `cat /proc/pci` ou `lspci -n` ; dans le deuxième cas, recherchez les ID de vendeur "10de", par ex. : 02:00.0 Class 0300:10de:0100 (rev 10) __________________________________________________________________________ (app-b) APPENDICE B: CONFIGURATION LOGICIELLE REQUISE __________________________________________________________________________ o Noyau Linux 2.2.12 # cat /proc/version o XFree86 4.0.1 # XFree86 -version o Noyau modutils 2.1.121 # insmod -V Si vous devez construire le module pour le noyau NVIDIA : o binutils 2.9.5 # size --version o GNU make 3.77 # make --version o gcc 2.91.66 # gcc --version Si vous faites la construction à partir de rpms : o spec-helper rpm # rpm -qi spec-helper Toutes les versions stables de noyaux officiels à partir de la 2.2.12 sont prises en charge ; les ve ne sont pas prises en charge, ni les noyaux de la série de développement, comme 2.3.x ou 2.5.x. Vous pouvez télécharger le noyau Linux depuis le site www.kernel.org ou l'un de ses miroirs. binutils et gcc sont accessibles sur www.gnu.org ou l'un de ses miroirs. Si vous utilisez XFree86, mais que vous n'avez pas un fichier /var/log/XFree86.0.log, vous avez probablement une version 3.x de XFree86 et devez la mettre la jour. Si vous configurez XFree86 4.x pour la première fois, il est souvent plus facile de commencer avec l'un des pilotes Open Source fournis avec XFree86 ('nv', 'vga' ou 'vesa'). Une fois que XFree86 fonctionne correctement avec le pilote Open Source, il est plus facile de passer au pilote nvidia. Toutefois, les derniers GPU NVIDIA pourraient ne pas fonctionner avec les anciennes versions du pilote "nv" fourni avec XFree86. Par exemple, le pilote "nv" fourni avec la version 4.0.1 de XFree86 ne reconnaissait pas les processeurs de la famille GeForce2 ni la Quadro2 MXR. Ce problème a toutefois été résolu dans la version 4.0.2 de XFree86 (XFree86 est disponible sur www.xfree86.org). Ces packages de logiciels sont également disponibles auprès de votre distributeur Linux. __________________________________________________________________________ (app-c) APPENDICE C: COMPOSANTS INSTALLÉS __________________________________________________________________________ Les pilotes accélérés NVIDIA pour Linux comprennent les composants suivants (le fichier entre parenthèse est le nom complet du composant après l'installation ; "x.y.z" représentent la version actuelle -- des liens symboliques appropriés sont créés pendant l'installation) : o Un pilote XFree86 (/usr/X11R6/lib/modules/drivers/nvidia_drv.o) ; XFree86 a besoin de ce pilote pour utiliser votre matériel NVIDIA. Le pilote nvidia_drv.o a une compatibilité binaire avec les versions 4.0.1 et supérieures de XFree86. o Un module d'extension GLX pour XFree86 (/usr/X11R6/lib/modules/extensions/libglx.so.x.y.z) ; XFree86 utilise ce module pour le support de glx côté serveur. o Une librairie OpenGL (/usr/lib/libGL.so.x.y.z) ; cette librairie fournit les points d'entrée des API pour tous les appels de fonctions OpenGL et GLX. Elle est reliée à un run-time par les applications OpenGL. o Une librairie principale OpenGL (/usr/lib/libGLcore.so.x.y.z); cette librairie est implicitement utilisée par libGL et libglx. Elle contient la fonctionnalité d'accélération 3D. Vous ne devez pas la charger explicitement dans votre fichier XF86Config - libglx le fait pour vous. o Deux librairies XvMC (X-Video Motion Compensation) : une librairie statique et une librairie partagée (/usr/X11R6/lib/libXvMCNVIDIA.a, /usr/X11R6/lib/libXvMCNVIDIA.so.x.y.z) ; pour de plus amples informations, reportez-vous à (app-p) APPENDICE P: PRISE EN CHARGE DE XVMC. o Un module de noyau (/lib/modules/`uname -r`/video/nvidia.o ou /lib/modules/`uname -r`/kernel/drivers/video/nvidia.o). Ce module de noyau permet un accès de bas niveau à votre matériel NVIDIA pour tous les composants ci-dessus. Il est généralement chargé dans le noyau au démarrage du serveur X et est utilisé par le pilote XFree86 et OpenGL. nvidia.o comporte deux parties : le cœur uniquement binaire et une interface kernel qui doit être spécialement compilée pour la version de noyau utilisée. Remarquez que le noyau Linux ne possède pas une interface binaire consistante comme XFree86 ; il est donc important que cette interface de noyau corresponde à la version du noyau que vous utilisez. Vous pouvez soit la compiler vous même, soit utiliser les binaires précompilés fournis pour les noyaux inclus dans certaines des distributions Linux les plus courantes. o Fichiers d'en-tête OpenGL et GLX (/usr/share/doc/NVIDIA_GLX-1.0/include/GL/gl.h et /usr/share/doc/NVIDIA_GLX-1.0/include/GL/glx.h). Ces fichiers peuvent également être installés dans /usr/include/GL/ en passant l'option "--opengl-headers" dans le fichier .run pendant l'installation. o Librairies principales ELF TLS OpenGL et OpenGL (/usr/lib/tls/libGL.so.x.y.z et /usr/lib/tls/libGLcore.so.x.y.z). Les systèmes Linux utilisant glibc 2.3 ou une version supérieure avec le support tls activé, ont recours à un nouveau mécanisme de TLS (Thread Local Storage). Ce mécanisme est incompatible avec le support TLS précédent de NVIDIA ; par conséquent, des librairies ELF TLS spéciales sont fournies et installées dans /usr/lib/tls/ sur les systèmes utilisant ce mécanisme. Le chargeur du runtime choisira entre les librairies OpenGL installées dans /usr/lib/ et les librairies installées dans /usr/lib/tls/. Remarquez que ce nouveau mécanisme TLS affecte également le module d'extension GLX (libglx.so.x.y.z). Toutefois, vu que le chargeur de XFree86 ne sait pas comment faire le choix entre les librairies tls et non tls, la librairie libglx correcte est automatiquement installée dans /usr/X11R6/lib/modules/extensions/. Vous pouvez déterminer si votre glibc utilise le nouveau mécanisme TLS en tapant la commande : /lib/libc.so.6 | grep "Thread-local storage support included." Cette commande affichera "Thread-local storage support included." sur les systèmes utilisant le nouveau mécanisme TLS. o L'application nvidia-installer (/usr/bin/nvidia-installer) est un outil NVIDIA pour l'installation et la mise à jour des pilotes NVIDIA. Vous trouverez une description détaillée de cet outil dans (sec-03) ÉDITION DE VOTRE FICHIER XF86CONFIG. Des problèmes surviendront si des applications utilisent une version de librairie non correcte. Ceci est le cas quand d'anciennes librairies libGL ou des liens symboliques désuets sont restées dans le système. Si vous pensez que quelque chose ne marche pas dans votre installation, contrôlez si les fichiers suivants sont en place (ce sont tous les fichiers des pilotes accélérés NVIDIA pour Linux, plus leurs liens symboliques): /usr/X11R6/lib/modules/drivers/nvidia_drv.o /usr/X11R6/lib/modules/extensions/libglx.so.x.y.z /usr/X11R6/lib/modules/extensions/libglx.so -> libglx.so.x.y.z /usr/lib/libGL.so.x.y.z /usr/lib/libGL.so.x -> libGL.so.x.y.z /usr/lib/libGL.so -> libGL.so.x /usr/lib/libGLcore.so.x.y.z /usr/lib/libGLcore.so.x -> libGLcore.so.x.y.z /lib/modules/`uname -r`/video/nvidia.o, ou /lib/modules/`uname -r`/kernel/drivers/video/nvidia.o L'installation créera les fichiers /dev : crw-rw-rw- 1 root root 195, 0 Feb 15 17:21 nvidia0 crw-rw-rw- 1 root root 195, 1 Feb 15 17:21 nvidia1 crw-rw-rw- 1 root root 195, 2 Feb 15 17:21 nvidia2 crw-rw-rw- 1 root root 195, 3 Feb 15 17:21 nvidia3 crw-rw-rw- 1 root root 195, 255 Feb 15 17:21 nvidiactl ldconfig peut créer des liens symboliques incorrects lorsque le "nom .so" d'autres librairies entre en conflit avec celui de librairies NVIDIA. Il est conseillé de supprimer ou renommer manuellement les librairies causant des conflits (n'oubliez pas de renommer les librairies pour être sûr que ldconfig ne les verra pas -- en général, l'ajout initial de "XXX" au nom d'une librairie suffit), de réexécuter 'ldconfig' et de vérifier que les liens symboliques ont été correctement créés. Les librairies à l'origine de conflits sont souvent "/usr/X11R6/lib/libGL.so*" et "/usr/X11R6/lib/libGLcore.so*". Après la vérification des librairies, contrôler que l'application utilise les bonnes librairies. Par exemple, pour contrôler que l'application /usr/X11R6/bin/gears utilise les librairies NVIDIA, tapez : $ ldd /usr/X11R6/bin/gears libglut.so.3 => /usr/lib/libglut.so.3 (0x40014000) libGLU.so.1 => /usr/lib/libGLU.so.1 (0x40046000) libGL.so.1 => /usr/lib/libGL.so.1 (0x40062000) libc.so.6 => /lib/libc.so.6 (0x4009f000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4018d000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40196000) libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x401ac000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x401c0000) libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x401cd000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x401d6000) libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x402ab000) libm.so.6 => /lib/libm.so.6 (0x4048d000) libdl.so.2 => /lib/libdl.so.2 (0x404a9000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x404ac000) Observez les fichiers utilisés pour libGL et libGLcore -- si certains d'entre eux ne correspondent pas à des librairies NVIDIA, vous devez soit supprimer ces librairies soit modifier votre chemin d'accès. Si vous ne savez pas à quoi correspondent certains fichiers, lisez les parties consacrées aux pointeurs dans les man pages de "ldconfig" et "ldd". __________________________________________________________________________ (app-d) APPENDICE D: OPTIONS DE XF86CONFIG __________________________________________________________________________ Les options de pilote suivantes sont prises en charge par le pilote XFree86 de NVIDIA : Option "NvAGP" "entier" Pour configurer le support AGP. Valeur possible : 0 : agp désactivé 1 : utilisation, dans la mesure du possible, du support AGP interne de NVIDIA 2 : utilisation d'AGPGART, dans la mesure du possible 3 : utilisation d'un support agp quelconque (essaye AGPGART, puis l'AGP NVIDIA) Notez toutefois que le support AGP interne de NVIDIA ne peut pas fonctionner si AGPGART est compilé statiquement dans votre noyau ou est construit comme un module, mais chargé dans votre noyau (certaines distributions chargent AGPGART dans le noyau lors du boot). Valeur par défaut: 3 (le défaut était 1 jusqu'à 1.0-1251). Option "NoLogo" "booléen" Désactive l'apparition du logo NVIDIA au démarrage de X. Par défaut : le logo apparaît. Option "RenderAccel" "booléen" Active ou désactive l'accélération matérielle de l'extension RENDER. CETTE OPTION EST EN PHASE D'EXPERIMENTATION. VOUS PRENEZ DES RISQUES EN L'ACTIVANT. Il n'existe aucune suite de tests d'exactitude pour l'extension RENDER ; en conséquence, NVIDIA ne peut vérifier que l'accélération de l'extension RENDER fonctionne correctement. Par défaut : accélération matérielle de l'extension RENDER désactivée. Option "NoRenderExtension" "booléen" Désactive l'extension RENDER. Il semble que XFree86 n'offre aucune méthode de désactivation de RENDER, à part la recompilation du serveur X. Heureusement, nous pouvons contrôler ceci depuis le pilote en exportant cette option. C'est utile en profondeur 8 lorsque RENDER utiliserait grande partie de la colormap par défaut. Par défaut : RENDER est activé dans la mesure du possible. Option "UBB" "booléen" Active ou désactive Unified Back Buffer sur tout GPU Quadro (à l'exception de Quadro4 NVS) ; reportez-vous à l'Appendice M pour une description d'UBB. Cette option n'a aucun effet sur les chipsets non Quadro. Par défaut : UBB est activé pour les chipsets Quadro. Option "WindowFlip" "booléen" Active ou désactive le retournement de fenêtre lorsque UBB est activé ; reportez-vous à l'Appendice M pour une description. Cette option n'a aucun effet lorsque UBB est désactivé. Elle peut améliorer les performances des applications 3D. Par défaut : Window flipping est toujours désactivé même si UBB est activé. Option "PageFlip" "booléen" Active ou désactive le retournement de page ; reportez-vous à l'Appendice M pour une description. Par défaut, page flipping est activé. Option "DigitalVibrance" "entier" Active le contrôle de vibrance numérique (DVC). Valeurs comprises entre 0 et 255. Cette fonctionnalité n'est pas disponible sur les produits antérieurs au GeForce2. Valeur par défaut : 0. Option "Dac8Bit" "booléen" Par défaut, la plupart des chipsets Quadro utilisent une table de conversion des couleurs (LUT) de 10 bits ; en réglant cette option sur TRUE, vous pouvez forcer l'utilisation d'une LUT de 8 bits. Par défaut, utilisation d'une LUT de 10 bits, si elle est disponible. Option "Overlay" "booléen" Active l'overlay RGB sur le moniteur de la station de travail. Cette option est uniquement supportée sur les Quadro4 et Quadro FX (Quadro4 NVS exclu) en profondeur 24. Si elle est activée, le serveur indique la propriété de la fenêtre racine SERVER_OVERLAY_VISUALS et GLX rapporte simple et double buffer, recouvrement 16 bits avec Z-buffer. La transparence est donnée par 0x0000 (hex). Aucun support de correction gamma n'existe dans le plan de recouvrement. Cette fonctionnalité est disponible à partir de la version 4.1.0 de XFree86. Les Quadro avec NV17/18 (c.-à-d. 500/550 XGL présente des restrictions supplémentaires, à savoir le recouvrement n'est pas supporté en mode TwinView ou avec des bureaux virtuels de taille supérieure à 2046x2047 en longueur ou en largeur (ex. il ne fonctionnera pas dans les modes 2048x1536). Les Quadro 7xx/9xx et Quadro FX présentent des recouvrement dans ces modes (TwinView ou bureaux virtuels de taille supérieure à 2046x2047), mais le recouvrement avec une baisse substantielle de performances. Par défaut : désactivée. Option "CIOverlay" "booléen" Active l'affichage de l'index des couleurs sur le moniteur de la station de travail, avec les mêmes restrictions que pour l'option "Overlay" ci-dessus. Le serveur permettra l'affichage avec et sans un facteur de transparence. Modes PseudoColor de profondeur 8. L'activation des recouvrements Color Index dans les anciennes versions X serveurs à XFree86 4.3 provoquera la désactivation du fait des bogues figurant dans l'extension RENDER des anciennes versions X serveurs Par défaut : désactivée. Option "TransparentIndex" "entier" Lorsque des recouvrements d'index de couleurs sont activés, cette option permet à l'utilisateur de choisir quel pixel utiliser pour la transparence dans les affichages dotés de pixels transparents. Celle valeur est comprise entre 0 et 255 (Remarque : certaines applications, telles que les Alias/Wavefront Maya, ne fonctionnent correctement que si cette valeur est égale à zéro) Par défaut : 0. Option "OverlayDefaultVisual" "booléen" Lorsque les recouvrements sont utilisés, cette option détermine comme affichage par défaut un recouvrement plaçant la fenêtre racine dans le recouvrement. Elle est déconseillées pour les recouvrements RGB. Par défaut : désactivée. Option "SWCursor" "booléen" Active ou désactive le rendu logiciel du pointeur X. Par défaut : désactivée. Option "HWCursor" "booléen" Active ou désactive le rendu matériel du pointeur X. Par défaut : activée. Option "CursorShadow" "booléen" Active ou désactive l'utilisation d'une ombre avec l'accélération matérielle du pointeur ; il s'agit d'une réplique translucide noire de votre pointeur décalée par rapport au pointeur réel. Cette option n'est disponible que sur le GeForce2 et les produits supérieurs (c.-à-d., tous sauf TNT/TNT2, GeForce 256, GeForce DDR et Quadro). Par défaut, l'ombre du pointeur est désactivée. Option "CursorShadowAlpha" "entier" La valeur alpha à appliquer à l'ombre du pointeur ; n'agit que si CursorShadow est activé. Cette valeur doit être comprise dans la plage [0, 255] -- 0 correspond à une ombre complètement transparente et 255 à une ombre complètement opaque. Valeur par défaut : 64. Option "CursorShadowXOffset" "entier" Le décalage, en pixels, vers la droite de l'ombre par rapport à l'image du pointeur réel ; n'agit que si CursorShadow est activé. Cette valeur doit être comprise dans la plage [0, 32]. Valeur par défaut : 4. Option "CursorShadowYOffset" "entier" Le décalage, en pixels, vers le bas de l'ombre par rapport à l'image du pointeur réel ; n'agit que si CursorShadow est activé. Cette valeur doit être comprise dans la plage [0, 32]. Valeur par défaut : 2. Option "ConnectedMonitor" "chaîne" Permet d'ignorer ce que le module du noyau NVIDIA détecte comme connecté à votre carte vidéo. Ceci peut être utile par exemple, si vous utilisez un commutateur KVM (clavier, vidéo, souris) et que vous êtes commuté à distance au démarrage de X. Dans ce cas, le module du noyau NVIDIA ne peut pas détecter quels périphériques d'affichage sont connectés, et le pilote X NVIDIA assume que vous avez un seul CRT. Les valeurs admises pour cette option sont "CRT" (écran cathodique), "DFP" (écran plat numérique) ou "TV" (téléviseur); Si vous utilisez TwinView, cette option peut être une liste de dispositifs d'affichage, séparés par une virgule ; par ex.: "CRT, CRT" ou "CRT, DFP". REMARQUE : tout périphérique branché dans un connecteur VGA à 15 broches est considéré par le pilote comme un CRT. "DFP" ne doit être utilisé que pour les écrans plats connectés via un port DVI. Par défaut : la chaîne est NULL. Option "UseEdidFreqs" "booléen" Cette option oblige le serveur X à utiliser les paramètres HorizSync et VertRefresh du périphérique d'affichage EDID (en sa présence). L'information de la plage EDID aura la priorité sur les plages HorizSync et VertRefresh spécifiées dans la section Monitor. Si un périphérique d'affichage ne fournit par un EDIT ou que l'EDIT ne précise aucune plage HorizSync ou VertRefresh, le serveur X utilisera par défaut les plages HorizSync et VertRefresh spécifiées dans la section Monitor. Option "IgnoreEDID" "booléen" Pour ignorer les valeurs EDID (Extended Display Identification Data) du moniteur. Les modes requis sont comparés aux valeurs EDID (en leur présence) obtenues de votre moniteur pendant la validation du mode. Certains moniteurs 'mentent' sur leurs capacités. Ignorer ces valeurs fournies par le moniteur peut être utile pour permettre la validation de certains modes, mais peut être dangereux si vous ne savez pas exactement ce que vous faites. Par défaut : utilisation des valeurs EDID. Option "NoDDC" "booléen" Synonyme de "IgnoreEDID" Option "FlatPanelProperties" "chaîne" Demande les propriétés particulières des écrans plats éventuellement connectés sous forme de liste contenant des paires de valeurs séparées par une virgule. Les deux seules propriétés actuellement disponibles sont 'Scaling' et 'Dithering'. Les valeurs admises pour 'Scaling' sont : 'default' (le pilote utilisera le cadrage courant), 'native' (le pilote utilisera le cadrage de l'écran plat, en sa présence), 'scaled' (le pilote utilisera le cadreur NVIDIA dans la mesure du possible ), 'centered' (le pilote centrera l'image dans la mesure du possible) et 'aspect-scaled' (le pilote utilisera le cadreur NVIDIA, mais conserve l'aspect correct). Les valeurs admises pour 'Dithering' sont : 'default' (le pilote décidera quand effectuer le tramage), 'enabled' (le pilote effectuera le tramage chaque fois que possible), et 'disabled' (le pilote n'effectuera jamais le tramage ). Si une propriété quelconque n'est pas spécifiée, la valeur sera 'default'. Une chaîne de propriétés peut ressembler à : "Scaling = centered, Dithering = enabled" Option "UseInt10Module" "booléen" Active l'utilisation du module Int10 XFree86 pour initialiser en douceur toutes les cartes secondaires au lieu de les POSTer par l'intermédiaire du module du noyau NVIDIA. Par défaut : désactivée (le POSTage est effectué via le module du noyau NVIDIA). Option "TwinView" "booléen" Active ou désactive TwinView. Reportez-vous à l'APPENDICE I. Par défaut, TwinView est désactivé. Option "TwinViewOrientation" "chaîne" Contrôle la relation entre les deux périphériques d'affichage en cas d'utilisation de TwinView. Les valeurs possibles sont : "RightOf" "LeftOf" "Above" "Below" "Clone". Reportez-vous à l'APPENDICE I. Par défaut, la chaîne est NULL. Option "SecondMonitorHorizSync" "plage(s) de valeurs" Cette option est similaire à l'entrée du paramètre HorizSync dans la section Monitor, mais se réfère au second moniteur si vous utilisez TwinView. Consultez l'APPENDICE I. Par défaut, aucune plage. Option "SecondMonitorVertRefresh" "plage(s) de valeurs" Cette option est similaire à l'entrée du paramètre VertRefresh dans la section Monitor, mais se réfère au second moniteur si vous utilisez TwinView. Consultez l'APPENDICE I. Par défaut, aucune plage. Option "MetaModes" "chaîne" Cette option décrit la combinaison de modes à utiliser sur chaque moniteur si vous utilisez TwinView. Consultez l'APPENDICE I. Par défaut, la chaîne est NULL. Option "NoTwinViewXineramaInfo" "booléen" Si vous utilisez TwinView, le pilote X NVIDIA fournit normalement une extension Xinerama permettant aux clients X (tels que les gestionnaires de fenêtres) d'appeler XineramaQueryScreens() pour connaître la configuration TwinView actuelle. Cette option permet de désactiver ce comportement, étant donné qu'il peut perturber certains gestionnaires de fenêtre. Par défaut, l'information Xinerama de TwinView est fournie. Option "UseClipIDs" "booléen" Permet l'utilisation de tampons d'id de clips matériels pour améliorer le rendu de dessinables clippés de manière complexe. Cette option n'est prise en charge que sur les chipsets Quadro4 et Quadro FX quand UBB est activé. Son activation met de côté une petite quantité de RAM vidéo pour les surfaces d'ID de clips, généralement inférieures à 2 Mo. Par défaut : désactivée Option "TVStandard" "chaîne" Reportez-vous à (app-j) APPENDICE J : CONFIGURATION TV-OUT. Option "TVOutFormat" "chaîne" Reportez-vous à (app-j) APPENDICE J: CONFIGURATION TV-OUT. Option "TVOverScan" "Valeur décimale comprise entre 0.0 et 1.0" Les valeurs admises sont comprises entre 0.0 et 1.0. Reportez-vous à (app-j) APPENDICE J: CONFIGURATION TV-OUT. Option "Stereo" "entier" Permet des affichages stéréo quad-buffered sur Quadro. Nombre entier indiquant le type de lunettes stéréo utilisées : 1 - Lunettes DDC. Le signal de synchronisation est envoyé aux lunettes via le DDC vers le moniteur. Il y a généralement un câble traversant entre le moniteur et la carte vidéo. 2 - Lunettes "Blueline". Il y a généralement un câble traversant entre le moniteur et la carte vidéo. Les lunettes savent quel œil afficher en fonction de la longueur de la ligne bleue visible en bas de l'écran En utilisant ce mode, la dimension Y de la fenêtre racine sera de un pixel plus courte que demandé. Ce mode ne fonctionne pas avec des fenêtres racines virtuelles de taille supérieure à la fenêtre racine visible (desktop panning). 3 - Onboard stereo support. Ne se trouve généralement que sur les cartes professionnelles. Les lunettes sont connectées via connecteur DIN à l'arrière de la carte vidéo. 4 - TwinView clone mode stéréo (aka " passive " stéréo). Sur les cartes vidéo qui supportent TwinView, l'œil gauche est affiché sur le premier écran et l'œil droit sur le second. Cette option s'utilise généralement avec des projecteurs spéciaux pour obtenir 2 images polarisées visibles à l'aide de lunettes polarisées. Pour utiliser ce mode stéréo, vous devez également configurer TwinView en mode clone en utilisant les même valeurs de résolution, panning offset et panning domains sur chaque écran. Le mode stéréo n'est disponible que sur les cartes Quadro. Les options Stéréo 1, 2 et 3 (aka, " active " stereo) peuvent être utilisées avec TwinView, si tous les modes de chaque métamode ont des valeurs de synchonisation identiques. Consultez l'appendice L (app-l), MODE DE PROGRAMMATION pour savoir si les modes de vos métamodes sont identiques. Il n'est pas nécessaire d'appliquer ces conditions à l'option Stéréo 4 (" passive " stereo). Actuellement, la stéréo peut être "bizarre" sur la Quadro originale (NV10) et le retournement gauche-droite peut être confus. Nous essayons de corriger ce problème pour une version future. Par défaut : le mode stéréo est désactivé. Option "NoBandWidthTest" "booléen" Pendant la validation de mode, le pilote X effectue le test si un mode donné respecte les contraintes de la bande passante mémoire du matériel. Cette option désactive ce test. Par défaut : le test de la bande passante mémoire est effectué. Option "IgnoreDisplayDevices" "chaîne" Cette option dit au module du noyau NVIDIA d'ignorer complètement les classes de périphériques d'affichage indiquées pendant le contrôle des périphériques connectés. Vous pouvez spécifier une liste de "CRT","DFP" et "TV", séparés par une virgule. Par exemple : "IgnoreDisplayDevices" "DFP, TV" empêchera le pilote NVIDIA d'essayer de détecter si des écrans plats ou des téléviseurs sont connectés. Généralement, cette option est inutile ; toutefois, certaines BIOS de vidéo contiennent des informations incorrectes sur les périphériques d'affichage pouvant être connectés ou concernant le port i2c à utiliser pour la détection. Ces erreurs peuvent ralentir considérablement le démarrage de X. Si X est très lent au démarrage, vous pouvez essayer de dire au pilote NVIDIA d'ignorer les périphériques d'affichage qui ne sont pas connectés. REMARQUE : tout périphérique branché dans un connecteur VGA à 15 broches est considéré par le pilote comme un CRT. "DFP" ne doit être utilisé que pour les écrans plats connectés via un port DVI. Option "MultisampleCompatibility" "booléen" Active ou désactive l'utilisation des buffers multisample avant et arrière. Bien que cela exige plus de mémoire, cette opération est nécessaire pour corriger la sortie dans le cas d'un rendu sur les buffers multisample avant et arrière ou d'un FSAA emboutissable. Cette option est nécessaire pour corriger le fonctionnement de SoftImage XSI. Par défaut : un buffer singlemultisample est partagé entre les buffers avant et arrière. __________________________________________________________________________ (app-e) APPENDICE E : DÉFINITION DES VARIABLES D'ENVIRONNEMENT OPENGL __________________________________________________________________________ ANTI-CRÉNELAGE DE LA SCÈNE COMPLÈTE (FSAA) L'anti-crénelage (ou antialiasing) est une technique qui permet d'atténuer les bords "en escalier" des objets graphiques d'une scène. L'anti-crénelage de la scène complète est pris en charge sur les GeForce et les processeurs plus récents. En réglant la variable d'environnement, vous pouvez activer l'anti-crénelage de la scène complète dans n'importe quelle application OpenGL sur ces GPU. Il existe plusieurs méthodes d'anti-crénelage que vous pouvez choisir en réglant correctement la variable d'environnement __GL_FSAA_MODE. Notez que les performances peuvent diminuer avec l'augmentation de nombre d'échantillons prélevés pendant le rendu FSAA. Les tableaux suivants indiquent les valeurs possibles de __GL_FSAA_MODE et leur effet sur les différents processeurs graphiques NVIDIA. __GL_FSAA_MODE GeForce, GeForce2, Quadro et Quadro2 Pro ----------------------------------------------------------------------- 0 FSAA désactivé 1 FSAA désactivé 2 FSAA désactivé 3 Super-échantillonnage 1.5 x 1.5 4 Super-échantillonnage 2 x 2 5 FSAA désactivé __GL_FSAA_MODE GeForce4 MX, GeForce4 4xx Go, Quadro4 380,550,580 XGL et Quadro4 NVS ----------------------------------------------------------------------- 0 FSAA désactivé 1 Multi-échantillonnage bilinéaire 2x 2 Multi-échantillonnage Quincunx 2x 3 FSAA désactivé 4 Super-échantillonnage 2 x 2 5 FSAA désactivé __GL_FSAA_MODE GeForce3, Quadro DCC, GeForce4 Ti, GeForce4 4200 Go, et Quadro4 700,750,780,900,980 XGL ----------------------------------------------------------------------- 0 FSAA désactivé 1 Multi-échantillonnage bilinéaire 2x 2 Multi-échantillonnage Quincunx 2x 3 FSAA désactivé 4 Multi-échantillonnage bilinéaire 4x 5 Multi-échantillonnage gaussien 4x __GL_FSAA_MODE GeForce FX, Quadro FX ----------------------------------------------------------------------- 0 FSAA désactivé 1 Multi-échantillonnage bilinéaire 2x 2 Multi-échantillonnage Quincunx 2x 3 FSAA désactivé 4 Multi-échantillonnage bilinéaire 4x 5 Multi-échantillonnage gaussien 4x REMARQUE : Multi-échantillonnage bilinéaire 2x par Super-échantillonnage 4x et Multi-échantillonnage bilinéaire 4x par Super-échantillonnage 4x ne sont pas disponibles si vous utilisez UBB. FILTRAGE ANISOTROPIQUE DE TEXTURE Le filtrage anisotropique automatique de texture peut être activé en définissant la variable d'environnement __GL_DEFAULT_LOG_ANISO. Les valeurs admises sont : __GL_DEFAULT_LOG_ANISO GeForce/GeForce2/GeForce4 MX Description ----------------------------------------------------------------------- 0 Filtrage anisotropique désactivé 1 Filtrage anisotropique automatique activé __GL_DEFAULT_LOG_ANISO GeForce3/GeForce4 Ti/GeForce FX Description ----------------------------------------------------------------------- 0 Filtrage anisotropique désactivé 1 Filtrage anisotropique minimum 2 Filtrage anisotropique moyen 3 Filtrage anisotropique maximum SYNCHRONISATION VBLANK Le réglage de la variable d'environnement __GL_SYNC_TO_VBLANK sur une valeur différente de zéro forcera glXSwapBuffers à se synchroniser sur la vitesse de rafraîchissement vertical de votre moniteur (effectue un swap uniquement pendant la période de rafraîchissement vertical) sur les GeForce et les produits plus récents (c.-à-d. sur tous les produits à l'exception de TNT/TNT2). Lorqsque __GL_SYNC_TO_VBLANK est utilisé avec TwinView, OpenGL n'est synchronisé qu'avec une seule unité d'affichage ; cela peut des distorsions sur l'unité d'affichage à laquelle qui n'est pas synchronisée avec OpenGL. Vous pouvez utiliser la variable d'environnement __GL_SYNC_DISPLAY_DEVICE pour spécifier l'unité d'affichage à synchroniser avec OpenGL. Vous devez affecter le nom d'une unité d'affichage à cette variable d'environnement ; par exemple "CRT-1". Sur la ligne "Connected display device(s):" de votre fichier-journal XFree86.0, consultez la liste des unités d'affichage installées et leur nom. DÉSACTIVATION DES FONCTIONNALITÉS SPÉCIFIQUES À L'UC Le réglage de la variable d'environnement __GL_FORCE_GENERIC_CPU sur une valeur différente de zéro empêche l'utilisation de fonctionnalités spécifiques à l'UC, telles que MX, SSE ou 3DNOW!. L'utilisation de cette option peut causer une réduction des performances. Elle peut être utile si elle est utilisée en association avec certains logiciels, tels que le logiciel de détection des problèmes de mémoire Valgrind. __________________________________________________________________________ (app-f) APPENDICE F: CONFIGURATION DE L'AGP __________________________________________________________________________ Vous avez le choix entre plusieurs configurations de l'AGP avec le module du noyau NVIDIA : vous pouvez décider d'utiliser le module AGP de NVIDIA (NVAGP)ou le module AGP fourni avec le noyau Linux (AGPGART). Ce dernier est contrôlé via l'option "NvAGP" dans votre fichier XF86Config : Option "NvAgp" "0" ... support AGP désactivé Option "NvAgp" "1" ... utilisation de NVAGP, si possible Option "NvAgp" "2" ... utilisation d'AGPGART, si possible Option "NvAGP" "3" ... tentative d'utilisation d'AGPGART et, en cas d'échec, de NVAGP La valeur par défaut est 3 (jusqu'après la version 1.0-1251, la valeur par défaut était 1). Vous devez utiliser le module AGP qui fonctionne le mieux avec votre chipset AGP. Si vous avez des problèmes de stabilité, essayez de démarrer en désactivant l'AGP et observez si le problème est résolu. Ensuite, vous pouvez faire un essai avec l'un des autres modules AGP. Vous pouvez demander l'état AGP courant à un moment quelconque via l'interface du système de fichiers /proc (consultez l'APPENDICE O : INTERFACE PROC). Si vous voulez utiliser le module AGPGART de Linux, celui-ci doit être compilé avec votre noyau et peut être soit lié statiquement soit construit en tant que module. Le support AGP NVIDIA ne peut pas être utilisé si AGPGART est chargé dans le noyau. Il est conseillé de compiler AGPGART comme module et de s'assurer qu'il n'est pas chargé si vous utilisez l'AGP NVIDIA . Notez également que si vous changez les pilotes AGP, vous devez généralement redémarrer le système avant que les changement ne prennent effet. Les chipsets AGP suivants sont pris en charge par l'AGP NVIDIA ; pour tous les autres chipsets, il est conseillé d'utiliser le module AGPGART. o Intel 440LX o Intel 440BX o Intel 440GX o Intel 815 ("Solano") o Intel 820 ("Camino") o Intel 830 o Intel 840 ("Carmel") o Intel 845 ("Brookdale") o Intel 845G o Intel 850 ("Tehama") o Intel 860 ("Colusa") o AMD 751 ("Irongate") o AMD 761 ("IGD4") o AMD 762 ("IGD4 MP") o VIA 8371 o VIA 82C694X o VIA KT133 o VIA KT266 o RCC 6585HE o Micron SAMDDR ("Samurai") o Micron SCIDDR ("Scimitar") o nForce AGP o nForce 2 AGP o ALi 1621 o ALi 1631 o ALi 1647 o ALi 1651 o ALi 1671 o SiS 630 o SiS 633 o SiS 635 o SiS 645 o SiS 730 o SiS 733 o SiS 735 o SiS 745 Si vous avez des problèmes de stabilité de l'AGP, vous devez savoir ce qui suit : o Support pour l'extension de format de page sur les processeurs Athlon Certains noyaux Linux ont un bogue d'attribut de cache causant des conflits avec le cache spéculatif avancé dans les nouveaux processeurs de la famille AMD d'Athlon (AMD Athlon XP, AMD Athlong 4, AMD Athlon MP et AMD Duron Modèles 6 et supérieurs).. Ce bogue de noyau se manifeste généralement en cas d'utilisation intensive de l'accélération graphique 3D avec une carte graphique AGP. Les distributions Linux basées sur le noyau 2.4.19 ou suivant *doivent* incorporer le correctif. Pour les noyaux précédents, l'utilisateur doit s'assurer lui-même qu'une petite portion du cache spéculatif avancé est désactivé (normalement en appliquant un patch sur le noyau) et qu'une option de boot est spécifiée de manière à appliquer l'ensemble du correctif. Le pilote Nvidia désactive automatiquement la petite portion de cache spéculatif avancé pour les processeurs AMD affectés sans besoin de patcher le noyau ; il peut même être utilisé sur les noyaux qui contiennent déjà le correctif. De plus, pour les noyaux plus anciens, l'utilisateur accomplit la portion de l'option de boot du correctif en désactivant explicitement les pages 4Mo. Il peut le faire depuis la ligne de commande du boot en tapant : mem=nopentium Ou en ajoutant la ligne suivante à etc/lilo.conf : append = "mem=nopentium" o Réglage du drive strength AGP dans le BIOS (cartes mères VIA) La plupart des cartes mères VIA permettent le réglage du drive strength AGP dans le BIOS système. Le réglage de cette option a de fortes répercussions sur la stabilité du système. La plage entre 0xEA et 0xEE semble être la meilleure pour le matériel NVIDIA. Le réglage d'un quartet quelconque sur 0xF cause généralement de sérieux problèmes de stabilité. Si vous décidez d'expérimenter ce réglage, vous le faites à vos risques et devez savoir que si vous utilisez des valeurs incorrectes le système pourrait ne plus être bootable tant que vous ne l'avez pas réinitialisé (avec une carte graphique PCI ou en réinitialisant le BIOS à ses valeurs par défaut). o Version du BIOS système Vérifiez que vous avez la dernière version du BIOS système fournie par le fabricant de la carte. o Vitesse AGP Si la vitesse de l'AGP utilisée cause des verrouillages, vous pouvez diminuer cette vitesse en procédant comme suit : Extrayez le fichier .run : sh NVIDIA-Linux-x86-1.0-4496-pkg1.run --extract-only cd NVIDIA-Linux-x86-1.0-4496-pkg1/usr/src/nv/ Éditez ensuite os-registry.c en apportant les modifications suivantes : - static int NVreg_ReqAGPRate = 7; + = 4; /* force la vitesse d'AGP à 4x */ ou + static int NVreg_ReqAGPRate = 2; /* force la vitesse d'AGP à 2x */ ou + static int NVreg_ReqAGPRate = 1; /* force la vitesse d'AGP à 1x */ puis supprimez les deux leading underscores : - { "__ReqAGPRate", &NVreg_ReqAGPRate }, + { "ReqAGPRate", &NVreg_ReqAGPRate }, Enfin, recompilez et chargez le nouveau module de noyau. Sur les cartes mères Athlon dotées du chipset VIA KX133 ou 694X (par ex. la carte mère ASUS K7V), les pilotes NVIDIA utilisent pas défaut le mode AGP 2x pour palier à l'insuffisance du drive strength sur l'un des signaux. Vous pouvez forcer AGP 4x en réglant NVreg_EnableVia4x sur 1, toutefois le système risque de devenir instable. Sur les chipsets ALi1541 et ALi1647 , les pilotes NVIDIA empêchent AGP de corriger les problèmes de timing et d'intégrité des signaux. Vous pouvez forcer l'activation de AGP sur ces chipsets en réglant NVreg_EnableALiAGP à 1. Le système peut toutefois devenir instable. __________________________________________________________________________ (app-g) APPENDICE G: PROBLÈMES SPÉCIFIQUES AUX SYSTÈMES ALI __________________________________________________________________________ Les astuces suivantes peuvent vous aider à corriger les problèmes de stabilité des systèmes ALI : o Désactivez TURBO AGP MODE dans le BIOS. o Si vous utilisez P5A, effectuez une mise à jour vers le BIOS 1002 bêta 2. o Si vous utilisez 1007, 1007A ou 1009, réglez le temps de récupération E/S sur 4 cycles. o AGP est désactivé par défaut sur certains chipsets ALi (ALi1541, ALi1647) pour corriger les sérieux problèmes de stabilité du système avec ces chipsets. Reportez-vous aux commentaires sur NVreg_EnableALiAGP dans os-registry.c pour force r AGP. __________________________________________________________________________ (app-h) APPENDICE H: PROBLÈMES SPÉCIFIQUES AUX SYSTÈMES TNT __________________________________________________________________________ __________________________________________________________________________ La plupart des problèmes liés aux cartes SGRAM/SDRAM TNT devraient être résolus. Même si ceci est rare, il peut toutefois arriver que le pilote ne fonctionne pas parce que le BIOS installé sur votre carte vidéo n'est pas le bon. Si ce pilote échoue, procédez comme suit : o Observez votre moniteur au démarrage du système. Le premier écran (qui reste affiché très peu de temps), indique le type de mémoire vidéo de votre carte, qui peut être une SGRAM ou une SDRAM. o Éditez le fichier "os-registry.c" depuis les sources du module du noyau. Recherchez la variable "NVreg_VideoMemoryTypeOverride" et entrez la valeur correspondant à votre type de mémoire (valeur numérique sur la ligne juste au dessus de la variable). o Cette variable n'étant généralement pas utilisée, remplacez "#if 0", qui se trouve environ 10 lignes au-dessus de la variable, par "#if 1". o Reconstruisez et réinstallez le nouveau pilote ("make") __________________________________________________________________________ (app-i) APPENDICE I: CONFIGURATION DE TWINVIEW __________________________________________________________________________ TwinView n'est pris en charge que sur les GPU NVIDIA supportant le double affichage, tels que les GeForce2 MX, GeForce2 Go, Quadro2 MXR, Quadro2 Go et tous les GeForce4 ou Quadro4. Demandez au vendeur de votre carte vidéo si elle prend en charge TwinView. TwinView permet à deux écrans (écrans plats numériques, CRT, et TV) d'afficher le contenu d'un seul écran X dans une configuration arbitraire quelconque. Cette méthode d'affichage multiple offre plusieurs avantages par rapport à d'autres techniques (telles que Xinerama): o Utilisation d'un seul écran X. Le pilote NVIDIA dissimule toutes les informations du serveur X concernant l'affichage multiple ; le serveur X considère qu'un seul écran est utilisé. o Les deux écrans partagent la même mémoire image. Par conséquent, toutes les fonctionnalités présentes sur un seul écran (par ex. accélération OpenGL) sont disponibles sur TwinView. o Aucune autre information n'est nécessaire pour l'émulation d'un seul bureau. Si vous souhaitez utilisez chaque périphérique d'affichage comme écran X distinct, reportez-vous à (app-r) APPENDICE R : CONFIGURATION D'ÉCRANS X MULTIPLES SUR UNE CARTE. OPTIONS TWINVIEW DE XF86CONFIG Pour activer TwinView, vous devez ajouter les options suivantes dans la section Device de votre fichier XF86Config : Option "TwinView" Option "SecondMonitorHorizSync" "" Option "SecondMonitorVertRefresh" "" Option "MetaModes" "" Vous pouvez également spécifier les options suivantes (ces options sont facultatives) : Option "TwinViewOrientation" "" Option "ConnectedMonitor" "" Chacune de ces options est décrite plus en détails ci-dessous : o TwinView Cette option est nécessaire pour activer TwinView ; si elle n'a pas été ajoutée, toutes les options TwinView seront ignorées. o SecondMonitorHorizSync, SecondMonitorVertRefresh Ces deux options spécifient les contraintes du second moniteur. Les valeurs entrées respectent la même convention que celles de "HorizSync" et "VertRefresh" dans la section Monitor. Comme décrit dans la man page XF86Config, les plages peuvent être une liste de valeurs distinctes séparées par un virgule et/ou deux valeurs distinctes séparées par un tiret. HorizSync est exprimé en kHz et VertRefresh en Hz. Si vous pouvez compter sur les EDIT des périphériques d'affichage, utilisez l'option "UseEdidFreqs" au lieu des ces options (vous trouverez une description de l'option "UseEdidFreqs" dans l'APPENDICE D). o MetaModes Un MetaMode décrit le mode à utiliser sur chaque écran à un moment donné. Les MetaModes listent les combinaisons de modes et la séquence dans laquelle ils doivent être utilisés. Lorsque le pilote NVIDIA dit à X quels sont les modes disponibles, il lui communique en fait le bounding box minimum du MetaMode, alors que le mode "per display device" est maintenu à l'intérieur du pilote. Dans la syntaxe des MetaModes, les modes contenus à l'intérieur d'un MetaMode sont séparés par une virgule et les MetaModes multiples sont séparés par des points-virgules. Par exemple : ", ; , " Où est le nom du mode à utiliser sur l'écran 0 simultanément à utilisé sur l'écran 1. Une commutation de mode causera ensuite l'utilisation de sur l'écran 0 et de sur l'écran 1. Voici une entrée réelle de MetaMode extraite du fichier d'exemple de configuration XF86Config : Option "MetaModes" "1280x1024,1280x1024; 1024x768,1024x768" Si vous voulez qu'un écran ne soit pas actif pour un MetaMode donné, vous pouvez utiliser "NULL" comme nom du mode ou simplement omettre complètement le nom du mode : "1600x1200, NULL; NULL, 1024x768" ou "1600x1200; , 1024x768" Facultativement, les noms de modes peuvent être suivis par une description de l'offset permettant de contrôler la position des écrans dans l'espace d'affichage virtuel ; par ex. : "1600x1200 +0+0, 1024x768 +1600+0; ..." Les descriptions de l'offset respectent les conventions utilisées dans l'option de ligne de commande "-geometry" de X ; les offsets positifs et négatifs sont valides, mais les valeurs d'offsets négatives ne sont pas admises si la taille de l'écran virtuel a été spécifiées dans le fichier XF86Config. Si aucun offset n'est spécifié pour un MetaMode, les offsets seront calculés en fonction de la valeur entrée pour l'option TwinViewOrientation (voir ci-dessous). Notez que si des offsets sont indiqués pour l'un quelconque des modes dans un seul MetaMode, ces offsets seront appliqués à tous les modes à l'intérieur de ce MetaMode ; dans ce cas, le système assumera que les offsets sont +0+0 s'ils n'ont pas été spécifiés. Si la taille de l'écran virtuel n'est pas entrés de manière explicite, elle sera calculée comme étant le bounding box de tous les bounding boxes des MetaModes. Les MetaModes dont le bounding box est plus grand que la taille de l'écran virtuel entrée de manière explicite seront rejetés. Il est également possible de modifier une chaîne de MetaMode en spécifiant un "Panning Domain" ; par ex. : "1024x768 @1600x1200, 800x600 @1600x1200" Un "Panning Domain" est la zone dans laquelle peut se déplacer la fenêtre d'affichage d'un écran pour suivre la souris. Avec TwinView, le panoramique est effectué sur deux niveaux : le premier est un panoramique de la fenêtre d"affichage d'un seul écran à l'intérieur de son panning domain, tant que la fenêtre est contenue dans le bounding box du MetaMode. Dès que la souris sort du bounding box du MetaMode, un panoramique est effectué sur l'intégralité de ce MetaMode (c.-à.d. sur tous les périphériques d'affichage) pour suivre la souris dans l'écran virtuel. Notez que les panning domains de chaque périphérique d'affichage sont accrochés par défaut dans la position de leurs fenêtres d'affichage, de sorte ces fenêtres d'affichage restent par défaut "verrouillées" ensemble et n'effectuent que le second type de mouvement. L'utilisation des panning domains est surtout utile pour éliminer les zones mortes de l'écran virtuel, qui sont inaccessibles lorsque les écrans ont différentes résolutions. Par exemple : "1600x1200, 1024x768" donne une région inaccessible au-dessous de l'écran de 1024x768. En spécifiant, pour le second écran, un panning domain de : "1600x1200, 1024x768 @1024x1200" il est possible d'accéder aux zones mortes et de faire un panoramique vers le haut et vers le bas de la fenêtre d'affichage 1024x768 dans le panning domain de 1024x1200 . Il est possible d'associer des offsets à des panning domains pour positionner les panning domains dans l'espace d'affichage virtuel (notez que l'offset décrit le panning domain et n'agit que sur la fenêtre d'affichage en l'obligeant à être contenue à l'intérieur du panning domain). L'exemple suivant décrit deux modes, ayant chacun un panning domain de 1900 pixels de largeur, avec le second écran placé au-dessous du premier : "1600x1200 @1900x1200 +0+0, 1024x768 @1900x768 +0+1200" Si rien n'est spécifié pour les MetaModes, le pilote X utilisera les modes indiqués dans la sous-section "Display" correspondante pour essayer de placer des modes adéquats sur chaque écran. o TwinViewOrientation Cette option détermine la position du second écran par rapport au premier écran X virtuel, si aucun offset n'a été spécifié dans les MetaModes. Les valeurs admises sont : "RightOf" (par défaut) "LeftOf" "Above" "Below" "Clone" Si vous avez entré "Clone", les deux écrans auront un offset de 0,0. o ConnectedMonitor Cette option permet d'ignorer ce que le module du noyau NVIDIA détecte comme étant connecté à votre carte vidéo. Elle peut être utile, par exemple, si l'un de vos écrans ne supporte pas la détection DDC (Display Data Channel). Les valeurs admises pour cette option sont "CRT" (écran cathodique), "DFP"(écran plat numérique) ou "TV" (téléviseur). Si vous utilisez TwinView, cette option peut être une liste d'écrans séparés par une virgule ; par ex. :"CRT, CRT" ou "CRT, DFP". Comme dans le fichier XF86Config, les espaces sont ignorés et le texte entré est insensible à la casse. FAQ SUR TWINVIEW : Q: Mon second moniteur ne fonctionne pas. Quel est le problème ? R: Les moniteurs non compatibles DDC (Display Data Channel) ne peuvent pas être détectés par votre carte NVIDIA (la plupart des anciens moniteurs ne sont pas compatibles). Dans ce cas, vous devez dire explicitement au pilote XFree86 de NVIDIA que vous êtes connecté, en utilisant l'option "ConnectedMonitor" ; par ex. : Option "ConnectedMonitor" "CRT, CRT" Q: Les gestionnaires de fenêtres sauront-ils placer les fenêtres correctement (par ex. en évitant de les placer à cheval entre deux écrans ou dans des zones inaccessibles du bureau virtuel) ? R: Oui. Le pilote X de NVIDIA fournit une extension Xinerama qui permet aux clients X (comme les gestionnaires de fenêtres) d'appeler XineramaQueryScreens() pour connaître la configuration TwinView courante. Notez que le protocole Xinerama ne peut pas informer les clients des changements de configuration. Aussi, si vous changez de MetaMode, votre gestionnaire de fenêtres ne le saura pas et continuera à se baser sur votre ancienne configuration. En utilisant l'extension Xinerama avec l'extension XF86VidMode, les gestionnaires de fenêtres devraient être capables de déterminer la configuration TwinView à tout moment. Malheureusement, certains gestionnaires de fenêtres ne savent pas interpréter les informations fournies par XineramaQueryScreens() ; pour corriger ce problème, vous pouvez désactiver la communication de la position des écrans TwinView à l'aide de l'option "NoTwinViewXineramaInfo" dans le fichier XF86Config (reportez-vous à l'Appendice D). N'oubliez pas que le pilote NVIDIA ne peut pas fournir l'extension Xinerama si l'extension Xinerama de XFree86 est déjà utilisée. L'extension Xinerama du pilote NVIDIA ne pourra pas être installée si Xinerama a été explicitement spécifié dans le fichier XF86Config ou sur la ligne de commande de XFree86. Par conséquent, vérifiez que le fichier journal /var/log/XFree86.0. de XFree86 ne contient pas : (++) XineramR: enabled si vous voulez que le pilote NVIDIA fournisse l'extension Xinerama dans TwinView. Une autre solution consiste à utiliser les panning domains pour éliminer les zones inaccessibles de l'écran virtuel (reportez-vous à la description des MetaModes ci-dessus). Une troisième solution est d'utiliser deux écrans X distincts, plutôt que TwinView. Reportez-vous à (app-r) APPENDICE R: CONFIGURATION D'ÉCRANS X MULTIPLES SUR UNE CARTE; Q: Pourquoi est-il impossible d'obtenir une résolution de 1600x1200 sur le second écran quand j'utilise un GeForce2 MX ? R: Sur le GeForce2 MX, le second écran est un écran plat numérique et le signal Pixel Clock (horloge pixel) du second écran a une fréquence de seulement 150 MHz, ce qui limite effectivement la résolution du second écran à environ 1280x1024 (le XFree86 Video Timings HOWTO explique comment les fréquences du signal Pixel Clock limitent les modes programmables). Cette contrainte n'est pas présente sur les GeForce4 et GeForce FX - la fréquence maximum du pixel clock est la même pour les deux écrans. Q: Le recouvrement vidéo fonctionne-t-il sur les écrans ? R: Le recouvrement vidéo matériel fonctionne uniquement sur le premier écran. Actuellement, la solution consiste à utiliser des blitters (transferts de blocs de bits transparents) vidéo au lieu de TwinView. Q: Comment les dimensions de l'écran virtuel sont-elles déterminées dans TwinView ? R: Après la validation de tous les modes demandés et le calcul des offsets pour chaque fenêtre d'affichage des MetaModes, le pilote NVIDIA calcule le bounding box des panning domains pour chaque MetaMode. Il détermine ainsi la largeur et la hauteur maximum du bounding box. Notez que la largeur virtuelle et la hauteur virtuelle peuvent être déterminées par différents MetaModes. Par exemple, si vous avez entré la chaînes suivante : "1600x1200,NULL; 1024x768+0+0, 1024x768+0+768" la taille de l'écran virtuel obtenu sera de 1600 x 1536. Q: Puis-je jouer à un jeu plein écran sur les deux écrans ? R: Oui. Tandis que les détails de la configuration varient d'un jeu à un autre, l'idée de base est qu'un MetaMode présente X avec un mode dont la résolution est le bounding box des fenêtres d'affichage pour ce MetaMode. Par exemple : Option "MetaModes" "1024x768,1024x768; 800x600,800x600" Option "TwinViewOrientation" "RightOf" produit deux modes : un avec un résolution de 2048x768 et un avec une résolution de 1600x600. Des jeux tels que Quake 3 Arena utilisent l'extension VidMode pour rechercher les résolutions des modes disponibles. Pour configurer Quake 3 Arena afin d'utiliser le MetaMode ci-dessus, ajoutez les paramètres suivants dans votre fichier q3config.cfg : seta r_customaspect "1" seta r_customheight "600" seta r_customwidth "1600" seta r_fullscreen "1" seta r_mode "-1" Notez que la configuration ci-dessus ne détermine pas de mode ayant une résolution de 800x600 (souvenez-vous que le MetaMode "800x600, 800x600" a un résolution de 1600x600") ; par conséquent, si vous configurez Quake 3 Arena pour utiliser une résolution de 800x600, il s'affichera dans le coin inférieur gauche de l'écran et le reste de l'écran sera grisé. Pour avoir également à disposition des modes head simples, vous devez entrer une chaîne de Metamode du type suivant : "800x600,800x600; 1024x768,NULL; 800x600,NULL; 640x480,NULL" L'objectif de ce document n'est pas de fournir une description précise de la configuration à utiliser pour chaque jeu. Toutefois les exemples cités et les nombreuses informations disponibles sur le web devraient vous mettre sur la bonne voie. __________________________________________________________________________ (app-j) APPENDICE J: CONFIGURATION TV-OUT __________________________________________________________________________ Les cartes vidéo basées sur les GPU NVIDIA avec un connecteur de sortie TV (S-Video) peut être utilisées pour la connexion d'un téléviseur, exactement comme s'il s'agissait d'un écran cathodique ou d'un écran plat numérique. Le téléviseur peut être utilisé seul ou (à l'aide de cartes vidéo appropriées) avec un autre écran dans une configuration TwinView. Si le téléviseur est le seul écran connecté à votre carte vidéo, il sera utilisé comme écran principal au démarrage de votre système (le bureau s'affichera sur le téléviseur exactement comme s'il s'agissait d'un écran cathodique). Pour utiliser votre téléviseur avec X, vous devez faire très attention aux paramètres suivants dans votre fichier XF86Config : o VertRefresh et HorizSync dans la section Monitor ; les valeurs affectées doivent être valables pour votre téléviseur. Valeurs généralement correctes : HorizSync 30-50 VertRefresh 60 o Modes dans la section Screen ; les modes admis pour votre encodeur TV seront indiqués en clair dans le fichier journal de XFree86.0. (générés à l'aide la commande `startx -- -logverbose 5`) quand X est exécuté sur un téléviseur. Certains modes peuvent être limités à certains standards TV, mais ceci sera indiqué dans le fichier journal XFree86.0. En général, au moins 800x600 et 640x480 sont supportés. o Il faut ajouter l'option "TVStandard" dans votre section Screen ; les valeurs admises sont : "PAL-B" : Belgique, Danemark, Finlande, Allemagne, Guinée, Hong Kong, Inde, Indonésie, Italie, Malaysia, Pays Bas, Norvège, Portugal, Singapour, Espagne, Suède et Suisse "PAL-D" : Chine et Corée du Nord "PAL-G" : Danemark, Finlande, Allemagne, Italie, Malaisie, Pays Bas, Norvège, Portugal, Espagne, Suède et Suisse "PAL-H" : Belgique "PAL-I" : Hong Kong et Royaume-Uni "PAL-K1" : Guinée "PAL-M" : Brésil "PAL-N" : France, Paraguay et Uruguay "PAL-NC" : Argentine "NTSC-J" : Japon "NTSC-M" : Canada, Chili, Colombie, Costa Rica, Équateur, Haïti, Honduras, Mexique, Panama, Porto Rico, Corée du Sud, Taiwan, États-Unis et Venezuela. La ligne dans votre fichier XF86Config devrait ressembler à : Option "TVStandard" "NTSC-M" Si aucun TVStandard n'est spécifié ou que la valeur indiquée est incorrecte, "NTSC-M" sera utilisé par défaut. Remarque : si votre pays ne figure pas dans la liste ci-dessus, choisissez le pays le plus proche de chez vous. o L'option "ConnectedMonitor" peut être utilisée pour dire à X d'utiliser le téléviseur comme écran. Cette option n'est utile que si votre carte vidéo ne détecte pas le téléviseur ou si vous utilisez un écran cathodique CRT (ou un écran plat numérique) comme écran de démarrage, mais que vous voulez rediriger X sur le téléviseur. La ligne dans votre fichier XF86Config doit être : Option "ConnectedMonitor" "TV" o L'option "TVOutFormat" peut être utilisée pour forcer SVIDEO ou la sortie COMPOSITE. Sans cette option, le pilote détecte automatiquement le format de sortie. Malheureusement, cette détection n'est pas toujours exacte. Le format de sortie peut être forcé à l'aide des options : Option "TVOutFormat" "SVIDEO" ou Option "TVOutFormat" "COMPOSITE" o L'option "TVOverScan" peut être utilisée pour activer Overscan s'il est supporté. Les valeurs admises sont des valeurs décimales de 1.0 (overscan maximum pour que les images soient les plus grandes possibles) à 0.0 (overscan désactivé, pour que les images soient les plus petites possibles). Par défaut, l'overscan est désactivé(0.0). À l'heure actuelle, l'overscan n'est disponible que sur le GeForce4 et les processeurs graphiques plus récents avec encodeurs TV NVIDIA ou Conexant. Le pilote NVIDIA XFree86 ne restaura correctement la console avec les versions XFree86 antérieures à la version 4.3, si un téléviseur est utilisé comme console. Cela est dû aux incompatibilités binaires entre les modules XFree86 int10. Si votre console est un téléviseur, nous vos conseillons de passer à la version XFree86 4.3. _ __________________________________________________________________________ (app-k) APPENDICE K: CONFIGURATION D'UN ORDINATEUR PORTABLE __________________________________________________________________________ INSTALLATION ET CONFIGURATION L'installation et la configuration de l'ensemble de pilotes accélérés NVIDIA pour Linux sur un ordinateur portable est similaire à celle d'un environnement d'ordinateur de bureau à part quelques différences mineures citées ci-dessous. A partir de la version 1.0-2802, les informations nécessaires à l'initialisation de l'écran plat interne sont générées par défaut à partir des données stockées dans le BIOS vidéo. Vous pouvez désactiver cette fonction en définissant l'option du noyau "SoftEDIDs" sur 0. Si "SoftEDIDs" est désactivée, les données enregistrées dans le programme seront choisies dans un tableau en fonction de la valeur entrée pour l'option de noyau "Mobile". L'option de noyau "Mobile" peut être réglée sur l'une des valeurs suivantes : 0xFFFFFFFF : laisse au module du noyau le soin de détecter automatiquement la valeur correcte. 1 : ordinateurs portables Dell 2 : ordinateurs portables Toshiba, à l'exception du Compal 3 : autres ordinateurs portables 4 : ordinateurs portables Compal Toshiba 5 : ordinateurs portables Gateway Là encore, l'option de noyau "Mobile" n'est nécessaire que si SoftEDIDs est désactivé ; si SoftEDIDs est utilisé, il est plus sûr de laisser au module du noyau le soin de détecter automatiquement la valeur correcte (comportement par défaut). Si vous devez modifier l'une de ces options, vous pouvez : o Éditer os-registry.c dans le répertoire usr/src/nv/ du fichier .run. o Entrer la valeur sur la ligne de commande modprobe (par ex. : `modprobe nvidia NVreg_SoftEDIDs=0 NVreg_Mobile=3`) o Ajouter une ligne "options" dans votre fichier de configuration du module ; en général, /etc/modules.conf (ex. : "options nvidia NVreg_Mobile=5") FONCTIONNALITÉS ADDITIONNELLES TWINVIEW Tous les chipsets NVIDIA pour ordinateurs portables supportent TwinView. La configuration de TwinView est la même sur un ordinateur portable et un ordinateur de bureau (consultez l'APPENDICE I ci-dessus). Notez cependant que dans une configuration TwinView utilisant l'écran plat interne de l'ordinateur portable et un écran cathodique externe, l'écran cathodique sera l'écran principal (spécifiez son HorizSync et VertRefresh dans la section Monitor de votre fichier XF86Config) et l'écran plat sera le secondaire (spécifiez son HorizSync et VertRefresh dans les options SecondMonitorHorizSync et SecondMonitorVertRefresh ). Vous pouvez également utiliser l'option UseEdidFreqs pour l'acquisition de HorizSync et VertRefresh de l'EDID de chaque écran sans besoin d'avoir recours au fichier XF86Config (mais vous devez être sûr des EDID de vos écrans - reportez vous à la description de l'option UseEdidFreqs dans l'APPENDICE D). BASCULEMENT ENTRE LES ÉCRANS PAR TOUCHE CLAVIER En plus de TwinView, les chipsets NVIDIA pour ordinateurs portables ont la capacité de réagir à un événement LCD/CRT généré sur le clavier, en basculant entre chacun des écrans connectés et chaque combinaison possible des écrans connectés (notez que seulement 2 écrans peuvent être utilisés en même temps). TwinView, tel que configuré dans votre fichier XF86Config et la fonctionnalité touche clavier sont mutuellement exclusifs -- si vous activez TwinView dans votre fichier XF86Config, le pilote X NVIDIA ignorera les événements LCD/CRT généré sur le clavier. Un autre aspect important de la fonctionnalité de basculement par touche clavier est la possibilité de connecter et déconnecter dynamiquement les écrans à/de votre ordinateur portable sans besoin de redémarrer X. Cette fonctionnalité pose toutefois le problème de savoir comment valider et déterminer les modes à programmer sur chacun des périphériques d'affichage. D'abord, l'option UseEdidFreqs est extrêmement précieuse parce qu'elle permet de retrouver les vitesses de rafraîchissement horizontal et de rafraîchissement vertical de chaque écran à partir de l'EDID des écrans -- sinon, la sémantique du contenu de la section Monitor changerait constamment avec chaque événement généré par touche clavier. Au démarrage de X ou quand un changement est détecté dans la liste des écrans connectés, une nouvelle liste de séquences de touches est construite -- elle indique quels écrans seront utilisés avec chaque événement clavier. Après un événement clavier, l'état de la touche suivante dans la séquence est choisi. Chaque mode demandé dans le fichier XF86Config est validé en fonction des contraintes de chaque écran et les modes qui en résultent deviennent disponible pour cet écran. Si plusieurs écrans doivent être actifs en même temps, les modes de chaque écran sont accouplés ; si les écrans n'ont pas la même résolution, le système recherche la meilleure correspondance et un panoramique sera effectué sur l'écran ayant la plus basse résolution à l'intérieur de la résolution de l'autre écran. Après une commutation VT quittant X, la console VGA sera toujours restaurée sur l'écran utilisé pour le démarrage de X. De même, en cas de commutation VT retournant dans X, la configuration utilisée sera la même qu'en cas de commutation VT quittant X, indépendamment des commandes clavier LCD/CRT activées quand X n'était pas accessible. MODES NON STANDARD SUR LES ÉCRANS LCD Certains utilisateurs n'arrivent pas à programmer un mode 1400x1050 (la résolution de certains écrans LCD d'ordinateurs portables). La base de données des modes par défaut de la version 4.0.3 de XFree86 offre plusieurs modes 1400x1050 supplémentaires, mais si vous utilisez une version antérieure de XFree86, vous pouvez utiliser un modeline du type : # -- 1400x1050 -- # 1400x1050 @ 60Hz, 65.8 kHz hsync Modeline "1400x1050" 129 1400 1464 1656 1960 1050 1051 1054 1100 +HSync +VSync PROBLÈMES CONNUS CONCERNANT LES ORDINATEURS PORTABLES o Le basculement LCD/CRT par touche clavier ne fonctionne pas sur les ordinateurs portables Toshiba, exception faite du Satellite 3000. o TwinView ne fonctionne pas sur l'ordinateur portable Toshiba Satellite 2800. o Le recouvrement vidéo ne fonctionne que sur l'écran principal (où vous avez démarré X. Par exemple, si vous démarrez X sur l'écran LCD interne, lancez une application vidéo utilisant le recouvrement vidéo (utilisant l'adaptateur "Video Overlay" via l'extension XV), puis basculez à l'aide d'une touche clavier pour ajouter un second écran, la vidéo n'apparaîtra pas sur le second écran. Pour corriger ce problème, vous pouvez configurer l'application vidéo de manière à utiliser l'adaptateur "Video Blitter" via l'extension XV (toujours disponible) ou basculer à l'aide d'une touche clavier sur l'écran devant utiliser le recouvrement vidéo *avant* de démarrer X. __________________________________________________________________________ (app-l) APPENDICE L: MODES DE PROGRAMMATION __________________________________________________________________________ L'ensemble de pilotes accélérés NVIDIA pour Linux prend en charge tous les modes VGA et VESA standard, ainsi que la plupart des lignes de modes personnalisées par l'utilisateur ; les modes double-scan sont pris en charge par tous les matériels. En général, les modes que vous pouvez utiliser dépendront plus de votre écran (moniteur/écran plat/téléviseur) que de votre carte vidéo basée sur GPU NVIDIA ou de l'ensemble de pilotes accélérés NVIDIA pour Linux. Pour utiliser un ou plusieurs modes standard dans X, il suffit d'ajouter une ligne "Modes" telle que : Modes "1600x1200" "1024x768" "640x480" dans la sous-section Display de votre fichier XF86Config (consultez la man page XF86Config(4/5) pour plus de détails). La documentation suivante est fondamentale si vous voulez éditer des lignes de mode, utiliser xvidtune(1) ou simplement vous informer. Notez que vous n'y trouverez pas d'explications détaillées sur l'édition de lignes de modes personnalisés pour XFree86. Nous laissons ce soin à d'autres documents, tels que XFree86 Video Timings HOWTO (disponible à l'adresse www.tldp.org). PROFONDEURS, BITS PAR PIXEL ET PAS Bien que le nombre de bits par pixel ne concerne pas directement les modes de programmation, il doit être pris en compte si l'on considère la résolution maximum programmable ; pour éviter tout confusion, il nous semble utile de faire le point sur les termes "profondeur" et "bits par pixel". La profondeur est le nombre de bits de données stockées par pixel. Les profondeurs supportées sont 8, 15, 16, et 24. Toutefois, la plupart des matériels vidéo stockent les données des pixels aux formats 8, 16, ou 32 bits ; il s'agit de la quantité de mémoire allouée pour chaque pixel. Lorsque vous spécifiez votre profondeur, X sélectionne le format de bits par pixel (bpp) auquel stocker les données. La tableau ci-dessous indique le bpp utilisé pour chaque profondeur possible. profondeur bpp ===== ===== 8 8 15 16 16 16 24 32 Enfin, le "pas" est le nombre d'octets dans la mémoire linéaire compris entre une donnée de pixel et la donnée du pixel immédiatement au-dessous. Vous pouvez penser qu'il s'agit de la résolution horizontale multipliée par le nombre d'octets par bytes (bits par pixel divisés par 8). En pratique, le pas peut être supérieur à ce produit en raison des contraintes d'alignement. RÉSOLUTIONS MAXIMALES L'ensemble de pilotes accélérés NVIDIA pour Linux et les cartes vidéo basées sur GPU NVIDIA supportent des résolutions allant jusqu'à 2048x1536, bien que la résolution maximum prise en charge par votre système soit également limitée par la quantité de mémoire vidéo (pour plus de détails, reportez-vous au point FORMULES UTILES) et la résolution maximum de votre écran (moniteur/écran plat/téléviseur). Notez également que si un recouvrement vidéo ne limite pas la résolution maximum ou la vitesse de rafraîchissement, la bande passante de la mémoire vidéo utilisée par un mode programmé a un effet sur la qualité du recouvrement. FORMULES UTILES La résolution maximum dépend de la quantité de mémoire vidéo et du nombre de bits par pixel que vous utilisez : HR * VR * (bpp/8) = Mémoire vidéo utilisée En d'autres termes, la quantité de mémoire vidéo utilisée est égale à la résolution horizontale (HR) multipliée par la résolution verticale (VR), multipliée par le nombre d'octets par pixel (bits par pixel divisés par huit). Techniquement, la mémoire vidéo utilisée correspond en fait au pas qui fixe la résolution verticale et ce pas peut être légèrement supérieur à (HR * (bpp/8)), de manière à remplir les conditions requises par le matériel, à savoir que le pas doit être un multiple d'une certaine valeur. Notez qu'il s'agit uniquement de l'utilisation que la mémoire d'image fait de la mémoire ; la mémoire vidéo est également utilisée pour d'autres choses, par exemple comme cache OpenGL ou pixmap. Une autre formule importante établit la relation entre la résolution, l'horloge pixel (aka dot clock) et la vitesse de rafraîchissement vertical : RR = PCLK / (HFL * VFL) En d'autres termes, la vitesse de rafraîchissement (RR) est égale à l'horloge pixel (PCLK) divisée par le nombre total de pixels : La longueur d'image horizontale (HFL) multipliée par la longueur d'image verticale (VFL) (remarquez qu'ils s'agit de longueurs d'images et non seulement de résolutions visibles). Comme décrit dans XFree86 Video Timings HOWTO, cette formule peut être réécrite sous la forme : PCLK = RR * HFL * VFL En considérant une horloge pixel maximum, vous pouvez régler RR, HFL et VFL à votre gré, tant que le produit de ces trois facteurs reste cohérent. L'horloge pixel est indiquée en clair dans le fichier journal quand vous démarrez X avec l'option `startx -- -logverbose 5`. Le fichier journal XFree86.0.log doit contenir plusieurs lignes telles que : (--) NVIDIA(0): Display Device 0: maximum pixel clock at 8 bpp: 350 MHz (--) NVIDIA(0): Display Device 0: maximum pixel clock at 16 bpp: 350 MHz (--) NVIDIA(0): Display Device 0: maximum pixel clock at 32 bpp: 300 MHz qui indiquent l'horloge pixel maximum pour chaque nombre de bits par pixel. VALIDATION DES MODES Pendant la phase PreInit du serveur X, le pilote X NVIDIA valide tous les modes requis de la manière suivante : o Il détecte l'intersection des plages HorizSync et VertRefresh entrées par l'utilisateur dans le fichier XF86Config avec les plages indiquées par le moniteur dans EDID (Extended Display Identification Data) ; ce comportement peut être désactivé en utilisant l'option "IgnoreEDID" ; dans ce cas, le pilote X acceptera aveuglement les plages de valeurs entrées par l'utilisateur pour HorizSync et VertRefresh. o Il appelle la fonction d'aide xf86ValidateModes(), qui recherche les modes ayant les noms spécifiés par l'utilisateur dans le fichier XF86Config, en éliminant les modes dont la vitesse de rafraîchissement horizontale ou verticale n'est pas valide, les horloges pixel dépassent la taille maximum admise par la carte vidéo ou les résolutions sont supérieures à la taille de l'écran virtuel (si une taille d'écran virtuel a été spécifiée dans le fichier XF86Config). Pour les autres contraintes appliquées, reportez-vous à xc/programs/Xserver/hw/xfree86/common/xf86Mode.c:xf86ValidateModes(). o Tous les modes renvoyés par xf86ValidateModes() sont ensuite examinés pour être sûr que leurs résolutions ne sont pas supérieures à celle du mode maximum à l'aide de l'option "IgnoreEDID". Si l'écran est un téléviseur, chaque mode est vérifié pour s'assurer que sa résolution est prise en charge par l'encodeur TV (en général, l'encodeur supporte uniquement les résolutions de 800x600 et 640x480). o Tous les modes sont également testés pour confirmer qu'ils respectent les contraintes liées à la bande passante mémoire. Ce test peut être désactivé à l'aide de l'option NoBandWidthTest du fichier XF86Config. o Tous les autres modes sont ensuite contrôlés pour s'assurer qu'ils respectent les contraintes décrites dans AUTRES CONTRAINTES DE MODES. Les trois dernières étapes sont également effectuées lors de la programmation de chaque mode, afin de détecter les modes potentiellement non valides soumis par XF86VidModeExtension (eg xvidtune(1)). Pour TwinView, la validation ci-dessus est effectuée pour les modes requis pour chaque périphérique d'affichage. AUTRES CONTRAINTES DE MODES La liste ci-dessous indique les autres contraintes à respecter pour les paramètres de modes. Dans certains cas, ces contraintes se réfèrent uniquement à certains chipsets particuliers. o La résolution horizontale (HR) doit être un multiple de 8 et inférieure ou égale à la valeur indiquée dans le tableau ci-dessous. o La largeur de l'espace vide horizontal (longueur maximum de trame horizontale et sync end horizontal moins résolution horizontale minimum et sync start horizontal (max(HFL,HSE) - min(HR,HSS)) doit être un multiple de 8 et inférieure ou égale à la valeur indiquée dans le tableau ci-dessous. o Le sync start horizontal (HSS) doit être un multiple de 8 et inférieur ou égal à la valeur indiquée dans le tableau ci-dessous. o Le sync width horizontal (sync end horizontal moins horizontal sync start (HSE - HSS)) doit être un multiple de 8 et inférieur ou égal à la valeur indiquée dans le tableau ci-dessous. o La longueur de trame horizontale (HFL) doit être un multiple de 8, supérieur ou égale à 40 et inférieure ou égale à la valeur indiquée dans le tableau ci-dessous. o La résolution verticale (VR) doit être inférieure ou égale à la valeur indiquée dans le tableau ci-dessous. o La largeur de l'espace vide vertical (longueur maximum de trame verticale et sync end vertical moins résolution verticale minimum et sync start vertical (max(VFL,VSE) - min(VR,VSS)) doit être inférieure ou égale valeur indiquée dans le tableau ci-dessous. o Le sync start vertical (VSS) doit être inférieur ou égal à la valeur indiquée dans le tableau ci-dessous. o Le sync width vertical (sync end vertical moins sync start vertical (VSE - VSS)) doit être inférieur ou égal à la valeur indiquée dans le tableau ci-dessous. o La longueur de trame verticale (VFL) doit être supérieure ou égale à 2 et inférieure ou égale à la valeur indiquée dans le tableau ci-dessous. Valeurs DAC maximum ------------------ | GeForce/TNT Geforce2 & 3 Geforce4 ou plus récent ______|_______________________________________________ | HR | 4096 4096 8192 HBW | 1016 1016 2040 HSS | 4088 4088 8224 HSW | 256 256 512 HFL | 4128 4128 8224 VR | 2048 4096 8192 VBW | 128 128 256 VSS | 2047 4095 8192 VSW | 16 16 16 VFL | 2049 4097 8192 Cet exemple de ligne de mode illustre comment utiliser les abréviations citées ci-dessus: # Ligne de mode personnalisée pour l'écran plat SGI 1600SW # nom PCLK HR HSS HSE HFL VR VSS VSE VFL Modeline "sgi1600x1024" 106.9 1600 1632 1656 1672 1024 1027 1030 1067 ENSURING IDENTICAL MODETIMINGS Certaines fonctionnalités telles que le mode de stéréo actif avec TwinView exigent une définition exacte de la synchronisation de mode utilisée. Cela peut s'effectuer de plusieurs manières : o Pour s'assurer que les deux unités d'affichage utilisent les mêmes modes, vous devez vérifier que les valeurs HorizSync et VertRefresh des deux unités d'affichage sont identiques en validant les modes ; cette validation consiste à s'assurer que les valeurs HorizSync et SecondMonitorHorizSync concordent, et que les valeurs VertRefresh et SecondMonitorVertRefresh concordent également. o Une méthode plus directe consiste à spécifier la ligne de mode que vous désirez utiliser(en sélectionnant un des générateurs de lignes de mode disponibles) et à affecter nom exclusif. Pa exemple, si vous désirez utiliser 1024x768 à 120 Hz sur chaque moniteur de TwinView avec l'option stéréo active, ajoutez des informations semblables à celles-ci : # 1024x768 @ 120.00 Hz (GTF) hsync: 98.76 kHz; pclk: 139.05 MHz Modeline "1024x768_120" 139.05 1024 1104 1216 1408 768 769 772 823 -HSync +Vsync Dans la section moniteur et la section écran de votre fichier XF86Config, spécifiez un métamode semblable à celui-ci : Option "MetaModes" "1024x768_120, 1024x768_120" VOIR ÉGALEMENT : Un générateur de modelines XFree86 conforme à la norme est disponible sur le site suivant : http://gtf.sourceforge.net/ Pour obtenir d'autres générateurs de modelines, vous pouvez rechercher "modeline" sur freshmeat.net. __________________________________________________________________________ (app-m) APPENDICE M: PAGE FLIPPING, WINDOW FLIPPING, ET UBB __________________________________________________________________________ A partir de la version 1.0-2313, les pilotes accélérés NVIDIA pour Linux prennent en charge UBB (Unified Back Buffer), Page Flipping, et Window Flipping. Dans certaines situations, ces fonctionnalités peuvent améliorer les performances. Voici une description de chacun d'elles : o Page Flipping: Cette fonctionnalité est disponible sur tous les GeForce et les produits plus récents ((c.-à-d. sur tous les produits à l'exception de TNT/TNT2) et est activée dans le cas d'une application OpenGL à un seul écran, non obscurci, quand on synchronise sur vblank. La permutation de mémoire est effectuée en changeant la mémoire balayée par DAC plutôt qu'en copiant le contenu du back buffer sur le front buffer ; ce mécanisme est généralement beaucoup plus performant et permet des permutations sans discontinuités pendant l'opération de retrace (quand __GL_SYNC_TO_VBLANK est activé. Cette fonctionnalité peut être désactivée à l'aide de l'option PageFlip du fichier XF86Config. o Unified Back Buffer (UBB): UBB n'est disponible que sur les GPU de la famille Quadro (exception faite du Quadro4 NVS) et est activé par défaut quand la mémoire vidéo disponible est suffisante. Il peut être désactivé à l'aide de l'option UBB du fichier XF86Config décrite dans l'Appendice D. Quand UBB est activé, toutes les fenêtres partagent le même back, stencil et depth buffer. Si les fenêtres sont nombreuses, l'utilisation de back, stencil et depth ne dépassera jamais la taille utilisée pour la fenêtre plein écran. Toutefois, même si on a une seule fenêtre de petite taille, back, stencil et depth seront ceux d'une fenêtre plein écran de sorte que l'utilisation de RAM vidéo peut être moins efficace que sans UBB. o Window Flipping: Cette fonctionnalité nécessite l'UBB et n'est donc disponible que sur les produits Quadro. En présence d'une seule fenêtre OpenGL, ces mémoires peuvent être permutées en changeant la mémoire balayée par DAC plutôt qu'en copiant le contenu du back buffer sur le front buffer. Cette fonctionnalité est similaire à Page Flipping sauf que la fenêtre ne doit pas obligatoirement être plein écran et non obscurcie. Elle ne fonctionne qu'en présence d'une seule fenêtre OpenGL. Window Flipping est désactivée par défaut et peut être activée à l'aide de l'option "WindowFlip" du fichier XF86Config décrite dans l'Appendice D. __________________________________________________________________________ (app-n) APPENDICE N : PROBLÈMES CONNUS __________________________________________________________________________ Les problèmes suivants existent encore dans cette version et leur résolution est actuellement à l'étude. o OpenGL + Xinerama À l'heure actuelle, OpenGL ne peut utiliser que le premier écran dans un environnement Xinerama. o OpenGL et dlopen() Il existe certains problèmes avec les versions précédentes du chargeur dynamique glibc (par ex., la version fournie avec Red Hat Linux 7.2) et des applications telles que Quake3 et Radiant, qui utilisent dlopen(). Pour de plus amples informations, reportez-vous à la section FAQ. o DPMS et TwinView Les modes DPMS "suspend" et "standby" ne fonctionnent pas correctement sur un second CRT quand on utilise TwinView. L'écran est vide au lieu du moniteur défini pour l'état DPMS requis. o DPMS et Flat Panel Les modes DPMS "suspend" et "standby" ne fonctionnent pas correctement sur un écran plat. L'écran est vide au lieu de l'écran plat défini pour l'état DPMS requis o Multicard, Multimonitor Dans certains cas, la carte secondaire n'est pas installée correctement par le module du noyau NVIDIA. Vous pouvez éliminer ce problème en activant l'utilisation du module Int10 XFree86 pour initialiser en douceur toutes les cartes secondaires. Pour plus de détails, reportez à l'APPENDICE D: OPTIONS DE XF86CONFIG. o Ordinateur portable Si vous utilisez un ordinateur portable, reportez-vous aux "Problèmes connus concernant les ordinateurs portables" dans l'APPENDICE D. o FSAA Lorsque FSAA est activée (la variable d'environnement __GL_FSAA_MODE est réglée sur une valeur qui active FSAA et un multi-échantillonnage est sélectionné), le rendu peut être altéré en cas de redimensionnement de la fenêtre. o Interaction avec pthreads Les applications à un thread qui dlopen() la librairie libGL de NVIDIA puis dlopen() toute autre librairie reliée avec pthreads, planteront dans la librairie libGL de NVIDIA. Ceci ne se produit pas dans les nouvelles librairies OpenGL ELF TLS OpenGL de NVIDIA. Reportez-vous à (app-c) APPENDICE C: COMPOSANTS INSTALLÉS pour une description des librairies OpenGl ELF TLS). Pour éliminer ce problème vous pouvez : 1) Charger la librairie qui est reliée avec pthreads avant de charger libGL.so. 2) Relier l'application avec pthreads. PROBLÈMES MATÉRIELS Cette section décrit les problèmes qui ne seront pas corrigés. Généralement, ces problèmes ne sont pas dus à NVIDIA. Voici la liste de ces problèmes : o Carte mère Gigabyte GA-6BX Cette carte mère utilise un régulateur LinFinity sur le rail 3.3-V de seulement 5 A - moins que la spécification AGP, qui exige 6 A. Pendant l'exécution de l'outil de diagnostic ou d'applications, la température du régulateur augmente en causant une baisse de tension dans le chip NVIDIA jusqu'à 2.2 V. Dans ce cas, le régulateur ne peut pas fournir sur le rail 3.3-V le courant dont le chip NVIDIA a besoin. Ce problème ne se produit pas quand la carte graphique a un régulateur avec commutateur ou quand l'alimentation externe est connectée au rail 3.3-V. o Chipsets VIA KX133 et 694X avec AGP 2x Sur les cartes mères Athlon avec le chipset VIA KX133 ou 694X, comme la carte mère ASUS K7V, les pilotes NVIDIA utilisent par défaut le mode AGP 2x pour palier à l'insuffisance du drive strength sur l'un des signaux. o Chipsets Irongate avec AGP 1x Les cartes mères Athlon avec le chipset Irongate utilisent les transferts AGP 1x pour palier au problème de l'intégrité du signal du chipset. o Chipsets ALi1541 et ALi1647 Sur les chipsets ALi1541 et ALi1647, les pilotes NVIDIA désactivent AGP pour palier aux problèmes de temporisation et d'intégrité des signaux. Vous trouverez des informations sur les chipsets Ali, dans l'APPENDICE G: PROBLÈMES SPÉCIFIQUES AUX SYSTÈMES ALI. o E/S APIC (SMP) Si vous rencontrez des problèmes d'instabilité avec une machine SMP Linux et que des messages d'avertissement I/O APIC sont générés par le noyau, vous pouvez considérablement améliorer la stabilité en réglant le paramètre "noapic" du noyau. o Local APIC (UP) Sur certains systèmes, l'option de configuration du noyau "Local APIC Support on Uniprocessors" peut causer des problèmes d'instabilité du système. Si des verrouillages se produisent avec une machine UP Linux et que cette option est activée, essayez de désactiver le support APIC local. __________________________________________________________________________ (app-o) APPENDICE O: INTERFACE PROC __________________________________________________________________________ L'interface /proc du système de fichiers vous permet d'obtenir des informations du run-time sur le pilote, les cartes graphiques NVIDIA installées et l'état AGP. Ces informations dont fournies par plusieurs fichiers dans /proc/driver/nvidia. Voici une brève description de chacun des ces fichiers : o version Contient la version du pilote installé et la version du compilateur GNU C utilisé pour construire le module du noyau Linux. o cards/0...3 Fournit des informations sur chacune des cartes graphiques NVIDIA installées (nom de modèle, IRQ, version du BIOS, type de bus). Notez que la version du BIOS n'est pas disponible pendant l'utilisation de X. o agp/card Informations sur les capacités AGP de la carte AGP installée. o agp/host-bridge Informations sur le host bridge (modèles et capacités AGP). o agp/status État courant d'AGP. Si le support AGP a été activé sur votre système (pilote AGP utilisé), ce fichier contient la vitesse d'AGP et des informations sur l'état de l'AGP Fast Writes et du Side Band Addressing sont affichées. Le pilote AGP peut être un pilote NVIDIA (pilote AGP NVIDIA incorporé) ou AGPGART (pilote agpgart.o du noyau Linux). Si vous voyez "inactive" à côté d'AGPGART, c'est que le chipset AGP a été programmé par AGPGART, mais qu'il n'est pas en cours d'utilisation. SBA et Fast Writes indiquent si l'une des fonctionnalités est en cours d'utilisation. Plusieurs facteurs entrent en jeu pour déterminer si ces fonctionnalités seront activées. D'abord, la carte AGP et le host bridge doivent tous les deux supporter ces fonctionnalités. Même si les deux les supportent, le pilote peut décider de le pas les utiliser pour préserver la stabilité du système. Il s'agit d'une particularité du Fast Writes AGP. __________________________________________________________________________ (app-p) APPENDICE P: PRISE EN CHARGE DE XVMC __________________________________________________________________________ Cette version comprend un support pour l'utilisation de l'application XvMC (X-Video Motion Compensation), vers. 1.0 sur les produits GeForce4 et GeForce FX uniquement. Elle contient une librairie statique "libXvMCNVIDIA.a" et une librairie dynamique "libXvMCNVIDIA_dynamic.so" permettant l'appel de la fonction dlopen. Les produits GeForce4 MX et GeForce FX supportent l'IDCT de XvMC et les "niveaux d'accélération de la compensation de mouvement". Les produits GeForce4 Ti supportent uniquement le niveau de compensation de mouvement. Les sous-images AI44 et IA44 sont prises en charge, ainsi que les surfaces 4:2:0 jusqu'à 2032x2032. libXvMCNVIDIA observe la variable d'environnement XVMC_DEBUG et enverra un débogage à stderr s'il est défini sur une valeur appropriée. '0' désactive le débogage. '1' active le débogage en cas de panne. '2' ou une valeur supérieure active la sortie de messages d'avertissement. __________________________________________________________________________ (app-q) APPENDICE Q: PRISE EN CHARGE DE GLX __________________________________________________________________________ Cette version supporte GLX 1.3 avec les extensions: GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_ARB_get_proc_address Vous trouverez une description de ces extensions, dans le registre d'extensions OpenGL à l'adresse : http://oss.sgi.com/projects/ogl-sample/registry/index.html Certaines de ces extensions font partie de la fonctionnalité GLX 1.3, mais sont également exportées comme extensions pour des raisons de compatibilité avec des versions antérieures. __________________________________________________________________________ (app-r) APPENDICE R: CONFIGURATION D'ÉCRANS X MULTIPLES SUR UNE CARTE __________________________________________________________________________ Les cartes graphiques qui supportent TwinView (consultez (app-i) APPENDICE I: CONFIGURATION DE TWINVIEW) peuvent également être configurées pour le traitement de chaque périphérique d'affichage en tant qu'écran X distinct. Bien que cette technique présente plusieurs inconvénients par rapport à TwinView (ex.: il n'est pas possible de déplacer les fenêtres d'un écran X à l'autre, OpenGL accéléré ne peut pas étendre les deux écrans X), elle offre un certains nombre d'avantages : o Si chaque périphérique d'affichage est un écran X distinct, les propriétés pouvant varier d'un écran X à un autre peuvent également varier d'un périphérique d'affichage à un autre (ex. : profondeur, taille de la fenêtre racine, etc.. o Le matériel pouvant uniquement être utilisé sur un seul écran à la fois (ex. : recouvrements vidéos, recouvrements RGB avec matériel accéléré) ne pouvant donc pas être utilisé dans TwinView, peut être exposé sur le premier écran X quand celui-ci est considéré séparément. o L'association 1 à 1 entre périphériques d'affichage et écrans X est davantage dans la tradition de X. Pour configurer deux écrans X distincts partageant une même carte graphique, vous devez procéder comme suit : Créez d'abord deux sections Device séparées ; dans chaque section, entrez le BusID de la carte graphique à partager, spécifiez "nvidia" comme pilote et affectez un écran distinct : Section "Device" Identifier "nvidia0" Driver "nvidia" # Entrez le BusID avec l'emplacement de votre carte graphique BusID "PCI:2:0:0" Screen 0 EndSection Section "Device" Identifier "nvidia1" Driver "nvidia" # Entrez le BusID avec l'emplacement de votre carte graphique BusId "PCI:2:0:0" Screen 1 EndSection Créez ensuite deux sections Screen, une pour chaque section Device : Section "Screen" Identifier "Screen0" Device "nvidia0" Monitor "Monitor0" DefaultDepth 24 Subsection "Display" Depth 24 Modes "1600x1200" "1024x768" "800x600" "640x480" EndSubsection EndSection Section "Screen" Identifier "Screen1" Device "nvidia1" Monitor "Monitor1" DefaultDepth 24 Subsection "Display" Depth 24 Modes "1600x1200" "1024x768" "800x600" "640x480" EndSubsection EndSection (Remarque : vous devez également créer un second section Monitor) Enfin, modifiez la section ServerLayout pour utiliser et positionner les deux sections Screen : Section "ServerLayout" ... Screen 0 "Screen0" Screen 1 "Screen1" leftOf "Screen0" ... EndSection Vous trouverez de plus amples informations dans la man page XF86Config. __________________________________________________________________________ (app-s) APPENDICE S: SYSTEME DE GESTION DE L'ENERGIE __________________________________________________________________________ Cette version inclut un système de gestion de la consommation d'énergie basé sur APM. Cela signifie que le pilote peut gérer les opérations d'arrêt et de reprise, mais pas le mode standby. Le bios de votre ordinateur portatif doit prendre en charge la fonction APM, au lieu de ACPI. De nombreux ordinateurs portatifs GeForce2 et GeForce4 intègrent le support APM. Vous pouvez rechercher le support APM via l'interface procfs (recherchez la présence du répertoire /proc/apm) ou, à partir de la sortie de la séquence de boot du noyau : % dmesg | grep -i apm un message similaire au message ci-dessous indique la présence du support apm : apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16) ou un message similaire au message ci-dessous indique l'absence du support apm : No APM support in Kernel Bien que le support ACPI avance dans la conception des noyaux et qu'il existe des correctifs pour les noyaux 2.4, le pilote graphique NVIDIA ne fournit pas encore de support pour la fonction ACPI. Nous pensons pouvoir fournir ce support dans un proche avenir. Notez que la fonction standby n'est pas prise en charge, mais que le noyau tentera d'activer le mode standby si l'utilisateur s'exige. Lorsqu'on varie les niveaux de puissance, de nombreux services du réseau sont informés de ces variations, ce qui leur permet de les gérer de manière appropriée. Par exemple, la fonction de mise en réseau est désactivée avant l'arrêt du serveur, puis réactivée avant la reprise du serveur. Lorsque le noyau tente de passer en mode standby, le bios échoue dans cette tentative. Le noyau envoie le message d'erreur "standby: Parameter out of range", mais ne notifie pas cette erreur aux services du réseau. En conséquence, le système ne s'arrête pas, tous les services du réseau seront désactivés, et le système semble bloqué. La meilleure manière de résoudre ce problème et de passer en mode arrêt, puis reprise. Sur certains ordinateurs portatifs, le bus agp devient défectueux lorsqu'on relance le système après un arrêt ayant provoqué un blocage du système. Pour remédier à ce problème, désactiver le module AGP (consultez l'Appendice F: CONFIGURATION D'AGP pour savoir comment désactiver le module agp).