110、影像算法的DSP/NPU Offloading实战——哪些算子适合DSP/哪些适合NPU上周在调试一个项目，客户要求把多帧降噪的时域滤波部分从CPU上挪走，说CPU占用率已经顶到85%了，再不加硬件加速就要爆了。我打开代码一看，好家伙，时域滤波用的是浮点，跑在NEON上，数据来回搬运还带cache flush。这玩意儿就算你挪到DSP上，如果数据通路设计不对，性能反而更烂。今天就把这些年踩过的坑捋一捋，聊聊影像算法里哪些算子该扔给DSP，哪些该扔给NPU，哪些最好老老实实留在CPU上。先搞清楚一个基本事实：DSP和NPU不是替代关系，是互补关系。DSP擅长的是流式处理、定点运算、内存访问模式规律的重负载计算，比如FIR滤波、FFT、色彩插值、畸变校正这类。NPU擅长的是卷积、矩阵乘、激活函数这类高度并行的神经网络算子。但这里有个关键区别：NPU的调度延迟和内存搬运开销比DSP大得多，小算子的启动开销可能比计算本身还贵。所以判断一个算子该不该上NPU，先问一个问题：这个算子的计算密度够不够高？如果输入是一张1080P的图，输出也是一张1080P的图，中间只有几个卷积层，那NPU是合适的。但如果输入是一小块ROI，比如人脸检测框里的几十乘几十像素，你跑一个轻量级分类网络，NPU的启动开销可能比CPU跑还慢，这时候DSP或者CPU反而更合适。拿高通平台举例，Spectra ISP里有个东西叫IFE（Image Front End），它能把RAW域的数据直接送给DSP或者NPU，但这里有个大坑：IFE的输出格式和DSP/NPU期望的输入格式经常不一致。比如IFE输出的是10-bit RAW，但DSP的向量单元是按16-bit对齐的 110、影像算法的DSP/NPU Offloading实战——哪些算子适合DSP/哪些适合NPU
110、影像算法的DSP/NPU Offloading实战——哪些算子适合DSP/哪些适合NPU上周在调试一个项目，客户要求把多帧降噪的时域滤波部分从CPU上挪走，说CPU占用率已经顶到85%了，再不加硬件加速就要爆了。我打开代码一看，好家伙，时域滤波用的是浮点，跑在NEON上，数据来回搬运还带cache flush。这玩意儿就算你挪到DSP上，如果数据通路设计不对，性能反而更烂。今天就把这些年踩过的坑捋一捋，聊聊影像算法里哪些算子该扔给DSP，哪些该扔给NPU，哪些最好老老实实留在CPU上。先搞清楚一个基本事实：DSP和NPU不是替代关系，是互补关系。DSP擅长的是流式处理、定点运算、内存访问模式规律的重负载计算，比如FIR滤波、FFT、色彩插值、畸变校正这类。NPU擅长的是卷积、矩阵乘、激活函数这类高度并行的神经网络算子。但这里有个关键区别：NPU的调度延迟和内存搬运开销比DSP大得多，小算子的启动开销可能比计算本身还贵。所以判断一个算子该不该上NPU，先问一个问题：这个算子的计算密度够不够高？如果输入是一张1080P的图，输出也是一张1080P的图，中间只有几个卷积层，那NPU是合适的。但如果输入是一小块ROI，比如人脸检测框里的几十乘几十像素，你跑一个轻量级分类网络，NPU的启动开销可能比CPU跑还慢，这时候DSP或者CPU反而更合适。拿高通平台举例，Spectra ISP里有个东西叫IFE（Image Front End），它能把RAW域的数据直接送给DSP或者NPU，但这里有个大坑：IFE的输出格式和DSP/NPU期望的输入格式经常不一致。比如IFE输出的是10-bit RAW，但DSP的向量单元是按16-bit对齐的