142、多摄DDR带宽分配与优先级调度——主摄/超广角/长焦同时工作时的带宽冲突解决去年年底接手一个项目，三摄同时预览，主摄4K30 + 超广角1080P60 + 长焦1080P30，外加一路录像编码。机器跑起来直接卡成PPT，ISP那边报带宽超限，DDR控制器温度飙升到85度。客户拿热像仪一照，板子上的LPDDR4x区域红得跟烙铁似的。这问题不是算法能救的，是DDR带宽被吃穿了。先算一笔账。主摄4K30，RAW10输出，一帧3840x2160x10bit，约82Mbit，30帧就是2.46Gbps。超广角1080P60，1920x1080x10bit，一帧20.7Mbit，60帧1.24Gbps。长焦1080P30，0.62Gbps。光这三路RAW进ISP，合计4.3Gbps。还没算ISP输出YUV、编码器读帧、显示通路、NPU偶尔抽风跑个检测。LPDDR4x 双通道32bit，频率1866MHz，理论带宽约14.9GB/s，换算成Gbps是119Gbps。听着挺宽裕对吧？但实际有效带宽打六折，而且多摄场景下bank冲突、page miss、读写切换开销，能把有效带宽再砍一半。真正能用的，可能就35-40Gbps。三摄RAW加编码，轻松顶到30Gbps以上，再叠加系统其他负载，不爆才怪。高通平台上有套现成的工具，叫DDR Budget Tool，在QXDM里能导出各IP的带宽占用曲线。联发科那边叫DVFS和QoS寄存器组，海思有DDRC的监控计数器。但问题是，这些工具只能告诉你"谁吃了多少"，不会告诉你"怎么分才合理"。架构师要干的事，就是定优先级、设水线、配QoS。先说优先级策略。多摄场景下，主摄永远是老大，这个没得商量。主摄掉帧，用户立刻能感知，
142、多摄DDR带宽分配与优先级调度——主摄/超广角/长焦同时工作时的带宽冲突解决去年年底接手一个项目，三摄同时预览，主摄4K30 + 超广角1080P60 + 长焦1080P30，外加一路录像编码。机器跑起来直接卡成PPT，ISP那边报带宽超限，DDR控制器温度飙升到85度。客户拿热像仪一照，板子上的LPDDR4x区域红得跟烙铁似的。这问题不是算法能救的，是DDR带宽被吃穿了。先算一笔账。主摄4K30，RAW10输出，一帧3840x2160x10bit，约82Mbit，30帧就是2.46Gbps。超广角1080P60，1920x1080x10bit，一帧20.7Mbit，60帧1.24Gbps。长焦1080P30，0.62Gbps。光这三路RAW进ISP，合计4.3Gbps。还没算ISP输出YUV、编码器读帧、显示通路、NPU偶尔抽风跑个检测。LPDDR4x 双通道32bit，频率1866MHz，理论带宽约14.9GB/s，换算成Gbps是119Gbps。听着挺宽裕对吧？但实际有效带宽打六折，而且多摄场景下bank冲突、page miss、读写切换开销，能把有效带宽再砍一半。真正能用的，可能就35-40Gbps。三摄RAW加编码，轻松顶到30Gbps以上，再叠加系统其他负载，不爆才怪。高通平台上有套现成的工具，叫DDR Budget Tool，在QXDM里能导出各IP的带宽占用曲线。联发科那边叫DVFS和QoS寄存器组，海思有DDRC的监控计数器。但问题是，这些工具只能告诉你"谁吃了多少"，不会告诉你"怎么分才合理"。架构师要干的事，就是定优先级、设水线、配QoS。先说优先级策略。多摄场景下，主摄永远是老大，这个没得商量。主摄掉帧，用户立刻能感知，
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
