Professional ways of tracking GPU memory leakage
Posted by Hemprasad Y. Badgujar on January 25, 2015
- CodeXL from AMD: http://developer.amd.com/tools-and-sdks/heterogeneous-computing/codexl/
- Nvidia NSight: https://developer.nvidia.com/gameworks-tools-overview
- Nvidia Visual Profiler: https://developer.nvidia.com/nvidia-visual-profiler
- gDebugger: http://www.gremedy.com/
Depending on what I am doing and what I need to track/trace and profile I utilise all 4 packages above. They also have the added benefit of being a: free; b: well maintained; c: free; d: regularly updated; e: free.
In case you hadn’t guessed I like the free part:)
In regards of object management, I would recommend an old C++ coding principle: as soon as you create an object, add the line that deletes it, every new should always (eventually) have a delete. That way you know that you are destroying the objects you create, however it will not save you from orphaned memory block memory leaks, where you change where pointers are pointing, for example:
myclass* firstInstance = new myclass(); myclass* secondInstance = new myclass(); firstInstance = secondInstance; delete firstInstance; delete secondInstance;
You will now have created a small memory leak where the data for the real firstInstance is now not being pointed at by any pointer. Very hard to detect when this happens in a large code-base, and more common that it should be.
generally these are the pairings you need to be aware of to ensure you properly dispose of all your objects:
new -> delete new -> delete malloc() -> free() // or you can use realloc(0) instead of free() calloc() -> free() // or you can use realloc(0) instead of free() realloc(nonzero) -> free() // or you can use realloc(0) instead of free()
If you are coming from a language with garbage collection to C++ it can take a while to get used to, but it quickly becomes habit:)