Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
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. State objects vary by version of Direct3D.
Input-Layout State
This group of state dictates how the Input Assembler (IA) 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 (IA) stage streams primitives from memory into the pipeline.
Rasterizer State
This group of state initializes the Rasterizer (RS) 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.
Depth-Stencil State
This group of state initializes the depth-stencil portion of the Output Merger (OM) stage. More specifically, this object initializes depth and stencil testing.
Blend State
This group of state initializes the blending portion of the Output Merger (OM) stage.
Sampler State
This group of state initializes a sampler object. A sampler object is used by the shader stages to filter textures in memory.
In Direct3D, the sampler object is not bound to a specific texture, it just describes how to do filtering given any attached resource.
Performance Considerations
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.
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.
Related topics