高帧率下DX12/Vulkan移动点光源立方体贴图阴影伪影调试求助

这个问题是显式图形API下非常典型的CPU-GPU资源同步疏漏，DX11因为驱动层默认做了全链路隐式资源保护所以不会触发，暂停/抓帧/加微小延迟就消失的特征完全符合这类问题的表现——上述操作都会强制GPU排空命令队列，刚好掩盖了资源读写竞争的问题，不需要在阴影算法、深度精度这类方向浪费排查时间。

第一优先级：动态常量缓冲区帧同步问题排查 #

你之前用Tracy只核对了CPU侧的提交时序，没有覆盖GPU侧实际资源读写的时序，大概率漏了以下问题：

• 检查用于传递光源位置、阴影投影矩阵的动态常量缓冲区的帧轮转池配置：如果你的轮转池是按常规3帧并行配置的，在800fps这种极高帧率下，GPU命令队列预缓存的帧数很可能超过3，CPU写入新帧矩阵数据时，GPU还在读取旧帧的常量缓冲区，就会出现阴影位置和实际光源位置的偏差。0.5ms的停顿刚好拖慢了CPU提交速度，让CPU写入速度没有追上GPU的读指针，问题就消失了。
• 修正判断逻辑：不要靠CPU侧的命令提交顺序判断资源是否可写，每次Map动态缓冲区写入数据前，必须等待对应帧的GPU fence完全触发，确认GPU已经完成了该缓冲区所有读操作之后再写入。
• 核对双Pass的缓冲区绑定偏移：确认阴影立方体贴图渲染Pass、主场景渲染Pass读取光源矩阵时，用的是同一个帧轮转槽位，不要出现阴影Pass取N-1帧数据、主Pass取N帧数据的情况。低帧率下帧间隔长、光源移动距离小，偏差肉眼不可见，高帧率下光源移动快偏差就会暴露，抓帧时强制全队列同步会让两个Pass读到同一份最新数据，伪影自然消失。

第二优先级：阴影资源依赖与屏障排查 #

• 检查立方体贴图阴影的资源屏障配置：不要靠命令提交顺序保证依赖，必须显式插入屏障，确保主场景Pass开始采样阴影贴图前，6个立方体面的深度写入全部完成，资源状态已经从DEPTH_WRITE切换为PIXEL_SHADER_READ。高帧率下GPU的命令调度空隙极小，很容易碰到资源还在写入就被采样的情况，低帧率下GPU天然有空闲等待写入完成，不会触发问题。
• 检查阴影贴图的Descriptor更新时序：确认绑定到主Pass的阴影贴图SRV、常量缓冲区CBV描述符，在GPU执行主Pass前已经完成写入，不要出现Descriptor刚被CPU更新、GPU还没读到新值就开始执行的情况。

可稳定复现定位问题的调试手段 #

常规抓帧工具会强制插入全局同步冲掉问题，改用以下无侵入的调试方式：

• 做帧数据埋点：在CPU写入阴影矩阵、阴影Pass提交、主Pass提交三个节点，把当前帧号、光源位置、矩阵值写入内存环形日志缓冲区，问题出现时直接导出最近100帧的日志，对比两个Pass用到的光源位置差值，不需要依赖抓帧工具。
• 强制限制并行帧数量：DX12下把交换链的MaxFrameLatency设为1，Vulkan下把交换链minImageCount设为1，关闭所有多帧并行优化，如果改完问题完全消失，可以100%确认是帧轮转资源的同步逻辑错误。
• 加校验标记：每帧给阴影Pass、主Pass传递的光源数据附加一个同帧生成的唯一校验值，shader里如果检测到两个Pass的校验值不一致，直接把对应像素输出为显眼的红色，不需要靠肉眼识别阴影偏差，也不会因为同步操作丢失问题现场。

容易忽略的细节 #

• 如果你开了Present的低延迟模式、允许撕裂模式，Present操作不会等待垂直同步，CPU提交命令的速度会远高于GPU执行速度，帧轮转资源的实际占用量会远高于常规垂直同步场景，之前按3帧并行配置的资源池很可能不够用。
• 不要漏查阴影Pass的视口、深度范围参数的绑定逻辑，这类参数如果和光源位置不同步，也会出现类似的阴影偏差。

这类问题如果不修复，后续接入更复杂的透明Pass、后处理Pass、多线程提交逻辑时，会随机出现更严重的资源撕裂、画面花屏问题，不是可以忽略的小问题。

内容的提问来源于stack exchange，提问作者Varrak