其實還有另一個問題存在....

nVIDIA雖然官方宣稱"FP16是FP32的兩倍快", 但是根據NFI那邊的數據分享, NV3x使用FP32時的速度延遲並不是真的那麼大.

http://www.notforidiots.com/forum/v...php?t=8&start=8

在極端的case(使用32個register)下, 程式碼完全使用FP16運作有可能比使用FP32快了2.4倍.
但是如果減少register的使用(意指交換減少, 共用增加, 程式碼總長度增加), FP32其實並不會很慢, 反而會有一些有趣的狀況: 使用超過16個register的時候, 效能會大幅降低.

也就是說, NV3x可以透過Compiler技術大幅改善效能, 比如說16個register的部分, 你可能可以透過增加10%的shader code長度, 換得40%的效能提昇.

如果今天是assembly寫死的話, 那只要code和NV3x的架構"相性不好", 跑出來一定很難看; 不過如果是 in-time assemble 甚至是 HLSL 的話, NV3x能透過 compiler 調整 shader code, 大幅地改善效能, 但是卻不會影響輸出品質.

因為目前的 DX9 HLSL 使用率還相當低, 而且 3DMark03 還有不少PS1.4 Shader, 這些都是寫死的 assembly code, 這對 nVIDIA 而言有點類似故意拿頭去撞牆壁吧.

相反地, R300 架構上直接改善了某某單一指令的執行速度, 這需要特定指令保持特定順序, 對固定指令的狀況比較有用; 但是如果引入 HLSL 的時候, 這種效果就不明顯了.

而我們知道一個關鍵是: DX8 與 DX9 的指令格式都是定死的.
而OpenGL2.0, GLSlang 的低階部分並沒有任何規範, 代表 DX9 的 compiler optimize 相比之下勢必有其極限存在, 而且定死的指令格式會成為未來的包袱(強迫相容), 於是已知 DX10 會取消指令格式方面的規定.

當然, R300 真正會快的原因還是因為 AF 的速度比較快, 這點可以從跑 DX8 的狀況下觀察得知; 由於 TMU 讀取能力直接關乎 AF 的速度, 從 NV3x 的 AF 在相同模式下與 NV2x 速度相同的狀況來看, NV3x 的 TMU 能力與 NV2x 比較起來並無改善, 因而形成了 NV3x的 fillrate 瓶頸, 於是 NV35 即使增加記憶體頻寬, 除了 FSAA 之外效能並沒有與 NV30 拉開差距的主因也是在於 TMU 的讀取能力並沒有差異.

====
總之 這一連串風波下來, 3DMark03 的參考價值與公信力已經被破壞得差不多了.
或許可以說這才是 nVIDIA 的目的吧.