Does the physical GPU chip/hardware only see one shader language?

[JHoxley]

Hi all,

I figure you guys know far too much about GPU's and the finer details of the hardware side of things to be healthy...

So, I work on the application side of things - I write my HLSL code and compile it to variations of 4 main targets (SM 1-4).

My general understanding is that the ATI/Nvidia drivers will translate what Direct3D feeds it into the appropriate binary/micro-code suitable for the GPU in the system. That the hardware will see a common set of GPU-specific instructions and not really have any knowledge of what shader model (be it HLSL or GLSL) or API it actually originated from.

The only case where it'd (possibly) know about any SM specifics is if the driver forced any restrictions on resolution and clamping.

Would that be a reasonable assumption?

This is kind of related to a bug I fixed today. Developed my code on an ATI chipset, everything was fine. Dropped it onto an NV card and it all went wrong. Bit of debugging later and it turns out that the NV implementation was correct according to the standards - it clamped SM1 outputs to [-1,+1] whereas the ATI implementation didn't.

Got me wondering about the IHV differences - does ATI just offload a number of instructions and leave it there and NV does the same but (where appropriate) clamp the results...

Anyone got any insight as to what that piece of silicon in my machine(s) actually end up seeing?

Cheers,
Jack

 

[Demirug]

Your GPU will always see the optimized binary code that the driver has generate. It doesn’t know anything about Shader models. Only the driver knows the rules and should make sure that the GPU will feed with the right codes that include all the rules.

But this binary code is not a common format like x86 assembler. Every GPU family have there own set and sometimes there are even differences in the same family. The instruction set of modern GPUs can be very complex as the ALUs/FPUs still support some of the old modifiers direct.

If you are interested in how shader hardware works there is a full description with all hardware registers of the rampage chip somewhere in the patent database. Ok it was only a DX8.0 chip but IMHO it is a good starting point.

 

[JHoxley]

Thanks for the reply - seems that my general understanding/assumption would be correct

I'm not too fussed about the details of the instructions that the drivers generate, just the rough overview.

To extend from what I originally posted...

My ps_1_4 shader generates the same output as a ps_2_0 shader when running on my ATI Radeon 9800. The same 1.4/2.0 shaders generate different results on an Nvidia 6600. So I wondered if ATI were just sending generic pixel-processing instructions to the GPU and ignoring the differences of shader models, yet Nvidia might have been sending additional instructions/data to get correct 1.4/2.0 differences... Extrapolate that a little further and it would (potentially) appear that the NV GPU knows the difference between an API-specific feature.

Cheers,
Jack

 

[Xmas]

The GPU does not know whether the shader it is executing was written for PS1.4 or PS2.0. But it seems the ATI compiler just forgets to add the saturate modifier on output for PS1.4.

 

[Colourless]

Have you checked the PixelShader1xMaxValue cap value? R3xx and R4xx cards have it set to 3.40282E+038.

 

[JHoxley]

But it seems the ATI compiler just forgets to add the saturate modifier on output for PS1.4.

Serves me right for making the foolish assumption that something that simple would follow the specification

Have you checked the PixelShader1xMaxValue cap value? R3xx and R4xx cards have it set to 3.40282E+038.

Nope, forgot about that one oops - I was vaguely aware of the ATI's SM1 hardware having higher precision somewhere but couldn't find the details of it when I ran a quick search for it.

Cheers,
Jack

 

[Xmas]

Actually I couldn't find anything on the range of the color output from the shader in the D3D docs.

 

[JHoxley]

Actually I couldn't find anything on the range of the color output from the shader in the D3D docs.

Finding stuff like this can be a bit of a challenge at times

From the ps_1_x page:

Direct3D 9 requires intermediate computations to maintain at least 8-bit precision for all surface formats. Both higher precision (12-bit) for in-stage math, and saturation to 8-bits between texture stages are recommended.

This page states that the valid range for r0 is "- PixelShader1xMaxValue to + PixelShader1xMaxValue", This page states that PixelShader1xMaxValue "must be >= 1.0 for any hardware that supports pixel shaders".

The CardCaps.xls listing seems to put all hardware at ranges sufficient to not cause my problem - so go figure...

Cheers,
Jack