スタッフBLOG

おはようございます。本日の当番、プログラマーの大川です。

今回のテーマですが、ズバリ「プログラマブル・シェーダ」を取り上げてみたいと思います。次世代機で搭載されている技術で、プログラミングについての知識が無い人でも言葉くらいは知っているのではないでしょうか。

さて、その「プログラマブル・シェーダ」（以下、シェーダ）ですが、歴史などを語り出すとかなりの長文になってしまいますので、ここでは割愛します。

「ほな、何を取り上げるねん？」ということになりますが、最先端の技術論とか展望などではなく、私が実際にゲームプログラムとしてシェーダを組み込んだ際のお話になります。

一般的にシェーダというと、画像処理やら複雑な計算式やらで難しそう、というイメージがあるかと思いますが、実はそんなことはありません。確かに基本的なグラフィックス知識は必要ですが、ゲーム用途（スキニングや法線マップなど）に限定すれば、既出の情報を参考にしながらで簡単に実装出来ます。それより問題なのは、その活用方法です。

ゲームグラフィックスでは、処理速度を重視した汎用的なシェーダ技術が要求されます。ボーンウェイト数の制御、光源計算／種類の有無、法線マップの切り替えなど、様々な機能を搭載したシェーダを設計しなければなりません。

これらの切り替えについては、シェーダの静的／動的分岐機能を活用すれば、実装自体にはさほど問題はありませんが、分岐コスト分の処理速度が犠牲になってしまいます。また、シェーダのレジスタ数にも限界があるため、もし機能が溢れた場合、マルチパスでのレンダリングが必要になります。そうなると、またまた処理速度に影響が出ます。

私もシェーダの設計段階でこういった問題に直面したことがあります。いくら性能が優れていても、処理速度に問題があれば改善はしなければなりません。そこで分岐を一切使わない、機能別にシェーダを事前に生成するシステムを試してみました。

その結果、確かに処理速度は向上しましたが、今度は生成されたシェーダ自体の容量がエラいことに…（汗）光源処理や法線マップなどといった組み合わせにして約８０００種類、容量にすると２０ＭＢ近くになってしまいました。

メモリ容量の問題は、処理速度と双璧を成すほど重要です。う～ん、完全なジレンマですね。で、どうしたかといいますと…、使用頻度の低い組み合わせを排除することで解決！しました。

というワケで、あまり派手なシェーダでなくても、それなりに考えなくてはいけません。私の場合、どちらかというと基礎レベルのシェーダのほうが難しい、と思ったほうでした。

何でも出来る！シェーダ論ではない、かなり地味なお話になってしまいましたが、中には「そうそう！」と共感した方もいらしたのではないでしょうか？

とは言え、数年後にはこんなこと考えなくてもよくなるんでしょうね～。
最近のグラフィックス技術の進歩は凄いですから！