有人叫我嗎? ^^a

上頭的說法好像是對AF的有效角度部分有點誤解?
R3x0的有效角度是以45度為單位的切割,所以失效角度比以前小,雖說一失效就會變成bilinear,但是那個區間比以前R2x0小多了,所以其實不是很容易看出來.

至於R3x0的fog濃度問題,似乎是以前就有的硬體實作的毛病....與cheat不是很有關係.
overdraw的alpha bliending省略是不是cheating也是靜待ATI回應得好.
畢竟R3x0的8pipes/112~128flops有確實的優勢在,實在是不太需要刻意去作弊....


http://www.guru3d.com/admin/imageview.php?image=1729
至於這張圖.... 留給大家自己去評估好了.

R3x0的主要問題在於FP24,因為這個format在CPU運算架構上不存在,於是不論是content creation或者是rendering process上,
都會因為轉換帶來一些額外的quality lost,其實應該視為只有FP16的水準; 至於有效值域帶來的問題也是developer得自己去解決的. 別的不提,光R3x0的VS自己就是32bit的了,Rasterizer之後如果沒注意的話爆掉難免.

這邊有一個好處啦,R3x0發表得比較早,所以這些部分市場上的developer早就已經了然於胸了,反倒是號稱"正當實作"的NV3x被當成異數,這點NVIDIA可能得叫屈了,不過誰叫NV30要delay呢? 嘿嘿.

NV3x的FP16/FP32全都是native support的,所以不會有這方面的問題; 但是NV3x自己有別
的問題,這也是設計之初的取捨就已經注定的"原罪".

http://pcweb.mycom.co.jp/news/2003/10/24/29.html

NV3x是在支援32bit與CineFX的一狗票功能為前提下做出來的東西,所以它的設計過程是與製程極限的格鬥.由於指令複雜度較高,所以單元構成也放得很複雜,NV3x的管線實在是很需要額外調整的玩意兒,而這點在R3x0先行推出,programmer早已經熟悉R3x0的狀況下,NV3x對programmer的額外要求其實更是讓人反感.

已經有這個不利前提了,NVIDIA還不早早解釋架構,這點實在是很找死....不過其實也難為他們了啦,NV30推出的時候如果做這種事情,只怕NV30也是會很慘,因為這樣比下來NV30其實只有32flops,和R3x0比起來差更多.

當時也有人提到,NV30是個"賣相不好的架構",不適合宣傳;CineFX2就好上許多,不過仍舊是處於劣勢.

R3x0的最佳化方針很簡單,看管線狀況就知道,R3x0適合將4D Vec拆成3D+1D處理,因為R3x0有3D+1D的管線,所以甚至可以同時吃不同種類的3D+1D的指令,這個時候就會賺到一個op,最極端的狀況相當於8x5的架構.(!!)但是當然這種事情非常不容易發生,因為就算再刻意去滿足這個條件,也不會有多少機會可以達成.

當初R300推出時宣稱有同時3個指令的執行能力,R350/R360推出時卻說成5個指令,其實這也是詭辯.... 因為R300和R350/R360根本就沒啥差異(except F-buffer),在RT3D遊戲設計上R350/R360做得到的,R300都做得到,基本上只是額外的宣傳手法而已.

well,這回NVIDIA也搞了類似的玩意兒就是: NV35的管線在FP32下只有64個flops,FP16時才有96flops,NVIDIA自稱的16Gflops+32Gflops是FP16時的數據.

不過,NV3x有個好處: 它的最佳化case比R3x0多,而且透過compiler能幫上忙的部分也比較多.因為雖然它有register file大就會變慢的問題,但是如果能夠搭配quad的持續streaming供給,就可以掩蓋掉這個問題.(SIMD的特性)反正就是盡量塞就對了.XD

R3x0的單元閒置狀況基本上不容易避免,NV3x雖然資源總量比較少但是如果有良好搭配工具的話則仍然可以逼出不錯的效能,所以R3x0與NV3x仍然打得起來.

問題來啦,ATI與Valve的綁標,和NVIDIA與EA之間的綁標,都把上面這些掩蓋到後頭去了.

基本上NV3x與R3x0之間應該是4x2與8x1之間的勝負,8x1有優勢但是不會太誇張(尤其是現在的記憶體頻寬和時脈都差不多),所以要是出現很誇張的落差,其實就可以懷疑有額外的原因在作用,比如說Valve可以看得出來朝ATI的架構靠攏得很厲害,應該是不用刻意去提了啦....

比如說,先前洩漏的HL2原始碼,可以看出NV3x的backend大多是ATI的指令再做點小修改來的,其實是應該要有段差距才對,要是有良好的最佳化的話,NV3x在HL2是應該不會輸得這麼慘就是了啦....(well,輸倒是應該還是要輸. )

本來,媒體(比方說各測試網站)應該要了解並且闡述這一點,不過這段時間內我們倒是沒看到這種表現,甚至連B3D都蠻有立場偏頗的一點跡象跑出來,其實我覺得是不太好的.

說到HL2,好像就會讓人想到NV3x的RTF failure?
不過DX9 03fall update有特別提到FP16/32的RTF support,ForceWare52.16的release note也特別寫明RTF support,我會覺得現在問題卡在微軟身上,可能需要新的DX9 Runtime update.

(嗯,微軟何時放呢? 所以,又是陰謀論!? XD)