Okay I see what your saying now about this.  Its one thing for a driver to be monitoring code to ensure that things work they way they need to work
		
		
	 
DirectX and OpenGL are actually designed to work this way.
In the OpenGL case, the entire compiler is inside the driver, so you pass a C-like text-file of source code directly to the driver, and the driver has complete control over how it compiles and optimizes the code. It doesn't matter at all how it does it, as long as it produces results that are within the OpenGL specs.
DirectX is slightly different, but the effect is the same. In their case, Microsoft supplies the compiler, and it outputs an intermediate bytecode file, very similar to how Java and .NET work.
The driver will then take this bytecode and compile and optimize it for the underlying hardware.
Basically the advantage of this method is that there will not be issues with source-code level compatibilities... and you can cut off some of the overhead at runtime by using pre-compiled bytecode in your application, so you don't have to parse and optimize text files entirely.
	
		
	
	
		
		
			So in my example before, it is the case then that the software is requesting 16bit precision, and the hardware can execute that 16bit precision just fine, but the driver is then dropping the precision just to inflate the performance numbers at a sacrifice of quality that neither the developer or the customer is necessarily aware of.
		
		
	 
Exactly. End-users and reviewers are so used to just 'turning up all the settings', that they generally run everything with AI on, but aren't fully aware of the impact it may have.
There is nothing wrong with that in and of itself... I mean, I've always used AI at the highest settings on my Radeons. I think they are generally a good trade-off between performance and image quality. Likewise I always run my GeForces with AF optimizations and such on.
However, when you want to benchmark against nVidia's products, I think nVidia is right about pointing out this AI issue, and how you should conduct apples-to-apples comparisons.
It's not exactly a new trick either, I'd like to add.
As soon as the first cards arrived with S3TC, drivers quickly appeared which would 'magically' enable texture compression and give massively increased texturing bandwidth in applications that had no support for texture compression whatsoever.
I know that the FutureMark guys were looking at one of those cards in the multitexturing benchmark and were going "Hum... hang on a minute... the scores this card is getting are physically impossible, it just doesn't have that much fillrate".
Then they figured out what was going on: the driver had replaced their 32-bit texture with a 16-bit compressed version, which greatly reduced memory bandwidth, and allowed the card to reach inflated fillrate scores, which were beyond the theoretical fillrate peak, because the fillrate was still calculated with the assumption that the textures were 32-bit.