A Linux PC, PCI 2.1 compliant, a monitor capable of 640x480, and a 3D accelerator board based on the 3Dfx Voodoo Graphics (tm). 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.
At one point, some 3Dfx 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.
No IRQ or port is used. You should not experience any collisions or related problems whatsoever.
There is no MMX specific code in the Glide code base. MMX is really good for repeated identical operations (SIMD) which are not done in Glide, so this situation will probably not change in upcoming Glide revisions and thus Linux Glide ports.
There is no K6 or other CPU specific optimization in Glide.
There is currently a performance difference between Linux Glide and other Glide ports, which is mainly due to some issues regarding Memory Type Range Registers (MTRR) setting by BIOS, FX chipset bugs, and how the Linux kernel could possibly handle this. This is being worked upon.
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.
There is also the issue of porting the 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.
Currently, the 3Dfx Voodoo Graphics (tm) chipset is supported under Linux. The Voodoo Rush (tm) chipset is not yet supported. The Voodoo 2 (tm) chipset is also not yetr supported.
The current port of Glide to Linux does not support the Voodoo Rush (tm). An update is in the works.
The problem is that at one point the Voodoo Rush (tm) 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.
Thus Voodoo Rush (tm) based boards like the Hercules Stingray 128/3D or Intergraph Intense Rush are not supported yet.
The current port of Glide to Linux does not support the Voodoo 2 (tm).
The chip manufacturer, 3Dfx, is providing internal support for the maintenance of the Linux Glide port. Limited resources currently prohibit further support, or official support by 3Dfx personnel.
One board manufacturer, Quantum3D, has publicly announced Linux support for its Obsidian boards, and is in the process of porting proprietary software to Linux.
During the beta testing of the Glide for Voodoo Graphics (tm) port to Linux, Quantum3D, their european distributor, Datapath Ltd., and Micronics, distributor for Orchid, were willing to provide hardware on loan. Intergraph and Diamond explicitely declined to provide any assistance whatsoever, Hercules did not reply to an enquiry.
With respect to the current preparation of supporting Voodoo 2 (tm) based boards with Linux, despite several requests no OEM has yet committed to any assistance whatsoever. See acknowledgements of OEM support for details.
There are no officially supported boards, as 3Dfx 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.
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 Voodoo Rush (tm) 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.
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 Graphics (tm) based boards, like Orchid Righteous 3D, Canopus Pure 3D, Flash 3D, and Diamond Monster 3D. Voodoo Rush (tm) based boards are not yet supported.
Boards that are not based on 3Dfx chipsets (e.g. manufactured by S3, Matrox, 3Dlabs, Videologic) do not work with the 3Dfx drivers and are beyond the scope of this document.
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.
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 Graphics (tm) board is described below, in a separate section.
Quantum 3D offers the widest selection of 3Dfx-based boards, and is probably the place to go if you are looking for a high end Voodoo Graphics (tm) 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.
There is no Voodoo Graphics (tm) or Voodoo Rush (tm) 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 3Dfx technology might possibly be supported with Linux.
The Voodoo 2 (tm) chipset is AGP aware, but is basically using AGP as a fast PCI bus, and to my knowledge not using any AGP specific features (e.g. the chipset does not use the "DIME" memory management scheme). As for performance improvements, you will get a the dedicated bus and the increased bus speed.
kernel will supposedly recognize a Voodoo 2 (tm) based AGP
board like being on a second PCI bus, like this
is already the case e.g. with
a RIVA-128 AGP (sniplett from
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.
You will have to find out yourself. Get your requirements straight (fullscreen or window, games or OpenGL, application or development, fill rate, texture memory, expected lifetime, scalability by SLI). Ignore Winbench. Take a good look at the technical specs.
If you are ultimately facing the decision between two or more technically acceptable boards, I also suggest looking at the acknowledgements of OEM support in this document. You might want to prefer a vendor that was willing to provide some assistance. If in doubt, submit an enquiry to the companies in question and ask for their position on Linux use specifically.