2 Replies Latest reply on Feb 23, 2010 8:46 PM by bobvodka2

    D3D11 Deferred Context memory leak issue in driver?

    bobvodka2
      Map/Unmap with discard leads to memory leak

      I'm currently in the process of working on a highly threaded game using D3D11 on my HD5870.

      The current test application is split into two parts;

      • A rendering thread which processes a command list and has the main D3D device (although the device wasn't created on that thread)
      • The main thread which has a deferred context created for it which the rendering commands are currently processed on and then stored for later rendering on the other thread

      As part of the work done on the deferred context a map with discard operation is performed on a ID3D11Buffer, which is a structured buffer with the same number of elements as the back buffer. The values are updated and the buffer is unlocked again. After this some compute shader calls are carried out and the command list is stored ready to be rendered on the main thread.

      The main thread executes the required command list and then calls release on the command list past as per the MS DX SDK example for multi-threaded rendering.

      However, after running for a short time the map operation was failing with the following error;

      D3D11: WARNING: ID3D11Device::RemoveContext: Deferred Context removal has been triggered for the following reason (E_OUTOFMEMORY: The application tried to create a Command List that would require more memory than can be aquired.), meaning FinishCommandList will return an error. [ EXECUTION WARNING #2097206: DEFERRED_CONTEXT_REMOVAL_PROCESS_AT_FAULT ]

      D3D11: ERROR: ID3D11DeviceContext::Map: Returning E_OUTOFMEMORY, meaning memory was exhausted. [ RESOURCE_MANIPULATION ERROR #2097215: RESOURCE_MAP_OUTOFMEMORY_RETURN ]
      d:\documents\visual studio 2010\projects\d3d11mtdxgitest\d3d11mtdxgitest\d3d11mtdxgitest.cpp(230): g_pDeferredContext->Map(g_pTLMDriveDataBuffer,0,D3D11_MAP_WRITE_DISCARD,0,&resouce) hr=E_OUTOFMEMORY (0x8007000e)

      A quick look in task manager shows that the private working set for the application has reached 1,728,612k

      In order to check this wasn't an error with my own code I ran up the MS example and left it running during the day. While it's peak memory usage only made it to 41meg, restarting the app and running it again showed that it initally settles at around 37meg before slowly leaking upwards.

      Given that both my app and the MS example both show memory leaks it would seem to be the case that there is a serious flaw in how the drivers currently handle map/unmap operations with discard on deferred contexts.

      If anyone has any information on this, how to avoid it maybe(?), then it would be much appricated. If someone from the driver development team wishes to contact me then feel free as I'd like to help in any way I can to fix this as its a MAJOR problem for the app I'm currently working on and I suspect will become one in the future for others.

      I've subscribed to the post so that I can get any updates.

        • D3D11 Deferred Context memory leak issue in driver?
          bobvodka2

          Ok, upon further investigation it seems to be the case that even a 'present' is causing me to leak ~300k/sec (I've tested the command link with a NOP command and that doesn't leak), so I've a feeling the problem might well lay with the way I'm using the device thread wise.

          I'll continue to look into it...

            • D3D11 Deferred Context memory leak issue in driver?
              bobvodka2

              *ahem*

              So it turns out I'm an idiot

              I wrote some code while tired the other night and didn't check it for logic, so my code for firing off rendering submission stuff was happening far too quickly.

              The second problem appeared to be related to a macro I was using (SAFE_RELEASE) which didn't seem to be releasing for some reason; removing the macro and replacing it with a direct call to 'release' fixed the problem.

              So, false alarm there and I've learnt a lesson re:being more careful in future...

              Now, to fix the leaks I KNOW I caused