Jump to content
  • Advertisement
Sign in to follow this  
joefear

Bool register order and fxc.exe

This topic is 3154 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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!

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!