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