I've recently run into an issue with shader compilation.
I have managed to pretty much boil it down to occurring when I try to sample a texture (or to be specific, a Texture2DArray) from a standalone function that is called from my pixel shader. Whenever I do this, the shader compiler seemingly gets stuck in an infinite loop. If it threw me an error, OK, but since that doesn't happen it feels like this may not be an actually invalid operation?
Furthermore, if I sample the texture array from the pixel shader itself (it's main function) everything compiles quickly and cleanly just as usual.
I don't want it there though since doing it that way would mean having to move a lot of should-be reusable code into several pixel shaders.
Edit - did some more tests while writing this:
It appears that you can indeed sample the texture array from another function, and that the problem rather arises from this happening inside a for-loop. The loop is used to iterate over light sources, so it has a dynamic number of iterations, and the texture lookup is of a shadow map. It should also be noted that the loop isn't inside the function itself, rather it goes something like this (pseudo code to highlight what seems to be the issue):
float4 PS_EntryPoint(vs_out IN): Sv_Target {
// ...
CalculateLightInfluence();
// ...
}
void CalculateLightInfluence(output parameters) {
// ...
for(uint l = 0; l < NumSpotLights; l++)
CalculateSpotLightInfluence(l);
// ...
}
void CalculateSpotLightInfluence(uint lightId) {
// ...
// If the below line is left as-is, the shader compiler seems to get stuck in an infinite loop.
// If outcommented the shader works as intended (except for the depth test of course).
float depth = ShadowMap.Sample(ShadowMapSampler, float3(lp.xy, spotLight[lightId].shadowMapId));
// ...
}
So my question basically boils down to whether it is some kind of known limitation that you can't sample textures from within such a loop?
For clarity, yes, the shadow map array is bound to all used shader stages, even if the mentioned helper-function that fails to compile is only ever called from the pixel shader.
Or may it be caused by something else failing, such as running out of instruction slots? Or does the compiler just get completely lost trying to unroll the for-loop with a dynamic number of iterations? But if so, why doesn't this happen when I remove the sampling instruction from there?
It seems that either of these cases, if true, really should make the D3DXCompileShader return some error code rather than just get stuck, but this is the first time I've run into this kind of issue so I thought I would ask.
Thanks in advance for any pointers.
