「プログラマブルシェーダー」の版間の差分

2025年4月8日 (火) 01:03時点における最新版

プログラマブルシェーダー（英語：programmable shader）とは、グラフィックカード上のシェーダーで独自のプログラム（カスタムシェーダー）を実行させられるものをいう。

概要[編集 | ソースを編集]

紀元前[編集 | ソースを編集]

初期のシェーダーは「ハードウェア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枚のテクスチャに見立ててアンチエイリアシング」などといった技法も登場した。

パイプラインの組み立てなどを考える必要性がでてきて、3Dを扱うプログラマーに求められる作業量・記述量はさらに激増した。

備考[編集 | ソースを編集]

プログラマブルシェーダーが進化するほど3Dを扱うプログラマーに求められる作業量・記述量は劇的に増え続けた。プログラミングするのがアホらしくなるほどであった。

その結果、自前実装は面倒くさすぎ、ゲームエンジンが用意するプログラマブルシェーダー（実質固定シェーダー）でいいじゃん。という空気になり、UnityやUnreal Engineなどのゲームエンジンが爆発的に普及した。

つまり今でも99%くらいの開発者にはハードウェアT&Lで十分なのでだったのであった。

デバッグ[編集 | ソースを編集]

HLSL[編集 | ソースを編集]

Visual Studio Graphics Analyzerで行う。

「デバッグ」→「グラフィックス」→「グラフィックスデバッグの開始」
フレームキャプチャを行う
サムネイルの上にあるフレーム番号をクリックする
Visual Studio Graphics Analyzerが起動する

Metal[編集 | ソースを編集]

Xcodeで行う。

普通にデバッグ実行する
中段ツールバー（ステップ実行などがあるところ）のカメラアイコンをクリックする
- 右側デバッグナビゲーターに「GPU」が追加され、メインウインドウが切り替わる
- 中段ツールバーも入れ替わり、ゴキブリアイコンが登場する

中段ツールバーのゴキブリアイコンをクリックする
- バーテックスシェーダか、フラグメントシェーダかを選ぶダイアログが表示される
  - 上部のタブでバーテックスシェーダとフラグメントシェーダを切り替え
  - 中段のメインウインドウでポリゴンやピクセルを選ぶ
  - 下部の「DEBUG」ボタンを押すとステップ実行やウォッチ変数の表示が開始される

GLSL[編集 | ソースを編集]

目視。ひたらす目視。OpenGL系にステップ実行やウォッチ変数など求めてはいけない。

@@ 1行目: / 1行目: @@
 '''プログラマブルシェーダー'''（[[英語]]：programmable shader）とは、[[グラフィックカード]]上の[[シェーダー]]で独自の[[プログラム]]（カスタムシェーダー）を実行させられるものをいう。
-== 概要 ==
+==概要==
-初期の[[シェーダー]]は「[[ハードウェアT&L]]（最近では対義語的に[[固定シェーダー]]と呼ばれることが多い）」などと呼ばれ、いわゆる[[API]]的な感じで「ライティングをする」などの固定機能が[[GPU]]に用意されており、[[プログラマー]]は何も考えずポリゴンモデルやテクスチャや座標などを[[GPU]]に送信すると表示用の一枚ペラの絵が返ってくるというものであった。この方式は簡潔明瞭という利点と、だれが作っても似たように絵になるという欠点があった。
+=== 紀元前 ===
+初期の[[シェーダー]]は「[[ハードウェアT&L]]（最近では対義語的に[[固定シェーダー]]と呼ばれることが多い）」などと呼ばれ、いわゆる[[API]]的な感じで「ライティングをする」などの固定機能が[[GPU]]に用意されていた。これは[[プログラマー]]は何も考えず[[3Dモデル]]とその[[ワールド座標]]などの[[データ]]を[[GPU]]に送信するだけで全自動で表示用の2D画像が返ってくるというものであった。
-これを[[アセンブラ]]のような[[プログラミング言語]]で自前で記述できるようにしたのがプログラマブルシェーダーである。後に[[HLSL]]や[[GLSL]]などの[[高級言語]]などが登場したが、それでも3Dを扱う[[プログラマー]]に求められる作業量・記述量は劇的に増えた。
+この方式はバカでも扱える簡潔明瞭さという利点と、だれが作っても似たように絵になるという欠点があった。
-その結果、よほどの事がないかぎり[[固定シェーダー]]でこと足りるのにそんなアホくさいことに労力を割くのは得策ではないとして[[Unity]]や[[Unreal Engine]]などの[[ゲームエンジン]]が爆発的に普及した。
+===第一世代===
+「だれが作っても似たように絵になる」というのが気に食わない人が現れた。
-== デバッグ ==
+そのような奇人変人のために[[バーテックスシェーダ]]や[[ピクセルシェーダ]]での処理を[[アセンブラ]]のような[[プログラミング言語]]で自前で記述できるようにした「第一世代のプログラマブルシェーダー」が登場した。
-ステップ実行やウォッチ変数などを搭載した「まとも」な[[デバッガ]]があるのは[[HLSL]]だけである。[[Visual Studio]] (communityエディションにもある）に搭載されている「Visual Studio Graphics Analyzer」しか存在しない。これは[[CPU]]上で[[GPU]]を[[エミュレーション]]し、その上で「最初の1[[スレッド]]目だけ再現」しているらしい。
-[[Xcode]]と[[Metal]]ではパイプラインの実行順序くらいしか確認できないので[[デバッガ]]はないに等しい。[[GLSL]]は[[WebGL]]を使った「見た目で[[デバッグ]]」という[[ウェブサービス]]があるが計算ミスまでは特定できない。GPUだと「print文でログや変数表示」などという原始的なデバッグすらできないので「まとも」な[[デバッガ]]の存在は非常に重要なのである。
+年11月に発表されたDirectX 8の「DirectXアセンブリ言語」や2002年に発表されたOpenGLの「ARB」などが該当する。
-プログラマブルシェーダーを使うのであれば、環境を問わず、まずはHLSLで書いて、そこから移植するというのが正しい手順であると言える。OpenGLの中の人達が作ったValkanではGLSLに加えHLSLも採用された。宗教上の理由だけでは超えられない壁があるということである。
+===第二世代===
+第一世代はあまりに難易度が高かった。
+そこに颯爽と登場したのが第二世代の「[[Cg言語]]」であった。
+[[C言語]]風に記述できるスグレモノであった。
+ただ「[[Cg言語]]は[[NVIDIA]]製」ということもあり、競合他社は宗教上の理由で使えないという問題が発生した。そこで[[マイクロソフト]]が[[HLSL]]、[[クロノスグループ]]が[[GLSL]]という似品をすぐさま開発した。
+こいつらの登場により大したことない描画にすら「自前のプログラマブルシェーダーを用意するのは当たり前」というクソみたいな風潮が蔓延し、3Dを扱う[[プログラマー]]に求められる作業量・記述量は劇的に増えた。
+=== 第三世代 ===
+そして次に登場したのが「[[統合シェーダー]]」と呼ばれる第三世代のプログラマブルシェーダーである。
+これは[[バーテックスシェーダ]]や[[ピクセルシェーダー]]の概念をなくし、「ひとつの汎用的なシェーダー」でバーテックスシェーダとピクセルシェーダでやってた処理を実行すればいいじゃんという代物である。
+しかも従来の定型的な2つの処理だけでなく、「パイプライン」というものに何個の処理でも詰め込めるように改良された。「１回の処理でピクセルシェーダーを２回呼ぶ」なんてこともできるようになり、「1回目のピクセルシェーダーで普通に描画して、2回目のピクセルシェーダーで画面全体を1枚のテクスチャに見立てて[[アンチエイリアシング]]」などといった技法も登場した。
+パイプラインの組み立てなどを考える必要性がでてきて、3Dを扱う[[プログラマー]]に求められる作業量・記述量はさらに激増した。
+===備考===
+プログラマブルシェーダーが進化するほど3Dを扱う[[プログラマー]]に求められる作業量・記述量は劇的に増え続けた。[[プログラミング]]するのがアホらしくなるほどであった。
+その結果、自前実装は面倒くさすぎ、[[ゲームエンジン]]が用意するプログラマブルシェーダー（実質固定シェーダー）でいいじゃん。という空気になり、[[Unity]]や[[Unreal Engine]]などの[[ゲームエンジン]]が爆発的に普及した。
+つまり今でも99%くらいの開発者には[[ハードウェアT&L]]で十分なのでだったのであった。
+==デバッグ==
+===HLSL===
+Visual Studio Graphics Analyzerで行う。
+*「デバッグ」→「グラフィックス」→「グラフィックス デバッグの開始」
+*フレームキャプチャを行う
+*サムネイルの上にあるフレーム番号をクリックする
+*Visual Studio Graphics Analyzerが起動する
+===Metal===
+Xcodeで行う。
+*普通にデバッグ実行する
+*中段ツールバー（ステップ実行などがあるところ）のカメラアイコンをクリックする
+**[[ファイル:Xcode-metal-shader-debug-1.png|境界|520x520ピクセル]]
+**右側デバッグナビゲーターに「GPU」が追加され、メインウインドウが切り替わる
+**中段ツールバーも入れ替わり、ゴキブリアイコンが登場する
+*中段ツールバーのゴキブリアイコンをクリックする
+**[[ファイル:Xcode-metal-shader-debug-2.png|520x520ピクセル]]
+**バーテックスシェーダか、フラグメントシェーダかを選ぶダイアログが表示される
+***上部のタブでバーテックスシェーダとフラグメントシェーダを切り替え
+***中段のメインウインドウでポリゴンやピクセルを選ぶ
+***下部の「DEBUG」ボタンを押すとステップ実行やウォッチ変数の表示が開始される
+===GLSL===
+目視。ひたらす目視。OpenGL系にステップ実行やウォッチ変数など求めてはいけない。
 ==関連項目==
 *[[CUDA]] = 最先端、[[NVIDIA]]製品でしか動かない
 *[[HLSL]] = [[CUDA]]から実験的な機能を排除したもの。唯一まともなデバッガがある。
 *[[GLSL]] = [[OpenGL]]や[[Valkan]]などで使われている。
 *[[Metal]] = [[Apple]]製品は[[OpenGL]]が禁止されこれ一本になった
+[[category: GPU]]
+[[category: 3DCG]]
+[[category: プログラマブルシェーダー]]