之前有小道消息似乎ATI有意玩Kentron的QBM,不知道是不是真的?
或許在像顯示卡Buffer這種純粹當local memory的場合真的有市場也說不定
QBM這種東西在MB上是玩不起來的===>根本沒Chipset廠商願意把
這項feature做進去,就連當初大力支持的VIA到現在也沒任何實際動作.
"個人懷疑"Kentron可能在那一顆QBM switch授權費上charge太高.
在不增加Pin count及Layout的情況下,QBM的確是有潛力一下子就把
Theoritical bandwidth拉到現有2倍以上(>70GB/S)

不論是R50或R520,嗯,
pipeline 2倍===>32 or 64 or...whatever,
老實講,除非有"突破性"新製程技術從天上掉下來,否則光是power consumption
就會炸掉世界上8成以上的Power supply.
猜測不論是R50或R520頂多是每管線多塞個TMU或VS再Double,
作作memory controller上的Load-Store optimize
(或者Embadded local memory for XBOX2?個人很懷疑small size的cache真的
對現今這種怪物級Texture intensive的游戲(如DOOM3或3Dmark05)有效嗎???)

唔... QBM需要特殊DRAM chup和ASIC喔，所以會面臨和RAMBUS類似的問題....
是沒那麼嚴重沒錯，不過顯然並沒有推起來，
所以我是覺得要DRAM bendor再生出QBM for Graphic，我覺得有點困難。

至於R5x0，從先前Xenon傳出的消息，似乎是24pipe/48ALU，然後搭配10MB eDRAM，
似乎能做到4x FSAA free.... 500MHz。
不過似乎是沒有具備NV4x的Shader/ROP crossbar機制。

NV4x已經可以做到類似32shader/16color這種組合了，只是沒有實際產品而已；
NV48後來看起來似乎是維持NV40 with Native PCIE的設計，所以沒有特別再強化過。
NV5x不知道會長什麼樣子，不過應該會繼續維持Shader/ROP crossbar。

至於製程.... 應該還好啦。
Intel不是生出了一顆超巨大的Montecito? (24M L3 on-die耶....)


NV40大概300mm2 (16.5x18.5).... 這邊這些怪物CPU不乏超過這個size的。

不過的確不能這樣比啦.... L3不是隨時在耗電的，GPU大概大部分的元件都是發熱源.... :ase

所以說QBM在MB上玩不起來,但在Graphic card這種特殊市場應可一試.
至少可暫時避掉使用512bit data bus在pcb版上的超高成本,
DRAM vendor方面應該是沒問題(驗證不用花太多成本,全給Kentron包辦),
反正以前Matrox也玩過WRAM,
QBM剩下就是那顆關鍵PLL及Switch的價格問題,如果Kentron有現貨的話.

10mb eDRAM在Graphic core上........除了FSAA之外有任何benefit嗎?
sorry這一點我不太清楚
想辦法多增加一些Register File給shader或許還有用一點(想到不成材的NV3X....)
多少減少一些pipeline hazard的發生及順便增加一些data throughput
(不太清楚Nvidia的Branch prediction及math operation機制,但compiler應或多或少可做一些彌補)
畢竟shader intensive的tile越來越多,至少目前趨勢是如此.

-----
抱歉小弟不是CS科班出身,本身是讀文科
請ART兄多多指教

嗯嗯.... QBM當初是針對Main Memory設計的，我是沒聽說過有BGA DRAM based的QBM成品啦。
不過要幹的話是可以生沒錯。
但是ATI當初提過，他們非常注重open standard.... 這個是既有政策。
(PCWatch訪談，http://pc.watch.impress.co.jp/docs/2004/0716/kaigai103.htm)

而我是覺得，GDDR3已經花了很多心思在電氣規格上，
還融入了不少Protocol Based Memory Interface的技術，
QBM實在是有點短線操作的感覺，何況它本身又只是DDR的小改而已。
要我來看也是沒什麼吸引力的東西。



我是覺得這個10MB eDRAM應該會是XBOX2上頭的R5x0專用的設計啦....
因為它要對付的是固定解析度的東西，雖然說這個世代早該支援HDTV了，
不過出現類似當初XBOX1的設計(如SC2在480i有FSAA，720p則沒有)的機會也不小，
很顯然地，在低解析度需要FSAA來提升品質，free的4x FSAA是值得考慮的。

其次，從Xenon的設計來看，R5x0還有一些R3x0的影子，
我是覺得應該也不會有Register File不足的問題。
(NV3x/4x其實都有，只是NV4x比較輕微)
NVIDIA的Brench搞得蠻複雜的，ATI則是避之唯恐不及，
可能政策上一邊是滿足功能再考慮效能，另一邊相反....
不過既然XBOX2要求SM3+，我是覺得總是得解決的，就看ATI怎麼做了。
對NVIDIA而言，只能說NV3x本身是失敗了沒錯，但是經驗還是沒有白費，
SM3的實作週期相較之下很短就是一個例子。



----
我不是業界人士啊，我只是個愛看Anime的學生....XD
何況我也看過不少文科出身的強者。

>>>>對NVIDIA而言，只能說NV3x本身是失敗了沒錯，但是經驗還是沒有白費，
>>>>SM3的實作週期相較之下很短就是一個例子。

感謝Art兄回答^^,真是收獲良多.
不好意思再請教一個問題:
NV4X效能增進是和SM3.0+的instruction length有關,
還是和整體pipeline data path的改良有關?(跟NV3X比較起來)
那一個影響較大呢?

嗚喔.... 剛剛才提到Register File，又來pipeline hazard，
又是data throughput.... 現在又開始扯到instruction length了....

重點是CPU和GPU的邏輯不一樣啊。

實質上，NV4x除了register file應該是NV3x的兩倍之外，
剩下的改良全都是處理單元的增設了，NV3x會大輸R3x0的原因，
不是別的，單元數量一開始NV3x就少R3x0少一截。

只有非常複雜的Shader才會用到大量的暫存器，主因是因為Shader不能對Memory作Direct Access....
所以只好準備大量的temp register(SM2.0是12個，但是SM2a是12~32個，SM3規定32個以上)
因為"要是"真的遇上那麼多的工作，那就跑不出來了。

比方說，(a+b)*(c+d)，一般來說需要兩個temp register，
r1 = a+b，r2=c+d，然後r1*r2
不然可以把它拆成
a*c + a*d + b*c + b*d，
這樣就可以用一個temp regisrer搞定，當然這樣計算量會增大不小。
但是如果今天是sin(a+b)*cos(c+d)，那就拆不掉了。
所以你需要一定數量的temp register，為了應付某些shader的需要。

但是，實質上，因為RT3D的需要，你根本不可能跑多複雜的Shader。
Half Life 2的Shader也不過40個指令而已，而對RT3D而言其實已經很大了。
因為fillrate最糟的狀況會降到1/40....

所以，實質上GPU還不太容易碰到pipeline hazard的，
要能夠造成GPU大量發生pipeline hazard的shader並不多，
因為在這之前，就會先碰到RT3D的需求無法滿足的問題；
至於簡單的pipeline hazard，compiler大多有能力避開。

剛剛說到，NV3x會慢的主因也不是真的因為register file不足，
而是單元數本身就比較少。
今天NV35有4個ALU，8個mini-ALU，但是R300有8個ALU，8個mini-ALU，
連RV360都有4個ALU，4個mini-ALU....(mini-ALU不是每個指令都能跑)
而NV40相當於有32個ALU(每個ALU都還有co-issue能力)....
我不知道剩下的還有什麼好比的。

最後，Shader Model 2 與 Shader Model 3 的關係。

SM3是SM2的完整版.... 主要是把SM2.x的一些optional的東西全變成一定要有的。
比方說Dynamic Flow Control，arbitrary swizzle，還有暫存器數目(12~32)，
SM2.x(2a)真的比SM2多出非常多東西....
SM2b倒就除了暫存器數目和指令長度之外，就沒什麼差異了，所以不能做的事情還是不能做。
也就是說，NV4x在指令結構與能力上，沒有真的比NV3x多很多，因為當初NV3x就做了很多了。
這也是我說"SM3的實作時間因此縮短"的主要原因。
而剛剛說了，NV4x的Register file應該是增為兩倍，不然其實是沒什麼改進的。

畢竟對GPU而言，你等於是要對"每一個pixel都準備register file"，
假設今天GPU有5個stage，總共8個pipeline，那最多同時會有8x5 = 40個pixel在跑，
你必須要準備這麼多的register file，不然就很容易變慢。
當然我剛剛也說了，32個temp register不容易全部使用到，
所以NV3x/4x自然不打算準備那麼多的register file，畢竟它一定得佔掉GPU的空間，
但是指令就準備得很充足，不然就會限制住功能了；速度的問題，則可以靠平行度來解決。

反過來說，R3x0當初以效率為最主要的要求，所以功能雖然較弱，但是準備了十分充足的register file。
先前有做過一個小實驗，R300使用到16個temp register還不會有減慢的狀況。
R420因為SM2b增加到32個temp register，沒測過不知道狀況；
不過顯然維持既有的組態應該也是足以應付。

----
其次，剛剛說到Texture intensive....
你提到：

>個人很懷疑
>small size的cache真的對現今這種怪物級Texture intensive的游戲
>如DOOM3或3Dmark05)有效嗎???)

首先要澄清的是，GPU並不會用到"整塊texture"，
它的材質壓縮和解壓縮都是設計成可以部份解開的，這是要注意的部份。
pixel會做和周邊的pixel有關聯性operation，比方說要參考周邊pixel的color value，
這些都不需要整塊texture，只要有texture address之後，解開需要的特定幾個pixel就好了。
所以小規模的cache還是有用的。

其次，其實現在的設計方向，反而是要減少texture operation(比例上)....
在CPU也是有這種狀況，因為其實Texture和查表的性質是很像的，
但是今天的CPU，除非這個table真的小到可以放進cache內，
不然我access 主記憶體的lantency可能高達數百個Cycle，直接硬算幾乎一定會比較快。

而GPU的狀況也慢慢朝向這個方向....
Texture只有在非用不可的狀況才用，剩下的color operation都是Shader的事情，
現在的觀念是打光要從Vertex Operation 轉到 fragment operation。
因為Graphic用的記憶體也是朝向高頻發展，而現在的高頻記憶體都傾向
long lantency，more bandwidth，而且GPU更缺乏具備大規模cache的條件，
所以texture可能會越來越"expensive"，不如轉為shader operation。

當然，上面提到的觀念都是"比例上"，請注意。
不會變得比"以前的遊戲"少，但是比較整個GPU的工作量時，
在比例上會減少texture的使用。

GPU是平行度萬歲的世界，只要記憶體頻寬夠大，目前平行度還可以不斷往上拉。
和CPU的設計哲學是有一段差距....

我覺得4037分也是有一點偏低, 可能是因為我從9800P換6800GT沒有重罐Windows, 測試時沒有把防毒軟體和msn關掉...
這一代的3DMark 很像用不一樣的CPU分數會差蠻多的...

我的結果跟你的不太一樣﹐應該NV方面的driver有問題。看起來他們好像為了贏3dmark05,最近幾天放出4個不同版的detonator﹐還真亂。

ATI X800XT-PE﹐沒超﹐catalyst 8.07 beta

嗯，我換了66.51之後，等效fillrate提高蠻多的。
基本上除非改變解析度"完全不會影響FPS"，不然顯示卡都還算是部分的瓶頸，
所以高核心時脈高記憶體頻寬還是會有差的。
有空把數據update之後再放上來。

====
不過，我自己是覺得"透過fansite放出的Driver"本身只能算對玩家的宣傳啦....
實質上offical release還是61.77啊，正式的官方放出版是要負責任的。
檯面下放的東西就比較沒關係啦.... 那個玩家自己搞得懂就好。
ATI目前的8.07beta應該不也是這樣放出來的？

所以我覺得沒理由說"亂".... :)

ATI的beta driver其實是為了修Star Wars

這裡是網頁
http://www.ati.com/support/infobase/4649.html

NV好像從來沒有在官網放出beta的detonator, 最多是還沒經過WHQL認證的driver﹐然後過2個禮拜後﹐同樣的driver就變有WHQL。應該是公司的driver政策不同造成的﹐不過自從3dmark05出現以後﹐NV短期內推出了66.29, 66.51, 66.70, 66.71, 66.72, 66.81﹐好像有點亂了陣腳。