我对 Open GL着色器语言中sin()和cos()的速度感兴趣。
GLSL Specification Document表示：
内置功能基本上分为三类：
- ...
- ...
- 它们代表一种操作图形硬件可能会在某些时候加速。三角函数属于这个 类别。
修改
正如已经指出的那样，计算sin()和cos()等单个操作的时钟周期并不能真正说明整个性能故事。
因此，为了澄清我的问题，我真正感兴趣的是，是否值得优化sin()和cos()调用常见案例。
例如，在我的应用程序中，参数通常是0。这样的事情是否有意义：
float sina, cosa;
if ( rotation == 0 )
{
sina = 0;
cosa = 1;
}
else
{
sina = sin( rotation );
cosa = cos( rotation );
}
或GLSL编译器或sin()和cos()实现是否会为我进行优化？
答案 0 :(得分：17)
例如，在我的应用程序中，参数为0是很常见的。所以这样的事情是有道理的：
没有
您的编译器将执行以下两种操作之一。
一般来说，使用条件逻辑围绕这样的小型表演跳舞并不是一个好主意。它需要非常大才有价值，比如discard或其他东西。
另外，请注意浮点等效性不太可能。除非你实际上将一个包含0.0的匀称或顶点属性传递给着色器。即使在0和非零之间进行插值，也可能永远不会为任何片段精确地生成0。
答案 1 :(得分：7)
这是一个很好的问题。我也很想知道这一点。
Google'd links自2005年以来，cos和sin在主流卡片上是单周期的。
答案 2 :(得分：5)
你必须自己测试一下，但我很确定着色器中的分支比sin或cos计算要昂贵得多。 GLSL编译器非常适合优化着色器，担心这是过早的优化。如果您后来发现，通过整个程序，着色器是瓶颈，那么您可以担心优化它。
如果您想查看特定平台的着色器汇编代码，我建议您AMD GPU ShaderAnalyzer。
答案 3 :(得分：2)
不确定这是否能解答您的问题，但很难告诉您指令需要多少时钟/插槽，因为它非常依赖于GPU。通常它是一个循环。但即使没有，编译器也可能重新排列指令执行的顺序以隐藏真实的成本。对sin / cos使用纹理查找肯定比执行指令要慢。
答案 4 :(得分：1)
看看你连续使用一个着色器可以获得多少罪，与math.abs，frac等相比......我认为gtx 470每个片段可以处理200个sin函数没有probs，这个框架将比空着色器慢10％。它的速度非常快，你可以发送结果。它将是计算效率的一个很好的指标。
答案 5 :(得分：-2)
编译器评估两个分支，这使得条件非常昂贵。如果在着色器中同时使用sin和cos，则只能计算sin（a）和cos（a）= sqrt（1.0 - sin（a）），因为sin（x）* sin（x）+ cos（x）* cos（x）总是1.0