Futuremark Announces Patch for 3DMark03

[Simon F]

Um. . . ok. . . Shader code is tossed to the video card through the driver. From what I've learned during my time at this forum, the GPU itself cannot interpret shader code by itself. It requires the shader code to be compiled by the driver into a form usable by the GPU, just like assembler has to be compiled into a binary format usable by the CPU.

My guess is that MS were originally expecting the HW to be a close-ish match to the "low level" shader code and so this would have just been an assembler. It hasn't turned out that way and so you need a very intelligent assembler, for all intents and purposes, "a compiler", to get high performance out of the hardware. It appears that one vendor is a bit behind in that technology (compounded, perhaps, by the possibility that their HW isn't as powerful as their competitor either)

As such, compilation occurs via CPU power anyway. However, assuming compilation takes place on the GPU, how would this be done?

It's not going to happen (not unless the GPU includes a CPU as powerful at conditional code as the main processor in which case Intel and AMD are out of business)

 

[Deathlike2]

How can a hand tuned shader be not specific to a particular application?

Beats me, but it sure sounds like NVidia wants you to use the same shader in YOUR application too

It is highly unlikely that the "same shader" would be used in two different applications....

 

[Tridam]

I've tried v330 and v340 shaders in another application. They showed exactly the same execution speed. So NVIDIA is doing replacement of these shaders ONLY in 3Dmark03. If a game uses the same shaders it won't have the enhancement.

 

[Exxtreme]

I've tried v330 and v340 shaders in another application. They showed exactly the same execution speed. So NVIDIA is doing replacement of these shaders ONLY in 3Dmark03. If a game uses the same shaders it won't have the enhancement.

Very good work and thanks for the info.

 

[Deathlike2]

This is a semi-related thought into this discussion... as this is how I feel the potential results would be...

1) NVidia on its track of shader replacement for their so-called "unified compiler" (as we all know isn't) will actually hold up on its word on its "advanced algorithms to defeat anti-detection mechanisms" as some version of the Det 40s (probably 44.67) have encryptions in the driver itself...

2) Futuremark will probably be worked up trying to defeat these mechanisms... we can only imagine potential lawsuits over COMMON terminology (which NVidia has no understanding of apparently)... possibly the Det 52.16s will be removed entirely if consumer demand is high enough (Dell or other Futuremark members)... of course Futuremark could just collapse if all their beta members leave...

3) Developers are probably going to be the ones most screwed over by this. Some of them may plan to do their own anti-detect mechanisms (for benchmarking purposes) and since NVidia striving to ensure developers use NVidia hand-coded shaders or just force it upon them... you may see them speak out more vocally as they do now. Either that... or they may actually succumb to let NVidia do their shader work... as bad as that may sound.

This is a lose-lose situation for developers.

I don't see any sort of light at the end of NVidia's tunnel.

 

[CorwinB]

I've tried v330 and v340 shaders in another application. They showed exactly the same execution speed. So NVIDIA is doing replacement of these shaders ONLY in 3Dmark03. If a game uses the same shaders it won't have the enhancement.

Thanks for the testing, Damien !

So the "unified compiler" does not only recognize specific shaders, but shaders when run in a given application ? This is getting better by the minute... I'd like to see Nvidia wiggle their way out of this one. They seem to have pushed the Fast Forward key on their Damage Control panel, and now their PR guys and their various proxies are all over the Web spewing incompatible lies and BS. I guess they all need to do some coherency check, because that random compiler-related stuff is going to hurt them a lot more than the lost 3DM points in the long term, IMHO...

Oh, and Damien, would you mind renaming your test application to "3DMark2003.exe" ? (or whatever the exe name, I don't have it here)

 

[nggalai]

Hi Damien,

I've tried v330 and v340 shaders in another application. They showed exactly the same execution speed. So NVIDIA is doing replacement of these shaders ONLY in 3Dmark03. If a game uses the same shaders it won't have the enhancement.

Thank you! That's all wrapped up, then. Well, unless somebody comes up with the GPU World Conspiracy Theory (tm), once more. i.e.

"no, that's not ALL [company] did with their latest [product], they actively disabled [IHV 1]'s [stupid marketing term] to make [IHV 1] look worse than they are. In turn, [company] were payed off by [large OEM], who also invested large amounts of money into [IHV 2] and thus ensured [IHV 2] will back [company]'s claims!"

OK. time for yet another coffee. Thanks, again, Damien for that sweet piece of work.

93,
-Sascha.rb

 

[Ostsol]

Perhaps I'm confused. . . Are you guys implying that NVidia's Universal Compiler is simply working on a per-application basis, swapping shaders with hand-tuned version? That would imply that such a cheat is getting through the 3dMark03 patch, which seems unlikely given the performance drop in the vertex shader test. After all, if shader detection and replacement worked for pixel shaders, would it not also work for vertex shaders? I'll hold to the theory that the patch is working as it is supposed to and that NVidia's Universal Compiler is working as it is supposed to (dynamic and not specific to any applications). By this theory, NVidia removed their pixel shader replacements a while ago and the good pixel shader performance that we are currently seeing is honest.

 

[andypski]

My guess is that MS were originally expecting the HW to be a close-ish match to the "low level" shader code and so this would have just been an assembler. It hasn't turned out that way and so you need a very intelligent assembler, for all intents and purposes, "a compiler", to get high performance out of the hardware. It appears that one vendor is a bit behind in that technology (compounded, perhaps, by the possibility that their HW isn't as powerful as their competitor either)

Unfortunately it appears that with the aid of some vigorous 'information' spreading it is easy to give people the wrong idea as to just who is behind in terms of technology - I guess this is the price we pay for working in an industry that is highly technical and not easily understood...

A technology that one company thinks is such a fundamental and obvious necessity that it is in basically since day one might therefore hardly be commented on (after all - it just works happily away in the background giving great performance), whereas when another company trumpets it from the rooftops after finally producing their own version of the same technology a day late and a dollar short it might make some people think they're 'innovating'.

Live and learn I guess...

Any compiler that relies on recognising code sequences from benchmarks and replacing them for higher performance can hardly be regarded as innovative by anyone with knowledge of computer history, since this has been done (and generally frowned upon) for many years. Of course this was sometimes just to show that compiler A produced faster code than a competing compiler B on the same platform, but the principle is the same. A compiler that is relying on being 'smart' to produce fast output under pretty much all circumstances without being twitchy would strike me as far more innovative than any hypothetical compiler whose operation could be severely compromised or disabled by flipping a couple of register names around.

If I released a true compiler (ie. one that wasn't relying on recognising programs and replacing them with hand-coded versions) that was so twitchy that swapping two registers over halved the performance then I might expect knowledgable people to be fairly ruthless - they might say something like - "Do you suck? Because if you suck, just get up and say you suck."

I also wouldn't have thought that developers would like a twitchy compiler very much, since then a minor alteration in their shaders could produce a big change in their application performance. Of course, if this hypothetical compiler was really relying on shader recognition and replacement to get high performance then you wouldn't get this behaviour during the development process - everything would probably just be slow all the time. The only way to get a big performance gain for your end users might then be to go all-out to try to become a popular benchmark - better start adding benchmarking modes to avoid customer disappointment kiddies .

 

[CorwinB]

If I released a true compiler (ie. one that wasn't relying on recognising programs and replacing them with hand-coded versions) that was so twitchy that swapping two registers over halved the performance then I might expect knowledgable people to be fairly ruthless - they might say something like - "Do you suck? Because if you suck, just get up and say you suck."

That one is a classic.

 

[Trawler]

...I might expect knowledgable people to be fairly ruthless - they might say something like - "Do you suck? Because if you suck, just get up and say you suck."

You've just made my day. Thanks for that!

 

[digitalwanderer]

If I released a true compiler (ie. one that wasn't relying on recognising programs and replacing them with hand-coded versions) that was so twitchy that swapping two registers over halved the performance then I might expect knowledgable people to be fairly ruthless - they might say something like - "Do you suck? Because if you suck, just get up and say you suck."

That one is a classic.

Agreed, thanks Andy!

 

[Dave Baumann]

The was a quote from the Wired NVIDIA article - it was reported that Huang has said this in some meetings.

 

[MuFu]

Perhaps I'm confused. . . Are you guys implying that NVidia's Universal Compiler is simply working on a per-application basis, swapping shaders with hand-tuned version?

Derek Perez has actually said that this is part of what it does, outright.

The was a quote from the Wired NVIDIA article - it was reported that Huang has said this in some meetings.

LOL. I wonder if the minutes included "admission of suck-factor"?

MuFu.

 

[Arun]

Wait, wait, wait...

Are you guys implying the compiler is nothing but fraud? Not AFAIK.

The real "unified compiler" can do the following thing:
- Reduce register usage by: reusing registers* and using swizzle**.
- Reorder instructions with the goal of exploiting parallelism ( Doing 2 TEX operations in a row as much as possible, for example )***.

*: Already done to an extent in the Detonator FX and 45 series.
**: Naive example of reducing register usage thanks to Swizzle: If, for two registers, you only access .xy - then it is possible to only use one register, by making the second register actually be the .zw part of the first register.
***: Fully introduced in the Det50s.

NVIDIA PR and Marketing however, seems to have decided to include "hand-made shader replacements" into their definition of the "unified compiler" technology. I suspect that in the case "hand-made shaders" are found to replace the standard shader, the real "unified compiler" technology is not used, as these shaders are already considered optimal.

This implies that:
1) NVIDIA will now describe their unified compiler technology as a mix of automatic and manual shader optimizations with "no IQ degradations".
2) In the Detonator50s, many new techniques for automatic shader optimizations were added in the compiler. Such a compiler already existed, but in a very primitive form, in older driver sets. That was roughly similar to ATI having had a basic compiler in their drivers since the 3.6. release.
3) According to NVIDIA, any application preventing them from using "homemade shader replacements" disables their "Unified Compiler". In reality, it only disables part of it, and this part is exactly as FutureMark describes; it's pure and simple application detection, as prohibited by their guidelines.


Hope that makes it clearer!


Uttar

 

[davefb]

i agree with uttar,, but it's absolutely obvious that actually swapping shaders AND ONLY IF THE SHADER IS IN A SPECIFIC APP !!! is diabolical afaik.......

-dave-

be interesting to see what the compiler could get that shader down to,, if we saw that i bet we'd be frothing about how good nv were instead ( maybe)

 

[tb]

i agree with uttar,, but it's absolutely obvious that actually swapping shaders AND ONLY IF THE SHADER IS IN A SPECIFIC APP !!! is diabolical afaik.......

-dave-

be interesting to see what the compiler could get that shader down to,, if we saw that i bet we'd be frothing about how good nv were instead ( maybe)

Even it would not be app specific - How many apps use the same shader? What about a unified shader library for all developers

Thomas

 

[digitalwanderer]

3) According to NVIDIA, any application preventing them from using "homemade shader replacements" disables their "Unified Compiler". In reality, it only disables part of it, and this part is exactly as FutureMark describes; it's pure and simple application detection, as prohibited by their guidelines.

So the Unified Compiler is legit/legal/whatever, but nVidia is trying to include app specific shader replacement as part of it?

Isn't that rather specifically against Futuremark's rules?

 

[Arun]

So the Unified Compiler is legit/legal/whatever, but nVidia is trying to include app specific shader replacement as part of it?

Yep. My point is that the core UC ( Unified Compiler ) technology is legit, and really works. But obviously, applications can still benefit from specific shader replacement.
What I suspect, and that part is really speculation, is that NVIDIA's PR and Marketing has decided, possibly with backing of engineering or possibly not, to include the shader replacement as part of THEIR definition of the UC.
That's why I'm talking of "real" UC5 ( UC Technology ) and "overly aggressive" UCT.

Isn't that rather specifically against Futuremark's rules?

It is. But trying the move to include non-legal optimizations in their definition of the UCT is a smart, although risky one. If it works, that means the "common public" and certain reviewers ( *cough* Kyle *cough* ) will believe everything associated with the term UCT is legit, and that no IQ losses and application detection happen under such conditions.

But that's just my take on it, of course.


Uttar

EDIT, BTW:
Looking at Wolfbar's statement:

According to my information patch 340 disables the GPU compiler. The compiler has to run on the CPU instead resulting in code harder to digest and taking away 20% of the performance.

Replace "GPU compiler" by "hardcoded shader replacements" and "The compiler (that) has to run on the CPU" by "NVIDIA's general purpose Unified Compiler Technology is used instead on the CPU,".
And you'll realize his statement made an awful lot more sense than what it seemed to originally.
"GPU Compiler" would be some BS NVIDIA gave to Gainward and AIBs in general in order to keep face.

 

[Bouncing Zabaglione Bros.]

3) According to NVIDIA, any application preventing them from using "homemade shader replacements" disables their "Unified Compiler". In reality, it only disables part of it, and this part is exactly as FutureMark describes; it's pure and simple application detection, as prohibited by their guidelines.

So the Unified Compiler is legit/legal/whatever, but nVidia is trying to include app specific shader replacement as part of it?

Isn't that rather specifically against Futuremark's rules?

Nvidia is just trying to blur the lines again. This way they can claim that shader replacement with hand-tuned shaders is as valid as a genuine compiler. They do this by continuing to link the two very different techniques together by way of misusing known terminology. Just the usual FUD from the Nvidia BS department.

Yes the shader replacement is against Futuremark's rules, which is why they block it by changing the shader code, thus breaking Nvidia's app/shader detection.