Blending applies a simple function to combine output values from a pixel shader with data in a render target. You have control over how the pixels are blended by using a predefined set of blending operations and preblending operations.

To create a blend-state object, call . To bind the blend-state object to the output-merger stage, call .

You use the description for blending state in a call to the method to create the blend-state object.

You use the description for blending state in a call to the method to create the blend-state object.

Blending applies a simple function to combine output values from a pixel shader with data in a render target. You have control over how the pixels are blended by using a predefined set of blending operations and preblending operations.

To create a blend-state object, call . To bind the blend-state object to the output-merger stage, call .

You use the description for blending state in a call to the method to create the blend-state object.

You use the description for blending state in a call to the method to create the blend-state object.

Here are the default values for blend state.

?

If the driver type is set to , the feature level is set to less than or equal to , and the pixel format of the render target is set to , , or , the display device performs the blend in standard RGB (sRGB) space and not in linear space. However, if the feature level is set to greater than , the display device performs the blend in linear space, which is ideal.

Here are the default values for blend state.

?

If the driver type is set to , the feature level is set to less than or equal to , and the pixel format of the render target is set to , , or , the display device performs the blend in standard RGB (sRGB) space and not in linear space. However, if the feature level is set to greater than , the display device performs the blend in linear space, which is ideal.

When you set the LogicOpEnable member of the first element of the RenderTarget array (RenderTarget[0]) to TRUE, you must also set the BlendEnable member of RenderTarget[0] to , and the IndependentBlendEnable member of this to . This reflects the limitation in hardware that you can't mix logic operations with blending across multiple render targets, and that when you use a logic operation, you must apply the same logic operation to all render targets.

There are three types of buffers: vertex, index, or a shader-constant buffer. Create a buffer resource by calling .

A buffer must be bound to the pipeline before it can be accessed. Buffers can be bound to the input-assembler stage by calls to and , to the stream-output stage by a call to , and to a shader stage by calling the appropriate shader method (such as for example).

Buffers can be bound to multiple pipeline stages simultaneously for reading. A buffer can also be bound to a single pipeline stage for writing; however, the same buffer cannot be bound for reading and writing simultaneously.

This structure is used by to create buffer resources.

In addition to this structure, you can also use the CD3D11_BUFFER_DESC derived structure, which is defined in D3D11.h and behaves like an inherited class, to help create a buffer description.

If the bind flag is , you must set the ByteWidth value in multiples of 16, and less than or equal to D3D11_REQ_CONSTANT_BUFFER_ELEMENT_COUNT.

This interface is created by calling . The interface is used when binding shader resources to the pipeline using APIs such as .

For more information about using the interface, see Dynamic Linking.

Windows?Phone?8: This API is supported.

For more information about using the interface, see Dynamic Linking.

An instance is not restricted to being used for a single type in a single shader. An instance is flexible and can be used for any shader that used the same type name or instance name when the instance was generated.

• A created instance will work for any shader that contains a type of the same type name. For instance, a class instance created with the type name DefaultShader would work in any shader that contained a type DefaultShader even though several shaders could describe a different type.
• A gotten instance maps directly to an instance name/index in a shader. A class instance aquired using GetClassInstance will work for any shader that contains a class instance of the name used to generate the runtime instance, the instance does not have to be the same type in all of the shaders it's used in.

An instance does not replace the importance of reflection for a particular shader since a gotten instance will not know its slot location and a created instance only specifies a type name.

Windows?Phone?8: This API is supported.

For more information about using the interface, see Dynamic Linking.

Windows?Phone?8: This API is supported.

For more information about using the interface, see Dynamic Linking.

An instance is not restricted to being used for a single type in a single shader. An instance is flexible and can be used for any shader that used the same type name or instance name when the instance was generated.

• A created instance will work for any shader that contains a type of the same type name. For instance, a class instance created with the type name DefaultShader would work in any shader that contained a type DefaultShader even though several shaders could describe a different type.
• A gotten instance maps directly to an instance name/index in a shader. A class instance aquired using GetClassInstance will work for any shader that contains a class instance of the name used to generate the runtime instance, the instance does not have to be the same type in all of the shaders it's used in.

An instance does not replace the importance of reflection for a particular shader since a gotten instance will not know its slot location and a created instance only specifies a type name.

Windows?Phone?8: This API is supported.

GetInstanceName will return a valid name only for instances acquired using .

For more information about using the interface, see Dynamic Linking.

Windows?Phone?8: This API is supported.

GetTypeName will return a valid name only for instances acquired using .

For more information about using the interface, see Dynamic Linking.

Windows?Phone?8: This API is supported.

A class linkage object can hold up to 64K gotten instances. A gotten instance is a handle that references a variable name in any shader that is created with that linkage object. When you create a shader with a class linkage object, the runtime gathers these instances and stores them in the class linkage object. For more information about how a class linkage object is used, see Storing Variables and Types for Shaders to Share.

An object is created using the method.

For more information about using the interface, see Dynamic Linking.

A class instance must have at least 1 data member in order to be available for the runtime to use with . Any instance with no members will be optimized out of a compiled shader blob as a zero-sized object. If you have a class with no data members, use instead.

Windows?Phone?8: This API is supported.

Instances can be created (or gotten) before or after a shader is created. Use the same shader linkage object to acquire a class instance and create the shader the instance is going to be used in.

For more information about using the interface, see Dynamic Linking.

Windows?Phone?8: This API is supported.

The compute-shader interface has no methods; use HLSL to implement your shader functionality. All shaders are implemented from a common set of features referred to as the common-shader core..

To create a compute-shader interface, call . Before using a compute shader you must bind it to the device by calling .

This interface is defined in D3D11.h.

A counter can be created with .

This is a derived class of .

Counter data is gathered by issuing an command, issuing some graphics commands, issuing an command, and then calling to get data about what happened in between the Begin and End calls. The data returned by GetData will be different depending on the type of counter. The call to End causes the data returned by GetData to be accurate up until the last call to End.

Counters are best suited for profiling.

For a list of the types of performance counters, see .

To create a depth-stencil-state object, call . To bind the depth-stencil-state object to the output-merger stage, call .

You use the description for depth-stencil state in a call to the method to create the depth-stencil-state object.

You use the description for depth-stencil state in a call to the method to create the depth-stencil-state object.

Pass a reference to to the method to create the depth-stencil state object.

Depth-stencil state controls how depth-stencil testing is performed by the output-merger stage.

The following table shows the default values of depth-stencil states.

?

The formats that support stenciling are and .

To create a depth-stencil view, call .

To bind a depth-stencil view to the pipeline, call .

To create a depth-stencil view, call .

To bind a depth-stencil view to the pipeline, call .

To create a depth-stencil view, call .

To bind a depth-stencil view to the pipeline, call .

A device is created using .

Windows?Phone?8: This API is supported.

The function signature PFN_D3D11ON12_CREATE_DEVICE is provided as a typedef, so that you can use dynamic linking techniques (GetProcAddress) instead of statically linking.

Feature levels determine the capabilities of your device.

The GetImmediateContext method returns an object that represents an immediate context which is used to perform rendering that you want immediately submitted to a device. For most applications, an immediate context is the primary object that is used to draw your scene.

The GetImmediateContext method increments the reference count of the immediate context by one. Therefore, you must call Release on the returned interface reference when you are done with it to avoid a memory leak.

An exception-mode flag is used to elevate an error condition to a non-continuable exception.

For example code, see How to: Create a Vertex Buffer, How to: Create an Index Buffer or How to: Create a Constant Buffer.

For a constant buffer (BindFlags of set to ), you must set the ByteWidth value of in multiples of 16, and less than or equal to D3D11_REQ_CONSTANT_BUFFER_ELEMENT_COUNT.

The Direct3D 11.1 runtime, which is available on Windows?8 and later operating systems, provides the following new functionality for CreateBuffer:

You can create a constant buffer that is larger than the maximum constant buffer size that a shader can access (4096 32-bit*4-component constants ? 64KB). When you bind the constant buffer to the pipeline (for example, via PSSetConstantBuffers or PSSetConstantBuffers1), you can define a range of the buffer that the shader can access that fits within the 4096 constant limit.

The runtime will emulate this feature for feature level 9.1, 9.2, and 9.3; therefore, this feature is supported for feature level 9.1, 9.2, and 9.3. This feature is always available on new drivers for feature level 10 and higher. On existing drivers that are implemented to feature level 10 and higher, a call to CreateBuffer to request a constant buffer that is larger than 4096 fails.

CreateTexture1D creates a 1D texture resource, which can contain a number of 1D subresources. The number of textures is specified in the texture description. All textures in a resource must have the same format, size, and number of mipmap levels.

All resources are made up of one or more subresources. To load data into the texture, applications can supply the data initially as an array of structures pointed to by pInitialData, or they can use one of the D3DX texture functions such as D3DX11CreateTextureFromFile.

For a 32 width texture with a full mipmap chain, the pInitialData array has the following 6 elements:

• pInitialData[0] = 32x1
• pInitialData[1] = 16x1
• pInitialData[2] = 8x1
• pInitialData[3] = 4x1
• pInitialData[4] = 2x1
• pInitialData[5] = 1x1

CreateTexture2D creates a 2D texture resource, which can contain a number of 2D subresources. The number of textures is specified in the texture description. All textures in a resource must have the same format, size, and number of mipmap levels.

All resources are made up of one or more subresources. To load data into the texture, applications can supply the data initially as an array of structures pointed to by pInitialData, or it may use one of the D3DX texture functions such as D3DX11CreateTextureFromFile.

For a 32 x 32 texture with a full mipmap chain, the pInitialData array has the following 6 elements:

• pInitialData[0] = 32x32
• pInitialData[1] = 16x16
• pInitialData[2] = 8x8
• pInitialData[3] = 4x4
• pInitialData[4] = 2x2
• pInitialData[5] = 1x1

CreateTexture3D creates a 3D texture resource, which can contain a number of 3D subresources. The number of textures is specified in the texture description. All textures in a resource must have the same format, size, and number of mipmap levels.

All resources are made up of one or more subresources. To load data into the texture, applications can supply the data initially as an array of structures pointed to by pInitialData, or they can use one of the D3DX texture functions such as D3DX11CreateTextureFromFile.

Each element of pInitialData provides all of the slices that are defined for a given miplevel. For example, for a 32 x 32 x 4 volume texture with a full mipmap chain, the array has the following 6 elements:

• pInitialData[0] = 32x32 with 4 slices
• pInitialData[1] = 16x16 with 2 slices
• pInitialData[2] = 8x8 with 1 slice
• pInitialData[3] = 4x4 with 1 slice
• pInitialData[4] = 2x2 with 1 slice
• pInitialData[5] = 1x1 with 1 slice

A resource is made up of one or more subresources; a view identifies which subresources to allow the pipeline to access. In addition, each resource is bound to the pipeline using a view. A shader-resource view is designed to bind any buffer or texture resource to the shader stages using the following API methods: , and .

Because a view is fully typed, this means that typeless resources become fully typed when bound to the pipeline.

The Direct3D 11.1 runtime, which is available starting with Windows?8, allows you to use CreateShaderResourceView for the following new purpose.

You can create shader-resource views of video resources so that Direct3D shaders can process those shader-resource views. These video resources are either Texture2D or Texture2DArray. The value in the ViewDimension member of the structure for a created shader-resource view must match the type of video resource, D3D11_SRV_DIMENSION_TEXTURE2D for Texture2D and D3D11_SRV_DIMENSION_TEXTURE2DARRAY for Texture2DArray. Additionally, the format of the underlying video resource restricts the formats that the view can use. The video resource format values on the reference page specify the format values that views are restricted to.

The runtime read+write conflict prevention logic (which stops a resource from being bound as an SRV and RTV or UAV at the same time) treats views of different parts of the same video surface as conflicting for simplicity. Therefore, the runtime does not allow an application to read from luma while the application simultaneously renders to chroma in the same surface even though the hardware might allow these simultaneous operations.

Windows?Phone?8: This API is supported.

The Direct3D 11.1 runtime, which is available starting with Windows?8, allows you to use CreateUnorderedAccessView for the following new purpose.

You can create unordered-access views of video resources so that Direct3D shaders can process those unordered-access views. These video resources are either Texture2D or Texture2DArray. The value in the ViewDimension member of the structure for a created unordered-access view must match the type of video resource, for Texture2D and for Texture2DArray. Additionally, the format of the underlying video resource restricts the formats that the view can use. The video resource format values on the reference page specify the format values that views are restricted to.

The runtime read+write conflict prevention logic (which stops a resource from being bound as an SRV and RTV or UAV at the same time) treats views of different parts of the same video surface as conflicting for simplicity. Therefore, the runtime does not allow an application to read from luma while the application simultaneously renders to chroma in the same surface even though the hardware might allow these simultaneous operations.

A render-target view can be bound to the output-merger stage by calling .

The Direct3D 11.1 runtime, which is available starting with Windows?8, allows you to use CreateRenderTargetView for the following new purpose.

You can create render-target views of video resources so that Direct3D shaders can process those render-target views. These video resources are either Texture2D or Texture2DArray. The value in the ViewDimension member of the structure for a created render-target view must match the type of video resource, for Texture2D and for Texture2DArray. Additionally, the format of the underlying video resource restricts the formats that the view can use. The video resource format values on the reference page specify the format values that views are restricted to.

The runtime read+write conflict prevention logic (which stops a resource from being bound as an SRV and RTV or UAV at the same time) treats views of different parts of the same video surface as conflicting for simplicity. Therefore, the runtime does not allow an application to read from luma while the application simultaneously renders to chroma in the same surface even though the hardware might allow these simultaneous operations.

A depth-stencil view can be bound to the output-merger stage by calling .

After creating an input layout object, it must be bound to the input-assembler stage before calling a draw API.

Once an input-layout object is created from a shader signature, the input-layout object can be reused with any other shader that has an identical input signature (semantics included). This can simplify the creation of input-layout objects when you are working with many shaders with identical inputs.

If a data type in the input-layout declaration does not match the data type in a shader-input signature, CreateInputLayout will generate a warning during compilation. The warning is simply to call attention to the fact that the data may be reinterpreted when read from a register. You may either disregard this warning (if reinterpretation is intentional) or make the data types match in both declarations to eliminate the warning.

Windows?Phone?8: This API is supported.

The Direct3D 11.1 runtime, which is available starting with Windows?8, provides the following new functionality for CreateVertexShader.

The following shader model 5.0 instructions are available to just pixel shaders and compute shaders in the Direct3D 11.0 runtime. For the Direct3D 11.1 runtime, because unordered access views (UAV) are available at all shader stages, you can use these instructions in all shader stages.

Therefore, if you use the following shader model 5.0 instructions in a vertex shader, you can successfully pass the compiled vertex shader to pShaderBytecode. That is, the call to CreateVertexShader succeeds.

If you pass a compiled shader to pShaderBytecode that uses any of the following instructions on a device that doesn?t support UAVs at every shader stage (including existing drivers that are not implemented to support UAVs at every shader stage), CreateVertexShader fails. CreateVertexShader also fails if the shader tries to use a UAV slot beyond the set of UAV slots that the hardware supports.

• dcl_uav_typed
• dcl_uav_raw
• dcl_uav_structured
• ld_raw
• ld_structured
• ld_uav_typed
• store_raw
• store_structured
• store_uav_typed
• sync_uglobal
• All atomics and immediate atomics (for example, atomic_and and imm_atomic_and)

After it is created, the shader can be set to the device by calling .

The Direct3D 11.1 runtime, which is available starting with Windows?8, provides the following new functionality for CreateGeometryShader.

The following shader model 5.0 instructions are available to just pixel shaders and compute shaders in the Direct3D 11.0 runtime. For the Direct3D 11.1 runtime, because unordered access views (UAV) are available at all shader stages, you can use these instructions in all shader stages.

Therefore, if you use the following shader model 5.0 instructions in a geometry shader, you can successfully pass the compiled geometry shader to pShaderBytecode. That is, the call to CreateGeometryShader succeeds.

If you pass a compiled shader to pShaderBytecode that uses any of the following instructions on a device that doesn?t support UAVs at every shader stage (including existing drivers that are not implemented to support UAVs at every shader stage), CreateGeometryShader fails. CreateGeometryShader also fails if the shader tries to use a UAV slot beyond the set of UAV slots that the hardware supports.

• dcl_uav_typed
• dcl_uav_raw
• dcl_uav_structured
• ld_raw
• ld_structured
• ld_uav_typed
• store_raw
• store_structured
• store_uav_typed
• sync_uglobal
• All atomics and immediate atomics (for example, atomic_and and imm_atomic_and)

For more info about using CreateGeometryShaderWithStreamOutput, see Create a Geometry-Shader Object with Stream Output.

The Direct3D 11.1 runtime, which is available starting with Windows?8, provides the following new functionality for CreateGeometryShaderWithStreamOutput.

The following shader model 5.0 instructions are available to just pixel shaders and compute shaders in the Direct3D 11.0 runtime. For the Direct3D 11.1 runtime, because unordered access views (UAV) are available at all shader stages, you can use these instructions in all shader stages.

Therefore, if you use the following shader model 5.0 instructions in a geometry shader, you can successfully pass the compiled geometry shader to pShaderBytecode. That is, the call to CreateGeometryShaderWithStreamOutput succeeds.

If you pass a compiled shader to pShaderBytecode that uses any of the following instructions on a device that doesn?t support UAVs at every shader stage (including existing drivers that are not implemented to support UAVs at every shader stage), CreateGeometryShaderWithStreamOutput fails. CreateGeometryShaderWithStreamOutput also fails if the shader tries to use a UAV slot beyond the set of UAV slots that the hardware supports.

• dcl_uav_typed
• dcl_uav_raw
• dcl_uav_structured
• ld_raw
• ld_structured
• ld_uav_typed
• store_raw
• store_structured
• store_uav_typed
• sync_uglobal
• All atomics and immediate atomics (for example, atomic_and and imm_atomic_and)

Windows?Phone?8: This API is supported.

After creating the pixel shader, you can set it to the device using .

The Direct3D 11.1 runtime, which is available starting with Windows?8, provides the following new functionality for CreateHullShader.

The following shader model 5.0 instructions are available to just pixel shaders and compute shaders in the Direct3D 11.0 runtime. For the Direct3D 11.1 runtime, because unordered access views (UAV) are available at all shader stages, you can use these instructions in all shader stages.

Therefore, if you use the following shader model 5.0 instructions in a hull shader, you can successfully pass the compiled hull shader to pShaderBytecode. That is, the call to CreateHullShader succeeds.

If you pass a compiled shader to pShaderBytecode that uses any of the following instructions on a device that doesn?t support UAVs at every shader stage (including existing drivers that are not implemented to support UAVs at every shader stage), CreateHullShader fails. CreateHullShader also fails if the shader tries to use a UAV slot beyond the set of UAV slots that the hardware supports.

• dcl_uav_typed
• dcl_uav_raw
• dcl_uav_structured
• ld_raw
• ld_structured
• ld_uav_typed
• store_raw
• store_structured
• store_uav_typed
• sync_uglobal
• All atomics and immediate atomics (for example, atomic_and and imm_atomic_and)

The Direct3D 11.1 runtime, which is available starting with Windows?8, provides the following new functionality for CreateDomainShader.

The following shader model 5.0 instructions are available to just pixel shaders and compute shaders in the Direct3D 11.0 runtime. For the Direct3D 11.1 runtime, because unordered access views (UAV) are available at all shader stages, you can use these instructions in all shader stages.

Therefore, if you use the following shader model 5.0 instructions in a domain shader, you can successfully pass the compiled domain shader to pShaderBytecode. That is, the call to CreateDomainShader succeeds.

If you pass a compiled shader to pShaderBytecode that uses any of the following instructions on a device that doesn?t support UAVs at every shader stage (including existing drivers that are not implemented to support UAVs at every shader stage), CreateDomainShader fails. CreateDomainShader also fails if the shader tries to use a UAV slot beyond the set of UAV slots that the hardware supports.

• dcl_uav_typed
• dcl_uav_raw
• dcl_uav_structured
• ld_raw
• ld_structured
• ld_uav_typed
• store_raw
• store_structured
• store_uav_typed
• sync_uglobal
• All atomics and immediate atomics (for example, atomic_and and imm_atomic_and)

For an example, see How To: Create a Compute Shader and HDRToneMappingCS11 Sample.

The interface returned in ppLinkage is associated with a shader by passing it as a parameter to one of the create shader methods such as .

An application can create up to 4096 unique blend-state objects. For each object created, the runtime checks to see if a previous object has the same state. If such a previous object exists, the runtime will return a reference to previous instance instead of creating a duplicate object.

Windows?Phone?8: This API is supported.

4096 unique depth-stencil state objects can be created on a device at a time.

If an application attempts to create a depth-stencil-state interface with the same state as an existing interface, the same interface will be returned and the total number of unique depth-stencil state objects will stay the same.

4096 unique rasterizer state objects can be created on a device at a time.

If an application attempts to create a rasterizer-state interface with the same state as an existing interface, the same interface will be returned and the total number of unique rasterizer state objects will stay the same.

4096 unique sampler state objects can be created on a device at a time.

If an application attempts to create a sampler-state interface with the same state as an existing interface, the same interface will be returned and the total number of unique sampler state objects will stay the same.

A deferred context is a thread-safe context that you can use to record graphics commands on a thread other than the main rendering thread. Using a deferred context, you can record graphics commands into a command list that is encapsulated by the interface. After all scene items are recorded, you can then submit them to the main render thread for final rendering. In this manner, you can perform rendering tasks concurrently across multiple threads and potentially improve performance in multi-core CPU scenarios.

You can create multiple deferred contexts.

For more information about deferred contexts, see Immediate and Deferred Rendering.

Windows?Phone?8: This API is supported.

The REFIID, or , of the interface to the resource can be obtained by using the __uuidof() macro. For example, __uuidof() will get the of the interface to a buffer resource.

The unique handle of the resource is obtained differently depending on the type of device that originally created the resource.

To share a resource between two Direct3D 11 devices the resource must have been created with the flag, if it was created using the interface. If it was created using a DXGI device interface, then the resource is always shared.

The REFIID, or , of the interface to the resource can be obtained by using the __uuidof() macro. For example, __uuidof() will get the of the interface to a buffer resource.

When sharing a resource between two Direct3D 10/11 devices the unique handle of the resource can be obtained by querying the resource for the interface and then calling GetSharedHandle.

 * pOtherResource(null);	
            hr = pOtherDeviceResource->QueryInterface( __uuidof(), (void**)&pOtherResource );	
            HANDLE sharedHandle;	
            pOtherResource->GetSharedHandle(&sharedHandle); 

The only resources that can be shared are 2D non-mipmapped textures.

To share a resource between a Direct3D 9 device and a Direct3D 11 device the texture must have been created using the pSharedHandle argument of CreateTexture. The shared Direct3D 9 handle is then passed to OpenSharedResource in the hResource argument.

The following code illustrates the method calls involved.

 sharedHandle = null; // must be set to null to create, can use a valid handle here to open in D3D9 	
            pDevice9->CreateTexture(..., pTex2D_9, &sharedHandle); 	
            ... 	
            pDevice11->OpenSharedResource(sharedHandle, __uuidof(), (void**)(&tempResource11)); 	
            tempResource11->QueryInterface(__uuidof(), (void**)(&pTex2D_11)); 	
            tempResource11->Release(); 	
            // now use pTex2D_11 with pDevice11    

Textures being shared from D3D9 to D3D11 have the following restrictions.

• Textures must be 2D
• Only 1 mip level is allowed
• Texture must have default usage
• Texture must be write only
• MSAA textures are not allowed
• Bind flags must have SHADER_RESOURCE and RENDER_TARGET set
• Only R10G10B10A2_UNORM, R16G16B16A16_FLOAT and R8G8B8A8_UNORM formats are allowed

If a shared texture is updated on one device must be called on that device.

When multisampling a texture, the number of quality levels available for an adapter is dependent on the texture format used and the number of samples requested. The maximum number of quality levels is defined by in D3D11.h. If this method returns 0, the format and sample count combination is not supported for the installed adapter.

Furthermore, the definition of a quality level is up to each hardware vendor to define, however no facility is provided by Direct3D to help discover this information.

Note that FEATURE_LEVEL_10_1 devices are required to support 4x MSAA for all render targets except R32G32B32A32 and R32G32B32. FEATURE_LEVEL_11_0 devices are required to support 4x MSAA for all render target formats, and 8x MSAA for all render target formats except R32G32B32A32 formats.

Length parameters can be null, which indicates the application is not interested in the length nor the corresponding string value. When a length parameter is non-null and the corresponding string is null, the input value of the length parameter is ignored, and the length of the corresponding string (including terminating null) will be returned through the length parameter. When length and the corresponding parameter are both non-null, the input value of length is checked to ensure there is enough room, and then the length of the string (including terminating null character) is passed out through the length parameter.

Windows?Phone?8: This API is supported.

To query for multi-threading support, pass the value to the Feature parameter, pass the structure to the pFeatureSupportData parameter, and pass the size of the structure to the FeatureSupportDataSize parameter.

Calling CheckFeatureSupport with Feature set to causes the method to return the same information that would be returned by .

The data stored in the device with this method can be retrieved with .

The data and guid set with this method will typically be application-defined.

The debug layer reports memory leaks by outputting a list of object interface references along with their friendly names. The default friendly name is "<unnamed>". You can set the friendly name so that you can determine if the corresponding object interface reference caused the leak. To set the friendly name, use the SetPrivateData method and the that is in D3Dcommon.h. For example, to give pContext a friendly name of My name, use the following code:

 static const char c_szName[] = "My name";	
            hr = pContext->SetPrivateData( , sizeof( c_szName ) - 1, c_szName );	
            

Feature levels determine the capabilities of your device.

The GetImmediateContext method returns an object that represents an immediate context which is used to perform rendering that you want immediately submitted to a device. For most applications, an immediate context is the primary object that is used to draw your scene.

The GetImmediateContext method increments the reference count of the immediate context by one. Therefore, you must call Release on the returned interface reference when you are done with it to avoid a memory leak.

Set an exception-mode flag to elevate an error condition to a non-continuable exception.

Whenever an error occurs, a Direct3D device enters the DEVICEREMOVED state and if the appropriate exception flag has been set, an exception is raised. A raised exception is designed to terminate an application. Before termination, the last chance an application has to persist data is by using an UnhandledExceptionFilter (see Structured Exception Handling). In general, UnhandledExceptionFilters are leveraged to try to persist data when an application is crashing (to disk, for example). Any code that executes during an UnhandledExceptionFilter is not guaranteed to reliably execute (due to possible process corruption). Any data that the UnhandledExceptionFilter manages to persist, before the UnhandledExceptionFilter crashes again, should be treated as suspect, and therefore inspected by a new, non-corrupted process to see if it is usable.

An exception-mode flag is used to elevate an error condition to a non-continuable exception.

GetImmediateContext1 returns an object that represents an immediate context. You can use this immediate context to perform rendering that you want immediately submitted to a device. For most applications, an immediate context is the primary object that is used to draw your scene.

GetImmediateContext1 increments the reference count of the immediate context by one. So, call Release on the returned interface reference when you are done with it to avoid a memory leak.

GetImmediateContext1 returns an object that represents an immediate context. You can use this immediate context to perform rendering that you want immediately submitted to a device. For most applications, an immediate context is the primary object that is used to draw your scene.

GetImmediateContext1 increments the reference count of the immediate context by one. So, call Release on the returned interface reference when you are done with it to avoid a memory leak.

A deferred context is a thread-safe context that you can use to record graphics commands on a thread other than the main rendering thread. By using a deferred context, you can record graphics commands into a command list that is encapsulated by the interface. After you record all scene items, you can then submit them to the main render thread for final rendering. In this manner, you can perform rendering tasks concurrently across multiple threads and potentially improve performance in multi-core CPU scenarios.

You can create multiple deferred contexts.

For more information about deferred contexts, see Immediate and Deferred Rendering.

Windows?Phone?8: This API is supported.

The logical operations (those that enable bitwise logical operations between pixel shader output and render target contents, refer to ) are only available on certain feature levels; call CheckFeatureSupport with set, to ensure support by checking the boolean field OutputMergerLogicOp of .

An app can create up to 4096 unique blend-state objects. For each object created, the runtime checks to see if a previous object has the same state. If such a previous object exists, the runtime will return a reference to previous instance instead of creating a duplicate object.

An app can create up to 4096 unique rasterizer state objects. For each object created, the runtime checks to see if a previous object has the same state. If such a previous object exists, the runtime will return a reference to previous instance instead of creating a duplicate object.

The REFIID value of the emulated interface is a obtained by use of the __uuidof operator. For example, __uuidof() gets the of the interface to a Microsoft Direct3D?11 device.

Call the method to activate the context state object. When the context state object is active, the device behaviors that are associated with both the context state object's feature level and its compatible interface are activated on the Direct3D device until the next call to SwapDeviceContextState.

When a context state object is active, the runtime disables certain methods on the device and context interfaces. For example, a context state object that is created with __uuidof() will cause the runtime to turn off most of the Microsoft Direct3D?10 device interfaces, and a context state object that is created with __uuidof(ID3D10Device1) or __uuidof(ID3D10Device) will cause the runtime to turn off most of the methods. This behavior ensures that a user of either emulated interface cannot set device state that the other emulated interface is unable to express. This restriction helps guarantee that the ID3D10Device1 emulated interface accurately reflects the full state of the pipeline and that the emulated interface will not operate contrary to its original interface definition.

For example, suppose the tessellation stage is made active through the interface when you create the device through or D3D11CreateDeviceAndSwapChain, instead of through the Direct3D?10 equivalents. Because the Direct3D?11 context is active, a Direct3D?10 interface is inactive when you first retrieve it via QueryInterface. This means that you cannot immediately pass a Direct3D?10 interface that you retrieved from a Direct3D?11 device to a function. You must first call SwapDeviceContextState to activate a Direct3D?10-compatible context state object.

The following table shows the methods that are active and inactive for each emulated interface.

?

The following table shows the immediate context methods that the runtime disables when the indicated context state objects are active.

?

The following table shows the immediate context methods that the runtime does not disable when the indicated context state objects are active.

?

The following table shows the ID3D10Device interface methods that the runtime does not disable because they are not immediate context methods.

?

Windows?Phone?8: This API is supported.

The REFIID, or , of the interface to the resource can be obtained by using the __uuidof() macro. For example, __uuidof() will get the of the interface to a buffer resource.

The unique handle of the resource is obtained differently depending on the type of device that originally created the resource.

To share a resource between two Direct3D 11 devices the resource must have been created with the flag, if it was created using the interface. If it was created using a DXGI device interface, then the resource is always shared.

The REFIID, or , of the interface to the resource can be obtained by using the __uuidof() macro. For example, __uuidof() will get the of the interface to a buffer resource.

When sharing a resource between two Direct3D 10/11 devices the unique handle of the resource can be obtained by querying the resource for the interface and then calling GetSharedHandle.

 * pOtherResource(null);	
            hr = pOtherDeviceResource->QueryInterface( __uuidof(), (void**)&pOtherResource );	
            HANDLE sharedHandle;	
            pOtherResource->GetSharedHandle(&sharedHandle); 

The only resources that can be shared are 2D non-mipmapped textures.

To share a resource between a Direct3D 9 device and a Direct3D 11 device the texture must have been created using the pSharedHandle argument of CreateTexture. The shared Direct3D 9 handle is then passed to OpenSharedResource in the hResource argument.

The following code illustrates the method calls involved.

 sharedHandle = null; // must be set to null to create, can use a valid handle here to open in D3D9 	
            pDevice9->CreateTexture(..., pTex2D_9, &sharedHandle); 	
            ... 	
            pDevice11->OpenSharedResource(sharedHandle, __uuidof(), (void**)(&tempResource11)); 	
            tempResource11->QueryInterface(__uuidof(), (void**)(&pTex2D_11)); 	
            tempResource11->Release(); 	
            // now use pTex2D_11 with pDevice11    

Textures being shared from D3D9 to D3D11 have the following restrictions.

• Textures must be 2D
• Only 1 mip level is allowed
• Texture must have default usage
• Texture must be write only
• MSAA textures are not allowed
• Bind flags must have SHADER_RESOURCE and RENDER_TARGET set
• Only R10G10B10A2_UNORM, R16G16B16A16_FLOAT and R8G8B8A8_UNORM formats are allowed

If a shared texture is updated on one device must be called on that device.

The behavior of OpenSharedResourceByName is similar to the behavior of the method; each call to OpenSharedResourceByName to access a resource creates a new resource object. In other words, if you call OpenSharedResourceByName twice and pass the same resource name to lpName, you receive two resource objects with different references.

To share a resource between two devices

1. Create the resource as shared and specify that it uses NT handles, by setting the flag.
2. Obtain the REFIID, or , of the interface to the resource by using the __uuidof() macro. For example, __uuidof() retrieves the of the interface to a 2D texture.
3. Query the resource for the interface.
4. Call the method to obtain the unique handle to the resource. In this call, you must pass a name for the resource if you want to subsequently call OpenSharedResourceByName to access the resource by name.

The GetImmediateContext2 method returns an object that represents an immediate context, which is used to perform rendering that you want immediately submitted to a device. For most apps, an immediate context is the primary object that is used to draw your scene.

The GetImmediateContext2 method increments the reference count of the immediate context by one. Therefore, you must call Release on the returned interface reference when you are done with it to avoid a memory leak.

The GetImmediateContext2 method returns an object that represents an immediate context, which is used to perform rendering that you want immediately submitted to a device. For most apps, an immediate context is the primary object that is used to draw your scene.

The GetImmediateContext2 method increments the reference count of the immediate context by one. Therefore, you must call Release on the returned interface reference when you are done with it to avoid a memory leak.

A deferred context is a thread-safe context that you can use to record graphics commands on a thread other than the main rendering thread. By using a deferred context, you can record graphics commands into a command list that is encapsulated by the interface. After you record all scene items, you can then submit them to the main render thread for final rendering. In this manner, you can perform rendering tasks concurrently across multiple threads and potentially improve performance in multi-core CPU scenarios.

You can create multiple deferred contexts.

For more information about deferred contexts, see Immediate and Deferred Rendering.

For more info about tiled resources, see Tiled resources.

When you multisample a texture, the number of quality levels available for an adapter is dependent on the texture format that you use and the number of samples that you request. The maximum number of quality levels is defined by in D3D11.h. If this method returns 0, the format and sample count combination is not supported for the installed adapter.

Furthermore, the definition of a quality level is up to each hardware vendor to define, however no facility is provided by Direct3D to help discover this information.

Note that FEATURE_LEVEL_10_1 devices are required to support 4x MSAA for all render targets except R32G32B32A32 and R32G32B32. FEATURE_LEVEL_11_0 devices are required to support 4x MSAA for all render target formats, and 8x MSAA for all render target formats except R32G32B32A32 formats.

The GetImmediateContext3 method outputs an object that represents an immediate context, which is used to perform rendering that you want immediately submitted to a device. For most apps, an immediate context is the primary object that is used to draw your scene.

The GetImmediateContext3 method increments the reference count of the immediate context by one. Therefore, you must call Release on the returned interface reference when you are done with it to avoid a memory leak.

CreateTexture2D1 creates a 2D texture resource, which can contain a number of 2D subresources. The number of subresources is specified in the texture description. All textures in a resource must have the same format, size, and number of mipmap levels.

All resources are made up of one or more subresources. To load data into the texture, applications can supply the data initially as an array of structures pointed to by pInitialData, or they can use one of the D3DX texture functions such as D3DX11CreateTextureFromFile.

For a 32 x 32 texture with a full mipmap chain, the pInitialData array has the following 6 elements:

• pInitialData[0] = 32x32
• pInitialData[1] = 16x16
• pInitialData[2] = 8x8
• pInitialData[3] = 4x4
• pInitialData[4] = 2x2
• pInitialData[5] = 1x1

CreateTexture3D1 creates a 3D texture resource, which can contain a number of 3D subresources. The number of textures is specified in the texture description. All textures in a resource must have the same format, size, and number of mipmap levels.

All resources are made up of one or more subresources. To load data into the texture, applications can supply the data initially as an array of structures pointed to by pInitialData, or they can use one of the D3DX texture functions such as D3DX11CreateTextureFromFile.

Each element of pInitialData provides all of the slices that are defined for a given miplevel. For example, for a 32 x 32 x 4 volume texture with a full mipmap chain, the array has the following 6 elements:

• pInitialData[0] = 32x32 with 4 slices
• pInitialData[1] = 16x16 with 2 slices
• pInitialData[2] = 8x8 with 1 slice
• pInitialData[3] = 4x4 with 1 slice
• pInitialData[4] = 2x2 with 1 slice
• pInitialData[5] = 1x1 with 1 slice

A render-target view can be bound to the output-merger stage by calling .

The GetImmediateContext3 method outputs an object that represents an immediate context, which is used to perform rendering that you want immediately submitted to a device. For most apps, an immediate context is the primary object that is used to draw your scene.

The GetImmediateContext3 method increments the reference count of the immediate context by one. Therefore, you must call Release on the returned interface reference when you are done with it to avoid a memory leak.

The provided resource must be a texture which was mapped for writing by a previous call to ID3D11DeviceContext3::Map while providing a null parameter.

This API is intended for calling at high frequency. Callers can reduce memory by making iterative calls that update progressive regions of the texture, while provide a small buffer during each call. It is most efficient to specify large enough regions, though, because this enables D3D to fill whole cache lines in the texture before returning.

For efficiency, ensure the bounds and alignment of the extents within the box are ( 64 / [bytes per pixel] ) pixels horizontally. Vertical bounds and alignment should be 2 rows, except when 1-byte-per-pixel formats are used, in which case 4 rows are recommended. Single depth slices per call are handled efficiently. It is recommended but not necessary to provide references and strides which are 128-byte aligned.

When writing to sub mipmap levels, it is recommended to use larger width and heights than described above. This is because small mipmap levels may actually be stored within a larger block of memory, with an opaque amount of offsetting which can interfere with alignment to cache lines.

The provided resource must be a texture which was mapped for writing by a previous call to ID3D11DeviceContext3::Map while providing a null parameter.

This API is intended for calling at high frequency. Callers can reduce memory by making iterative calls that update progressive regions of the texture, while provide a small buffer during each call. It is most efficient to specify large enough regions, though, because this enables D3D to fill whole cache lines in the texture before returning.

For efficiency, ensure the bounds and alignment of the extents within the box are ( 64 / [Bytes per pixel] ) pixels horizontally. Vertical bounds and alignment should be 2 rows, except when 1-byte-per-pixel formats are used, in which case 4 rows are recommended. Single depth slices per call are handled efficiently. It is recommended but not necessary to provide references and strides which are 128-byte aligned.

When reading from sub mipmap levels, it is recommended to use larger width and heights than described above. This is because small mipmap levels may actually be stored within a larger block of memory, with an opaque amount of offseting which can interfere with alignment to cache lines.

A device is created using .

Windows?Phone?8: This API is supported.

There are several types of device child interfaces, all of which inherit this interface. They include shaders, state objects, and input layouts.

Windows?Phone?8: This API is supported.

Any returned interfaces will have their reference count incremented by one, so be sure to call ::release() on the returned reference(s) before they are freed or else you will have a memory leak.

Any returned interfaces will have their reference count incremented by one, so be sure to call ::release() on the returned reference(s) before they are freed or else you will have a memory leak.

The data stored in the device child is set by calling .

Windows?Phone?8: This API is supported.

The data stored in the device child with this method can be retrieved with .

The debug layer reports memory leaks by outputting a list of object interface references along with their friendly names. The default friendly name is "<unnamed>". You can set the friendly name so that you can determine if the corresponding object interface reference caused the leak. To set the friendly name, use the SetPrivateData method and the that is in D3Dcommon.h. For example, to give pContext a friendly name of My name, use the following code:

 static const char c_szName[] = "My name";	
            hr = pContext->SetPrivateData( , sizeof( c_szName ) - 1, c_szName );	
            

When this method is called ::addref() will be called on the -derived interface, and when the device child is detroyed ::release() will be called on the -derived interface.

If an overlapping resource view is already bound to an output slot, such as a render target, then the method will fill the destination shader resource slot with null.

For information about creating shader-resource views, see .

The method will hold a reference to the interfaces passed in. This differs from the device state behavior in Direct3D 10.

Windows?Phone?8: This API is supported.

The method will hold a reference to the interfaces passed in. This differs from the device state behavior in Direct3D 10.

The maximum number of instances a shader can have is 256.

The method will hold a reference to the interfaces passed in. This differs from the device state behavior in Direct3D 10.

The maximum number of instances a shader can have is 256.

The method will hold a reference to the interfaces passed in. This differs from the device state behavior in Direct3D 10.

The maximum number of instances a shader can have is 256.

Any sampler may be set to null; this invokes the default state, which is defined to be the following.

//Default sampler state:	
             SamplerDesc;	
            SamplerDesc.Filter = ;	
            SamplerDesc.AddressU = ;	
            SamplerDesc.AddressV = ;	
            SamplerDesc.AddressW = ;	
            SamplerDesc.MipLODBias = 0;	
            SamplerDesc.MaxAnisotropy = 1;	
            SamplerDesc.ComparisonFunc = ;	
            SamplerDesc.BorderColor[0] = 1.0f;	
            SamplerDesc.BorderColor[1] = 1.0f;	
            SamplerDesc.BorderColor[2] = 1.0f;	
            SamplerDesc.BorderColor[3] = 1.0f;	
            SamplerDesc.MinLOD = -FLT_MAX;	
            SamplerDesc.MaxLOD = FLT_MAX; 

The method will hold a reference to the interfaces passed in. This differs from the device state behavior in Direct3D 10.

The method will hold a reference to the interfaces passed in. This differs from the device state behavior in Direct3D 10.

The Direct3D 11.1 runtime, which is available starting with Windows?8, can bind a larger number of resources to the shader than the maximum constant buffer size that is supported by shaders (4096 constants ? 4*32-bit components each). When you bind such a large buffer, the shader can access only the first 4096 4*32-bit component constants in the buffer, as if 4096 constants is the full size of the buffer.

If the application wants the shader to access other parts of the buffer, it must call the CSSetConstantBuffers1 method instead.

Any returned interfaces will have their reference count incremented by one. Applications should call IUnknown::Release on the returned interfaces when they are no longer needed to avoid memory leaks.

Any returned interfaces will have their reference count incremented by one. Applications should call IUnknown::Release on the returned interfaces when they are no longer needed to avoid memory leaks.

Any returned interfaces will have their reference count incremented by one. Applications should call IUnknown::Release on the returned interfaces when they are no longer needed to avoid memory leaks.

Any returned interfaces will have their reference count incremented by one. Applications should call IUnknown::Release on the returned interfaces when they are no longer needed to avoid memory leaks.

Any returned interfaces will have their reference count incremented by one. Applications should call IUnknown::Release on the returned interfaces when they are no longer needed to avoid memory leaks.

If you call Map on a deferred context, you can only pass , , or both to the MapType parameter. Other -typed values are not supported for a deferred context.

The Direct3D 11.1 runtime, which is available starting with Windows Developer Preview, can map shader resource views (SRVs) of dynamic buffers with . The Direct3D 11 and earlier runtimes limited mapping to vertex or index buffers.

The GetContextFlags method gets the flags that were supplied to the ContextFlags parameter of ; however, the context flag is reserved for future use.

A draw API submits work to the rendering pipeline.

If the sum of both indices is negative, the result of the function call is undefined.

Draw submits work to the rendering pipeline.

The vertex data for a draw call normally comes from a vertex buffer that is bound to the pipeline.

Even without any vertex buffer bound to the pipeline, you can generate your own vertex data in your vertex shader by using the SV_VertexID system-value semantic to determine the current vertex that the runtime is processing.

If you call Map on a deferred context, you can only pass , , or both to the MapType parameter. Other -typed values are not supported for a deferred context.

For info about how to use Map, see How to: Use dynamic resources.

For info about how to use Unmap, see How to: Use dynamic resources.

Windows?Phone?8: This API is supported.

A draw API submits work to the rendering pipeline.

Instancing may extend performance by reusing the same geometry to draw multiple objects in a scene. One example of instancing could be to draw the same object with different positions and colors. Instancing requires multiple vertex buffers: at least one for per-vertex data and a second buffer for per-instance data.

A draw API submits work to the rendering pipeline.

Instancing may extend performance by reusing the same geometry to draw multiple objects in a scene. One example of instancing could be to draw the same object with different positions and colors.

The vertex data for an instanced draw call normally comes from a vertex buffer that is bound to the pipeline. However, you could also provide the vertex data from a shader that has instanced data identified with a system-value semantic (SV_InstanceID).

Use to mark the ending of the series of commands.

Use to mark the beginning of the series of commands.

Queries in a deferred context are limited to predicated drawing. That is, you cannot call on a deferred context to get data about a query; you can only call GetData on the immediate context to get data about a query. For predicated drawing, the results of a predication-type query are used by the GPU and not returned to an application. For more information about predication and predicated drawing, see D3D11DeviceContext::SetPredication.

GetData retrieves the data that the runtime collected between calls to and . Certain queries only require a call to in which case the data returned by GetData is accurate up to the last call to . For information about the queries that only require a call to and about the type of data that GetData retrieves for each query, see .

If DataSize is 0, GetData is only used to check status.

An application gathers counter data by calling , issuing some graphics commands, calling , and then calling to get data about what happened in between the Begin and End calls. For information about performance counter types, see .

The predicate must be in the "issued" or "signaled" state to be used for predication. While the predicate is set for predication, calls to and are invalid.

Use this method to denote that subsequent rendering and resource manipulation commands are not actually performed if the resulting predicate data of the predicate is equal to the PredicateValue. However, some predicates are only hints, so they may not actually prevent operations from being performed.

The primary usefulness of predication is to allow an application to issue rendering and resource manipulation commands without taking the performance hit of spinning, waiting for to return. So, predication can occur while returns S_FALSE. Another way to think of it: an application can also use predication as a fallback, if it is possible that returns S_FALSE. If returns , the application can skip calling the rendering and resource manipulation commands manually with it's own application logic.

Rendering and resource manipulation commands for Direct3D?11 include these Draw, Dispatch, Copy, Update, Clear, Generate, and Resolve operations.

• Draw
• DrawAuto
• DrawIndexed
• DrawIndexedInstanced
• DrawIndexedInstancedIndirect
• DrawInstanced
• DrawInstancedIndirect
• Dispatch
• DispatchIndirect
• CopyResource
• CopyStructureCount
• CopySubresourceRegion
• CopySubresourceRegion1
• CopyTiles
• CopyTileMappings
• UpdateSubresource
• UpdateSubresource1
• UpdateTiles
• UpdateTileMappings
• ClearRenderTargetView
• ClearUnorderedAccessViewFloat
• ClearUnorderedAccessViewUint
• ClearView
• ClearDepthStencilView
• GenerateMips
• ResolveSubresource

You can set a rendering predicate on an immediate or a deferred context. For info about immediate and deferred contexts, see Immediate and Deferred Rendering.

A draw API submits work to the rendering pipeline. This API submits work of an unknown size that was processed by the input assembler, vertex shader, and stream-output stages; the work may or may not have gone through the geometry-shader stage.

After data has been streamed out to stream-output stage buffers, those buffers can be again bound to the Input Assembler stage at input slot 0 and DrawAuto will draw them without the application needing to know the amount of data that was written to the buffers. A measurement of the amount of data written to the SO stage buffers is maintained internally when the data is streamed out. This means that the CPU does not need to fetch the measurement before re-binding the data that was streamed as input data. Although this amount is tracked internally, it is still the responsibility of applications to use input layouts to describe the format of the data in the SO stage buffers so that the layouts are available when the buffers are again bound to the input assembler.

The following diagram shows the DrawAuto process.

Calling DrawAuto does not change the state of the streaming-output buffers that were bound again as inputs.

DrawAuto only works when drawing with one input buffer bound as an input to the IA stage at slot 0. Applications must create the SO buffer resource with both binding flags, and .

This API does not support indexing or instancing.

If an application needs to retrieve the size of the streaming-output buffer, it can query for statistics on streaming output by using .

When an application creates a buffer that is associated with the interface that pBufferForArgs points to, the application must set the flag in the MiscFlags member of the structure that describes the buffer. To create the buffer, the application calls the method and in this call passes a reference to in the pDesc parameter.

Windows?Phone?8: This API is supported.

When an application creates a buffer that is associated with the interface that pBufferForArgs points to, the application must set the flag in the MiscFlags member of the structure that describes the buffer. To create the buffer, the application calls the method and in this call passes a reference to in the pDesc parameter.

You call the Dispatch method to execute commands in a compute shader. A compute shader can be run on many threads in parallel, within a thread group. Index a particular thread, within a thread group using a 3D vector given by (x,y,z).

In the following illustration, assume a thread group with 50 threads where the size of the group is given by (5,5,2). A single thread is identified from a thread group with 50 threads in it, using the vector (4,1,1).

The following illustration shows the relationship between the parameters passed to , Dispatch(5,3,2), the values specified in the numthreads attribute, numthreads(10,8,3), and values that will passed to the compute shader for the thread-related system values (SV_GroupIndex,SV_DispatchThreadID,SV_GroupThreadID,SV_GroupID).

ff476405 void ID3D11DeviceContext::Dispatch([In] unsigned int ThreadGroupCountX,[In] unsigned int ThreadGroupCountY,[In] unsigned int ThreadGroupCountZ) ID3D11DeviceContext::Dispatch

The source box must be within the size of the source resource. The destination offsets, (x, y, and z), allow the source box to be offset when writing into the destination resource; however, the dimensions of the source box and the offsets must be within the size of the resource. If you try and copy outside the destination resource or specify a source box that is larger than the source resource, the behavior of CopySubresourceRegion is undefined. If you created a device that supports the debug layer, the debug output reports an error on this invalid CopySubresourceRegion call. Invalid parameters to CopySubresourceRegion cause undefined behavior and might result in incorrect rendering, clipping, no copy, or even the removal of the rendering device.

If the resources are buffers, all coordinates are in bytes; if the resources are textures, all coordinates are in texels. D3D11CalcSubresource is a helper function for calculating subresource indexes.

CopySubresourceRegion performs the copy on the GPU (similar to a memcpy by the CPU). As a consequence, the source and destination resources:

• Must be different subresources (although they can be from the same resource).
• Must be the same type.
• Must have compatible DXGI formats (identical or from the same type group). For example, a texture can be copied to an texture since both of these formats are in the group. CopySubresourceRegion can copy between a few format types. For more info, see Format Conversion using Direct3D 10.1.
• May not be currently mapped.

CopySubresourceRegion only supports copy; it does not support any stretch, color key, or blend. CopySubresourceRegion can reinterpret the resource data between a few format types. For more info, see Format Conversion using Direct3D 10.1.

If your app needs to copy an entire resource, we recommend to use instead.

CopySubresourceRegion is an asynchronous call, which may be added to the command-buffer queue, this attempts to remove pipeline stalls that may occur when copying data. For more information about pipeline stalls, see performance considerations.

This method is unusual in that it causes the GPU to perform the copy operation (similar to a memcpy by the CPU). As a result, it has a few restrictions designed for improving performance. For instance, the source and destination resources:

• Must be different resources.
• Must be the same type.
• Must have identical dimensions (including width, height, depth, and size as appropriate).
• Must have compatible DXGI formats, which means the formats must be identical or at least from the same type group. For example, a texture can be copied to an texture since both of these formats are in the group. CopyResource can copy between a few format types. For more info, see Format Conversion using Direct3D 10.1.
• Can't be currently mapped.

CopyResource only supports copy; it doesn't support any stretch, color key, or blend. CopyResource can reinterpret the resource data between a few format types. For more info, see Format Conversion using Direct3D 10.1.

You can't use an Immutable resource as a destination. You can use a depth-stencil resource as either a source or a destination provided that the feature level is or greater. For feature levels 9_x, resources created with the flag can only be used as a source for CopyResource. Resources created with multisampling capability (see ) can be used as source and destination only if both source and destination have identical multisampled count and quality. If source and destination differ in multisampled count and quality or if one is multisampled and the other is not multisampled, the call to fails. Use to resolve a multisampled resource to a resource that is not multisampled.

The method is an asynchronous call, which may be added to the command-buffer queue. This attempts to remove pipeline stalls that may occur when copying data. For more info, see performance considerations.

We recommend to use instead if you only need to copy a portion of the data in a resource.

For a shader-constant buffer; set pDstBox to null. It is not possible to use this method to partially update a shader-constant buffer.

A resource cannot be used as a destination if:

• the resource is created with immutable or dynamic usage.
• the resource is created as a depth-stencil resource.
• the resource is created with multisampling capability (see ).

When UpdateSubresource returns, the application is free to change or even free the data pointed to by pSrcData because the method has already copied/snapped away the original contents.

The performance of UpdateSubresource depends on whether or not there is contention for the destination resource. For example, contention for a vertex buffer resource occurs when the application executes a Draw call and later calls UpdateSubresource on the same vertex buffer before the Draw call is actually executed by the GPU.

• When there is contention for the resource, UpdateSubresource will perform 2 copies of the source data. First, the data is copied by the CPU to a temporary storage space accessible by the command buffer. This copy happens before the method returns. A second copy is then performed by the GPU to copy the source data into non-mappable memory. This second copy happens asynchronously because it is executed by GPU when the command buffer is flushed.
• When there is no resource contention, the behavior of UpdateSubresource is dependent on which is faster (from the CPU's perspective): copying the data to the command buffer and then having a second copy execute when the command buffer is flushed, or having the CPU copy the data to the final resource location. This is dependent on the architecture of the underlying system.

To better understand the source row pitch and source depth pitch parameters, the following illustration shows a 3D volume texture.

Each block in this visual represents an element of data, and the size of each element is dependent on the resource's format. For example, if the resource format is , the size of each element would be 128 bits, or 16 bytes. This 3D volume texture has a width of two, a height of three, and a depth of four.

To calculate the source row pitch and source depth pitch for a given resource, use the following formulas:

• Source Row Pitch = [size of one element in bytes] * [number of elements in one row]
• Source Depth Pitch = [Source Row Pitch] * [number of rows (height)]

In the case of this example 3D volume texture where the size of each element is 16 bytes, the formulas are as follows:

• Source Row Pitch = 16 * 2 = 32
• Source Depth Pitch = 16 * 2 * 3 = 96

The following illustration shows the resource as it is laid out in memory.

For example, the following code snippet shows how to specify a destination region in a 2D texture. Assume the destination texture is 512x512 and the operation will copy the data pointed to by pData to [(120,100)..(200,220)] in the destination texture. Also assume that rowPitch has been initialized with the proper value (as explained above). front and back are set to 0 and 1 respectively, because by having front equal to back, the box is technically empty.

  destRegion;	
            destRegion.left = 120;	
            destRegion.right = 200;	
            destRegion.top = 100;	
            destRegion.bottom = 220;	
            destRegion.front = 0;	
            destRegion.back = 1; pd3dDeviceContext->UpdateSubresource( pDestTexture, 0, &destRegion, pData, rowPitch, 0 );	
            

The 1D case is similar. The following snippet shows how to specify a destination region in a 1D texture. Use the same assumptions as above, except that the texture is 512 in length.

  destRegion;	
            destRegion.left = 120;	
            destRegion.right = 200;	
            destRegion.top = 0;	
            destRegion.bottom = 1;	
            destRegion.front = 0;	
            destRegion.back = 1; pd3dDeviceContext->UpdateSubresource( pDestTexture, 0, &destRegion, pData, rowPitch, 0 );	
            

For info about various resource types and how UpdateSubresource might work with each resource type, see Introduction to a Resource in Direct3D 11.

Applications that wish to clear a render target to a specific integer value bit pattern should render a screen-aligned quad instead of using this method. The reason for this is because this method accepts as input a floating point value, which may not have the same bit pattern as the original integer.

?

When using D3D_FEATURE_LEVEL_9_x, ClearRenderTargetView only clears the first array slice in the render target view. This can impact (for example) cube map rendering scenarios. Applications should create a render target view for each face or array slice, then clear each view individually.

This API copies the lower ni bits from each array element i to the corresponding channel, where ni is the number of bits in the ith channel of the resource format (for example, R8G8B8_FLOAT has 8 bits for the first 3 channels). This works on any UAV with no format conversion. For a raw or structured buffer view, only the first array element value is used.

This API works on FLOAT, UNORM, and SNORM unordered access views (UAVs), with format conversion from FLOAT to *NORM where appropriate. On other UAVs, the operation is invalid and the call will not reach the driver.

?

You can call GenerateMips on any shader-resource view to generate the lower mipmap levels for the shader resource. GenerateMips uses the largest mipmap level of the view to recursively generate the lower levels of the mip and stops with the smallest level that is specified by the view. If the base resource wasn't created with , , and , the call to GenerateMips has no effect.

Feature levels 9.1, 9.2, and 9.3 can't support automatic generation of mipmaps for 3D (volume) textures.

Video adapters that support feature level 9.1 and higher support generating mipmaps if you use any of these formats:

Video adapters that support feature level 9.2 and higher support generating mipmaps if you use any of these formats in addition to any of the formats for feature level 9.1:

Video adapters that support feature level 9.3 and higher support generating mipmaps if you use any of these formats in addition to any of the formats for feature levels 9.1 and 9.2:

 	
            DXGI_FORMAT_B4G4R4A4 (optional)	
            

Video adapters that support feature level 10 and higher support generating mipmaps if you use any of these formats in addition to any of the formats for feature levels 9.1, 9.2, and 9.3:

  (optional)	
            	
            	
            	
            	
            	
            	
            	
            	
            	
            	
            	
            	
            	
            	
             (optional)	
            

For all other unsupported formats, GenerateMips will silently fail.

To use a resource with SetResourceMinLOD, you must set the flag when you create that resource.

For Direct3D 10 and Direct3D 10.1, when sampling from a texture resource in a shader, the sampler can define a minimum LOD clamp to force sampling from less detailed mip levels. For Direct3D 11, this functionality is extended from the sampler to the entire resource. Therefore, the application can specify the highest-resolution mip level of a resource that is available for access. This restricts the set of mip levels that are required to be resident in GPU memory, thereby saving memory.

The set of mip levels resident per-resource in GPU memory can be specified by the user.

Minimum LOD affects all of the resident mip levels. Therefore, only the resident mip levels can be updated and read from.

All methods that access texture resources must adhere to minimum LOD clamps.

Empty-set accesses are handled as out-of-bounds cases.

This API is most useful when re-using the resulting rendertarget of one render pass as an input to a second render pass.

The source and destination resources must be the same resource type and have the same dimensions. In addition, they must have compatible formats. There are three scenarios for this:

?

Use this method to play back a command list that was recorded by a deferred context on any thread.

A call to ExecuteCommandList of a command list from a deferred context onto the immediate context is required for the recorded commands to be executed on the graphics processing unit (GPU). A call to ExecuteCommandList of a command list from a deferred context onto another deferred context can be used to merge recorded lists. But to run the commands from the merged deferred command list on the GPU, you need to execute them on the immediate context.

This method performs some runtime validation related to queries. Queries that are begun in a device context cannot be manipulated indirectly by executing a command list (that is, Begin or End was invoked against the same query by the deferred context which generated the command list). If such a condition occurs, the ExecuteCommandList method does not execute the command list. However, the state of the device context is still maintained, as would be expected ( is performed, unless the application indicates to preserve the device context state).

Windows?Phone?8: This API is supported.

Any returned interfaces will have their reference count incremented by one. Applications should call IUnknown::Release on the returned interfaces when they are no longer needed to avoid memory leaks.

This method resets any device context to the default settings. This sets all input/output resource slots, shaders, input layouts, predications, scissor rectangles, depth-stencil state, rasterizer state, blend state, sampler state, and viewports to null. The primitive topology is set to UNDEFINED.

For a scenario where you would like to clear a list of commands recorded so far, call and throw away the resulting .

Most applications don't need to call this method. If an application calls this method when not necessary, it incurs a performance penalty. Each call to Flush incurs a significant amount of overhead.

When Microsoft Direct3D state-setting, present, or draw commands are called by an application, those commands are queued into an internal command buffer. Flush sends those commands to the GPU for processing. Typically, the Direct3D runtime sends these commands to the GPU automatically whenever the runtime determines that they need to be sent, such as when the command buffer is full or when an application maps a resource. Flush sends the commands manually.

We recommend that you use Flush when the CPU waits for an arbitrary amount of time (such as when you call the Sleep function).

Because Flush operates asynchronously, it can return either before or after the GPU finishes executing the queued graphics commands. However, the graphics commands eventually always complete. You can call the method with the value to create an event query; you can then use that event query in a call to the method to determine when the GPU is finished processing the graphics commands.

Microsoft Direct3D?11 defers the destruction of objects. Therefore, an application can't rely upon objects immediately being destroyed. By calling Flush, you destroy any objects whose destruction was deferred. If an application requires synchronous destruction of an object, we recommend that the application release all its references, call , and then call Flush.

The GetContextFlags method gets the flags that were supplied to the ContextFlags parameter of ; however, the context flag is reserved for future use.

Create a command list from a deferred context and record commands into it by calling FinishCommandList. Play back a command list with an immediate context by calling .

Immediate context state is cleared before and after a command list is executed. A command list has no concept of inheritance. Each call to FinishCommandList will record only the state set since any previous call to FinishCommandList.

For example, the state of a device context is its render state or pipeline state. To retrieve device context state, an application can call or .

For more information about how to use FinishCommandList, see How to: Record a Command List.

Windows?Phone?8: This API is supported.

For information about creating vertex buffers, see Create a Vertex Buffer.

Calling this method using a buffer that is currently bound for writing (i.e. bound to the stream output pipeline stage) will effectively bind null instead because a buffer cannot be bound as both an input and an output at the same time.

The debug layer will generate a warning whenever a resource is prevented from being bound simultaneously as an input and an output, but this will not prevent invalid data from being used by the runtime.

The method will hold a reference to the interfaces passed in. This differs from the device state behavior in Direct3D 10.

For information about creating vertex buffers, see Create a Vertex Buffer.

Calling this method using a buffer that is currently bound for writing (i.e. bound to the stream output pipeline stage) will effectively bind null instead because a buffer cannot be bound as both an input and an output at the same time.

The debug layer will generate a warning whenever a resource is prevented from being bound simultaneously as an input and an output, but this will not prevent invalid data from being used by the runtime.

The method will hold a reference to the interfaces passed in. This differs from the device state behavior in Direct3D 10.

For information about creating vertex buffers, see Create a Vertex Buffer.

Calling this method using a buffer that is currently bound for writing (i.e. bound to the stream output pipeline stage) will effectively bind null instead because a buffer cannot be bound as both an input and an output at the same time.

The debug layer will generate a warning whenever a resource is prevented from being bound simultaneously as an input and an output, but this will not prevent invalid data from being used by the runtime.

The method will hold a reference to the interfaces passed in. This differs from the device state behavior in Direct3D 10.

For information about creating an input-layout object, see Creating the Input-Layout Object.

Any returned interfaces will have their reference count incremented by one. Applications should call IUnknown::Release on the returned interfaces when they are no longer needed to avoid memory leaks.

Input-layout objects describe how vertex buffer data is streamed into the IA pipeline stage. To create an input-layout object, call .

The method will hold a reference to the interfaces passed in. This differs from the device state behavior in Direct3D 10.

For info about creating vertex buffers, see How to: Create a Vertex Buffer.

Calling this method using a buffer that is currently bound for writing (that is, bound to the stream output pipeline stage) will effectively bind null instead because a buffer can't be bound as both an input and an output at the same time.

The debug layer will generate a warning whenever a resource is prevented from being bound simultaneously as an input and an output, but this will not prevent invalid data from being used by the runtime.

The method will hold a reference to the interfaces passed in. This differs from the device state behavior in Direct3D 10.

Windows?Phone?8: This API is supported.

For information about creating index buffers, see How to: Create an Index Buffer.

Calling this method using a buffer that is currently bound for writing (i.e. bound to the stream output pipeline stage) will effectively bind null instead because a buffer cannot be bound as both an input and an output at the same time.

The debug layer will generate a warning whenever a resource is prevented from being bound simultaneously as an input and an output, but this will not prevent invalid data from being used by the runtime.

The method will hold a reference to the interfaces passed in. This differs from the device state behavior in Direct3D 10.

Windows?Phone?8: This API is supported.

Windows?Phone?8: This API is supported.

For information about creating an input-layout object, see Creating the Input-Layout Object.

Any returned interfaces will have their reference count incremented by one. Applications should call IUnknown::Release on the returned interfaces when they are no longer needed to avoid memory leaks.

Any returned interfaces will have their reference count incremented by one. Applications should call IUnknown::Release on the returned interfaces when they are no longer needed to avoid memory leaks.

Any returned interfaces will have their reference count incremented by one. Applications should call IUnknown::Release on the returned interfaces when they are no longer needed to avoid memory leaks.

The maximum number of active render targets a device can have active at any given time is set by a #define in D3D11.h called D3D11_SIMULTANEOUS_RENDER_TARGET_COUNT. It is invalid to try to set the same subresource to multiple render target slots. Any render targets not defined by this call are set to null.

If any subresources are also currently bound for reading in a different stage or writing (perhaps in a different part of the pipeline), those bind points will be set to null, in order to prevent the same subresource from being read and written simultaneously in a single rendering operation.

The method will hold a reference to the interfaces passed in. This differs from the device state behavior in Direct3D 10.

If the render-target views were created from an array resource type, then all of the render-target views must have the same array size. This restriction also applies to the depth-stencil view, its array size must match that of the render-target views being bound.

The pixel shader must be able to simultaneously render to at least eight separate render targets. All of these render targets must access the same type of resource: Buffer, Texture1D, Texture1DArray, Texture2D, Texture2DArray, Texture3D, or TextureCube. All render targets must have the same size in all dimensions (width and height, and depth for 3D or array size for *Array types). If render targets use multisample anti-aliasing, all bound render targets and depth buffer must be the same form of multisample resource (that is, the sample counts must be the same). Each render target can have a different data format. These render target formats are not required to have identical bit-per-element counts.

Any combination of the eight slots for render targets can have a render target set or not set.

The same resource view cannot be bound to multiple render target slots simultaneously. However, you can set multiple non-overlapping resource views of a single resource as simultaneous multiple render targets.

The maximum number of active render targets a device can have active at any given time is set by a #define in D3D11.h called D3D11_SIMULTANEOUS_RENDER_TARGET_COUNT. It is invalid to try to set the same subresource to multiple render target slots. Any render targets not defined by this call are set to null.

If any subresources are also currently bound for reading in a different stage or writing (perhaps in a different part of the pipeline), those bind points will be set to null, in order to prevent the same subresource from being read and written simultaneously in a single rendering operation.

The method will hold a reference to the interfaces passed in. This differs from the device state behavior in Direct3D 10.

If the render-target views were created from an array resource type, then all of the render-target views must have the same array size. This restriction also applies to the depth-stencil view, its array size must match that of the render-target views being bound.

The pixel shader must be able to simultaneously render to at least eight separate render targets. All of these render targets must access the same type of resource: Buffer, Texture1D, Texture1DArray, Texture2D, Texture2DArray, Texture3D, or TextureCube. All render targets must have the same size in all dimensions (width and height, and depth for 3D or array size for *Array types). If render targets use multisample anti-aliasing, all bound render targets and depth buffer must be the same form of multisample resource (that is, the sample counts must be the same). Each render target can have a different data format. These render target formats are not required to have identical bit-per-element counts.

Any combination of the eight slots for render targets can have a render target set or not set.

The same resource view cannot be bound to multiple render target slots simultaneously. However, you can set multiple non-overlapping resource views of a single resource as simultaneous multiple render targets.

The maximum number of active render targets a device can have active at any given time is set by a #define in D3D11.h called D3D11_SIMULTANEOUS_RENDER_TARGET_COUNT. It is invalid to try to set the same subresource to multiple render target slots. Any render targets not defined by this call are set to null.

If any subresources are also currently bound for reading in a different stage or writing (perhaps in a different part of the pipeline), those bind points will be set to null, in order to prevent the same subresource from being read and written simultaneously in a single rendering operation.

The method will hold a reference to the interfaces passed in. This differs from the device state behavior in Direct3D 10.

If the render-target views were created from an array resource type, then all of the render-target views must have the same array size. This restriction also applies to the depth-stencil view, its array size must match that of the render-target views being bound.

The pixel shader must be able to simultaneously render to at least eight separate render targets. All of these render targets must access the same type of resource: Buffer, Texture1D, Texture1DArray, Texture2D, Texture2DArray, Texture3D, or TextureCube. All render targets must have the same size in all dimensions (width and height, and depth for 3D or array size for *Array types). If render targets use multisample anti-aliasing, all bound render targets and depth buffer must be the same form of multisample resource (that is, the sample counts must be the same). Each render target can have a different data format. These render target formats are not required to have identical bit-per-element counts.

Any combination of the eight slots for render targets can have a render target set or not set.

The same resource view cannot be bound to multiple render target slots simultaneously. However, you can set multiple non-overlapping resource views of a single resource as simultaneous multiple render targets.

The maximum number of active render targets a device can have active at any given time is set by a #define in D3D11.h called D3D11_SIMULTANEOUS_RENDER_TARGET_COUNT. It is invalid to try to set the same subresource to multiple render target slots. Any render targets not defined by this call are set to null.

If any subresources are also currently bound for reading in a different stage or writing (perhaps in a different part of the pipeline), those bind points will be set to null, in order to prevent the same subresource from being read and written simultaneously in a single rendering operation.

The method will hold a reference to the interfaces passed in. This differs from the device state behavior in Direct3D 10.

If the render-target views were created from an array resource type, then all of the render-target views must have the same array size. This restriction also applies to the depth-stencil view, its array size must match that of the render-target views being bound.

The pixel shader must be able to simultaneously render to at least eight separate render targets. All of these render targets must access the same type of resource: Buffer, Texture1D, Texture1DArray, Texture2D, Texture2DArray, Texture3D, or TextureCube. All render targets must have the same size in all dimensions (width and height, and depth for 3D or array size for *Array types). If render targets use multisample anti-aliasing, all bound render targets and depth buffer must be the same form of multisample resource (that is, the sample counts must be the same). Each render target can have a different data format. These render target formats are not required to have identical bit-per-element counts.

Any combination of the eight slots for render targets can have a render target set or not set.

The same resource view cannot be bound to multiple render target slots simultaneously. However, you can set multiple non-overlapping resource views of a single resource as simultaneous multiple render targets.

The maximum number of active render targets a device can have active at any given time is set by a #define in D3D11.h called D3D11_SIMULTANEOUS_RENDER_TARGET_COUNT. It is invalid to try to set the same subresource to multiple render target slots. Any render targets not defined by this call are set to null.

If any subresources are also currently bound for reading in a different stage or writing (perhaps in a different part of the pipeline), those bind points will be set to null, in order to prevent the same subresource from being read and written simultaneously in a single rendering operation.

The method will hold a reference to the interfaces passed in. This differs from the device state behavior in Direct3D 10.

If the render-target views were created from an array resource type, then all of the render-target views must have the same array size. This restriction also applies to the depth-stencil view, its array size must match that of the render-target views being bound.

The pixel shader must be able to simultaneously render to at least eight separate render targets. All of these render targets must access the same type of resource: Buffer, Texture1D, Texture1DArray, Texture2D, Texture2DArray, Texture3D, or TextureCube. All render targets must have the same size in all dimensions (width and height, and depth for 3D or array size for *Array types). If render targets use multisample anti-aliasing, all bound render targets and depth buffer must be the same form of multisample resource (that is, the sample counts must be the same). Each render target can have a different data format. These render target formats are not required to have identical bit-per-element counts.

Any combination of the eight slots for render targets can have a render target set or not set.

The same resource view cannot be bound to multiple render target slots simultaneously. However, you can set multiple non-overlapping resource views of a single resource as simultaneous multiple render targets.

The maximum number of active render targets a device can have active at any given time is set by a #define in D3D11.h called D3D11_SIMULTANEOUS_RENDER_TARGET_COUNT. It is invalid to try to set the same subresource to multiple render target slots. Any render targets not defined by this call are set to null.

If any subresources are also currently bound for reading in a different stage or writing (perhaps in a different part of the pipeline), those bind points will be set to null, in order to prevent the same subresource from being read and written simultaneously in a single rendering operation.

The method will hold a reference to the interfaces passed in. This differs from the device state behavior in Direct3D 10.

If the render-target views were created from an array resource type, then all of the render-target views must have the same array size. This restriction also applies to the depth-stencil view, its array size must match that of the render-target views being bound.

The pixel shader must be able to simultaneously render to at least eight separate render targets. All of these render targets must access the same type of resource: Buffer, Texture1D, Texture1DArray, Texture2D, Texture2DArray, Texture3D, or TextureCube. All render targets must have the same size in all dimensions (width and height, and depth for 3D or array size for *Array types). If render targets use multisample anti-aliasing, all bound render targets and depth buffer must be the same form of multisample resource (that is, the sample counts must be the same). Each render target can have a different data format. These render target formats are not required to have identical bit-per-element counts.

Any combination of the eight slots for render targets can have a render target set or not set.

The same resource view cannot be bound to multiple render target slots simultaneously. However, you can set multiple non-overlapping resource views of a single resource as simultaneous multiple render targets.

The maximum number of active render targets a device can have active at any given time is set by a #define in D3D11.h called D3D11_SIMULTANEOUS_RENDER_TARGET_COUNT. It is invalid to try to set the same subresource to multiple render target slots. Any render targets not defined by this call are set to null.

If any subresources are also currently bound for reading in a different stage or writing (perhaps in a different part of the pipeline), those bind points will be set to null, in order to prevent the same subresource from being read and written simultaneously in a single rendering operation.

The method will hold a reference to the interfaces passed in. This differs from the device state behavior in Direct3D 10.

If the render-target views were created from an array resource type, then all of the render-target views must have the same array size. This restriction also applies to the depth-stencil view, its array size must match that of the render-target views being bound.

The pixel shader must be able to simultaneously render to at least eight separate render targets. All of these render targets must access the same type of resource: Buffer, Texture1D, Texture1DArray, Texture2D, Texture2DArray, Texture3D, or TextureCube. All render targets must have the same size in all dimensions (width and height, and depth for 3D or array size for *Array types). If render targets use multisample anti-aliasing, all bound render targets and depth buffer must be the same form of multisample resource (that is, the sample counts must be the same). Each render target can have a different data format. These render target formats are not required to have identical bit-per-element counts.

Any combination of the eight slots for render targets can have a render target set or not set.

The same resource view cannot be bound to multiple render target slots simultaneously. However, you can set multiple non-overlapping resource views of a single resource as simultaneous multiple render targets.