http://pc.watch.impress.co.jp/docs/2008/0828/nvision06.htm
トニー・タマシ上級副社長テクニカルセッションレポート
「NVIDIAが描く5年後のGPUの姿」
他們願意拿FX5800出來比較讓我很意外….XDa
不過想想GTX280也被拿來和FX5800並列了。
從1998~2007年之間的性能攀升比例來看，GTX280的texture和AA性能低於預期、但是浮點性能是高於預期。不過只差10%是怎麼看的？
照這個曲線走下去，2013年會是1Ttexel/s texturing、20TFLOPS、1TB/s的大怪獸，而以每年兩倍的比率算的話，2010年也得要有2.5TFLOPS才成，而且ROP還是分開的。
所以這也是在嗆Larrabee不夠看嘍….？XD(如果Larrabee要拖到2010年才出的話)
總之從這可以看出NVIDIA堅持單晶片擴大的理由了….他們似乎認為無論如何要維持住單晶片每年幾乎兩倍的性能增長。
2013年的GPU 1Ttexel/s texturing 20TFLOPS实现起来应该都没有问题，只是担心1TB/s的记忆体频宽NVIDIA如何实现？难道要靠XDR3？
這個取決于臺積電，和nv沒有太大關系。
這個取決于臺積電，和nv沒有太大關系。
2013太遠了無法預測…
可以肯定的是Larrabee的Core一定遠大於SPE.
因為SPE只有vec4向量單位,沒有獨立scalar單位.
而且省略cache相關線路,向量也只有4way而非16way.
Larrabee的簡單64bit X86 Core一定會比SPE要龐大.
只是還不知道大多少.
Larrabee的Core如果大於Atom,
例如要40~50M大概就沒競爭力了..
那樣32core+Tex至少會接近4870X2的size
卻只有16vec X 32core X 2Ghz = 1T op/sec
(2Tflops MADD)
這恐怕跑不贏4870X2或GT300…因為Larrabee還有ROP,Interpolator等固定管線要模擬.
Larrabee的Core如果如果在30M上下,還有一拼的機會.
GT300應該會針對ALU做強化,起碼也需要2Tflops.
200GB/sec頻寬,以擊敗4870X2奪回卡王位置.
2013太遠了無法預測…
可以肯定的是Larrabee的Core一定遠大於SPE.
因為SPE只有vec4向量單位,沒有獨立scalar單位.
而且省略cache相關線路,向量也只有4way而非16way.
Larrabee的簡單64bit X86 Core一定會比SPE要龐大.
只是還不知道大多少.
Larrabee的Core如果大於Atom,
例如要40~50M大概就沒競爭力了..
那樣32core+Tex至少會接近4870X2的size
卻只有16vec X 32core X 2Ghz = 1T op/sec
(2Tflops MADD)
這恐怕跑不贏4870X2或GT300…因為Larrabee還有ROP,Interpolator等固定管線要模擬.
Larrabee的Core如果如果在30M上下,還有一拼的機會.
GT300應該會針對ALU做強化,起碼也需要2Tflops.
200GB/sec頻寬,以擊敗4870X2奪回卡王位置.
单晶片继续扩大对功耗以及散热是个严峻的考验，看NVIDIA如何解决这个问题…
单晶片继续扩大对功耗以及散热是个严峻的考验，看NVIDIA如何解决这个问题…
1TB/s靠類似C1的edram完全沒有問題。
而且在能夠輕易滿足當時高端分辨率加8AA的容量的edram面積也不會太大。
1TB/s靠類似C1的edram完全沒有問題。
而且在能夠輕易滿足當時高端分辨率加8AA的容量的edram面積也不會太大。
我對Larrabee還是比較失望的
我開始以為是能每周期處理4道SSE指令（可以是來自不同執行緒的）實現16D的運算能力。
結果是獨立的向量單元。
這Intel一邊說Cell需要程序員多學一門語言，一邊往Larrabee里面塞非X86的東西作為主要運算性能。
我看起來是非常可笑的。
我對Larrabee還是比較失望的
我開始以為是能每周期處理4道SSE指令（可以是來自不同執行緒的）實現16D的運算能力。
結果是獨立的向量單元。
這Intel一邊說Cell需要程序員多學一門語言，一邊往Larrabee里面塞非X86的東西作為主要運算性能。
我看起來是非常可笑的。
>>這Intel一邊說Cell需要程序員多學一門語言，一邊往>>Larrabee里面塞非X86的東西作為主要運算性能。
這不太一樣.
CELL的PPE和SPE是不同的架構.
SPE不能跑PPE的code.
Larrabee的16way SIMD只是增加X86指令而已.
它仍是可以跑基本的X86 code.
它的開發工具compiler很可能只是更新版本而已.
不是另外一個開發環境.
而且它是以GPU的型態出現,開發者不一定要
學怎麼去coding….當它當GPU看就好了.
開發者在乎的只是這種新架構的GPU效能好不好.
目前最大的Larrabee疑問還是效能.
cpu的core再怎麼精簡也不會很小.
而GPU的shader unit卻是比SPE更精簡的東西.
RV770只增加300M電晶體卻可以多了
800個SP(96個4+1D)和一堆TMU….
1個4+1D的US unit可能不到3M電晶體
X1950的1個PS unit只要2M電晶體.
(雖然這不含L1和register file.
但是那些是很多SP共用的.佔不了多少空間)
而現在高時脈CPU core隨便都是幾十M電晶體起跳.
就算時脈高一倍,vector unit寬了4倍.
還是很難和純種GPU競爭flops.
除非把CPU指令相容的包袱全丟掉….
但那就是一般GPU了.
>>這Intel一邊說Cell需要程序員多學一門語言，一邊往>>Larrabee里面塞非X86的東西作為主要運算性能。
這不太一樣.
CELL的PPE和SPE是不同的架構.
SPE不能跑PPE的code.
Larrabee的16way SIMD只是增加X86指令而已.
它仍是可以跑基本的X86 code.
它的開發工具compiler很可能只是更新版本而已.
不是另外一個開發環境.
而且它是以GPU的型態出現,開發者不一定要
學怎麼去coding….當它當GPU看就好了.
開發者在乎的只是這種新架構的GPU效能好不好.
目前最大的Larrabee疑問還是效能.
cpu的core再怎麼精簡也不會很小.
而GPU的shader unit卻是比SPE更精簡的東西.
RV770只增加300M電晶體卻可以多了
800個SP(96個4+1D)和一堆TMU….
1個4+1D的US unit可能不到3M電晶體
X1950的1個PS unit只要2M電晶體.
(雖然這不含L1和register file.
但是那些是很多SP共用的.佔不了多少空間)
而現在高時脈CPU core隨便都是幾十M電晶體起跳.
就算時脈高一倍,vector unit寬了4倍.
還是很難和純種GPU競爭flops.
除非把CPU指令相容的包袱全丟掉….
但那就是一般GPU了.
昨天翻了一下ShaderX1的舊書.
Intel之前就努力過推廣Software PS2.0.
那是透過MMX處理Pixel,用SSE處理頂點和shader.
但他們也坦言,軟體繪圖效能落後GPU好幾世代.
因為鋒值效能差了10倍.只能做為替代方案.
現在Larrabee的軟體工程師可能是同一批人,
這次透過硬體架構的大改來提昇SoftwareGPU的效率.
昨天翻了一下ShaderX1的舊書.
Intel之前就努力過推廣Software PS2.0.
那是透過MMX處理Pixel,用SSE處理頂點和shader.
但他們也坦言,軟體繪圖效能落後GPU好幾世代.
因為鋒值效能差了10倍.只能做為替代方案.
現在Larrabee的軟體工程師可能是同一批人,
這次透過硬體架構的大改來提昇SoftwareGPU的效率.
> 目前最大的Larrabee疑問還是效能.
> cpu的core再怎麼精簡也不會很小.
> 而GPU的shader unit卻是比SPE更精簡的東西.
SPE其實與其說精不精簡，不如說平行度不太夠…..
不知道CELL3打不打算強化到8way SIMD，不過看來是不見得了。
> RV770只增加300M電晶體卻可以多了
> 800個SP(96個4+1D)和一堆TMU….
> 1個4+1D的US unit可能不到3M電晶體
> X1950的1個PS unit只要2M電晶體.
> (雖然這不含L1和register file.
> 但是那些是很多SP共用的.佔不了多少空間)
register file適用來對抗記憶體延遲用的，和快取一樣都要隨著需求增加，也要隨著單元數量增加，以確保平行度。
所以雖說是共用的，但是我想小不到哪邊去….
以規模來說，G8x/G9x class的TPC有16D，8TMU，和64KB的register file，估計約50M電晶體，但是論電晶體來說core2 duo只有1/3的數量，die size卻大得多…. 所以x86電晶體電晶體數量可能沒那麼複雜，但是wiring的複雜度卻可能造成很大的規模。（主要是OOOE)
反過來說，相對起來簡化很多的Larrabee CPU core當然會稀釋這個差距。
> 而現在高時脈CPU core隨便都是幾十M電晶體起跳.
> 就算時脈高一倍,vector unit寬了4倍.
> 還是很難和純種GPU競爭flops.
我是覺得應該用TPC啦，array之類的單位去和CPU core比較啦….
比方說R6x0/R7x0應該是80sp為單位，那其實也沒小到哪去。
用SP來當core數量顯然是很行銷的寫法….
> 目前最大的Larrabee疑問還是效能.
> cpu的core再怎麼精簡也不會很小.
> 而GPU的shader unit卻是比SPE更精簡的東西.
SPE其實與其說精不精簡，不如說平行度不太夠…..
不知道CELL3打不打算強化到8way SIMD，不過看來是不見得了。
> RV770只增加300M電晶體卻可以多了
> 800個SP(96個4+1D)和一堆TMU….
> 1個4+1D的US unit可能不到3M電晶體
> X1950的1個PS unit只要2M電晶體.
> (雖然這不含L1和register file.
> 但是那些是很多SP共用的.佔不了多少空間)
register file適用來對抗記憶體延遲用的，和快取一樣都要隨著需求增加，也要隨著單元數量增加，以確保平行度。
所以雖說是共用的，但是我想小不到哪邊去….
以規模來說，G8x/G9x class的TPC有16D，8TMU，和64KB的register file，估計約50M電晶體，但是論電晶體來說core2 duo只有1/3的數量，die size卻大得多…. 所以x86電晶體電晶體數量可能沒那麼複雜，但是wiring的複雜度卻可能造成很大的規模。（主要是OOOE)
反過來說，相對起來簡化很多的Larrabee CPU core當然會稀釋這個差距。
> 而現在高時脈CPU core隨便都是幾十M電晶體起跳.
> 就算時脈高一倍,vector unit寬了4倍.
> 還是很難和純種GPU競爭flops.
我是覺得應該用TPC啦，array之類的單位去和CPU core比較啦….
比方說R6x0/R7x0應該是80sp為單位，那其實也沒小到哪去。
用SP來當core數量顯然是很行銷的寫法….
提一個離題的東西
nV努力發展GPGPU到最後
最得利的會不會是AMD的Fusion？
提一個離題的東西
nV努力發展GPGPU到最後
最得利的會不會是AMD的Fusion？
eDRAM能到1TB/s？Xenos的频宽也才是256GB/s而已耶，在说eDRAM的容量也太小了吧~这么小的容量能做什么呢？
eDRAM能到1TB/s？Xenos的频宽也才是256GB/s而已耶，在说eDRAM的容量也太小了吧~这么小的容量能做什么呢？
>eDRAM能到1TB/s？Xenos的频宽也才是256GB/s而已耶，在说eDRAM的容量也太小了吧~这么小的容量能做什么呢？
8年翻4倍是有難度的事情么？
而且，2013年做128~256MB的edram應該不會過100mm^2。
>這不太一樣.
>CELL的PPE和SPE是不同的架構.
>SPE不能跑PPE的code.
>Larrabee的16way SIMD只是增加X86指令而已.
>它仍是可以跑基本的X86 code.
>它的開發工具compiler很可能只是更新版本而已.
>不是另外一個開發環境.
Cell同樣可以跑PowerPC指令集
只不過不能發揮8倍的性能。
當然可以跑X86，但是光是X86性能只有多少？這點跟Cell不是雷同的么？
而且16D SIMD不是X86正式擴展呀，Intel目前計劃中的幾個CPU根本不用的呀。
上次跟Eji談到這個結論是SPE是靠DMA來交換數據的，不如Larrabee的快取一致性實現效率高和開發便利。
>eDRAM能到1TB/s？Xenos的频宽也才是256GB/s而已耶，在说eDRAM的容量也太小了吧~这么小的容量能做什么呢？
8年翻4倍是有難度的事情么？
而且，2013年做128~256MB的edram應該不會過100mm^2。
>這不太一樣.
>CELL的PPE和SPE是不同的架構.
>SPE不能跑PPE的code.
>Larrabee的16way SIMD只是增加X86指令而已.
>它仍是可以跑基本的X86 code.
>它的開發工具compiler很可能只是更新版本而已.
>不是另外一個開發環境.
Cell同樣可以跑PowerPC指令集
只不過不能發揮8倍的性能。
當然可以跑X86，但是光是X86性能只有多少？這點跟Cell不是雷同的么？
而且16D SIMD不是X86正式擴展呀，Intel目前計劃中的幾個CPU根本不用的呀。
上次跟Eji談到這個結論是SPE是靠DMA來交換數據的，不如Larrabee的快取一致性實現效率高和開發便利。
> eDRAM能到1TB/s？Xenos的频宽也才是256GB/s而已耶，在说eDRAM的容量也太小了吧~这么小的容量能做什么呢？
Xenos的eDRAM和main core中間只有32GB/s的頻寬….裡面做8ROP的動作做完之後送回結果的關係所以才有”等效256GB/s”…..那算是一種accerator。
所以通常來說一般認定360的記憶體頻寬就是那25.6GB/s的GDDR3。
> eDRAM能到1TB/s？Xenos的频宽也才是256GB/s而已耶，在说eDRAM的容量也太小了吧~这么小的容量能做什么呢？
Xenos的eDRAM和main core中間只有32GB/s的頻寬….裡面做8ROP的動作做完之後送回結果的關係所以才有”等效256GB/s”…..那算是一種accerator。
所以通常來說一般認定360的記憶體頻寬就是那25.6GB/s的GDDR3。
＞＞應該用TPC啦，array之類的單位去和CPU core
＞＞比較啦….比方說R6x0/R7x0應該是80sp為單位，
＞＞那其實也沒小到哪去。
＞＞用SP來當core數量顯然是很行銷的寫法….
若拿G80的SP來看可能不太適合,
因為它是scalar架構.本來就比較龐大,
R7x0則和Larrabee一樣是n way vector ALU,
都是要衝高peak輸出的設計,比較有可比性.
不過TPC的ALU數量卻遠超過Larrabee的core….
TPC的80SP（16個4D+1D）是160flops…
vec16的32flops實在差太多即使時脈較高也無法彌補.
應該以同樣計算能力下的電晶體使用量來看,
一個R7x0 TPC計算能力,已經相當於2.5個
2Ghz larrabee的core.
兩者用的電晶體卻可能差不多,甚至TPC更少,
因為還要扣掉TPC裡一些fixed function的單位.
register file和cache尺寸除以R7x0的160個4D+1D.
其實平均每個5D vector unit分不到幾k而已.
雖然GPU的register和cache一直有增加,
但vector ALU也一直增加,平均每個vector ALU消費
的register和cache其實一直都很少.
＞＞應該用TPC啦，array之類的單位去和CPU core
＞＞比較啦….比方說R6x0/R7x0應該是80sp為單位，
＞＞那其實也沒小到哪去。
＞＞用SP來當core數量顯然是很行銷的寫法….
若拿G80的SP來看可能不太適合,
因為它是scalar架構.本來就比較龐大,
R7x0則和Larrabee一樣是n way vector ALU,
都是要衝高peak輸出的設計,比較有可比性.
不過TPC的ALU數量卻遠超過Larrabee的core….
TPC的80SP（16個4D+1D）是160flops…
vec16的32flops實在差太多即使時脈較高也無法彌補.
應該以同樣計算能力下的電晶體使用量來看,
一個R7x0 TPC計算能力,已經相當於2.5個
2Ghz larrabee的core.
兩者用的電晶體卻可能差不多,甚至TPC更少,
因為還要扣掉TPC裡一些fixed function的單位.
register file和cache尺寸除以R7x0的160個4D+1D.
其實平均每個5D vector unit分不到幾k而已.
雖然GPU的register和cache一直有增加,
但vector ALU也一直增加,平均每個vector ALU消費
的register和cache其實一直都很少.
其實Xenos的32GB/sec應該看作內部通道,
用來從PS把color和Z,”單向”傳到ROP用的,
只是Xenos竟然把ROP做到另一個晶片,
其他GPU也有這樣的東西,只是做法不同(做在內部).
對ROP來說,它用的記憶體頻寬就是256GB/sec
GPU內部有一堆這種bus….只是這一個放外面.
如果把ROP和Edram整合到main core就不會那麼奇怪了.
過去Voodoo系列還有把TMU也放外面.
這種放外面的Internal Bus其實不太會有頻寬問題.
頻寬不容易搞定的是連接”外部記憶體”的bus.
其實Xenos的32GB/sec應該看作內部通道,
用來從PS把color和Z,”單向”傳到ROP用的,
只是Xenos竟然把ROP做到另一個晶片,
其他GPU也有這樣的東西,只是做法不同(做在內部).
對ROP來說,它用的記憶體頻寬就是256GB/sec
GPU內部有一堆這種bus….只是這一個放外面.
如果把ROP和Edram整合到main core就不會那麼奇怪了.
過去Voodoo系列還有把TMU也放外面.
這種放外面的Internal Bus其實不太會有頻寬問題.
頻寬不容易搞定的是連接”外部記憶體”的bus.
GPU是很多很多pipeline的硬體,
不同pipeline像流水線一樣把資料傳下去,
中間有FIFO buffer做緩衝.
一直傳到最後的ROP,然後讀寫記憶體.
如果GPU有8ROP, color+Z至少就要
64bit X 8ROP X 500Mhz=32GB/sec的內部bus.
才能把8組Pixel資料傳給8個ROP.
所以RSX也有這個bus,只是它做在裡面.
由於Pixel傳輸能力是受限於ROP數量而非bus頻寬,
做大了也不會增加效能只是浪費電晶體.
就算把Xenos的那32GB/sec變成100GB/sec
也不會比較好,因為ROP還是只吃8個pixel.
只會用到32GB/sec而已.
所以RSX那個到ROP的內部bus頻寬八成也是3x GB/sec.
兩者沒有不同,只是Xenos的Pixel要跑比較遠,
不過反正”傳給ROP的東西不需要讀回來”,
那是單向的流水線,所以Pixel跑比較遠
造成的Latency根本無所謂,不會影響輸出能力.
做在外面的缺點是成本較高.
EDram雖然會越做越大,但是由於frame buffer(MSAA)
也越來越大, 所以EDram還是很不夠用.
要讓Edram實用就得Tile化…..
或是像PSP,解析度不高又不做AA,剛好可以放進EDram
GPU是很多很多pipeline的硬體,
不同pipeline像流水線一樣把資料傳下去,
中間有FIFO buffer做緩衝.
一直傳到最後的ROP,然後讀寫記憶體.
如果GPU有8ROP, color+Z至少就要
64bit X 8ROP X 500Mhz=32GB/sec的內部bus.
才能把8組Pixel資料傳給8個ROP.
所以RSX也有這個bus,只是它做在裡面.
由於Pixel傳輸能力是受限於ROP數量而非bus頻寬,
做大了也不會增加效能只是浪費電晶體.
就算把Xenos的那32GB/sec變成100GB/sec
也不會比較好,因為ROP還是只吃8個pixel.
只會用到32GB/sec而已.
所以RSX那個到ROP的內部bus頻寬八成也是3x GB/sec.
兩者沒有不同,只是Xenos的Pixel要跑比較遠,
不過反正”傳給ROP的東西不需要讀回來”,
那是單向的流水線,所以Pixel跑比較遠
造成的Latency根本無所謂,不會影響輸出能力.
做在外面的缺點是成本較高.
EDram雖然會越做越大,但是由於frame buffer(MSAA)
也越來越大, 所以EDram還是很不夠用.
要讓Edram實用就得Tile化…..
或是像PSP,解析度不高又不做AA,剛好可以放進EDram
>>SPE是靠DMA來交換數據的，
>>不如Larrabee的快取一致性實現效率高和開發便利
例如gather 和 scatter,
前者是從任意記憶體位置讀取許多資料,
後者是從任意記憶體位置寫入許多資料,
而SPE處理這兩種計算都很麻煩,
因為LS就只有256KB,還要double buffer….
所以往往麻煩的是資料結構.
那不是想改就能改的.
要讓gather 和 scatter都限制在100多KB以內.
萬一資料沒辦法這樣改,那就只好讓PPE去算吧.
所以很多工作都是擠到PPE那裡.
SPE在處理頂點資料很有效率,因為頂點沒有
gather 和 scatter的問題,….讀取-計算-寫回.
頂點處理是stream processing的最佳範例.
(GPU就很適合gather,因為TMU就是設計來從很大的資料
陣列(Texture)中搜尋任意資料(texel).)
有cache就方便太多了,CPU可以任意讀寫全部主記憶體.
Latency問題讓cache和prefetcher和thread去搞定.
>>SPE是靠DMA來交換數據的，
>>不如Larrabee的快取一致性實現效率高和開發便利
例如gather 和 scatter,
前者是從任意記憶體位置讀取許多資料,
後者是從任意記憶體位置寫入許多資料,
而SPE處理這兩種計算都很麻煩,
因為LS就只有256KB,還要double buffer….
所以往往麻煩的是資料結構.
那不是想改就能改的.
要讓gather 和 scatter都限制在100多KB以內.
萬一資料沒辦法這樣改,那就只好讓PPE去算吧.
所以很多工作都是擠到PPE那裡.
SPE在處理頂點資料很有效率,因為頂點沒有
gather 和 scatter的問題,….讀取-計算-寫回.
頂點處理是stream processing的最佳範例.
(GPU就很適合gather,因為TMU就是設計來從很大的資料
陣列(Texture)中搜尋任意資料(texel).)
有cache就方便太多了,CPU可以任意讀寫全部主記憶體.
Latency問題讓cache和prefetcher和thread去搞定.
需要好好計算一下：
根據Larrabee: A Many-Core x86 Architecture for Visual Computing的介紹，制程相同條件下，L2 4MB的Core 2 duo的面積與10個x86/16-way-simd-vpu+4MB L2基本相同。
如果允許假定larrabee也比較接近這個比例的話
可計算一下面積： L2 4MB的Core 2 duo肯定是65nm conroe的規格，面積為142mm ^2
10個x86&vpu核心+4MB L2=142mm
如果是65nm制程下，16個核心x86&vpu核心+4MB L2的面積=？
如果是65nm制程下，32個核心x86&vpu核心+8MB L2的面積=？
先計算4MB L2的面積size，conroe的4M L2面積約65mm^2。
然後扣除L2面積後，除以核心數量得到一個x86&vpu核心的面積是=(142-65)/10=7.7mm^2。
16個核心x86&vpu核心+4MB L2的面積=16X7.7+65=190mm^2
而32核心8M L2應該需要加倍380mm^2。
所以45nm制程下，面積還可以縮小0.6到0.5之間，
也就是說32核心8M L2面積約為200mm^2上下
考慮實際情況，由於還有固定功能單元需要更多面積，
32核心larrabee應該在270mm^2上下。
而Paper裏面說vpu與vector寄存器組的面積占CPU core的1/3， 要是推算一下， vector寄存器組的容量有可能會達到16KB以上。
(The VPU and its registers are approximately one third the area of the CPU core)
或者簡單的說：
一個x86&vpu core使用65nm制程需要面積約為7～8mm^2，
如果使用45nm制程就需要3～4mm^2的面積。
65nm制程GTX280 面積576mm^2，浮點峰值620Gflops，晶體管14億
65nm的10核x86/vpu@2GHz,面積140mm^2，浮點峰值640Gflops，晶體管?
55nm的rv770,面積260mm^2，浮點峰值960Gflops，晶體管?
計算密度的統計結果是：
Gflops/面積
65nm制程GTX280 1.076 Gflops/mm2
65nm的10核x86 4.57 Gflops/mm2
55nm的rv770 3.69 Gflops/mm2
如果可以歸一化就是
GTX280 1
x86/vpu 4.2
rv770 2.5
所以制程相同，面積相同時的計算密度，x86/vpu浮點峰值要高出GTX200約4倍，而比rv770高約4.2/2.5=1.7倍。
如果larrabee效能是GTX280的1/10，那么就需要面積大2.5倍才能超過GTX280的實際性能。
而rv770效能僅有GXT280的1/3，所以需要面積大20%才能超過GTX280的實際性能。
所以，larrabee唯一取勝的機會就是制程始終領先1代以上。
65nm制程GTX280 面積576mm^2，浮點峰值620Gflops，晶體管14億
65nm的10核x86/vpu@2GHz,面積140mm^2，浮點峰值640Gflops，晶體管?
55nm的rv770,面積260mm^2，浮點峰值960Gflops，晶體管?
計算密度的統計結果是：
Gflops/面積
65nm制程GTX280 1.076 Gflops/mm2
65nm的10核x86 4.57 Gflops/mm2
55nm的rv770 3.69 Gflops/mm2
如果可以歸一化就是
GTX280 1
x86/vpu 4.2
rv770 2.5
所以制程相同，面積相同時的計算密度，x86/vpu浮點峰值要高出GTX200約4倍，而比rv770高約4.2/2.5=1.7倍。
如果larrabee效能是GTX280的1/10，那么就需要面積大2.5倍才能超過GTX280的實際性能。
而rv770效能僅有GXT280的1/3，所以需要面積大20%才能超過GTX280的實際性能。
所以，larrabee唯一取勝的機會就是制程始終領先1代以上。
見無我覺得你算得有點歡樂….XDa
只算MAD不算MUL我覺得還可以接受，可是GTX280感覺很大的原因是因為ROP規模放大，然後ROP規模放大又是和只有GDDR3有關係，所以要擴大記憶體頻寬只好連ROP一起做大，然後面積擴大大多是這樣換來的，所以今天NVIDIA其實只要換成GDDR5，晶片規模很快就可以縮小。
—-
Larrabee需要維持領先製程一代才能夠取勝，你為什麼不想成”因為我們(Intel)製程能夠持續領先一代”，所以才那樣設計Larrabee？XD
現況繼續下去的話就會只剩Intel一個有做到垂直整合而已了，然後fabless和垂直整合之間的製造能力差異只會更大。
我只是覺得他們好像對自己的cache太有自信了，cache自己的交換行為也是有overhead的啊。
見無我覺得你算得有點歡樂….XDa
只算MAD不算MUL我覺得還可以接受，可是GTX280感覺很大的原因是因為ROP規模放大，然後ROP規模放大又是和只有GDDR3有關係，所以要擴大記憶體頻寬只好連ROP一起做大，然後面積擴大大多是這樣換來的，所以今天NVIDIA其實只要換成GDDR5，晶片規模很快就可以縮小。
—-
Larrabee需要維持領先製程一代才能夠取勝，你為什麼不想成”因為我們(Intel)製程能夠持續領先一代”，所以才那樣設計Larrabee？XD
現況繼續下去的話就會只剩Intel一個有做到垂直整合而已了，然後fabless和垂直整合之間的製造能力差異只會更大。
我只是覺得他們好像對自己的cache太有自信了，cache自己的交換行為也是有overhead的啊。
請教一下
gt200的rop和頻寬都加倍了
為啥在aa衝擊的幅度和rv770差不多
請教一下
gt200的rop和頻寬都加倍了
為啥在aa衝擊的幅度和rv770差不多
從底層測試看來雙方的ROP吞吐能量差不多(RV6x0的時代是G8x比較好)，RV770改善的主要是MRT的MSAA性能，高過G8x/G9x/GT200約一倍。
所以記憶體頻寬(含比例)類似的時候，下降幅度會是類似的；當然如果GT200用GDDR5的話，那記憶體頻寬增加後就不見得如此了。
從底層測試看來雙方的ROP吞吐能量差不多(RV6x0的時代是G8x比較好)，RV770改善的主要是MRT的MSAA性能，高過G8x/G9x/GT200約一倍。
所以記憶體頻寬(含比例)類似的時候，下降幅度會是類似的；當然如果GT200用GDDR5的話，那記憶體頻寬增加後就不見得如此了。
>我只是覺得他們好像對自己的cache太有自信了，cache自己的交換行為也是有overhead的啊。
GTX280的TPC有64KB的register file，10个TPC就是640KB的register file
如果larrabee一个核心有16KB的vpu register file，那么32核心就是512KB的register file
還有由于larrabee的vpu具有格式轉換能力，larrabee的32KB L1D是存放原始數據格式，而GPU的register好像是FP32格式。
所以32KB的L1D容量相當于64-128KB的reg。 3個核心的L1D就是200-360KB的容量。
>我只是覺得他們好像對自己的cache太有自信了，cache自己的交換行為也是有overhead的啊。
GTX280的TPC有64KB的register file，10个TPC就是640KB的register file
如果larrabee一个核心有16KB的vpu register file，那么32核心就是512KB的register file
還有由于larrabee的vpu具有格式轉換能力，larrabee的32KB L1D是存放原始數據格式，而GPU的register好像是FP32格式。
所以32KB的L1D容量相當于64-128KB的reg。 3個核心的L1D就是200-360KB的容量。
說不定 AMD 最後會把顯卡拿回他們自己的廠去做也不一定。
短期內製程發展速度的差異應該還不會太大，但在進到23nm 時應該會卡上個一陣子，到時問題可能就不是架構好壞了。
說不定 AMD 最後會把顯卡拿回他們自己的廠去做也不一定。
短期內製程發展速度的差異應該還不會太大，但在進到23nm 時應該會卡上個一陣子，到時問題可能就不是架構好壞了。
我覺得GPU很快就會進入不是架構決定的世界…. 就像CPU一樣。
我覺得GPU很快就會進入不是架構決定的世界…. 就像CPU一樣。
那由什么決定？
誰的制程先進，相同的size誰就能放置更多的logic，誰就能性能更強–前提是設計人員水平合格–架構還是要基本合格才行。
那由什么決定？
誰的制程先進，相同的size誰就能放置更多的logic，誰就能性能更強–前提是設計人員水平合格–架構還是要基本合格才行。
fabless 支撐起來的 GPU 發展能走到何時的確是令人玩味，當製程研發已經非單純的縮小就能改變時，或是說當無法有效縮小時，才是真正挑戰的開始。進到 45nm 時 high-k matel 導入，過一陣子說不定導線挖洞，超薄 SOI 製程，多層堆疊，或是更多想不到的壓箱寶都在產品效能進步的壓力下被拿出來，究竟有那間 fabless 能在製程上追上 IBM 跟 Intel 的腳步呢?
但不管怎麼說這好日子應該還能維持個 3~4 年左右，之後就看誰家養的物理/材料人材夠多了……
fabless 支撐起來的 GPU 發展能走到何時的確是令人玩味，當製程研發已經非單純的縮小就能改變時，或是說當無法有效縮小時，才是真正挑戰的開始。進到 45nm 時 high-k matel 導入，過一陣子說不定導線挖洞，超薄 SOI 製程，多層堆疊，或是更多想不到的壓箱寶都在產品效能進步的壓力下被拿出來，究竟有那間 fabless 能在製程上追上 IBM 跟 Intel 的腳步呢?
但不管怎麼說這好日子應該還能維持個 3~4 年左右，之後就看誰家養的物理/材料人材夠多了……
如果類似larrabee此類架構–幾十個核心&16-way-simd&cache，合理改進后(例如改用shader ISA/HW ROP)其效能可以優于rv770的話， 應該就game over了。
計算密度與效能兩者都是關鍵因素，GTX280的效能好，而larrabee的密度高,rv770的計算密度也較高但是低于larrabee。所以larrabee效能到底如何，就是關鍵了。 類似larrabee架構并非一無是處， 而是需要重視， 如果改進后效能確實可以提高很多的話， 那就game over了。
如果類似larrabee此類架構–幾十個核心&16-way-simd&cache，合理改進后(例如改用shader ISA/HW ROP)其效能可以優于rv770的話， 應該就game over了。
計算密度與效能兩者都是關鍵因素，GTX280的效能好，而larrabee的密度高,rv770的計算密度也較高但是低于larrabee。所以larrabee效能到底如何，就是關鍵了。 類似larrabee架構并非一無是處， 而是需要重視， 如果改進后效能確實可以提高很多的話， 那就game over了。
G8x的效率好有很大的關聯應該與Gather & scatter有關，而這個功能Larrabee有；至於share memory和cache，其實我覺得這比較就和CELL一樣，因為CELL也是走share memory(local store，以sctatch pad memory為主要觀念)的做法。
重點是cache比較可以讓programmer在寫程式的時候可以不需要替一些奇怪的資料結構如何適應硬體煩心，不過反過來說就是完全依靠cache了，而cache的行為顯然也不是完美的。
所以Intel 一開始的狀況，我覺得是成也cache敗也cache…. 不過即使一開始不好，製程磨下去我想還是會贏就是了，現在的問題真的是”一開始會怎樣”而已。
G8x的效率好有很大的關聯應該與Gather & scatter有關，而這個功能Larrabee有；至於share memory和cache，其實我覺得這比較就和CELL一樣，因為CELL也是走share memory(local store，以sctatch pad memory為主要觀念)的做法。
重點是cache比較可以讓programmer在寫程式的時候可以不需要替一些奇怪的資料結構如何適應硬體煩心，不過反過來說就是完全依靠cache了，而cache的行為顯然也不是完美的。
所以Intel 一開始的狀況，我覺得是成也cache敗也cache…. 不過即使一開始不好，製程磨下去我想還是會贏就是了，現在的問題真的是”一開始會怎樣”而已。
>>計算密度與效能兩者都是關鍵因素，
>>GTX280的效能好，而larrabee的密度高
根據AMD PDF檔裡標示的die photo.
160個5way SIMD core, 40個TMU.
各佔36%,14%的面積,
估計1個5way SIMD core約2.2M電晶體
(已含register file).
1個TMU(4 tap per cycle)約3.5M電晶體.
(已含texture cache)
由於ALU:Tex ratio是可以提昇的,
RV770要再增加運算密度也很簡單.
目前是ALU:Tex=4:1 (以前X1950是3:1)
以8:1去做,單核2.4Tflops只增加約333M電晶體.
如果只想拼運算密度,GPU可以衝到很高.
因為SIMD core很精簡,可以放一大堆.
現階段不做的原因,是要適應目前的shader code,
過高的ALU只會卡在TMU不足而發揮不出來.
ALU:Tex ratio要隨軟體發展,恰當的分配,
才不會浪費硬體資源.
>>計算密度與效能兩者都是關鍵因素，
>>GTX280的效能好，而larrabee的密度高
根據AMD PDF檔裡標示的die photo.
160個5way SIMD core, 40個TMU.
各佔36%,14%的面積,
估計1個5way SIMD core約2.2M電晶體
(已含register file).
1個TMU(4 tap per cycle)約3.5M電晶體.
(已含texture cache)
由於ALU:Tex ratio是可以提昇的,
RV770要再增加運算密度也很簡單.
目前是ALU:Tex=4:1 (以前X1950是3:1)
以8:1去做,單核2.4Tflops只增加約333M電晶體.
如果只想拼運算密度,GPU可以衝到很高.
因為SIMD core很精簡,可以放一大堆.
現階段不做的原因,是要適應目前的shader code,
過高的ALU只會卡在TMU不足而發揮不出來.
ALU:Tex ratio要隨軟體發展,恰當的分配,
才不會浪費硬體資源.
>現階段不做的原因,是要適應目前的shader code,
>過高的ALU只會卡在TMU不足而發揮不出來.
>ALU:Tex ratio要隨軟體發展,恰當的分配,
>才不會浪費硬體資源.
其實這點在Larrabee上也有效：Larrabee的說法主要是ROP和ALU的全部軟體化來減少瓶頸，但是TMU目前還沒辦法軟體化，所以TMU和ALU的比例其實即使是到了Larrabee仍然是固定的。(TMU和CPU core總量的比例)
反過來說，x86 core本身不再增加規模，光是Vector unit本身擴增的話，再過一段時間也許x86對Larrabee就不是個很大的負擔….延遲隱藏能力也只和cache容量有關。
>現階段不做的原因,是要適應目前的shader code,
>過高的ALU只會卡在TMU不足而發揮不出來.
>ALU:Tex ratio要隨軟體發展,恰當的分配,
>才不會浪費硬體資源.
其實這點在Larrabee上也有效：Larrabee的說法主要是ROP和ALU的全部軟體化來減少瓶頸，但是TMU目前還沒辦法軟體化，所以TMU和ALU的比例其實即使是到了Larrabee仍然是固定的。(TMU和CPU core總量的比例)
反過來說，x86 core本身不再增加規模，光是Vector unit本身擴增的話，再過一段時間也許x86對Larrabee就不是個很大的負擔….延遲隱藏能力也只和cache容量有關。
ALU:TEX的比例在GPU上長期來看不是固定的,
而是隨軟體演進慢慢增加.
從以前0.5:1到1:1到2:1…到4:1
目前最新的GPU是4:1也許2010要5:1~6:1以上比較恰當.
如果Larrabee想固定某個ALU:TEX比例,
只增加core和時脈,那麼就會變成,
比例定的過高會浪憤ALU的電晶體(受限於TMU不足)
比例定的過低會浪憤TMU的電晶體(受限於ALU不足)
對2009遊戲恰當的比例,拿到2012年卻是TMU過多…
所以Larrabee也沒辦法固定一個ALU:TEX比例.
恐怕每1~2年要review一次目前的配置比例是否符合現實.
對x86 core和TMU數量比例做修正.
突然想到…..都已經有測試數據了.
Larrabee為什麼不公佈TMU數量?
如果TMU數量不確定那是怎麼測出數據的?
難道那個數據真是假設將來TMU和頻寬一定夠用的
模擬情況…..XD
ALU:TEX的比例在GPU上長期來看不是固定的,
而是隨軟體演進慢慢增加.
從以前0.5:1到1:1到2:1…到4:1
目前最新的GPU是4:1也許2010要5:1~6:1以上比較恰當.
如果Larrabee想固定某個ALU:TEX比例,
只增加core和時脈,那麼就會變成,
比例定的過高會浪憤ALU的電晶體(受限於TMU不足)
比例定的過低會浪憤TMU的電晶體(受限於ALU不足)
對2009遊戲恰當的比例,拿到2012年卻是TMU過多…
所以Larrabee也沒辦法固定一個ALU:TEX比例.
恐怕每1~2年要review一次目前的配置比例是否符合現實.
對x86 core和TMU數量比例做修正.
突然想到…..都已經有測試數據了.
Larrabee為什麼不公佈TMU數量?
如果TMU數量不確定那是怎麼測出數據的?
難道那個數據真是假設將來TMU和頻寬一定夠用的
模擬情況…..XD
只是TMU沒辦法拿掉,GPU就永遠要頻繁的修改硬體配置.
以適應不同時期的軟體需求.
Larrabee恐怕也很難跳脫.
不改的只有shader ALU的native指令集而已.
從RV770和X1950的shader core的尺寸來看.
其實SM3.0的PS core 2M,和SM4.0的US core 2.2M,
在電晶體上差距不到10%.
大概是表示PS3.0的core已經完備大部分alu指令了,
之後都只是小增改和US化而已.
DX11的HS和DS可能也只用到原本SM4.0的指令,不必再改.
只是TMU沒辦法拿掉,GPU就永遠要頻繁的修改硬體配置.
以適應不同時期的軟體需求.
Larrabee恐怕也很難跳脫.
不改的只有shader ALU的native指令集而已.
從RV770和X1950的shader core的尺寸來看.
其實SM3.0的PS core 2M,和SM4.0的US core 2.2M,
在電晶體上差距不到10%.
大概是表示PS3.0的core已經完備大部分alu指令了,
之後都只是小增改和US化而已.
DX11的HS和DS可能也只用到原本SM4.0的指令,不必再改.
所以Larrabee的TMU和CPU core都是在ringbus上可以輕易地追加；問題是頻寬夠不夠。
不過照理來說應該是無關就是了….
此外，Intel似乎在模擬上有那種…. 只做到L1模擬那層的狀況，那記憶體系統就是完美的啦XD
所以Larrabee的TMU和CPU core都是在ringbus上可以輕易地追加；問題是頻寬夠不夠。
不過照理來說應該是無關就是了….
此外，Intel似乎在模擬上有那種…. 只做到L1模擬那層的狀況，那記憶體系統就是完美的啦XD