144、影像算法DSP/NPU Offloading——降噪/超分/语义分割算子在高通/联发科/海思平台的部署选择

144、影像算法DSP/NPU Offloading——降噪/超分/语义分割算子在高通/联发科/海思平台的部署选择

上个月在调试一台搭载骁龙8 Gen2的旗舰机，客户反馈夜景模式在暗光下预览帧率掉到18fps，而且发热明显。抓了systrace一看，罪魁祸首是自研的时域降噪算子——纯CPU跑，每帧耗时32ms，把整个pipeline拖垮了。当时我第一反应是“这玩意儿不是该扔给DSP吗”，结果一查代码，发现当初为了赶进度，直接在ARM核上写了NEON版本，压根没考虑过异构计算。这种事儿在行业里太常见了，算法工程师觉得“能跑就行”，系统工程师又没空帮你重构，最后就是性能烂在产线上。

先泼盆冷水：不是所有算子都适合offload。降噪、超分、语义分割这三类，恰恰是“看起来适合、实际坑最多”的典型。你拿一个3x3的均值滤波去问DSP要不要接，它当然说“来者不拒”，但等你把bilateral filter的权重计算搬上去，就会发现DSP的L2 cache小得可怜，数据搬运的时间比计算还长。我见过最离谱的案例，有人把超分网络里的transformer block硬塞给NPU，结果NPU不支持动态shape，每次推理都要重新编译模型，帧率直接砍半。

高通平台，Spectra ISP和Hexagon DSP之间有一条叫“camera fast path”的专用通道，数据从ISP出来可以不经过DDR，直接进DSP的TCM（紧耦合内存）。这个设计本意是给实时降噪用的，但有个致命限制——TCM总共才几百KB，你塞不下一个完整的U-Net。所以高通的推荐做法是“分块处理”，把图像切成16x16的tile，