(57)【要約】複数の計算ユニットへの分割ワークグループのディスパッチを実行するためのシステム、装置、及び方法を開示する。システムは、少なくとも複数の計算ユニット、制御ロジック、及びディスパッチユニットを含む。制御ロジックは、複数の計算ユニット間のリソース競合を監視し、リソース競合に基づいて計算ユニットごとに負荷率を計算する。ディスパッチユニットは、ディスパッチのためにワークグループを受信し、計算された負荷率に基づいて、ワークグループを複数の計算ユニットにディスパッチする方法を決定する。ワークグループが計算ユニットの現在利用可能なリソースに基づいて単一の計算ユニット内に適合することができない場合、ディスパッチユニットは、ワークグループをその個々のウェーブフロントに分割し、ワークグループのウェーブフロントを異なる計算ユニットにディスパッチする。ディスパッチユニットは、計算された負荷率に基づいて、ウェーブフロントを計算ユニットのうちの特定のものにディスパッチする方法を決定する。【選択図】図４
2021522593.tif 000002
【特許請求の範囲】
【請求項１】
インストラクションを実行するように設定される回路を含む複数の計算ユニットと、
ワークグループを前記複数の計算ユニットにディスパッチするように設定される回路を含むディスパッチユニットと、を備えるプロセッサであって、
前記複数の計算ユニットの現在利用可能なリソースに基づいて、ワークグループが単一の計算ユニット内に適合しないと決定することに応答して、前記ディスパッチユニットから別々の計算ユニットへのディスパッチのために前記ワークグループを個々のウェーブフロントに分割し、
前記複数の計算ユニット間のリソース競合を減少させることに基づいて、前記ワークグループの個々のウェーブフロントを前記複数の計算ユニットにディスパッチするためのプロセスを決定する、
ように設定される、プロセッサ。
【請求項２】
前記ディスパッチユニットから別々の計算ユニットへのディスパッチのために前記ワークグループを個々のウェーブフロントに分割することは、
前記ワークグループの第一ウェーブフロントを第一計算ユニットにディスパッチすることと、
前記ワークグループの第二ウェーブフロントを第二計算ユニットにディスパッチすることであって、前記第二ウェーブフロントは前記第一ウェーブフロントとは異なり、前記第二計算ユニットは前記第一計算ユニットとは異なる、前記ディスパッチすることと、
を備える、請求項１に記載のプロセッサ。
【請求項３】
前記プロセッサは、スコアボードをさらに含み、
前記プロセッサは、
前記ワークグループのウェーブフロントを追跡するエントリを前記スコアボードに割り振り、
前記エントリにおいて、所与のバリアに到達したウェーブフロントの数を追跡し、
前記所与のバリアに到達した前記ウェーブフロントの数が前記ワークグループ内のウェーブフロントの総数に等しい場合にウェーブフロントが進行することを可能にする信号を２つ以上の計算ユニットに送信する、
ようにさらに設定される、請求項１に記載のプロセッサ。
【請求項４】
前記２つ以上の計算ユニットは、前記エントリ内の計算ユニットマスクフィールドによって識別される、請求項３に記載のプロセッサ。
【請求項５】
前記プロセッサは、
複数のパフォーマンスカウンタを監視して、前記複数の計算ユニット間のリソース競合を追跡し、
前記複数のパフォーマンスカウンタに基づいて、各計算ユニット及び各リソースについて負荷率を計算し、
計算された負荷率に基づいて、前記ワークグループのウェーブフロントを前記複数の計算ユニットに割り振る方法を決定する、
ようにさらに設定される、請求項１に記載のプロセッサ。
【請求項６】
前記プロセッサは、第一計算ユニットが、第一リソースについて前記複数の計算ユニット間で最低の負荷率を有すると決定することに応答して、ディスパッチのための候補として前記第一計算ユニットを選択するようにさらに設定される、請求項５に記載のプロセッサ。
【請求項７】
前記複数のパフォーマンスカウンタは、ベクトル算術論理演算装置（ＶＡＬＵ）実行帯域幅、スカラーＡＬＵ（ＳＡＬＵ）実行帯域幅、ローカルデータ共有（ＬＤＳ）帯域幅、ロードストアバス帯域幅、ベクトルレジスタファイル（ＶＲＦ）帯域幅、スカラーレジスタファイル（ＳＲＦ）帯域幅、キャッシュサブシステム容量、キャッシュ帯域幅、及びトランスレーションルックアサイドバッファ（ＴＬＢ）帯域幅のうちの２つ以上を追跡する、請求項５に記載のプロセッサ。
【請求項８】
複数の計算ユニットの現在利用可能なリソースに基づいて、ワークグループが単一の計算ユニット内に適合しないと決定することに応答して、別々の計算ユニットへのディスパッチのために前記ワークグループを個々のウェーブフロントに分割することと、
前記複数の計算ユニット間のリソース競合を減少させることに基づいて、前記ワークグループの個々のウェーブフロントを前記複数の計算ユニットにディスパッチするためのプロセスを決定することと、
を備える、方法。
【請求項９】
別々の計算ユニットへのディスパッチのために前記ワークグループを個々のウェーブフロントに分割することは、
前記ワークグループの第一ウェーブフロントを第一計算ユニットにディスパッチすることと、
前記ワークグループの第二ウェーブフロントを第二計算ユニットにディスパッチすることであって、前記第二ウェーブフロントは前記第一ウェーブフロントとは異なり、前記第二計算ユニットは前記第一計算ユニットとは異なる、前記ディスパッチすることと、
を備える、請求項８に記載の方法。
【請求項１０】
前記ワークグループのウェーブフロントを追跡するエントリをスコアボードに割り振ることと、
前記エントリにおいて、所与のバリアに到達したウェーブフロントの数を追跡することと、
前記所与のバリアに到達した前記ウェーブフロントの数が前記ワークグループ内のウェーブフロントの総数に等しい場合にウェーブフロントが進行することを可能にする信号を２つ以上の計算ユニットに送信することと、
をさらに備える、請求項８に記載の方法。
【請求項１１】
前記２つ以上の計算ユニットは、前記エントリ内の計算ユニットマスクフィールドによって識別される、請求項８に記載の方法。
【請求項１２】
複数のパフォーマンスカウンタを監視して、前記複数の計算ユニット間のリソース競合を追跡することと、
前記複数のパフォーマンスカウンタに基づいて、各計算ユニット及び各リソースについて負荷率を計算することと、
計算された負荷率に基づいて、前記ワークグループのウェーブフロントを前記複数の計算ユニットに割り振る方法を決定することと、
をさらに備える、請求項８に記載の方法。
【請求項１３】
第一計算ユニットが第一リソースについて前記複数の計算ユニット間で最低の負荷率を有すると決定することに応答して、ディスパッチのための候補として前記第一計算ユニットを選択する、請求項１２に記載の方法。
【請求項１４】
前記複数のパフォーマンスカウンタは、ベクトル算術論理演算装置（ＶＡＬＵ）実行帯域幅、スカラーＡＬＵ（ＳＡＬＵ）実行帯域幅、ローカルデータ共有（ＬＤＳ）帯域幅、ロードストアバス帯域幅、ベクトルレジスタファイル（ＶＲＦ）帯域幅、スカラーレジスタファイル（ＳＲＦ）帯域幅、キャッシュサブシステム容量、キャッシュ帯域幅、及びトランスレーションルックアサイドバッファ（ＴＬＢ）帯域幅のうちの２つ以上を追跡する、請求項１２に記載の方法。
【請求項１５】
メモリと、
前記メモリに結合されるプロセッサと、を含むシステムであって、
前記プロセッサは、
前記複数の計算ユニットの現在利用可能なリソースに基づいて、ワークグループが単一の計算ユニット内に適合しないと決定することに応答して、別々の計算ユニットへのディスパッチのために前記ワークグループを個々のウェーブフロントに分割し、
前記複数の計算ユニット間のリソース競合を減少させることに基づいて、前記ワークグループの個々のウェーブフロントを前記複数の計算ユニットにディスパッチするためのプロセスを決定する、
ように設定される、前記システム。
【請求項１６】
別々の計算ユニットへのディスパッチのために前記ワークグループを個々のウェーブフロントに分割することは、
前記ワークグループの第一ウェーブフロントを第一計算ユニットにディスパッチすることと、
前記ワークグループの第二ウェーブフロントを第二計算ユニットにディスパッチすることであって、前記第二ウェーブフロントは前記第一ウェーブフロントとは異なり、前記第二計算ユニットは前記第一計算ユニットとは異なる、前記ディスパッチすることと、
を備える、請求項１５に記載のシステム。
【請求項１７】
前記プロセッサは、スコアボードをさらに含み、
前記プロセッサは、
前記ワークグループのウェーブフロントを追跡するエントリを前記スコアボードに割り振り、
前記エントリにおいて、所与のバリアに到達したウェーブフロントの数を追跡し、
前記所与のバリアに到達した前記ウェーブフロントの数が前記ワークグループ内のウェーブフロントの総数に等しい場合にウェーブフロントが進行することを可能にする信号を２つ以上の計算ユニットに送信する、
ようにさらに設定される、請求項１５に記載のシステム。
【請求項１８】
前記２つ以上の計算ユニットは、前記エントリ内の計算ユニットマスクフィールドによって識別される、請求項１７に記載のシステム。
【請求項１９】
前記プロセッサは、
複数のパフォーマンスカウンタを監視して、前記複数の計算ユニット間のリソース競合を追跡し、
前記複数のパフォーマンスカウンタに基づいて、各計算ユニット及び各リソースについて負荷率を計算し、
計算された負荷率に基づいて、前記ワークグループのウェーブフロントを前記複数の計算ユニットに割り振る方法を決定する、
ようにさらに設定される、請求項１５に記載のシステム。
【請求項２０】
前記プロセッサは、第一計算ユニットが第一リソースについて前記複数の計算ユニット間で最低の負荷率を有すると決定することに応答して、ディスパッチのための候補として前記第一計算ユニットを選択するようにさらに設定される、請求項１９に記載のシステム。
【発明の詳細な説明】
【背景技術】
【０００１】
本発明は、米国エネルギー省によって与えられたＬａｗｒｅｎｃｅ  Ｌｉｖｅｒｍｏｒｅ  Ｎａｔｉｏｎａｌ  Ｓｅｃｕｒｉｔｙ，Ｐｒｉｍｅ  Ｃｏｎｔｒａｃｔ  Ｎｏ．ＤＥ−ＡＣ５２−０７ＮＡ２７３４４，Ｓｕｂｃｏｎｔｒａｃｔ  Ｎｏ．Ｂ６２０７１７によるＰａｔｈＦｏｒｗａｒｄ  Ｐｒｏｊｅｃｔの下、政府の支援を受けて行われた。米国政府は、本発明に一定の権利を有する。
【０００２】
関連技術の説明
グラフィックスプロセッシングユニット（ＧＰＵ）は、グラフィックス処理タスクを実行する複雑な集積回路である。例えば、ＧＰＵは、ビデオゲームアプリケーションなどのエンドユーザアプリケーションに必要なグラフィックス処理タスクを実行する。ＧＰＵは、グラフィックスとは関係のない他のタスクを実行するためにもますます使用されている。一部の実施態様では、ＧＰＵは、別個のデバイスである、または中央処理装置（ＣＰＵ）などの別のプロセッサと同じデバイスに含まれる。
【０００３】
ＧＰＵでのグラフィックス処理など、多くのアプリケーションでは、スレッドとも称されることができる、ワークアイテムシーケンスは、最終結果を出力するために処理される。一実施態様では、各処理素子は、着信データを処理するために特定のワークアイテムのそれぞれのインスタンス化を実行する。ワークアイテムは、計算ユニット上に呼び出されるカーネルの並列実行のコレクションのうちの１つである。ワークアイテムは、グローバルＩＤ及びローカルＩＤにより、コレクション内の他の実行と区別される。本明細書に使用される場合、「計算ユニット」という用語は、複数のワークアイテムの同期実行を実行する処理素子（例えば、シングルインストラクション、マルチプルデータ（ＳＩＭＤ）ユニット）のコレクションとして定義される。計算ユニットあたりの処理素子の数は、実施態様ごとに異なることができる。計算ユニット上で合わせて同時に実行するワークグループ内の１サブセットのワークアイテムは、ウェーブフロント、ワープ、またはベクトルと称されることができる。ウェーブフロントの幅は、計算ユニットのハードウェアの特性である。本明細書で使用される場合、ウェーブフロントのコレクションは、「ワークグループ」と称される。ＧＰＵは、ワークグループの粒度で基盤となる計算リソースに作業をディスパッチする。通常、ワークグループは、全ワークグループをサポートするためのすべてのリソースが単一の計算ユニット上で利用可能である場合にディスパッチされる。これらのリソースは、少なくともベクトル及びスカラーレジスタ、ウェーブフロントスロット、ならびにローカルデータ共有（ＬＤＳ）スペースを含む。現在のＧＰＵハードウェアは、所与の計算ユニットがワークグループ内のすべてのウェーブフロントに必要なリソースを含まない場合に、ワークグループを所与の計算ユニットにディスパッチすることを可能にしない。これは、リソースの可用性がないことが原因で、ワークグループのストールにおける増加を導く。これは、アプリケーションによって行われる前進に直接影響を与え、ＧＰＵのウェーブフロントレベル並列性（ＷＬＰ）及びスレッドレベル並列性（ＴＬＰ）を低下させる。
【０００４】
添付図面と共に以下の説明を参照することによって、本明細書に記載される方法及び機構の利点をより良く理解することができよう。
【図面の簡単な説明】
【０００５】
【図１】コンピューティングシステムの一実施態様のブロック図である。
【図２】コンピューティングシステムの別の実施態様のブロック図である。
【図３】ＧＰＵの一実施態様のブロック図である。
【図４】ＧＰＵにおけるワークグループの分割ディスパッチの一実施態様のブロック図である。
【図５】ワークグループディスパッチ制御ロジックの一実施態様のブロック図である。
【図６】フィードバックベースの計算ユニット選択メカニズムの一実施態様のブロック図である。
【図７】計算ユニットに接続される分割ワークグループスコアボードを備えるＧＰＵの一実施態様のブロック図である。
【図８】分割ディスパッチワークグループのスコアボード追跡の一実施態様のブロック図である。
【図９】分割ワークグループディスパッチを実行するための方法の一実施態様を示す一般化された流れ図である。
【図１０】分割ワークグループのウェーブフロントの進行を追跡するためにスコアボードを使用する方法の一実施態様を示す一般化された流れ図である。
【図１１】分割ワークグループのウェーブフロントを割り振るために計算ユニットを選択する方法の一実施態様を示す一般化された流れ図である。
【図１２】計算ユニット間のリソース競合を最小限にするためにワークグループのウェーブフロントをディスパッチする方法の一実施態様を示す一般化された流れ図である。
【発明を実施するための形態】
【０００６】
以下の説明では、本明細書で提示される方法及び機構の完全な理解をもたらすために、多数の特定の詳細が示される。しかしながら、当業者は、それらの特定の詳細なしにさまざまな実施態様を実践し得ることを認識するべきである。いくつかの例では、本明細書で説明されるアプローチを曖昧にすることを回避するために、周知の構造、コンポーネント、信号、コンピュータプログラムインストラクション、及び技術が詳細には示されていない。例示の簡潔性及び明確さのために、図に示される要素は、必ずしも縮尺通りに描かれていないことは理解されよう。例えば、要素のいくつかの寸法は、他の要素に対して誇張されてよい。
【０００７】
複数の計算ユニットへの「分割（ｓｐｌｉｔ）」（または代替に「分割（ｄｉｖｉｄｅｄ）」）ワークグループのディスパッチを実行するために、さまざまなシステム、装置、方法、及びコンピュータ可読媒体を本明細書に開示する。プロセッサ（例えば、グラフィックスプロセッシングユニット（ＧＰＵ））は、少なくとも複数の計算ユニット、制御ロジック、及びディスパッチユニットを含む。ディスパッチユニットは、ワークグループをＧＰＵの計算ユニットにディスパッチする。通常、ワークグループは、全ワークグループをサポートするためのすべてのリソースが単一の計算ユニット上で利用可能である場合にディスパッチされる。これらのリソースは、少なくともベクトル及びスカラーレジスタ、ウェーブフロントスロット、ならびにローカルデータ共有（ＬＤＳ）スペースを含む。ただし、ハードウェアは、ウェーブフロントの粒度でスレッドを実行し、ウェーブフロントはワークグループ内の１サブセットのスレッドである。ハードウェア実行の単位がディスパッチの単位よりも小さいため、ハードウェアがワークグループディスパッチ要求を拒否することが一般的であるが、そのワークグループを形成する１サブセットのウェーブフロントをサポートすることは依然として可能である。ディスパッチと実行粒度との間のこの矛盾は、特定のアプリケーションについてプロセッサ上で達成可能なＴＬＰ及びＷＬＰを制限する。
【０００８】
一実施態様では、制御ロジックは、複数の計算ユニット間のリソース競合を監視し、リソース競合に基づいて計算ユニットごとに負荷率を計算する。ディスパッチユニットは、ディスパッチのためにワークグループを受信し、計算された負荷率に基づいて、ワークグループを複数の計算ユニットにディスパッチする方法を決定する。ワークグループが計算ユニットの現在利用可能なリソースに基づいて単一の計算ユニット内に適合することができない場合、ディスパッチユニットは、ワークグループをその個々のウェーブフロントに分割し、ワークグループのウェーブフロントを異なる計算ユニットにディスパッチする。一実施態様では、ディスパッチユニットは、計算された負荷率に基づいて、ウェーブフロントを計算ユニットの特定のものにディスパッチする方法を決定する。
【０００９】
一実施態様では、制御ロジックは、分割ワークグループのウェーブフロントの実行ステータスを追跡するためにスコアボードに結合される。制御ロジックは、複数の計算ユニットにディスパッチされたウェーブフロントに分割されたワークグループについてスコアボード内の新しいエントリを割り振る。いずれかのウェーブフロントがバリアインストラクションに到達するときに、対応する計算ユニットは、制御ロジックにインディケーションを送信する。このインディケーションを受信することに応答して、制御ロジックは、対応するスコアボードエントリ内にバリア取得フラグフィールドを設定する。次に、計算ユニットは、その他のウェーブフロントがバリアに到達するときに信号を送信する。制御ロジックは、対応するスコアボードエントリ内のバリア取得カウントをインクリメントし、バリア取得カウントがワークグループについてウェーブフロントの総数に到達するときに、制御ロジックは、ウェーブフロントが進行することを可能にする信号を計算ユニットに送信する。一実施態様では、スコアボードエントリは、分割ワークグループのウェーブフロントを実行する計算ユニットを識別する計算ユニットマスクを含む。
【００１０】
ここで図１を参照して、コンピューティングシステム１００の一実施態様のブロック図を示す。一実施態様では、コンピューティングシステム１００は、少なくともプロセッサ１０５Ａ〜Ｎ、入出力（Ｉ／Ｏ）インタフェース１２０、バス１２５、メモリコントローラ（複数可）１３０、ネットワークインタフェース１３５、及びメモリデバイス（複数可）１４０を含む。他の実施態様では、コンピューティングシステム１００は他のコンポーネントを含む、及び／またはコンピューティングシステム１００は異なって配置される。プロセッサ１０５Ａ〜Ｎは、システム１００に含まれる任意の数のプロセッサを表す。
【００１１】
一実施態様では、プロセッサ１０５Ａは、中央処理装置（ＣＰＵ）などの汎用プロセッサである。この実施態様では、プロセッサ１０５Ｎは、高度な並列アーキテクチャを備えるデータ並列プロセッサである。データ並列プロセッサは、グラフィックスプロセッシングユニット（ＧＰＵ）、デジタルシグナルプロセッサ（ＤＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）などを含む。いくつかの実施態様では、プロセッサ１０５Ｂ〜Ｎは、複数のデータ並列プロセッサを含む。各データ並列プロセッサは、複数の計算ユニットへのディスパッチのためにワークグループを分割することができる。各データ並列プロセッサは、ワークグループを複数の計算ユニットにディスパッチして、計算ユニット間のリソース競合を最小限にすることもできる。これらの機能、及び他の機能を実装するための技術は、本開示の残りの部分でより詳細に説明される。
【００１２】
メモリコントローラ（複数可）１３０は、Ｉ／Ｏインタフェース１２０に結合されるプロセッサ１０５Ａ〜Ｎ及びＩ／Ｏデバイス（図示せず）によってアクセス可能な任意の数及びタイプのメモリコントローラを表す。メモリコントローラ（複数可）１３０は、任意の数及びタイプのメモリデバイス（複数可）１４０に結合される。メモリデバイス（複数可）１４０は、いずれかの数及びタイプのメモリデバイスを表す。例えば、メモリデバイス（複数可）１４０におけるメモリのタイプは、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ＮＡＮＤフラッシュメモリ、ＮＯＲフラッシュメモリ、強誘電体ランダムアクセスメモリ（ＦｅＲＡＭ）、または他のものを含む。
【００１３】
Ｉ／Ｏインタフェース１２０は、いずれかの数及びタイプのＩ／Ｏインタフェース（例えば、ペリフェラルコンポーネントインターコネクト（ＰＣＩ）バス、ＰＣＩ−Ｅｘｔｅｎｄｅｄ（ＰＣＩ−Ｘ）、ＰＣＩＥ（ＰＣＩ  Ｅｘｐｒｅｓｓ）バス、ギガビットイーサネット（ＧＢＥ）バス、ユニバーサルシリアルバス（ＵＳＢ））を表す。さまざまなタイプのペリフェラルデバイス（図示せず）は、Ｉ／Ｏインタフェース１２０に結合される。それらのようなペリフェラルデバイスは、ディスプレイ、キーボード、マウス、プリンタ、スキャナ、ジョイスティックまたは他のタイプのゲームコントローラ、メディア記録デバイス、外部ストレージデバイス、ネットワークインタフェースカードなどを含む（がそれらに限定されない）。ネットワークインタフェース１３５は、ネットワークを介してネットワークメッセージを送受信するために使用される。
【００１４】
さまざまな実施態様では、コンピューティングシステム１００は、コンピュータ、ラップトップ、モバイルデバイス、ゲームコンソール、サーバ、ストリーミングデバイス、ウェアラブルデバイス、またはさまざまな他のタイプのコンピューティングシステムもしくはデバイスのいずれかである。コンピューティングシステム１００のコンポーネントの数が実施態様ごとに異なることに留意する。例えば、他の実施態様では、図１に示された数よりも多い、または少ない各コンポーネントがある。また他の実施態様では、コンピューティングシステム１００が図１に示されていない他のコンポーネントを含むことに留意する。加えて、他の実施態様では、コンピューティングシステム１００は、図１に示された以外の方式において構造化される。
【００１５】
ここで図２を参照して、コンピューティングシステム２００の別の実施態様のブロック図を示す。一実施態様では、システム２００は、ＧＰＵ２０５、システムメモリ２２５及びローカルメモリ２３０を含む。また、システム２００は、図を曖昧にすることを回避するために示されない他のコンポーネントを含む。ＧＰＵ２０５は、少なくともコマンドプロセッサ２３５、制御ロジック２４０、ディスパッチユニット２５０、計算ユニット２５５Ａ〜Ｎ、メモリコントローラ２２０、グローバルデータ共有部２７０、レベル１（Ｌ１）キャッシュ２６５、及びレベル２（Ｌ２）キャッシュ２６０を含む。他の実施態様では、ＧＰＵ２０５は、他のコンポーネントを含む、図示されたコンポーネントのうちの１つ以上を省略する、図２に１つのインスタンスのみが示されている場合でも１つのコンポーネントの複数のインスタンスを有する、及び／または他の適切な方法で編成される。例えば、別の実施態様では、ＧＰＵ２０５は、複数のディスパッチユニットを含む。
【００１６】
さまざまな実施態様では、コンピューティングシステム２００は、さまざまなタイプのソフトウェアアプリケーションのいずれかを実装する。コマンドプロセッサ２４０は、ホストＣＰＵ（図示せず）からコマンドを受信し、ディスパッチユニット２５０を使用して計算ユニット２５５Ａ〜Ｎにコマンドを発行する。計算ユニット２５５Ａ〜Ｎ上で実行するカーネル内のスレッドは、ＧＰＵ２０５内のグローバルデータ共有部２７０、Ｌ１キャッシュ２６５、及びＬ２キャッシュ２６０にデータを読み出し、書き込む。図２には示されないが、計算ユニット２５５Ａ〜Ｎは、各計算ユニット２５５Ａ〜Ｎ内に１つ以上のキャッシュ及び／またはローカルメモリも含む。
【００１７】
コマンドプロセッサ２４０は、ＧＰＵ２０５についてさまざまなタスクを実行する。例えば、コマンドプロセッサ２４０は、計算タスク、ダイレクトメモリアクセス（ＤＭＡ）を介するデータ移動操作、及びさまざまなカーネル後クリーンアップアクティビティをスケジュールする。制御ロジック２４０は、ＧＰＵ２０５のリソース間のリソース競合を監視し、リソース競合を最小限にするためにウェーブフロントを計算ユニット２５５Ａ〜Ｎにディスパッチする方法をディスパッチユニット２５０が決定するのを援助する。一実施態様では、制御ロジック２４０は、計算ユニット２５５Ａ〜Ｎ間のリソース競合を監視するために、スコアボード２４５及びパフォーマンスカウンタ（ＰＣ）２４７Ａ〜Ｎを含む。パフォーマンスカウンタ２４７Ａ〜Ｎは、ベクトル算術論理演算装置（ＶＡＬＵ）実行帯域幅、スカラーＡＬＵ（ＳＡＬＵ）実行帯域幅、ローカルデータ共有（ＬＤＳ）帯域幅、ロードストアバス帯域幅、ベクトルレジスタファイル（ＶＲＦ）帯域幅、スカラーレジスタファイル（ＳＲＦ）帯域幅、キャッシュサブシステム容量及びＬ１、Ｌ２及びＬ３キャッシュを含む帯域幅及びＴＬＢなどのリソース、ならびに他のリソースを監視するための任意の数のパフォーマンスカウンタを表す。
【００１８】
制御ロジック２４０は、スコアボード２４５を使用して、複数の計算ユニット２５５Ａ〜Ｎにディスパッチされる分割ワークグループのウェーブフロントを監視する。例えば、スコアボード２４５は、複数の異なる計算ユニット２５５Ａ〜Ｎ上で実行している所与の分割ワークグループの異なるウェーブフロントを追跡する。スコアボード２４５は、所与の分割ワークグループについてのエントリを含み、そのエントリは、所与の分割ワークグループのウェーブフロントの数、ウェーブフロントが実行している特定の計算ユニット、ワークグループＩＤなどを識別する。スコアボードエントリは、いずれかのウェーブフロントがバリアに到達したことを示すバリア同期有効フィールドも含む。ウェーブフロントがバリアに到達するときに、計算ユニットは、ウェーブフロントをストールさせる。スコアボードエントリは、バリアに到達したウェーブフロントの数を追跡する、バリア取得カウントを含む。バリア取得カウントが所与のワークグループのウェーブフロントの総数に到達するときに、制御ロジック２４０は、今からウェーブフロントが進行することを可能にすることを、関連する計算ユニットに通知する。
【００１９】
一実施態様では、システム２００は、カーネル２２７の２つのコンパイルされたバージョンをシステムメモリ２２５に格納する。例えば、カーネル２２７Ａの１つのコンパイルされたバージョンは、バリアインストラクションを含み、別々の計算ユニット２５５Ａ〜Ｎ上で実行されるウェーブフロントを同期させるための中央メカニズムとしてスコアボード２４５を使用する。カーネル２２７Ｂのもう１つのコンパイルされたバージョンは、別々の計算ユニット２５５Ａ〜Ｎ上で実行されるウェーブフロントを同期させる、グローバルデータ共有部２７０のインストラクション、またはアトミック操作をメモリに使用する。カーネル２２７Ａ及びカーネル２２７Ｂの両方は、アプリケーションのバイナリに利用可能であり、実行時に利用可能である。コマンドプロセッサ２３５及び制御ロジック２４０は、実行時に、対応するワークグループのウェーブフロントを計算ユニット２５５Ａ〜Ｎにディスパッチするときに使用するカーネルを決定する。使用するカーネル（２２７Ａまたは２２７Ｂ）の決定は、消費電力目標、パフォーマンス目標、計算ユニット２５５Ａ〜Ｎ間のリソース競合、及び／または他の要因のうちの１つ以上に基づいて行われる。
【００２０】
ここで図３を参照して、ＧＰＵ３００の一実施態様のブロック図を示す。ＧＰＵ３００について、ワークグループ（ＷＧ）３０２のディスパッチを検討している。４つのウェーブフロントを有するワークグループ３０２の例が例示目的のために示されるに過ぎないことを理解されたい。他の実施態様では、ワークグループは、４つ以外の他の数のウェーブフロントを有する。さらに、４つの計算ユニット３１０〜３１３を有するＧＰＵ３００の例も、一実施態様の例示として意図されるに過ぎない。他の実施態様では、ＧＰＵ３００は、４つ以外の他の数の計算ユニットを含む。
【００２１】
計算ユニット３１０〜３１３の現在の割り振りは、図３の右側に示される。占有されたリソースホールを網掛け矩形として示し、利用可能なリソースホールを透明な矩形として示す。計算ユニット３１０〜３１３の現在の割り振りから分かるように、個々の計算ユニット３１０〜３１３のいずれも、ワークグループ３０２の４つのウェーブフロントのすべてに適合するのに十分な利用可能なリソースを含まない。したがって、従来のＧＰＵ３００について、ワークグループ３０２のディスパッチをストールする。
【００２２】
ここで図４を参照して、ＧＰＵ４００におけるワークグループ４０２の分割ディスパッチの一実施態様のブロック図を示す。ＧＰＵ４００は、図３に示されるＧＰＵ３００に類似し、ＧＰＵ４００が４つの計算ユニット４１０〜４１３を含み、ワークグループ４０２が４つのウェーブフロントを含む。ただし、この例が一実施態様を示すに過ぎないことを理解されたい。他の実施態様では、ＧＰＵ４００及び／またはワークグループ４０２は、他の数のコンポーネントを含む。
【００２３】
しかしながら、図３に示される例とは対照的に、ＧＰＵ４００は、ワークグループ４０２をウェーブフロントスプリットの異なる組み合わせに分割し、ウェーブフロントを異なる計算ユニット４１０〜４１３に割り振って、ワークグループ４０２の即時ディスパッチを可能にすることができる。ＧＰＵ４００がワークグループ４０２をウェーブフロントスプリットの異なる組み合わせに分割することができ、実際のウェーブフロントスプリットが実施態様ごとに異なることができることを理解されたい。一実施態様では、ワークグループ４０２のウェーブフロント０〜２を計算ユニット４１２に割り振り、ワークグループ４０２のウェーブフロント３を計算ユニット４１０に割り振る。ワークグループ４０２の割り振りを分割することによって、これは、計算ユニットがワークグループ４０２全体を割り振るのに十分なリソースを含むまで待機するのではなく、ワークグループ４０２を即時に割り振ることを可能にする。これは、ＧＰＵ４００上で実行するアプリケーションについて、より高いウェーブフロントレベル並列性（ＷＬＰ）及びスレッドレベル並列性（ＴＬＰ）をもたらす。
【００２４】
ここで図５を参照して、ワークグループディスパッチ制御ロジック５００の一実施態様のブロック図を示す。一実施態様では、ワークグループディスパッチ制御ロジック５００のコンポーネントをＧＰＵ２０５（図２の）の制御ロジック２４０に含む。ワークグループディスパッチ制御ロジック５００は、分割ワークグループディスパッチャ５０６を含む。分割ワークグループディスパッチャ５０６は、ワークグループが単一の計算ユニット内に適合することができない場合に、ワークグループ割り振り失敗検出ユニット５０２からトリガを受信するスコアボードチェッカ５０８を含む。スコアボードチェッカ５０８は、所与のワークグループのウェーブフロントに適合するのに十分な利用可能なリソースがホストＧＰＵの計算ユニットにあるかどうかを判定するクエリを適合検出ユニット５１０に行う。一実施態様では、適合検出ユニット５１０は、ウェーブフロントを計算ユニットに適合させるために、最大適合（Ｍａｘ  Ｆｉｔ）５１０Ａアプローチ、均等適合（Ｅｑｕａｌ  Ｆｉｔ）５１０Ｂアプローチ、またはプログラム可能な適合５１０Ｃアプローチを使用する。最大適合５１０Ａアプローチは、複数のウェーブフロントを同じ計算ユニットに割り振ることにより、ウェーブフロントを最小数の計算ユニットに適合させようとする。均等適合５１０Ｂアプローチは、ウェーブフロントを計算ユニットのすべてにわたり均等に拡散させようとする。プログラム可能な適合５１０Ｃアプローチは、プログラム可能なポリシーに従ってウェーブフロントを計算ユニットに適合させようとする。他の実施態様では、適合検出ユニット５１０は、ウェーブフロントを計算ユニットに適合させるために他のアプローチを使用する。複数の計算ユニット内に十分な利用可能なリソースがあった場合、計算ユニットセレクタ５１２は、フィードバックメカニズムに基づいて、所与のワークグループを利用可能な計算ユニットに割り振る方法を決定する。このフィードバックメカニズムは、パフォーマンスカウンタの値を使用して、ＧＰＵの利用可能な計算ユニット上でのリソース使用率及びリソース競合を追跡する。
【００２５】
一実施態様では、計算ユニットセレクタ５１２は、ブロック５１６に示されるような選択メカニズムを含む。計算ユニット（ＣＵ）セレクタ５１２は、所与のワークグループのウェーブフロントを利用可能な計算ユニットに割り振る方法を決定する際に使用する複数の選択アルゴリズムのうちの１つを選択する。例えば、ブロック５１６に示されるように、計算ユニットセレクタ５１２は、所与のワークグループのウェーブフロントを利用可能な計算ユニットに割り振る方法を決定する３つの別個のアルゴリズムから選択する。他の実施態様では、計算ユニットセレクタ５１２は、３つ以外の他の数のアルゴリズムから選択する。
【００２６】
第一アルゴリズムは、所与のワークグループのウェーブフロントを割り振るための計算ユニットを選択する、ラウンドロビン、先着順（ＲＲ−ＦＣＦＳ）アルゴリズムである。第二アルゴリズムは、パフォーマンスカウンタからのフィードバックを使用して利用可能な計算ユニットのすべての中から最もストールが少ない計算ユニットを決定する、最小計算ストール計算ユニットアルゴリズム（ＦＢ−ＣＯＭＰ）である。次に、分割ワークグループディスパッチャ５０６は、最もストールが少ないと識別される計算ユニットにウェーブフロントを割り振る。第三アルゴリズムは、所与のワークグループのウェーブフロントを最小メモリストール計算ユニット（ＦＢ−ＭＥＭ）に割り振ろうとする。分割ワークグループディスパッチャ５０６は、パフォーマンスカウンタを使用して、最もメモリストールが少ない計算ユニットを決定した後に、分割ワークグループディスパッチャ５０６は、これらの識別された計算ユニットにウェーブフロントを割り振る。他の実施態様では、他のタイプのアルゴリズムを用いる。
【００２７】
実施態様に応じて、使用されるアルゴリズムのタイプは、ソフトウェア及び／またはハードウェアによって動的に調整される。一実施態様では、管理者は、使用されるアルゴリズムのタイプを選択する。別の実施態様では、ユーザアプリケーションは、使用されるアルゴリズムのタイプを選択する。ユーザアプリケーションは選択するアルゴリズムの固定ポリシーを有する、またはユーザアプリケーションは操作条件に基づいてアルゴリズムのタイプを動的に調整する。さらなる実施態様では、オペレーティングシステム（ＯＳ）またはドライバは、ワークグループのウェーブフロントを利用可能な計算ユニットに割り振るために使用されるアルゴリズムのタイプを選択する。他の実施態様では、分割ワークグループディスパッチアルゴリズムを選択する他の技術が可能であり、企図されている。
【００２８】
所与のワークグループが個々のウェーブフロントに分割され、複数の計算ユニットに割り振られた後に、分割ワークグループディスパッチャ５０６は、所与のワークグループについてスコアボード５１４内のエントリを割り振る。次に、分割ワークグループディスパッチャ５０６は、スコアボードエントリを使用して、異なる計算ユニット上でのこれらのウェーブフロントの実行進行を追跡する。スコアボード５１４は、実施態様に応じて任意の数のエントリを有する。例えば、スコアボードエントリの一例をボックス５０４に示す。例えば、一実施態様では、スコアボード５１４の各スコアボードエントリは、仮想マシン識別子（ＶＭＩＤ）フィールド、グローバルワークグループＩＤフィールド、ワークグループ寸法フィールド、ワークグループフィールド内のウェーブフロントの数、ワークグループからウェーブフロントを割り振られた計算ユニットを識別する計算ユニットマスクフィールド、バリアに到達したウェーブフロントの数を追跡するバリアカウントフィールド、及び少なくとも１つのウェーブフロントがバリアに到達したことを示すバリア同期有効フィールドを含む。他の実施態様では、スコアボードエントリは、他のフィールドを含む、及び／または他の適切な方法で編成される。
【００２９】
ここで図６を参照して、フィードバックベースの計算ユニット（ＣＵ）選択メカニズム６１０の一実施態様のブロック図を示す。フィードバックベースのＣＵセレクタ６１０は、ワークグループ（ＷＧ）割り振り要求バッファ６１５及びパフォーマンス監視モジュール６２０を含む。他の実施態様では、フィードバックベースのＣＵセレクタ６１０は、他のコンポーネントを含む、及び／または他の適切な方法で構造化される。ＷＧ割り振り要求バッファ６１５は、割り振りのために受信したワークグループを格納する。ＷＧ割り振り要求バッファ６１５は、所与のワークグループのウェーブフロントをＧＰＵの利用可能な計算ユニット（ＣＵ）に割り振る方法を決定する、割り振り要求をパフォーマンス監視モジュール６２０に伝達する。パフォーマンス監視モジュール６２０は、所与のワークグループのウェーブフロントの数、及び現在利用可能なＣＵリソースに基づいて、適合または不適合のインディケーションをＷＧ割り振り要求バッファ６１５に伝達する。ＷＧ割り振り要求バッファ６１５がパフォーマンス監視モジュール６２０から適合インディケーションを受信するときに、ＷＧ割り振り要求バッファ６１５は、割り振り確認をディスパッチユニット（図示せず）に送信する。
【００３０】
一実施態様では、パフォーマンス監視モジュール６２０は、さまざまなパフォーマンスカウンタから値を収集し、これらの値を追跡するためにＣＵレベル及びＳＩＭＤレベルのテーブルを実装する。さまざまな実施態様では、パフォーマンスカウンタは、ベクトル算術論理演算装置（ＶＡＬＵ）実行帯域幅、スカラーＡＬＵ（ＳＡＬＵ）実行帯域幅、ローカルデータ共有（ＬＤＳ）帯域幅、ロードストアバス帯域幅、ベクトルレジスタファイル（ＶＲＦ）帯域幅、スカラーレジスタファイル（ＳＲＦ）帯域幅、ならびにキャッシュサブシステム容量及びＬ１、Ｌ２及びＬ３キャッシュを含む帯域幅及びＴＬＢなどのリソースを監視する。ＣＵパフォーマンス（ｐｅｒｆ）コンパレータ６３５は所与のディスパッチＩＤ（例えば、カーネルＩＤ）について各ＣＵの負荷率を決定するためのロジックを含み、ＣＵ  ｐｅｒｆコンパレータ６３５は計算された負荷率に基づいて好ましいＣＵ宛先を選択する。一実施態様では、負荷率は、現在占有されているＣＵのパーセンテージとして、または現在使用されている、もしくは現在割り振られている所与のリソースのパーセンテージとして計算される。一実施態様では、ＣＵの異なるリソースの負荷率を合わせて加算し、ＣＵについて負荷率を生成する。一実施態様では、異なる重み付け係数を異なるリソースのさまざまな負荷率に適用し、ＣＵ全体について負荷率を生成する。シェーダプロセッサ入力リソース割り振り（ＳＰＩ−ＲＡ）ユニット６４０は、所与のワークグループに好ましいＣＵ（複数可）上のリソースを割り振る。
【００３１】
ここで図７を参照して、計算ユニット７１０Ａ〜Ｎに接続される分割ワークグループ（ＷＧ）スコアボード７２０を備えるＧＰＵ７００の一実施態様のブロック図を示す。一実施態様では、ＧＰＵ７００は、少なくとも計算ユニット７１０Ａ〜Ｎ及び分割ＷＧディスパッチャ７１５を含む。また、ＧＰＵ７００は、図を曖昧にすることを回避するために示されない、いずれかの数のさまざまな他のコンポーネントを含む。計算ユニット７１０Ａ〜Ｎは、いずれかの数及びタイプの計算ユニットを表す。各計算ユニット７１０Ａ〜Ｎは、ワークアイテムを並行して実行するための複数のシングルインストラクション、マルチプルデータ（ＳＩＭＤ）ユニットを含む。一実施態様では、各計算ユニット７１０Ａ〜Ｎは、４つのＳＩＭＤユニットを含む。他の実施態様では、各計算ユニット７１０Ａ〜Ｎは、４つ以外の他の数のＳＩＭＤユニットを含む。
【００３２】
所与のワークグループが複数の計算ユニット７１０Ａ〜Ｎ上でのディスパッチのために分割される場合、分割ＷＧディスパッチャ７１５は、分割ＷＧスコアボード７２０を使用して、計算ユニット７１０Ａ〜Ｎ上での所与のワークグループのウェーブフロントの実行を追跡する。計算ユニット７１０は、分割ＷＧのいずれかのウェーブフロントがバリアインストラクションに到達するときに、バリア同期有効メッセージをスコアボード７２０に送信する。スコアボードエントリのバリア取得カウントフィールドは、このバリアに到達するウェーブフロントごとにインクリメントされる。分割ＷＧのすべてのウェーブがバリアに到達したときに、スコアボード７２０は、ウェーブが実行を継続することを可能にすることを、分割スコアボード計算ユニットマスク内で識別される各計算ユニット７１０Ａ〜Ｎに通知する。一実施態様では、スコアボード７２０は、バリア取得メッセージを送信することによって、各計算ユニット７１０Ａ〜Ｎに通知する。
【００３３】
ここで図８を参照して、分割ディスパッチワークグループのスコアボード追跡の一実施態様のブロック図を示す。一実施態様では、６つのウェーブフロントを有するワークグループ８０５を、ＧＰＵ８００の計算ユニット８１０Ａ〜Ｈの複数の計算ユニットにディスパッチする。６つのウェーブフロントを有するワークグループ８０５の例が一実施態様を示すに過ぎないことに留意する。他の実施態様では、ワークグループ８０５は、他の数のウェーブフロントを有する。８つの計算ユニット８１０Ａ〜Ｈを有するＧＰＵ８００の例が一実施態様を示すに過ぎないことにも留意する。他の実施態様では、ＧＰＵ８００は、他の数の計算ユニットを含む。
【００３４】
ワークグループ８０５の６つのウェーブフロントが計算ユニット８１０Ａ〜Ｈのいかなる単一の計算ユニットにも適合することができないので、これら６つのウェーブフロントを分割し、複数の計算ユニットに割り振る。図８に示されるように、ウェーブフロント０〜１を計算ユニット８１０Ａに割り振り、ウェーブフロント２〜３を計算ユニット８１０Ｆに割り振り、ウェーブフロント４〜５を計算ユニット８１０Ｇに割り振る。他の実施態様では、ワークグループの６つのウェーブフロントのすべてを計算ユニット８１０Ａ〜Ｈの利用可能なリソースホールに割り振るように、他の適切な方法で、ワークグループ８０５のウェーブフロントを計算ユニット８１０Ａ〜Ｈに割り振る。
【００３５】
一実施態様では、スコアボード８２０は、計算ユニット８１０Ａ〜Ｈ上でのワークグループ８０５のウェーブフロントの実行を追跡するために使用される。図８の最下部に示されるスコアボード８２０Ａ〜Ｆは、６つの異なる時点でスコアボード８２０を表すためのものであり、スコアボード８２０Ａがより早い時点を表し、スコアボード８２０Ｆがより遅い時点を表し、その他のスコアボード８２０Ｂ〜Ｅがその間の時点を表す。スコアボード８２０Ａは、計算ユニット８１０Ａ〜Ｈへのウェーブフロントの割り振り直後のワークグループ８０５の状態を表す。仮想マシン識別子（ＶＭＩＤ）フィールドは、オペレーティングシステムによって指定されるような一意のアプリケーションコンテキスト識別子を指定する。複数のアプリケーションは、別個のＶＭＩＤを含むＧＰＵ上で実行することができる。ワークグループ（ＷＧ）ＩＤ及びグローバルＷＧ  ＩＤフィールドはワークグループ８０５を識別し、ウェーブフィールドの数はワークグループ８０５内のウェーブフロントの数を指定する。計算ユニットマスクは、計算ユニット８１０Ａ〜Ｈのどれがワークグループ８０５からウェーブフロントを割り振られたかを示す。バリアカウントフィールドは、バリア同期有効フィールドが設定されるときにバリアに到達したウェーブフロントの数を示す。スコアボード８２０Ａは、ワークグループ８０５のいかなるウェーブフロントも、まだバリアに到達していないことを示す。
【００３６】
スコアボード８２０Ｂは、最初のウェーブフロントがバリアインストラクションに到達したことを示す。ウェーブフロントがバリアインストラクションに到達した結果として、計算ユニットの対応するＳＩＭＤユニットは、バリア同期有効インディケーションをスコアボード８２０Ｂに送信する。バリア同期有効インディケーションを受信することに応答して、スコアボード８２０Ｂのバリア同期有効フィールドは設定される。スコアボード８２０Ｃは、スコアボード８２０Ｂによって表される時点に続く時点を表す。この点について考察する目的で、ウェーブフロントｗｖ０及びｗｖ１がこの後続の時点までにバリアにヒットしたと仮定する。ウェーブフロントｗｖ０及びｗｖ１がバリアにヒットすることに応答して、計算ユニット８１０Ａ内のＳＩＭＤユニットは、バリアカウント更新インディケーションをスコアボード８２０Ｃに送信する。バリアカウント更新インディケーションを受信した結果として、スコアボード８２０Ｃは、ワークグループ８０５についてバリアカウントを２にインクリメントする。
【００３７】
スコアボード８２０Ｄは、スコアボード８２０Ｃによって表される時点に続く時点を表す。この点について考察する目的で、ウェーブフロントｗｖ４及びｗｖ５がこの後続の時点までにバリアにヒットしたと仮定する。ウェーブフロントｗｖ４及びｗｖ５がバリアにヒットしたことに応答して、計算ユニット８１０Ｇ内のＳＩＭＤユニットは、バリアカウント更新インディケーションをスコアボード８２０Ｄに送信する。スコアボード８２０Ｄは、計算ユニット８１０Ｇからバリアカウント更新インディケーションを受信した後に、ワークグループ８０５についてバリアカウントを４にインクリメントする。
【００３８】
スコアボード８２０Ｅは、スコアボード８２０Ｄによって表される時点に続く時点を表す。この点について考察する目的で、ウェーブフロントｗｖ２及びｗｖ３がこの後続の時点までにバリアにヒットしたと仮定する。ウェーブフロントｗｖ２及びｗｖ３がバリアにヒットしたことに応答して、計算ユニット８１０Ｆ内のＳＩＭＤユニットは、バリアカウント更新インディケーションをスコアボード８２０Ｅに送信する。バリアカウント更新インディケーションを受信した結果として、スコアボード８２０Ｅは、ワークグループ８０５についてバリアカウントを６にインクリメントする。
【００３９】
スコアボード８２０Ｆは、スコアボード８２０Ｅによって表される時点に続く時点を表す。ウェーブフロントの数に等しいバリアカウントフィールドによって示されるように、この時点までにすべてのウェーブがバリアにヒットしたことから、制御ロジックは、ワークグループ８０５のすべてのウェーブフロントについてバリアが取得された信号を、計算ユニットマスクフィールド内で識別されるすべての計算ユニットに送る。その結果、これらの計算ユニット内のＳＩＭＤユニットは、ウェーブフロントを実行に取りかからせることができる。バリアカウントフィールド及びバリア同期有効フィールドは、スコアボード８２０Ｆについてのエントリに示されるように、ワークグループ８０５のすべてのウェーブフロントによってバリアが取得された後にクリアされる。
【００４０】
ここで図９を参照して、分割ワークグループディスパッチを実行するための方法９００の一実施態様を示す。考察する目的で、この実施態様におけるステップ、及び図１０〜１２のこれらのステップを順番に示す。ただし、記載された方法のさまざまな実施態様では、記載される要素のうちの１つ以上が、同時に実行される、示されるのとは異なる順に実行される、または全体的に省略されることに留意する。他の追加の要素も必要に応じて実行される。本明細書に記載されるさまざまなシステムまたは装置のいずれも、方法９００を実施するように構成される。
【００４１】
ＧＰＵのディスパッチユニットは、単一の計算ユニットの利用可能なリソース内に適合しない、ディスパッチ用のワークグループを受信する（ブロック９０５）。次に、ディスパッチユニットは、ワークグループが分割される場合に、ワークグループの個々のウェーブフロントが複数の計算ユニット内に適合することができるかどうかを決定する（条件ブロック９１０）。ワークグループが個々のウェーブフロントに分割されているにもかかわらず、ワークグループが利用可能な計算ユニットリソース内に適合することができなかった場合（条件ブロック９１０、「いいえ」脚部）、ディスパッチユニットは、より多くの計算ユニットリソースが利用可能になるまで待機する（ブロック９１５）。ブロック９１５の後、方法９００は条件ブロック９１０に戻る。ワークグループが分割されることによって利用可能な計算ユニットリソース内に適合することができた場合（条件ブロック９１０、「はい」脚部）、ディスパッチユニットは、複数の計算ユニットにわたるワークグループの割り振りを分割する（ブロック９２０）。
【００４２】
ブロック９２０の後、ＧＰＵは、スコアボードを使用して分割ワークグループのウェーブフロントの進行を追跡する（ブロック９２５）。分割ワークグループのウェーブフロントの進行を追跡するためにスコアボードを使用する一例は、方法１０００（図１０の）に関する考察において以下により詳細に説明される。ブロック９２５の後、方法９００は終了する。
【００４３】
ここで図１０を参照して、スコアボードを使用して分割ワークグループのウェーブフロントの進行を追跡するための方法１０００の一実施態様を示す。ディスパッチユニットは、分割され、個々のウェーブフロントとしてＧＰＵの複数の計算ユニットに割り振られたワークグループについて新しいスコアボードエントリを割り振る（ブロック１００５）。また、制御ロジックは、ワークグループの個々のウェーブフロントが割り振られた計算ユニットを示すように、スコアボードエントリの計算ユニットマスクフィールドを設定する（ブロック１０１０）。次に、ワークグループの個々のウェーブフロントの実行を開始する（ブロック１０１５）。ワークグループのウェーブフロントが同期する必要がある場合（条件ブロック１０１７、「はい」脚部）、計算ユニットは、それらのウェーブフロントがバリアに到達したかどうかを監視する（条件ブロック１０２０）。ワークグループのウェーブフロントが同期する必要がない場合（条件ブロック１０１７、「いいえ」脚部）、制御ロジック及び計算ユニットは、ウェーブフロントを互いから独立して実行することを可能にする（ブロック１０１８）。ブロック１０１８の後、方法１０００は終了する。
【００４４】
ウェーブフロントのいずれかがバリアに到達した場合（条件ブロック１０２０、「はい」脚部）、対応する計算ユニットは、スコアボードにインディケーションを送信する（ブロック１０２５）。インディケーションを受信することに応答して、スコアボードエントリのバリア同期有効フィールドを設定する（ブロック１０３０）。いかなるウェーブフロントもバリアに到達していない場合（条件ブロック１０２０、「いいえ」脚部）、ＧＰＵは、ウェーブフロントの進行を監視し続ける（ブロック１０３５）。ブロック１０３５の後、方法１０００は、条件ブロック１０２０に戻る。
【００４５】
ブロック１０３０の後、制御ロジックは、所与のバリアにヒットする各ウェーブフロントについてスコアボードエントリ内のバリア取得カウントをインクリメントする（ブロック１０４０）。次に、制御ロジックは、バリア取得カウントがワークグループ内のウェーブフロントの総数に到達したかどうかを判定する（条件ブロック１０４５）。バリア取得カウントがワークグループ内のウェーブフロントの総数に到達した場合（条件ブロック１０４５、「はい」脚部）、制御ロジックは、スコアボードエントリのバリア取得カウント及びバリア同期有効フィールドをリセットし、ウェーブフロントが進行することを可能にする信号を、計算マスクフィールドによって識別される計算ユニットに送る（ブロック１０５０）。バリア取得カウントがワークグループ内のウェーブフロントの総数に到達していない場合（条件ブロック１０４５、「いいえ」脚部）、方法１０００は条件ブロック１０２０に戻る。最終バリアに到達した場合（条件ブロック１０５５、「はい」脚部）、方法１０００は終了する。そうでなければ、最終バリアに到達していない場合（条件ブロック１０５５、「いいえ」脚部）、方法１０００は条件ブロック１０２０に戻る。
【００４６】
ここで図１１を参照して、分割ワークグループのウェーブフロントを割り振るために計算ユニットを選択する方法１１００の一実施態様を示す。制御ロジックは、ＧＰＵの計算ユニット全体のリソース使用率及び競合を監視する（ブロック１１０５）。監視されているリソースは、少なくともベクトル算術論理演算装置（ＶＡＬＵ）実行帯域幅、スカラーＡＬＵ（ＳＡＬＵ）実行帯域幅、ローカルデータ共有（ＬＤＳ）帯域幅、ロードストアバス帯域幅、ベクトルレジスタファイル（ＶＲＦ）帯域幅、スカラーレジスタファイル（ＳＲＦ）帯域幅、ならびにキャッシュサブシステム容量及びＬ１、Ｌ２及びＬ３キャッシュを含む帯域幅及びＴＬＢを含む。一実施態様では、制御ロジックは、パフォーマンスカウンタを使用して、ＧＰＵの計算ユニット全体のリソース使用率及び競合を監視する。
【００４７】
次に、ディスパッチユニットは、ディスパッチのためにワークグループを受信する（ブロック１１１０）。ディスパッチユニットは、リソース競合、及びワークグループの予測されたビヘイビアに基づいて、ワークグループのウェーブフロントをさまざまな計算ユニットにディスパッチする方法を決定する（ブロック１１１５）。実施態様に応じて、ディスパッチユニットは、ワークグループのウェーブフロントをＧＰＵの計算ユニットにディスパッチする方法を決定するためのさまざまなポリシーのいずれかを使用する。実施態様に応じて、ディスパッチユニットは、従来のディスパッチ、単一ユニットワークグループディスパッチ、または分割ワークグループディスパッチを実行することを決定する。さらに、使用されるポリシーは、最大適合ポリシー、均等適合ポリシー、及びプログラム可能な適合ポリシーを含む（がこれらに限定されない）。最大適合ポリシーは、ウェーブを最小数の計算ユニットに割り当てる。均等適合ポリシーは、分割ワークグループのウェーブフロントを候補の計算ユニット間で均等に拡散させようとする。プログラム可能な適合ポリシーは、分割ワークグループのウェーブフロントを計算ユニット全体に拡散させて、計算ユニット全体の負荷率を最小限にする。ブロック１１１５の後、方法１１００は終了する。
【００４８】
ここで図１２を参照して、計算ユニット間のリソース競合を最小限にするためにワークグループのウェーブフロントをディスパッチする方法の一実施態様を示す。ＧＰＵの制御ロジックは、追跡するリソースを決定し、プログラム可能なコンテキスト設定レジスタを介してこれらのリソースを設定する（ブロック１２０５）。一実施態様では、プログラム可能なコンテキスト設定レジスタは、カーネルモードドライバによって更新される。次に、制御ロジックは、複数のプログラムカウンタによってリソース使用率を追跡する（ブロック１２１０）。プログラムカウンタによって監視されているリソースの例は、少なくともＶＡＬＵ実行帯域幅、ＳＡＬＵ実行帯域幅、ＬＤＳ帯域幅、ロードストアバス帯域幅、ＶＲＦ帯域幅、ＳＲＦ帯域幅、ならびにキャッシュサブシステム容量及びＬ１、Ｌ２及びＬ３キャッシュを含む帯域幅及びＴＬＢを含む。
【００４９】
次いで、制御ロジックは、プログラム可能なインターバルでプログラムカウンタをサンプリングする（ブロック１２１５）。次に、制御ロジックは、選択された各リソースについて各計算ユニットの負荷率を計算する（ブロック１２２０）。一実施態様では、制御ロジックは、ディスパッチＩＤごとに、選択された各リソースに対する各計算ユニットの負荷率を計算する。一実施態様では、ディスパッチＩＤは、コマンドプロセッサによる実行のためにディスパッチされるカーネルを識別する単調に増加する数である。一実施態様では、各アプリケーションコンテキストまたはＶＭＩＤは、単調に増加する独自のディスパッチＩＤカウンタを含む。次に、ディスパッチユニットは、ＧＰＵの計算ユニットにディスパッチする新しいワークグループを検出する（ブロック１２２５）。ディスパッチユニットは、各計算ユニットの負荷率をチェックする（ブロック１２３０）。次に、ディスパッチユニットは、選択された各リソースについて最低の負荷率を有する計算ユニット（複数可）をディスパッチのための候補（複数可）として選択する（ブロック１２３５）。次に、ディスパッチユニットは、ワークグループのウェーブフロントを選択された計算ユニット（複数可）にディスパッチする（ブロック１２４０）。ブロック１２４０の後、方法１２００は終了する。
【００５０】
さまざまな実施態様では、ソフトウェアアプリケーションのプログラムインストラクションを使用して、本明細書に記載される方法及び／またはメカニズムを実装する。例えば、汎用または特殊目的プロセッサによって実行可能なプログラムインストラクションが企図される。さまざまな実施態様では、それらのようなプログラムインストラクションは、高水準プログラミング言語によって表現される。他の実施態様では、プログラムインストラクションは、高水準プログラミング言語から、バイナリ、中間、または他の形式にコンパイルされる。代替に、プログラムインストラクションは、ハードウェアのビヘイビアまたは設計を記述するように書き込まれる。これらのようなプログラムインストラクションをＣなどの高水準プログラミング言語によって表現する。代替に、Ｖｅｒｉｌｏｇなどのハードウェア設計言語（ＨＤＬ）を使用する。さまざまな実施態様では、プログラムインストラクションは、さまざまな非一時的なコンピュータ可読記憶媒体のいずれかに格納される。記憶媒体は、プログラム実行のためにプログラムインストラクションをコンピューティングシステムに提供するために使用される間にコンピューティングシステムによってアクセス可能である。概して、そのようなコンピューティングシステムは、プログラムインストラクションを実行するように構成された少なくとも１つ以上のメモリ及び１つ以上のプロセッサを含む。
【００５１】
上記の実施態様が、実施態様の非限定的な例にすぎないことを強調する必要がある。上記の開示が一旦完全に理解されると、多くの変形及び修正が当業者にとって明らかになるであろう。以下の特許請求の範囲は、全てのそのような変形及び修正を包含すると解釈されることが意図される。
【図１】
2021522593.tif 000003
【図２】
2021522593.tif 000004
【図３】
2021522593.tif 000005
【図４】
2021522593.tif 000006
【図５】
2021522593.tif 000007
【図６】
2021522593.tif 000008
【図７】
2021522593.tif 000009
【図８】
2021522593.tif 000010
【図９】
2021522593.tif 000011
【図１０】
2021522593.tif 000012
【図１１】
2021522593.tif 000013
【図１２】
2021522593.tif 000014
【国際調査報告】
2021522593.tif 000015
2021522593.tif 000016