我目前正在写我的论文，主题是通过三重缓冲提高 WebGL 的渲染性能，或者只是避免一般的同步。我目前正在尝试了解WebGL 机器何时以及为何同步，就像在一个进程中以任何方式在内部或外部等待另一个进程一样。
我基本上想找出 WebGL/OpenGL 渲染管道中的任何潜在瓶颈。
我仍然没有找到具有足够详细规范的书或任何其他来源。有什么指示或解释吗？
问问题
623 次
2 回答
5
渲染瓶颈：
着色器编译。因为 WebGL 可以运行移动平台，所以我认为其行为类似于 Opengl ES，并且这里的着色器是在第一次绘制调用时编译的。这可以通过在加载着色器时渲染一个像素以防止在进入主循环时进行编译来解决。同样在 opengl ES 着色器中，可以触发重新编译，然后着色器内的统一纹理会更改格式。（我认为这也值得在 webgl 中进行研究）
不断切换着色器或纹理单元：解决此问题的方法是通过着色器的使用和纹理使用对渲染进行排序，因此，例如，当您有 2 个着色器程序时，您首先使用第一个着色器渲染所有内容，然后使用第二个着色器渲染所有内容，而不是在第一和第二之间不断切换。这个想法是最小化着色器使用之间的切换。
在混合状态之间切换（或不断使用混合）。至少在移动设备上混合是昂贵的，所以你应该尽量减少它的使用。如果您经常这样做，切换混合状态也可能需要时间。再次为了解决这个问题，您应该首先渲染所有实体，然后渲染所有需要混合的内容。
一般来说，切换状态可能很昂贵，就像第 3 点一样，您需要避免不断的状态变化（深度缓冲区状态/模板状态/混合状态/等）。
很多draw call。这里的想法是尽可能少的绘制调用，并避免在许多小部分中绘制几何图形（不要在这里混淆几何图形的数量可以相同）。要解决这个问题，您必须移动可以合并到一个顶点数组中的所有内容。因此，如果您有例如 100 个要绘制的框，请避免调用 draw 100 次，而是为每个框创建一个具有顶点的顶点数组（您用内存换取性能）。如果 WebGL 支持实例化，那么您基本上可以在没有内存损失的情况下做同样的事情。
于 2013-11-12T13:40:41.500 回答
1
只是对以后可能偶然发现这个问题的其他人说清楚：
答案是同步依赖于实现，与 OpenGL/WebGL 标准几乎没有关系。可以对有限长度的命令队列进行一些假设，并且垂直同步将导致同步。但除此之外，将取决于所讨论的特定显卡。
于 2013-11-16T09:22:23.753 回答