我聽說較少的繪圖調用=更快 暗示的教訓是將盡可能多的頂點數據打包成儘可能少的數組以儘量減少繪圖調用的次數。渲染優化
我正在考慮在OpenGL之上編寫一個渲染框架,將所有的頂點數據打包成少數幾個數組,然後在幾個繪圖調用中繪製整個場景。
我的問題是,如果在一次調用中繪製ALOT(例如對於glDrawElements),這實際上是否會更快地結束?
我也聽說如果你嘗試用一個調用畫出太大的頂點數組,它會溢出緩存,而不是真的最終變得更快。
我聽說較少的繪圖調用=更快 暗示的教訓是將盡可能多的頂點數據打包成儘可能少的數組以儘量減少繪圖調用的次數。渲染優化
我正在考慮在OpenGL之上編寫一個渲染框架,將所有的頂點數據打包成少數幾個數組,然後在幾個繪圖調用中繪製整個場景。
我的問題是,如果在一次調用中繪製ALOT(例如對於glDrawElements),這實際上是否會更快地結束?
我也聽說如果你嘗試用一個調用畫出太大的頂點數組,它會溢出緩存,而不是真的最終變得更快。
本文將是很有用處的你:http://www.nvidia.de/docs/IO/8230/BatchBatchBatch.pdf
恕我直言,你的狀態更改優化的更好。即最大限度地減少切換着色器或紋理等的次數。這些是「真正的」昂貴的操作。
但是關於你的問題。根據我的經驗,渲染大頂點緩衝區的頂點總是比從多個較小的頂點緩衝區渲染要快。
我不知道「溢出緩存」的事情。據我所知,頂點提取單元直接從GPU內存中提取頂點(好吧,有一個頂點緩存,但它只能存儲16個頂點的順序)。唯一可能的溢出是VRAM用完,此時您遇到了更大的問題。
大頂點緩衝區唯一的其他問題是,驅動程序將有麻煩在內存中移動它們。如果您的頂點緩衝區是靜態的,這不是問題,但是您可能會在「即時」更改數據時看到一些較差的性能。
謝謝,這是你鏈接到的一篇很好的文章 – Prime
我目前正在爲KRI引擎實施一個類似的管道。我想親自回答你的問題。 – kvark