为什么 GPU 渲染时间不一致？

Question

我正在使用 THREE 构建一个 WebGL 应用程序，并注意到 GPU 上出现了一些奇怪的时序。我目前没有可用的重现代码，但我想我会问这个问题，以防它是一个已知的浏览器怪癖或常见且可修复的东西。

场景设置

• 具有约 2,000,000 个多边形、136 个网格和 568 个 Object3D 实例的场景。
• 将 THREE.Composer 与 FXAA 和 Unreal Bloom 通道结合使用。
• 使用 THREE.OrbitControls。
• 仅当已知某些内容发生更改时才会渲染场景。例如，当用户拖动场景以使用控件移动相机或场景中的某些东西移动时，就会安排绘制。场景通常是静态的，因此我们尽量不要在这些情况下进行不必要的渲染。

问题

当场景是静态的（暂时未绘制）然后用户通过拖动更改相机位置时会出现此问题。一旦用户开始拖动，帧率就会非常不稳定——可能是 10-20 fps 或更低——持续几帧，然后平滑回到接近 60 的水平。当场景保持几秒钟然后再次拖动时，这种情况会一直发生。如果鼠标在初始卡顿后持续拖动，则帧速率保持平滑。这些帧没有呈现任何不同。

如果使用requestAnimationFrame 渲染每一帧，则不会发生这种卡顿，并且场景仍然很流畅。

这是仅在某些情况发生变化时才渲染场景时出现卡顿的性能分析器。您可以看到，在再次平滑之前出现卡顿的帧期间，GPU 花费了更多时间：

场景以 60 fps 渲染时的分析器：

有什么想法吗？为什么在拖动时突然发生这么多 GPU 工作？绘制是否会被其他渲染进程阻止？为什么在几秒钟没有渲染后会如此一致地发生？我使用最新版本的 Chrome 进行了分析，但 Firefox 中也存在口吃。

谢谢！

Answer 1

没有现场样本，就没有简单的方法可以知道但是......

1 Three.js 可以对对象进行平截头体剔除。

这意味着如果某些对象不在视图之外，它们将不会被绘制。因此，将相机放置在所有物体可见的情况下会比只有一些物体可见时运行得更慢

2 原始剪辑

除 GPU 级别外，与上述相同。 GPU剪辑基元（它不会在视图之外绘制或计算像素）与上面非常相似，如果您尝试绘制的许多东西恰好在视图之外，它会比一切都在视图内运行得更快查看。

3 深度 (Z) 缓冲区拒绝

再次与上述类似，如果您的对象是不透明的，那么如果通过深度测试一个像素位于现有像素的后面，那么 GPU 将跳过调用像素着色器（如果可以）。这意味着如果你画了 568 个东西，而你画的第一个是离相机最近的东西，并且覆盖了它后面的很多东西，那么它的运行速度会比它后面的所有东西都先绘制的情况要快。 Three.js 可以选择在绘制之前进行排序。通常为透明度打开排序，因为需要将透明对象绘制回前面。对于不透明的对象，如果前面的对象遮挡了后面的对象，则从前到后绘制会更快。

4 画的帧太多？

另一个问题是您如何排队抽奖？理想情况下，您只排队一次抽奖，在抽奖发生之前不要再排队。

所以

// bad
someElement.addEventListener('mousemove', render);

上面的代码会尝试为每次鼠标移动进行渲染，即使是 > 60 fps

// bad
someElement.addEventListener('mousemove', () => {
  requestAnimationFrame(render);
});

上面的代码可能会排队很多很多 requestAnimationFrames 所有这些都将在下一帧执行，每帧多次绘制你的场景

// good?
let frameQueued = false;

function requestFrame() {
  if (!frameQueued) {
    frameQueued = true;
    requestAnimationFrame(render);
  }
}

function render(time) {
  frameQueued = false;
  ...
}      


someElement.addEventListener('mousemove', () => {
  requestFrame();
});

或者类似的东西，这样你最多只能在渲染时排队，在渲染完成之前不再排队。上面的代码只是构建代码的一个示例，这样您就不会绘制超出需要的帧数。