Bool register order and fxc.exe

Started by
3 comments, last by DieterVW 13 years, 11 months ago
Hello all, I can't seem to find a lot of information on this issue, so here goes. I ran into an issue where, using fxc.exe, the generated assembler code from an HLSL had the boolean global constant parameters in a different order than how I declared them in the HLSL file. It looks like the assembler file is listing them in order of first usage, rather than the declared order. In my current case, I was able to see what was happening and change the code app-side to feed the booleans to the shader in the order that the assemble wanted (but not in the order that I had specified in the HLSL). However, I can see this possibly becoming a headache down the road. So, my question is, can the order of shader parameters be "forced" to the order they are declared in the HLSL file using fxc, or do we just have to deal with whatever order it chooses? I don't see such a flag in fxc's help. On a side note, this is the first time I've ever seen the assembler code have the global constants in an order that is difference than the order in which I declared them in the HLSL. Now, I DO tend to declare the globals in the order I use them, so maybe I've just been lucking out? Thanks in advance!
Advertisement
Does it matter which order the variables end up in? Don't you set them by their name anyway (not their index)?

Or is that problem that you're manually assigning them to specific registers, and the compiler assigns them to the wrong ones?
Thanks for the quick reply, Hodgman.

I'm not setting them to registers manually in the HLSL (though that is somewhat interesting...).

The HLSL boolean declaration I create might look something like this:
uniform bool lightExists;
uniform bool lightIsDirectional;

fxc will then produce the assembler code so that register b0 is used as lightIsDirectional in the shader, and register b1 is used as lightExists in the shader. So, this effectively means that they've swapped order, since I declared them the other way around and expect register b0 to be lightExists and register b1 to be lightIsDirectional.

Application side, I'm using SetVertexShaderConstantF(), SetVertexShaderConstantB(), and the pixel counterparts to set the constant registers. So, at this point, I'm expecting the registers to be in the order in which I declared them.
Hodgman, you're the man! I updated the HLSL so it manually specifies the registers, and for all intents and purposes of what I need, it works like a charm. I'm calling this case closed.
It's actually beneficial cache wise to have the variables appear in the constant buffer in order of shader usage. Both IHV's suggest this as well. FXC doesn't make any guarantees about variable order and the reflection api must be used to provide maximum safety, or else use the registers/packing as pointed out above.

This topic is closed to new replies.

Advertisement