2010年3月14日 星期日

OpenGL 4.0 specification released.


上週引起廣大討論的新聞莫過於 OpenGL 4.0 規格的釋出
眼尖的人可以發現 GLSL 的版本編號與 OpenGL 一致了
(不再像以往有著不同的編號: ex: GLSL 1.4 - OpenGL 3.1, GLSL 1.5 - OpenGL 3.2)
同一時間 OpenGL 3.3 規格也釋出了
OpenGL 3.3主要目的在於盡可能導入4.0的功能, 提供OpenGL 3.x世代硬體所能利用的 4.0 特性
詳細關於 4.0 的介紹可以參考這篇

特別的新功能在於
1. 兩個新的 shader 來處理 geometry tesselation
2. 能夠使用 OpenGL/OpenCL 計算出的資料來繪圖 ( 如此將可大幅降低CPU運算, 也降低CPU 對於CG, Gaming 的重要性, 可以預期的是與其花大錢買高速CPU, 其效應可能不如省下來買張中階顯卡還有找 )
3. shader 支援 倍精準(double) 浮點數運算, 以增進繪圖的正確性與品質.

Linux kernel 2.6.33

Linux kernel 2.6.33 在 Feb 24th, 2010 釋出了
主要的更動可以參考 kernelnewbies 與 H-Online 的What's new in linux 2.6.33這篇

這個版本受到注目在於
1. 整合Nouveau - open source nvidia 3D driver (Nvidia 並無提供協助, 主要是以逆向工程實作)
2. 整合DRBD - Distributed Replicated Block Device, 能視為基於網路的 RAID-1 實作
3. 整合Compcahe - 提供 Ram-Based Compressed Swap Device, 主要是切割出一塊記憶體空間, 將需要swap-out page資料, 壓縮後存放. 如此達到在記憶體中放置更多page 的目的, 減少 Harddisk IO(現今 CPU 壓縮/解壓縮 速度勝過對 HardDisk 讀寫), 提高效能.
4. Android removed from the linux kernel - 相關細節請參考 Android and the Linux kernel community (關於文章作者Kroah), 在今年二月初時此事在各大資訊相關網站廣受討論.

2010年3月8日 星期一

from linux thread to protothread

去年在使用 buildroot/uClibc 環境移植 linux 過程中
由於編譯時對於 thread 選項選取預設的 linuxthreads 而非較為完整的 NTPL
因 thread 行為模式的緣故, 造成 IP 廠商提供的 OpenGL ES 環境無法正常運作
當時觀察到主要的錯誤在於每個 thread 取得的 pid 是不相同的
明顯地, 這不符合 thread 一般的認知, 然而這也與 linux thread 實作演進有相當的關係
(而linuxthreads 演進到 NTPL 的過程, 請參考 wikipedia 上的關於linux thread的歷史, 這裡就不詳加說明.)

在碰到這樣結果的當下, 稍微感到有些訝異
現今 thread 的概念在 OS 教科書中是一大重點
而 thread programming tutorial/guide 更是垂手可得
利用 thread 來改善系統效能, 更是常見於日常的程式中
這些資訊多到讓人產生一種 thread 的存在是理所當然似地
看著 wikipedia 中對於 thread 的說明, 跟教科書其實相去不遠

撇開 user-level/kernel-level 的優缺 和 1:1, N:1, N:M 的 Model 不同的理論不談
kernel-level threads 間的 context switch 可能可以較容易理解, 或是寄情於OS的能力
其中最引人入勝的莫過於 user-level threads 間又是如何達成的?

對於 user-level thread 的考量點有二
1. 如何於 user space 維護 thread context
2. thread switch 的時機點
preemptive or non-preemptive

其中 1.又取決於針對 2.的考量決定複雜的程度
可以想見, 可能必須在 process 中建構屬於 thread 的context
從 PC register, stack, 甚至可能細到 signal, 取決於實作的規劃

複雜者可能如 FSU Thread 在user-level 中實作了 POSIX thread

另外常見的 user-level thread 方式是提供特定的 I/O 與 switch API
讓 programmer 決定可以選擇切換的時機
這類者像GNU Portable Thread 即為一例
對於 GNU Pth 的細節技術可以參考這篇論文
主要在於使用泛 unix 的 ucontext/setjmp 支援

然而確也可能簡單到像 Contiki 中使用的 protothread
(與 coroutine 不同的地方在於 protothread 是 stack-less)
其概念可以拜讀 Simon Tatham 關於 coroutine 的大作
jserv 於 2006 年也對 coroutine 做了簡單的介紹
其精神在於僅存放 thread 所在的狀態, 以利於切換時跳至正確的位置

由於不停地在 thread 中切換, 若 thread 的 execution time 過小
搭配 sleep 的時機不佳, 簡單者是浪費 cpu 的 busywaiting
然而延伸而言, 卻也會影響 scheduling 與 cpu freqency 切換的判斷
而需要 computation 時, thread 間執行時間的比例, 與 sleep 可能造成降低效能
而這些都與使用 user-level thread API 實作 thread routine 的方式有很大的關係

儘管 thread 帶給 programmer 許多便利性
然而需要注意 thread 在各種環境下的特性, 才能夠正確地使用

Lookup Table 在 NEON 中的處理

在 SIMD Programming 中由於希望能夠每個 lane 有一致的行為, 因此有一些事情是不容易達到的 而 Lookup Table (LUT) 即是其中之一 但若是特定條件之下, 還是有可能透過 NEON 加速 而這個 直接前提是 8bit LUT (當然...