本文把 MR 头显的端到端延迟逐段拆开说明哪些是硬件固定成本、哪些是软件可以压缩的部分并给出各阶段的实际优化手段与踩坑记录。文中数值为 90Hz 设备上的典型预算参考值非某一具体产品的实测数据。目录一、问题背景二、把 20ms 拆开看三、三段硬件固定成本3.1 曝光与积分约 3ms3.2 出帧传输与同步约 2ms3.3 显示扫描约 5ms四、软件可控的 11ms 怎么抢4.1 追踪解算约 3ms4.2 姿态预测 1ms4.3 双目渲染约 5.5ms4.4 畸变校正与合成约 2ms五、TimeWarp最后一道防线六、踩坑记录七、小结一、问题背景做 XR 的人都知道一句话延迟超过 20ms 就开始有人不适超过 30ms 大部分人会晕。但这句话本身没什么用——它只告诉了你红线在哪没告诉你时间花在哪。真正做开发时遇到的困境是帧率明明稳在 90fpsGPU 占用只有 60%可头部转动时画面还是黏。这时候你去查性能面板CPU 不忙、GPU 不忙、没有掉帧一切正常。问题在于帧率衡量的是吞吐延迟衡量的是时延两者之间没有必然关系。一台设备可以稳定跑满 90fps每帧 11.1ms同时拥有 45ms 的端到端延迟——因为它同时在处理三、四帧画面。流水线越深吞吐越高但时延也越大。所以优化 XR 体验不能盯着帧率看必须盯着motion-to-photonMTP从你的头开始转动到屏幕上对应画面真正被光子照亮,中间流逝了多少时间。这篇文章把这条链路完整拆开。二、把 20ms 拆开看一次完整的 motion-to-photon 链路包含七个阶段。下面这张表是 90Hz 设备上的典型预算分布参考值阶段典型耗时属性谁负责传感器曝光与积分≈ 3.0 ms硬件固定相机模组出帧传输与同步≈ 2.0 ms硬件受控MIPI / ISP追踪解算≈ 3.0 ms软件可控VIO / SLAM姿态预测与外推 1.0 ms软件可控运行时双目渲染≈ 5.5 ms软件可控应用 GPU畸变校正与合成≈ 2.0 ms软件可控运行时 Compositor显示扫描逐行点亮≈ 5.0 ms硬件固定显示模组合计≈ 21.5 ms——这张表最值得注意的不是总数而是属性列7 个阶段里有 3 个是硬件固定成本合计 10ms。也就是说在 20ms 的延迟预算里软件真正能控制的区间只有大约 11ms而这 11ms 里还要塞进一帧完整的渲染。这解释了一个很反直觉的现象当你的应用已经跑满 90fps 时延迟优化的空间其实已经很小了。因为帧率只保证渲染能在 11ms 内完成它管不到曝光、传输和扫描。三、三段硬件固定成本3.1 曝光与积分约 3ms相机不是瞬间拍照。CMOS 传感器需要一段时间累积光子这段时间叫曝光时间或积分时间。在室内典型照明下为了让画面足够亮曝光时间通常在 2~4ms。它为什么不能随便缩短因为缩短曝光 → 进光量不足 → 图像噪声上升 → 特征点提取质量下降 → 追踪精度下降。这是一个闭环的反向作用为了降低延迟而去缩短曝光反而可能让追踪漂移导致用户感知到的稳定性变差。可行的做法提高环境亮度上限用红外补光辅助追踪相机这是一个常见设计采用全局快门global shutter而非卷帘快门减少行间时序差——这不会降低曝光时间但能显著降低运动畸变接受这段成本转而在后面的阶段补偿。3.2 出帧传输与同步约 2ms从传感器读出、经过 MIPI CSI-2 传输、可能经过 ISP 处理、最终进入内存并打上时间戳。这一段真正的问题不是耗时而是多路相机之间的时序一致性。MR 头显通常有 4 路黑白追踪相机 2 路彩色透视相机 1 路深度模组。如果各路相机的出帧时刻互不相同、时间戳又由不同模块各自打点那么后续所有依赖同一时刻的算法都会引入难以定位的误差。这是必须在 HAL 层解决的问题应用层无法补救需要硬件级的同步触发以及统一的时钟域打点。3.3 显示扫描约 5ms这是最容易被忽略的一段。LCD/OLED 面板不是整帧瞬间显示而是逐行扫描。一帧 2160 行的画面在高刷新率下从第一行扫描到最后一行需要几毫秒。更关键的是扫描顺序与渲染顺序的关系。如果从上往下扫描而你最后渲染的是画面顶部那么顶部的光子延迟最长。有些系统会采用与扫描方向一致的渲染顺序rolling render来降低平均延迟。这一段同样是软件无法消除的只能通过提高刷新率来缩短。四、软件可控的 11ms 怎么抢现在进入真正的战场。11ms 要分给追踪、渲染、合成三件事。4.1 追踪解算约 3ms追踪必须在下一帧渲染开始前给出位姿否则应用只能用旧位姿渲染。典型流水线是相机帧 (60fps) → 前端角点提取 帧间跟踪降采样后处理特征数控制在 100~300 → 后端滑动窗口 BA IMU 预积分窗口 10 帧左右 → 输出 6DoF 位姿500~1000Hz 上报优化手段图像降采样在 1/2 分辨率上做特征提取精度损失可控耗时可降一半以上限制特征数量后端计算规模与特征数近似平方相关把 500 个特征降到 200 个收益远大于优化前端感知加速单元卸载把前端特征提取放到 SoC 内的专用加速器上CPU 只做后端优化设置迭代次数上限宁可给出够用的结果也不要让一次优化吃掉 10ms。关键取舍追踪精度和解算耗时是直接冲突的。工程上的做法是动态调节——静止或慢速运动时提高精度快速转头时降低精度保证实时性。因为快速运动时用户对细节的敏感度本来就低。4.2 姿态预测 1ms这是整个链路里性价比最高的一环。因为从追踪算出位姿到光子出屏中间还有 10ms这 10ms 里头部还在动。渲染时用的是过去的位置显示时用户已经转到了新的位置。姿态预测就是根据角速度、角加速度把姿态外推到显示时刻。外推的精度直接决定了 TimeWarp 的效果// 简化示意用一阶 二阶项外推姿态// t_delta 为从位姿采样时刻到预计显示时刻的时间差QuatpredictOrientation(constQuatq_now,constVec3angVel,// rad/sconstVec3angAcc,// rad/s^2floatt_delta){// 一阶项主导角速度积分Vec3 deltaangVel*t_delta;// 二阶项修正角加速度高速运动时贡献明显delta0.5f*angAcc*t_delta*t_delta;returnq_now*quatFromAxisAngle(delta);}工程注意点二阶项的收益只在中低速有意义。快速甩头时角加速度噪声很大盲目加二阶项反而会引入抖动。实践上通常按角速度大小分档处理或者对二阶项做限幅。另一个细节是t_delta的确定它必须来自显示服务的扫描时刻预测而不是简单地取半帧时间。这个值算错了预测就等于白做。4.3 双目渲染约 5.5ms这是最大的一块也是优化手段最多的。核心思路只有一句话不要渲染你看不见的像素。手段原理相对收益经验值多视图渲染双目视图矩阵在驱动层合并为一次绘制避免顶点处理与提交重复CPU 提交开销降 30%~50%注视点渲染FFR/DFR中心凹保持高分辨率边缘降采样GPU 填充负载降 20%~40%动态分辨率按 GPU 负载实时调整渲染目标尺寸把掉帧概率显著压低视锥剔除 LOD不渲染视锥外与远处高模与场景强相关其中多视图渲染是必选项——它几乎没有画质代价只是把两次提交合成一次。而注视点渲染有画质代价需要调参找到临界点。4.4 畸变校正与合成约 2ms这一步包含桶形畸变反向映射、RGB 三通道色差补偿、以及虚实画面的 Alpha 混合。优化原则只有一条不要产生中间纹理。理想做法是在最终合成的一个 pass 里同时完成畸变采样、色差补偿、TimeWarp 重投影和虚实混合。任何先渲染到纹理 A再读回来处理成 B的做法都会带来一次额外的显存带宽往返。五、TimeWarp最后一道防线TimeWarp或叫 Reprojection / 重投影做的事是在不重新渲染场景的前提下用最新姿态对已经渲染好的画面做一次二维重投影。它的价值在于把姿态新鲜度从渲染结束时刻推进到接近显示时刻能补掉大约一帧的延迟。// 合成阶段的 TimeWarp把已渲染的画面按姿态差重新投影// 注意这是 2D 重投影只能补偿旋转无法补偿平移视差for(autovertex:fullscreenQuad){Vec3 rayunproject(vertex,oldViewProj);Vec2 warpedproject(ray,newViewProj);colorsample(renderedTexture,warped);}必须知道的三个限制只能补偿旋转。纯 2D 重投影无法处理平移带来的视差变化所以它解决不了前后移动时物体位置不对的问题画面边缘会露出。重投影会把画面推出原来的边界需要放大一点引入 5%~10% 的超采样或用黑色填充否则会看到黑边它是补偿不是修复。如果预测本身错了TimeWarp 只会把错误一起搬过去。六、踩坑记录坑 1只优化渲染帧率上去了眩晕感没减轻现象把渲染耗时从 9ms 降到 6ms帧率稳定 90fps但测试用户仍反馈转头时跟不上。原因渲染耗时下降不等于延迟下降。如果换帧时机没有跟着提前只是流水线变得更空延迟一点没变。解决用逐帧打点测量各阶段真实耗时确认瓶颈在追踪解算3ms 中实际用了 6ms而不是渲染。坑 2把帧时间当成延迟来做预算现象按 11.1ms 做单帧预算结果各阶段加起来卡在 11ms端到端却有 22ms。原因混淆了吞吐帧时间与时延端到端。显示器扫描与传感器曝光根本不在帧里。解决把预算拆成两张表——一张是单帧时间预算CPU/GPU 分配一张是端到端延迟预算含硬件固定成本。坑 3TimeWarp 让边缘渗出黑边现象快速转头时画面边缘出现黑边或拉伸。原因重投影后采样点超出原画面范围且没有做超采样。解决渲染目标放大 5%~10%或对超出区域做边缘钳制采样。放大比例与用户头部最大角速度相关需要实测调参。坑 4姿态预测用了错的 t_delta现象快速转头时画面出现过冲转过头再弹回来。原因预测时假设的显示时刻比实际早了半帧导致外推不足又叠加了 TimeWarp 的二次矫正两个误差叠加。解决t_delta必须由显示服务给出的扫描时刻计算并在运行时统计接口中暴露预测姿态 vs 实际姿态的偏差作为持续监控指标。七、小结延迟和帧率是两回事。帧率看吞吐延迟看端到端流水线越深吞吐越高但时延可能反而变大。20ms 里有 10ms 是硬件固定成本曝光 3ms 传输 2ms 扫描 5ms软件可优化区间只有约 11ms。优化优先级先保证多视图渲染零画质代价→ 再做动态分辨率防止掉帧→ 最后调注视点渲染有画质代价需要找临界点。姿态预测与 TimeWarp 的性价比最高因为它们不需要降低任何渲染质量纯粹靠时序信息捡回一帧的延迟。但两者都必须以准确的显示时刻预测为前提。适用边界以上数值基于 90Hz、移动 SoC、双目 VST 方案的 MR 一体机。刷新率提升到 120Hz 时渲染预算压缩到 8.3ms但硬件固定成本中扫描一段会同步缩短整体延迟下降会比单纯按比例估算更明显。–
