Chapter 118: Multi-GPU and Distributed Rendering Optimization

多 GPU 与分布式渲染优化讨论的是同一个核心问题：当单个 GPU 已经接近预算上限时，如何把一帧、一组 pass 或一批渲染任务拆到多个执行位置，并判断拆分之后的同步、传输、合成和呈现成本是否仍然划算。本章读完后，读者应能追踪一个跨 GPU frame 的数据路径，判断任务划分方式，定位 peer memory、frame pacing、work split、synchronization 与 output merge 造成的延迟瓶颈。

本章贯穿一个固定场景：一个实时渲染器需要在 16.67 ms 内完成 60 FPS 输出。单 GPU 版本中，shadow pass、G-buffer、lighting、SSR、denoise、post process 与 present 合计超过预算。工程团队准备把 shadow、反射探针、屏幕分区或相邻帧交给第二块 GPU，同时评估把渲染扩展到远端节点的可行性。这个场景足够具体，因为它同时包含 GPU 资源、API 状态、队列同步、图像合成和用户可见的帧节奏。

多 GPU 成功的前提是任务之间存在真实并行段。同步点、跨设备读写和最终合成会把并行收益折回到串行路径。分布式渲染也遵循同一判断：节点越多，计算能力越大，网络传输、场景同步、任务调度和结果归并也越重。优化的主线因此是先画出依赖图，再量化每个跨边界动作的代价。

本章中的多 GPU 指同一台机器内的多个 GPU adapter、device 或 node；分布式渲染指跨机器节点的渲染任务分配。两者在 API 形态上差异明显，但诊断顺序一致：先定位单 GPU 瓶颈，再选择拆分维度，再测量等待、传输和合成，最后根据帧时间与尾延迟决定保留、收缩或取消拆分。

118.1 多 GPU 渲染同步机制

多 GPU 同步机制要回答的问题是：哪个 GPU 拥有资源，哪个 GPU 生产结果，哪个 GPU 消耗结果，哪个队列负责呈现。同步的对象包含 command queue、resource state、memory visibility、fence、semaphore、copy command 和 present ownership。把这些对象混在一起会让调试失去方向；把它们放回 frame timeline，问题会变成一组可检查的边界。

在贯穿场景中，GPU0 负责 swapchain 与最终 present，GPU1 负责 shadow atlas 和反射 probe 的重计算。GPU1 产生的 shadow atlas 需要在 GPU0 的 lighting pass 前可见。这个路径包含四步：GPU1 写入本地资源，GPU1 发出完成信号，GPU0 等待该信号，GPU0 通过 peer-visible resource 或 copy resource 读取结果。任何一步提前或遗漏，视觉上会表现为旧阴影、随机闪烁、局部黑块、GPU wait 增大或 present 节奏抖动。

API 层通常把多 GPU 暴露为 device group、linked adapter 或多个独立 adapter。Direct3D 12 的 Multi-adapter systems 文档把多个物理 adapter 描述为 node，并通过 node mask 指定队列、pipeline state、resource heap 和可见性范围。这个模型给工程实践一个稳定判断：多 GPU 资源创建从一开始就要声明创建位置和可见位置，后续同步只是在这些可见性边界上安排等待与传输。

下面的图只描述本章贯穿案例中的跨 GPU frame 边界。它不覆盖所有 API 细节，重点是把生产、传输、等待和合成分开。

图中的关键路径是 GPU1 shadow and probe → Signal fence → Peer copy or shared resource → GPU0 lighting。如果 lighting pass 在 GPU1 完成前启动，结果会读到上一帧或未完成数据；如果 GPU0 等待过早，GPU0 的其它可并行 pass 会被压缩；如果 peer copy 太晚，present 前的串行尾巴会变长。同步机制的设计目标是把等待放在真正消费资源之前，并让 GPU0 在等待前完成本地可执行工作。

多 GPU 同步还要区分三类资源。第一类是只读静态资源，例如 mesh、material texture、环境贴图，它们适合每个 GPU 各自持有副本。第二类是每帧局部结果，例如 shadow atlas、G-buffer tile、denoise history，它们需要明确生产者和消费者。第三类是跨帧历史资源，例如 TAA history、SSR history、temporal denoise cache，它们对 frame index 和 GPU ownership 敏感。AFR 场景下，历史资源如果跟随 GPU 分离保存，帧间稳定性会下降；如果每帧在 GPU 间传递，传输与等待会进入关键路径。

最小可执行的同步设计可以写成一条资源生命周期规则：每个跨 GPU resource 必须有 owner、producer queue、consumer queue、visible mask、ready fence 和 fallback path。owner 说明资源主要驻留位置，producer queue 说明谁写，consumer queue 说明谁读，visible mask 说明哪些 GPU 可以直接访问，ready fence 说明何时读，fallback path 说明跨 GPU访问失败或性能不足时如何回到单 GPU 或局部副本。

工程上常见的错误是把 fence 当成数据传输。fence 只说明某个队列上的命令到达了某个执行点，数据是否能被另一块 GPU 高效读取，还取决于 resource 的创建方式、heap 可见性、layout / state transition、peer access 能力和互连带宽。一个正确的 frame capture 应能同时看到等待点、copy 点、资源状态和后续 shader 读取位置。

118.2 分布式任务调度

分布式任务调度要回答的问题是：任务按什么粒度拆分，节点拿到哪些输入，结果按什么顺序归并，失败或慢节点如何处理。它比同机多 GPU 多出网络、存储、版本一致性和调度尾延迟。对渲染工程来说，调度质量经常比单个节点的 shader 性能更决定总体吞吐。

贯穿案例扩展到远端节点后，可以有两种目标。第一种是实时云渲染：客户端输入到达服务器，服务器渲染、编码、传回视频流。第二种是离线分布式渲染：一批镜头、一组帧或若干 tile 被提交到 render farm，节点完成后把图像、AOV、深度、cryptomatte 或中间缓存写回存储。两种模式的调度对象都叫任务，但优化指标不同：实时模式看端到端延迟与帧节奏，离线模式看吞吐、失败恢复和资源利用率。

分布式渲染的任务粒度通常有三种。按 frame 拆分时，每个节点渲染完整帧，依赖少，适合动画序列和离线批处理。按 tile 拆分时，每个节点渲染画面区域，合成需要处理边界、采样核、后处理和深度关系。按 pass 拆分时，不同节点负责不同渲染阶段，依赖最强，实时价值取决于网络延迟和中间结果大小。贯穿场景中的 shadow、probe 和 denoise pass 只有在中间结果可压缩、依赖清晰、合成位置稳定时才适合远端化。

一个稳定的分布式调度器需要维护四类状态：scene version、resource package、task dependency 和 output contract。scene version 保证所有节点使用同一份几何、材质、动画和相机输入；resource package 记录节点需要的 texture、shader cache、BVH、light cache 和配置；task dependency 描述任务前后关系；output contract 描述节点必须产出什么格式、分辨率、颜色空间、AOV 列表和校验信息。

这条路径里的风险集中在 Worker assignment → Render frame or tile → Merge result。如果调度粒度太大，慢节点会拖住整批任务；如果粒度太小，调度开销、资源加载和输出文件数量会增加。稳定做法是让单个任务的计算时间显著高于调度和加载时间，同时把任务切到足够细，使慢节点只影响局部区域或少量帧。

实时分布式渲染还要增加输入同步与输出编码。用户输入、相机姿态、动画时间、模拟状态和随机种子必须绑定到同一个 frame id。服务器端多个节点返回结果时，compositor 需要按 frame id 合成，再进入编码器。任何节点返回晚于合成截止时间，调度器都要选择降级：使用上一帧缓存、降低质量、缩小远端任务范围或回到本地近似结果。这个策略必须在系统设计时明确，运行时临时等待会直接增加交互延迟。

离线分布式渲染的诊断重点在吞吐曲线。一个 render farm 随节点数增长出现收益下降时，先检查资源分发时间、场景加载时间、许可证或队列限制、共享存储带宽、输出写入争用和失败重试率。只有当这些系统开销已经受控，单节点 shader、采样和内存瓶颈才成为下一层优化对象。

118.3 跨 GPU 渲染案例

跨 GPU 渲染案例可以按拆分维度理解：AFR 按时间拆分，SFR 按屏幕空间拆分，multi-adapter 按 pass 或资源职责拆分，peer memory 按数据驻留和访问路径拆分。四类方案都能提高某些场景的吞吐，但它们对延迟、历史资源和合成路径的压力不同。

AFR（Alternate Frame Rendering）让 GPU0 渲染第 N 帧，GPU1 渲染第 N+1 帧。它的优点是单帧内部依赖少，两个 GPU 都能独立执行完整 frame graph。代价是交互延迟和 frame pacing 更敏感，因为用户输入影响的可见帧可能已经排进后续队列。贯穿场景中，如果 TAA、motion blur、temporal denoise、SSR history 都依赖上一帧，AFR 需要复制历史资源或维护每 GPU 历史链；两种方式都会给稳定性和传输带来成本。

SFR（Split Frame Rendering）把同一帧分成多个屏幕区域。它的优点是输入延迟较低，因为多个 GPU 共同服务当前帧。它的代价是 load balance 和 output merge 更难。屏幕上半部分如果是天空，下半部分如果是高密度透明粒子，固定一半一半的分割会让一块 GPU 空闲，另一块 GPU 拖住 present。动态分区可以改善负载，但会增加任务分配、边界处理和后处理复杂度。

显式 multi-adapter 更适合 pass 级拆分。GPU1 可以负责 shadow map、reflection probe、ray tracing denoise 或 compute culling，GPU0 负责主渲染和 present。这类方案的判断点是中间结果大小和消费时机。shadow atlas 在 lighting 前被读取，路径短且格式稳定；全分辨率 G-buffer 如果跨 GPU 传回，带宽和同步压力会迅速增大。pass 级拆分因此优先选择输出紧凑、复用率高、与主 frame 低耦合的任务。

Peer memory 让一个 GPU 访问另一个 GPU 上的资源或通过专用互连传输结果。它减少了 CPU staging 参与，但它仍然是跨边界访问。远端读取的延迟、带宽和缓存行为通常弱于本地访问。稳定策略是把频繁随机访问的数据复制为本地副本，把一次性大块结果作为显式 copy，把少量控制信息放在共享可见资源中。判断重点是 shader 访问模式：随机采样大 texture 依赖本地性，顺序 copy 更容易被带宽优化。

下表把四类方案放到同一组维度中比较，便于在工程评审中直接判断适用条件。

方案	拆分维度	主要收益	主要成本	适合场景
AFR	相邻帧	提高吞吐	输入延迟、frame pacing、历史资源复制	离线预览、低交互压力场景
SFR	屏幕区域	服务当前帧	负载不均、边界处理、合成成本	屏幕空间工作量可预测的场景
Pass 级 multi-adapter	渲染阶段	隔离重 pass	同步点、跨 GPU 结果传输	shadow、probe、部分 compute pass
Peer memory	数据驻留	减少 CPU 中转	远端访问延迟、互连带宽	大块 copy、少量共享控制数据

跨 GPU 案例的复盘应回到用户可见结果。AFR 的失败结果是平均 FPS 看起来提升，但帧交付间隔不稳定。SFR 的失败结果是某些视角收益明显，另一些视角被单个区域拖住。pass 级拆分的失败结果是 GPU0 在 lighting 前等待 GPU1，最终 present 仍然超预算。peer memory 的失败结果是 shader 看似并行，实际被远端纹理读取或跨设备 copy 压住。

118.4 Multi-GPU Efficiency and Latency Bottleneck Diagnosis

Multi-GPU efficiency 的诊断必须从单 GPU baseline 开始。baseline 需要记录 CPU frame time、GPU frame time、每个 pass 的 GPU timestamp、present interval、render target 大小、跨帧历史资源大小和 GPU memory pressure。没有 baseline，双 GPU 后的收益和损失都缺少参照。贯穿场景中，先确认 21 ms 来自 GPU 执行超时，而非 CPU submit、shader compile、resource streaming 或 present blocking。

第一步是画 frame timeline。把 CPU build、GPU0 pass、GPU1 pass、copy、wait、merge、present 放到同一条时间轴。效率瓶颈通常会落在四个位置：GPU1 完成太晚，GPU0 等待太早，跨 GPU copy 太大，output merge 进入 present 前串行尾部。只看 GPU 利用率会掩盖问题，因为两块 GPU 都忙也可能意味着它们在做重复工作或远端访问。

第二步是量化跨 GPU 数据。每个跨边界资源都要记录 format、resolution、mip count、更新频率、访问模式和生命周期。一个 4096 x 4096 的 32-bit shadow atlas 传输体积约 64 MB；如果每帧复制并且在 lighting 前等待，它会直接占用关键路径。压缩格式、低频更新、局部更新和 atlas 分区可以降低体积，但这些优化必须保持采样语义稳定。

第三步是检查同步粒度。同步粒度太粗会让 GPU0 等待 GPU1 的整组 pass；同步粒度太细会引入过多 fence、barrier 和提交开销。合理粒度通常对应 frame graph 中真实资源依赖边。shadow pass 只需要在 lighting pass 前完成，post process 无需等待 shadow；reflection probe 如果只影响下一帧，可以把结果延后一帧消费，让当前帧少一个关键等待点。

第四步是诊断 frame pacing。平均 FPS 不能代表交互稳定性。需要看每帧 present 间隔、p95 / p99 frame time、最大连续超预算帧数和输入到光子延迟。AFR 中尤其要检查排队深度和历史资源复制，因为这些因素会让帧率升高但操作反馈变慢。实时渲染的目标是稳定交付帧，而非只提高吞吐峰值。

第五步是检查 output merge。SFR 或 tile-based multi-GPU 需要把多个 GPU 的结果合成到最终 render target。合成可能包含 color resolve、depth merge、alpha blend、post effect、tone mapping 和 UI overlay。合成如果放在 present 前的单队列尾部，会把所有并行收益压回一个串行 pass。更好的设计是尽早合并低成本中间结果，或把后处理限制在合成之后一次完成。

下面是一条可复用的诊断顺序。它适用于同机多 GPU，也适用于远端节点参与实时渲染的原型评估。

1. 固定单 GPU baseline，记录 frame graph、pass 时间、present 间隔和资源体积。
2. 标记可拆分 pass，筛掉需要大量历史资源和全分辨率中间结果的候选项。
3. 为每个候选项估算计算收益、传输体积、等待位置和合成成本。
4. 在 capture 中确认 GPU0、GPU1 的 timestamp、copy、fence 和 present 顺序。
5. 用 p95 / p99 frame time 判断交互稳定性，用平均 FPS 只判断吞吐趋势。
6. 将跨 GPU 路径缩减到少数高收益、低耦合、低传输的任务。

如果双 GPU 后的总帧时间没有下降，优先排查等待和传输。常见修正是把跨 GPU 结果改成下一帧消费、把频繁读取资源改成本地副本、把全分辨率输出改成低分辨率中间量、把 pass 拆分改成资源预计算。只有当这些调整之后仍然被单个重 shader 压住，才进入 shader 内部优化或算法替换。

118.5 技术对比与最佳实践

多 GPU、云渲染和离线分布式渲染的差异可以用三条轴判断：延迟容忍度、带宽压力和一致性要求。同机多 GPU 的网络延迟最低，但它仍受 PCIe、NVLink、统一内存架构或平台互连限制。云渲染拥有集中硬件和弹性资源，但输入、编码、网络和解码进入端到端链路。离线分布式渲染容忍分钟级或小时级等待，适合把大量帧、tile 或采样任务铺到节点上。

同机多 GPU 适合低耦合任务。shadow atlas、reflection probe、部分 ray tracing denoise、visibility buffer preprocessing、particle simulation 和 asynchronous compute-like workload 都可能成为候选。候选任务要满足三个条件：结果体积可控，消费时机可后移或精确同步，失败时可以回退到单 GPU 或低质量路径。全分辨率 G-buffer、TAA history、复杂透明合成和大量随机纹理读取通常会带来更高跨边界压力。

云渲染适合把整个 renderer 放在远端，而非把一帧拆成客户端与服务器混合计算。原因是跨网络传输中间图形资源的成本高，传输压缩后的视频流更符合带宽模型。云渲染优化重点是服务器 frame time、编码延迟、网络 jitter、客户端解码和输入预测。它的质量策略通常是动态分辨率、码率调整、帧率降级和输入补偿。

离线分布式渲染适合高吞吐批处理。它的最佳拆分单位通常是 frame 或 tile，因为这些任务依赖清晰、结果可校验、失败可重试。离线模式中，场景版本锁定、缓存预热、资产分发、任务优先级、失败重试和输出校验比单帧 present 更重要。节点数增加时，吞吐收益会被共享存储、资产加载和长尾任务逐渐限制。

最佳实践可以收束为一组工程决策。先用单 GPU baseline 证明真实瓶颈，再用 frame graph 找到低耦合任务；先复制静态资源，再显式传输中间结果；先使用延后一帧消费降低关键等待，再评估严格同帧同步；先度量 p95 / p99 frame time，再讨论平均 FPS。多 GPU 方案只有在这些检查通过后才进入产品路径。

平台边界需要提前写进渲染抽象层。Vulkan device group、Direct3D 12 linked / unlinked adapter、Metal 的多 device 使用方式和具体硬件互连能力不完全等价。抽象层可以统一表达 device、queue、resource、visible mask、transfer 和 fence，但底层 backend 必须保留能力查询和 fallback。跨 API 统一的目标是复用判断模型，同时承认平台能力差异。

最终判断可以写成一个简短公式：多 GPU 净收益 = 被移出的 GPU 计算时间 - 等待时间 - 传输时间 - 合成时间 - 调度与维护开销。这个公式不追求数学精确，它提供工程排序。只要后四项接近或超过第一项，拆分就会让系统更复杂且收益有限；当被移出的任务稳定、独立、结果紧凑，并且等待点能后移，多 GPU 才会形成可持续收益。

最小自检任务

你维护一个 60 FPS 实时 renderer，单 GPU frame time 为 21 ms。frame graph 中 shadow atlas 4 ms，SSR 3 ms，lighting 5 ms，post process 2 ms，present 1 ms，其余任务 6 ms。团队准备加入第二块 GPU，有两个方案：方案 A 使用 AFR；方案 B 让 GPU1 每帧计算 shadow atlas，并在 GPU0 的 lighting pass 前交给 GPU0。请判断两个方案的主要风险，并给出你会先验证的证据。

答案要点

方案 A 的主要风险是 frame pacing、输入延迟和历史资源管理。AFR 会让两块 GPU 分别处理相邻帧，平均吞吐可能提升，但 TAA、SSR history、motion vector、denoise history 等跨帧资源需要在 GPU 间复制或分开维护。验证时先看 present interval、p95 / p99 frame time、输入到可见画面的延迟，以及历史资源在每个 GPU 上的 ownership。

方案 B 的主要风险是 GPU0 在 lighting 前等待 GPU1，以及 shadow atlas 的传输体积进入关键路径。它比 AFR 更容易保持当前帧语义，因为 GPU1 只生产一个 pass 结果，但收益取决于 shadow 计算 4 ms 是否大于 fence、copy、state transition 和等待成本。验证时先看 GPU timestamp：GPU1 shadow 完成时间、GPU0 lighting 启动时间、copy 时间、GPU0 wait 时间和 present 前尾部长度。

优先验证顺序是：固定单 GPU baseline，记录各 pass timestamp；实现方案 B 的最小原型，因为它的资源依赖更清晰；把 shadow atlas 改成下一帧消费做对照；再评估 AFR 对 frame pacing 的影响。最终结论不由平均 FPS 决定，而由 p95 / p99 frame time、等待位置、跨 GPU 数据体积和可回退路径决定。

本章知识点总结

• 主问题：多 GPU 优化要判断拆分收益是否覆盖同步、传输、合成和调度成本。
• 贯穿路径：跨 GPU frame 应按生产、信号、传输、等待、消费和呈现追踪。
• 资源归属：每个跨 GPU resource 都要有 owner、producer、consumer、visible mask、ready fence 和 fallback path。
• 同步边界：fence 只表达执行点完成，数据可见性和访问效率还依赖资源创建方式与互连能力。
• 静态资源：mesh、材质纹理和环境贴图适合多 GPU 副本，减少频繁远端读取。
• 历史资源：TAA、SSR 和 denoise history 对 frame index 与 GPU ownership 敏感，是 AFR 的主要风险源。
• 调度粒度：分布式任务要让计算时间显著高于调度、加载和输出开销。
• AFR 判断：AFR 提高吞吐的同时会增加 frame pacing、输入延迟和历史资源压力。
• SFR 判断：SFR 服务当前帧，但负载均衡、边界处理和 output merge 决定最终收益。
• Pass 拆分：pass 级 multi-adapter 适合输出紧凑、低耦合、可后移消费的任务。
• Peer memory：peer memory 减少 CPU 中转，但远端访问仍受延迟、带宽和访问模式约束。
• 诊断顺序：先固定单 GPU baseline，再量化跨 GPU 数据、等待点、copy 点和 present 节奏。
• 帧节奏：实时渲染应优先看 p95 / p99 frame time 和 present interval，平均 FPS 只反映吞吐趋势。
• 云渲染：云渲染更适合远端完整渲染与视频流传输，中间图形资源跨网络传输成本高。
• 离线分布式：离线 render farm 的核心是吞吐、版本一致性、失败重试和输出校验。
• 最终公式：净收益等于移出的计算时间减去等待、传输、合成、调度和维护开销。