Voodoo 5 6000 FSAA: The Feature That Never Engaged

Key takeaways

• One fixed Quake III frame at 1024×768 at cfg 5 (no AA), cfg 7 (4× AA requested) and cfg 7 with FX_GLIDE_AA_SAMPLE=4: all three md5 6361acdebeb7dec0e2396aa436a9a18a.
• 2× AA requested costs 0.99× at fill-bound 1024×768 (58.2 vs 58.6 fps); real 2× supersampling must roughly halve fill rate.
• UT99 436 on native Glide, no OpenGL in the path: cfg 8 ("8× AA") at RENDER 5.1 ms against 5.4 ms with none, and hard staircase edges.
• The display driver owns enables (SSTH3_ANTIALIAS, SSTH3_DIGITAL_SLI_AA) the lab's route never wrote — a hypothesis for the cause, not a finding. Every AA number here is "requested, not delivered".

What 3dfx promised: the T-buffer and the rotated grid

When 3dfx announced the VSA-100 line on November 15, 1999, the headline features were full-scene anti-aliasing, texture compression and T-buffer effects, with the four-chip Voodoo 5 6000 the $599 flagship (The Register). The T-buffer descends from SGI's 1990 accumulation-buffer paper, with the sample grid rotated about 20–30 degrees so samples straddle the vertical and horizontal edges the eye is most sensitive to, and "FSAA can be used with every game" (x86-secret).

Beyond3D explained in April 2000 that each VSA-100 calculates two sub-samples, so 4-sample anti-aliasing needs at least two chips, with geometry sent once and jittered by the chip itself (Beyond3D). A two-chip Voodoo 5 5500 AGP — or its PCI Mac Edition — tops out at 4×; the T-buffer arrived with VSA-100, so a Voodoo3 3000 has none (x86-secret); and 8-sample needs all four chips.

The cost was equally understood: Tom's Hardware told GeForce2 GTS owners to estimate FSAA by doubling X and Y — 1280×960 rendered internally for a 640×480 screen — and concluded "if you really need to play Q3A at High Quality with FSAA, I guess you will have to stick to 640x480" (Tom's Hardware). Supersampling is expensive by definition.

What the prototypes delivered in 2000

At the September 2000 demo, 3dfx ran Quake III at 1600×1200, 32-bit, 4-sample AA — stuttering in big fights, "silky smooth" at 1024×768 — with a sticker over the monitor's frame counter — Eurogamer's September 2000 hands-on, as relayed on the AnandTech forums, described the card as "effectively rendering four times as much information" (AnandTech forums).

Anti-aliasing was also the mode that broke the board. The Dodge Garage FAQ records the cause — secondary PCI traces run against the 2.9 V core plane with no reliable signal return — and Hank Semenec's verdict that dropping to 166 MHz "did not help" because "the problem was not on memory but on secondary PCI bus". His post-mortem PCI rework turned boards "that used to fail within 30 seconds to 2 minutes" into ones that ran overnight Quake 3 loops at 4× and 8× (The Dodge Garage); one reworked-3700A owner says the 6000 "never reached a fully stable state when FSAA was applied" across every PCB revision (VOGONS).

x86-secret's 2005 retest called 8× in Quake III "almost a pure marketing feature because the framerate is really too low" (x86-secret). The reproduction's maker says the new PCB "Functions correctly in all AA modes (unlike original V5 6K issues)" (ModLabs).

How the lab asked for anti-aliasing

On VSA-100 hardware the SLI and anti-aliasing mode is one value with nine meanings, documented in the Mesa ICD's README.3DFX (README.3DFX). AmigaMerlin 3.1-R11 carries the same enumeration in its 3dfx Tools descriptors, whose "Tweak Map" labels each entry by chip count. Those labels are the driver's words — Part 3 showed cfg 2 ("Dual Chip") beating cfg 5 ("Quad Chip") at every resolution — so this series prints number and label.

On the box it is SSTH3_SLI_AA_CONFIGURATION (REG_SZ) under HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E968-E325-11CE-BFC1-08002BE10318}\<instance>\Settings\Glide — instance \0001 on host 2 — and the launcher exports it as an environment variable too. The live key holds only that and FX_GLIDE_ANALOG_SLI=1. It writes, reads back and survives a reboot — verified on every row, in a column now named reg-readback-only, because a value that reads back is not a feature that works.

Did Quake III anti-alias?

A GDI SCREENSHOT of a Glide exclusive surface returns dark noise on host 2, so the engine took the picture. Quake III's screenshotJPEG captured a fixed demo four frame at 1024×768 three times: cfg 5 (no AA), cfg 7 (4× AA requested), and cfg 7 with FX_GLIDE_AA_SAMPLE=4 in case Glide wanted the count itself. All three PNGs carry md5 6361acdebeb7dec0e2396aa436a9a18a at 1,419,507 bytes; the JPEGs are 355,428 bytes; the PIL per-channel difference is (0,0) (0,0) (0,0). Not visually identical — byte-identical.

Byte-identical at cfg 5, cfg 7, and cfg 7 with FX_GLIDE_AA_SAMPLE=4.

Then the frame rate. At fill-bound 1024×768 on host 2, cfg 1 ("Single Chip, 2-Sample AA") returned 58.2 fps against cfg 0's 58.6 — 0.99× (host 2 results) — where real 2× supersampling must roughly halve fill rate. Host 1 showed the same shape earlier at 640×480, cfg 1 126.9 against cfg 0 127.8 (the hosts are never compared; each alone shows no cost). The host 2 re-run even puts cfg 1 at 640×480 (106.9) ahead of cfg 0 (97.4) — noise on a CPU-bound cell plus anti-aliasing that never engaged. A feature that costs nothing is a measurement bug; the article generator now flags any AA cell retaining 97% or more of its no-AA cell as "AA not applied".

Quake III 1024×768: 58.2 vs 58.6 fps. UT99 native Glide: RENDER 5.1 vs 5.4 ms.

Was it the Mesa ICD?

The first hypothesis was reasonable. AmigaMerlin's ICD is a MesaFX build — GL_RENDERER "Mesa Glide v0.63 Voodoo5 6000 (tm)", GL_VERSION "1.2 Mesa 6.3" — and Mesa might never issue the request. So the lab took OpenGL out of the path: Unreal Tournament 436 on GlideDrv.GlideRenderDevice, native Glide straight into glide3x.dll, at 1024×768 with cfg 8, "8× AA". UE1 accepts synthetic keystrokes in exclusive fullscreen, so UIKEY F11 produced the engine's own Shot; the stat fps overlay was the measurement channel.

UT99 on GlideDrv at cfg 8, 8× AA requested; the engine's own Shot.

cfg 8: FRAME=006.6 MSEC, RENDER=005.1 MSEC.

cfg 5, no AA: FRAME=006.9 MSEC, RENDER=005.4 MSEC.

Eight samples requested, and the frame rendered faster than with none. Zoomed, the cfg 8 frame's edges are hard staircases. A further frame at cfg 4 (4× AA requested) was counted: across the terrain horizon against the starfield, crop (300,430)–(700,510), 257 of 328 edge columns — 78% — carry no blended pixel. The counting script is published with the evidence README.

The cfg 8 frame, zoomed: unblended staircase edges.

One caution: the two UT99 frames are different random PlayerStarts, so their 74% pixel difference is scene and they are not a diff pair; the UT evidence is frame time and edge quality, which are scene-independent. With no OpenGL in the path, the request still never reached the chips. It is not the Mesa ICD.

The evidence, in one table

UT99 frame hashes: cfg 5 773982043ad36865dc81a460a401fd27 (497,882 B), cfg 8 08258233a3c811d2f53458e0e11c8622 (575,710 B). The dossier records this as Retraction 0.

What the binaries say

The lab read the installed files rather than the forums. glide3x.dll reads the value, carries the jitter tables — the rotated grid itself — and asks the miniport for the mode; the display driver owns enables the lab's Glide key never held.

The reading that fits — a hypothesis, not a fact — is that SSTH3_SLI_AA_CONFIGURATION selects a mode and a separate enable owned by the display driver is never set by the registry-and-environment route. The live key held the value and FX_GLIDE_ANALOG_SLI=1, nothing from the SSTH3_ANTIALIAS family. Whether 3dfx Tools writes it, whether the INF should have, or whether the reproduction answers the escape at all is not established; the miniport 3dfxvsm.sys (174,720 B, md5 83ee5503255fd9f9c2291253221cb466) is unread.

What does this mean for AA benchmarks of this card?

The finding is specific: this card, AmigaMerlin 3.1-R11 on Windows XP SP3, the mode set by registry and environment variable. It says nothing about GamersNexus' Windows 98 SE runs under Amigamerlin 2.9, Raziel64 and VRG (GamersNexus), or ModLabs' Windows ME numbers (ModLabs) — different builds, different routes. It does say what evidence an AA number needs: a frame whose bytes differ from the no-AA frame, edges that blend, and a fill-rate cost. A number with none of those is a request, not a result.

The lab applies that standard to itself first. Retraction 0: aa_verified=yes on the early rows meant only that the registry value read back. Retraction 4: the harness this campaign replaced, benchmark_runner.py, iterated an FSAA axis across 8 titles and 96 planned runs, logged "apply via the card's driver profile if configured", never applied it, and wrote the level into its CSV; its two host 1 runs were dry-runs, the only reason no bad AA row was published. Every AA cell now reads "requested and not delivered"; the card's benchmark page renders it that way.

What the lab tries next

The most promising lead is twenty years old. In 2005 x86-secret ran a genuine rev-3700A under Windows XP SP2 with AmigaMerlin 3.1 R6 and its 3dfx Tools; the panel showed 8× FSAA activated (x86-secret), and its benchmark page records Quake III at 8× returning 14.2 fps at 1024×768, 27.8 at 800×600 and 43.9 at 640×480 (x86-secret) — the collapse real supersampling produces. That route is untried here: the lab wrote the value directly, and its benchmark quiesce kills 3dfxMan.exe, the 3dfx Tools process, as a CPU thief.

1. Run 3dfx Tools, select 4× and 8×, dump the display-class key and diff it against the lab's Glide-only key — does the panel write SSTH3_ANTIALIAS and SSTH3_DIGITAL_SLI_AA?
2. Write the enables directly beside the configuration value; repeat the three-frame Quake III capture and the UT99 edge count.
3. Accept an AA cell only when the frame md5 changes, the edge count drops and the frame rate falls.
4. Repeat under other drivers — host 2's Athlon XP has no SSE2 and SFFT 1.9 requires it (VOGONS), so SFFT needs an older build or another host; the official 3dfx 1.04.00 driver is untested.

The 8× request has a history: on host 1 a cfg 8 run through Quake III's vid_restart route hung on 2026-09-12; Part 5 covers the hangs.

Bottom line

The reproduction's maker says anti-aliasing works in every mode; x86-secret reached 8× in Quake III on a real prototype through the control panel — and reported in the same article that 3DMark 2001 SE ignored the 8× setting, scoring identically to 4×. The lab has shown neither wrong — only something narrower: with AmigaMerlin 3.1-R11 on Windows XP and the mode set as the driver's own descriptors describe, the request never arrives. Our verdict: until a frame proves otherwise, the Voodoo 5 6000's defining feature remains, on this bench, the feature that never engaged.

Related guides

• Why Nvidia killed 3dfx and how Voodoo still shapes every GPU launch
• 3dfx Voodoo2 SLI in 2026: build guide, Glide setup, CF storage
• Glide on modern PCs: dgVoodoo2 and nGlide for 3dfx-era games

Citations and sources

• https://nscagentstorage.blob.core.windows.net/article-images/voodoo5-6000-strange-god/dataset/fsaa-evidence-README.md (accessed 2026-09-16)
• https://nscagentstorage.blob.core.windows.net/article-images/voodoo5-6000-strange-god/dataset/host2-124-results.csv (accessed 2026-09-16)
• https://nscagentstorage.blob.core.windows.net/article-images/voodoo5-6000-strange-god/dataset/campaign-dossier.md (accessed 2026-09-16)
• https://www.theregister.com/1999/11/15/3dfx_launches_voodoo/ (accessed 2026-09-16)
• http://www.x86-secret.com/articles/divers/v5-6000/v56kgb-4.htm (accessed 2026-09-16)
• https://www.beyond3d.com/content/articles/37/5 (accessed 2026-09-16)
• https://www.tomshardware.com/reviews/tom,184-7.html (accessed 2026-09-16)
• https://forums.anandtech.com/threads/voodoo-5-6000-preview.349187/ (accessed 2026-09-16)
• http://www.thedodgegarage.com/3dfx/v6k_faq.htm (accessed 2026-09-16)
• https://www.vogons.org/viewtopic.php?t=51006 (accessed 2026-09-16)
• http://www.x86-secret.com/articles/divers/v5-6000/v56kgb-6.htm (accessed 2026-09-16)
• http://www.x86-secret.com/articles/divers/v5-6000/v56kgb-7.htm (accessed 2026-09-16)
• https://www.modlabs.net/forum/topic/60674/ (accessed 2026-09-16)
• https://github.com/nobled/mesa-ics/blob/master/docs/README.3DFX (accessed 2026-09-16)
• https://gamersnexus.net/gpus/back-dead-3dfxs-unreleased-voodoo5-6000-quad-gpu-card (accessed 2026-09-16)
• https://www.modlabs.net/page/return-of-the-king-zx-c64-voodoo-5-6000-review (accessed 2026-09-16)
• https://www.vogons.org/viewtopic.php?t=67025 (accessed 2026-09-16)

This is a first-party lab report: the measurements above were taken by the SpecPicks Retro Lab on its own hardware. The full dataset, method, driver and game file hashes, evidence frames and every correction are published at https://nscagentstorage.blob.core.windows.net/article-images/voodoo5-6000-strange-god/dataset/campaign-dossier.md. It is not editorial synthesis of third-party sources.

— SpecPicks Retro Lab · Last verified Sep 16, 2026