中端车规SoC上的三屏3D座舱：GPU负载约30%的RaaS实现路径

从 2D 静态表盘到 3D 实时交互，座舱 HMI 承载的内容这几年变化很快。把一个 3D HMI 从 demo 做到量产，卡点通常不仅限于渲染效果，更重要的是中端车规平台上的一笔资源账——多屏、多域、多个 3D 场景，如果每一处都起一套渲染引擎，中端 SoC 的算力和内存撑不住。Outpace 要回答的就是这个问题。

Outpace 是我们面向汽车行业做的一套全场景座舱 HMI 技术方案，今年 4 月在北京车展上展示过。硬件是一颗中端车规 SoC——联发科 MT8676，配 7680×936 的 8K 一体屏，系统为 Android Automotive，同时部署仪表、中控和副驾。

中控把 Qt Quick 3D 渲染的画面融入安卓应用框架，承载 3D 车模与车控车设；仪表完全由 Qt 实现，2D 叠加 3D，引入实时数据驱动的 ADAS SR（surrounding reality）背景，还原车辆、行人、信号灯、斑马线这些道路元素。车模约 20 万面，加上背景工作室，整个场景三十几万面。

Outpace 的目标是验证在中端平台上实现功能完整，效果丰富，同时性能有余量的座舱方案。

我们几年前做过一批 demo，包含仪表、中控和 ADAS SR，这些 demo 现在以开源形式随 Qt Design Studio 提供。它们单看效果和功能都算完整，问题是彼此不连通，也匹配不上真实的车机架构，最后只能作为 3D 能力的展示。这几年项目多起来之后，低端到高端各种芯片平台上都有了量产项目，Qt 在汽车行业的平台版图也因此铺开——不同的平台，关注点是不一样的。

Qt 在汽车行业的低端／中端／高端平台版图（Entry / Standard / Premium 与对应芯片、场景）——替代平台分档的文字展开

现在行业里常见的是 Linux 或 QNX 加 Android Automotive，靠 Hypervisor 虚拟化实现仪表与中控的多屏混合架构渲染。如今的汽车HMI 功能已经不是单个应用的就能满足的，而是一个系统性的生态需要搭建。

选型一个 3D 引擎时，要看三个要素：渲染效果、与系统架构的协同能力、性能与硬件成本的平衡。单一 Qt App 架构无法满足当前汽车 HMI 对系统生态的需求。

Outpace 采用的是 Qt 为汽车架构专门做的 Rendering as a Service（RaaS）。它将 Qt 引擎的渲染能力封装成一个系统级渲染服务service，以 Service 形式后台运行：Qt 只负责渲染，把渲染 Buffer交给 Android 的 Surface。

仪表跑在 Linux 或 QNX 上，安卓侧运行中控 3D 背景、车控车设和 ADAS SR。

Qt + Android + Linux/QNX 混合部署架构示意

RAAS 的 Qt 源码实现中，同步机制上与安卓的 VSync 信号每帧触发一次，驱动 GUI 线程与渲染线程握手，并用信号量保证两个线程同步；一次 render() 共享绘制，更新 N 张图层纹理，再分发到各自独立 swapBuffers 的 Surface。刷新节拍由安卓端定、Qt 侧跟随，多屏合成时才不会各跑各的频率。

RaaS 架构设计图（VSync 信号源 → VSync Thread → GUI 线程／渲染线程握手 → 多纹理 → 多 Surface，含四个特点标注）

由此形成 Qt Render Service 的四个特点：

1. 单进程共享渲染资源——所有安卓客户端和 Activity 共用同一份 GL 上下文与场景图逻辑，只起一个 Qt引擎，即可获得 2D，3D 混合场景渲染结果。

2. 一次渲染、多路部署——无论 Launcher 还是 ADAS，都不必在进程里各起一套 3D 场景。

3. 完全离屏，渲染与呈现解耦——引擎底层不显示任何东西，呈现方式和生命周期统一由安卓控制。

4. 与安卓频率对齐——VSync 属于安卓端的刷新信号，多屏合成时不容易出现丢帧或撕裂。

整个 HMI 分为四层：外部环境与数据源、安卓系统层（渲染服务、主页处理服务、可选服务）、Qt RaaS 核心层（统一 3D 场景、通信层、ADAS SR 数据适配），以及三块屏的应用层。层与层之间明确解耦，换平台、换数据源、换项目 IP，只需替换对应那一层的模块实现——这直接影响后期维护和跨项目的成本。

Outpace HMI 四层模块化架构图（外部环境／Android 系统层／Qt RaaS 核心层／应用层）——替代分层结构的逐层文字说明

ADAS SR 数据链路图（数据源 → DataAdapter → RaaS 渲染服务 → SR 渲染输出）

现在让我们从系统性能的角度来看，将最消耗性能的 ADAS SR 拆开看，它的性能消耗主要集中在两处。

一是场景里的目标车辆。 小轿车、大巴、行人高频出现和消失，传统做法是逐个创建几何体、逐个管理状态，CPU 开销随目标数线性增长。改用 Qt Quick 3D 的实例化渲染（instancing）后，所有目标共享同一个网格（Mesh），灯光、车门、位置按实例存入状态缓冲，交给 GPU 批量渲染。合并之后，CPU 与 GPU 的握手次数不再随目标数增长，CPU 开销也就保持平稳。

传统方案 vs 实例化方案对比图

二是车道线的点集数据。 难点不在有几条，而在每一帧数据都在变。逐帧重建网格、重传顶点缓冲，CPU 到 GPU 的开销会非常大。Outpace 把车道线点集编码进一张纹理，由 GPU 着色器采样绘制，CPU 只更新这张纹理。更新一张纹理的成本是固定的，与点集规模无关。

传统方案 vs 动态纹理方案对比图

引擎侧近几个版本的 3D 渲染也在持续优化：RHI 中间层让 2D 与 3D 走同一条渲染链路，工程可迁移、代码库可裁剪；轻量抗锯齿与后处理通过 SceneEnvironment 配置；Qt 6.11 新增 SSGI + SSR 与烘焙的混合模式，静态光照提前烘焙、动态场景实时计算，正好对应 Outpace 里昼夜与天气的转场。

Qt Engine 2D & 3D 统一渲染要点

光照／粒子／骨骼动画的实际画面

ADAS SR（SA8155 Android，Release Qt 6.11，1080 屏 30 FPS）：CPU 均值 28.5%、峰值 48.2%，GPU 均值 30.5%、峰值 40.9%。

ADAS SR 性能曲线图

Outpace Launcher3D（无 ADAS SR）整体场景（MT8676 Android，Release Qt 6.11，8K 屏 30 FPS）的性能测试场景分为静态与动态两组。

静态摆放时 CPU 均值 2.4%、峰值 7.4%，GPU 全程为零。GPU 归零但通过 CPU 的起伏可以说明Qt Quick 3D 的脏区判断在正常工作——GPU 的 0 占用是由于场景图没有脏节点就不重绘，2%–3% 的 CPU 用在输入事件轮询、少量 QML 绑定求值和 RaaS 进程间通信上。

动态场景包含 360 度环视、雨雪粒子、车控车设切换和一镜到底的场景切换，稳态 CPU 均值 36.1%、GPU 均值 31.5%，长时间运行内存无增长。

这组数据里比较关键的一点是：即使在峰值，MT8676 的算力也还留有约一半余量。这是我们判断 Outpace 在这个平台上具备量产可行性的主要依据。

静态场景 CPU／GPU／FPS 曲线图（GPU 归零，FPS = 30）

动态场景 CPU／GPU／内存曲线图（启动资源加载爬坡段、场景切换低谷、内存无增长）

问1：MT8676 能跑多少万面的车模和背景？

答：三十几万面。这是 Outpace 的实际用量——车模 20 万面，背景工作室 10 万面左右；我们没有在这个平台上做过极限测试。考虑到平台算力，车模方向上做了比较大的调整。

问2：Qt 方案是否必须依赖虚拟化板卡？直接在 Linux 环境下能用吗？

答：可以。Qt 是跨平台的，Linux、QNX、Android 都能直接部署，做一些适配即可，我们对嵌入式 Linux 方向的支持一直比较好。

问3：为什么是 Qt 的画面给安卓，而不是安卓的图层给 Qt？

答：确实是 Qt 给安卓。安卓提供一个 Surface 给 Qt，Qt 把渲染好的一帧放进去，安卓拿到后再做生命周期管理或投屏。Qt 引擎只负责渲染，这样无论渲染中控车模还是 ADAS 画面，都在同一个引擎里共享一份资源，内存成本会低一些。

Outpace 想验证的是一件很具体的事：在中端车规平台上，把系统架构、模块解耦和渲染优化这三件事做对，高质量的 3D 座舱是可以落地的，不必等到旗舰芯片。无论是Outpace 项目本身的性能和效果还是 Qt 引擎对于 Automotive 的支持，都在持续进化中，请继续期待。

观看完整研讨会录屏

本文内容来自「汽车电子与软件空中课堂」的一期线上研讨会，主题为《终端芯片如何跑出全景 3D 座舱体验》，由 TCL 驭新智行与 Qt Group 共同支持。研讨会包含两场分享：上半场由 TCL 驭新智行系统架构师杨昌文带来《TCL 驭新智行基于 MT8676 座舱域控平台方案介绍》，讲解 MT8676 的 SoC 选型依据、座舱平台系统架构、音视频子系统设计与虚拟化方案——这也是 Outpace 运行其上的硬件与底软基础；下半场即本文整理的《Outpace：基于 Qt Quick 3D 与 RaaS 架构的智能座舱 3D HMI 方案介绍》。