Re: [請益] cpu跟顯示卡要如何了解是否互相餵飽
華碩的strix
技嘉的 G1
華碩看板上說是最弱的470，而技嘉則是風扇有bug，不知道該怎麼選OAO
另外我的power430w,只有4pin的接頭，而技嘉的似乎是8pin接頭，是不是只要買轉接的就
好了
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 42.78.113.3
※ 文章網址: https://www.ptt.cc/bbs/PC_Shopping/M.1481937840.A.AE2.html
→
12/17 09:24,
12/17 09:24
推
12/17 09:25,
12/17 09:25
→
12/17 09:25,
12/17 09:25
→
12/17 09:25,
12/17 09:25
→
12/17 09:25,
12/17 09:25
推
12/17 09:27,
12/17 09:27
可是460弱弱的QQ
推
12/17 09:31,
12/17 09:31
→
12/17 09:32,
12/17 09:32
推
12/17 09:34,
12/17 09:34
對... 只有4pin
※ 編輯: Moxa (42.78.113.3), 12/17/2016 09:38:07
※ 編輯: Moxa (42.78.113.3), 12/17/2016 09:39:30
→
12/17 09:38,
12/17 09:38
推
12/17 09:39,
12/17 09:39
→
12/17 09:39,
12/17 09:39
→
12/17 09:39,
12/17 09:39
→
12/17 09:40,
12/17 09:40
推
12/17 09:41,
12/17 09:41
推
12/17 09:41,
12/17 09:41
推
12/17 09:41,
12/17 09:41
那是什麼東西OAO 我十分鐘回去再拍張照
推
12/17 09:43,
12/17 09:43
※ 編輯: Moxa (42.78.113.3), 12/17/2016 09:44:08
→
12/17 09:43,
12/17 09:43
→
12/17 09:44,
12/17 09:44
推
12/17 09:46,
12/17 09:46
→
12/17 09:47,
12/17 09:47
推
12/17 09:47,
12/17 09:47
→
12/17 09:47,
12/17 09:47
→
12/17 09:59,
12/17 09:59
推
12/17 10:04,
12/17 10:04
推
12/17 10:06,
12/17 10:06
推
12/17 10:07,
12/17 10:07
推
12/17 10:07,
12/17 10:07
推
12/17 10:19,
12/17 10:19
推
12/17 10:24,
12/17 10:24
推
12/17 10:27,
12/17 10:27
推
12/17 10:28,
12/17 10:28
→
12/17 10:30,
12/17 10:30
推
12/17 10:30,
12/17 10:30
→
12/17 10:30,
12/17 10:30
→
12/17 10:31,
12/17 10:31
抱歉，我沒講清楚，我找到一條6pin了
，造成誤會深感抱歉
推
12/17 10:31,
12/17 10:31
※ 編輯: Moxa (125.230.159.117), 12/17/2016 10:36:53
推
12/17 10:37,
12/17 10:37
推
12/17 10:39,
12/17 10:39
→
12/17 10:39,
12/17 10:39
→
12/17 10:41,
12/17 10:41
推
12/17 10:45,
12/17 10:45
推
12/17 10:45,
12/17 10:45
→
12/17 10:45,
12/17 10:45
推
12/17 10:47,
12/17 10:47
→
12/17 10:47,
12/17 10:47
→
12/17 10:47,
12/17 10:47
推
12/17 10:48,
12/17 10:48
→
12/17 10:48,
12/17 10:48
→
12/17 10:49,
12/17 10:49
→
12/17 11:18,
12/17 11:18
推
12/17 11:20,
12/17 11:20
推
12/17 11:49,
12/17 11:49
推
12/17 11:51,
12/17 11:51
推
12/17 11:52,
12/17 11:52
→
12/17 11:52,
12/17 11:52
→
12/17 11:52,
12/17 11:52
推
12/17 11:53,
12/17 11:53
→
12/17 11:54,
12/17 11:54
→
12/17 12:17,
12/17 12:17
→
12/17 12:19,
12/17 12:19
→
12/17 12:19,
12/17 12:19
→
12/17 12:20,
12/17 12:20
→
12/17 12:21,
12/17 12:21
→
12/17 12:26,
12/17 12:26
推
12/17 12:29,
12/17 12:29
→
12/17 13:15,
12/17 13:15
→
12/17 13:16,
12/17 13:16
推
12/17 14:44,
12/17 14:44
→
12/17 14:45,
12/17 14:45
→
12/17 14:45,
12/17 14:45
→
12/17 14:46,
12/17 14:46
感謝各位解說，最後買了技嘉的G1※ 引述《tea999 (測試君)》之銘言：
: 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), 來自: 42.78.18.41
※ 文章網址: https://www.ptt.cc/bbs/PC_Shopping/M.1481964633.A.7AC.html
→
12/17 16:51, , 1F
12/17 16:51, 1F
→
12/17 16:52, , 2F
12/17 16:52, 2F
→
12/17 16:52, , 3F
12/17 16:52, 3F
推
12/17 16:53, , 4F
12/17 16:53, 4F
推
12/17 17:35, , 5F
12/17 17:35, 5F
→
12/17 17:35, , 6F
12/17 17:35, 6F
推
12/17 17:48, , 7F
12/17 17:48, 7F
推
12/17 18:17, , 8F
12/17 18:17, 8F
推
12/17 19:30, , 9F
12/17 19:30, 9F
→
12/17 19:49, , 10F
12/17 19:49, 10F
推
12/17 19:52, , 11F
12/17 19:52, 11F
推
12/17 21:10, , 12F
12/17 21:10, 12F
→
12/17 21:11, , 13F
12/17 21:11, 13F
噓
03/28 19:02, , 14F
03/28 19:02, 14F
討論串 (同標題文章)
完整討論串 (本文為第 6 之 6 篇)：
37
163
PC_Shopping 近期熱門文章
41
133
PTT數位生活區 即時熱門文章
