(57)【特許請求の範囲】
【請求項１】
アクセラレーテッド処理デバイス（ＡＰＤ）が、中央処理装置（ＣＰＵ）に対して複数のタスクの処理を要求することを可能にする方法であって、
前記ＡＰＤを用いて、前記複数のタスクを、前記ＣＰＵが認識可能なキューにエンキューするステップと、
前記ＡＰＤを用いて、前記複数のタスクの処理を担当するＣＰＵスレッドをアクティブにするユーザレベルインタラプト（ＵＬＩ）を生成するステップと、
前記ＡＰＤを用いてエンキューされた前記複数のタスクを、前記ＣＰＵスレッドを用いて、前記ＣＰＵ上で処理するステップと、
を含む方法。
【請求項２】
前記複数のタスクの処理に応じて、前記ＣＰＵスレッドから結果を受信するステップをさらに含む、
請求項１に記載の方法。
【請求項３】
前記複数のタスクは、１つ以上のシェーダコアを用いてキューに加えられる、
請求項１に記載の方法。
【請求項４】
中央処理装置（ＣＰＵ）が、アクセラレーテッド処理デバイス（ＡＰＤ）からの複数のタスクを処理するための方法であって、
前記ＡＰＤによって前記複数のタスクがエンキューされたキューであって、前記ＣＰＵが認識可能なキューに関連するユーザレベルインタラプト（ＵＬＩ）を、前記ＡＰＤから受信するステップと、
前記ＵＬＩに関連するインタラプトハンドラにアクセスするステップであって、前記インタラプトハンドラは、ＣＰＵスレッドに対して、前記複数のタスクがエンキューされたキューにアクセスさせるステップと、
前記ＣＰＵスレッドを用いて、前記複数のタスクを前記ＣＰＵ上で処理するステップと、
を含む方法。
【請求項５】
前記タスクの処理に応じて、前記ＣＰＵスレッドから前記ＡＰＤに結果を送信するステップをさらに含む、
請求項４に記載の方法。
【請求項６】
前記インタラプトハンドラは、前記複数のタスクが処理されている間、ワークを前記ＡＰＤに提供するサブルーチンにアクセスする、
請求項４に記載の方法。
【請求項７】
サブルーチンは、前記ＡＰＤの状況を照会する、
請求項４に記載の方法。
【請求項８】
前記ＵＬＩは、非同期のインタラプトである、
請求項４に記載の方法。
【請求項９】
前記ＣＰＵスレッドは、前記ＵＬＩが発生したときを示すレジスタを含む、
請求項４に記載の方法。
【請求項１０】
前記インタラプトハンドラが前記複数のタスクをスキャンするステップをさらに含む、
請求項４に記載の方法。
【請求項１１】
前記スキャンするステップに基づいて、前記複数のタスクを処理するステップを優先させるステップをさらに含む、
請求項１０に記載の方法。
【請求項１２】
前記処理されたタスクの結果を、前記ＡＰＤに送信するステップをさらに含む、
請求項４に記載の方法。
【請求項１３】
アクセラレーテッド処理デバイス（ＡＰＤ）が、中央処理装置（ＣＰＵ）に対して複数のタスクの処理を要求することを可能にするシステムであって、
前記ＡＰＤ及び前記ＣＰＵが認識可能な記憶領域を格納するように構成されたメモリと、
前記ＡＰＤとを備え、
前記ＡＰＤは、
前記複数のタスクをキューにエンキューし、
前記複数のタスクの処理を担当するＣＰＵスレッドをアクティブにするユーザレベルインタラプト（ＵＬＩ）を生成し、
前記ＡＰＤを用いてエンキューされた前記複数のタスクを、前記ＣＰＵスレッドを用いて、前記ＣＰＵ上で処理する、ように構成されている、
システム。
【請求項１４】
前記ＡＰＤは、前記ＣＰＵが前記複数のタスクを処理することに応じて、前記ＣＰＵスレッドから結果を受信する、
請求項１３に記載のシステム。
【請求項１５】
前記複数のタスクは、前記ＡＰＤ内の１つ以上のシェーダコアを用いてエンキューされる、
請求項１３に記載のシステム。
【請求項１６】
中央処理装置（ＣＰＵ）が、アクセラレーテッド処理デバイス（ＡＰＤ）からの複数のタスクを処理することを可能にするシステムであって、
前記ＡＰＤ及び前記ＣＰＵが認識可能なキューを格納するように構成されたメモリと、
前記ＣＰＵ上で実行されるＣＰＵスレッドとを備え、
前記ＣＰＵスレッドは、
前記複数のタスクが前記ＡＰＤによってエンキューされた前記キューが処理を要求していることを示すユーザレベルインタラプト（ＵＬＩ）を受信したことに応じて、アクティブになり、
前記ＵＬＩに関連するインタラプトハンドラであって、前記キューに記憶された前記複数のタスクにアクセスするインタラプトハンドラにアクセスし、
前記ＣＰＵに前記複数のタスクを処理させる、ように構成されている、
システム。
【請求項１７】
前記ＣＰＵは、前記複数のタスクの処理に応じて、前記ＣＰＵスレッドから前記ＡＰＤに結果を送信する、
請求項１６に記載のシステム。
【請求項１８】
前記インタラプトハンドラは、前記複数のタスクが処理されている間、前記ＡＰＤにワークを提供するサブルーチンにアクセスする、
請求項１６に記載のシステム。
【請求項１９】
サブルーチンは、前記ＡＰＤの状況を照会する、
請求項１６に記載のシステム。
【請求項２０】
前記ＵＬＩは、非同期のインタラプトである、
請求項１６に記載のシステム。
【請求項２１】
前記ＣＰＵスレッドは、前記ＵＬＩが発生したときを示すレジスタを含む、
請求項１６に記載のシステム。
【請求項２２】
前記ＣＰＵスレッドは、前記複数のタスクをスキャンするように構成されている、
請求項１６に記載のシステム。
【請求項２３】
前記スキャンに基づいて、前記キューの前記複数のタスクの処理を優先させることをさらに含む、
請求項１６に記載のシステム。
【請求項２４】
コンピューティングデバイスによって実行されると、アクセラレーテッド処理デバイス（ＡＰＤ）が、中央処理装置（ＣＰＵ）に対して複数のタスクの処理を要求することを可能にする方法を前記コンピューティングデバイスに実行させる命令を記憶するコンピュータ可読媒体であって、
前記命令は、
前記ＡＰＤを用いて、前記複数のタスクを、前記ＣＰＵが認識可能なキューにエンキューすることと、
前記ＡＰＤを用いて、前記複数のタスクの処理を担当するＣＰＵスレッドをアクティブにするユーザレベルインタラプト（ＵＬＩ）を生成することと、
前記ＡＰＤを用いてエンキューされた前記複数のタスクを、前記ＣＰＵスレッドを用いて、前記ＣＰＵ上で処理することと、を含む、
コンピュータ可読媒体。
【請求項２５】
コンピューティングデバイスによって実行されると、中央処理装置（ＣＰＵ）が、アクセラレーテッド処理デバイス（ＡＰＤ）からの複数のタスクを処理することが可能になる操作を前記コンピューティングデバイスに実行させる命令を記憶するコンピュータ可読媒体であって、
前記命令は、
前記ＡＰＤによって前記複数のタスクがエンキューされたキューであって、前記ＣＰＵが認識可能なキューに関連するユーザレベルインタラプト（ＵＬＩ）を、前記ＡＰＤから受信することと、
前記ＵＬＩに関連するインタラプトハンドラにアクセスすることであって、前記インタラプトハンドラは、ＣＰＵスレッドに対して、前記複数のタスクがエンキューされたキューにアクセスさせることと、
前記ＣＰＵスレッドを用いて、前記複数のタスクを前記ＣＰＵ上で処理することと、を含む、
コンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、コンピュータシステムを対象とする。さらに詳細には、本発明は、コンピュータシステムインタラプト処理に関する。
【背景技術】
【０００２】
グラフィックス処理ユニット（ＧＰＵ：ｇｒａｐｈｉｃｓ  ｐｒｏｃｅｓｓｉｎｇ  ｕｎｉｔ）を一般的な演算に用いる要請は、ＧＰＵの単位電力および／またはコストあたりの能力が優れることから、最近ではより顕著となってきている。ＧＰＵの計算能力は、対応する中央処理装置（ＣＰＵ：ｃｅｎｔｒａｌ  ｐｒｏｃｅｓｓｉｎｇ  ｕｎｉｔ）の計算能力の成長速度を超える速度で成長してきた。モバイルコンピューティング市場（例えば、ノートブック、モバイルスマートフォン、タブレット、その他）およびその必要な支援サーバ／企業システムの爆発的な成長と組み合わされたこの成長は、特定品質の所望のユーザ経験を提供するために用いられてきている。したがって、並列データの内容を有する作業負荷を実行するためにＣＰＵとＧＰＵとを併用することはボリュームテクノロジとなりつつある。
【０００３】
しかし、ＧＰＵは、従来、主にグラフィックの高速化のために利用可能な制約されたプログラミング環境で動作する。これらの制約は、ＧＰＵが、ＣＰＵと同程度に豊かなプログラミングエコシステムを有さないという事実に起因するものである。したがって、ＧＰＵの使用は、主に、グラフィックスおよびビデオのアプリケーションプログラミングインターフェース（ＡＰＩ：ａｐｐｌｉｃａｔｉｏｎ  ｐｒｏｇｒａｍｍｉｎｇ  ｉｎｔｅｒｆａｃｅ）を処理することに既に順応した、２次元（２Ｄ）グラフィックスと、３次元（３Ｄ）グラフィックスと、少数の最先端マルチメディアアプリケーションとに限られていた。
【０００４】
マルチベンダにサポートされるＯｐｅｎＣＬ（登録商標）、ＤｉｒｅｃｔＣｏｍｐｕｔｅ（登録商標）、標準的なＡＰＩおよびサポート用ツールの出現とともに、従来の用途におけるＧＰＵの限界は、従来のグラフィックスを越えて拡張されてきている。ＯｐｅｎＣＬ（登録商標）およびＤｉｒｅｃｔＣｏｍｐｕｔｅ（登録商標）は将来性のあるスタートではあるが、大部分のプログラミングタスクに対して、ＣＰＵと同程度に流動的にＣＰＵとＧＰＵとの組合せが用いられることを可能にする環境およびエコシステムを作成するには、多数のハードルが残されている。
【０００５】
既存のコンピューティングシステムは、大抵、複数の処理装置を含む。例えば、いくつかのコンピューティングシステムは、ＣＰＵおよびＧＰＵの両方を、別個のチップ上（例えば、ＣＰＵはマザーボード上に、ＧＰＵはグラフィックカード上に配置され得る）または単一チップパッケージ上に有し得る。これらの構成の両方は、（ｉ）別個のメモリシステム、（ｉｉ）効率的なスケジューリング、（ｉｉｉ）プロセス間のサービス品質（ＱｏＳ）の保証の提供、（ｉｖ）プログラミングモデルおよび（ｖ）複数のターゲット命令セットアーキテクチャ（ＩＳＡ：ｉｎｓｔｒｕｃｔｉｏｎ  ｓｅｔ  ａｒｃｈｉｔｅｃｔｕｒｅ）へのコンパイル、の全項目を、電力消費を最小化しながら満足することに関して顕著な問題点を依然として含む。
【０００６】
例えば、個別チップ構成においては、各プロセッサがメモリにアクセスするためには、システムアーキテクチャおよびソフトウェアアーキテクチャは、チップ間インターフェースを利用することを余儀なくされる。これらの外部インターフェース（例えばチップ間インターフェース）においては、異機種環境のプロセッサを協働させるために、メモリレイテンシおよび電力消費に弊害がもたらされる一方で、別個のメモリシステム（すなわち、別個のアドレス空間）およびドライバに管理される共有メモリにおいては、きめ細かな負荷軽減に対しては許容されないオーバーヘッドが生成されてしまうこととなる。
【０００７】
ＣＰＵおよびＧＰＵを含むコンピューティングシステムにおいて、ある種のコマンドは、ＧＰＵ上で効率的に実行できず、ＣＰＵのアテンションを要求する。従来のシステムにおいて、ＧＰＵは、ＣＰＵにコマンドおよび命令を処理する要求を発行する。ＣＰＵは、要求を受信すると、インタラプトを発行するためにオペレーティングシステム（ＯＳ：ｏｐｅｒａｔｉｎｇ  ｓｙｓｔｅｍ）を呼び出し、ＯＳを使用して要求を処理する。しかし、ＧＰＵからの各要求を処理するためにＯＳを呼び出すことは、特にＧＰＵ内の複数のワークアイテムが反復要求を発行する場合には、コストがかかり、非効率的である。
【発明の概要】
【０００８】
したがって、ＣＰＵによるＧＰＵ要求の改善された処理のためのシステムおよび方法が必要とされる。
【０００９】
ＧＰＵと、アクセラレーテッドプロセッシングユニット（ＡＰＵ）と、ＧＰＵによる汎目的計算（ＧＰＧＰＵ）とは、この分野において一般に用いられる用語であるが、「アクセラレーテッド処理デバイス」（ＡＰＤ）は、より広い表現とみなされる。例えば、ＡＰＤは、従来のＣＰＵ、従来のＧＰＵ、ソフトウェアおよび／またはこれらの組合せと比較して高速化された方法で行われる、グラフィックス処理タスク、データ並列タスク、またはネスト化されたデータ並列タスクの高速化に関連する機能および演算を実行する任意のハードウェアおよび／またはソフトウェアの協働的集合体を指す。
【００１０】
本発明の実施形態は、ある特定の状況では、ＡＰＤがＣＰＵに複数のタスクの処理を要求する方法、システムおよび製品を含む。方法は、ＡＰＤを使用して、複数のタスクをキューに加える（エンキューする）ステップと、ユーザレベルインタラプトを生成するステップと、ＣＰＵスレッドに関連するインタラプトハンドラを用いて、キューの複数のタスクをＣＰＵに送信するステップとを含む。
【００１１】
また、本発明の実施形態は、ユーザレベルインタラプトをＡＰＤから受信することと、ＣＰＵスレッドのユーザレベルインタラプトに関連したインタラプトハンドラにアクセスすることであって、インタラプトハンドラは、複数のタスクを取り出す（デキューする）キューにアクセスし、キューに加えられた複数のタスクは、ＡＰＤを使用することと、キューから取り出されたタスクを処理することとを含む、ＣＰＵがＡＰＤからの複数のタスクを処理するための方法、システムおよび製品を含む。
【００１２】
本発明の追加的な特徴および利点、ならびに本発明の様々な実施形態の構造および動作は、添付の図面を参照して以下で詳細に説明される。本発明は、本明細書において説明される特定の実施形態に制限されないことに注意すべきである。係る実施形態は、例示目的のみのために、本明細書において提示される。追加的な実施形態は、本明細書に含まれる教示に基づいて、当業者（単数または複数）に明らかとなるであろう。
【００１３】
添付の図面は、本明細書に組み込まれ本明細書の一部を構成するものであって、本発明を例示し、説明とともに、本発明の原理を説明し、当業者が本発明を実施することを可能にするように、さらに機能する。本発明の様々な実施形態は、添付の図面を参照して以下で説明される。なお、添付の図面の全体を通じて、同様の参照番号は、同様の構成要素を参照するために用いられる。
【図面の簡単な説明】
【００１４】
【図１Ａ】本発明の実施形態に係る処理システムの例示的ブロック図である。
【図１Ｂ】図１Ａに示されたＡＰＤの例示的ブロック図である。
【図２】ユーザレベルインタラプト（ＵＬＩ：ｕｓｅｒ−ｌｅｖｅｌ  ｉｎｔｅｒｒｕｐｔｓ）を処理可能なＣＰＵスレッドの初期化プロセスの例示的なフロー図である。
【図３】ＡＰＤの要求を処理するＵＬＩと、ＣＰＵを発行するＡＰＤとの例示的なフロー図である。
【図４】ＵＬＩを用いてキューを処理することをＣＰＵに要求するＡＰＤの例示的なフロー図である。
【００１５】
本発明は、添付の図面を参照して説明される。概して、構成要素が最初に現れる図面は、通常、対応する参照番号の最も左側の桁（単数または複数）によって示される。
【発明を実施するための形態】
【００１６】
以下の詳細な説明においては、「１つの実施形態」、「ある実施形態」、「例示的実施形態」またはその他を参照することは、本明細書において説明される実施形態が、特定の特徴、構造または特性を有することを示すが、全ての実施形態が当該特定の特徴、構造または特性を必ずしも含むとは限らない。さらに、係る語句は、同一の実施形態を参照するとは限らない。さらに、特定の特徴、構造または特性が、１つの実施形態に関連して説明される場合、係る特長、構造または特性を他の実施形態との関連で実施することは、当業者の知識の範囲内であることが提起される。
【００１７】
「本発明の実施形態」という用語は、本発明の実施形態の全てが、検討の対象である特徴、特長または操作モードを含むことを必ずしも要求しない。代替的な実施形態が本発明の範囲から逸脱することなく考案され、本発明の既知の構成要素は、本発明の関連する詳細を不明瞭化しないために、必ずしも詳細に説明されるとは限らず、または省略され得る。また、本明細書において用いられる用語は、特定の実施形態を説明することのみを目的とし、本発明を制限することを意図するものではない。例えば、本明細書において用いられる単数形の「１つの」および「その」は、内容的に明らかに単数のみを指す場合を除き、複数形も含むことを意図するものである。本明細書において用いられる場合、「含む」、「備える」、「包含する」および／または「有する」という用語は、述べられた特徴、整数、ステップ、操作、構成要素および／またはコンポーネントが存在することを指定するが、１つまたは複数の他の特徴、整数、ステップ、操作、構成要素、コンポーネントおよび／またはこれらの群の存在または追加を除外しない。
【００１８】
図１Ａは、ＣＰＵ１０２およびＡＰＤ１０４を含む統合化されたコンピューティングシステム１００の例示的な図である。ＣＰＵ１０２は、１つ以上のシングルコアまたはマルチコアＣＰＵを含み得る。本発明の一実施形態において、システム１００は、統合化されたプログラミング環境および実行環境を提供するために、ＣＰＵ１０２およびＡＰＤ１０４を組み合わせた単一のシリコンダイまたはパッケージ上に形成される。この環境は、ＡＰＤ１０４が、いくつかのプログラミングタスクに対して、ＣＰＵ１０２と同程度に流動的に用いられることを可能にする。しかし、ＣＰＵ１０２およびＡＰＤ１０４が単一のシリコンダイ上に形成されることは、本発明の絶対的な要件ではない。いくつかの実施形態において、ＣＰＵ１０２およびＡＰＤ１０４は別個に形成され、同一の基板または異なる基板上に搭載されることが可能である。
【００１９】
１つの例において、システム１００は、メモリ１０６、オペレーティングシステム１０８および通信インフラストラクチャ１０９を含む。オペレーティングシステム１０８および通信インフラストラクチャ１０９は、以下でより詳細に説明される。
【００２０】
システム１００は、カーネルモードドライバ（ＫＭＤ：ｋｅｒｎｅｌ  ｍｏｄｅ  ｄｒｉｖｅｒ）１１０と、ソフトウェアスケジューラ（ＳＷＳ：ｓｏｆｔｗａｒｅ  ｓｃｈｅｄｕｌｅｒ）１１２と、例えば入出力メモリ管理ユニット（ＩＯＭＭＵ：ｉｎｐｕｔ／ｏｕｔｐｕｔ  ｍｅｍｏｒｙ  ｍａｎａｇｅｍｅｎｔ  ｕｎｉｔ）等のメモリ管理ユニット１１６とを含む。システム１００の構成品は、ハードウェア、ファームウェア、ソフトウェアまたはこれらの任意の組合せとして実装され得る。当業者は、システム１００が図１Ａに示される実施形態において示されるものに加えて、またはこれらとは異なる、１つ以上のソフトウェアコンポーネント、ハードウェアコンポーネントおよびファームウェアコンポーネントを含み得ることを理解するであろう。
【００２１】
１つの例において、ＫＭＤ１１０等のドライバは、通常、ハードウェアが接続されたコンピュータバスまたは通信サブシステムを通してデバイスと通信する。呼び出しプログラムがドライバにおいてルーチンを呼び出すと、ドライバは、デバイスに対してコマンドを発行する。デバイスがドライバに対してデータを戻すと、ドライバは、元の呼び出しプログラムにおいてルーチンを呼び出し得る。１つの例において、ドライバは、ハードウェア依存的であり、オペレーティングシステム固有である。ドライバは、通常、任意の必要な非同期的時間依存性のハードウェアインターフェースに対して要求されるインタラプトハンドリング（インタラプト処理）を提供する。
【００２２】
デバイスドライバは、特に現代のマイクロソフト・ウィンドウズ（登録商標）プラットフォームにおいては、カーネルモード（リング０）またはユーザモード（リング３）において実行され得る。ドライバをユーザモードにおいて実行することの主要な利益は、安定性が改善されることである。なぜなら、不完全な形で書かれたユーザモードデバイスドライバは、カーネルメモリを上書きすることによってシステムをクラッシュさせることができないためである。一方、ユーザモード／カーネルモードの遷移は、通常、顕著な性能オーバーヘッドを与え、それにより、低レイテンシおよび高スループット要件のためにユーザモードドライバを阻害する。カーネルスペースは、システムコールの使用を通してのみ、ユーザモジュールからのアクセスが可能である。ＵＮＩＸ（登録商標）シェルまたは他のＧＵＩベースのアプリケーションなどのエンドユーザプログラムは、ユーザスペースの一部である。これらのアプリケーションは、カーネルにサポートされた機能を通してハードウェアと相互作用する。
【００２３】
ＣＰＵ１０２は、制御プロセッサ、フィールド・プログラマブル・ゲートアレイ（ＦＰＧＡ：ｆｉｅｌｄ  ｐｒｏｇｒａｍｍａｂｌｅ  ｇａｔｅ  ａｒｒａｙ）、特定用途集積回路（ＡＳＩＣ：ａｐｐｌｉｃａｔｉｏｎ  ｓｐｅｃｉｆｉｃ  ｉｎｔｅｇｒａｔｅｄ  ｃｉｒｃｕｉｔ）またはデジタル・シグナル・プロセッサ（ＤＳＰ：ｄｉｇｉｔａｌ  ｓｉｇｎａｌ  ｐｒｏｃｅｓｓｏｒ）のうち１つ以上を含み得る（図示せず）。ＣＰＵ１０２は、例えば、コンピューティングシステム１００の動作を制御する、オペレーティングシステム１０８、ＫＭＤ１１０、ＳＷＳ１１２およびアプリケーション１１１を含む制御ロジックを実行する。この例示的な実施形態において、ＣＰＵ１０２は、１つの実施形態によれば、アプリケーション１１１の実行の起動および制御を、例えばそのアプリケーションに関連する処理をＣＰＵ１０２とＡＰＤ１０４等の他の処理リソースとの間に分散させることにより行う。
【００２４】
ＡＰＤ１０４は、とりわけ、グラフィックス演算や、例えば特に並列処理に好適となり得る他の演算等の、選択された機能のためのコマンドおよびプログラムを実行する。一般に、ＡＰＤ１０４は、ピクセル処理、幾何学演算およびディスプレイに対する画像のレンダリング等のグラフィックスパイプライン処理を実行するために、しばしば用いられ得る。本発明の様々な実施形態において、ＡＰＤ１０４は、ＣＰＵ１０２から受信したコマンドまたは命令に基づいて、計算処理演算（例えば、ビデオ演算、物理シミュレーション、計算流体力学、その他等の、グラフィックスに関連しない演算）も実行し得る。
【００２５】
例えば、コマンドは、命令セットアーキテクチャ（ＩＳＡ：ｉｎｓｔｒｕｃｔｉｏｎ  ｓｅｔ  ａｒｃｈｉｔｅｃｔｕｒｅ）において通常定義されない特殊な命令であるとみなされ得る。コマンドは、例えばディスパッチプロセッサ、コマンドプロセッサまたはネットワークコントローラ等の特殊なプロセッサにより実行され得る。一方、命令は、例えばコンピュータアーキテクチャ内のプロセッサの単一の演算であるとみなされ得る。１つの例において、２セットのＩＳＡが用いられる場合には、いくつかの命令は、ｘ８６プログラムを実行するために用いられ、いくつかの命令は、ＡＰＤユニット上でカーネルを実行するために用いられる。
【００２６】
例示的な実施形態において、ＣＰＵ１０２は、選択されたコマンドをＡＰＤ１０４に伝達する。これらの選択されたコマンドは、並列実行に適したグラフィックスコマンドと、並列実行に適した他のコマンドとを含み得る。計算処理コマンドを含み得るこれらの選択されたコマンドは、実質的にＣＰＵ１０２から独立して実行され得る。
【００２７】
ＡＰＤ１０４は、例えば１つ以上のＳＩＭＤ処理コア等ではあるがこれに制限されない、自身の計算ユニット（図示せず）を含み得る。本明細書で参照されるＳＩＭＤは、パイプライン、すなわち、それぞれが自身のデータおよび共有プログラムカウンタを有する複数の処理エレメント上でカーネルが同時に実行されるプログラミングモデルである。全ての処理エレメントは、同一の１組の命令を実行する。プレディケーションを用いることにより、発行されたコマンドごとに、ワークアイテムを関与させることまたはさせないことが可能となる。
【００２８】
１つの例において、各ＡＰＤ１０４計算ユニットは、１つ以上のスカラーおよび／またはベクトル浮動小数点演算ユニットおよび／または算術論理ユニット（ＡＬＵ：ａｒｉｔｈｍｅｔｉｃ  ａｎｄ  ｌｏｇｉｃ  ｕｎｉｔ）を含み得る。ＡＰＤ計算ユニットは、逆平方根ユニットおよびサイン／コサインユニット等の特殊用途処理ユニット（図示せず）も含み得る。１つの例において、ＡＰＤ計算ユニットは、本明細書においてシェーダコア１２２と総称される。
【００２９】
１つ以上のＳＩＭＤが存在することにより、一般に、ＡＰＤ１０４は、グラフィックス処理において一般的なデータ並列タスク等のデータ並列タスクの実行に、理想的に好適なものとなる。
【００３０】
ピクセル処理等のいくつかのグラフィックスパイプライン処理と、他の並列演算処理とは、同一のコマンドストリームまたは計算カーネルが、ストリームまたは入力データ要素の集合体上で実行されることを要求する。同一の計算カーネルのそれぞれのインスタンス化は、上記データ要素を並列に処理するために、シェーダコア１２２の複数の計算ユニット上で同時に実行され得る。本明細書で参照されるように、例えば計算カーネルは、プログラム上で宣言され、ＡＰＤ上で実行される命令を含む関数である。この関数は、カーネル、シェーダ、シェーダプログラムまたはプログラムとも称される。
【００３１】
１つの例示的な実施形態において、各ＡＰＤ計算ユニット（例えばＳＩＭＤ処理コア）は、入力されるデータを処理するために、特定ワークアイテムのそれぞれのインスタンス化を実行し得る。ワークアイテムは、コマンドによりデバイス上で呼び出されるカーネルの並列実行の集合体のうちの１つである。ワークアイテムは、ＡＰＤ計算ユニット上で実行されるワークグループの一部として、１つ以上の処理エレメントにより実行され得る。
【００３２】
ワークアイテムは、自身のグローバルＩＤおよびローカルＩＤによって、集合体内の他の実行から区別される。１つの例において、ワークグループにおいて１つのＳＩＭＤエンジンで同時に実行されるワークアイテムの一部は、ウェーブフロント１３６と称され得る。ウェーブフロントの幅は、計算ユニット（例えば、ＳＩＭＤ処理コア）のハードウェアの特性である。本明細書で参照されるワークグループは、単一の計算ユニット上で実行される関連するワークアイテムの集合体である。ワークグループ内のワークアイテムは、同一のカーネルを実行し、ローカルメモリおよびワークグループバリアを共有する。
【００３３】
代表的な実施形態において、ワークグループからの全てのウェーブフロントは、同一のＳＩＭＤ処理コアで処理される。ウェーブフロントにわたる命令は１つずつ発行され、全てのワークアイテムが同一の制御フローに従う場合には、各ワークアイテムは、同一のプログラムを実行する。ウェーブフロントは、ワープ、ベクトルまたはスレッドと称され得る。
【００３４】
実行マスクおよびワークアイテムプレディケーションは、ウェーブフロント内の拡散的な制御フローを可能にするために用いられる。なお、拡散的な制御フローにおいては、各個別のワークアイテムは、カーネルを通じて一意的なコードパスを実際に取り得る。部分的に占められたウェーブフロントは、ワークアイテムの全てのセットがウェーブフロント開始時にて必ずしも利用可能とは限らない場合に、処理され得る。例えば、シェーダコア１２２は、所定数のウェーブフロント１３６を同時に実行し得る。なお、各ウェーブフロント１３６は、複数のワークアイテムを含む。
【００３５】
システム１００において、ＡＰＤ１０４は、グラフィックスメモリ１３０等の自身のメモリを含む（なお、メモリ１３０は、グラフィックス専用に制限されるとは限らない）。グラフィックスメモリ１３０は、ＡＰＤ１０４における計算実行の間の使用のために、ローカルメモリを提供する。シェーダコア１２２内の個々の計算ユニット（図示せず）は、自身のローカルデータ記憶装置（図示せず）を有し得る。１つの実施形態において、ＡＰＤ１０４は、ローカルグラフィックスメモリ１３０へのアクセス、ならびにメモリ１０６へのアクセスを含む。他の実施形態において、ＡＰＤ１０４は、ダイナミックランダムアクセスメモリ（ＤＲＡＭ：ｄｙｎａｍｉｃ  ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ）、または、ＡＰＤ１０４には直接的に接続されているがメモリ１０６からは分離している他のメモリ（図示せず）へのアクセスを含み得る。
【００３６】
図示の例において、ＡＰＤ１０４は、１つまたは「ｎ」個のコマンドプロセッサ（ＣＰ：ｃｏｍｍａｎｄ  ｐｒｏｃｅｓｓｏｒ）１２４を含み得る。ＣＰ１２４は、ＡＰＤ１０４内の処理を制御する。ＣＰ１２４は、実行されるべきコマンドを、メモリ１０６内のコマンドバッファ１２５から取得し、ＡＰＤ１０４でのこれらのコマンドの実行を調整する。
【００３７】
１つの例において、ＣＰＵ１０２は、アプリケーション１１１に基づくコマンドを、適切なコマンドバッファ１２５に入力する。本明細書において参照されるように、アプリケーションは、ＣＰＵ内またはＡＰＤ内の計算ユニット上で実行されるプログラム部分の組合せである。
【００３８】
複数のコマンドバッファ１２５は、各プロセスがＡＰＤ１０４での実行のためにスケジュールされた状態で、保持され得る。
【００３９】
ＣＰ１２４は、ハードウェア、ファームウェア、ソフトウェアまたはこれらの組合せにおいて実装され得る。１つの実施形態において、ＣＰ１２４は、スケジューリングロジックを含むロジックを実装するためのマイクロコードを有する縮小命令セットコンピュータ（ＲＩＳＣ：ｒｅｄｕｃｅｄ  ｉｎｓｔｒｕｃｔｉｏｎ  ｓｅｔ  ｃｏｍｐｕｔｅｒ）エンジンとして実装される。
【００４０】
ＡＰＤ１０４は、１つまたは「ｎ」個のディスパッチコントローラ（ＤＣ：ｄｉｓｐａｔｃｈ  ｃｏｎｔｒｏｌｌｅｒ）１２６を含み得る。本願において、ディスパッチという用語は、１セットの計算ユニット上の１セットのワークグループに対するカーネルの実行のスタートを起動するために、コンテキスト状態を使用するディスパッチコントローラにより実行されるコマンドを指す。ＤＣ１２６は、シェーダコア１２２内でワークグループを起動するためのロジックを含む。いくつかの実施形態において、ＤＣ１２６は、ＣＰ１２４の一部として実装され得る。
【００４１】
システム１００は、ＡＰＤ１０４上で実行するためのプロセスを実行リスト１５０から選択するためのハードウェアスケジューラ（ＨＷＳ：ｈａｒｄｗａｒｅ  ｓｃｈｅｄｕｌｅｒ）１２８を含む。ＨＷＳ１２８は、ラウンドロビン方式、優先レベルを用いて、または他のスケジューリングポリシーに基づいて、プロセスを実行リスト１５０から選択し得る。優先レベルは、例えば、動的に決定され得る。ＨＷＳ１２８は、例えば、新規のプロセスを追加することによって、あるいは既存のプロセスを実行リスト１５０から削除することによって、実行リスト１５０を管理する機能を含み得る。ＨＷＳ１２８の実行リスト管理ロジックは、実行リストコントローラ（ＲＬＣ：ｒｕｎ  ｌｉｓｔ  ｃｏｎｔｒｏｌｌｅｒ）と称されることもある。
【００４２】
本発明の様々な実施形態において、ＨＷＳ１２８が、ＲＬＣ１５０からのプロセスの実行を開始すると、ＣＰ１２４は、対応するコマンドバッファ１２５からのコマンドの取得および実行を開始する。いくつかの事例において、ＣＰ１２４は、ＣＰＵ１０２から受信したコマンドに対応する、ＡＰＤ１０４内で実行される１つ以上のコマンドを生成し得る。１つの実施形態において、ＣＰ１２４は、ＡＰＤ１０４リソースおよび／またはシステム１００のリソースの利用が改善または最大化されるように、ＡＰＤ１０４におけるコマンドの優先化およびスケジューリングを、他のコンポーネントとともに実装する。
【００４３】
ＡＰＤ１０４は、インタラプトジェネレータ１４６に対してアクセスを有するか、またはインタラプトジェネレータ１４６を含み得る。インタラプトジェネレータ１４６は、ＡＰＤ１０４がページフォールト等のインタラプトイベントに遭遇すると、ＡＰＤ１０４によってオペレーティングシステム１０８にインタラプトをかけるよう構成され得る。例えば、ＡＰＤ１０４は、ＩＯＭＭＵ１１６内のインタラプト生成ロジックに依存して、上述のページフォールトインタラプトを生成し得る。
【００４４】
ＡＰＤ１０４は、シェーダコア１２２内で現在実行中のプロセスを切り替えるためのプリエンプションおよびコンテキストスイッチロジック１２０を含み得る。コンテキストスイッチロジック１２０は、例えばプロセスを停止させ、その現在状態（例えばシェーダコア１２２状態およびＣＰ１２４状態）を保存する機能を含む。
【００４５】
本明細書において参照される状態という用語は、初期状態、中間状態および／または最終状態を含み得る。初期状態は、機械がプログラム順序に従って入力データセットを処理することによって、データの出力セットを生成する開始点である。例えば、処理を前進させるためにいくつかのポイントにおいて記憶される必要がある中間状態が存在する。この中間状態は、他のプロセスによってインタラプトがかけられた場合に、後に実行を継続することを可能にするために記憶される場合もある。出力データセットの一部として記録され得る最終状態も存在する。
【００４６】
プリエンプションおよびコンテキストスイッチロジック１２０は、他のプロセスを、ＡＰＤ１０４にコンテキストスイッチするためのロジックを含み得る。他のプロセスをＡＰＤ１０４で実行するようにコンテキストスイッチするための機能は、ＡＰＤ１０４上で実行するために、例えばＣＰ１２４およびＤＣ１２６によってプロセスをインスタンス化することと、当該プロセスに対して以前に保存された状態を復元することと、当該プロセスの実行を開始することと、を含み得る。
【００４７】
メモリ１０６は、ＤＲＡＭ（図示せず）等の非永続型メモリを含み得る。メモリ１０６は、例えば、アプリケーションまたは他の処理ロジックの部分を実行する間に、処理ロジック命令、定数および様々な変数を記憶し得る。例えば、１つの実施形態において、ＣＰＵ１０２上で１つ以上の演算を実行するための制御ロジックの部分は、ＣＰＵ１０２によって演算のそれぞれの部分が実行される間にメモリ１０６内に常駐し得る。
【００４８】
実行中、個別のアプリケーション、オペレーティングシステム関数、処理ロジックコマンドおよびシステムソフトウェアは、メモリ１０６に常駐し得る。オペレーティングシステム１０８に対して必須である制御ロジックコマンドは、一般に、実行中にはメモリ１０６に常駐することとなるであろう。他のソフトウェアコマンド、例えばカーネルモードドライバ１１０およびソフトウェアスケジューラ１１２は、システム１００の実行中にはメモリ１０６に常駐し得る。
【００４９】
この例において、メモリ１０６は、コマンドをＡＰＤ１０４に送るために、ＣＰＵ１０２によって用いられるコマンドバッファ１２５を含む。メモリ１０６は、プロセスリストおよびプロセス情報（例えば、アクティブリスト１５２およびプロセス制御ブロック１５４）を含み得る。これらのリストおよび情報は、スケジュール情報を、ＡＰＤ１０４および／または関連するスケジューリングハードウェアに伝えるために、ＣＰＵ１０２上で実行されるスケジューリングソフトウェアによって使用される。メモリ１０６に対するアクセスは、メモリ１０６に接続されたメモリコントローラ１４０によって管理され得る。例えば、メモリ１０６に対する読み出しおよび書き込みを実行するための、ＣＰＵ１０２または他のデバイスからの要求は、メモリコントローラ１４０によって管理される。
【００５０】
システム１００の他の態様に戻ると、ＩＯＭＭＵ１１６は、マルチコンテキスト・メモリ管理ユニットである。
【００５１】
本明細書で用いられるコンテキストという用語は、カーネルが実行される環境であって、同期およびメモリ管理が定義されるドメインであるとみなされる。コンテキストは、１セットのデバイスと、これらのデバイスに対してアクセス可能であるメモリと、対応するメモリ特性と、メモリオブジェクトにおけるカーネル（単数または複数）または演算の実行をスケジュールするために用いられる１つ以上のコマンドキューとを含む。
【００５２】
図１Ａにおいて示される例に戻ると、ＩＯＭＭＵ１１６は、ＡＰＤ１０４を含むデバイスに対するメモリページアクセスに対して、仮想アドレスから物理アドレスへの変換を実行するためのロジックを含む。ＩＯＭＭＵ１１６は、例えば、ＡＰＤ１０４等のデバイスによるページアクセスの結果としてページフォールトが生じる場合に、インタラプトを生成するためのロジックを含み得る。ＩＯＭＭＵ１１６は、トランスレーションルックアサイドバッファ（ＴＬＢ：ｔｒａｎｓｌａｔｉｏｎ  ｌｏｏｋａｓｉｄｅ  ｂｕｆｆｅｒ）１１８を含むか、あるいはＴＬＢ１１８に対するアクセスを有し得る。ＴＬＢ１１８は、１つの例として、メモリ１０６内のデータ用にＡＰＤ１０４によりなされた要求に対して、論理（すなわち仮想）メモリアドレスから物理メモリアドレスへの変換を高速化するために、コンテントアドレサブルメモリ（ＣＡＭ：ｃｏｎｔｅｎｔ  ａｄｄｒｅｓｓａｂｌｅ  ｍｅｍｏｒｙ）に実装され得る。
【００５３】
示された例において、通信インフラストラクチャ１０９は、必要に応じてシステム１００のコンポーネントを相互接続する。通信インフラストラクチャ１０９は、周辺構成要素相互接続（ＰＣＩ）バス、拡張ＰＣＩ（ＰＣＩ−Ｅ）バス、アドバンスト・マイクロコントローラ・バス・アーキテクチャ（ＡＭＢＡ）バス、アドバンスト・グラフィックス・ポート（ＡＧＰ）または他の通信インフラストラクチャのうち１つ以上を含み得る（図示せず）。通信インフラストラクチャ１０９は、イーサネット（登録商標）若しくは同様のネットワークまたはアプリケーションの転送速度要求を満足する任意の好適な物理的通信インフラストラクチャを含み得る。通信インフラストラクチャ１０９は、コンピューティングシステム１００のコンポーネントを含むコンポーネントを相互接続するための機能を含む。
【００５４】
この例において、オペレーティングシステム１０８は、システム１００のハードウェアコンポーネントを管理する機能と、共通サービスを提供するための機能とを含む。様々な実施形態において、オペレーティングシステム１０８は、ＣＰＵ１０２上で実行し、共通サービスを提供する。これらの共通サービスは、例えば、ＣＰＵ１０２内での実行のためにアプリケーションをスケジューリングすることと、フォールト管理と、インタラプトサービスと、他のアプリケーションの入力および出力を処理することと、を含む。
【００５５】
いくつかの実施形態において、オペレーティングシステム１０８は、例えばインタラプトコントローラ１４８等のインタラプトコントローラによって生成されたインタラプトに基づいて、適切なインタラプトハンドリングルーチンを呼び出す。例えば、オペレーティングシステム１０８は、ページフォールト・インタラプトを検出すると、関連するページをメモリ１０６にロードし始め、且つ、対応するページテーブルを更新するために、インタラプトハンドラを呼び出す。
【００５６】
オペレーティングシステム１０８は、オペレーティングシステムにより管理されるカーネル機能を通して、ハードウェア部品に対するアクセスが仲介されることを確保することによって、システム１００を保護する機能を含み得る。事実、オペレーティングシステム１０８は、アプリケーション１１１等のアプリケーションが、ＣＰＵ１０２上でユーザスペースにおいて実行されることを確保する。オペレーティングシステム１０８は、アプリケーション１１１が、ハードウェアにアクセスするためにオペレーティングシステムにより提供されるカーネル機能および／または入出力機能を呼び出すことも確保する。
【００５７】
例として、アプリケーション１１１は、ＣＰＵ１０２上でも実行されるユーザ計算を実行するための様々なプログラムまたはコマンドを含む。ＣＰＵ１０２は、選択されたコマンドを、ＡＰＤ１０４で処理するためにシームレスに送信し得る。１つの例において、ＫＭＤ１１０は、ＣＰＵ１０２、ＣＰＵ１０２上で実行されるアプリケーションまたは他のロジックが、ＡＰＤ１０４の機能を呼び出し得るアプリケーションプログラミングインタフェース（ＡＰＩ）を実装する。例えば、ＫＭＤ１１０は、ＣＰＵ１０２からのコマンドを、コマンドバッファ１２５にエンキューし得る。なお、ＡＰＤ１０４は、このコマンドバッファ１２５からコマンドを続けて取得することとなる。加えて、ＫＭＤ１１０は、ＡＰＤ１０４上で実行されるプロセスのスケジューリングを、ＳＷＳ１１２とともに実行する。ＳＷＳ１１２は、例えば、ＡＰＤ上で実行されるプロセスの優先度リストを保持するためのロジックを含み得る。
【００５８】
本発明の他の実施形態において、ＣＰＵ１０２上で実行するアプリケーションは、コマンドをエンキューするときに、ＫＭＤ１１０を完全にバイパスし得る。
【００５９】
いくつかの実施形態において、ＳＷＳ１１２は、ＡＰＤ１０４上で実行されるプロセスのアクティブリスト１５２を、メモリ１０６に保持する。ＳＷＳ１１２は、アクティブリスト１５２におけるプロセスのうち、ハードウェアのＨＷＳ１２８により管理される一部を選択する。各プロセスをＡＰＤ１０４上で実行することに関する情報は、ＣＰＵ１０２からプロセス制御ブロック（ＰＣＢ：ｐｒｏｃｅｓｓ  ｃｏｎｔｒｏｌ  ｂｌｏｃｋ）１５４を通して、ＡＰＤ１０４に伝えられる。
【００６０】
アプリケーション、オペレーティングシステムおよびシステムソフトウェアのための処理ロジックは、マスクワーク／フォトマスクの生成を通して最終的に製造プロセスを構成することで、本明細書において説明される本発明の態様を具体化するハードウェア装置を生成することを可能にするための、例えば、Ｃ言語等のプログラム言語および／またはＶｅｒｉｌｏｇ、ＲＴＬ等のハードウェア記述言語もしくはネットリストにおいて指定されるコマンドを含み得る。
【００６１】
当業者は、コンピューティングシステム１００が、図１Ａにおいて示されるコンポーネントよりも多数または少数のコンポーネントを含み得ることを、本明細書を読むことで理解するであろう。例えば、コンピューティングシステム１００は、１つ以上の入力インターフェースと、不揮発性ストレージと、１つ以上の出力インターフェースと、ネットワークインターフェースと、１つ以上のディスプレイまたはディスプレイインターフェースと、を含み得る。
【００６２】
図１Ｂは、図１Ａにおいて示されるＡＰＤ１０４のより詳細な例示を示す実施形態である。図１Ｂにおいて、ＣＰ１２４は、ＣＰパイプライン１２４ａ，１２４ｂ，１２４ｃを含み得る。ＣＰ１２４は、図１Ａにおいて示されるコマンドバッファ１２５から入力として提供されるコマンドリストを処理するように、構成され得る。図１Ｂの典型的な動作において、ＣＰ入力０（１２４ａ）は、コマンドをグラフィックスパイプライン１６２に駆動することを担当する。ＣＰ入力１および２（１２４ｂおよび１２４ｃ）は、コマンドを計算パイプライン１６０に伝える。ＨＷＳ１２８の動作を制御するためのコントローラ機構１６６も提供される。
【００６３】
図１Ｂにおいて、グラフィックスパイプライン１６２は、本明細書において順序化パイプライン１６４と称される、１セットのブロックを含み得る。例えば、順序化パイプライン１６４は、頂点グループ変換器（ＶＧＴ：ｖｅｒｔｅｘ  ｇｒｏｕｐ  ｔｒａｎｓｌａｔｏｒ）１６４ａと、プリミティブアセンブラ（ＰＡ：ｐｒｉｍｉｔｉｖｅ  ａｓｓｅｍｂｌｅｒ）１６４ｂと、スキャンコンバータ（ＳＣ：ｓｃａｎ  ｃｏｎｖｅｒｔｅｒ）１６４ｃと、シェーダエクスポート・レンダーバック・ユニット（ＳＸ／ＲＢ：ｓｈａｄｅｒ−ｅｘｐｏｒｔ，ｒｅｎｄｅｒ−ｂａｃｋ  ｕｎｉｔ）１７６とを含む。順序化パイプライン１６４内の各ブロックは、グラフィックスパイプライン１６２内の異なる段階のグラフィックス処理を表し得る。順序化パイプライン１６４は、固定機能ハードウェアパイプラインであり得る。本発明の精神および範囲に含まれ得る他の実装を用いることも可能である。
【００６４】
わずかな量のデータが、入力としてグラフィックスパイプライン１６２に提供されるが、このデータは、グラフィックスパイプライン１６２からの出力として提供される時まで増幅されることとなるであろう。グラフィックスパイプライン１６２は、ＣＰパイプライン１２４ａから受け取ったワークアイテムグループ内の範囲にわたってカウントするためのＤＣ１６６も含む。ＤＣ１６６を通して提示された計算作業は、グラフィックスパイプライン１６２と準同期している。
【００６５】
計算パイプライン１６０は、シェーダＤＣ１６８，１７０を含む。ＤＣ１６８，１７０のそれぞれは、ＣＰパイプライン１２４ｂ，１２４ｃから受け取ったワークグループ内の計算範囲にわたってカウントするように構成されている。
【００６６】
図１Ｂにおいて示されるＤＣ１６６，１６８，１７０は、入力範囲を受け取り、入力範囲をワークグループに分割し、次いでこれらのワークグループをシェーダコア１２２に伝える。
【００６７】
グラフィックスパイプライン１６２は、一般に固定機能パイプラインであるため、その状態を保存および復元することは困難であり、そのためグラフィックスパイプライン１６２は、コンテキストスイッチが困難である。したがって、ほとんどの場合、本明細書において論じられるコンテキストスイッチは、グラフィックス処理におけるコンテキストスイッチに関係しない。例外は、シェーダコア１２２におけるグラフィックス作業であり、これはコンテキストスイッチされ得る。
【００６８】
グラフィックスパイプライン１６２内のワーク処理が完了した後、完了したワークを、レンダーバックユニット１７６を通じて処理する。レンダーバックユニット１７６は、デプス計算およびカラー計算を行い、次いで、この最終結果をメモリ１３０に書き込む。
【００６９】
シェーダコア１２２は、グラフィックスパイプライン１６２および計算パイプライン１６０により共有され得る。シェーダコア１２２は、ウェーブフロントを実行するように構成された汎用プロセッサであり得る。１つの例において、計算パイプライン１６０内の全てのワークは、シェーダコア１２２内で処理される。シェーダコア１２２は、プログラム可能なソフトウェアコードを実行し、多様な形態のデータ（例えば、状態データ）を含む。
【００７０】
全てのワークアイテムがＡＰＤリソースにアクセスできないとき、ＱｏＳ内で中断が起こる。本発明の実施形態は、ＡＰＤ１０４内のリソースに対する２つ以上のタスクの効率的および同時の起動を容易にし、全てのワークアイテムが種々のＡＰＤリソースにアクセスするのを可能にする。１つの実施形態では、ＡＰＤ入力スキームは、ＡＰＤの作業負荷を管理することにより、全てのワークアイテムが並列にＡＰＤリソースへのアクセスを有することを可能にする。ＡＰＤの作業負荷が最大レベルに近づくとき（例えば最大Ｉ／Ｏレートの達成中）、このＡＰＤ入力スキームは、未使用となり得た処理リソースが多くのシナリオで同時に使用可能であるように補助する。シリアル入力ストリームは、例えば、ＡＰＤへの並列同時入力として現れるように抽象化され得る。
【００７１】
例えば、ＣＰ１２４の各々は、ＡＰＤ１０４内の他のリソースへ入力として送る１つ以上のタスクを有することが可能であり、各タスクは、複数のウェーブフロントを表すことが可能である。第１のタスクが入力として送られた後に、このタスクは、一定期間にわたって、タスクの完了に必要な全てのＡＰＤリソースを使用するように起動することが許可されてもよい。この第１のタスクは、単独で、最大ＡＰＤ使用閾値に達してもよいし、達しなくてもよい。しかし、他のタスクがエンキューされ、ＡＰＤ１０４内で処理されるのを待っているので、ＡＰＤリソースの割り当ては、全てのタスクがＡＰＤ１０４を同時に使用でき、各タスクがＡＰＤの最大使用率を達成するのを保証するように管理されることが可能である。複数のタスクによるＡＰＤ１０４の同時使用、およびこれらの組み合わせた使用率は、所定の最大ＡＰＤ使用閾値に達することを保証する。
【００７２】
図２は、ＵＬＩを処理可能なＣＰＵスレッドの初期化プロセスの例示的なフロー図である。
【００７３】
オペレーション２０２において、ＣＰＵ１０２は、ＣＰＵスレッドを初期化する。初期化プロセス中、ＣＰＵ１０２は、ＵＬＩの処理を担当するサブルーチンのメモリアドレスを用いて、ハードウェアテーブルをプログラムする。また、ＣＰＵ１０２は、ＡＰＤ１１０４がＵＬＩを受信しなかったことを示す値を、ＵＬＩレジスタに設定する。
【００７４】
オペレーション２０４において、ＣＰＵスレッドは、ＡＰＤ１０４用のタスクをスケジュールする。オペレーション２０６において、ＡＰＤ１０４は、オペレーション２０４にてスケジュールされたタスクの実行を開始する。ＡＰＤ１０４は、本明細書において説明されるように、スケジュールされたタスクを、１つ以上のシェーダコア１２２を用いて実行する。
【００７５】
同時に、オペレーション２０８において、ＣＰＵスレッドは、ＣＰＵ１０２によってＣＰＵスレッドに委託されたタスクの処理を開始する。当業者は、オペレーション２０８において実行されるＣＰＵスレッドは、ＣＰＵ１０２によって周期的にスケジュール解除され、再スケジュールされてもよいことを理解するであろう。
【００７６】
ＡＰＤ１０４は、ＣＰＵ１０２からのアテンションを要求する場合に、ＵＬＩを発行する。
【００７７】
図３は、ＵＬＩを発行するＡＰＤと、ＡＰＤの要求を処理するＣＰＵとの例示的なフロー図３００である。オペレーション３０２において、ＡＰＤ１０４は、ＣＰＵ１０２からのアテンションを要求し、ＵＬＩを発行する。オペレーション３０４において、ＣＰＵ１０２は、ＡＰＤ１０４からＵＬＩを受信する。
【００７８】
オペレーション３０６において、ＣＰＵ１０２は、オペレーション２０４にてＡＰＤ１０４のタスクをスケジュールしたＣＰＵスレッドが、ＣＰＵ１０２で実行されているか否かを判定する。スレッドがＣＰＵ１０２で実行されている場合には、フロー図では、オペレーション３０８に処理が進む。そうでない場合には、フロー図では、本明細書において説明されるオペレーション３１８に処理が進む。
【００７９】
オペレーション３０８において、ＣＰＵスレッドは、自身の現在状態をシステムメモリ１０６に保存する。当業者は、現在状態が、スレッドＣＰＵ１０２がＵＬＩをＡＰＤ１０４から受信したときに処理していたタスクに関して、レジスタおよびＣＰＵスレッドの状態を将来復元するために必要な他の情報を含むことができることを理解するであろう。
【００８０】
オペレーション３１０において、ＣＰＵスレッドは、サブルーチンを含むインタラプトハンドラにアクセスする。ＣＰＵスレッドは、サブルーチンのメモリアドレスを記憶するハードウェアテーブルにアクセスすることにより、サブルーチンにアクセスする。
【００８１】
オペレーション３１２において、ＣＰＵスレッドは、サブルーチンの実行を開始し、したがって、ＡＰＤ１０４によって発生したＵＬＩ要求の処理を開始する。本明細書において説明されるように、サブルーチンは、ＡＰＤ１０４に対するさらなるワークをエンキューするコードを含んでもよく、その結果、ＡＰＤ１０４は、ＣＰＵ１０２がＵＬＩを処理する間、待機状態のままではない。
【００８２】
オペレーション３１４において、ＣＰＵスレッドは、サブルーチンにおける処理命令を完了する。ＣＰＵスレッドは、要求されたワークがコマンドバッファ１２５を用いて完了したという信号を、ＡＰＤ１０４に送信する。ＵＬＩが完了した後に、ＣＰＵスレッドはオペレーション２０８に戻り、ＡＰＤ１０４はオペレーション２０６に戻る。
【００８３】
コンピューティング環境において、ＣＰＵ１０２は、複数のＣＰＵスレッドを処理する。例えば、ＣＰＵ１０２は、ＣＰＵスレッドの優先度、ＣＰＵコアの数、その他に依存して、ＣＰＵスレッドをスケジュールおよびスケジュール解除できる。通常、ＣＰＵ１０２がＣＰＵスレッドをスケジュール解除すると、ＣＰＵ１０２は、ＸＳＡＶＥ機能を用いてＣＰＵスレッドのレジスタの状態を保存する。
【００８４】
しかし、ＣＰＵ１０２はＣＰＵスレッドをスケジュール解除するが、ＡＰＤ１０４は、ＣＰＵスレッドがＡＰＤ１０４に投入したタスクを処理し続ける。ＡＰＤ１０４は、これらのタスクを処理し続けるので、ＣＰＵ１０２がＣＰＵスレッドをスケジュール解除すると、ＵＬＩを発行することができる。
【００８５】
ＣＰＵ１０２によってＣＰＵスレッドがスケジュール解除されたときにＵＬＩが受信されたことを、ＣＰＵスレッドが判定するために、ＵＬＩイベントは、ＫＭＤ１１０によってアクセス可能であるシステムメモリ１０６内に保存される。ＣＰＵ１０２がＣＰＵスレッドを復元すると、ＫＭＤ１１０は、ＵＬＩが発生したことを示す。次いで、復元されたＣＰＵスレッドは、サブルーチンへのベクトルをオフにし、ＵＬＩの処理を開始する。通常、ＣＰＵ１０２は、ＸＲＳＴＯＲ機能を用いて、ＣＰＵスレッドを復元する。
【００８６】
図３に戻ると、ＣＰＵ１０２は、スケジュール解除されたＣＰＵスレッドに対してＵＬＩが発行されたと判定すると、オペレーション３１６に進む。
【００８７】
オペレーション３１６において、ＣＰＵ１０２が、対応するＣＰＵスレッドを再スケジュールするまで、ＵＬＩがＫＭＤ１１０に経路決定される。一実施形態において、ＣＰＵスレッドを生成したプロセス識別子（プロセスＩＤ：ｐｒｏｃｅｓｓ  ｉｄｅｎｔｉｆｉｅｒ）およびＣＰＵスレッド識別子（スレッドＩＤ：ｔｈｒｅａｄ  ｉｄｅｎｔｉｆｉｅｒ）も、ＵＬＩと共にＫＭＤ１１０に経路決定される。代替的な実施形態において、ＣＰＵ１０２は、ＵＬＩ、プロセスＩＤおよびスレッドＩＤをシステムメモリ１０６に保存して、ＫＭＤ１１０の使用を回避し得る。
【００８８】
オペレーション３１８において、ＣＰＵ１０２は、ＣＰＵスレッドを復元する。ＣＰＵ１０２は、ＸＲＳＴＯＲ機能を用いて、ＣＰＵスレッドの状態をシステムメモリ１０６から取得する。１つの実施形態において、ＣＰＵ１０２は、ＵＬＩがＣＰＵスレッドに発行されたか否かに関わらず、ＣＰＵスレッドを一度に復帰させ得る。
【００８９】
別の例示的な実施形態において、ＫＭＤ１１０は、ＣＰＵ１０２が特定のＣＰＵスレッドに対するＵＬＩを受信すると、ＣＰＵスレッドをより迅速に、ＣＰＵ１０２に復元させてもよい。例えば、ＫＭＤ１１０は、ＣＰＵスレッドの優先度を増してもよく、したがって、当該ＣＰＵスレッドを、他のスケジュール解除されたＣＰＵスレッドよりも前に、ＣＰＵ１０２に復元させる。
【００９０】
オペレーション３２０において、ＣＰＵスレッドは、任意のＵＬＩがＡＰＤ１０４によって発行されたか否かを判定する。ＵＬＩがＣＰＵスレッドに対して発行された場合には、例示的なフロー図３００のオペレーション３０８に処理が進む。そうでない場合には、ＣＰＵスレッドは、本明細書において説明されるようにオペレーション３０８に進む。
【００９１】
ＡＰＤ１０４は、ＣＰＵ１０２からのアテンションを要求すると、本明細書において説明されるように、ＵＬＩを発行する。ＡＰＤ１０４は、単一のタスクに対するＣＰＵ１０２からのアテンションを要求することに加えて、単一のＵＬＩにおいて複数のタスクを処理するように、ＣＰＵ１０２に要求することもできる。ＡＰＤ１０４は、ＵＬＩを発行する前に、いくつかのタスクをパブリックキューに加える（エンキューする）。当業者は、ＣＰＵ１０２およびＣＰＵ１０４プロセッサがパブリックキューを認識できることを理解するであろう。一実施形態において、複数のシェーダコア１２２は、タスクをキューに加える（エンキューする）ことができる。
【００９２】
ＣＰＵスレッドは、ＡＰＤ１０４がＵＬＩをＣＰＵ１０２に発行すると、サブルーチンを含むインタラプトハンドラへのベクトルをオフにする。サブルーチンは、パブリックキューに対するアクセスを有しており、キューされたタスクを取り出し（デキューし）、取り出された（デキューされた）タスクを処理することができる。一実施形態において、ＣＰＵスレッドは、処理前にデキューされたタスクをスキャンし、優先させる。例えば、ＣＰＵスレッドは、タスクの優先度、タスクタイプ、サービスの特質その他に基づいて、タスクをどのように優先させるかを決定することができる。
【００９３】
図４は、ＵＬＩを用いてキューを処理するようにＣＰＵに要求するＡＰＤの例示的なフロー図４００である。オペレーション４０２において、ＡＰＤ１０４は、タスクをキューに加える（エンキューする）。オペレーション４０４において、ＡＰＤ１０４は、ＵＬＩをＣＰＵ１０２に発行する。
【００９４】
オペレーション４０６において、ＣＰＵ１０２は、ＡＰＤ１０４からＵＬＩを受信し、本明細書において説明されるようにＵＬＩを処理する。本明細書において説明されるように、ＣＰＵ１０２が、ＡＰＤ１０４用のワークをスケジュールしたＣＰＵスレッドを実行または再スケジュールすると、フロー図のオペレーション４０８に処理が進む。
【００９５】
オペレーション４０８において、ＣＰＵスレッドは、自身の現在の作業負荷を保存し、サブルーチンへのベクトルをオフにする。ＣＰＵスレッドは、サブルーチン内で、タスクをデキューし、本明細書において説明されるように処理を開始する。ＣＰＵスレッドは、タスクの処理を一旦完了すると、必要に応じてＡＰＤ１０４に通知し、および／または保存された自身の作業負荷の処理に戻る。
【００９６】
本発明の様々な態様は、ソフトウェア、ファームウェア、ハードウェアまたはこれらの組合せによって実装され得る。例えば、図２のフロー図２００、図３のフロー図３００、図４のフロー図４００によって示された方法は、図１の統合化されたコンピューティングシステム１００において実装され得る。本発明の様々な実施形態は、この例示的な統合化されたコンピューティングシステム１００に関して説明されている。他のコンピュータシステムおよび／またはコンピュータアーキテクチャを使用して本発明を実施する方法は、当業者に明らかであろう。
【００９７】
本文書において、用語「コンピュータプログラム媒体」および「コンピュータ使用可能媒体」は、概して、取り外し可能な記憶装置またはハードディスクドライブなどの媒体を指すために使用される。また、コンピュータプログラム媒体およびコンピュータ使用可能媒体は、メモリ半導体（例えばＤＲＡＭなど）からなるシステムメモリ１０６およびグラフィックスメモリ１３０などのメモリを指すこともできる。これらのコンピュータプログラム製品は、統合化されたコンピューティングシステム１００にソフトウェアを提供するための手段である。
【００９８】
また、本発明は、任意のコンピュータ使用可能媒体に記憶されるソフトウェアを含むコンピュータプログラム製品を対象とする。上記ソフトウェアは、１つ以上のデータ処理装置で実行される場合に、本明細書において説明されるようにデータ処理装置を動作させ、あるいは上述したように、本明細書において説明される本発明の実施形態を実行するように、コンピューティングデバイス（例えばＡＳＩＣまたはプロセッサなど）の合成および／または製造を可能にする。本発明の実施形態は、現在公知のまたは将来公知になる、任意のコンピュータ使用可能媒体またはコンピュータ可読媒体を利用する。コンピュータ使用可能媒体の例としては、これに制限されないが、一次記憶装置（例えば、任意のタイプのランダムアクセスメモリ）、二次記憶装置（例えば、ハードドライブ、フロッピディスク、ＣＤＲＯＭ、ＺＩＰディスク、テープ、磁気記憶装置、光学式記憶装置、ＭＥＭＳ、ナノテクノロジー記憶装置など）ならびに通信媒体（例えば、有線および無線通信ネットワーク、ローカルエリアネットワーク、広域ネットワーク、イントラネットなど）が含まれる。
【００９９】
本発明の様々な実施形態が上に説明されたが、これらは例証のみとして提示されているものであり、制限するものではないことを理解されたい。当業者は、形式および詳細の様々な変更が、添付の特許請求項において定義されているように、本発明の精神および範囲から逸脱することなくその中でなされ得ることを理解するであろう。本発明はこれらの例に制限されないことを理解されたい。本発明は、本明細書において説明されるように動作する任意の構成要素に適用可能である。したがって、本発明の範囲は、上述の代表的な実施形態のいずれによっても制限されるものではなく、以下の特許請求項およびそれらの均等物にしたがって定められるべきである。
【図１Ａ】
0005805783.tif 000002
【図１Ｂ】
0005805783.tif 000003
【図２】
0005805783.tif 000004
【図３】
0005805783.tif 000005
【図４】
0005805783.tif 000006