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.
So what does the new "super driver" do?
 
It just filters all the algorithms/commands requested by 3dmark, and replaces them (if possible) by their own algorithms and commands.
 
As we can see this really results in a better 3dmark score - but: it only affects 3dmark 2003!
Not a single other game or application should see a performance increase by that.
 
Looks like nVidia is fooling people on 3DMark, at least they seem to give a wrong picture of the situation.
(my personal point of view)
 
But who knows, probably they'll do it that way with all upcoming games that seem to run too slow. (e.g. compared to Radeons)
And if you think about it seriously - as long as the games run fast and without any glitches and errors, would you care about the cheating?
 
Réponses :
 
Hilbert: I have to disagree with you there Kennung as this was the exact reason nVidia made this driver. Let me show you a statement from nVidia themselves I received last week regarding this exact topic:
We did that driver to show how easy it is to optimise for the benchmark and how the scores should not be taken at face value - I know the good sites, including yourself, understand the balance needed between synthetic and real world benchmarks, but a lot of sites take that benchmark to be the final word on GPU performance and our point is that it should only, if at all, be used as a background test and not a measure of actual game performance or for that matter DX9, given it's shortcomings in using true DX9 shaders.
All synthetic benchmarks are liable to be manipulated with drivers optimised for the benchmark ... this has happened since the early days of graphics benchmarking and will continue to occur. It is a moral responsibility for the graphics companies not to do this ... although there is also pressure since if they get caught cheating it will be bad for them (e.g. Quake vs Quack)
 
Kennung Eins:
The problem here, as far as I understood, is not, that it's just an optimized driver.
The whole program logic was bypassed!
And I ask myself: Why didn't nVidia talk like this before 3DMark 03 was released?  
But, be it. I'm quiet  
If we didn't learn it yet, today we have learned not to count on 3DMark 2003 (or ANY benchmark at all).
 
Hilbert: nVidia did not cover this up at all, in fact I was asked for a telephone conference by nVidia to allow them to explain this and their concerns regarding 3D Mark 03. The sites who used the 42.68 driver ALL have been briefed what nVIDIA had done to proof their point. Tommorow our GeForce FX review will go live, this site will include this info. Other sites who did not include this info made a choice not to post it. Now I ask you .. who's at fault here .. nVidia ? no way .. It's time to stop flaming nVIDIA people.

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

Au final, c'est nous qui allons ramasser les pots casses :
- soit des jeux pas optimises du tout (nivellement pour le bas) pour pas se taper deux moteurs 3D a ecrire
- soit des jeux optimises Standard DX9/OpenGL2 seulement
- soit des jeux optimises nVidia copyright standard, we fuck ze world and gimme your money ! © seulement
Ca c'est le pire des cas, certes. Mais bon, c'est pas bon signe