CarDroid：面向汽车驾驶舱图形密集型任务的容器化架构

《ACM Transactions on Architecture and Code Optimization》：CarDroid: Container-Based Architecture for Graphic-Intensive Tasks in Automotive Cockpits

　　

摘要 AI 总结
要查看此 AI 生成的摘要，您必须拥有高级访问权限。
了解更多 登录
摘要
汽车行业已广泛采用 GPU 用于车载信息娱乐（IVI）系统，该系统支持的应用程序范围从导航到图形密集型游戏。然而，当前的汽车 GPU 虚拟化解决方案通常缺乏车辆驾驶舱所需的效率、灵活性和低开销。在动态工作负载下隔离不足会导致性能波动和延迟，包括在路线规划等对延迟敏感的任务中。

为了解决这些局限性，我们介绍了 CarDroid，一种用于车载系统的 GPU 虚拟化解决方案。CarDroid 有三大主要组件：(1) 一个轻量级容器运行时，用于卸载图形任务并最小化干扰，(2) 跨操作系统缓冲区投影，与 Android 主机共享渲染缓冲区以消除冗余的跨操作系统复制，以及 (3) 一个 PMU 引导的预测器，用于实时资源调整。在测试的工作负载组合中，这些机制将算术平均干扰比率降低了 31.83%，相对于 GPU 直通基线，虚拟化开销溢价为 9.19 个百分点。CarDroid 在 9 家汽车公司的 10 款车型的生产驾驶舱平台上进行了试点和验证。

AI 总结
AI 生成摘要（实验性）
此摘要是由自动化工具生成的，未经文章作者撰写或审阅。它旨在支持发现，帮助读者评估相关性，并协助相邻研究领域的读者理解该工作。它旨在补充作者提供的摘要，后者仍然是论文的主要摘要。全文仍是权威版本记录。点击此处了解更多。
点击此处评论此摘要的准确性、清晰度和实用性。这样做将有助于改进未来的重新生成版本。
要查看此 AI 生成的通俗语言摘要，您必须拥有高级访问权限。

1 引言
现代汽车驾驶舱越来越像紧凑的计算平台，集成了信息娱乐、导航和交互式娱乐。为了提供这些体验，车载系统现在纳入了强大的 GPU；例如，特斯拉与 Valve 合作在高端车型上运行 SteamOS，奥迪和宝马使用 NVIDIA GPU 来驱动高级信息娱乐和 3D 导航功能。由于丰富的应用程序生态系统，Android 已成为 IVI 系统的事实操作系统。

由于电源、冷却和成本限制，车载平台通常包含一个共享于多个驾驶舱功能的单 GPU。将功能整合到共享的车载硬件上使跨功能隔离成为安全问题以及性能问题，并且车载攻击面现已得到充分记录。这需要对 GPU 进行灵活且安全的复用，因为驾驶舱需求会波动——例如，在密集城市驾驶中优先考虑感知工作负载，并在低变化场景中将 GPU 周期重新分配给娱乐任务。虚拟化提供了隔离和动态资源控制的自然机制，但现有的 GPU 虚拟化方法对于 IVI 工作负载仍然不足。

关于 GPU 虚拟化的先前工作主要集中在数据中心环境。现有的 IVI 解决方案要么依赖直通，这阻止了 GPU 共享，要么依赖设备仿真，这需要大量的开发工作和对专有 GPU 内部的了解。如图 1 所示，GPU 直通 IVI 系统遭受严重干扰：共同运行的 Geekbench 使游戏 FPS 降低了 26.0%。

图 1. 在 GPU 直通 IVI 系统中运行《全面战争：三国》@1080p 时的性能下降。当与 Geekbench 共存时，FPS 下降 26.0%。

我们提出了 CarDroid，一个用于 IVI 系统的轻量级 GPU 虚拟化框架，能够实现细粒度的性能隔离和弹性资源供应。CarDroid 引入了硬件切片容器化以实现安全的 GPU 共享，用于双屏 Android 和 3A 工作负载的跨操作系统缓冲区投影，以及一个利用 I/O、缓存和游戏级别信号来动态调整资源分配的 PMU 引导的预测器。CarDroid 是在英特尔的 ASE 部门内部开发的，并在基于 x86 的驾驶舱平台上与汽车制造商进行了试点；该项目随后因业务原因被中止（第 7 节）。

CarDroid 针对的是驾驶舱计算，而不是安全关键的驾驶或车身控制域；那些系统依赖于专用硬件和认证软件栈。

除了集成已知的隔离基元外，CarDroid 做出了三项贡献。首先，跨操作系统缓冲区投影让 Linux 容器能够直接写入 Android 帧缓冲区，将四次跨操作系统复制减少为一次。其次，PMU 引导的预测器将粗粒度的 GPU 分区转换为驾驶舱导航和娱乐工作负载的弹性、工作负载感知策略。第三，CarDroid 提供容器之间的动态、操作系统内 GPU 共享。相比之下，硬件空间分区机制（如 NVIDIA MIG、AMD CU 掩码和 Imagination Hyperlane）依赖于静态配置的 GPU 分区，并且不会在运行时动态调整大小或在单个操作系统内的容器之间共享 GPU 容量（第 3 节）。因此，CarDroid 是这些机制的补充而不是重新实现。

我们的贡献如下：
—我们设计了一个基于容器的 GPU 虚拟化框架，用于 Android IVI 系统，支持图形密集型工作负载且开销最小。
—我们分析了现有 GPU 虚拟化方法的局限性，并引入了硬件切片资源分区，以低复杂度提供隔离。
—我们开发了一种弹性资源分区算法和跨操作系统缓冲区投影，将 FPS 提高了 7.16%，并将额外中断减少了 26.27%。
—我们实现了完整的 CarDroid 原型，并将其与最先进系统进行评估，在测试的工作负载组合中将算术平均干扰比率降低了 31.83%。

2 背景
2.1 IVI 系统中的高效 GPU 共享
随着 IVI 系统的演变，渲染需求持续增长。GPU 虚拟化必须满足三个要求：为图形工作负载提供高性能，其日益增长的内存占用已经使移动 GPU 感到吃力；隔离以防止驾驶舱任务之间的干扰；以及低开销以支持多个并发应用程序。

当前 IVI 部署由两种方法主导：
GPU 直通：如图 2(a) 所示，直通将 GPU 专用于运行图形工作负载的 Linux 虚拟机，而 Android 则回退到基于 CPU 的渲染。尽管已商业使用（例如在特斯拉中），直通排除了虚拟机之间的 GPU 共享。
图 2. IVI 系统中的 GPU 虚拟化选项。直通提供接近原生的性能但无法共享；仿真启用共享但产生开销；CarDroid 提供直接访问同时保持隔离。
设备仿真：图 2(b) 说明了带有 Virglrender 的 virtio-GPU，它启用了硬件加速的 3D 渲染。然而，与直接直通相比，virtio-GPU 会产生仿真开销并存在兼容性限制。

CarDroid 提供了一种使用硬件切片的轻量级替代方案（图 2(c)）。图形密集型任务在 Android 主机上的容器中运行，共享公共内核并利用直接渲染管理器（DRM）子系统进行联合 GPU 调度。这允许直接访问硬件驱动程序，同时通过诸如英特尔 CAT 等机制隔离资源。该模型在不具备设备仿真开发负担的情况下实现了性能和兼容性。

2.2 异构任务的动态资源分区
本小节的测量是我们自己的剖析结果；我们呈现它们是为了激励 CarDroid 的动态分区，而不是作为一般背景。

驾驶舱中的游戏工作负载表现出高度可变的 GPU 和 CPU 需求，使静态分配无效；优先考虑图形会降低导航或系统响应速度。图 3(a) 显示，虽然游戏的平均 GPU 利用率仅为 33.46%，但峰值达到 99.92%，并在暂停期间偶尔降至零。
图 3.《全面战争：三国》@1080p 的资源指标。(a) GPU 利用率。(b) I/O 吞吐量（单独的读取和写入系列，对数刻度）。(c) 缓存未命中率。(d) 游戏和系统事件标签，每种事件类型一行标记。阴影垂直带跨越所有四个面板的相同时间窗口：在每个带内，(d) 中的事件爆发与 (a) 中的 GPU 利用率峰值以及 (b) 中的 I/O 和 (c) 中的缓存未命中的相关变化相吻合，表明这些廉价信号领先于 GPU 需求的变化。在 (d) 中，每个绘制的标记是其事件类型的一次发生：SE（系统事件）、GC（游戏控制）、IGA（游戏内动作）和 SC（场景更改事件）。

监控其他系统指标进一步揭示了工作负载的转变。I/O 吞吐量的增加（图 3(b)）通常表示伴随大量数据加载的场景过渡。缓存未命中率的上升（图 3(c)）与着色器编译相关，这是一种在 GPU 密集型渲染之前发生的受 CPU 限制的任务。频繁的用户交互（图 3(d)）表明即将出现 CPU 和 GPU 需求的峰值。这些观察结果使得能够对即将到来的资源需求进行准确、细粒度的预测。

在此基础上，CarDroid 集成了一种 PMU 引导的预测器，采样 I/O 和微体系结构信号以动态调整 GPU 和 CPU 分配。这确保了流畅的图形性能，同时将空闲的 GPU 容量回收给其他驾驶舱任务。

3 IVI 系统工作负载和生态系统
3.1 IVI 系统用例和工作负载特性
现代 IVI 平台已从媒体仪表盘演变为集导航、连接、多媒体、驾驶员辅助可视化和越来越多的交互式娱乐于一体的多用途计算机系统。这些工作负载必须在严格的汽车功耗和热限制下共享受限的 CPU/GPU/DRAM 预算。

虽然导航和安全功能仍然是德国、美国和中国用户的首要任务，但调查数据显示，从 2021 年到 2022 年，娱乐服务的重要性稳步上升（PwC Digital Automotive Report 2023，每国 1,000 名受访者）。这种转变在年轻用户和高端细分市场用户中最为明显，他们报告的支付意愿也更高（例如，中国几乎为每月 40 欧元，而欧盟/美国为每月 20 欧元）。这一趋势与特斯拉街机和奥迪 holoride 系统等商业部署相一致，这些系统将实时 GPU 密集型工作负载带入驾驶舱。

在整个过程中，我们将使用"3A"（AAA）游戏（如《黑神话：悟空》和《赛博朋克 2077》等高预算游戏）作为压力工作负载，因为它们会产生沉重且突发的 GPU 需求。在这些工作负载下保持隔离的设计也应能够容纳较轻松的娱乐工作负载，如云游戏和休闲游戏。与合成基准不同，这些是具有复杂渲染管道的商业应用程序。

IVI 需求现在分为两类：可预测、对延迟敏感的导航工作负载（地图渲染、ADAS 叠加层），以及具有突发带宽需求和较大帧时间差异的受 GPU 限制的娱乐工作负载（例如云游戏）。这些特征意味着 (1) IVI 工作负载是双峰的，(2) 对于单 GPU 汽车 SoC，静态 GPU 分区效率低下，以及 (3) 导航和娱乐工作负载的弹性共存正在成为基本要求：OEM 驾驶舱计划越来越多地在与导航相同的 SoC 上提供娱乐，使并发支持成为集成要求。

3.2 案例研究：IVI 中的游戏与导航
为了量化传统 IVI 工作负载与新兴 IVI 工作负载之间的差距，我们比较了高德地图（中国使用最广泛的导航应用）和 Unigine Valley 基准测试（图形密集型 3D 工作负载）在相同的 CarDroid 评估设置下的 GPU 利用率（表 3）。图 4 中的每条追踪是重复测量中的代表性运行。如图 4 所示，导航保持在 15% 以下的利用率且方差低，而游戏则持续保持 70–95% 并频繁出现峰值。
图 4. 在同一 IVI 平台上高德地图导航与 Unigine Valley 3D 工作负载的 GPU 利用率（代表性运行）。导航保持在 15% 以下，而 3D 工作负载持续保持 70–95%。

这些追踪突出了三点：导航工作负载是受 CPU 限制且 GPU 轻量的；游戏工作负载显示出高时间方差；由于导航使大部分 GPU 空闲，因此产生的空闲空间足够大，可以在两个工作负载在单个 GPU 上时分复用时吸收交互式娱乐的 GPU 需求。因此，静态 GPU 分区浪费了资源且无法容纳混合 IVI 场景。

3.3 IVI 硬件和软件生态系统概述
CPU/SoC 格局。IVI SoC 市场由一小群供应商主导。高通占 2023 年中国驾驶舱出货量的 59% 以上，其次是 AMD、瑞萨、三星、德州仪器和芯驰（表 1）。x86 供应商（AMD+ 英特尔）占部署量的近 20%，特别是在离散 GPU 支持桌面级图形管道的高端车辆中——例如，特斯拉的 x86 Ryzen 部件与约 10 TFLOPS 的 Radeon GPU 配对，而主流 Arm 驾驶舱 SoC（如高通 SA8155P）则集成了 Adreno 640。

表 1. 2023 年顶级 IVI SoC 供应商（中国）
供应商 出货量 市场份额 ISA
高通 2,261,869 59.20% Arm
AMD 575,628 15.10% x86_64
瑞萨 327,877 8.60% Arm
英特尔 173,960 4.60% x86_64
三星 152,206 4.00% Arm
德州仪器 134,599 3.50% Arm
芯驰（SemiDrive） 60,152 1.60% Arm
NVIDIA 49,997 1.30% Arm
展锐（Ingenic） 38,358 1.00% MIPS/RISC-V
华为 21,923 0.60% Arm

硬件 GPU 分区是 CarDroid 最接近的替代方案。NVIDIA MIG 将 GPU 划分为多达七个固定实例，AMD CU 掩码是一种队列级机制，将队列限制为所选的计算单元子集，而 Imagination 的 Hyperlane 暴露了类似的硬件 vGPU。最近的工作在硬件级别分区 NVIDIA GPU 计算容量以实现可组合实时系统，并且最近对 MIG 的汽车评估报告了我们在下文指出的相同静态配置限制。这三者对于驾驶舱工作负载都有两个局限性。(i) 静态配置的分区：分区几何形状是在带外设置的——对于 MIG 和 Hyperlane 是在虚拟机或实例创建时，对于 CU 掩码是通过预设 CU 掩码——并且不会根据运行时需求进行调整大小。

因此，它无法跟随图4中的导航/娱乐波动：为峰值游戏而划分的切片在导航期间会闲置容量，而为导航而划分的切片则无法满足游戏需求。

（ii）粗粒度所有权：MIG 和 Hyperlane 将每个切片绑定到独立的虚拟机，而 CU 掩码将计算单元限定到一个队列；这些方案都没有在单个 Android/Linux 实例内的多个应用之间共享并动态调整 GPU 容量——而这正是车载信息娱乐系统（IVI）的常见部署模式。因此，静态分区无法在随时间变化的混合负载中回收空闲的 GPU 容量。CarDroid 则在单个操作系统内核内动态共享 GPU 资源。两者是互补的，因为 CarDroid 也可以对硬件切片进行细分。

**操作系统与部署模式。** 如表2所示，现代 IVI 部署通常组合多个操作系统——例如，QNX 用于安全功能，Linux/Android 用于信息娱乐。这满足了认证要求，但也增加了碎片化：应用必须在不同操作系统之间移植，服务无法共享，GPU 资源往往被静态绑定到单一操作系统。

**表2：主流 IVI 操作系统对比**

| 属性 | QNX | Linux | Android |
|------|-----|-------|---------|
| 内核 | 微内核 | 单体内核 | 单体内核 |
| 实时性 | 高 | 中 | 中 |
| 功能安全 | 高 | 中 | 低 |
| 生态系统 | 有限 | 中等 | 成熟 |
| 典型领域 | 安全/仪表 | 仪表/IVI | 信息娱乐 |

降低操作系统级别的碎片化，或将应用与操作系统选择解耦，将有助于简化 IVI 集成并实现跨域资源共享。这正推动了 CarDroid 等设计，旨在支持图形密集型游戏级工作负载，使其在异构 IVI 环境中运行。

---

## 4 CarDroid 架构

### 4.1 概述

图5展示了 CarDroid 的架构，这是一款面向图形密集型任务的轻量级 IVI 虚拟化方案。标准 IVI 应用（音乐、导航、浏览）运行在 Android 主机上，并通过 Android 原生图形栈（包括 SurfaceFlinger 和 HWComposer）进行渲染。

**图5：CarDroid 概述，可同时运行 IVI 任务和图形密集型应用。硬件切片容器确保 GPU 隔离，PMU 引导的预测器动态分配资源，缓冲区投影减少开销。**

对于资源密集型应用，CarDroid 通过容器运行时启动硬件切片容器，提供专用的硬件资源和隔离。

跨操作系统缓冲区投影使 Linux 容器可以渲染到与 Android 主机共享的缓冲区，Android 主机再通过其原生图形栈呈现帧；这消除了传统路径中冗余的跨操作系统数据拷贝，降低了系统延迟。

内核级预测器根据实时 I/O 和 GPU 利用率动态重新分配资源，确保非关键任务不会影响导航等关键任务。

### 4.2 硬件切片容器化

如 §2 所述，直通和仿真都无法提供高效且隔离的 GPU 共享。CarDroid 通过硬件切片容器运行时技术解决了这一问题，在硬件层面分配专用 GPU 资源，减轻数据泄露和任务干扰。

**CPU 绑定：** 容器在专用物理核心上运行。CPU 绑定同时具有性能和安全两方面的效果。在性能方面，防止核心在容器之间共享可减少执行和缓存资源的争用，而后者是延迟敏感的车舱任务中协同放置抖动的一个重要来源。在安全方面，专用物理核心可防止不可信任务通过 SMT 兄弟核心共享被缓存和执行端口侧信道利用的微架构状态。这两种效果都源于消除跨容器共享。绑定仍然兼容动态分配：CarDroid 根据负载调整容器持有哪些核心以及持有多少核心，连同其 GPU 权重和 CAT 方式（见第4.4节）。已分配的核心仅在当前的分配周期内保持固定，以避免迁移开销并维持稳定的隔离边界。

**缓存动态分区：** Intel 的缓存分配技术（CAT）为每个容器分配专用的 CPU 末级缓存（LLC）部分，按缓存方式划分，并由第4.4节中的启发式方法在运行时调整大小，消除跨任务的 LLC 污染及相关的侧信道。我们明确说明其适用范围：CAT 仅分区 CPU LLC。它不分区 GPU 内部缓存，也不分区共享的 DRAM 带宽和内存控制器队列，在这些位置仍可能存在残余争用——以及，在原理上的争用侧信道。CarDroid 通过时间域上的加权 GPU 时间切片（见下文）来缓解 GPU 侧的干扰，而不是在空间上分区 GPU 缓存（消费级 GPU 不暴露此能力）；消除 DRAM 和控制器争用则需要内存带宽分区（如 Intel MBA 或 Arm MPAM），留待未来工作。

**GPU Cgroup：** 基于权重的 GPU 调度器，通过 DRM 框架和 cgroup 实现，根据任务优先级动态分配 GPU 时间。我们引入了两个 cgroup 接口文件：`drm.weight` 用于每个任务的权重，`drm.active_us` 用于跟踪随时间的 GPU 使用情况。CarDroid 在时间域而非空间域上共享 GPU：DRM 调度器根据 `drm.weight` 的比例在容器之间对单个 GPU 进行时间切片，而不是像 NVIDIA MIG 或 AMD CU 掩码那样分配固定的执行单元。加权时间切片是多任务 GPU 共享的通用基础 [14]；CarDroid 在单个车舱操作系统内核内应用它，并通过第4.4节中的运行时启发式来驱动权重。切换复用 GPU 驱动程序在作业提交边界处已有的上下文切换路径，因此较高权重的导航/安全容器会在下一个边界处优先于较低权重的游戏被调度。CarDroid 不会在运行中的内核中间进行抢占或检查点 GPU 状态；重新调度仅在这些提交边界处发生。这对车舱场景已经足够，因为游戏工作以有界持续时间的逐帧命令批次形式提交——通常为单个 16–33 毫秒的帧，即使负载较重也通常在 100 毫秒以下——因此更高优先级的容器最多只需等待约一帧即可获得 GPU，从而在不付出内核中间抢占代价的情况下限制了服务延迟。这避免了启动时的空间切片，代价是在时间域而非硬件中执行隔离。

### 4.3 跨操作系统缓冲区投影

GPU 直通将 GPU 专属于某个虚拟机，无法同时加速导航和娱乐。CarDroid 使用硬件切片容器在两者之间共享 GPU。

CarDroid 不是虚拟机监视器设计：它不像 Hyper-V 等 VMM 那样将 Android 和 Linux 作为来宾运行，而是 Linux 图形容器和 Android 主机共享同一个内核，"跨操作系统"指的是在该共享内核之上连接 Android 用户空间图形栈和容器的 Linux 用户空间。这正是使直接的帧缓冲区投影成为可能的原因——不存在需要跨越的来宾/主机内存边界。

图6对比了两种管线。在传统方案（图6(a)）中，容器的渲染命令需要经过容器的合成器、HWComposer 和 DRM，需要四次跨系统数据拷贝。CarDroid（图6(b)）将 Android 帧缓冲区的一部分直接映射到 Linux 容器，并通过 Android 的 SurfaceFlinger 呈现容器的帧，将拷贝次数减少到一次并降低了延迟。

**图6：跨操作系统缓冲区投影管线：Linux 容器渲染到与 Android 共享的缓冲区，Android 通过其原生图形栈（SurfaceFlinger 和 HWComposer）呈现帧；这消除了传统路径中四次的跨操作系统拷贝，降低延迟和系统开销。**

关键挑战在于帧同步。CarDroid 将渲染与显示时间解耦：容器预渲染帧，缓冲区交换与 Android 的 vsync 信号同步，防止撕裂和丢帧。

具体而言，投影按四个步骤进行。（1）在容器启动时，CarDroid 将 Android 帧缓冲区的目标区域作为 DMA-BUF 导入，并通过共享内核将其文件描述符共享给容器。（2）容器渲染到这个共享缓冲区，并将其作为 surface 提交给 Android 的 SurfaceFlinger，使帧由 Android 直接合成而非跨系统拷贝。（3）缓冲区交换与 Android 的 vsync 同步，仅在主机刷新边界处发布容器的翻转。（4）Android 的 HWComposer 呈现投影区域时不需要额外的合成拷贝。步骤（1）–（2）消除了图6(a)中四次拷贝中的三次；步骤（3）保证了无撕裂显示。

### 4.4 PMU 引导的预测器

CarDroid 在运行时通过轻量级反应式启发式调整资源——而非学习或预测模型——由性能监控单元（PMU）和操作系统计数器驱动。我们有意保持其简单，以便在汽车平台上易于推理其成本和行为。

**为什么选择这三个信号。** 该启发式监控三个信号，我们的剖析（图3）显示它们领先于 GPU 需求的变化：（i）I/O 吞吐量，其峰值标志着资源流加载和场景加载，会很快提高 GPU 和显存压力；（ii）用户输入率，先于交互驱动的 CPU 和 GPU 突发；（iii）LLC 缺失率，在着色器编译期间上升，而着色器编译是 GPU 密集渲染之前的 CPU 密集型阶段 [6, 9]。它们是争用的先行指标，而非穷举集合；可以添加其他计数器。

**策略。** 每个控制周期——在原型中是一个显示帧（60Hz 时约 16 毫秒）——控制器采样这三个信号并应用阈值规则。如果某个信号连续几个周期（约 67 毫秒）保持在高位水位以上，CarDroid 将前景容器的分配提高一级：前景对背景的 `drm.weight` 比例提升一级（例如，1:1→2:1→3:1），前景的 CAT 掩码增加一个缓存方式。一旦所有信号在一个保持窗口（约 0.5 秒）内保持在低位水位以下，则衰减分配并回收资源供其他车舱任务使用。独立的高/低位水位加上保持窗口（滞回）防止振荡，并且水位值按平台离线配置而非在线学习。我们根据图3的剖析设定它们以框住每个信号的观测到的空闲与突发间隙：I/O 吞吐量 10/1 MB/s（基线约 0.1 MB/s，场景加载峰值在图3(b)中超过 100 MB/s），LLC 缺失率 50%/35%（基线约 35%，着色器编译峰值在图3(c)中接近 55%），用户输入突变为每秒几次事件与场景间近乎空闲相比（图3(d)）。

**采样成本与观测者效应。** 每个周期的成本是三次计数器读取加上少量比较，每帧轮询一次而非每次中断，因此决策工作量在 16 毫秒帧预算下约为微秒量级——远低于 0.1%；我们将其表述为基于第一性原理的上界，而非单独测量的数值。读取 LLC 缺失计数器确实会扰动它所测量的缓存，因此我们将缺失率视为粗略趋势；粗略采样使这种扰动保持较小。

**计数器争用与优雅降级。** PMU 计数器是有限且共享的硬件资源。如果启发式所需的计数器被其他分析器占用，则回退到最后一个静态权重和 CAT 分配，因此正确性从不依赖于 PMU 的可用性。

**优先级。** 导航和其他延迟敏感的容器具有较高的基线 `drm.weight`，因此调度器在每个提交边界处将它们优先于游戏调度。CarDroid 专注于在繁重游戏负载下保持这些交互式车舱任务的响应性，为信息娱乐域提供有界的帧级优先级。

**与更简单策略的对比。** 该启发式涵盖两个自然的基线——纯 GPU 时间切片和仅基于 CPU 亲和性的分配——我们在图7中对它们进行了隔离：两者都留下了显著的干扰，而权重大加 CAT 的组合启发式可以消除。一个闭环替代方案是基于反馈控制的 GPU 调度，它使用正式控制器调节实时嵌入式 GPU 工作负载 [29]；我们有意选择阈值规则来交换该控制器更强的保证，因为阈值规则在生产级车舱 SoC 上的最坏情况成本可以轻松限定。

**图7：Rodinia 基准测试与 stress-ng 的协同放置：时间共享利用 Docker 的时间切片分配方法（50%时间切片），基于亲和性分配 48 个 CPU 核心中的 28 个专用核心，而 CarDroid 利用硬件切片容器化技术。**

---

## 5 评估

### 5.1 评估设置

我们在 Android 12L 上构建了包含 9,300 行代码的 CarDroid 原型，内核为 Linux 5.15，Mesa 版本为 23.2。据我们所知，CarDroid 是首个面向图形密集型 IVI 应用的轻量级虚拟化方案。我们将它与 GPU 直通和 virtio-GPU 基线进行比较。

我们使用流行的 3A 游戏评估 CarDroid，搭载 Intel Arc A750 显卡（表3）。由于 CarDroid 仅依赖 Android 的图形环境，它可以扩展到任何 Android 支持的 GPU。表4列出了所使用的基准测试。

**表3：硬件和软件规格**

| 平台 | 规格 |
|------|------|
| 硬件切片容器 | Intel(R) Xeon(R) Gold 5317 CPU @ 3.00GHz，24 核 × 2 路 |
| CarDroid & virtio-GPU | Intel i9-11900 @ 3.30GHz，Intel Arc A750 显卡 |
| Tesla 模拟器 | Intel i9-7980XE @ 2.60GHz，AMD 6600 RADV |

**表4：基准测试设置和工作负载**

| 图形密集型游戏 | 设置 |
|---|---|
| 黑神话：悟空 | 高质量 1920×1080 |
| 赛博朋克2077（C2077） | 高质量 1920×1080 |
| 异变工厂（SB） | 超高质量 1920×1080 |
| 古墓丽影：暗影（SOTTR） | 高质量 1920×1080 |
| 全面战争：三国（TWTK） | 超高画质 1920×1080，1. 战斗基准（bb）2. 王朝模式基准（db） |
| 全面战争：战锤（TWW） | 超高画质 1920×1080，1. 战斗基准（bb）2. 战役基准（cb）3. 斯卡文基准（sb） |

| 性能基准 | 设置 |
|---|---|
| Geekbench（GB） | CPU 工作负载 |
| FIO | 随机读取基准 |
| stress-ng（SNG） | 80% CPU 压力 |
| Furmark2 | furmark-glheaven 高质量 1920×1080 |
| OpenVINO | bert-base-ner |

**平台选择及为何选择三个平台。** 尽管 Arm SoC（以高通 59% 领先）主导了 IVI 市场，但 x86 在高端细分市场仍有可观份额（AMD+Intel ≈20%，表1），并搭载于特斯拉等量产汽车中；我们的生产级车舱平台为 x86，因此在 x86 上进行评估。CarDroid 的机制在其他方面与硬件无关：CAT 在 Arm 架构的对应技术是 MPAM，已存在于最近的汽车 SoC 中（例如 NVIDIA Orin 和 Drive Thor），尽管尚未在出厂固件中启用。

表3中的三个平台各自扮演不同角色：Tesla-Simulator基线需要AMD硬件（SteamOS基线需要AMD GPU）；CarDroid和virtio-GPU运行在消费级Intel + Arc A750台式机上；而服务器级Xeon仅用于测试每路CAT[12]，这是Xeon暴露但消费级和当前车规级部件所禁用的功能。这种设置使我们在可用时能够评估每路CAT；但它并不构成车规级验证。

## 该比较能展示与不能展示的内容

由于这三个系统的CPU和GPU不同，跨平台的绝对FPS值无法直接比较。因此，我们将每个系统归一化到其自身裸机性能，并报告相对干扰和开销，从而将虚拟化方案与芯片隔离开来；我们所支持的结论涉及各平台上的这些相对量，而非绝对车规级数值。生产级验证需要在车规级硬件上进行单一SoC的重新评估；当前结果仅刻画了所测试的平台。

### 重复与方差局限性

图4展示了重复测量的代表性追踪数据。对于主要结果图，由于项目缩减后不再保留完整的运行次数和每次运行方差记录，因此我们直接报告所记录的结果，不附加置信区间，也不做统计显著性声明。

我们将干扰比定义为共同放置导致的GPU性能效率降低：

$$\text{干扰比} = \frac{PE_{\text{base}} - PE_{\text{co}}}{PE_{\text{base}}} \quad (1)$$

性能效率 $PE = \frac{\text{FPS}}{\text{GPUUtil}} \quad (2)$

GPUUtil是与FPS相同测量区间上的运行级平均GPU利用率，而非瞬时采样；瞬时零利用率样本包含在该平均值中。如果某次运行的平均GPU利用率为零，则该指标无定义；所有报告的工作负载组合的运行级平均值均非零。正比值表示共同放置导致效率下降；负比值表示效率提升。

我们将干扰比降低报告为所有测试工作负载组合的算术平均值，包括CarDroid干扰比为负的那些组合，不按比值正负进行筛选。

### 基线与方法论

我们以Tesla Simulator作为基线。Tesla Simulator指在AMD GPU上基于SteamOS的GPU直通配置（SteamOS 3/Holoiso配合Proton）——与Tesla用于车内Steam游戏的软件和GPU技术栈相同——GPU由单一游戏操作系统独占。我们选择它是因为直通模式可提供最佳单租户性能，且是目前量产汽车中唯一采用的GPU模型（例如Tesla）；尽管它无法共享GPU——这正是CarDroid所增加的能力——但它仍是一个具有部署相关性的强有力上界。

由于AMD驱动缺乏完整的Android支持，CarDroid无法在AMD基线机器上运行——这正是上述归一化处理所解决的"平台差距"。

## 5.2 评估结果

### 性能隔离

我们共同运行Rodinia（模拟车内任务的负载：图像识别、传感器处理）和stress-ng（CPU/内存/IO压力），以验证隔离性。

如图7所示，时间片轮转（Docker 50%时间片）产生2.03倍归一化运行时间；亲和性绑定（28/48核）将其降低至1.30倍。CarDroid达到接近原生的1.00倍，展现出优越的隔离性能。

### FPS保证

我们将真实基准测试与3A游戏共同运行，以模拟汽车多任务场景。

图8(a)显示CarDroid在大多数情况下优于基线。与FIO共同运行时，CarDroid平均仅损失2.24% FPS，而基线下降高达77.9%（SB+SNG）。唯一例外是TWW+SNG，由于TWW的CPU密集型特性和CarDroid受限的CPU分配，直通基线优于CarDroid。

> **图8** 3A游戏性能(a)和共同放置性能退化(b)。CarDroid在大多数情况下优于基线，受IO密集型任务影响最小，而基线则遭受严重FPS下降和更高退化。

图8(b)比较了CarDroid与基线之间的干扰比。CarDroid在大多数测试中干扰比低于10%，在某些情况下由于PMU引导的预测器更高效地利用了硬件资源，实现了负干扰比。基线干扰比大多超过20%，范围从65.4%到0.01%。

在图8(b)所测试的工作负载组合中，CarDroid将算术平均干扰比降低了31.83%。

## 5.3 性能分解

### 虚拟化开销

如图9所示，CarDroid相比裸机产生18.18%开销，而Tesla Simulator为8.99%——动态分区溢价9.19个百分点。

> **图9** CarDroid与Tesla Simulator的FPS比较。所有FPS均归一化到裸机机器上的FPS。

### 游戏FPS随时间变化

图10展示了SOTTR与Geekbench共同运行的情况。Tesla Simulator（图10(a)）平均FPS下降68%，且波动剧烈导致游戏无法游玩。CarDroid（图10(b)）将下降限制在18%——退化降低50%。

> **图10** 共同放置任务的FPS比较。CarDroid相比基线提供更优越的隔离。

### 缓冲区投射

缓冲区投射使FPS提升7.16%（图11）。DMA拷贝导致中断开销；启用投射后，系统中断相比原生Android图形栈减少26.27%。

> **图11** 原生Android图形栈与缓冲区投射优化的CarDroid之间的FPS（左）和系统中断（右）比较，显示FPS提升7.16%、中断减少26.27%。

## 5.4 案例研究：黑神话：悟空

性能本身并不决定可玩性；游戏还必须正确渲染。由于GPU直通依赖于制造商的原生驱动并实现接近裸机的兼容性，我们将本案例研究集中在比较两种虚拟化方案的游戏兼容性：CarDroid与virtio-GPU。

如图表5所示，virtio-GPU仅支持Steam前10大热门游戏中的1款；CarDroid支持全部10款。virtio-GPU的OpenGL设备模型依赖过时的ToGL翻译器8或逐游戏OpenGL支持——随着现代游戏放弃OpenGL，这一覆盖率正在缩小。图12证实：前10/100/1000大热门游戏中仅10%、27%和29.2%支持OpenGL。CarDroid使用Vulkan和DXVK9，在同一组别中实现100%、87%和85%的兼容性。

| 排名 | 游戏 | virtio-GPU | CarDroid | 历史峰值用户 |
|------|------|-----------|----------|------------|
| 1 | PUBG: BATTLEGROUNDS | ? | ? | 3,257,248 |
| 2 | 黑神话：悟空 | ? | ? | 2,415,714 |
| 3 | Palworld | ? | ? | 2,101,867 |
| 4 | CS2 | ? | ? | 1,818,773 |
| 5 | Lost Ark | ? | ? | 1,325,305 |
| 6 | Dota 2 | ? | ? | 1,295,114 |
| 7 | Cyberpunk 2077 | ? | ? | 1,054,388 |
| 8 | ELDEN RING | ? | ? | 953,426 |
| 9 | Banana | ? | ? | 917,272 |
| 10 | New World | ? | ? | 913,634 |

> Steam最热门的10款游戏。本表展示了Virtio-GPU和CarDroid对Steam上10大热门游戏的兼容性，数据采自2024年9月的SteamDB。Virtio-GPU仅支持列表中1款游戏，而CarDroid支持全部10款。

> **图12** API上最热门的前10/100/1000款游戏支持百分比。数据提取自ProtonDB。OpenGL和Vulkan进行比较，Vulkan将低于银牌徽章的游戏视为不支持。

黑神话：悟空是一款基于虚幻引擎5（Nanite、Lumen）的动作角色扮演游戏，成为历史上最受欢迎的单机游戏。其资源密集度使在虚拟化IVI中流畅运行极具挑战性。

我们将CarDroid与Proton 9.0-2（DX12模式）进行了内置基准测试比较。原始FPS相近，但视觉检查发现Proton-DX12存在渲染错误（图13）——由于着色器处理不正确导致的纹理缺失和过曝区域。在140帧采样中，仅36帧正确渲染，大幅降低了Proton-DX12的有效FPS。

> **图13** CarDroid（左）与Proton-DX12（右）上黑神话：悟空的截图。CarDroid显示正确渲染，而Proton-DX12存在渲染问题。

CarDroid基于Vulkan的渲染全程产生正确输出。在90百分位处，CarDroid的有效FPS是Proton-DX12的3.8倍（图14）。

> **图14** 黑神话：悟空的FPS CDF。CarDroid相比有效基线FPS有3.8倍提升。

## 6 相关工作

### 6.1 汽车平台上的GPU虚拟化

GPU虚拟化使汽车系统中实现高效资源管理和应用隔离成为可能[13]。与桌面方案不同，汽车GPU虚拟化必须在性能、安全性和隔离之间取得平衡[26]。

该领域最早的提案之一是GERM[5]，它专注于公平的GPU资源分配，但缺乏隔离和优先级机制。TimeGraph引入基于优先级的GPU调度，但不受限的执行时间仍可能降低性能[16]。

VADI[19]使图形命令能在单个GPU上并发执行，并使用TrustZone保护GPU和显示设备；TrustZone同样被用于保护通用GPU计算[25]。VADI报告了30 FPS，并在另一域失败时保持数字仪表盘正常运行。然而，其资源分配仍相对不灵活。

CarDroid则使用轻量级容器和动态资源分配。其跨操作系统缓冲区投射与Android宿主共享一个渲染缓冲区，消除了冗余的跨OS拷贝——这是VADI范围之外的问题。

近期工作从相邻角度切入同一平台。硬件计算分区在NVIDIA GPU上组合实时工作负载[3]，MIG的汽车评估刻画了固定硬件实例在车内能实现和不能实现什么[4]；两者都是静态分区而非运行时调整份额。在数据中心，内核空间拦截实现了性能感知的GPU共享，兼具兼容性和隔离[38]，动态自适应超额分配驱动了面向经济性的GPU虚拟化[37]，反馈控制也已被应用于实时嵌入式GPU调度[29]。这些数据中心方案优化的是聚合吞吐量或成本，而非驾驶舱所要求的有界逐帧服务时延。在Android Automotive方面，近期工作保护了不可信Android Automotive OS上的车辆控制[11]，处理了CarDroid视为已知的宿主栈完整性问题。

### 6.2 硬件辅助容器

Docker和LXC等容器系统支持隔离用户空间环境的轻量级部署。10 先前研究比较了Docker与KVM和Hyper-V[17, 24]，并刻画了containerd和CRI-O等运行时的性能和可扩展性[10]。然而，共享宿主内核提供的隔离弱于VM[39]。

硬件辅助系统以多种方式解决此局限。SCONE使用Intel SGX减少对宿主OS或VMM的信任[2]。Google的gVisor则以用户空间内核沙箱化容器，伴有相应的兼容性限制和开销[1]。

Kata Containers[18]和VMware vSphere集成容器将容器封装在VM内。11 这改善了隔离但增加了虚拟化开销，且可能需要嵌套虚拟化，使其不太适合GPU密集型工作负载。

相比之下，CarDroid使用硬件辅助容器而非完整VM封装，允许GPU任务以更低虚拟化开销访问原生驱动栈。

## 7 CarDroid现状

CarDroid使用细粒度硬件切片和动态资源管理来改善汽车驾驶舱中的GPU共享。该项目后因业务原因终止。

在终止前，CarDroid已在9家汽车公司的10款车型中进行试点，包括中国五大电动汽车制造商。这些合作是原型和验证试点而非量产。试点覆盖了图形密集型工作负载，包括游戏、导航和座舱娱乐。我们无法发布这些试点的逐车型测量数据，因为数据受OEM保密协议覆盖且项目已结束。因此我们仅报告第5节中的平台结果，归一化到裸机；向其他车辆平台的迁移尚未测量。

## 8 结论

本文提出CarDroid，一种轻量级IVI系统虚拟化方案。为实现高性能汽车游戏，我们实现了硬件切片容器化，使游戏可与其他日常任务并行流畅运行。我们设计了跨操作系统缓冲区投射以减少不同操作系统之间的渲染开销。基于游戏特性，我们开发了PMU引导的预测器用于动态资源分配，在测试工作负载组合中将算术平均干扰比相比当前最优方案降低了31.83%。CarDroid基于开源组件构建，在项目因业务原因终止前，已在涵盖9家汽车公司和10款车型的原型和验证试点中进行了评估。未来工作将专注于降低虚拟化开销以支持更多游戏实例。

## 致谢

我们感谢Intel Corporation支持本工作并授权使用评估中的座舱平台。