Strange OpenGL Memory Leak

Nobody has got the problem ?

Well, if it's the case then I suppose I will have to let this post be lost within the huge list of gamedev's posts...

Most programs typically do call glClear() once per frame, to at least clear the color buffer, so I guess it is remotely possible that the driver is using the glClear() call to free resources, but really that should happen on SwapBuffers() or at any rate on glFlush().

Try emailing NVidia about it, they should have a better idea than anyone why this happens.

No, I tried it with a 50k polygon model, but didn't see any growth in the memory allocated to the application. I turned off depth testing and back face culling as well as not clearing the screen. I would say it is either specific to features you are using in the application or the driver for the card. If the program doesn't do it on an nVidia card then figure it is the driver. If it does the same thing there then figure it is some specific feature of the API you are using.

PS: Oops, thought you were running on a ATI card. I believe the Quadro drivers are differant than for the 6200 I'm using so while you are using a nVida driver already you might try it with a 6200, 6600, 6800 or 7800.

try running with glintercept
and a mem leak detector eg search for mmgr from paul nettle

I set this up with my basecode a while back, and it has been a godsend for keeping tabs on memory leaks.

http://www.flipcode.com/cgi-bin/fcarticles.cgi?show=63785

Hi !

Thanks for your remarks and suggestions.

There is only a small chance that the memory leak comes from my code because two people (me included) checked it thouroughly and we didn't find anything. So, I guess I will have to write to NVidia. I think I will also try glIntercept too.

Anyway, thanks all.

Are you using multiple threads or rendering contexts?

Hi everybody.

I indeed use multiple threads in the application but only one of them is using/calling OpenGL functions. The cause of the problem shouldn't come from multithreading.

A for new/delete pairs, every line of code regarding OpenGL has been examined and nothing was found. The previous version of the program hadn't the problem and I diff'ed the two sources and, again, no problematic code has been found.

I insist that the problem disappears as soon as I put a glClear() call on every frame (which shouldn't be needed as I'm rendering on the whole screen).

Anyway, thanks for your suggestions.

I cannot reproduce this behaviour, neither on a GF4, 7800, Radeon X800, or Radeon Mobility 9700.

Of course a driver will allocate memory if you successively call IM commands without flushing the pipeline. They have to be cached somewhere, until they get pushed into the GPU command queue and processed. But this memory is either released, or recycled at some later point, not necessarily on swap buffers. Sometimes the grown queue can be kept at the new size, and will shrink at some later point because the driver expects the same large amount of data over the next frames. This avoids constant reallocation of memory at each frame.

Memory allocation policies are not specified by the standard, and are left at the discretion of the driver implementor. It is extremely unlikely that such a memory leak occurs on both an nvidia and ATI driver, at the exact same spot (unless NV or ATI have some serious case of corporate espionnage and source leaking going on ;). So there is a very large chance that your code is at fault.

Now, in a modern engine, it is pretty much expected that you call glClear each frame. It is not an optimization to avoid calling it, even if you draw over the entire frame ! In fact, not calling it can and will slow you down on modern GPUs. glClear does a lot more than simply clearing the framebuffers. It will also reset internal pixel occlusion and early z rejection structures, internal caches, can clear padded depth/stencil buffer very efficiently, etc. You should most definitely call it once per frame, even if just for performance reasons.

Now, if you are 100% positive that this memory leak is a driver issue, then try to write a short and basic code snippet that can reliably reproduce this behaviour. Post it here. If the effect can be reproduced by several people, then it is in fact a bug that can be submitted to NV or ATI. If not, it is probably your code.

Oh btw, there is a well known memory leak on ATI hardware if using several contexts. But this is not an issue on nvidia.