Harmless DXGI warnings with C++ AMP

  • Artikel

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.

Comments

  • Anonymous
    February 19, 2013
    That's a very poor excuse, Lukasz. Please see the following thread. social.msdn.microsoft.com/.../6ebaf459-0715-4e30-8fcc-9ae499e2d714

  • Anonymous
    February 19, 2013
    Alan, I understand that this might be a problem for you and some other customers. This blog post is not meant to excuse ourselves, it is just to describe the current situation to the users. As Amit mentioned in the forum thread you are referring to, we do acknowledge it is not desirable and we want to improve it.

  • Anonymous
    February 19, 2013
    I do appreciate the transparency around talking about these warnings, they've been bugging me while working with the tech. Please do make fixing them a priority, because as it is they stand as broken windows in the product offering and detract from its perceived quality and robustness.

  • Anonymous
    March 14, 2013
    In my humble opinion I would prefer having to initialize and deinitialize this static cache objects which both APIs, something like "AMPInit" "AMPExit", so you can safely control when these objects are instanced and released respectively.

  • Anonymous
    March 20, 2013
    I am wondering why the result of the project is not posted here so that all of us can check our own work.

  • Anonymous
    August 07, 2013
    The comment has been removed

  • Anonymous
    August 08, 2013
    @Christian, please note that DXGI warning does not mean that the application is using C++ AMP. It is a generic warning and in fact C++ AMP was first released on VS 2012, so if you are using VS 2008 C++ AMP is not the reason for the warning.

  • Anonymous
    June 17, 2014
    The comment has been removed