JP4691493B2 - マルチプロセッサ・グラフィックス処理システムの適応型負荷分散 - Google Patents

Description

関連出願

（関連出願の相互引用）
本開示は、本出願と同日に出願された「Ｐｒｉｖａｔｅ Ａｄｄｒｅｓｓｉｎｇ ｉｎ ａ Ｍｕｌｔｉ−Ｐｒｏｃｅｓｓｏｒ Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｓｙｓｔｅｍ」という表題の同一出願人による同時係属米国特許出願第＿＿＿＿＿号（整理番号０１９６８０−００６０００ＵＳ）および＿＿年＿＿月＿＿日に出願された「Ｐｒｏｇｒａｍｍｉｎｇ Ｍｕｌｔｉｐｌｅ Ｃｈｉｐｓ ｆｒｏｍ ａ Ｃｏｍｍａｎｄ Ｂｕｆｆｅｒ」という表題の同一出願人による同時係属米国特許出願第＿＿＿＿＿号（整理番号０１９６８０−００５９００ＵＳ）に関係し、それぞれの開示は、あらゆる目的に関して参照により本明細書に組み込まれる。

本発明は、一般に、複数のプロセッサを備えるグラフィックス処理サブシステムに関するものであり、とりわけ、グラフィックス処理サブシステムの適応型負荷分散に関するものである。

グラフィックス処理サブシステムは、リアルタイムで、例えば、毎秒３０フレーム以上で、リアルな動画をレンダリングするように設計されている。これらのサブシステムは、コンピュータ・システムのマザーボード上の適切に構成されたスロット内に差し込むことができる拡張カードに実装されることが最も多く、一般的には、１つまたは複数の専用グラフィックス処理ユニット（ＧＰＵ）と専用グラフィックス・メモリを備える。典型的なＧＰＵは、グラフィックス計算（例えば、行列変換、走査変換、および／またはその他のラスター化技術、テクスチャ合成など）を実行し、それらの結果をグラフィックス・メモリに書き込むように最適化された非常に複雑な集積回路デバイスである。ＧＰＵは、「マスター」プロセッサ、一般的にはシステムの中央演算処理装置（ＣＰＵ）上で実行されるドライバ・プログラムから受け取ったコマンドに応答して動作する「スレーブ」プロセッサである。

現実性と速度の要求条件を満たすために、一部のＧＰＵが含むトランジスタ数は、典型的ＣＰＵに比べて多い。さらに、グラフィックス・メモリは、システム上のトラフィックを少なくすることにより速度を改善するために極めて大きくなっており、現在では一部のグラフィックス・カードは、２５６ＭＢ程度のメモリを搭載する。しかし、このように進歩してきたにも関わらず、なおいっそうの現実性と高速なレンダリングに対する需要が根強い。

このような需要に応じるアプローチの１つとして、一部のメーカーでは、通常は同じカード上にある２つ以上のＧＰＵが並列動作する「マルチ・チップ」グラフィックス処理サブシステムの開発を開始している。並列オペレーションでは、ＧＰＵの設計を著しく高度な設計にしなくても、１秒当たり実行可能なレンダリング・オペレーションの回数を実質的に増やすことができる。ＧＰＵ間のリソース衝突を最小にするため、それぞれのＧＰＵに対し、ＧＰＵがレンダリングするピクセル・データを書き込むディスプレイ・バッファを含む、それ専用のメモリ領域を用意するのが一般的である。

マルチ・チップ・システムでは、処理の負荷を、様々な方法で複数のＧＰＵ間に分割することができる。例えば、それぞれのＧＰＵに対し、ラスター・ベースのディスプレイの多数のラインなど、表示可能な画像の異なる部分についてピクセル・データをレンダリングするよう命令することができる。画像は、適切な順序でそれぞれのＧＰＵのディスプレイ・バッファからピクセル・データを読み出すことにより表示される。より具体的な例として、グラフィックス処理サブシステムは、２つのＧＰＵを使用して、Ｍ行分のピクセル・データからなる表示可能画像を生成することができ、第１のＧＰＵに対し１からＰまでの行をレンダリングすることを命令することができ、その一方で、第２のＧＰＵに対しＰ＋１からＭまでの行をレンダリングすることを命令することができる。表示される画像の内部的一貫性（「フレーム・コヒーレンス」）を保つため、他のＧＰＵが現在のフレームを終了して、表示される画像の両方の部分が同じスキャンアウト・パスで更新されるまで、各ＧＰＵは後続のフレームをレンダリングできないようにされる。

理想的には、表示領域（または画面）は、それぞれのＧＰＵが画像のその部分をレンダリングするのに等しい時間を要するように分割される。レンダリング時間が等しくない場合、フレームのその部分を終了するＧＰＵが最初にアイドル状態になり、貴重な計算リソースを無駄にする。一般に、単純に表示領域を複数のＧＰＵ間に均等分割することは、画像の異なる部分のレンダリング複雑度が大きく変化する場合があるため最適な解とはいえない。例えば、ビデオ・ゲームの典型的シーンでは、前景のキャラクタおよび／またはビークル（多数のプリミティブからレンダリングされた複合オブジェクトであることが多い）は、画像の底部近くに現れる傾向があるが、画像の上部は、比較的少数のプリミティブとテクスチャ・マップからレンダリングできる比較的静的な背景により占有されることが多い。このような画像が上半分と下半分に分割された場合、上半分をレンダリングするＧＰＵは、一般に、画像のその部分を完成し、その後、他のＧＰＵが終了するのを待つ。このアイドル時間を避けるために、上側部分が下側部分よりも大きくなるように、表示領域を不均等に分割することが望ましい。一般に、最適な分割は、レンダリングされる特定のシーンに依存し、単一のビデオ・ゲームまたは他のグラフィックス・アプリケーション内でさえ、時間とともに変化する。

したがって、それぞれのＧＰＵにかかる処理負荷を監視し、負荷を分散させるため複数のＧＰＵへの表示領域の分割を動的に調整するためのメカニズムを実現することが望ましい。

本発明は、フレームの異なる部分をレンダリングする複数のグラフィックス・プロセッサ間に負荷を分散させるためのシステムおよび方法を実現する。

本発明の一態様により、並列動作するように構成されたグラフィックス・プロセッサの負荷分散を行うための方法を実現する。表示領域は、複数のグラフィックス・プロセッサのうちの第１のプロセッサによりレンダリングされる少なくとも第１の部分と複数のグラフィックス・プロセッサのうちの第２のプロセッサによりレンダリングされる第２の部分とに分割される。グラフィックス・プロセッサは、フレームをレンダリングするよう命令され、そこで、第１と第２のグラフィックス・プロセッサは、表示領域の第１と第２の部分に対するレンダリングをそれぞれ実行する。第１と第２のグラフィックス・プロセッサからフレームに対するフィードバック・データが受信され、フィードバック・データは、第１と第２のグラフィックス・プロセッサに対するそれぞれのレンダリング時間を反映する。フィードバック・データに基づき、第１と第２のグラフィックス・プロセッサのそれぞれの負荷の間に不均衡が存在するかどうかが判定される。不均衡が存在する場合、フィードバック・データに基づき、重い第１と第２のグラフィックス・プロセッサのうちのより負荷の重い一方が識別され、表示領域は、その表示領域の第１と第２の部分のうちの第１と第２のグラフィックス・プロセッサの負荷の重いプロセッサによりレンダリングされる方のサイズを増やし、表示領域の第１と第２の部分の他方のサイズを減らすように再分割される。

本発明の他の態様により、並列動作するように構成されたグラフィックス・プロセッサの負荷分散を行うための方法を実現する。表示領域は、第１のグラフィックス・プロセッサによりレンダリングされる少なくとも第１の部分と、第２のグラフィックス・プロセッサによりレンダリングされる第２の部分とに分割される。グラフィックス・プロセッサは、多数のフレームをレンダリングするよう命令され、そこで、第１と第２のグラフィックス・プロセッサは、表示領域の第１と第２の部分に対するレンダリングをそれぞれ実行する。第１と第２のグラフィックス・プロセッサからそれぞれのフレームに対するフィードバック・データが受信され、それぞれのフレームに対するフィードバック・データは、第１と第２のグラフィックス・プロセッサのうちのどちらがフレームのレンダリングを最後に終了したのかを示す。フィードバック・データに基づき、第１と第２のグラフィックス・プロセッサのそれぞれの負荷の間に不均衡が存在するかどうかが判定される。不均衡が存在する場合、フィードバック・データに基づき、第１と第２のグラフィック・プロセッサの負荷が重い方が識別され、表示領域は、その表示領域の第１と第２の部分のうち第１と第２のグラフィックス・プロセッサの負荷の重いプロセッサによりレンダリングされる方のサイズを増やし、表示領域の第１と第２の部分の他方のサイズを減らすように再分割される。

いくつかの実施態様では、格納先は複数のフレームのうちのそれぞれのフレームに関連付けられ、複数のフレームのそれぞれに対するフィードバック・データを受信することは、第１のグラフィックス・プロセッサに、そのフレームの表示領域の第１の部分をレンダリングした後複数のフレームのそれぞれに対する複数の格納先のうちの関連付けられた格納先に第１のプロセッサ識別子を格納するよう命令することと、第２のグラフィックス・プロセッサに、そのフレームの表示領域の第２の部分をレンダリングした後複数のフレームのそれぞれに対する複数の格納先の関連付けられた格納先に第１のプロセッサ識別子と異なる第２のプロセッサ識別子を格納するよう命令することを含む。第１と第２の識別子のそれぞれは、異なる数値を持つことができ、不均衡が存在するかどうかの判定は、格納先に格納されている数値から負荷係数を計算することを含む。負荷係数は、例えば、不均衡が存在しているかどうかを判定するためにプロセッサ識別子の数値の算術平均と対比できる記録された数値の平均とすることができる。

いくつかの実施態様では、再分割の活動時に、表示領域の第１の部分のサイズがどれだけ縮小されるかは、負荷係数と算術平均との差の大きさに少なくとも一部は依存する。

いくつかの実施態様では、複数のグラフィックス・プロセッサは、さらに、第３のグラフィックス・プロセッサを含む。分割の活動中に、表示領域は、表示領域の第１の部分に対応する第１のバンド、表示領域の第２の部分に対応する第２のバンド、第３のグラフィックス・プロセッサによりレンダリングされる表示領域の第３の部分に対応する第３のバンドを含む少なくとも３つのバンドに分割することができ、第１のバンドは第２のバンドに隣接し、第２のバンドは第３のバンドに隣接する。複数のフレームのそれぞれについて追加フィードバック・データを受信することができ、追加フィードバック・データは、フレームのレンダリングを最後に終了したのは第２のグラフィックス・プロセッサと第３のグラフィックス・プロセッサのうちのどちらであるかを示す。フィードバック・データに基づき、第２と第３のグラフィックス・プロセッサのそれぞれの負荷の間に不均衡が存在するかどうかを判定できる。不均衡が存在する場合、第２と第３のグラフィックス・プロセッサのうちのどちらの負荷が重いかを判定することができ、また表示領域は、その表示領域の第２と第３の部分のうちの第２と第３のグラフィックス・プロセッサの負荷の重いプロセッサによりレンダリングされる方のサイズを増やし、表示領域の第２と第３の部分の他方のサイズを減らすように再分割さできる。

本発明のさらに他の態様により、複数のグラフィックス・プロセッサを備えるグラフィックス処理サブシステム用のドライバは、コマンド・ストリーム・ジェネレータ、不均衡検出モジュール、分割モジュールを含む。コマンド・ストリーム・ジェネレータは、グラフィックス・プロセッサ用のコマンド・ストリームを生成するように構成され、コマンド・ストリームは、フレームのレンダリング・コマンドの集合とそれぞれのプロセッサがレンダリング・コマンドの集合を実行したことを示すフィードバック・データを送信する第１のグラフィックス・プロセッサと第２のグラフィックス・プロセッサのそれぞれへの命令を含む。不均衡検出モジュールは、第１と第２のグラフィックス・プロセッサにより送信されたフィードバック・データを受信し、第１と第２のグラフィックス・プロセッサのそれぞれの負荷の間に不均衡が存在するかどうかをフィードバック・データから判定するように構成されている。分割モジュールは、１つの表示領域を複数の部分に分割するように構成され、それぞれの部分は、複数のグラフィックス・プロセッサのうちの異なる１つのグラフィックス・プロセッサによりレンダリングされ、それら複数の部分は第１のグラフィックス・プロセッサによりレンダリングされる第１の部分と第２のグラフィックス・プロセッサによりレンダリングされる第２の部分を含む。分割モジュールは、さらに、不均衡が存在すると不均衡検出モジュールにより判定されたことに応じて、分割モジュールは、表示領域の第１と第２の部分のうちの、第１と第２のグラフィックス・プロセッサのうちの負荷の重いグラフィックス・プロセッサによりレンダリングされる方のサイズを増やし、表示領域の第１と第２の部分のうちの他方のサイズを減らす。
以下の詳細な説明を付属の図面と併せて読むと、本発明の性質および利点をよく理解できる。

本発明は、フレームの異なる部分をレンダリングする複数のグラフィックス・プロセッサ間に負荷を分散させるためのシステムおよび方法を実現する。いくつかの実施形態では、負荷分散は、２つのグラフィックス・プロセッサのうち一方がフレームのレンダリングを最後に終了する頻度が他方よりも多いかどうかを判定することにより実行される。最後に終了する頻度が一方のプロセッサにかたよっている場合、処理負担の一部（例えば、レンダリングするピクセルのライン数）が、そのプロセッサから他方のプロセッサにシフトされる。比較を繰り返し、望む回数だけ負荷調整をすることができる。２つ一組の負荷比較と負荷分散の技術を任意の数のグラフィックス・プロセッサを備えるシステムに拡張することができる。

図１は、本発明の一実施形態によるコンピュータ・システム１００のブロック図である。コンピュータ・システム１００は、バス１０６を介して通信する中央演算処理装置（ＣＰＵ）１０２とシステム・メモリ１０４を備える。ユーザ入力は、バス１０６に結合されている１つまたは複数のユーザ入力デバイス１０８（例えば、キーボード、マウス）から受信される。視覚的出力が、システム・バス１０６に結合されたグラフィックス処理サブシステム１１２の制御の下で動作しているピクセル・ベースのディスプレイ・デバイス１１０（例えば、従来のＣＲＴまたはＬＣＤベースのモニタ）上に送られる。システム・ディスク１２８と、１つまたは複数の取り外し可能なストレージ・デバイス１２９（例えば、フロッピ・ディスク・ドライブ、コンパクト・ディスク（ＣＤ）ドライブ、および／またはＤＶＤドライブ）などの他のコンポーネントも、システム・バス１０６に結合することができる。

グラフィックス処理サブシステム１１２は、システム１００のマザーボード上の適切なバス・スロット（例えば、ＰＣＩまたはＡＧＰ）に接続されるように適合されたプリント基板カードを使用して実装されると都合がよい。この例では、グラフィックス処理サブシステム１１２は、２つ（またはそれ以上）のグラフィックス処理ユニット（ＧＰＵ）１１４ａ、１１４ｂを備え、それぞれ、別々の集積回路デバイスとして実装されると都合がよい（例えば、プログラム可能プロセッサまたは特定用途向け集積回路（ＡＳＩＣ））。ＧＰＵ １１４ａ、１１４ｂは、システム・バス１０６を介して受信された命令（コマンド）への応答として様々なレンダリング機能を実行するように構成される。いくつかの実施形態では、レンダリング機能は、ディスプレイ・デバイス１１０上に表示するためシーンを記述する幾何学データをピクセル・データに変換するために使用されるグラフィックス処理パイプラインにおける様々なステップに対応する。これらの機能は、例えば、照明変換、座標変換、幾何学的プリミティブのラスター化データへの走査変換、隠面消去表示計算、陰影レンダリング、テクスチャ合成などを含むことができる。当業では、レンダリング機能の多数の実装が知られており、ＧＰＵ １１４ａ、１１４ｂで実現することができる。ＧＰＵ １１４ａ、１１４ｂは、グラフィックス処理命令がいずれかのＧＰＵにより実行することができ、実質的に同一の結果を得られるようにまったく同じに構成されると都合がよい。

それぞれのＧＰＵ １１４ａ、１１４ｂは、関連付けられたグラフィックス・メモリ１１６ａ、１１６ｂを備え、これらは、一般的に従来の設計の１つまたは複数の集積回路メモリ・デバイスを使用して実装することができる。グラフィックス・メモリ１１６ａ、１１６ｂは、ディスプレイ・バッファ１２２ａ、１２２ｂと、コマンド・バッファ１２４ａ、１２４ｂなどの様々な物理的または論理的細分を含むことができる。ディスプレイ・バッファ１２２ａ、１２２ｂは、スキャンアウト制御論理回路１２０により読み込まれ、表示するためディスプレイ・デバイス１１０に送信される画像（または画像の一部）に対するピクセル・データを格納する。このピクセル・データは、システム・バス１０６を介してＧＰＵ １１４ａ、１１４ｂに供給されるシーン・データから生成されるか、またはＣＰＵ １０２上で実行されている様々なプロセスにより生成され、システム・バス１０６を介してディスプレイ・バッファ１２２ａ、１２２ｂに供給されるようにできる。いくつかの実施形態では、ディスプレイ・バッファ１２２ａ、１２２ｂは、二重バッファ型とすることができ、これにより、「前」バッファから表示のため第１の画像のデータが読み込まれている間に、第２の画像のデータを現在表示されている画像に影響を及ぼすことなく「後」バッファに書き込むことができる。コマンド・バッファ１２４ａ、１２４ｂを使用することで、後述のように、それぞれのＧＰＵ １１４ａ、１１４ｂにより実行するためシステム・バス１０６を介して受信されたコマンドをキューに入れる。グラフィックス・メモリ１１６ａ、１１６ｂの他の部分は、それぞれのＧＰＵ １１４ａ、１１４ｂ（テクスチャ・データ、色ルックアップ・テーブルなど）、ＧＰＵ １１４ａ、１１４ｂ用の実行可能プログラム・コードなどにより必要とされるデータを格納するために使用できる。

それぞれのグラフィックス・メモリ１１６ａ、１１６ｂについて、それぞれのグラフィックス・メモリへのアクセスを制御するために、メモリ・インターフェース１２３ａ、１２３ｂがさらに備えられる。メモリ・インターフェース１２３ａ、１２３ｂを、それぞれのＧＰＵ １１４ａ、１１４ｂ、またはそれぞれのメモリ１１６ａ、１１６ｂと一体化することができるか、または別の集積回路デバイスとして実装することができる。一実施形態では、ＧＰＵ １１４ａから発せられるすべてのメモリ・アクセス要求は、メモリ・インターフェース１２３ａに送信される。要求のターゲット・アドレスがメモリ１１６ａ内のあるロケーションに対応している場合、メモリ・インターフェース１２３ａは、適切なロケーションにアクセスし、対応していない場合、メモリ・インターフェース１２３ａは、その要求をブリッジ・ユニット１３０に転送するが、これについては後述する。メモリ・インターフェース１２３ａは、さらに、メモリ１１６ａ内のロケーションをターゲットとするすべてのメモリ・アクセス要求を受信する。これらの要求は、スキャンアウト制御論理回路１２０、ＣＰＵ １０２、または他のシステム・コンポーネント、さらにＧＰＵ １１４ａまたは１１４ｂから発信される。同様に、メモリ・インターフェース１２３ｂは、ＧＰＵ １１４ｂから発信されるか、メモリ１１６ｂ内のロケーションをターゲットとする、すべてのメモリ・アクセス要求を受信する。

ブリッジ・ユニット１３０は、グラフィックス処理サブシステム１１２（メモリ・インターフェース１２３ａ、１２３ｂ）のコンポーネントとシステム１００の他のコンポーネントとの通信を管理するように構成される。例えば、ブリッジ・ユニット１３０は、システム・バス１０６からすべての着信データ転送要求を受信し、メモリ・インターフェース１２３ａ、１２３ｂの１つまたは複数に要求を配信（またはブロードキャスト）することができる。ブリッジ・ユニット１３０は、さらに、グラフィックス処理サブシステム１１２の外部にあるメモリ・ロケーションを参照するグラフィックス処理サブシステム１１２（ＧＰＵ １１４ａ、１１４ｂ）のコンポーネントから発信するデータ転送要求を受信し、システム・バス１０６を介してそれらの要求を送信することもできる。さらに、いくつかの実施形態では、ブリッジ・ユニット１３０は、ＧＰＵ １１４ａ、１１４ｂのうちの他方に関連付けられているメモリ１１６ｂ、１１６ａにＧＰＵ １１４ａ、１１４ｂのいずれかによりアクセスすることを容易にする。ブリッジ・ユニット１３０の例は、上記の同時係属出願第＿＿＿＿＿号（整理番号０１９６８０−００６０００ＵＳ）で詳述されており、本明細書では、本発明を理解するうえで重要でないので、詳細な説明を省く。

動作時に、ＣＰＵ １０２上で実行されているグラフィックス・ドライバ・プログラム（または他のプログラム）は、ＧＰＵ １１４ａ、１１４ｂによる処理のためレンダリング・コマンドと、それに関連付けられたデータを配信する。いくつかの実施形態では、ＣＰＵ １０２は、ＣＰＵ １０２とＧＰＵ １１４ａ、１１４ｂの両方からアクセス可能なメモリ内に実装することができるコマンド・バッファを使用してＧＰＵ １１４ａ、１１４ｂのそれぞれと非同期に通信する。一実施形態では、コマンド・バッファは、システム・メモリ１０４内に格納され、直接メモリ・アクセス（ＤＭＡ）転送を介してＧＰＵ １１４ａ、１１４ｂからアクセス可能である。他の実施形態では、それぞれのＧＰＵ １１４ａ、１１４ｂは、メモリ１１６ａ、１１６ｂ内にそれぞれのコマンド・バッファ１２４ａ、１２４ｂを備える。それらのコマンド・バッファは、ＤＭＡ転送を介してＣＰＵ １０２からアクセス可能である。コマンド・バッファには、多数のレンダリング・コマンドとレンダリング・データの集合が格納される。一実施形態では、レンダリング・コマンドは、レンダリング・データに関連付けることができ、レンダリング・コマンドは、関連付けられているレンダリング・データに対しＧＰＵにより実行されるレンダリング・オペレーションの集合を定義する。いくつかの実施形態では、レンダリング・データは、関連付けられているレンダリング・コマンドに隣接するコマンド・バッファ内に格納される。

ＣＰＵ １０２は、レンダリング・コマンドとデータの集合を含むコマンド・ストリームをそれぞれのＧＰＵ １１４ａ、１１４ｂ用のコマンド・バッファ（例えば、コマンド・バッファ１２４ａ、１２４ｂ）に書き込む。いくつかの実施形態では、同じレンダリング・コマンドとデータが、それぞれのＧＰＵのコマンド・バッファに書き込まれ（例えば、ブリッジ・チップ１３０のブロードキャスト・モードを使用して）、他の実施形態では、ＣＰＵ １０２がそれぞれのＧＰＵのコマンド・バッファに別々に書き込む。同じコマンド・ストリームが両方のＧＰＵ １１４ａ、１１４ｂに供給される場合、コマンド・ストリームは、それらのＧＰＵのうちのどちらが特定のコマンド処理すべきかを指示するタグまたは他のパラメータを含む。

それぞれのコマンド・バッファ１２４ａ、１２４ｂは、ＣＰＵ １０２により書き込まれ、ＧＰＵ １１４ａ、１１４ｂのうちのそれぞれの一方により読み出される先入れ先出しバッファ（ＦＩＦＯ）として実装されると都合がよく、読み書きは非同期に実行することで可能である。一実施形態では、ＣＰＵ １０２は、ＣＰＵ １０２が書き込む毎にインクリメントする、「ｐｕｔ」ポインタにより決定されるロケーションでそれぞれのコマンド・バッファに新しいコマンドとデータを定期的に書き込む。それぞれのＧＰＵ １１４ａ、１１４ｂは、非同期に、そのコマンド・バッファ１２４ａ、１２４ｂにすでに格納されているコマンドとデータの集合を連続的に読み込み、処理し、それぞれのＧＰＵ １１４ａ、１１４ｂは、そのコマンド・バッファ１２４ａ、１２４ｂ内の読み込みロケーションを識別するための「ｇｅｔ」ポインタを保持し、そのｇｅｔポインタは、読み込み毎にインクリメントされる。ＣＰＵ １０２がＧＰＵ １１４ａ、１１４ｂよりも十分先んじているとすると、それらのＧＰＵは、ＣＰＵ １０２を待つアイドル時間を被ることなく画像をレンダリングすることができる。いくつかの実施形態では、コマンド・バッファのサイズとシーンの複雑度に応じて、ＣＰＵ １０２は、ＧＰＵ １１４ａ、１１４ｂによりレンダリングされるフレームよりも数フレーム先のフレームに対するコマンドとデータの集合を書き込むことができる。

コマンド・バッファは、固定サイズ（例えば、５メガバイト）とすることができ、ラップアラウンド方式で読み書きすることができる（例えば、最後のロケーションに書き込んだ後、ＣＰＵ １０２は「ｐｕｔ」ポインタを第１のロケーションにリセットすることができる）。マルチチップ・グラフィックス処理システムでコマンドとデータをコマンド・バッファに書き込むためのコマンド・バッファと手法の実施形態の詳細については、上述の同時係属出願第＿＿＿＿＿号（整理番号０１９６８０−００５９００ＵＳ）に記載されている。

スキャンアウト制御論理回路１２０は、フレーム・バッファ１２２ａ、１２２ｂから画像のピクセル・データを読み込み、そのデータを表示するためディスプレイ・デバイス１１０に転送する。スキャンアウトは、一定の垂直走査周波数（例えば、８０Ｈｚ）で実行することができ、垂直走査周波数は、ユーザ選択可能なパラメータとすることができ、画像データの新しいフレームがディスプレイ・バッファ１２２ａ、１２２ｂに書き込まれる速度に対応している必要はない。スキャンアウト制御論理回路１２０は、さらに、色値の調整、ディスプレイ・バッファ１２２ａ、１２２ｂのいずれかのピクセル・データをグラフィックス・メモリ１１６ａ、１１６ｂまたは他のデータ・ソース（図に示されていない）のいずれかから得られるビデオまたはカーソル・オーバーレイ画像などのデータと組み合わせることによる合成画面画像の生成、デジタル−アナログ変換などの他のオペレーションを実行することもできる。

ＧＰＵ １１４ａ、１１４ｂは、並列動作させると、画像データの新しいフレームをレンダリングできる速度を高めることができて都合がよい。「空間を並列方式」と本明細書で呼ばれる一実施形態では、それぞれのＧＰＵ １１４ａ、１１４ｂは、それぞれのフレームの異なる部分（例えば、水平または垂直バンド）に対するピクセル・データを生成し、スキャンアウト制御論理回路１２０は、ディスプレイ・バッファ１２２ａからのフレームに対するピクセル・データの第１の部分（例えば、上側部分）とディスプレイ・バッファ１２２ｂからの第２の部分（例えば、下側部分）を読み込む。空間並列方式では、レンダリング・コマンドとそれに随伴するデータは、両方のコマンド・バッファ１２４ａ、１２４ｂに並列動作で書き込むことができるが（例えば、ブリッジ・ユニット１３０のブロードキャスト・モードを使用して）、コマンドおよび／またはデータは、コマンド・バッファの１つまたは複数に選択的に書き込むこともできる（例えば、表示可能領域を定義するコマンドに対する異なるパラメータは、それぞれのＧＰＵが画像の正しい部分をレンダリングするように異なるコマンド・バッファに書き込むことが可能である）。

空間並列方式の一例が図２に示されている。表示領域２００は、ピクセル・データのＭ本のライン（水平行）からなる。ライン１からＰ（表示領域２００の上側部分２０２に対応する）は、図１のＧＰＵ １１４ａによりレンダリングされ、ラインＰ＋１からＭ（表示領域２００の下側部分２０４に対応する）は、ＧＰＵ １１４ｂによりレンダリングされる。この実施形態では、それぞれのＧＰＵ １１４ａ、１１４ｂは、ディスプレイ・バッファ１２２ａ、１２２ｂを、データのフレーム全体（Ｍ本のライン）を格納するのに十分な大きさのローカル・メモリ１１６ａ、１１６ｂ内に割り付けるが、それがレンダリングするラインのみを埋める（ＧＰＵ １１４ａについてはライン１からＰまで、ＧＰＵ １１４ｂについてはラインＰ＋１からＭまで）。それぞれの表示フレッシュ・サイクルで、スキャンアウト制御論理回路１２０は、ディスプレイ・バッファ１２２ａから最初のＰ本のラインを読み込み、その後、ディスプレイ・バッファ１２２ｂに切り替えて、ラインＰ＋１からＭまでを読み込む。それぞれのＧＰＵがどのラインをレンダリングするかを決定するために、ＧＰＵ毎に「クリップ矩形」が設定され、例えば、ＧＰＵ １１４ａは、フレーム２００の上側部分２０２に対応するクリップ矩形を持つことができるが、ＧＰＵ １１４ｂは、フレーム２００の下側部分２０４に対応するクリップ矩形を持つ。

本発明の一実施形態により、それぞれのＧＰＵは、フィードバック・データをグラフィックス・ドライバ・プログラム（またはＣＰＵ １０２上で実行する他のプログラム）に供給する。フィードバック・データは、画像のその部分をレンダリングするために特定のＧＰＵでかかる時間に関する情報を含む。グラフィックス・ドライバ・プログラムは、このフィードバックを使用して、ときどきクリップ矩形を修正する、例えば、２つのＧＰＵ上の相対的負荷に基づき境界ラインを異なるラインＰ’に変更することにより、ＧＰＵ間の動的負荷分散を行う。

コマンド・バッファ１２４ａ、１２４ｂのいずれか一方（または両方に）書き込むことができるコマンド・ストリーム３００の例が図３に示されている。ストリームは、画像の表示可能領域を定義する、「クリップ矩形」（ＣＲ）コマンド３０２で開始する。例えば、ＧＰＵ １１４ａのクリップ矩形は、表示領域２００（図２）のライン１からＰまでを含むように定義することができ、ＧＰＵ １１４ｂのクリップ矩形はラインＰ＋１〜Ｍを含む。本明細書で使用されているように、「クリップ矩形」という用語は、フレームまたは画像に対する像平面の見える部分、またはより具体的には、特定のＧＰＵがレンダリングするよう命令されている像平面の部分を定義することに関連する特定のコマンドまたは用語を含むものと理解すべきである。

クリップ矩形コマンドの後に、フレームＦ０に対する１つまたは複数のレンダリング・コマンド３０４と関連するレンダリング・データが続く。これらのコマンドとデータは、例えば、シーンを構成するプリミティブおよび／またはオブジェクトの定義、座標変換、照明変換、隠面消去表示コマンド、テクスチャ・コマンド、その他の種類のレンダリング・コマンドおよび／またはデータを含むことができ、通常は、ピクセル・データをディスプレイ・バッファ１２２ａ、１２２ｂに書き込んで（および、スキャンアウト制御９論理回路１２０によるそのデータの読み込みで）終わりになる。

フレームＦ０に対する最後のレンダリング・コマンド３０４の後に、「ライト・ノティファイヤ」（ＷＮ：write notifier）コマンド３０６が続く。ライト・ノティファイヤ・コマンドは、ＧＰＵに、システム・メモリにフィードバック・データを書き込み、フレームＦ０を終了したことを示すよう命令する。このフィードバック・データは、グラフィックス・ドライバ・プログラムにより読み込まれ、ＧＰＵ間の負荷分散に使用される。フィードバック・データの特定の実施形態について以下で説明する。

ノティファイヤ・コマンド３０６の後に、次のフレームＦ１に対するレンダリング・コマンド３０８と関連するレンダリング・データが続き、順に、他のライト・ノティファイヤ・コマンド３１０と続く。ある数（Ｑ）のフレームの後に、ライト・ノティファイヤ・コマンド３２２があり、その後に新しいクリップ矩形コマンド３２４が続く。この時点で、それぞれのＧＰＵに対するクリップ矩形は、様々なライト・ノティファイヤ・コマンド（例えば、コマンド３０６、３１０）に対する応答として受信されたフィードバック・データに基づきグラフィックス・ドライバ・プログラムにより修正することができる。例えば、表示領域が図２に示されているように分割される場合、Ｐの値は、フィードバック・データに応じて（例えば、Ｐ’に）修正することができ、上側部分２０２を処理するＧＰＵがフレームを先に終了する傾向がある場合、Ｐの値が増やされ、下側部分２０４を処理するＧＰＵが先に終了する傾向がある場合、Ｐの値が減らされる。フィードバック・データに応じて表示領域を再分割する特定の実施形態について、以下で説明する。

本明細書で説明されているシステムは、例示的であり、変更形態や修正形態も可能であることは理解されるであろう。例えば、それぞれのメモリを有する２つのＧＰＵが示されているが、使用するＧＰＵはいくつでもよく、複数のＧＰＵがメモリを共有することが可能である。本明細書で説明されているメモリ・インターフェースは、単一の集積回路デバイス（チップ）内のＧＰＵおよび／またはメモリと一体化するか、または別のチップとして実装することが可能である。ブリッジ・ユニットは、メモリ・インターフェースおよび／またはＧＰＵチップと一体化することができるか、または別のチップ上に実装することができる。１つまたは複数の集積回路デバイスを使用して様々なメモリを実装できる。グラフィックス処理サブシステムは、ＰＣＩ、ＰＣＩＸ（ＰＣＩ Ｅｘｐｒｅｓｓ）、ＡＧＰ（Ａｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ）などを含む様々な拡張カード形式を使用して実装することができる。グラフィックス処理サブシステムのコンポーネントのいくつか、またはすべてをマザーボード上に直接取り付けることができ、例えば、ＧＰＵの１つは、マザーボード取り付けグラフィックス・コプロセッサとすることができる。本発明を実施する上で好適なコンピュータ・システムは、さらに、高速ＤＭＡ（直接メモリ・アクセス）チップなどの他の様々なコンポーネントを含むこともでき、また単一システムは、バスを相互接続するために用意されている適切なコンポーネントとともに複数のバス・プロトコルを実装することができる（例えば、ＰＣＩとＡＧＰバスが両方とも存在しうる）。１つまたは複数のコマンド・バッファを、グラフィックス・サブシステム・メモリではなく、メイン・システム・メモリ内に実装することができ、コマンドは、（複数の）ＧＰＵがコマンドを受信または処理することを示す追加パラメータを含むことができる。本発明の説明では、非同期オペレーションを取りあげている場合があるが、当業者であれば、本発明は、ＣＰＵがＧＰＵと同期して通信するシステム内に実装することもできることを理解するであろう。

次に、フィードバック・データとフィードバック・データに基づく負荷分散技術の実施形態について説明する。一実施形態では、それぞれのＧＰＵ １１４ａ、１１４ｂは、ローカル・メモリ１１６ａ、１１６ｂ内の指定ロケーションに格納する識別子を割り当てられ、この識別子は、さらに、それぞれのＧＰＵ １１４ａ、１１４ｂのオンチップ・レジスタ内にも格納できる。例えば、ＧＰＵ １１４ａは、識別子「０」を割り当てることができるが、ＧＰＵ １１４ｂは、識別子「１」を割り当てられる。これらの識別子は、数値を持つと都合がよく、例えば、システム起動またはアプリケーション起動時に割り当てることができる。後述のように、この識別子は、負荷分散を目的としてフィードバック・データとして使用することができる。

図４は、ＧＰＵの識別子を含むフィードバック・データを記録するためのプロセス４００を例示している。ステップ４０２で、グラフィックス・ドライバ・プログラムは、システムのメイン・メモリ内に次元Ｂ（例えば、５、１０、２０、５０など）のフィードバック配列（本明細書ではｆｅｅｄｂａｃｋ［０：Ｂ−１］と呼ばれる）を作成し、ステップ４０４で、フレーム・カウンタｋは初期化される（例えば、０に）。この実施形態では、それぞれのフレームｋに続くライト・ノティファイヤ・コマンドは、例えば、ＤＭＡブロック転送オペレーション（「Ｂｌｉｔ」）またはＧＰＵがシステム・メイン・メモリにデータを書き込む他のオペレーションを使用して、ローカル・メモリからシステム・メイン・メモリ内のロケーションｆｅｅｄｂａｃｋ［ｋ］に識別子をコピーするようＧＰＵに対し命令する。そのため、ステップ４０６で、フレームｋのレンダリングを終了する第１のＧＰＵは、その識別子を配列ロケーションｆｅｅｄｂａｃｋ［ｋ］に書き込む。ステップ４０８で、フレームｋのレンダリングを終了する第２のＧＰＵは、その識別子を配列ロケーションｆｅｅｄｂａｃｋ［ｋ］に書き込み、第１のＧＰＵの識別子を上書きする。ＧＰＵ １１４ａ、１１４ｂのいずれかが最初に終了し、先に１つのフレームを終了するＧＰＵは、他のフレームを最後に終了する可能性のあることは理解されるであろう。

この実施形態では、それぞれのＧＰＵは、システム・メモリ内の同じロケーションに書き込むように命令され、その結果、フレームｋを終了する第２のＧＰＵは、配列要素ｆｅｅｄｂａｃｋ［ｋ］内で第１のＧＰＵの識別子を上書きすることに留意されたい。したがって、両方のＧＰＵが特定のフレームｋを終了した後、ｆｅｅｄｂａｃｋ［ｋ］に格納された値は、どのＧＰＵがフレームｋを最後に終了したかを示す。

ステップ４１０で、フレーム・カウンタは、次のフレームにインクリメントされる、モジュロＢ。これにより、フィードバック配列は、Ｂ個のフレーム毎に循環する形で上書きされ、配列の内容は、一般的に、レンダリングされた最後Ｂ個のフレームを反映する。一実施形態では、それぞれのフレームに対するフレーム・カウンタ値は、書き込み通知コマンドとともにそれぞれのＧＰＵに送られ、他の実施形態では、それぞれのＧＰＵは、それ専用のフレーム・カウンタを保持し、ライト・ノティファイヤ・コマンドに応答して、システム・メモリ内の適切なロケーションに識別子を書き込んだ後、フレーム・カウンタを更新する。

フィードバック配列内の情報は、図５に例示されているように、負荷分散のためグラフィックス・ドライバ・プログラム（またはＣＰＵ １０２上で実行される他のプログラム）で使用することができる。プロセス５００は、連続ループとして示されており、そこでは、ＧＰＵ上の相対的負荷は、ときどきフィードバック配列に格納されている値の平均をとることにより推定され、負荷は、推定値に基づいて調整される。この実施形態では、空間並列方式で動作する２つのＧＰＵ（例えば、図１のＧＰＵ １１４ａ、１１４ｂ）があり、表示領域は、図２に示されているように分割される。表示領域の上側部分２０２に割り当てられたＧＰＵは、識別子「０」を持ち、本明細書ではＧＰＵ−０とし呼ばれ、下側部分２０４に割り当てられたＧＰＵは、識別子「１」を持ち、本明細書ではＧＰＵ−１と呼ばれる。負荷分散は、ＧＰＵ毎にクリップ矩形を調整することにより、実行され、この例では図２の境界ラインＰの配置により決定される。

ステップ５０１で、クリップ矩形コマンドは、ＧＰＵ毎に発行される（例えば、コマンド・ストリーム内に置かれる）。この初期クリップ矩形コマンドは、表示領域をＧＰＵ間で均等に（例えば、Ｐ＝Ｍ／２を使用して）または不均等に分割することができる。例えば、アプリケーション・プログラムの開発者は、その負荷を近似的に分散するＰの値を経験に基づいて決定し、適切なコマンドを介してその値をグラフィックス・ドライバ・プログラムに供給することができる。それぞれのＧＰＵに割り付けられた表示領域の部分の初期サイズは、負荷分散のためときどき変化するのがふつうなので、重要でない。

ステップ５０２で、グラフィックス・ドライバは、ＧＰＵ間の負荷分散を行う時間かどうかを判定する。この判定には様々な基準を使用でき、例えば、グラフィックス・ドライバは、Ｑが１、２、５、１０、２０などである場合に、何らかの数（Ｑ）のフレームの後に負荷分散を行うことができる。Ｑは、フィードバック配列内のエントリＢの個数を超えないのがよいが、ＱはＢに等しい必要はない。それとは別に、負荷分散は、定期的間隔（例えば、１秒に１回）、または他の基準に従って実行することができる。負荷分散を行う時間でない場合、プロセス５００は待機し（ステップ５０４）、その後、ステップ５０２で負荷分散基準を再びチェックする。

負荷分散を行う時間の場合、グラフィックス・ドライバは、ステップ５０６でフィードバック配列からのＱ値の平均を求め、それにより負荷係数を計算する。一実施形態では、ＱはＢ（フィードバック配列の長さ）に等しく、他の値を選択することができる。グラフィックス・ドライバとＧＰＵは、上述のようにＣＰＵと非同期に動作することができるため、グラフィックス・ドライバは、ＧＰＵが特定のフレームを終了したかどうかを関知しなくてよく、ＧＰＵは、グラフィックス・ドライバの現在のフレームよりも、コマンド・ストリーム内の数フレーム前にあるフレームをレンダリングしている可能性があることに留意されたい。フィードバック配列が、上述のプロセス４００のように、循環方式で書き込まれる場合、ＱをＢに等しくなるように選択することで、Ｂ個の一番最近レンダリングされたフレーム上で平均をとる。いくつかの実施形態では、重み付き平均を使用し、例えば、より大きな重みを最近レンダリングされたフレームに与えることができる。

負荷係数は、ＧＰＵのクリップ矩形に対する調整を行う必要があるかどうかを判定するために使用される。ＧＰＵに等しい負荷がかかっている場合、いずれかのＧＰＵがフレームを最初に終了する確率は約５０％であり、適当な数（例えば、２０）のフレームに対する平均値は、識別子の値として０と１が使用されれば約０．５である。０．５を超える平均値は、ＧＰＵ−１（画像の下側部分をレンダリングする）はＧＰＵ−０よりも負荷が重いことを示し、０．５未満の平均値は、ＧＰＵ−０（画像の上側部分をレンダリングする）はＧＰＵ−１よりも負荷が重いことを示す。

したがって、ステップ５１０で、負荷係数が「高」しきい値を超えるかどうかが判定される。高しきい値が事前に選択され、またこれは、きっかり０．５、またはそれよりもいくぶん高い値（例えば、０．５５または０．６）とすることができる。負荷係数が高しきい値を超える場合、ステップ５１２で、図２の境界ラインＰをプリセット値（例えば、ライン１本、５本、１０本分）だけ下げることにより負荷を調整する。これにより、ＧＰＵ−１によりレンダリングされる表示領域の一部が縮小され、このため、ＧＰＵ−１の負荷が減少し、ＧＰＵ−０の負荷が増大する傾向が生じる。そうでなければ、ステップ５１４で、負荷係数が「低」しきい値よりも低いかどうかが判定される。低しきい値が事前に選択され、またこれは、きっかり０．５、またはそれよりもいくぶん低い値（例えば、０．４５または０．４）とすることができる。負荷係数が低しきい値よりも小さい場合、ステップ５１６で、図２の境界ラインＰをプリセット値（例えば、ライン１本、５本、１０本分）だけ下げることにより負荷を調整する。ステップ５１８で、負荷係数が高しきい値以下、かつ低しきい値以上の場合、負荷は均衡していると考えられ、境界ラインＰは変更されない。

新しい境界ラインＰが決定された後、新しいクリップ矩形コマンドがＧＰＵ毎に発行され（ステップ５２２）、プロセスは、ステップ５０４に戻り、再び負荷分散のときを待つ。他の実施形態では、境界ラインが変化した場合のみ、ステップ５２２で、新しいクリップ矩形コマンドが発行される。新しいクリップ矩形コマンドとともに、適切なディスプレイ・バッファが選択されピクセル・データのそれぞれのラインを供給するように、メッセージがスキャンアウト制御論理回路に送信される（例えば、ディスプレイ・バッファの選択に関係する１つまたは複数のスキャンアウト・パラメータを修正することにより）。スキャンアウト制御論理回路のパラメータの変更は、新しいクリップ矩形が有効になるフレームのレンダリングと同期すると都合がよく、したがって、いくつかの実施形態では、クリップ矩形コマンドは、さらに、スキャンアウト・パラメータを更新し、次にレンダリングされたフレームを正しく表示することができる。

いくつかの実施形態では、境界ラインが負荷分散するようにシフトされるときに、一方のディスプレイ・バッファから他方のディスプレイ・バッファへデータを転送すると有益な場合がある。例えば、図２では、ＧＰＵ １１４ａ、１１４ｂが現在のフレームのレンダリングを終了した直後に、Ｐの値をより大きな値Ｐ’に変更し、ＧＰＵ １１４ａが次のフレームについてレンダリングするラインの本数を増やすと仮定する。ＧＰＵ １１４ａは、次のフレームを正しく処理するために、現在のフレームのラインＰ＋１からＰ’の一部または全部に対するデータにアクセスする必要がある場合がある。一実施形態では、ＧＰＵ １１４ａは、ラインＰ＋１からＰ’に対するデータを持つディスプレイ・バッファ１２２ｂの部分からＤＭＡ転送によりデータを取得することができる。この目的のために使用されると都合がよいと思われるプロセスの例については、上記の出願第＿＿＿＿＿号（整理番号０１９６８０−００６０００ＵＳ）で説明されているが、データを転送するための他の様々なプロセスも使用できる。ディスプレイ・バッファ間でデータを転送することは必要というわけではないが、データ転送に関連するオーバーヘッドを、一方のＧＰＵに他方のＧＰＵによりすでに実行済みの計算を繰り返させることのオーバーヘッドが超えている実施形態では有用な場合があることは理解されるであろう。グラフィックス・メモリ１１６ａ、１１６ｂ間で表示されないデータ（例えば、テクスチャ・データ）を転送することも、場合によっては、望ましく、上述の手法を使用して実装することができる。

本明細書で説明されているプロセスは、例示的であり、変更形態や修正形態も可能であることは理解されるであろう。逐次的として説明されているステップは、並列実行することができ、ステップの順序は可変であり、ステップは、修正または組み合わせることができる。平均するフレームの数（Ｑ）および／または負荷分散の頻度の最適な選択は、一般的に、様々なトレードオフ要因に左右される。例えば、Ｑの値が小さいと、レンダリングされるシーン内の変化への反応が高速化され、Ｑの値が大きいと、より安定した結果が得られる傾向があるとともに（変動の影響を最小にすることにより）、一方のＧＰＵのみが終了したフレームに対するフィードバック配列内のエントリの影響を小さくする（そのようなエントリがあると、そのフレームを終了する最後のＧＰＵを正確に反映しない）。負荷分散が頻繁であれば、ＧＰＵのアイドル時間は短縮される可能性があるが、負荷分散があまり頻繁でないと、クリップ矩形を変化させることに関連するオーバーヘッド（異なるＧＰＵのメモリ間のデータ転送など）が低減される傾向がある。一実施形態では、Ｑ＝Ｂ＝２０として２０フレーム毎に均衡をチェックすることは有効であるが、一般に、最適な値は、様々な実装上の詳細に依存する。均衡のチェックは極めて頻繁に行われる場合があり、例えば、１秒間に３０フレームがレンダリングされ、２０フレーム毎にチェックが行われると、均衡は約０．６７秒毎に変化しうることに留意されたい。

異なるＧＰＵに対する識別子はいかなる値をもとることができる。それに対応して、高しきい値と低しきい値は、任意の値をとることができ、高しきい値は低しきい値以上である限り、２つのしきい値を等しくすることができる（例えば、両方とも０．５に等しい）。両方のしきい値を２つの識別子の算術平均に近い値または等しい値に設定すると都合がよく、特定のシステムにおけるしきい値の最適な選択は、負荷再分散の頻度とそれぞれのＧＰＵに割り当てられたクリップ矩形を変更することに関係するオーバーヘッドなどの考慮事項の影響を受ける可能性がある。しきい値比較は、負荷が均衡していると考えられる条件（例えば、平均が算術平均と正確に等しい場合）が存在するように定義されると都合がよい。

画像のレンダリングまたはフィードバック・データの書き込みに先立って、例えば、エントリ毎にＧＰＵ識別子のいずれかをランダムに選択するか、または交互エントリに異なる識別子を埋めて行くことにより、フィードバック配列を初期化することができる。このような初期化では、ＧＰＵが負荷係数を決定するために使用されているエントリすべてに値を書き込む前に負荷分散のチェックが実行される場合に見せかけの不均衡が検出される可能性が低減される。

一実施形態では、分割変更（例えば、境界ラインＰがシフトされるラインの本数）は、負荷係数と算術平均との差の大きさに依存する。例えば、負荷係数が０．５よりも大きく、０．６よりも小さい場合、４本のラインの下方向へのシフトを使用することができるが、負荷係数が０．６よりも大きい場合は、ライン８本分のシフトを使用することができ、算術平均よりも小さい負荷係数については、反対方向の類似のシフトを実装できる。いくつかの実施形態では、それぞれのＧＰＵが常に表示領域の少なくとも最小部分（例えば、１０％または２５％）をレンダリングするように２つのクリップ矩形のサイズの差が制限される。

平均をとる代わりに、他の方法で負荷係数を定義することもできる。例えば、記録された識別子値の総和を負荷係数として使用できる。上述の実施形態では、Ｑ＝２０としているが、格納されている識別子値（０または１）は、負荷が均衡している場合には、総和すると１０になり、それに応じて、高、低のしきい値を設定することができる。本明細書で説明されているオペレーションの代わりに使用できる他の算術演算も、当業者には明らかであろうし、本発明の範囲内にある。

他の代替え実施形態では、異なるフィードバック・データを上述のＧＰＵ識別子の代わりに、またはそれに加えて使用することができる。例えば、両方のＧＰＵが与えられたフレームについてフィードバック・データを同じロケーションに書き込む、１つのフィードバック配列をシステム・メモリ内に用意する代わりに、それぞれのＧＰＵが異なるフィードバック配列の対応するエントリに書き込むことができ、またフィードバック・データは、タイミング情報、例えば、それぞれのＧＰＵが特定のフレームを終了したときを示すタイムスタンプを含むことができる。この実施形態では、グラフィックス・ドライバは、一方のＧＰＵが他のＧＰＵよりも多いフレーム当たり時間を一貫して使用し、それに応じてクリップ矩形を調整し、負荷分散するかどうかを判定するためにタイミング情報を使用するように構成される。いくつかのシステム実装では、タイムスタンプはＧＰＵのパフォーマンスを正確には反映しえず、さらに、それぞれのＧＰＵのタイムスタンプのシーケンスからの相対的負荷を決定することは、一般に、上述のような負荷係数の単純な計算に比べて多くの計算ステップ数を必要とすることに留意されたい。しかしながら、本発明のいくつかの実施形態は、ＧＰＵ識別子の代わりに、またはそれに加えて、フィードバック・データのタイミング情報を含むことができることは理解されるであろう。

マルチプロセッサ・グラフィックス処理システムは、２つよりも多いＧＰＵを含むことができ、プロセス４００、５００は、前記システムで使用するように適合できる。例えば、本発明の一実施形態は、３つのＧＰＵを備え、それぞれのＧＰＵは、図６に示されているように、表示領域の異なる水平バンドを割り当てられる。Ｍライン表示領域６００は、ライン１からＫまでを含む上側部分６０２、ラインＫ＋１からＬまでを含む中間部分６０４、Ｌ＋１からＭまでを含む下側部分６０６に分割される。上側６０２のデータは、識別子値「０」を持つＧＰＵ ６１４ａ（本明細書ではＧＰＵ−０と呼ばれる）により生成され、中間部分６０４のデータは、識別子値「１」を持つＧＰＵ ６１４ｂ（本明細書ではＧＰＵ−１と呼ばれる）により生成され、下側部分６０６のデータは、識別子値「２」を持つＧＰＵ ６１４ｃ（本明細書ではＧＰＵ−２と呼ばれる）により生成される。負荷分散は、値ＫとＬを調整することにより達成される。

より具体的には、一実施形態では、それぞれのＧＰＵに対するコマンド・ストリームは、図３のと類似しているが、図７に示されているように、次元Ｂの２つのフィードバック配列（本明細書ではｆｅｅｄｂａｃｋ０１［０：Ｂ−１］とｆｅｅｄｂａｃｋ１２［０：Ｂ−１］と呼ばれる）が用意される。ライト・ノティファイヤ・コマンド３０６への応答として、ＧＰＵ−０は、その識別子値フィードバック配列７０２内のロケーションに書き込み（書き込みは、図７の矢印により示される）、ＧＰＵ−１は、その識別子値をｆｅｅｄｂａｃｋ０１配列７０２とｆｅｅｄｂａｃｋ１２配列７０４の両方のそれぞれのロケーションに書き込み、ＧＰＵ−２は、その識別子値をｆｅｅｄｂａｃｋ１２配列７０４内のロケーションに書き込む。その結果、ｆｅｅｄｂａｃｋ０１配列の平均値は、ＧＰＵ−０とＧＰＵ−１上の相対的負荷を反映するが、ｆｅｅｄｂａｃｋ１２配列の平均値はＧＰＵ−１とＧＰＵ−２上の相対的負荷を反映する。

負荷分散のため、グラフィックス・ドライバは、例えば、上述の図５のプロセス５００に従って、ｆｅｅｄｂａｃｋ０１配列から決定された負荷係数に基づいて値Ｋを調整し（負荷係数が０．５の場合に均衡が生じる）、例えば、プロセス５００に従って、ｆｅｅｄｂａｃｋ１２配列から決定された負荷係数に基づいて値Ｌを調整する（負荷係数が１．５の場合に均衡が生じる）。ＧＰＵ−０とＧＰＵ−２の相対的負荷は直接比較されないが、時間が経過すると、３つの負荷すべてがほぼ等しくなる傾向を有する。例えば、ＧＰＵ−１上の負荷がＧＰＵ−０上の負荷を超える場合、ｆｅｅｄｂａｃｋ０１配列内のエントリの平均値は０．５を超え、その結果、値Ｋは増大され、それにより、ＧＰＵ−１上の負荷は減少する。ＧＰＵ−１上の低減された負荷がＧＰＵ−２上の負荷よりも小さくなると、この差異はｆｅｅｄｂａｃｋ０２配列内のエントリの平均値に反映され、この平均値は１．５を超え、応答として、値Ｌは増大され、それにより、再びＧＰＵ−１上の負荷は増大する。この変化の結果、値Ｋの調整が行われ、というように続く。当業者であれば、時間が経過するうちに、この負荷分散プロセスは３つの負荷すべてを等しくする傾向があることを理解するであろう。何らかの不安定性が永続することがあるが、これは、新しい値Ｋおよび／またはＬに対する応答としてクリップ矩形を修正することに関連するオーバーヘッドが十分に小さい限り許容可能である。

この負荷分散手法は、さらに、任意の数のＧＰＵを備えるシステムに拡張することができることは理解されるであろう。例えば、表示領域は、任意の数の水平バンドに分割することができ、それぞれのバンドは異なるＧＰＵに割り当てられる。このような実施形態では、フィードバック配列の個数は、一般に、ＧＰＵの個数よりも１つ小さい。それとは別に、垂直バンドを使用することもできる。

それぞれのフィードバック配列に書き込む２つのＧＰＵが互いに異なる識別子を持つ限り、特定のＧＰＵの識別子がすべてのＧＰＵにわたって一意的である必要はないことにも留意されたい。例えば、図６に示されている実施形態では、ＧＰＵ ６１４ａ、６１４ｃは、両方とも、識別子「０」を割り当てられる可能性がある。図７が示しているように、これらのＧＰＵは、その識別子を同じフィードバック配列に書き込まないので、曖昧さが生じることにならない。

他の代替え実施形態では、表示領域の水平分割と垂直分割の組合せを使用して、表示領域のいくつかの部分をＧＰＵに割り当てることができる。例えば、図８は、４つのセクション８０１〜８０４に分割される、それぞれＮ個のピクセルを含むＭ本のラインからなる表示領域８００を示している。セクション８０１〜８０４は、それぞれ、矢印により示されているように、４つのＧＰＵ ８１４ａ〜８１４ｄによりレンダリングされる。それぞれのＧＰＵ ８１４ａ〜８１４ｄは、異なる識別子値（０、１、２、３）を割り当てられる。この実施形態では、画像の複雑度は、一般に、左側と右側とでほぼ等しく、その場合、垂直境界ラインＪは固定されたままとすることができる（例えば、Ｊ＝Ｎ／２）。２つのフィードバック配列が用意され、ＧＰＵ−０（８１４ａ）とＧＰＵ−１（８１４ｂ）は、その識別子を第１のフィードバック配列ｆｅｅｄｂａｃｋ０１に書き込むが、ＧＰＵ−２（８１４ｃ）とＧＰＵ−３（８１４ｄ）は、その識別子を第２のフィードバック配列ｆｅｅｄｂａｃｋ２３に書き込む。セクション８０１と８０２を分割する境界ラインＫは、ｆｅｅｄｂａｃｋ０１配列内のエントリの平均値に基づき調整されるが、セクション８０３および８０４を分割する境界ラインＬは、ｆｅｅｄｂａｃｋ２３配列内のエントリの平均値に基づき調整される。

さらに他の代替え実施形態では、垂直境界ラインＪも調整可能である。例えば、ＧＰＵ−０とＧＰＵ−１は、それぞれ二次（列）識別子値「０」を割り当てることが可能であり、ＧＰＵ−２とＧＰＵ−３は、それぞれ、値「１」を持つ二次識別子を割り当てられる。第３のフィードバック配列ｆｅｅｄｂａｃｋＣを用意することができ、それぞれのＧＰＵは、一次識別子をｆｅｅｄｂａｃｋ０１配列とｆｅｅｄｂａｃｋ２３配列のうちの適切な一方に書き込むことに加えて、二次識別子をｆｅｅｄｂａｃｋＣ配列に書き込む。その後、垂直境界ラインＪは、ｆｅｅｄｂａｃｋＣ配列内のエントリの平均値に基づいて調整することができる。それとは別に、一次識別子（値０〜３を持つ）は、垂直分割に関連付けることができ、二次識別子（値０と１を持つ）は、水平分割に関連付けられる。

本明細書で説明されている手法は、さらに、ＰＣＩＸ（６４ビットＰＣＩ Ｅｘｐｒｅｓｓ）バスまたは現在開発中の３ＧＩＯ（第三世代入力／出力）バスなどの高速バスによって接続された異なる拡張カード上に異なるＧＰＵが配置されている「マルチカード」グラフィックス処理サブシステムでも使用できる。マルチカード・システム９００の一例が図９に示されている。２つのグラフィックス・カード９１２ａ、９１２ｂは、高速バス９０８により相互接続され、任意の数のカードを組み込むことができ、また高速バス９０８は、一般に、コンピュータ・システムの他の要素（例えば、図１に示されているようにシステム１００の様々なコンポーネント）にも接続することは理解されるであろう。それぞれのグラフィックス・カードは、それぞれのＧＰＵ ９１４ａ、９１４ｂと、ディスプレイ・バッファ９２２ａ、９２２ｂを含むそれぞれのグラフィックス・メモリ９１６ａ、９１６ｂを持つ。カード９１２ａは、ディスプレイ・バッファ９２２ａからディスプレイ・デバイス９１０にピクセル・データを供給するスキャンアウト制御論理回路９２０を備える。カード９１２ｂは、さらに、スキャンアウト制御論理回路を備えることもできるが、この例では、カード９１２ｂは、ディスプレイ・デバイスに接続されておらず、カード９１２ｂ内に存在する任意のスキャンアウト制御論理回路を無効にすることができる。

この配列では、空間並列方式を実装することができ、それぞれのＧＰＵ ９１４ａ、９１４ｂはそれぞれのフレームの一部をディスプレイ・バッファ９２２ａ、９２２ｂにレンダリングする。フレームを表示するために、ディスプレイ・バッファ９２２ｂからのピクセル・データは、バス９０８を介してディスプレイ・バッファ９２２ａに転送され（例えば、従来のブロック転送、またはＢｌｉｔ、オペレーションを使用して）、そこから、ピクセル・データがスキャンアウト制御論理回路９２０により読み出される。

上述のような負荷分散は、このシステム内に実装することができ、またデータ転送に要する時間を考慮すると都合がよい。例えば、図１０は、一般に図３のコマンド・ストリーム３００に類似のＧＰＵ ９１４ａ、９１４ｂに対するそれぞれのコマンド・ストリーム１０００ａ、１０００ｂを示している。それぞれのコマンド・ストリームは、クリップ矩形コマンド（ＣＲ）１００２ａ、１００２ｂから始まり、その後、フレームＦ０に対するレンダリング・コマンド１００４ａ、１００４ｂが続く。上述の単一カードの実装のように、異なるクリップ矩形境界がそれぞれのＧＰＵ ９１４ａ、９１４ｂについて用意され、それぞれ、フレームの異なる部分をレンダリングし、それぞれのＧＰＵに対するレンダリング・コマンドは、特定の実施形態に関して適宜同一であるかまたは異なる。

この実施形態では、ディスプレイ・バッファ９２２ｂからのピクセル・データは、スキャンアウトに先立ってディスプレイ・バッファ９２２ａに転送される。したがって、ＧＰＵ ９１４ｂについて、レンダリング・コマンド１００４ｂの後に、ローカル・ディスプレイ・バッファ９２２ｂからカード９１２ａ上のディスプレイ・バッファ９２２ａにピクセル・データを転送し、そのデータをスキャンアウトするようにＧＰＵ ９１４ｂに命令するＢｌｉｔコマンド１００６が続く。ＧＰＵ ９１４ａは、ピクセル・データを直接ディスプレイ・バッファ９２２ａに書き込むので、Ｂｌｉｔコマンドは、コマンド・ストリーム１０００ａ内に必要ではなく、したがってＧＰＵ ９１４ａに対するレンダリング・コマンド１００４ａの後に「ｎｏ−ｏｐ」１００５が続く。ｎｏ−ｏｐは、例えば、後のコマンドの実行を単純に遅らせるコマンド（そのようなコマンドは当業で知られている）、コマンドなし、またはコマンド・ストリーム内に現れるＢｌｉｔコマンドを無視するようＧＰＵ ９１４ａに命令するコマンドとすることができる。

フレームＦ０に対するライト・ノティファイヤ・コマンド１００８ａは、コマンド・ストリーム１０００ａ内のｎｏ−ｏｐコマンド１００５の後に続き、対応するライト・ノティファイヤ・コマンド１００８ｂは、Ｂｌｉｔコマンド１００６の後に続く。ライト・ノティファイヤ・コマンド１００８ａ、１００８ｂは、図４のプロセス４００を参照しつつ上述のライト・ノティファイヤ・コマンドと同様に実装することができる。図５のプロセス５００などの負荷分散プロセスは、負荷を均衡させるために使用することができる。

フレームＦ０に対するライト・ノティファイヤ・コマンド１００８ｂは、フレームＦ０に対するＢｌｉｔオペレーションが実行されるまでＧＰＵ ９１４ｂにより実行されないため、Ｂｌｉｔオペレーションに要する時間が負荷分散プロセス内を占めることに留意されたい。したがって、ＧＰＵ ９１４ａに対するレンダリング時間は、ＧＰＵ ９１４ｂのレンダリング時間＋Ｂｌｉｔ時間と釣り合いがとられる。

前景領域（常にというわけではないがほとんどの場合、表示領域の下側の）が背景領域に比べて一貫して複雑であるシーンをレンダリングするために使用されるいくつかのマルチカード実施形態では、シーンの背景領域を処理するためＧＰＵ ９１４ａを割り当て、前景領域を処理するためＧＰＵ ９１４ｂを割り当てることによりパフォーマンスが向上する。例えば、図２では、前景が表示領域２００の下側に向かって現れると仮定する。その場合、ＧＰＵ ９１４ａは、上側領域２０２をレンダリングするために割り当てられ、ＧＰＵ ９１４ｂは、下側領域２０４をレンダリングするために割り当てられる。前景（下側）領域の複雑度が高いほど、ＧＰＵ ９１４ｂのレンダリング時間は延びる傾向がある。それに応答して、本明細書で説明されている負荷分散プロセスは、境界ラインＰを表示領域の下側へ移動させる傾向がある。これは、下側領域２０４に含まれるデータのラインの数を減らし、Ｂｌｉｔコマンド１００６によりディスプレイ・バッファ９２２ａに転送される必要のあるデータの量を減らす。その結果、データ転送ではなく計算により多くのＧＰＵ ９１４ｂの処理能力が使われ、正味効率利得が生じる。

当業者であれば、すべてのＧＰＵからのピクセル・データがスキャンアウトに先立って単一のディスプレイ・バッファに転送される単一カードのマルチプロセッサ・システムの実施形態でも使用されうることを理解するであろう。例えば、図１のシステム１１２では、ディスプレイ・バッファ１２２ｂからのデータは、スキャンアウトのためディスプレイ・バッファ１２２ａに転送することが可能であり、スキャンアウト制御論理回路１２０は、フレームに対するすべてのピクセル・データを取得するためディスプレイ・バッファ１２２ａに単にアクセスすることができる。この実施形態では、ＧＰＵ １１４ｂに対して、ライト・ノティファイヤ命令の前にＢｌｉｔオペレーションを実行するよう命令することができるが、ＧＰＵ １１４ａにはｎｏ−ｏｐを与えられる。

本発明は、特定の実施形態に関して説明されたが、当業者であれば、様々な修正形態も可能であることを理解するであろう。例えば、マルチプロセッサ・グラフィックス処理システムでは、グラフィックス・カードにＧＰＵをいくつでも搭載することができ、またカードをいくつでも備えることができ、例えば、４ ＧＰＵサブシステムは、それぞれ２つのＧＰＵを備える２つのカードを使用して実装することが可能であるか、または３ ＧＰＵサブシステムは、１つのＧＰＵを備える第１のカードと２つのＧＰＵを備える第２のカードを含むことが可能である複数のＧＰＵのうちの１つまたは複数は、マザーボード搭載のグラフィックス・コプロセッサとすることができる。

ディスプレイ・フレームのレンダリングは、水平バンドおよび／または垂直バンド内のＧＰＵに分割することができる。当業者であれば、垂直バンドを使用すると、異なるＧＰＵによりレンダリングされる領域のサイズの均一さが増し（画像複雑度は、通常、上から下へよりも左から右へのほうが変化が少ないため）、水平バンドを使用すると、水平行向きのディスプレイ・デバイス内でスキャンアウト・オペレーションを簡素化できる（ピクセルの特定の行を読み込むためにＧＰＵのディスプレイ・バッファを１つだけアクセスするため）。さらに、フレームを水平と垂直の両方の境界にそってＧＰＵ間で分割することができ、上述のようにいずれか、または両方の境界にそって負荷分散を実行することができる。

本発明のいくつかの実施形態は、専用ハードウェア、汎用または専用プロセッサ上で実行するソフトウェア、またはそれらの任意の組合せを使用して実装することができる。これらの実施形態は、特定の実装内の別々の集積回路デバイスに対応する場合も対応しない場合もある機能ブロックに関して説明されている。本発明の開示では、汎用コンピューティング・システムを参照している場合があるが、本発明の開示を利用しようとする当業者であれば、本発明は、ゲーム機などの専用コンピューティング・システムまたは複数のグラフィックス・プロセッサによりグラフィックス処理機能を実現する他のコンピューティング・システムを含む、他の様々な実施形態で使用することができることを理解するであろう。

本発明の様々な特徴を具現化するコンピュータ・プログラムは、格納および／または伝送のためのコンピュータ可読媒体上で符号化することができ、好適な媒体は、磁気ディスクまたはテープ、コンパクト・ディスク（ＣＤ）またはＤＶＤ（デジタル・ビデオ・ディスク）などの光記憶媒体、フラッシュ・メモリ、インターネットを含む、様々なプロトコルに準拠する有線、光、および／または無線ネットワークを介して送信する搬送波信号を含む。プログラム・コードにより符号化されたコンピュータ可読媒体は、マルチプロセッサ・グラフィックス・カードなどの互換性のあるデバイスとともにパッケージ化されるか、または他のデバイスから別に提供されるようにできる（例えば、インターネットによるダウンロードを介して）。

そのため、本発明は、特定の実施形態に関して説明されているが、本発明は、特許請求の範囲内のすべての変更形態と均等物を対象とすることを意図されていることは理解されるであろう。

本発明の一実施形態によるコンピュータ・システムの簡略化されたブロック図である。 本発明の一実施形態による空間並列方式を示す表示領域の図である。 本発明の一実施形態によるコマンド・ストリームを示す図である。 本発明の一実施形態によるグラフィックス処理ユニットからフィードバック・データを供給するプロセスの流れ図である。 本発明の一実施形態による２つのグラフィックス処理ユニットの間で負荷分散を行うプロセスの流れ図である。 本発明の一実施形態による３方向空間並列方式を示す表示領域の図である。 本発明の一実施形態による３方向空間並列方式のフィードバック・アレイのペアを示す図である。 本発明の一実施形態による４方向空間並列方式を示す表示領域の図である。 本発明の一実施形態によるマルチカード・グラフィックス処理システムの簡略化されたブロック図である。 本発明の一実施形態によるマルチカード・グラフィックス処理システムのコマンド・ストリームの図である。

Claims (22)

1. 並列動作するように構成された複数のグラフィックス・プロセッサに命令を与えるＣＰＵによって該複数のグラフィックス・プロセッサの負荷分散を行うための方法であって、
   前記ＣＰＵによって、表示領域を、前記複数のグラフィックス・プロセッサのうちの第１のプロセッサによりレンダリングされる少なくとも第１の部分と前記複数のグラフィックス・プロセッサのうちの第２のプロセッサによりレンダリングされる第２の部分とに分割するステップと、
   前記ＣＰＵによって、フレームをレンダリングするよう前記複数のグラフィックス・プロセッサに命令し、前記第１と第２のグラフィックス・プロセッサは、前記表示領域の前記第１と第２の部分に対するレンダリングをそれぞれ実行するステップと、
   前記ＣＰＵによって、フィードバック・データが前記第１と第２のグラフィックス・プロセッサに対するそれぞれのレンダリング時間を反映するデータであり、前記第１と第２のグラフィックス・プロセッサから前記フレームに対する前記フィードバック・データを受信するステップと、
   前記ＣＰＵによって、前記フィードバック・データに基づき、前記第１と第２のグラフィックス・プロセッサのそれぞれの負荷の間に不均衡が存在するかどうかを判定するステップと、
   不均衡が存在する場合に、
   前記ＣＰＵによって、前記フィードバック・データに基づき、前記第１と第２のグラフィックス・プロセッサのうちのどちらにより重い負荷がかかっているかを識別するステップと、
   前記ＣＰＵによって、前記第１と第２のグラフィックス・プロセッサのうちのより重い負荷がかかっているプロセッサでレンダリングされる表示領域の前記第１と第２の部分のうちの前記一方のサイズを増やし、前記表示領域の前記第１と第２の部分の前記他方のサイズを減らすように前記表示領域を再分割するステップと
   を含んでおり、
   前記フィードバック・データは、前記第１と第２のグラフィックス・プロセッサのうちのどちらがフレームのレンダリングを最後に終了するかを示すデータを含み、
   前記受信するステップは、複数のフレームのそれぞれに対する前記フィードバック・データを受信することを含み、
   前記判定するステップは、前記複数のフレームに対する前記フィードバック・データから負荷係数を計算することを含み、前記負荷係数は前記第１と第２のグラフィックス・プロセッサのうちの一方が前記レンダリングを最後に終了する頻度を示す、方法。
2. 前記表示領域の前記第１の部分は、ピクセルの連続的なラインの第１の数を含み、前記表示領域の前記第２の部分は、ピクセルの連続的なラインの第２の数を含む請求項１に記載の方法。
3. 前記表示領域を再分割するステップは、ピクセルの連続的なラインの第３の数を前記表示領域の前記第１の部分から前記表示領域の前記第２の部分にシフトすることを含み、前記第３の数は前記第１の数よりも小さい請求項２に記載の方法。
4. ピクセルの前記ラインは、水平方向に向けられている請求項２に記載の方法。
5. ピクセルの前記ラインは、垂直方向に向けられている請求項２に記載の方法。
6. さらに、前記ＣＰＵによって、異なる１つのプロセッサ識別子を前記第１と第２のグラフィックス・プロセッサのそれぞれに割り当てることを含み、
   前記第１と第２のグラフィックス・プロセッサのそれぞれから受信された前記フィードバック・データは、前記それぞれのプロセッサ識別子を含む請求項１に記載の方法。
7. 前記プロセッサ識別子のそれぞれは数値を持つ請求項６に記載の方法。
8. 前記フィードバック・データは、タイムスタンプを含む請求項１に記載の方法。
9. 最後に終了する前記第１と第２のグラフィックス・プロセッサのうちの一方からの前記フィードバック・データが前記第１と第２のグラフィックス・プロセッサのうちの他方からのフィードバック・データを上書きする請求項１に記載の方法。
10. さらに、
    前記ＣＰＵによって、それぞれ前記複数のフレームのうちの異なる１つのフレームに関連付けられている複数の格納先を用意することを含み、
    前記複数のフレームのそれぞれに対する前記フィードバック・データを受信する前記ステップは、
    前記フレームに対する前記表示領域の前記第１の部分をレンダリングした後、前記複数のフレームのそれぞれについて前記格納先のうちの関連付けられた１つに第１のプロセッサ識別子を格納するように前記第１のグラフィックス・プロセッサに命令することと、
    前記フレームに対する前記表示領域の前記第２の部分をレンダリングした後、前記複数のフレームのそれぞれについて前記格納先のうちの関連付けられた１つに第１のプロセッサ識別子と異なる第２のプロセッサ識別子を格納するよう前記第２のグラフィックス・プロセッサに命令することと
    を含む請求項１に記載の方法。
11. フレームのレンダリングを最後に終了した前記第１と第２のグラフィックス・プロセッサのうちの前記一方の前記プロセッサ識別子が前記格納先の中の前記第１と第２のグラフィックス・プロセッサのうちの前記他方の前記プロセッサ識別子を上書きする請求項１０に記載の方法。
12. 前記第１と第２のグラフィックス・プロセッサのそれぞれに数値識別子が関連付けられ、前記負荷係数は、それぞれのフレームを最後に終了した前記プロセッサの前記数値識別子の前記複数のフレーム上でとった平均である請求項１に記載の方法。
13. 判定する前記ステップは、さらに、前記負荷係数を前記数値識別子の算術平均と比較することを含む請求項１２に記載の方法。
14. 再分割の前記ステップ時に、前記表示領域の前記第１の部分の前記サイズが縮小される量は、前記負荷係数と前記算術平均との差の大きさに少なくとも一部は依存する請求項１２に記載の方法。
15. さらに、
    前記ＣＰＵによって、前記第１と第２のグラフィックス・プロセッサのそれぞれについて、前記フレームのレンダリング・コマンドの集合を含むコマンド・ストリームを生成することと、
    前記ＣＰＵによって、レンダリング・コマンドの前記集合の後に、前記第１と第２のグラフィックス・プロセッサのそれぞれについてライト・ノティファイヤ・コマンドをコマンド・ストリーム内に挿入することと
    を含み、前記第１と第２のグラフィックス・プロセッサはそれぞれ、前記フィードバック・データを格納先に送信することにより前記ライト・ノティファイヤ・コマンドに応答する請求項１に記載の方法。
16. グラフィックス処理システムであって、
    グラフィックス・ドライバ・モジュールと、
    表示領域のそれぞれの部分をレンダリングし、フィードバック・データを前記グラフィックス・ドライバ・モジュールに供給するため並列動作するように構成された複数のグラフィックス・プロセッサとを備え、
    前記グラフィックス・ドライバ・モジュールは、さらに、前記フィードバック・データに基づき、前記複数のグラフィックス・プロセッサの２つのそれぞれの負荷の間の不均衡を検出し、不均衡を検出したことに対する応答として、前記２つのグラフィックス・プロセッサのうちの負荷が重い方によりレンダリングされる前記表示領域の第１の部分のサイズを減らし、前記２つのグラフィックス・プロセッサのうちの他方によりレンダリングされる前記表示領域の第２の部分のサイズを増やすように構成されており、
    前記フィードバック・データは、前記２つのグラフィックス・プロセッサのうちフレームのレンダリングを最後に終了したのはどちらであるのかを示す情報を含み、
    前記フィードバック・データは、最後に終了した前記２つのグラフィックス・プロセッサのうちの前記１つの数値識別子を含み、
    前記グラフィックス・ドライバ・モジュールは、さらに、複数のフレームについて前記数値識別子からの負荷係数を計算するよう構成され、
    前記負荷係数は、前記２つのグラフィックス・プロセッサのうちの一方が前記レンダリングを最後に終了する頻度を示す、グラフィックス処理システム。
17. さらに、それぞれ前記グラフィックス・プロセッサのそれぞれの１つに結合され、結合された前記グラフィックス・プロセッサによりレンダリングされる前記表示領域の前記部分に対するピクセル・データを格納する複数のグラフィックス・メモリを備える請求項１６に記載のグラフィックス処理システム。
18. さらに、前記複数のグラフィックス・メモリに結合され、前記グラフィックス・メモリから前記表示領域に対するピクセル・データを読み取るように構成されたスキャンアウト制御論理回路を備える請求項１７に記載のグラフィックス処理システム。
19. 前記グラフィックス・ドライバ・モジュールは、さらに、前記複数のグラフィックス・プロセッサに対しコマンド・ストリームを生成するように構成され、
    前記コマンド・ストリームは
    フレームのレンダリング・コマンドの集合と、
    前記フィードバック・データを送信する前記２つのグラフィックス・プロセッサのそれぞれへの命令であって、前記フィードバック・データは、該フィードバック・データを送信する前記グラフィックス・プロセッサが前記レンダリング・コマンドの集合を実行したことを示す、命令と、
    を含む請求項１６に記載のグラフィックス処理システム。
20. 前記グラフィックス・ドライバ・モジュールは、さらに、前記負荷係数が第１しきい値よりも大きいか、または、該第１しきい値よりも低い第２しきい値よりも小さい場合に不均衡を検出するように構成される請求項１６に記載のグラフィックス処理システム。
21. 前記表示領域のそれぞれの部分は、ピクセルの連続的ラインのいくつかを含み、前記２つのグラフィックス・プロセッサは、隣接する部分をレンダリングするように構成される請求項１６に記載のグラフィックス処理システム。
22. 前記グラフィックス・ドライバは、さらに、前記第１の部分から前記第２の部分にピクセルのラインのいくつかをシフトすることにより、前記第１の部分の前記サイズを減らし、前記第２の部分の前記サイズを増やすように構成される請求項２１に記載のグラフィックス処理システム。

Images