(57)【特許請求の範囲】
【請求項１】
コンピュータシステム内のプロセッサによってコンピュータ・グラフィックス・シーン・データをジオメトリ・エンジンに送出する方法であって、
プロセッサが第１のシーン・データを生成するステップであって、前記第１のシーン・データは、関連するアプリケーション・コンテキストを各々が含む複数のブロックを含む、ステップと、
プロセッサが、前記第１のシーン・データをシステム・メモリ内の第１の中間バッファに書き込むステップと、
前記ジオメトリ・エンジンが、前記第１のシーン・データを前記第１の中間バッファから読み出すステップと、
前記ジオメトリ・エンジンが前記第１のシーン・データをレンダリングし、同時に前記プロセッサが第２のシーン・データを生成するステップと、
前記プロセッサが、前記第２のシーン・データを前記システム・メモリ内の第２の中間バッファに書き込むステップと、
前記ジオメトリ・エンジンが、前記第２のシーン・データを前記第２の中間バッファから読み出すステップと、
前記ジオメトリ・エンジンが前記第２のシーン・データをレンダリングするステップと
から成る送出方法。
【請求項２】
請求項１記載の方法において、前記第１のシーン・データは、自身のそれぞれのアプリケーションを実行する複数のプロセッサから生成される複数のブロックを含み、前記複数のブロックは集合的に単一のフレームとして解釈されることを特徴とする送出方法。
【請求項３】
請求項１記載の方法であって、前記第１のシーン・データは複数のアプリケーション・コンテキストを含み、各アプリケーション・コンテキストは複数のアプリケーションを参照し、前記複数のブロックは集合的に単一のフレームとして解釈されることを特徴とする送出方法。
【請求項４】
請求項１記載の方法において、前記第１のシーン・データのレンダリングは、
前記ジオメトリ・エンジンが、前記第１のシーン・データの第１のブロックの前記アプリケーション・コンテキストに従って前記第１のシーン・データの前記第１のブロックをレンダリングするステップと、
前記ジオメトリ・エンジンが前記第１のシーン・データの前記第１のブロックのレンダリングを中止するステップと、
前記ジオメトリ・エンジンが前記第１のシーン・データの前記第１のブロックの前記アプリケーション・コンテキストをセーブするステップと、
前記ジオメトリ・エンジンが前記第１のシーン・データの第２のブロックの前記アプリケーション・コンテキストをロードするステップと、
前記ジオメトリ・エンジンが、前記第１のシーン・データの前記第２のブロックの前記アプリケーション・コンテキストに従って、前記第１のシーン・データの前記第２のブロックをレンダリングするステップと
からなること、を特徴とする送出方法。
【請求項５】
請求項１記載の方法において、前記ジオメトリ・エンジンが前記第２のシーン・データを読み出す準備ができていることを前記プロセッサに示すために、前記ジオメトリ・エンジンがフラグを設定するステップをさらに含むこと、を特徴とする送出方法。
【請求項６】
プロセッサによってコンピュータ・グラフィックス・シーン・データをジオメトリ・エンジンへ送出するシステムであって、
第１の中間バッファ及び第２の中間バッファを含むシステム・メモリと、
前記システム・メモリと通信するプロセッサであって、第１のシーン・データを生成し前記第１のシーン・データを前記第１の中間バッファに送信するように構成され、前記第１のシーン・データは、関連するアプリケーション・コンテキストを各々が含む複数のブロックを含む、プロセッサと、
１組のグラフィックス・ハードウェア内の第１のモジュールを含み、前記プロセッサ及び前記システム・メモリと通信するジオメトリ・エンジンであって、前記プロセッサによる第２のシーン・データの生成とは独立して且つ同時に、前記第１の中間バッファから前記第１のシーン・データを読み出してレンダリングするように構成された、ジオメトリ・エンジンと、
を備えること、
を特徴とする送出システム。
【請求項７】
請求項６記載のシステムにおいて、前記プロセッサは、前記第２のシーン・データを生成して前記第２のシーン・データを前記第２の中間バッファへ送信するようにさらに構成され、前記ジオメトリ・エンジンは、前記第２の中間バッファから前記第２のシーン・データを読み出してレンダリングするようにさらに構成されることを特徴とする送出システム。
【請求項８】
請求項７記載のシステムにおいて、前記第１のシーン・データは、自身のそれぞれのアプリケーションを実行する複数のプロセッサから生成された複数のブロックを含み、前記複数のブロックは集合的に単一のフレームとして解釈されることを特徴とする送出システム。
【請求項９】
請求項８記載のシステムにおいて、前記ジオメトリ・エンジンは、前記第１のシーン・データの第１のブロックの前記アプリケーション・コンテキストに従って前記第１のシーン・データの前記第１のブロックをレンダリングし、前記第１のシーン・データの前記第１のブロックのレンダリングを中止し、前記第１のシーン・データの前記第１のブロックの前記アプリケーション・コンテキストをセーブし、前記第１のシーン・データの第２のブロックの前記アプリケーション・コンテキストをロードし、前記第１のシーン・データの前記第２のブロックの前記アプリケーション・コンテキストに従って前記第１のシーン・データの前記第２のブロックをレンダリングするようにさらに構成されることを特徴とする送出システム。
【請求項１０】
請求項７記載のシステムにおいて、前記第１のシーン・データは複数のアプリケーション・コンテキストを含み、各アプリケーション・コンテキストは複数のアプリケーションを参照し、前記複数のブロックは集合的に単一のフレームとして解釈されることを特徴とする送出システム。
【請求項１１】
コンピュータ上で実行されると請求項１乃至５のいずれかに記載の方法のすべてのステップを実行するコンピュータ実行可能命令を有するコンピュータ読取り可能な媒体。
【発明の詳細な説明】
【０００１】
【発明の背景】
（発明の分野）
本発明は、一般的にはコンピュータ・グラフィックスに関するものである。詳細には、本発明は、グラフィックス・データの収集並びにこのデータをグラフィックス・ハードウェアへ送出することに関するものである。
【０００２】
（関係する技術）
コンピュータ・グラフィックス・イメージの制作は、２つの基本的なステージから成っている。その第１のステージは、１つのフレームまたはシーンを指定するデータの生成であり、これは、以下ではシーン・データとして識別する。第２のステージは、グラフィックス・ハードウェアによって、このシーン・データに基づき、表示のためにイメージをレンダリングすることである。ある種の現行のコンピュータ・グラフィックス・システムは、１つのプロセッサを利用することによって、シーン・データの生成を扱い、そしてもう１つのプロセッサを利用してこのシーン・データをグラフィックス・ハードウェアへ送出するようにしている。これら２つのステージは、代表的には、交互にしかも直列的に生じる。シーン・データは、その第１のプロセッサが生成する。第２プロセッサは、次にそのシーン・データを、ジオメトリ・エンジン（geometry engine）、すなわちグラフィックス・ハードウェア・スーツ（graphics hardware suite）内の第１のモジュールに送出する。次に、第１プロセッサは、次のシーンのためのデータを生成し、そしてこのデータを第２プロセッサがジオメトリ・エンジンに対し送出する。このプロセスは、直列形式で続くことになる。
【０００３】
このアーキテクチャには、多くの欠点がある。第１に、上記２つのプロセッサの直列動作において本来的な非効率さがあることである。各プロセッサは、他方のプロセッサが活動するときにアイドル時間に遭遇する。このようなアイドル時間の間においては、利用可能な処理パワーは、使用されない。さらにまた、スループットが制限されることになる。１つのフレームは、シーン・データ生成ステージとデータ送出ステージの両方が順番に完了した後においてしか、ジオメトリ・エンジンは受けることができない。さらにまた、２つのプロセッサが必要となる。このことは、グラフィックス・システムの費用および複雑さの一因となる。
【０００４】
したがって、シーン・データの生成および伝送の集合的なプロセスを効率およびスループットの点から改善したグラフィックス・システム・アーキテクチャに対するニーズがある。加えて、このようなアーキテクチャは、計算パワーの必要量を最小限にするものとすべきである。
【０００５】
【発明の摘要】
本文に記述する本発明は、シーン・データをジオメトリ・エンジンに送出するための方法、システムおよびコンピュータ製品を構成する。プロセッサは、アプリケーション・プログラムにしたがって１つのフレームのためのシーン・データを生成し、そしてこのシーン・データを、以下において中間バッファとして識別する第１のメモリ・ロケーションに書き込む。その次のフレームのためのシーン・データを次に生成し、そして第２の中間バッファに書き込み、そしてこの間において、ジオメトリ・エンジンは、それと同時に、第１の中間バッファ内のシーン・データを読み出してレンダリングを行う。次に、後続のフレームのためのシーン・データを生成して第１中間バッファに書き込む一方で、ジオメトリ・エンジンは第２中間バッファ内のシーン・データを読み出してレンダリングを行う。このプロセスは、アプリケーション・プログラムが実行を終了するまで、上記のようにして継続する。
【０００６】
本発明は、シーン・データを読み取りそしてレンダリングする一方で、それと同時に追加のシーン・データを生成するという特徴を有している。
本発明は、シーン・データをパイプライン・アーキテクチャで生成しレンダリングするという追加の特徴を有している。
【０００７】
このパイプライン・アーキテクチャのため、本発明は、シーン・データの処理においてスループットが比較的高いという利点がある。
本発明は、さらに、シーン・データを生成することおよびこのシーン・データをジオメトリ・エンジンに対し利用可能とすることの双方を行うために１つのプロセッサしか必要としないという利点がある。
【０００８】
本発明のさらに別の特徴および利点、並びに本発明の種々の実施形態の動作については、添付の図面を参照して以下に詳細に説明する。
本発明の特徴および利点は、図面を参照しての以下に記載の詳細な説明からより明かとなる。尚、図面においては、同じあるいは機能的に類似の要素には同じ参照番号を使用する。さらに、参照番号の左端の数字は、この参照番号が最初に現れる図を示している。
【０００９】
【好ましい実施形態の詳細な説明】
Ｉ．概観
上述したように、現行のコンピュータ・グラフィックス・システムは、１つのプロセッサを使用することにより、このプロセッサ上でランしているアプリケーション・プログラムにしたがってシーン・データを生成している。第２のプロセッサは、この生成されたシーン・データをその第１プロセッサからジオメトリ・エンジンへ中継するという目的のために一般に割り当てられており、そしてこのジオメトリ・エンジンでは、そのシーン・データを表示イメージへ変換するプロセスが開始される。図１には、このようなアーキテクチャを示している。第１プロセッサ１０５は、アプリケーション１１０を実行することにより、プロセッサ１０５は、１つのフレームのためのシーン・データを生成する。このようにすることにおいて、プロセッサ１０５は、必要に応じてメモリ・ユニット１１５と相互作用する。プロセッサ１０５が生成するこのシーン・データは、次に、第２プロセッサ１１８によってジオメトリ・エンジン１２５へ転送する。プロセッサ１０５からジオメトリ・エンジン１２５へシーン・データ１２０を転送するのは、プロセッサ１１８の担当である。
【００１０】
図２には、このようなアーキテクチャから生ずるイベントのシーケンスを示している。これらイベントは、時間２０５の関数として示している。イベント２１０においては、第１プロセッサは、フレームframenに対応するシーン・データを生成する。イベント２１５においては、第２プロセッサは、framenのシーン・データをジオメトリ・エンジンに送出する。イベント２２０においては、第１プロセッサは、その次のフレームframen+1のためのシーン・データを生成する。イベント２２５においては、第２プロセッサは、framen+1に属するシーン・データをジオメトリ・エンジンに送出する。以上のプロセスは、直列形式で続行する。各シーン・データ生成イベントには、第２プロセッサがそのシーン・データをジオメトリ・エンジンに送出するイベントが直列で後続する。このプロセスは、各々の連続したフレームに対し繰り返される。
【００１１】
本発明においては、第２プロセッサは不要となる。単一のプロセッサによって、シーン・データを生成し、そしてこのシーン・データをメモリ内の中間バッファに転送する。次に、このプロセッサは、ジオメトリ・エンジンに対し命令を発してそのシーン・データを検索する。こうすることにおいては、そのプロセッサは、ジオメトリ・エンジンに対し中間バッファのメモリ内におけるアドレスを送る。ジオメトリ・エンジンは次に、その指示したアドレスからシーン・データを検索する。
【００１２】
ジオメトリ・エンジンがシーン・データを検索しそしてそのシーン・データについての必要なレンダリングを実行している間、プロセッサは、次のフレームのためのシーン・データを生成していることになる。これが完了すると、その次フレームのためのシーン・データは、プロセッサが第２の中間バッファに対し送出する。一旦メモリへのこの転送が完了し、グラフィックス・ハードウェアが第１中間バッファからのシーン・データのレンダリングを終了すると、プロセッサは、別の読み取り命令をジオメトリ・エンジンに対し発する。ジオメトリ・エンジンは、第２中間バッファ・ロケーションからシーン・データの次のセグメントを読み取ることに進む。
【００１３】
ジオメトリ・エンジンがこれを行う間、プロセッサは、第３のフレームのためのシーン・データを生成し、このシーン・データを第１メモリ・ロケーション内に置く。このプロセスは続行し、シーン・データ生成が、シーン・データの読み取りおよびレンダリング動作と並行してかつ同時に進行する。したがって、グラフィックス・ハードウェアが１フレームのシーン・データを読み取りそしてレンダリングする間においては、プロセッサは、それに続くフレームのためのシーン・データを生成している。その結果、シーン・データの生成およびこのシーン・データのグラフィックス・ハードウェアへの転送という集合的なプロセスは、より効率的となる。これら集合的プロセスは、パイプライン化され、そしてスループットが上昇する。さらにまた、１つのプロセッサしか使用しない。
ＩＩ．用語
以下のセクションでは、本願を通して頻繁に現れるいくつかの用語を定義する。
【００１４】
アプリケーションとは、ここでは、プロセッサが実行する一連の命令を記述するために広義に使用する。コンピュータ・グラフィックスのコンテキストにおいては、この用語は、一連の命令であって、実行されたときに、１つのイメージ、１つのイメージの一部、または一連のイメージを形成するようにレンダリングすることができるデータを発生するようなそのような一連の命令を指す。
【００１５】
フレームとは、１つのセグメントのデータであって、レンダリング・プロセスに入力したときに、１つのイメージまたは１つのイメージの一部を発生するようなそのような１つのセグメントのデータを指す。
【００１６】
ジオメトリ・エンジンとは、レンダリング・プロセスにおいて最初のステップを実行するハードウェア・コンポーネントを指す。これらステップは、ジオメトリ計算、ライティング計算、遠近法計算、ピクセルのカラー処理を含むことができる。ジオメトリ・エンジンの出力は、ラスタ化できるデータから成る。
【００１７】
中間バッファとは、メモリ媒体内の１つのロケーションであって、本発明の１実施形態にしたがいシーン・データをその生成の直後に格納することができるそのような１つのロケーションを指す。中間バッファは、シーン・データ格納のため、およびジオメトリ・エンジンによるそのデータの係属中の後続のアクセスのための一時的ロケーションとして作用する。
【００１８】
シーン・データとは、プロセッサによるアプリケーションの実行により生成されるデータを指す。シーン・データは、レンダリング・プロセスを開始するためにジオメトリ・エンジンに入力され、そして実際にイメージへとレンダリングされる。
ＩＩＩ．システム
Ａ．全体
図３には、本発明の１実施形態を示している。プロセッサ３０５は、アプリケーション１１０をロードしているとして示している。アプリケーション１１０は、グラフィックス・ハードウェアをプログラミングするのに適当ないくつかの言語のうちの任意のもので書くことができる。１つのそのような言語は、ＯｐｅｎＧＬ（登録商標）である。アプリケーション１１０を実行する際、プロセッサ３０５は、シーン・データ１２０を生成する。本発明の１実施形態では、これは、一回に１つのシーンまたはフレームずつ行う。シーン・データ１２０は、表示されるフレームを最終的に構成することになるオブジェクトおよびフィーチャの記述を含む。もしＯｐｅｎＧＬ（登録商標）を使用する場合、シーン・データ１２０は、表示リストから構成される。所与のフレームに関連するシーン・データ１２０は、一旦生成されると、メモリ・モジュール１１５へ転送する。特に、そのフレームに対するシーン・データ１２０は、メモリ１１５内の中間バッファとして識別する複数の特定のロケーションのうちの１つに書き込む。
【００１９】
プロセッサ３０５は、命令３１５をジオメトリ・エンジン３１０に発する。ジオメトリ・エンジン３１０は、レンダリング・プロセスを開始させることを担当し、そして１つのシーンを最終的に形成することになるジオメトリ上のエンティティの初期操作としてそのようなタスクを実行する。命令３１５は、ジオメトリ・エンジン３１０に対し、シーン・データ１２０をメモリ１１５から読み取るように知らせる。さらにまた、命令３１５は、シーン・データ１２０を見い出すことができる中間バッファのアドレスを、ジオメトリ・エンジン３１０に知らせる。このとき、ジオメトリ・エンジン３１０は、シーン・データ１２０をメモリ１１５内のその指定された中間バッファから検索する。
【００２０】
Ｂ．メモリ
図４には、本発明の１実施形態によるメモリ１１５の構造を詳細に示している。メモリ１１５は、２つの中間バッファ４０５Ａ，４０５Ｂから構成されている。プロセッサ３０５は、フレーム毎にシーン・データを生成するが、このプロセッサは、最初に、フレーム４１５に関連するシーン・データを生成する。プロセッサ３０５は、フレーム４１５に関連したシーン・データを中間バッファ４０５Ａに送出する。ジオメトリ・エンジン３１０は、次に、フレーム４１５に関連したこのシーン・データに対し中間バッファ４０５Ａからのアクセスを、プロセッサ３０５によってそうするように言われたときに行うことができる。中間バッファ４０５Ａがアクセスされそしてそのシーン・データがレンダリングされている間においては、プロセッサ３０５は、次のフレーム４２０に関連するシーン・データを生成する。プロセッサ３０５は、フレーム４２０に関連するそのシーン・データを中間バッファ４０５Ｂに書き込むことになる。
【００２１】
次のステップ（不図示）では、ジオメトリ・エンジン３１０は、フレーム４２０に関連したシーン・データを中間バッファ４０５Ｂから読み取る。これを行っている間においては、プロセッサ３０５は、その次のフレームに対するシーン・データを生成し、そしてそのシーン・データを中間バッファ４０５Ａに書き込む。以上のプロセスは、この形式で続くことになる。したがって、プロセッサ３０５は、中間バッファ４０５Ａと中間バッファ４０５Ｂとに対し交互に書込を行う。ジオメトリ・エンジン３１０は、プロセッサ３０５が現在アドレス指定していないどちらかの中間バッファからシーン・データを読み出す。これは、以下で詳述するパイプライン化したデータ・フローをもたらす。
【００２２】
ここで、本発明の代替の実施形態では、２つより多い中間バッファを使用することもできる。例えば、ジオメトリ・エンジンが第２の中間バッファからの読み取りを終了する前にプロセッサが第１の中間バッファへの書込を終了する場合、このときには、プロセッサは、次のフレームに対するシーン・データを書き込む場所がないことになる。このような状態を取り扱うため、３つ以上の中間バッファを使用することによって、本発明のパイプライン・プロセスをサポートするようにすることができる。
【００２３】
Ｃ．  シーン・データ構造
図５Ａおよび図５Ｂには、本発明の１実施形態によるシーン・データのための可能なフォーマットを記載している。図５Ａにおいて、１つのフレームに対するシーン・データを示している。このシーン・データは、複数のオブジェクト記述から構成されている。第１の記述は、オブジェクト５０５を定めている。同様に、第２および第３のオブジェクト記述は、それぞれ、オブジェクト５１０，５１５を定めている。各オブジェクト記述内のデータは、ジオメトリ・エンジンを含むこのグラフィックス・システムが、そのオブジェクトに対応するフレームの部分のレンダリングを開始するのに十分な情報を含んでいる。一連の明示的なオブジェクト記述から成るシーン・データは、フラット構造をもつと言える。
【００２４】
対照的に、図５Ｂは、例示の階層的構造を示している。ここで、シーン・データ５５０は、オブジェクト５５５のようなオブジェクトの記述を含んでいる。しかし、階層的構造においては、シーン・データはまた、ポインタ５６０，５７０，５７５のようなポインタも含み、これは、メモリ内のどこか他の所のオブジェクト記述を参照する。図示した例では、ポインタ５６０は、メモリ内のどこか他の所に記述されたオブジェクト、すなわちオブジェクト５６５に対する参照として作用する。同様に、ポインタ５７０も、オブジェクト５６５を参照する。ポインタ５７５は、別のオブジェクト５８０を参照する。オブジェクト５６５とオブジェクト５８０の記述は、プロセッサが中間バッファに書き込むシーン・データ内に明示的には含まれていない。したがって、中間バッファに書き込まれたシーン・データ５５０は、オブジェクト５５５，ポインタ５６０，５７０，５７５を含む。シーン・データ５５０は、オブジェクト５５５，５６５，５６５（再度），５８０の明示的記述から成るシーン・データと等価である。ポインタは明示的オブジェクト記述よりも少ないメモリ空間しか必要としないため、階層的構造のシーン・データは、１つのシーンのよりコンパクトな表現となる。
【００２５】
Ｄ．多数のプロセッサおよびシーン生成
本発明の代替の実施形態においては、複数のプロセッサが、各々のそれら自身のアプリケーションを実行する。このような実施形態では、プロセッサは全て、それら自身のシーン・データを単一の中間バッファへ書き込む。その結果生じる複数のシーン・データ・ブロックは、集合的に、単一のフレームとして解釈される。図６には、例示の実施形態を示している。ここで、複数のプロセッサ、すなわちプロセッサ６０５Ａ，６０５Ｂ，６０５Ｃを示している。各プロセッサは、それ自身のシーン・データを中間バッファ６０１Ｂに書き込む。シーン・データ６１０Ａはプロセッサ６０５Ａが提供し、シーン・データ６１０Ｂはプロセッサ６０５Ｂが提供し、シーン・データ６１０Ｃはプロセッサ６０５Ｃが提供する。これらシーン・データのブロックは、図５Ａおよび図５Ｂに示したようにフラットまたは階層的のいずれかとすることができる。
【００２６】
図６の実施形態においては、図４に示したシーケンスと同様に、パイプライン化した動作シーケンスが生じる。プロセッサ６０５Ａ〜６０５Ｃがシーン・データを生成しそしてこれを中間バッファ６０１Ｂに書き込んでいる間、ジオメトリ・エンジン１２５は、中間バッファ６０１Ａの内容を読み取っており、この中間バッファは、プロセッサ６０５Ａ〜６０５Ｃが前のステップにおいて書き込んだシーン・データを含んだものである。中間バッファ６０１Ａ内のこのシーン・データがレンダリングされ、そしてプロセッサ６０５Ａ〜６０５Ｃがそれらのシーン・データの中間バッファ６０１Ｂへの書込を完了した後、ジオメトリ・エンジン１２５は、中間バッファ６０１Ｂ内のこのシーン・データを読み取ることになる。一方では、プロセッサ６０５Ａ〜６０５Ｃは、次のフレームのためのシーン・データを生成することになる。このシーン・データは、中間バッファ６０１Ａに書き込まれる。動作は、全てのシーン・データが生成され処理されるまでこのようにして続く。
【００２７】
尚、図６の各プロセッサは、それ自身の個々のアプリケーション・プログラムを実行しているため、中間バッファ６０１Ｂにおいて記述されたフレームにおいて表されるいくつかの異なったコンテキストがあることになる。中間バッファ６０１Ｂ内のデータが読み取られそしてグラフィックス・ハードウェアによってレンダリングされるとき、多数のコンテキストを扱わなければならない。その結果、ジオメトリ・エンジン１２５は、１つのブロックのシーン・データのレンダリングを完了しそして別のものを開始するとき、必要なコンテキスト・スイッチングを実行する能力を有していなければならない。
ＩＶ．方法
Ａ．全体
本発明の方法は、２組のプロセスの並列実行を提供する。グラフィックス・ハードウェアは、所与のフレームに対しプロセッサが生成したシーン・データを読み取りレンダリングする間、このプロセッサは、次フレームのためのシーン・データを生成しそしてこれをメモリに書き込む。このようにして、シーン・データの生成は、前に生成したシーン・データの読み取りおよびレンダリングの間において実行される。このパイプライン・アプローチは、グラフィックス・システムにおけるより大きなスループットを可能にし、そしてリソースの効率的な使用を提供する。
【００２８】
図７には、これらイベントのタイムラインを示している。イベント７１０においては、プロセッサは、フレームframenに関連したシーン・データを生成し、そしてこれをメモリ内の中間バッファに書き込む。イベント７１５においては、プロセッサは、フレームframen+1に関連したシーン・データを生成し書込を行う。イベント７２０では、プロセッサは、フレームframen+2に関連したシーン・データを生成し書込を行う。シーン・データ生成イベント７１０〜７２０と並行して、シーン・データをグラフィックス・ハードウェアがメモリから読み取りそしてレンダリングする。イベント７１０においてプロセッサがフレームframenに関連したシーン・データを生成し書き込んでいる間、ジオメトリ・エンジンも活動している。この時点で、イベント７２５において、ジオメトリ・エンジンは、メモリ内の中間バッファからフレームframen-1に関連したシーン・データを読み取っている最中である。同様に、プロセッサがフレームframen+1に関連したシーン・データを生成し書き込んでいる間、グラフィックス・ハードウェアは、イベント７３０において、フレームframenに対して先に生成されたシーン・データを読み取りそしてレンダリングをしている最中となる。同様に、イベント７１５において生成したシーン・データを、イベント７３５においてグラフィックス・ハードウェアが読み取りレンダリングする。この後者のイベントは、プロセッサがイベント７２０において次フレームframen+2に関連したシーン・データを生成している間に生じる。
【００２９】
図８には、本発明の１実施形態によるこのプロセスの各ステップをより詳細に示している。このプロセスは、ステップ８０５で始まる。ステップ８１０においては、本プロセスで使用するどのフラグまたはインデックスも適当な初期値にセットする。以下で述べるように、このようなフラグは、種々のタスクの完了を知らせるために使用することができる。ステップ８１５においては、第１のフレームすなわちframe0に対するシーン・データを、図８においてバッファＡとして示した第１の中間バッファにおいて利用可能となるようにする。このステップでは、プロセッサは、シーン・データを生成しそしてこのシーン・データをメモリ内のバッファＡに書き込む。
【００３０】
ステップ８１５の後、２つのイベントが、ほぼ同時期に生起する。ステップ８２０では、バッファＡに丁度書き込んだシーン・データを、ジオメトリ・エンジンがその中間バッファから読み取り、そしてグラフィックス・ハードウェアがレンダリングする。その間、ステップ８２５において、プロセッサは、次のフレームすなわちframe1に関連したシーン・データを生成し、そしてこれを第２の中間バッファ（図８ではバッファＢとして示す）に書き込む。
【００３１】
一旦ステップ８２５が完了し、またグラフィックス・ハードウェアがバッファＡからのシーン・データのレンダリングを終了すると、ステップ８３０が生じる。このステップでは、frame1に関連したシーン・データは、ジオメトリ・エンジンがバッファＢから読み取り、そしてグラフィックス・ハードウェアがレンダリングする。これは、ステップ８２５において利用可能とされたシーン・データである。一方、ステップ８３５において、プロセッサは、次にフレームframe2に関連したシーン・データを生成する。ステップ８３５では、プロセッサはまた、このシーン・データを中間バッファＡに書き込む。
【００３２】
ステップ８４０では、frame2に関連したシーン・データは、ジオメトリ・エンジンがバッファＡから読み取り、そしてグラフィックス・ハードウェアがレンダリングする。この間、ステップ８４５においては、プロセッサが、次のフレームframe3に関連したシーン・データを生成する。プロセッサは、このシーン・データをバッファＢにおいて利用可能とする。
【００３３】
ステップ８５０においては、フレームframe3に関連したシーン・データは、ジオメトリ・エンジンがバッファＢから読み取り、そしてグラフィックス・ハードウェアがレンダリングする。このプロセスは、本アプリケーションがプロセッサにおける実行を完了するまで、並列のパイプライン形式で続行する。
【００３４】
Ｂ．シーン・データの生成およびメモリへの書込
図９には、プロセッサがシーン・データをメモリにおいて利用可能とするステップ（ステップ８１５，８２５，８３５，８４５）をより詳細に示している。このプロセスは、ステップ９００で開始する。ステップ９０５において、プロセッサは、フレームframenに対するシーン・データを生成する。ステップ９１０において、framenシーン・データを書き込むべき中間バッファからジオメトリ・エンジンが読み取りを終了したかどうか、判定を行う。本発明の１実施形態では、この判定は、フラグのシステムを使用することによって行うことができ、そしてそれらフラグは、ジオメトリ・エンジンの読み取り動作の状態に依存してセットしたりリセットしたりする。ジオメトリ・エンジンがそのバッファからの読み取りを終了していない場合、ステップ９１５において、本プロセスは、ジオメトリ・エンジンがそのように行うのを完了するまで待機する。ジオメトリ・エンジンがそのバッファからの読み取りを終了したときに、ステップ９２０において、本プロセスは、フレームframenに関連したシーン・データをそのバッファに書き込むことに進む。このプロセスは、ステップ９２５で終了する。
【００３５】
Ｃ．シーン・データの読み取りおよびレンダリング
図１０には、ジオメトリ・エンジンがシーン・データを読み取りそしてレンダリングする図８のステップ（ステップ８２０，８３０，８４０，８５０）をより詳細に示している。このプロセスは、ステップ１０００で開始する。ステップ１００５において、ジオメトリ・エンジンがシーン・データを中間バッファから読み取る準備ができているかどうか、判定を行う。ジオメトリ・エンジンは、例えば、別のメモリ・ロケーションからの読み取りを依然として行っている最中であることがある。この場合、ジオメトリ・エンジンは、この現在のバッファからの読み取りの準備がまだできていないことになる。したがって、ステップ１０１０において、本プロセスは、ジオメトリ・エンジンがそのバッファからの読み取りの準備ができるまで待機しなければならない。ジオメトリ・エンジンの準備ができたとき、ステップ１０１５において、プロセッサは、ジオメトリ・エンジンに対し、フレームframenに関連するシーン・データ読み取りを行いそしてそのレンダリングを開始するよう知らせる。こうする際、プロセッサは、そのメモリ・アドレス、すなわちジオメトリ・エンジンがシーン・データを読み取るべきバッファ・ロケーションを指定する。本発明の１実施形態においては、ジオメトリ・エンジンがシーン・データの読み取りの準備ができているかどうかの判定は、フラグのシステムを使用して行うことができ、そしてそれらフラグは、ジオメトリ・エンジンの読み取りに対する準備の状態に依存してセットしたりリセットしたりする。ステップ１０２０では、ジオメトリ・エンジンは、バッファからフレームframenに関連するシーン・データの読み取り、そしてそのレンダリングを開始する。本プロセスは、ステップ１０２５で終了する。
【００３６】
Ｄ．マルチ・スレッドおよびコンテキスト・スイッチング
ＯｐｅｎＧＬ（登録商標）のような状態ベースのアプリケーション言語が使用されている場合、シーン・データのレンダリングにおける任意の所与の時点において、ある特定のコンテキストが有効となる。シーン・データのこのコンテキストは、現行のカラーあるいは現行のポリゴンの描画モードのような状態変数の現行の値を指し、そしてこれは、アプリケーションにより定義される。
【００３７】
上述のように、本発明のある種の実施形態は、複数のプロセッサを備え、その各々は、それ自身のそれぞれのアプリケーションを実行する。ある所与のプロセッサは、このプロセッサがマルチタスキング能力をもつ場合には、多数のアプリケーションを実行することもできる。各アプリケーションは、それ自身のシーケンスの命令を有しているため、各アプリケーションは、それ自身のスレッドを有すると言える。このような実施形態では、複数のブロックのシーン・データを、１つの中間バッファに書き込む。このシーン・データの各ブロックは、互いに集合的に１つのフレームのためのシーン・データを表す。各アプリケーションまたはスレッドは、それ自身のコンテキストを定めるため、グラフィックス・ハードウェアは、それら複数のシーン・データ・ブロックにおいて表される複数のコンテキストを認識していなければならない。さらにまた、グラフィックス・ハードウェアは、１つのアプリケーションからの１つのシーン・データ・ブロックをレンダリングするときに、必要なコンテキスト・スイッチングを扱い、そして次に別のブロックに移ることができなければならない。
【００３８】
図１１には、本発明の１実施形態によるコンテキスト・スイッチングのプロセスを示している。図示した例示のシナリオでは、シーン・データのブロックblockiが終了し、そしてブロックblockjが開始する。ブロックblockiとblockjは、別々のアプリケーションを実行している別々のプロセッサが発生したものである。その結果、ブロックblockiとblockjは、異なったコンテキストを有している可能性があり、したがってジオメトリ・エンジンは、コンテキストをスイッチングできなければならない。このプロセスは、ステップ１１０５で開始する。ステップ１１１０では、ブロックblockiのレンダリングを中止させる。ステップ１１１５では、ブロックblockiのコンテキストをセーブする。ステップ１１２０では、ブロックblockjのコンテキストをロードする。ステップ１１２５では、ブロックblockjのレンダリングを開始させる。このプロセスは、ステップ１１３０で終了する。
【００３９】
Ｖ．環境
上述のように、本発明は、コンピュータ・グラフィックス・システムの上記セッティングで動作し、そしてこれは、ハードウェア、ファームウェア若しくはソフトウェアまたはこれらの組み合わせによって実現することができる。図１２には、そのようなシステムのより完全な例を示している。この説明を読めば、本発明を、他のコンピュータ・システムおよび／またはコンピュータ・アーキテクチャを使用して実現する方法が当業者には明かとなる。
【００４０】
コンピュータ・システム１２００は、プロセッサ３０５のような１つまたはそれより多いプロセッサを備えている。プロセッサ３０５は、バスまたはネットワークのような通信インフラストラクチャ１２０６に接続している。また、コンピュータ・システム１２００は、メモリ１１５も備え、これは好ましくはランダム・アクセス・メモリ（ＲＡＭ）である。プロセッサ３０５は、通信インフラストラクチャ１２０６を使用することによって、メモリ１１５と通信する。コンピュータ・システム１２００はまた、二次メモリ１２１０を備えることもできる。二次メモリ１２１０は、例えば、ハードディスク・ドライブ１２１２と、フロッピ・ディスク・ドライブ、磁気テープ・ドライブ、光ディスク・ドライブ等を表すリムーバブル・ストレージ・ドライブ１２１４との一方または双方を備えることもできる。リムーバブル・ストレージ・ドライブ１２１４は、リムーバブル・ストレージ・ユニット１２１８に対する読み出しおよび書き込みの一方または双方を周知の方法で行う。リムーバブル・ストレージ・ユニット１２１８は、フロッピ・ディスク、磁気テープ、光ディスクまたはその他のストレージ媒体を表しており、これらは、リムーバブル・ストレージ・ドライブ１２１４によって読み出しおよび書き込みを行う。理解されるように、リムーバブル・ストレージ・ユニット１２１８は、コンピュータが使用可能なストレージ媒体であってこの中にコンピュータ・ソフトウェアおよびデータの一方または双方を格納したものを含む。
【００４１】
代替の実現例においては、二次メモリ１２１０は、コンピュータ・プログラムまたは他の命令をコンピュータ・システム１２００にロードできるようにするための他の手段を備えることもできる。このような手段は、例えば、リムーバブル・ストレージ・ユニット１２２２およびインターフェース１２２０を備えることもできる。このような手段の例には、プログラム・カートリッジおよびカートリッジ・インターフェース（例えば、ビデオゲーム・デバイスにおいて見られるもの）、リムーバブル・メモリ・チップ（例えばＥＰＲＯＭまたはＰＲＯＭ）および関連するソケット、並びに他のリムーバブル・ストレージ・ユニット１２２２およびインターフェース１２２０を備えることもでき、そしてこれらは、ソフトウェアおよびデータをリムーバブル・ストレージ・ユニット１２２２からコンピュータ・システム１２００へ転送することができるようにする。
【００４２】
上述の本発明の実施形態は、メモリ１１５中に実現した中間バッファを特徴に有しているが、中間バッファは代替的には、二次メモリ１２１０において実現することもできる。
【００４３】
また、コンピュータ・システム１２００は、通信インターフェース１２２４を備えることもできる。通信インターフェース１２２４は、ソフトウェアおよびデータをコンピュータ・システム１２００および外部デバイスに転送することができるようにする。通信インターフェース１２２４の例には、モデム、ネットワーク・インターフェース（例えばイーサーネット・カード）、通信ポート、ＰＣＭＣＩＡスロットおよびカード等が含まれ得る。通信インターフェース１２２４を介して転送するソフトウェアおよびデータは、信号１２２８の形態であり、そしてその信号は、通信インターフェース１２２４により受け取られ得る電子信号、電磁的信号、光信号その他の信号とすることができる。これら信号１２２８は、通信インターフェース１２２４に対し通信経路（すなわちチャンネル）１２２６を介して送る。このチャンネル１２２６は、信号１２２８を運び、そしてこれは、ワイヤまたはケーブル、光ファイバ、電話回線、セルラ電話回線、ＲＦリンクおよび他の通信チャンネルを使用して実現することもできる。本発明の１実施形態では、ジオメトリ・エンジン３１０は、プロセッサ３０５から通信インターフェース１２２４および通信経路１２２６を介して命令を受け取る。本発明の１実施形態では、ジオメトリ・エンジン３１０はまた、シーン・データ１２０をメモリ１１５から通信インターフェース１２２４および通信経路１２２６を介して受け取る。
【００４４】
本明細書においては、用語“コンピュータ・プログラム媒体”および“コンピュータ使用可能媒体”は、リムーバブル・ストレージ・ユニット１２１８，１２２２、ハードディスク・ドライブ１２１２にインストールするハードディスクのような媒体および信号１２２８を一般に指すよう使用している。これらコンピュータ・プログラム製品は、ソフトウェアをコンピュータ・システム１２００に提供するための手段である。
【００４５】
コンピュータ・プログラム（コンピュータ制御ロジックとも呼ぶ）は、メモリ１１５および二次メモリ１２１０の一方または双方に格納する。コンピュータ・プログラムはまた、通信インターフェース１２２４を介して受け取ることもできる。このようなコンピュータ・プログラムは、実行されたときには、コンピュータ・システム１２００が上述の本発明を実施できるようにする。特に、コンピュータ・プログラムは、実行されたときには、プロセッサ３０５が、本発明を実施することができるようにする。したがって、このようなコンピュータ・プログラムは、コンピュータ・システム１２００のコントローラを表している。本発明がソフトウェアを使用して実現される場合、このソフトウェアは、コンピュータ・プログラム製品に格納し、そしてリムーバブル・ストレージ・ドライブ１２１４、ハード・ドライブ１２１２または通信インターフェース１２２４を介してコンピュータ・システム１２００へロードするようにすることもできる。本発明の１実施形態では、アプリケーション・プログラム１１０は、ソフトウェアで実現し、そしてこのためそれら手段の任意のものを介してプロセッサ３０５にとって利用可能なものとすることができる。
【００４６】
ＶＩ．結び
以上、本発明の種々の実施形態について説明したが、理解されるべきように、それらは例示のために提示したものであって限定するためのものではない。当業者には明らかなように、本発明の要旨および範囲から逸脱せずに細部において種々の変更を行うことができる。したがって、本発明は、上述の例示の実施形態によって限定されるべきものではなく、添付の特許請求の範囲によってまたその均等物によって定められるべきものである。
【図面の簡単な説明】
【図１】  図１は、現行技術によるコンピュータ・グラフィックス・システムのアーキテクチャを示すブロック図。
【図２】  図２は、図１に示したタイプのコンピュータ・グラフィックス・システムから生ずるイベントのシーケンスを示すタイミング図。
【図３】  図３は、本発明に１実施形態による、コンピュータ・グラフィックス・システムのアーキテクチャを示すブロック図。
【図４】  図４は、本発明の１実施形態による、プロセッサとジオメトリ・エンジンと中間バッファとの間の相互作用を示すブロック図。
【図５】  図５Ａは、本発明の１実施形態による、中間バッファ内に含まれたシーン・データのフラット編成を示すブロック図。
図５Ｂは、本発明の１実施形態による、中間バッファ内および他のメモリ・ロケーション内に含まれたシーン・データの階層的編成を示すブロック図。
【図６】  図６は、本発明の１実施形態による、多数のプロセッサとジオメトリ・エンジンと中間バッファとの間の相互作用を示すブロック図。
【図７】  図７は、本発明の１実施形態による、プロセッサによるシーン・データ生成と、グラフィックス・ハードウェアによるシーン・データの読み取りおよびレンダリングとの間の関係を示すタイミング図。
【図８】  図８は、本発明の１実施形態の全体の動作を示すフローチャート。
【図９】  図９は、本発明の１実施形態による、シーン・データをジオメトリ・エンジンに利用可能とするプロセスを示すフローチャート。
【図１０】  図１０は、本発明の１実施形態による、シーン・データの読み取りおよびレンダリングのプロセスを示すフローチャート。
【図１１】  図１１は、本発明の１実施形態による、コンテキスト・スイッチングのプロセスを示すフローチャート。
【図１２】  図１２は、本発明の計算環境を示すブロック図。
【図１】
0004497445.tif 000002
【図２】
0004497445.tif 000003
【図３】
0004497445.tif 000004
【図４】
0004497445.tif 000005
【図５】
0004497445.tif 000006
【図６】
0004497445.tif 000007
【図７】
0004497445.tif 000008
【図８】
0004497445.tif 000009
【図９】
0004497445.tif 000010
【図１０】
0004497445.tif 000011
【図１１】
0004497445.tif 000012
【図１２】
0004497445.tif 000013