为什么 MR 头显必须把合成放在 GPU 最后一级TimeWarp 与 late-latch 的工程取舍摘要在 90Hz 的 MR 一体机上从应用提交一帧到光子出屏还要走 ~16ms这段时间里头部仍在转动。如果合成发生在应用渲染的同一帧屏幕上看到的位姿就会落后用户实际头部位置。本文拆解 late-latch延迟姿态锁存与 GPU 最后一级合成的关系、TimeWarp 的四种误差来源及其工程取舍给出可编译的代码示例与典型踩坑记录。文中延迟预算均为 90Hz 设备上的典型量级非某一具体产品的实测数据。目录为什么 MR 头显必须把合成放在 GPU 最后一级TimeWarp 与 late-latch 的工程取舍一、问题背景二、为什么合成必须是 GPU 最后一级2.1 一个反直觉的算式2.2 late-latch 的定义2.3 为什么必须是 GPU 最后一级三、TimeWarp 的工程实现3.1 流水线伪代码3.2 关键参数 t_delta 的来源四、TimeWarp 的四种误差来源4.1 旋转可补偿平移不可补偿4.2 边缘渗出与超采样4.3 预测姿态的代价4.4 姿态锁存失效——最大的未知误差五、踩坑记录六、小结一、问题背景XR 头显的延迟红线是 20ms这是常识。但很多人对它的理解停留在渲染要在 11ms 内完成于是只盯着渲染耗时优化帧率确实上去了转头时画面依然黏。上一篇《MR 一体机延迟拆解20ms 里软件其实只抢得到 11ms》里我们把这条链路完整拆开过本文接着讲那个 11ms 之外、却被很多人忽视的问题合成时机。90Hz 设备的帧时间预算 11.1ms。但应用渲染结束、提交到扫描线末端这中间还有扫描过程——逐行点亮的 LCD/OLED 从第一行扫到最后一行大约 5ms。在扫描的 5 分钟里用户的头部并没有停下他还在以一个真实的角速度转动。这就出现了一个看似微小但工程上致命的差应用结束渲染用的位姿落后于光子落在屏幕上那一刻用户的实际头部位置。常见的错误做法是在应用渲染的同一个 pass 里完成 TimeWarp 重投影 合成 输出。这个做法在 PC 显示器上看不出问题但在头显里会立刻表现为快速转头时画面整体飘。业界对此的解决方案叫late-latch延迟姿态锁存它要求合成必须是 GPU 流水线的最后一级并且要等到扫描时刻才能锁定本次合成用的姿态。本文拆开它的来由。二、为什么合成必须是 GPU 最后一级2.1 一个反直觉的算式设t_render_done 应用结束渲染的时刻t_scanout_start 扫描线开始扫本帧第一行的时刻t_scanout_end 扫描线扫到最后一行的时刻即用户实际看到完整画面头部位姿刷新率 1000Hz陀螺仪典型量级那么[t_render_done, t_scanout_end] ≈ 5ms 头部位姿在这 5ms 内的角位移 ≈ ω × 0.005s 若 ω 60°/s普通转头则差 ≈ 0.3°0.3° 听起来不大。但在头显里换算成屏幕中心像素偏移单眼水平 FOV ≈ 90°单眼分辨率 ≈ 1800px1° ≈ 20px → 0.3° ≈ 6px6px 的偏移在静止画面上是看不出来的但在用户转动时它会产生一种画面追不上头的感知业内叫swim。这就是很多设备帧率稳、延迟不舒适的真正原因不是帧率不够而是合成时机不对。2.2 late-latch 的定义late-latch 是一种姿态锁存策略不在应用渲染结束的t_render_done锁定姿态而是把姿态推到扫描过程中某个时刻t_scanout_lock才被采用。t_scanout_lock通常取t_scanout_start N / 2 × row_time即平均扫描中点这是平衡合成器等待延迟与预测误差的工程取舍。工程实现上分两步应用在t_render_done时向合成器提交一帧纹理 元数据但合成器此时不读合成器持续监听扫描线位置驱动层会暴露这个信号扫描到t_scanout_lock时才重新读一次最新姿态并把这个姿态作为合成这一帧的输入。注意一个细节应用结束渲染时的位姿此时已经被合成器抛弃因为它太旧。合成器用的姿态是扫描过程中的最新值由陀螺仪 1kHz 上报的角速度外推出来。2.3 为什么必须是 GPU 最后一级理解了 late-latch你就明白为什么合成不能放在应用层应用层无法监听扫描线位置这是 GPU/显示驱动层的能力应用层拿到t_render_done时的姿态后就失去更新机会陀螺仪数据不会回流到应用合成器必须在 GPU 流水线的最后一站因为它要等到扫描开始才确定姿态——任何更早的合成都意味着用了旧姿态。结论合成器 GPU 流水线最后一级 late-latch。这两条是绑定的少一条都不行。下面这张表把 4 种合成方案的误差做个量化对比估算值基于 60°/s 转头场景方案合成时机姿态新鲜度转头时屏幕偏移估算应用层合成错误t_render_done渲染结束时旧~12pxGPU 中段合成半错渲染结束后 ~2ms略新~8pxGPU 最后一级 立即锁存半错合成前固定时刻一般~5pxGPU 最后一级 late-latch正确t_scanout_lock扫描最实时2px最后一种是工业界唯一可接受的方案。三、TimeWarp 的工程实现TimeWarp在 OpenXR 里叫 Reprojection是合成阶段的最后一步把已经渲染好的画面按扫描线中的最新姿态做一次二维重投影。3.1 流水线伪代码// 合成线程GPU 流水线最后一级持续循环while(running){// 1. 等应用提交一帧本帧未就绪则重复上一帧推荐if(appFrameQueue.tryPop(submittedFrame)){latestFramesubmittedFrame;}// 2. 等扫描线进入 [t_lock_start, t_lock_end] 的窗口期waitForScanlineInWindow(scanlinePos);// scanlinePos 是 GPU/驱动层给出的实时扫描行号// 3. 读陀螺仪最新姿态Pose latestPoseimu.readLatest();// 1000Hz 量级// 4. 计算 t_scanout_lock 时刻的预测姿态用角速度外推floatt_deltat_scanout_lock-imu.lastSampleTime();Pose poseAtLockpredict(latestPose,gyro,t_delta);// 5. TimeWarp用 poseAtLock 对 latestFrame.texture 做重投影warp(latestFrame.texture,latestFrame.projMatrix,poseAtLock,oldPose:latestFrame.appliedPose);// 6. 输出到扫描线驱动层 handlescanout(warpOutput);}注意latestFrame.appliedPose——这是应用提交这一帧时使用的姿态TimeWarp 必须知道它跟当前锁存姿态差多少否则不知道该怎么重投影。3.2 关键参数t_delta的来源predict()里的t_delta不是简单的半帧时间它必须是t_scanout_lock 与最近一次 IMU 采样的时间差。这两者都需要走显示服务与 IMU 子系统才能拿准的时钟t_scanout_lock由显示驱动给出部分 GPU 厂商如 Qualcomm Adreno会通过 vendor extension 暴露IMU 时间戳通常来自 SoC 内的高精度定时器独立于系统 tick。如果这两个时钟没对齐t_delta算出来就有偏差——下面踩坑记录里会说这种情况。四、TimeWarp 的四种误差来源理解了流水线再看误差。TimeWarp 不是银弹它有明确的边界4.1 旋转可补偿平移不可补偿TimeWarp 本质是2D 像素重投影它能把已渲染画面绕视线中心旋转对齐到新姿态的旋转画面。但不能补偿平移带来的视差。工程上的取舍90% 的头部运动是旋转转头、点头、歪头TimeWarp 对这些场景效果最好平移前后走动产生的视差需要深度信息才能正确处理简单的 2D TimeWarp 解决不了高端头显Quest Pro、Vision Pro会同时做Depth-Warp依赖深度纹理做反向重投影能处理平移视差但代价是每帧多一次深度纹理采样与重投影。是否上 Depth-Warp 是产品定位问题不是技术能不能做。4.2 边缘渗出与超采样TimeWarp 后画面边缘会出现两类伪影画面外推露出黑边新姿态下看到的区域超出了原画面边界画面外推露出拉伸超出区域被钳制采样到原画面最外一圈的像素。解决方法是超采样渲染目标尺寸 显示尺寸 × (1 ε)经验值ε取 5%~10%。ε与用户最大角速度相关角速度越大重投影后采样点超出原画面的比例越高需要的 ε 越大。但 ε 越大意味着渲染压力越大必须权衡。4.3 预测姿态的代价predict()用的是一阶或二阶姿态外推// 一阶外推典型实现QuatpredictOrientation(constQuatq_now,constVec3angVel,// rad/sfloatt_delta){Vec3 deltaangVel*t_delta;returnq_now*quatFromAxisAngle(delta);}这种预测在中低速ω 60°/s误差很小但在快速转头ω 120°/s时有两个问题角速度本身有量测噪声外推会把噪声放大二阶项角加速度噪声更大盲目加二阶项反而引入抖动。工程做法按角速度大小分档。中低速走一阶 二阶外推高速关掉二阶项并适度降低外推量把误差留给 TimeWarp 的真实姿态去补偿。4.4 姿态锁存失效——最大的未知误差waitForScanlineInWindow()的窗口期设计是个工程难题窗口太宽等到扫描接近末端才锁姿态外推t_delta大预测误差大窗口太窄合成器来不及读完陀螺仪 完成重投影错过扫描时机 → 当帧不输出 → 黑屏或丢帧。工业上常见的窗口是扫描行 [10%, 30%]这个区间。但窗口期的具体行号跟面板时序、扫描方向、刷新率都相关必须用厂商提供的工具实测调参。五、踩坑记录坑 1合成放在了应用层帧率稳 90fps 仍感到 swim现象用户报告快速转头时画面整体飘性能面板显示 90fps 稳定GPU 占用 60%。原因合成发生在应用渲染的同一 pass姿态用的是t_render_done时刻的旧值扫描过程里 0.3° 的姿态差在屏幕上表现为 6px 偏移。解决把合成下沉到 GPU 流水线最后一级并启用 late-latch从 12px 偏移降到 2px。坑 2TimeWarp 后画面边缘出现黑边现象快速转头时画面四周露出黑色条带且随转头方向移动。原因重投影后的采样点超出了原渲染画面边界没有做超采样。解决把渲染目标尺寸放大 10%并对超出区域钳制采样到边缘像素。经验上转头最大角速度 180°/s 时 10% 足够更高需重新调参。坑 3t_delta用了固定的半帧时间结果转头时出现过头再回弹现象转头结束后画面轻微回弹一次呈现转过头→回正的反向运动。原因陀螺仪时钟与显示时钟没对齐t_delta算出来比真实值大一截外推过度外推过度 TimeWarp 的真实姿态校正两个误差叠加 → 过冲 → 回正。解决让显示服务与 IMU 子系统共用同一时钟域具体做法是让陀螺仪的时间戳对齐到显示 vsync并在线程里统计预测姿态 vs 实际扫描时刻姿态的偏差作为监控指标。坑 4窗口期设错扫描到 60% 才锁姿态预测误差反而放大现象普通转头没问题一旦快速甩头就出现明显 swim。原因窗口期设得过宽[40%, 60%]t_scanout_lock太靠后外推t_delta偏大预测误差随 t_delta 二次增长。解决把窗口期收紧到 [10%, 30%]并用厂商工具观察真实扫描时刻的分布再微调。六、小结合成必须是 GPU 最后一级。这是 late-latch 的硬件前提——应用层拿不到扫描线位置更新不了姿态合成时机只要不在最后一站就是错的。late-latch 是配套策略不是可选开关。它的价值是把合成用的姿态从t_render_done推进到t_scanout_lock把 ~5ms 的姿态老化窗口压到接近 0。TimeWarp 不是银弹能补偿旋转不能补偿平移能靠超采样压制边缘渗出但代价是渲染压力能用预测姿态抵消老延迟但快速运动时预测本身有误差。窗口期与时钟对齐是工程上最容易忽略的部分。陀螺仪时钟与显示 vsync 不对齐t_delta算错整个 late-latch 等于没做。适用边界以上分析基于 90Hz、单层 TimeWarp无 Depth-Warp、单眼 ~1800px 分辨率的 MR 一体机。引入 Depth-Warp、120Hz 刷新或注视点渲染后误差分布与窗口期参数都要重新调结论可参考但不能直接套用。建议标签XR / MR / 性能优化 / 图形渲染 / OpenXR建议分类专栏XR 系统开发