我正在使用最新版本的 Chrome（和 Firefox）为 WebGL（GLSL ES 1.0）编写一个片段着色器，并且编写了一个迭代算法。
首先，我发现循环的长度是非常有限的（文档说它必须在编译时是可猜测的，这意味着它必须是一个常量或非常接近）。
另外，我必须写一个（for，因为它是唯一一个must根据标准实现）循环可能很长，但几乎每次都会在结束之前中断。
现在，我注意到，如果设置更高的最大数量，着色器的编译和链接会花费更多时间。因此，除非我错了，否则编译器确实会展开循环。
我不确定是否可以做任何事情，但我尝试了一些事情，编译器似乎也内联函数，即使在循环中调用时也是如此。
我觉得着色器花费一分钟来编译大约一百次循环迭代是不正常的。或者我做错了事？对于 GPU 来说，片段着色器中的一百次迭代是否太多了？因为编译后似乎运行得很好。
这是 GLSL 不幸的现实之一。如果我们可以进行离线编译并以字节码发送，或者如果我们能够在编译时指定标志等，那就太好了，但这并不是规范的工作方式。您完全受驱动程序制造商的支配。如果 NVIDIA/ATI 认为循环展开对您有好处，那么您的循环就会展开。
不过，我确实质疑您正在做的事情需要如此多的循环。着色器并不是进行超级复杂循环或分支计算的正确位置。您肯定会因此而受到性能影响。如果您不担心实时性能，那么程序开始时的大量编译命中也许并没有那么糟糕。如果您担心应用程序的渲染速度，那么您可能需要重新评估着色器的复杂性。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
