[工作积累] OpenGL ES3.0: glInvalidateFramebuffer

https://www.khronos.org/opengles/sdk/docs/man3/html/glInvalidateFramebuffer.xhtml

这个在GLES2.0上只有Extension:

https://www.khronos.org/registry/gles/extensions/EXT/EXT_discard_framebuffer.txt

原理跟D3D9 的Present参数(D3DSWAPEFFECT_DISCARD)类似:

http://msdn.microsoft.com/en-us/library/windows/desktop/bb172612(v=vs.85).aspx

 

理论上, 每一帧的绘制都可以基于之前帧的绘制内容叠加, 所以需要保持之前backbuffer内容的有效性, 但是实时游戏中每一帧之间一般不这么做.

如果原有的backbuffer在swap之后内容不再有效, 这样可以避免GPU直接操作的frame buffer cache(fast memory)再重新写回video memory. 而且从下一次绘制开始, GPU也不关心原有backbuffer的内容, 不用再把backbuffer的内容load到frame buffer cache中. 这也是为什么要求video memory内的backbuffer数据必须是无效的.

 

这样可以节省带宽, 提高效率, 同时可能节省video memory开销.

这里的video memory不一定是显卡内的物理显存. 对于现代移动设备, 大部分是GPU和CPU共享的物理内存, 类似XBOX和PS4的Unified Memory Access.

然而OpenGL/ES的架构上只能是先准备用户内存, 然后"upload"给API, 实际上是从user space memory到driver(kernel) space memory的copy.

 

需要注意的是,这个函数只是对具体GL ES实现的hint, 所以我姑且认为它是implementation defined behavior:

The intention of this function is to provide a hint to the GL implementation that there is no longer a need to preserve the contents of particular attachments of a framebuffer object, or the default framebuffer.

这意味着某些厂商的内部实现, 可能对这一情况无法做任何实际优化. 当然实际上可能所有厂商都可以做优化, 只不过GLES3的标准不保证. 对于我们用户, 还是要使用的好, 即便某些时候没效果.

 

另外当FBO为默认FBO时, 输入的参数是不一样的:

If a framebuffer object is bound, then attachments may contain GL_COLOR_ATTACHMENTi, GL_DEPTH_ATTACHMENT, GL_STENCIL_ATTACHMENT, and/or GL_DEPTH_STENCIL_ATTACHMENT. If the framebuffer object is not complete, glInvalidateFramebuffer may be ignored.

If the default framebuffer is bound, then attachments may contain GL_COLOR, identifying the color buffer; GL_DEPTH, identifying the depth buffer; and/or GL_STENCIL, identifying the stencil buffer.