180、高通Spectra ISP在Android HAL3下的多摄并发——IFE/BPS资源竞争与QOS优先级配置实战上周在调试一个双摄项目，主摄IMX766加广角OV08D，平台是SM8250。客户反馈一个诡异现象：广角预览偶尔卡顿，但主摄录像时尤其明显。抓了systrace，发现广角帧的ISP处理时间从正常的8ms飙到25ms，而且不是偶发，是持续性的。一开始怀疑是带宽问题，查了DDR频率和总线占用，都没到瓶颈。后来把问题定位到IFE和BPS的资源竞争上——高通Spectra的ISP管线里，IFE负责Sensor数据接入和基础处理，BPS做缩放和畸变校正，这两个硬件模块在双摄并发时共享内部带宽和某些处理单元。主摄录像占了高分辨率高帧率的IFE带宽，广角的BPS任务就被挤到后面排队了。这个案例很典型，很多工程师在HAL3层做多摄配置时，只关注了Sensor的stream配置和buffer分配，完全忽略了ISP内部硬件资源的调度策略。高通在Spectra ISP里提供了QOS（Quality of Service）优先级机制，但默认配置下所有camera session的QOS等级是一样的。这就导致多摄并发时，系统按先来后到的顺序分配ISP资源，后启动的摄像头就会吃亏。我翻了下高通的camera kernel驱动代码，在cam_isp_hw_mgr.c里有个cam_isp_hw_acquire函数，里面会根据cam_isp_hw_client_info结构体的qos_config字段来设置硬件优先级。但HAL3层默认不会去改这 180、高通Spectra ISP在Android HAL3下的多摄并发——IFE/BPS资源竞争与QOS优先级配置实战
180、高通Spectra ISP在Android HAL3下的多摄并发——IFE/BPS资源竞争与QOS优先级配置实战上周在调试一个双摄项目，主摄IMX766加广角OV08D，平台是SM8250。客户反馈一个诡异现象：广角预览偶尔卡顿，但主摄录像时尤其明显。抓了systrace，发现广角帧的ISP处理时间从正常的8ms飙到25ms，而且不是偶发，是持续性的。一开始怀疑是带宽问题，查了DDR频率和总线占用，都没到瓶颈。后来把问题定位到IFE和BPS的资源竞争上——高通Spectra的ISP管线里，IFE负责Sensor数据接入和基础处理，BPS做缩放和畸变校正，这两个硬件模块在双摄并发时共享内部带宽和某些处理单元。主摄录像占了高分辨率高帧率的IFE带宽，广角的BPS任务就被挤到后面排队了。这个案例很典型，很多工程师在HAL3层做多摄配置时，只关注了Sensor的stream配置和buffer分配，完全忽略了ISP内部硬件资源的调度策略。高通在Spectra ISP里提供了QOS（Quality of Service）优先级机制，但默认配置下所有camera session的QOS等级是一样的。这就导致多摄并发时，系统按先来后到的顺序分配ISP资源，后启动的摄像头就会吃亏。我翻了下高通的camera kernel驱动代码，在cam_isp_hw_mgr.c里有个cam_isp_hw_acquire函数，里面会根据cam_isp_hw_client_info结构体的qos_config字段来设置硬件优先级。但HAL3层默认不会去改这