I've lifted the shader code from the det 44.03's. I won't post it directly for obvious reasons, but if any shader heads want a copy to look over...
D44.03 shader code
- Thread starter BoardBonobo
- Start date
Well for about three revisions now their drivers have been full of shader code. I just stripped it all out, I have no idea as to whether it has any relevance to the the 3dmark thing. I just thought somebody might be interested in having a look. 
Just rapidly browsed through them ( he sent them to me by PM )
And frankly, it's impossible to know exactly what they do, since they're using constants and stuff - by themselves, they don't mean anything IMO.
However, it's easy to realize they're all ( or at least, 99% of them, since I only looked quite rapidly ) VS programs. And none of them seem like very complex ones, either...
So I ask: why would nVidia hardcode simple vertex programs, with probably little or no optimization opportunity.
Well, according to FutureMark, the static clip planes are activated whenever a specific shader is detected.
And the number of shaders ( 10+ ) makes me think this is not limited to 3DMark 2003's Game 4.
So, should those indeed be detection mechanisms ( and frankly, I've got no idea, they could be anything ) - well, we're in some deep trouble here...
BTW, BoardBonobo, you didn't say me if you wanted me to host the thing at NFI
Uttar
And frankly, it's impossible to know exactly what they do, since they're using constants and stuff - by themselves, they don't mean anything IMO.
However, it's easy to realize they're all ( or at least, 99% of them, since I only looked quite rapidly ) VS programs. And none of them seem like very complex ones, either...
So I ask: why would nVidia hardcode simple vertex programs, with probably little or no optimization opportunity.
Well, according to FutureMark, the static clip planes are activated whenever a specific shader is detected.
And the number of shaders ( 10+ ) makes me think this is not limited to 3DMark 2003's Game 4.
So, should those indeed be detection mechanisms ( and frankly, I've got no idea, they could be anything ) - well, we're in some deep trouble here...
BTW, BoardBonobo, you didn't say me if you wanted me to host the thing at NFI
Uttar
Run the popular benchmarks. Strip out the code, then re-run the benchmarks. See what benchmarks are affected if any.
In particular, I'd like to see Shadermark run with and without this shader code as it mysteriously doubled performance with these drivers.
I'd like to see splinter cell run also.
In particular, I'd like to see Shadermark run with and without this shader code as it mysteriously doubled performance with these drivers.
I'd like to see splinter cell run also.
YeuEmMaiMai
Regular
wow you have 32 bit percision hardware and you have to use driver hacks to lower it to 16, 12, INTX or whatever just to compete with your competitor.......
I'll bet that
1. no one picks up on it
2. Kyle will be very quite or come up with a nVidia PR prepared statement.
I'll bet that
1. no one picks up on it
2. Kyle will be very quite or come up with a nVidia PR prepared statement.
YeuEmMaiMai
Regular
YOu know I for one have to seriously question weither or not the nV3X design is a good overall solution. The way things are turning out to be in the drivers makes me uderstand that it is a bad bad bad design....if it was a good or very good design, why would one need to use all of these driver hacks?
YeuEmMaiMai said:
I hope you're wrong YeuEm, if this pans out it should be picked up by everyone!
Methinks I'm gonna go take a quick check in on the most asshatted one...
Uttar said:BTW, BoardBonobo, you didn't say me if you wanted me to host the thing at NFI
Uttar
You can if you want but I think itmay be dangerous territory, after all they are proprietery code and belong to someone...
Uttar said:
OMMFG!!! What a smoking gun, what iron-clad evidence! <pause>
What does it mean? :?
pocketmoon_
Newcomer
could be that fixed function pipeline is (partially) implemented using shaders now.
OpenGL guy
Veteran
Sure, but you shouldn't need to store every possible fixed function shader in your driver code. Do you know how many possible fixed function shaders there are when you support 8 fixed-function texture stages?pocketmoon_ said:
Except for the very first one, they all look pretty innocent. The first one may be innocent too but its hard to tell without knowing what some of the constant registers are seeded with.
For instance this:
%!VP1.0
MAIN:
MOV o[HPOS],v[0];
MOV o[TEX0],v[8];
MOV o[TEX1],v[9];
MOV o[TEX2],v[10];
MOV o[TEX3],v[11];
MOV o[TEX4],v[12];
MOV o[TEX5],v[13];
MOV o[TEX6],v[14];
MOV o[TEX7],v[15];
END,
basically just passes a vertex through without doing anything to it. v[0] is input vertex position and HPOS is the output position. TEX# just pass through texture coordinates.
Some other ones are simple vertex lit w/specular and fog calculations. v[3] and v[4] are input diffuse and specular colour with COL0 and COL1 the corresponding outputs.
---
edit:
oh yeah, o[PSIZ] is point size. I'd guess that there is no fixed-function for doing point size and point sprites are emulated using vertex programs. Most of the programs seem to deal with point sprites.
For instance this:
%!VP1.0
MAIN:
MOV o[HPOS],v[0];
MOV o[TEX0],v[8];
MOV o[TEX1],v[9];
MOV o[TEX2],v[10];
MOV o[TEX3],v[11];
MOV o[TEX4],v[12];
MOV o[TEX5],v[13];
MOV o[TEX6],v[14];
MOV o[TEX7],v[15];
END,
basically just passes a vertex through without doing anything to it. v[0] is input vertex position and HPOS is the output position. TEX# just pass through texture coordinates.
Some other ones are simple vertex lit w/specular and fog calculations. v[3] and v[4] are input diffuse and specular colour with COL0 and COL1 the corresponding outputs.
---
edit:
oh yeah, o[PSIZ] is point size. I'd guess that there is no fixed-function for doing point size and point sprites are emulated using vertex programs. Most of the programs seem to deal with point sprites.
Hellbinder
Banned
Yes but that does not explain why they need to be hardcoded into the Driver.