Android 与 Linux 平台下 DMA-BUF 在端侧 AI 零拷贝管道中的应用

Android 与 Linux 平台下 DMA-BUF 在端侧 AI 零拷贝管道中的应用

在移动端、车载座舱或边缘工控设备上构建多模态 AI 应用（如实时手势识别、AI 超分渲染、自动驾驶目标检测）时，数据流转管道通常包含三个硬件子系统：摄像头采集（Camera ISP/V4L2）$\rightarrow$AI 神经网络推理（NPU/GPU）$\rightarrow$图形渲染与显示（GPU/DRM/SurfaceFlinger）。

在 4K @ 60fps 的视频输入下，一帧未经压缩的 NV12 格式图像大约占据 12MB 内存，每秒产生的数据吞吐量高达 720MB/s。如果数据在各个硬件驱动之间流转时仍然依赖传统的“驱动向用户空间拷贝，用户空间再拷贝给下一个驱动”，不仅会吃满 CPU 负荷，更会导致系统内存总线（DDR Bandwidth）陷入瓶颈、设备发热降频。

Linux 内核中的DMA-BUF（DMA Buffer Sharing）机制，正是为了解决跨异构硬件设备之间共享内存物理缓冲区而生的零拷贝核心标准。

一、 传统内存拷贝与 DMA-BUF 零拷贝管道对比

[传统多重拷贝管道 (CPU 参与搬运)] [Camera ISP 驱动] ──(DMA)──> [内核 V4L2 Buffer] ──(copy_to_user)──> [用户态内存] │ (copy_from_user) ▼ [DRM 显示控制器] <──(DMA)── [内核 Framebuffer] <──(copy_from_user)─ [NPU 推理驱动] -------------------------------------------------------------------------------------- [DMA-BUF 零拷贝管道 (硬件直通共享)] [Camera ISP (Exporter)] ──> 分配连续/离散物理内存 ──> 导出为标准文件描述符 (dma_buf fd) │ ┌───────────────────────────┴───────────────────────────┐ ▼ ▼ [NPU 驱动 (Importer)] [DRM 显示驱动 (Importer)] 通过 fd 映射为 NPU IOMMU 页表 通过 fd 映射为 Display IOMMU 页表 (直接读取同一物理块推理) (直接读取同一物理块送显)

在 DMA-BUF 架构下，物理内存只在内存池（如 ION / CMA / System Heap）中分配一次，随后的所有硬件模块都通过内核传递的dma_buf fd直接建立硬件 IOMMU 映射，全流程 CPU 零拷贝参与。

二、 DMA-BUF 核心内核流转接口与机制

DMA-BUF 的核心思想是将一段物理内存封装为一个struct file，并通过标准的文件描述符fd进行跨进程与跨驱动的传递。

核心流转步骤包括：

1. 导出方（Exporter）创建 Buffer：通过dma_buf_export()将物理页（通常表现为sg_table）封装为dma_buf对象，并用dma_buf_fd()分配给用户态一个整数fd。
2. 传递 fd：用户态通过 Binder、UNIX Domain Socket 或普通系统调用将该fd传给其他设备驱动。
3. 导入方（Importer）挂载与映射：其他驱动调用dma_buf_get(fd)获取对象，调用dma_buf_attach()绑定自身硬件设备，调用dma_buf_map_attachment()将物理页表配置进自身硬件的 IOMMU 中。

以下展示 Importer 驱动核心映射逻辑的 C 代码实现框架：

#include <linux/dma-buf.h> #include <linux/device.h> struct npu_tensor_buffer { struct dma_buf *dmabuf; struct dma_buf_attachment *attachment; struct sg_table *sgt; dma_addr_t npu_dma_addr; }; int npu_import_dmabuf(struct device *npu_dev, int fd, struct npu_tensor_buffer *out_buf) { struct dma_buf *dmabuf; struct dma_buf_attachment *attachment; struct sg_table *sgt; // 1. 根据用户态传入的整数 fd 获取内核 dma_buf 实例 dmabuf = dma_buf_get(fd); if (IS_ERR(dmabuf)) { return PTR_ERR(dmabuf); } // 2. 将 NPU 设备挂载到该 dma_buf 上 attachment = dma_buf_attach(dmabuf, npu_dev); if (IS_ERR(attachment)) { dma_buf_put(dmabuf); return PTR_ERR(attachment); } // 3. 为当前设备的 IOMMU 映射 Scatter-Gather 物理页表 sgt = dma_buf_map_attachment(attachment, DMA_BIDIRECTIONAL); if (IS_ERR(sgt)) { dma_buf_detach(dmabuf, attachment); dma_buf_put(dmabuf); return PTR_ERR(sgt); } // 4. 获取用于硬件直接寻址的 DMA 地址（第一个连续段或首地址） out_buf->dmabuf = dmabuf; out_buf->attachment = attachment; out_buf->sgt = sgt; out_buf->npu_dma_addr = sg_dma_address(sgt->sgl); return 0; // 成功建立硬件级零拷贝映射 } void npu_release_dmabuf(struct npu_tensor_buffer *buf) { if (buf && buf->attachment) { dma_buf_unmap_attachment(buf->attachment, buf->sgt, DMA_BIDIRECTIONAL); dma_buf_detach(buf->dmabuf, buf->attachment); dma_buf_put(buf->dmabuf); } }

三、 硬件同步屏障：DMA-Fence 与 Cache 一致性

当多个异构硬件并发读写同一个 DMA-BUF 时，必须解决两个致命问题：硬件读写时序同步与CPU/DMA Cache 一致性。

1. DMA-Fence 硬件级信号量同步

在没有 CPU 干预的情况下，NPU 不能在 Camera ISP 还没写完一帧数据时就开始推理。Linux 内核通过dma_fence机制实现异步硬件依赖驱动：

• Exporter 驱动在启动硬件 DMA 传输时，向dma_buf附加一个write_fence；
• Importer 驱动（NPU）无需在用户态阻塞等待，直接将该 fence 注册进 NPU 硬件调度器；
• Camera 硬件触发完成中断时，内核自动信号化（Signal）该 fence，NPU 硬件被直接唤醒并立即启动计算。

2. CPU 访问与 Cache 刷新

如果用户态或 CPU 偶尔需要读取 DMA-BUF 中的部分元数据（如 AI 检测到的 Bounding Box 结果），必须显式通知内核同步 Cache：

#include <linux/dma-buf.h> #include <sys/ioctl.h> // 用户态读取前：使 CPU Cache 对应行失效，确保读取到最新的硬件物理内存数据 struct dma_buf_sync sync_start = { .flags = DMA_BUF_SYNC_READ | DMA_BUF_SYNC_START }; ioctl(buf_fd, DMA_BUF_IOCTL_SYNC, &sync_start); // ... 用户态 CPU 读取数据 ... // 读取完毕后释放锁 struct dma_buf_sync sync_end = { .flags = DMA_BUF_SYNC_READ | DMA_BUF_SYNC_END }; ioctl(buf_fd, DMA_BUF_IOCTL_SYNC, &sync_end);

四、 工业级调优收益与工程权衡

在端侧 AI 的工程化落地中，算子性能只决定了计算速度，而DMA-BUF 驱动的零拷贝管道才决定了系统的整机功耗与帧率上限。