Android平台OpenGL帧缓冲纹理内存释放异常问题咨询

Problem Context #

I'm running memory tests for OpenGL framebuffer textures on Android, but after executing the release code, some textures aren't fully cleaned up. Here's my test code:

Initialization Code #

// Initialize framebuffer texture test code
glGenTextures(20, texs);
for (uint32_t i = 0; i < 20; ++i) {
    glBindTexture(GL_TEXTURE_2D, texs[i]);
    glTexImage2D(GL_TEXTURE_2D, GL_RGBA, 0, 1024, 1024, 0, GL_RGBA, GL_UNSIGNED_BYTE, nullptr);
    glBindTexture(GL_TEXTURE_2D, 0);
    glBindFrameBuffer(GL_FRAMEBUFFER, fbo);
    glFrameBufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, texs[i], 0);
    glViewport(0,0,1024,1024);
    glClear(GL_COLOR_BUFFER_BIT);
    glBindFrameBuffer(GL_FRAMEBUFFER, 0);
}

Release Code #

// Release framebuffer texture test code
glBindFrameBuffer(GL_FRAMEBUFFER, fbo);
glFrameBufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, 0, 0);
glBindFrameBuffer(GL_FRAMEBUFFER, 0);
for (uint32_t i = 0; i < 20; ++i) {
    glDeleteTexture(1, &texs[i]);
}

Questions & Answers #

Q1: Is this driver behavior? #

It could partially relate to driver behavior, but first let's address a critical code issue that's most likely the root cause.

OpenGL commands are asynchronous—when you issue a deletion call, the driver might queue it instead of executing it immediately. Some Android GPU drivers (e.g., Qualcomm, MediaTek, Kirin) also use deferred memory recycling: they may keep unused texture memory in a pool for quick reuse instead of releasing it back to the system right away. This can create the illusion of lingering textures if you check memory usage immediately after deletion.

That said, your code has a typo that's almost certainly preventing proper deletion (covered in Q2), which is a bigger factor than driver behavior here.

Q2: Is there a way to delete all textures? #

Yes—fix the code bug and follow these best practices to ensure full cleanup:

1. Fix the deletion function typo
   You used glDeleteTexture (singular), but the standard OpenGL API function is glDeleteTextures (plural). The singular version isn't valid, so your current code isn't actually deleting any textures. Correct the release logic:

   // Option 1: Delete all textures in one call (more efficient)
   glDeleteTextures(20, texs);
   
   // Option 2: Fixed loop version
   for (uint32_t i = 0; i < 20; ++i) {
       glDeleteTextures(1, &texs[i]);
   }
   

2. Ensure no active bindings/attachments
   While your code unbinds the FBO's color attachment, it's good practice to unbind textures from texture units before deletion (though technically, glDeleteTextures will mark bound textures for deletion, which takes effect once unbound):

   for (uint32_t i = 0; i < 20; ++i) {
       glBindTexture(GL_TEXTURE_2D, texs[i]);
       glBindTexture(GL_TEXTURE_2D, 0);
       glDeleteTextures(1, &texs[i]);
   }
   

3. Force driver to flush pending commands
   To ensure the driver executes all deletion operations immediately, call glFinish() after deleting textures. This waits for all pending OpenGL tasks to complete, ensuring the driver frees the texture memory:

   glDeleteTextures(20, texs);
   glFinish();
   

4. Check for lingering references
   Double-check that no other parts of your code are holding onto these texture IDs (e.g., global variables, other data structures). If a texture ID is reused or referenced elsewhere, it might appear as though the texture wasn't deleted.

After fixing the typo and following these steps, all textures should be properly deleted. Any temporary memory lingering after that is likely due to the driver's deferred recycling pool, which will be released when the GPU needs more memory or is idle.

内容的提问来源于stack exchange，提问作者LaChen