OpenGL ES 多线程和多屏渲染

原文：https://www.imgtec.com/blog/understanding-opengl-es-multi-thread-multi-window-rendering/
转载：https://blog.csdn.net/hanbingfengying/article/details/38782043

“内容归纳”
应用程序和驱动程序之间的传输完成之前，阻塞型操作有：
1、上传数据的图形API调用；
2、显卡驱动程序中着色器编译；

一、什么情况下使用：

多线程渲染最适合于编译着色器或上传数据至显卡驱动器时CPU资源有限的应用程序。原因有2:

• 主线程不会阻塞
  从根本上说，一直到应用程序和驱动程序内存之间的传输完成之前，上传数据的图形API调用一定会被阻塞。此外，在许多显卡驱动程序中着色器编译就是阻塞型操作。这种阻塞造成开销较大，导致GPU无法运行。将所有上传操作迁移至后台线程，主线程可以维持统一帧率
• 在多核CPU上进行并行任务分配
  由于图形驱动程序在CPU上运行，将这项运行分配至多个渲染线程，使得操作系统向多个CPU内核并行发布指令。这就导致与单个渲染线程相比，驱动程序的工作负载能够处理的更为迅速
  

二、什么情况不使用：

1、不受CPU资源限制或不涉及加载次数时，运行显卡驱动程序时，CPU资源足够。
2、视图“简化”渲染引擎时：
最糟的使用实例是不断将单一图形环境绑定至不同线程(使用eglmakeCurrent()) ，原因有2：

• The cost of context binding 上下文开销
  调用eglMakeCurrent()迫使驱动程序取消所有未完成的操作，应保持在最低限度以降低开销。
• API calls are serialized API调用串行化
  由于图形环境在任何时点只能绑定到一个CPU线程，所有API调用将被串行提交

因此，API调用与单线程渲染的开销一致（API调用提交呈串行化），但上行文转换时需要额外开销…也就是说与单线程渲染相比，性能会较差

知识点：

1、共享环境（共享context），一个或多个后台负载线程可访问主线程的资源。
2、后台线程的数量应保持在最低限度（如每个CPU内核一个线程） 。