我的.Net Winforms应用程序在我的主窗口中创建了三个OpenGL渲染上下文,然后允许用户弹出其他窗口,其中每个窗口有两个以上的渲染上下文(使用拆分器).在第26个渲染环境中,事情开始变得非常缓慢.新的渲染上下文不需要花费几毫秒来渲染帧,而是需要5到10秒.它仍然有效,只是真的很慢!并且OpenGL不会返回任何错误(glGetError).
其他窗口工作正常.只是在一定数量的减速后新的渲染上下文.如果我关闭那些窗户,一切都很好 - 直到我重新打开足够的窗户才能通过限制.每个渲染上下文都有自己的线程,每个都使用一个简单的着色器.当我上传纹理时,似乎会发生减速.但是纹理的大小对我可以创建的上下文数量没有影响,OpenGL窗口的大小也没有影响.
我正在运行nVidia显卡,并在不同的GPU上看到这个,具有不同的内存量和不同的驱动程序版本.这是怎么回事？应用程序可以创建多少渲染上下文是否有一些限制？
是否有其他人同时拥有大量渲染上下文的应用程序？
the*_*ine 11
正如Nathan Kidd所说,限制是特定于实现的,您所能做的就是在常见硬件上运行一些测试.
我在今天的部门会议上感到无聊,所以我试图拼凑一些创建OpenGL上下文并尝试渲染的代码.我尝试使用和不使用纹理进行渲染,使用和不使用前向兼容的OpenGL上下文.
事实证明,GeForce卡的限制相当高(甚至没有限制).对于桌面Quadro,有128个上下文能够正确重绘的限制,该程序能够创建128个没有错误的上下文,但窗口包含垃圾.
它在ATi Radeon 6950上更加有趣,重绘在#105窗口停止,创建渲染上下文#200失败.
如果你想自己尝试,可以在这里找到程序:Max OpenGL Contexts测试(有完整的源代码+ win32二进制文件).
结果就是这样.一条建议 - 尽可能避免使用多个上下文.在多个监视器上运行的应用程序中可以理解多个上下文,但单个监视器上的应用程序应该使用单个上下文.上下文切换很慢.而这还不是全部.OpenGL窗口与其他窗口重叠的应用程序需要硬件剪切区域.GeForce上有一个硬件剪辑区域,Quadro上有八个或更多硬件剪辑区域(CAD应用程序通常使用与OpenGL窗口重叠的窗口和菜单,与游戏相比).如果需要更多的区域,渲染可以追溯到软件 - 再次 - 拥有大量的OpenGL窗口(上下文)并不是一个好主意.
最好的选择是这个问题没有真正的答案。这可能取决于驱动程序、硬件甚至操作系统的一些内部限制。您可能想要尝试检查的是使用的可用纹理单元的数量glGet(GL_MAX_TEXTURE_UNITS)，但这可能是也可能不是指示性的。
避免这种情况的常见解决方案是在单个上下文中创建多个视口，而不是在单个窗口中创建多个上下文。将共享一个窗口的两个上下文结合到一个具有两个视口和某种 UI 小部件作为分割器的上下文应该不会太难。多个窗口则不同，如果实际需要 26 个独立的 OpenGL 窗口，您可能需要考虑完全重新考虑您的 UI 设计。
我现在很难想象一个真正的 UI 用例实际上需要 26 个不同的 OpenGL 窗口同时运行。也许另一种选择是创建一个包含 5-10 个上下文的池，并仅在用户当前可见的窗口（选项卡？）中重用它们。我没有尝试过，但应该可以在一个不包含其他内容的普通窗口内创建一个上下文，然后将该窗口从一个父窗口移动到另一个父窗口到需要它的顶级窗口。
编辑-
嗯，实际上想出一个并不难。支持 WebGL 的最新 Chrome (9.xx) 可能想要打开许多选项卡，每个选项卡都有一个 WebGL 上下文...我想知道他们是否以任何方式处理这个问题。刚刚尝试了一下，在 13 个选项卡后内存不足...这实际上对您来说也是一个很好的检查，看看您是否做错了什么，或者 chrome 和 firefox (4.0.x-beta) 是否有相同的情况问题