如果你和我一樣在一款自帶GPU的國產(chǎn)SoC上折騰OpenHarmony圖形棧大概率見過下面這幅場景系統(tǒng)窗口能刷出來光標(biāo)也在動(dòng)可只要一跑帶OpenGL ES的測試程序要么黑屏要么隔幾秒崩出滿屏EGL_BAD_ALLOC。去年我做Mesa3D移植第一版時(shí)就是這樣老render框架能點(diǎn)亮屏幕但整條鏈路里到處都是臨時(shí)判斷改一處壞一處。所以才有了這篇移植二也是這次真正想聊的render新框架一個(gè)在Mesa3D Gallium之上重新梳理的渲染后端目標(biāo)是把OpenHarmony的NativeWindow、BufferQueue和顯示合成鏈路真正串成一條可以擴(kuò)展的管線。這篇文章不重復(fù)第一版的基礎(chǔ)步驟只講新框架的模塊劃分、關(guān)鍵移植點(diǎn)以及我實(shí)測過程中踩到的坑。1. 重做之前的痛點(diǎn)舊render框架到底卡在哪1.1 第一版“能跑”和“好用”之間隔著一整條渲染鏈路第一版我為了快速驗(yàn)證實(shí)際是把Mesa的EGL初始化直接綁到了某個(gè)遠(yuǎn)程窗口模塊的全局單例上。聽起來挺省事Mesa初始化完就能通過opengles測試但問題在后期集中爆發(fā)系統(tǒng)有三塊顯示設(shè)備HDMI、MIPI屏、還有一層虛擬屏舊框架里EGLDisplay只有一個(gè)于是三個(gè)屏幕只能輪流搶同一個(gè)渲染target。另外OpenHarmony的資源管理器有自己一套生命周期它認(rèn)為buffer還掛在隊(duì)列里就應(yīng)該繼續(xù)顯示但Mesa那邊已經(jīng)把資源釋放了。結(jié)果就是開機(jī)一小時(shí)后突然花屏或者應(yīng)用退到后臺再回來時(shí)畫面上殘留上一幀的內(nèi)容。這些都是第一版完全沒考慮進(jìn)去的狀態(tài)同步問題。更麻煩的是線程。舊框架在設(shè)計(jì)時(shí)沒有把GL Context的創(chuàng)建和綁定的線程歸屬理順我不得不在應(yīng)用層加一個(gè)全局互斥量來串行化所有eglMakeCurrent調(diào)用。這相當(dāng)于讓GPU渲染退化成單線程。一旦某個(gè)app開了子線程做后臺加載主線程的渲染幀率就會(huì)劇烈抖動(dòng)。1.2 幀緩沖管理沒有一個(gè)清晰的資源歸屬舊框架里的framebuffer管理非?！耙啊敝苯影袽esa內(nèi)部生成的pipe_resource當(dāng)作成前端要的buffer來用再映射給顯示控制器掃描。這樣做的好處是代碼短壞處是資源所有權(quán)不明確。誰能改這個(gè)buffer誰能讀這個(gè)buffer什么時(shí)候改完在沒有Fence約束的情況下全靠運(yùn)氣。我實(shí)際遇到過的現(xiàn)象是vblank回調(diào)已經(jīng)觸發(fā)顯示控制器開始讀取這一幀但GPU這邊還在繪制同一個(gè)buffer于是一幀畫面里上半部分是新的、下半部分是撕裂的。舊框架我試著加過一版“檢測到繪制中就多等一個(gè)vblank”的邏輯結(jié)果因?yàn)椴慌袛嗬L制是否真結(jié)束只是盲目多等導(dǎo)致掉幀。真正的問題是缺乏明確的同步機(jī)制而不是等待時(shí)間不夠。1.3 從問題反推設(shè)計(jì)目標(biāo)把上面這些痛點(diǎn)列成表格之后新框架該做什么其實(shí)已經(jīng)很清楚問題根因新框架目標(biāo)EGLDisplay只能綁定一個(gè)屏幕單例設(shè)計(jì)沒有抽象顯示設(shè)備支持多Display每個(gè)Display獨(dú)立EGLSurface后臺線程導(dǎo)致幀率抖動(dòng)context綁定線程不清晰由框架統(tǒng)一管理context歸屬花屏、撕裂、殘留畫面資源生命周期不明確、缺少同步引入buffer所有權(quán)轉(zhuǎn)移與Fence同步改一處壞一處平臺適配代碼侵入Mesa內(nèi)部把平臺適配收斂到固定適配層所以這版我確定的核心原則只有一條絕不在Mesa源碼里到處打補(bǔ)丁所有硬件相關(guān)邏輯全部收口到一個(gè)薄適配層。這個(gè)決策直接決定了后面所有模塊的代碼結(jié)構(gòu)。2. render新框架的模塊劃分在Gallium之上加一個(gè)適配層2.1 所謂“新框架”本質(zhì)是給EGL和Gallium之間加一個(gè)中間層很多人一聽到“重寫render框架”就覺得要?jiǎng)覯esa的渲染核心其實(shí)恰恰相反。Mesa的Gallium架構(gòu)本身足夠穩(wěn)定狀態(tài)跟蹤器、編譯器、驅(qū)動(dòng)后端分得很清楚沒必要為了適配一個(gè)操作系統(tǒng)去改渲染引擎內(nèi)部。新框架真正改的是Mesa和OpenHarmony平臺之間的銜接方式。我這邊最后落地的模塊分成三塊Display管理模塊負(fù)責(zé)發(fā)現(xiàn)顯示設(shè)備、創(chuàng)建EGLDisplay、管理原生窗口和屏幕的映射關(guān)系。舊版是把一個(gè)全局對象到處傳新版則是注冊一張表每個(gè)物理屏幕對應(yīng)一個(gè)Display實(shí)例前端通過類似ohos_display_get_default的接口拿到句柄。Surface管理模塊負(fù)責(zé)把OpenHarmony的NativeWindow封裝成Mesa可識別的EGLSurface。這里包含buffer的申請、提交、釋放以及和BufferQueue的交互。前端的SurfaceView、XComponent最終都落到這個(gè)模塊里的一個(gè)window_surface結(jié)構(gòu)體。資源管理模塊負(fù)責(zé)buffer的導(dǎo)入導(dǎo)出、DMA-BUF的轉(zhuǎn)換、Fence同步。說白了就是讓GPU畫的幀能被顯示控制器安全地拿走去掃。這三個(gè)模塊統(tǒng)一收口在一個(gè)叫render_backend的接口里只有一組固定的創(chuàng)建、配置、提幀、釋放操作。內(nèi)部再根據(jù)底層GPU能力選擇軟渲染還是硬件驅(qū)動(dòng)前端完全無感。2.2 一次draw調(diào)用從應(yīng)用走到顯示器的完整路徑講代碼之前先過一次數(shù)據(jù)流不然看后面細(xì)節(jié)容易懵。我在新框架里理順后的完整鏈路是這樣的應(yīng)用調(diào)用eglGetDisplay框架根據(jù)設(shè)備節(jié)點(diǎn)返回一個(gè)Display實(shí)例。應(yīng)用調(diào)用eglCreateWindowSurface框架從NativeWindow里拿到一個(gè)空閑buffer交給Mesa作為drawbuffer。應(yīng)用執(zhí)行g(shù)lDrawElementsMesa的GL狀態(tài)跟蹤器把API調(diào)用翻譯成Gallium命令再由后端驅(qū)動(dòng)生成實(shí)際的GPU命令。GPU命令執(zhí)行完通過Fence通知框架“這幀可以拿去顯示了”。框架把buffer提交給OpenHarmony的BufferQueue顯示合成器拿到buffer后和UI層疊加最終送屏。這版框架最核心的變化在第三步和第四步之間。舊框架里GPU畫完后直接把buffer地址丟給顯示控制器新框架則引入了Fence機(jī)制確保顯示控制器讀取時(shí)GPU的寫入已經(jīng)完整落定。2.3 為什么保留Gallium而不是干脆自研一個(gè)小渲染器有人可能會(huì)問既然OpenHarmony本身有自己的render service為什么還要費(fèi)勁移植Mesa答案是應(yīng)用生態(tài)。OpenHarmony的富媒體應(yīng)用大量依賴OpenGL ES做特效、游戲、地圖渲染這些API的實(shí)現(xiàn)不是三天兩頭能重寫干凈的。而Mesa的Gallium架構(gòu)把著色器編譯、狀態(tài)管理、資源管理都做了很好的抽象我只需要讓平臺層符合它的接口預(yù)期。相比第一版那種“能用就行”的思路新框架等于在平臺和Mesa之間劃了一條明確的契約線。后續(xù)想換硬件驅(qū)動(dòng)、想支持Vulkan、想接更多buffer格式都只動(dòng)適配層不需要重新排查整條渲染鏈路。這是我做這次重構(gòu)最看重的東西。3. 移植過程中真正難啃的幾個(gè)硬骨頭3.1 給Mesa的EGL增加一個(gè)OHOS PlatformMesa本身有一套EGL平臺枚舉機(jī)制常見的像EGL_PLATFORM_X11、EGL_PLATFORM_WAYLAND、EGL_PLATFORM_DRM。OpenHarmony不在其中所以第一步是讓Mesa能識別OpenHarmony的native window類型。我參考了Android platform的做法在Mesa的egl源碼里增加了一個(gè)平臺入口讓eglGetPlatformDisplayEXT在檢測到EGL_PLATFORM_OHOS時(shí)走我們自己的初始化分支。這里有個(gè)關(guān)鍵坑OpenHarmony的NativeWindow結(jié)構(gòu)體和傳統(tǒng)X11/Wayland的window類型完全不同不能直接強(qiáng)轉(zhuǎn)。正確的做法是在適配層寫一個(gè)轉(zhuǎn)換函數(shù)把OHOS的OHNativeWindow指針封裝成結(jié)構(gòu)同時(shí)把窗口的寬高、格式、usage flag一起傳給Mesa的surface配置。當(dāng)時(shí)我卡了最久的地方是顏色格式。Mesa默認(rèn)expect的framebuffer格式經(jīng)常是XRGB8888而OpenHarmony的BufferQueue默認(rèn)給的是RGBA8888。這兩個(gè)在字節(jié)排列上看起來很像但alpha位的處理邏輯不一樣。如果不顯式設(shè)置EGL_ALPHA_SIZE就會(huì)出現(xiàn)半透明窗口背景下文字發(fā)虛的奇怪bug。3.2 DMA-BUF資源導(dǎo)入與緩存同步新框架里buffer在GPU和顯示控制器之間流轉(zhuǎn)靠的是DMA-BUF的fd傳遞。Mesa這邊有現(xiàn)成的resource_from_handle接口可以基于一個(gè)已有的fd創(chuàng)建pipe_resource這樣就不需要把GPU顯存內(nèi)容拷貝一份到系統(tǒng)內(nèi)存再拷回去。但這塊有一個(gè)必須注意的點(diǎn)不是所有fd都能直接拿去mmap。我遇到過MMU配置不對導(dǎo)致map出來的地址訪問直接段錯(cuò)誤后來排查發(fā)現(xiàn)是設(shè)備的dma地址范圍和CPU地址空間之間需要做偏移轉(zhuǎn)換。這個(gè)屬于平臺級問題Mesa本身不會(huì)幫你處理必須在buffer導(dǎo)入前把物理地址信息填對。緩存同步也是大坑。GPU用Cache寫數(shù)據(jù)CPU那邊直接讀的時(shí)候可能看到的是舊數(shù)據(jù)。我在調(diào)試一個(gè)紋理上傳慢的問題時(shí)發(fā)現(xiàn)每次用CPU往buffer里寫數(shù)據(jù)后GPU那邊拿到的總是上一次的內(nèi)容。后來在提交緩沖前增加了cache clean操作在GPU訪問前增加cache invalidate操作才把問題解決。這些東西在PC上一般由驅(qū)動(dòng)自動(dòng)處理但在這種嵌入式移植場景里往往要顯式調(diào)平臺接口。3.3 線程模型與Context切換新框架把GL Context的管理收口后線程問題就從應(yīng)用層轉(zhuǎn)移到了框架層框架必須自己保證并發(fā)安全。我最后采用的方案是“Display級別的鎖”同一個(gè)Display下eglMakeCurrent切換context時(shí)加鎖但不同Display之間互不影響。這樣主線程和渲染線程可以同時(shí)跑在不同Display上不會(huì)互相卡死。另一個(gè)細(xì)節(jié)是eglDestroyContext的時(shí)機(jī)。某些驅(qū)動(dòng)在context銷毀時(shí)還會(huì)嘗試訪問它綁定過的surface如果surface已經(jīng)提前釋放就會(huì)觸發(fā)use-after-free。我在框架里規(guī)定銷毀context前必須先解除它和surface的綁定關(guān)系并等待正在執(zhí)行的GPU命令完成再回收內(nèi)存。這個(gè)順序錯(cuò)一步就容易在退出應(yīng)用時(shí)偶發(fā)崩潰。4. 顯示鏈路改造讓合成器正常消費(fèi)GPU的產(chǎn)出4.1 從BufferQueue到HWC的buffer所有權(quán)交接在OpenHarmony的顯示架構(gòu)里應(yīng)用拿到的buffer來自BufferQueue最終展示則要交給HWC合成。Mesa渲染完的buffer不能直接推給屏幕必須把所有權(quán)沿著“應(yīng)用 - BufferQueue - 合成器”的順序依次移交。新框架實(shí)現(xiàn)這套交接依賴一個(gè)buffer_release回調(diào)。當(dāng)BufferQueue認(rèn)為buffer已經(jīng)被合成器讀取后會(huì)回調(diào)框架層框架再把這個(gè)buffer歸還給Mesa的資源池供下一次渲染復(fù)用。如果這個(gè)回調(diào)時(shí)機(jī)不對要么buffer被過早回收合成器讀了一半被覆蓋要么buffer一直不歸還應(yīng)用申請不到新buffer開始卡頓。我在調(diào)試時(shí)觀察過一個(gè)詭異現(xiàn)象只有連續(xù)滑動(dòng)桌面時(shí)才卡停下來就正常。后來抓log發(fā)現(xiàn)是合成器持有了兩個(gè)buffer還沒釋放應(yīng)用側(cè)的緩沖池已經(jīng)見底。調(diào)整成三緩沖并增加超時(shí)回收后才算穩(wěn)定。4.2 像素格式和plane對齊顯示控制器對buffer有幾個(gè)硬性要求內(nèi)存對齊、像素格式匹配、掃描線地址按行對齊。這些在PC上通常由驅(qū)動(dòng)繞過了但OpenHarmony的HWC會(huì)直接檢查。我移植的顯示核心雖然支持常見的RGBA8888和RGB888但有一個(gè)tiled模式的問題。GPU那邊默認(rèn)生成tiled布局提升紋理效率但顯示控制器只認(rèn)linear布局。舊框架里我直接讓GPU用linear模式性能損失明顯。新框架的做法是開啟GPU的寫壓縮/轉(zhuǎn)置引擎在buffer提交前做一次硬件格式轉(zhuǎn)換讓GPU保持高效率的排列顯示側(cè)也能讀到正確的linear數(shù)據(jù)。這個(gè)代價(jià)是增加了大約一毫秒的轉(zhuǎn)換時(shí)間相比讓GPU全程跑linear帶來的帶寬損失值很多。4.3 三緩沖下的幀間隔和Fence策略O(shè)penHarmony默認(rèn)傾向三緩沖來減少jank但三緩沖如果配合Fence策略不當(dāng)反而會(huì)增加延遲。我試過兩種方案第一種是渲染完立即釋放不等合成器讀第二種是等Fence信號后再釋放。第一種在負(fù)載低時(shí)流暢高負(fù)載時(shí)花屏第二種在高負(fù)載時(shí)穩(wěn)定但延遲多一到兩幀。最終我做的決定是動(dòng)態(tài)判斷當(dāng)BufferQueue里可用buffer少于2個(gè)時(shí)強(qiáng)制開啟Fence等待可用buffer充足時(shí)走快速路徑。實(shí)測下來在高負(fù)載場景下花屏消失普通場景延遲沒有明顯惡化。5. 驗(yàn)證與調(diào)優(yōu)從能出圖到穩(wěn)定跑分5.1 dEQP測試結(jié)果出來的那一晚渲染框架重構(gòu)完第一件事不是跑性能而是驗(yàn)證正確性。我用了Khronos的dEQP工具集分別跑GLES2、GLES3的核心測試組。第一輪結(jié)果非常慘大量shader compile失敗的case幾乎全是精度修飾符和循環(huán)展開相關(guān)的差異。仔細(xì)排查后發(fā)現(xiàn)不是Mesa的問題而是我在EGL配置里把EGL_CONTEXT_MAJOR_VERSION設(shè)置錯(cuò)了導(dǎo)致app請求到的是軟件兼容profile而不是完整GLES3上下文。修正之后GLES2的通過率從40%跳到接近100%GLES3也有99.4%左右剩下個(gè)別case是紋理壓縮格式擴(kuò)展沒接全。還有一個(gè)必須提的驗(yàn)證環(huán)節(jié)是壓力測試。dEQP跑的是單幀正確性不管長時(shí)間運(yùn)行的穩(wěn)定性。我額外寫了腳本循環(huán)跑圖形demo兩小時(shí)同時(shí)反復(fù)切換前后臺、開關(guān)屏幕確認(rèn)沒有buffer泄漏和Fence死鎖。5.2 軟渲染和硬件加速的性能差異這套平臺目前適配的是內(nèi)置GPU所以硬件路徑為主。但調(diào)試初期Mesa驅(qū)動(dòng)還沒完全工作我先用llvmpipe軟渲染驗(yàn)證框架邏輯那時(shí)候性能很能說明問題。llvmpipe在OpenHarmony這種輕量系統(tǒng)上幀率大致能到30到40幀但對內(nèi)存帶寬非常敏感。新框架dma-buf共享繞過了很多拷貝軟渲染性能比第一版反而提升了。這也印證了我之前說的很多時(shí)候瓶頸不在GPU計(jì)算而在于buffer搬運(yùn)。硬件加速跑起來后我用一個(gè)標(biāo)準(zhǔn)UI交互場景和GPU benchmark分別測試。差異最明顯的是1080p全屏天氣動(dòng)效場景軟渲染在復(fù)雜模糊shader下掉到個(gè)位數(shù)硬件加速能穩(wěn)定在50幀以上。這說明針對該GPU所做的內(nèi)存布局轉(zhuǎn)換和命令提交優(yōu)化是有效果的。5.3 黑屏、花屏問題的定位套路新框架上線后我總結(jié)出一套黑屏花屏的排查順序基本上是看EGL_BAD_ALLOC是否出現(xiàn)在buffer申請階段如果是優(yōu)先查usage flag和format組合是否被allocator拒絕?？达@示控制器是否報(bào)“pixel format not supported”如果是重點(diǎn)查提交前的格式轉(zhuǎn)換有沒有生效。看Fence回調(diào)是否遲遲不觸發(fā)如果是多半是DMA-BUF sync對象沒有綁定正確的fd。如果以上都正常查buffer地址對齊特別是stride大于width時(shí)的行對齊問題。這套順序幫我節(jié)省了大量時(shí)間。大多數(shù)黑屏不是渲染完全沒輸出而是某一環(huán)的格式或尺寸信息傳錯(cuò)了顯示控制器根本沒把buffer當(dāng)作有效輸入。6. 回頭看除了代碼幾個(gè)值得說說的選擇6.1 選穩(wěn)定的Mesa分支而不是追最新Mesa的master分支變化很快特別是在vulkan和新的gallium驅(qū)動(dòng)上。我在項(xiàng)目中期換過一次新分支結(jié)果EGL平臺接口內(nèi)部結(jié)構(gòu)調(diào)整導(dǎo)致我寫的適配代碼大面積需要重改。后來固定在某個(gè)長期穩(wěn)定版本上只做小版本跟進(jìn)。奉勸做嵌入式移植的朋友除非需要新特性否則別追主線穩(wěn)定分支能少掉一半頭發(fā)。6.2 “新框架”不是造輪子而是把邊界劃清楚一開始我也有點(diǎn)抵觸重寫畢竟第一版能跑誰愿意動(dòng)它。但實(shí)踐下來的體會(huì)是所謂render新框架真正帶來的價(jià)值不是新的渲染算法而是把“誰負(fù)責(zé)分配、誰負(fù)責(zé)渲染、誰負(fù)責(zé)顯示”這條責(zé)任鏈劃清了。Mesa內(nèi)部的功能依然沿用原樣OpenHarmony側(cè)的資源管理模式也基本沒動(dòng)我只在中間補(bǔ)了一層防腐邏輯結(jié)果所有以前“改了這里壞了那邊”的毛病都消失了。6.3 后續(xù)可以怎么擴(kuò)展這套框架跑通OpenGL ES之后后續(xù)最自然的擴(kuò)展是支持Vulkan。Mesa本身就帶Vulkan的驅(qū)動(dòng)支持如果再配一個(gè)Vulkan ICD加載器很多游戲應(yīng)用可以直接受益。另一個(gè)可做的方向是擴(kuò)展buffer格式比如支持10bit HDR的RGB10A2適配高端視頻播放場景?？蚣軐用嫖乙呀?jīng)預(yù)留了format清單的注冊入口增加新格式不再需要改代碼邏輯。最后分享一個(gè)實(shí)戰(zhàn)建議拿到一塊新板子別上來就跑dEQP或者游戲demo先用一個(gè)簡單的全屏色塊程序驗(yàn)證buffer從GPU到顯示器的全鏈路。只要色塊顏色正確、切換流暢說明最底層的傳輸沒壞后面的功能再逐個(gè)加。渲染棧的問題絕大多數(shù)是資源和時(shí)序問題不是數(shù)學(xué)問題。把這兩樣理順了Mesa3D移植基本就成功了一大半。