PCDVD數位科技討論區
PCDVD數位科技討論區   註冊 常見問題 標記討論區為已讀

回到   PCDVD數位科技討論區 > 電腦硬體討論群組 > 顯示卡討論區
帳戶
密碼
 

  回應
 
主題工具
DanFang
*停權中*
 

加入日期: Aug 2000
您的住址: Seattle, WA
文章: 6,075
引用:
作者老頭
NVIIDA即將要出的CK8-04好像就是支援PCI-E的ㄟ


就是nForce4啦...
     
      
舊 2004-08-19, 08:05 AM #51
回應時引用此文章
DanFang離線中  
Artx1
Master Member
 

加入日期: Jun 2002
您的住址: 耗電量頗高的地方.
文章: 1,959
引用:
作者anomaly
小弟認為NV40有16 pipeline是為了要防止GPU stall,GPU越來越像CPU﹐任何stall都對效能大打折扣。NV40從6 vertex shader變成16pixel shader。 NV應該認為未來的游戲會提高polygon數﹐所以為了不讓vertex shader等pixel shader而閑置,所以提高vertex shader跟pixel shader的比例。


我覺得這個想法有問題.... 6個Vertex Shader本來就已經幾乎是過剩了。
而且"Polygon數量提昇的話",是不是相應解析度下每個surface的pixel數量反而會減少?
實質上,Pixel Shader的數量增加,是因為對Polygon數的依賴降低...
為什麼會對Polygon數的依賴會降低?Normal Mapping。

接著,提高Polygon數的話,會增加的是Vertex Shader的負擔,不是Pixel Shader的負擔。
所以你的說法有前後矛盾的問題。

而且,實質上根本用不到那麼多頂點。
根據NVIDIA的官方說辭,6個VS跑400MHz,可以生出600M個polygon,等於代表4cycle一個polygon....
就算是解析度1600x1200的解析度,每個pixel最多也可以分到三百多個polygon。
但是通通擠一個pixel哪顯示得出來?
就算以最糟的情況,全部的polygon都沒有共用邊,200M個triangle也絕對會遠遠蓋滿畫面,每個pixel都會分到一票polygon。
很久以前,Vertex Rate就已經不是瓶頸所在了,這點可以去看看NVIDIA的GPU Programming Guide。
目前實質上的瓶頸,可以說只有CPU和Fillrate兩個而已。(Fillrate同時受到pipeline和Memory影響)
Vertex Texturing是因為VS在等Texture Unit,所以我不認為算是瓶頸。(那是特殊情況)

引用:
其實剛小弟說過﹐vertex shader只有6個﹐所以大部份時間都會有閑置的pixel shader﹐因pixel shader的負載並不高﹐不會真的需要512bit的memory才能滿足NV40(有512bit到memory當然是最好﹐不過卡的價格會貴的難看)。


GPU stall只有發生在content switching(Shader Profile switching),不會發生VS等PS的情況。
因為VS的動作經過Rasterization之後才交給PS,Geometry Operation和Fragment Operation根本就沒有直接的關係。
所以PS根本不需要去"等"VS,只有VS夠不夠用而已的問題。
至於會不會有閒置的Pixel Shader,我只能說Pixel Shader實在忙到翻掉,因為那是最主要的瓶頸之一,Vertex Shader反而還有可能閒置。

比方說,HL2聽說最長有40個指令的shader。
現在不知道它每個指令各需要多少時間,我們就通通都算1cycle吧。
這樣的話NV40的fillrate會跌到多少?1/40。
這才是Pixel Shader不能休息,記憶體頻寬卻不必顯著增加的原因--運算量顯著提高。

引用:
再來看看NV43的pipeline。vertex shader跟pixel shader的比例比NV40差﹐因此會有vertex shader等pixel shader的情況。不過因pixel shader又在等memory﹐所以只要memory access一多﹐就會有出現GPU等memory的嚴重情況。nv43為256bit進入crossbar,128bit到memory。不過因 pixel shader永遠是處於高負載狀態﹐nv43開4xFSAA會缺氧。既然256bit是在現有科技下可達成的﹐而且價格並不會貴太多﹐為什麼不做?我想這才是關鍵。


NV43開FSAA會缺氧沒錯,但是有個問題是--FSAA Unit一直是獨立於Pixel Shader的。
我覺得這兩張圖都改得有毛病,Pixel Shader並不是指ROP的部份。

最後,256bit的記憶體到底多貴?
我這樣說好了,你覺得128bit很貴嗎?那為什麼小強卡拼命想往64bit擠?

----
NV43不可能256bit,因為看NV43的PCB背後就知道了。128bit就已經把空間都用滿了。
 

此文章於 2004-08-20 04:35 AM 被 Artx1 編輯.
舊 2004-08-20, 04:31 AM #52
回應時引用此文章
Artx1離線中  
HigH
Golden Member
 
HigH的大頭照
 

加入日期: Nov 2000
您的住址: 戰星卡拉狄加
文章: 3,822
這邊似乎有個vs成為瓶頸的遊戲
http://www.gzeasy.com/sparticle.asp...BNV38&offset=16

另外ati x800 demo "crowd" 展示的是x800系列強力的vs

還有未來一年內
LOTR battle for middle earth
black and white 2
rome total war
似乎都是vs非常吃重的遊戲

所以vs還是很有可能成為瓶頸吧?
舊 2004-08-20, 04:50 AM #53
回應時引用此文章
HigH離線中  
Artx1
Master Member
 

加入日期: Jun 2002
您的住址: 耗電量頗高的地方.
文章: 1,959
引用:
作者HigH
這邊似乎有個vs成為瓶頸的遊戲
http://www.gzeasy.com/sparticle.asp...BNV38&offset=16

另外ati x800 demo "crowd" 展示的是x800系列強力的vs

還有未來一年內
LOTR battle for middle earth
black and white 2
rome total war
似乎都是vs非常吃重的遊戲

所以vs還是很有可能成為瓶頸吧?


別忘了,真正大幅度落後的只有5600,它只有1個VS,
其他的要不是記憶體頻寬不一樣就是管線數量都不一樣。
真的要確定是不是VS bounded我覺得要把PerfHUD開出來比才知道。

話說NV31/34真的砍得太厲害了啦.... 砍到和GeForce3一樣都是1個VS....
實際上,那個測試裡面,9600以上(2~3個vs,搭配到8管線)可能就很夠了,
6600的3vs/8ps我就覺得是個不錯的平衡。

上面您提到的吃重遊戲,幾乎都是大場景+重複率相當高的多數物件,
這個都是Geometry Instacing可以發揮的好所在。
真的物理複雜度高到非常可怕,但是貼圖相比之下又比較簡單(才不會卡在fillrate)的東西,
我是覺得真的很少了。

此文章於 2004-08-20 09:40 AM 被 Artx1 編輯.
舊 2004-08-20, 09:38 AM #54
回應時引用此文章
Artx1離線中  
anomaly
Advance Member
 

加入日期: Feb 2003
文章: 406
引用:
作者Artx1
我覺得這個想法有問題.... 6個Vertex Shader本來就已經幾乎是過剩了。
而且"Polygon數量提昇的話",是不是相應解析度下每個surface的pixel數量反而會減少?
實質上,Pixel Shader的數量增加,是因為對Polygon數的依賴降低...
為什麼會對Polygon數的依賴會降低?Normal Mapping。


VS跟PS中間的stall與否應該是看解析度﹐AA/AF有沒有開而定。假設跑320x200﹐每個polygon需要的pixel數比在跑1600x1200絕對少很多。第一情況很有可能是PS在等VS﹐第二情況很有可能是VS在等PS。應該有辦法code出兩個特殊例子使以上兩個情形都發生。ATI跟NV都不公開datasheet﹐小弟也弄不到﹐所以VS/PS中間的關係其實很難去恆量﹐不是一些powerpoint就能解釋的。相信大大也有光臨beyond3d,那裡有些ATI跟NV的RD都會互相猜測對方的產品到底在幹啥﹐如果他們都在互相猜疑﹐可見之中有很多黑洞是公司機密﹐不是一個RD能完全了解一個產品的全部。不過ATI跟NV這代的頂級產品很巧都是6個VS﹐說是巧合也好﹐說是有商業間諜行為也好﹐本身video architecture設計時應該有做評估。

引用:
作者Artx1
接著,提高Polygon數的話,會增加的是Vertex Shader的負擔,不是Pixel Shader的負擔。
所以你的說法有前後矛盾的問題。

小弟同意您的說法﹐也是小弟的原意﹐可能沒表達清楚。

引用:
作者Artx1
而且,實質上根本用不到那麼多頂點。
根據NVIDIA的官方說辭,6個VS跑400MHz,可以生出600M個polygon,等於代表4cycle一個polygon....
就算是解析度1600x1200的解析度,每個pixel最多也可以分到三百多個polygon。
但是通通擠一個pixel哪顯示得出來?


同意您﹐不過官方quote出來的數據應該是theoretical peak。跟CPU的I公司﹐A公司說的CPU FLOPS有異曲同工之妙﹐需要特別的case才有可能達到那種數字﹐而且他們不告訴大眾要如何寫程式驗證。一般workload能有20-30%效率就不錯了。 假設我們有個很笨的3D engine﹐可以看到很遠的東西﹐而且不會因object的距離而減少object的polygon數。假設我們有個100000 polygon的人物﹐把它排排站成一條線然後我們從前面看﹐這個model可能重疊幾萬次。你看到的是一條人在排隊﹐不過後面polygon依舊要算。不過這是很笨的3d engine 。實際上來說﹐很多商業化的engine跟小弟的笨engine很類似﹐需要靠一些 programming hack, 美工的徹步來彌補這些問題。

引用:
作者Artx1
最後,256bit的記憶體到底多貴?
我這樣說好了,你覺得128bit很貴嗎?那為什麼小強卡拼命想往64bit擠?


就小弟了解﹐支援256bit memory比128bit memory,GPU需要多大約450針角﹐GPU製成上是封裝跟die大小的問題﹐每顆大約多US$3-5。就板子而言﹐memory料需多4顆﹐不過每顆慢的memory比貴的便宜﹐多大約US$10。PCB版多少層是沒差很多錢﹐多US$1。小弟前些時候有說過﹐如果弄的出來那256bit大約要比128bit最後市價多約$1000-1500。其實6600GT/6800LE要我選﹐我會買6800LE。
舊 2004-08-20, 10:40 AM #55
回應時引用此文章
anomaly離線中  
a9607
Master Member
 
a9607的大頭照
 

加入日期: Oct 2001
文章: 2,264
刪~~~~~~~~~~~

此文章於 2004-09-18 04:50 PM 被 a9607 編輯.
舊 2004-09-18, 04:40 PM #56
回應時引用此文章
a9607離線中  
a9607
Master Member
 
a9607的大頭照
 

加入日期: Oct 2001
文章: 2,264
引用:
作者Artx1

CROSSBAR..

包含NV17/18/31/34/36全部都是2x64bit,
而使用4way的只有NV20/28/30/35/38,
其中NV20/28/30是4x32bit,NV35/38是4x64bit。



這裡有一點很有趣的...

nv 17/18/31/34 全都是 2x64 bit 的crossbar controler沒錯...^_^

之前 NV18B/MX40000 沒上市之前,依照NVDIA公佈(說是公佈其實是什麼都沒說..@@)的SPEC來看, MEMORY BUS為64BIT 寬的 FX5X00、MX4系列,似乎是只用上了兩個MEMORY CONTROLER的其中一個(剛好是64BIT嘛....)

但是MX4000/NV18B發布後....MX4000可以"支援"(逆進化..^^)到 32BIT的MEMORY BUS...

這意味著,原本的CROSSBAR MEMORY CONTROLER 不侷限於64BIT而已,也可能支援到 32BIT (甚至 16BIT ???)

這種情況下,64BIT帶寬的 5200、MX440、有沒有可能還是用上全部(也就那麼兩個)MEMORY CONTROLER呢 ?

如果答案是否定的,那麼支援32BIT帶寬的MX4000可能是用了修改過的架構,可以彈性的支援 32/64BIT,這種狀況下,即使是 64MB/64BIT的MX4000 也可能用上CROSSBAR CONTROLER

反之..如果答案是肯定的,那有可能全系列的 CROSSBAR MEMORY CONTROLER都支援到 32BIT的BUS...那即使是配置成64BIT的記憶體帶寬,還是有可能CROSS成 2X32BIT..^^
舊 2004-09-20, 01:05 PM #57
回應時引用此文章
a9607離線中  


    回應


POPIN
主題工具

發表文章規則
不可以發起新主題
不可以回應主題
不可以上傳附加檔案
不可以編輯您的文章

vB 代碼打開
[IMG]代碼打開
HTML代碼關閉



所有的時間均為GMT +8。 現在的時間是08:22 PM.


vBulletin Version 3.0.1
powered_by_vbulletin 2025。