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， 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，