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.

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

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.