【著者近影】
ニンテンドー3DSのグラフィックスIPコアに国産のPICA200が採用されたことは筆者も驚かされたが、どうやって従来機のDSとの互換性をとるのかが気になるところ。先代機のエミュレーションを嫌う任天堂のことなのでシュリンクした専用チップで従来DSソフトを動かす可能性は高い。3DSにはまだまだ謎が多いが、それだけに夢もある。筆者のブログはこちら

　ディジタルメディアプロフェッショナル(本社：東京都武蔵野市、代表取締役CEO 山本達夫、以下DMP)は2010年6月21日、任天堂の新型携帯ゲーム機「ニンテンドー3DS」にDMPの3DグラフィックスIPコア「PICA200」が採用されたことを発表した。

　事前に出回った噂では、NVIDIAの組み込み向けGPU、2世代目TEGRA(俗称「TEGRA2」)が採用されると言われていたが、大方の予想を裏切る形で、日本独自設計の国産のグラフィックスIPコアが採用されることとなり、業界に大きなセンセーションを呼んだ。

　今回の3Dグラフィックス講座では、このニンテンドー3DSに採用されたというDMPのGPU「PICA200」のアーキテクチャに迫ってみたいと思う。

■ ニンテンドー3DSのグラフィックスIPコアを開発したDMPとは?

左から、アプリケーションビジネス推進ディレクター 桐井敬祐氏、代表取締役兼CEO 山本達夫氏、取締役ハードウェア開発部長 大渕栄作氏、取締役ソフトウェア開発部長 岩田茂人氏、執行役員ビジネス開発担当 横関亘氏

DMPの事業概要

　DMPは、東京都武蔵野市に2002年に設立された比較的若い会社で、社員は40数名ほど。NVIDIA等と比べれば規模の小さい会社だ。主に組み込み機器向けや業務用の3Dグラフィックスプロセッサ、いわゆるGPUのIP(Intellectual Property)コアを設計すること及び関連のソフトウェア開発を主たる業務にしている。

　DMPの企業活動の中で、1つのマイルストーンとなり、なおかつ、その後の技術開発のベースとなったのが、2005年のGPU「ULTRAY2000」(アルトレイ2000)の自社開発成功だ。ULTRAY2000は、当時、TSMCの0.13μmプロセスルールで製造され、実動デモの公開はロサンゼルスで開催された「SIGGRAPH2005」で行なわれた。

　ULTRAY2000のトランジスタ数は1億以上で、実動チップはFCBGAパッケージであった。当時の実動デモプロセッサの動作周波数は200MHz、ビデオメモリとして400MHzデータレートのDDR SDRAM 256MBが256ビットバスで接続されていた。接続ホストインターフェイスは64ビット/66MHz PCIバス、あるいは32ビット/33MHz PCIバスの両方に対応していたが、半ば実験的なプロジェクトであったためか、当時最新バスであったPCI-Expressへの対応は見送られていた。

　パイプライン構造および頂点性能、ピクセルフィルレートなどの基本性能値は当時も公開されず。公開されていたのは対応プログラミングAPIのみで、当時はOpenGL2.0、OpenGL ES2.0、携帯機器向けのJAVAベースの3D-APIであるJSR184への対応が謳われていた。

　この時点で、ULTRAY2000がユニークだったのは、プログラマブルシェーダー・アーキテクチャをあえて採用しないという点であった。この開発コンセプトは、今回、3DSに採用されたDMPのGPUである「PICA200」にも継承されている。

【ULTRAY2000】
「PICA200」の元になった「ULTRAY2000」
SIGGRAPH2005で公開されたULTRAY200評価システム（左）、SIGGRAPH2006ではPICA200の評価システムも公開された（右）

■ DMPの「プログラマブルシェーダー」のハードウェア化という新発想

ULTRAY2000のブロックダイアグラム

DMPのGPUのIPコアラインナップ

　2000年、GPUはそのアーキテクチャに、大きな変革期を迎えた。プログラマブルシェーダーアーキテクチャ時代の到来だ。

　それまでGPUメーカーは、新しい3Dグラフィックス表現を実現するために、各社独自のハードウェア機能を追加していた。これらの独自機能は各社のGPU間で機能的な互換はなく、それゆえにその機能を使うものも少数派となってしまい、世代を重ねるごとに独自機能が肥大化していくことになる。そこで業界は、最新のグラフィックス技術をソフトウェア的に実装する方針に解決を見出した。これがプログラマブルシェーダーの概念であり、2000年のDirectX 8で、この標準化が進むと、以降のGPUの進化の歴史はプログラマブルシェーダーアーキテクチャの進化にシンクロして行なわれることとなる。

　この新概念は、消費電力、チップコスト等がある程度許容できるPCやワークステーション、あるいは据え置き型ゲーム機などのGPUには、うまくハマった考え方だったが、全ての局面で歓迎されていたわけでもなかった。

　特に使えるリソースが限られ、なおかつ設計上の電力や熱にまつわる仕様制限が厳しい小型携帯機器ではプログラマブルシェーダーアーキテクチャはオーバースペックであり、性能対消費電力の面で、効率があまりよくなかった。

　たとえば最も基本的なピクセルシェーダーの処理系であるフォンシェーディングを行なう場合にしても、これを行なうためのシェーダープログラムをGPU側のメモリに置かなければならないし、その命令の取り出しにはメモリバスを使う。また、プログラムの実行に際してはテンポラリレジスタを介して演算器を駆動することになる。どんなに定番の処理系でもプログラマブルシェーダーアーキテクチャではソフトウェアを実行しなければ処理系が成り立たないのだ。

　一般的な3Dアプリケーションを制作する際、必要になってくる3Dグラフィックス表現には定番といえるものがあり、それらまでを全てプログラマブルシェーダーで構築するのは無駄なのではないのか？

　プログラマブルシェーダーが業界標準となっていく一方で、こうしたアンチテーゼも、組み込み機器や携帯機器の世界では起こったのだ。プログラマブルシェーダーの活用が進む過程で、よく使われる定番のプログラマブルシェーダー活用の処理系を、逆に専用ハードウェアの形で実装してしまえば、ハイパフォーマンスが期待でき、なおかつメモリやレジスタなどの無駄なリソース活用も減らせられるため、性能対消費電力の効率の面で優れるのではないか。DMPはこの考えを軸に独自GPUの開発に乗り出した。

　この考え方を具現化したのがDMP独自の「MAESTRO」アーキテクチャになる。心配されるのは、これでは、DirectX 7以前の無計画な新機能の増改築が乱立した旧世代GPUの問題が再発しないかという点だが、これについてはDMPは問題無いと考えている。

　その理由の1つは、MAESTROアーキテクチャは、プログラマブルシェーダーアーキテクチャで使用される定番の処理系をハードウェア化するのであって、単一の使い切り機能を増設していくのとは違うためだ。

　いわば、現状のプログラマブルシェーダーアーキテクチャ上で走るシェーダープログラムの最大公約数的ロジックをハードウェア化するのであり、根本的にはプログラマブルシェーダーアーキテクチャに対立するものではないのだ。

　プログラマブルシェーダーアーキテクチャの進化が進むことで、「定番の処理系」も増えていくことだろう。その時代時代の代表的な定番のシェーダープログラムのロジックをその都度、ハードウェア化して実装していけば時代遅れになることもない。組み込み機器や小型携帯機器ではプラットフォームサイクルが早いため、MAESTROアーキテクチャのリファインの機会は多いはず、とDMPは見ている。

　プロセッサの製造プロセスルールの進化やその実装技術が進むことで、いちいち定番シェーダーロジックをハードウェア化せずとも、プログラマブルシェーダーのままで、要求される性能対消費電力を満たせる局面もやってくるかもしれない。そうした状況に対応すべく、DMPはMAESTROアーキテクチャとは別に、素のOpenGL ES2.0ベースのプログラマブルシェーダーが利用できるGPUアーキテクチャとして「SMAPH-S」や「PICA Extreme」というラインも用意している。

　なお、SMAPH-SはOpenGL/ES2.0フル対応GPUで、PICA Extremeは、PICA系列のMAESTROアーキテクチャをベースに、OpenGL/ES2.0とOpenCLへの対応を行なったDMPアーキテクチャの全部入りバージョンという位置付けになる。

■ PICA200のベースライン機能はOpenGL/ES1.1+1.1拡張パック相当

OpenGL ES1.0で利用できる3Dグラフィックス機能

OpenGL ES1.1で利用できる3Dグラフィックス機能

OpenGL/ES1.1の拡張パックで利用できる3Dグラフィックス機能

　ニンテンドー3DSに採用された「PICA200」は、前出のULTRAY2000をベースに組み込み機器向けや携帯機器向けに最適化、カスタマイズしたバージョンになる。

　ハードウェアスペックの公開を嫌う任天堂は、3DSで採用されるPICA200の詳細スペックを公表していない。ただし、PICA200である事は間違いないため、ここからはPICA200がどういったGPUなのかを見ていきながら、3DSのグラフィックスパフォーマンスに思いを侍らせてみることにしよう。

　PICA200のベースラインとしての3Dグラフィックス仕様はOpenGL/ES1.1に準拠したものになる。また、PICA200は、OpenGL/ES1.1仕様に加え、OpenGLの規格を策定する団体KHRONOSグループが策定したOpenGL/ES1.1拡張パック(1.1 extension Pack)の仕様についてもフルサポートしている。

　レンダリングパイプラインは固定パイプライン機能ベースになり、PCでいうとDirectX 7相当のアーキテクチャになる。PICA200はIPコアであるため、クライアント(3DSの場合であれば任天堂)の要求仕様に対して、ある程度自由な設計が可能となるが、PICA200のベースラインとしての仕様は、頂点(V)パイプラインが4本、ピクセル(P)パイプラインが4本になる。一般論としては、このV4×P4を基準として、クライアント要求仕様に合わせてV4×P8としたり、V8×P8としたりする可能性があるわけだが、例によって3DS向けのプロファイルは公開されていないため、正確なパフォーマンスはわからない。

　具体的に、PICA200において、基本レンダリングパイプラインで、どういった機能がサポートされるのか、パイプラインの上段から下段に向かって1つずつ整理してみることにしよう。

　まず、頂点パイプラインだが、ここではARB_Vertex_Programがサポートされるため、基本的な頂点シェーダープログラムは動作することになる。ここでは頂点単位のライティング演算はもちろん、各種マトリックス計算、頂点スキニング処理などをプログラマブルに行なうことができる。取り扱えるプリミティブは一般的なポリゴンの他に、ライン、ポイントスプライト(パーティクル)などがある。

　頂点データ配列でしかなかったポリゴンデータを実体を伴うピクセルへと変換するラスタライズ処理は固定機能ユニットになる。ここでは隠面消去などの機能が備わっている。ピクセルパイプラインは、固定機能シェーダーで構成され、高度なテクスチャアドレス計算、ピクセル単位の各種陰影処理がサポートされる。ピクセルフォーマットはRGBαが全部8ビットの8888の32ビットフォーマットはもちろん、4444、5551、5650の16ビットフォーマットもサポートされる。フレームバッファの最大解像度は4,095×4,095ピクセル(テクセル)となっている。

　テクスチャユニットは、キューブ環境マップやスペキュラマップなど、基本的な近代テクスチャマッピングメソッドの多くがサポートされているが、簡略化されている部分もある。それはテクスチャフィルタリングはバイリニアとトライリニアをサポートするが、異方性はサポートされない点だ。テクスチャ圧縮メソッドについては、DirectXで標準的に利用されているDXTCよりも高品位に圧縮できるETC(Ericsson Texture Compression)に対応する。

　パイプラインの最下段、実際のビデオメモリ出力を担当するフレームバッファ・オペレーション(ROP:Rendering Output Pipeline)においては、α合成、フォグ、ステンシル処理などがサポートされる。デプスバッファは24ビット、ステンシルは8ビット。

　アンチエイリアスは4X(2X2)のスーパーサンプリング方式とマルチサンプル方式に対応する。マルチサンプル方式の場合はピクセルシェーダーは1X解像度、Zバッファは4X解像度になる、ごく一般的な実装だ。ここまでがPICA200の「OpenGL/ES1.1の基本機能+1.1拡張パック」までの機能になる。

■ PICA200の目玉機能、MAESTROアーキテクチャはコンフィギュラブルシェーダーである

PICA200のソフトウェア開発フロー。PC上で開発したOpenGL2.0ベースのシェーダープログラムをPICA200上でのコンフィギュラブルシェーダーで動作する形式に変換する仕組みがある

　冒頭で解説したように、PICA200は、プログラマブルシェーダーを用いて構成される定番のシェーダーロジックをハードウェア化したDMP独自の拡張機能も備えている。この部分が「MAESTRO」と呼ばれる機能になる。

　DMPの研究開発チームが、一般的なリアルタイム3Dグラフィックス表現において、どういったものがよく用いられるかを調査し、そうした表現の数々から、それらで頻繁に用いられている演算処理系の数々を定式化して抜き出し、それらをハードウェアロジックで構成して、PICA200に実装している。これがMAESTROアーキテクチャの正体だ。

　MAESTROを構成するハードウェアロジックを大別すると2種類に分かれる。1つは、パラメータを与えることで特定の固定機能を提供する、いうなれば固定機能シェーダー的なロジックだ。詳細は後で解説するが、テッセレーション機能(サブディビジョン機能)やプロシージャル・テクスチャ機能などが、これに該当する。

　もうひとつは、プログラマブルシェーダーアーキテクチャ上で動作するシェーダープログラムに含まれる定番の演算処理系を1つのハードウェアロジックでまとめ上げた複合演算ユニット形態のロジックだ。これらはいわば、シェーダープログラムの部品をハードウェア化したようなものになる。

　こうした部品ロジックは各頂点パイプライン、あるいは各ピクセルパイプラインに1個以上実装されているものと、各パイプライン全体で共有されて利用される実装形態にあるものとがあるが、どういった部品ロジックがハードウェア化されているか、どの部品ロジックが各パイプラインに何個あるのかといった点についてはDMPは「企業秘密」として公開していない。

　MAESTROアーキテクチャでは、この部品ロジックを自在に組み合わせて、ある程度自由なシェーダーを構成することができる。発表当時、多くのメディアが「PICA200は固定機能シェーダーアーキテクチャである」と報じたが、これは確かに間違えてはいないが、「実際には、コンフィギュラブル・シェーダーという表現の方が的を射ていると思う」とDMP側は述べている。

　部品ロジックは、1回のパイプライン起用において複数回、再利用することができる。もちろん、利用回数の上限はあるし、利用回数を増やせば処理時間は嵩む。また、部品ロジックの組み合わせにもある程度の制限はあると思われる。

　DMPによれば、「一般的な処理を行なうシェーダープログラムであれば、部品ロジックの組み合わせで大抵は構成できる。深度バッファを利用したエフェクトや、ポストプロセスエフェクトのようなこともできなくはない」とのことで、かなり自由度は高いと見て良さそうだ。

　それでは、実際にどのようにして開発者はコンフィギュラブルシェーダーを書くのだろうか。さすがに、部品ロジックをどう組み合わせるのか、までを開発者に考えさせるのはシェーダープログラムをアセンブラで書いていた時代よりも難しそうだ。

　これについては、ちゃんとDMPが提供する開発キットが半自動でサポートしてくれる。 プログラマブルシェーダーに慣れ親しんだ開発者であれば、PC上でシェーダープログラムをOpenGL2.0ベースで書けばいい。その動作はPC上のPICA200エミュレータ上で確認することができる。

　実機のPICA200へ落とし込む際には、PICA200の開発キットに含まれる「ShaderBox」と呼ばれるオーサリングツールが、OpenGL2.0ベースのシェーダープログラムを、PICA200のコンフィギュラブルシェーダーで動作できるよう、MAESTRO上の部品ロジックの組み合わせに分解してくれる。

　もちろん、あまりにも奇抜だったり、演算ヘビーなシェーダープログラムのコンバージョンは不可能だと思われるが、少なくとも、プログラマブルシェーダーに慣れ親しんだ開発者はその知識を用いた開発は行なえる。逆に、プログラマブルシェーダーに不慣れな開発者は、DMPが提供しているMAESTROライブラリを利用して、使いたい表現やエフェクトを適当にチョイスして使えばいいのだ。

　MAESTROの実体が、コンフィギュラブル・シェーダーであることがわかった。ここまでを前編とし、続く後編では、DMPの独自グラフィックス機能である「MAESTRO」によって提供されるグラフィックス表現の1つ1つを見ていくことにしよう。

(C) 2010 株式会社ディジタルメディアプロフェッショナル