<!DOCTYPE linuxdoc
               PUBLIC "-//LinuxDoc//DTD LinuxDoc 96//EN"
   [
        <!ENTITY % Internal    "IGNORE"                >
        <!ENTITY % Indexing    "INCLUDE"               >

        <!ENTITY   SGMLT       "SGML-Tools"            >
        <!ENTITY   c3Dfx       "3Dfx"                  >
        <!ENTITY   OGL         "OpenGL"                >
        <!ENTITY   Mesa        "Mesa"                  >
        <!ENTITY   MesaVer     "2.6"                   >
        <!ENTITY   Glide       "Glide"                 >
        <!ENTITY   GlVer       "2.4"                   >
        <!ENTITY   TexUs       "TexUS"                 >
        <!ENTITY   Pixelfx     "Pixelfx"               >
        <!ENTITY   Texelfx     "Texelfx"               >
        <!ENTITY   VooDoo      "Voodoo Graphics (tm)"  >
        <!ENTITY   VooRush     "Voodoo Rush (tm)"      >
        <!ENTITY   VooD2       "Voodoo 2 (tm)"         >
        <!ENTITY   VooMesa     "Mesa Voodoo"           >
        <!ENTITY   CurrentDate "6 February 1998"       >
        <!ENTITY   CurrentVer  "v1.16"                 >
   ] >

<!-- sgmltool 
       PUBLIC "-//SGML-Tools//DTD SGML-Tools v0.9//EN" -->

<!-- ================================================= -->
<!--

    $Id: 3Dfx-HOWTO.sgml,v 1.1.1.1 2003/01/03 02:38:54 traduc Exp $
     
    Ce document est le HOWTO Linux3Dfx.sgml.
    Il couvre diverses questions relatives à l'utilisation
    des cartes à base de composants Voodoo 3Dfx sous Linux.

    $Log: 3Dfx-HOWTO.sgml,v $
    Revision 1.1.1.1  2003/01/03 02:38:54  traduc
    Ajout des HOWTO existants à l'archive.


                                                       -->
<!-- ================================================= -->


<article>

<title>HOWTO &c3Dfx; pour Linux
<author>Bernd Kreimeier
        (<htmlurl 
        url="mailto:bk@gamers.org"
        name="bk@gamers.org">)
<date>v1.16, 6 February 1998 


<abstract>
Ce document décrit l'utilisation des cartes accélératrices &c3Dfx; 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.
</abstract>


<!-- ====================================================== -->
<!-- Index                                                  -->


<toc>


<![ %Indexing 
 [
<p>
<nidx>Accélération du graphisme 3D avec les composants Voodoo 3Dfx </nidx>

<nidx>XFree86 et 3Dfx Voodoo</nidx> 
<nidx>OpenGL et 3Dfx Voodoo</nidx>
<nidx>Mesa et 3Dfx Voodoo</nidx>
<nidx>GLUT et 3Dfx Voodoo</nidx>
<nidx>GGI et 3Dfx Voodoo</nidx>

<nidx>3Dfx</nidx>
<nidx>Composants Voodoo</nidx>
<nidx>API Glide pour Linux</nidx>

<nidx>Quantum 3D</nidx>
<nidx>Cartes graphiques Obsidian</nidx>

<nidx>Orchid Righteous 3D</nidx>
<nidx>Canopus Pure 3D</nidx>
<nidx>Hercules Stealth 3D</nidx>
<nidx>Diamond Monster 3D</nidx>

<nidx>Quake pour Linux</nidx>
<nidx>GLQuake pour Linux</nidx>
<nidx>GLQuake et 3Dfx Voodoo</nidx>
</p>
 ]]>

<!-- ====================================================== -->

<sect>Introduction


<p>
Ce document est le &c3Dfx; HOWTO pour Linux. Il contient toutes les
informations nécessaires à l'installation et la configuration du &c3Dfx; sous
Linux. Des réponses aux questions les plus fréquentes sur l'utilisation du
&c3Dfx; 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>
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 &c3Dfx;. L'utilisation d'autres cartes accélératrices déborde du cadre
de ce document.


<sect1>Contributions et contacts
<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 &VooMesa; et celles qui ont
relu ce document pour le compte de &c3Dfx; et de Quantum3D. Ce texte leur
est redevable de l'intégralité de certaines parties.
<p>
Daryll Strauss
<htmlurl 
 url="mailto:Daryll Strauss <daryll@harlot.rb.ca.us>"
 name="daryll@harlot.rb.ca.us"> a effectué le portage,
Paul J. Metzger
<htmlurl 
 url="mailto:Paul J. Metzger <pjm@rbd.com>"
 name="pjm@rbd.com">
modifications du pilote &VooMesa; ( écrit par
David Bucciarelli )
<htmlurl 
 url="mailto:David Bucciarelli <tech.hmw@plus.it>"
 name="tech.hmw@plus.it">) pour Linux, 
Brian Paul 
<htmlurl 
 url="mailto:Brian Paul <brianp@RA.AVID.COM>"
 name="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; de &Mesa;, des remerciements supplémentaires sont dus
à Henri Fousse, Gary McTaggart, et au développeur de &c3Dfx; Mesa pour DOS,  
Charlie Wallace
<htmlurl 
 url="mailto:Charlie Wallace <Charlie.Wallace@unistudios.com>"
 name="Charlie.Wallace@unistudios.com">.
Le personnel de &c3Dfx;, 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 &c3Dfx;. GlQuake2 pour Linux, qui repose sur  &Glide; et &Mesa;,
est maintenu par Dave Kirsch <htmlurl 
url="mailto:Dave Kirsch <zoid@idsoftware.com>"
name="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.
<p>
Grâce aux outils  &SGMLT; ( ex Linuxdoc-SGML ), ce HOWTO est disponible dans 
plusieurs formats qui reposent tous sur le contenu de ce fichier. Pour en
savoir davantage sur &SGMLT;, reportez vous à la page suivante :
<htmlurl 
   url="http://pobox.com/~cg/sgmltools"
   name="pobox.com/~cg/sgmltools">.

<sect1>Noms des produits et protection industrielle
<p>
&c3Dfx;, le logo &c3Dfx; Interactive , &VooDoo; et  &VooRush;
sont des marques déposées appartenant à &c3Dfx; Interactive, Inc.
&Glide;, &TexUs;, &Pixelfx; et &Texelfx; sont des marques déposées par 
3Dfx Interactive, Inc. &OGL; 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.

<sect1>Historique
<p>
<descrip>
<tag>Version 1.03</tag>First version for public release.
<tag>Version 1.16</tag>Current version &CurrentVer; &CurrentDate;.
</descrip>

<!-- ====================================================== -->
<sect1>Versions actualisées du document
<p>
Vous trouverez la version la plus récente de l'original en langue anglaise de
ce document à la page web :
<htmlurl
 url="http://www.gamers.org/dEngine/xf3D/"
 name="www.gamers.org/dEngine/xf3D/">.
<p>
Les nouvelles versions seront postées périodiquement sur le forum Usenet
<htmlurl 
url="news:comp.os.linux.answers"
name="comp.os.linux.answers">. Des archives sont également disponibles sur
divers serveurs ftp anonymes tels que
<htmlurl 
url="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/"
name ="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/">.
<p>
De nombreux sites web proposent des versions hypertextes, notamment
<htmlurl
url="http://sunsite.unc.edu/LDP/"
name="sunsite.unc.edu/LDP/">. La plupart des distributions de Linux sur CD
incluent les HOWTO, en général dans le répertoire <tt>/usr/doc/</tt>.
Certains vendeurs proposent des versions imprimées. 
<p>
Si vous traduisez ce document dans une autre langue, faites le moi savoir
que je puisse y faire référence.

<sect1>Retour d'expérience
<p>
Je m'en remets à vous, lecteur, pour rendre ce HOWTO utile. Envoyez les
corrections, suggestions et commentaires à mon adresse ( 
<htmlurl 
 url="mailto:bk@gamers.org"
 name="bk@gamers.org"> ) et je les prendrai en compte dans une nouvelle
version. Mentionnez <tt>HOWTO 3Dfx</tt> dans le champ Sujet du courrier 
afin que procmail le dirige vers le fichier adéquat.
<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>
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 
(<htmlurl 
 url="mailto:linux-howto@sunsite.unc.edu"
 name="linux-howto@sunsite.unc.edu">). 

<sect1>Licence
<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 :
<htmlurl 
 url="http://sunsite.unc.edu/LDP/COPYRIGHT.html"
 name="sunsite.unc.edu/LDP/COPYRIGHT.html">.
<p>

<!-- 

Ce HOWTO est une documentation libre et gratuite; vous pouvez la
redistribuer et/ou la modifier selon les termes de la licence LDP.
Ce document est distribué dans l'espoir qu'il rendra service, ceci
sans aucune garantie; sans même une garantie implicite de possibilité
de commercialisation pour un objectif précis.
Consultez la licence LDP pour de plus amples détails.

-->

<sect>Technologie des accélérateurs graphiques

<sect1>Les bases
<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'&OGL;.

<sect1>Configuration matérielle
<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 &c3Dfx; à base de composants &VooDoo;
appartiennent à la première catégorie. On y reviendra ultérieurement.
<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.

<sect1>Quelques mots sur l'organisation du &VooDoo;
<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>
L'architecture &VooDoo; 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>
Enfin, le &VooDoo; est susceptible d'employer deux &Texelfx; (ou TMU pour 
texture management unit ) et on peut combiner deux systèmes &VooDoo; 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.

<sect>Installation
<p>
La mise en place du &c3Dfx; sous Linux passe par les étapes suivantes :

<enum>
<item>installation de la carte;
<item>installation des logiciels &Glide;;
<item>compilation, édition de liens et/ou exécution de l'application.
</enum>

Les sections suivantes couvrent ces étapes en détail.

<sect1>Installation de la carte.
<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>
Puisque &c3Dfx; n'intervient pas dans le développement et la fabrication de
cartes, il est inutile de les contacter en cas de problèmes.

<sect2>Solutions aux problèmes d'installation
<p>
Afin de vérifier l'installation et l'adressage mémoire des périphériques,
faites un <tt>cat /proc/pci</tt>. La sortie devrait ressembler à ce qui suit :
<code>
  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.
</code>
( cas d'une Diamond Monster 3D utilisée conjointement à une Diamond 
Stealth-64 ). Un <tt>cat /proc/cpuinfo /proc/meminfo</tt> aidera à résoudre
les conflits et sera utile pour signaler un bug.
<p>
Les noyaux courants afficheront peut-être au démarrage :
<code>
Jun 12 12:31:52 hal kernel: Warning : Unknown PCI device (121a:1).
Please read include/linux/pci.h 
</code>
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
<tt>/usr/include/linux/pci.h</tt> afin de transmettre les informations utiles à
<htmlurl 
        url="mailto:linux-pcisupport@cao-vlsi.ibp.fr"
        name="linux-pcisupport@cao-vlsi.ibp.fr">.
<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. 

<sect2>Configuration du noyau
<p>
Seule la gestion du bus PCI est requise.
Le <url url="http://sunsite.unc.edu/mdw/HOWTO/Kernel-HOWTO.html"
name="Linux Kernel HOWTO"> fournit tous les détails relatifs à la
compilation d'un noyau.

<sect2>Configuration des périphériques
<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
<tt>/dev/dsp</tt> et <tt>/dev/audio</tt> dont la présence n'est pas garantie,
les pilotes reposent ici sur le <tt>/dev/mem</tt> qui est toujours disponible.
Il vous faudra bien sûr disposer des droits de super-utilisateur ou recourir
à <tt>setuid</tt> pour accéder à la carte accélératrice.

<sect1>Gestion des écrans
<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.

<sect2>Affichage avec un seul écran
<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>
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>
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>
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.

<sect2>Un moniteur avec deux entrées vidéo
<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.


<sect2>Deux écrans
<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>
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 :
<code>
setenv SST_DUALSCREEN 1
</code>
pour maintenir la sortie vidéo active.
 
<sect1>Installation des logiciels &Glide; 
<p>
Les pilotes et la librairie &Glide; sont réunis dans un unique fichier 
compressé. Décompactez/détarez les avec <tt>tar</tt> et <tt>gzip</tt> 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 <tt>/usr/local/glide/</tt> et le chemin d'accés aux librairies
correspondants est ajouté au <tt>ld.conf</tt>. 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>
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
<tt>can't load library 'libglide.so'</tt>.


<sect2>Le programme <tt>detect</tt>
<p>
La distribution logicielle inclut le programme <tt>bin/detect</tt> ( les 
sources ne sont pas disponibles ). Le lançant sous l'identité root, vous 
obtiendrez quelque chose dans le genre :
<code>
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
</code>
Si vous n'êtes pas root, vous serez gratifié d'un :
<code>
Permission denied: Failed to change I/O privilege. Are you root?
</code>
Si vous signalez un bug, joignez une copie de la sortie écran de 
<tt>detect</tt>.


<sect2>Test de l'installation
<p>
La distribution &Glide; comprend un répertoire avec des programmes de test.
Ces programmes sont soumis au copyright &c3Dfx;. Leur utilisation n'est licite
que pour les possesseurs d'une carte munie d'un composant  &c3Dfx;. Reportez
vous au fichier LICENSE de la distribution ou au site web
 <htmlurl 
        url="http://www.3dfx.com/"
        name="www.3dfx.com"> pour plus de détails. 
<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
<tt>alpha.3df</tt> 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 
<tt>Press A Key To Begin Test</tt>. 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>
Le fichier README.test donne la liste des programmes ainsi que divers détails.

<sect>Réponses aux questions les plus courantes ( la Foire Aux Questions )
<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 :
<itemize>
<item>FAQ: Quel Matériel ?
<item>FAQ: &VooDoo; ? &c3Dfx; ?
<item>FAQ: &Glide; ?
<item>FAQ: &Glide; et SVGA ?
<item>FAQ: &Glide; et XFree86 ?
<item>FAQ: &Glide; ou OpenGL/Mesa ?
<item>FAQ: Et Quake ?
<item>FAQ: A marche pôôô...
</itemize>
La plupart des problèmes devraient trouver une réponse ici.


<sect>FAQ: quel Matériel ?

<sect1>Système nécessaire :
<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; &c3Dfx;. 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>
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.

<sect1>Est-ce que ça fonctionne avec Linux-Alpha ?
<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>
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.

<sect1>Quels sont les composants &c3Dfx; compatibles avec la distribution ? 
<p>
Pour l'instant, le &VooDoo; &c3Dfx; est accepté. Le &VooRush; n'est pas encore
géré.

<sect1>Le &VooRush; est-il géré ?
<p>
La version actuelle de &Glide; pour Linux ne gère pas le &VooRush;. Une mise
à jour est en cours de développement.
<p>
A l'origine, le pilote &VooRush; 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>
Les cartes &VooRush; telles l'<em>Hercules Stingray 128/3D</em> ou 
l'<em>Intergraph Intense Rush</em> ne sont donc actuellement pas gérées.

<sect1>Le &VooD2; est-il géré ?
<p>
Le portage actuel de la librairie &Glide; ne supporte pas le &VooD2;.

<sect1>Quelles sont les cartes compatibles avec &Glide; ?
<p>
Il n'existe pas de carte officielle ( &c3Dfx; 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>
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>
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; telles la Righteous 3D d'Orchid, la Canopus Pure 3D, la Flash 
3D ou la Monster 3D de Diamond.
Les cartes reposant sur un &VooRush; ne sont pas supportées.
<p>
Les cartes qui ne reposent pas sur des composants fournis pas &c3Dfx; telles
celles que fabriquent S3, Matrox, 3Dlabs et Videologic ne fonctionnent 
<em>PAS</em> avec les pilotes &c3Dfx; et débordent du cadre de ce document.

<sect1>Qu'est-ce qui distingue les cartes ?
<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>
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>
Quantum 3D propose la palette de cartes &c3Dfx; 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.


<sect1>Qu'en est-il de l'AGP?
<p>
A ma connaissance il n'existe pas de carte AGP &VooDoo; ni &VooRush;. Je ne sais
pas où en est la gestion de l'AGP sous Linux.

Le chipset &VooD2; 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 &VooD2; 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 <tt>/proc/pci</tt> :
<code>
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.
</code>

<sect>FAQ: &VooDoo; ? &c3Dfx; ? 

<sect1>&c3Dfx;, qui est-ce ?
<p>
&c3Dfx; est un fabricant de composants pour l'accélération graphique 3D basé
à San Jose. Leur site officiel :
<htmlurl
 url="http://www.3dfx.com/"
 name="www.3dfx.com">. 
&c3Dfx; ne vend pas de cartes, contrairement à d'autres sociétés ( Quantum3D
par exemple ).


<sect1>Qui est Quantum3D ?
<p>
Quantum3D est une entreprise issue de &c3Dfx; qui fabrique des cartes 
accélératrices haut de gamme à base de composants &c3Dfx; à usage personnel
et professionnel. Quantum3D intervient également sur le marché des jeux 
d'arcade. Pour avoir davantage de renseignements, consultez donc leurs pages :
<htmlurl
 url="http://www.quantum3d.com/"
 name="www.quantum3d.com">
Pour toute question concernant Quantum3D, envoyez un message électronique à :
<htmlurl
 url="mailto:info@quantum3d"
 name="info@quantum3d">.



<sect1>&VooDoo;, quès acco ?
<p>
Le &VooDoo; est un composant électronique fabriqué par &c3Dfx;. Il est
employé dans les cartes d'accélération graphique pour PC. Reportez 
vous à la section du HOWTO concernant le matériel. 

<sect1>&VooRush; ?
<p>
Le &VooRush; est un dérivé du &VooDoo; 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.

<sect1>&VooD2; ?
<p>
Le &VooD2; succède, avec des améliorations, au &VooDoo;. Quantum3D, Creative 
Labs, Orchid Technologies et Diamond Multimedia fournissent des cartes intégrant
le &VooD2;.
<p>
Bien que le &VooD2; soit censé être compatible, une nouvelle version de &Glide;
devra être développée pour Linux.

<sect1>Qu'est ce qu'un intermédiaire VGA ?
<p>
Les cartes &VooDoo; ( mais pas les &VooRush; ) 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; qui par 
défaut se contente de transmettre au moniteur. Si le &VooDoo; 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>
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; risque de
bloquer la sortie vidéo usuelle et le signal vidéo transitant par
l'intermédiaire VGA est détérioré.

<sect1>Qu'est-ce que le &Texelfx;, un TMU ?
<p>
Les composants &VooDoo; 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>
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>
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. 

<sect1>Qu'est ce qu'une unité &Pixelfx; ?
<p>
Il s'agit de la seconde partie d'un composant &VooDoo;, 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é.


<sect1>Qu'est-ce que le mode SLI ?
<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>
Les &Pixelfx; peuvent être sur deux cartes distinctes reliées de façon adéquate.
Certaines cartes Obsidian supportent le SLI avec le  &VooDoo;.
<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.

<sect1>Le SLI avec une seule carte ?
<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 ).

<sect1> Quelle quantité de mémoire ?
<p>
La différence entre les cartes utilisant les composants &VooDoo; 
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 &VooD2;,
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;.
<code>
    "SLI / Pixelfx / Texelfx1 / Texelfx2 "
</code>
Une carte courante munie de deux fois 2 Mo est décrite par le quadruplet
<tt>1/2/2/0</tt>, la quantité totale de mémoire étant égale au minimum
requis de 4Mo. Une Canopus Pure 3D, munie de 6 Mo, est du type 
<tt>1/2/4/0</tt>. Une Obsidian-2220 avec deux Texelfx; est du type 
<tt>1/2/2/2</tt> et à une Obsidian SLI-2440 board correspondrait 
<tt>2/2/4/4</tt>. 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 <tt>2/4/4/4</tt> pour une quantité totale de mémoire de
<tt>SLI*(Pixelfx+Texelfx1+Texelfx2)</tt> soit 24 Mo.   
<p>

<sect1>Le &VooDoo; gère-t-il l'affichage en 24 ou 32 bits ?
<p>
Non. L'architecture &VooDoo; fonctionne à 16 bpp en interne. Idem pour
le &VooRush; et le &VooD2;. Quantum3D affirme mettre en oeuvre un
affichage à 22 bpp avec un tampon de mémoire vidéo ( 16 bpp ) compressé.

<sect1>Le calcul de profondeur du &VooDoo; est-t-il en 24 ou 32 bits par pixel ?
<p>
Non. Là encore, l'architecture interne est sur 16 bits. Même chose pour
le &VooRush; et le &VooD2;. 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.

<sect1>Quelles résolutions offre le &VooDoo; ?
<p>
Le jeu de composants &VooDoo; 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>
Le 960 par 720 n'est malheureusement pas accessible. Le &VooDoo; 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>
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>
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.

<sect1>Quelles sont les tailles de texture disponibles ?
<p>
Le composant &VooDoo; 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.

<sect1>Le &VooDoo; gère-t-il les textures palettisées ?
<p>
Les composants &VooDoo; et &Glide; gèrent l'extension correspondante de
&OGL;. La dernière version de &Mesa; comporte les extensions
<tt>GL_EXT_paletted_texture</tt> et
<tt>GL_EXT_shared_texture_palette</tt>.

<sect1>Qu'en est-il du dépassement de fréquence d'horloge ?
<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>
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>
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.

<sect1>Où puis-je trouver d'autres informations concernant le &VooDoo; ?
<p>
&c3Dfx; a rédigé une FAQ qui devrait se trouver à l'adresse suivante :
<htmlurl
 url="http://www.3dfx.com/voodoo/faq.html"
 name="web site">.
Vous trouverez des informations sur la vente aux adresses suivantes :
<htmlurl
 url="http://www.3dfx.com/voodoo/sale/"
 name="www.3dfx.com">
et
<htmlurl
 url="http://www.quantum3d.com/"
 name="www.quantum3d.com">.
<p>
Certains sites non-officiels sont bien renseignés :
<htmlurl
 url="http://www.ve3d.com/"
 name="www.ve3d.com">,
<htmlurl
 url="http://www.ve3d.com/"
 name="www.ve3d.com">.

<sect>FAQ: &Glide;? &TexUs;?

<sect1>&Glide;, quès acco ?
<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 &c3Dfx;. &Glide; est disponible pour DOS, Windows et Macintosh.
Daryll Strauss a effectué le portage Linux. 

<sect1>&TexUs;, quès acco ?
<p>
La distribution comprend une bibliothèque <tt>libtexus.so</tt>
( &c3Dfx; 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 &c3Dfx; Interactive &Glide;. Cette bibliothèque 
inclut des fonctions de conversion de formats de fichiers, la
création de mipmap et la gestion des textures &c3Dfx; compressées
( &c3Dfx; Interactive Narrow Channel Compression ).
<p>
Le programme <tt>texus</tt> lit les images dans divers formats
courants ( TGA, PPM, RGT ), génère des mipmaps et écrit les images
sous forme de textures &c3Dfx; ( reportez vous par exemple
au fichier alpha.3df disponible dans la distribution ). Pour les 
détails relatifs aux paramètres de <tt>texus</tt> et à l'API,
reportez vous à la documentation &TexUs;.

<sect1>&Glide; est-il un freeware?
<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 &c3Dfx;.
&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 &c3Dfx;.
<p>
Il en est de même de toutes les sources disponibles dans la
distribution &Glide;. Selon les termes de &c3Dfx; : 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 !

<sect1>Où trouver &Glide;?
<p>
Le SDK &c3Dfx; est téléchargeable via le web :
<htmlurl
 url="http://www.3dfx.com/software/download_glide.html"
 name="www.3dfx.com/software/download_glide.html">. 
Tout ce qui a trait à &c3Dfx; et qui est publiquement accessible,
se trouve généralement sur le site &c3Dfx;.
<p>
Il y a également un site FTP :
<htmlurl
 url="ftp://ftp.3dfx.com/"
 name="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 ).

<sect1>Les sources de &Glide; sont elles disponibles ?
<p>
Non. L'accès aux sources de &Glide; requiert la signature d'un
NDA avec &c3Dfx;.

<sect1>Quel est le support de Linux &Glide; ?
<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>
&c3Dfx; 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 &c3Dfx;
( voir plus bas ).
<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.

<sect1>Où puis-je poser des questions ayant trait à &Glide; ?
<p>
Il existe des forums USENET fournis par 3Dfx :
<htmlurl
 url="news://news.3dfx.com/"
 name="news.3dfx.com">.
Ils sont dédiés à &c3Dfx; et à &Glide; de façon générale et
fourniront surtout des indications pour DOS, Windows95 et NT.
La liste actuelle est la suivante :
<code>
3dfx.events
3dfx.games.glquake
3dfx.glide
3dfx.glide.linux
3dfx.products
3dfx.test
</code>
ainsi que les forums <tt>3dfx.oem.products.*</tt> pour les 
différentes cartes ( <tt>3dfx.oem.products.quantum3d.obsidian</tt> 
par exemple ).
Utilisez 
<htmlurl
 url="news://news.3dfx.com/3dfx.glide.linux"
 name="news.3dfx.com/3dfx.glide.linux"> 
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 à : 
<htmlurl
 url="mailto:majordomo@gamers.org"
 name="majordomo@gamers.org">,
avec un champ sujet vide et comme corps de message :
<tt>info linux-3dfx</tt>. Vous obtiendrez ainsi
des informations sur la liste ( comment souscrire, accès aux
archives, conseils de rédaction, etc ... ).

<sect1>Où envoyer les notifications de bug ?
<p>
Pour l'instant, utilisez le forum USENET :
<htmlurl
 url="news://news.3dfx.com/3dfx.glide.linux"
 name="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.

<sect1>Qui assure la maintenance de Linux &Glide; ?
<p>
&c3Dfx; 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 :
<htmlurl
 url="mailto:daryll@harlot.rb.ca.us"
 name="daryll@harlot.rb.ca.us">

<sect1>Comment puis-je contribuer à Linux &Glide;?
<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 &VooMesa;
basé sur &Glide; serait la bienvenue. Reportez vous à la section
sur &VooMesa; plus bas.


<sect1>Dois-je nécessairement avoir recours à &Glide; ?
<p>
Oui. Pour l'instant, il n'existe pas d'autre pilote &VooDoo;
sous Linux. &Glide; est la seule interface pour dialoguer avec
le matériel. Vous pouvez néanmoins écrire du code &OGL; sans
rien connaître à &Glide; et utiliser &Mesa; avec le pilote 
&VooMesa; reposant sur &Glide;. Savoir à quel point &Glide; est
impliqué aide cependant à identifier les bugs ainsi que les
limitations du pilote.
<!-- p>
Pour Win32, on notera l'existence d'OpenGVS. Il s'agit 
d'une API de haut niveau multi-plateformes qui se situerait 
quelque part entre &OGL; et IRIS Performer ou OpenInventor.
OpenGVS est distribué par Quantum 3D. Contactez John Archdeacon :
<htmlurl
 url="mailto:John Archdeacon <jarch@gemtech.com>"
 name="jarch@gemtech.com">  -->


<sect1>Dois-je programmer avec l'API Glide ?
<p>
Tout dépend de l'application. &Glide; est une API propriétaire. 
Elle reste certes voisine d'&OGL; ou de &Mesa;, mais elle contient 
quand même certaines fonctionnalités qui, pour les unes, sont 
disponibles comme des extensions d'&OGL; et, pour les autres, 
n'existent nulle part ailleurs.
<p>
Si vous souhaitez utiliser l'API &OGL;, vous aurez besoin de 
&Mesa ( cf. plus bas ). &Mesa;, ou plus exactement le pilote
&VooMesa;, propose une API voisine de celle d'OpenGL, cette 
dernière étant assez répandue et plutôt bien documentée. Le pilote
&VooMesa; est cependant en phase alpha et il vous faudra accepter
des performances parfois limitées ainsi que l'absence de certaines
fonctionnalités.
<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-&c3Dfx;, &Glide; n'est pas un mauvais choix. 
Si vous vous souciez avant tout de portabilité, &OGL; sera 
peut-être une meilleure solution à long terme.

<sect1>Quelle est la version courante de &Glide; ?
<p>
La version actuelle de Linux &Glide; est &GlVer;. 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 &VooRush;
( VR ) et &VooDoo; ( 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
&VooD2; ( V2 ).
<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 &OGL; dispose de modes spécifiques de
ce type. Pour des explications plus détaillées, consultez la 
documentation &OGL;.

<sect1>Qu'en est-il de la gestion de plusieurs &Texelfx; ?
<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>
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.


<sect1>Linux &Glide; est il semblable à &Glide; pour DOS/Windows ?
<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. 

<sect1>Où trouver des informations sur &Glide;?
<p>
&c3Dfx; fournit des informations exhaustives. Vous pouvez les
télécharger via leur site web :
<htmlurl
 url="http://www.3dfx.com/software/download_glide.html"
 name="www.3dfx.com/software/download&lowbar;glide.html">.
Ces informations sont disponibles gratuitement dès lors que
vous avez acheté une carte à base de composant &c3Dfx;.
Lisez attentivement les termes du contrat de licence.
<p>
Dans un premier temps, vous pouvez vous intéresser aux 
documents suivants :
<itemize>
<item><em>Glide Release Notes</em>
<item><em>Glide Programming Guide</em>
<item><em>Glide Reference Manual</em>
<item><em>Glide Porting Guide</em>
<item><em>TexUs Texture Utility Software</em>
<item><em>ATB Release Notes</em>
<item><em>Installing and Using the Obsidian</em>
</itemize>
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 : 
<htmlurl
url="http://www.3dfx.com/software/download_glide.html"
name="www.3dfx.com">.
Notez que les numéros de version ne correspondent pas toujours
à ceux de &Glide;.

<sect1>Où trouver des démos &Glide; ?
<p>
Vous trouverez des sources de démos pour &Glide; parmi les
programmes de test de la distribution et sur le site de &c3Dfx;.
Certaines parmi ces dernières nécessitent ATB : le portage
impliquerait la réécriture du gestionnaire d'évènements.
<p>
En outre, vous trouverez sûrement des choses intéressantes dans
les sources des démos &OGL; qui accompagnent Mesa et GLUT. Bien
que les API &Glide; et &OGL; diffèrent, elles se destinent à
des matériels dont les organisations sont voisines.


<sect1>Qu'est-ce qu'ATB?
<p>
Certaines des démos &c3Dfx; pour &Glide; ne reposent pas
seulement sur &Glide; mais également sur la boite à outils
pour l'arcade &c3Dfx; ( 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>

<sect>FAQ: &Glide; et XFree86 ?
<p>
<sect1>&Glide; fonctionne-t-il avec XFree86 ?
<p>
En fait, les périphériques &VooDoo; 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>
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 ).


<sect1>Doit-on se cantonner au plein écran ?
<p>
Les périphériques &VooDoo; 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;
dans une fenêtre X11.


<sect1>Quel est le problème des cartes AT3D/&VooRush; ?
<p>
Le problème est inhérent à l'utilisation des cartes &VooRush; 
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 &VooRush; est un
accélérateur multimédia Promotion-AT3D d'Alliance Semiconducteur.
XFree86 requiert un pilote pour le composant AT3D.
<p>
Il existe une mailing list et un site web avec une FAQ à ce 
sujet :
<htmlurl
 url="http://www.frozenwave.com/linux-stingray128"
 name="www.frozenwave.com/linux-stingray128">.
Vous y obtiendrez l'information la plus à jour.
Suse maintient un pilote :
<htmlurl
 url="ftp://ftp.suse.com/suse_update/special/xat3d.tgz"
 name="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.
<p>
La configuration suivante du <tt>XF86Config</tt> est
censée fonctionner :
<code>
# 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)  
</code>
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 &VooRush;
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
&VooRush; 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 &c3Dfx;. 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 ).

<sect1>Qu'en est-il de GLX pour XFree86 ?
<p>
Il y a quelques difficultés.
<p>
Les périphériques &VooDoo; 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>
Le &VooRush; 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>
Enfin, GLX est intimement lié à &OGL;, 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 :
<htmlurl
 url="http://www.cs.utah.edu/~sparker/xfree86-3d/"
 name="www.cs.utah.edu/~sparker/xfree86-3d/">
De plus, XFree86 et SuSe ont joint leurs efforts dans la
réalisation d'un GLX. Cf :
<htmlurl
 url="http://www.suse.de/~sim/"
 name="www.suse.de/~sim/">.
Pour l'instant, &Mesa; émule toujours de façon logicielle GLX 
avec Linux.


<sect1>&Glide; et les serveurs X commerciaux ?
<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.


<sect1>&Glide; et SVGA ?
<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. 

<sect1>&Glide; et GGI ?
<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 : 
<htmlurl
 url="http://synergy.caltech.edu/~ggi/"
 name="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 &OGL;. Il a été testé avec Mesa sans accélération. Pour
tout résumer, cela signifie que X11R6 est disponible sur 
&VooDoo; grâce à &Mesa; ou à &Glide;.

<sect>FAQ: &OGL;/&Mesa; ?

<sect1>Qu'est ce qu'&OGL; ?
<p>
&OGL; est une API pour le graphisme de niveau intermédiaire
développée par SGI à partir de leur interface précédente Iris GL.
&OGL; 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>
&OGL; 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, &OGL; forme un
ensemble d'outils puissant pour le graphisme accéléré sur ordinateur.

<sect1>Où trouver davantage d'informations sur OpenGL ?
<p>
Le site officiel d'&OGL;, administré par les membres de l'ARB :
<htmlurl
 url="http://www.opengl.org/"
 name="www.opengl.org">,
<p>
On préférera peut être la passerelle vers &OGL; de Mark Kilgard :
<htmlurl
 url="http://reality.sgi.com/mjk_asd/opengl-links.html"
 name="reality.sgi.com/mjk&lowbar;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.
<p>
Si le développement de jeu utilisant &OGL; vous tente, il 
existe une liste de diffusion <tt>OpenGL-GameDev-L@fatcity.com</tt>
accessible via <tt>Listserv@fatcity.com</tt>. Il s'agit
d'une liste à contenu fortement technique et dont le débit est
très élevé. Vous recourerez sûrement à <tt>procmail</tt> pour
ventiler la centaine de messages quotidiens qui en provient.
Pour réduire le besoin en bande passante, servez vous de la 
commande <tt>SET OpenGL-GameDev-L DIGEST</tt>. Cette liste
est inappropriée si vous cherchez des documents d'introduction.
L'archivage est assuré par le logiciel ListServ. Les commandes
<tt>INDEX OpenGL-GameDev-L</tt> et 
<tt>GET OpenGL-GameDev-L "filename"</tt> permettent de se 
faire un idée avant de souscrire.


<sect1>I&Glide; met-il en oeuvre &OGL; ?
<p>
Non. &Glide; est une API propriétaire de &c3Dfx; dont plusieurs
fonctions sont spécifiques aux composants &VooDoo; et &VooRush;.
Une librairie OpenGL &c3Dfx; 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>
La librairie &Mesa; de Brian Paul et le pilote &VooMesa; de
David Bucciarelli sont ce qui se rapproche le plus d'une
version Linux d'&OGL; accélérée grâce à des périphériques
particuliers ( voyez plus bas ).


<sect1>Existe-t-il un pilote &OGL; pour &c3Dfx; ?
<p>
Les sites web de &c3Dfx; et de Quantum3D annoncent une version
d'&OGL; pour &VooDoo; 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>
Aucun portage vers Linux n'a encore été annoncé pour l'instant.

<sect1>Existe-t-il une version commerciale d'&OGL; pour Linux et &c3Dfx; ?
<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.

<sect1>Qu'est-ce que Mesa ?
<p>
Mesa constitue une réalisation libre de l'API &OGL;, 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 &OGL;, du moins plus complète
que bon nombre de produits commerciaux.


<sect1>Mesa fonctionne-t-elle avec &c3Dfx; ?
<p>
La dernière version de &Mesa; &MesaVer; fonctionne avec Linux
&Glide; &GlVer;. 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>
Il vous faudra l'archive de la bibliothèque Mesa :
<htmlurl
 url="ftp://iris.ssec.wisc.edu/"
 name="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.

<sect1>Qu'en est-il de la portabilité de &Mesa; pour &Glide;?
<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>
&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 à :
<htmlurl
 url="http://www.geocities.com/~charlie_x/"
 name="www.geocities.com/~charlie_x/">.

<sect1>Où trouver des informations sur &Mesa; ?
<p>
La page web de &Mesa; :
<htmlurl
 url="http://www.ssec.wisc.edu/~brianp/Mesa.html"
 name="www.ssec.wisc.edu/~brianp/Mesa.html">.
L'archive de la liste de distribution &Mesa; :
<htmlurl
 url="http://www.iqm.unicamp.br/mesa/"
 name="www.iqm.unicamp.br/mesa/">. 
Cette liste n'est certes pas dédiée à &c3Dfx; ni à &Glide; mais 
il s'agit d'un bon point de départ si le recours au matériel 
&c3Dfx; pour accélérer &Mesa; vous intéresse.

<sect1>Où trouver des informations sur &VooMesa; ?
<p>
Pour les informations les plus à jour sur le pilote &VooMesa;
de David Bucciarelli
<htmlurl 
 url="mailto:tech.hmw@plus.it"
 name="tech.hmw@plus.it">,
reportez vous à la page web :
<htmlurl
 url="http://www-hmw.caribel.pisa.it/fxmesa/index.shtml"
 name="www-hmw.caribel.pisa.it/fxmesa/">.



<sect1>Mesa gère-t-il le texturage multiple ?
<p>
Pas encore en ce qui concerne &Mesa; &MesaVer; mais la question est
à l'étude. Vous disposerez probablement d'une extension &OGL;
<tt>EXT_multitexture</tt> sous &Mesa; une fois qu'elle sera achevée.
Il n'y a pas de spécifications figées pour le texturage multiple dans
&OGL;. La version 1.2 d'&OGL; 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
&VooD2; changera certainement la donne.

<sect1>Mesa supporte-t-elle le filtrage tri-linéaire en une seule étape ?
<p>
Linux &Glide; gère cette opération mais ce n'est pas le cas
de &Mesa; ( au moins jusqu'à la version &MesaVer; ). Le
développement est en cours.

<sect1>Qu'est-ce que le hack &Mesa ( "Window Hack" ) ?
<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; vers la mémoire vidéo pour chaque 
appel à la fonction <tt>glXSwapBuffers</tt>. Mesa offre 
également cette possibilité sous Windows.
<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;. 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>
Notez que cette fonctionnalité expérimentale n'a <em>RIEN</em>
à voir avec le &VooRush;. Elle ne concerne que les cartes
&VooRush;, 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>
Vérifiez le positionnement des variables suivantes :
<code>
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
</code>
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.


<sect1>Qu'en est-il de GLUT ?
<p>
La distribution GLUT de Mark Kilgard constitue une excellente 
ressource pour ce qui est des applications type et des 
utilitaires. Vous la trouverez à :
<htmlurl
 url="http://reality.sgi.com/mjk_asd/glut3/glut3.html"
 name="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.
<p>
Il existe une liste de diffusion spécifique à GLUT :
<tt>glut@perp.com</tt>. Envoyez à  
<htmlurl
 url="mailto:Majordomo@perp.com"
 name="majordomo@perp.com">
le message suivant :
<code>
   help
   info glut
   subscribe glut
   end
</code>
<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; 
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. 


<sect>FAQ: Quake ?

<sect1>Où en est le pilote &c3Dfx; GL pour Quake ?
<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
<htmlurl
url="http://www.cs.unc.edu/~martin/3dfx.html"
name="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 ( <tt>opengl32.dll</tt> ) fournie par &c3Dfx;.
Cette DLL n'a pas été portée sous Linux et il n'est pas
prévu qu'elle le soit un jour.

<sect1>Existe-t-il une version Linux de &c3Dfx; glQuake ?
<p>
Oui. Les binaires de linuxquake v0.97 supportent Mesa et Glide.
L'exécutable du programme q2test de Quake2 pour Linux
et &VooDoo; 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>
Pour les dernières versions :
<htmlurl
url="ftp://ftp.idsoftware.com/idstuff/quake/unix/"
name="ftp.idsoftware.com/idstuff/quake/unix/">.

<sect1>glQuake fonctionne-t-il dans une fenêtre XFree86 ?
<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.

<sect1>Comment réinitialiser l'affichage après un plantage de glQuake ?
<p>
Essayez d'utiliser le programme <tt>pass</tt> 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.

<sect1>Des problèmes avec Quake pour Linux ?
<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 &c3Dfx;.
<itemize>
<item>
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.
<item>
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.
<item>
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.
<item>
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.
<item>
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.
</itemize>

<sect1>Les trous de sécurité de Quake pour Linux 
<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 
<tt>setuid</tt>.
<p>
Si vous désirez employer les routines de rendu <tt>ref_soft</tt>
et <tt>ref_gl</tt>, 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>
Le rendu sous X11 ne requiert pas les privilèges root ( dès lors
que le <tt>/dev/dsp</tt> est accessible à tous en écriture ).
Le serveur associé n'a bien entendu pas non plus besoin de droits
particuliers.
<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 
<tt>ref_ggi</tt>.

<sect1>Linuxquake supporte-t-il le texturage multiple ?
<p>
glQuake offrira vraisemblablement une telle extension dès lors que 
le pilote &OGL; 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. 

<sect1>Où trouver des informations à jour sur glQuake pour Linux ?
<p>
Essayez les sites suivants : "The Linux Quake Resource" à
<htmlurl
url="http://linuxquake.telefragged.com/"
name="linuxquake.telefragged.com">, ou "Linux Quake Page" à
<htmlurl
url="http://www.planetquake.com/threewave/linux/"
name="www.planetquake.com/threewave/linux/">.
Jetez donc un oeil dans la base de données "SlipgateCentral"
pour trouver des sites Quake Linux :
<htmlurl
url="http://www.slipgatecentral.com/"
name="www.slipgatecentral.com">.



<sect>FAQ: solutions aux problèmes courants ?

<sect1>Cette carte a-t-elle été testée ?
<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 &c3Dfx; 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; 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>
Les fabricants souhaitant valider la compatibilité de leurs cartes 
&VooDoo;, &VooRush; ou &VooD2; 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 :
<htmlurl
 url="mailto:daryll@harlot.rb.ca.us"
 name="daryll@harlot.rb.ca.us">

<sect1>Échec lors du changement des privilèges d'entrées/sorties ?
<p>
Il faut que vous soyez root ou bien que l'identité associée à votre 
application puisse être telle ( cf <tt> setuid </tt> ). Le pilote se
sert du périphérique <tt>/dev/mem</tt> 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.

<sect1>Un fonctionnement sans les droits root est-il possible ?
<p>
Non. Des solutions de remplacement sont en cours de réalisation.

<sect1>L'affichage est déplorable !
<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>
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 &c3Dfx; ! ) 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.

<sect1>La dernière image ne disparaît pas !
<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. 


<sect1>L'économiseur d'écran se déclenche ( deux écrans ) ?
<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 :
<code>
setenv SST_DUALSCREEN 1
</code>


<sect1>Mon ordinateur semble se bloquer ( X11, un seul écran ) !
<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>
Si votre programme concurrence X11, il est conseillé d'installer une
fenêtre plein écran ou de se servir des fonctions <tt>XGrabPointer</tt>
et <tt>XGrabServer</tt> tandis que le serveur X est désactivé. Notez 
que le recours à <tt>XGrabPointer</tt> et à <tt>XGrabServer</tt> ne
qualifie pas une application comme particulièrement propre à l'égard
de X; le système pourrait ainsi se retrouver bloqué. 
<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 ).

<sect1>Ma machine se bloque ( un ou deux écrans ) ?
<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>
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;. 

<sect1>Ma machine se bloque ( avec une carte S3 ) ?
<p>
Il existe un problème de recouvrement de zones mémoires spécifique
aux cartes S3. Le site web &c3Dfx; 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; 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 ?

<sect1>Pas de conflit d'adresse mais la machine se bloque quand même !
<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 !

<sect1>Mesa est actif mais n'accède pas à la carte !
<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;. Vérifiez que vous avez supprimé
les anciennes bibliothèques, que vous avez relancé <tt>ldconfig</tt>
et/ou positionné correctement votre <tt>LD_LIBRARY_PATH</tt>.
&Mesa; inclut plusieurs pilotes ( MIT SHM pour X11, rendu hors écran,
&VooMesa; ) utilisables simultanément et il se peut que vous deviez
changer explicitement le pilote employé ( reportez vous à la fonction
<tt>MakeCurrent</tt> ) si le &VooDoo; n'est pas choisi par défaut.


<sect1>Réinitialiser une carte SLI ( configuration à deux cartes ) ?
<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é <tt>resetsli</tt> pour réinitialiser les cartes. Tant
que vous ne l'aurez pas appelé, la réinitialisation des cartes 
Obsidian restera impossible.


<sect1>Réinitialiser une carte SLI ( configuration à une seule carte ) ? 
<p>
Le programme <tt>resetsli</tt> 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.

</article>

<!-- ================================================= -->
<!-- end of Linux3Dfx.sgml                             -->
<!--
     Local Variables:
     mode: sgml
     End:                                              -->
<!-- ================================================= -->
