Jump to content
  • Advertisement
Jiraya

DX11 Can pre-compiled shaders be provided in the Release version of a game?

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

From what the MSDN states, there are two ways of compiling HLSL shaders: either at runtime or "offline" -- using a tool like fxc.exe, for instance

My question is, are there any risks in using pre-compiled shaders in the final game? I mean, is there any situation in which the pre-compiled shaders might not work?

Or ideally shaders should always be compiled when lauching the game?

Share this post


Link to post
Share on other sites
Advertisement

Ideally shaders would always be precompiled.

6 minutes ago, thefoxbard said:

I mean, is there any situation in which the pre-compiled shaders might not work?

Shaders are pre-compiled for a particular target / shader model -- e.g. SM5 shaders for FEATURE_LEVEL_11.

If you try to load these on FEATURE_LEVEL_10, they won't work... So, you have to precompile your shaders once for each target that you wish to support.

e.g. if you want to support D3D10, D3D10.1 and D3D11 hardware, then compile your shaders for SM4, SM4.1 and SM5, and then load the correct set of precompiled shaders at runtime.

Share this post


Link to post
Share on other sites

Thanks Hodgman!

For some reason I thought games compiled shaders at the user's machine before execution. I'm glad this is simpler than I thought.

Share this post


Link to post
Share on other sites
22 minutes ago, thefoxbard said:

For some reason I thought games compiled shaders at the user's machine before execution.

They do in OpenGL, and you can in D3D if you like. If you had a lot of procedurally generated content then you might prefer it, perhaps...

Share this post


Link to post
Share on other sites

It's instructive in cases such as this to examine how the compilation process actually works.

Under D3D compiling a shader is a two-stage process.  Stage 1 compiles the text-based HLSL code to hardware-independent binary blobs and this is the stage that is carried out by fxc.exe or D3DCompile (which are actually the same thing but I'll get to that in a moment).  Stage 2 always happens in your program and this stage takes the hardware-independent binary blobs and converts them to actual shader objects (i.e. ID3D11VertexShader, etc); this stage is exposed by the ID3D11Device::CreateVertexShader/etc API calls.

The point I made above is that fxc.exe and D3DCompile are actually the same thing; fxc.exe actually calls D3DCompile to compile it's shaders, and this is something you can confirm by using a tool such as e.g. Dependency Walker.  You can also infer that D3DCompile and D3DCompile2 are hardware-independent by the fact that they don't take an ID3D11Device as a parameter (in other words Direct3D doesn't even need to be initialized in order to compile a shader; this is a pure software stage).

Microsoft's own advice on this matter is given at the page titled HLSL, FXC, and D3DCompile and I'll quote:

Quote

As we have recommended for many years, developers should compile their HLSL shaders at build-time rather than rely on runtime compilation. There is little benefit to doing runtime compilation for most scenarios, as vendor-specific micro-optimizations are done by the driver at runtime when converting the HLSL binary shader blobs to vendor-specific instructions as part of the shader object creation step. Developers don’t generally want the HLSL compiler results to change ‘in the field’ over time, so it makes more sense to do compilation at build-time. That is the primary usage scenario expected with the Windows 8.0 SDK and Visual Studio 11, and is the only supported scenario for Windows Store apps (a.k.a Metro style apps) in Windows 8.0.

This page then goes on to discuss scenarios in which you may, despite this advice, still wish to compile at runtime, such as for development purposes; runtime compilation is particularly useful for shader development if you're able to quickly reload and recompile your shaders while the program is running, and see the effects of code changes immediately.

Finally, and this may not be immediately obvious, but you can actually compile your shaders for a lower target than the D3D device you end up creating and ship a single set of precompiled shaders that way.  For example, if you set a minimum of D3D10 class hardware, you can compile your shaders for SM4 and set up your feature levels appropriate, and they'll work on D3D_FEATURE_LEVEL_10_0, D3D_FEATURE_LEVEL_10_1, D3D_FEATURE_LEVEL_11_0 or higher.

Share this post


Link to post
Share on other sites

This also means that you actually can't compile to any HW-dependent format with D3D11 on PC at all, it will all happen in the driver at run-time, as stated above. It can cost measurable amounts of time, so in order to reduce spikes during gameplay on PC (when accessing the shader for the first time), "pre-warm" your shader cache at load-time. On consoles, on the other hand, you can't compile in runtime (at all!) and must load everything as final microcode for the target HW. So it makes sense to build offline under all cases + compile online only for rapid development on PC.

Share this post


Link to post
Share on other sites

  • 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!