Jump to content
  • Advertisement
Sign in to follow this  
Funkymunky

Stop HLSL from optimizing out unused textures

This topic is 1004 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

Say I have a shader that uses 4 textures as input.  For debugging purposes, I just want to check what's in the 4th texture, so I comment out the majority of the shader and just sample that one.  I get all black, because apparently the shader has optimized that texture to slot t0 instead of t3 where i declared it.

 

I'm compiling with D3DCOMPILE_DEBUG | D3DCOMPILE_SKIP_OPTIMIZATION, and yet this optimization still happens.  Is there a way to disable it, for debug builds?  It's not a problem I can't work around, but it's a nuisance.

Share this post


Link to post
Share on other sites
Advertisement


 I get all black, because apparently the shader has optimized that texture to slot t0 instead of t3 where i declared it.
That's a different issue to the compiler optimizing out unused resources... Are you saying that it's changed the register assignments of your resources?

What does your code look like where you declare the textures?

Share this post


Link to post
Share on other sites
TextureCube tex1 : register(t0);
Texture2D tex2 : register(t1);
Texture2D tex3 : register(t2);
TextureCube tex4 : register(t3);
 
If I don't sample from tex1-3, and only sample tex4, I get all black.

Share this post


Link to post
Share on other sites
I've never come across this but just wondered, if you change your commented shader to use t0 for the texture, does it then work?

Share this post


Link to post
Share on other sites

it does not. I'm still assigning 4 textures on the CPU side, and regardless of if I put t0 or t3, it samples from the first-assigned cubemap, not the 4th.

Share this post


Link to post
Share on other sites

It's probably easier if you just sample all the textures, and just throw away the results smile.png Maybe use them in the output but multiplied by 0 or whatever it takes for the compiler not to optimize them out. Don't know if that will work though, depends on how smart the compiler is smile.png

 

Otherwise, move the t3 texture to t0, and of course reflect that change in the texture assigning....

 

Edit: Still is a bit weird though, isn't that the purpose of register() to have control over which slot to use regardless of any optimization?

Edited by vinterberg

Share this post


Link to post
Share on other sites


and regardless of if I put t0 or t3, it samples from the first-assigned cubemap

 


I get all black

 

This is... odd. Is the first bound cubemap actually black, or is there some calculation going on that would turn black if you enter a texture with different content than what it would expect? Because you shouldn't really get black in any other case if it really samples just from the first cubemap. So try to, instead of executing the rest of the shader, just output the actual content of the t3 declared cubemap and see if it matches your t0-bound texture first.

Share this post


Link to post
Share on other sites

Say I have a shader that uses 4 textures as input.  For debugging purposes, I just want to check what's in the 4th texture, so I comment out the majority of the shader and just sample that one.  I get all black, because apparently the shader has optimized that texture to slot t0 instead of t3 where i declared it.

 

I'm compiling with D3DCOMPILE_DEBUG | D3DCOMPILE_SKIP_OPTIMIZATION, and yet this optimization still happens.  Is there a way to disable it, for debug builds?  It's not a problem I can't work around, but it's a nuisance.

What dx are you targeting?

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!