Camera驱动开发与应用开发中的零拷贝与DMA-育师

在嵌入式 Linux 开发中，尤其是在进行音视频处理或边缘 AI 部署时，我们经常会遇到系统卡顿、CPU 占用率飙升的问题。当我们尝试接入高分辨率摄像头（如 1080P 或 4K）并进行实时目标检测或推流时，传统的内存拷贝操作往往会成为整个系统的性能瓶颈。

今天，我们就来深入聊聊系统性能杀手memcpy，以及如何通过 DMA 和 V4L2 零拷贝技术（Zero-Copy）来彻底释放 CPU 算力。

提到CPU参与，主要还是CPU寄存器

很多初学者在处理视频帧时，习惯性地将底层抓取到的图像数据通过memcpy拷贝到应用层，再分发给其他处理模块。我们来算一笔账：一路 1080P NV12 格式的视频流，单帧大小约为 3MB。如果帧率是 30fps，每秒钟产生的数据量高达 90MB。

当我们调用memcpy时，CPU 在微观层面上正在经历一场“灾难”：

纯粹的体力劳动：CPU 并没有在进行任何有价值的算术计算（加减乘除），而是沦为了无情的“数据搬运工”。通过总线将源地址数据读入CPU寄存器，再写回目的地址的物理内存中。
严重的缓存污染 (Cache Pollution)：巨大的像素裸数据会瞬间冲进并占满 CPU 内部极其宝贵的 L1/L2 Cache。这会无情地将我们高频运行的核心业务代码（例如后台运行的 HTTP 转发线程、状态机控制逻辑）挤出缓存，导致系统执行效率雪崩。
榨干总线带宽：3MB 的数据在“DDR -> CPU -> DDR”之间走一个来回，实际占用了 6MB 的总线带宽，导致挂载在总线上的其他外设（如 NPU、GPU）被迫陷入等待。

为了解救 CPU，硬件架构师引入了DMA 控制器。

DMA 相当于系统中的一个独立“外包团队”。当我们开启 DMA 后，CPU 只需要做一件事：向 DMA 写入几个控制寄存器，下达指令（“把源地址 A 的数据搬到目的地址 B，长度为 N”）。

下达完指令后，CPU 就可以立刻转身去处理其他的并发任务。数据的物理搬运工作完全由 DMA 接管，直接在内存和外设之间高速流转。搬运完成后，DMA 会触发一个硬件中断通知 CPU。

除了上述提到的DMA控制器外，在像 RK3588 这样的复杂 SoC（片上系统）中，DMA 并不是由一个单一的“大总管”来做的，而是分为两种形态：

通用 DMA 控制器 (System DMAC，如 ARM 的 PL330)：这是一个通用的搬运工。CPU 可以派它去把内存 A 处的数据搬到内存 B 处，或者负责 UART、SPI 等低速外设的数据传输。它什么都能干，但吞吐量有限。
专用的 DMA Engine (如 ISP 后面的 MI 模块)：它是内嵌（Embedded）在高性能多媒体硬件内部的专属引擎。它是个“单功能特种兵”，不需要通用 DMA 控制器的协助，它自己内部就集成了 DMA 控制逻辑。
- 它的唯一工作：睁开眼就盯着 Main Resizer，Resizer 一吐出 NV12 像素，它就立刻把数据通过 AXI 总线拍进 DDR。它不能用来搬运别的数据，但由于是硬件级强绑定，它的吞吐率极高，延迟极低。

下面我们介绍一下专用DMA Engine相关内容：

这也是一种零拷贝，我将他称之为硬件层面的零拷贝，因为是硬件工程师已经搞好的东西，相当于是写死的东西，我们无法在应用层/驱动改变数据流向。

在我们的Camera架构中，如ISP模块，其中的DMA-engine就是上述内容的实现，这里的ISP后面跟的dma-engine是ISP的专属dma，其实现目标与目的是，在isp将数据写入DDR时不需要经过CPU而直接写入DDR中。

下面说的零拷贝是我们在应用层可以自己配置定义的，可以选择的，与上述不同层面。

假设你要处理一路 1080P 的 NV12 视频流，准备送去进行 RTMP 推流或目标检测：

在“非零拷贝”模式下：

摄像头硬件（ISP/CIF）把图像写入内核空间。
CPU 通过memcpy把这 3MB 数据从内核态拷贝到用户态的应用层变量中。
应用层把这 3MB 数据再次memcpy给编码器（MPP）或推理引擎。结果：仅仅是一路 1080P，CPU 每秒就要做近 200MB 的无效搬运。这会导致极高的延迟（Latency），并迅速耗尽 CPU 算力，导致整个系统发热、卡顿，甚至影响并行的 HTTP 转发线程或其他业务逻辑的调度。

在“零拷贝”模式下：无论图像在各个模块之间怎么流转，这 3MB 的像素数据始终静静地躺在同一块物理内存中。流转的只是一个文件描述符（FD, File Descriptor）或者物理地址指针，CPU 的拷贝开销几乎为 0。

要实现 V4L2 零拷贝，通常是在调用VIDIOC_REQBUFS申请缓冲区时，通过指定不同的memory类型来实现的。常见的有三种：

①V4L2_MEMORY_MMAP（内存映射）

②V4L2_MEMORY_USERPTR（用户指针）

原理：缓冲区由用户态应用程序自行分配（比如通过malloc，或者是其他硬件预先分配好的内存），然后把这块内存的指针（User Pointer）塞给 V4L2 驱动，让摄像头硬件直接往这里面写数据。
局限性：现代硬件（如 NPU 或硬件编码器）通常要求物理地址绝对连续，而malloc出来的内存在物理层面上往往是碎片的。如果不带 IOMMU 的硬件，直接使用 USERPTR 极易引发内存越界奔溃。

③V4L2_MEMORY_DMABUF（DMA 缓冲区共享 —— 真正的全链路零拷贝）

原理：这是目前嵌入式多媒体系统最主流的高阶玩法。DMA-BUF 是一套内核级别的缓冲区共享机制。它把一块连续的物理内存封装成一个 Linux 文件，对外暴露出一个fd（文件描述符）。
工作流：硬件 A（比如摄像头 ISP）分配并导出了一个fd。你用 C++ 代码把这个fd直接传给硬件 B（比如 MPP 编码器）。硬件 B 解析这个fd，通过硬件总线直接去那一块物理内存里拿数据。CPU 在中间只是一个“传递fd整数的信差”。