(57)【特許請求の範囲】
【請求項１】
複数の並列スレッドを実行するための方法であって、
（ａ）前記複数の並列スレッドを少なくとも２つのワークグループにグループ化することであって、各ワークグループはプロセッサのプロセッサコアに割り当てられることと、
（ｂ）前記少なくとも２つのワークグループからの第１のワークグループを、第１のプロセッサコア上で実行するように構成された第１のオペレーティングシステムスレッドに関連付けることと、
（ｃ）第２のプロセッサに関連するメモリ階層を前記第１のプロセッサコアに関連するメモリにマッピングすることと、
（ｄ）前記第１のオペレーティングシステムスレッド内の前記第１のワークグループからの並列スレッドをスケジューリングすることであって、前記スケジューリングすることは、前記第１のワークグループからの前記並列スレッドを同期点に至るまで実行するように構成することと、前記第１のワークグループからの前記並列スレッドの全てが前記同期点に達した後に、前記第１のワークグループからの前記並列スレッドの各々を、前記同期点からの実行を再開するように構成することとを含む、ことと、
を備えた方法。
【請求項２】
ステップ（ｄ）は、
前記第１のワークグループからの前記並列スレッドを、スレッドのサブセットにグループ化することと、
前記プロセッサコアによって実行される第１のサブセットを、前記サブセットから構成することと、
前記第１のサブセットが実行を完了した後に、前記プロセッサコアによって実行される第２のサブセットを、前記サブセットから構成することとを備える請求項１の方法。
【請求項３】
前記少なくとも２つのワークグループからの第２のワークグループを、第２のプロセッサコア上の第２のオペレーティングシステムスレッドに関連付けることと、
前記第２のオペレーティングシステムスレッド内の前記第２のワークグループからの並列スレッドを構成することとを更に備え、
前記第１及び第２のワークグループは同時に実行される、請求項１の方法。
【請求項４】
ステップ（ｄ）は、
前記同期点に達した場合に前記第１のワークグループからの前記並列スレッドごとの状態を保存することと、
前記実行を再開するのに先立ち前記第１のワークグループからの前記並列スレッドごとの前記状態を回復することとを更に備える請求項１の方法。
【請求項５】
前記第１のワークグループからの前記並列スレッドのための同期点を定義することを備え、前記定義することは、前記第１のワークグループからの前記並列スレッドのためのコード内に同期呼び出しを挿入することを備える請求項１の方法。
【請求項６】
前記第１のプロセッサコアは制御処理ユニット（ＣＰＵ）コアである請求項１の方法。
【請求項７】
前記第１のワークグループの前記並列スレッドはグラフィクス処理ユニット（ＧＰＵ）カーネルである請求項１の方法。
【請求項８】
前記マッピングすることは、
前記第１のプロセッサコアに結合されるシステムメモリ内の複数の第１の領域を割り当てることと、
前記第１のプロセッサコアに結合されるシステムメモリ内の複数の第２の領域を割り当てることとを備え、
前記第１の領域の各々は前記第１のワークグループからの１つのスレッドによってアクセス可能なプライベートメモリに対応し、各前記第２の領域は前記第１のワークグループからの全部のスレッドに関連するローカルメモリに対応する請求項１の方法。
【請求項９】
前記マッピングすることは、
前記複数の第１の領域からの第１の領域の各ペアの間にガードページを割り当てることと、
前記複数の第２の領域からの第２の領域の各ペアの間にガードページを割り当てることとを更に備える請求項８の方法。
【請求項１０】
前記マッピングすることは、前記第１のプロセッサコアに結合されるキャッシュメモリ内にキャッシュ領域を形成することを更に備え、
前記キャッシュ領域は前記第１の領域の少なくとも１つ及び第２の領域の内容を備える請求項８の方法。
【請求項１１】
グラフィクス処理ユニット（ＧＰＵ）カーネルを実行するための方法であって、
ＧＰＵ上での実行のために前もって構成された前記ＧＰＵカーネルであって前記ＧＰＵ上の複数の並列スレッドをインスタンス化するように構成される前記ＧＰＵカーネルをホストプロセッサにロードすることと、
前記複数の並列スレッドを少なくとも２つのワークグループにグループ化することであって、各ワークグループは前記ホストプロセッサのプロセッサコアに割り当てられることと、
第１のワークグループを、前記ホストプロセッサコアに結合された第１のプロセッサコアの第１のオペレーティングスレッドに関連付けることであって、前記第１のオペレーティングスレッドは、前記プロセッサコアのうち１つのプロセッサコア上でのみ実行するように構成されていることと、
前記ＧＰＵに関連するメモリ階層を、前記プロセッサコアに関連するシステムメモリにマッピングすることと、
前記第１のオペレーティングシステムスレッド内の前記第１のワークグループからの並列スレッドをスケジューリングすることであって、前記スケジューリングすることは、前記第１のワークグループからの前記並列スレッドを同期点に至るまで実行するように構成することと、前記第１のワークグループからの前記並列スレッドの全てが前記同期点に達した後に、前記第１のワークグループからの前記並列スレッドの各々を、前記同期点からの実行を再開するように構成することとを含む、ことと、
を備えた方法。
【請求項１２】
前記ＧＰＵに結合される前記メモリ階層からの割り当てを前記１つ以上のプロセッサコアに結合される前記システムメモリへとマッピングすることを更に備えた請求項１１の方法。
【請求項１３】
複数の並列スレッドを実行するためのシステムであって、
プロセッサコアを含む少なくとも１つのプロセッサと、
前記プロセッサコアに結合される少なくとも１つのメモリと、
前記少なくとも１つのメモリ及び前記少なくとも１つのプロセッサに結合されるグラフィクス処理ユニット（ＧＰＵ）カーネルスケジューラとを備え、
前記ＧＰＵカーネルスケジューラは、
前記複数の並列スレッドを少なくとも２つのワークグループにグループ化することであって、各ワークグループはプロセッサのプロセッサコアに割り当てられることと、
前記少なくとも２つのワークグループからの第１のワークグループを、第１のプロセッサコア上で実行するように構成された第１のオペレーティングシステムスレッドに関連付けることと、
第２のプロセッサに関連するメモリ階層を、前記プロセッサコアに関連するメモリにマッピングすることと、
前記第１のオペレーティングシステムスレッド内の前記第１のワークグループからの並列スレッドをスケジューリングすることであって、前記スケジューリングすることは、前記第１のワークグループからの前記並列スレッドを同期点に至るまで実行するように構成することと、前記第１のワークグループからの前記並列スレッドの全てが前記同期点に達した後に、前記第１のワークグループからの前記並列スレッドの各々を、前記同期点からの実行を再開するように構成することとを含む、ことと、
のために構成されるシステム。
【請求項１４】
前記グラフィクス処理ユニットカーネルスケジューラは、
前記第１のワークグループからの並列スレッドを、スレッドのサブセットにグループ化することと、
第１のサブセットを実行のために構成することと、
前記第１のサブセットが実行を完了した後に第２のサブセットを実行のために構成することとのために更に構成される請求項１３のシステム。
【請求項１５】
前記プロセッサは、制御処理ユニット（ＣＰＵ）である、請求項１３のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は概してコンピュータプロセッサ及びデータ並列スレッドに関する。
【背景技術】
【０００２】
コンピュータ及び他の同種のデータ処理デバイスは、一般的には制御処理ユニット（ＣＰＵ）として知られる１つ以上の制御プロセッサを有している。そのようなコンピュータ及び処理デバイスはまた、様々な種類の特殊な処理のために用いられる他のプロセッサ、例えばグラフィクス処理ユニット（ＧＰＵ）を有していることがある。例えばＧＰＵは、特にグラフィクス処理動作に適するように設計される。ＧＰＵは、概して、並列データストリームに対して同一の命令を実行すること、例えばデータ並列処理、に理想的には適する多重処理要素を備えている。一般に、ＣＰＵはホスト又は制御プロセッサとして機能し、そしてグラフィクス処理等の特殊な機能をＧＰＵ等の他のプロセッサに任せる。
【０００３】
各ＣＰＵが多重処理コアを有する多重コアＣＰＵの利用可能性に伴い、特殊な機能のためにも用いられ得るかなりの処理能力がＣＰＵにおいて利用可能である。多重コアのＣＰＵ又はＧＰＵの１つ以上の計算コアは、同一ダイ（例えばＡＭＤ＿Ｆｕｓｉｏｎ（商標））の一部であることがあり、あるいは異なるダイ（例えばＮＶＩＤＩＡ＿ＧＰＵを伴うＩｎｔｅｌ＿Ｘｅｏｎ（商標））内にあることがある。近年、ＣＰＵ及びＧＰＵの両方の特徴を有するハイブリッドコア（例えばＣｅｌｌＳＰＥ（商標）、Ｉｎｔｅｌ＿Ｌａｒｒａｂｅｅ（商標））が、汎用ＧＰＵ(General Purpose GPU)（ＧＰＧＰＵ）型コンピューティングのために広く提案されてきている。ＧＰＧＰＵ型のコンピューティングは、ＣＰＵが主として制御コードを実行すると共に性能臨界なデータ並列コードをＧＰＵに解放するようにＣＰＵを用いることを推奨している。ＧＰＵは主としてアクセラレータとして用いられる。多重コアのＣＰＵとＧＰＧＰＵコンピューティングモデルの組み合わせは、ＣＰＵコア及びＧＰＵコアの両方をアクセラレータ目標として網羅する。多重コアのＣＰＵコアの多くは、様々な分野でＧＰＵに匹敵する性能を有している。例えば、多くのＣＰＵコアの１秒当たり浮動小数点演算数（ＦＬＯＰＳ）が、今や幾つかのＧＰＵコアのそれと同程度である。
【０００４】
ＣＰＵ及びＧＰＵを有するヘテロコンピューティング(heterogeneous computing)プラットフォームのために種々のフレームワークが開発されてきた。これらのフレームワークは、スタンフォード大学によるＢｒｏｏｋＧＰＵ、ＮＶＩＤＩＡによるＣＵＤＡ、及びＫｈｒｏｎｏｓＧｒｏｕｐと称される産業共同体によるＯｐｅｎＣＬを含む。ＯｐｅｎＣＬフレームワークはＣ的開発環境を提示しており、それを用いてユーザはＧＰＵのためのアプリケーションを創出することができる。ＯｐｅｎＣＬは、例えば、データ並列計算のような幾つかの計算をＧＰＵへと解放するための命令をユーザが指定することを可能にする。ＯｐｅｎＣＬはまた、ヘテロコンピューティングシステム内でコードがコンパイルされ且つ実行され得るようなコンパイラ及びランタイム環境を提供する。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従って、一般的にはＧＰＵ上で処理される機能の実行のためにＣＰＵ能力の効率的な使用を可能にする方法及びシステムが求められている。
【課題を解決するための手段】
【０００６】
処理論理の複数のデータ並列スレッドをプロセッサコア上で実行するためのシステム及び方法が開示される。処理論理の複数のデータ並列スレッドをプロセッサコア上で実行するための方法は、複数のデータ並列スレッドを１つ以上のワークグループにグループ化することと、１つ以上のワークグループからの第１のワークグループをプロセッサコア上のオペレーティングシステムスレッドに関連付けることと、第１のワークグループからのスレッドをオペレーティングシステムスレッド内のユーザレベルスレッドとして構成することとを含む。処理論理は、ＧＰＵ上での実行のために前もって構成されるＧＰＵカーネルを含むことができる。処理コアは、多重コアＣＰＵの処理コアのようなＣＰＵコアを含むことができる。
【０００７】
別の実施形態はＧＰＵカーネルを実行するための方法であり、方法は、ＧＰＵカーネルをホストプロセッサにロードすることと、各々が複数のデータ並列スレッドを含む１つ以上のワークグループを形成することと、ホストプロセッサに結合される１つ以上のプロセッサコアのオペレーティングシステムスレッドにワークグループを関連付けることとを含む。各ワークグループは、１つ以上のオペレーティングシステムスレッドに関連付けられていてよく、そして各オペレーティングシステムスレッドは、１つのプロセッサコア上でのみ実行されるように構成される。方法はまた、各ワークグループのデータ並列スレッドを、それぞれの関連付けられたオペレーティングシステムスレッドの各々におけるユーザレベルスレッドとして構成するステップを含むことができる。
【０００８】
別の実施形態は、処理論理の複数のデータ並列スレッドをプロセッサコア上で実行するためのシステムである。システムは、プロセッサコアを含む少なくとも１つのプロセッサと、プロセッサコアに結合される少なくとも１つのメモリと、ＧＰＵカーネルスケジューラとを含む。ＧＰＵカーネルスケジューラは、複数のデータ並列スレッドを１つ以上のワークグループにグループ化することと、１つ以上のワークグループからの第１のワークグループをプロセッサコア上のオペレーティングシステムスレッドに関連付けることと、第１のワークグループからのスレッドをオペレーティングシステムスレッド内のユーザレベルスレッドとして実行することと、のために構成される。
【０００９】
更に別の実施形態はコンピュータ可読媒体を備えたコンピュータプログラム製品であり、コンピュータ可読媒体はその上に記録されるコンピュータプログラム論理を有し、コンピュータプログラム論理は、少なくとも１つのプロセッサに、複数のデータ並列スレッドを１つ以上のワークグループにグループ化することと、１つ以上のワークグループからの第１のワークグループをプロセッサコア上のオペレーティングシステムスレッドに関連付けることと、第１のワークグループからのスレッドをオペレーティングシステムスレッド内のユーザレベルスレッドとして実行することとをさせる。
【００１０】
本発明の更なる実施形態、特徴及び利益の他、本発明の種々の実施形態の構成及び動作が、添付の図面を参照して以下に詳細に説明される。
【図面の簡単な説明】
【００１１】
添付の図面は、本明細書に組み入れられその一部を構成し、本発明の実施形態を示しており、上述の一般的な説明及び以下に与えられる実施形態の詳細な説明と共に、本発明の原理を説明するのに役立つ。
【００１２】
【図１】図１は本発明の実施形態に従うヘテロコンピューティングシステムを示す図である。
【００１３】
【図２】図２は本発明の実施形態に従うＧＰＵカーネルスケジューラを示す図である。
【００１４】
【図３】図３は本発明の実施形態に従いヘテロコンピューティングシステム上でコードを実行するための処理を示す図である。
【００１５】
【図４】図４は本発明の実施形態に従う例示的なメモリ配置の説明図である。
【００１６】
【図５】図５は本発明の実施形態に従いヘテロコンピューティングシステム上でワークアイテムをスケジューリングするための処理を示す図である。
【００１７】
【図６】図６は本発明の実施形態に従うスレッドスケジューリングの例示的な説明図である。
【発明を実施するための形態】
【００１８】
本発明の実施形態は、ＣＰＵプロセッサ及びＧＰＵプロセッサ上での同一の又は類似のコードベースの使用を可能にすることによる他、そのようなコードベースのデバッグを容易にすることによって、実質的な利点を生み出し得る。本発明はここでは特定のアプリケーションのための例示的な実施形態と共に説明されるが、本発明はそれらに限定されないことが理解されるべきである。ここに提供される教示を利用し得る当業者であれば、その範囲内での並びに本発明が顕著に有用であろう追加的な分野の範囲内での追加的な修正、応用、及び実施形態を認識するであろう。
【００１９】
本発明の実施形態は、任意のコンピュータシステム、コンピューティングデバイス、エンタテーメントシステム、メディアシステム、ゲームシステム、通信デバイス、パーソナルデジタルアシスタント、又は１つ以上のプロセッサを用いる任意のシステムにおいて用いられ得る。本発明は、システムがヘテロコンピューティングシステムを備えている場合に特に有用である。ここで用いられる用語としての「ヘテロコンピューティングシステム」は、多重種のプロセッサが利用可能なコンピューティングシステムのことである。
【００２０】
本発明の実施形態は、同一のコードベースが異なるプロセッサ、例えばＧＰＵ及びＣＰＵ上で実行されることを可能にする。本発明の実施形態は、例えば多重コアのＣＰＵ及び／又はＧＰＵを有する処理システムにおいて特に有用であり得るのであるが、その理由は、１つの種類のプロセッサのために開発されたコード(code developed)が、追加的な努力を殆ど又は全く伴わずに別の種類のプロセッサ上で展開され(deployed)得るところにある。例えば、ＧＰＵカーネル(GPU-kernels)としても知られるＧＰＵ上での実行のために開発されたコードは、本発明の実施形態を用いてＣＰＵ上に展開されて実行され得る。
【００２１】
また、本発明は、典型的には多数のデータ並列スレッドを伴うＧＰＵカーネルを、スレッドをデバッグすることに役立つ方法でＣＰＵ及び他のプロセッサ上で展開することを可能にする。
【００２２】
ヘテロコンピューティングシステム
本発明の実施形態に従う例示的なヘテロコンピューティングシステム１００が図１に示されている。ヘテロコンピューティングシステム１００は、１つ以上のＣＰＵ、例えばＣＰＵ１０１と、１つ以上のＧＰＵ、例えばＧＰＵ１０２とを含み得る。ヘテロコンピューティングシステム１００はまた、少なくとも１つのシステムメモリ１０３と、少なくとも１つの永続的記憶デバイス１０４と、少なくとも１つのシステムバス１０５と、少なくとも１つの入力／出力デバイス１０６と、ＧＰＵカーネルスケジューラ(GPU-kernel scheduler)１０９と、デバッガ(debugger)１０８とを含み得る。
【００２３】
ＣＰＵ１０１は、任意の市販の制御プロセッサ又は特別注文の制御プロセッサを含み得る。ＣＰＵ１０１は、例えば、ヘテロコンピューティングシステム１００の動作を制御する制御論理を実行する。ＣＰＵ１０１は、多重コアＣＰＵ、例えば２つのＣＰＵコア１４１及び１４２を伴う多重コアＣＰＵであってよい。ＣＰＵ１０１は、任意の制御回路に加えて、ＣＰＵキャッシュメモリ、例えばそれぞれＣＰＵコア１４１及び１４２のキャッシュメモリ１４３及び１４４を含み得る。ＣＰＵキャッシュメモリ１４３及び１４４は、それぞれＣＰＵコア１４１及び１４２上でのアプリケーションの実行の間に命令及び／又はパラメータ値を一時的に保持するために用いられ得る。例えばＣＰＵキャッシュメモリ１４３は、ＣＰＵコア１４１上での制御論理命令の実行の間におけるシステムメモリ１０３からの１つ以上の制御論理命令、変数の値、又は定数パラメータの値を一時的に保持するために用いられ得る。幾つかの実施形態においては、ＣＰＵ１０１はまた、特殊なベクトル命令処理ユニットを含み得る。例えばＣＰＵコア１４２は、ベクトル化された命令を効率的に処理することができるストリーミングＳＩＭＤ拡張(Streaming SIMD Extensions)（ＳＳＥ）ユニットを含み得る。当業者であれば、ＣＰＵ１０１は選択された例におけるＣＰＵコアよりも多い又は少ないＣＰＵコアを含み得るし、またＣＰＵ１０１はキャッシュメモリを有していないことがあり又はより複雑なキャッシュメモリ階層を有し得ることを理解するであろう。
【００２４】
ＧＰＵ１０２は、任意の市販のグラフィクスプロセッサ又は特注設計のグラフィクスプロセッサを含み得る。ＧＰＵ１０２は、例えば、選択された機能に対して特殊なコードを実行することができる。概して、ＧＰＵ１０２は、グラフィクスパイプライン計算のようなグラフィクス機能、例えば幾何学的な計算及びディスプレイ上での画像の描画を実行するために用いられ得る。
【００２５】
ＧＰＵ１０２は、ＧＰＵグローバルキャッシュメモリ１１０と、１つ以上の計算ユニット１１２及び１１３とを含み得る。ＧＰＵ１０２内にはグラフィクスメモリ１０７が含まれていてよく、あるいはグラフィクスメモリ１０７はＧＰＵ１０２に結合されていてもよい。計算ユニット１１２及び１１３は、それぞれＧＰＵローカルメモリ１１４及び１１５と関連付けられている。各計算ユニットは１つ以上のＧＰＵ処理要素（ＰＥ）を含む。例えば、計算ユニット１１２はＧＰＵ処理要素１２１及び１２２を含み、また計算ユニット１１３はＧＰＵ処理要素１２３及び１２４を含む。ＧＰＵ処理要素１２１、１２２、１２３、及び１２４は、少なくとも１つのプライベートメモリ（ＰＭ）１３１、１３２、１３３、及び１３４とそれぞれ関連付けられている。各ＧＰＵ処理要素は、１つ以上のスカラー及びベクトル浮動小数点ユニットを含み得る。ＧＰＵ処理要素はまた、逆平方根ユニット及びサイン／コサインユニット等の特殊目的ユニットを含み得る。ＧＰＵグローバルキャッシュメモリ１１０は、システムメモリ１０３等のシステムメモリ及び／又はグラフィクスメモリ１０７等のグラフィクスメモリに結合され得る。
【００２６】
システムメモリ１０３は、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）等の少なくとも１つの非永続的メモリを含むことができる。システムメモリ１０３は、アプリケーションの一部分又は他の処理論理の実行の間に、処理論理命令、定数値、及び変数値を保持することができる。例えば１つの実施形態においては、ＧＰＵカーネルスケジューラ１０９の制御論理及び／又は他の処理論理は、ＣＰＵ１０１によるＧＰＵカーネルスケジューラ１０９の実行の間にシステムメモリ１０３内に存在することができる。ここで用いられる「処理論理」の用語は、制御フロー命令、計算を実行するための命令、及び資源への関連するアクセスのための命令を参照する。
【００２７】
永続的メモリ１０４は、デジタルデータを記憶可能な１つ以上の記憶デバイス、例えば磁気ディスク、光学ディスク、又はフラッシュメモリを含む。永続的メモリ１０４は、例えば、ＧＰＵカーネルスケジューラ１０９及びデバッガ１０８の命令論理の少なくとも一部を記憶することができる。例えば、ヘテロコンピューティングシステム１００の起動に際して、オペレーティングシステム及び他のアプリケーションソフトウエアが、永続的メモリ１０４からシステムメモリ１０３へとロードされ得る。
【００２８】
システムバス１０５は、周辺構成部品相互接続(Peripheral Component Interconnect)（ＰＣＩ）バス、進歩的マイクロ制御器バスアーキテクチャ(Advanced Microcontroller Bus Architecture)（ＡＭＢＡ）バス、業界標準アーキテクチャ(Industry Standard Architecture)（ＩＳＡ）バス、又は同様のデバイスを含み得る。システムバス１０５はまた、ローカルエリアネットワーク（ＬＡＮ）等のネットワークを含み得る。システムバス１０５は、ヘテロコンピューティングシステム１００の構成要素を含む複数の構成要素を結合するための機能性を包含する。
【００２９】
入力／出力インタフェース１０６は、ユーザ入力／出力デバイス、例えばキーボード、マウス、ディスプレイ、及び／又はタッチスクリーンを接続する１つ以上のインタフェースを含む。例えばユーザ入力は、キーボード及びマウス接続のユーザインタフェース１０６を介してヘテロコンピューティングシステム１００へ供給され得る。ヘテロコンピューティングシステム１００の出力、例えばＧＰＵカーネルスケジューラ１０９及びデバッガ１０８の出力は、ユーザインタフェース１０６を介してディスプレイへ出力され得る。
【００３０】
グラフィクスメモリ１０７は、システムバス１０５及びＧＰＵ１０２に結合されている。グラフィクスメモリ１０７は、一般的に、システムメモリ１０３から転送されるデータをＧＰＵによる高速アクセスのために保持するのに用いられる。例えば、ＧＰＵ１０２とグラフィクスメモリ１０７の間でのインタフェースは、システムバスインタフェース１０５の数倍は高速であり得る。
【００３１】
デバッガ１０８は、ヘテロコンピューティングシステム１００上で実行中のアプリケーションコード及び他の処理論理をデバッグする機能性を包含する。例えばデバッガ１０８は、アプリケーションコード及び／又は他の処理論理の実行の間に１つ以上の変数をモニタリングする機能性を包含し得る。ヘテロコンピューティング環境においては、デバッガ１０８は、ＣＰＵの他ＧＰＵ上でのアプリケーションコード及び他の処理論理の実行をモニタリングする能力を必要とすることがある。
【００３２】
ＧＰＵカーネルスケジューラ１０９は、特にＧＰＵ上での実行のために書かれた機能及び処理論理をＧＰＵ上又はＣＰＵ上のいずれかにスケジューリングする機能性を包含する。ＧＰＵカーネルスケジューラは、図２に関連して後で更に説明される。当業者であれば、デバッガ１０８及びＧＰＵカーネルスケジューラ１０９は、ソフトウエア、ファームウエア、ハードウエア、又はこれらの任意の組み合わせを用いて実装され得ることを理解するであろう。例えばソフトウエアにおいて実装される場合、ＧＰＵカーネルスケジューラ１０９は、コンパイルされ実行中にはシステムメモリ１０３内に存在するＣ又はＯｐｅｎＣＬで書かれたコンピュータプログラムであってよい。ソースコードの形態及び／又はコンパイルされた実行可能な形態においては、ＧＰＵカーネルスケジューラ１０９は永続的メモリ１０４内に記憶されていてよい。１つの実施形態においては、ＧＰＵカーネルスケジューラ１０９及び／又はデバッガ１０８の機能性の一部又は全部は、ここに説明される本発明の態様を具現化するハードウエアデバイスを創出するためのマスクワーク／フォトマスクの生成を通して最終的に製造プロセスを構成することを可能にするＶｅｒｉｌｏｇ、ＲＴＬ、ネットリスト(netlists)等のハードウエア記述言語において指定される。
【００３３】
当業者であれば、ヘテロコンピューティングシステム１００は、図１に示されるよりも多い又は少ない構成要素を含み得ることを理解するであろう。例えば、ヘテロコンピューティングシステム１００は、１つ以上のネットワークインタフェース、及び／又はＯｐｅｎＣＬフレームワーク等のソフトウエアアプリケーションを含み得る。
【００３４】
ＧＰＵカーネル
ここで用いられる「ＧＰＵカーネル」の用語は、ＧＰＵ上での１つ以上の機能又は動作を実行するコード及び／又は処理論理を含む。例えばＧＰＵカーネルは、行列乗算、行列転置(matrix transpose)、細分化(subdivision)、方程式解法(equation solving)、及び種々の他の動作のために開発される。ＧＰＧＰＵモデルにおいては、例えば、ＧＰＵカーネルは、ＣＰＵによってＧＰＵ上での実行から解放され得る機能及び／又は他の動作のコードフラグメント(code fragments)である。典型的なＧＰＧＰＵアプリケーションにおいては、同じＧＰＵカーネルコードが多重並列データストリーム上で同時に実行されるであろう。これは「データ並列」コンピューティングとして知られる。例えば２つの行列を乗算する場合、２つの元の行列からの対応する要素の多重対が、異なる処理コアを用いて同時に乗ぜられ得る。単純な例ではあるが、行列乗算はＧＰＵ上でのデータ並列動作を例示し得る。
【００３５】
上述の行列乗算の例に続き、結果として得られる行列の各要素に対する計算は、実行（スレッド）の別個のスレッドとして考えられ得る。結果として得られる行列の各要素に対応するスレッドは、並列で実行可能である。ＧＰＵ１０２においては、例えば、スレッドは各処理要素１２１、１２２、１２３、及び１２４上で同時に実行されてよい。
【００３６】
例えばグラフィクスアプリケーションにおいて一般的であるように、行列の多重対が乗ぜられることになる場合、行列の各対は、計算要素１１２及び１１３等の１つの計算要素に割り当てられ得る。
【００３７】
ＧＰＵカーネルの実行は、ＧＰＵ１０２に関して説明され得る。ＧＰＵカーネルは、一般には並列の多重スレッドとして実行される。これらの並列スレッドの各々が「ワークアイテム(workitem)」である。各ワークアイテムは、１つの処理要素、例えば処理要素１２１、１２２、１２３、又は１２４上で実行され得る。１つの計算ユニットに割り当てられる複数のワークアイテムは「ワークグループ(workgroup)」として知られる。
【００３８】
概して、ワークアイテム間での同期は、単一のワークグループ内のワークアイテムに限定される。この制限は一般的には多数のスレッドを伴う環境において強制され、その結果、多数のスレッドが効率的に管理され得る。しかし、幾つかの実施形態においては、同期は単一のワークグループ内のワークアイテムに限定されなくてよい。
【００３９】
ＧＰＵカーネルスケジューラ
図２は本発明の実施形態に従うＧＰＵカーネルスケジューラ１０９の構成要素を示している。ＧＰＵカーネルスケジューラ１０９は、コードアナライザ２０１と、ＣＰＵメモリマッパ(memory mapper)２０３と、ワークグループスケジューラ２０５と、スレッドスケジューラ２０７とを備えていてよい。当業者であれば、ＧＰＵカーネルスケジューラ１０９は、追加的な構成要素及び／又は構成要素２０１〜２０７の異なる組み合わせを備えていてよいことを理解するであろう。
【００４０】
コードアナライザ２０１は、ＯｐｅｎＣＬコード等のコードを解析するための機能性を包含する。コードアナライザ２０１は、ＣＰＵ上又は代替的にはＧＰＵ上で有利にスケジューリングされ得る解析中のコードにおけるコードフラグメント(code fragments)及び／又はＧＰＵカーネルを識別することができる。コードアナライザ２０１はまた、目標プラットフォームの詳細を知る機能性を包含し得る。例えばコードアナライザ２０１は、ＣＰＵコアの数、及び目標プラットフォーム上で利用可能なＧＰＵコアを識別することができる。コードアナライザ２０１は更に、システムメモリ、キャッシュメモリ、グローバルＧＰＵキャッシュメモリの量、等を識別し得る。
【００４１】
ＣＰＵメモリマッパ２０３は、コードが実行のために送られ得る先であるＣＰＵのメモリ利用可能性を決定すると共にマッピングされたＧＰＵカーネルを実行するためにＣＰＵを準備する機能性を包含する。
【００４２】
ワークグループスケジューラ２０５は、ワークグループをスケジューリングする機能性を包含する。例えばワークグループスケジューラ２０５は、各ワークグループを実行するために用いられ得るＧＰＵの計算ユニットの適切なセットを決定することができる。別の実施形態においては、ワークグループスケジューラはまた、１つ以上のＣＰＵコア上のスレッドにワークグループが割り当てられ得るように、ＧＰＵカーネルのワークアイテムスレッドがどのようにワークグループにグループ化されるべきかを決定することもできる。ワークグループスケジューラは更に、ＧＰＵカーネルスレッドのワークグループをＣＰＵ又はＣＰＵコアにマッピングする機能性を包含し得る。
【００４３】
スレッドスケジューラ２０７は、ＧＰＵカーネルのスレッドをＧＰＵ又はＣＰＵにスケジューリングする機能性を包含する。例えばスレッドスケジューラ２０７は、スレッドの処理要求が受け入れられ得る方法で、処理要素１２１、１２２、１２３、又は１２４へのスレッドの割り当てを決定することができる。１つの実施形態においては、スレッドスケジューラ２０７は、ＧＰＵ１０２内のどの処理要素で各ワークアイテムがスケジューリングされ得るのかを決定する。別の実施形態においては、スレッドスケジューラ２０７はＣＰＵ１０１上でワークアイテムスレッドをスケジューリングする。例えばスレッドスケジューラ２０７は、１つのワークグループの複数のワークアイテムスレッドを単一のＣＰＵコア、例えばＣＰＵコア１４２上でスケジューリングすることができる。モジュール２０１〜２０７の機能性は、本発明の実施形態に従い図３〜６との関係において後で更に説明される。
【００４４】
ＣＰＵコア上でのＧＰＵカーネルのマッピング及び実行
図３は本発明の実施形態に従いヘテロコンピューティングシステム上でコードを実行するための処理３００を示している。処理３００は、例えば、ヘテロコンピューティングシステム１００上で実行可能である。１つの実施形態においては、処理３００はＧＰＵカーネルスケジューラ１０９の処理論理のフローを代表し得る。
【００４５】
一般性を損なうことなしに、以下の説明は主としてＯｐｅｎＣＬフレームワークに基づいている。当業者であれば、本発明の実施形態はまた、他の開発及び実行フレームワーク、限定はされないが例えばＣＵＤＡフレームワーク、ＢｒｏｏｋＧＰＵフレームワーク等を用いて実装され得ることを認識するであろう。上述したように、ＯｐｅｎＣＬは、ヘテロコンピューティングシステム内でコードが開発され、コンパイルされ、そして実行され得る開発環境、コンパイラ、及びランタイム環境(run time emvironment)を提供する。
【００４６】
ＯｐｅｎＣＬはまた、選択されたプロセッサ上で実行されるＧＰＵカーネルを展開すること(deploying)等の種々の機能を実行するためにユーザアプリケーションによって呼び出され得る組み込みライブラリ機能(built-in library functions)及びアプリケーションプログラミングインタフェース（ＡＰＩ）を提供する。一般にＯｐｅｎＣＬフレームワークは主としてホストシステム上で実行され、そしてコマンド（例えばＧＰＵカーネルを含む実行可能なコード）を展開することによって、結合されている複数のプロセッサの動作を制御する。例えばＯｐｅｎＣＬはＣＰＵコア１４１上で主として実行されてよく、そしてそれぞれのデバイス上で実行されるべきコマンドを展開することによって、ＧＰＵ１０２並びにＣＰＵコア１４１及び１４２の動作を制御してよい。
【００４７】
ステップ３０１では、１つ以上のアプリケーションのためのコードがロードされる。ロードされたコードは、ソースコード、又はバイトコードのような事前コンパイルされたコード(pre-compilation code)の他の形態であってよい。幾つかの実施形態では、埋め込まれたコンパイルされた機能をコードが含んでいてもよい。例えば幾つかの機能が、アプリケーション内に埋め込まれた機能呼び出しに基づいてライブラリから動的にリンクされ得る。説明を目的として、ロードされたコードは、ＯｐｅｎＣＬのようなプログラミング言語におけるソースコード形態にあるものとする。ソースコードは、例えば、最初には永続的メモリ１０４上に存在し得る。ステップ３０１においてコードをロードするに際して、ソースコードは、メモリ、例えばシステムメモリ１０３内へとロードされ得る。尚、ロードされたコードは、ソースコード、事前コンパイルされたコード、及び／又はコンパイルされたバイナリの組み合わせを含み得る。例えば、処理３００が実装され得るＯｐｅｎＣＬ開発、コンパイル、及び実行フレームワークは、ＧＰＵカーネルのソースコード及び／又はコンパイルされたバイナリのロードを可能にする。ＯｐｅｎＣＬプログラムは、例えば、ＧＰＵカーネル、制御フローコード、及びＧＰＵカーネルによって呼び出される他の機能を含み得る。
【００４８】
ステップ３０３では、ロードされたコードが解析される。コードの解析はコードを構文解析することを含み得る。幾つかの実施形態では、ステップ３０３で解析されるコードは、有効なＯｐｅｎＣＬコード又はＣのような別のプログラミング言語若しくはフレームワークにおけるコードを含み得る。解析ステップ３０３においては、必要とされるＣＰＵ資源が決定され得る。例えば、解析及び／又は構文解析は、１つ以上のＣＰＵコア上でスケジューリングされることを必要としているスレッド（ワークアイテム）の総数を決定することができる。また、解析ステップ３０３は、メモリ要求、例えばＧＰＵカーネルによって使用されるプライベートメモリ及びローカルメモリの実際の量を決定するために用いられ得る。１つの実施形態においては、ステップ３０１及び３０３は、コードアナライザ２０１の処理論理を用いて実装され得る。
【００４９】
ステップ３０５では、ステップ３０１でロードされたコードを実行するようにヘテロコンピューティングシステムが設定される。例えば、ステップ３０３で実行されたコード解析に基づいて、幾つかのＣＰＵ及びＧＰＵが、ロードされたコードを実行するために割り当てられ得る。ステップ３０５はまた、ロードされたコードの実行を準備するようにメモリ１０３等のメモリ資源を設定することを含み得る。
【００５０】
ステップ３０７〜３２３は、ロードされたコードにおいて各機能及び／又はＧＰＵカーネルに対して繰り返される。例えば、ロードされたソースコードは、各機能及び／又はＧＰＵカーネルを識別する上から下への方法で走査され得る。ステップ３０７では、機能及び／又はＧＰＵカーネルが識別される。１つの実施形態では、例えば、ＧＰＵカーネルは、ＯｐｅｎＣＬにおけるカーネル識別子のような予め定められた識別子によって識別され得る。
【００５１】
ステップ３０９では、ステップ３０７で識別されたコードセグメントをＣＰＵ又はＧＰＵのどちらで実行するかが決定される。例えば、既定の挙動(default behavior)は、ＧＰＵカーネル以外の全ての機能をＣＰＵ上で実行し且つ全てのＧＰＵカーネルをＧＰＵ上で実行することであってよい。例えばコード内に埋め込まれた識別子に基づいてコマンド又は機能がデータ並列であるかどうかを決定するために、別の考慮があり得る。データ並列コマンド又は機能は、望ましくはＧＰＵに対してスケジューリングされ得る。ロードバランシング(load balancing)要求及びアプリケーション特性のような他の基準が用いられてもよい。
【００５２】
処理論理及び／又はコードセグメントがＧＰＵ上で実行されるべきと決定された場合（ステップ３０９において）には、ステップ３１１においてＧＰＵ上に実装されるようにスケジューリングされる。幾つかの実施形態においては、処理論理及び／又はコードセグメントは、特定のＧＰＵ上で実装されるものとしてスケジューリングされる。
【００５３】
ステップ３１１では、選択されたＧＰＵ上で処理論理及び／又はコードセグメントがスケジューリングされる。ステップ３１１は、ＧＰＵの構成、例えばＧＰＵにおける計算デバイスの数及び各計算デバイス内の処理要素の数を決定することを含んでいてよい。ステップ３１１はまた、当該ＧＰＵに対するコンテクスト及びコマンドキューを作成することと、そのコンテクストに関連するメモリオブジェクトを作成することと、ＧＰＵカーネルオブジェクトをコンパイルすると共に作成することと、ＧＰＵカーネルオブジェクトを実行するようにコマンドキューへ対応するコマンドを発行することと、発行されたコマンドの任意の同期を行うこととを含み得る。
【００５４】
ＧＰＵの構成を決定することは、例えば、システム内で利用可能な計算デバイス（例えばＣＰＵ、ＧＰＵ）にＯｐｅｎＣＬ＿ＡＰＩ呼び出しを用いて問い合わせることと、次いで１つ以上の識別された計算デバイスにそのローカル情報を問い合わせることとを含み得る。ＧＰＵ処理要素の数、レンジ限界、ワークグループサイズ、種々のメモリ空間のサイズ、最大メモリオブジェクトサイズ等を決定するために、計算デバイスのリストから、あるＧＰＵデバイスが問い合わせされ得る。
【００５５】
選択されたＧＰＵ上で処理論理及び／又はコードセグメントが実行されるようにスケジューリングするに際して、コードセグメント（例えば実行可能なカーネルオブジェクト）を含む実行可能なコードを含んでいるコマンドが、選択されたＧＰＵのコンテクストにおいて作成されるコマンドキューにスケジューリングされ得る。ここで用いられる「コンテクスト」は、ＧＰＵカーネルのための実行環境を定義する。コンテクストは、カーネルに関連するデバイス、メモリ、及び他のプログラムオブジェクトのためのハンドル及び他の情報を含み得る。例えばコンテクストは、実行中のカーネルに、それが使用することを許可されているＧＰＵデバイス及びメモリロケーションを提供することができる。
【００５６】
作成されるメモリオブジェクトは、ソース及び宛先オブジェクトに対応し得る。例えば処理論理及び／又はコードセグメントが反復アレイ追加(interactive array addition)を行う場合、ソースオブジェクトは２つのソースアレイであってよい。宛先オブジェクトは、出力結果が書き込まれるアレイであり得る。メモリオブジェクトは、システムメモリ１０３内又はグラフィクスメモリ１０７内で作成され得る。メモリオブジェクトは次いで、キャッシュ１１０、１４３、及び１４４のような種々のキャッシュ内にキャッシュされてよい。作成される各メモリオブジェクトは、対応するコンテクストに関連している。
【００５７】
実行可能なカーネルオブジェクトの作成は、処理論理及び／又はコードセグメントをコンパイルすること並びに任意の必要な特定デバイス向けモジュールをリンクすることによって行われる。例えば、コンパイルされたカーネルオブジェクトは、カーネル機能コード又は命令、カーネルに提供される任意の引数(arguments)、関連するコンテクスト、及びそれが実行されることになるＧＰＵに関連するライブラリコードを含み得る。
【００５８】
カーネルオブジェクトが作成された後に、カーネルを実行することになるコマンドがコマンドキューにキューされる。コマンドがキューに入れられる(enqueued)方法は、コマンドがデータ並列コマンドであるかタスク並列コマンドであるかに特有であろう。例えば反復アレイ追加の例では、データ並列コマンドは、指定された数の計算デバイス内で並列に実行される命令と共に単一のコマンドをキューに入れることができるが、タスク並列モデルは、１つのコマンドが各アレイ要素のためにある幾つかの別個のコマンドが結果としてキューに入れられるようにし得る。
【００５９】
ステップ３０９において、処理論理及び／又はコードセグメントがＣＰＵ上で実行されるべきであるとの決定がなされた場合には、処理３００はステップ３１３へ進む。ステップ３１３では、コードセグメントを実行するために１つ以上のＣＰＵが選択され得る。幾つかの実施形態では、例えば多重コアＣＰＵシステムにおいて、ＣＰＵの選択はＣＰＵのロード又は処理能力に基づき得る。利用可能なキャッシュメモリの有用性及び大きさ等の他の検討もまた、考慮され得る。
【００６０】
説明を簡略化するために、ステップ３１１〜３２１の説明は、ＣＰＵ上で実行されることになる処理論理及び／又はコードセグメントがＧＰＵカーネルであることを前提とする。選択されたＣＰＵにＧＰＵカーネルをマッピングすることは、ＣＰＵコアへのきめ細かいＧＰＵスレッド（即ちワークアイテム）のマッピングと、加えてＣＰＵメモリシステムへのＧＰＵメモリ階層のマッピングとを含み得る。ステップ３１５では、選択されたＣＰＵにＧＰＵカーネルスレッドがマッピングされる。もしＧＰＵカーネルがＣＰＵに単純にマッピングされるとすれば、各ＧＰＵワークアイテムは、オペレーティングシステム（ＯＳ）スレッドにマッピングするであろう。ステップ３１５の処理は、ワークグループスケジューラ２０５によって提供される機能性の一部であり得る。
【００６１】
ＣＰＵはより多くの制限された数のハードウエアコンテクストを有し、そしてしばしば唯一のハードウエアコンテクストを有する。ＯＳは一般的にはＯＳスレッドをスケジューリングすると共に実行することに関与する。ＯＳスレッドへのワークアイテムの単純なマッピングは、結果として数百乃至は数千のスレッドをもたらし得る。単一のコンテクストで多数のスレッドを実行させることは、各処理が実行されるときに多数のコンテクストスイッチが必要になることを含む理由で、実質的に非効率になり得る。また、多数のスレッドをＯＳに管理させることも極めて非効率になり得る。本発明の実施形態は、高い性能を達成すると共に多数のスレッドを有するアプリケーションのデバッグを容易にするような方法で、ＧＰＵからＣＰＵへのマッピングを可能にする。
【００６２】
ＧＰＵカーネルのワークアイテムをＣＰＵコアへマッピングすることは、本発明の実施形態においては、利用可能な多重コアＣＰＵを活用すると共に、コンテクストスイッチング等に関連する非効率性を回避するための管理可能な数のＯＳスレッドを有するような方法で行われる。従って、本発明の実施形態においては、ワークアイテムに代わりワークグループが、ＯＳスレッドにマッピングされ且つ／又は関連付けられる単位である。１つ以上のワークアイテムが１つのワークグループへとグループ化される。１つのワークグループ内のワークアイテムの数は予め定められていてよく、あるいは利用可能な処理コアの数及び能力のような基準に基づいて決定されてよい。ワークグループをＯＳスレッドにマッピングし且つ／又は関連付けることは、ワークグループに対して新たなＯＳスレッドを生じさせること又はワークグループを既存のＯＳスレッドに結合させることのいずれかのための設定を含み得る。新たなＯＳスレッドを生じさせるための及び既存のスレッドに結合させるためのＡＰＩ機能は、１つ以上のＯｐｅｎＣＬフレームワーク（ＯｐｅｎＣＬランタイムシステムを含む）及び下層のオペレーティングシステムによって提供される。
【００６３】
ＧＰＵカーネルの各ワークグループは、例えばワークグループに関連付けられるＯＳスレッドに対して親和性のあるプロセッサを設定するすることによって、ＣＰＵコアにマッピングされ得る。各ＣＰＵコアは１つ以上のワークグループを割り当てられてよい。ＣＰＵコア毎の多重ワークグループは並列で実行され得る。ある実施形態では、各ＣＰＵコアは一度に単一のワークグループのみを実行するように構成される。例えば、単一のＯＳスレッドのみが各ＣＰＵコアで生成される。各ＣＰＵコアは、１つのワークグループを実行して終了したら次いで別のワークグループを実行することによって、多重ワークグループを実行することができる。
【００６４】
ステップ３１７では、ワークグループ内のスレッドがマッピングされ且つ／又は構成される。ステップ３１７の処理は、スレッドスケジューラ２０７によって提供される機能性の一部であってよい。ワークグループにマッピングされている各ＯＳスレッド内で、ワークアイテムスレッドが次々に順序正しく実行されるように構成される。ワークアイテムスレッドはユーザレベルスレッドとして実装される。ワークアイテムスレッドをユーザレベルスレッドとして実装することによって、オーバーヘッドがユーザ空間とカーネル空間の間で切り換わる必要性が回避され、また多数のコンテクストスイッチの関連するコストが回避される。尚、殆どの場合に、ＧＰＵカーネルはユーザ空間アプリケーションに適合し、またカーネル空間アクセスを要求するシステム資源への直接アクセスを必要としない。当業者に知られているように、多重ユーザレベルスレッドは、単一のオペレーティングシステムレベルスレッド内に実装され得る。
【００６５】
本発明の幾つかの実施形態においては、ワークアイテムスレッドは、１つのワークグループ内の幾つかのグループにおいて実行され得る。例えば、２つ以上の浮動小数点計算又は二重計算を同時に提供することができるＳＳＥユニット（例えばシステム１００内のＳＳＥユニット１４５）のようなベクトルユニットが利用可能な環境においては、ＳＳＥユニットの最大限の能力が利用されるように、コンパイラは、幾つかのワークアイテムを組み合わせて並列で実行することができる。
【００６６】
ステップ３１９では、ＣＰＵコアにとってアクセス可能なメモリが、ＧＰＵに利用可能なメモリ階層を提供するようにマッピングされる。ステップ３１９の処理は、ＣＰＵメモリマッパ２０３によって提供される機能性の一部であってよい。ＧＰＵカーネルがＣＰＵコア上で実行可能になるようにＧＰＵメモリ階層をＣＰＵコアへマッピングすることは、種々の態様を含む。ＧＰＵカーネルコードはＧＰＵメモリ階層内のロケーションへの参照を含み得るので、ＧＰＵメモリ階層からＣＰＵメモリへのマッピングが必要になり得る。ＣＰＵコアは典型的にはそのメモリ（例えばシステムメモリ１０３）のために単一のアドレス空間のみを有しているのに対して、ＧＰＵコアは幾つかの独立してアドレス可能なメモリを有し得る。ＧＰＵグローバルメモリ、計算デバイスローカルメモリ、及び処理要素プライベートメモリの全てがＣＰＵメモリへとマッピングされ得る。
【００６７】
ＧＰＵグローバルメモリ、例えばＧＰＵメモリ１０７は、システムメモリ、例えばメモリ１０３に直接マッピングされ得る。ＧＰＵローカルメモリ及びプライベートメモリのマッピングは、より微妙な手法を必要とする。メモリとの関係で用いられるマッピングは、自動アドレストランスレーション(translation)メカニズムをセットアップすることを伴っていてよく、それにより、ＣＰＵコア上で実行中のＧＰＵカーネル内に含まれるメモリアドレスが、ＧＰＵに付随するメモリ階層内のロケーションの代わりにシステムメモリ１０３へとリダイレクトされる。
【００６８】
ＧＰＵローカルメモリ、例えばＧＰＵローカルメモリ１１４及び１１５は、計算ユニットの複数の処理要素によって共有される。従って、１つのＧＰＵローカルメモリが１つのワークグループの全てのワークアイテムの間で共有される。あるＣＰＵに複数のワークグループがマッピングされる場合、１つのワークグループは単一のＣＰＵコアにマッピングされるので、対応するＧＰＵローカルメモリがこのＣＰＵコアにもたらされてよい。多くの場合、ＧＰＵ内でのローカルメモリの実際の使用は、それが完全にＣＰＵコアのキャッシュメモリ内に組み込まれ得るようなものであってよい。
【００６９】
ＧＰＵローカルメモリ、例えばＧＰＵローカルメモリ１１４及び１１５は、１つのワークグループ内の複数のワークアイテムによって共有される。本発明の実施形態は、各ＣＰＵコアが同時に単一のワークグループのみを実行するように制限することがある。ＣＰＵが同時に単一のワークグループのみを実行する場合、ＧＰＵローカルメモリに対応する単一の割り当てのみが１つのＣＰＵコアによって利用される。従って、ＣＰＵコア毎に単一のローカルメモリが割り当てられてよく、そして割り当てられたローカルメモリは、ＣＰＵコア上で実行される連続するワークグループのために再使用され得る。あるローカルメモリは、各計算デバイスのためにシステムメモリの連続的なメモリ領域内に割り当てられてよい。好ましくは、ＣＰＵコア内のキャッシュメモリは、そのＣＰＵコアに対応する、システムメモリ内のローカルメモリの割り当てのインスタンス(instance)を提供するのに十分な大きさのものであってよい。当業者であれば、メモリ及び／又はキャッシュ内に割り当てられるローカルメモリ領域は、次に続く各ワークグループに対して再使用される前にフラッシュされる(flushed)ことを必要とする場合があることを理解するであろう。幾つかの実施形態においては、メモリ及び／又はキャッシュ内に割り当てられるローカルメモリ領域は、前の内容に上書きすることによって再使用されてよい。
【００７０】
ＧＰＵプライベートメモリ、例えばＧＰＵプライベートメモリ１３１、１３２、１３３、及び１３４は、各処理要素にプライベートである。ＧＰＵ環境内の各プライベートメモリは、同時に単一のワークアイテムによって用いられる。従って、ローカルメモリと同様に、プライベートメモリはシステムメモリ内に割り当てられてよく、そして連続するワークアイテムのために再使用されてよい。例えば、あるプライベートメモリに対するシステムメモリ１０３内での単一の割り当ては、単一のワークグループの連続的に実行されるワークアイテムによって再使用されてよく、また連続するワークグループ内で同一のＣＰＵコアによって実行されてよい。ＧＰＵプライベートメモリ、及びそれに伴いそのＧＰＵプライベートメモリに対応するシステムメモリ１０３内の割り当ては、典型的には、カーネルの内部にあり且つ各ワークアイテムにとってローカルであるスタック変数(Stack variables)を保持するために用いられる。
【００７１】
定数メモリは、コードの実行の間中は一定である値を有するデータを含む。ＧＰＵ上で実行中のＧＰＵカーネルのために、定数メモリは、グラフィクスメモリ１０７及び／又はＧＰＵグローバルキャッシュメモリ１１０内にあってよい。定数メモリは、一般的には、読み出し専用であってよく、そしてワークグループに依存しない。本発明の実施形態においては、任意のＣＰＵ上で実行中の任意のワークグループ又はワークアイテムは定数メモリへのアクセスを必要とするであろうから、定数メモリは、全てのＣＰＵコアにアクセス可能であってよいシステムメモリ内の領域にマッピングされる。また、主メモリからの定数メモリ割り当ては、各ＣＰＵコアのキャッシュメモリ内に複製されることが望ましい。ＧＰＵメモリ階層をＣＰＵへとマッピングする例示的な配置が図４に示されている。
【００７２】
ステップ３２１では、１つ以上の選択されたＣＰＵコア、例えばコア１４１及び／又は１４２上での実行のために、ＧＰＵカーネルがスケジューリングされてよい。ＧＰＵカーネルを実行のためにスケジューリングすることは、ＯｐｅｎＣＬランタイムシステムのような実行環境を構成して、選択されたＣＰＵコア上でのワークグループ及びワークアイテムのマッピングを実装することを含み得る。
【００７３】
本発明の１つの実施形態においては、ヘテロコンピューティングシステム１００上でコードをコンパイルし且つ実行するためにＯｐｅｎＣＬフレームワークが使用中である場合、ステップ３２１は、１つ以上のコマンドをコマンドキュー内にキューすることを含み得る。例えば、ヘテロコンピューティングシステム１００内でＯｐｅｎＣＬフレームワークを用いて、ＧＰＵカーネルが、１つ以上のコア１４１及び多重コアＣＰＵ１０１上で実行されるようにスケジューリングされ得る。典型的には、ＯｐｅｎＣＬフレームワークを用いてヘテロコンピューティングシステム１００上でアプリケーションを実行する場合、制御部分は、ＧＰＵ１０２又はコア１４１若しくは１４２のようなシステム１００のデバイス上での選択されたコードの実行を開始するホスト上で動作する。ＣＰＵコア、例えばコア１４１又は１４２の１つは、ホストとして機能すると共にＧＰＵカーネルを実行のためにシステム１００のデバイスへと分配することができる。例えば、ＣＰＵメモリをマッピングするためのコマンド、及びＧＰＵカーネルを実行するためのコマンドは、多重コアＣＰＵ１０１に対して作成されるコンテクストにおいて作り出されるコマンドキュー内でスケジューリングされ得る。ＯｐｅｎＣＬランタイム環境は、システム１００において指定されるデバイス内のそれぞれのコマンドキューに書き込まれたコマンドの各々を実行する。
【００７４】
多重コアＣＰＵ１０１上での実行のためにＧＰＵカーネルをスケジューリングする場合、ステップ３１３〜３２５において決定されるマッピング及び構成を強制するための命令は、多重コア１０１上で実行されるべきコード内に挿入され得る。例えば、ワークグループ内の複数のワークアイテムは、自動的に又はプログラマによって手動でのいずれかで挿入されるべき同期点(synchronization point)を必要とすることがある。
【００７５】
多重コアＣＰＵ１０１上でワークグループ内のワークアイテム同期を実装している場合、本発明の実施形態は、同期点に至るまでワークアイテムが実行されることを可能にし得る。例えば、各ワークアイテムは、同期点（例えばｂａｒｒｉｅｒ（  ）関数）に至るまでシリアルなやり方で１つずつ実行され、そして次のワークアイテムが実行される前に同期点で停止する。同期点を有するワークグループ内の全てのワークアイテムがそこに到達した場合、各ワークアイテムは、同期点からそのワークアイテムの終りまでシリアルに実行される。幾つかの関数、例えばワークアイテム状態を保存するためのｓｅｔｊｍｐ（  ）及び当該ワークアイテムの状態を復元するためのｌｏｎｇｊｍｐ（  ）が、コード内に挿入され得る。本発明の実施形態においては、そのような追加に係るコードは、ＧＰＵカーネルのソースコード内には挿入されない。むしろ、そのような追加に係るコードは、ＧＰＵカーネルのエントリ、エグジット、及び／又はバリアルーチン内に挿入される（且つＧＰＵカーネルコード内には挿入されない）。ＧＰＵカーネルのソースコードそれら自身を変えないことによって、本発明の実施形態はデバッグ作業の試みを容易にする。
【００７６】
ステップ３２３では、実行されるべき追加に係るコードがあるかどうかが判断され、ある場合には処理３００はステップ３０７に戻る。もはや実行されるべきコードがない場合には、処理３００はステップ３２５で終了する。
【００７７】
ＣＰＵへの例示的なメモリマッピング
図４はシステムメモリ内及び１つのＣＰＵコアのキャッシュメモリ内の例示的なメモリ配置を示している。４０１は、例えば、システムメモリ１０３内での配置であって、ＧＰＵ１０２のようなＧＰＵ上で実行されるものと当初書き込まれたＧＰＵカーネルに対応するメモリ割り当ての配置を示している。４０２は、単一のＣＰＵコアのキャッシュ内、例えばＣＰＵ１０１におけるキャッシュ１４３，１４４内での対応するメモリ配置を示している。
【００７８】
例えば、ＧＰＵ１０２の場合、ローカルメモリ４１１及び４２１はそれぞれローカルメモリ１１４及び１１５に対応し得る。プライベートメモリ４１２、４１３、４２２、及び４２３は、それぞれＧＰＵ１０２のプライベートメモリ１３１、１３２、１３３、及び１３４に対応し得る。定数メモリ（即ち定数パラメータが記憶されるメモリ領域）４３１は、グラフィクスメモリ１０７及び／又はＧＰＵグローバルキャッシュメモリ１１０に対応し得る。４０２に示されるように、ＣＰＵコアのキャッシュは、１つのローカルメモリブロックと、ワークグループ内の各ワークアイテムのための１つのブロックに対応する一連のプライベートメモリブロックと、定数メモリ領域とを有していてよい。幾つかの実施形態では、ＣＰＵコアによる処理のために必要とされるローカルメモリ、プライベートメモリ、及び定数メモリを有することは、ＣＰＵコアのキャッシュ内で利用可能な全てに対して特に有用であり、その結果、システムメモリ１０３へのアクセスに伴う遅延が低減され得る。
【００７９】
４０１に示されるように、ＧＰＵ１０２のそれぞれローカルメモリ１１４及び１１５をエミュレート(emulates)するように、ローカルメモリ４１１及び４２１の各々に対してシステムメモリの連続する領域が割り当てられてよい。ＧＰＵカーネルコードによってアクセスされるローカルメモリアドレスは、この割り当てられた領域内でのオフセットへとトランスレートされ得る。システムメモリ内に割り当てられるローカルメモリの全体サイズはＭ＊（ワークグループ毎のローカルメモリサイズ）であってよく、ここでＭはＣＰＵコアの数である。プライベートメモリの全体サイズはＭ＊Ｎ＊（ワークアイテム毎のプライベートメモリのサイズ）であってよく、ここでＭはコアの数、Ｎはワークグループ毎のワークアイテムの数である。
【００８０】
追加されるデバッグ能力のために、本発明の幾つかの実施形態は、システムメモリ内の別個のメモリ割り当ての間にガードページ(guard pages)を含み得る。例えば、ガードページ４４１、４４２、４４３、４４４、４４５、及び４４６が、異なるＯＳスレッドに対する割り当ての間の他、同一スレッドに対する異なるメモリ割り当ての間に挿入されてよい。例示的な実装においては、命令がメモリのガードページ領域にアクセスすることを試みるたびに、レジスタがセットされてよい。メモリアクセスエラーの高速な検出は、多数の並列スレッドが実質的に並列に実行されるアプリケーションにおいて特に有用であり得る。
【００８１】
ＣＰＵ上でのワークアイテムの例示的なスケジューリング
図５は本発明の実施形態に従いステップ３１７を実装する処理ステップ５０１〜５２７を示している。ステップ５０１では、ワークグループスレッドがスケジューリングされる。上述したように、本発明の実施形態は、多重ユーザレベルスレッドがスケジューリングされる各ＣＰＵコア上で単一のオペレーティングシステムスレッドを作成する。例えばＧＰＵカーネルの２０個のインスタンス１，…，２０がスケジューリングされるべきである場合、ＧＰＵカーネルスレッド１，…，１０（ワークアイテム１，…，１０として）はコア１４１に対してスケジューリングされてよく、そしてＧＰＵカーネルスレッド１１，…，２０（ワークアイテム１１，…，２０として）はコア１４２に対してスケジューリングされてよい。ワークアイテム１，…，１０及び１１，…，２０は、それぞれワークグループ１及びワークグループ２へ集められてよい。上述したように、各ワークグループは１つのＯＳスレッドとして実装されるので、ワークグループ１及び２をそれぞれ実装するために、コア１４１及び１４２の各々上で１つのＯＳスレッドが作成され得る。
【００８２】
ステップ５０３では、ＧＰＵカーネルが他の並列実行中のＧＰＵカーネルとの同期を必要としているかどうかが決定される。例えば、ＯｐｅｎＣＬコードは、ｂａｒｒｉｅｒ（  ）関数への１つ以上の呼び出しを含んでいてよい。同期のためのそのような呼び出しが存在する場合、ＧＰＵカーネルが同期を必要としていると決定され、そうでない場合には、ＧＰＵカーネルは同期を必要としていないであろう。
【００８３】
ＧＰＵカーネルが同期を必要としていないと決定された場合、ＧＰＵカーネルは、インスタンスが要求した番号に従って始めから終りまで実行されるようにスケジューリングされる。例えば、ステップ５０１で作成されたＯＳスレッドの各々において、予め定められた数のＧＰＵカーネル、又はワークアイテムが、ユーザレベルスレッドとして実行されるようにスケジューリングされる。ワークアイテムの間で同期は必要ないので、各ワークアイテムは始めから終りまで実行されるようにスケジューリングされる。
【００８４】
ワークアイテムユーザスレッドの実行がステップ５０５で完了すると、例えばコールバック機能の使用によって、ＯｐｅｎＣＬ実行フレームワークが通知されてよい。ワークアイテムが実行を完了した旨の通知がステップ５０７でなされると、ステップ５０９において、ワークグループ内の次のワークアイテムが、ユーザレベルスレッドとしての実行のためにスケジューリングされてよい。ＯｐｅｎＣＬ実行フレームワークはまた、１つ以上の状態パラメータに定期的にクエリを行って(query)、ワークアイテムが実行を完了したかどうかを決定することができる。スケジューリングされるべきワークアイテムがもはやワークグループ内に残っていないと、そのワークグループは実行を完了したことになる。
【００８５】
尚、幾つかの実施形態においては、２つ以上のワークグループが、次々とシリアルに実行されるべく各ＣＰＵコア上でスケジューリングされ得る。ステップ５０９で、実行中のワークグループの全てのワークアイテムが実行を完了したと決定されると、ステップ５１１において、現在のコア上で実行されるべき他のワークグループがあるかどうかが決定される。現在のＣＰＵコア上でスケジューリングされるべき更なるワークグループがある場合には、次のワークグループが実行のためにスケジューリングされる。別のワークグループをスケジューリングすることは、現在のＣＰＵコア上で現在実行中のＯＳスレッドに対してメモリ割り当てを再初期化することを含んでいてよい。尚、本発明の実施形態においては、メモリ割り当てはＯＳスレッドが作成されたときに一回なされればよく、そして一般的にはそのＯＳスレッドに割り当てられる各ワークグループに対する再割り当てを必要としない。
【００８６】
ステップ５０３において、同期が必要であると決定されると、ＧＰＵカーネルは、インスタンスが要求した番号に従って始めから次の同期点（例えばｂａｒｒｉｅｒ（  ）呼び出し）まで実行されるようにスケジューリングされる。例えば、ステップ５１３において、ワークアイテムのユーザレベルスレッドが、始めから次に生じるｂａｒｒｉｅｒ（  ）への呼び出しまで実行されるようにスケジューリングされる。ｂａｒｒｉｅｒ（  ）への呼び出しに遭遇すると、実行中のスレッドの状態が保存されてよい。１つの実施形態では、ｓｅｔｊｍｐ（  ）のような関数呼び出しが、ユーザレベルスレッドの状態を保存するために用いられ得る。保存されているスレッドの状態は、レジスタの内容、例えばスタックポインタ、フレームポインタ、及びプログラムカウンタを含み得る。各ワークアイテムユーザレベルスレッドの状態は、システムメモリ、例えばシステムメモリ１０３の領域内、又は永続的メモリ、例えば永続的メモリ１０４内に保存され得る。
【００８７】
ステップ５１５で実行中ワークアイテムスレッドが同期点に達すると、ステップ５１７において更なるワークアイテムが現在のワークグループ内でスケジューリングされるべきかどうかが決定される。ステップ５１５でワークアイテムユーザレベルスレッドの実行が同期点に達すると、例えばコールバック機能を用いてＯｐｅｎＣＬ実行フレームワークが通知されてよい。ワークアイテムが同期点に達した旨の通知がステップ５１５でなされると、ステップ５１７において、ワークグループ内の次のワークアイテムが、ユーザレベルスレッドとしての実行のためにスケジューリングされてよい。ＯｐｅｎＣＬ実行フレームワークはまた、１つ以上の状態パラメータに定期的にクエリを行って、ワークアイテムが同期点に達したかどうかを決定することができる。スケジューリングされるべきワークアイテムがもはやワークグループ内に残っていないと、ワークグループは、同期点までの各ワークアイテムを実行することを完了したことになる。
【００８８】
ステップ５１９において、スレッド実行の終わりに到達する前にワークアイテムが更なる同期点を有しているものと決定されると、現在の同期点から次の同期点まで実行されるように各ワークアイテムに対してステップ５１３〜５１９が繰り返される。
【００８９】
ステップ５１９において、ワークグループ内のワークアイテムがもはや同期点を有していないと決定されると、ステップ５２１において、同期点に達したワークアイテムの１つがその点から終わりまで実行されるようにスケジューリングされる。ワークアイテムスレッドが同期点から終わりまで実行されるようにスケジューリングすることは、スレッドの状態を回復することを含み得る。１つの実施形態では、ｓｅｔｊｍｐ（  ）を用いて先に保存されたスレッドの状態を回復するために、ｌｏｎｇｊｍｐ（  ）のような関数呼び出しが用いられ得る。尚、ｓｅｔｊｍｐ（  ）及びｌｏｎｇｊｍｐ（  ）は、処理又はスレッドの状態を保存すること及び回復することとそれぞれ同一であると伝統的にみなされる関数名である。
【００９０】
ステップ５２３では、実行中のワークアイテムスレッドが実行を完了したかどうかが決定される。ステップ５０７に関連して説明したように、ワークアイテムスレッドが実行を完了したかどうかの決定は、コールバック機能又は定期的なクエリに基づき得る。ワークアイテムが実行を完了したと決定されると、ステップ５２５において、更なるワークアイテムスレッドが、最後に遭遇した同期点から終わりまで実行されるべきかどうかが決定される。実行されるべきである場合には、次のワークアイテムがスケジューリングされ、そして実行されるべき各ワークアイテムに対してステップ５２１〜５２５が繰り返される。
【００９１】
ワークグループのワークアイテムスレッドの全てが実行を完了したならば、ステップ５２７において、現在選択されているＣＰＵコア上で他のワークグループがスケジューリングされるべきかどうかが決定される。他のワークグループがスケジューリングされるべきである場合には、他のワークグループの各々に対してステップ５１３〜５２７が繰り返される。
【００９２】
図６はワークアイテムスレッド実行をグラフ的に示している。６０１においては、ワークアイテムスレッドＷｉ０，…Ｗｉｎ−１は、ワークグループの全てのワークアイテムが始めから終りまで実行されるまで次々に実行される。６０１は、同期が必要とされない場合を示している。６０２においては、ワークアイテムスレッドＷｉ０，…Ｗｉｎ−１は、ワークグループの全てのワークアイテムが始めから最初の同期点まで実行されるまで次々に実行され、最初の同期点はここではｂａｒｒｉｅｒ（  ）への呼び出しと共に表示されている。ワークグループの全てのワークアイテムが始めからｂａｒｒｉｅｒ（  ）まで実行された後、これらのワークアイテムの各１つが、当該同期点から終りまで次々と実行される。
【００９３】
結論
概要及び要約の部は、発明者によって検討された本発明の１つ以上のしかし全部ではない例示的な実施形態を記述することができ、従って本発明及び添付の特許請求の範囲を限定することが意図されているわけではけっしてない。
【００９４】
特定の機能及びそれらの関係性の実装を示す機能構築ブロックを補助として、本発明が上述のように説明されてきた。これらの機能構築ブロックの境界は、説明の便宜上ここでは適宜画定されてきた。特定の機能及びそれらの関係が適切に実行される限りにおいて、代替的な境界が画定されてよい。
【００９５】
特定の実施形態の上述した説明は、本発明の一般的性質を十分に明らかにするであろうから、他者は、当業者の知識を適用することによって、過度の実験を必要とせず、本発明の概略的概念から逸脱することなく、そのような特定の実施形態を容易に修正し且つ／又は種々の応用に適用することができる。従って、そのような適用及び修正は、ここで提示されている教示及び指針に基いて、開示されている実施形態と均等なものの意味及び範囲の範疇にあることが意図されている。ここでの用語等は、本明細書の用語等が教示及び指針の下で当業者によって解釈されるべきであるという点において、説明を目的としたものであって限定を目的としていないことが理解されるべきである。
【００９６】
本発明の広さ及び範囲は、上述したいかなる例示的な実施形態によっても限定されるべきではなく、以下の特許請求の範囲及びそれらと均等なものに従ってのみ画定されるべきである。
【図１】
0005934094.tif 000002
【図２】
0005934094.tif 000003
【図３】
0005934094.tif 000004
【図５】
0005934094.tif 000005
【図６】
0005934094.tif 000006
【図４】
0005934094.tif 000007