2

The tutorial that i'm taking for direct3d says this:

"... Basically, if you create Direct3D, but never close it, it will just keep on running in the background of the computer until your next reboot, even after the program itself closes. Bad. Especially bad if you have a lot of resources in your game. Releasing these two interfaces let's everything off the hook and allows Windows to take back it's memory." (link)

I really don't believe what this tutorial says, that the resources will still hang about after you exit the process...

Like if my program crashes or i simply press stop while debugging.. are the resources still hanging around? And other games which use directx, i often close them by killing the process.

Will the resources be free to the operating system if i exit my process and don't call device->Release?

Kaije
  • 2,631
  • 6
  • 38
  • 40

2 Answers2

4

Simply put, no. That is not true. When your process terminates, all your DirectX resources will be freed and no GPU or system memory will be leaked.

Alan
  • 4,897
  • 2
  • 24
  • 17
1

While it's true that process-related resources, such as memory, threads, handles, etc. will be reclaimed, recall that D3D is also utilizing memory and resources on the video hardware. Depending on your specific implementation, failing to inform D3D that you are shutting down can and will not clean all of these up on a process exit.

I have seen some very interesting rendering artifacts occur in software using the Managed DX9 interface that failed to clean up until the EvictManagedResources call was made. These artifacts occurred in an automated test suite, and yes - they persisted between separate invocations of the same process (as small rectangles of garbage on the display/framebuffer).

A properly coded app can still react appropriately to internal exceptions and/or process termination request (WM_QUERYENDSESSION, etc.) and perform this cleanup.

holtavolt
  • 4,378
  • 1
  • 26
  • 40
  • There is a difference between cleaning up memory (zeroing) and just deallocating it for further use. I doubt that the latter isn't done when the process exits. But yes, things written into video memory persist over application invokations, but the fact that these things are then located in the video memory of the next application show, that this memory is reallocated to the new application and therefore no memory is leaked. – Christian Rau May 26 '11 at 16:13
  • "cleaning up" != "zeroing memory" as far as I'm concerned. You are correct that process system memory is deallocated, but video device resources (memory) are not, depending on your [D3DPOOL usage]http://msdn.microsoft.com/en-us/library/bb172584(v=vs.85).aspx - the device-portion of this memory is not associated with the application (and the D3DPOOL_MANAGED was being used in my case). I'll also point out that the artifacts were visible on the desktop after the first test application iteration, and before the next iteration started (they persisted), until the EvictManagedResources was added – holtavolt May 26 '11 at 17:49
  • Regardless of the pool you allocate your D3D resources in, they will be automatically deallocated and returned to the driver when you application terminates, even if it crashes. They won't be zero'ed out or overwritten, so use of newly allocated but uninitialized buffers in a second process may still show a distored version of the old contents. But that can be the case even if you manually Release every resource pointer in the first process before exiting. – Alan May 27 '11 at 15:07
  • Again, the display artifacts I observed were persistent after the first had terminated, and stayed present throughout the run of the subsequent invocations, so clearly the app had corrupted "driver memory" outside of the scope of the app, until I added the explicit EvictManagedResources call. That said, I've read some more of the guidelines [http://msdn.microsoft.com/en-us/library/ee418784(v=vs.85).aspx] and see that EvictManagedResources should not be necessary on exit. Likely the corruption was occuring elsewhere, or this was a bug only in Managed DirectX 9. – holtavolt May 27 '11 at 17:05