4、GPU与显示处理：GPU架构、显示输出接口（LVDS/eDP/DP）、多屏异显技术
4.1 GPU架构：不只是算力堆砌
说到智能座舱的显示，GPU是绕不开的核心。很多人一上来就问「GPU算力多少TOPS？」。说实话，这个指标在座舱场景里有点被过度神话了。
我个人的习惯是，先看GPU的架构设计。座舱GPU和桌面GPU不一样。它不需要跑《赛博朋克2077》，但它需要同时处理4块屏幕，还要保证仪表盘指针的60fps不掉帧。
目前主流方案分三类：
- 独立GPU：比如NVIDIA的Xavier/Orin系列。性能强，但功耗高，散热压力大。我做过一个项目，Orin芯片的散热片占了整个PCB面积的1/3。
- 集成GPU：高通SA8295、三星Exynos Auto V920这类。GPU和CPU共享内存，延迟低，成本可控。现在中高端座舱基本都走这条路。
- 显示协处理器：像瑞萨R-Car H3里的IMG PowerVR。专门处理2D合成和图层叠加，功耗极低。适合做仪表盘这种安全等级高的场景。
关键点：座舱GPU的核心能力不是「算力峰值」，而是「多路显示并发」和「低延迟合成」。你想想看，仪表盘和娱乐屏同时刷新，如果GPU调度不好，就会出现「撕裂」——左边指针跳了，右边导航还在卡。
我记得有一次调试，发现仪表盘偶尔闪一下。查了三天，最后发现是GPU的图层混合单元在切换分辨率时，缓冲区没清干净。嗯，这种坑，文档里根本不会写。
4.2 显示输出接口：LVDS、eDP、DP怎么选？
接口选型，说白了就是「带宽」和「距离」的博弈。我列个表，大家一看就明白：
| 接口类型 | 最大带宽 | 传输距离 | 典型分辨率 | 座舱场景 |
|---|---|---|---|---|
| LVDS | ~1.0 Gbps/对 | 5-10米 | 1920x1080@60fps | 仪表盘、后视镜 |
| eDP 1.4 | ~8.1 Gbps/通道 | 0.5-1米 | 3840x2160@60fps | 中控屏、副驾屏 |
| DP 1.4 | ~32.4 Gbps | 3-5米 | 7680x4320@60fps | 后排娱乐、HUD |
LVDS：老将了。抗干扰能力强，线束也便宜。但带宽是硬伤。4K屏就别想了。我建议仪表盘这种安全关键场景，还是用LVDS。为什么？因为它差分信号，共模抑制比高，电磁干扰下不容易丢帧。
eDP：现在座舱的「万金油」。支持动态刷新率，可以省电。我做过一个项目，中控屏用eDP 1.4，跑2K分辨率，线长控制在30cm以内，信号质量非常好。注意，eDP对线缆质量很敏感。我曾经因为用了便宜的FPC排线，导致屏幕边缘出现「水波纹」——换了一根屏蔽好的排线，问题立刻消失。
DP：带宽怪兽。适合做多屏拼接或者8K HUD。但DP的协议栈比较复杂，需要额外的AUX通道做握手。如果你用DP做仪表盘，一定要考虑启动时间——DP链路训练需要几百毫秒，而LVDS几乎是即插即用。
我的经验：如果项目预算允许，中控屏优先选eDP，仪表盘选LVDS。DP留给后排娱乐或者AR-HUD。这样既保证了性能，又控制了成本。
4.3 多屏异显技术：让每块屏各司其职
多屏异显，说白了就是「一块SoC，驱动多块屏幕，显示不同内容」。听起来简单，做起来坑不少。
先讲技术原理。GPU内部有多个显示控制器（Display Controller）。每个控制器独立管理一个屏幕的时序、分辨率和刷新率。比如高通SA8295有4个显示控制器，可以同时驱动仪表盘、中控、副驾和HUD。
关键点在于图层合成。每个屏幕可能有多个图层：仪表盘有指针层、背景层、报警图标层；中控有导航层、媒体层、空调控制层。GPU需要把这些图层合成到一个帧缓冲区，再通过显示接口输出。
我遇到过最头疼的问题：多屏同步。仪表盘和中控屏如果刷新率不同步，就会出现「视觉错位」——比如导航转弯提示已经变了，仪表盘上的箭头还指着直行。
避坑指南：我曾经在一个项目中，用了两个独立的显示控制器，分别驱动仪表盘（60Hz）和中控（30Hz）。结果发现，中控屏的动画总是比仪表盘慢半拍。后来查了芯片手册，发现这两个控制器共享同一个PLL时钟源。解决办法是：把中控屏的刷新率也改成60Hz，或者用「垂直同步信号」做硬件同步。
多屏异显的软件架构，我建议用虚拟显示的方式。什么意思？就是在操作系统里，把每块物理屏幕映射成一个独立的「虚拟显示器」。应用层只需要往对应的虚拟显示器上画图，底层驱动负责合成和输出。
代码层面，以Linux DRM（Direct Rendering Manager）为例：
// 伪代码：多屏异显配置
struct drm_mode_create_dumb dumb;
dumb.width = 1920;
dumb.height = 1080;
dumb.bpp = 32;
ioctl(fd, DRM_IOCTL_MODE_CREATE_DUMB, &dumb);
// 为每个屏幕创建独立的framebuffer
for (int i = 0; i < screen_count; i++) {
drmModeAddFB(fd, width, height, 32, 32,
dumb.pitch, dumb.handle, &fb_id[i]);
drmModeSetCrtc(fd, crtc_id[i], fb_id[i], 0, 0,
&connector_id[i], 1, &mode[i]);
}这段代码看起来简单，但实际调试时，你会发现帧缓冲区分配是个大坑。如果所有屏幕共享同一个缓冲区，那一个屏幕的更新会影响其他屏幕。我建议每个屏幕分配独立的缓冲区，然后用GPU的DMA引擎做异步刷新。
4.4 实战建议：从选型到调试
最后，我总结几条实战经验：
- 先定屏幕，再定GPU。屏幕的分辨率、刷新率、接口类型，直接决定了GPU的选型。别先买了Orin，才发现屏幕只支持LVDS。
- 预留带宽余量。GPU的显示接口带宽，建议留20%的余量。比如4K@60fps需要约12Gbps，那eDP 1.4的8.1Gbps就不够，得上DP或者eDP 1.5。
- 重视EMC测试。座舱里电磁环境复杂，LVDS和eDP的差分信号容易受干扰。我建议在PCB布局时，把显示信号线走在内层，两侧用地线包裹。
- 多屏同步用硬件。别指望软件做帧同步。用GPU的「垂直同步锁相环」或者外部的「帧同步芯片」，才是靠谱的方案。
一句话总结：GPU选型看架构，接口选型看带宽，多屏异显看同步。这三样搞定了，座舱显示系统就稳了八成。
嗯，今天就聊到这儿。下一章我们讲音频处理——那个坑更多，我到时候再细说。