Tons of ieq/add/or instructions for array indexing in pixel shader loop (D3D 11.0, PS model 5.0)

Question

First of all, I have to apologize for the long code samples, but their content is not so important, I just wanted to give as much info as I can. Besides they are really simple and I tried to comment as much as possible.
I'm working on a pixel shader doing deferred lighting of the frame (Direct3D feature level 11.0, PS
model 5.0, IDE - Visual Studio 2013, OS - Windows 8.1 x64). I noticed some huge FPS drops when I add light sources to the scene, and the more sources I add, the bigger performance impact is. After many hours
of trying to find the problem, experimenting and checking compiled pixel shader ASM's, I found out that at some moment after I comment / uncomment some lines (or event line) my output ASM changes dramatically. I won't put here all the code, of course, but
here's simplified part of the point lighting in HLSL, so you could imagine the structure of the lighting algorithm:
// Total amount of color that pixel receives from all the point light sources.
float3 totalPointLightColor = { 0.0f, 0.0f, 0.0f };
// Loop through the active light sources.
[loop] for (uint i = 0; i < g_scene.pointLightCount; i++)
// xyz - vector from light source to pixel.
// w - the length of that vector.
float4 fromLightToPixel;
fromLightToPixel.xyz = worldPos - g_pointLights[i].position.xyz;
fromLightToPixel.w = length(fromLightToPixel.xyz);
// Check max light distance here (skip pixel if it is too far).
if (fromLightToPixel.w > g_pointLights[i].farZ)
continue;
// Normalize direction vector.
fromLightToPixel.xyz = normalize(fromLightToPixel.xyz);
// Angle between the pixel normal and light direction.
float lightIntensity = saturate(dot(normal, -fromLightToPixel.xyz));
// Check that light comes not from behind of the pixel surface.
if (lightIntensity <= 0.0f)
continue;
// If light casts shadows, process shadow map and get amount of light the pixel receives.
// THIS LINE IS MENTIONED IN MY QUESTION BELOW.
if (g_pointLights[i].shadowMapIndex >= 0)
// Here was shadow map check, but I removed it and nothing really changed - the problem remained even with no code here.
// Calculate the amount of light at the pixel from distance and angle and modify intensity.
lightIntensity *= g_pointLights[i].brightness / (fromLightToPixel.w * fromLightToPixel.w);
// Add this light's color to the total amount of light the pixel receives from point lights.
totalPointLightColor += lightIntensity * g_pointLights[i].color.rgb;
I compile shaders with D3DCompileFromFile() method, using the following flags:
shaderFlags = D3DCOMPILE_ENABLE_STRICTNESS | D3DCOMPILE_DEBUG
| D3DCOMPILE_SKIP_OPTIMIZATION | D3DCOMPILE_PREFER_FLOW_CONTROL;
I tried to compile in release config with the following flags:
shaderFlags = D3DCOMPILE_ENABLE_STRICTNESS | D3DCOMPILE_OPTIMIZATION_LEVEL3;
But nothing seriously changes - only a couple less ASM instructions here and there, the main problem still remained. I should add that I have zero to none knowledge of ASM, and understand what's happening mostly thanks to comments Visual Studio / FXC generates
in debug compilation mode.
So, when I compile my whole deferred shader (including the part above), I get
414 instructions in ASM, and performance is fine. If I uncomment only 1 line with CAPSED comment in the section above (which actually does nothing, as you can see), I get
476 instructions, and I get huge FPS hiccups. When I check output ASM code, I can clearly see, that the line I uncommented produces no code in ASM at all, but somehow it makes many parts of compiled shader to change.
For example, the loop above with commented line looks like the following in ASM:
# Loop starts.
loop
# Loop index check and increment, as I can understand.
uge r6.w, r5.w, cb0[1].x
breakc_nz r6.w
imul null, r6.w, r5.w, l(3)
# Calculate <fromLightToPixel>.
# cb6 - constant buffer that stores point lights.
# Array access is done simply via [] operator.
add r10.xyz, r3.xyzx, -cb6[r6.w + 1].xyzx
dp3 r7.w, r10.xyzx, r10.xyzx
sqrt r8.w, r7.w
# Distance check.
lt r8.w, cb6[r6.w + 1].w, r8.w
if_nz r8.w
iadd r8.w, r5.w, l(1)
mov r5.w, r8.w
continue
endif
# Normalization.
rsq r8.w, r7.w
mul r10.xyz, r8.wwww, r10.xyzx
# Calculate <lightIntensity>.
dp3_sat r8.w, r1.xywx, -r10.xyzx
# Check <lightIntensity>.
ge r9.w, l(0.000000), r8.w
if_nz r9.w
iadd r9.w, r5.w, l(1) // r9.w <- i
mov r5.w, r9.w // r5.w <- i
continue
endif
# Update <lightIntensity>. Note [] operator.
div r7.w, cb6[r6.w + 0].w, r7.w
mul r7.w, r7.w, r8.w
# etc.
endloop
When I
uncomment that 1 line, the ASM is growing heavily (by 62 instructions!), and this is how it starts to look like:
# Loop starts.
loop
# Loop index check, but no <imul> instruction, why?
uge r6.w, r5.w, cb0[1].x
breakc_nz r6.w
# Here comes some new code...
# Indices are obviously related to the size of the point lights' constant buffer (16 elements).
ieq r10.xyzw, r5.wwww, l(0, 1, 2, 3)
ieq r11.xyzw, r5.wwww, l(4, 5, 6, 7)
ieq r12.xyzw, r5.wwww, l(8, 9, 10, 11)
ieq r13.xyzw, r5.wwww, l(12, 13, 14, 15)
# And this part is also new...
and r14.xyzw, r10.xxxx, cb6[1].xyzw
and r15.xyzw, r10.yyyy, cb6[4].xyzw
or r14.xyzw, r14.xyzw, r15.xyzw
and r15.xyzw, r10.zzzz, cb6[7].xyzw
or r14.xyzw, r14.xyzw, r15.xyzw
# 26 more lines of such and/or pairs.
# Calculate <fromLightToPixel> - finally! Why so much code instead of simple [] operator?
add r14.xyz, r3.xyzx, -r14.xyzx
dp3 r6.w, r14.xyzx, r14.xyzx
sqrt r7.w, r6.w
# Distance check.
lt r7.w, r14.w, r7.w
if_nz r7.w
iadd r7.w, r5.w, l(1)
mov r5.w, r7.w
continue
endif
# Normalization.
rsq r7.w, r6.w
mul r14.xyz, r7.wwww, r14.xyzx
# Calculate <lightIntensity>.
dp3_sat r7.w, r1.xywx, -r14.xyzx
# Check <lightIntensity>.
ge r8.w, l(0.000000), r7.w
if_nz r8.w
iadd r8.w, r5.w, l(1)
mov r5.w, r8.w
continue
endif
# Here we go again - more code!
and r15.xyzw, r10.xxxx, cb6[0].wxyz
and r16.xyzw, r10.yyyy, cb6[3].wxyz
or r15.xyzw, r15.xyzw, r16.xyzw
and r16.xyzw, r10.zzzz, cb6[6].wxyz
or r15.xyzw, r15.xyzw, r16.xyzw
# 26 more lines of such and/or pairs.
# Update <lightIntensity> - finally! Why no [] operator here, but tons of those instructions?
div r6.w, r10.x, r6.w
mul r6.w, r6.w, r7.w
# etc.
endloop
I tried to save current array element to temp variable at the beginning of the loop, but it makes no difference - only several more instructions are added to copy the data.
I just can't understand, why in the first case loop is translated into such small and logic code where array access is done via single
[] operator, but in the second one it expands to such enormous bunch of instructions? And I change only 1 line of code, nothing more (and that line does nothing actually - it even has no ASM representation)! But every array access seems to
be affected with this change.
Can someone please explain that to me? Is there some sort of tricks with array indexing or loops in HLSL? I tried to find something about it on the Internet to no avail. Seems like I miss something very simple and obvious, but I don't get it. Sadly I
work mostly alone by now and know nobody familiar with ASM / HLSL / Direct3D. Answering this question on another popular developer resource brought no result.
Big thanks in advance for any tips or explanations!

Answer 1

The latest version may help with this. 11.9.900.170 is now a step back.
12.0.0.38  is here: http://get.adobe.com/flashplayer/
or download the FULL installer here: Flash Player 12 (Mac OS X)