/usr/share/doc/HOWTO/fr-html/3Dfx-HOWTO.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for HTML5 for Linux version 5.2.0">
<meta name="GENERATOR" content="LinuxDoc-Tools 0.9.72">
<title>HOWTO 3Dfx pour Linux</title>
</head>
<body>
<h1>HOWTO 3Dfx pour Linux</h1>
<h2>Bernd Kreimeier ( <a href=
"mailto:bk@gamers.org">bk@gamers.org</a>)</h2>
v1.16, 6 February 1998
<hr>
<em>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.</em>
<hr>
<p><!--
Acc&eacute;l&eacute;ration du graphisme 3D avec les composants Voodoo 3Dfx 
--></p>
<p><!--
XFree86 et 3Dfx Voodoo
-->
 <!--
OpenGL et 3Dfx Voodoo
-->
 <!--
Mesa et 3Dfx Voodoo
-->
 <!--
GLUT et 3Dfx Voodoo
-->
 <!--
GGI et 3Dfx Voodoo
--></p>
<p><!--
3Dfx
-->
 <!--
Composants Voodoo
-->
 <!--
API Glide pour Linux
--></p>
<p><!--
Quantum 3D
-->
 <!--
Cartes graphiques Obsidian
--></p>
<p><!--
Orchid Righteous 3D
-->
 <!--
Canopus Pure 3D
-->
 <!--
Hercules Stealth 3D
-->
 <!--
Diamond Monster 3D
--></p>
<p><!--
Quake pour Linux
-->
 <!--
GLQuake pour Linux
-->
 <!--
GLQuake et 3Dfx Voodoo
--></p>
<h2><a name="s1">1. Introduction</a></h2>
<p>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.</p>
<p>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.</p>
<h2><a name="ss1.1">1.1 Contributions et contacts</a></h2>
<p>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.</p>
<p>Daryll Strauss <a href=
"mailto:Daryll%20Strauss%20%3Cdaryll@harlot.rb.ca.us%3E">daryll@harlot.rb.ca.us</a>
a effectué le portage, Paul J. Metzger <a href=
"mailto:Paul%20J.%20Metzger%20%3Cpjm@rbd.com%3E">pjm@rbd.com</a>
modifications du pilote Mesa Voodoo ( écrit par David Bucciarelli )
<a href=
"mailto:David%20Bucciarelli%20%3Ctech.hmw@plus.it%3E">tech.hmw@plus.it</a>)
pour Linux, Brian Paul <a href=
"mailto:Brian%20Paul%20%3Cbrianp@RA.AVID.COM%3E">brianp@RA.AVID.COM</a>
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
<a href=
"mailto:Charlie%20Wallace%20%3CCharlie.Wallace@unistudios.com%3E">Charlie.Wallace@unistudios.com</a>.
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 <a href=
"mailto:Dave%20Kirsch%20%3Czoid@idsoftware.com%3E">zoid@idsoftware.com</a>.
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.</p>
<p>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 : <a href=
"http://pobox.com/~cg/sgmltools">pobox.com/~cg/sgmltools</a>.</p>
<h2><a name="ss1.2">1.2 Noms des produits et protection
industrielle</a></h2>
<p>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.</p>
<h2><a name="ss1.3">1.3 Historique</a></h2>
<dl>
<dt><b>Version 1.03</b></dt>
<dd>
<p>First version for public release.</p>
</dd>
<dt><b>Version 1.16</b></dt>
<dd>
<p>Current version v1.16 6 February 1998.</p>
</dd>
</dl>
<h2><a name="ss1.4">1.4 Versions actualisées du document</a></h2>
<p>Vous trouverez la version la plus récente de l'original en
langue anglaise de ce document à la page web : <a href=
"http://www.gamers.org/dEngine/xf3D/">www.gamers.org/dEngine/xf3D/</a>.</p>
<p>Les nouvelles versions seront postées périodiquement sur le
forum Usenet <a href=
"news:comp.os.linux.answers">comp.os.linux.answers</a>. Des
archives sont également disponibles sur divers serveurs ftp
anonymes tels que <a href=
"ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/">ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/</a>.</p>
<p>De nombreux sites web proposent des versions hypertextes,
notamment <a href=
"http://sunsite.unc.edu/LDP/">sunsite.unc.edu/LDP/</a>. La plupart
des distributions de Linux sur CD incluent les HOWTO, en général
dans le répertoire <code>/usr/doc/</code>. Certains vendeurs
proposent des versions imprimées.</p>
<p>Si vous traduisez ce document dans une autre langue, faites le
moi savoir que je puisse y faire référence.</p>
<h2><a name="ss1.5">1.5 Retour d'expérience</a></h2>
<p>Je m'en remets à vous, lecteur, pour rendre ce HOWTO utile.
Envoyez les corrections, suggestions et commentaires à mon adresse
( <a href="mailto:bk@gamers.org">bk@gamers.org</a> ) et je les
prendrai en compte dans une nouvelle version. Mentionnez
<code>HOWTO 3Dfx</code> dans le champ Sujet du courrier afin que
procmail le dirige vers le fichier adéquat.</p>
<p>Avant de signaler un bug ou de poser une question, <em>lisez ce
HOWTO dans son intégralité</em>. Vous pourrez ensuite envoyer un
compte rendu <em>détaillé</em> du problème.</p>
<p>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 ( <a href=
"mailto:linux-howto@sunsite.unc.edu">linux-howto@sunsite.unc.edu</a>).</p>
<h2><a name="ss1.6">1.6 Licence</a></h2>
<p>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 : <a href=
"http://sunsite.unc.edu/LDP/COPYRIGHT.html">sunsite.unc.edu/LDP/COPYRIGHT.html</a>.</p>
<h2><a name="s2">2. Technologie des accélérateurs
graphiques</a></h2>
<h2><a name="ss2.1">2.1 Les bases</a></h2>
<p>Il s'agit ici de survoler <em>brièvement</em> 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.</p>
<h2><a name="ss2.2">2.2 Configuration matérielle</a></h2>
<p>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.</p>
<p>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.</p>
<h2><a name="ss2.3">2.3 Quelques mots sur l'organisation du Voodoo
Graphics (tm)</a></h2>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h2><a name="s3">3. Installation</a></h2>
<p>La mise en place du 3Dfx sous Linux passe par les étapes
suivantes :</p>
<ol>
<li>installation de la carte;</li>
<li>installation des logiciels Glide;</li>
<li>compilation, édition de liens et/ou exécution de
l'application.</li>
</ol>
<p>Les sections suivantes couvrent ces étapes en détail.</p>
<h2><a name="ss3.1">3.1 Installation de la carte.</a></h2>
<p>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&amp;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.</p>
<p>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.</p>
<h3>Solutions aux problèmes d'installation</h3>
<p>Afin de vérifier l'installation et l'adressage mémoire des
périphériques, faites un <code>cat /proc/pci</code>. La sortie
devrait ressembler à ce qui suit :</p>
<hr>
<pre>
  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.
</pre>
<hr>
( cas d'une Diamond Monster 3D utilisée conjointement à une Diamond
Stealth-64 ). Un <code>cat /proc/cpuinfo /proc/meminfo</code>
aidera à résoudre les conflits et sera utile pour signaler un bug.
<p>Les noyaux courants afficheront peut-être au démarrage :</p>
<hr>
<pre>
Jun 12 12:31:52 hal kernel: Warning : Unknown PCI device (121a:1).
Please read include/linux/pci.h 
</pre>
<hr>
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 <code>/usr/include/linux/pci.h</code> afin de
transmettre les informations utiles à <a href=
"mailto:linux-pcisupport@cao-vlsi.ibp.fr">linux-pcisupport@cao-vlsi.ibp.fr</a>.
<p>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.</p>
<h3>Configuration du noyau</h3>
<p>Seule la gestion du bus PCI est requise. Le <a href=
"http://sunsite.unc.edu/mdw/HOWTO/Kernel-HOWTO.html">Linux Kernel
HOWTO</a> fournit tous les détails relatifs à la compilation d'un
noyau.</p>
<h3>Configuration des périphériques</h3>
<p>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 <code>/dev/dsp</code> et
<code>/dev/audio</code> dont la présence n'est pas garantie, les
pilotes reposent ici sur le <code>/dev/mem</code> qui est toujours
disponible. Il vous faudra bien sûr disposer des droits de
super-utilisateur ou recourir à <code>setuid</code> pour accéder à
la carte accélératrice.</p>
<h2><a name="ss3.2">3.2 Gestion des écrans</a></h2>
<p>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.</p>
<h3>Affichage avec un seul écran</h3>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h3>Un moniteur avec deux entrées vidéo</h3>
<p>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.</p>
<h3>Deux écrans</h3>
<p>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.</p>
<p>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 :</p>
<hr>
<pre>
setenv SST_DUALSCREEN 1
</pre>
<hr>
pour maintenir la sortie vidéo active.
<h2><a name="ss3.3">3.3 Installation des logiciels Glide</a></h2>
<p>Les pilotes et la librairie Glide sont réunis dans un unique
fichier compressé. Décompactez/détarez les avec <code>tar</code> et
<code>gzip</code> 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 <code>/usr/local/glide/</code> et le chemin d'accés
aux librairies correspondants est ajouté au <code>ld.conf</code>.
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.</p>
<p>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 <code>can't load library 'libglide.so'</code>.</p>
<h3>Le programme <code>detect</code></h3>
<p>La distribution logicielle inclut le programme
<code>bin/detect</code> ( les sources ne sont pas disponibles ). Le
lançant sous l'identité root, vous obtiendrez quelque chose dans le
genre :</p>
<hr>
<pre>
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
</pre>
<hr>
Si vous n'êtes pas root, vous serez gratifié d'un :
<hr>
<pre>
Permission denied: Failed to change I/O privilege. Are you root?
</pre>
<hr>
Si vous signalez un bug, joignez une copie de la sortie écran de
<code>detect</code>.
<h3>Test de l'installation</h3>
<p>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 <a href=
"http://www.3dfx.com/">www.3dfx.com</a> pour plus de détails.</p>
<p>Bien que des binaires soient disponibles, il est recommandé de
compiler soi-même les programmes. Certains exécutables ont besoins
de fichiers tels <code>alpha.3df</code> 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 <code>Press A Key To Begin Test</code>.
Méfiez vous d'un éventuel accaparement des évènements de saisie par
X11 si ce dernier fonctionne également sur le même écran.</p>
<p>Le fichier README.test donne la liste des programmes ainsi que
divers détails.</p>
<h2><a name="s4">4. Réponses aux questions les plus courantes ( la
Foire Aux Questions )</a></h2>
<p>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 :</p>
<ul>
<li>FAQ: Quel Matériel ?</li>
<li>FAQ: Voodoo Graphics (tm) ? 3Dfx ?</li>
<li>FAQ: Glide ?</li>
<li>FAQ: Glide et SVGA ?</li>
<li>FAQ: Glide et XFree86 ?</li>
<li>FAQ: Glide ou OpenGL/Mesa ?</li>
<li>FAQ: Et Quake ?</li>
<li>FAQ: A marche pôôô...</li>
</ul>
La plupart des problèmes devraient trouver une réponse ici.
<h2><a name="s5">5. FAQ: quel Matériel ?</a></h2>
<h2><a name="ss5.1">5.1 Système nécessaire :</a></h2>
<p>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.</p>
<p>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.</p>
<h2><a name="ss5.2">5.2 Est-ce que ça fonctionne avec Linux-Alpha
?</a></h2>
<p>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.</p>
<p>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.</p>
<h2><a name="ss5.3">5.3 Quels sont les composants 3Dfx compatibles
avec la distribution ?</a></h2>
<p>Pour l'instant, le Voodoo Graphics (tm) 3Dfx est accepté. Le
Voodoo Rush (tm) n'est pas encore géré.</p>
<h2><a name="ss5.4">5.4 Le Voodoo Rush (tm) est-il géré ?</a></h2>
<p>La version actuelle de Glide pour Linux ne gère pas le Voodoo
Rush (tm). Une mise à jour est en cours de développement.</p>
<p>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.</p>
<p>Les cartes Voodoo Rush (tm) telles l'<em>Hercules Stingray
128/3D</em> ou l'<em>Intergraph Intense Rush</em> ne sont donc
actuellement pas gérées.</p>
<h2><a name="ss5.5">5.5 Le Voodoo 2 (tm) est-il géré ?</a></h2>
<p>Le portage actuel de la librairie Glide ne supporte pas le
Voodoo 2 (tm).</p>
<h2><a name="ss5.6">5.6 Quelles sont les cartes compatibles avec
Glide ?</a></h2>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Les cartes qui ne reposent pas sur des composants fournis pas
3Dfx telles celles que fabriquent S3, Matrox, 3Dlabs et Videologic
ne fonctionnent <em>PAS</em> avec les pilotes 3Dfx et débordent du
cadre de ce document.</p>
<h2><a name="ss5.7">5.7 Qu'est-ce qui distingue les cartes
?</a></h2>
<p>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.</p>
<p>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 ).</p>
<p>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.</p>
<h2><a name="ss5.8">5.8 Qu'en est-il de l'AGP?</a></h2>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Voici ce que donne <code>/proc/pci</code> :</p>
<hr>
<pre>
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.
</pre>
<hr>
<h2><a name="s6">6. FAQ: Voodoo Graphics (tm) ? 3Dfx ?</a></h2>
<h2><a name="ss6.1">6.1 3Dfx, qui est-ce ?</a></h2>
<p>3Dfx est un fabricant de composants pour l'accélération
graphique 3D basé à San Jose. Leur site officiel : <a href=
"http://www.3dfx.com/">www.3dfx.com</a>. 3Dfx ne vend pas de
cartes, contrairement à d'autres sociétés ( Quantum3D par exemple
).</p>
<h2><a name="ss6.2">6.2 Qui est Quantum3D ?</a></h2>
<p>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 : <a href=
"http://www.quantum3d.com/">www.quantum3d.com</a> Pour toute
question concernant Quantum3D, envoyez un message électronique à :
<a href="mailto:info@quantum3d">info@quantum3d</a>.</p>
<h2><a name="ss6.3">6.3 Voodoo Graphics (tm), quès acco ?</a></h2>
<p>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.</p>
<h2><a name="ss6.4">6.4 Voodoo Rush (tm) ?</a></h2>
<p>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.</p>
<h2><a name="ss6.5">6.5 Voodoo 2 (tm) ?</a></h2>
<p>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).</p>
<p>Bien que le Voodoo 2 (tm) soit censé être compatible, une
nouvelle version de Glide devra être développée pour Linux.</p>
<h2><a name="ss6.6">6.6 Qu'est ce qu'un intermédiaire VGA
?</a></h2>
<p>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.</p>
<p>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é.</p>
<h2><a name="ss6.7">6.7 Qu'est-ce que le Texelfx, un TMU ?</a></h2>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h2><a name="ss6.8">6.8 Qu'est ce qu'une unité Pixelfx ?</a></h2>
<p>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é.</p>
<h2><a name="ss6.9">6.9 Qu'est-ce que le mode SLI ?</a></h2>
<p>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é.</p>
<p>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).</p>
<p>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.</p>
<h2><a name="ss6.10">6.10 Le SLI avec une seule carte ?</a></h2>
<p>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 ).</p>
<h2><a name="ss6.11">6.11 Quelle quantité de mémoire ?</a></h2>
<p>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;.</p>
<hr>
<pre>
    "SLI / Pixelfx / Texelfx1 / Texelfx2 "
</pre>
<hr>
Une carte courante munie de deux fois 2 Mo est décrite par le
quadruplet <code>1/2/2/0</code>, la quantité totale de mémoire
étant égale au minimum requis de 4Mo. Une Canopus Pure 3D, munie de
6 Mo, est du type <code>1/2/4/0</code>. Une Obsidian-2220 avec deux
Texelfx; est du type <code>1/2/2/2</code> et à une Obsidian
SLI-2440 board correspondrait <code>2/2/4/4</code>. 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 <code>2/4/4/4</code> pour une quantité totale de mémoire de
<code>SLI*(Pixelfx+Texelfx1+Texelfx2)</code> soit 24 Mo.
<h2><a name="ss6.12">6.12 Le Voodoo Graphics (tm) gère-t-il
l'affichage en 24 ou 32 bits ?</a></h2>
<p>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é.</p>
<h2><a name="ss6.13">6.13 Le calcul de profondeur du Voodoo
Graphics (tm) est-t-il en 24 ou 32 bits par pixel ?</a></h2>
<p>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.</p>
<h2><a name="ss6.14">6.14 Quelles résolutions offre le Voodoo
Graphics (tm) ?</a></h2>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h2><a name="ss6.15">6.15 Quelles sont les tailles de texture
disponibles ?</a></h2>
<p>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.</p>
<h2><a name="ss6.16">6.16 Le Voodoo Graphics (tm) gère-t-il les
textures palettisées ?</a></h2>
<p>Les composants Voodoo Graphics (tm) et Glide gèrent l'extension
correspondante de OpenGL. La dernière version de Mesa comporte les
extensions <code>GL_EXT_paletted_texture</code> et
<code>GL_EXT_shared_texture_palette</code>.</p>
<h2><a name="ss6.17">6.17 Qu'en est-il du dépassement de fréquence
d'horloge ?</a></h2>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h2><a name="ss6.18">6.18 Où puis-je trouver d'autres informations
concernant le Voodoo Graphics (tm) ?</a></h2>
<p>3Dfx a rédigé une FAQ qui devrait se trouver à l'adresse
suivante : <a href="http://www.3dfx.com/voodoo/faq.html">web
site</a>. Vous trouverez des informations sur la vente aux adresses
suivantes : <a href=
"http://www.3dfx.com/voodoo/sale/">www.3dfx.com</a> et <a href=
"http://www.quantum3d.com/">www.quantum3d.com</a>.</p>
<p>Certains sites non-officiels sont bien renseignés : <a href=
"http://www.ve3d.com/">www.ve3d.com</a>, <a href=
"http://www.ve3d.com/">www.ve3d.com</a>.</p>
<h2><a name="s7">7. FAQ: Glide? TexUS?</a></h2>
<h2><a name="ss7.1">7.1 Glide, quès acco ?</a></h2>
<p>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.</p>
<h2><a name="ss7.2">7.2 TexUS, quès acco ?</a></h2>
<p>La distribution comprend une bibliothèque
<code>libtexus.so</code> ( 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 ).</p>
<p>Le programme <code>texus</code> 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 <code>texus</code> et à l'API,
reportez vous à la documentation TexUS.</p>
<h2><a name="ss7.3">7.3 Glide est-il un freeware?</a></h2>
<p>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.</p>
<p>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 !</p>
<h2><a name="ss7.4">7.4 Où trouver Glide?</a></h2>
<p>Le SDK 3Dfx est téléchargeable via le web : <a href=
"http://www.3dfx.com/software/download_glide.html">www.3dfx.com/software/download_glide.html</a>.
Tout ce qui a trait à 3Dfx et qui est publiquement accessible, se
trouve généralement sur le site 3Dfx.</p>
<p>Il y a également un site FTP : <a href=
"ftp://ftp.3dfx.com/">ftp.3dfx.com</a>. 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 ).</p>
<h2><a name="ss7.5">7.5 Les sources de Glide sont elles disponibles
?</a></h2>
<p>Non. L'accès aux sources de Glide requiert la signature d'un NDA
avec 3Dfx.</p>
<h2><a name="ss7.6">7.6 Quel est le support de Linux Glide
?</a></h2>
<p>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 ).</p>
<p>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 ).</p>
<p>Enfin, la page web de Quantum3D annonce un support Linux
concernant l'Obsidian sur les architectures Intel et AXP pour le
second semestre 97.</p>
<h2><a name="ss7.7">7.7 Où puis-je poser des questions ayant trait
à Glide ?</a></h2>
<p>Il existe des forums USENET fournis par 3Dfx : <a href=
"news://news.3dfx.com/">news.3dfx.com</a>. 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 :</p>
<hr>
<pre>
3dfx.events
3dfx.games.glquake
3dfx.glide
3dfx.glide.linux
3dfx.products
3dfx.test
</pre>
<hr>
ainsi que les forums <code>3dfx.oem.products.*</code> pour les
différentes cartes (
<code>3dfx.oem.products.quantum3d.obsidian</code> par exemple ).
Utilisez <a href=
"news://news.3dfx.com/3dfx.glide.linux">news.3dfx.com/3dfx.glide.linux</a>
pour toutes les questions ayant trait à Linux Glide.
<p>Une liste de diffusion spécifique à Linux Glide est en
préparation pour 1998. Envoyez un courrier électronique à :
<a href="mailto:majordomo@gamers.org">majordomo@gamers.org</a>,
avec un champ sujet vide et comme corps de message : <code>info
linux-3dfx</code>. Vous obtiendrez ainsi des informations sur la
liste ( comment souscrire, accès aux archives, conseils de
rédaction, etc ... ).</p>
<h2><a name="ss7.8">7.8 Où envoyer les notifications de bug
?</a></h2>
<p>Pour l'instant, utilisez le forum USENET : <a href=
"news://news.3dfx.com/3dfx.glide.linux">news.3dfx.com/3dfx.glide.linux</a>.
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.</p>
<h2><a name="ss7.9">7.9 Qui assure la maintenance de Linux Glide
?</a></h2>
<p>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 : <a href=
"mailto:daryll@harlot.rb.ca.us">daryll@harlot.rb.ca.us</a></p>
<h2><a name="ss7.10">7.10 Comment puis-je contribuer à Linux
Glide?</a></h2>
<p>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.</p>
<h2><a name="ss7.11">7.11 Dois-je nécessairement avoir recours à
Glide ?</a></h2>
<p>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.</p>
<h2><a name="ss7.12">7.12 Dois-je programmer avec l'API Glide
?</a></h2>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h2><a name="ss7.13">7.13 Quelle est la version courante de Glide
?</a></h2>
<p>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 ).</p>
<p>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.</p>
<h2><a name="ss7.14">7.14 Qu'en est-il de la gestion de plusieurs
Texelfx ?</a></h2>
<p>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.</p>
<p>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.</p>
<h2><a name="ss7.15">7.15 Linux Glide est il semblable à Glide pour
DOS/Windows ?</a></h2>
<p>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.</p>
<h2><a name="ss7.16">7.16 Où trouver des informations sur
Glide?</a></h2>
<p>3Dfx fournit des informations exhaustives. Vous pouvez les
télécharger via leur site web : <a href=
"http://www.3dfx.com/software/download_glide.html">www.3dfx.com/software/download_glide.html</a>.
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.</p>
<p>Dans un premier temps, vous pouvez vous intéresser aux documents
suivants :</p>
<ul>
<li><em>Glide Release Notes</em></li>
<li><em>Glide Programming Guide</em></li>
<li><em>Glide Reference Manual</em></li>
<li><em>Glide Porting Guide</em></li>
<li><em>TexUs Texture Utility Software</em></li>
<li><em>ATB Release Notes</em></li>
<li><em>Installing and Using the Obsidian</em></li>
</ul>
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 : <a href=
"http://www.3dfx.com/software/download_glide.html">www.3dfx.com</a>.
Notez que les numéros de version ne correspondent pas toujours à
ceux de Glide.
<h2><a name="ss7.17">7.17 Où trouver des démos Glide ?</a></h2>
<p>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.</p>
<p>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.</p>
<h2><a name="ss7.18">7.18 Qu'est-ce qu'ATB?</a></h2>
<p>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.</p>
<h2><a name="s8">8. FAQ: Glide et XFree86 ?</a></h2>
<h2><a name="ss8.1">8.1 Glide fonctionne-t-il avec XFree86
?</a></h2>
<p>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.</p>
<p>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 ).</p>
<h2><a name="ss8.2">8.2 Doit-on se cantonner au plein écran
?</a></h2>
<p>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.</p>
<h2><a name="ss8.3">8.3 Quel est le problème des cartes AT3D/Voodoo
Rush (tm) ?</a></h2>
<p>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.</p>
<p>Il existe une mailing list et un site web avec une FAQ à ce
sujet : <a href=
"http://www.frozenwave.com/linux-stingray128">www.frozenwave.com/linux-stingray128</a>.
Vous y obtiendrez l'information la plus à jour. Suse maintient un
pilote : <a href=
"ftp://ftp.suse.com/suse_update/special/xat3d.tgz">ftp.suse.com/suse_update/special/xat3d.tgz</a>.
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.</p>
<p>La configuration suivante du <code>XF86Config</code> est censée
fonctionner :</p>
<hr>
<pre>
# 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)  
</pre>
<hr>
En fin de compte, même si les pilotes XFree86 ne sont pas encore
terminés, il n'y a rien de rédhibitoire.
<p>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 ).</p>
<h2><a name="ss8.4">8.4 Qu'en est-il de GLX pour XFree86 ?</a></h2>
<p>Il y a quelques difficultés.</p>
<p>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.</p>
<p>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.</p>
<p>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 :
<a href=
"http://www.cs.utah.edu/~sparker/xfree86-3d/">www.cs.utah.edu/~sparker/xfree86-3d/</a>
De plus, XFree86 et SuSe ont joint leurs efforts dans la
réalisation d'un GLX. Cf : <a href=
"http://www.suse.de/~sim/">www.suse.de/~sim/</a>. Pour l'instant,
Mesa émule toujours de façon logicielle GLX avec Linux.</p>
<h2><a name="ss8.5">8.5 Glide et les serveurs X commerciaux
?</a></h2>
<p>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.</p>
<h2><a name="ss8.6">8.6 Glide et SVGA ?</a></h2>
<p>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.</p>
<h2><a name="ss8.7">8.7 Glide et GGI ?</a></h2>
<p>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 : <a href=
"http://synergy.caltech.edu/~ggi/">synergy.caltech.edu/~ggi/</a>.
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.</p>
<h2><a name="s9">9. FAQ: OpenGL/Mesa ?</a></h2>
<h2><a name="ss9.1">9.1 Qu'est ce qu'OpenGL ?</a></h2>
<p>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.</p>
<p>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.</p>
<h2><a name="ss9.2">9.2 Où trouver davantage d'informations sur
OpenGL ?</a></h2>
<p>Le site officiel d'OpenGL, administré par les membres de l'ARB :
<a href="http://www.opengl.org/">www.opengl.org</a>,</p>
<p>On préférera peut être la passerelle vers OpenGL de Mark Kilgard
: <a href=
"http://reality.sgi.com/mjk_asd/opengl-links.html">reality.sgi.com/mjk_asd/opengl-links.html</a>.
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.</p>
<p>Si le développement de jeu utilisant OpenGL vous tente, il
existe une liste de diffusion
<code>OpenGL-GameDev-L@fatcity.com</code> accessible via
<code>Listserv@fatcity.com</code>. Il s'agit d'une liste à contenu
fortement technique et dont le débit est très élevé. Vous
recourerez sûrement à <code>procmail</code> pour ventiler la
centaine de messages quotidiens qui en provient. Pour réduire le
besoin en bande passante, servez vous de la commande <code>SET
OpenGL-GameDev-L DIGEST</code>. Cette liste est inappropriée si
vous cherchez des documents d'introduction. L'archivage est assuré
par le logiciel ListServ. Les commandes <code>INDEX
OpenGL-GameDev-L</code> et <code>GET OpenGL-GameDev-L
"filename"</code> permettent de se faire un idée avant de
souscrire.</p>
<h2><a name="ss9.3">9.3 IGlide met-il en oeuvre OpenGL ?</a></h2>
<p>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
).</p>
<p>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 ).</p>
<h2><a name="ss9.4">9.4 Existe-t-il un pilote OpenGL pour 3Dfx
?</a></h2>
<p>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.</p>
<p>Aucun portage vers Linux n'a encore été annoncé pour
l'instant.</p>
<h2><a name="ss9.5">9.5 Existe-t-il une version commerciale
d'OpenGL pour Linux et 3Dfx ?</a></h2>
<p>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.</p>
<h2><a name="ss9.6">9.6 Qu'est-ce que Mesa ?</a></h2>
<p>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.</p>
<h2><a name="ss9.7">9.7 Mesa fonctionne-t-elle avec 3Dfx ?</a></h2>
<p>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.</p>
<p>Il vous faudra l'archive de la bibliothèque Mesa : <a href=
"ftp://iris.ssec.wisc.edu/">iris.ssec.wisc.edu FTP site</a>. 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.</p>
<h2><a name="ss9.8">9.8 Qu'en est-il de la portabilité de Mesa pour
Glide?</a></h2>
<p>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.</p>
<p>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
à : <a href=
"http://www.geocities.com/~charlie_x/">www.geocities.com/~charlie_x/</a>.</p>
<h2><a name="ss9.9">9.9 Où trouver des informations sur Mesa
?</a></h2>
<p>La page web de Mesa : <a href=
"http://www.ssec.wisc.edu/~brianp/Mesa.html">www.ssec.wisc.edu/~brianp/Mesa.html</a>.
L'archive de la liste de distribution Mesa : <a href=
"http://www.iqm.unicamp.br/mesa/">www.iqm.unicamp.br/mesa/</a>.
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.</p>
<h2><a name="ss9.10">9.10 Où trouver des informations sur Mesa
Voodoo ?</a></h2>
<p>Pour les informations les plus à jour sur le pilote Mesa Voodoo
de David Bucciarelli <a href=
"mailto:tech.hmw@plus.it">tech.hmw@plus.it</a>, reportez vous à la
page web : <a href=
"http://www-hmw.caribel.pisa.it/fxmesa/index.shtml">www-hmw.caribel.pisa.it/fxmesa/</a>.</p>
<h2><a name="ss9.11">9.11 Mesa gère-t-il le texturage multiple
?</a></h2>
<p>Pas encore en ce qui concerne Mesa 2.6 mais la question est à
l'étude. Vous disposerez probablement d'une extension OpenGL
<code>EXT_multitexture</code> 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.</p>
<h2><a name="ss9.12">9.12 Mesa supporte-t-elle le filtrage
tri-linéaire en une seule étape ?</a></h2>
<p>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.</p>
<h2><a name="ss9.13">9.13 Qu'est-ce que le hack Mesa ( "Window
Hack" ) ?</a></h2>
<p>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 <code>glXSwapBuffers</code>. Mesa offre également cette
possibilité sous Windows.</p>
<p>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 ).</p>
<p>Notez que cette fonctionnalité expérimentale n'a <em>RIEN</em> à
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 ! ).</p>
<p>Vérifiez le positionnement des variables suivantes :</p>
<hr>
<pre>
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
</pre>
<hr>
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.
<p>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.</p>
<h2><a name="ss9.14">9.14 Qu'en est-il de GLUT ?</a></h2>
<p>La distribution GLUT de Mark Kilgard constitue une excellente
ressource pour ce qui est des applications type et des utilitaires.
Vous la trouverez à : <a href=
"http://reality.sgi.com/mjk_asd/glut3/glut3.html">reality.sgi.com/mjk_asd/glut3/</a>.
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.</p>
<p>Il existe une liste de diffusion spécifique à GLUT :
<code>glut@perp.com</code>. Envoyez à <a href=
"mailto:Majordomo@perp.com">majordomo@perp.com</a> le message
suivant :</p>
<hr>
<pre>
   help
   info glut
   subscribe glut
   end
</pre>
<hr>
<p>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.</p>
<h2><a name="s10">10. FAQ: Quake ?</a></h2>
<h2><a name="ss10.1">10.1 Où en est le pilote 3Dfx GL pour Quake
?</a></h2>
<p>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 <a href=
"http://www.cs.unc.edu/~martin/3dfx.html">http://www.cs.unc.edu/~martin/3dfx.html</a>
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 ( <code>opengl32.dll</code> ) 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.</p>
<h2><a name="ss10.2">10.2 Existe-t-il une version Linux de 3Dfx
glQuake ?</a></h2>
<p>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.</p>
<p>Pour les dernières versions : <a href=
"ftp://ftp.idsoftware.com/idstuff/quake/unix/">ftp.idsoftware.com/idstuff/quake/unix/</a>.</p>
<h2><a name="ss10.3">10.3 glQuake fonctionne-t-il dans une fenêtre
XFree86 ?</a></h2>
<p>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.</p>
<h2><a name="ss10.4">10.4 Comment réinitialiser l'affichage après
un plantage de glQuake ?</a></h2>
<p>Essayez d'utiliser le programme <code>pass</code> 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.</p>
<h2><a name="ss10.5">10.5 Des problèmes avec Quake pour Linux
?</a></h2>
<p>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.</p>
<ul>
<li>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.</li>
<li>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.</li>
<li>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.</li>
<li>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.</li>
<li>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.</li>
</ul>
<h2><a name="ss10.6">10.6 Les trous de sécurité de Quake pour
Linux</a></h2>
<p>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
<code>setuid</code>.</p>
<p>Si vous désirez employer les routines de rendu
<code>ref_soft</code> et <code>ref_gl</code>, 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 !</p>
<p>Le rendu sous X11 ne requiert pas les privilèges root ( dès lors
que le <code>/dev/dsp</code> est accessible à tous en écriture ).
Le serveur associé n'a bien entendu pas non plus besoin de droits
particuliers.</p>
<p>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 <code>ref_ggi</code>.</p>
<h2><a name="ss10.7">10.7 Linuxquake supporte-t-il le texturage
multiple ?</a></h2>
<p>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.</p>
<h2><a name="ss10.8">10.8 Où trouver des informations à jour sur
glQuake pour Linux ?</a></h2>
<p>Essayez les sites suivants : "The Linux Quake Resource" à
<a href=
"http://linuxquake.telefragged.com/">linuxquake.telefragged.com</a>,
ou "Linux Quake Page" à <a href=
"http://www.planetquake.com/threewave/linux/">www.planetquake.com/threewave/linux/</a>.
Jetez donc un oeil dans la base de données "SlipgateCentral" pour
trouver des sites Quake Linux : <a href=
"http://www.slipgatecentral.com/">www.slipgatecentral.com</a>.</p>
<h2><a name="s11">11. FAQ: solutions aux problèmes courants
?</a></h2>
<h2><a name="ss11.1">11.1 Cette carte a-t-elle été testée
?</a></h2>
<p>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.</p>
<p>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 : <a href=
"mailto:daryll@harlot.rb.ca.us">daryll@harlot.rb.ca.us</a></p>
<h2><a name="ss11.2">11.2 Échec lors du changement des privilèges
d'entrées/sorties ?</a></h2>
<p>Il faut que vous soyez root ou bien que l'identité associée à
votre application puisse être telle ( cf <code>setuid</code> ). Le
pilote se sert du périphérique <code>/dev/mem</code> 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.</p>
<h2><a name="ss11.3">11.3 Un fonctionnement sans les droits root
est-il possible ?</a></h2>
<p>Non. Des solutions de remplacement sont en cours de
réalisation.</p>
<h2><a name="ss11.4">11.4 L'affichage est déplorable !</a></h2>
<p>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.</p>
<p>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.</p>
<h2><a name="ss11.5">11.5 La dernière image ne disparaît pas
!</a></h2>
<p>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.</p>
<h2><a name="ss11.6">11.6 L'économiseur d'écran se déclenche ( deux
écrans ) ?</a></h2>
<p>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 :</p>
<hr>
<pre>
setenv SST_DUALSCREEN 1
</pre>
<hr>
<h2><a name="ss11.7">11.7 Mon ordinateur semble se bloquer ( X11,
un seul écran ) !</a></h2>
<p>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.</p>
<p>Si votre programme concurrence X11, il est conseillé d'installer
une fenêtre plein écran ou de se servir des fonctions
<code>XGrabPointer</code> et <code>XGrabServer</code> tandis que le
serveur X est désactivé. Notez que le recours à
<code>XGrabPointer</code> et à <code>XGrabServer</code> ne qualifie
pas une application comme particulièrement propre à l'égard de X;
le système pourrait ainsi se retrouver bloqué.</p>
<p>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
).</p>
<h2><a name="ss11.8">11.8 Ma machine se bloque ( un ou deux écrans
) ?</a></h2>
<p>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.</p>
<p>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.</p>
<h2><a name="ss11.9">11.9 Ma machine se bloque ( avec une carte S3
) ?</a></h2>
<p>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 ?</p>
<h2><a name="ss11.10">11.10 Pas de conflit d'adresse mais la
machine se bloque quand même !</a></h2>
<p>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 !</p>
<h2><a name="ss11.11">11.11 Mesa est actif mais n'accède pas à la
carte !</a></h2>
<p>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é
<code>ldconfig</code> et/ou positionné correctement votre
<code>LD_LIBRARY_PATH</code>. 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
<code>MakeCurrent</code> ) si le Voodoo Graphics (tm) n'est pas
choisi par défaut.</p>
<h2><a name="ss11.12">11.12 Réinitialiser une carte SLI (
configuration à deux cartes ) ?</a></h2>
<p>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é <code>resetsli</code> pour réinitialiser les
cartes. Tant que vous ne l'aurez pas appelé, la réinitialisation
des cartes Obsidian restera impossible.</p>
<h2><a name="ss11.13">11.13 Réinitialiser une carte SLI (
configuration à une seule carte ) ?</a></h2>
<p>Le programme <code>resetsli</code> 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.</p>
</body>
</html>
doc-linux-fr-html 2013.01-3ubuntu1 / usr / share / doc / HOWTO / fr-html / 3Dfx-HOWTO.html
