<p>Assuming your code has several locations that can allocate/release GPU memory, but you don't know which one leaks.
Maybe you can try to add a GPU memory monitor to that code. </p>

<p>When GPU memory is allocated in code, insert the buffer handle that was returned, the buffer size, the function/file name (or even better, stack trace) in a globally defined array.
When GPU memory is released, remove the handle of the buffer that was released from that array.
Run the application a while and exit before it crashes. Output the contents of the array before leaving. It shows information about the GPU memory that was not released. You might see some patterns leading you to understand how to fix the "leak".</p>

CC BY-SA 3.0
2017-03-24T20:18:33.017Z
The problem is that there are hundreds of OpenGL calls in my codebase. Is there a list of OpenGL calls which have as side effect the allocation/deallocation of memory?
George
CC BY-SA 3.0
2017-03-24T20:23:58.273Z
Regarding my prior comment, I'm assuming `glBindBuffer` is the key function call to look out for?
George
CC BY-SA 3.0
2017-03-25T13:26:07.680Z
It depends on which flavor of OpenGL your program uses, I would suggest to monitor `glGenBuffers` / `glDeleteBuffers`, (see the OpenGL wiki's [Buffer Object page](https://www.khronos.org/opengl/wiki/Buffer_Object) ). Also `glCreateProgram` /  `glDeleteProgram`, `glGenSamplers` / `glDeleteSamplers`, etc
wip
CC BY-SA 3.0
2017-03-25T13:28:34.017Z
In my code, there are 20 calls to `glGenBuffers`, and only one call to `glDeleteBuffers`. Does that automatically identify a problem, in that these calls should be 1 for 1 with each other?
George
CC BY-SA 3.0
2017-03-25T13:32:52.043Z
No, it is not necessary a problem, you have to check the handles of the objects generated versus deleted, and see if they match.
wip
CC BY-SA 3.0
2017-03-25T13:36:35.343Z
A good-practice for multi-platform graphics application (rendering engines, etc) is to wrap the graphics API specific functions under a generic layer (for example, your program has a structure/class `MyAppBuffer` from which are derived `MyAppOpenGLBuffer`, `MyAppDirectXBuffer`, etc. It has the benefit of having all the graphics API functions in a single place, making it easier to monitor. You could try to refactor your code in a similar way.
wip
CC BY-SA 3.0
2017-03-23T17:11:24.093Z
2017-03-23T17:11:24.093Z
wip
<ol>
<li><p>Probably not. Most OpenGL resources (framebuffers, vertex buffer objects, textures &amp;c.) are controlled by host code (i.e. your C++ code), but take up GPU memory. OpenGL doesn't make it very easy to manage these resources, so it's most likely that they're being created but not deleted from your C++ code. For example, it might create a new VBO per frame but never delete the old VBOs.</p></li>
<li><p>I've never used it for this purpose, but if you're on Windows I'd suggest RenderDoc as your first stop. It's not specifically designed for debugging source - it intercepts GL and DX calls so you can see how the application is using the library even if you don't have the source - so it won't point you to the offending line of code, but it does show you what resources are being created and when, so it should at least tell you <em>what</em> is being leaked and how often. It might even be that this is enough information is enough for you to guess the rest, or that the easiest way to continue after this is to do something by hand (e.g. printing <code>__FILE__</code> and <code>__LINE__</code> every time such a resource is created).</p></li>
</ol>

<p>Sorry this is a bit of a half-answer but it's too big for a comment. I hope it gives you a good starting point at least.</p>

CC BY-SA 3.0
2017-03-21T13:07:06.040Z
With you can also insert debug messages into the opengl stream with push/pop debug group to get some context. The opengl objects created can also be named with glObjectLabel.
ratchet freak
CC BY-SA 3.0
2017-03-20T20:10:09.437Z
2017-03-20T20:10:09.437Z
Dan Hulme
<p><strong>Problem.</strong> I have inherited a large C++ 3D graphics codebase (with some shader code). The program runs for about 1-5 minutes before crashing. </p>

<p><strong>Problem Data.</strong> Using system tools, one can see a sharp rise in VRAM memory usage after the program launches, which eclipses into a crash. The same is true for GTT memory usage also (although the spike isn't quite as dramatic as with the VRAM).</p>

<p><strong>Questions.</strong></p>

<ol>
<li><p>Does this (probably) mean that there is a memory leak in OpenGL shader code somewhere (as opposed to a leak in regular C++ code)?</p></li>
<li><p>Are there well-known tools for tracking down vram/gtt memory leaks (similar to the way that valgrind can be used to track down system memory usage)?</p></li>
</ol>

<memory><debugging>
How can I chase down VRAM & GTT memory leaks?
George
# How can I chase down VRAM & GTT memory leaks?

(Asked by: username_0 on 2017-03-20)

**Problem.** I have inherited a large C++ 3D graphics codebase (with some shader code). The program runs for about 1-5 minutes before crashing.

**Problem Data.** Using system tools, one can see a sharp rise in VRAM memory usage after the program launches, which eclipses into a crash. The same is true for GTT memory usage also (although the spike isn't quite as dramatic as with the VRAM).

**Questions.**

1. Does this (probably) mean that there is a memory leak in OpenGL shader code somewhere (as opposed to a leak in regular C++ code)?
2. Are there well-known tools for tracking down vram/gtt memory leaks (similar to the way that valgrind can be used to track down system memory usage)?

**Tags:** memory, debugging


---

## 2 answers

### Answer by username_1 on 2017-03-23. Score: 3

Assuming your code has several locations that can allocate/release GPU memory, but you don't know which one leaks.
Maybe you can try to add a GPU memory monitor to that code.

When GPU memory is allocated in code, insert the buffer handle that was returned, the buffer size, the function/file name (or even better, stack trace) in a globally defined array.
When GPU memory is released, remove the handle of the buffer that was released from that array.
Run the application a while and exit before it crashes. Output the contents of the array before leaving. It shows information about the GPU memory that was not released. You might see some patterns leading you to understand how to fix the "leak".

> **Comments:**
> **username_0**: The problem is that there are hundreds of OpenGL calls in my codebase. Is there a list of OpenGL calls which have as side effect the allocation/deallocation of memory?  
> **username_0**: Regarding my prior comment, I'm assuming `glBindBuffer` is the key function call to look out for?  
> **username_1**: It depends on which flavor of OpenGL your program uses, I would suggest to monitor `glGenBuffers` / `glDeleteBuffers`, (see the OpenGL wiki's [Buffer Object page](https://www.khronos.org/opengl/wiki/Buffer_Object) ). Also `glCreateProgram` /  `glDeleteProgram`, `glGenSamplers` / `glDeleteSamplers`, etc  
> **username_0**: In my code, there are 20 calls to `glGenBuffers`, and only one call to `glDeleteBuffers`. Does that automatically identify a problem, in that these calls should be 1 for 1 with each other?  
> **username_1**: No, it is not necessary a problem, you have to check the handles of the objects generated versus deleted, and see if they match.  
> **username_1**: A good-practice for multi-platform graphics application (rendering engines, etc) is to wrap the graphics API specific functions under a generic layer (for example, your program has a structure/class `MyAppBuffer` from which are derived `MyAppOpenGLBuffer`, `MyAppDirectXBuffer`, etc. It has the benefit of having all the graphics API functions in a single place, making it easier to monitor. You could try to refactor your code in a similar way.  

---

### Answer by username_2 on 2017-03-20. Score: 3

1. Probably not. Most OpenGL resources (framebuffers, vertex buffer objects, textures &c.) are controlled by host code (i.e. your C++ code), but take up GPU memory. OpenGL doesn't make it very easy to manage these resources, so it's most likely that they're being created but not deleted from your C++ code. For example, it might create a new VBO per frame but never delete the old VBOs.
2. I've never used it for this purpose, but if you're on Windows I'd suggest RenderDoc as your first stop. It's not specifically designed for debugging source - it intercepts GL and DX calls so you can see how the application is using the library even if you don't have the source - so it won't point you to the offending line of code, but it does show you what resources are being created and when, so it should at least tell you *what* is being leaked and how often. It might even be that this is enough information is enough for you to guess the rest, or that the easiest way to continue after this is to do something by hand (e.g. printing `__FILE__` and `__LINE__` every time such a resource is created).

Sorry this is a bit of a half-answer but it's too big for a comment. I hope it gives you a good starting point at least.

> **Comments:**
> **username_3**: With you can also insert debug messages into the opengl stream with push/pop debug group to get some context. The opengl objects created can also be named with glObjectLabel.  

---

