10.1 MDP多通道设计不止是多那么简单MDPMobile Display Processor的多通道设计不是简单地把一个通道复制成几个。我刚开始接触时也这么以为结果被坑了一次——两个屏幕同时刷视频一个卡成PPT另一个却正常。后来才明白每个通道都是独立的数据管道。MTK8678的MDP支持最多4个独立显示通道每个通道都有自己的一套硬件资源独立的DMA引擎每个通道有自己的数据搬运工不共享独立的缩放器支持从1/16x到16x的独立缩放独立的色彩转换器每个屏幕可以有不同的色彩空间独立的时序发生器刷新率可以不同比如主屏60Hz副屏30Hz关键点多通道不是分时复用而是空间并行。每个通道的硬件资源是物理独立的这样才能保证多屏同时显示时互不干扰。我记得在做一个车载项目时需要同时驱动仪表盘60fps、中控屏30fps和副驾娱乐屏24fps。三个屏幕刷新率完全不同但MDP的独立时序发生器完美解决了这个问题。嗯这里要注意不同刷新率的屏幕帧同步是个大坑后面我会专门讲。10.2 显示路径选择数据该走哪条路显示路径选择说白了就是决定数据从GPU/视频解码器出来后走哪条路到达屏幕。MTK8678提供了多种路径选择路径类型延迟带宽适用场景直接路径Direct Path低1ms高4K60fps游戏、视频播放合成路径Composition Path中2-3ms中2K60fpsUI界面、多窗口叠加路径Overlay Path低1ms高支持HDR画中画、字幕叠加回写路径Writeback Path高5-10ms低1080p30fps屏幕录制、投屏你想想看为什么要有这么多路径因为不同的场景对延迟和带宽的要求不一样。玩游戏时你肯定不希望因为路径选择不当导致操作延迟而屏幕录制时稍微慢一点无所谓但数据量要控制好。我的经验路径选择不是写死的而是动态切换的。我曾经在调试一个双屏异显的应用时发现副屏总是卡顿。查了半天原来是路径选择策略没配好——副屏走了合成路径但合成器带宽不够。改成直接路径后问题解决。10.3 带宽管理别让数据堵在路上带宽管理是MDP最头疼的问题。为什么因为显示数据量太大了。算一笔账4K60fps3840×2160×4字节×60 ≈ 2GB/s双屏4K直接翻倍到4GB/s再加上GPU、视频解码器、相机等模块抢带宽MTK8678的带宽管理策略主要有三种优先级调度显示数据优先级最高其次是视频解码最后是GPU渲染动态频率调整根据负载自动调整MDP和内存控制器的频率数据压缩支持AFBC帧缓冲压缩压缩比可达2:1到4:1避坑指南我曾经遇到过一个诡异的问题——单屏显示正常双屏显示时主屏偶尔闪一下。查了三天最后发现是带宽不足导致MDP丢数据。解决方案是开启AFBC压缩同时把主屏的优先级调高。记住带宽不是无限的该压缩时就压缩。10.4 仲裁机制谁先谁后仲裁机制解决的是多个请求同时到达时谁先获得服务的问题。MTK8678的MDP仲裁器采用两级仲裁第一级通道间仲裁固定优先级主屏通道 副屏通道1 副屏通道2 副屏通道3但可以动态调整比如副屏在播放视频时可以临时提升优先级第二级请求间仲裁读请求优先于写请求因为显示需要读数据紧急请求优先于普通请求比如VSYNC信号触发时小数据量请求优先于大数据量请求减少等待时间我个人习惯在调试时先看仲裁日志。MTK提供了MDP的debugfs接口可以实时查看每个通道的仲裁次数和等待时间# 查看MDP仲裁状态 cat /sys/kernel/debug/mdp/arbiter_status # 输出示例 # Channel 0 (Primary): 仲裁次数 12345, 平均等待 0.3us # Channel 1 (Secondary): 仲裁次数 6789, 平均等待 1.2us # Channel 2 (Tertiary): 仲裁次数 2345, 平均等待 3.5us如果某个通道的等待时间超过5us基本就会丢帧了。我一般会把这个阈值作为报警线。核心总结多屏显示的硬件架构本质上是在解决三个问题数据怎么分多通道设计数据走哪条路路径选择数据不够用时怎么办带宽管理与仲裁这三个问题搞定了多屏显示就成功了一大半。好了这一章的内容就到这里。下一章我们会讲帧同步与撕裂消除——嗯那又是一个让人头秃的话题。到时候我会分享一个我踩过的坑保证让你印象深刻。