図1は、実施の形態に係るマルチプロセッサシステムの構成図である。このマルチプロセッサシステムは、CPU(Central Processing Unit)100と、GPU(Graphic Processing Unit)200と、メインメモリ120と、ローカルメモリ220とを含む。
CPU100は、単一のメインプロセッサであってもよく、複数のプロセッサを含むマルチプロセッサシステムであってもよく、あるいは、複数のプロセッサコアを1個のパッケージに集積したマルチコアプロセッサであってもよい。GPU200は、グラフィックプロセッサコアを搭載したグラフィックチップである。
CPU100の入出力ポートとGPU200の入出力ポートは、入出力インタフェース(以下、「IOIF」と呼ぶ)110で接続されており、CPU100とGPU200は互いにIOIF110を介してデータをやりとりすることができる。IOIF110は、非常に高速なインタフェースであり、その帯域幅は、CPU100とメインメモリ120の間を結ぶバス122や、GPU200とローカルメモリ220の間を結ぶバス222の帯域幅にほぼ等しい。
グラフィックスライブラリ300は、描画処理を行うために生成されるグラフィックスコマンドを生成および管理するためのライブラリであり、アプリケーション310からこのライブラリを呼び出してグラフィックス処理を実行することができる。また、グラフィックスライブラリ300は、メモリ管理やデータ転送制御の機能を提供し、それらの機能を利用して、アプリケーション310から、メモリマッピングや、ジオメトリ情報、テクスチャ、シェーダプログラムなどのデータのメモリ間転送などを実行することができる。
CPU100は、アプリケーション310がグラフィックスライブラリ300を用いて生成したグラフィックスコマンドを、メインメモリ120内に設けられたコマンドバッファ10にキューイングする。GPU200は、コマンドバッファ10に蓄積されたグラフィックスコマンドを順次読み出して処理する。コマンドバッファ10に対するグラフィックスコマンドの読み書きには同期機能が提供されており、アプリケーション310は、CPU100からGPU200への処理の流れをきめ細かく制御することができる。
CPU100は、オブジェクトの3次元モデルにもとづいて、ポリゴンの頂点座標値、頂点カラー、法線ベクトル、UV値などのジオメトリデータ12を生成し、メインメモリ120に格納する。また、CPU100は、ポリゴン表面にマッピングするためのテクスチャ14をメインメモリ120に格納する。さらに、CPU100は、ハードディスクなどの記録媒体からシェーダプログラム16を読み込み、メインメモリ120に格納する。
メインメモリ120のメモリ領域はI/Oアドレス空間にメモリマッピングされており、GPU200は、I/Oアドレス空間にメモリマップされたメインメモリ120のメモリ領域をIOIF110経由で読み取ることができる。このように、GPU200は、ローカルメモリ220の他にメインメモリ120へアクセスすることができるため、ジオメトリデータ、テクスチャなどグラフィックス演算に必要なデータをローカルメモリ220にもメインメモリ120にも配置することができる。グラフィックス演算に必要なデータの参照頻度やサイズに応じて、システム全体でもっとも効率が良くなるようにローカルメモリ220またはメインメモリ120にデータが配置される。
ジオメトリデータ12、テクスチャ14およびシェーダプログラム16が格納されたメインメモリ120内のメモリ領域は、IOIF110のコントローラに設けられたメモリ内のI/Oアドレス空間にメモリマッピングされる。GPU200は、IOIF110を介して、I/Oアドレス空間にメモリマッピングされたジオメトリデータ12、テクスチャ14およびシェーダプログラム16を読み出す。
GPU200は、シェーダプログラム16にしたがって、ジオメトリデータ12を用いてポリゴンのラスタライズデータを生成し、ピクセルデータをフレームバッファ20に書き込む。さらに、GPU200は、ポリゴン表面にテクスチャ14をマッピングし、テクスチャマッピング後のピクセルデータをフレームバッファ20に書き込む。
また、GPU200は、ローカルメモリ220内にジオメトリデータ22、テクスチャ24およびシェーダプログラム26が格納されている場合、ローカルメモリ220からこれらのデータを読み出し、グラフィックス演算に利用する。これらのデータは、メインメモリ120からローカルメモリ220にあらかじめDMA転送してもよく、GPU200がIOIF110経由でメインメモリ120から読み出し、ローカルメモリ220に格納してもよい。
図2は、メインメモリ120の実効アドレス空間140とIOIF110のI/Oアドレス空間150の関係を説明する図である。
アプリケーション310は、グラフィックスライブラリ300のメモリ初期化関数を用いて、GPU200にアクセスを許可するメインメモリ120内のメモリ領域を確保する。グラフィックスライブラリ300は、確保されたメモリ領域の実効アドレスとサイズにもとづいて、そのメモリ領域をI/Oアドレス空間にメモリマッピングする。これにより、メインメモリ120内のメモリ領域がI/Oアドレス空間150の一部としてGPU200からアクセス可能になる。
GPU200がメインメモリ120へアクセスする際に使用する参照先アドレスは、I/Oアドレス空間150の先頭アドレスをベースアドレスとするオフセットであり、実効アドレス空間140の実効アドレスではない。グラフィックスライブラリ300は、I/Oアドレス空間150のベースアドレスを管理するとともに、実効アドレス空間140を参照する際の実効アドレスを、I/Oアドレス空間150を参照する際のオフセットに変換する関数を提供する。
グラフィックスライブラリ300は、実効アドレス空間140からI/Oアドレス空間150へのメモリマッピングを管理し、アプリケーションがメインメモリ120内で確保した連続領域がGPU200からも同じような連続領域に見えることを保証する。これにより、実効アドレス空間140において実効アドレスで参照されるデータをI/Oアドレス空間150においてベースアドレスに対するオフセットを指定することで読み出すことが可能となる。もっとも、実効アドレス空間140およびI/Oアドレス空間150はともに仮想的なメモリ空間であるから、物理メモリとしては連続している必要はない。
以下、図3A〜図3Cを参照して、テクスチャをメインメモリ120および/またはローカルメモリ220に配置した場合にテクスチャの転送効率がどのように変わるか説明する。ここでは、テクスチャの例で説明するが、テクスチャ以外のグラフィックス演算に必要なデータを配置する場合にも同様のことが当てはまる。
図3Aは、テクスチャをローカルメモリ220側に配置した構成を示す。メインメモリ120に格納されたテクスチャ14は、ローカルメモリ220にあらかじめDMA転送される。GPU200は、ローカルメモリ220にDMA転送されたテクスチャ24を読み出してグラフィックス演算に利用する。一方、GPU200は、ローカルメモリ220のフレームバッファ20に対してピクセルデータ25を読み書きする。
この構成では、GPU200とローカルメモリ220の間のバス222は、ピクセルデータ25の読み書きとテクスチャ24の読み取りの両方に用いられ、バスの帯域がリードとライトの双方向で消費されることになるから、テクスチャの転送速度が低下し、グラフィックス演算の全体の処理効率が落ちる。
図3Bは、テクスチャをメインメモリ120側に配置した構成を示す。メインメモリ120にテクスチャ14が格納されており、テクスチャ14が格納された領域は、GPU200からアクセス可能にI/Oアドレス空間にメモリマッピングされている。GPU200はIOIF110を介してメインメモリ120内のテクスチャ14を読み取り、テクスチャマッピングに利用する。一方、GPU200はローカルメモリ220のフレームバッファ20に対してピクセルデータ25を読み書きする。
この構成では、テクスチャ14の読み取りはIOIF110の帯域を使って行われ、ピクセルデータ25の読み書きはバス222の帯域を使って行われる。図3Aの構成と比べた場合、バス222の帯域はピクセルデータ25の読み書きに使われるだけであり、テクスチャの読み取りはバス222に負担をかけない。テクスチャ14はIOIF110の帯域を使って転送されるから、GPU200がローカルメモリ220のフレームバッファ20にピクセルデータ25を書き込んでいる間も、テクスチャ14の転送速度が低下することはない。
図3Cは、テクスチャをメインメモリ120とローカルメモリ220に分散配置した構成を示す。テクスチャのファイルが複数枚ある場合に、メインメモリ120に一部の枚数のテクスチャ14が格納され、ローカルメモリ220に残りの枚数のテクスチャ24が格納される。
IOIF110の帯域幅はバス222の帯域幅と同程度に大きいが、GPU200がIOIF110経由でメインメモリ120内のテクスチャ14を読み取る場合は、CPU100側の処理が介在するため、GPU200がバス222経由でローカルメモリ220から直接テクスチャ24を読み取る場合よりもレーテンシーが長くなる。一方、GPU200がローカルメモリ220からテクスチャ24を読み取る場合は、ピクセルデータ25の読み書きと競合するため、バス222の帯域幅が圧迫され、転送速度が低下することがある。そこで、テクスチャをメインメモリ120とローカルメモリ220に分散させて格納しておくことにより、テクスチャの読み取り速度を最適化することが可能となる。
図4は、メインメモリ120に配置されるテクスチャの枚数を変化させた場合におけるテクスチャの転送速度を示す図である。ここでは、8枚のテクスチャを用いて描画処理を行うサンプルプログラムを用いて実験し、メインメモリ120とローカルメモリ220に配置されるテクスチャの枚数を変えながら描画時間を計測する。サンプルプログラムでは、8枚のテクスチャの平均値を求めて各ポリゴンにテクスチャマッピングする。8枚のテクスチャの総データ量を測定された描画時間で割ることで全テクスチャの転送速度が求められる。
同図には、メインメモリ120に配置されるテクスチャの枚数を0〜8の間で変化させて描画処理を実行したときの全テクスチャの転送速度(単位はギガバイト/秒)が示されている。メインメモリ120に格納されない残りのテクスチャはあらかじめローカルメモリ220に転送される。メインメモリ120に格納するテクスチャの枚数を増やしていくにつれて転送速度が上昇し、5枚のテクスチャをメインメモリ120に配置した場合に転送速度が最大になる。これは、メインメモリ120に記憶されたテクスチャの読み込みはIOIF110の帯域幅を利用して行われ、ローカルメモリ220のバス222の輻輳を避けることができるからである。しかし、6枚以上のテクスチャをメインメモリ120に配置すると、転送速度が逆に低下していく。これは、IOIF110の帯域がボトルネックとなり、また、ローカルメモリ220からデータを読み出すときのレーテンシーによって描画時間が長くなるためである。なお、この結果は、負荷の状況によって変化する。
この実験結果にもとづいて、5枚のテクスチャをメインメモリ120に配置し、3枚のテクスチャをローカルメモリ220に配置することで、最適な転送速度を実現することができる。プログラマは、このようなサンプルプログラムを用いて実験することで、メインメモリ120とローカルメモリ220に格納するテクスチャの最適な配分をあらかじめ決定する。グラフィックスライブラリ300は、メインメモリ120からローカルメモリ220へデータを転送するための関数を提供しており、プログラマは、その関数を用いて、テクスチャの配置をプログラムする。
また、別のサンプルプログラムの例として、ビデオテクスチャの処理プログラムを用いることもできる。ビデオテクスチャとは、動画のフレームをテクスチャとして画面の一部に貼り付けたものである。このビデオテクスチャのサンプルプログラムでは、CPU100が実行するビデオコーデック(codec)で生成された動画のフレームをテクスチャとして用いるため、テクスチャをあらかじめローカルメモリ220に格納しておくことはできない。ビデオコーデックによりメインメモリ120に生成される動画フレームをGPU200が直接読み出すか、メインメモリ120に生成された動画フレームをいったんローカルメモリ220にフレーム毎に転送するしかない。
ビデオテクスチャのサンプルプログラムでは、メインメモリ120に生成された動画フレームをGPU200がIOIF110経由で読み込み、テクスチャマッピングに利用する場合の描画時間を計測することができる。また、動画フレームをフレーム毎にメインメモリ120からローカルメモリ220へIOIF110を介して転送した上で、GPU200がローカルメモリ220からバス222経由で動画のフレームを読み込み、テクスチャマッピングに利用する場合の描画時間を計測することができる。
動画フレームをテクスチャとしてメインメモリ120に格納し、メインメモリ120から直接テクスチャマッピングする場合、GPU200によるローカルメモリ220に対するアクセスはピクセルデータの書き込みだけになるため、ローカルメモリ220に対して発生するアクセス負荷が減る。これに対して、ローカルメモリ220に動画フレームを転送してローカルメモリ220から動画フレームを読み出してテクスチャマッピングする場合、ローカルメモリ220からのテクスチャの読み込みとローカルメモリ220へのピクセルデータの書き込みの両方向のアクセスが発生するため、バス222の輻輳により、テクスチャの転送速度が低下する。
プログラマは、実際のアプリケーションに近いサンプルプログラムを用いてシミュレーションを行い、テクスチャがメインメモリ120および/またはローカルメモリ220に最適に配置されるようにアプリケーションをプログラミングする。
複数のテクスチャをテクスチャマッピングに利用する場合、テクスチャによって参照される頻度が異なることもある。GPU200からの参照頻度の高いテクスチャは、GPU200から高速にアクセス可能なローカルメモリ220に配置し、GPU200からの参照頻度の低いテクスチャはメインメモリ120に配置することで転送効率の調整を図ることができる。また、メインメモリ120の容量に比べてローカルメモリ220の容量が小さい場合、サイズの小さいテクスチャをローカルメモリ220に配置し、サイズの大きいテクスチャをメインメモリ120に配置してもよい。
あらかじめ用意されたテクスチャを利用する場合はテクスチャに対して書き込みが発生せず、テクスチャは読み取り専用となるから、メインメモリ120に配置してGPU200から読み出すことがグラフィックス処理全体の効率化につながる。しかしながら、CPU100やGPU200がテクスチャを生成する場合は、テクスチャを生成するCPU100やGPU200が直接読み書きするメモリにテクスチャを格納するのが効率的である。たとえば、パーリン(Perlin)ノイズで生成されるテクスチャのようなプロシージャルテクスチャ(procedual texture)では、CPU100が計算によりテクスチャを生成するため、CPU100が直接読み書き可能なメインメモリ120にテクスチャを格納するのが効率的である。
一方、描画テクスチャ(rendered texture)と呼ばれるように、GPU200がフレームバッファ20に描画したフレームをテクスチャとして用いる場合は、GPU200が直接読み書きできるローカルメモリ220にテクスチャを格納するのが効率的である。
このように、テクスチャに対して読み書きが発生する場合は、その読み書きの主体がCPU100である場合は、メインメモリ120にテクスチャを格納し、読み書きの主体がGPU200である場合は、ローカルメモリ220にテクスチャを格納するのが処理効率の面で有利である。
同様に、頂点データについても、CPU100が頂点データを生成する場合は、頂点データをメインメモリ120に配置するのが効率的であり、GPU200が頂点データを生成する場合は、頂点データをローカルメモリ220に配置するのが効率的である。ディスプレイスメントマッピング(displacement mapping)のようにテクスチャマッピングの手法で頂点位置を変位させる場合は、GPU200が頂点データを読み書きするため、頂点データをローカルメモリ220側に配置する方が効率的である。
このように、GPU200がメインメモリ120にもローカルメモリ220にもアクセスできる構成であることを利用して、テクスチャなどのグラフィックス演算に必要なデータをメインメモリ120および/またはローカルメモリ220に最適に分散配置して、テクスチャの転送速度を高め、グラフィックス処理の効率を上げることができる。
特に、GPU200が大きなサイズのポリゴンを描画するときなど、ローカルメモリ220に対してピクセルデータを大量に書き込む場合は、ローカルメモリ220に対する書き込みによりバス222が占有される。このような場合、メインメモリ120にテクスチャを配置して、IOIF110を経由してメインメモリ120からテクスチャを読み取ってテクスチャマッピングするのが効率的である。
上記の説明では、テクスチャをメインメモリ120、ローカルメモリ220のいずれかに配置したが、ローカルメモリ220に十分な容量がある場合、メインメモリ120とローカルメモリ220の両方にテクスチャを重複させて配置し、同一テクスチャをメインメモリ120とローカルメモリ220のどちらからでも読み取れるように構成してもよい。この構成によれば、ローカルメモリ220に対する書き込みアクセスが多発する状況では、メインメモリ120からテクスチャを読み取り、ローカルメモリ220に対する書き込みアクセスが少ない状況では、ローカルメモリ220からテクスチャを読み取るなど、ローカルメモリ220のバス222の輻輳状態に応じて、メインメモリ120とローカルメモリ220の間でテクスチャの読み取り先を切り替えることが可能である。シミュレーションなどによってテクスチャの最適な配置を決めることなく、アプリケーションの実行過程において、テクスチャの読み取り先をメインメモリ120とローカルメモリ220の間で動的に切り替えて転送効率を最適化することができるという利点がある。
図5は、グラフィックスライブラリ300が提供する機能を説明する図である。グラフィックスライブラリ300は、メモリ管理機能162、データ配置機能164、データ転送機能166などを提供するプログラム部品を1つのファイルにまとめたものである。これらのプログラム部品の機能をアプリケーション310から利用するためのアプリケーションプログラムインタフェース(API)がプログラマに提供されている。
メモリ管理機能162は、実効アドレス空間140におけるメモリ領域の実効アドレスとサイズの指定を受けて、そのメモリ領域をI/Oアドレス空間150にメモリマッピングする。データ配置機能164は、グラフィックス演算に必要なデータの内、メインメモリ120に格納すべきものを実効アドレス空間140のメモリ領域に格納する。データ転送機能166は、グラフィックス演算に必要なデータの内、メインメモリ120に配置せずに、ローカルメモリ220に配置すべきものをメインメモリ120から読み出し、ローカルメモリ220に転送する。
以上、本発明を実施の形態をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。そのような変形例を説明する。
実施の形態では、ポリゴン表面にテクスチャをマッピングするテクスチャマッピングを説明したが、ポリゴン表面にテクスチャ以外のデータをマッピングしてもよい。たとえば、法線ベクトルをマッピングするバンプマッピングの場合、法線ベクトルを格納した法線マップがテクスチャの代わりに用いられる。テクスチャ以外のマッピングデータについても実施の形態と同様に、メインメモリ120とローカルメモリ220に分散配置して、転送速度の効率化を図ることができることは言うまでもない。
IOIF110経由でメインメモリ120にアクセスするときのレーテンシーが長いため、CPU100のキャッシュメモリにメインメモリ120のデータをキャッシュすることでレーテンシーを短くすることができる。特にテクスチャの読み込みのために、CPU100にはテクスチャをキャッシュするためのテクスチャキャッシュが設けられてもよい。テクスチャキャッシュがCPU100に設けられていることから、より積極的にテクスチャをメインメモリ120に配置することで、IOIF110の帯域を活用した転送効率の改善を達成することができるようになる。
10 コマンドバッファ、 12、22 ジオメトリデータ、 14、24 テクスチャ、 16、26 シェーダプログラム、 20 フレームバッファ、 100 CPU、 110 IOIF、 120 メインメモリ、 122 バス、 140 実効アドレス空間、 150 I/Oアドレス空間、 162 メモリ管理機能、 164 データ配置機能、 166 データ転送機能、 200 GPU、 220 ローカルメモリ、 222 バス、 300 グラフィックスライブラリ、 310 アプリケーション。