http://www.cs.ucf.edu/~zhou/dlp.pdf
Experiencing Various Massively Parallel Architectures and Programming
Models for Data-Intensive Applications
Thread Hierarchy
G80：16 Stream multi-processors (SM), 8 streaming processors (SP) per SM, 4 SMs share 1 Texture subsystem
RV670：4 clusters, 16 x 5 cores per cluster, each cluster time-multiplex 1 Texture subsystemRegister File (32-bit registers)
G80：512 kB = 32kB per SM * 16 SM; 8K registers per SM; 1K register per SP
RV670：1MB = 256kB per cluster * 4 cluster; 64K registers per cluster; 1K register per core
這太精采啦XD
所以R600的觀念其實是比G80更大的register file，然後不具備G80的shared memory。
R600/RV670的GPGPU要算得快的話，就是要配合大register file使用loop unrolling之類的技巧；
能算的東西則很類似Pixel Shader，因為只要做了thread interconnection效率就會很差，原因是R600沒有on-chip的share memory，只有讀寫on-board memory的FIFO。
此外，G80/G92是24個warp(32 threads per warp)，R600/RV670則是每個array有192個”wavefront”(64 threads per wavefront)，這個詞大概就是和G80的warp相對應。
一看很有趣地，G80是24×8 = 192warp total，R600/RV670也是192wavefront total，只是一邊是32threads per warp、一邊是64threads per wavefront，同時兩邊的egister file的規模也剛好是相差一倍，這下謎題都解開了XD
—–
這篇也確認了R600每個cluster上面的core(16×5=80cores)以分時的方式共用一個Texture Array(4D)。
所以RV670維持4個array對4個tex-array(4x4D)，RV770增加到10個array，Tex-array也增加到10組4D。
G80到GT200的register file規模增加的幅度，是從8K registers per SM，擴充到16K，等於64KB per SM * 30 = 1.92MB。
R600的每個core都有自己的256KB register file，所以4個array共計1MB，10個array共計增加到2.5MB，其實比GT200提供的規模還大上許多….
當然RV770雖然看起來”只增加20%”電晶體，但是說起來這也是增加了超過200M的規模(666M->954M)，所以說起來仍然很合理就是了。XD
也就是說，未來如果R600的架構要繼續增加SP，比方說現在在傳的「2000個SP」(25個array)，其實考慮換成45nm之後大概也是和現在的RV770差不多大或者稍大。
而這也可以說是R600結構的價值所在。
—-
在G94推出前，光比較RV670和G92就會顯得R600結構效率很差，運算密度很低，然後G92的成本很高；G94推出時就會看到G8x的結構比R6x0可以更小些….
RV770推出後則把R6x0的運算密度提高，達到和G92可以對抗的程度。也就是說其實雙方的core(TPC vs ALU array)幾乎是可以單位上相對比的。
現在的問題就是RV770有沒有辦法以現在的方式拿出和GT200可以對抗的產品：
GT200顯示NVIDIA認為8TPC-256bit是適當，所以往上做就是16TPC-512bit(16TPC整合到10TPCx1.5，以縮小crossbar規模)
那麼，RV770之後謠傳會到2000個SP，可能是從10個array變成25個array；但是在此同時TMU的數量也跟著增加到100個，這時候還會是16ROP + 256bit(GDDR5)嗎？
要不然的話NVIDIA也可以拿更多TPC來搭配256bit，就可以快速地縮小看起來很巨大的GT200了….
從RV770可以看得出來，其實TMU和ROP在R6x0裡面也是占較大規模，所以只增加20%就可以達成不刪減register file增加總運算量。
