GLSL 编译器是否优化得很好答案

【问题标题】：Are GLSL compilers well optimizedGLSL 编译器是否优化得很好
【发布时间】：2014-04-18 06:24:56
【问题描述】：

最近的 GLSL 编译器是否智能/优化良好？

换句话说，如果我无脑写下类似的东西，最近的编译器会节省我的时间并优化掉不必要的代码，还是我应该总是小心我写的东西？

// All of the values are constants

if (3.7 == 3.7) // Will the condition be executed or removed at build time?
   x++;

// Will this whole block be entirely removed? (or should I use macros)
if (1 == 2)
    x++;

for (i = 0; i < 0; ++i) // Remove this
    x++;

for (i = 0; i < varA * varB; ++i) // Compute varA * varB once, outside the loop
    x++;

vec3 v = vec3(0);
if (length(v) > 0) // Remove
    x++;

float p = mix(varA, varB, 1); // p = varB

float p = 5;
p *= uniform * 0; // Just set a = 0 from the start

float p = 5;
p *= 1; // Remove that

还有很多事情我现在说不出来，但你应该明白这一点。

此外，最近的编译器是否可以自动检测不太明显的优化，例如那里描述的优化： http://www.opengl.org/wiki/GLSL_Optimizations

在“编译时间”与“优化时间”之间是否存在已知的权衡，由实现者或规范设置？

【问题讨论】：

你应该阅读humus.name/index.php?page=Articles&ID=6。简短的回答是“你不能确定”
这个读数令人沮丧。大文件通过。我想我仍然需要三思而后行我在写什么。然而 GLSL 似乎为一些优化留出了更少的空间（没有饱和，rcp，rsqrt，sincos...）
这也很大程度上取决于平台。例如，移动平台在编译着色器时没有太多时间用于优化。

标签： c++ opengl glsl compiler-optimization

【解决方案1】：

GLSL 编译器在浮点优化方面非常保守。您无法确定是否有任何特定的优化。经验法则是：尽你所能优化，不要指望 GLSL 编译器提供任何帮助。

阅读 Emil Persson 的 Low-Level Thinking in High-Level Shading Languages，了解有趣的细节和案例研究。

P.S：这个答案听起来可能很悲观。但是，GLSL 编译器在优化代码方面仍然做得很好。只是不要指望它并尽力而为。

【讨论】：

嗯，nvidia 的cgc（来自 cg 工具包）可以用来查看将生成的程序集，但它仅适用于 nvidia 驱动程序和工具包中的编译器版本驱动程序可能不同。对于其他实现——“神奇的事情发生了”，似乎没有人愿意将即时程序集至少作为扩展公开（除了 nvidia，他们有所有可用功能的程序集扩展）。
链接的演示文稿正在谈论 HLSL -- GLSL 完全不同，因为该语言明确允许编译器违反正常的 IEEE-754 精度规则，除非您使用特定的结构来保证。
@ChrisDodd：是的，但他们不必这样做。这是非常特定于编译器的。
没错，但是 GLSL 编译器是由硬件供应商编写的，因此他们有很大的动力全力以赴改进驱动程序基准测试结果（通常基于编写不佳的 GLSL 代码的性能）。 HLSL 是由微软编写的，他们缺乏这种激励。
@keltar：这正是我的观点。 GLSL 有很多优化的潜力，但是这个责任落在了实施者的肩上。投入到这项任务上的时间和精力在不同的实现中会有很大的不同；在 HLSL 中，因为 Microsoft 编写了执行所有高级优化的字节码生成前端，驱动程序实现之间唯一不同的事情是非常小的。拥有标准 HLSL 字节码意味着您可以反汇编着色器并查看编译器对特定高级代码的理解程度。