glFence 的一些思考

1. EGL Context

   当我们的程序运行时，每一个方法的调用都是在 CPU 上的，OpenGL 也不例外，与普通调用的区别在于这些调用会被转换成 GPU 驱动指令在 GPU 上执行，而 CPU 和 GPU 作为两个不同的处理单元，它们之间的指令是并行执行的。在执行 gl 命令时会有一个队列用于暂存还未发送到 GPU 的命令，实际上我们调用的绝大多数 OpenGL 方法，只是在往命令队列中插入命令，在 CPU 中并不一定会等待命令执行完。

   OpenGL

   但并不是所有的线程都对应同一个命令队列，命令队列是和 EGL Context 对应的，而一个线程又只能同时绑定到一个 EGL Context。因此可以理解为命令队列是和绑定的 EGL Context 的线程对应的。在 OpenGL 中大部分对象都是可以共享的，但是跨线程的共享也会带来一些同步问题，比如两个线程对同一个纹理进行操作，thread0 在纹理上绘制，thread1 使用 thread0 提供的纹理，这时候如果 thread0 的线程没有渲染完，而 thread1 就开始使用，就会造成黑屏或者花屏的问题。

花屏原因

2. glFinish 和 glFlush

在 EGL 的 spec (3.7.3.2 Order of Rendering Operations Between Contexts) 的表述中，在多个 EGL Context 中，即便是同一个线程，EGL 也并不能保证渲染的顺序。

要解决这个问题有一个简单的方案是使用 glFinish(), glFinish() 是一个同步方法，运行时会等待该线程中所有的 GL 命令（包括所有改变 GL 状态的命令，所有改变连接状态的命令和所有改变 Frame buffer 内容的命令）都执行完，从而保证绘制的完整性。

glFInish

与 glFinish() 比较相近的还有一个 glFlush() 方法, 它的作用是将命令队列中的命令全部刷到GPU，但并不等它执行完成。

在实际使用中，各个厂家的GPU实现差异很大，但都要求符合openGL标准，glFlush可以异步实现，也可以同步实现，但glFinish必须同步实现，所以调用glFlush并返回时，只能说是渲染命令都下发了，但不能保证一定完成；而glFinish返回时是保证了命令已经执行完成的。

glFinish 虽然能保证命令的完整执行，但是会对性能有一定的影响，同时也只能保持在自己线程里的同步，有些厂商在实现中已经做了一些保证操作完整性的处理（比如高通部分 Soc），并不需要使用到 glFinish，过度的使用 glFinish 反而降低了渲染的效率，相比于 glFinish 在 OpenGL 3.0 中有了更好的方案 glFence。

3. glFence

GLFence 的原理是在同步过程中创建一个 Fence 同步对象并将 Fence 命令插入 GL 命令队列中，当 Fence 命令满足同步对象的指定条件时，GL 发出解除信号，解除由glWaitSync 或 glClientWaitSync命令造成的阻塞。同时，glFenceSync 或相关 Fence 命令的执行不会影响其他 GL 状态。

GLFence

glFence 中包含两个 Sync 命令 glWaitSync 和 glClientWaitSync，glWaitSync 是在 GPU 上等待，而 glClientWaitSync 是在 CPU 上等待，实际使用中只有 glClientWaitSync 起到了阻止闪屏的作用。

4. Fusion 中的处理
   在 Fusion 中对需要做同步的对象标记为 UnSync 状态并记录当前的 GL Context 对象，当需要做同步时当前 GL Context 和记录的 GL Context 对比，如果不同就调用 glClientWaitSync 方法，否则不调用。

参考

OpenGL ES命令队列及glFinish/glFlush
OpenGL ES 高级进阶：fence同步