GPU在Android顯示系統中的應用與研究

李洪輝，劉志勤

（西南科技大學 計算機科學與技術學院，四川 綿陽621010）

0 引 言

Android系統在智能手機、數字電視、機頂盒等視聽產品中廣泛應用，豐富的游戲娛樂軟件對顯示及3D圖形性能要求越來越高。顯示系統直接負責與用戶交互，是Android核心，其處理速度和顯示效果很大程度上影響到用戶體驗。目前，原生Android中顯示系統是在通用處理器上的軟件實現，圖形的繪制、顯示窗口的融合不僅占據了大量的CPU資源，而且顯示處理速度慢、顯示效果差。因此，提高Android顯示系統性能改善顯示效果成為了亟待解決的關鍵問題之一。

近年來，集成強大圖形處理能力的嵌入式微處理器的出現，不少學者采用硬件加速技術對圖形系統進行優化。蔣永剛[1]等通過深入分析嵌入式多媒體系統中的2D硬件圖形加速器，設計了一種無縫軟硬件圖形加速架構，利用設備驅動統一了繪圖函數接口。董劍[2]對在北大眾志Unicore平臺上利用硬件通道傳遞和更新顯示內容，減少跨層函數調用以及顯示內容的交換次數，這依賴于處理器的硬件通道。凌明[3]也在Unicore平臺上通過對GPU驅動模塊性能分析，修改內核態映射空間來提升用戶態內核圖形數據訪問效率，這依賴于處理器對Linux內核虛擬地址空間的映射策略。

本文以OMAP3530芯片的PowerVR SGX 530圖形處理器內核為平臺，借鑒前人經驗從驅動程序和顯示內容兩方面入手，實現GPU硬件加速技術在Android顯示系統中的應用優化，改善顯示系統性能，改善用戶體驗。

1 Android顯示系統

1.1 顯示系統框架

Android顯示系統采用采用客服端／服務器 （client／server）模式，通過Android的Binder服務機制實現。服務端主要由C＋＋語言實現，主要由Surface Flinger系統服務來提供服務。客服端包括，實現來調用輸入和輸出設備驅動程序的C語言底層，和為應用程序構建UI元素的JAVA繪圖接口。顯示系統的C語言部分和Java語言部分通過JNI接口調用。顯示系統框圖如圖1所示。

圖1 顯示系統框架

（1）C語言部分包括:

Skia（2D圖形圖像引擎），負責2D圖形繪制；

OpenGL｜ES（3D圖形引擎），負責3D圖形繪制和2D圖形搬運操作；

libui（顯示系統框架），提供顯示接口框架庫；

Surface是應用程序顯示的基本單元，可以包含一個或多個，是SurfaceFlinger的客服端；

SurfaceFlinger負責將各Surface按照Z－order（垂直屏幕序列）融合到顯示緩存中，是Surface的服務端；

Pixelflinger為OpenGL ES引擎提供的一套軟件渲染器；

FrameBuffer（幀緩存區），是最終顯示內容的存儲區。

（2）JAVA語言部分主要包括:

android.graphics對應Skia庫，提供繪圖接口；

android.view.Surface:構建顯示界面；

android.view.View:包含各UI元素基類；

javax.microedition.khronos.opengles:OpenGL ES接口；

android.opengl:Android系統和OpenGL聯系層。

在C語言模塊中，libui提供顯示接口框架庫，其他庫為實現庫通過類繼承方式來實現。連接JAVA部分的JNI庫通過libui庫接口實現。

1.2 顯示系統繪制流程

Android中顯示系統的繪制依賴于SurfaceFlinger服務，主要有應用程序請求、顯示內容繪制、顯示更新3個步驟，其繪制流程請參見文獻[2]，如圖2所示。

圖2 顯示系統繪制流程

在顯示系統中看到的每一個組件就是一個View。上層應用程序通過JAVA的本地方法調用Skia和OpenGL ES圖形庫的圖形繪制原語，將各視覺元素的繪制在每個View對應的一個或多個Surface上。Surface是服務端Surface－Flinger創建的，為各應用程序進行繪圖操作提供的中介。每個Surface的創建都會得到一個Canvas對象，它是用來管理View在Surface上的繪圖操作。

每個Surface上的繪制內容存儲在其Canvas對象對應的一個Buffer中，這個Buffer就是Surface的繪制緩存BackBuffer。當繪制完成后，Surface通過Binder機制向SurfaceFlinger請求顯示更新；這時會將Surface的顯示緩存Frontbuffer和繪制緩存Backbuffer互換，直接顯示Backbuffer的數據到屏幕。這種雙緩沖技術可以避免屏幕閃爍，減少了數據的拷貝。

SurfaceFlinger收到一個或多個Surface客戶端請求時，會通過EGL接口調用OpenGL ES來融合顯示畫面 （compose surface）。融合完成后將顯示內容輸出到Framebuffer設備上，以輸出到顯示設備。Android使用標準Frame－Buffer驅動接口，設備節點路徑為／dev／graphics／fb0，該設備節點由init進程自動創建，并由libui調用。

1.3 顯示性能分析

為了更好了解顯示系統性能，本文對0xbenchmark基準測試工具中2D和3D測試程序進行了函數級的Oprofile[4]測試。測試環境如下:CPU主頻設置為最大600MHz，Android4.0（ICS）版，測試結果見表1和表2，其中P為單個函數運行時間在系統總運行時間中所占比例。

表1 2D圖形繪制Oprofile結果

表2 3D圖形繪制Oprofile結果

由表1、表2可知，2D測試和3D測試中P值最大的是libpixelflinger的融合函數占32%左右，其次為libGLES＿android庫的繪圖函數占28.50%，libskia.so的繪圖函數占27.78%。

2 軟硬件平臺及GPU優化方案設計

2.1 軟硬件平臺

本文采用Texas Instruments公司的OMAP3530處理器，搭配有256MDDRII內存和512M的NAND Flash存儲。OMAP3530是一個異構多核的處理器芯片，不僅具有嵌入式常用的ARM Cortex－A8內核，還具有2D／3D圖形加速的 PowerVR SGX 530 1.2.1版 GPU 內核[5]。圖像處理器GPU是高度并行化的更適合圖形化操作，SGX530圖形引擎每秒繪制多邊形數最大可達到10M個，支持Open－GL ES1.1、OpenGL ES2.0、OpenVG1.0工業標準接口。OpenGL ES提供了靈活且功能強大的底層的接口，這為圖形加速程序的開發提供了方便。OpenVG針對像Flash和SVG矢量圖形算法庫提供底層硬件加速界面的免授權、跨平臺應用程序接口。

實驗平臺硬件方面Cortex－A8CPU主頻設置為最大600MHz，PowerVR SGX 530GPU主頻為110MHZ，內存DDR II 256MB，以太網接口100Mbps，根文件系統通過NFS掛載。

軟件方面，系統引導程序BootLoader包括x－load－1.41、u－boot－2010.06，Linux內 核 使 用 2.6.37，Android文件系統使用Android 4.0（ice cream sandwich），交叉編譯器使用 Android源碼中的arm－eabi－gcc 4.4.3。

2.2 GPU優化方案設計

libpixelflinger是SufaceFlinger在沒有硬件加速情況下，軟件實現的融合器。在Android 2.0以后SufaceFlinger直接調用OpenGL ES API，如果存在OpenGL ES硬件庫則系統自動調用硬件庫API實現多窗口融合。

然而，PowerVR SGX 530GPU內核支持對OpenGL ES 3D硬件加速接口，可以使用OpenGL ES硬件接口的實現窗口融合加速。同時OpenGL ES接口的集成，可以不在使用libGLES＿android軟件實現的OpenGL接口，而使用硬件來完成3D圖形繪制。

Skia圖形引擎擁有完整的2D圖形算法，Skia圖形繪制是基于CPU完成地，直接使用GPU實現Skia繪制可能不會帶到優化效果。文獻[6]中Huang Dongsung使用GPU實現的Skia和原生Skia進行對比，實驗結果出乎意料:Skia GPU的渲染速度比CPU的渲染速度慢2倍以上。作者使用GDEBugger、Callgrind工具發現Skia對glDraw－Something調用次數太多，glstates改變次數太多，對framebuffer節點／graphic／fb0開關次數太多。

Skia集成了一個基于OpenGL ES2加速的后端，被稱為Ganesh。Ganesh已經實驗了兩種加速方式[7]，一種在渲染過程中使用模板緩存；另一種對加載紋理進行光柵化，讓GPU提供適當的抗鋸齒覆蓋。Android的2D矢量圖形部分并沒有使用OpenVG而是使用Skia庫，對OpenVG并不支持。因此這里沒有考慮使用OpenVG來實現2D加速，而是集成OpenGL ES接口支持Skia的Ganesh后端來實現2D加速。

因此使用OpenGL ES硬件接口來實現了GPU在Android顯示系統中的優化，在此之前還需要對GPU設備驅動進行集成。

3 GPU優化方案實現

在分析Android顯示系統框架及其繪制流程的基礎上，利用GPU硬件對圖形系統進行加速優化。GPU的開發使用了TI提供的GPU軟件開發包[8]Graphics＿SDK＿setup linux＿4＿06＿00＿02.bin。

3.1 GPU驅動編譯及安裝

GPU圖形開發包包括omaplfb、pvrsrvkm和bufferclass＿ti內核模塊[8]，這些模塊需要在運行時加載到系統中。

Omaplfb.ko:負責和平臺底層特定的FrameBuffer驅動進行交互；

Pvrsrvkm.ko:負責和用戶空間的PVR服務層交互；

ufferclass＿ti.ko:負責將特定后綴的文件流，流向SGX處理器進行處理。

進入開發包安裝目錄，編輯Rules.make文件，修改下列環境變量值:Graphics＿SDK安裝目錄、交叉編譯器路徑及其前綴、內核安裝路徑、目標文件系統安裝路徑。然后，設置處理器架構并編譯make ARCH＝armBUILD＝release OMAPES＝3.x all。順利完成后，安裝內核模塊及OpenGL ES庫等軟件模塊到根文件系統中make ARCH＝armBUILD＝release OMAPES＝3.x install。

在Android的啟動文件init.rc中添加sgx＿service服務，用以加載內核模塊，而且該服務需要添加在adbd服務之前。

service pvr／system／bin／sgx／rc.pvr start

class core

oneshot

3.2 OpenGL ES硬件接口集成

OpenGL本地庫有軟件庫和硬件庫兩種實現方式:軟件實現對應libagl.so；硬件實現對應libhgl.so。OpenGL本地本地庫的加載是通過libs／EGL／egl.cpp中egl＿init＿drivers（） （egl＿init＿drivers＿locked（）調用libs／EGL／Loader.c文件中的loader::open（）函數打開軟件和硬件EGL加速驅動。加載流程如圖3所示。根據／system／lib／egl／egl.cfg文件，分別加載并解析libagl和libhal；獲取其中標準OpenGL函數的函數地址 （函數指針）。系統調用時，通過函數指針調用libagl或libhgl，從而實現圖形的繪制。

圖3 OpenGL本地庫加載流程

配 置 文 件 “／system／lib／egl／egl.cfg” 在 libs／EGL／Loader.c文件的Loader::Loader（）函數打開，并賦值給dpy、impl、tag這3個變量，Loader::open（）函數中通過dpy、impl與tag來加載默認的軟件實現動態庫或者硬件實現動態庫中的EGL、GLESv1＿CM、GLESv2這3個部分的函數。如果加載成功則new一個driver＿t架構，并用加載的函數進行初始化。

將OpenGL ES庫安裝到Android文件系統中后，修改OpenGL ES接口的配置文件／system／lib／egl／egl.cfg為

0 0android

0 1POWERVR＿SGX530＿121

Android啟動時讀取／system／lib／egl／egl.cfg中的dpy＝0，impl＝1，tag＝POWERVR＿SGX530＿121；Loader::open（）函數中通過獲取該dpy、impl與tag來加載硬件加速動態 庫／system／lib／egl／libEGL ＿POWERVR ＿SGX530 ＿121.so中的EGL、GLESv1＿CM、GLESv2這3個部分的函數。若加載失敗則dpy＝0、impl＝0、tag＝android，使用默 認 的 軟 件 實 現 動 態 庫／system／lib／egl／libGLES＿android.so，繼 續 使 用 libpix elflinger.so、libGLES ＿android.so。

4 實驗測試與結果

實驗測試硬件環境、軟件環境和性能測試時一樣。測試軟件使用0xlab[9]提供的0xbenchmark[10]基準測試工具對2D和3D圖形進行測試，測試結果如表3和表4所示。

由表3可以看出，2D圖形每秒幀數平均是原來的3.32倍，同時CPU負載平均下降了19.19%。其中Draw Circle CPU負載上升了7.93%，這是因為和比Draw Circle2相比Draw Circle的每秒幀數多1.1倍，CPU負載更高。

表3 使用GPU優化前后2D性能測試數據

表4 使用GPU優化前后3D性能測試數據

由表4可以看出，3D圖形每秒幀數平均是原來的5.53倍，同時CPU負載平均下降了70.87%。其中OpenGL Cube和OpenGL Teapot比其他兩個測試實例加速比小，是因為OpenGL Cube和OpenGL Teapot都需要對魔方（cube）和茶壺 （teapot）進行繪制，而其兩個實例主要是紋理映射，繪制計算量相對較小。魔方 （cube）的繪制包含多個立方體及其面不同顏色的繪制，相比茶壺 （teapot）繪制計算量較大，加速比也就較小。

5 結束語

本文對Android顯示系統的基本框架和繪制流程分析的基礎上，在OMAP3530處理器平臺對顯示系統進行性能分析，并提出了使用GPU來優化Android顯示子系統。從GPU設備驅動和OpenGL ES接口兩方面實現了GPU在Android顯示系統中的優化。使用0xbenchmark對2D和3D性能測試，實驗結果顯示2D和3D每秒幀加速比平均為4.12，同時CPU負載平均下降38%，顯示性能大幅提升，達到了預期目的。

[1]JANG Yonggang.Apply hardware accelerator in embedded multimedia system[D].Shanghai:Shanghai Jiaotong University，2009（in Chinese）.[蔣永剛.嵌入式多媒體系統中硬件加速技術的應用[D].上海:上海交通大學，2009.]

[2]DONG Jian.Research of applying hardware acceleration in the Android display system[D].Shanghai:Fudan University，2011（in Chinese）.[董劍.Android顯示系統應用硬件加速技術的研究[D].上海:復旦大學，2011.]

[3]LING Ming，WU Jianping，LIU Qi，et al.Optimization for Android graphics system based on domestic Unicore architecture[J].Southeast University Journal of Southeast University（Natural Science Edition），2012 （6）:1069－1073 （in Chinese）.[凌明，武建平，柳琦，等.面向國產Unicore架構的Android圖形系統優化[J].東南大學學報 （自然科學版），2012 （6）:1069－1073.]

[4]Oprofile.OProfile－A system profiler for Linux[EB／OL].[2013－01－20].http:／／oprofile.sourceforge.net／.

[5]Texas Instruments.DSP ＋ ARM Cortex－A8－OMAP3525／30 SOC－OMAP3530－TI[EB／OL].[2013－01－21].http:／／www.ti.com.cn／product／cn／omap3530.

[6]HUANG Dongsung.How much Skia GPU can accelerate Web－Kit rendering on Android[EB／OL].[2013－2－20].http:／／www.dorothybrowser.com／41／.

[7]Kilgard M J，Bolz J.GPU－accelerated path rendering[J].ACM Trans Graph，2012，31 （6）:1－10.

[8]Texas Instruments.Texas instruments Linux graphics SDK[EB／OL].[2013－01－31].http:／／software－dl.ti.com／dsps／dsps＿public＿sw／sdo＿sb／targetcontent／gfxsdk／latest／index＿FDS.html.

[9]0xlab. 0xLab－Home[EB／OL].[2013－02－20]. http:／／0xlab.org／.

[10]0xbench.Benchmarks－comprehensive benchmark suite for Android[EB／OL].[2013－02－20].http:／／code.google.com／p／0xbench／wiki／Benchmarks.