呃，這邊稍微解釋一下....這篇是敝人在配合 Pcinlife 站長 Edison cho在該站GPU論壇所發出的一份文件所寫的一些簡易導讀。
由於這套sdk商業化的時間其實很晚(與該單位屬學術單位轉投資，直到今年7月才籌資到四千萬美金有關)，所以先前一直很少有遊戲使用到。

不過其實這套SDK有一些特性值得討論：

1. 它本身的原始設計是GPU-based，一開始在XBOX360和PS3上也都是這樣執行的
根據Geomerics的人員在2007年2月的時候表示，XBOX360上也可以達到720p@60fps，PS3一開始也是以RSX來執行，效果與一般的平台無異。

2. 然後他們開始嘗試移植這套引擎到SPE上，因為這套工具提供在GPU本身工作負擔較大時，將部分工作轉移到CPU上的功能。
CELL的PPE性能有限，只能移植到SPE上。

3. 他們一開始也對SPE充滿疑慮。但是經過四個月的工作之後，發現SPE的效果比預想中來得好，所以建議PS3上直接以SPE取代RSX來執行這一個工具，以確實發揮Enlighten的功能。
也就是說是SPE在結構上的某些特性讓這套工具跑得特別快。由於XBOX360的VMX128同樣有128個128bit registers，所以能有這種效果，應該是SPE內LS的低latency發揮作用。

現在比較值得注意的事情是：
1. Radiosity的工作量畢竟還是會隨著面數線性成長，即使考慮RT3D需求，仍然很讓人懷疑這套工具能不能在現有的主流遊戲環境中，以他們宣稱的效率執行。
如果可以的話那當然是萬幸.... 不然大概只能把toro貓的skylight移植版(那真的很吃資源)替換掉而已。

2. 這套工具的研究過程與結果其實證明SPE與RSX之間的輔助關係的限制與當初設想的相同。
也就是說SPE與360的eDRAM結構是完全相反的方向，所以SPE沒有辦法改善RSX相對於C1的弱項。

Texture Generation指的是利用運算動態產生材質，或者說程序材質也可以。

首先，Texture可以視為一種查表的動作。
查表過去的用途是因為運算速度不夠快，所以用事先計算好內容用一個表格存起來，等於用記憶體空間和頻寬來換速度。
當然隨著最近的技術進步，我們開始發現記憶體的速度不夠快(延遲、頻寬等等)，半導體的集積量成長的速度超過記憶體系統的演進速度。
所以就開始出現"直接計算說不定比查表還快"的想法。

只是這邊純粹是"SPE算得比GPU快，所以SPE算完之後讓GPU用"。
本來Enlighten的流程是讓GPU透過Render to texture存起來，然後在下一個pass的時候使用，所以前面這段流程換成SPE並沒有什麼問題。

當然啦，即使運算本身不是問題，在PS3上用SPE產生材質還是會有下述的限制：
1. 需要空間存放(CELL讀寫XDR的速度顯然比GDDR3快，所以你也不能直接寫入GDDR3)
2. 需要頻寬傳遞，延遲也會是個問題
這些都需要實際上的實驗才會知道結果....

----
HeavenPR不是有在這邊出沒？這種東西應該請他來解釋才對啊。

引用:

原帖由 ibelieveicandie 于 2007-8-14 15:00 发表
那么，在X360上用一个硬件线程来进行同样的操作效率如何？

"理論上"應該會不錯，因為PPX也有128個register，也設計了主記憶體直通L1的程序；
不過畢竟Enlighten移植XBOX360得非常早(Geomerics在今年1月才拿到PS3 sdk，同時間XBOX360版都已經快發表了)，如果有成果的話其實沒有理由不講....

所以也許只與一般的CPU相去不遠而已吧。
可能Enlighten是個記憶體延遲吃重的演算法，所以對cache類的結構不太適合。

引用:

原帖由 hourousha 于 2007-8-14 15:18 发表
哦？HPR参与了该SDK的研发？

我倒不是這個意思....
我只是想說，實際工作內容就是寫遊戲的人應該會嘗試做這種東西吧，應該有機會接觸到。

http://filecoreinuse.livejournal.com/154268.html
這位仁兄似乎是developer.....
然後他表示
"On the XBox 360 we can get >60fps at 720p."

引用:

原帖由 村上春樹 于 2007-8-14 15:22 发表
texture generation 是把材質用算的來生出來，這會比較不容易實作出與遊戲美工概念相符的東西吧?

Eji 有沒有Enlighten Demo的圖像可以放一張上來看看

如果看得到Youtube的話可以試試這邊。
http://www.youtube.com/watch?v=L1pfCUmEoCs
雖然細節因為解析度掉了一些，不過原則上Radiosity特有的環境光自然過渡勉強看得出來。

流程上Enlighten只是產生類似lightmap的方式讓GPU當成lighting的憑據而已，應該不會造成多少衝擊；
不過Radiosity是個photorealistic風格的東西，如果遊戲本身美術風格是偏向比較誇張的，
那的確是幫不上什麼忙。
以效果來說，這是個很樸素的東西....

[ 本帖最后由 Eji 于 2007-8-14 15:41 编辑 ]

引用:

原帖由 zhangjingy 于 2007-8-14 18:10 发表


FSF会说，不讲不代表不成。

呃，說實在的，C1做這個特效並不會慢。是這時候的SPE強得異常....

其實這算是該讓很多人醒覺的時候，CELL和RSX畢竟是兩顆隔著I/O bus兩端的晶片，沒有辦法像一開始SONY講的一樣作用得這麼緊密。
頻寬也沒有大到SPE可以做多少事情，只能做[高度運算後產生資料數量不是那麼大]的東西。
所以做AA，做即時後製都沒有希望的狀況下，能做的事情就比先前講的少很多了。

當然要不是有FlexIO，RSX沒辦法很有效率地取得SPE產生的資料，短期內GPU市場也很難出現SPE這樣有一堆register的GPU，這都會限制住GPU在這方面的能力。
除非現在有人可以設計另一顆具備FlexIO介面的GPU，來和CELL配合....

引用:

原帖由 ibelieveicandie 于 2007-8-15 16:56 发表
你能想出在多少情况下有这必要呢?
实际上,同样的绝对性能下,SPE这样的general purpose processor肯定比GPU内嵌的专用tesselation, shader, vertex fetch, ... 等units有更灵活的功能。这也是为什么我前面 ...

這邊會產生另一個問題：ROP和CELL本身整合很困難，General Processing Unit和ASIC(TMU/ROP)兩邊的clock會互相影響。

G8x算是已經很厲害了，常規運作下Shader clock可以到1.5GHz，但是這個peak還是沒有達到CELL那種時脈，更別提SPE多得是可以上6GHz的測試。
而分成兩個晶片的話，I/O的頻寬和延遲都會讓運作變得很困難，所以GPU那邊怎樣都會需要一些可程式化能力。

這也是當初4PE/32SPE的CELL想單顆解決一切的最大瓶頸之一，即使它本身設計上有100GB/s的記憶體頻寬....
我們可以想像一下，4顆CELL和一個GS(I-32)合起來的話會產生多少問題。

比方說我們今天要是把CELL做成32SPE、然後GPU照樣用RSX、甚至用更簡化的Rasterizer的話，那可能會造成更多限制，
SPE不容易完全在沒有TMU輔助作addressing/filtering的狀況下動作，這也是G8x的TCP設計最核心的觀念：
shader的動作與texture息息相關，兩者之間的interconnection至關重要。

SPE作rasterization的部分我有點質疑，Triangle Setup有必要這麼多靈活性嗎？

不過Radiosity/Ray Tracing的話SPE問題就不大，而且實在很快...
所以用Texture generation的形式扔給RSX是個好點子，只要CELL的主記憶體容量再大一些，如果CELL有512MB記憶體的話，這方面可能會無敵好一陣子。
過去我認為SPE直接render到RSX是個點子，不過RSX那邊的實作看來限制了這部分....

[ 本帖最后由 Eji 于 2007-8-15 18:01 编辑 ]

引用:

原帖由 ibelieveicandie 于 2007-8-15 09:52 发表
关键不是大家（游戏开发者）想用spe做什么，而是spe能做什么。

就目前来看物理运算是没问题的，这也算是spe作为CPU一部分的本职工作之一。
另外spe应该还是可以做做和gameplay无关的事情，比如生成粒子，草，等等（前提是rsx有这个能力去渲染）。
spe还可以后台解压缩，比如video/audio data streaming，background loading。

sony号称会有一个AI的middleware可以让spe执行ai，但目前还没有进一步信息。假如spe能很好的执行ai的话，对于游戏来说实用意义可以大N倍。

SpeedTree有個SPE的版本，KZ2也宣稱用SPE作particle，不過KZ2的particle目前看來精確度不算高，可能和頻寬有關？
照理說KZ2那份pdf的SPE runtime應該就是執行時間，但是不知道SPE的總執行時間多少，所以很難知道SPE跑particle有用到多少時間。

SPE的AI執行類型應該會有些限制，不過實話是都有人拿EE的 VU 跑 neural network了，我也不知道什麼不能跑啦。XD

引用:

原帖由 爱你一棒陲 于 2007-8-15 11:02 发表

知道不知道HALO3的粒子系统就是基于GPU的，而且ATI很早就展示过基于R5XX的GPGPU系统，演示的就是复杂的粒子运算，DEMO里就是20万个。真是孤陋寡闻，无知啊无知～～～

particle system用GPU跑是個點子沒錯啦.... 不過就和Enlighten一樣，製造太多render pass給GPU我覺得不見得是好點子。

引用:

原帖由 爱你一棒陲 于 2007-8-10 16:18 发表
nAO32啊？似乎改名MDR比较合适，HDR的H体现在何处呢？32位RGB可不算哦。

? C1不是FP10嗎？記得eDRAM內的Alpha blending都是用FP10啊。

引用:

原帖由 zhangjingy 于 2007-8-15 18:43 发表
老E把我的问题忽视了。
LAIR对于CELL的图形辅助做出了什么成绩吗？

有啊，只是不太想講：Lair使用的剛好是先前JC大神批評的方法之一。

JC大神表示，他認為他的MegaTexture技術使用上比較有效率，實作上也比較簡單容易，不需要用強力的CPU作很複雜的LOD系統。

Lair則是選擇用CPU作LOD的典型，Lair實作的是Progresive mesh，可以隨著遠近距離動態改變場景的複雜度。
這已經不是新技術了，也有人在GPU上實作過。

[ 本帖最后由 Eji 于 2007-8-15 19:59 编辑 ]

引用:

原帖由 zhangjingy 于 2007-8-15 20:06 发表
难道LAIR图形方面做得不好吗？看来很多技术高深的人都没有掌握好CELL使用的最佳方向，主要是能做的事情太多了。

別急著這麼說，有時候這真的和擅長的方向有關。
科學運算的領域都是如此了，何況沒有什麼研究開發資源的遊戲市場。

這邊舉個例子：
Programming the Cell Processor

DDJ寫程式的應該很多人知道....他們刊載過一篇CELL在HPC optimize的相關文章。
有個很傷眼睛的例子在page3:

一個只有60行程式碼的小程式，BFS(breadth-first search，寬度優先搜尋)，學校作業等級的東西。
不屬於這個領域但想知道BFS是什麼的可以參閱Wikipedia維基百科。

DDJ在第三頁也列出了他們使用的程式碼。
在一台Pentium4 HT 3.4GHz上跑的性能是每秒鐘搜尋2千4百萬個邊(24million/s)，
重寫過後的程式，CELL上面的性能則是每秒搜尋5億3千8百萬個邊(538million/s)。

也就是說在CELL上面透過有效的最佳化，得到了一顆Woodcrest約22倍以上的效能，一顆SPE就有1.5(35million)~4.75倍(114million)不等的實力，總性能足以和256顆CPU版的BlueGene/L單挑；不過在此同時，他們最佳化的程式碼也長了20倍，達到1200行。_A_
(該文後面有詳解，想了解如何在CELL上寫好程式請不要錯過)

好，這是鼎鼎大名的DDJ，三位作者都是任職於PNNL的專家，而他們在標題上就寫值得努力。
那遊戲界有多少人有這個能耐？有多少人想花這個時間？花的時間和金錢是不是和效能成正比？
我們看看他們現在的態度就知道了。

[ 本帖最后由 Eji 于 2007-8-16 06:23 编辑 ]

引用:

原帖由 eastspider 于 2007-8-16 06:12 发表
看来Cell的性能果然是P4的22倍呀！！！！

天师看好了，再发一贴

Cell你究竟有多强悍！！！秒杀！！！

不要光看數字啦.... 單一SPE可以跑到最高接近5倍，也就是說這其實也是個4個SPE之後性能就不會明顯提升的狀況。

此外，BFS是個AI領域會用到的基礎演算法，有改良過的技術。
這個演算法本來根本沒幾行，但是原文提到的最佳化技術一狗票，
loop unrolling, function inlining, SIMDization比較常用， bulk synchronous parallelization, DMA traffic scheduling, overlapping of computation and transfers就比較少見了。
(第一步就搞迴圈展開，這也是在講SPE真的不適合做分支)

總之，這的確是會讓人擔心實際遊戲用到的演算法，真的要最佳化不是沒辦法，性能也可以預期....(而且是專家預期的)
但是只怕複雜度超出大部分遊戲廠商的能耐，要花的時間(成本)對廠商來說大概是天文數字。

所以一般狀況下，廠商不是不能而是不為的機會最大。
當年有人在EE的VU上做過類神經網路模擬，所以很多技術的事情沒深入了解真的別亂說。

[ 本帖最后由 Eji 于 2007-8-16 08:30 编辑 ]

引用:

原帖由 爱你一棒陲 于 2007-8-16 09:09 发表

是7E3 FP10浮点像素精度没错。总比INT8和nAO32色彩正确，比上不足比下有余。

FP10有沒有比nAo32這我可不敢確定....

引用:

原帖由 RacingPHT 于 2007-8-16 10:25 发表
小程式与大程式的区别是巨大的 。Eji兄毕竟不是程序员, 有些话其实你不是很适合说。
DDJ这篇文章我们这边第一时间就已经看过了, 其中一个明显的疏漏, 就是拿手工优化的SPE ASM与最原始的C代码和P4比性能。 ...

其實就我所知，大部分的狀況CELL的性能都是拿optimize過的asm code和x86 C code比性能。
這不是在講"這樣比正確不正確"，而是在講"這其實是最常見的狀況"....即使這個情況有問題。

這邊有另一個反例：
當初Pentium4/Core2Duo的SACD decode，optimize到最後還是可以在2GHz上的Core2 Dou上順利執行，也被Intel Compiler當成成功案例宣傳。
廣告：http://jp.xlsoft.com/documents/intel/case/sdna_case_study.pdf
後面VAIO系列的DSD direct player就是透過這點達成的，前後性能差了3.5倍.... 而這還是靠compiler和optimize達成的，意義更大。

而PS3的SACD CODEC主要的目的是為了累積CELL上操作的know how，所以它企圖做到的optimize degree會比較高。
另外一個問題是，一個較少自動功能的CPU本身的可optimize程度也會比較高。(OOO之類的CPU行為是很難人力預測的)

-----
然後前文每篇都有提到遊戲廠商有合理成本的要求與壓力，後面跟幾篇內容無關的回文，就變成小弟的原文有問題了，這不是很奇怪....

[ 本帖最后由 Eji 于 2007-8-16 13:04 编辑 ]