實(shí)戰(zhàn):架構(gòu)、驅(qū)動(dòng)與AI部署全解析)
Mali GPU 這顆藏在 SoC 里的“計(jì)算心臟”這些年我折騰過的架構(gòu)、驅(qū)動(dòng)和部署問題值得好好梳理一遍。這篇文章我打算從一個(gè)實(shí)際開發(fā)者的視角把 ARM Mali GPU 相關(guān)的資源、開發(fā)工具鏈、驅(qū)動(dòng)調(diào)試和 AI 部署經(jīng)驗(yàn)一次性講透文中涉及的鏈接和關(guān)鍵詞希望幫你少走點(diǎn)彎路。1. 認(rèn)識(shí) Mali GPU架構(gòu)演進(jìn)與開發(fā)者的第一課1.1 從 Utgard 到第五代你手里的 Mali 到底是哪一代很多新手拿到一塊開發(fā)板第一件事就是cat /proc/cpuinfo看 CPU 型號(hào)卻常常忽略 GPU 的架構(gòu)代次。這個(gè)信息直接決定了你能用哪個(gè)版本的驅(qū)動(dòng)、支持什么圖形 API、能不能跑 OpenCL 通用計(jì)算。Mali GPU 家族大概分成這幾代Utgard 架構(gòu)代表作 Mali-400、Mali-450廣泛用在老款手機(jī)和入門級(jí)工控板。只支持 OpenGL ES 2.0OpenCL 支持非常有限如果沒有特殊需求不建議在這類 GPU 上折騰通用計(jì)算。Midgard 架構(gòu)代表作 Mali-T720、T760、T820、T860、T880。這是目前二手市場(chǎng)和低成本方案里最常見的一代支持 OpenGL ES 3.1 和 OpenCL 1.1/1.2 的部分特性。我最早做 GPU 調(diào)試就是在這代架構(gòu)上印象最深的是它的 CoreLink 互聯(lián)設(shè)計(jì)多核擴(kuò)展時(shí)緩存一致性做得不錯(cuò)。Bifrost 架構(gòu)代表作 Mali-G71、G72、G51、G76。從這代開始Mali 引入了“quad-based”的 warp 調(diào)度思想Shader Core 內(nèi)部以 16 線程為一組執(zhí)行指令對(duì)計(jì)算著色器的友好度明顯提升。支持 Vulkan 1.0。Valhall 架構(gòu)代表作 Mali-G57、G77、G78、G68。這代把指令集從 32 位統(tǒng)一到了 64 位調(diào)度器對(duì)分支發(fā)散的處理更高效。如果搞 AI 推理Valhall 的 FP16 算力非??捎^。第五代Immortalis 系列代表作 Immortalis-G715主打硬件光線追蹤但這跟大多數(shù)嵌入式開發(fā)者關(guān)系不大看看就好。1.2 為什么說 Mali 的驅(qū)動(dòng)模型和 PC 顯卡完全不同在 x86 平臺(tái)上NVIDIA 或 AMD 顯卡有獨(dú)立的顯存驅(qū)動(dòng)是一整套完整的二進(jìn)制棧。而 Mali GPU 用的是統(tǒng)一內(nèi)存架構(gòu)UMAGPU 和 CPU 共享同一片物理內(nèi)存中間沒有顯存顆粒。這個(gè)特性帶來兩個(gè)直接影響功耗低、成本低適合 SoC 集成但也意味著 GPU 運(yùn)算會(huì)和 CPU 搶占內(nèi)存帶寬。實(shí)測(cè)經(jīng)驗(yàn)是在 4K 分辨率下GPU 密集任務(wù)會(huì)把 DDR 帶寬吃滿CPU 側(cè)表現(xiàn)會(huì)肉眼可見地變卡。驅(qū)動(dòng)不是一個(gè)“萬能 .exe”。Mali 的 Linux 驅(qū)動(dòng)通常分成三塊內(nèi)核態(tài)的DPPDisplay and Pixel Processor相關(guān)模塊、內(nèi)核態(tài)的MMU 和 job manager通常編譯進(jìn)內(nèi)核或作為模塊加載以及用戶態(tài)的libmali.so。用戶態(tài)庫需要針對(duì)具體的 GPU 型號(hào)和 DDK 版本匹配隨手找一個(gè).so拷進(jìn)去最典型的結(jié)果就是gpu crash dump triggered。我見過太多項(xiàng)目的坑都出在這條鏈路上板子供應(yīng)商給的內(nèi)核是 4.19用戶態(tài)庫卻是按 4.4 內(nèi)核編譯的跑起來毫無征兆地黑屏。排查到最后居然是 libmali.so 的 EGL 入口和內(nèi)核模塊的 ioctl 版本對(duì)不上。2. 驅(qū)動(dòng)與用戶態(tài)工具鏈交叉編譯、庫路徑和真實(shí)部署細(xì)節(jié)2.1 Linux 環(huán)境下 Mali 驅(qū)動(dòng)的整體結(jié)構(gòu)在 Linux 系統(tǒng)上Mali 驅(qū)動(dòng)的典型加載路徑是這樣的內(nèi)核側(cè)/sys/module/mali/目錄存在說明 Mali 內(nèi)核模塊已加載。設(shè)備節(jié)點(diǎn)/dev/mali0是 GPU 的用戶態(tài)訪問入口沒有這個(gè)設(shè)備節(jié)點(diǎn)用戶態(tài)庫再全也白搭。用戶態(tài)庫通常位于/usr/lib/aarch64-linux-gnu/或/usr/lib/arm-linux-gnueabihf/重點(diǎn)文件包括libmali.so集成了 EGL/GLES/OpenCL 多個(gè)入口、libEGL.so、libGLESv2.so。說到這要提一個(gè)熱搜詞里反復(fù)出現(xiàn)的命令export LD_LIBRARY_PATH/usr/lib/aarch64-linux-gnu/mali:$LD_LIBRARY_PATH這條命令本身沒什么問題就是讓動(dòng)態(tài)鏈接器優(yōu)先去 Mali 庫所在的目錄找?guī)煳募?。但我必須提醒一句不要盲目敲這條命令。如果當(dāng)前系統(tǒng)的 Mali 庫實(shí)際在/usr/lib/aarch64-linux-gnu/下一個(gè)層級(jí)而/usr/lib/aarch64-linux-gnu/mali/這個(gè)子目錄根本不存在export 完反而可能因?yàn)閹炻窂巾樞騿栴}加載到錯(cuò)誤的 libmali。正確的做法是先確認(rèn)目錄存在ls /usr/lib/aarch64-linux-gnu/mali/如果確實(shí)沒有這個(gè)目錄但系統(tǒng)里的 GPU 能正常工作那就說明庫文件直接放在了通用搜索路徑里這時(shí)不需要額外設(shè)置 LD_LIBRARY_PATH。真正需要設(shè)置的場(chǎng)景是交叉編譯后把庫放在非標(biāo)準(zhǔn)路徑運(yùn)行時(shí)才需要告訴系統(tǒng)去哪里找。2.2 交叉編譯工具鏈選型從 ARM Compiler 5 到 GCC熱搜詞里出現(xiàn)的“arm compiler 5.06u7 下載”是 ARM 自家提供的商業(yè)編譯器有歷史包袱的項(xiàng)目特別是一些閉源第三方庫還在用它。ARM Compiler 5 系列最后的版本是 5.06 update 7之后的官方支持轉(zhuǎn)向了 ARM Compiler 6基于 LLVM。如果你的項(xiàng)目不強(qiáng)制要求 AC5我強(qiáng)烈建議直接用 GCC 交叉工具鏈比如aarch64-linux-gnu-gcc省心得多。選工具鏈時(shí)有個(gè)點(diǎn)要注意ARM Compiler 5.06 編譯出來的代碼默認(rèn)針對(duì) ARMv7 或 ARMv8 的老 AArch32 模式而 Mali GPU 用戶態(tài)驅(qū)動(dòng)多數(shù)是 AArch64 庫?;煊脮r(shí)最好統(tǒng)一目標(biāo)架構(gòu)否則鏈接階段會(huì)出現(xiàn)莫名其妙的cannot find -lEGL或 ABI 不匹配的報(bào)錯(cuò)。一個(gè)實(shí)用的排查技巧是使用file /usr/lib/aarch64-linux-gnu/mali/libmali.so看看輸出是ELF 64-bit LSB shared object, ARM aarch64還是ELF 32-bit。如果返回的是 32 位而你的用戶程序是 64 位那么無論怎么配 LD_LIBRARY_PATH 都無濟(jì)于事。2.3 銀河麒麟系統(tǒng)上安裝軟件的實(shí)操SSH 升級(jí)包示例熱搜詞里出現(xiàn)“銀河麒麟 ssh 10.3 rpm升級(jí)包arm”其實(shí)指向一個(gè)典型場(chǎng)景國產(chǎn)化替代環(huán)境里的 ARM 服務(wù)器系統(tǒng)自帶 OpenSSH 版本偏舊想升到 10.3只能找 rpm 包。這類系統(tǒng)通常是 ARM64 架構(gòu)基礎(chǔ)安裝命令我實(shí)測(cè)過一套sudo rpm -Uvh openssh-10.3p1-1.ky3.arm64.rpm這里的關(guān)鍵在于-Uvh它表示升級(jí)-U、顯示詳細(xì)輸出-v、顯示進(jìn)度-h。直接rpm -ivh安裝舊版本沒卸載干凈時(shí)可能生成兩個(gè) sshd 服務(wù)導(dǎo)致 ssh 端口綁定沖突。另外在麒麟這類系統(tǒng)上如果用非 root 用戶執(zhí)行后出現(xiàn)error: cant create transaction lock on /var/lib/rpm/.rpm.lock多半是權(quán)限問題加 sudo 重試即可。升級(jí)完 OpenSSH 后請(qǐng)一定重啟sshdsudo systemctl restart sshd不要直接斷開當(dāng)前的 ssh 連接先另開一個(gè)終端驗(yàn)證新版本 sshd 能正常監(jiān)聽 22 端口再退出否則可能把自己鎖在門外。2.4 ARM 系統(tǒng)常用命令工具的補(bǔ)齊很多從 x86 遷過來的朋友會(huì)發(fā)現(xiàn)ARM 板子上iftop、iotop、htop、iperf3這類工具往往沒裝。這里給一個(gè)比較通用的操作思路對(duì)于 Debian/Ubuntu 衍生系統(tǒng)樹莓派 OS、Ubuntu Mate、麒麟也是基于 Debian 體系sudo apt update sudo apt install -y htop iotop iftop iperf3對(duì)于使用 yum/dnf 的 ARM 系統(tǒng)部分 CentOS 移植版、OpenAnolis ARM 版sudo dnf install -y htop iotop iftop真實(shí)遇到的問題往往是源里沒有對(duì)應(yīng) ARM64 的 rpm 包這時(shí)候可以去 EPEL 的 aarch64 倉庫找或者直接從源碼編譯。uname -m 看一下輸出aarch64就是 ARM64armv7l是 32 位 ARM。3. GPU 計(jì)算與 AI 推理部署Mali 在真實(shí)項(xiàng)目里的邊界3.1 Mali 跑 GPGPU 的幾條路線OpenCL、OpenGL ES Compute、Vulkan Compute很多做嵌入式視覺的朋友都問過Mali GPU 能不能像 NVIDIA 那樣跑 CUDA很遺憾CUDA 是 NVIDIA 的封閉生態(tài)Mali 上一條都走不通。Mali 可選的通用計(jì)算路線大致三條OpenCLMidgard 以上架構(gòu)支持不錯(cuò)適合圖像處理、卷積類的并行任務(wù)。Mali OpenCL 驅(qū)動(dòng)對(duì) buffer 的分配有嚴(yán)格要求頻繁創(chuàng)建/釋放大批量 buffer 會(huì)引發(fā)嚴(yán)重抖動(dòng)正確姿勢(shì)是復(fù)用 buffer。OpenGL ES Compute Shader如果已經(jīng)有 GLES 渲染管線混入 compute shader 成本最低適合后處理特效不太適合超大計(jì)算量。Vulkan ComputeValhall 架構(gòu)上效率最高但開發(fā)門檻也最高需要自己管理 Command Buffer 和 Pipeline。如果你跑 NCNN 推理框架它可以直接切換到 Vulkan 后端來利用 Mali GPU這也是目前邊緣設(shè)備上最主流的做法。用 NCNN 的時(shí)候編譯命令關(guān)鍵參數(shù)這樣寫cmake -DCMAKE_TOOLCHAIN_FILE../../toolchains/aarch64-linux-gnu.toolchain.cmake \ -DNCNN_VULKANON \ -DNCNN_OPENMPON ..如果編譯好以后運(yùn)行ncnn_benchmark報(bào)錯(cuò)vkCreateInstance failed大概率是 GPU 驅(qū)動(dòng)和 Vulkan Loader 不匹配可以用vulkaninfo先檢查。3.2 PyTorch 與 PaddleOCR 的 GPU 部署哪些能跑哪些別折騰很多朋友問我“ARM 板子上能不能像 x86 一樣裝 PyTorch GPU 版”。說實(shí)話PyTorch 在 ARM 平臺(tái)上對(duì) Mali GPU 幾乎沒有官方支持。主打推理場(chǎng)景時(shí)更現(xiàn)實(shí)的方案是TensorFlow Lite對(duì) Mali 支持較好通過gpuDelegate可以在部分算子下調(diào)用 OpenCL。NCNN / MNN國內(nèi)開源框架對(duì) ARM Mali 的適配比較積極。ONNX Runtime有 OpenCL execution provider但算子覆蓋有限。如果在搜 PyTorch GPU 安裝教程注意一點(diǎn)不要看到 NVIDIA 的教程就往 ARM 上套如果發(fā)現(xiàn)要裝 CUDA那大概率是 x86 教程。真正的 ARM 平臺(tái)部署推理模型的路線是 onnxruntime arm 版 so或者直接用 TFLite。關(guān)于 PaddleOCR 的 GPU 模式它在 ARM Mali 上最靠譜的一條路是走 NPU如果 SoC 里有GPU 模式需要 cudnn 8.5 之類的前提那都是面向 NVIDIA 的。我實(shí)測(cè)下來在 RK3588Mali-G610上跑 PaddleOCR 的 ARM CPU 版用 ONNX Runtime 加多線程效果比折騰 GPU 穩(wěn)定且 ROI 更高。3.3 大模型微調(diào)里的 GPUMali 的無奈與出路熱搜詞里“gpu微調(diào)大模型”也指向當(dāng)前很火的場(chǎng)景?,F(xiàn)實(shí)很骨感Mali GPU 不適合做大模型微調(diào)。原因不復(fù)雜大模型微調(diào)需要超大顯存、高帶寬和成熟的張量核心Mali 統(tǒng)一內(nèi)存架構(gòu)撐不起來。但 Mali 可以做兩件事部署量化后的推理模型比如在手機(jī)上跑 7B 模型走 4bit 量化通過 Vulkan compute 調(diào)用 Mali 算力速度雖然沒法說“流暢”但能接受。混合調(diào)度把部分算子放在 GPU部分放在 NPU剩下放 CPU用 NCNN 的流水線做并行。這個(gè)對(duì)開發(fā)者的調(diào)度功底要求很高新手不建議一上來就碰。3.4 ollama 指定 GPU 和 GPU 租用的經(jīng)驗(yàn)ollama 指定 GPU 的場(chǎng)景主要在 Linux x86 服務(wù)器上但這不代表 ARM 完全沒機(jī)會(huì)。如果在 ARM 板子上跑 ollama我建議直接用官方的 linux-arm64 安裝腳本安裝安裝完默認(rèn)走 CPU。如果板子的 NPU 有額外的 runtime也可以嘗試配置但不要指望 Mali GPU 能直接被 ollama 調(diào)用——它沒把 OpenCL/Vulkan 納入主流后端。GPU 租用這一塊補(bǔ)充一句如果你是做 AI 訓(xùn)練租帶有獨(dú)立顯卡的云主機(jī)比本地淘 ARM 板子靠譜得多成本低、免維護(hù)。真正需要本地 Mali 的場(chǎng)景還是邊緣推理和圖形渲染。4. 常見問題與排查技巧實(shí)錄從 crash dump 到性能調(diào)優(yōu)4.1 “gpu crash dump triggered”到底是什么這條讓我最頭疼也最熟悉Mali 驅(qū)動(dòng)檢測(cè)到 GPU 執(zhí)行出錯(cuò)后會(huì)打印一系列寄存器狀態(tài)和 dump 信息。觸發(fā)原因集中在幾個(gè)點(diǎn)shader 數(shù)組越界最常見。比如 compute shader 里訪問 buffer 時(shí)下標(biāo)超出了分配范圍。排查手段是使用Mali Offline Compilermalioc靜態(tài)分析或者打開報(bào)錯(cuò)時(shí)附帶的 shader 索引核對(duì)對(duì)應(yīng) shader。非法指令或浮點(diǎn)異常LLVM 編譯 OpenCL kernel 時(shí)如果優(yōu)化級(jí)別過高某些中間表示會(huì)引入 GPU 不支持的指令。調(diào)低優(yōu)化級(jí)別或者用-cl-fast-relaxed-math之外的保守編譯選項(xiàng)。非法內(nèi)存訪問用戶態(tài) glBufferData 分配的 buffer 太小shader 訪問越界直接命中未映射區(qū)域。出現(xiàn)gpu crash dump triggered后第一步不是改代碼而是先把 dump 完整保存下來。Mali 驅(qū)動(dòng)會(huì)給出類似這樣的信息示意Mali: gpu crash dump triggered Mali: Job fault 0x0013Job fault后面的十六進(jìn)制數(shù)很關(guān)鍵不同值對(duì)應(yīng)不同故障類型。查內(nèi)核頭文件mali_kbase_gpu_fault.h能定位到具體錯(cuò)誤碼。比如 fault 0x0004 是讀寫非法地址0x0005 是總線錯(cuò)誤0x0013 是 job 超時(shí)。應(yīng)對(duì)策略一般三步走升級(jí)用戶態(tài)驅(qū)動(dòng)到與內(nèi)核匹配的 DDK 版本。用malioc檢查 shader 的資源占用和非法行為。簡(jiǎn)化場(chǎng)景二分排查哪個(gè) draw call / dispatch 觸發(fā)崩潰。4.2 那臺(tái) Linux 板子上的“三個(gè) GPU 同時(shí)測(cè)試”怎么落地?zé)崴言~“l(fā)inux 三個(gè) gpu同時(shí)測(cè)試”聽起來像是服務(wù)器多卡場(chǎng)景但 ARM 平臺(tái)上也可能遇到多核 Mali 或 MaliNPUGPU 的組合。我分享一個(gè)通用方法論用/dev/mali0的設(shè)備句柄區(qū)分 GPU 實(shí)例但 Mali 通常是一個(gè) SoC 只有一個(gè) GPU 設(shè)備節(jié)點(diǎn)。如果是多個(gè) SoC 組成的集群比如一臺(tái)主板上集成了多塊 RK3588那就按進(jìn)程綁定不同的/dev/mali0用glmark2-es2等工具做并行壓力測(cè)試然后通過mali_util和mali_pmu有性能計(jì)數(shù)器的板子看利用率。如果想同時(shí)跑 CPU/GPU/NPU 的負(fù)載需要關(guān)注總內(nèi)存帶寬建議用perf stat或likwid這類工具先摸一下 baseline。如果只是測(cè)試單顆 Mali GPU 的穩(wěn)定性就用glmark2-es2連續(xù)跑幾小時(shí)配合溫度監(jiān)控判斷散熱是否達(dá)標(biāo)while true; do glmark2-es2 --run-forever; done并在另一個(gè)終端跑watch -n 1 cat /sys/class/thermal/thermal_zone0/temp如果溫度超過 85°C散熱就要加強(qiáng)。4.3 Linux 禁用 GPU、驅(qū)動(dòng)黑名單和 GPU 調(diào)度有些場(chǎng)景下我們反而要禁用 GPU。比如在服務(wù)器環(huán)境里Mali GPU 的圖形功能用不上還占內(nèi)存帶寬最簡(jiǎn)單的做法是sudo sh -c echo blacklist mali /etc/modprobe.d/blacklist-mali.conf sudo reboot如果想臨時(shí)卸載驅(qū)動(dòng)模塊而不重啟sudo rmmod mali不過需要確認(rèn)沒有進(jìn)程占用 GPU。另外“GPU調(diào)度”在 Mali 語境下一般指 job scheduler 的優(yōu)先級(jí)策略Mali 驅(qū)動(dòng)默認(rèn)是按提交順序排隊(duì)但可以通過dma_fence相關(guān)機(jī)制或者用戶態(tài)設(shè)置優(yōu)先級(jí)。實(shí)際調(diào)優(yōu)經(jīng)驗(yàn)是在實(shí)時(shí)視覺場(chǎng)景里盡量把 GPU job 切小避免單個(gè)大 job 霸占所有 shader core。4.4 學(xué)習(xí)資源和“l(fā)inks”的整理說了這么多最后把真正有價(jià)值的資源鏈接整理一下以官方文檔名和社區(qū)名稱為主搜索時(shí)認(rèn)準(zhǔn)這些名字Mali GPU 官方文檔ARM 官網(wǎng)的 “Mali GPU” 文檔中心包括Arm Mali GPU Best Practices Guide和Mali Offline Compiler User Guide。Mali 驅(qū)動(dòng)源碼與 DDK如果從 vendor BSP 里拿不到最新驅(qū)動(dòng)去 ARM 官網(wǎng)的 “Arm Driver Development Kit (DDK)” 頁面注冊(cè)下載。工具鏈Arm Compiler 5.06在官網(wǎng)的下載中心頁注冊(cè)后可以下載歷史版本免費(fèi)替代用 Linaro 的gcc-arm-9.2-2019.12。調(diào)試工具Android 平臺(tái)可以用Mali Graphics DebuggerMGDLinux 平臺(tái)可以用開源工具M(jìn)aliGPU或配合perf使用內(nèi)核導(dǎo)出的 PMU 事件。框架層面NCNN 官方 GitHub 的 README 對(duì) Vulkan 后端有詳細(xì)編譯說明TFLite 官方文檔里有 GPU Delegate 的 ARM 支持列表。性能分析Streamline Performance Analyzer配合gatord守護(hù)進(jìn)程可以采集 GPU 的硬件計(jì)數(shù)器這是調(diào)優(yōu)比較標(biāo)準(zhǔn)的路徑。GPU 模型與規(guī)格速查Ardunix Mali GPU數(shù)據(jù)庫按 Mali 型號(hào)查最大頻率、核心數(shù)和 API 支持級(jí)別做方案選型時(shí)很有用。5. 從 ARM 匯編到系統(tǒng)級(jí)優(yōu)化用底層視角理解 Mali 生態(tài)5.1 ARM 匯編入門對(duì) Mali 開發(fā)的隱藏價(jià)值很多人覺得寫 ARM 匯編和 GPU 開發(fā)八桿子打不著。其實(shí) GPU 的 shader 最終也要編譯成 GPU 指令而驅(qū)動(dòng)和用戶態(tài)庫里的 CPU 部分也跑在 ARM 指令集上。懂一點(diǎn) ARM 匯編至少有三個(gè)實(shí)際好處能看懂 crash dump 里的 PC 寄存器和調(diào)用??焖俣ㄎ皇球?qū)動(dòng)死循環(huán)還是應(yīng)用層非法跳轉(zhuǎn)。調(diào) NEON 優(yōu)化時(shí)能識(shí)別編譯器生成的低效指令序列手動(dòng)改進(jìn)向量化策略。理解 AArch64 調(diào)用約定x0-x7 傳參x30 存返回地址排查 JNI/OpenCL host 端代碼時(shí)不容易懵。入門路線我建議先看 ARM 官方《ARM Architecture Reference Manual》的 AArch64 章節(jié)然后找《ARM 匯編語言實(shí)戰(zhàn)從零到精通》這類偏實(shí)戰(zhàn)的書刷一遍最后拿objdump -d反匯編實(shí)際的 C 代碼對(duì)比驗(yàn)證。5.2 教師視角與“期末復(fù)習(xí)”關(guān)鍵詞扯點(diǎn)閑篇熱搜詞里有“arm 期末復(fù)習(xí)”“arm處理器體系結(jié)構(gòu)及其應(yīng)用 電子科技大學(xué)”說明不少學(xué)生朋友也在查資料。如果你想快速建立知識(shí)框架我建議按“體系結(jié)構(gòu) → 指令集 → MMU/Cache → 異常模型 → 啟動(dòng)流程BL31/U-Boot→ 外設(shè)/GPU”這條鏈路復(fù)習(xí)。后面提到的arm bl31 uboot就是啟動(dòng)流程中非常關(guān)鍵的兩個(gè)環(huán)節(jié)BL31 是 ARM Trusted Firmware 的運(yùn)行時(shí) EL3 固件U-Boot 負(fù)責(zé)拉起內(nèi)核。學(xué)習(xí)過程中多數(shù)人都會(huì)在 MMU 這塊卡殼。Mali GPU 在這方面其實(shí)給了很好的參照物GPU 也有自己的 MMU叫Mali MMU它負(fù)責(zé)把 GPU 的虛擬地址翻譯成物理地址和 CPU 側(cè) MMU 的原理高度相似。5.3 使用 malioc 分析 shader找到性能瓶頸Mali 平臺(tái)和 NVIDIA 不一樣沒有 nsight 這類圖形化分析工具但Mali Offline Compilermalioc是命令行神器。它可以不跑真機(jī)直接編譯 shaderGLSL/OpenCL C輸出寄存器占用率、workgroup 大小建議、內(nèi)存訪問模式分析等。一個(gè)典型的分析命令malioc -v shader.frag關(guān)鍵輸出項(xiàng)Work register count每個(gè)線程占用的寄存器數(shù)。太高會(huì)降低 occupancy太低可能導(dǎo)致 spilling。Uniform register countuniform 緩存占用。Stack size如果過大需要減少局部變量或拆小函數(shù)。Cycle estimates不同 Mali 架構(gòu)下的模擬時(shí)鐘周期數(shù)。實(shí)測(cè)中我發(fā)現(xiàn)很多性能問題根本不是 shader 數(shù)學(xué)太復(fù)雜而是寄存器溢出導(dǎo)致本地內(nèi)存訪問暴漲。malioc 一下就能看出端倪。5.4 一例真實(shí)優(yōu)化圖像模糊濾鏡的 OpenCL 提速以 3x3 均值模糊為例最容易寫出的一種寫法是每個(gè)像素都去讀周邊 9 個(gè)點(diǎn)這會(huì)讓內(nèi)存讀取量是理論值的 9 倍。簡(jiǎn)單優(yōu)化是改用行緩存line buffer每個(gè) work-item 處理一行像素把讀到的數(shù)據(jù)緩存到 local memory橫向滑動(dòng)時(shí)只讀新像素。在 Mali GPU 上這個(gè)改動(dòng)通常能把性能提升 3~5 倍。原因是 Mali 的 L1 cache 對(duì)線性訪問比較友好local memory 有專門的高速通路。優(yōu)化前大量隨機(jī)訪問L1 cache miss 率高。優(yōu)化后順序訪問 local memory 復(fù)用吞吐量大幅提升。這個(gè)過程需要的知識(shí)正好是所有熱搜詞串聯(lián)起來的理解 Mali 的架構(gòu)第 1 章、會(huì)編譯和部署驅(qū)動(dòng)第 2 章、有 OpenCL 開發(fā)經(jīng)驗(yàn)第 3 章、會(huì)做性能分析和排查第 4 章。6. 實(shí)操心得把零散知識(shí)串成可落地的開發(fā)流程6.1 必備工具包和軟硬件清單我通常在接觸一個(gè)新的 ARM Mali 板卡時(shí)會(huì)按下面這個(gè)清單準(zhǔn)備環(huán)境交叉編譯工具鏈aarch64-linux-gnu-gcc9.3 或 linaro 版本。圖形測(cè)試工具glmark2-es2es2gears。計(jì)算測(cè)試工具clinfo檢查 OpenCL 平臺(tái)和設(shè)備信息vulkaninfo。性能監(jiān)控工具maliocstreamlineperf。AI 推理框架NCNN、TFLite。遠(yuǎn)程管理OpenSSH升級(jí)到新版rsynctmux。不要輕視clinfo的輸出它能一次性把 Mali OpenCL 支持到什么版本、有多少計(jì)算單元、最大 workgroup 多大、本地內(nèi)存多大全部列出來。拿到新板子第一件事就跑clinfo看看Device Name是不是預(yù)期型號(hào)Max compute units是否符合規(guī)格Max work group size是不是 1024 或以上。如果顯示不出 device驅(qū)動(dòng)??隙ㄓ袉栴}。6.2 在板子上建立高效的 GPU 開發(fā)循環(huán)在 ARM 板子上開發(fā) GPU 應(yīng)用和 x86 有個(gè)很大不同編譯速度和調(diào)試工具拉胯。我的經(jīng)驗(yàn)是在 x86 主機(jī)上交叉編譯生成二進(jìn)制后通過 scp/sftp 拷到板子。板子上只放運(yùn)行時(shí)庫和測(cè)試腳本把 sshfs 用起來代碼目錄直接掛載到板子本地。每次修改 shader 或 host 代碼后用一條腳本直接編譯、拷貝、運(yùn)行、收集日志。可以參考這樣一條自動(dòng)化腳本思路偽代碼#!/bin/bash # 在 x86 主機(jī)上運(yùn)行 aarch64-linux-gnu-g -o test_app test.cpp \ -I/path/to/OpenCL/include -L/path/to/libmali -lOpenCL scp test_app userboard:/home/user/ ssh userboard /home/user/test_app關(guān)鍵心得在 ARM 板子上安裝的編譯器未必比交叉編譯器差對(duì)于小項(xiàng)目甚至直接板端編譯更省心。但大項(xiàng)目強(qiáng)烈建議交叉編譯。6.3 可靠性優(yōu)先Mali 的電源管理可不是鬧著玩的Mali GPU 的功耗管理由內(nèi)核態(tài)的mali_devfreq控制。如果板子的 devfreq 策略沒配好高負(fù)載任務(wù)一上來頻率會(huì)劇烈波動(dòng)帶來畫面卡頓甚至 crash。檢查當(dāng)前 GPU 頻率cat /sys/class/devfreq/ff9a0000.gpu/cur_freq如果這個(gè)路徑不存在說明驅(qū)動(dòng)可能沒有啟用 devfreq或者設(shè)備樹里的 GPU 節(jié)點(diǎn)沒有正確描述。想限制最大頻率以降低發(fā)熱可以echo 600000000 /sys/class/devfreq/ff9a0000.gpu/max_freq單位是 Hz這里的 600000000 就是 600MHz具體數(shù)值取決于板卡的頻率表。經(jīng)驗(yàn)之談做穩(wěn)定性測(cè)試時(shí)一定要在真實(shí)散熱條件下壓測(cè)至少 24 小時(shí)因?yàn)?Mali GPU 在高溫下會(huì)觸發(fā)降頻和 job timeout這兩種情況的表現(xiàn)截然不同降頻是性能下降timeout 是直接 crash。7. 常見問題速查表與避坑清單以下是我實(shí)際項(xiàng)目里最常碰到的問題和解決方案匯總做成一張速查表方便查閱現(xiàn)象可能原因解決思路程序啟動(dòng)報(bào)libmali.so: cannot open shared object fileLD_LIBRARY_PATH 未設(shè)置或庫路徑不對(duì)用find / -name libmali.so 2/dev/null找實(shí)際位置再 export系統(tǒng)啟動(dòng)后屏幕黑屏或閃爍內(nèi)核模塊與用戶態(tài) DDK 版本不匹配從 BSP 供應(yīng)商獲取統(tǒng)一驅(qū)動(dòng)包不要混用clinfo顯示不了 Mali 設(shè)備OpenCL ICD 未注冊(cè)檢查/etc/OpenCL/vendors/下是否有 mali.icd 文件內(nèi)容應(yīng)為libmali.so的絕對(duì)路徑Vulkan 初始化失敗Vulkan loader 與驅(qū)動(dòng)不匹配裝vulkan-tools后運(yùn)行vulkaninfo --summary確認(rèn) driver 版本GPU crash dump 頻繁shader 越界或驅(qū)動(dòng)超時(shí)用 malioc 靜態(tài)分析 shader降低優(yōu)化等級(jí)檢查 buffer 大小推理框架跑起來比 CPU 還慢算子沒有真正走 GPU或者走了但拷貝開銷過大用GpuDelegate/NCNN_VULKAN的 debug 版本打印實(shí)際后端檢查 buffer 是否做了零拷貝系統(tǒng)卡頓CPU 占用不高但整體響應(yīng)慢GPU 內(nèi)存帶寬占用過高降低分辨率減少重復(fù)紋理讀取優(yōu)化 shader 帶寬訪問交叉編譯程序在板子上段錯(cuò)誤工具鏈 ABI 或庫版本不匹配readelf -A 程序查看 Tag_ABI_VFP_args確認(rèn)浮點(diǎn) ABI銀河麒麟升級(jí) openssh 后無法登錄sshd 配置文件權(quán)限或上下文不對(duì)恢復(fù)/etc/ssh/sshd_config權(quán)限為 600restorecon -v /etc/ssh/sshd_config高溫下長時(shí)間跑 GPU 作業(yè)崩潰散熱不足觸發(fā)降頻或 job timeout優(yōu)化散熱設(shè)計(jì)限制 max_freq或加大驅(qū)動(dòng) watchdog 超時(shí)參數(shù)還有一些值得寫進(jìn)項(xiàng)目記錄的避坑經(jīng)驗(yàn)不要在用戶態(tài)庫版本不明的情況下直接替換 libmali.so。建議備份并用strings查看內(nèi)嵌版本號(hào)。OpenCL buffer 的分配要一次性到位。Mali 的 user pointer 方式?jīng)]法保證物理連續(xù)共享內(nèi)存場(chǎng)景下性能衰退嚴(yán)重。盡量少在 GPU 和 CPU 之間做頻繁同步。每次 clFinish 都是一次全局屏障把多個(gè) kernel 串成一個(gè) pipeline用 event 來做依賴管理。RGBA8888 紋理不一定比 RGBA4444 慢。Mali 對(duì)非 8 位格式的壓縮支持很糟純性能考慮反而推薦標(biāo)準(zhǔn)格式。設(shè)備樹里 GPU 的 interrupt 配置錯(cuò)了驅(qū)動(dòng)能加載但跑任務(wù)必崩。拿到板子先確認(rèn) dmesg 里沒有mali: IRQ 63 cant request IRQ這種字樣。我在實(shí)際使用中發(fā)現(xiàn)花時(shí)間搞清楚設(shè)備和驅(qū)動(dòng)棧的匹配關(guān)系比盲目?jī)?yōu)化 shader 收益大得多。Mali GPU 的 26 條經(jīng)驗(yàn)踩坑一半都跟驅(qū)動(dòng)版本有關(guān)。最后再分享一個(gè)小技巧每次拿到新開發(fā)板我都習(xí)慣先記錄三樣?xùn)|西——內(nèi)核版本uname -a、Mali 內(nèi)核模塊版本modinfo mali | grep version、用戶態(tài)庫的 md5 值md5sum /usr/lib/aarch64-linux-gnu/mali/libmali.so。后面不管出了什么問題拿著這三個(gè)信息去搜效率高得不是一點(diǎn)半點(diǎn)。ARM Mali 這套體系只要掌握了架構(gòu)脈絡(luò)、驅(qū)動(dòng)匹配、工具鏈選型和計(jì)算資源邊界就能在邊緣設(shè)備上做出穩(wěn)定可用的東西。希望這篇能幫你少流幾次汗有具體問題歡迎在評(píng)論區(qū)繼續(xù)聊。