In your first example, you would compile two different shaders. When you compile a shader you specify the entry point function, so you would compile one with "Texture" as the entry point and then the other with "noTexture" as the entry point.

To pass values to a shader, you use a constant buffer. The syntax looks like this:


cbuffer Constants
{
bool bTex;
}
float4 Texture(PS_INPUT input) : SV_Target
{
if (bTex)
return tex.Sample(linearSampler, input.Tex );
else
return input.Color;
}


Then you also need to handle creating a constant buffer, filling it with data, and binding it in your C++ app code. If you're not familiar with constant buffers, I would simple recommend consulting some of the simple tutorials and samples that come with the SDK.

Not sure how you compile your shader code but if you use this function you can state for example the name of the pixel shader function to use.
Like this:

D3DX11CompileFromFile(PATH, 0, 0, NAME, MODEL, NULL, 0, 0, &this->PS_Buffer, NULL, 0);


Where PATH is the path where you shader file is located at, NAME is the name (string) of your shader function (like in your example "Texture") and MODEL the specific shader model you want to use.
For a more detailed description on how this function works:
http://msdn.microsoft.com/en-us/library/windows/desktop/ff476261(v=vs.85).aspx

I don't think you can set specific shader functions during run-time if that's what you were asking.
The compiler has to know which function the entry function should be.

I believe you could also do something like (haven't tried it)

#ifdef USETEXTURES
float4 PS(PS_input input) : SV_TARGET
{
return texture.Sample(...);
}
#else
float4 PS(PS_input input) : SV_TARGET
{
return 1.0f;
}
#endif


But that would still need to be done during the compile

Ahh now that's much harder question to answer.

It's true that compiling many different "permutations" of a shader can lead to the "explosion" of shaders that you're alluding to. The thing you have to keep in mind is that even if you support 2^16 possible shader variations, your game would never actually use that many. So the trick is to limit your set of shaders to the ones that you actually need. For instance some games have used an on-demand shader system during development that didn't compile and load a particular permutation until a mesh was loaded that needed it. They would then save those shaders to a cache, and once the game was QA'ed they would ship the game with the pre-compiled cache stored on disc. Some games will simply pre-determine the shaders needed as part of a level build step, and pre-compile them. In practice it depends a lot on the game, and how the game's shader/material system is setup.

Putting variables in constant buffers is a different problem. With that approach you don't have to deal with compiling or loading a lot shaders, and you can stick lots of variables in the constant buffer without worrying about doubling the number of shaders. Instead you have to deal with the runtime performance of having a branch (which is pretty cheap on modern hardware, especially since all threads will take the same branch) and suboptimal code from the compiler not being able to optimize things out. However it's possible to mix this approach with shader permutations, in order to minimize the downsides of either. In general I would suggest putting expensive, complex functionality in a permutation rather than a branch. This will ensure that you don't suffer a higher register count for materials that don't use the expensive feature.

If i remeber correct. #ifndef/#endif are far more efficent to use rather than an "if-branch" in the pixelshader.
and you could set your defines in an global header file that you include to all your shaders. you could allso rewrite that file at runtime to set diffrent graphics options.