   HLSL: for-loop, compiler can't predict number of loops
  HiA similar problem to mine was discussed here: http://tinyurl.com/m7j7v but i'm still having the problem:in a pixel shader 3.0 (render target fx_2_0, the technique compiles ps_3_0) i'm doing something like this:for(int i = 0; i < iNum; ++i){...}where iNum is actually read from a texture:iNum = (int)tex2D(g_SomeSampler, float2(0.0, 0.0)).x;The compiler does not want to compile this:error X3511: loop does not appear to terminate in a timely manner (1024 iterations)I understandi that it can not predict the content of the variable and therefor does not want to compile my code. My question: how can i convince it? I tried to clamp the varialbe before using t:iNum = clamp(iNum, 1, 10);or something like this:if(iNum > 10) iNum = 10;The compiler still does not compile. If I use a global (uniform) variable it works, although the compiler can't know that variable's range either:g_iNum;...for(int i = 0; i < g_iNum; ++i)   // works{...}Is it a compiler issue or am I doing something wrong and just don't see it? I know, you'll say: "Why don't you use a uniform variable?". Let's just say it's a more general question since I'm using the shader more generally. Thanks for all answers in advance.rou[Edited by - rouaiha on May 24, 2006 11:34:33 AM]
  maybe I'm missing something..a sampled fragment will be clamped from 0 to 1 (unless its a floating point texture), so how can you use a number less than 1 in a for loop? you would have to multiply by 10 or something..   ;  If you're truly wanting condiditonal for loop execution -- make sure you're compiling your shader with the /Gfp flag to indicate to the comipler that you want it to prefer and use flow control constructs.Also, to help the compiler determine the maximum number of itterations -- I've seen people suggest using the modulo operator as in:for( int i = 0; i < g_nSomeVar % SOME_MAX_VALUE; i++ ){...}   ;Quote:Original post by Matt Aufderheidemaybe I'm missing something..a sampled fragment will be clamped from 0 to 1 (unless its a floating point texture), so how can you use a number less than 1 in a for loop? you would have to multiply by 10 or something..HiForgot to mention... I'm using floating point textures and convert the value to int :)rou   ;Quote:Original post by Brian LawsonIf you're truly wanting condiditonal for loop execution -- make sure you're compiling your shader with the /Gfp flag to indicate to the comipler that you want it to prefer and use flow control constructs.I've tried that already - doesn't change anything.Quote:Also, to help the compiler determine the maximum number of itterations -- I've seen people suggest using the modulo operator as in:for( int i = 0; i < g_nSomeVar % SOME_MAX_VALUE; i++ ){...}Hm. I will try that one. Thank you.rou   ;  Ok. Thanks again. I tried it with the modulo and it worked. Looks a bit strange... but ok. Still i wonder if it shouldn't be possible to do something like this:iNum = clamp(iNum, 1, 10);for(i = 0; i < iNum; ++i){...}But it seems like the compiler just doesn't check that although (in my eyes) this would be the better way. Nevermind.rou   ;Quote:Original post by rouaihaOk. Thanks again. I tried it with the modulo and it worked. Looks a bit strange... but ok. Still i wonder if it shouldn't be possible to do something like this:iNum = clamp(iNum, 1, 10);for(i = 0; i < iNum; ++i){...}But it seems like the compiler just doesn't check that although (in my eyes) this would be the better way. Nevermind.rouits possible to clamp, usefor(i = 0; i< MAX_VALUE;i++){    if(i<iNum)    {    ...    }}all other possibilities to write it will result in the same compiled code, cause ps2_0 cannot do dynamic branching, it has to loop a specific count of times that is known on compiletime like MAX_VALUE.;  but i'm using ps_3_0 which should support dynamic branching.rou   ;There's no particular reason why fxc can't generate a dynamic loop in that case.  The only reason it doesn't is because it isn't a very well-written compiler.   ;Quote:Original post by jbarcz1There's no particular reason why fxc can't generate a dynamic loop in that case.  The only reason it doesn't is because it isn't a very well-written compiler.yeah.. i'm having some trouble with it. see my other post:linkrou   