🔒 Locked

Speed up shader compilation (HLSL)

Started by Meltac May 2, 2012 at 11:25 AM 33 replies 22.7k views

Original Post

May 2, 2012 at 11:25 AM

Hi all!

Given the fact that I have no option to pre-compile my shaders in the game I'm modding because it's always compiling the HLSL source files on every start-up (and again whenever you load a savegame) - what options would I have to speed up the game's just-in-time compilation?

I mean, my shaders are getting fairly complex and by now they take quite some time to compile on every game startup, which kind of sucks. I know I could try to clean up my files, remove comments, empty lines, unused functions and variables, even could try to simplify functions and control flow in order to make compilation simpler and more straight-forward (e.g. prevent some branching). But I'm afraid that wouldn't help too much simply due to the complexity of things I need my shaders to do, so the large effort that would take wouldn't fit the resulting improvement.

So, are there other ways to make compilation faster? For example any hacked / tweaked DX9 binaries or "injected" optimized compilers that are executed automatically when installed instead of the originals when the game addresses the DirectX engine to do the compilation? Or, some way to nest shader assembly code inside a HLSL file (pixel or vertex shader source) with I could generate offline with the fxa compiler prior to letting the game compile the rest of the shader sources? Or any other approaches which I might not have been thought of yet?

Any thoughts would be appreciated.

pcmaster

May 2, 2012 at 1:53 PM

You won't speed anything up by removing comments, dead code, useless vars and such, since the lexical/syntactic analysis isn't slow. What's slow is register allocation and I'm afraid there's usually not much you can do. We're getting into 15-30 minute compile times with our complex DX11 shaders (and we have hundreds) and what sometimes helps (with compile time):
- manually unroll loops (works better (in terms of compilation time) than using [unroll], [fastopt] or whatever compiler hints)
- especially true for nested loops!
- the deeper the called function, the worse
- look for redundant texture sampling which could be pulled up from loops or functions - you'll get cache hit, however it will compile longer

What doesn't help (neither compilation speed nor performance):
- trying to manually optimise ALU operations

I guess most of this will be true for DX9, too.

Meltac

May 2, 2012 at 2:49 PM

Thanks, this is already helpful. I always had the expression that much texture sampling causes long compilation times, although I don't know why that is.

What about arithmetic stuff? I'm having the expression that sometimes when I simply add another formula with one or two additional variables the compilation slows down significantly. Are there, besides texture lookups, some operations that are rather expensive and might be avoided by other expressions doing the same job?

And what about using pre-compiled parts in source files? Is there a way to do this (I remember old Pascal times where I had to place assembly code within Pascal code in order to speed up graphical processing)?

MJP

May 2, 2012 at 6:17 PM

Loop unrolling is usually the big performance killer. You can usually avoid it using the [loop] attribute. Aside from that multithreading helps if you've got multiple cores to play with, it's pretty trivial to compile 1 shader per thread.

There's no way to inline assembly in HLSL shaders. You can manually assemble a shader from chunks of pre-compiled assembly if you'd like, but that's about it.

Meltac

May 3, 2012 at 8:37 AM

Thank you. Unfortunately the compiler being used doesn't support HLSL attributes like [loop], so I fear I'll have to unroll my loops manually in order to prevent the compiler from doing this.

Meltac

May 6, 2012 at 6:28 PM

As it turned out, most of the compilation time was caused by the combination of nested function calls and texture sampling calls. The former I've been able to reduce massively, but the latter gives my kinda head-ache due to the fact that I need a large amount of texture samples in order to achieve the image quality I'd like to have.

So is there any way to speed up texture sampling / lookups specifically? And why does this type of operation take such amounts of time to compile?

Meltac

May 7, 2012 at 8:11 PM

Anybody?

pcmaster

May 9, 2012 at 7:56 AM

I'm afraid there's no way :-) How long compilation times are we talking here?

Meltac

May 9, 2012 at 8:01 AM

Worst case I encountered so far is over 3 minutes, whereas the original (un-modded) shaders take less than 5 seconds. Longer compilation times than that (due to yet more complex shader code) cause the game to crash upon start-up. And that duration is caused by one single function within one single shader file.

AlexandreMutel

May 12, 2012 at 11:03 PM

Given the fact that I have no option to pre-compile my shaders in the game I'm modding because it's always compiling the HLSL source files on every start-up (and again whenever you load a savegame) - what options would I have to speed up the game's just-in-time compilation?.

Just by curiosity, why can't you ship precompiled 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.

Meltac

May 16, 2012 at 8:41 AM

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?

hupsilardee

May 16, 2012 at 9:10 AM

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!

Meltac

May 16, 2012 at 10:50 AM

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.

pcmaster

May 16, 2012 at 1:35 PM

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 :-(

MJP

May 16, 2012 at 6:38 PM

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.

Meltac

May 17, 2012 at 6:29 PM

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.

MJP

May 17, 2012 at 8:25 PM

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.

Meltac

May 18, 2012 at 8:12 AM

Ok, thanks a lot!

pcmaster

May 18, 2012 at 12:58 PM

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 ). 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...

Meltac

May 18, 2012 at 1:06 PM

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?

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.