Futuremark Announces Patch for 3DMark03

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

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


Uttar

 

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.

 

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, tu t'es vendu

Let's speak english, please

 

Hum, hum....

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.

 

Never

 

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......

 

Yep, I hope so, I feel that having to write english makes me more.... serious.....

Hey, and just imagine if Nicolas_b came here to post his reality shifts

 

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

 

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?

 

<laughs> Well, Mike Magee linked to the other info, and let's just say...in rather amusing fashion.

 

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.

 

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.

 

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.

If those aren't being thrown out at the first step I'd be very surprised.

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?

You are a truly sadistic man.

 

[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.

 

Do you think that, maybe, nV has a new driver that reimplements the cheats but keeps the previous version number?