|Microsoft DirectX 9.0|
The pixel shader completely replaces the pixel-blending functionality specified by the Microsoft?DirectX?6.0 and 7.0 multi-texturing application programming interfaces (APIs), specifically those operations defined by the D3DTSS_COLOROP, D3DTSS_COLORARG1, D3DTSS_COLORARG2, D3DTSS_ALPHAOP, D3DTSS_ALPHAARG1, and D3DTSS_ALPHAARG2 texture stage states, and associated arguments and modifiers. When a procedural pixel shader is set, these states are ignored.
When pixel shaders are in operation, the following texture stage states are still observed. They are version dependent as shown in the table.
|Texture stage state||Version(s)|
|D3DTSS_BUMPENVMAT00||1_1 - 1_4|
|D3DTSS_BUMPENVMAT01||1_1 - 1_4|
|D3DTSS_BUMPENVMAT10||1_1 - 1_4|
|D3DTSS_BUMPENVMAT11||1_1 - 1_4|
|D3DTSS_BUMPENVLSCALE||1_1 - 1_3|
|D3DTSS_BUMPENVLOFFSET||1_1 - 1_3|
|D3DTSS_TEXCOORDINDEX||1_1 - 1_3. Valid only for fixed function vertex processing.|
|D3DTSS_TEXTURETRANSFORMFLAGS||1_1 - 1_3. Valid only for fixed function vertex processing.|
When pixel shaders are in operation, the following sampler states are still observed.
|D3DSAMP_DMAPOFFSET||Vertex shaders only (displacement mapping)|
Because these texture stage states are not part of the pixel shader, they are not available at shader compile time so the driver can make no assumptions about them. For example, the driver cannot differentiate between bilinear and trilinear filtering at that time. The application is free to change these states without requiring the regeneration of the currently bound shader.
Texture sampling and filtering operations are controlled by the standard texture stage states for minification, magnification, mip filtering, and the wrap addressing modes. For more information, see Texture Stage States. This information is not available to the driver at shader compile time, so shaders must be able to continue operation when this state changes. The application is responsible for setting textures of the correct type (image map, cube map, volume map, etc.) needed by the pixel shader. Setting a texture of the incorrect type will produce unexpected results.
Other pixel operations—such as fog blending, stencil operations, and render target blending—occur after execution of the shader. Render target blending syntax is updated to support new features as described in this topic.
For pixel shader versions ps_1_1 - ps_2_0, diffuse and specular colors are saturated (clamped) to the range 0 through 1 before use by the shader because this is the range of valid inputs to the shader.
Color values input to the pixel shader are assumed to be perspective correct, but this is not guaranteed in all hardware. Colors generated from texture coordinates by the address shader are always iterated in a perspective correct manner. However, they are also clamped to the range 0 to 1 during iteration.
For pixel shader versions ps_1_1 - ps_1_4, the result emitted by the pixel shader is the contents of register r0. Whatever it contains when the shader completes processing is sent to the fog stage and render target blender.
For pixel shader versions ps_2_0 and above, output color is emitter from oC0 - oC4.