A display sub-system is often referred to as a video card, however, on some machines the display sub-system is part of the mother board.

To enumerate the display sub-systems, use . To get an interface to the adapter for a particular device, use . To create a software adapter, use .

implements base class functionality for several other interfaces: , , ,

SetPrivateData makes a copy of the specified data and stores it with the object.

Private data that SetPrivateData stores in the object occupies the same storage space as private data that is stored by associated Direct3D objects (for example, by a Microsoft Direct3D?11 device through or by a Direct3D?11 child device through ).

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 well-known private data () 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 );	
            

You can use to track down memory leaks and understand performance characteristics of your applications. This information is reflected in the output of the debug layer that is related to memory leaks () and with the event tracing for Windows events that we've added to Windows Developer Preview.

This API associates an interface reference with the object.

When the interface is set its reference count is incremented. When the data are overwritten (by calling SPD or SPDI with the same ) or the object is destroyed, ::Release() is called and the interface's reference count is decremented.

If the data returned is a reference to an , or one of its derivative classes, previously set by , then ::Release() must be called on the reference before the reference is freed to decrement the reference count.

When the EnumOutputs method succeeds and fills the ppOutput parameter with the address of the reference to the output interface, EnumOutputs increments the output interface's reference count. To avoid a memory leak, when you finish using the output interface, call the Release method to decrement the reference count.

EnumOutputs first returns the output on which the desktop primary is displayed. This adapter corresponds with an index of zero. EnumOutputs then returns other outputs.

Graphics applications can use the DXGI API to retrieve an accurate set of graphics memory values on systems that have WDDM drivers. The following are the critical steps involved.

• Graphics driver model determination ? Because DXGI is only available on systems with WDDM drivers, the application must first confirm the driver model by using the following API.

   HasWDDMDriver()	
              { LPDIRECT3DCREATE9EX pD3D9Create9Ex = null; HMODULE             hD3D9          = null; hD3D9 = LoadLibrary( L"d3d9.dll" ); if ( null == hD3D9 ) { return false; } // /*  Try to create  interface (also known as a DX9L interface). This interface can only be created if the driver is a WDDM driver. */ // pD3D9Create9Ex = (LPDIRECT3DCREATE9EX) GetProcAddress( hD3D9, "Direct3DCreate9Ex" ); return pD3D9Create9Ex != null;	
              } 

• Retrieval of graphics memory values.? After the driver model is determined to be WDDM, the application can use the DirectX 10 or later API and DXGI to get the amount of graphics memory. After creating a Direct3D device the following code can be used to obtain a structure containing the amount of available graphics memory.

    * pDXGIDevice;	
              hr = g_pd3dDevice->QueryInterface(__uuidof(), (void **)&pDXGIDevice);	
               * pDXGIAdapter;	
              pDXGIDevice->GetAdapter(&pDXGIAdapter);	
               adapterDesc;	
              pDXGIAdapter->GetDesc(&adapterDesc); 

Note??You can use CheckInterfaceSupport only to check whether a Direct3D 10.x interface is supported, and only on Windows Vista SP1 and later versions of the operating system. If you try to use CheckInterfaceSupport to check whether a Direct3D 11.x and later version interface is supported, CheckInterfaceSupport returns . Therefore, do not use CheckInterfaceSupport. Instead, to verify whether the operating system supports a particular interface, try to create the interface. For example, if you call the method and it fails, the operating system does not support the interface.

Graphics applications can use the DXGI API to retrieve an accurate set of graphics memory values on systems that have WDDM drivers. The following are the critical steps involved.

• Graphics driver model determination ? Because DXGI is only available on systems with WDDM drivers, the application must first confirm the driver model by using the following API.

   HasWDDMDriver()	
              { LPDIRECT3DCREATE9EX pD3D9Create9Ex = null; HMODULE             hD3D9          = null; hD3D9 = LoadLibrary( L"d3d9.dll" ); if ( null == hD3D9 ) { return false; } // /*  Try to create  interface (also known as a DX9L interface). This interface can only be created if the driver is a WDDM driver. */ // pD3D9Create9Ex = (LPDIRECT3DCREATE9EX) GetProcAddress( hD3D9, "Direct3DCreate9Ex" ); return pD3D9Create9Ex != null;	
              } 

• Retrieval of graphics memory values.? After the driver model is determined to be WDDM, the application can use the DirectX 10 or later API and DXGI to get the amount of graphics memory. After creating a Direct3D device the following code can be used to obtain a structure containing the amount of available graphics memory.

    * pDXGIDevice;	
              hr = g_pd3dDevice->QueryInterface(__uuidof(), (void **)&pDXGIDevice);	
               * pDXGIAdapter;	
              pDXGIDevice->GetAdapter(&pDXGIAdapter);	
               adapterDesc;	
              pDXGIAdapter->GetDesc(&adapterDesc); 

The interface is designed for use by DXGI objects that need access to other DXGI objects. This interface is useful to applications that do not use Direct3D to communicate with DXGI.

The object returned by the Direct3D create device functions implements the interface and can be queried for the device's corresponding interface. To retrieve the interface of a Direct3D device the following code can be used.

 * pDXGIDevice;	
            hr = g_pd3dDevice->QueryInterface(__uuidof(), (void **)&pDXGIDevice);	
            

If the GetAdapter method succeeds, the reference count on the adapter interface will be incremented. To avoid a memory leak, be sure to release the interface when you are finished using it.

The CreateSurface method creates a buffer to exchange data between one or more devices. It is used internally, and you should not directly call it.

The runtime automatically creates an interface when it creates a Direct3D resource object that represents a surface. For example, the runtime creates an interface when it calls or to create a 2D texture. To retrieve the interface that represents the 2D texture surface, call ID3D11Texture2D::QueryInterface or ID3D10Texture2D::QueryInterface. In this call, you must pass the identifier of . If the 2D texture has only a single MIP-map level and does not consist of an array of textures, QueryInterface succeeds and returns a reference to the interface reference. Otherwise, QueryInterface fails and does not return the reference to .

The information returned by the pResidencyStatus argument array describes the residency status at the time that the QueryResourceResidency method was called. Note that the residency status will constantly change.

If you call the QueryResourceResidency method during a device removed state, the pResidencyStatus argument will return the flag.

Note??This method should not be called every frame as it incurs a non-trivial amount of overhead.

The information returned by the pResidencyStatus argument array describes the residency status at the time that the QueryResourceResidency method was called. Note that the residency status will constantly change.

If you call the QueryResourceResidency method during a device removed state, the pResidencyStatus argument will return the flag.

Note??This method should not be called every frame as it incurs a non-trivial amount of overhead.

The values for the Priority parameter function as follows:

• Positive values increase the likelihood that the GPU scheduler will grant GPU execution cycles to the device when rendering.
• Negative values lessen the likelihood that the device will receive GPU execution cycles when devices compete for them.
• The device is guaranteed to receive some GPU execution cycles at all settings.

To use the SetGPUThreadPriority method, you should have a comprehensive understanding of GPU scheduling. You should profile your application to ensure that it behaves as intended. If used inappropriately, the SetGPUThreadPriority method can impede rendering speed and result in a poor user experience.

If the GetAdapter method succeeds, the reference count on the adapter interface will be incremented. To avoid a memory leak, be sure to release the interface when you are finished using it.

The type of interface that is returned can be any interface published by the device. For example, it could be an * called pDevice, and therefore the REFIID would be obtained by calling __uuidof(pDevice).

Create a factory by calling CreateDXGIFactory.

Because a Direct3D device can be created without creating a swap chain, you might need to retrieve the factory that is used to create the device in order to create a swap chain. This can be accomplished by requesting the interface from the Direct3D device and then using to locate the factory. The following code illustrates the process.

 * pDXGIDevice;	
            hr = g_pd3dDevice->QueryInterface(__uuidof(), (void **)&pDXGIDevice);  * pDXGIAdapter;	
            hr = pDXGIDevice->GetParent(__uuidof(), (void **)&pDXGIAdapter);  * pIDXGIFactory;	
            pDXGIAdapter->GetParent(__uuidof(), (void **)&pIDXGIFactory);	
            

See for a diagram of the relationship between DXGI objects.

When you create a factory, the factory enumerates the set of adapters that are available in the system. Therefore, if you change the adapters in a system, you must destroy and recreate the object. The number of adapters in a system changes when you add or remove a display card, or dock or undock a laptop.

When the EnumAdapters method succeeds and fills the ppAdapter parameter with the address of the reference to the adapter interface, EnumAdapters increments the adapter interface's reference count. When you finish using the adapter interface, call the Release method to decrement the reference count before you destroy the reference.

EnumAdapters first returns the local adapter with the output on which the desktop primary is displayed. This adapter corresponds with an index of zero. EnumAdapters then returns other adapters with outputs.

The combination of WindowHandle and Flags informs DXGI to stop monitoring window messages for the previously-associated window.

If the application switches to full-screen mode, DXGI will choose a full-screen resolution to be the smallest supported resolution that is larger or the same size as the current back buffer size.

Applications can make some changes to make the transition from windowed to full screen more efficient. For example, on a WM_SIZE message, the application should release any outstanding swap-chain back buffers, call , then re-acquire the back buffers from the swap chain(s). This gives the swap chain(s) an opportunity to resize the back buffers, and/or recreate them to enable full-screen flipping operation. If the application does not perform this sequence, DXGI will still make the full-screen/windowed transition, but may be forced to use a stretch operation (since the back buffers may not be the correct size), which may be less efficient. Even if a stretch is not required, presentation may not be optimal because the back buffers might not be directly interchangeable with the front buffer. Thus, a call to ResizeBuffers on WM_SIZE is always recommended, since WM_SIZE is always sent during a fullscreen transition.

While windowed, the application can, if it chooses, restrict the size of its window's client area to sizes to which it is comfortable rendering. A fully flexible application would make no such restriction, but UI elements or other design considerations can, of course, make this flexibility untenable. If the application further chooses to restrict its window's client area to just those that match supported full-screen resolutions, the application can field WM_SIZING, then check against . If a matching mode is found, allow the resize. (The can be retrieved from . Absent subsequent changes to desktop topology, this will be the same output that will be chosen when alt-enter is fielded and fullscreen mode is begun for that swap chain.)

Applications that want to handle mode changes or Alt+Enter themselves should call MakeWindowAssociation with the flag after swap chain creation. The WindowHandle argument, if non-null, specifies that the application message queues will not be handled by the DXGI runtime for all swap chains of a particular target . Calling MakeWindowAssociation with the flag after swapchain creation ensures that DXGI will not interfere with application's handling of window mode changes or Alt+Enter.

If a Metro style app calls MakeWindowAssociation, it fails with .

A Microsoft Win32 application can use MakeWindowAssociation to control full-screen transitions through the Alt+Enter key combination and print screen behavior for full screen. For Metro style apps, because DXGI cannot perform full-screen transitions, Metro style app have no way to control full-screen transitions.

If a Metro style app calls GetWindowAssociation, it fails with .

If you attempt to create a swap chain in full-screen mode, and full-screen mode is unavailable, the swap chain will be created in windowed mode and will be returned.

If the buffer width or the buffer height is zero, the sizes will be inferred from the output window size in the swap-chain description.

Because the target output cannot be chosen explicitly when the swap-chain is created, you should not create a full-screen swap chain. This can reduce presentation performance if the swap chain size and the output window size do not match. Here are two ways to ensure that the sizes match:

• Create a windowed swap chain and then set it full-screen using .
• Save a reference to the swap chain immediately after creation, and use it to get the output window size during a WM_SIZE event. Then resize the swap chain buffers (with ) during the transition from windowed to full-screen.

If the swap chain is in full-screen mode, before you release it you must use SetFullscreenState to switch it to windowed mode. For more information about releasing a swap chain, see the "Destroying a Swap Chain" section of DXGI Overview.

You can specify and values in the swap-chain description that pDesc points to. These values allow you to use features like flip-model presentation and content protection by using pre-Windows Developer Preview APIs.

However, to use stereo presentation and to change resize behavior for the flip model, applications must use the IDXGIFactory2::CreateSwapChainForHwnd method. Otherwise, the back-buffer contents implicitly scale to fit the presentation target size; that is, you can't turn off scaling.

If a Metro style app calls CreateSwapChain with full screen specified, CreateSwapChain fails.

Metro style apps call the IDXGIFactory2::CreateSwapChainForImmersiveWindow method to create a swap chain.

A software adapter is a DLL that implements the entirety of a device driver interface, plus emulation, if necessary, of kernel-mode graphics components for Windows. Details on implementing a software adapter can be found in the Windows Vista Driver Development Kit. This is a very complex development task, and is not recommended for general readers.

Calling this method will increment the module's reference count by one. The reference count can be decremented by calling FreeLibrary.

The typical calling scenario is to call LoadLibrary, pass the handle to CreateSoftwareAdapter, then immediately call FreeLibrary on the DLL and forget the DLL's HMODULE. Since the software adapter calls FreeLibrary when it is destroyed, the lifetime of the DLL will now be owned by the adapter, and the application is free of any further consideration of its lifetime.

This interface is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

To create a factory, call the CreateDXGIFactory1 function.

This method is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

When you create a factory, the factory enumerates the set of adapters that are available in the system. Therefore, if you change the adapters in a system, you must destroy and recreate the object. The number of adapters in a system changes when you add or remove a display card, or dock or undock a laptop.

When the EnumAdapters1 method succeeds and fills the ppAdapter parameter with the address of the reference to the adapter interface, EnumAdapters1 increments the adapter interface's reference count. When you finish using the adapter interface, call the Release method to decrement the reference count before you destroy the reference.

EnumAdapters1 first returns the local adapter with the output on which the desktop primary is displayed. This adapter corresponds with an index of zero. EnumAdapters1 next returns other adapters with outputs. EnumAdapters1 finally returns adapters without outputs.

This method is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

This method is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

The enumerated type is used by the Flags member of the or DXGI_ADAPTER_DESC2 structure to identify the type of DXGI adapter.

A few formats have additional restrictions.

1. A resource declared with the DXGI_FORMAT_R32G32B32 family of formats cannot be used simultaneously for vertex and texture data. That is, you may not create a buffer resource with the DXGI_FORMAT_R32G32B32 family of formats that uses any of the following bind flags: , , , or (see ).
2. is designed specifically for text filtering, and must be used with a format-specific, configurable 8x8 filter mode. When calling an HLSL sampling function using this format, the address offset parameter must be set to (0,0).
3. A resource using a sub-sampled format (such as DXGI_FORMAT_R8G8_B8G8) must have a size that is a multiple of 2 in the x dimension.
4. Format is not available in Direct3D 10 and Direct3D 10.1

The following topics provide lists of the formats that particular hardware feature levels support:

• Hardware Support for Direct3D 11.1 Formats
• Hardware Support for Direct3D 11 Formats
• Hardware Support for Direct3D 10.1 Formats
• Hardware Support for Direct3D 10 Formats
• Hardware Support for Direct3D 10Level9 Formats

For a list of the DirectXMath types that map to values, see DirectXMath Library Internals.

Each enumeration value contains a format modifier which describes the data type.

 , , , ,	
            

?

Direct3D 10 offers new data compression formats for compressing high-dynamic range (HDR) lighting data, normal maps and heightfields to a fraction of their original size. These compression types include:

• Shared-Exponent high-dynamic range (HDR) format (RGBE)
• New Block-Compressed 1-2 channel UNORM/SNORM formats

The block compression formats can be used for any of the 2D or 3D texture types ( Texture2D, Texture2DArray, Texture3D, or TextureCube) including mipmap surfaces. The block compression techniques require texture dimensions to be a multiple of 4 (since the implementation compresses on blocks of 4x4 texels). In the texture sampler, compressed formats are always decompressed before texture filtering.

This enumeration is used by the structure and the method.

This enumeration is also used by the DXGI_SWAP_CHAIN_DESC1 structure.

Swap chains that you create in full-screen mode with the method behave as if DXGI_SWAP_CHAIN_FLAG_DISPLAY_ONLY is set even though the flag is not set. That is, presented content is not accessible by remote access or through the desktop duplication APIs.

Swap chains that you create with the IDXGIFactory2::CreateSwapChainForHwnd, IDXGIFactory2::CreateSwapChainForImmersiveWindow, and IDXGIFactory2::CreateSwapChainForCompositionSurface methods are not protected if DXGI_SWAP_CHAIN_FLAG_DISPLAY_ONLY is not set and are protected if DXGI_SWAP_CHAIN_FLAG_DISPLAY_ONLY is set. When swap chains are protected, screen scraping is prevented and, in full-screen mode, presented content is not accessible through the desktop duplication APIs.

This enumeration is used by the structure.

This enumeration is also used by the DXGI_SWAP_CHAIN_DESC1 structure.

The primary difference between presentation models is how back-buffer contents get to the Desktop Window Manager (DWM) for composition. In the bitblt model, which is used with the and values, contents of the back buffer get copied into the redirection surface on each call to . In the flip model, which is used with the DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL value, all back buffers are shared with the DWM. Therefore, the DWM can compose straight from those back buffers without any additional copy operations. In general, the flip model is the more efficient model. The flip model also provides more features, such as enhanced present statistics.

Regardless of whether the flip model is more efficient, an application still might choose the bitblt model for the following reasons:

• The bitblt model is the only way to mix GDI and DirectX presentation.

  In the flip model, the application must create the swap chain with , and then must use GetDC on the back buffer explicitly. After the first successful call to on a flip-model swap chain, GDI no longer works with the that is associated with that swap chain, even after the destruction of the swap chain. This restriction even extends to methods like ScrollWindowEx.

• The flip model requires at least three window-sized buffers if the application uses child windows. For the bitblt model, this minimum is two buffers.

Use a DXGI 1.1 factory to generate objects that enumerate adapters, create swap chains, and associate a window with the alt+enter key sequence for toggling to and from the full-screen display mode.

If the CreateDXGIFactory1 function succeeds, the reference count on the interface is incremented. To avoid a memory leak, when you finish using the interface, call the IDXGIFactory1::Release method to release the interface.

This entry point is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

Note??Do not mix the use of DXGI 1.0 () and DXGI 1.1 () in an application. Use or , but not both in an application.

Use a DXGI factory to generate objects that enumerate adapters, create swap chains, and associate a window with the alt+enter key sequence for toggling to and from the fullscreen display mode.

If the CreateDXGIFactory function succeeds, the reference count on the interface is incremented. To avoid a memory leak, when you finish using the interface, call the IDXGIFactory::Release method to release the interface.

Note??Do not mix the use of DXGI 1.0 () and DXGI 1.1 () in an application. Use or , but not both in an application.

The CreateDXGIFactory function does not exist for Metro style apps. Instead, Metro style apps use the CreateDXGIFactory1 function.

This interface is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

A display sub-system is often referred to as a video card, however, on some machines the display sub-system is part of the mother board.

To enumerate the display sub-systems, use . To get an interface to the adapter for a particular device, use . To create a software adapter, use .

This method is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

Use the GetDesc1 method to get a DXGI 1.1 description of an adapter. To get a DXGI 1.0 description, use the method.

This method is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

Use the GetDesc1 method to get a DXGI 1.1 description of an adapter. To get a DXGI 1.0 description, use the method.

This interface is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

The interface is designed for use by DXGI objects that need access to other DXGI objects. This interface is useful to applications that do not use Direct3D to communicate with DXGI.

This method is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

Frame latency is the number of frames that are allowed to be stored in a queue before submission for rendering. Latency is often used to control how the CPU chooses between responding to user input and frames that are in the render queue. It is often beneficial for applications that have no user input (for example, video playback) to queue more than 3 frames of data.

This method is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

Frame latency is the number of frames that are allowed to be stored in a queue before submission for rendering. Latency is often used to control how the CPU chooses between responding to user input and frames that are in the render queue. It is often beneficial for applications that have no user input (for example, video playback) to queue more than 3 frames of data.

This method is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

Frame latency is the number of frames that are allowed to be stored in a queue before submission for rendering. Latency is often used to control how the CPU chooses between responding to user input and frames that are in the render queue. It is often beneficial for applications that have no user input (for example, video playback) to queue more than 3 frames of data.

The AcquireSync method creates a lock to a surface that is shared between multiple devices, allowing only one device to render to a surface at a time. This method uses a key to determine which device currently has exclusive access to the surface.

When a surface is created using the value of the enumeration, you must call the AcquireSync method before rendering to the surface. You must call the ReleaseSync method when you are done rendering to a surface.

To acquire a reference to the keyed mutex object of a shared resource, call the QueryInterface method of the resource and pass in the UUID of the interface. For more information about acquiring this reference, see the following code example.

The AcquireSync method uses the key as follows, depending on the state of the surface:

• On initial creation, the surface is unowned and any device can call the AcquireSync method to gain access. For an unowned device, only a key of 0 will succeed. Calling the AcquireSync method for any other key will stall the calling CPU thread.
• If the surface is owned by a device when you call the AcquireSync method, the CPU thread that called the AcquireSync method will stall until the owning device calls the ReleaseSync method using the same Key.
• If the surface is unowned when you call the AcquireSync method (for example, the last owning device has already called the ReleaseSync method), the AcquireSync method will succeed if you specify the same key that was specified when the ReleaseSync method was last called. Calling the AcquireSync method using any other key will cause a stall.
• When the owning device calls the ReleaseSync method with a particular key, and more than one device is waiting after calling the AcquireSync method using the same key, any one of the waiting devices could be woken up first. The order in which devices are woken up is undefined.
• A keyed mutex does not support recursive calls to the AcquireSync method.

The AcquireSync method creates a lock to a surface that is shared between multiple devices, allowing only one device to render to a surface at a time. This method uses a key to determine which device currently has exclusive access to the surface.

When a surface is created using the value of the enumeration, you must call the AcquireSync method before rendering to the surface. You must call the ReleaseSync method when you are done rendering to a surface.

To acquire a reference to the keyed mutex object of a shared resource, call the QueryInterface method of the resource and pass in the UUID of the interface. For more information about acquiring this reference, see the following code example.

The AcquireSync method uses the key as follows, depending on the state of the surface:

• On initial creation, the surface is unowned and any device can call the AcquireSync method to gain access. For an unowned device, only a key of 0 will succeed. Calling the AcquireSync method for any other key will stall the calling CPU thread.
• If the surface is owned by a device when you call the AcquireSync method, the CPU thread that called the AcquireSync method will stall until the owning device calls the ReleaseSync method using the same Key.
• If the surface is unowned when you call the AcquireSync method (for example, the last owning device has already called the ReleaseSync method), the AcquireSync method will succeed if you specify the same key that was specified when the ReleaseSync method was last called. Calling the AcquireSync method using any other key will cause a stall.
• When the owning device calls the ReleaseSync method with a particular key, and more than one device is waiting after calling the AcquireSync method using the same key, any one of the waiting devices could be woken up first. The order in which devices are woken up is undefined.
• A keyed mutex does not support recursive calls to the AcquireSync method.

The ReleaseSync method releases a lock to a surface that is shared between multiple devices. This method uses a key to determine which device currently has exclusive access to the surface.

When a surface is created using the value of the enumeration, you must call the method before rendering to the surface. You must call the ReleaseSync method when you are done rendering to a surface.

After you call the ReleaseSync method, the shared resource is unset from the rendering pipeline.

To acquire a reference to the keyed mutex object of a shared resource, call the QueryInterface method of the resource and pass in the UUID of the interface. For more information about acquiring this reference, see the following code example.

To see the outputs available, use . To see the specific output that the swap chain will update, use .

In general, when switching from windowed to full-screen mode, a swap chain automatically chooses a display mode that meets (or exceeds) the resolution, color depth and refresh rate of the swap chain. To exercise more control over the display mode, use this API to poll the set of display modes that are validated against monitor capabilities, or all modes that match the desktop (if the desktop settings are not validated against the monitor).

As shown, this API is designed to be called twice. First to get the number of modes available, and second to return a description of the modes.

 UINT num = 0;	
             format = ;	
            UINT flags         = ; pOutput->GetDisplayModeList( format, flags, &num, 0); ...  * pDescs = new [num];	
            pOutput->GetDisplayModeList( format, flags, &num, pDescs); 

FindClosestMatchingMode behaves similarly to the IDXGIOutput1::FindClosestMatchingMode1 except FindClosestMatchingMode considers only the mono display modes. IDXGIOutput1::FindClosestMatchingMode1 considers only stereo modes if you set the Stereo member in the DXGI_MODE_DESC1 structure that pModeToMatch points to, and considers only mono modes if Stereo is not set.

IDXGIOutput1::FindClosestMatchingMode1 returns a matched display-mode set with only stereo modes or only mono modes. FindClosestMatchingMode behaves as though you specified the input mode as mono.

A vertical blank occurs when the raster moves from the lower right corner to the upper left corner to begin drawing the next frame.

When you are finished with the output, call .

TakeOwnership should not be called directly by applications, since results will be unpredictable. It is called implicitly by the DXGI swap chain object during full-screen transitions, and should not be used as a substitute for swap-chain methods.

If a Metro style app uses TakeOwnership, it fails with .

If you are not using a swap chain, get access to an output by calling and release it when you are finished by calling . An application that uses a swap chain will typically not call either of these methods.

Note??Calling this method is only supported while in full-screen mode.

Note??Calling this method is only supported while in full-screen mode.

Note??Calling this method is only supported while in full-screen mode.

should not be called directly by applications, since results will be unpredictable. It is called implicitly by the DXGI swap chain object during full-screen transitions, and should not be used as a substitute for swap-chain methods.

This method should only be called between and calls.

If a Metro style app uses SetDisplaySurface, it fails with .

can only be called when an output is in full-screen mode. If the method succeeds, DXGI fills the destination surface.

Use to determine the size (width and height) of the output when you want to allocate space for the destination surface. This is true regardless of target monitor rotation. A destination surface created by a graphics component (such as Direct3D 10) must be created with CPU-write permission (see ). Other surfaces should be created with CPU read-write permission (see D3D10_CPU_ACCESS_READ_WRITE). This method will modify the surface data to fit the destination surface (stretch, shrink, convert format, rotate). The stretch and shrink is performed with point-sampling.

This API is similar to .

Note??Calling this method is only supported while in full-screen mode.

Note??Calling this method is only supported while in full-screen mode.

Note??Calling this method is only supported while in full-screen mode.

This API is similar to .

Note??Calling this method is only supported while in full-screen mode.

To find out what type of memory a resource is currently located in, use . To share resources between processes, use . For information about how to share resources between multiple Windows graphics APIs, including Direct3D 11, Direct2D, Direct3D 10, and Direct3D 9Ex, see Surface Sharing Between Windows Graphics APIs.

You can retrieve the interface from any video memory resource that you create from a Direct3D 10 and later function. Any Direct3D object that supports or also supports . For example, the Direct3D 2D texture object that you create from supports . You can call QueryInterface on the 2D texture object () to retrieve the interface. For example, to retrieve the interface from the 2D texture object, use the following code.

 * pDXGIResource;	
            hr = g_pd3dTexture2D->QueryInterface(__uuidof(), (void **)&pDXGIResource);	
            

You can pass the handle that GetSharedHandle returns in a call to the method to give a device access to a shared resource that you created on a different device.

GetSharedHandle doesn't always return a handle. GetSharedHandle only returns the handle when you created the resource as shared (that is, you set the or flag).

The handle that GetSharedHandle returns is not an NT handle. Therefore, don't use the handle with CloseHandle, DuplicateHandle, and so on. The creator of a shared resource must not destroy the resource until all entities that opened the resource have destroyed the resource. The validity of the handle is tied to the lifetime of the underlying video memory. If no resource objects exist on any devices that refer to this resource, the handle is no longer valid. To extend the lifetime of the handle and video memory, you must open the shared resource on a device.

The eviction priority is a memory-management variable that is used by DXGI for determining how to populate overcommitted memory.

You can set priority levels other than the defined values when appropriate. For example, you can set a resource with a priority level of 0x78000001 to indicate that the resource is slightly above normal.

The eviction priority is a memory-management variable that is used by DXGI to determine how to manage overcommitted memory.

Priority levels other than the defined values are used when appropriate. For example, a resource with a priority level of 0x78000001 indicates that the resource is slightly above normal.

You can pass the handle that GetSharedHandle returns in a call to the method to give a device access to a shared resource that you created on a different device.

GetSharedHandle doesn't always return a handle. GetSharedHandle only returns the handle when you created the resource as shared (that is, you set the or flag).

The handle that GetSharedHandle returns is not an NT handle. Therefore, don't use the handle with CloseHandle, DuplicateHandle, and so on. The creator of a shared resource must not destroy the resource until all entities that opened the resource have destroyed the resource. The validity of the handle is tied to the lifetime of the underlying video memory. If no resource objects exist on any devices that refer to this resource, the handle is no longer valid. To extend the lifetime of the handle and video memory, you must open the shared resource on a device.

The eviction priority is a memory-management variable that is used by DXGI to determine how to manage overcommitted memory.

Priority levels other than the defined values are used when appropriate. For example, a resource with a priority level of 0x78000001 indicates that the resource is slightly above normal.

An image-data object is a 2D section of memory, commonly called a surface. To get the surface from an output, call .

The runtime automatically creates an interface when it creates a Direct3D resource object that represents a surface. For example, the runtime creates an interface when you call or to create a 2D texture. To retrieve the interface that represents the 2D texture surface, call ID3D11Texture2D::QueryInterface or ID3D10Texture2D::QueryInterface. In this call, you must pass the identifier of . If the 2D texture has only a single MIP-map level and does not consist of an array of textures, QueryInterface succeeds and returns a reference to the interface reference. Otherwise, QueryInterface fails and does not return the reference to .

Use to access a surface from the CPU. To release a mapped surface (and allow GPU access) call .

This interface is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

An image-data object is a 2D section of memory, commonly called a surface. To get the surface from an output, call . Then, call QueryInterface on the object that returns to retrieve the interface.

Any object that supports also supports .

The runtime automatically creates an interface when it creates a Direct3D resource object that represents a surface. For example, the runtime creates an interface when you call or to create a 2D texture. To retrieve the interface that represents the 2D texture surface, call ID3D11Texture2D::QueryInterface or ID3D10Texture2D::QueryInterface. In this call, you must pass the identifier of . If the 2D texture has only a single MIP-map level and does not consist of an array of textures, QueryInterface succeeds and returns a reference to the interface reference. Otherwise, QueryInterface fails and does not return the reference to .

This method is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

After you use the GetDC method to retrieve a DC, you can render to the DXGI surface by using GDI. The GetDC method readies the surface for GDI rendering and allows inter-operation between DXGI and GDI technologies.

Keep the following in mind when using this method:

• You must create the surface by using the flag for a surface or by using the flag for swap chains, otherwise this method fails.
• You must release the device and call the method before you issue any new Direct3D commands.
• This method fails if an outstanding DC has already been created by this method.
• The format for the surface or swap chain must be or .
• On GetDC, the render target in the output merger of the Direct3D pipeline is unbound from the surface. You must call the method on the device prior to Direct3D rendering after GDI rendering.
• Prior to resizing buffers you must release all outstanding DCs.

You can also call GetDC on the back buffer at index 0 of a swap chain by obtaining an from the swap chain. The following code illustrates the process.

 * g_pSwapChain = null;	
            * g_pSurface1 = null;	
            ...	
            //Setup the device and and swapchain	
            g_pSwapChain->GetBuffer(0, __uuidof(), (void**) &g_pSurface1);	
            g_pSurface1->GetDC( , &g_hDC );	
            ...      	
            //Draw on the DC using GDI	
            ...	
            //When finish drawing release the DC	
            g_pSurface1->ReleaseDC( null ); 

This method is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

Use the ReleaseDC method to release the DC and indicate that your application finished all GDI rendering to this surface. You must call the ReleaseDC method before you can use Direct3D to perform additional rendering.

Prior to resizing buffers you must release all outstanding DCs.

You can create a swap chain in several ways. If your application uses Direct3D, create a swap chain when you create a device by calling or . If your application does not need Direct3D, create a swap chain for use directly with DXGI by calling , IDXGIFactory2::CreateSwapChainForHwnd, IDXGIFactory2::CreateSwapChainForImmersiveWindow, or IDXGIFactory2::CreateSwapChainForCompositionSurface.

For the best performance when flipping swap-chain buffers in a full-screen application, see Full-Screen Application Performance Hints.

Because calling Present might cause the render thread to wait on the message-pump thread, be careful when calling this method in an application that uses multiple threads. For more details, see Multithreading Considerations.

?

For flip presentation model swap chains that you create with the DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL value set, a successful presentation unbinds back buffer 0 from the graphics pipeline, except for when you pass the flag in the Flags parameter.

Suppose the following frames with sync-interval values are queued from oldest (A) to newest (E) before you call Present.

A: 3, B: 0, C: 0, D: 1, E: 0

When you call Present, the runtime shows frame A for 3 vertical blank intervals, then frame D for 1 vertical blank interval, and then frame E until you submit a new presentation. The runtime discards frames C and D.

DXGI may change the display state of a swap chain in response to end user or system requests.

We recommend that you create a windowed swap chain and allow the end user to change the swap chain to full screen through SetFullscreenState; that is, do not set the Windowed member of to to force the swap chain to be full screen. However, if you create the swap chain as full screen, also provide the end user with a list of supported display modes because a swap chain that is created with an unsupported display mode might cause the display to go black and prevent the end user from seeing anything. Also, we recommend that you have a time-out confirmation screen or other fallback mechanism when you allow the end user to change display modes.

If a Metro style app calls SetFullscreenState to set the display state to full screen, SetFullscreenState fails with .

You cannot call SetFullscreenState on a windowless swap chain that you created with IDXGIFactory2::CreateSwapChainForCompositionSurface.

For the flip presentation model, after you transition the display state to full screen, you must call ResizeBuffers to ensure that your call to IDXGISwapChain1::Present1 succeeds.

When the swap chain is in full-screen mode, a reference to the target output will be returned and its reference count will be incremented.

You can't resize a swap chain unless you release all outstanding references to its back buffers. You must release all of its direct and indirect references on the back buffers in order for ResizeBuffers to succeed.

Direct references are held by the application after it calls AddRef on a resource.

Indirect references are held by views to a resource, binding a view of the resource to a device context, a command list that used the resource, a command list that used a view to that resource, a command list that executed another command list that used the resource, and so on.

Before you call ResizeBuffers, ensure that the application releases all references (by calling the appropriate number of Release invocations) on the resources, any views to the resource, and any command lists that use either the resources or views, and ensure that neither the resource nor a view is still bound to a device context. You can use to ensure that all references are released. If a view is bound to a deferred context, you must discard the partially built command list as well (by calling ClearState, , then Release on the command list). After you call ResizeBuffers, you can re-query interfaces via .

For swap chains that you created with , before you call ResizeBuffers, also call on the swap chain's back-buffer surface to ensure that you have no outstanding GDI device contexts (DCs) open.

We recommend that you call ResizeBuffers when a client window is resized (that is, when an application receives a WM_SIZE message).

The only difference between ResizeBuffers in Windows Developer Preview and ResizeBuffers in Windows?7 is with flip presentation model swap chains that you create with the DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL value set. In Windows Developer Preview, you must call ResizeBuffers to realize a transition between full-screen mode and windowed mode; otherwise, your next call to the Present method fails.

ResizeTarget resizes the target window when the swap chain is in windowed mode, and changes the display mode on the target output when the swap chain is in full-screen mode. Therefore, applications can call ResizeTarget to resize the target window (rather than a Microsoft Win32API such as SetWindowPos) without knowledge of the swap chain display mode.

If a Metro style app calls ResizeTarget, it fails with .

You cannot call ResizeTarget on a windowless swap chain that you created with IDXGIFactory2::CreateSwapChainForCompositionSurface.

If the method succeeds, the output interface will be filled and its reference count incremented. When you are finished with it, be sure to release the interface to avoid a memory leak.

The output is also owned by the adapter on which the swap chain's device was created.

You cannot call GetContainingOutput on a windowless swap chain that you created with IDXGIFactory2::CreateSwapChainForCompositionSurface.

You cannot use GetFrameStatistics for swap chains that both use the bit-block transfer (bitblt) presentation model and draw in windowed mode.

You can only use GetFrameStatistics for swap chains that either use the flip presentation model or draw in full-screen mode. You set the DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL value in the SwapEffect member of the DXGI_SWAP_CHAIN_DESC1 structure to specify that the swap chain uses the flip presentation model.

For info about presentation statistics for a frame, see .

If the method succeeds, the output interface will be filled and its reference count incremented. When you are finished with it, be sure to release the interface to avoid a memory leak.

The output is also owned by the adapter on which the swap chain's device was created.

You cannot call GetContainingOutput on a windowless swap chain that you created with IDXGIFactory2::CreateSwapChainForCompositionSurface.

You cannot use GetFrameStatistics for swap chains that both use the bit-block transfer (bitblt) presentation model and draw in windowed mode.

You can only use GetFrameStatistics for swap chains that either use the flip presentation model or draw in full-screen mode. You set the DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL value in the SwapEffect member of the DXGI_SWAP_CHAIN_DESC1 structure to specify that the swap chain uses the flip presentation model.

For info about presentation statistics for a frame, see .

The structure provides a description of an adapter. This structure is initialized by using the method.

The structure provides a DXGI 1.1 description of an adapter. This structure is initialized by using the method.

You initialize the structure with the or method.

You can only use for swap chains that either use the flip presentation model or draw in full-screen mode. You set the DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL value in the SwapEffect member of the DXGI_SWAP_CHAIN_DESC1 structure to specify that the swap chain uses the flip presentation model.

The values in the PresentCount and PresentRefreshCount members indicate information about when a frame was presented on the display screen. You can use these values to determine whether a glitch occurred. The values in the SyncRefreshCount and SyncQPCTime members indicate timing information that you can use for audio and video synchronization or very precise animation. If the swap chain draws in full-screen mode, these values are based on when the computer booted. If the swap chain draws in windowed mode, these values are based on when the swap chain is created.

The structure is used by the method.

To get a list of the capabilities for controlling gamma correction, call .

The structure is initialized by the method.

The following format values are valid for display modes and when you create a bit-block transfer (bitblt) model swap chain. The valid values depend on the feature level that you are working with.

• Feature level >= 9.1

  • (except 10.x on Windows?Vista)
  • (except 10.x on Windows?Vista)

• Feature level >= 10.0

• Feature level >= 11.0

You can pass one of these format values to to determine if it is a valid format for displaying on screen. If returns in the bit field to which the pFormatSupport parameter points, the format is valid for displaying on screen.

Starting with Windows Developer Preview for a flip model swap chain (that is, a swap chain that has the DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL value set in the SwapEffect member of ), you must set the Format member of to , , or .

Because of the relaxed render target creation rules that Direct3D 11 has for back buffers, applications can create a render target view from a swap chain so they can use automatic color space conversion when they render the swap chain.

The structure is initialized by the method.

The structure operates under the following rules:

• 0/0 is legal and will be interpreted as 0/1.
• 0/anything is interpreted as zero.
• If you are representing a whole number, the denominator should be 1.

The default sampler mode, with no anti-aliasing, has a count of 1 and a quality level of 0.

If multi-sample antialiasing is being used, all bound render targets and depth buffers must have the same sample counts and quality levels.

?

To create a shared surface, pass a shared-resource handle into the method.

In full-screen mode, there is a dedicated front buffer; in windowed mode, the desktop is the front buffer.

If you create a swap chain with one buffer, specifying does not cause the contents of the single buffer to be swapped with the front buffer.

For performance information about flipping swap-chain buffers in full-screen application, see Full-Screen Application Performance Hints.