D3D9CAPS gives unusual maximum shader instructions value

Question

I'm trying to implement a vertex and pixel shader on a piece of hardware we're developing a game for which uses the DirectX 9.0c runtime. The shaders are for boned mesh animation and is a bit more complicated than the only other shader I have gotten working so far which is a simple 2d sprite shader. The boned mesh shader seems to work fine when developing on my PC but doesn't work when I transfer it over to the target hardware. This lead me to checking the hardware capabilities of both machines to check for any differences and I got the following unusual results:

Development machine Dx9 cap results:

Maximum primitive count: 16777215
Device supports level 3.0 vertex shaders
Vertex shader maximum number of instructions run when using flow control 65535
Vertex shader maximum number of constant buffers 256
Vertex shader maximum number of 30 instruction slots 4096
Vertex shader instruction predication supported
Vertex shader dynamic flow control depth 24
Vertex shader number of temporary registers 32
Vertex shader static flow control depth 4
Device supports level 3.0 pixel shaders
Pixel shader maximum number of instructions run when using flow control 65535
Pixel shader maximum value of arithmetic component 65504.000000
Pixel shader maximum number of instruction slots 4096
Pixel shader instruction predication supported
Pixel shader dynamic flow control depth 24
Pixel shader number of temporary registers 32
Pixel shader static flow control depth 4
Pixel shader number of instruction slots 512

Target machine Dx9 cap results:

Maximum primitive count: 5592405
Device supports level 3.0 vertex shaders
Vertex shader maximum number of instructions run when using flow control -1
Vertex shader maximum number of constant buffers 256
Vertex shader maximum number of 30 instruction slots 32768
Vertex shader instruction predication supported
Vertex shader dynamic flow control depth 24
Vertex shader number of temporary registers 32
Vertex shader static flow control depth 4
Device supports level 3.0 pixel shaders
Pixel shader maximum number of instructions run when using flow control -1
Pixel shader maximum value of arithmetic component 340282346638528860000000000000000000000.000000
Pixel shader maximum number of instruction slots 32768
Pixel shader instruction predication supported
Pixel shader dynamic flow control depth 24
Pixel shader number of temporary registers 32
Pixel shader static flow control depth 4
Pixel shader number of instruction slots 512

What I found unusual was the maximum number of instructions during flow control was -1 for both the pixel and vertex shaders on the target machine. Is it the case that the target hardware can only support shaders with no flow control? i.e. no for loops, if conditions etc.

The only reason I ask is because the simple shader, with no flow control, works fine but the more complicated boned mesh shader, with for loops and if conditions, isn't working. It just seemed like too much of a coincidence that the only major difference between the two caps seems to be the flow control based one or am I barking up the wrong tree?

In case this helps I've linked the two shaders I've written just in case there's any obvious errors in there:

2D Sprite shader: https://pastebin.com/0G9swKu6

3D Boned Mesh shader: https://pastebin.com/Ayd0bXWU

Any input/ideas would be greatly appreciated.

Answer 1

These two caps - MaxVShaderInstructionsExecuted and MaxPShaderInstructionsExecuted - are both of type DWORD, which is an unsigned int type.

From d3d9caps.h:

DWORD   MaxVShaderInstructionsExecuted; // maximum number of vertex shader instructions that can be executed
DWORD   MaxPShaderInstructionsExecuted; // maximum number of pixel shader instructions that can be executed

Cross-checking on other PCs we see that they can have values of 4294967295, or hexadecimal 0xffffffff.

If you cast/convert this to a signed int type, you get -1.

The -1 value is therefore not significant but rather a bug in your own code - you're converting an unsigned int to a signed int at some stage between retrieving and displaying the caps.

As for what's wrong with your shaders - you need to be more specific when you say "not working" - you need to describe what's actually happening. From a brief glance at the shader code I would suggest that you're using a lot of constant registers for SM3, but in the absence of clarification (and I suggest you make it a separate question) I can't do more than speculate.