Multielement Texture

Traditional textures are considered to be single-element textures. Multielement textures enable applications to write out to multiple elements of a texture, simultaneously, from the pixel shader. The result in the next rendering pass is that an application can use one or more of the elements as a single-element texture—that is, as inputs to the pixel shader. These additional elements can be thought of as a temporary store for intermediate results that will be used in a later pass by the application. The first generation of hardware that exposes this feature has the following restrictions.

All multielement texture surfaces will be allocated automatically. This limitation is addressed by treating this as a new type of surface format with multiple RGBA channels interleaved.
All elements of the multielement texture can have the same bit depth. This limitation is expressed by the name of the new surface formats.
Multielement texture cannot be the primary/displayable. In other words, it must be off-screen only. This limitation is expressed by the surface-format enumeration.
No dithering, alpha test, fogging, blending, raster-op, or masking is allowed. No post-pixel shader processing is done, except the z-test and stencil test.
It cannot be a mipmap. Creation of the mip chain will fail.
The same element cannot be set as a texture at the same time it is a render target. However, different elements of the same multielement texture surface can simultaneously be textures and render targets.
No antialiasing is supported.
Multielement texture surfaces, when used as a texture, cannot be filtered. This limitation can be verified using IDirect3D9::CheckDeviceFormat.
Multielement texture surfaces cannot be locked.
Multiple multielement texture surfaces can be used simultaneously, by assigning each to various stages, like normal textures.
Multielement texture surfaces support gamma 2.2 -> 1.0 conversion on read, just like other texture formats.
Some of the implementations do not apply the output write mask (D3DRS_COLORWRITEENABLE). Those that can, have independent color write masks. This is expressed using a new capability bit. The number of independent color write masks available will be equal to the maximum number of elements the device is capable of.
IDirect3DDevice9::Clear clears all elements of the multielement texture, set as the render target.

The usage is documented in the following list.

Applications discover support for this feature by checking for the availability of multielement texture formats.
The application creates these surfaces by calling IDirect3DDevice9::CreateTexture.
The application sets the surface as a render target using the IDirect3DDevice9::SetRenderTarget call. The pixel shader outputs to the surfaces using the mov instruction.
IDirect3DDevice9::SetTexture is called to set a multielement texture surface to a particular stage. Like other textures, the same surface is allowed to be set to multiple stages at once.
IDirect3DDevice9::SetSamplerState is called to set D3DSAMP_ELEMENTINDEX to the appropriate element number in the multielement texture that the sampler samples from. Default value for this state is 0, which means non-multielement textures will work. Setting this state to an inappropriate number results in an undefined behavior. For example, if the multielement texture is only two elements wide but the sampler is asked to sample from the fourth element.

API Changes

The following are the proposed application programming interface (API) changes to support this feature. New surface formats like the ones shown here express the interleaved nature of the format.

A new interleaved surface format:

D3DFMT_MULTI2_ARGB8    = MAKEFOURCC('M','E','T','1'),

A new sampler state to indicate which element to pick up:

D3DSAMP_ELEMENTINDEX

New render states:

D3DRS_COLORWRITEENABLE1
D3DRS_COLORWRITEENABLE2
D3DRS_COLORWRITEENABLE3

D3DRS_COLORWRITEENABLE applies to render target (or element) zero.

New hardware caps:

D3DPMISCCAPS_INDEPENDENTWRITEMASKS // True if they can support it