Slogging through the list of OpenGL API usage performance warnings given by the Analyze instrument, I am finding that we are generating several logical buffer loads per frame - places where we are not clearing a buffer because a draw call completely overwrites it.
Counterintuitively, introducing glClear() calls for these cases simply moves the location of the warning to the glClear() calls. Apple implement GL_EXT_discard_framebuffer, however using this on its own is also not sufficient to stop the warning. A glDiscardFramebufferEXT() followed by a glClear() does stop the warning, and improves performance significantly, but the glClear() call itself takes time to clear the buffer, which in our use case is a redundant operation.
Do others also find they need to call both functions to avoid the reload cost or am I missing something? Is there a cheap way of hinting to OpenGL that the contents of the framebuffer is about to be completely overwritten and so does not need to be reloaded into tile memory?
The documentation implies that a fullscreen glClear() sets some magical flag, which is consistent with what I've seen while debugging the same issue. I wouldn't worry about doing a redundant glClear(), as this is the intended usage pattern from what I can tell.
Update: You may also be experiencing the same bug I had, where I was clearing the colour and depth buffers, but forgot to set glDepthMask(GL_TRUE) before calling glClear(). This resulted in a Logical Buffer Load warning.
来源：https://stackoverflow.com/questions/5470822/ios-opengl-es-logical-buffer-loads