http://nueda.main.jp/blog/archives/004374.html

40nmプロセスのハイエンドGPU Radeon HD 5800シリーズの仕様

從40個TMU/800個SP變成48個TMU/1200SP，所以每個array的SIMD unit等於從16個變成20個，假設每個SIMD unit還是5D的話。

或者說從160個5D shaders，變成240個5D shaders。shader的運算資源號稱2.1TFLOPS(950MHz)、搭配256bit 4.6GHz GDDR5，共有8x4RBEs，並宣稱支援DX11。

所以要比crossbar的話這邊也不小….(12×8)

—-

http://game.watch.impress.co.jp/docs/series/3dcg/20090417_125909.html

西川善司の3Dゲームファンのための「KILLZONE 2」グラフィックス講座(前編)

PS3のハイクオリティグラフィックスはDeferred Shadingでキマリ!?

http://game.watch.impress.co.jp/docs/series/3dcg/20090424_153727.html

西川善司の3Dゲームファンのための「KILLZONE 2」グラフィックス講座(後編)

～オランダ精鋭部隊がCELLプロセッサで実装した「脅威推測型AI」の秘密

只要會吃掉20%以上RSX執行時間的post processing，就設法改轉給SPE作。結果SPE作真的很有效率….

於是繼geometry之後post processing也轉給SPE作…. 連AI也轉給SPE作。

RSX越來越包袱了_A_

well這也沒辦法，半路臨時找救兵。

號稱Bulldozer的真面目之類的

http://pc.watch.impress.co.jp/docs/column/kaigai/20090424_153641.html

チップスタッキング技術でメモリウォールを破る2010年代のCPU

http://www.cc.gatech.edu/~loh/Papers/isca2008-3Ddram.pdf

3D DRAM

上次提到stacked memory，和eDRAM有個差異是：其實很多時候我們知道，eDRAM如果能做到和主記憶體差不多大那很多事情都迎刃而解。

而stacked memory (or 3D memory)有這個潛力，因為雖然eDRAM時代說容量有限，問題是code的規模成長也不是那麼線性，能拿來利用的資料越來越多是沒錯，但是成長的幅度也沒有那麼誇張…. 如果CPU上頭已經有個512MB~1GB的話，那是真的很多事情都會被改變，更別提8GB這種大規模。

以我自己的觀點來說，GPU顯然也會得力於stacked memory，除非GPU廠商得不到這個技術。(這還不太容易想像)

而且在繪圖的case上，同時兼顧大頻寬與相當規模的容量、以及相對低的latency，可能會改變不少GPU的設計也說不定。

GPU在繪圖用途上的頻寬利用率肯定比GPGPU即CPU來得高，這點是無庸置疑的，所以論從3D memory技術上的”得益比”，GPU反而會比CPU高得多。

可是從整合的觀點來說，問題就在於市場對GPU性能需求成長的腳步，比方說audio市場也是不斷地有在進步，但是需求沒成長的話進步就只停留在專業市場上了。所以GPU的問題其實不是技術面的成長會被CPU趕上，而是如何解決需求疲軟的問題。

這點是不是該拿去問黃仁勳….XDa

CPU自己遇到的memory wall的問題，根據AMD的slide可以整理成下面幾個時間點。

1. CPU和DRAM的cycle越差越遠－

用on-die cache + OOOE，讓程式的latency可以縮短，來解決這個問題。

2. 第一次軟體生產性危機－

為了克服規模成長造成的軟體生產性下降而使用物件導向，甚至是script language的JIT compile，結果software reuse製造了大量而小規模的memory access，軟體的整個working set都變大，使得on-die cache的規模與階層複雜度都跟著成長，到現在在die上佔的比例大幅超越CPU core，所以難以稱作”解決”。

3. 遇上ILP之牆，導致multi-core化－

已經很龐大的software working set變成複數個，但是對外能用的記憶體系統仍然受限，沒辦法等比例地擴大，所以CPU一定得在自己內部把問題先給解決一部分才行，結果就是memory-controller on-die，使得多個memory access可以更有效率地消化(當然沒那麼完美就是)，然後cache規模也持續增加中。

然後差不多4.也要跑出來了：AMD的slide裡面預想了「第二次軟體生產性危機」的部分。

4. 第二次軟體生產性危機－

core數量的增加造成軟體上”free lunch”的終結，必須要朝向平行化發展之外，透過異質多核心(& stream computing)的導入帶來的運算資源擴充，CPU結構變得加倍複雜，以抽象化來隱蔽硬體複雜度的做法，也造成軟體結構上又會再膨脹。最後是運算資源擴充之後，可以消化的資料當然也變得更大，那麼沒有搭配更多記憶體頻寬的話，要如何去消化掉這些增加的需求呢。

上面的3已經遇到了一個問題是，memory會慢的原因是天生的，memory cell始終就是只能run在100~200MHz這個點上，所以記憶體系統的強化一直都只能走高頻寬，然後延遲就越來越大，延遲的問題只能交給CPU(or GPU)自己在結構內消化掉。GPU因為使用到的data reuse性低、而且運算性質上dependency也低，所以光靠threading就可以相當有效地處理掉latency問題；CPU這方面就複雜得多，如果要維持現有的code可以在新的CPU上得到性能成長，那真的是會很辛苦。

反過來說，為了利用CPU設計上「繞路」的結果，軟體的coding style被強制要求更改，這代表演算法大多要重新開發，我們要從頭去思考軟體如何解決問題，痛苦的日子終於要來了。stream computing 遇到的問題其實就是programmer畢竟是最懶的生物…._A_)a

stacked memory在這個slide上面被視為有希望的解法，如果stacked memory(3D memory)可以順利導入的話，on-die可以有機會建構相較於過去來說極大的cache容量，來消化掉上面這幾個問題；不過還是掛上了一個”？”，畢竟實現性上有不少問題，良率和散熱都是新的挑戰，以前Intel和IBM都提出過所謂micro-heatpipe之類的東西，讓疊起來的chip可以每層連出一些heatpipe，把集中在中央的熱給取走。