D44.03 shader code

[OpenGL guy]

And if your HW was not so sensitive to resource usage, then I would say it's more complex, not less.

Well, the itanium folks would probably get all in a hissy about that.

Let's not go there

Beyond thatl, what are your opinions for what these shader snippets are?

In my previous post I mentioned that I thought they could be shader replacements, but after thinking about it on the way home from work I've decided that's not a good guess. For example, if you wanted to replace an incoming shader with a new shader, why not just replace it with fully compiled/optimized machine code? Unless people think nvidia chips can parse text Anyway, my current thought is they are text versions of shaders being detected.

 

[RussSchultz]

Anyway, my current thought is they are text versions of shaders being detected.

A reasonable option, though it seems to me if they're going to store the shaders are tokens, why don't they detect them in that form, also?

Recognizing tokens seems like a more foolproof way to defeat folks like futuremark who would attempt to bypass the shader detection--white space, and capitolization and/or comments wouldn't matter anymore.

 

[DemoCoder]

Detecting via absolute textual representation of the shader wouldn't make sense either, since even white space could throw it off.

If you were going to do detection that way, you wouldn't store the text, you'd store a HASH of the text (but even better, a code based on the parse tree representation) and compare hash codes, similar to the way virus segments are detected. Or, you'd atleast use regular expressions.

Is it possible these are some kind of "warmup" shaders that the driver executes before doing the real workload to prime caches or pipelines?

Or even more mundane, is it possible they are leftovers from debugging modes?

 

[DemoCoder]

Detecting via absolute textual representation of the shader wouldn't make sense either, since even white space could throw it off.

If you were going to do detection that way, you wouldn't store the text, you'd store a HASH of the text (but even better, a code based on the parse tree representation) and compare hash codes, similar to the way virus segments are detected. Or, you'd atleast use regular expressions.

Is it possible these are some kind of "warmup" shaders that the driver executes before doing the real workload to prime caches or pipelines?

Or even more mundane, is it possible they are leftovers from debugging modes?

I noticed that the ATI drivers for example still continue some symbolic information like references to c:\work\377area\mai\377driver...

 

[OpenGL guy]

Anyway, my current thought is they are text versions of shaders being detected.

A reasonable option, though it seems to me if they're going to store the shaders are tokens, why don't they detect them in that form, also?

Recognizing tokens seems like a more foolproof way to defeat folks like futuremark who would attempt to bypass the shader detection--white space, and capitolization and/or comments wouldn't matter anymore.

As mentioned previously, these are apparently OpenGL shaders. In D3D, the driver doesn't get the text version of the shader, but in OpenGL the shader is coming directly from the application so it should be in text form.

 

[Typedef Enum]

Doom III?

Maybe that's why John said he didn't like nVidia's benchmark configuration.

 

[jjayb]

Doom 3 is already optimized for the fx cards though. I don't see why they would need to put in any more optimizations for it.

 

[Arun]

Frankly, I don't know whether some FX12 units are shared between Fragment and Geometry in the NV3x. I'm just saying it's *possible*

Then I'm going to kick in and say it's not possible. FX12 for transform is just too little precision for transform and simply doesn't have anywhere near the range we need for geometry. Fp16 would probably have to little precision too, definitely too small range. Fp24? Could maybe work, but would think that all vendors are already doing things at 32bit in the vertex pipeline.

I'm perfectly aware that FX12 is not sufficent for transforming vertices
I think I said it somewhere else, sadly forgot to say it here I believe: My guess is that those FX12 units are used exclusively for the lighting. Not for the transforms.

Yes, I've got that nasty habit of including both transform & lighting in "geometry"... Sorry for the confusion!


Uttar

 

[Humus]

If it doesn't work for transform, why would it work for lighting? It's even more floating point intensive.

 

[Kombatant]

Doom 3 is already optimized for the fx cards though. I don't see why they would need to put in any more optimizations for it.

It's usually "the more the merrier" and you know it

 

[digitalwanderer]

Could it be optimizations aimed at the Q3 engines?

 

[Tridam]

Could it be optimizations aimed at the Q3 engines?

It could be the case for an engine or another.

Optimizations for an engine are good optimizations if they don't kill quality.

But optimizations for a demo that run on an engine like Q3 one's is bad optimizations. It's just cheating.

 

[RussSchultz]

As mentioned previously, these are apparently OpenGL shaders. In D3D, the driver doesn't get the text version of the shader, but in OpenGL the shader is coming directly from the application so it should be in text form.

Sure, a text compare would be the easiest method--but its also easily detected and easily thwarted. I'd hope they'd be able to cover their tracks easier than that.

 

[Colourless]

What is it easiest to write shaderes in? Text or an array of possibly variable sized opcodes? The text of course.

Nvidia need not be doing text compares. They could be compiling these shaders, and comparing the compled shaders, not the text shaders. This would be a more reliable method.

 

[Kombatant]

I posted this in another thread as well (HellB knows where ). Here's an nVidia paper (for the rest of us who can't tell by first glance) which clearly shows that this is OpenGL shader code:

http://developer.nvidia.com/docs/IO/1352/ATT/Vertex_Shader_API_Diffs.pdf

 

[darkblu]

Detecting via absolute textual representation of the shader wouldn't make sense either, since even white space could throw it off.

If you were going to do detection that way, you wouldn't store the text, you'd store a HASH of the text (but even better, a code based on the parse tree representation) and compare hash codes, similar to the way virus segments are detected. Or, you'd atleast use regular expressions.

i absolutely agree with you. YET keep in mind you compare a hash derived from the parse tree generated in the context of given parser, namely the parser in the present drivers. so you may also want to make sure that that present parser is properly factored in in the comparison as well. IOW, if you want to detect a particular shader A, you have best chances to detect shader A if you pass its 'reference' source through the present parser, compute the hash from the resulting token tree, then check if the user's shader under scrutiny happens to produce the same token tree hash-wise under the present parser. i hope i'm making enough sense (had too long a workday)

[edit] i see colourless is on the same track of thinking as me [/edit]

I noticed that the ATI drivers for example still continue some symbolic information like references to c:\work\377area\mai\377driver...

apropos, as long as that's not symbolic info about locals or publics it doesn't matter that much - some compilers like storing sources locations in the objects for peculiar reasons.

 

[Arun]

I recieved an interesting e-mail yesterday.
That person investigated multiple other driver revisions, and while he did not give further information, after personally looking at it, it seems fairly obvious the Detonators 40 introduced *most* of the shader code.

I don't have access to FTP here ( and probably won't for a few days, managed to burn 768MB of RAM in a day and I'm not on my primary computer ) - so I'll simply put one of the multiple driver revisions he sent me here:

%!VP1.0
MOV R1,v[0];
MOV o[COL0],v[3] : RCP R1.w,R1.w;
MOV o[COL1],v[4];
MOV o[FOGC],v[4].w;
MUL R1,R1,c[58];
MOV o[PSIZ],v[1].x;
ADD o[HPOS],R1,c[59];
MUL o[TEX0],v[9],c[15].xyzz;
MUL o[TEX1],v[10],c[23].xyzz;
MUL o[TEX2],v[11],c[31].xyzz;
MUL o[TEX3],v[12],c[39].xyzz;

%!VP1.0
MOV R1,v[0];
MOV o[COL0],v[3] : RCP R1.w,R1.w;
MOV o[COL1],v[4];
MOV o[FOGC],R1.z;
MUL R1,R1,c[58];
MOV o[PSIZ],v[1].x;
ADD o[HPOS],R1,c[59];
MUL o[TEX0],v[9],c[15].xyzz;
MUL o[TEX1],v[10],c[23].xyzz;
MUL o[TEX2],v[11],c[31].xyzz;
MUL o[TEX3],v[12],c[39].xyzz;

%!VP1.0
MOV R1,v[0];
MOV o[COL0],v[3] : RCP R1.w,R1.w;
MOV o[COL1],v[4];
MOV o[FOGC],R1.w;
MUL R1,R1,c[58];
MOV o[PSIZ],v[1].x;
ADD o[HPOS],R1,c[59];
MUL o[TEX0],v[9],c[15].xyzz;
MUL o[TEX1],v[10],c[23].xyzz;
MUL o[TEX2],v[11],c[31].xyzz;
MUL o[TEX3],v[12],c[39].xyzz;

The 40.71 files seem fairly identical to the current ones ( didn't look at the details though, but the length sure is roughly the same )

Now, considering nVidia's claim of performance boost in the case of the Detonators 40 was mostly shader-related, does anyone have an idea about this?


Uttar

 

[Popnfresh]

All the shaders posted -- with the exception of the first incomplete fragment and the last simple pass-throughs -- are just subtle variations on figuring out the size of a point sprite aka. 'billboarded polygon'.

The three in Uttar's message about all are exactly the same except for where they get thier fogging value from.

The first:

MOV o[FOGC],v[4].w;

takes the fog value from the alpha of the specular channel.

The second

MOV o[FOGC],R1.z;

takes it from the Z of the vertex position.

The third

MOV o[FOGC],R1.w;

takes it from the W coordinate of the vertex postion.


None of the code fragments even do anything so complex as transforming the vertex by a matrix - you couldn't use them for normal geometry. They don't even do hardware transform and lighting.

You may all now ignore this post and go back to your random speculation.