Think they'll sue you for damages for just suggesting those options?Uttar said:
Futuremark Announces Patch for 3DMark03
- Thread starter Nick[FM]
- Start date
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
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".Uttar said:
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?Uttar said:
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"?
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.
Disregarding the other two points for a second, I'd like to expand upon the "random" idea.Uttar said:
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?
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.
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.
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".ByteMe said:
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.Uttar said:
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.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 (
[Disclaimer: Again this is all speculation on my part...]XForce said:
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.
Similar threads
