我渲染的是由大約500k個三角形組成的相當重的對象。我使用opengl顯示列表,並在render方法中調用glCallList。我認爲一旦圖形原語被編譯到顯示列表中,cpu工作就完成了,它只是告訴GPU繪製。但是現在一個cpu內核被加載到100%。在渲染過程中的高cpu負載
能給我一些線索爲什麼會發生?
更新:我已經檢查它需要多長時間運行glCallList,它的速度快,大約需要30毫秒來運行它
我渲染的是由大約500k個三角形組成的相當重的對象。我使用opengl顯示列表,並在render方法中調用glCallList。我認爲一旦圖形原語被編譯到顯示列表中,cpu工作就完成了,它只是告訴GPU繪製。但是現在一個cpu內核被加載到100%。在渲染過程中的高cpu負載
能給我一些線索爲什麼會發生?
更新:我已經檢查它需要多長時間運行glCallList,它的速度快,大約需要30毫秒來運行它
最有可能你打就行了長度的限制,這是在64K verteces每個列表。嘗試將你的500k三角形(1500k verteces?)分成更小的塊並看看你得到了什麼。
btw您正在使用哪種圖形芯片?如果verteces是在CPU處理,這也可能是一個問題
我檢查了哪些函數在使用cpu,它們來自atioglx2.dll。不幸的是我不能檢查現在是否有限制,一段時間後。我正在使用ATI Mobility Radeon HD 2600顯卡 – 2011-05-29 14:28:53
@misha你確定你沒有獲得SW渲染?如果沒有,那麼你打破了限制 – 2011-05-29 15:00:58
我沒有設置任何選項來做軟件渲染。該限制64k是用於一個顯示列表或全部,例如只有一個顯示列表不能超過它,或所有顯示列表的總和不能超過它? – 2011-05-29 21:28:07
這有點是顯示列表中奇蹟般地一切卸載到GPU的一個神話。如果真的如此,紋理對象和頂點緩衝區就不需要添加到OpenGL中。所有的顯示列表真的是一種方便的方式來重放OpenGL調用序列,並希望保存一些函數調用/數據轉換開銷(請參閱here)。據我所知,我用過的任何PC硬件實現似乎都沒有做過任何事情;也許它在SGI工作站的時代有所不同,但是現在緩衝對象是要走的路。 (現在的OpenGL書籍如OpenGL Distilled只會在插入新的東西之前給glBegin/glEnd等最簡單的提及)。
的一個地方,我所看到的顯示列表做了巨大的差異就是您的應用程序以遠程顯示器(X11「服務器」)運行GLX/X11情況;在這種情況下,使用顯示列表確實會將所有顯示列表狀態只顯示一次,而非顯示列表直接模式應用需要使用更多帶寬再次發送一堆內容。
然而,顯示列表之外,你應該知道的周圍Vsync和忙等待(或它的錯覺)的一些問題......看到this question/answer.
你使用一個簡單的遊戲循環或垂直同步?通常,沒有「睡眠」的遊戲循環需要100%的CPU。 – Lanbo 2011-05-29 07:43:34
30毫秒是巨大的。 30幀/秒意味着33毫秒/幀,所以你只剩下3毫秒...避免顯示列表,順便說一句。 – Calvin1602 2011-05-29 08:21:18
@Scan,我使用FPSAnimator – 2011-05-29 09:11:54