JP7481560B2 - グラフィック処理のための方法、コンピュータシステム、及びコンピュータ可読媒体 - Google Patents

Description

本開示は、グラフィック処理に関し、より具体的には、アプリケーション用の画像をレンダリングするときのマルチＧＰＵ連携に関する。

近年、クラウドゲームサーバとネットワークを介して接続されたクライアントとの間でストリーミング形式のオンラインまたはクラウドゲームを可能にするオンラインサービスが継続的に推進されている。ストリーミング形式は、オンデマンドのゲームタイトルの利用可能性、より複雑なゲームを実行する能力、マルチプレイヤーゲームのためのプレイヤー間のネットワーク機能、プレイヤー間のアセットの共有、プレイヤー及び／または観客間のインスタントエクスペリエンスの共有、友人がフレンドプレイビデオゲームを見ることを可能にする、友人を友人の進行中のゲームプレイに参加させるなどにより、いっそう人気が高まっている。

クラウドゲームサーバは、１つまたは複数のクライアント及び／またはアプリケーションにリソースを提供するように構成することができる。すなわち、クラウドゲームサーバは、高スループットが可能なリソースで構成され得る。例えば、個々のグラフィック処理ユニット（ＧＰＵ）が達成できるパフォーマンスには限界がある。シーンを生成するときに、さらに複雑なシーンをレンダリングしたり、さらに複雑なアルゴリズム（例えば、マテリアル、ライティング）を使用したりするには、複数のＧＰＵを使用して単一の画像をレンダリングすることが望ましい場合がある。しかしながら、これらのグラフィック処理ユニットを均等に使用することは達成困難である。さらに、従来のテクノロジを使用してアプリケーション用の画像を処理するために複数のＧＰＵが存在する場合でも、対応するスクリーンピクセル数とジオメトリ密度の両方の増加をサポートする能力はない（例えば、４つのＧＰＵにより画像に対して４倍のピクセルを書き込むこと及び／または４倍の頂点またはプリミティブを処理することは不可能である）。

本開示の実施形態は、このような背景の下になされたものである。

本開示の実施形態は、レンダリング中にジオメトリ解析を実行して、画像フレームのレンダリングのためのＧＰＵへのスクリーン領域の動的割り当てに使用される情報を生成することによる、及び／またはレンダリングの前にジオメトリ解析を実行することによる、及び／またはレンダリングフェーズ中にＧＰＵのレスポンシビリティの割り当てを再分散するために、レンダリングフェーズ中にタイミング解析を実行することによる、アプリケーション用のジオメトリのマルチＧＰＵレンダリングなど、複数のＧＰＵ（グラフィック処理ユニット）を連携して使用して単一の画像をレンダリングすることに関する。

本開示の実施形態は、グラフィック処理のための方法を開示する。方法は、複数のグラフィック処理ユニット（ＧＰＵ）を使用してアプリケーション用のグラフィックをレンダリングすることを含む。方法は、複数のジオメトリのピースを含む画像フレームをレンダリングするために複数のＧＰＵを連携して使用することを含む。方法は、レンダリングのプレパスフェーズ中に、複数のジオメトリのピース及び複数のスクリーン領域に対するそれらの関係に関する情報をＧＰＵで生成することを含む。方法は、レンダリングの後続のフェーズで複数のジオメトリのピースをレンダリングするために、情報に基づいて複数のスクリーン領域を複数のＧＰＵに割り当てることを含む。

本開示の他の実施形態では、プロセッサと、プロセッサに結合されたメモリとを含むコンピュータシステムが開示され、メモリは命令を格納しており、命令は、コンピュータシステムにより実行されると、グラフィック処理のための方法をコンピュータシステムに実行させる。方法は、複数のグラフィック処理ユニット（ＧＰＵ）を使用してアプリケーション用のグラフィックをレンダリングすることを含む。方法は、複数のジオメトリのピースを含む画像フレームをレンダリングするために複数のＧＰＵを連携して使用することを含む。方法は、レンダリングのプレパスフェーズ中に、複数のジオメトリのピース及び複数のスクリーン領域に対するそれらの関係に関する情報をＧＰＵで生成することを含む。方法は、レンダリングの後続のフェーズで複数のジオメトリのピースをレンダリングするために、情報に基づいて複数のスクリーン領域を複数のＧＰＵに割り当てることを含む。

本開示のさらに他の実施形態は、グラフィック処理のためのコンピュータプログラムを格納する非一時的コンピュータ可読媒体を開示する。コンピュータ可読媒体は、複数のグラフィック処理ユニット（ＧＰＵ）を使用してアプリケーション用のグラフィックをレンダリングするためのプログラム命令を含む。コンピュータ可読媒体は、複数のジオメトリのピースを含む画像フレームをレンダリングするために複数のＧＰＵを連携して使用するためのプログラム命令を含む。コンピュータ可読媒体は、レンダリングのプレパスフェーズ中に、複数のジオメトリのピース及び複数のスクリーン領域に対するそれらの関係に関する情報をＧＰＵで生成するためのプログラム命令を含む。コンピュータ可読媒体は、レンダリングの後続のフェーズで複数のジオメトリのピースをレンダリングするために、情報に基づいて複数のスクリーン領域を複数のＧＰＵに割り当てるためのプログラム命令を含む。

本開示の実施形態は、グラフィック処理のための方法を開示する。方法は、複数のグラフィック処理ユニット（ＧＰＵ）を使用してアプリケーション用のグラフィックをレンダリングすることを含む。方法は、複数のＧＰＵ間でのレンダリングの解析プレパスフェーズ中に画像フレームの複数のジオメトリのピースを処理するレスポンシビリティを分割することを含み、複数のジオメトリのピースのそれぞれが、対応するＧＰＵに割り当てられる。方法は、複数のスクリーン領域のそれぞれとの、複数のジオメトリのピースのそれぞれのオーバーラップを解析プレパスフェーズにおいて決定することを含む。方法は、複数のスクリーン領域のそれぞれとの、複数のジオメトリのピースのそれぞれのオーバーラップに基づいて、複数のジオメトリのピースおよび複数のスクリーン領域に対するそれらの関係に関する情報を複数のＧＰＵで生成することを含む。方法は、レンダリングの後続のフェーズ中に複数のジオメトリのピースをレンダリングするために、情報に基づいて複数のスクリーン領域を複数のＧＰＵに割り当てることを含む。

本開示の他の実施形態では、プロセッサと、プロセッサに結合されたメモリとを含むコンピュータシステムが開示され、メモリは命令を格納しており、命令は、コンピュータシステムにより実行されると、グラフィック処理のための方法をコンピュータシステムに実行させる。方法は、複数のグラフィック処理ユニット（ＧＰＵ）を使用してアプリケーション用のグラフィックをレンダリングすることを含む。方法は、複数のＧＰＵ間でのレンダリングの解析プレパスフェーズ中に画像フレームの複数のジオメトリのピースを処理するレスポンシビリティを分割することを含み、複数のジオメトリのピースのそれぞれが、対応するＧＰＵに割り当てられる。方法は、複数のスクリーン領域のそれぞれとの、複数のジオメトリのピースのそれぞれのオーバーラップを解析プレパスフェーズにおいて決定することを含む。方法は、複数のスクリーン領域のそれぞれとの、複数のジオメトリのピースのそれぞれのオーバーラップに基づいて、複数のジオメトリのピースおよび複数のスクリーン領域に対するそれらの関係に関する情報を複数のＧＰＵで生成することを含む。方法は、レンダリングの後続のフェーズ中に複数のジオメトリのピースをレンダリングするために、情報に基づいて複数のスクリーン領域を複数のＧＰＵに割り当てることを含む。

本開示のさらに他の実施形態は、グラフィック処理のためのコンピュータプログラムを格納する非一時的コンピュータ可読媒体を開示する。コンピュータ可読媒体は、複数のグラフィック処理ユニット（ＧＰＵ）を使用してアプリケーション用のグラフィックをレンダリングするためのプログラム命令を含む。コンピュータ可読媒体は、複数のＧＰＵ間でのレンダリングの解析プレパスフェーズ中に画像フレームの複数のジオメトリのピースを処理するレスポンシビリティを分割するためのプログラム命令を含み、複数のジオメトリのピースのそれぞれが、対応するＧＰＵに割り当てられる。コンピュータ可読媒体は、複数のスクリーン領域のそれぞれとの、複数のジオメトリのピースのそれぞれのオーバーラップを解析プレパスフェーズにおいて決定するためのプログラム命令を含む。コンピュータ可読媒体は、複数のスクリーン領域のそれぞれとの、複数のジオメトリのピースのそれぞれのオーバーラップに基づいて、複数のジオメトリのピースおよび複数のスクリーン領域に対するそれらの関係に関する情報を複数のＧＰＵで生成するためのプログラム命令を含む。コンピュータ可読媒体は、レンダリングの後続のフェーズ中に複数のジオメトリのピースをレンダリングするために、情報に基づいて複数のスクリーン領域を複数のＧＰＵに割り当てるためのプログラム命令を含む。

本開示の実施形態は、グラフィック処理のための方法を開示する。方法は、複数のグラフィック処理ユニット（ＧＰＵ）を使用してアプリケーション用のグラフィックをレンダリングすることを含む。方法は、複数のジオメトリのピースを含む画像フレームをレンダリングするために複数のＧＰＵを連携して使用することを含む。方法は、画像フレームのレンダリング中に、複数のジオメトリのピースのうちの１つまたは複数をより小さなピースに再分割し、これらのジオメトリのより小さな部分をレンダリングするレスポンシビリティを複数のＧＰＵ間で分割することを含み、ジオメトリのより小さな部分のそれぞれは、対応するＧＰＵによって処理される。方法は、再分割されていないジオメトリのピースについて、ジオメトリのピースをレンダリングするレスポンシビリティを複数のＧＰＵ間で分割することを含み、これらのジオメトリのピースのそれぞれが、対応するＧＰＵによって処理される。

本開示の他の実施形態では、プロセッサと、プロセッサに結合されたメモリとを含むコンピュータシステムが開示され、メモリは命令を格納しており、命令は、コンピュータシステムにより実行されると、グラフィック処理のための方法をコンピュータシステムに実行させる。方法は、複数のグラフィック処理ユニット（ＧＰＵ）を使用してアプリケーション用のグラフィックをレンダリングすることを含む。方法は、複数のジオメトリのピースを含む画像フレームをレンダリングするために複数のＧＰＵを連携して使用することを含む。方法は、画像フレームのレンダリング中に、複数のジオメトリのピースのうちの１つまたは複数をより小さなピースに再分割し、これらのジオメトリのより小さな部分をレンダリングするレスポンシビリティを複数のＧＰＵ間で分割することを含み、ジオメトリのより小さな部分のそれぞれは、対応するＧＰＵによって処理される。方法は、再分割されていないジオメトリのピースについて、ジオメトリのピースをレンダリングするレスポンシビリティを複数のＧＰＵ間で分割することを含み、これらのジオメトリのピースのそれぞれが、対応するＧＰＵによって処理される。

本開示のさらに他の実施形態は、グラフィック処理のためのコンピュータプログラムを格納する非一時的コンピュータ可読媒体を開示する。コンピュータ可読媒体は、複数のグラフィック処理ユニット（ＧＰＵ）を使用してアプリケーション用のグラフィックをレンダリングするためのプログラム命令を含む。コンピュータ可読媒体は、複数のジオメトリのピースを含む画像フレームをレンダリングするために複数のＧＰＵを連携して使用するためのプログラム命令を含む。コンピュータ可読媒体は、画像フレームのレンダリング中に、複数のジオメトリのピースのうちの１つまたは複数をより小さなピースに再分割し、これらのジオメトリのより小さな部分をレンダリングするレスポンシビリティを複数のＧＰＵ間で分割するためのプログラム命令を含み、ジオメトリのより小さな部分のそれぞれは、対応するＧＰＵによって処理される。コンピュータ可読媒体は、再分割されていないジオメトリのピースについて、ジオメトリのピースをレンダリングするレスポンシビリティを複数のＧＰＵ間で分割するためのプログラム命令を含み、これらのジオメトリのピースのそれぞれが、対応するＧＰＵによって処理される。

本開示の他の態様は、本開示の原理の例として示される添付図面と併せて、下記の発明を実施するための形態から明らかになるであろう。

本開示は、添付図面と併せて、以下の詳細な説明を参照することにより、最も良く理解することができる。

本開示の実施形態による、レンダリング中にジオメトリ解析を実行して、画像フレームのさらなるレンダリングパスのためのＧＰＵへのスクリーン領域の動的割り当てに使用される情報を生成することによる、及び／またはレンダリングフェーズ前にジオメトリ解析を実行することによる、及び／またはジオメトリのピースを再分割し、結果として得られるジオメトリのより小さな部分を複数のＧＰＵに割り当てることによる、アプリケーション用のジオメトリのマルチＧＰＵ（グラフィック処理ユニット）レンダリングを含んで、単一の画像をレンダリングするために連携して複数のＧＰＵを実装するように構成された１つまたは複数のクラウドゲームサーバ間でネットワークを介してゲームを提供するためのシステムの図である。 本開示の一実施形態による、複数のＧＰＵが連携して単一の画像をレンダリングする、マルチＧＰＵアーキテクチャの図である。 本開示の実施形態による、レンダリング中にジオメトリ解析を実行することによる、及び／またはレンダリングの前にジオメトリ解析を実行することによる、及び／またはジオメトリのピースを再分割し、結果として得られるジオメトリのより小さな部分を複数のＧＰＵに割り当てることによる、アプリケーション用のジオメトリのマルチＧＰＵレンダリングのために構成された、複数のグラフィック処理ユニットリソースの図である。 本開示の一実施形態による、複数のＧＰＵが連携して単一の画像をレンダリングするように、マルチＧＰＵ処理用に構成されたグラフィックパイプラインを実装する、レンダリングアーキテクチャの図である。 本開示の一実施形態による、マルチＧＰＵレンダリングを実行するときに象限に再分割されるスクリーンの図である。 本開示の一実施形態による、マルチＧＰＵレンダリングを実行するときに複数のインターリーブされた領域に再分割されるスクリーンの図である。 本開示の一実施形態による、複数のＧＰＵが連携して単一の画像をレンダリングするときのスクリーン領域に対するオブジェクトテストを示す。 本開示の一実施形態による、複数のＧＰＵが連携して単一の画像をレンダリングするときのスクリーン領域に対するオブジェクトの一部のテストを示す。 本開示の一実施形態による、レンダリング中にジオメトリ解析を実行することによる、アプリケーション用のジオメトリのマルチＧＰＵレンダリングを含むグラフィック処理の方法を示す流れ図である。 本開示の一実施形態による、現在の画像フレームのレンダリング中に実行される現在の画像フレームのジオメトリの解析に基づくジオメトリレンダリングのためのＧＰＵへのスクリーン領域の動的割り当てを示すスクリーンの図である。 本開示の一実施形態による、画像フレームをレンダリングするＺプレパスフェーズ及びジオメトリフェーズを含む４つのオブジェクトを含む画像フレームのレンダリングを示す図であり、Ｚプレパスフェーズは、スクリーン領域の動的割り当てに使用される画像フレームのジオメトリレンダリングのためのＧＰＵへの情報を生成するために実行される。 本開示の一実施形態による、画像フレームをレンダリングするＺプレパスフェーズ及びジオメトリフェーズを含む４つのオブジェクトを含む画像フレームのレンダリングを示す図であり、Ｚプレパスフェーズは、スクリーン領域の動的割り当てに使用される画像フレームのジオメトリレンダリングのためのＧＰＵへの情報を生成するために実行される。 本開示の一実施形態による、画像フレームをレンダリングするＺプレパスフェーズ及びジオメトリフェーズを含む４つのオブジェクトを含む画像フレームのレンダリングを示す図であり、Ｚプレパスフェーズは、スクリーン領域の動的割り当てに使用される画像フレームのジオメトリレンダリングのためのＧＰＵへの情報を生成するために実行される。 本開示の一実施形態による、画像フレームをレンダリングしている間にレンダリングのＺプレパスフェーズ中に実行された現在の画像フレームのジオメトリの解析に基づいてジオメトリレンダリングのために、オブジェクト全体またはオブジェクトの一部に基づいたスクリーン領域のＧＰＵへの動的割り当てを使用して画像フレームをレンダリングすることを示している。 本開示の一実施形態による、画像フレームのジオメトリレンダリングのためのＧＰＵへのスクリーン領域の動的割り当てに使用される情報を生成するために、レンダリングのＺプレパスフェーズを実行するために、画像フレームのジオメトリのピースへのＧＰＵ割り当てをインターリーブすることを示す図である。 本開示の一実施形態による、レンダリングの前にジオメトリ解析を実行することによる、アプリケーション用のジオメトリのマルチＧＰＵレンダリングを含むグラフィック処理の方法を示す流れ図である。 本開示の一実施形態による、画像フレームのレンダリングフェーズの前に実行される解析プレパスを示す図であり、解析プレパスは、画像フレームのジオメトリレンダリングのためのＧＰＵへのスクリーン領域の動的割り当てに使用される情報を生成する。 本開示の一実施形態による、画像フレームのジオメトリレンダリングのためのＧＰＵへのスクリーン領域の動的割り当てに使用される情報を生成するために、解析プレパスを実行するときの、ジオメトリのピースとスクリーン領域の間の正確なオーバーラップの計算を示す図である。 本開示の一実施形態による、画像フレームのジオメトリレンダリングのためのＧＰＵへのスクリーン領域の動的割り当てに使用される情報を生成するために、解析プレパスを実行するときの、ジオメトリのピースとスクリーン領域の間の概算のオーバーラップの計算を示す一対の図である。 本開示の一実施形態による、ジオメトリのピースに対してＺプレパスフェーズを実行して画像フレームのジオメトリレンダリングのためにスクリーン領域をＧＰＵに動的に割り当てるために使用される情報を生成するときなど、レンダリングまたは解析フェーズ中にＧＰＵレスポンシビリティの割り当てを再分散するために、レンダリングまたは解析フェーズ中にタイミング解析を実行することによる、アプリケーション用のジオメトリのマルチＧＰＵレンダリングを含む、グラフィック処理のための方法を示す流れ図である。 本開示の一実施形態による、画像フレームのジオメトリレンダリングのためのＧＰＵへのスクリーン領域の動的割り当てに使用される情報を生成するために、レンダリングのＺプレパスフェーズを実行する、ＧＰＵ割り当ての様々な分散を示す図である。 本開示の一実施形態による、スクリーン領域においてジオメトリのピースをレンダリングするために複数のＧＰＵを使用することを示す図である。 本開示の一実施形態による、ジオメトリのピースをそれらの対応するドローコールとは順不同でレンダリングすることを示す図である。 本開示の様々な実施形態の態様を実行するために使用することができる例示的なデバイスのコンポーネントを示す。

以下の詳細な説明は、例示の目的で多くの特定の詳細を含むが、当業者であれば、以下の詳細に対する多くの変形及び変更が本開示の範囲内にあることを理解するであろう。したがって、以下で説明される本開示の態様は、この説明に続く特許請求の範囲への一般性を失うことなく、また限定を課すことなく示される。

一般的に言えば、個々のＧＰＵが達成できるパフォーマンスには限界があり、例えば、ＧＰＵをどれだけ大きくできるかの限界から導き出される。さらに複雑なシーンをレンダリングする、またはさらに複雑なアルゴリズム（例えば、マテリアル、ライティングなど）を使用するには、複数のＧＰＵを連携して使用して単一の画像フレームを生成及び／またはレンダリングすることが望ましい。例えば、画像フレーム内のオブジェクト及び／またはジオメトリのピース（piece:例えば、オブジェクトの一部、プリミティブ、ポリゴン、頂点など）のジオメトリ解析から決定された情報に基づいて、レンダリングのレスポンシビリティ（responsibility）が複数のＧＰＵ間で分割される。この情報は、インターリーブされる可能性のあるジオメトリと各スクリーン領域との間の関係を提供する。これにより、ＧＰＵはジオメトリをより効率的にレンダリングする、またはそれをすべてまとめてレンダリングするのを回避し得る。特に、本開示の様々な実施形態は、画像フレームのジオメトリの解析を提供し、画像フレームをレンダリングするレスポンシビリティをＧＰＵ間で動的かつ柔軟に割り当て、各ＧＰＵが最終的にその画像フレームに固有のものである（つまり、次の画像フレームでは、ＧＰＵのスクリーン領域への関連付けが異なる場合がある）スクリーン領域のセットのレスポンシビリティを持つことになるようにする。ジオメトリ解析と、画像フレームごとのＧＰＵへのレンダリングレスポンシビリティの動的な割り当てを通じて、本開示の実施形態は、ピクセル数（つまり、解像度）と複雑さの増加、及び／または幾何学的な複雑さの増加、及び／または、頂点及び／またはプリミティブあたりの処理量の増加をサポートする。具体的には、本開示の様々な実施形態は、画像フレームのジオメトリレンダリングのためにＧＰＵにスクリーン領域を動的に割り当てるレンダリング中にジオメトリ解析を実行することによって、アプリケーション用のジオメトリのマルチＧＰＵレンダリングを実行するように構成された方法及びシステムを説明し、ジオメトリ解析は、画像フレームのためにレンダリングされるジオメトリとスクリーン領域との間の関係を定義する情報に基づく。例えば、ジオメトリレンダリング前のＺプレパス中など、レンダリング中にジオメトリ解析の情報が生成される。具体的には、レンダリングの後続のフェーズ中にジオメトリレンダリングを実行するときに、ＧＰＵへのスクリーン領域のインテリジェントな割り当てを支援するために使用される情報をプレパスが生成するように、ハードウェアが構成される。本開示の他の実施形態は、画像フレームのレンダリングのそのフェーズのためにＧＰＵにスクリーン領域を動的に割り当てるために、レンダリングのフェーズの前にジオメトリ解析を実行することによって、アプリケーションのジオメトリのマルチＧＰＵレンダリングを実行するように構成された方法及びシステムを説明し、ジオメトリ解析は、画像フレームのためにレンダリングされるジオメトリとスクリーン領域との間の関係を定義する情報に基づく。例えば、情報は、シェーダ（例えば、ソフトウェア）を使用するなどして、レンダリングの前に実行されるプレパスで生成される。この情報は、ジオメトリレンダリングを実行するときに、スクリーン領域をＧＰＵにインテリジェントに割り当てるために使用される。本開示のさらに他の実施形態は、例えばドローコールによって処理または生成されたようなジオメトリのピースをジオメトリのより小さな部分に再分割し、ジオメトリのそれらのより小さな部分をレンダリングのために複数のＧＰＵに割り当て、ジオメトリのそれぞれのより小さな部分がＧＰＵに割り当てられるように構成される、方法及びシステムを説明する。利点として、例えばこれにより、複数のＧＰＵがより複雑なシーン及び／または画像を同じ時間量でレンダリングできるようになる。

様々な実施形態の上記の一般的な理解により、様々な図面を参照して実施形態の例の詳細をここに説明する。

本明細書全体を通して、「アプリケーション」または「ゲーム」または「ビデオゲーム」または「ゲームアプリケーション」への言及は、入力コマンドの実行を通して指示される任意のタイプのインタラクティブアプリケーションを表すことを意味する。説明目的のみで、インタラクティブアプリケーションは、ゲーム、文書処理、ビデオ処理、ビデオゲーム処理などのためのアプリケーションを含む。さらに、これらの用語は、置き換え可能である。

本明細書を通して、本開示の様々な実施形態は、４つのＧＰＵを有する例示的なアーキテクチャを使用するアプリケーションのためのマルチＧＰＵ処理またはジオメトリのレンダリングについて説明される。しかしながら、アプリケーションのジオメトリをレンダリングするときに、任意の数のＧＰＵ（例えば、２つ以上のＧＰＵ）が連携できることが理解される。

図１は、本開示の一実施形態による、アプリケーション用の画像（例えば、画像フレーム）をレンダリングするときにマルチＧＰＵ処理を実行するためのシステムの図である。このシステムは、本開示の実施形態に従って、１つまたは複数のクラウドゲームサーバ間のネットワークを介してゲームを提供するように構成されており、より具体的には、複数のＧＰＵを連携させてアプリケーションの単一の画像をレンダリングするように構成されており、それは例えば、画像フレームのジオメトリレンダリングのためにスクリーン領域をＧＰＵに動的に割り当てるために、レンダリング中またはレンダリング前に画像フレームのジオメトリのピースのジオメトリ解析を実行するとき、及び／または、例えばドローコールによって処理または生成されたようなジオメトリのピースをジオメトリのより小さな部分に再分割し、ジオメトリのそれらのより小さな部分をレンダリングのために複数のＧＰＵに割り当てるときであり、この場合は、ジオメトリのそれぞれのより小さな部分がＧＰＵに割り当てられる。クラウドゲームには、サーバでビデオゲームを実行して、ゲームでレンダリングされたビデオフレームを生成し、次いでそれをクライアントに送信して表示することが含まれる。具体的には、システム１００は、レンダリング前にインターリーブされたスクリーン領域に対して事前テストすることによって、アプリケーションのジオメトリの効率的なマルチＧＰＵレンダリングのために構成される。

図１は、クラウドゲームシステムの１つまたは複数のクラウドゲームサーバ間のジオメトリのマルチＧＰＵレンダリングの実施態様を示しているが、本開示の他の実施形態は、アプリケーションのジオメトリの効率的なマルチＧＰＵレンダリングを、複数のＧＰＵを有するハイエンドグラフィックカードを含む、パーソナルコンピュータやゲームコンソールなどの、スタンドアロンシステム内でレンダリングしながら領域テストを実行することによって提供する。

ジオメトリのマルチＧＰＵレンダリングは、様々な実施形態において（例えば、クラウドゲーム環境またはスタンドアロンシステム内で）、物理ＧＰＵ、または仮想ＧＰＵ、または両方の組み合わせを使用して実行され得ることも理解される。例えば、仮想マシン（例えば、インスタンス）は、複数のＣＰＵ、メモリモジュール、ＧＰＵ、ネットワークインタフェース、通信コンポーネントなどのハードウェア層の１つまたは複数のコンポーネントを利用するホストハードウェア（例えば、データセンターに配置される）のハイパーバイザを使用して作成することができる。これらの物理リソースは、ＣＰＵのラック、ＧＰＵのラック、メモリのラックなどのラックに配置でき、インスタンスに使用される（インスタンスの仮想化されたコンポーネントを構築するときなど）コンポーネントの組み立てとアクセスのためのファブリックを容易にするラックスイッチのトップを使用して、ラック内の物理リソースにアクセスできる。通常、ハイパーバイザは、仮想リソースで構成された複数のインスタンスの複数のゲストオペレーティングシステムを提示できる。すなわち、オペレーティングシステムのそれぞれは、１つまたは複数のハードウェアリソース（例えば、対応するデータセンターに配置される）によってサポートされる仮想化リソースの対応するセットで構成され得る。例えば、各オペレーティングシステムは、仮想ＣＰＵ、複数の仮想ＧＰＵ、仮想メモリ、仮想化された通信コンポーネントなどでサポートされ得る。さらに、インスタンスの構成は、あるデータセンターから別のデータセンターに転送されてレイテンシを短縮することができる。ユーザまたはゲームに対して定義されたＧＰＵ利用は、ユーザのゲームセッションを保存するときに使用できる。ＧＰＵ利用は、ゲームセッション用のビデオフレームの高速レンダリングを最適化するために、本明細書で説明する任意の数の構成を含むことができる。一実施形態では、ゲームまたはユーザに対して定義されたＧＰＵ利用は、構成可能な設定としてデータセンター間で転送することができる。ＧＰＵ利用を転送する機能により、ユーザが異なる地理的位置からゲームをプレイするために接続する場合に、データセンターからデータセンターへのゲームプレイの効率的な移行が可能になる。

システム１００は、クラウドゲームネットワーク１９０を介してゲームを提供し、本開示の一実施形態によれば、ゲームは、ゲームをプレイしている対応するユーザのクライアントデバイス１１０（例えば、シンクライアント）からリモートで実行されている。システム１００は、シングルプレイヤーモードまたはマルチプレイヤーモードのいずれかで、ネットワーク１５０を介してクラウドゲームネットワーク１９０を介して１つまたは複数のゲームをプレイする１人または複数のユーザにゲームのコントロールをもたらすことができる。いくつかの実施形態において、クラウドゲームネットワーク１９０は、ホストマシンのハイパーバイザ上で実行する複数の仮想マシン（ＶＭ）を含むことができ、１つまたは複数の仮想マシンは、ホストのハイパーバイザに利用可能であるハードウェアリソースを利用するゲームプロセッサモジュールを実行するように構成される。ネットワーク１５０は、１つまたは複数の通信技術を含み得る。いくつかの実施形態では、ネットワーク１５０は、高度な無線通信システムを有する第５世代（５Ｇ）ネットワーク技術を含み得る。

いくつかの実施形態では、通信は、無線技術を使用して促進され得る。そのような技術には、例えば、５Ｇ無線通信技術が含まれ得る。５Ｇは、セルラーネットワークテクノロジーの第５世代である。５Ｇネットワークはデジタルセルラーネットワークであり、プロバイダーがカバーするサービスエリアはセルと呼ばれる小さな地理的エリアに分割されている。音と画像を表すアナログ信号は、電話でデジタル化され、アナログデジタルコンバーターによって変換され、ビットのストリームとして送信される。セル内のすべての５Ｇワイヤレスデバイスは、他のセルで再利用される周波数のプールからトランシーバによって割り当てられた周波数チャネルを介して、セル内のローカルアンテナアレイ及び低電力自動トランシーバ（送信機及び受信機）と電波で通信する。ローカルアンテナは、高帯域幅光ファイバまたは無線バックホール接続によって、電話網及びインターネットに接続される。他のセルネットワークと同様に、あるセルから別のセルに移動するモバイルデバイスは、新しいセルに自動的に転送される。５Ｇネットワークは単なる一例のタイプの通信ネットワークであり、本開示の実施形態は、５Ｇに続く後の世代の有線または無線技術と同様に、前世代の無線または有線通信を利用することができることを理解されたい。

示されるように、クラウドゲームネットワーク１９０は、複数のビデオゲームへのアクセスを提供するゲームサーバ１６０を含む。ゲームサーバ１６０は、クラウド内で利用可能な任意の種類のサーバコンピューティングデバイスであってもよく、１つまたは複数のホスト上で実行される１つまたは複数の仮想マシンとして構成され得る。例えば、ゲームサーバ１６０は、ユーザのゲームのインスタンスをインスタンス化するゲームプロセッサをサポートする仮想マシンを管理し得る。よって、複数の仮想マシンに関連付けられたゲームサーバ１６０の複数のゲームプロセッサは、複数のユーザのゲームプレイに関連付けられた１つまたは複数のゲームの複数のインスタンスを実行するように構成される。そのようにして、バックエンドサーバサポートは、複数のゲームアプリケーションのゲームプレイのメディア（例えば、ビデオ、オーディオなど）のストリーミングを、対応する複数のユーザに提供する。つまり、ゲームサーバ１６０は、ネットワーク１５０を介して、データ（例えば、対応するゲームプレイのレンダリングされた画像及び／またはフレーム）を対応するクライアントデバイス１１０にストリーミング返信するように構成される。そのようにして、クライアントデバイス１１０によって受信されて転送されたコントローラの入力に応答して、計算の複雑なゲームアプリケーションが、バックエンドサーバで実行し続けることができる。各サーバは、画像及び／またはフレームをレンダリングし、次いでそれらを符号化（例えば、圧縮）して、対応するクライアントデバイスにストリーミングして表示することが可能である。

例えば、複数のユーザは、ストリーミングメディアを受信するように構成された対応するクライアントデバイス１１０を使用して、通信ネットワーク１５０を介して、クラウドゲームネットワーク１９０にアクセスすることができる。一実施形態では、クライアントデバイス１１０は、計算機能（例えば、ゲームタイトル処理エンジン１１１を含む）を提供するように構成されたバックエンドサーバ（例えば、クラウドゲームネットワーク１９０）とのインターフェースを提供するシンクライアントとして構成され得る。別の実施形態では、クライアントデバイス１１０は、ビデオゲームの少なくともいくつかのローカル処理のためのゲームタイトル処理エンジン及びゲームロジックで構成され得、バックエンドサーバで実行されるビデオゲームによって生成されるストリーミングコンテンツを受信するために、またはバックエンドサーバサポートによって提供されるその他のコンテンツ用に、さらに利用され得る。ローカル処理の場合、ゲームタイトル処理エンジンは、ビデオゲームと、ビデオゲームに関連するサービスとを実行するための基本的なプロセッサベースの機能を含む。その場合、ゲームロジックは、ローカルクライアントデバイス１１０に格納することができ、ビデオゲームを実行するために使用される。

クライアントデバイス１１０のそれぞれが、クラウドゲームネットワークから異なるゲームへのアクセスを要求している可能性がある。例えば、クラウドゲームネットワーク１９０は、ゲームサーバ１６０のＣＰＵリソース１６３及びＧＰＵリソース３６５を使用して実行されるように、ゲームタイトル処理エンジン１１１上に構築される１つまたは複数のゲームロジックを実行していてもよい。例えば、ゲームタイトル処理エンジン１１１と連携するゲームロジック１１５ａは、１つのクライアントのゲームサーバ１６０で実行され、ゲームタイトル処理エンジン１１１と連携するゲームロジック１１５ｂは、第２のクライアントのゲームサーバ１６０で実行され、そしてゲームタイトル処理エンジン１１１と連携するゲームロジック１１５ｎは、第Ｎのクライアントのゲームサーバ１６０で実行され得る。

特に、対応するユーザ（図示せず）のクライアントデバイス１１０は、インターネットなどの通信ネットワーク１５０経由でゲームへのアクセスを要求するために、及びゲームサーバ１６０により実行されるビデオゲームにより生成される表示画像（例えば、画像フレーム）をレンダリングするために構成され、その場合に符号化された画像が対応するユーザと関連する表示のためにクライアントデバイス１１０へ配信されている。例えば、ユーザは、ゲームサーバ１６０のゲームプロセッサ上で実行するビデオゲームのインスタンスとクライアントデバイス１１０を通してインタラクトすることができる。より具体的には、ビデオゲームのインスタンスは、ゲームタイトル処理エンジン１１１により実行される。ビデオゲームを実装する対応するゲームロジック（例えば、実行可能コード）１１５は、データストア（図示せず）を介して格納及びアクセス可能であり、ビデオゲームを実行するために使用される。ゲームタイトル処理エンジン１１１は、複数のゲームロジック（例えば、ゲームアプリケーション）を使用して複数のビデオゲームをサポートすることができ、それぞれがユーザによって選択可能である。

例えば、クライアントデバイス１１０は、ゲームプレイを駆動するために使用される入力コマンドを介するなどして、対応するユーザのゲームプレイに関連付けられたゲームタイトル処理エンジン１１１とインタラクトするように構成される。特に、クライアントデバイス１１０は、ゲームコントローラ、タブレットコンピュータ、キーボードなどの様々な種類の入力デバイスからの入力、ビデオカメラ、マウス、タッチパッドなどにより取り込まれたジェスチャを、受信し得る。クライアントデバイス１１０は、メモリとプロセッサモジュールとを少なくとも有する任意の種類のコンピューティングデバイスであってもよく、ネットワーク１５０を介してゲームサーバ１６０に接続することができる。バックエンドゲームタイトル処理エンジン１１１は、レンダリングされた画像を生成するように構成され、レンダリングされた画像は、クライアントデバイス１１０に関連する対応するディスプレイに表示するためにネットワーク１５０を介して配信される。例えば、クラウドベースのサービスを介して、ゲームレンダリングされた画像は、ゲームサーバ１６０のゲーム実行エンジン１１１で実行される対応するゲーム（例えば、ゲームロジック）のインスタンスによって配信され得る。すなわち、クライアントデバイス１１０は、符号化された画像（例えば、ビデオゲームの実行を通じて生成されたゲームレンダリング画像から符号化された）を受信し、ディスプレイ１１上にレンダリングされる画像を表示するように構成される。一実施形態では、ディスプレイ１１は、ＨＭＤを含む（例えば、ＶＲコンテンツを表示する）。いくつかの実施形態では、レンダリングされた画像は、クラウドベースのサービスから直接、またはクライアントデバイス１１０（例えば、ＰｌａｙＳｔａｔｉｏｎ（登録商標）Ｒｅｍｏｔｅ Ｐｌａｙ）を介して、無線または有線でスマートフォンまたはタブレットにストリーミングすることができる。

一実施形態では、ゲームサーバ１６０及び／またはゲームタイトル処理エンジン１１１は、ゲーム及びゲームアプリケーションに関連するサービスを実行するための基本的なプロセッサベースの機能を含む。例えば、ゲームサーバ１６０は、２Ｄまたは３Ｄレンダリング、物理シミュレーション、スクリプト作成、オーディオ、アニメーション、グラフィック処理、ライティング、シェーディング、ラスタ化、レイトレーシング、シャドウイング、カリング、変換、人工知能などを含むプロセッサベースの機能を実行するように構成された中央処理装置（ＣＰＵ）リソース１６３及びグラフィック処理ユニット（ＧＰＵ）リソース３６５を含む。さらに、ＣＰＵ及びＧＰＵグループは、メモリ管理、マルチスレッド管理、サービス品質（ＱｏＳ）、帯域幅テスト、ソーシャルネットワーキング、ソーシャルフレンドの管理、フレンドのソーシャルネットワークとの通信、通信チャネル、テキストメッセージ、インスタントメッセージング、チャットサポートなどを部分的に含む、ゲームアプリケーション用のサービスを実装する場合がある。一実施形態では、１つまたは複数のアプリケーションが特定のＧＰＵリソースを共有する。一実施形態では、複数のＧＰＵデバイスを組み合わせて、対応するＣＰＵ上で実行されている単一のアプリケーション用のグラフィック処理を実行することができる。

一実施形態では、クラウドゲームネットワーク１９０は、分散型ゲームサーバシステム及び／またはアーキテクチャである。具体的には、ゲームロジックを実行する分散型ゲームエンジンが、対応するゲームの対応するインスタンスとして構成されている。一般に、分散型ゲームエンジンは、ゲームエンジンの各機能を取り込み、それらの機能を分散させて多数の処理エンティティによって実行する。個々の機能は、さらに１つまたは複数の処理エンティティにわたって分散させることができる。処理エンティティは、物理ハードウェアを含んで、及び／または仮想コンポーネントまたは仮想マシンとして、及び／または仮想コンテナとしてなど、様々な構成で構成することができ、コンテナは、仮想化されたオペレーティングシステム上で動作するゲームアプリケーションのインスタンスを仮想化するものであるため、仮想マシンとは異なる。処理エンティティは、クラウドゲームネットワーク１９０の１つまたは複数のサーバ（計算ノード）上のサーバ及びその基礎となるハードウェアを利用し、及び／またはそれらに依拠してもよく、サーバは１つまたは複数のラック上に配置され得る。種々の処理エンティティに対するそれらの機能の実行の協調、割り当て、及び管理は、分散同期層によって行われる。そのようにして、それらの機能の実行が分散同期層によって制御されて、プレイヤーによるコントローラ入力に応答して、ゲームアプリケーション用のメディア（例えば、ビデオフレーム、オーディオなど）を生成することが可能になる。分散同期層は、重要なゲームエンジンコンポーネント／機能が、より効率的な処理のために分散されて再構築されるように、分散処理エンティティ全体で（例えば、負荷バランシングを介して）それらの機能を効率的に実行することが可能である。

図２は、本開示の一実施形態による、複数のＧＰＵが連携して対応するアプリケーションの単一の画像をレンダリングする、例示的なマルチＧＰＵアーキテクチャ２００の図である。本開示の様々な実施形態によれば、マルチＧＰＵアーキテクチャ２００は、画像フレームのジオメトリレンダリングのためにスクリーン領域をＧＰＵに動的に割り当てるために、レンダリング中またはレンダリング前に、及び／または、例えばドローコールによって処理または生成されたようなジオメトリのピースをジオメトリのより小さな部分に再分割し、ジオメトリのそれらのより小さな部分をレンダリングのために複数のＧＰＵに割り当てるときに、画像フレームのジオメトリのピースのジオメトリ解析を実行するように構成されており、ジオメトリのそれぞれのより小さな部分がＧＰＵに割り当てられる。明示的に説明または図示されていないが、複数のＧＰＵが連携して単一の画像をレンダリングする本開示の様々な実施形態において、多くのアーキテクチャが可能であることが理解される。例えば、レンダリング中に領域テストを実行することによるアプリケーション用のジオメトリのマルチＧＰＵレンダリングは、クラウドゲームシステムの１つまたは複数のクラウドゲームサーバ間で実装することも、パーソナルコンピュータまたは、複数のＧＰＵを有するハイエンドグラフィックカードを含むゲームコンソールなどのスタンドアロンシステム内で実装することもできる。

マルチＧＰＵアーキテクチャ２００は、アプリケーション用の単一の画像（「画像フレーム」とも呼ばれる）、及び／またはアプリケーション用の一連の画像の各画像のマルチＧＰＵレンダリングのために構成されたＣＰＵ１６３及び複数のＧＰＵを含む。具体的には、ＣＰＵ１６３及びＧＰＵリソース３６５は、前述の通り、２Ｄまたは３Ｄレンダリング、物理シミュレーション、スクリプト作成、オーディオ、アニメーション、グラフィック処理、ライティング、シェーディング、ラスタ化、レイトレーシング、シャドウイング、カリング、変換、人工知能などを含むプロセッサベースの機能を実行するように構成される。

例えば、マルチＧＰＵアーキテクチャ２００のＧＰＵリソース３６５には４つのＧＰＵが示されているが、アプリケーション用の画像をレンダリングする際には任意の数のＧＰＵを利用することができる。各ＧＰＵは、高速バス２２０を介して、ランダムアクセスメモリ（ＲＡＭ）などの対応する専用メモリに接続される。具体的には、ＧＰＵ－Ａはバス２２０を介してメモリ２１０Ａ（例えばＲＡＭ）に接続され、ＧＰＵ－Ｂはバス２２０を介してメモリ２１０Ｂ（例えばＲＡＭ）に接続され、ＧＰＵ－Ｃはバス２２０を介してメモリ２１０Ｃ（例えばＲＡＭ）に接続され、ＧＰＵ－Ｄはバス２２０を介してメモリ２１０Ｄ（例えば、ＲＡＭ）に接続される。

さらに、各ＧＰＵは、バス２４０を介して互いに接続され、バス２４０は、アーキテクチャに応じて、対応するＧＰＵとその対応するメモリとの間の通信に使用されるバス２２０と速度がほぼ等しいかそれより遅いものであり得る。例えば、ＧＰＵ－Ａは、バス２４０を介してＧＰＵ－Ｂ、ＧＰＵ－Ｃ、及びＧＰＵ－Ｄのそれぞれに接続される。また、ＧＰＵ－Ｂは、バス２４０を介してＧＰＵ－Ａ、ＧＰＵ－Ｃ、及びＧＰＵ－Ｄのそれぞれに接続される。加えて、ＧＰＵ－Ｃは、バス２４０を介してＧＰＵ－Ａ、ＧＰＵ－Ｂ、及びＧＰＵ－Ｄのそれぞれに接続される。さらに、ＧＰＵ－Ｄは、バス２４０を介してＧＰＵ－Ａ、ＧＰＵ－Ｂ、及びＧＰＵ－Ｃのそれぞれに接続される。

ＣＰＵ１６３は、低速バス２３０を介して各ＧＰＵに接続する（例えば、バス２３０は、対応するＧＰＵとその対応するメモリとの間の通信に使用されるバス２２０より遅い）。具体的には、ＣＰＵ１６３は、ＧＰＵ－Ａ、ＧＰＵ－Ｂ、ＧＰＵ－Ｃ、及びＧＰＵ－Ｄのそれぞれに接続される。

いくつかの実施形態では、４つのＧＰＵは個別のＧＰＵであり、それぞれが独自のシリコンダイ上にある。他の実施形態では、４つのＧＰＵは、高速相互接続及びダイ上の他のユニットを利用するために、ダイを共有することができる。さらに他の実施形態では、単一のより強力なＧＰＵとして、または４つのより強力でない「仮想」ＧＰＵ（ＧＰＵ－Ａ、ＧＰＵ－Ｂ、ＧＰＵ－Ｃ及びＧＰＵ－Ｄ）のどちらかとして使用するように構成できる、１つの物理ＧＰＵ２５０が存在する。すなわち、ＧＰＵ－Ａ、ＧＰＵ－Ｂ、ＧＰＵ－Ｃ、ＧＰＵ－Ｄそれぞれがグラフィックパイプラインを動作させるのに十分な機能があり（図４に示すように）、チップ全体としてグラフィックパイプラインを動作させることができ（図４に示すように）、構成は２つの構成間で（例えば、レンダリングパス間で）柔軟に切り替えることができる。

図３は、本開示の様々な実施形態による、画像フレームのジオメトリレンダリングのためにスクリーン領域をＧＰＵに動的に割り当てるために、レンダリング中またはレンダリング前に、及び／または、例えばドローコールによって処理または生成されたようなジオメトリのピースをジオメトリのより小さな部分に再分割し、ジオメトリのそれらのより小さな部分をレンダリングのために複数のＧＰＵに割り当てるときに、画像フレームのジオメトリのピースのジオメトリ解析を実行することによって、アプリケーションによって生成された画像フレームのジオメトリのマルチＧＰＵレンダリングのために構成されており、ジオメトリのそれぞれのより小さな部分がＧＰＵに割り当てられる、グラフィック処理ユニットリソース３６５の図である。例えば、ゲームサーバ１６０は、図１のクラウドゲームネットワーク１９０にＧＰＵリソース３６５を含めるように構成され得る。図示のように、ＧＰＵリソース３６５には、ＧＰＵ３６５ａ、ＧＰＵ３６５ｂ…ＧＰＵ３６５ｎなどの複数のＧＰＵが含まれる。前述のように、様々なアーキテクチャは、クラウドゲームシステムの１つまたは複数のクラウドゲームサーバ間でジオメトリのマルチＧＰＵレンダリングを実装する、または、複数のＧＰＵを有するハイエンドグラフィックカードを含むパーソナルコンピュータやゲームコンソールなどのスタンドアロンシステム内でのジオメトリのマルチＧＰＵレンダリングを実装するなど、レンダリング中に領域テストを介してアプリケーションのジオメトリのマルチＧＰＵレンダリングを実行することにより、単一の画像をレンダリングするために連携する、複数のＧＰＵを含むことができる。

具体的には、一実施形態では、ゲームサーバ１６０は、複数のＧＰＵが連携して単一の画像をレンダリングする、及び／またはアプリケーションの実行時に一連の画像の１つまたは複数の画像のそれぞれをレンダリングするように、アプリケーションの単一の画像をレンダリングするときに、マルチＧＰＵ処理を実行するように構成される。例えば、一実施形態では、ゲームサーバ１６０は、アプリケーションの一連の画像における１つまたは複数の画像のそれぞれのマルチＧＰＵレンダリングを実行するように構成されたＣＰＵ及びＧＰＵグループを含むことができ、１つのＣＰＵ及びＧＰＵグループはグラフィックを実装する、及び／またはアプリケーション用のパイプラインをレンダリングすることができる。ＣＰＵ及びＧＰＵグループは、１つまたは複数の処理デバイスとして構成できる。前述のとおり、ＧＰＵ及びＧＰＵグループは、ＣＰＵ１６３及びＧＰＵリソース３６５を含むことができ、これらは、２Ｄまたは３Ｄレンダリング、物理シミュレーション、スクリプト作成、オーディオ、アニメーション、グラフィック処理、ライティング、シェーディング、ラスタ化、レイトレーシング、シャドウイング、カリング、変換、人工知能などを含むプロセッサベースの機能を実行するように構成される。

ＧＰＵリソース３６５は、オブジェクトのレンダリング（例えば、オブジェクトのピクセルの色または法線ベクトル値を複数レンダーターゲット－ＭＲＴに書き込む）及び同期計算カーネルの実行（例えば、結果のＭＲＴでのフルスクリーン効果）のレスポンシビリティを持ち、及び／またはそのために構成され、実行する同期計算、及びレンダリングするオブジェクトは、ＧＰＵが実行する複数のレンダリングコマンドバッファ３２５に含まれるコマンドによって指定される。具体的には、ＧＰＵリソース３６５は、オブジェクトをレンダリングし、レンダリングコマンドバッファ３２５からコマンドを実行する際に（例えば、同期計算カーネルの実行中に）同期計算を実行するように構成され、コマンドは、及び／または操作は、順番に実行されるように、他の操作に依存する場合がある。

例えば、ＧＰＵリソース３６５は同期計算、及び／または１つまたは複数のレンダリングコマンドバッファ３２５（例えば、レンダリングコマンドバッファ３２５ａ、レンダリングバッファ３２５ｂ…レンダリングコマンドバッファ３２５ｎ）を使用するオブジェクトのレンダリングを実行するように構成されている。一実施形態では、ＧＰＵリソース３６５内の各ＧＰＵは、独自のコマンドバッファを有することができる。あるいは、オブジェクトの実質的に同じセットが各ＧＰＵによってレンダリングされているとき（例えば、領域のサイズが小さいため）、ＧＰＵリソース３６５内のＧＰＵは、同じコマンドバッファまたはコマンドバッファの同じセットを使用することができる。さらに、ＧＰＵリソース３６５内の各ＧＰＵは、コマンドが１つのＧＰＵによって実行されるが別のＧＰＵによって実行されない機能をサポートすることができる。例えば、レンダリングコマンドバッファ内の描画コマンドまたは述語のフラグにより、単一のＧＰＵが対応するコマンドバッファ内の１つまたは複数のコマンドを実行できるようになるが、他のＧＰＵはコマンドを無視する。例えば、レンダリングコマンドバッファ３２５ａはフラグ３３０ａをサポートすることができ、レンダリングコマンドバッファ３２５ｂはフラグ３３０ｂをサポートし、レンダリングコマンドバッファ３２５ｎはフラグ３３０ｎをサポートすることができる。

同期計算のパフォーマンス（例えば、同期計算カーネルの実行）とオブジェクトのレンダリングは、レンダリング全体の一部である。例えば、ビデオゲームが６０Ｈｚ（例：６０フレーム／秒）で実行されている場合、画像フレームのすべてのオブジェクトレンダリングと同期計算カーネルの実行は通常、約１６．６７ｍｓ（例えば、６０Ｈｚで１フレーム）以内に完了する必要がある。前述のように、オブジェクトをレンダリングするとき及び／または同期計算カーネルを実行するときの操作は、操作が他の操作に依存してもよいように順序付けられる（例えば、レンダリングコマンドバッファ内のコマンドは、そのレンダリングコマンドバッファ内の他のコマンドが実行される前に実行を完了する必要がある場合がある）。

具体的には、レンダリングコマンドバッファ３２５のそれぞれは、対応するＧＰＵ構成に影響を与えるコマンド（例えば、レンダーターゲットの位置及びフォーマットを指定するコマンド）、ならびにオブジェクトをレンダリングする、及び／または同期計算カーネルを実行するためのコマンドを含む、様々なタイプのコマンドを含む。説明のために、同期計算カーネルを実行するときに実行される同期計算には、オブジェクトが対応する１つ以上の複数レンダーターゲット（ＭＲＴ）にすべてレンダリングされたときにフルスクリーン効果を実行することが含まれる場合がある。

さらに、ＧＰＵリソース３６５が画像フレームのオブジェクトをレンダリングするとき、及び／または画像フレームを生成するときに同期計算カーネルを実行するとき、ＧＰＵリソース３６５は、各ＧＰＵ３６５ａ、３６５ｂ…３６５ｎのレジスタを介して構成される。例えば、ＧＰＵ３６５ａは、そのレジスタ３４０（例えば、レジスタ３４０ａ、レジスタ３４０ｂ…レジスタ３４０ｎ）を介して、そのレンダリングまたは計算カーネル実行を特定の方法で実行するように構成される。すなわち、レジスタ３４０に格納された値は、オブジェクトをレンダリングするため、及び／または画像フレームの同期計算カーネルを実行するために使用されるレンダリングコマンドバッファ３２５内のコマンドを実行するときのＧＰＵ３６５ａ３６５のハードウェアコンテキスト（例えば、ＧＰＵ構成またはＧＰＵ状態）を定義する。ＧＰＵリソース３６５内のＧＰＵのそれぞれは、ＧＰＵ３６５ｂがそのレジスタ３５０（例えば、レジスタ３５０ａ、レジスタ３５０ｂ…レジスタ３５０ｎ）を介して構成され、特定の方法でそのレンダリングを実行するか、またはカーネル実行を計算するように、同様に構成され得る。そしてＧＰＵ３６５ｎは、そのレジスタ３７０（例えば、レジスタ３７０ａ、レジスタ３７０ｂ…レジスタ３７０ｎ）を介して構成され、特定の方法でそのレンダリングまたは計算カーネル実行を実行する。

ＧＰＵ構成の例には、レンダーターゲット（ＭＲＴなど）の位置とフォーマットが含まれる。また、ＧＰＵ構成の他の例には、操作手順が含まれる。例えば、オブジェクトをレンダリングするとき、オブジェクトの各ピクセルのＺ値を様々な方法でＺバッファと比較できる。例えば、オブジェクトのＺ値がＺバッファの値と一致する場合にのみ、オブジェクトのピクセルが書き込まれる。別の方法として、オブジェクトのＺ値がＺバッファの値と同じかそれより小さい場合にのみ、オブジェクトのピクセルを書き込むこともできる。実行されるテストのタイプは、ＧＰＵ構成内で定義される。

図４は、本開示の一実施形態による、複数のＧＰＵが連携して単一の画像をレンダリングするように、マルチＧＰＵ処理用に構成されたグラフィックパイプライン４００を実装する、レンダリングアーキテクチャの簡略図である。グラフィックパイプライン４００は、３Ｄ（三次元）ポリゴンレンダリング処理を使用して画像をレンダリングする一般的処理の例示である。レンダリングされた画像に対するグラフィックパイプライン４００は、ピクセルの各々に対する対応する色情報をディスプレイに出力し、色情報は、テクスチャ及びシェーディング（例えば、色、シャドーイングなど）を表すことができる。グラフィックパイプライン４００は、図１及び図３のクライアントデバイス１１０、ゲームサーバ１６０、ゲームタイトル処理エンジン１１１、及び／またはＧＰＵリソース３６５内に実装可能であり得る。つまり、様々なアーキテクチャは、クラウドゲームシステムの１つまたは複数のクラウドゲームサーバ間でジオメトリのマルチＧＰＵレンダリングを実装する、または、複数のＧＰＵを有するハイエンドグラフィックカードを含むパーソナルコンピュータやゲームコンソールなどのスタンドアロンシステム内でのジオメトリのマルチＧＰＵレンダリングを実装するなど、レンダリング中に領域テストを介してアプリケーション用のジオメトリのマルチＧＰＵレンダリングを実行することにより、単一の画像をレンダリングするために連携する、複数のＧＰＵを含むことができる。

示されているように、グラフィックパイプラインは入力ジオメトリ４０５を受信する。例えば、ジオメトリ処理ステージ４１０は、入力ジオメトリ４０５を受信する。例えば、入力ジオメトリ４０５は、３Ｄゲーミング世界内の頂点、及び頂点の各々に対応する情報を含んでもよい。ゲーミング世界内の所与のオブジェクトは、頂点によって定義されるポリゴン（例えば、三角形）を使用して表すことができ、対応するポリゴンの表面は、次に、グラフィックパイプライン４００を介して処理されて、最終効果（例えば、色、テクスチャ、等）を達成する。頂点属性には、法線（例えば、その位置のジオメトリに対してどの方向が直角であるか）、色（例えば、ＲＧＢー赤、緑、青のトリプルなど）、及びテクスチャ座標／マッピング情報が含まれ得る。

ジオメトリ処理ステージ４１０は、頂点処理（例えば、頂点シェーダを介して）及びプリミティブ処理の両方のレスポンシビリティを持つ（そしてそれらを行うことができる）。具体的には、ジオメトリ処理ステージ４１０は、プリミティブを定義する頂点のセットを出力し、それらをグラフィックパイプライン４００の次のステージに配信するだけでなく、それらの頂点の位置（正確には同次座標）及び様々な他のパラメータを出力することができる。位置は、後のシェーダステージによるアクセスのために位置キャッシュ４５０に配置される。他のパラメータは、これも後のシェーダステージによるアクセスのためにパラメータキャッシュ４６０に配置される。

プリミティブ及び／またはポリゴンのライティング及びシャドーイング計算の実行など、様々な操作がジオメトリ処理ステージ４１０によって実行され得る。一実施形態では、ジオメトリステージはプリミティブを処理できるため、背面カリング及び／またはクリッピング（例えば、視錐台に対するテスト）を実行でき、それにより、下流ステージ（例えば、ラスタ化ステージ４２０など）の負荷を軽減する。別の実施形態では、ジオメトリステージはプリミティブを生成することができる（例えば、従来のジオメトリシェーダと同等の機能を有する）。

ジオメトリ処理ステージ４１０によって出力されたプリミティブは、プリミティブをピクセルから構成されるラスタ画像に変換するラスタ化ステージ４２０に供給される。具体的には、ラスタ化ステージ４２０は、３Ｄゲーミング世界内の視点（例えば、カメラ位置、ユーザの目の位置など）によって定義される二次元（２Ｄ）画像平面にシーン内のオブジェクトを投影するように構成される。単純化したレベルにおいて、ラスタ化ステージ４２０は、各々のプリミティブを検査し、どのピクセルが対応するプリミティブによって影響を与えられるかを判定する。具体的には、ラスタライザ４２０は、プリミティブをピクセルサイズのフラグメントに分割し、各フラグメントは、ディスプレイ内のピクセルに対応する。１つまたは複数のフラグメントは、画像を表示するとき、対応するピクセルの色に貢献し得ることに留意することが重要である。

前述のように、クリッピング（視錐台から外側にあるフラグメントを識別及び無視する）並びに視点へのカリング（より近いオブジェクトによって閉塞されたフラグメントを無視する）などの追加の演算もラスタ化ステージ４２０によって実行され得る。クリッピングに関して、ジオメトリ処理ステージ４１０及び／またはラスタ化ステージ４２０は、ゲーミング世界の視点によって定義される視錐台の外側にあるプリミティブを識別して無視するように構成することができる。

ピクセル処理ステージ４３０は、ジオメトリ処理ステージによって作成されたパラメータ及び他のデータを使用して、ピクセルの結果の色などの値を生成する。具体的には、そのコアにおけるピクセル処理ステージ４３０は、プリミティブの色及び輝度が利用可能なライティングによりどのように変化するかを判定するよう、フラグメントに対してシェーディング演算を実行する。例えば、ピクセル処理ステージ４３０は、各々のフラグメントに対して奥行、色、法線、及びテクスチャ座標（例えば、テクスチャ詳細）を判定してもよく、さらに、フラグメントに対して適切なレベルの光、暗がり、及び色を判定してもよい。具体的には、ピクセル処理ステージ４３０は、色及び他の属性（例えば、視点からの距離に対するｚ－奥行、透過性に対するα値）を含む、各々のフラグメントの特徴を計算する。加えて、ピクセル処理ステージ４３０は、対応するフラグメントに影響を与える利用可能なライティングに基づいて、ライティング効果をフラグメントに適用する。さらに、ピクセル処理ステージ４３０は、各フラグメントにシャドウイング効果を適用し得る。

ピクセル処理ステージ４３０の出力は、処理されたフラグメント（例えば、テクスチャ及びシェーディング情報）を含み、グラフィックパイプライン４００の次のステージの出力マージャステージ４４０に送られる。出力マージャステージ４４０は、ピクセル処理ステージ４３０の出力ならびに既にメモリにある値などの他のデータを使用して、ピクセルの最終的な色を生成する。例えば、出力マージャステージ４４０は、ピクセル処理ステージ４３０から決定されたフラグメント及び／またはピクセルと、そのピクセルに対してＭＲＴにすでに書き込まれている値との間の値の、オプションのブレンディングを実行することができる。

ディスプレイ内の各ピクセルの色値は、フレームバッファ（図示せず）に格納することができる。これらの値は、シーンの対応する画像を表示するときに、対応するピクセルにスキャンされる。特に、ディスプレイは、ピクセルごと、行ごと、左から右にあるいは右から左に、上から下にあるいは下から上に、または任意の他のパターンで、フレームバッファから色値を読み取り、画像を表示するときにそれらのピクセル値を使用してピクセルを照らす。

本開示の実施形態は、複数のＧＰＵを連携して使用して、単一の画像フレームを生成及び／またはレンダリングする。複数のＧＰＵを使用する際の難点は、各ＧＰＵに等量の作業を分散することにある。本開示の実施形態は、各ＧＰＵに等しい量の作業を提供することができ（すなわち、作業を概算で分散する）、レンダリングされるジオメトリの空間分散の解析を通じて、ピクセル数（すなわち解像度）及び複雑さの増加及び／または幾何学的な複雑さの増加、及び／または頂点及び／またはプリミティブあたりの処理量の増加をサポートし、動的に（つまり、フレームからフレームへ）スクリーン領域に対するＧＰＵのレスポンシビリティを調整して、ジオメトリ作業とピクセルの両方を最適化する。このように、ＧＰＵのレスポンシビリティの動的な分散は、図５Ａ～５Ｂ及び６Ａ～６Ｂに関連して以下でさらに説明されるように、スクリーン領域によって実行される。

図５Ａ～５Ｂは、純粋に例示を目的として、領域に再分割されたスクリーンのレンダリングを示しており、各領域は固定的な方法でＧＰＵに割り当てられている。つまり、ＧＰＵへの領域の割り当ては、画像フレームごとに変わらない。図５Ａでは、スクリーンは４つの象限に再分割され、そのそれぞれが異なるＧＰＵに割り当てられる。図５Ｂでは、スクリーンはより多数のインターリーブされた領域に再分割され、そのそれぞれがＧＰＵに割り当てられる。以下の図５Ａ～５Ｂの議論は、複数のＧＰＵが割り当てられた複数のスクリーン領域に対してマルチＧＰＵレンダリングを実行するときに生じる非効率性を示すことを意図している。図８は、本発明の実施形態による、より効率的なレンダリングを示す。

具体的には、図５Ａは、マルチＧＰＵレンダリングを実行するときに象限（例えば、４つの領域）に再分割されるスクリーン５１０Ａの図である。示されるように、スクリーン５１０Ａは、４つの象限（例えば、Ａ、Ｂ、Ｃ、及びＤ）に再分割される。各象限は、一対一の関係で４つのＧＰＵ［ＧＰＵ－Ａ、ＧＰＵ－Ｂ、ＧＰＵ－Ｃ、及びＧＰＵ－Ｄ］のうちの１つに割り当てられる。つまり、ＧＰＵのレスポンシビリティは固定的領域割り当てによって分散され、各ＧＰＵは１つまたは複数のスクリーン領域に固定的に割り当てられる。例えば、ＧＰＵ－Ａは象限Ａに割り当てられ、ＧＰＵ－Ｂは象限Ｂに割り当てられ、ＧＰＵ－Ｃは象限Ｃに割り当てられ、ＧＰＵ－Ｄは象限Ｄに割り当てられる。

ジオメトリはカリングできる。例えば、ＣＰＵ１６３は、各象限の錐台に対して境界ボックスをチェックし、対応する錐台にオーバーラップするオブジェクトのみをレンダリングするように各ＧＰＵに要求することができる。その結果、各ＧＰＵはジオメトリの一部のみをレンダリングするレスポンシビリティを持つ。例示の目的で、スクリーン５１０はジオメトリのピースを示し、各ピースは対応するオブジェクトであり、スクリーン５１０はオブジェクト５１１～５１７（例えば、ジオメトリのピース）を示す。ジオメトリのピースは、オブジェクト全体またはオブジェクトの一部（例えば、プリミティブなど）に対応し得ることが理解される。ＧＰＵ－Ａは、象限Ａにオーバーラップするオブジェクトがないため、オブジェクトをレンダリングしない。ＧＰＵ－Ｂはオブジェクト５１５と５１６をレンダリングする（オブジェクト５１５の一部が象限Ｂに存在するため、ＣＰＵのカリングテストは、ＧＰＵ－Ｂがそれをレンダリングする必要があると正確に結論付ける）。ＧＰＵ－Ｃはオブジェクト５１１と５１２をレンダリングする。ＧＰＵ－Ｄは、オブジェクト５１２、５１３、５１４、５１５、及び５１７をレンダリングする。

図５Ａにおいて、スクリーン５１０Ａが象限Ａ～Ｄに分割されるとき、状況によっては不均衡な量のジオメトリが１つの象限にある可能性があるため、各ＧＰＵが実行しなければならない作業の量は非常に異なる可能性がある。例えば、象限Ａにはジオメトリのピースがないが、象限Ｄにはジオメトリの５つのピース、またはジオメトリの少なくとも５つのピースの少なくとも一部がある。そのため、象限Ａに割り当てられたＧＰＵ－Ａはアイドル状態になるが、象限Ｄに割り当てられたＧＰＵ－Ｄは、対応する画像内のオブジェクトをレンダリングするときに不均衡にビジーになる。

図５Ｂは、本開示の一実施形態による、マルチＧＰＵレンダリングを実行するときにスクリーン５１０Ｂが複数のインターリーブされた領域に再分割されるように、スクリーンを領域に再分割するときの別の技法を示す。具体的には、スクリーン５１０Ｂは、単一の画像または一連の画像内の１つまたは複数の画像のそれぞれのマルチＧＰＵレンダリングを実行するときに、象限に再分割するのではなく、複数の領域に再分割される。例えば、スクリーン５１０Ｂは、ＧＰＵに対応する領域に再分割され得る。その場合、スクリーン５１０Ｂは、レンダリングのために同量のＧＰＵ（例えば、４つ）を使用しながら、より多数の領域（例えば、４象限よりも多い）に再分割される。スクリーン５１０Ａに示されるオブジェクト（５１１～５１７）は、スクリーン５１０Ｂにも同じ対応する位置に示されている。

具体的には、４つのＧＰＵ（例えば、ＧＰＵ－Ａ、ＧＰＵ－Ｂ、ＧＰＵ－Ｃ、及びＧＰＵ－Ｄ）を使用して、対応するアプリケーション用の画像をレンダリングする。各ＧＰＵは、対応する領域にオーバーラップするジオメトリのレンダリングのレスポンシビリティを持つ。つまり、各ＧＰＵは対応する領域のセットに割り当てられる。例えば、ＧＰＵ－Ａは対応するセットでＡとラベル付けされた各領域のレスポンシビリティを有し、ＧＰＵ－Ｂは対応するセットでＢとラベル付けされた各領域のレスポンシビリティを有し、ＧＰＵ－Ｃは対応するセットでＣとラベル付けされた各領域のレスポンシビリティを有し、ＧＰＵ－Ｄは、対応するセットでＤとラベル付けされた各領域のレスポンシビリティを有する。

さらに、領域は特定のパターンでインターリーブされる。領域のインターリーブ（及びより多くの数）により、各ＧＰＵが実行する必要がある作業量は、はるかにバランスが取れたものになり得る。例えば、スクリーン５１０Ｂのインターリービングのパターンは、領域Ａ－Ｂ－Ａ－Ｂなど、及び領域Ｃ－Ｄ－Ｃ－Ｄなどを含む交互の行を含む。領域をインターリーブする他のパターンも、本開示の実施形態でサポートされる。例えば、パターンには、領域の反復シーケンス、均等に分散した領域、領域の不均等な分散、領域のシーケンスの反復行、領域のランダムシーケンス、領域のシーケンスのランダム行などが含まれ得る。

領域の数の選択は重要である。例えば、領域の分散が細かすぎる場合（例えば、領域の数が多すぎて最適ではない場合）、各ＧＰＵは相変わらずジオメトリの大部分またはすべてを処理する必要がある。例えば、ＧＰＵがレスポンシビリティを有するすべての領域に対してオブジェクトの境界ボックスをチェックするのは難しい場合がある。また、境界ボックスをタイムリーにチェックできたとしても、領域サイズが小さいため、結果として、画像内のすべてのオブジェクトがＧＰＵのそれぞれの少なくとも１つの領域でオーバーラップするので、各ＧＰＵがほとんどのジオメトリを処理しなければならない可能性が高くなる（例えば、ＧＰＵは、オブジェクトの一部のみがそのＧＰＵに割り当てられた領域のセット内の少なくとも１つの領域とオーバーラップしている場合でも、オブジェクト全体を処理する）。

結果として、領域の数の選択は重要である。選択する領域が少なすぎるか、または多すぎると、ＧＰＵ処理を実行するときに非効率になる可能性がある（例えば、各ＧＰＵがほとんどまたはすべてのジオメトリを処理する）、または不均衡につながる可能性がある（例えば、１つのＧＰＵが別のＧＰＵよりも多くのオブジェクトを処理する）。それらの場合、画像をレンダリングするために複数のＧＰＵがあっても、これらの非効率性のために、スクリーンのピクセル数とジオメトリの密度の両方の対応する増加をサポートする能力がない（つまり、４つのＧＰＵはピクセルの４倍を書き込んで頂点またはプリミティブの４倍を処理することはできない）。したがって、本開示の実施形態では、（「ジオメトリ解析」を介して）情報を生成して、どのオブジェクトまたは複数オブジェクトがスクリーン領域のそれぞれに存在するかを示すことができる。レンダリング中またはレンダリング前にジオメトリ解析を実行することができ、以下でさらに説明するように、結果として得られる情報を使用して、対応する画像フレームをさらにレンダリングするためにスクリーン領域をＧＰＵに動的に割り当てることができる。つまり、スクリーン領域は対応するＧＰＵに固定されるのではなく、対応する画像フレームをレンダリングするためにＧＰＵに動的に割り当てられ得る。

図６Ａ～６Ｂは、本開示の様々な実施形態における、画像フレームのオブジェクト全体及び／またはオブジェクトの部分のジオメトリレンダリングのために、スクリーン領域をＧＰＵに動的に割り当てるためにジオメトリ解析を実行するために、画像フレーム内のオブジェクトをより小さな部分に分割する利点を示す。具体的には、オブジェクトのマルチＧＰＵレンダリングは、スクリーン内のオブジェクトにジオメトリ解析を実行することにより、単一の画像フレームに対して実行される。情報は「ジオメトリのピース」に対して生成され、ジオメトリのピースは、オブジェクト全体またはオブジェクトの一部であり得る。例えば、ジオメトリのピースは、オブジェクト６１０またはオブジェクト６１０の一部であり得る。具体的には、ＧＰＵは、ジオメトリと複数のスクリーン領域のそれぞれとの間の関係を決定するために、ジオメトリのピース（例えば、オブジェクト全体及び／またはオブジェクトの一部）に割り当てられる。つまり、連携するＧＰＵは、ジオメトリのピースのそれぞれとスクリーン領域のそれぞれとの間の関係を提供する情報を決定する。情報に対して解析が実行され、対応する画像フレームの後続のレンダリングのためにスクリーン領域がＧＰＵに動的に割り当てられる。ジオメトリ解析とその後のレンダリング、例えばジオメトリのレンダリング中に、オブジェクトがジオメトリレンダリング用の単一のＧＰＵに関連付けられている場合（例えば、オブジェクトを含むすべてのスクリーン領域を単一のＧＰＵに動的に割り当てる）、画像フレームをレンダリングするときに他のＧＰＵは、本開示の一実施形態に従って、そのオブジェクト全体をスキップでき、これは、ジオメトリの効率的な処理をもたらす。さらに、オブジェクトをより小さな部分に分割すると、ジオメトリ解析及び／または対応する画像フレームでのジオメトリのレンダリングを実行する際の効率をさらに高めることができる。

図６Ａは、本開示の一実施形態による、複数のＧＰＵが連携して対応する画像フレームをレンダリングするときに、スクリーン領域に対するオブジェクトの関係を決定するための、オブジェクト全体のジオメトリ解析（すなわち、対応するドローコールによって使用される、または生成されるジオメトリの量）を示す。オブジェクト全体がレンダリングされる場合（つまり、ドローコールによって使用または生成されるジオメトリが部分に分割されない場合）、オブジェクトとオーバーラップするスクリーン領域のレンダリングのレスポンシビリティを有する各ＧＰＵは、オブジェクト全体をレンダリングする必要がある。具体的には、ジオメトリ解析中に、オブジェクト６１０は領域６２０Ａとオーバーラップすると判断され得、オブジェクト６１０はまた領域６２０Ｂとオーバーラップすると判断され得る。すなわち、オブジェクト６１０の部分６１０Ａは領域６２０Ａとオーバーラップし、オブジェクト６１０の部分６１０Ｂは領域６２０Ｂとオーバーラップする。続いて、ＧＰＵ－Ａは、スクリーン領域６２０Ａ内のオブジェクトをレンダリングするレスポンシビリティを割り当てられ、ＧＰＵ－Ｂは、スクリーン領域６２０Ｂ内のオブジェクトをレンダリングするレスポンシビリティを割り当てられる。オブジェクトは全体としてレンダリングされるので、ＧＰＵ－Ａは、オブジェクト６１０を完全にレンダリングする、すなわち、領域６２０Ａ及び６２０Ｂの両方にわたるプリミティブを含む、オブジェクト内のすべてのプリミティブを処理するタスクを与えられる。この特定の例では、ＧＰＵ－Ｂもまた、オブジェクト６１０全体をレンダリングするタスクを与えられる。つまり、対応する画像フレーム内のオブジェクトのジオメトリのレンダリングを実行するときに、ＧＰＵ－ＡとＧＰＵ－Ｂによる作業の重複が発生する可能性がある。また、ＧＰＵ間で分散するオブジェクト（つまり、ドローコール）の数が少ない場合、ジオメトリ解析自体のバランスをとるのが難しい場合がある。

図６Ｂは、本開示の一実施形態による、複数のＧＰＵが連携して対応する画像フレームをレンダリングするときに、オブジェクトの一部のスクリーン領域に対する関係を決定するためのオブジェクトの一部のジオメトリ解析を示す。示されているように、ドローコールによって使用または生成されたジオメトリは、オブジェクトのこれらの部分を作成するために再分割される。例えば、オブジェクト６１０は、ドローコールによって使用または生成されたジオメトリがより小さなジオメトリのピースに再分割されるように、ピースに分割されてもよい。その場合、ジオメトリのより小さなピースと各スクリーン領域との間の関係（例えば、オーバーラップ）を決定するために、ジオメトリ解析中にジオメトリのより小さなピースについて情報が生成される。この情報を使用してジオメトリ解析が実行され、ＧＰＵ間のスクリーン領域ごとにレンダリングのレスポンシビリティが動的に割り当てられ、対応する画像フレームのジオメトリのより小さなピースがレンダリングされる。各ＧＰＵは、対応する画像フレームのレンダリングを実行するときに、レスポンシビリティを有するスクリーン領域とオーバーラップするジオメトリのより小さなピースのみをレンダリングする。そのため、各ＧＰＵは、対応する画像フレームのジオメトリのピースをレンダリングするためのスクリーン領域のセットに割り当てられる。つまり、画像フレームごとにＧＰＵのレスポンシビリティが一意に割り当てられる。このようにして、ジオメトリ解析及び／または対応する画像フレーム内のオブジェクトのジオメトリのレンダリングを実行するときに、ＧＰＵ間で作業の重複が少なくなり得るため、対応する画像フレームをレンダリングするときの効率が向上する。

一実施形態では、コマンドバッファ内のドローコールは同じままであるが、レンダリングする間、ＧＰＵはジオメトリをピースに分割する。ジオメトリのピースは、位置キャッシュ及び／またはパラメータキャッシュが割り振られるサイズとほぼ同じとしてもよい。各ＧＰＵは、ＧＰＵが割り当てられたスクリーン領域とオーバーラップするピースのみをレンダリングするように、これらのピースをレンダリングまたはスキップする。

例えば、オブジェクト６１０は、領域テストに使用されるジオメトリのピースがオブジェクト６１０のこれらのより小さな部分に対応するように、部分に分割される。示されるように、オブジェクト６１０は、ジオメトリ「ａ」、「ｂ」、「ｃ」、「ｄ」、「ｅ」、及び「ｆ」のピースに分割される。ジオメトリ解析の後、ＧＰＵ－Ａは、対応する画像フレームをレンダリングするときにジオメトリ「ａ」、「ｂ」、「ｃ」、「ｄ」、及び「ｅ」のピースをレンダリングするために、スクリーン領域６２０Ａに動的に割り当てられてもよい。つまり、ＧＰＵ－Ａはジオメトリ「ｆ」のピースをレンダリングするのをスキップできる。また、ジオメトリ解析の後、ＧＰＵ－Ｂは、対応する画像フレームをレンダリングするときに、ジオメトリ「ｄ」、「ｅ」、及び「ｆ」のピースをレンダリングするために、スクリーン領域６２０Ｂに割り当てられ得る。つまり、ＧＰＵ－Ｂは、ジオメトリ「ａ」、「ｂ」、及び「ｃ」のピースをレンダリングするのをスキップできる。示されるように、オブジェクト６１０を完全にレンダリングする代わりに、ＧＰＵ－Ａ及びＧＰＵ－Ｂのそれぞれによってジオメトリ「ｄ」及び「ｅ」のピースのみがレンダリングされるので、ＧＰＵ－ＡとＧＰＵ－Ｂとの間の作業の重複は少ない。

レンダリング中にジオメトリ解析を実行することによるジオメトリのマルチＧＰＵレンダリング
図１～３のクラウドゲームネットワーク１９０（例えば、ゲームサーバ１６０内）及びＧＰＵリソース３６５の詳細な説明とともに、図７の流れ図７００は、本開示の一実施形態による、レンダリング中にジオメトリ解析を実行することによって、アプリケーションによって生成された画像フレームのジオメトリのマルチＧＰＵレンダリングを実装するときのグラフィック処理の方法を示す。具体的には、多数のＧＰＵが連携して画像フレームを生成する。レンダリングの特定のフェーズに対するレスポンシビリティは、各画像フレームのスクリーン領域に基づいて複数のＧＰＵ間で分割される。ジオメトリのレンダリング中に、ＧＰＵはジオメトリ及びそのスクリーン領域との関係に関する情報を生成する。この情報は、ＧＰＵをスクリーン領域に割り当てるために使用され、より効率的なレンダリングを可能にする。このようにして、複数のＧＰＵリソースを使用して、アプリケーションの実行時に画像フレームのオブジェクトのレンダリングを効率的に実行する。前述のように、様々なアーキテクチャは、クラウドゲームシステムの１つまたは複数のクラウドゲームサーバ内、または、複数のＧＰＵを有するハイエンドグラフィックカードを含むパーソナルコンピュータやゲームコンソールなどのスタンドアロンシステム内などで、レンダリング中に領域テストを介してアプリケーション用のジオメトリのマルチＧＰＵレンダリングを実行することにより、単一の画像をレンダリングするために連携する、複数のＧＰＵを含むことができる。

７１０において、方法は、複数のＧＰＵを使用してグラフィックをレンダリングすることを含み、特定のフェーズにおいて、レンダリングのレスポンシビリティは、スクリーン領域に基づいて複数のＧＰＵの間で動的に分割される。特に、単一の画像フレーム、及び／またはリアルタイムアプリケーション用の一連の画像フレームの１つまたは複数の画像フレームのそれぞれをレンダリングするときにマルチＧＰＵ処理が実行され、各画像フレームは複数のジオメトリのピースを含む。特定のフェーズでは、各ＧＰＵがその割り当てられたスクリーン領域でジオメトリのピースをレンダリングするように、ＧＰＵレンダリングのレスポンシビリティが各画像フレームの複数のスクリーン領域間で動的に割り当てられる。つまり、各ＧＰＵは、対応するレスポンシビリティ（例えば、対応するスクリーン領域）のディビジョンあるいは分割部を有する。

７２０において、方法は、対応する複数のジオメトリのピースを含む画像フレームをレンダリングするために複数のＧＰＵを連携して使用することを含む。一実施形態では、レンダリング時に、レンダリングのプレパスフェーズが実行される。一実施形態では、このレンダリングのプレパスフェーズは、Ｚプレパスであり、複数のジオメトリのピースがレンダリングされる。

レンダリングのプレパスフェーズを実行するために、７２０で、方法は、複数のＧＰＵ間でのレンダリングのＺプレパスフェーズ中に画像フレームの複数のジオメトリのピースを処理するレスポンシビリティを分割することを含む。すなわち、複数のジオメトリのピースのそれぞれは、Ｚプレパスを実行するために対応するＧＰＵに割り当てられ、及び／またはＧＰＵのそれぞれには、それがレスポンシビリティを有するスクリーン領域のセットが割り当てられる。こうして、複数のジオメトリのピースは、複数のＧＰＵにおいてＺプレパスフェーズでレンダリングされ、１つまたは複数のＺバッファを生成する。具体的には、各ＧＰＵは、Ｚプレパスフェーズで対応するジオメトリのピースをレンダリングして、対応するＺバッファを生成する。例えば、ジオメトリの対応するピースについて、Ｚバッファは、投影面上のピクセルからジオメトリのピースまでの距離を測定する対応するｚ値（例えば、深度値）を含み得る。隠されたジオメトリまたはオブジェクトは、当技術分野で周知のように、Ｚバッファから削除することができる。

一実施形態では、各ＧＰＵは専用のＺバッファを有することができる。例えば、第１のＧＰＵは、Ｚプレパスフェーズでジオメトリの第１のピースをレンダリングして、第１のＺバッファを生成する。他のＧＰＵは、Ｚプレパスフェーズで対応するジオメトリのピースをレンダリングして、対応するＺバッファを生成する。一実施形態では、各ＧＰＵは、その対応するＺバッファ内のそのデータを複数のＧＰＵのそれぞれに送信し、対応するＺバッファが更新されて画像フレームのジオメトリをレンダリングするときに使用するためにほぼ同様になるようにする。すなわち、各ＧＰＵは、ＧＰＵの対応する各Ｚバッファが同様に更新されるように、すべてのＺバッファから受信したデータをマージするように構成される。

７３０において、方法は、画像フレームの複数のジオメトリのピース及びそれらの複数のスクリーン領域との関係に関する情報を生成することを含む。一実施態様では、情報は、レンダリングのプレパスフェーズ中に生成される。例えば、ジオメトリのピースをレンダリングしている間に情報が第１のＧＰＵで生成され、その情報はジオメトリのピースがどのスクリーン領域にオーバーラップするかを示すことができる。前述のように、ジオメトリのピースは、オブジェクト全体（つまり、個々のドローコールによって使用または生成されたジオメトリ）またはオブジェクトの一部（例えば、個々のプリミティブ、プリミティブのグループなど）であり得る。さらに、情報は、対応するスクリーン領域内のジオメトリのピースの存在を含むことができる。情報は、対応するスクリーン領域内のジオメトリのピースの存在に関する控えめな概算を含むことができる。情報は、ジオメトリのピースがスクリーン領域でカバーするピクセル面積または概算ピクセル面積（例えば、カバレッジ）を含むことができる。情報は、スクリーン領域に書き込まれたピクセルの数を含むことができる。情報は、レンダリングのＺプレパスフェーズ中にスクリーン領域ごとのジオメトリのピースごとにＺバッファに書き込まれたピクセルの数を含むことができる。

７４０において、方法は、複数のＧＰＵへのスクリーン領域のその後の割り当てにおいてこの情報を使用することを含む。具体的には、各ＧＰＵは、ジオメトリパスである可能性があるレンダリングの後続のフェーズ中に画像フレームをレンダリングするために、情報に基づいて、対応するスクリーン領域に割り当てられる。このようにして、ＧＰＵへのスクリーン領域の割り当ては、画像フレームごとに変化することができ、つまり、動的であり得る。

図８は、本開示の一実施形態による、現在の画像フレームのレンダリング中に実行される現在の画像フレームのジオメトリの解析に基づくジオメトリレンダリング（すなわち、ＭＲＴへのジオメトリのピースのレンダリング）のためのＧＰＵへのスクリーン領域の動的割り当てを示すスクリーン８００の図である。図示のように、スクリーン８００は領域に再分割することができ、各領域は説明のためにほぼ等しいサイズである。他の実施形態において、領域のそれぞれは、様々なサイズ及び形状とすることができる。例えば、領域８１０は、スクリーン８００の等しい再分割を表す。

スクリーン８００に示されるオブジェクト及びオブジェクトの位置は、図５Ａのスクリーン５１０Ａ及び図５Ｂのスクリーン５１０Ｂに示されるオブジェクト及びそれらの位置と同一である。例えば、オブジェクト５１１～５１７はスクリーン８００に示される。図５Ａは、ジオメトリレンダリングのためにＧＰＵに固定的に割り当てられる象限へのスクリーン５１０Ａの分割を示す。図５Ｂは、ジオメトリレンダリングのためにＧＰＵに固定的方式で割り当てられる領域へのスクリーン５１０Ｂの分割を示す。図８は、オブジェクト５１１～５１７を含む現在の画像フレームのＧＰＵへのスクリーン領域の動的割り当てを示す。割り当ては、画像フレームごとに実行される。すなわち、次の画像フレームでは、オブジェクト５１１～５１７は異なる位置にある可能性があり、したがって、次の画像フレームのスクリーン領域の割り当ては、現在の画像フレームの割り当てとは異なる可能性がある。例えば、ＧＰＵ－Ａはスクリーン領域のセット８３２に割り当てられ、オブジェクト５１１及び５１２をレンダリングする。また、ＧＰＵ－Ｂはスクリーン領域のセット８３４に割り当てられ、オブジェクト５１３、５１５、及び５１７をレンダリングする。ＧＰＵ－Ｃはスクリーン領域のセット８３６に割り当てられ、オブジェクト５１２、５１３、５１４、及び５１７をレンダリングする。そして、ＧＰＵ－Ｄはスクリーン領域のセット８３８に割り当てられ、オブジェクト５１５及び５１６をレンダリングする。オブジェクトがさらに部分に分割されると、より小さな部分ほどＧＰＵ領域間のオーバーラップが少なくなるため、レンダリングの重複がより少なくなる可能性がある。つまり、対応するコマンドバッファ内のドローコールは同じままであるが、レンダリング中にＧＰＵは、ジオメトリを、潜在的にほぼ位置及び／またはパラメータキャッシュが割り振られるサイズであるピースなどのピース（例えば、オブジェクトの部分）に分割し、それらがジオメトリレンダリング用にそのＧＰＵに割り当てられたスクリーン領域とオーバーラップするかどうかに応じて、それらのピースをレンダリングまたはスキップする。

一実施形態では、スクリーン領域のＧＰＵへの割り当ては、ジオメトリをレンダリングするときに各ＧＰＵによってほぼ等しい量のピクセル作業が実行されるように処理され得る。オブジェクトに関連付けられたピクセルシェーダは複雑さが異なる場合があるため、対応するオブジェクトによってカバーされるスクリーン面積の量が必ずしも等しいとは限らない。例えば、ＧＰＵ－Ｄは４つの領域のレンダリングのレスポンシビリティを有し、ＧＰＵ－Ａは６つの領域のレンダリングのレスポンシビリティを有するが、それらの対応するピクセル及び／またはレンダリング作業はほぼ等しいものであり得る。つまり、オブジェクトごとにレンダリングコストが異なり、ピクセル、プリミティブ、または頂点あたりのコストがオブジェクトごとに高くなる、または低くなる可能性がある。このピクセル、プリミティブ、または頂点などごとのコストは、各ＧＰＵで利用できるようにして、情報の生成に使用することができるか、または情報として含めることができる。あるいは、スクリーン領域を割り当てるときにコストを使用することもできる。

一実施形態では、クロスハッチ領域８３０はジオメトリを含まず、ＧＰＵのいずれか１つに割り当てられる可能性がある。別の実施形態では、クロスハッチ領域８３０は、ＧＰＵのいずれにも割り当てられない。いずれの場合も、領域８３０に対してジオメトリレンダリングは実行されない。

別の実施形態では、オブジェクトに関連付けられたすべての領域が単一のＧＰＵに割り当てられる。このようにして、他のすべてのＧＰＵは、ジオメトリレンダリングを実行するときにオブジェクトを完全にスキップできる。

図９Ａ～９Ｃは、４つのオブジェクトを示す画像フレームのレンダリングについてより詳細な説明を提供する図であり、画像フレームのレンダリングは、レンダリングのＺプレパスフェーズ及びジオメトリフェーズを含む。前述のように、Ｚプレパスフェーズは、本開示の実施形態に従って、画像フレームのジオメトリレンダリングのためにＧＰＵにスクリーン領域を動的に割り当てるために使用される情報を生成するために実行される。説明の目的で、図９Ａ～９Ｃは、一連の画像フレームのそれぞれをレンダリングするための複数のＧＰＵの使用を示す。図９Ａ～９Ｃに示される例に対する４つのＧＰＵの選択は、純粋にマルチＧＰＵレンダリングを説明するために作成されたものであり、様々な実施形態において、マルチＧＰＵレンダリングのために任意の数のＧＰＵを使用できることが理解される。

具体的には、図９Ａは、画像フレーム内に含まれる４つのオブジェクトを示すスクリーン９００Ａを示す。例えば、画像フレームはオブジェクト０、オブジェクト１、オブジェクト２、及びオブジェクト３を含む。示されるように、スクリーン９００Ａは複数の領域に分割される。例えば、スクリーン９００Ａは、４つを超える領域に分割されてもよく、その各々は、現在の画像フレームをレンダリングするための対応するＧＰＵに割り当てられる。

一実施形態では、対応する画像フレームをレンダリングするために、単一のコマンドバッファが複数のＧＰＵによって使用される。共通レンダリングコマンドバッファには、レンダリングのＺプレパスフェーズを実行するための各オブジェクトのドローコールと状態設定が含まれ得る。すべてのＧＰＵがレンダリングのジオメトリパスフェーズを同時に開始するように、コマンドバッファ内にシンク（例えば、同期）操作を含めることができる。コマンドバッファには、レンダリングのジオメトリパスフェーズを実行するための各オブジェクトのドローコールと状態セットが含まれ得る。

一実施形態では、共通レンダリングコマンドバッファは、コマンドが１つのＧＰＵによって実行されるが別のＧＰＵによって実行されない機能をサポートする。すなわち、共通レンダリングコマンドバッファのフォーマットは、複数のＧＰＵの１つまたはサブセットによってコマンドが実行されることを可能にする。例えば、前述のように、レンダリングコマンドバッファ内の描画コマンドまたは述語のフラグにより、単一のＧＰＵが、他のＧＰＵからの干渉を受けることなく、対応するコマンドバッファ内の１つまたは複数のコマンドを実行できる。

図９Ｂは、本開示の一実施形態による、１つまたは複数のＺバッファと、特定の画像フレームのジオメトリのピース及び描画されたスクリーンのスクリーン領域及び／またはサブ領域のそれぞれに関連する情報とを生成するために実行される、レンダリングのＺプレパスフェーズを示す。図９ＢのレンダリングのＺプレパスフェーズにおいて、複数のＧＰＵが連携してレンダリングのフレーム用の１つまたは複数のＺバッファを生成できる１つの戦略が示されている。１つまたは複数のＺバッファを生成するために、他の戦略を実装することができる。

示されているように、マルチＧＰＵアーキテクチャの各ＧＰＵにはジオメトリの一部が割り振られる。説明のために、ＧＰＵ－Ａはオブジェクト０に割り当てられ、ＧＰＵ－Ｂはオブジェクト１に割り当てられ、ＧＰＵ－Ｃはオブジェクト２に割り当てられ、ＧＰＵ－Ｄはオブジェクト３に割り当てられている。各ＧＰＵは対応するオブジェクトをＺプレパスフェーズでレンダリングし、対応するオブジェクトをＺバッファのその独自のコピーにレンダリングする。例えば、Ｚプレパスフェーズでは、ＧＰＵ－Ａはオブジェクト０をそのＺバッファにレンダリングする。スクリーン９２１は、ＧＰＵ－Ａによって決定され、その対応するＺバッファに格納されるオブジェクト０のピクセルカバレッジを示している。また、ＧＰＵ－Ｂは、ＧＰＵ－Ｂによって決定され、対応するＺバッファに格納されたオブジェクト１のピクセルカバレッジをスクリーン９２２が示すように、オブジェクト１をそのＺバッファにレンダリングする。加えて、ＧＰＵ－Ｃは、ＧＰＵ－Ｃによって決定され、対応するＺバッファに格納されたオブジェクト２のピクセルカバレッジをスクリーン９２３が示すように、オブジェクト２をそのＺバッファにレンダリングする。さらに、ＧＰＵ－Ｄは、ＧＰＵ－Ｄによって決定され、対応するＺバッファに格納されたオブジェクト３のピクセルカバレッジをスクリーン９２４が示すように、オブジェクト３をそのＺバッファにレンダリングする。

その後、ＧＰＵに対応する４つのＺバッファコピーがマージされる。つまり、各ＧＰＵは、その独自のＲＡＭ（ランダムアクセスメモリ）に対応するＺバッファのコピーを有する。一実施形態では、１つまたは複数のＺバッファを構築する戦略は、各ＧＰＵにその完成したＺバッファを他のＧＰＵに送信させることを含む。このように、Ｚバッファのそれぞれは、サイズとフォーマットが類似している必要がある。具体的には、Ｚバッファのそれぞれのデータは、Ｚバッファのそれぞれをマージ及び更新するためにすべてのＧＰＵに送信され、これは、４つのオブジェクト１～４のそれぞれのピクセルカバレッジを示すスクリーン９２５によって示され、ＧＰＵの更新されたＺバッファのそれぞれに格納される。オブジェクトは、図９Ｂでは空白であり、これは、Ｚのみが書き込まれており、他の値（例えば、色）がスクリーンのピクセルのそれぞれについて計算されていないことを表す。

別の実施形態では、マージ時間が短縮される。データが他のＧＰＵに送信される前に、対応するＧＰＵによって各Ｚバッファが完全に完了するのを待つ代わりに、各ＧＰＵが対応するジオメトリのピースをそのＺバッファに書き込むときに、対応するＧＰＵは更新されたスクリーン領域のＺバッファデータを他のＧＰＵに送信する。すなわち、第１のＧＰＵがジオメトリを対応するＺバッファまたは他のレンダーターゲットにレンダリングすると、第１のＧＰＵはＺバッファからのデータまたは更新されたスクリーン領域を含む他のレンダーターゲットデータを他のＧＰＵに送信する。送信前に、対応するＧＰＵの各Ｚバッファが完全に書き込まれるのを待たないことで、Ｚバッファのマージに必要な時間の一部が取り除かれ、それによりマージ時間が短縮される。

別の実施形態では、Ｚバッファを構築するための別の戦略は、複数のＧＰＵ間で共通のＺバッファまたは共通のレンダーターゲットを共有することを含む。例えば、Ｚバッファリングを実行するために使用されるハードウェアは、各ＧＰＵによって共有及び更新される共通のＺバッファまたは共通のレンダーターゲットが存在するように構成され得る。つまり、各ＧＰＵは、レンダリングのＺプレパスフェーズで１つまたは複数の対応するジオメトリのピースをレンダリングしながら、共通のＺバッファを更新する。４つのＧＰＵアーキテクチャの例では、第１のＧＰＵは、それぞれが複数のＧＰＵによって共有される共通のＺバッファまたは共通のレンダーターゲットを更新することによって、対応するＺバッファまたは他のレンダーターゲットにジオメトリをレンダリングする。共通のＺバッファまたは共通のレンダーターゲットを使用すると、マージステップが不要になる。一実施形態では、スクリーン領域がＧＰＵに割り振られ、共通のＺバッファにアクセスするときの調停の必要性を簡素化する。

前述のように、Ｚバッファのレンダリング中に情報が生成される。一実施形態では、図４のラスタ化ステージ４２０の一部として実行するスキャンコンバータが情報を生成する。例えば、スキャンコンバータは、ジオメトリのピースとスクリーン領域のそれぞれとのオーバーラップ面積を計算することができる。様々な実施形態では、オーバーラップは、ジオメトリのピースの各プリミティブと各スクリーン領域との間など、ピクセル単位で測定することができる。さらに、スキャンコンバータは、領域ごとに測定されたように、オーバーラップの面積を合計して、ジオメトリのピースごとに（例えば、ピクセルごとに）オーバーラップの総面積を作成することができる。

ジオメトリパスの開始前に、この情報を使用してスクリーン領域をＧＰＵに割り当てることができる。すなわち、複数のＧＰＵのうちの１つまたは複数をスクリーン領域に割り当てることができる。一実施形態では、割り当ては、各ＧＰＵのレンダリングレスポンシビリティ（例えばレンダリングジオメトリ）がほぼ等しくなるように行われる。このように、レンダリングの１つのフェーズ（Ｚプレパスフェーズ）で生成された情報は、レンダリングのジオメトリパスフェーズに対してスクリーン領域をＧＰＵに割り当てるなど、レンダリングの別のフェーズで使用される。

前述のように、オブジェクトは他のオブジェクトとは異なるレンダリングコストを有し得る。つまり、１つのオブジェクトのピクセル、またはプリミティブ、または頂点あたりのコストは、他のオブジェクトより高いことも低いこともある。いくつかの実施形態では、ピクセル／プリミティブ／頂点当たりのコストがＧＰＵで利用可能であり、情報の生成に使用され、及び／または情報の中に含まれている。別の実施形態では、ピクセル／プリミティブ／頂点当たりのコストは、スクリーン領域をＧＰＵに割り当てるときに使用され、これにより、生成される情報は、ピクセル、プリミティブ、または頂点ごとの対応するジオメトリのピースの概算レンダリングコストを考慮に入れる。すなわち、複数のコストが、レンダリングのジオメトリフェーズ中に画像フレームの複数のジオメトリのピースをレンダリングするために決定される。ジオメトリレンダリングのためにスクリーン領域をＧＰＵに割り当てるとき、コストが考慮される。例えば、複数のＧＰＵへのスクリーン領域のその後の割り当てでは、ＧＰＵをレンダリングのコストがＧＰＵ間で必要に応じて（均等または不均等に）分割される方法でスクリーン領域に割り当てることができるように、ピクセル、プリミティブ、または頂点ごとのジオメトリのピースの概算のレンダリングコストを考慮に入れる。

図９Ｃは、本開示の一実施形態による、特定の画像フレームのジオメトリのピースをレンダリングするために実行されるレンダリングのジオメトリパスフェーズを示す。ジオメトリパスフェーズでは、各ＧＰＵは、特定の画像フレームのオブジェクトを、それがレスポンシビリティを有するスクリーン領域にレンダリングする（例えば、スクリーン領域へのＧＰＵの以前の割り当てに基づいて）。具体的には、各ＧＰＵはすべてのオブジェクトをレンダリングするが、これらのオブジェクトとジオメトリレンダリングのためにＧＰＵに割り当てられたスクリーン領域との間にオーバーラップがないことが（情報に基づいて）わかっているオブジェクトは除く。そのため、ジオメトリのピースが特定のＧＰＵに割り当てられたスクリーン領域にオーバーラップしない場合、そのＧＰＵはそのジオメトリのピースのレンダリングをスキップできる。

示されているように、マルチＧＰＵアーキテクチャの各ＧＰＵは、スクリーンの一部に割り当てまたは割り振られる。説明のために、ＧＰＵ－Ａは９３１Ａとラベル付けされた１つの領域に割り当てられ、（図９Ａで紹介されたように）オブジェクト０をレンダリングする（ここでは、色データなどの他の値が書き込まれていることを表すために薄暗くされている）。スクリーン９３１は、ジオメトリレンダリング後のオブジェクト０のレンダーターゲットデータ（例えばピクセル）を示している。また、ＧＰＵ－Ｂは９３２Ａとラベル付けされた２つの領域に割り当てられ、オブジェクト１及びオブジェクト２の部分（薄暗くされたそれらのオブジェクトのそれぞれの部分）をレンダリングする。スクリーン９３２は、ジオメトリレンダリング後のオブジェクト１及び２のそれぞれの部分のレンダーターゲットデータ（例えばピクセル）を示す。さらに、ＧＰＵ－Ｃは９３３Ａとラベル付けされた２つの領域に割り当てられ、オブジェクト２の部分（薄暗くされたそれぞれの部分）をレンダリングする。スクリーン９３３は、ジオメトリレンダリング後のオブジェクト２のそれぞれの部分のレンダーターゲットデータ（例えばピクセル）を示す。また、ＧＰＵ－Ｄは９３４Ａとラベル付けされた３つの領域に割り当てられ、オブジェクト３をレンダリングする（ここでは、色データなどの他の値が書き込まれていることを表すために薄暗くされている）。スクリーン９３４は、ジオメトリレンダリング後のオブジェクト３のレンダーターゲットデータ（例えばピクセル）を示している。

ジオメトリのレンダリング後、各ＧＰＵによって生成されたレンダーターゲットデータをマージする必要があり得る。例えば、各ＧＰＵのレンダリングのジオメトリパスフェーズ中に生成されたジオメトリデータのマージが実行され、これは、４つのオブジェクト０～３すべてのレンダーターゲットデータ（例えば、ピクセル）を含むスクリーン９３５によって示される。

一実施形態では、スクリーン領域のＧＰＵへの割り当ては、フレームごとに変化する。つまり、各ＧＰＵは、２つの連続する画像フレームの割り当てを比較するときに、異なるスクリーン領域のレスポンシビリティを有する場合がある。別の実施形態では、ＧＰＵへのスクリーン領域の割り当ても、単一のフレームをレンダリングする際に使用される様々なフェーズを通じて変化し得る。すなわち、スクリーン領域の割り当ては、ジオメトリ解析フェーズ（例えば、Ｚプレパス）またはジオメトリパスフェーズなどのレンダリングフェーズ中に動的に変化する場合がある。

例えば、ジオメトリフェーズの割り当てが行われるとき、この割り当てはそのため既存の割り当てと異なる場合がある。つまり、以前はＧＰＵ－Ｂがレスポンシビリティをもっていたスクリーン領域を今はＧＰＵ－Ａがレスポンシビリティをもつ可能性がある。これにより、ＧＰＵ－ＢのメモリからＧＰＵ ＡのメモリへのＺバッファまたはその他のレンダーターゲットデータの転送が必要になる場合がある。一例として、情報は、スクリーン領域に書き込むコマンドバッファ内の第１のオブジェクトを含み得る。この情報を使用して、あるＧＰＵから別のＧＰＵにスクリーン領域のＺバッファデータまたはその他のレンダーターゲットデータを転送するなど、ＤＭＡ（ダイレクトメモリアクセス）転送をスケジュールすることができる。上記の例に従って、ＧＰＵ－Ｂのメモリからのデータ（例えば、Ｚバッファまたはレンダーターゲットデータ）は、ＧＰＵ－Ａのメモリに転送され得る。場合によっては、画像フレームのレンダリング時に最初のスクリーン使用が発生するのが遅いほど、ＤＭＡ転送の時間が長くなる。

別の実施形態では、ＧＰＵ間のＺバッファまたは他のレンダーターゲットデータのすべての更新が完了すると、情報は、スクリーン領域に書き込むコマンドバッファ内の最後のオブジェクトを含み得る。その情報を使用して、レンダリングＧＰＵ（レンダリングのＺプレパスフェーズ中に実行）から他のＧＰＵへのＤＭＡ転送をスケジュールすることができる。つまり、この情報は、あるＧＰＵから別のＧＰＵ（例えば、レンダリングＧＰＵ）へのスクリーン領域のＺバッファまたはその他のレンダーターゲットデータの転送をスケジュールするために使用される。

さらに別の実施形態では、ＧＰＵ間のＺバッファまたは他のレンダーターゲットデータのすべての更新が完了すると、更新されたデータをＧＰＵにブロードキャストすることができる。その場合、更新されたデータは、ＧＰＵのいずれかがそのデータを必要とする場合に利用できる。別の実施形態では、受信ＧＰＵがレンダリングの後続のフェーズでスクリーン領域のレスポンシビリティを有することを見越すなどして、データが特定のＧＰＵに送信される。

図１０は、本開示の一実施形態による、ジオメトリレンダリングのために、オブジェクト全体またはオブジェクトの一部に基づいたスクリーン領域のＧＰＵへの動的割り当てを使用した画像フレームのレンダリングを示しており、割り当ては、画像フレームをレンダリングしている間に実行されるレンダリングのＺプレパスフェーズ中に実行された現在の画像フレームのジオメトリの解析に基づく。具体的には、レンダリングタイミング図１０００Ａは、オブジェクト全体（すなわち、個々のドローコールによって使用または生成されたジオメトリ）に基づく画像フレームのレンダリングを示している。対照的に、レンダリングタイミング図１０００Ｂは、オブジェクトの部分に基づく画像フレームのレンダリングを示す。オブジェクトの部分に基づいて画像フレームをレンダリングするときに示される利点には、ＧＰＵ間のレンダリングパフォーマンスのバランスが向上し、したがって画像フレームのレンダリング時間が短縮されることが含まれる。

具体的には、レンダリングタイミング図１０００Ａは、４つのＧＰＵ（例えば、ＧＰＵ－Ａ、ＧＰＵ－Ｂ、ＧＰＵ－Ｃ、及びＧＰＵ－Ｄ）による４つのオブジェクト０～３のそれぞれのレンダリングを示し、レンダリングのレスポンシビリティはオブジェクトの粒度でＧＰＵ間に分散される。オブジェクト０～３は、図９Ａ～９Ｃで以前に紹介されたものである。レンダリングの様々なフェーズが、タイムライン１０９０に関連して示されている。垂直線１００１Ａは、Ｚプレパスのレンダリングの開始を示す。レンダリングタイミング図１０００Ａは、レンダリングのＺプレパスフェーズ１０１０Ａを含み、ＧＰＵ間のＺバッファデータのマージを示すフェーズ１０２０Ａも示す。ＧＰＵのアイドル時間は、ハッシュアウトされた面積を使用して示され、マージフェーズ１０２０Ａは、このアイドル時間中に発生する可能性がある。シンクポイント１０３０Ａは、各ＧＰＵがそれぞれのジオメトリパスレンダリングフェーズを同時に開始するように提供される。また、レンダリングタイミング図１０００Ａは、前述のように、画像フレームのジオメトリをレンダリングするためのレンダリングのジオメトリパスフェーズ１０４０Ａを含む。シンクポイント１０５０Ａは、各ＧＰＵが同時に次の画像フレームのレンダリングを開始するように提供される。シンクポイント１０５０Ａはまた、対応する画像フレームのレンダリングの終了を示し得る。オブジェクト全体をレンダリングするときの画像フレームのレンダリングの合計時間は、期間１０７０で示される。各ＧＰＵのスクリーン領域レスポンシビリティを決定するための情報の処理は、図には示されていないが、ジオメトリパス１０３０Ａの開始前に完了すると推定され得る。

示されるように、ジオメトリパスフェーズ１０４０Ａ中のレンダリングタイミング図１０００Ａのハッシュされた面積は、ＧＰＵアイドル時間を示す。例えば、ＧＰＵ－Ａは、ＧＰＵ－Ａがレンダリングに費やす時間とほぼ同じ時間アイドル状態になる。一方、ＧＰＵ－Ｂはアイドル状態になる時間がほとんどなく、ＧＰＵ－Ｃがアイドル状態になる時間はない。

対照的に、レンダリングタイミング図１０００Ｂは、４つのＧＰＵ（例えば、ＧＰＵ－Ａ、ＧＰＵ－Ｂ、ＧＰＵ－Ｃ、及びＧＰＵ－Ｄ）による４つのオブジェクト０～３のそれぞれのレンダリングを示し、レンダリングのレスポンシビリティはＧＰＵ間で、オブジェクト全体ではなく、図６Ｂに示されるジオメトリのピースなどのオブジェクトの部分の粒度で分散される。例えば、オブジェクト全体ではなくジオメトリのピース（例えば、オブジェクトの部分）について情報（例えば、スクリーン領域とのオーバーラップ）が生成される。このようにして、ドローコールによって使用または生成される画像フレームのジオメトリ（例えば、オブジェクト全体）は、ジオメトリのより小さなピースに再分割され、生成される情報は、これらのジオメトリのピースに関するものである。いくつかの場合では、ジオメトリのピースを再分割できる程度には制限がある。

レンダリングの様々なフェーズが、タイムライン１０９０に関連して示されている。垂直線１００１Ｂは、Ｚプレパスのレンダリングの開始を示す。レンダリングタイミング図１０００Ｂは、レンダリングのＺプレパスフェーズ１０１０Ｂを含み、ＧＰＵ間でＺバッファデータのマージが実行されるハッシュアウトされた期間１０２０Ｂも示す。レンダリングタイミング図１０００ＢのＧＰＵアイドル時間１０２０Ｂは、レンダリングタイミング図１０００Ａのアイドル時間１０２０Ａより短い。示されているように、各ＧＰＵはほぼ同じ時間をＺプレパスフェーズの処理に費やしており、アイドル時間はほとんどまたはまったくない。シンクポイント１０３０Ｂは、各ＧＰＵがそれぞれのジオメトリパスレンダリングフェーズを同時に開始するように提供される。また、レンダリングタイミング図１０００Ｂは、前述のように、画像フレームのジオメトリをレンダリングするためのレンダリングのジオメトリパスフェーズ１０４０Ｂを含む。シンクポイント１０５０Ｂは、各ＧＰＵが同時に次の画像フレームのレンダリングを開始するように提供される。シンクポイント１０５０Ｂはまた、対応する画像フレームのレンダリングの終了を示し得る。示されているように、各ＧＰＵはほぼ同じ時間をジオメトリパスフェーズの処理に費やしており、アイドル時間はほとんどまたはまったくない。つまり、Ｚプレパスレンダリングとジオメトリレンダリングは、それぞれＧＰＵ間でほぼバランスが取れている。また、オブジェクト全体の部分によってレンダリングするときの画像フレームのレンダリングの合計時間は、期間１０７５で示される。各ＧＰＵのスクリーン領域レスポンシビリティを決定するための情報の処理は、図には示されていないが、ジオメトリパス１０３０Ｂの開始前に完了すると推定され得る。

示されるように、レンダリングタイミング図１０００Ｂは、オブジェクト全体ではなくオブジェクトの部分の粒度でレンダリングレスポンシビリティがＧＰＵ間で分散されるときの短縮されたレンダリング時間を示す。例えば、オブジェクトの部分の粒度で画像フレームをレンダリングするときの時間の節約１０７７が示される。

加えて、本開示の一実施形態によれば、この情報により、レンダリングフェーズの要件及び／または依存関係を緩和でき、これにより、別のＧＰＵがレンダリングの現在のフェーズをまだ処理している間に、ＧＰＵがレンダリングの後続のフェーズに進む結果となる。例えば、任意のＧＰＵがジオメトリフェーズ１０４０Ａまたは１０４０Ｂを開始する前に、すべてのＧＰＵについてＺプレパスフェーズ１０２０Ａまたは１０２０Ｂが完了しなければならない、という１つの要件は緩和され得る。示されるように、レンダリングタイミング図１０００Ａは、ジオメトリフェーズ１０４０Ａを開始する前に、すべてのＧＰＵのシンクポイント１０２０Ａを含む。しかしながら、この情報は、（例えば）ＧＰＵ Ａが、他のＧＰＵが対応するレンダリングのＺプレパスフェーズを完了する前に、その割り当てられた領域のレンダリングを開始できることを示し得る。これにより、画像フレームのレンダリング時間が全体的に短縮される場合がある。

図１１は、本開示の一実施形態による、画像フレームのジオメトリレンダリングのためのＧＰＵへのスクリーン領域の動的な割当てに使用される情報を生成するために、レンダリングのＺプレパスフェーズを実行するために、画像フレームのジオメトリのピースへのＧＰＵ割り当てをインターリーブすることを示す図である。即ち、図１１は、Ｚプレパスに対する複数のＧＰＵ間のレンダリングレスポンシビリティの分散を示す。前述のように、各ＧＰＵは画像フレームのジオメトリの対応する部分に割り当てられ、その部分はさらにオブジェクト、オブジェクトの部分、ジオメトリ、ジオメトリのピースなどに分割され得る。

図１１に示すように、オブジェクト０、１、及び２は、個々のドローコールによって使用または生成されたジオメトリを表す。一実施形態では、ＧＰＵは、前述のように、各オブジェクトを、位置キャッシュ及び／またはパラメータキャッシュが割り振られるおおよそのサイズのピースなど、ジオメトリのより小さなピースに分割する。純粋に説明のために、オブジェクト０は、図６Ｂのオブジェクト６１０のように、ピース「ａ」、「ｂ」、「ｃ」、「ｄ」、「ｅ」および「ｆ」に分割される。また、オブジェクト１は、ピース「ｇ」、「ｈ」、及び「ｉ」に分割される。さらに、オブジェクト２はピース「ｊ」、「ｋ」、「ｌ」、「ｍ」、「ｎ」、及び「ｏ」に分割される。ピースは、レンダリングのＺプレパスフェーズを実行するレスポンシビリティを分散するために（例えば、ａ～ｏに）順序付けることができる。

分散１１１０（例えば、ＡＢＣＤＡＢＣＤＡＢＣＤ…行）は、複数のＧＰＵ間でジオメトリテストを実行するレスポンシビリティの均等な分散を示している。具体的には、１つのＧＰＵにジオメトリの最初の４分の１を取らせ（例えば、ブロックで、ＧＰＵ－Ａが約１６個の合計ピースのうちの「ａ」、「ｂ」、「ｃ」及び「ｄ」を含む最初の４つのピースをテストのために取る）、２番目のＧＰＵに２番目の４分の１を取らせる、などではなく、ＧＰＵへの割り当てはインターリーブされる。つまり、レンダリングのＺプレパスフェーズを実行するために、連続するジオメトリのピースが異なるＧＰＵに割り当てられる。例えば、ピース「ａ」はＧＰＵ－Ａに割り当てられ、ピース「ｂ」はＧＰＵ－Ｂに割り当てられ、ピース「ｃ」はＧＰＵ－Ｃに割り当てられ、ピース「ｄ」はＧＰＵ－Ｄに割り当てられ、ピース「ｅ」はＧＰＵ－Ａに割り当てられ、ピース「ｆ」はＧＰＵ－Ｂに割り当てられ、ピース「ｇ」はＧＰＵ－Ｃに割り当てられる。結果として、（ＧＰＵ－Ａがジオメトリのピースの最初の４分の１を取得した場合などのように）処理するジオメトリのピースの合計数を知る必要は無く、レンダリングのＺプレパスフェーズの処理はＧＰＵ（例えば、ＧＰＵ－Ａ、ＧＰＵ－Ｂ、ＧＰＵ－Ｃ、及びＧＰＵ－Ｄ）間でほぼバランスが取れている。

他の実施形態では、１つのフレーム（例えば前の画像フレーム）のレンダリング中に生成された情報を使用して、後続のフレーム（例えば現在の画像フレーム）のスクリーン領域にＧＰＵを割り当てることができる。例えば、ハードウェアは、前の画像フレームのレンダリングのジオメトリパスフェーズ中のＧＰＵの使用状況など、前の画像フレームのレンダリングのジオメトリパスフェーズ中に情報を生成するように構成できる。具体的には、この情報には、スクリーン領域ごとのジオメトリのピースごとにシェーディングされる実際のピクセルの数が含まれ得る。この情報は、レンダリングのジオメトリパスのスクリーン領域にＧＰＵを割り振るときに、後続のフレーム（例えば、現在の画像フレームのレンダリング）で使用できる。つまり、現在の画像フレームのレンダリングのジオメトリパスフェーズを実行するためのＧＰＵへのスクリーン領域の割り当てでは、前述のとおり、前の画像フレームから生成された情報と、現在の画像フレーム（もしあれば）のＺプレパスフェーズで生成された情報の両方が考慮される。そのため、スクリーン領域は、前の画像フレームからの情報（例えば、ＧＰＵの使用状況）と、現在の画像フレームのレンダリングのＺプレパスフェーズ中に生成された情報（存在する場合）に基づいて、ＧＰＵに割り当てられる。

前のフレームからのこの情報は、前述のオーバーラップ面積を使用するだけ（例えば、現在の画像フレームの情報を生成する場合）、またはＺプレパス中にスクリーン領域ごとのジオメトリのピースごとにＺバッファに書き込まれたピクセルの数を使用するだけよりも、精度を高めることができる。例えば、オブジェクトのＺバッファに書き込まれるピクセルの数は、他のオブジェクトによるオブジェクトの閉塞に起因してジオメトリパスでシェーディングする必要があるピクセルの数に対応しない場合がある。前の画像フレームからの情報（例えば、ＧＰＵの使用状況）と、現在の画像フレームのレンダリングのＺプレパスフェーズ中に生成された情報の両方を使用すると、現在の画像フレームのレンダリングのジオメトリパスフェーズ中にレンダリングがより効率的になり得る。

情報はまた、対応するスクリーン領域にオーバーラップするジオメトリの対応する部分（例えば、ジオメトリのピース）によって使用される頂点の数を与える、各スクリーン領域の頂点数を含むことができる。そのため、後で対応するジオメトリのピースをレンダリングするときに、レンダリングＧＰＵは頂点数を使用して、位置キャッシュとパラメータキャッシュにスペースを割り振ることができる。例えば、一実施形態では、必要とされない頂点には割り振られたスペースがなく、これによりレンダリングの効率を高めることができる。

さらに別の実施形態では、レンダリングのＺプレパスフェーズ中に情報を生成することに関連する処理オーバーヘッド（ソフトウェアまたはハードウェアのいずれか）が存在する場合がある。その場合、ジオメトリの特定のピースについての情報の生成をスキップすることが有益であり得る。つまり、特定のオブジェクトについて情報が生成されて、他のオブジェクトについては生成されなくてもよい。例えば、大きなプリミティブを有し、多数のスクリーン領域にオーバーラップする可能性が高いジオメトリのピース（例えば、オブジェクトまたはオブジェクトの部分）については、情報が生成されなくてもよい。大きなプリミティブを有するオブジェクトは、スカイボックスである場合や、例えば大きな三角形を含む大きな地形のピースである場合がある。その場合、画像フレームのマルチＧＰＵレンダリングに使用される各ＧＰＵは、それらのジオメトリのピースをレンダリングする必要がある可能性が高く、そのことを示す情報は不要である。このように、情報は、対応するジオメトリのピースの特性に応じて、生成されても生成されなくてもよい。

レンダリング前のジオメトリ解析実行によるジオメトリの効率的なマルチＧＰＵレンダリングのためのシステム及び方法
図１～３のクラウドゲームネットワーク１９０（例えば、ゲームサーバ１６０内）及びＧＰＵリソース３６５の詳細な説明とともに、図１２Ａの流れ図１２００Ａは、本開示の一実施形態による、レンダリング前にジオメトリ解析を実行することによるアプリケーション用のジオメトリのマルチＧＰＵレンダリングを含む、グラフィック処理の方法を示す。即ち、図７、９、及び１０に関連して説明したようにレンダリング中に情報を生成する代わりに、情報は、プレパス（すなわち、ＺバッファまたはＭＲＴに書き込まないパス）中など、レンダリングの前に生成される。レンダリング中の情報の生成（例えば、レンダリングのＺプレパスフェーズ）に関して説明された様々な実施形態の様々な特徴及び利点の１つまたは複数は、レンダリング前の情報の生成（例えば、ジオメトリ解析を実行するプレパス）にも等しく適用可能であり、説明の重複を最小限に抑えるために、ここでは繰り返さない場合があることが理解される。前述のように、様々なアーキテクチャは、クラウドゲームシステムの１つまたは複数のクラウドゲームサーバ内、または、複数のＧＰＵを有するハイエンドグラフィックカードを含むパーソナルコンピュータやゲームコンソールなどのスタンドアロンシステム内などで、レンダリング中に領域テストを介してアプリケーション用のジオメトリのマルチＧＰＵレンダリングを実行することにより、単一の画像をレンダリングするために連携する、複数のＧＰＵを含むことができる。

具体的には、各ＧＰＵがその割り当てられたスクリーン領域でオブジェクトをレンダリングするように、ＧＰＵレンダリングのレスポンシビリティが各画像フレームの複数のスクリーン領域間で動的に割り当てられる。解析は、ジオメトリレンダリングの前に（例えば、プリミティブシェーダまたは計算シェーダで）実行され、画像フレーム内のジオメトリの空間分散を決定し、スクリーン領域に対するＧＰＵのレスポンシビリティを動的に調整して、その画像フレーム内のオブジェクトをレンダリングする。

１２１０において、この方法は、複数のグラフィック処理ユニット（ＧＰＵ）を使用してアプリケーション用のグラフィックをレンダリングすることを含む。具体的には、多数のＧＰＵが連携して画像フレームを生成する。具体的には、単一の画像フレーム及び／またはリアルタイムアプリケーション用の一連の画像フレームの１つまたは複数の画像フレームのそれぞれをレンダリングするときにマルチＧＰＵ処理が実行される。レンダリングのレスポンシビリティは、以下でさらに説明するように、各画像フレームのスクリーン領域に基づいて複数のＧＰＵ間で分割される。

１２２０において、方法は、複数のＧＰＵ間での解析プレパス中に画像フレームの複数のジオメトリのピースを処理するレスポンシビリティを分割することを含み、複数のジオメトリのピースのそれぞれが、対応するＧＰＵに割り当てられる。解析プレパスは、画像フレームのレンダリングのフェーズの前に実行される。

解析プレパスでは、オブジェクトは複数のＧＰＵ間に分散される。例えば、４つのＧＰＵを有するマルチＧＰＵアーキテクチャでは、各ＧＰＵは解析プレパス中にオブジェクトの約４分の１を処理する。前述のように、一実施形態では、オブジェクトをジオメトリのより小さなピースに再分割することには利点があり得る。加えて、他の実施形態では、オブジェクトは、画像フレームごとにＧＰＵに動的に割り当てられる。解析プレパスのためにＧＰＵにジオメトリのピースを動的に割り当てると、処理効率が向上し得る。

解析プレパスはレンダリングフェーズの前に実行されるため、処理は通常、ハードウェアでは実行されない。すなわち、解析プレパスは、様々な実施形態でシェーダを使用するなどして、ソフトウェアで実行することができる。例えば、プリミティブシェーダは、対応するピクセルシェーダがないように、解析プレパス中に使用されてもよい。加えて、Ｚバッファ及び／または他のレンダーターゲットは、解析プレパス中に書き込まれない。他の実施形態では、計算シェーダが使用される。

１２３０において、方法は、複数のスクリーン領域のそれぞれとの、複数のジオメトリのピースのそれぞれのプレパスフェーズオーバーラップを解析において決定することを含む。前述のように、ジオメトリのピースは、オブジェクトまたはオブジェクトの部分（例えば、個々のプリミティブ、プリミティブのグループなど）であり得る。一実施形態では、生成された情報は、複数のスクリーン領域のそれぞれとの、複数のジオメトリのピースのそれぞれのオーバーラップの正確な表示を含む。一実施形態では、情報は、複数のスクリーン領域のそれぞれとの、複数のジオメトリのピースのそれぞれのオーバーラップの概算を含む。

１２４０において、方法は、複数のスクリーン領域のそれぞれとの、複数のジオメトリのピースのそれぞれのオーバーラップに基づいて、複数のジオメトリのピース及び複数のスクリーン領域に対するそれらの関係に関する情報を生成することを含む。情報は、単にオーバーラップがあるということであってもよい。情報は、ジオメトリのピースがスクリーン領域でオーバーラップするかまたはカバーするピクセル面積または概算ピクセル面積を含むことができる。情報は、スクリーン領域に書き込まれたピクセルの数を含むことができる。情報は、スクリーン領域にオーバーラップする頂点またはプリミティブの数、またはその概算値を含むことができる。

１２５０において、方法は、レンダリングのジオメトリパスフェーズ中に複数のジオメトリのピースをレンダリングするために、情報に基づいて複数のスクリーン領域を複数のＧＰＵに動的に割り当てることを含む。すなわち、情報は、その後の複数のＧＰＵへのスクリーン領域の割り当てに使用することができる。例えば、各ＧＰＵは、情報に基づいて対応するスクリーン領域に割り当てられる。このようにして、各ＧＰＵは、画像フレームのレンダリングのための対応するレスポンシビリティ（例えば、対応するスクリーン領域）のディビジョンを有する。そのため、ＧＰＵへのスクリーン領域の割り当ては、画像フレームごとに異なる場合がある。

さらに、方法は、ジオメトリパスフェーズ中に、複数のＧＰＵに複数のスクリーン領域を割り当てることから決定されたＧＰＵからスクリーン領域への割り当てに基づいて、複数のＧＰＵのそれぞれで複数のジオメトリのピースをレンダリングすることを含む。

図１２Ｂは、本開示の一実施形態による、画像フレームをレンダリングする前に（例えば、レンダリングのジオメトリパスフェーズ中に）実行される解析プレパスを示す、レンダリングタイミング図１２００Ｂである。解析プレパスは、ジオメトリのピースとスクリーン領域の間の関係の解析専用である。解析プレパスは、画像フレームのジオメトリレンダリングのために、スクリーン領域をＧＰＵに動的に割り当てるために使用される情報を生成する。具体的には、レンダリングタイミング図１２００Ｂは、複数のＧＰＵを使用して画像フレームを連携してレンダリングすることを示している。レンダリングのレスポンシビリティは、スクリーン領域に基づいて複数のＧＰＵ間で分割される。前述のように、画像フレームのジオメトリをレンダリングする前に、ＧＰＵはジオメトリとそのスクリーン領域との関係に関する情報を生成する。この情報は、ＧＰＵをスクリーン領域に割り当てるために使用され、より効率的なレンダリングを可能にする。例えば、レンダリングの前に、第１のＧＰＵがジオメトリのピースとそのスクリーン領域との関係に関する情報を生成し、この情報は、そのジオメトリのピースをレンダリングする１つまたは複数の「レンダリングＧＰＵ」にスクリーン領域を割り当てる際に使用される。

具体的には、レンダリングタイミング図１２００Ｂは、タイムライン１２９０を参照して、４つのＧＰＵ（例えば、ＧＰＵ－Ａ、ＧＰＵ－Ｂ、ＧＰＵ－Ｃ、及びＧＰＵ－Ｄ）による１つまたは複数のオブジェクトのレンダリングを示す。前述のように、４つのＧＰＵの使用は、マルチＧＰＵアーキテクチャに１つまたは複数のＧＰＵを含めることができるように、単に説明を目的としたものである。垂直線１２０１は、画像フレームの一連のレンダリングフェーズの開始を示す。垂直線１２０１は、解析プレパス１２１０の開始も示す。解析プレパスでは、オブジェクトは複数のＧＰＵの間で分散される。４つのＧＰＵを用いて、各ＧＰＵがオブジェクトの約４分の１を処理する。シンクポイント１２３０Ａは、各ＧＰＵがそれぞれのジオメトリパスレンダリングフェーズ１２２０を同時に開始するように提供される。すなわち、一実施形態では、シンク操作１２３０ａは、すべてのＧＰＵによるジオメトリパスの同時開始を保証する。別の実施形態では、前に説明したように、シンク操作１２３０ａは使用されず、レンダリングのジオメトリパスフェーズが、解析プレパスを終了する任意のＧＰＵに対して、他のすべてのＧＰＵが対応する解析プレパスを終了するのを待たずに開始され得る。

シンクポイント１２３０ｂは、現在の画像フレームのレンダリングのジオメトリパスフェーズの終了を示し、また、各ＧＰＵが現在のフレームのレンダリングの後続フェーズを同時に続行できるように、または次の画像フレームのレンダリングを同時に開始できるように提供される。

一実施形態では、対応する画像フレームをレンダリングするために、単一のコマンドバッファが複数のＧＰＵによって使用される。レンダリングコマンドバッファには、解析プレパスを実行するために、状態を設定するコマンドと、プリミティブシェーダまたはコンピュータシェーダを実行するコマンドとを含めることができる。ＧＰＵによる様々な操作の開始を同期するために、シンク操作をコマンドバッファ内に含めることができる。例えば、シンク操作を使用して、ＧＰＵによるレンダリングのジオメトリパスフェーズの開始を同期することができる。そのため、コマンドバッファには、レンダリングのジオメトリパスフェーズを実行するための各オブジェクトのドローコールと状態設定が含まれ得る。

一実施形態では、情報の生成は、専用の１つまたは複数の命令を使用することによって加速される。つまり、情報を生成するシェーダは、１つまたは複数の専用命令を使用して、ジオメトリのピースとそのスクリーン領域との関係に関する情報の生成を加速する。

一実施形態では、命令は、ジオメトリのピースのプリミティブとスクリーン領域のそれぞれとの間の正確なオーバーラップを計算することができる。例えば、図１３Ａは、本開示の一実施形態による、画像フレームのジオメトリレンダリングのためのＧＰＵへのスクリーン領域の動的割り当てに使用される情報を生成するために、解析プレパスフェーズを実行するときの、プリミティブ１３５０と１つまたは複数のスクリーン領域の間の正確なオーバーラップの計算を示す図１３１０である。例えば、プリミティブ１３５０は、３つの異なる領域をオーバーラップするように示され、プリミティブ１３５０のそれぞれの部分のオーバーラップは、領域のそれぞれについて正確に決定される。

他の実施形態では、命令実施態様の複雑さを低減するために、この命令はオーバーラップ面積の概算を実行することができ、情報は、プリミティブが１つまたは複数のスクリーン領域とオーバーラップする概算面積を含む。具体的には、命令は、ジオメトリのピースのプリミティブと１つまたは複数のスクリーン領域との間の概算のオーバーラップを計算することができる。例えば、図１３Ｂは、本開示の一実施形態による、画像フレームのジオメトリレンダリングのためのＧＰＵへのスクリーン領域の動的割り当てに使用される情報を生成するために、解析プレパスフェーズを実行するときの、ジオメトリのピースと複数のスクリーン領域の間の概算のオーバーラップの計算を示す一対の図である。

図１３Ｂの左側の図に示すように、命令はプリミティブの境界ボックスを使用することができる。こうして、プリミティブ１３５０の境界ボックスと１つまたは複数のスクリーン領域とのオーバーラップが決定される。境界１３２０Ａは、境界ボックスの解析を通じて決定されたジオメトリ１３５０のピースの概算のオーバーラップを示す。

図１３Ｂの右側の図において、命令は、プリミティブに対してスクリーン領域をチェックし、ジオメトリのピースがオーバーラップしないスクリーン領域が除外され、各スクリーン領域とオーバーラップするプリミティブの部分に対して境界ボックスが生成される。境界１３２０Ｂは、境界ボックスの解析及びオーバーラップフィルタリングによって決定されるプリミティブ１３５０の概算のオーバーラップを示す。図１３Ｂの右側の図の境界ボックス１３２０Ｂは、図１３Ｂの左側の図の境界ボックス１３２０Ａよりも小さいことに留意されたい。

さらに他の実施形態では、命令の複雑さをさらに低減するために、命令は、ジオメトリのピースがスクリーン領域に存在するかどうかなどの存在情報を生成することができる。例えば、存在情報は、ジオメトリのピースのプリミティブがスクリーン領域とオーバーラップするかどうかを示すことができる。情報は、対応するスクリーン領域内のジオメトリのピースの概算の存在を含むことができる。

別の実施形態では、シェーダは、位置キャッシュまたはパラメータキャッシュにスペースを割り当てない。つまり、シェーダは位置またはパラメータキャッシュの割り振りを実行せず、それにより解析プレパスを実行するときに高度な並列処理が可能になる。これはまた、解析プレパスに必要な時間の対応する削減にもつながる。

別の実施形態では、解析プレパスで実行される解析、またはジオメトリパスでのレンダリングのいずれかを実行するために、単一のシェーダが使用される。例えば、情報を生成するシェーダは、ジオメトリのピースとそのスクリーン領域との関係に関する情報を出力するように、または後のレンダリングステージで使用することによって頂点位置とパラメータ情報を出力するように構成可能であってもよい。これは、シェーダがチェックできる外部ハードウェア状態（例えば、ハードウェアレジスタの設定）を介して、またはシェーダへの入力を介してなど、様々な方法で実現できる。その結果、シェーダは２つの異なる機能を実行して、対応する画像フレームをレンダリングする。

前述のように、レンダリングのジオメトリパスフェーズを開始する前に、この情報を使用して領域をＧＰＵに割り当てる。前のフレームのレンダリング中に生成された情報（例えば、ジオメトリのピースをレンダリングする間にシェーディングされた実際のピクセル数）は、スクリーン領域をＧＰＵに割り当てるために使用することもできる。前のフレームからの情報には、例えば、スクリーン領域ごとのジオメトリのピースごとにシェーディングされる実際のピクセルの数が含まれ得る。つまり、スクリーン領域は、前の画像フレームから生成された情報（例えば、ＧＰＵの使用状況）と解析プレパス中に生成された情報に基づいてＧＰＵに割り当てられる。

ジオメトリの再分割によるジオメトリの効率的なマルチＧＰＵレンダリングのシステム及び方法
図１～３のクラウドゲームネットワーク１９０（例えば、ゲームサーバ１６０内）及びＧＰＵリソース３６５の詳細な説明と共に、図１４Ｂのライン１１１０は、ジオメトリを再分割することによるアプリケーションのマルチＧＰＵレンダリングを含むグラフィック処理のための方法を示す。オブジェクト０、１、及び２は、個々のドローコールによって使用または生成されたジオメトリを表す。オブジェクト全体（つまり、ドローコール）をＧＰＵ－Ａ、ＧＰＵ－Ｂ、ＧＰＵ－Ｃ、及びＧＰＵ－Ｄに分散するのではなく、代わりに、ＧＰＵは各オブジェクトを、位置及び／またはパラメータキャッシュが割り当てられるおおよそのサイズのピースなど、ジオメトリのより小さなピースに分割する。純粋に説明のために、オブジェクト０は、図６Ｂのオブジェクト６１０のように、ピース「ａ」、「ｂ」、「ｃ」、「ｄ」、「ｅ」及び「ｆ」に分割される。また、オブジェクト１は、ピース「ｇ」、「ｈ」、及び「ｉ」に分割される。さらに、オブジェクト２はピース「ｊ」、「ｋ」、「ｌ」、「ｍ」、「ｎ」、及び「ｏ」に分割される。分散１１１０（例えば、ＡＢＣＤＡＢＣＤＡＢＣＤ…行）は、複数のＧＰＵ間でのレンダリング（またはレンダリングのフェーズ）のレスポンシビリティの均等な分散を示している。この分散はオブジェクト全体（つまり、ドローコール）よりも粒度が細かいため、ＧＰＵ間のレンダリング時間の不均衡が減少し、レンダリングの合計時間（またはレンダリングのフェーズの時間）が減少する。図１４Ａの流れ図１４００Ａと図１４Ｂのライン１４１０は、レンダリングフェーズ中にＧＰＵのレスポンシビリティの割り当てを再分散するために、レンダリングフェーズ中にタイミング解析を実行することによる、アプリケーションのためのジオメトリのマルチＧＰＵレンダリングを含むグラフィック処理のための方法を示す。図７～１３のレンダリング及びレンダリングのジオメトリパスフェーズの前及びその最中の情報の生成に関して説明された様々な実施形態の様々な特徴及び利点の１つまたは複数が、ジオメトリを再分割する、及び／またはタイミング解析を実行するときの使用に等しく適用でき、説明の重複を最小限に抑えるために、ここでは繰り返さない場合がある、ということが理解される。前述のように、様々なアーキテクチャは、クラウドゲームシステムの１つまたは複数のクラウドゲームサーバ内、または、複数のＧＰＵを有するハイエンドグラフィックカードを含むパーソナルコンピュータやゲームコンソールなどのスタンドアロンシステム内などで、レンダリング中に領域テストを介してアプリケーションのジオメトリのマルチＧＰＵレンダリングを実行することにより、単一の画像をレンダリングするために連携する、複数のＧＰＵを含むことができる。

いくつかの実施形態では、図７～１３に関して前に説明したように、各ＧＰＵがその割り当てられたスクリーン領域でオブジェクトをレンダリングするように、ＧＰＵレンダリングのレスポンシビリティが各画像フレームの複数のスクリーン領域間で固定的または動的に割り当てられる。他の実施形態では、各ＧＰＵは、それ自体のＺバッファまたは他のレンダーターゲットにレンダリングする。レンダリングのフェーズの１つまたは複数（例えば、ジオメトリプレパス解析、Ｚプレパス、またはジオメトリレンダリング）でタイミング解析が実行され、その目的は、これらのフェーズでＧＰＵのレスポンシビリティの割り当てを再分散するためである。つまり、レンダリングフェーズ中にＧＰＵのレスポンシビリティの割り当てを再分散するために、レンダリングフェーズ中にタイミング解析が実行され、それは例えば、一実施態様では、画像フレームのジオメトリレンダリングのためにジオメトリのピースに対してＺプレパスフェーズを実行して、ＧＰＵへのスクリーン領域の動的割り当てに使用される情報を生成するときなどである。例えば、最初に１つのＧＰＵに割り当てられたスクリーン領域が、レンダリングのフェーズ中に別のＧＰＵに再割り当てされる場合がある（例えば、あるＧＰＵがそのフェーズ中に他のＧＰＵに遅れている可能性がある）。

１４１０において、方法は、複数のグラフィック処理ユニット（ＧＰＵ）を使用してアプリケーション用のグラフィックをレンダリングすることを含む。具体的には、単一の画像フレーム及び／またはリアルタイムアプリケーション用の一連の画像フレームの１つまたは複数の画像フレームのそれぞれをレンダリングするときにマルチＧＰＵ処理が実行される。すなわち、複数のＧＰＵは連携して、複数のジオメトリのピースを含む対応する画像フレームをレンダリングする。

１４２０において、方法は、複数のスクリーン領域に基づいて、複数のＧＰＵ間でグラフィックのジオメトリのレンダリングに対するレスポンシビリティを分割することを含む。つまり、各ＧＰＵは、対応するレスポンシビリティのディビジョン（対応するスクリーン領域のセット）を有する。

ジオメトリのレンダリングまたはジオメトリの解析の実行中、レンダリングまたは解析にかかる時間は、オブジェクトに関するレスポンシビリティのディビジョンを調整するために使用される。特に、１４３０において、方法は、画像フレームのレンダリングまたは解析のフェーズ中に、第１のＧＰＵが、第２のＧＰＵなど、少なくとも１つの他のＧＰＵに遅れていると判断することを含む。１４４０において、方法は、第１のＧＰＵが第２のＧＰＵより少なく割り当てられるようにジオメトリを動的に割り当てることを含む。

例えば、ジオメトリの動的な割り当ては、説明の目的で、Ｚバッファの生成中に実行することができる。ジオメトリの動的割り当ては、解析プレパス及び／またはレンダリングのジオメトリパスフェーズ中に実行され得る。Ｚバッファの生成及びＺプレパス解析中にジオメトリを動的に割り当てる場合、１つまたは複数のＺバッファが複数のＧＰＵによって生成される、及び／またはレンダリングのＺプレパスフェーズ中に画像フレームに対して連携してマージされる。具体的には、ジオメトリのピースは、レンダリングのＺプレパスフェーズを処理するためにＧＰＵ間で分割され、複数のジオメトリのピースのそれぞれは、対応するＧＰＵに割り当てられる。対応する画像フレームのレンダリングを最適化するのに使用される情報を生成するために、Ｚプレパスフェーズ中にハードウェアを使用する代わりに、ハードウェアは、解析プレパスを実行して、例えば、後続のジオメトリパスのレンダリング速度を最適化するために使用される情報を生成するように構成することができる。

具体的には、オブジェクトは、図６Ｂで前に説明したように、より小さなピースに再分割することができる。レンダリングのＺプレパスフェーズにおけるジオメトリのピースのレンダリングのレスポンシビリティは、図１４Ｂの分散１１１０に関して前述したように、インターリーブ方式でＧＰＵ間に分散され、図１４Ｂは、レンダリングのＺプレパスフェーズを実行して、画像フレームのジオメトリレンダリングのためにスクリーン領域をＧＰＵに動的に割り当てるために使用される情報を生成するためのＧＰＵ割り当ての様々な分散を示す。分散１１１０は、Ｚプレパスに対する複数のＧＰＵ間のレンダリングレスポンシビリティの分散を示している。前述のように、各ＧＰＵは画像フレームのジオメトリの対応する部分に割り当てられ、その部分はさらにジオメトリのピースに分割され得る。分散１１１０に示すように、ジオメトリの連続するピースが異なるＧＰＵに割り当てられるため、結果として、Ｚプレパス中のレンダリング時間はほぼバランスがとれる。

分散１４１０に示すように、ジオメトリのピースをレンダリングするレスポンシビリティを動的に調整することで、ＧＰＵ間のレンダリング時間のさらなるバランスを実現できる。これは、レンダリングのＺプレパスフェーズを実行するときのＧＰＵへのジオメトリのピースの分散であり、レンダリングのそのフェーズ中に動的に調整される。例えば、分散１４１０［ＡＢＣＤＡＢＣＤＢＣＤＢＢＣＤ行］は、複数のＧＰＵ間でＺプレパスフェーズを実行するレスポンシビリティの非対称分散を示している。例えば、特定のＧＰＵに、他のＧＰＵに割り当てられたものよりも大きいジオメトリのピースが割り当てられていることにより他のＧＰＵに比べてＺプレパスが遅れている場合、非対称分散が有利になり得る。

分散１４１０に示すように、ＧＰＵ－Ａは、Ｚプレパスフェーズ中にジオメトリのピースをレンダリングするためにより多くの時間を費やしているため、ジオメトリのピースをＧＰＵに割り当てるときにスキップされる。例えば、Ｚプレパスレンダリング中にオブジェクト１のジオメトリ「ｉ」のピースをＧＰＵ－Ａに処理させる代わりに、ＧＰＵ－ＢがＺプレパスフェーズ中にジオメトリのピースをレンダリングするように割り当てられる。そのため、ＧＰＵ－Ｂには、レンダリングのＺプレパスフェーズ中にＧＰＵ－Ａよりも多くのジオメトリのピースが割り当てられる。具体的には、レンダリングのＺプレパスフェーズ中に、ジオメトリのピースが第１のＧＰＵから割り当て解除され、第２のＧＰＵに割り当てられる。さらに、ＧＰＵ－Ｂは他のＧＰＵよりも進んでいるため、Ｚプレパスフェーズ中により多くのジオメトリを処理できる。すなわち、分散１４１０は、Ｚプレパスレンダリングのための連続するジオメトリのピースへのＧＰＵ－Ｂの繰り返し割り当てを示す。例えば、ＧＰＵ－Ｂは、Ｚプレパスフェーズ中にオブジェクト２のジオメトリのピース「ｌ」と「ｍ」を処理するために割り当てられる。

上記はジオメトリの「動的割り当て」の観点から提示されているが、これを「割り当て」と「再割り当て」の観点から見ることも等しく有効である。例えば、分散１４１０に示すように、ＧＰＵ－Ａは、Ｚプレパスフェーズ中にジオメトリのピースをレンダリングするのにより多くの時間を費やしているため、再割り当てされる。例えば、Ｚプレパスレンダリング中にオブジェクト１のジオメトリ「ｉ」のピースをＧＰＵ－Ａに処理させる代わりに、ＧＰＵ－ＢがＺプレパスフェーズ中にジオメトリのピースをレンダリングするように割り当てられ、ＧＰＵ－Ａは、ジオメトリのピースをレンダリングするために最初に割り当てられていてもよい。さらに、ＧＰＵ－Ｂは他のＧＰＵよりも進んでいるため、Ｚプレパスフェーズ中により多くのジオメトリを処理できる。すなわち、分散１４１０は、Ｚプレパスレンダリングのための連続するジオメトリのピースへのＧＰＵ－Ｂの繰り返し割り当てかまたは再割り当てを示す。例えば、ＧＰＵ－Ｂは、Ｚプレパスフェーズ中にオブジェクト２のジオメトリのピース「ｌ」と「ｍ」を処理するために割り当てられる。つまり、オブジェクト２のジオメトリのピース「ｌ」をレンダリングするために、そのジオメトリのピースが最初にＧＰＵ－Ａに割り当てられていた可能性があっても、ＧＰＵ－Ｂが割り当てられる。そのため、第１のＧＰＵに初めに割り当てられたジオメトリのピースは、レンダリングのＺプレパスフェーズ中に第２のＧＰＵ（レンダリングが進んでいる可能性がある）に再割り当てされる。

ＧＰＵへのＺプレパスフェーズ中のジオメトリのピースの割り当てはバランスが取れていない可能性があるが、ＧＰＵによって実行されるＺプレパスフェーズ中の処理は、ほぼバランスが取れていることが判明する場合がある（例えば、各ＧＰＵはレンダリングのＺプレパスフェーズを実行するためにほぼ同じ時間を費やす）。

別の実施形態では、ジオメトリの動的割り当ては、画像フレームのレンダリングのジオメトリパスフェーズ中に実行することができる。例えば、スクリーン領域は、Ｚプレパスまたは解析プレパス中に生成された情報に基づいて、レンダリングのジオメトリパスフェーズ中にＧＰＵに割り当てられる。あるＧＰＵに割り当てられたスクリーン領域は、レンダリングフェーズ中に別のＧＰＵに再割り当てされる場合がある。これにより、効率が向上する可能性があり、これは他のＧＰＵよりも進んでいるＧＰＵには追加のスクリーン領域が割り振られる可能性があり、他のＧＰＵよりも遅れているＧＰＵは追加のスクリーン領域が割り振られるのを回避できるからである。特に、連携する複数のＧＰＵは、レンダリングのＺプレパスフェーズ中に画像フレームのＺバッファを生成する。情報は、このＺプレパス中に、画像フレームのジオメトリのピースとそれらの複数のスクリーン領域との関係について生成される。スクリーン領域は、レンダリングのジオメトリパスフェーズ中に画像フレームをレンダリングするために、情報に基づいてＧＰＵに割り当てられる。ＧＰＵは、ＧＰＵからスクリーン領域への割り当てに基づくレンダリングのジオメトリパスフェーズ中に、ジオメトリのピースをレンダリングする。タイミング解析は、レンダリングのジオメトリパスフェーズ中に実行され、その結果、初めに第１のＧＰＵに割り当てられたジオメトリの第１のピースが、ジオメトリパスフェーズ中にレンダリングするために第２のＧＰＵに再割り当てされ得る。例えば、一実施形態では、レンダリングのジオメトリパスフェーズの処理において、第１のＧＰＵが遅れている可能性がある。別の実施形態では、レンダリングのジオメトリパスフェーズの処理において、第２のＧＰＵが進んでいる可能性がある。

図１５Ａ～１５Ｂは、様々なスクリーン領域割り振り戦略を示しており、これは、図７～１４に関して前に説明した画像フレームのレンダリングに適用できる。

具体的には、図１５Ａは、本開示の一実施形態による、特定のスクリーン領域においてジオメトリ（例えば、オブジェクト０～３に関連するジオメトリ）のピースをレンダリングするために複数のＧＰＵの使用することを示す図である。すなわち、スクリーン領域１５１０は、レンダリングするために複数のＧＰＵに割り当てられ得る。例えば、これにより、レンダリングフェーズの後半で非常に密集したジオメトリがある場合などに、効率が向上する可能性がある。スクリーン領域１５１０を複数のＧＰＵに割り当てるには、通常、スクリーン領域を再分割する必要があるため、各ＧＰＵがスクリーン領域の一部分または部分のレスポンシビリティを有することができる。

図１５Ｂは、本開示の一実施形態による、ジオメトリのピースをそれらの対応するドローコールとは順不同でレンダリングすることを示す図である。特に、ジオメトリのピースのレンダリング順序は、対応するコマンドバッファ内の対応するドローコールの順序と一致しない場合がある。この例に示すように、オブジェクト０は、レンダリングコマンドバッファ内でオブジェクト１よりも優先される。しかしながら、オブジェクト０と１は、スクリーン領域Ｃ内などで交差する。その場合、領域Ｃではレンダリングの厳密な順序を守る必要があり得る。つまり、オブジェクト０は領域Ｃにおいてオブジェクト１の前にレンダリングする必要がある。

一方、領域Ａと領域Ｂのオブジェクトは、交差がないため、任意の順序でレンダリングできる。つまり、領域Ａ及び／または領域Ｂをレンダリングするときに、オブジェクト１がオブジェクト０に先行する場合もあれば、その逆の場合もある。

さらに別の実施形態では、レンダリングコマンドバッファを複数回トラバーサルできる場合、第１のトラバーサルで特定のスクリーン領域（例えば、高コスト領域）をレンダリングし、第２またはそれ以降のトラバーサルで残りの領域（例えば、低コスト領域）をレンダリングすることが可能である。結果として得られるジオメトリのピースのレンダリング順序は、第１のオブジェクトが第２のトラバーサルでレンダリングされる場合などは、対応するドローコールの順序と一致しない場合がある。ＧＰＵ間の負荷バランシングは、高コスト領域よりも低コスト領域の方が簡単であるため、この戦略により、対応する画像フレームをレンダリングする際の効率が向上する。

図１６は、本開示の様々な実施形態の態様を実行するために使用することができる例示的なデバイス１６００のコンポーネントを示す。例えば、図１６は、本開示の実施形態による、レンダリング中にジオメトリ解析を実行して、画像フレームのジオメトリレンダリングのためにスクリーン領域をＧＰＵに動的に割り当てることによる、及び／または、レンダリングの前にジオメトリ解析を実行して、画像フレームのジオメトリレンダリングのためにスクリーン領域をＧＰＵに動的に割り当てることによる、及び／または、ジオメトリのピースを再分割し、結果として得られるジオメトリのより小さな部分を複数のＧＰＵに割り当てることによる、アプリケーションのためのジオメトリのマルチＧＰＵレンダリングに適した例示的なハードウェアシステムを示す。このブロック図は、パーソナルコンピュータ、サーバコンピュータ、ゲームコンソール、モバイルデバイス、または他のデジタルデバイスを組み込むことができる、またはそれらであってもよく、それらの各々が本発明の実施形態を実践するのに適している、デバイス１６００を示している。デバイス１６００は、ソフトウェアアプリケーション及び任意選択でオペレーティングシステムを実行するための、中央処理装置（ＣＰＵ）１６０２を含む。ＣＰＵ１６０２は、１つまたは複数の同種または異種の処理コアから構成されてもよい。

様々な実施形態によれば、ＣＰＵ１６０２は、１つまたは複数の処理コアを有する１つ以上の汎用マイクロプロセッサである。さらなる実施形態は、ゲーム実行中のグラフィック処理のために構成されたアプリケーションの、メディア及びインタラクティブエンターテインメントアプリケーションなどの、きわめて並列かつ計算集約的なアプリケーションに特に適合されたマイクロプロセッサアーキテクチャを有する１つまたは複数のＣＰＵを使用し、実装することができる。

メモリ１６０４は、ＣＰＵ１６０２とＧＰＵ１６１６とが使用するアプリケーション及びデータを記憶する。ストレージ１６０６は、アプリケーション及びデータ用の不揮発性ストレージ及び他のコンピュータ可読媒体を提供し、かつ、固定ディスクドライブ、取り外し可能ディスクドライブ、フラッシュメモリデバイス、及びＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、Ｂｌｕ－ｒａｙ（登録商標）、ＨＤ－ＤＶＤ、または他の光学記憶デバイス、ならびに信号伝送及び記憶媒体を含み得る。ユーザ入力デバイス１６０８は、１人または複数のユーザからのユーザ入力をデバイス１６００に伝達するものであり、その例としては、キーボード、マウス、ジョイスティック、タッチパッド、タッチスクリーン、スチルまたはビデオレコーダ／カメラ、及び／またはマイクロフォンがあり得る。ネットワークインタフェース１６０９は、デバイス１６００が電子通信ネットワークを介して他のコンピュータシステムと通信することを可能にし、ローカルエリアネットワーク、及びインターネットなどのワイドエリアネットワークにわたる有線または無線通信を含み得る。オーディオプロセッサ１６１２は、ＣＰＵ１６０２、メモリ１６０４、及び／またはストレージ１６０６によって提供される命令及び／またはデータから、アナログまたはデジタルのオーディオ出力を生成するように適合されている。ＣＰＵ１６０２、ＧＰＵ１６１６を含むグラフィックサブシステム、メモリ１６０４、データストレージ１６０６、ユーザ入力デバイス１６０８、ネットワークインタフェース１６０９、及びオーディオプロセッサ１６１２を含むデバイス１６００のコンポーネントは、１つまたは複数のデータバス１６２２を介して接続されている。

グラフィックサブシステム１６１４はさらに、データバス１６２２及びデバイス１６００のコンポーネントと接続される。グラフィックサブシステム１６１４は、少なくとも１つのグラフィック処理ユニット（ＧＰＵ）１６１６及びグラフィックメモリ１６１８を含む。グラフィックメモリ１６１８は、出力画像の各ピクセルのピクセルデータを格納するために使用される表示メモリ（例えばフレームバッファ）を含む。グラフィックメモリ１６１８は、ＧＰＵ１６１６と同一のデバイスに統合されてもよく、ＧＰＵ１６１６と別個のデバイスとして接続されてもよく、及び／またはメモリ１６０４内に実装されてもよい。ピクセルデータは、ＣＰＵ１６０２から直接グラフィックメモリ１６１８に提供することができる。あるいは、ＣＰＵ１６０２は、所望の出力画像を定義するデータ及び／または命令をＧＰＵ１６１６に提供し、ＧＰＵ１６１６は、そこから、１つまたは複数の出力画像のピクセルデータを生成する。所望の出力画像を定義するデータ及び／または命令は、メモリ１６０４及び／またはグラフィックメモリ１６１８に記憶することができる。一実施形態では、ＧＰＵ１６１６は、シーンのジオメトリ、ライティング、陰影、質感、モーション、及び／またはカメラのパラメータを定義する命令及びデータから、出力画像のピクセルデータを生成する３Ｄレンダリング機能を含む。ＧＰＵ１６１６はさらに、シェーダプログラムを実行することができる１つまたは複数のプログラム可能実行ユニットを含み得る。

グラフィックサブシステム１６１４は、グラフィックメモリ１６１８から画像のピクセルデータを定期的に出力して、ディスプレイデバイス１６１０に表示させる、または投影システム（図示せず）により投影させる。ディスプレイデバイス１６１０は、ＣＲＴ、ＬＣＤ、プラズマ、及びＯＬＥＤディスプレイを含む、デバイス１６００からの信号に応答して、視覚情報を表示することが可能な任意のデバイスであってもよい。デバイス１６００は、ディスプレイデバイス１６１０に、例えば、アナログ信号またはデジタル信号を提供することができる。

グラフィックサブシステム１６１４を最適化するための他の実施形態は、画像フレームのオブジェクトをレンダリングする前に、インターリーブされたスクリーン領域に対してジオメトリを事前テストすることによる、アプリケーションのジオメトリのマルチＧＰＵレンダリングを含むことができる。グラフィックサブシステム１６１４は、１つまたは複数の処理デバイスとして構成することができる。

例えば、グラフィックサブシステム１６１４は、一実施形態では、レンダリング中の領域テストによってアプリケーションのジオメトリのマルチＧＰＵレンダリングを実行するように構成され得、複数のグラフィックサブシステムが、単一のゲームのためのグラフィック及び／またはレンダリングパイプラインを実装し得る。すなわち、グラフィックサブシステム１６１４は、アプリケーションを実行するときに、画像、または一連の画像の１つまたは複数の画像のそれぞれをレンダリングするために使用される複数のＧＰＵを含む。

他の実施形態では、グラフィックサブシステム１６１４は、対応するＣＰＵ上で実行している単一のアプリケーションのグラフィック処理を実行するために組み合わされる複数のＧＰＵデバイスを含む。例えば、複数のＧＰＵは、画像のオブジェクトのレンダリングの間に、領域テストにより、アプリケーションのジオメトリのマルチＧＰＵレンダリングを実行できる。他の例では、複数のＧＰＵが、フレームレンダリングの代替形式を実行でき、この場合、連続したフレーム期間で、ＧＰＵ１は第１のフレームをレンダリングし、ＧＰＵ２は第２のフレームをレンダリングするなどして、最後のＧＰＵに到達すると、最初のＧＰＵが次のビデオフレームをレンダリングする（例えば、ＧＰＵが２つしかない場合、ＧＰＵ１は第３のフレームをレンダリングする）。つまり、フレームをレンダリングするときにＧＰＵが循環する。レンダリング操作はオーバーラップする可能性があり、それにおいて、ＧＰＵ１が最初のフレームのレンダリングを終了する前にＧＰＵ２が２番目のフレームのレンダリングを開始できる。別の実施態様では、複数のＧＰＵデバイスに、レンダリング及び／またはグラフィックパイプラインで異なるシェーダ操作を割り当てることができる。マスターＧＰＵがメインのレンダリングと合成を実行している。例えば、３つのＧＰＵを含むグループでは、マスターＧＰＵ１がメインレンダリング（例えば、第１のシェーダ操作）及び、スレーブＧＰＵ２とスレーブＧＰＵ３からの出力の合成を実行でき、スレーブＧＰＵ２は第２のシェーダ（例えば、川などの流体効果）操作を実行でき、スレーブＧＰＵ３は第３のシェーダ（例えば、粒子の煙）操作を実行でき、マスターＧＰＵ１は、ＧＰＵ１、ＧＰＵ２、及びＧＰＵ３のそれぞれからの結果を合成する。このようにして、様々なＧＰＵを割り当てて、様々なシェーダ操作（旗振り、風、煙の発生、炎など）を実行してビデオフレームをレンダリングできる。さらに別の実施形態では、３つのＧＰＵのそれぞれを、ビデオフレームに対応するシーンの異なるオブジェクト及び／または部分に割り当てることができる。上記の実施形態及び実施態様では、これらの操作は、同じフレーム周期で（同時に並行して）、または異なるフレーム周期で（順次並列に）実行することができる。

したがって、本開示は、レンダリング中にジオメトリ解析を実行して、画像フレームのジオメトリレンダリングのためにスクリーン領域をＧＰＵに動的に割り当てることによる、及び／または、レンダリングの前にジオメトリ解析を実行して、画像フレームのジオメトリレンダリングのためにスクリーン領域をＧＰＵに動的に割り当てることによる、及び／または、ジオメトリのピースを再分割し、結果として得られるジオメトリのより小さな部分を複数のＧＰＵに割り当てることによる、アプリケーションのためのジオメトリのマルチＧＰＵレンダリングのために構成された方法及びシステムを説明する。

本明細書で定義される様々な実施形態は、本明細書で開示される様々な特徴を使用する特定の実施態様に組み合わされ得る、または組み立てられ得ることを、理解されたい。従って、提供される例は、可能な例の一部にすぎず、様々な要素を組み合わせることでより多くの実施態様を規定することが可能な様々な実施態様に制限を加えるものではない。ある例では、ある実施態様は、開示されたまたは同等の実施態様の趣旨から逸脱することなく、より少ない要素を含んでもよい。

本開示の実施形態は、ハンドヘルドデバイス、マイクロプロセッサシステム、マイクロプロセッサベースもしくはプログラム可能な消費者向け電気製品、ミニコンピュータ、及びメインフレームコンピュータなどを含む様々なコンピュータシステム構成で実施されてよい。本開示の実施形態はまた、有線ベースネットワークまたは無線ネットワークを介してリンクされる遠隔処理デバイスによりタスクが行われる分散コンピューティング環境においても、実施することができる。

上記の実施形態を念頭に置いて、本開示の実施形態がコンピュータシステムに格納されたデータを含む様々なコンピュータ実装の動作を使用し得ることを理解されたい。これらの動作は、物理量の物理的操作を必要とする動作である。本開示の実施形態の一部を形成する、本明細書で説明される動作のうちのいずれも、有用な機械動作である。開示の実施形態はまた、これら動作を実行するためのデバイスまたは装置に関する。装置は、必要な目的のために特別に構築することができる。または、装置は、コンピュータに記憶されたコンピュータプログラムにより選択的に起動または構成される汎用コンピュータであってもよい。具体的には、本明細書の教示に従って書かれたコンピュータプログラムとともに様々な汎用マシンを使用することができる、あるいは、必要な動作を実行するためにさらに特化した装置を構築するほうがより好都合である場合もある。

本開示はまた、コンピュータ可読媒体上のコンピュータ可読コードとしても具現化することができる。コンピュータ可読媒体は、後でコンピュータシステムにより読み出され得るデータを格納できる任意のデータストレージデバイスである。コンピュータ可読媒体の例は、ハードドライブ、ネットクワーク接続ストレージ（ＮＡＳ）、読み出し専用メモリ、ランダムアクセスメモリ、ＣＤ－ＲＯＭ、ＣＤ－Ｒ、ＣＤ－ＲＷ、磁気テープ、並びに他の光学及び非光学データストレージデバイスを含む。コンピュータ可読媒体には、コンピュータ可読コードが分散方式で記憶され実行されるように、ネットワーク接続されたコンピュータシステムにわたり分散されたコンピュータ可読有形媒体が含まれ得る。

方法動作は特定の順序で説明されたが、オーバーレイ動作の処理が所望の方法で実行される限り、動作間に他の維持管理動作が実行されてもよく、または動作がわずかに異なる時間に起こるように調整されてもよく、またはシステム内に動作を分散することで、処理に関連する様々な間隔で処理動作が起こることを可能にしてもよいことを、理解すべきである。

前述の開示は、理解を明確にするためにある程度詳細に説明されたが、添付の特許請求の範囲内で特定の変更及び修正を実施できることは明らかであろう。したがって、本実施形態は、限定ではなく例示としてみなされるべきであり、本開示の実施形態は、本明細書に提供される詳細に限定されるものではなく、添付の特許請求の範囲内及び均等物内で変更されてよい。

Claims (20)

1. グラフィック処理のための方法であって、
   複数のグラフィック処理ユニット（ＧＰＵ）を使用してアプリケーション用のグラフィックをレンダリングし、
   複数のジオメトリピースを含む画像フレームをレンダリングするために前記複数のＧＰＵを連携して使用し、
   前記画像フレームの前記レンダリング中に、前記複数のジオメトリピースのうちの１つまたは複数を、ジオメトリの複数のより小さな部分に再分割し、ジオメトリの前記複数のより小さな部分のレンダリングに対するレスポンシビリティを前記複数のＧＰＵ間で分割し、
   ジオメトリの前記複数のより小さい部分のそれぞれは、第１の対応するＧＰＵによって処理され、
   再分割されていないジオメトリピースについて、前記ジオメトリピースのレンダリングに対するレスポンシビリティを前記複数のＧＰＵ間で分割し、
   再分割されていない前記複数のジオメトリピースのそれぞれは、第２の対応するＧＰＵによって処理され、
   前記画像フレームのレンダリングのフェーズ中にレンダリングを行うために、最初に第１ＧＰＵに割り当てられた、ジオメトリピース又はジオメトリのより小さな部分を、レンダリングの前記フェーズについて決定された前記複数のＧＰＵのレンダリングタイミング情報に基づいて、第２ＧＰＵに再割り当てする、
   グラフィック処理のための方法。
2. 前記画像フレームのためのレンダリングの前記フェーズは、レンダリングのジオメトリ解析フェーズ、またはレンダリングのＺプレパスフェーズ、またはレンダリングのジオメトリパスフェーズを含む、
   請求項１に記載の方法。
3. さらに、レンダリングの前記ジオメトリ解析フェーズ、またはレンダリングの前記Ｚプレパスフェーズ、またはレンダリングの前記ジオメトリパスフェーズ中に、前記第１ＧＰＵが前記第２ＧＰＵに遅れていると判断し、
   前記第１ＧＰＵに前記第２ＧＰＵよりも少ないジオメトリピースが割り当てられるように、ジオメトリの前記複数のピースをレンダリングするレスポンシビリティを動的に割り当てる、
   請求項２に記載の方法。
4. レンダリングのＺプレパスフェーズ中に、前記複数のジオメトリピースを含む前記画像フレーム用のＺバッファを生成するために前記複数のＧＰＵを連携して使用し、
   レンダリングの前記Ｚプレパスフェーズ中に、前記画像フレームの前記複数のジオメトリピースと、複数のスクリーン領域に対する前記複数のジオメトリピースの関係と、に関する情報を生成し、
   レンダリングのジオメトリパスフェーズ中に前記画像フレームをレンダリングするために、前記情報に基づいて前記複数のＧＰＵに対する前記複数のスクリーン領域の割り当てを行い、
   前記複数のＧＰＵに対する前記複数のスクリーン領域の前記割り当てから決定された、スクリーン領域に対するＧＰＵの割り当てに基づいて、レンダリングの前記ジオメトリパスフェーズ中に前記複数のＧＰＵのそれぞれで前記複数のジオメトリピースをレンダリングし、かつ、
   前記ジオメトリパスフェーズ中にレンダリングするために、最初に前記第１ＧＰＵに割り当てられた前記ジオメトリピースを、前記第２ＧＰＵに再割り当てする、
   請求項１に記載の方法。
5. レンダリングコマンドバッファは、共通レンダリングコマンドバッファとして前記複数のＧＰＵ間で共有され、
   前記共通レンダリングコマンドバッファのフォーマットは、前記複数のＧＰＵのサブセットによってのみコマンドが実行されることを可能にする、
   請求項１に記載の方法。
6. 前記複数のＧＰＵのうちの１つまたは複数が、複数の仮想ＧＰＵとして構成された、より大きなＧＰＵの部分である、
   請求項１に記載の方法。
7. コンピュータシステムであって、
   プロセッサと、
   前記プロセッサに結合され、前記コンピュータシステムにより実行されると、前記コンピュータシステムにグラフィック処理のための方法を実行させる命令を格納しているメモリと、を有し、前記方法は、
   複数のグラフィック処理ユニット（ＧＰＵ）を使用してアプリケーション用のグラフィックをレンダリングし、
   複数のジオメトリピースを含む画像フレームをレンダリングするために前記複数のＧＰＵを連携して使用し、
   前記画像フレームの前記レンダリング中に、前記複数のジオメトリピースのうちの１つまたは複数を、ジオメトリの複数のより小さな部分に再分割し、ジオメトリの前記複数のより小さな部分のレンダリングに対するレスポンシビリティを前記複数のＧＰＵ間で分割し、
   ジオメトリの前記複数のより小さい部分のそれぞれは、第１の対応するＧＰＵによって処理され、
   再分割されていないジオメトリピースについて、前記ジオメトリピースのレンダリングに対するレスポンシビリティを前記複数のＧＰＵ間で分割し、
   これらのジオメトリピースのそれぞれは、第２の対応するＧＰＵによって処理され、
   前記画像フレームのレンダリングのフェーズ中にレンダリングを行うために、最初に第１ＧＰＵに割り当てられた、ジオメトリピース又はジオメトリのより小さな部分を、レンダリングの前記フェーズについて決定された前記複数のＧＰＵのレンダリングタイミング情報に基づいて、第２ＧＰＵに再割り当てする、
   コンピュータシステム。
8. 前記方法では、前記画像フレームのためのレンダリングの前記フェーズは、レンダリングのジオメトリ解析フェーズ、またはレンダリングのＺプレパスフェーズ、またはレンダリングのジオメトリパスフェーズを含む、
   請求項７に記載のコンピュータシステム。
9. さらに、レンダリングの前記ジオメトリ解析フェーズ、またはレンダリングの前記Ｚプレパスフェーズ、またはレンダリングの前記ジオメトリパスフェーズ中に、前記第１ＧＰＵが前記第２ＧＰＵに遅れていると判断し、
   前記第１ＧＰＵに前記第２ＧＰＵよりも少ないジオメトリピースが割り当てられるように、ジオメトリの前記複数のピースをレンダリングするレスポンシビリティを動的に割り当てる、
   請求項８に記載のコンピュータシステム。
10. レンダリングのＺプレパスフェーズ中に、前記複数のジオメトリピースを含む前記画像フレーム用のＺバッファを生成するために前記複数のＧＰＵを連携して使用し、
    レンダリングの前記Ｚプレパスフェーズ中に、前記画像フレームの前記複数のジオメトリピースと、複数のスクリーン領域に対する前記複数のジオメトリピースの関係とに関する情報を生成し、
    レンダリングのジオメトリパスフェーズ中に前記画像フレームをレンダリングするために、前記情報に基づいて前記複数のＧＰＵに対する前記複数のスクリーン領域の割り当てを行い、
    前記複数のＧＰＵに対する前記複数のスクリーン領域の前記割り当てから決定された、スクリーン領域に対するＧＰＵの割り当てに基づいて、レンダリングの前記ジオメトリパスフェーズ中に前記複数のＧＰＵのそれぞれで、前記複数のジオメトリピースをレンダリングし、かつ、
    前記ジオメトリパスフェーズ中にレンダリングするために、最初に前記第１ＧＰＵに割り当てられた前記ジオメトリピースを、前記第２ＧＰＵに再割り当てする、
    請求項７に記載のコンピュータシステム。
11. 前記方法では、レンダリングコマンドバッファは、共通レンダリングコマンドバッファとして前記複数のＧＰＵ間で共有され、前記方法では、前記共通レンダリングコマンドバッファのフォーマットは、前記複数のＧＰＵのサブセットによってのみコマンドが実行されることを可能にする、
    請求項７に記載のコンピュータシステム。
12. 前記方法において、前記複数のＧＰＵのうちの１つまたは複数が、複数の仮想ＧＰＵとして構成された、より大きなＧＰＵの部分である、
    請求項７に記載のコンピュータシステム。
13. グラフィック処理のためのコンピュータプログラムを格納するコンピュータ可読媒体であって、前記コンピュータ可読媒体が、
    複数のグラフィック処理ユニット（ＧＰＵ）を使用してアプリケーション用のグラフィックをレンダリングするためのプログラム命令を有し、
    複数のジオメトリピースを含む画像フレームをレンダリングするために前記複数のＧＰＵを連携して使用するためのプログラム命令を有し、
    前記画像フレームの前記レンダリング中に、前記複数のジオメトリピースのうちの１つまたは複数を、ジオメトリの複数のより小さな部分に再分割し、ジオメトリの前記複数のより小さな部分のレンダリングに対するレスポンシビリティを前記複数のＧＰＵ間で分割するためのプログラム命令を有し、
    ジオメトリの前記複数のより小さい部分のそれぞれは、第１の対応するＧＰＵによって処理され、
    再分割されていないジオメトリピースについて、前記ジオメトリピースのレンダリングに対するレスポンシビリティを前記複数のＧＰＵ間で分割するためのプログラム命令を有し、
    再分割されていない前記複数のジオメトリピースのそれぞれは、第２の対応するＧＰＵによって処理され、
    前記画像フレームのレンダリングのフェーズ中にレンダリングを行うために、最初に第１ＧＰＵに割り当てられた、ジオメトリピース又はジオメトリのより小さな部分を、レンダリングの前記フェーズについて決定された前記複数のＧＰＵのレンダリングタイミング情報に基づいて、第２ＧＰＵに再割り当てする、
    コンピュータ可読媒体。
14. 前記画像フレームのためのレンダリングの前記フェーズは、レンダリングのジオメトリ解析フェーズ、またはレンダリングのＺプレパスフェーズ、またはレンダリングのジオメトリパスフェーズを含む、
    請求項１３に記載のコンピュータ可読媒体。
15. さらに、レンダリングの前記ジオメトリ解析フェーズ、またはレンダリングの前記Ｚプレパスフェーズ、またはレンダリングの前記ジオメトリパスフェーズ中に、前記第１ＧＰＵが前記第２ＧＰＵに遅れていると判断し、
    前記第１ＧＰＵに前記第２ＧＰＵよりも少ないジオメトリピースが割り当てられるように、ジオメトリの前記複数のピースをレンダリングするレスポンシビリティを動的に割り当てる、
    請求項１４に記載のコンピュータ可読媒体。
16. レンダリングのＺプレパスフェーズ中に、前記複数のジオメトリピースを含む前記画像フレーム用のＺバッファを生成するために前記複数のＧＰＵを連携して使用するためのプログラム命令と、
    レンダリングの前記Ｚプレパスフェーズ中に、前記画像フレームの前記複数のジオメトリピースと、複数のスクリーン領域に対する前記複数のジオメトリピースの関係と、に関する情報を生成するためのプログラム命令と、
    レンダリングのジオメトリパスフェーズ中に前記画像フレームをレンダリングするために、前記情報に基づいて前記複数のＧＰＵに対する前記複数のスクリーン領域の割り当てを行うためのプログラム命令と、
    前記複数のＧＰＵに対する前記複数のスクリーン領域の前記割り当てから決定された、スクリーン領域に対するＧＰＵの割り当てに基づいて、レンダリングの前記ジオメトリパスフェーズ中に前記複数のＧＰＵのそれぞれで前記複数のジオメトリピースをレンダリングするためのプログラム命令と、
    前記ジオメトリパスフェーズ中にレンダリングするために、最初に前記第１ＧＰＵに割り当てられた前記ジオメトリピースを、前記第２ＧＰＵに再割り当てするためのプログラム命令と、を有する、
    請求項１３に記載のコンピュータ可読媒体。
17. レンダリングコマンドバッファは、共通レンダリングコマンドバッファとして前記複数のＧＰＵ間で共有され、前記共通レンダリングコマンドバッファのフォーマットは、前記複数のＧＰＵのサブセットによってのみコマンドが実行されることを可能にする、
    請求項１３に記載のコンピュータ可読媒体。
18. 複数のグラフィック処理ユニット（ＧＰＵ）を使用してアプリケーション用のグラフィックをレンダリングし、
    複数のジオメトリピースを含む画像フレームをレンダリングするために前記複数のＧＰＵを連携して使用し、
    前記画像フレームのレンダリング中に、前記複数のジオメトリピースのレンダリングに対するレスポンシビリティを前記複数のＧＰＵ間で分割し、
    前記複数のジオメトリピースのそれぞれは、対応するＧＰＵによって処理され、
    レンダリングのＺプレパスフェーズ中に、前記複数のジオメトリピースのそれぞれ及び複数のスクリーン領域に対するその関係に関する情報を生成し、
    前記情報に基づいて、レンダリングのジオメトリパスフェーズ中に前記複数のスクリーン領域をレンダリングするために前記複数のＧＰＵに割り当て、
    前記レンダリングのジオメトリフェーズ中にレンダリングするために最初に第１ＧＰＵに割り当てられたジオメトリピースを、第２ＧＰＵに再割り当てする、
    グラフィック処理のための方法。
19. 前記再割り当ては、レンダリングの前記ジオメトリフェーズについて決定された前記複数のＧＰＵのレンダリングタイミング情報に基づく、
    請求項１８に記載の方法。
20. 前記ジオメトリピースは、前記複数のＧＰＵに対する前記複数のスクリーン領域の前記割り当てから決定される、ＧＰＵに対するスクリーン領域の割り当てに基づいて、前記第１ＧＰＵに割り当てられる、
    請求項１８に記載の方法。