[tcchiu]

Does the ATI or nVidia driver unroll the loops (SM 2.0 flow control)?

[Simon F]

Originally Posted by tcchiu

Does the ATI or nVidia driver unroll the loops (SM 2.0 flow control)?

IIRC, given the simplicity of SM2.0 looping, it may not be necessary, perhaps apart from very small loops.

In fact, it may be counter-productive since those loops are controlled by constants which could be changed frequently. Unrolling the loop would mean you may end up reloading new code rather than just tweaking a constant.

[Chalnoth]

Originally Posted by tcchiu

Does the ATI or nVidia driver unroll the loops (SM 2.0 flow control)?

If the loops can be unrolled, they are. Basically, any loop that doesn't depend upon per-vertex or per-pixel information is unrolled. This is simply because it is typically assumed that many pixels and vertices will be drawn per branch, and the branching itself will incur a performance hit. Thus it makes more sense to just eat that little bit of extra data swapping that is needed when the new shader is loaded, instead of eating some constant performance hit for each pixel/vertex.

Since hardware like the R3xx and R4xx don't support any branching at all, this means that all loops must be unrolled. Similarly, the NV3x doesn't support pixel shader branching, and any pixel shader loops must therefore be unrolled.

[DemoCoder]

It is the HLSL compiler in SM2.0 which unrolls the loops, not the driver. There is no loop instruction in SM2.0 assembly.

[Ostsol]

Originally Posted by DemoCoder

It is the HLSL compiler in SM2.0 which unrolls the loops, not the driver. There is no loop instruction in SM2.0 assembly.

Well, not for pixel shaders, but for vertex shaders there seems to be. . .

VS 2.0 Instructions

[MfA]

Zero overhead looping isn't exactly rocket science, there is really no need to unroll loops on a sane architecture.

[DemoCoder]

Originally Posted by Ostsol

Well, not for pixel shaders, but for vertex shaders there seems to be. . .

VS 2.0 Instructions

Yeah, I make the common mistake of using SM2.0 interchangeably with PS2.0. For me, the most interesting changes in shader model are in the PS. Vertex texturing was nice, but until geometry shading is added, the vertex stuff is pretty boring, since I find vertex lighting boring and skinning is commodity stuff now

[Remage]

Is there a way to disable loop unrolling (in the HLSL compiler, SM3.0)?
I'd like to achieve the shortest possible compiled shader binaries, for a 4 kbytes intro/demo. At compile time I compile the shaders with a tool that uses D3DXCompileShaderFromFile(), and store the result.
The vertex/pixel shaders contain 2-3 loops, for a fixed number of lights, texture stages, procedural texcoord generators, etc. The HLSL compiler just unrolls the whole thing, producing a "huge" shader...
D3DXSHADER_PREFER_FLOW_CONTROL doesn't help.

[mhouston]

Make the loop bounds dynamic so it can't unroll and pass in the loop bounds via constants.

For example, using this for 8 lights

for(i=0; i<8, i++)
{
..
}

for(i=0;i<lights;i++)
{
...
}

and pass in 'lights' as a shader constant at shader bind.

[Humus]

Use the [loop] attribute on loops and [branch] on branches.

float4 main(float4 texCoord: TEXCOORD0) : COLOR {
    [loop]
    for (int i = 0; i < 8; i++){
        texCoord += 3.7 * texCoord.wzyx;
    }
    return texCoord;
}

Before:

ps_3_0
def c0, 3.70000005, 0, 0, 0
dcl_texcoord v0
mad r0, v0.wzyx, c0.x, v0
mad r0, r0.wzyx, c0.x, r0
mad r0, r0.wzyx, c0.x, r0
mad r0, r0.wzyx, c0.x, r0
mad r0, r0.wzyx, c0.x, r0
mad r0, r0.wzyx, c0.x, r0
mad r0, r0.wzyx, c0.x, r0
mad oC0, r0.wzyx, c0.x, r0

After:

ps_3_0
def c0, 0, 3.70000005, 0, 0
defi i0, 8, 0, 0, 0
dcl_texcoord v0
mov r0, v0
rep i0
 mad r0, r0.wzyx, c0.y, r0
endrep
mov oC0, r0

I think you'll have to use a recent version of the SDK though for the compiler to support these [] attributes.

[mhouston]

Yes, but the vendor compilers will sometimes unroll the loop themselves if it's statically analyzable... Making it dynamic will avoid this, unless they recompile on parameter changes.

[Remage]

Originally Posted by Humus

Use the [loop] attribute on loops and [branch] on branches.
I think you'll have to use a recent version of the SDK though for the compiler to support these [] attributes.

Thanks, that kinda helps... It seems to work, my test shader has a real loop now.
However, it doesn't work with my original shader (that compiled nicely with the dec.2006 sdk, but had unrolled loops), now I have a lot of strange error messages from the HLSL compiler...

It seems "PixelShader" and "VertexShader" became some kind of keywords (shouldn't these be case sensitive?), at least the compiler gives an "error X3000: syntax error: unexpected token 'VertexShader'" message when I name my functions like that.

Another one: "error X5300: Invalid register number: 11. Max allowed for v# register is 9.", in the line where the halfvector is calculated (pixelshader code cropped, I quote the whole shader if that helps):

	float diffuse_light = 0;
	float specular_light = 0;
	float3 view_normal = normalize( input.ViewNormal );
	[loop]
	for ( int i = 0; i < 2; i++ )
	{
		float3 view_light = normalize( input.ViewLights[ i ] );
		diffuse_light += saturate( dot( view_normal, view_light ));
		float3 halfvector = normalize( view_light - normalize( input.Position.xyz ));
		specular_light += pow( dot( view_normal, halfvector ), 64.0 );
	}

The compilation stops here, so I can't check what would the resulting shader be.

Any ideas why I get this error message?

[Dee.cz]

Originally Posted by tcchiu

Does the ATI or nVidia driver unroll the loops (SM 2.0 flow control)?

IMHO, GLSL fixed length loops with access to array element were broken on ATI for long time, and possibly still are, so it's necessary to unroll them manually in source code.