切换OpenGL上下文或切换上下文渲染目标,更好的是什么?

Mec*_*cki 6 opengl macos

在MacOS X上,您可以将OpenGL渲染到NSView您选择的任何对象,只需创建一个NSOpenGLContext然后调用-setView:它即可.但是,您只能在任何时候将一个视图与单个OpenGL上下文关联.我的问题是,如果我想在一个窗口内(或可能在两个不同的窗口内)将OpenGL渲染到两个不同的视图,我有两个选择:

  1. 创建一个上下文并始终通过setView每次要渲染到另一个视图时适当调用来更改视图.如果视图位于不同的窗口或不同的屏幕上,这甚至可以工作.

  2. 创建两个NSOpenGLContext对象并将一个视图与任一个关联.这两个上下文可以共享,这意味着大多数资源(如纹理,缓冲区等)都可以在两个视图中使用,而不会浪费两倍的内存.但是,在这种情况下,每次我想要渲染到另一个视图时,我必须通过-makeCurrentContext在进行任何OpenGL调用之前调用正确的上下文来保持切换当前上下文.

事实上我在过去使用过任何一个选项,每个选项都可以满足我的需求,但是,我问自己,哪种方式在性能,兼容性等方面更好.我读到上下文切换实际上非常慢,或者至少过去曾经非常慢,可能同时发生了变化.它可能取决于与上下文(例如资源)相关联的数据量,因为切换活动上下文可能导致数据在系统内存和GPU内存之间传输.

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

Sam*_*Sam 4

我研究了 Lion 上 3 个窗口之间的上下文切换,其中我尝试使用有点滥用的 VTK 库来解决一些性能问题,该库本身已经非常慢了。

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

我工作的最有效的设置与您的第二个类似,但有两个专用渲染线程,其渲染上下文(共享)和窗口永久绑定。上述上下文切换/绑定仅在初始化时完成一次。

可以使用一些线程东西(例如公共屏障)来控制线程,这使得两个线程同步渲染单个帧(两者在再次启动之前都在屏障处停止)。数据处理还必须是互锁的,这可以在一个线程中完成,同时停止其他渲染线程。

  • 好吧,我尝试通过语法基准来对上下文切换开销进行基准测试,使用非共享上下文,每个上下文中只有一个资源(一个非常大的纹理),并且没有挂起的绘图调用。结果是每秒可以进行大约 50'000 次上下文切换。这听起来相当不错,但必须持保留态度,因为老实说,这个基准有多现实?哪个应用程序拥有那么少的资源或者没有任何待处理的绘图调用?所以你的数字可能比我的好得多,至少更现实。 (2认同)
  • 相关章节:http://www.seas.upenn.edu/~pcozzi/OpenGLInsights/OpenGLInsights-AsynchronousBufferTransfers.pdf (2认同)