1. 在搜索引擎里输入“ARM Mali GPU links”你真正需要的是什么我先说个真实经历。前几年给一块国产 ARM 开发板做视觉推理项目时我在搜索引擎里翻来覆去搜“ARM Mali GPU links”结果出来的东西特别分裂有 Arm 官方的 OpenCL 用户指南 PDF有某个论坛里的libmali.so下载链接有人在问export LD_LIBRARY_PATH/usr/lib/aarch64-linux-gnu/mali:$LD_LIBRARY_PATH为什么不管用还有人直接把 PyTorch 的 CUDA 安装教程甩过来。说实话当时我差点被这些碎片信息带偏。“Mali GPU”大家都不陌生手机、电视盒子、开发板、工控机里到处都是但“links”这个词放在标题里其实有两层意思。第一层是字面意义上的“资源链接”跟 Mali 相关的驱动、文档、开源项目分散得到处都是缺一个主线把它们串起来。第二层是软件工程意义上的“链接”你写的程序最终要跟libmali.so动态链接才能调用 OpenCL、Vulkan 这些接口。可以说谁把这两层“links”搞明白了谁就算入了 Mali 开发的门。这篇文章就是干这个的以 ARM Mali GPU 为主线把驱动安装、计算 API、AI 推理、交叉编译工具链这些最常踩坑的地方整理成一条可以照着走的路。适合正要给嵌入式 Linux 平台做 GPU 计算或者模型部署的朋友也适合从 x86 GPU 服务器转过来、但对 ARM 生态不太熟的人。我不保证每个板子的细节都一致但大的方向和坑基本是通用的。1.1 一个尴尬的事实Mali GPU 不缺性能缺的是“入口”先讲个小故事。以前实验室里一台 GPU 服务器跑着 CUDA 程序一切都很顺利。后来有个项目要下放到嵌入式设备上团队大部分人第一反应是“继续用 PyTorch改一改就行”。结果一查ARM 平台上的 Mali GPU 根本不支持 CUDA官方也没提供 PyTorch 的 Mali GPU 后端。准备了两天的方案第一天就废了。这就是 Mali 生态最尴尬的地方。论硬件规模Mali 系列出货量非常大但大部分设备只是用它来渲染手机界面和游戏真正拿它做通用计算、跑 AI 推理的人少很多。Arm 确实提供了 OpenCL 和 Vulkan 的驱动接口可每一个板子的 BSP 动不动就是定制的libmali有的带 X11 支持有的走 GBM有的只有 OpenCL 1.2有的支持 Vulkan 1.2。这种碎片化直接导致了一个结果关于“怎么把我的程序跑在 Mali GPU 上”的资料永远是一堆零散帖子而不是一套完整文档。所以不要指望找到一个统一入口。你要做的第一件事是搞清楚手上的 SoC 是哪一代 Mali 架构BSP 里提供了哪个版本的libmali.so系统里加载的是哪个内核驱动。这几个问题直接决定了后面所有技术选型。1.2 把 links 理解为三重关系我一般把 Mali 开发中的“links”拆成三个层面来看第一层是硬件和软件的连接。Mali GPU 不是独立显卡它跟 CPU、内存、总线都集成在同一个 SoC 里没有独立显存也没有 BIOS 里那种设备管理界面。你能控制的只有内核驱动节点和用户态库。第二层是用户程序与驱动库的连接。Mali 在 Linux 下通常不采用 x86 平台上那套“内核模块 /dev 驱动 独立用户态 SDK”的做法。它会把 EGL、OpenGL ES、OpenCL、Vulkan 这些 API 的实现统统塞进一个libmali.so里。你的程序通过-lOpenCL链接到的那个libOpenCL.so通常只是libmali.so的一个符号链接。这个设计虽然很灵活但也导致了很多“链接”层面的坑。第三层是资源与项目的连接。比如你要部署 YOLOv8可能会用到 NCNN要跑大模型会考虑 Ollama要做算子加速会碰到 Arm Compute Library。这些项目和 Mali 的关系、集成方式、官方支持程度都不一样。后面我专门用一章讲这块因为太多人在这里浪费了时间。先把这三层关系放在心里后面的内容就好理解了。2. 驱动安装与动态链接libmali 是绕不过去的入口在 Mali 的 Linux 生态里90% 的问题都出在驱动没配对、库路径没找对、或者内核驱动冲突上。所以这一章必须把 libmali 和动态链接机制讲透否则后面所有程序都跑不起来。2.1 libmali 不是普通驱动而是一坨用户态库先纠正一个常见误解。很多人一听到“GPU 驱动”就以为像 Windows 下装个 NVIDIA 驱动包那样装完就有了。Mali 在嵌入式 Linux 上的驱动是分两部分的一部分是内核里的mali内核模块负责管理 GPU 硬件、提供/dev/mali这样的设备节点另一部分是用户态库libmali.so里面实现了 OpenGL ES、OpenCL、Vulkan 这些 API 的实际逻辑。也就是说你的应用程序调用clGetPlatformIDs时并不会直接跟内核打交道而是先进入libmali.so再由它通过 ioctl 机制下发到内核模块。这跟 x86 上 OpenCL 的加载方式在原理上类似但在嵌入式平台很容易出错如果你的用户态库和内核驱动版本不匹配程序可能直接崩溃甚至没有任何报错。那为什么网上大量教程里一句“export LD_LIBRARY_PATH...”被反复贴因为很多 BSP 会把多个libmali变体放在不同的目录里比如/usr/lib/aarch64-linux-gnu/mali/下面可能有好几个文件系统默认加载的却是/usr/lib/aarch64-linux-gnu/libmali.so。当你需要切换某个变体时最粗暴的办法就是把这个目录加到动态链接器的搜索路径里。2.2 那条反复出现的 LD_LIBRARY_PATH 命令到底在干什么直接看命令export LD_LIBRARY_PATH/usr/lib/aarch64-linux-gnu/mali:$LD_LIBRARY_PATH动态链接器在程序启动时会按一定顺序查找需要的共享库LD_LIBRARY_PATH是一个优先级很高的用户自定义搜索路径。把 Mali 的库目录放在它前面本质上是告诉系统优先从这个目录里找libOpenCL.so、libmali.so、libEGL.so这些库。我建议你只把这条命令当作临时调试手段。因为它有两个问题一是全局环境变量会影响到你启动的所有程序如果目录里某个库版本不对其他程序也可能跟着遭殃二是它不持久重启后失效。更稳的持久化做法是写一个/etc/ld.so.conf.d/mali.conf文件内容就是那个目录路径然后执行sudo ldconfig。这样动态链接器会在系统级别记住这个路径不需要每次手动 export。另外要检查一下目录里的符号链接。常见板卡上至少应该有这几个文件libOpenCL.so - libmali.so libEGL.so - libmali.so libGLESv2.so - libmali.so libmali.so如果libOpenCL.so指向的是一个不存在的目标或者干脆缺了这个链接文件那你就算设置了LD_LIBRARY_PATH程序也会报“cannot find -lOpenCL”。2.3 确认 GPU 是否真的活动clinfo / vulkaninfo / dmesg很多人在写完 OpenCL 程序后一运行就崩溃然后怀疑代码。其实问题很可能出在前置环节GPU 驱动的设备节点根本没出现或者用户态库加载了错误版本。我建议按照这一套顺序检查。第一步看内核模块和设备节点lsmod | grep -E mali|panfrost ls -l /dev/mali* dmesg | grep -i mali如果看到/dev/mali0或者/dev/mali存在说明内核侧驱动基本就位。如果只有/dev/dri/renderD128那内核加载的很可能是开源的 panfrost 驱动。再执行sudo dmesg | tail -50确认有没有类似 “Probed.” 或者 “firmware loaded” 的日志。如果出现资源冲突、中断注册失败说明设备树配置或内核模块有问题。第二步验证用户态计算接口。安装clinfo或者vulkan-tools后执行clinfo vulkaninfo --summaryclinfo能列出 OpenCL 平台和设备vulkaninfo能看到 Vulkan 设备属性。这里要特别强调如果你的系统同时加载了 panfrost 和 libmaliclinfo极大概率会报错因为 OpenCL 驱动需要在设备节点上完成初始化而 panfrost 和 mali 内核模块会争抢同一个 GPU 硬件。遇到这种情况要么卸载 panfrost要么把 Mali 内核模块加入黑名单二选一不能共存。2.4 驱动加载失败的排查链路我把实际遇到的故障按频率排了个序遇到问题可以直接照着查第一内核驱动和用户态库版本不匹配。比如 BSP 刷了新版固件但/usr/lib/aarch64-linux-gnu/mali/libmali.so还是老版本。查法是对比 BSP 发布文档里的版本号和特性或者直接看 dmesg 里有没有 “Version mismatch” 字样。第二设备树没有正确配置。某些开发板默认使用开源 panfrost 驱动设备树里没有打开 Mali 的 proprietary 驱动节点。这时候需要修改设备树或引导参数启用对应的mali节点。第三用户态库变体选错。有的 BSP 会把 libmali 拆成libmali-bifrost-gbm.so、libmali-bifrost-x11.so、libmali-valhall-gbm.so等。如果你的显卡要跑 Wayland却选了一个 X11 的变体就会出现“能初始化 OpenCL 但创建 EGL 上下文失败”这种奇怪问题。建议先确认显示协议再选择对应变体。第四库路径干扰。如果系统里有多个libOpenCL.so比如某个 SDK 自带了一个而 BSP 也有一个手动设了LD_LIBRARY_PATH反而可能让程序加载到错误版本。我一般用ldd ./my_program看程序到底链接了哪个库。第五权限问题。某些旧系统上/dev/mali的权限是 root:root普通用户无法打开。测试时最直接的办法是临时chmod 666 /dev/mali生产环境更好的是写一个 udev 规则。3. 通用计算接入OpenCL 与 Vulkan Compute 的选择驱动通了之后下一个问题就是“程序怎么写”。这一章只讨论真正的 GPU 通用计算也就是让人工智能、图像处理、科学计算这些任务跑在 Mali 的并行单元上。这里有一条非常关键的原则不要等 CUDA因为永远不会来。3.1 别等 CUDAMali 只认 Khronos 系 APIMali GPU 的底层架构决定了它只支持 Khronos 组织定义的开放标准本质上是 OpenGL ES、OpenCL、Vulkan 这一套。Arm 没有提供也不需要提供 CUDA。所以你的项目里但凡写着cudaMalloc、__global__这类代码到了 Mali 平台上全都得换掉。对大多数通用计算场景我建议优先用 OpenCL。理由很简单OpenCL 的生态资料相对多一些代码结构也更接近 CUDA 的“平台-设备-上下文-命令队列”思维模型从 NVIDIA 转过来的人比较容易理解。Vulkan Compute 当然也可以性能上也不差但它的编程模型更偏底层初始化代码特别长对于只想做并行计算的人来说学习成本高了不少。不过要注意Mali 各代架构的 OpenCL 支持能力很不一样。简单整理一下Mali 架构代际代表型号常见计算 API 支持UtgardMali-400/450基本只能做 OpenGL ES几乎没有可用的 OpenCL 实现MidgardMali-T6xx/T7xx/T8xxOpenCL 1.1/1.2部分支持 OpenCL 2.xBifrostMali-G31/G51/G71/G76OpenCL 1.2/2.0Vulkan 1.0/1.1ValhallMali-G57/G77/G78/G610/G710OpenCL 2.0/3.0Vulkan 1.1/1.2这里要提醒一句最终支持到什么程度不是 Arm 一家说了算。很多 SoC 厂商出于发布节奏考虑BSP 里的 libmali 可能只实现了 OpenCL 1.2哪怕硬件本身能跑更高版本。所以写代码前先用clinfo看清楚CL_PLATFORM_VERSION和CL_DEVICE_OPENCL_C_VERSION。3.2 最小 OpenCL 示例与交叉编译命令下面这段代码是典型的 OpenCL 启动模板作用是读取 CPU 传入的数组在 GPU 上做一次加 1 操作。它包含了初始化、编译、建 buffer、执行 kernel、回读结果的全流程。#include CL/cl.h #include stdio.h #include stdlib.h const char *source __kernel void add_one(__global int *data) { int i get_global_id(0); data[i] 1; }; int main(void) { cl_platform_id platform; cl_device_id device; cl_context context; cl_command_queue queue; cl_program program; cl_kernel kernel; cl_mem buffer; cl_int err; int data[4] {1, 2, 3, 4}; size_t count 4; err clGetPlatformIDs(1, platform, NULL); err | clGetDeviceIDs(platform, CL_DEVICE_TYPE_GPU, 1, device, NULL); context clCreateContext(NULL, 1, device, NULL, NULL, err); queue clCreateCommandQueue(context, device, 0, err); program clCreateProgramWithSource(context, 1, source, NULL, err); err clBuildProgram(program, 1, device, NULL, NULL, NULL); kernel clCreateKernel(program, add_one, err); buffer clCreateBuffer(context, CL_MEM_READ_WRITE | CL_MEM_COPY_HOST_PTR, sizeof(data), data, err); clSetKernelArg(kernel, 0, sizeof(cl_mem), buffer); clEnqueueNDRangeKernel(queue, kernel, 1, NULL, count, NULL, 0, NULL, NULL); clEnqueueReadBuffer(queue, buffer, CL_TRUE, 0, sizeof(data), data, 0, NULL, NULL); for (int i 0; i 4; i) printf(%d , data[i]); printf(\n); clReleaseMemObject(buffer); clReleaseKernel(kernel); clReleaseProgram(program); clReleaseCommandQueue(queue); clReleaseContext(context); return 0; }如果是在板子本地用 GCC 编译命令很简单gcc -o opencl_demo opencl_demo.c -I/usr/include -lOpenCL关键是链接参数-lOpenCL。在 Mali 板上它最终会解析到libOpenCL.so也就是libmali.so的符号链接。如果头文件不在/usr/include/CL记得用-I指定目录。交叉编译时命令会变成这样aarch64-linux-gnu-gcc -o opencl_demo_arm64 opencl_demo.c \ -I/path/to/CL-headers \ -L/path/to/mali-libdir \ -lOpenCL3.3 验证与性能陷阱跑起来之后先别急着上真实业务。我建议先写一个小测试反复计算同一个 kernel 的执行时间同时用dmesg观察有没有 GPU 相关的异常。这里有个容易忽略的点Mali GPU 和 CPU 共享内存但 OpenCL 是支持内存对象的。如果你每次 kernel 调用都频繁地写回 CPU 读取带宽很容易成为瓶颈。实测下来一个很小的 kernel 如果只有 1ms 执行时间但数据拷贝占 10ms那整体性能感知会非常差。另一个经典陷阱是clBuildProgram报错但不打印日志。OpenCL 规范允许你把 build 日志取出来但很多教程没写。建议加一段size_t log_size 0; clGetProgramBuildInfo(program, device, CL_PROGRAM_BUILD_LOG, 0, NULL, log_size); char *log malloc(log_size); clGetProgramBuildInfo(program, device, CL_PROGRAM_BUILD_LOG, log_size, log, NULL); printf(%s\n, log);否则遇到 kernel 里的语法错误你只能看到一个冰冷的CL_BUILD_PROGRAM_FAILURE。4. AI 推理与 LLMPyTorch / Ollama / YOLO 在 Mali 上的适用边界这几年 AI 应用爆发后很多人想把模型部署到 ARM 嵌入式设备上。于是“PyTorch GPU 安装教程”“Ollama 怎么使用 GPU 运行”“GPU 微调大模型”这些词成了热搜。但放在 Mali 平台上这些关键词的含义会发生很大变化。4.1 为什么你搜到的“PyTorch GPU 安装教程”在 Mali 上救不了你先说结论PyTorch 官方的 GPU 支持只面向 CUDA、ROCm 这类后端没有 Mali 后端。你搜到的教程提到pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121这个cu121的意思就是 NVIDIA CUDA 12.1ARM 开发板上装了也找不到设备。那怎么办现实的路线是走 ONNX Runtime、NCNN、TFLite GPU Delegate 这一类框架。TFLite GPU Delegate 在 Mali 上可以基于 OpenGL ES compute shader 或 Vulkan 执行NCNN 也支持 Vulkan 后端ONNX Runtime 则有实验性的 OpenCL execution provider 或通过其他自定义 EP 接入。如果 SoC 还带有 AI 加速器比如常见的是 NPU那也可以把模型切一部分到 NPU一部分留在 GPU不过这属于进阶玩法不展开。简单说在 Mali 上AI 推理的选型是“多种引擎并存”而不是“一个 PyTorch 打天下”。4.2 可以把 YOLOv8 跑起来的路线ONNX - NCNNYOLOv8 是很多嵌入式视觉项目的首选。我之前在 Mali 板子上部署过 YOLOv8n整体链路是这样先安装 ultralytics把权重导出成 ONNXyolo export modelyolov8n.pt formatonnx imgsz640然后用 NCNN 的onnx2ncnn工具转成 NCNN 格式onnx2ncnn yolov8n.onnx yolov8n.param yolov8n.bin接着在 C 工程里用 NCNN 的 Vulkan 后端加载模型。NCNN 会优先尝试调用 Vulkan 设备如果 Mali 的 libmali 提供了 Vulkan 支持通常能成功。没有 Vulkan 的时候NCNN 会自动退到 CPU但那样性能会差不少。这里有个非常重要的实测结论小模型在 Mali 上用 GPU 不一定会比 CPU 快。原因在于 kernel 启动开销和数据搬移开销。比如 YOLOv8n 这种轻量模型输入图像预处理的耗时占比很高GPU 计算本身可能只占一小部分。我实测过几次在 Mali-G610 这类中等性能 GPU 上如果线程调度写得好GPU 确实能跑出优势但如果你只是套了一个现成推理 demo什么都不优化CPU 和 GPU 的差距可能非常小甚至 GPU 更慢。所以别迷信“GPU 一定快”要结合模型大小和实现质量来判断。4.3 Ollama 与大模型真正的限制是带宽不是“显存不够”Ollama 现在很火很多人想在 ARM 开发板上跑 Llama、Qwen 这类模型。但这里要泼一盆冷水Ollama 在 Linux 上的默认后端是 llama.cpp而 llama.cpp 在 ARM 平台上的常规优化是 CPU 的 NEON 指令集不是 Mali GPU。Mac 用户能享受 Metal 加速是因为 llama.cpp 专门做了 Metal 后端NVIDIA 用户能享受 CUDA是因为有 CUDA 后端。但在 Mali 上目前没有一个稳定、开箱即用的主流 GPU 后端。所以你在 Windows 上遇到“Ollama 未使用 GPU”的情况在 Mali 开发板上更常见。这不是你配置错了而是 Ollama 根本没打算调用 Mali GPU。它的官方支持范围内嵌入式 Linux 主要走 CPU。想要在 Mali 上跑大模型更现实的路径是使用支持 OpenCL/Vulkan 的推理框架比如 llama.cpp 的 Vulkan 后端或者其他定制推理引擎。不过这类方案的生态还不够成熟你大概率需要自己编译、自己调参。顺带回应一个热门问题GPU 显存容量是测训练还是推理用的两者都很重要但侧重点不同。推理时显存主要装模型权重、激活值和 KV Cache训练时除了权重还要装梯度、优化器状态往往是推理的几倍。所以“能不能训某个大模型”和“能不能跑某个大模型”是两个完全不同的问题。在 Mali 这种集成 GPU 上没有传统意义的独立显存所有内存都是系统内存所以性能瓶颈更多是内存带宽和 Cache 命中率。4.4 服务器 GPU 运维经验移植到 Mali 前要先改掉什么如果你是从 x86 GPU 服务器运维转过来的比如维护过 NVIDIA 驱动、CUDA 容器、GPU 调度那么到了 Mali 平台有三个习惯要改掉。第一个习惯是“装好驱动就完事”。x86 上 NVIDIA 驱动一般装上后系统会统一管理但 Mali 的驱动高度依赖 BSP刷内核、改设备树、换库版本都是家常便饭。第二个习惯是“用独立显存容量做规划”。x86 服务器上你会问“这张卡显存多大够不够跑模型”。Mali 没有独立显存所以你要看的是系统内存总容量、内存频率和 Mali GPU 的 L2 Cache 大小。带宽不够模型再小也可能跑得不快。第三个习惯是“禁用 GPU 只是设备管理操作”。在 Linux 上禁用 GPU 可以用systemctl mask或者把驱动模块加入黑名单。在 Mali 上你确实也可能暂时禁用 GPU 来排查崩溃比如sudo vim /etc/modprobe.d/blacklist-mali.conf # 写入 blacklist mali但要注意如果禁用后 GPU 节点消失你已经加载的图形环境可能会崩。这种操作适合排查不适合作为常规运维手段。Mali 的 GPU 通常和显示输出共用同一块硬件把它禁了屏幕可能也没了。5. 交叉编译与链接器避坑从工具链选型到动态链接错误嵌入式开发几乎离不开交叉编译。很多人在 Mali 项目里翻车不是因为代码写错而是因为工具链选错、库路径指错、或者 ABI 不匹配。5.1 工具链选型对照表先看一张简洁对照表能省掉很多迷茫你手上的任务正确工具容易选错的东西Linux 用户态程序OpenCL/Vulkan 等aarch64-linux-gnu-gcc或arm-linux-gnueabihf-gcc用 x86 的 gcc 直接编译ARM 上裸机/RTOSCortex-MARM Compiler 5.06 / armclang把 ARM Compiler 当 Linux 编译器用纯计算内核代码调试OpenCL 在线编译用板载 gcc 即可交叉编译 kernel 源码嵌入式汇编优化aarch64-linux-gnu-as/ clang混用不同目标架构的汇编器这里重点说一下 ARM Compiler 5.06。它在热搜里出现频率不低很多人以为是给 ARM Linux 应用程序用的编译器。实际上ARM Compiler 5.06 主要服务于 Cortex-M 这样的裸机或 RTOS 场景典型输出是烧录到 MCU 里的固件而不是跑在 Linux 用户态的可执行文件。而且它现在只能通过 Arm 官方渠道获取下载时需要注册账号并同意许可协议别从来源不明的网盘下。如果你想给 Mali 板子编译 OpenCL 应用用的应该是发行版提供的交叉工具链比如sudo apt install gcc-aarch64-linux-gnu或者直接用板子本地编译。工具链越接近目标系统自带版本出问题的概率越小。5.2 交叉编译 OpenCL 程序的完整命令假设你的项目目录是这样的project/ ├── demo.c ├── CL/ │ └── cl.h └── libmali/ ├── libOpenCL.so - libmali.so └── libmali.so编译命令aarch64-linux-gnu-gcc demo.c -o demo_arm64 \ -I ./CL \ -L ./libmali \ -lOpenCL \ -Wl,-rpath-link,./libmali可能有人会问为什么交叉编译的时候还要加-Wl,-rpath-link因为链接器在解析符号时需要知道libOpenCL.so还依赖哪些库而这些库并不在默认搜索路径里。-rpath-link告诉链接器去哪里找这些间接依赖。直接把-L指过去通常也能生效但写成-rpath-link更保险尤其是在 CMake 项目里链接多个静态库和动态库混用的时候。运行时也要注意把demo_arm64和libmali/目录一起拷贝到板子上然后设置export LD_LIBRARY_PATH/path/to/libmali:$LD_LIBRARY_PATH ./demo_arm645.3 高频链接错误的根因与处理我总结了几个出现频率最高的链接报错直接对照处理cannot find -lOpenCL编译器找不到库文件。检查-L指向的目录里有没有libOpenCL.so。在 Mali BSP 里最常见的情况是目录里只有libmali.so没有创建libOpenCL.so符号链接。手动补一个ln -s libmali.so libOpenCL.solibmali.so: undefined reference to ...这通常不是库本身缺符号而是工具链版本跟 BSP 库的编译环境不一致。比如用太新的 arm64 gcc 链接一个由老版本 glibc 编译的 libmali就会出现符号版本找不到。解决办法是改用 BSP 文档推荐的工具链或者直接上板子用本地编译器。error while loading shared libraries: libOpenCL.so: cannot open shared object file库路径没设置好。优先用ldd demo_arm64查看实际搜索路径再用LD_LIBRARY_PATH或/etc/ld.so.conf.d/mali.conf修正。Exec format error架构不匹配。最常见的是把 aarch64 的二进制放到 32 位 armhf 系统上或者反过来。用file demo_arm64查看目标文件类型再用uname -m确认板子架构能对上。undefined reference to clGetPlatformIDs说明链接时根本没有找到 OpenCL 库。有些人会误把cl.h头文件拿来当库用这是不对的。头文件只负责声明接口真正的实现必须在libOpenCL.so里。6. 资源清单与学习路线的个人建议文章最后我把这条路上真正值得收藏的资源和学习顺序整理出来。不是那种“收藏了就等于学会了”的清单而是我实际用下来觉得有价值的入口。6.1 值得反复看的官方与社区资源Arm 官方文档中最核心的是 Mali GPU 的 OpenCL 开发指南和 Mali GPU Best Practices。前者能让你搞清楚 OpenCL 在 Mali 上的内存模型、workgroup 调度限制后者对纹理、带宽、Cache 命中率这些性能问题讲得比较透。还有 Arm Compute Library这是 Arm 自己维护的高性能计算库底层针对 NEON 和 Mali GPU 做了优化适合图像、矩阵运算这类场景。Khronos 的 OpenCL 官方 spec 和 Vulkan 官方文档也是必看的不过不建议一开始就啃整本。我的方法是先读接口列表遇到不懂的再查具体章节。社区方面Mesa3D 的 panfrost 文档是不错的背景阅读能帮你理解为什么有的板子用开源驱动跑不动计算。NCNN、ONNX Runtime、TFLite 的 GitHub 仓库里有大量针对 ARM 平台的讨论比论坛零散帖子有价值。6.2 学习顺序先通用再平台相关我经常被问到“ARM 架构怎么学”或者“Mali GPU 从哪里入门”。我的建议是三层递进。第一层先建立 ARM 体系结构的基础概念。你不需要立刻精通底层但至少要理解什么是架构代际、什么是 SoC、为什么 GPU 算力要跟内存带宽放一起看。如果你想补课可以看 ARM 处理器体系结构相关的课程或教材比如一些高校公开课还有《ARM 汇编语言实战》这类书虽然它们不会直接讲 Mali但能帮你建立指令集和内存模型的概念。第二层掌握 OpenCL 或 Vulkan 的核心编程模型。在这个阶段建议用你能接触到的任意板卡做实验哪怕手上只有一块老旧的 Mali-T760。跑通一个最小 OpenCL 程序比读十篇文档都管用。第三层再回到具体的 BSP。此时你已经知道 OpenCL 程序长什么样接下来要做的就是把 libmali 选对、把内核驱动调试通、把工具链的坑避开。这时候再看厂商文档你会发现很多之前看不懂的配置参数突然就合理了。6.3 我用得最多的排错顺序最后分享一个我实际调试 Mali 板子时最常用的排错顺序算是给整篇内容收个尾。遇到“程序报错”我第一件事永远是看 dmesg 和 ldd而不是盲目改代码。dmesg 能看到内核驱动有没有报错ldd 能确定程序加载了哪个 libmali。第二步是跑 clinfo 或 vulkaninfo。如果这两个工具都正常说明驱动和库路径大概率没问题问题集中在程序本身。第三步才轮到自己写的代码检查clBuildProgram的 build log检查内存对象的创建标志检查 NDRange 的 workgroup 大小是否符合设备限制。这三步走下来绝大部分问题都能定位。这个顺序帮我节省了大量时间也希望对你有效。