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 .

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

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 .

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.

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.

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.

?

Note?? is identical to .

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.

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.

A resource interface cannot be created directly; instead, buffers and textures are created that inherit from a resource interface (see Creating Buffer Resources or Creating Texture Resources).

Resource priorities determine which resource to evict from video memory when the system has run out of video memory. The resource will not be lost; it will be removed from video memory and placed into system memory, or possibly placed onto the hard drive. The resource will be loaded back into video memory when it is required.

A resource that is set to the maximum priority, , is only evicted if there is no other way of resolving the incoming memory request. The Windows Display Driver Model (WDDM) tries to split an incoming memory request to its minimum size and evict lower-priority resources before evicting a resource with maximum priority.

Changing the priorities of resources should be done carefully. The wrong eviction priorities could be a detriment to performance rather than an improvement.

This structure is used by to create buffer resources.

In addition to this structure, there is also a derived structure in D3D11.h (CD3D11_BUFFER_DESC) which behaves like an inherited class to help create a buffer description.

If the bind flag is then the ByteWidth value must be 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.

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.

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

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

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

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

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

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.

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.

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.

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.

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 .

Rasterizer state defines the behavior of the rasterizer stage; to set rasterizer state, call .

These are the default values for rasterizer state.

?

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 .

There are three types of asynchronous interfaces, all of which inherit this interface:

• - Queries information from the GPU.
• - Determines whether a piece of geometry should be processed or not depending on the results of a previous draw call.
• - Measures GPU performance.

The swap chain retrieved by this method will only be used if is set in the feature mask.

Setting one of the following feature-mask flags will cause a rendering-operation method (listed below) to do some extra task when called.

?

These feature-mask flags apply to the following rendering-operation methods:

By setting one of the following feature-mask flags, you can control the behavior of the IDXGIDevice2::OfferResources and IDXGIDevice2::ReclaimResources methods to aid in testing and debugging.

Note??These flags are supported by the Direct3D 11.1 runtime, which is available starting with Windows Developer Preview.

?

The behavior of the IDXGIDevice2::OfferResources and IDXGIDevice2::ReclaimResources methods depends on system-wide memory pressure. Therefore, the scenario where content is lost and must be regenerated is uncommon for most applications. The preceding new options in the Direct3D debug layer let you simulate that scenario consistently and test code paths.

The following flag is supported by the Direct3D 11.1 runtime.

?

When the debug layer is enabled, it performs certain actions to reveal application problems. By setting the D3D11_DEBUG_FEATURE_AVOID_BEHAVIOR_CHANGING_DEBUG_AIDS feature-mask flag, you can enable the debug layer without getting the following default debugging behavior:

• If an application calls ID3D11DeviceContext1::DiscardView, the runtime fills in the resource with a random color.
• If an application calls IDXGISwapChain1::Present1 with partial presentation parameters, the runtime ignores the partial presentation information.

The application will only sleep if is a set in the feature mask. If that flag is not set the number of milliseconds is set but ignored and the application does not sleep. 10ms is used as a default value if this method is never called.

Value is set with .

The swap chain set by this method will only be used if is set in the feature mask.

The swap chain retrieved by this method will only be used if is set in the feature mask.

Use validate prior to calling a draw method (for example, ); validation requires the debug layer.

ReportLiveDeviceObjects uses the value in Flags to determine the amount of information to report about a device object's lifetime.

Use this method before you call a dispatch method (for example, ). Validation requires the debug layer.

Value is set with .

The swap chain retrieved by this method will only be used if is set in the feature mask.

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.

To create a depth-stencil view, call .

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

A view interface is the base interface for all views. There are four types of views; a depth-stencil view, a render-target view, a shader-resource view, and an unordered-access view.

• To create a render-target view, call .
• To create a depth-stencil view, call .
• To create a shader-resource view, call .
• To create an unordered-access view, call .

All resources must be bound to the pipeline before they can be accessed.

• To bind a render-target view or a depth-stencil view, call .
• To bind a shader resource, call .

This function increments the reference count of the resource by one, so it is necessary to call Release on the returned reference when the application is done with it. Destroying (or losing) the returned reference before Release is called will result in a memory leak.

This function increments the reference count of the resource by one, so it is necessary to call Dispose on the returned reference when the application is done with it. Destroying (or losing) the returned reference before Release is called will result in a memory leak.

This function increments the reference count of the resource by one, so it is necessary to call Release on the returned reference when the application is done with it. Destroying (or losing) the returned reference before Release is called will result in a memory leak.

A device is created using .

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

The Direct3D 11.1 runtime, which is available on Windows Developer Preview 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 .

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 .

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 .

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.

Note??To successfully create a shader-resource view from a typeless buffer (for example, ), you must set the flag when you create the buffer.

The Direct3D 11.1 runtime, which is available starting with Windows Developer Preview, 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.

The Direct3D 11.1 runtime, which is available starting with Windows Developer Preview, 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 Developer Preview, 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.

The Direct3D 11.1 runtime, which is available starting with Windows Developer Preview, 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 Developer Preview, 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 Developer Preview, 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)

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

The Direct3D 11.1 runtime, which is available starting with Windows Developer Preview, 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 Developer Preview, 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.

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.

Note??If you use the value to create the device that is represented by , the CreateDeferredContext method will fail, and you will not be able to create a deferred context.

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

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.

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.

If an application uses this method to change the device type using GUID_DeviceType, results are undefined. However, GUID_DeviceType can be used to retrieve the device type using .

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.

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.

An offset of -1 will cause the stream output buffer to be appended, continuing after the last location written to the buffer in a previous stream output pass.

Calling this method using a buffer that is currently bound for writing 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.

An offset of -1 will cause the stream output buffer to be appended, continuing after the last location written to the buffer in a previous stream output pass.

Calling this method using a buffer that is currently bound for writing 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.

A maximum of four output buffers can be retrieved.

The offsets to the output buffers pointed to in the returned ppSOTargets array may be assumed to be -1 (append), as defined for use in .

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 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.

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 Developer Preview, 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.

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.

A draw API 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. However, you could also provide the vertex data from a shader that has vertex data marked with the SV_VertexId system-value semantic.

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.

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. Indexing 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 counter data is of type FLOAT32.

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.

This method is used 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 graphics 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 graphics commands manually with it's own application logic.

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.

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).

You call the DispatchIndirect method to execute commands in a compute shader.

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.

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 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.
• May not be currently mapped.

CopySubresourceRegion only supports copy; it does not support any stretch, color key, blend, or format conversions. An application that needs to copy an entire resource should 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.

Note??If you use CopySubresourceRegion with a depth-stencil buffer or a multisampled resource, you must copy the whole subresource. In this situation, you must pass 0 to the DstX, DstY, and DstZ parameters and null to the pSrcBox parameter. In addition, source and destination resources, which are represented by the pSrcResource and pDstResource parameters, should have identical sample count values.

The following code snippet copies a box (located at (120,100),(200,220)) from a source texture into a reqion (10,20),(90,140) in a destination texture.

  sourceRegion;	
            sourceRegion.left = 120;	
            sourceRegion.right = 200;	
            sourceRegion.top = 100;	
            sourceRegion.bottom = 220;	
            sourceRegion.front = 0;	
            sourceRegion.back = 1; pd3dDeviceContext->CopySubresourceRegion( pDestTexture, 0, 10, 20, 0, pSourceTexture, 0, &sourceRegion );	
            

Notice, that for a 2D texture, front and back are set to 0 and 1 respectively.

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).
• Will only be copied. CopyResource does not support any stretch, color key, blend, or format conversions.
• 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.
• Might not be currently mapped.

You cannot use an Immutable resource as a destination. You can use a depth-stencil resource as either a source or a destination. 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.

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.

An application that only needs to copy a portion of the data in a resource should use instead.

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 );	
            

If your application calls UpdateSubresource on a deferred context with a destination box?to which pDstBox points?that has a non-(0,0,0) offset, and if the driver does not support command lists, UpdateSubresource inappropriately applies that destination-box offset to the pSrcData parameter. To work around this behavior, use the following code:

  UpdateSubresource_Workaround(  *pDevice,  *pDeviceContext,  *pDstResource, UINT dstSubresource, const  *pDstBox, const void *pSrcData, UINT srcBytesPerElement, UINT srcRowPitch, UINT srcDepthPitch, bool* pDidWorkAround )	
            {  hr = ; bool needWorkaround = false;  contextType = pDeviceContext->GetType(); if( pDstBox && ( == contextType) ) {  threadingCaps = { ,  }; hr = pDevice->CheckFeatureSupport( , &threadingCaps, sizeof(threadingCaps) ); if( SUCCEEDED(hr) ) { if( !threadingCaps.DriverCommandLists ) { needWorkaround = true; } } } const void* pAdjustedSrcData = pSrcData; if( needWorkaround ) {  alignedBox = *pDstBox; // convert from pixels to blocks if( m_bBC ) { alignedBox.left     /= 4; alignedBox.right    /= 4; alignedBox.top      /= 4; alignedBox.bottom   /= 4; } pAdjustedSrcData = ((const BYTE*)pSrcData) - (alignedBox.front * srcDepthPitch) - (alignedBox.top * srcRowPitch) - (alignedBox.left * srcBytesPerElement); } pDeviceContext->UpdateSubresource( pDstResource, dstSubresource, pDstBox, pAdjustedSrcData, srcRowPitch, srcDepthPitch ); if( pDidWorkAround ) { *pDidWorkAround = needWorkaround; } return hr;	
            }	
            

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.

?

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.

?

GenerateMips may be called on any shader-resource view in order to generate the lower mipmap levels. GenerateMips uses the largest mipmap level of the view to recursively generate the lower levels of the mip, stopping with the smallest level specified by the view. If the base resource was not created with and , this call has no effect.

All video adapters support generating mipmaps if you are using any of the following formats:

Some video adapters support generating mipmaps if you are using this format:

For all other unsupported formats, this method 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.

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).

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.

Direct3D?11 defers the destruction of objects like views and resources until it can efficiently destroy them. This deferred destruction can cause problems with flip presentation model swap chains. Flip presentation model swap chains have the DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL flag set. When you create a flip presentation model swap chain, you can associate only one swap chain at a time with an , IWindow, or composition surface. If an application attempts to destroy a flip presentation model swap chain and replace it with another swap chain, the original swap chain is not destroyed when the application immediately frees all of the original swap chain's references.

Most applications typically use the method for the majority of scenarios where they replace new swap chain buffers for old swap chain buffers. However, if an application must actually destroy an old swap chain and create a new swap chain, the application must force the destruction of all objects that the application freed. To force the destruction, call (or otherwise ensure no views are bound to pipeline state), and then call Flush on the immediate context. You must force destruction before you call IDXGIFactory2::CreateSwapChainForHwnd, IDXGIFactory2::CreateSwapChainForImmersiveWindow, or IDXGIFactory2::CreateSwapChainForCompositionSurface again to create a new swap chain.

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.

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

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.

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 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 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.

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.

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.

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.

For pixel shaders, the render targets and unordered-access views share the same resource slots when being written out. This means that UAVs must be given an offset so that they are placed in the slots after the render target views that are being bound.

Note??RTVs, DSV, and UAVs cannot be set independently; they all need to be set at the same time.

Two RTVs conflict if they share a subresource (and therefore share the same resource).

Two UAVs conflict if they share a subresource (and therefore share the same resource).

An RTV conflicts with a UAV if they share a subresource or share a bind point.

OMSetRenderTargetsAndUnorderedAccessViews operates properly in the following situations:

1. NumViews != D3D11_KEEP_RENDER_TARGETS_AND_DEPTH_STENCIL and NumUAVs != D3D11_KEEP_UNORDERED_ACCESS_VIEWS

   The following conditions must be true for OMSetRenderTargetsAndUnorderedAccessViews to succeed and for the runtime to pass the bind information to the driver:

   • NumViews <= 8
   • UAVStartSlot >= NumViews
   • UAVStartSlot + NumUAVs <= 8
   • There must be no conflicts in the set of all ppRenderTargetViews and ppUnorderedAccessView.
   • ppDepthStencilView must match the render-target views. For more information about resource views, see Introduction to a Resource in Direct3D 11.

   OMSetRenderTargetsAndUnorderedAccessViews performs the following tasks:

   • Unbinds all currently bound conflicting resources (stream-output target resources (SOTargets), compute shader (CS) UAVs, shader-resource views (SRVs)).
   • Binds ppRenderTargetViews, ppDepthStencilView, and ppUnorderedAccessView.

2. NumViews == D3D11_KEEP_RENDER_TARGETS_AND_DEPTH_STENCIL

   In this situation, OMSetRenderTargetsAndUnorderedAccessViews binds only UAVs.

   The following conditions must be true for OMSetRenderTargetsAndUnorderedAccessViews to succeed and for the runtime to pass the bind information to the driver:

   • UAVStartSlot + NumUAVs <= 8
   • There must be no conflicts in ppUnorderedAccessView.

   OMSetRenderTargetsAndUnorderedAccessViews unbinds the following items:

   • All RTVs in slots >= UAVStartSlot
   • All RTVs that conflict with any UAVs in ppUnorderedAccessView
   • All currently bound resources (SOTargets, CS UAVs, SRVs) that conflict with ppUnorderedAccessView

   OMSetRenderTargetsAndUnorderedAccessViews binds ppUnorderedAccessView.

   OMSetRenderTargetsAndUnorderedAccessViews ignores ppDepthStencilView, and the current depth-stencil view remains bound.

3. NumUAVs == D3D11_KEEP_UNORDERED_ACCESS_VIEWS

   In this situation, OMSetRenderTargetsAndUnorderedAccessViews binds only RTVs and DSV.

   The following conditions must be true for OMSetRenderTargetsAndUnorderedAccessViews to succeed and for the runtime to pass the bind information to the driver:

   • NumViews <= 8
   • There must be no conflicts in ppRenderTargetViews.
   • ppDepthStencilView must match the render-target views. For more information about resource views, see Introduction to a Resource in Direct3D 11.

   OMSetRenderTargetsAndUnorderedAccessViews unbinds the following items:

   • All UAVs in slots < NumViews
   • All UAVs that conflict with any RTVs in ppRenderTargetViews
   • All currently bound resources (SOTargets, CS UAVs, SRVs) that conflict with ppRenderTargetViews

   OMSetRenderTargetsAndUnorderedAccessViews binds ppRenderTargetViews and ppDepthStencilView.

   OMSetRenderTargetsAndUnorderedAccessViews ignores UAVStartSlot.

For pixel shaders, the render targets and unordered-access views share the same resource slots when being written out. This means that UAVs must be given an offset so that they are placed in the slots after the render target views that are being bound.

Note??RTVs, DSV, and UAVs cannot be set independently; they all need to be set at the same time.

Two RTVs conflict if they share a subresource (and therefore share the same resource).

Two UAVs conflict if they share a subresource (and therefore share the same resource).

An RTV conflicts with a UAV if they share a subresource or share a bind point.

OMSetRenderTargetsAndUnorderedAccessViews operates properly in the following situations:

1. NumViews != D3D11_KEEP_RENDER_TARGETS_AND_DEPTH_STENCIL and NumUAVs != D3D11_KEEP_UNORDERED_ACCESS_VIEWS

   The following conditions must be true for OMSetRenderTargetsAndUnorderedAccessViews to succeed and for the runtime to pass the bind information to the driver:

   • NumViews <= 8
   • UAVStartSlot >= NumViews
   • UAVStartSlot + NumUAVs <= 8
   • There must be no conflicts in the set of all ppRenderTargetViews and ppUnorderedAccessView.
   • ppDepthStencilView must match the render-target views. For more information about resource views, see Introduction to a Resource in Direct3D 11.

   OMSetRenderTargetsAndUnorderedAccessViews performs the following tasks:

   • Unbinds all currently bound conflicting resources (stream-output target resources (SOTargets), compute shader (CS) UAVs, shader-resource views (SRVs)).
   • Binds ppRenderTargetViews, ppDepthStencilView, and ppUnorderedAccessView.

2. NumViews == D3D11_KEEP_RENDER_TARGETS_AND_DEPTH_STENCIL

   In this situation, OMSetRenderTargetsAndUnorderedAccessViews binds only UAVs.

   The following conditions must be true for OMSetRenderTargetsAndUnorderedAccessViews to succeed and for the runtime to pass the bind information to the driver:

   • UAVStartSlot + NumUAVs <= 8
   • There must be no conflicts in ppUnorderedAccessView.

   OMSetRenderTargetsAndUnorderedAccessViews unbinds the following items:

   • All RTVs in slots >= UAVStartSlot
   • All RTVs that conflict with any UAVs in ppUnorderedAccessView
   • All currently bound resources (SOTargets, CS UAVs, SRVs) that conflict with ppUnorderedAccessView

   OMSetRenderTargetsAndUnorderedAccessViews binds ppUnorderedAccessView.

   OMSetRenderTargetsAndUnorderedAccessViews ignores ppDepthStencilView, and the current depth-stencil view remains bound.

3. NumUAVs == D3D11_KEEP_UNORDERED_ACCESS_VIEWS

   In this situation, OMSetRenderTargetsAndUnorderedAccessViews binds only RTVs and DSV.

   The following conditions must be true for OMSetRenderTargetsAndUnorderedAccessViews to succeed and for the runtime to pass the bind information to the driver:

   • NumViews <= 8
   • There must be no conflicts in ppRenderTargetViews.
   • ppDepthStencilView must match the render-target views. For more information about resource views, see Introduction to a Resource in Direct3D 11.

   OMSetRenderTargetsAndUnorderedAccessViews unbinds the following items:

   • All UAVs in slots < NumViews
   • All UAVs that conflict with any RTVs in ppRenderTargetViews
   • All currently bound resources (SOTargets, CS UAVs, SRVs) that conflict with ppRenderTargetViews

   OMSetRenderTargetsAndUnorderedAccessViews binds ppRenderTargetViews and ppDepthStencilView.

   OMSetRenderTargetsAndUnorderedAccessViews ignores UAVStartSlot.

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.

For pixel shaders, the render targets and unordered-access views share the same resource slots when being written out. This means that UAVs must be given an offset so that they are placed in the slots after the render target views that are being bound.

Note??RTVs, DSV, and UAVs cannot be set independently; they all need to be set at the same time.

Two RTVs conflict if they share a subresource (and therefore share the same resource).

Two UAVs conflict if they share a subresource (and therefore share the same resource).

An RTV conflicts with a UAV if they share a subresource or share a bind point.

OMSetRenderTargetsAndUnorderedAccessViews operates properly in the following situations:

1. NumViews != D3D11_KEEP_RENDER_TARGETS_AND_DEPTH_STENCIL and NumUAVs != D3D11_KEEP_UNORDERED_ACCESS_VIEWS

   The following conditions must be true for OMSetRenderTargetsAndUnorderedAccessViews to succeed and for the runtime to pass the bind information to the driver:

   • NumViews <= 8
   • UAVStartSlot >= NumViews
   • UAVStartSlot + NumUAVs <= 8
   • There must be no conflicts in the set of all ppRenderTargetViews and ppUnorderedAccessView.
   • ppDepthStencilView must match the render-target views. For more information about resource views, see Introduction to a Resource in Direct3D 11.

   OMSetRenderTargetsAndUnorderedAccessViews performs the following tasks:

   • Unbinds all currently bound conflicting resources (stream-output target resources (SOTargets), compute shader (CS) UAVs, shader-resource views (SRVs)).
   • Binds ppRenderTargetViews, ppDepthStencilView, and ppUnorderedAccessView.

2. NumViews == D3D11_KEEP_RENDER_TARGETS_AND_DEPTH_STENCIL

   In this situation, OMSetRenderTargetsAndUnorderedAccessViews binds only UAVs.

   The following conditions must be true for OMSetRenderTargetsAndUnorderedAccessViews to succeed and for the runtime to pass the bind information to the driver:

   • UAVStartSlot + NumUAVs <= 8
   • There must be no conflicts in ppUnorderedAccessView.

   OMSetRenderTargetsAndUnorderedAccessViews unbinds the following items:

   • All RTVs in slots >= UAVStartSlot
   • All RTVs that conflict with any UAVs in ppUnorderedAccessView
   • All currently bound resources (SOTargets, CS UAVs, SRVs) that conflict with ppUnorderedAccessView

   OMSetRenderTargetsAndUnorderedAccessViews binds ppUnorderedAccessView.

   OMSetRenderTargetsAndUnorderedAccessViews ignores ppDepthStencilView, and the current depth-stencil view remains bound.

3. NumUAVs == D3D11_KEEP_UNORDERED_ACCESS_VIEWS

   In this situation, OMSetRenderTargetsAndUnorderedAccessViews binds only RTVs and DSV.

   The following conditions must be true for OMSetRenderTargetsAndUnorderedAccessViews to succeed and for the runtime to pass the bind information to the driver:

   • NumViews <= 8
   • There must be no conflicts in ppRenderTargetViews.
   • ppDepthStencilView must match the render-target views. For more information about resource views, see Introduction to a Resource in Direct3D 11.

   OMSetRenderTargetsAndUnorderedAccessViews unbinds the following items:

   • All UAVs in slots < NumViews
   • All UAVs that conflict with any RTVs in ppRenderTargetViews
   • All currently bound resources (SOTargets, CS UAVs, SRVs) that conflict with ppRenderTargetViews

   OMSetRenderTargetsAndUnorderedAccessViews binds ppRenderTargetViews and ppDepthStencilView.

   OMSetRenderTargetsAndUnorderedAccessViews ignores UAVStartSlot.

Blend state is used by the output-merger stage to determine how to blend together two pixel values. The two values are commonly the current pixel value and the pixel value already in the output render target. Use the blend operation to control where the two pixel values come from and how they are mathematically combined.

To create a blend-state interface, call .

Passing in null for the blend-state interface indicates to the runtime to set a default blending state. The following table indicates the default blending parameters.

?

A sample mask determines which samples get updated in all the active render targets. The mapping of bits in a sample mask to samples in a multisample render target is the responsibility of an individual application. A sample mask is always applied; it is independent of whether multisampling is enabled, and does not depend on whether an application uses multisample render targets.

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

To create a depth-stencil state interface, call .

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

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 reference count of the returned interface will be incremented by one when the blend state is retrieved. Applications must release returned reference(s) when they are no longer needed, or else there will be a memory leak.

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.

All scissor rects must be set atomically as one operation. Any scissor rects not defined by the call are disabled.

The scissor rectangles will only be used if ScissorEnable is set to true in the rasterizer state (see ).

Which scissor rectangle to use is determined by the SV_ViewportArrayIndex semantic output by a geometry shader (see shader semantic syntax). If a geometry shader does not make use of the SV_ViewportArrayIndex semantic then Direct3D will use the first scissor rectangle in the array.

Each scissor rectangle in the array corresponds to a viewport in an array of viewports (see ).

All scissor rects must be set atomically as one operation. Any scissor rects not defined by the call are disabled.

The scissor rectangles will only be used if ScissorEnable is set to true in the rasterizer state (see ).

Which scissor rectangle to use is determined by the SV_ViewportArrayIndex semantic output by a geometry shader (see shader semantic syntax). If a geometry shader does not make use of the SV_ViewportArrayIndex semantic then Direct3D will use the first scissor rectangle in the array.

Each scissor rectangle in the array corresponds to a viewport in an array of viewports (see ).

All viewports must be set atomically as one operation. Any viewports not defined by the call are disabled.

Which viewport to use is determined by the SV_ViewportArrayIndex semantic output by a geometry shader; if a geometry shader does not specify the semantic, Direct3D will use the first viewport in the array.

All viewports must be set atomically as one operation. Any viewports not defined by the call are disabled.

Which viewport to use is determined by the SV_ViewportArrayIndex semantic output by a geometry shader; if a geometry shader does not specify the semantic, Direct3D will use the first viewport in the array.

All viewports must be set atomically as one operation. Any viewports not defined by the call are disabled.

Which viewport to use is determined by the SV_ViewportArrayIndex semantic output by a geometry shader; if a geometry shader does not specify the semantic, Direct3D will use the first viewport in the array.

To create a rasterizer state interface, call .

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

All viewports must be set atomically as one operation. Any viewports not defined by the call are disabled.

Which viewport to use is determined by the SV_ViewportArrayIndex semantic output by a geometry shader; if a geometry shader does not specify the semantic, Direct3D will use the first viewport in the array.

All scissor rects must be set atomically as one operation. Any scissor rects not defined by the call are disabled.

The scissor rectangles will only be used if ScissorEnable is set to true in the rasterizer state (see ).

Which scissor rectangle to use is determined by the SV_ViewportArrayIndex semantic output by a geometry shader (see shader semantic syntax). If a geometry shader does not make use of the SV_ViewportArrayIndex semantic then Direct3D will use the first scissor rectangle in the array.

Each scissor rectangle in the array corresponds to a viewport in an array of viewports (see ).

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 domain-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 domain-shader interface, call . Before using a domain shader you must bind it to the device by calling .

This interface is defined in D3D11.h.

SetForwardScale sets the scale used by .

SetInverseScale sets the scale used by .

The buffers must be no smaller than the corresponding buffer sizes returned by *(). Temporary buffers can be shared between multiple contexts, though care should be taken not to concurrently execute multiple FFTs which share temp buffers.

The buffers must be no smaller than the corresponding buffer sizes returned by *(). Temporary buffers can be shared between multiple contexts, though care should be taken not to concurrently execute multiple FFTs which share temp buffers.

ForwardTransform can be called after buffers have been attached to the context using . The combination of pInputBuffer and *ppOuputBuffer can be one of the temp buffers.

The format of complex data is interleaved components (for example, (Real0, Imag0), (Real1, Imag1) ... , and so on). Data is stored in row major order.

In general, binding flags can be combined using a logical OR (except the constant-buffer flag); however, you should use a single flag to allow the device to optimize the resource usage.

This enumeration is used by a:

• Buffer description when creating a buffer.
• Texture description when creating a texture (see or or ).

A shader-resource buffer is NOT a constant buffer; rather, it is a texture or buffer resource that is bound to a shader, that contains texture or buffer data (it is not limited to a single element type in the buffer). A shader-resource buffer is created with the flag and is bound to the pipeline using one of these APIs: , , or . Furthermore, a shader-resource buffer cannot use the flag.

The runtime implements RGB blending and alpha blending separately. Therefore, blend state requires separate blend operations for RGB data and alpha data. These blend operations are specified in a blend description. The two sources?Source 1, called SrcBlend and SrcBlendAlpha, and Source 2, called DestBlend and DestBlendAlpha?are shown in the blending block diagram.

Blend operations are specified in a blend description.