Recent times in the video card industry have placed increasing importance on hardware. With NVIDIA creating an almost unheard of 6 month product cycle, video card hardware seems to evolve at lightening fast speeds. Although it was not until recently that other manufacturers were able to match NVIDIA's pace, the pressure to produce faster and more powerful hardware has been on ever since the launch of the TNT2

Although both the video card manufacturers as well as the video card consumers place a large amount of emphasis on hardware, one aspect of a video card's performance is often overlooked and many times swept under the carpet. No matter how much we may deny it, video card drivers actually play a crucial role in card performance. Unfortunately, with increasing importance on hardware, software in the form of drivers was often neglected.

Slowly but surely, however, many manufacturers realized the increased importance of drivers in a product. The most recent example of this was the August announcement of NVIDIA's Detonator3 Drivers that accompanied the release of the GeForce2 Ultra. The announcement of the Detonator3 drivers marked the first time in recent memory that a video card manufacturer mated a new driver with a large product announcement. NVIDIA, knowing that the Detonator3 drivers would increase performance to a noticeable extent in gameplay, found that a "driver launch" would be the perfect way to show that they are still dedicated to "older" products while still working on the newer ones.

Other manufacturers have not made as big of a deal out of new drivers, skipping the "driver launch" idea and choosing to just release the drivers on the support pages. Such drivers are not only often unrecognized by users but many are also untapped when it comes to potential performance increases. All but the very technologically inclined, for example, would notice the naming difference between ATI's initial D7.11-CD01 driver release and the more current D7.14-0831a-62B-SPD build, let alone know which version they are currently using.

The problem with this is these newer and often undownloaded driver builds often result in not only bug fixes but also speed increases. Take 3dfx's most recent products, the Voodoo4 4500 and Voodoo5 5500. The Voodoo5 5500 debuted with driver version 1.00.01 while the Voodoo4 4500 arrived with support in version 1.03.00, yet both cards are supported in the most recent 1.04.01 build. With some users noting large performance increases as well as support for hidden surface removal (HSR), we thought it was about time AnandTech took a look at 3dfx's newest drivers.

The Test Explained

We were recently asked a few questions by our readers inquiring about our testing process. One question posed is why we do not use the more current and T&L based D3D game Evolva for testing. The reason for this is due to the limited attraction of Evolva. Our benchmarks are there to show how a card performs on games that the reader plays. Unreal Tournament, our current D3D benchmarks, is far more popular than Evolva, allowing users to better judge how games they play will perform on a given card or driver set. Recently we have also switched to Reverend's Thunder demo benchmark and we have been quite happy with the stress that the benchmark puts on the video card. Until a new popular D3D game that has a respectable benchmark comes out, we will continue to use Unreal Tournament to judge D3D performance.

A second question posed is why we use D3D for testing of 3dfx cards as opposed to Glide. First off, the reason we test D3D as opposed to Glide is that game supporting Glide as an API are dwindling. The current crop of video games are supporting D3D and OpenGL far more than Glide, meaning that testing in D3D is a better representation of how a card will perform in the future. In addition, we pointed out in our GeForce2 GTS review that not only does Glide limit color depth to 16-bit (a quality frowned upon by many) it also runs slower than D3D at higher resolutions. For the full explanation, please look here. Keep in mind that these scores were recorded with a previous benchmark.

To support this theory, please read the following quote by Tim Sweeney as made in the "Ask The Sweeney" interview found on VoodooExtreme:

Tim, [Question submitted by Jeff Walker] Is Glide dead yet?

Tim Sweeney's response -- Yes. Glide is dead. Nobody is writing any new code aimed at Glide. There are just some games on the market still taking advantage of it, so it will be a little while before the thing is fully buried. But I can assure you developers are doing their best to shovel dirt on the grave, and it we ever see the deceased try to claw its way out, we will whack it back down.

The final question we were asked was what settings we use to test. This is a very good question and since it has been a while since we last addressed this, let's take a look how we test.

First off, one will note the lack of a Sound Card in our testbed platform. We have chosen to eliminate the soundcard from our test system because we wish to isolate the performance of the video card alone. Including a sound card in our tests would introduce a second potential bottleneck that would mean that the performance of the card would no longer be measured accurately.

Now, when it comes to game configurations, we test each card with the same set of settings. In Quake III Arena, we test all cards with the "Normal" settings, only modifying the color depth, texture quality, and video mode (resolution) to the desired resolution. For example, at 1024x768x32, we set the video mode to 1024x768 and both the color depth and texture quality are set to 32-bit.

In Unreal Tournament, we only alter the world texture detail setting, the skin detail setting, the min desired framerate, the resolution, and the color depth. Both the world texture detail setting as well as the skin detail setting are set to high, while the min desired framerate is set to 0 in order to stress the video card to the maximum amount. Both the resolution and the color depth are set to what ever resolution and color depth we are testing with at the time.

Our final benchmark, MDK2, is left at all defaults except for enabling hardware T&L as well as altering the resolution to reflect the desired resolution. Even in cards that do not support T&L, we enable this feature in order to see how the card performs in a T&L game. We expect to see more and more games support this feature and we feel it is important to see how a card reacts in a T&L environment.

In all of our benchmarks, we have V-Sync disabled. This is set because we wish to measure the performance of the video card, not the refresh rate of the monitor.

With those questions out of the way, let's see what kind of system we are going to test on today.

The Voodoo5 5500

Although the Voodoo5 5500 was originally scheduled to launch in fall 1999, chip shortages and compatibility problems pushed 3dfx's multiprocessor weapon back to the summer of 2000. Powered by two VSA-100 chips, the expectations surrounding the Voodoo5 5500 were quite large. Although it is true that if the Voodoo5 5500 arrived when 3dfx planed it to, the Voodoo5 5500 would have been quite a show stopper. The problem came with the Voodoo5 5500's delay, a delay which placed the card head to head with cards such as the the GeForce2 GTS and the lower priced GeForce2 MX. High performers such as the GeForce2 GTS and the GeForce DDR had no problem overpowering the Voodoo5 5500. For more information regarding the Voodoo5 5500, please see our Voodoo5 5500 review.

Lucky for 3dfx, the preliminary numbers proved to be a bit deceiving. Early and immature drivers plagued the early Voodoo5 5500 tests. We originally noted the problem when in 640x480x32, where the Voodoo5 5500's performance was severely crippled. Although some of the Voodoo5 5500's lackluster performance at low resolutions are due to the Voodoo5 5500's lack of a T&L engine, we suspected that some of the performance problems could be attributed to immature drivers.

With the release of newer Voodoo5 5500 drivers, many users noted increased performance. Let's see how the performance of the Voodoo5 5500 increased with more mature drivers.

Voodoo5 5500 - Quake III Arena Performance

Via the maturation of the Voodoo5 5500's drivers, we are able to see a slight performance increase over the original drivers at 640x480x32. Although updated drivers do not make up for the lack of T&L support in the VSA-100 chip, they do provide a 5% speed improvement. This allows the Voodoo5 5500 to encroach even more into the GeForce2 GTS's area, falling behind the GTS by about 25%.

The updated Voodoo5 5500 drivers provide an even larger performance increase at 1024x768x32. Increasing the framerate by 5.7 FPS, the 1.04.01 drivers increased performance at this resolution by about 9%. This raises the framerate to a total of 72.6 FPS, making 1024x768x32 a very playable resolution. Although the Voodoo5 5500 falls behind the GTS by 27%, the speed increase associated with the more recent drivers places the Voodoo5 5500 in a more favorable position.

Finally, at 1600x1200x32, we see a jump similar to those experienced in other resolutions. At this resolution, the performance of the Voodoo5 5500 jumps about 10% to reach 24.6 FPS. Although this is 38% slower than the GeForce2 GTS, both cards will be noticeable slow at this resolution. The only way to clear the 1600x1200x32 barrier successfully is to invest in a GeForce2 Ultra, GeForce2 Pro, or a Voodoo6 6000, if you can find one.

Voodoo5 5500 - MDK2 Performance

Typically we associate more recent drivers with increased performance, as we observed in Quake III Arena. Unfortunately, manufacturers often times sacrifice speed in one game to make another faster. This seems to be the case in the Voodoo5 5500's 1.04.01 drivers: although we saw Quake III Arena scores increase by a noticeable amount, MDK2 scores actually decrease with the newer drivers. Although the difference is very small, going only 4% slower with the more recent drivers, it is still disappointing to see the Voodoo5 5500 decrease in MDK2 performance.

We also notice again that the Voodoo5 5500 is severely lacking when it comes to MDK2 performance, as the card falls behind the GeForce2 GTS by a full 184%. This is most likely due to the intense stress that MDK2 places on a card's T&L engine, if available. Since the VSA-100 chip does not possess any T&L section, the Voodoo5 5500 is not able to match the speed of NVIDIA's "second generation T&L."

Once again we find that the Voodoo5 5500 looses speed in MDK2 with the latest drivers. The performance loss is extremely small, just .7 FPS or 2%, however it is still present. The Voodoo5 5500 takes back seat again to the GeForce2 GTS regardless of drivers, with the GTS performing 160% faster. Once again, this can be attributed to the Voodoo5 5500's lack of a T&L engine.

Finally, at 1600x1200x32, we see that it does not make a difference which drivers you use in MDK2. Unlike the previous resolutions, MDK2 is finally faster with the latest Voodoo5 5500 drivers, with a speed increase of a nearly unmeasurable .1 FPS. The high resolution is beginning to put stress on the GeForce2 GTS, allowing the Voodoo5 5500 to catch-up to some extent. Here, the card performs 'only' 60% slower than the GeForce2 GTS.

Voodoo5 5500 - Unreal Tournament Performance

The minimum framerate recorded by Unreal Tournament increased significantly when going from the release drivers to the latest 1.04.01 drivers. With a framerate increase of 11.1 FPS or 30%, the minimum framerate recorded by the Voodoo5 5500 clocks in about 2 FPS faster than the minimum framerate that the GeForce2 GTS produced.

This increase is quite dramatic, as it shows that by simply upgrading the Voodoo5 5500's drivers one is able to significantly improve gameplay.

The average framerate associated with the Voodoo5 5500 remains relatively unchanged regardless of driver build. Although we saw a dramatic increase in minimum framerate, the average framerate is not affected. This is most likely due to the fact that the minimum framerate number is only hit very rarely during gameplay (under times of extreme system stress). Regardless of how the Voodoo5 5500's performance varies with driver build, the card remains 3% faster than the GeForce2 GTS at 640x480x32

Once again, we see minimum framerate dramatically increase with the latest Voodoo5 5500 drivers. Rising 19 %, the minimum framerate that the Voodoo5 5500 produced was 35 FPS. Although this is 5 FPS behind that of the GeForce2 GTS, it is a substantial improvement over the 30 FPS that the card previously produced.

Unlike at 640x480x32, the average framerate for the Voodoo5 5500 at 1024x768x32 increases with the latest driver build. The Voodoo5 5500 was able to increase performance by 4 % with the simple driver update and was able to narrow the margin of defeat down to 10%.

At 1600x1200x16, there is only so much that a driver can speed up hardware. The raw power of the Voodoo5 5500 is simply not enough to compete with the GeForce2 GTS, and therefore the Voodoo5 5500 is easily dominated. The lack of performance increase with the latest drivers suggests that the Voodoo5 5500 is no longer driver limited at this resolution but rather hardware limited.

Similar to the results we saw in the minimum framerate measurement of Unreal Tournament at 1600x1200x16, the Voodoo5 5500 appears to have hit its maximum performance regardless of drivers. The lack of performance increase between driver builds suggests that the Voodoo5 5500 is simply over powered by the GeForce2 GTS.

Voodoo5 5500 - 16-bit vs 32-bit Performance

As always, we were interested to see exactly how the new Voodoo5 5500 drivers effect the card's 16-bit and 32-bit performance. By testing Quake III Arena at both 1024x768 as well as 1600x1200, we could judge how the new drivers impact 16-bit and 32-bit performance

At 1024x768, the updated Voodoo5 5500 drivers seem to help 32-bit performance more than 16-bit performance. At 1024x768x32, the Voodoo5 5500 only improved by 3% or 2.3 FPS. On the other hand, 32-bit performance increased by 9%, as we saw in our previous Quake III Arena tests.

At 1600x1200, the performance increase given by the later 1.04.01 drivers seem to favor 32-bit color once again. At 1600x1200x16, the newer drivers result in a 5% performance increase and at 1600x1200x32 they result in a 10% increase.

Voodoo5 5500 - FSAA Performance

One other major attraction of the Voodoo5 5500 is its full scene anti-aliasing support (FSAA). 3dfx was the first manufacturer to not only publicly mention FSAA but also support it in a product. The idea of "smoothing" the edges of a picture in order to produce a clearer picture grabbed the attention of many, and the Voodoo5 5500's design essentially screams for FSAA support.

By including two VSA-100 chips on the Voodoo5 5500, the card's performance is equal to that of a single chip VSA-100 solution (3dfx's Voodoo4 4500) when 2x FSAA is enabled. Although this means that the resolution must be brought down to compensate for the performance loss, many claim that FSAA at lower resolutions looks better than no FSAA at higher ones. Throughout the months that have passed since FSAA's introduction, the question of which is better, higher resolutions or FSAA, still sparks heated debate. For more information on FSAA, please see our FSAA & Image Quality Comparison.

We were curious to see what kind of improvements in the FSAA arena came with updated driver builds. We have already seen rather large improvements in non-FSAA scores in Quake III Arena, but would the drivers provide similar results with FSAA on? Let's take a look.

We thought we saw large performance gains between driver builds with FSAA disabled, but those gains appear to be only the tip of the iceberg. While running Quake III Arena in a variety of resolutions with 2x FSAA enabled, we were able to realize huge performance increases throughout the whole spectrum.

At 640x480x32, updating the Voodoo5 5500's drivers produced a 11% performance gain, pushing the 2x FSAA score up to 84.2, only 11.2 FPS below that of the non-FSAA score.

The performance increase was most dramatic at 800x600x32, a resolution that many people choose to use FSAA in. Here, the Voodoo5 5500 was able to increase performance by 33%, pushing the scores over the much desired 60 FPS mark.

Finally, at 1024x768x32, an update to the 1.04.01 drivers allowed the card's performance to increase by 11%, the same performance increase we saw at 640x480x32.

Although the performance increases seen when in FSAA 2x mode are impressive, they are not that unexpected. Since enabling FSAA 2x means that the Voodoo5 5500 must render each frame twice, it makes sense that the effectiveness of the driver update is realized two fold. At 640x480x32 we see that this is almost exactly the case, with the non-FSAA performance increase clocking in a 5% and the FSAA performance increase double that at 11%. Although we did not test non-FSAA at 800x600x32 (as this is no longer a resolution included in our standard video card tests), it is quite logical to expect that the Voodoo5 5500's performance at this resolution increased by about 15% after the driver update due to the fact that 2x FSAA performance increased by 33%. Finally, at 1600x1200x32 the Voodoo5 5500 begins to become hardware limited as opposed by driver limited when FSAA 2x is enabled. This explains why the Voodoo5 5500 gains 11% with FSAA enabled at this resolution but still gains 9% speed with FSSA disabled.

The Voodoo4 4500

Just like the Voodoo5 5500, the Voodoo4 4500 was extremely delayed. The idea behind the budget Voodoo4 4500 was quite a good one: instead of having two VSA-100 chips each with 32MB of memory each like the Voodoo5 5500 has, 3dfx decided to produce a lower cost card that only utilized one VSA-100 chip paired with 32MB of memory total. As was the case with the Voodoo5 5500, if the Voodoo4 4500 came when it was expected it would have been not only a novel idea but also a rather impressive product. The problem is that the Voodoo4 4500 did not launch until October of this year. For more information on the Voodoo4 4500, please see our Voodoo4 4500 review.

The delay pushed the Voodoo4 4500 into competition with two other high performance budget cards, the NVIDIA GeForce2 MX and the ATI Radeon SDR. As we saw in our Budget Video Card Comparison - November 2000, the Voodoo4 4500 could not compete with the other higher performing options. Let's see if updated drivers can put the Voodoo4 4500 in a more favorable position.

Voodoo4 4500 - Quake III Arena Performance

Unlike the dramatic performance increase we saw with a simple driver update in the case of the Voodoo5 5500, updating the Voodoo4 4500's drivers result in no performance change. The scores remain the same regardless of which driver built is used. This is most likely due to the fact that the Voodoo4 4500 was already using driver build 1.03.00 upon its release. This means that while the original Voodoo5 5500 drivers lagged behind the most recent drivers by about 3 publicly released builds, the Voodoo4 4500 drivers only changed by one build since the card's release.

At 1024x768x32 we come to the same conclusion: the 1.03.00 drivers that shipped with the Voodoo4 4500 have not been that modified when compared to the latest driver build.

The results at 1600x1200x32 match the results found above.

Voodoo4 4500 - MDK2 Performance

Although the Voodoo4 4500 did not benefit from the driver update like the Voodoo5 5500 did in Quake III Arena, it remains crippled in MDK2. The initial release drivers, driver version 1.03.00, provide a 5% performance gain compared to the newer 1.04.01 drivers.

Once again, the Voodoo4 4500 seems to loose out in many ways with the newer drivers. There is still a loss of framerate in MDK2 at 1024x768x32, this time accounting for a 9% speed loss. It seems that there is not much to be gained in the case of the Voodoo4 4500 by upgrading the drivers, as there seems to be a bit lost.

Finally, at 1600x1200x32 we see a very slight performance gain from the updated drivers. Raising the framerate by 2% up to 5.1 FPS, the latest drivers seem to provide at least one point of benefit, although a very small one.

Voodoo4 4500 - Unreal Tournament Performance

As we saw in the case of the Voodoo5 5500, the updated drivers seem to have a positive effect on the minimum framerate that the card produces. In the case of the Voodoo4 4500, we actually see an improvement here, with the latest drivers performing 5% faster. Will this trend continue, providing one good reason to update one's driver?

Unfortunately, the performance increase does not seem to last. Once again, the two drivers perform identically.

Not much can be said with the above graphs, as the drivers result in no performance increase.

We finally see a performance increase again, this time occurring at 1600x1200x16 with the minimum framerate numbers. The updated drivers provide a 7% performance increase.

At the final resolution we test Unreal Tournament at, we see that the average framerate does not increase as a result of the updated drivers.

Voodoo4 4500 - 16-bit vs 32-bit Performance

Finally, it is time to look and see if 16-bit performance of the Voodoo4 4500 increases with the latest driver build.

At 1024x768, the Voodoo4 4500 could care less which drivers you use. Once again, the lack of performance difference between the latest drivers and the initial release drivers is most likely a result of the few builds between the Voodoo4 4500's release and the current drivers. It is too bad that the Voodoo4 4500 can not regain some lost ground like the Voodoo5 5500 was able to.

At 1600x1200 we also noticed that the Voodoo4 4500's 16-bit and 32-bit performance does not increase or decrease depending on the drivers used.

HSR Explained

On top of increased speed, various driver builds often introduce new features. A good video card company is always striving not only to improve driver speed but also to improve driver features. NVIDIA's Detonator series drivers provide a perfect example of this.

The Detonator drivers that support NVIDIA based cards always seem to be a work in progress. No matter what features are added or how much speed is gained, NVIDIA is always striving to produce more feature rich and powerful drivers. Take Detonator2 versus the newest Detonator3 drivers. Not only did NVIDIA increase speed dramatically with the latest drivers, they also introduced a host of new features, from Digital Vibrance Control to TwinView support.

Likewise, 3dfx seems to have followed in the footsteps of NVIDIA. Not only do the latest 1.04.01 drivers feature increased performance, they also contain a very exciting and often misunderstood "hidden" feature.

This feature is know as hidden surface removal, or HSR for short. Searching 3dfx's page reveals no information on the subject. In fact, even contacting 3dfx to discuss this new "feature" results in a "no comment" response. So what is this feature and what does it do?

3dfx's HSR driver setting does exactly what its name implies: removes hidden (or overwritten surfaces). Overdraw, the act of drawing polygons over existing polygons to render a scene, is a result of the immediate mode rendering that has been used since the 1960's to render a 3D scene. Let's take a look at how we described this form of rendering in our Imagination Technologies / STMicro PowerVR Series 3: Kyro review:

A traditional 3D accelerator processes each polygon as it is sent to the hardware, without any knowledge of the rest of the scene. Since there is no knowledge of the rest of the scene, every forward facing polygon must be shaded and textured. A z-buffer is used to store the depth of each pixel in the current back buffer. Each pixel of each polygon rendered must be checked against the z-buffer to determine if it is closer to the viewer than the pixel currently stored in the back buffer.

Checking against the z-buffer must be performed after the pixel is already shaded and textured. If a pixel turns out to be in front of the current pixel, the new pixel replaces (or is blended with in the case of transparency) the current pixel in the back buffer and the z-buffer depth updated. If the new pixel ends up behind the current pixel, the new pixel is thrown out and no changes are made to the back buffer (or blended in the case of transparency). When pixels are drawn for no reason, this is known as overdraw. Drawing the same pixel three times is equivalent to an overdraw of 3, which Imagination Technologies and STMicro claim is typical.

With the increasing game complexity and decreasing memory bandwidth, the overdraw encountered in traditional rendering systems is a very large problem. For example, an overdraw of 3 in a scene results in every polygon in a scene being overwritten (and thus hidden) an average of two times before the final visible polygon is visible. By eliminating polygons that are not visible to the user, not only is the memory bandwidth needed to render a scene decrease but the graphics processor has to work less. This means that a given scene with any amount of overdraw could be rendered faster if this overdraw is eliminated.

There are a few ways of attacking the overdraw problem that exists in immediate mode rendering systems. One approach is the tile rendering attack that PowerVR products have been using for quite some time now. Tile base rendering is described in depth in our Imagination Technologies / STMicro PowerVR Series 3: Kyro review, but essentially this rendering method eliminates overdraw by splitting a scene into groups known as display lists. Each item in the display list is then compared against others in order to find which item is on top (using the z-buffer) and only the visible area is textured. This feature of tile based rendering systems eliminates the overdraw problem described above.

Although there are many benefits to tile based rendering, there is one major problem. The problem is that this form of rendering requires a drastically different approach to rendering which requires not only new drivers but also a drastically new chip design. This makes the transition to a tile based rendering system extremely difficult to implement. Take PowerVR for example, who is finally realizing success with their 3rd generation tile based renderer after previous generations falling short of expectations and having various bugs.

The other approach to reduce overdraw and make scene rendering more efficient is to utilize a more efficient form of the immediate mode rendering that we are all used to. The potential gains from optimizations and the like are very large, as a feature that provides less overdraw and fewer memory hits could finally rid us of the memory bottlenecks that plague video cards currently.

One manufacturer, ATI, has chosen to include such optimizations in their most recent product. The ATI Radeon series cards all include what is called HyperZ in order to make more efficient use of the immediate mode rendering process. The entire process is described in detail in our ATI Radeon SDR review, but in essence the optimizations allow for more efficient memory access. ATI claims that the parts of HyperZ, Hierarchical Z, Z-Compression and Fast Z-Clear, combine to increase memory bandwidth by up to 20%.

Hierarchical Z is the part of ATI's HyperZ technology that most resembles a tile based rendering system. Hierarchical Z basically allows for the pixel being rendered to be checked against the z-buffer before actually hitting the pipeline. This means that much like a tile based rendering system, ATI's Radeon core can throw out pixels before actually having to render them. In our tests we did find that this feature increased performance to a noticeable extent and was measured to add 22% to performance.

The latest 3dfx drivers, version 1.04.01, seem to have some form of optimizations that prevent overdraw in a similar manner to ATI's solution. Called HSR, this setting may be enabled with a small registry tweak.

Enabling HSR

By far the easiest way to enable HSR as well as choose which setting you wish to run it at is by downloading nAuTiS' HSR registry tweak. Although the interface is great, getting it to work is a bit tricky.

The first thing one has to do is open the registry editor (regedit.exe) and open the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\Display\ folder. Under here, one should see at least a 0000 folder and perhaps a 0001 and higher folder. Open each one of these (left click once) until you find one that contains a key of "ProviderName" with a value of "3dfx Interactive, Inc." Note which folder this resides under.

If the folder that has the name 0000, then you are ready to skip to the next step and merge the registry. If not, then it is necessary to modify the HSR.reg file, changing the location line from the 0000 folder to the 000x folder under which the Voodoo series drivers lives. This file can be altered by right clicking on the .reg file and going to "edit." From there, the rest is self explanatory.

After the current folder is set in the HSR.reg file, the file is ready to be merged into the registry. Here it is necessary to note that this file, as well as HSR in general, will not work under Windows 2000 or Windows NT simply due to the fact that the Windows 2000 and NT driver builds are not up to the 1.04.01 build that includes the HSR support.

With that out of the way, once the HSR.reg file is clicked on, a new option will appear under the 3dfx Advanced Features tab of the display properties. The HSR option appears in the OpenGL/Glide header and is named "Hidden Surface Removal. Clicking on the current setting (4 by default) a menu box of choices pops up, with the options of "Disable, Conservative Tiling, Non-Aggressive Tiling, Semi-Aggressive Tiling, and Aggressive Tiling. Each one of these settings corresponds to a value in the registry, from 0 (disable) to 4 (aggressive tiling).

Throughout our testing we found it very easy to change the HSR setting for the card. One problem we encountered was the option of Hidden Surface Removal actually disappearing from the option list. The data (shown below) was still active in the registry, but the menu box could not be accessed. The easy way to fix this problem, we found, was to simply add the data to the registry again (by clicking on the HSR.reg file) and setting the setting to the desired one once again.

It should also be noted that the HSR setting has been reported to work in Voodoo3 series cards by copying over a Voodoo5 5500 .dll and renaming it to the Voodoo3 series DLL Unfortunately, we did not get a chance to try this out.

We do know how to enable it, but what does the hidden surface removal setting do? It is unknown the exact method that 3dfx uses to remove the non-visible surfaces, a problem that lies in the fact that 3dfx will not comment on this feature at all, but we do know that some users are experiencing rather large performance gains. Let's take a look and see what happens.

Problems with HSR

Before we get to the benchmarks, let's take a look at some of the problems that surfaced when enabling hidden surface removal.

As we mentioned before, the hidden surface removal setting in the 1.04.01 driver build is not only unofficial, it is hidden. Therefore, it is not a surprise that enabling the setting seems to cause a variety of problems. The main problem that appeared during testing was the removal of the wrong surfaces. As discussed before, the HSR setting is supposed to remove polygons that are not visible in a rendered scene, thus decreasing work and increasing rendering speed. Due to the immature nature of the HSR setting, it seems that the Voodoo drivers get confused on which surfaces to remove. This results in the removal of the front surface and the appearance of items that should be invisible. For example, when facing a wall with a room behind it, enabling HSR in some instances resulted in seeing items in the room behind the wall. As a picture is worth a thousand words, below are two examples of exactly what we saw.

A result of HSR problems. Note the fading of the floor. Click here to enlarge.

A result of HSR problems. Note the disappearance of the floor. Click here to enlarge.

As the above pictures show, surfaces that should be visible are replaced with those that should not be. The above pictures show the affects of improper surface removal on the floor, but the same problem was also noted in walls with rooms behind them. Also, the scene is not constantly rendered with the same surfaces missing, causing a flashing of sorts of the missing surfaces.

The second problem we noted under some HSR settings was very jumpy or choppy game play despite high FPS ratings. This means that in some cases (noted in the test results with an *) the FPS rating put out by the demo001 benchmark are not an accurate display of what the user will see.

The above pictures may be worth a thousand words, but a movie is worth even more. In order to fully understand what goes on when HSR causes problems, it is necessary to see exactly what is being rendered on the screen. In order to show this, we recorded a series of three 5 second movies that show the problems we experienced during gameplay. The first movie shows some of the lesser errors that improper HSR caused. The second movie shows some of the more serious errors that some HSR settings caused. Finally, the third movie shows the worst problems we experienced when using HSR.

We highly suggest that you download the above movies to get a realistic idea of what happens during gameplay under some HSR instances. Each movie is 1.86MB but is well worth the download.

The second problem that the current implementation of HSR consists of is the lack of support under any game but Quake III Arena. Although we expected the HSR settings to work in all OpenGL based games, our testing showed that not only did HSR not do anything under the D3D based Unreal Tournament, it also did nothing to our other OpenGL based game, MDK2.

Why this is we do not know, and since 3dfx refuses to comment on the matter, it may be quite some time before we understand why HSR is not supported under other OpenGL based games. Until then, we can see what kind of difference this early implementation of HSR results in under Quake III Arena.

Note: Throughout the benchmark graphs, one should pay attention to the *'s next to a number, if any. A single * means that the gameplay was relatively undesirable, with some see though surfaces at times. Two *'s (**) means that the gameplay was very jumpy with many see through textures, making gameplay very borderline and not desirable at all. Three *'s (***) means that gameplay was very jumpy with many see through textures and unplayable.

HSR 1: Conservative Tiling

The HSR setting of 1, called Conservative Tiling in the dropdown menu, is the most orthodox of the HSR settings. After setting both the Voodoo4 4500 and the Voodoo5 5500 to use this mode of hidden surface removal, we came up with the following results.

At an HSR setting of 1 (conservative tiling), both the Voodoo4 4500 and the Voodoo5 5500 produced no rendering problems. Although this is good, the performance increase paired with the HSR setting of 1 is relatively small. In the Voodoo5 5500, the HSR 1 setting did not improve performance at all. The same setting in the Voodoo4 4500 increased performance by 1.5 FPS, an increase of a mere 2%.

At 1024x768x32 the HSR setting of 1 increases performance to a large extent but also produced rendering problems. As noted previously, the single * next to the Voodoo5 5500's score means that the gameplay produced see through surfaces at times, producing some image quality problems. Although the image quality suffered, the FPS rating increased by 8%. In the case of the Voodoo4 4500, gameplay was affected more adversely, with the game becoming somewhat jumpy and misrendered polygons popping up more often. The setting here resulted in a 30% speed increase but left gameplay very undesirable.

At 1600x1200x32, the speed of both cards increased significantly but Quake III Arena became virtually unplayable. The speed increases shown demonstrate the potential of HSR, but the immature nature of this function in driver release 1.04.01 cause sever image problems.

Perhaps the most exciting result of our HSR 1 tests is the large increase in performance noted with FSAA 2x enabled. Although at 1024x768x32 we noted some image quality problems, the speed still increased by 25%. At 800x600x32 with an HSR setting of 1, we noticed no image quality problems and saw speed increase by a full 13%. Not too bad for a simple driver tweak.

HSR 2: Non-Aggressive Tiling

The second most aggressive HSR setting is an HSR of 2, named "Non-Aggressive Tiling" in the HSR.reg file. Let's see how this setting affected performance as well as gameplay.

Once again, pushing up the HSR setting resulted in a slight gain for the Voodoo4 4500 but no gain for the Voodoo5 5500. The Voodoo4 4500 was able to gain 7.6 FPS or 9% without any image quality problems.

At HSR 2 at 1024x768x32, we see that both the Voodoo4 4500 as well as the Voodoo5 5500 produce image quality problems, with the problems in the Voodoo4 4500 being worse than those in the Voodoo5 5500. Although we must take these results with a grain of salt because the game approaches unplayable at these settings, the Voodoo5 5500 gains 22% performance and the Voodoo4 4500 gains 87%.

At 1600x1200x32, both cards render unplayable games with an HSR setting of 2. It is too bad that the performance of the cards increases by 46% in the Voodoo5 5500 and 143% in the Voodoo4 4500.

Once again, the FSAA 2x results prove to be quite exciting. With FSAA enabled on the Voodoo5 5500, the card sees no image quality problems at 800x600x32 but performs 38% higher. At 1024x768x32 we noted some image problems but the speed of the card increased by 79%.

HSR 3: Semi-Aggressive

The HSR setting of 3 gets the name "Semi-Aggressive Tiling" in nAuTiS' driver tweak. Let's see what HSR 3 does to the performance of our two cards.

As seems to be the trend, only the crippled Voodoo4 4500 gets any gain from HSR at 640x480x32. The setting of HSR 3 produced no image quality problems and resulted in a 11%. The most likely reason that the only the Voodoo4 4500 realizes performance gains at 640x480x32 with HSR enabled is due to the fact that the Voodoo5 5500 is already performing at top speed here. Not suffering the same memory bandwidth limitations that occur in the Voodoo4 4500, as the Voodoo5 5500 essentially has double the memory bandwidth due to the two VSA-100 chips, the Voodoo5 5500 can not gain so much by removing unseen polygons.

With an HSR setting of 3, we notice that both the Voodoo5 5500 as well as the the Voodoo4 4500 have some image quality problems. In the case of the Voodoo5 5500, which suffers less than the Voodoo4 4500 when it comes to image problems, the performance of the card increased by 25%, bringing it up to GeForce2 GTS speeds. The performance of the Voodoo4 4500 rose by 132%, but the resulting images were not pretty.

Finally, at 1600x1200x32, both cards become unplayable with the HSR 3 setting. We have yet to see how accurate the Quake III Arena framerate counter is when the scene is as altered as it is at this resolution, but it does show a 184% speed increase for the Voodoo5 5500 and a 233% speed increase for the Voodoo4 4500.

Unfortunately with the HSR setting of 3 we were not able to run smoothly at 800x600x32 with FSAA 2x enabled, a resolution that we were quite excited to see improve drastically without any problems with the lower HSR settings. Here, the performance of the Voodoo5 5500 with FSAA in 2x mode increased by 51% but resulted in image problems. The only resolution where image problems were not present in this case was at 640x480x32, where performance increased by 10%.

HSR 4: Aggressive Tiling

The final and most aggressive HSR setting is HSR 4, named "Aggressive Tiling." Let's see what happens when HSR is turned up to the max.

Once again, we only see an improvement on the Voodoo4 4500 side at 640x480x32. This time the performance of the card increases by 11% with no image quality problems.

At 1024x768x32, no card escapes without image quality problems. The Voodoo5 5500 suffers less than the Voodoo4 4500, but both cards will produce undesirable results with an HSR setting of 4 at 1024x768x32. Here you can see that the Voodoo4 4500 actually clocked in faster than the Voodoo5 5500, but the image quality of the Voodoo4 4500 was severely impaired.

At the final resolution of 1600x1200x32, both the Voodoo5 5500 as well as the Voodoo4 4500 provided very exciting scores but as a result made Quake III look absolute horrible.

As we saw with the HSR setting of 3, an HSR setting of 4 only produces acceptable gameplay at 640x480x32 with FSAA 2x. At this resolution the performance of the Voodoo5 5500 increased 10%. All other resolutions produced image quality problems.

Conclusion

Not only do the most recent 1.04.01 drivers for the Voodoo4 and Voodoo5 cards increase performance across the board, they also include the exciting option of hidden surface removal. It is too bad that this feature does not quite yet appear to be in working mode.

As far as upgrading the drivers go, every Voodoo5 5500 owner should do this without question. A bit of performance is lost in MDK2, but the FSAA performance as well as the Unreal Tournament performance increases a noticeable amount, placing the Voodoo5 5500 closer to GeForce2 GTS speeds.

Voodoo4 4500 owners may want to think twice before installing the latest driver build. The older version 1.03.00 drivers provided essentially no performance increase in Unreal Tournament as well as Quake III Arena and resulted in a performance drop in MDK2. The only reason for Voodoo4 4500 owners to upgrade to this driver build would be to either take advantage of any bug fixes that may have been implemented and/or take advantage of hidden surface removal.

The hidden surface removal feature of the 1.04.01 driver build is quite exciting. Not only does it show that 3dfx has some interesting technology in the works for upcoming driver releases and cards, it also shows the huge potential behind this technology. The problem is that there are still quite a few bugs that need ironing out.

The user most likely wanting to use the current form of HSR is one who owns a Voodoo5 5500 and plays with FSAA 2x enabled at lower resolutions. We have shown that at 800x600x32, an HSR setting of 2 results in a 38% performance gain without causing any noticeable image quality problems.

The other area in which the current form of HSR appeals is at low resolutions when paired with a Voodoo4 4500 card. Our tests showed no image quality problems at 640x480x32 with HSR settings up to the maximum of 4 and it is likely that more conservative settings paired with the 800x600x32 resolution will result in increased performance with little image sacrifice.

With the discovery of the HSR setting in the Voodoo4 and 5 drivers, it brings up the possibility that other manufacturers can do the same thing with driver updates. There is no question that the 1.04.01 driver release results in large performance gains over the initial Voodoo5 5500 drivers, but it will take more than that for the Voodoo5 5500 to catch up to GeForce2 GTS speeds. If 3dfx can pull this off, putting HSR to work while still maintaining image quality, we may have quite a battle on our hands.

The problem is the lack of acknowledgment on 3dfx's side. By not explaining what exactly is going on as well as proclaiming that future driver releases will not possess this feature, they may be shielding themselves from another company stealing their technology but they are also hurting their current product line. From now until the HSR feature of the Voodoo4 4500 and Voodoo5 5500 is finalized we must play a waiting game, waiting to see exactly what 3dfx can do with this exciting technology. From the looks of it, we may have some powerful technology on the way soon from 3dfx.