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