问题描述
我正在使用最新版本的Chrome(和Firefox)编写WebGL(GLSL ES 1.0)的片段着色器，并编写了迭代算法.
I'm writing a fragment shader for WebGL(GLSL ES 1.0) using the latest version of Chrome(and Firefox), and I wrote an iterative algorithm.
因此，首先，我发现了一种很难的方法，即循环的长度受到了严格的限制(文档说它在编译时必须是可猜测的，这意味着它必须是一个常数或非常接近).
So first of all, I found out the hard way that the length of the loop is quite restricted (doc says it must be guessable at compile-time, which means it must be a constant or very close).
此外，我必须编写一个(for，因为它是唯一必须按标准实现的 )循环，可能很长，但几乎每次结束之前都会中断.
In addition, I must write a (for, since it's the only one which must be implemented according to the standard) loop that's potentially long but that breaks almost every time before the end.
现在，我注意到，如果我设置了更高的最大数字，则着色器的编译和链接将花费更多的时间.因此，除非我错了，否则编译器会循环展开.
Now, I've noticed that if I set a higher maximum number the compilation and linking of the shader takes alot more time. So, unless I'm wrong, the compiler does loop unwinding.
我不确定是否可以做任何事情，但是我尝试了一些事情，即使在循环中调用，编译器似乎也可以内联函数.
I'm not sure if anything can be done, but I've tried a few things and the compiler seems also to inline functions, even when called in loops.
我认为着色器花一整分钟的时间来编译大约一百次循环是不正常的.还是我做错了事?对于GPU而言，以片段着色器方式进行的一百次迭代是否过多?因为它似乎在编译后就可以正常运行.
I don't feel like it's normal for a shader to take a whole minute to compile for just about a hundred iterations of a loop. Or am I doing the wrong thing? Is a hundred iterations in a fragment shader way too much for a GPU? Because it seems to run just fine after it has compiled.
推荐答案
这是GLSL的不幸现实之一.如果我们可以进行离线编译并发送字节码，或者如果我们能够在编译时指定标志等，那将是很好的，但这不是规范的工作原理.您完全由驱动程序制造商摆布.如果NVIDIA/ATI认为循环展开对您有利，那么您的循环将被展开.
This is one of the unfortunate realities of GLSL. It would be great if we could do an offline compile and send in bytecode, or if we had the ability to specify flags at compile time or so on, but that's just not how the spec works. You are entirely at the mercy of the driver manufacturer. If NVIDIA/ATI thinks loop unrolling is good for you, your loop is gonna get unrolled.
我确实质疑您正在做的事情需要大量的循环.着色器并不是进行超级复杂的循环或分支计算的正确位置.您肯定会对它产生性能上的冲击.如果您不担心实时性能，那么在程序开始时遇到很大的编译问题可能还不错.如果您担心应用的渲染速度，则可能需要重新评估着色器的复杂性.
I do question what it is that you are doing that requires so much looping, though. Shaders are not really the right place to be doing super complex looping or branching calculations. You'll certainly take a performance hit for it. If you're not worried about realtime performance, then perhaps a large compile hit at the start of your program isn't so bad. If you are concerned about the rendering speed of your app then you likely need to re-evaluate your shaders complexity.
这篇关于防止片段着色器中的循环展开的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！