MOST OF YOU ARE probably familiar by now with the controversy surrounding the current drivers for ATI’s Radeon 8500 card. It’s become quite clear, thanks to this article at the HardOCP, that ATI is “optimizing” for better performance in Quake III Arenaand, most importantly, for the Quake III timedemo benchmarks that hardware review sites like us use to evaluate 3D cards. Kyle Bennett at the HardOCP found that replacing every instance of “quake” with “quack” in the Quake III executable changed the Radeon 8500’s performance in the game substantially.
The folks at 3DCenter.de followed Kyle’s trail and discovered that, on the Radeon 8500, “Quack 3” produces much better image qualitytexture quality in particularthan Quake III. The FiringSquad observed the same behavoir, only they did so in English.
With the publication of these articles, it became a matter of public record that ATI was intentionally sacrificing image quality in Quake III for better benchmark scores. The issue, as far as I was concerned, was settled: ATI was busted.
Only a couple of questions remained: What did ATI have to say for themselves? And how exactly did they implement their cheat? Now we have answers for both.
Yesterday, the FiringSquad asked ATI for their side of the story. ATI’s response was interesting. I suggest you go read through the whole interview at the FiringSquad if you haven’t already. It’s all worth reading.
I’d like to focus on one particular bit of ATI’s explanation of the situation. It reads like so:
Most of our optimizations for Quake 3 and other applications have no impact at all on image quality, and therefore it would be pointless to allow users disable them. The current RADEON 8500 driver revision has an issue that prevents it from correctly interpreting the texture quality slider setting in Quake 3. This issue will be corrected in the next driver release.
Note that the texture quality setting is just one of many possible ways that users can increase image quality in Quake 3 at the expense of performance; forcing on anisotropic filtering or disabling texture compression are alternative methods. It is also important to note that the image quality obtained using all of the standard image settings in Quake 3 (fastest, fast, normal, and high quality) can be observed to be equal to or better than any competing product (try it!); it is only in the special case of selecting “high quality” AND turning the texture quality slider up to the highest setting that a potential discrepancy appears.
Like some of ATI’s previous PR statements, this answer is packed with tricky twists and turns: reader beware. Truth be told, ATI is doing something more than simply misinterpreting the texture quality slider setting. After a little digging, we’ve zeroed in on what they’re doing.
The cheat in action
First, some background. Like Kyle, I was able to modify the Quake III executable to purge it of all instances of the word “quake”. In my case, I simply used a hex editor’s search-and-replace function to replace all instances of “uake” with “uaff”. The result? My own hot new game: quaff3.exe.
I tested quaff3.exe with the Radeon 6.13.3276 drivers on the following setup:
Processor: AMD Athlon XP 1800+ – 1.53GHz on a 266MHz (DDR) bus
Motherboard: Gigabyte GA7-DX
Memory: 256MB PC2100 DDR SDRAM
Audio: Creative SoundBlaster Live!
Storage: IBM 75GXP 30.5GB 7200RPM ATA/100 hard drive
OS: Windows XP Professional
Running quaff3.exe with the Radeon 8500 produces quite decent image quality. Like so:
Running the original quake3.exe isn’t nearly as pretty. Check it out:
It’s not hard to see why the Radeon 8500 produces better benchmarks with this driver “issue” doing its thing. The amount of detailed texture data the card has to throw around is much lower.
How the cheat works
The big question has been this: How was ATI able to produce textures that looked a little worse than the standard “high quality” textures, but in close-up detail screenshots, still looked better than the next notch down the slider?
The answer: They are futzing with the mip map level of detail settings in the card’s driver whenever the Quake III executable is running. Mip mapslower resolution versions of textures used to avoid texture shimmer when textured objects are far awayare everywhere; they’re the product of good ol’ bilinear filtering. ATI is simply playing with them. When the quake3.exe executable is detected, the Radeon 8500 drivers radically alter the card’s mip map level of detail settings.
To show you what I mean, I’ve used Quake III’s “r_colormiplevels” feature, which colorizes the various mip maps in an image in order to show us what’s happening. Here’s how the mip maps look with quaff3.exe:
That is as expected; the GeForce3 produces very similar results. Now, here are the mip maps in quake3.exe, when ATI’s “optimizations” are in full effect:
ATI has moved the threshhold for mip mapping so close to the user’s point of view that mip maps overwhelm the entire image. Even the counters reading “100” at the bottom of the screen are mip maps instead of full-quality textures (notice how they are tinted red). In fact, when Quake III is loading a level with ATI’s “optimizations,” even the game’s static splash screens turn red when r_colormiplevels is enabled.
This is something different than the simple misinterpretation of a texture quality slider. To establish that fact, I’ve included screenshots from quake3.exe and quaff3.exe for the Radeon 8500, plus comparative GeForce3 shots, on the next three pages. You can see for yourself what effect the slider has with each card at each of the game’s four texture quality settings.
As you can see, mip mapping is usually affected by texture quality settings, but only a little bit. ATI’s hyper-aggressive “optimization” of mip maps goes well beyond that. Also, quake3.exe shows more aggressive mip mapping than quaff3.exe with at least three of Quake III’s four texture quality settings: high, medium, and low.
(It’s also worth noting that the Radeon 8500’s mip maps are are bounded by two lines that intersect at the middle of the screen. The GeForce3’s mip map boundaries come in a smooth arc determined by their distance from the user’s point of view. But I’m getting ahead of myself.)
I find it very difficult to believe that what ATI was doing here wasn’t 100% intentional. Judge for yourself, but personally, I find the evidence mighty compelling.