glDeleteTextures does not seem to free up texture memory on Windows, is there no solution?

Question

I have been having some problems with my openGL application running out of memory and I am trying to track down my problem. To this end, I created a small test program that bas

Answer 1

Also, since your error has the GLU prefix, could you try running the same program without building mipmaps?[already done] I don't think GLU_OUT_OF_MEMORY necessarily means that you are out of GPU memory (in fact the mipmaps are probably built on the CPU), so maybe you are suffering from Heap fragmentation. The fact that you get the error on different Windows machines with very different GPUs seems to indicate that it's not a specific OpenGL driver problem; they are too different across vendors.

Since you are using a large texture, and if not using gluBuild2DMipmaps doesn't solve the problem, you could pre-allocate the GPU memory for your large texture(s) once when your app starts and reuse the texture objects with glTexSubImage instead of creating new ones on reload.

edit: the following does not provide a solution (see question comments), but is still useful in my opinion

Since you get GLU_OUT_OF_MEMORY and not GL_OUT_OF_MEMORYI assume the problem occurs during mipmap creation with gluBuild2DMipmaps. Since maybe the glu function is at fault, perhaps you could try building your mipmaps in an offline process and then simply load them in Create-texture-from-file. Besides potentially solving your out of memory error, this would let you have much better control over the actual mipmap generation. You could for example use a gaussian filter instead of a box filter. It would also ensure identical mipmap content across platforms. My understanding is that this is how mipmaps are usually handled.

Answer 2

I think you could try to push an empty image to the texture you want to delete by using glTexImage2d/3d. It worked for me with VBO's - I get rid of the data from the graphic cards by removing a buffer data using glBufferData and passing an empty array handle, because the glDeleteBuffers didn't removed the data by itself.

Answer 3

Windows OpenGL drivers are designed on the assumption that your code will actually draw stuff at some point. Because of that, they tend to avoid doing things exactly when you ask them to be done, deferring them to a more convenient time. And that's what you're running into here.

Just because you tell OpenGL that you're done with a texture object doesn't mean that OpenGL must immediately relinquish that memory. Doing that generally requires some pretty heavy-weight operations. So instead, drivers will defer this until later.

The problem is that "later" is usually defined as some form of glDraw* command, glEnd, glFlush/Finish, or a swap buffer command. Or something of that nature. If all you do is sit in a loop and create/delete textures, the driver may not get the chance to actually delete anything.

Try making your test less artificial. Add a glFinish after each glDeleteTextures. If that doesn't work, draw stuff between deletions.

Ultimately, you cannot force drivers to do what you want. All you can do is make your test application behave more like a normal application.