連載 .NET＆Windows Vistaへ広がるDirectXの世界 第1回 DirectXの真実 NyaRuRu 2006/06/21
Page1 Page2 Page3

2. 高速描画の裏事情

　Direct3Dの描画処理は、グラフィック・データが最終的な画面出力色になるまでに多段階の変換処理が行われることから、レンダリング・パイプラインと呼称されている。パイプライン方式は、近年のCPUアーキテクチャの説明にもしばしば登場することから、おなじみという方も多いだろう。

レンダリング・パイプラインのイメージ図

各ステージは並行実行できるため、大量のデータを処理するのに適している。

■パイプラインの二面性――スループットとレイテンシ

　パイプライン方式で重要となる速度には2種類あって、単位時間当たりのデータの流量（＝スループット）と、パイプラインにデータを投入してからそのデータが実際に出力されるまでの時間（＝レイテンシ）である。

　ゲームやベンチマークではFPS（Frame Par Second：1秒当たりの画面更新回数）を描画性能の指標に用いることが多いが、これはどちらかというとスループット的な視点である。そのため、大量のオブジェクトを滑らかにアニメーションさせることができる高スループットなハードウェアが高速と評価される傾向があることに注意する必要がある。

　パイプライン構成では、同種のパイプラインを並列させることで単純に処理能力を倍加させることができ、パイプラインの太さに見合った回路を1段追加することで新機能の追加を行うことができるため、ハードウェア技術の進化の範囲内で一定の成長率を維持できることが多い。

　注意深く見てみれば、CPUのクロック競争や、ブロードバンド通信の帯域競争で強調されていたのが実質的にはスループットの向上であったことが分かる。毎年一定の成長が見込めるスループットという指標は、広告面でも扱いやすい数字だったわけだ。

　しかし、高スループットは必ずしも低レイテンシとは限らない。例えば、高DPIでちらつきがなく滑らかにアニメーションするGUI環境が、マウス操作に対しては秒単位の応答時間がかかってしまうということも原理的には起こり得る。ベンチマーク・スコアが3倍のビデオ・カードによって応答時間が3分の1になることを期待してしまうのはありがちな錯覚だが、すべてのWindows Vistaの紹介記事がこういった危うい推論を排除しているかというと残念ながらそうでもない。

■Windows Vistaにおける画面描画の改善

　現実には、ハードウェアの応答時間はそうそう急激に改善されることはなく、むしろ悪化することすらある。それでもアプリケーションの応答時間に大幅な改善があった場合は、その改善はアルゴリズムの工夫によって実現されていることが多いだろう。

　例えば、最近発達してきたデスクトップ検索は、事前に巨大なインデックスを作成していることでWeb検索並みの応答性を実現しているのであって、CPUとHDDのスループットが急に増加したわけでも応答時間が減少したわけでもない。

　同様にWindows VistaのDWM環境では、ウィンドウ切り替えの応答性が改善され、ディスプレイのリフレッシュ・レートに同期した画面更新を行うことでティアリング*6が排除されているが、これは、単純にDirectXの高スループットにより実現されたというよりは、前提とするメモリ・リソースのサイズを増やしたことで、よりリッチなアルゴリズムが選択できるようになった効果が大きいと見るべきであろう。

*6 ビデオ・カードから出力される画面が更新されるタイミングと、ディスプレイの更新タイミングがずれていると、ディスプレイの上部と下部で異なる時刻の画面が同時に表示されてしまい、アニメーションにちらつきを感じる原因となる。このような現象をティアリングと呼ぶ。ディスプレイ更新タイミングに最も近い画面更新以外を破棄することでティアリングは回避できるが、これはある意味ではレイテンシを悪化させているともいえる。

　従来のWindowsのデスクトップ・ウィンドウ・マネージャでは、基本的にデスクトップ画面のみを保持し、手前のウィンドウによって隠されているウィンドウ領域の画像情報は保持しないことで、少ないメモリ・リソースでも実行できるような配慮が行われていた*7。

*7 厳密にはWindows 2000から導入されたLayered Windowによって、ウィンドウごとに画像バッファを持つことは以前から可能ではあった。Vista DWMはこれを一段進め、GDI描画をリダイレクトすることで、すべてのウィンドウ描画がオフ・スクリーン画面に行われるようにするものだ。

　そしてウィンドウ切り替えによって隠れていた領域が表に現れると該当するウィンドウに対して再描画を求めるメッセージが送信されるが、一般に描画メッセージの優先度は低いため、ほかのメッセージ処理が一段落してからやっと再描画が始まるということになる。そのため従来のWindows環境では、画面更新が目で分かるほど遅延する場面があった。

　Vista DWMでは、対照的に、各ウィンドウが必ず独自の画像バッファを持つようになったため、ウィンドウ切り替え時に再描画が不要となり、またウィンドウ合成後の画面が実際にディスプレイに表示されるタイミングをリフレッシュ・レートに同期させられるようになった。この改善を「Direct3Dによってハードウェア処理されるようになったから」と片付けてしまうのはいささか乱暴であるように思う。

　Windows VistaにはWindows Aeroスタイル（＝「Windows Vista Aero」モード）のほかに従来どおりまたはAeroよりも少ないリソースで動く描画アルゴリズムを使用するクラシック・スタイル（＝「Windows Vista ベーシック」「Windows スタンダード」「Windows クラシック」などのモード）も存在するが、応答性に注目すると、最近のハードウェアではクラシック・スタイルの方が「遅く」「ちらついて」感じられるのではないかと思う。

　実際、筆者の手元のベータ版では、クラシック・スタイルよりWindows Aeroスタイルの方が軽快と感じる場面が多々あり、この点ではWindows Vistaに移行することで作業効率が改善されると納得できる。このような改善があまりクローズアップされない一方で、デスクトップに3D表現が使用されるといったさまつな部分のみに報道が集中しているのは実にもったいないことだ。

■リレーショナル・データベースとの類似性

　再びDirectXの話に戻ろう。

　初期のDirect3Dデバイスの特性をひと言でいうと、非常に多くの三角形をまとめて受け取り、その内側を塗りつぶすことに特化したハードウェア、というものだ。

　最もシンプルな構成では、ハードウェアはスクリーン上の座標の列を受け取り、出来た三角形をひたすら塗りつぶしていくデバイスとして理解することができる。ハードウェアが受け取るデータはリレーショナル・データベース（以下、RDB）でいうところのテーブルに近く、必要最低限な部分に絞れば、スクリーン座標（x, y）の2列である。

　この時代、スクリーン上の頂点座標は、カメラの位置や向きなどを考慮してCPUによって計算で求めていた。なお、この過程でしばしば行列計算が出てくるためDirectXプログラミングには数学が必要といわれるのだが、ここでのポイントは、処理を変化する部分と変化しない部分に分けるというところにある。

　次の3つの処理に注目してみよう。

　物体形状を表すデータ配列X　→　変換1　→　スクリーンに投影した頂点配列1
　物体形状を表すデータ配列X　→　変換2　→　スクリーンに投影した頂点配列2
　物体形状を表すデータ配列X　→　変換3　→　スクリーンに投影した頂点配列3

　基となるデータ配列Xと対応する変換1／変換2／変換3さえ保持しておけば、それぞれの変換結果は何度でも再現できる。

　RDBもしばしばこれと似た戦略をとる。永続化すべきは、ある物事を表す必要最低限なデータであり、そのデータを射影することで作成可能な2次データは必要に応じて計算で求めればよい。

　テーブルX　→　クエリ1　→　出力1
　テーブルX　→　クエリ2　→　出力2
　テーブルX　→　クエリ3　→　出力3

　リアルタイム3Dプログラミングにおいては、基準座標系で表された物体形状というのは正規化されたテーブルに似たような意味を持つ。

　変換処理が行う作業は、さまざまな姿勢で空間上に配置することであったり、特定のカメラ視点で眺めることであったりするのだが、これらの変換はしばしば4次正方行列（16個の浮動小数点数）で表現される。つまり、ある形状の物体を100通りの姿勢で画面上に表示するためには、1つの形状データと、100個の姿勢に対応する行列のみを管理すればよい。姿勢を1つ追加することによる増加分は、物体の頂点数に関係なく64bytes（float×16）である。

　3Dゲームが市場に登場し始めたころは、行列による座標変換を毎回CPUで行い、計算結果の三角形頂点座標をハードウェアに送っていた。これは、ポリゴン数の向上ペースがCPUスループットの向上曲線を上回れないということを意味する。この状況を打破するためには、ハードウェアにあらかじめデータを転送しておき、変換処理自体をアウトソースすればよい。これこそがDirectX 7で導入された「ハードウェアT&L」（HARDWARE Transform and Lighting）と呼ばれる仕組みの本質である。

　ハードウェアT&LとCPU処理のどちらが高い絶対性能を示すかは場合によって異なり、事実当初はハイエンドCPUで変換処理を行う方が高いスループットを示すケースもあった。現在でもこの部分をCPUによってエミュレートする環境は少なくない。とはいえ、高いスケーラビリティとコスト・パフォーマンスでハードウェア頂点処理は徐々に市場を席巻しつつある。

　またライティングを行うための計算（光源計算）も、ハードウェアT&Lの時代にCPUからビデオ・カードに移された。光源計算の種類ごとに最適化された専用回路が用意され、変換処理そのものがビデオ・カード内で完結したことで、静的データはもはやメイン・メモリではなくむしろビデオ・メモリ側に存在すべきということになり、CPUとビデオ・カードの関係は急速にサーバ／クライアントの色を強めていった。この流れはGPUがプログラマブルになることでさらに加速していく。

　そして、描画処理そのものをプログラムしてビデオ・カード上で実行できるようになった。専用言語で記述された描画処理は、事前または実行時にコンパイルされ、実行時にハードウェアに転送されている。これに伴う変換処理の自由度の向上は、基となるテーブル設計の段階から最適化し直すことを可能にし、物体形状を表すテーブルは、もはやシステム定義の固定フォーマットである必要すらない。

　また、以前はほぼ固定フォーマットの単一テーブルしか参照できなかったという制限がなくなり、現在では自由にテーブルを定義し、十数テーブルを同時に参照することも可能になっている。こうなってくると、O/Rマッピングやデータ中心アプローチ（DOA）による開発といったおなじみの話が出てくるのが必然といえるが、それについては後述することにし、さらにDirectXの奥深くをのぞいてみよう。

　続いては、ドライバ・レベルでのDirectXがどのような高速化戦略を採っているかについて見てみよう。

INDEX
	.NET＆Windows Vistaへ広がるDirectXの世界
	第1回 DirectXの真実
	1．DirectXとは？
	2．高速描画の裏事情（1）
	3．高速描画の裏事情（2）

　

「.NET＆Windows Vistaへ広がるDirectXの世界」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）