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

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

  回應
 
主題工具
宗毛
Elite Member
 
宗毛的大頭照
 

加入日期: Mar 2002
您的住址: 台北市
文章: 4,505
引用:
Originally posted by orinsinal
宗毛你這麼愛用XD這個icon....
你應該去弄學校最近有人在穿的XD服,背後好大一個XD表情..


XD
那個衣服我今天有看到有人穿了(好吧,我不是很常去學校 )
之前在ptt就有在訂不過我也不想訂…感覺上做得不是很好…可惜了
喔喔喔,離題了
     
      
舊 2003-06-13, 01:47 AM #51
回應時引用此文章
宗毛離線中  
Artx1
Master Member
 

加入日期: Jun 2002
您的住址: 耗電量頗高的地方.
文章: 1,959
引用:
Originally posted by 宗毛
可以請問一個笨問題嗎?

"dx9"和"使用ps2.0"這兩件事有什麼不一樣呢?


嗯.... 我這句話指的是"有使用到PS2.0 Shader的物件,可能在畫面的比例中佔得十分地少"的狀況.

我們舉個例子好了.... 比如說, Game Test4 in 3DMark03.
http://www.beyond3d.com/articles/3d...o/index.php?p=4
(source: Beyond3D)

Game Test 4 Technical Summary:
a. DX9 hardware with PS2.0 support required
b. VS2.0 used for modelling the swaying of individual leaves.
c. PS2.0 used for the lake surface and sky. Higher dynamic range used in calculating the sun
d. The ground uses 1.4 pixel shaders, with a colour map, a detail map, a light map, a bump map, and a normalization cube map.
e. Approximately 780,000 polygons are rendered per frame.
f. 50MB video memory is used for textures, 54MB for vertex buffers and 9MB for index buffers.

所以, Game4用到PS2.0的部分是湖面, 天空.
高動態範圍打光用在陽光, 其他地面部分則全部都還是PS1.4; 當然湖面和天空在畫面上佔的比例也不算小了....

只是如果是其他更極端的狀況, 只怕該應用程式就不應該能稱之為一個有廣泛使用到DX9技術的應用程式....

----
或許大家都應該去用Mad-FX來做Real Time Rendering Test.... ^^a
 

此文章於 2003-06-13 02:28 AM 被 Artx1 編輯.
舊 2003-06-13, 02:13 AM #52
回應時引用此文章
Artx1離線中  
宗毛
Elite Member
 
宗毛的大頭照
 

加入日期: Mar 2002
您的住址: 台北市
文章: 4,505
引用:
Originally posted by Artx1
嗯.... 我這句話指的是"有使用到PS2.0 Shader的物件,可能在畫面的比例中佔得十分地少"的狀況.

我們舉個例子好了.... 比如說, Game Test4 in 3DMark03.
http://www.beyond3d.com/articles/3d...o/index.php?p=4
(source: Beyond3D)

Game Test 4 Technical Summary:
a. DX9 hardware with PS2.0 support required
b. VS2.0 used for modelling the swaying of individual leaves.
c. PS2.0 used for the lake surface and sky. Higher dynamic range used in calculating the sun
d. The ground uses 1.4 pixel shaders, with a colour map, a detail map, a light map, a bump map, and a normalization cube map.
e. Approximately 780,000 polygons are rendered per frame.
f. 50MB video memory is used for textures, 54MB for vertex buffers and 9MB for index buffers.

所以, Game4用到PS2.0的部分是湖面, 天空.
高動態範圍打光用在陽光, 其他地面部分則全部都還是PS1.4; 當然湖面和天空在畫面上佔的比例也不算小了....

只是如果是其他更極端的狀況, 只怕該應用程式就不應該能稱之為一個有廣泛使用到DX9技術的應用程式....

----
或許大家都應該去用Mad-FX來做Real Time Rendering Test.... ^^a


謝謝您的解答
(因為之前聽過Gun Metal有沒有支援dx9跑出來效果差不多)

3dmark03真是ps1.4貫穿呀!對nv實在是非常不利
(呃,好像有人測過ati強制跑ps1.3?……我也不知道要去那找了 )
舊 2003-06-13, 02:38 AM #53
回應時引用此文章
宗毛離線中  
Artx1
Master Member
 

加入日期: Jun 2002
您的住址: 耗電量頗高的地方.
文章: 1,959
引用:
Originally posted by 0220
不知道之前那個踢館的"冒牌舒馬克"看不看的懂Artx1大大的文章咧!?
應該請A大跟他過兩招才對.....


我倒覺得我辯才有礙, 只怕八成會被辯倒.... ^^b
比如我先前寫的那篇, 就算是個蠻不好的範例, 常常從某一件事情忽然扯到另一件事情.... ^^a

我本來想插入一些進一步的解釋, 但是好像破字數上限5K了, 只好在外頭另打一篇....
----

1. NV3x的小單元架構.
所謂說和P10的做法很像一樣, 用的是頂點處理器陣列, 把計算打散之後, 交由一個前端的命令處理器先排序之後, 交給後面的處理器群運算, 類似這個狀況:


所以如果要加快速度, 只需要增加那些小VP的量.

不過Pixel Pipeline的部分就複雜很多了....我也不知道要實作所謂的"processor pool"(處理器池)會長成啥樣子, 只能說它們的確是很多小單元結合起來的.

有用到這種"小處理器"的地方總共有
Vertex Shader
Pixel Shader
Texture Fetch Unit

其他地方的改動, 因為都設法固定起來了, 所以看來就不會差那麼多了.
比如說, NV30/31/34的記憶體介面全部都是128bit, 管線全部都是4條....

NV35的話可能就有改動到一些地方, 讓整個架構更有效率.
而這些資源可能會回饋到NV3x最後的成員--NV36上頭.
(目前傳聞NV3x最後應該是到NV36; NV36X除了介面改成PCI -Express之外應該沒有差異)

但是, 它根本的觀念其實是從VSA100來的....
因為VSA100才是真正創始"方便用增加晶片數目"來快速提高效能的方法.
(SLI的成本太大了, 用VSA100可以節省一些東西; 而現在NV3x這種做法顯然省得更多)

原始的概念解釋在這個地方.
http://www.notforidiots.com/NV3x.php

----
2. 十字樹的遊戲畫面算作弊?
這點也是該篇文章那部份的文字前後有問題的地方.
其實這個是先前在一個遊戲討論區中, 有人覺得遊戲畫面品質要好, 就應該要動用大量的資源硬刻.... 但是我們知道, 遊戲適度地使用一些技巧, 減少掉部分的畫面負擔, 可以分配更多的資源給畫面上的其他物件, 有效分配的話, 畫面的整體質感必然會提升.

但是相對地, 當初PS2的鐵拳3與DC的劍魂使用的一種環場佈景技術, 是一個性質上很接近十字樹這一類技巧的東西, 就有人覺得它是偷工減料, "不是真正的3D".

我想, 即使難以量化, 畫面的質感本身就是個頗有說服力的東西.... 雖然"同樣的畫面質感下, 使用更少的資源達到原有的效果"這種說法, 其實老實說是有點難量化了.... 參考性質其實很有限. ^^a (不過要是集中個相當的人數來作普查, 結果就能有一定的參考價值也說不定)

只是, 話說回來.... 如果要測量硬體的效能, 就應該要把軟體上的工作量給固定住, 來看硬體的執行時間, 這點應該大家有其共識吧?

此文章於 2003-06-13 04:22 AM 被 Artx1 編輯.
舊 2003-06-13, 03:51 AM #54
回應時引用此文章
Artx1離線中  
0220
Master Member
 
0220的大頭照
 

加入日期: Jun 2002
文章: 2,291
引用:
Originally posted by Artx1
我倒覺得我辯才有礙, 只怕八成會被辯倒.... ^^b



A大謙虛了!這點我很肯定.....絕對不可能!
舊 2003-06-13, 04:14 AM #55
回應時引用此文章
0220離線中  
宗毛
Elite Member
 
宗毛的大頭照
 

加入日期: Mar 2002
您的住址: 台北市
文章: 4,505
引用:
Originally posted by Artx1
NV35的話可能就有改動到一些地方, 讓整個架構更有效率.
而這些資源可能會回饋到NV3x最後的成員--NV36上頭.
(目前傳聞NV3x最後應該是到NV36; NV36X除了介面改成PCI -Express之外應該沒有差異)


那也就是說nv35只閹一次囉

引用:
http://www.notforidiots.com/NV3x.php


Oops!It's not for me....

此文章於 2003-06-13 10:07 AM 被 宗毛 編輯.
舊 2003-06-13, 09:56 AM #56
回應時引用此文章
宗毛離線中  
giligula
Major Member
 

加入日期: Dec 2002
文章: 156
引用:
Originally posted by Artx1

NV3x是完全不同的理念. 要說起來NV3x整個實作性質上還比較接近3Dlabs P10.(Scalable Shader Array), 處理單元在晶片內部形成陣列, 高階晶片的Shader單元數量最多, 要出中階低階只要砍單元數量就好. 雖說P10當時主要的企圖是想透過compiler技術進一步提高管線執行效率, 當然NV3x因為有同樣性質的實作, 也具有同樣的優勢; 相對地, P10也有NV3x這樣可以很快部署高中低階產品的效果存在, 3Dlabs宣稱當初P10的簡化版P9的設計, 只花了兩個禮拜就搞定了, 架構設計可以說只做了一次, 成本管理上差距天差地遠,

反過來說, R8500 和 R9000 之間的差異並不大, 但是ATi可是幾乎從頭去刻這個晶片.... 搞著搞著可能ATi真的怕了, 現在 R300 和 R350之間沒啥差異, 只有整個晶片作徹底Custom Optimize, 不過花的功夫只怕旁人也難以想像. 總之R200時代帶來的反動就是現在傳聞R360和R390, 直到R420都是同樣的玩意兒不斷地在最佳化.... 直到 R500才會是新的架構. 只怕到時候ATi也開始玩nVIDIA/3Dlabs的這一套.

要強調的事情是, 暴力法是有極限的. 因為我們知道, 即使理論fillrate再高, 都會因為pipeline管線中其他地方造成瓶頸, 而無法實際發揮出來, 比如說即使是現在開始拋售的爛玩意兒, GF4Ti系列,即使是Ti4200都有4pipes x 250MHz = 1Gpixel/s, 這可是有辦法在1600x1200的解析度下跑出520FPS的鬼玩意兒; 更別提R9700啦, 那可是8pipe, FPS會破1K的.... 實際上呢? 我們知道, 瓶頸根本就不在那個地方; 那麼不如務實地追求Shader Performance還比較好不是嗎?

而且產品線的推展成本也變低了, 目前NV31Ultra最終版的時脈是400/800, 不管是fillrate和Memory Bandwidth都和NV30NU同等(1.6Gpixel/s & 12.8GB/s); 但是效能還是有差異. 因為內部的處理單元數量的確有差異, 架構本身已經等於考慮好產品區隔了, 能只做一次的事情就不應該做兩次.

只可惜, 現在根本就沒有啥DX9的遊戲, 甚至DX8的遊戲才剛開始普及, 隨便用個PS2.0的Shader就可以打著DX9遊戲的大旗了, NV3x這樣的架構在宣傳上實在是非常的不利, 看到ATi拿出"8pipes are for REAL.... 4 are a pipedream"字樣的T恤出來, nVIDIA的廣報部門當然是只能鬼扯了....

先不要提FP32和FP16環境上的問題, 即使12bit Int的品質之高令人驚艷, 連John Carmack大神都稱讚; 但是在宣傳上12bit Int一定是矮24bit FP一截, 偏偏就算是現行CRT也很難看出12bit Int與24bitFP的差異----目前市面上LCD目前頂多8bit, 256階, CRT則普遍可以顯示出約三百多階的色階差異, 但是12bit可是4096階.... 透過現行顯示週邊, 用肉眼看得出來才有鬼.

當初Beyond3D貼出3DMark03部分有問題截圖的時候, 有人指出可以"明顯看出"(apperently)因為用了FP16, 使得品質低於24bit的R300; 但是其實即使真的有差異, 因為CRT的限制, 肉眼也絕對看不出來; 除非你拿軟體去分析才會有結果, 肉眼則絕對看不出有差異.

那現在的這麼一大團烏煙瘴氣到底是什麼?

最主要的問題還是在於軟體方面. 像P10/NV3x這樣的架構效能維繫在Compiler Optimize, 塞給它傳統的 Shader 一定沒辦法發揮它的效能, 但是其實因為各種宣傳手法的關係, Optimize和Adaptec之類的字樣濫用得很厲害, 害消費者現在都搞不清楚了.

有些話恕刪了
就我認為
NV30 仍是一顆暴力的 GPU
500MHz 超高時脈
DDR II 記憶體
加上那顆超暴力風扇
很難將它歸類為精巧或聰明的 GPU
只能說他遇到了 R300 這顆比怪�**朁ヰ囿煽馱�

我不是來踢館
只是修正一下 A 大的某些話
A大應是講太快了一時語誤
floating point precision 主要不是用在顏色上
就算使用了 FP32
但是最後輸出的 DAC 也只有 10bit
那其他 22bit 照樣浪費
floating point 是應用在其他方面如 normal map 上
目前 8bit 的 normal map 的確有精確度不足的問題
造成 artifact 的存在
DOOM III 的 normal map 材質在設計之初就為 floating point precision 了

JC 並沒有說 12bit 就足夠
而是說並不是所有的情況下都需要用到高精確度
在某些情況下 12bit 就足夠
在某些是 FP16
少數需要用到 FP32
這和使用 pixel shader 2.0 的時機是一樣的
在 pixel shader 1.4 能夠做出很好的效果
又何必需要用到 2.0 呢
2.0 跟 1.4 的差別在可程式化的程度不同而已
如果 1.4 代表的是 Pentium 的指令集
那就能把 2.0 想成原先 Pentium 指令集加上 SSE 變成 Pentium III 指令集
這麼想就很容易理解(雖然這例子仍有許多不一樣的地方)
不是所有的程式都需要用到 SSE 吧
所以也不是所有像素都需要用到 2.0
同樣的
精度這種東西也是視情況而定
在效能與品質間取得平衡才是重要的
畢竟大家之前用 8bit precision 還不是用得很爽
不必出了個 floating point precision
就一窩蜂的趕流行

說實話
PS2.0 的能力
的確能做出許多貼近真實的質感
加上它只是 1.4 的擴充
所以 developer 接受它的速度會比一開始的 pixel shader 要來得快很多
像 Halo 的電腦版本已經有小部份用上 PS 2.0 了
舊 2003-06-13, 11:41 AM #57
回應時引用此文章
giligula離線中  
0220
Master Member
 
0220的大頭照
 

加入日期: Jun 2002
文章: 2,291
哎喔!好可惜喔!giligula大也是牛魔王級的,可是有人踢館的時候卻不知潛水潛到哪了!
真是的!以後你們這幾個魔王通通要戴綠蠵龜專用的訊號發射器材才行!
舊 2003-06-13, 12:31 PM #58
回應時引用此文章
0220離線中  
宗毛
Elite Member
 
宗毛的大頭照
 

加入日期: Mar 2002
您的住址: 台北市
文章: 4,505
引用:
Originally posted by 0220
哎喔!好可惜喔!giligula大也是牛魔王級的,可是有人踢館的時候卻不知潛水潛到哪了!
真是的!以後你們這幾個魔王通通要戴綠蠵龜專用的訊號發射器材才行!


要不要把giligula大的手機號碼貼在版上算了
--
期末考期末考,專心唸書才是正途呀!
舊 2003-06-13, 12:43 PM #59
回應時引用此文章
宗毛離線中  
0220
Master Member
 
0220的大頭照
 

加入日期: Jun 2002
文章: 2,291
引用:
Originally posted by 宗毛
要不要把giligula大的手機號碼貼在版上算了
--
期末考期末考,專心唸書才是正途呀!


請問一下毛大....gili大到底是念什麼鳥系呀?功課怎麼會那麼重!
啊!該不會是"一顆"那就...................沒法度了!
舊 2003-06-13, 12:57 PM #60
回應時引用此文章
0220離線中  


    回應


POPIN
主題工具

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

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



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


vBulletin Version 3.0.1
powered_by_vbulletin 2025。