和我預估的改變方向很類似,不過Tex比預期還多.

之前GF100 SM的TEX單位,反而比GT200的TPC還少.
在繪圖時有時會變成弱點.
GF104最大的改變其實是TEX爆增兩倍......
雖然只有2GPC卻有64Tex

GF100原本SP:TEX是1:8,現在GF104是1:6.
所以Texturing能力變超強..
(在算PostEffect方面會很快.)
Fermi在Shader運算量的先天劣勢,
靠Tex固定管線效能可以追回不少.

不過GF104 register file偏低是個疑慮
從G92以來每ALU配4KB的公式第一次被打破了.
GPU是非常依賴thread,而register file尺寸
決定可以有多少thread......
不管硬體有多少Wrap,如果register file不夠.
就會限制了thread的數量....

不知道DP那1/12的倍精度是怎麼來的?
到底哪些單位在算DP?
DP應該不會真的拿掉,畢竟本來就共用線路.
只是大部份不做測試直接關掉.

>>用同樣的SM結構推高階的話就非常夠格稱為
>>「Fermi2」了吧

問題是這版本要做4GPC.....那就是4000M電晶體.
應該會超過光罩上限的600mm2....
就算能做,良率也會低到吐血.

3GPC的話,因為要以GPC為單位來堆積.
那模組可能沒辦法拼成方方正正的.....
所以其實可能沒辦法往上推高階.
不過砍一半做192SP/128bit倒很有機會.

它Die Size應該類似RV870.
如果能控制在350mm2以內就很有競爭力
但其384SP版應該也跑不贏完整的RV870.
畢竟RV870裝了80TEX unit,320SIMD
連GF100都贏的很吃力.

只能確定GF104會提升Fermi架構的繪圖競爭力.
但重演G92恐怕有困難.
畢竟對手不是R6x0那種架構半成品.
RV870已經上市8個月,照慣例ATI的新改版
大概4個月以內會上市,以趕上年底商戰.
GF104的對手應該很快就知道了.

>>從G92以來每ALU配4KB的公式

應該是從G80以來...

GF104即始只開336SP,
每SP也只配到3KB 的register file.
如果真的開到384SP,問題更大....
某些比較佔register的thread恐怕有藏不住latency
的可能性..

费米割掉一半.....看来打不过RV870嘛 囧

那就让SM吃胖点,变成强袭型SM....好像可以一战了.

那胖胖的芯片面积究竟是多大 囧

唉~~老實說，
看了Anandtech後，
我才知道GF100的SM還有16個Interpolation SFUs，
我以為GF100的4個SFU會包辦全部，
沒想到還有內插運算專用的SFU，
難道GT200以前也有這樣搞？
另外Texture Units的TA：TF比例方面比G80還誇張，
G80的TA：TF是1：2，
G92、GT200則是1：1，
GF100卻為1：4...比G80的比例還差更多，
話說後藤大叔給的是1：1的資料，
到底誰正確？
如果是Anandtech正確的話，
GF100與下個接替者會和"G80 > G92"發生一樣的變更嗎？

>>不知道DP那1/12的倍精度是怎麼來的?
>>到底哪些單位在算DP?
>>DP應該不會真的拿掉,畢竟本來就共用線路.
>>只是大部份不做測試直接關掉.
Anandtech給的答案是3組CUDA Cores中只有1組可算FP64，
還有其效能只有FP32的1/4，
而且Anandtech還強調其餘2組CUDA Cores是更小的CUDA Core，
至於Anandtech的資料有多準確，
小弟我就不知道了。

總覺得GF100的接班人如果未出現在製程重大突破(28nm以下吧？)，
G80 > G92的戲碼有可能看得到，
到時候可能加個Dispatch Unit和SFU、改TA：TF為1：1，
最後砍ROP數量後，
再藉著製程的些微優勢增加時脈...

我想對沒錢買GTX460的我而言，
還是別想太多好了XD

>>3組CUDA Cores中只有1組可算FP64，
>>還有其效能只有FP32的1/4，
>>其餘2組CUDA Cores是更小的CUDA Core，

...若Fermi可以算FP64的CUDA core就有兩種.
而還有一種不能算FP64的CUDA core....
......這樣架構好像搞得太複雜了?

to WaffenSS兄：

關於register file的部分，因為GT200當初從G80的16sp變成24sp的時候有擴充，所以我想32sp -> 48sp還是會維持等倍擴充的。

這個擔心我先前在R520 to R580的時候也做過，但是實際上都有增加，所以SP數量和register file規模是完全連動的，增加50%的ALU就必然會增加50%的register file。

咦，不對，GF104還是只有32,768個thread？

>>......這樣架構好像搞得太複雜了?

waffenss兄不用想得太複雜，
反正想簡單點，
不是NV用軟體屏蔽成FP32的1/4效能的FP64或無FP64 CUDA Core，
就是已經準備好一系列硬體的FP64效能的CUDA Core，
有1/2、1/4...等，
甚至更低的都有可能有，
當然軟體和硬體混著用也有可能。

所以呢...嗯~~！
好像越說越複雜XD

>>關於register file的部分，
>>因為GT200當初從G80的16sp變成24sp的時候有擴充，
>>所以我想32sp -> 48sp還是會維持等倍擴充的。

Eji大，
我想waffenss兄是看到下面的後藤大叔的圖才會有此反應吧？

http://pc.watch.impress.co.jp/...aigai-08.jpg.html

這應該是對48wrap/SM的GF104所做的決定吧？

>>咦，不對，GF104還是只有32,768個thread？

Eji大想說的是32768個register嗎？

其實 registers/ALU 意義不大，真正的問題應該是 registers/thread，因為 thread 之間不能共用 register。比如說，在 G8X/G9X 上（有 8192 registers），若同一個 block 內有 256 threads，則每個 thread 只能分到 32 registers。

G8X/G9X/GT200 若要完全隱藏 ALU latency（即下一個指令立刻使用到前一個指令的計算結果），通常需要至少 6 warps，也就是 192 threads。在 GF100 上則是 11 warps，將近兩倍。但是因為 GF100 的 register 數目是 GT200 的兩倍，因此 register 的壓力並沒有增加（反而稍微減少一些）。

GF104 則是一個比較有趣的問題。因為它有所謂的 "superscalar" 執行，所以如果兩個相鄰指令有相依性，則執行效率會等同於只有 32 SP（而非 48 SP）。所以，它需要的 thread 數目其實不會比 GF100 多，因為如果有相依性，增加 thread 數目無法解決問題。所以，真正的問題是在於 compiler 為了避免相鄰指令有相依性，可能會需要增加 temp register 的使用量，這可能會使 register 的使用量提高。

>>因為它有所謂的 "superscalar" 執行，
>>所以如果兩個相鄰指令有相依性，
>>則執行效率會等同於只有 32 SP（而非 48 SP）。

總覺得有點像是將GT200以前的SFU的MUL拉出來，
再做成可獨立發動的FMAD放回GF100，
然後將issue方式更改...，
噹噹...完成了_A_a

話說小弟比較想知道GF104的1 warp scheduler 2 dispatch有需綁住某些架構嗎？
例如第1個warp scheduler只能同時dispatch CUDA Cores block1、CUDA Cores block2，
而第2個warp scheduler只能同時dispatch CUDA Cores block3、S/L、SFU、Interp、Tex其中2個。

現在從registers/thread可能看不出真正問題,
因為過去ALU數量和Register一直是成正比的,
比例沒有變過.
(SP數和ALU數不一定相等,因為有時有mini-ALU...)

registers數量雖然決定有多少thread能active.
但是真正消耗這些register的是ALU.
Thread只是提供被分配的register,不是使用者.
有多少ALU就需要準備多少register讓它放資料.

3D繪圖的thread切換時,原本的local變數
都需要暫存在register不能丟出去,因為還沒算完,
而Shader運算單位裡(SM)平行的ALU數量越多,
要保留的變數資料量就越大.
而這些就是消耗泛用的Register file,
同樣一個thread,SM16個SP和48個SP運算量不同,
需要的register數也不會一樣.

每個thread可分配多少Register
過去是吸收latency的主要參考數據,
但是ALU數量其實也是需要和Register成正比的,
所以ATI的小晶片thread不多,
卻需要NV幾倍的Register.
因為它的5D ALU,需要用更多Register暫存資料.
沒有投機取巧的方法可走.
這從registers/thread比例反而看不出來.
表面上ATI的thread有超多的register,
但是考慮其ALU龐大數量,就差不多了.

當registers/ALU改變時,
register pressure就不能以過去的數據來對比.
這時不能只看到registers/thread比例沒變.
並不是每個thread的可分配register數不變,
ALU就可以任意增加而不會影響到register消耗量.

表面上GF104和G80的thread數量相同,而RF是2倍......所以每個thread可分配register好像變多?
但是考慮到它SP數是三倍....ALU的輸入輸出暫存, register消耗量也會是三倍.
其實384SP版本效率不是很樂觀.

不過我覺得也許GF104的RF,不太可能像表上那麼少.
不知道後藤的數據是從哪來的....
1536KB才是比較合理的規畫.

為何 ALU 「輸出輸入暫存」會影響到暫存器使用？實際上是，暫存器的使用量，基本上就是 thread 數目乘上該 kernel 使用的暫存器數目（真正的公式比較複雜，可以在 CUDA programming guide 中查到）。由於 kernel 使用的暫存器數目和 kernel 有關，所以最重要的關鍵還是 thread 數目。

我也已經說過 thread 數目的確和 ALU 數目有關，因為 ALU 數目愈多，就可能會需要愈多的 thread 才能隱藏所有 latency，但是 ALU 的 latency 也可能減少，所以需要 hide 這個 latency 的 thread 數目可能會減少。以 G8X/G9X/GT200 和 GF100，一個是 6 warps（192 threads）另一個是 11 warps（352 threads），其實相差只有不到一倍。而 GF104 的情形，我也說了，增加 thread 數目對隱藏 ALU latency 無太大幫助。

要注意的是這個 thread 數目是強調「隱藏所有 ALU latency」。如果一個 kernel 並不需要隱藏這麼多 ALU latency，它可以用比較少的 thread 數目，而不會影響它的效率。比如說，假設一個 kernel 用到太多 register 以致於 256 threads 會超過 register file 大小，而必須使用 local memory，那麼減少到 128 threads，雖然可能使某些 ALU latency 無法完全隱藏，但是因為不需要使用 local memory，反而會比較快。

GF104 每個 SM 的暫存器數目和 GF100 一樣（至少如果 NVIDIA 沒唬爛），都是 32768 個，並沒有增加。

>>kernel 使用的暫存器數目和 kernel 有關

我不熟悉CUDA, 以GPU繪圖來說,
應該不可能ALU平行度增加而不需要增加RF.
繪圖中間資料都會放在General Purpose Register.
繪圖時的Shader kernel,
執行時是大量的ALU和大量的Tex平行處理.
這些單位運算到一半的中間資料該怎麼辦?
硬體總要找地方放吧?
所以ATI才需要搞這麼大的Register File.

以programming最佳化的眼光來看,
thread夠多,就能隱藏Latency....
但不能說ALU數愈多需要愈多的 thread.
而是SM越多才需要越多thread/Warp.
因為SM是各跑各的thread,
多SM只是把一SM的情形線性放大.
過去都是靠增加SM模組來增加ALU/SP.
所以ALU/RF/Thread比例不變,
但是現在GF104是例外.
它是SM數不變,但ALU數大增的方式.
狀況不同了.

先不要看多SM的情形,
我們簡化一下用一個SM的GPU情形來看.
假設我們設計一個gpu只有一組SM,
一個SM只跑一個kernel.但SM有512SP平行,
所有SP跑相同指令,類似超級寬的vector unit.
(所有SP跑同一個指令只是data不同)
那麼因這GPU同時只會有幾個warp x 32thread在運作.
即使512ALU這麼大的Shader unit,
理論上只要幾百個thread
就可以隱藏Tex指令的latency.
(因為SM只需要數百cycle就能隱藏記憶體存取)

但是它的register file
如果還是原本的1SM 16~32SP的小尺寸.
RF可能只夠1-2個thread的使用量.
這1SM會512SP的GPU根本沒辦法跑....
ALU數改變會直接影響硬體分配給kernel的register數.
而kernel的register數會影響實質可用的thread數.
所以ALU數明顯不同時,不能只看thread和SM數不變,
就認為kernel的register數也不會變.
ALU數量不同,compiler要分配的資源數就不一樣.

Anandtech有稍微提到這問題.
Compute performance on the GTX 460
may also be impacted by pressure on the registers and L1 cache:
NVIDIA increased the number of CUDA cores
per SM, but not the size of the Register
File or the amount of L1 cache/shared
memory, so there are now additional CUDA
cores fighting for the same resources

當然這只是worst case, 也許某些遊戲
每個shader thread都很簡單,
不必吃這麼多資源也不一定.....

SM有多少ALU,SM就必須提供相對的Register,
這是我個人的理解啦.
也許新的GPU有除了增加RF以外的做法?

我自己也比較傾向維持每個SP有4KB可用、384sp就搭1536KB給它的狀況就是了....

問題在於它不是和 ALU 的數目成正比，而是和 thread 數目成正比。在你所說的情形，要餵一個 512SP 的 SM，至少需要 512 threads 吧。如果這些 SP 的latency 都是 1 cycle，那其實 512 threads 也夠了。這樣一來，相對於 32 SP 但較高 latency 的 SM（因此也需要 512 threads）其實它們的暫存器使用量是一樣的。

真正的問題是在於，如果為了減少指令間的 dependency，compiler 可能會因此 compile 出使用更多暫存器的程式。比如說，同樣是

a = b + c + d + e

可以 compile 成（假設都是整數）

a = b + c
a = a + d
a = a + e

或

a = b + c
t = d + e
a = a + t

這樣可以減少 dependency，但是代價是多用一個暫存器 t。

在 GF104 之前的顯示晶片，這兩個程式的效率可能沒什麼差別（假設 threads 數目夠多，暫存器也夠多）。在 GF104 就不同了，第一個程式的效率會比較差，因為多出來的 ALU 是不能使用的。所以 compiler 會傾向產生第二個程式，這樣就會增加暫存器的使用量了。這就是我之前說的

"compiler 為了避免相鄰指令有相依性，可能會需要增加 temp register 的使用量，這可能會使 register 的使用量提高。"

理論上Compiler應該有辦法做到判斷主要運算瓶頸,
(它會知道每Thread要用多少RF=知道Thread是否足夠)
Register不足和ALU Bound可以用不同的最佳化方式.

在 GF104 之前的顯示晶片，compiler 可以儘量朝減少暫存器使用量的角度做。原因是，它不需要太在意指令相依性的問題，因為只要有足夠的 thread 數目就可以隱藏。另一方面，暫存器使用量愈少，可以同時執行的 thread 數目就愈多，因此很明顯的 compiler 應該儘可能減少暫存器使用量，而不用太在意相依性問題（雖然也有例外）。

但是 GF104 就不一樣了，如果照 NVIDIA 說法，它是需要注意指令相依性的（雖然目前有些測試結果似乎不完全顯示出這個現象…我想這還需要更多進一步的實驗，或是等 NVIDIA 有更完整的解釋，但 NVIDIA 到目前為止仍說 GF104 對開發者來說和 GF100 除了 SP 數目之外並無明顯差異），否則 SP 的利用率就會下降。最簡單的做法是不改變暫存器使用策略，而只是儘可能調整指令順序（簡單的說就是「軟體」做 out-of-order execution）。這樣能有一定的效果，不過要有最大的效果，還是要從 compiler 的策略上進行改變。

>>要餵一個 512SP 的 SM，至少需要 512 threads 吧

應該不是這樣,那是要看記憶體Latency.
單一SM的SP(ALU)數和thread數不必然成正比.

假設外部記憶體頻寬不是問題,
且一個thread能隱藏1cycle latency的話,
記憶體Latency有多少GPU Cycle,就需要多少thread.
如果記憶體Latency是128個GPU Cycle.
就最少需要128個thread.

而SM的SP數是32或512其實和thread數無直接關係.
因為只要一用Tex指令....
因為除了記憶體存取還有解壓縮和filtering....
基本就是上百cycle的idle
就算只有1SP的GPU也沒辦法只用1個thread來隱藏latency
會需要很多的thread.

但SP數直接牽涉到RF的數量需求.
1SP的GPU就可以用很少的RF來應付很多thread.

hotball大，
小弟我有個問題想提問，
就是a = b + c + d + e

compile 成

a = b + c
a = a + d
a = a + e

這個樣子，
按照hotball大的說法是GF104有1組CUDA Core不能用，
然而在GF100上也是在此時只能用2組CUDA Core中的1組而已嗎？

> 應該不是這樣,那是要看記憶體Latency.
> 單一SM的SP(ALU)數和thread數不必然成正比.

所以我說「至少」…
512 SP 若無 512 threads，那必然有某些 SP 會空著無法使用，不是嗎？
至於記憶體的 latency，它和「整體」的 thread 數量有關，而不是單一 SM。假如記憶體的 latency 是 500 cycles，那至少需要「總共」500 threads 才能隱藏。不管是一個 SM 有 512SP，還是 4 個 SM 有 64SP，都是至少 500 個 threads。

> 但SP數直接牽涉到RF的數量需求.
> 1SP的GPU就可以用很少的RF來應付很多thread.

這是不合理的。假設只有一個 SP，但是同時要跑 512 個 threads，它還是需要總共 512 * （每個 kernel 用到的暫存器數）的暫存器數。這和有 32 SP 但也是同時跑總共 512 threads 並無差別。

> 按照hotball大的說法是GF104有1組CUDA Core不能用，
> 然而在GF100上也是在此時只能用2組CUDA Core中的1組而已嗎？

GF100 兩個 warp scheduler 必然是處理不同的 warp（一個處理奇數號，一個處理偶數號），因此指令的相依性並無影響。

>>a = b + c + d + e可以 compile 成
>>a = b + c
>>a = a + d
>>a = a + e

指令Dependency應該也是可以靠多thread的切換,
例如每thread的指令1處理32pixel的a = b + c.
分成N個thread算完N x 32 pixel
算完N個thread再回第一個thread算a = a + d......
所以不必那麼在意dependency....
對GPU的compiler來說,
每ALU的register使用量越少越好.

VLIW的dependency則是另一種情形了....

>>512 SP 若無 512 threads，
>>那必然有某些 SP 會空著無法使用，不是嗎？

不是吧,
以1SM/512SP的狀況來說
那一群SP是跑同一個thread.
不是每SP各跑各的thread....
thread不夠就是所有SP一起stall....
不會有某些SP空著無法使用的情形.

> 不是吧,
> 以1SM/512SP的狀況來說
> 那一群SP是跑同一個thread.
> 不是每SP各跑各的thread....
> thread不夠就是所有SP一起stall....
> 不會有某些SP空著無法使用的情形.

在 GPU 上就是每個 SP 都跑一個 thread 啊！當然，這也是因為 NVIDIA 對 "thread" 的詭異定義（也因此在 OpenCL 中稱為 work item 而非 thread），但目前 GPGPU 中習慣的用法就是如此。

似乎各家的Thread有點混亂.
這樣的話,我應該改用warp/wave/thread group
來代替目前的"thread"比較恰當.
現在GPU對"thread"這個字的定義和一般不同....

有一陣子GPU對Thread的定義和現在不同.
例如Xenos/C1就類似1SM的GPU.
整個GPU的所有Shader單位都共用thread發放單位.
整個GPU只有64thread來吸收Latency.
而1Thread使用的register是指整組80個ALU的使用量.
運算單位分成三個Array,3array跑3個thread.
1個thread是對一整個shader array(16x5個ALU)....
而RF由這些thread去分割使用....
而每組shader array的ALU數量會影響Register使用量,
越多ALU就佔用越多Register而改變可用thread數.
增加ALU就是得增加Register.
Xenos每個thread都是不同工作不同指令.
指令Dependency是可以靠多thread的切換,

NV過去似乎是把1個Pixel當做1個thread來看.....
所以現在thread定義怪怪的,Warp的32thread必須是
相同工作的相同的指令進度,但卻叫它thread.

姑且不管名詞的問題.
不管什麼架構的GPU,ALU數量會直接影響需要多少RF.
因為Shader Array(SM/Simd core....)
需要Register來當做Warp(Thread)切換時
暫放未完成運算的值.

自從可程式化Shader時代,沒辦法靠pipeline/FIFO
來隱藏每個Shader無法預期的Latency後,
NV和ATI都開始實做大量Thread和RF的架構.
每個ALU只要暫存4個float4,乘上足夠的Warp(Thread)
就需要佔好幾KB的RF,所以過去幾年
各廠一直維持著每ALU/4KBRF的比例很少改變.
雖然ATI的是256KB/80ALU是3.2KB.
不過VLIW在遊戲平均也只有約8成滿載率,
實際上沒有這麼多ALU的運算資料要暫放在RF.
所以每個運算中的ALU其實也是接近4KB RF Per ALU.

不知道GF104如果真的明顯降低那比例,
是否對遊戲繪圖隱藏Latency的能力有所影響.....

GPU 在 warp 切換時，資料是必須留在 register file 裡面的，這是因為它不會把 register file 的資料寫到記憶體裡（那樣會太慢），所以暫存器的使用量，就是一個 kernel 所使用的量，乘上它需要的 warp/thread 數目。

ALU 的數目增加，有可能會增加它需要的 warp/thread 數目，但是最後決定暫存器使用量的因素，是 warp/thread 數目，而不是 ALU 數目。這就是我一直在

這就是我一直前面說的重點：register file 的大小，不是和 ALU 數目成正比，而是要和它「需要」的 warp/thread 數目成正比。

今天如果說 GF104 增加到 48 SP，就是增加到三個 warp scheduler，那麼它需要的 warp 數就會增加 50%（相對於 GF100），這樣的話，宣稱它應該需要多出 50% 的 register file 就是合理的。但是現在它並不是這樣。照目前 NVIDIA 的說法，它仍是兩個 warp scheduler，這表示「增加 warp/thread 數目並無助於隱藏其 ALU latency」。因此宣稱它需要多 50% 的 register file 是沒有根據的。

我在這裡很簡單的說明一下現在 NVIDIA 和 ATI 的 GPU 的 shader units 倒底是怎麼執行的：

NVIDIA 和 ATI 的 GPU 基本上都是所謂的 SIMD（single instruction multiple data）。但是它們和 MMX 或 SSE 這種 "SIMD" 不太一樣，因為它們有比較完整的功能（例如 masked execution、gather/scatter 等等），所以他們性質上比較類似以前超級電腦的向量處理器。不過 ATI 的又稍微複雜一些。

先說明 NVIDIA 的情形。NVIDIA 喜歡宣稱他的 GPU 有幾個 "cores"（例如 8800GT 有 112 "cores"），但其實這是不太合理的說法（這樣說就有點像是宣稱 Intel 的 Pentium 3 有四個 "cores" 因為它的 SSE 一次可以跑四個資料…）。比較合理的看法是以 MP（multi-processor）為單位。例如，8800GT 其實是有 14 個 MP，每個 MP 有八個 SP，因此共有 112 個 SP。基本上它的性質應該比較類似有 14 個 "cores"，而非 112 個 "cores"。

為什麼這樣說呢？這是因為，一個 MP 裡面的八個 SP，其實同時只能跑同一個指令，只是這個指令同時會處理八個資料，就好像 SSE 的一個 SIMD 指令，一次是處理四個資料一樣（嚴格來說，8800GT 的 MP 裡面應該是兩組 4D SP，所以它其實同時可以跑兩個不同的指令，每個指令同時處理四個資料，但現在先不用管這些細節 XD）。但是 8800GT 還有一個特色，就是它的 scheduler 每四個時脈才能處理一個指令。因此，它的一個指令其實要重覆四個時脈，也就是處理 4x8 = 32 個資料。這就是 NVIDIA 所稱的 "warp"。如果以 CPU 的觀點來看，warp 和 CPU 的 thread 比較相似。GT200 基本上有同樣的架構。

由於 ALU 是有 pipelined，所以它有一定的 latency。也就是說，雖然一個 MP 每時脈可以處理八個資料，但是一個一般的運算指令（不包括比較複雜的指令）通常需要 22 cycles 才能完成。所以，如果有一個指令，需要前一個指令的運算結果，那麼它要等待 22 cycles 才行（現代 CPU 也差不多有類似的 latency，但現代 CPU 透過 out-of-order execution、register renaming 等技巧來儘可能隱藏 latency）。為了避免這樣的等待，GPU 的做法就是同時處理大量的資料（也就是同時有大量的 thread 或 warp）。

前面提到 8800GT 每個 "warp" 是 4 cycles（即 4*8 = 32 筆資料）。所以，22/4 = 5.5 即需要至少 6 warps。也就是說，如果同時有 6 個 warp，則一般 ALU latency 可以被有效隱藏起來。至於顯示記憶體的 latency，通常都會是數百 cycles，因此需要更多的 "warps" 才能隱藏，不過這其實要看整個 GPU 的 warp 數目而非單一 MP 的 warp 數目。比如說，假設顯示記憶體的 latency 是 400 cycles，則需要 100 個 warps 才能隱藏。以 8800GT 有 14 個 MP 來說，100/14 = 7.14，因此每個 MP 有 8 個 warps（即 256 "threads"）理論上就可以有效隱藏顯示記憶體的 latency。

另外，GPU 由於需要快速在不同的 "warp" 中切換，因此所有 warp 使用到的暫存器資料，都需要保存在 MP 的 register file 裡面。比如說，假設有一個 shader program 使用了 16 個暫存器，而同時要跑 8 個 "warps"，那就需要使用到 16x8 = 128 個暫存器。這是因為 MP 不能在切換 warp 時把這些暫存器資料寫到顯示記憶體中（如同 CPU 在 context switch 時的做法），因為 GPU 顯示記憶體並無 cache，這樣做會太慢。

由於 GPU 的 "SIMD" 有完整的 masked execution、gather/scatter 等等，因此它可以讓每筆資料看起來像是獨立執行。某個角度來說，這也是 NVIDIA 會把它稱為 "thread" 的原因。當然，這還是有一定的限制。例如，如果一個 warp 中有條件分支指令，而且一部份的 thread 有不同的分支方向，就會造成所謂的 "divergent branch"，這時 GPU 就必須把兩個分支方向都去執行。

ATI 的顯示晶片（至少從 RV770 開始），基本上和 NVIDIA 的類似，只是他使用的名稱稍微不同（比如說 warp 則稱為 "wavefront"）。ATI 顯示晶片的一個 "MP" 通常有 16 個 SP。和 NVIDIA 的情況類似，它的 scheduler 也是四個時脈送一個指令，因此一個 "wavefront" 有 64 個 "threads"。

不過，ATI 的情形有個不太一樣的地方，就是它的每個 SP 其實是一個 VLIW，也就是它同時最多可以跑五個指令（ATI 把這五個 "channel" 稱為 xyzwt）。ATI 因此宣稱它的一個 MP 有 80 個 "cores"（即 16x5 = 80）。這也是為什麼 ATI 顯示晶片的 "cores" 數目比 NVIDIA 的多出甚多。不過因為它是 VLIW，這五個指令必須是沒有相關性的（但其實有一些例外，這是 ATI 架構設計上的一些特點，在此不深入討論）。和 8800GT 的情形一樣，ATI 的一個 "MP" 其實裡面是分成四組 SIMD，所以一個 wavefront 其實是分成四組 16 筆資料的「分塊」分別給四組 SIMD 執行。但這也都只是小細節

經過hotball大的講解過後，
小弟回去翻了一下後藤大叔過去的warp發送示意圖，
終於比較詳細了(老實說之前根本沒去了解_A_|||)。

但含GT200之前掩蓋ALU latency的方式是在SM的單位上，
而GF100則是移到CUDA Core上了，
因GF100的一個CUDA Core需11個warp，
故GF100的整個SM可達到22個warp (同一時間可送2個warp)，
當然以上都只有針對以SP所構成的執行單元(無考慮SFU等其他執行單元)，
不知小弟這樣理解是否有誤_A_|||

現在小弟比較不解的是memory latency，
每個SM應該是平行動作的，
所以要掩蓋100個warp的latency是不是要更多的warp呢？
例如：
400 / 4 = 100 warps/SM
100 warps/SM * 14 SM = 1400 warps

想的簡單一點，把場景換回General Purpose CPU的世界，為什麼Power5要比Power4增加24%的physical register、4 SMT的Power7還要往上加？為何Nehalem/Westmere要比Merom/Penryn多出33%的physical register/ROB entry和四倍的reservation station？當然不是因為ALU變多（事實上也沒有），而是跟著Thread的增加而成長的，為了提高ALU效率、hide latency而擴增register file則是另一個層面的問題。

別擅自抽回CPU的世界啊。

要不然要我去叫大家去看計量方法最新版的附錄嗎？哈哈哈哈哈～（酒）

> 但含GT200之前掩蓋ALU latency的方式是在SM的單位上，
> 而GF100則是移到CUDA Core上了，
> 因GF100的一個CUDA Core需11個warp，
> 故GF100的整個SM可達到22個warp (同一時間可送2個warp)，
> 當然以上都只有針對以SP所構成的執行單元(無考慮SFU等其他執行單元)，
> 不知小弟這樣理解是否有誤_A_|||

這樣說不太對，其實隱藏 ALU latency 都是依賴足夠數目的 warp。GT200 以及之前的 GPU 只需要 6 warps 的原因是它的每個 warp 執行本身就會耗掉 4 cycles，所以 6 個 warps 可以耗掉 6x4 = 24 cycles，這樣已經超過 ALU 的 22 cycles latency。但在 GF100 上，一個 warp 執行只會耗掉 2 cycles，所以它需要 11 個 warps 來耗掉 22 cycles 的 ALU latency。

> 現在小弟比較不解的是memory latency，
> 每個SM應該是平行動作的，
> 所以要掩蓋100個warp的latency是不是要更多的warp呢？
> 例如：
> 400 / 4 = 100 warps/SM
> 100 warps/SM * 14 SM = 1400 warps

如果記憶體有無限制的頻寬，那確實是如此。可是實際上記憶體的頻寬有限。例如，14 個 MP 沒辦法都同時進行記憶體的存取動作（8800GT 只有四個 memory controller）。所以每個 MP 都有 100 個 warps 並沒有幫助（大部份的 warp 還是得等待記憶體控制器）。

換個方式來說，如果真的有 1400 warps，每個 warp 每時脈都在存取 32x4 bytes 的記憶體（即每個 "thread" 都存取一個 32 bits 數字），那麼它需要的記憶體頻寬會高達 1400x32x4x1.4GHz = 250TB/s。8800GT 的記憶體頻寬當然沒這麼多 XD

實際上當然一個程式不可能這樣一直存取顯示記憶體，它總是需要做一些計算什麼的。因此，通常兩個記憶體存取中間會有別的運算動作，所以實際上並不需要真的這麼多 warps（其實 8800GT 的一個 MP 同時最多只能處理 24 個 warps，所以也不能做到每個 MP 有 100 個 warps）。

更正一下，它需要的記憶體頻寬應該是

14x32x4x1.4GHz = 2.508TB/s

因為假設有 1400 warps 可以完全隱藏 memory latency，則表示每個 MP 每時脈能對一個 warp 進行記憶存取動作，所以應該是 14 而不是 1400

>>但在 GF100 上，一個 warp 執行只會耗掉 2 cycles，
>>所以它需要 11 個 warps 來耗掉 22 cycles 的 ALU latency。

所以是2組CUDA Core來分這11個warp嗎？

這樣小弟反而是換這裡有疑問了，
因為GF100的SM可於同一時間發2個warp，
等於是2 cycles可以做2 warps，
所以11 warps於GF100的單一SM中只需花費大約6 warps的時間，
也就是 6 * 2 = 12 cycles 就完成了，
還是小弟這樣想有沒考慮到的地方？

顯然小弟只要看shady兄孜孜不倦的背影作筆記就好了....(崇拜的眼神)

> 所以是2組CUDA Core來分這11個warp嗎？

> 這樣小弟反而是換這裡有疑問了，
> 因為GF100的SM可於同一時間發2個warp，
> 等於是2 cycles可以做2 warps，
> 所以11 warps於GF100的單一SM中只需花費大約6 warps的時間，
> 也就是 6 * 2 = 12 cycles 就完成了，
> 還是小弟這樣想有沒考慮到的地方？

因為實際上要隱藏的 cycles 數目是 22 個，所以每個 warp scheduler 需要 11 warps。因為 GF100 有兩個 warp scheduler，所以技術上來說其實總共需要 22 個 warps（因為如你所說，每兩時脈可送 2 warps）。不過，這並不一定表示每個 block 要有超過 22x32 = 704 個 threads。這是因為即使一個 block 的 thread 數較少（例如假設只有 512 個），只要它使用的暫存器數目還沒有超過 MP 裡的總暫存器數目，GPU 還是可以把兩個 block 同時放在一起進行 scheduling（這就是為什麼雖然 CUDA 中一個 block 只能有 512 threads，但是 8800GT 的一個 MP 同時最多可以有 768 threads，即 24 warps，GT200 則增加到 1024 threads）。

另一個關鍵點是 ALU latency 不一定需要完全被隱藏。前面討論到 GF104 時有提到，如果兩個指令沒有立即的暫存器相依性，則需要隱藏的 latency 就會減少了。但是在 GF104 上則不見得，因為如果利用到第三組 16 個 SP，那還是得隱藏 22 cycles。所以，技術上來說，GF104 要「填滿」48 個 SP，會比 GF100「填滿」32 個 SP 要困難。目前也有一些人發現，在 GF104 上執行一些針對 GF100 或更早的 GPU 最佳化的測試程式，效果顯然不如預期，有些甚至表現出類似每個 MP 只有 32 SP 的行為。這應該就是前面說的相依性問題所造成的。

>>顯然小弟只要看shady兄孜孜不倦的背影作筆記就好了....(崇拜的眼神)

Eji大過獎了
只是心中有疑問，
總不能不問個明白..._A_a

話說現在觀看GF100和GF104的效率比較，
GF100真的是比不上GF104...，
如果SM的warp發送示意圖，
真如anandtech於下面網址所畫的最後2張圖一樣，
那GF100要發送Tex、LD/ST、SFU、Interp其中之一時就只有1組CUDA Core可用，
也就是只有16個SP可運算，
這樣和G70、G71發動Tex時就只有一半運算量有啥兩樣...？

http://www.anandtech.com/...gtx-460-the-200-king/2

老實說，實際狀況真如anandtech說的那樣的話，
那GF100只要將發送方式弄得像GF104一樣的話，
32個SP滿載的機會就大大的增加了，
整個發送示意圖大概就會像後藤大叔畫的GF104的圖一樣大滿載，
只是少了1組CUDA Core而已。

後藤大叔畫的圖：
http://pc.watch.impress.co.jp/...aigai-06.jpg.html

要注意一下 AnandTech 的 GF100 圖中，雖然畫成好像 issue 1 連到某組 SP 而 issue 2 連到另一組，但是實際上不是這樣的。它們可以任意 issue 指令到任意單元。他那樣畫只是示意說 warp 1 正在使用第一組 SP 而 warp 2 正在使用第二組。

在 GF100 上，如果使用到特定指令，則同時只有一個 scheduler 能使用。這些特定指令包括：64 bits 浮點數加法/乘法/MAD、32 bits 整數 shift/compare、32 bits 整數乘法/MAD/SAD。而使用 SFU 的指令（主要是 32 bits 浮點數的倒數運算、平方根倒數、超越函數等），因為只能使用 SFU，因此每時脈最多只能同時跑四個（也就是一個 MP 中 SFU 的數目）。

hotball大，
老實說小弟的出發點很單純，
就是既然第1組CUDA Core都要做11個warp了，
同時間內其他的執行單元總該不能不找事情做吧？
不過經hotball大的解說後，
要寫出讓GF10x滿載的實用應用程式，
好好編排一番是免不了的(迷之聲：大家都是這麼做的~~)。

話說如果1個block(是指kernel，沒錯吧？)用超過暫存器，
嗯~~，除非不得以，
總該不會有人把程式往這方向撰寫吧？

>>要注意一下 AnandTech 的 GF100 圖中，
>>雖然畫成好像 issue 1 連到某組 SP 而 issue 2 連到另一組，
>>但是實際上不是這樣的。

這邊小弟了解，
但GF100總不能像GF104同時發動2個CUDA Core加上SFU等其他執行單元吧？

當然如果用 CUDA 寫程式（OpenCL 也一樣），會用到幾個暫存器，基本上就是由 compiler 決定了。NVIDIA 的 CUDA C compiler 有提供指定一個 kernel 最多使用幾個暫存器的選項（例如可以設定最多只能使用 32 個暫存器）。當然，天下沒有白吃的午餐，若 compiler 真的找不到位置放資料，就會放到顯示記憶體裡面了，這樣反而造成更大的 latency（不過，GF100 開始有 L1 cache，所以較少用到的變數可以放在 L1 cache 中）。

不過，前面也有提到，要減少指令間相依性，有時需要使用更多的暫存器。這也會產生額外的暫存器壓力。

每一個Shader program在compiler時
就決定好需要用多少暫存器了.
以NV定義的"thread"來說,
同一cycle越多ALU一起跑=越多的thread一起跑,
GF100 SM是16x2個ALU thread.
GF104 SM是16x3個ALU thread.
thread的消耗速度應該也是不同的.

當然我們可以說GF104受限於硬體thread數沒有增加,
所以不會吃更多RF,不會有Register Pressure.
但是這似乎只是NV成本考量沒法提供更多Warp/thread
導致的結果,以每個SP平均可切換NV thread數來說,
thread數/SP數
GF100的SP是48個,到了GF104只有32個.
RF尺寸和Thread數在NV這特殊架構上,其實是一體兩面的.
越多Thread就需要越多RF.
如果不增加Thread/RF,那增加ALU時
每個ALU可切換的Thread數就會變少.

雖然Warp的發放可以靠superdcalar來彌補,
但是NV的架構下,thread的不足似乎沒有辦法彌補.
而NV thread數量直接和RF需求成正比.
越多SP能同時跑就會消耗更多NV的thread.
所以GF104即使沒有Register Pressure,
但是其實還是因為Register和Thread的同時不足,
而會影響隱藏Latency的能力.

>>register file 的大小，不是和 ALU 數目成正比，
>>而是要和它「需要」的 warp/thread 數目成正比。

其實沒否認這一點,
只是我想的thread其實是現在NV是叫warp了.
所以原本說一個thread的情形,
套在NV架構下就是很多nv thread(一個Warp).
我認為"NV的"Thread的使用量和ALU數是有直接關係的.
因為他把每個ALU的工作當成一個nv thread.
現在你有更多ALU要跑,你就需要提供更多的nv thread
來隱藏記憶體Latency,
若希望效率不變,
要做更多ALU->需要更多Thread->需要更多RF.
這就是我想講的.
如果我們做一個1SM 512SP的假想GPU.
它會一次有512個nv的thread,
(或是照早期DX9 GPU的講法是一個thread)
而需要多少RF就和nv thread是成正比的.
在同樣架構同樣隱藏Latency能力的前提下.
這個1SM 512SP的GPU會需要比32SP版更多的thread
(NV的定義),而更多的thread就需要更多RF.....
所以ALU和RF的比例連結就是由此而來.
其實和講更多SP需要更多Warp/thread才需要更多RF
是類似的概念.

GF仍是兩個warp scheduler，但每個warp scheduler
現在似乎可以發放給更多SP單位,潛在消耗thread數多50%
這應該會導致thread不足的情形變多.

GF104並沒有提供更多的thread.自然不需要更多RF.
但這應該不是理想的改進方式.
也許它沒有,但它確實需要更多RF與nv的thread
才能維持相同ALU效率.
現在的改進如果沒有相對增加RF/nv Thread,
未來384SP如果全開,thread反而更吃緊.
恐怕效率沒有理想中的好.

> 當然我們可以說GF104受限於硬體thread數沒有增加,

其實重點不是硬體 thread 數目。以 GF100 支援的 1536 threads/MP 來說（或 48 warps/MP），能真的填滿這個數字的程式是非常少的，通常只有那種幾乎完全是大量非常單純計算的 kernel 才有可能。GF104 的情形也會一樣。因此重點不是硬體支援的數字，而是 kernel 實際上需要用到多少。如果 kernel 需要隱藏的 latency（不管是 ALU latency 或記憶體的 latency）沒有這麼多，增加 thread 數目是沒有意義的，有時反而會對效率造成負面影響。

> 雖然Warp的發放可以靠superdcalar來彌補,
> 但是NV的架構下,thread的不足似乎沒有辦法彌補.
> 而NV thread數量直接和RF需求成正比.
> 越多SP能同時跑就會消耗更多NV的thread.
> 所以GF104即使沒有Register Pressure,
> 但是其實還是因為Register和Thread的同時不足,
> 而會影響隱藏Latency的能力.

可是 GF104 的架構不是這樣啊！GF104 的兩個 warp scheduler 仍然只能從兩個不同的 warp issue 指令（和 GF100 一樣）。它並沒有因為 SP 增加而「消耗更多 thread」。每兩個時脈中，它還是只能「消耗」兩個 warp 的 threads，只是變成有時可以一次「消耗」兩個指令而已。這就是為什麼我前面說，如果程式一樣，GF104 需要的 thread 數目不會比 GF100 多。當然，在這種情況下，它的 SP 使用率會比 GF100 要來得低，但是這不是增加 thread 數目就能解決的。單純是增加 thread 數目，並不能使 GF104 的 SP 利用率提高。

如果今天 NVIDIA 設計 GF104 時，是選擇設計三個 warp scheduler，我就會同意它的確應該要增加 50% 的 register file。

最後我要強調一點：我並不是說現在的 GPU register file 已經夠大了。對寫程式的人來說，這個東西當然是多多益善，愈大愈好（我寫過很多程式都是用 shared memory 來暫存一些較少用的變數，以儘可能減少 kernel 的 register 使用量）。但是這並不表示「增加 ALU 數目就應該以同樣比例增加 register file 大小」。硬體的設計永遠是要考慮到平衡性的問題。當然所有的人都希望有愈多 SP 愈多 cache 愈多 registers，但是實際上真的這樣設計的話，只會造成晶片耗能過大，良率過低，時脈拉不上去等等的問題（我沒有影射某 GPU ）。

>>GF104 的兩個 warp scheduler 仍然只能從兩個不同的 warp issue 指令（和 GF100 一樣）。
>>它並沒有因為 SP 增加而「消耗更多 thread」。
>>每兩個時脈中，它還是只能「消耗」兩個 warp 的 threads，
>>只是變成有時可以一次「消耗」兩個指令而已。

若照Anandtech的說法，
GF104的SM可分成以下7個執行單元：

•16 CUDA cores (#1)
•16 CUDA cores (#2)
•16 CUDA cores (#3)
•16 Load/Store Units
•16 Interpolation SFUs
•8 Special Function SFUs
•8 Texture Units

照著Anandtech的說法，
最好的狀況可以有4個執行單元同時動作，
那最差的狀況是只有3個執行單元同時動作嗎？
還是說是只有2個執行單元能同時動作？

從hotball大的說法來看，
好像只有考慮SM只有3組CUDA Cores執行單元，
而無其餘單元的考量。
不知小弟這樣是否誤會了hotball大的解說。

後藤畫的圖http://pc.watch.impress.co.jp/...aigai-06.jpg.html
是4個Warp Schedualer+4個Dispatcher.
好像和AnandTech不一樣.......

> 照著Anandtech的說法，
> 最好的狀況可以有4個執行單元同時動作，
> 那最差的狀況是只有3個執行單元同時動作嗎？
> 還是說是只有2個執行單元能同時動作？

最差的狀況是只能兩個，就是當兩個 warp 的下一個指令都有相依性的時候（當然實際上最差是一個，因為有些指令只有一個 warp scheduler 能處理）。

> 後藤畫的圖http://pc.watch.impress.co.jp/...aigai-06.jpg.html
> 是4個Warp Schedualer+4個Dispatcher.
> 好像和AnandTech不一樣.......

我想四個 warp scheduler 應該是不對的。至少它是沒辦法同時從四個不同的 warp 送指令（也不需要這樣做，真要做的話三個就夠了）。

老實說，
後藤大叔的圖不只和Anandtech不同，
也和NVIDIA的不同...。

不過說真的，
若GF100有GF104的2 Warp Schedulers / 4 Dispatch Units的發送機制，
就增強不少了，至少在無指令相依性時都有4個執行單元可動作，
若有3 Warp Schedulers / 6 Dispatch Units的發送機制，
嘿嘿~~，看樣子28nm時代的GFxxx系的NV GPU的1個SM，
用GF100或GF104的小改一下就是了XD

其實為什麼 GF104 會選擇這樣的設計，我想有一個很重要的原因就是，把 warp scheduler 改成這樣比較簡單。如果真的做了三個 warp scheduler，那不只是暫存器要多 50%，shared memory 的 bank 數目也應該要多 50%。同時間一個 MP 能維持的 warp 數目最好也能多 50%。這樣的成本是很巨大的。

相對的，採用現在這樣的設計，NVIDIA 可以透過相對比較低的成本（只有 SP 增加 50%，warp scheduler 稍微複雜一些），就可以讓 NVIDIA 宣稱 GF104 有多出 50% 的 "core" 數目，也可以宣稱更高的 "GFLOPS" 數目。這些都是在 marketing 上很好的宣傳。至於它的利用率會比 GF100 低，那就不是這麼容易測量得出來了。

當然，這也不完全是一個 marketing 導向的決策。畢竟嚴格來說，GF104 的 core 利用率顯然也沒有非常差。當然這要看程式，但很明顯的對一般 pixel shader 或 vertex shader 應該不至於會太差，這是因為 pixel shader 和 vertex shader 經常要處理的是 3D 或 4D 的資料，而 NVIDIA 的 GPU 卻是以 scalar 的方式來執行，因此要找到不具相依性的指令應該不會很困難。不過，對於 GPGPU 的程式，情況就不太一樣了，因為很多 GPGPU 的程式，在最佳化時是針對過去的 GPU，而那些 GPU 是不用太擔心指令相依性的。

對遊戲來說,其實8個TEX才是關鍵.....
因為GF100原本的TEX數量實在太少了.
即使GF104做了64TEX也只是勉強夠用而已.
只要開高AF,CUDA core很少會是瓶頸.
遊戲非常依賴TEX單位,雖然ATI一直鼓吹
高ALU:TEX比,但是現實上市場至少有一半產品不適合那樣比例.
很多遊戲還是要考慮大多數硬體的特性.

>>當然這要看程式，
>>但很明顯的對一般 pixel shader 或 vertex shader 應該不至於會太差，
>>這是因為 pixel shader 和 vertex shader 經常要處理的是 3D 或 4D 的資料，
>>而 NVIDIA 的 GPU 卻是以 scalar 的方式來執行，
>>因此要找到不具相依性的指令應該不會很困難。

所以GF104的任務就是搶GPU市場用的，
比起GF100要GPU和GPGPU都通吃，
顯然GF104於shader的運算效率上，
以單一SM來看確實會好過GF100，
就算少1組CUDA Core也是好過GF100...，
怎麼現在看起來GF100在GPU市場上才是個過渡期架構XD

>>對遊戲來說,其實8個TEX才是關鍵.....
>>因為GF100原本的TEX數量實在太少了.
>>即使GF104做了64TEX也只是勉強夠用而已.

GF100總體的Tex效能有GT200總體的1.4到1.7倍，
雖然SP是2倍於GT200，
但GF104的SP只有GT200的1.5倍，
而Tex和GF100一樣，
這樣還只是夠用而已嗎？

>>GF100總體的Tex效能有GT200總體的1.4到1.7倍，
>>雖然SP是2倍於GT200，
>>但GF104的SP只有GT200的1.5倍，而Tex和GF100一樣，
>>這樣還只是夠用而已嗎？

因為GF104相等的對手並不是GT200阿....
(而且NV的高階卡比較重視GPGPU,而非遊戲繪圖需要的TEX)
雖然GF104目前沒有384sp全開的版本.
但等庫存gtx465清完,NV終究要出完整版的GF104.
GF104真正對手會是電晶體數和Die Size
只差10%的RV870....
就wafer切割數量來說,兩者都是16x-17x左右.
生產成本上沒有明顯差別.

對手的TEX都是直接Double+一點硬體面最佳化....
GF100的TEX進步幅度相對之下就太少了.
GF104的TEX數量算是OK,但也沒有到能像
G80/G92 vs r670那樣數量/性能優勢.
現在這TEX數量只是剛好拉回應該能抗衡的局面而已.

http://techreport.com/...e-gtx-480/3dm-texture.gif
從數理測試就很明顯,其實以每一個TEX unit來說
兩社的單體TEX性能是每一代都很接近,
而各自每一代產品的TEX效率也都有明顯提升.
(3870在這方面慘敗是因為TEX unit少對手太多了)

但是GF100卻被像3870一樣的看不到對手5870的車尾燈...
倒不是它的TEX unit不如人,而是數量實在太少了.
(其實過去NV的TEX一直都比ATI的單位效能高了一點點.)
50%的進步,相對於直接double再進步的RV870,差距太大.
而且其實RV870算是次一級的對手@_@....

雖然遊戲只有一部份Shader是Tex bound.
但是這就變成被對手追上拋遠的弱點了.
而GF104犧牲一些東西,大幅增加遊戲需要的TEX數量.
至少TEX fill rate應該不會和對手有太明顯差距...

>怎麼現在看起來GF100在GPU市場上才是個過渡期架構XD

相對於G92的G80也有這個味道啊_A_

不過GF104和RV870都在350mm^2等級，想想一邊是從RV770的250mm^2等級大幅提升、一邊是從GT200/GF100一開始的500mm^2等級大幅壓低，卻剛好平衡在兩邊的中點上。