glDrawElements allocating memory and not releasing it

Question

Using OpenGLES 1.1 on the iPhone 3G (device, not simulator), I do normal drawing fun. But at points during the run of the application I get giant memory spikes, after a lot of digging with instruments I have found that it is glDrawElements that is grabbing the memory.

The buffer being allocated is 4 meg, which to me means its loading a texture into RAM, which I guess could be valid, but its never releasing this buffer, and is allocating multiple of them.

How do I make sure that these buffers that GL is creating get destroyed, instead of just hanging around?

Answer 1

Check to see if this is on the simulator or the iPhone device itself. Instruments/Leaks can and will report false positives on the simulator, which you will not encounter on the device.

Answer 2

This doesn't sound like a leak, more like a driver optimization where the GPU holds on to a memory block (vertexbuffer, texture, whatever) in case it's needed again. If you run your application for some time does it keep allocating more and more memory until the device eventually run out of memory?

It's an unfortunate fact the the first generation of iPhone 3G doesn't have proper support for vertex buffer objects (VBO), they are exposed by the API but they work in exactly the same way as ordinary software vertex buffers. This means that whenever you call glDrawElements whatever vertex buffers you've set with glVertexPointer etc will be copied from system memory to the GPU.

The only way you can "leak" memory to OpenGL is by repeatedly allocate various buffer objects (texture objects, vertex buffer objects, frame buffer objects etc.) and not releasing them, like doing this every frame:

GLuint id;  
glGenTextures(1, &id);
glBindTexture(GL_TEXTURE_2D, id);        
glTexImage2D(...);

you'll eventually run out of memory. I'm using glDrawElements on the iPhone 3G myself and I'm not seeing this problem, can you give a small repro code sample?

Answer 3

I figured this out with the help of some people on IRC. The issue ended up being the way I was doing threading in my app. By moving GL and the game update loop to the same thread, the issue disappeared, I have no idea WHY the other way caused the memory allocations it did, but the issue is resolved.