How can I check for Shader Model 3 support?

Question

Currently I am working on a 3D visualization app. A requirement of my app is that host's graphics card supports Shader Model 3. How can I check for Shader Model 3 support?

I know that these versions are supposed to support these models:

• DirectX 8.0 - Shader Model 1.0 & 1.1
• DirectX 8.0a - Shader Model 1.3
• DirectX 8.1 - Shader Model 1.4
• DirectX 9.0 - Shader Model 2.0
• DirectX 9.0a - Shader Model 2.0a
• DirectX 9.0b - Shader Model 2.0b
• DirectX 9.0c - Shader Model 3.0
• DirectX 10.0* - Shader Model 4.0
• DirectX 10.1* - Shader Model 4.1
• DirectX 11.0* - Shader Model 5.0

But some graphic hardware doesn't support Shader Model 3.0 even with the proper DirectX version. So I want to determine it by checking the hardware not just the DirectX version.

Answer 1

You'll need to check the GPU capabilities through D3DCAPS (check the DirectX SDK docs if you don't know it). More than just determining the shader model, you can check for specific capabilities supported.

For a one-off check (not gonna help you at runtime) you can use GPU-Z.

Answer 2

If you are using D3D9, you can query for device capabilities reported by your card using the IDirect3D9::GetDeviceCaps method. This will give you a structure containing a lot of interesting information about what the hardware supports. Of interest to you concerning this problem will the fields in the resulting structure called VertexShaderVersion and PixelShaderVersion as well as possibly MaxVertexShader30InstructionSlots and MaxPixelShader30InstructionSlots. All four are described on the linked documentation page.

For D3D10 you should be guaranteed SM4. For D3D11 (which I'd recommend over 10, since it should be the case that you can use 11 if you can use 10) device capabilities are categorized into feature levels. If you're using the 10_0 feature level or greater, you should be guaranteed SM4. Below the 10_0 level you have some odd 10Level9 differences to take into account -- the upshot for you is that you have to use odd shader model designations like vs_4_0_level_9_1 in some (perhaps all, we're getting into territory I haven't explored much in practice) scenarios.

You'll note that I said "should be guaranteed" in a few places. This is because, as you alluded to, it's possible for cards to lie or for there to be driver bugs that effectively render particular hardware/driver combinations "non functional" (or at least broken in a fashion you'd want to work around). This is much rarer these days than it used to be, but in these cases you can't really trust the hardware or driver anyhow and will have to "do it yourself." One way to do this is to simply try to create something using SM3 and see if it fails... although this will not catch all bugs/failures.

What I have done to account for that kind of issue in the past is build up a locally-maintained "feature database" API that allows me to store information about particular card/driver failures and how to fall back to safe alternative code paths when that hardware/driver combination is present on the end-user's machine. Populating this database generally requires trial-and-error and a lot of different hardware configurations, so can be difficult for the lone developer to do, unfortunately.