Harmless DXGI warnings with C++ AMP

  • Article

If you have tried to run C++ AMP program in Visual Studio 2012 on Windows 8 in debug configuration, you might have noticed that after a successful execution there are DXGI warnings reported in the output window. Long story short – there is nothing to worry about; these warnings may be safely ignored. If you are interested in the background, read on for more information.

DXGI_warnings

Fig. 1. Visual Studio 2012 with DXGI warnings visible in the output window.

DXGI

The DXGI acronym stands for Microsoft DirectX Graphics Infrastructure. It is a low-level layer used by DirectX to communicate with the kernel-mode GPU driver. As you may know, C++ AMP implementation provided by Microsoft builds on top of the DirectX stack, thus by extension, on top of DXGI. What is crucial here, is that Windows 8 introduces a new version, DXGI 1.2.

DXGI warnings

When you are working on Windows 8 and running your program in in debug configuration even the simplest code using C++ AMP will result in DXGI warnings being reported in the Visual Studio output window. They will look similar to the following:

DXGI WARNING: Process is terminating. Using simple reporting. Please call ReportLiveObjects() at runtime for standard reporting. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Producer at 0x006C4820, Refcount: 3. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Object at 0x006CBB18, Refcount: 3. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Object at 0x006E9328, Refcount: 1. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Object : 2 [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Process is terminating. Using simple reporting. Please call ReportLiveObjects() at runtime for standard reporting. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Producer at 0x006E9A28, Refcount: 2. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Object at 0x006EBE50, Refcount: 3. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Object : 1 [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Process is terminating. Using simple reporting. Please call ReportLiveObjects() at runtime for standard reporting. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Producer at 0x00716688, Refcount: 2. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Object at 0x00718A00, Refcount: 3. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Object : 1 [ STATE_CREATION WARNING #0: ]

To explain the conditions, reporting “live objects” is a part of the debugging capabilities added to DXGI 1.2. You can register for receiving these messages yourself using IDXGIInfoQueue interface or you can rely on them being printed to Visual Studio 2012 output window, which is automatically enabled when you are using DXGI (and by extension, C++ AMP) in the debug mode.

The reported warnings are last chance messages printed during DXGI shutdown. They include all DXGI objects being alive (meaning not released) at that point of time.

Does it mean that C++ AMP runtime is not freeing these objects? Yes. Is it harmful? No, since:

  1. There is a fixed number of such cached objects (consuming small amount of resources), and their count never goes up during the application lifetime.
  2. The resources associated with these objects are automatically reclaimed by the operating system at process exit.

Diving into a deeper explanation

To go a little deeper, the C++ AMP runtime caches some DXGI objects in its static structures to improve performance. For example this includes IDXGIAdapters underlying Direct3D accelerator objects. At a higher level, both the C++ AMP runtime and DXGI are dynamic libraries, where the first is a dependency of any C++ AMP program and the latter is a dependency of the runtime DLL. So far so good, static dependencies of DLLs aren’t the problem, however the situation complicates a little bit when we add truly dynamically loaded (i.e. using LoadLibrary) libraries to the equation. As it happens, the order of their unloading is not defined against other dynamic libraries. And actually they are quite common in C++ AMP programs, e.g. all driver DLLs are currently dynamically loaded by the DXGI. Going back to the C++ AMP runtime implementation, given that we cannot tell whether our DLL is being unloaded before or after the dynamically loaded driver DLL, we cannot safely release any object from it. But as I explained before, it’s not a problem, since the operating system is going to reclaim it anyway.

One solution would be not to cache DXGI objects. That’s a big no-no for us because caching buys us performance, and we (and you) like performance. The other workaround would be to suppress these messages. Unfortunately there is no way to selectively do so, and we do not want to inhibit this mechanism altogether, as some users might be creating DXGI objects themselves for their own use and might benefit from learning about extraordinary leaks.