0xlab 在 COSCUP 2009 的議程分享

一年一度的「COSCUP / 開源人年會」即將於八月 15 與 16 兩日舉辦,今年的規模與議程深廣度再創新紀錄,依據公佈的議程大綱,今年大會有四個主題:
  • Android 和嵌入式系統
  • 雲端運算和 Web 技術
  • 開發者工具
  • 使用者桌面
0xlab 除了很榮幸能成為 COSCUP 贊助單位之外,也有四位開發者獲邀分享若干技術議程,以下摘錄 COSCUP 的演講摘要
講題:Android Wave Is Not Google Wave

講者:Chia-I Wu "olv" (0xlab)

摘要:

There is 3D acceleration on our laptops/netbooks. There is no reason that we cannot accelerate Android when it runs on the same devices. This talk is about 3D acceleration on Android. However, it will focus more on Mesa/DRI and focus less on Android, as the former is more open to our definitions.
講題: How Android Differs from GNU/Linux? And How can we FIX it?

講者: walkingice (0xlab)
摘要:
Android is indeed an open platform and large-scale open source project, which is amazing, but it excludes some well-known free and open source software such as glibc. This talk is about to share the experience about migrating from traditional GNU/Linux to Android. Also, 0xlab introduces some non-trivial modifications in order to leverage existing native Linux software into Android.
講題: Happy Build with OpenEmbedded
講者: tick (0xlab)

摘要:
Openembedded is a flexible and powerful autobuild system. It helps us porting different distributions to different hardwares without too much pain. I'd like to introduce the OpenEmbedded system via creating a tiny distribution and running it on a real embedded system. I will use beagleboard to demonstrate the image. If you have beagleboard, you can take that and play at the same time.
講題:Linux Virtualization Goes Mobile
講者:Jim Huang "jserv" (0xlab)

摘要:
Although the concept of virtualization has existed since the 1960s, the applications become mature and diverse recently. the term "hypervisor" is referred to the original goal: providing a virtualization layer that strictly isolates virtual machines from each other for security and reliability purposes, that meets the requirement of rich mobile devices nowadays. the talk covers running operating systems in isolated run-time environments on a single hardware platform, and what we can benefit from it: flexible system configurations, legal/contractual liability, secure designs, etc.
涵蓋 Android 3D、Android / Embedded Linux 開發,與 Linux virtualization 等等,屆時我們也會發布最近幾個月的成果,期待您的蒞臨指教,謝謝!

read on
Posted 張貼者: jserv 於 晚上8:07 on 2009年7月28日 星期二 | 2 意見
Filed under: ,
 

Android/Beagle 效能改善簡記

以圖表展現前文「在 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
Posted 張貼者: jserv 於 上午11:13 on 2009年7月13日 星期一 | 0 意見
Filed under: , , ,
 

在 Android/OMAP 展現硬體加速的 OpenGL|ES 與影片播放

BeagleBoard0xlab 內部用來驗證 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 人機介面展示影片:

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

read on
Posted 張貼者: jserv 於 下午3:05 on 2009年7月8日 星期三 | 0 意見
Filed under: , ,
 

針對 ARMv7 改進的 Android

前文「升級 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
Posted 張貼者: jserv 於 上午10:41 on 2009年7月1日 星期三 | 1 意見
Filed under: , , ,
 

簡報: Power Management from Linux Kernel to Android

上週五 (June 19),Matt 跟我分享 Android 之上 Power Management 的背景概念、實做,以及可改進的方向,而論及 Android 的系統架構設計時,不免得先談談 Linux PM,期待這份簡報對進行系統移植與客製化的同好有助益:

授權方式採用 Creative Commons S-A 3.0,不完善與謬誤處,請多指教,謝謝!

read on
Posted 張貼者: jserv 於 凌晨4:36 on 2009年6月22日 星期一 | 0 意見
Filed under: , ,
 

升級 Android 內建 GNU Toolchain 到 gcc 4.4

GNU GCC 4.4 已於 Apr 21, 2009 正式釋出,伴隨眾多改進、修正,與硬體平台改善,詳情可見"GCC 4.4 Release Series Changes, New Features, and Fixes",不過 Android repository 裡頭的 prebuilt GNU Toolchain 仍停留在 gcc-4.2.1 (Release date: Jul 18, 2007),總是有些遺憾,且讓我們動手改變。

EMBINUX™ Lab 提供一份 prebuilt GNU Toolchain for Android,參考其 git 的更動,可建立一套基於 gcc-4.4 與 binutils-2.19.1 的 toolchain,筆者準備打包好的套件: toolchain-arm-eabi-4_4_0.tar.bz2。另外,因為 gcc-4.4 對於 C/C++ 語意更加嚴格,像是應用程式對 va_list 的使用就需要調整,筆者將這些小修改整理為 migrate-gcc44.patch。以下是簡要的升級方式:

# cd mydroid
# cd prebuilt/linux-x86/toolchain
# tar jxvf toolchain-arm-eabi-4_4_0.tar.bz2
# cd ../../..
# patch -p1 < migrate-gcc44.patch
重新編譯與建構 Android 即可。需要更動的部份,列出作參考:
# diffstat migrate-gcc44.patch
core/combo/linux-arm.mk | 2 +-
dist/sqlite3.h | 2 +-
envsetup.sh | 2 +-
pdk/ndk/samples/sample/Makefile.lib | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)

read on
Posted 張貼者: jserv 於 下午6:04 on 2009年6月18日 星期四 | 1 意見
Filed under: ,
 

改善 Android 中 memcpy 效能

在 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. .global memcpy_neon

  4. .func memcpy_neon
  5. memcpy_neon:
  6. push {r4-r11}
  7. mov r3, r0
  8. 1: subs r2, r2, #128
  9. pld [r1, #64]
  10. pld [r1, #256]
  11. pld [r1, #320]
  12. ldm r1!, {r4-r11}
  13. vld1.64 {d0-d3}, [r1,:128]!
  14. vld1.64 {d4-d7}, [r1,:128]!
  15. vld1.64 {d16-d19}, [r1,:128]!
  16. stm r3!, {r4-r11}
  17. vst1.64 {d0-d3}, [r3,:128]!
  18. vst1.64 {d4-d7}, [r3,:128]!
  19. vst1.64 {d16-d19}, [r3,:128]!
  20. bgt 1b
  21. pop {r4-r11}
  22. bx lr
  23. .endfunc
至於 SurfaceFlinger 的操作仍有優化的空間,稍後再討論。

read on
Posted 張貼者: jserv 於 下午2:34 on | 1 意見
Filed under: , , ,
 
Developer at 0xlab.