html - 使用 chrome://tracing 分析 WebGL

Question

我正在尝试提高我的延迟渲染器的 FPS，所以我偶然发现了 chrome://tracing （这里和这里）。我添加console.time并console.timeEnd为我渲染的每一层。你可以在这里看到它们：

http://i.imgur.com/Rh5jfpN.jpg

我的跟踪点是以 开头的最上面的项目node/...，它们一起运行大约 2 毫秒。gl*所有的调用都在这两毫秒内完成。我目前的 FPS 大约是 38 FPS，一帧大约 28 毫秒。现在是另一张使用 GPU 进程缩小的图片：

http://i.imgur.com/sM4aAXB.jpg

您仍然可以在那里看到跟踪点，顶部的小条。奇怪的是，Chrome 渲染两帧的速度非常快，然后运行这个神秘的DoSwapBuffers/Onscreen任务，停止渲染大约 25 毫秒，加上MakeCurrent与第二帧重叠的任务（如在两个快速连续帧中），这需要 15 毫秒。

在我看来，Chrome 将所有 WebGL 任务推迟到以后，因此无法进行任何类型的分析。但这只是我的猜测。如何处理这个问题以及如何分析我的 WebGL 代码？

Answer 1

由于 GPU 独立于 JS 主线程运行，因此只要没有将渲染数据直接反馈到 JS 上下文中，它就不会与 JS 活动同步。因此发出任何 WebGL 命令都不会阻止 JavaScript 继续执行，并且只有在 GPU 完成 JS 发出的所有操作后才会显示帧。

因此，在此跟踪中不可能看到任何 WebGL 操作的实际计算时间。

但是有一个简单的技巧：通过将一些与渲染相关的数据拉回 JS 世界来同步 JS 线程。最简单的做法是将每个中间纹理的一些像素渲染到 3D 画布，然后通过 2D 上下文drawImage方法将此画布渲染为 2D 画布（确保通过 访问此画布ctx.getImageData()）。这种方法很慢，并且会增加一些时间，同时使所有 WebGL 绘制操作对分析/跟踪可见。请注意，这也可能会在一定程度上扭曲结果，因为所有内容都将被迫按顺序计算，并且 GPU 驱动程序无法优化独立绘制操作以相互交错。