State Objects (Direct3D 10)
In Direct3D 10, device state is grouped into state objects which greatly reduce the cost of state changes. There are several state objects, and each one is designed to initialize a set of state for a particular pipeline stage. You can create up to 4096 of each type of state object.
- Input-Layout State
- Rasterizer State
- Depth-Stencil State
- Blend State
- Sampler State
- Performance Considerations
- Related topics
This group of state (see D3D10_INPUT_ELEMENT_DESC) dictates how the input-assembler stage reads data out of the input buffers and assembles it for use by the vertex shader. This includes state such as the number of elements in the input buffer and the signature of the input data. The input-assembler stage is a new stage in the pipeline whose job is to stream primitives from memory into the pipeline.
To create a input-layout-state object, see CreateInputLayout.
This group of state (see D3D10_RASTERIZER_DESC) initializes the rasterizer stage. This object includes state such as fill or cull modes, enabling a scissor rectangle for clipping, and setting multisample parameters. This stage rasterizes primitives into pixels, performing operations like clipping and mapping primitives to the viewport.
To create a rasterizer-state object, see CreateRasterizerState.
To create a depth-stencil-state object, see CreateDepthStencilState.
To create a blend-state object, see CreateBlendState.
This group of state (see D3D10_SAMPLER_DESC) initializes a sampler object. A sampler object is used by the shader stages to filter textures in memory.
Differences between Direct3D 9 and Direct3D 10:In Direct3D 10, the sampler object is no longer bound to a specific texture - it just describes how to do filtering given any attached resource.
To create a sampler-state object, see CreateSamplerState.
Designing the API to use state objects creates several performance advantages. These include validating state at object creation time, enabling caching of state objects in hardware, and greatly reducing the amount of state that is passed during a state-setting API call (by passing a handle to the state object instead of the state).
To achieve these performance improvements, you should create your state objects when your application starts up, well before your render loop. State objects are immutable, that is, once they are created, you cannot change them. Instead you must destroy and recreate them. To cope with this restriction, you can create up to 4096 of each type of state objects. For example, you could create several sampler objects with various sampler-state combinations. Changing the sampler state is then accomplished by calling the appropriate Set API which passes a handle to the object (as opposed to the sampler state). This significantly reduces the amount of overhead during each render frame for changing state since the number of calls and the amount of data are greatly reduced.
Alternatively, you can choose to use the effect system which will automatically manage efficient creation and destruction of state objects for your application.