CarDroid：汽车座舱中图形密集型任务的基于容器架构

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

　　

## 摘要

汽车行业已广泛采用GPU用于车载信息娱乐（IVI）系统，该系统支持从导航到图形密集型游戏等各种应用。然而，当前的车载GPU虚拟化解决方案往往缺乏车载座舱所需的效率、灵活性和低开销。在动态工作负载下，隔离不足可能导致性能波动和延迟，包括路线规划等延迟敏感任务中的延迟。

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

## AI生成的摘要（实验性）

本摘要使用自动化工具生成，未经本文作者撰写或审核。它旨在支持发现，帮助读者评估相关性，并协助邻近研究领域的读者理解该工作。它旨在补充作者提供的摘要，后者仍然是论文的主要摘要。完整文章仍然是权威版本。

## 1 引言

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

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

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

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

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

CarDroid面向座舱计算，而非安全关键驾驶或车身控制域；这些系统依赖于专用硬件和经过认证的软件栈。

除了整合已知的隔离原语外，CarDroid做出了三项贡献。首先，跨操作系统缓冲区投影使Linux容器能够直接写入Android帧缓冲区，将四次跨系统复制减少到一次。其次，PMU引导的预测器将粗略的GPU分区转变为座舱导航和娱乐工作负载的弹性、工作负载感知策略。第三，CarDroid提供了操作系统内部的容器间动态GPU共享。相比之下，NVIDIA MIG、AMD CU掩码和Imagination Hyperlane等硬件空间分区机制依赖于静态配置的GPU分区，不会在运行时动态调整或共享单一操作系统中容器间的GPU容量。因此，CarDroid是对这些机制的补充，而非重新实现。

我们的贡献如下：

- 我们设计了一个基于容器的GPU虚拟化框架，用于Android IVI系统，支持图形密集型工作负载，开销极小。
- 我们分析了现有GPU虚拟化方法的局限性，并引入了硬件切片资源分区，以低复杂度提供隔离。
- 我们开发了弹性资源分区算法和跨操作系统缓冲区投影，将帧率提高了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)说明了virtio-GPU与Virglrender，它支持硬件加速的3D渲染。然而，virtio-GPU产生仿真开销，并且与直接直通相比存在兼容性限制。

CarDroid提供了一种使用硬件切片的轻量级替代方案。图形密集型任务在Android主机的容器中运行，共享一个通用内核，并利用直接渲染管理器子系统进行联合GPU调度。这允许直接访问硬件驱动程序，同时通过Intel 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吞吐量的增加通常预示着涉及大量数据加载的场景切换。缓存未命中率的上升与着色器编译相关，这是一种CPU密集型的任务，发生在GPU密集型渲染之前。频繁的用户交互表明即将出现CPU和GPU需求的峰值。这些观察结果使得能够准确、精细地预测即将到来的资源需求。

在此基础上，CarDroid整合了一个PMU引导的预测器，该预测器采样I/O和微架构信号来动态调整GPU和CPU分配。这确保了流畅的图形性能，同时将空闲的GPU容量回收给其他座舱任务。

## 3 IVI系统工作负载和生态系统

### 3.1 IVI系统用例和工作负载特性

现代IVI平台已从媒体仪表盘演变为多用途计算系统，集成了导航、连接性、多媒体、驾驶辅助可视化和日益增长的交互式娱乐。这些工作负载必须在严格的汽车功耗和热限制下共享受限的CPU/GPU/DRAM预算。

虽然导航和安全功能在德国、美国和中国仍然是用户的最高优先级，但调查数据显示，从2021年到2022年，娱乐服务的重要性稳步上升（普华永道2023年数字汽车报告，每国1000名受访者）。这种转变在年轻和高端细分用户中最强烈，他们还报告了更高的付费意愿（例如，中国每月近40欧元，而欧美/美国为每月20欧元）。这一趋势与特斯拉Arcade和奥迪holoride系统等商业部署相一致，这些系统带来了实时GPU密集型工作负载进入座舱。

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

IVI需求现在集中在两类：可预测的、延迟敏感的导航工作负载（地图渲染、ADAS叠加层）和GPU受限的娱乐工作负载（如云游戏），后者具有突发带宽需求和大的帧时间方差。这些特性意味着：（1）IVI工作负载是双峰的；（2）对于单GPU汽车SoC，静态GPU分区效率低下；（3）导航和娱乐工作负载的弹性共存正成为基本要求：OEM座舱项目越来越多地将娱乐与导航一起出货在同一SoC上，使得并发支持成为集成要求。

### 3.2 案例研究：IVI中的游戏与导航

为了量化传统IVI工作负载与新兴IVI工作负载之间的差距，我们在相同的CarDroid评估设置上比较了中国使用最广泛的导航应用高德地图（AMap）和Unigine Valley基准测试（图形密集型3D工作负载）的GPU利用率。图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+Intel）占部署量的近20%，特别是在高端车辆中，离散GPU支持桌面级图形管线——例如，特斯拉的x86 Ryzen部件配备了约10 TFLOPS的Radeon GPU，而主流Arm座舱SoC（如高通SA8155P）则采用集成的Adreno 640。

**表1** 2023年中国主要IVI SoC供应商

| 供应商 | 出货量 | 市场份额 | 指令集 |
|--------|--------|----------|--------|
| 高通 | 2,261,869 | 59.20% | Arm |
| AMD | 575,628 | 15.10% | x86_64 |
| 瑞萨 | 327,877 | 8.60% | Arm |
| Intel | 173,960 | 4.60% | x86_64 |
| 三星 | 152,206 | 4.00% | Arm |
| 德州仪器 | 134,599 | 3.50% | Arm |
| 芯驰科技 | 60,152 | 1.60% | Arm |
| NVIDIA | 49,997 | 1.30% | Arm |
| 晶晨半导体 | 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 主机共享的缓冲区，后者通过其原生图形栈呈现帧；这消除了传统路径中冗余的跨操作系统数据复制，降低了系统延迟。内核级预测器根据实时 IO 和 GPU 利用率动态重新分配资源，确保非关键任务不影响导航等关键任务。

4.2 硬件切片容器化

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

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

缓存动态分区：英特尔的缓存分配技术（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–33ms帧，即使在重负载下也不超过约100ms——因此更高优先级的容器等待 GPU 的时间最多约一帧，在不付出中间抢占开销的前提下将服务延迟控制在有界范围内。这避免了启动时的空间切片，代价是在时间域而非硬件层面强制隔离。

4.3 跨操作系统缓冲投射

GPU 直通将 GPU 独占分配给虚拟机，阻止导航和娱乐的并发加速。CarDroid 使用硬件切片容器在两者间共享 GPU。

CarDroid 不是 hypervisor 设计：它不是在 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 和 VRAM 压力；(ii) 用户输入速率，领先于交互驱动的 CPU 和 GPU 突发；(iii) LLC 缺失率，在着色器编译期间上升，这是一个 CPU 密集型阶段，领先于 GPU 密集型渲染 [6, 9]。它们是竞争的前导指标，而非穷尽集；可以添加其他计数器。

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

采样成本与观察者效应。每个周期成本为三次计数器读取加上几次比较，每帧轮询一次而非每中断轮询，因此决策工作量在微秒级别，对比约16ms的帧预算——远低于0.1%；我们将其陈述为第一性原理边界，而非单独测量的数字。读取 LLC 缺失计数器确实会扰动其测量的缓存，因此我们将缺失率视为粗粒度趋势；粗粒度采样保持该扰动较小。

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

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

与更简单策略的比较。启发式算法涵盖了两个自然基线——纯 GPU 时间分片和仅 CPU 亲和性分配——我们在图7中隔离了它们：两者都留有实质性干扰，而组合的权重加 CAT 启发式算法消除了这些干扰。一个闭环替代方案是反馈控制 GPU 调度，它通过形式化控制器调节实时嵌入式 GPU 负载 [29]；我们刻意用阈值规则交换该控制器的更强保证，其最坏情况成本在生产座舱 SoC 上可被平凡界定。

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

5 评估

5.1 评估设置

我们在 Android 12L 上构建了9300行的 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-gl |
| heaven | 高质量 1920×1080 |
| OpenVINO | bert-base-ner |

平台选择及为何三个平台。虽然 Arm SoC（高通领先，占59%）主导 IVI，但 x86 在高端细分市场仍保留有意义的份额（AMD+Intel ≈20%，表1），并搭载于 Tesla 等量产汽车中；我们的生产座舱平台是 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 仅用于验证 per-way CAT [12]，这是 Xeon 暴露但消费级和当前汽车部件禁用的功能。该配置使我们能够在可用时评估 per-way CAT；它不构成汽车级验证。

本比较能展示什么和不能展示什么。由于三个系统在 CPU 和 GPU 上存在差异，绝对跨平台 FPS 无法直接比较。因此，我们将每个系统归一化为其自身的裸机性能，并报告相对干扰和开销，从而将虚拟化方案与硅片隔离开来；我们所支持的主张涉及各平台上这些相对量，而非绝对汽车级数值。生产验证需要在汽车级硬件上对单一 SoC 重新评估；当前结果仅表征所测试的平台。

重复和方差限制。图4展示了重复测量中的代表性轨迹。对于主要结果图表，精简后的项目不再保留完整的运行次数和每次运行的方差记录，因此我们报告记录的结果而不附带置信区间，也不进行统计显著性声明。

我们将干扰比定义为共置导致的 GPU 性能效率下降：干扰比 = (PE_base - PE_co) / PE_base。(1) PE（性能效率）为 PE = FPS / GPUUtil。(2) GPUUtil 是与 FPS 在相同测量区间内的运行级平均 GPU 利用率，而非瞬时采样；该均值中包含瞬态零利用率样本。如果某次运行的平均 GPU 利用率为零，则该指标未定义；所有报告的工作负载组合均具有非零的运行级平均值。正比值表示共置导致效率下降；负比值表示效率提升。

我们将干扰比下降报告为所有测试工作负载组合的算术平均值，包括 CarDroid 具有负干扰比的那些组合，不按比值的符号进行过滤。

基线与方法论：我们使用 Tesla Simulator 作为基线。Tesla Simulator 指基于 SteamOS 的 GPU 直通配置（SteamOS 3/Holoiso 配合 Proton），运行在 AMD GPU 上——与 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，其中直通基线优于 CarDroid，原因是 TWW 具有 CPU 密集特性且 CarDroid 的 CPU 分配受限。

图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)）遭受平均 68% 的 FPS 下降，且波动严重导致游戏无法进行。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 仅支持前10款 Steam 游戏中的1款；CarDroid 支持全部10款。virtio-GPU 的 OpenGL 设备模型依赖过时的 ToGL 转换器或逐游戏 OpenGL 支持——随着现代游戏放弃 OpenGL，这种覆盖度在缩减。图12证实了这一点：前10/100/1000款游戏中仅 10%、27% 和 29.2% 支持 OpenGL。CarDroid 使用 Vulkan 和 DXVK，在相同的集合中实现了 100%、87% 和 85% 的兼容性。

表5.

| # | 游戏 | virtio-GPU | CarDroid | 历史峰值用户数 |
|---|------|-----------|----------|--------------|
| 1 | PUBG: BATTLEGROUNDS | ? | ? | 3,257,248 |
| 2 | Black Myth: Wukong | ? | ? | 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款游戏的兼容性，数据收集自 SteamDB 2024年9月。Virtio-GPU 仅支持列表中的一款游戏，而 CarDroid 支持全部十款游戏。

图12. API 支持前10/100/1000款最受欢迎游戏的百分比。数据提取自 ProtonDB。对比 OpenGL 和 Vulkan，Vulkan 将低于 Silver 徽章的游戏视为不支持。

《黑神话：悟空》是一款基于虚幻引擎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 主机共享一个渲染缓冲区，消除了冗余的跨操作系统拷贝，这是 VADI 范围之外的问题。

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

6.2 硬件辅助容器

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

硬件辅助系统以多种方式解决这一局限。SCONE 使用 Intel SGX 减少对主机操作系统或 hypervisor 的依赖[2]。Google 的 gVisor 则使用用户空间内核对容器进行沙箱隔离，并带来相应的兼容性限制和开销[1]。

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

相比之下，CarDroid 使用硬件辅助容器而不进行完整的虚拟机封装，使 GPU 任务能够以较低的虚拟化开销访问原生驱动栈。

7 CarDroid 当前状态

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

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

8 结论

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

致谢

我们感谢 Intel Corporation 对本研究的支持以及在评估中使用的座舱平台的访问权限。