3Dfx and Mesa Howto

3Dfx Voodoo3/Banshee Linux How-To

(2-1-01 Note: This was originally written in July, 1999. Much of it is out of date, especialy since 3Dfx has gone out of business! Pretty much all the links which go to www.3dfx.com don't work anymore. The best place I can find for the Glide packages are at http://www.rpmfind.net/linux/RPM/. At least you can get the Glide lib there and install it with little pain. Another very interesting site is http://sourceforge.net/projects/glide/ which is the development site for, apparently, an open-source flavor (or could be the same as production) Glide lib.)

This is an attempt to show how (in theory) one could use their 3dfx card to use some OpenGL based end product like Quake 3 Test under Linux. Notice, Q3T has a problem with it's default configuration which makes it not work 'out-of-the-box' (as of version 1.05), so replace the config file with the one below. I'll be assuming that you have a Voodoo3 (this may work with a Banshee as well), and a semi-recient Linux installation with access to the usual tools.

Get and install the packages:

http://glide.xxedgexx.com/3DfxRPMS_vb_glibc.html -- the X server, Glide, 3Dfx device module, etc.

http://www.3dfx.com/ -- The Linux Glide 2.x SDK (required for compiling Mesa with Glide support)

http://www.mesa3d.org/download.html -- A recient version of Mesa 3.1. You can also try the very latest CVS code by doing this in an empty directory:

# cvs -d :pserver:anonymous@cvs.mesa3d.org:/cvs/mesa3d login
[hit return]

# cvs -d :pserver:anonymous@cvs.mesa3d.org:/cvs/mesa3d checkout .

(notice that space and period after 'checkout')

To 'sync' the code to the current version at some later time, do this within the same directory: # cvs update -d

Install the RPMs and such on the system and do any configuration you might need to. If you get some weird dependancy problems from a missing 'libNoVersion', then simply use the rpm parameter '--nodeps'.

Priority for getting things working:

1: get X working with support for the usual resolutions (640x480, 800x600, 1024x768, and any others you might want) for 16 bit depth and other depths you might use. Due to popular request, I'll cover this a little bit more in detail:

Get and install Daryll's RPM of the X server for the Voodoo3/Banshee.

Get Daryll's xf86config (from the same place)

Make sure your symbolic links for 'X' all point to Daryll's 'special' XF86_SVGA (these include /usr/X11R6/bin/X, /etc/X11/X, and maybe others)

Use Daryll's xf86config program to create the XF86Config configuration file (mine gets kept at /etc/X11/XF86Config). Just answer the questions to set up your mouse, keyboard, monitor, and video card. Answer 'no' to RAMDAC and 'clockchip', and don't do any 'probing'.

Note that the 'screen' section in XF86Config used with the server is the 'svga' screen (not the 'accel' screen)

Most of the resulting XF86Config file is fluff and can be shorted up by quite a bit, in case you try to wade through it.

After a lot of nudging, I've reluctantly made available my XF86Config file. The link to it is the period at the end of this sentence. ;') You must understand, though, that it is for a US keyboard, an intellimouse type PS/2 mouse, my font paths (usual rh5.2), and a multisync 17" monitor.

When you get into X (by a 'startx' or what ever), you can change resolutions by doing ctrl-alt-plus/minus (plus and minus on the numeric 10-key pad, that is). If you want to change the default resolution (xf86config likes to make the lowest res the default), change the order of the resolutions in the screen/display lists near the bottom of the XF86Config file (remember, for 'svga'!).

You can choose the bit depth when you startx by doing a 'startx -- -bpp [depth]'. For example, to start in 32-bit, do this: 'startx -- -bpp 32'

If you get stuck, read the man pages for 'XF86Config' ('xf86config', 'X11', and most others probably won't help much regarding this). Do some searches on the net, too, for help. This is a deep topic, but then again it's like being able to build and configure MacOS's 'Finder' or Windoze's interface from scratch. It's a pain, but the control and flexibility is quite impressive when you understand how things work (not to mention that it works across many hardware platforms!).

1b: If you want to build Daryll's X server from scratch, download his source package and install it. Untar X333src-1.tgz, X333src-2.tgz, and X333src-3.tgz all in the same directory. You should have a directory 'xc'. Go into it and do a 'patch -p1 < /usr/src/redhat/SOURCES/BansheeDiffs'. Then a 'make World' and (if it worked OK), a 'make install'. Be warned, this take a lot of disk space and time. Also be carefull to make sure that you don't have any old X libs laying around which the system will be trying to link to (I had trouble with libs in /usr/i486-linux-libc5/lib being linked). Also notice that new shared libs (.so files) are installed but not archive files (.a files).

2a: get glide working. Run these commands in X while in 16 bit depth (startx -- -bpp 16) as root:

# /usr/local/glide/bin/test3Dfx -r 640x480

# /usr/local/glide/bin/test3Dfx -r 800x600

# /usr/local/glide/bin/test3Dfx -r 1024x768

You should get a blue screen at increasing resolutions for each test.

2b : now, to get glide working through the /dev/3dfx device. Do this by building and installing the 3dfx.o module (part of Device3Dfx-x.y-z.src.rpm package, installed at /usr/src/redhat/SOURCES/Device3Dfx-x.y.tar.gz). Don't use the 3dfx.o file provided, remove it (if it exists) and type 'make'. Be certain that it is build for SMP if you are using an SMP kernel - insert '-D__SMP__' in the CFLAGS list if needed. Then insert the module using 'insmod [full path to 3dfx.o]'. You need to do this every time your computer boots (inserting the insmod command in /etc/rc.d/rc.local is a good idea). Now, if it doesn't already exist, create the device file by doing a 'mknod /dev/3dfx c 107 0' as root. Then change the permissions on the file as appropriate (like 'chmod a+rw /dev/3dfx'). Now test this setup by running test3Dfx exactly as stated for step 2a but under a regular user ID. The 3dfx module contains some extra stuff in it (like MTRR settings) to increase performance not just for users, but for root as well. Daryll suggests using it even if you will be doing 3D stuff mostly as root.

3: Get Mesa working. This is a few steps: (note: the lib with Q3T works, so you don't need to do this if all you want to do is use Q3T. But, it definately can't hurt to build your own optimized and more up-to-date Mesa lib.)

Set a link to the glide headers so Mesa can find them:

# ln -s /usr/include/glide /usr/local/glide/include

'make' it:

# make linux-386-glide

set the environment variable MESA_GLX_FX to 'fullscreen'. Under bash, it looks like this:

# export MESA_GLX_FX=fullscreen

(For more info on related environment variables which effect Glide, check out this page.

Run the demos in 3Dfx/demos. They should all run very fast as long as your X is in 16 bit and you are root. Warning, though, 'gltest' takes a while and isn't interruptable. You can set the geometry of the demos to something other than 640x480 by doing (at least 640x480, 800x600, and 1024x768 should work):

# tunnel -geometry 800x600

You can use some other demos (like gears) in accelerated mode by replacing the 'glutInitWindowSize' call with one which passes an initial x and y which you can support in fullscreen mode, such as:

glutInitWindowSize(1024,768);

Finally, try to run Quake3Test if you feel brave (you may need to do a hard reboot if you attempt this and it fails):

# export MESA_GLX_FX=f

# q3test/linuxquake3 +set r_glDriver [your-Mesa-path]/lib/libMesaGL.so

BTW-Tv out works while in 3D rendering mode! Use the lm-sensors package to control the BT869 on your Voodoo3. You need to change your 640x480 and 800x600 modes (for US NTSC) to:

ModeLine "640x480NTSC"  28.195793   640  656  658  784   480  520  525  600
ModeLine "800x600NTSC"  38.769241   800  812  814  880   600  646  649  735

HINTS:

People are able to get Q3T working by doing the following:

Setting in_dgamouse to "0" (in the config file)

Setting the enviroment variable 'MESA_GFX_FX' to 'f'

Choosing the Mesa lib with Glide support (by doing something like './linuxquake3 +set r_glDriver /usr/src/Mesa-3.1/lib/libMesaGL.so')

Optionally, to turn on the optimal caching method for the Voodoo's (well, for video cards in general) by doing something like: 'echo "base=0xXX000000 size=0x1000000 type=write-combining" > /proc/mtrr' (replace X's with the proper values of the Prefetchable 32 bit memory for the video card)

Follow up: Here's a q3config.cfg which worked. (Thanks to Martijn de Meulde)

More follow up: I just confirmed that the config file above works! Be sure to change some of the preferences (like player name).

Update on the AMD issue:

(The AMD issue is out of date, and has been removed because it is no longer a problem.)

CPU usage fix. Q3T 1.05 and older had a problem with doing spin-waits, this version of the linuxquake3 app solves this. (Don't ask where it came from... ;') Now, finally CPU usage drops down to about %20 (depending on the CPU, I suppose).

Enabling 'Bots': Well, it can be done on the Windoze version (using a 'patch' written by YoGrE [who has been giving me tips and tricks to try for the Linux version]), but at least one vital library function for generating the 'nav' maps is left undefined in both versions 1.03 and 1.05 for Linux. The best possible solution (as of the time of this writing [6/26/99]) is to use a nav file generated from the Windoze patched version (like the one here for the Q3TEST1 map), and then try to use the 'bot' command to use it. Here's how to 'patch' your qagamei386.so to enable bots:

Do this first. This unzips the pak and puts the contents in a directory named 'baseq3'. If you've already done this, then skip this step. (BTW- You may need to copy maps/q3test1.bsp to maps/Q3TEST1.bsp. There is some weird case-sensitive problems that can arise. Same goes for the Nav file.)

Duplicate qagamei386.so (for backup reasons)

Get a nav file for the map, like the one here. This is a .nav file created by the Window's version of the bots patch which has the benefit of using the 'nav gen' console command missing for the Linux release.

Use a hexeditor (like hexedit) to change the 16 bytes starting at offset 0x242A0 from
E8 1F 38 FE FF 83 C4 0C 85 C0 75 08 E8 53 37 FE
to
E8 23 94 FE FF 83 C4 0C 85 C0 90 90 E8 5B 9E FE

Then, use the 'bot' command like normal.

One catch to this is that the nav map is loaded every time the bot command is used. This can cause q3t to run out of memory if you spawn a lot of bots. BTW- There are some rumblings that a new version of Q3T is going to be released soon and it may have bots enabled.

Known Issues:

AMD machines (just those with '3DNow' support?) had problems getting even the glide tests to run. The 'fix' is to tell Glide to not use the 3Dnow! instructions. Do this by setting the environment variable FX_CPU to "5". (Notice: The current version of glide does not have the problem. Don't do this 'fix' unless you experience problems.)

ALSA sound drivers get locked-up after running Q3T once (/dev/dsp reports always being busy). Apparently, this is a known bug in Alsa (not Q3T) and has since been fixed in the latest (CVS) version of the Alsa drivers. The problem has something to do with the way some programs (like Q3T) directly DMA map audio to /dev/dsp. I haven't tested to see if using the latest Alsa fixes this, but it sounds like it does.

Some have reported some build problems with the 3dfx.o module. I don't think you need 3dfx.o to play as root, but if you need it, make sure that you read the building instructions and get certain flags correct (like -D__SMP__) included when you need them. I didn't have any troubles building after reading the docs. Update: Daryll changed the way the module builds, so read the docs. Also note that the 3dfx module does some optimization [like MTRR stuff] which can help performance for root as well as for users.

Mesa on Redhat 6.0 might give people problems. If so, Jason McMullan (jmcc@ontv.com) suggests building using the "i386-glibc20-linux-gcc" gcc. Or downloading the RedHat RPM package with 3Dfx support. Also check Daryll's page for builds specific to glib2.1 and RH6.

Color allocation for 8-bit apps report 'color allocation failed' errors, even when running in 16-bit or better. I've experienced this first hand, but wasn't able to pin it down from talking with Daryll, app developers, nor the X86Free team. This probably requires some code sniffing by a third party to verify and fix the problem.

MTRR magic (a speed optimization):

Phil DeBecker (debecker@NO.SPAM.iglou.com) write:
[...] All that /dev/3dfx (the device entry for the 3dfx.o module)
does is allow you to remap the board's memory into user space so that
you can be a non-root user and access it.

If you want to set an MTRR write-combining entry for your V3, cat your
/proc/pci and look for the 3dfx entry.  Mine looks like:

  Bus  1, device   0, function  0:
    VGA compatible controller: 3Dfx Unknown device (rev 1).
      Vendor id=121a. Device id=5.
      Fast devsel.  Fast back-to-back capable.  IRQ 11.  
      Non-prefetchable 32 bit memory at 0xf6000000 [0xf6000000].
      Prefetchable 32 bit memory at 0xfc000000 [0xfc000008].
      I/O at 0x9000 [0x9001].

(this is an AGP V3-3000 but it still gets a /proc/pci entry)

You want to use the prefetchable range; assuming your memory ranges are
like mine, you'd enter the following:

echo "base=0xfc000000 size=0x1000000 type=write-combining" > /proc/mtrr

This will yield (in /proc/mtrr):

reg00: base=0x00000000 (   0MB), size= 128MB: write-back, count=1
reg01: base=0xfc000000 (4032MB), size=  16MB: write-combining, count=1

There is a noticeable speedup in small polygon rendering when you do this :)

For relative MTRR acceleration results, check out Bucciarelli's page here. I got roughly the same percentage increases for these same tests with my Voodoo3 as he did for his Voodoo2 on his page.

This is a chart I made from my results of my Voodoo3 compaired to David Bucciarelli's Voodoo2 using the same tests.

Other speed optimizations (over clocking and such). People are still experimenting and discovering things, but here's what I know so far:

Overclocking or other 'hacks' can do bad things to your card. Do so at your own risk and know that you are probably voiding the warranty (how would they know? I dunno, but you want to be a _good_ person, don't you?) Odds are that if you didn't notice an improvement of the MTRR 'hack', then overclocking is probably going to do your hardware more harm than do you good.

Hey, just cool it buddy! The card gets hot. Put a fan on it. If you really want to have fun, put a fan on it and sandwich a Peltier between the chip and heatsink. Here's Peltier How-to I wrote after playing with a couple Peltiers I ordered..

If the card 'hangs' during 3D, then it is getting too hot. If this happens without a fan and without overclocking, then take the card back to the store where you bought it as a defective product. People are reporting this happening, and 3Dfx says to return it if this is the case.

Play with the environment variables. This is where people haven't had much luck, but head on over to this nice site which has some nice info, and looks nice, too.

I did some 'poking around' and discovered these (environment?) variables:

IFX_GLIDE_NUM_TMU
FX_GLIDE_BOUNDS_CHECK
FX_GLIDE_NO_SPLASH
FX_GLIDE_SHAMELESS_PLUG
FX_GLIDE_IGNORE_REOPEN
FX_GLIDE_NO_DITHER_SUB
FX_GLIDE_LOD_DITHER
FX_GLIDE_ALLOC_COLOR
FX_GLIDE_TMU_MEMSIZE
FX_GLIDE_ALLOC_AUX
FX_GLIDE_LWM
FX_GLIDE_SWAPINTERVAL
FX_SNAPSHOT
SSTH3_RGAMMA
SSTH3_GGAMMA
SSTH3_BGAMMA
FX_CPU
FX_GLIDE_EMUL_RUSH
FX_GLIDE_BUMP
FX_GLIDE_BUMPSIZE
FX_GLIDE_GRXCLK

Other items of interest:

Another Voodoo3 How-to aimed at Newbies.

Yet another V3 howto this time aimed at Suse users. Very well organized and has different doc formats (besides HTML) as well as much detail.

A Debian Voodoo3 How-to aimed at, well, Debian users who want to get their Voodoo3 or Banshee running.

Another Q3T Linux How-to breif, but has some good stuff.

The Lm-sensors project has some support for the BT869 video (TV) out at 640x480 and 800x600 resolutions (both NTSC and PAL).

Quake3Tool is a Java program I wrote to send remote connection commands ('rcon's) to a Quake server over the internet to control it. It can also be used to query a server to gather information on what level is being played, how may people are connected, etc.

xscreensaver is a screensaver package with some OpenGL (Mesa + Glide compatibile) screensavers. There are also some neat non-GL ones like 'xmatrix' (the 'static' seen on the monitors in the movie "The Matrix").

3Dfx + Mesa Demos is a collection of demos and Mesa programs which the author of the Glide interface for Mesa thought was interesting. The particle system package is quite fun (but requires some tweaking.

LinuxQuake web site is a popular site. This page has been known to have been linked from there.

S'Cary's Shuga Shack is a good site, particularly the message board area for Q3T and Q3T for Linux.

The (new) Quake 3 Arena site from Id, of course, is a good place to visit.

What to do when things go wrong:

Panic. Scream. Run naked in the streets. Then when you are done with those things, don't bother continuing to get something farther down the list working if you run into something which doesn't work. E.g., if Glide tests don't work, don't bother trying to get Mesa+Glide working.

Try to read as much of the docs you can for the software you failed to get working, and try to fix it. A good resource is the 3dfx.glide.linux newsgroup at news.3dfx.com. If you can't figure out your problem, first *read* the other posts, then if you can't find your answer, post a message to 3dfx.glide.linux giving your errors and what you tried to do.

I got everything working, including q3test, from the steps above. I'm using a Voodoo3 3000 AGP on a 440GX dual PentII Linux box running kernel 2.2.7+SMP with gcc version 2.8.1.

Visit Chickenhead: