从环视到监测：RK3576基于DMA-BUF零拷贝技术的车载双视觉系统

本文为《360环视实时性评估》的续篇：聚焦从原型到车规级实时性的工程落地路径

平台：米尔MYD-LR3576开发板

处理器： RK3576 (4×A72 + 4×A53 + Mali G52 + 6TOPS NPU)

系统：Linux 6.1.75 ｜ 摄像头：4×720P鱼眼 + 1×1080P MIPI RGB

一、问题定义：为什么传统OpenCV管线「跑不动」

在360环视系统的初始验证阶段，我们采用了一套直观且广泛使用的技术栈：OpenCV负责从采集到显示的全部图像处理任务。功能层面，这套方案完全跑通了——四路鱼眼去畸变、透视投影、鸟瞰拼接，所有算法逻辑均正确。但当我们将目光从「能不能跑」转向「能不能用」时，一个严峻的问题浮出水面：端到端延迟高达约300ms，远超25fps对应的40ms帧预算。

经过深入的性能剖析，我们发现瓶颈的根源并非算法复杂度——RK3576的4核Cortex-A72在单纯的计算吞吐上并非不堪重负。真正吃掉时间的，是全链路中密集且不必要的数据搬运。以下为原始方案的典型数据流：

上述五步中，每一步都产生至少一次全帧内存拷贝（720P BGR约2.6MB/帧）。四路相机并行处理后，单帧处理周期的总数据搬运量超过50MB。在一个40ms的帧预算里，光是内存拷贝就占据了不可忽视的时间比例，这还不包括OpenCV函数内部的中间缓冲分配。

1.1 GPU加速的尝试与局限

为突破CPU的性能瓶颈，我们尝试将计算密集型环节（去畸变、投影变换、拼接）迁移至Mali-G52 GPU，通过OpenCL（cv::UMat）并行加速。GPU的算力优势立竿见影——去畸变从CPU的约10ms降至约1ms，投影变换从约30ms降至约8ms。但是cv::Mat与cv::UMat间的显式搬运（约15ms上传 + 10ms下载）几乎抵消了计算加速。

1.2 核心矛盾：算力够，数据搬运不够

算力充裕，但“每步独立分配、独立拷贝”的范式使数据搬运成为绝对瓶颈。优化方向由此明确——不是换更强的算法，而是消灭拷贝本身。

二、优化路线总览：从「能跑」到「能用」

基于对问题根因的准确诊断，我们确立了一条清晰的优化路线：用DMA-BUF文件描述符（fd）替代内存拷贝，让V4L2、RGA、CPU和DRM四者共享同一块物理内存；用DRM Ove...