找到原因了...，原因有點囧就是了。

那就是 Shady 的測試主程式中的此段程式：

    for(i = 32, j = 0; i > 0; i--, j += 128) {
        __dcbf(d + j);    /* 就是當中的 d+j，Shady 寫成 s+j 了。*/
    }

因為 Shady 的測試程式一開始就是為 memcpy 類型的函式撰寫的，
所以會配置二個記憶體空間，
一個為來源 s、一個為目的 d，
故一直以來 Shady 都如上面程式解說般，
目的記憶體 d 都未從 cache 中消除，
而 memset 類型的函式就一直使用 d 而未更正，
因此 d 一直堵塞住 cache 而 Shady 卻不自知。
現在更正之後，
16KB 記憶體空間的測試就正常了，
但 setmem 的成績還不怎麼理想，
因為它還有至少 30 tick 的空間可以改善，
所以 Shady 下次放出的組語函式有可能是 setmem 修正版或 memcpy 的組語版，
也有可能二者同時釋放，
但不久之後 Shady 會比較忙，
所以釋放的頻率會比現在更低上很多，
因此請大家多體諒。

超過 16KB 的記憶體配置後，造成程式緩慢之因素的猜測。

Shady 之前曾說過，
當配置的記憶體容量超過 16KB 時，
不管是出自 Linux 本身之函式、別人之函式或 Shady 的，
都將有很高的 tick 值出現。
而此情形有可能大於 4KB 記憶體配置就會出現，
只是 Shady 還未有稍大於 4KB 的測試就是了...XD

現在 Shady 最大的懷疑是" cache 堵塞"為主要原因，
因為不管是出自別人之函式或 Shady 的，
都有不當使用過多和未適時使用 lvxl、stvxl、dcbf等指令，
而這些指令都是將 cache line 標記為"最近最少使用"或"無效化"，
所以目前 Shady 正在實驗這些指令的特性和它們在程式中的順序，
以更改配置的記憶體容量超過 16KB 時所造成的大失速。

當然主要的原因可能不在此處，
但目前也只能朝這方向猜測，
因為都已經用組語撰寫了，
甚至還避免使用微碼指令。
所以除了這個方向，
Shady 實在是想不出還會有啥其它的原因...囧rz

memset 函式的組語版：setmem。

新的函式出爐囉：

setmem 原始碼。

這次也附上 setzero 的 bug 修正版：

setzero 修正版原始碼。

這次不論是 setzero 修正版或 setmem 都有加上 Altivec ABI，
這通常是編譯器做的事，
但在組語中，程式設計師只有自己手動撰寫，
有 Altivec ABI 的地方，Shady 會用 /* altivec abi */ 做註解。

至於成績，這次 Shady 只放出其 tick 值，如下:

setzero 修正版：16 ~ 17 ticks。
setmem：93 ~ 94 ticks。

這次的測試是用 4KB 的容量為測試對象，
在測試時，主程式是用 C 語言撰寫，其內容大致上如下：

#include < stdlib.h >
#include < stdio.h >
#include < ppu_intrinsics.h >    /* PPU 在 C 語言下的專用底層函式表頭。*/

extern void setzero(void *, int);

int main() {
    unsigned char *d;
    unsigned long long i, j,start, finish;

    if(posix_memalign((void *)&d, 128, 4096)) {    /* 配置一對齊 128 Bytes */
        printf("failed\n");                        /* 邊界的 4KB 記憶體空間。*/
        goto end;
    }
    for(i = 32, j = 0; i > 0; i--, j += 128) {
        __dcbf(d + j);            /* 將所配置的記憶體空間，從 cache 裡消除。*/
    }

    __dcbt(setzero);            /* 將 setzero 函式預先提取到 cache 中 */
    __dcbt(setzero + 128);    /* 這也就是為什麼 setzero 的 tick 值較 */
    __dcbt(setzero + 256);    /* 上次小的原因，而要做 __dcbt(); 多少次，*/
    __dcbt(setzero + 384);    /* 需要視 setzero 之大小，而 __dcbt(); 一次載入 */
    __dcbt(setzero + 512);    /* 之大小為一 cache line，共 128 Bytes。*/
    __dcbt(setzero + 640);    /* Shady 建議最少六次，以掩蓋 cache、memory 的延遲。*/
    __sync();        /* 同步、排空整個 PPU 管線。*/

    start = __mftb();
    setzero((void *) d, 4096);
    finish = __mftb();
    printf("%lld\n", finish - start);    /* tick 值的計算兼印出。*/
end:
    return 0;
}

老實說，這次的 setmem 成績不太理想，
而且還有當配置的記憶體超過 4KB 時，
一次所要設置的記憶體量不要超過 2KB，
否則將看到 2000 ticks 以上的成績出現，
這種狀況，不論是 Shady 的函式或別人的函式，
甚至是 Linux 的 libc 都會大失速。
當然 Shady 會找出原因所在，
而 setmem 的效率，Shady 也會盡量改進，
之後 Shady 還是會不定時釋放出新函式或修正函式，
只不過，可能頻率不會太常，
請大家見諒。

好想買個 GTX580 ~~XD

雖然現在 Shady 所使用的 GPU (GT200系列的入門款) 能支援CUDA，
但效能不佳，又沒錢換更好的，
看樣子得多爭點錢了...囧rz

目前 Shady 正在收集 CUDA 的相關資訊中，
也正在選擇是要在 Linux 下，
還是 Windows 下把玩 CUDA 或被 CUDA 把玩中，
而 Cell 的 PPU 的字串相關的組語版，
Shady 還是會不定期釋出新的函式，
只不過會不太常更新就是了...，
因為 Shady 有事情要忙了，
希望大家會諒解。

心情好差！

將一句平凡無任何傷害之心的噓寒問暖的關心話，
說出來關心他人還被那個人當垃圾，
而且為此和 Shady 大吵一架，
而對方的理由是 Shady 多管閒事？
真不知大家會有何感想，
尤其是那個人居然是自己的家人...。

最後想了一想，
不只是對方錯了，
Shady 還很雞婆呢？
如果說家人都這樣了，
很難想像親戚、朋友給的反應會是如何？
反正心得很簡單：
少說少錯，
而事情做多也不一定對。

因此任何事都應該以不傷害他人為考量前提，
然後讓自己自私一些是沒錯的，
就算對方是自己的家人也是一樣，
因為良心、良言這種東西永遠是被踐踏之物，
所以除非對方主動找上門，
要不然你的良心、良言千萬不要主動付出。

經過此事後 Shady 也體會到社會會如此冷漠不是無原因的。

忘了說的事項。

嘿嘿~~！
真是不好意思，
Shady 忘記向大家說明如何在 C 語言程式中呼叫組語函式了，
以 Shady 之前釋放出的 setzero.s 為例：

#include < stdlib.h >

extern void setzero(void *, int);
int main() {
        unsigned char *d;
        int a = 4096;
        if(posix_memalign((void *)&d, 128, a)) {
                printf("failed\n");
                goto end;
        }
        setzero(d, a);
end:
        return 0;
}

以上就是使用 C 語言程式呼叫 setzero.s 的例子，
當中的 posix_memalign 函式為配置一對齊 128 Bytes 邊界的記憶體區塊，
其大小為 4K Bytes。

最後 Shady 說明一下如何組譯、編譯程式，
首先是對 setzero.s 做組譯之指令：

ppu-as -o setzero.o setzero.s -mcell -maltivec --gdwarf-2

當中的 -mcell 選項為對 Cell CPU 做組譯，
而 -maltivec 為 VMX 的支援組譯選項。

假如上例的 C 程式的檔名為 test.c，
其編譯指令為：

ppu-gcc -o test test.c setzero.o -g

如此將二程式放在同個目錄下按順序在文字模式下輸入以上二個指令，
執行檔 test 就會出現在同個目錄下了。

bzero 函式的組語版：setzero。

setzero原始碼。

在此 Shady 簡略談及 ELF ABI ，
若想詳細了解，請參考 Shady 給的連結。

在 Linux 下的 ELF ABI 下撰寫組語程式，
函式的整數參數會依序放在 GPR3 ~ GPR10 共8個，
其中的 GPR3 也是回傳值的存放處。
其它詳細資訊請參考 Shady 文章開頭給的第二個連結。


另外 Shady 還要說明 32 bits 寬度的 "條件暫存器" (CR)，
CR 被分成八個域：CR0 ~ CR7，
一個域有 4 bits 寬。
其它詳細資訊請參考 Shady 給的連結。
 
最後要注意的是，
組語中的暫存器，如：GPR0 ~ 31、FPR0 ~ 31、VR0 ~ 31，
這三種暫存器的名稱在相關指令下以編號替代，
如 GPR0 在整數指令下用 0 代替。
若指令結尾為 i，如：addi、cmpldi等，
其最後的運算元必為立即數。
 
若想多了解 PowerPC 組語者可至 IBM 的官網搜索相關文章。
 
最後公佈 setzero 函式的成績，
以 4KB 為測試且有對齊 128 Bytes 記憶體邊界：
 
4096 Bytes / ( 25 ticks * 40 cycles ) * 3.192GHz = 13.07 GB/s。
 
若無對齊 128 Bytes 的狀況下，
會比有對齊多出約 10 ~ 15 ticks 不等。

以後 Shady 會不定時放出與 bzero 這種字串函式相關的組語函式。

撰寫 Cell 的 PPU 之組語所需的知識及技巧。

這次的文章，
Shady 將分享一些組語程式的知識及技巧。

首先寫組語或其他語言之程式時，
若只要求能運作、能有正確結果，
那程式就不會快了，當然，
以上要求也是寫程式時的第一要求，
但當為了程式最佳化的話，
就必須針對您所控制之晶片的架構有所熟悉才行。

所以我們有必要知道 Cell 的 PPU 之架構，
而它的架構敘述如後。

在 Linux 使用者空間下，
能使用的暫存器有 32 個整數暫存器 (GPR)、
32 個浮點暫存器 (FPR)、32 個向量暫存器 (VR) 和連結暫存器 (LR)、
計數暫存器 (CTR)、整數例外暫存器 (XER)、條件暫存器 (CR)、
浮點狀態控制暫存器 (FPSCR)、向量狀態控制暫存器 (VSCR)、
向量保存暫存器 (VRSAVE) 各 1 個，
至於每個暫存器寬度 (所能容納的 bit 數量)，
按以上介紹順序為 64、64、128、64、64、64、32、32、32、32。
由於 PPU 只支援大端記憶體排序，
所以以 GPR 來說，其最大的 bit 在最左端，編號為 0，
最小則在右端，編號為 63，
故十六進位數值 0x800000010 在暫存器中，
bit0 之數值為 1，之後的 bit1 ~ bit61 皆為 0，
而後的 bit62、bit63 各為 1、0。
其餘暫存器的詳細介紹就請各位參考 IBM 的 Cell 網頁之文件了。

不要以為知道暫存器後就高枕無憂囉。
接著要介紹的是 PPU 對指令的處理過程。

PPU 是個循序單核心、雙執行緒且管線深度很深的 CPU，
所以在程式撰寫上，盡量以執行緒撰寫，
雖然執行緒不如雙核心之效能，
但也能盡量將其管線填滿。
故 Shady 推薦在 C 以上的高階語言，
盡量以此方式撰寫，如 Linux 上的 POSIX 所提供的 pthread。
可是 "雙執行緒" 對組合語言適用嗎？
Shady 的回答是對小函式是不適用，
而大函式亦不適用。

為什麼大、小函式都不適用？
因為小函式太過於殺雞用牛刀了，
而大函式則是開發困難，
所以通常以 C 等高階語言主程式的 thread 來呼叫組語函式為佳。

所以我們需將焦點轉移到單一執行緒上的指令處理，
首先要注意的是 "指令相依性"，
"指令相依性" 指的是第一個指令的結果為第二個指令的運算元，
遇到此狀況會導致第二個指令延遲，
若第一個指令為微碼或複雜指令，
將會導致 6 ~ 11 個以上的 CPU 週期且避免 "雙發射"，
所以最好以二個獨立指令交互排列且盡量不使用微碼和複雜指令，
其例子如：

add  ra,rb,rc
add  rd,ra,re  /* 此行與前一行相依 */
add  rf,rg,rh
add  ri,rj,rf  /* 此行與前一行相依 */

改成：

add ra,rb,rc
add rf,rg,rh
add rd,ra,re
add ri,rj,rf

會比較好。

再來介紹 "雙發射"，
它的意思是單一 CPU 週期能發送二個不同執行單元之指令，
而這也是 "單執行緒" 用來加強 IPC (Instruction Per cycle) 的機制，
雖然在單一執行緒程式很難全都 "雙發射"，但不無小補。
至於 PPU 有多少執行單元且哪些指令是對應什麼執行單元，
就請各位多參考 IBM 的文件了。
以下為 "雙發射" 的典型例子：

add  ra,rb,rc  /* 整數單元 */
ldx  rd,re,rf  /* 加載 / 存儲單元 */

此二個指令中間並沒有其它指令，
這樣子的指令排序方式就能令 "雙發射" 成立。

最後 Shady 要介紹最後的一項技巧："分支演算法"。
"分支演算法" 被提出的原因為分支的代價對 PPU 效能的影響很重大，
因為分支的成功與否都會因分支後的指令不在指令快取中，
而且分支的預測也會對循序架構的 PPU 有效能衝擊，
因而導致慢長的 CPU 週期延遲，
所以為了提升整體程式之效率，
減少分支指令是勢在必行的。
雖然 "分支演算法"  不會比分支指令的最好例子快，
但平均下來，"分支演算法" 會較好。
以下為 C 的 if 例子：

if ( a >= b ) {
    c = b;
} else {
    c = a;
}

其組語 "分支演算法"：

sub  rd,ra,rb  /* a - b */
srdi  rd,rd,63  /* 取出正負號 bit */
neg  rd,rd  /* 取正負號 bit 的 "二捕數" */
and  re,ra,rd  /* a 和正負號 bit 的 "二補數" 做 and 運算 */
andc  rf,rb,rd  /* b 和正負號 bit 的 "二補數" 的 "一補數" 做 and 運算 */
or  rc,re,rf  /* c = a 或 c = b，使用 c = a | b 運算式運算 */

雖說 "指令相依性" 不少，
但只要有更多的 "分支演算法" 或獨立指令交互穿插，
就能掩蓋 "指令相依性" 造成的延遲。

下篇文章中，
Shady 將會提供功能相當於 bzero 函式的組語函式，
而且會說明組語撰寫的一些注意事項。

轉戰 Cell 的 PPU 組合語言或彙編語言(對岸的說法)中...

為什麼 Shady 會這麼突然要轉向組語呢？
理由很簡單...

因為編譯器的最佳化好麻煩，
有多麼麻煩呢？看以下分析就知道了。

雖然目前使用 C 語言就能碰到很底層的指令操作，
使用如 intrinsic 這類利用 C 行內組合語言做成的巨集或函式就能辦到，
但還是很難滿足最佳化的需求，因為還有很多指令是沒有 intrinsic 的...
就算自己製作，但 register 就很難用 C 控制。
最後交給編譯器的選項做最佳化，但魚與熊掌有時無法兼顧...
因此在需要了解很多編譯器選項和 C 程式中的編譯器指令下，
麻煩就出現了...

我只是弄個簡單的函式，
有需要搞得如此複雜嗎？

前篇 memcpy 的結果很清楚，
在 Shady 的編譯器選項中有最高的最佳化選項和避免某些微碼選項，
但效果之慘，後來 Shady 參考別人的程式，
有組語和 C 的程式，Shady 已將自己的 C 能做好的已做好了，
但 Shady 的 C 是用 VMX 撰寫的，卻還是輸給別人的 scalar 組語，
甚至使用別人比 Shady 還簡潔的 VMX 的 C 還是輸五倍。

以下是 memcpy 的最新測試結果，
4KB 為測試之容量且對齊記憶體 128 Bytes 位址(裡頭有更好的頻寬算法)：

再次告知 PS3 有一秒 79800000 ticks，
時脈為 3.192GHz，所以 1 tick 有 40 個 CPU 週期。

別人的 scalar 組語：4096Bytes / (62 ticks * 40) * 3.192GHz = 5.272GB/s
別人的 VMX 的 C：4096Bytes / (318 ticks * 40) * 3.192GHz = 1.028GB/s
Shady 的 VMX 的 C：只有 ~400MB/s ... ，說真的 Shady 的程式也很簡潔了。

所以總結就是 Shady 需要更簡潔的 C 撰寫和更多更適當的編譯器選項，
因此簡單的函式能用組語寫就用組語寫吧！

libfreevec 的 memcpy 函式測結果。

先聲明 PS3 的記憶體頻寬有 25.6GB/s。
因為 PS3 的時間測量是以 tick 為單位，
而 PS3 有 79,800,000 ticks per second，
所以 Shady 會把比較結果換算成 GB/s 來比較。
以下為 Shady 的測試結果對比，
記憶體拷貝容量以 16MBytes 做測試。

Linux memcpy：
約 8,000,000 ticks，16*1024*1024/(8000000/79800000)/1000000000 = 0.167GB/s

freevec memcpy：
約 1,590,000 ticks，16*1024*1024/(1590000/79800000)/1000000000 = 0.842GB/s


Shady loop prefech freevec memcpy：
約 597,500 ticks，16*1024*1024/(597500/79800000)/1000000000 = 2.24GB/s

結果只能說悽慘...，
還有 Cell 模擬器是個"快樂模擬器"，
因為它的 tick 為 25,000,000 ，且換算後的頻寬又較高，
更以 freevec memcpy 的測試數值最高，有超過 25.6GB/s 的 50%，
但 Shady 猜想此模擬器應該是對應 PowerXCell8i 版的 Cell，所以會有所不同。
看樣子得重寫個沒有 loop 版的 prefech memcpy 才行了...XD

訂正：
以上的測試與計算方式有誤，
因為三者是在同一程式按順測試，
所以順序越後者，其速度較快。
在 Shady 重頭一一測試後，
"Shady loop prefech freevec memcpy"項之 Tick 值約為原本的四倍不到，
而其餘二者則高出 10000ticks 多以上。
而計算頻寬之方式，
Shady 還在尋找其他方法。

撰寫程式來讓 PS3 顯示 BMP 圖 (程式篇)。

這次的程式篇，說實話是沒什麼好說明的，
因為大部分的說明，Shady 已經放進 Shady 的程式原始碼的註釋中了。
但在程式下載連結之前，Shady 要說說這程式的運作慨要。
這程式最多只能顯示與 PS3 的 YDL 上所設定的解析度大小的 BMP 圖，
所以若照 Shady 之前 YDL 瘦身文設定的話，
那麼 BMP 圖的解析度最大為 1280 * 720。
還有這程式只能將圖片顯示在螢幕正中央。

程式原始碼連結。

在這建議 Cell Performance 這英文 Blog，
當中有不錯的文章，也有 Blog 主人自製的 PS3 FB 函式。

撰寫程式來讓 PS3 顯示 BMP 圖 (VMX 篇)。

記得之前有關 libfreevec 的文章吧？
若不記得，請翻閱 Shady 之前的文章。

這次並不是像之前一樣，
VMX 只是約略簡介而已，
這次 Shady 要講解在"撰寫程式來讓 PS3 顯示 BMP 圖 (程式篇)。"中，
有使用的VMX指令。
這次要介紹的 VMX 指令是 vec_perm，其使用詳細請行如下：

#include< altivec.h >
vector unsigned char va, vb, vc, vd;
vd = vec_perm(va, vb, vc);

它的實際運作如下：

若 va = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}，
而 vb = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16}，
且 vc = {0, 16, 1, 17, 2, 18, 3, 19, 4, 20, 5, 21, 6, 22, 7, 23}，
所以 vd 的結果會是 {0, 1, 0, 2, 0, 3, 0, 4, 0, 5, 0, 6, 0, 7, 0, 8}。

為何如此，解釋如下：

內容：va va va va ... va va va va, vb vb vb vb ... vb vb vb vb
位置：00 01 02 03 ... 12 13 14 15, 16 17 18 19 ... 28 29 30 31
以上是 va 和 vb 之內容與位置對應的表示圖，
所以 vc 的內容是 va 和 vb 之內容所對應的位置，
也就是說 vc 代表為索引用的變數。
因此這個範例之結果為 vd 的第一元素為 va 第一元素，
而 vd 第二元素為 vb 第一元素，
再來 vd 第三元素為 va 第二元素...之後以此類推。
vc 的每個元素的索引值範圍為 0 ~ 31，不能低於 0，也不能高於 31。

OK！Shady 就只介紹這個 VMX 指令，
其它指令請參考此處(小心，當中有些指令是 Cell 的 PPU 所沒有的)。

為什麼 Shady 只介紹 vec_perm 呢？
因為 BMP 的顏色保存順序為 alpha、藍、綠、紅，
所以 Shady 才會才用 vec_perm 來搬運資料，
以至於顏色會對應成 PS3 的 FB 的 alpha、紅、綠、藍順序。

下一篇就是"程式篇"了。

撰寫程式來讓 PS3 顯示 BMP 圖 (函式篇，下)。

在上篇文章的最後，Shady 介紹了 ioctl 函式，
它會視裝置而有不同用途的第三個參數，
接下來 Shady 將解釋如何使用 ioctl 控制 FB。

首先 Shady 先略提 Linux Frame Buffer I/O，
然後接著介紹  PS3 Frame Buffer I/O，它可以說是很底層的控制了。

如果有大略觀看過 linux/fb.h 標頭檔，
將會看到很多有關 Linux Frame Buffer 之內容，
當中會有可成為 ioctl 的第二參數 cmd 的要求碼，
還有 bit mask，它是用來過濾 ioctl 的輸出資料用的。
在這 Shady 只介紹一個重要的要求碼 FBIOGET_VBLANK，
因為它會告訴我們有關系統的掃描操作，
如果 ioctl 使用此要求碼會回傳一個 fb_vblank 結構，
fb_vblank 結構的內容與解釋如下：

○ unsigned int flags：用來辨識掃描狀態。
○ unsigned int count：自啟動來的 traces 數量。
○ unsigned int vcount：目前垂直掃描位置。
○ unsigned int hcount：目前水平掃描位置。
○ unsigned int reserved[4]：保留給以後之功能使用。

以上的 fb_vblank 的內容中我們會用 flags 來辨識是否有支援垂直同步信號，
所以只要將 FB_VBLANK_HAVE_VSYNC 此一 bit mask 與 flags 作 AND 運算就行了。
使用 ioctl 實作的例子入下：

#include< linux/fb.h >
struct fb_vblank date;/*宣告 fb_vblank 結構變數 date*/
ioctl(fd, FBIOGET_VBLANK, &date);/*取得 Linux FB 之資訊*/
if(！(date.flags & FB_VBLANK_HAVE_VSYNC))
      /*做無垂直同步的處理*/

至此 Linux Frame Buffer 就到此打住，
因為以 Shady 對 YDL 的設置是 8MB 的 FB，
這樣的設置對 720p 的解析度而言，會有兩個 FB，
又垂直同步對多個 FB 較重要，所以 Shady 只介紹到這，
想多了解的朋友可觀看 linux/fb.h 這一標頭檔。

再來就是 PS3 Frame Buffer 了。
首先是 Shady 感覺較重要的要求碼，它們被定義在 asm/ps3fb.h 中：

●PS3FB_IOCTL_SCREENINFO：用來獲取 FB 的環境資訊。
●FBIO_WAITFORVSYNC：停止 FB 輸出動作且等待垂直同步信號。
●PS3FB_IOSTL_FSEL：發送 FB 的操作，等於垂直同步的發送。
●PS3FB_IOCTL_ON：開啟讓使用者程式操控 FB 的權利。
●PS3FB_IOCTL_OFF：關閉使用者程式操控 FB 的權利。

以上的要求碼 Shady 只會再介紹第一個，
剩下的四個會在"撰寫程式來讓 PS3 顯示 BMP 圖 (程式篇)。"中解釋。
PS3FB_IOCTL_SCREENINFO 於 ioctl 使用後，
會回傳 ps3fb_ioctl_res 的結構，其內容為：

○unsigned int xres：水平解析度數目。
○unsigned int yres：垂直解析度數目。
○unsigned int xoff：水平 Margin數目。
○unsigned int yoff：垂直 Margin數目。
○unsigned int num_frames：FB 的數量。

至於如何利用這些要求碼，
Shady 將會在"撰寫程式來讓 PS3 顯示 BMP 圖 (程式篇)。"解說。

撰寫程式來讓 PS3 顯示 BMP 圖 (函式篇，上)。

上一篇介紹了 PS3 的畫面 (Frame) 是通過 8MBytes 的改變而改變的，
而這個記憶體區塊被稱為 Frame Buffer ，簡稱 FB 。
所以接下來要介紹 FB 的相關資訊，
以至於大家能在 PS3 上填充自己想要的畫面。

首先 FB 在 PS3 的 Linux 上是一 IO (Input/Output) 裝置，
而 Linux 上的 IO 裝置又有"字元裝置"和"區塊裝置"兩種，
"字元裝置"如虛擬終端機就是個字元裝置，
因為它只能於一時間內接收一字元資料，
而"區塊裝置"顧名思義就是一次能接收一個固定大小之資料。
FB 屬於後者，所以他必須填滿整個 Frame 才能發送出去。

接著要說明的是 Linux 上要如何存取這些 IO 裝置。
由於 Linux 都將 IO 裝置當作檔案來處理，
所以這些 IO 裝置檔案都放置於 /dev 底下，
在文字模式下輸入 ls /dev 就會有一堆檔案出現，
其中 FB 之檔案名稱為 fb0。

既然知道 IO 裝置是個檔案，
那要將其用 C 語言開啟就不用想太多了，
下面就是用來開啟 fb0 的檔案描述子的函式：

#include< fcntl.h/ >
#include< sys/types.h >
#include< sys/stat.h >
int open(cont char *path, int oflags);

此函式只要將第一參數填入 "/dev/fb0" 包含雙引號，
而第二參數則填 O_RDONLY (唯讀)、O_WRONLY (唯寫)、O_RDWR (讀寫) 三者之一，
所以 open 可填寫如下：

int fd;
fd = open("/dev/fb0", O_RDWR);

這是以讀寫模式開啟 fb0 的檔案描述子之例子，
而檔案描述子經 open 函式回傳後，被存放在 fd 變數中。
想知道 open 函式的其餘較詳細資訊請使用 man open 指令於終端機下輸入。
關閉 fb0 檔案描述子可透過 close 函式：

#include< unistd.h >

int close(int fildes);

當中的 fildes 參數便是填入檔案描述子。

再來要介紹 ioctl 函式，
此函式可用來取得 FB 資訊、FB 控制權和 FB 的操作。
ioctl 函式入下：

#include< unistd.h >

int ioctl(int fildes, int cmd, ...);

ioctl 會針對檔案描述子 fildes，執行 cmd 的功能。
它可能還有第三個參數，這個與裝置的功能有關。

至於如何詳細使用 ioctl 函式來取得FB 資訊、FB 控制權和 FB 的操作，
Shady 將會在下篇文章講解。

撰寫程式來讓 PS3 顯示 BMP 圖 (FB 篇)。

這次 Shady 要告知如何撰寫有關在 PS3 上顯示 BMP 圖片，
而要達到此目的，就有必要知道 BMP 儲存格式和 PS3 的螢幕操控、顯示等，
所以 Shady 會將 PS3 的螢幕操控、顯示告知大家，
但 BMP 儲存格式則要請各位自己去 Google ，故在這 Shady 要說聲抱歉了。

首先要先講解 PS3 螢幕上的顯示，示意如下：

當中的白色部份為顯示區，而灰色為 Margin 區(不作顯示之區域)，
Margin 區有分為上下兩個垂直 Margin 和左右兩個水平 Margin ，共四個。
若有照著 Shady 之前的 YDL 瘦身文章來調整解析度，
則 Margin 區是沒有出現的，也就是說整個畫面都是顯示區。

由於畫面的顯示是由多條水平掃描線構成，
而每條掃描線又由多個 Pixel 構成，最後每一 Pixel 則是由 4Bytes 構成，
而每個顏色占用 1Byte，其構成方式，按照順序為：

其中的白色應該是 Alpha 值，但目前好像沒有作用，
其餘為三原色：紅、綠、藍。

最後要說的是整個畫面是對應到之前 YDL 瘦身文章中的 ps3fb=8M，
也就是說在主記憶體區塊中有個 8MBytes 是屬於畫面顯示用，
而此區塊稱為 Frame Buffer，簡稱 FB，
且 8MBytes 則可存放二張 720p 畫面，
所以接下來就是要操控此記憶體區域來改變畫面成你想要的內容。

下一篇文章將介紹一些函式，
它們是用來取得畫面控制權、畫面資訊等。

啟用 libfreevec 來替 PS3 增加些效能吧！

什麼是 libfreevec 呢？

它是一個利用 PowerPC 的 VMX 單元為主的 Linux 的 glibc 替代方案，
而所謂的 VMX 指的是 PowerPC CPU 系列的 SIMD 單元，
以 VMX 的 register 而言有 128 bits 的寬度，
因為它可以用一指令同時命令 16 個 char、8 個 short、 4 個 int、4 個 float 等資料，
所以它可比平時的指令有更多的平行度，
也因此有一定的效能提升。

但它終究沒有完全代替 glibc，
不過它還是有不少有用的替代涵式，
如 memcpy、strcpy、strcpm 等，
光這些基本涵式就有不小的效能增長啦！

好啦！還沒安裝 libfreevec 的朋友，
就請跟著 Shady 的說明步驟前進吧！

1. 請以 root 的身分登入 YDL。
2. 在 YDL 的文字模式或虛擬終端機下輸入 yum install libfreevec 來安裝 libfreevec 。
3. 然後用 vi /etc/sysconfig/libfreevec 來開啟 libfreevec 檔案。
4. 再來按 A 鍵後將 ENABLE_FREEVEC=no 改成 ENABLE_FREEVEC=yes。
5. 最後按一下 Esc 鍵後輸入 :wq 來記錄檔案。
6. 登出 YDL 後再行登入就完成了。

雖然 libfreevec 可在 Cell 上執行，
但由於它是以 PowerPC 為準，
所以 Cell 中唯一有支援的核心只有 PPU 而已，
而且 PPU 比起以前的 PowerPC 有刪減和增加及更改的指令，
可剛好 libfreevec 用到的預先快取串流系列指令都以 nop (無操作指令)執行，
所以利用 libfreevec 的涵式前可能要自己撰寫預先提取的指令了...XD

之後 Shady 會有些文章針對 libfreevec 的最佳化，
主要是針對預先快取的部分，
而有興趣了解 libfreevec 原始碼的朋友可從此處下載SRPM檔，
如有SRPM使用的問題請參考"鳥哥的 Linux 私房菜"裡的文章。

最後在這裡預告下次的文章標題：
撰寫程式來讓 PS3 顯示 BMP 圖。

替 PS3 的 YDL6.2 做瘦身 ( 下篇 )。

這次先從一些原由說起，
由於 PS3 於 YDL 下並沒有太多的記憶體 ( 約 230MB 左右 )，
所以 Shady 大多以跨平台編譯來撰寫程式。

最後 YDL 下的 PS3 都是跑程式時使用，
所以記憶體的節省也很重要，
要不然程式 Port 到 PS3 時就會因記憶體不夠而慢下來...，
故 Shady 在此有一些建議：

1. 請撰寫兼編譯程式於 x86 電腦上。
2. 因 1. 的關係，請將 PS3 當作程式測試平台，
    所以 PS3 最好於文字模式下節省記憶體。
3. 若得於圖型模式下測試程式時，
    請將解析度降低到 720p 以下確保記憶體夠用。

所以當撰寫大型或資料量大的程式時，
記憶體多寡就是我們首要考慮的問題了，
以下是 Shady 對 YDL 做的一些調整，
希望對大家有幫助。

1. 將 YDL 預設為文字模式，
    輸入 vi /etc/inittab，
    將 id:5:initdefault: 更改為 id:3:initdefault:。
   
2. 將 YDL 的虛擬終端機預設開啟設為一個，
    輸入 vi /etc/inittab，
    將
        1:2345:respawn:/sbin/mingetty tty1
        2:2345:respawn:/sbin/mingetty tty2
        3:2345:respawn:/sbin/mingetty tty3
        4:2345:respawn:/sbin/mingetty tty4
        5:2345:respawn:/sbin/mingetty tty5
        6:2345:respawn:/sbin/mingetty tty6
    改為
        1:2345:respawn:/sbin/mingetty tty1
        2:2345:off:/sbin/mingetty tty2
        3:2345:off:/sbin/mingetty tty3
        4:2345:off:/sbin/mingetty tty4
        5:2345:off:/sbin/mingetty tty5
        6:2345:off:/sbin/mingetty tty6
    。

3. 調整解析度為 720p，
    輸入 vi /boot/etc/yaboot.conf，
    將 append="video=ps3fb:mode:3 ps3fb root=LABEL=/1"，
    改為 append="video=ps3fb:mode:3747 ps3fb=8M root=LABEL=/1"。
    其他解析度設置請參考此網頁。
    ps3fb=8M 是為了配合 720p 設置的，
    因為 1280 * 720 * 4bytes * 2framebuffer / 1048576 = 7.03152MBytes，
    但只能填整數，故因而填 8M。

若非得有圖型模式，
可參考這裡，
當中有教導安裝 fluxbox，
而 Shady 使用後，
未開啟任何應用程式的情況下，
還可以擁有 170MB 以上的記憶體容量。

到此，Shady 已將 YDL 的安裝和調校教導完畢，
下次開始就是程式的心得與分享了，
所以請大家多觀看 IBM 的 Cell SDK 的相關文件，
因為 Shady 之後並不會有太多 Cell SDK 相關工具的教導文章，
還請多多包涵。

替 PS3 的 YDL6.2 做瘦身 ( 上篇 )。

老實說，
瘦身工作最好從 YDL6.2 安裝時做起，
當然沒有也沒關係，
以下是從安裝時就開始瘦身的步驟，
已安裝者可從完成 YDL6.2 安裝後的步驟開始。

安裝時請選擇手動選擇套件，
將所有套件勾選成非勾選狀態，
也就是不要安裝所有套件，
如此，YDL6.2 將會自動安裝最基礎的套件，
當然，以上是於 install_ps3_720p 更高的解析度模式安裝，
雖然安裝結果是文字模式，
但卻是以高解析度安裝完成。

接下來就是安裝完成之後的步驟。

進入 YDL6.2 之後，
請以 root 登入，
然後輸入 yum update 更新套件，
若有出現 expat、readline、util-linux 時，
請勿更新套件，
請個別輸入套件名稱更新，
例如：yum update kernel，
以上例子是只有更新 YDL6.2 的核心。

再來就是安裝 CellSDK，
請輸入 yum install glibc* irqbalance，
再輸入 yum install crash* elfspe* libspe* netpbm* oprofile* ppu* spu*，
安裝完成之後就去下載 CellSDK-Devel-Fedora_3.1.0.0.0.iso、CellSDK-Extras-Fedora_3.1.0.0.0.iso、3.1-SDKMA-Linux-ppc-FP01.tar.bz2，
將其放置在 /tmp/cellsdkiso 下，
利用 mount -o loop /tmp/cellsdkiso/CellSDK-Devel-Fedora_3.1.0.0.0.iso /mnt 掛載 iso 檔，
再以 cd /mnt/cbea 進入 cbea 目錄，
輸入 yum localinstall --nogpgcheck *.rpm，
完成後輸入 cd ~，
再輸入 umount /mnt，
接下來 CellSDK-Extras-Fedora_3.1.0.0.0.iso 也是以同樣的方式安裝，
最後以安裝 x86_64 版的方式安裝 3.1-SDKMA-Linux-ppc-FP01.tar.bz2，
自此，CellSDK 已經完成安裝，
由於 YDL6.2 的 tcl 和 tk 套件較舊，
所以沒安裝 Cell 模擬器，
且 PS3 的記憶體較小，
Cell IDE 整合開發環境也盡量使用 x86 版做 cross-compile。

接下來將不需要的系統服務關閉，
請輸入 chkconfig --list 列出所有的服務，
若要關閉 irqbalance 的服務的話，
請輸入 chkconfig --level 01246 irqbalance off，
以上會將 irqbalance 的服務關閉等級 0、1、2、4、6，
所以以上會將 irqbalance 的這五個等級關閉，
而 chkconfig --level 35 irqbalance on 則是開啟 3、5 等級，
最後請確保 elfspe、irqbalance、messagebus、network、sshd、syslog，
以上此六個服務一定開著 3、5 等級，
其餘服務則全部關閉。

上篇到此為止已省下不少記憶體，
而下篇將會替大家做解析度和虛擬終端機等調整來節省記憶體，
當然，於 GUI 使用 YDL6.2 的使用者，
我也會建議轉向文字介面，
所以這些也將會於下篇的教學當中完成。

Yellow Dog Linux For CUDA

PS3 的 YDL6.2 瘦身文章將延後至下一篇，
而這篇是稍微提一提 CUDA 版的 YDL。

什麼是 CUDA？
CUDA 是顯示卡廠商 NVIDIA 所推行的 GPGPU 運算，
預期將有平行運算部分的應用程式往顯示卡，
也就是 GPU 上移植，
其市場有 HPC、PC上的平行運算的應用程式等，
至於詳細內容應該不用 Shady 介紹了吧？
有興趣了解的人可到此處逛逛。

然而 YDL 的發行商 Fixstars，
因 SONY 將 PS3 的 Linux 安裝界面 OtherOS 於3.21 版韌體之後就消除了，
又 CUDA 的市場大多與 Fixstars 重疊，
所以 Fixstars 早在 PS3 的 OtherOS 消除前一年左右就注意到 CUDA，
因此 YDL for CUDA 的出現並不意外。

而 Fixstars 已經於 7 月中、下旬左右釋出了 YDL for CUDA 的 iso、LiveDVD，
至於安裝流程教學，
由於 Shady 還未安裝，
所以想了解詳細安裝流程的人可參考此處。

在 PS3 上安裝 Yellow Dog Linux 6.2 ( YDL6.2 )。

請先準備好 USB 滑鼠、鍵盤，
還有 PS3 必須用 HDMI、色差端子連接顯示器或電視才能使用圖形模式，
顯示器須有 720P 解析度以上較佳，
再來是 PS3 的備份，這邊請參照 PS3 的官方說明，
最後是 YDL6.2 的 ISO 檔，將 ISO 燒成 DVD。

再來是 PS3 的設定，
首先請確定 PS3 的韌體為 3.15 之前、2.8 之後，
然後是將 PS3 的硬碟格式化，請參照此網址。

第三，將燒錄好的 YDL6.2 的 DVD 放進 PS3，
注意 DVD 會直到 YDL6.2 安裝完畢後自動退出 PS3，
因為 YDL6.2 的 DVD 中已備好 kboot，
所以請按照此網址安裝 kboot 和啟動 kboot。

第四，
啟動 kboot 後，按 Tab 鍵選擇以下選項的其中之一，括號內為說明：
install_ps3_1080i     (解析度為 1080i 的圖示安裝)
install_ps3_1080p     (解析度為 1080p 的圖示安裝)
install_ps3_720p      (解析度為 720p 的圖示安裝)
install_ps3_480i      (解析度為 480i 的文字安裝)
install_ppc32         (無用選項)
install_ppc32_text    (無用選項)
install_ppc64         (無用選項)
install_ppc64_text    (無用選項)

最後參考此網頁安裝 YDL6.2。

如果想要將 PS3 的 Linux 環境做為開發用，
將會於下篇文章描述如何替 YDL6.2 瘦身。

注意 CellSDK 的 License！

CellSDK 的 License 有必須注意的地方，
因為它有些限制。

可能有人會以為 CellSDK 大多為 GPL 或 LGPL 等開放式 License，
但其實不然，當中只有 GCC Toolchain 等少數工具為 GPL、LGPL，
凡舉 IBM 提供的 Librarys、Tools 都是基於 ILAR License，
就 Shady 從一本原文書(注)得知，
其使用期間只有 90 天，於此之後 Tools 將不得使用，
而且若您的產品使用了這些IBM的Librarys、Tools，
亦不得做 modifying、distributing、transferring 等動作，
但有項好消息，
就是你可以販賣給有安裝 IBM 提供的 ILAR 的 Librarys、Tools 的使用者。


注："PROGRAMMING THE CELL PROCESSOR For Games, Graphics, and Computation"，
    Matthew Scarpino著。

如何在 OS 為 Linux 環境的 x86 電腦上安裝 CellSDK。

這次 Shady 要分享在 Fedora 9 x86_64 的電腦 ( PC ) 上安裝 Cell 的開發工具 ( CellSDK ) 之過程，廢話不多說，我們馬上開始吧！

首先請準備好已安裝 Fedora 9 x86_64 的 PC 或已安裝 Fedora 9 x86_64 的虛擬機器，而 Shady 是選擇後者，而且是使用 Oracle VM VirtualBox ( 前生為 Sun VirtualBox )。

第二，請先於 IBM 申請免費帳戶後下載以下檔案：
請至下面網址 http://www.ibm.com/developerworks/power/cell/downloads.html 下載下面三個檔案：
cell-install-3.1.0-0.0.noarch.rpm
CellSDK-Devel-Fedora_3.1.0.0.0.iso
CellSDK-Extras-Fedora_3.1.0.0.0.iso
後於 http://www.alphaworks.ibm.com/tech/cellsystemsim/download 下載下面的檔案：
systemsim-cell-3.1-25.f9.x86_64.rpm
再於右面網址 http://www-933.ibm.com/support/fixcentral/ 下載下面的修正檔：
3.1-SDKMA-Linux-i386-FP01.tar.bz2 ( 請選擇與 Cell 和 i386 有關之選項 )
最後至此 http://www.bsc.es/projects/deepcomputing/linuxoncell/ 下載最後的檔案：
IBM-SDKMA-3.1.0.1-x86.tar.bz2

第三，將之前下載的檔案放在 /tmp/cellsdkiso 路徑下，而 3.1-SDKMA-Linux-i386-FP01.tar.bz2 和 IBM-SDKMA-3.1.0.1-x86.tar.bz2 則放在 /tmp/cellsdkiso/update 路徑下，之後開啟終端機按照以下指令進行：

yum update

yum list xulrunner

如顯示 i386 版和 x86_64 版都安裝，請執行 yum remove xulrunner.i386，如只安裝 i386 版，則執行下一步指令後再往回執行 yum remove xulrunner.i386。

yum install rsync sed tcl wget expat tk blt cairo libXtst xulrunner.x86_64

cd /tmp/cellsdkiso

rpm -ivh cell-install-3.1.0.0.0.noarch.rpm

cd ~

/opt/cell/cellsdk -o --iso /tmp/cellsdkiso install

安裝過程中如遇提問同不同意和接不接受，都請選同意和接受。

cd /tmp/cellsdkiso

rpm -ivh systemsim-cell-3.1-25.f9.x86_64.rpm

cd update

tar xf  IBM-SDKMA-3.1.0.1-x86.tar.bz2

tar xf 3.1-SDKMA-Linux-i386-FP01.tar.bz2

yum localupdate *.rpm ( 如失敗請用 yum --nogpgcheck localupdate *.rpm )

最後，
到 /opt/cell/ide/eclipse/plugins/com.ibm.celldt.simulator.profile.default_3.1.0.200811171424/ 下，用文字編譯器開啟 simulator_init.tcl 此檔案，然後將 704 列按照以下做更改：

原為此三列：
mysim trigger set console "The system is going down for system halt NOW!" CellDT_ShutdownNotified

mysim trigger set console "INIT: Switching to runlevel: 0" CellDT_ShutdownStarted

mysim trigger set console "INIT: no more processes left in this runlevel" CellDT_ShutdownComplete

改為此六列：
#mysim trigger set console "The system is going down for system halt NOW!" CellDT_ShutdownNotified

#mysim trigger set console "INIT: Switching to runlevel: 0" CellDT_ShutdownStarted

#mysim trigger set console "INIT: no more processes left in this runlevel" CellDT_ShutdownComplete

mysim trigger set console "init: rcS main" CellDT_ShutdownNotified

mysim trigger set console "Sending all processes the TERM signal" CellDT_ShutdownStarted

mysim trigger set console "md: stopping all md devices." CellDT_ShutdownComplete

還有 745 列原為此三列：
mysim trigger set console "Starting Linux" CellDT_BootedBios

mysim trigger set console "Welcome to Fedora Core" CellDT_BootedLinux

mysim trigger set console "INIT: Entering runlevel: 2" CellDT_BootNearlyReady

改為此五列：
mysim trigger set console "Starting Linux" CellDT_BootedBios

#mysim trigger set console "Welcome to Fedora Core" CellDT_BootedLinux

#mysim trigger set console "INIT: Entering runlevel: 2" CellDT_BootNearlyReady

mysim trigger set console "Welcome to Fedora" CellDT_BootedLinux

mysim trigger set console "Starting login process" CellDT_BootNearlyReady

到這裡 CellSDK 已安裝完成，以下則提供 Cell 開發環境 eclipse 啟動指令和模擬器啟動指令。

Cell 開發環境 eclipse：
 /opt/cell/ide/eclipse/eclipse -vm /opt/ibm/java2-i386-50/jre/bin

模擬器有兩列，請按順序輸入：
ulimit -s unlimited
PATH=/opt/ibm/systemsim-cell/bin:$PATH systemsim -g

最後提供 Cell 開發環境 eclipse 的更新設置：
開啟 eclipse 後於 eclipse 的視窗上方按照 Help→ Software Update→ Find and Install→ search for new features to install →next→ New local site→ /opt/cell/ide/eclipse 就可以了。

如何保養能安裝 Linux 的 PS3 呢？

由於 PS3 於 3.21 版後的韌體更新將再無支援 OtherOS 安裝的功能，
且維修後的 PS3 亦會以最新的韌體為韌體，
所以能安裝 Linux 的 PS3 的保養就顯得格外重要！

因此在此告知各位保養的方法，
保養的方法很簡單，
那就是啟動 PS3 時是在 GameOS 以外的 OS 啟動，
也就是說有使用 Linux 的使用者於今後盡量在 Linux 下開關機，
而不要在 GameOS 下開關機以避免 RSX 的發熱造成散熱系統耗損。

壞消息!

今天，
美國 PlayStationBlog 公佈了一壞消息，
PS3 的新韌體 3.21 版 (於 2010/04/01 號開放更新)，
將會取消 OtherOS (Linux) 的安裝功能支援，
請有在使用 Linux 的用戶注意！
Linux 用戶可選擇不更新，
但將會無PSN等使用權。

測試文章

1　2　3　テスト　テスト