2011-02-09 66 views
10

我的。Winforms应用程序在我的主窗口中创建三个OpenGL渲染上下文,然后允许用户弹出其他窗口,其中每个窗口有两个更多渲染上下文(使用分离器)。在大约26日的渲染环境中,事情开始变得非常缓慢。新的渲染上下文需要5到10秒,而不是花几毫秒来渲染帧。它仍然有效,只是真的很慢!而OpenGL不会返回任何错误(glGetError)。您可以同时创建多少个OpenGL渲染上下文有限制吗?

其他窗口正常工作。只是在一定数量的减速后新的渲染上下文。如果我关闭这些窗口,一切都很好 - 直到我重新打开足够的窗口超过限制。每个渲染上下文都有自己的线程,每个渲染上下文都使用一个简单的着色器。当我上传纹理时,减速似乎发生。但是纹理的大小对我可以创建的上下文数量没有影响,OpenGL窗口的大小也没有影响。

我在nVidia显卡上运行,并在不同的GPU上看到不同数量的内存和不同的驱动程序版本。这是怎么回事?应用程序可以创建多少个渲染上下文有限制吗?

其他人是否有一个应用程序与LOTS的渲染上下文同时进行?

+0

另请参阅https://community.amd.com/thread/184325以获取有关AMD的参考,我有感觉AMD计数很低(+/- 20 ctx?) –

回答

4

最好的选择是这个问题没有真正的答案。这可能取决于驱动程序的某些内部限制,甚至操作系统的硬件。您可能要尝试检查的是使用glGet(GL_MAX_TEXTURE_UNITS)的可用纹理单元的数量,但这可能是也可能不是指示性的。

避免这种情况的常见解决方案是在单个上下文中创建多个视口,而不是在单个窗口中创建多个上下文。将共享窗口的两个对象与具有两个视口和某种UI小部件的单个上下文作为分隔符合并应该不会太困难。多个窗口是不同的故事,如果实际需要26个独立的OpenGL窗口,您可能需要考虑完全重新考虑您的UI设计。
现在很难想象一个实际需要26个不同的OpenGL窗口同时运行的真实UI用例。也许另一种选择是创建一个包含5-10个上下文的池,并仅在用户当前可见的窗口(选项卡?)中重用它们。我没有尝试过,但应该可以在不包含其他内容的纯窗口中创建一个上下文,然后将该窗口从父窗口移至父窗口,以将其置于需要的任何顶层窗口中。

编辑 -
呃,实际上并不难想象一个。支持WebGL的最新Chrome(9.x.x)可能希望打开多个标签,每个标签都带有WebGL上下文......我想知道他们是否以任何方式处理这个问题。刚刚尝试过,并在13个标签后耗尽内存...这实际上是一个很好的检查你,以及如果它的东西你做错了,或者如果铬和火狐(4.0.x-β)有相同的问题

+4

GL_MAX_TEXTURE_UNITS'确实没有使用最大数量的渲染上下文。 –

0

鉴于OpenGL驱动程序的多样性,最好的方法是检查主要驱动程序(AMD/Intel/NVIDIA/MS Software Render)的行为并在首次启动时运行测试。例如。如果你能看到NVIDIA总是像你看到的那样慢下来,那么只需运行一个快速循环,直到你看到那台机器(或者说卡)的极限。这没有多少乐趣,但我认为很难可靠地推动其他限制。

换句话说,“最好的赌注”就像以前的回答,你事先不知道。

9

正如Nathan Kidd所说的,限制是特定于实现的,您只能在通用硬件上运行一些测试。

我在今天的部门会议上很无聊,所以我试图拼凑一些创建OpenGL上下文并尝试渲染的代码。我尝试使用和不使用纹理进行渲染,使用和不使用前向兼容的OpenGL上下文。

事实证明,GeForce显卡的极限是非常高的(甚至可能没有限制)。对于台式机Quadro,有128个上下文的限制能够正确重新绘制,该程序能够创建128个更多上下文而没有错误,但窗口包含垃圾。

ATi Radeon 6950更令人感兴趣,在#105窗口停止重绘,并且创建渲染上下文#200失败。

如果你想自己尝试,可以在这里找到该程序:Max OpenGL Contexts test(有完整的源代码+ win32二进制文件)。

这就是结果。一条建议 - 尽可能避免使用多个上下文。在多监视器上运行的应用程序中可以理解多个上下文,但单个监视器上的应用程序应该使用单个上下文。上下文切换很慢。而这还不是全部。 OpenGL窗口与另一个窗口重叠的应用程序需要硬件剪切区域。 GeForce上有一个硬件剪裁区域,Quadro上有八个或更多的区域(CAD应用程序通常使用与OpenGL窗口重叠的窗口和菜单,与游戏相比)。如果需要更多的区域,渲染会回落到软件 - 如此重复 - 有很多OpenGL窗口(上下文)并不是一个好主意。

+1

非常丰富的测试程序,谢谢 - 在这款ATI Radeon HD 4870上,它的价值在于它的价值(在预期的情况下),所有更新都顺利进行 - 尽管在此之后它会挂起。 – fusi

-1

如果你经历了很多麻烦,以过多的多线程方式设置OpenGL,你也可以从中受益并考虑切换到Vulkan。通过设计,请参阅OpenGL体系结构将所有辛苦赚取的上下文/线程分离的绘制操作集中到一个驱动程序线程中,然后将所有这些调用重新分配映射到每个上下文的交互式虚拟硬件线程。这个驱动程序本质上是一个巨大的瓶颈,因为它本身并不是线程化的,尽管任何一个glewmx都坐着。它根本不是为了处理这个问题而设计的。

这就是说,我很好奇你是否使用了旧版本的Glew,或者如果你以其他方式完成所有扩展处理,因为最新的glew库不再支持mx。还有一个原因需要转换。

相关问题