SurfaceFlinger在X Window系統環境下的運行方案①

江 帆,賀也平,周啟明

(中國科學院 軟件研究所 基礎軟件國家工程研究中心,北京 100190)

SurfaceFlinger在X Window系統環境下的運行方案①

江 帆,賀也平,周啟明

(中國科學院 軟件研究所 基礎軟件國家工程研究中心,北京 100190)

本文給出一種將Android圖形系統SurfaceFlinger移植到桌面Linux發行版的X Window系統環境下運行的方案.在X Window系統環境下運行的SurfaceFlinger可使Android運行環境中以本地進程形式的Android應用進程的UI界面顯示到X Window的窗口中.使用Mesa作為OpenGL ES實現并使Mesa EGL兼容Android的本地窗口ANativeWindow,同時借助Androidx86的gralloc.drm.so模塊,實現了Android應用程序的UI渲染過程SurfaceFlinger的圖像合成過程能夠使用GPU進行硬件加速.另外,用X11的DRI2擴展協調 SurfaceFlinger的窗口和X Server的DDX驅動,使合成后的圖像能高效地更新到窗口中,避免了SurfaceFlinger的圖像緩存由獨立顯存到系統內存的拷貝過程.經實驗,在本移植方案下,第三方3D基準測試軟件San-Angeles能達到60FPS的幀率.相比于已有方案,本方案的架構更加簡潔高效,且支持硬件加速.

Android圖形系統; SurfaceFlinger; X Window系統; 移植; 兼容環境

Android運行環境可以使數量眾多的Android應用程序不經修改即可在桌面Linux系統上以本地進程的形式運行,這對于原本應用資源匱乏的桌面Linux系統來說是一個很好的補充[1].而使Android的圖形系統SurfaceFlinger在桌面Linux系統上運行是構建Android運行環境的重要環節.SurfaceFlinger的主要功能是將應用窗口和系統窗口合成一幀完整畫面并提交到屏幕顯示.張超等[2]成功地實現SurfaceFlinger在桌面Linux的X Window環境下運行.其主要方法是利用軟件渲染的方法方式將SurfaceFlinger合成的圖像寫入共享內存,再由一個桌面圖形程序輸出畫面.該方法的不足是使用軟件渲染而沒有調用GPU實現硬件加速,造成占用大CPU時間,并且畫面輸出過程需要不斷調用IPC,在處理3D圖形時只有個位數的幀數,性能十分低下.

提高圖形系統性能的思路是使用GPU進行硬件渲染而非使用CPU進行軟件渲染.arm架構和x86架構在圖形系統方面存在較大差異.具體表現為arm架構下的GPU沒有獨立顯存,所有程序的圖像緩存都位于系統內存,而在x86的Linux內核之上,需要使用DRI框架來調用GPU,并且GPU有自己的獨立顯存[3].而面向arm架構設計的SurfaceFlinger的源碼即使能面向x86架構編譯,也不能直接在x86架構的Linux內核之上運行.另一方面,SurfaceFlinger在自己的圖像緩存上合成好的畫面幀需要提交到X Window的窗口中顯示.因此,要實現SurfaceFlinger在X Window系統環境下運行,需要解決的問題主要有兩個:1)使Android應用程序的UI渲染過程和SurfaceFlinger的圖像合成過程能夠在x86架構的Linux內核之上進行硬件加速;2)使SurfaceFlinger的圖像緩存能夠顯示在X Window的窗口中.

從OpenGL ES的角度來看Android應用程序的UI渲染過程和SurfaceFlinger的圖像合成過程,Android應用程序和SurfaceFlinger都可以看作是OpenGL ES的應用程序.因此首先需要一種能在x86 架構下使用的OpenGL ES的實現作為GPU驅動.Androidx86項目在讓Android系統在x86架構的PC上運行做出了重要貢獻[4].該項目使用Mesa[5]作為OpenGL ES實現,并基DRM[6]和GEM[7]實現了gralloc.drm.so模塊,成功地使SurfaceFlinger在x86架構下運行并實現硬件加速.但是該項目的目標是在x86架構下運行完整的Android系統,因此其運行時會占用整個顯示屏,并不能實現在桌面Linux的圖形系統X Window的環境下獨立運行SurfaceFlinger程序.本文以Mesa作為OpenGL ES實現,借用Androidx86的擴展的Mesa EGL的DRI驅動實現對Android本地窗口ANativeWindow的支持,并使用gralloc.drm.so進行圖像緩存的申請,成功實現了基于硬件加速的Android應用程序UI渲染.對于SurfaceFlinger將畫面提交到窗口顯示的過程,首先SuracefFlinger需要有自己的窗口.其次使用gralloc.drm.so直接通過內核DRM模塊申請的顯存無法和Surface-Flinger的窗口進行內在綁定.本文使用X11的DRI2擴展協調SurfaceFlinger的圖像緩存和窗口,有效避免了SurfaceFlinger圖像緩存由GPU獨立顯存到系統內存的拷貝,使得SurfaceFlinger的窗口畫面更新過程更加流暢.

本文余下章節的結構如下.第1節,以Android應用程序UI渲染到SurfaceFlinger合成的畫面在窗口中顯示的過程為線索,分析整體架構的運作流程.第2節,為更好地理解系統架構的原理,分析Android應用程序UI渲染過程中涉及到的關鍵組件.第3節,在不考慮X Window系統的情況下,討論Android應用程序和SurfaceFlinger如何在x86的架構下運行并支持硬件加速.第4節,給出SurfaceFlinger和X Window系統兼容的關鍵技術和進一步的優化方案.第5節,給出并分析移植方案在各型GPU上運行的實驗結果.第6節,結語.

1 總體架構

圖1描述了SurfaceFlinger移植到X Window環境下的架構.序號1至19描述了從Actitity的UI渲染到畫面最終提交到窗口的完整過程.整個系統運行于開啟了Binder驅動的x86架構的Linux內核之上./dev/binder和/dev/dri/card0分別為Binder IPC和DRM內核子系統的設備文件.

App的UI使用硬件渲染路徑(1～6).軟件渲染調用CPU在系統內存上進行計算,這樣會占用大量CPU時間,性能低下.因此從OpenGL ES的角度來看,所有App都是OpenGL ES的應用程序.App的圖像緩存通過EGL向Surface申請.Android的本地窗口是BufferQueue(由 producer和 consumer組成)的 wrapper,因此Surface拿到的圖像緩存是從BufferQueue申請的GraphicBuffer.GraphicBuffer包含的圖像緩存的實際句柄則是通過gralloc.drm.so調用libdrm向內核的GEM模塊申請的.

SurfaceFlinger同樣擁有自己的Surface,但是它的圖像緩存則是通過xwindow.default.so調用X11的DRI2擴展向X Server的DDX驅動申請的,而非直接調用libdrm向內核申請.這樣可使SurfaceFlinger圖像緩存的GEM句柄和SurfaceFlinger自己的窗口在X Server端產生內在綁定.

圖1 系統架構

當一個Activity的一幀畫面渲染好以后,就通過BufferQueue經Binder IPC機制將GraphicBuffer提交到SurfaceFlinger中(7～8).GraphicBuffer支持序列化,因此可以通過Binder傳遞.每個Surface對應Surface-Flinger中的一個Layer.當一個由EventThread發處的VSync同步信號到來時,SurfaceFlinger就會調用OpenGL ES將這些Layer合成為一幀畫面(9～10).SurfaceFlinger同樣需要有自己的本地窗口Surface來承載這一幀合成好的圖像.在INVALIDATE_ON_VSYNC宏置為1時,在Surface緩存更新的同時發起一個畫面更新.

因為桌面上沒有硬件HWComposer,因此Surface-Flinger的畫面合成過程是基于OpenGL ES完成的,而hwcomposer.x86.so只是一個符合HWComposer 1.0 接口標準的軟件實現,并不是硬件HWComposer的驅動程序.它的set()接口僅調用了EGL層的eglSwapBuffers()函數進行前后臺圖像緩存更新,eglSwapBuffers()再調用Surface的queueBuffer()將一個GraphicBuffer通過BufferQueuer傳給了同位于SurfaceFlinger進程中的作為consumer的 FrameBufferSurface對象(11～14).FrameBufferSurface接下來通過gralloc.drm.so將這個渲染好的GraphicBuffer提交到窗口.

在HAL層中基于Xlib和X11的DRI2擴展實現了xwindow.default.so模塊.SurfaceFlinger通過該模塊和X Server通信,并創建屬于SurfaceFlinger自己的窗口.gralloc.drm.so將這個渲染好的GraphicBuffer提交到窗口的過程由xwindow.default.so調用X11的DRI2擴展的pageflip功能完成(15～19).

本項目基于源碼分支android-5.1.1_r9開發.后續章節中關于Android圖形系統的分析以該版本為基準.

2 Android應用程序的UI渲染路徑

為理解移植后的系統架構如何運作,我們以Android應用程序UI渲染到圖像呈現在屏幕的過程為線索,分析該過程中涉及的一些Android圖形系統的關鍵組件.

要讓SurfaceFlinger在X Window環境下運行,我們首先需要了解在arm架構下Android系統中App的UI是如何渲染和顯示到屏幕的以及SurfaceFlinger在這個過程起到的作用.App的UI界面的渲染方式分為2D和3D兩種.進行2D渲染的方式包括:1)調用Canvas的drawRect(),drawText()等方法將像素點繪制到一個Bitmap; 2)View的子類繪制Button、List等空間; 3)或一個定制的View類實現開發者自己定義的行為等.2D渲染有兩條路徑,一是使用hwui的基于OpenGL ES2.0的硬件渲染,一種是使用Skia軟件渲染引擎的軟件渲染.Android的UI繪制也支持硬件加速,這時Activity會創建一個GLSurfaceView并且使用OpenGL ES的Java綁定接口(android.opengl.*)進行畫面渲染.AOSP中提供的libEGL.so、libGLESv1_CM.so、libGLESv2.so、libGLESv3.so只是EGL和OpenGL ES實現的wrapper,底下真正調用的是由供應商提供的閉源專屬GPU驅動或Android自己實現的軟件GPU模擬PixelFlinger.但是不論是2D渲染還是3D渲染,最終的渲染結果的所有像素點都位于該Activity的Surface之上.

2.1 SurfaceFlinger

SurfaceFlinger是Android的窗口合成器.它和App的Surface構成了C/S架構.一個完整的屏幕界面實際上是由多個窗口(包括導航條、狀態條和應用UI)合成后的結果.每個窗口分別屬于不同的進程,由這些進程獨立渲染在自己的Surface之上.每個Surface對應SurfaceFlinger中的一個Layer,這些Layer通過z軸順序排列起來.SurfaceFlinger基于OpenGL ES的API將這些Layer合成一幀完整的畫面.

2.2 BufferQueue和gralloc

Surface和SurfaceFlinger構成C/S架構.Buffer-Queue是Surface和SurfaceFlinger之間進行Graphic-Buffer交換的通道.App從Surface獲取新的Graphic-Buffer并將繪制好的GraphicBuffer通過Buffer-Queue傳遞給 SurfaceFlinger,而 SurfaceFlinger從BufferQueue接收渲染好的GraphicBuffer用于下一幀的畫面合成,同時將新的GraphicBuffer放入BufferQueue傳遞給App的Surface.

gralloc是Android HAL層定義的圖形緩存分配器.在BufferQueue中傳遞的GraphicBuffer對象通過gralloc獲取實際的圖像緩存描述句柄.gralloc的圖形緩存申請接口alloc()接收width,height,pixel format以及usage flags等參數.App和SurfaceFlinger使用圖像緩存的目的不同,App是為了渲染UI畫面并傳遞給SurfaceFlinger進行圖形合成,而SurfaceFlinger要在自己的圖像緩存上合成最終畫面并提交到屏幕顯示.因此它們申請圖像緩存的類型也不一樣,具體表現為usage flags參數的區別.SurfaceFlinger是GRALLOC_-USAGE_HW_FB,而App的則是其他類型.因此,需要在App和SurfaceFlinger之間傳遞的App的圖像緩存是從Ashmem申請的共享內存,而SurfaceFlinger的圖像緩存則是Framebuffer.但在arm架構下,兩者實際上都位于系統內存之上.App的畫面渲染完成時會通過Ashmem共享內存換地給SurfaceFlinger,而Surface-Flinger在畫面合成完畢時會調用Framebuffer的pageflip機制將新生成的畫面更新到屏幕顯示.

2.3 Android的本地窗口Surface

本地窗口是EGL中的概念,EGL為了保證OpenGL ES的平臺獨立性,需要適應各種操作系統下的本地窗口.ANativeWindow是Android系統定義的本地窗口,也是EGL的Android平臺適配窗口,其中定義了獲取和釋放圖像緩存的接口.圖像緩存用ANative-WindowBuffer其定義,它描述了窗口的基本信息如寬度、高度、像素格式等基本信息.實際圖像緩存的地址和句柄buffer_handle_t結構體描述.Surface是應用層次的本地窗口,不論是App還是SurfaceFlinger,Android上的所有圖形程序都需要有自己的Surface,而Surface的作用就是給EGL層提供ANativeWindow的接口.上層應用即可通過這些接口獲取和釋放圖像緩存.

3 在x86架構下運行SurfaceFlinger

要讓SurfaceFlinger能在X Window的環境下運行,首先要解決的問題是如何讓SurfaceFlinger在x86架構的Linux內核之上運行.Androidx86項目很好地解決了SurfaceFlinger在x86架構下運行的問題.Android系統主要是為arm架構設計的,arm架構下的GPU沒有自己的獨立顯存,SurfaceFlinger通過Surface申請的的Framebuffer硬件緩存仍然是系統內存的一部分.而x86架構下,GPU有自己的專屬獨立圖顯存.SurfaceFlinger本身基于OpenGL ES實現,要使用x86架構的GPU進行硬件加速,就需要有可以在x86架構下運行的OpenGL ES實現.因此Androidx86項目在圖形系統方面的主要工作有兩點:1)使用Mesa作為OpenGLES實現; 2)實現了gralloc.drm.so.

3.1 Mesa和EGL

DRI是一個使應用程序在X Window系統的環境下直接發訪問圖形硬件的框架.其實現分散在X Server和它的客戶端共享庫Xlib、Mesa以及DRM內核子系統中[8].Mesa在DRI框架中扮演了GPU驅動的角色,因此Androidx86選擇Mesa作為OpenGL ES的實現.但是Mesa默認只支持X Window系統的本地窗口,而不支持Android的本地窗口ANativeWindow.在Mesa的架構中,EGL是OpenGL ES和本地窗口之間的一個中間層,其作用之一是保證OpenGL ES的平臺獨立性.因此Androidx86在Mesa EGL中添加了對ANative-Window的支持(platform_android.c),使得Mesa可以通過Surface獲取ANativeWindow.因此本文中借用Android對Mesa EGL的擴展實現對Android本地窗口的支持.

3.2 gralloc.drm.so

在X Window環境下,一個桌面OpenGL ES程序的圖像緩存是由Mesa EGL的DRI驅動(platform_x11.c)借用X11的DRI2擴展通過X Server的DDX驅動向內核申請的.而在Android系統中,實際圖像緩存申請操作是由GraphicBuffer類調用HAL層的gralloc完成的.在arm架構下,gralloc為應用申請的圖像緩存來自Ashmem共享內存,而為SurfaceFlinger申請的圖像緩存來自Framebuffer,這些圖像緩存本身都位于系統內存,而Mesa無法基于系統內存調用GPU進行硬件加速.這一點也從側面說明文獻[2]中的移植方法不支持硬件加速.gralloc.drm.so基于libdrm,實現了從x86架構的獨立顯存為應用程序和SurfaceFlinger申請圖像緩存.libdrm是內核DRM子系統的用戶態共享庫,應用程序可以通過libdrm調用內核的GEM模塊來創建圖像緩存對象,在用戶態使用一個GEM句柄(本質是一個整數)作為圖像緩存的引用.因此在arm架構下,buffer_handle_t包含的是圖像緩存的首地址,而在x86架構下包含的則是GEM句柄.這時,在Androidx86系統中,不論是App還是SurfaceFlinger,通過graloc.drm.so申請圖像緩存的過程是一樣的,并不會因為alloc()接口的usage flags參數不同而不同.另一方面,在Androidx86環境下,SurfaceFlinger會占用整個屏幕作為其畫面輸出的目標.這樣無法和桌面Linux發行版的X Window系統兼容.因此,要讓SurfaceFlinger的合成畫面在X Window系統的窗口中顯示,就需要將SurfaceFlinger的角色由Android窗口合成器降級為X Window系統的應用程序.

4 在X Window的環境下運行SurfaceFlinger

X Window系統是桌面Linux系統的標準圖形系統[9].它采用C/S架構,客戶端程序基于Xlib和X Server通過TCP連接通信,如果客戶端程序和X Server位于統一系統上,則使用IPC通信.因為X Window系統為分布式環境而設計,客戶端程序通過Xlib向X Server申請的資源(例如一個窗口)位于X Server中,客戶端程序只能拿到該資源的一個整數ID作為引用.

在Androidx86中,SurfaceFlinger在初始化時直接作為DRM Master,進行KMS設置,這樣會與X Server發生沖突.因為在一個桌面Linux系統中只允許有一個DRM Master.在畫面需要更新到屏幕是直接調用drm的pageflip機制進行屏幕畫面刷新,并且Surface-Flinger合成的畫面會顯示到整個屏幕上.現在我們要讓SurfaceFlinger在X Window系統的環境下運行,具體而言是讓SurfaceFlinger將更新后的圖像緩存提交到一個窗口中顯示.

4.1 移植方案

首先SurfaceFlinger需要有自己的窗口,此時SurfaceFlinger需要調用X Window的客戶端共享庫,而采用NDK編譯的SurfaceFlinger的ELF文件無法使用桌面Linux的默認動態鏈接器和已安裝的Xlib共享庫[1].因此需要將Xlib的源碼轉換為Android項目并使用NDK進行編譯,并基于移植的Xlib在HAL實現了xwindow.default.so模塊.SurfaceFlinger即可使用xwindow.default.so模塊創建自己的窗口.

當SurfaceFlinger需要將自己的Surface中的最新的GraphicBuffer提交窗口時,在SurfaceFlinger進程中已有兩個資源,一是通過GraphicBuffer的buffer_handle_t中獲取的圖像緩存標識GEM句柄,一是標識窗口的整數ID.一個直觀的方法是利用libdrm將GEM句柄描述的圖像緩存映射到系統內存空間,將這段空間封裝成XImage最后通過Xlib提交到X Server顯示.

XImage和Pixmap的區別是前者位于客戶端進程而后者位于X Server進程.XImage是一個結構體,包含了位圖的各種格式、大小等信息,同時還有一個指針指向像素數據所在的內存地址.所以我們可以根據圖像緩存在系統內存空間的映射來構造這個XImage,然后讓這個XImage顯示在SurfaceFlinger的窗口中.這個XImage最終要通過Xlib傳給X Server,由X Server顯示出來.但不論是TCP連接還是IPC機制,傳遞大塊內存的效率較低.所以我們使用了X11的共享內存擴展MIT-SHM[10].這樣,XImage就可以通過共享內存傳遞給X Server.相比于文獻[2]的架構,本架構下畫面更新頻率由HWComposer中用于模擬硬件VSync信號的VSyncThread的信號頻率決定(一般為60FPS,和顯示屏刷新率保持一致),而不需要額外的同步信號控制,也不需要額外的圖像顯示進程,因此總體架構更為簡潔.

4.2 優化方案

在各種GPU上測試時發現,只有在Intel集成顯卡上畫面刷新頻率能達到60FPS,而Nvidia和AMD獨立顯卡上畫面十分卡頓.在上述移植方案中,App和SurfaceFlinger從Surface獲取的圖像緩存都是通過libdrm向內核的GEM模塊申請的,因此基于Mesa的App的UI渲染過程和SurfaceFlinger的畫面合成過程是使用GPU進行硬件加速的.問題在于將GEM句柄標識的圖像緩存映射到系統內存空間并封裝到XImage的過程需要將圖像緩存從獨立顯存讀取到系統內存,這個過程的延遲較大.在該方法下,每次畫面更新都需要拷貝一次,因此拖慢了畫面刷新頻率.

優化的思路來自于對桌面上基于Mesa的圖形程序架構的思考.基于X Window系統的圖形程序申請圖像緩存是由X Server端的DDX驅動完成的,本質仍然是通過libdrm調用GEM內核模塊創建顯存對象.而桌面上基于Mesa的圖形程序調用eglSwapBuffers()進行畫面更新時,EGL的DRI驅動并沒有將圖像緩存拷貝到系統內存,但是畫面仍然能在一個由X Window系統創建的窗口中更新.因此桌面Linux上基于Mesa的圖形程序的圖像緩存的申請和更新是由Mesa和X Window協同完成的.其原理在于,在DRI架構中,X Server提供X11協議的DRI2擴展,用于DRI客戶端進行窗口系統和DDX驅動的協調[8,11].因此,在上文移植方案的基礎上需要做兩點改進:1)在gralloc.drm.so中區分App和SurfaceFlinger圖像緩存申請方式,App直接使用libdrm向內核GEM模塊申請,而Surface-Flinger使用DRI2擴展接口通過DDX驅動申請; 2)SurfaceFlinger進行畫面更新時不再直接使用DRM的pageflip接口,而使用DRI2擴展的緩存交換接口.這樣就不需要將SurfaceFlinger的圖像緩存拷貝到系統內存了,因此是一種完全支持硬件加速的架構.

5 性能測試

系統性能測試方法是運行一個以Surface為本地窗口的Android OpenGL ES圖形程序,測量其在一段時間內的平均幀率(FPS).同時測量該程序的CPU負載.采用San Angeles Observation作為基準測試軟件,后文簡稱Angeles.Angeles基于OpenGL ES1.0實現,每次運行約109秒,結束后會自動給出該時間內的總幀數和幀率.系統部署平臺選取了三臺GPU分別由Intel、Nvidia和AMD制造的PC.三臺PC均運行Linux Mint 17.3操作系統,并使用開啟了Binder驅動的版本號為4.2.6的Linux內核.各PC的關鍵硬件參數如表1所示.實驗方案是以800*480、1280*720 兩種分辨率大小的窗口,分別在各PC以優化前和優化兩種架構運行Angeles程序,并采集運行期間Surface-Flinger和Angeles的CPU占用情況.

表1 測試主機關鍵參數

從表2和表3可以看出,不論是在哪種分辨率下,優化前只有PC1的幀率能到達60FPS的速度,PC2和PC3的幀率均小于30FPS.幀率低于30FPS時人眼便能覺察到畫面的卡頓感.原因在于Intel集顯沒有獨立顯存,而是共享系統內存,因此每次將顯存拷貝是由系統內存的一個地址拷貝到另一個地址,該過程的速度很快,不會拖慢圖像更新頻率.而在PC2和PC3上,顯存的拷貝需要從GPU獨顯拷貝到系統內存,此過程耗時較長,拖慢了SurfaceFlinger的畫面更新速率.另一方面,觀察兩種分辨率下的優化前的PC2和PC3的幀率變化,發現分辨率越大,幀率越小,其原因在于分辨率越大,需要拷貝的顯存越大,拷貝時間越長.

表2 圖形性能測試結果(800*480)

表3 圖形性能測試結果(1280*720)

優化后,在800*480分辨率時,三臺PC均能達到60FPS幀率,畫面十分流暢.只有在1280*720時,PC2的幀率低于60FPS,其原因是PC2的GPU性能較弱.優化后的運行幀率和CPU負載均優于張超等人[2]的實驗結果.

從SurfaceFlinger(S)和Angeles(A)的CPU負載的變化情況分析,不論在哪種分辨率下,優化后相較于優化前,SurfaceFlinger的CPU負載降低且均低于2%,而Angeles的CPU負載升高.原因在于,優化前,Surface-Flinger的顯存拷貝過程需要占用大量CPU時間,拖慢了畫面更新速率.在BufferQueue另一端的Angeles程序需要等待SurfaceFlinger交出空閑的GraphicBuffer才能進行下一幀的渲染,CPU負責也較低.優化后,SurfaceFlinger的畫面更新時沒有了圖像緩存的拷貝過程,SurfaceFlinger本身不再是瓶頸,而Angeles在渲染完一幀畫面后可以立即從BufferQueue獲取一個空閑的GraphicBuffer.因此造成這種變化.

6 結語

使Android的圖形系統SurfaceFlinger能夠在桌面Linux發行版的X Window系統的環境下運行,是構建Android桌面運行環境的重要環節.本文給出了一種簡潔高效的移植方案.使用Mesa作為OpenGL ES實現,并借助gralloc.drm.so模塊,實現了Android應用程序的UI渲染過程和SurfaceFlinger的圖像合成過程能夠使用GPU進行硬件加速.同時,使用X11的DRI2擴展協調SurfaceFlinger的窗口和X Server的DDX驅動,實現了窗口畫面的快速更新,且避免了SurfaceFlinger圖像緩存由獨立顯存到系統內存的拷貝過程.經實驗,本移植方案能基于各型GPU進行硬件加速,圖形性能相較于已有方案有顯著提升.

1張超.面向桌面Linux的Android運行環境構建[碩士學位論文].長沙:國防科學技術大學,2012.

2張超,易曉東,戴華東.Android圖形系統向桌面Linux的移植.2012全國計算機體系結構學術年會論文集.西安,中國.2012.209–213.

3Inki Dae Software Platform Lab.DRM driver development for embedded systems.http://elinux.org/images/7/71/Elce11_dae.pdf.[2011].

4Android-x86-porting android to x86.http://www.androidx86.org/.

5The mesa 3D graphics library.http://www.mesa3d.org/.

6Direct rendering manager (DRM).https://dri.freedesktop.org/wiki/DRM.

7Packard K.Gem-the graphics execution manager.2008.https://lwn.net/Articles/283798/.

8Direct rendering infrastructure.https://en.wikipedia.org/wiki/Direct_Rendering_Infrastructure.

9Scheifler RW,Gettys J.The X Window system.ACM Trans.on Graphics,1986,5(2):79–109.

10Corbet J.MIT-SHM-the MIT shared memory extension.https://www.x.org/Releases/X11R7.7/doc/xextproto/shm.html.[1991].

11H?gsberg K.The DRI2 extension.https://www.x.org/releases/X11R7.7/doc/dri2proto/dri2proto.txt.[2008].

Method to Run SurfaceFlinger on X Window System

JIANG Fan,HE Ye-Ping,ZHOU Qi-Ming
(National Engineering Research Center of Fundamental Software,Institue of Sofware,Chinese Academy of Sciences,Beijing 100190,China)

This paper presents a method to transplant Android’s graphic system,SurfaceFlinger,to run on desktop Linux distribution’s X Window System.SurfaceFlinger running on X can make UI of the Android applications,running as native processes in the desktop Android runtime,show in a window of X.Using Mesa as the OpenGL ES implementation and making Mesa EGL compatible with Android’s native window,together with gralloc.drm.so module,the Android UI rendering process and SurfaceFlinger’s graphic compositing process can be implemented by using the GPU for hardware acceleration.In addition,using X11’s DRI2 extension to coordinate window of SurfaceFlinger with X Server’s DDX driver,can avoid graphic buffer coping from GPU’s dedicated memory to the system memory.In our experiment,the third-party 3D benchmark software San-Angeles can achieve 60FPS on variety GPUs.Compared with the existing method,the architecture of our method is more concise,efficient,and supportive of hardware acceleration.

Android graphic system; SurfaceFlinger; X Window system; transplant; compatibility environment

江帆,賀也平,周啟明.SurfaceFlinger在X Window系統環境下的運行方案.計算機系統應用,2017,26(10):95–101.http://www.c-sa.org.cn/1003-3254/6012.html

國家科技重大專項(2012ZX01039-004)

2017-01-17; 采用時間:2017-02-23