dorbie,
As for the screen capture, it's rather ill-specified how some of this is supposed to work. Microsoft has not ever specified, and is not likely to ever specify, how GDI interacts with AA. Worse, using the filtered image can cause serious problems, too; so "fixing" this may cause other problems. The driver behavior was not ideal, not by any means, but it would be hard to call it "wrong". Also, PrintScreen screenshots being inaccurate is nothing new. PrintScreen doesn't capture overlays, and in fact MS would probably have a fit if it did (copy protection and all)...
 
And I already told you that we *are* going to fix this, didn't I? So no need to get all worked up. I just wish certain web sites would, oh, post corrections or something... kind of like how newspapers often print corrections when they print news articles that have mistakes in them.
 
 
As for everything else...
 
If 3DMark's algorithm was part of a synthetic vertex program benchmark, that might be OK. However, it's not presented as such. It's presented as a gaming benchmark, and it's presented as even being comparable to what Doom3 does, and certainly as being a reasonably representative shadow-volume-employing game. However, it is grossly incomparable to Doom3, and it is definitely a very, very poor way for any game to implement shadow volumes.
 
This isn't in any way comparable to how some developers get all paranoid about "T&L doesn't let me output intermediate vertices". That was always a stupid complaint, and now it's even a false complaint -- there are ways to do this by using an appropriate vertex/fragment program plus techniques like PDR.
 
First of all, in this case, that previous problem is taken to an extreme. This is not some app that, say, draws a model with 2 rendering passes and has to skin twice; it uses a *very* large number of rendering passes, and the skinning program is complicated, *and* the shadow volume stuff is particularly bad in how much skinning it does.
 
Second, there are far better ways for the app to accomplish the same thing. (Skinning on the CPU is not the only one!)
 
But third, *because* the benchmark does *so much* stupid and wasteful work, the best way for us to win the benchmark down the road is to put in incredibly convoluted driver logic that -- in short -- detects everything stupid that the app is doing, and reimplements it using a smarter/faster algorithm, all behind the app's back. I'll leave thinking of the possible ways we could do this up to you; suffice it to say that implementing such code will help 3DMark03 and 3DMark03 *only*, at the expense of our time and at the cost of making our driver quite a bit bigger and buggier.
 
The dumber and more popular the benchmark, the worse the driver benchmarksmanship that is required. The more driver benchmarksmanship, the less valuable the benchmark.
 
And at least if it was a game, such benchmarksmanship would improve people's gaming experience. People who like Quake 3 engine games (and there are a bunch of those games) have undoubtedly benefited from the driver tuning we and ATI and others have done for the Quake 3 engine. I'm sure the same will be true for UT2003 and for Doom 3, and it's been true for other popular game benchmarks in the past.
 
But what gamer benefits from benchmarksmanship targeted at 3DMark03?
 
Bad but popular benchmarks hurt everyone. The primary issue is not whether 3DMark03 is unfair to NVIDIA or unfair to ATI or too geometry-heavy or whatever. (Although a benchmark that is unrealistically geometry-heavy could also be argued to be a bad gaming benchmark, too, and as promoting bad hardware design -- if no real app wants that much geometry power, then it forces us to spend too many transistors there.) The issue, as I see it, is benchmarksmanship. (Combined, in part, with Futuremark's business model.)
 
- Matt