既然您說這是offline-rendering才用得到的東西，
那這是不是表示，
NV30/35跑PS 2.0的game永遠不會有脫胎換骨般的效能表現?
因為game不會用到如此複雜的shader。:confused:

有點尷尬的是在 NV 的網站上介紹古墓 6 的那個 "The way it's meant to be played" Logo:



尤其是第 2 項:
What is TWIMTBP?
- The Ultimate "Install and Play" Experience
- The Hottest Games Developed and Optimized on NVIDIA
- Stunning Cinematic Effects at Blazing Speeds
- The Choice of PC Gamers Worldwide

嗯, 所以這是引導性的回答? (汗)
您希望聽到某些可以預期的答案嗎?

那, 我們朝兩個方向來推論吧.

1. 假設為架構問題....
可能的狀況是平行度不良.
目前來看, 問題可能在於CineFX(NV3x)野心太大了.
CineFX有1024個指令和架構上提供出來的大量常數暫存器....
32個? 話說DX9規格只有要求到12個吧? 總之(目前來看)實在是很不小的數字.
為了支援到這麼大的玩意兒, NV3x的實作看來是作了不少折衷, 於是平行度就受到影響了.

老實說, Shader的實作理想上應該是要不會發生啥指令互相depend的毛病,
不用去在乎何時使用什麼指令仍能全速運作, 但是NV3x看來是有這方面的問題,
效能才會出不來, 而現在看來R300系則沒有這個問題.

會出現這個問題的主因是和競爭對手之間沒有很大的技術差距
因為大家都在靠台灣晶圓廠商代工.... 結果大家都被同一個限制綁住了.

於是, 和當初3Dlabs P10 VPU一樣, 靈活度驚人換來的就是效能不振....
(P10一樣也是256bit記憶體介面啊, 但是VP980Pro卻和750XGL差不多快....)
現在的問題是, datapatch的成本現在實在越來越高了....
繼續搞多單元靈活組合的方式, 到底能有多少賺頭?
如果效能真的拉不起來的話大概就沒人用了, 不管他多有彈性....

總之, 如果是架構問題的話, 那麼下一代產品(NV4x)很可能就不會停留在這個架構下了.
這看來會與Register Combiner的狀況有差異.


2. 假設為Driver問題
不過再怎麼說上述的也是推測, 哪天某個新版Driver又沒cheat又沒耍詭雀能飛上天,
那就只好等著撿眼鏡碎片了? 總之這個只好繼續觀察看看了.

實際上還是要看NV....

一 篇 未 經 證 實 的 報 導 ~
http://www.3dgpu.com/modules/news/a...php?storyid=315

嗯，這邊應該是消息來源
http://www.halflife2.net/forums/sho...5&pagenumber=17

其實拿nv3x來跑跑看9700/9800的dx9 demo就差不多心裡有數了…
之前測的：
5900NU 128MB,Detonator 44.90

[9700 Pipe Dream v1.1]
2003-07-23 06:27:44 - SushiDX
Frames: 2244 - Time: 202062ms - Avg: 11.105 - Min: 7 - Max: 19

[9800 Chimp v1.1]
2003-07-23 06:26:01 - SushiDX
Frames: 837 - Time: 66469ms - Avg: 12.592 - Min: 9 - Max: 21

9700Pro 128MB,Catalyst 3.6

[9700 Pipe Dream v1.1]
2003-07-24 02:13:22 - SushiDX
Frames: 5840 - Time: 199172ms - Avg: 29.321 - Min: 24 - Max: 39

[9800 Chimp v1.1]
2003-07-24 02:17:03 - SushiDX
Frames: 2498 - Time: 66453ms - Avg: 37.590 - Min: 25 - Max: 66

--
我是覺得有可能是driver的問題
因為44.90的表現比44.03好很多了，45.20/45.23應該差不多

上面這段話我不太懂。

R300目前看來沒有shader指令平行度的問題，而NV30/35有，
這會跟在台灣晶圓廠代工有關係???

簡單的說
（要講得很正確又很仔細可是落落長沒人看得完）

NV2x、 R300 和 NV3x 是三種不同的架構
NV2x 是屬於一般 pipeline
每個 pipeline 一個週期(clock cycle)可以處理一個指令(instruction)
不管指令的複雜度

這麼做不是浪費嗎
指令簡單和複雜都是一個週期

所以 NV3x 是有一群小的 processor
簡單的指令一個 processor 一個週期可以完成
複雜的可能要四個 processor 合作才能在一個週期完成
這麼做不僅不浪費
而且彈性佳
不過實際上要像理論上所說的
還需要其他配合

R300 是介在中間
一樣是 pipeline 的架構
但是每個 pipeline 同時配備了純量和向量(scalar and vector) pipe
（scalar operatoin可以看成簡單的指令 vector operation可以看成複雜的指令)
而且 texture fetch 還能平行運算
所以一個 pipeline 一個週期最多能處理一個簡單、一個複雜、還有一個材質指令
算是一種折衷方案
我覺得在目前這是一種較實際的做法

如果有越來越多 DX9 PS2.0 遊戲上市，只有越來越多不漂亮評論，證實 FX 架構只是空有規格高、彈性大，實際表現並不如 ATI 的產品，對 NVIDIA 的現有或未來產品線是不是重大打擊呢？

是有關係啊, 理由除了先前giligula兄講的部分之外, 其實還有兩點需要補充.

1. 如果Driver寫得好的話, scaler(純量) based的管線可以非常有效率,
一個4D vector(向量), 在NV2x時就是一個單元幹掉.
在R300則是一個3D Vector + 一個Scaler,
在NV3x則是4個Scaler

於是, 如果是一個複雜的Vector指令, 則三個晶片每個時脈都能執行1個指令.
但是如果是一個比較簡單的Scaler指令, 則NV2x還是每個時脈只能執行一個,
R300則能在執行scaler的時候, 執行另一個3D Vector指令,
或者是最浪費的狀況下兩個scaler指令, 效率就相當於NV2x的2倍.(至少一個指令, 至多2個指令)
而NV3x的狀況, 則可以有機會執行4個scaler, 效率變成4倍.(至少一個指令, 至多四個指令)

但是, 一個4D Vector單元(NV2x), 與一個3D Vector單元加上1個Scaler單元(R300系), 最後是4個Sclaer單元(NV3x), 這三種架構的電晶體數都不同.
完整的3個Sclaer單元所需的總電晶體數可能比起一個3D Vector單元多出許多,
於是同樣的製程技術水準下, 變成製程可能無法負擔完整的Scaler單元,
而要在硬體設計上縮減部分指令的規格, 於是便成部分指令執行的時候會有相依性,
沒辦法任何指令都全速執行....
指令沒辦法完全平行運作, 於是稱為指令平行度不足.

先天上架構複雜度已經會比較高了, 還外加上NV3x的規格(CineFX)上有著
遠比R300系更多的常數暫存器, 更複雜的條件分支, 更長的指令數量,
這些都會讓Pixel Shader 的 ALU 設計複雜度上升許多, 當然電晶體數就會跟著攀升了.
在同樣的製程技術水準下, 更複雜的架構代表的是較低的良率, 以及受限的晶片總規模.
就算架構的效率相對上比較高, 整體跑出來的效能純量上能不能贏過人家就難說了.

所以, nVIDIA今年去找了IBM合作, 也有改善製程來源的用意.
本來用意再好再理想, 生產不出來或是因為生不出來而被迫降級製作, 就都是空談了.
話說R300, P10 VPU和NV3x都是由TSMC生產的, 或許該說責任都應該推給台灣廠商?
台灣的製程技術大多來自朝vendor外求(UMC/Novellus, TSMC/AMK),
本身技術上根本沒有多強的本事, 如果沒有自己的技術, 外商永遠可以隨時轉向,
而你要是拿不到技術, 根本沒有辦法對抗新敵手....

nVIDIA轉向IBM, 看得出來企圖透過求得遠超過對手的製程, 來投入新架構....
不過問題在於, 目前的態勢上IBM沒辦法取代TSMC成為nVIDIA的主要產能,
於是, 可能就是高階指標產品有機會都靠IBM, 中低階還是得用TSMC.

----
另外一個問題是, 複雜的架構相對地也會提高Driver的撰寫難度.
效率能不能如同理想狀況般發揮, 得要靠更多的心血....

由於nVIDIA的硬體與軟體(Driver)的開發團隊是各自平行運作的,
於是在設計新產品的當下我們也可以繼續拿到更新的Driver....

現在有兩個可能.

1. 新的Driver慢慢地提高NV3x的效能.
架構真的太複雜了於是靠Driver才能慢慢打開封印....
於是已經下手的人可以繼續等等看.

2. 架構有缺失
指令平行度的問題會直接限制住整個架構的理想狀況效能.
假設這個問題真的存在, 而且很嚴重的話, 那寄望Driver就變得沒多少幫助,
下一代的產品(NV4x)便很可能不會再使用同樣的設計.

不過, 考慮到過去nVIDIA的傳統(所有產品維持回朔程式相容性),
維持並且改善架構的方式便成為另一個選擇, 畢竟現有的這個架構是有其優點存在的.
只是相應的成本提升(如上所述)能不能應付就是nVIDIA方面自己要有所覺悟的了.

總之, 基本上CineFX祇是一個"行銷口號"而已, 同樣的程式結構其實也不一定就得要用和現有硬體設計相彷的做法(scaler based, Virtual pipeline datapath)才能做得出來, 回到過去的做法(vector based, pipeline based)同樣能夠達成同樣的規格(程式上的同樣規格).
效率低又如何? 用管線數量彌補也是一個方式啊. 暴力法很多時候並不是笨方法.... :)

總之要看nVIDIA了.
到底是硬體本身設計問題, 或者是Driver問題, 現在其實很難判斷....
人家說"蓋棺論定", 真的是只能看下去了.