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