2011-02-09 67 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。還有一個原因需要轉換。

相關問題