以下の詳細な説明には、説明の目的上、多くの特定の詳細が含まれているが、当業者であれば分かるように、以下の詳細に対する多くの変形及び修正も本開示の範囲内である。したがって、以下に説明する本開示の態様は、この説明に続く特許請求の範囲に対する一般性を何ら失うことなく、また特許請求の範囲に限定を課すことなく、述べられている。
概して、本開示の実施形態は、カーネルを実行するための方法及びシステムであって、複数のグラフィックス処理ユニット(GPU)が協働して画像またはデータを処理する方法及びシステムを開示している。_処理中のカーネルは部分に分割される。画像またはバッファを処理する間、GPUはカーネルの部分に割り当られ、かつ、これらの部分間の依存関係データを追跡し、その結果、カーネル間のきめの細かい、領域ベースの依存関係データを用いて、GPU間のバランスの取れた作業負荷が可能になる。
種々の実施形態の前述した全般的な理解に基づき、次に実施形態の詳細例について、種々の図面を参照して説明する。
明細書の全体に渡って、「アプリケーション」または「ゲーム」または「ビデオゲーム」または「ゲーミングアプリケーション」に参照する場合、入力コマンドの実行を通して指示される任意のタイプの対話型アプリケーションを表すことが意図されている。例示のみを目的として、対話型アプリケーションには、ゲーミング、文書処理、ビデオ処理、ビデオゲーム処理などに対するアプリケーションが含まれる。これらの導入された用語は相互に交換可能である。
明細書の全体に渡って、本開示の種々の実施形態を、4つのGPUを有する典型的なアーキテクチャを用いてアプリケーションに対するカーネルのマルチGPU処理について説明する。しかし当然のことながら、アプリケーションに対する画像及び/またはデータを生成するときに、任意の数のGPU(たとえば、2つ以上のGPU)が協働してもよい。
図1は、本開示の一実施形態による、アプリケーションを処理するときにカーネルを実行するためのシステムの略図であり、複数のグラフィックス処理ユニット(GPU)が協働して画像またはデータを処理する図である。一実施形態では、システムは、1つ以上のクラウドゲーミングサーバ間でネットワークを介してゲーミングを提供するように構成されている。クラウドゲーミングには、サーバにおいてビデオゲームを実行して、ゲームレンダリングされたビデオフレームを生成することが含まれる。これは次に、クライアントに送られて表示される。
図1は、クラウドゲーミングシステムの1つ以上のクラウドゲーミングサーバ間でのカーネルのマルチGPU実行の実施態様を例示しているが、本開示の他の実施形態では、アプリケーションを処理するときにカーネルを実行し、複数のGPUを有するハイエンドグラフィックスカードを含むパーソナルコンピュータまたはゲーミングコンソールなどのスタンドアロンシステム内で、複数のグラフィックス処理ユニット(GPU)が協働して画像またはデータを処理する、実行することが提供される。
また当然のことながら、カーネルのマルチGPU実行を、物理GPU、または仮想GPU、または両方の組み合わせを種々の実施形態で(たとえば、クラウドゲーミング環境においてまたはスタンドアロンシステム内で)用いて、行ってもよい。たとえば、仮想マシン(たとえば、インスタンス)を、ハードウェア層の1つ以上のコンポーネント(たとえば、複数のCPU、メモリモジュール、GPU、ネットワークインターフェース、通信コンポーネントなど)を用いるホストハードウェア(たとえば、データセンタに配置される)のハイパーバイザを用いて、形成してもよい。これらの物理リソースを、ラック(たとえば、CPUのラック、GPUのラック、メモリのラックなど)内に配列してもよい。ラック内の物理リソースにはトップオブラックスイッチを用いてアクセスしてもよく、これにより、インスタンスに対して用いるコンポーネントの組み立て及びアクセスを行うための構造が促進される(たとえば、インスタンスの仮想化コンポーネントを構築するときに)。全般的に、ハイパーバイザは、仮想リソースを用いて構成される複数のインスタンスの複数のゲストオペレーティングシステムを示すことができる。すなわち、オペレーティングシステムはそれぞれ、1つ以上のハードウェアリソース(たとえば、対応するデータセンタに配置される)によってサポートされる対応する組の仮想化リソースを用いて構成してもよい。たとえば、各オペレーティングシステムを、仮想CPU、複数の仮想GPU、仮想メモリ、仮想化通信コンポーネントなどによってサポートしてもよい。加えて、あるデータセンタから別のデータセンタへ移される得るインスタンスの構成によって待ち時間を減らす。ユーザのゲーミングセッションを節約するときに、ユーザまたはゲームに対して規定されるGPU稼働率を用いることができる。GPU稼働率には、ゲーミングセッションに対するビデオフレームの高速レンダリングを最適化するための本明細書で説明する任意の数の構成を含むことができる。一実施形態では、ゲームまたはユーザに対して規定されるGPU稼働率を、構成可能な設定としてデータセンタ間で移すことができる。異なるジオロケーションからゲームをプレイするためにユーザが接続する場合には、GPU稼働率設定を移せることで、データセンタからデータセンタへゲームプレイを効率的に移行することができる。
本開示の一実施形態による、システム100は、クラウドゲームネットワーク190を介してゲーミングを提供する。ゲームは、ゲームをプレイしている対応するユーザのクライアントデバイス110(たとえば、シンクライアント)から遠隔で実行されている。システム100は、シングルプレイヤーモードまたはマルチプレイヤーモードのいずれかでネットワーク150を介してクラウドゲームネットワーク190を通して1つ以上のゲームをプレイしている1人以上のユーザに対するゲーミングコントロールを提供してもよい。いくつかの実施形態では、クラウドゲームネットワーク190は、ホストマシンのハイパーバイザ上で実行される複数の仮想マシン(VM)を含んでいてもよい。1つ以上の仮想マシンが、ホストのハイパーバイザにとって利用可能なハードウェアリソースを用いるゲームプロセッサモジュールを実行するように構成されている。ネットワーク150は1つ以上の通信技術を含んでいてもよい。いくつかの実施形態では、ネットワーク150は、高度な無線通信システムを有する第5世代(5G)ネットワーク技術を含んでいてもよい。
いくつかの実施形態では、通信を無線技術を用いて促進してもよい。このような技術には、たとえば、5G無線通信技術が含まれていてもよい。5Gは第5世代のセルラーネットワーク技術である。5Gネットワークはデジタルセルラーネットワークであり、ここでは、プロバイダがカバーするサービスエリアが、セルと言われる小さい地理的領域に分割される。音及び画像を表すアナログ信号は、電話機内でデジタル化され、アナログデジタル変換器によって変換されて、ビットのストリームとして送信される。セル内のすべての5G無線デバイスは、セル内のローカルアンテナアレイ及び低パワー自動化送受信装置(送信部及び受信部)を用いて電波によって通信し、他のセル内で再使用される周波数のプールから送受信装置によって割り当てられた周波数チャネル上で行われる。ローカルアンテナは、高帯域幅光ファイバまたは無線バックホール接続によって電話ネットワーク及びインターネットと接続される。他のセルネットワークの場合と同様に、モバイルデバイスがあるセルから別のセルへ横断すると、新しいセルに自動的に移される。当然のことながら、5Gネットワークは単に通信ネットワークのタイプ例であり、本開示の実施形態では、前の世代の無線または有線通信、ならびに5Gの後に来る後の世代の有線または無線技術を用いてもよい。
図示したように、クラウドゲームネットワーク190には、複数のビデオゲームにアクセスするゲームサーバ160が含まれる。ゲームサーバ160は、クラウド内で利用できる任意のタイプのサーバコンピューティングデバイスであってもよく、1つ以上のホスト上で実行される1つ以上の仮想マシンとして構成してもよい。たとえば、ゲームサーバ160は、ユーザに対するゲームのインスタンスをインスタンス化するゲームプロセッサをサポートする仮想マシンを管理してもよい。したがって、複数の仮想マシンに対応付けられるゲームサーバ160の複数のゲームプロセッサは、複数のユーザのゲームプレイに対応付けられる1つ以上のゲームの複数のインスタンスを実行するように構成されている。このように、バックエンドサーバサポートは、複数のゲーミングアプリケーションのゲームプレイの媒体(たとえば、ビデオ、オーディオなど)のストリーミングを、複数の対応するユーザに提供する。すなわち、ゲームサーバ160は、データ(たとえば、対応するゲームプレイのレンダリング画像及び/またはフレーム)を、対応するクライアントデバイス110にネットワーク150を通してストリーミングによって戻すように構成されている。このように、コンピュータ的に複雑なゲーミングアプリケーションを、クライアントデバイス110が受け取って転送するコントローラ入力に応じて、バックエンドサーバで実行してもよい。各サーバは画像及び/またはフレームをレンダリングすることができ、これらは次に、エンコード(たとえば圧縮)され、対応するクライアントデバイスにストリーミングされて表示される。
たとえば、複数のユーザは、ストリーミングメディアを受け取るように構成された対応するクライアントデバイス110を用いて、通信ネットワーク150を介してクラウドゲームネットワーク190にアクセスしてもよい。一実施形態では、クライアントデバイス110をシンクライアントとして構成して、計算機能(たとえば、ゲームタイトル処理エンジン111を含む)を提供するように構成されたバックエンドサーバ(たとえば、クラウドゲームネットワーク190)とのインターフェースを提供してもよい。別の実施形態では、クライアントデバイス110を、ビデオゲームの少なくとも何らかのローカル処理を行うためのゲームタイトル処理エンジン及びゲームロジックを用いて構成してもよく、さらに、バックエンドサーバで実行されるビデオゲームが生成するストリーミングコンテンツを受け取るために、またはバックエンドサーバサポートが提供する他のコンテンツに対して用いてもよい。ローカル処理に対しては、ゲームタイトル処理エンジンには、ビデオゲームに対応付けられるビデオゲーム及びサービスを実行するための基本プロセッサベースの機能が含まれる。その場合、ゲームロジックを、ローカルクライアントデバイス110上に記憶して、ビデオゲームを実行するために用いてもよい。
クライアントデバイス110はそれぞれ、クラウドゲームネットワークから異なるゲームへのアクセスをリクエストしていてもよい。たとえば、クラウドゲームネットワーク190は、ゲームサーバ160のCPUリソース163及びGPUリソース265を用いて実行されるように、ゲームタイトル処理エンジン111上に構築される1つ以上のゲームロジックを実行していてもよい。たとえば、ゲームロジック115aはゲームタイトル処理エンジン111と共同して、1つのクライアントに対してゲームサーバ160上で実行していてもよく、ゲームロジック115bはゲームタイトル処理エンジン111と共同して、2番目のクライアントに対してゲームサーバ160上で実行していてもよく、またゲームロジック115nはゲームタイトル処理エンジン111と共同して、n番目のクライアントに対してゲームサーバ160上で実行していてもよい。
詳細には、対応するユーザ(図示せず)のクライアントデバイス110は、通信ネットワーク150(たとえば、インターネット)を介してゲームへのアクセスをリクエストするように、またゲームサーバ160が実行するビデオゲームによって生成される表示画像をレンダリングするように、構成されている。エンコード画像は、クライアントデバイス110に送出されて、対応するユーザに関連して表示される。たとえば、ユーザは、ゲームサーバ160のゲームプロセッサ上で実行されているビデオゲームのインスタンスと、クライアントデバイス110を通してやり取りしていてもよい。より詳細には、ビデオゲームのインスタンスはゲームタイトル処理エンジン111によって実行される。ビデオゲームを実行する対応するゲームロジック(たとえば、実行可能コード)115は、データ記憶する(図示せず)を通して記憶されてアクセス可能であり、ビデオゲームを実行するために用いられる。ゲームタイトル処理エンジン111は、複数のゲームロジック(たとえば、ゲーミングアプリケーション)(それぞれ、ユーザによって選択可能である)を用いて、複数のビデオゲームをサポートすることができる。
たとえば、クライアントデバイス110は、対応するユーザのゲームプレイに関連するゲームタイトル処理エンジン111と、たとえば、ゲームプレイを駆動するために用いる入力コマンドを通して、相互に作用するように構成されている。詳細には、クライアントデバイス110は、種々のタイプの入力デバイス、たとえば、ゲームコントローラ、タブレットコンピュータ、キーボード、ビデオカメラによって取り込まれたジェスチャ、マウス、タッチパッドなどから入力を受け取ってもよい。クライアントデバイス110は、ネットワーク150を介してゲームサーバ160に接続することができるメモリ及びプロセッサモジュールを少なくとも有する任意のタイプのコンピューティングデバイスとすることができる。バックエンドのゲームタイトル処理エンジン111は、レンダリング画像を生成するように構成されている。レンダリング画像は、ネットワーク150を介して送出されて、クライアントデバイス110に関連する対応するディスプレイにおいて表示される。たとえば、クラウドベースのサービスを通して、ゲームレンダリング画像を、ゲームサーバ160のゲーム実行エンジン111上で実行されている対応するゲーム(たとえば、ゲームロジック)のインスタンスが送出してもよい。すなわち、クライアントデバイス110は、エンコード画像(たとえば、ビデオゲームの実行を通して生成されるゲームレンダリング画像からエンコードされる)を受け取るように、またディスプレイ11上でレンダリングされる画像を表示するように構成されている。一実施形態では、ディスプレイ11は、HMD(たとえば、VRコンテンツを表示する)を含む。いくつかの実施形態では、レンダリング画像を、スマートフォンまたはタブレットに、無線または有線で、クラウドベースのサービスから直接にまたはクライアントデバイス110(たとえば、プレイステーション(登録商標)リモートプレイ)を介して、ストリーミングしてもよい。
一実施形態では、ゲームサーバ160及び/またはゲームタイトル処理エンジン111には、ゲーミングアプリケーションに対応付けられるゲーム及びサービスを実行するための基本プロセッサベースの機能が含まれる。たとえば、ゲームサーバ160には、プロセッサベースの機能(たとえば、2Dまたは3Dレンダリング、物理シミュレーション、スクリプティング、オーディオ、アニメーション、グラフィックス処理、照明、シェーディング、ラスタライゼーション、レイトレーシング、シャドーイング、選抜除去、変換、人工知能など)を行うように構成された中央処理ユニット(CPU)リソース163及びグラフィックス処理ユニット(GPU)リソース265が含まれる。加えて、CPU及びGPUグループは、ゲーミングアプリケーションに対するサービス(メモリ管理、マルチスレッド管理、サービスの質(QoS)、バンド幅テスティング、ソーシャルネットワーキング、ソーシャルフレンズの管理、フレンズのソーシャルネットワークとの通信、通信チャネル、テキスティング、インスタントメッセージ、チャットサポートなどを部分的に含む)を実施してもよい。一実施形態では、1つ以上のアプリケーションは特定のGPUリソースを共有する。一実施形態では、複数のGPUデバイスを結合して、対応するCPU上で実行されている単一アプリケーションに対するグラフィックス処理を実行してもよい。
一実施形態では、クラウドゲームネットワーク190は分散ゲームサーバシステム及び/またはアーキテクチャである。詳細には、ゲームロジックを実行する分散ゲームエンジンは、対応するゲームの対応するインスタンスとして構成される。全般的に、分散ゲームエンジンは、ゲームエンジンの機能のそれぞれを取って、それらの機能を多数の処理エンティティが実行するように分配する。個々の機能をさらに、1つ以上の処理エンティティにわたって分配することができる。処理エンティティを異なる構成(たとえば、物理ハードウェア)で、及び/または仮想コンポーネントまたは仮想マシンとして、及び/または仮想コンテナとして構成してもよい。コンテナは、仮想化オペレーティングシステム上で実行されるゲーミングアプリケーションのインスタンスを仮想化するため、仮想マシンとは異なる。処理エンティティは、クラウドゲームネットワーク190のサーバ及びその基礎をなすハードウェア(1つ以上のサーバ(計算ノード)上にある)を使用し及び/またはそれらに依拠してもよい。サーバは1つ以上のラック上に配置してもよい。種々の処理エンティティに対するこれらの機能の実行の調整、割当て、及び管理は、分散同期層が行う。このように、これらの機能の実行を分散同期層が制御して、プレーヤによるコントローラ入力に応じたゲーミングアプリケーションに対する媒体(たとえばビデオフレーム、オーディオなど)の生成を可能にする。分散同期層は、これらの機能を、分散させた処理エンティティにわたって効率的に実行して(たとえば、負荷バランシングを通して)、重要なゲームエンジンコンポーネント/機能を分散させて再組立てして、より効率的な処理が行われるようにすることができる。
図2は、本開示の一実施形態による、複数のGPUが協働してデータを生成し及び/または対応するアプリケーションの単一画像をレンダリングする、典型的なマルチGPUアーキテクチャ200の略図である。明示的な説明や図示は行わないものの、本開示の種々の実施形態において、複数のGPUが協働してデータを生成し及び/または画像をレンダリングする多くのアーキテクチャが可能であることが理解されよう。たとえば、画像及び/またはデータの処理が、クラウドゲーミングシステムの1つ以上のクラウドゲーミングサーバ間で実施され得るか、または複数のGPUを有するハイエンドグラフィックスカードを含むパーソナルコンピュータまたはゲーミングコンソールなどのスタンドアロンシステム内で実施され得る場合に、マルチGPUが協働してカーネルを実行し得る。
マルチGPUアーキテクチャ200には、アプリケーションに対する単一画像及び/またはアプリケーションに対する画像列内の各画像のマルチGPUレンダリングを行うように構成されたCPU163及び複数のGPUが含まれている。詳細には、CPU163及びGPUリソース265は、プロセッサベースの機能(たとえば、前述したように、2Dまたは3Dレンダリング、物理シミュレーション、スクリプティング、オーディオ、アニメーション、グラフィックス処理、照明、シェーディング、ラスタライゼーション、レイトレーシング、シャドーイング、選抜除去、変換、人工知能など)を行うように構成されている。
たとえば、マルチGPUアーキテクチャ200のGPUリソース265には4つのGPUが示されているが、アプリケーションに対するデータを生成し及びまたは画像をレンダリングするときには任意の数のGPUを用いてもよい。各GPUは、対応する専用メモリ(たとえば、ランダムアクセスメモリ(RAM))に高速バス220を介して接続されている。詳細には、GPU-Aはメモリ210A(たとえば、RAM)にバス220を介して接続され、GPU-Bはメモリ210B(たとえば、RAM)にバス220を介して接続され、GPU-Cはメモリ210C(たとえば、RAM)にバス220を介して接続され、GPU-Dはメモリ210D(たとえば、RAM)にバス220を介して接続されている。
さらに、各GPUは、バス240を介して互いに接続されている。バス240は、アーキテクチャに応じて、対応するGPUとその対応するメモリとの間の通信に対して用いるバス220と速度がほぼ等しいかまたはそれよりも遅い場合がある。たとえば、GPU-Aは、GPU-B、GPU-C、及びGPU-Dのそれぞれと、バス240を介して接続されている。また、GPU-Bは、GPU-A、GPU-C、及びGPU-Dのそれぞれと、バス240を介して接続されている。加えて、GPU-Cは、GPU-A、GPU-B、及びGPU-Dのそれぞれと、バス240を介して接続されている。さらに、GPU-Dは、GPU-A、GPU-B、及びGPU-Cのそれぞれと、バス240を介して接続されている。
CPU163は、GPUのそれぞれと、より低速度のバス230を介して接続されている(たとえば、バス230は、対応するGPUとその対応するメモリとの間の通信に対して用いるバス220よりも遅い)。詳細には、CPU163は、GPU-A、GPU-B、GPU-C、及びGPU-Dのそれぞれと接続されている。
いくつかの実施形態では、4つのGPUは別個のGPUであり、それぞれ独自のシリコンダイ上にある。他の実施形態では、4つのGPUは、ダイ上の高速の相互配線あるいはインターコネクト及び他のユニットを利用するためにダイを共有してもよい。さらに他の実施形態では、単一のより強力なGPUとしてかまたは4つのそれほど強力でない「仮想」GPU(GPU-A、GPU-B、GPU-C、及びGPU-D)として用いるように構成することができる1つの物理GPU250がある。言い換えれば、グラフィックスパイプラインを(図4に示すように)動作させるGPU-A、GPU-B、GPU-C、及びGPU-Dそれぞれに対する十分な機能があり、チップは、全体として、グラフィックスパイプラインを(図4に示すように)動作させることができ、構成は、2つの構成の間で(たとえば、レンダリングパス間で)フレキシブルに切り替えることができる。
図3~5に、より低速度のバスを介して接続された専用メモリを有するGPUが、アイドル状態であるか、または依存関係データを用いないときに1つのGPUからのコピー動作を行うときのレイテンシーあるいはレイテンシーが増加されているという、発生し得るシナリオを例示する。
詳細には、図3は、カーネル依存関係とカーネルが処理を完了した後のデータのコピーとを示す時間軸305を例示し、カーネル(「計算カーネル」とも言う)は、画像リソースまたはバッファリソースにデータの読み書きを行い得るGPU上で実行されるプログラムである。たとえば、カーネルAがデータを生成して書き込み、そしてそれをカーネルBが読み取って処理用に用いる。カーネルA及びBを、異なるGPUによって別個に実行される作業グループまたは部分に分割し得る。説明のために、カーネルAを複数の部分に分割し得る。GPU Aに実行用にカーネルAの1つ以上の部分320Aを割り当てて、GPU Bに実行用にカーネルAの1つ以上の部分320Bを割り当てる。また、カーネルBを複数の部分に分割し得る。GPU Aに実行用にカーネルBの1つ以上の部分340Aを割り当てて、GPU Bに実行用にカーネルBの1つ以上の部分340Bを割り当てる。こうして、カーネルA及びカーネルBをそれぞれ、1つ以上のGPUによって実行し得る。
図示したように、カーネルBの1つ以上の部分がカーネルAの1つ以上の部分からのデータに依存し得る。そのため、コピー動作330を行う必要がある。詳細には、カーネルAの結果に対する高速のアクセスを望む場合、カーネルBは以前に実行したカーネルAに依存するため、カーネルAが書き込んだメモリを他のすべてのGPU(たとえば、GPU B)にコピーすることを、カーネルBが1つ以上のGPU上で実行を開始できる前に行う必要がある。すなわち、カーネルBを実行する前に、カーネルAからの作業が完了してコピーされるのを待つ必要がある。たとえば、同期点310は、コピー動作330が始まる前のカーネルAのすべての部分の完了を与える。GPU A及び/またはGPU Bに割り当てられた部分間にアンバランスな作業負荷があり得るため、GPU AまたはGPU B(またはGPU AもしくはGPU Bのいくつかの実行ユニット)は、コピー動作330が始まる前に同期点310において他の部分が処理を終了するのを待つ間、アイドル状態にあるかまたは十分に用いられていない場合がある。
さらに、同期点311において、カーネルAが書き込んだメモリを他のすべてのGPUにコピーすることが完了するまで、カーネルBのどの部分も始めることができない。なぜならば、カーネルAの実行中にどの依存関係が満たされているかが分かっておらず、またカーネルBが要求した依存関係が満たされているか否かについて不明だからである。図示したように、同期点311においてGPU AまたはGPU B上のカーネルAの部分はコピーを終了している場合があり、カーネルAのすべての部分がその対応するコピー動作330を完了するまで、GPU AまたはGPU Bはアイドル状態にある。
図4に、カーネル依存関係と、別個のカーネルの実行中にカーネルが処理を完了した後にデータをコピーする損失を隠すことと、を示す時間軸405を例示する。カーネルは、画像リソースまたはバッファリソーストにデータの読み書きを行い得るGPU上で実行されるプログラムである。たとえば、カーネルAがデータを生成して書き込み、そしてそれをカーネルCが読み取って処理用に用いる。また別個のカーネルBも必要であり得る。カーネルA、B、及びCをそれぞれ、異なるGPUによって別個に実行される作業グループまたは部分に分割し得る。説明のために、カーネルAを複数の部分に分割し得る。GPU Aに実行用に1つ以上の部分420Aを割り当てられて、GPU Bに実行用に1つ以上の部分420Bを割り当てる。また、カーネルBを複数の部分に分割し得る。GPU Aに実行用に1つ以上の部分440Aを割り当てて、GPU Bに実行用に1つ以上の部分440Bを割り当てる。さらに、カーネルCを複数の部分に分割し得る。GPU Aに実行用に1つ以上の部分450Aを割り当てて、GPU Bに実行用に1つ以上の部分450Bを割り当てる。したがって、カーネルA、B、及びCをそれぞれ、1つ以上のGPUによって実行し得る。
図示したように、カーネルCの1つ以上の部分が、カーネルAの1つ以上の部分からのデータに依存し得る。すなわち、たとえば、カーネルAの結果に対する高帯域幅のアクセスが望まれる場合に、カーネルAがデータを書き込み、それをカーネルCが読み取る。そのため、コピー動作430を行う必要がある。詳細には、カーネルCは以前に実行したカーネルAに依存するため、カーネルCが1つ以上のGPU上で実行を開始できる前に、カーネルAが書き込んだメモリを他のすべてのGPU(たとえば、GPU A及び/またはGPU B)にコピーする必要がある。前述したように、いくつかのGPUはカーネルAのすべての部分が完了するのを待ちながらアイドル状態にある場合があり、及び/またはコピー動作430が完了するまでカーネルCは実行を始められないため、カーネルAが書き込んだメモリをコピーする損失が存在し得る。
コピー動作430を他の別個の動作と一緒に行うことによって、コピー動作430の損失を隠す方法が存在し得る。たとえば、コピー動作430を、カーネルBが実行している間に行ってもよい。図示したように、同期点410は、コピー動作430が開始する前のカーネルAのすべての部分の完了を与える。この場合もやはり、GPU A及び/またはGPU Bに割り当てられた部分間にアンバランスな作業負荷があり得るため、GPU AまたはGPU Bは、コピー動作430が始まる前に同期点410において他の部分が処理を終了するのを待ちながらアイドル状態にある場合がある。コピー動作430の間に、GPU A上で実行されるカーネルBの部分440Aと、GPU B上で実行されるカーネルBの部分440Bとは、完了し得る。
同期点411において、カーネルAが書き込んだメモリを他のすべてのGPUにコピーすることが完了するまで、カーネルCのどの部分も始まることができない。なぜならば、カーネルAの実行中にどの依存関係が満たされているかが分かっておらず、またカーネルCが要求した依存関係が満たされているか否かについて不明だからである。図示したように、同期点411においてGPU AまたはGPU B上のカーネルAの部分はコピーを終了している場合があり、すべての部分がその対応するコピー動作430を完了するまでアイドル状態にある。しかし、カーネルBの実行中にコピーの損失が隠れたとしても、追加の損失がある。詳細には、カーネルCの実行の開始にレイテンシーが加わる。なぜならば、カーネルCが実行を始める前に、同期点411において完了するまでカーネルBは実行しなければならないからである。
図5に、複数のGPU間で均一に分割されたカーネルの実行を示す時間軸505を例示する。GPU間の作業負荷は異なり得る。図示したように、カーネルは、GPU A、GPU B、GPU C、及びGPU Dを含む4つのGPU間で等しく分割されている。たとえば、カーネルは画像をレンダリングするときに照明機能を実行してもよく、カーネルをピクセルの数だけ均一に分割してもよい。各GPUは、図3及び4で前述したように、実行用にカーネルの一部分を受け取って、時間軸505に沿って同期点510と520との間で他のGPUに結果をコピーする。図示したように、GPU Aは、カーネルの固有の部分を実行するカーネルインスタンス540Aを含み、その後にコピー動作545Aを行って、他のすべてのGPUに結果をコピーする。カーネルインスタンスは、対応する部分における引数に対応付けられる値を含み得る。この部分は、カーネルのインデックス空間におけるインデックス範囲によって規定される。また、GPU Bは、同じカーネルの固有の部分を実行するカーネルインスタンス540Bを含み、その後にコピー動作545Bを行って、他のすべてのGPUに結果をコピーする。GPU Cは、同じカーネルの固有の部分を実行するカーネルインスタンス540Cを含み、その後にコピー動作545Cを行って、他のすべてのGPUに結果をコピーする。最終的に、GPU Dは、同じカーネルの固有の部分を実行するカーネルインスタンス540Dを含み、その後にコピー動作545Dを行って、他のすべてのGPUに結果をコピーする。
アプリケーション開発者が複数のGPUの負荷バランシングを行って、すべてのGPU上で均等な作業負荷を実行しようと試みる場合があり、そうでない場合にはアプリケーションがアンバランスな作業負荷によるパフォーマンスの多少の損失を被る場合がある。しかし、すべてのGPU間でバランスの取れた作業負荷を予測することは難しく、特に不均質なGPUを用いる場合には難しい。例として、作業負荷(ワークロード)をあらかじめ分割し、あるいは、アプリケーションディベロッパーによって分割することは非効率的であり得る。なぜならば、作業負荷によっては、入力が異なるためにいくつかのGPU上でより時間がかかる場合があるからである。カーネルが照明機能を実行して、ピクセルの数だけGPU間で等しく分けられ得る例に従って、各ピクセルまたはピクセルのタイル(たとえば、画像バッファの一部分)に対して行われる作業負荷を予測することは難しい場合がある。なぜならば、異なるタイルに対して入力が異なる場合があるからである(たとえば、異なる数の光、異なるシェーディングモデルなど)。この結果、カーネルのいくつかの部分に対してより長い計算時間がかかる場合がある。カーネルの部分を実行するいくつかのGPUがコピーを完了して終了するのを待つ間、カーネルの部分の実行と結果のコピーを終了した他のGPUは、すべてのコピー動作が完了するのを待ちながらアイドル状態にある。たとえば、GPU A、GPU B、及びGPU Dはすべて、GPU Cがそのコピー動作を終了するのを待ちながらアイドル状態にあり、GPU Bは、同期点510及び520の間で最も長くアイドル状態にある。
図5に示すように、これらの非効率性(たとえば、すべてのGPUからのコピーを待つ時間、同期化中の空き時間、及びレイテンシーの付加)があるために、より低速度のバスを介して接続され、それぞれが専用メモリを伴うGPUは、共有メモリに高速バスを介して接続されたGPUと比べて著しい不利であり得る。画像リソースまたはバッファリソースが大きくなるにつれて、コピーに対するサイズ及び時間長さが増加することで非効率性が増すことがあり、さらなるボトルネックになる場合がある。これらの非効率性と、本開示の実施形態のデータ依存関係を用いないことの結果として、N倍の数のGPUが利用でき得たとしても、N倍のデータを処理することは難しくなる。
本開示の実施形態において、GPUを実施して、計算シェーダー機能、またはグラフィックスシェーダー(たとえば、ピクセルまたは頂点シェーダー)機能を実行してもよい。たとえば、GPUには、グラフィックスまたは非グラフィックス関連の処理を実行し得るカーネル呼び出しに加えて、画像または複数の画像のピクセルにオブジェクトをレンダリングする(たとえば、色または他のデータを書き込む)レスポンシビリティがある場合がある。1つまたは複数のコマンドバッファが、GPUが行う動作を規定する。例として、GPUが行う動作は、オブジェクトをレンダリングするために必要な描画コマンド及び状態情報を介してオブジェクトをレンダリングすることを含み得る。GPUが行う別の動作は、カーネルを実行するために必要な状態情報と共にカーネル呼び出しコマンドを介したカーネル呼び出しを含み得る。GPUが行う他の動作は、描画コマンドの完了を待つために用いる同期化コマンド、またはカーネル呼び出し、またはグラフィックスパイプライン、またはいくつかの他の状態を含み得る。さらに他の動作は、GPUの構成を含んで、カーネル呼び出し用のバッファまたは画像の構成、レンダリングターゲット(たとえば、MRT)の場所及びフォーマット、スキャンアウト、深度テスト状態などを含み得る。
GPUがコマンドを実行し、ここで、GPUはグラフィックス処理を行う(たとえば、オブジェクトをレンダリングする)か、または非グラフィックス機能を行う(たとえば、カーネル呼び出しを行っても)ように実行されてもよい。「コマンド」はGPUが読み取るデータであり、GPUはコマンドに基づいて動作を実行する。「カーネル呼び出しコマンド」は、カーネル呼び出しを実行するために用いる特定のコマンドである。「描画コマンド」は、オブジェクトをレンダリングするために用いる特定のコマンドである。
「コマンドバッファ」には1つ以上のコマンドが収められ、GPUは、コマンドを対応するコマンドバッファから読み取ることによって実行する。詳細には、GPUを、対応するコマンドバッファからコマンドを実行するように構成し得る。オブジェクトをレンダリングし及び/またはカーネルを実行するときに行うコマンド及び/または動作を、コマンド及び/または動作が他のコマンド及び/または動作に依存し得るように順序付けあるいはオーダー付けし得る(たとえばあるコマンドバッファ内のコマンドは、そのコマンドバッファ内の他のコマンドが実行できる前に、実行を完了する必要がある)。また、あるGPUが行うコマンド及び/または動作が、別のGPUが行う他のコマンド及び/または動作に依存して、それらが1つ以上のGPUによって順次行われるようであり得る。一実施形態では、各GPUはその独自のコマンドバッファを有し得る。代替的に、GPUは同じコマンドバッファまたは同じコマンドバッファセットを用い得る(たとえば、実質的に同じオブジェクトセットを各GPUがレンダリングしているときに)。
また、コマンドバッファを、マルチGPUアーキテクチャにおけるすべてのGPUまたはGPUの下位集合上で実行されるように規定し得る。マルチGPUアーキテクチャにおいて、メモリは、コマンドバッファ内のコマンドを用いることによってGPU間で明示的にコピーされ必要があり得る。コマンドバッファ内の同期化コマンドによってGPUを同期させるのではなくて、本開示の実施形態では、依存関係データを用いることによって同期化コマンドの使用頻度を最小限にする。これについては、さらに説明する。また、本開示の実施形態は、複数のGPU間での作業負荷の静的及び/または動的な負荷バランシングを行うことができる。
複数のGPUが協働して画像をレンダリングするかまたはカーネルを実行する多くのアーキテクチャが可能である。たとえば、マルチGPUアーキテクチャを、クラウドゲーミングシステムの1つ以上のクラウドゲーミングサーバ間で実施し得るか、またはスタンドアロンシステム(たとえば、複数のGPUを有するハイエンドグラフィックスカードを含むパーソナルコンピュータまたはゲーミングコンソール)内で実施し得る。一実施形態では、マルチGPUアーキテクチャの各GPUは、高速バスを介して共有メモリにアクセスでき得る。別のマルチGPUアーキテクチャにおいて、各GPUは、高速バスを介してアクセスされるローカルメモリを有し得て、他のGPUのメモリへのアクセスは低速バスを介して行い得る。これは、別の実施形態の図2に示したアーキテクチャにおいて前述したとおりである。
図6に、本開示の一実施形態による、N次元におけるカーネル呼び出し600を例示する。詳細には、「インデックス空間」はカーネル呼び出し600のために用いるN次元空間である。カーネル関数が、インデックス空間内の各ポイントまたはインデックスに対して実行される。単に説明の目的上、カーネル呼び出し600を、9x8インデックスを含む2次元空間(x及びy次元)によって表す場合がある。
カーネル呼び出し600の部分を実行用に複数のGPUに割り当てる。以前に紹介したように、カーネル呼び出し600が実行するカーネルまたは計算カーネルは、画像またはバッファを読み取るかまたは書き込むGPU上で実行されるプログラムである。カーネルは、引数及び/または使用する引数に対応付けられる値を含み得る。図示したカーネル呼び出し600は、対応するN次元のインデックス範囲に基づいて部分に分割し得る。各部分は、カーネルが用いる各次元におけるインデックス空間全体またはその下位集合であり得る。すなわち、「インデックス範囲」は、N次元のインデックス空間の一部分を規定する。1つ以上のインデックス範囲を用いて、カーネル呼び出しを部分に分割することができる。このように、「部分」はカーネルまたはカーネル呼び出し600の一部を規定する。各部分は、N次元のインデックス空間におけるインデックスまたはインデックス範囲であり得る。典型例として、カーネル呼び出し600を2つの次元に沿って6つの部分に分割する。カーネル呼び出し600の各部分には、カーネル関数を評価する12のインデックスが含まれる。たとえば、部分610は、インデックス(6,0)、(7,0)、(8,0)、(6,1)、(7,1)、(8,1)、(6,2)、(7,2)、(8,2)、(6,3)、(7,3)、及び(8,3)を含む。カーネル呼び出し600によって実行されるカーネルの1つ以上の部分は、いくつかの依存関係データに対応付けられ得る。
カーネル呼び出しによって実行されるカーネルの一部分を、メモリ資源であり得る「リソース」の領域に読み書きし得る。詳細には、リソースは、カーネルが用いる入力及び出力データを含み得る。たとえば、リソースはバッファリソースまたは画像リソースであり得て、また多次元においてまたはキューブマップとして構成し得る。いくつかの実施形態では、リソースは1、もしくは2、もしくは3次元によって規定し得るか、またはキューブマップによって規定し得る。
「領域」はリソースの一部であり、カーネルの一部分に対応付けられる。たとえば、領域は、対応するカーネル呼び出しによって実行される2Dカーネルの一部分に対応する画像の面積を規定し得る。一実施形態では、領域がリソースの下位集合に対応し、カーネルが用いる各次元を含む(たとえば、画像リソースのタイルまたはバッファ内の範囲)。たとえば、「タイル」は、画像の面積を規定するあるタイプの領域(たとえば、画像リソースの)であり得る。カーネルの対応する部分のインデックス範囲を用いて、リソースのどの領域を処理するかを決定し得る。
説明の目的上、図7Aに、24の領域に分割される画像リソース710を例示する。さらに、画像リソース710内の領域はそれぞれ、64の要素を有する。たとえば、領域(2,2)の引き伸ばした画像は8x8または64の要素を含んでいる。また説明の目的上、図7Bに、4つの領域に分割されるバッファリソース720を例示する。さらに、バッファリソース720内の領域はそれぞれ、8つの要素を有する。たとえば、領域2の引き伸ばした画像は8つの要素を含む。
図1~7で前述したマルチGPUアーキテクチャ及びそれらの実施態様の詳細な説明を用いて、図8のフロー図800に、本開示の一実施形態による、複数のGPUを用いてカーネルを処理することを含むグラフィックス処理を行うための方法を例示する。ここでは、複数のGPUが協働して画像またはデータを処理する。前述したように、種々のアーキテクチャは、複数のGPUが協働して、画像またはデータを処理することを含み得る(たとえば、クラウドゲーミングシステムの1つ以上のクラウドゲーミングサーバ内、またはスタンドアロンシステム内、たとえば、複数のGPUを有するハイエンドグラフィックスカードを含むパーソナルコンピュータまたはゲーミングコンソール内などで)。
810において、本方法は、複数のGPUを用いて複数のカーネルを実行することを含む。各カーネルは、画像またはバッファリソースに読み書きを行い得るマルチGPUアーキテクチャ上で実行されるプログラムを含む。加えて、カーネル呼び出しを用いて、対応するカーネルを実行する。カーネルは、画像またはバッファリソースにデータの読み書きを行い得る1つ以上のGPU上で実行されるプログラムである。カーネル呼び出しはインデックス空間によって規定され得る。各インデックスは、カーネルの対応する部分を実行するために用いる引数及び/または引数に対応付けられる値を含み得る。部分は、インデックス空間内のインデックス範囲によって規定される。
820において、本方法は、カーネルを実行するレスポンシビリティを複数の部分に分割することを含む。その他のレスポンシビリティを有してカーネルを実行するためには用いられないいくつかのGPUも存在し得る。
830において、本方法は、複数のGPUに複数の部分を割り当てることを含む。各部分を対応するGPUに割り当てる。詳細には、カーネル呼び出しを部分に分割する。部分は、対応するGPUに割り当てられた後に、実行される。GPUは同時に実行される。各GPUは、コマンドバッファを共有し得るか、または種々のコマンドバッファを有し得る(たとえば、各GPUは1つ以上の専用のコマンドバッファを有する)。コマンドバッファは、カーネル呼び出しコマンド、ならびに他のコマンド(たとえば、ドローコールコマンドなど)を含み得る。
図9に、本開示の一実施形態による、カーネル910の部分を実行用に複数のGPUにわたって均一に分配する固定または静的な割り当て方式を例示する。詳細には、対応するカーネル呼び出しによって実行されるカーネル910の部分は、すべてのGPU上で実行するように均一に分割される。図示したように、カーネル910の2次元のインデックス空間は24のインデックスを含み得る。カーネル910の均一な分布によって、実行用に4つのGPU(たとえばGPU A、GPU B、GPU C、及びGPU D)のそれぞれに、等量のインデックスが分配されて、6つのインデックスが各GPUに割り当てられ得る。たとえば、固定割り当て方式では、GPU Aには、6つのインデックス(0,0)、(1,0)、(2,0)、(0,1)、(1,1)、及び(2,1)が割り当てられ得る。また、GPU Bには、6つのインデックス(3,0)、(4,0)、(5,0)、(3,1)、(4,1)、及び(5,1)が割り当てられ得る。さらに、GPU Cには、6つのインデックス(0,2)、(1,2)、(2,2)、(0,3)、(1,3)、及び(2,3)が割り当てられ得る。またGPU Dには、6つのインデックス(3,2)、(4,2)、(5,2)、(3,3)、(4,3)、及び(5,3)が割り当てられ得る。割り当て方式は固定され、各部分の実行には等しい時間がかからない場合があるため、これは結果的に、GPU間でのアンバランスな作業負荷になり得る。本開示の他の実施形態では、依存関係データを用いて動的な割り当て方式を実施し得る。これについては、図10及び11A~11Bに関連して以下でさらに説明する。
図1~9で前述したマルチGPUアーキテクチャ及びそれらの実施態様の詳細な説明を用いて、図10のフロー図1000に、本開示の一実施形態による、グラフィックス処理を行うための方法を例示する。この方法では、複数のGPUを用いてカーネルを処理し、カーネル部分ごとのまたは部分ごとの領域ごとの依存関係を追跡して、後続のカーネルの依存部分の早い処理を可能にしており、複数のGPUが協働して画像またはデータを処理する。
前述したように、種々のアーキテクチャは、複数のGPUが協働して画像またはデータを処理することを含み得る(たとえば、クラウドゲーミングシステムの1つ以上のクラウドゲーミングサーバ内、またはスタンドアロンシステム内、たとえば複数のGPUを有するハイエンドグラフィックスカードを含むパーソナルコンピュータまたはゲーミングコンソール内などで)。GPUは同時に実行される。実施形態では、複数のGPUはコマンドバッファを共有し得るか、または各GPUは1つ以上の専用のコマンドバッファを有し得る。コマンドバッファは、カーネル呼び出しコマンド、ならびに他のコマンド、たとえば、ドローコールコマンドを含むことができる。
1010において、本方法は、複数のグラフィックス処理ユニット(GPU)を用いて複数のカーネルを実行することを含む。前述したように、各カーネルは、画像またはバッファリソースからデータを読み取るかまたはデータを書き込み得るマルチGPUアーキテクチャ上で実行されるプログラムを含む。加えて、カーネル呼び出しを用いて対応するカーネルを実行する。カーネル呼び出しはインデックス空間によって規定され得る。各インデックスは、カーネルの対応する部分を実行するために用いる引数及び/または引数に対応付けられる値を含み得る。その部分は、インデックス空間内の1つ以上のインデックス範囲によって規定され得る。
また、対応するカーネルを実行するレスポンシビリティを1つ以上の部分に分割する。部分はそれぞれ、対応するGPUに割り当てられる。すなわち、処理されているカーネル呼び出しを部分に分けるかまたは分割する。各部分は対応するGPUに実行用に割り当てられる。前述したように、GPUは、1つ以上のカーネルの実行を通して、協働して画像またはデータを処理する。また、カーネルが読み取るリソース(たとえばメモリ)を、1つ以上の領域に分割し得る。一部分を1つ以上のリソースの1つ以上の領域から読み取り及び/または書き込み得る。
1020において、本方法は、第1カーネルの第1の複数の部分のそれぞれが処理を完了したときに、第1カーネルにおいて複数の依存関係データを生成することを含む。すなわち、カーネルの対応する部分が処理を完了したら依存関係データを生成する。カーネル部分が実行を終了する前に(すなわち、カーネル部分のすべての命令が実行を終了する前に)、カーネル部分は依存関係データを書き込み得る。依存関係データは、カーネルの各部分によって生成され得る情報である。たとえば、情報は、カーネルの対応する部分の処理が完了したことを示し得る。別の例では、情報は、リソースの領域がカーネルの対応する部分によって書き込まれたことを示し得る。詳細には、カーネルの一部分がリソースの領域への書き込みを終了した後で、その一部分は、その一部分による領域への書き込みが完了したこと及び/またはどのGPUがその領域に書き込んだかを含む依存関係データを生成し得る。このように、画像またはバッファリソースを処理する間に、GPUにはカーネルの部分が割り当てられ、依存関係データがこれらの部分の間で追跡され得る。その結果、GPU間でのバランスされた作業負荷が可能になる。加えて、きめの細かい、領域ベースの依存関係データを生成して、カーネル間で用い得る。
1030において、本方法は、第1カーネルの1つ以上の部分から生成された依存関係データを、第2カーネルの一部分の実行の前にチェックすることを含む。詳細には、第2カーネルの一部分が読み取る必要がある1つ以上のリソースのすべての領域を、第1カーネルが完全に書き込んだことを確実にするために、第2カーネルの一部分を後に実行することが、依存関係データを待つ。たとえば、第1カーネルの一部分が生成した依存関係データが、リソースの1つ以上の領域への1つ以上の書き込みの完了、または第1カーネルの一部分の実行の完了を示す。
一実施形態では、GPUが領域に書き込むと(たとえば、第1カーネルの一部分を実行したら)、書き込まれたデータを他のGPUに送る。本開示の実施形態では、第2カーネルの一部分が要求するすべての領域が、第1カーネルの以前の実行(たとえば、第1カーネルの別の部分)によって書き込まれている場合、第2カーネルの一部分の実行は、第1カーネルの他の部分がそのコピー動作を完了することを待つことなく、及びコピーのために同期点を用いることなく、始まり得る。
別の実施形態では、GPUは、実行すべきカーネルの部分が必要とするリソースの領域をプリフェッチし得る。GPU情報(すなわち、どのGPUが依存関係データ内の領域に書き込んだか)を用いて、どのGPUからデータを読み取るかを決定し得る。場合によっては、領域データはリクエスト元のGPUのローカルメモリ内に良好に存在し得る。
1040において、本方法は、第1カーネルの対応する依存関係データが満たされない間は、第2カーネルの一部分の実行を遅らせることを含む。すなわち、第2カーネルの一部分は、依存関係データを用いてチェックして、それが必要とするすべての領域が書き込まれていることを確実にし、その後に第2カーネルの一部分は処理を始め得る。すなわち、依存関係データはカーネルの一部分が必要な領域にアクセスできるか否かを示す。詳細には、依存関係データを用いて、後のカーネル呼び出し、またはカーネルの一部分の実行(たとえば、第2カーネル)を同期させ得る。
図11Aに、本開示の一実施形態による、カーネルの一部分に基づいた依存関係データの生成を例示する。詳細には、カーネルA及びカーネルBはそれぞれ、3つの対応する部分-部分0、部分1、及び部分2に分割されている。リソース0及びリソース1はそれぞれ、3つの対応する領域-領域0、領域1、及び領域2に分割されている。
詳細には、カーネルの一部分は、その処理が完了するかまたはリソースの領域への書き込みが完了したら、依存関係データを生成し得る。たとえば、カーネルAの部分0の完了後またはリソースA及びリソースBの領域0へのカーネルAの部分0の書き込みの完了時にのみ、依存関係データが書き込まれるように、カーネルAの部分0は部分ベースの依存関係データを生成し得る。詳細には、カーネルAの部分0は、経路1110に沿ってリソース0の領域0に書き込み、また経路1115に沿ってリソース1の領域0に書き込む。その処理または領域への書き込みが完了したら、カーネルAの部分0は、経路1120が示すように、依存関係データDD0も書き込む。一実施形態では、依存関係データ(たとえばDDO、またはDD1、またはDD2)は任意のアレイ内に記憶することができる。たとえば、依存関係データをインデックス範囲内に記憶し得る。各次元をある量によってシフトまたは除算して、結果として生じる値をアレイ内へのインデックスとして用いる。
カーネルBの部分0は、依存関係データDD0が示すように、リソース0及びリソース1の両方からのデータに依存する。詳細には、カーネルBの部分0は、依存関係データDD0を待ち、そしてDD0が生成された後に、リソース0の領域0を読み取ること、及びリソース1の領域0を読み取ることができる。すなわち、カーネルBの部分0は、依存関係データDDOのステータスをチェックすることができ、DD0に、それが生成されて記憶されたときにアクセスすることができる(これを、経路1125によって示す)。カーネルBの部分0は、依存関係データを介してリソースの必要な領域のすべてにアクセスできることを判定できるため、その部分は、カーネルAの部分がその処理及びコピーを完了することを待つことなく、及び同期点を(たとえば、コピーのために)用いることなく、実行を始めることができる。
図11Bに、本開示の一実施形態による、リソースの領域及びカーネルの部分に基づいた依存関係データを例示する。詳細には、カーネルA及びカーネルBはそれぞれ、3つの対応する部分-部分0、部分1、及び部分2に分割されている。リソース0及びリソース1はそれぞれ、3つの対応する領域-領域0、領域1、及び領域2に分割されている。
依存関係データは、部分ごと及びリソースの領域ごとに生成される。詳細には、リソース(たとえば、リソースの領域)へのすべての書き込みが完了したら、カーネルの一部分は依存関係データを生成し得る。たとえば、カーネルAの部分0は、経路1130に沿ってリソース0の領域0に書き込む。リソース0の領域0へのすべての書き込みが完了したら、カーネルAの部分0は、依存関係データDD0を生成して、経路1135に沿って依存関係データ記憶する0(たとえば、アレイ)内に依存関係データDD0を記憶し得る。加えて、カーネルAの部分0は、経路1140に沿ってリソース1の領域0に書き込む。リソース1の領域0へのすべての書き込みが完了したら、カーネルAの部分0は、依存関係データDD0を生成して、経路1145に沿って依存関係データ記憶する1(たとえば、アレイ)内に依存関係データDDOを記憶し得る。
カーネルBの部分0は、リソース0及びリソース1の両方からのデータに依存している。図11Bで生成した依存関係データは、依存関係データが部分ごと及びリソースの領域ごとに生成されるため、図11Aで生成した依存関係データよりもきめが細かい場合がある。詳細には、カーネルBの部分0は、2組の依存関係データ(依存関係データ記憶する0の依存関係データDD0と依存関係データ記憶する1の依存関係データDD0とを含む)を待つ。
詳細には、カーネルBの部分0は、依存関係データ記憶する0の依存関係データDD0を待ち、そしてDD0が生成された後に、経路1150に沿ってリソース0の領域0を読み取ることができる。カーネルBの部分0は、データ記憶する0の依存関係データDD0のステータスをチェックすることができ、その依存関係データDD0に、それが生成されて記憶されたときにアクセスすることができる(これを、経路1155によって示す)。また、カーネルBの部分0は、依存関係データ記憶する1の依存関係データDD0を待ち、そしてDD0が生成された後に、経路1160に沿ってリソース1の領域0を読み取ることができる。カーネルBの部分0は、データ記憶する1の依存関係データDD0のステータスをチェックすることができ、アクセスするその依存関係データDD0に、それが生成されて記憶されたときにアクセスすることができる(これを、経路1165によって示す)。
なぜならば、カーネルBの部分0は、依存関係データ(依存関係データ記憶する0のDD0と依存関係データ記憶する1のDD0)を介してリソースの必要な領域のすべてにアクセスできることを判定できるため、その部分は、カーネルAの部分がその処理及びコピーを完了することを待つことなく、及び同期点を(たとえば、コピーのために)用いることなく、実行を始めることができる。
別の実施形態では、カーネルの一部分が、対応する領域への書き込みを終了したら、対応するリソースの領域データをすべてのGPUにプッシュし得る(すなわち、すべてのGPUのローカルメモリに送り得る)。その場合、その領域データを用いる後続のカーネルは、そのローカルメモリへのデータの到着を待ち得る。詳細には、第1GPU上で実行される第1カーネルの一部分が完了したら、第1GPUにおいて第1カーネルによって生成されたデータを第2GPUのローカルメモリに送る。
前述したように、GPUは、実行すべきカーネルの部分が必要とするリソースの領域をプリフェッチし得る。すなわち、領域データはデータが必要となる前にフェッチされ得る。詳細には、第1GPU上で実行される第1カーネルの一部分が、リソースの領域への書き込み及び対応する依存関係データの生成を終了したら、この依存関係データを待っている場合がある第2GPU上で実行される第2カーネルの一部分が、次にその領域を読み取り得る。第2GPU(第2カーネルの一部分を実行する)は、どのGPUからメモリを読み取るかを分かっている。なぜならば、その情報は依存関係データの一部であり得るからである。いくつかの実施形態では、効率的なプリフェッチは、後続部分を実行する既知の順序あるいはオーダーを用いて、それらの部分が要求するリソースのどの領域をコピーすべきかを決定する。
一実施形態では、第2GPUは、第1GPUのローカルメモリから直接領域データを、たとえば図2に示したより低速度のバスを介して読み取り得る。別の実施形態では、第2GPUは、領域データを第1GPUのローカルメモリから第2GPUのローカルメモリ内に、第2カーネルの一部分の実行の前にコピーし得る。この場合、第2カーネルの一部分は次に、そのローカルメモリから領域データを読み取ることができる。
さらなる他の実施形態では、第2GPUは、上記で概略した読み取り方法及びコピー方法の両方を用いて、第1GPUのローカルメモリから直接領域データを読み取ること、またその領域データを対応するローカルメモリから第2GPUのローカルメモリ内にコピーすることを含む。詳細には、第2カーネルの一部分の実行の開始において、第2GPUは、領域データを第1GPUのローカルメモリから第2GPUのローカルメモリへコピーすることを始める。たとえば、第1GPUによって生成されて第1GPUのローカルメモリに書き込まれたデータに、第2GPUが、ダイレクトメモリアクセス(Direct Memory Access:DMA)が完了する前にアクセスする。アクセスは、通常の読み取り動作によって第1GPUのローカルメモリから直接行われる。コピーが進んでいる間、第2GPUは第1GPUのローカルメモリから直接領域データを読み取る。すなわち、第2GPUは、第2カーネルのその一部分の早い処理を、第1GPUのローカルメモリからの直接の読み取りを行うことによって始め得る。たとえば、第1GPU上で実行される第1カーネルによって生成されて第1GPUのローカルメモリに書き込まれたデータを、DMAを介して、第2カーネルを実行する第2GPUのローカルメモリ内にフェッチする。コピーが完了する前に、第2GPUは、第1GPUから直接データを読み取る。コピーが完了した後、第2GPUは次に、第2GPUのローカルメモリから直接領域データを読み取る。たとえば、第1GPUによって生成されて第1GPUのローカルメモリに書き込まれたデータに、第2GPUが、第2GPUのローカルメモリからのDMAが完了した後にアクセスする。このように、第2カーネルの一部分を実行するために必要な領域のみを読み取り、その結果、マルチGPUアーキテクチャにわたるバンド幅が低減される。
別の実施形態では、第2カーネルの部分の実行順序が分かっている場合、第2GPUはこの順序を用いて、第2カーネルのどの部分が次に実行される可能性があるかを予測することができる。このように、第2GPUは、第2カーネルの一部分が実行前に入力として用いる1つ以上のリソースの対応する領域をプリフェッチすることができる。すなわち、第2GPUにおける第2カーネルの所定のまたは予測される順序に基づいて、第1GPU上で実行される第1カーネルによって生成されたデータを第2GPUのローカルメモリ内にプリフェッチし得る。これは、それらの領域に対する依存関係データが生成されてそれらの領域が書き込まれたことを示していることを、前提としている。カーネル部分を実行するGPUのローカルメモリ内に領域データがすでに存在する場合、この順序をもちいてローカルメモリからより速いローカルキャッシュメモリ内にプリフェッチすることができ、さらにバンド幅が増加し及び/またはレイテンシーが減る。
実施形態では、カーネルの一部分が、対応する依存関係データをチェックするとき、その一部分は、それ自体に対応付けられるインデックス範囲(たとえば、カーネル呼び出しに対応付けられる対応するインデックス空間において)及び依存関係データを生成したカーネルの一部分に対応付けられるインデックス範囲を参照する種々の戦略を用い得る。たとえば、図12A~12Dに、本開示の実施形態により、カーネルの一部分による依存関係データのチェックを典型的に例示する。依存関係データは、その一部分のインデックス範囲の何らかの関数である。当然のことながら、依存関係データのチェックのために任意の関数を用いてもよい。
明瞭及び簡潔にするために、図12A~12Dのそれぞれは、カーネルの各部分が単位サイズのインデックス範囲を有することを示している。また、図12A~12Dのそれぞれにおいて、カーネルA(図示せず)がリソースAの領域に書き込んで、関連する依存関係データを生成して記憶する。カーネルBのインデックス範囲(2,2)または(1,1)を有する部分Aは、リソースAを読み取ってリソースBに書き込む。依存関係データをチェックするための4つの異なる戦略を、図12A~12Dに示す。これにより、カーネルBの部分Aが依存関係データをチェックすることができる。
詳細には、第2カーネル(たとえば、カーネルB)の一部分の実行前に依存関係データがチェックされる第1カーネル(たとえば、カーネルA)の1つ以上の部分は、第2カーネル(たとえば、カーネルB)の一部分を含む各次元に対するインデックス範囲に依存する。一実施形態では、第1カーネル(たとえば、カーネルA)の一部分に関連する依存関係データをチェックする。一部分は、第2カーネル(たとえば、カーネルB)のそれらに対応する各次元に対するインデックス範囲(またはそのオフセット)を含む。別の実施形態では、第1カーネル(たとえば、カーネルA)の複数の部分に関連する依存関係データをチェックする。部分は、第2カーネルの各次元に対するインデックス範囲の上位集合にまとめられる各次元に対するインデックス範囲を含む。さらなる他の実施形態では、第1カーネル(たとえば、カーネルA)の部分に関連する1つ以上の依存関係データをチェックする。1つ以上の部分は、第2カーネル(たとえば、カーネルB)のインデックス範囲を用いて計算された関数である各次元に対する少なくとも1つのインデックス範囲を含む。
詳細には、図12Aに、本開示の一実施形態による、カーネルBの部分Aによる依存関係データ(その部分のインデックス範囲(たとえば2,2)に対応する)のチェックを例示する。たとえば、カーネルBの部分Aは、対応するインデックス空間におけるインデックス範囲(2,2)に対応付けられる。また、図12Aに示すように、カーネルBの部分Aは、リソースBの領域(2,2)に書き込む。カーネルBの部分AがリソースAにおいて読み取るかまたは書き込んだ領域と、その同じデータまたはその何らかの関数が書き込まれたリソースB内に配置された領域との間に1対1の変換が存在する。すなわち、出力データを受け取るリソースBの領域(2,2)は、データを読み取られたリソースAの領域(2,2)と同じ場所である。言い換えれば、領域インデックス(リソースAの(2,2))と部分インデックス(カーネルBの(2,2))との間に1対1の関係が存在する。
図12Bに、本開示の一実施形態による、インデックス範囲に対応付けられるカーネルBの部分Aによる依存関係データの複数のピースのチェックを例示する、詳細には、カーネルBの部分Aのインデックス範囲(2,2)または部分IDのうちの1つの半径内にあるインデックス範囲に対応する依存関係データをチェックされる。たとえば、カーネルBの部分Aはフィルタ関数であり得る。フィルタ関数では、中心ピクセル(たとえば、カーネルBの部分Aのインデックス範囲に関連するリソースAの領域(2,2)に対応する)を囲む複数の領域が読み取られてフィルタリングされ、リソースBの領域(2,2)に出力される。すなわち、フィルタ関数は、カーネルBの部分Aのインデックス範囲(たとえば、部分ID)を囲むサンプリング領域を規定する。図示したように、データを読み取るサンプリング領域は、リソースAの領域(1,1)、(2,1)、(3,1)、(1,2)、(2,2)、(3,2)、(1,3)、(2,3)、及び(3,3)を含む。関数から生成されている出力は、リソースBの領域(2,2)内に記憶される。
図12Cに、本開示の一実施形態による、カーネルBの部分Aによる依存関係データのチェックを例示する。依存関係データは、その部分のインデックス範囲の関数である。詳細には、カーネルBの部分Aのインデックス範囲(1,1)または部分IDの関数に基づいて、依存関係データをチェックする。この場合、関数は、部分A、カーネルBのインデックス範囲(1,1)を2倍にして、右及び下方向におけるその隣接物を取ることである。図示したように、サンプリングされて読み取られる領域は、リソースAの領域(2,2)、(3,2)、(2,3)、及び(3,3)を含む。関数から生成されている出力はリソースBの領域(1,1)内に記憶する。すなわち、関数はダウンサンプリング操作を表している。
図12Dに、本開示の一実施形態による、カーネルBの部分Aによる依存関係データのチェックを例示する。依存関係データは、その部分のインデックス範囲の関数である。関数はその部分のインデックス範囲のオフセットである。詳細には、カーネルBの部分Aのインデックス範囲(2,2)または部分IDの関数に基づいて、依存関係データをチェックする。この場合、関数は、部分A、カーネルBのインデックス範囲(2,2)を上向き方向にオフセットすることである。図示したように、サンプリングされて読み取られる領域は、リソースAの領域(2,1)である。関数から生成されている出力はリソースBの領域(2,2)内に記憶する。
カーネルのインデックス範囲の一部分の関数を用いると、規定のインデックス空間の外にあるインデックスになり得る。これらの場合では、さらなる動作を行い得る。詳細には、図13A~Cに、本開示の実施形態による、カーネルの一部分のインデックス範囲の関数が規定のインデックス空間の外にあるときに対処するための種々の戦略を例示する。
明瞭及び簡潔にするために、図13A~13Cのそれぞれは、単位サイズのインデックス範囲(たとえば、「単位」インデックス範囲)を有するカーネルの各部分を示す。また、図13A~13Cのそれぞれにおいて、カーネルAはリソースAの領域に書き込み、関連する依存関係データを生成して記憶する。カーネルBのインデックス範囲(2,2)を有する部分Aは、リソースAを読み取ってリソースBに書き込む。第1カーネルの一部分に対するインデックス範囲がそのインデックス空間の外にある場合の異なる戦略を、図13A~13Cに示す。具体的には、(-3,-1)のオフセットを、単位インデックス範囲(2,2)に適用する。その結果、第1の次元(たとえば、水平方向またはx方向)においてインデックス空間の外にある(-1,1)の単位インデックス範囲となる(図13Cにも示す)。
図13Aに、本開示の一実施形態による、カーネルBの部分Aのインデックス範囲に適用されたオフセット(たとえば、関数)が規定のインデックス空間から外れたときに、インデックス範囲の1つの次元をクランプすることを例示する。オフセットは、リソースAにおける同様の次元の対応する領域に変換される。詳細には、カーネルAの一部分に対するオフセットインデックス範囲、上位集合インデックス範囲、または計算されたインデックス範囲がインデックス空間の外にある場合、カーネルAが生成した依存関係データを、インデックス空間の外にある次元において有効範囲にクランプされたインデックス範囲に対応するカーネルAの一部分についてチェックする。クランピングによって、結果として生じるインデックス範囲(0,1)がインデックス空間内にあることが確実になる。たとえば、インデックス範囲を水平方向またはx方向においてその最初の値の0にクランプして、依存関係データがリソースAの領域(0,1)についてチェックされるようにする。
図13Bに、本開示の一実施形態による、カーネルBの一部分のインデックス範囲に適用されたオフセット(たとえば、関数)が規定のインデックス空間から外れたときに、インデックス範囲の1次元においてラッピングすることを例示する。オフセットは、リソースAにおける同様の次元の対応する領域に変換される。詳細には、カーネルAの一部分に対するオフセットインデックス範囲、上位集合インデックス範囲、または計算されたインデックス範囲がインデックス空間の外にある場合、カーネルAが生成した依存関係データを、インデックス空間の外にある次元において有効範囲にラッピングされたインデックス範囲に対応するカーネルAの一部分についてチェックする。詳細には、インデックス範囲を(5,1)にラッピングする。ラッピングによって、結果として生じるインデックス範囲(5,1)がインデックス空間内にあることが確実になる。一実施形態では、値を、その方向のインデックス空間のサイズを伴うインデックスの符号なしモジュロとして選択する。ラッピングを行うときには他の方法が好適である。たとえば、インデックス範囲を水平方向またはx方向においてその最大値の5にラッピングして、依存関係データがリソースAの領域(5,1)についてチェックされるようにする。
図13Cに、本開示の一実施形態による、カーネルの一部分のインデックス範囲に適用されたオフセット(たとえば、関数)が規定のインデックス空間から外れたときに、依存関係データを無視することを例示する。詳細には、カーネルAが生成した依存関係データを無視する。そのようにして、カーネルBの一部分は、依存関係データを待たないと決定するか、またはカーネルBのその部分を実行しない、またはそれを何らかの他の方法で取り扱うことを決定し得る。
いくつかの実施形態では、依存関係データに対するインデックス範囲を読み取るために行う関数、及び結果が規定のインデックス空間の外にある場合に行う動作は、リソースごと及びカーネルごとに異なり得る。すなわち、関数は、関連するリソース及びカーネルに基づき得る。
図14Aに、本開示の一実施形態による、動的な割り当て方式を例示する。ここでは、カーネルの部分を実行用に複数のGPUに割り当てるときに、異なるGPUが異なる空間充填曲線(space filling curves: SFC)に続く。詳細には、カーネルの部分をGPUに動的に割り当てる。単一のGPUにカーネルの固有の部分に対する割り当てを与えて、どの部分も実行用に1つの対応するGPUに割り当てられるようにする。図示したように、カーネルの2次元のインデックス空間1410は24のインデックスを含み得る。
動的な割り当て方式を用いることができ、GPUがカーネルの部分を実行できるようになる(たとえば、実行に利用できる)と、カーネルの部分をGPUに割り当てられる。カーネルの各部分を実行するレスポンシビリティをただ1つのGPUに割り当てて、カーネルの実行中にカーネルの部分をGPUに動的に割り当てる。すなわち、カーネルの部分の割当ては、GPUごとに異なり得る所定の順序(たとえば、空間充填曲線)を参照し得る。図14Aは、1つ以上の所定の順序または空間充填曲線を表しているが、当然のことながら、他のアクセスパターンに対しては他の順序の方が効率的な場合がある。詳細には、各GPUに割り当てられた部分の局所性を実現するために、順序はGPUごとに異なり得る。利点として、GPUごとに異なる順序を用いたときであっても、同じGPU上で複数のカーネルに対して同じ順序を(たとえば、連続して)用いると、他のGPUの他のローカルメモリからデータをフェッチする必要が減る。なぜならば、部分の局所性によって、データがそのGPU内に存在し得るからである。図14Aに示すように、カーネルの部分を、各GPUに対する既知の所定の順序を用いて、対応するGPUに割り当てようと試みる。
図14Aに、複数の順序付けまたは空間充填曲線(それぞれ、GPUに対応している)を示す。たとえば、GPU Aは、インデックス空間1410のインデックス範囲(0,1)で始まる空間充填曲線1420に従い、インデックス範囲をほぼ時計回りにチェックして、インデックス範囲(0,2)で終了する。説明のために、空間充填曲線1420は、カーネルの部分を以下の順序で割り当てようと試みている。(0,1)、次に(0,0)、次に(1,0)、次に(1,1)、次に(2,1)など。また、GPU Bは、インデックス空間1410のインデックス範囲(5,1)で始まる空間充填曲線1425に従い、インデックス範囲をほぼ反時計回りにチェックして、インデックス範囲(5,2)で終了する。説明のために、空間充填曲線1425は、カーネルの部分を以下の順序で割り当てようと試みている。(5,1)、次に(5,0)、次に(4,0)、次に(4,1)、次に(3,1)など。さらに、GPU Cは、インデックス空間1410のインデックス範囲(0,2)で始まる空間充填曲線1430に従い、インデックス範囲をほぼ反時計回りにチェックして、インデックス範囲(0,1)で終了する。説明のために、空間充填曲線1430は、カーネルの部分を以下の順序で割り当てようと試みている。(0,2)、次に(0,3)、次に(1,3)、次に(1,2)、次に(2,2)など。
また、GPU Dは、インデックス空間1410のインデックス範囲(5,2)で始まる空間充填曲線1435に従い、インデックス範囲をほぼ時計回りにチェックして、インデックス範囲(5,1)で終了する。説明のために、空間充填曲線1435は、カーネルの部分を以下の順序で割り当てようと試みている。(5,2)、次に(5,3)、次に(4,3)、次に(4,2)、次に(3,2)など。
一実施形態では、カーネルの一部分が、バッファリソースまたは画像リソースにおいて空間的に互いに近接した複数の領域を、連続パスにおける入力として用いるときに、GPUごとの部分局所性に対して最適化された1つ以上の空間充填曲線によって、他のGPUのローカルメモリからデータをフェッチする必要が減る。詳細には、カーネルの部分を割り当てるときの対応するGPUが参照する所定の順序は、カーネルまたは対応するカーネル呼び出しの次元内で規定される空間充填曲線であり得る。
一実施形態では、対応する割り当て順序に沿った進行(たとえば、空間充填曲線に対する開始からの距離)を、複数のGPU間で共有することができる。この進行によって、すでに割り当てられている一部分をGPUが割り当てようとする必要がないように、カーネルのどの部分がすでに各GPUに割り当てようと試みられたかをチェックする効率的な方法が得られる。
図14Bに、本開示の一実施形態による、図14Aで規定したGPU空間充填曲線において輪郭が描かれた割り当ての順序に従うカーネルの部分の割り当てを例示する(たとえば、GPU Aに対する曲線1420、GPU Bに対する曲線1425、GPU Cに対する曲線1430、及びGPU Dに対する曲線1435)。各GPUは、部分を同時に、たとえばステップ刻みで割り当てる。空間充填曲線は種々のインデックス範囲で始まるため、各GPUに当初は、実行用の対応するカーネルの一部分が割り当てられる。たとえば、ステップ1では、GPU Aにはインデックス空間1410の部分(0,1)が割り当てられ、GPU Bには部分(5,1)が割り当てられ、GPU Cには部分(0,2)が割り当てられ、及びGPU Dには部分(5,2)が割り当てられる。
部分によっては、完了までの時間が他よりも長い場合があるため(たとえば、入力値などに応じて)、GPUによっては、インデックス空間1410から割り当てられる部分がより多い状態で終わる。たとえば、GPU Cは、ステップ1~3上で部分(0,2)を実行し続けて、ステップ2またはステップ3では何らさらなる部分は割り当てられないが、GPU A、GPU B、及びGPU Dはそれぞれ、ステップ2及びステップ3のそれぞれにおいてさらなる部分が割り当てられている。
場合によっては、GPUは2つ以上の部分を割り当てることができる。たとえば、ステップ4では、GPU Aは3つのさらなる部分(たとえば、部分(1,1)、(2,1)、及び(2,0))を割り当てることができる。また、ステップ4では、GPU Bは2つのさらなる部分(たとえば、部分(4,1)及び(3,1))を割り当てることができる。
図14Bに示すように、GPUはそれぞれ、部分が互いに局在化されるように、局所性によって部分が割り当てられている。場合によっては、GPUは、局在化に対する希望に従って、割り当てができない場合がある。たとえば、ステップ5では、GPU Bが、両方の部分(3,0)、(2,0)、(2,1)を割り当てるようと試みるが、これらの部分はそれぞれ、GPU A及び/またはGPU Cによってすでに割り当てられている。空間充填曲線1425に従ってすでに割り当てられているわけではないGPU Bが利用できる最初の部分は、部分(1,2)である。すなわち、GPU Bは、GPUにすでに割り当てられているわけではない所定の順序または空間充填曲線1425に沿って次の部分を割り当てる。
図1~14で前述したマルチGPUアーキテクチャ及びそれらの実施態様の詳細な説明を用いて、図15のフロー図1500に、本開示の一実施形態による、アプリケーションに対する画像のマルチGPUレンダリングを含むグラフィックス処理を行うための方法を例示する。依存関係データはカーネル処理及び/またはドローコール実行に基づき得る。複数のGPUが協働して画像またはデータを処理する。前述したように、種々のアーキテクチャは、複数のGPUが協働して画像またはデータを処理することを含み得る(たとえば、クラウドゲーミングシステムの1つ以上のクラウドゲーミングサーバ内、またはスタンドアロンシステム内、たとえば、複数のGPUを有するハイエンドグラフィックスカードを含むパーソナルコンピュータまたはゲーミングコンソール内などで)。GPUは同時に実行される。実施形態では、複数のGPUは1つ以上のコマンドバッファを共有し得るか、または各GPUは1つ以上の専用のコマンドバッファを有し得る。コマンドバッファは、カーネル呼び出しコマンド、ならびに他のコマンド(たとえば、ドローコールコマンド)、またはカーネル呼び出しコマンドとドローコールコマンドとの両方の組み合わせを含むことができる。
1510において、本方法は、複数のグラフィックス処理ユニット(GPU)を用いて画像をレンダリングすることを含む。たとえば、協働して画像及び/またはデータを生成する複数のGPUを用いて、グラフィックスをアプリケーションに対してレンダリングし得る。単一画像及び/またはリアルタイムアプリケーションに対する画像列のうちの1つ以上の画像のそれぞれをレンダリングするときに、マルチGPU処理を行う。
1520において、本方法は、複数のGPU上で複数のカーネルを実行することを含む。対応するカーネルを実行するレスポンシビリティを1つ以上の部分に分割し、各部分を対応するGPUに割り当てる。
1530において、本方法は、複数のGPU上で複数のドローコールを実行することを含む。対応するドローコールを実行するレスポンシビリティを1つ以上の部分に分割し、各部分を対応するGPUに割り当てる。詳細には、描画コマンドを介して画像をレンダリングするときに、対応する描画コマンドを部分に分割し得る(カーネルの呼び出しを部分に分割するのに類似する方法で)。各部分がたった1つのGPUに割り当てられるように、各部分をGPUに割り当てる。このように、各GPUは、同じGPUに割り当てられたドローコールの部分をレンダリングする。加えて、ドローコールの各部分は依存関係データを生成し得る(たとえば、ドローコールの一部分の完了時に依存関係データを生成し得る)。
一実施形態では、ドローコールの部分及び/またはカーネルの部分の間で依存関係チェックがあり得る。すなわち、ドローコールの一部分はカーネルの1つ以上の部分に依存するか、またはカーネルの一部分はドローコールの1つ以上の部分に依存する。依存関係データをカーネルの一部分が生成し得るか、またはドローコールの一部分が生成し得る。
1540において、本方法は(任意選択で)、カーネルの一部分の実行の前に、カーネルにおいて、ドローコールの1つ以上の部分の依存関係データをチェックすることを含む。詳細には、カーネルの部分は、ドローコールの部分が生成した依存関係データをチェックして、適切な処置を取り得る(たとえば、カーネルの対応する部分の実行を、対応するドローコールの部分が完了するまで一時停止する)。
1550において、本方法は(任意選択で)、ドローコールの一部分の実行の前に、ドローコールにおいて、カーネルの1つ以上の部分の依存関係データをチェックすることを含む。詳細には、ドローコールの各部分は、依存関係データをチェックして(たとえば、依存関係が満たされるまで処理しない)、及び/または依存関係データを生成し得る(たとえば、ドローコールの一部分の完了時に依存関係データを生成する)。一実施形態では、ドローコールの部分は、カーネルの部分が生成した依存関係データをチェックして、適切な処置を取り得る(たとえば、描画コマンドの対応する部分の実行を、対応するカーネルの一部分が完了するまで一次停止する)。
図16に、本開示の種々の実施形態の態様を実行するために使用できるデバイス例1600のコンポーネントを例示する。たとえば、図16に、本開示の実施形態による、カーネルの実行に適した典型的なハードウェアシステムを例示する。複数のグラフィックス処理ユニット(GPU)が協働して画像またはデータを処理する。このブロック図で例示するデバイス1600は、パーソナルコンピュータ、サーバコンピュータ、ゲーミングコンソール、モバイルデバイス、または他のデジタルデバイス(それぞれ、本発明の実施形態を実行するのに適している)を組み込むことができるかまたはそれらとすることができる。デバイス1600は、ソフトウェアアプリケーション及び随意的にオペレーティングシステムを実行するための中央処理ユニット(CPU)1602を含んでいる。CPU1602は、1つ以上の同種または異種の処理コアから構成され得る。
種々の実施形態により、CPU1602は1つ以上の処理コアを有する1つ以上の汎用マイクロプロセッサである。さらなる実施形態を、ゲームの実行中にグラフィックス処理を行うように構成されたアプリケーションの高並列で計算集約型のアプリケーション(たとえば、媒体及びインタラクティブエンターテインメントアプリケーション)に具体的に適応されたマイクロプロセッサアーキテクチャを伴う1つ以上のCPUを用いて実施することができる。
メモリ1604は、CPU1602及びGPU1616が用いるアプリケーション及びデータを記憶する。記憶装置1606は、アプリケーション及びデータ用の不揮発性記憶装置及び他のコンピュータ可読媒体であり、固定ディスクドライブ、リムーバブルディスクドライブ、フラッシュメモリ装置、及びCD-ROM、DVD-ROM、ブルーレイ、HD-DVD、または他の光学記憶装置、ならびに信号伝送及び記憶媒体を含んでいてもよい。ユーザ入力デバイス1608は、1人以上のユーザからのユーザ入力をデバイス1600に伝達する。その例としては、キーボード、マウス、ジョイスティック、タッチパッド、タッチスクリーン、スチールまたはビデオレコーダ/カメラ、及び/またはマイクロフォンを挙げてもよい。ネットワークインターフェース1609によって、デバイス1600は、電子通信ネットワークを介して他のコンピュータシステムと通信することができる。ネットワークインターフェース1609としては、ローカルエリアネットワーク及びワイドエリアネットワーク(たとえば、インターネット)を介した有線または無線通信を挙げてもよい。オーディオプロセッサ1612は、CPU1602、メモリ1604、及び/または記憶装置1606が提供する命令及び/またはデータからアナログまたはデジタルオーディオ出力を生成するように適応されている。デバイス1600のコンポーネント(たとえば、CPU1602、グラフィックスサブシステム、たとえば、GPU1616、メモリ1604、データ記憶装置1606、ユーザ入力デバイス1608、ネットワークインターフェース1609、及びオーディオプロセッサ1612)は、1つ以上のデータバス1622を介して接続されている。
グラフィックスサブシステム1614がさらに、データバス1622及びデバイス1600のコンポーネントと接続されている。グラフィックスサブシステム1614は、少なくとも1つのグラフィックス処理ユニット(GPU)1616及びグラフィックスメモリ1618を含んでいる。グラフィックスメモリ1618は、出力画像の各ピクセルに対するピクセルデータを記憶するために用いるディスプレイメモリ(たとえば、フレームバッファ)を含んでいる。グラフィックスメモリ1618は、GPU1616と同じデバイスに統合すること、個別のデバイスとしてGPU1616と接続すること、及び/またはメモリ1604内で実施することができる。ピクセルデータをCPU1602から直接グラフィックスメモリ1618に提供することができる。代替的に、CPU1602は、GPU1616に、所望の出力画像を規定するデータ及び/または命令を提供する。所望の出力画像から、GPU1616が1つ以上の出力画像のピクセルデータを生成する。所望の出力画像を規定するデータ及び/または命令を、メモリ1604及び/またはグラフィックスメモリ1618に記憶することができる。一実施形態では、GPU1616は、シーンに対するジオメトリ、照明、シェーディング、模様付け、動き、及び/またはカメラパラメータを規定する命令及びデータから、出力画像用のピクセルデータを生成するための3Dレンダリング能力を含む。GPU1616はさらに、シェーダープログラムを実行することができる1つ以上のプログラマブル実行ユニットを含むことができる。
グラフィックスサブシステム1614は、グラフィックスメモリ1618から、ディスプレイデバイス1610上に表示すべき、または投影システム(図示せず)によって投影すべき画像用のピクセルデータを定期的に出力する。ディスプレイデバイス1610は、デバイス1600からの信号に応じて視覚情報を表示することができる任意のデバイスとすることができる。たとえば、CRT、LCD、プラズマ、及びOLEDディスプレイである。デバイス1600は、ディスプレイデバイス1610に、たとえば、アナログまたはデジタル信号を提供することができる。
グラフィックスサブシステム1614を最適化するための他の実施形態は、複数のGPUを用いてカーネルを処理し、カーネル部分ごとの依存関係を追跡して、後続のカーネルの依存部分の早い処理を可能にすることを含むことができる。複数のGPUが協働して画像またはデータを処理する。グラフィックスサブシステム1614を、1つ以上の処理デバイスとして構成することができる。
たとえば、一実施形態では、グラフィックスサブシステム1614を、レンダリング中の領域テストによってアプリケーションに対するジオメトリのマルチGPUレンダリングを行うように構成してもよい。複数のグラフィックスサブシステムが、グラフィックスを実施していることができ、及び/または単一アプリケーションに対するパイプラインをレンダリングしていることができる。すなわち、グラフィックスサブシステム1614は、アプリケーションを実行するときに画像または画像列の1つ以上の各画像をレンダリングするために用いる複数のGPUを含んでいる。
他の実施形態では、グラフィックスサブシステム1614は複数のGPUデバイスを含んでいる。これらは、対応するCPU上で実行されている単一アプリケーションに対するグラフィックス処理を実行するために結合される。たとえば、複数のGPUは、画像に対するオブジェクトのレンダリング中の領域テストによってアプリケーションに対するジオメトリのマルチGPUレンダリングを行うことができる。他の例では、複数のGPUは交互形式のフレームレンダリングを実行することができる。ここでは、GPU1が第1のフレームをレンダリングし、GPU2が第2のフレームをレンダリングして、これを連続的なフレーム周期で行うことなどを、最後のGPUに達するまで続ける。その上で、最初のGPUが次のビデオフレームをレンダリングする(たとえば、2つのGPUのみが存在する場合には、GPU1が第3のフレームをレンダリングする)。すなわち、フレームをレンダリングするときにGPUが回転する。レンダリング動作はオーバーラップすることができる。GPU1が第1のフレームのレンダリングを終了する前に、GPU2が第2のフレームのレンダリングを開始してもよい。別の実施態様では、複数のGPUデバイスに、レンダリング及び/またはグラフィックスパイプラインにおいて異なるシェーダー動作を割り当てることができる。マスタGPUが主なレンダリング及び合成を行っている。たとえば、3つのGPUを含むグループでは、マスタGPU1が、スレーブGPU2及びスレーブGPU3からの出力の主なレンダリング(たとえば、第1のシェーダー動作)及び合成を実行することができる。スレーブGPU2は、第2のシェーダー(たとえば、河などの流体効果)動作を実行することができ、スレーブGPU3は、第3のシェーダー(たとえば、粒子煙)動作を実行することができる。マスタGPU1は、GPU1、GPU2、及びGPU3のそれぞれからの結果を合成する。このように、異なるシェーダー動作(たとえば、旗を振ること、風、発煙、火災など)を実行するために異なるGPUを割り当てて、ビデオフレームをレンダリングすることができる。さらなる他の実施形態では、3つのGPUをそれぞれ、ビデオフレームに対応するシーンの異なるオブジェクト及び/または部分に割り当てることができる。前述の実施形態及び実施態様では、これらの動作を同じフレーム周期(同時に並列)でまたは異なるフレーム周期(順次に並列)で行うことができる。
したがって、本開示では、アプリケーションを実行するときの画像または画像列内の1つ以上の各画像に対するオブジェクトのレンダリング中の領域テストによってアプリケーションに対するジオメトリのマルチGPUレンダリングを行うように構成された方法及びシステムを説明している。
当然のことながら、本明細書で規定した種々の実施形態を、本明細書で開示した種々の特徴を用いて具体的な実施に結合するかまたは組み立ててもよい。したがって、提供した例は単にいくつかの可能な例であり、種々の要素を結合してさらに多くの実施態様を規定することによって可能な種々の実施態様に限定されない。いくつかの例では、開示した実施態様または同等な実施態様の趣旨から逸脱することなく、いくつかの実施態様にはもっと少ない要素が含まれていてもよい。
本開示の実施形態は、種々のコンピュータシステム構成(たとえば、ハンドヘルドデバイス、マイクロプロセッサシステム、マイクロプロセッサベースまたはプログラマブル民生用エレクトロニクス、ミニコンピュータ、メインフレームコンピュータなど)によって実施してもよい。また本開示の実施形態は、分散コンピューティング環境において実行することもできる。ここでは、タスクが、有線ベースまたは無線ネットワークを通してリンクされたリモート処理デバイスによって行われる。
前述の実施形態を念頭において、当然のことながら、本開示の実施形態は、コンピュータシステムに記憶されたデータを伴う種々のコンピュータ実装動作を用いることができる。これらの動作は、物理量の物理的な操作を必要とするものである。本開示の実施形態の一部分を構成する本明細書で説明した動作のいずれも、有用なマシン動作である。また本開示の実施形態は、これらの動作を行うためのデバイスまたは装置に関する。装置は必要な目的に対して特別に構成することもできるし、または装置を、コンピュータに記憶されたコンピュータプログラムによって選択的に作動または構成される汎用コンピュータとすることもできる。詳細には、種々の汎用マシンを本明細書の教示により書き込まれたコンピュータプログラムによって用いることもできるし、または必要な動作を実行するためにもっと特化された装置を構成することがより好都合であり得る。
また本開示を、コンピュータ可読媒体上のコンピュータ可読コードとして具体化することができる。コンピュータ可読媒体は、データを記憶することができる任意のデータ記憶装置とすることができる。データはその後にコンピュータシステムによって読み取ることができる。コンピュータ可読媒体の例としては、ハードドライブ、ネットワーク接続ストレージ(NAS)、読み取り専用メモリ、ランダムアクセスメモリ、CD-ROM、CD-R、CD-RW、磁気テープ、ならびに他の光学及び非光学データ記憶装置が挙げられる。コンピュータ可読媒体としては、コンピュータ可読コードが分散的に記憶及び実行されるようにネットワーク結合コンピュータシステム上に分散されたコンピュータ可読有形的表現媒体を挙げることができる。
本方法の動作を特定の順序で説明したが、当然のことながら、動作の合間に他のハウスキーピング動作を行ってもよいし、または動作を調整してわずかに異なる時間に行われるようにしてもよいし、またはシステム内で分散させて、オーバーレイ動作の処理が所望の方法で行われる限り、処理動作を処理に対応付けられる種々の間隔で行えるようにしてもよい。
前述の開示内容は、理解を明瞭にするために少し詳しく説明しているが、添付の請求項の範囲内で特定の変形及び変更を実施できることが明らかである。したがって、本実施形態は例示的であって限定的ではないと考えるべきであり、本開示の実施形態は、本明細書で示した詳細に限定してはならないが、添付の請求項の範囲及び均等物内で変更してもよい。