"アクセラレーテッド処理デバイスの作業待ち行列を、カーネルモードドライバを介してアプリケーションに割り当てるステップと、コマンドを、前記アプリケーションから前記作業待ち行列に転送するステップと、前記コマンドを、前記作業待ち行列から前記アクセラレーテッド処理デバイスにディスパッチするステップと、を含む方法。前記コマンドを、コマンドバッファに格納するステップをさらに含み、前記コマンドを前記アプリケーションから前記作業待ち行列に転送するステップは、前記コマンドを、前記コマンドバッファから前記作業待ち行列に転送するステップを含む、請求項1に記載の方法。アクセラレーテッド処理デバイスにアクセス可能なメモリリソースを、前記アプリケーションに割り当てるステップをさらに含む、請求項1に記載の方法。前記アクセラレーテッド処理デバイスの作業待ち行列を、前記アプリケーションに割り当てるステップは、計算コマンドリングバッファを、前記アプリケーションに割り当てるステップを含む、請求項1に記載の方法。前記アプリケーションに対応する計算プロセス制御ブロックを割り当てるステップであって、前記計算プロセス制御ブロックは、前記アプリケーションの前記アクセラレーテッド処理デバイスの作業待ち行列の位置を識別する情報を格納するステップをさらに含む、請求項1に記載の方法。前記コマンドを、前記作業待ち行列から前記アクセラレーテッド処理デバイスにディスパッチするステップは、前記アクセラレーテッド処理デバイスが、前記計算プロセス制御ブロックからの前記位置情報に基づいて前記作業待ち行列にアクセスし、コマンドを読み出すステップを含む、請求項5に記載の方法。前記計算プロセス制御ブロックおよび1つ以上の追加的な計算プロセス制御ブロックへの参照を含む計算プロセスリストを割り当てるステップをさらに含む、請求項5に記載の方法。命令が記録されているコンピュータ使用可能媒体であって、前記命令は、コンピューティング装置によって実行される場合に、前記コンピューティング装置に、アクセラレーテッド処理デバイスの作業待ち行列を、カーネルモードドライバを介してカーネルモードドライバを介してアプリケーションに割り当てることと、コマンドを、前記アプリケーションから前記作業待ち行列に転送することと、前記コマンドを、前記作業待ち行列から前記アクセラレーテッド処理デバイスにディスパッチすることと、を含む方法を実行させる、コンピュータ使用可能媒体。前記コマンドを、コマンドバッファに格納することをさらに含み、前記コマンドを、前記アプリケーションから前記作業待ち行列に転送することは、前記コマンドを、前記コマンドバッファから前記作業待ち行列に転送することを含む、請求項8に記載のコンピュータ使用可能媒体。アクセラレーテッド処理デバイスにアクセス可能なメモリリソースを、前記アプリケーションに割り当てることをさらに含む、請求項8に記載のコンピュータ使用可能媒体。前記アクセラレーテッド処理デバイスの作業待ち行列を、前記アプリケーションに割り当てることは、計算コマンドリングバッファを、前記アプリケーションに割り当てることを含む、請求項8に記載のコンピュータ使用可能媒体。前記アプリケーションに対応する計算プロセス制御ブロックを割り当てることであって、前記計算プロセス制御ブロックは、前記アプリケーションの前記アクセラレーテッド処理デバイスの作業待ち行列の位置を識別する情報を格納することを含む、請求項8に記載のコンピュータ使用可能媒体。前記コマンドを、前記作業待ち行列から前記アクセラレーテッド処理デバイスにディスパッチすることは、前記アクセラレーテッド処理デバイスが、前記計算プロセス制御ブロックからの前記位置情報に基づいて前記作業待ち行列にアクセスし、コマンドを読み出すことを含む、請求項12に記載のコンピュータ使用可能媒体。前記計算プロセス制御ブロックおよび1つ以上の追加的な計算プロセス制御ブロックへの参照を含む計算プロセスリストを割り当てることをさらに含む、請求項12に記載のコンピュータ使用可能媒体。メモリと、アクセラレーテッド処理デバイスの作業待ち行列を、カーネルモードドライバを介してアプリケーションに割り当て、コマンドを、前記アプリケーションから前記作業待ち行列に転送し、および、前記コマンドを、前記作業待ち行列から前記アクセラレーテッド処理デバイスにディスパッチするように構成されたプロセッサと、を備える、システム。前記プロセッサは、前記コマンドを、コマンドバッファに格納するように構成されており、前記コマンドを、前記アプリケーションから前記作業待ち行列に転送することは、前記コマンドを、前記コマンドバッファから前記作業待ち行列に転送することを含む、請求項15に記載のシステム。前記プロセッサは、アクセラレーテッド処理デバイスにアクセス可能なメモリリソースを、前記アプリケーションに割り当てるように構成されている、請求項15に記載のシステム。前記アクセラレーテッド処理デバイスの作業待ち行列を、前記アプリケーションに割り当てることは、計算コマンドリングバッファを、前記アプリケーションに割り当てることを含む、請求項15に記載のシステム。前記プロセッサは、前記アプリケーションに対応する計算プロセス制御ブロックを割り当てるように構成されており、前記計算プロセス制御ブロックは、前記アプリケーションの前記アクセラレーテッド処理デバイスの作業待ち行列の位置を識別する情報を格納する、請求項15に記載のシステム。前記コマンドを、記作業待ち行列から前記アクセラレーテッド処理デバイスにディスパッチすることは、前記アクセラレーテッド処理デバイスが、前記計算プロセス制御ブロックからの前記位置情報に基づいて前記作業待ち行列にアクセスし、コマンドを読み出すことを含む、請求項19に記載のシステム。前記プロセッサは、前記計算プロセス制御ブロックおよび1つ以上の追加的な計算プロセス制御ブロックへの参照を含む計算プロセスリストを割り当てるように構成されている、請求項19に記載のシステム。従って、必要なことは、GPU計算リソースへのアクセス可能性に対する改善されたサポートである。GPUと、アクセラレーテッドプロセッシングユニットAPUと、GPUによる汎目的計算GPGPUとは、この分野において一般に用いられる用語であるが、アクセラレーテッド処理デバイスAPDは、より広い表現とみなされる。例えば、APDは、従来のCPU、従来のGPU、ソフトウェアおよび/またはこれらの組合せと比較して高速化された方法で行われる、グラフィックス処理タスク、データ並列タスク、またはネスト化されたデータ並列タスクの高速化に関連する機能および演算を実行する任意のハードウェアおよび/またはソフトウェアの協働的集合体を指す。本発明の様々な実施形態は、APD作業待ち行列を、カーネルモードドライバを介してアプリケーションに割り当てるための方法および装置を提供する。方法および装置は、コマンドを、アプリケーションから作業待ち行列に転送し、このコマンドを、作業待ち行列からAPDにディスパッチすることも含む。本発明の追加的な特徴および利点、ならびに本発明の様々な実施形態の構造および動作は、添付の図面を参照して以下で詳細に説明される。本発明は本明細書において説明される特定の実施形態に制限されないことに注意すべきである。係る実施形態は、例示目的のみのために本明細書において提示される。追加的実施形態は、本明細書に含まれる教示に基づいて当業者に明らかとなるであろう。添付の図面は、本明細書に組み込まれ本明細書の一部を構成するものであって、本発明の実施形態を例示し、説明とともに、本発明の原理を説明し、当業者が本発明を実施することを可能にするように、さらに機能する。以下の詳細な説明においては、1つの実施形態、ある実施形態、例示的実施形態またはその他を参照することは、本明細書において説明される実施形態が、特定の特徴、構造または特性を有することを示すが、すべての実施形態がその特定の特徴、構造または特性を必ずしも含むとは限らない。さらに、係る語句は、同一の実施形態を参照するとは限らない。さらに、特定の特徴、構造または特性が1つの実施形態に関連して説明されるとき、係る特長、構造または特性を他の実施形態との関連で実施することは、明示されているか否かによらず、当業者の知識の範囲内であることが提起される。本発明の実施形態という用語は、本発明の実施形態の全部が検討の対象である特徴、特長または操作モードを含むことを必ずしも要求しない。代替的な実施形態が本発明の範囲から逸脱することなく考案され、本発明の既知の構成要素は、本発明の関連する詳細を不明瞭化しないために、必ずしも詳細に説明されるとは限らず、または省略され得る。加えて、本明細書において用いられる用語は、特定の実施形態を説明することのみを目的とし、本発明を制限することを意図するものではない。例えば、本明細書において用いられる単数形の1つのおよびそのは、内容的に明らかに単数のみを指す場合を除き、複数形をも含むことを意図するものである。本明細書において用いられる場合、含む、備える、包含するおよび/または有するという用語は、述べられた特徴、整数、ステップ、操作、構成要素および/またはコンポーネントが存在することを指定するが、1つまたは複数の他の特徴、整数、ステップ、操作、構成要素、コンポーネントおよび/またはこれらの群の存在または追加を除外しない。図1Aは、2つのプロセッサ、すなわちCPU102およびAPD104を含む統合化されたコンピューティングシステム100の例示的な図である。CPU102は1つ以上のシングルコアまたはマルチコアCPUを含み得る。本発明の一実施形態において、システム100は、統合化されたプログラミング環境および実行環境を提供するために、CPU102およびAPD104を組み合わせた単一のシリコンダイまたはパッケージ上に形成される。この環境は、APD104が、いくつかのプログラミングタスクに対して、CPU102と同程度に流動的に用いられることを可能にする。しかし、CPU102およびAPD104が単一のシリコンダイ上に形成されることは、本発明の絶対的な要件ではない。いくつかの実施形態において、CPU102およびAPD104は別個に形成され、同一の基板または異なる基板上に搭載されることが可能である。1つの例において、システム100は、メモリ106、オペレーティングシステム108および通信インフラストラクチャ109を含む。オペレーティングシステム108および通信インフラストラクチャ109は、以下でより詳細に説明される。システム100は、カーネルモードドライバKMD:kernelmodedriver110と、ソフトウェアスケジューラSWS:softwarescheduler112と、例えば入出力メモリ管理ユニットIOMMU:input/outputmemorymanagementunit等のメモリ管理ユニット116とを含む。システム100の構成品は、ハードウェア、ファームウェア、ソフトウェアまたはこれらの任意の組合せとして実装され得る。当業者は、システム100が図1Aに示される実施形態において示されるものに加えて、またはこれらとは異なる、1つ以上のソフトウェアコンポーネント、ハードウェアコンポーネントおよびファームウェアコンポーネントを含み得ることを理解するであろう。1つの例において、KMD110等のドライバは、通常、ハードウェアが接続されたコンピュータバスまたは通信サブシステムを通してデバイスと通信する。呼び出しプログラムがドライバにおいてルーチンを呼び出すと、ドライバは、デバイスに対してコマンドを発行する。デバイスがドライバに対してデータを戻すと、ドライバは、元の呼び出しプログラムにおいてルーチンを呼び出し得る。1つの例において、ドライバは、ハードウェア依存的であり、オペレーティングシステム固有である。ドライバは、通常、任意の必要な非同期的時間依存性のハードウェアインターフェースに対して要求されるインタラプトハンドリングを提供する。デバイスドライバは、特に現代のマイクロソフトウィンドウズ登録商標プラットフォームにおいては、カーネルモードリング0またはユーザモードリング3において実行され得る。ドライバをユーザモードにおいて実行することの主要な利益は、安定性が改善されることである。なぜなら、不完全な形で書かれたユーザモードデバイスドライバは、カーネルメモリを上書きすることによってシステムをクラッシュさせることができないためである。一方、ユーザモード/カーネルモードの遷移は、通常、顕著な性能オーバーヘッドを与え、それにより、低レイテンシおよび高スループット要件のためにユーザモードドライバを阻害する。カーネルスペースは、システムコールの使用を通してのみ、ユーザモジュールからのアクセスが可能である。UNIX登録商標シェルまたは他のGUIベースのアプリケーションなどのエンドユーザプログラムは、ユーザスペースの一部である。これらのアプリケーションは、カーネルにサポートされた機能を通してハードウェアと相互作用する。CPU102は、制御プロセッサ、フィールドプログラマブルゲートアレイFPGA:fieldprogrammablegatearray、特定用途集積回路ASIC:applicationspecificintegratedcircuitまたはデジタルシグナルプロセッサDSP:digitalsignalprocessorのうち1つ以上を含み得る図示せず。CPU102は、例えば、コンピューティングシステム100の動作を制御する、オペレーティングシステム108、KMD110、SWS112およびアプリケーション111を含む制御ロジックを実行する。この例示的な実施形態において、CPU102は、1つの実施形態によれば、アプリケーション111の実行の起動および制御を、例えばそのアプリケーションに関連する処理をCPU102とAPD104等の他の処理リソースとの間に分散させることにより行う。APD104は、とりわけ、グラフィックス演算や、例えば特に並列処理に好適となり得る他の演算等の、選択された機能のためのコマンドおよびプログラムを実行する。一般に、APD104は、ピクセル処理、幾何学演算およびディスプレイに対する画像のレンダリング等のグラフィックスパイプライン処理を実行するために、しばしば用いられ得る。本発明の様々な実施形態において、APD104は、CPU102から受信したコマンドまたは命令に基づいて、計算処理演算例えば、ビデオ演算、物理シミュレーション、計算流体力学等のグラフィックスに関連しない演算も実行し得る。例えば、コマンドは、通常、命令セットアーキテクチャISA:instructionsetarchitectureにおいて定義されない特殊な命令であるとみなされ得る。コマンドは、例えばディスパッチプロセッサ、コマンドプロセッサまたはネットワークコントローラ等の特殊なプロセッサにより実行され得る。一方、命令は、例えばコンピュータアーキテクチャ内のプロセッサの単一の演算であるとみなされ得る。1つの例において、2セットのISAが用いられる場合には、いくつかの命令は、x86プログラムを実行するために用いられ、いくつかの命令は、APD計算ユニット上でカーネルを実行するために用いられる。例示的な実施形態において、CPU102は、選択されたコマンドをAPD104に伝達する。これらの選択されたコマンドは、並列実行に適したグラフィックスコマンドと、並列実行に適した他のコマンドとを含み得る。計算処理コマンドを含み得るこれらの選択されたコマンドは、実質的にCPU102から独立して実行され得る。APD104は、例えば1つ以上のSIMD処理コア等ではあるがこれに制限されない、自身の計算ユニット図示せずを含み得る。本明細書で参照されるSIMDは、パイプライン、すなわち、それぞれが自身のデータおよび共有プログラムカウンタを有する複数の処理エレメント上でカーネルが同時に実行されるプログラミングモデルである。全ての処理エレメントは、同等なセットの命令を実行する。プレディケーションを用いることにより、発行された各コマンドに対して、ワークアイテムを関与させることまたはさせないことが可能となる。1つの例において、各APD計算ユニット104は、1つ以上のスカラーおよび/またはベクトル浮動小数点演算ユニットおよび/または算術論理ユニットALU:arithmeticandlogicunitを含み得る。APD計算ユニットは、逆平方根ユニットおよびサイン/コサインユニット等の特殊用途処理ユニット図示せずも含み得る。1つの例において、APD計算ユニットは、本明細書においてシェーダコア122と総称される。1つ以上のSIMDが存在することにより、一般に、APD104は、グラフィックス処理において一般的なデータ並列タスク等のデータ並列タスクの実行に、理想的に好適なものとなる。ピクセル処理等のいくつかのグラフィックスパイプライン処理と、他の並列演算処理とは、同一のコマンドストリームまたは計算カーネルが、ストリームまたは入力データ要素の集合体上で実行されることを要求する。同一の計算カーネルのそれぞれのインスタンス化は、上記データ要素を並列に処理するために、シェーダコア122の複数の計算ユニット上で同時に実行され得る。本明細書で参照されるように、例えば計算カーネルは、プログラム上で宣言され、APD計算ユニット上で実行される命令を含む関数である。この関数は、カーネル、シェーダ、シェーダプログラムまたはプログラムとも称される。1つの例示的な実施形態において、各計算ユニット例えばSIMD処理コアは、入力されるデータを処理するために、特定ワークアイテムのそれぞれのインスタンス化を実行し得る。ワークアイテムは、コマンドによりデバイス上で呼び出されるカーネルの並列実行の集合体のうちの1つである。ワークアイテムは、計算ユニット上で実行されるワークグループの一部として、1つ以上の処理エレメントにより実行され得る。ワークアイテムは、自身のグローバルIDおよびローカルIDによって、集合体内の他の実行から区別される。1つの例において、ワークグループ内のSIMD上でともに同時に実行されるワークアイテムの一部は、ウェーブフロント136と称され得る。ウェーブフロントの幅は、計算ユニット例えば、SIMD処理コアのハードウェアの特性である。本明細書で参照されるワークグループは、単一の計算ユニット上で実行される関連するワークアイテムの集合体である。ワークグループ内のワークアイテムは、同一のカーネルを実行し、ローカルメモリおよびワークグループバリアを共有する。代表的な実施形態において、ワークグループからの全てのウェーブフロントは、同一のSIMD処理コア上で処理される。ウェーブフロントにわたる命令は1度に1つずつ発行され、全てのワークアイテムが同一の制御フローに従う場合には、各ワークアイテムは、同一のプログラムを実行する。ウェーブフロントは、ワープ、ベクトルまたはスレッドと称され得る。実行マスクおよびワークアイテムプレディケーションは、ウェーブフロント内の拡散的な制御フローを可能にするために用いられる。拡散的な制御フローでは、各個別のワークアイテムは、カーネルを通る一意的なコードパスを実際に取り得る。部分的に占められたウェーブフロントは、ワークアイテムの全セットがウェーブフロント開始時に必ずしも利用可能とは限らない場合に、処理され得る。例えば、シェーダコア122は、所定数のウェーブフロント136を同時に実行し得る。なお、各ウェーブフロント136は、複数のワークアイテムを含む。システム100において、APD104は、グラフィックスメモリ130等の自身のメモリを含むなお、メモリ130は、グラフィックス専用に制限されるとは限らない。グラフィックスメモリ130は、APD104における計算実行の間の使用のために、ローカルメモリを提供する。シェーダコア122内の個々の計算ユニット図示せずは、自身のローカルデータ記憶装置図示せずを有し得る。1つの実施形態において、APD104は、ローカルグラフィックスメモリ130へのアクセス、ならびにメモリ106へのアクセスを含む。他の実施形態において、APD104は、ダイナミックランダムアクセスメモリDRAM:dynamicrandomaccessmemory、または、APD104には直接的に接続されているがメモリ106からは分離している他のメモリ図示せずへのアクセスを含み得る。図示の例において、APD104は、1つまたはn個のコマンドプロセッサCP:commandprocessor124を含み得る。CP124は、APD104内の処理を制御する。CP124は、実行されるべきコマンドを、メモリ106内のコマンドバッファ125から取得し、APD104でのこれらのコマンドの実行を調整する。1つの例において、CPU102は、アプリケーション111に基づくコマンドを、適切なコマンドバッファ125に入力する。本明細書において参照されるように、アプリケーションは、CPU内またはAPD内の計算ユニット上で実行されるプログラム部分の組合せである。複数のコマンドバッファ125は、各プロセスがAPD104での実行のためにスケジュールされた状態で、保持され得る。CP124は、ハードウェア、ファームウェア、ソフトウェアまたはこれらの組合せにおいて実装され得る。1つの実施形態において、CP124は、スケジューリングロジックを含むロジックを実装するためのマイクロコードを有する縮小命令セットコンピュータRISC:reducedinstructionsetcomputerエンジンとして実装される。APD104は、1つまたはn個のディスパッチコントローラDC:dispatchcontroller126を含み得る。本願において、ディスパッチという用語は、1セットの計算ユニット上の1セットのワークグループに対するカーネルの実行のスタートを起動するために、コンテキスト状態を使用するディスパッチコントローラにより実行されるコマンドを指す。DC126は、シェーダコア122内でワークグループを起動するためのロジックを含む。いくつかの実施形態において、DC126は、CP124の一部として実装され得る。システム100は、APD104上で実行するためのプロセスを実行リスト150から選択するためのハードウェアスケジューラHWS:hardwarescheduler128を含む。HWS128は、ラウンドロビン方式、優先レベルを用いて、または他のスケジューリングポリシーに基づいて、プロセスを実行リスト150から選択し得る。優先レベルは、例えば、動的に決定され得る。HWS128は、例えば、新規のプロセスを追加することによって、あるいは既存のプロセスを実行リスト150から削除することによって、実行リスト150を管理する機能を含み得る。HWS128の実行リスト管理ロジックは、実行リストコントローラRLC:runlistcontrollerと称されることもある。本発明の様々な実施形態において、HWS128が、実行リスト150からプロセスの実行を開始すると、CP124は、対応するコマンドバッファ125からのコマンドの取得および実行を開始する。いくつかの事例において、CP124は、CPU102から受信したコマンドに対応する、APD104内で実行される1つ以上のコマンドを生成し得る。1つの実施形態において、CP124は、APD104リソースおよび/またはシステム100のリソースの利用が改善または最大化されるように、APD104におけるコマンドの優先化およびスケジューリングを、他のコンポーネントとともに実装する。APD104は、インタラプトジェネレータ146に対してアクセスを有するか、またはインタラプトジェネレータ146を含み得る。インタラプトジェネレータ146は、APD104がページフォールト等のインタラプトイベントに遭遇すると、APD104によってオペレーティングシステム108にインタラプトをかけるよう構成され得る。例えば、APD104は、IOMMU116内のインタラプト生成ロジックに依存して、上述のページフォールトインタラプトを生成し得る。APD104は、シェーダコア122内で現在実行中のプロセスを切り替えるためのプリエンプションおよびコンテキストスイッチロジック120を含み得る。コンテキストスイッチロジック120は、例えばプロセスを停止させ、その現在状態例えばシェーダコア122状態およびCP124状態を保存する機能を含む。本明細書において参照される状態という用語は、初期状態、中間状態および/または最終状態を含み得る。初期状態は、機械がプログラム順序にしたがって入力データセットを処理することによって、データの出力セットを生成する開始点である。例えば、処理を前進させるためにいくつかのポイントにおいて記憶される必要がある中間状態が存在する。この中間状態は、他のプロセスによってインタラプトがかけられた場合に、後に実行を継続することを可能にするために記憶される場合もある。出力データセットの一部として記録され得る最終状態も存在する。プリエンプションおよびコンテキストスイッチロジック120は、他のプロセスを、APD104にコンテキストスイッチするためのロジックを含み得る。他のプロセスをAPD104で実行するようにコンテキストスイッチするための機能は、APD104上で実行するために、例えばCP124およびDC126によってプロセスをインスタンス化することと、当該プロセスに対して以前に保存された状態を復元することと、当該プロセスの実行を開始することと、を含み得る。メモリ106は、DRAM図示せず等の非永続型メモリを含み得る。メモリ106は、例えば、アプリケーションまたは他の処理ロジックの部分を実行する間に、処理ロジック命令、定数および様々な変数を記憶し得る。例えば、1つの実施形態において、CPU102上で1つ以上の演算を実行するための制御ロジックの部分は、CPU102によって演算のそれぞれの部分が実行される間、メモリ106内に常駐し得る。実行中、個別のアプリケーション、オペレーティングシステム関数、処理ロジックコマンドおよびシステムソフトウェアは、メモリ106に常駐し得る。オペレーティングシステム108に対して必須である制御ロジックコマンドは、一般に、実行中にはメモリ106に常駐することとなるであろう。他のソフトウェアコマンド、例えばカーネルモードドライバ110およびソフトウェアスケジューラ112は、システム100の実行中にはメモリ106に常駐し得る。この例において、メモリ106は、コマンドをAPD104に送るために、CPU102によって用いられるコマンドバッファ125を含む。メモリ106は、プロセスリストおよびプロセス情報例えば、アクティブリスト152およびプロセス制御ブロック154を含み得る。これらのリストおよび情報は、スケジュール情報を、APD104および/または関連するスケジューリングハードウェアに伝えるために、CPU102上で実行されるスケジューリングソフトウェアによって使用される。メモリ106に対するアクセスは、メモリ106に接続されたメモリコントローラ140によって管理され得る。例えば、メモリ106に対する読み出しおよび書き込みを実行するための、CPU102または他のデバイスからの要求は、メモリコントローラ140によって管理される。システム100の他の態様に戻ると、IOMMU116は、マルチコンテキストメモリ管理ユニットである。本明細書で用いられるコンテキストという用語は、カーネルが実行される環境であって、同期およびメモリ管理が定義されるドメインであるとみなされる。コンテキストは、1セットのデバイスと、これらのデバイスに対してアクセス可能であるメモリと、対応するメモリ特性と、メモリオブジェクト上におけるカーネル単数または複数または演算の実行をスケジュールするために用いられる1つ以上のコマンドキューとを含む。図1Aにおいて示される例に戻ると、IOMMU116は、APD104を含むデバイスに対するメモリページアクセスに対して、仮想アドレスから物理アドレスへの変換を実行するためのロジックを含む。IOMMU116は、例えば、APD104等のデバイスによるページアクセスの結果としてページフォールトが生じる場合に、インタラプトを生成するためのロジックを含み得る。IOMMU116は、トランスレーションルックアサイドバッファTLB:translationlookasidebuffer118を含むか、あるいはTLB118に対するアクセスを有し得る。TLB118は、1つの例として、メモリ106内のデータ用にAPD104によりなされた要求に対して、論理すなわち仮想メモリアドレスから物理メモリアドレスへの変換を高速化するために、コンテントアドレサブルメモリCAM:contentaddressablememoryに実装され得る。示された例において、通信インフラストラクチャ109は、必要に応じてシステム100のコンポーネントを相互接続する。通信インフラストラクチャ109は、周辺構成要素相互接続PCIバス、拡張PCIPCI-Eバス、アドバンストマイクロコントローラバスアーキテクチャAMBAバス、アドバンストグラフィックスポートAGPまたは他の通信インフラストラクチャのうち1つ以上を含み得る図示せず。通信インフラストラクチャ109は、イーサネット登録商標若しくは同様のネットワークまたはアプリケーションの転送速度要求を満足する任意の好適な物理的通信インフラストラクチャを含み得る。通信インフラストラクチャ109は、コンピューティングシステム100のコンポーネントを含むコンポーネントを相互接続するための機能を含む。この例において、オペレーティングシステム108は、システム100のハードウェアコンポーネントを管理する機能と、共通サービスを提供するための機能とを含む。様々な実施形態において、オペレーティングシステム108は、CPU102上で実行し、共通サービスを提供する。これらの共通サービスは、例えば、CPU102内での実行のためにアプリケーションをスケジューリングすることと、フォールト管理と、インタラプトサービスと、他のアプリケーションの入力および出力を処理することと、を含む。いくつかの実施形態において、オペレーティングシステム108は、例えばインタラプトコントローラ148等のインタラプトコントローラによって生成されたインタラプトに基づいて、適切なインタラプトハンドリングルーチンを呼び出す。例えば、オペレーティングシステム108は、ページフォールトインタラプトを検出すると、関連するページをメモリ106にロードし始め、且つ、対応するページテーブルを更新するために、インタラプトハンドラを呼び出す。オペレーティングシステム108は、オペレーティングシステムにより管理されるカーネル機能を通して、ハードウェア部品に対するアクセスが仲介されることを確保することによって、システム100を保護する機能を含み得る。事実、オペレーティングシステム108は、アプリケーション111等のアプリケーションが、CPU102上でユーザスペースにおいて実行されることを確保する。オペレーティングシステム108は、アプリケーション111が、ハードウェアにアクセスするためにオペレーティングシステムにより提供されるカーネル機能および/または入出力機能を呼び出すことも確保する。例として、アプリケーション111は、CPU102上でも実行されるユーザ計算を実行するための様々なプログラムまたはコマンドを含む。CPU102は、選択されたコマンドを、APD104上で処理されるためにシームレスに送信し得る。1つの例において、KMD110は、CPU102、CPU102上で実行されるアプリケーションまたは他のロジックが、APD104の機能を呼び出し得るアプリケーションプログラミングインタフェースAPIを実装する。例えば、KMD110は、CPU102からのコマンドを、コマンドバッファ125にエンキューし得る。なお、APD104は、このコマンドバッファ125からコマンドを続けて取得することとなる。加えて、KMD110は、APD104上で実行されるプロセスのスケジューリングを、SWS112とともに実行する。SWS112は、例えば、APD上で実行されるプロセスの優先度リストを保持するためのロジックを含み得る。本発明の他の実施形態において、CPU102上で実行するアプリケーションは、コマンドをエンキューするときに、KMD110を完全にバイパスし得る。いくつかの実施形態において、SWS112は、APD104上で実行されるプロセスのアクティブリスト152を、メモリ106に保持する。SWS112は、アクティブリスト152におけるプロセスのうち、ハードウェアのHWS128により管理される一部を選択する。各プロセスをAPD104上で実行することに関する情報は、CPU102からプロセス制御ブロックPCB:processcontrolblock154を通して、APD104に伝えられる。アプリケーション、オペレーティングシステムおよびシステムソフトウェアのための処理ロジックは、マスクワーク/フォトマスクの生成を通して最終的に製造プロセスを構成することで、本明細書において説明される本発明の態様を具体化するハードウェア装置を生成することを可能にするための、例えば、C言語等のプログラム言語および/またはVerilog、RTL等のハードウェア記述言語もしくはネットリストにおいて指定されるコマンドを含み得る。当業者は、コンピューティングシステム100が、図1Aにおいて示されるコンポーネントよりも多数または少数のコンポーネントを含み得ることを、本明細書を読むことで理解するであろう。例えば、コンピューティングシステム100は、1つ以上の入力インターフェースと、不揮発性ストレージと、1つ以上の出力インターフェースと、ネットワークインターフェースと、1つ以上のディスプレイまたはディスプレイインターフェースと、を含み得る。図1Bは、図1Aにおいて示されるAPD104のより詳細な例示を示す実施形態である。図1Bにおいて、CP124は、CPパイプライン124a,124b,124cを含み得る。CP124は、図1Aにおいて示されるコマンドバッファ125から入力として提供されるコマンドリストを、処理するように構成され得る。図1Bの典型的な動作において、CP入力0124aは、コマンドをグラフィックスパイプライン162に駆動することを担当する。CP入力1および2124bおよび124cは、コマンドを計算パイプライン160に伝える。HWS128の動作を制御するためのコントローラ機構166も提供される。図1Bにおいて、グラフィックスパイプライン162は、本明細書において順序化パイプライン164と称される、1セットのブロックを含み得る。例えば、順序化パイプライン164は、頂点グループ変換器VGT:vertexgrouptranslator164aと、プリミティブアセンブラPA:primitiveassembler164bと、スキャンコンバータSC:scanconverter164cと、シェーダエクスポートレンダーバックユニットSX/RB:shader-export,render-backunit176とを含む。順序化パイプライン164内の各ブロックは、グラフィックスパイプライン162内の異なる段階のグラフィックス処理を表し得る。順序化パイプライン164は、固定機能ハードウェアパイプラインであり得る。本発明の精神および範囲に含まれ得る他の実装を用いることも可能である。わずかな量のデータが、入力としてグラフィックスパイプライン162に提供されるが、このデータは、グラフィックスパイプライン162からの出力として提供される回数分だけ増幅されることとなるであろう。グラフィックスパイプライン162は、CPパイプライン124aから受け取ったワークアイテムグループ内の範囲にわたってカウントするためのDC166も含む。DC166を通して提示された計算作業は、グラフィックスパイプライン162と準同期している。計算パイプライン160は、シェーダDC168,170を含む。DC168,170のそれぞれは、CPパイプライン124b,124cから受け取ったワークグループ内の計算範囲にわたってカウントするように構成されている。図1Bにおいて示されるDC166,168,170は、入力範囲を受け取り、入力範囲をワークグループに分割し、次いでこれらのワークグループをシェーダコア122に伝える。グラフィックスパイプライン162は、一般に固定機能パイプラインであるため、その状態を保存および復元することは困難であり、そのためグラフィックスパイプライン162は、コンテキストスイッチが困難である。したがって、ほとんどの場合、本明細書において論じられるコンテキストスイッチは、グラフィックス処理におけるコンテキストスイッチに関係しない。例外は、シェーダコア122におけるグラフィックス作業であり、これはコンテキストスイッチされ得る。グラフィックスパイプライン162内の作業の処理が完了した後に、完了した作業は、レンダーバックユニット176を通して処理される。レンダーバックユニット176は、デプス計算およびカラー計算を行い、次いでその最終結果をメモリ130に書き込む。シェーダコア122は、グラフィックスパイプライン162および計算パイプライン160により共有され得る。シェーダコア122は、ウェーブフロントを実行するように構成された一般的なプロセッサである。1つの例において、計算パイプライン160内の全ての作業は、シェーダコア122内で処理される。シェーダコア122は、プログラム可能なソフトウェアコードを実行し、例えば状態データ等の様々な形態のデータを含む。QoSにおける混乱は、全てのワークアイテムが、APDリソースにアクセスできない場合に生じる。本発明の実施形態は、2つ以上のタスクが、APD104内のリソースに対して効率的かつ同時に起動するのを容易にして、全てのワークアイテムが、様々なAPDリソースにアクセスできるようにする。一実施形態では、APD入力方式は、APDの作業負荷を管理することにより、全てのワークアイテムが、APDのリソースに対して並行してアクセスできるようにする。例えば、最大入出力速度に達している間にAPDの作業負荷が最高レベルに近づくと、このAPD入力方式は、他の方法では使用されない処理リソースが多くのシナリオで同時に利用できるようにすることを支援する。例えば、一連の入力ストリームは、APDへの同時並列入力として現れるように抽象化できる。例として、CP124の各々は、APD104内の他のリソースへの入力として送るための1つ以上のタスクを有することができ、各タスクは、複数のウェーブフロントを表すことができる。第1のタスクが入力として遅れられた後に、このタスクは、そのタスクの完了に必要な全てのAPDリソースを利用するために、ある期間にわたって増加するのが許可され得る。それだけで、この第1のタスクは、最大APD利用閾値に達し得ることもあれば、達し得ないこともある。しかし、他のタスクがキューに加えられ、APD104内で処理されるのを待機しているとき、APDリソースの割当ては、タスクの全てがAPD104を同時に使用できることを確実にするように管理でき、各々のタスクがAPDの最大利用の割合を達成する。複数のタスクによるAPD104の同時使用および各タスクの合計の利用割合は、所定の最大APD利用閾値が達成されることを確実にする。図2は、図1Bに示すAPD104のさらなる詳細を示すブロック図である。図2では、APD104は、シェーダコア122へのアクセスを調停するシェーダリソースアービタshaderresourcearbiter204を含む。図2では、シェーダリソースアービタ204は、シェーダコア122の外側にある。別の実施形態では、シェーダリソースアービタ204は、シェーダコア122内に存在し得る。さらなる実施形態では、シェーダリソースアービタ204は、グラフィックスパイプライン162内に含まれ得る。シェーダリソースアービタ204は、計算パイプライン160、グラフィックスパイプライン162またはシェーダコア122と通信するように構成され得る。シェーダリソースアービタ204は、ハードウェア、ソフトウェア、ファームウェアまたはそれらの任意の組合せを用いて、実装され得る。例えば、シェーダリソースアービタ204は、プログラム可能なハードウェアとして実装され得る。前述のように、計算パイプライン160は、図1Bに示すように、DC168,170を含み、DC168,170は、入力スレッドグループを受信する。スレッドグループは、所定数のスレッドを含むウェーブフロントに分けられる。各ウェーブフロントスレッドは、例えば頂点シェーダvertexshaderなどのシェーダプログラムを含み得る。シェーダプログラムは、通常、コンテキスト状態データのセットと関連する。シェーダプログラムは、シェーダコアプログラム実行のために、シェーダコア122に転送される。動作中、各シェーダコアプログラムは、いくつかの汎用レジスタGPR図示せずにアクセスするが、GPRは、プログラムを実行する前に、シェーダコア122に動的に割り当てられる。ウェーブフロントが処理される準備ができている場合、シェーダリソースアービタ204は、GPRおよびスレッド空間を割り当てる。シェーダコア122は、新しいウェーブフロントが実行のために準備ができていることを通知され、そのウェーブフロントについてシェーダコアプログラムを実行する。図1に示すように、APD104は、例えば1つ以上のSIMDなどの計算ユニットを含む。図2では、例えば、シェーダコア122は、特定のワークグループのそれぞれのインスタンス化を実行するための、あるいは着信データを処理するための、SIMD206A~206Nを含む。SIMD206A~206Nは、それぞれローカルデータストアLDS208A~208Nに結合されている。LDS208A~208Nは、それぞれのSIMDによってのみアクセス可能な専用privateのメモリ領域を提供する。LDS208A~208Nは、ワークグループに対して専用である。LDS208A~208Nは、シェーダプログラムのコンテキスト状態データを格納する。以下で説明するように、本発明の態様は、ソフトウェア、ハードウェア、ファームウェアおよび/または図に示す実体の多くの異なる実施形態で実施され得ることが当業者には明らかであろう。本発明を実施するために特殊化したハードウェア制御を備えたいかなる実際のソフトウェアコードも、本発明を制限しない。従って、本発明の操作上の挙動は、本明細書で提示するレベルの詳細を前提として、実施形態の修正および変形が可能であるという理解の下で説明されるであろう。さらに、当業者には明らかであるように、本発明の様々な実施形態のシミュレーション、合成および/または製造は、汎用プログラミング言語CまたはCなど、VerilogHDL、VHDL、AlteraHDLAHDLなどを含むハードウェア記述言語HDL、または他の利用可能なプログラミングツールおよび/もしくは概略図キャプチャツール回路キャプチャツールなどを含む、コンピュータ可読コード前述したようなの使用を通じて、部分的に達成され得る。このコンピュータ可読コードは、半導体、磁気ディスク、光ディスクCD-ROM、DVD-ROMなどを含む任意の既知のコンピュータ使用可能媒体内に、あるいは、コンピュータ使用可能例えば、可読伝達媒体搬送波、またはデジタル、光若しくはアナログベースの媒体を含む任意の他の媒体など内で具体化されたコンピュータデータ信号として、配置され得る。そのため、コードは、インターネットおよびイントラネットを含む通信ネットワークを経由して伝送され得る。前述したシステムおよび技術によって達成される機能および/または提供される構造は、プログラムコードで具体化されるコアAPDコアおよび/もしくはCPUコアまたは他の処理コアなど内に表され得ること、及び、集積回路の製造の一部としてハードウェアに変換され得ることを理解されたい。図3は、コマンドをAPDにサブミットするためにカーネルモードドライバに依存するデータフローモデル300を示す。このデータフローモデルでは、ユーザモードアプリケーション302がコマンドバッファ304を操作し、それに対してアプリケーション302が、APDコアによる実行のためのコマンドを書き込む。アプリケーション302が準備できると例えば、コマンドバッファが満杯であるため、アプリケーション302は、データを、コマンドバッファから、APDエンジンリングバッファ308へのアクセスを有するカーネルモードドライバ306へ転送する。カーネルモードドライバ306または他のカーネルモードソフトウェアは、コマンドバッファ304からコマンドを読み取り、それらをAPDエンジンリングバッファ308に書き込むことができる。データフローモデル300のアプローチは、コマンドのリングバッファ308への送信ごとに、ユーザモードとカーネルモードとの間で遷移する。図4は、図3のデータフローモデル300の概念を、例示的なWindows登録商標環境に適用する追加のデータフローモデル400を示すが、当業者は、データフローモデル400の他の動作環境への適用性を認識するであろう。データフローモデル400に示すように、例えばユーザモードアプリケーション302などのアプリケーション用のAPDコンテキストは、ステップ402において作成され、メモリは、カーネルモードドライバの機能性例えば、コマンドバッファ304の割当てを含むを用いてステップ404において割り当てられる。ユーザモードアプリケーション302は、ステップ406においてコマンドバッファ304を命令で充填し、コマンドバッファ304は、ステップ408においてWindows登録商標DisplayDriverModel例示的なWindows登録商標環境では、WDDMコンポーネントに転送される。ステップ410において、カーネルモードドライバは、アプリケーション302用のコンテキストをコンテキストキューに追加でき、コマンドバッファ304の処理の準備が整っていることを示す。カーネルモードソフトウェアは、次いで、ステップ414において、コマンドを、コマンドバッファ304からAPDエンジンリングバッファ308に送信することができる。このアプローチは、アプリケーションのAPD命令を、カーネルモードドライバ例えば、Windows登録商標環境におけるDXGKRNLを介して送るfunnel。このアプローチにはいくつかの欠点があり、主としてAPDの元の設計フォーカスから生じる。このアプローチでは、APDは、グラフィックスコンテキストの外部のアプリケーションからの一般的な処理命令を処理するように意図されていない。全ては、標準的なグラフィックスインタフェースを通じてパッケージ化される必要がある。コマンドをサブミットする際のユーザモードとカーネルモードとの間で必要な遷移は、コストがかかり、ハードウェア特権レベルの遷移を必要とする。さらに、単一のAPDエンジンリングバッファ308への書込みはロックを必要とし、それは、他のAPDバウンドアプリケーションをブロックすることになる。このレガシーアプローチが直面する追加の課題は、APDリングバッファに追加されている動作が、仮想メモリ空間への参照について検査される必要があることである。具体的には、APDは、APDメモリおよびピン留めされたシステムメモリpinnedsystemmemory上で動作することが許可されているだけである。そうでない場合、操作によって参照されるデータは、その参照されるデータをメインメモリにコピーし、それをピン留めすることなどにより、APDメモリおよびピン留めされたシステムメモリの何れかに取り込まれる必要がある。コマンドをAPDエンジンリングバッファ308にサブミットする前に、APDが、APDエンジンリングバッファ308に書き込みを行うコマンドによって参照されるメモリにアクセスできることを確実にするために、ステップ412が実行される。これは、仮想メモリへの全ての参照に対してコマンドバッファをトラバースすることと、これらの参照を、物理メモリアドレス参照を用いてパッチをあてることとを含む。物理メモリ参照が存在しない場合、仮想メモリによって参照されるデータは、APDで使用できるように、APDメモリのピン留めされたシステムメモリにページインされる必要がある。APDリングバッファに操作をポストする前に、全ての操作に対して参照されるメモリの可用性を確実にする必要性は、高価になり得る。パッチのチェックは、参照データがピン留めされたシステムメモリまたはAPDメモリに既に存在するか否かに関わらず、全ての操作で実行される必要がある。結果として、APDリングバッファへのコマンドのサブミットは、著しいオーバーヘッドを伴う。図3および図4に示すデータフローモデルに関連する性能問題を克服または縮小するために、APDを第1級オブジェクトfirst-classcitizenとして扱うことのできる機能を組み込むことが有益である。言い換えれば、CPUと同等なまたは同等に近いコンピューティングリソースとして扱われることである。APDおよびAPDがアクセス可能なメモリ空間を、CPUと同様の方法で処理可能にするという概念は、いくつかの異なる方法で達成できる。しかし、様々な実施形態では例えば、オペレーティングシステムからの完全なサポートおよびネイティブのハードウェアサポートを受けて、アプリケーションの初期化を超えてカーネルモード遷移を回避することが可能である。図5は、本発明の実施形態による、システムスタック500の例示的なコンポーネントを示す。各ユーザモードアプリケーションは、ランタイム502を含み、アプリケーションとのリソースの確立および接続を可能にする。DXGKRNL504MicrosoftWindows登録商標DirectXグラフィックスカーネルサブシステムであり、APDに対するレガシーのグラフィックス指向カーネルモードドライバインタフェースを代表するを通じてコマンドをチャネリングする代わりに、前述した例によって、システムスタック500は、アプリケーションのためにメモリおよびコマンドキューの割当てを可能にするIOMMUv2ドライバ506を導入する。システムスタック500は、APDスケジューラ508aおよびCPUスケジューラ508bをさらに含む。CPUスケジューラ508bは、CPUバウンド作業をスケジューリングするための既存のシステム内に存在する従来型のスケジューラに類似しているが、APDスケジューラ508aは、APDバウンド作業のスケジューリングを処理する。APDスケジューラ508aの動作は、以下でさらに詳細に説明される。システムスタック500は、APDメモリ管理コンポーネント510aおよびCPUメモリ管理コンポーネント510bを追加として含む。CPUメモリ管理コンポーネント510bは、メモリをCPUバウンドアプリケーションに割り当てるための既存のオペレーティングシステム内に存在する従来型のメモリマネージャに類似しているが、APDメモリ管理コンポーネント510aは、APDバウンドコマンドを有するアプリケーションに対するメモリオブジェクトの割当てを処理する。図5は、オペレーティングシステムおよび基本的なハードウェアから協働が得られる例示的な実施形態を示しているが、当業者は、図3および図4のデータフローモデルに関連する性能問題を回避するために、他の機構が採用され得ることを理解するであろう。図6は、本発明の実施形態による、例示的なデータフローモデル600を示す。データフローモデル600は、MicrosoftWindows登録商標オペレーティングシステムのコンポーネントを参照するが、当業者は、データフローモデル600によって示される概念が、他のオペレーティングシステムを含むがそれらに限定されず、他のシステムに提供できることを理解するであろう。図5のIOMMUv2ドライバ506または他のカーネルモードドライバもしくはカーネルモードソフトウェアコンポーネントによって、ユーザモードアプリケーションは、ステップ602において、自身のユーザモードアクセス可能な作業待ち行列例えば、リングバッファを作成できる。限定されない例として、初期化中、ユーザモードアプリケーションは、作業待ち行列を割り当てるために、ランタイム502内の関数を呼び出す。この作業待ち行列は、限定されない例として、リングバッファまたは他のFIFOキューであり得るが、当業者は、コマンドバッファリングのための他の技術が使用され得ることを理解するであろう。アプリケーションは、カーネルモードドライバ内のカーネルモード関数をさらに呼び出し、カーネルモード関数は、ステップ604において、APDによるアクセスのためにリングバッファを登録する。本発明のさらなる実施形態による、ステップ606において、同じカーネルモードドライバは、リソース割当て要求をアプリケーションから受け入れ、ステップ608において、APDメモリまたはピン留めされたシステムメモリなどのリソースを割り当てる。メモリは、仮想メモリアドレスを用いて割り当てられ得るが、それらは、初期化前の場合のように現在物理メモリ空間内にないデータに対応し得る。初期化後、データフローモデル600は、実行の間、ユーザモードアプリケーションの挙動を示す。アプリケーションの実行の間、アプリケーションは、ステップ610においてコマンドバッファを充填できる。コマンドバッファの内容は、ステップ612において、アプリケーションのリングバッファに転送され得、ステップ614において、そこから命令がAPDにディスパッチされる。当業者は、ステップ610におけるコマンドバッファなどのコマンドバッファの使用が随意であり、コマンドが、代わりとして、ステップ612において使用されるリングバッファに直接転送され得ることを理解するであろう。コマンドバッファは、限定されない例として、リングバッファへの書込みが高価な操作書込み操作が、図3および図4の例における統合化されたリングバッファをブロックする場合などであるような状況で採用され得る。しかし、各アプリケーションが、カーネルモードドライバによって割り当てられた自身のリングバッファを有する状況では、この操作は、伝統的にそれに関連した同じコストが掛からない可能性があり、従って、性能コストの削減がコマンドバッファの不使用によって実現できる。従って、本明細書でのコマンドバッファへの参照は、コマンドバッファ内に置かれているコマンドが、代わりにアプリケーションのリングバッファに直接転送されるという状況を企図する。例示する実施形態は、実行時、APDによって処理される命令を処理するために、いくつかのコンポーネントに依存する。図7は、本発明の実施形態による、実行時における例示的なアーキテクチャのシステム概要700を示す。前述したように、各アプリケーション702には、それぞれのリングバッファ704が割り当てられている。このリングバッファ704は、1つ以上のコマンドバッファ706に格納されているコマンドによって書き込まれ得る。しかし、前述したように、コマンドバッファ706の使用は随意であり、代わりに、コマンドがリングバッファ704に直接書き込まれ得る。さらに、カーネルモードドライバは、いくつかのカーネル空間メモリオブジェクトを割り当てて、保持する。これらのカーネル空間メモリオブジェクトは、計算プロセス制御ブロックおよび実行リストエントリ710を含み、対応するアプリケーション702に割り当てられている。計算プロセス制御ブロック710の未処理のインスタンスを参照するマスタ計算プロセスリスト708が、登録されているアプリケーションのリストを追跡するために使用される。当業者は、個々のアプリケーション702に関する情報を保持する他の方法が使用され得ることと、この特定の方法が制限ではなく、例として提供されていることとを理解するであろう。カーネル空間メモリオブジェクトは、コンテキストスイッチブロック712も含む。これらのメモリブロックは、対応するアプリケーションがマルチタスク環境においてスイッチアウトされる場合にはいつでも、APDの現在の状態すなわち、コンテキストを保存するために使用される。アプリケーションのコンテキスト切替えは、スケジューラの操作に関連して、以下でさらに説明される。前述したように、システム概要700で説明したアーキテクチャの有益性の1つは、作業をユーザモードアプリケーションからAPDに送信する際に、カーネルモード遷移を回避する能力である。アプリケーション702がカーネルモードドライバに登録される場合、アプリケーション702は、対応する計算プロセス制御ブロック710に割り当てられる。APDは、計算プロセス制御ブロック710にアクセスして、関連するプロセスコンテキストに関連した特権状態情報を取得するが、この情報は、アプリケーション702のリングバッファ704の位置を含む。結果として、APDは、コストのかかるカーネルモード遷移を必要とすることなく、リングバッファ704からのコマンドにアクセスできる。計算プロセス制御ブロック710は、スケジューリングの処理に有用な追加の情報を含み得る。例えば、対応するアプリケーション702に対する優先レベル例えば、低、中、高、リアルタイムが計算プロセス制御ブロック710内に保持され得、優先レベルは、以下でさらに詳述するように、APD処理時間をアプリケーション702に割り当てるために、スケジューラによって利用され得る。優先度情報は、タイマリセット値も含み得、次のスケジューリングウィンドウ中に処理するAPD処理時間例えば、クロック周期または個々の命令の数などを示す。計算プロセス制御ブロック710は、APDがアプリケーションコンテキストを切り替えるときに利用できる、対応するコンテキストスイッチブロック712への参照も含む。したがって、APDは、計算プロセス制御ブロック710を、APDがサービスする個々のアプリケーション702の表現として利用する。本発明の実施形態によれば、リングバッファ704は、APDによってアクセスされる際にメモリ内に常駐していることが保証され、ページアウトできない。カーネルモードドライバ計算インターフェースは、ユーザ空間常駐コマンドバッファを割り当てるために使用されるが、それは、APDハードウェアによって直接アクセス可能であり、計算作業負荷ディスパッチおよび完了プロセスが任意のカーネルモード遷移を迂回できるようにする。本発明の追加の実施形態によれば、IOMMUv2およびAPDハードウェアのサポートを受けて、ページフォールトがユーザ空間コマンドおよびデータバッファ706に対してサポートされるが、それは、これらのバッファがメモリピン留めのオーバーヘッドを回避できるようにする。図3および図4のデータフローモデルとは対照的に、カーネルモードソフトウェアが仮想メモリ参照に対してパッチを当てるために、ユーザモードアプリケーションによって送信されたコマンドをトラバースする必要があり、それによって、全ての参照が、ピン留めされたシステムメモリまたはAPDメモリに常駐することを保証する。APDは、任意のパッチが行われる前に、リングバッファ704に直接アクセスすることができる。それ故、APDは、様々な機構の1つによってページフォールトを識別し処理できる必要がある。例えば、仮想メモリを参照する命令がAPDによって処理される場合、仮想メモリアドレスが物理メモリアドレスに対応しているか否かに関して例えば、ページテーブルを使用して判断が行われる。対応していない場合、APDは、システムのCPUに対してページフォールトをトリガーし得、CPUが、データを、対応する仮想メモリアドレスから、ピン留めされたシステムメモリまたはAPDメモリに読み出すことができるようにする。APDの能力が許せば、APDは、ページフォールトでブロックしながら別のアプリケーションコンテキストに切り替えることができるか、または代わりに、ページフォールトがサービスされるのを待機しながら、停止stallできる。本発明のさらなる実施形態によれば、APDは、ページフォールトが必要か否かを判断するために、サービスする前に命令を調べることができ、必要であれば、CPUのページフォールト機構インタラプトをトリガーするであろう。ユーザモードアプリケーション702の観点から見れば、前述した機能は、システムのCPUと同様の方法で、APDとの直接のやりとりを可能にする。本発明のある実施形態のこの特性は、CPUと比較して、APDを第1級オブジェクトとして確立すると言われる。図8は、本発明の実施形態による、図7のアプリケーション702などのアプリケーションが初期化されるステップを示すフロー図である。方法は、ステップ802から始まり、アプリケーション自身が初期化されるステップ804まで進む。当業者は、ステップ804の初期化プロセスは、アプリケーションに固有の、いくつかの異なる機能を含み得ることを理解するであろう。限定されない例として、ステップ804におけるアプリケーションの初期化は、図7の計算プロセス制御ブロック710などの計算プロセス制御ブロックの作成を含む。当業者は、APDにアクセス可能なアプリケーションの表現が、それによって保持され更新され得る他の機構が使用され得ることを理解するであろう。ステップ806および808は、本発明の態様を利用するアプリケーションに対する初期化プロセスを示す。ステップ806において、リングバッファ図7のリングバッファ704または他の形式のコマンドバッファ例えば、FIFOキューなどがアプリケーションに割り当てられ、ステップ808において、メモリリソースが割り当てられる。方法は、その後、ステップ810で終了する。前述したように、ステップ806および808におけるリングバッファ704およびメモリリソースの割当ての各々は、カーネルモードドライバまたは他のカーネルモードソフトウェアとのやりとりを通して処理される例えば、図6のステップ604におけるように、アプリケーションがリングバッファ704を割り当てて、それをカーネルモードソフトウェアに登録する。リングバッファ704およびメモリリソースは、リソースを利用するために他のアプリケーションのブロックまたはカーネルモードへの遷移を必要とすることなく、アプリケーションおよびAPDにアクセス可能である。図9は、APDによって実行されるためのコマンドをアプリケーションが提供するステップを示すフロー図である。方法は、ステップ902から始まり、アプリケーションが、コマンドバッファおよび任意の参照データバッファを充填するステップ904に進む。図7のコマンドバッファ706などのコマンドバッファに格納されたコマンドは、図7のリングバッファ704などのリングバッファに転送される。本発明のさらなる実施形態によれば、ステップ906の代わりに、コマンドが、アプリケーションによって直接リングバッファ704内に置かれ得、これによって、別個のコマンドバッファの使用をスキップする。ステップ908において、リングバッファ704内のコマンドは、ディスパッチの準備ができている。方法は、ステップ910で終了する。前述したように、APDハードウェアは、リングバッファ704に格納されたコマンドに直接アクセスでき、例えばスケジューリングアルゴリズムによってコマンドの処理を開始するように指示される場合などのように必要に応じて、適切なアプリケーションのリングバッファ704からコマンドの処理を開始できる。図6のステップ604のように、リングバッファを各アプリケーションに割り当てることにより、スケジューリングを様々な異なる方法で処理することが可能である。特に、図3および図4に示すデータフローモデルでのスケジューリングは、データを、統合化されたAPD用のリングバッファにプッシュすることにより達成される。APDハードウェアは、操作がどのような順番で提示されても、リングバッファから操作をプルするであろう。リング内に置かれたデータの特定のパケットの完了を信号通知するために、統合化されたリングバッファ内の操作パケット内の最後の操作がタイムスタンプを増加させる技術が使用される。しかし、この操作は、待ち時間を追加し、ハードウェアインタラプトの実行によって取り込まれる非効率性を要求する。このアプローチはまた、操作パケット全体に対して完了が判断されるので、特定のタイムフレーム内でいくつの操作が処理されているのかを正確に判断する場合、解決策を欠いている。対照的に、本発明の例示的な実施形態では、スケジューラまたは他の機構が、次に実行する特定のアプリケーションコンテキスト図7の計算プロセス制御ブロック710によって識別されるアプリケーションなどを選択できるようにして、選択されたアプリケーション702のリングバッファ704から実行用のAPDに命令を提供する。また、アプリケーションのリングバッファ704内の作業パケットは、ユーザモード内で完全に自身の完了を信号通知することができ、低コストかつ低解像度の構成可能な解決策を完了の信号通知に提供する。当業者は、スケジューリングに対するいくつかのアプローチが、本明細書で開示する実施形態に適用でき、また、本明細書で説明するアプローチは、制限ではなく、例として提供されていることを理解するであろう。図10は、本発明の実施形態による、図5のAPDスケジューラ508aなどのスケジューラが、APDコマンドの処理をスケジューリングするステップを示すフロー図1000である。方法は、ステップ1002から始まり、計算プロセス制御ブロック710が、アプリケーションの初期化中などにアプリケーション702に割り当てられるステップ1004に進む。ステップ1006において、リングバッファ704またはコマンドをアプリケーション702からキューに登録するための他のデータ構造が、アプリケーション702に割り当てられる。ステップ1008において、スケジューラは、スケジューリングする次のアプリケーションを判断する。これは、限定されない例として、スケジューリングする次のアプリケーションに対応する計算プロセス制御ブロックまたは実行リスト710の選択を通じて、達成され得る。次の計算プロセス制御ブロック710の選択は、ラウンドロビンのスケジューリングなど、いくつかのスケジューリングアルゴリズムによって処理され得る。他のスケジューリングアルゴリズムの使用は、当業者には明らかであろう。本発明の追加の実施形態によれば、アプリケーション702は、実行のために選択されるのが望ましいということをAPDに通知することができる。これは、限定されない例として、コマンドがリングバッファ704に追加される場合にはいつでも、アプリケーションによるドアベルdoorbell信号の使用を通じて処理される。待機しているコマンドが、ドアベル信号の使用を通じてAPDに通知されていない場合、APDは、ステップ1008において、コマンドがそのリングバッファ704内に存在すること、またはAPDが別の方法で準備の整ったAPDコマンドを有していることを知っていることを信号通知している次の計算プロセス制御ブロック710にスキップできる。スケジューラが、実行する次のアプリケーション702を、対応する計算プロセス制御ブロック710によって識別すると、APDは、アプリケーションのリングバッファ704の位置を、計算プロセス制御ブロック710から取得する。APDは、次いで、ステップ1012において、リングバッファ704から直接コマンドをサービスできる。アプリケーション702は、CPUバウンドのコマンドを自由に別々に実行しながら、APDバウンドのコマンドのみをリングバッファ704内に配置することができる。これは、CPUおよびAPDが、他の完了を待機する必要なく従属関係の場合を除く、命令を異なる速度および頻度で実行できることを意味する。ステップ1012においてAPDがコマンドをサービスしている間、CPUは、自身のコマンドについて操作を継続できる。APDは、ステップ1012において、いくつかのコマンドのサービスを継続し、次いで、スケジューラがAPD時間に対して異なるアプリケーションをスケジューリングし得るステップ1014に進み、この場合、方法は、ステップ1008に再度進む。スケジューリングするアプリケーションがもう残っていなければ、方法は、ステップ1016で終了し、APDはアイドルのままである。ステップ1012において、後続のアプリケーションのスケジューリング前に、APDによってサービスされるコマンドの数は、いくつかの要因によって制御され得る。当業者は、これらの要因は例示的であり、また、アプリケーションに割り当てられるAPD時間を制御するために、他の技術が代わりに採用され得ることを理解するであろう。例えば、アプリケーション702が終了するか、またはリングバッファ704がAPDによって空にされるすなわち、さらなるAPDバウンドのコマンドが実行のためにキューに登録されていないと、スケジューラは、直ちに実行するために次のアプリケーションをスケジューリングできる。さらに、APDマルチタスクを可能にするため、リングバッファ704内の全てのコマンドをサービスする前に、スケジューラは、コンテキストを別のアプリケーションに切り替えることができるステップ1014に続くステップ1008。これは、満了時例えば、いくつかのクロック周期の後、またはある期間の実測時間が経過した後に、コンテキストスイッチをトリガーするタイマーの使用を通じて処理できる。このタイマーは、随意に、アプリケーション702に割り当てられた値を通じて設定され、その計算プロセス制御ブロック710に格納され得る。また、計算プロセス制御ブロック710内の優先度値は、ステップ1012において、コンテキストスイッチの前に、リングバッファ704からサービスするコマンドの数をスケジューラが判断する際の助けとなり得る。コンテキスト切替えが生じると、リングバッファ704からの現在のアプリケーションのAPDバウンドコマンドの実行状態が、保存されるはずである。このことは、APDが、コマンドが依存し得る任意のレジスタ値を含む同じ実行状態を使用して、リングバッファ704からのコマンドの処理を継続することを許容する。図11は、本発明の実施形態による、実行状態がコンテキストスイッチ内に保存されるステップを示すフロー図1100である。方法は、ステップ1102から始まり、ステップ1104に進むが、そこで、別のアプリケーションのために、コンテキストがスイッチアウトcontext-switched-outされるアプリケーション702のAPD状態例えば、レジスタ値、次の命令などが、アプリケーション702に対応するコンテキストスイッチブロック712に格納される。ステップ1106において、スケジューラは、スケジューリングする次のアプリケーション702を、計算プロセス制御ブロック710によって参照される、対応するリングバッファ704およびコンテキストスイッチブロック712と共に計算プロセス制御ブロック710を介して識別する。次いで、ステップ1108において、APDは、次のアプリケーション702のためにコンテキストスイッチブロック712内に保存された状態を使用して、APDの状態を復元する。方法は、その後、1110で終了する。このことは、コンテキストがスイッチインcontext-switched-inされているアプリケーション702が、APD実行を中止した位置で継続できるようにする。前述のアプリケーションは、ハードウェアバウンドのスケジューリングを説明するが、本発明のさらなる実施形態に従って、ハードウェアバウンドおよびソフトウェアバウンドのスケジューリングを結合することも可能である。この技法は、ソフトウェアベースのスケジューラが、限定されない例として、ヒューリスティックの使用を通じてどのアプリケーションに次のAPD時間を許可すべきかを予測し、APDによって次にスケジューリングされるアプリケーションを登録できるようにする。図12は、ソフトウェアベースのスケジューラがハードウェアベースのスケジューラに指示を出すことができるステップを示すフロー図1200である。方法は、ステップ1202から始まり、ソフトウェアベースのスケジューラが、スケジューリングされるべき次のアプリケーション702のいくつかのヒューリスティックな判断を実行するステップ1204に進む。次いで、ステップ1206において、ソフトウェアベースのスケジューラは、アプリケーション702の実行リストエントリ710をハードウェアスケジューラに登録し、アプリケーション702がそれによって実行をスケジューリングされるようにする。方法は、ステップ1210で終了する。このことは、実行する全てのアプリケーションコンテキストの自動的なスケジューリングとは対照的に、代わりにソフトウェアベースのコンポーネントによる細粒度の制御を可能にする。本発明の追加の実施形態によれば、かかる変更が、APDによって既知の実行リストエントリ710のセットに行われると、ハードウェアのスケジューラがスケジューリング順を再評価できるようにするために、実行リストエントリ710のセット全体が再サブミットされる。この挙動をトリガーする変更には、別の実行リストエントリの追加、実行リストエントリの削除または1つ以上の実行リストエントリの編集例えば、アプリケーションコンテキストの優先度を変更するためを含む。本発明の様々な態様は、ソフトウェア、ファームウェア、ハードウェアまたはそれらの組合せによって実施され得る。例えば、図3のフロー図300、図8の800、図9の900、図10の1000、図11の1100および図12の1200によって例示される方法は、図1の統合化されたコンピューティングシステム100で実施できる。本発明の様々な実施形態は、この統合化されたコンピューティングシステム例100の観点から説明される。当業者には、他のコンピュータシステムおよび/またはコンピュータアーキテクチャを用いて、本発明をどのように実施するかは明らかであろう。本文書では、コンピュータプログラム媒体およびコンピュータ使用可能媒体という用語は、一般に、取外し可能記憶装置またはハードディスクドライブなどの媒体を参照するために使用される。コンピュータプログラム媒体およびコンピュータ使用可能媒体は、システムメモリ106およびグラフィックスメモリ130などのメモリも参照し得、それらは半導体メモリ例えば、DRAMなどであり得る。コンピュータプログラム製品は、統合化されたコンピューティングシステム100にソフトウェアを提供するための手段である。本発明は、任意のコンピュータ使用可能媒体に格納されたソフトウェアを含むコンピュータプログラム製品も対象とする。かかるソフトウェアは、1つ以上のデータ処理装置で実行される場合、データ処理装置を本明細書に記載するとおりに動作させるか、または前述したように、本明細書に記載する本発明の実施形態を実行するために、コンピューティング装置例えば、ASICまたはプロセッサの合成および/もしくは製造を可能にする。本発明の実施形態は、現在または将来において既知の任意のコンピュータ使用可能媒体またはコンピュータ可読媒体を採用する。コンピュータ使用可能媒体の例には、主記憶装置例えば、任意のタイプのランダムアクセスメモリ、二次記憶装置例えば、ハードドライブ、フロッピィディスク、CDROM、ZIPディスク、テープ、磁気記憶装置、光学記憶装置、MEMS、ナノテクノロジ記憶装置などおよび通信媒体例えば、有線および無線通信ネットワーク、ローカルエリアネットワーク、ワイドエリアネットワーク、イントラネットなどが含まれるが、それらに限定されない。結論本発明の様々な実施形態が上述されているが、それらは例としてのみ提示されており、制限ではないことが理解されるべきである。当業者には、形式および詳細における様々な変更が、添付の特許請求項で定義されている本発明の精神および範囲から逸脱することなく、行われ得ることが理解されるであろう。本発明がこれらの例に制限されないことが理解されるべきである。本発明は、本明細書に記載するとおりに動作する任意の要素に対して適用可能である。さらに、本発明の範囲は、上述の代表的な実施形態のいずれよっても制限されるものではなく、以下の特許請求項およびそれらの均等物にしたがって定められるべきである。"