CELL的DDR2支援實作法

http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/AF7832F379790768872572D10047E52B
http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/AF7832F379790768872572D10047E52B/$file/CellBE_HIG_65nm_v1.01_8Jun2007.pdf

Cell Broadband Engine
CMOS SOI 65 nm
Hardware Initialization Guide

page 209.
E.11 DDR2 support

所以其實是RAMBUS提供了一個XDR轉DDR2的translator chip,每個translator支援128bit,連接到32bit的XDR controller上,總寬度是256bit。
在這個前提下,CELL支援到最大16GB的DDR2記憶體(double bank),每個channel定址到33bit。(XDR下提供到35bit)
使用ch DDR2-800時最大頻寬與使用XDR 3.2GHz時相同,為25.6GB/s。

這樣看來LANL RoadRunner需要的大容量記憶體支援並不是真的靠作兩個版本的CELL來解決….其實這種作法也比較符合IBM目前在高階市場的需要啦。
而以原理來說,初代CELL”應該”也可以透過這個晶片支援DDR2;不過在舊版的Initialization Guide裡面並沒有DDR2如何支援的詳細資料,只有提及DDR2的容量,所以當時可能只有計畫,還沒有實作好….

總之,如果CELL Computing Board也用這種方式提供DDR2支援的話,那要擴充容量相對來說就比較簡單了。

CELL 舊版 HIG(2006年9月)
http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/BD3F1F4C3DB32C7487257142006131BC

話說這份PDF是6月8日釋出的,這或許可以代表65nm版CELL確實的完成時期….

—-
而現在回去看RoadRunner的文件,就會看出許多端倪。

http://www.lanl.gov/orgs/hpc/roadrunner/pdfs/sc06rrbriefing.pdf
RoadRunner設計上是每4個Dual-Core Opteron配上4個CELL-Blade,兩邊各32GB memory。
即8個Opteron-Cores搭上8個Cell,每個Opteron都搭上一個CELL,並且各自搭載4GB Memory。

也就是說,其實RoadRunner的原始目的,是希望有個Opteron-Core + 8個SPE的CPU存在….
或者是說用Opteron來取代PPE,這樣講可能比較直接。_A_

http://www.lanl.gov/orgs/hpc/roadrunner/pdfs/rrsummary.pdf
裡面提到了提供Hybrid computing 的 SDK3.0提供時間是07年後半、Phase3實際完成時間是08年前半。
此時所有系統都會採用eDP CELL來建置,可以穩定地提供1PetaFlops的Linpack,來支援LANL的核武模擬作業。(從64-ways增長到1000-ways)

SDK 3.0的重點有:(page9)

ALF & libSPE [PPE-SPE互動]
• Computational Library (ALF w/ IBM)
– Task & work block queuing & management
– Streaming & user-defined data partitioning
– Process management
– Error handling

DaCS or OpenMPI [Opteron-CELL/PPE互動]
• Communication Library (DaCS w/ IBM)
– Data movement & synchronization
– Process management & synchronization
– Topology description
– Error handling
– First implementation may leverage OpenMPI

• Longer term
– ALF & DaCS support in tools
– ALF from Opteron ⇒ Cell directly
– Compilers supporting some of this

話說RR雖然持續如火如荼地進行中,不過過去其實有很多人對HPC的觀念都是
「有很多老程式」、「要加速現有的code」,不過CELL/GPGPU之類的方案都需要幾乎重新coding,這會帶來多少衝擊,其實可以看遊戲界現在的狀況就知道。
HPC市場真的能平安過渡過去嗎?這又是個值得觀察的問題了。

We are not 「sad Madden-like」title

http://www.ps3fanboy.com/2007/08/14/call-of-duty-4-on-the-ps3-run-at-60fps-with-full-aa/
Call of Duty 4 on the PS3 runs at 60FPS with full AA

One of the developers behind the sexy looking FPS has recently shot-down the rumor that COD4 on the PS3 would run at a sad Madden-like 30FPS with little to no anti-aliasing, versus the 360 version which has already been confirmed to run at 60FPS with AA.
「對不起那些痛恨PS3人士了,我們已經為「對PS3有愛的玩家」在PS3版本中實現了60FPS和抗鋸齒。」

我只能說這翻譯GJ…. XD
和AI做不起來的Ubisoft相比,又有其他developer覺醒了嗎XD

然後EA也替自己找理由:
EA Explains Why Madden Sucks on PS3

In the case of the next-generation consoles, many publishers have been developing titles for the Xbox 360 for over 3 1/2 years while everyone who publishes now for the PlayStation 3 with the exception of Sony has been developing for the PlayStation 3 for only a little over one full year. The differences in the overall knowledge of the hardware is vastly different for both consoles and…it is very difficult to get it right the first time.

3年半和1年未滿…. _A_

—-

[EDIT]
http://www.cod4forums.com/index.php?showtopic=220
有人丟pre-beta screenshot的對比出來了,看起來PS3版多那麼一點點細節?

Deferred Rendering in Killzone 2

http://www.develop-conference.com/developconference/schedule_at_a_glance.shtml?view=day&daycode=8

Deferred Rendering in Killzone 2

Next generation gaming brought high resolutions, very complex environments and large textures to our living rooms. With virtually every asset being inflated, it’s hard to use traditional forward rendering and hope for rich, dynamic environments with extensive dynamic lighting. Deferred rendering, on the other hand, has been traditionally described as a nice technique for rendering of scenes with many dynamic lights, that unfortunately suffers from fill-rate problems and lack of anti-aliasing and very few games that use it were published.

In this talk, we will discuss our approach to face this challenge and how we designed a deferred rendering engine that uses multi-sampled anti-aliasing (MSAA). We will give in-depth description of each individual stage of our real-time rendering pipeline and the main ingredients of our lighting, post-processing and data management. We’ll show how we utilize PS3’s SPUs for fast rendering of a large set of primitives, parallel processing of geometry and computation of indirect lighting. We will also describe our optimizations of the lighting and our parallel split (cascaded) shadow map algorithm for faster and stable MSAA output.

http://www.develop-conference.com/developconference/downloads/vwsection/Deferred%20Rendering%20in%20Killzone.pdf

其實說起來Deferred Rendering已經不是什麼了不起的東西。
KZ2用Deferred Rendering的時候最大的問題看起來像是G-buffer並不便宜,有36MB….
而且KZ2的SPE雖然有用到四個,但是和繪圖相關的主要都是在display list產生上,還有一些Image-Based Lighting的資料產生。

SPU Usage
> We use SPU a lot during rendering
> Display list generation
>> Main display list
>> Lights and Shadow Maps
>> Forward rendering
> Scene graph traversal / visibility culling
> Skinning
> Triangle trimming
> IBL generation
> Particles

所以從這篇來看,KZ2實在是非常善用美術可做的事情來彌補RSX的不足….
不過他們正在檢討Ambient Occlusion和Dynamic Radiosity,也許有計畫利用Enlighten那一類的技術?

—-
每次遇到這種題目,我就會想,如果頻寬/容量條件完全相同的狀況下,改用G8x到底能表現比G7x好多少?
除了晶片本身之外,其他部份的成本不能大幅度改變之故,考慮的記憶體頻寬主要是靠原來的128bit GDDR3和FlexIO,總共25.6GB/s + 5GB/s雙向 + 15GB/s 下行 + 10GB/s上行,容量也限制在256MB + 256MB。

如果有G8x的TCP結構,可能KZ2不需要用到Deferred Rendering…. 因為console不能換硬體,這點特別的痛。
但是如果要維持peak performance的話,可能要作到3 ~ 4TCP的規模,電晶體數量可能會衝到500M….這樣真的值得嗎?

PS3相關AV功能展望(2007-08附記)

http://hobby9.2ch.net/test/read.cgi/av/1186410056/l50

Hivi 2007年8月号 に今後のアップデート展望が少し載ってた
年内→BDプロファイル(BD-JAVA等)に完全対応、アプコン用パラメータを細分化
来年以降→アプコン用パラメータをユーザーが好きに設定できるように、1080のi/p変換を可能に

我是覺得功能加強全部集中在光碟player上不太好….

http://www.phileweb.com/news/d-av/200708/09/19049.html
TA-DA5300ES緊急Review兼金井隆先生interview

「ロスレスデコードは記録時の原音を再現する実力はあるが、専用の回路でデコード時のノイズ対策をしないとリニアPCMよりも音が悪くなる」
「自社内のBDレコーダー/プレーヤー開発チームと連絡を密に取ることでこの現象を確認し、対策を施すことができました。またTA-DA5300ESの開発にはSCEの”PLAYSTATION3″を設計しているチームも協力しています。アンプ単独で開発を進めていたならば、ロスレスデコード時のノイズ対策はできなかったかもしれません。きっと来年以降に登場するAVアンプはロスレスデコード時のノイズ対策がカギになると思います」
(by 金井隆先生)

所以看起來這台也是很值得考慮的機器?

Painting with Light Enlighten and the PS3

or….
How I learned to stop worrying and accept that the PS3 is perfect for doing real time radiosity XD

Source:
http://www.geomerics.com/documents/GeomericsDevstation2007.pdf

News:
http://www.gamasutra.com/php-bin/news_index.php?story=10031
July 11, 2006
Product: Geomerics Debuts Real-Time Radiosity Solution

http://www.gamasutra.com/php-bin/news_index.php?story=12812
February 19, 2007
Product: Geomerics, Epic Partner To Enlighten UE3

http://www.gamasutra.com/php-bin/news_index.php?story=14659
July 12, 2007
Geomerics Gets $4mil Investment, PS3/360 Middleware Invite

2006年7月的時候,屬於劍橋大學的一個學術兼遊戲媒體製作單位Geomerics發表了它們的第一個產品「Enlighten」,作用是一個tookit可以在其餘的繪圖引擎內加入Real time Radiosity的效果。
然後2007年2月的時候與Epic簽約,整合進UE3;並且在GDC07的時候展示了XBOX360版。(正好在同時,まいにちいっしょ也做出了類似Real Time Radiosity、或者說Ambient occlusion的效果,演算法來自3dsmax知名的plug-in,SkyLight)
今年5月的時候,Devstation 2007上他們發表了PS3上的Enlighten研究成果,標題如上。

“以光替萬物上色:Enlighten 與 PS3的配合”,或者說:”我們終於學到了PS3做Real Time Radiosity實在是屌到不行“XD

所以我們來提一下他們到底做了什麼。
Enlighten的功能大致如下:

  • Real-time radiosity
  • Dynamic lighting environments
  • Colour bleeding
  • Soft shadows
  • Character lighting
  • Ambient occlusion
  • Specular highlights
  • Normal mapping
  • HDR
  • Cross-platform compatibility

其中,Radiosity(熱輻射演算法)的內容請參照Geomerics本身提供的資訊,或者是Wikipedia
Enlighten在PC和XBOX360上的作法,應該是用CPU或GPU的資源,產生有Radiosity效果的各種材質,然後讓GPU讀回來打光。
而PS3上的Enlighten則是使用SPE。

問題來了,SPE這東西讓諸多廠商又愛又恨,感覺上能做的東西很多,但是又不知道怎麼做。
比方說,SPE靈活度很高,但是性能夠嗎?延遲如何?它能幫助打光流程多大?這麼重大牽涉到整個render流程的東西,真的有辦法靠SPE做嗎?而且用SPE做會不會佔掉很多資源?

所以,以下是他們的報告:

1. SPE真的非常powerful。

Lots of good examples of SPUs doing useful things
– ‘Offline’ image processing
– Animation
– Physics
– Compression
– Progressive meshing
– Blend shapes
– Extreme vertex/triangle processing
(see: The Naughty Dog guys talk from gdc 2007:
https://ps3.scedev.net/projects/gdc_2007) *:需要帳號
– Clearly very powerful!

2. 但因為架構的關係,它沒有強到可以提供GPU fillrate的代用方案。
當初David Kirk所曾提到的Post-processing的作法,實用度也不高。

Not so hot at replacing fillrate
– Bit difficult to use it as a substitute GPU
– Can’t really render part of the scene on SPU and combine results on GPU
Triangle rasterisation setup, streaming…
Hardware filtering, mipmaps, perspective correction…Antialiasing,zbuffering,stencilling…
GPU really benefits from having dedicated hardware for this
Would be god damn complicated

– Also not really workable for post processing
Render scene >dma round through SPUs >process >render through GPU again
Could delay results by a frame?
Still not particularly desirable and large amount of data to move

3. 但是SPE卻很適合Texture Generation;而因為結構上的設計特性,RSX也可以相當有效率地讀取這些東西,而這個作法也可以比較容易整合進繪圖流程裡面。
也就是說,Enlighten在PS3上作法,其實是透過SPE產生以材質為形式的資訊,讓RSX可以取用。

Most previous work has focused on vertex based operations
– Makes sense given flexibility of SPUs

RSX can efficiently read textures straight from main memory
– Huge advantage for generating anything intended for the GPU on the SPU
– One of the best points of the PS3 architecture

Textures easy to process on SPUs
– Simple to stream in/out in chunks
– However, random accesses need to be made coherent – so not much good if you can’t do this

Easy to do inplace modifications
– Possibility of progressively updating a texture
– No need to double buffer if you get sync right

4. 不過這東西因為是用額外材質的方式送給GPU,所以要加進原來頻寬就很吃緊的繪圖流程中會變得比較困難,比較好的方式是整合一些壓縮來減少頻寬負擔。

Memory bandwidth is likely to be the bottleneck
– Generating large textures is going to generate problems in a heavily loaded system
– Generating full screen images still going to be unfriendly
– Compression is your friend
– Need to make your memory usage count

Textures are just a storage medium
– Ultimately just a way of getting data into shaders
– Many possibilities!

原理講完了,來點爽快的數字吧,Geometrics提供了他們在SPE上執行的效果與性能數字。
基本上Enlighten本身為了求可以整合進客戶的繪圖流程,他們表示Enlighten本身在一般的GPU(這應該指的是Xenos,或者是同時期的高階SM3 device,在GDC06[06Q1]的時候應該是G71和R580)上可以達到100fps的速度(也就是大約10ms左右),這樣才能在實際工作的狀況下,維持60fps。
當然它使用到了Render to Texture之類的技術,所以頻寬其實吃得也不會少,如果GPU負載高的話他們也有提供offload到Host CPU(比方說Xenon的Host CPU其中一個thread、或者是PC上的Multi-Core)的功能。

但是在PS3上,他們企圖全部由SPE來處理。因為RSX其實頻寬並不是很充足,做Render to Texture本身就是個很耗資源的事情。

Originally implemented a GPU version for reference on the PS3
– Runs perfectly fine, but expensive resource

結果SPE…. 實在太快了。XD
在1個SPE上只佔了5ms的執行時間,幾乎是60fps(15ms per frame)下1/3的單SPE資源,或者是SPE總資源的5%左右(5/ 15×6 大約5.5%)
(順道給個對比,當初まいにちいっしょ用了總共4個SPE來達到30fps,大約135ms;不過因為本身型態所致,他們畢竟沒有花很多時間在optimize上;而Geometrics的optimize工作,至少有從1月收到PS3硬體,到五月 Devstation07 發表之間這段時間可作,他們主要的業務也是這個)

SPU version much faster
– System runs in 5ms on a single SPU (!)
– That’s = 1/3r d of an SPU @ 60 fps
– Or 5% of the total SPU potential at 60fps

That’ s why we are excited
– Algorithm is scalable so we can crank up the quality
– Still need to explore possibilities unique to the PS3
– SPUs are more flexible than GPUs – haven’t really exploited this yet
– Very promising future!

這超屌的….如果前面的100fps(10ms)的數字是確定的話,那相當於單顆SPE就可以比C1、R580和G71還快兩倍。(!)
總之,除了GPU讀texture之外,實質上對GPU沒有額外的負擔;相對於其他系統而言需要GPU做R2T再讀回來需要兩倍的頻寬與時間,又會影響GPU的PS可用資源,即使offload到CPU上,也會另外需要足夠的I/O頻寬來負擔傳輸所需。
PS3有SPE處理、FlexIO提供充足的頻寬,RSX針對主記憶體內的材質做了改進,使得Enlighten在PS3上的執行變得非常有效率。想當然爾,這讓Geometrics非常振奮,並預期還有很大的進步空間

不過這也預告了一件事情:就像上面Geometrics所提示的內容,SPE畢竟和RSX之間有距離限制,高度整合的fillrate replacement(如讓SPE做AA)、或者是post-processing確實是不很實際,未來的SPE assistence應該都會在Texture Generation的基礎上做。

相關的討論在PIL也發了一份。
http://we.pcinlife.com/thread-806346-1-1.html

充滿期待才會受傷害

Elite的三紅….身邊遇到一個案例。

聽說這位仁兄GOW大約跑了1hr左右吧,遇上hang然後Reset,就掛成這樣了。
畢竟拆機報告也看得出來Elte晶片並沒有換,散熱結構一點小修改並不是絕對安全的作法,如果強化的散熱裝置和製程更換的措施兩頭並進,或許安全性會高一點點。

實話是Elite未上市前媒體就碰過ROD了,人實在是不能鐵齒。
http://www.gamingbits.com/content/view/2422/2/

現在只剩下黑歷史….