記得很多年前第一次把 OpenGL ES 程序跑在 ARM Linux 開發(fā)板上時卡在的不是shader寫錯了而是程序一啟動就報錯找不到libmali.so。那時還沒有現(xiàn)在這么多現(xiàn)成工具鏈我折騰了一整天才弄明白所謂“ARM Mali GPU links”主要就是三條線交叉編譯鏈怎么選、GPU 用戶態(tài)驅(qū)動庫怎么鏈接、運(yùn)行時怎么把libmali加載進(jìn)進(jìn)程。搞清楚這三條線你在 RK3399、RK3568、樹莓派或者飛騰平臺上調(diào) Mali 顯卡基本就是順?biāo)浦鄣氖?。這篇內(nèi)容我按自己實際踩坑的順序整理先講整體思路和工具鏈選型再講編譯鏈接時的具體操作接著講運(yùn)行時動態(tài)庫加載最后是問題排查速查表。內(nèi)容適合剛把 SDL/EGL/OpenGL ES 項目往 ARM 板上移植的開發(fā)者也適合想搞明白 “export LD_LIBRARY_PATH/usr/lib/aarch64-linux-gnu/mali”這行命令到底干了啥的運(yùn)維和 AI 部署工程師。1. 整體設(shè)計思路Mali 平臺上的“鏈接”到底在鏈接什么1.1 鏈接的本質(zhì)是讓 GPU 用戶態(tài)驅(qū)動與你的應(yīng)用“對上話”ARM Mali 的 GPU 架構(gòu)里有一個非常明確的分工內(nèi)核側(cè)有 kbase/mali 驅(qū)動用戶態(tài)側(cè)有 libmali.so。你的應(yīng)用程序不管是 EGLC 客戶端、Wayland compositor還是直接掉 OpenGL ES 的圖形程序在調(diào) EGL/GLES API 時實際是調(diào)用libmali.so里的入口再由這個庫通過 ioctl 把命令提交給內(nèi)核驅(qū)動。整個過程里“l(fā)inks”這個詞體現(xiàn)在兩個層面第一層是編譯和靜態(tài)鏈接。你的應(yīng)用要能解析到eglCreateContext、glBufferData這類符號。在 PC 上NVIDIA 幫你把 libGL.so 塞進(jìn)了系統(tǒng)目錄但 ARM 嵌入式環(huán)境往往要你手動指-L和-l。這一層出錯通常發(fā)生在 cmake 交叉編譯時找不到庫文件或者鏈接時出現(xiàn)“undefined reference to eglCreateContext”。第二層是運(yùn)行時動態(tài)加載。當(dāng)你敲下./my_gpu_app后動態(tài)鏈接器要能按編譯時記錄的 SONAME 找到libmali.so以及它的依賴。如果你的板子鏡像預(yù)裝的庫路徑不是標(biāo)準(zhǔn)/usr/lib或者你手動把不同版本的 mali 庫扔到倉庫目錄就需要通過LD_LIBRARY_PATH或 ldconfig 告訴動態(tài)鏈接器。這一層出錯就是經(jīng)典的error while loading shared libraries: libmali.so: cannot open shared object file: No such file or directory。我自己的實踐里這兩層問題往往同時出現(xiàn)編譯鏈配好了運(yùn)行又掛。所以你在做平臺移植時不妨先停下來把整個鏈接過程拆開審視一遍不要一上來就去調(diào) shader。1.2 交叉編譯鏈選型為什么別一上來就去翻 ARM Compiler 5.06熱搜詞里反復(fù)出現(xiàn) “arm compiler 5.06u7 下載”“arm compiler 5”我想提醒一下ARM Compiler 5.06RVCT 風(fēng)格確實是老嵌入式項目里的老朋友很多裸機(jī) SoC SDK 和早期 Mali 驅(qū)動包都是用它編譯的。但對于跑 Linux 的 Mali GPU 項目我建議你優(yōu)先用Linaro GCC而不是 ARM Compiler 5.06。原因是這幾點一linaro gcc 是開源的版本迭代快對 C11/14 和 OpenMP 支持好而 ARMCC 5.x 早就停止功能更新了二Mali 用戶態(tài)驅(qū)動廠商比如 Rockchip 的 BSP一般提供的是已經(jīng)針對 GCC 編好的.so你用 ARMCC 編應(yīng)用運(yùn)行時是去調(diào) GCC 編的動態(tài)庫ABI 層面雖然大體兼容都是 EABI但遇到 C 異常處理、STL 符號版本這類問題調(diào)試成本會非常高三也是最實際的ARM Compiler 5.06 在老機(jī)器上還得配許可證折騰 License 的時間夠你編譯十遍內(nèi)核了。只有一種情況我會考慮 ARM Compiler 5.06項目里同時要編裸機(jī)固件比如 Mali 相關(guān)的安全固件或獨立的 GPU 微控制器程序且 SDK 強(qiáng)制要求 RVCT。這種情境下你可以繞過系統(tǒng) GCC單獨用 ARMCC 編出獨立的裸機(jī)鏡像但在 Linux 應(yīng)用側(cè)還是老實用 GCC/Linaro 的交叉編譯鏈。所以我這里給出一個非常直接的建議交叉編譯工具鏈選aarch64-linux-gnu-gcc版本不低于 9如果你需要 OpenMP確認(rèn)工具鏈里包含libgomp。如果你用的是 Rockchip Linux SDK里面自帶的交叉編譯鏈就是 prebuilt 的 linaro gcc直接export PATH$PATH:/opt/your_sdk/prebuilts/gcc/linux-x86/aarch64/gcc-linaro-6.3.1-2017.05-x86_64_aarch64-linux-gnu/bin即可。不要混用 kernel 編譯鏈和用戶態(tài)編譯鏈。Kernel module 和用戶態(tài)程序最好用同一套鏈避免 glibc 版本和符號版本差異帶來的問題。1.3 搞清楚你的 libmali 是哪種“馬甲”鏈接才不會錯Mali 的“馬甲”多到讓人頭大同一個 Rockchip BSP 里目錄下可能同時躺著libmali-midgard.so、libmali-bifrost.so、libmali-valhall.so或者帶-r32p0、-g2p0這類版本號尾巴的庫。我剛開始接觸時老是搞混以為隨便復(fù)制一個就行結(jié)果程序起來后 EGL 調(diào)用直接返回EGL_BAD_ALLOC。簡單說Mali 驅(qū)動跟 GPU 硬件代際強(qiáng)相關(guān)。你能在 SoC 數(shù)據(jù)手冊或內(nèi)核設(shè)備樹里看到 GPU 的型號比如 “Mali-T860”就是 Midgard 代對應(yīng)libmali-midgard.so“Mali-G52” 是 Bifrost 代對應(yīng)libmali-bifrost.soG78/G710 這類就是 Valhall 代。不同代際的 libmali 之間絕對不能混用。它們在 EGL 擴(kuò)展、內(nèi)存分配、job slot 提交方式上差異非常大。鏈接中我的操作方法是先看設(shè)備樹或內(nèi)核日志確認(rèn) GPU 具體型號再在板子的/usr/lib/aarch64-linux-gnu/mali/或/usr/lib/arm-linux-gnueabihf/mali/里確認(rèn)有哪些庫文件然后用readelf -d libmali.so | grep SONAME查看它的 SONAME 到底是什么——這非常關(guān)鍵因為運(yùn)行時是按 SONAME 找?guī)斓娜绻愕?app 編譯時鏈接-lmali但 SONAME 卻是libmali.so.1編譯過了運(yùn)行卻會去找libmali.so.1而你系統(tǒng)里沒有這個文件名程序就起來不來。順帶一提像 Luckfox Pico、愛芯派這類小的 ARM 板Mali 的用戶態(tài)驅(qū)動可能沒有原始廠商的版本更新快你有時需要從官方 BSP 的 release notes 里找對應(yīng)的“version string”而不是只看文件名。這個細(xì)節(jié)在我初期的項目里浪費(fèi)過好多時間。2. 編譯鏈接實操CMake 交叉編譯項目里Mali GPU 鏈接的五步配置2.1 首先讓 CMake 認(rèn)識你的 ARM 工具鏈寫 Mali 項目的人基本繞不開 CMake因為它對交叉編譯的支持做得相當(dāng)順手。你可以先建一個arm-linux-toolchain.cmake核心內(nèi)容如下set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR aarch64) set(TOOLCHAIN_PREFIX aarch64-linux-gnu-) set(CMAKE_C_COMPILER ${TOOLCHAIN_PREFIX}gcc) set(CMAKE_CXX_COMPILER ${TOOLCHAIN_PREFIX}g) set(CMAKE_FIND_ROOT_PATH /usr/aarch64-linux-gnu) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)這里最容易被忽略的是CMAKE_FIND_ROOT_PATH。它告訴 CMake找?guī)旌皖^文件時只在/usr/aarch64-linux-gnu下找不要跑去 x86 宿主機(jī)的/usr/lib。如果你不設(shè)置這個CMake 可能會在宿主機(jī)上找 libGL、libEGL鏈接出一堆 x86 格式的庫放板子上直接段錯誤。我早期就犯過這個錯連 vc4 simulator 的庫都差點被拉進(jìn)來。CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER的意思是找可執(zhí)行程序比如 pkg-config時仍用宿主機(jī)的因為那是 x86 可執(zhí)行的工具用來生成編譯參數(shù)但庫和頭文件只能從目標(biāo)系統(tǒng)目錄里找。2.2 手把手配置 EGL/GLES 頭文件和庫路徑假設(shè)你拿到了 Rockchip 提供的libmali頭文件一般在/usr/include/EGL、/usr/include/GLES2、/usr/include/GLES3這幾個目錄下。在 CMakeLists 里這么寫set(MALI_INCLUDE_DIR /usr/aarch64-linux-gnu/include) set(MALI_LIB_DIR /usr/aarch64-linux-gnu/lib) include_directories( ${MALI_INCLUDE_DIR} ${MALI_INCLUDE_DIR}/EGL ${MALI_INCLUDE_DIR}/GLES2 ${MALI_INCLUDE_DIR}/GLES3 ) link_directories(${MALI_LIB_DIR})然后添加可執(zhí)行文件并鏈接add_executable(mali_demo main.cpp) target_link_libraries(mali_demo mali # 對應(yīng) libmali.so EGL GLESv2 pthread dl m )我習(xí)慣把libmali.so通過-l:libmali.so這種形式來鏈接防止名字匹配錯。你在 target_link_libraries 里寫mali鏈接器會找libmali.so或libmali.a如果這個庫 SONAME 不匹配鏈接也能成功但運(yùn)行時就有問題。為保險推薦直接寫全路徑target_link_libraries(mali_demo ${MALI_LIB_DIR}/libmali-bifrost-g52.so EGL GLESv2 pthread dl m )這樣寫還有個好處你一眼就能告訴自己板上跑的是 Bifrost G52 的 mali 庫而不是 Midgard 的。項目維護(hù)起來幾個月后回看 CMakeLists 都能想起當(dāng)時的硬件平臺。2.3 鏈接選項里必須注意的“隱藏符號”問題Mali 的 libmali.so 是個“大雜燴”有些版本會同時導(dǎo)出 EGL、GLESv1、GLESv2、OpenVG 的符號。如果你在鏈接時用了--as-needed并且鏈接順序不對鏈接器可能把libmali.so整個丟棄導(dǎo)致最后可執(zhí)行文件里沒有任何 EGL 符號。運(yùn)行時就會報undefined symbol: eglGetDisplay。我通常在 CMake 的 CMAKE_EXE_LINKER_FLAGS 里加入以下內(nèi)容set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} -Wl,--no-as-needed)這樣強(qiáng)制所有顯式列出的庫都參與鏈接。在 Ubuntu/Debian 系的交叉編譯環(huán)境里尤其要注意這一點因為系統(tǒng) GCC 默認(rèn)的--as-needed行為會比你在 x86 電腦上遇到的問題更隱蔽程序編譯通過、卻半天跑不起來。如果你是手工寫gcc命令而不是用 CMake那我給你一個標(biāo)準(zhǔn)命令行模板aarch64-linux-gnu-g main.cpp -o mali_demo \ -I/usr/aarch64-linux-gnu/include \ -L/usr/aarch64-linux-gnu/lib \ -l:libmali-bifrost-g52.so -lEGL -lGLESv2 -lpthread -ldl -lm \ -Wl,--no-as-needed執(zhí)行完以后用aarch64-linux-gnu-readelf -d mali_demo | grep NEEDED檢查一下看看 NEEDED 列表里的庫名是不是預(yù)期的名稱——這一步真的很快能省去后面大量調(diào)試時間。2.4 JIT shader 編譯與特定工具鏈約束Mali GPU 驅(qū)動有“JIT 編譯”機(jī)制shader 編譯發(fā)生在運(yùn)行時而不是預(yù)先編譯雖然也有 offline blob 的方式比如malisc但多數(shù)項目還是運(yùn)行時編譯。這意味著你的進(jìn)程在運(yùn)行時要能夠分配可執(zhí)行內(nèi)存頁所以我們通常要鏈接dl并且確保/dev/mali設(shè)備節(jié)點的權(quán)限允許當(dāng)前用戶訪問。另外如果你的程序用到了 OpenGL ES 3.1 的計算著色器compute shader記得要在編譯時加-stdc11以上并且確保你鏈接的 libmali 支持這個擴(kuò)展版本。有些老版本 BSP 里的 libmali 只到 GLES3.0運(yùn)行時會返回GL_INVALID_OPERATION或干脆造成 GPU 崩潰gpu crash dump triggered。如果你是從桌面 OpenGL 轉(zhuǎn)到 Mali心里要有個預(yù)期Mali 對 GL 版本的支撐就是“能用但別挑戰(zhàn)極限”你最好把目標(biāo)定為 GLES3.1 或 GLES3.2而不是去想 4.x core profile。這樣鏈接和運(yùn)行時的問題都會少一大截。2.5 靜態(tài)鏈接還是動態(tài)鏈接別迷信“靜態(tài)更省事”有些朋友為了部署省事把 libmali 直接靜態(tài)鏈接進(jìn)主程序。我不建議這么做原因是一Mali 庫包含對內(nèi)核接口的依賴內(nèi)核驅(qū)動版本升級后舊靜態(tài)庫可能和新內(nèi)核不兼容而你沒法通過替換一個.so來解決二Mali 生態(tài)里很多輔助庫比如 OpenCL 的libOpenCL.so本來就不是純靜態(tài)發(fā)布的三如果你的 SDK 里有多個 GPU 相關(guān)程序動態(tài)鏈接可以共享一份用戶態(tài)驅(qū)動內(nèi)存對整個系統(tǒng)資源占用更友好。所以我推薦的策略是動態(tài)鏈接 在部署腳本里顯式復(fù)制庫 為依賴設(shè)置 RPATH。當(dāng)然有些 BSP 的 libmali 是用某些舊 GCC 版本編的動態(tài)加載時可能會報缺少 GLIBC 某個版本符號。這時候如果你不想重新編譯頂層依賴就得在板子上用符號鏈接偽造一個 GLIBC 版本但這非常危險不如檢查自己的工具鏈版本和板子 stub 庫的一致性。3. 運(yùn)行時動態(tài)庫加載LD_LIBRARY_PATH 與 ldconfig 的決策細(xì)節(jié)3.1 那行“export LD_LIBRARY_PATH...”命令到底在干嘛你搜到的熱詞里有一個典型的命令export LD_LIBRARY_PATH/usr/lib/aarch64-linux-gnu/mali:$LD_LIBRARY_PATH這行命令的核心作用是在動態(tài)鏈接器的搜索路徑優(yōu)先級里把/usr/lib/aarch64-linux-gnu/mali放到繼承的路徑之前。動態(tài)鏈接器通常是ld-linux-aarch64.so.1加載程序時會按以下順序查找共享庫DT_RPATH如果存在且 DT_RUNPATH 未設(shè)置LD_LIBRARY_PATH 環(huán)境變量可執(zhí)行文件的 DT_RUNPATH緩存文件/etc/ld.so.cache默認(rèn)目錄/lib、/usr/lib等如果你板子上/usr/lib/aarch64-linux-gnu/里本身也有一個libEGL.so而 mali 目錄里有另一個那么加了LD_LIBRARY_PATH后E GL 調(diào)用就會優(yōu)先命中 Mali 目錄下的版本。這在 Rockchip 和全志的許多 Debian 鏡像里非常關(guān)鍵因為它們系統(tǒng)自帶的libEGL.so可能指向 panfrost 或 llvmpipe軟件渲染唯獨 mali 目錄里的才是硬件 GPU 驅(qū)動。我用個生活類比LD_LIBRARY_PATH就像給外賣配送員提前畫了一條“優(yōu)先送達(dá)路線”只要這條路線上的商家?guī)齑嬖谒筒粫@遠(yuǎn)路去系統(tǒng)默認(rèn)市場取貨。但如果那條路線上的商家還沒開業(yè)文件不存在或權(quán)限不對外賣小哥還是會退回默認(rèn)路線而這一“退回”行為程序往往不會給你明確提示。3.2 驗證你的 .so 實際被哪個路徑加載如果你懷疑程序加載了錯誤的庫版本最實際的驗證方式有兩個。第一個用ldd檢查動態(tài)庫依賴。注意交叉編譯環(huán)境下的 ldd 不能直接跑目標(biāo)板程序但你可以用aarch64-linux-gnu-readelf -d來看也可以把程序拷貝到板子上在板子上跑ldd。板子的命令rootboard:~# ldd ./mali_demo linux-vdso.so.1 (0x0000ffff8f7f0000) libmali-bifrost-g52.so /usr/lib/aarch64-linux-gnu/mali/libmali-bifrost-g52.so (0x0000ffff8f5f0000) libEGL.so.1 /usr/lib/aarch64-linux-gnu/mali/libEGL.so.1 (0x0000ffff8f5e0000) libGLESv2.so.2 /usr/lib/aarch64-linux-gnu/mali/libGLESv2.so.2 (0x0000ffff8f5d0000) libpthread.so.0 /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000ffff8f5b0000) libdl.so.2 /lib/aarch64-linux-gnu/libdl.so.2 (0x0000ffff8f5a0000) ...如果這里顯示的是/usr/lib/aarch64-linux-gnu/libGLESv2.so.2而不是 mali 目錄說明 LD_LIBRARY_PATH 沒配置成功或者該路徑下沒有對應(yīng)文件。第二個是在程序里打印實際加載路徑。用dladdr或直接打印dlopen句柄的路徑這在調(diào)試時特別有用。我在一個合成器項目里加過如下代碼#include dlfcn.h #include cstdio int main() { void* handle dlopen(libEGL.so.1, RTLD_NOW); if (!handle) { fprintf(stderr, dlopen failed: %s\n, dlerror()); return 1; } Dl_info info; if (dladdr(dlsym(handle, eglGetDisplay), info)) { printf(EGL implementation: %s\n, info.dli_fname); } dlclose(handle); return 0; }實測下來這個方法比看 ldd 輸出更直接因為有的庫是通過 dlopen 動態(tài)打開而不是直接編譯鏈接的在 ldd 里根本看不到。3.3 更持久的配置/etc/ld.so.conf.d/mali.confLD_LIBRARY_PATH是臨時的、只對當(dāng)前 shell 進(jìn)程樹有效的方案。如果你希望程序開機(jī)就能用或者通過 systemd 服務(wù)啟動的程序也能自動找到 Mali 庫我更推薦在板子上創(chuàng)建一個配置echo /usr/lib/aarch64-linux-gnu/mali /etc/ld.so.conf.d/mali.conf ldconfig這樣動態(tài)鏈接器在讀取/etc/ld.so.cache時就會把 mali 目錄下的庫都索引好后續(xù)任何程序直接libEGL.so.1都能命中。這個做法的核心好處是“全局生效”缺點是如果你板子上同時存在多個 GPU 用戶態(tài)庫比如 mali 和 panfrostldconfig的索引順序可能不按你的預(yù)期來。這時候你可以用ldconfig -p | grep mali查看緩存列表確認(rèn)優(yōu)先級。如果發(fā)現(xiàn) panfrost 搶了先可以用/etc/ld.so.preload但一般不建議或者把不需要的庫重命名/移出目錄來確保命中目標(biāo)庫。我在 RK3588 的板子上就遇到過類似問題系統(tǒng)自帶的 gdm/wayland 合成器需要 Mali 庫但它以 systemd user 服務(wù)方式運(yùn)行LD_LIBRARY_PATH不會傳入該用戶的登錄 shell。后來我用ld.so.conf.d方案一次性解決穩(wěn)定跑了幾個月。3.4 RPATH 別亂設(shè)但也不能完全不設(shè)編譯時設(shè)置 RPATH可以在可執(zhí)行文件內(nèi)部記錄庫搜索路徑效果類似aarch64-linux-gnu-g main.cpp -o mali_demo \ -Wl,-rpath,/usr/lib/aarch64-linux-gnu/mali \ -L/usr/lib/aarch64-linux-gnu/mali -l:libmali-bifrost-g52.soRPATH 的坑在于如果目錄里缺失某個運(yùn)行時依賴程序報錯信息會很隱晦且當(dāng)你把整個目錄結(jié)構(gòu)移動到另一臺機(jī)器上時RPATH 里寫死的絕對路徑會導(dǎo)致庫找不到。更推薦用$ORIGIN風(fēng)格-Wl,-rpath,$ORIGIN/libs這表示可執(zhí)行文件同目錄下的libs子目錄。把 libmali 系列庫復(fù)制到應(yīng)用的libs目錄整個程序就是“自包含”的很適合嵌入式應(yīng)用發(fā)布。需要注意的是動態(tài)鏈接器只有在可執(zhí)行文件設(shè)置了 DT_RUNPATH 而不是 DT_RPATH 時才會讓LD_LIBRARY_PATH優(yōu)先于 RPATH如果你想要 RPATH 最高優(yōu)先級甚至高于 LD_LIBRARY_PATH必須使用 DT_RPATH 格式但大多數(shù)現(xiàn)代系統(tǒng)默認(rèn)會轉(zhuǎn)成 DT_RUNPATH。這塊兒細(xì)節(jié)很多我的建議是能用LD_LIBRARY_PATH或ld.so.conf.d解決的就別折騰 RPATH只有在需要“單目錄分發(fā)”時才用$ORIGIN。4. 交叉編譯中的典型問題與排查技巧4.1 程序咔一下退出了還報 gpu crash dump triggeredMali 驅(qū)動的日志里出現(xiàn)gpu crash dump triggered是最讓人頭大的錯誤之一。我在一個 RK3399 平臺上跑自己寫的延遲渲染 demo 時切換 framebuffer 分辨率后必現(xiàn)崩潰。經(jīng)過抓取/sys/kernel/debug/mali的 dump 才發(fā)現(xiàn)問題出在我在程序里用glBufferData頻繁分配了一個超大 vertex buffer而庫版本沒有開啟 GPU 內(nèi)存的 CMA 預(yù)分配導(dǎo)致物理內(nèi)存碎片化驅(qū)動無法分配連續(xù) pages最終 GPU job 超時崩潰。這個問題的排查方向我建議從這三個點入手用戶的 app 是否用到了 Mali 不擅長的“長渲染指令”或“非常規(guī) framebuffer 維度”。系統(tǒng)內(nèi)存是否不足。Mali 和 CPU 共用內(nèi)存GPU 內(nèi)存分配失敗不比 CPU OOM 溫和。內(nèi)核驅(qū)動和用戶態(tài) libmali 版本是否一致。版本不匹配是這類崩潰的頭號原因。調(diào)試時建議先在內(nèi)核啟動參數(shù)里加上mali_debug_force_panic或打開/sys/kernel/debug/mali的 debug 節(jié)點讓它輸出更詳細(xì)的 job 狀態(tài)。工業(yè)級做法是寫一個長時間運(yùn)行的 stress 腳本不斷地創(chuàng)建銷毀 EGL Context同時用dmesg監(jiān)控mali內(nèi)核日志一旦崩了就把完整調(diào)用鏈抓出來。我后來定位到崩潰的根因是我在 GLES 主線程里同時跑了一個 CPU 線程讀回glReadPixels而 Mali 的同步對象處理在這種情況下有比較高的開銷導(dǎo)致 CPU 線程頻繁觸發(fā) job slot 搶占。為了解決它我在隊列提交前用了glFinish()而非glFlush()并把讀寫分離到不同 FBO。問題隨之消失。4.2 為什么我鏈接了 libmali還是報 undefined reference to eglCreateContext這問題通常不是你沒鏈接而是頭文件和庫不配套。舉例頭文件來自 Mesa 的主機(jī)開發(fā)包里面聲明了 EGL 1.5 的所有函數(shù)而你板子上的 libmali 可能只實現(xiàn)了 EGL 1.4。鏈接時的 undefined reference 倒不一定出現(xiàn)更常見的是運(yùn)行時報EGL_BAD_DISPLAY或EGL_BAD_ALLOC。如果你看到的真的是鏈接錯誤為undefined reference to eglCreateContext則一般有下面幾種情況你鏈接的庫文件名不對。-lEGL實際去找libEGL.so但板子 BSP 里只有l(wèi)ibmali-bifrost-g52.so里面雖然導(dǎo)出 EGL 符號但并沒有名為libEGL.so的軟鏈接。解決辦法在 mali 庫目錄里手動建libEGL.so - libmali-bifrost-g52.so、libGLESv2.so - libmali-bifrost-g52.so。你忘了在鏈接命令里加-lEGL。因為 EGL 頭文件是純聲明編譯器不會知道你還需要專門鏈接哪個庫它只會看著源碼里調(diào)用了eglCreateContext等到鏈接器階段才告訴你找不到符號。你的 toolchain 是arm-linux-gnueabihf但目標(biāo)系統(tǒng)是aarch64。位數(shù)不一致鏈接器當(dāng)然報 undefined。排查時要用file libmali*.so看 ELF 的 machine 類型。實際操作中我最常用的土辦法是先編譯一個只調(diào)用eglGetDisplay的最小程序把庫路徑和-Wl,--trace或-Wl,-y,eglCreateContext加進(jìn)去鏈接器會輸出它到底在哪個庫里找到符號。這條命令的輸出信息量極大能幫你快速判斷是頭文件和庫版本不匹配還是庫文件本身有問題。4.3 重啟后 LD_LIBRARY_PATH 丟失如果你是在 SSH 會話里執(zhí)行export LD_LIBRARY_PATH...一關(guān)終端就失效這是 shell 環(huán)境變量作用域的問題。針對這種情況我建議根據(jù)啟動方式選擇方案手動調(diào)試寫到~/.bashrc或/etc/profile.d/mali.sh。systemd 服務(wù)在 service 文件的[Service]段加EnvironmentLD_LIBRARY_PATH/usr/lib/aarch64-linux-gnu/mali。圖形桌面登錄寫到 Xsession 或 wayland-session 的配置里。最省事也最穩(wěn)定直接用/etc/ld.so.conf.d/mali.confldconfig。我見過不少朋友把LD_LIBRARY_PATH寫進(jìn).bashrc結(jié)果 systemd 起的服務(wù)依然找不到庫。后來我全部統(tǒng)一成ld.so.conf.d方案系統(tǒng)所有進(jìn)程都受益。唯一需要注意的是ldconfig后要確認(rèn)ldconfig -p里出現(xiàn)了 mali 庫并注意順序優(yōu)先級。4.4 一個萬能級的排查步驟清單如果你現(xiàn)在編譯一個 Mali GPU 程序遇到問題按下面順序走一遍通常 20 分鐘內(nèi)能定位確認(rèn) GPU 型號cat /sys/class/misc/mali/device/uevent或內(nèi)核日志里的maliprobe 信息。確認(rèn)用戶態(tài)庫是否存在ls -l /usr/lib/aarch64-linux-gnu/mali/。查看庫的 SONAMEreadelf -d libmali-bifrost-g52.so | grep SONAME。交叉編譯后用readelf -d app | grep NEEDED確認(rèn)依賴?？截惖桨遄由嫌胠dd app看能否解析。用LD_DEBUGlibs ./app看動態(tài)鏈接器的詳細(xì)查找路徑這招非常有用。運(yùn)行最小 EGL 示例而不是直接上復(fù)雜渲染器。我把常遇到的靜態(tài)問題和應(yīng)對方法整理成一張速查表方便你貼到工位旁邊癥狀大概率原因排查/解決動作編譯時找不到 EGL/GLES 頭文件INCLUDE 路徑未指向 BSP 的 include 目錄在 CMake 里打印 include dirs確認(rèn)路徑存在且包含 EGL/egl.h鏈接時 undefined reference頭文件與庫不匹配庫名寫錯檢查-lEGL是否實際解析到有符號的.so用nm -D libmali.so | grep eglCreateContext運(yùn)行時找不到 libmaliLD_LIBRARY_PATH 未設(shè)置或目錄沒有這個庫用export LD_LIBRARY_PATH/usr/lib/aarch64-linux-gnu/mali或 ld.so.conf.d運(yùn)行時加載到錯誤的 libEGL庫里有多套實現(xiàn)用ldd確認(rèn)實際加載路徑必要時移動/屏蔽舊庫程序崩潰且內(nèi)核打 mali crash dump內(nèi)核驅(qū)動與用戶態(tài)庫版本不匹配/內(nèi)存壓力統(tǒng)一 BSP 版本調(diào)整 GPU 內(nèi)存分配策略檢查 dmesg渲染結(jié)果花屏/黑屏顏色格式、buffer 尺寸不對檢查 EGL config 的 buffer size嘗試不同的 ANativeWindow format5. 再進(jìn)一步GPU 計算與 AI 部署場景下的 Mali 鏈接經(jīng)驗現(xiàn)在在 ARM 板上做 GPU 計算和 AI 推理的場景非常普遍像paddleocr、sensevoice部署到 ARM 架構(gòu)平臺時很多人誤以為只靠 CPU 就能跑或者以為大家都去 CUDA 了Mali 就不需要了。實際上Mali 也支持 OpenCL部分產(chǎn)品還支持 OpenGL ES 3.1 的 compute shader甚至 ARM 在最新的 Valhall 代 GPU 上強(qiáng)化了矩陣運(yùn)算能力。對于在 ARM Mali 上部署 AI 模型鏈接層面的經(jīng)驗也值得單獨拎出來說一說。5.1 OpenCL 的鏈接和 libmali 的“萬能導(dǎo)出”Mali GPU 要跑 OpenCL往往同樣依賴一個 libmali 或?qū)ｉT的 libOpenCL.so。在 Rockchip 的 BSP 里你經(jīng)常會看到/usr/lib/aarch64-linux-gnu/mali/libOpenCL.so。這個庫可能只是一個符號鏈接到 libmali-bifrost.so。如果你的應(yīng)用要鏈接 OpenCL公式如下aarch64-linux-gnu-g cl_demo.cpp -o cl_demo \ -I/usr/aarch64-linux-gnu/include/CL \ -L/usr/lib/aarch64-linux-gnu/mali \ -lOpenCL -lpthread -ldl這里要注意有些 OpenCL 頭文件版本要求庫至少支持 OpenCL 1.2而部分老 Mali 的 BSP 只提供 1.1 擴(kuò)展。我建議你在編譯前先寫個clinfo類似的工具在板子上跑一下確認(rèn)CL_PLATFORM_VERSION和CL_DEVICE_TYPE_GPU。從部署角度如果你跑 PaddleOCR 的 GPU 版Paddle Lite 加載的 mali OpenCL 庫需要在編譯 Paddle Inference 時指定-DWITH_GPUON -DWITH_OPENCLON并且靜態(tài)/動態(tài)搜索 libOpenCL.so 的路徑要提前配置好。很多人以為 PaddleOCR 的 GPU 部署只要換一個模型文件就行實際上鏈接和運(yùn)行時庫配置缺一不可。我在 RK3588 上部署 PaddleOCR 時就是靠把libOpenCL.so放進(jìn)/usr/lib/aarch64-linux-gnu/mali/再寫一個mali.conf然后用LD_LIBRARY_PATH指向它應(yīng)用才正確調(diào)起 GPU。5.2 SenseVoice 等新一代小模型的 ARM 部署要考慮 GPU 動態(tài)庫沖突像sensevoice-small這類 ASR 模型官方往往提供 ARM 架構(gòu) CPU 版本但我實測過如果在帶 Mali GPU 的板子上有 libOpenCL部分推理框架會默認(rèn)嘗試 GPU/OpenCL 加速這時如果鏈接庫配置不對運(yùn)行可能掛掉。我的處理方式是如果只是做 CPU 推理驗證就在啟動腳本里明確不加載 mali 的 OpenCL 庫如果想要 GPU 加速就專門設(shè)計一條推理路徑確保libOpenCL.so和libmali.so來自同一 BSP 版本并設(shè)置好 loader 搜索順序。這里最容易踩的坑是你自己把libOpenCL.so.1放到/usr/local/lib而系統(tǒng)也有/usr/lib/aarch64-linux-gnu/libOpenCL.so.1兩邊的實現(xiàn)不同導(dǎo)致 clGetPlatformIDs 返回空。我建議你對板子上所有 OpenCL 相關(guān)庫做一次“審計”find / -name *OpenCL* -type f -o -name *libmali* -type f 2/dev/null把路徑理清后再決定是統(tǒng)一通過ld.so.conf.d配置還是在每個服務(wù)的啟動腳本里手動 export。小模型部署項目里穩(wěn)定大于性能。5.3 多 GPU 同時測試與 GPU 調(diào)度Mali 不是主戰(zhàn)場但也別忽略現(xiàn)在的 AI 服務(wù)器場景里linux 三個gpu同時測試、gpu調(diào)度這類詞很熱但那是 NVIDIA 和昇騰的主場。你要是真在 ARM 單板上做“多 GPU 調(diào)度”通常是指 GPU NPU VPU 的異構(gòu)協(xié)同。鏈接層面的經(jīng)驗是NPU 工具鏈比如 RKNN和 GPU 工具鏈libmali會同時出現(xiàn)在系統(tǒng)里它們各自有自己的 runtime 庫容易因符號沖突打架。我在 RK3568 上做過一個路燈檢測項目RKNN Toolkit 的庫依賴librga.so而這個庫又依賴libmali.so做 2D 加速。如果不把libmali路徑正確配置RGA 初始化也會失敗。雖然這不是嚴(yán)格的“多 GPU 調(diào)度”但底層都繞不開 Mali library 的鏈接是否干凈。我當(dāng)時的做法是把 RKNN 和 RGA 的庫、Mali 庫全部放入/opt/vendor/libs然后為每個服務(wù)單獨配置LD_LIBRARY_PATH避免全局污染。5.4 NVIDIA GPU Operator 文檔、arm64 GPU 節(jié)點Mali 只是背景板還有一個容易誤解的地方nvidia gpu operator 官方文檔 中文這種熱詞你可能會覺得與 Mali 無關(guān)但如果你的 ARM 平臺指的是Grace-Hopper 這類 NVIDIA ARM64 服務(wù)器那么它里面并沒有 Mali GPU而是 NVIDIA 自家 GPU。這種平臺上的 GPU 驅(qū)動、容器運(yùn)行時支持跟 Mali 完全不是一套。寫這篇博文的目的之一也是想提醒大家看到 “ARM” 和 “GPU” 兩個詞不要想當(dāng)然認(rèn)為就是 Mali。ARM 作為一種 CPU 架構(gòu)可以搭配 Mali、Adreno、PowerVR、NVIDIA 等不同的 GPU IP而“Mali GPU links”更準(zhǔn)確地說是針對 ARM SoC 集成的 Mali 圖形/計算處理單元的鏈接與部署場景。如果你要在 NVIDIA ARM64 上部署加速需要考慮的是 NVIDIA 官方 driver 的 deb/rpm 包【像熱詞里的銀河麒麟 ssh 10.3 rpm升級包arm就屬于這種場景】而不是 Mali 的 libmali。這個區(qū)別我在多個項目里反復(fù)提醒過因為兩者編譯參數(shù)、動態(tài)庫名稱、EGL 實現(xiàn)都完全不同。6. 避坑心得與長期維護(hù)建議6.1 我每次搭建 Mali 開發(fā)環(huán)境都會做的三件小事經(jīng)過反復(fù)折騰后我把一套“初始化清單”固定了下來你以后拿到任何新的 ARM/Mali 板子都可以照做第一下載或提取 BSP 后先別急著編應(yīng)用先把板子上的 GPU 相關(guān)庫做一次快照ls -l /usr/lib/aarch64-linux-gnu/mali/、cat /sys/kernel/debug/mali/version或/sys/class/misc/mali/device/uevent把版本號記錄下來。第二在板子上跑一個最小的 EGL 初始化程序。這個程序不做任何渲染只是創(chuàng)建 EGLDisplay、EGLContext打印EGL_VENDOR。如果它能過說明庫和系統(tǒng)環(huán)境正常如果不行后面搞什么大程序都是白搭。第三寫一個setenv_mali.sh腳本內(nèi)容就是用export LD_LIBRARY_PATH/usr/lib/aarch64-linux-gnu/mali:$LD_LIBRARY_PATH并且用ldconfig -p驗證它的實際生效情況。如果你的系統(tǒng)已經(jīng)用ld.so.conf.d方案則這個腳本可以空著但你要確保每個 systemd 服務(wù)的Environment字段都對了。6.2 如何確保內(nèi)核驅(qū)動和用戶態(tài)庫版本的一致Mali 最麻煩的問題就是內(nèi)核 kbase 驅(qū)動和用戶態(tài) libmali 的版本必須匹配。比如 RK 的 BSP release 里內(nèi)核側(cè)通過mali_kbase模塊實現(xiàn)用戶態(tài)側(cè)libmali的版本字符串通常長這樣r32p0-01rel0或g2p0-01rel0。如果你的內(nèi)核 driver 是 r32p0而用戶態(tài)庫是 g2p0即使兩者都能加載運(yùn)行一段時間后也極易產(chǎn)生 GPU crash dump。我建議你在初始化時寫一個監(jiān)控腳本定時抓 dmesg 里的maliregister 信息再對照庫的strings libmali.so | grep r[0-9]p輸出確認(rèn)一致。這聽起來很土但在嵌入式環(huán)境里往往比想象中有效。你甚至可以寫個小函數(shù)把查詢結(jié)果自動拼接成一條日志放到 CI 流水線里每次更新 BSP 后自動比對。選擇 BSP 時盡量使用官方 release 里配好的固定版本組合不要自己去內(nèi)核主線里隨便升級 kbase 驅(qū)動——主線內(nèi)核的 Mali 驅(qū)動版本往往和 Rockchip/全志的庫版本不匹配。6.3 最終部署分發(fā)應(yīng)用時把庫和環(huán)境一起帶上我經(jīng)?？吹接腥税丫幾g好的二進(jìn)制直接拷給同事然后同事跑不起來原因就是目標(biāo)板子缺少 Mali 庫路徑。為了避免這種低級問題我現(xiàn)在一律在發(fā)布目錄里帶上一個deploy/文件夾my_app/ ├── my_app # 主程序 ├── libs/ │ ├── libmali-bifrost-g52.so │ ├── libEGL.so - libmali-bifrost-g52.so │ ├── libGLESv2.so - libmali-bifrost-g52.so │ ├── libOpenCL.so - libmali-bifrost-g52.so │ └── libgbm.so.1 # 如果有 GBM 需求 ├── run.sh └── README.mdrun.sh內(nèi)容非常短#!/bin/bash SCRIPT_DIR$(cd $(dirname $0) pwd) export LD_LIBRARY_PATH$SCRIPT_DIR/libs:$LD_LIBRARY_PATH exec $SCRIPT_DIR/my_app $這種方式既保證了庫版本的可控又避免了污染系統(tǒng)目錄后續(xù)升級應(yīng)用時只需替換libs下的.so完全不用改動系統(tǒng)鏡像。我做過的好幾個嵌入式 HMI 項目都是這么發(fā)版的。當(dāng)然如果板子上的系統(tǒng)集成商有統(tǒng)一鏡像管理你仍可以沿用/usr/lib/aarch64-linux-gnu/malild.so.conf.d方案但應(yīng)用自攜帶libs至少是一種與環(huán)境解耦的底牌。6.4 關(guān)于LD_LIBRARY_PATH的一個容易被忽略的細(xì)節(jié)最后補(bǔ)充一個在這個問題上極其容易被忽略的坑動態(tài)鏈接器對LD_LIBRARY_PATH的搜索順序是啟動時固化的不是運(yùn)行中動態(tài)變更的。也就是說如果你的程序在運(yùn)行過程中把庫路徑unset或改成別的值已經(jīng)加載進(jìn)來的庫不會受影響。所以如果你在調(diào)試時看到“我明明改了環(huán)境變量但程序還是報錯”大概率是因為你的 shell 環(huán)境沒有重新執(zhí)行export或者程序的父進(jìn)程是 systemd 啟動的根本不會繼承你 shell 里的變量。解決方法是始終用env | grep LD_LIBRARY_PATH確認(rèn)當(dāng)前值或者在程序里主動調(diào)用dlopen并指定絕對路徑。有些程序例如部分 AI 推理引擎內(nèi)部自己管理庫加載可能不走系統(tǒng)動態(tài)鏈接器的默認(rèn)搜索而是通過/proc/self/maps和dlopen的絕對路徑來加載。這種情況下你即便配好LD_LIBRARY_PATH也不一定管用最直接的辦法就是看到庫路徑不對時手動改庫的軟鏈接或直接替換/usr/lib下的庫文件但這種操作要盡量保證系統(tǒng)里沒有其他程序依賴舊版本。我在 RK3588 上面調(diào)試 GStreamer Mali 的 GPU 視頻合成時就遇到過 GStreamer 用絕對路徑加載libmali而忽略LD_LIBRARY_PATH的情況最后是通過patchelf --set-rpath /usr/lib/aarch64-linux-gnu/mali給 GStreamer 的插件 .so 設(shè)置 RPATH 解決的。這里不展開講 patchelf 的所有參數(shù)但記住一個原則軟件加載庫的路徑可能五花八門最終要確認(rèn)的是 /proc/進(jìn)程pid/maps 里面那行 .so 到底指向哪里。6.5 額外提醒交叉編譯時不要過度依賴-marchnative我知道很多人喜歡在交叉編譯時加-marchnative來提升性能但在 Mali 項目里這是個非常危險的操作。-marchnative會讓編譯器根據(jù)宿主機(jī)x86的 CPU 特性生成指令而不是目標(biāo) ARM 板卡的指令集。結(jié)果就是編譯出的程序根本跑不了或者出現(xiàn)非法指令。正確做法是明確指定目標(biāo) CPU 的微架構(gòu)比如-marcharmv8-asimd或更高版本。Mali GPU 本身和 CPU 指令集無關(guān)但用戶態(tài)驅(qū)動的調(diào)用序列和方式與 CPU ABI 強(qiáng)相關(guān)。如果你在交叉編譯時不小心加了 host 相關(guān)的 flags鏈接階段可能不會報錯但程序一上板就是 illegal instruction。這種錯誤很難排查所以我建議在你的 CMakeLists 里加上set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -marcharmv8-a) set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -marcharmv8-a)如果你的程序一定要用 OpenMP 或向量化再按目標(biāo)板卡的 CPU 核型如 Cortex-A76微調(diào)-mcpu參數(shù)。這個原則在“ARM Mali GPU links”這個主題下尤其重要Mali 庫本身是預(yù)編譯好的你的應(yīng)用只要遵循目標(biāo)板的 ABI鏈接就不會出問題。我在實際項目里見過太多因為-marchnative把整個工程搞得云里霧里的情況所以這里單獨拎出來提醒一下。7. 最后再分享一個實用小技巧用LD_DEBUGlibs看透一切加載細(xì)節(jié)如果你和我一樣是“肉眼調(diào)試派”那么LD_DEBUG環(huán)境變量絕對是你解決動態(tài)庫鏈接問題的殺手锏。在板子上執(zhí)行LD_DEBUGlibs ./mali_demo你會看到動態(tài)鏈接器打印出它查找每個庫的完整路徑find librarylibEGL.so.1 [0]; searching search path/usr/lib/aarch64-linux-gnu/mali/tls/aarch64:/usr/lib/aarch64-linux-gnu/mali/tls:/usr/lib/aarch64-linux-gnu/mali (LD_LIBRARY_PATH) trying file/usr/lib/aarch64-linux-gnu/mali/tls/aarch64/libEGL.so.1 trying file/usr/lib/aarch64-linux-gnu/mali/tls/libEGL.so.1 trying file/usr/lib/aarch64-linux-gnu/mali/libEGL.so.1這一段信息幾乎能解決所有“我明明設(shè)置了路徑但程序還是找不到”的困惑。比如它告訴你搜索路徑里有沒有 mali 目錄、是否因為 tls 子目錄不存在而被忽略。還有LD_DEBUGbindings可以看到符號綁定過程LD_DEBUGfiles看到文件打開關(guān)閉順序。真實項目中使用這招一個小時能頂你好幾天“猜謎式”調(diào)試。但注意LD_DEBUG輸出量很大會拖慢程序啟動只適合調(diào)試時用。生產(chǎn)環(huán)境千萬不要留著。寫在最后ARM Mali GPU 的鏈接?xùn)|西說多不多說少也不少。你只要抓住“編譯時符號解析”和“運(yùn)行時動態(tài)加載”這條主線再深入理解libmali在 BSP 體系中的定位大部分問題都能迎刃而解。我個人經(jīng)歷中最難的不是哪一條命令不會寫而是同時面對內(nèi)核驅(qū)動、用戶態(tài)庫、CMake 交叉編譯鏈、運(yùn)行時環(huán)境變量這幾個環(huán)節(jié)時心智容易混亂。建議你調(diào)試時一次只動一個變量改完路徑就ldd驗證改完 CMake 就readelf -d驗證不要一次性把所有參數(shù)全換掉。這樣即便報錯也能快速回滾。如果你已經(jīng)能順利把 EGL Context 創(chuàng)建出來并且glGetString(GL_RENDERER)返回了 “Mali-…” 開頭的信息那恭喜你這一關(guān)過了。后面無論是寫渲染器、OpenCL 計算還是往 RKNN/NPU 異構(gòu)方案里塞 Mali 加速你都已經(jīng)有了扎實的底層基礎(chǔ)。希望這篇內(nèi)容能幫你在 ARM Mali 的板子上少走彎路早點跑出第一幀畫面。