MTK显示架构演进：从MDP到DDP，带宽与功耗优化的关键设计

前几年在调一块4K60的屏时我被一个怪问题折腾了很久。帧率上不去翻开总线监控发现带宽统计里MDP_OVL独占了一大块DDR读写的数值比预期高出一截。后来追到根因才发现问题根本不在这颗SoC而在于整套显示通路的架构——它还在用老一代的MDP思路数据在内存里被来回搬运等于同一个画面花了两次带宽。从那次之后我就开始认真研究MTK-Display从MDP到DDP的架构演进也摸清了为什么新平台要彻底换一套框架。这篇文章想把这些技术细节整理出来不聊空泛的“演进方向”而是落到模块、数据流、带宽、功耗和实际调试这几个具体维度。适合正在做显示驱动适配、做底层软件优化或者是刚接触MTK显示子系统的工程师。你会发现理解了MDP和DDP的本质差异很多屏幕相关的疑难杂症自己就能推导出方向。1. MDP时代一锅端的内存搬运与单级合成瓶颈MDP的全称是Media Data Path早年MTK在Linux内核里把显示路径统一挂在“多媒体数据处理”这个大类下面。这个名字其实已经暗示了它的设计思路——显示合成只是多媒体处理的一种场景和视频解码、图像后处理走的是同一套资源池思路。1.1 典型MDP合成链路上的模块角色一条典型的MDP合成链路由几个模块串联而成。MDP_OVL负责把多图层做硬件合成MDP_RDMA从DDR里读取图层数据MDP_WROT负责旋转或写回MDP_RSZ做缩放。有的SoC还会在链路上挂MDP_COLOR、MDP_TDSHP这类用于色彩校正和锐化的模块。整条链路的输出最终落到DSI、DPI或者DP接口上。我用一个简化流程来说明假设界面有一层壁纸、一个状态栏、一个弹窗MDP_OVL会把这3层按Z序混合成一个单图层再经由RDMA把结果写回DDR的某个buffer下一次vsync到来时显示控制器再从DDR把这张合成好的图读出来送给屏幕。很多做过显示驱动的人一眼就能看出问题——这中间存在一次额外的“写回再读取”也就是MDP_WROT之后那一段。合成结果明明可以直接喂给DSI却非要回到内存里中转一下帧率越高、分辨率越大这个中转消耗的带宽就越夸张。1.2 命令队列机制在小分辨率时代的合理性MDP时代内核里有一个“命令队列”机制用户空间可以通过ioctl把一组显示配置打包提交给MDP硬件去排队执行。这种做法在小分辨率、单屏、帧率60Hz的场景下非常稳定因为单帧数据量不太大队列积压的概率很低。而且命令队列的好处是应用层一次性提交多个图层配置硬件可以按照时间戳逐个生效避免逐层操作带来的撕裂。这也是为什么很多老工程师对MDP并不反感——它设计得很完整调试工具也齐全甚至在多图层合成场景下MDP_OVL的硬件效率并不差。但问题在于这套架构把“显示通路”和“多媒体通路”绑在同一个大框架里导致所有模块共享同一个带宽入口和同一套中断管理。当屏幕从1080P跳到2K、4K刷新率从60Hz跳到120Hz、144HzMDP的短板就开始集中爆发。1.3 高分辨率多任务场景下的带宽失血我算过一笔账用1080P60来举例RGB888格式一帧约6.2MB60Hz下纯显存读取就是373MB/s这还只是单图层。如果是3图层合成MDP_OVL要先读3个图层合成后再写回一张图显示控制器再读一次总线上的流量大约等于4到5帧的全屏数据量。到4K60单帧带宽直接变成25MB左右一个合成场景跑下来总线占用率能到30%以上这个数字会直接影响GPU和CPU的DDR访问延迟。带宽还不是最致命的问题。MDP合成路径上的模块都挂在同一个M4UIOMMU域里一旦某个图层地址写错或越界整个显示通路都会受牵连轻则黑屏闪屏重则直接触发系统DDR fault。我在一个老平台上遇到过很奇怪的现象屏幕偶尔花屏但dmesg里没有明显错误。最后定位出来是一个驱动的输入参数触发了WROT的越界写把相邻模块的寄存器区域冲掉了。这种问题放在MDP架构里很难隔离因为所有模块共用一条通路、共用一个地址空间。2. DDP重新分工合成器回归显示路径的本位DDP的全称是Data Display Path后缀从“多媒体数据处理”变成了“显示数据通路”这不仅仅是命名上的区别而是把显示合成从“媒体处理框架”里彻底拆了出来成为一个独立的、以显示时序为生命周期的硬件路径。2.1 DDP的核心思路以管道Pipe为单位组织模块DDP架构下硬件模块不再是一个个零散的功能块而是被组织成若干条DisplayPipe。一条典型的Pipe从OVL开始经过RDMA、AAL、CCORR、GAMMA、DITHER最后喂给DSI或DP。OVL负责图层合成RDMA读取数据并做格式转换AAL做环境光自适应调整CCORR做色彩校正GAMMA和DITHER做最终的色彩映射和抖动处理。一整条Pipe可以独立完成从图层到像素输出的全部工作不需要再经由内存中转。用生活化的比喻来说MDP时代相当于先把各种菜在中央厨房炒好再装盒送到店里去卖而DDP就像把炒菜设备直接搬到每个门店的后厨食材洗好切好就能直接下锅。省掉的不只是中间运输环节还包括装盒洗盒子的开销。2.2 逐层处理的硬件加速路径DDP的另一个关键变化是把原来放在内核软件逻辑里的不少功能下沉到了硬件Pipeline。比如原先你需要在驱动里手动配置OVL layer的alpha blending顺序DDP硬件会自动按Z轴顺序处理AAL会根据背光传感器联动动态调整显示效果和功耗这些原本在MDP时代可能需要额外的软件定时器去轮询在DDP里都是硬件状态机的一部分。这些改进的背后是“显示实时性”理念的转变。显示通路不再是一个被调用时才工作的外设而是一条始终跟随vsync节奏运转的流水线。每一帧到来了Pipe上的每个模块会按固定节拍处理数据如果一个模块没准备好状态机会自动等待而不会像MDP那样出现命令队列顶住的情况。2.3 多Pipe并行与跨平台复用DDP架构里通常会有多条Pipe有的SoC提供两到三条具体数目取决于产品定位。多Pipe的价值在折叠屏、双屏或者副屏场景里特别明显——每条Pipe可以独立绑定一个物理接口各自按自己的时序跑互不干扰。比如内屏用Pipe0驱动折叠屏的LTPO面板外屏用Pipe1驱动一小块副屏两块屏刷新率不同、时序不同但硬件互不影响。跨平台复用也是DDP的优势。从主流中端SoC到旗舰平台的Display子系统寄存器布局和模块连接关系保持了很高的延续性。我手头同时维护过两代平台的显示驱动DDP node的配置方法基本一致区别主要在Power Domain和时钟树的拆分上。这意味着工程师迁移平台的学习成本大幅降低。3. 架构演进背后的四个工程动因从MDP到DDP不可能是拍脑袋的决定背后一定有明确的工程诉求。我总结下来至少四个维度直接推动了这次演进。3.1 带宽与功耗合成结果不进DDR总线立刻喘了口气前面已经算过MDP方案里合成结果要写回DDR再读一次DDP方案直接省掉这两次内存访问。以一个4K60三图层场景计算DDP架构每帧能省下大约25MB的写入和25MB的读取换算成带宽就是3GB/s的流量下降。别小看这3GB/s在多路多媒体并发相机预览、视频编解码同时进行时省下的带宽可能决定系统会不会掉帧、会不会出现DDR仲裁优先级倒挂。功耗上也是一样逻辑。DDR访问的单位功耗远高于片上模块间的数据搬运。同样是合成一张图DDP让数据在OVL和DSI之间直接流动不需要经过M4U的page walk和DDR控制器的bank切换。实测在新平台同类场景下显示相关功耗比旧平台下降了5%到10%这个数据我很确定不是面板或背光带来的因为对比时关闭了CABC和PSR。3.2 故障隔离一个图层页错误不再拖垮整条通路M4U在DDP时代也做了重构。老MDP架构里所有图层的buffer都映射在同一个地址空间域一个layer的address fault会污染整个显示通路内核只能通过full reset来恢复。DDP架构支持下每个Pipe甚至每个关键模块可以有不同的page table段IOMMU能更精准地把fault定位到具体图层。这在安全显示和复杂多媒体场景里尤为重要。我遇到过一个场景某个视频播放器申请了带保护标志的buffer因为映射错误被显示控制器访问旧平台直接触发安全中断导致整个系统重启。而新平台的DDP安全显示路径能把这类问题隔离在特定Pipe内部顶层系统只需要重建那条Pipe不需要整个display子系统重启。3.3 多屏与异形屏适配DCONFIG让通路组合更灵活DDP架构里有一个重要的配置模块叫DCONFIG它本质上是一个硬件交叉开关负责把多条Pipe的输