Sign in to follow this  

Stop HLSL from optimizing out unused textures

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


 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

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

Could it maybe be some weird user-error with the API? Maybe something you setup that was just slightly off?

 

I have never seen such behavior from the shader compiler, which makes me very skeptical that the compiler is actually re-assigning it to register 0. You can check this pretty easily by using fxc.exe to dump the disassembly, which includes the register assignments for shader resources. Alternatively, you can also use a program like RenderDoc to capture a frame and then inspect the disassembly. If you do this, you can also easily confirm that you are in fact binding your shader resource view to the correct slot.

If all else fails, try running with the reference device. If it works correctly with the reference device, then you may have hit a driver bug.

 

I've seen this exact issue before, but it's hard to say if it's the compiler. I remember having sampler binding issues in CryENGINE 2, where we had to read from the textures and throw away the results to get it to work properly - the shaders that shipped with Crysis have plenty of DX10 specific permutations just to read the textures as a workaround. But I can't say if that was an issue with our own shader compiler not building the source files properly, or FXC, since the issue has long since been fixed (and I have no idea who fixed it or how).

Share this post


Link to post
Share on other sites
This does not sound like a compiler issue.
Most likely your assignment of the textures to their slots is wrong (when you don’t have the 0-2 textures to assign) or your code for using the 0-2 textures is not “properly” disabled. That is you disabled the use of those textures via some comments and perhaps caused some values to be unassigned and NaN, resulting in black.


L. Spiro

Share this post


Link to post
Share on other sites

This topic is 787 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this