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 整数的信差"。