2 Replies Latest reply on Oct 11, 2011 7:33 PM by georgepee

    Rare D3D9 mutlihead memory issue

    georgepee

      I've run across a very strange issue running 2 fullscreen windows, either in multihead mode, or as separate devices.

      My configuration is a x2400 mobility radeon, tried with both 9.3 catalyst drivers, 11.3, and 11.8.

      XPe SP3, Using DirectX9 (tried both March2009 and June2010), swap is disabled (on an embedded device).

      I have a D3D app that uses all of the available video memory, and I'm using managed textures.  When I lose a device, my Commit Charge (viewed via task manager) grows and grows, and it can get to a point where repeatedly losing the device (via ctrl-alt-del) will run into out of memory situations.

      Consequently, if I shut down the application, I may not have enough available memory to launch it again.

      I've run the directx debug with debug set to most verbose (with D3D_DEBUG_INFO #defined) with no memory leaks detected, looked through apitrace calls with no luck, played around with GPUPerfStudio (version 1.2), all without much information.  I've also tracked the return values from all IUnknown::Release calls to make sure the ref counts all go to 0.

      So, if I shut down the application, I end up with lots of memory in the commit charge that I can't reclaim.  What's really strange is that if, at this point,  I change the resolution via display properties, I see the commit charge drop.

      I have tested on various machines (XP, and XPe), but so far, I've only been able to duplicate it on XPe.  If I run the desktop resolution (or color depth) at a different resolution, then when I reset the d3d device, the memory usage drops.

      I've tried adding a call to EvictManagedResources prior to device reset, but this was not much help.

      If I'm running in windowed mode, or only running one monitor,  I don't see this problem.

      Has anyone ever seen an issue like this?  I keep trying to program my way around it, but since I don't know the actual problem, it's quite difficult.