bluesystem wrote:
呃....我寫了十年...(恕刪)
接著這位大大的話繼續..
這真的跟應用程式寫法有直接的關係,
在一個遊戲中CPU需要做的事情很多,
人機互動方面->操作流程的控制, UI介面所需的資料的準備, networking behavior, 劇本控制, 鍵盤搖桿輸入中斷, 字幕輸出中斷...等等的
特效處理方面->物理運算, 場景物件管理(occlusion結構maintain, LOD分析, GPU不支援某些特效的時候還要software workaround(這超傷的), 陰影處理(多半需要multi-pass render)..等等).. 等等
OS多工->就..OS多工被分走了一些資源, 另外window mode也會suffer效能, 因為這肯定是multi-pass render(雖然以現在的gpu而言suffer的其實很小).
驅動程式->理論上好的驅動應該指能用很低的cpu資源才對..不過其實現有的gpu廠難免都會有些東西有bug是用software workaround去補的, 用到這種效果的話效能就挺傷.
但驅動程式的行為完全視應用程式而定, 例如說畫1M條線好了,
省CPU資源的作法是先把這1M的線條起終點全部load到VRAM上去, 然後一個buffer mode line command一次執行, 驅動程式大概就只要告訴GPU現在有1M條線要畫,
座標資料從記憶體位置P1開始, 共N條, 資料型態為Float, 顏色資料定義位置在P2,
然後下個command fire之後CPU就不用再做事情了, 之後的事情就交給GPU即可,
所以CPU做完這些事情的時間可能只要0.01ms,
(因為要下的指令只有幾個, 我們這裡假設劃一串線的命令需要10個好了)
但如果應用程式寫的很爛的話, 他可能就是暴力送, 也就是說, 他每一條線都分開的送,
那麼他要送的命令可能就是10x1M=10M個命令, 總共需要0.01ms * 1000000 = 10000ms, 那效能就差多了.(但是這種資料量連AGP的頻寬可能都綽綽有餘)
但是有沒有可能需要這樣子下?
有可能, 如果一個車子的model被撞擊的話, 外型勢必要改變, 以DX9以前的架構來說,
就真的需要一條一條慢慢送. 這也就是DX10開始有的Geometry Shader的好處了, 形變可以用計算的.
所以, 上面所說的車子被撞的情形, 在一張只有DX8的顯卡的電腦上, 勢必會造成CPU bound, 因為DX8的shader還太過陽春, 還是得靠CPU自己去算變形後會變什麼樣子.
到了一個支援DX9的環境後, 可能就不會再是CPU bound,
因為這個動作會在shader裡面被計算(Shader model 2.0以後提供的彈性大大的增加了這種運算能力),
花的是GPU(正確的說是shader)的時間(然而不同的shader model版本又會有效能及結構上的不同),
但到了DX10的環境, 可能CPU跟shader都不會bound, 所以可以跑的很快.
然而一個遊戲還有很多可能發生的效能瓶頸,
例如bus bound, fill-rate bound, polygon-rate bound, memory bandwidth bound,..等等的
bus bound這種卡在傳輸介面上的問題應該比較常發生在行動裝置上, 在PC上比較不可能發生, 就不討論了.
fill-rate bound這種情況就是GPU來不及填色, 什麼情況會發生這種事情呢?
記得3D mark有一個fill-rate測試嗎? 他就是畫一整串方塊, 全部疊在一起,
從後面畫到前面, 讓GPU沒有機會得到z-buffer的好處而減少畫素填充量,
於是GPU就會開始大量的填充畫素, 這樣就可以測到這個GPU到底一秒鐘可以填多少東西~
所以說, 如果一個遊戲他沒有去做場景管理,
把確定不會出現在畫面上的東西取消不去畫的話, 就會容易發生fill-rate bound.
polygon-rate bound的狀況就是表示GPU無法處理這麼多的polygon,
最簡單的測試方法就是給他超大量的共點三角形(三頂點再同一個位置),
然後打開z-buffer, 關掉render target, 顏色全部改黑色, 讓他一直去空轉, 只去算polygon的位置,
完全不考慮顏色也不會去真的把它畫出來(z-buffer打開的目的就是不讓他會被fill-rate限制住),
這樣就可以得到在真實狀況下這張卡可以達到的最高polygon rate.
(不過這種實作方式很容易就被driver最佳化掉就是了
..或許這就是為什麼新的3Dmark拿掉傳統fill-rate跟polygon-rate測試的原因吧XD)
所以說, 如果一個遊戲不懂得利用bump-mapping或者其他欺騙你的眼睛的技術,
而是暴力的直接使用polygon數量來撐出畫面效果的話, 那麼polygon-rate bound就會發生~
memory-bandwidth bound的情形其實如果發生的話勢必一定會發生fill-rate bound,
因為GPU著色的地點就是frame buffer, frame buffer就是開在顯示卡記憶體上的.
這也就是為什麼市面上的那些閹割卡(ex. 64bit DDR記憶體)在大解析度上只有笑能的原因之一.
所以說, 同樣一個效果, 看你用哪一版的API思考方式去寫,
可能就會決定了這是CPU餵不飽GPU,還是GPU滿足不了CPU的胃口.
如果一個遊戲只知道衝polygon數量來比精細, 那麼可能你插多強的顯示卡都沒有用,
如果一個遊戲用了顯卡還不支援的特效, 讓他得用CPU去進行前置運算,
那麼這遊戲可能就會發生CPU餵不飽GPU的情況, 但這是CPU太弱的錯嗎?
也不能這麼說, 總之就是得看程式怎麼寫的, 看目的是要技術宣示, 還是效能測試, 還是要給玩家玩,
不同的寫法都會造成不同的結果, 所以討論CPU餵不餵的飽GPU真的是得看是對於哪個應用程式而言比較好~
內文搜尋