-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. -
From 8f62fb064b6804c664e68ba4c64b435b97fc3e29 Mon Sep 17 00:00:00 2001
From: gferg <>
Date: Thu, 29 Dec 2005 18:03:49 +0000
Subject: [PATCH] hsuecleaning
---
LDP/howto/linuxdoc/3Dfx-HOWTO.sgml | 2275 ----------------------------
1 file changed, 2275 deletions(-)
delete mode 100644 LDP/howto/linuxdoc/3Dfx-HOWTO.sgml
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 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- ] >
-
-
-
-
-
-
-
-
-
-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.
-
-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. -
-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.
-
-
-
-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.
-
-Daryll Strauss
-
-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
-
-&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.
-
-
-
-The verbose revision history below is for internal use only,
-to provide assistance during the review/copy editing process.
-
-
-You will find the most recent version of this document at
-
-New versions of this document will be periodically posted to the
-
-Hypertext versions of this and other Linux HOWTOs are available on
-many World-Wide-Web sites, including
-
-If you make a translation of this document into another language, let
-me know and I'll include a reference to it here.
-
-
-
-I rely on you, the reader, to make this HOWTO useful. If you have any
-suggestions, corrections, or comments, please send them to me (
-
-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, Tim Bynum
-(
-Copyright (c) 1997, 1998 by Bernd Kreimeier.
-This document may be
- distributed under the terms set forth in the LDP license
- at
-
-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
-
-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 &OGL; in order to learn more.
-
-
-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.
-
-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.
-
-
-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; 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; 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.
-
-
-
-Configuring Linux to support &c3Dfx; accelerators involves the
-following steps:
-
-
-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 &c3Dfx; does not develop or sell any boards, do not contact
-them on any problems.
-
-
-To check the installation and the memory mapping, do
-cat /proc/pci. The output should contain something like
-
-With current kernels, you will probably get a boot warning
-like
-
-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.
-
-
-There is no kernel configuration necessary, as long as PCI
-support is enabled.
-The
-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 /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.
-
-
-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.
-
-
-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.
-
-
-
-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.
-
-
-
-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
-
-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'.
-
-
-
-
-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
-
-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
-
-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.
-
-
-
-
-
-
-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
-
-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.
-
-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.
-
-
-There is currently no Linux &Glide; distribution available
-for any platform besides i586. As the &Glide; sources are
-not available for distribution, you will have to
-wait for the binary. Quantum3D has DEC Alpha support
-announced for 2H97. Please contact Daryll Strauss
-if you are interested in supporting this.
-
-There is also the issue of porting the the assembly
-modules. While there are alternative C paths in the
-code, the assembly module in &Glide; (essentially
-triangle setup) offered significant performance gains
-depending on the P5 CPU used.
-
-
-
-Currently, the &c3Dfx; &VooDoo; chipset is supported
-under Linux. The &VooRush; chipset is not yet supported.
-
-
-The current port of &Glide; to Linux does not support
-the &VooRush;. An update is in the works.
-
-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.
-
-Thus &VooRush; based boards like the
-Hercules Stingray 128/3D
-or Intergraph Intense Rush are not supported
-yet.
-
-
-
-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.
-
-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.
-
-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.
-
-Boards that are not based on &c3Dfx; chipsets (e.g. manufactured
-by S3, Matrox, 3Dlabs, Videologic) do not work with the &c3Dfx;
-drivers and are beyond the scope of this document.
-
-
-
-
-As the board manufacturers are using the same chipset,
-any differences are due to board design. Examples are
-quality of the pass-through cable and connectors
-(reportedly, Orchid provided better quality than
-Diamond), availability of a TV-compliant video
-signal output (Canopus Pure 3D), and, most notably,
-memory size on board.
-
-Most common were boards for games
-with 2MB texture cache and 2 MB framebuffer memory,
-however, the Canopus Pure3D comes with a maximal
-4 MB texture cache, which is an advantage e.g.
-with games using dynamically changed textures,
-and/or illumation textures (Quake, most notably).
-The memory architecture of a typical &VooDoo;
-board is described below, in a separate section.
-
-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.
-
-
-
-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.
-
-
-
-
-&c3Dfx is a San Jose based manufacturer of 3D graphics
-accelerator hardware for arcade games, game consoles,
-and PC boards.
-Their official website is
-
-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
-
-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.
-
-
-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.
-
-
-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.
-
-The &VooD2; is supposed to be backwards compatible.
-However, a new version of &Glide; will have to be
-ported to Linux.
-
-
-
-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.
-
-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.
-
-
-&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.
-
-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.
-
-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.
-
-
-
-&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.
-
-
-
-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.
-
-The &Pixelfx; in question can be on the same board,
-or on two boards properly connected. Some Quantum3D
-Obsidian boards support SLI with &VooDoo;.
-
-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.
-
-
-
-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.
-
-
-
-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.
-
-So there.
-
-
-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.
-
-
-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.
-
-
-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.
-
-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.
-
-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.
-
-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.
-
-
-
-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.
-
-
-The &VooDoo; hardware and &Glide; support the palette
-extension to &OGL;. The most recent version of
-&Mesa; does support the
-GL_EXT_paletted_texture
-and
-GL_EXT_shared_texture_palette extensions.
-
-
-
-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.
-
-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.
-
-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.
-
-
-
-There is a FAQ by &c3Dfx;, which should be available
-at their
-
-Inofficial sites that have good info
-are "Voodoo Extreme" at
-
-&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.
-
-
-In the distribution is a libtexus.so, 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.
-
-The &TexUs; utility program texus
-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 texus, and the
-API, see the &TexUs; documentation.
-
-
-
-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;.
-
-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!
-
-
-The entire &c3Dfx; SDK is available for download off their
-public web-site located at
-
-There is also an FTP site,
-
-Nope. The &Glide; source is made available only based
-on a special agreement and NDA with &c3Dfx;.
-
-
-Currently, Linux &Glide; is unsupported. Basically,
-it is provided under the same disclaimers
-as the 3Dfx GL DLL (see below).
-
-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).
-
-In addition, the Quantum3D web page claims that
-Linux support (for Obsidian) is planned for both Intel
-and AXP architecture systems in 2H97.
-
-
-There are newsgroups currently available only on
-the NNTP server
-A mailing list dedicated to Linux &Glide; is in preparation
-for 1Q98. Send mail to
-
-Currently, you should rely on the newsgroup (see above),
-that is
-
-&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
-
-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.
-
-
-
-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.
-
-
-
-
-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;.
-
-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.
-
-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.
-
-
-
-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.
-
-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.
-
-
-
-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.
-
-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.
-
-
-
-
-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.
-
-
-There is exhaustive information available from
-&c3Dfx;. You could download it from their home
-page at
-
-Basically, you should look for some of the following:
-
-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.
-
-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.
-
-
-
-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.
-
-
-
-
-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.
-
-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).
-
-
-
-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.
-
-
-
-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.
-
-There is a mailing list on this, and a web site
-with FAQ at
-
-The
-following XF86Config settings reportedly work.
-
-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.
-
-
-
-There are a couple of problems.
-
-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.
-
-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.
-
-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
-
-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.
-
-
-
-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.
-
-
-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
-
-&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.
-
-&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.
-
-
-
-The official site for &OGL; maintained by the members
-of the ARB, is
-
-A most recommended site is Mark Kilgard's Gateway to &OGL;
-Info at
-
-If you are interested in game programming using &OGL;,
-there is the OpenGL-GameDev-L@fatcity.com at
-Listserv@fatcity.com. Be warned, this is
-a high traffic list with very technical content, and
-you will probably prefer to use procmail to
-handle the 100 messages per day coming in. You cut
-down bandwidth using the
- SET OpenGL-GameDev-L DIGEST
-command. It is also
-not appropriate if you are looking for introductions.
-The archive is handled by the ListServ software, use
-the
- INDEX OpenGL-GameDev-L
-and
- GET OpenGL-GameDev-L "filename"
-commands to get a preview before subscribing.
-
-
-
-
-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).
-
-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).
-
-
-
-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.
-
-A linux port has not been announced yet.
-
-
-
-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.
-
-
-
-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.
-
-
-
-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.
-
-You will need to get the Mesa library archive
-from the
-
-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.
-
-&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
-
-The &Mesa; home page is at
-
-For latest information on the &VooMesa; driver
-maintained by David Bucciarelli
-
-Not yet (as of &Mesa; &MesaVer;), but it is on the list.
-In &Mesa; you will probably have to use the &OGL;
-EXT_multitexture 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.
-
-
-
-
-
-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.
-
-
-
-
-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 glXSwapBuffers call. This feature
-is also available with Mesa for Windows.
-
-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).
-
-Note that this experimental feature is NOT
-&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.
-
-Make really sure that you have enabled the
-following environment variables:
-
-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.
-
-
-
-
-
-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
-
-There is also a GLUT mailing list,
-glut@perp.com. Send mail to
-
-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.
-
-
-
-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
-
-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.
-
-See
-
- 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
-
- ]]>
-
-
-
-
-
- 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.
-
-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 necessary information
-to
-
-setenv SST_DUALSCREEN 1
-
-to force continued video output in this setup.
-
-
-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.
-
-
-
-
- "SLI / Pixelfx / Texelfx1 / Texelfx2 "
-
-It means that a common 2MB+2MB board would be a
-1/2/2/0 solution, with the minimally
-required total 4Mb of memory. A Canopus Pure 3D
-would be 1/2/4/0, or 6MB. An Obsidian-2220
-board with two Texelfx would be 1/2/2/2,
-and an Obsidian SLI-2440 board would be 2/2/4/4.
-A fully featured dual board solution (2 Pixelfx, each
-with 2 Texelfx and 4MB frame buffer, each Texelfx 4 MB
-texture cache) would be 2/4/4/4, and the
-total amount of memory would be
-SLI*(Pixelfx+Texelfx1+Texelfx2), or 24 MB.
-
-3dfx.events
-3dfx.games.glquake
-3dfx.glide
-3dfx.glide.linux
-3dfx.products
-3dfx.test
-
-and the 3dfx.oem.products.* group for
-specific boards, eg. 3dfx.oem.products.quantum3d.obsidian.
-Please use
-
-# 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)
-
-In summary, there is nothing prohibiting this except
-for the fact that the drivers in XFree86 are not yet
-finished.
-
-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
-
-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.
-
- help
- info glut
- subscribe glut
- end
-
-