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