プログラマブルシェーダー - 版の履歴

2025年4月8日 (火) 01:03にAdministratorによる

2025-04-08T01:03:58Z

← 古い版		2025年4月8日 (火) 01:03時点における版
75行目:		75行目:
	[[category: GPU]]		[[category: GPU]]
	[[category: 3DCG]]		[[category: 3DCG]]
			[[category: プログラマブルシェーダー]]

Administrator: /* 関連項目 */

2025-03-04T10:39:13Z

2023年10月26日 (木) 07:05にAdministratorによる

2023-10-26T07:05:24Z

← 古い版		2023年10月26日 (木) 07:05時点における版
68行目:		68行目:

	==関連項目==		==関連項目==

	*[[CUDA]] = 最先端、[[NVIDIA]]製品でしか動かない		*[[CUDA]] = 最先端、[[NVIDIA]]製品でしか動かない
	*[[HLSL]] = [[CUDA]]から実験的な機能を排除したもの。唯一まともなデバッガがある。		*[[HLSL]] = [[CUDA]]から実験的な機能を排除したもの。唯一まともなデバッガがある。
	*[[GLSL]] = [[OpenGL]]や[[Valkan]]などで使われている。		*[[GLSL]] = [[OpenGL]]や[[Valkan]]などで使われている。
	*[[Metal]] = [[Apple]]製品は[[OpenGL]]が禁止されこれ一本になった		*[[Metal]] = [[Apple]]製品は[[OpenGL]]が禁止されこれ一本になった

			[[category: GPU]]

153.220.48.50: /* 第三世代 */

2020-11-18T01:54:28Z

第三世代

← 古い版		2020年11月18日 (水) 01:54時点における版
24行目:		24行目:

	=== 第三世代 ===		=== 第三世代 ===
	そして次に登場したのが「[[統合シェーダー]]~~」と呼ばれる第二世代のプログラマブルシェーダーである。これは~~[[バーテックスシェーダ]]や[[ピクセルシェーダー]]の概念をなくし、「ひとつの汎用的なシェーダー」でバーテックスシェーダとピクセルシェーダでやってた処理を実行すればいいじゃんという代物である。しかもこの定型的な2つの処理だけでなく、「パイプライン」というものに何個の処理でも詰め込めるように改良された。		そして次に登場したのが「[[統合シェーダー]]」と呼ばれる第三世代のプログラマブルシェーダーである。
			これは[[バーテックスシェーダ]]や[[ピクセルシェーダー]]の概念をなくし、「ひとつの汎用的なシェーダー」でバーテックスシェーダとピクセルシェーダでやってた処理を実行すればいいじゃんという代物である。

	~~これにより「1回目のピクセルシェーダーで普通に描画して、2回目のピクセルシェーダーで画面全体を1枚のテクスチャに見立てて~~[[アンチエイリアシング]]」などといった技法も登場した。		しかも従来の定型的な2つの処理だけでなく、「パイプライン」というものに何個の処理でも詰め込めるように改良された。「１回の処理でピクセルシェーダーを２回呼ぶ」なんてこともできるようになり、「1回目のピクセルシェーダーで普通に描画して、2回目のピクセルシェーダーで画面全体を1枚のテクスチャに見立てて[[アンチエイリアシング]]」などといった技法も登場した。

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

153.220.48.50: /* 概要 */

2020-11-18T01:50:26Z

概要

← 古い版		2020年11月18日 (水) 01:50時点における版
2行目:		2行目:

	==概要==		==概要==
	初期の[[シェーダー]]は「[[ハードウェアT&L]]（最近では対義語的に[[固定シェーダー]]と呼ばれることが多い）」などと呼ばれ、いわゆる[[API]]的な感じで「ライティングをする」などの固定機能が[[GPU]]に用意されていた。これは[[プログラマー]]~~は何も考えずポリゴンモデルやテクスチャや座標など3Dデータを~~[[GPU]]~~に送信すると表示用の2D画像が返ってくるというものであった。~~		=== 紀元前 ===
			初期の[[シェーダー]]は「[[ハードウェアT&L]]（最近では対義語的に[[固定シェーダー]]と呼ばれることが多い）」などと呼ばれ、いわゆる[[API]]的な感じで「ライティングをする」などの固定機能が[[GPU]]に用意されていた。これは[[プログラマー]]は何も考えず[[3Dモデル]]とその[[ワールド座標]]などの[[データ]]を[[GPU]]に送信するだけで全自動で表示用の2D画像が返ってくるというものであった。

	~~この方式は簡潔明瞭という利点と、だれが作っても似たように絵になるという欠点があった。~~		この方式はバカでも扱える簡潔明瞭さという利点と、だれが作っても似たように絵になるという欠点があった。

	===第一世代===		===第一世代===
	「だれが作っても似たように絵になる」というのが気に食わない人が現れた。		「だれが作っても似たように絵になる」というのが気に食わない人が現れた。

	~~そういう奇人のために~~[[バーテックスシェーダ]]や[[ピクセルシェーダ]]での処理を[[アセンブラ]]のような[[プログラミング言語]]~~で自前で記述できるようにしたのが第一世代のプログラマブルシェーダーである。~~		そのような奇人変人のために[[バーテックスシェーダ]]や[[ピクセルシェーダ]]での処理を[[アセンブラ]]のような[[プログラミング言語]]で自前で記述できるようにした「第一世代のプログラマブルシェーダー」が登場した。

	~~後に[[HLSL]]や[[GLSL]]などの[[高級言語]]などが登場したが、それでも3Dを扱う[[プログラマー]]に求められる作業量・記述量は劇的に増えた。~~		2000年11月に発表されたDirectX 8の「DirectXアセンブリ言語」や2002年に発表されたOpenGLの「ARB」などが該当する。

	===第二世代===		===第二世代===
	そして次に登場したのが「[[統合シェーダー]]」と呼ばれる第二世代のプログラマブルシェーダーである。これはバーテックスシェーダやピクセルシェーダーの概念をなくし、「ひとつの汎用的なシェーダー」でバーテックスシェーダとピクセルシェーダでやってた処理を実行すればいいじゃんという代物である。しかもこの定型的な2つの処理だけでなく、「パイプライン」というものに何個の処理でも詰め込めるように改良された。		第一世代はあまりに難易度が高かった。
			そこに颯爽と登場したのが第二世代の「[[Cg言語]]」であった。
			[[C言語]]風に記述できるスグレモノであった。

			ただ「[[Cg言語]]は[[NVIDIA]]製」ということもあり、競合他社は宗教上の理由で使えないという問題が発生した。そこで[[マイクロソフト]]が[[HLSL]]、[[クロノスグループ]]が[[GLSL]]という似品をすぐさま開発した。

			こいつらの登場により大したことない描画にすら「自前のプログラマブルシェーダーを用意するのは当たり前」というクソみたいな風潮が蔓延し、3Dを扱う[[プログラマー]]に求められる作業量・記述量は劇的に増えた。

			=== 第三世代 ===
			そして次に登場したのが「[[統合シェーダー]]」と呼ばれる第二世代のプログラマブルシェーダーである。これは[[バーテックスシェーダ]]や[[ピクセルシェーダー]]の概念をなくし、「ひとつの汎用的なシェーダー」でバーテックスシェーダとピクセルシェーダでやってた処理を実行すればいいじゃんという代物である。しかもこの定型的な2つの処理だけでなく、「パイプライン」というものに何個の処理でも詰め込めるように改良された。

	これにより「1回目のピクセルシェーダーで普通に描画して、2回目のピクセルシェーダーで画面全体を1枚のテクスチャに見立てて[[アンチエイリアシング]]」などといった技法も登場した。		これにより「1回目のピクセルシェーダーで普通に描画して、2回目のピクセルシェーダーで画面全体を1枚のテクスチャに見立てて[[アンチエイリアシング]]」などといった技法も登場した。

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

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

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

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

	==デバッグ==		==デバッグ==

imported>Administrator: /* 備考 */

2019-08-14T05:28:25Z

備考

← 古い版		2019年8月14日 (水) 05:28時点における版
6行目:		6行目:
	この方式は簡潔明瞭という利点と、だれが作っても似たように絵になるという欠点があった。		この方式は簡潔明瞭という利点と、だれが作っても似たように絵になるという欠点があった。

	=== 第一世代 ===		===第一世代===
	「だれが作っても似たように絵になる」というのが気に食わない人が現れた。		「だれが作っても似たように絵になる」というのが気に食わない人が現れた。

13行目:		13行目:
	後に[[HLSL]]や[[GLSL]]などの[[高級言語]]などが登場したが、それでも3Dを扱う[[プログラマー]]に求められる作業量・記述量は劇的に増えた。		後に[[HLSL]]や[[GLSL]]などの[[高級言語]]などが登場したが、それでも3Dを扱う[[プログラマー]]に求められる作業量・記述量は劇的に増えた。

	=== 第二世代 ===		===第二世代===
	そして次に登場したのが「[[統合シェーダー]]」と呼ばれる第二世代のプログラマブルシェーダーである。これはバーテックスシェーダやピクセルシェーダーの概念をなくし、「ひとつの汎用的なシェーダー」でバーテックスシェーダとピクセルシェーダでやってた処理を実行すればいいじゃんという代物である。しかもこの定型的な2つの処理だけでなく、「パイプライン」というものに何個の処理でも詰め込めるように改良された。		そして次に登場したのが「[[統合シェーダー]]」と呼ばれる第二世代のプログラマブルシェーダーである。これはバーテックスシェーダやピクセルシェーダーの概念をなくし、「ひとつの汎用的なシェーダー」でバーテックスシェーダとピクセルシェーダでやってた処理を実行すればいいじゃんという代物である。しかもこの定型的な2つの処理だけでなく、「パイプライン」というものに何個の処理でも詰め込めるように改良された。

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

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

	~~その結果、よほどの事がないかぎり~~[[~~固定シェーダー~~]]~~でこと足りるのにそんなアホくさいことに労力を割くのは得策ではないとして、実質固定シェーダーみたいな標準シェーダーが充実している~~[[Unity]]や[[Unreal Engine]]などの[[ゲームエンジン]]が爆発的に普及した。		その結果、自前実装は面倒くさすぎ。[[ゲームエンジン]]が用意するプログラマブルシェーダー（実質固定シェーダー）でいいじゃん。という空気になり、[[Unity]]や[[Unreal Engine]]などの[[ゲームエンジン]]が爆発的に普及した。

			つまり今でも95%くらいの用途は[[ハードウェアT&L]]で十分なのでだったのであった。

	==デバッグ==		==デバッグ==

imported>Administrator: /* 概要 */

2019-08-14T05:20:38Z

概要

← 古い版		2019年8月14日 (水) 05:20時点における版
2行目:		2行目:

	==概要==		==概要==
	初期の[[シェーダー]]は「[[ハードウェアT&L]]（最近では対義語的に[[固定シェーダー]]と呼ばれることが多い）」などと呼ばれ、いわゆる[[API]]的な感じで「ライティングをする」などの固定機能が[[GPU]]~~に用意されており、~~[[プログラマー]]~~は何も考えずポリゴンモデルやテクスチャや座標などを~~[[GPU]]に送信すると表示用の一枚ペラの絵が返ってくるというものであった。この方式は簡潔明瞭という利点と、だれが作っても似たように絵になるという欠点があった。		初期の[[シェーダー]]は「[[ハードウェアT&L]]（最近では対義語的に[[固定シェーダー]]と呼ばれることが多い）」などと呼ばれ、いわゆる[[API]]的な感じで「ライティングをする」などの固定機能が[[GPU]]に用意されていた。これは[[プログラマー]]は何も考えずポリゴンモデルやテクスチャや座標など3Dデータを[[GPU]]に送信すると表示用の2D画像が返ってくるというものであった。

	これを[[アセンブラ]]のような[[プログラミング言語]]で自前で記述できるようにしたのがプログラマブルシェーダーである。後に[[HLSL]]や[[GLSL]]などの[[高級言語]]などが登場したが、それでも3Dを扱う[[プログラマー]]に求められる作業量・記述量は劇的に増えた。		この方式は簡潔明瞭という利点と、だれが作っても似たように絵になるという欠点があった。

	その結果、よほどの事がないかぎり[[固定シェーダー]]~~でこと足りるのにそんなアホくさいことに労力を割くのは得策ではないとして~~[[Unity]]や[[Unreal Engine]]などの[[ゲームエンジン]]が爆発的に普及した。		=== 第一世代 ===
			「だれが作っても似たように絵になる」というのが気に食わない人が現れた。

			そういう奇人のために[[バーテックスシェーダ]]や[[ピクセルシェーダ]]での処理を[[アセンブラ]]のような[[プログラミング言語]]で自前で記述できるようにしたのが第一世代のプログラマブルシェーダーである。

			後に[[HLSL]]や[[GLSL]]などの[[高級言語]]などが登場したが、それでも3Dを扱う[[プログラマー]]に求められる作業量・記述量は劇的に増えた。

			=== 第二世代 ===
			そして次に登場したのが「[[統合シェーダー]]」と呼ばれる第二世代のプログラマブルシェーダーである。これはバーテックスシェーダやピクセルシェーダーの概念をなくし、「ひとつの汎用的なシェーダー」でバーテックスシェーダとピクセルシェーダでやってた処理を実行すればいいじゃんという代物である。しかもこの定型的な2つの処理だけでなく、「パイプライン」というものに何個の処理でも詰め込めるように改良された。

			これにより「1回目のピクセルシェーダーで普通に描画して、2回目のピクセルシェーダーで画面全体を1枚のテクスチャに見立てて[[アンチエイリアシング]]」などといった技法も登場した。

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

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

			その結果、よほどの事がないかぎり[[固定シェーダー]]でこと足りるのにそんなアホくさいことに労力を割くのは得策ではないとして、実質固定シェーダーみたいな標準シェーダーが充実している[[Unity]]や[[Unreal Engine]]などの[[ゲームエンジン]]が爆発的に普及した。

	==デバッグ==		==デバッグ==
19行目:		36行目:

	===Metal===		===Metal===
	~~MetalのデバッグはXcodeで行うことになる。~~		Xcodeで行う。

	*普通にデバッグ実行する		*普通にデバッグ実行する
36行目:		53行目:
	===GLSL===		===GLSL===
	目視。ひたらす目視。OpenGL系にステップ実行やウォッチ変数など求めてはいけない。		目視。ひたらす目視。OpenGL系にステップ実行やウォッチ変数など求めてはいけない。

	~~ValkanはGLSLとHLSLに両対応しているので、宗教上の理由はグッとこらえてHLSLで書いたほうがいいと思うよ。~~

	==関連項目==		==関連項目==

imported>Administrator: /* GLSL */

2019-08-14T05:01:36Z

GLSL

← 古い版		2019年8月14日 (水) 05:01時点における版
19行目:		19行目:

	===Metal===		===Metal===
	~~Xcodeで行う。~~		MetalのデバッグはXcodeで行うことになる。

	*普通にデバッグ実行する		*普通にデバッグ実行する
36行目:		36行目:
	===GLSL===		===GLSL===
	目視。ひたらす目視。OpenGL系にステップ実行やウォッチ変数など求めてはいけない。		目視。ひたらす目視。OpenGL系にステップ実行やウォッチ変数など求めてはいけない。

			ValkanはGLSLとHLSLに両対応しているので、宗教上の理由はグッとこらえてHLSLで書いたほうがいいと思うよ。

	==関連項目==		==関連項目==

imported>Administrator: /* Metal */

2019-08-14T04:58:38Z

Metal

← 古い版		2019年8月14日 (水) 04:58時点における版
8行目:		8行目:
	その結果、よほどの事がないかぎり[[固定シェーダー]]でこと足りるのにそんなアホくさいことに労力を割くのは得策ではないとして[[Unity]]や[[Unreal Engine]]などの[[ゲームエンジン]]が爆発的に普及した。		その結果、よほどの事がないかぎり[[固定シェーダー]]でこと足りるのにそんなアホくさいことに労力を割くのは得策ではないとして[[Unity]]や[[Unreal Engine]]などの[[ゲームエンジン]]が爆発的に普及した。

	== デバッグ ==		==デバッグ==

	=== HLSL ===		===HLSL===
	Visual Studio Graphics Analyzerで行う。		Visual Studio Graphics Analyzerで行う。

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

	=== Metal ===		===Metal===
	Xcodeで行う。		Xcodeで行う。

	* 普通にデバッグ実行する		*普通にデバッグ実行する
	* 中段ツールバー（ステップ実行などがあるところ）のカメラアイコンをクリックする		*中段ツールバー（ステップ実行などがあるところ）のカメラアイコンをクリックする
	** ~~右側デバッグナビゲーターに「GPU」が追加され、メインウインドウが切り替わる~~		**[[ファイル:Xcode-metal-shader-debug-1.png\|境界\|520x520ピクセル]]
	** ~~中段ツールバーも入れ替わり、ゴキブリアイコンが登場する~~		**右側デバッグナビゲーターに「GPU」が追加され、メインウインドウが切り替わる
	* ~~中段ツールバーのゴキブリアイコンをクリックする~~		**中段ツールバーも入れ替わり、ゴキブリアイコンが登場する
	** バーテックスシェーダか、フラグメントシェーダかを選ぶダイアログが表示される
	*** 上部のタブでバーテックスシェーダとフラグメントシェーダを切り替え
	*** 中段のメインウインドウでポリゴンやピクセルを選ぶ
	*** 下部の「DEBUG」ボタンを押すとステップ実行やウォッチ変数の表示が開始される

	=== GLSL ===		*中段ツールバーのゴキブリアイコンをクリックする
			**[[ファイル:Xcode-metal-shader-debug-2.png\|520x520ピクセル]]
			**バーテックスシェーダか、フラグメントシェーダかを選ぶダイアログが表示される
			***上部のタブでバーテックスシェーダとフラグメントシェーダを切り替え
			***中段のメインウインドウでポリゴンやピクセルを選ぶ
			***下部の「DEBUG」ボタンを押すとステップ実行やウォッチ変数の表示が開始される

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

2019年8月14日 (水) 04:54に124.87.119.49による

2019-08-14T04:54:10Z

@@ 1行目: / 1行目: @@
 '''プログラマブルシェーダー'''（[[英語]]：programmable shader）とは、[[グラフィックカード]]上の[[シェーダー]]で独自の[[プログラム]]（カスタムシェーダー）を実行させられるものをいう。
-== 概要 ==
+==概要==
 初期の[[シェーダー]]は「[[ハードウェアT&L]]（最近では対義語的に[[固定シェーダー]]と呼ばれることが多い）」などと呼ばれ、いわゆる[[API]]的な感じで「ライティングをする」などの固定機能が[[GPU]]に用意されており、[[プログラマー]]は何も考えずポリゴンモデルやテクスチャや座標などを[[GPU]]に送信すると表示用の一枚ペラの絵が返ってくるというものであった。この方式は簡潔明瞭という利点と、だれが作っても似たように絵になるという欠点があった。
@@ 7行目: / 7行目: @@
 その結果、よほどの事がないかぎり[[固定シェーダー]]でこと足りるのにそんなアホくさいことに労力を割くのは得策ではないとして[[Unity]]や[[Unreal Engine]]などの[[ゲームエンジン]]が爆発的に普及した。
 ==関連項目==
 *[[CUDA]] = 最先端、[[NVIDIA]]製品でしか動かない
 *[[HLSL]] = [[CUDA]]から実験的な機能を排除したもの。唯一まともなデバッガがある。
 *[[GLSL]] = [[OpenGL]]や[[Valkan]]などで使われている。
 *[[Metal]] = [[Apple]]製品は[[OpenGL]]が禁止されこれ一本になった

← 古い版		2025年3月4日 (火) 10:39時点における版
74行目:		74行目:

	[[category: GPU]]		[[category: GPU]]
			[[category: 3DCG]]