009、影像系统DDR带宽分配策略：多摄并发与AI算法同时运行时的带宽争抢与优化

009、影像系统DDR带宽分配策略：多摄并发与AI算法同时运行时的带宽争抢与优化

去年年底在给某款旗舰机型调双主摄+AI夜景模式的时候，遇到一个特别诡异的现场问题。相机预览界面在切换镜头的那一瞬间，画面会卡顿大概三百毫秒，但更致命的是，后台同时跑着的人脸检测框直接“飞”了——检测框的坐标和实际人脸位置差了半个屏幕。一开始我们怀疑是传感器同步问题，查了三天，最后用总线监测工具一看，DDR带宽在切换瞬间被拉到了95%以上，CPU和NPU的请求全部被堵在队列里，ISP的line buffer直接饿死，画面断层就是这么来的。

这个问题其实特别典型，多摄并发加AI算法同时跑，本质上是把DDR带宽当成一个共享的“水管”，谁都想多吸一口，但水管就那么大。高通Spectra、联发科Imagiq、海思ISP，各家对带宽的管理思路完全不一样，但底层逻辑是相通的——你得知道谁在吃带宽，吃多少，什么时候吃，以及怎么让它在关键时候让路。

先掰扯一下影像系统里DDR带宽的消耗大户。第一是ISP本身，尤其是多摄并发的时候，每个sensor都在往DDR里写RAW数据，ISP从DDR里读RAW，处理完再写回YUV或RAW，这中间还有3A统计数据的读写。第二是NPU，跑AI模型的时候，权重和中间特征图都是DDR大户，尤其是那种大分辨率输入的人脸检测模型，一次推理的DDR访问量轻松上GB级别。第三是显示和视频编码，预览要往显示控制器送数据，录像要往编码器送数据，这些虽然单次访问量不大，但频率极高，而且有实时性要求，卡一帧就是掉帧。

多摄并发的时候，带宽争抢最激烈的地方其实在ISP的写回阶段。比如双摄同时出图，两个ISP pipeline都在往DDR里写RAW，如果平台的总线仲裁策略是公平轮询，那每个ISP分到的带宽就是一半，看起来公平，但实际上一旦NPU开始跑模型，它的大块burst访问会直接把总线占满，ISP的写回请求被无限期延后，导致ISP内部buffer溢出，只能丢帧或者等下一帧。这里踩过坑——别指望硬件总线仲裁能自动解决优先级问题，它只保证不饿死，不保证实时性。

高通Spectra平台的做法是引入了“QoS优先级”的概念，每个总线主设备可以设置一个优先级等级，ISP的写回请求可以设置成高优先级，NPU的访问设置成中优先级，显示控制器设置成最高优先级。但这里有个坑，QoS优先级不是全局的，它是分区域的，比如ISP的写回请求在某个DDR通道上是高优先级，但到了另一个通道上可能就变成低优先级了。所以调优的时候，你得先搞清楚你的数据流走的是哪个通道，别想当然地以为设置了高优先级就万事大吉。

联发科Imagiq平台的思路不太一样，它更强调“带宽预算”的概念。你在初始化ISP的时候，可以给每个pipeline分配一个固定的带宽上限，比如主摄RAW写入带宽上限是2GB/s，副摄是1GB/s，NPU是1.5GB/s。这样做的优点是确定性很强，不会出现某个模块突然把带宽吃满的情况，但缺点是灵活性差，如果某个场景下主摄需要更多带宽（比如开启HDR），而副摄闲着，你没法动态调整。所以联发科的方案里，你得在软件层面做动态带宽重分配，这就要用到它的“bandwidth manager”接口，可以在运行时修改每个模块的带宽上限。

海思ISP平台在带宽管理上更“硬核”一些，它直接在硬件层面做了“带宽隔离”——每个模块有独立的DDR通道，物理上隔离，互不干扰。这个方案在安防和车载领域特别吃香，因为那些场景对确定性要求极高，宁可牺牲一点带宽利用率，也要保证关键模块不卡顿。但缺点是成本高，DDR通道数量有限，多摄并发的时候，通道不够用，你就得把两个模块塞到同一个通道里，这时候又回到了争抢的问题。

瑞芯微和安霸平台相对简单一些，它们更依赖CPU侧的软件调度。比如瑞芯微的RK3588，它的ISP和NPU之间没有硬件级的带宽仲裁，全靠Linux内核的DMA-BUF和ION内存管理来协调。这种方案的优点是灵活，你可以完全掌控带宽分配逻辑，但缺点是性能上限低，一旦并发压力大，软件调度的开销本身就占用不少CPU周期，反而加剧了带宽压力。

说回实战调优。我总结了一套“三步走”的带宽分配策略，适用于大多数平台。

第一步是“摸清家底”。用平台自带的性能监测工具（比如高通的Perfetto、联发科的Systrace、海思的Profiler），把每个模块在典型场景下的DDR带宽占用曲线拉出来。注意，一定要测“峰值”而不是“平均值”，因为带宽争抢发生在峰值时刻。比如跑AI模型的时候，NPU的带宽占用是脉冲式的，峰值可能是平均值的三倍，如果你按平均值做预算，峰值一来就崩了。

第二步是“定优先级”。根据业务场景，把模块分成“硬实时”、“软实时”和“尽力而为”三档。硬实时模块包括显示控制器、ISP的写回、视频编码器的输入，这些一旦卡顿就是掉帧或花屏，必须保证带宽。软实时模块包括NPU推理、3A统计、人脸检测框绘制，这些可以容忍一定的延迟，但不能丢数据。尽力而为模块包括缩略图生成、后台图像分析，这些可以随时降级或暂停。优先级定好之后，在硬件层面设置QoS，在软件层面设置带宽预算，双管齐下。

第三步是“动态调整”。这一步最关键，也最容易踩坑。静态的优先级和预算只能保证“不崩”，但没法保证“最优”。比如在夜景模式下，主摄需要更多带宽来跑多帧降噪，这时候副摄的带宽预算就应该降下来，甚至可以把副摄的ISP pipeline暂时挂起。这个动态调整逻辑，一定要放在一个独立的“带宽管理线程”里，不要放在ISP的中断回调里，因为中断回调里做复杂逻辑容易导致中断超时，引发更严重的问题。别这样写——在ISP回调里直接调用带宽管理接口，你会把整个pipeline卡死的。

还有一个容易被忽略的点，就是DDR的page policy。很多平台支持DDR的page open/close策略，如果设置成“page close”，每次访问都需要重新打开page，延迟高但带宽利用率高；如果设置成“page open”，延迟低但带宽利用率低。对于影像系统来说，建议设置成“page open”，因为影像数据流的访问模式是顺序的，page open能显著降低延迟，而且带宽利用率虽然低一点，但影像系统对延迟更敏感。

最后给点个人经验。第一，多摄并发加AI的场景，不要指望硬件仲裁能解决所有问题，一定要在软件层面做带宽预算和动态调整。第二，调带宽的时候，别只盯着DDR带宽，还要关注总线协议转换的开销，比如AXI到CHI的转换，有时候带宽没满但延迟很高，就是协议转换在作祟。第三，量产阶段一定要做“带宽压力测试”，模拟最恶劣的场景（比如双摄+AI+录像+显示同时跑），连续跑24小时，看有没有带宽饥饿导致的偶发卡顿。这种问题在实验室里很难复现，但到了用户手里，一旦触发就是致命bug。

做影像系统，带宽管理是“隐形的地基”，地基不稳，上面盖的楼再漂亮也白搭。希望这篇笔记能帮你在调试的时候少走几个弯路。