6 Replies Latest reply on Jan 17, 2011 6:20 AM by dexfx

    DX11 DSSetConstantBuffers causing memory leak

      Memory leaking in samples and my own app when tessellation enabled


      I've been playing around with tessellation in DX11, on HD5870 (x2). Problem is, setting the domain shader constant buffer seems to be leaking memory.

      I get this same problem with all of the DirectX 11 samples that include tessellation, including PNTriangles11 (the AMD sample), SimpleBezier11 and DetailTessellation11, and my own app that uses tessellation.

      The PNTriangles11 sample is the best example of the problem happening, since the tessellation can be turned on and off, which also turns the memory leaking on and off. Using the adaptive tessellation sometimes seems to speed up the memory leaking. My app leaks a lot faster than these samples, because I'm updating the domain shader constant buffer a lot more (once for each mesh drawn), instead of just once per frame.

      I was able to isolate the leak to being caused by DSSetConstantBuffers, since if I comment out that line the leak stops happening (but nothing is rendered properly).

      Debug leak check picks up nothing.

      I also posted a topic on the DX11 forum about this, at http://forums.xna.com/forums/t/54722.aspx

      System specs are: Win7, i7 920, 6GB RAM, HD5870 x2. CCC/driver version 10.5.




      I left PNTriangles11 running for a couple of hours using the reference device, and the leak didn't seem to happen. Which seems to point at the graphics drivers being the culprit..

        • DX11 DSSetConstantBuffers causing memory leak

          Did you ever find a solution for this?  I am getting this in my app as well.   I have updated to the latest beta driver (8753_RC2) but leak memory like crazy if I call DSSetConstantBuffers, even if I pass NULL for the buffers.  I am not however able to repro the leak in PNTriangles (June 2010 DX SDK).

            • DX11 DSSetConstantBuffers causing memory leak

              No, I haven't found a solution yet, apart from avoiding using DSSetConstantBuffers... Which I have been doing, up until now, since my current terrain implementation is now using tessellation. As you can imagine, the leak is becoming quite big (>5MB/sec), since I'm using 15 shadow projections, everything is multiplied by 15...

              The leak I have observed in the DX samples (PNTriangles, DetailTessellation11 etc) is hardly noticeable because of this - they are only calling DSSetConstantBuffers once per frame. I had to leave the samples running for a while before I observed a leak. Its much more noticeable with higher frame rates, ie with VSync off, when PNTriangles was running at 1500fps, the leak was noticeable in task manager (a few KB/sec). I did notice some "intermittence" in the leaking speed, but it seemed to be linked with the frame rate - PNTriangles occasionally drops down to 200-300fps, and the leak seems to temporarily go away, until it goes back to higher framerate. I'm not sure why the framerate temporarily drops like that (usually happens for a few sec at a time).

              Anyway, I suspect this is an ATI driver issue. Haven't tested with an nVidia card yet (I don't have one). What hardware are you experiencing this leak with?

                • DX11 DSSetConstantBuffers causing memory leak

                  Ok I can repro in PNTriangles11 now, I found that cranking the tessellation slider up to max and turning on screen space adaptive makes it occur more quickly.  Leave it running for 3 mins and it starts leaking ~128KB/sec.  Also when the leak starts happening the page faults go from 0 to ~30/sec according to ProcessExplorer.

                  My app also calls DSSetConstantBuffers multiple times per frame and so leaks memory faster.  The leak starts right away on launch and happens even though I am not actually drawing with tessellation, just calling DSSetConstantBuffers for a global buffer (in multiple passes per frame).

                  I am running on a Radeon HD 5870.  I tested my app on Nvidia GTX480 and it did not leak, same with the reference device.  So it definitely appears to be an ATI driver issue.