Skip to main content

Chapter 142: Foveated Rendering

Foveated Rendering 的核心问题是：在 VR/AR 一帧中，如何根据用户视线把有限的像素、采样和着色预算分配到用户最敏感的位置，同时让画面变化保持稳定。读完本章后，读者应能定位 gaze 数据进入渲染管线的位置，判断一张 rate map 是否合理，追踪中心清晰区、周边降采样、眼动延迟和画质突变之间的因果关系。

本章使用一个贯穿材料：头显中正在显示的工业驾驶舱帧。用户眼睛看向中央仪表时，仪表盘文字需要保持锐利；用户扫向右侧报警灯时，清晰区需要快速迁移；周边墙面、管线和天空可以降低 shading rate，但头部运动造成的视差和亮边仍需要稳定。这个 frame 会贯穿理论、数据融合、系统搭建、质量评估和场景策略。

Foveated Rendering 可以理解为“按视觉敏感度分配渲染工作”。它的输入来自眼动追踪、头部姿态和预测显示时间；处理过程生成 foveal region、过渡区和周边区；输出可能是 shading rate image、多分辨率 render target、分区 viewport 或 runtime foveation profile；最终影响是 GPU fragment 工作量、纹理采样压力、画面清晰度和用户舒适度。

工程判断的稳定顺序是：先确认 gaze 的空间和时间，再确认 rate map 的分区，再确认渲染管线是否按分区改变 shading 成本，最后观察中心画质、周边闪烁、延迟错位和性能收益。只看帧率会漏掉用户感知风险；只看画质会漏掉 GPU 工作量是否真的下降。

142.1 聚焦渲染的理论基础与视觉原理​

聚焦渲染建立在一个视觉事实上：人眼在注视点附近拥有最高空间分辨率，离注视点越远，细小纹理、文字边缘和高频几何细节的可辨能力越低。在工业驾驶舱帧中，用户盯着速度表时，速度数字、刻度线和指针边缘位于视觉中心；侧墙螺丝、远处管线和天窗纹理落在周边视觉区。系统可以把完整 shading 预算集中在速度表附近，把侧墙纹理降到更粗的 shading rate。

这里的“聚焦”指 gaze 对屏幕或视图空间中某个区域的指向关系。它解决的问题是 GPU 在高刷新率 VR/AR 中的像素着色压力。头显每只眼通常需要独立视图，高分辨率和高刷新率会把 fragment shader、纹理采样、MSAA 和后处理开销推高。Foveated Rendering 通过降低周边区域每像素着色频率，把同一帧的计算预算转移到用户正在看的区域。

视觉中心与周边视差需要分开处理。视觉中心主要关心空间清晰度，例如文字是否糊、边缘是否锯齿、法线高光是否稳定；周边区域虽然对细节分辨率较低，但对运动、闪烁、亮度突变和深度错位仍然敏感。驾驶舱右侧报警灯如果在周边区域突然闪烁，用户可能立刻感知到跳变；头部转动时墙面管线的 parallax 如果被低分辨率分区破坏，也会造成不自然的运动线索。

因此，聚焦渲染的理论边界是“降低周边着色密度”，同时保持时间稳定、深度一致和运动线索稳定。中心区负责清晰文字、交互目标和视线落点；过渡区负责把清晰区和低清晰区连接起来；周边区负责维持大形状、亮度、运动和深度关系。缺少过渡区会产生清晰度硬边，过度降低周边区会产生闪烁、色块和深度不适。

一个可执行的划分方式是用注视点到像素的视角距离建立三层区域：中心区使用完整 shading rate，过渡区使用中等 shading rate，周边区使用更粗 shading rate。实际工程中可以把视角距离近似映射到 normalized device coordinates，或在 lens distortion 前的 eye buffer 空间生成 rate map。判断标准保持一致：用户视线落点附近必须清晰，分区边界必须柔和，周边运动必须稳定。

142.2 实现方式与眼动追踪数据融合​

眼动追踪数据进入渲染系统后，第一步是把 gaze point 放到当前 frame 的时间和空间中。gaze 样本通常包含方向、置信度和采样时间；渲染管线需要的是预测显示时刻的注视点。工业驾驶舱帧在 CPU 开始准备 draw call 时拿到的眼动数据，可能已经落后即将显示的 frame。系统需要结合预测显示时间、头部姿态和上一段 gaze 速度，把清晰区放到更接近用户真正注视的位置。

空间转换同样决定成败。眼动追踪通常给出相对头显或眼睛空间的 gaze ray；渲染系统需要把它投影到左眼和右眼的 view/projection 中，得到每只眼的 gaze point。双眼画面的投影、IPD、非对称 frustum 和 lens distortion 都会影响注视点位置。工程上应分别生成 per-eye gaze point，再用每只眼自己的 render target 坐标生成 rate map。

实现路径通常分成两类。第一类是硬件或 API 提供的 variable rate shading，系统用 shading rate image 或类似机制为屏幕 tile 指定着色频率。Direct3D 12 的 Variable-rate shading 和 Vulkan 的 VK_KHR_fragment_shading_rate 都属于这类入口。第二类是多分辨率渲染，系统把中心区、过渡区和周边区渲染到不同分辨率的目标，再在合成阶段重建到最终 eye buffer。

OpenXR 生态中，gaze、foveation profile 和平台扩展通常由 runtime 暴露。开发者可以把 OpenXR 1.1 specification 作为扩展和 frame 生命周期的回溯入口，但正文中的工程判断保持在通用层：先拿到可信 gaze，再把 gaze 对齐到 predicted display time，再生成 per-eye rate map，最后让渲染 pass 或 runtime 按 map 分配 shading 成本。

下面的图只表达一帧中的数据流边界。它不绑定具体 API，重点是 gaze 数据需要在 frame prediction、rate map 和实际渲染之间闭合。

这条路径中最容易出错的位置是时间对齐。gaze point 如果按采样时间直接生成 rate map，清晰区会落在用户已经离开的旧位置；gaze point 如果被过度平滑，快速扫视时中心区会追不上眼睛；gaze point 如果完全不平滑，微小眼动会让清晰区边界抖动。稳定实现通常把 gaze confidence、角速度和帧预测时间一起使用：高置信、低速度时使用较窄中心区；低置信或快速扫视时扩大中心区并增强时间平滑。

rate map 的融合也要考虑渲染阶段。前向渲染可以直接让 fragment shading rate 改变材质着色成本；延迟渲染需要确认 G-buffer 写入、lighting pass、透明物体和后处理是否真的受益。某些 pass 需要保持全分辨率，例如深度 prepass、UI layer、手部交互轮廓和高对比文字。把所有 pass 都套同一张 rate map 会把视觉敏感对象也降采样，最终收益变成可见瑕疵。

142.3 Foveated Rendering 系统搭建​

一个可维护的 Foveated Rendering 系统应把 gaze input、rate map、multi-resolution render、temporal smoothing 和 debug overlay 分成独立阶段。独立阶段的价值在于排查清晰：当中心区错位时先查 gaze 和坐标；当边界闪烁时查 smoothing 和过渡区；当性能收益不足时查 pass 是否真正读取 rate map；当 UI 变糊时查 layer 和遮罩策略。

在工业驾驶舱帧中，系统可以先定义三个资源：每眼 gaze point、每眼 shading rate image、调试 overlay。gaze point 由 eye tracker 和 pose prediction 生成；shading rate image 是低分辨率 tile 图，tile 值代表完整、半速或更粗的着色频率；debug overlay 把中心区、过渡区和周边区叠在最终画面上，帮助开发者看到清晰区是否覆盖了仪表盘文字。

下面的伪代码展示了 rate map 生成的最小逻辑。它省略 API 细节，保留输入、处理和输出的关系。

struct FoveationInputs {
    Vec2 gazeNdc;
    float confidence;
    float predictedDeltaMs;
    float gazeVelocityDegPerSec;
};

enum class ShadingRate {
    Full,
    Medium,
    Coarse
};

ShadingRate chooseRate(float distanceDeg, const FoveationInputs& input) {
    float centerRadius = 6.0f;
    float transitionRadius = 18.0f;

    if (input.confidence < 0.7f || input.gazeVelocityDegPerSec > 250.0f) {
        centerRadius = 10.0f;
        transitionRadius = 24.0f;
    }

    if (distanceDeg <= centerRadius) {
        return ShadingRate::Full;
    }
    if (distanceDeg <= transitionRadius) {
        return ShadingRate::Medium;
    }
    return ShadingRate::Coarse;
}

这段代码的关键点是把不确定性转成保守分区。低置信度和高速扫视会扩大中心区与过渡区，因为错位的低清晰区域比减少一些收益更容易被用户感知。代码中的角度阈值只是示例参数；真实项目应通过头显视场、显示分辨率、lens distortion、内容类型和用户测试来调参。

multi-resolution render 是另一条常见路径。系统可以把中心区域渲染到高分辨率 tile，把周边区域渲染到低分辨率 tile，再在合成 pass 中放回 eye buffer。它对缺少硬件 VRS 的平台有价值，也适合把某些 pass 固定在高分辨率。代价是合成边界、采样坐标、mip level 和后处理半径都要重新校准，否则过渡区会出现模糊环或锐度断层。

Temporal smoothing 负责把相邻帧的 rate map 连接起来。直接用当前 gaze 生成全新 map 会产生区域跳动，尤其在用户扫视仪表盘和报警灯之间时。稳定做法是对 gaze point、中心半径和分区边界分别平滑，并在大幅眼跳时使用短时扩大中心区。这里的目标是让清晰区迁移跟上眼睛，同时让边界变化在几帧内平滑完成。

Debug overlay 是系统搭建中的必要观察面。overlay 至少应显示 gaze point、中心区半径、过渡区半径、tile shading rate、confidence 和 predicted display delta。排查时先关闭复杂材质和后处理，用 overlay 确认清晰区覆盖交互目标；再打开真实内容，观察文字、边缘、高光和运动是否稳定。没有 overlay 时，开发者容易把 gaze 错位误判成 TAA、DLSS、FSR 或纹理 mip 问题。

142.4 性能提升与视觉质量权衡​

Foveated Rendering 的性能收益来自减少 fragment shader、纹理采样、部分后处理和带宽开销。收益大小取决于瓶颈位置。驾驶舱帧如果主要受复杂材质和高分辨率光照限制，周边 shading rate 降低会直接减少 GPU 执行时间；如果主要受 CPU 提交、几何处理、同步等待或 compositor 限制，rate map 再激进也不会明显改善帧时间。

评估顺序应从 GPU frame time 开始，再拆到 pass 级别。先看总帧时间是否低于 VR runtime 的 frame deadline；再看主渲染 pass、lighting pass、透明 pass、post-process 和 compositor submit 的时间变化；最后对比开启与关闭 foveation 时的 fragment workload、纹理带宽和 cache 行为。工具证据可以来自 GPU timestamp、pipeline statistics、vendor profiler 或 frame capture，但结论必须回到 pass 是否真的减少了对应工作量。

视觉质量评估需要同时看中心清晰度和周边稳定性。中心清晰度用文字、仪表刻度、远处细线和交互 UI 检查；周边稳定性用头部横向转动、亮边、高光、阴影边界和快速眼跳检查。用户对错误的敏感度和内容类型相关：低对比天空盒可以使用较粗 rate，细密网格、文字、透明玻璃和高亮报警灯需要保守处理。

质量突变通常来自三个原因。第一，rate map 边界过硬，中心区移动时出现一圈清晰度断层。第二，TAA、motion blur、bloom、depth of field 等后处理没有理解分辨率变化，历史帧与当前帧的清晰度区域对齐失败。第三，眼动延迟让清晰区落在旧注视点，用户扫视到新目标时先看到低清晰画面。排查时应按“overlay → gaze latency → pass coverage → post-process history”的顺序检查。

性能和质量的权衡可以用一组固定维度记录。中心半径越大，画质越稳，收益越低；周边 rate 越粗，收益越高，闪烁和色块风险越高；平滑越强，边界越稳，快速扫视越容易落后；对 UI 和透明 pass 越保守，交互越清晰，整体收益越受限。项目调参时应记录每个维度的变化，配合用户测试和工具数据，最终留下能回溯到证据的“foveation level”。

一个实用策略是从保守配置开始：中心区覆盖交互目标，过渡区足够宽，周边只降低最昂贵材质 pass，UI layer 保持独立高分辨率。确认用户感知稳定后，再逐步扩大周边降采样范围。这样能把风险集中到可观察的单个变量上，排查时也能解释“收益来自哪个 pass，瑕疵来自哪个分区”。

142.5 VR/AR 中的聚焦渲染实例​

头显游戏通常使用动态聚焦渲染处理高刷新率压力。场景中存在粒子、阴影、反射和复杂材质时，GPU 很容易受 fragment workload 限制。游戏可以把玩家正在瞄准、阅读或交互的区域保持高质量，把天空、地面远处和低对比背景降到更粗 shading rate。失败信号是准星附近文字变糊、快速转头时边界闪烁、粒子在周边成块或 TAA 拖影增强。

工业可视化更强调文字、线框和仪表可靠性。驾驶舱、管线工厂、医学可视化和 CAD 评审中，用户经常扫视细小标签、报警状态和空间边界。这里的 foveal region 应覆盖当前注视点附近的标签和关键轮廓，过渡区应比游戏更宽，透明 overlay 和标注 layer 应保持独立清晰。性能收益可以从材质 shading、体渲染采样或远景网格 pass 中取得，关键标注需要保守处理。

远程渲染中的聚焦策略同时影响服务器 GPU、编码码率和网络传输。服务器可以根据客户端上传的 gaze point 渲染高质量中心区，再对周边区域降低渲染分辨率或编码质量。这里新增的风险是网络延迟：gaze 到达服务器、服务器渲染、视频编码、网络传输和客户端显示形成长链路。策略应扩大中心区、预测 gaze，并在客户端保留低延迟 overlay 或 UI layer。

AR 场景还要考虑真实世界背景和虚拟物体的融合。用户看向真实桌面上的虚拟标注时，标注文字、遮挡边界和深度关系需要保持稳定；周边虚拟装饰可以降低 shading 成本。AR 中的失败信号通常更刺眼，因为低清晰虚拟边界会和真实世界高频纹理相邻。调参时应重点检查 occlusion mesh、depth composition、hand interaction 和 passthrough layer 的边缘质量。

这些实例的共同判断顺序一致：先确定用户当前任务和视觉目标，再确定哪些 pass 影响该目标，再决定哪些区域可以降低 shading 成本，最后用 overlay、frame time 和用户观察验证。Foveated Rendering 的工程价值来自可控降级；当系统能解释每个降级区域对应的视觉风险和性能收益时，它才适合进入正式 VR/AR 管线。

最小自检任务​

给定一个 VR 工业驾驶舱 frame：用户先看中央速度表，随后快速扫向右侧红色报警灯。系统使用眼动追踪、per-eye render target 和 variable rate shading。开启 Foveated Rendering 后，速度表清晰，但扫视到报警灯时会先看到一帧模糊，随后变清晰；周边管线在头部横向转动时出现轻微闪烁。请按本章方法给出排查顺序，并说明哪些参数或资源最可能需要调整。

答案要点​

排查应先打开 debug overlay，确认 per-eye gaze point 是否在 predicted display time 下落到正确位置，并检查报警灯扫视过程中的 confidence、gaze velocity 和中心区半径。报警灯先模糊后清晰，说明清晰区迁移慢于用户眼跳，优先调整 gaze prediction、短时中心区扩大策略和 temporal smoothing 强度。周边管线在头动时闪烁，说明周边 shading rate、过渡区宽度、TAA history 或后处理采样半径与运动线索不匹配，应先放宽过渡区，再降低周边降采样强度，并确认管线、亮边和高光相关 pass 是否使用过粗 rate。UI、报警灯和关键标注应保留高分辨率 layer 或加入保守 mask，性能收益应从背景材质、远景和低对比区域取得。

本章知识点总结​

  • 主目标：Foveated Rendering 用 gaze 数据把渲染预算集中到用户最敏感的画面区域。
  • 贯穿材料：工业驾驶舱帧能同时暴露文字清晰度、周边运动、眼跳延迟和分区边界问题。
  • 视觉中心：注视点附近承担文字、细线、交互目标和高频细节的清晰度要求。
  • 周边区域：周边视觉对细节分辨率较低，但仍然敏感于运动、闪烁、亮度突变和深度错位。
  • 时间对齐：gaze 样本需要对齐 predicted display time，旧采样会让清晰区落在用户已经离开的区域。
  • 空间转换：每只眼需要独立的 gaze point 和 rate map，IPD、projection 和 lens distortion 会影响分区位置。
  • 实现路径：variable rate shading 通过 rate map 改变 tile 着色频率，多分辨率渲染通过不同分辨率区域重建 eye buffer。
  • 保守分区：低置信度和快速扫视应扩大中心区与过渡区，把错位风险转成可控的性能让步。
  • 系统拆分：gaze input、rate map、multi-resolution render、temporal smoothing 和 debug overlay 应分阶段观察。
  • 质量评估：中心清晰度、周边稳定性、后处理历史和眼动延迟需要一起检查。
  • 性能评估：收益应落到具体 pass 的 GPU 时间、fragment workload、纹理带宽或后处理开销。
  • 场景策略：游戏、工业可视化、远程渲染和 AR 的保守区域不同，但都要围绕用户当前任务调参。