▶ ソニー・インタラクティブエンタテインメント エルエルシーの特許一覧
特許7376732領域ベースの依存関係によるカーネルの効率的なマルチＧＰＵ実行のためのシステム及び方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-10-30
(45)【発行日】2023-11-08
(54)【発明の名称】領域ベースの依存関係によるカーネルの効率的なマルチＧＰＵ実行のためのシステム及び方法
(51)【国際特許分類】
G06T 15/00 20110101AFI20231031BHJP
【ＦＩ】
G06T15/00 501
【請求項の数】
30
(21)【出願番号】P 2022565586
(86)(22)【出願日】2021-04-28
(65)【公表番号】
(43)【公表日】2023-04-20
(86)【国際出願番号】 US2021029592
(87)【国際公開番号】W WO2021222377
(87)【国際公開日】2021-11-04
【審査請求日】2022-11-21
(31)【優先権主張番号】16/861,049
(32)【優先日】2020-04-28
(33)【優先権主張国・地域又は機関】US
【早期審査対象出願】
(73)【特許権者】
【識別番号】518187455
【氏名又は名称】ソニー・インタラクティブエンタテインメント エルエルシー
(74)【代理人】
【識別番号】100099324
【弁理士】
【氏名又は名称】鈴木 正剛
(72)【発明者】
【氏名】フロリアン エー． ストラウス
(72)【発明者】
【氏名】マーク イーヴァン セルニー
【審査官】村松 貴士
(56)【参考文献】
【文献】特表２０１４－５２３０２１（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１６／０１８０４８６（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｔ １５／００ － １５／８７
(57)【特許請求の範囲】
【請求項1】
グラフィックス処理を行うための方法であって、複数のグラフィックス処理ユニット（ＧＰＵ）を用いて複数のカーネルを実行し、前記複数のカーネルのうち対応するカーネルを実行するレスポンシビリティは、それぞれが前記複数のＧＰＵのうち対応するＧＰＵに割り当られた前記対応するカーネルの１つ以上の部分の間で分割され、
第１カーネルの第１の複数の部分のそれぞれが処理を完了するときに、前記第１カーネルにおいて複数の依存関係データを生成し、
前記第１カーネルの１つ以上の部分からの第１依存関係データを、第２カーネルの部分の実行の前にチェックし、
前記第１カーネルの前記１つ以上の部分からの前記第１依存関係データが満たされない間は、前記第２カーネルの前記部分の前記実行を遅らせ、
前記第１カーネルの前記１つ以上の部分からの前記第１依存関係データは、前記第１カーネルが前記第１カーネルの前記１つ以上の部分の実行を終了したか否かを示し、
前記第１カーネルの前記第１の複数の部分が処理を終了する前に、前記第２カーネルの前記部分の前記実行が開始され、
前記第１カーネルの前記１つ以上の部分に含まれる部分は前記第１カーネルの前記第１の複数の部分よりも少ない、方法。
【請求項2】
前記第１カーネルの部分により生成された依存関係データは、リソースの１つ以上の領域への１つ以上の書き込みの完了を示す、請求項１に記載の方法。
【請求項3】
前記領域は前記リソースの下位集合に対応し、前記リソースの前記下位集合は画像のタイルまたはバッファ範囲を含む、請求項２に記載の方法。
【請求項4】
前記第１カーネルの前記１つ以上の部分からの前記第１依存関係データは、リソースの領域への書き込みの完了を示す、請求項１に記載の方法。
【請求項5】
前記第１カーネルの前記１つ以上の部分からの前記第１依存関係データは部分ごとに記憶されるか、または、前記第１カーネルの前記１つ以上の部分からの前記第１依存関係データは部分ごとの領域ごとに記憶される、請求項４に記載の方法。
【請求項6】
前記第１カーネルの前記第１の複数の部分の各部分は、１つ以上の次元によって規定されるインデックス空間のインデックス範囲に対応し、前記第１カーネルの前記第１の複数の部分の前記各部分のインデックス範囲は、前記インデックス空間全体に広がり得るか、または、前記第１カーネルにより用いられる前記１つ以上の次元のそれぞれの中で前記インデックス空間の下位集合に広がり得る、請求項１に記載の方法。
【請求項7】
前記第１カーネルの前記１つ以上の部分からの前記第１依存関係データは、前記第２カーネルの前記部分の前記実行の前にチェックされ、かつ、前記第２カーネルの前記部分に対応する次元に対する第１インデックス範囲に基づいており、前記第２カーネルの前記部分に対応する前記次元に対する前記第１インデックス範囲、またはオフセットインデックス範囲を規定する前記第１インデックス範囲のオフセット、によって規定される、前記第１カーネルの第１部分により生成された第２依存関係データをチェックするか、
次元に対する第２インデックス範囲によって規定された前記第１カーネルの複数の部分によって生成されて、前記第２インデックス範囲は前記第２カーネルの前記部分に対応する前記次元に対する前記第１インデックス範囲の上位集合にまとめられるものである、第３依存関係データをチェックするか、または、
次元に対する第３インデックス範囲によって規定される前記第１カーネルの前記１つ以上の部分によって生成されて、前記第３インデックス範囲は前記第２カーネルの前記部分に対応する前記次元に対する前記第１インデックス範囲を用いて計算される関数から導出される、第４依存関係データをチェックする、
請求項６に記載の方法。
【請求項8】
前記オフセットインデックス範囲、前記第２カーネルの前記部分に対応する前記次元に対する前記第１インデックス範囲の前記上位集合、または、前記第２カーネルの前記部分に対応する前記次元に対する前記第１インデックス範囲を用いて計算された前記関数から導出された前記次元に対する前記第３インデックス範囲が、前記インデックス空間の外にある場合には、前記第２カーネルの前記部分の前記実行の前にチェックされた前記第１依存関係データを無視するか、
前記第２カーネルの前記部分の前記実行の前にチェックされた前記第１依存関係データを、前記インデックス範囲に対応する前記第１カーネルの第２部分が前記インデックス空間内にあるようにクランプされたインデックス範囲に対応する前記第１カーネルの前記第２部分に対してチェックするか、または、
前記第２カーネルの前記部分の前記実行の前にチェックされた前記第１依存関係データを、前記インデックス空間内に包まれたインデックス範囲に対応する前記第１カーネルの第３部分についてチェックする、請求項７に記載の方法。
【請求項9】
さらに、前記第１カーネルの部分を第１ＧＰＵ上で実行し、前記第１ＧＰＵによる前記第１カーネルの前記部分の実行が完了した場合に、前記第１カーネルの前記部分が生成したデータを第２ＧＰＵのローカルメモリに送る、請求項１に記載の方法。
【請求項10】
さらに、前記第１カーネルの部分を第１ＧＰＵ上で実行し、第２ＧＰＵによる前記第２カーネルの前記部分の前記実行の前に、前記第２ＧＰＵのローカルメモリ内に、前記第１カーネルの前記部分が生成したデータをフェッチする、請求項１に記載の方法。
【請求項11】
直接メモリアクセス（ＤＭＡ）を介して、前記第２カーネルの前記部分を実行する第２ＧＰＵのローカルメモリ内に、第１ＧＰＵ上で実行される前記第１カーネルの部分によって生成されて前記第１ＧＰＵのローカルメモリに書き込まれたデータをフェッチすることをさらに含む、請求項１に記載の方法。
【請求項12】
さらに、前記ＤＭＡの前記完了前に前記第２ＧＰＵで、前記第１ＧＰＵで実行されている前記第１カーネルの前記部分が生成した前記データを、通常の読み取り動作によって前記第１ＧＰＵの前記ローカルメモリから直接アクセスするか、または、前記ＤＭＡの前記完了後に前記第２ＧＰＵで、前記第１ＧＰＵで実行されている前記第１カーネルの前記部分が生成した前記データを、前記第２ＧＰＵの前記ローカルメモリからアクセスする、請求項１１に記載の方法。
【請求項13】
前記第１カーネルの前記１つ以上の部分からの前記第１依存関係データは、前記第１カーネルの部分の実行の完了を示す、請求項１に記載の方法。
【請求項14】
前記第１カーネルの前記第１の複数の部分の各部分を実行するレスポンシビリティは、１つのＧＰＵにのみ割り当てられ、前記第１カーネルの前記第１の複数の部分を複数のＧＰＵに静的に割り当てられる、請求項１に記載の方法。
【請求項15】
前記第１カーネルの前記第１の複数の部分の各部分を実行するレスポンシビリティは、１つのＧＰＵにのみ割り当てられ、前記第１カーネルが実行されるときに、前記第１カーネルの前記第１の複数の部分を複数のＧＰＵに動的に割り当てられる、請求項１に記載の方法。
【請求項16】
前記第１カーネルの前記第１の複数の部分を前記複数のＧＰＵに割り当てでは、それぞれＧＰＵごとに異なる１つ以上の所定の順序を参照する、請求項１５に記載の方法。
【請求項17】
参照する所定の順序は、前記第１カーネルのインデックス空間の次元における空間充填曲線である、請求項１６に記載の方法。
【請求項18】
さらに、第２ＧＰＵにおける前記第２カーネルの所定の順序に基づいて、前記第２ＧＰＵのローカルメモリ内に、第１ＧＰＵ上で実行される前記第１カーネルによって生成されたデータをプリフェッチする、請求項１５に記載の方法。
【請求項19】
さらに、前記複数のＧＰＵは、１つ以上のカーネル呼び出し、または１つ以上のドローコール、または前記１つ以上のカーネル呼び出しと前記１つ以上のドローコールとの組み合わせを収容し得る共通のコマンドバッファを共有する、請求項１に記載の方法。
【請求項20】
グラフィックス処理を行うための方法であって、複数のグラフィックス処理ユニット（ＧＰＵ）を用いて画像をレンダリングし、
前記複数のＧＰＵ上で複数のカーネルを実行し、対応するカーネルを実行するレスポンシビリティは、それぞれが第１の対応するＧＰＵに割り当てられた、前記対応するカーネルの１つ以上の部分の間で分割され、
前記複数のＧＰＵ上で複数のドローコールを実行し、対応するドローコールを実行するレスポンシビリティは、それぞれが第２の対応するＧＰＵに割り当てられた、前記対応するドローコールの１つ以上の部分の間で分割され、第１ドローコールの部分は第１カーネルの１つ以上の部分に依存するか、または、第２カーネルの部分は第２ドローコールの１つ以上の部分に依存し、
前記第１カーネルの前記１つ以上の部分からの依存関係データが、前記第１カーネルの前記１つ以上の部分が実行を終了していないことを示す限り、前記第１ドローコールの前記部分の実行を遅らせ、前記第１カーネルの複数の部分が処理を終了する前に、前記第１ドローコールの前記部分の前記実行が開始され、前記第１カーネルの前記１つ以上の部分に含まれる部分は、前記第１カーネルの前記複数の部分よりも少なく、
前記第２ドローコールの前記１つ以上の部分からの依存関係データが、前記第２ドローコールの前記１つ以上の部分が実行を終了していないことを示す限り、前記第２カーネルの前記部分の実行を遅らせ、前記第２ドローコールの複数の部分が処理を終了する前に、前記第２カーネルの前記部分の前記実行が開始され、前記第２ドローコールの前記１つ以上の部分に含まれる部分は、前記第２ドローコールの前記複数の部分よりも少ない、方法。
【請求項21】
後続のカーネルの部分の実行は、以前のカーネルの部分の実行に依存する、請求項２０に記載の方法。
【請求項22】
前記対応するカーネルの前記１つ以上の部分の各部分は、１つ以上の次元によって規定されるインデックス空間のインデックス範囲に対応し、前記インデックス範囲は、前記インデックス空間の全体に広がり得るか、または、前記対応するカーネルが用いる前記１つ以上の次元のそれぞれにおける前記インデックス空間の下位集合に広がり得る、請求項２０に記載の方法。
【請求項23】
前記第２ドローコールの前記１つ以上の部分からの前記依存関係データを、前記第２カーネルの前記部分の前記実行の前にチェックする、請求項２０に記載の方法。
【請求項24】
前記第１カーネルの前記１つ以上の部分からの前記依存関係データを、前記第１ドローコールの前記部分の前記実行の前にチェックする、請求項２０に記載の方法。
【請求項25】
前記対応するカーネルの前記１つ以上の部分の各部分を実行するレスポンシビリティは、１つのＧＰＵにのみ割り当てられ、前記対応するカーネルの前記１つ以上の部分は、前記複数のＧＰＵに静的に割り当てられる、請求項２０に記載の方法。
【請求項26】
前記対応するカーネルの前記１つ以上の部分の各部分を実行するレスポンシビリティは、１つのＧＰＵにのみ割り当てられ、前記対応するカーネルを実行するときに、前記対応するカーネルの前記１つ以上の部分は、前記複数のＧＰＵに動的に割り当てられる、請求項２０に記載の方法。
【請求項27】
グラフィックス処理を行うための方法であって、複数のグラフィックス処理ユニット（ＧＰＵ）を用いて複数のカーネルを実行し、
対応するカーネルを実行するレスポンシビリティを、前記対応するカーネルの複数の部分の間で分割し、
前記対応するカーネルの前記複数の部分を前記複数のＧＰＵに割り当て、前記対応するカーネルの前記複数の部分の各部分は、対応するＧＰＵに割り当てられ、
第１カーネルの部分からの依存関係データを、第２カーネルの部分の実行の前にチェックし、前記第２カーネルの前記部分は、前記第１カーネルの前記部分の実行から生成されたデータを要求し、
前記第１カーネルの前記部分からの前記依存関係データが、前記第１カーネルの前記部分が実行を終了していないことを示す限り、前記第２カーネルの前記部分の前記実行を遅らせ、
前記第１カーネルの複数の部分が処理を終了する前に、前記第２カーネルの前記部分の前記実行が開始される、方法。
【請求項28】
前記対応するカーネルの前記複数の部分の前記各部分は、１つ以上の次元によって規定されるインデックス空間のインデックス範囲に対応し、前記インデックス範囲は、前記対応するカーネルが用いる各次元において前記インデックス空間全体または前記インデックス空間の下位集合に広がり得る、請求項２７に記載の方法。
【請求項29】
さらに、前記対応するカーネルの前記複数の部分の前記各部分を実行するレスポンシビリティは、１つのＧＰＵにのみ割り当てられ、前記対応するカーネルを実行するときに、前記対応するカーネルの前記複数の部分は前記複数のＧＰＵに動的に割り当てられる、請求項２７に記載の方法。
【請求項30】
前記対応するカーネルの前記複数の部分の前記複数のＧＰＵへの割り当てでは、ＧＰＵごとに異なる１つ以上の所定の順序を参照する、請求項２７に記載の方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示はグラフィックス処理に関し、より具体的には、グラフィックス処理ユニット（ＧＰＵ）上でのカーネル計算に対するものである。
【背景技術】
【0002】
近年、クラウドゲーミングサーバと、ネットワークを通して接続されたクライアントとの間で、ストリーミングフォーマットでオンラインまたはクラウドゲーミングを行うことを可能にするオンラインサービスが次々と登場している。ストリーミングフォーマットはますます人気が出ている。これは、オンデマンドでゲームタイトルが利用できること、より複雑なゲームが実行できること、マルチプレイヤーゲーミングの場合にプレーヤ間でネットワーク接続できること、プレーヤ間で資産を共有できること、プレーヤ及び／または観戦者の間で瞬時の経験を共有できること、友人がビデオゲームをプレイする様子を友人が観戦できること、友人の進行中のゲームプレイに友人が参加できることなどに起因する。
【0003】
クラウドゲーミングサーバは、１つ以上のクライアント及び／またはアプリケーションにリソースを提供するように構成される場合がある。すなわち、クラウドゲーミングサーバは、高スループットが可能なリソースとともに構成される場合がある。たとえば、個々のグラフィックス処理ユニット（ＧＰＵ）が達成できる性能には限界があり、たとえばＧＰＵをどの程度大きくできるかに対する限界から導き出される限界がある。さらに複雑なシーンをレンダリングするために、またはシーンを生成するときにさらに複雑なアルゴリズム（たとえば、材料、照明など）を用いるために、複数のＧＰＵを用いて単一画像をレンダリングすることが望ましい場合がある。
【0004】
しかし、これらのＧＰＵを等しく用いることは実現が難しい。たとえば、作業負荷をＧＰＵの間で均一に分配することは難しく、特定の処理サイクルではあるＧＰＵが他のＧＰＵよりもその作業負荷を速く完了することが起こる。あるＧＰＵが生成したデータを次の処理サイクルにおいて別のＧＰＵが用いる場合があることから、実行速度が速いＧＰＵは、他のＧＰＵがその対応する作業負荷の処理を終了してその結果を他のＧＰＵにコピーするのを待つ（たとえば、アイドル状態になる）。また、共有メモリに高速バスを介して接続されたＧＰＵと比べて、より低速度のバスを介して接続されたＧＰＵは著しく不利である。画像またはバッファが大きくなるにつれて、コピーのサイズは増加し、ボトルネックになる。この非効率性（たとえば、他のＧＰＵからのコピー待ち、同期化中の空き時間、待ち時間あるいはレイテンシーの付加など）の結果、従来の技術を用いた場合、４倍の数のＧＰＵが利用できたとしても、４倍のデータを処理することは難しかった。たとえば、従来、アプリケーションに対する画像を処理する複数のＧＰＵがあったとしても、スクリーンピクセル数及びジオメトリ密度の両方での対応する増加をサポートすることはできなかった（たとえば、４つのＧＰＵによって画像に対して４倍のピクセルを書き込むこと及び／または４倍の頂点またはプリミティブを処理することはできない）。
【0005】
本開示の実施形態は、このような背景の下になされたものである。
【発明の概要】
【0006】
本開示の実施形態は、複数のＧＰＵを協働で用いてデータまたは画像を処理することに関する。
【0007】
本開示の実施形態は、グラフィックス処理を行うための方法を開示する。本方法には、複数のグラフィックス処理ユニット（ＧＰＵ）を用いて複数のカーネルを実行することであって、対応するカーネルを実行するレスポンシビリティ（responsibility）を１つ以上の部分に分割し、各部分を対応するＧＰＵに割り当てることが含まれる。本方法には、第１カーネルの第１の複数の部分のそれぞれが処理を完了したときに、第１カーネルにおいて複数の依存関係データを生成することが含まれる。本方法には、第１カーネルの１つ以上の部分からの依存関係データを、第２カーネルの部分の実行の前にチェックすることが含まれる。本方法には、第１カーネルの対応する依存関係データが満たされない間は、第２カーネルの部分の実行を遅らせることが含まれる。
【0008】
本開示の他の実施形態は、方法を行うための非一時的コンピュータ可読媒体を開示する。コンピュータ可読媒体は、複数のグラフィックス処理ユニット（ＧＰＵ）を用いて複数のカーネルを実行し、対応するカーネルを実行するレスポンシビリティを１つ以上の部分に分割し、各部分を対応するＧＰＵに割り当てるためのプログラム命令を含む。コンピュータ可読媒体は、第１カーネルの第１の複数の部分のそれぞれが処理を完了したときに、第１カーネルにおいて複数の依存関係データを生成するためのプログラム命令を含む。コンピュータ可読媒体は、第１カーネルの１つ以上の部分からの依存関係データを、第２カーネルの部分の実行の前にチェックするためのプログラム命令を含む。コンピュータ可読媒体は、第１カーネルの対応する依存関係データが満たされない間は、第２カーネルの部分の実行を遅らせるためのプログラム命令を含む。
【0009】
本開示のさらに他の実施形態は、コンピュータシステムであって、プロセッサと、プロセッサに結合され、命令が記憶されたメモリであって、命令は、コンピュータシステムによって実行されると、コンピュータシステムに方法を実行させるメモリと、を含むコンピュータシステムを開示する。本方法には、複数のグラフィックス処理ユニット（ＧＰＵ）を用いて複数のカーネルを実行することであって、対応するカーネルを実行するレスポンシビリティを１つ以上の部分に分割し、各部分を対応するＧＰＵに割り当てる、実行することが含まれる。本方法には、第１カーネルの第１の複数の部分のそれぞれが処理を完了したときに、第１カーネルにおいて複数の依存関係データを生成することが含まれる。本方法には、第１カーネルの１つ以上の部分からの依存関係データを、第２カーネルの部分の実行の前にチェックすることが含まれる。本方法には、第１カーネルの対応する依存関係データが満たされない間は、第２カーネルの部分の実行を遅らせることが含まれる。
【0010】
本開示の他の態様は、以下の詳細な説
明と併せて、一例として本開示の原理を例示する添付図面から明らかになる。
明と併せて、一例として本開示の原理を例示する添付図面から明らかになる。
【0011】
本開示は、以下の説明と併せて添付図面を参照することにより最良に理解され得る。
【図面の簡単な説明】
【0012】
【図1】本開示の一実施形態による、複数のＧＰＵを協働で実施して単一画像をレンダリングするように構成された１つ以上のクラウドゲーミングサーバ間でネットワークを介してゲーミングを提供するためのシステムの図である。
【図2】本開示の一実施形態による、複数のＧＰＵが協働してデータまたは画像を処理するマルチＧＰＵアーキテクチャの図である。
【図3】カーネル依存関係、カーネルが処理を完了した後のデータのコピーを示す時間軸を例示する図である。
【図4】カーネル依存関係、カーネルが処理を完了した後のデータのコピーを示す時間軸を例示する図である。
【図5】データ依存関係を用いないときのＧＰＵの非効率性を示す時間軸を例示する図である。
【図6】本開示の一実施形態による、実行のために複数のＧＰＵに割り当てられた複数の部分にパーティション分割されたＮ次元におけるカーネル呼び出しを例示する。
【図7A】本開示の一実施形態による、領域に分割された画像リソースを例示する図である。
【図7B】本開示の一実施形態による、領域に分割されたバッファリソースを例示する図である。
【図8】本開示の一実施形態による、複数のＧＰＵを用いてカーネルを処理することを含むグラフィックス処理を行うための方法におけるステップを例示するフロー図である。
【図9】本開示の一実施形態による、カーネルの部分を複数のＧＰＵの間で均一に分配する固定または静的な割り当て方式を例示する図である。
【図10】本開示の一実施形態による、複数のＧＰＵを用いてカーネルを処理し、カーネル部分ごとの依存関係を追跡して、後続のカーネルの依存部分の早い処理を可能にすることを含むグラフィックス処理を行うための方法におけるステップを例示するフロー図である。
【図11A】本開示の一実施形態による、カーネルの一部分に基づいた依存関係データを例示する図である。
【図11B】本開示の一実施形態による、カーネルの領域及び部分に基づいた依存関係データを例示する図である。
【図12A】本開示の実施形態により、カーネルの一部分による依存関係データのチェックを例示する図であり、依存関係データはその一部分のインデックス範囲の関数である図である。
【図12B】本開示の実施形態により、カーネルの一部分による依存関係データのチェックを例示する図であり、依存関係データはその一部分のインデックス範囲の関数である図である。
【図12C】本開示の実施形態により、カーネルの一部分による依存関係データのチェックを例示する図であり、依存関係データはその一部分のインデックス範囲の関数である図である。
【図12D】本開示の実施形態により、カーネルの一部分による依存関係データのチェックを例示する図であり、依存関係データはその一部分のインデックス範囲の関数である図である。
【図13A】本開示の実施形態により、カーネルの一部分のインデックス範囲の関数が、規定されたインデックス空間の外にあるときに対処するための種々の戦略を例示する図である。
【図13B】本開示の実施形態により、カーネルの一部分のインデックス範囲の関数が、規定されたインデックス空間の外にあるときに対処するための種々の戦略を例示する図である。
【図13C】本開示の実施形態により、カーネルの一部分のインデックス範囲の関数が、規定されたインデックス空間の外にあるときに対処するための種々の戦略を例示する図である。
【図14A】本開示の一実施形態による、実行させるためにＧＰＵにカーネルの部分を割り当てるときに異なるＧＰＵが異なる空間充填曲線に従う動的な割り当て方式を例示する図である。
【図15】本開示の一実施形態による、アプリケーションに対する画像のマルチＧＰＵレンダリングを含むグラフィックス処理を行うための方法におけるステップを例示するフロー図であり、依存関係データはカーネル処理及び／またはドローコール実行に基づき得る図である。
【図16】本開示の種々の実施形態の態様を実行するために用いることができるデバイス例のコンポーネントを例示する図である。
【発明を実施するための形態】
【0013】
以下の詳細な説明には、説明の目的上、多くの特定の詳細が含まれているが、当業者であれば分かるように、以下の詳細に対する多くの変形及び修正も本開示の範囲内である。したがって、以下に説明する本開示の態様は、この説明に続く特許請求の範囲に対する一般性を何ら失うことなく、また特許請求の範囲に限定を課すことなく、述べられている。
【0014】
概して、本開示の実施形態は、カーネルを実行するための方法及びシステムであって、複数のグラフィックス処理ユニット（ＧＰＵ）が協働して画像またはデータを処理する方法及びシステムを開示している。_処理中のカーネルは部分に分割される。画像またはバッファを処理する間、ＧＰＵはカーネルの部分に割り当られ、かつ、これらの部分間の依存関係データを追跡し、その結果、カーネル間のきめの細かい、領域ベースの依存関係データを用いて、ＧＰＵ間のバランスの取れた作業負荷が可能になる。
【0015】
種々の実施形態の前述した全般的な理解に基づき、次に実施形態の詳細例について、種々の図面を参照して説明する。
【0016】
明細書の全体に渡って、「アプリケーション」または「ゲーム」または「ビデオゲーム」または「ゲーミングアプリケーション」に参照する場合、入力コマンドの実行を通して指示される任意のタイプの対話型アプリケーションを表すことが意図されている。例示のみを目的として、対話型アプリケーションには、ゲーミング、文書処理、ビデオ処理、ビデオゲーム処理などに対するアプリケーションが含まれる。これらの導入された用語は相互に交換可能である。
【0017】
明細書の全体に渡って、本開示の種々の実施形態を、４つのＧＰＵを有する典型的なアーキテクチャを用いてアプリケーションに対するカーネルのマルチＧＰＵ処理について説明する。しかし当然のことながら、アプリケーションに対する画像及び／またはデータを生成するときに、任意の数のＧＰＵ（たとえば、２つ以上のＧＰＵ）が協働してもよい。
【0018】
図１は、本開示の一実施形態による、アプリケーションを処理するときにカーネルを実行するためのシステムの略図であり、複数のグラフィックス処理ユニット（ＧＰＵ）が協働して画像またはデータを処理する図である。一実施形態では、システムは、１つ以上のクラウドゲーミングサーバ間でネットワークを介してゲーミングを提供するように構成されている。クラウドゲーミングには、サーバにおいてビデオゲームを実行して、ゲームレンダリングされたビデオフレームを生成することが含まれる。これは次に、クライアントに送られて表示される。
【0019】
図１は、クラウドゲーミングシステムの１つ以上のクラウドゲーミングサーバ間でのカーネルのマルチＧＰＵ実行の実施態様を例示しているが、本開示の他の実施形態では、アプリケーションを処理するときにカーネルを実行し、複数のＧＰＵを有するハイエンドグラフィックスカードを含むパーソナルコンピュータまたはゲーミングコンソールなどのスタンドアロンシステム内で、複数のグラフィックス処理ユニット（ＧＰＵ）が協働して画像またはデータを処理する、実行することが提供される。
【0020】
また当然のことながら、カーネルのマルチＧＰＵ実行を、物理ＧＰＵ、または仮想ＧＰＵ、または両方の組み合わせを種々の実施形態で（たとえば、クラウドゲーミング環境においてまたはスタンドアロンシステム内で）用いて、行ってもよい。たとえば、仮想マシン（たとえば、インスタンス）を、ハードウェア層の１つ以上のコンポーネント（たとえば、複数のＣＰＵ、メモリモジュール、ＧＰＵ、ネットワークインターフェース、通信コンポーネントなど）を用いるホストハードウェア（たとえば、データセンタに配置される）のハイパーバイザを用いて、形成してもよい。これらの物理リソースを、ラック（たとえば、ＣＰＵのラック、ＧＰＵのラック、メモリのラックなど）内に配列してもよい。ラック内の物理リソースにはトップオブラックスイッチを用いてアクセスしてもよく、これにより、インスタンスに対して用いるコンポーネントの組み立て及びアクセスを行うための構造が促進される（たとえば、インスタンスの仮想化コンポーネントを構築するときに）。全般的に、ハイパーバイザは、仮想リソースを用いて構成される複数のインスタンスの複数のゲストオペレーティングシステムを示すことができる。すなわち、オペレーティングシステムはそれぞれ、１つ以上のハードウェアリソース（たとえば、対応するデータセンタに配置される）によってサポートされる対応する組の仮想化リソースを用いて構成してもよい。たとえば、各オペレーティングシステムを、仮想ＣＰＵ、複数の仮想ＧＰＵ、仮想メモリ、仮想化通信コンポーネントなどによってサポートしてもよい。加えて、あるデータセンタから別のデータセンタへ移される得るインスタンスの構成によって待ち時間を減らす。ユーザのゲーミングセッションを節約するときに、ユーザまたはゲームに対して規定されるＧＰＵ稼働率を用いることができる。ＧＰＵ稼働率には、ゲーミングセッションに対するビデオフレームの高速レンダリングを最適化するための本明細書で説明する任意の数の構成を含むことができる。一実施形態では、ゲームまたはユーザに対して規定されるＧＰＵ稼働率を、構成可能な設定としてデータセンタ間で移すことができる。異なるジオロケーションからゲームをプレイするためにユーザが接続する場合には、ＧＰＵ稼働率設定を移せることで、データセンタからデータセンタへゲームプレイを効率的に移行することができる。
【0021】
本開示の一実施形態による、システム１００は、クラウドゲームネットワーク１９０を介してゲーミングを提供する。ゲームは、ゲームをプレイしている対応するユーザのクライアントデバイス１１０（たとえば、シンクライアント）から遠隔で実行されている。システム１００は、シングルプレイヤーモードまたはマルチプレイヤーモードのいずれかでネットワーク１５０を介してクラウドゲームネットワーク１９０を通して１つ以上のゲームをプレイしている１人以上のユーザに対するゲーミングコントロールを提供してもよい。いくつかの実施形態では、クラウドゲームネットワーク１９０は、ホストマシンのハイパーバイザ上で実行される複数の仮想マシン（ＶＭ）を含んでいてもよい。１つ以上の仮想マシンが、ホストのハイパーバイザにとって利用可能なハードウェアリソースを用いるゲームプロセッサモジュールを実行するように構成されている。ネットワーク１５０は１つ以上の通信技術を含んでいてもよい。いくつかの実施形態では、ネットワーク１５０は、高度な無線通信システムを有する第５世代（５Ｇ）ネットワーク技術を含んでいてもよい。
【0022】
いくつかの実施形態では、通信を無線技術を用いて促進してもよい。このような技術には、たとえば、５Ｇ無線通信技術が含まれていてもよい。５Ｇは第５世代のセルラーネットワーク技術である。５Ｇネットワークはデジタルセルラーネットワークであり、ここでは、プロバイダがカバーするサービスエリアが、セルと言われる小さい地理的領域に分割される。音及び画像を表すアナログ信号は、電話機内でデジタル化され、アナログデジタル変換器によって変換されて、ビットのストリームとして送信される。セル内のすべての５Ｇ無線デバイスは、セル内のローカルアンテナアレイ及び低パワー自動化送受信装置（送信部及び受信部）を用いて電波によって通信し、他のセル内で再使用される周波数のプールから送受信装置によって割り当てられた周波数チャネル上で行われる。ローカルアンテナは、高帯域幅光ファイバまたは無線バックホール接続によって電話ネットワーク及びインターネットと接続される。他のセルネットワークの場合と同様に、モバイルデバイスがあるセルから別のセルへ横断すると、新しいセルに自動的に移される。当然のことながら、５Ｇネットワークは単に通信ネットワークのタイプ例であり、本開示の実施形態では、前の世代の無線または有線通信、ならびに５Ｇの後に来る後の世代の有線または無線技術を用いてもよい。
【0023】
図示したように、クラウドゲームネットワーク１９０には、複数のビデオゲームにアクセスするゲームサーバ１６０が含まれる。ゲームサーバ１６０は、クラウド内で利用できる任意のタイプのサーバコンピューティングデバイスであってもよく、１つ以上のホスト上で実行される１つ以上の仮想マシンとして構成してもよい。たとえば、ゲームサーバ１６０は、ユーザに対するゲームのインスタンスをインスタンス化するゲームプロセッサをサポートする仮想マシンを管理してもよい。したがって、複数の仮想マシンに対応付けられるゲームサーバ１６０の複数のゲームプロセッサは、複数のユーザのゲームプレイに対応付けられる１つ以上のゲームの複数のインスタンスを実行するように構成されている。このように、バックエンドサーバサポートは、複数のゲーミングアプリケーションのゲームプレイの媒体（たとえば、ビデオ、オーディオなど）のストリーミングを、複数の対応するユーザに提供する。すなわち、ゲームサーバ１６０は、データ（たとえば、対応するゲームプレイのレンダリング画像及び／またはフレーム）を、対応するクライアントデバイス１１０にネットワーク１５０を通してストリーミングによって戻すように構成されている。このように、コンピュータ的に複雑なゲーミングアプリケーションを、クライアントデバイス１１０が受け取って転送するコントローラ入力に応じて、バックエンドサーバで実行してもよい。各サーバは画像及び／またはフレームをレンダリングすることができ、これらは次に、エンコード（たとえば圧縮）され、対応するクライアントデバイスにストリーミングされて表示される。
【0024】
たとえば、複数のユーザは、ストリーミングメディアを受け取るように構成された対応するクライアントデバイス１１０を用いて、通信ネットワーク１５０を介してクラウドゲームネットワーク１９０にアクセスしてもよい。一実施形態では、クライアントデバイス１１０をシンクライアントとして構成して、計算機能（たとえば、ゲームタイトル処理エンジン１１１を含む）を提供するように構成されたバックエンドサーバ（たとえば、クラウドゲームネットワーク１９０）とのインターフェースを提供してもよい。別の実施形態では、クライアントデバイス１１０を、ビデオゲームの少なくとも何らかのローカル処理を行うためのゲームタイトル処理エンジン及びゲームロジックを用いて構成してもよく、さらに、バックエンドサーバで実行されるビデオゲームが生成するストリーミングコンテンツを受け取るために、またはバックエンドサーバサポートが提供する他のコンテンツに対して用いてもよい。ローカル処理に対しては、ゲームタイトル処理エンジンには、ビデオゲームに対応付けられるビデオゲーム及びサービスを実行するための基本プロセッサベースの機能が含まれる。その場合、ゲームロジックを、ローカルクライアントデバイス１１０上に記憶して、ビデオゲームを実行するために用いてもよい。
【0025】
クライアントデバイス１１０はそれぞれ、クラウドゲームネットワークから異なるゲームへのアクセスをリクエストしていてもよい。たとえば、クラウドゲームネットワーク１９０は、ゲームサーバ１６０のＣＰＵリソース１６３及びＧＰＵリソース２６５を用いて実行されるように、ゲームタイトル処理エンジン１１１上に構築される１つ以上のゲームロジックを実行していてもよい。たとえば、ゲームロジック１１５ａはゲームタイトル処理エンジン１１１と共同して、１つのクライアントに対してゲームサーバ１６０上で実行していてもよく、ゲームロジック１１５ｂはゲームタイトル処理エンジン１１１と共同して、２番目のクライアントに対してゲームサーバ１６０上で実行していてもよく、またゲームロジック１１５ｎはゲームタイトル処理エンジン１１１と共同して、ｎ番目のクライアントに対してゲームサーバ１６０上で実行していてもよい。
【0026】
詳細には、対応するユーザ（図示せず）のクライアントデバイス１１０は、通信ネットワーク１５０（たとえば、インターネット）を介してゲームへのアクセスをリクエストするように、またゲームサーバ１６０が実行するビデオゲームによって生成される表示画像をレンダリングするように、構成されている。エンコード画像は、クライアントデバイス１１０に送出されて、対応するユーザに関連して表示される。たとえば、ユーザは、ゲームサーバ１６０のゲームプロセッサ上で実行されているビデオゲームのインスタンスと、クライアントデバイス１１０を通してやり取りしていてもよい。より詳細には、ビデオゲームのインスタンスはゲームタイトル処理エンジン１１１によって実行される。ビデオゲームを実行する対応するゲームロジック（たとえば、実行可能コード）１１５は、データ記憶する（図示せず）を通して記憶されてアクセス可能であり、ビデオゲームを実行するために用いられる。ゲームタイトル処理エンジン１１１は、複数のゲームロジック（たとえば、ゲーミングアプリケーション）（それぞれ、ユーザによって選択可能である）を用いて、複数のビデオゲームをサポートすることができる。
【0027】
たとえば、クライアントデバイス１１０は、対応するユーザのゲームプレイに関連するゲームタイトル処理エンジン１１１と、たとえば、ゲームプレイを駆動するために用いる入力コマンドを通して、相互に作用するように構成されている。詳細には、クライアントデバイス１１０は、種々のタイプの入力デバイス、たとえば、ゲームコントローラ、タブレットコンピュータ、キーボード、ビデオカメラによって取り込まれたジェスチャ、マウス、タッチパッドなどから入力を受け取ってもよい。クライアントデバイス１１０は、ネットワーク１５０を介してゲームサーバ１６０に接続することができるメモリ及びプロセッサモジュールを少なくとも有する任意のタイプのコンピューティングデバイスとすることができる。バックエンドのゲームタイトル処理エンジン１１１は、レンダリング画像を生成するように構成されている。レンダリング画像は、ネットワーク１５０を介して送出されて、クライアントデバイス１１０に関連する対応するディスプレイにおいて表示される。たとえば、クラウドベースのサービスを通して、ゲームレンダリング画像を、ゲームサーバ１６０のゲーム実行エンジン１１１上で実行されている対応するゲーム（たとえば、ゲームロジック）のインスタンスが送出してもよい。すなわち、クライアントデバイス１１０は、エンコード画像（たとえば、ビデオゲームの実行を通して生成されるゲームレンダリング画像からエンコードされる）を受け取るように、またディスプレイ１１上でレンダリングされる画像を表示するように構成されている。一実施形態では、ディスプレイ１１は、ＨＭＤ（たとえば、ＶＲコンテンツを表示する）を含む。いくつかの実施形態では、レンダリング画像を、スマートフォンまたはタブレットに、無線または有線で、クラウドベースのサービスから直接にまたはクライアントデバイス１１０（たとえば、プレイステーション（登録商標）リモートプレイ）を介して、ストリーミングしてもよい。
【0028】
一実施形態では、ゲームサーバ１６０及び／またはゲームタイトル処理エンジン１１１には、ゲーミングアプリケーションに対応付けられるゲーム及びサービスを実行するための基本プロセッサベースの機能が含まれる。たとえば、ゲームサーバ１６０には、プロセッサベースの機能（たとえば、２Ｄまたは３Ｄレンダリング、物理シミュレーション、スクリプティング、オーディオ、アニメーション、グラフィックス処理、照明、シェーディング、ラスタライゼーション、レイトレーシング、シャドーイング、選抜除去、変換、人工知能など）を行うように構成された中央処理ユニット（ＣＰＵ）リソース１６３及びグラフィックス処理ユニット（ＧＰＵ）リソース２６５が含まれる。加えて、ＣＰＵ及びＧＰＵグループは、ゲーミングアプリケーションに対するサービス（メモリ管理、マルチスレッド管理、サービスの質（ＱｏＳ）、バンド幅テスティング、ソーシャルネットワーキング、ソーシャルフレンズの管理、フレンズのソーシャルネットワークとの通信、通信チャネル、テキスティング、インスタントメッセージ、チャットサポートなどを部分的に含む）を実施してもよい。一実施形態では、１つ以上のアプリケーションは特定のＧＰＵリソースを共有する。一実施形態では、複数のＧＰＵデバイスを結合して、対応するＣＰＵ上で実行されている単一アプリケーションに対するグラフィックス処理を実行してもよい。
【0029】
一実施形態では、クラウドゲームネットワーク１９０は分散ゲームサーバシステム及び／またはアーキテクチャである。詳細には、ゲームロジックを実行する分散ゲームエンジンは、対応するゲームの対応するインスタンスとして構成される。全般的に、分散ゲームエンジンは、ゲームエンジンの機能のそれぞれを取って、それらの機能を多数の処理エンティティが実行するように分配する。個々の機能をさらに、１つ以上の処理エンティティにわたって分配することができる。処理エンティティを異なる構成（たとえば、物理ハードウェア）で、及び／または仮想コンポーネントまたは仮想マシンとして、及び／または仮想コンテナとして構成してもよい。コンテナは、仮想化オペレーティングシステム上で実行されるゲーミングアプリケーションのインスタンスを仮想化するため、仮想マシンとは異なる。処理エンティティは、クラウドゲームネットワーク１９０のサーバ及びその基礎をなすハードウェア（１つ以上のサーバ（計算ノード）上にある）を使用し及び／またはそれらに依拠してもよい。サーバは１つ以上のラック上に配置してもよい。種々の処理エンティティに対するこれらの機能の実行の調整、割当て、及び管理は、分散同期層が行う。このように、これらの機能の実行を分散同期層が制御して、プレーヤによるコントローラ入力に応じたゲーミングアプリケーションに対する媒体（たとえばビデオフレーム、オーディオなど）の生成を可能にする。分散同期層は、これらの機能を、分散させた処理エンティティにわたって効率的に実行して（たとえば、負荷バランシングを通して）、重要なゲームエンジンコンポーネント／機能を分散させて再組立てして、より効率的な処理が行われるようにすることができる。
【0030】
図２は、本開示の一実施形態による、複数のＧＰＵが協働してデータを生成し及び／または対応するアプリケーションの単一画像をレンダリングする、典型的なマルチＧＰＵアーキテクチャ２００の略図である。明示的な説明や図示は行わないものの、本開示の種々の実施形態において、複数のＧＰＵが協働してデータを生成し及び／または画像をレンダリングする多くのアーキテクチャが可能であることが理解されよう。たとえば、画像及び／またはデータの処理が、クラウドゲーミングシステムの１つ以上のクラウドゲーミングサーバ間で実施され得るか、または複数のＧＰＵを有するハイエンドグラフィックスカードを含むパーソナルコンピュータまたはゲーミングコンソールなどのスタンドアロンシステム内で実施され得る場合に、マルチＧＰＵが協働してカーネルを実行し得る。
【0031】
マルチＧＰＵアーキテクチャ２００には、アプリケーションに対する単一画像及び／またはアプリケーションに対する画像列内の各画像のマルチＧＰＵレンダリングを行うように構成されたＣＰＵ１６３及び複数のＧＰＵが含まれている。詳細には、ＣＰＵ１６３及びＧＰＵリソース２６５は、プロセッサベースの機能（たとえば、前述したように、２Ｄまたは３Ｄレンダリング、物理シミュレーション、スクリプティング、オーディオ、アニメーション、グラフィックス処理、照明、シェーディング、ラスタライゼーション、レイトレーシング、シャドーイング、選抜除去、変換、人工知能など）を行うように構成されている。
【0032】
たとえば、マルチＧＰＵアーキテクチャ２００のＧＰＵリソース２６５には４つのＧＰＵが示されているが、アプリケーションに対するデータを生成し及びまたは画像をレンダリングするときには任意の数のＧＰＵを用いてもよい。各ＧＰＵは、対応する専用メモリ（たとえば、ランダムアクセスメモリ（ＲＡＭ））に高速バス２２０を介して接続されている。詳細には、ＧＰＵ－Ａはメモリ２１０Ａ（たとえば、ＲＡＭ）にバス２２０を介して接続され、ＧＰＵ－Ｂはメモリ２１０Ｂ（たとえば、ＲＡＭ）にバス２２０を介して接続され、ＧＰＵ－Ｃはメモリ２１０Ｃ（たとえば、ＲＡＭ）にバス２２０を介して接続され、ＧＰＵ－Ｄはメモリ２１０Ｄ（たとえば、ＲＡＭ）にバス２２０を介して接続されている。
【0033】
さらに、各ＧＰＵは、バス２４０を介して互いに接続されている。バス２４０は、アーキテクチャに応じて、対応するＧＰＵとその対応するメモリとの間の通信に対して用いるバス２２０と速度がほぼ等しいかまたはそれよりも遅い場合がある。たとえば、ＧＰＵ－Ａは、ＧＰＵ－Ｂ、ＧＰＵ－Ｃ、及びＧＰＵ－Ｄのそれぞれと、バス２４０を介して接続されている。また、ＧＰＵ－Ｂは、ＧＰＵ－Ａ、ＧＰＵ－Ｃ、及びＧＰＵ－Ｄのそれぞれと、バス２４０を介して接続されている。加えて、ＧＰＵ－Ｃは、ＧＰＵ－Ａ、ＧＰＵ－Ｂ、及びＧＰＵ－Ｄのそれぞれと、バス２４０を介して接続されている。さらに、ＧＰＵ－Ｄは、ＧＰＵ－Ａ、ＧＰＵ－Ｂ、及びＧＰＵ－Ｃのそれぞれと、バス２４０を介して接続されている。
【0034】
ＣＰＵ１６３は、ＧＰＵのそれぞれと、より低速度のバス２３０を介して接続されている（たとえば、バス２３０は、対応するＧＰＵとその対応するメモリとの間の通信に対して用いるバス２２０よりも遅い）。詳細には、ＣＰＵ１６３は、ＧＰＵ－Ａ、ＧＰＵ－Ｂ、ＧＰＵ－Ｃ、及びＧＰＵ－Ｄのそれぞれと接続されている。
【0035】
いくつかの実施形態では、４つのＧＰＵは別個のＧＰＵであり、それぞれ独自のシリコンダイ上にある。他の実施形態では、４つのＧＰＵは、ダイ上の高速の相互配線あるいはインターコネクト及び他のユニットを利用するためにダイを共有してもよい。さらに他の実施形態では、単一のより強力なＧＰＵとしてかまたは４つのそれほど強力でない「仮想」ＧＰＵ（ＧＰＵ－Ａ、ＧＰＵ－Ｂ、ＧＰＵ－Ｃ、及びＧＰＵ－Ｄ）として用いるように構成することができる１つの物理ＧＰＵ２５０がある。言い換えれば、グラフィックスパイプラインを（図４に示すように）動作させるＧＰＵ－Ａ、ＧＰＵ－Ｂ、ＧＰＵ－Ｃ、及びＧＰＵ－Ｄそれぞれに対する十分な機能があり、チップは、全体として、グラフィックスパイプラインを（図４に示すように）動作させることができ、構成は、２つの構成の間で（たとえば、レンダリングパス間で）フレキシブルに切り替えることができる。
【0036】
図３～５に、より低速度のバスを介して接続された専用メモリを有するＧＰＵが、アイドル状態であるか、または依存関係データを用いないときに１つのＧＰＵからのコピー動作を行うときのレイテンシーあるいはレイテンシーが増加されているという、発生し得るシナリオを例示する。
【0037】
詳細には、図３は、カーネル依存関係とカーネルが処理を完了した後のデータのコピーとを示す時間軸３０５を例示し、カーネル（「計算カーネル」とも言う）は、画像リソースまたはバッファリソースにデータの読み書きを行い得るＧＰＵ上で実行されるプログラムである。たとえば、カーネルＡがデータを生成して書き込み、そしてそれをカーネルＢが読み取って処理用に用いる。カーネルＡ及びＢを、異なるＧＰＵによって別個に実行される作業グループまたは部分に分割し得る。説明のために、カーネルＡを複数の部分に分割し得る。ＧＰＵ Ａに実行用にカーネルＡの１つ以上の部分３２０Ａを割り当てて、ＧＰＵ Ｂに実行用にカーネルＡの１つ以上の部分３２０Ｂを割り当てる。また、カーネルＢを複数の部分に分割し得る。ＧＰＵ Ａに実行用にカーネルＢの１つ以上の部分３４０Ａを割り当てて、ＧＰＵ Ｂに実行用にカーネルＢの１つ以上の部分３４０Ｂを割り当てる。こうして、カーネルＡ及びカーネルＢをそれぞれ、１つ以上のＧＰＵによって実行し得る。
【0038】
図示したように、カーネルＢの１つ以上の部分がカーネルＡの１つ以上の部分からのデータに依存し得る。そのため、コピー動作３３０を行う必要がある。詳細には、カーネルＡの結果に対する高速のアクセスを望む場合、カーネルＢは以前に実行したカーネルＡに依存するため、カーネルＡが書き込んだメモリを他のすべてのＧＰＵ（たとえば、ＧＰＵ Ｂ）にコピーすることを、カーネルＢが１つ以上のＧＰＵ上で実行を開始できる前に行う必要がある。すなわち、カーネルＢを実行する前に、カーネルＡからの作業が完了してコピーされるのを待つ必要がある。たとえば、同期点３１０は、コピー動作３３０が始まる前のカーネルＡのすべての部分の完了を与える。ＧＰＵ Ａ及び／またはＧＰＵ Ｂに割り当てられた部分間にアンバランスな作業負荷があり得るため、ＧＰＵ ＡまたはＧＰＵ Ｂ（またはＧＰＵ ＡもしくはＧＰＵ Ｂのいくつかの実行ユニット）は、コピー動作３３０が始まる前に同期点３１０において他の部分が処理を終了するのを待つ間、アイドル状態にあるかまたは十分に用いられていない場合がある。
【0039】
さらに、同期点３１１において、カーネルＡが書き込んだメモリを他のすべてのＧＰＵにコピーすることが完了するまで、カーネルＢのどの部分も始めることができない。なぜならば、カーネルＡの実行中にどの依存関係が満たされているかが分かっておらず、またカーネルＢが要求した依存関係が満たされているか否かについて不明だからである。図示したように、同期点３１１においてＧＰＵ ＡまたはＧＰＵ Ｂ上のカーネルＡの部分はコピーを終了している場合があり、カーネルＡのすべての部分がその対応するコピー動作３３０を完了するまで、ＧＰＵ ＡまたはＧＰＵ Ｂはアイドル状態にある。
【0040】
図４に、カーネル依存関係と、別個のカーネルの実行中にカーネルが処理を完了した後にデータをコピーする損失を隠すことと、を示す時間軸４０５を例示する。カーネルは、画像リソースまたはバッファリソーストにデータの読み書きを行い得るＧＰＵ上で実行されるプログラムである。たとえば、カーネルＡがデータを生成して書き込み、そしてそれをカーネルＣが読み取って処理用に用いる。また別個のカーネルＢも必要であり得る。カーネルＡ、Ｂ、及びＣをそれぞれ、異なるＧＰＵによって別個に実行される作業グループまたは部分に分割し得る。説明のために、カーネルＡを複数の部分に分割し得る。ＧＰＵ Ａに実行用に１つ以上の部分４２０Ａを割り当てられて、ＧＰＵ Ｂに実行用に１つ以上の部分４２０Ｂを割り当てる。また、カーネルＢを複数の部分に分割し得る。ＧＰＵ Ａに実行用に１つ以上の部分４４０Ａを割り当てて、ＧＰＵ Ｂに実行用に１つ以上の部分４４０Ｂを割り当てる。さらに、カーネルＣを複数の部分に分割し得る。ＧＰＵ Ａに実行用に１つ以上の部分４５０Ａを割り当てて、ＧＰＵ Ｂに実行用に１つ以上の部分４５０Ｂを割り当てる。したがって、カーネルＡ、Ｂ、及びＣをそれぞれ、１つ以上のＧＰＵによって実行し得る。
【0041】
図示したように、カーネルＣの１つ以上の部分が、カーネルＡの１つ以上の部分からのデータに依存し得る。すなわち、たとえば、カーネルＡの結果に対する高帯域幅のアクセスが望まれる場合に、カーネルＡがデータを書き込み、それをカーネルＣが読み取る。そのため、コピー動作４３０を行う必要がある。詳細には、カーネルＣは以前に実行したカーネルＡに依存するため、カーネルＣが１つ以上のＧＰＵ上で実行を開始できる前に、カーネルＡが書き込んだメモリを他のすべてのＧＰＵ（たとえば、ＧＰＵ Ａ及び／またはＧＰＵ Ｂ）にコピーする必要がある。前述したように、いくつかのＧＰＵはカーネルＡのすべての部分が完了するのを待ちながらアイドル状態にある場合があり、及び／またはコピー動作４３０が完了するまでカーネルＣは実行を始められないため、カーネルＡが書き込んだメモリをコピーする損失が存在し得る。
【0042】
コピー動作４３０を他の別個の動作と一緒に行うことによって、コピー動作４３０の損失を隠す方法が存在し得る。たとえば、コピー動作４３０を、カーネルＢが実行している間に行ってもよい。図示したように、同期点４１０は、コピー動作４３０が開始する前のカーネルＡのすべての部分の完了を与える。この場合もやはり、ＧＰＵ Ａ及び／またはＧＰＵ Ｂに割り当てられた部分間にアンバランスな作業負荷があり得るため、ＧＰＵ ＡまたはＧＰＵ Ｂは、コピー動作４３０が始まる前に同期点４１０において他の部分が処理を終了するのを待ちながらアイドル状態にある場合がある。コピー動作４３０の間に、ＧＰＵ Ａ上で実行されるカーネルＢの部分４４０Ａと、ＧＰＵ Ｂ上で実行されるカーネルＢの部分４４０Ｂとは、完了し得る。
【0043】
同期点４１１において、カーネルＡが書き込んだメモリを他のすべてのＧＰＵにコピーすることが完了するまで、カーネルＣのどの部分も始まることができない。なぜならば、カーネルＡの実行中にどの依存関係が満たされているかが分かっておらず、またカーネルＣが要求した依存関係が満たされているか否かについて不明だからである。図示したように、同期点４１１においてＧＰＵ ＡまたはＧＰＵ Ｂ上のカーネルＡの部分はコピーを終了している場合があり、すべての部分がその対応するコピー動作４３０を完了するまでアイドル状態にある。しかし、カーネルＢの実行中にコピーの損失が隠れたとしても、追加の損失がある。詳細には、カーネルＣの実行の開始にレイテンシーが加わる。なぜならば、カーネルＣが実行を始める前に、同期点４１１において完了するまでカーネルＢは実行しなければならないからである。
【0044】
図５に、複数のＧＰＵ間で均一に分割されたカーネルの実行を示す時間軸５０５を例示する。ＧＰＵ間の作業負荷は異なり得る。図示したように、カーネルは、ＧＰＵ Ａ、ＧＰＵ Ｂ、ＧＰＵ Ｃ、及びＧＰＵ Ｄを含む４つのＧＰＵ間で等しく分割されている。たとえば、カーネルは画像をレンダリングするときに照明機能を実行してもよく、カーネルをピクセルの数だけ均一に分割してもよい。各ＧＰＵは、図３及び４で前述したように、実行用にカーネルの一部分を受け取って、時間軸５０５に沿って同期点５１０と５２０との間で他のＧＰＵに結果をコピーする。図示したように、ＧＰＵ Ａは、カーネルの固有の部分を実行するカーネルインスタンス５４０Ａを含み、その後にコピー動作５４５Ａを行って、他のすべてのＧＰＵに結果をコピーする。カーネルインスタンスは、対応する部分における引数に対応付けられる値を含み得る。この部分は、カーネルのインデックス空間におけるインデックス範囲によって規定される。また、ＧＰＵ Ｂは、同じカーネルの固有の部分を実行するカーネルインスタンス５４０Ｂを含み、その後にコピー動作５４５Ｂを行って、他のすべてのＧＰＵに結果をコピーする。ＧＰＵ Ｃは、同じカーネルの固有の部分を実行するカーネルインスタンス５４０Ｃを含み、その後にコピー動作５４５Ｃを行って、他のすべてのＧＰＵに結果をコピーする。最終的に、ＧＰＵ Ｄは、同じカーネルの固有の部分を実行するカーネルインスタンス５４０Ｄを含み、その後にコピー動作５４５Ｄを行って、他のすべてのＧＰＵに結果をコピーする。
【0045】
アプリケーション開発者が複数のＧＰＵの負荷バランシングを行って、すべてのＧＰＵ上で均等な作業負荷を実行しようと試みる場合があり、そうでない場合にはアプリケーションがアンバランスな作業負荷によるパフォーマンスの多少の損失を被る場合がある。しかし、すべてのＧＰＵ間でバランスの取れた作業負荷を予測することは難しく、特に不均質なＧＰＵを用いる場合には難しい。例として、作業負荷（ワークロード）をあらかじめ分割し、あるいは、アプリケーションディベロッパーによって分割することは非効率的であり得る。なぜならば、作業負荷によっては、入力が異なるためにいくつかのＧＰＵ上でより時間がかかる場合があるからである。カーネルが照明機能を実行して、ピクセルの数だけＧＰＵ間で等しく分けられ得る例に従って、各ピクセルまたはピクセルのタイル（たとえば、画像バッファの一部分）に対して行われる作業負荷を予測することは難しい場合がある。なぜならば、異なるタイルに対して入力が異なる場合があるからである（たとえば、異なる数の光、異なるシェーディングモデルなど）。この結果、カーネルのいくつかの部分に対してより長い計算時間がかかる場合がある。カーネルの部分を実行するいくつかのＧＰＵがコピーを完了して終了するのを待つ間、カーネルの部分の実行と結果のコピーを終了した他のＧＰＵは、すべてのコピー動作が完了するのを待ちながらアイドル状態にある。たとえば、ＧＰＵ Ａ、ＧＰＵ Ｂ、及びＧＰＵ Ｄはすべて、ＧＰＵ Ｃがそのコピー動作を終了するのを待ちながらアイドル状態にあり、ＧＰＵ Ｂは、同期点５１０及び５２０の間で最も長くアイドル状態にある。
【0046】
図５に示すように、これらの非効率性（たとえば、すべてのＧＰＵからのコピーを待つ時間、同期化中の空き時間、及びレイテンシーの付加）があるために、より低速度のバスを介して接続され、それぞれが専用メモリを伴うＧＰＵは、共有メモリに高速バスを介して接続されたＧＰＵと比べて著しい不利であり得る。画像リソースまたはバッファリソースが大きくなるにつれて、コピーに対するサイズ及び時間長さが増加することで非効率性が増すことがあり、さらなるボトルネックになる場合がある。これらの非効率性と、本開示の実施形態のデータ依存関係を用いないことの結果として、Ｎ倍の数のＧＰＵが利用でき得たとしても、Ｎ倍のデータを処理することは難しくなる。
【0047】
本開示の実施形態において、ＧＰＵを実施して、計算シェーダー機能、またはグラフィックスシェーダー（たとえば、ピクセルまたは頂点シェーダー）機能を実行してもよい。たとえば、ＧＰＵには、グラフィックスまたは非グラフィックス関連の処理を実行し得るカーネル呼び出しに加えて、画像または複数の画像のピクセルにオブジェクトをレンダリングする（たとえば、色または他のデータを書き込む）レスポンシビリティがある場合がある。１つまたは複数のコマンドバッファが、ＧＰＵが行う動作を規定する。例として、ＧＰＵが行う動作は、オブジェクトをレンダリングするために必要な描画コマンド及び状態情報を介してオブジェクトをレンダリングすることを含み得る。ＧＰＵが行う別の動作は、カーネルを実行するために必要な状態情報と共にカーネル呼び出しコマンドを介したカーネル呼び出しを含み得る。ＧＰＵが行う他の動作は、描画コマンドの完了を待つために用いる同期化コマンド、またはカーネル呼び出し、またはグラフィックスパイプライン、またはいくつかの他の状態を含み得る。さらに他の動作は、ＧＰＵの構成を含んで、カーネル呼び出し用のバッファまたは画像の構成、レンダリングターゲット（たとえば、ＭＲＴ）の場所及びフォーマット、スキャンアウト、深度テスト状態などを含み得る。
【0048】
ＧＰＵがコマンドを実行し、ここで、ＧＰＵはグラフィックス処理を行う（たとえば、オブジェクトをレンダリングする）か、または非グラフィックス機能を行う（たとえば、カーネル呼び出しを行っても）ように実行されてもよい。「コマンド」はＧＰＵが読み取るデータであり、ＧＰＵはコマンドに基づいて動作を実行する。「カーネル呼び出しコマンド」は、カーネル呼び出しを実行するために用いる特定のコマンドである。「描画コマンド」は、オブジェクトをレンダリングするために用いる特定のコマンドである。
【0049】
「コマンドバッファ」には１つ以上のコマンドが収められ、ＧＰＵは、コマンドを対応するコマンドバッファから読み取ることによって実行する。詳細には、ＧＰＵを、対応するコマンドバッファからコマンドを実行するように構成し得る。オブジェクトをレンダリングし及び／またはカーネルを実行するときに行うコマンド及び／または動作を、コマンド及び／または動作が他のコマンド及び／または動作に依存し得るように順序付けあるいはオーダー付けし得る（たとえばあるコマンドバッファ内のコマンドは、そのコマンドバッファ内の他のコマンドが実行できる前に、実行を完了する必要がある）。また、あるＧＰＵが行うコマンド及び／または動作が、別のＧＰＵが行う他のコマンド及び／または動作に依存して、それらが１つ以上のＧＰＵによって順次行われるようであり得る。一実施形態では、各ＧＰＵはその独自のコマンドバッファを有し得る。代替的に、ＧＰＵは同じコマンドバッファまたは同じコマンドバッファセットを用い得る（たとえば、実質的に同じオブジェクトセットを各ＧＰＵがレンダリングしているときに）。
【0050】
また、コマンドバッファを、マルチＧＰＵアーキテクチャにおけるすべてのＧＰＵまたはＧＰＵの下位集合上で実行されるように規定し得る。マルチＧＰＵアーキテクチャにおいて、メモリは、コマンドバッファ内のコマンドを用いることによってＧＰＵ間で明示的にコピーされ必要があり得る。コマンドバッファ内の同期化コマンドによってＧＰＵを同期させるのではなくて、本開示の実施形態では、依存関係データを用いることによって同期化コマンドの使用頻度を最小限にする。これについては、さらに説明する。また、本開示の実施形態は、複数のＧＰＵ間での作業負荷の静的及び／または動的な負荷バランシングを行うことができる。
【0051】
複数のＧＰＵが協働して画像をレンダリングするかまたはカーネルを実行する多くのアーキテクチャが可能である。たとえば、マルチＧＰＵアーキテクチャを、クラウドゲーミングシステムの１つ以上のクラウドゲーミングサーバ間で実施し得るか、またはスタンドアロンシステム（たとえば、複数のＧＰＵを有するハイエンドグラフィックスカードを含むパーソナルコンピュータまたはゲーミングコンソール）内で実施し得る。一実施形態では、マルチＧＰＵアーキテクチャの各ＧＰＵは、高速バスを介して共有メモリにアクセスでき得る。別のマルチＧＰＵアーキテクチャにおいて、各ＧＰＵは、高速バスを介してアクセスされるローカルメモリを有し得て、他のＧＰＵのメモリへのアクセスは低速バスを介して行い得る。これは、別の実施形態の図２に示したアーキテクチャにおいて前述したとおりである。
【0052】
図６に、本開示の一実施形態による、Ｎ次元におけるカーネル呼び出し６００を例示する。詳細には、「インデックス空間」はカーネル呼び出し６００のために用いるＮ次元空間である。カーネル関数が、インデックス空間内の各ポイントまたはインデックスに対して実行される。単に説明の目的上、カーネル呼び出し６００を、９ｘ８インデックスを含む２次元空間（ｘ及びｙ次元）によって表す場合がある。
【0053】
カーネル呼び出し６００の部分を実行用に複数のＧＰＵに割り当てる。以前に紹介したように、カーネル呼び出し６００が実行するカーネルまたは計算カーネルは、画像またはバッファを読み取るかまたは書き込むＧＰＵ上で実行されるプログラムである。カーネルは、引数及び／または使用する引数に対応付けられる値を含み得る。図示したカーネル呼び出し６００は、対応するＮ次元のインデックス範囲に基づいて部分に分割し得る。各部分は、カーネルが用いる各次元におけるインデックス空間全体またはその下位集合であり得る。すなわち、「インデックス範囲」は、Ｎ次元のインデックス空間の一部分を規定する。１つ以上のインデックス範囲を用いて、カーネル呼び出しを部分に分割することができる。このように、「部分」はカーネルまたはカーネル呼び出し６００の一部を規定する。各部分は、Ｎ次元のインデックス空間におけるインデックスまたはインデックス範囲であり得る。典型例として、カーネル呼び出し６００を２つの次元に沿って６つの部分に分割する。カーネル呼び出し６００の各部分には、カーネル関数を評価する１２のインデックスが含まれる。たとえば、部分６１０は、インデックス（６，０）、（７，０）、（８，０）、（６，１）、（７，１）、（８，１）、（６，２）、（７，２）、（８，２）、（６，３）、（７，３）、及び（８，３）を含む。カーネル呼び出し６００によって実行されるカーネルの１つ以上の部分は、いくつかの依存関係データに対応付けられ得る。
【0054】
カーネル呼び出しによって実行されるカーネルの一部分を、メモリ資源であり得る「リソース」の領域に読み書きし得る。詳細には、リソースは、カーネルが用いる入力及び出力データを含み得る。たとえば、リソースはバッファリソースまたは画像リソースであり得て、また多次元においてまたはキューブマップとして構成し得る。いくつかの実施形態では、リソースは１、もしくは２、もしくは３次元によって規定し得るか、またはキューブマップによって規定し得る。
【0055】
「領域」はリソースの一部であり、カーネルの一部分に対応付けられる。たとえば、領域は、対応するカーネル呼び出しによって実行される２Ｄカーネルの一部分に対応する画像の面積を規定し得る。一実施形態では、領域がリソースの下位集合に対応し、カーネルが用いる各次元を含む（たとえば、画像リソースのタイルまたはバッファ内の範囲）。たとえば、「タイル」は、画像の面積を規定するあるタイプの領域（たとえば、画像リソースの）であり得る。カーネルの対応する部分のインデックス範囲を用いて、リソースのどの領域を処理するかを決定し得る。
【0056】
説明の目的上、図７Ａに、２４の領域に分割される画像リソース７１０を例示する。さらに、画像リソース７１０内の領域はそれぞれ、６４の要素を有する。たとえば、領域（２，２）の引き伸ばした画像は８ｘ８または６４の要素を含んでいる。また説明の目的上、図７Ｂに、４つの領域に分割されるバッファリソース７２０を例示する。さらに、バッファリソース７２０内の領域はそれぞれ、８つの要素を有する。たとえば、領域２の引き伸ばした画像は８つの要素を含む。
【0057】
図１～７で前述したマルチＧＰＵアーキテクチャ及びそれらの実施態様の詳細な説明を用いて、図８のフロー図８００に、本開示の一実施形態による、複数のＧＰＵを用いてカーネルを処理することを含むグラフィックス処理を行うための方法を例示する。ここでは、複数のＧＰＵが協働して画像またはデータを処理する。前述したように、種々のアーキテクチャは、複数のＧＰＵが協働して、画像またはデータを処理することを含み得る（たとえば、クラウドゲーミングシステムの１つ以上のクラウドゲーミングサーバ内、またはスタンドアロンシステム内、たとえば、複数のＧＰＵを有するハイエンドグラフィックスカードを含むパーソナルコンピュータまたはゲーミングコンソール内などで）。
【0058】
８１０において、本方法は、複数のＧＰＵを用いて複数のカーネルを実行することを含む。各カーネルは、画像またはバッファリソースに読み書きを行い得るマルチＧＰＵアーキテクチャ上で実行されるプログラムを含む。加えて、カーネル呼び出しを用いて、対応するカーネルを実行する。カーネルは、画像またはバッファリソースにデータの読み書きを行い得る１つ以上のＧＰＵ上で実行されるプログラムである。カーネル呼び出しはインデックス空間によって規定され得る。各インデックスは、カーネルの対応する部分を実行するために用いる引数及び／または引数に対応付けられる値を含み得る。部分は、インデックス空間内のインデックス範囲によって規定される。
【0059】
８２０において、本方法は、カーネルを実行するレスポンシビリティを複数の部分に分割することを含む。その他のレスポンシビリティを有してカーネルを実行するためには用いられないいくつかのＧＰＵも存在し得る。
【0060】
８３０において、本方法は、複数のＧＰＵに複数の部分を割り当てることを含む。各部分を対応するＧＰＵに割り当てる。詳細には、カーネル呼び出しを部分に分割する。部分は、対応するＧＰＵに割り当てられた後に、実行される。ＧＰＵは同時に実行される。各ＧＰＵは、コマンドバッファを共有し得るか、または種々のコマンドバッファを有し得る（たとえば、各ＧＰＵは１つ以上の専用のコマンドバッファを有する）。コマンドバッファは、カーネル呼び出しコマンド、ならびに他のコマンド（たとえば、ドローコールコマンドなど）を含み得る。
【0061】
図９に、本開示の一実施形態による、カーネル９１０の部分を実行用に複数のＧＰＵにわたって均一に分配する固定または静的な割り当て方式を例示する。詳細には、対応するカーネル呼び出しによって実行されるカーネル９１０の部分は、すべてのＧＰＵ上で実行するように均一に分割される。図示したように、カーネル９１０の２次元のインデックス空間は２４のインデックスを含み得る。カーネル９１０の均一な分布によって、実行用に４つのＧＰＵ（たとえばＧＰＵ Ａ、ＧＰＵ Ｂ、ＧＰＵ Ｃ、及びＧＰＵ Ｄ）のそれぞれに、等量のインデックスが分配されて、６つのインデックスが各ＧＰＵに割り当てられ得る。たとえば、固定割り当て方式では、ＧＰＵ Ａには、６つのインデックス（０，０）、（１，０）、（２，０）、（０，１）、（１，１）、及び（２，１）が割り当てられ得る。また、ＧＰＵ Ｂには、６つのインデックス（３，０）、（４，０）、（５，０）、（３，１）、（４，１）、及び（５，１）が割り当てられ得る。さらに、ＧＰＵ Ｃには、６つのインデックス（０，２）、（１，２）、（２，２）、（０，３）、（１，３）、及び（２，３）が割り当てられ得る。またＧＰＵ Ｄには、６つのインデックス（３，２）、（４，２）、（５，２）、（３，３）、（４，３）、及び（５，３）が割り当てられ得る。割り当て方式は固定され、各部分の実行には等しい時間がかからない場合があるため、これは結果的に、ＧＰＵ間でのアンバランスな作業負荷になり得る。本開示の他の実施形態では、依存関係データを用いて動的な割り当て方式を実施し得る。これについては、図１０及び１１Ａ～１１Ｂに関連して以下でさらに説明する。
【0062】
図１～９で前述したマルチＧＰＵアーキテクチャ及びそれらの実施態様の詳細な説明を用いて、図１０のフロー図１０００に、本開示の一実施形態による、グラフィックス処理を行うための方法を例示する。この方法では、複数のＧＰＵを用いてカーネルを処理し、カーネル部分ごとのまたは部分ごとの領域ごとの依存関係を追跡して、後続のカーネルの依存部分の早い処理を可能にしており、複数のＧＰＵが協働して画像またはデータを処理する。
【0063】
前述したように、種々のアーキテクチャは、複数のＧＰＵが協働して画像またはデータを処理することを含み得る（たとえば、クラウドゲーミングシステムの１つ以上のクラウドゲーミングサーバ内、またはスタンドアロンシステム内、たとえば複数のＧＰＵを有するハイエンドグラフィックスカードを含むパーソナルコンピュータまたはゲーミングコンソール内などで）。ＧＰＵは同時に実行される。実施形態では、複数のＧＰＵはコマンドバッファを共有し得るか、または各ＧＰＵは１つ以上の専用のコマンドバッファを有し得る。コマンドバッファは、カーネル呼び出しコマンド、ならびに他のコマンド、たとえば、ドローコールコマンドを含むことができる。
【0064】
１０１０において、本方法は、複数のグラフィックス処理ユニット（ＧＰＵ）を用いて複数のカーネルを実行することを含む。前述したように、各カーネルは、画像またはバッファリソースからデータを読み取るかまたはデータを書き込み得るマルチＧＰＵアーキテクチャ上で実行されるプログラムを含む。加えて、カーネル呼び出しを用いて対応するカーネルを実行する。カーネル呼び出しはインデックス空間によって規定され得る。各インデックスは、カーネルの対応する部分を実行するために用いる引数及び／または引数に対応付けられる値を含み得る。その部分は、インデックス空間内の１つ以上のインデックス範囲によって規定され得る。
【0065】
また、対応するカーネルを実行するレスポンシビリティを１つ以上の部分に分割する。部分はそれぞれ、対応するＧＰＵに割り当てられる。すなわち、処理されているカーネル呼び出しを部分に分けるかまたは分割する。各部分は対応するＧＰＵに実行用に割り当てられる。前述したように、ＧＰＵは、１つ以上のカーネルの実行を通して、協働して画像またはデータを処理する。また、カーネルが読み取るリソース（たとえばメモリ）を、１つ以上の領域に分割し得る。一部分を１つ以上のリソースの１つ以上の領域から読み取り及び／または書き込み得る。
【0066】
１０２０において、本方法は、第１カーネルの第１の複数の部分のそれぞれが処理を完了したときに、第１カーネルにおいて複数の依存関係データを生成することを含む。すなわち、カーネルの対応する部分が処理を完了したら依存関係データを生成する。カーネル部分が実行を終了する前に（すなわち、カーネル部分のすべての命令が実行を終了する前に）、カーネル部分は依存関係データを書き込み得る。依存関係データは、カーネルの各部分によって生成され得る情報である。たとえば、情報は、カーネルの対応する部分の処理が完了したことを示し得る。別の例では、情報は、リソースの領域がカーネルの対応する部分によって書き込まれたことを示し得る。詳細には、カーネルの一部分がリソースの領域への書き込みを終了した後で、その一部分は、その一部分による領域への書き込みが完了したこと及び／またはどのＧＰＵがその領域に書き込んだかを含む依存関係データを生成し得る。このように、画像またはバッファリソースを処理する間に、ＧＰＵにはカーネルの部分が割り当てられ、依存関係データがこれらの部分の間で追跡され得る。その結果、ＧＰＵ間でのバランスされた作業負荷が可能になる。加えて、きめの細かい、領域ベースの依存関係データを生成して、カーネル間で用い得る。
【0067】
１０３０において、本方法は、第１カーネルの１つ以上の部分から生成された依存関係データを、第２カーネルの一部分の実行の前にチェックすることを含む。詳細には、第２カーネルの一部分が読み取る必要がある１つ以上のリソースのすべての領域を、第１カーネルが完全に書き込んだことを確実にするために、第２カーネルの一部分を後に実行することが、依存関係データを待つ。たとえば、第１カーネルの一部分が生成した依存関係データが、リソースの１つ以上の領域への１つ以上の書き込みの完了、または第１カーネルの一部分の実行の完了を示す。
【0068】
一実施形態では、ＧＰＵが領域に書き込むと（たとえば、第１カーネルの一部分を実行したら）、書き込まれたデータを他のＧＰＵに送る。本開示の実施形態では、第２カーネルの一部分が要求するすべての領域が、第１カーネルの以前の実行（たとえば、第１カーネルの別の部分）によって書き込まれている場合、第２カーネルの一部分の実行は、第１カーネルの他の部分がそのコピー動作を完了することを待つことなく、及びコピーのために同期点を用いることなく、始まり得る。
【0069】
別の実施形態では、ＧＰＵは、実行すべきカーネルの部分が必要とするリソースの領域をプリフェッチし得る。ＧＰＵ情報（すなわち、どのＧＰＵが依存関係データ内の領域に書き込んだか）を用いて、どのＧＰＵからデータを読み取るかを決定し得る。場合によっては、領域データはリクエスト元のＧＰＵのローカルメモリ内に良好に存在し得る。
【0070】
１０４０において、本方法は、第１カーネルの対応する依存関係データが満たされない間は、第２カーネルの一部分の実行を遅らせることを含む。すなわち、第２カーネルの一部分は、依存関係データを用いてチェックして、それが必要とするすべての領域が書き込まれていることを確実にし、その後に第２カーネルの一部分は処理を始め得る。すなわち、依存関係データはカーネルの一部分が必要な領域にアクセスできるか否かを示す。詳細には、依存関係データを用いて、後のカーネル呼び出し、またはカーネルの一部分の実行（たとえば、第２カーネル）を同期させ得る。
【0071】
図１１Ａに、本開示の一実施形態による、カーネルの一部分に基づいた依存関係データの生成を例示する。詳細には、カーネルＡ及びカーネルＢはそれぞれ、３つの対応する部分－部分０、部分１、及び部分２に分割されている。リソース０及びリソース１はそれぞれ、３つの対応する領域－領域０、領域１、及び領域２に分割されている。
【0072】
詳細には、カーネルの一部分は、その処理が完了するかまたはリソースの領域への書き込みが完了したら、依存関係データを生成し得る。たとえば、カーネルＡの部分０の完了後またはリソースＡ及びリソースＢの領域０へのカーネルＡの部分０の書き込みの完了時にのみ、依存関係データが書き込まれるように、カーネルＡの部分０は部分ベースの依存関係データを生成し得る。詳細には、カーネルＡの部分０は、経路１１１０に沿ってリソース０の領域０に書き込み、また経路１１１５に沿ってリソース１の領域０に書き込む。その処理または領域への書き込みが完了したら、カーネルＡの部分０は、経路１１２０が示すように、依存関係データＤＤ０も書き込む。一実施形態では、依存関係データ（たとえばＤＤＯ、またはＤＤ１、またはＤＤ２）は任意のアレイ内に記憶することができる。たとえば、依存関係データをインデックス範囲内に記憶し得る。各次元をある量によってシフトまたは除算して、結果として生じる値をアレイ内へのインデックスとして用いる。
【0073】
カーネルＢの部分０は、依存関係データＤＤ０が示すように、リソース０及びリソース１の両方からのデータに依存する。詳細には、カーネルＢの部分０は、依存関係データＤＤ０を待ち、そしてＤＤ０が生成された後に、リソース０の領域０を読み取ること、及びリソース１の領域０を読み取ることができる。すなわち、カーネルＢの部分０は、依存関係データＤＤＯのステータスをチェックすることができ、ＤＤ０に、それが生成されて記憶されたときにアクセスすることができる（これを、経路１１２５によって示す）。カーネルＢの部分０は、依存関係データを介してリソースの必要な領域のすべてにアクセスできることを判定できるため、その部分は、カーネルＡの部分がその処理及びコピーを完了することを待つことなく、及び同期点を（たとえば、コピーのために）用いることなく、実行を始めることができる。
【0074】
図１１Ｂに、本開示の一実施形態による、リソースの領域及びカーネルの部分に基づいた依存関係データを例示する。詳細には、カーネルＡ及びカーネルＢはそれぞれ、３つの対応する部分－部分０、部分１、及び部分２に分割されている。リソース０及びリソース１はそれぞれ、３つの対応する領域－領域０、領域１、及び領域２に分割されている。
【0075】
依存関係データは、部分ごと及びリソースの領域ごとに生成される。詳細には、リソース（たとえば、リソースの領域）へのすべての書き込みが完了したら、カーネルの一部分は依存関係データを生成し得る。たとえば、カーネルＡの部分０は、経路１１３０に沿ってリソース０の領域０に書き込む。リソース０の領域０へのすべての書き込みが完了したら、カーネルＡの部分０は、依存関係データＤＤ０を生成して、経路１１３５に沿って依存関係データ記憶する０（たとえば、アレイ）内に依存関係データＤＤ０を記憶し得る。加えて、カーネルＡの部分０は、経路１１４０に沿ってリソース１の領域０に書き込む。リソース１の領域０へのすべての書き込みが完了したら、カーネルＡの部分０は、依存関係データＤＤ０を生成して、経路１１４５に沿って依存関係データ記憶する１（たとえば、アレイ）内に依存関係データＤＤＯを記憶し得る。
【0076】
カーネルＢの部分０は、リソース０及びリソース１の両方からのデータに依存している。図１１Ｂで生成した依存関係データは、依存関係データが部分ごと及びリソースの領域ごとに生成されるため、図１１Ａで生成した依存関係データよりもきめが細かい場合がある。詳細には、カーネルＢの部分０は、２組の依存関係データ（依存関係データ記憶する０の依存関係データＤＤ０と依存関係データ記憶する１の依存関係データＤＤ０とを含む）を待つ。
【0077】
詳細には、カーネルＢの部分０は、依存関係データ記憶する０の依存関係データＤＤ０を待ち、そしてＤＤ０が生成された後に、経路１１５０に沿ってリソース０の領域０を読み取ることができる。カーネルＢの部分０は、データ記憶する０の依存関係データＤＤ０のステータスをチェックすることができ、その依存関係データＤＤ０に、それが生成されて記憶されたときにアクセスすることができる（これを、経路１１５５によって示す）。また、カーネルＢの部分０は、依存関係データ記憶する１の依存関係データＤＤ０を待ち、そしてＤＤ０が生成された後に、経路１１６０に沿ってリソース１の領域０を読み取ることができる。カーネルＢの部分０は、データ記憶する１の依存関係データＤＤ０のステータスをチェックすることができ、アクセスするその依存関係データＤＤ０に、それが生成されて記憶されたときにアクセスすることができる（これを、経路１１６５によって示す）。
【0078】
なぜならば、カーネルＢの部分０は、依存関係データ（依存関係データ記憶する０のＤＤ０と依存関係データ記憶する１のＤＤ０）を介してリソースの必要な領域のすべてにアクセスできることを判定できるため、その部分は、カーネルＡの部分がその処理及びコピーを完了することを待つことなく、及び同期点を（たとえば、コピーのために）用いることなく、実行を始めることができる。
【0079】
別の実施形態では、カーネルの一部分が、対応する領域への書き込みを終了したら、対応するリソースの領域データをすべてのＧＰＵにプッシュし得る（すなわち、すべてのＧＰＵのローカルメモリに送り得る）。その場合、その領域データを用いる後続のカーネルは、そのローカルメモリへのデータの到着を待ち得る。詳細には、第１ＧＰＵ上で実行される第１カーネルの一部分が完了したら、第１ＧＰＵにおいて第１カーネルによって生成されたデータを第２ＧＰＵのローカルメモリに送る。
【0080】
前述したように、ＧＰＵは、実行すべきカーネルの部分が必要とするリソースの領域をプリフェッチし得る。すなわち、領域データはデータが必要となる前にフェッチされ得る。詳細には、第１ＧＰＵ上で実行される第１カーネルの一部分が、リソースの領域への書き込み及び対応する依存関係データの生成を終了したら、この依存関係データを待っている場合がある第２ＧＰＵ上で実行される第２カーネルの一部分が、次にその領域を読み取り得る。第２ＧＰＵ（第２カーネルの一部分を実行する）は、どのＧＰＵからメモリを読み取るかを分かっている。なぜならば、その情報は依存関係データの一部であり得るからである。いくつかの実施形態では、効率的なプリフェッチは、後続部分を実行する既知の順序あるいはオーダーを用いて、それらの部分が要求するリソースのどの領域をコピーすべきかを決定する。
【0081】
一実施形態では、第２ＧＰＵは、第１ＧＰＵのローカルメモリから直接領域データを、たとえば図２に示したより低速度のバスを介して読み取り得る。別の実施形態では、第２ＧＰＵは、領域データを第１ＧＰＵのローカルメモリから第２ＧＰＵのローカルメモリ内に、第２カーネルの一部分の実行の前にコピーし得る。この場合、第２カーネルの一部分は次に、そのローカルメモリから領域データを読み取ることができる。
【0082】
さらなる他の実施形態では、第２ＧＰＵは、上記で概略した読み取り方法及びコピー方法の両方を用いて、第１ＧＰＵのローカルメモリから直接領域データを読み取ること、またその領域データを対応するローカルメモリから第２ＧＰＵのローカルメモリ内にコピーすることを含む。詳細には、第２カーネルの一部分の実行の開始において、第２ＧＰＵは、領域データを第１ＧＰＵのローカルメモリから第２ＧＰＵのローカルメモリへコピーすることを始める。たとえば、第１ＧＰＵによって生成されて第１ＧＰＵのローカルメモリに書き込まれたデータに、第２ＧＰＵが、ダイレクトメモリアクセス（Direct Memory Access:ＤＭＡ）が完了する前にアクセスする。アクセスは、通常の読み取り動作によって第１ＧＰＵのローカルメモリから直接行われる。コピーが進んでいる間、第２ＧＰＵは第１ＧＰＵのローカルメモリから直接領域データを読み取る。すなわち、第２ＧＰＵは、第２カーネルのその一部分の早い処理を、第１ＧＰＵのローカルメモリからの直接の読み取りを行うことによって始め得る。たとえば、第１ＧＰＵ上で実行される第１カーネルによって生成されて第１ＧＰＵのローカルメモリに書き込まれたデータを、ＤＭＡを介して、第２カーネルを実行する第２ＧＰＵのローカルメモリ内にフェッチする。コピーが完了する前に、第２ＧＰＵは、第１ＧＰＵから直接データを読み取る。コピーが完了した後、第２ＧＰＵは次に、第２ＧＰＵのローカルメモリから直接領域データを読み取る。たとえば、第１ＧＰＵによって生成されて第１ＧＰＵのローカルメモリに書き込まれたデータに、第２ＧＰＵが、第２ＧＰＵのローカルメモリからのＤＭＡが完了した後にアクセスする。このように、第２カーネルの一部分を実行するために必要な領域のみを読み取り、その結果、マルチＧＰＵアーキテクチャにわたるバンド幅が低減される。
【0083】
別の実施形態では、第２カーネルの部分の実行順序が分かっている場合、第２ＧＰＵはこの順序を用いて、第２カーネルのどの部分が次に実行される可能性があるかを予測することができる。このように、第２ＧＰＵは、第２カーネルの一部分が実行前に入力として用いる１つ以上のリソースの対応する領域をプリフェッチすることができる。すなわち、第２ＧＰＵにおける第２カーネルの所定のまたは予測される順序に基づいて、第１ＧＰＵ上で実行される第１カーネルによって生成されたデータを第２ＧＰＵのローカルメモリ内にプリフェッチし得る。これは、それらの領域に対する依存関係データが生成されてそれらの領域が書き込まれたことを示していることを、前提としている。カーネル部分を実行するＧＰＵのローカルメモリ内に領域データがすでに存在する場合、この順序をもちいてローカルメモリからより速いローカルキャッシュメモリ内にプリフェッチすることができ、さらにバンド幅が増加し及び／またはレイテンシーが減る。
【0084】
実施形態では、カーネルの一部分が、対応する依存関係データをチェックするとき、その一部分は、それ自体に対応付けられるインデックス範囲（たとえば、カーネル呼び出しに対応付けられる対応するインデックス空間において）及び依存関係データを生成したカーネルの一部分に対応付けられるインデックス範囲を参照する種々の戦略を用い得る。たとえば、図１２Ａ～１２Ｄに、本開示の実施形態により、カーネルの一部分による依存関係データのチェックを典型的に例示する。依存関係データは、その一部分のインデックス範囲の何らかの関数である。当然のことながら、依存関係データのチェックのために任意の関数を用いてもよい。
【0085】
明瞭及び簡潔にするために、図１２Ａ～１２Ｄのそれぞれは、カーネルの各部分が単位サイズのインデックス範囲を有することを示している。また、図１２Ａ～１２Ｄのそれぞれにおいて、カーネルＡ（図示せず）がリソースＡの領域に書き込んで、関連する依存関係データを生成して記憶する。カーネルＢのインデックス範囲（２，２）または（１，１）を有する部分Ａは、リソースＡを読み取ってリソースＢに書き込む。依存関係データをチェックするための４つの異なる戦略を、図１２Ａ～１２Ｄに示す。これにより、カーネルＢの部分Ａが依存関係データをチェックすることができる。
【0086】
詳細には、第２カーネル（たとえば、カーネルＢ）の一部分の実行前に依存関係データがチェックされる第１カーネル（たとえば、カーネルＡ）の１つ以上の部分は、第２カーネル（たとえば、カーネルＢ）の一部分を含む各次元に対するインデックス範囲に依存する。一実施形態では、第１カーネル（たとえば、カーネルＡ）の一部分に関連する依存関係データをチェックする。一部分は、第２カーネル（たとえば、カーネルＢ）のそれらに対応する各次元に対するインデックス範囲（またはそのオフセット）を含む。別の実施形態では、第１カーネル（たとえば、カーネルＡ）の複数の部分に関連する依存関係データをチェックする。部分は、第２カーネルの各次元に対するインデックス範囲の上位集合にまとめられる各次元に対するインデックス範囲を含む。さらなる他の実施形態では、第１カーネル（たとえば、カーネルＡ）の部分に関連する１つ以上の依存関係データをチェックする。１つ以上の部分は、第２カーネル（たとえば、カーネルＢ）のインデックス範囲を用いて計算された関数である各次元に対する少なくとも１つのインデックス範囲を含む。
【0087】
詳細には、図１２Ａに、本開示の一実施形態による、カーネルＢの部分Ａによる依存関係データ（その部分のインデックス範囲（たとえば２，２）に対応する）のチェックを例示する。たとえば、カーネルＢの部分Ａは、対応するインデックス空間におけるインデックス範囲（２，２）に対応付けられる。また、図１２Ａに示すように、カーネルＢの部分Ａは、リソースＢの領域（２，２）に書き込む。カーネルＢの部分ＡがリソースＡにおいて読み取るかまたは書き込んだ領域と、その同じデータまたはその何らかの関数が書き込まれたリソースＢ内に配置された領域との間に１対１の変換が存在する。すなわち、出力データを受け取るリソースＢの領域（２，２）は、データを読み取られたリソースＡの領域（２，２）と同じ場所である。言い換えれば、領域インデックス（リソースＡの（２，２））と部分インデックス（カーネルＢの（２，２））との間に１対１の関係が存在する。
【0088】
図１２Ｂに、本開示の一実施形態による、インデックス範囲に対応付けられるカーネルＢの部分Ａによる依存関係データの複数のピースのチェックを例示する、詳細には、カーネルＢの部分Ａのインデックス範囲（２，２）または部分ＩＤのうちの１つの半径内にあるインデックス範囲に対応する依存関係データをチェックされる。たとえば、カーネルＢの部分Ａはフィルタ関数であり得る。フィルタ関数では、中心ピクセル（たとえば、カーネルＢの部分Ａのインデックス範囲に関連するリソースＡの領域（２，２）に対応する）を囲む複数の領域が読み取られてフィルタリングされ、リソースＢの領域（２，２）に出力される。すなわち、フィルタ関数は、カーネルＢの部分Ａのインデックス範囲（たとえば、部分ＩＤ）を囲むサンプリング領域を規定する。図示したように、データを読み取るサンプリング領域は、リソースＡの領域（１，１）、（２，１）、（３，１）、（１，２）、（２，２）、（３，２）、（１，３）、（２，３）、及び（３，３）を含む。関数から生成されている出力は、リソースＢの領域（２，２）内に記憶される。
【0089】
図１２Ｃに、本開示の一実施形態による、カーネルＢの部分Ａによる依存関係データのチェックを例示する。依存関係データは、その部分のインデックス範囲の関数である。詳細には、カーネルＢの部分Ａのインデックス範囲（１，１）または部分ＩＤの関数に基づいて、依存関係データをチェックする。この場合、関数は、部分Ａ、カーネルＢのインデックス範囲（１，１）を２倍にして、右及び下方向におけるその隣接物を取ることである。図示したように、サンプリングされて読み取られる領域は、リソースＡの領域（２，２）、（３，２）、（２，３）、及び（３，３）を含む。関数から生成されている出力はリソースＢの領域（１，１）内に記憶する。すなわち、関数はダウンサンプリング操作を表している。
【0090】
図１２Ｄに、本開示の一実施形態による、カーネルＢの部分Ａによる依存関係データのチェックを例示する。依存関係データは、その部分のインデックス範囲の関数である。関数はその部分のインデックス範囲のオフセットである。詳細には、カーネルＢの部分Ａのインデックス範囲（２，２）または部分ＩＤの関数に基づいて、依存関係データをチェックする。この場合、関数は、部分Ａ、カーネルＢのインデックス範囲（２，２）を上向き方向にオフセットすることである。図示したように、サンプリングされて読み取られる領域は、リソースＡの領域（２，１）である。関数から生成されている出力はリソースＢの領域（２，２）内に記憶する。
【0091】
カーネルのインデックス範囲の一部分の関数を用いると、規定のインデックス空間の外にあるインデックスになり得る。これらの場合では、さらなる動作を行い得る。詳細には、図１３Ａ～Ｃに、本開示の実施形態による、カーネルの一部分のインデックス範囲の関数が規定のインデックス空間の外にあるときに対処するための種々の戦略を例示する。
【0092】
明瞭及び簡潔にするために、図１３Ａ～１３Ｃのそれぞれは、単位サイズのインデックス範囲（たとえば、「単位」インデックス範囲）を有するカーネルの各部分を示す。また、図１３Ａ～１３Ｃのそれぞれにおいて、カーネルＡはリソースＡの領域に書き込み、関連する依存関係データを生成して記憶する。カーネルＢのインデックス範囲（２，２）を有する部分Ａは、リソースＡを読み取ってリソースＢに書き込む。第１カーネルの一部分に対するインデックス範囲がそのインデックス空間の外にある場合の異なる戦略を、図１３Ａ～１３Ｃに示す。具体的には、（－３，－１）のオフセットを、単位インデックス範囲（２，２）に適用する。その結果、第１の次元（たとえば、水平方向またはｘ方向）においてインデックス空間の外にある（－１，１）の単位インデックス範囲となる（図１３Ｃにも示す）。
【0093】
図１３Ａに、本開示の一実施形態による、カーネルＢの部分Ａのインデックス範囲に適用されたオフセット（たとえば、関数）が規定のインデックス空間から外れたときに、インデックス範囲の１つの次元をクランプすることを例示する。オフセットは、リソースＡにおける同様の次元の対応する領域に変換される。詳細には、カーネルＡの一部分に対するオフセットインデックス範囲、上位集合インデックス範囲、または計算されたインデックス範囲がインデックス空間の外にある場合、カーネルＡが生成した依存関係データを、インデックス空間の外にある次元において有効範囲にクランプされたインデックス範囲に対応するカーネルＡの一部分についてチェックする。クランピングによって、結果として生じるインデックス範囲（０，１）がインデックス空間内にあることが確実になる。たとえば、インデックス範囲を水平方向またはｘ方向においてその最初の値の０にクランプして、依存関係データがリソースＡの領域（０，１）についてチェックされるようにする。
【0094】
図１３Ｂに、本開示の一実施形態による、カーネルＢの一部分のインデックス範囲に適用されたオフセット（たとえば、関数）が規定のインデックス空間から外れたときに、インデックス範囲の１次元においてラッピングすることを例示する。オフセットは、リソースＡにおける同様の次元の対応する領域に変換される。詳細には、カーネルＡの一部分に対するオフセットインデックス範囲、上位集合インデックス範囲、または計算されたインデックス範囲がインデックス空間の外にある場合、カーネルＡが生成した依存関係データを、インデックス空間の外にある次元において有効範囲にラッピングされたインデックス範囲に対応するカーネルＡの一部分についてチェックする。詳細には、インデックス範囲を（５，１）にラッピングする。ラッピングによって、結果として生じるインデックス範囲（５，１）がインデックス空間内にあることが確実になる。一実施形態では、値を、その方向のインデックス空間のサイズを伴うインデックスの符号なしモジュロとして選択する。ラッピングを行うときには他の方法が好適である。たとえば、インデックス範囲を水平方向またはｘ方向においてその最大値の５にラッピングして、依存関係データがリソースＡの領域（５，１）についてチェックされるようにする。
【0095】
図１３Ｃに、本開示の一実施形態による、カーネルの一部分のインデックス範囲に適用されたオフセット（たとえば、関数）が規定のインデックス空間から外れたときに、依存関係データを無視することを例示する。詳細には、カーネルＡが生成した依存関係データを無視する。そのようにして、カーネルＢの一部分は、依存関係データを待たないと決定するか、またはカーネルＢのその部分を実行しない、またはそれを何らかの他の方法で取り扱うことを決定し得る。
【0096】
いくつかの実施形態では、依存関係データに対するインデックス範囲を読み取るために行う関数、及び結果が規定のインデックス空間の外にある場合に行う動作は、リソースごと及びカーネルごとに異なり得る。すなわち、関数は、関連するリソース及びカーネルに基づき得る。
【0097】
図１４Ａに、本開示の一実施形態による、動的な割り当て方式を例示する。ここでは、カーネルの部分を実行用に複数のＧＰＵに割り当てるときに、異なるＧＰＵが異なる空間充填曲線（space filling curves: SFC）に続く。詳細には、カーネルの部分をＧＰＵに動的に割り当てる。単一のＧＰＵにカーネルの固有の部分に対する割り当てを与えて、どの部分も実行用に１つの対応するＧＰＵに割り当てられるようにする。図示したように、カーネルの２次元のインデックス空間１４１０は２４のインデックスを含み得る。
【0098】
動的な割り当て方式を用いることができ、ＧＰＵがカーネルの部分を実行できるようになる（たとえば、実行に利用できる）と、カーネルの部分をＧＰＵに割り当てられる。カーネルの各部分を実行するレスポンシビリティをただ１つのＧＰＵに割り当てて、カーネルの実行中にカーネルの部分をＧＰＵに動的に割り当てる。すなわち、カーネルの部分の割当ては、ＧＰＵごとに異なり得る所定の順序（たとえば、空間充填曲線）を参照し得る。図１４Ａは、１つ以上の所定の順序または空間充填曲線を表しているが、当然のことながら、他のアクセスパターンに対しては他の順序の方が効率的な場合がある。詳細には、各ＧＰＵに割り当てられた部分の局所性を実現するために、順序はＧＰＵごとに異なり得る。利点として、ＧＰＵごとに異なる順序を用いたときであっても、同じＧＰＵ上で複数のカーネルに対して同じ順序を（たとえば、連続して）用いると、他のＧＰＵの他のローカルメモリからデータをフェッチする必要が減る。なぜならば、部分の局所性によって、データがそのＧＰＵ内に存在し得るからである。図１４Ａに示すように、カーネルの部分を、各ＧＰＵに対する既知の所定の順序を用いて、対応するＧＰＵに割り当てようと試みる。
【0099】
図１４Ａに、複数の順序付けまたは空間充填曲線（それぞれ、ＧＰＵに対応している）を示す。たとえば、ＧＰＵ Ａは、インデックス空間１４１０のインデックス範囲（０，１）で始まる空間充填曲線１４２０に従い、インデックス範囲をほぼ時計回りにチェックして、インデックス範囲（０，２）で終了する。説明のために、空間充填曲線１４２０は、カーネルの部分を以下の順序で割り当てようと試みている。（０，１）、次に（０，０）、次に（１，０）、次に（１，１）、次に（２，１）など。また、ＧＰＵ Ｂは、インデックス空間１４１０のインデックス範囲（５，１）で始まる空間充填曲線１４２５に従い、インデックス範囲をほぼ反時計回りにチェックして、インデックス範囲（５，２）で終了する。説明のために、空間充填曲線１４２５は、カーネルの部分を以下の順序で割り当てようと試みている。（５，１）、次に（５，０）、次に（４，０）、次に（４，１）、次に（３，１）など。さらに、ＧＰＵ Ｃは、インデックス空間１４１０のインデックス範囲（０，２）で始まる空間充填曲線１４３０に従い、インデックス範囲をほぼ反時計回りにチェックして、インデックス範囲（０，１）で終了する。説明のために、空間充填曲線１４３０は、カーネルの部分を以下の順序で割り当てようと試みている。（０，２）、次に（０，３）、次に（１，３）、次に（１，２）、次に（２，２）など。
【0100】
また、ＧＰＵ Ｄは、インデックス空間１４１０のインデックス範囲（５，２）で始まる空間充填曲線１４３５に従い、インデックス範囲をほぼ時計回りにチェックして、インデックス範囲（５，１）で終了する。説明のために、空間充填曲線１４３５は、カーネルの部分を以下の順序で割り当てようと試みている。（５，２）、次に（５，３）、次に（４，３）、次に（４，２）、次に（３，２）など。
【0101】
一実施形態では、カーネルの一部分が、バッファリソースまたは画像リソースにおいて空間的に互いに近接した複数の領域を、連続パスにおける入力として用いるときに、ＧＰＵごとの部分局所性に対して最適化された１つ以上の空間充填曲線によって、他のＧＰＵのローカルメモリからデータをフェッチする必要が減る。詳細には、カーネルの部分を割り当てるときの対応するＧＰＵが参照する所定の順序は、カーネルまたは対応するカーネル呼び出しの次元内で規定される空間充填曲線であり得る。
【0102】
一実施形態では、対応する割り当て順序に沿った進行（たとえば、空間充填曲線に対する開始からの距離）を、複数のＧＰＵ間で共有することができる。この進行によって、すでに割り当てられている一部分をＧＰＵが割り当てようとする必要がないように、カーネルのどの部分がすでに各ＧＰＵに割り当てようと試みられたかをチェックする効率的な方法が得られる。
【0103】
図１４Ｂに、本開示の一実施形態による、図１４Ａで規定したＧＰＵ空間充填曲線において輪郭が描かれた割り当ての順序に従うカーネルの部分の割り当てを例示する（たとえば、ＧＰＵ Ａに対する曲線１４２０、ＧＰＵ Ｂに対する曲線１４２５、ＧＰＵ Ｃに対する曲線１４３０、及びＧＰＵ Ｄに対する曲線１４３５）。各ＧＰＵは、部分を同時に、たとえばステップ刻みで割り当てる。空間充填曲線は種々のインデックス範囲で始まるため、各ＧＰＵに当初は、実行用の対応するカーネルの一部分が割り当てられる。たとえば、ステップ１では、ＧＰＵ Ａにはインデックス空間１４１０の部分（０，１）が割り当てられ、ＧＰＵ Ｂには部分（５，１）が割り当てられ、ＧＰＵ Ｃには部分（０，２）が割り当てられ、及びＧＰＵ Ｄには部分（５，２）が割り当てられる。
【0104】
部分によっては、完了までの時間が他よりも長い場合があるため（たとえば、入力値などに応じて）、ＧＰＵによっては、インデックス空間１４１０から割り当てられる部分がより多い状態で終わる。たとえば、ＧＰＵ Ｃは、ステップ１～３上で部分（０，２）を実行し続けて、ステップ２またはステップ３では何らさらなる部分は割り当てられないが、ＧＰＵ Ａ、ＧＰＵ Ｂ、及びＧＰＵ Ｄはそれぞれ、ステップ２及びステップ３のそれぞれにおいてさらなる部分が割り当てられている。
【0105】
場合によっては、ＧＰＵは２つ以上の部分を割り当てることができる。たとえば、ステップ４では、ＧＰＵ Ａは３つのさらなる部分（たとえば、部分（１，１）、（２，１）、及び（２，０））を割り当てることができる。また、ステップ４では、ＧＰＵ Ｂは２つのさらなる部分（たとえば、部分（４，１）及び（３，１））を割り当てることができる。
【0106】
図１４Ｂに示すように、ＧＰＵはそれぞれ、部分が互いに局在化されるように、局所性によって部分が割り当てられている。場合によっては、ＧＰＵは、局在化に対する希望に従って、割り当てができない場合がある。たとえば、ステップ５では、ＧＰＵ Ｂが、両方の部分（３，０）、（２，０）、（２，１）を割り当てるようと試みるが、これらの部分はそれぞれ、ＧＰＵ Ａ及び／またはＧＰＵ Ｃによってすでに割り当てられている。空間充填曲線１４２５に従ってすでに割り当てられているわけではないＧＰＵ Ｂが利用できる最初の部分は、部分（１，２）である。すなわち、ＧＰＵ Ｂは、ＧＰＵにすでに割り当てられているわけではない所定の順序または空間充填曲線１４２５に沿って次の部分を割り当てる。
【0107】
図１～１４で前述したマルチＧＰＵアーキテクチャ及びそれらの実施態様の詳細な説明を用いて、図１５のフロー図１５００に、本開示の一実施形態による、アプリケーションに対する画像のマルチＧＰＵレンダリングを含むグラフィックス処理を行うための方法を例示する。依存関係データはカーネル処理及び／またはドローコール実行に基づき得る。複数のＧＰＵが協働して画像またはデータを処理する。前述したように、種々のアーキテクチャは、複数のＧＰＵが協働して画像またはデータを処理することを含み得る（たとえば、クラウドゲーミングシステムの１つ以上のクラウドゲーミングサーバ内、またはスタンドアロンシステム内、たとえば、複数のＧＰＵを有するハイエンドグラフィックスカードを含むパーソナルコンピュータまたはゲーミングコンソール内などで）。ＧＰＵは同時に実行される。実施形態では、複数のＧＰＵは１つ以上のコマンドバッファを共有し得るか、または各ＧＰＵは１つ以上の専用のコマンドバッファを有し得る。コマンドバッファは、カーネル呼び出しコマンド、ならびに他のコマンド（たとえば、ドローコールコマンド）、またはカーネル呼び出しコマンドとドローコールコマンドとの両方の組み合わせを含むことができる。
【0108】
１５１０において、本方法は、複数のグラフィックス処理ユニット（ＧＰＵ）を用いて画像をレンダリングすることを含む。たとえば、協働して画像及び／またはデータを生成する複数のＧＰＵを用いて、グラフィックスをアプリケーションに対してレンダリングし得る。単一画像及び／またはリアルタイムアプリケーションに対する画像列のうちの１つ以上の画像のそれぞれをレンダリングするときに、マルチＧＰＵ処理を行う。
【0109】
１５２０において、本方法は、複数のＧＰＵ上で複数のカーネルを実行することを含む。対応するカーネルを実行するレスポンシビリティを１つ以上の部分に分割し、各部分を対応するＧＰＵに割り当てる。
【0110】
１５３０において、本方法は、複数のＧＰＵ上で複数のドローコールを実行することを含む。対応するドローコールを実行するレスポンシビリティを１つ以上の部分に分割し、各部分を対応するＧＰＵに割り当てる。詳細には、描画コマンドを介して画像をレンダリングするときに、対応する描画コマンドを部分に分割し得る（カーネルの呼び出しを部分に分割するのに類似する方法で）。各部分がたった１つのＧＰＵに割り当てられるように、各部分をＧＰＵに割り当てる。このように、各ＧＰＵは、同じＧＰＵに割り当てられたドローコールの部分をレンダリングする。加えて、ドローコールの各部分は依存関係データを生成し得る（たとえば、ドローコールの一部分の完了時に依存関係データを生成し得る）。
【0111】
一実施形態では、ドローコールの部分及び／またはカーネルの部分の間で依存関係チェックがあり得る。すなわち、ドローコールの一部分はカーネルの１つ以上の部分に依存するか、またはカーネルの一部分はドローコールの１つ以上の部分に依存する。依存関係データをカーネルの一部分が生成し得るか、またはドローコールの一部分が生成し得る。
【0112】
１５４０において、本方法は（任意選択で）、カーネルの一部分の実行の前に、カーネルにおいて、ドローコールの１つ以上の部分の依存関係データをチェックすることを含む。詳細には、カーネルの部分は、ドローコールの部分が生成した依存関係データをチェックして、適切な処置を取り得る（たとえば、カーネルの対応する部分の実行を、対応するドローコールの部分が完了するまで一時停止する）。
【0113】
１５５０において、本方法は（任意選択で）、ドローコールの一部分の実行の前に、ドローコールにおいて、カーネルの１つ以上の部分の依存関係データをチェックすることを含む。詳細には、ドローコールの各部分は、依存関係データをチェックして（たとえば、依存関係が満たされるまで処理しない）、及び／または依存関係データを生成し得る（たとえば、ドローコールの一部分の完了時に依存関係データを生成する）。一実施形態では、ドローコールの部分は、カーネルの部分が生成した依存関係データをチェックして、適切な処置を取り得る（たとえば、描画コマンドの対応する部分の実行を、対応するカーネルの一部分が完了するまで一次停止する）。
【0114】
図１６に、本開示の種々の実施形態の態様を実行するために使用できるデバイス例１６００のコンポーネントを例示する。たとえば、図１６に、本開示の実施形態による、カーネルの実行に適した典型的なハードウェアシステムを例示する。複数のグラフィックス処理ユニット（ＧＰＵ）が協働して画像またはデータを処理する。このブロック図で例示するデバイス１６００は、パーソナルコンピュータ、サーバコンピュータ、ゲーミングコンソール、モバイルデバイス、または他のデジタルデバイス（それぞれ、本発明の実施形態を実行するのに適している）を組み込むことができるかまたはそれらとすることができる。デバイス１６００は、ソフトウェアアプリケーション及び随意的にオペレーティングシステムを実行するための中央処理ユニット（ＣＰＵ）１６０２を含んでいる。ＣＰＵ１６０２は、１つ以上の同種または異種の処理コアから構成され得る。
【0115】
種々の実施形態により、ＣＰＵ１６０２は１つ以上の処理コアを有する１つ以上の汎用マイクロプロセッサである。さらなる実施形態を、ゲームの実行中にグラフィックス処理を行うように構成されたアプリケーションの高並列で計算集約型のアプリケーション（たとえば、媒体及びインタラクティブエンターテインメントアプリケーション）に具体的に適応されたマイクロプロセッサアーキテクチャを伴う１つ以上のＣＰＵを用いて実施することができる。
【0116】
メモリ１６０４は、ＣＰＵ１６０２及びＧＰＵ１６１６が用いるアプリケーション及びデータを記憶する。記憶装置１６０６は、アプリケーション及びデータ用の不揮発性記憶装置及び他のコンピュータ可読媒体であり、固定ディスクドライブ、リムーバブルディスクドライブ、フラッシュメモリ装置、及びＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、ブルーレイ、ＨＤ－ＤＶＤ、または他の光学記憶装置、ならびに信号伝送及び記憶媒体を含んでいてもよい。ユーザ入力デバイス１６０８は、１人以上のユーザからのユーザ入力をデバイス１６００に伝達する。その例としては、キーボード、マウス、ジョイスティック、タッチパッド、タッチスクリーン、スチールまたはビデオレコーダ／カメラ、及び／またはマイクロフォンを挙げてもよい。ネットワークインターフェース１６０９によって、デバイス１６００は、電子通信ネットワークを介して他のコンピュータシステムと通信することができる。ネットワークインターフェース１６０９としては、ローカルエリアネットワーク及びワイドエリアネットワーク（たとえば、インターネット）を介した有線または無線通信を挙げてもよい。オーディオプロセッサ１６１２は、ＣＰＵ１６０２、メモリ１６０４、及び／または記憶装置１６０６が提供する命令及び／またはデータからアナログまたはデジタルオーディオ出力を生成するように適応されている。デバイス１６００のコンポーネント（たとえば、ＣＰＵ１６０２、グラフィックスサブシステム、たとえば、ＧＰＵ１６１６、メモリ１６０４、データ記憶装置１６０６、ユーザ入力デバイス１６０８、ネットワークインターフェース１６０９、及びオーディオプロセッサ１６１２）は、１つ以上のデータバス１６２２を介して接続されている。
【0117】
グラフィックスサブシステム１６１４がさらに、データバス１６２２及びデバイス１６００のコンポーネントと接続されている。グラフィックスサブシステム１６１４は、少なくとも１つのグラフィックス処理ユニット（ＧＰＵ）１６１６及びグラフィックスメモリ１６１８を含んでいる。グラフィックスメモリ１６１８は、出力画像の各ピクセルに対するピクセルデータを記憶するために用いるディスプレイメモリ（たとえば、フレームバッファ）を含んでいる。グラフィックスメモリ１６１８は、ＧＰＵ１６１６と同じデバイスに統合すること、個別のデバイスとしてＧＰＵ１６１６と接続すること、及び／またはメモリ１６０４内で実施することができる。ピクセルデータをＣＰＵ１６０２から直接グラフィックスメモリ１６１８に提供することができる。代替的に、ＣＰＵ１６０２は、ＧＰＵ１６１６に、所望の出力画像を規定するデータ及び／または命令を提供する。所望の出力画像から、ＧＰＵ１６１６が１つ以上の出力画像のピクセルデータを生成する。所望の出力画像を規定するデータ及び／または命令を、メモリ１６０４及び／またはグラフィックスメモリ１６１８に記憶することができる。一実施形態では、ＧＰＵ１６１６は、シーンに対するジオメトリ、照明、シェーディング、模様付け、動き、及び／またはカメラパラメータを規定する命令及びデータから、出力画像用のピクセルデータを生成するための３Ｄレンダリング能力を含む。ＧＰＵ１６１６はさらに、シェーダープログラムを実行することができる１つ以上のプログラマブル実行ユニットを含むことができる。
【0118】
グラフィックスサブシステム１６１４は、グラフィックスメモリ１６１８から、ディスプレイデバイス１６１０上に表示すべき、または投影システム（図示せず）によって投影すべき画像用のピクセルデータを定期的に出力する。ディスプレイデバイス１６１０は、デバイス１６００からの信号に応じて視覚情報を表示することができる任意のデバイスとすることができる。たとえば、ＣＲＴ、ＬＣＤ、プラズマ、及びＯＬＥＤディスプレイである。デバイス１６００は、ディスプレイデバイス１６１０に、たとえば、アナログまたはデジタル信号を提供することができる。
【0119】
グラフィックスサブシステム１６１４を最適化するための他の実施形態は、複数のＧＰＵを用いてカーネルを処理し、カーネル部分ごとの依存関係を追跡して、後続のカーネルの依存部分の早い処理を可能にすることを含むことができる。複数のＧＰＵが協働して画像またはデータを処理する。グラフィックスサブシステム１６１４を、１つ以上の処理デバイスとして構成することができる。
【0120】
たとえば、一実施形態では、グラフィックスサブシステム１６１４を、レンダリング中の領域テストによってアプリケーションに対するジオメトリのマルチＧＰＵレンダリングを行うように構成してもよい。複数のグラフィックスサブシステムが、グラフィックスを実施していることができ、及び／または単一アプリケーションに対するパイプラインをレンダリングしていることができる。すなわち、グラフィックスサブシステム１６１４は、アプリケーションを実行するときに画像または画像列の１つ以上の各画像をレンダリングするために用いる複数のＧＰＵを含んでいる。
【0121】
他の実施形態では、グラフィックスサブシステム１６１４は複数のＧＰＵデバイスを含んでいる。これらは、対応するＣＰＵ上で実行されている単一アプリケーションに対するグラフィックス処理を実行するために結合される。たとえば、複数のＧＰＵは、画像に対するオブジェクトのレンダリング中の領域テストによってアプリケーションに対するジオメトリのマルチＧＰＵレンダリングを行うことができる。他の例では、複数のＧＰＵは交互形式のフレームレンダリングを実行することができる。ここでは、ＧＰＵ１が第１のフレームをレンダリングし、ＧＰＵ２が第２のフレームをレンダリングして、これを連続的なフレーム周期で行うことなどを、最後のＧＰＵに達するまで続ける。その上で、最初のＧＰＵが次のビデオフレームをレンダリングする（たとえば、２つのＧＰＵのみが存在する場合には、ＧＰＵ１が第３のフレームをレンダリングする）。すなわち、フレームをレンダリングするときにＧＰＵが回転する。レンダリング動作はオーバーラップすることができる。ＧＰＵ１が第１のフレームのレンダリングを終了する前に、ＧＰＵ２が第２のフレームのレンダリングを開始してもよい。別の実施態様では、複数のＧＰＵデバイスに、レンダリング及び／またはグラフィックスパイプラインにおいて異なるシェーダー動作を割り当てることができる。マスタＧＰＵが主なレンダリング及び合成を行っている。たとえば、３つのＧＰＵを含むグループでは、マスタＧＰＵ１が、スレーブＧＰＵ２及びスレーブＧＰＵ３からの出力の主なレンダリング（たとえば、第１のシェーダー動作）及び合成を実行することができる。スレーブＧＰＵ２は、第２のシェーダー（たとえば、河などの流体効果）動作を実行することができ、スレーブＧＰＵ３は、第３のシェーダー（たとえば、粒子煙）動作を実行することができる。マスタＧＰＵ１は、ＧＰＵ１、ＧＰＵ２、及びＧＰＵ３のそれぞれからの結果を合成する。このように、異なるシェーダー動作（たとえば、旗を振ること、風、発煙、火災など）を実行するために異なるＧＰＵを割り当てて、ビデオフレームをレンダリングすることができる。さらなる他の実施形態では、３つのＧＰＵをそれぞれ、ビデオフレームに対応するシーンの異なるオブジェクト及び／または部分に割り当てることができる。前述の実施形態及び実施態様では、これらの動作を同じフレーム周期（同時に並列）でまたは異なるフレーム周期（順次に並列）で行うことができる。
【0122】
したがって、本開示では、アプリケーションを実行するときの画像または画像列内の１つ以上の各画像に対するオブジェクトのレンダリング中の領域テストによってアプリケーションに対するジオメトリのマルチＧＰＵレンダリングを行うように構成された方法及びシステムを説明している。
【0123】
当然のことながら、本明細書で規定した種々の実施形態を、本明細書で開示した種々の特徴を用いて具体的な実施に結合するかまたは組み立ててもよい。したがって、提供した例は単にいくつかの可能な例であり、種々の要素を結合してさらに多くの実施態様を規定することによって可能な種々の実施態様に限定されない。いくつかの例では、開示した実施態様または同等な実施態様の趣旨から逸脱することなく、いくつかの実施態様にはもっと少ない要素が含まれていてもよい。
【0124】
本開示の実施形態は、種々のコンピュータシステム構成（たとえば、ハンドヘルドデバイス、マイクロプロセッサシステム、マイクロプロセッサベースまたはプログラマブル民生用エレクトロニクス、ミニコンピュータ、メインフレームコンピュータなど）によって実施してもよい。また本開示の実施形態は、分散コンピューティング環境において実行することもできる。ここでは、タスクが、有線ベースまたは無線ネットワークを通してリンクされたリモート処理デバイスによって行われる。
【0125】
前述の実施形態を念頭において、当然のことながら、本開示の実施形態は、コンピュータシステムに記憶されたデータを伴う種々のコンピュータ実装動作を用いることができる。これらの動作は、物理量の物理的な操作を必要とするものである。本開示の実施形態の一部分を構成する本明細書で説明した動作のいずれも、有用なマシン動作である。また本開示の実施形態は、これらの動作を行うためのデバイスまたは装置に関する。装置は必要な目的に対して特別に構成することもできるし、または装置を、コンピュータに記憶されたコンピュータプログラムによって選択的に作動または構成される汎用コンピュータとすることもできる。詳細には、種々の汎用マシンを本明細書の教示により書き込まれたコンピュータプログラムによって用いることもできるし、または必要な動作を実行するためにもっと特化された装置を構成することがより好都合であり得る。
【0126】
また本開示を、コンピュータ可読媒体上のコンピュータ可読コードとして具体化することができる。コンピュータ可読媒体は、データを記憶することができる任意のデータ記憶装置とすることができる。データはその後にコンピュータシステムによって読み取ることができる。コンピュータ可読媒体の例としては、ハードドライブ、ネットワーク接続ストレージ（ＮＡＳ）、読み取り専用メモリ、ランダムアクセスメモリ、ＣＤ－ＲＯＭ、ＣＤ－Ｒ、ＣＤ－ＲＷ、磁気テープ、ならびに他の光学及び非光学データ記憶装置が挙げられる。コンピュータ可読媒体としては、コンピュータ可読コードが分散的に記憶及び実行されるようにネットワーク結合コンピュータシステム上に分散されたコンピュータ可読有形的表現媒体を挙げることができる。
【0127】
本方法の動作を特定の順序で説明したが、当然のことながら、動作の合間に他のハウスキーピング動作を行ってもよいし、または動作を調整してわずかに異なる時間に行われるようにしてもよいし、またはシステム内で分散させて、オーバーレイ動作の処理が所望の方法で行われる限り、処理動作を処理に対応付けられる種々の間隔で行えるようにしてもよい。
【0128】
前述の開示内容は、理解を明瞭にするために少し詳しく説明しているが、添付の請求項の範囲内で特定の変形及び変更を実施できることが明らかである。したがって、本実施形態は例示的であって限定的ではないと考えるべきであり、本開示の実施形態は、本明細書で示した詳細に限定してはならないが、添付の請求項の範囲及び均等物内で変更してもよい。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7A】
【図7B】
【図8】
【図9】
【図10】
【図11A】
【図11B】
【図12A】
【図12B】
【図12C】
【図12D】
【図13A】
【図13B】
【図13C】
【図14A】
【図14B】
【図15】
【図16】