プログラマブルシェーダー
概要
紀元前
初期のシェーダーは「ハードウェアT&L(最近では対義語的に固定シェーダーと呼ばれることが多い)」などと呼ばれ、いわゆるAPI的な感じで「ライティングをする」などの固定機能がGPUに用意されていた。これはプログラマーは何も考えず3Dモデルとそのワールド座標などのデータをGPUに送信するだけで全自動で表示用の2D画像が返ってくるというものであった。
この方式はバカでも扱える簡潔明瞭さという利点と、だれが作っても似たように絵になるという欠点があった。
第一世代
「だれが作っても似たように絵になる」というのが気に食わない人が現れた。
そのような奇人変人のためにバーテックスシェーダやピクセルシェーダでの処理をアセンブラのようなプログラミング言語で自前で記述できるようにした「第一世代のプログラマブルシェーダー」が登場した。
2000年11月に発表されたDirectX 8の「DirectXアセンブリ言語」や2002年に発表されたOpenGLの「ARB」などが該当する。
第二世代
第一世代はあまりに難易度が高かった。 そこに颯爽と登場したのが第二世代の「Cg言語」であった。 C言語風に記述できるスグレモノであった。
ただ「Cg言語はNVIDIA製」ということもあり、競合他社は宗教上の理由で使えないという問題が発生した。そこでマイクロソフトがHLSL、クロノスグループがGLSLという似品をすぐさま開発した。
こいつらの登場により大したことない描画にすら「自前のプログラマブルシェーダーを用意するのは当たり前」というクソみたいな風潮が蔓延し、3Dを扱うプログラマーに求められる作業量・記述量は劇的に増えた。
第三世代
そして次に登場したのが「統合シェーダー」と呼ばれる第三世代のプログラマブルシェーダーである。 これはバーテックスシェーダやピクセルシェーダーの概念をなくし、「ひとつの汎用的なシェーダー」でバーテックスシェーダとピクセルシェーダでやってた処理を実行すればいいじゃんという代物である。
しかも従来の定型的な2つの処理だけでなく、「パイプライン」というものに何個の処理でも詰め込めるように改良された。「1回の処理でピクセルシェーダーを2回呼ぶ」なんてこともできるようになり、「1回目のピクセルシェーダーで普通に描画して、2回目のピクセルシェーダーで画面全体を1枚のテクスチャに見立ててアンチエイリアシング」などといった技法も登場した。
パイプラインの組み立てなどを考える必要性がでてきて、3Dを扱うプログラマーに求められる作業量・記述量はさらに激増した。
備考
プログラマブルシェーダーが進化するほど3Dを扱うプログラマーに求められる作業量・記述量は劇的に増え続けた。プログラミングするのがアホらしくなるほどであった。
その結果、自前実装は面倒くさすぎ、ゲームエンジンが用意するプログラマブルシェーダー(実質固定シェーダー)でいいじゃん。という空気になり、UnityやUnreal Engineなどのゲームエンジンが爆発的に普及した。
つまり今でも99%くらいの開発者にはハードウェアT&Lで十分なのでだったのであった。
デバッグ
HLSL
Visual Studio Graphics Analyzerで行う。
- 「デバッグ」→「グラフィックス」→「グラフィックス デバッグの開始」
- フレームキャプチャを行う
- サムネイルの上にあるフレーム番号をクリックする
- Visual Studio Graphics Analyzerが起動する
Metal
Xcodeで行う。
- 普通にデバッグ実行する
- 中段ツールバー(ステップ実行などがあるところ)のカメラアイコンをクリックする
- 中段ツールバーのゴキブリアイコンをクリックする
GLSL
目視。ひたらす目視。OpenGL系にステップ実行やウォッチ変数など求めてはいけない。