<!doctype linuxdoc system
   [
        <!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.2 2004/05/06 22:35:01 emmajane Exp $
     
    This is Linux3Dfx.sgml.
    It covers all aspects related to use of 3Dfx VooDoo
    based boards with Linux.

    $Log: 3Dfx-HOWTO.sgml,v $
    Revision 1.2  2004/05/06 22:35:01  emmajane
    Note added re. archived status.

    Revision 1.1  2000/04/26 18:26:14  gleblanc
    CVS restructuring, hopefully for better organization and with the goal of making updates automatic.


    Comments: Versions with "i" postfix are internal,
    for review, versions without are public and
    (supposed to be) released. The section marked
    "Internal" are not supposed to show up in the
    public releases.

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


<article>

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


<abstract>
The Linux &c3Dfx; HOWTO is not being maintained by the author,
and is no longer relevant to the modern Linux system. It was removed
from the collection May 6, 2004 by Emma Jane Hogbin (Technical Review
Coordinator) based on the advice of the maintainer at the time, Michael 
Scherer. Comments should be sent to discuss@en.tldp.org
<p>
This document describes &c3Dfx; graphics accelerator chip
support for Linux. It lists some supported hardware,
describes how to configure the drivers, and answers
frequently asked questions.
</abstract>


<!-- ====================================================== -->
<!-- Indexing                                               -->
<!-- The index entries below might overlap with similar
     entries from other HOWTO's e.g. on Mesa, GLint based
     graphics, XFree86. Thus they are set as "idxentry"
     style entries not meant to be tied to a particular
     location. They could be anywhere in the file.
     As the current backends maps invisible index entries
     into the Index, that is, has no "idxentry" complement
     to "idxref", I tried to put the index list in front
     of the table of contents which was organized
     in a way to remove the need for Index e.g. in HTML
     backends, where indexing is currently not supported
     anyway.
     Keeping them in one spot should ease manual adjustment
     of index entries from several documents into one
     global index not using too many synonyms.              -->



<toc>


<![ %Indexing 
 [

<p>
<nidx>Hardware accelerated 3D graphics with 3Dfx Voodoo</nidx>

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

<nidx>3Dfx</nidx>
<nidx>Voodoo chipset</nidx>
<nidx>Glide API for Linux</nidx>

<nidx>Quantum 3D</nidx>
<nidx>Obsidian graphics boards</nidx>

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

<nidx>Quake for Linux</nidx>
<nidx>GLQuake for Linux</nidx>
<nidx>GLQuake and 3Dfx Voodoo</nidx>
</p>

 ]]>

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

<sect>Introduction


<p>
This is the Linux &c3Dfx; HOWTO document. It is intended as a quick
reference covering everything you need to know to install and
configure &c3Dfx; support under Linux. Frequently asked questions
regarding the &c3Dfx; support are answered, and references
are given to some other sources of information on a variety of topics
related to computer generated, hardware accelerated 3D graphics.
<p>
This information is only valid for Linux on the Intel platform.  Some
information may be applicable to other processor architectures, but I
have no first hand experience or information on this. It is only
applicable to boards based on &c3Dfx; technology, any other graphics
accelerator hardware is beyond the scope of this document.


<sect1>Contributors and Contacts
<p>
This document would not have been possible without all the
information contributed by other people - those involved
in the Linux &Glide; port and the beta testing process, in
the development of &Mesa; and the &VooMesa; drivers, or
rewieving the document on behalf of &c3Dfx; and Quantum3D.
Some of them contributed entire sections to this document.
<p>
Daryll Strauss
<htmlurl 
 url="mailto:Daryll Strauss <daryll@harlot.rb.ca.us>"
 name="daryll@harlot.rb.ca.us"> did the port,
Paul J. Metzger
<htmlurl 
 url="mailto:Paul J. Metzger <pjm@rbd.com>"
 name="pjm@rbd.com">
modified the &VooMesa; driver (written by
David Bucciarelli
<htmlurl 
 url="mailto:David Bucciarelli <tech.hmw@plus.it>"
 name="tech.hmw@plus.it">) for Linux, 
Brian Paul 
<htmlurl 
 url="mailto:Brian Paul <brianp@RA.AVID.COM>"
 name="brianp@RA.AVID.COM">
integrated it
with his famous &Mesa; library. With respect to &VooDoo;
accelerated Mesa, additional thanks has to go to Henri Fousse,
Gary McTaggart, and the maintainer of the &c3Dfx; Mesa
for DOS,  Charlie Wallace
<htmlurl 
 url="mailto:Charlie Wallace <Charlie.Wallace@unistudios.com>"
 name="Charlie.Wallace@unistudios.com">.
The folks at &c3Dfx;,
notably Gary Sanders, Rod Hughes, and Marty Franz, provided
valuable input, as did Ross Q. Smith of Quantum3D. The
pages on the Voodoo Extreme and Operation 3Dfx websites
provided useful info as well, and in some case I relied on
the &c3Dfx; local Newsgroups. The Linux glQuake2 port
that uses Linux &Glide; and &Mesa; is maintained by
Dave Kirsch <htmlurl 
 url="mailto:Dave Kirsch <zoid@idsoftware.com>"
 name="zoid@idsoftware.com">.
Thanks to all those who sent
e-mail regarding corrections and updates, and special
thanks to Mark Atkinson for reminding me of the dual
cable setup.
<p>
Thanks to the &SGMLT; package (formerly known as Linuxdoc-SGML),
this HOWTO is available in several formats, all generated from a
common source file. For information on &SGMLT; see its homepage
at
<htmlurl 
   url="http://pobox.com/~cg/sgmltools"
   name="pobox.com/~cg/sgmltools">.


<sect1>Acknowledgments
<p>
&c3Dfx;, the &c3Dfx; Interactive logo, &VooDoo;, and &VooRush;
are registered trademarks of &c3Dfx; Interactive, Inc.
&Glide;, &TexUs;, &Pixelfx; and &Texelfx; are trademarks of 
3Dfx Interactive, Inc. &OGL; is a registered trademark of
Silicon Graphics. Obsidian is a trademark of Quantum3D.
Other product names are trademarks of the respective holders,
and are hereby considered properly acknowledged. 

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

<![ %Internal 
 [
<sect2>Internal Revision History
<p>
The verbose revision history below is for internal use only,
to provide assistance during the review/copy editing process.

  <code>
    Version 0.1i
      First version; used for proof-reading purposes only.
    Version 0.2i
      Added Flash3D, added Orchid R3D to list of boards 
      known to work, minor fixes.
      FAQ regarding grSstWinOpen() added, FAQ regarding
      Glide demos with ATB. Trademark acknowdlegments.
    Version 0.3i
      Added Quantum3D statements about Linux support,
      chipset definitions, Obsidian board. Added a
      bit on Voodoo architecture.
    Version 0.4i
      Official Obsidian taxonomy from Ross Q. Smith.
      Explanation on setuid from Daryll Strauss.
      Comments on Voodoo GLUT by David Bucciarelli.
    Version 0.5i
      Upgraded to 2.3.1, added Intergraph Intense.
    Version 1.0i
      Fixed news.3dfx hierarchy, added bug report
      group pointer, ready for release.
    Version 1.01i
      Corrections from Daryll, SST_DUALSCREEN, snapping
      vertices, removed setuid/device/XAA discussion.
    Version 1.02i
      P5 added to requirements. Removed Banshee. No
      Intergraph support. FAQ section overiew. 
    Version 1.03
      Corrected typos, added Macintosh. Changed wording 
      on grSstOpen error - might be removed entirely.
      Added a Mesa compilation problems section. More
      trademarks from the Glide docs. TexUS. ATB doc
      mentioned. Upp'ed to pending 2.4 release.

    Version 1.10i
      Internal revision, for long overdue update.
      Removed some general accelerated 3D graphics
      explanations. Stripped some vendor references,
      as I am not going to keep track of that in
      all detail. Added some Pixelfx, Texelfx,
      SLI, AGP, and other 3Dfx specific technical
      backgrounder. Removed the outdated commercial
      Linux OpenGL details. Added some more URL's
      of 3Dfx web and FTP site, ATB info, miniport
      info. Added some details to the Rush support
      issue (DirectDraw, SSST96). Added Mesa window
      hack. Removed the deprecated mdw LDP URL.
      LDP license link, copyright changed. Link to
      Stingray FAQ. Added info@quantum3d. Added a
      memory/board(s) configuration formula.
      A few GGI changes, resolved SVGA duplicate.
      Corrected GLUT version number.

    Version 1.11i
      Internal revision. Added www.opengl.org,
      emphasized pointer to Gateway. Added Mark
      Kilgard to beta mail alias. Added OpenGL
      GameDev list and ListServ archive reference.
      Hercules FAQ maintained by Kertis Henderson
      (kertis@frozenwave.com) confirmed. Added TMU
      alias to Texelfx entry. FAQ on support for
      multi TMU in current release. Added mention
      of seperate VR/VG distributions to current
      version FAQ. No mention of any upcoming Glide
      revisions. Added Mesa/Glide combo portability,
      and Charlie Wallace' DOS port. Moved X vs. AT3D
      into the X11 section, added technical details
      on problem to pacify those bitching, mentioned
      XFree86 3.3.3.2. Added Dirk Hohndel to beta mail
      alias. Added assembly remark to Alpha
      port question. Added texture size entry.
      Replaced max res. 1280x960 for SLI with 1024x768.
      Added overclocking/cooling comments. Removed
      outdated Mesa-2.3.x and Glide 2.3 specifics 
      like grSstWinOpen/grSstOpen. Added glQuake in
      window remark. Removed outdated VoodooGLUT in
      Mesa remark.

      Installed SGML-Tools v1.0.3. Added some minimal
      indexing for RedHat LDP compilation. Switched to
      Linuxdoc96 for release, as the nidx element has
      not been added to strict DTD, while idx has.
      Invisible indices cannot be created prior to
      ToC - bugger.
      Formatting: run into the familiar problem with
      LaTeX styles not updated properly, and a duplicate
      url.sty in a different location. Manual removal
      and copy. Run texconfig rehash, fixed read permit
      on style files. Formatting runs.
      The url attribute rendering screws up underscores
      and tilde character. OPP (other people's problem).
      Strange, a misspelled &3Dfx; entity slips through
      validation?

    Version 1.12i
      Rephrased multitexture in Mesa remark. Clarified
      the 1024x768 issue, ruled out 1280x960. Reworked
      info file for linux-3dfx@gamers.org proposal,
      rephrased entry. Fixed Glide version 2.4.
      ATB source hint, whatever it's worth. Fixed 3Dfx/
      Quantum corporate entry. Added Linux Quake setuid,
      an GL related bugs/workarounds from Dave Kirsch's
      plan. Added LinuxQuake sites.

    Version 1.13i
      Added "Internal" marked section, moved revision
      history out of comment. Have to take out <nidx>
      indexing after submission to RedHat, because it
      breaks HTML output. Added "Indexing" marked
      section, might actually scatter some more indices
      throughout the document that way. Memory speed
      mentioned as overclocking issue, lot of typos
      fixed there. Fixed outdated SGML-Tools URL. Mesa
      2.6b5 (current) and 3.0 (upcoming) mentioned. 
      Made separate Mesa multitexturing entry. Also made
      LinuxQuake multitexturing entry.

    Version 1.14i
      Added blatant plug to "supported hardware" section,
      for Voodoo2 board loans and DEC Alpha. Reworded
      Glide multitexture section a bit, added Mesa
      single pass trilinear filtering. Added "as of 2.6b5"
      to Mesa statements.
 
    Version 1.15i
      Upped Mesa to 2.6b6. Feedback from Daryll, Paul, and
      Brian so far. Created a Contributors and Contacts
      section following Paul's suggestion, included all
      e-mails of those publicly visible (no 3Dfx/Quantum3D
      mailto). Added single screen dual cable as proposed
      by Mark Atkinson. Typos. Slightly reworded Quantum3D
      entry added to How do boards differ. Added two cross
      references to Mesa window hack. Added single board
      Obsidian SB SLI, added resetting dual and single
      board SLI reset problem. Glide 3.0 is publicly talked
      about, thus added a remark to current version. Keep
      linux-3dfx mailing list entry. Disclaimer with Mark
      Kilgards SGI address, GLUT mailing list.
    Version 1.16
      Switched Internal to IGNORE, upped current version,
      notified LDP.

   </code>

 ]]>



<!-- ====================================================== -->
<sect1>New versions of this document
<p>
You will find the most recent version of this document at
<htmlurl
 url="http://www.gamers.org/dEngine/xf3D/"
 name="www.gamers.org/dEngine/xf3D/">.
<p>
New versions of this document will be periodically posted to the
<htmlurl 
url="news:comp.os.linux.answers"
name="comp.os.linux.answers"> newsgroup. They will also be uploaded
to various anonymous ftp sites that archive such information including
<htmlurl 
url="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/"
name ="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/">.
<p>
Hypertext versions of this and other Linux HOWTOs are available on
many World-Wide-Web sites, including 
<htmlurl
url="http://sunsite.unc.edu/LDP/"
name="sunsite.unc.edu/LDP/">. Most Linux CD-ROM
distributions include the HOWTOs, often under the 
<tt>/usr/doc/</tt>directory, and you can also buy printed copies from
several vendors.
<p>
If you make a translation of this document into another language, let
me know and I'll include a reference to it here.


<sect1>Feedback
<p>
I rely on you, the reader, to make this HOWTO useful. If you have any
suggestions, corrections, or comments, please send them to me (
<htmlurl 
 url="mailto:bk@gamers.org"
 name="bk@gamers.org">), and I will try to
incorporate them in the next revision.  Please add 
<tt>HOWTO 3Dfx</tt> to the Subject-line of the mail, so procmail
will dump it in the appropriate folder.
<p>
Before sending bug reports or questions, <EM>please read all of the
information in this HOWTO</EM>, and <EM>send detailed information
about the problem</EM>.
<p>
If you publish this document on a CD-ROM or in hardcopy form, a
complimentary copy would be appreciated. Mail me for my postal
address. Also consider making a donation to the
Linux Documentation Project to help support
free documentation for Linux. Contact the
Linux HOWTO coordinator, Tim Bynum 
(<htmlurl 
 url="mailto:linux-howto@sunsite.unc.edu"
 name="linux-howto@sunsite.unc.edu">), 
for more information.


<sect1>Distribution Policy
<p>
Copyright (c) 1997, 1998 by Bernd Kreimeier.
This document may be
      distributed under the terms set forth in the LDP license 
      at 
<htmlurl 
 url="http://sunsite.unc.edu/LDP/COPYRIGHT.html"
 name="sunsite.unc.edu/LDP/COPYRIGHT.html">.
<p>
This HOWTO is free documentation; you can redistribute it and/or
modify it under the terms of the LDP license.
This document is distributed in the hope that it will be useful, but
<bf>without any warranty</bf>; without even the implied warranty of
<bf>merchantability</bf> or <bf>fitness for a particular purpose</bf>.
See the LDP license for more details.




<!-- ====================================================== -->
<sect>Graphics Accelerator Technology

<sect1>Basics
<p>
This section gives a <em>very</em> cursory overview of computer 
graphics accelerator technology, in order to help you understand
the concepts used later in the document. You should consult e.g.
a book on &OGL; in order to learn more.

<sect1>Hardware configuration
<p>
Graphics accelerators come in different flavors: either
as a separate PCI board that is able to pass through
the video signal of a (possibly 2D or video accelerated)
VGA board, or as a PCI board that does both VGA and
3D graphics (effectively replacing older VGA controllers).
The &c3Dfx; boards based on the &VooDoo; belong to the
former category. We will get into this again later.
<p> 
If there is no address conflict, any 3D accelerator
board could be present under Linux without interfering,
but in order to access the accelerator, you will need
a driver. A combined 2D/3D accelerator might behave
differently.

<sect1>A bit of &VooDoo; architecture
<p>
Usually, accessing texture memory and frame/depth buffer is a
major bottleneck. For each pixel on the screen, there are
at least one (nearest), four (bi-linear), or eight (tri-linear
mipmapped) read accesses to texture memory, plus a read/write
to the depth buffer, and a read/write to frame buffer memory.
<p>
The &VooDoo; architecture separates texture memory from
frame/depth buffer memory by introducing two separate
rendering stages, with two corresponding units (&Pixelfx; and
&Texelfx;), each having a separate memory interface to dedicated
memory. This gives an above-average fill rate, paid for
restrictions in memory management (e.g. unused framebuffer
memory can not be used for texture caching).
<p>
Moreover, a &VooDoo; could use two TMU's (texture management
or texelfx units), and finally, two &VooDoo; could be
combined with a mechanism
called Scan-Line Interleaving (SLI). SLI essentially
means that each &Pixelfx; unit effectively provides only
every other scanline, which decreases bandwidth impact
on each &Pixelfx;' framebuffer memory.  


<sect>Installation
<p>
Configuring Linux to support &c3Dfx; accelerators involves the
following steps:

<enum>
<item>Installing the board.
<item>Installing the &Glide; distribution.
<item>Compiling, linking and/or running the application.
</enum>

The next sections will cover each of these steps in detail.

<sect1>Installing the board
<p>
Follow the manufacturer's instructions for installing the hardware or
have your dealer perform the installation.
It should not be necessary to select settings for IRQ, DMA channel,
either Plug&amp;Pray (tm) or factory defaults should work. The
add-on boards described here are memory mapped devices and do
not use IRQ's. The only kind of conflict to avoid 
is memory overlap with other devices.
<p>
As &c3Dfx; does not develop or sell any boards, do not contact
them on any problems. 

<sect2>Troubleshooting the hardware installation
<p>
To check the installation and the memory mapping, do 
<tt>cat /proc/pci</tt>. The output should contain something like
<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>
for a Diamond Monster 3D used with a Diamond Stealth-64. Additionally
a <tt>cat /proc/cpuinfo /proc/meminfo</tt> might be helpfull for
tracking down conflicts and/or submitting a bug report.
<p>
With current kernels, you will probably get a boot warning
like
<code>
Jun 12 12:31:52 hal kernel: Warning : Unknown PCI device (121a:1).
Please read include/linux/pci.h 
</code>
which could be safely ignored. If you happen to have a board
not very common, or have encountered a new revision, you should
take the time to follow the advice in <tt>/usr/include/linux/pci.h</tt>
and send all necessary information
to
<htmlurl 
        url="mailto:linux-pcisupport@cao-vlsi.ibp.fr"
        name="linux-pcisupport@cao-vlsi.ibp.fr">.
<p>
If you experience any problems with the board, you should
try to verify that DOS and/or Win95 or NT support works. You
will probably not receive any useful response from a
board manufacturer on a bug report or request regarding
Linux. Having dealt with the Diamond support e-mail
system, I would not expect useful responses for other
operating systems either. 

<sect2>Configuring the kernel
<p>
There is no kernel configuration necessary, as long as PCI
support is enabled.
The <url url="http://sunsite.unc.edu/mdw/HOWTO/Kernel-HOWTO.html"
name="Linux Kernel HOWTO"> should be consulted for the details of
building a kernel.


<sect2>Configuring devices
<p>
The current drivers do not (yet) require any special devices.
This is different from other driver developments 
(e.g. the sound drivers, where you will find 
a <tt>/dev/dsp</tt> and <tt>/dev/audio</tt>). The
driver uses the <tt>/dev/mem</tt> device which should 
always be available. In consequence, you need to use
<tt>setuid</tt> or root privileges to access the 
accelerator board. 

<sect1>Setting up the Displays
<p>
There are two possible setups with add-on boards. You
could either pass-through the video signal from your
regular VGA board via the accelerator board to the
display, or you could use two displays at the same time.
Rely to the manual provided by the board manufacturer
for details. Both configurations have been tried with
the Monster 3D board.

<sect2>Single screen display solution
<p>
This configuration allows you to check basic operations
of the accelerator board - if the video signal is not
transmitted to the display, hardware failure is possible.
<p>
Beware that the video output signal might deteoriate
significantly if passed through the video board. To
a degree, this is inevitable. However, reviews have
complained about below-average of the cables provided
e.g. with the Monster 3D, and judging from the one I
tested, this has not changed.
<p>
There are other pitfalls in single screen configurations.
Switching from the VGA display mode to the accelerated 
display mode will change resolution and refresh rate as
well, even if you are using 640x480 e.g. with X11, too.
Moreover, if you are running X11, your application is
responsible for demanding all keyboard and mouse events,
or you might get stuck because of changed scope and exposure
on the X11 display (that is effectively invisible when the
accelerated mode is used) You could use SVGA console mode
instead of X11.
<p>
If you are going to use a single screen configuration and
switch modes often, remember that your monitor hardware
might not enjoy this kind of use. 


<sect2>Single screen dual cable setup
<p>
Some high end monitors (e.g. the EIZO F-784-T)
come with two connectors, one with 5 BNC connectors
for RGB, HSync, VSync, the other e.g. a regular VGA
or a 13W3 Sub-D VGA.
These displays usually also feature a front panel
input selector to safely switch from one to the
other. It is thus possible to use e.g. a VGA-to-BNC
cable with your high end 2D card, and a VGA-to-13W3
Sub-D cable with your 3Dfx, and effectively run dual
screen on one display.


<sect2>Dual screen display solution
<p>
The accelerator board does not need the VGA input signal.
Instead of routing the common video output through the
accelerator board, you could attach a second monitor to
its output, and use both at the same time. This solution
is more expensive, but gives best results, as your main
display will still be hires and without the signal
quality losses involved in a pass-through solution. In
addition, you could use X11 and the accelerated full
screen display in parallel, for development and debugging.
<p>
A common problem is that the accelerator board will not
provide any video signal when not used. In consequence,
each time the graphics application terminates, the
hardware screensave/powersave might kick in depending
on your monitors configuration. Again, your hardware
might not enjoy being treated like this. You should
use
<code>
setenv SST_DUALSCREEN 1
</code>
to force continued video output in this setup.
 
<sect1>Installing the &Glide; distribution
<p>
The &Glide; driver and library are provided as a single
compressed archive. Use <tt>tar</tt> and <tt>gzip</tt>
to unpack, and follow the instructions in the
README and INSTALL accompanying the distribution.
Read the install script and run it. Installation puts
everything in /usr/local/glide/include,lib,bin and sets
the ld.conf to look there. Where it installs and setting
ld.conf are independent actions. If you skip the ld.conf
step then you need the LD_LIBRARY_PATH.
<p>
You will need to install the header files in a location
available at compile time, if you want to compile your own
graphics applications. If you do not want to use the
installation as above (i.e. you insist on a different
location), make sure that any application could access
the shared libary at runtime, or you will get a response
like
<tt>can't load library 'libglide.so'</tt>.



<sect2>Using the detect program
<p>
There is a <tt>bin/detect</tt> program in the distribution
(the source is not available). You have to run it as root,
and you will get something like
<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>
as a result. If you do not have root privileges, the program will
bail out with
<code>
Permission denied: Failed to change I/O privilege. Are you root?
</code>
output might come handy for a bug report as well.



<sect2>Using the test programs
<p>
Within the &Glide; distribution, you will find a folder with
test programs. Note that these test programs are under
&c3Dfx; copyright, and are legally available for use only
if you have purchased a board with a &c3Dfx; chipset. See
the LICENSE file in the distribution, or 
their web site
 <htmlurl 
        url="http://www.3dfx.com/"
        name="www.3dfx.com"> for details.
<p>
It is recommend to compile and link the test programs even
if there happen to be binaries in the distribution. Note
that some of the programs will requires some files
like <tt>alpha.3df</tt> from the distribution to be available
in the same folder. 
All test programs use the 640x480 screen resolution. Some
will request a veriety of single character inputs, others
will just state <tt>Press A Key To Begin Test</tt>. Beware
of loss of input scope if running X11 on the same screen
at the same time.
<p>
See the README.test for a list of programs, and other details.





<sect>Answers To Frequently Asked Questions
<p>
The following section answers some of the questions that
(will) have been asked on the Usenet news groups and mailing
lists. The FAQ has been subdivided into several parts for
convenience, namely
<itemize>
<item>FAQ: Requirements?
<item>FAQ: &VooDoo;? &c3Dfx;?
<item>FAQ: &Glide;?
<item>FAQ: &Glide; and SVGA?
<item>FAQ: &Glide; and XFree86?
<item>FAQ: &Glide; versus OpenGL/Mesa?
<item>FAQ: But Quake?
<item>FAQ: Troubleshooting?
</itemize>
Each section lists several questions and answers, which
will hopefully address most problems.


<sect>FAQ: Requirements?

<sect1>What are the system requirements?
<p>
A Linux PC, PCI 2.1 compliant, a monitor capable 
of 640x480, and a 3D accelerator board based on
the &c3Dfx; &VooDoo;. It will work on a P5 or P6,
with or without MMX. The current version does not
use MMX, but it has some optimized code paths for P6. 
<p>
At one point, some &c3Dfx; statements seemed to
imply that using Linux &Glide; required using a
RedHat distribution. Note that while
Linux &Glide; has originally been ported in a
RedHat 4.1 environment, it has been used and
tested with many other Linux distributions,
including homebrew, Slackware, and Debian 1.3.1.

<sect1>Does it work with Linux-Alpha?
<p>
There is currently no Linux &Glide; distribution available
for any platform besides i586. As the &Glide; sources are
not available for distribution, you will have to
wait for the binary. Quantum3D has DEC Alpha support
announced for 2H97. Please contact Daryll Strauss
if you are interested in supporting this.
<p>
There is also the issue of porting the assembly
modules. While there are alternative C paths in the
code, the assembly module in &Glide; (essentially
triangle setup) offered significant performance gains
depending on the P5 CPU used.


<sect1>Which &c3Dfx; chipsets are supported? 
<p>
Currently, the  &c3Dfx; &VooDoo; chipset is supported
under Linux. The &VooRush; chipset is not yet supported.

<sect1>Is the &VooRush; supported?
<p>
The current port of &Glide; to Linux does not support
the &VooRush;. An update is in the works.
<p>
The problem is that at one point the &VooRush; driver
code in &Glide; depended on Direct Draw. There was
an SST96 based DOS portion in the library that could
theoretically be used for Linux, as soon as all
portions residing in the 2D/Direct Draw/D3D combo
driver are replaced.
<p>
Thus &VooRush; based boards like the 
<em>Hercules Stingray 128/3D</em>
or <em>Intergraph Intense Rush</em> are not supported
yet.


<sect1>Which boards are supported?
<p>
There are no officially supported boards, as &c3Dfx; does
not sell any boards. This section does not attempt to 
list all boards, it will just give an overview, and
will list only boards that have been found to cause
trouble.
<p>
It is important to recognize that Linux support for a given
board does not only require a driver for the 3D accelerator
component. If a board features its own VGA core as well,
support by either Linux SVGA or XFree86 is required as well
(see section about &VooRush; chipset).
Currently, an add-on solution is recommended, as it allows
you to choose a regular graphics board well supported for
Linux. There are other aspects discussed below.
<p>
All Quantum3D Obsidian boards, independend of texture
memory, frame buffer memory, number of Pixelfx and
Texelfx units, and SLI should work. Same for all other
 &VooDoo; based boards, like  Orchid Righteous 3D, Canopus
Pure 3D, Flash 3D, and Diamond Monster 3D.
&VooRush; based boards are not yet supported.
<p>
Boards that are not based on &c3Dfx; chipsets (e.g. manufactured
by S3, Matrox, 3Dlabs, Videologic) do <em>not</em> work with the &c3Dfx;
drivers and are beyond the scope of this document.



<sect1>How do boards differ?
<p>
As the board manufacturers are using the same chipset,
any differences are due to board design. Examples are
quality of the pass-through cable and connectors
(reportedly, Orchid provided better quality than
Diamond), availability of a TV-compliant video
signal output (Canopus Pure 3D), and, most notably,
memory size on board.
<p>
Most common were boards for games
with 2MB texture cache and 2 MB framebuffer memory,
however, the Canopus Pure3D comes with a maximal
4 MB texture cache, which is an advantage e.g.
with games using dynamically changed textures,
and/or illumation textures (Quake, most notably).
The memory architecture of a typical &VooDoo;
board is described below, in a separate section.
<p>
Quantum 3D offers the widest selection of &c3Dfx;-based
boards, and is probably the place to go if you are
looking for a high end &VooDoo; based board configuration.
Quantum 3D is addressing the visual simulation market,
while most of the other vendors are only targetting the
consumer-level PC-game market.


<sect1>What about AGP?
<p>
There is no &VooDoo; or &VooRush; AGP board that I am
aware of. I am not aware of AGP support under Linux,
and I do not know whether upcmong AGP boards using
&c3Dfx; technology might possibly be supported with
Linux.



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

<sect1>Who is &c3Dfx;?
<p>
&c3Dfx is a San Jose based manufacturer of 3D graphics 
accelerator hardware for arcade games, game consoles,
and PC boards.
Their official website is
<htmlurl
 url="http://www.3dfx.com/"
 name="www.3dfx.com">. &c3Dfx; does not sell any boards,
but other companies do, e.g. Quantum3D.


<sect1>Who is Quantum3D?
<p>
Quantum3D started as a &c3Dfx; spin-off, manufacturing
high end accelerator boards based on &c3Dfx; chip
technology for consumer and business market, and
supplying arcade game technology. See
their home page at
<htmlurl
 url="http://www.quantum3d.com/"
 name="www.quantum3d.com">
for additional information. For general inquiries
regarding Quantum3D,
please send mail to
<htmlurl
 url="mailto:info@quantum3d"
 name="info@quantum3d">.



<sect1>What is the &VooDoo;?
<p>
The &VooDoo; is a chipset manufactured by &c3Dfx;. It
is used in hardware acceleration boards for the PC.
See the HOWTO section on supported hardware.

<sect1>What is the &VooRush;?
<p>
The &VooRush; is a derivate of the &VooDoo; that
has an interface to cooperate with a 2D VGA
video accelerator, effectively supporting
accelerated graphics in windows. This combo 
is currently not supported with Linux.

<sect1>What is the &VooD2;?
<p>
The &VooD2; is the successor of the &VooDoo; chipset,
featuring several improvements. It is announced
for late March 1998, and annoucements of &VooD2;
based boards have been published e.g. by Quantum 3D,
by Creative Labs, Orchid Technologies, and
Diamond Multimedia.
<p>
The &VooD2; is supposed to be backwards compatible.
However, a new version of &Glide; will have to be
ported to Linux. 


<sect1>What is VGA pass-though?
<p>
The &VooDoo; (but not the &VooRush;) boards are
add-on boards, meant to be used with a regular
2D VGA video accelerator board. In short, the
video output of your regular VGA board is used
as input for the &VooDoo; based add-on board,
which by default passes it through to the display
also connected to the &VooDoo; board. If the
&VooDoo; is used (e.g. by a game), it will
disconnect the VGA input signal, switch the
display to a 640x480 fullscreen mode with the
refresh rate configured by SST variables and
the application/driver, and generate the video
signal itself. The VGA doesn't need to be aware
of this, and won't be.
<p>
This setup has several advantages: free choice
of 2D VGA board, which is an issue with Linux,
as XFree86 drivers aren't available for all
chipsets and revisions, and a cost effective 
migration path to accelerated 3D graphics. It 
also has several disadvantages: an application
using the &VooDoo; might not re-enable video
output when crashing, and regular VGA video
signal deteoriates in the pass-through
process.

<sect1>What is &Texelfx; or TMU?
<p>
&VooDoo; chipsets have two units. The first one interfaces
the texture memory on the board, does the texture mapping,
and ultimately generates the input for the second unit
that interfaces the framebuffer. This one is called
&Texelfx;, aka Texture Management Unit, aka TMU. The neat
thing about this is that a board can use two &Texelfx;
instead of only one, like some of
the Quantum3D Obsidian boards did, effectively doubling the
processing power in some cases, depending on the application.
<p>
As each &Texelfx; can address 4MB texture memory, a dual
&Texelfx; setup has an effective texture cache of up to 8MB.
This can be true even if only one &Texelfx; is actually
needed by a particular application, as textures can be
distributed to both &Texelfx;, which are used depending
on the requested texture. Both &Texelfx; are used together
to perform certain operations as trilinear filtering and
illumination texture/lightmap passes (e.g. in glQuake)
in a single pass instead of the two passes that are
required with only one &Texelfx;. To actually exploit the
theoretically available speedup and cache size increase,
a &Glide; application has to use both &Texelfx; properly.
<p>
The two &Texelfx; can not be used separately to
each draw a textured triangle at the same time. A triangle
is always drawn using whatever the current setup is,
which can be to use both &Texelfx; for a single pass
operation combining two textures, or one &Texelfx;
for only a single texture. Each &Texelfx; can only
access its own memory.


<sect1>What is a &Pixelfx; unit?
<p>
&VooDoo; chipsets have two units. The second one interfaces
the framebuffer and ultimately generates the depth buffer
and pixel color updates. This one is called &Pixelfx;. The
neat thing here is that two &Pixelfx; units can cooperate
in SLI mode, like with some of the Quantum3D Obsidian boards,
effectively doubling the frame rate.


<sect1>What is SLI mode?
<p>
SLI means "Scanline Interleave". In this mode, two &Pixelfx;
are connected and render in alternate turns, one handling
odd, the other handling even scanlines of the actual output.
Inthis mode, each &Pixelfx; stores only half of the image
and half of the depth buffer data in its own local
framebuffer, effectively doubling the number of pixels.
<p>
The &Pixelfx; in question can be on the same board,
or on two boards properly connected. Some Quantum3D
Obsidian boards support SLI with &VooDoo;.
<p>
As two cards can decode the same PCI addresses and receive
the same data, there is not necessarily additional bus
bandwidth required by SLI. On the other hand, texture
data will have to be replicated on both boards, thus
the amount of texture memory effectively stays the same.


<sect1>Is there a single board SLI setup?
<p>
There are now two types of Quantum3D SLI boards.
The intial setup used two boards, two PCI slots,
and an interconnect (e.g. the Obsidian 100-4440).
The later revision which performs identically is
contained on one full-length PCI board (e.g.
Obsidian 100-4440SB). Thus a single board SLI
solution is possible, and has been done.


<sect1>How much memory? How many buffers?
<p>
The most essential difference between different boards
using the &VooDoo; chipset is the amount and
organization of memory. Quantum3D used a three digit
scheme to descibe boards. Here is a slightly modifed
one (anticipating &VooD2;). Note that if you use
more than one Texelfx, they need the same amount of
texture cache memory each, and if you combine two
Pixelfx, each needs the same amount of frame buffer
memory. 
<code>
    "SLI / Pixelfx / Texelfx1 / Texelfx2 "
</code>
It means that a common 2MB+2MB board would be a
<tt>1/2/2/0</tt> solution, with the minimally
required total 4Mb of memory. A Canopus Pure 3D
would be <tt>1/2/4/0</tt>, or 6MB. An Obsidian-2220
board with two Texelfx would be <tt>1/2/2/2</tt>,
and an Obsidian SLI-2440 board would be <tt>2/2/4/4</tt>.
A fully featured dual board solution (2 Pixelfx, each
with 2 Texelfx and 4MB frame buffer, each Texelfx 4 MB
texture cache) would be <tt>2/4/4/4</tt>, and the
total amount of memory would be
<tt>SLI*(Pixelfx+Texelfx1+Texelfx2)</tt>, or 24 MB.   
<p>
So there. 

<sect1>Does the &VooDoo; do 24 or 32 bit color?
<p>
No. The &VooDoo; architecture uses 16bpp internally.
This is true for  &VooDoo;, &VooRush; and &VooD2;
alike. Quantum3D claims to implement 22-bpp effective color depth
with an enhanced 16-bpp frame buffer, though. 

<sect1>Does the &VooDoo; store 24 or 32 bit z-buffer per pixel?
<p>
No. The &VooDoo; architecture uses 16bpp internally
for the depth buffer, too. This again is true for  &VooDoo;,
&VooRush; and &VooD2; alike. Again, Quantum3D claims
that using the floating point 16-bits per pixel (bpp) depth
buffering provides 22-bpp effective Z-buffer precision.

<sect1>What resolutions does the &VooDoo; support?
<p>
The &VooDoo; chipset supports up to 4 MB frame buffer
memory. Presuming double buffering and a depth buffer,
a 2MB framebuffer will support a resolution of 640x480.
With 4 MB frame buffer, 800x600 is possible.
<p>
Unfortunately 960x720 is not supported. The &VooDoo;
chipset requires that the amount of memory for a particular
resolution must be such that the vertical and horizontal
resolutions must be evenly divisible by 32. The video
refresh controller, though can output any particular
resolution, but the "virtual" size required for the memory
footprint must be in dimensions evenly divisible by 32.
So, 960x720 actually requires 960x736 amount of memory,
and 960x736x2x3 = 4.04MBytes.
<p>
However, using two boards with SLI, or a dual &Pixelfx;
SLI board means that each framebuffer will only have
to store half of the image. Thus 2 times 4 MB in SLI
mode are good up to 1024x768, which is the maximum
because of the overall hardware design. You will be
able to do 1024x768 tripled buffered with Z, but you
will not be able to do e.g. 1280x960 with double
buffering.
<p>
Note that triple buffering (no VSync synchonization 
required by the application), stereo buffering (for
interfacing LCD shutters) and other more demanding
setups will severely decrease the available resolution.


<sect1>What texture sizes are supported?
<p>
The maximum texture size for the &VooDoo; chipset 
is 256x256, and you have to use powers of two. Note
that for really small textures (e.g. 16x16) you
are better off merging them into a large texture,
and adjusting your effective texture coordinates
appropriately.

<sect1>Does the &VooDoo; support paletted textures?
<p>
The &VooDoo; hardware and &Glide; support the palette
extension to &OGL;. The most recent version of
&Mesa; does support the 
<tt>GL_EXT_paletted_texture</tt>
and 
<tt>GL_EXT_shared_texture_palette</tt> extensions.


<sect1>What about overclocking?
<p>
If you want to put aside considerations about warranty
and overheating, and want to do overclocking to boost
up performance even further, there is related info out
on the web. The basic mechanism is to use
&Glide; environment variables to adjust the clock.
<p>
Note that the actual recommended clock is board
dependend. While the default clock speed is 50 Mhz,
the Diamond Monster 3D property sheet lets you set up
a clock of 57 MHz. It all comes down to the design of
a specific board, and which components are used with
the &VooDoo; chipset - most notably access speed of
the RAM in question. If you exceed the limits of your
hardware, rendering artifacts will occur to say the
least. Reportedly, 57 MHz usually works, while 60 MHz
or more is already pushing it.
<p>
Increasing the clock frequency also means increasing
the waste heat disposed in the chips, in a nonlinear
dependency (10% increase in frequency means a lot
larger increase in heating). In consequence, for permanent
overclocking you might want to educate yourself about
ways to  add cooling fans to the board in a way that does
not affect warranty. A very recommendable source is
the "3Dfx Voodoo Heat Report" by Eric van Ballegoie,
available on the web.


<sect1>Where could I get additional info on &VooDoo;?
<p>
There is a FAQ by &c3Dfx;, which should be available
at their
<htmlurl
 url="http://www.3dfx.com/voodoo/faq.html"
 name="web site">.
You will find retail information
at the following locations:
<htmlurl
 url="http://www.3dfx.com/voodoo/sale/"
 name="www.3dfx.com">
and
<htmlurl
 url="http://www.quantum3d.com/"
 name="www.quantum3d.com">.
<p>
Inofficial sites that have good info
are "Voodoo Extreme" at
<htmlurl
 url="http://www.ve3d.com/"
 name="www.ve3d.com">, and
"Operation 3Dfx"
at 
<htmlurl
 url="http://www.ve3d.com/"
 name="www.ve3d.com">.



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

<sect1>What is &Glide; anyway?
<p>
&Glide; is a proprietary API plus drivers to access
3D graphics accelerator hardware based on chipsets
manufactured by &c3Dfx;. &Glide; has been developed
and implemented for DOS, Windows, and Macintosh, and
has been ported to Linux by Daryll Strauss.

<sect1>What is &TexUs;?
<p>
In the distribution is a <tt>libtexus.so</tt>, which
is the &c3Dfx; Interactive Texture Utility Software.
It is an image processing libary and utility program
for preparing images for use with the &c3Dfx;
Interactive &Glide; library. Features of &TexUs; include
file format conversion, MIPmap creation, and support for
&c3Dfx; Interactive Narrow Channel Compression
textures.
<p>
The &TexUs; utility program <tt>texus</tt>
reads images in several popular formats (TGA, PPM,
RGT), generates MIPmaps, and writes the
images as &c3Dfx; Interactive textures files
(see e.g. alpha.3df, as found in the distribution)
or as an image file for inspection. For details
on the parameters for <tt>texus</tt>, and the
API, see the &TexUs; documentation.


<sect1>Is &Glide; freeware?
<p>
Nope. &Glide; is neither GPL'ed nor subject to any other
public license. See LICENSE in the distribution for any
details. Effectively, by downloading and using it, you
agree to the End User License Agreement (EULA) on the
&c3Dfx; web site. &Glide; is provided as binary only,
and you should
neither use nor distribute any files but the ones released
to the public, if you have not signed an NDA. The &Glide;
distribution including the test program sources are
copyrighted by &c3Dfx;.
<p>
The same is true for all the sources in the &Glide;
distribution. In the words of &c3Dfx;: These are not public
domain, but they can be freely distributed to
owners of 3Dfx products only.  No card, No code!

<sect1>Where do I get &Glide;?
<p>
The entire &c3Dfx; SDK is available for download off their
public web-site located at  
<htmlurl
 url="http://www.3dfx.com/software/download_glide.html"
 name="www.3dfx.com/software/download_glide.html">. Anything
else &c3Dfx; publicly released by &c3Dfx; is nearby on
their website, too. 
<p>
There is also an FTP site, 
<htmlurl
 url="ftp://ftp.3dfx.com/"
 name="ftp.3dfx.com">. The FTP has a longer timeout, and some
of the larger files have been broken into 3 files
(approx. 3MB each). 


<sect1>Is the &Glide; source available?
<p>
Nope. The &Glide; source is made available only based
on a special agreement and NDA with &c3Dfx;.

<sect1>Is Linux &Glide; supported?
<p>
Currently, Linux &Glide; is unsupported. Basically,
it is provided under the same disclaimers
as the 3Dfx GL DLL (see below).
<p>
However, &c3Dfx; definitely wants to provide as much
support as possible, and is in the process of
setting up some prerequisites. For the time being,
you will have to rely on the &c3Dfx; newsgroup (see
below). 
<p>
In addition, the Quantum3D web page claims that
Linux support (for Obsidian) is planned for both Intel
and AXP architecture systems in 2H97.

<sect1>Where could I post &Glide; questions?
<p>
There are newsgroups currently available only on
the NNTP server <htmlurl
 url="news://news.3dfx.com/"
 name="news.3dfx.com"> run by 3Dfx.
This USENET groups are dedicated to
&c3Dfx; and &Glide; in general, and will mainly provide
assistance for DOS, Win95, and NT. The current
list includes:
<code>
3dfx.events
3dfx.games.glquake
3dfx.glide
3dfx.glide.linux
3dfx.products
3dfx.test
</code>
and the <tt>3dfx.oem.products.*</tt> group for
specific boards, eg. <tt>3dfx.oem.products.quantum3d.obsidian</tt>.
Please use 
<htmlurl
 url="news://news.3dfx.com/3dfx.glide.linux"
 name="news.3dfx.com/3dfx.glide.linux"> for all
Lnux &Glide; related questions.
<p>
A mailing list dedicated to Linux &Glide; is in preparation
for 1Q98. Send mail to 
<htmlurl
 url="mailto:majordomo@gamers.org"
 name="majordomo@gamers.org">, no subject,
body of the message <tt>info linux-3dfx</tt> to get
information about the posting guidelines, the
hypermail archive and how
to subscribe to the list or the digest.


<sect1>Where to send bug reports?
<p>
Currently, you should rely on the newsgroup (see above),
that is
<htmlurl
 url="news://news.3dfx.com/3dfx.glide.linux"
 name="news.3dfx.com/3dfx.glide.linux">.
There is no official support e-mail set up yet.
For questions not specific to Linux Glide, make sure
to use the other newsgroups.

<sect1>Who is maintaining it?
<p>
&c3Dfx; will appoint an official maintainer soon.
Currently, inofficial maintainer of the Linux
&Glide; port is Daryll Strauss. Please post
bug reports in the newsgroup (above). If you
are confident that you found a bug not previously
reported, please mail to Daryll at
<htmlurl
 url="mailto:daryll@harlot.rb.ca.us"
 name="daryll@harlot.rb.ca.us">

<sect1>How can I contribute to Linux &Glide;?
<p>
You could submit precise bug reports. Providing sample
programs to be included in the distribution is another
possibility. A major contribution would be adding
code to the &Glide; based &VooMesa; driver source. 
See section on &VooMesa; below.


<sect1>Do I have to use &Glide;?
<p>
Yes. As of now, there is no other &VooDoo; driver available
for Linux. At the lowest level, &Glide; is the only interface
that talks directly to the hardware. However, you
can write &OGL; code without knowing anything about &Glide;,
and use &Mesa; with the &Glide; based &VooMesa; driver.
It helps to be aware of the involvement of &Glide; for
recognizing driver limitations and bugs, though.
<!-- p>
For Win32 there is also OpenGVS, a cross platform high level
graphics API (located somewhere between the level of 
&OGL; and IRIS Performer or OpenInventor). Quantum 3D is the
sole distributor of OpenGVS, contact is
John Archdeacon
<htmlurl
 url="mailto:John Archdeacon <jarch@gemtech.com>"
 name="jarch@gemtech.com">  -->


<sect1>Should I program using the Glide API?
<p>
That depends on the application you are heading for.
&Glide; is a proprietary API that is partly similar
to &OGL; or &Mesa;, partly contains features 
only available as EXTensions to some &OGL;
implementations, and partly contains features not
available anywhere but within &Glide;.
<p>
If you want to use the &OGL; API, you will need
&Mesa; (see below).
&Mesa;, namely the &VooMesa; driver, offers an
API resembling the well documented and widely
used OpenGL API. However, the &VooMesa; driver
is in early alpha, and you will have to accept
performance losses and lack of support for some
features.
<p>
In summary, the decision is up to you - if you
are heading for maximum performance while
accepting potential problems with porting to
non-&c3Dfx; hardware, &Glide; is not a bad
choice. If you care about maintenance, &OGL;
might be the best bet in the long run.


<sect1>What is the &Glide; current version?
<p>
The current version of Linux &Glide; is &GlVer;.
The next version will probably be identical to
the current version for DOS/Windows, which is 2.4.3,
which comes in two distributions. Right now, various
parts of &Glide; are different for &VooRush; (VR)
and &VooDoo; (VG) boards. Thus you have to pick up
separate distributions (under Windows) for VR and VG.
The same will be true for Linux. There will possibly
be another chunk of code and another distribution for 
&VooD2; (V2) boards.
<p>
There is also a &Glide; 3.0 in preparation that
will extend the API for use of triangle fans
and triangle strips, and provide better state
change optimization. Support for fans and strips
will in some situations significantly reduce the
amount of data sent ber triangle, and the
&Mesa; driver will benefit from this, as
the &OGL; API has separate modes for this. For
a detailed explanation on this see e.g. the
&OGL; documentation.


<sect1>Does it support multiple &Texelfx; already?
<p>
Multiple &Texelfx;/TMU's can be used for single pass
trilinear mipmapping for improvement image
quality without performance penalty in current
Linux &Glide; already. You will need a board
with two &Texelfx; (that is, one of the appropriate
Quantum3D Obsidian boards). The application needs
to specify the use of both &Texelfx; accordingly,
it does not happen automatically.
<p>
Note that because most applications are implemented for
consumer boards with a single &Texelfx;, they might not
query the presence of a second &Texelfx;, and thus not
use it. This is not a flaw of &Glide; but of the
application.



<sect1>Is Linux &Glide; identical to DOS/Windows &Glide;?
<p>
The publicly available version of Linux &Glide; should
be identical to the respective DOS/Windows versions.
Delays in releasing the Linux port of newer DOS/Windows
releases are possible.

<sect1>Where to I get information on &Glide;?
<p>
There is exhaustive information available from
&c3Dfx;. You could download it from their home
page at
<htmlurl
 url="http://www.3dfx.com/software/download_glide.html"
 name="www.3dfx.com/software/download&lowbar;glide.html">.
These are for free, presuming you bought a &c3Dfx;
hardware based board. Please read the licensing regulations.
<p>
Basically, you should look for some of the following:
<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>
These are available as Microsoft Word documents, and
part of the Windows Glide distribution, i.e. 
the self-extracting archive file. Postscript copies
for separate download should be available at
<htmlurl
url="http://www.3dfx.com/software/download_glide.html"
name="www.3dfx.com"> as well. Note that the release
numbers are not always in sync with those of &Glide;.


<sect1>Where to get some &Glide; demos?
<p>
You will find demo sources for &Glide; within the
distribution (test programs), and on the &c3Dfx; home
page. The problem with the latter is that some require
ATB. To port these demos to Linux, the event handling
has to be completely rewritten.
<p>
In addition, you might find useful some of the &OGL;
demo sources accompanying Mesa and GLUT. While
the &Glide; API is different from the &OGL; API,
they target the same hardware rendering pipeline.


<sect1>What is ATB?
<p>
Some of the &c3Dfx; demo programs for &Glide; depend
not only on &Glide; but also on &c3Dfx;'s proprietary Arcade
Toolbox (ATB), which is available for DOS and Win32,
but has not been ported for Linux. If you are a devleoper,
the sources are available within the Total Immersion
program, so porting ATB to Linux would be possible.
<p>

<sect>FAQ: &Glide; and XFree86?
<p>
<sect1>Does it run with XFree86?
<p>
Basically, the &VooDoo; hardware does not care about X. The
X server will not even notice that the video signal generated
by the VGA hardware does not reach the display in single screen
configurations. If your application is not written X aware,
&Glide; switching to full screen mode might cause problems
(see troubleshooting section). If you do not want the overhead
of writing an X11-aware application, you might want to use
SVGA console mode instead.
<p>
So yes, it does run with XFree86, but no, it is not cooperating
if you don't write your application accordingly. You can use
the &Mesa; "window hack", which will be significantly slower
than fullscreen, but still a lot faster than software rendering
(see section below).


<sect1>Does it only run full screen?
<p>
See above. The &VooDoo; hardware is not window environment
aware, neither is Linux &Glide;. Again, the experimental
&Mesa; "window hack" covered below will allow for pasting
the &VooDoo; board framebuffer's content into an X11 window.


<sect1>What is the problem with AT3D/&VooRush; boards?
<p>
There is an inherent problem when using
&VooRush; boards with Linux: Basically, these
boards are meant to be VGA 2D/3D accelerator
boards, either as a single board solution,
or with a &VooRush; based daughterboard used
transparently. The VGA component tied to the
&VooRush; is a Alliance Semiconductor's
ProMotion-AT3D multimedia accelerator.
To use this e.g. with XFree86 at all, you need
a driver for the AT3D chipset.
<p>
There is a mailing list on this, and a web site
with FAQ at 
<htmlurl
 url="http://www.frozenwave.com/linux-stingray128"
 name="www.frozenwave.com/linux-stingray128">.
Look there for most current info.
There is a SuSE maintained driver at
<htmlurl
 url="ftp://ftp.suse.com/suse_update/special/xat3d.tgz"
 name="ftp.suse.com/suse_update/special/xat3d.tgz">.
Reportedly, the XFree86 SVGA server also
works, supporting 8, 16 and 32 bpp. 
Official support will probably be in XFree86 4.0.
XFree86 decided to prepare an intermediate XFree86 3.3.2
release as well, which might already address the issues.
<p>
The
following <tt>XF86Config</tt> settings reportedly work.
<code>
# device section settings
Chipset "AT24"
Videoram 4032

# videomodes tested by 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>
In summary, there is nothing prohibiting this except
for the fact that the drivers in XFree86 are not yet
finished.
<p>
If you want a more technical explanation: &VooRush; support 
requires X server changes to support grabbing a buffer
area in the video memory on the AT3D board, as the &VooRush;
based boards need to store their back buffer and z buffer
there. This  memory allocation and locking requirement is not
a &c3Dfx; specific problem, it is also needed e.g. for 
support of TV capture cards, and is thus under active
development for XFree86. This means changes at the
device dependend X level (thus XAA), which are currently
implemented as an extension to XFree86 DGA (Direct Graphics
Access, an X11 extension proposal implemented in different ways
by Sun and XFree86, that is not part of the final X11R6.1
standard and thus not portable). It might be part of an
XFree86 GLX implementation later on. The currently distributed
X servers assume they have full control of the framebuffer,
and use anything that is not used by the visual region of the
framebuffer as pixmap cache, e.g. for caching fonts.


<sect1>What about GLX for XFree86?
<p>
There are a couple of problems.
<p>
The currently supported &VooDoo; hardware and the available
revision of Linux &Glide; are full screen only, and not set up
to share a framebuffer with a window environment. Thus GLX
or other integration with X11 is not yet possible.
<p>
The &VooRush; might be capable of cooperating with XFree86
(that is, an SVGA compliant board will work with the
XFree86 SVGA server),
but it is not yet supported by Linux &Glide;, nor do
S3 or other XFree86 servers support these boards yet.  
<p>
In addition, GLX is tied to &OGL; or, in the Linux case, to &Mesa;.
The XFree86 team is currently working on integrating Mesa with
their X Server. GLX is in beta, XFree86 3.3 has the hooks for GLX.
See Steve Parker's GLX pages at
<htmlurl
 url="http://www.cs.utah.edu/~sparker/xfree86-3d/"
 name="www.cs.utah.edu/~sparker/xfree86-3d/">
for the most recent information.
Moreover, there is a joint effort by XFree86 and
SuSe, which includes a GLX, see 
<htmlurl
 url="http://www.suse.de/~sim/"
 name="www.suse.de/~sim/">.
Currently, &Mesa; still uses its GLX emulation with Linux.


<sect1>&Glide; and commerical X Servers?
<p>
I have not received any mail regarding use
of &Glide; and/or Mesa with commercial X Servers.
I would be interested to get confirmation on this,
especially on Mesa and &Glide; with a commercial
X Server that has GLX support.


<sect1>&Glide; and SVGA?
<p>
You should have no problems running &Glide; based applications
either single or dual screen using VGA modes. It might be a good
idea to set up the 640x480 resolution in the SVGA modes, too,
if you are using a single screen setup.

<sect1>&Glide and GGI?
<p>
A GGI driver for &Glide; is under development by Jon
M. Taylor, but has not officially been released and was put
on hold till completion of GGI 0.0.9. For information about
GGI see
<htmlurl
 url="http://synergy.caltech.edu/~ggi/"
 name="synergy.caltech.edu/~ggi/">.
If you are adventurous,
you might find the combination of XGGI (a GGI based
X Server for XFree86) and GGI for &Glide; an interesting
prospect. There is also a GGI driver interfacing the
&OGL; API; tested with unaccelerated Mesa. Essentially,
this means X11R6 running on a &VooDoo;, using
either Mesa or &Glide; directly.



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

<sect1>What is &OGL;?
<p>
&OGL; is an immediate mode graphics programming API
originally developed by SGI based on their previous
proprietary Iris GL, and became in industry standard
several years ago. It is defined and maintained by
the Architectural Revision Board (ARB), an organization
that includes members as SGI, IBM, and DEC, and Microsoft.
<p>
&OGL; provides a complete feature set for 2D and
3D graphics operations in a pipelined hardware
accelerated architecture for triangle and polygon
rendering. In a broader sense, &OGL; is a powerful
and generic toolset for hardware assisted computer
graphics. 


<sect1>Where to get additional information on OpenGL?
<p>
The official site for &OGL; maintained by the members
of the ARB, is
<htmlurl
 url="http://www.opengl.org/"
 name="www.opengl.org">,
<p>
A most recommended site is Mark Kilgard's Gateway to &OGL;
Info at
<htmlurl
 url="http://reality.sgi.com/mjk_asd/opengl-links.html"
 name="reality.sgi.com/mjk&lowbar;asd/opengl-links.html">:
it provides pointers to book, online manual pages, GLUT,
GLE, Mesa, ports to several OS, tons of demos and tools.
<p>
If you are interested in game programming using &OGL;,
there is the <tt>OpenGL-GameDev-L@fatcity.com</tt> at
<tt>Listserv@fatcity.com</tt>. Be warned, this is
a high traffic list with very technical content, and
you will probably prefer to use <tt>procmail</tt> to
handle the 100 messages per day coming in. You cut
down bandwidth using the
 <tt>SET OpenGL-GameDev-L DIGEST</tt>
command. It is also
not appropriate if you are looking for introductions.
The archive is handled by the ListServ software, use
the
  <tt>INDEX OpenGL-GameDev-L</tt>
and
   <tt>GET OpenGL-GameDev-L "filename"</tt>
commands to get a preview before subscribing.



<sect1>Is Glide an &OGL; implementation?
<p>
No, &Glide; is a proprietary &c3Dfx; API which several features
specific to the &VooDoo; and &VooRush;. A &c3Dfx; OpenGL is
in preparation (see below). Several Glide features would require
EXTensions to OpenGL, some of which already found in other
implementations (e.g. paletted textures).
<p>
The closest thing to a hardware accelerated Linux &OGL;
you could currently get is Brian Paul's &Mesa;
along with David Bucciarelli's &VooMesa; driver (see below). 


<sect1>Is there an &OGL; driver from &c3Dfx;?
<p>
Both the &c3Dfx; website and the Quantum3D website
announced &OGL; for &VooDoo; to be available 4Q97.
The driver is currently in Beta, and accessible only
to registered deverloper's under written Beta test
agreement.
<p>
A linux port has not been announced yet.


<sect1>Is there a commercial &OGL; for Linux and &c3Dfx;?
<p>
I am not aware of any third party commercial OpenGL
that supports the &VooDoo;. Last time I paid attention,
neither MetroX nor XInside OpenGL did. 


<sect1>What is Mesa?
<p>
Mesa is a free implementation of the &OGL; API, designed
and written by Brian Paul, with contributions from many
others. Its performance is competitive, and while it
is not officially certified, it is an almost fully
compliant &OGL; implementation conforming to the ARB
specifications - more complete than some commercial
products out, actually.


<sect1>Does Mesa work with &c3Dfx;?
<p>
The latest &Mesa; MesaVer; release works with
Linux &Glide; &GlVer;. In fact, support was included
in earlier versions, however, this driver is still under
development, so be prepared for bugs and less than optimal
performance. It is steadily improving, though, and bugs
are usually fixed very fast.
<p>
You will need to get the Mesa library archive
from the
<htmlurl
 url="ftp://iris.ssec.wisc.edu/"
 name="iris.ssec.wisc.edu FTP site">.
It is recommended to subscribe to the mailing list
as well, especially when trying to track down bugs,
hardware, or driver limitations. Make sure to get
the most recent distribution. A Mesa-3.0 is in
preparation.


<sect1>How portable is &Mesa; with &Glide;?
<p>
It is available for Linux and Win32, and any application
based on Mesa will only have the usual system specific
code, which should usually mean XWindows vs. Windows,
or GLX vs. WGL. If you use e.g. GLUT or Qt, you should
get away with any system specifics at all for virtually
most
applications. There are only a few issues (like sampling
relative mouse movement) that are not adressed by the
available portable GUI toolkits.
<p>
&Mesa;/&Glide; is also available for DOS. The port
which is 32bit DOS is maintained by Charlie Wallace
and kept up to date with the main Mesa base. See
<htmlurl
 url="http://www.geocities.com/~charlie_x/"
 name="www.geocities.com/~charlie_x/">.for the 
most current releases.


<sect1>Where to get info on &Mesa;?
<p>
The &Mesa; home page is at
<htmlurl
 url="http://www.ssec.wisc.edu/~brianp/Mesa.html"
 name="www.ssec.wisc.edu/~brianp/Mesa.html">.
There is an archive of the Mesa mailing list. 
at 
<htmlurl
 url="http://www.iqm.unicamp.br/mesa/"
 name="www.iqm.unicamp.br/mesa/">. This list is
not specific to &c3Dfx; and &Glide;, but if
you are interested in using &c3Dfx; hardware
to accelerate &Mesa;, it is a good place to
start.

<sect1>Where to get information on &VooMesa;?
<p>
For latest information on the &VooMesa; driver
maintained by David Bucciarelli
<htmlurl 
 url="mailto:tech.hmw@plus.it"
 name="tech.hmw@plus.it">
see the home page at
<htmlurl
 url="http://www-hmw.caribel.pisa.it/fxmesa/index.shtml"
 name="www-hmw.caribel.pisa.it/fxmesa/">.



<sect1>Does Mesa support multitexturing?
<p>
Not yet (as of &Mesa; &MesaVer;), but it is on the list.
In &Mesa; you will probably have to use the &OGL;
<tt>EXT_multitexture</tt> extension once it is
available. There is no final specification for
multitextures in &OGL;, which is supposed to be
part of the upcoming &OGL; 1.2 revision. There might
be a &Glide; driver specific implementation of
the extension in upcoming Mesa releases, but as
long as only certain Quantum3D Obsidian boards come
with multiple TMU's, it is not a top priority. This
will surely change once &VooD2; based boards are in
widespread use.




<sect1>Does Mesa support single pass trilinear mipmapping?
<p>
Multiple TMU's should be used for single pass
trilinear mipmapping for improvement image
quality without performance penalty in current
Linux &Glide; already. Mesa support is not
yet done (as of &Mesa; &MesaVer;), but is in
preparation.



<sect1>What is the Mesa "Window Hack"?
<p>
The most recent revisions of Mesa contain an experimental
feature for Linux XFree86. Basically, the GLX emulation
used by Mesa copies the contents of the &VooDoo; board's
most recently finished framebuffer content into video
memory on each <tt>glXSwapBuffers</tt> call. This feature
is also available with Mesa for Windows.
<p>
This obviously puts some drain on the PCI, doubled by
the fact that this uses X11 MIT SHM, not XFree86 DGA
to access the video memory. The same approach could
theoretically be used with e.g. SVGA. The major benefit
is that you could use a &VooDoo; board for accelerated
rendering into a window, and that you don't have to
use the VGA passthrough mode (video output
of the VGA board deteoriates in passing through,
which is very visible with high end monitors like 
e.g. EIZO F784-T).
<p>
Note that this experimental feature is <em>NOT</em>
&VooRush; support by any means. It applies only
to the &VooDoo; based boards. Moreover, you need to
use a modified GLUT, as interfacing the window
management system and handling the events appropriately
has to be done by the application, it is not handled
in the driver.
<p>
Make really sure that you have enabled the 
following environment variables:
<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>
If you manage to forget one of the SST variables, your
VGA board will be shut off, and you will loose the
display (but not the actual X). It is pretty hard to
get that back being effectively blind.
<p>
Finally, note that the libMesaGL.a (or .so) library can contain
multiple client interfaces.  I.e. the GLX, OSMesa, and fxMesa
(and even SVGAMesa) interfaces call all be compiled into the
same libMesaGL.a. The client program can use any of them freely,
even simultaneously if it's careful.




<sect1>How about GLUT?
<p>
Mark Kilgard's GLUT distribution is a very good place to
get sample applications plus a lot of useful utilities.
You will find it at
<htmlurl
 url="http://reality.sgi.com/mjk_asd/glut3/glut3.html"
 name="reality.sgi.com/mjk_asd/glut3/">,
and you should get it anyway. The current release is
GLUT 3.6, and discussion on a GLUT 3.7 (aka GameGLUT)
has begun. Note that Mark Kilgard has left SGI recently,
so the archive might move some time this year - for the
time being it will be kept at SGI.
<p>
There is also a GLUT mailing list,
<tt>glut@perp.com</tt>. Send mail to 
<htmlurl
 url="mailto:Majordomo@perp.com"
 name="majordomo@perp.com">,
with the (on of the) following
in the body of your email message:
<code>
   help
   info glut
   subscribe glut
   end
</code>
<p>
As GLUT handles double buffers, windows, events,
and other operations closely tied to hardware and operating
system, using GLUT with &VooDoo; requires support, which
is currently in development within GLX for Mesa. It 
already works for most cases.


<sect>FAQ: But Quake?

<sect1>What about that &c3Dfx; GL driver for Quake?
<p>
The &c3Dfx; Quake GL, aka mini-driver, aka miniport, 
aka Game GL, aka &c3Dfx; GL alpha, implemented only a
Quake-specific subset of OpenGL (see
<htmlurl
url="http://www.cs.unc.edu/~martin/3dfx.html"
name="http://www.cs.unc.edu/~martin/3dfx.html"> for
an inofficial list of supported code paths). It is
not supported, and not updated anymore.
It was a Win32 DLL (<tt>opengl32.dll</tt>) released
by &c3Dfx; and was available for Windows only. This
DLL is not, and will not be ported to Linux.

<sect1>Is there a &c3Dfx; based glQuake for Linux?
<p>
Yes. A Quake linuxquake v0.97 binary has been released
based on Mesa with Glide. The Quake2 q2test binary
for Linux and &VooDoo; has been made available as well.
A full Quake2 for Linux was released in January 1998,
with linuxquake2-3.10. Dave "Zoid" Kirsch is the
official maintainer of all Linux ports of Quake,
Quakeworld, and Quake2, including all the recent
&Mesa; based ports. Note that all Linux ports, including
the &Mesa; based ones, are not officially supported by
id Software.
<p>
See
<htmlurl
url="ftp://ftp.idsoftware.com/idstuff/quake/unix/"
name="ftp.idsoftware.com/idstuff/quake/unix/"> for
the latest releases. 

<sect1>Does glQuake run in an XFree86 window?
<p>
A revision of &Mesa; and the &Mesa;-based Linux glQuake
is in preparation. &Mesa; already does support this
by GLX, but Linux glQuake does not use GLX.


<sect1>Known Linux Quake problems?
<p>
Here is an excerpt, as of January 7th, 1998. I omitted
most stuff not specific to &3Dfx; hardware.
<itemize>
<item>
 You really should run Quake2 as root when using the SVGALib and/or GL
 renders. You don't have to run as root for the X11 refresh, but the modes
 on the mouse and sound devices must be read/writable by whatever user you
 run it as. Dedicated server requires no special permissions.
<item>
 X11 has some garbage on the screen when 'loading'. This is normal in 16bit
 color mode. X11 doesn't work in 24bit (TrueColor). It would be very slow
 in any case.
<item>
 Some people are experiencing crashes with the GL renderer. Make sure you
 install the libMesa that comes with Quake2! Older versions of libMesa don't
 work properly.
<item>
 If you are experience video 'lag' in the GL renderer (the frame rate feels
 like it's lagging behind your mouse movement) type "gl_finish 1" in the
 console. This forces update on a per frame basis.
<item>
 When running the GL renderer, make sure you have killed selection and/or
 gpm or the mouse won't work as they won't "release" it while Quake2 is 
 running in GL mode.
</itemize>

<sect1>Know Linux Quake security problems?
<p>
As Dave Kirsch posted on January 28th, 1998: an exploit
for Quake2 under Linux has been published. Quake2 is using
shared libraries. While the READMRE so far does not
specifically mention it, note that Quake2 should not be 
<tt>setuid</tt>.
<p>
If you want to use the <tt>ref_soft</tt> and <tt>ref_gl</tt>
renderers, you should run Quake2  as root. Do not make the
binary setuid. You can only run both those renderers at
the console only, so being root is not that much of an issue.
<p>
The X11 render does not need any root permissions
(if <tt>/dev/dsp</tt> is writable by others for sound).
The dedicated server mode does not need to be root either,
obviously.
<p>
Problems such as root requirements for games has been sort
of a sore spot in Linux for a number of years now. This is
one of the goals that e.g. GGI is targetting to fix. 
A <tt>ref_ggi</tt> might be supported in the near future.

<sect1>Does LinuxQuake use multitexturing?
<p>
To my understadnding, glQuake will use a multitexture
EXTension if the &OGL; driver in question offers it.
The current Mesa implementation and the &Glide; driver
for Linux do not yet support this extension, so for the
time being the answer is no. See section on Mesa and
multitexturing for details.


<sect1>Where can I get current information on Linux glQuake?
<p>
Try some of these sites: the "The Linux Quake Resource" at 
<htmlurl
url="http://linuxquake.telefragged.com/"
name="linuxquake.telefragged.com">, or
the "Linux Quake Page" at
<htmlurl
url="http://www.planetquake.com/threewave/linux/"
name="www.planetquake.com/threewave/linux/">.
Alternatively, you could look for Linux Quake sites
in the "SlipgateCentral" database at 
<htmlurl
url="http://www.slipgatecentral.com/"
name="www.slipgatecentral.com">.



<sect>FAQ: Troubleshooting?

<sect1>Has this hardware been tested?
<p>
See hardware requirements list above. I currently do not
maintain a conclusive list of vendors and boards, as no
particular board specific problems have been verified.
Currently, only &c3Dfx; and Quantum3D provide boards
for testing to the developers, so Quantum3D consumer
boards are a safe bet. Every other &VooDoo; based board
should work, too. I have reports regarding the
Orchid Righteous 3D, Guillemot Maxi 3D Gamer, and 
Diamond Monster 3D. 
<p>
If you are a board manufacturer who wants to make
sure his &VooDoo;, &VooRush; or &VooD2; boards work
with upcoming releases of Linux, Xfree86, Linux &Glide;
and/or Mesa, please contact me, and I will happily forward
your request to the persons maintaining the drivers in
question. If you are interested in support for Linux &Glide;
on other then the PC platfrom, e.g. DEC Alpha, please
contact the maintainer of Linux &Glide; Daryll Strauss, at
<htmlurl
 url="mailto:daryll@harlot.rb.ca.us"
 name="daryll@harlot.rb.ca.us">


<sect1>Failed to change I/O privilege?
<p>
You need to be root, or <tt>setuid</tt> your
application to run a &Glide; based application.
For DMA, the driver accesses <tt>/dev/mem</tt>,
which is not writeable for anybody but root,
with good reasons. See the README in the
&Glide; distribution for Linux.


<sect1>Does it work without root privilege?
<p>
There are compelling case where the setuid requirement is a
problem, obviously. There are currently solutions in
preparation, which require changes to the library internals
itself. 


<sect1>Displayed images looks awful (single screen)?
<p>
If you are using the analog pass through configuration,
the common SVGA or X11 display might look pretty bad.
You could try to get a better connector cable than
the one provided with the accelerator board (the
ones delivered with the Diamond Monster 3D are
reportedly worse then the one accompanying the
Orchid Righteous 3D), but up to a degree there will
inevitably be signal loss with an additional
transmission added.
<p>
If the 640x480 full screen image created by the
accelerator board does look awful, this might indicate
a real hardware problem. You will have to contact
the board manufacturer, not &c3Dfx; for details, as
the quality of the video signal has nothing to do
with the accelerator - the board manufacturer chooses
the RAMDAC, output drivers, and other components
responsible.


<sect1>The last frame is still there (single or dual screen)?
<p>
You terminated your application with Ctrl-C, or it
did not exit normally. The accelerator board will
dutifully provide the current content of the
framebuffer as a video signal unless told otherwise.


<sect1>Powersave kicks in (dual screen)?
<p>
When you application terminates in dual screen setups,
the accelerator board does not provide video output
any longer. Thus powersave kicks each time. To avoid
this, use
<code>
setenv SST_DUALSCREEN 1
</code>


<sect1>My machine seem to lock (X11, single screen)?
<p>
If you are running X when calling a &Glide;
application, you probably moved the mouse out
of the window, and the keyboard inputs do
not reach the application anymore.
<p>
If you application is supposed to run concurrently
with X11, it is recommend to expose a full screen
window, or use the <tt>XGrabPointer</tt> and 
<tt>XGrabServer</tt>
functions to redirect all inputs to the application
while the X server cannot access the display. Note
that grabbing all input with <tt>XGrabPointer</tt> and
<tt>XGrabServer</tt> does not qualify as well-behaved
application, and that your program might block the
entire system.
<p>
If you experience this problem without running X,
be sure that there is no hardware conflict (see below).

<sect1>My machine locks (single or dual screen)?
<p>
If the system definitely does not respond to any inputs
(you are running two displays and know about the loss
of focus), you might experience a more or less
subtle hardware conflict.
See installation troubleshooting section for details.
<p>
If there is no obvious address conflict, there might
still be other problems (below). If you are writing your
own code the most common reason for locking is that you
didn't snap your vertices. See the section on snapping
in the &Glide; documentation.

<sect1>My machine locks (used with S3 VGA board)?
<p>
It is possible you have a problem with memory
region overlap specific to S3. There is some
info and a patch to the so-called S3 problem
in the &c3Dfx; web site, but these apply to Windows
only. To my understanding, the cause of the problem
is that some S3 boards (older revisions of Diamond 
Stealth S3 968) reserve more memory space than
actually used, thus the &VooDoo; has to be mapped
to a different location. However, this has not
been reported as a problem with Linux, and might
be Windows-specific.


<sect1>No address conflict, but locks anyway?
<p>
If you happen to use a motherboard with non-standard
or incomplete PCI support, you could try to 
shuffle the boards a bit. I am running an ASUS
TP4XE that has that non-standard modified "Media Slot",
i.e. PCI slot4 with additional connector for
ASUS-manufactured SCSI/Sound combo boards,
and I experienced severe problems while running a
Diamond Monster 3D in that slot. The system operates
flawlessly since I put the board in one of the 
regular slots.


<sect1>Mesa runs, but does not access the board?
<p>
Be sure that you recompiled all the libraries (including
the toolkits the demo programs use - remember that
GLUT does not yet support &VooDoo;), and that you
removed the older libraries, run <tt>ldconfig</tt>,
and/or set your <tt>LD_LIBRARY_PATH</tt> properly.
&Mesa; supports several drivers in parallel (you could
use X11 SHM, off screen rendering, and &VooMesa; at
the same time), and you might have to create and
switch contexts explicitely (see <tt>MakeCurrent</tt>
function) if the &VooDoo; isn't chosen by default.


<sect1>Resetting dual board SLI?
<p>
If a Quantum 3D Obsidian board using in an SLI setup
exits abruptly (i.e., the application crashes, or is
aborted by user), the boards are left in an undefined
state.  With the dual-board set, you can run a 
program called <tt>resetsli</tt> to reset them. Until
you run the <tt>resetsli</tt> program, you will not
be able to re-initialize the Obsidian board.


<sect1>Resetting single board SLI?
<p>
The <tt>resetsli</tt> program mentioned above does not
yet work with a single board Obsidian SLI (e.g. the
Obsidian 100-4440SB). You will have to reboot your
system by reset in order to reset the board.


</article>




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