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.

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.

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.

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

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

To share a resource between two devices

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

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.

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

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

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

You can create multiple deferred contexts.

Note??If you use the value to create the device that is represented by , the CreateDeferredContext1 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.

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

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

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

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

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

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

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

?

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

?

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

?

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

?

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

To share a resource between two devices

1. Create the resource as shared and specify that it uses NT handles, by setting the flag.
2. Obtain the REFIID, or , of the interface to the resource by using the __uuidof() macro. For example, __uuidof() retrieves the of the interface to a 2D texture.
3. Query the resource for the interface.
4. Call the method to obtain the unique handle to the resource.

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

To share a resource between two devices

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

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

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

To create a rasterizer-state object, call . To bind the rasterizer-state object to the rasterizer stage, call .

To create a rasterizer-state object, call . To bind the rasterizer-state object to the rasterizer stage, call .

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

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

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

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

If no buffer is bound at a slot, pFirstConstant and pNumConstants are null for that slot.

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

The source and destination resources can be identical, and the source and destination regions can overlap each other. For existing display drivers that don?t support overlapping, the runtime drops the call (that is, the runtime doesn't call the corresponding device driver interface (DDI)). This overlapping support enables additional scroll functionality in a call to .

If you call UpdateSubresource1 to update a constant buffer, pass any region, and the driver has not been implemented to Windows?8 Consumer Preview, the runtime drops the call (except feature level 9.1, 9.2, and 9.3 where the runtime emulates support). The runtime also drops the call if you update a constant buffer with a partial region whose extent is not aligned to 16-byte granularity (16 bytes being a full constant). When the runtime drops the call, the runtime doesn't call the corresponding device driver interface (DDI).

When you record a call to UpdateSubresource with an offset pDstBox in a software command list, the offset in pDstBox is incorrectly applied to pSrcData when you play back the command list. The new-for-Windows?8UpdateSubresource1 fixes this issue. In a call to UpdateSubresource1, pDstBox does not affect pSrcData.

DiscardResource informs the graphics processing unit (GPU) that the existing content in the resource that pResource points to is no longer needed.

DiscardView informs the graphics processing unit (GPU) that the existing content in the resource view that pResourceView points to is no longer needed. The view can be an SRV, RTV, UAV, or DSV. DiscardView is a variation on the DiscardResource method. DiscardView allows you to discard a subset of a resource that is in a view (such as a single miplevel). More importantly, DiscardView provides a convenience because often views are what are being bound and unbound at the pipeline. Some pipeline bindings do not have views, such as stream output. In that situation, DiscardResource can do the job for any resource.

The runtime drops the call to VSSetConstantBuffers1 if the number of constants to which pNumConstants points is larger than the maximum constant buffer size that is supported by shaders (4096 constants ? 4*32-bit components each). The values in the elements of the pFirstConstant and pFirstConstant + pNumConstants arrays can exceed the length of each buffer; from the shader's point of view, the constant buffer is the intersection of the actual memory allocation for the buffer and the window [value in an element of pFirstConstant, value in an element of pFirstConstant + value in an element of pNumConstants]. The runtime also drops the call to VSSetConstantBuffers1 on existing drivers that do not support this offsetting.

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.

From the shader?s point of view, element [0] in the constant buffers array is the constant at pFirstConstant.

Out of bounds access to the constant buffers from the shader to the range that is defined by pFirstConstant and pNumConstants returns 0.

If pFirstConstant and pNumConstants arrays are null, you get the same result as if you were binding the entire buffer into view. You get this same result if you call the VSSetConstantBuffers method. If the buffer is larger than the maximum constant buffer size that is supported by shaders (4096 elements), the shader can access only the first 4096 constants.

If either pFirstConstant or pNumConstants is null, the other parameter must also be null.

The runtime drops the call to VSSetConstantBuffers1 if the number of constants to which pNumConstants points is larger than the maximum constant buffer size that is supported by shaders (4096 constants ? 4*32-bit components each). The values in the elements of the pFirstConstant and pFirstConstant + pNumConstants arrays can exceed the length of each buffer; from the shader's point of view, the constant buffer is the intersection of the actual memory allocation for the buffer and the window [value in an element of pFirstConstant, value in an element of pFirstConstant + value in an element of pNumConstants]. The runtime also drops the call to VSSetConstantBuffers1 on existing drivers that do not support this offsetting.

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.

From the shader?s point of view, element [0] in the constant buffers array is the constant at pFirstConstant.

Out of bounds access to the constant buffers from the shader to the range that is defined by pFirstConstant and pNumConstants returns 0.

If pFirstConstant and pNumConstants arrays are null, you get the same result as if you were binding the entire buffer into view. You get this same result if you call the VSSetConstantBuffers method. If the buffer is larger than the maximum constant buffer size that is supported by shaders (4096 elements), the shader can access only the first 4096 constants.

If either pFirstConstant or pNumConstants is null, the other parameter must also be null.

The runtime drops the call to HSSetConstantBuffers1 if the numbers of constants to which pNumConstants points is larger than the maximum constant buffer size that is supported by shaders (4096 constants ? 4*32-bit components each). The values in the elements of the pFirstConstant and pFirstConstant + pNumConstants arrays can exceed the length of each buffer; from the shader's point of view, the constant buffer is the intersection of the actual memory allocation for the buffer and the window [value in an element of pFirstConstant, value in an element of pFirstConstant + value in an element of pNumConstants]. The runtime also drops the call to HSSetConstantBuffers1 on existing drivers that do not support this offsetting.

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.

From the shader?s point of view, element [0] in the constant buffers array is the constant at pFirstConstant.

Out of bounds access to the constant buffers from the shader to the range that is defined by pFirstConstant and pNumConstants returns 0.

If the pFirstConstant and pNumConstants arrays are null, you get the same result as if you were binding the entire buffer into view. You get this same result if you call the HSSetConstantBuffers method. If the buffer is larger than the maximum constant buffer size that is supported by shaders (4096 elements), the shader can access only the first 4096 constants.

If either pFirstConstant or pNumConstants is null, the other parameter must also be null.

The runtime drops the call to HSSetConstantBuffers1 if the numbers of constants to which pNumConstants points is larger than the maximum constant buffer size that is supported by shaders (4096 constants ? 4*32-bit components each). The values in the elements of the pFirstConstant and pFirstConstant + pNumConstants arrays can exceed the length of each buffer; from the shader's point of view, the constant buffer is the intersection of the actual memory allocation for the buffer and the window [value in an element of pFirstConstant, value in an element of pFirstConstant + value in an element of pNumConstants]. The runtime also drops the call to HSSetConstantBuffers1 on existing drivers that do not support this offsetting.

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.

From the shader?s point of view, element [0] in the constant buffers array is the constant at pFirstConstant.

Out of bounds access to the constant buffers from the shader to the range that is defined by pFirstConstant and pNumConstants returns 0.

If the pFirstConstant and pNumConstants arrays are null, you get the same result as if you were binding the entire buffer into view. You get this same result if you call the HSSetConstantBuffers method. If the buffer is larger than the maximum constant buffer size that is supported by shaders (4096 elements), the shader can access only the first 4096 constants.

If either pFirstConstant or pNumConstants is null, the other parameter must also be null.

The runtime drops the call to DSSetConstantBuffers1 if the number of constants to which pNumConstants points is larger than the maximum constant buffer size that is supported by shaders (4096 constants ? 4*32-bit components each). The values in the elements of the pFirstConstant and pFirstConstant + pNumConstants arrays can exceed the length of each buffer; from the shader's point of view, the constant buffer is the intersection of the actual memory allocation for the buffer and the window [value in an element of pFirstConstant, value in an element of pFirstConstant + value in an element of pNumConstants]. The runtime also drops the call to DSSetConstantBuffers1 on existing drivers that do not support this offsetting.

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.

From the shader?s point of view, element [0] in the constant buffers array is the constant at pFirstConstant.

Out of bounds access to the constant buffers from the shader to the range that is defined by pFirstConstant and pNumConstants returns 0.

If pFirstConstant and pNumConstants arrays are null, you get the same result as if you were binding the entire buffer into view. You get this same result if you call the DSSetConstantBuffers method. If the buffer is larger than the maximum constant buffer size that is supported by shaders (4096 elements), the shader can access only the first 4096 constants.

If either pFirstConstant or pNumConstants is null, the other parameter must also be null.

The runtime drops the call to DSSetConstantBuffers1 if the number of constants to which pNumConstants points is larger than the maximum constant buffer size that is supported by shaders (4096 constants ? 4*32-bit components each). The values in the elements of the pFirstConstant and pFirstConstant + pNumConstants arrays can exceed the length of each buffer; from the shader's point of view, the constant buffer is the intersection of the actual memory allocation for the buffer and the window [value in an element of pFirstConstant, value in an element of pFirstConstant + value in an element of pNumConstants]. The runtime also drops the call to DSSetConstantBuffers1 on existing drivers that do not support this offsetting.

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.

From the shader?s point of view, element [0] in the constant buffers array is the constant at pFirstConstant.

Out of bounds access to the constant buffers from the shader to the range that is defined by pFirstConstant and pNumConstants returns 0.

If pFirstConstant and pNumConstants arrays are null, you get the same result as if you were binding the entire buffer into view. You get this same result if you call the DSSetConstantBuffers method. If the buffer is larger than the maximum constant buffer size that is supported by shaders (4096 elements), the shader can access only the first 4096 constants.

If either pFirstConstant or pNumConstants is null, the other parameter must also be null.

The runtime drops the call to GSSetConstantBuffers1 if the numbers of constants to which pNumConstants points is larger than the maximum constant buffer size that is supported by shaders (4096 constants ? 4*32-bit components each). The values in the elements of the pFirstConstant and pFirstConstant + pNumConstants arrays can exceed the length of each buffer; from the shader's point of view, the constant buffer is the intersection of the actual memory allocation for the buffer and the window [value in an element of pFirstConstant, value in an element of pFirstConstant + value in an element of pNumConstants]. The runtime also drops the call to GSSetConstantBuffers1 on existing drivers that do not support this offsetting.

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.

From the shader?s point of view, element [0] in the constant buffers array is the constant at pFirstConstant.

Out of bounds access to the constant buffers from the shader to the range that is defined by pFirstConstant and pNumConstants returns 0.

If pFirstConstant and pNumConstants arrays are null, you get the same result as if you were binding the entire buffer into view. You get this same result if you call the GSSetConstantBuffers method. If the buffer is larger than the maximum constant buffer size that is supported by shaders (4096 elements), the shader can access only the first 4096 constants.

If either pFirstConstant or pNumConstants is null, the other parameter must also be null.

The runtime drops the call to GSSetConstantBuffers1 if the numbers of constants to which pNumConstants points is larger than the maximum constant buffer size that is supported by shaders (4096 constants ? 4*32-bit components each). The values in the elements of the pFirstConstant and pFirstConstant + pNumConstants arrays can exceed the length of each buffer; from the shader's point of view, the constant buffer is the intersection of the actual memory allocation for the buffer and the window [value in an element of pFirstConstant, value in an element of pFirstConstant + value in an element of pNumConstants]. The runtime also drops the call to GSSetConstantBuffers1 on existing drivers that do not support this offsetting.

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.

From the shader?s point of view, element [0] in the constant buffers array is the constant at pFirstConstant.

Out of bounds access to the constant buffers from the shader to the range that is defined by pFirstConstant and pNumConstants returns 0.

If pFirstConstant and pNumConstants arrays are null, you get the same result as if you were binding the entire buffer into view. You get this same result if you call the GSSetConstantBuffers method. If the buffer is larger than the maximum constant buffer size that is supported by shaders (4096 elements), the shader can access only the first 4096 constants.

If either pFirstConstant or pNumConstants is null, the other parameter must also be null.

The runtime drops the call to PSSetConstantBuffers1 if the numbers of constants to which pNumConstants points is larger than the maximum constant buffer size that is supported by shaders (4096 constants ? 4*32-bit components each). The values in the elements of the pFirstConstant and pFirstConstant + pNumConstants arrays can exceed the length of each buffer; from the shader's point of view, the constant buffer is the intersection of the actual memory allocation for the buffer and the window [value in an element of pFirstConstant, value in an element of pFirstConstant + value in an element of pNumConstants]. The runtime also drops the call to PSSetConstantBuffers1 on existing drivers that do not support this offsetting.

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.

From the shader?s point of view, element [0] in the constant buffers array is the constant at pFirstConstant.

Out of bounds access to the constant buffers from the shader to the range that is defined by pFirstConstant and pNumConstants returns 0.

If pFirstConstant and pNumConstants arrays are null, you get the same result as if you were binding the entire buffer into view. You get this same result if you call the PSSetConstantBuffers method. If the buffer is larger than the maximum constant buffer size that is supported by shaders (4096 elements), the shader can access only the first 4096 constants.

If either pFirstConstant or pNumConstants is null, the other parameter must also be null.

The runtime drops the call to PSSetConstantBuffers1 if the numbers of constants to which pNumConstants points is larger than the maximum constant buffer size that is supported by shaders (4096 constants ? 4*32-bit components each). The values in the elements of the pFirstConstant and pFirstConstant + pNumConstants arrays can exceed the length of each buffer; from the shader's point of view, the constant buffer is the intersection of the actual memory allocation for the buffer and the window [value in an element of pFirstConstant, value in an element of pFirstConstant + value in an element of pNumConstants]. The runtime also drops the call to PSSetConstantBuffers1 on existing drivers that do not support this offsetting.

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.

From the shader?s point of view, element [0] in the constant buffers array is the constant at pFirstConstant.

Out of bounds access to the constant buffers from the shader to the range that is defined by pFirstConstant and pNumConstants returns 0.

If pFirstConstant and pNumConstants arrays are null, you get the same result as if you were binding the entire buffer into view. You get this same result if you call the PSSetConstantBuffers method. If the buffer is larger than the maximum constant buffer size that is supported by shaders (4096 elements), the shader can access only the first 4096 constants.

If either pFirstConstant or pNumConstants is null, the other parameter must also be null.

The runtime drops the call to CSSetConstantBuffers1 if the number of constants to which pNumConstants points is larger than the maximum constant buffer size that is supported by shaders (4096 constants ? 4*32-bit components each). The values in the elements of the pFirstConstant and pFirstConstant + pNumConstants arrays can exceed the length of each buffer; from the shader's point of view, the constant buffer is the intersection of the actual memory allocation for the buffer and the window [value in an element of pFirstConstant, value in an element of pFirstConstant + value in an element of pNumConstants]. The runtime also drops the call to CSSetConstantBuffers1 on existing drivers that do not support this offsetting.

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.

From the shader?s point of view, element [0] in the constant buffers array is the constant at pFirstConstant.

Out of bounds access to the constant buffers from the shader to the range that is defined by pFirstConstant and pNumConstants returns 0.

If pFirstConstant and pNumConstants arrays are null, you get the same result as if you were binding the entire buffer into view. You get this same result if you call the CSSetConstantBuffers method. If the buffer is larger than the maximum constant buffer size that is supported by shaders (4096 elements), the shader can access only the first 4096 constants.

If either pFirstConstant or pNumConstants is null, the other parameter must also be null.

The runtime drops the call to CSSetConstantBuffers1 if the number of constants to which pNumConstants points is larger than the maximum constant buffer size that is supported by shaders (4096 constants ? 4*32-bit components each). The values in the elements of the pFirstConstant and pFirstConstant + pNumConstants arrays can exceed the length of each buffer; from the shader's point of view, the constant buffer is the intersection of the actual memory allocation for the buffer and the window [value in an element of pFirstConstant, value in an element of pFirstConstant + value in an element of pNumConstants]. The runtime also drops the call to CSSetConstantBuffers1 on existing drivers that do not support this offsetting.

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.

From the shader?s point of view, element [0] in the constant buffers array is the constant at pFirstConstant.

Out of bounds access to the constant buffers from the shader to the range that is defined by pFirstConstant and pNumConstants returns 0.

If pFirstConstant and pNumConstants arrays are null, you get the same result as if you were binding the entire buffer into view. You get this same result if you call the CSSetConstantBuffers method. If the buffer is larger than the maximum constant buffer size that is supported by shaders (4096 elements), the shader can access only the first 4096 constants.

If either pFirstConstant or pNumConstants is null, the other parameter must also be null.

If no buffer is bound at a slot, pFirstConstant and pNumConstants are null for that slot.

If no buffer is bound at a slot, pFirstConstant and pNumConstants are null for that slot.

If no buffer is bound at a slot, pFirstConstant and pNumConstants are null for that slot.

If no buffer is bound at a slot, pFirstConstant and pNumConstants are null for that slot.

If no buffer is bound at a slot, pFirstConstant and pNumConstants are null for that slot.

If no buffer is bound at a slot, pFirstConstant and pNumConstants are null for that slot.

SwapDeviceContextState changes device behavior. This device behavior depends on the emulated interface that you passed to the EmulatedInterface parameter of the method when you created the context state object.

SwapDeviceContextState is not supported on a deferred context.

SwapDeviceContextState disables the incompatible device interfaces , , , and . When a context state object is active, the runtime disables certain methods on the device and context interfaces. A context state object that is created with __uuidof() or __uuidof() turns off most of the Direct3D?10 device interfaces. A context state object that is created with __uuidof() or __uuidof() turns off most of the methods. For more information about this behavior, see .

SwapDeviceContextState activates the context state object specified by pState. This means that the device behaviors that are associated with the context state object's feature level and compatible interface are activated on the Direct3D device until the next call to SwapDeviceContextState. In addition, any state that was saved when this context state object was last active is now reactivated, so that the previous state is replaced.

SwapDeviceContextState sets ppPreviousState to the most recently activated context state object. The object allows the caller to save and then later restore the previous device state. This behavior is useful in a plug-in architecture such as Direct2D that shares a Direct3D device with its plug-ins. A Direct2D interface can use context state objects to save and restore the application's state.

If the caller did not previously call the method to create a previous context state object, SwapDeviceContextState sets ppPreviousState to the default context state object. In either case, usage of SwapDeviceContextState is the same.

The feature level that is specified by the application, and that is chosen by the context state object from the acceptable list that the application supplies to , controls the feature level of the immediate context whenever the context state object is active. Because the Direct3D?11 device is free-threaded, the device methods cannot query the current immediate context feature level. Instead, the device runs at a feature level that is the maximum of all previously created context state objects' feature levels. This means that the device's feature level can increase dynamically.

The feature level of the context state object controls the functionality available from the immediate context. However, to maintain the free-threaded contract of the Direct3D?11 device methods?the resource-creation methods in particular?the upper-bound feature level of all created context state objects controls the set of resources that the device creates.

Because the context state object interface is published by the immediate context, the interface requires the same threading model as the immediate context. Specifically, SwapDeviceContextState is single-threaded with respect to the other immediate context methods and with respect to the equivalent methods of .

Crucially, because only one of the Direct3D?10 or Direct3D?11 ref-count behaviors can be available at a time, one of the Direct3D?10 and Direct3D?11 interfaces must break its ref-count contract. To avoid this situation, the activation of a context state object turns off the incompatible version interface. Also, if you call a method of an incompatible version interface, the call silently fails if the method has return type void, returns an value of E_INVALIDARG, or sets any out parameter to null.

When you switch from Direct3D?11 mode to either Direct3D?10 mode or Direct3D?10.1 mode, the binding behavior of the device changes. Specifically, the final release of a resource induces unbind in Direct3D?10 mode or Direct3D?10.1 mode. During final release an application releases all of the resource's references, including indirect references such as the linkage from view to resource, and the linkage from context state object to any of the context state object's bound resources. Any bound resource to which the application has no reference is unbound and destroyed, in order to maintain the Direct3D?10 behavior.

SwapDeviceContextState does not affect any state that sets.

Command lists that are generated by deferred contexts do not hold a reference to context state objects and are not affected by future updates to context state objects.

No asynchronous objects are affected by SwapDeviceContextState. For example, if a query is active before a call to SwapDeviceContextState, it is still active after the call.

ClearView works only on render-target views (RTVs), unordered-access views (UAVs), or any video view of a Texture2D surface. The runtime drops invalid calls. Empty rectangles in the pRect array are a no-op. A rectangle is empty if the top value equals the bottom value or the left value equals the right value.

ClearView doesn?t support 3D textures.

ClearView applies the same color value to all array slices in a view; all rectangles in the pRect array correspond to each array slice. The pRect array of rectangles is a set of areas to clear on a single surface. If the view is an array, ClearView clears all the rectangles on each array slice individually.

When you apply rectangles to buffers, set the top value to 0 and the bottom value to 1 and set the left value and right value to describe the extent within the buffer. When the top value equals the bottom value or the left value equals the right value, the rectangle is empty and a no-op is achieved.

The driver converts and clamps color values to the destination format as appropriate per Direct3D conversion rules. For example, if the format of the view is , the driver clamps inputs to 0.0f to 1.0f (+INF -> 1.0f (0XFF)/NaN -> 0.0f).

If the format is integer, such as , the runtime interprets inputs as integral floats. Therefore, 235.0f maps to 235 (rounds to zero, out of range/INF values clamp to target range, and NaN to 0).

Here are the color mappings:

• Color[0]: R (or Y for video)
• Color[1]: G (or U/Cb for video)
• Color[2]: B (or V/Cr for video)
• Color[3]: A

For video views with YUV or YCbBr formats, ClearView doesn't convert color values. In situations where the format name doesn?t indicate _UNORM, _UINT, and so on, ClearView assumes _UINT. Therefore, 235.0f maps to 235 (rounds to zero, out of range/INF values clamp to target range, and NaN to 0).

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.

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

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.

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.