我發的前幾篇標題都不好，所以另開一篇標題。
11/24 報的paper：Optimizing Assignment of Threads to SPEs on the Cell BE Processor
請點此另外進度報告我們切的方式是要在QP=25，INTRA_PERIOD=30才能得到最好比較好的Performance
----------------------------------我是分隔線--------------------------------12/01
請點此測了幾個Block的時間~
最先一開始是讓SPE去讀檔案，然後扣掉檔案的讀取時間。
所測得的時間非常不穩定，時間上下抖動的範圍太大。
之後就想到，疑？是不是讓PPE去讀進來放到External Memory，
然後再去從External Memory去抓這些資料就好。
試了之後效果還不錯，
不過這又產生一個大問題了。
當PPE去讀取很大筆的資料放到Memory，例如要花了兩百多MB。
當我去測它的執行時間時，它的執行時間範圍就有時2秒、有時51秒。
差距非常大。我想了一想，也許是用到虛擬記憶體導致變慢。
所以我將要讀進來的檔案切成五等份， 每一等份是23681筆資料。
每一次我就只做一等份，之後再將這所有的五等份時間相加，得到每一個component時間。
之後所測得的時間就蠻穩定的。
註：老師說時間很奇怪，建議只接收一筆資料，同一筆資料做很多次。
再測其時間看看有沒有變。
----------------------------------我是分隔線--------------------------------趕緊來記一下跟老師討論的文件大綱
第一章 Overview(大綱，提到Toshiba)
第二章 Cell BE硬體架構
第三章 編譯環境
3.1 PS3上的作業系統 - Yellow Dog Linux3.1.0 安裝作業系統
3.1.1 介紹Toolchain
3.1.2 如何編譯
3.1.3 其他Compiler (XLC compiler)
3.2 Cell Simulator3.2.0 安裝Simulator
3.2.1 介紹Simulator的各種mode
3.2.2 如何編譯
3.2.3 各種mode跑幾個範例
第四章 Library的使用：寫程式介紹很多API
第五章 自製Toolchain
---------------------------我是20081208分隔線-----------------------------投影片內容說明了我們怎麼測SPE的時間
另外還有Queue的實作方式，未來會越改越好地。(希望)
註：拿GNU Pofiler測試一下時間，確定各個block時間的合理性
Future work就是把Queue通通的改成漂亮的Queue，
然後做小實驗。
我是投影片---------------------------我是20081222分隔線----------------------------- 今天報了有關Cell B.E. blocking, non-blocking channel的介紹
Intro: 每一個SPE上MAILBOX或Signal或其實都是一個個的channel。
透過MMIO(Memory Mapped I.O.)去抓取任何一個channel都將是non-blocking。
SPU讀寫channel的話，要根據channel的type決定是blocking或non-blocking。
我是投影片
進度報告：
實作了將DMA做成多筆一次傳，跑出的數據是多少。
實作了另一種版本的Queue，此版本Queue只有一次DMA，測出數據是沒有達到預期效果。
未來要再解一些bug。
刪了某些圖的投影片---------------------------我是20081229分隔線-----------------------------1.
今天報告另外一種切割的方法，簡單的說就是做os的task分配的意思，讓每一個block都能
夠滿滿的、負擔都差不多，不要一直只等著事情做。
2.
報告程式流程
Future work:
解決在一開始的初始化時資料被蓋掉的情況
註：下星期與忠和學長討論有關SystemC的部份
投影片---------------------------我是20090105分隔線-----------------------------一. paper的outlinedata-flow for mpeg4 decoder on cell
1. Introduction
i) multicore programming
ii) data-flow, Pipelined
iii) MPEG4 on cell
iv) cell architecture, programming thread communication
v) Related Work Difference (only MB-level parallelism)
vi) Contribution
2. Design Methodology
i) mpeg-4 component graph
ii) profiling computation communication
iii) Task Allocation
3. Queue Implementation
i) Mailbox/Signal/DMA Synchronization
ii) Batch Transfer
4. Experiment Results
第一個是不同傳輸方式
第二個是不同切法
第三個是不同node數
5. Conclusion
二. 書的outline
當然是還沒有...
目前我有稍微看過阿六仔寫的書，我還沒有看的很仔細。因為看簡體字也需要想一下。
個人觀感是書的前半部份感覺像是英翻中的手冊，例如講一下SPE的架構，然後列出有哪些指令可以用，感覺比較稍微草率一點，後半部份的某些章節我覺得還不錯，例如它有一章列出你可能會遇到哪三樣錯誤，然後這錯誤大概是因為什麼。
我覺得這章節很不錯，如果使用者遇到的錯誤都能在這本書找到所以然，這本書的價值也許會比較高。
---------------------------我是20090108分隔線-----------------------------Toshiba SpursEngine
Toshiba所出的這塊媒體串流器(SpursEngine)與Cell B.E.的不同點有
1. Cell B.E有8顆SPE，SpursEngine只有4顆
2. 為了Low Power的設計，將減少的4顆SPE換成MPEG-2與MPEG-4/H.264 Encoder/Decoder
3. 不採PPE為主CPU，可用PC上的Intel Processor
4. IO變更
以上4點摘自
東芝半導體公司披露繼承Cell設計構思的處理器真面目reference:
[1]
Full HD趨勢化的波濤，掌握加工編輯關鍵的影像處理引擎提到了各種影像處理的加速卡優缺
---------------------------我是20090217分隔線-----------------------------
1. 本書導覽
2. Cell BE 硬體架構
2.1 PowerPC Processor Unit
2.2 Synergistic Processor Unit
2.3 Element InterConnect Bus
3. Cell BE 工具列
3.1 安裝Yellow Log Linux
3.2 安裝軟體開發工具列SDK3.0
3.2.1 Cell Simulator
3.2.2 compiler
3.2.3 Eclipse IDE
4. Cell Programming基本概念
4.1 Process and Thread
4.2 Create SPE Thread
4.3 Create PPE Process
4.4 編譯程式
5. Direct Memory Access
5.1 MMIO concept
5.2 DMA concept
5.2.1 mfc_put, mfc_get
5.2.2 barrier和fenced
5.2.3 alignment
5.3 DMA List
5.4 Double buffer
5.5 Atomic Method
6. 訊息傳遞與同步
6.1 Mailbox
6.1.1 介紹SPE的Mailbox種類
6.1.2 PPE與SPE之間的通信
6.2 Signal
6.2.1 介紹SPE的Signal種類
6.2.2 PPE與SPE之間的通信
6.2.3 OR-mode與Overwrite Mode
6.3 使用DMA達到SPE之間訊息傳遞
6.4 使用Queue達成資料資料傳遞
7. Vector Programming
7.1 在PPE上使用SIMD
7.2 在SPE上使用SIMD
7.3 PPE與SPE上使用SIMD的異同
8. 錯誤解決
---------------------------我是20090224分隔線-----------------------------今日報告，
完成Queue Type II的Doble Buffer，
我們交互使用兩個不同的參數與標籤(TAG)，以節省Communication time。
未來要做的事
1. channel(queue) code generator
2. scheduler code generator
欲先完成第一件事，在經過簡單的程序建立如下的Graph後，
能夠幫我在每個core build channel，並在consumer core初始化queue。
scheduler code generator要等到我把這個先弄完才會繼續，
目前怕參數太多，產生出來的code很複雜。
老師的comment：
1. 未來Cell Programming搭配OpenESL GUI，拉幾下就就可以build connection (這點應該沒問題)
自動產生scheduler，需要user告知scheduler額外資訊。
今天我誤會老師問我的問題？老師問說scheduler寫在哪裡？
scheduler的code當然是另外寫的一支程式，產生的code是跑在componenet裡。
我以為老師是問產生的code跑在哪。
我們目前是想說scheduler會產生一張圖，什麼時候哪個core該做什麼事，都在這張圖上。
目前大概就是這樣，萬事都想好，只欠一步一步完成。
---------------------------我是20090303分隔線-----------------------------
欲用一個Graph來代表Core與Core之間的溝通機制，
所以我們建一個Graph，經由加Vertex與Directional Edge(有向邊)，
語法
1. Add Vertex ex: myGraph.AddEdge(VLD);
2. Add Edge ex: myGraph.AddEdge("VLD","IMC1","IQ_para","IQ_ARRAY");
Vertext 代表module name，Edge代表channel，如同我們在SystemC語法宣告一個channel，
必須給它一個channel type和channel name，後面這兩個變數就是這個Edge的Feature(屬性)。
依據這個圖我們可以分析每個Vertex，它是當了幾個Core的Producer，自己是誰的Producer。
根據這樣的資訊建立channel initialize Code。
下一步就是scheduler code generator，而scheduler code還在改，希望能簡單到可以自動產生，不然原本的code太複雜了。
-----------------------我是20090317分隔線-----------------------------User一開始會給我們以下幾個資訊
0. DataFlow的流程圖
1. Core的數目，Ex: 現在要跑在6個core上面
2. 每一個Task的loading Ex: VLD必須花500 ms，IMC花2000ms等等的資訊
我們根據以上的資訊，找出最好的Duplication
演算法我們這邊就不提，以後補上。
根據演算法我們會產生每一個Core的Scheduler Graph，如下圖11個duplication分給6core
根據這張scheduler graph，我們能夠建一張Table描述core與core之間的communication關係之後根據這張Table我們就能跟建立之前我們所說的communication graph，之後就能使用communication(channel) code Generator。目前只做channel code Generator，接著再將code改一改就能完成codeGen了。
老師今天的comment:
1. Eclipse GUI與阿凡討論，列出規格與規劃進度，之後meting拿出來討論進度
2. 4月之後希望能開始改SIMD，然後將改完的SIMD的時間再來重新build graph，讓大家知道不一樣的load會產生不同的scheuler graph
3. 希望未來能再porting一個codec上去，希望這個scheduler code generator是夠general的
Core 0 |
VLD0 |
VLD1 |
VLD2 |
VLD3 |
VLD4 |
IQ3 |
VLD5 |
IQ4 |
VLD6 |
IQ5 |
VLD7 |
IQ6 |
IDCT2 |
VLD8 |
VLD9 |
IQ8 |
VLD10 |
IQ9 |
IQ10 |
Core 0 |
0~419 |
419~838 |
838~1257 |
1257~1676 |
1676~2095 |
2095~2705 |
2705~3124 |
3124~3734 |
3734~4153 |
4153~4763 |
4763~5182 |
5182~5792 |
5792~8065 |
8065~8484 |
8484~8903 |
8903~9513 |
9513~9932 |
9932~10542 |
10542~11152 |
|
Core 1 |
IDCT3 |
IMC0 |
IDCT5 |
IMC1 |
IMC2 |
IMC3 |
IMC4 |
IDCT8 |
IMC5 |
IMC6 |
IMC7 |
IMC8 |
IMC9 |
IMC10 |
Core 1 |
2705~4978 |
4978~5484 |
5484~7757 |
7757~8263 |
8263~8769 |
8769~9275 |
9275~9781 |
9781~12054 |
12054~12560 |
12560~13066 |
13066~13572 |
13572~14078 |
14078~14584 |
14584~15090 |
|
Core 2 |
PB0 |
PB1 |
PB2 |
PB3 |
PB4 |
PB5 |
PB6 |
IQ7 |
PB7 |
IDCT7 |
PB8 |
PB9 |
PB10 |
IDCT10 |
Core 2 |
419~1162 |
1162~1905 |
1905~2648 |
2648~3391 |
3391~4134 |
4134~4877 |
4877~5620 |
5620~6230 |
6230~6973 |
6973~9246 |
9246~9989 |
9989~10732 |
10732~11475 |
11475~13748 |
|
Core 3 |
IQ0 |
IQ1 |
IDCT0 |
IQ2 |
IDCT1 |
IDCT4 |
IDCT6 |
IDCT9 |
Core 3 |
419~1029 |
1029~1639 |
1639~3912 |
3912~4522 |
4522~6795 |
6795~9068 |
9068~11341 |
11341~13614 |
|
---------------------------我是20090401分隔線----------------------------
今天報的是有關IBM所開發的Accelerated FrameWork(ALF)
附上投影片
---------------------------我是20090408分隔線----------------------------
今天提出兩個問題，其中之一已能妥善解決，以下描述我遇到的問題。
1. 初始化中，Race Condition的問題。解決方式：使用PPE做主端控制，將控制權依順序交給各個SPE做初始化。同時間只有一個SPE能做寫入的動作。這樣雖然初始化會慢了一點點，但是卻能不用變更到現層的架構所提出的方法。
2. 遇到架構上的缺限，scheduler所產生的排程，應用在core與core之間的channel對應會有問題存在。
目前先寫論文，目前要兩步驟方式，
第一 產生scheduler圖
第二 檢查schduler圖可否產生code，可以的話gen code。
---------------------------我是20090414分隔線----------------------------
解決conflict的問題。Future work: 當candidate list為空的時候，找尋workload此少的core去assign。
數據看起來不make sense，目前要固定某種變量，看數據跑出來的狀況。
1. 為什麼相同Duplication, 比較多Core卻較差
2. 為什麼相同Core, 比較多Duplicatoin卻較差。
是不是因為Queue SIZE未達到最佳的臨界點。
我目前打算產生兩樣數據
1. 固定每一個core的Queue Size，測出數據圖。
2. 紀錄每張圖的最佳Queue size是多大。
---------------------------我是20090429分隔線----------------------------
老師的comment
1. 更改演算法，讓4core在1個duplication下的時間能比3core在1個duplication的時間少
2. 產生出來的數據有多點疑問，必須一一釐清
2.1 Estimate的時間怎麼會比Real跑出來的還慢？必需再去確認這方面的code有沒有錯，還有就是Estimate的時間要再精確點，例如使用SystemC去model整個執行環境。
3. codeGen有一些bug存在，必須把它解掉
4. mplayer那部份的code要重寫，整合Eclipse IDE部份
5.列出論文大綱
第3,4,5點的部份我會先把它做掉，之後再從第1、2點開始解。
---------------------------我是20090512分隔線----------------------------
根據這張圖，老師的疑問說，為什麼4core在1個duplication會比3core的執行時間長。
我們更改程式分配行為，每一顆core上有兩種時間，一種是current time，另一種是workload time。workload time本來是紀錄是此核心上的所有的Task的時間總和。我們現在加上idle time。current time是目前該核心的時間。我們是根據最小的workload來分配Task。
此圖是更改後。
老師的comment，解釋3,4core在1個duplication的時間為什麼會一樣，5,6core為什麼在1個duplication的時間會一樣，而且會比3,4core好。
解釋1. 4 core的執行時間會一樣，是因為task的之間有dependency的關係。如IDCT0要等到IQ0做完才可做，所以雖然多了一顆核心，但是最長的執行時間仍然坐落在做IDCT0與IMC0的核心上。
解釋2. 5,6 core的執行時間會一樣，是因為在1個duplication的狀況下，Task有5個，所以剛好可以分配給五個core。但是多了一顆core其實是沒有做事的。
小新的問題：為什麼4,5core同樣的Estart Time，5core卻會比較好？
解釋 5core在1個duplication的狀況下會比4core好，是因為剛好每一個task都分配給一個核心做。而沒有dependency的Task，可以自由的先執行，例如VLD1不用等IMC0執行完才做，所以這樣的時間就會重疊起來。所以執行時間是該核心最後一個task的結束時間減去第一個Task開始的時間。
小新的問題: duplication的名詞有點怪，以為是要等到1個Macroblck都做完才能輪到下個Macroblock做。
阿拉給我的旨意: 想辦法取每一個Module的最佳的程式時間，但分配用的是平均時間。
-------------------------------------------------------------------------------------------
將程式部份的名稱改的好看
函式名稱有個DB代表使用Double Buffer機制
DB_funName(para1,para2,para3)
para1用來表示channel是跟誰建立的，如圖中的C_SPE0
表示我是當Consumer，SPE0是Producer。我要接收從SPE0傳遞過來的資料。
ToSPE3(para1,para2,para3);
To後方接的名稱代表我要將計算完的資料重送到哪一個core，例如SPE3。
如果是要傳送給做IMC的core，因為我們使用角色互換的trick。
所以它不是固定給哪個core做，這裡我們使用ToIMC傳遞參數
這個函式會幫我們判斷OutputSel是0或1的時候要送給哪一個Core。
我們的CodeGenerator要寫的適合各種case的話
必須讓User設定很多參數，例如要讓這些code執行多少次，要使用的Function是input、output是什麼。
所以我們原先的使用方式是我們先將程式改成可以Codegen的格式，再來寫code generator
而目前沒有辦法做到任何case都可以適用，最大的問題也許是角色互換的那個trick。
再來就是我們要幫它們的module function 建立Double Buffer機制、然後傳遞資料時要有TAG的資訊，TAG不能都用一樣的，因為會有效率上的問題。
期待學弟了解這些機制後和寫法後能夠改善。
