Decoupling Vertex Shaders and Vertex Declarations

In Microsoft?DirectX?9.0, vertex shaders and vertex declarations are no longer bound together at shader create (CreateVertexShader) time. The shader validation has been broken up into two parts. The first part is run at shader creation time and the other is run at draw (DrawPrimitive) time.

• Mapping a DirectX 8.x Vertex Declaration to a DirectX 9.0 Vertex Declaration
• Mapping an FVF code to a DirectX 9.0 Vertex Declaration
• Mapping a DirectX 9.0 Vertex Declaration to a DirectX 8.x Vertex Declaration
• Mapping a DirectX 9.0 Vertex Declaration to FVF codes

Vertex shaders and vertex declarations are represented by objects. To make this work with a DirectX 8.x driver, some caching is done. At "draw time" the runtime checks to see if a combined shader object that encapsulated the current declaration and shader exists. If it does, it sends it down to the driver, or else it will create a new one for that combination of shader and declaration. Additionally, to address application programming interface (API) usability issues, there will be a separate SetFVF call that is equivalent to the SetVertexDeclaration call. This is a convenience function. When this call is made, it will clobber the currently set declaration and vice versa. If the driver is pre-DirectX 8.0 (the number of stream is 0) SetVertexDeclaration might fail for declarations that cannot be converted to an flexible vertex format (FVF).

• SetVertexDeclaration and SetVertexShader calls are recorded by stateblocks. Setting or getting the declaration or the shader causes an increment of the refcount for that object.
• An FVF code can be used with both the fixed function and the programmable vertex pipeline. FVF is converted to a vertex shader declaration, using the table. DCL commands in vertex shader functions should be written with this in mind.
• Software vertex processing supports DirectX 9.0 level features besides tessellation and hence when Drawing with software VP more declarations are supported.
• For the programmable vertex pipeline: At draw time, Microsoft Direct3D?looks for the same "usage - usage index" combination in the current vertex declaration and the current vertex shader function. When the combination is found, the register from shader function DCL is used as destination for the vertex element.
• If an FVF has XYZRHW position type, vertices are treated as transformed and lit, and the vertex shader function is not applied when used with the programmable vertex pipeline.
• When a vertex element in the current vertex declaration has a usage that is not found in the current vertex shader, that vertex element is ignored.

A subset of declarations are allowed on DirectX 8.x drivers (numstreams is not zero but does not support stream offset), only those that can be converted to DirectX 8.x-style declaration can be created. Hence the CreateVertexDeclaration call may fail if the declaration provided cannot be converted. For a mixed-mode device, this failure will happen at Drawxxx time because that is the only time it can be known whether this shader is being used with hardware or software vertex processing. This conversion is summarized in the table.

A further subset of decls are allowed on pre-DirectX 8.0 drivers (numstreams is zero); only those declarations that can be converted to an appropriate FVF are allowed. If that conversion is not possible, the CreateVertexDeclaration might fail. For a mixed-mode device, this failure will happen at Drawxxx time because that is the only time it can be known whether this shader is being used with hardware or software vertex processing. This conversion is summarized in the table. Only stream 0 should be used (evident from the MaxStreams cap).

The order of vertex elements should correspond to the order of the FVF codes. The usage index for D3DDECLUSAGE_POSITION and D3DDECLUSAGE_NORMAL should be 0. When switching vertex processing mode for a device with mixed vertex processing, there is no need to reset all input vertex (and index) streams, the vertex declaration, and the vertex function. NULL is an invalid input to SetVertexDeclaration. When using software vertex processing, all usages mentioned in the shader code for the programmable vertex pipeline need to be present in the declaration (or the FVF) bound at the draw time.

Declarations that use the following rules can be rendered with the fixed function pipeline (this assumes no tessellation is required).

• Use only D3DDECLMETHOD_DEFAULT.
• There should be no gaps between vertex elements (SKIP was not allowed in a DirectX 8.x declaration).
• Specify usage POSITION.
• Specify D3DDECLTYPE_FLOAT3 data type for POSITION usage.
• Vertex elements not described in the table following cannot be converted into a valid FVF for all pre-DirectX 8.0 drivers and so cannot be used with the fixed function vertex processing on those drivers.

Mapping a DirectX 8.x Vertex Declaration to a DirectX 9.0 Vertex Declaration

Mapping an FVF code to a DirectX 9.0 Vertex Declaration

Mapping a DirectX 9.0 Vertex Declaration to a DirectX 8.x Vertex Declaration

Mapping a DirectX 9.0 Vertex Declaration to FVF codes

Additional types can be successfully converted to a valid declaration on DirectX 8.0 and newer drivers, and hence can be used by fixed function vertex processing.

• When DirectX 8.x drivers are used, the vertex declaration is converted to a DirectX 8.x declaration by the following rules. For other combinations of usages, the Direct3D will fail.
• For each new stream in the D3DVSD_STREAM, a token is inserted.
• Vertex elements cannot share the same offset in a stream and they cannot overlap.
• The data type must be less than or equal to D3DDECLTYPE_SHORT4.
• For each vertex element with the D3DDECLMETHOD_DEFAULT method, the D3DVSD_REG token is inserted.
• Usage and UsageIndex are converted to a register value using the table following. When using the DrawRectPatch (RT-patches), the output of the tessellator should comply with the previous rules.