http://gametomorrow.com/blog/index.php/2007/04/26/want-to-run-a-game-on-big-iron/
這是上週的新聞，IBM開始進行所謂的”GameFrame”計畫，打算將CELL與MainFrame整合。
這個算是過去已經有心理準備的東西了，而且也很循序漸進一段時間了。大概可以成下面幾個階段：
1. 使用CELL的PS3
2. 在CELL blade上執行的全物理模擬化MMORPG
3. RoadRunner的異種處理器分散結構(x86 + CELL，各自負責大型程式的執行與關鍵浮點運算)
4. 上述的要素重新整合進Power6 based的MainFrame。
剛好同一個時間SCE也開始Home的beta作業，可以說一切都配合得很好。
PS3本身的記憶體並不算多，傳統的Server=Client結構也很難達成讓遠端資源順利為客戶端所用的夢想；但是GameFrame的構想如果可以實現的話，理論上整體的運算資源會變得比較有效率：Server端執行一個相對比較大的遊戲規模，然後在client端就可以只分割處理成一個比較小的單位，而client之間也可以用P2P交換資料，改善效率，就像是GameFrame單獨執行一個巨大的遊戲image，而各個PS3只需要從中取得一部分的content般的感覺。
而且MainFrame結合CELL的技術，也可以擴充單一image的規模。過去一個網路遊戲的server一般限制在頂多數千人左右的規模(與硬體及網路資源均有關係)，但是現在可能可以到達數十萬人的境界。而且考慮Home本身在”遊戲內執行遊戲”的這個特性(本身Home作為match-making工具的色彩仍然很重)，擴充Home內的社會性行為，以及利用Home來進行PS3本體的遊戲，都有相當的發展空間。
雖說個人認為PS3在細部繪圖上還可以發展的空間，已經受限於RSX的硬體能力的部份較大，但是關於數位內容的表現能力上，多樣性本身應該會有很長足的進展。比方說Lair已經透過Progressive Mesh實現了極大規模的real-time LOD場景結構，畫面細部部份不見得表現非常出色，但是仍然實現了過去CPU性能受限(來自於x86市場特性)，必須將工作轉交給GPU時所犧牲的許多東西。這已經提示了一些未來的方向，或者說本來設計PS3這個系統的技術人員原始的願景。
最低限度，光是MainFrame帶來的RAS改善，就已經非常可觀了。
—-
不過話說回來，上面看起來只和MMO Game有關….而不是MMO Game類型的遊戲的話，Home還有沒有用呢？
Home本身會吃掉一定程度的記憶體(雖說某光頭說”很薄一層”)，如果要做到”從Home進入別的遊戲”，”跳出回到Home”都要瞬間解決的話，那毫無疑問Home只能常駐了。當然Home裡面的3D環境要做到完全不吃記憶體其實不難，場景內容全部用重新運算產生就可以；但是重點在於作為一個純match-making system來說，Home顯得真的很花俏(畢竟刻意把非MMO Game作成可以接近MMO-Game的結構意義不大)…而Home提供的社會性行為部份真的能夠抵銷這個衝擊嗎？這是一個不小的疑問。
所以，如果Home可以同時提供許多非遊戲的功能的話，那就會顯得更有意義 — 目前聽說Home可能會有P2P Media-sharing功能，應該就是為了這點而加入的。而且實際上已經有些遊戲想加入PS3本身就可以當Host的功能，如WarHawk。(玩家可以用PS3來建立一個同時上線人數超過20人的server，並且那台PS3本身同時可以開4分割螢幕提供對戰….雖然這在PC上並不是什麼了不起的事情)
而這時候，能夠提供線上同時對話的match-making系統的存在價值，就是使玩家之間的聯絡更便利。即使遊戲本身提供server功能，Home仍然可以提供與玩家對話的功能，而且不僅是遊戲中的玩家，還包含沒有參加遊戲的其他玩家。能維護共通的member-list顯然會很方便。
總之，可以期待的事情非常多….
P2P Media-sharing !?
sony這個連自家隨身聽都龜毛到不行的會做出這種東西嗎？
to shady:
>>3. RoadRunner的異種處理器分散結構(x86 + CELL，各自負責大型程式的執行與關鍵浮點運算)
>不知道為何要才用x86+Cell,是成本的問題還是… (我曾經想說IBM已經有Power6,為何不用它…)
不知道XD
不過Opteron那時候已經取得一些成果了，Cray的XD1 就是用Opteron的產品。Opteron的延展性在當時其實應該是非常好的。
也有人說IBM大規模使用Opteron是因為AMD是最佳的戰略夥伴(最大宗製程使用者)之類非技術面的因素就是了。
> sony這個連自家隨身聽都龜毛到不行的會做出這種東西嗎？
呃，龜毛不變啊。
Home先前已經知道在自己的房間可以上載PS3內部的media file，現在根據beta tester指出，現在可以做到user間直接傳輸上的檔案交換。
但是即使傳輸上使用的是P2P技術，還是限制在PS3現在自己可以處理的媒體….雖說容量上應該可以透過DLNA/samba去擴充，但是可以處理的媒體以及對DRM的政策顯然是不會讓你使用起來和emule一樣方便。
>雖說個人認為PS3在細部繪圖上還可以發展的空間，已經受限於RSX的硬體能力的部份較大，但是關於數位內容的表現能力上，多樣性本身應該會有很長足的進展。
RSX比起Xenos來說,VS是40GFLOPS比72GFLOPS(16US),
而PS則是204GFLOPS(有計兩個SFU)比144GFLOPS(32US)…
在整個核心來說,VS與PS各有優勢(除非XBOX360把VS全數交給CPU作,那RSX的PS不計SFU則須有565MHz才夠)…
但現在Cell也可以處理VS或GS,也就是說只論繪圖核心,
PS3還是略勝(不知一個SPE能產生多少的Vertex/s?)…
所以整個PS3的繪圖最主要還是卡在記憶體的分配,
總是覺得RSX讀XDR 20GB/s,寫XDR 15GB/s,
比起GDDR3的頻寬很不足,且有延遲…
而FlexIO總體的頻寬我記得有7xGB/s(Cell於3.2GHz),
然現在只用40GB/s,那剩下的呢?
若RSX的讀+寫有25+25=50GB/s,貼圖應該會更好…
總結PS3的繪圖系統須先解決記憶體的問題,
否則Cell再強也不會加強畫面太多…
我去查過Cell的FlexIO的規格為:
This consists of a set of 12 x 8 bit busses which run at 6.4 Gigabit / second per wire (76.8 Gigabytes per second total). The busses are directional with 7 going out and 5 going in.{出處:http://www.blachford.info/…r/Cell/Cell2_v2.html}
而為了PS3產量的考量,6.4Gbps改為5Gbps,所以總頻寬為60GB/s(out為35GB/s,in為25GB/s){參考:http://pc.watch.impress.co.jp/…28/kaigai220.htm}
所以RSX和南橋晶片組共吃掉20+15+2.5+2.5=40GB/s,故只剩20GB/s(out為12.5GB/s,in為7.5GB/s),不知這剩下的頻寬是跑到哪了呢(真是耐人尋味啊~~,不知Eji大是否有這剩下的頻寬之情報,不過我也不排除因為產量之因素而將其砍掉XD)?
兩個失效的連結重貼:
http://www.blachford.info/…er/Cell/Cell2_v2.html
http://pc.watch.impress.co.jp/…028/kaigai220.htm
FlexIO剩下的頻寬？”沒用到” XD
不過實際上FlexIO有個限制，就是”和兩顆晶片”相連不需要額外的ASIC。
所以，可以想像最大的組態就是
1. 兩個CELL相連，雙向頻寬20GB/s（去回各10GB/s）
2. 一個CELL連接RSX、一個CELL連接SSC。
這個也是先前對強化版AV用PS3的猜測。
如果照上面的設定….連接法就像下面這樣：
SCC—CELL1—-CELL2—-RSX
一個CELL在沒有外部switch的狀況下最多只能與兩個晶片直接相連，這是FlexIO的限制。
SCC–CELL1的頻寬是5GB/s up、5GB/s down(SCC的極限)，
CELL1–CELL2的頻寬是10GB/s up、10GB/s down
CELL2–RSX的頻寬是20GB/s up、15GB/s down(相信是RSX的極限)
主要限制是RSX/SCC的頻寬實做了幾個channel….
RSX的頻寬是上傳20GB/s、下傳15GB/s（上=往RSX），所以是上傳32bit、下傳24bit。
SCC在PS3上的頻寬只有在CELL blade上的一半，所以buss寬度只用了上下傳各4bit，實際上SCC實做了上下各8bit，所以應該是上下傳各5GB/s。
上列的頻寬總共上傳40bit、下載30bit，剛好上下傳各剩16bit，考慮前述FlexIO在topology上的限制，前述的連接法正好可以用完FlexIO的可用頻寬。
>CELL2–RSX的頻寬是20GB/s up、15GB/s down(相信是RSX的極限)
不知RSX是用啥來與FlexIO接續,是PCI-E還是用記憶體的256bit來接(GDDR3與FlexIO各128bit),
又或者是RSX也有一in為20GB/s、out為15GB/s的FlexIO,因此造成Cell–RSX的頻寬就是如此?
(如果RSX也是用FlexIO,真不知為何要20+15,而不20+20? 真搞不懂SONY啊XD)
真不知PS3的繪圖記憶體要如何突破256MB…
(正確來說XDR+GDDR3=64+32=96MB,所以GDDR3只有224MB給貼圖用…XD)
不知Eji大是否知道有那些方法能用XDR來做繪圖記憶體呢?
http://www.chipworks.com/…laystation_report%20(2).pdf
上面這PDF中有提到PS3還有Samsung K9F1G08U0A 1Gb SLC NAND Flash的記憶體,看圖好像是接在南橋,不曉得這記憶體能搞啥鬼?
>不知RSX是用啥來與FlexIO接續,是PCI-E還是用記憶體的256bit來接(GDDR3與FlexIO各128bit),>又或者是RSX也有一in為20GB/s、out為15GB/s的FlexIO,因此造成Cell–RSX的頻寬就是如此?
>(如果RSX也是用FlexIO,真不知為何要20+15,而不20+20? 真搞不懂SONY啊XD)
很明顯啊，因為G7x並不重視GPGPU-based的運算，並不太需要回傳頻寬，所以CELL往RSX的頻寬比較大是可以理解的。實際上CELL從RSX的local buffer讀取記憶體的頻寬小到反常，反而是RSX直接render到主記憶體的效率和頻寬成正比。
>真不知PS3的繪圖記憶體要如何突破256MB…
>(正確來說XDR+GDDR3=64+32=96MB,所以GDDR3只有224MB給貼圖用…XD)
>不知Eji大是否知道有那些方法能用XDR來做繪圖記憶體呢?
嗯？就普通的TurboCache就可以啦？RSX讀寫主記憶體的頻寬都有很確實的實測值，是可以掌握的資源，那取用上有什麼特別的問題嗎？
http://www.theinquirer.net/…emory_bandwidths.jpg
而CELL倒是幾乎等於只能用256MB….雖然這其實並不是大問題。
小弟我已看過這張PS3實測圖了,
最讓小弟疑問的是Cell讀/寫XDR相差甚大且未達25.6,
但RSX讀/寫GDDR3卻可以達到22.4,
不知是啥原因造成的?
還有就是Cell讀/寫GDDR3可以不用了,
全給RSX讀/寫XDR來達到20/15較實際XD
可Cell讀/寫GDDR3全給RSX讀/寫XDR卻只有19.5/14.6,
和Cell讀/寫XDR一樣未達100%,
造成此原因是否和Cell讀/寫XDR相差甚大且未達25.6之原因一樣?
最後小弟一直將XDR能否當作繪圖記憶體之焦點一直放在FlexIO的BW上錯了,
應該放在XIOEIBFlexIO的延遲才對,
不知其延遲是否非常的小?
>應該放在XIOEIBFlexIO的延遲才對,
當中的XIOEIBFlexIO是筆誤,
原本是要打成”從XIO經EIB到FlexIO”才對…
不過話說回來,
就算這段路徑的延遲在能接受的範圍內,
難道RSX對XDR作材質貼圖的處理不會影響Cell的效能嗎?
延遲的部份RSX是用加大的texture cache去cover了。
至於拿XDR存取材質會不會影響效能？當然會啊。
可是今天的問題如果在材質容量的話，這就是現在的解答。
頻寬的話，很多人都會想256bit GDDR3，但是那不是成本內的解決方案。
>延遲的部份RSX是用加大的texture cache去cover了。
哦~~原來還有這招啊XD
既然如此就要看頻寬夠不夠用了…
>至於拿XDR存取材質會不會影響效能？當然會啊。
>可是今天的問題如果在材質容量的話，這就是現在的解答。
也就是說一次存取一塊材質的容量要在不影響效能的範圍內…
所以那張PS3實測圖中Cell讀/寫XDR相差甚大且未達25.6GB/s,
就是RSX拿XDR存取材質容量過大所造成的影響囉?
不過話又說回來,
PS3的Cell只有7個SPE,
照理說應該是少一個SPE在搶頻寬才對,
所以對有307.2GB/s的EIB來說應該很夠用才對啊?
(EIB的BW到底是307.2GS/s還是204.8GB/s…我被IBM給搞混了XD)
可對XDR來說是大家都在搶啊…
其實考慮大家都那麼不會作multi-thread，從8個2.4GHz（SDK）變成6個SPE應該會比較好用XD
(單一thread性能上升33%)
EIB的頻寬部份，至少IEEE的論文上最後是寫204.8GB/s就是了。XD
http://hpc.pnl.gov/…io/papers/ieeemicro-cell.pdf
7個裡面有一個是Hypervisior/OS專用的關係，所以並不會吃頻寬。
不論如何，所有在EIB上的單位都有一個(FlexIO bus是兩個)16byte的port，所以每個SPE/PPE/XDR都是25.6GB/s的雙向頻寬(只有FlexIO是51.2GB/s)，所以照理來說只要EIB能符合這個需求應該就可以了。
也就是說相較於EIB的總頻寬，每個SPE/PPE其實都只有一點點的頻寬吞吐能力，並不是一堆單元有辦法靠自己吃滿EIB頻寬…. 所以其實並沒有什麼EIB頻寬不足的問題。
所以EIB剩下的問題就只有latency….這邊就要靠DMA上的處理技巧了，比方說那篇瑞典大學的H.264 Encoder，裡面就有”如果frame的複雜度不高，就可能會發生SPE已經算完了，但是下個frame的資料還沒透過DMA傳過來，結果造成SPE stall”的問題，這就是運算量和傳輸量之間還沒有配合好所造成的。
看過那篇IEEE的論文後,
我想我了解到SPE的最佳化…不,
應該說是整個PS3的最佳化是:
1. PPE盡量作好分配指導的角色,
做好整個system的平行處理…
2. SPE則是靠DMA上的處理技巧,
使自己不會stall(RSX也要當成如此處理)…
3. 舉不出例子來了XD
不過光前兩點就已經搞死很多的遊戲商了XD
(因為大家最先摸熟的只有RSX,而且只能用GDDR3而已…)
不過說真的，以我自己的看法，我覺得比較可能是307.2GB/s。
因為其實你算一下，PPE、SPE x 8、XDR各有一個16byte的port，FlexIO有兩個16byte的port，合起來剛好是 12 x 16byte x 1.6GHz = 307.2GB/s。
所以EIB有307.2GB/s剛好可以完全符合這個需求。
此外，PPE你提到做好分配指導的角色，不過只要是移植類的軟體似乎都很難做到這點，只有重新coding才能解決這個問題。
比方說Ageia的PhsyX library for PS3，當初宣稱可以把PPE的工作減輕50%，這不就代表還有一半的工作還在PPE上？那蠻悲慘的耶。
來源：
http://www.watch.impress.co.jp/…060514/ageia.htm
PS3上的Havok 4.0和4.5可以差10倍效能，這也是一個代表性的部份。
(可惜一些用到Havok的title已經都release了，這個更新才放出來)
照Eji大的算法,那204.8GB/s應該是指8個SPE的BW…
>比方說Ageia的PhsyX library for PS3，當初宣稱可以把PPE的工作減輕50%，這不就代表還有一半的工作還在PPE上？那蠻悲慘的耶。
如果考慮最糟糕的情況,就是原版本在Cell上執行時,
全靠PPE在撐場面,那真的很慘…
不過就算原版本PPE只吃60%,看樣子也好不了多少XD
看樣子重新coding方為上策…
(目前移植的遊戲,PS3真的做的不是很好…)