[关闭]
@SR1s 2017-02-09T09:38:18.000000Z 字数 3525 阅读 780

谈谈eglMakeCurrent、eglSwapBuffers、glFlush和glFinish

OpenGLES EGL


接触OpenGL ES 2.0有一段时间了,分享一些理解。

eglMakeCurrent

记得这个调用吗?方法原型是:

  1. EGLBoolean eglMakeCurrent(
  2. EGLDisplay display,
  3. EGLSurface draw,
  4. EGLSurface read,
  5. EGLContext context
  6. );

为了弄懂这个方法,我们需要搞清楚DisplaySurfaceContext这几个概念。

Display

在使用EGL 的过程中,会发现EGL 相关的调用都经常需要我们传入一个类型为Display的参数。
顾名思义,Display是一个连接,用于连接设备上的底层窗口系统。

所以在调用EGL 方法之前,需要先创建、初始化这个Display连接。步骤如下:

  1. EGLint majorVersion;
  2. EGLint minorVersion;
  3. EGLDisplay display;
  4. display = eglGetDisplay(EGL_DEFAULT_DISPLAY);
  5. if (display == EGL_NO_DISPLAY) {
  6. // 无法打开到底层窗口系统的连接
  7. }
  8. if (!eglInitialize(display, &majorVersion, &minorVersion)) {
  9. // 无法初始化EGL
  10. }

通常情况下传入EGL_DEFAULT_DISPLAY作为eglGetDisplay的参数就可以了,EGL 会自动返回默认的Display

Context

Context不是什么神秘的东西,它仅仅是一个容器,里面放着两个东西:

总的来说,Context是设计来存储渲染相关的输入数据。

Surface

对应的Surface则是设计来存储渲染相关的输出数据。Surface实际上是一个对底层窗口对象的拓展、或是一个有着额外辅助缓冲的像素映射(pixmap)。这些辅助缓存包括颜色缓存(color buffer)、深度缓冲(depth buffer)、模板缓冲(stencil buffer)。

再回到 eglMakeCurrent

那么eglMakeCurrent到底做了什么?当发起GL 调用指令(如:glDrawElements)的时候,这个调用会影响到哪个ContextSurface呢?答案就在eglMakeCurrent里。

  1. EGLBoolean eglMakeCurrent(
  2. EGLDisplay display,
  3. EGLSurface draw,
  4. EGLSurface read,
  5. EGLContext context
  6. );

eglMakeCurrentcontext绑定到当前的渲染线程以及drawread指定的Surface。draw用于除数据回读(glReadPixelsglCopyTexImage2DglCopyTexSubImage2D)之外的所有GL 操作。回读操作作用于read指定的Surface上的帧缓冲(frame buffer)。

因此,当我们在线程T上调用GL 指令,OpenGL ES 会查询T线程绑定是哪个Context C,进而查询是哪个Surface draw和哪个Surface read绑定到了这个Context C上。

多个Context

某些情况下,我们想创建、使用多个Context,对于这种情况,需要注意以下几个情况:

共享Context

共享Context这种方式在加载阶段很有用。由于上传数据到GPU(尤其是纹理数据(textures))这类操作很重,如果想要维持帧率稳定,应该在另一个线程进行上传。

然而,出于上述3种情况的限制,必须在第一个Context之外,创建第二个Context,这个Context将使用第一个Context使用的内部状态信息。这两个Context即共享Context。

需要注意的是:这两个Context共享的只是内部状态信息,它们两个并不共享调用缓存(每个Context各自拥有一个调用缓存)。

创建第二个Context的方法:

  1. EGLContext eglCreateContext(
  2. EGLDisplay display,
  3. EGLConfig config,
  4. EGLContext share_context,
  5. EGLint const * attrib_list);

第三个参数share_context是最重要的,它就是第一个Context。

在第二个线程,不进行任何的绘制,只进行上传数据到GPU 的操作。所以,给第二个Context 的Surface 应该是一个像素缓冲(pixel buffer)Surface。

  1. EGLSurface eglCreatePbufferSurface(
  2. EGLDisplay display,
  3. EGLConfig config,
  4. EGLint const * attrib_list);

eglSwapBuffers

  1. EGLBoolean eglSwapBuffers(
  2. EGLDisplay display,
  3. EGLSurface surface);

第一次看到这个调用的时候,我以为它的作用是对displaysurface进行交换:) 槑

实际上,这里需要重点注意的是surface。如果这里的`surface
是一个像素缓冲(pixel buffer)Surface,那什么都不会发生,调用将正确的返回,不报任何错误。

但如果surface是一个双重缓冲surface(大多数情况),这个方法将会交换surface内部的前端缓冲(front-buffer)和后端缓冲(back-surface)。后端缓冲用于存储渲染结果,前端缓冲则用于底层窗口系统,底层窗口系统将缓冲中的颜色信息显示到设备上。

glFlush 和 glFinish

OpenGL ES 驱动和GPU以并行/异步的机制运行。发起GL 调用时,为了得到最好的性能,驱动会尝试尽快地把调用指令发送给GPU。但GPU 并不会马上执行这些指令,这些指令只是添加到了GPU的指令队列里等待GPU 执行。如果在短时间内发送大量的GL 指令给GPU,GPU的指令队列可能满了,以至于驱动需要把这些指令保存在Context的调用缓存里(即上文里提到的Context内的调用缓存)。

那么问题来了,这些等待中的指令何时会发送给GPU呢?通常来说,大多数OpenGL ES驱动的实现可能会在发起新的(下一个)GL 指令发起的时候发送这些指令。如果想要主动执行这个操作,那就调用glFlush。这个操作将会阻塞当前线程,直到所有的指令都发送给了GPUglFinish这个命令更加强大,它会阻塞当前线程,直到所有的指令都发送给了GPU,并执行完毕。需要注意的是,应用程序的性能会因此下降。

glFlushglFinish被称为显式同步操作。某些情况下也会发生隐式同步操作。调用eglSwapBuffers时,就可能发生这种情况。由于这个操作是由驱动直接执行的,此时GPU 可能把所有待执行的glDraw*绘制指令,作用在一个不符合预期的surface 缓冲上(如果之前前端缓冲和后端缓冲已经交换过了)。为了防止这种情形,在交换缓冲前,驱动必须阻塞当前线程,等待所有的影响当前surface的glDraw*指令执行完毕。

当然,使用双重缓冲的surfaces时,不需要主动调用glFlushglFinish:因为eglSwapBuffers进行了隐式同步操作。但在使用单缓冲surfaces(如上文提到的第二个线程里)的情况,需要及时调用glFlush,例如:在线程退出前,必须调用glFlush,否则,GL 指令可能从未发送到GPU。

End

好了,就说到这吧,glFinish :)

原文链接:Let’s talk about eglMakeCurrent, eglSwapBuffers, glFlush, glFinish

译文链接:谈谈eglMakeCurrent、eglSwapBuffers、glFlush和glFinish

备份译文链接:谈谈eglMakeCurrent、eglSwapBuffers、glFlush和glFinish

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注