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顯然會很方便。

總之，可以期待的事情非常多….

http://apache.dataloss.nl/~fred/www.nunce.org/hdcp/hdcp111901.htm

HDCP’s linear key exchange is a fundamental weaknesses. We can:

* Eavesdrop on any data
* Clone any device with only their public key
* Avoid any blacklist on devices
* Create new device keyvectors.
* In aggregate, we can usurp the authority completely.

The weaknesses are not easy to repair. Two proposed modifications are broken and still susceptible in $ O(n^2)$ work and $ n$ sets of keys to:

* Eavesdrop on any data
* Clone any device with only their public key
* Avoid any blacklist on devices

好像真的比想像好破….
這樣的話就會變成：

1. 無法阻止沒有得到licence的廠商copy已經發行的public key
2. 這個device即使照HDCP的規定實做black list功能，實質上也可以讓black list更新功能無力化。

於是以後發行的媒體就這樣….？
順道，XBOX360 HD-DVD Drive似乎是這個狀況的代表。_A_

XBMC 29-04-2007 SVN rev8692 build – T3CH

這版把script的選項稍微換了個位置，把原來的位置弄出了一個新功能”Favorites”。請參照screenshot。
剩下的大多是bug fix。T3CH這個svn build不再附上TMIDI，不過效果真的不錯….沒理由去掉，所以自己裝上去的時候還是有保留TMIDI。

升級1.7版韌體之後，回頭作這個測試。PSP和PS3都用固定IP。

發現：
1. 顯示組態選項的問題改善了。不會再當機。
2. 成功讓PSP透過Wi-Fi AP連上PS3了。收訊也因此改善很多。(心頭的大石落了地….)
3. 放久了時間一到還是會跑去開FAH，然後提示”不支援RemotePlay”…..XD

總之，只要PS3不使用PPPoE，而透過Router(NAT)連線的話，那麼在同一個區域網路內就可以透過AP連上PS3。
所以可以肯定目前不論哪個硬體版本的PS3，Remote Play都會試圖透過任何一個網路介面(不論有線無線)來接受PSP的連線。
這樣的話要透過其他網路技術來擴展連線範圍就會越來越方便。

此外，發現PS3直立狀態下散熱的確會好很多，運作溫度明顯地低了些。
雖說1.7版就已經大幅減少1.6版當機的狀況，不過顯然與直立無關。
為了確保穩固，去買個直立架好了….XD

R600的結構資訊裡面提到，Shader是VLIW + SuperScalr + SIMD….
乍看之下很陌生，不過這邊要提醒一下，其實VLIW並不是很新的東西，因為NV30就已經是VLIW結構了….

這裡(引用Tech Report的內文)提到，Xenos”不是”NV30般的VLIW結構，沒有排程上的問題。
不過R600似乎是第一個ATI提供register file overflow to DRAM的產品，這是為了達成SM4的規格；
NV3x當初為了達成當時為overspec的SM2a，也做了類似的決定，雖說這個特性有保留至NV4x/G7x，但是因為NV4x/G7x結合Superscalar的關係，相較於NV3x效率得到大幅改善。等到G80的時候，就和VLIW的關係更小了。

所以，其實VLIW真的沒什麼新奇的，不知道ATI這時候才拿出來講的原因是什麼。XD

補充：
http://www.rage3d.com/board/showthread.php?t=33816261
Xenos相關的一些資訊。其實只要扣掉一些特性之後，Xenos真的和R600很像。

然後，Xenos的Scalar並沒有mad，只有add/mul。
所以Xenos的raw performance應該是500MHz x 48 x (4×2+1) = 216GFLOPS。

48 ALU
simultaneous vector, scalar ops
16 vertex & 16 texture fetch
96 shader instr/cycle ( 48 Ginstr/s) – 12 instr/pix fill rate
32-bit IEEE FP (VS & PS)
216 GFLOPS (theory)
168 GFLOPS (Vtransform)
they are arranged in 3 banks of 16 ALUs in SIMD
64 threads (HW), 16×64 Vertex vectors, 48×64 Pixel Vectors
Balancing vertex vs pixel shader perf

資訊來源：
http://we.pcinlife.com/thread-757792-1-1.html
http://msdn2.microsoft.com/en-us/library/bb313879.aspx

http://forum.beyond3d.com/showpost.php?p=978652&postcount=3679
Jawed的R600指令使用率測試。(含R580/Xenos對比)

—-
最後一個無聊的小插曲：G80沒有PureVideo HD2，R600同樣沒有UVD。

XBMC 20-04-2007 SVN rev8582 build – T3CH

– This time only, I include the necessary Timidity files for MIDI playback, they add ~30MB (placed in >>system/players/paplayer/timidity<<) and that’s why this build is so larger than usual.

哇，這回有Tmididity…. 所以可以播MIDI了。
播起來還真的蠻屌的….._A_

先不管解析度之類的問題，到底XBMC還有什麼不能播的….XD

http://torotiti.cocolog-nifty.com/blog/2007/04/ps3_4c59.html
PS3 の性能の使い方

簡單講就是說….
如果想說要”徹底發揮PS3硬體”的話，就會變得很困難；但是如果”以自己要做的遊戲來思考”的話，不見得一定就會遇上那些瓶頸。

裡面舉的例子是蠻怪的啦….
“比方說寫網頁我們不會用C/C++寫，即使這樣執行效率會比較好，平常我們還是用script language”，因為這樣會比較方便、內容面上比較有生產力、實際上也因為這樣web簡單好寫而產生很多有意思的東西。

那麼，PS3的性能，用這種觀念去想的話，用比較低效率的做法、不見得就是”浪費資源”，而是讓你很快地做出東西來，之後再去慢慢想optimize的事情不就得了？畢竟靠XNA在360底下開發程式，從效率面來看，也不見得好到哪去不是嗎。

所以好不好寫PS3程式，其實是很相對的：所以上面這篇文章裡面，南治さん就認定這個觀點下，PS3的程式實在要來得比PS2/PSP要好寫得多。

まいにちいっしょ的更新頻率這麼高，其實也算是蠻有生產力了吧。

http://blog.cell.sijam.com/x264_for_cell_070412_part2/
哇哈哈哈…. 慢到爆。

最慘的莫過於原始版 x264 rev:635 和 SPE 化的 rev:635 cell 比起來，不論是用不用SPE都比原始版慢。XD

當然了，這個程式碼以減少對x264原始程式碼的改動比例為前提….
基本上SPE只做motion vector search的關係，一開始就知道效率不會好。

這個程式碼有下列的問題：
1. PPE的使用率幾乎沒有什麼明顯縮減。(55% -> 40%)
原文指出因為要求SPE處理用的packet的複製動作需要耗損PPE資源，這部分要的時間很長。
2. PPE剩下的處理因為使用的資料隨機性質大，所以cache miss機率高。
3. 工作分割單位過小。

最後，還提供了thread數量與SPE使用率的比例表….(1~6)
有執行指令(包含搬動資料的指令)就只有8~14%了，更別提裡面運算指令只占了55%前後，也就是說SPE的使用率最高也只有8%前後…

結論：移植程式給CELL，需要大幅修改演算法….或者說重寫比較快。_A_

http://techon.nikkeibp.co.jp/article/NEWS/20070419/131215/
IBM，倍精度の浮動小数点演算能力を4倍に高めた新型「Cell」を「COOL Chips X」で紹介

HPC專用的CELL B.E，正式名稱為”Enhanced CELL Broadband Engine”，至於俗稱好像真的是”CELL 2″….XD
主要的改進有：
1. 倍精度運算指令從13cycle縮短到9cycle，並且pipeline化（原來的倍精度指令有6cycle stall），可同時執行兩道倍精度運算指令(dual-issue)，使得倍精度的總運算性能從25.6GFLOPS提升到102.4GFLOPS。
2. 改善的IEEE754支援，現在起支援Denormal Support、Expected NaNs。
3. 主記憶體支援容量從2GB增加到16GB。（支援DDR2，增加腳位）

然後，還有SDK update：The system simulator was updated for the Cell/B.E. SDK 2.1 with an improved PPE model and support for an enhanced Cell/B.E. architecture-compliant processor with a fully pipelined, double precision SPE.

不過最後最可怕的一點是die size和耗電量的比較。

上表，R580的per power/per mm^2勉強和CELL打平….
考慮未來的GPU的規模即使增加，raw performance部分的強化也很可能沒有比R580好(為了DX10 support之類增加的功能)，CELL的性能與成本(耗電量、die size等)的比值仍然相當出色。

但是這張表也表現出了G80的可怕之處….
仔細看的話就知道，G80的數字有扣掉missing MUL….所以實際上G80比R580帳面上差是正常的。
表上的數據大約是336GFLOPS，如果只算MAD的話G80的理論性能大約是345.6GFLOPS，如果有把MUL算進去，實際上的數字應該是518.4GFLOPS左右。
這樣一來，flops per watt則會變成2.9FLOPS、per mm^2則是1.08FLOPS。

只是CELL這裡面的數據真的很怪，90nm到65nm，製程微縮之後幾乎沒有帶來什麼顯著的改善….
65nm下的電晶體數量是250M（90nm下原為241M）、die size為212mm^2（原為235mm^2），TDP為100w（原為110w）。
Die Size從235mm^2變成212mm^2，單位面積只多了10%電晶體，但是原本一般期望CELL的製程改善，應該可以縮小40~50%的die size才對。
(這個和複雜的on-chip network、wire有關係嗎？)

總之這些數據需要再研究….不過，如果確實是如此的話，不論有沒有eDP，65nm的CELL能降的耗電量可能都不大（不考慮LongRun2的話，因為LongRun2是90nm版CELL完成之後才簽約的），後面縮小規模的機會也不大；倒是相對起來可能RSX有比較大的機會縮小規模和耗電量。

這代表，最糟的情況，即使是用新版晶片的PS3，耗電量可能也不會改善太多。
機殼的散熱系統所需的成本也可能不會有太大的改善。

補充：
http://www.power.org/resources/devcorner/cellcorner/hpcspe.pdf
PDF出來啦….

http://www.vr-zone.com/?i=4883
http://www.hardwarezone.com/articles/view.php?cid=3&id=2231

開始出現8600GTS性能review了….32SP、1.5GHz前後shader。
基本上可以看到1.4倍法則的作用。
(DX9和DX10的功能實作差距大約需要1.4x電晶體，此為ATI提出)

G84是115mm^2 @ 80nm，基本上90nm下就是150mm^2左右，性能大約介於7600GT和7900GT之間。
32個SP就要289M，G86只有16個SP卻更高達210M，讓人真的很質疑SP需要的電晶體預算。

考慮RSX”只有”250mm^2，就能達成相當的良率，就算存在G84兩倍規模的G8x core，在90nm下能達到的成本效能比也非常微妙(應該沒有放冗餘shader的空間)；加上沒有準備eDRAM相關的設計，以NVIDIA手邊的核心在300mm^2內提供最佳效能這點來看，PS3用RSX看來應該是合理的。

EDIT：聽說這幾天的新版Driver上頭，G84的Dual-issue復活了，Missing MUL補回來帶來的效能落差相當明顯。
不過G80是救不了了，應該是硬體bug。

只是如果真的是這樣的話，就變成G80用稍遜於R580的理論資源、大不到1/3的記憶體頻寬、正好多1/3的記憶體容量，狂電R580兩倍有剩。
Unified Shader的可怕效率展現無疑啊。