   HLSL, PS 3.0: texture lookup max? or other problem?
  hii'm using ps3.0 and have the following construct within a function (which is called directly from the ps main function):#define NUM 3while(!b){ .. for(i = 0; i < _NUM; ++i) {  .. } .. if(..)  b = true;}that works although it should be hard for the compiler to determine the loop count. but still no problem.now i want to make a texture lookup inside the loops:while(!b){ .. for(i = 0; i < j; ++i) {  v = tex2D(s, t);  .. } .. if(..)  b = true;}the compiler loops infinitely. after several minutes i abort the compilation. any ideas why this is happening? is there a maximum of texture lookups and the compiler is trying to determine how often they occur? it also happens if i put the tex lookup directly into the while loop outside the for loop. can anyone help? thanks in advance!btw: i tried the compiler flags /Gfp and /Vdrou   
  If it hits a particular problem with targetting your HLSL to the shader model it'll spit out error messages. You shouldn't just get it "hang" [oh]What SDK/compiler version are you trying this on? One of the older/"mature" D3D9 versions of fxc.exe or a newer/beta fxc10.exe?Even if your shader wont actually compile, I'd interpret a hung compilation as a broken compiler. It should at least return with a compiler error [smile]If you can repro it on the latest SDK you might want to try contacting MS (directx@microsoft.com) with the repro shader/details so they can check it out.hthJack   ;  hithat doesn't sound too good. i'm using the compiler shiped with the april 06 sdk... i also tried the 10 version... same problem.rou   ;  I've seen the HLSL compiler take on the order of 5 minutes to compile things when there are nested flow control constructs involved.  I suspect that they're using some inefficient optimization algorithm that breaks in this case.  What happens if you disable optimizations (/Od)  ?JB   ;  Remember that you can't do normal texture lookups inside of a dynamic branch.  You need to calculate the LOD outside of the while loop and set then use tex2Dlod to do the texture lookups.  I don't see why this would keep the compiler from spitting out an error message though.   ;Quote:Original post by jameswRemember that you can't do normal texture lookups inside of a dynamic branch.  You need to calculate the LOD outside of the while loop and set then use tex2Dlod to do the texture lookups.  I don't see why this would keep the compiler from spitting out an error message though.Why can't I do normal tex lookups in a dynamic branch? Is it a compiler issue? Can I avoid that problem by using assembler code? And where is the difference in using the LOD version? Could you please give some detailed infos on your suggestion? The idea of the whole loop is to do a dynamic number of texture lookups since I am using the texture as a data input (written in the app, read in the shader). Thanks for any further answers.rou   ;  ok. problem solved in an other thread. thanks for your help!rou   