ように条件代入に置き換えることでエラーを回避出来ました。時にあふれていた可能性があります。生成結果が意図したものになっておらずまだ問題があります。正常に見えるものの、壁が途切れている部分があります。まともですが処理能力が足りていません。パフォーマンスに影響が生じました。書き換えることで著しく速度が落ちました。方が高速になっています。ここまで顕著ではありませんが影響が出ているようです。比較的書いたとおりにそのままコンパイルされているのではないかと考えられます。その様子は動的分岐の結果からもわかります。値で「25.7~16.3」と範囲が書かれているものがあります。落ちていることを意味しています。考えられる要因としてシェーダーの動的分岐があります。迷路生成初期はほとんど全部床面の状態なので、レンダリング時は同一ブロック(WARP)内のピクセルが同じ方向に分岐していると考えられます。この場合他の分岐状態を実行する必要がありません。終盤になって複雑になると、ブロック内の各ピクセルの状態がばらばらになるのでシェーダーは可能性のあるすべての分岐コードを実行していると考えられます。値が変化しているので、分岐の複雑さが速度に影響を与えていると考えられます。変化が大きくなっています。変化が大幅に少なくなることもわかります。ここからも、記述通りに代入命令に置き換わっているのではないかと考えられます。コードは最初は遅いものの、分岐判定のコストが無いためか、複雑な終盤は落ち込みが少なく速度を維持しています。速度が一定しておりほとんど変化がありませんでした。すべての分岐を通過しているか、またはコンパイラが分岐命令を置き換えているのではないかと思います。方が速いので、命令置換ではなくそのまま分岐命令の分コストが発生していると考えられます。なければ動かないので変化が生じていません。理由はわかりませんが、条件が複雑になる終盤の方が速度が上がっており特徴的な結果となっています。よるアクセスができません。