[1.08 Driver/ROM Update: On 9/22/2000 3dfx released a 1.08 driver update (with ROM update as well). See the updated Genesis (9500 based) system tests that show both VSA-100 chips are now enabled.

Note: Just as I had finished writing this original review Bryan Speece of 3dfx called to say they had found one possible reason for some of my results. He said based on the 1.0 results last night they wrote a small application to test fill rates in 'fastest' mode (dual processors) vs FSAA and noted about 80MP/sec less fill rate in 'fastest' mode, indicating that mode is not running at full efficiency. This may be one reason for the fact I saw similar single chip vs dual chip performance (even in 2D) and the often close scores on 2xFSAA vs non-FSAA modes. (These sorts of baffling results cost over 2 days of re-testing as I hesitated to post results that logically made absolutely no sense.) The fix for this inefficiency should boost performance and hopefully will be available by the time retail cards arrive to end users.]

Preface: I won't even begin to try and explain some of these results, which in some cases make no sense logically. I can only assume it's due to the current drivers (1.0) or firmware (1.3). [3dfx noted there is a performance/efficiency issue in the current versions.] A major reason this review is not more comprehensive is due to the fact I literally spent days repeating tests and verifying settings, etc. to make sure I had not made some mistake in my test setup or game settings. Bryan's later comment on the driver inefficiencies must be the reason why the Voodoo5 was often outperformed by the single chip Voodoo3 cards at lower resolutions. Only after repeated tests was I confident the results were valid. Later driver updates should address the issues 3dfx says and they agree that the Voodoo5 should always outperform a Voodoo3.

I suspect my early rev G4 CPU upgrade in the B&W G3 (a 2.6 stepping with cache errata) may have hampered performance, but the results even in other cases often defied logic. Even my Voodoo3 scores in the B&W G3 seemed low. For the record, my tests with the Voodoo3 3000 AGP used beta 11 drivers, the Voodoo3 2000 PCI card used beta 12 drivers. All systems had the latest software updates including the Multimedia 1.0 update for the Rage128 PRO AGP.

In many cases here you can see that no Mac model available now really delivers enough data to a fast graphics card to saturate it. Often you'll see 'flat' performance numbers that illustrate this. In the past with slower graphics cards (before the Voodoo3 era), this bottleneck was not usually apparent. No more...

What follows some general comments on FSAA and image quality are hard numbers from benchmarking. I felt a lot better about the Voodoo5 after seeing performance of FSAA in Falcon4 and Quake2 as well as general gameplay in other titles. For those that expect 60FPS performance however, I don't think any video card can pull that much data from any Mac made to date. Although there's certainly driver optimizations that need to be done, there's nothing 3dfx can do about the fact Mac's just can't pump enough data over the bus to equal framerates from modern, fast PCs. It hurts to say that, but it's a fact of life. You can see it in the flat performance numbers from many games in the results below.

General Image Quality Comments:
Except for some faint very thin lines visible occasionally at lower res modes in some games like Quake3 in non-FSAA/16bit modes, 32bit color or 16bit color in FSAA looked great. The thin lines varied in visibility and only seemed to affect lower resolutions in 'fastest performance' settings, often most visible in smoke or fog. Maybe I'm nitpicking and this may not be typical. I'm curious to see if any other reviews mention it.

About FSAA:
My only previous experience with FSAA (Full Screen Anti-Aliasing) before the Voodoo5 was with an early driver version on a GeForce card, and I wasn't impressed. (I didn't really notice any FSAA improvement with that driver version.) After seeing FSAA (Full Screen Anti-Aliasing) on the Voodoo5, I now understand why many consider the 3dfx's hardware/jittered FSAA to be the best around. I really didn't appreciate FSAA from viewing screenshots, as they just don't deliver the same effect as seeing it in real-time instead of a static picture. 3dfx comments "Spatial anti-aliasing, the pixel pops, white flashes, and crawling pixels along the edge of the screen, is fixed with the T-Buffer, but is best shown through animation. Unfortunately a still shot cannot show how the T-Buffer solves these spatial AA issues". For more details on 3dfx's FSAA see 3dfx's FSAA white paper. (doc no longer online after 3dfx closed their doors)

The benefit to Mac owners who often can't run higher resolution modes acceptably fast is that FSAA can provide you with much better image quality at modes your Mac can sustain; offsetting the fact it's not a higher resolution. There's much debate on the PC side of higher resolutions or FSAA w/lower resolutions, but on the Mac we don't have the luxury of systems that can run most 3D games at high resolutions, so that argument is a moot point. I'm not knocking the Mac - just stating something that most avid gamer's (and graphics card companies) already know. Personally I find Mac game performance fine for my needs but do hope that improved system designs appear in the future.

I was surprised at the framerates in Quake2 and Falcon 4 with FSAA on, as it was not something I expected to be playable (especially in first person action games). FSAA in 32bit mode would be better suited for Simulations, flying games, driving games, Pod Racer, etc. but depending on your Mac, you may find 2xFSAA in 32bit mode at lower resolutions playable. 32bit 4xFSAA in Quake3 is too slow in my opinion at any resolution on a Mac, although 2xFSAA often equaled the framerates of some other cards without FSAA depending on resolution). Granted in FPS games speed is needed for survival and you don't spend much time looking at the scenery. Many feel 60FPS is needed in games like Quake3, but without configuration tweaks like Locki's config (severely reduced image quality settings), I've not seen a Mac that can run that rate with good quality image quality. And there are hundreds of thousands of gamers that are fragging away with far less than 60FPS Quake 3 scores. With Locki's config settings however (see below), framerates were over 60FPS even on a Mac. (You can get Locki's config file at http://guides.barrysworld.com/quake3/Configs&Bindings/Locki-1.3.zip. Remember you need to exec(ute) the file and also do a 'vid_restart' in the console. Also after using Locki's config, when I want to retest using the standard config file I delete the quake3 config file and relaunch Q3 to force a clean rebuild of it.)

As far as realistic expectations, remember no video card can pull more data from the system bus/CPU than it can deliver.

3dfx's claim that games look better at lower res with FSAA on than higher resolutions (and play as fast or faster than current non-3dfx Mac cards) has some truth to it. Several times I noticed that 2xFSAA 16bit lower resolutions on the Voodoo5 looked better than 32bit mode on other cards at higher resolutions and played just as smoothly. Granted the Quake series' coloring and textures are not the best way to show it off. FSAA may or may not appeal to you (I think it will in at least some games) - some prefer higher resolutions, but with the current Mac's inability to feed enough data (to any card) to sustain high framerates at high resolutions, you may find FSAA a good compromise depending on the game type.

There's no way for a static image to really show the FSAA difference, but assigning a 'hot-key' in the 3dfx control panel allows you to toggle FSAA on and off to better illustrate the differences in real-time. (Note that once enabled, toggling FSAA off with the hot-key will not restore performance back to non-FSAA modes according to the review documents. You need to use the control panel settings to restore faster performance mode.)

Notes on Older Games and FSAA: I tested FSAA with one of my old (and now dusty) favorites - Dark Forces. The walls and scene details were much smoother, but FSAA can't address the fact LucasArts used low-resolution sprites for things like enemies and explosions. These still appear jagged when viewed close-up, as does your weapon in the center of the screen. I ran the original version of the game, but don't think any Dark Forces updates would affect this. Modern games usually don't have these low-res characters and sprites.

During combat framerates averaged between 35 and 45FPS during the 'instant action' autopilot test. Until now I'd considered Falcon4 just too demanding for any Mac. I'll have to give it a 2nd look now with the Voodoo5 in the G4/500.

Descent 3:

Descent 3 showed much better performance with the Voodoo5 than any card to date. Bryan Speece of 3dfx also commented that feedback on FSAA with Descent 3 is very positive, as is overall performance in non-FSAA modes. I'm a novice at Descent 3 and don't know of any way to test framerates, but if you know of a way please contact me and I'll post some comparison numbers.

Star Wars Episode 1 Racer:

This game is one of the best live illustrations of FSAA in my opinion. Make sure you apply the v1.01 update, and I also had to edit the switches.txt file to set the Z-buffer to 16Bit, otherwise FSAA modes would freeze. After making the change the game played smooth as silk in FSAA modes.

FPS Game Performance Tests:

To compare game performance (benchmarking) I used some of the most popular past and present titles: Quake 2 (v1.03), Quake3 (v117) and Unreal Tournament. In addition to the built-in timedemos I used user created 'torture tests' like Crusher for Quake2 and Wicked400 for Unreal Tournament. I also tested Quake3 with the FPS boosting 'Locki' config file.

Quake 2:
Quake 2 requires a lot less system horsepower than later games like Quake3 and UT. Although 640x480 scores with the Voodoo5 were disappointing, I was impressed with FSAA performance. Hopefully the next update of the drivers will boost performance at 640x480 to exceed the levels of the much lower cost Voodoo3 cards.

Quake2 Crusher Demo Results: Crusher is a popular demo used to stress test your system in Quake2 to provide a more accurate performance indication from intense deathmatch play than the built-in timedemos.

At 1024x768 the Voodoo5 finally shows an advantage, running 2xFSAA at nearly the rate of a V3 3000 AGP (66mhz slot). If you noted the similarity of FSAA scores to non-FSAA, you can understand why I retested several times before daring to post such results. (I wouldn't have believed it if I had not seen it personally.)

Quake 3:

Quake 3 scores were the most baffling in many cases. Often the dual chip Voodoo5 was slower than a Voodoo3 in the same system. Also note how close (often literally identical) the Voodoo5 scores are with one chip vs the default 2 chip setting. Note that 2xFSAA was nearly as fast as non-FSAA in 640x480 mode. Again the Mac system/CPU design doesn't deliver the data to the card fast enough to fully saturate the card, but the results still were puzzling. I can only assume this driver or firmware revision is to blame. [Due to time pressure I wasn't able to graph the results, but did list them by system. Grouped as one graph from fastest to slowest was more confusing in my opinion.]

Other than the Locki config results farther down - Quake 3 had all the default quality options on (Lightmap lighting, high geometric detail, marks on walls, dynamic lighting, etc. ON).

16-Bit Test Results:

32-Bit Test Results:
(Voodoo3 not in the list as it can't run 32bit mode)

Quake3 Locki.cfg Results:
Locki is a config file for Quake3 that is designed for maximum framerates without regard to image quality.

Tests in Genesis/9500: If not for the repeated testing in the other Macs, I'd would have liked far more comparison tests in my loaded Genesis (9500 motherboard based Mac). I cannot explain why 4xFSAA was faster than 2xFSAA other than the logical conclusion that 4xFSAA is not functional in older Macs (pre-Beige G3s). Note how 4xFSAA framerates drop in tests of the B&:W G3 and G4 Macs, indicating it is working in those systems. Perhaps this is why, as noted in the 'Cons' on the first page of this review that officially the Voodoo5 is not supported in Macs older than a Beige G3.

Note: Since the 9500 tests were done at the last minute before publishing this review, I later did some further tests. I'm not sure if the older Mac hardware (PCI/Memory controller, etc.) or the Voodoo5 driver/ firmware is responsible for the fact that only one VSA100 chip seems to be fully functional. However it's clear after testing 4xFSAA in Pod Racer and from temperature tests of the two VSA100 chips that only one is really working when the card is in my 9500. (I suspect other pre-Beige G3 models would show the same results. Note: Readers with 7500, 8500 and 9600 Macs have reported that only 1 chip is fully functional in these systems also.) This explains why the 4xFSAA results in the 9500 were faster than 4xFSAA tests in the B&:W G3 and G4/500. Both VSA100 chips get hot when running in the B&W G3, Beige G3 and G4 Systems, whereas only one does in the 9500.

Note: This issue still exists in the 1.01 drivers/1.31 ROM update released in early August. Using Pod Racer as a test with the driver/ROM update, it appears that 2XFSAA is working in the 9500, but 4XFSAA doesn't show any visual benefit in the 9500. 4xFSAA requires both VSA100 chips to be operating, whereas 1 chip can perform 2xFSAA. Again I'm not sure if this issue can be fixed in a future firmware/driver update, but I wanted owners of older Mac models (pre-Beige G3) to be aware that as of driver v1.01/ROM 1.3.1 at least, there's no benefit from using a Voodoo5 vs. the lower cost single chip Voodoo4 card (due to be available in September at an estimated price of under $200).

v1.08 Driver/ROM Update Tests (9/22/2000): I've tested the new 1.08 Voodoo5 drivers in my Genesis (9500 based) system with G4 upgrade. Both VSA100 chips are working now. I ran tests at 1024x768, 32bit mode before and after the update. Before the update the 4xFSAA mode was not working (same FPS as 'fastest performance'). After the update the 4xFSAA scores at 1024x768 were the same as my B&W G3 with a G4/400 upgrade running the Voodoo5 in a 66MHz PCI slot. Both systems were tested with the new drivers.

The B&W G3 showed basically zero gain from the drivers, but the card in the G4/400 upgraded Genesis showed a small gain at 'fastest' mode, but appx. 30% gain at 2xFSAA mode now that the 2nd chip is enabled.

Here are the scores from the Genesis. Quake3 32bit settings were high geometric detail, etc. and all game options on (except vsync):

Remember with the 1.01 drivers 4xFSAA wasn't really enabled, since only one chip was fully functional (4xFSAA requires both chips). So the low score is normal now with 4FSAA functional. For the first time, both VSA100 chips are very hot indicating they are both working.

(Update:) Here's a comparison of the new drivers comparing the Voodoo5 in the Genesis w/G4 400Mhz (rev 2.2 G4 CPU w/1MB cache) vs the B&W System (66MHz slot) w/G4 400Mhz (rev 2.2 G4 CPU w/2MB cache) at 640x480, 32bit mode:

Unreal Tournament:

I ran Unreal Tournament in Glide and OpenGL modes, using both the Cityintro (flyby/movie basically) and the 'Wicked400' demo stress test. Due to deadline I will have to post those results later. I will say that the Wicked400 benchmark reports very similar framerates with several cards. The average scores even with a fast Mac and graphics card seemed to average in the low 20's (frames per second) at best, depending on graphics mode and quality settings. I can only assume the graphics cards are not getting enough data to run the demo faster. (I know that's beginning to sound like a stuck record, but it's a hard fact.) I did record min, max and average framerates to at help differentiate the performance in some way. I also played several botmatches at 2xFSAA at 640x480 on the G4 and performance seemed very smooth but the reported framerates were not stellar in.

(9/16/2000 update - The following is from tests done during my review of the MetaBox G4/450 2MB ZIF upgrade since I could not find my notes from past tests.)

The 'cityintro' timedemo was run in Unreal Tournament full version with the 425a update applied. All tests were run at 640x480 (the tests were done as part of a CPU upgrade review, to show what benefit the CPU upgrade provided and higher resolutions would have the Rage128 fill rate become a factor). OpenGL and Rave tests were run at 32bit mode with medium detail, and low audio quality, with a "min desired framerate" set to 0. Dynamic lighting was enabled. All results are in frames-per-second, higher is better.

Since the UT's timedemo stats reports min, max and average framerates, all are listed below. The Cityintro test is basically a flyby with no firing, etc. so I also included the Wicked400 demo torture test as well. Scores with Wicked400 have always been very low even with the fastest Macs I have.

One important note I wanted to make about the OpenGL scores. I had problems applying the 425a update and ended up performing a clean install and then applying the patches. I didn't realize until preparing to run the G4/AGP system tests that I had not reset UT to my normal 150MB allocated RAM setting (Westlake notes OpenGL mode requires more RAM). Had I noticed this sooner I would have re-tested (I thought I had reset UT to 150MB). The 107MB default UT allocation may have affected OpenGL scores somewhat with the Rage128 cards but a repeat of the Cityintro and Wicked400 tests on the G4/500 AGP with 150MB allocated showed scores were literally the same, with a max of 0.5 fps gained from the additional RAM allocation with the Cityintro test and only 0.2 FPS avg gain on the Wicked400 OpenGL mode test (at least on that system/video card combo).

The Voodoo5 PCI card however, would lock up quickly in UT with only 107MB RAM allocated, so scores in the table for the Voodoo5 were with 150MB allocated. (Glide mode ran fine with 107MB allocated to UT, but since that's 16bit mode the results are not show in the table (but are farther down in the text).

Like many of the other results from this review, performance was disappointing with the current drivers (1.01 drivers, 1.31 ROM used for the UT tests). As you can see above, in some cases a Rage128 was faster at 640x480 modes than the Voodoo5. (Granted at higher resolutions the fill rate limits of the Rage128 would cause FPS to drop, where the Voodoo5 card would stay relatively flat from 640x480 to 1024x768). Since it wouldn't be fair to include 16-bit Glide mode tests in comparison to the 32Bit modes above but for those that are interested Glide mode results with the V5 and the G4/450 CPU upgrade, here they are:

Voodoo5 Glide (16Bit) Results w/G4/450 2MB Upgrade: