最近看了OGRE2.0的一個PPT, 觸動挺大的其實OGRE一直以來所為人詬病的效能問題, 何償不也是我們引擎存在的問題雖然很多時候我們都拿OGRE和GameBryo的效率當反面教材, 但是自己也沒有做到極致相對於GPU的效能最佳化來說, CPU的效能最佳化難得多就好比遊戲開發的書籍, 講API/渲染的多, 講架構&邏輯的少可能很多人以為, 做引擎開發就是做圖形開發, 對於國內的遊戲來說好像沒錯但是如果真正做下來, 資源管理, 情境管理, 動畫, 物理, AI, UI, 音效, 指令碼, 甚至技能系統等都是非常有深度的這也就是導致了, 很多自研引擎能夠把GPU的效能最佳化得很好, 玩起來卻仍然不流暢究其原因, 大多數是對資料的處理存在瓶頸最早讓人覺得"毀三觀"的是Battlefield3的一個PPT, 打破了傳統基於樹/圖的情境管理員模式15000+的物體, 並行Bruce force的一個線性數組做Culling, 比基於樹形結構的管理方式快了3倍, 代碼量只有1/5為什麼呢? 是因為當前的硬體架構決定了, 大多數的瓶頸是在資料訪問上面CPU與記憶體之間有速度非常快的Cache, 如果資料可以在Cache中直接找到, 會比從記憶體中Load過來快很多具體快多少呢? 我只能說不是一個數量級的之所以說是"毀三觀", 是因為這跟學校教的完全不一樣大學裡的"資料結構", "演算法導論", 拿到當前領域&當前硬體體繫結構上, 無疑是有一定誤導性的各種所謂的O(n)演算法, 都是"brach heavy"的, 會引起非常多的"cache miss"舉個例子, 在某些情況下, 二分尋找還不如線性遍曆來得快再加上各種物件導向理論的洗腦, 完全就走上了一條邪路當然, Battlefield3裡還利用了parallel(並行)的思想, 並不僅僅是"cache frieldly"就可以把效率提上去的說了這麼多, 其實就是想闡明一句話(OGRE2.0 PPT裡的):SIMD, parallel, cache-friendly algorithms are the industry standard today!當VTune的熱點函數看不出什麼來, 當GPA的GPU柱狀圖都很平均, 但是效能仍然不夠好, 是不是有些抓狂?想想上面這句話, 也就有了最佳化的方向!
- SIMD, Cache friendly
-
- 其實大多數做引擎的人都有考慮, 好多人都會說"SSE我很熟"
- 我去, 看看他們寫的代碼, 連資料結構記憶體都沒對齊, 還好意思說"SSE我很熟"......
- 另外, 盡量把相同類型的資料存放在連續的記憶體空間裡, 並且進行順序訪問
- 如果有需要, 甚至可以使用prefetch指令把資料載入到Cache中去
- 吐槽一句: 喜歡用if-else的程式員都不是好程式員
- SOA vs AOS
-
- 很多時候SOA(struct of array)比AOS(array of struct)是快的, 因為多數情況下我們遍曆一個結構體數組, 只是訪問其中的一個欄位而已
- SOA與AOS的區別, 就是物件導向與面向資料程式設計的區別之一
- class vs struct
-
- 這才是物件導向與面向資料在語言層面的差異
- 最早認識到class效能會出問題的, 是從N3的代碼裡. floh有說為什麼自己的引擎平台抽象層沒有使用抽象類別, 是因為虛函數對於主機平面的硬體架構效能很差. 本質上來說, 還是cache miss的問題
- 剛入行時看到有人說, 一開始寫程式用struct, 後來用class, 最後還是用struct. 想想這也是從入門->改善設計->改善效能的一個過程吧
- parallel
-
- 現在CPU核越來越多, 甚至手機都4核8核了, 我們遊戲已經把雙核定義為入門配置了
- 開啟工作管理員, 看看CPU佔用率, 除一個核跑滿, 其它都是閑置的-_-
- 所以, 從引擎架構上, 效能最佳化必需要做的一步就是並行化
- 一般來說, 可以有兩種方式
-
- 模組劃分: IO一個線程, 渲染一個線程, 物理一個線程, 邏輯一個線程等
- 任務劃分: 動畫計算, 情境剔除, AI尋路計算, 粒子計算等可以拆分成一個個的小任務, 扔到任務系統(本質上是一個線程池, PS3可以是SPU)裡進行計算
- 很多頓卡問題其實就是某些API調用時間過長引起的, 可以放入後台線程調用. 如磁碟IO, Shader編譯, DirectX API調用等
- memory, bandwidth
-
- 另一個最佳化方向, 其實就是盡量減少記憶體佔用
- 一是從數量上減少, 這樣資料處理次數就減少了
- 一是從單位佔用上, 可以提高記憶體訪問效率
- 再就是記憶體對齊了, 參考SIMD
- 頻寬的考慮, 更多的是GPU端. 如Vertex, Texture的縮小, FrameBuffer的UpSampling, PixelFormat的壓縮, UV的運算(影響Cache), Overdraw的減少(Fillrate最佳化), Shader branch的減少(影響Cache)
- 從ForwardShading到DeferredShading是演算法複雜度上的考慮, 從DeferredShading到DeferredLighting就是頻寬和靈活性上的考慮了. 現在又出來個TileBasedRendering, 都是因為硬體的變化帶來演算法/架構上的變化
總得來說, 硬體在不斷升級換代, 我們頭腦也需要升級換代才能跟得上潮流物件導向雖然加快了開發效率,但是並不是對機器友好的. 在效能至上的領域, 不是很適用說到底, 還是人與機器的博弈
