系统架构设计：多屏显示架构与硬件接口规划
多屏系统，说白了就是让几块屏幕各司其职，又不打架。我见过不少项目，硬件选型时没想清楚，结果软件团队天天在调同步、修撕裂。今天咱们就把这块掰开揉碎了讲。
多屏显示架构：IVI + 仪表 + HUD + 后排娱乐
先看一个典型的四屏架构。我习惯把它分成「主控域」和「显示域」两层来思考。
核心原则：仪表和HUD属于安全域，IVI和后排娱乐属于信息域。安全域必须独立渲染、独立刷新，不能受信息域卡顿影响。
硬件接口规划：DSI / DP / eDP
接口选型这块，我踩过不少坑。8295 的显示接口资源很丰富，但怎么分配，得看屏幕规格和走线距离。
| 接口类型 | 带宽 | 最大分辨率 | 传输距离 | 推荐场景 |
|---|---|---|---|---|
| DSI (4-lane) | ~12 Gbps | 1920x1080@60fps | < 30cm | 仪表屏、HUD（短距、低延迟） |
| DP 1.4 | ~32.4 Gbps | 4K@60fps | < 3m | IVI 中控、后排娱乐（长距、高分辨率） |
| eDP 1.4 | ~21.6 Gbps | 2560x1600@60fps | < 50cm | HUD 或副驾屏（内嵌、低功耗） |
我的经验：仪表屏尽量用 DSI，延迟最低。IVI 用 DP 走长线，方便布局。HUD 如果距离近，eDP 是个好选择，省一路 DSI 资源给其他屏。
操作系统选择与 Hypervisor 方案
多屏系统最头疼的问题是什么？是「一个系统崩了，所有屏都黑了」。Hypervisor 就是来解决这个问题的。
我建议的方案是这样的：
- 安全域（仪表 + HUD）：运行在独立的 Linux 或 QNX 上，通过 Hypervisor 隔离。我习惯用 QNX，ASIL-B 认证好过。
- 信息域（IVI + 后排娱乐）：运行在 Android Automotive 上，享受生态和开发效率。
- Hypervisor：推荐用 BlackBerry QNX Hypervisor 或 ACRN。8295 的虚拟化硬件支持很好，IOMMU 和 SMMU 都能用上。
避坑指南：我曾经在一个项目里，把仪表和 IVI 放在同一个 Linux 上，用容器隔离。结果 IVI 的 GPU 驱动崩了，仪表直接黑屏。后来改成 Hypervisor 硬隔离，再也没出过这个问题。
显示同步与帧率管理
多屏同步，说白了就是让仪表和 IVI 的画面不要「错位」。8295 的 DPU 支持硬件 VSync 同步，但需要软件配合。
我总结了几条经验：
- 仪表和 HUD 必须使用硬件 VSync：软件同步延迟不可控，安全域不能用。
- IVI 和后排娱乐可以软件同步：允许 1-2 帧的延迟，不影响体验。
- 帧率不要一刀切：仪表 60fps 保证流畅，后排娱乐 30fps 省带宽，IVI 动态调整。
核心指标：仪表屏的帧渲染延迟必须控制在 16ms 以内，否则会出现「画面撕裂」。我见过一个项目，仪表帧率掉到 45fps，驾驶员投诉说「指针在抖」。
带宽预算与内存规划
多屏系统最容易被低估的就是带宽。8295 的内存带宽是 68GB/s，听起来很多，但四屏同时跑起来，很容易吃满。
我建议做这样的预算：
| 屏幕 | 分辨率 | 色深 | 帧率 | 带宽需求 |
|---|---|---|---|---|
| 仪表 | 1920x720 | 24bit | 60fps | ~2.5 Gbps |
| IVI | 1920x1080 | 30bit | 60fps | ~3.7 Gbps |
| HUD | 1280x720 | 24bit | 60fps | ~1.3 Gbps |
| 后排娱乐 | 1920x1080 | 24bit | 30fps | ~1.9 Gbps |
| 合计 | ~9.4 Gbps |
我的建议：留 30% 的余量，也就是实际带宽需求控制在 7 Gbps 以内。8295 的显示引擎有 4 个 DPU，每个 DPU 独立处理，不会互相抢占带宽。
总结一下关键点
- 架构：安全域和信息域必须物理隔离，Hypervisor 是首选。
- 接口：DSI 给短距低延迟屏，DP 给长距高分辨率屏，eDP 给内嵌屏。
- 同步：安全域用硬件 VSync，信息域可以软件同步。
- 带宽：做好预算，留余量，别让内存带宽成为瓶颈。