「プログラマブルシェーダー」の版間の差分
imported>Administrator (→GLSL) |
imported>Administrator (→概要) |
||
| 2行目: | 2行目: | ||
==概要== | ==概要== | ||
| − | 初期の[[シェーダー]]は「[[ハードウェアT&L]]（最近では対義語的に[[固定シェーダー]]と呼ばれることが多い）」などと呼ばれ、いわゆる[[API]]的な感じで「ライティングをする」などの固定機能が[[GPU]] | + | 初期の[[シェーダー]]は「[[ハードウェアT&L]]（最近では対義語的に[[固定シェーダー]]と呼ばれることが多い）」などと呼ばれ、いわゆる[[API]]的な感じで「ライティングをする」などの固定機能が[[GPU]]に用意されていた。これは[[プログラマー]]は何も考えずポリゴンモデルやテクスチャや座標など3Dデータを[[GPU]]に送信すると表示用の2D画像が返ってくるというものであった。 |
| − | + | この方式は簡潔明瞭という利点と、だれが作っても似たように絵になるという欠点があった。 | |
| − | その結果、よほどの事がないかぎり[[固定シェーダー]] | + | === 第一世代 === |
| + | 「だれが作っても似たように絵になる」というのが気に食わない人が現れた。 | ||
| + | |||
| + | そういう奇人のために[[バーテックスシェーダ]]や[[ピクセルシェーダ]]での処理を[[アセンブラ]]のような[[プログラミング言語]]で自前で記述できるようにしたのが第一世代のプログラマブルシェーダーである。 | ||
| + | |||
| + | 後に[[HLSL]]や[[GLSL]]などの[[高級言語]]などが登場したが、それでも3Dを扱う[[プログラマー]]に求められる作業量・記述量は劇的に増えた。 | ||
| + | |||
| + | === 第二世代 === | ||
| + | そして次に登場したのが「[[統合シェーダー]]」と呼ばれる第二世代のプログラマブルシェーダーである。これはバーテックスシェーダやピクセルシェーダーの概念をなくし、「ひとつの汎用的なシェーダー」でバーテックスシェーダとピクセルシェーダでやってた処理を実行すればいいじゃんという代物である。しかもこの定型的な2つの処理だけでなく、「パイプライン」というものに何個の処理でも詰め込めるように改良された。 | ||
| + | |||
| + | これにより「1回目のピクセルシェーダーで普通に描画して、2回目のピクセルシェーダーで画面全体を1枚のテクスチャに見立てて[[アンチエイリアシング]]」などといった技法も登場した。 | ||
| + | |||
| + | パイプラインの組み立てなどを考える必要性がでてきて、3Dを扱う[[プログラマー]]に求められる作業量・記述量は劇的に増えた。 | ||
| + | |||
| + | === 備考 === | ||
| + | プログラマブルシェーダーが進化するほど3Dを扱う[[プログラマー]]に求められる作業量・記述量は劇的に増え続けた。[[プログラミング]]するのがアホらしくなるほどであった。 | ||
| + | |||
| + | その結果、よほどの事がないかぎり[[固定シェーダー]]でこと足りるのにそんなアホくさいことに労力を割くのは得策ではないとして、実質固定シェーダーみたいな標準シェーダーが充実している[[Unity]]や[[Unreal Engine]]などの[[ゲームエンジン]]が爆発的に普及した。 | ||
==デバッグ== | ==デバッグ== | ||
| 19行目: | 36行目: | ||
===Metal=== | ===Metal=== | ||
| − | + | Xcodeで行う。 | |
*普通にデバッグ実行する | *普通にデバッグ実行する | ||
| 36行目: | 53行目: | ||
===GLSL=== | ===GLSL=== | ||
目視。ひたらす目視。OpenGL系にステップ実行やウォッチ変数など求めてはいけない。 | 目視。ひたらす目視。OpenGL系にステップ実行やウォッチ変数など求めてはいけない。 | ||
| − | |||
| − | |||
==関連項目== | ==関連項目== | ||
2019年8月14日 (水) 05:20時点における版
プログラマブルシェーダー（英語：programmable shader）とは、グラフィックカード上のシェーダーで独自のプログラム（カスタムシェーダー）を実行させられるものをいう。
概要
初期のシェーダーは「ハードウェアT&L（最近では対義語的に固定シェーダーと呼ばれることが多い）」などと呼ばれ、いわゆるAPI的な感じで「ライティングをする」などの固定機能がGPUに用意されていた。これはプログラマーは何も考えずポリゴンモデルやテクスチャや座標など3DデータをGPUに送信すると表示用の2D画像が返ってくるというものであった。
この方式は簡潔明瞭という利点と、だれが作っても似たように絵になるという欠点があった。
第一世代
「だれが作っても似たように絵になる」というのが気に食わない人が現れた。
そういう奇人のためにバーテックスシェーダやピクセルシェーダでの処理をアセンブラのようなプログラミング言語で自前で記述できるようにしたのが第一世代のプログラマブルシェーダーである。
後にHLSLやGLSLなどの高級言語などが登場したが、それでも3Dを扱うプログラマーに求められる作業量・記述量は劇的に増えた。
第二世代
そして次に登場したのが「統合シェーダー」と呼ばれる第二世代のプログラマブルシェーダーである。これはバーテックスシェーダやピクセルシェーダーの概念をなくし、「ひとつの汎用的なシェーダー」でバーテックスシェーダとピクセルシェーダでやってた処理を実行すればいいじゃんという代物である。しかもこの定型的な2つの処理だけでなく、「パイプライン」というものに何個の処理でも詰め込めるように改良された。
これにより「1回目のピクセルシェーダーで普通に描画して、2回目のピクセルシェーダーで画面全体を1枚のテクスチャに見立ててアンチエイリアシング」などといった技法も登場した。
パイプラインの組み立てなどを考える必要性がでてきて、3Dを扱うプログラマーに求められる作業量・記述量は劇的に増えた。
備考
プログラマブルシェーダーが進化するほど3Dを扱うプログラマーに求められる作業量・記述量は劇的に増え続けた。プログラミングするのがアホらしくなるほどであった。
その結果、よほどの事がないかぎり固定シェーダーでこと足りるのにそんなアホくさいことに労力を割くのは得策ではないとして、実質固定シェーダーみたいな標準シェーダーが充実しているUnityやUnreal Engineなどのゲームエンジンが爆発的に普及した。
デバッグ
HLSL
Visual Studio Graphics Analyzerで行う。
- 「デバッグ」→「グラフィックス」→「グラフィックス デバッグの開始」
- フレームキャプチャを行う
- サムネイルの上にあるフレーム番号をクリックする
- Visual Studio Graphics Analyzerが起動する
Metal
Xcodeで行う。
- 普通にデバッグ実行する
- 中段ツールバー（ステップ実行などがあるところ）のカメラアイコンをクリックする
- 右側デバッグナビゲーターに「GPU」が追加され、メインウインドウが切り替わる
- 中段ツールバーも入れ替わり、ゴキブリアイコンが登場する
- 中段ツールバーのゴキブリアイコンをクリックする
- バーテックスシェーダか、フラグメントシェーダかを選ぶダイアログが表示される
- 上部のタブでバーテックスシェーダとフラグメントシェーダを切り替え
- 中段のメインウインドウでポリゴンやピクセルを選ぶ
- 下部の「DEBUG」ボタンを押すとステップ実行やウォッチ変数の表示が開始される
GLSL
目視。ひたらす目視。OpenGL系にステップ実行やウォッチ変数など求めてはいけない。
