HLSL's, Cg and the RenderMonkey

High Level Shading Languages

After all that, I can summarise by saying that HLSLs are to VS (vertex shader)/ PS (pixel shader) assembly, what C is to CPU assembly. For example, take a quick look at the following code, which carries out a directional lighting calculation and outputs it to the diffuse color register.

In VS we get:

mov r0, c0 // light direction

mov r1, v2 // normal
dp3 r2, r0, r1 // dot product
mov r3, c1 // move 0, 0, 0, 0 into r3
max r0, r2, r3 // clamp lighting to 0
mov oD0, r0 // output diffuse colour

Or, with mov elimination:

dp3 r0, c0, v2

max oD0, r0, c1

Now, in an HLSL, you'll have something like this:

float4 lightdirection = constant[0];

OUT.Diffuse = max( dp3(IN.Normal, lightdirection), 0 );

So, why is an HLSL better again? Well basically, you can tell what it's doing. If you read the vertex shader code above, it's not particularly obvious what's going on. If a directional light equation wasn't completely obvious, you'd have no real idea why that code was doing what it was doing. In the HLSL example, it's fairly obvious that we're calculating the lighting using the normal and the light direction, clamping it to 0, and outputting this value in the Diffuse component of the output. Code clarity becomes increasingly important as we start looking at shaders with >50 instructions. At this point, an assembly shader can become extremely cryptic; the HLSL version will be human readable, which means less bugs and easier maintenance and editing.

The platform independence for HLSLs has yet to be tested. And for the moment, each new generation of hardware is very different from the generation that came before. Although it might be possible to write shaders that run on DX8 and DX9, I can't imagine that this wouldn't be crippling the DX9 implementation in some way. Once HLSLs have been around for a few years, this should be a much bigger plus.