Android Wave

上篇文章提到的程式碼已上線，有興趣的朋友可以到 Android Eee PC 專案網頁下載。

在做 clean build 的空檔，請 Jeremy 幫忙錄了一段影片，以證明加速是真的 XD



不過錄到後半，我頭暈得差點連瀏覽器 icon 在哪都找不到，所以請注意不要靠太近看。再來兩天要參加 FreedomHEC Taipei 2009，順便休息一下。

Android 3D acceleration on x86

過去一、二個月的文章都是圍繞著 android x86 與 mesa/dri 在打轉，原因無它，因為這陣子在做的事恰好就是 Android 在 Eee PC 上的 3D 加速。因為 android 跟 mesa 都是第一次接觸，所以確實費了不少工夫在認識它們。

Android 在起來的時候，會試著載入 /system/lib 底下的 libagl.so 與 libhgl.so。前者是 OpenGL ES 與 EGL 的純軟體實作，source code 在 frameworks/base/opengl/libagl/ 底下；後者則與硬體相關，目前沒有開放的實作。所以我做的事基本上就是寫一份 libhgl.so。

之前在 DRI Overview 有提到，只要有適當的 loader，DRI driver 可以在 X 以外的平台使用。目前我的 libhgl.so 實作是基於 eagle，並只支援 intel graphics chipsets。因為 i915_dri.so 實作了 OpenGL，而不是 OpenGL ES，所以定點數與部份 ES 才有的 extension 沒有辦法支援。這個問題最快的解決方式應該是改用 Gallium 搭配 OpenGL ES state tracker，這也是接下來要評估的。

對 Android 本身，主要則有三個部份需要修改。一是 EGLDisplaySurface 要用 kernel modesetting 的實作取代，同時 kernel 也要上 2.6.29；二是 GPUHardware 要改用 i915 的 GEM object 實作；三是 Surface 要能認得 GEM object。

目前整個 Android 系統可以正常運作。SurfaceFlinger 或一些 3D 軟體像是 Android-GL 也可以正確地被加速。不過目前的實作比較接近於驗證這個方式的可行性。程式碼整理好後會放在 Android Eee PC，到時有興趣的開發者都可以一同參與。

Android Window System

在上星期 0xlab 的討論會中，我對 Android 的視窗系統做了簡短的分享，投影片可以在這邊取得。簡報內容主要在介紹 SurfaceManager，同時也附上簡短的範例程式，示範利用 Android 的 native library 取得可用來繪圖的記憶體。

之前的文章提到 Android 跟 cairo 的結合，也是利用一樣的方法，麻煩的地方反而是在於 cairo 的編譯。我當時是照著 cairo (與 pixman) 的 Makefile.am 寫一份 Android.mk，非常的苦。jserv 後來提到了 agcc，或許可以拿來與既有程式的 autotools 結合。

不過苦也有苦的好處，因為苦慣了就不會害怕。不小心還會弄出怪怪的東西



花了一陣子的時間在認識 Android，慢慢地也比較能掌握。希望下篇文章開始，本小站可以脫離嘴炮，向上提升。

一千零一夜之 eagle

這個系列是讀書筆記，作者可能沒有跟主題有關的開發經驗。

之前的文章提到過，只要有適當的 loader，DRI driver 也可以用在 X server 以外的平台，eagle 就是一個例子。eagle 提供開發者接近於 EGL 的 API，並且可以運作在支援 DRI2 的 X server 與支援 GEM 的 intel drm 之上。這篇文章主要想討論後者。

eagle 與視窗系統無關的實作，行數落在大約 800 行左右。intel drm 的支援也只在 250 行左右。對它使用到的技術有些許了解後，只要花一個晚上就可以讀完，算是學習 linux 3D 實作不錯的途徑。也因為它的簡單，閱讀過程如果有難以理解的部份，也可以馬上修改跑跑看。如果這兩部份看完後想要再看 DRI2 的部份，eagle 也可以讓人滿足。

intel drm 的支援在 eagle 中稱為 backend，以 EagleBackend 表示。Backend 與視窗系統相關，要提供的主要功能有

• 建立 EGLSurface


• 提供 DRI driver 需要的 GEM buffer


• 更新畫好的內容到螢幕上

intel drm backend 建立 EGLSurface 的函數是 intelCreateSurfaceForName。這邊的 name 型別為 uint32_t，指的是 GEM buffer 的 identifier。如果沒給的話，backend 會產生一塊新的 buffer。client 可以要求 double buffering，這時 surface 的 backBuffer 會設為 EGL_TRUE。

intelGetBuffers 負責提供 DRI driver 需要的 GEM buffer，像是 front buffer，back buffer 或 depth buffer 等。這邊要特別注意，在 double buffering 的情形，也就是 backBuffer 設為 EGL_TRUE 的時候，即便 DRI driver 要求了 front buffer，intelGetBuffers 還是會產生新的 buffer 回傳給 DRI driver，而不是回傳 intelCreateSurfaceForName 時給定或產生的 front buffer。這個新產生的 buffer 也被稱為 fake front buffer。

最後看到 intelSwapBuffers，也就是 eglSwapBuffers 會呼叫的函數。可以看到，當不是 double buffering 時，這個函數會直接 return，因為 DRI driver 本來就是畫在真正的 front buffer 上。若是 double buffering 的話，intelSwapBuffers 會把 DRI driver 以為的 (fake) front buffer 複製到真正的 front buffer 上。

Backend 大致上就處理這些事情。eagle 的核心則負責提供接近 EGL 的 API。它同時也是 DRI loader，選定適當的 EagleBackend 並載入適當的 DRI driver。除了選擇與 dlopen 適當的 .so 檔外，核心其餘的程式碼大多在處理 EGL 的型別與 DRI 型別的對映。這個部份很基礎，也是所有想寫 loader 的開發者都要熟悉的東西。這邊的程式碼比較直接，有興趣的人可以自行閱讀。

在初次研讀 eagle 的過程中，我最感興趣的其實是這篇文章沒提到的 glapi。這是 mesa 或 mesa 自動產生的程式碼，其中後者佔了絕大多數。在許多功用中，其中一項功用是提供 OpenGL (ES) 的 global symbols，讓 link 到 libeagle.so 的程式可以呼叫 gl* 等函數。這可以算是 mesa build system 的一部份，對熟悉 linux 3D 的組成有相當的幫助。