Futuremark Announces Patch for 3DMark03

Uttar said:
BTW, regarding a way to beat NVIDIA at their own game if they want to continue cheating:
When reading the shader files, change them a bit randomly. A few easy and "annoying-for-nv" changes would be:

1) randomly change the name of registers ( search for R0 in the string, replace all instances by R3, all instances of R3 by R2, and so on )
2) Put NOP operations in the code randomly
3) Add "easy-to-optimize-by-driver" operations randomly, such as MUL R0,R0,1 or ADD R0,R0,0. If ATI's compiler can also do this ( and I know NVIDIA can ), do operations whose results are never checked again ( like, if in the end only R0, R1 and R2 are still used, do MUL R3, R1, R2 and never use R3 again ).

Just make sure you don't add too many and that it makes it goes beyond PS2.0. standards and can't compile, though!
All of these could be bypassed by NVIDIA, but it'd take an awful lot more time for them to fix it than for FutureMark to add them IMO.


Uttar
Think they'll sue you for damages for just suggesting those options? ;)
 
digitalwanderer said:
Think they'll sue you for damages for just suggesting those options? ;)

Nah, I'm sure they'll hire me just because they'll assume I'm the only one who knows how to bypass my own suggestions :p :LOL:

Kidding. Super easy to bypass; actually, it's easy to THINK how to bypass them, but I suspect it's harder to actually implement the bypass ( would have to go checking it another level, which makes it actually possible for future drivers to break the replacements themselves, without FM doing anything! So could be icky, and they may want not to go that way! )

Plus, I don't know... I suspect NVIDIA did consider sueing me or at least trying to stop me before I published ULE, when they didn't know what it was and feared the worst. I doubt they'd still want to now though.

And maybe I'm just being paranoid :p


Uttar
 
Uttar said:
Add "easy-to-optimize-by-driver" operations randomly, such as MUL R0,R0,1 or ADD R0,R0,0. If ATI's compiler can also do this ( and I know NVIDIA can ), do operations whose results are never checked again ( like, if in the end only R0, R1 and R2 are still used, do MUL R3, R1, R2 and never use R3 again ).
There is an old maxim in driver-writing circles: "We do not optimise for stupidity".

Of course, this is much more of a guideline than a rule. It tends to be restated as "We'd prefer not to have to optimise for stupidity" or maybe "There's a limit to how much effort we'll put in to optimise for stupidity".

I think it would be a bit unfair to rely on the compiler to cut daft code out - but using a technique like this strictly for R&D purposes is probably OK.
 
Uttar said:
sireric said:
No idea about the NV30, but your number makes no sense for the R300. What cache? There are so many. And none of them are even close to 500KB (not by a long shot).
I meant the total of all caches on the R300.
I wonder if instead of the term 'cache' your might mean 'on-chip memory' - cache being a specific use of on-chip memory?

If so, note that on-chip memory is a complex beast. It's a long way from being as simple as 'This chip has this much RAM'. One example would be the question "how many read and write ports does this bit have"?
 
Tridam said:
According to NVIDIA, NV35 has 256 quads in flight and 8 FP32 registers per quad.

-> 2048 FP32 registers -> 32 Ko de cache pour ces registres

Tridam, tu t'es vendu :eek:

Let's speak english, please :D
 
Uttar said:
Tridam said:
According to NVIDIA, NV35 has 256 quads in flight and 8 FP32 registers per quad.

-> 2048 FP32 registers -> 32 Ko de cache pour ces registres

Oui, bon, on parle tout les deux français, mais c'est pas pour ça qu'il faut pas parler anglais sur des forums anglais ;)

Hum, hum.... :idea:

A quand Beyond3D.fr ?
 
Nah, I don't want to see them continuing to "foil" more illegal optimizations at this point. They've established their ruleset and brought everything up to date--NOW they have to stand behind their statements and not waffle, which basically means talking with the IHV's a lot about problems, but ultimately not certifying any new drivers or updates which violate their terms.
 
cthellis42 said:
Nah, I don't want to see them continuing to "foil" more illegal optimizations at this point. They've established their ruleset and brought everything up to date--NOW they have to stand behind their statements and not waffle, which basically means talking with the IHV's a lot about problems, but ultimately not certifying any new drivers or updates which violate their terms.

Yep, and since nVIDIA is in the beta program, normally, nVIDIA should have been aware of the dezoptimisation process some times ago.... That returns us to the question of why the damage control was so poor......
 
Uttar said:
BTW, regarding a way to beat NVIDIA at their own game if they want to continue cheating:
When reading the shader files, change them a bit randomly. A few easy and "annoying-for-nv" changes would be:

1) randomly change the name of registers ( search for R0 in the string, replace all instances by R3, all instances of R3 by R2, and so on )
Disregarding the other two points for a second, I'd like to expand upon the "random" idea.
Don't fully randomize each run. Use a deterministic RNG, and change its seed once every two weeks.

That way, an enterprising shader replacement department (;)) might be tricked into thinking they've won - yet they didn't :devilish:
 
Im sorry for bringing this up again, but from knowledge of 3d mark 03s ps2.0 test do you think that the gffx can legitimatly using full precision be getting the results it is getting?

I mean is the radeon under performing in this test? or is there some reason why the gffx would perform well on this particular test without app specific optimization?
 
I wonder how the driver department at Nvidia feels about having to hand-code shaders to cheat at benchmarks.

I would think there would be a serious morale problem, what with having to spend so much time on short-lived and fragile application and scene-specific replacements as opposed to working on general performance enhancements and bug fixes.
 
ByteMe said:
At what point will the driver employee's (Nvidia) get feed up and tell their boss to go suck on an egg?
Once they find better jobs, preferably in the same area if they have families or other strong social ties. Meanwhile they'll tell themselves that "everyone else is doing it", and that it "doesn't really hurt anyone" or even that they "keep their colleagues at nVidia employed".
 
If ATI needed some driver programmers this would be their chance to get a bunch.


Maybe they should form a union and tell nvidia they won't program like that anymore.
 
Uttar said:
BTW, regarding a way to beat NVIDIA at their own game if they want to continue cheating:
When reading the shader files, change them a bit randomly. A few easy and "annoying-for-nv" changes would be:

1) randomly change the name of registers ( search for R0 in the string, replace all instances by R3, all instances of R3 by R2, and so on )
You would sort of think that renumbering (even if it's to change the first used register to R0, the second used to R1) would be an easy process for a "compiler" to defeat that trick - the "Signatures" would then match.
2) Put NOP operations in the code randomly
If those aren't being thrown out at the first step I'd be very surprised.
3) Add "easy-to-optimize-by-driver" operations randomly, such as MUL R0,R0,1 or ADD R0,R0,0. If ATI's compiler can also do this ( and I know NVIDIA can ), do operations whose results are never checked again ( like, if in the end only R0, R1 and R2 are still used, do MUL R3, R1, R2 and never use R3 again ).
I'm not entirely sure those would be easy to fix - at least not in the vertex shader. The constants get put in their own area and, at any time, the application can replace the constant with another value - e.g. replace the +0 with +3.1415... etc. For example, how could you tell that the add wasn't used, say, to increment an animation key-frame position and it had just set up 0 as the default?

zeckensack said:
Disregarding the other two points for a second, I'd like to expand upon the "random" idea.
Don't fully randomize each run. Use a deterministic RNG, and change its seed once every two weeks.

That way, an enterprising shader replacement department (;)) might be tricked into thinking they've won - yet they didn't :devilish:
You are a truly sadistic man.
 
XForce said:
Simon F said:
How about this answer -
(DISCLAIMER This is all speculation of course...)

#3 A hypothetical company currently has a poor quality compiler but it probably expects it to improve in future revisions. To make their system look better in the interim (until they can make the compiler more intelligent) they put in some customised, hand-coded examples. FM changed their code so it no longer matches those examples.
To be frank, 1 1/2 years ago, I would have considered this, too, but I don't think NV deserves the benefit of doubt or speculation anymore, to put it nicely.

This whole soap opera appears to me like if a company produced a car that only can do left hand turns due to an mistake during steering wheel developement.
[Disclaimer: Again this is all speculation on my part...]
I suspect that, maybe, they put a lot of of their original software development effort into CG thinking/hoping that it would be adopted as the standard. Instead, low-level and/or HLSL seems to be the norm (which uses an intermediate format) and so it may be that they are hastily trying to catch up.
 
Back
Top