JP2013546097A - グラフィックス処理計算リソースのアクセシビリティ - Google Patents

Abstract

アクセラレーテッド処理デバイス計算リソースへの改善されたアクセスをユーザモードアプリケーションに提供するための方法、システムおよびコンピュータプログラム製品が開示される。開示された機能は、ユーザモードアプリケーションが、統合化されたリングバッファにアクセスするために、カーネルモード遷移を必要とすることなしに、コマンドをアクセラレーテッド処理デバイスに提供することを可能にする。代わりに、各アプリケーションの各々にはバッファが提供され、アクセラレーテッド処理デバイスハードウェアは、コマンドを処理するために当該バッファにアクセスすることができる。ユーザモードアプリケーションは、完全なオペレーティングシステムサポートとともに、ＣＰＵとほぼ同様の方法でアクセラレーテッド処理デバイスを利用することが可能である。
【選択図】図７

Description

本発明は、概して、コンピューティングシステムを対象とする。さらに詳細には、本発明は、コンピューティングシステム内の計算コンポーネントの統合化を対象とする。

グラフィックス処理ユニット（ＧＰＵ：ｇｒａｐｈｉｃｓ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）を一般的な演算に用いる要請は、ＧＰＵの単位電力および／またはコストあたりの能力が優れることから、最近ではより顕著となってきている。ＧＰＵの計算能力は、対応する中央処理装置（ＣＰＵ：ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）の計算能力の成長速度を超える速度で成長してきた。移動コンピューティング市場（例えば、ノートブック、モバイルスマートフォン、タブレット、その他）およびその必要な支援サーバ／企業システムの爆発的な成長と組み合わされたこの成長は、特定品質の所望のユーザ経験を提供するために用いられてきている。したがって、並列データの内容を有する作業負荷を実行するためにＣＰＵとＧＰＵとを併用することはボリュームテクノロジとなりつつある。

しかし、ＧＰＵは、従来、主にグラフィックの高速化のために利用可能な制約されたプログラミング環境で動作する。これらの制約は、ＧＰＵが、ＣＰＵと同程度に豊かなプログラミングエコシステムを有さないという事実に起因するものである。したがって、ＧＰＵの使用は、主に、グラフィックスおよびビデオのアプリケーションプログラミングインターフェース（ＡＰＩ：ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ）を処理することに既に順応した、２次元（２Ｄ）グラフィックスと、３次元（３Ｄ）グラフィックスと、少数の最先端マルチメディアアプリケーションとに限られていた。

マルチベンダにサポートされるＯｐｅｎＣＬ（登録商標）、ＤｉｒｅｃｔＣｏｍｐｕｔｅ（登録商標）、標準的なＡＰＩおよびサポート用ツールの出現とともに、従来の用途におけるＧＰＵの限界は、従来のグラフィックスを越えて拡張されてきている。ＯｐｅｎＣＬ（登録商標）およびＤｉｒｅｃｔＣｏｍｐｕｔｅ（登録商標）は将来性のあるスタートではあるが、大部分のプログラミングタスクに対して、ＣＰＵと同程度に流動的にＣＰＵとＧＰＵとの組合せが用いられることを可能にする環境およびエコシステムを作成するには、多数のハードルが残されている。

既存のコンピューティングシステムは、大抵、複数の処理装置を含む。例えば、いくつかのコンピューティングシステムは、ＣＰＵおよびＧＰＵの両方を、別個のチップ上（例えば、ＣＰＵはマザーボード上に、ＧＰＵはグラフィックカード上に配置され得る）または単一チップパッケージ上に有し得る。これらの構成の両方は、（ｉ）別個のメモリシステム、（ｉｉ）効率的なスケジューリング、（ｉｉｉ）プロセス間でサービス品質（ＱｏＳ）保証を提供すること、（ｉｖ）プログラミングモデルおよび（ｖ）複数のターゲット命令セットアーキテクチャ（ＩＳＡ：ｉｎｓｔｒｕｃｔｉｏｎ ｓｅｔ ａｒｃｈｉｔｅｃｔｕｒｅ）へのコンパイルの全項目を、電力消費を最小化しながら満足することに関して顕著な問題点を依然として含む。

例えば、個別チップ構成においては、各プロセッサがメモリにアクセスするためには、システムアーキテクチャおよびソフトウェアアーキテクチャは、チップ間インターフェースを利用することを余儀なくされる。これらの外部インターフェース（例えばチップ間インターフェース）においては、異機種環境のプロセッサを協働させるために、メモリレイテンシおよび電力消費に弊害がもたらされる一方で、別個のメモリシステム（すなわち、別個のアドレス空間）およびドライバに管理される共有メモリにおいては、きめ細かな負荷軽減に対しては許容されないオーバーヘッドが生成されてしまうこととなる。

個別および単一チップ配置の両方は、実行用にＧＰＵに送信できるコマンドのタイプを制限できる。例として、計算コマンド（例えば、物理学または人工知能コマンド）は、多くの場合、実行用にＧＰＵに送信できない。この制限は、ＣＰＵが、これらの計算コマンドによって実行される演算の結果を比較的迅速に必要とし得るために存在する。しかし、現在のシステム内のＧＰＵに作業をディスパッチする高いオーバーヘッドのために、および、これらのコマンドが、以前に発行された他のコマンドが最初に実行されるのを列内で待機する必要があり得るという事実のために、計算コマンドをＧＰＵに送信することによって被る待ち時間が、多くの場合許容できない。

計算の負荷軽減のためにＧＰＵを使用する際に直面するさらなる困難は、ＧＰＵとインターフェースを取り、且つ、作業を提供するために、開発者が利用可能なソフトウェアツールにある。既存のソフトウェアツールの多くが、ＧＰＵのグラフィックス機能を考慮して設計されており、それ故、非グラフィックス作業をＧＰＵに容易に提供するための機能を欠いている。

従って、必要なことは、ＧＰＵ計算リソースへのアクセス可能性に対する改善されたサポートである。

ＧＰＵと、アクセラレーテッドプロセッシングユニット（ＡＰＵ）と、ＧＰＵによる汎目的計算（ＧＰＧＰＵ）とは、この分野において一般に用いられる用語であるが、「アクセラレーテッド処理デバイス」（ＡＰＤ）は、より広い表現とみなされる。例えば、ＡＰＤは、従来のＣＰＵ、従来のＧＰＵ、ソフトウェアおよび／またはこれらの組合せと比較して高速化された方法で行われる、グラフィックス処理タスク、データ並列タスク、またはネスト化されたデータ並列タスクの高速化に関連する機能および演算を実行する任意のハードウェアおよび／またはソフトウェアの協働的集合体を指す。

本発明の様々な実施形態は、ＡＰＤ作業待ち行列を、カーネルモードドライバを介してアプリケーションに割り当て、計算プロセス制御ブロックをアプリケーションに割り当てるための方法および装置を提供する。計算プロセス制御ブロックは、作業待ち行列への参照を含む。方法および装置は、スケジューラによって、実行用の計算プロセス制御ブロックを選択することと、コマンドを、計算プロセス制御ブロックによって参照される作業待ち行列からＡＰＤにディスパッチすることとを含む。

本発明の追加的な特徴および利点、ならびに本発明の様々な実施形態の構造および動作は、添付の図面を参照して以下で詳細に説明される。本発明は本明細書において説明される特定の実施形態に制限されないことに注意すべきである。係る実施形態は、例示目的のみのために本明細書において提示される。追加的実施形態は、本明細書に含まれる教示に基づいて当業者に明らかとなるであろう。

添付の図面は、本明細書に組み込まれ本明細書の一部を構成するものであって、本発明の実施形態を例示し、説明とともに、本発明の原理を説明し、当業者が本発明を実施することを可能にするように、さらに機能する。

本発明の実施形態に係る処理システムの例示的ブロック図である。 図１Ａに示されたＡＰＤの例示的ブロック図である。 図１Ｂに示されたＡＰＤのさらに詳細な例示的ブロック図である。 コマンドをＡＰＤに送るためのカーネルモードドライバに依存するデータフローモデルを示す図である。 図３のデータフローモデルの概念を例示的なＷｉｎｄｏｗｓ（登録商標）環境に適用する追加のデータフローモデルを示す図である。 本発明の実施形態による、システムスタックの例示的なコンポーネントを示す図である。 本発明の実施形態による、例示的なデータフローモデルを示す図である。 本発明の実施形態による、実行時におけるアーキテクチャのシステム概要を示す図である。 本発明の実施形態による、アプリケーションが初期化されるステップを示すフロー図である。 ＡＰＤが実行するためのコマンドをアプリケーションが提供するステップを示すフロー図である。 本発明の実施形態による、スケジューラがＡＰＤコマンドの処理をスケジューリングするステップを示すフロー図である。 本発明の実施形態による、実行の状態がコンテキストスイッチに保存されるステップを示すフロー図である。 本発明の実施形態による、ソフトウェアベースのスケジューラが、ハードウェアベースのスケジューラに指示を出すことができるステップを示すフロー図である。

本発明の様々な実施形態の構造および動作のみならず、本発明のさらなる特徴および利点が、添付の図を参照して、以下で詳細に説明される。本発明は、本明細書に記載する特定の実施形態に限定されないことに留意されたい。かかる実施形態は、本明細書において例示のみを目的として提示されている。追加の実施形態は、本明細書に含まれる教示に基づき、当業者にとって明らかであろう。

以下の詳細な説明においては、「１つの実施形態」、「ある実施形態」、「例示的実施形態」またはその他を参照することは、本明細書において説明される実施形態が、特定の特徴、構造または特性を有することを示すが、すべての実施形態がその特定の特徴、構造または特性を必ずしも含むとは限らない。さらに、係る語句は、同一の実施形態を参照するとは限らない。さらに、特定の特徴、構造または特性が１つの実施形態に関連して説明されるとき、係る特長、構造または特性を他の実施形態との関連で実施することは、明示されているか否かによらず、当業者の知識の範囲内であることが提起される。

「本発明の実施形態」という用語は、本発明の実施形態の全部が検討の対象である特徴、特長または操作モードを含むことを必ずしも要求しない。代替的な実施形態が本発明の範囲から逸脱することなく考案され、本発明の既知の構成要素は、本発明の関連する詳細を不明瞭化しないために、必ずしも詳細に説明されるとは限らず、または省略され得る。加えて、本明細書において用いられる用語は、特定の実施形態を説明することのみを目的とし、本発明を制限することを意図するものではない。例えば、本明細書において用いられる単数形の「１つの」および「その」は、内容的に明らかに単数のみを指す場合を除き、複数形をも含むことを意図するものである。本明細書において用いられる場合、「含む」、「備える」、「包含する」および／または「有する」という用語は、述べられた特徴、整数、ステップ、操作、構成要素および／またはコンポーネントが存在することを指定するが、１つまたは複数の他の特徴、整数、ステップ、操作、構成要素、コンポーネントおよび／またはこれらの群の存在または追加を除外しない。

図１Ａは、２つのプロセッサ、すなわちＣＰＵ１０２およびＡＰＤ１０４を含む統合化されたコンピューティングシステム１００の例示的な図である。ＣＰＵ１０２は１つ以上のシングルコアまたはマルチコアＣＰＵを含み得る。本発明の一実施形態において、システム１００は、統合化されたプログラミング環境および実行環境を提供するために、ＣＰＵ１０２およびＡＰＤ１０４を組み合わせた単一のシリコンダイまたはパッケージ上に形成される。この環境は、ＡＰＤ１０４が、いくつかのプログラミングタスクに対して、ＣＰＵ１０２と同程度に流動的に用いられることを可能にする。しかし、ＣＰＵ１０２およびＡＰＤ１０４が単一のシリコンダイ上に形成されることは、本発明の絶対的な要件ではない。いくつかの実施形態において、ＣＰＵ１０２およびＡＰＤ１０４は別個に形成され、同一の基板または異なる基板上に搭載されることが可能である。

１つの例において、システム１００は、メモリ１０６、オペレーティングシステム１０８および通信インフラストラクチャ１０９を含む。オペレーティングシステム１０８および通信インフラストラクチャ１０９は、以下でより詳細に説明される。

システム１００は、カーネルモードドライバ（ＫＭＤ：ｋｅｒｎｅｌ ｍｏｄｅ ｄｒｉｖｅｒ）１１０と、ソフトウェアスケジューラ（ＳＷＳ：ｓｏｆｔｗａｒｅ ｓｃｈｅｄｕｌｅｒ）１１２と、例えば入出力メモリ管理ユニット（ＩＯＭＭＵ：ｉｎｐｕｔ／ｏｕｔｐｕｔ ｍｅｍｏｒｙ ｍａｎａｇｅｍｅｎｔ ｕｎｉｔ）等のメモリ管理ユニット１１６とを含む。システム１００の構成品は、ハードウェア、ファームウェア、ソフトウェアまたはこれらの任意の組合せとして実装され得る。当業者は、システム１００が図１Ａに示される実施形態において示されるものに加えて、またはこれらとは異なる、１つ以上のソフトウェアコンポーネント、ハードウェアコンポーネントおよびファームウェアコンポーネントを含み得ることを理解するであろう。

１つの例において、ＫＭＤ１１０等のドライバは、通常、ハードウェアが接続されたコンピュータバスまたは通信サブシステムを通してデバイスと通信する。呼び出しプログラムがドライバにおいてルーチンを呼び出すと、ドライバは、デバイスに対してコマンドを発行する。デバイスがドライバに対してデータを戻すと、ドライバは、元の呼び出しプログラムにおいてルーチンを呼び出し得る。１つの例において、ドライバは、ハードウェア依存的であり、オペレーティングシステム固有である。ドライバは、通常、任意の必要な非同期的時間依存性のハードウェアインターフェースに対して要求されるインタラプトハンドリングを提供する。

デバイスドライバは、特に現代のマイクロソフト・ウィンドウズ（登録商標）プラットフォームにおいては、カーネルモード（リング０）またはユーザモード（リング３）において実行され得る。ドライバをユーザモードにおいて実行することの主要な利益は、安定性が改善されることである。なぜなら、不完全な形で書かれたユーザモードデバイスドライバは、カーネルメモリを上書きすることによってシステムをクラッシュさせることができないためである。一方、ユーザモード／カーネルモードの遷移は、通常、顕著な性能オーバーヘッドを与え、それにより、低レイテンシおよび高スループット要件のためにユーザモードドライバを阻害する。カーネルスペースは、システムコールの使用を通してのみ、ユーザモジュールからのアクセスが可能である。ＵＮＩＸ（登録商標）シェルまたは他のＧＵＩベースのアプリケーションなどのエンドユーザプログラムは、ユーザスペースの一部である。これらのアプリケーションは、カーネルにサポートされた機能を通してハードウェアと相互作用する。

ＣＰＵ１０２は、制御プロセッサ、フィールド・プログラマブル・ゲートアレイ（ＦＰＧＡ：ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）、特定用途集積回路（ＡＳＩＣ：ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）またはデジタル・シグナル・プロセッサ（ＤＳＰ：ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ）のうち１つ以上を含み得る（図示せず）。ＣＰＵ１０２は、例えば、コンピューティングシステム１００の動作を制御する、オペレーティングシステム１０８、ＫＭＤ１１０、ＳＷＳ１１２およびアプリケーション１１１を含む制御ロジックを実行する。この例示的な実施形態において、ＣＰＵ１０２は、１つの実施形態によれば、アプリケーション１１１の実行の起動および制御を、例えばそのアプリケーションに関連する処理をＣＰＵ１０２とＡＰＤ１０４等の他の処理リソースとの間に分散させることにより行う。

ＡＰＤ１０４は、とりわけ、グラフィックス演算や、例えば特に並列処理に好適となり得る他の演算等の、選択された機能のためのコマンドおよびプログラムを実行する。一般に、ＡＰＤ１０４は、ピクセル処理、幾何学演算およびディスプレイに対する画像のレンダリング等のグラフィックスパイプライン処理を実行するために、しばしば用いられ得る。本発明の様々な実施形態において、ＡＰＤ１０４は、ＣＰＵ１０２から受信したコマンドまたは命令に基づいて、計算処理演算（例えば、ビデオ演算、物理シミュレーション、計算流体力学等のグラフィックスに関連しない演算）も実行し得る。

例えば、コマンドは、通常、命令セットアーキテクチャ（ＩＳＡ：ｉｎｓｔｒｕｃｔｉｏｎ ｓｅｔ ａｒｃｈｉｔｅｃｔｕｒｅ）において定義されない特殊な命令であるとみなされ得る。コマンドは、例えばディスパッチプロセッサ、コマンドプロセッサまたはネットワークコントローラ等の特殊なプロセッサにより実行され得る。一方、命令は、例えばコンピュータアーキテクチャ内のプロセッサの単一の演算であるとみなされ得る。１つの例において、２セットのＩＳＡが用いられる場合には、いくつかの命令は、ｘ８６プログラムを実行するために用いられ、いくつかの命令は、ＡＰＤ計算ユニット上でカーネルを実行するために用いられる。

例示的な実施形態において、ＣＰＵ１０２は、選択されたコマンドをＡＰＤ１０４に伝達する。これらの選択されたコマンドは、並列実行に適したグラフィックスコマンドと、並列実行に適した他のコマンドとを含み得る。計算処理コマンドを含み得るこれらの選択されたコマンドは、実質的にＣＰＵ１０２から独立して実行され得る。

ＡＰＤ１０４は、例えば１つ以上のＳＩＭＤ処理コア等ではあるがこれに制限されない、自身の計算ユニット（図示せず）を含み得る。本明細書で参照されるＳＩＭＤは、パイプライン、すなわち、それぞれが自身のデータおよび共有プログラムカウンタを有する複数の処理エレメント上でカーネルが同時に実行されるプログラミングモデルである。全ての処理エレメントは、同等なセットの命令を実行する。プレディケーションを用いることにより、発行された各コマンドに対して、ワークアイテムを関与させることまたはさせないことが可能となる。

１つの例において、各ＡＰＤ計算ユニット１０４は、１つ以上のスカラーおよび／またはベクトル浮動小数点演算ユニットおよび／または算術論理ユニット（ＡＬＵ：ａｒｉｔｈｍｅｔｉｃ ａｎｄ ｌｏｇｉｃ ｕｎｉｔ）を含み得る。ＡＰＤ計算ユニットは、逆平方根ユニットおよびサイン／コサインユニット等の特殊用途処理ユニット（図示せず）も含み得る。１つの例において、ＡＰＤ計算ユニットは、本明細書においてシェーダコア１２２と総称される。

１つ以上のＳＩＭＤが存在することにより、一般に、ＡＰＤ１０４は、グラフィックス処理において一般的なデータ並列タスク等のデータ並列タスクの実行に、理想的に好適なものとなる。

ピクセル処理等のいくつかのグラフィックスパイプライン処理と、他の並列演算処理とは、同一のコマンドストリームまたは計算カーネルが、ストリームまたは入力データ要素の集合体上で実行されることを要求する。同一の計算カーネルのそれぞれのインスタンス化は、上記データ要素を並列に処理するために、シェーダコア１２２の複数の計算ユニット上で同時に実行され得る。本明細書で参照されるように、例えば計算カーネルは、プログラム上で宣言され、ＡＰＤ計算ユニット上で実行される命令を含む関数である。この関数は、カーネル、シェーダ、シェーダプログラムまたはプログラムとも称される。

１つの例示的な実施形態において、各計算ユニット（例えばＳＩＭＤ処理コア）は、入力されるデータを処理するために、特定ワークアイテムのそれぞれのインスタンス化を実行し得る。ワークアイテムは、コマンドによりデバイス上で呼び出されるカーネルの並列実行の集合体のうちの１つである。ワークアイテムは、計算ユニット上で実行されるワークグループの一部として、１つ以上の処理エレメントにより実行され得る。

ワークアイテムは、自身のグローバルＩＤおよびローカルＩＤによって、集合体内の他の実行から区別される。１つの例において、ワークグループ内のＳＩＭＤ上でともに同時に実行されるワークアイテムの一部は、ウェーブフロント１３６と称され得る。ウェーブフロントの幅は、計算ユニット（例えば、ＳＩＭＤ処理コア）のハードウェアの特性である。本明細書で参照されるワークグループは、単一の計算ユニット上で実行される関連するワークアイテムの集合体である。ワークグループ内のワークアイテムは、同一のカーネルを実行し、ローカルメモリおよびワークグループバリアを共有する。

代表的な実施形態において、ワークグループからの全てのウェーブフロントは、同一のＳＩＭＤ処理コア上で処理される。ウェーブフロントにわたる命令は１度に１つずつ発行され、全てのワークアイテムが同一の制御フローに従う場合には、各ワークアイテムは、同一のプログラムを実行する。ウェーブフロントは、ワープ、ベクトルまたはスレッドと称され得る。

実行マスクおよびワークアイテムプレディケーションは、ウェーブフロント内の拡散的な制御フローを可能にするために用いられる。拡散的な制御フローでは、各個別のワークアイテムは、カーネルを通る一意的なコードパスを実際に取り得る。部分的に占められたウェーブフロントは、ワークアイテムの全セットがウェーブフロント開始時に必ずしも利用可能とは限らない場合に、処理され得る。例えば、シェーダコア１２２は、所定数のウェーブフロント１３６を同時に実行し得る。なお、各ウェーブフロント１３６は、複数のワークアイテムを含む。

システム１００において、ＡＰＤ１０４は、グラフィックスメモリ１３０等の自身のメモリを含む（なお、メモリ１３０は、グラフィックス専用に制限されるとは限らない）。グラフィックスメモリ１３０は、ＡＰＤ１０４における計算実行の間の使用のために、ローカルメモリを提供する。シェーダコア１２２内の個々の計算ユニット（図示せず）は、自身のローカルデータ記憶装置（図示せず）を有し得る。１つの実施形態において、ＡＰＤ１０４は、ローカルグラフィックスメモリ１３０へのアクセス、ならびにメモリ１０６へのアクセスを含む。他の実施形態において、ＡＰＤ１０４は、ダイナミックランダムアクセスメモリ（ＤＲＡＭ：ｄｙｎａｍｉｃ ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、または、ＡＰＤ１０４には直接的に接続されているがメモリ１０６からは分離している他のメモリ（図示せず）へのアクセスを含み得る。

図示の例において、ＡＰＤ１０４は、１つまたは（ｎ）個のコマンドプロセッサ（ＣＰ：ｃｏｍｍａｎｄ ｐｒｏｃｅｓｓｏｒ）１２４を含み得る。ＣＰ１２４は、ＡＰＤ１０４内の処理を制御する。ＣＰ１２４は、実行されるべきコマンドを、メモリ１０６内のコマンドバッファ１２５から取得し、ＡＰＤ１０４でのこれらのコマンドの実行を調整する。

１つの例において、ＣＰＵ１０２は、アプリケーション１１１に基づくコマンドを、適切なコマンドバッファ１２５に入力する。本明細書において参照されるように、アプリケーションは、ＣＰＵ内またはＡＰＤ内の計算ユニット上で実行されるプログラム部分の組合せである。

複数のコマンドバッファ１２５は、各プロセスがＡＰＤ１０４での実行のためにスケジュールされた状態で、保持され得る。

ＣＰ１２４は、ハードウェア、ファームウェア、ソフトウェアまたはこれらの組合せにおいて実装され得る。１つの実施形態において、ＣＰ１２４は、スケジューリングロジックを含むロジックを実装するためのマイクロコードを有する縮小命令セットコンピュータ（ＲＩＳＣ：ｒｅｄｕｃｅｄ ｉｎｓｔｒｕｃｔｉｏｎ ｓｅｔ ｃｏｍｐｕｔｅｒ）エンジンとして実装される。

ＡＰＤ１０４は、１つまたは「ｎ」個のディスパッチコントローラ（ＤＣ：ｄｉｓｐａｔｃｈ ｃｏｎｔｒｏｌｌｅｒ）１２６を含み得る。本願において、ディスパッチという用語は、１セットの計算ユニット上の１セットのワークグループに対するカーネルの実行のスタートを起動するために、コンテキスト状態を使用するディスパッチコントローラにより実行されるコマンドを指す。ＤＣ１２６は、シェーダコア１２２内でワークグループを起動するためのロジックを含む。いくつかの実施形態において、ＤＣ１２６は、ＣＰ１２４の一部として実装され得る。

システム１００は、ＡＰＤ１０４上で実行するためのプロセスを実行リスト１５０から選択するためのハードウェアスケジューラ（ＨＷＳ：ｈａｒｄｗａｒｅ ｓｃｈｅｄｕｌｅｒ）１２８を含む。ＨＷＳ１２８は、ラウンドロビン方式、優先レベルを用いて、または他のスケジューリングポリシーに基づいて、プロセスを実行リスト１５０から選択し得る。優先レベルは、例えば、動的に決定され得る。ＨＷＳ１２８は、例えば、新規のプロセスを追加することによって、あるいは既存のプロセスを実行リスト１５０から削除することによって、実行リスト１５０を管理する機能を含み得る。ＨＷＳ１２８の実行リスト管理ロジックは、実行リストコントローラ（ＲＬＣ：ｒｕｎ ｌｉｓｔ ｃｏｎｔｒｏｌｌｅｒ）と称されることもある。

本発明の様々な実施形態において、ＨＷＳ１２８が、実行リスト１５０からプロセスの実行を開始すると、ＣＰ１２４は、対応するコマンドバッファ１２５からのコマンドの取得および実行を開始する。いくつかの事例において、ＣＰ１２４は、ＣＰＵ１０２から受信したコマンドに対応する、ＡＰＤ１０４内で実行される１つ以上のコマンドを生成し得る。１つの実施形態において、ＣＰ１２４は、ＡＰＤ１０４リソースおよび／またはシステム１００のリソースの利用が改善または最大化されるように、ＡＰＤ１０４におけるコマンドの優先化およびスケジューリングを、他のコンポーネントとともに実装する。

ＡＰＤ１０４は、インタラプトジェネレータ１４６に対してアクセスを有するか、またはインタラプトジェネレータ１４６を含み得る。インタラプトジェネレータ１４６は、ＡＰＤ１０４がページフォールト等のインタラプトイベントに遭遇すると、ＡＰＤ１０４によってオペレーティングシステム１０８にインタラプトをかけるよう構成され得る。例えば、ＡＰＤ１０４は、ＩＯＭＭＵ１１６内のインタラプト生成ロジックに依存して、上述のページフォールトインタラプトを生成し得る。

ＡＰＤ１０４は、シェーダコア１２２内で現在実行中のプロセスを切り替えるためのプリエンプションおよびコンテキストスイッチロジック１２０を含み得る。コンテキストスイッチロジック１２０は、例えばプロセスを停止させ、その現在状態（例えばシェーダコア１２２状態およびＣＰ１２４状態）を保存する機能を含む。

本明細書において参照される状態という用語は、初期状態、中間状態および／または最終状態を含み得る。初期状態は、機械がプログラム順序にしたがって入力データセットを処理することによって、データの出力セットを生成する開始点である。例えば、処理を前進させるためにいくつかのポイントにおいて記憶される必要がある中間状態が存在する。この中間状態は、他のプロセスによってインタラプトがかけられた場合に、後に実行を継続することを可能にするために記憶される場合もある。出力データセットの一部として記録され得る最終状態も存在する。

プリエンプションおよびコンテキストスイッチロジック１２０は、他のプロセスを、ＡＰＤ１０４にコンテキストスイッチするためのロジックを含み得る。他のプロセスをＡＰＤ１０４で実行するようにコンテキストスイッチするための機能は、ＡＰＤ１０４上で実行するために、例えばＣＰ１２４およびＤＣ１２６によってプロセスをインスタンス化することと、当該プロセスに対して以前に保存された状態を復元することと、当該プロセスの実行を開始することと、を含み得る。

メモリ１０６は、ＤＲＡＭ（図示せず）等の非永続型メモリを含み得る。メモリ１０６は、例えば、アプリケーションまたは他の処理ロジックの部分を実行する間に、処理ロジック命令、定数および様々な変数を記憶し得る。例えば、１つの実施形態において、ＣＰＵ１０２上で１つ以上の演算を実行するための制御ロジックの部分は、ＣＰＵ１０２によって演算のそれぞれの部分が実行される間、メモリ１０６内に常駐し得る。

実行中、個別のアプリケーション、オペレーティングシステム関数、処理ロジックコマンドおよびシステムソフトウェアは、メモリ１０６に常駐し得る。オペレーティングシステム１０８に対して必須である制御ロジックコマンドは、一般に、実行中にはメモリ１０６に常駐することとなるであろう。他のソフトウェアコマンド、例えばカーネルモードドライバ１１０およびソフトウェアスケジューラ１１２は、システム１００の実行中にはメモリ１０６に常駐し得る。

この例において、メモリ１０６は、コマンドをＡＰＤ１０４に送るために、ＣＰＵ１０２によって用いられるコマンドバッファ１２５を含む。メモリ１０６は、プロセスリストおよびプロセス情報（例えば、アクティブリスト１５２およびプロセス制御ブロック１５４）を含み得る。これらのリストおよび情報は、スケジュール情報を、ＡＰＤ１０４および／または関連するスケジューリングハードウェアに伝えるために、ＣＰＵ１０２上で実行されるスケジューリングソフトウェアによって使用される。メモリ１０６に対するアクセスは、メモリ１０６に接続されたメモリコントローラ１４０によって管理され得る。例えば、メモリ１０６に対する読み出しおよび書き込みを実行するための、ＣＰＵ１０２または他のデバイスからの要求は、メモリコントローラ１４０によって管理される。

システム１００の他の態様に戻ると、ＩＯＭＭＵ１１６は、マルチコンテキスト・メモリ管理ユニットである。

本明細書で用いられるコンテキストという用語は、カーネルが実行される環境であって、同期およびメモリ管理が定義されるドメインであるとみなされる。コンテキストは、１セットのデバイスと、これらのデバイスに対してアクセス可能であるメモリと、対応するメモリ特性と、メモリオブジェクト上におけるカーネル（単数または複数）または演算の実行をスケジュールするために用いられる１つ以上のコマンドキューとを含む。

図１Ａにおいて示される例に戻ると、ＩＯＭＭＵ１１６は、ＡＰＤ１０４を含むデバイスに対するメモリページアクセスに対して、仮想アドレスから物理アドレスへの変換を実行するためのロジックを含む。ＩＯＭＭＵ１１６は、例えば、ＡＰＤ１０４等のデバイスによるページアクセスの結果としてページフォールトが生じる場合に、インタラプトを生成するためのロジックを含み得る。ＩＯＭＭＵ１１６は、トランスレーションルックアサイドバッファ（ＴＬＢ：ｔｒａｎｓｌａｔｉｏｎ ｌｏｏｋａｓｉｄｅ ｂｕｆｆｅｒ）１１８を含むか、あるいはＴＬＢ１１８に対するアクセスを有し得る。ＴＬＢ１１８は、１つの例として、メモリ１０６内のデータ用にＡＰＤ１０４によりなされた要求に対して、論理（すなわち仮想）メモリアドレスから物理メモリアドレスへの変換を高速化するために、コンテントアドレサブルメモリ（ＣＡＭ：ｃｏｎｔｅｎｔ ａｄｄｒｅｓｓａｂｌｅ ｍｅｍｏｒｙ）に実装され得る。

示された例において、通信インフラストラクチャ１０９は、必要に応じてシステム１００のコンポーネントを相互接続する。通信インフラストラクチャ１０９は、周辺構成要素相互接続（ＰＣＩ）バス、拡張ＰＣＩ（ＰＣＩ−Ｅ）バス、アドバンスト・マイクロコントローラ・バス・アーキテクチャ（ＡＭＢＡ）バス、アドバンスト・グラフィックス・ポート（ＡＧＰ）または他の通信インフラストラクチャのうち１つ以上を含み得る（図示せず）。通信インフラストラクチャ１０９は、イーサネット（登録商標）若しくは同様のネットワークまたはアプリケーションの転送速度要求を満足する任意の好適な物理的通信インフラストラクチャを含み得る。通信インフラストラクチャ１０９は、コンピューティングシステム１００のコンポーネントを含むコンポーネントを相互接続するための機能を含む。

この例において、オペレーティングシステム１０８は、システム１００のハードウェアコンポーネントを管理する機能と、共通サービスを提供するための機能とを含む。様々な実施形態において、オペレーティングシステム１０８は、ＣＰＵ１０２上で実行し、共通サービスを提供する。これらの共通サービスは、例えば、ＣＰＵ１０２内での実行のためにアプリケーションをスケジューリングすることと、フォールト管理と、インタラプトサービスと、他のアプリケーションの入力および出力を処理することと、を含む。

いくつかの実施形態において、オペレーティングシステム１０８は、例えばインタラプトコントローラ１４８等のインタラプトコントローラによって生成されたインタラプトに基づいて、適切なインタラプトハンドリングルーチンを呼び出す。例えば、オペレーティングシステム１０８は、ページフォールト・インタラプトを検出すると、関連するページをメモリ１０６にロードし始め、且つ、対応するページテーブルを更新するために、インタラプトハンドラを呼び出す。

オペレーティングシステム１０８は、オペレーティングシステムにより管理されるカーネル機能を通して、ハードウェア部品に対するアクセスが仲介されることを確保することによって、システム１００を保護する機能を含み得る。事実、オペレーティングシステム１０８は、アプリケーション１１１等のアプリケーションが、ＣＰＵ１０２上でユーザスペースにおいて実行されることを確保する。オペレーティングシステム１０８は、アプリケーション１１１が、ハードウェアにアクセスするためにオペレーティングシステムにより提供されるカーネル機能および／または入出力機能を呼び出すことも確保する。

例として、アプリケーション１１１は、ＣＰＵ１０２上でも実行されるユーザ計算を実行するための様々なプログラムまたはコマンドを含む。ＣＰＵ１０２は、選択されたコマンドを、ＡＰＤ１０４上で処理されるためにシームレスに送信し得る。１つの例において、ＫＭＤ１１０は、ＣＰＵ１０２、ＣＰＵ１０２上で実行されるアプリケーションまたは他のロジックが、ＡＰＤ１０４の機能を呼び出し得るアプリケーションプログラミングインタフェース（ＡＰＩ）を実装する。例えば、ＫＭＤ１１０は、ＣＰＵ１０２からのコマンドを、コマンドバッファ１２５にエンキューし得る。なお、ＡＰＤ１０４は、このコマンドバッファ１２５からコマンドを続けて取得することとなる。加えて、ＫＭＤ１１０は、ＡＰＤ１０４上で実行されるプロセスのスケジューリングを、ＳＷＳ１１２とともに実行する。ＳＷＳ１１２は、例えば、ＡＰＤ上で実行されるプロセスの優先度リストを保持するためのロジックを含み得る。

本発明の他の実施形態において、ＣＰＵ１０２上で実行するアプリケーションは、コマンドをエンキューするときに、ＫＭＤ１１０を完全にバイパスし得る。

いくつかの実施形態において、ＳＷＳ１１２は、ＡＰＤ１０４上で実行されるプロセスのアクティブリスト１５２を、メモリ１０６に保持する。ＳＷＳ１１２は、アクティブリスト１５２におけるプロセスのうち、ハードウェアのＨＷＳ１２８により管理される一部を選択する。各プロセスをＡＰＤ１０４上で実行することに関する情報は、ＣＰＵ１０２からプロセス制御ブロック（ＰＣＢ：ｐｒｏｃｅｓｓ ｃｏｎｔｒｏｌ ｂｌｏｃｋ）１５４を通して、ＡＰＤ１０４に伝えられる。

アプリケーション、オペレーティングシステムおよびシステムソフトウェアのための処理ロジックは、マスクワーク／フォトマスクの生成を通して最終的に製造プロセスを構成することで、本明細書において説明される本発明の態様を具体化するハードウェア装置を生成することを可能にするための、例えば、Ｃ言語等のプログラム言語および／またはＶｅｒｉｌｏｇ、ＲＴＬ等のハードウェア記述言語もしくはネットリストにおいて指定されるコマンドを含み得る。

当業者は、コンピューティングシステム１００が、図１Ａにおいて示されるコンポーネントよりも多数または少数のコンポーネントを含み得ることを、本明細書を読むことで理解するであろう。例えば、コンピューティングシステム１００は、１つ以上の入力インターフェースと、不揮発性ストレージと、１つ以上の出力インターフェースと、ネットワークインターフェースと、１つ以上のディスプレイまたはディスプレイインターフェースと、を含み得る。

図１Ｂは、図１Ａにおいて示されるＡＰＤ１０４のより詳細な例示を示す実施形態である。図１Ｂにおいて、ＣＰ１２４は、ＣＰパイプライン１２４ａ，１２４ｂ，１２４ｃを含み得る。ＣＰ１２４は、図１Ａにおいて示されるコマンドバッファ１２５から入力として提供されるコマンドリストを、処理するように構成され得る。図１Ｂの典型的な動作において、ＣＰ入力０（１２４ａ）は、コマンドをグラフィックスパイプライン１６２に駆動することを担当する。ＣＰ入力１および２（１２４ｂおよび１２４ｃ）は、コマンドを計算パイプライン１６０に伝える。ＨＷＳ１２８の動作を制御するためのコントローラ機構１６６も提供される。

図１Ｂにおいて、グラフィックスパイプライン１６２は、本明細書において順序化パイプライン１６４と称される、１セットのブロックを含み得る。例えば、順序化パイプライン１６４は、頂点グループ変換器（ＶＧＴ：ｖｅｒｔｅｘ ｇｒｏｕｐ ｔｒａｎｓｌａｔｏｒ）１６４ａと、プリミティブアセンブラ（ＰＡ：ｐｒｉｍｉｔｉｖｅ ａｓｓｅｍｂｌｅｒ）１６４ｂと、スキャンコンバータ（ＳＣ：ｓｃａｎ ｃｏｎｖｅｒｔｅｒ）１６４ｃと、シェーダエクスポート・レンダーバック・ユニット（ＳＸ／ＲＢ：ｓｈａｄｅｒ−ｅｘｐｏｒｔ，ｒｅｎｄｅｒ−ｂａｃｋ ｕｎｉｔ）１７６とを含む。順序化パイプライン１６４内の各ブロックは、グラフィックスパイプライン１６２内の異なる段階のグラフィックス処理を表し得る。順序化パイプライン１６４は、固定機能ハードウェアパイプラインであり得る。本発明の精神および範囲に含まれ得る他の実装を用いることも可能である。

わずかな量のデータが、入力としてグラフィックスパイプライン１６２に提供されるが、このデータは、グラフィックスパイプライン１６２からの出力として提供される回数分だけ増幅されることとなるであろう。グラフィックスパイプライン１６２は、ＣＰパイプライン１２４ａから受け取ったワークアイテムグループ内の範囲にわたってカウントするためのＤＣ１６６も含む。ＤＣ１６６を通して提示された計算作業は、グラフィックスパイプライン１６２と準同期している。

計算パイプライン１６０は、シェーダＤＣ１６８，１７０を含む。ＤＣ１６８，１７０のそれぞれは、ＣＰパイプライン１２４ｂ，１２４ｃから受け取ったワークグループ内の計算範囲にわたってカウントするように構成されている。

図１Ｂにおいて示されるＤＣ１６６，１６８，１７０は、入力範囲を受け取り、入力範囲をワークグループに分割し、次いでこれらのワークグループをシェーダコア１２２に伝える。

グラフィックスパイプライン１６２は、一般に固定機能パイプラインであるため、その状態を保存および復元することは困難であり、そのためグラフィックスパイプライン１６２は、コンテキストスイッチが困難である。したがって、ほとんどの場合、本明細書において論じられるコンテキストスイッチは、グラフィックス処理におけるコンテキストスイッチに関係しない。例外は、シェーダコア１２２におけるグラフィックス作業であり、これはコンテキストスイッチされ得る。

グラフィックスパイプライン１６２内の作業の処理が完了した後に、完了した作業は、レンダーバックユニット１７６を通して処理される。レンダーバックユニット１７６は、デプス計算およびカラー計算を行い、次いでその最終結果をメモリ１３０に書き込む。

シェーダコア１２２は、グラフィックスパイプライン１６２および計算パイプライン１６０により共有され得る。シェーダコア１２２は、ウェーブフロントを実行するように構成された一般的なプロセッサである。１つの例において、計算パイプライン１６０内の全ての作業は、シェーダコア１２２内で処理される。シェーダコア１２２は、プログラム可能なソフトウェアコードを実行し、例えば状態データ等の様々な形態のデータを含む。

ＱｏＳにおける混乱は、全てのワークアイテムが、ＡＰＤリソースにアクセスできない場合に生じる。本発明の実施形態は、２つ以上のタスクが、ＡＰＤ １０４内のリソースに対して効率的かつ同時に起動するのを容易にして、全てのワークアイテムが、様々なＡＰＤリソースにアクセスできるようにする。一実施形態では、ＡＰＤ入力方式は、ＡＰＤの作業負荷を管理することにより、全てのワークアイテムが、ＡＰＤのリソースに対して並行してアクセスできるようにする。（例えば、最大入出力速度に達している間に）ＡＰＤの作業負荷が最高レベルに近づくと、このＡＰＤ入力方式は、他の方法では使用されない処理リソースが多くのシナリオで同時に利用できるようにすることを支援する。例えば、一連の入力ストリームは、ＡＰＤへの同時並列入力として現れるように抽象化できる。

例として、ＣＰ１２４の各々は、ＡＰＤ１０４内の他のリソースへの入力として送るための１つ以上のタスクを有することができ、各タスクは、複数のウェーブフロントを表すことができる。第１のタスクが入力として遅れられた後に、このタスクは、そのタスクの完了に必要な全てのＡＰＤリソースを利用するために、ある期間にわたって増加するのが許可され得る。それだけで、この第１のタスクは、最大ＡＰＤ利用閾値に達し得ることもあれば、達し得ないこともある。しかし、他のタスクがキューに加えられ、ＡＰＤ１０４内で処理されるのを待機しているとき、ＡＰＤリソースの割当ては、タスクの全てがＡＰＤ １０４を同時に使用できることを確実にするように管理でき、各々のタスクがＡＰＤの最大利用の割合を達成する。複数のタスクによるＡＰＤ１０４の同時使用および各タスクの合計の利用割合は、所定の最大ＡＰＤ利用閾値が達成されることを確実にする。

図２は、図１Ｂに示すＡＰＤ１０４のさらなる詳細を示すブロック図である。図２では、ＡＰＤ１０４は、シェーダコア１２２へのアクセスを調停するシェーダリソースアービタ（ｓｈａｄｅｒ ｒｅｓｏｕｒｃｅ ａｒｂｉｔｅｒ）２０４を含む。図２では、シェーダリソースアービタ２０４は、シェーダコア１２２の外側にある。別の実施形態では、シェーダリソースアービタ２０４は、シェーダコア１２２内に存在し得る。さらなる実施形態では、シェーダリソースアービタ２０４は、グラフィックスパイプライン１６２内に含まれ得る。シェーダリソースアービタ２０４は、計算パイプライン１６０、グラフィックスパイプライン１６２またはシェーダコア１２２と通信するように構成され得る。

シェーダリソースアービタ２０４は、ハードウェア、ソフトウェア、ファームウェアまたはそれらの任意の組合せを用いて、実装され得る。例えば、シェーダリソースアービタ２０４は、プログラム可能なハードウェアとして実装され得る。

前述のように、計算パイプライン１６０は、図１Ｂに示すように、ＤＣ１６８，１７０を含み、ＤＣ１６８，１７０は、入力スレッドグループを受信する。スレッドグループは、所定数のスレッドを含むウェーブフロントに分けられる。各ウェーブフロントスレッドは、例えば頂点シェーダ（ｖｅｒｔｅｘ ｓｈａｄｅｒ）などのシェーダプログラムを含み得る。シェーダプログラムは、通常、コンテキスト状態データのセットと関連する。シェーダプログラムは、シェーダコアプログラム実行のために、シェーダコア１２２に転送される。

動作中、各シェーダコアプログラムは、いくつかの汎用レジスタ（ＧＰＲ）（図示せず）にアクセスするが、ＧＰＲは、プログラムを実行する前に、シェーダコア１２２に動的に割り当てられる。ウェーブフロントが処理される準備ができている場合、シェーダリソースアービタ２０４は、ＧＰＲおよびスレッド空間を割り当てる。シェーダコア１２２は、新しいウェーブフロントが実行のために準備ができていることを通知され、そのウェーブフロントについてシェーダコアプログラムを実行する。

図１に示すように、ＡＰＤ１０４は、例えば１つ以上のＳＩＭＤなどの計算ユニットを含む。図２では、例えば、シェーダコア１２２は、特定のワークグループのそれぞれのインスタンス化を実行するための、あるいは着信データを処理するための、ＳＩＭＤ２０６Ａ〜２０６Ｎを含む。ＳＩＭＤ２０６Ａ〜２０６Ｎは、それぞれローカルデータストア（ＬＤＳ）２０８Ａ〜２０８Ｎに結合されている。ＬＤＳ２０８Ａ〜２０８Ｎは、それぞれのＳＩＭＤによってのみアクセス可能な専用（ｐｒｉｖａｔｅ）のメモリ領域を提供する。ＬＤＳ２０８Ａ〜２０８Ｎは、ワークグループに対して専用である。ＬＤＳ２０８Ａ〜２０８Ｎは、シェーダプログラムのコンテキスト状態データを格納する。

以下で説明するように、本発明の態様は、ソフトウェア、ハードウェア、ファームウェアおよび／または図に示す実体の多くの異なる実施形態で実施され得ることが当業者には明らかであろう。本発明を実施するために特殊化したハードウェア制御を備えたいかなる実際のソフトウェアコードも、本発明を制限しない。従って、本発明の操作上の挙動は、本明細書で提示するレベルの詳細を前提として、実施形態の修正および変形が可能であるという理解の下で説明されるであろう。

さらに、当業者には明らかであるように、本発明の様々な実施形態のシミュレーション、合成および／または製造は、汎用プログラミング言語（ＣまたはＣ＋＋など）、Ｖｅｒｉｌｏｇ ＨＤＬ、ＶＨＤＬ、Ａｌｔｅｒａ ＨＤＬ（ＡＨＤＬ）などを含むハードウェア記述言語（ＨＤＬ）、または他の利用可能なプログラミングツールおよび／もしくは概略図キャプチャツール（回路キャプチャツールなど）を含む、コンピュータ可読コード（前述したような）の使用を通じて、部分的に達成され得る。このコンピュータ可読コードは、半導体、磁気ディスク、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭなど）を含む任意の既知のコンピュータ使用可能媒体内に、あるいは、コンピュータ使用可能（例えば、可読）伝達媒体（搬送波、またはデジタル、光若しくはアナログベースの媒体を含む任意の他の媒体など）内で具体化されたコンピュータデータ信号として、配置され得る。

そのため、コードは、インターネットおよびイントラネットを含む通信ネットワークを経由して伝送され得る。前述したシステムおよび技術によって達成される機能および／または提供される構造は、プログラムコードで具体化されるコア（ＡＰＤコアおよび／もしくはＣＰＵコアまたは他の処理コアなど）内に表され得ること、及び、集積回路の製造の一部としてハードウェアに変換され得ることを理解されたい。

図３は、コマンドをＡＰＤにサブミットするためにカーネルモードドライバに依存するデータフローモデル３００を示す。このデータフローモデルでは、ユーザモードアプリケーション３０２がコマンドバッファ３０４を操作し、それに対してアプリケーション３０２が、ＡＰＤコアによる実行のためのコマンドを書き込む。アプリケーション３０２が準備できると（例えば、コマンドバッファが満杯であるため）、アプリケーション３０２は、データを、コマンドバッファから、ＡＰＤエンジンリングバッファ３０８へのアクセスを有するカーネルモードドライバ３０６へ転送する。カーネルモードドライバ３０６（または他のカーネルモードソフトウェア）は、コマンドバッファ３０４からコマンドを読み取り、それらをＡＰＤエンジンリングバッファ３０８に書き込むことができる。

データフローモデル３００のアプローチは、コマンドのリングバッファ３０８への送信ごとに、ユーザモードとカーネルモードとの間で遷移する。図４は、図３のデータフローモデル３００の概念を、例示的なＷｉｎｄｏｗｓ（登録商標）環境に適用する追加のデータフローモデル４００を示すが、当業者は、データフローモデル４００の他の動作環境への適用性を認識するであろう。

データフローモデル４００に示すように、例えばユーザモードアプリケーション３０２などのアプリケーション用のＡＰＤコンテキストは、ステップ４０２において作成され、メモリは、カーネルモードドライバの機能性（例えば、コマンドバッファ３０４の割当てを含む）を用いてステップ４０４において割り当てられる。ユーザモードアプリケーション３０２は、ステップ４０６においてコマンドバッファ３０４を命令で充填し、コマンドバッファ３０４は、ステップ４０８においてＷｉｎｄｏｗｓ（登録商標） Ｄｉｓｐｌａｙ Ｄｒｉｖｅｒ Ｍｏｄｅｌ（例示的なＷｉｎｄｏｗｓ（登録商標）環境では、「ＷＤＤＭ」）コンポーネントに転送される。ステップ４１０において、カーネルモードドライバは、アプリケーション３０２用のコンテキストをコンテキストキューに追加でき、コマンドバッファ３０４の処理の準備が整っていることを示す。カーネルモードソフトウェアは、次いで、ステップ４１４において、コマンドを、コマンドバッファ３０４からＡＰＤエンジンリングバッファ３０８に送信することができる。

このアプローチは、アプリケーションのＡＰＤ命令を、カーネルモードドライバ（例えば、Ｗｉｎｄｏｗｓ（登録商標）環境におけるＤＸＧＫＲＮＬ）を介して送る（ｆｕｎｎｅｌ）。このアプローチにはいくつかの欠点があり、主としてＡＰＤの元の設計フォーカスから生じる。このアプローチでは、ＡＰＤは、グラフィックスコンテキストの外部のアプリケーションからの一般的な処理命令を処理するように意図されていない。全ては、標準的なグラフィックスインタフェースを通じてパッケージ化される必要がある。コマンドをサブミットする際のユーザモードとカーネルモードとの間で必要な遷移は、コストがかかり、ハードウェア特権レベルの遷移を必要とする。さらに、単一のＡＰＤエンジンリングバッファ３０８への書込みはロックを必要とし、それは、他のＡＰＤバウンドアプリケーションをブロックすることになる。

このレガシーアプローチが直面する追加の課題は、ＡＰＤリングバッファに追加されている動作が、仮想メモリ空間への参照について検査される必要があることである。具体的には、ＡＰＤは、ＡＰＤメモリおよびピン留めされたシステムメモリ（ｐｉｎｎｅｄ ｓｙｓｔｅｍ ｍｅｍｏｒｙ）上で動作することが許可されているだけである。そうでない場合、操作によって参照されるデータは、その参照されるデータをメインメモリにコピーし、それをピン留めすることなどにより、ＡＰＤメモリおよびピン留めされたシステムメモリの何れかに取り込まれる必要がある。

コマンドをＡＰＤエンジンリングバッファ３０８にサブミットする前に、ＡＰＤが、ＡＰＤエンジンリングバッファ３０８に書き込みを行うコマンドによって参照されるメモリにアクセスできることを確実にするために、ステップ４１２が実行される。これは、仮想メモリへの全ての参照に対してコマンドバッファをトラバースすることと、これらの参照を、物理メモリアドレス参照を用いてパッチをあてることとを含む。物理メモリ参照が存在しない場合、仮想メモリによって参照されるデータは、ＡＰＤで使用できるように、ＡＰＤメモリのピン留めされたシステムメモリにページインされる必要がある。

ＡＰＤリングバッファに操作をポストする前に、全ての操作に対して参照されるメモリの可用性を確実にする必要性は、高価になり得る。パッチのチェックは、参照データがピン留めされたシステムメモリまたはＡＰＤメモリに既に存在するか否かに関わらず、全ての操作で実行される必要がある。結果として、ＡＰＤリングバッファへのコマンドのサブミットは、著しいオーバーヘッドを伴う。

図３および図４に示すデータフローモデルに関連する性能問題を克服または縮小するために、ＡＰＤを第１級オブジェクト（ｆｉｒｓｔ−ｃｌａｓｓ ｃｉｔｉｚｅｎ）として扱うことのできる機能を組み込むことが有益である。言い換えれば、ＣＰＵと同等な（または同等に近い）コンピューティングリソースとして扱われることである。ＡＰＤおよびＡＰＤがアクセス可能なメモリ空間を、ＣＰＵと同様の方法で処理可能にするという概念は、いくつかの異なる方法で達成できる。しかし、様々な実施形態では（例えば、オペレーティングシステムからの完全なサポートおよびネイティブのハードウェアサポートを受けて）、アプリケーションの初期化を超えてカーネルモード遷移を回避することが可能である。

図５は、本発明の実施形態による、システムスタック５００の例示的なコンポーネントを示す。各ユーザモードアプリケーションは、ランタイム５０２を含み、アプリケーションとのリソースの確立および接続を可能にする。ＤＸＧＫＲＮＬ ５０４（Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標） ＤｉｒｅｃｔＸグラフィックスカーネルサブシステムであり、ＡＰＤに対するレガシーのグラフィックス指向カーネルモードドライバインタフェースを代表する）を通じてコマンドをチャネリングする代わりに、前述した例によって、システムスタック５００は、アプリケーションのためにメモリおよびコマンドキューの割当てを可能にするＩＯＭＭＵｖ２ドライバ５０６を導入する。

システムスタック５００は、ＡＰＤスケジューラ５０８ａおよびＣＰＵスケジューラ５０８ｂをさらに含む。ＣＰＵスケジューラ５０８ｂは、ＣＰＵバウンド作業をスケジューリングするための既存のシステム内に存在する従来型のスケジューラに類似しているが、ＡＰＤスケジューラ５０８ａは、ＡＰＤバウンド作業のスケジューリングを処理する。ＡＰＤスケジューラ５０８ａの動作は、以下でさらに詳細に説明される。

システムスタック５００は、ＡＰＤメモリ管理コンポーネント５１０ａおよびＣＰＵメモリ管理コンポーネント５１０ｂを追加として含む。ＣＰＵメモリ管理コンポーネント５１０ｂは、メモリをＣＰＵバウンドアプリケーションに割り当てるための既存のオペレーティングシステム内に存在する従来型のメモリマネージャに類似しているが、ＡＰＤメモリ管理コンポーネント５１０ａは、ＡＰＤバウンドコマンドを有するアプリケーションに対するメモリオブジェクトの割当てを処理する。

図５は、オペレーティングシステムおよび基本的なハードウェアから協働が得られる例示的な実施形態を示しているが、当業者は、図３および図４のデータフローモデルに関連する性能問題を回避するために、他の機構が採用され得ることを理解するであろう。

図６は、本発明の実施形態による、例示的なデータフローモデル６００を示す。データフローモデル６００は、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムのコンポーネントを参照するが、当業者は、データフローモデル６００によって示される概念が、他のオペレーティングシステムを含むがそれらに限定されず、他のシステムに提供できることを理解するであろう。

図５のＩＯＭＭＵｖ２ドライバ５０６（または他のカーネルモードドライバもしくはカーネルモードソフトウェアコンポーネント）によって、ユーザモードアプリケーションは、ステップ６０２において、自身のユーザモードアクセス可能な作業待ち行列（例えば、リングバッファ）を作成できる。限定されない例として、初期化中、ユーザモードアプリケーションは、作業待ち行列を割り当てるために、ランタイム５０２内の関数を呼び出す。この作業待ち行列は、限定されない例として、リングバッファまたは他のＦＩＦＯキューであり得るが、当業者は、コマンドバッファリングのための他の技術が使用され得ることを理解するであろう。アプリケーションは、カーネルモードドライバ内のカーネルモード関数をさらに呼び出し、カーネルモード関数は、ステップ６０４において、ＡＰＤによるアクセスのためにリングバッファを登録する。

本発明のさらなる実施形態による、ステップ６０６において、同じカーネルモードドライバは、リソース割当て要求をアプリケーションから受け入れ、ステップ６０８において、ＡＰＤメモリまたはピン留めされたシステムメモリなどのリソースを割り当てる。メモリは、仮想メモリアドレスを用いて割り当てられ得るが、それらは、（初期化前の場合のように）現在物理メモリ空間内にないデータに対応し得る。

初期化後、データフローモデル６００は、実行の間、ユーザモードアプリケーションの挙動を示す。アプリケーションの実行の間、アプリケーションは、ステップ６１０においてコマンドバッファを充填できる。コマンドバッファの内容は、ステップ６１２において、アプリケーションのリングバッファに転送され得、ステップ６１４において、そこから命令がＡＰＤにディスパッチされる。

当業者は、ステップ６１０におけるコマンドバッファなどのコマンドバッファの使用が随意であり、コマンドが、代わりとして、ステップ６１２において使用されるリングバッファに直接転送され得ることを理解するであろう。コマンドバッファは、限定されない例として、リングバッファへの書込みが高価な操作（書込み操作が、図３および図４の例における統合化されたリングバッファをブロックする場合など）であるような状況で採用され得る。しかし、各アプリケーションが、カーネルモードドライバによって割り当てられた自身のリングバッファを有する状況では、この操作は、伝統的にそれに関連した同じコストが掛からない可能性があり、従って、性能コストの削減がコマンドバッファの不使用によって実現できる。従って、本明細書でのコマンドバッファへの参照は、コマンドバッファ内に置かれているコマンドが、代わりにアプリケーションのリングバッファに直接転送されるという状況を企図する。

例示する実施形態は、実行時、ＡＰＤによって処理される命令を処理するために、いくつかのコンポーネントに依存する。図７は、本発明の実施形態による、実行時における例示的なアーキテクチャのシステム概要７００を示す。前述したように、各アプリケーション７０２には、それぞれのリングバッファ７０４が割り当てられている。このリングバッファ７０４は、１つ以上のコマンドバッファ７０６に格納されているコマンドによって書き込まれ得る。しかし、前述したように、コマンドバッファ７０６の使用は随意であり、代わりに、コマンドがリングバッファ７０４に直接書き込まれ得る。

さらに、カーネルモードドライバは、いくつかのカーネル空間メモリオブジェクトを割り当てて、保持する。これらのカーネル空間メモリオブジェクトは、計算プロセス制御ブロックおよび実行リストエントリ７１０を含み、対応するアプリケーション７０２に割り当てられている。計算プロセス制御ブロック７１０の未処理のインスタンスを参照するマスタ計算プロセスリスト７０８が、登録されているアプリケーションのリストを追跡するために使用される。当業者は、個々のアプリケーション７０２に関する情報を保持する他の方法が使用され得ることと、この特定の方法が制限ではなく、例として提供されていることとを理解するであろう。カーネル空間メモリオブジェクトは、コンテキストスイッチブロック７１２も含む。これらのメモリブロックは、対応するアプリケーションがマルチタスク環境においてスイッチアウトされる場合にはいつでも、ＡＰＤの現在の状態（すなわち、コンテキスト）を保存するために使用される。アプリケーションのコンテキスト切替えは、スケジューラの操作に関連して、以下でさらに説明される。

前述したように、システム概要７００で説明したアーキテクチャの有益性の１つは、作業をユーザモードアプリケーションからＡＰＤに送信する際に、カーネルモード遷移を回避する能力である。アプリケーション７０２がカーネルモードドライバに登録される場合、アプリケーション７０２は、対応する計算プロセス制御ブロック７１０に割り当てられる。ＡＰＤは、計算プロセス制御ブロック７１０にアクセスして、関連するプロセスコンテキストに関連した特権状態情報を取得するが、この情報は、アプリケーション７０２のリングバッファ７０４の位置を含む。結果として、ＡＰＤは、コストのかかるカーネルモード遷移を必要とすることなく、リングバッファ７０４からのコマンドにアクセスできる。

計算プロセス制御ブロック７１０は、スケジューリングの処理に有用な追加の情報を含み得る。例えば、対応するアプリケーション７０２に対する優先レベル（例えば、低、中、高、リアルタイム）が計算プロセス制御ブロック７１０内に保持され得、優先レベルは、以下でさらに詳述するように、ＡＰＤ処理時間をアプリケーション７０２に割り当てるために、スケジューラによって利用され得る。優先度情報は、タイマリセット値も含み得、次のスケジューリングウィンドウ中に処理するＡＰＤ処理時間（例えば、クロック周期または個々の命令の数など）を示す。計算プロセス制御ブロック７１０は、ＡＰＤがアプリケーションコンテキストを切り替えるときに利用できる、対応するコンテキストスイッチブロック７１２への参照も含む。したがって、ＡＰＤは、計算プロセス制御ブロック７１０を、ＡＰＤがサービスする個々のアプリケーション７０２の表現として利用する。

本発明の実施形態によれば、リングバッファ７０４は、ＡＰＤによってアクセスされる際にメモリ内に常駐していることが保証され、ページアウトできない。カーネルモードドライバ計算インターフェースは、ユーザ空間常駐コマンドバッファを割り当てるために使用されるが、それは、ＡＰＤハードウェアによって直接アクセス可能であり、計算作業負荷ディスパッチおよび完了プロセスが任意のカーネルモード遷移を迂回できるようにする。本発明の追加の実施形態によれば、ＩＯＭＭＵｖ２およびＡＰＤハードウェアのサポートを受けて、ページフォールトがユーザ空間コマンド（およびデータ）バッファ７０６に対してサポートされるが、それは、これらのバッファがメモリピン留めのオーバーヘッドを回避できるようにする。

図３および図４のデータフローモデルとは対照的に、カーネルモードソフトウェアが仮想メモリ参照に対してパッチを当てるために、ユーザモードアプリケーションによって送信されたコマンドをトラバースする必要があり、それによって、全ての参照が、ピン留めされたシステムメモリまたはＡＰＤメモリに常駐することを保証する。ＡＰＤは、任意のパッチが行われる前に、リングバッファ７０４に直接アクセスすることができる。それ故、ＡＰＤは、様々な機構の１つによってページフォールトを識別し処理できる必要がある。

例えば、仮想メモリを参照する命令がＡＰＤによって処理される場合、仮想メモリアドレスが物理メモリアドレスに対応しているか否かに関して（例えば、ページテーブルを使用して）判断が行われる。対応していない場合、ＡＰＤは、システムのＣＰＵに対してページフォールトをトリガーし得、ＣＰＵが、データを、対応する仮想メモリアドレスから、ピン留めされたシステムメモリまたはＡＰＤメモリに読み出すことができるようにする。ＡＰＤの能力が許せば、ＡＰＤは、ページフォールトでブロックしながら別のアプリケーションコンテキストに切り替えることができるか、または代わりに、ページフォールトがサービスされるのを待機しながら、停止（ｓｔａｌｌ）できる。

本発明のさらなる実施形態によれば、ＡＰＤは、ページフォールトが必要か否かを判断するために、サービスする前に命令を調べることができ、必要であれば、ＣＰＵのページフォールト機構インタラプトをトリガーするであろう。

ユーザモードアプリケーション７０２の観点から見れば、前述した機能は、システムのＣＰＵと同様の方法で、ＡＰＤとの直接のやりとりを可能にする。本発明のある実施形態のこの特性は、ＣＰＵと比較して、ＡＰＤを「第１級オブジェクト」として確立すると言われる。

図８は、本発明の実施形態による、図７のアプリケーション７０２などのアプリケーションが初期化されるステップを示すフロー図である。方法は、ステップ８０２から始まり、アプリケーション自身が初期化されるステップ８０４まで進む。当業者は、ステップ８０４の初期化プロセスは、アプリケーションに固有の、いくつかの異なる機能を含み得ることを理解するであろう。

限定されない例として、ステップ８０４におけるアプリケーションの初期化は、図７の計算プロセス制御ブロック７１０などの計算プロセス制御ブロックの作成を含む。当業者は、ＡＰＤにアクセス可能なアプリケーションの表現が、それによって保持され更新され得る他の機構が使用され得ることを理解するであろう。

ステップ８０６および８０８は、本発明の態様を利用するアプリケーションに対する初期化プロセスを示す。ステップ８０６において、リングバッファ（図７のリングバッファ７０４または他の形式のコマンドバッファ（例えば、ＦＩＦＯキュー）など）がアプリケーションに割り当てられ、ステップ８０８において、メモリリソースが割り当てられる。方法は、その後、ステップ８１０で終了する。

前述したように、ステップ８０６および８０８におけるリングバッファ７０４およびメモリリソースの割当ての各々は、カーネルモードドライバまたは他のカーネルモードソフトウェアとのやりとりを通して処理される（例えば、図６のステップ６０４におけるように、アプリケーションがリングバッファ７０４を割り当てて、それをカーネルモードソフトウェアに登録する）。リングバッファ７０４およびメモリリソースは、リソースを利用するために他のアプリケーションのブロックまたはカーネルモードへの遷移を必要とすることなく、アプリケーションおよびＡＰＤにアクセス可能である。

図９は、ＡＰＤによって実行されるためのコマンドをアプリケーションが提供するステップを示すフロー図である。方法は、ステップ９０２から始まり、アプリケーションが、コマンドバッファおよび任意の参照データバッファを充填するステップ９０４に進む。図７のコマンドバッファ７０６などのコマンドバッファに格納されたコマンドは、図７のリングバッファ７０４などのリングバッファに転送される。本発明のさらなる実施形態によれば、ステップ９０６の代わりに、コマンドが、アプリケーションによって直接リングバッファ７０４内に置かれ得、これによって、別個のコマンドバッファの使用をスキップする。

ステップ９０８において、リングバッファ７０４内のコマンドは、ディスパッチの準備ができている。方法は、ステップ９１０で終了する。前述したように、ＡＰＤハードウェアは、リングバッファ７０４に格納されたコマンドに直接アクセスでき、例えばスケジューリングアルゴリズムによってコマンドの処理を開始するように指示される場合などのように必要に応じて、適切なアプリケーションのリングバッファ７０４からコマンドの処理を開始できる。

図６のステップ６０４のように、リングバッファを各アプリケーションに割り当てることにより、スケジューリングを様々な異なる方法で処理することが可能である。特に、図３および図４に示すデータフローモデルでのスケジューリングは、データを、統合化されたＡＰＤ用のリングバッファにプッシュすることにより達成される。ＡＰＤハードウェアは、操作がどのような順番で提示されても、リングバッファから操作をプルするであろう。リング内に置かれたデータの特定のパケットの完了を信号通知するために、統合化されたリングバッファ内の操作パケット内の最後の操作がタイムスタンプを増加させる技術が使用される。しかし、この操作は、待ち時間を追加し、ハードウェアインタラプトの実行によって取り込まれる非効率性を要求する。このアプローチはまた、操作パケット全体に対して完了が判断されるので、特定のタイムフレーム内でいくつの操作が処理されているのかを正確に判断する場合、解決策を欠いている。

対照的に、本発明の例示的な実施形態では、スケジューラまたは他の機構が、次に実行する特定のアプリケーションコンテキスト（図７の計算プロセス制御ブロック７１０によって識別されるアプリケーションなど）を選択できるようにして、選択されたアプリケーション７０２のリングバッファ７０４から実行用のＡＰＤに命令を提供する。また、アプリケーションのリングバッファ７０４内の作業パケットは、ユーザモード内で完全に自身の完了を信号通知することができ、低コストかつ低解像度の構成可能な解決策を完了の信号通知に提供する。

当業者は、スケジューリングに対するいくつかのアプローチが、本明細書で開示する実施形態に適用でき、また、本明細書で説明するアプローチは、制限ではなく、例として提供されていることを理解するであろう。図１０は、本発明の実施形態による、図５のＡＰＤスケジューラ５０８ａなどのスケジューラが、ＡＰＤコマンドの処理をスケジューリングするステップを示すフロー図１０００である。方法は、ステップ１００２から始まり、計算プロセス制御ブロック７１０が、（アプリケーションの初期化中などに）アプリケーション７０２に割り当てられるステップ１００４に進む。ステップ１００６において、リングバッファ７０４またはコマンドをアプリケーション７０２からキューに登録するための他のデータ構造が、アプリケーション７０２に割り当てられる。

ステップ１００８において、スケジューラは、スケジューリングする次のアプリケーションを判断する。これは、限定されない例として、スケジューリングする次のアプリケーションに対応する計算プロセス制御ブロックまたは実行リスト７１０の選択を通じて、達成され得る。次の計算プロセス制御ブロック７１０の選択は、ラウンドロビンのスケジューリングなど、いくつかのスケジューリングアルゴリズムによって処理され得る。他のスケジューリングアルゴリズムの使用は、当業者には明らかであろう。

本発明の追加の実施形態によれば、アプリケーション７０２は、実行のために選択されるのが望ましいということをＡＰＤに通知することができる。これは、限定されない例として、コマンドがリングバッファ７０４に追加される場合にはいつでも、アプリケーションによる「ドアベル（ｄｏｏｒｂｅｌｌ）」信号の使用を通じて処理される。待機しているコマンドが、「ドアベル」信号の使用を通じてＡＰＤに通知されていない場合、ＡＰＤは、ステップ１００８において、コマンドがそのリングバッファ７０４内に存在すること、またはＡＰＤが別の方法で準備の整ったＡＰＤコマンドを有していることを知っていることを信号通知している次の計算プロセス制御ブロック７１０にスキップできる。

スケジューラが、実行する次のアプリケーション７０２を、対応する計算プロセス制御ブロック７１０によって識別すると、ＡＰＤは、アプリケーションのリングバッファ７０４の位置を、計算プロセス制御ブロック７１０から取得する。ＡＰＤは、次いで、ステップ１０１２において、リングバッファ７０４から直接コマンドをサービスできる。

アプリケーション７０２は、ＣＰＵバウンドのコマンドを自由に別々に実行しながら、ＡＰＤバウンドのコマンドのみをリングバッファ７０４内に配置することができる。これは、ＣＰＵおよびＡＰＤが、他の完了を待機する必要なく（従属関係の場合を除く）、命令を異なる速度および頻度で実行できることを意味する。ステップ１０１２においてＡＰＤがコマンドをサービスしている間、ＣＰＵは、自身のコマンドについて操作を継続できる。

ＡＰＤは、ステップ１０１２において、いくつかのコマンドのサービスを継続し、次いで、スケジューラがＡＰＤ時間に対して異なるアプリケーションをスケジューリングし得るステップ１０１４に進み、この場合、方法は、ステップ１００８に再度進む。スケジューリングするアプリケーションがもう残っていなければ、方法は、ステップ１０１６で終了し、ＡＰＤはアイドルのままである。

ステップ１０１２において、後続のアプリケーションのスケジューリング前に、ＡＰＤによってサービスされるコマンドの数は、いくつかの要因によって制御され得る。当業者は、これらの要因は例示的であり、また、アプリケーションに割り当てられるＡＰＤ時間を制御するために、他の技術が代わりに採用され得ることを理解するであろう。例えば、アプリケーション７０２が終了するか、またはリングバッファ７０４がＡＰＤによって空にされる（すなわち、さらなるＡＰＤバウンドのコマンドが実行のためにキューに登録されていない）と、スケジューラは、直ちに実行するために次のアプリケーションをスケジューリングできる。

さらに、ＡＰＤマルチタスクを可能にするため、リングバッファ７０４内の全てのコマンドをサービスする前に、スケジューラは、コンテキストを別のアプリケーションに切り替えることができる（ステップ１０１４に続くステップ１００８）。これは、満了時（例えば、いくつかのクロック周期の後、またはある期間の「実測時間」が経過した後）に、コンテキストスイッチをトリガーするタイマーの使用を通じて処理できる。このタイマーは、随意に、アプリケーション７０２に割り当てられた値を通じて設定され、その計算プロセス制御ブロック７１０に格納され得る。また、計算プロセス制御ブロック７１０内の優先度値は、ステップ１０１２において、コンテキストスイッチの前に、リングバッファ７０４からサービスするコマンドの数をスケジューラが判断する際の助けとなり得る。

コンテキスト切替えが生じると、リングバッファ７０４からの現在のアプリケーションのＡＰＤバウンドコマンドの実行状態が、保存されるはずである。このことは、ＡＰＤが、コマンドが依存し得る任意のレジスタ値を含む同じ実行状態を使用して、リングバッファ７０４からのコマンドの処理を継続することを許容する。図１１は、本発明の実施形態による、実行状態がコンテキストスイッチ内に保存されるステップを示すフロー図１１００である。

方法は、ステップ１１０２から始まり、ステップ１１０４に進むが、そこで、別のアプリケーションのために、コンテキストがスイッチアウト（ｃｏｎｔｅｘｔ−ｓｗｉｔｃｈｅｄ−ｏｕｔ）されるアプリケーション７０２のＡＰＤ状態（例えば、レジスタ値、次の命令など）が、アプリケーション７０２に対応するコンテキストスイッチブロック７１２に格納される。ステップ１１０６において、スケジューラは、スケジューリングする次のアプリケーション７０２を、計算プロセス制御ブロック７１０によって参照される、対応するリングバッファ７０４およびコンテキストスイッチブロック７１２と共に（計算プロセス制御ブロック７１０を介して）識別する。次いで、ステップ１１０８において、ＡＰＤは、次のアプリケーション７０２のためにコンテキストスイッチブロック７１２内に保存された状態を使用して、ＡＰＤの状態を復元する。方法は、その後、１１１０で終了する。このことは、コンテキストがスイッチイン（ｃｏｎｔｅｘｔ−ｓｗｉｔｃｈｅｄ−ｉｎ）されているアプリケーション７０２が、ＡＰＤ実行を中止した位置で継続できるようにする。

前述のアプリケーションは、ハードウェアバウンドのスケジューリングを説明するが、本発明のさらなる実施形態に従って、ハードウェアバウンドおよびソフトウェアバウンドのスケジューリングを結合することも可能である。この技法は、ソフトウェアベースのスケジューラが、（限定されない例として、ヒューリスティックの使用を通じて）どのアプリケーションに次のＡＰＤ時間を許可すべきかを予測し、ＡＰＤによって次にスケジューリングされるアプリケーションを登録できるようにする。

図１２は、ソフトウェアベースのスケジューラがハードウェアベースのスケジューラに指示を出すことができるステップを示すフロー図１２００である。方法は、ステップ１２０２から始まり、ソフトウェアベースのスケジューラが、スケジューリングされるべき次のアプリケーション７０２のいくつかのヒューリスティックな判断を実行するステップ１２０４に進む。次いで、ステップ１２０６において、ソフトウェアベースのスケジューラは、アプリケーション７０２の実行リストエントリ７１０をハードウェアスケジューラに登録し、アプリケーション７０２がそれによって実行をスケジューリングされるようにする。方法は、ステップ１２１０で終了する。このことは、実行する全てのアプリケーションコンテキストの自動的なスケジューリングとは対照的に、代わりにソフトウェアベースのコンポーネントによる細粒度の制御を可能にする。

本発明の追加の実施形態によれば、かかる変更が、ＡＰＤによって既知の実行リストエントリ７１０のセットに行われると、ハードウェアのスケジューラがスケジューリング順を再評価できるようにするために、実行リストエントリ７１０のセット全体が再サブミットされる。この挙動をトリガーする変更には、別の実行リストエントリの追加、実行リストエントリの削除または１つ以上の実行リストエントリの編集（例えば、アプリケーションコンテキストの優先度を変更するため）を含む。

本発明の様々な態様は、ソフトウェア、ファームウェア、ハードウェアまたはそれらの組合せによって実施され得る。例えば、図３のフロー図３００、図８の８００、図９の９００、図１０の１０００、図１１の１１００および図１２の１２００によって例示される方法は、図１の統合化されたコンピューティングシステム１００で実施できる。本発明の様々な実施形態は、この統合化されたコンピューティングシステム例１００の観点から説明される。当業者には、他のコンピュータシステムおよび／またはコンピュータアーキテクチャを用いて、本発明をどのように実施するかは明らかであろう。

本文書では、「コンピュータプログラム媒体」および「コンピュータ使用可能媒体」という用語は、一般に、取外し可能記憶装置またはハードディスクドライブなどの媒体を参照するために使用される。コンピュータプログラム媒体およびコンピュータ使用可能媒体は、システムメモリ１０６およびグラフィックスメモリ１３０などのメモリも参照し得、それらは半導体メモリ（例えば、ＤＲＡＭなど）であり得る。コンピュータプログラム製品は、統合化されたコンピューティングシステム１００にソフトウェアを提供するための手段である。

本発明は、任意のコンピュータ使用可能媒体に格納されたソフトウェアを含むコンピュータプログラム製品も対象とする。かかるソフトウェアは、１つ以上のデータ処理装置で実行される場合、データ処理装置を本明細書に記載するとおりに動作させるか、または前述したように、本明細書に記載する本発明の実施形態を実行するために、コンピューティング装置（例えば、ＡＳＩＣまたはプロセッサ）の合成および／もしくは製造を可能にする。本発明の実施形態は、現在または将来において既知の任意のコンピュータ使用可能媒体またはコンピュータ可読媒体を採用する。コンピュータ使用可能媒体の例には、主記憶装置（例えば、任意のタイプのランダムアクセスメモリ）、二次記憶装置（例えば、ハードドライブ、フロッピィディスク、ＣＤ ＲＯＭ、ＺＩＰディスク、テープ、磁気記憶装置、光学記憶装置、ＭＥＭＳ、ナノテクノロジ記憶装置など）および通信媒体（例えば、有線および無線通信ネットワーク、ローカルエリアネットワーク、ワイドエリアネットワーク、イントラネットなど）が含まれるが、それらに限定されない。

（結論）
本発明の様々な実施形態が上述されているが、それらは例としてのみ提示されており、制限ではないことが理解されるべきである。当業者には、形式および詳細における様々な変更が、添付の特許請求項で定義されている本発明の精神および範囲から逸脱することなく、行われ得ることが理解されるであろう。本発明がこれらの例に制限されないことが理解されるべきである。本発明は、本明細書に記載するとおりに動作する任意の要素に対して適用可能である。さらに、本発明の範囲は、上述の代表的な実施形態のいずれよっても制限されるものではなく、以下の特許請求項およびそれらの均等物にしたがって定められるべきである。

Claims (22)

1. アクセラレーテッド処理デバイスの作業待ち行列を、カーネルモードドライバを介してアプリケーションに割り当てるステップと、
   前記アクセラレーテッド処理デバイスによる直接的なアクセスを、前記作業待ち行列に提供するステップと、
   前記作業待ち行列からのコマンドを、前記アクセラレーテッド処理デバイスが処理するステップと、
   を含む方法。
2. コマンドを、前記アプリケーションから前記作業待ち行列に転送するステップと、
   前記コマンドを、前記作業待ち行列から前記アクセラレーテッド処理デバイスにディスパッチするステップと、をさらに含む、
   請求項１に記載の方法。
3. 前記コマンドを、コマンドバッファに格納するステップをさらに含み、
   前記コマンドを、前記アプリケーションから前記作業待ち行列に転送するステップは、前記コマンドを、前記コマンドバッファから前記作業待ち行列に転送するステップを含む、
   請求項２に記載の方法。
4. アクセラレーテッド処理デバイスにアクセス可能なメモリリソースを、前記アプリケーションに割り当てるステップをさらに含む、
   請求項１に記載の方法。
5. 前記アクセラレーテッド処理デバイスの作業待ち行列を前記アプリケーションに割り当てるステップは、計算コマンドリングバッファを前記アプリケーションに割り当てるステップを含む、
   請求項１に記載の方法。
6. 前記アプリケーションに対応する計算プロセス制御ブロックを割り当てるステップをさらに含み、
   前記計算プロセス制御ブロックは、前記アプリケーションに対する前記アクセラレーテッド処理デバイスの作業待ち行列の位置を特定する情報を格納する、
   請求項１に記載の方法。
7. 前記計算プロセス制御ブロックを割り当てるステップは、前記アクセラレーテッド処理デバイスが、前記計算処理制御ブロックからの前記位置情報に基づいて前記作業待ち行列にアクセスし、コマンドを読み出すステップを含む、
   請求項６に記載の方法。
8. 前記計算プロセス制御ブロックおよび１つ以上の追加的な計算プロセス制御ブロックへの参照を含む計算プロセスリストを割り当てるステップをさらに含む、
   請求項６に記載の方法。
9. 命令が記録されているコンピュータ使用可能媒体であって、
   前記命令は、コンピューティング装置によって実行される場合に、前記コンピューティング装置に、
   アクセラレーテッド処理デバイスの作業待ち行列を、カーネルモードドライバを介してアプリケーションに割り当てることと、
   前記アクセラレーテッド処理デバイスによる直接的なアクセスを、前記作業待ち行列に提供することと、
   前記作業待ち行列からのコマンドを、前記アクセラレーテッド処理デバイスが処理するステップであって、前記コマンドは、前記コマンドが送られたときに存在しないリソースを参照することが許可されるステップと、
   を含む方法を実行させる、
   コンピュータ使用可能媒体。
10. コマンドを、前記アプリケーションから前記作業待ち行列に転送することと、
    前記コマンドを、前記作業待ち行列から前記アクセラレーテッド処理デバイスにディスパッチすることと、をさらに含む、
    請求項９に記載のコンピュータ使用可能媒体。
11. 命令を格納するコンピュータ可読媒体であって、
    前記命令の実行は、グラフィックスプロセッサユニット、グラフィックスプロセッサまたはグラフィックス処理コアを含むアクセラレーテッド処理デバイスにて作業項目を処理することにより、
    前記アクセラレーテッド処理デバイスの作業待ち行列を、カーネルモードドライバを介してアプリケーションに割り当てることと、
    前記アクセラレーテッド処理デバイスによる直接的なアクセスを、前記作業待ち行列に提供することと、
    前記作業待ち行列からのコマンドを、前記アクセラレーテッド処理デバイスが処理することと、
    を含む方法を実行するように適応されている、
    コンピュータ可読媒体。
12. 前記コマンドは、前記コマンドが送られたときに存在しないリソースを参照することが許可される、
    請求項１１に記載のコンピュータ使用可能媒体。
13. コマンドを、前記アプリケーションから前記作業待ち行列に転送することと、
    前記コマンドを、前記作業待ち行列から前記アクセラレーテッド処理デバイスにディスパッチすることと、をさらに含む、
    請求項１１に記載のコンピュータ使用可能媒体。
14. アクセラレーテッド処理デバイスにアクセス可能なメモリリソースを、前記アプリケーションに割り当てることをさらに含む、
    請求項１１に記載のコンピュータ使用可能媒体。
15. メモリと、
    アクセラレーテッド処理デバイスの作業待ち行列を、カーネルモードドライバを介してアプリケーションに割り当てるように構成されたプロセッサと、
    前記作業待ち行列からのコマンドを処理するように構成されたアクセラレーテッド処理デバイスであって、前記コマンドは、前記コマンドが送られたときに存在しないリソースを参照することが許可されており、前記オペレーティングシステムは、前記アクセラレーテッド処理デバイスによる直接的なアクセスを、前記作業待ち行列に提供するように構成されている、アクセラレーテッド処理デバイスと、
    を備えるシステム。
16. 前記オペレーティングシステムは、コマンドを、前記アプリケーションから前記作業待ち行列に転送し、前記コマンドを、前記作業待ち行列から前記アクセラレーテッド処理デバイスにディスパッチするようにさらに構成されている、
    請求項１５に記載のシステム。
17. 前記オペレーティングシステムは、前記コマンドをコマンドバッファに格納するようさらに構成されており、
    前記コマンドを、前記アプリケーションから前記作業待ち行列に転送することは、前記コマンドを、前記コマンドバッファから前記作業待ち行列に転送することを含む、
    請求項１６に記載のシステム。
18. 前記オペレーティングシステムは、アクセラレーテッド処理デバイスにアクセス可能なメモリリソースを、前記アプリケーションに割り当てるようにさらに構成されている、
    請求項１５に記載のシステム。
19. 前記アクセラレーテッド処理デバイスの作業待ち行列を、前記アプリケーションに割り当てることは、計算コマンドリングバッファを前記アプリケーションに割り当てることを含む、
    請求項１８に記載のシステム。
20. 前記オペレーティングシステムは、前記アプリケーションに対応する計算プロセス制御ブロックを割り当てるようにさらに構成されており、
    前記計算プロセス制御ブロックは、前記アプリケーションに対する前記アクセラレーテッド処理デバイス作業待ち行列の位置を特定する情報を格納する、
    請求項１５に記載のシステム。
21. 前記アクセラレーテッド処理デバイスは、前記計算プロセス制御ブロックからの前記位置情報に基づいて前記作業待ち行列にアクセスし、コマンドを読み出すようにさらに構成されている、
    請求項２０に記載のシステム。
22. 前記オペレーティングシステムは、前記計算プロセス制御ブロックおよび１つ以上の追加的な計算プロセス制御ブロックへの参照を含む計算プロセスリストを割り当てるようにさらに構成されている、
    請求項２０に記載のシステム。

Images