1. R-Car多屏图形系统总览
Renesas R-Car 系列是面向车载信息娱乐、数字座舱与仪表显示的 SoC 家族，其图形与显示子系统并不是单一 GPU 的“画图能力”，而是由 GPU、显示控制器（Display Controller）、显示接口、内存带宽与软件栈共同构成的流水线。理解这条流水线的分工，是后续做多屏渲染、分辨率规划、性能调优与问题定位的基础。
一、R-Car SoC 家族与显示子系统定位
R-Car 家族按算力与集成度大致可分为入门级（如 R-Car E 系列）、主流座舱级（如 R-Car M 系列、R-Car H 系列）以及面向更高阶座舱与域控的 R-Car H 高配与 R-Car X 系列。不同型号在 CPU 核数、GPU 型号、显示通道数量、视频输入输出接口上存在差异，但显示子系统的组织方式具有共性：GPU 负责把应用提交的绘制命令渲染成像素，显示控制器负责从显存中按扫描时序读取图层并合成，最终通过 MIPI DSI、LVDS、HDMI 或 DP 等接口送到屏幕。
需要特别区分两个概念：渲染分辨率是 GPU 实际绘制的像素规模，显示分辨率是显示控制器扫描输出的像素规模。多屏场景下，两者可以不一致，例如仪表以 1920×720 渲染后由显示控制器缩放输出，中控以 1920×1080 原生输出。工程上必须明确每一路屏幕的时序、图层数量与像素格式，否则容易出现带宽不足或撕裂。
二、多屏应用场景与典型拓扑
典型座舱多屏包括：全液晶仪表（约 12.3 英寸、1920×720 或 1280×480）、中控主屏（约 12～15 英寸、1920×1080）、副驾娱乐屏（1920×1080）、HUD（抬头显示，分辨率较低但刷新与延迟敏感）以及后排娱乐屏。这些屏幕对实时性、安全等级和刷新率的要求不同：仪表与 HUD 通常要求稳定帧率与低延迟，中控与副驾更关注交互流畅与视频播放。
从系统拓扑看，多屏可以由同一 GPU 分时渲染多个 surface，再由多个显示控制器分别扫描输出；也可以由 GPU 渲染后通过共享显存交给不同显示通道。关键约束是显存带宽与图层合成能力：每增加一路 1080p60 的 RGB888 图层，扫描读取带宽约为 1920×1080×4 字节×60 ≈ 497 MB/s，多图层叠加后带宽需求迅速上升。
三、GPU 与显示控制器的协同关系
GPU 与显示控制器之间通过帧缓冲和同步机制协作。GPU 完成一帧渲染后，通过 fence 或 VSync 信号通知显示控制器可以读取该缓冲；显示控制器在垂直消隐期切换缓冲地址，避免撕裂。多屏场景下，如果多个显示控制器共享同一 GPU，需要合理分配渲染优先级：仪表通常需要固定 60fps 且延迟稳定，中控可以接受一定波动，因此工程上常把仪表 surface 设为高优先级，并限制中控的 GPU 占用。
另一个关键点是图层合成策略。显示控制器通常支持若干硬件图层（如 4～8 层），可以叠加视频层、图形层和光标层。如果应用提交的图层数超过硬件能力，就需要 GPU 先做离屏合成，再作为一个图层交给显示控制器。这会增加 GPU 负载和显存带宽，因此多屏设计时要尽量让视频播放走硬件视频层，UI 走 GPU 图层，减少不必要的合成。
四、工程开发流程与工具链概览
典型开发流程如下：首先确认目标 R-Car 型号的显示通道数量、GPU 型号与支持的接口；然后在 BSP 中配置显示时序（分辨率、刷新率、前后肩、像素时钟）和引脚复用；接着在 Linux 侧配置 DRM/KMS 或专有显示驱动，把每路输出映射为独立的 CRTC 与 connector；再在应用层使用 Wayland、Qt 或 OpenGL ES 提交渲染内容；最后通过工具观察帧率、GPU 占用、带宽与延迟。
常用工具包括：modetest 查看和设置 DRM 显示模式，glmark2 或 gfxbench 评估 GPU 渲染性能，perf 与厂商提供的 GPU 性能计数器观察负载，vblank 相关接口检查刷新同步。调试多屏问题时，先确认每路 connector 是否正常识别，再检查 CRTC 是否绑定正确，最后看帧缓冲格式与带宽是否匹配。
五、多屏带宽与性能的初步估算示例
假设某座舱方案包含三块屏：仪表 1920×720@60、中控 1920×1080@60、副驾 1920×1080@60，像素格式均为 RGB888（4 字节/像素）。仅扫描输出带宽约为：仪表 1920×720×4×60 ≈ 332 MB/s，中控与副驾各约 497 MB/s，合计约 1.33 GB/s。若 GPU 还要渲染并写入这些帧缓冲，则写入带宽与扫描读取带宽叠加，实际 DDR 压力更大。因此工程上常采用压缩（如 AFBC）、降低副驾刷新率或使用 YUV 格式来缓解。
需要强调：以上数值为教学示例估算，实际带宽受 DDR 效率、图层叠加、压缩比和访问模式影响，必须以实测为准。掌握这套估算方法，可以在方案阶段快速判断某组屏幕配置是否可行，避免后期返工。
六、本节要点回顾
- R-Car 显示子系统由 GPU、显示控制器、显示接口和共享显存构成，分工明确。
- 多屏场景的核心约束是 DDR 带宽、显示控制器图层数和刷新同步。
- GPU 与显示控制器通过帧缓冲和 VSync/fence 协同，仪表等高实时性屏幕应优先保障。
- 开发流程从 BSP 时序配置到 DRM/KMS 映射，再到应用层渲染与工具验证。
- 带宽估算应在方案阶段完成，示例数值仅作方法演示，最终以实测为准。