HLSL compiled code

Question

I've been using RenderDoc for debugging my shaders, and one thing that struck me as odd is that sometimes, after stepping through the debugger, I notice some vector attributes are interchanged, for example sometimes a float3 variables register has .z interchanged with .y, and I'm positive there is nothing wrong in the shader code part.

Is this some magic optimizations from the compiler? It certainly makes debugging ALOT more frustrating, never being quite sure if it truly is the viewPosition.z or actually the viewPosition.y for example... Is there any good ways around this?

Answer 1

The compiler won't always put the ".xyz" of a hlsl variable into ".xyz" of a register, if that's what you're referring to - sometimes it will move between .xyz, .xyw, .yzw, or even between components in separate registers, depending on if it's some intermediate calculation value or not and how much register pressure there is. As far as I'm aware there's no way to change this, it's just how the internal register allocation handles things. If this swizzling is happening and getting you some wrong output though, that means a bug in RenderDoc :).

You can make it a little easier to read if you disable optimisations and enable the debug flag /Zi or D3DCOMPILE_DEBUG when compiling your shader. That way whenever you have a function that returns a value, it will always compile in a 'mov' instruction that contains the return value, to make it easier to trace what's happening from then on. I think it also makes a 'mov' for each function parameter, but don't quote me on that. In either case, the compiler doesn't try nearly as hard to minimise the number of registers used.

What's all the more infuriating is that modern GPUs have moved away from the SIMD vector style instructions and it all compiles down to scalar operations under the hood, but we're stuck with this old-style fxc!