HOWTO 3Dfx pour Linux
Bernd Kreimeier ( bk@gamers.org)
v1.16, 6 February 1998
_________________________________________________________________
_Ce document décrit l'utilisation des cartes accélératrices 3Dfx sous
Linux. Il contient une liste de différents matériels compatibles,
décrit la configuration des gestionnaires de périphériques impliqués
et propose des réponses aux questions les plus courantes._
_________________________________________________________________
1. Introduction
Ce document est le 3Dfx HOWTO pour Linux. Il contient toutes les
informations nécessaires à l'installation et la configuration du 3Dfx
sous Linux. Des réponses aux questions les plus fréquentes sur
l'utilisation du 3Dfx ainsi que des pointeurs vers d'autres sources
d'informations en rapport avec l'accélération matérielle du graphisme
sur ordinateur sont fournies.
Ce document n'est valable que pour les architectures PC munies de
Linux. Certaines informations peuvent être valables sur d'autres
architectures mais je n'ai aucune expérience dans ce domaine. Seules
sont couvertes les cartes à base de 3Dfx. L'utilisation d'autres
cartes accélératrices déborde du cadre de ce document.
1.1 Contributions et contacts
Ce document n'existerait pas sans l'information glanée par de
multiples personnes : celles qui se sont impliquées dans le portage et
le test de Glide pour Linux, les développeurs des pilotes Mesa et Mesa
Voodoo et celles qui ont relu ce document pour le compte de 3Dfx et de
Quantum3D. Ce texte leur est redevable de l'intégralité de certaines
parties.
Daryll Strauss daryll@harlot.rb.ca.us a effectué le portage, Paul J.
Metzger pjm@rbd.com modifications du pilote Mesa Voodoo ( écrit par
David Bucciarelli ) tech.hmw@plus.it) pour Linux, Brian Paul
brianp@RA.AVID.COM a procédé à l'intégration au sein de sa librairie
Mesa. En ce qui concerne l'accélération Voodoo Graphics (tm) de Mesa,
des remerciements supplémentaires sont dus à Henri Fousse, Gary
McTaggart, et au développeur de 3Dfx Mesa pour DOS, Charlie Wallace
Charlie.Wallace@unistudios.com. Le personnel de 3Dfx, et plus
particulièrement Gary Sanders, Rod Hughes, et Marty Franz, a fourni
des informations importantes. On citera également Ross Q. Smith chez
Quantum3D. Les pages des sites web traitant du Voodoo Extreme et de
3Dfx recèlent des informations utiles. Je me suis également renseigné
dans les forums Usenet 3Dfx. GlQuake2 pour Linux, qui repose sur Glide
et Mesa, est maintenu par Dave Kirsch zoid@idsoftware.com. Merci à
tout ceux qui ont envoyé des corrections et des mises à jours par
courrier électronique et plus particulièrement à Mark Atkinson pour
m'avoir rappelé la méthode de mise en oeuvre du câble vidéo.
Grâce aux outils SGML-Tools ( ex Linuxdoc-SGML ), ce HOWTO est
disponible dans plusieurs formats qui reposent tous sur le contenu de
ce fichier. Pour en savoir davantage sur SGML-Tools, reportez vous à
la page suivante : pobox.com/~cg/sgmltools.
1.2 Noms des produits et protection industrielle
3Dfx, le logo 3Dfx Interactive , Voodoo Graphics (tm) et Voodoo Rush
(tm) sont des marques déposées appartenant à 3Dfx Interactive, Inc.
Glide, TexUS, Pixelfx et Texelfx sont des marques déposées par 3Dfx
Interactive, Inc. OpenGL est une marque déposée par Silicon Graphics.
Obsidian est une marque déposée par Quantum3D. Les autres noms de
produits sont des marques déposées de leurs propriétaires respectifs.
1.3 Historique
_Version 1.03_
First version for public release.
_Version 1.16_
Current version v1.16 6 February 1998.
1.4 Versions actualisées du document
Vous trouverez la version la plus récente de l'original en langue
anglaise de ce document à la page web : www.gamers.org/dEngine/xf3D/.
Les nouvelles versions seront postées périodiquement sur le forum
Usenet comp.os.linux.answers. Des archives sont également disponibles
sur divers serveurs ftp anonymes tels que
ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/.
De nombreux sites web proposent des versions hypertextes, notamment
sunsite.unc.edu/LDP/. La plupart des distributions de Linux sur CD
incluent les HOWTO, en général dans le répertoire /usr/doc/. Certains
vendeurs proposent des versions imprimées.
Si vous traduisez ce document dans une autre langue, faites le moi
savoir que je puisse y faire référence.
1.5 Retour d'expérience
Je m'en remets à vous, lecteur, pour rendre ce HOWTO utile. Envoyez
les corrections, suggestions et commentaires à mon adresse (
bk@gamers.org ) et je les prendrai en compte dans une nouvelle
version. Mentionnez HOWTO 3Dfx dans le champ Sujet du courrier afin
que procmail le dirige vers le fichier adéquat.
Avant de signaler un bug ou de poser une question, _lisez ce HOWTO
dans son intégralité_. Vous pourrez ensuite envoyer un compte rendu
_détaillé_ du problème.
Si ce document est publié sous forme papier ou sur CD-ROM,
j'apprécierais une copie. Demandez moi mon adresse postale via le
courrier électronique. Les dons de soutien au Linux Documentation
Project ( LDP ) pour le développement de la documentation libre Linux
seront appréciés. Pour plus d'informations, contactez le responsable
du projet Linux HOWTO, Tim Bynum Linux HOWTO coordinator, Tim Bynum (
linux-howto@sunsite.unc.edu).
1.6 Licence
Copyright (c) 1997, 1998 by Bernd Kreimeier. La distribution de ce
document doit se conformer aux termes de la licence LDP tels que
définis à l'adresse : sunsite.unc.edu/LDP/COPYRIGHT.html.
2. Technologie des accélérateurs graphiques
2.1 Les bases
Il s'agit ici de survoler _brièvement_ les concepts de l'accélération
graphique pour faciliter le reste de la lecture. Pour en apprendre
plus, vous pourrez consulter des livres traitant d'OpenGL.
2.2 Configuration matérielle
Les accélérateurs graphiques se présentent sous diverses formes : soit
comme une carte PCI traitant les signaux vidéo issus d'une carte VGA (
usuelle ou accélérée ), soit comme une carte PCI gérant le graphisme
VGA et la 3D. Dans ce cas, l'ancien périphérique VGA est mis hors
circuit. Les cartes 3Dfx à base de composants Voodoo Graphics (tm)
appartiennent à la première catégorie. On y reviendra ultérieurement.
S'il n'y a pas de conflit d'adresses, n'importe quelle carte
accélératrice 3D peut être présente dans la machine sans perturber son
fonctionnement sous Linux. Cependant, l'accés aux fonctions
accélératrices nécessite un pilote spécifique. Une carte combinant les
fonctions 2D et 3D peut se comporter différemment.
2.3 Quelques mots sur l'organisation du Voodoo Graphics (tm)
En général, les accès à la mémoire de stockage des textures et au
tampon mémoire vidéo constituent un sérieux goulot d'étranglement.
Chaque pixel nécessite au moins un ( sinon quatre voire huit ) accès
en lecture à la mémoire de stockage des textures ainsi qu'un accès en
lecture pour la profondeur et un accès en lecture/écriture à la
mémoire vidéo.
L'architecture Voodoo Graphics (tm) sépare l'espace mémoire dédié aux
textures de celui concerné par le stockage des pixels et introduit un
rendu à deux niveaux, chacun disposant d'une unité dédiée ( Texelfx et
Pixelfx ) qui gère sa propre mémoire. Le rythme de fonctionnement
dépasse ainsi la moyenne mais des restrictions quant à l'utilisation
de la mémoire apparaissent : le stockage de textures dans la zone de
mémoire écran est impossible.
Enfin, le Voodoo Graphics (tm) est susceptible d'employer deux Texelfx
(ou TMU pour texture management unit ) et on peut combiner deux
systèmes Voodoo Graphics (tm) par un mécanisme nommé SLI ( Scan-Line
Interleaving ). Le SLI consiste à ne faire traiter par chaque Pixelfx
qu'une ligne sur deux, réduisant ainsi la bande passante requise par
chaque Pixelfx pour accéder à sa propre mémoire.
3. Installation
La mise en place du 3Dfx sous Linux passe par les étapes suivantes :
1. installation de la carte;
2. installation des logiciels Glide;
3. compilation, édition de liens et/ou exécution de l'application.
Les sections suivantes couvrent ces étapes en détail.
3.1 Installation de la carte.
Reportez vous aux instructions données par le fabricant de votre
matériel pour mettre la carte en place. Il ne devrait pas s'avérer
nécessaire d'aller modifier les IRQ, les canaux DMA : le Plug&Plante
(tm) ou les valeurs en sortie d'usine sont censés fonctionner. On
accède aux cartes décrites ci-après via l'espace d'adressage mémoire.
On n'a donc pas besoin d'interruption. Les chevauchements en mémoire
avec d'autres périphériques constituent les seuls conflits possibles.
Puisque 3Dfx n'intervient pas dans le développement et la fabrication
de cartes, il est inutile de les contacter en cas de problèmes.
Solutions aux problèmes d'installation
Afin de vérifier l'installation et l'adressage mémoire des
périphériques, faites un cat /proc/pci. La sortie devrait ressembler à
ce qui suit :
_________________________________________________________________
Bus 0, device 12, function 0:
VGA compatible controller: S3 Inc. Vision 968 (rev 0).
Medium devsel. IRQ 11.
Non-prefetchable 32 bit memory at 0xf4000000.
Bus 0, device 9, function 0:
Multimedia video controller: Unknown vendor Unknown device (rev 2).
Vendor id=121a. Device id=1.
Fast devsel. Fast back-to-back capable.
Prefetchable 32 bit memory at 0xfb000000.
_________________________________________________________________
( cas d'une Diamond Monster 3D utilisée conjointement à une Diamond
Stealth-64 ). Un cat /proc/cpuinfo /proc/meminfo aidera à résoudre les
conflits et sera utile pour signaler un bug.
Les noyaux courants afficheront peut-être au démarrage :
_________________________________________________________________
Jun 12 12:31:52 hal kernel: Warning : Unknown PCI device (121a:1).
Please read include/linux/pci.h
_________________________________________________________________
Rien de grave. Cependant, si vous possédez une carte exotique ou
récemment mise à jour, prenez le temps de lire les conseils donnés au
début du fichier /usr/include/linux/pci.h afin de transmettre les
informations utiles à linux-pcisupport@cao-vlsi.ibp.fr.
Si des problèmes se manifestent avec votre carte, examinez ce qui se
passe sous DOS et/ou Windows. Il est peu probable qu'un constructeur
prenne la peine de répondre à une demande d'aide ou au rapport d'un
bug sous Linux. Pour avoir pratiqué le service d'aide de Diamond via
courrier électronique, je ne m'attendrais d'ailleurs pas trop à une
réaction quel que soit le système d'exploitation.
Configuration du noyau
Seule la gestion du bus PCI est requise. Le Linux Kernel HOWTO fournit
tous les détails relatifs à la compilation d'un noyau.
Configuration des périphériques
Pour l'instant, les pilotes ne nécessitent pas de périphériques
particuliers. Contrairement aux gestionnaires de cartes sons qui
requièrent les entrées /dev/dsp et /dev/audio dont la présence n'est
pas garantie, les pilotes reposent ici sur le /dev/mem qui est
toujours disponible. Il vous faudra bien sûr disposer des droits de
super-utilisateur ou recourir à setuid pour accéder à la carte
accélératrice.
3.2 Gestion des écrans
Deux configurations sont possibles avec les cartes accélératrices.
Soit vous faites transiter les signaux vidéo issus de votre carte
usuelle par l'accélérateur graphique, soit vous employez simultanément
deux écrans. Reportez vous aux manuels utilisateurs du constructeur de
votre carte pour plus de détails. Les deux solutions ont été essayées
avec la Monster 3D.
Affichage avec un seul écran
Ce mode opératoire permet de vérifier le bon fonctionnement de base de
la carte accélératrice : si le signal vidéo n'est pas transmis à
l'écran, une défaillance matérielle est à envisager.
Notez qu'il risque de se produire un affaiblissement sensible du
signal. On a signalé le cas de câbles de piètre qualité fournis avec
la Monster 3D ( par exemple ) et celui que j'ai essayé n'a pas fait
exception.
Les configurations reposant sur un écran unique recèlent d'autres
subtilités. Le passage d'un mode d'affichage VGA à l'affichage
accéléré modifie aussi bien la résolution que la fréquence du moniteur
, et ce même si vous travaillez avec X11 en 640x480. De surcroît, avec
X11, votre application a la charge de gérer les évènements souris et
claviers sans quoi vous vous exposez à de sérieuses difficultés ( X
reste naturellement invisible lorsque l'on a basculé en mode accéléré
). L'utilisation d'une console SVGA à la place de X11 est
envisageable.
Si vous avez l'intention de n'utiliser qu'un seul écran duquel vous
exigerez des changements de mode fréquents, n'oubliez pas que les
composants de votre moniteur risquent de se fatiguer.
Un moniteur avec deux entrées vidéo
Certains moniteurs haut-de-gamme ( par exemple le EIZO F-784-T )
offrent deux connecteurs : un BNC à 5 broches ( RGB, HSync, VSync ) et
un Sub-D VGA usuel. Ces écrans comportent généralement des boutons de
sélection de l'entrée vidéo. Il est ainsi possible d'utiliser le
connecteur BNC avec la carte graphique habituelle via un câble adéquat
et de relier l'accélérateur 3Dfx à l'autre entrée.
Deux écrans
La carte accélératrice n'a nul besoin d'une entrée VGA. Au lieu de
faire transiter par cette dernière le signal vidéo usuel, vous pouvez
diriger les sorties vidéos vers deux moniteurs différents. Cette
solution est certes la plus dispendieuse mais elle donne les meilleurs
résultats. Vous pourrez ainsi utiliser conjointement X11 et
l'affichage accéléré en plein écran à des fins de déboggage et de
développement.
La carte accélératrice cesse de fournir le moindre signal vidéo
lorsqu'elle n'est plus utilisée. Par conséquent, à chaque fois que
l'application concernée s'arrête, les composants économiseurs
d'énergie risquent, selon la configuration de votre matériel, d'entrer
en action. Le moniteur se lassera peut-être à la longue. Utilisez donc
:
_________________________________________________________________
setenv SST_DUALSCREEN 1
_________________________________________________________________
pour maintenir la sortie vidéo active.
3.3 Installation des logiciels Glide
Les pilotes et la librairie Glide sont réunis dans un unique fichier
compressé. Décompactez/détarez les avec tar et gzip et suivez les
instructions fournies dans les fichiers README et INSTALL qui
accompagnent le logiciel. Par défaut, les fichiers sont installés dans
les répertoires lib, bin, include sous /usr/local/glide/ et le chemin
d'accés aux librairies correspondants est ajouté au ld.conf.
L'installation des fichiers et la modification du ld.conf sont des
étapes indépendantes. Sans l'étape de mise à jour du ld.conf, vous
devrez positionner manuellement la variable d'environnement
LD_LIBRARY_PATH.
Les fichiers d'en-tête doivent être visibles par le compilateur si
vous souhaitez compiler vos propres applications graphiques ! Si
l'installation par défaut ne vous satisfait pas, vérifiez bien que les
bibliothèques dynamiques sont accessibles sans quoi vous aurez droit à
un can't load library 'libglide.so'.
Le programme detect
La distribution logicielle inclut le programme bin/detect ( les
sources ne sont pas disponibles ). Le lançant sous l'identité root,
vous obtiendrez quelque chose dans le genre :
_________________________________________________________________
slot vendorId devId baseAddr0 command description
---- -------- ------ ---------- ------- -----------
00 0x8086 0x122d 0x00000000 0x0006 Intel:430FX (Triton)
07 0x8086 0x122e 0x00000000 0x0007 Intel:ISA bridge
09 0x121a 0x0001 0xfb000008 0x0002 3Dfx:video multimedia adapter
10 0x1000 0x0001 0x0000e401 0x0007 ???:SCSI bus controller
11 0x9004 0x8178 0x0000e001 0x0017 Adaptec:SCSI bus controller
12 0x5333 0x88f0 0xf4000000 0x0083 S3:VGA-compatible display co
_________________________________________________________________
Si vous n'êtes pas root, vous serez gratifié d'un :
_________________________________________________________________
Permission denied: Failed to change I/O privilege. Are you root?
_________________________________________________________________
Si vous signalez un bug, joignez une copie de la sortie écran de
detect.
Test de l'installation
La distribution Glide comprend un répertoire avec des programmes de
test. Ces programmes sont soumis au copyright 3Dfx. Leur utilisation
n'est licite que pour les possesseurs d'une carte munie d'un composant
3Dfx. Reportez vous au fichier LICENSE de la distribution ou au site
web www.3dfx.com pour plus de détails.
Bien que des binaires soient disponibles, il est recommandé de
compiler soi-même les programmes. Certains exécutables ont besoins de
fichiers tels alpha.3df que vous trouverez dans le même répertoire.
Tous les test ont lieu avec une résolution de 640 par 480. Certains
demanderont des caractères, d'autre se cantonneront à afficher Press A
Key To Begin Test. Méfiez vous d'un éventuel accaparement des
évènements de saisie par X11 si ce dernier fonctionne également sur le
même écran.
Le fichier README.test donne la liste des programmes ainsi que divers
détails.
4. Réponses aux questions les plus courantes ( la Foire Aux Questions )
Ce paragraphe reprend les réponses aux questions les plus fréquemment
posées sur Usenet ou dans les liste de diffusion. Dans un souci
d'efficacité, les questions ont été regroupées dans diverses parties :
* FAQ: Quel Matériel ?
* FAQ: Voodoo Graphics (tm) ? 3Dfx ?
* FAQ: Glide ?
* FAQ: Glide et SVGA ?
* FAQ: Glide et XFree86 ?
* FAQ: Glide ou OpenGL/Mesa ?
* FAQ: Et Quake ?
* FAQ: A marche pôôô...
La plupart des problèmes devraient trouver une réponse ici.
5. FAQ: quel Matériel ?
5.1 Système nécessaire :
Un compatible PC sous Linux disposant d'un bus PCI compatible avec la
spécification 2.1, un moniteur supportant le mode 640 par 480 et une
carte accélératrice à base de composant Voodoo Graphics (tm) 3Dfx. Le
fonctionnement sera le même sur un P5 ou un P6 qu'il possède les
extension MMX ou non. Les versions actuelles des programmes
n'utilisent pas le MMX mais elles ont été optimisées pour le P6.
Certaines phrases pourraient conduire à penser qu'une distribution
RedHat est nécessaire. Bien que Glide pour Linux ait été initialement
développé dans un environnement RedHat 4.1, il a également été utilisé
avec d'autres distributions telles la Slackware ou la Debian 1.3.1
voire avec des installations maisons.
5.2 Est-ce que ça fonctionne avec Linux-Alpha ?
Pour l'instant, il n'y a pas de distribution Glide pour Linux hors des
plateformes x86. Les sources Glide n'étant pas disponibles, il vous
faudra attendre les binaires. Quantum3D a annoncé une version DEC
Alpha. Contactez Daryll Strauss si vous êtes prêts à participer au
développement.
Se pose aussi la question du portage des modules écrits en assembleur.
Bien qu'un code C équivalent soit disponible, le module en assembleur
de Glide permet une amélioration significative des performances selon
le type de microprocesseur P5.
5.3 Quels sont les composants 3Dfx compatibles avec la distribution ?
Pour l'instant, le Voodoo Graphics (tm) 3Dfx est accepté. Le Voodoo
Rush (tm) n'est pas encore géré.
5.4 Le Voodoo Rush (tm) est-il géré ?
La version actuelle de Glide pour Linux ne gère pas le Voodoo Rush
(tm). Une mise à jour est en cours de développement.
A l'origine, le pilote Voodoo Rush (tm) de Glide utilise Direct Draw.
On devrait pouvoir utiliser une portion de la bibliothèque d'origine
DOS dès lors que les parties liées à 2D/Direct Draw/D3D seront
remplacées.
Les cartes Voodoo Rush (tm) telles l'_Hercules Stingray 128/3D_ ou
l'_Intergraph Intense Rush_ ne sont donc actuellement pas gérées.
5.5 Le Voodoo 2 (tm) est-il géré ?
Le portage actuel de la librairie Glide ne supporte pas le Voodoo 2
(tm).
5.6 Quelles sont les cartes compatibles avec Glide ?
Il n'existe pas de carte officielle ( 3Dfx ne fabrique pas de cartes
). Cette section ne vise pas à répertorier toutes les cartes
disponibles mais seulement à donner un aperçu de ce qui existe en
citant au besoin les fauteuses de troubles.
Notez que la gestion d'une carte donnée sous Linux ne se limite pas à
la disponibilité d'un pilote pour le composant d'accélération 3D mais
requiert également une bonne compatibilité avec la librairie SVGA ou
XFree86. Pour l'instant, une solution venant en complément de la carte
graphique est préférable en ce qu'elle vous laisse libre de choisir
pour cette dernière une carte correctement gérée sous Linux.
Toutes les cartes Quantum3D Obsidian, indépendemment de leur mémoire
dédiée aux textures, de celle affectée au tampon de mémoire vidéo, du
nombre d'unités Pixelfx, Texelfx ou SLI, devraient fonctionner. Idem
pour les autres cartes à base de Voodoo Graphics (tm) telles la
Righteous 3D d'Orchid, la Canopus Pure 3D, la Flash 3D ou la Monster
3D de Diamond. Les cartes reposant sur un Voodoo Rush (tm) ne sont pas
supportées.
Les cartes qui ne reposent pas sur des composants fournis pas 3Dfx
telles celles que fabriquent S3, Matrox, 3Dlabs et Videologic ne
fonctionnent _PAS_ avec les pilotes 3Dfx et débordent du cadre de ce
document.
5.7 Qu'est-ce qui distingue les cartes ?
Les fabricants de cartes utilisant tous le même composant, les
différences sont liées à la conception de la carte. La qualité du
câble et des connecteurs peuvent varier ( Orchid semble ainsi être
meilleur sur ce point que Diamond ), une sortie vidéo supplémentaire
pour la télévision peut être disponible ( Canopus Pure 3D ) et,
surtout, les quantités de mémoire diffèrent.
Les cartes les plus courantes sont dédiées au jeu et ne comprennent
que 2 Mo de mémoire. La Canopus Pure 3D est cependant fournie avec une
mémoire pour les textures allant jusqu'à 4 Mo, ce qui améliore
nettement le rendu des jeux qui modifient dynamiquement les textures
ou ont recours à des textures d'illumination ( Quake par exemple ).
Quantum 3D propose la palette de cartes 3Dfx la plus étendue et vous
irez surement chez eux si vous êtes à la recherche d'une carte haut de
gamme. Quantum 3D vise le marché de la simulation tandis que la
plupart des autres vendeurs se cantonnent au marché des utilisateurs
courants de PC.
5.8 Qu'en est-il de l'AGP?
A ma connaissance il n'existe pas de carte AGP Voodoo Graphics (tm) ni
Voodoo Rush (tm). Je ne sais pas où en est la gestion de l'AGP sous
Linux.
Le chipset Voodoo 2 (tm) est prévu pour le bus AGP. En fait, il le
considère comme un bus PCI rapide, et n'utilise pas, à ma connaissance
les spécificités du bus AGP. Le gain en performances est néanmoins lié
à l'augmentation de la vitesse du bus.
Le noyau Linux reconnaîtra une carte AGP à base de Voodoo 2 (tm) comme
si elle était sur un second bus PCI, comme c'est déjà le cas avec la
carte RIVA-128 AGP.
Voici ce que donne /proc/pci :
_________________________________________________________________
Bus 1, device 0, function 0:
VGA compatible controller: Unknown vendor Unknown device (rev 16).
Vendor id=12d2. Device id=18.
Medium devsel. Fast back-to-back capable. IRQ 9.
Master Capable. Latency=64.
Min Gnt=3.Max Lat=1.
Non-prefetchable 32 bit memory at 0xfd000000.
Prefetchable 32 bit memory at 0xf6000000.
_________________________________________________________________
6. FAQ: Voodoo Graphics (tm) ? 3Dfx ?
6.1 3Dfx, qui est-ce ?
3Dfx est un fabricant de composants pour l'accélération graphique 3D
basé à San Jose. Leur site officiel : www.3dfx.com. 3Dfx ne vend pas
de cartes, contrairement à d'autres sociétés ( Quantum3D par exemple
).
6.2 Qui est Quantum3D ?
Quantum3D est une entreprise issue de 3Dfx qui fabrique des cartes
accélératrices haut de gamme à base de composants 3Dfx à usage
personnel et professionnel. Quantum3D intervient également sur le
marché des jeux d'arcade. Pour avoir davantage de renseignements,
consultez donc leurs pages : www.quantum3d.com Pour toute question
concernant Quantum3D, envoyez un message électronique à :
info@quantum3d.
6.3 Voodoo Graphics (tm), quès acco ?
Le Voodoo Graphics (tm) est un composant électronique fabriqué par
3Dfx. Il est employé dans les cartes d'accélération graphique pour PC.
Reportez vous à la section du HOWTO concernant le matériel.
6.4 Voodoo Rush (tm) ?
Le Voodoo Rush (tm) est un dérivé du Voodoo Graphics (tm) muni d'une
interface pour opérer de concert avec un accélérateur graphique VGA
2D. Les fonctions accélératrices peuvent alors être restreintes à une
fenêtre. Cette possibilité n'est pas encore gérée sous Linux.
6.5 Voodoo 2 (tm) ?
Le Voodoo 2 (tm) succède, avec des améliorations, au Voodoo Graphics
(tm). Quantum3D, Creative Labs, Orchid Technologies et Diamond
Multimedia fournissent des cartes intégrant le Voodoo 2 (tm).
Bien que le Voodoo 2 (tm) soit censé être compatible, une nouvelle
version de Glide devra être développée pour Linux.
6.6 Qu'est ce qu'un intermédiaire VGA ?
Les cartes Voodoo Graphics (tm) ( mais pas les Voodoo Rush (tm) ) sont
des cartes accélératrices censées travailler de concert avec une carte
VGA 2D. Pour résumer, le signal vidéo en sortie de la carte VGA sert
d'entrée à la carte Voodoo Graphics (tm) qui par défaut se contente de
transmettre au moniteur. Si le Voodoo Graphics (tm) est activé ( par
exemple durant un jeu ), il intercepte le signal VGA, bascule l'écran
en 640 par 480, ajuste la fréquence conformément aux exigences du
pilote et génère lui même le signal vidéo. La carte VGA n'a pas besoin
d'être informée de ce qui se passe et, dans les faits, elle ne l'est
pas.
Ce mode opératoire présente plusieurs avantages : d'une part le choix
de la carte vidéo reste libre, point d'importance sous Linux puisque
XFree86 ne peut gérer toutes les révisions et variantes des jeux de
composants, et d'autre part l'introduction du graphisme 3D accéléré se
fait au meilleur prix. La médaille a son revers : le plantage d'un
applicatif utilisant le Voodoo Graphics (tm) risque de bloquer la
sortie vidéo usuelle et le signal vidéo transitant par l'intermédiaire
VGA est détérioré.
6.7 Qu'est-ce que le Texelfx, un TMU ?
Les composants Voodoo Graphics (tm) comportent deux unités. La
première contrôle l'accès à la mémoire dédiée aux textures, met en
place les textures et passe la main à la seconde unité qui assure la
gestion du tampon de mémoire vidéo. La première partie est nommée
Texelfx. Il faut savoir que certaines cartes telles l'Obsidian de
Quantum3D sont capables d'utiliser deux Texelfx. Selon l'application,
on doublera ainsi la puissance de calcul.
Chaque Texelfx peut gérer 4 Mo de mémoire pour ses textures. Une
configuration munie de deux Texelfx dispose de 8 Mo utilisables et ce
même si seule une unité est requise par le logiciel. Les deux Texelfx
opèrent de concert pour certaines opérations tel le filtrage
tri-linéaire ou l'illumination qui ont lieu en une seule phase ( ex.
GlQuake ). A charge des applications Glide d'utiliser correctement les
Texelfx pour accéder aux performances théoriques.
On ne peut pas recourir à deux Texelfx afin d'afficher simultanément
plusieurs triangles texturés. Soit un triangle ne requiert qu'une
seule texture, au tel cas un seul Texelfx est actif, soit deux
textures sont utilisées en une seule passe. Un Texelfx ne peut accéder
qu'à sa mémoire propre.
6.8 Qu'est ce qu'une unité Pixelfx ?
Il s'agit de la seconde partie d'un composant Voodoo Graphics (tm),
chargée de la gestion du tampon de mémoire vidéo ( mise à jour de la
couleur des pixel, etc ... ). Deux Pixelfx peuvent coopérer en mode
dit SLI, doublant ainsi le rythme d'affichage. Les cartes Quantum3D
Obsidian offrent cette fonctionnalité.
6.9 Qu'est-ce que le mode SLI ?
Le SLI est une abréviation pour "Scanline Interleave" ou entrelacement
des lignes d'affichage. Dans ce mode de fonctionnement, on relie deux
Pixelfx qui calculent le rendu, sur les lignes paires pour l'un, sur
les lignes impaires pour l'autre. Chaque Pixelfx ne stocke plus que la
moitié de l'image et du tampon de calcul de profondeur dans sa zone de
mémoire propre et le nombre de pixels affichables est ainsi doublé.
Les Pixelfx peuvent être sur deux cartes distinctes reliées de façon
adéquate. Certaines cartes Obsidian supportent le SLI avec le Voodoo
Graphics (tm).
Plusieurs cartes pouvant décoder simultanément les mêmes adresses PCI
et recevoir les mêmes données, le SLI ne nécessite pas un surcroît de
bande passante. Sur un autre plan, les données relatives aux textures
doivent être présentes sur les deux cartes.
6.10 Le SLI avec une seule carte ?
Il existe à présent deux types de cartes Quantum3D pour faire du SLI.
A l'origine il fallait deux cartes, deux connecteurs PCI et un câble
de liaison ( Obsidian 100-4440 ). La nouvelle version se comporte à
l'identique mais ne nécessite qu'un seul connecteur PCI ( Obsidian
100-4440SB ).
6.11 Quelle quantité de mémoire ?
La différence entre les cartes utilisant les composants Voodoo
Graphics (tm) se fait essentiellement sur la quantité de mémoire et
sur son organisation. A cet égard, les cartes Quantum3D sont décrites
par un schéma à trois niveaux. Le schéma suivant, qui anticipe le
Voodoo 2 (tm), diffère légèrement. A noter que si l'on utilise
plusieurs Texelfx, tous doivent posséder la même quantité de mémoire (
pour les textures ). Idem en ce qui concerne l'utilisation simultanée
de plusieurs Pixelfx;.
_________________________________________________________________
"SLI / Pixelfx / Texelfx1 / Texelfx2 "
_________________________________________________________________
Une carte courante munie de deux fois 2 Mo est décrite par le
quadruplet 1/2/2/0, la quantité totale de mémoire étant égale au
minimum requis de 4Mo. Une Canopus Pure 3D, munie de 6 Mo, est du type
1/2/4/0. Une Obsidian-2220 avec deux Texelfx; est du type 1/2/2/2 et à
une Obsidian SLI-2440 board correspondrait 2/2/4/4. Une carte double à
2 Pixelfx, chacun possédant 2 Texelfx et 4 Mo de mémoire vidéo, les
Texelfx ayant chacun 4 Mo pour les textures, serait du type 2/4/4/4
pour une quantité totale de mémoire de SLI*(Pixelfx+Texelfx1+Texelfx2)
soit 24 Mo.
6.12 Le Voodoo Graphics (tm) gère-t-il l'affichage en 24 ou 32 bits ?
Non. L'architecture Voodoo Graphics (tm) fonctionne à 16 bpp en
interne. Idem pour le Voodoo Rush (tm) et le Voodoo 2 (tm). Quantum3D
affirme mettre en oeuvre un affichage à 22 bpp avec un tampon de
mémoire vidéo ( 16 bpp ) compressé.
6.13 Le calcul de profondeur du Voodoo Graphics (tm) est-t-il en 24 ou 32 bits
par pixel ?
Non. Là encore, l'architecture interne est sur 16 bits. Même chose
pour le Voodoo Rush (tm) et le Voodoo 2 (tm). Quantum3D affirme
obtenir une précision effective de 22 bpp pour le tampon de profondeur
( Z-buffer ) avec des calculs en flottant sur 16 bits.
6.14 Quelles résolutions offre le Voodoo Graphics (tm) ?
Le jeu de composants Voodoo Graphics (tm) gère jusqu'à 4 Mo de mémoire
vidéo. Avec un tampon double et un tampon de profondeur, 2 Mo de
mémoire permettent du 640 par 480 et 4 Mo du 800 par 600.
Le 960 par 720 n'est malheureusement pas accessible. Le Voodoo
Graphics (tm) ne peut opérer que sur des résolutions divisibles par 32
dans les deux directions, ce qui emmène le 960 par 720 à 960 par 736,
soit 4,04 Mo de mémoire pour les trois zones de mémoire considérées en
16 bit.
En utilisant deux cartes en SLI, ou une carte avec un double Pixelfx
en SLI, chaque tampon de mémoire vidéo n'a plus à stocker qu'une
moitié de l'image. Dans ce cas, 2 fois 4 Mo permettent d'obtenir du
1024 par 768, ce qui constitue de toute façon le maximum accessible
compte tenu de l'architecture matérielle. Vous pourrez certes faire du
1024 par 768 avec un triple tampon mais le matériel est incapable de
tenir le 1280 par 960 avec un tampon double.
Notez que la présence d'un tampon triple ( les applications ne
nécessitent par de signal VSync de synchronisation ), de mémoire
intermédiaire pour la stéréo ( avec des lunettes à LCD ) ou toute
autre configuration particulière diminue d'autant la résolution
maximale.
6.15 Quelles sont les tailles de texture disponibles ?
Le composant Voodoo Graphics (tm) accepte au maximum des textures de
256 par 256. Les dimensions des textures doivent être des puissances
de 2. Il est judicieux de regrouper les textures de petite taille (
16x16 par exemple ) au sein de textures plus grandes et d'adapter le
système de coordonnées des textures en conséquence.
6.16 Le Voodoo Graphics (tm) gère-t-il les textures palettisées ?
Les composants Voodoo Graphics (tm) et Glide gèrent l'extension
correspondante de OpenGL. La dernière version de Mesa comporte les
extensions GL_EXT_paletted_texture et GL_EXT_shared_texture_palette.
6.17 Qu'en est-il du dépassement de fréquence d'horloge ?
Mettant de côté les considérations relatives à la garantie et au
risque de surchauffe, si vous voulez obtenir de meilleurs performances
en augmentant la fréquence d'horloge, des informations sont
disponibles sur le web. Le mécanisme consiste à modifier certaines
variables d'environnement Glide.
La fréquence d'horloge recommandée dépend de la carte. Si la fréquence
d'horloge par défaut de la Diamond Monster 3D est de 50 MHz, son
feuillet de spécifications vous laisse l'emmener à 57 MHz. Tout dépend
des divers composants utilisés et de la façon dont la carte a été
conçue ( en particulier au niveau des temps d'accés à la mémoire ). Si
vous allez trop loin, des artefacts d'affichage feront leur apparition
( entre autre choses ). Une fréquence de 57 MHz reste en général
admissible, ce qui est bien moins le cas du 60 MHz.
L'augmentation de la fréquence d'horloge provoque un accroissement
non-linéaire de l'énergie dissipée. Si vous augmentez de façon
permanente la fréquence d'horloge, n'oubliez pas de revoir le
mécanisme de refroidissement. Une bonne source de renseignements
accessible via le Web est le "3Dfx Voodoo Heat Report" par Eric van
Ballegoie. A vos risques et périls.
6.18 Où puis-je trouver d'autres informations concernant le Voodoo Graphics
(tm) ?
3Dfx a rédigé une FAQ qui devrait se trouver à l'adresse suivante :
web site. Vous trouverez des informations sur la vente aux adresses
suivantes : www.3dfx.com et www.quantum3d.com.
Certains sites non-officiels sont bien renseignés : www.ve3d.com,
www.ve3d.com.
7. FAQ: Glide? TexUS?
7.1 Glide, quès acco ?
Glide comprend une API propriétaire et des pilotes pour la gestion des
accélérateurs graphiques 3D reposant sur les composants fabriqués par
3Dfx. Glide est disponible pour DOS, Windows et Macintosh. Daryll
Strauss a effectué le portage Linux.
7.2 TexUS, quès acco ?
La distribution comprend une bibliothèque libtexus.so ( 3Dfx
Interactive Texture Utility Software ). Il s'agit d'une bibliothèque
de fonctions utilitaires et de traitement de l'image qui met en forme
les images avant leur traitement dans la bibliothèque 3Dfx Interactive
Glide. Cette bibliothèque inclut des fonctions de conversion de
formats de fichiers, la création de mipmap et la gestion des textures
3Dfx compressées ( 3Dfx Interactive Narrow Channel Compression ).
Le programme texus lit les images dans divers formats courants ( TGA,
PPM, RGT ), génère des mipmaps et écrit les images sous forme de
textures 3Dfx ( reportez vous par exemple au fichier alpha.3df
disponible dans la distribution ). Pour les détails relatifs aux
paramètres de texus et à l'API, reportez vous à la documentation
TexUS.
7.3 Glide est-il un freeware?
Non. Glide n'est pas en GPL ni couvert par une quelconque license du
même type. Tous les détails se trouvent dans le fichier LICENSE de la
distribution. Dans les faits, en téléchargeant et en utilisant le
logiciel, vous acceptez les termes de la license d'utilisateur final
tel qu'il se trouve sur le site 3Dfx. Glide est fourni sous forme de
binaires et vous ne devez pas utiliser ni distribuer d'autres fichiers
que ceux accessibles publiquement si vous n'avez pas signé un NDA. La
distribution Glide comprenant les sources du programme de test est
propriété de 3Dfx.
Il en est de même de toutes les sources disponibles dans la
distribution Glide. Selon les termes de 3Dfx : les sources
n'appartiennent pas au domaine public mais elles peuvent être fournies
sans limitations aux possesseurs de produits 3Dfx. Pas de carte, pas
de code !
7.4 Où trouver Glide?
Le SDK 3Dfx est téléchargeable via le web :
www.3dfx.com/software/download_glide.html. Tout ce qui a trait à 3Dfx
et qui est publiquement accessible, se trouve généralement sur le site
3Dfx.
Il y a également un site FTP : ftp.3dfx.com. Le temps de maintien de
connexion du FTP est plus long et certains des fichiers les plus
volumineux ont été découpés en trois ( environ 3 Mo pour chaque partie
).
7.5 Les sources de Glide sont elles disponibles ?
Non. L'accès aux sources de Glide requiert la signature d'un NDA avec
3Dfx.
7.6 Quel est le support de Linux Glide ?
Actuellement, il n'y a pas de support pour Linux Glide. La
distribution est fournie dans les mêmes conditions que la DLL 3Dfx GL
( voir plus bas ).
3Dfx souhaite cependant fournir le meilleur support possible et met en
place les outils adéquats. Pour l'instant, vous devrez vous en
remettre au forum USENET de 3Dfx ( voir plus bas ).
Enfin, la page web de Quantum3D annonce un support Linux concernant
l'Obsidian sur les architectures Intel et AXP pour le second semestre
97.
7.7 Où puis-je poser des questions ayant trait à Glide ?
Il existe des forums USENET fournis par 3Dfx : news.3dfx.com. Ils sont
dédiés à 3Dfx et à Glide de façon générale et fourniront surtout des
indications pour DOS, Windows95 et NT. La liste actuelle est la
suivante :
_________________________________________________________________
3dfx.events
3dfx.games.glquake
3dfx.glide
3dfx.glide.linux
3dfx.products
3dfx.test
_________________________________________________________________
ainsi que les forums 3dfx.oem.products.* pour les différentes cartes (
3dfx.oem.products.quantum3d.obsidian par exemple ). Utilisez
news.3dfx.com/3dfx.glide.linux pour toutes les questions ayant trait à
Linux Glide.
Une liste de diffusion spécifique à Linux Glide est en préparation
pour 1998. Envoyez un courrier électronique à : majordomo@gamers.org,
avec un champ sujet vide et comme corps de message : info linux-3dfx.
Vous obtiendrez ainsi des informations sur la liste ( comment
souscrire, accès aux archives, conseils de rédaction, etc ... ).
7.8 Où envoyer les notifications de bug ?
Pour l'instant, utilisez le forum USENET :
news.3dfx.com/3dfx.glide.linux. Un support officiel par courrier
électronique n'est pas encore disponible. Pour tout ce qui n'est pas
spécifique à Linux Glide, postez dans les autres forums.
7.9 Qui assure la maintenance de Linux Glide ?
3Dfx nommera bientôt quelqu'un pour s'occuper officiellement de la
maintenance. Le responsable ( officieux ) du portage reste pour le
moment Daryll Strauss. Envoyez vos avis de bug dans le forum adéquat (
cf ci-dessus ). Si vous êtes persuadé d'avoir identifié un bug
non-repertorié, écrivez à Daryll : daryll@harlot.rb.ca.us
7.10 Comment puis-je contribuer à Linux Glide?
Vous pouvez décrire de façon précise les bugs que vous remarquez. Il
est également possible de fournir un programme d'exemple pour la
distribution. L'amélioration des sources du pilote Mesa Voodoo basé
sur Glide serait la bienvenue. Reportez vous à la section sur Mesa
Voodoo plus bas.
7.11 Dois-je nécessairement avoir recours à Glide ?
Oui. Pour l'instant, il n'existe pas d'autre pilote Voodoo Graphics
(tm) sous Linux. Glide est la seule interface pour dialoguer avec le
matériel. Vous pouvez néanmoins écrire du code OpenGL sans rien
connaître à Glide et utiliser Mesa avec le pilote Mesa Voodoo reposant
sur Glide. Savoir à quel point Glide est impliqué aide cependant à
identifier les bugs ainsi que les limitations du pilote.
7.12 Dois-je programmer avec l'API Glide ?
Tout dépend de l'application. Glide est une API propriétaire. Elle
reste certes voisine d'OpenGL ou de Mesa, mais elle contient quand
même certaines fonctionnalités qui, pour les unes, sont disponibles
comme des extensions d'OpenGL et, pour les autres, n'existent nulle
part ailleurs.
Si vous souhaitez utiliser l'API OpenGL, vous aurez besoin de Mesa (
cf. plus bas ). Mesa, ou plus exactement le pilote Mesa Voodoo,
propose une API voisine de celle d'OpenGL, cette dernière étant assez
répandue et plutôt bien documentée. Le pilote Mesa Voodoo est
cependant en phase alpha et il vous faudra accepter des performances
parfois limitées ainsi que l'absence de certaines fonctionnalités.
En résumé, le choix vous appartient. Si vous voulez les meilleurs
performances au prix d'éventuelles difficultés lors du portage vers
des architectures non-3Dfx, Glide n'est pas un mauvais choix. Si vous
vous souciez avant tout de portabilité, OpenGL sera peut-être une
meilleure solution à long terme.
7.13 Quelle est la version courante de Glide ?
La version actuelle de Linux Glide est 2.4. La version suivante sera
vraisemblablement identique à la version actuelle pour DOS/Windows, à
savoir la 2.4.3. Pour l'instant, certaines parties de Glide sont
différentes pour les cartes Voodoo Rush (tm) ( VR ) et Voodoo Graphics
(tm) ( VG ). Sous Windows, vous devez donc récupérer la distribution
correspondante. Il en sera de même sous Linux. Il y aura surement une
autre distribution pour les cartes Voodoo 2 (tm) ( V2 ).
Glide 3.0 étendra l'API aux éventails et aux rubans de triangles et
gérera les optimisations de changement d'état. La gestion des
éventails et des rubans diminuera notablement dans certains cas la
quantité de données transmise par triangle. Le pilote Mesa en
bénéficiera puisque l'API OpenGL dispose de modes spécifiques de ce
type. Pour des explications plus détaillées, consultez la
documentation OpenGL.
7.14 Qu'en est-il de la gestion de plusieurs Texelfx ?
Des Texelfx ( ou TMU ) multiples peuvent 2 employés lors d'un filtrage
tri-linéaire ( de type mipmap ) avec Linux Glide. La qualité de
l'image est améliorée sans pertes de performances. Il vous faudra une
carte munie de deux Texelfx ( une des cartes Obsidian de Quantum3D
donc ). A charge de l'application de réclamer l'utilisation des deux
Texelfx. Il n'y a rien d'automatique.
Notez dès à présent que la plupart des applications visent les cartes
grand public qui ne sont munies que d'un seul Texelfx. Elles
n'envisagent pas l'éventualité de la présence d'une seconde unité et
ne s'en servent donc pas. Il ne s'agit pas d'une limitation de Glide
mais bien d'une mauvaise conception des applications.
7.15 Linux Glide est il semblable à Glide pour DOS/Windows ?
La version publique de Linux Glide devrait être identique aux versions
disponibles pour DOS/Windows. Les nouvelles versions pour Linux
arriveront peut-être un peu après celles pour DOS/Windows.
7.16 Où trouver des informations sur Glide?
3Dfx fournit des informations exhaustives. Vous pouvez les télécharger
via leur site web : www.3dfx.com/software/download_glide.html. Ces
informations sont disponibles gratuitement dès lors que vous avez
acheté une carte à base de composant 3Dfx. Lisez attentivement les
termes du contrat de licence.
Dans un premier temps, vous pouvez vous intéresser aux documents
suivants :
* _Glide Release Notes_
* _Glide Programming Guide_
* _Glide Reference Manual_
* _Glide Porting Guide_
* _TexUs Texture Utility Software_
* _ATB Release Notes_
* _Installing and Using the Obsidian_
Il s'agit de documents disponibles tels quels au format(s) Word et
inclus sinon dans la distribution Glide. Des versions PostScript sont
téléchargeables : www.3dfx.com. Notez que les numéros de version ne
correspondent pas toujours à ceux de Glide.
7.17 Où trouver des démos Glide ?
Vous trouverez des sources de démos pour Glide parmi les programmes de
test de la distribution et sur le site de 3Dfx. Certaines parmi ces
dernières nécessitent ATB : le portage impliquerait la réécriture du
gestionnaire d'évènements.
En outre, vous trouverez sûrement des choses intéressantes dans les
sources des démos OpenGL qui accompagnent Mesa et GLUT. Bien que les
API Glide et OpenGL diffèrent, elles se destinent à des matériels dont
les organisations sont voisines.
7.18 Qu'est-ce qu'ATB?
Certaines des démos 3Dfx pour Glide ne reposent pas seulement sur
Glide mais également sur la boite à outils pour l'arcade 3Dfx ( ATB ou
Arcade ToolBox ). Cette dernière existe sous DOS et Win32 mais n'a pas
encore été portée sous Linux. Si vous êtes un développeur dans l'âme,
les sources sont disponibles dans le cadre du programme "Total
Immersion". Le portage devrait donc être possible.
8. FAQ: Glide et XFree86 ?
8.1 Glide fonctionne-t-il avec XFree86 ?
En fait, les périphériques Voodoo Graphics (tm) ne se préoccupent pas
de X. Le serveur X ne remarque d'ailleurs même pas que le signal vidéo
issu du matériel VGA n'atteint pas le moniteur. Si vos applications ne
font pas attention à X, le passage de Glide en plein écran risque de
soulever des difficultés ( cf la section de résolution des problèmes
). Pour éviter le surcroît de code chargé d'assurer la cohabitation
avec X, utilisez plutôt la console SVGA.
Pour résumer, la bonne entente avec XFree86 est possible pour autant
que vous vous en occupiez. Vous pouvez avoir recours au "hack de
fenêtre" Mesa. Il est plus lent que le mode plein écran mais reste
plus rapide qu'un rendu purement logiciel ( cf la section suivante ).
8.2 Doit-on se cantonner au plein écran ?
Les périphériques Voodoo Graphics (tm) ne se soucient guère de modes
d'opération fenêtrés. Il en est de même de Linux Glide. Le hack Mesa à
venir permet cependant de copier le contenu du tampon de mémoire vidéo
d'une carte Voodoo Graphics (tm) dans une fenêtre X11.
8.3 Quel est le problème des cartes AT3D/Voodoo Rush (tm) ?
Le problème est inhérent à l'utilisation des cartes Voodoo Rush (tm)
sous Linux. A la base, elles sont censées jouer un rôle de cartes
accélératrices VGA 2D/3D, que ce soit seules ou en tant que cartes
filles. Le composant VGA lié au Voodoo Rush (tm) est un accélérateur
multimédia Promotion-AT3D d'Alliance Semiconducteur. XFree86 requiert
un pilote pour le composant AT3D.
Il existe une mailing list et un site web avec une FAQ à ce sujet :
www.frozenwave.com/linux-stingray128. Vous y obtiendrez l'information
la plus à jour. Suse maintient un pilote :
ftp.suse.com/suse_update/special/xat3d.tgz. On signale que le serveur
SVGA de XFree86 fonctionne également en 8, 16 et 32 bpp. Le support
officiel sera vraisemblablement présent dans la version 4.0 de la
XFree86. XFree86 s'est décidé à mettre au point une distribution
intermédiaire, la 3.3.2, qui pourrait très bien résoudre le problème.
La configuration suivante du XF86Config est censée fonctionner :
_________________________________________________________________
# device section settings
Chipset "AT24"
Videoram 4032
# modes vidéos testés par Oliver Schaertel
# 25.18 28.32 for 640 x 480 (70hz)
# 61.60 for 1024 x 786 (60hz)
# 120 for 1280 x 1024 (66hz)
_________________________________________________________________
En fin de compte, même si les pilotes XFree86 ne sont pas encore
terminés, il n'y a rien de rédhibitoire.
Voici un peu plus de précisions techniques : la gestion du Voodoo Rush
(tm) exige de la part du serveur X la capacité d'accéder à une zone
dans la mémoire vidéo de la carte AT3D tandis que le Voodoo Rush (tm)
a également besoin de cette mémoire pour stocker son second buffer et
celui du calcul de profondeur. Le besoin d'allocation et de
vérouillage de la mémoire n'est pas spécifique aux composants 3Dfx. On
le rencontre également dans la gestion des cartes TV capables de
saisir l'image. Les développements XFree86 sont actifs dans ce
domaine. Cela implique des changements au niveau où X est lié au
matériel ( XAA ), changements qui sont à lors actuel mis en oeuvre via
l'extension XFree86 DGA ( Direct Graphics Access ) aux spécifications
X11R6.1. L'extension fera peut-être partie d'une réalisation GLX
d'XFree86. Les serveurs X actuels agissent comme s'ils étaient les
seuls à accéder au tampon de mémoire vidéo et affectent tout ce qui
n'est pas directement utilisé pour l'affichage au stockage de pixmaps
( typiquement pour les fontes ).
8.4 Qu'en est-il de GLX pour XFree86 ?
Il y a quelques difficultés.
Les périphériques Voodoo Graphics (tm) gérés par la version actuelle
de Linux Glide ne fonctionnent qu'en plein écran et ne sont pas prévus
pour partager leur tampon de mémoire vidéo dans un environnement
multi-fenêtres. GLX, ou toute autre intégration avec X11, n'est donc
pas encore réalisable.
Le Voodoo Rush (tm) devrait accepter de coopérer avec XFree86 : une
carte conforme aux spécifications SVGA fonctionnera avec le serveur
SVGA XFree86. Cependant, Linux Glide ne supporte pas encore ce
composant. Il en est de même du serveur S3 et des autres serveurs
XFree86.
Enfin, GLX est intimement lié à OpenGL, ou, en ce qui concerne Linux,
à Mesa. L'équipe XFree86 travaille en ce moment à l'intégration de
Mesa avec leurs serveurs X. GLX est en bêta et les points d'ancrage
sont présents dans XFree86 3.3. Reportez vous aux pages GLX de Steve
Parker pour des informations les plus à jour :
www.cs.utah.edu/~sparker/xfree86-3d/ De plus, XFree86 et SuSe ont
joint leurs efforts dans la réalisation d'un GLX. Cf :
www.suse.de/~sim/. Pour l'instant, Mesa émule toujours de façon
logicielle GLX avec Linux.
8.5 Glide et les serveurs X commerciaux ?
Je n'ai reçu aucun courrier ayant trait à l'utilisation de Glide et/ou
de Mesa avec des serveurs X commerciaux. Je suis intéressé par toute
information sur le sujet, notamment s'il existe un serveur X
commercial offrant GLX.
8.6 Glide et SVGA ?
Vous ne devriez pas rencontrer de problèmes avec des applications
Glide à un ou deux écrans dans les modes d'affichage VGA. Il peut
également s'avérer intéressant d'activer une résolution de 640 par 480
parmi les modes SVGA si vous travaillez avec un seul écran.
8.7 Glide et GGI ?
Jon Taylor est en train de mettre au point un pilote GGI pour Glide.
Il n'est pas encore distribué officiellement et le restera jusqu'à ce
que GGI 0.0.9 soit achevé. Pour davantage d'informations au sujet de
GGI, consultez : synergy.caltech.edu/~ggi/. Si vous aimez vivre
dangereusement, vous ne résisterez pas au charme de la combinaison
XGGI ( serveur X pour XFree86 reposant sur GGI ) + GGI pour Glide. Il
existe également un pilote GGI qui s'interface avec l'API OpenGL. Il a
été testé avec Mesa sans accélération. Pour tout résumer, cela
signifie que X11R6 est disponible sur Voodoo Graphics (tm) grâce à
Mesa ou à Glide.
9. FAQ: OpenGL/Mesa ?
9.1 Qu'est ce qu'OpenGL ?
OpenGL est une API pour le graphisme de niveau intermédiaire
développée par SGI à partir de leur interface précédente Iris GL.
OpenGL est devenu un standard il y a de ça quelques années. Il est
fourni et maintenu par l'ARB ( Architectural Revision Board ), une
organisation à laquelle appartiennent par exemple SGI, IBM, DEC et
Microsoft.
OpenGL fournit tout un ensemble de fonctions 2D et 3D pour le rendu de
triangles et de polygones sur du matériel accélérateur muni d'une
architecture en pipeline. De façon plus générale, OpenGL forme un
ensemble d'outils puissant pour le graphisme accéléré sur ordinateur.
9.2 Où trouver davantage d'informations sur OpenGL ?
Le site officiel d'OpenGL, administré par les membres de l'ARB :
www.opengl.org,
On préférera peut être la passerelle vers OpenGL de Mark Kilgard :
reality.sgi.com/mjk_asd/opengl-links.html. Ce site contient des
pointeurs vers des livres, des pages de manuel en ligne, GLUT, GLE,
Mesa, des portages sous divers OS ainsi que de nombreuses démos et des
outils.
Si le développement de jeu utilisant OpenGL vous tente, il existe une
liste de diffusion OpenGL-GameDev-L@fatcity.com accessible via
Listserv@fatcity.com. Il s'agit d'une liste à contenu fortement
technique et dont le débit est très élevé. Vous recourerez sûrement à
procmail pour ventiler la centaine de messages quotidiens qui en
provient. Pour réduire le besoin en bande passante, servez vous de la
commande SET OpenGL-GameDev-L DIGEST. Cette liste est inappropriée si
vous cherchez des documents d'introduction. L'archivage est assuré par
le logiciel ListServ. Les commandes INDEX OpenGL-GameDev-L et GET
OpenGL-GameDev-L "filename" permettent de se faire un idée avant de
souscrire.
9.3 IGlide met-il en oeuvre OpenGL ?
Non. Glide est une API propriétaire de 3Dfx dont plusieurs fonctions
sont spécifiques aux composants Voodoo Graphics (tm) et Voodoo Rush
(tm). Une librairie OpenGL 3Dfx est en cours de réalisation ( voyez
plus bas ). Diverses fonctionnalités Glide nécessiteraient des
extensions à OpenGL, certaines étant déjà disponibles par ailleurs (
les textures palettisées par exemple ).
La librairie Mesa de Brian Paul et le pilote Mesa Voodoo de David
Bucciarelli sont ce qui se rapproche le plus d'une version Linux
d'OpenGL accélérée grâce à des périphériques particuliers ( voyez plus
bas ).
9.4 Existe-t-il un pilote OpenGL pour 3Dfx ?
Les sites web de 3Dfx et de Quantum3D annoncent une version d'OpenGL
pour Voodoo Graphics (tm) en fin d'année 1997. Le pilote est
actuellement en bêta et seuls peuvent y accéder les développeurs ayant
souscrit à un accord de bêta-test spécifique.
Aucun portage vers Linux n'a encore été annoncé pour l'instant.
9.5 Existe-t-il une version commerciale d'OpenGL pour Linux et 3Dfx ?
Je n'ai entendu parler de rien de tel. La dernière fois que je m'y
suis intéressé, ni MetroX, ni XInside ne proposaient OpenGL.
9.6 Qu'est-ce que Mesa ?
Mesa constitue une réalisation libre de l'API OpenGL, dont l'auteur
est Brian Paul, et à laquelle de nombreuses personnes ont contribué.
Ses performances sont respectables et bien qu'elle ne soit pas
certifiée de façon officielle, sa conformité aux spécifications de
l'ARB la rend, sinon parfaitement compatible avec OpenGL, du moins
plus complète que bon nombre de produits commerciaux.
9.7 Mesa fonctionne-t-elle avec 3Dfx ?
La dernière version de Mesa 2.6 fonctionne avec Linux Glide 2.4. Bien
que ce soit le cas depuis des versions plus anciennes, ce pilote est
encore en développement. Attendez vous donc à des bugs et des
performances éloignées de l'optimum. Les progrès sont cependant
permanents et les correctifs aux bugs viennent souvent assez vite.
Il vous faudra l'archive de la bibliothèque Mesa : iris.ssec.wisc.edu
FTP site. Il est également conseillé de s'abonner à la liste de
diffusion, notamment pour débusquer les bugs ou les limitations du
pilote. Vérifiez que vous disposez bien de la version la plus récente.
Mesa 3.0 est en préparation.
9.8 Qu'en est-il de la portabilité de Mesa pour Glide?
Mesa est disponible pour Linux et Win32. Une application qui s'appuie
sur Mesa ne devrait être spécifique qu'en ce qui concerne le code lié
au système. Typiquement il s'agira de passer d'X à Windows ou de WGL à
GLX. Si vous avez recours à GLUT ou à Qt, vous devriez éviter toutes
les spécificités dues au système pour une grande majorité
d'applications. Il n'y a que quelques domaines particuliers, comme
l'échantillonage des positions successives de la souris, qui ne sont
pas couverts par les GUI portables dont on dispose.
Mesa/Glide est également disponible pour DOS. Il s'agit d'un portage
32 bits maintenu par Charlie Wallace qui assure la synchronisation
avec Mesa. Pour la dernière version, reportez vous à :
www.geocities.com/~charlie_x/.
9.9 Où trouver des informations sur Mesa ?
La page web de Mesa : www.ssec.wisc.edu/~brianp/Mesa.html. L'archive
de la liste de distribution Mesa : www.iqm.unicamp.br/mesa/. Cette
liste n'est certes pas dédiée à 3Dfx ni à Glide mais il s'agit d'un
bon point de départ si le recours au matériel 3Dfx pour accélérer Mesa
vous intéresse.
9.10 Où trouver des informations sur Mesa Voodoo ?
Pour les informations les plus à jour sur le pilote Mesa Voodoo de
David Bucciarelli tech.hmw@plus.it, reportez vous à la page web :
www-hmw.caribel.pisa.it/fxmesa/.
9.11 Mesa gère-t-il le texturage multiple ?
Pas encore en ce qui concerne Mesa 2.6 mais la question est à l'étude.
Vous disposerez probablement d'une extension OpenGL EXT_multitexture
sous Mesa une fois qu'elle sera achevée. Il n'y a pas de
spécifications figées pour le texturage multiple dans OpenGL. La
version 1.2 d'OpenGL est censée préciser les choses. Les prochaines
versions de Mesa incluront peut être une mise en oeuvre spécifique au
pilote Glide mais ceci ne sera pas une priorité tant qu'il ne se
trouvera que quelques cartes Obsidian Quantum3D à intégrer plusieurs
TMU. La banalisation des cartes Voodoo 2 (tm) changera certainement la
donne.
9.12 Mesa supporte-t-elle le filtrage tri-linéaire en une seule étape ?
Linux Glide gère cette opération mais ce n'est pas le cas de Mesa ( au
moins jusqu'à la version 2.6 ). Le développement est en cours.
9.13 Qu'est-ce que le hack Mesa ( "Window Hack" ) ?
La dernière version de Mesa incorpore une fonctionnalité expérimentale
pour XFree86 sous Linux. L'émulation GLX de Mesa copie le dernier
tampon de mémoire vidéo mis à jour depuis la carte Voodoo Graphics
(tm) vers la mémoire vidéo pour chaque appel à la fonction
glXSwapBuffers. Mesa offre également cette possibilité sous Windows.
Il en résulte bien sûr une charge assez importante au niveau du bus
PCI, et ce d'autant plus que le mécanisme utilise l'extension SHM du
MIT à X11 et non pas le DGA XFree86 lors des accès à la mémoire vidéo.
On pourrait théoriquement employer la même technique avec SVGA par
exemple. Le calcul du rendu limité à une fenêtre peut donc tirer
pleinement parti de la présence d'une carte Voodoo Graphics (tm). De
plus, on évite l'intermédiation VGA qui dégrade le signal vidéo ( les
moniteurs haut de gamme tels le EIZO F784-T l'illustrent très bien ).
Notez que cette fonctionnalité expérimentale n'a _RIEN_ à voir avec le
Voodoo Rush (tm). Elle ne concerne que les cartes Voodoo Rush (tm), un
point c'est tout. Enfin, il est nécessaire d'utiliser une version
modifiée de GLUT puisque la gestion des évènements et la cohabitation
avec le gestionnaire de fenêtres sont alors du ressort de
l'application ( et non du pilote ! ).
Vérifiez le positionnement des variables suivantes :
_________________________________________________________________
export SST_VGA_PASS=1 # to stop video signal switching
export SST_NOSHUTDOWN=1 # to stop video signal switching
export MESA_GLX_FX="window" # to initiate Mesa window mode
_________________________________________________________________
Si vous oubliez une des variables SST, votre carte VGA sera désactivée
et l'affichage disparaîtra. X restera cependant toujours actif et vous
risquez d'éprouver certaines difficultés pour revenir en aveugle à une
situation normale.
Pour clore le sujet, on remarquera que la bibliothèque libMesaGL.a (
ou celle en .so ) est susceptible de contenir les fonctions
d'interfaçage pour différents clients. Ainsi les fonctions GLX, OSMesa
et fxMesa ( voir même SVGAMesa ) peuvent être compilées au sein d'une
unique bibliothèque libMesaGL.a. Un programme client attentif saura
les appeler simultanément.
9.14 Qu'en est-il de GLUT ?
La distribution GLUT de Mark Kilgard constitue une excellente
ressource pour ce qui est des applications type et des utilitaires.
Vous la trouverez à : reality.sgi.com/mjk_asd/glut3/. La dernière
version est GLUT 3.6 et les discussions ont commencé pour GLUT 3.7 (
alias GameGLUT ). Mark Kilgard ayant récemment quitté SGI, il est
possible que l'archive se déplace en cours d'année; pour l'instant
elle reste en place sur le site de SGI.
Il existe une liste de diffusion spécifique à GLUT : glut@perp.com.
Envoyez à majordomo@perp.com le message suivant :
_________________________________________________________________
help
info glut
subscribe glut
end
_________________________________________________________________
GLUT gérant le dédoublement des tampons de mémoire, le fenêtrage, les
évènements et d'autres opérations fortement liées au matériel et au
système d'exploitation, la cohabitation de GLUT avec Voodoo Graphics
(tm) nécessite un support qui est encore en cours de développement au
niveau de GLX pour Mesa. La plupart des situations sont déjà prises en
compte.
10. FAQ: Quake ?
10.1 Où en est le pilote 3Dfx GL pour Quake ?
Quake GL, encore appelé mini-driver, ou miniport, ou Game GL, ou GL
alpha, ne met en oeuvre qu'un sous ensemble d'OpenGL orienté vers
Quake ( cf http://www.cs.unc.edu/~martin/3dfx.html pour une liste
officieuse de programmes acceptés ). Quake GL n'est maintenu par
personne et ne bénéficie d'aucun support. A l'origine il s'agissait
d'une DLL Win32 ( opengl32.dll ) fournie par 3Dfx. Cette DLL n'a pas
été portée sous Linux et il n'est pas prévu qu'elle le soit un jour.
10.2 Existe-t-il une version Linux de 3Dfx glQuake ?
Oui. Les binaires de linuxquake v0.97 supportent Mesa et Glide.
L'exécutable du programme q2test de Quake2 pour Linux et Voodoo
Graphics (tm) est également disponible. L'apparition en janvier 1998
de linuxquake2-3.10 offre une version complète de Quake2 pour Linux.
Dave "Zoid" Kirsch est officiellement chargé de tenir à jour les
portages Linux de Quake, Quakeworld, Quake2 ainsi les versions Mesa.
Notez qu'aucune version de Quake pour Linux ne bénéficie du support
officiel de la part d'Id Software.
Pour les dernières versions : ftp.idsoftware.com/idstuff/quake/unix/.
10.3 glQuake fonctionne-t-il dans une fenêtre XFree86 ?
Une mise à jour de Mesa et de la version associée de glQuake pour
Linux est en cours. Mesa supporte le fenêtrage via GLX mais glQuake
pour Linux n'a pas recours à GLX.
10.4 Comment réinitialiser l'affichage après un plantage de glQuake ?
Essayez d'utiliser le programme pass fourni avec la distribution
Glide. Tout ce qu'il fait consiste à activer puis désactiver la carte.
Si la carte dialogue bien avec la machine, ceci devrait la
réinitialiser (la carte :)). Si la carte est belle et bien bloquée,
ceci ne fonctionnera pas et un redémarrage est à envisager.
10.5 Des problèmes avec Quake pour Linux ?
Voici une liste, à jour au 7 janvier 1998, des problèmes éventuels.
Est absent tout ce qui n'a pas trait au matériel 3Dfx.
* Quake2 doit être lancé par le super utilisateur si l'on souhaite
recourir à la SVGALib et/ou au rendu GL. Ce n'est pas nécessaire
sous X11 mais les périphériques liés à la souris et au son doivent
être accessibles en lecture/écriture par les utilisateurs courants
du logiciel.
* Certains artefacts se manifestent pendant le chargement avec X11.
Cela reste normal en 16 bits. Le programme ne fonctionnera pas en
24 bits ( TrueColor ). Ce serait de toute façon assez lent.
* On signale divers plantages en cas de rendu via GL. Vérifiez que
vous avez bien installé la bibliothèque Mesa fournie avec Quake2 !
Les versions plus anciennes ne fonctionnent pas correctement.
* Si vous ressentez un "retard" avec le rendu GL, si vous avez
l'impression que la fréquence de rafraîchissement ne suit pas les
déplacements de votre souris, tapez "gl_finish 1" dans la console.
Vous forcez ainsi la mise à jour en fonction du défilement des
images.
* Vérifiez que gpm ou tout autre sélection sont désactivés quand le
moteur de rendu GL est en action ou alors la souris sera
inutilisable lorsque Quake2 fonctionne avec GL.
10.6 Les trous de sécurité de Quake pour Linux
Ainsi que Dave Kirsch l'a signalé le 28 janvier 1998, Quake2 pour
Linux présente un trou de sécurité. Même si le README ne le mentionne
pas particulièrement, Quake2 ne doit pas être setuid.
Si vous désirez employer les routines de rendu ref_soft et ref_gl, il
vous faudra exécuter Quake2 sous l'identité root. N'activez pas le
droit attribuant les privilèges de super utilisateur à toute
invocation du programme !
Le rendu sous X11 ne requiert pas les privilèges root ( dès lors que
le /dev/dsp est accessible à tous en écriture ). Le serveur associé
n'a bien entendu pas non plus besoin de droits particuliers.
La question des droits root exigés par certains jeux est récurrente à
Linux depuis plusieurs années. Entre autre objectifs, le projet GGI
tente de résoudre ce problème. L'avenir devrait apporter un ref_ggi.
10.7 Linuxquake supporte-t-il le texturage multiple ?
glQuake offrira vraisemblablement une telle extension dès lors que le
pilote OpenGL impliqué l'autorisera. Pour l'instant, Mesa et le pilote
Glide pour Linux ne gèrent pas cette extension. Le texturage multiple
n'est donc pas disponible. Reportez vous à la section sur Mesa et le
texturage multiple pour davantage de détails.
10.8 Où trouver des informations à jour sur glQuake pour Linux ?
Essayez les sites suivants : "The Linux Quake Resource" à
linuxquake.telefragged.com, ou "Linux Quake Page" à
www.planetquake.com/threewave/linux/. Jetez donc un oeil dans la base
de données "SlipgateCentral" pour trouver des sites Quake Linux :
www.slipgatecentral.com.
11. FAQ: solutions aux problèmes courants ?
11.1 Cette carte a-t-elle été testée ?
Une liste suit. Je ne dispose pas d'une liste achevée de vendeurs et
de cartes vu que l'on n'a pas mis en évidence de difficultés liées à
une carte spécifique. Pour l'instant, seuls 3Dfx et Quantum3D ont
procuré des cartes aux développeurs afin que ceux-ci les testent. Les
cartes Quantum3D s'avèrent donc un choix raisonnable. Toutes les
autres cartes à base de composants Voodoo Graphics (tm) sont censées
fonctionner. Ont été signalées la Righteous 3D d'Orchid, la Maxi 3D
Gamer de Guillemot et la Monster 3D de Diamond.
Les fabricants souhaitant valider la compatibilité de leurs cartes
Voodoo Graphics (tm), Voodoo Rush (tm) ou Voodoo 2 (tm) avec les
versions à venir de Linux, de XFree86, de Glide pour linux et de Mesa
peuvent contacter l'auteur de ce document qui se fera un plaisir de
transmettre leur requête aux personnes ayant la charge des pilotes
concernés. Si vous êtes tenté par le portage de Linux Glide sur une
plateforme autre que les compatibles PC - DEC alpha par exemple -,
prenez contact avec Daryll Strauss qui se charge de la mise à jour de
Glide pour Linux : daryll@harlot.rb.ca.us
11.2 Échec lors du changement des privilèges d'entrées/sorties ?
Il faut que vous soyez root ou bien que l'identité associée à votre
application puisse être telle ( cf setuid ). Le pilote se sert du
périphérique /dev/mem pour les transferts DMA. Ce n'est pas sans
raisons que seul root en bénéficie du droit d'accés. Reportez vous au
README dans la distribution de Glide pour Linux.
11.3 Un fonctionnement sans les droits root est-il possible ?
Non. Des solutions de remplacement sont en cours de réalisation.
11.4 L'affichage est déplorable !
Si votre configuration nécessite un intermédiaire VGA analogique, la
qualité d'affichage avec SVGA ou X11 peut s'avérer décevante. Essayez
donc un autre câble. Ceux qui accompagnent la Monster 3D de Diamond
sont notoirement plus mauvais que ceux livrés avec la Righteous 3D
d'Orchid. Quoi qu'il en soit, il y aura toujours une dégradation
résiduelle.
Si la carte accélératrice délivre une image médiocre en 640 par 480 en
plein écran, un problème matériel est envisageable. Contactez le
fabricant de la carte ( pas 3Dfx ! ) puisque la qualité du signal
vidéo, indépendamment du circuit accélérateur, dépend du choix de la
RAMDAC et des composants de sortie.
11.5 La dernière image ne disparaît pas !
Vous avez quitté votre application via Ctrl-C ou d'une autre façon
brutale. La carte accélératrice conserve le contenu de son tampon de
mémoire vidéo comme source du signal vidéo tant qu'on ne lui demande
pas explicitement d'arrêter.
11.6 L'économiseur d'écran se déclenche ( deux écrans ) ?
Lorsqu'une application s'achève dans une configuration à deux écrans,
la carte accélératrice ne fournit plus de signal vidéo et
l'économiseur se déclenche. Pour éviter ça :
_________________________________________________________________
setenv SST_DUALSCREEN 1
_________________________________________________________________
11.7 Mon ordinateur semble se bloquer ( X11, un seul écran ) !
Si X fonctionne en même temps qu'une application Glide, la souris se
retrouve surement à pointer hors de la fenêtre. Les évènements clavier
n'atteignent donc plus l'application.
Si votre programme concurrence X11, il est conseillé d'installer une
fenêtre plein écran ou de se servir des fonctions XGrabPointer et
XGrabServer tandis que le serveur X est désactivé. Notez que le
recours à XGrabPointer et à XGrabServer ne qualifie pas une
application comme particulièrement propre à l'égard de X; le système
pourrait ainsi se retrouver bloqué.
Si vous rencontrez ce problème alors que X n'est pas lancé, vérifiez
qu'il n'y a pas de conflit matériel ( voir ci-dessous ).
11.8 Ma machine se bloque ( un ou deux écrans ) ?
Si le système ne répond plus et que la perte de focus est à exclure,
un conflit matériel plus ou moins subtil est à envisager. Reportez
vous au paragraphe traitant des problèmes d'installation pour plus de
détails.
Les difficultés ne se limitent pas aux conflits d'adresses ( cf
ci-dessous ). Si vous écrivez vous même vos applications, oublier de
fermer ses sommets est une cause courante de blocage. Reportez vous à
la section "snapping" de la documentation Glide.
11.9 Ma machine se bloque ( avec une carte S3 ) ?
Il existe un problème de recouvrement de zones mémoires spécifique aux
cartes S3. Le site web 3Dfx contient des informations et un patch au
problème suscité mais seul Windows est concerné. Certaines cartes S3,
typiquement les Diamond Stealth S3 968 les plus anciennes, réservent
davantage de mémoire qu'elles n'en utilisent. Le Voodoo Graphics (tm)
doit donc être placé ailleurs. Comme rien de tel n'a été signalé avec
Linux, peut-être s'agit-il d'une *spécificité* Windows ?
11.10 Pas de conflit d'adresse mais la machine se bloque quand même !
Peut-être avez vous une carte qui ne gère pas le PCI de façon tout à
fait standard. L'ASUS TP4XE possède à cet égard un connecteur dit
"Media Slot" c'est-à-dire un connecteur PCI non standard qui étend ce
dernier de façon à accueillir certaines cartes ASUS combinant des
fonctions son et SCSI. L'auteur de ce document a éprouvé de sérieuses
difficultés avec une Monster 3D de chez Diamond à laquelle il avait
affecté ce connecteur. Le déplacement de la carte vers un connecteur
PCI standard a supprimé tous les dysfonctionnements. NdT: si le bios
de votre carte ASUS comprend quelque chose suggérant un vague couplage
des connecteurs PCI 3 et 4, lisez le manuel et essayez d'autre options
sans quoi vous risquez des problèmes dès qu'une carte quelconque
occupera le connecteur maudit !
11.11 Mesa est actif mais n'accède pas à la carte !
Vérifiez que vous avez bien recompilé toutes les bibliothèques,
notamment les paquetages requis par les démos. N'oubliez pas que GLUT
ne gère pas encore le Voodoo Graphics (tm). Vérifiez que vous avez
supprimé les anciennes bibliothèques, que vous avez relancé ldconfig
et/ou positionné correctement votre LD_LIBRARY_PATH. Mesa inclut
plusieurs pilotes ( MIT SHM pour X11, rendu hors écran, Mesa Voodoo )
utilisables simultanément et il se peut que vous deviez changer
explicitement le pilote employé ( reportez vous à la fonction
MakeCurrent ) si le Voodoo Graphics (tm) n'est pas choisi par défaut.
11.12 Réinitialiser une carte SLI ( configuration à deux cartes ) ?
Si le fonctionnement en mode SLI d'une carte Obsidian Quantum 3D est
interrompu brutalement, les cartes se retrouvent dans un état des plus
incertains. Si vous avez deux cartes, vous utiliserez un programme
nommé resetsli pour réinitialiser les cartes. Tant que vous ne l'aurez
pas appelé, la réinitialisation des cartes Obsidian restera
impossible.
11.13 Réinitialiser une carte SLI ( configuration à une seule carte ) ?
Le programme resetsli susmentionné reste sans effet sur une carte
Obsidian SLI ( à savoir la 100-4440SB ). Rebootez en appuyant sur le
bouton reset pour réinitialiser complètement la carte.
distrib
>
Mandriva
>
2010.0
>
i586
>
media
>
contrib-release
>
by-pkgid
>
ebac5394abc62d2e0b61505bfba9712a
>
files
>
3
