po在這裡好像怪怪的,如果有人認為不適合我再砍吧.... 小弟不敢稱什麼專家,寫些算是很粗淺的概念,大致上是directX的, 不過其實3d這東西大致上是這樣. 不太會畫圖,所以用連結的,下面是msdn direct3d9的pipeline, 我們先不要管shader model3.0之後太複雜東西,先來基本的 http://msdn.microsoft.com/en-us/library/bb219679(VS.85).aspx 這是一個很基本的d3d9 pipeline,相信很多人都很熟了, 畢竟這架構很久了,還是簡單的說一下, vertex data:可以想像成一堆vertex,他可能代表一個物體,甚至是數個物體 都沒關係,整體而言就是一個很大的buffer儲存我們需要的vertex primitive data:假設我們上面的vertex data是一堆物體,那我們要如何取得 一個物體的vertex?答案很簡單,我們利用index的方法,也就是把上面的vertex編號, 而每個物體只要把他對應的indices給紀錄下來就好了,因為index只需要一個16或是 32bits的數,然而我們每個vertex光他的座標就是三個32bits的浮點數了. 更何況還有類似normal等其他東西,那為什麼不乾脆每個物體都用一個vertex buffer 就好?這其實也是蠻多問題的,最基本的就是一般而言,我們不斷的換vertex buffer 來render對硬體是不好的,所以我們改用一個大buffer而來swap index會是比較有效率 的做法,另外,有些架構上並沒有辦法分的那麼開,假設我們有一個很大的城市我們 把他放進一個buffer,那我們可能需要運算的並沒有那麼多,我們可以用index的方式 只取一小段進入pipeline來處理. tessellation:這其實是類似patch比較會用到,有些只用參數定義的面, 我們必須把他解析為點,可以先無視,印象中蠻少人用patch的,我是指遊戲... vertex processing:這就是一般vertex shader做的工作,我們在這邊做 transformation matrix的乘法,將座標系轉換到screen座標系,或是決定每個 vertex的顏色,一般基本上做的就是這些 geometry processing:因為還沒有dx10,這邊一般做的,是所謂back-face culling, polygon有兩面,如果是反面,沒有正對鏡頭的,那就沒有必要畫,所以有些遊戲例如你 偷看裙子裡面你會發現衣服內側是透明,那是因為他被判定是back-face,所以沒有畫, 基本上這都可以設定啦...但是一般為了效率看不到就不會畫. 另外還有就是clipping,我們前面已經把vertex data轉到螢幕座標系了, 這時候如果超出螢幕外的頂點實際上是不需要的,這時候就會裁掉,因為我們等一下要 進入load重的pixel範圍內,這時候能砍的就砍 textured surface,texture sampler:我們把物體表面對應的texture座標找出來 並且取他的顏色,送進去pixel shader做著色的參考 pixel processing:基本上就是把pixel著色,也是pixel shader的主要工作, 我們根據前面vertex的顏色做內插找出夾在中間pixel的顏色,和貼圖的顏色做結合 pixel rendering:根據z值,alpha,fog來決定最後的顏色,至於stencil這和 陰影一些特殊用法比較有關,這裡我們只顧基本盤,不要理他. 上面講那麼多,其實我們可以看到: 1.d3d pipeline裡面和CPU根本沒關係 2.解析度的大小,其實比較有關聯的pixel shader的部分,除非例如4:3變成16:9, 那我們可能會改變可視範圍讓東西加進來,不然基本上都是和pixel才有關聯, 所以cpu基本上和解析度的相關性也是極小 那CPU真的沒有用嗎?其實這只是因為directx本來就是拿來做graphic部分, 所以單從directx來看和cpu的關聯性並不高.但是其實cpu還是和graphic pipeline 有息息相關的.所以上面的還是要介紹一下. 我們從pipeline來看,一旦我們要進入pipeline的時候,我們的input要是什麼東西? vertex,index的資料,再來還有這邊沒有看到的,就是transformation matrix, 這東西本來應該是在vertex shader,他是作為一個input,我們需要他的world matrix,view matrix,project matrix,world matrix就是這個物體在3d世界的座標 轉換矩陣,基本上我們畫3d都會做一個標準座標系,而我們最後的目的就是要把他 轉到螢幕的座標系,這樣我們才可以說,螢幕座標(x,y)的點,是對應到這個3d的哪些點, 然後用這些點來決定顏色,我們一般都稱為world transformation matrix,因為 通常我們可能有一個起始座標,而物體如果移動,這中間的轉換,我們藉由這個矩陣 來達成,所以我們前面pipeline提的vertex data裡面有包含座標其實是起始座標, 然而藉由不斷改變world矩陣,我們可以讓物體移動到這個世界的任何地方. 另外view matrix則是由camera決定的,如果camera移動,就會改變他, 而最後的project,你可以想像成這是一個camera的參數,他的用途是camera視角轉到 螢幕的對應,如果你camera的參數沒有改變,這基本上是不變的.藉由vertex shader, 他就是把vertex藉由index選出,然後照順序每次處理一個vertex,而這個所謂的處理, 就是把裡面的矩陣乘一乘,這樣的話,我們不會常常去動到vertex buffer,index buffer內部,只要選擇掛上不同的buffer,指定不同的matrix給shader,就能做出運算. 綜合上面所講的,我們通常需要設定一個vertex shader的,有三個matrix, 但是這三個matrix是怎麼算出來的?這是靠cpu,其中,view和camera移動有關, 而且通常都是只有一個camera(除非是動態反射),project通常不變,那剩下的就是 world matrix了,所以每個會移動的物體都會造成cpu的使用. 我們可以說: object相關的是由cpu去做, vertex相關的是vertex shader, pixel相關的pixel shader, 他們的單位劃分基本上就是這樣 以物體的行為來看,如果我們需要知道一個物體怎麼移動,那需要什麼? 如果是我們操作的,那需要input,而如果不是我們操作的,那就需要AI, 再來兩者都需要就是碰撞,或是一些物理上的性質,再來如果有animation, 那我們需要決定animation. 基本上來說,AI,物理,這都是比較操的部分,AI除了決策外,還有所謂的path finding, 也就是找路,這算是比較特殊卻又不可獲缺的東西,甚至他還包含了很多碰撞在裡面, 物理更不用說了,最基本的碰撞就讓人傷透腦筋,物理特性就不贅述,你簡單力學 有碰過的現在很多遊戲都有,另外最近也開始有作品做出動態的破碎或是損害效果, 有些看起來是能藉助shader model4.0,不過目前市面上有一口氣要求一定要4.0以上 的卡的遊戲.....我不太清楚,應該沒有吧? 大部分要做還是要看cpu.另外我還看到有人開始做dynamic animation, 利用計算平衡的方式來算animation,這基本上也是很強的物理運算了. 除了這些外,還有culling,我們前面已經有提過,pipeline中有culling的動作, 然而我們仔細看的話,會發現culling是發生在vertex shader和pixel shader之間, 所以一般遊戲還會做額外的culling,目的是為了上vertex shader能處理的vertex 更少.當然現在有很多演算法,有些甚至先用比較簡化的方式render一遍來做這種 culling,但是基本上這東西以倚靠cpu運算還是無可避免的,還有現在LOD也已經 很多遊戲用了,這也是消耗cpu運算的部分.以上是我粗淺想到一般cpu比較在做的東西. 如果拿這個運算和gpu比較到底比例是多少,這是個無解的問題,程式的東西, 你要寫多操就能有多操,或許就一個畫面的量來看,gpu的運算是驚人的,每個pixel 都要算,倒推回去每個pixel所經過的物體都要算,而且現在render都很複雜,multi-pass 的大量使用使得一個畫面都不只是一個畫面的運算量,還有per-pixel lighting的比重 也都是相當的負荷,更不提一些多算的culling掉的,但是cpu負責的可沒個範圍, 先不提那亂七八糟的物理可能有多複雜,我也寫過cpu的運算要到per-vertex, 甚至一般我們shader比較避免的增減vertex(除非你用4.0),這可能還會額外增加大片 的memory搬移運算,另外超過畫面外的東西,要多少就有多少,無接縫地圖背面可能是 大量的cut scene,lod,外加cpu還要負責一般gpu比較少的branch運算,這對 performance hits不言可喻,平行化處理也沒那麼強,舉凡graphic,physic,AI,music, sound,I/O,network,disk access這些的帳都算在他頭上,現在還有要解壓縮貼圖還是 資料的,真是亂七八糟,包山包海的,要真的搞起來,有時候cpu這邊的負擔更是無法想像 之重,且更難去optimize他.這邊的演算法的變化性也相當之大. 上面所說的都是一個fps要產生一定要經過的,所以cpu和gpu之間的合作本來就是 相輔相乘.而有人會說餵這個動作其實也無可厚非,因為在進入gpu作業之前的前置 全部都是cpu算出來的,我們把結果算好,參數設完,然後才啟動shader,所以我們會把 cpu的結果拿給gpu去當輸入,說是餵其實還蠻貼切的.很多外國的文件也是用feed這個 單字,有點像是叫cpu把要拍的東西都擺好後,gpu過來拍一張照片就走人了,至於擺這些 東西要花多久時間,空間其實很大. 提一個之前讀過ati對於optimize的建議,算是一個蠻基本的概念. 這兩個東西都有其獨立的運算,最好的型態,就是當我們將cpu的結果得出後送給gpu, gpu開始運算的時候,cpu就開始下一個frame的運算,而得到結果後,剛好gpu也把 上一個frame給算完給顯示了,這時候接著下一個開始做,這樣下來cpu,gpu都沒有閒著. 一直做下去,如果cpu delay或是gpu delay,會影響另外一個的運算時間. 即使這篇文章是很久以前的東西,現在還有的pipeline feedback,不過其實可以 大致上看到這個精神所在,如果cpu處理時間過長,那麼gpu需要等結果才能開始 繪製畫面,如果gpu很慢,那cpu算出來的結果必須hold住,等到gpu結束運算我們 才能把結果給feed過去,在xbox360中,directX SDK裡甚至還提到開始delay一個frame 的做法,也就是其實我們每次顯示都是晚一個frame,讓cpu做足一個frame,下一個frame time才丟給gpu算,而gpu也做足一個frame,雖然顯示晚一個frame,但是這樣的感受對 玩家而言其實相當難以查覺且不影響遊戲性的.所以gpu和cpu之間的平衡一直是 game programer要注意的. 重點來了,到底要怎麼知道我的軟體目前是cpu bound還是gpu bound? 我引一個nvidia在gpu gems裡面提到的有關optimize的東西: http://http.developer.nvidia.com/GPUGems/gpugems_ch28.html 在圖28-2裡面這是一個製作者拿來測試現在performance到底是cpu bound還是 gpu bound,老實說放在這裡可能有點不倫不類,但是我想還是可以看一下軟體製作者 是怎麼做的,我們寫程式的也是要知道現在到底瓶頸在哪裡,才能最佳化.現在玩家 可能角度不一樣的是,我們可能要藉由硬體提升來解決performance issue, 老實說我認為在這裡提蠻沒意思的,畢竟你只要換一顆cpu看fps有沒有增加不就知道 了?^^ 不過還是想讓大家看看開發者的做法,我們得從pipeline倒過來,我們先想辦法 移除gpu上的變因,接下來才能得知是否是cpu bound.因為我們cpu負責的是餵給gpu 之前的資料處理,也讓大家知道,對玩家而言,其實說實在還真的除了換一個試試看, 要直接從tool的角度來下手其實不太可能. 首先我們要先問,到底什麼樣的標準才算是合格?就軟體工作者當然有他開發的平台 標準,就玩家來看,應該還是開同步吧?大概60fps就夠了,講是這樣講,我下面也沒 什麼數據啦@_@ 1.首先他先確定是否為frame buffer頻寬,從pipeline最後的raster operation著手, 也就是前面提到的pixel rendering,我們藉由改變32bits到16bits這種depth buffer size的方法,不過這一般的遊戲通常是不會有這個選項給你選的,雖然有些tool可以 從外部去更改,但是我們首先也要知道他原來用的是什麼size^_^ 或是這樣的override有沒有效,才有辦法去測. 2.texture size/filter,這可能一般遊戲比較容易可以調整 3.解析度,這也是可以調的,可以看看下面的解說,裡面有提到這最主要測 pixel shader,雖然他和第一項都和fillrate有關,但是因為我們在pipeline中 這是屬於兩個不同的stage,所以分開測. 4.vertex processing:基本上是測vertex buffer,又來了,這我們根本不可能去測, 因為我們不太可能去改vertex shader的程式,玩家根本束手無策 5.vertex index transfer:這其實解釋起來有點麻煩,一般我們 vertex buffer,index buffer,是有可能放在系統記憶體或是顯示卡記憶體上面, 我們可以指定一定要放在系統,例如dynamic vertex,我們需要cpu運算來改動 vertex buffer,那放在系統會比放在顯示卡好,如果我們不會去動到vertex, 當然放在顯示卡比較好,然而顯示卡記憶體是會爆的,所以我們只能用參數建議, 而並不能直接去干涉,但是問題就來了,如果放在系統上面,那一旦要畫的時候, 勢必要經過agp或是pci-e傳到顯示卡,那這之間的頻寬問題就可能會影響到了, 也就是這個地方想要測的東西.還是老話,這根本不是玩家可以測的,別鬧了,連寫程式 的都不一定會確定directX把東西放在哪裡了,還得花一番功夫測,我們玩家連參數下 什麼都不曉得,要怎麼知道?? 如果gpu的要素都移除了,接下來才是cpu的問題,也就是在開發階段,我們的確可以 用餵不飽這種形容詞來說.我認為,玩家要知道是不是cpu還是gpu的問題, 要得到準確性的結果是不太可能的事,我們頂多就只能就我們能看的選項調一調, 基本上那些解析度,貼圖相關的,如果調一調沒差多少,有可能是cpu問題,而在無法 完全移除gpu變因之前,是否為cpu變因其實無法如此斬釘截鐵.所以即使不夠力, 也不能排除cpu問題...@___@而且這還只是單針對開發中的graphic part,如果以 一個完整遊戲去測,他還有很多graphic以外的變因都隨時在困擾著cpu. 結論:打了那麼多字,聽起來像廢話一樣 所以你要知道你現在cpu夠不夠,應該要先問你顯示卡夠不夠力,才會有下個問題吧? 不然兩個都是變因,且A會影響到B,那至少也得先移除B的原因.不然就直接賭一把 換了就對了啦...反正買好東西以後也用的到-_-a 很多遊戲著重的都不一樣,也無法一概而論,偏高物理,AI,或是大的open map的, 通常會比較需要cpu,現在一般而言其實大部分的軟體還是gpu bound吧?常常一調個 解析度就fps掉的亂七八糟的,既然連gpu bound都沒釐清,那我們要怎麼去確定他 又是個cpu bound的東西呢??有時候,玩家暴力地使用硬體更換得到實際的數據 其實反而還比較容易反應出結果. 遊戲有建議配備,可以先參考一下那個,每個遊戲一定有訂標準,照道理說, 這種東西的確也只有開發者能抓的準,我認為cpu其實比較好的一點,在於其實現在 大部分都還是針對雙核心,一些遊戲thread沒用那麼多個,畢竟thread這東西不是說 開越多就越猛,有些架構設計下開那麼多反而糟糕,還有thread的同步問題或是使用 時機,種種都導致核心再多也無用武之地,而這也只有開發者才比較曉得,時脈其實 大致上不太可能要求到3G,如果沒和intel掛勾的話..... 話雖是這樣講,現在越來越多遊戲的趨勢是在遊樂器上開發,pc版本那個建議配備 說實在還是亂不準一把的,買東西還是看預算看c/p比較重要,如果有那個預算也就沒 這種問題了,反正都買高檔的還不行也只能死給他看了,要是沒那麼有錢的話還 不如挑合適價位的買,不然買台遊樂器算了,至少最佳化都比較好,還不用看這篇長文 廢話.... --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 123.192.157.54 沒辦法啊...如果要知道cpu,gpu做什麼,不講這還不行勒... 寫3d遊戲最麻煩的就是,明明只想搞軟體,為什麼都要搞硬體...:~~~~ 這可能要請問一下了,因為我也沒有trace過,不過根據sdk裡面,xbox有三核,每個核有 兩個hardware的thread,除非他一開始就是為了跨平台,不然有六個硬體thread只開到 2~3個確實有點少,不過當然thread也不是說有那麼多就盡量開吧^^ 在文件裡面有建議的設計model裡面針對360也用了6個thread,不過另外三個其實比較偏 非必要性的,只是我覺得把這種model如果原封不動拿到pc上,那個效率可能會是... cell其實蠻扯的....看的懂日文可以看一下這兩篇... http://game.watch.impress.co.jp/docs/20050519/ps3_r.htm http://game.watch.impress.co.jp/docs/20060331/ps3_2.htm 其實我想這邊能人那麼多應該大概都知道了,可能只是班門弄斧... 第一篇講的是cell的架構,基本上就是一個管理搭配搭配數個simd的用法, 第二篇是當初cell很低迷的時候,他們提出來要怎麼用 cell才能發揮他真正的價值,答案就是:把他當gpu用,看完第二篇只能點點點..... 其實我第一次看到cuda還想說這東西還和cell架構還真有點像 這真的是蠻扯的做法,實在不曉得當初設計的時候在想什麼.... 的確都忘了開發成本這件事了,而且跨平台還可以多撈一筆..... 其實我自己還蠻喜歡sdk裡面建議的那個架構,如果有多核的平台的話應該是 很不錯的idea. ※ 編輯: tea999 來自: 123.192.157.54 (01/21 04:03)