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 3Dfx and Quantum3D provide boards for testing to the developers, so Quantum3D consumer boards are a safe bet. Every other Voodoo Graphics (tm) based board should work, too. I have reports regarding the Orchid Righteous 3D, Guillemot Maxi 3D Gamer, and Diamond Monster 3D.
If you are a board manufacturer who wants to make sure his Voodoo Graphics (tm), Voodoo Rush (tm) or Voodoo 2 (tm) 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 daryll@harlot.rb.ca.us
You need to be root, or setuid your
application to run a Glide based application.
For DMA, the driver accesses /dev/mem,
which is not writeable for anybody but root,
with good reasons. See the README in the
Glide distribution for Linux.
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.
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.
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 3Dfx 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.
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.
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
setenv SST_DUALSCREEN 1
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.
If you application is supposed to run concurrently
with X11, it is recommend to expose a full screen
window, or use the XGrabPointer and
XGrabServer
functions to redirect all inputs to the application
while the X server cannot access the display. Note
that grabbing all input with XGrabPointer and
XGrabServer does not qualify as well-behaved
application, and that your program might block the
entire system.
If you experience this problem without running X, be sure that there is no hardware conflict (see below).
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.
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.
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 3Dfx 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 Graphics (tm) has to be mapped to a different location. However, this has not been reported as a problem with Linux, and might be Windows-specific.
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.
Be sure that you recompiled all the libraries (including
the toolkits the demo programs use - remember that
GLUT does not yet support Voodoo Graphics (tm)), and that you
removed the older libraries, run ldconfig,
and/or set your LD_LIBRARY_PATH properly.
Mesa supports several drivers in parallel (you could
use X11 SHM, off screen rendering, and Mesa Voodoo at
the same time), and you might have to create and
switch contexts explicitely (see MakeCurrent
function) if the Voodoo Graphics (tm) isn't chosen by default.
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 resetsli to reset them. Until
you run the resetsli program, you will not
be able to re-initialize the Obsidian board.
The resetsli 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.