H.264 Encoder on CELL…. 實作論文

http://www.diva-portal.org/liu/undergraduate/abstract.xsql?dbid=8294
A Simplified High Definition Video Encoder Based on The STI CELL Multiprocessor

這篇算是解決了我長久以來的疑惑….他們的作法算簡單的(畢竟為了畢業),但是程式碼的效率真的不怎麼樣,用的compiler也是很老的gcc。如果這樣都能做到1080p 30fps real-time,那我相信Toshiba他們的實作也早就已經有real-time了。

但是如果要拿去作製品化Encoder的話,那相信驗證還有很長的路要走。
H.264在低流量上已經把MPEG2甩遠了,但是高流量的時候其實畫質並沒有很明顯的優勢。
CODEC在規格上的潛力當然是毋庸置疑,但是MPEG2成熟得多這點也無從反駁,只能說H.264登基的時候還沒到,所以BD既然有流量優勢,那麼繼續用MPEG2其實沒什麼不好的。

所以真正的問題或許是:我們對SCEI的軟體開發人力期望太大了?
PS3這個系統能做的事情太多了,他們根本做不完XD

IBM 發表 “GameFrame”

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

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

HDCP破解完畢?

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_

PSP Remote Play on PS3 1.7版

升級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的VLIW….

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 update to XBMC 20-04-2007 SVN rev8582 build – T3CH

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

PS3的性能該怎麼用呢?

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要好寫得多。

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

現在只剩下黑歷史….