GLSL pow関数は不安定な関数なのでしょうか

Question

// valueを5回累乗する
pow(value, 5.0);

フラグメントシェーダー(ピクセルカラーを司る様分割したシェーダーファイル)にて光の加減などを調整するためにpow関数を使用して累乗しているコードがありました。
それと同時になぜかフラグメントシェーダー部位における描画パフォーマンスが著しく不安定となる症状に悩まされてました。

フラグメントシェーダー部位にて軽量化のためコードを見直し、pow関数を使用せず必要な回数分だけ乗算していくスタイルへと書き換えました。

すると描画が著しく安定しました。

GLSLっというよりOpenGLという規格から見てどの関数においても各々のGPUにて処理が最適かされるという先入観を持っていたのですが、どうやらそういうわけでもないのかもしれません。

---

長い前置きでしたが質問です。

GLSLにおいてpow関数は不安定化しやすい関数という認識は正しいでしょうか？それともたまたま私のGPUがpow関数の最適化を行えていないのでしょうか？

このパフォーマンスの改善についての根拠が知りたいので、もしわかる方がいましたら教えてください。

---

※ちなみに描画が安定しないというのはFPS値が著しく上がったり下がったりを繰り返すという意味です。

Answer 1

確かにpowは比較的高負荷でしょうね。GLSLではなくてすみませんが、Unity - Manual: Optimizing graphics performanceではパフォーマンス改善のアドバイスとして「超越関数はできるだけ使うのを控え、場合によってはテクスチャの参照による方法も検討する（必要な範囲の冪乗を事前計算してテクスチャ化しておき、シェーダーからはそれをサンプリングすることで近似値を得るテクニックを指すものと思われます）」といったものがありました。

opengl - GLSL: pow vs multiplication for integer exponent - Stack Overflowでも類似した疑問をお持ちの方がいらっしゃったようですが、回答として両方試してみるのがいいとのお返事がありました。
powを最適化してくれるかどうかはコンパイラによって変わってくるのかもしれませんが、冪乗部分を書き換えるだけで顕著な差が出たということは、少なくともご質問者さんの環境では整数のpowを乗算に置き換えるような最適化は行われていないように思います。今回の比較結果を拝見する限りでは、ここは乗算に展開したほうがよさそうですね。
ですが念のため、pow版のコードを完全に捨ててしまうのではなく、powと乗算を必要に応じてすばやく切り替えられるよう作っておくのも一案かと思います。