I have a Java OpenGL application - backed by JOGL, running on Linux slitaz 3.2.53-slitaz #4 SMP Europe 2014 i686 GNU/Linux.
OpenGL details:
When running loading & deleting textures on the GPU, it crashes after a certain amount of time - proportional to the frequency of loads & unloads, more loads crash sooner etc.
The error given: intel_do_flush_locked failed: No space left on device
In this case I'm:
After searching around, I've found sources suggesting that glDeleteTextures doesn't guarantee the free-ing of the VRAM used by the texture, just the ID returned by glGenTextures so it can be reused. For example: https://gamedev.stackexchange.com/questions/63629/how-to-deallocate-release-delete-of-a-gltexstorage2d
But I've also found articles reporting potential/bugs in the Mesa driver & versions of Lunix that report the same exception: intel_do_flush_locked failed: No space left on device
In conclusion I'm asking:
The problem was indeed as Reto Koradi suggested in the comments via his answer to OpenGL es 1.1 - android - does gl.glDeleteTextures free video memory? whereby not detaching textures & render buffers from frame buffers before deletion was keeping them in memory.
To anyone else who is creating off screen frame buffers with textures &/or render buffers, make sure you detach them first! E.g:
glBindFramebuffer( GL2ES2.GL_FRAMEBUFFER, theFrameBufferID);
glFramebufferTexture2D( GL2ES2.GL_FRAMEBUFFER, GL2ES2.GL_COLOR_ATTACHMENT0, GL2ES2.GL_TEXTURE_2D, 0, 0);
glFramebufferRenderbuffer( GL2ES2.GL_FRAMEBUFFER, GL2ES2.GL_STENCIL_ATTACHMENT, GL2ES2.GL_RENDERBUFFER, 0);
glDeleteFramebuffers.. theFrameBufferID..
glDeleteTextures..
glDeleteRenderbuffers..
glBindFramebuffer( GL2ES2.GL_FRAMEBUFFER, 0);