Macos 切换OpenGL上下文或切换上下文渲染目标，哪个更可取？

在MacOS X上，只需创建一个

NSOpenGLContext

，然后在其上调用

-setView:

，就可以将OpenGL渲染到您选择的任何

NSView

对象。但是，在任何时候都只能将一个视图与单个OpenGL上下文关联。我的问题是，如果我想在一个窗口（或者可能在两个不同的窗口）内将OpenGL渲染到两个不同的视图，我有两个选项：

创建一个上下文并始终更改视图，每次我要渲染到另一个视图时，根据需要调用

setView

。如果视图位于不同的窗口或不同的屏幕上，这甚至会起作用

创建两个

NSOpenGLContext

对象，并将一个视图与任一视图关联。这两个上下文可以共享，这意味着大多数资源（如纹理、缓冲区等）将在两个视图中都可用，而不会浪费两倍的内存。但是，在这种情况下，每次我想要渲染到另一个视图时，我都必须不断切换当前上下文，在进行任何OpenGL调用之前，通过在右侧上下文上调用

-makeCurrentContext

事实上，我在过去使用过这两种方法，每种方法都可以满足我的需要，但是，我问自己，哪种方法在性能、兼容性等方面更好。我读到上下文切换实际上非常慢，或者至少在过去它非常慢，可能同时也发生了变化。这可能取决于与上下文（例如资源）关联的数据数量，因为切换活动上下文可能会导致数据在系统内存和GPU内存之间传输

---

另一方面，切换视图也可能非常慢，特别是如果这可能导致底层渲染器发生更改；e、 g.如果您的两个视图是位于两个不同屏幕上的两个不同窗口的一部分，这两个屏幕由两个不同的图形适配器驱动。即使渲染器没有更改，我也不知道系统在切换视图时是否会执行大量昂贵的OpenGL设置/清理，例如创建/销毁渲染/帧缓冲区对象。

我研究了Lion上3个窗口之间的上下文切换，我试图用一个使用不当的VTK库来解决一些性能问题，它本身已经非常慢了

切换渲染上下文还是窗口并不重要， 因为将它们作为三元组同时发送给调用线程总是有开销的。我测量了每个交换机大约50毫秒，其中一些操作系统/窗口管理器的开销也是如此。此开销还很大程度上取决于其他GL调用的安排，因为驱动程序可能被迫等待命令完成，这可以通过对glFinish（）的阻塞调用手动实现

我得到的最有效的设置与第二个类似，但有两个专用的渲染线程，它们的渲染上下文（共享）和窗口永久绑定。上述上下文切换/绑定只在init上执行一次

---

线程可以使用一些线程功能来控制，比如公共屏障，它允许两个线程同步渲染单个帧（两个线程都在屏障处暂停，然后才能再次启动）。数据处理也必须联锁，这可以在一个线程中完成，同时暂停其他渲染线程。

50毫秒，它们是指GLContext切换还是渲染目标切换？如果他们提到第一个，那么上下文是共享的还是非共享的？上下文是共享的（强制），开销或多或少是稳定的，并且来自于使不同的窗口对和渲染上下文为当前，独立于哪一个更改。这种测量不可能是一个普遍的事实，因为在没有共享数据或挂起的draw调用的情况下，我没有测量交换开销。在您的特定情况下，您可以测量两种方法的差异（有无绘图）。我尝试通过语法基准测试上下文切换开销，使用非共享上下文，每个上下文中只有一个资源（非常大的纹理），并且没有挂起的绘图调用。结果是每秒大约有50000个上下文切换是可能的。这听起来很高，但必须谨慎对待，因为老实说，这个基准有多现实？哪个应用程序会有那么少的资源，或者永远不会有任何挂起的绘图调用？所以你的数字可能比我的好得多，至少更现实。5万。。。尽管如此，这还是一个有趣的数字！上下文切换的最坏情况是，当另一个窗口“位于”另一个图形卡上时，修改的内容必须通过总线传输。当然，驱动程序在延迟操作中是很好的，但是当渲染到纹理时，或者当纹理由于资源管理而无法持久存储在GPU内存中时，就会发生这种情况。不幸的是，我现在无法访问Mac。相关章节：