106、实时影像处理延迟优化：Pipeline流水线与并行加速
去年夏天，我在调试一款车载环视系统的拼接模块时，遇到了一个让人抓狂的问题。摄像头采集帧率是30fps，ISP处理完每帧大概需要28ms，理论上刚好卡在33ms的周期边缘。但实际跑起来，系统每隔几秒就会掉一帧，拼接画面出现明显的撕裂和跳变。我盯着示波器看了整整两天，最后发现罪魁祸首不是某个算法太慢，而是整个处理链路里藏着三个“隐形刹车”——CPU在等GPU释放资源，GPU在等DMA传输完成，DMA又在等上一帧的ISP输出。这种互相等待的连锁反应，才是实时影像系统最大的敌人。
延迟到底藏在哪
很多人一提到延迟优化，第一反应就是“把算法改快”。这当然没错，但在真实的影像系统里，算法计算时间往往只占总延迟的30%到40%。剩下的时间都花在了数据搬运、同步等待和资源竞争上。
拿一个典型的手机拍照Pipeline来说：Sensor输出RAW数据→ISP做Bayer处理→统计模块算AE/AWB→3A算法调整参数→下一帧用新参数采集。这个闭环里，如果ISP处理完一帧后，CPU才去读统计值，那CPU等待的时间就是纯浪费。更糟糕的是，如果3A算法跑在GPU上，GPU调度延迟又会被叠加进来。
我习惯用“延迟瀑布图”来定位问题。把每一帧从Sensor曝光开始，到最终显示输出，按时间轴画出每个模块的起止点。你很快就会发现，那些看起来“很快”的模块，因为启动时机不对，反而成了瓶颈。比如某个降噪算法本身只跑2ms，但它必须等前一个模块完全结束才能开始，中间这1ms的上下文切换和缓存刷新，就是白白丢掉的。
<