Webgl全屏混合减速答案

【问题标题】：Webgl full screen blending slowdownWebgl全屏混合减速
【发布时间】：2017-11-16 05:24:12
【问题描述】：

我尝试在 3D 场景中制作“叠加”效果。在将东西绘制到缓冲区后，我尝试绘制一个启用混合并禁用深度测试的全屏四边形。在某些 android 设备上，这似乎导致速度变慢。

我找到了这个link：

特别慢的点是像素的绘制需要检查它背后的颜色是什么。

因此，我没有绘制单个全屏四边形，而是将其划分为图块，并使用多个绘制调用进行渲染，这似乎带来了一些收益。

这里可能发生了什么以及如何使用 webgl 对其进行分析，即如何从上面的引用中得出结论？

【问题讨论】：

许多第一代和第二代安卓设备在减速之前不能绘制超过大约 1.5 个屏幕的像素。这对 WebGL 来说真的很糟糕，因为 WebGL 需要合成。因此，如果您在浏览器上有一个全屏 WebGL 页面，首先您将图像渲染到画布（即 1 个全屏绘图）。然后画布被渲染以将其与页面合成。那是另一个全屏绘图。添加您的后期处理通行证是另一个完整的绘图屏幕。甚至我的 2015 MBP 在达到 60fps 限制之前也只能绘制大约 10 个全屏像素。
即使这 10 个全屏像素只是一个恒定的颜色？
是的，颜色不变，但启用了混合。
我可以读什么类型的书来理解为什么？

标签： webgl gpu

【解决方案1】：

我想要对其进行分析，您只需使用几种混合功能进行测试，无论是否启用混合等...

混合不是一个简单的操作，实际上我们可以假设需要读取缓冲区上的像素的混合函数会导致性能损失，就像 OpenGL 中的所有“读取”操作一样，因为这会阻塞管道。我猜大多数现代桌面 GPU 都有一些特定的设计来优化这一点，但在手机上，这可能会更有问题。

无论如何，如果您要绘制一个全屏四边形，为什么不使用两个源纹理直接渲染您的四边形，然后使用自定义方程直接在片段着色器中混合它们？这样，您就不需要使用混合，并且可以避免任何后台缓冲区读取问题。

【讨论】：

好吧，我肯定会放弃的一件事是抗锯齿是否正确？实际上，我还想问一下，如果我尝试阅读整个纹理，发生的事情是否可能类似于会发生的事情。在图块中渲染似乎有所作为。
如果您仅限于 WebGL 1.0，这是真的，如果您只使用纹理，您将失去 MSAA。我认为读取整个纹理不是问题，因为它旨在以这种方式工作：read texture => fragment shader => write buffer，因此不会阻塞管道。我猜出现问题是因为混合需要读取后台缓冲区：fragment shader => read buffer => blending => write buffer。为什么使用瓷砖可以减少问题？可能是因为这一切都与内存带宽和访问有关……
我的理论是：当必须读取内存块时，必须停止所有写入过程，直到读取操作完成。如果你分成瓦片，写入操作只会在一个“瓦片”上阻塞，但其他的可以继续。在 GPU 中，一切都是并行化的，这是这个概念的优点和缺点。