1. Larrabee 架構主要目的為multi core Software renderer。
會場給予的presentation可以看出，Intel 透過遊戲測試數據，認定目前的rasterizer架構並沒有顯著的固定load，所以沒有必要準備fix pipeline。
他們將包含rasterizer、ROP等目前GPU既有的fix func stage全部改為software。
2. Intel 實際的實驗device命題，為”與Core2Duo相同的規模下，更換為Larrabee版的x86 core，能夠得到多少的繪圖性能boost”
他們在4MB 65nm 版Core2Duo相同大小的晶片上，放上了10個具有16way Vector的x86 core、一定數量的TMU(性能與規模不明)。
Core與TMU是分離，並且全部採512bit 雙向 ring bus 互聯。
內建microOS，以軟體方式模擬DirectX/OpenGL硬體功能，並且在內文不時指出”不必重新設計”的好處，以及”比較聰明”、有硬體指令集作加速的software rasterizer。
運作模式類似tile、每個core有L1與256KB的L2 cache，與Ringbus互相連接，但是否與材質共用則不明。
(更正：Larrabee有獨立的32KB texture cache)
3. 根據Intel的統計，core數量與性能為線性關係。
8cores為1x下、Gear Of Wars在48core下得到6x performance boost。
對asic fix-function pipeline的性能與電晶體規模優勢，他們以software的靈活性、以及重新設計的小core有足夠優勢來回應。
這個結構畢竟是實驗用，是否與未來產品有絕對相同的關連不明。
但是以Intel在內文 不時強調的特點來說，至少multi-core CPU + TMU，software rasterizer這兩個特性應該是不會改變了。
對Intel來說，NV與AMD/ATI手上持有的大量繪圖相關專利，是他們踏入繪圖市場最大的障礙；但是NVIDIA與AMD是以ASIC電路設計的方式呈現出來(來保證效率)，缺點就是每一到兩代可能就得重新設計。如果每個世代的產品都有固定規模的loading、非得做這些事情的話，那就還算是值得；但是似乎不見得是如此。
Intel 的想法是，CPU core執行的software rasterizer在”效率”(考慮overdraw等”會被浪費的性能)上必然是最佳的，並且可以不斷地改進；問題是x86 core目前在desktop市場上的核心具備了不少”與繪圖無關的特性”，比方說較長的pipeline、較強大的分支預測等等，造成以電晶體的規模來看，CPU來執行繪圖工作時，效率會與GPU有很大的差異。
所以他們要做的其實是個”最小限度並且最高效率的x86 core”、來滿足software rasterizer執行上的需求，只要縮小到某個範疇，CPU執行software rasterizer的效率就會趕上GPU設計ASIC的效率，原因是每次重新設計，NV與AMD不可能花費過高的成本在設計上，一定是採用library來兜，就不會像Intel把設計高度optimize時必然會採用的customize design。
當然這樣講相當籠統，說起來CELL也是在尋找”最小規模、最低成本但最高效率的SIMD processor”，然後加以不斷擴充數量而已；問題是Intel 認為，沒有使用與host CPU相同的ISA，造成programmer需要學習兩種不同的programming model，而造成推廣上的困難，所以Larrabee為了考慮未來與CPU core的整合、programmer在存取這些core的時候不需要學習等訴求，仍然提供了一個有完整記憶體保護功能、分頁功能的x86 core，只是只提供in-order design、dual-issue，管線設計上接近過去P54c的規模。
所以到底需要做多少”GPU的功能”在上面，就變成是量化研究的重心了，這也是這回Siggraph2008上Intel將會發表的內容。
以結論來說，Larrabee實質上可以說是把各種GPU的工作，比方說各種fix function pipeline，以指令集的方式實作進CPU，這部分可能不會公開(這樣未來就不需要處理相容性的問題)。
當然這樣的好處是可以處理一些繪圖上奇奇怪怪的需求，比方說過去ROP必然在pixel shader與memory controller中間，所以如果今天pixel shader想要用到”另一個、前一個pixel的z值”這種奇怪的演算法，那就得在ROP設計上另外支援。
但是沒有硬體化的話，顯然地throughtput大概不會大到哪去：比方說 RV770在SIMD core上的TMU(4×10)、與ROP的texture cache(4組)之間有320GB/s的頻寬(cross bar)，Larrabee的512bit雙向ring bus宣稱1TB/s，那代表傳輸量至少要有8Gbps，考慮2GHz運作的話可能是切成四段，或者是1GHz八段(同時有八個資料在ring bus上傳輸)；但是以傳統的觀念來說，ring bus的頻寬絕對不敷IMR使用的關係，所以Larrabee勢必要引入一些其他的設計，比方說模擬GPU動作的microOS部分，就需要動一些腦筋，才能節省頻寬。
一個參考的數據是，目前已知最快的DX9 class software rasterizer－Swift Shader，在Core2Quad上面執行Crysis的時候，在640×480還達不到10fps。
http://www.transgaming.com/products/swiftshader/
現在Larrabee可以明顯看到的是，他們將運算的要素全部解開，以他們熟悉的實作法加以重組，並且放入CPU的設計裡面，最後再用micro OS之類的方式包裝成GPU；畢竟他們還很不熟悉GPU市場(上一個i740已經是很久以前的事情了)，第一個產品出槌的話透過這種方式還有得改。
當然了，既然Larrabee打算讓software rendering相關的動作都有專用的指令集加速的話，那應該可以到相當快的地步才是；可是這樣的話其實等於你還是把所有ROP該有的要素都給做進去了，這些指令集硬體實作上的效率其實也是很值得關注的；Larrabee的整個cache系統還不知道能不能滿足需求，但是cache至少會讓程式好寫一點；CELL和CUDA的share memory最典型的問題，就是工作的workset超過那個容量的話，就會變得非常麻煩….現在還沒人可以在cache設計讓從Intel手上討到便宜的緣故，這也是Larrabee在通用運算部分最有吸引力的地方。
想想之前他們還在嚷著GPGPU沒有意義，CPU的core很快就會多到沒人想用GPU算東西；現在他們的產品也要出來了….XD
其實事情很單純，GPU這種形式的產品單一thread性能不高、靠高平行度衝thoughtput，所以記憶體系統為了拉高頻寬，延遲通常非常大，和現在CPU要求低延遲、單一thread執行性能得很高的狀況有很大的區別，所以如果Intel還是想賺這個錢，大概就得設計一個符合這種需求的晶片才行，那就可以視為GPU(or throughtput-optimized processor)而不是CPU；反過來說，那麼你就很難把GPU直接吞進CPU了….一個針對thoughtput需求optimize的core，和現有的CPU的設計上其實還是不少衝突的。
光讓Intel承認這點，就可以說是NVIDIA的大勝利了也說不定。
—–
延伸：
http://www.tacc.utexas.edu/~cburns/papers/izb-tog.pdf
The Irregular Z-Buffer: Hardware Acceleration for Irregular Data Structures
http://attila.ac.upc.edu/wiki/index.php/Main_Page
Attila Project
The Attila Project goal is to research and develop high performance microarchitectures for the next generation of GPUs. To this end, the team has started by exploring the performance of the current generation (R580, G70, G80) of rasterization-based GPUs. So far we’ve produced a full GPU (soft) stack: an OpenGL driver, an Attila driver, and a cycle-accurate simulator of the first incarnation of the Attila architecture. Additionally, the team has produced helper tools to capture open GL traces, play the captured traces and a WaveForm visualizer for the Attila simulator.
fiber：user-customize micro threading。(….可自訂的微執行緒？)
http://blog.chinaunix.net/u/18517/showart_734498.html
http://softwarecommunity.intel.com/articles/eng/1677.htm
In the Win32 threading API, there is a threading option called fibers that enables users to write their own thread scheduler and so exert fine-grained control over threading operations. This too is not possible in OpenMP.
—–
http://pc.watch.impress.co.jp/docs/2008/0804/kaigai457.htm
ついにベールを脱いだIntelのCPU&GPUハイブリッド「Larrabee」
全部重畫，後藤老爹實在是太猛了。_A_
文件裡面其他關於延遲隱蔽、thread & fiber、vector reorder unit在內的全部都仔細解釋，他老人家果然沒把NDA放在眼裡….
不過後藤老爹說「Larrabee的software stack與GPU不同，它本身執行micro OS，將host CPU上的工作在Larrabee內的core完成」，我看起來是沒有這種感覺….它應該是把software rasterizer 寫在micro OS裡面，然後透過driver包裝成一張普通的GPU；但是因為有一般CPU等級的靈活性，所以你可以把很多過去要host CPU作的事情，透過DX11的compute shader或者是Larrabee自己的programming model來執行，host CPU就除了發號施令之外閒閒沒事….但是這其實GPU目前也是如此，不然難不成要說是”不需要driver的GPU”嗎？那好像又不太對。
另外，抽象化當然是好事沒錯，但是抽象化帶來的overhead自然是無法忽略，所以你要是想衝出peak performance，那麼你還是得要意識到GPU實際硬體的vector長度，我想這點Larrabee也不會不同就是了。
但是同時支援DX11 compute shader、自己本身的專用native C/C++ compiler都可以存取這點，看起來和CUDA相比是已經有抗衡的態勢就是了。(當然CUDA很可能會影響DX11 compute shader的結構，所以差異大概不會像Larrabee這麼大)
http://anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3367
Intel’s Larrabee Architecture Disclosure: A Calculated First Move
這邊就乾脆直接貼了XD
Intel Software Network at SIGGRAPH 2008
http://softwarecommunity.intel.com/articles/eng/3803.htm
Siggraph08 paper本體。
http://softwarecommunity.intel.com/UserFiles/en-us/File/larrabee_manycore.pdf
