diff --git a/LDP/howto/linuxdoc/3Dfx-HOWTO.sgml b/LDP/howto/linuxdoc/3Dfx-HOWTO.sgml deleted file mode 100644 index 3b68d77e..00000000 --- a/LDP/howto/linuxdoc/3Dfx-HOWTO.sgml +++ /dev/null @@ -1,2275 +0,0 @@ - - - - - - - - - - - - - - - - - - - - ] > - - - - - - - - -
- -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&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 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 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_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_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: --> -<!-- ================================================= -->