010、端到端影像延迟分析从曝光到屏幕显示的延迟拆解与优化实战上周在车载项目上被一个“玄学”问题缠住了。客户拿秒表掐着测说倒车影像从R挡挂上到屏幕出画面慢了整整一拍大概220ms比竞品多了70ms。我们一开始怀疑是sensor出图慢后来怀疑是显示链路没走fast path查了一圈最后发现罪魁祸首竟然是ISP里一个不起眼的统计模块在等3A收敛。这事儿让我觉得有必要把端到端延迟这笔账好好捋一捋——从光子打到sensor到屏幕像素亮起来中间每一毫秒都花在哪了怎么拆怎么量怎么压。先给个总账。一条典型的预览链路sensor曝光结束到屏幕刷新大致拆成这么几段sensor读出、ISP管线处理、3A统计与收敛等待、编码/传输如果是远程显示、显示合成与刷新。每一段都有固定开销和可变开销固定开销是架构决定的可变开销才是调优空间。sensor读出这块很多人只盯着帧率忽略了一个关键参数——滚动快门读出时间。一帧1080p60的sensor读出时间通常占掉帧周期的30%到50%。什么意思曝光结束不是整帧同时结束的是逐行结束的。最后一行曝光结束的时刻比第一行晚了将近一个读出周期。如果你在曝光结束中断里打时间戳这个误差就有十几毫秒。更坑的是有些平台把sofstart of frame当时间基准那误差更大。这里踩过坑——我们曾经用sof算延迟结果怎么优化都差那么十几ms后来改成eofend of frame中断问题立刻清晰了。别这样写代码在sof里取时间戳然后拿去算端到端延迟除非你明确知道自己在做什么补偿。ISP管线处理时间这个在不同平台差异巨大。高通Spectra是分块流水线一行一行处理延迟跟帧高成正比海思ISP是整帧乒乓buffer延迟基本等于一帧周期瑞芯微介于两者之间有行buffer也有帧buffer。这里有个容易忽略的点ISP的延迟不是固定值它跟当前负载、时钟频率、甚至温度都有关。我们在联发科Imagiq平台上遇到过开了多帧降噪之后ISP处理时间从8ms飙到23ms因为多帧对齐要等参考帧完全写入DDR才能开始。这种延迟不是线性的是跳变的排查起来特别容易误判成sensor问题。3A统计这块是重灾区。很多架构师把3A收敛当成“后台任务”觉得它不影响通路延迟。大错特错。在暗光场景AE收敛可能需要十几帧每一帧都在调整曝光和增益画面亮度一直在变但这不是延迟问题是体验问题。真正的延迟陷阱在AWB——有些平台在AWB未收敛时会强制插入一帧“统计帧”这一帧不输出图像白白浪费一个帧周期。我们在安霸平台上遇到过AWB从荧光灯切换到日光灯中间卡了整整两帧端到端延迟直接翻倍。解决方案是预判光源切换或者把AWB统计放到ISP管线内的空闲slot里别让它独占通路。编码和传输这个在车载和安防场景特别常见。如果显示端和sensor不在同一个芯片上比如倒车影像sensor在车尾屏幕在车头中间走LVDS或者以太网那编码延迟和传输延迟就是大头。H.264硬编一帧1080p60大概要3到5ms这还算快的如果是JPEG或者MJPEG单帧编码可能到8ms。传输延迟取决于链路带宽和buffer策略有些方案为了抗丢包做了三重buffer延迟直接加30ms。这里有个经验值能用raw或者YUV传输就别用编码传输除非带宽实在不够。别为了省那几兆带宽把延迟搞上去得不偿失。显示合成与刷新这是最后一段也是最容易被忽视的一段。屏幕本身的刷新率是固定的但合成器的策略会影响延迟。高通平台有display pipeline的fast path可以绕过GPU直接送显延迟能省2到3ms。但fast path不是什么时候都能走的比如你开了HDR或者旋转了画面就得走GPU合成延迟就上去了。还有VSYNC对齐的问题——如果sensor的帧率跟屏幕刷新率不是整数倍关系那画面到达显示端之后可能要等半个刷新周期才能上屏这个等待时间在60Hz屏幕上就是8ms在120Hz屏幕上就是4ms。我们做过一个优化把sensor帧率锁到屏幕刷新率的整数倍延迟立刻降了5ms。现在说怎么量。端到端延迟的测量别用秒表别用肉眼别用“感觉”。最靠谱的办法是打时间戳——在sensor曝光结束中断打一个在ISP输出完成中断打一个在显示提交VSYNC打一个在屏幕实际刷新如果有te信号打一个。把这些时间戳对齐到同一个时钟域就能精确拆解每一段的延迟。这里有个坑不同模块可能用不同的时钟域sensor用MCLKISP用ISPCLK显示用VSYNC直接相减会得到垃圾数据。得先做时钟同步或者统一用系统时间戳。我们在瑞芯微平台上吃过这个亏sensor中断和显示中断的时间戳差了整整一个时钟周期排查了半天才发现是时钟域没对齐。优化实战按性价比排序。第一查sensor的曝光结束中断是不是真的在最后一行读出之后——有些驱动偷懒用sof加固定偏移代替偏移算错了就全错了。第二查ISP有没有不必要的帧内等待比如某些统计模块在等整帧数据才往下走改成行统计行输出能省一半延迟。第三查3A有没有阻塞通路把AWB和AE的统计放到后台线程别让它们卡住出图。第四查显示链路有没有走fast path没走的话看看能不能绕开GPU。第五查buffer深度有些平台默认给预览通路配了四层buffer实际上两层就够每层buffer就是几毫秒延迟。最后说点个人经验。做延迟优化最忌讳的是“头痛医头”。你看到显示端慢了不一定是显示的问题你看到ISP慢了不一定是ISP的问题。端到端延迟是一个系统指标必须从全局拆解每一段都量化才能找到真正的瓶颈。而且延迟优化跟画质优化经常打架——你为了降延迟跳过了某一帧的3A统计画面可能就闪一下你为了降延迟减少了buffer可能就出现撕裂。这个平衡怎么拿捏得看具体场景。车载倒车影像延迟优先级最高画质可以牺牲一点安防监控画质优先级高延迟可以放宽到200ms以内都行。别拿一套参数打天下每个项目都得重新调。还有一点量产阶段的延迟跟开发板上的延迟经常不一样。开发板上sensor和屏幕都是直连的量产车上可能多了线束、连接器、电源噪声这些都会影响时序。我们遇到过量产车上sensor的MCLK被电源噪声干扰导致曝光时间抖动端到端延迟忽高忽低。这种问题在开发板上根本复现不了只能在产线上用示波器抓。所以做延迟优化一定要在产线环境验证别只在实验室里自嗨。这篇先写到这。延迟分析是个细活每一段都有坑但拆开了看其实不复杂。下一章我打算写写不同平台ISP的buffer管理策略那个才是真正拉开架构差距的地方。 010、端到端影像延迟分析：从曝光到屏幕显示的延迟拆解与优化实战
010、端到端影像延迟分析从曝光到屏幕显示的延迟拆解与优化实战上周在车载项目上被一个“玄学”问题缠住了。客户拿秒表掐着测说倒车影像从R挡挂上到屏幕出画面慢了整整一拍大概220ms比竞品多了70ms。我们一开始怀疑是sensor出图慢后来怀疑是显示链路没走fast path查了一圈最后发现罪魁祸首竟然是ISP里一个不起眼的统计模块在等3A收敛。这事儿让我觉得有必要把端到端延迟这笔账好好捋一捋——从光子打到sensor到屏幕像素亮起来中间每一毫秒都花在哪了怎么拆怎么量怎么压。先给个总账。一条典型的预览链路sensor曝光结束到屏幕刷新大致拆成这么几段sensor读出、ISP管线处理、3A统计与收敛等待、编码/传输如果是远程显示、显示合成与刷新。每一段都有固定开销和可变开销固定开销是架构决定的可变开销才是调优空间。sensor读出这块很多人只盯着帧率忽略了一个关键参数——滚动快门读出时间。一帧1080p60的sensor读出时间通常占掉帧周期的30%到50%。什么意思曝光结束不是整帧同时结束的是逐行结束的。最后一行曝光结束的时刻比第一行晚了将近一个读出周期。如果你在曝光结束中断里打时间戳这个误差就有十几毫秒。更坑的是有些平台把sofstart of frame当时间基准那误差更大。这里踩过坑——我们曾经用sof算延迟结果怎么优化都差那么十几ms后来改成eofend of frame中断问题立刻清晰了。别这样写代码在sof里取时间戳然后拿去算端到端延迟除非你明确知道自己在做什么补偿。ISP管线处理时间这个在不同平台差异巨大。高通Spectra是分块流水线一行一行处理延迟跟帧高成正比海思ISP是整帧乒乓buffer延迟基本等于一帧周期瑞芯微介于两者之间有行buffer也有帧buffer。这里有个容易忽略的点ISP的延迟不是固定值它跟当前负载、时钟频率、甚至温度都有关。我们在联发科Imagiq平台上遇到过开了多帧降噪之后ISP处理时间从8ms飙到23ms因为多帧对齐要等参考帧完全写入DDR才能开始。这种延迟不是线性的是跳变的排查起来特别容易误判成sensor问题。3A统计这块是重灾区。很多架构师把3A收敛当成“后台任务”觉得它不影响通路延迟。大错特错。在暗光场景AE收敛可能需要十几帧每一帧都在调整曝光和增益画面亮度一直在变但这不是延迟问题是体验问题。真正的延迟陷阱在AWB——有些平台在AWB未收敛时会强制插入一帧“统计帧”这一帧不输出图像白白浪费一个帧周期。我们在安霸平台上遇到过AWB从荧光灯切换到日光灯中间卡了整整两帧端到端延迟直接翻倍。解决方案是预判光源切换或者把AWB统计放到ISP管线内的空闲slot里别让它独占通路。编码和传输这个在车载和安防场景特别常见。如果显示端和sensor不在同一个芯片上比如倒车影像sensor在车尾屏幕在车头中间走LVDS或者以太网那编码延迟和传输延迟就是大头。H.264硬编一帧1080p60大概要3到5ms这还算快的如果是JPEG或者MJPEG单帧编码可能到8ms。传输延迟取决于链路带宽和buffer策略有些方案为了抗丢包做了三重buffer延迟直接加30ms。这里有个经验值能用raw或者YUV传输就别用编码传输除非带宽实在不够。别为了省那几兆带宽把延迟搞上去得不偿失。显示合成与刷新这是最后一段也是最容易被忽视的一段。屏幕本身的刷新率是固定的但合成器的策略会影响延迟。高通平台有display pipeline的fast path可以绕过GPU直接送显延迟能省2到3ms。但fast path不是什么时候都能走的比如你开了HDR或者旋转了画面就得走GPU合成延迟就上去了。还有VSYNC对齐的问题——如果sensor的帧率跟屏幕刷新率不是整数倍关系那画面到达显示端之后可能要等半个刷新周期才能上屏这个等待时间在60Hz屏幕上就是8ms在120Hz屏幕上就是4ms。我们做过一个优化把sensor帧率锁到屏幕刷新率的整数倍延迟立刻降了5ms。现在说怎么量。端到端延迟的测量别用秒表别用肉眼别用“感觉”。最靠谱的办法是打时间戳——在sensor曝光结束中断打一个在ISP输出完成中断打一个在显示提交VSYNC打一个在屏幕实际刷新如果有te信号打一个。把这些时间戳对齐到同一个时钟域就能精确拆解每一段的延迟。这里有个坑不同模块可能用不同的时钟域sensor用MCLKISP用ISPCLK显示用VSYNC直接相减会得到垃圾数据。得先做时钟同步或者统一用系统时间戳。我们在瑞芯微平台上吃过这个亏sensor中断和显示中断的时间戳差了整整一个时钟周期排查了半天才发现是时钟域没对齐。优化实战按性价比排序。第一查sensor的曝光结束中断是不是真的在最后一行读出之后——有些驱动偷懒用sof加固定偏移代替偏移算错了就全错了。第二查ISP有没有不必要的帧内等待比如某些统计模块在等整帧数据才往下走改成行统计行输出能省一半延迟。第三查3A有没有阻塞通路把AWB和AE的统计放到后台线程别让它们卡住出图。第四查显示链路有没有走fast path没走的话看看能不能绕开GPU。第五查buffer深度有些平台默认给预览通路配了四层buffer实际上两层就够每层buffer就是几毫秒延迟。最后说点个人经验。做延迟优化最忌讳的是“头痛医头”。你看到显示端慢了不一定是显示的问题你看到ISP慢了不一定是ISP的问题。端到端延迟是一个系统指标必须从全局拆解每一段都量化才能找到真正的瓶颈。而且延迟优化跟画质优化经常打架——你为了降延迟跳过了某一帧的3A统计画面可能就闪一下你为了降延迟减少了buffer可能就出现撕裂。这个平衡怎么拿捏得看具体场景。车载倒车影像延迟优先级最高画质可以牺牲一点安防监控画质优先级高延迟可以放宽到200ms以内都行。别拿一套参数打天下每个项目都得重新调。还有一点量产阶段的延迟跟开发板上的延迟经常不一样。开发板上sensor和屏幕都是直连的量产车上可能多了线束、连接器、电源噪声这些都会影响时序。我们遇到过量产车上sensor的MCLK被电源噪声干扰导致曝光时间抖动端到端延迟忽高忽低。这种问题在开发板上根本复现不了只能在产线上用示波器抓。所以做延迟优化一定要在产线环境验证别只在实验室里自嗨。这篇先写到这。延迟分析是个细活每一段都有坑但拆开了看其实不复杂。下一章我打算写写不同平台ISP的buffer管理策略那个才是真正拉开架构差距的地方。