ARM Mali GPU开发实战：架构、驱动与AI部署全解析

Mali GPU 这颗藏在 SoC 里的“计算心脏”，这些年我折腾过的架构、驱动和部署问题，值得好好梳理一遍。这篇文章我打算从一个实际开发者的视角，把 ARM Mali GPU 相关的资源、开发工具链、驱动调试和 AI 部署经验一次性讲透，文中涉及的链接和关键词希望帮你少走点弯路。

1. 认识 Mali GPU：架构演进与开发者的第一课

1.1 从 Utgard 到第五代：你手里的 Mali 到底是哪一代

很多新手拿到一块开发板，第一件事就是cat /proc/cpuinfo看 CPU 型号，却常常忽略 GPU 的架构代次。这个信息直接决定了你能用哪个版本的驱动、支持什么图形 API、能不能跑 OpenCL 通用计算。

Mali GPU 家族大概分成这几代：

• Utgard 架构：代表作 Mali-400、Mali-450，广泛用在老款手机和入门级工控板。只支持 OpenGL ES 2.0，OpenCL 支持非常有限，如果没有特殊需求，不建议在这类 GPU 上折腾通用计算。
• Midgard 架构：代表作 Mali-T720、T760、T820、T860、T880。这是目前二手市场和低成本方案里最常见的一代，支持 OpenGL ES 3.1 和 OpenCL 1.1/1.2 的部分特性。我最早做 GPU 调试就是在这代架构上，印象最深的是它的 CoreLink 互联设计，多核扩展时缓存一致性做得不错。
• Bifrost 架构：代表作 Mali-G71、G72、G51、G76。从这代开始，Mali 引入了“quad-based”的 warp 调度思想，Shader Core 内部以 16 线程为一组执行指令，对计算着色器的友好度明显提升。支持 Vulkan 1.0。
• Valhall 架构：代表作 Mali-G57、G77、G78、G68。这代把指令集从 32 位统一到了 64 位，调度器对分支发散的处理更高效。如果搞 AI 推理，Valhall 的 FP16 算力非常可观。
• 第五代（Immortalis 系列）：代表作 Immortalis-G715，主打硬件光线追踪，但这跟大多数嵌入式开发者关系不大，看看就好。

1.2 为什么说 Mali 的驱动模型和 PC 显卡完全不同

在 x86 平台上，NVIDIA 或 AMD 显卡有独立的显存，驱动是一整套完整的二进制栈。而 Mali GPU 用的是统一内存架构（UMA），GPU 和 CPU 共享同一片物理内存，中间没有显存颗粒。

这个特性带来两个直接影响：

• 功耗低、成本低，适合 SoC 集成，但也意味着 GPU 运算会和 CPU 抢占内存带宽。实测经验是：在 4K 分辨率下，GPU 密集任务会把 DDR 带宽吃满，CPU 侧表现会肉眼可见地变卡。
• 驱动不是一个“万能 .exe”。Mali 的 Linux 驱动通常分成三块：内核态的DPP（Display and Pixel Processor）相关模块、内核态的MMU 和 job manager（通常编译进内核或作为模块加载），以及用户态的libmali.so。用户态库需要针对具体的 GPU 型号和 DDK 版本匹配，随手找一个.so拷进去，最典型的结果就是gpu crash dump triggered。

我见过太多项目的坑都出在这条链路上：板子供应商给的内核是 4.19，用户态库却是按 4.4 内核编译的，跑起来毫无征兆地黑屏。排查到最后，居然是 libmali.so 的 EGL 入口和内核模块的 ioctl 版本对不上。

2. 驱动与用户态工具链：交叉编译、库路径和真实部署细节

2.1 Linux 环境下 Mali 驱动的整体结构

在 Linux 系统上，Mali 驱动的典型加载路径是这样的：

• 内核侧：/sys/module/mali/目录存在，说明 Mali 内核模块已加载。
• 设备节点：/dev/mali0是 GPU 的用户态访问入口，没有这个设备节点，用户态库再全也白搭。
• 用户态库：通常位于/usr/lib/aarch64-linux-gnu/或/usr/lib/arm-linux-gnueabihf/，重点文件包括libmali.so（集成了 EGL/GLES/OpenCL 多个入口）、libEGL.so、libGLESv2.so。

说到这要提一个热搜词里反复出现的命令：

export LD_LIBRARY_PATH=/usr/lib/aarch64-linux-gnu/mali:$LD_LIBRARY_PATH

这条命令本身没什么问题，就是让动态链接器优先去 Mali 库所在的目录找库文件。但我必须提醒一句：不要盲目敲这条命令。如果当前系统的 Mali 库实际在/usr/lib/aarch64-linux-gnu/下一个层级，而/usr/lib/aarch64-linux-gnu/mali/这个子目录根本不存在，export 完反而可能因为库路径顺序问题加载到错误的 libmali。

正确的做法是先确认目录存在：

ls /usr/lib/aarch64-linux-gnu/mali/

如果确实没有这个目录，但系统里的 GPU 能正常工作，那就说明库文件直接放在了通用搜索路径里，这时不需要额外设置 LD_LIBRARY_PATH。真正需要设置的场景是交叉编译后把库放在非标准路径，运行时才需要告诉系统去哪里找。

2.2 交叉编译工具链选型：从 ARM Compiler 5 到 GCC

热搜词里出现的“arm compiler 5.06u7 下载”是 ARM 自家提供的商业编译器，有历史包袱的项目（特别是一些闭源第三方库）还在用它。ARM Compiler 5 系列最后的版本是 5.06 update 7，之后的官方支持转向了 ARM Compiler 6（基于 LLVM）。如果你的项目不强制要求 AC5，我强烈建议直接用 GCC 交叉工具链，比如aarch64-linux-gnu-gcc，省心得多。

选工具链时有个点要注意：ARM Compiler 5.06 编译出来的代码默认针对 ARMv7 或 ARMv8 的老 AArch32 模式，而 Mali GPU 用户态驱动多数是 AArch64 库。混用时最好统一目标架构，否则链接阶段会出现莫名其妙的cannot find -lEGL或 ABI 不匹配的报错。

一个实用的排查技巧是使用：

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 都无济于事。

2.3 银河麒麟系统上安装软件的实操（SSH 升级包示例）

热搜词里出现“银河麒麟 ssh 10.3 rpm升级包arm”其实指向一个典型场景：国产化替代环境里的 ARM 服务器，系统自带 OpenSSH 版本偏旧，想升到 10.3，只能找 rpm 包。

这类系统通常是 ARM64 架构，基础安装命令我实测过一套：

sudo rpm -Uvh openssh-10.3p1-1.ky3.arm64.rpm

这里的关键在于-Uvh，它表示升级（-U）、显示详细输出（-v）、显示进度（-h）。直接rpm -ivh安装旧版本没卸载干净时，可能生成两个 sshd 服务，导致 ssh 端口绑定冲突。

另外，在麒麟这类系统上，如果用非 root 用户执行后出现error: can't create transaction lock on /var/lib/rpm/.rpm.lock，多半是权限问题，加 sudo 重试即可。升级完 OpenSSH 后，请一定重启sshd：

sudo systemctl restart sshd

不要直接断开当前的 ssh 连接，先另开一个终端验证新版本 sshd 能正常监听 22 端口，再退出，否则可能把自己锁在门外。

2.4 ARM 系统常用命令工具的补齐

很多从 x86 迁过来的朋友会发现，ARM 板子上iftop、iotop、htop、iperf3这类工具往往没装。这里给一个比较通用的操作思路：

• 对于 Debian/Ubuntu 衍生系统（树莓派 OS、Ubuntu Mate、麒麟也是基于 Debian 体系）：

sudo apt update sudo apt install -y htop iotop iftop iperf3

• 对于使用 yum/dnf 的 ARM 系统（部分 CentOS 移植版、OpenAnolis ARM 版）：

sudo dnf install -y htop iotop iftop

真实遇到的问题往往是源里没有对应 ARM64 的 rpm 包，这时候可以去 EPEL 的 aarch64 仓库找，或者直接从源码编译。uname -m 看一下输出，aarch64就是 ARM64，armv7l是 32 位 ARM。

3. GPU 计算与 AI 推理部署：Mali 在真实项目里的边界

3.1 Mali 跑 GPGPU 的几条路线：OpenCL、OpenGL ES Compute、Vulkan Compute

很多做嵌入式视觉的朋友都问过：Mali GPU 能不能像 NVIDIA 那样跑 CUDA？很遗憾，CUDA 是 NVIDIA 的封闭生态，Mali 上一条都走不通。Mali 可选的通用计算路线大致三条：

• OpenCL：Midgard 以上架构支持不错，适合图像处理、卷积类的并行任务。Mali OpenCL 驱动对 buffer 的分配有严格要求，频繁创建/释放大批量 buffer 会引发严重抖动，正确姿势是复用 buffer。
• OpenGL ES Compute Shader：如果已经有 GLES 渲染管线，混入 compute shader 成本最低，适合后处理特效，不太适合超大计算量。
• Vulkan Compute：Valhall 架构上效率最高，但开发门槛也最高，需要自己管理 Command Buffer 和 Pipeline。如果你跑 NCNN 推理框架，它可以直接切换到 Vulkan 后端来利用 Mali GPU，这也是目前边缘设备上最主流的做法。

用 NCNN 的时候，编译命令关键参数这样写：

cmake -DCMAKE_TOOLCHAIN_FILE=../../toolchains/aarch64-linux-gnu.toolchain.cmake \ -DNCNN_VULKAN=ON \ -DNCNN_OPENMP=ON ..

如果编译好以后运行ncnn_benchmark报错vkCreateInstance failed，大概率是 GPU 驱动和 Vulkan Loader 不匹配，可以用vulkaninfo先检查。

3.2 PyTorch 与 PaddleOCR 的 GPU 部署：哪些能跑哪些别折腾

很多朋友问我“ARM 板子上能不能像 x86 一样装 PyTorch GPU 版”。说实话，PyTorch 在 ARM 平台上对 Mali GPU 几乎没有官方支持。主打推理场景时，更现实的方案是：

• TensorFlow Lite：对 Mali 支持较好，通过gpuDelegate可以在部分算子下调用 OpenCL。
• NCNN / MNN：国内开源框架，对 ARM + Mali 的适配比较积极。
• ONNX Runtime：有 OpenCL execution provider，但算子覆盖有限。

如果在搜 PyTorch GPU 安装教程，注意一点：不要看到 NVIDIA 的教程就往 ARM 上套，如果发现要装 CUDA，那大概率是 x86 教程。真正的 ARM 平台部署推理模型的路线是 onnxruntime + arm 版 so，或者直接用 TFLite。

关于 PaddleOCR 的 GPU 模式，它在 ARM Mali 上最靠谱的一条路是走 NPU（如果 SoC 里有），GPU 模式需要 cudnn 8.5 之类的前提，那都是面向 NVIDIA 的。我实测下来，在 RK3588（Mali-G610）上跑 PaddleOCR 的 ARM CPU 版，用 ONNX Runtime 加多线程，效果比折腾 GPU 稳定，且 ROI 更高。

3.3 大模型微调里的 GPU：Mali 的无奈与出路

热搜词里“gpu微调大模型”也指向当前很火的场景。现实很骨感：Mali GPU 不适合做大模型微调。原因不复杂：大模型微调需要超大显存、高带宽和成熟的张量核心，Mali 统一内存架构撑不起来。

但 Mali 可以做两件事：

• 部署量化后的推理模型：比如在手机上跑 7B 模型，走 4bit 量化，通过 Vulkan compute 调用 Mali 算力，速度虽然没法说“流畅”，但能接受。
• 混合调度：把部分算子放在 GPU，部分放在 NPU，剩下放 CPU，用 NCNN 的流水线做并行。这个对开发者的调度功底要求很高，新手不建议一上来就碰。

3.4 ollama 指定 GPU 和 GPU 租用的经验

ollama 指定 GPU 的场景主要在 Linux x86 服务器上，但这不代表 ARM 完全没机会。如果在 ARM 板子上跑 ollama，我建议直接用官方的 linux-arm64 安装脚本安装，安装完默认走 CPU。如果板子的 NPU 有额外的 runtime，也可以尝试配置，但不要指望 Mali GPU 能直接被 ollama 调用——它没把 OpenCL/Vulkan 纳入主流后端。

GPU 租用这一块补充一句：如果你是做 AI 训练，租带有独立显卡的云主机比本地淘 ARM 板子靠谱得多，成本低、免维护。真正需要本地 Mali 的场景还是边缘推理和图形渲染。

4. 常见问题与排查技巧实录：从 crash dump 到性能调优

4.1 “gpu crash dump triggered”到底是什么

这条让我最头疼也最熟悉：Mali 驱动检测到 GPU 执行出错后，会打印一系列寄存器状态和 dump 信息。触发原因集中在几个点：

• shader 数组越界：最常见。比如 compute shader 里访问 buffer 时下标超出了分配范围。排查手段是使用Mali Offline Compiler（malioc）静态分析，或者打开报错时附带的 shader 索引，核对对应 shader。
• 非法指令或浮点异常：LLVM 编译 OpenCL kernel 时，如果优化级别过高，某些中间表示会引入 GPU 不支持的指令。调低优化级别，或者用-cl-fast-relaxed-math之外的保守编译选项。
• 非法内存访问：用户态 glBufferData 分配的 buffer 太小，shader 访问越界直接命中未映射区域。

出现gpu crash dump triggered后，第一步不是改代码，而是先把 dump 完整保存下来。Mali 驱动会给出类似这样的信息（示意）：

Mali: gpu crash dump triggered Mali: Job fault 0x0013

Job fault后面的十六进制数很关键，不同值对应不同故障类型。查内核头文件mali_kbase_gpu_fault.h能定位到具体错误码。比如 fault 0x0004 是读写非法地址，0x0005 是总线错误，0x0013 是 job 超时。

应对策略一般三步走：

1. 升级用户态驱动到与内核匹配的 DDK 版本。
2. 用malioc检查 shader 的资源占用和非法行为。
3. 简化场景，二分排查哪个 draw call / dispatch 触发崩溃。

4.2 那台 Linux 板子上的“三个 GPU 同时测试”怎么落地

热搜词“linux 三个 gpu同时测试”听起来像是服务器多卡场景，但 ARM 平台上也可能遇到多核 Mali 或 Mali+NPU+GPU 的组合。我分享一个通用方法论：

• 用/dev/mali0的设备句柄区分 GPU 实例，但 Mali 通常是一个 SoC 只有一个 GPU 设备节点。
• 如果是多个 SoC 组成的集群（比如一台主板上集成了多块 RK3588），那就按进程绑定不同的/dev/mali0，用glmark2-es2等工具做并行压力测试，然后通过mali_util和mali_pmu（有性能计数器的板子）看利用率。
• 如果想同时跑 CPU/GPU/NPU 的负载，需要关注总内存带宽，建议用perf stat或likwid这类工具先摸一下 baseline。

如果只是测试单颗 Mali GPU 的稳定性，就用glmark2-es2连续跑几小时，配合温度监控判断散热是否达标：

while true; do glmark2-es2 --run-forever; done

并在另一个终端跑：

watch -n 1 cat /sys/class/thermal/thermal_zone0/temp

如果温度超过 85°C，散热就要加强。

4.3 Linux 禁用 GPU、驱动黑名单和 GPU 调度

有些场景下，我们反而要禁用 GPU。比如在服务器环境里，Mali GPU 的图形功能用不上，还占内存带宽，最简单的做法是：

sudo sh -c 'echo blacklist mali > /etc/modprobe.d/blacklist-mali.conf' sudo reboot

如果想临时卸载驱动模块而不重启：

sudo rmmod mali

不过需要确认没有进程占用 GPU。另外，“GPU调度”在 Mali 语境下一般指 job scheduler 的优先级策略，Mali 驱动默认是按提交顺序排队，但可以通过dma_fence相关机制或者用户态设置优先级。实际调优经验是，在实时视觉场景里，尽量把 GPU job 切小，避免单个大 job 霸占所有 shader core。

4.4 学习资源和“links”的整理

说了这么多，最后把真正有价值的资源链接整理一下（以官方文档名和社区名称为主，搜索时认准这些名字）：

• Mali GPU 官方文档：ARM 官网的 “Mali GPU” 文档中心，包括Arm Mali GPU Best Practices Guide和Mali Offline Compiler User Guide。
• Mali 驱动源码与 DDK：如果从 vendor BSP 里拿不到最新驱动，去 ARM 官网的 “Arm Driver Development Kit (DDK)” 页面注册下载。
• 工具链：Arm Compiler 5.06在官网的下载中心页，注册后可以下载历史版本；免费替代用 Linaro 的gcc-arm-9.2-2019.12。
• 调试工具：Android 平台可以用Mali Graphics Debugger（MGD）；Linux 平台可以用开源工具MaliGPU或配合perf使用内核导出的 PMU 事件。
• 框架层面：NCNN 官方 GitHub 的 README 对 Vulkan 后端有详细编译说明；TFLite 官方文档里有 GPU Delegate 的 ARM 支持列表。
• 性能分析：Streamline Performance Analyzer（配合gatord守护进程），可以采集 GPU 的硬件计数器，这是调优比较标准的路径。
• GPU 模型与规格速查：Ardunix Mali GPU数据库，按 Mali 型号查最大频率、核心数和 API 支持级别，做方案选型时很有用。

5. 从 ARM 汇编到系统级优化：用底层视角理解 Mali 生态

5.1 ARM 汇编入门对 Mali 开发的隐藏价值

很多人觉得写 ARM 汇编和 GPU 开发八杆子打不着。其实 GPU 的 shader 最终也要编译成 GPU 指令，而驱动和用户态库里的 CPU 部分也跑在 ARM 指令集上。懂一点 ARM 汇编，至少有三个实际好处：

• 能看懂 crash dump 里的 PC 寄存器和调用栈，快速定位是驱动死循环还是应用层非法跳转。
• 调 NEON 优化时，能识别编译器生成的低效指令序列，手动改进向量化策略。
• 理解 AArch64 调用约定（x0-x7 传参，x30 存返回地址），排查 JNI/OpenCL host 端代码时不容易懵。

入门路线我建议：先看 ARM 官方《ARM Architecture Reference Manual》的 AArch64 章节，然后找《ARM 汇编语言实战：从零到精通》这类偏实战的书刷一遍，最后拿objdump -d反汇编实际的 C 代码对比验证。

5.2 教师视角与“期末复习”关键词扯点闲篇

热搜词里有“arm 期末复习”“arm处理器体系结构及其应用 电子科技大学”，说明不少学生朋友也在查资料。如果你想快速建立知识框架，我建议按“体系结构 → 指令集 → MMU/Cache → 异常模型 → 启动流程（BL31/U-Boot）→ 外设/GPU”这条链路复习。后面提到的arm bl31 uboot就是启动流程中非常关键的两个环节：BL31 是 ARM Trusted Firmware 的运行时 EL3 固件，U-Boot 负责拉起内核。

学习过程中多数人都会在 MMU 这块卡壳。Mali GPU 在这方面其实给了很好的参照物：GPU 也有自己的 MMU，叫Mali MMU，它负责把 GPU 的虚拟地址翻译成物理地址，和 CPU 侧 MMU 的原理高度相似。

5.3 使用 malioc 分析 shader，找到性能瓶颈

Mali 平台和 NVIDIA 不一样，没有 nsight 这类图形化分析工具，但Mali Offline Compiler（malioc）是命令行神器。它可以不跑真机，直接编译 shader（GLSL/OpenCL C），输出寄存器占用率、workgroup 大小建议、内存访问模式分析等。

一个典型的分析命令：

malioc -v shader.frag

关键输出项：

• Work register count：每个线程占用的寄存器数。太高会降低 occupancy，太低可能导致 spilling。
• Uniform register count：uniform 缓存占用。
• Stack size：如果过大，需要减少局部变量或拆小函数。
• Cycle estimates：不同 Mali 架构下的模拟时钟周期数。

实测中我发现，很多性能问题根本不是 shader 数学太复杂，而是寄存器溢出导致本地内存访问暴涨。malioc 一下就能看出端倪。

5.4 一例真实优化：图像模糊滤镜的 OpenCL 提速

以 3x3 均值模糊为例，最容易写出的一种写法是每个像素都去读周边 9 个点，这会让内存读取量是理论值的 9 倍。简单优化是改用行缓存（line buffer）：每个 work-item 处理一行像素，把读到的数据缓存到 local memory，横向滑动时只读新像素。

在 Mali GPU 上，这个改动通常能把性能提升 3~5 倍。原因是 Mali 的 L1 cache 对线性访问比较友好，local memory 有专门的高速通路。

• 优化前：大量随机访问，L1 cache miss 率高。
• 优化后：顺序访问 + local memory 复用，吞吐量大幅提升。

这个过程需要的知识正好是所有热搜词串联起来的：理解 Mali 的架构（第 1 章）、会编译和部署驱动（第 2 章）、有 OpenCL 开发经验（第 3 章）、会做性能分析和排查（第 4 章）。

6. 实操心得：把零散知识串成可落地的开发流程

6.1 必备工具包和软硬件清单

我通常在接触一个新的 ARM + Mali 板卡时，会按下面这个清单准备环境：

• 交叉编译工具链：aarch64-linux-gnu-gcc9.3 或 linaro 版本。
• 图形测试工具：glmark2-es2，es2gears。
• 计算测试工具：clinfo（检查 OpenCL 平台和设备信息），vulkaninfo。
• 性能监控工具：malioc，streamline，perf。
• AI 推理框架：NCNN、TFLite。
• 远程管理：OpenSSH（升级到新版），rsync，tmux。

不要轻视clinfo的输出，它能一次性把 Mali OpenCL 支持到什么版本、有多少计算单元、最大 workgroup 多大、本地内存多大全部列出来。拿到新板子第一件事就跑：

clinfo

看看Device Name是不是预期型号，Max compute units是否符合规格，Max work group size是不是 1024 或以上。如果显示不出 device，驱动栈肯定有问题。

6.2 在板子上建立高效的 GPU 开发循环

在 ARM 板子上开发 GPU 应用和 x86 有个很大不同：编译速度和调试工具拉胯。我的经验是：

• 在 x86 主机上交叉编译，生成二进制后通过 scp/sftp 拷到板子。
• 板子上只放运行时库和测试脚本，把 sshfs 用起来，代码目录直接挂载到板子本地。
• 每次修改 shader 或 host 代码后，用一条脚本直接编译、拷贝、运行、收集日志。

可以参考这样一条自动化脚本思路（伪代码）：

#!/bin/bash # 在 x86 主机上运行 aarch64-linux-gnu-g++ -o test_app test.cpp \ -I/path/to/OpenCL/include -L/path/to/libmali -lOpenCL scp test_app user@board:/home/user/ ssh user@board "/home/user/test_app"

关键心得：在 ARM 板子上安装的编译器未必比交叉编译器差，对于小项目甚至直接板端编译更省心。但大项目强烈建议交叉编译。

6.3 可靠性优先：Mali 的电源管理可不是闹着玩的

Mali GPU 的功耗管理由内核态的mali_devfreq控制。如果板子的 devfreq 策略没配好，高负载任务一上来频率会剧烈波动，带来画面卡顿甚至 crash。

检查当前 GPU 频率：

cat /sys/class/devfreq/ff9a0000.gpu/cur_freq

如果这个路径不存在，说明驱动可能没有启用 devfreq，或者设备树里的 GPU 节点没有正确描述。想限制最大频率以降低发热，可以：

echo 600000000 > /sys/class/devfreq/ff9a0000.gpu/max_freq

单位是 Hz，这里的 600000000 就是 600MHz，具体数值取决于板卡的频率表。经验之谈：做稳定性测试时，一定要在真实散热条件下压测至少 24 小时，因为 Mali GPU 在高温下会触发降频和 job timeout，这两种情况的表现截然不同（降频是性能下降，timeout 是直接 crash）。

7. 常见问题速查表与避坑清单

以下是我实际项目里最常碰到的问题和解决方案汇总，做成一张速查表方便查阅：

还有一些值得写进项目记录的避坑经验：

• 不要在用户态库版本不明的情况下直接替换 libmali.so。建议备份并用strings查看内嵌版本号。
• OpenCL buffer 的分配要一次性到位。Mali 的 user pointer 方式没法保证物理连续，共享内存场景下性能衰退严重。
• 尽量少在 GPU 和 CPU 之间做频繁同步。每次 clFinish 都是一次全局屏障，把多个 kernel 串成一个 pipeline，用 event 来做依赖管理。
• RGBA8888 纹理不一定比 RGBA4444 慢。Mali 对非 8 位格式的压缩支持很糟，纯性能考虑反而推荐标准格式。
• 设备树里 GPU 的 interrupt 配置错了，驱动能加载但跑任务必崩。拿到板子先确认 dmesg 里没有mali: IRQ 63 can't request IRQ这种字样。

我在实际使用中发现，花时间搞清楚设备和驱动栈的匹配关系，比盲目优化 shader 收益大得多。Mali GPU 的 26 条经验踩坑一半都跟驱动版本有关。

最后再分享一个小技巧：每次拿到新开发板，我都习惯先记录三样东西——内核版本（uname -a）、Mali 内核模块版本（modinfo mali | grep version）、用户态库的 md5 值（md5sum /usr/lib/aarch64-linux-gnu/mali/libmali.so）。后面不管出了什么问题，拿着这三个信息去搜，效率高得不是一点半点。

ARM + Mali 这套体系，只要掌握了架构脉络、驱动匹配、工具链选型和计算资源边界，就能在边缘设备上做出稳定可用的东西。希望这篇能帮你少流几次汗，有具体问题欢迎在评论区继续聊。