もうすぐ PS3 が登場して、ようやくメジャーハードでハードウエアシェーダーが
当たり前になります。1年前に登場した Xbox360 を筆頭に、ShaderModel3.0 が
リアルタイムレンダリングで必須になるわけです。

本当は 2002年に発売された Xbox1 に ShaderModel1.x が搭載されており
シェーダーの時代はとっくに始まっていました。

あまり注目されなかったのは販売台数のせいもありますが、ShaderModel1.x では
機能的制約が大きかったのも一因でしょう。

特に PixelShader で使用可能なステップ数は 演算8+テクスチャ4 の 12個で、
演算制度も 9～12bit 程度の固定少数でした。

もちろん海外での事情は異なっており、Xbox も PC ゲームも人気があるので
シェーダーのノウハウの蓄積はずいぶん先行しているといえます。

シェーダーの登場によって、開発するプログラマの手間は結構増大します。
固定機能の時代はハードに設定すれば勝手にやってくれたジオメトリやライトの
演算も、まるで時代が逆行したかのように自分でやらなければいけなくなりました。

特に初期のシェーダーはアセンブリ言語で記述していたため、拒否反応を示す
人も多かったようです。

ではなぜそこまでしてシェーダーが必要なのでしょうか。

ハードウエアロジックでの実装はたいへん時間がかかると考えられます。
設計から試作、量産まで、実際に動いて使えるようになるまでどれだけの手間と
時間がかかるか想像もできません。

それでも GPU はテクノロジの進化によってさまざまな機能を実装できるように
なりました。もちろんひたすら高速化のために並列度を上げていけばいいんですが、
それだとトランジスタ数よりも先に、メモリ速度やバス帯域が限界に到達して
しまいます。

そのため、ただただ速度を上げるよりも、より美しい描画を行うために機能を割く
必要が生じます。

ただしこの分野はアルゴリズムの問題であり、どんなアルゴリズムを、どんな仕様
でハードで実装すればいいのか取捨選択するのが難しいのです。
アルゴリズムの研究の進化も早いですから。

だったらプログラマが自由に命令を選択できる方がいいのではないか、そう考える
のも自然でしょう。

ハードウエアシェーダーの登場によって、プログラマが自由にハードウエアの演算
ロジックを変更できるようになりました。

プログラマがハードの機能を選択するのに必要な時間はごくわずかです。いくらでも
設計と試行、フィードバックを繰り返すことができるのです。
ハードロジックを設計してチップを製造する時間とは比較になりません。

ハードウエアアクセラレーションの恩恵を受けつつ新しいアルゴリズムの開発が
短期間でできるようになり、一気にリアルタイムグラフィックスの分野が華やかに
なりました。

アルゴリズムを開拓する人にとってはたいへん魅力的なものです。

そしてシェーダーはハードウエアでしかできなかったさまざまなアルゴリズムを
アプリケーション化してくれます。他の人が作ったシェーダーをもらってきて
使うこともできるわけです。

もう１点、シェーダーがどうしても必要だった理由があります。

GPU の開発会社や Direct3D 等の API を設計する Microsoft 等と、実際にゲーム
等を開発する現場とはどうしてもそれなりの距離や隔たりがあります。

実際に現場が欲しい、リアルタイムレンダリングで欲しい機能と、ハードに実装
される機能は必ずしも一致していませんでした。

頂点カラーの演算方法、値の持ち方、ジオメトリブレンディングの仕様、ライティ
ングの仕様など。

固定機能の時代は、使わない機能やオーバースペックな機能であってもハードに
実装されているため使わざるを得ませんでした。また API の設計によっても
制限を受けます。

むしろ DirectX3～6 等、CPU だけでジオメトリ演算を行っていた時代の方が
ゲームにあわせて自由に頂点や演算を設計し、不要な演算は徹底的に省いて必要
最小限にすることができました。

DirectX7 世代のハードで Hardware Transform and Lighting が搭載され、
演算が極めて高速になったのは望んでいたことでした。
が、速度は速くなったのだけど、逆に使いづらい制約も増えたなと感じたものです。

DirectX8 でシェーダーが登場し、不満だった部分も全部再設計できるようになり
ました。CPU 演算時代の自由度と、GPU の速度の両方を手に入れたのだから
シェーダーは最高です！