004、联发科天玑Imagiq ISP架构与HyperEngine协同：Tuning Toolkit调优实战

004、联发科天玑Imagiq ISP架构与HyperEngine协同：Tuning Toolkit调优实战

老规矩，先扔一个上周刚处理的案子。某项目用天玑9000+配OV50H，客户反馈夜景预览取景框里暗部噪点像下雪，但拍完照片看RAW又觉得还行。一开始怀疑是3A没收敛，查了AE统计值，曝光时间、增益都正常。后来把预览通路和拍照通路的ISP pipeline拉出来对比，发现预览走的是Imagiq 7.0的Fast Path，拍照走的是Full Path，两者在NR（降噪）模块的强度配置差了整整三档。这问题在骁龙平台上几乎不会遇到，因为Spectra的预览和拍照共用一套tuning参数，顶多分辨率不同导致scale系数微调。但天玑的Imagiq为了压低预览功耗，默认把Fast Path的NR强度砍了一半，而且Tuning Tool里这个开关藏得极深，不翻到ISP Sub-block的Per-frame Setting页签根本找不到。

这就是联发科平台和骁龙平台最大的思维差异：高通把ISP当成一个整体黑盒，你调的是全局风格；联发科把ISP拆成多个可独立开关的硬件加速器，每个加速器有自己的SRAM预算和时钟门控，Tuning的粒度细到令人发指，但也意味着你必须理解每个模块在什么场景下会被硬件调度器自动旁路。

先看Imagiq 7.0/8.0的核心架构。天玑9000之后，联发科把ISP拆成了三路并行管线：主摄走MISP（Main ISP），超广角和长焦走SISP（Secondary ISP），还有一路极低功耗的LISP（Low-power ISP）专门给AOD和Always-on场景用。MISP内部又分前段和后段，前段做Bayer域的坏点校正、黑电平、去马赛克，后段做RGB域的3A统计、色彩校正、Gamma、NR和Sharpen。这里有个关键点：联发科的NR和Sharpen是放在后段的RGB域，而不是像高通那样放在YUV域。这意味着你在Tuning Toolkit里调NR强度时，实际上是在调一个对RGB三个通道分别加权的滤波器，如果某个通道的权重配得不合适，很容易出现彩色噪点残留，而灰度噪点反而被抹得很干净。这个现象在低照度下特别明显，因为Bayer域的绿色通道信噪比天然高于红蓝通道，RGB域的NR如果不做通道差异化处理，就会把绿色通道的细节连带抹掉。

再说HyperEngine协同。这玩意儿名义上是游戏优化引擎，但影像系统里它管的是CPU/GPU/DDR的带宽分配。天玑平台的ISP没有独立的DDR端口，它和GPU、视频编解码器共享内存带宽。当你开启HyperEngine的Game Mode时，系统会把DDR带宽优先让给GPU，ISP的带宽配额被压缩，这时候如果Tuning参数里某个模块的line buffer需求超过配额，硬件调度器会强制降级——比如把NR从三帧时域降成单帧空域，或者把Sharpen的kernel size从5x5砍成3x3。最坑的是这个降级过程在Tuning Toolkit的离线仿真里完全看不出来，因为离线仿真用的是固定带宽模型，只有跑到真机上，用联发科的AP_Log抓取ISP Per-frame的带宽占用和降级标志位，才能发现。

所以调天玑平台，第一步不是打开Tuning Toolkit，而是先跑一遍联发科的ISP Benchmark脚本，生成一份当前固件下各模块的带宽和延迟报告。这份报告会告诉你每个ISP子模块在目标分辨率下的SRAM占用、DDR读写带宽、以及硬件调度器的降级阈值。拿到这份报告后，你才能决定哪些参数可以放开调，哪些参数必须保守。比如在1080P预览下，MISP的NR模块如果开满三帧时域降噪，带宽占用会达到1.2GB/s，而HyperEngine的Game Mode只给ISP留了800MB/s，这时候你必须在Tuning Toolkit里把NR的时域帧数从3降到2，否则硬件调度器会在每帧的VSYNC中断里强制旁路NR，导致画面出现周期性噪点波动——这个现象在预览时很难察觉，但录视频时就会变成一卡一卡的噪点闪烁。

Tuning Toolkit本身的操作逻辑和高通QPST完全是两个物种。高通的Tuning工具是"参数-曲线-3A表"三层结构，你调完一组参数直接烧进ACD（Automatic Calibration Data）就行。联发科的Tuning Toolkit是"场景-模式-子块"三层结构，每个场景（如夜景、逆光、室内）下挂多个模式（如预览、拍照、录像），每个模式里再挂ISP子块的参数集。这里有个大坑：联发科的场景切换不是靠3A算法自动触发的，而是靠传感器端的LSC（镜头阴影校正）表和AWB的色温区间共同决定的。如果你在Tuning Toolkit里改了某个场景的NR参数，但没同步更新该场景的LSC表，那么当环境色温跨越场景边界时，ISP会突然切换参数集，导致画面亮度或色彩跳变。我见过好几个项目在客户现场出现"拍照颜色突然变绿"的问题，最后查下来都是场景切换时LSC表和NR参数不匹配造成的。

代码层面，联发科提供的Camera HAL里有一个imagiq_tuning_override接口，可以在运行时动态修改ISP参数，这个接口在调试时非常有用。比如你想验证某个NR参数在真机上的效果，不用重新编译固件，直接通过adb shell调用这个接口，传入JSON格式的参数覆盖即可。但注意，这个接口只对MISP生效，SISP和LISP的覆盖需要走另一个secondary_isp_override接口，而且这两个接口的优先级不同——MISP的override优先级高于Tuning Toolkit烧录的参数，但低于硬件调度器的降级指令。换句话说，如果你在override里把NR强度调到100，但硬件调度器判定带宽超限，它仍然会强制降级，override不会阻止这个行为。

// 这里踩过坑：别直接改vendor/mediatek/proprietary/packages/apps/Camera/下的默认参数// 那个路径下的参数是给CTS测试用的，改了会被系统OTA覆盖// 正确做法是写一个独立的tuning override模块，挂在CameraProvider的initialize阶段status_tImagiqTuningOverride::applyOverride(uint32_tframeId,constsp<CaptureRequest>&request){// 先检查当前场景是否在override白名单里// 别用strcmp去匹配场景名，联发科的场景名在不同版本固件里会变// 用场景ID判断，这个ID在ISP的tuning data头文件里定义if(request->mMetadata.exists(ANDROID_CONTROL_AWB_MODE)){uint8_tawbMode=request->mMetadata.find(ANDROID_CONTROL_AWB_MODE).value();// 这里有个隐藏逻辑：AWB_MODE为CONTROL_AWB_MODE_OFF时，// ISP会跳过AWB模块的tuning参数，直接用传感器原始增益// 如果你在Tuning Toolkit里改了AWB的曲线，但没改传感器增益表，// 会导致色彩偏移，而且这个偏移在log里查不到任何errorif(awbMode==ANDROID_CONTROL_AWB_MODE_OFF){// 手动模式下的NR强度要单独调，别复用自动模式的参数// 自动模式下NR强度是随ISO动态插值的，手动模式下是固定值// 如果固定值设得太高，暗部细节会糊成一团mNrStrength=0.6f;// 实测0.6是安全值，0.8以上会明显涂抹}}// 写入ISP寄存器组的操作要放在flush之前// 联发科的ISP寄存器是双缓冲的，当前帧读的是shadow register// 你写入的active register会在下一帧VSYNC时生效// 如果放在flush之后写，会覆盖掉硬件调度器的降级指令sp<IImageISP>isp=mISP->getISPInstance();isp->setTuningParameter(ISP_NR_STRENGTH,mNrStrength);isp->setTuningParameter(ISP_SHARPEN_GAIN,mSharpenGain);// 最后别忘了调用commit，否则参数不会生效// 这个commit是异步的，返回后不代表硬件已经接受// 要等下一帧的VSYNC回调确认，或者用ISP的getAppliedParameter查询isp->commitTuningParameters(frameId);returnOK;}

真机调试时，联发科的AP_Log比高通的logcat要复杂得多。高通平台你抓camx的log就能看到3A状态和ISP参数，联发科需要同时抓三个log：isp_log（ISP寄存器读写）、cam_log（HAL层和3A算法）、sys_log（硬件调度器和带宽监控）。这三个log的时间戳是不同步的，isp_log用的是硬件时间戳，cam_log用的是系统时间戳，sys_log用的是内核时间戳。如果你要定位一个帧率抖动问题，得先把三个log的时间戳对齐，否则根本对不上哪帧ISP参数被改了、哪帧带宽超限了。联发科提供了一个ap_log_merge工具，但那个工具只对齐秒级时间戳，对于帧级（16ms）的问题定位完全不够用。我的做法是写一个脚本，用每帧的frameId作为关联键，把三个log里同一frameId的记录合并成一行，这样就能看到一帧从HAL下发到ISP执行再到硬件调度的完整链路。

最后说点个人经验。天玑平台的Tuning Toolkit里，有一个叫ISP_Global_Clock_Control的选项，默认是Auto模式，硬件会根据场景自动调节ISP时钟频率。这个选项在量产时一定要改成Fixed模式，并且固定到最高频率。原因很简单：Auto模式下，当场景从暗光切到亮光时，ISP时钟会先降频再升频，这个切换过程大约需要3帧，期间NR和Sharpen的强度会波动，表现为画面先变模糊再变清晰。虽然这个波动只有几十毫秒，但在人眼敏感的亮度跳变场景下，会被感知为"画面呼吸感"。改成Fixed模式后，功耗会增加约80mW，但换来的是稳定的画质表现。这个取舍在旗舰机上值得，在千元机上就要权衡了——如果项目功耗预算紧，建议至少把预览通路的时钟固定，拍照通路可以保持Auto，因为拍照时用户注意力在取景框上，对画质波动的敏感度低于预览。

还有一点，联发科的ISP tuning参数是分版本管理的，同一个传感器在不同Android版本下的默认参数可能不同。比如天玑9000+在Android 13和Android 14下的默认NR强度差了0.2档，这是因为联发科在Android 14里改了ISP的默认带宽分配策略。所以你在做平台适配时，不要假设上一代平台的tuning参数可以直接迁移，一定要在目标Android版本上重新跑一遍ISP Benchmark，确认带宽和延迟的基线数据。这个坑我踩过两次，第一次是天玑1200迁移到天玑8100，第二次是天玑9000迁移到天玑9200，都是因为默认参数变了导致夜景画质回退，最后查了半天才发现是版本差异。

写代码时还有个细节，联发科的ISP驱动里有一个isp_pm_qos接口，用于在ISP工作期间锁定DDR带宽。这个接口默认是关闭的，需要你在HAL层显式调用。如果你的项目有严重的预览卡顿问题，可以尝试在预览流开启时调用这个接口，锁定额外的200MB/s带宽。但注意，这个接口会直接影响HyperEngine的带宽分配，如果同时开启了Game Mode，可能会导致GPU带宽不足，游戏掉帧。所以这个接口的使用要谨慎，最好在系统层面做一个动态策略：前台是相机时锁定带宽，前台是游戏时释放带宽。这个策略的实现不复杂，就是监听Activity的焦点变化，但联发科的框架里没有现成的回调，需要你自己在SystemUI或AMS里加一个监听器。