Chip 1998 September

home *** CD-ROM | disk | FTP | other *** search

/ Chip 1998 September / CHIP Eylül 1998.iso / Slackwar / docs / 3Dfx-HOWTO next >

Wrap

Text File | 1997-09-02 | 47.2 KB | 1,150 lines

The Linux 3Dfx HOWTO Bernd Kreimeier (bk@gamers.org) v1.03, 12 July 1997 This document describes 3Dfx graphics accelerator chip support for Linux. It lists the supported hardware, describes how to configure the drivers, and answers frequently asked questions. The intent is to bring new users up to speed more quickly and reduce the amount of traffic in the Usenet news groups and mailing lists. 1. Introduction This is the Linux 3Dfx HOWTO document. It is intended as a quick reference covering everything you need to know to install and configure 3Dfx support under Linux. Frequently asked questions regarding the 3Dfx support specifically, as well as questions about 3D graphics under Linux in general 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. 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. It is only applicable to boards based on 3Dfx technology, any other graphics accelerator hardware is beyond the scope of this document. 1.1. Acknowledgments Much of this information found in this document has been provided by the people involved in the Linux Glide port and the beta testing process. Daryll Strauss did the port, Paul J. Metzger modified the Mesa Voodoo driver (written by David Bucciarelli) for Linux, Brian Paul integrated it with his famous Mesa library. With respect to Voodoo Graphics (tm) accelerated Mesa, additional thanks has to go to Henri Fousse and Charlie Wallace. The folks at 3Dfx, notably Gary Sanders and Gary McTaggart, provided valuable input, as did Ross Q. Smith of Quantum3D. Thanks to the SGML-Tools package (formerly known as Linuxdoc-SGML), this HOWTO is available in several formats, all generated from a common source file. For information on SGML-Tools see its homepage at web.inter.NL.net/users/C.deGroot/sgmltools/. 3Dfx, the 3Dfx Interactive logo, Voodoo Graphics (tm), and Voodoo Rush (tm) are registered trademarks of 3Dfx Interactive, Inc. Glide, TexUS, Pixelfx and Texelfx are trademarks of 3Dfx Interactive, Inc. OpenGL 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. 1.2. Revision History Version 1.03 First version for public release. 1.3. New versions of this document You will find the most recent version of this document at www.gamers.org/dEngine/xf3D/. New versions of this document will be periodically posted to the comp.os.linux.answers newsgroup. They will also be uploaded to various anonymous ftp sites that archive such information including ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/. Hypertext versions of this and other Linux HOWTOs are available on many World-Wide-Web sites, including sunsite.unc.edu/mdw/mdw.html. Most Linux CD-ROM distributions include the HOWTOs, often under the /usr/doc/directory, and you can also buy printed copies from several vendors. If you make a translation of this document into another language, let me know and I'll include a reference to it here. 1.4. Feedback I rely on you, the reader, to make this HOWTO useful. If you have any suggestions, corrections, or comments, please send them to me ( bk@gamers.org), and I will try to incorporate them in the next revision. Please add HOWTO 3Dfx to the Subject-line of the mail, so procmail will dump it in the appropriate folder. Before sending bug reports or questions, please read all of the information in this HOWTO, and send detailed information about the problem. 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, Greg Hankins (gregh@sunsite.unc.edu), for more information. 1.5. Distribution Policy Copyright (C) 1997 Bernd Kreimeier. This HOWTO is free documentation; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This document is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details. You can obtain a copy of the GNU General Public License by writing to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. 2. Graphics Accelerator Technology 2.1. Basics This section gives a very 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 OpenGL in order to learn more. Basically, 3D computer graphics often requires a lot of calculations for each single pixel on the screen. This is especially true if the application has to render a polygon world for many frames of an interactive animation. Even with low resolutions like 320x200, this consumes more processing power than even the most powerful PC could deliver. To overcome that bottleneck, several companies have designed, manufactured and sold processors dedicated to operations needed for 3D computer graphics. So far, virtually none of the boards manufactured so far offered any Linux support. Fortunately, the manufacturer of the Voodoo Graphics (tm) and Voodoo Rush (tm) chipsets, 3Dfx, decided to support use of Voodoo Graphics (tm) based boards with Linux. The purpose of this document is to describe the support currently available. 2.2. Hardware configurations (add-on) 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 3Dfx boards based on the Voodoo Graphics (tm) belong to the former category. We will get into this again later. 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. 2.3. Performance limitations 2.3.1. Fill bound Hardware accelerated graphics is performance bound for several reasons. A typical bottleneck is fill rate: the total number of pixels that the hardware could possibly do under optimal conditions, within a given time interval - e.g. about 40 Mpixels/second. Given a 640x480 screen resolution and zero overdraw, the hardware won't do more than 130 frames/second. The amount of overdraw depends on the actual depth complexity of the scene (how many polygons would a ray through a pixel intersect) and the efficiency of the visible surface determination algorithm used by the application. Drawing each pixel twice means 65 frames/second, an overdraw of 2 (drawing each pixel thrice) gets you down to about 43 frames/second. 2.3.2. Missing refresh Next, you will probably render with double buffering, swapping back and front buffer as soon as the frame is completed. Here the refresh rate of the display comes into play: you will only switch buffers during refresh. If your application misses a 60Hz refresh on every single frame, your effective frame rate will drop to 30Hz (every second refresh). Missing two refreshes gets you down to 20Hz. 2.3.3. Primitive bound If the scene is not very detailed (only a few polygons, but those very large, with lots of overdraw), your application will probably be fill bound - it is possible to throw more primitives (lines, triangles, polygons) at the hardware, but the pixel pipeline can't go any faster anyway. However, if your application insists on rendering a lot of small triangles or polygons, you might end up primitive bound. Given a PCI bandwidth of 33MHz times 32bit, or 132 MB/sec, and a per-triangle dataset of 3 vertices (9 coordinates, 16bit each, plus 3 colors, 24bit each), and a frame rate of 20Hz, you will transfer about 240K triangles/frame - not counting texture data, disk access, and other operations. 2.4. Hardware accelerated features The rendering operations usually supported by usefull hardware accelerators are: ╖ Perspective correct texture mapping ╖ Alpha-blending, Fog ╖ Anti-aliasing ╖ Bi-linear and advanced texture filtering ╖ Level of detail (LOD) MIP mapping ╖ Sub-pixel correction ╖ Polygonal-based Gouraud shading and texture modulation ╖ Double buffering ╖ Depth buffering, stencil buffer Usually, hardware allows increased screen resolution (software-only rendering being limited to 320x200 pixels for interactive frame rates), advanced filtering, true alpha channel translucency, and use true color 16bpp or 24bpp frame buffers. 2.5. A bit of Voodoo Graphics (tm) architecture 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. The Voodoo Graphics (tm) 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). Moreover, a Voodoo Graphics (tm) could use two TMU's (texture management or texelfx units), and finally, two Voodoo Graphics (tm) could be combined accessing the same RAMDAC with a mechanism called Scan-Line Interleaving (SLI). SLI essentially means that each pixelfx unit effectively provides only every second scanline, which decreases bandwidth impact on each pixelfx' framebuffer memory. 3. Installation Configuring Linux to support 3Dfx accelerators involves the following steps: 1. Installing the board. 2. Installing the Glide distribution. 3. Compiling, linking and/or running the application. The next sections will cover each of these steps in detail. 3.1. Installing the board 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. As 3Dfx does not develop or sell any boards, do not contact them on any problems. 3.1.1. Troubleshooting the hardware installation To check the installation and the memory mapping, do cat /proc/pci. The output should contain something like ______________________________________________________________________ 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. ______________________________________________________________________ for a Diamond Monster 3D used with a Diamond Stealth-64. Additionally a cat /proc/cpuinfo /proc/meminfo might be helpfull for tracking down conflicts and/or submitting a bug report. With current kernels, you will probably get a boot warning like ______________________________________________________________________ Jun 12 12:31:52 hal kernel: Warning : Unknown PCI device (121a:1). Please read include/linux/pci.h ______________________________________________________________________ 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 /usr/include/linux/pci.h and send all neces¡ sary information to linux-pcisupport@cao-vlsi.ibp.fr. 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. 3.1.2. Configuring the kernel There is no kernel configuration necessary, as long as PCI support is enabled. The Linux Kernel HOWTO <http://sunsite.unc.edu/mdw/HOWTO/Kernel-HOWTO.html> should be consulted for the details of building a kernel. 3.1.3. Configuring devices The current drivers to not (yet) require any special devices. This is different from other driver developments (e.g. the sound drivers, where you will find a /dev/dsp and /dev/audio). The driver uses the /dev/mem device which should always be available. In consequence, you need to use setuid or root privileges to access the accelerator board. 3.2. Setting up the Displays 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. 3.2.1. Single screen display solution 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. 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. 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. 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. 3.2.2. Dual screen display solution 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. 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 ______________________________________________________________________ setenv SST_DUALSCREEN 1 ______________________________________________________________________ to force continued video output in this setup. 3.3. Installing the Glide distribution The Glide driver and library are provided as a single compressed archive. Use tar and gzip 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. 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 can't load library 'libglide.so'. 3.3.1. Using the detect program There is a bin/detect program in the distribution (the source is not available). You have to run it as root, and you will get something like ______________________________________________________________________ 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 ______________________________________________________________________ as a result. If you do not have root privileges, the program will bail out with ______________________________________________________________________ Permission denied: Failed to change I/O privilege. Are you root? ______________________________________________________________________ output might come handy for a bug report as well. 3.3.2. Using the test programs Within the Glide distribution, you will find a folder with test programs. Note that these test programs are under 3Dfx copyright, and are legally available for use only if you have purchased a board with a 3Dfx chipset. See the LICENSE file in the distribution, or their web site www.3dfx.com for details. 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 alpha.3df 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 Press A Key To Begin Test. Beware of loss of input scope if running X11 on the same screen at the same time. See the README.test for a list of programs, and other details. 4. Answers To Frequently Asked Questions 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 ╖ FAQ: Requirements? ╖ FAQ: Voodoo Graphics (tm)? 3Dfx? ╖ FAQ: Glide? ╖ FAQ: Glide and SVGA? ╖ FAQ: Glide and XFree86? ╖ FAQ: Glide versus OpenGL/Mesa? ╖ FAQ: But Quake? ╖ FAQ: Troubleshooting? Each section lists several questions and answers, which will hopefully address most problems. 5. FAQ: Requirements? 5.1. What are the system requirements? 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. 5.2. Does it work with Linux-Alpha? 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. 5.3. Which chipsets are supported? Currently, the most recent revision of the 3Dfx Voodoo Graphics (tm) chipset is supported under Linux. The Voodoo Rush (tm) chipset is not yet supported. 5.4. Which boards are supported? This section lists the boards that are currently known to work under Linux. There are no officially supported boards, as 3Dfx does not sell any boards. The information here is based on the latest Linux kernels, at time of writing, and lists the boards that have been tested, plus boards that might work, but have yet to be checked. 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. 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. The following configurations have been tested: ╖ Diamond Monster 3D with Diamond Stealth 64 3240XL ╖ Orchid Righteous 3D with S3-968 based graphics card ╖ Quantum3D Obsidian 50-4220 These are the existing Obsidian board configurations, most of them have not been tested yet, but should work as well. Obsidian 50-2200 1 pixelfx with 2MB frame buffer memory, 1 texelfx with 2MB texture memory Obsidian 50-2400 1 pixelfx with 2MB frame buffer memory, 1 texelfx with 4MB texture memory Obsidian 50-4400 1 pixelfx with 4MB frame buffer memory, 1 texelfx with 4MB texture memory Obsidian 50-2220 1 pixelfx with 2MB frame buffer memory, 2 texelfx chips with 2MB texture memory, each, for a total of 4MB texture memory Obsidian 50-4220 1 pixelfx with 4MB frame buffer memory, 2 texelfx chips with 2MB texture memory, each, for a total of 4MB texture memory. This configuration was the original "Obsidian Pro" which has been used for the 3DS Plug-in Project (now done with Datapath Realistorm). Datapath used to call this "Pro VR". Obsidian 50-4440 1 pixelfx with 4MB frame buffer memory, 2 texelfx chips with 4MB texture memory, each, for a total of 8MB texture memory. This configuration is now the intended target for the 3DS Plug-in Project (now done with Datapath Realistorm). Obsidian 50-2440 1 pixelfx with 2MB frame buffer memory, 2 texelfx chips with 4MB texture memory, each, for a total of 8MB texture memory. Obsidian 100-2440 aka 2440-SLI, aka XS-100, or just "SLI". Two PCI boards, each with 1 pixelfx with 2MB frame buffer memory and 2 texelfx chips each with 4MB texture memory, each, for a total of 8MB texture memory per board. Texture have to be stored on both boards, so this does not equal 16MB texture memory. Video output is scan line interleaved for two times the standard fill rate. The bundling deal with additional software for Autodesk 3DS MAX is dubbed Obsidian 3DS, which originally used a 50-4220 and now comes with a 50-4440 board. The following boards have not yet been tested: ╖ Deltron RealVision Flash 3D With the current Glide 2.4, the following Voodoo Rush (tm) based boards are not expected to work with Linux: ╖ Hercules Stingray 128/3D ╖ Intergraph Intense 3D Rush As the Voodoo Rush (tm) chipset supports operations within a window, it is meant for use on accelerated VGA boards, which in turn require XFree86 oder Linux SVGA support not yet available. 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. 5.5. Is the Hercules Stingray 128/3D supported? In this board, the 2D accelerator is mounted on a PCI card, and the Voodoo Rush (tm) chipset is mounted on a daughterboard. Currently, this board is neither supported by Linux Glide, nor by XFree86 accelerated servers. Reportedly, the XFree86 SVGA server works, according to a posting on the Mesa mailing list. It supports 8, 16 and 32 bpp. ______________________________________________________________________ # 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) ______________________________________________________________________ There is currently no Voodoo Rush (tm) support. It might be worth a try, but as no test boards have been provided by the manufacturers, you are in your own. Regarding the VGA component tied to the Voodoo Rush (tm) on this board, it is a Alliance Semiconductor's ProMotion-AT3D multimedia accelerator. XFree86's support for AT3D/AT24 will not be accelerated prior to XFree86 4.0, which is quite some time away. 5.6. Is the Intergraph Intense Rush supported? Despite the fact that this board will be a single board integrated solution, it is essentially the same chipset combo (AT3D, Voodoo Rush (tm)), thus all disclaimers made above regarding the Hercules Stringray apply here as well. According to David E. Anderson from Intergraph, they will not be providing support for Linux at this time. 6. FAQ: Voodoo Graphics (tm)? 3Dfx? 6.1. Who is 3Dfx? 3Dfx is a San Jose based manufacturer of 3D graphics accelerator hardware for arcade games, game consoles, and PC boards. Their official website is www.3dfx.com. 3Dfx does not sell any boards, but there is an associcated company, Quantum3D. See their home page at www.quantum3d.com for additional information. 6.2. What is the Voodoo Graphics (tm)? The Voodoo Graphics (tm) is a chipset manufactured by 3Dfx. It is used in hardware acceleration boards for the PC. See the HOWTO section on supported hardware. There is a newer chipset, the Voodoo Rush (tm), that is currently not supported with Linux. 6.3. Where could I get additional info on Voodoo Graphics (tm)? There is a FAQ by 3Dfx, which should be available at their web site. You will find retail information at the following locations: ╖ www.3dfx.com ╖ www.quantum3d.com ╖ www.orchid.com ╖ www.diamondmm.com ╖ www.deltrontech.com 7. FAQ: Glide? TexUS? 7.1. What is Glide anyway? Glide is a proprietary API plus drivers to access 3D graphics accelerator hardware based on chipsets manufactured by 3Dfx. Glide has been developed and implemented for DOS, Windows, and Macintosh, and has been ported to Linux by Daryll Strauss. 7.2. What is TexUS? In the distribution is a libtexus.so, which is the 3Dfx Interactive Texture Utility Software. It is an image processing libary and utility program for preparing images for use with the 3Dfx Interactive Glide library. Features of TexUS include file format conversion, MIPmap creation, and support for 3Dfx Interactive Narrow Channel Compression textures. The TexUS utility program texus reads images in several popular formats (TGA, PPM, RGT), generates MIPmaps, and writes the images as 3Dfx 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 texus, and the API, see the TexUS documentation. 7.3. Is Glide freeware? Nope. Glide is neither GPL'ed nor subject to any other public license. See LICENSE in the distribution for any details. 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 3Dfx. The same is true for all the sources in the Glide distribution. In the words of 3Dfx: These are not public domain, but they can be freely distributed to owners of 3Dfx products only. No card, No code! 7.4. Is the Glide source available? Nope. The Glide source is made available only based on a special agreement and NDA with 3Dfx. 7.5. Is Linux Glide supported? Currently, Linux Glide is unsupported. Basically, it is provided under the same disclaimers as the GLQuake DLL. However, 3Dfx 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 3Dfx newsgroup (see below). In addition, the Quantum3D web page claims that Linux support (for Obsidian) is planned for both Intel and AXP architecture systems in 2H97. 7.6. Where could I post Glide questions? There are newsgroups currently available only on the NNTP server news.3dfx.com run by 3Dfx. This USENET groups are dedicated to 3Dfx and Glide in general, and will mainly provide assistance for DOS, Win95, and NT. The current list is: ______________________________________________________________________ 3dfx.d3d.drivers 3dfx.events 3dfx.game.titles 3dfx.games.glquake 3dfx.glide 3dfx.glide.linux 3dfx.oem.products.diamond.monster3d 3dfx.oem.products.hercules.stingray128-3d 3dfx.oem.products.orchid.righteous3d 3dfx.oem.products.quantum3d.obsidian 3dfx.oem.products.realvision.flash3d 3dfx.products 3dfx.test ______________________________________________________________________ Please use news.3dfx.com/3dfx.glide.linux for all Lnux Glide related questions. A mailing list dedicated to Linux Glide is in preparation (ETA in late august). Send mail to majordomo@gamers.org, no subject, body of the message info linux-3dfx to get information about the posting guidelines, the hypermail archive and how to subscribe to the list or the digest when available. 7.7. Where to send bug reports? Currently, you should rely on the newsgroup (see above), that is 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. 7.8. Who is maintaining it? 3Dfx 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 daryll@harlot.rb.ca.us 7.9. How can I contribute to Linux Glide? 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 Mesa Voodoo driver source. See section on Mesa Voodoo below. 7.10. Do I have to use Glide? Yes. As of now, there is no other Voodoo Graphics (tm) driver available for Linux. 7.11. Should I program using the Glide API? That depends on the application you are heading for. Glide is a proprietary API that is partly similar to OpenGL or Mesa, partly contains features only available as EXTensions to some OpenGL implementations, and partly contains features not available anywhere but within Glide. If you want to use the OpenGL API, you will need Mesa (see below). Mesa, namely the Mesa Voodoo driver, offers an API resembling the well documented and widely used OpenGL API. However, the Mesa Voodoo driver is in early alpha, and you will have to accept performance losses and lack of support for some features. In summary, the decision is up to you - if you are heading for maximum performance while accepting potential problems with porting to non-3Dfx hardware, Glide is not a bad choice. If you care about maintenance, OpenGL might be the best bet in the long run. 7.12. What is the current version? The version of Linux Glide to be released to the public is 2.4, as is the next release of Glide for DOS/Windows. Note that this HOWTO has been written based on Linux Glide 2.3.1, as Glide 2.4 has not been released, and the Linux Glide 2.4 port as not been finished yet. As the API did not change, and as there are no changes planned for the Linux Glide distribution, this document should still address the most common problems. 7.13. Is Linux Glide identical to DOS/Windows Glide? The version of Linux Glide to be publicly released will be 2.4, following the release of DOS/Windows Glide 2.4. API and implementation are supposed to be identical. Glide 2.2 has been ported to Linux in April 1997. The port of Glide 2.3.1 has been done in June 1997. Both lacked a key optimization for triangle setup, which will be included in the public Linux Glide 2.4 release. The previous ports have never been publicly available, and have been used for beta tests only. 7.14. Where to I get information on Glide? There is exhaustive information available from 3Dfx. You could download it from their home page at www.3dfx.com/software/download_glide.html. These are for free, presuming you bought a 3Dfx hardware based board. Please read the licensing regulations. Basically, you should look for some of the following: ╖ Glide Release Notes ╖ Glide Programming Guide ╖ Glide Reference Manual ╖ Glide Porting Guide ╖ TexUs Texture Utility Software ╖ ATB Release Notes ╖ Installing and Using the Obsidian 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 www.3dfx.com as well. Note that the release numbers are not always in sync with those of Glide. 7.15. Where to get some Glide demos? You will find demo sources for Glide within the distribution (test programs), and on the 3Dfx 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. In addition, you might find useful some of the OpenGL demo sources accompanying Mesa and GLUT. While the Glide API is different from the OpenGL API, they target the same hardware rendering pipeline. 8. FAQ: Glide and SVGA? 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. 9. FAQ: Glide and XFree86? 9.1. Does it run with XFree86? Basically, the Voodoo Graphics (tm) 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. So yes, it does run with XFree86, but no, it is not cooperating if you don't write your application accordingly. 9.2. Does it only run full screen? See above. The Voodoo Graphics (tm) hardware is not window environment aware, neither is Linux Glide. 9.3. What about GLX for XFree86? There are a couple of problems. The currently supported Voodoo Graphics (tm) 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. The Voodoo Rush (tm) 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. In addition, GLX is tied to OpenGL 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 www.cs.utah.edu/~sparker/xfree86-3d/ for the most recent information. Currently, Mesa still uses its GLX emulation with Linux. 10. FAQ: Glide versus OpenGL/Mesa? 10.1. Is Glide OpenGL? No, Glide is a proprietary 3Dfx API which several features specific to the Voodoo Graphics (tm) and Voodoo Rush (tm). A 3Dfx 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). The closest thing to a hardware accelerated Linux OpenGL you could currently get is Brian Paul's Mesa along with David Bucciarelli's Mesa Voodoo driver (see below). 10.2. Does Mesa work with 3Dfx? As of Mesa 2.3 Beta3, Mesa works with Linux Glide 2.2, similar to Mesa with Glide for DOS/Windows. There are patches to Mesa 2.3b3 for Linux Glide 2.3.1. Later versions of Mesa will work with Linux Glide 2.4; as the API did not change, the patches to Mesa-2.3b3 might be sufficient. The Glide distribution is not part of the Mesa distribution. You will need to get the Mesa library archive from the iris.ssec.wisc.edu FTP site. 10.3. Where to get additional information on OpenGL? Use Mark Kilgard's Gateway to OpenGL Info at reality.sgi.com/mjk_asd/opengl-links.html, and proceed from there. 10.4. Where to get info on Mesa? The Mesa home page is at www.ssec.wisc.edu/~brianp/Mesa.html. There is an archive of the Mesa mailing list. at www.iqm.unicamp.br/mesa/. This list is not specific to 3Dfx and Glide, but if you are interested in using 3Dfx hardware to accelerate Mesa, it is a good place to start. 10.5. Where to get information on Mesa Voodoo? For latest information on the Mesa Voodoo driver maintained by David Bucciarelli tech.hmw@plus.it see the home page at www- hmw.caribel.pisa.it/fxmesa/. 10.6. Is there a commercial OpenGL for Linux and 3Dfx? 3Dfx has publicly announced an OpenGL implementation for Windows for this year (2H97). It is not known whether this will be available for Linux as well. As for third party commercial OpenGL, I am aware of three products: ╖ MetroLink MetroOpenGL ╖ XInside OpenGL ╖ Evans & Sutherland OpenGL The latter was distributed by Portable Graphics, and was a straight Linux port of the OpenGL reference software implementation, with a link kit for an older revision of the XFree86 X servers. Portable Graphics never promised hardware support. To my knowledge, this product is no longer available. The other two promised support for hardware accelerators, but both are tied to proprietary ports of the X server, and both do not support any 3D acceleration, as far as I know. 10.7. How about GLUT? 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 reality.sgi.com/mjk_asd/glut3/, and you should get it anyway. The current release is GLUT 3.4. However, as GLUT handles double buffers, windows, events, and other operations closely tied to hardware and operating system, a Voodoo- GLUT requires several specific modifications. There is an alpha release available as part of the most recent Mesa distribution (David Bucciarelli, Henri Fousse). 11. FAQ: But Quake? 11.1. What about the Quake GL? The DLL released by 3Dfx is only available for Windows. It supports a Quake-specific a subset of OpenGL only (see http://www.cs.unc.edu/~martin/3dfx.html for an inofficial list of supported code paths). No, this DLL is not ported to Linux. No, there is no Glide based Quake version, not even for Windows. I have no information about a Linux glQuake. 12. FAQ: Troubleshooting? 12.1. Has this hardware been tested? See hardware requirements above, there is a list of hardware that has been found to work. 12.2. Failed to change I/O privilege? 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. 12.3. Does it work without root privilege? 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. 12.4. Displayed images looks awful (single screen)? 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. 12.5. The last frame is still there (single or dual screen)? 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. 12.6. Powersave kicks in (dual screen)? 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 ______________________________________________________________________ 12.7. My machine seem to lock (X11, single screen)? 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). 12.8. My machine locks (single or dual screen)? 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. 12.9. My machine locks (used with S3 VGA board)? 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. 12.10. No address conflict, but locks anyway? 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. 12.11. Compile/link error: grSstWinOpen()? As Linux Glide will be version 2.4, this error should not occur. This function was not available in Glide and thus Linux Glide 2.2;; the latter has never been released to the public. 12.12. Compile/link error: grSstOpen()? Your application's source is based on Glide 2.2, and this function was removed in Glide 2.3;. It is not available anymore and so may not be used with Linux Glide 2.4. Modify your application to use the function grSstWinOpen instead. As the Linux Glide integration with Mesa was based on Glide 2.2 originally, earlier versions of Mesa might produce compile time errors. The Mesa-2.3b3 release has been patched to be used with Linux Glide 2.3.1; make sure to get both the distribution and the patches, or, preferably, a later revision of Mesa. 12.13. Cannot open shared object file? ______________________________________________________________________ test25: error in loading shared libraries libglide2x.so: cannot open shared object file: No such file or directory ______________________________________________________________________ If, for whatever reasons, you have a binary lying around compiled for a different revision of Linux Glide, or if there is an inconsistency in your ldconfig setup, the program will not find the shared library. Check the name (e.g. libglide2x.so) and make sure that the proper flags are used when compiling and linking - e.g. -lglide might not work with the default installation. Note that the naming of Linux Glide revisions follows the conventions used in the 3Dfx Windows distribution, not the conventions common for Linux. 12.14. Mesa compilation problems Be sure to set USE_GLIDE_FULLSCREEN in fxmesa.h. Check whether the linkage options (e.g. -lglide) match the name of the Linux Glide library installed (e.g. -lglide2x instead). Be sure to use the patches to Mesa-2.3b3 or a later release, as all Mesa releases up to 2.3b3 were based on Linux Glide 2.2. See above. 12.15. Mesa runs, but does not access the board? 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.