忙碌的日子總是過得比較快，這一年來，0xlab 歷經頗多轉變，主要有以下三方面：

• 技術涵蓋： 為了加速 Android 系統整合與優化，我們建構了若干工具與提供一些創新的方法，比方說快速啟動 Android，詳情可見 0xlab::Technology
• 與知名專案與開源團隊的合作：除了過去已合作的 android-x86 與 CyanogenMod 專案外 (主要是 Graphics 與 ARM 相關效能優化)，我們也投入 Linaro 的開發，建立 Android platform 與 LAVA (Linaro Automated Validation Architecture) 的基礎
• 建立與主要 SoC 廠商的聯繫及協同開發：與兩家重要的 SoC 廠商 (排名 Top 20 半導體公司) 密切合作開發，在 Android 的基礎上，透過若干開源的創新，加強 SoC 競爭力，並導入產品設計

即使比過往忙碌，不過我們仍持續貢獻於開放原始碼的世界，以下是從去年發表「簡介 0xlab 新的開放原始碼專案」之後的更新：

• 0xdroid :作為 0xlab 的 Android 參考優化與客製化設計，其成果不僅為 Beagleboard 社群所熟知，許多內部的改進也廣泛用於 CyanogenMod，間接使許多裝置與公司團體受惠。可參考 0xdroid::Roadmap 以得知細部的演進，簡單來說，在高解析度的環境，提昇了 Android 使用者體驗 (software curosr, on-screen keyboard, launcher)，另外就是進一步的 ARM 優化，從 skia, zlib, libcore, libc, 到 libagl (libGLES_android) 都有
• 0xbench : 仍是截至目前為止，我們所知的最完整 Android 開放原始碼系統效能評測工具，與上個版本相較，追加了 Web/JavaScript 效能評測、LAVA 的資料格式 (bundle)、重新啟用 libMicro 等等，詳情可見 0xbench::Benchmarks
• Linaro : 經 ARM 的支持，0xlab 投入 Linaro 開發，共同為改善開發原始碼軟體品質而努力。我們涉及的項目稍微繁雜些，從整合 Linaro toolchain、改善 Android runtime、強化 LAVA 的整合，到多媒體驗證都有
  
• aster : 全名是 "Android System Testing Environment and Runtime"，著眼於 Android 系統中許多無法透過 API 呼叫所作的 black-box test，一旦 adb daemon 正常啟動後，這個系統就可依據指定的 test case 去逐一執行並驗證，此系統也允許使用者編輯操作案例
• Android 快速開機: 利用優化過的 ARM hibernation (suspend-to-disk)，大幅縮減 Android 系統從 HW reset 到使用者得以操作的時間，可參考展示影片 "Android Fast Booting with CarHome"，相關的原始碼也一併釋出，可見 0xlab-kernel，儘管仍有頗大的進步空間，但這是完全可運作且開源的解決方案
  
• AMBER : 這是我們提供的第一個完整的應用系統，概念非常簡單，考量到現有 Android 裝置相當多元，可能是手機、筆記型電腦、平板電腦、電子書，或者數位電子，這之間要進行媒體 (media/content) 的交換往往很沒效率，而且使用者還得被繁複且多樣的多媒體格式所困擾，若無適度的轉換，通常就無法在手機或者較陽春的平板上播放。我們提出的解法，就是將動作縮減為 "push" 與 "pull"，自動偵測媒體的格式與屬性，無論在近距 (家用或小範圍) 或遠距 (透過雲端或者防火牆)，挑選最合適的途徑，讓使用者盡情觀賞與交換。同樣的，這也是開放原始碼，內建於 0xdroid
• Toolchain : 除了改善 Linaro Toolchain for Android 外，我們還改善了 Android ELF prelink，大幅縮減執行時期需要解析的 ELF 符號數量，也縮減了載入時間，近期內會提交到 AOSP
• Android Open Source Project : 已被 Google Android 計畫正式收錄 37 個修改/貢獻
  

其他項目就要看合作夥伴的狀況了，先提到這邊。歡迎透過以下方式，與我們聯繫與交流：

• Twitter: http://twitter.com/0xlab
• 郵件論壇: 0xlab-devel (系統開發) ; 0xlab-discuss (一般討論)
• YouTube: http://www.youtube.com/0xlab
• 有源碼有真相: gitorious, github
  

一如過往，我們今年也會在台灣最大的開放原始碼研討會 COSCUP 發布最新的專案與社群計畫，期待您的指教，謝謝！

read on

在台灣，一年一度的開放原始碼盛會 OSDC.tw 即將於今年三月 26 與 27 兩日舉辦，而 0xlab 除了很榮幸能成為 OSDC.tw 贊助單位之外，也有五位開發者獲邀分享若干技術議程，以下摘錄的演講摘要：

講題： The meaning of open
講者： John Lee
摘要： Open source can be a culture, a belief, a hobby, a profession, and many things else. Now it can also be a business model. 0xlab has been trying to build a bridge between companies and open source communities for almost two years. We believe that by creating an ecosystem around open source technologies, we can help it growing stronger in Taiwan. This session is about our idea, our vision, and our progress.

講題： Build Programming Language Runtime by LLVM
講者： Jim Huang (jserv)
摘要： 在 OSDC 2009 的〈窮得只剩下 Compiler -- 淺談編譯技術的革命〉議程，提及編譯器相關的技術獲得空前的成功，而在運算型態多元的今日，如何跨越語言的藩籬卻又得兼顧底層平台的效能與安全，即是當前的重要課題。本議程將探討如何打造架構於 LLVM Compiler Infrastructure 的程式語言執行環境，並分析傳統編譯/解譯式語言到當紅的動態程式語言在引入於移動平台時，值得深入探索的技術細節。

講題： Rloader, alternative technology to achieve fast boot time for ARM Linux
講者： Matt Hsu
摘要： To reduce boot time for embedded device, you can optimize from different aspects, such as bootloader, kernel, and applications. But this usually needs to do optimization on specific application. Instead, Rloader can provide _generic_ solution to achieve fast boot time without changing your application.

講題： SVG+Javascript meets Embedded Systems
講者： Thinker Li
摘要： After two years of work, MadButterfly, a SVG based GUI environment, had made a breakthrough. It suports Javascript to improve efficiency for developing embedded systems. In late 2010, we also improve our code with OpenVG, an HW acceleration API, to provide high-performance GUI. This talk would demonstrate an efficient way for developing an embedded system with GUI, and provide high quality and performance GUI output with a low-Hz platform at the same time.

講題： Gallium3D - Mesa's new driver model
講者： Chia-I Wu (olv)
摘要： 做為 Linux 系統主要的開放源始碼 3D 驅動程式，在 GPU 應用範圍越來越廣泛的同時，傳統的 Mesa driver model 已逐漸不敷使用。本議程將簡介 Mesa 新提出的 Gallium3D 架構，理解何以 Gallium3D 能夠幫助開發者更快地去支援新的硬體、作業系統與繪圖 API 。

依據慣例，屆時我們也會發布最近的開發成果，期待您的蒞臨指教，謝謝！

read on

有鑑於 Google 的 Android toolchain 開發團隊雖然活躍提交修改/貢獻到 GCC 與 binutils，但受限於 Android 原始碼釋出的慣例，總是要等待頗長的時間，才有機會使用到新的 GNU Toolchain 改善或者新功能，所以，0xlab 開發者就準備一份客製化的版本，請參考以下網址：

• http://downloads.0xlab.org/toolchain/armv5te/

目前提供 gcc-4.4.3 與 gcc-4.4.4 兩個版本，前者是取自 Google Android 的原始碼分支，提供 ICF (Identical Comdat/Code Folding) 與 LIPO (Lightweight IPO) 等優化機制，而 gcc-4.4.4 的版本則是 0xlab 升級到新的程式基礎，並加入必要的修正。原始程式碼與 Toolchain 建構系統可參考 GIT: android-toolchain。不久的將來，我們將會全面移轉到 Linaro toolchain，也會一併發布 gcc-4.4 與 gcc-4.5 的 Android toolchain。

read on

我們在今年八月中旬的 COSCUP 研討會中，很榮幸地向與會的朋友介紹 0xlab 若干新的開放原始碼專案，本文稍作整理回顧。0xdroid 是 0xlab 最早的一項整合性開放原始碼專案，目的是建構於 Beagleboard 開放的硬體之上，提供 Android 的參考實做環境，經過一年多的累積，裡頭的成果被帶到不同的移動裝置中，比方說手機與 Tablet。今年二月份，有幸在 Mobile World Congress 2010 展示基於 Android 的移動裝置，Tieto 也在 TI OMAP3 平台展示 0xdroid，這些都讓我們更有信心，擴展到多元的應用。

這半年間，延續 0xdroid 的經驗，我們發展 / 貢獻以下專案：

• 0xRobocat : 與 CATCAN 合作的專案，目的是打造一組控制伺服馬達與相關零組件的軟體框架，可提供給 Android 或 GNU/Linux 使用，以 Apache License 2.0 授權釋出。除了用於打造機器人外 (是真的可走動的 "Android")，本專案可用於 Android 裝置 (如手機) 的自動測試
  
• 0xBench : 有鑑於 Android 上的系統效能評比程式，不是不完整，就是非開放原始碼，所以我們決定重新打造一個。0xBench 可從 C 函式庫/系統呼叫的層面，一路從 Dalvik VM 評測到 Android framework，仍持續擴充，並且我們提供 Web service，允許貢獻評測的結果，用互動的方式來分析。程式主體是 Apache License 2.0 授權
• android-toolchain : 0xlab 特製的 GNU Toolchain，以 Android team 的成果為基礎，整合來自 Linaro Toolchain Working Group 的改善。這些主要是 GNU GPLv3 授權
  
• Android Open Source Project (AOSP) : 提交 0xlab 過去在 TI OMAP 與 Qualcomm 72xx 平台的一些修改，經過公開的 Review 機制，慢慢整合到 AOSP
• CyanogenMod : 社群版本的 Android，在 Nexus One, HTC Dream 等裝置有相當優越的表現，收錄若干來自 0xlab 的改良，比方說 Bluetooth HID profile
  

除了以上的開放原始碼專案，我們內部正進行一個基於 Android 的新型態應用，未來也會將相關的專案程式碼，以開放原始碼的形式釋出，完整的列表可參考 0xlab Projects。至於 AOSP，我們現有更改的項目是：

• build - 調整 Android build system、修正工具程式的瑕疵
• bionic - 提供 ARM optimizations，針對 ARMv6/ARMv7
• PixelFlinger - 基本的 refactoring，以及 ARM 實做的改良
• libpng / libz - 利用 GCC visibility，進一步縮減 code size
• elfcopy - ELF 工具的調整
• bionic / apriori / build - 支援 DT_GNU_HASH，加快動態連結的速度
• toolchain - 加強 build system 的彈性

以上，歡迎舊雨新知給我們支持與指教，謝謝。

read on

Android 2.0 (Eclair) 原始程式碼已於一個月前釋出，在目錄 system/core 下有個 libacc 的子項目，這是開發者修改自 Fabrice Bellard 的大作 OTCC (Obfuscated Tiny C Compiler)，以 C++ 與 Android 的執行時期函式庫重寫。libacc 的功能是提供給 Android 2.0 的 RenderScript 一個 C-like 語法的描述，如此一來，開發者可撰寫高效能的視覺效果與動畫，不過這部份並未完成，詳情可參考 "Android renderscript, more info' and an example application" 一文。

關於 libacc 的整合部份，可參考 frameworks/base/libs/rs 目錄下的兩個檔案：

• rsScriptC.cpp
• rsScriptC_Lib.cpp
  

筆者準備了一份可單獨執行於 GNU/Linux 環境的套件："libacc.tar.bz2"，除去 Android 的相依性並補上 Makefile，測試方式如下：

libacc$ make
g++ -I./include -DHAVE_PTHREADS -c acc.cpp
gcc -I./include -DHAVE_PTHREADS -c hashmap.c
gcc -I./include -DHAVE_PTHREADS -c logd_write.c
g++ -I./include -DHAVE_PTHREADS -c tests/main.cpp
g++ -I./include -DHAVE_PTHREADS -c tests/runtimeTest.cpp
g++ -o main \
  acc.o \
  hashmap.o \
  logd_write.o \
  main.o \
  -ldl
g++ -o runtimeTest \
  acc.o \
  hashmap.o \
  logd_write.o \
  runtimeTest.o \
  -ldl

libacc 的 Code generator 支援以下硬體架構：

• x86 / IA32
• x86_64
• ARMv5

以 IA32 的環境為例，可透過測試程式來驗證 libacc： (參數 -R 表示作執行的動作)

libacc$ ./main -R tests/data/hello.c
Executing compiled code:
Hello, world
result: 0

其中 tests/data/hello.c 的內容為：

libacc$ cat tests/data/hello.c
int main() {
printf("Hello, world\n");
return 0;
}

若平台是 ARM 的話，還可以支援反組譯輸出，libacc 是 RenderScript 背後很重要的基礎建設，允許動態編譯 Android Graphics 的 RenderScript，輸出成機械碼並執行。參考檔案 tests/runtimeTest.cpp 可得知 RenderScript 的寫法，整個 libacc 可內嵌於程式中，比方說：

const char* text = "void op_int(int a);\n"
   "void op_float12(float a, float b, float c, float d,\n"                   
   "           float e, float f, float g, float h,\n"
   "           float i, float j, float k, float l);\n"
   "void script() {\n"
   "  globalVar += 3;\n"
   "  op_int(123);\n"
   "  op_float12(1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0, 10.0, 11.0, 12.0);\n"
   "}\n";

這個字串經過 libacc 的函式呼叫後，可得到以下的編譯與執行結果：

libacc$ ./runtimeTest
Executing script:
op_int(123)
op_float12(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12)
After script globalVar = 20

目錄 tests 還包含可在 Android 環境執行的自動測試 Python script。

read on

最近 0xlab 的開發者持續改善 0xdroid，在 gitorious 的團隊排名維持在前五名的活躍程度，除了稍早提及針對 ARMv7 與底層軟體架構的改進外，0xdroid 也加入了對 Beagleboard / TI OMAP3 硬體更充分的支援。現在與多媒體處理相關的架構圖可參考以下：

紅色的部份是 Android 的 framework 層面 (Media framework, Media server)，而藍色則是實做 framework 所需服務的元件 (如 OpenCore)，剩下綠色的地方自然是 0xlab 關注、與硬體平台相關的元件，這裡簡要列出：

• libaudio : 透過 ALSA 處理 Audio In/Out，針對 TI OMAP3 平台做了調整
  
• libcamera : 以 V4L2 (Video For Linux) API 為基礎，提供上層 Android framework 對 camera 所需的硬體支援。透過 TI OMAP3 平台的 video overlays 作 preview 影像處理，並善用 TI DSP 的能力作 JPEG 處理
  
• libopencorehw : 銜接 OpenCore，允許透過 TI OMAP3 平台的 video overlay 作高效能顯示處理
  
• liboverlay : 讓 libcamera 與 libopencorehw 共用的 video overlay 操作模組
  
• TI DSP / OMX : 透過 OpenMAX 標準介面，使用 TI DSP 實做的硬體多媒體 codec 運算
  
• FFmpeg / OMX : 透過 OpenMAX 標準介面，使用針對 ARMv7/NEON 優化的硬體多媒體 codec 運算，這部份採納 FFmpeg 的基礎
  

目前上述的硬體特有的元件已有初步實做，待驗證與調整 HAL 後，就會陸續整合到 0xdroid 的公開 repository，至於開發相關的議題，可到 0xlab 的郵件討論群組 0xlab-devel 交流，謝謝。

read on

前文「對 String 操作的改進」與「Android Dalvik VM vs. Java VM」談及基於 CVM 引擎的 Java VM 與 Dalvik 的效能差異後，最近 0xlab 內部也因為挑選硬體平台，持續分析 Embedded CaffeineMark 一類量化效能的報告。參考的硬體組態是 OMAP3/ARMv7 500 MHz，粗略的效能評比如下圖：

Dalvik 取自 0xdroid (cupcake + backported from donut)，而 CVM-jit 則源自 phoneME CVM svn r19264，整體分數為：

• Dalvik VM : 1034
• CVM + jit : 7526

CVM 的組態設定：

• cached constant
• cached constant inlining
• array init bounds check elimination
• Hardware fpu = NEON
• AAPCS

當然 Just-In-Time compiler 不是萬靈丹，從上述效能評比可發現，CVM 在若干地方做了重要的微調，比方說透過 CNI 實做若干 class library 的關鍵 method，以及善用硬體 floating-point 操作 (注意：本組態未引入 ARMv6 與 ARMv7 的 Thumb2/Thumb-EE 指令集)。儘管 Android 團隊中 Dalvik 開發者 fadden 在郵件討論群組談及：

Four String methods -- charAt, compareTo, equals, and length -- are
"inlined" by the VM, and are not going to get much faster.

There are probably a few others that could benefit from this
treatment, but I'm guessing that most string-centric processing in
Java will likely be dominated by the cost of String allocations. (The
above weren't inlined because of a measured performance need -- the
inlining was an experiment that needed a test subject.)

Dalvik 理論上可施加這些優化技術 (string allocation / native method inlining)，不過目前開放的實做中，尚未引入 (至少在 donut branch 中)。即便在保持 pure interpreter 的架構下，現有 class library 與 GC (garbage collector) 仍可作些調整，以改善 Android 的應用程式執行效能與 (圖形應用導向的) 使用者互動反應表現。

read on

本日仍在追蹤 0xdroid 的穩定性與效能議題，進行壓力測試時，順便將知名的 SDL 函式庫移植到 Android window system，更具體來說，就是允許在 Android Surface Manager (SurfaceFlinger) 上運作 SDL 應用程式，背景知識請參考 0xlab 圖形處理達人 olv 的簡報 "Introduction to Android Window System" (PDF)。依據 olv 提供的範例 SurfaceFlinger 操作程式，libSDL 可很快地加上 Android video backend，接著透過 libui 的 EventHub 取得來自 Linux input subsystem 的事件。現在初步的移植成果可參考下圖：
上圖展示一個以 SDL 撰寫的 NES 任天堂模擬器，顯示更新於新建立的 Android Surface 上，筆者將該 Android surface 的起始座標位置挪到 (100, 100)，並設定其半透明度值，載入筆者最愛的泡泡龍 (Bubble Bobble) 遊戲 ROM。目前僅算堪用的狀態，未來要考慮到 Android Surface 限制 color space 為 RGB565 (針對 16-bit depth 顯示所做的優化限制)，勢必得在 libSDL 引入若干 color space 轉換的繁瑣運算，可透過 ARM NEON 一類的硬體加速機制去改善效能。

read on

之前的文章「Android Dalvik VM vs. Java VM」提及純 interpreter 的 Dalvik VM 與具備 Just-In-Time compiler 的 JBend JVM (基於 CVM 引擎) 的效能比較，以修改過的 Embedded CaffeineMark 作為量化的依據，可發現 String 測試項目差了一個數量級 (491 vs. 5109)，整體的分數是 1:4.18 (1811:433)。稍早 ansoncat 做了初步分析：

「這部分應該是由於在 CVM 中，使用了 CNI 來實作 String class 的重要操作 ... 因為 String 的分數拉高了平均，其它 benchmark 的效能差異會比平均分數的差異大的多」

目前 0xdroid 在不更動 Dalvik VM 實做的前提 (後續再談改進的途徑)，對 bionic libc 的 string 相關函式作調整，移植來自 CodeSourcery/ARM 的 ARMv7 Thumb2 優化實做，就 micro-benchmark 的角度來說，效能改進約有 25% (初步分析，要考慮到不同的環境配置)，但整合到 Android/Dalvik 的表現又是如何呢？筆者的實驗結果如下： (score 大者為佳)

測試環境是 Beagleboard (500MHz) 運作 0xdroid，以 ARMv7 GNU Toolchain 編譯，"armv7" 是 bionic 更動前的數據，而 "armv7-opt" 則是更動後的表現。很顯然發現，String 一項的改進大幅受到壓抑 (score = 1898:2140)，致使兩者最終僅有些微的落差，可見 JNI 帶來 overhead 的著實不小。又，大部分應用程式的效能瓶頸往往在於圖形處理、系統資源的調度、檔案讀寫等 I/O 操作，所以現階段我們的想法是儘量調整 native 的部份，針對 ARM core 與 SoC 的特性作調整，並提出可行的輕量級 native method invocation 實做。

read on

這幾周，0xlab 的開發者都在準備新的 Android distribution，標的平台是 Beagleboard，可望在 COSCUP 到來前釋出，過程中順便寫了一個簡單易用的 Image Installer，可從 SD card 開機並將可運作的 Android system image 植入 Beagleboard 之上的 NAND flash，而不必依據繁瑣的流程，才能體驗我們的新創作。目前已有初步成果，可參見下圖：
已實做的特徵有：

• 僅需要放置單一檔案 (uImage.bin) 到 VFAT 格式的 SD card 中，在 Beagleboard 插入 SD 開機進入 Image Installer，即有簡單俐落的 UI
• 整個 Image Installer (kernel + busybox + file system + MTD tools + UI) 佔用不到 2Mb 的空間
• 預設讀取 SD card 裡頭的 android_beagle.ubi 與 0xkernel-beagle.bin 兩個檔案，自動寫入 NAND flash，並設定必要的 u-boot 環境參數。放置 image 檔案的動作可在多數的作業系統平台下進行，舉凡 MS-Windows, GNU/Linux, Mac OS X 等等，只要支援 VFAT 與 SD/MMC 讀寫即可

貌似單純的 Image Installer 開發，卻折騰了好幾天，歸納有若干因素：

• 準備在 Beagleboard/OMAP3 環境下可最小可啟動的 Linux image，需要考慮到 device driver 間的相依性，比方說若將 USB subsystem 完全移除的話，很可能無法正常開機。又，OMAP3 內建的 MFD (Multi-Function Device) 要注意到驅動順序的議題，不然功能無法正確運作
• 要留意 TI OMAP3 / Beagleboard 啟動順序，即使 boot from SD，但 u-boot 與其 u-boot bootenv 很可能仍讀取自 NAND flash，這導致後續啟動的 Linux kernel 採用了預設值，致使 Image Installer 無法在預期的環境參數下啟動
• ARM/Linux 啟動過程中，會試圖自一段特別的記憶體空間讀取 command line parameters，這空間稱為 ATAGS，係由 boot loader (以 Beagleboard 來說就是由 X-Loader 帶起的 u-boot) 填寫的記憶體內容，也就是所謂的 u-boot bootenv。但對 Image Installer 來說，雖然 u-boot 給予頗大的彈性，但也使得執行環境充滿不確定性

關於 ARM/Linux 的 ATAGS 實做程式碼可參考 arch/arm/boot/compressed/head.S 與 arch/arm/kernel/setup.c 兩個檔案，筆者做了簡單的 hack 以迴避：

--- android-omap.orig/arch/arm/kernel/setup.c 2009-08-08 18:40:30.000000000 +0800
+++ android-omap/arch/arm/kernel/setup.c 2009-08-08 18:43:09.000000000 +0800
@@ -613,7 +613,6 @@

static int __init parse_tag_cmdline(const struct tag *tag)
{
- strlcpy(default_command_line, tag->u.cmdline.cmdline, COMMAND_LINE_SIZE);
return 0;
}

由此可見，原本的動作是將 u-boot 對 ATAGS 寫入的資料寫入預設的 command line。至於安裝 Linux kernel image 與 root file system image 到 NAND flash 後，還得作 (NAND 裡頭的) u-boot bootenv 的編輯動作，這部份的工作原理可參考 Openmoko 開發的 Devirginator。喔，忘了說，這些惱人的限制，會在轉換到 Qi boot-loader 後迎刃而解 :)

read on

以圖表展現前文「在 Android/OMAP 展現硬體加速的 OpenGL|ES 與影片播放」與「針對 ARMv7 優化的 Android」所提到的效能改善，可參見以下：

分析若干繪圖操作：

• 302700 bytes memcpy
• 512x512 unmodified texture, 512x512 blit
• 512x512 unmodified texture, 512x512 blit (x2)
• 512x512 modified texture, 512x512 blit

baseline 是原本 Android on Beagle 的移植，而 hardware-opt 則是運用 ARM NEON 指令集與硬體 OpenGL|ES 加速，基準 baseline 302700 bytes memcpy 時間為 1373 us，整體時間越短越佳。

read on

BeagleBoard 是 0xlab 內部用來驗證 ARM 硬體的參考平台，這兩個月內，我們整合了若干無線通訊大廠的 WLAN/Bluetooth 晶片組，而 TI OMAP 353x SoC 的表現著實令人驚豔。初步對 ARMv7 做了優化後，我們進一步運用 OMAP DSP 與 Display Subsystem 的特性，下圖即是在 Android 上硬體加速的 OpenGL|ES 與影片播放，
透過 DVI-HDMI 到顯示器，呈現 1024x768 的解析度，圖上方可見 Android 的狀態資訊列，而最上層就是 video overlay，而下方是 OpenGL|ES 的繪圖區，被遮蔽的最底層則為 Android surface。TI OMAP 3 整體示意圖可參考下圖：
硬體支援三個 stacked overlays，其中 Video 2 和 Video 1 overlay 提供 RGB 及 YCbCr/YUV 的 color space，搭配 TI DSP 與 ARM NEON 加速指令集，可帶來相當順暢且華麗的展現。以下是稍早所作的 OpenGL|ES 與 HW video overlay 人機介面展示影片：

• beagle-gfx.avi

OpenGL|ES 由 PowerVR/Imagination Technologies 提供，搭配 OMAP2/3 嶄新的 DSS2 顯示架構，需要對 Linux kernel driver 作些調整，可參考筆者提供的套件與修改部份。當然這一切僅是基礎建設，銜接於 Android 及 ARM SoC 所需要的功夫仍相當多，期望不久的將來，我們的圖形處理達人會提出更多新玩意 :)

read on

前文「升級 Android 內建 GNU Toolchain 到 gcc 4.4」提及使用更新的編譯器平台，現在追蹤的是 gcc 4.4/4.5，不排除引入 LLVM，這些準備都是為了允許施加更多優化、展現平台的特性，而在 Android 的 build system 也需要作一些更動，至少涵蓋以下：

• 針對硬體平台的編譯參數
• Dalvik machine-dependent interpreter implementation (mterp)
• 針對硬體特徵優化的關鍵軟體，如 BlueZ 中處理音訊 Bluetooth low-complexity, subband codec (SBC) 的實做

當然優化是無止盡的，我們只求在合理的工程資源，能解決夠多的技術議題即可。筆者的參考修改可見 android-armv7.patch，其中做了以下調整：

• 設定 gcc 編譯參數為 "-march=armv7-a -mtune=cortex-a8 -mfpu=neon"，適用於 BeagleBoard (TI OMAP 353x) 平台
• 額外啟動 gcc 的 Auto-vectorization 優化策略
• 以 ARM NEON 指令集優化 SBC 的執行效能

前期我們還是著重於泛 ARMv7 平台的優化技術，再來就是針對 SoC 平台的 DSP 與特性去作進一步處理。為了證明以上的修改發揮作用，可檢視 libjpeg 是否自動的做了 vectorized，也就是看看有無 ARM NEON 指令集的生成：

# ./prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-objdump -d \
out/target/product/generic/obj/STATIC_LIBRARIES/libjpeg_intermediates/jdmerge.o | egrep "v[add|mov]"
1d4:   f2c09012        vmov.i32        d25, #2 ; 0x00000002
1d8:   f3c01210        vmov.i32        d17, #32768     ; 0x00008000
200:   f26048a9        vadd.i32        d20, d16, d25
204:   f22069b8        vmul.i32        d6, d16, d24
208:   f26438a9        vadd.i32        d19, d20, d25
20c:   f2266821        vadd.i32        d6, d6, d17

至於 ARM NEON 指令集，這裡不贅述，可參考 ARM 官方文獻 NEON Technology。

read on

在 Android 內部實做中，有許多細節涉及大量的 memcpy() 操作，比方說將一塊使用者定義的繪圖區域傳遞給 SurfaceFlinger 管理的過程，由於得先轉換成 texture，再對應為 Surface，之間至少需要三次 memcpy。由於 BeagleBoard (TI OMAP3) 透過 HDMI 輸出 (max: 1280x1024)，居中涉及大量的繪圖操作，意味著 memcpy() 頻繁被呼叫著，對整體效能有顯著的影響，於是筆者花了一些時間分析。

Android 的 libc 實做 -- bionic -- 已包含針對 ARMv5 優化過的 memcpy()，詳情可參考 libc/arch-arm/bionic/memcpy.S，而 GNU Toolchain (glibc) 中，其實也有一份針對 ARMv5 優化過的 memcpy() 實做，也利用到 ARMv5 的 data prefetch 指令。既然我們採用 ARMv7 架構的 BeagleBoard，何不使用其引入的 NEON SIMD 加速指令集呢？以下就是在 BeagleBoard 所作的 benchmark：

數據如下：

• glibc-armv5 : 181884276 B/s
• bionic-armv5 : 225881095 B/s
• armv7 : 269294302 B/s

參考的 ARM NEON 優化 memcpy() 實做如下： (arm-neon-memcpy.S from Måns Rullgård )

1. .fpu neon
2. .text
3. 
   
4. .global memcpy_neon
5. 
   
6. .func memcpy_neon
7. memcpy_neon:
8. push {r4-r11}
9. mov r3, r0
10. 1: subs r2, r2, #128
11. pld [r1, #64]
12. pld [r1, #256]
13. pld [r1, #320]
14. ldm r1!, {r4-r11}
15. vld1.64 {d0-d3}, [r1,:128]!
16. vld1.64 {d4-d7}, [r1,:128]!
17. vld1.64 {d16-d19}, [r1,:128]!
18. stm r3!, {r4-r11}
19. vst1.64 {d0-d3}, [r3,:128]!
20. vst1.64 {d4-d7}, [r3,:128]!
21. vst1.64 {d16-d19}, [r3,:128]!
22. bgt 1b
23. pop {r4-r11}
24. bx lr
25. .endfunc

至於 SurfaceFlinger 的操作仍有優化的空間，稍後再討論。

read on