我正在编写一些具有网格视图的代码（一次在屏幕上显示大约20个子视图）。每个子视图都在GL中绘制其内容，并有自己的绘制线程和EAGLContext。
这样做的好处是，每个视图与应用程序中的其他GL使用相对隔离，尽管屏幕上有20个这样的视图，我们必须glFlush+setCurrentContext:每帧20次。我的直觉告诉我这不是GL的最有效使用
我的问题：
- 切换上下文的成本是多少
- 必须为每个上下文glFlush实际上会减慢速度吗，还是glFlush只会暂停当前上下文
•必须为每个上下文glFlush实际上会减慢速度吗，还是glFlush只会暂停当前上下文？
上下文有各自的命令流
所有这些东西最终都必须串行化才能在单个GPU上绘制，因此为20个并发上下文刷新命令流会给驱动程序的任何部分带来一些压力。
幸运的是，GL不能保证不同上下文之间的任何同步，因此GL本身不会花费大量精力来确保来自不同上下文的命令以特定的顺序执行。但是，如果您正在等待围栏同步。对象，则它将引入一些有趣的GL相关开销。
•切换上下文的成本是多少？
你为什么要切换上下文
你说每个视图都有自己的线程和上下文，所以我很难理解为什么要将上下文当前更改为线程。
切换上下文的成本非常依赖于硬件。较新一代的硬件往往具有更高效的上下文切换支持。但在任何情况下，这通常都是一项相当繁重的手术。
CCD_ 1的成本既不是很小也不是很大。这不是你想经常做的事情，但适度使用也不会很有害。比起同花顺，我更担心上下文切换。正如Andon在回应中提到的，如果您需要上下文/线程之间的同步，那么glFlush是不够的。这将需要glFinish或某种围栏。
通过您的设置，您还将获得CPU上线程开关的价格。
我认为你的直觉是绝对正确的。根据我对用例的理解，使用单个渲染线程和上下文按顺序渲染子视图可能会更高效。这可能会使状态管理更加繁琐，但您应该能够相当干净地处理它。
为了让这个答案更加独立，Andon值得称赞：您不必调用来设置当前上下文，因为当前上下文是按线程维护的。但在GPU层面，一旦提交了来自多个上下文的工作，仍然会有上下文切换。