0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

【情報求む】FragmentShaderの演算精度でハマった話(Android Chrome93)

Posted at

こんにちは。つんあーです。

あんまり意識していなかったのですが、シェーダを書く時って頭に演算精度を示す精度修飾子を記載しますよね。

frag.glsl
#version 300 es
precision mediump int; <- これ
precision mediump float; <- これ

精度には三段階あります。

  • precision lowp float
  • precision mediump float
  • precision highp float

頂点シェーダでは自動的にhighpが選択されるそうなので、
今回の話はフラグメントシェーダーに限った話になります。

Android Chrome93で起こったこと

highpの場合

frag.glsl
#version 300 es
precision highp int;
precision highp float;

out vec4 color;
...

void main() {
  
  int num = 2000 + 2001;
  // => 4001
  // ↑当然の結果

}

mediumpの場合

frag.glsl
#version 300 es
precision mediump int;
precision mediump float;

out vec4 color;
...

void main() {
  
  int num = 2000 + 2001;
  // => 4000
  // ファッ!?

}

単純な足し算ですが、結果が正しくありません。

もちろん、PC(Mac)のChromeではこういったことは起こりませんでした。

今のところ、原因はよくわかっていません。

じゃあhighpで書けばいいんじゃね?という話

まあそうといえばそうなんですが。
GLSL3.0は一応、highpが標準とされたようです。

なので大方問題はないと思うのですが。。。
とはいえ、GLSL2.0以前の潮流なのか多くのサイトで「highpの実装具合や実行の確実性は環境に左右される」といった記載がされているのと、
これはどこかで聞いたのですがhighpが実装されていない環境の場合は自動的にmediumpが選択されるらしいので、自分の知らないところで不具合が出てるかもと思うとちょっとソワソワしますね。

そもそも、フラグメントシェーダの実行結果を数字でみるのってちょっと面倒なので、もし不具合が起こっていた場合の原因追及もなかなかしんどそう。

あと、ぶっちゃけエンジニア感情論的に気持ち悪いですよね。

この後の動き

もう少し詳しく調べつつ、再現に条件があるのかどうかなどを調べてみようかなと思います。
あととりあえず、Android Chromeの不具合報告にでも送っておこうかな...

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?