Speed up shader compilation (HLSL)

Started by
33 comments, last by Meltac 11 years, 10 months ago

Just by curiosity, why can't you ship precompiled shaders?


Simply because the modded game (STALKER) won't support it. The game expects all shaders to be located in a specific sub-folder in pure HLSL source code. Everything else won't work. But please don't ask me why the dev's decided not to allow compilded shaders...


As it has been said nested loops with texture sampling can be damn slow, as the compiler is trying to calculate correct ddx/ddy. If you can calculate them yourself or you can afford to sample a single mipmap the shader will compile more quickly.


That sounds interesting and might be helpful. I guess I'd need to use an other method than tex2D, so which one would be required here? And how would I sample a single mipmap?
Advertisement
This blog post by MJP might come in handy

http://mynameismjp.wordpress.com/2012/04/13/a-quick-note-on-shader-compilers/

He managed to reduce compile time for a compute shader from 10 minutes to 45 seconds!

This blog post by MJP might come in handy

http://mynameismjp.w...ader-compilers/

He managed to reduce compile time for a compute shader from 10 minutes to 45 seconds!


Interesting, thanks. However since I don't have an option to change the compiler in use I'll have to tweak my code in order to compile faster with the built-in compiler.
Big thanks, the new Windows 8 SDK fxc.exe indeed compiles MUCH faster (130 seconds vs 15 seconds!!!). I just hope the compilated fxo will continue working with existing drivers and Windows 7 / DirectX 11 SDKs and runtimes...

What sucks is that they're dropping D3DX from SDK 8 :-( That means a lot of rewrite :-(

Big thanks, the new Windows 8 SDK fxc.exe indeed compiles MUCH faster (130 seconds vs 15 seconds!!!). I just hope the compilated fxo will continue working with existing drivers and Windows 7 / DirectX 11 SDKs and runtimes...


It works fine, they didn't change the shader binary format at all.
Just out of curiosity, by "compiler", do you mean fxc.exe only, or also the compiler methods nested in D3DX9_XX.dll or maybe other DLLs as well?

But may we come back to topic please:


As it has been said nested loops with texture sampling can be damn slow, as the compiler is trying to calculate correct ddx/ddy. If you can calculate them yourself or you can afford to sample a single mipmap the shader will compile more quickly.

That sounds interesting and might be helpful. I guess I'd need to use an other method than tex2D, so which one would be required here? And how would I sample a single mipmap?


So, any suggestions here? Thanks.
In later versions of the SDK the shader compiler is entirely hosted in D3DCompile_xx.dll. That DLL is then used by fxc.exe and the D3DX functions, or it can be used directly.

You can specify the mipmap level explicitly with tex2Dlod. You can also use tex2Dgrad if you want to specify the UV gradients instead of a mip level.
Ok, thanks a lot!
I have to thank MJP again for trying this out. We were quite frustrated by compilation times of our shaders and would check Microsoft webs for a new SDK version from time to time, however we wouldn't go into Win 8 SDK yet, as we'd miss D3DX a lot (and don't care about Win 8 at all, yet :D). The possibility to use the new, fixed fxc alone while compiling and linking against June 2010 SDK is just awesome and saves us a lot of time and nerves now :-)

I wonder what went bad in their prior version that it's so insanely slow...

In later versions of the SDK the shader compiler is entirely hosted in D3DCompile_xx.dll. That DLL is then used by fxc.exe and the D3DX functions, or it can be used directly.


So does that mean that I could simply replace the existing D3DCompile_xx.dll in the system32 and/or SysWOW64 folder with the one from the new Win8 SDK in order to speed up shader compilation in any application that doesn't use it's own directX binaries?

This topic is closed to new replies.

Advertisement