コプロセッサの性能を強化するシステムおよび方法
【課題】コプロセッサ長時間停止状態を最小にすると同時に他のスケジューリング効率を可能にすることによってコプロセッサの性能を強化するシステムおよび方法を提供すること。
【解決手段】コプロセッサ「長時間停止状態」を最小にする技法、およびより高い効率および威力のためにコプロセッサ内の処理の効果的なスケジューリングの技法。実行リストが設けられて、コプロセッサが、CPU介入を待たずにあるタスクから別のタスクに切り替えられるようになる。「サーフェスフォールト」と称する方法によって、コプロセッサが、タスクの途中の場所ではなく、大きいタスクの初めにフォールトを発生できるようになる。DMA制御命令すなわち「フェンス」、「トラップ」、および「コンテキスト切り替え許可/禁止」を処理ストリームに挿入して、コプロセッサに、コプロセッサの効率および威力を強化するタスクを実行させることができる。
【解決手段】コプロセッサ「長時間停止状態」を最小にする技法、およびより高い効率および威力のためにコプロセッサ内の処理の効果的なスケジューリングの技法。実行リストが設けられて、コプロセッサが、CPU介入を待たずにあるタスクから別のタスクに切り替えられるようになる。「サーフェスフォールト」と称する方法によって、コプロセッサが、タスクの途中の場所ではなく、大きいタスクの初めにフォールトを発生できるようになる。DMA制御命令すなわち「フェンス」、「トラップ」、および「コンテキスト切り替え許可/禁止」を処理ストリームに挿入して、コプロセッサに、コプロセッサの効率および威力を強化するタスクを実行させることができる。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、コンピュータプロセッサに関し、具体的には、コプロセッサの処理をスケジューリングするハードウェアおよびソフトウェアに関する。
【背景技術】
【0002】
多くのコンピュータシステムに、現在、コプロセッサ、たとえばグラフィックス処理ユニット(GPU)が含まれる。コプロセッサは、マイクロプロセッサなどの中央処理装置(CPU)と共にシステムのマザーボード上にある場合があり、別々のグラフィックスカードにある場合がある。コプロセッサは、その処理タスクを実行する際に、しばしば、補助メモリ、たとえばビデオメモリにアクセスする。現在のコプロセッサは、しばしば、ゲームおよびコンピュータ支援設計(CAD)などのアプリケーションをサポート(支援)するために3次元グラフィックス計算を実行するように最適化される。現在のコンピュータシステムおよびコプロセッサは、単一のグラフィック集中型アプリケーションを実行するときに適当に動作するが、複数のグラフィック集中型アプリケーションを実行するときに、問題が生じる場合がある。
【0003】
これの理由の1つが、通常のコプロセッサが、作業負荷を効率的にスケジューリングする能力を有しないことである。現在のコプロセッサによって、通常は、協力的マルチタスキングが実施されるが、これは、現在コプロセッサを制御しているアプリケーションが、他のアプリケーションに制御を与えなければならないタイプのマルチタスキングである。アプリケーションは、制御を放棄できない場合に、効果的にコプロセッサを「独占する」ことができる。単一のグラフィック集中型プログラムを実行するときには、これは大きな問題ではなかったが、コプロセッサを独占するという問題は、複数のアプリケーションがコプロセッサの使用を試みるときに深刻になる。
【0004】
動作の間で処理を配分するという問題は、複数の動作の洗練されたスケジューリングが必要になるCPUに関して対処されてきたが、コプロセッサのスケジューリングは、有効に対処されなかった。これは、コプロセッサが、一般に、現在のシステムにおいて、計算的に重く時間がかかる動作をCPUからそらし、CPUに他の機能のためのより多くの処理時間を与えるためのリソースとみなされるからである。そのような計算的に重い動作は、しばしば、グラフィックス動作であり、これは、かなりの処理能力を必要とすることがわかっている。
【0005】
コプロセッサのためにタスクがスケジューリングされる場合に生じる問題の1つが、コプロセッサ「長時間停止状態(starvation)」の可能性である。長時間停止状態は、コプロセッサがビジーでなく、したがって、コンピュータシステムの処理リソースが効果的に使用されていないときに発生する。
【発明の概要】
【発明が解決しようとする課題】
【0006】
上記および他の理由から、コプロセッサ長時間停止状態を最小にすると同時に他のスケジューリング効率を可能にすることによってコプロセッサの性能を強化するシステムおよび方法が望ましい。
【課題を解決するための手段】
【0007】
本発明は、コプロセッサ「長時間停止状態」を最小にし、より高い効率および威力のためにコプロセッサでの処理を効果的にスケジューリングする、連繋してまたは個別に使用することができるさまざまな技法を提供する。これに関して、実行リストが、中央処理装置(「CPU」)によって提供され、ページフォールとまたはタスク完了などの切り替えイベントの発生時に、コプロセッサが、CPU介入を待たずに、あるタスクから次のタスクへ即座に切り替えられるようになる。実行リストに加え、「サーフェスフォールト」と称する方法によって、コプロセッサが、サーフェスの途中のかなりの処理リソースが費やされた後の場所ではなく、サーフェスのレンダリングなどの大きいタスクの初めにフォールトを発生できるようになる。さらに、DMA制御命令すなわち「フェンス」、「トラップ」、および「コンテキスト切り替え許可/禁止」が設けられ、これらを処理ストリームに挿入して、コプロセッサに、コプロセッサの効率および威力を強化するタスクを実行させることができる。これらの命令は、下で詳細に説明するように、高水準同期化オブジェクトの構築にも使用することができる。最後に、ディスプレイのベース参照をある位置から別の位置に切り替え、これによってディスプレイサーフェス全体を変更することができる「フリップ」技法を説明する。これらの技法を有益に使用することができる状況を、本発明の上記および他の態様のさらなる説明に加えて、下で示す。
【図面の簡単な説明】
【0008】
【図1】コプロセッサに関する処理をスケジューリングする従来技術の手法を示す概念図である。
【図2】本発明によるコプロセッサスケジューリングの改善を示す例示的な図である。
【図3】概念的に図2に示されたスケジューリングの改善をもたらすのに用いられるコンピューティングコンポーネントを示すより詳細な図である。
【図4(A)】図3のステップを機能シーケンスに組み合わせるさまざまな非制限的な可能な方法を示す擬似コードアルゴリズムを示す図である。
【図4(B)】図3のステップを機能シーケンスに組み合わせるさまざまな非制限的な可能な方法を示す擬似コードアルゴリズムを示す図である。
【図5】スケジューラが、提供される情報を使用して、本発明による直接メモリアクセス(DMA)バッファ内で使用されるメモリリソースのタイムラインを定義する方法を示す図である。
【図6】本発明による準備ワーカースレッドと補助メモリマネージャの間の動きを示すアルゴリズムを示す図である。
【図7】本発明による、ページングバッファを準備し、ページングバッファに関するCPU前処理を処理するワーカースレッドを示すページングバッファの準備を示す例示的な図である。
【図8】本発明による、ページングバッファ内のフェンスの処理を含む、ワーカースレッド内で行うことができるイベントのチェーンを表すアルゴリズムを示す図である。
【図9】コプロセッサコンテキストの仮想アドレス空間を提供でき、さまざまなコプロセッサコンテキストの間で物理メモリを管理してコプロセッサコンテキストがメモリの公平な分け前を得られるようにすることができる、カーネルモードの補助メモリマネージャ「VidMm」を示す図である。
【図10】本発明による基本的なスケジューリングモデルを示す図である。
【図11】本発明による高度なスケジューリングモデルを示す図である。
【図12(A)】高度なスケジューリングモデルを実施することができるアクションのシーケンスを例示的に示す図である。
【図12(B)】高度なスケジューリングモデルを実施することができるアクションのシーケンスを例示的に示す図である。
【図13】可変長フラットページテーブルと共に本発明の使用を示す図である。
【図14】マルチレベルページテーブルと共に本発明の使用を示す図である。
【図15】サーフェスレベルフォールトをサポートする高度なスケジューリングモデルと共にスケジューラによって維持される例示的処理を示す図である。
【図16】本発明と共にサーフェスレベルフォールトが実施されるときに同時に処理することができる、それぞれがそれ自体のDMAリングを有する複数のコンテキストを示す図である。
【図17(A)】図16の構成要素と共に本発明の動作を示す、有用であることを示すことができるさまざまな追加の特徴を含む擬似コードアルゴリズムを示す図である。
【図17(B)】図16の構成要素と共に本発明の動作を示す、有用であることを示すことができるさまざまな追加の特徴を含む擬似コードアルゴリズムを示す図である。
【図17(C)】図16の構成要素と共に本発明の動作を示す、有用であることを示すことができるさまざまな追加の特徴を含む擬似コードアルゴリズムを示す図である。
【図18】本発明による実行リストの使用を概念的に著す図である。
【図19】本発明に従って使用されるスケジューラによって読取可能な指定されたシステムメモリ位置にコンテキスト切り替えヒストリを書き込むことができるハードウェアの動作を示す図である。
【図20】特権的コマンドをコプロセッサコンテキストリングに直接に挿入することによって特権的DMAチャネルをサポートするハードウェア手法を示す図である。
【図21】間接参照コマンドのビットがリングバッファに挿入される、コプロセッサでの限定DMAバッファ対特権的DMAバッファのサポートの手法を示す図である。
【図22】現在のディスプレイサーフェスに関してコプロセッサに照会する方法を示す図である。
【図23】即時フリップが本発明と共に使用されるときのフリップのキューイングに好ましい手法を示す図である。
【図24】2つまたはそれ以上のプロセッサがレンダリング中に有効な内容を使用できることを保証するためにリソースへのアクセスを同期化する例示的な技法を示す図である。
【図25】イベントヒストリバッファのさまざまな実施形態を示す図である。
【図26】補助メモリ内のどこにでもリダイレクトできるPCIアパーチャを使用する、コプロセッサコンテキストごとの仮想アドレス空間をサポートする好ましい方法を示す図である。
【発明を実施するための形態】
【0009】
本発明によって達成される複数の改善を、図1および図2の比較を介して概念的に示すことができる。図1に、コプロセッサに関するタスクスケジューリングの従来技術の手法を示す。さまざまなアプリケーション、たとえばアプリケーション1、アプリケーション2、およびアプリケーション3からアクセスできるバッファが設けられる。アプリケーションは、コプロセッサに関するタスクをバッファにロードすることができ、これらのタスクを、前にサブミットされたタスクが完了した後に、コプロセッサによって処理することができる。図からわかるように、この手法では、コプロセッサの潜在的な「独占(hogging)」が未解決のままである。図1では、アプリケーション1(APP.1)が、コプロセッサを独占している。APP.1は、コプロセッサが8つのタスクを扱うことを要求するが、他の2つのアプリケーションは、組み合わせても3つのタスクだけの操作を要求している。複数のアプリケーションがコプロセッサを必要とする、これに似た状況では、図2に示されたものなどのシステムによって、改善された機能性を提供することができる。
【0010】
図2に、本発明によるシステムおよび方法を示すが、これによって、各アプリケーション、たとえばアプリケーション1、アプリケーション2、およびアプリケーション3が、それ自体のバッファすなわち、図2の「第1バッファ」を維持することができる。これらのバッファ(下では「コマンドバッファ」と称する)は、スケジューリングプロセスにサブミットされ、スケジューリングプロセスは、さまざまなタスクをコプロセッサに渡すときを決定することができる。図2に示すように、スケジューリングプロセスは、この例では、タスクを「第2バッファ」に挿入している。単純にするために、図2の「第2バッファ」を、単一のバッファとして図示する。しかし、実際には、図2の「第2バッファ」の機能を実行するために、複数のバッファが必要になる場合がある。図2の第2バッファによって、アプリケーション1がコプロセッサリソースを独占できないように、コプロセッサに渡されるタスクが分割されている。スケジューリングプロセスは、アプリケーション1のコプロセッサの第1タスクを許可し、次にアプリケーション2、次にアプリケーション3、次に再びアプリケーション1を許可している。
【0011】
図2に概念的に示されたシステムおよび方法の実施形態は、図2に示されたものより複雑であるが、本明細書で開示される改善は、一般に、図2に示された基本概念をサポートする方向に向けられる。本発明の実施形態のより詳細な説明に移るが、参照を簡単にするために、下記の用語定義を示す。
【0012】
コマンドバッファ − ユーザモードドライバによって構築されるバッファ。このバッファは、レンダリングアプリケーションのコンテキスト内で割り当てられる通常のページング可能メモリとすることができる。
【0013】
DMAバッファ − 「直接メモリアクセス」バッファ。カーネルモードドライバによって構築されるバッファ。このバッファは、コマンドバッファの概念に基づくものとすることができる。一般に、このバッファは、カーネルページング可能メモリから割り当てられ、カーネルだけに可視である。これに関して、ページをコプロセッサが読み取れるようになる前に、ページをロックし、アパーチャを介してマッピングすることができる。
【0014】
ページングバッファ − カーネルモードドライバによって構築されるバッファ。このバッファは、特定のDMAバッファに必要なメモリリソースのページイン、追出し、および移動に使用することができる。ページングバッファは、対応するDMAバッファの前に即座に実行されるように構成することができる。
【0015】
リングバッファ − これは、コプロセッサコンテキスト固有のバッファである。DMAバッファへの指示を、このバッファに挿入することができる。これに関して、コプロセッサは、そのようなリングバッファから、実行されるコマンドをフェッチすることができる。リングバッファには、一般に、DMAバッファからのコマンド読取を開始し、DMAバッファが完全に処理されたならばリングバッファに戻るようにコプロセッサに指示するリダイレクション命令が含まれる。
【0016】
補助メモリ − 一般に、コプロセッサによる使用専用であり、物理システムメモリの一部である必要がないメモリ。これは、たとえば、グラフィックスカードにあるローカルビデオメモリとすることができる。これは、システムメモリアパーチャを介してマッピングされたメモリなど、他のコプロセッサ可読メモリとすることもできる。このメモリは、通常は、統合型またはUMA式のグラフィックスデバイスには存在しない。このメモリは、GART様ページテーブルベースのアパーチャを介してアクセスされない。
【0017】
システムメモリアパーチャ − これは、物理システムメモリのサブセットである。これは、GART様ページテーブルベースのアパーチャを介してコプロセッサに可視とすることができる。CPUは、システムメモリアパーチャと独立に物理システムメモリにアクセス可能とすることができる。概念的に類似する例が、アパーチャを介してアクセスされる、Accelerated Graphics Port(「AGP」)メモリ、Peripheral Component Interconnect(「PCI」)Expressメモリ、またはUnified Memory Architecture(「UMA」)メモリである。
【0018】
本発明のさまざまな実施形態のより詳細な図を、図3に示す。図3は、概念的に図2に示された機能を提供するために組み合わせることができるさまざまなソフトウェアオブジェクトおよびハードウェアオブジェクトの概略図である。図3に、下で説明する一連のシーケンシャルステップが示されている。これらのステップは、本発明を明瞭に説明し、使用可能にするためにシーケンシャルに提示されるものであって、本発明の実践に必要なシーケンスを表すものと解釈するべきではない。順序は、当技術分野で既知のまたは将来に開発される実践に従って変更することができる。下の説明は、図3のシステムおよび方法の概要から始まり、図3のいくつかの態様のより詳細な説明に進む。
【0019】
図3のステップ1は、アプリケーションプログラムインターフェース(「API」)へのアプリケーション呼出しを表す。アプリケーションは、ユーザにとってのソフトウェアを構成するファイルの任意の組とすることができる。APIは、通常は、オペレーティングシステムカーネルと通信するのにアプリケーションによって使用される言語およびメッセージフォーマットであるが、データベース管理システム(DBMS)などの他の制御プログラムとの通信のフォーマットまたは通信プロトコルも指す。本発明と共に使用される例示的なAPIの1つが、MICROSOFT(登録商標)社によって開発されたDirect3D Runtime APIである。
【0020】
ステップ2は、APIからユーザモードドライバへの呼出しを表す。ユーザモードドライバは、一般に、ソフトウェアまたはハードウェアのいずれかとすることができる周辺サブルーチンへソフトウェアシステム(しばしばオペレーティングシステムである)をリンクすることができるプログラムルーチン(またはハードウェア)である。ここで、ユーザモードドライバは、ステップ1からの元の呼出しに対応するAPIパラメータを含めることができる、APIからの呼出しを受け取る。ステップ3は、ユーザモードドライバによって生成されるレンダリングコマンドの、コマンドバッファへの累積を表す。バッファは、中間リポジトリとしての使用のために予約されたメモリの領域である。データエリアおよびプロセッサまたはコプロセッサなどの2つの位置の間での処理のための転送を待っている間に、データを一時的にバッファに保持することができる。ユーザモードドライバによって生成されるコマンドバッファ内容の詳細は、下でさらに説明するように、ハードウェア固有DMAバッファへの変換を容易にするように選択することができる。また、コマンドバッファを定義する際に、「テクスチャ」または「頂点バッファ」などのメモリリソースへの直接メモリ参照を省略することが有用である場合がある。その代わりに、独立ハードウェアベンダ(「IHV」)が、任意選択としてハンドルを含むコマンドバッファを定義することができ、カーネルインターフェースによって、メモリリソースが作成される時にコマンドバッファへのメモリ参照を提供することができる。
【0021】
ステップ4は、コマンドバッファのフラッシュを表す。「フラッシュ」は、単純に、累積されたレンダリングコマンドについてコマンドバッファを空にすることを指す。レンダリングコマンドは、図3に示されたコプロセッサカーネルに渡すために、図示のようにAPIに送り返すことができる。フラッシュは、コマンドバッファが満杯になり、着信レンダリングコマンドの空きが必要であるため、即時処理を必要とする高優先順位レンダリングコマンドがコマンドバッファに存在するため、などを含むがこれに制限されない理由で行うことができる。
【0022】
ステップ5は、APIによる、コプロセッサカーネルへの累積されたコマンドバッファのフラッシュを表す。カーネルは、一般に、オペレーティングシステムの中核部分すなわち、任意選択としてメモリ、ファイル、および周辺デバイスを管理し、アプリケーションを起動でき、システムリソースを割り当てることができる部分として知られる。コプロセッサカーネルを、プライマリシステムカーネル、または別々のコプロセッサ固有のカーネル、あるいは、たとえば、MICROSOFT(登録商標)DirectX Kernel(「DXG」)などの特定のタイプのカーネルを含む、任意のタイプのカーネルとすることができることを諒解されたい。
【0023】
ステップ6は、コプロセッサカーネルへのコマンドバッファのサブミットを表す。コプロセッサカーネルは、コマンドバッファをカーネルモードドライバに向けることができる。カーネルモードドライバは、一般に、ユーザモードドライバに関して上で説明したドライバとすることができるが、カーネルモードドライバは、名前が示すように、カーネルモードで動作することができる。これに関して、カーネルモードドライバは、コマンドバッファをDMAバッファに変換する責任を負うことができる。IHVは、コマンドバッファの正しい確認およびカーネルモードで割り当てられたDMAバッファへの正しいコピーを確実にする適当な機構を提供することを検討することができる。DMAバッファは、最終的にコプロセッサ向けのコマンドの集合であり、したがって、コプロセッサおよびサポートするハードウェアと正しくインターフェースしなければならないという点で、ハードウェア固有とすることができる。
【0024】
図3を横切る、ユーザモードとカーネルモードを分離する水平線に留意されたい。この線によって示されるように、本発明は、システムのセキュリティのために実施される、コンピュータメモリ割り当ての従来のレイアウト内で動作することができる。ユーザモードは、非特権的メモリであり、アプリケーションによってアクセスできる。その一方で、カーネルモードは、特権的であり、アプリケーションによってアクセスできない。カーネルモードで割り当てられたDMAバッファは、理論的にはあらゆるメモリ空間にマッピングできるが、アプリケーションのプライベートプロセス空間へのマッピングが、セキュリティリスクにつながる可能性があることに留意されたい。これは、アプリケーションのプライベートプロセス空間内のスレッドによって参照される仮想アドレスの内容を、修正できるからである。言い換えると、DMAバッファの内容を、確認された時とハードウェアによって処理される時の間に修正することができる。
【0025】
ステップ7に示されているように、カーネルモードドライバによって、DMAバッファによって使用されるメモリリソースのリストを作ることもできる。これは、コマンドバッファの確認の一部として達成することができる。このリストには、たとえば、リストのさまざまなメモリリソースのカーネルハンドル、およびメモリリソースが参照されるバッファ位置を含めることができる。このリストに、リストされたメモリリソースの期待されるコンテキスト状態も含めることができる。これによって、現在のハードウェア状態(たとえば、「現在のレンダターゲット」、「現在のZバッファ」など)の一部であるメモリリソースを、DMAバッファの先頭に再プログラムされるリストの一部とすることができる。というのは、コプロセッサにサブミットされた最後のDMAバッファ以降に位置を変更された可能性があるからである。
【0026】
ステップ8は、メモリリソースリストと共に、DMAバッファをコプロセッサカーネルに送ることを表す。コプロセッサカーネルは、ステップ9に示されているようにコプロセッサスケジューラにDMAバッファをサブミットすることができ、ステップ10に示されているようにユーザモードに戻ることができる。
【0027】
コプロセッサスケジューラは、一般に、コプロセッサのタスク(コプロセッサに送られるさまざまなDMAバッファおよび他の作業で具体化される)のフローをスケジューリングする責任を負う。コプロセッサスケジューラの機能性は、潜在的に非常に広範囲であり、この説明には、コプロセッサスケジューラが実行できる多数の潜在的な機能が含まれる。コプロセッサスケジューラを、コプロセッサスケジューラまたは単にスケジューラのいずれかと呼称することができる。さまざまな実施形態で、図3に示されているように、スケジューラによって、DMAバッファをコプロセッサにサブミットする前に、1つまたは複数の機能を実行することができる。ステップ11aは、スケジューラの一機能が、処理の準備ができたDMAバッファのサブミットであることを動的に示す。
【0028】
ステップ11bは、準備済みDMAバッファのリストに追加されるか、次に実行されるとスケジューラが決定したDMAバッファの選択を表す。これに関して、スケジューラは、DMAバッファを準備スレッドに渡すことができる。準備スレッドは、本明細書で使用される用語として、一般に、正しいメモリリソースがDMAバッファの処理を引き受けるようにする機能を提供する。第1に、準備スレッドは、補助メモリマネージャプロセス(図示せず)を呼び出して、現在補助メモリにないすべての必要なメモリオブジェクト(グラフィックスに関しては「サーフェス」)をページングするのに十分な位置を判定する(これがステップ12である)。用語「補助メモリ」が、コプロセッサによる使用に割り当てられたメモリを指すことに留意されたい。GPUコプロセッサの場合に、補助メモリを、しばしば、「ビデオメモリ」と呼ぶ。
【0029】
DMAバッファによって要求されるメモリリソースの一部が、使用可能な補助メモリに同時にはおさまらない可能性がある。補助メモリマネージャが、様々な理由からこの点で補助メモリにすべてのサーフェスを持ち込めない可能性がある。これが発生する場合には、さらなる処理を行って、補助メモリにより多くの空きを設けるか、その代わりにまたは空きの作成と組み合わせて、DMAバッファを複数のフラグメントに分割することができる。この場合に、準備スレッドによって、ドライバ事前定義分割点を使用して、バッファを分割し、このより小さいDMAバッファが必要とするメモリリソースのサブセットを突き止めるのを試みることができる。
【0030】
DMAバッファに十分な補助メモリが突き止められたならば、準備スレッドによって、ステップ13に示されているように、カーネルモードドライバを呼び出すことができる。当業者が諒解するように、これは、ステップ6、7、および8に関して述べたカーネルモードドライバとするか、別々のカーネルモードドライバとすることができる。
【0031】
ステップ14には、カーネルモードドライバによって、処理を待っているDMAバッファのページングバッファを構築できることが示されている。カーネルモードドライバによって、準備スレッドからの処理コマンドに基づいてこのページングバッファを構築することができる。ページングバッファは、上で定義したように、メモリリソースのページングのためのバッファである。「ページング」は、マッピングハードウェアを使用してメモリのブロック(ページ)の物理アドレスを変更することを指す。ページングバッファは、一般的に言って、メモリリソースをそれに割り当てられた位置に移動するコプロセッサ命令を含むDMAバッファである。ページングバッファは、DMAバッファが必要とするメモリリソースを正しいメモリ位置に移す機能をサービスし、このメモリ位置から、必要なときにコプロセッサによってそのリソースにアクセスすることができる。ページングバッファが正しく生成された場合に、特定のコプロセッサタスクに関する必要なすべてのメモリリソース(すなわちDMAバッファ)の位置がわかる。
【0032】
ステップ15は、ページングバッファが生成されたことの準備スレッドへの通知を表す。ステップ16は、ページングバッファの準備ができたことのスケジューラへのシグナルを表す。スケジューラは、この時点で、次のDMAバッファの処理の準備ができていると仮定することができ、あるいは、処理のためにコプロセッサに送る前に、DMAバッファに対するさらなる準備動作を行うために進行することができる。たとえば、元のDMAバッファの作成以降にメモリ位置が変更されている可能性があるので、スケジューラは、この点でカーネルモードドライバをもう一度呼び出して、メモリリソースの実際の位置を用いてDMAバッファをパッチできるようにすることができる。最後に、スケジューラは、ページングバッファ(存在する場合に)およびDMAバッファの両方を、処理のためにコプロセッサ(および他の任意の補助ハードウェア)にサブミットすることができる。
【0033】
上で説明したステップ1から16は、ハードウェア、ソフトウェア、およびその組合せを介して実施することができる。これに関して、図4(A)および4(B)に、擬似アルゴリズムの形式で図3のステップを全般的に示す。図4(A)および4(B)は、本発明に関して実践することができる潜在的な擬似アルゴリズムステップの網羅的なリストではなく、図4(A)および4(B)のすべてのステップが本発明の実践に必要と解釈するべきではない。そうではなく、図4(A)および4(B)は、本発明の教示における暗示的なリストである。
【0034】
図3に関して提供した上の説明は、本発明のさまざまな実施形態の説明である。しかし、上で説明した本発明の実施形態に関して、複数の利益が発見された。この説明の残りは、さまざまな改善を可能にし、本発明の実践で生じる可能性がある困難を克服するためのものである。
【0035】
スケジューリングの考慮事項
前に定義した動作(上のステップ1から16を参照されたい)の一部またはすべてを、DMAバッファがハードウェアにサブミットされる前に行うことができる。しかし、これらの動作の一部は、DMAバッファがハードウェアにサブミットされるまで実行が困難である場合がある。たとえば、メモリリソースの位置は、DMAバッファがコプロセッサにサブミットされる直前まで、判定が困難である可能性がある。これは、補助メモリリソースが、コプロセッサで実行されるときに各DMAバッファと共に移動される可能性があるからである。
【0036】
上のステップ1から16に含まれる動作の一部は、時間がかかり、したがって、たとえばスケジューラが次に実行するタスクを選択した後など、割込み時に行うことができない場合がある。同様に、まさに時間がかかるので、コプロセッサが他のタスクで忙しい間は、中央処理装置(「CPU」)で実行することが有益である。これによって、コプロセッサ長時間停止状態(starvation)が最小限になる。コプロセッサ長時間停止状態は、単に、コプロセッサが処理機能を処理せずに費やされる時間を指す。この問題に応答して、スケジューラと共に「ワーカースレッド」を利用することが有益である可能性がある。ワーカースレッドによって、時間のかかるセットアップ作業の一部を処理するのに役立つ機能を実行することができる。ワーカースレッドは、本発明の他のプロセスに関する動作の例について図4(B)の擬似アルゴリズムに追加された。
【0037】
このスケジューリングの考慮事項に加え、図3のシステムで任意の所与の時に、動作中のDMAバッファ(すなわち、コプロセッサによって現在処理されつつあるDMAバッファ)、準備されつつあるDMAバッファ、および準備される準備ができているDMAバッファのリストが存在する可能性がある。スケジューラへのサブミットの際に、新しいDMAバッファを、レディキュー(ready queue)に挿入し、その優先順位に応じて適当に順序付けることができる。しかし、新しいDMAバッファが、スケジューラにサブミットされるときに、コプロセッサの次のタスクとして選択されたDMAバッファを先取りできない場合に、本発明のさまざまな実施形態によって、機能性を高めることができる。これの理由は、DMAバッファの準備に、補助メモリとの間でのメモリリソースのページングが伴う可能性があるからである。したがって、処理に関して選択された次のDMAバッファの先取りによって、補助メモリマネージャの永続状態の変化がもたらされる可能性がある。準備されるタスクが先取りされる可能性がある場合には、新たに選ばれたDMAバッファの準備に起因する、補助メモリマネージャの永続状態に対する変更を元に戻すことがもたらされる可能性がある。DMAバッファタスクの動作の途中での補助メモリに対する変更を元に戻すことは、普通ではない可能性があり、潜在的に頻繁なコプロセッサ長時間停止状態につながる可能性がある。
【0038】
DMAバッファの分割
コマンドバッファが、APIによってコプロセッサカーネルにサブミットされるときに、カーネルモードドライバは、ハードウェア固有のDMAバッファおよびそのDMAバッファを実行するのに必要なメモリリソースのリストを生成する役割を担うことができる。特定のDMAバッファフォーマットが、IHVによって定義される場合があるが、ソフトウェアプロバイダは、自身がカーネルモードドライバのリソースリストのフォーマットを定義する作業を知ることができる。
【0039】
メモリリソースリストによって、DMAバッファによって使用できる異なるメモリリソースのタイムライン(timeline)情報を提供することができる。スケジューラは、このメモリリソースリストを使用して、DMAバッファがコプロセッサ上で実行される前にすべての必要なメモリリソースをページインし、DMAバッファによって同時に大量のリソースが使用されるときなど、必要な場合にDMAバッファを分割することができる。
【0040】
DMAバッファが、スケジューラによって分割される場合に、カーネルモードドライバは、メモリリソースリスト内でタイムライン情報を供給することによって、これを容易にする。これは、ドライバに、DMAバッファ内の「オフセット」を指定させることによって行うことができる。オフセットは、そのオフセットでのメモリリソースの使用法を指定するメモリリソース識別子を挿入することによって、メモリリソースがプログラムされているときに送ることができる。メモリリソースは、DMAバッファ内に複数回現れることができるので、同一のメモリリソースが、メモリリソースリストに複数回現れる場合がある。DMAバッファ内のメモリリソースへの参照のそれぞれによって、1つのエントリがリソースリストに追加される。
【0041】
本来、ハンドル/オフセットリストは、DMAバッファを分割する必要があるメモリリソースに関する十分な情報をスケジューラに与えるのに十分でない可能性がある。DMAバッファで特定のメモリリソースが必要なときを正確に知るために、スケジューラが、メモリリソースが別のリソースによって置換されるときに関する情報を必要とする場合もある。たとえば、DMAバッファの先頭で第1テクスチャステージに使用される第1のテクスチャ、テクスチャAが、途中で第2のテクスチャ、テクスチャBによって置換され、その後、DMAバッファの最後でテクスチャAに戻される。スケジューラは、この追加情報を使用して、より少ないメモリリソースを使用する量でDMAバッファを分割することができる。しかし、上で説明したシナリオでは、テクスチャBも、第1テクスチャステージでプログラミングされる可能性があり、この場合には、テクスチャAと同時に使用されており、DMAバッファの別々のサブセットに分離するべきではない。
【0042】
上で説明した洗練された方法でDMAバッファを分割するのに必要な「微細な粒子(finer grain)」の時間情報を達成するために、スケジューラによって、DMAバッファ全体のメモリリソースの使用状況に関する情報を使用することができる。これは、一実施形態では、カーネルモードドライバによって、メモリリソースリスト内のエントリごとにリソース識別子を供給することによって達成することができる。リソース識別子は、単純に、特定のメモリリソースがどのように使用されるかを表す整数値である。たとえば、0の値によって、メモリリソースがレンダターゲットとして使用されることを示すことができ、1の値によって、リソースがZバッファとして使用されることを示すことができる。この情報を用いて、スケジューラは、テクスチャBによってテクスチャAが置換されるか(たとえば、両方が同一のリソース識別子を有する)、またはテクスチャBがテクスチャAと同時に使用される(たとえば、AおよびBが異なるリソース識別子を有する)かどうかを判定することができる。リソース識別子の実際の値およびその意味は、IHVが定義するか、ソフトウェアアーキテクチャで供給することができる。リソース識別子として使用される値が、0ベースになることを保証し、ドライバ初期化の時にそのドライバが使用する最大のリソース識別子の値をドライバが指定することが有用になる可能性がある。
【0043】
図5に、DMAバッファ内で使用されるメモリリソースのタイムラインを定義するために供給される情報をスケジューラがどのように使用できるかを示す。スケジューラは、タイムラインの使用に進んで、バッファ分割点を定義することができる。一般に、DMAバッファが、現在のメモリリソース(すなわち、前のDMAバッファの末尾で最新であったメモリリソース)の、「セットアップ」または識別プロセスを開始しなければならないことに留意することが重要である可能性がある。これの理由は、前のDMAバッファが実行されてから後に、メモリリソースが移動され、したがって、再プログラムが必要である場合があるからである。メモリリソースは、DMAバッファが処理のためにスケジューリングされる時までに、再プログラムされる必要がある場合がある。
【0044】
図5に示されたメモリリソースリストに、任意の数のフィールドを含めることができる。下の表に、有用なフィールドの非網羅的リストを示す。
【0045】
【表1】
【0046】
ページング
一般に、DMAバッファによって参照されるメモリリソースは、コプロセッサによる実行のためにDMAバッファがサブミットされる前に、メモリ内に持ち込まれる。参照されるメモリリソースをメモリ内に持ち込むことを、リソースのページングと称する。ページングに、上で説明した準備ワーカースレッドと、カーネルモードドライバなどのドライバの間の対話を含めることができる。準備ワーカースレッドと補助メモリマネージャの間の動きを示す擬似アルゴリズムについて、図6を参照されたい。
【0047】
ページングステップは、通常は、処理についてDMAバッファが選択され、特定のDMAバッファに関するリソースのリストが生成されているときに行われる。ページングは、メモリリソースを補助メモリに入れる方法と、補助メモリのどこにそれを置くかを決定するために行われる。
【0048】
ページング処理を、補助メモリマネージャによって処理することができる。補助メモリマネージャは、特定の割り当ての作成時にカーネルモードドライバによって任意選択として供給されるヒントを使用することができる。このヒントは、メモリリソースに関してメモリ内の適当な位置を見つけるために作成されたものである。
【0049】
メモリリソースのページングに関連する複数の問題がある。すべてのリソースを持ち込むのに使用可能な十分な空き補助メモリがない場合があり、その場合には、現在メモリ内にあるリソースを追い出すことができる。補助メモリ内の他のオブジェクトを追い出した後であっても、DMAバッファ用のメモリが不十分である場合がある。その場合には、DMAバッファを複数のより小さい部分に分割することができ、これによって、必要なメモリリソースが減る。
【0050】
ページング中に、補助メモリマネージャは、適当な位置にメモリリソースを置くのに使用することができるコマンドのリストを構築することができる。そのコマンドのリストは、たとえば下記の動作から構築することができる。
1)追出し:別のリソースのための空きを作るために、特定のメモリリソースを現在のセグメントからシステムメモリに移動する;
2)ページイン:特定のメモリリソースをシステムメモリから補助メモリ内の空き位置に持ち込む;
3)再配置:特定のメモリリソースをある補助メモリ位置から別の補助メモリ位置に移動する。
【0051】
補助メモリマネージャは、メモリ配置問題を解決するために、これらの動作のどれでも使用することを許可されることができる。この非網羅的なコマンドリストは、ページング動作中に補助メモリマネージャによって生成し、後にスケジューラによってページングバッファを生成するのに使用することができる。補助メモリマネージャは、再配置、追出し、またはページイン、あるいは他の方法で移動されるまたは他の方法で変更されるメモリリソースについてコマンドリスト内のエントリを生成することができる。これに関して、本発明のさまざまな実施形態によって、コマンドリスト内に下記のフィールドを設けることができる。
【0052】
【表2】
【0053】
ページングバッファ生成
上で説明したコマンドラインを使用して、スケジューラによってページングバッファを生成して、コマンドを実行することができる。本発明に関連して使用されるページングバッファのさまざまな実施形態は、図7に示されているように実施することができる。
【0054】
図7からわかるように、コマンドの中には、実行の前に前処理を必要とするものと、前処理なしで処理できるものがある。前処理は、ワーカースレッドを含む複数の方法で行うことができる。コマンドの前処理で、ページングバッファの一部が処理されるまで待つ必要がある場合があることに留意されたい。図7に示されたモデルでは、ワーカースレッドによって、ページングバッファを準備し、ページングバッファに関するCPU前処理を処理する。CPU前処理が、ページングバッファでの動作の前に必要なときには、ワーカースレッドによって、コプロセッサでのページングバッファに対する動作がブロックされる。その後、ワーカースレッドによって、ページングバッファを再始動する前にCPU要求がサブミットされて、動作が完了する。
【0055】
したがって、コマンドリスト内のコマンドごとに、下記のアクションが適当である可能性がある:
ページングバッファ生成時の前処理;
ページングバッファ内の同期ポイントでのCPU処理;
メモリリソースを移動する「Blit」コマンド;
ページングバッファが完了した後のCPU作業の後処理。
【0056】
可能なアクションの上のリストに関して、ページングバッファ自体に、CPUが作業を処理している間にコプロセッサに停止するように要求するコマンドを含めることができる。そのような、割込みを生成し、コプロセッサを停止させるコマンドを、本明細書では「ブロッキングフェンス」と称する。ページングバッファ内のどのコマンドにも、その前または後にブロッキングフェンスを置くことができる。割込みは望ましくないので、CPUがコプロセッサに割り込む回数は、ポスト動作フェンスをバッファの末尾に集めることによって減らされる。ポスト動作フェンス(または「ポストフェンス」)がバッファの末尾の前に必要である場合は、スケジューラによって検出され、ポストフェンスが実行済みであることを必要とするコマンドのプリ動作フェンス(または「プリフェンス」)にマージされる。
【0057】
補助メモリの一貫性を維持するために、ページングバッファの処理で外部割込みを許可しないことが有利になる場合がある。したがって、ページングバッファが実行を完了する前にカンタム(quantum)が満了する場合には、ページングバッファを、完了までコプロセッサの制御下に留まらせることができる。
【0058】
ページングバッファ内のフェンスの処理を含む、ワーカースレッド内で行うことができるイベントのチェーンを表す擬似アルゴリズムについて、図8を参照されたい。図8に関して、下の表に、コマンドリスト内に現れる可能性がある一般化されたコマンドと、前処理、ページングバッファ生成、および生成され得る終了フェンスに関するコマンドのタイプのありそうな分岐のリストを示す。下の表は、役に立つ例示としてのみ提供され、可能なコマンドのタイプまたはこれらのコマンドに関して発生し得るアクションの網羅的なリストであることを意図されたものではない。
【0059】
【表3】
【0060】
【表4】
【0061】
【表5】
【0062】
本明細書で提示するスケジューリングモデルが、コプロセッサをビジーに保つためにかなりの量の自明でないCPU処理を必要とする可能性があることに留意されたい。この作業は、少なくとも部分的に、現在存在するコプロセッサハードウェアの機能によって必要とされる。将来のグラフィックスハードウェアは、より強力なメモリ仮想化およびコプロセッサスケジューリングを有するように設計される可能性がある。これに関して、複数の長所に到達しており、これらの長所も本発明に関して開示される。ハードウェア機能のそれぞれについて、改善の動機および上で説明したスケジューリングモデルに対する影響を説明する。いくつかの改善は、特定の実施手法に基づいて提示される。これらの手法のすべてが必ずしも将来のモデルでサポートされるのではないが、特定の手法が実践される場合に、そのときに、改善を実施手法に適合させる基準を提供する方法で、さまざまな改善を本明細書で説明する。
【0063】
割込み可能なハードウェア
コプロセッサスケジューリングの信頼性を高めるために、コプロセッサによって、DMAバッファ全体より微細な粒度での割込みをサポートすることができる。たとえば、コプロセッサおよびサポートするハードウェアによって、三角形の処理の前または後だけではなく、三角形の処理の中での割込みをサポートすることができる。
【0064】
そのような割込み可能ハードウェアのさまざまな実施形態で、好ましい設計手法は、コプロセッサコンテキストの補助メモリへの自動的な保存および復元を介してコプロセッサの潜在的に完全な仮想化を提供することとすることができる。各コプロセッサコンテキストは、制限ではなく例として、プライベートアドレス空間、DMAバッファが累積されるプライベートリングバッファ、およびコプロセッサコンテキストが実行中でないときにハードウェアの状態が保存されるメモリのプライベート部分を有することができる。この設定でのコンテキスト切り替えをサポートするために、スケジューラによって、保存されたコンテキストの補助メモリ内の物理アドレスをメモリマップ式レジスタを介してコプロセッサに与えることができる。コプロセッサは、そのコプロセッサコンテキストをロードし、すべてのメモリリソースが有効であることを検証し、リングバッファに累積されたDMAバッファを実行し、必要なリソースに出会うときにそのリソースをフォールトにする。
【0065】
上記に関して、さらに、カーネルモードドライバによって、実行されていないコプロセサコンテキストの状態を照会することを可能にすることができる。これは、「実行リスト」イベントトレース(下で説明する)を使用することによるか、照会手段によって、保存されたコンテキストを検査することによって行うことができる。これに関して、ドライバによって、(1)コプロセッサがもっとも最近に特定のコンテキストから切り替えられた理由(たとえば、空、新しい実行リスト、ページフォールト)、(2)ハードウェアによって使用中のメモリリソースのリスト(サーフェスレベルフォールトがサポートされる場合)、(3)フォールトアドレス(ページレベルフォールトがサポートされる場合、および(4)特定のコンテキストを実行していたコプロセサクロックサイクル数などの有用な情報を判定することができる。
【0066】
さらに、カーネルモードドライバによって、現在実行されていないコンテキストのリングに、新しいDMAバッファを挿入できるようにすることができる。保存されたコンテキスト内で、リングの位置、そのコンテキストに保管されたページテーブルまたは他の物理メモリ参照を修正できることも可能である。そのような修正は、たとえば、メモリ内のリソースの移動に続いて必要になる可能性がある。
【0067】
コプロセッサコンテキストごとの仮想アドレス空間
上で説明した基本的なスケジューリングモデルの複雑さの一部は、コプロセッサコンテキストが共通のコプロセッサアドレス空間を共有している可能性があるという事実に起因する。このアドレス空間を仮想化することによって、よりスマートなシステムを提供することができる。アドレス空間の仮想化では、補助メモリマネージャによって、メモリを移動することができ、リソースを補助メモリから完全に追い出すことさえできる。これは、リソースに関する実際にコプロセッサから可視のアドレスを、その寿命の間に変更できることを意味する。したがって、ユーザモードで構築されるコマンドバッファは、コマンドバッファが実行のためにスケジューリングされるまでアドレスが未知である可能性があるので、そのアドレスによって割り当てを直接に参照することができない。
【0068】
たとえば、上で説明した基本スケジューリングモデルの下記の要素を、コプロセッサコンテキストごとのアドレス空間の使用を介して除去することができる。
1)ハンドルを実際のメモリ位置に置換することによるコマンドバッファのパッチ
2)メモリアクセスに関するコマンドバッファの確認
3)カーネルモードでのメモリリソースリストの構築
4)別々のコマンドバッファおよびDMAバッファの作成
5)割り込まれたDMAバッファのリソースの割込み前の位置への移動
【0069】
プロセッサコンテキストごとの仮想アドレス空間を提供する際に、特定のコプロセッサコンテキスト内での割り当てによって、そのコンテキストのアドレス空間内の独自のアドレスを得ることができる。このアドレスは、割り当ての寿命の間に変更する必要がない。したがって、コマンドバッファによって、このアドレスを直接に参照することができ、パッチは不要である。コマンドバッファを確認し、DMAバッファにコピーする必要もなくなる。DMAバッファでのメモリ参照は、コプロセッサの仮想アドレス空間内であり、そのアドレス空間が、実際にすべてのコプロセッサコンテキストについてプライベートなので、有効性に関してメモリ参照を確認する必要はなく、したがって、アプリケーションに可視でないDMAバッファ内のコマンドバッファの確認された内容を隠蔽する必要はない。割り当てまたは追い出された割り当てによって占められていないアドレス空間(ハンドルまたは実アドレス)は、ハードウェアによってダミーページにリダイレクトされるか、アクセスフォールトを引き起こすことができる。これによって、コンテキストが、アクセスすると思われないメモリにアクセスできないので、カーネルモードメモリのセキュリティが保たれる。
【0070】
コプロセッサコンテキストごとの仮想アドレス空間の長所の一部は、次の通りである。各割り当てが、割り当て時にコプロセッサに可視のアドレス(またはハンドル)を得る。コマンドバッファがなく、DMAバッファは、ユーザモードドライバに直接に可視であり、ユーザモードドライバによって書き込まれる。DMAバッファは、それが使用する割り当てのアドレス(またはハンドル)を直接に参照する。ページングに使用されるリソースリストは、ユーザモードドライバによって構築される。
【0071】
図3および対応する説明に示された本発明のさまざまな実施形態のモデルを想起されたい。このモデルを、割込み可能ハードウェアおよび/またはプロセッサコンテキストごとの仮想アドレス空間を使用してさらに改善することができる。これに関して、次の節で、本発明の追加の長所によってさらに改善されることを除いて図3の概念に似た概念を説明する。
【0072】
サーフェスの割り当ておよび割り当て解除
高度なモデルで、カーネルモードのビデオメモリマネージャ「VidMm」などの補助メモリマネージャによって、コプロセッサコンテキストに関する仮想アドレス空間を提供でき、さまざまなコプロセッサコンテキストの間で、これらがメモリの公平な分け前を得られるように物理メモリを管理することができる。基本モデルの割り当て方式に対するこの改善のさまざまな実施形態を、図9に示す。図9には、当業者に馴染みのある用語を使用して本発明の実施形態を示す。というのは、これが、当技術分野で認識された概念に対応するからである。たとえば、「VidMm」は、ビデオメモリマネージャであり、「サンク(Thunk)インターフェース」は、サンクインターフェースである。しかし、この用語は、本発明をより明瞭に説明するのに使用されるが、本発明を制限する意図の表明と解釈するべきではないことに留意されたい。したがって、「VidMm」は、任意の補助メモリに関するメモリマネージャとすることができ、「サンクインターフェース」は、任意の適当なインターフェースとすることができる。
【0073】
図9に関して、高度なモデルを用いると、DMAバッファをアプリケーションのアドレス空間に直接にマッピングできるようになり、これによって、任意選択として、DMAバッファをユーザモードドライバから直接にアクセス可能にすることができる。ユーザモードドライバは、アクセスする必要がある各メモリリソースの永久仮想アドレスまたはハンドルを使用して(したがってパッチが不要になる)レンダリングプリミティブをDMAバッファに直接にバッチ化する。ユーザモードドライバによって、DMAバッファによって使用されるメモリリソースのリストも構築され、したがって、補助メモリマネージャは、DMAバッファがスケジューリングされる前にこれらのリソースを補助メモリバッファに持ち込むことができる。悪意のあるアプリケーションがリソースリストを修正する場合に、リソースの正しい組が、正しくページインされなくなる。これによって必ずしもメモリ保護モデルが壊されないことに留意されたい。というのは、有効なメモリを参照していないアドレス空間の範囲が、ダミーメモリページを参照することまたはハードウェアにフォールトにすることのいずれかのために必要になる可能性があり、指定されたコプロセッサコンテキストの実行を停止させるからである。どちらの場合でも、壊れたリソースリストによって、コプロセッサコンテキストが別のコンテキストのメモリにアクセスできるようになることがもたらされることはない。
【0074】
高度なモデルでは、ユーザモードドライバが、DMAバッファをカーネルモードドライバにサブミットし、カーネルモードライバが、DMAバッファをスケジューラにサブミットする。メモリマネージャにリソースリスト内のリソースをページングするように要求した後に、スケジューラは、DMAバッファをそのままハードウェアに送る。
【0075】
高度なモデルでのスケジューリング
高度なモデルでのスケジューリングは、基本モデルでのスケジューリングに非常に似ている。DMAバッファがコプロセッサにサブミットされる前にDMAバッファを準備するワーカースレッドが依然としてある。しかし、高度なモデルでワーカースレッドによって達成できる作業は、ページング動作だけに制限される必要がある。
【0076】
基本モデルのスケジューリングおよび高度なモデルのスケジューリングの実施形態について、図10および図11を参照されたい。これから明らかにするように、高度なモデルは、2つのスケジューリングオプションを有する。デマンドフォールトなしでスケジューリングするときには、準備フェーズを実施することができる。しかし、高度なモードでデマンドフォールトを使用するときには、準備フェーズは不要である。
【0077】
さらに、図12(A)、12(B)に、高度なスケジューリングモデルを実施することができる擬似コードを示す流れ図を示す。
【0078】
高度なモデルでのページング
高度なモデルでのページングは、基本モデルのページングと異なる。高度なモデルでは、ページングされる割り当てのアドレスが、既に知られており、メモリマネージャは、単に、それを有効にする必要がある。リソースリスト内の割り当てを有効にするために、メモリマネージャは、空いている物理補助メモリの範囲を見つけ、ドライバに、ページテーブルまたはハンドルをその範囲にマッピングするように要求する必要がある。必要であれば、物理メモリの範囲が連続するページのセットになることを要求することができる。
【0079】
割り当てを有効にするのに使用可能な物理ビデオメモリが不十分な場合には、本明細書でVidMmと称する補助メモリマネージャは、追出しについて、現在有効な割り当てをマークすることができる。割り当てが追い出されるときに、そのコンテキストが、システムメモリ(まだシステムメモリ内になかったと仮定して)に転送され、その後、その仮想アドレスまたはハンドルが、無効にされる。
【0080】
仮想アドレス空間
当技術分野で既知または将来に開発される、仮想アドレス空間の提供に関する技法のいずれかを、本発明と共に使用することができる。そのようなアドレス空間を使用できる方法を示すために、共通の仮想アドレス空間技法を使用する2つの例を、本明細書で示す。コプロセッサの仮想アドレス空間を作成する複数の方法があり、当業者が本明細書の例から外挿できることを理解されたい。これに関して、可変長フラットページテーブルおよびマルチレベルページテーブルを使用する仮想アドレス空間を、本明細書で説明する。
【0081】
可変長フラットページテーブル。可変長フラットページテーブルと連合しての本発明の使用を、図13に示す。この方法では、コプロセッサのアドレス空間が、フラットページテーブルの使用を介して仮想化される。仮想アドレス空間を、事前定義のメモリ量、たとえば4KBのページに分割することができる。仮想アドレス空間内のページごとに、1つのページテーブルが設けられ、このページテーブルには、関連する物理メモリの物理アドレスおよび位置(たとえば、Accelerated Graphics Port(AGP)、Peripheral Component Interconnect(PCI)、またはビデオ)を指定するための識別子、たとえば64ビットエントリが含まれる。一実施形態では、コプロセッサによってサポートされるページサイズが、任意ではなく、コプロセッサページテーブルによってシステムメモリページを参照できるようにするために、4KBでなければならない。さらに、この実施形態では、コプロセッサページテーブルによって、同一のアドレス空間から、ローカルビデオメモリとシステムメモリの両方をアドレッシングできなければならない。コプロセッサは、単一のサーフェスに属するすべてのページを単一のタイプのメモリにマッピングすることを要求することができる。たとえば、コプロセッサは、特定のレンダターゲットに属するすべてのページを、ローカルビデオメモリにマッピングすることを要求することができる。しかし、サーフェスをさまざまな物理メモリタイプ(AGP、ローカルビデオなど)にマッピングするページテーブルエントリが、ページテーブルに存在することができる。
【0082】
PCIアダプタおよびAGPアダプタについて、各ページテーブルエントリの例示的実施形態に、32ビットが含まれ、4GB物理アドレス空間全体をコプロセッサに可視にすることができる。PCI−Expressタイプのアダプタを使用する実施形態について、コプロセッサは、64ビットアドレッシングサイクルをサポートすることができる。各ページテーブルエントリに、40ビット以上を含めて、それぞれテラバイト単位のメモリをアドレッシングすることができる。マザーボード上の40ビット以上の物理アドレス信号線を利用する64ビットシステムを実施する実施形態では、対応するビデオアダプタがこのアドレス空間全体をアドレッシングできない場合に、性能ペナルティを経験する場合がある。したがって、64ビットのフルサポートが推奨される。
【0083】
フラットページテーブル法は、ページディレクトリがなく巨大なページテーブルだけがあることを除いて、現在INTEL(登録商標)社の8086(x86)ファミリCPUで使用可能な仮想化機構に似ている。
【0084】
有効な割り当てに関連しない仮想アドレスを、ダミーページにリダイレクトして、悪意のあるDMAバッファが、コプロセッサに、アクセスするべきではないメモリを強制的にアクセスさせることを防ぐことができる。ハードウェアによって、エントリが有効であることを指定する有効ビットを、ページテーブルエントリのそれぞれで実施することができる。
【0085】
ページテーブルは、関連するコプロセッサコンテキストがコプロセッサ上で現在実行中でないときに、再配置可能とすることができる。コンテキストが実行中でないときに、VidMmによって、ページテーブルをシステムメモリに追い出すことができる。コンテキストが、再実行の準備ができたときに、ページテーブルをビデオメモリの、潜在的に異なる位置に戻すことができる。ドライバは、保存されたコプロセッサコンテキスト内のページテーブルの位置を更新することもできる。
【0086】
この実施形態で、すべてのメモリアクセスを、コプロセッサ仮想アドレスを介して行うことができる。しかし、これは、本発明がそのようなアクセスを必要とすることを意味するのではない。ある要素を、他の方法でアクセスすることができ、他の方法でアクセスされる場合により高い機能性を提供することができる。仮想アドレス方式から除外できるいくつかの項目の例が、下記である。
1)ページテーブル自体を、物理アドレスを介して参照することができる。
2)陰極線管(CRT)を、連続するメモリ範囲について物理アドレスにプログラムすることができる。
3)仮想印刷エンジン(VPE)によって、物理アドレスに直接にDMAを実行することができる。
4)オーバーレイは、物理アドレスから直接に読み取ることができる。
5)コプロセッサコンテキストを、物理アドレスを介して参照することができる。
6)プライマリリングバッファを、物理アドレスを介して参照することができる。
【0087】
コンテキスト切り替え中に、コプロセッサによって、復元されるコンテキストによって使用される仮想アドレスを再変換することができる。これによって、これらのアドレスがコンテキスト切り替えの前と同一の物理ページを参照するという潜在的に誤った仮定をコプロセッサにさせるのではなく、メモリリソースが正しいプレーンに配置されることが保証される。また、本発明のさまざまな実施形態に関して、単一のページテーブル内または複数のページテーブルにまたがる複数のエントリが、同一の物理ページを参照できるようにすることが有益であることにも留意されたい。
【0088】
さまざまな実施形態で、コプロセッサによって、ページテーブルの現在のサイズを与えるリミットレジスタ(limit register)を実施することができる。ページテーブルの末尾を超えるメモリ参照のすべてが、コプロセッサによって無効なアクセスとみなされ、それなりに処理される。ページテーブルは、2のべきで拡張可能であり、一実施形態で、少なくとも2GBのアドレス空間(2MBのページテーブル)をサポートすることができる。
【0089】
コプロセッサコンテキストに関連する仮想アドレス空間が断片化された場合に、API、たとえばMICROSOFT(登録商標)Direct3Dランタイムによって、ガーベジコレクションを実行して、アドレス空間および関連するページテーブルのサイズを減らすことができる。上位仮想アドレスでの割り当てが、削除され、低位アドレスに再割り当てされる。
【0090】
本発明と共に可変長フラットページテーブルを使用して仮想アドレス空間を実施することの長所および短所は、当業者に明白である。要約すると、フラットページテーブルを使用することの長所の1つが、物理メモリに対する1レベルの間接参照だけがあることである。もう1つの長所は、ページの不連続の組を用いてページングを解決できることである。しかし、短所もある。たとえば、コプロセッサが動作中であるときに、一般に、ページテーブル全体がメモリ内に存在する必要がある。また、ページテーブルによって、かなりの量のメモリが消費される可能性がある。ページテーブルは、一般にメモリ内のページの連続する組を必要とするので、配置に不便である可能性がある。
【0091】
マルチレベルページテーブル。マルチレベルページテーブルと共の本発明の使用を、図14に示す。マルチレベルページテーブルは、全般的に、可変長フラットページテーブルに類似するものとすることができるが、マルチレベルページテーブルでは、仮想アドレスのインデックス部分が、複数のテーブルにまたがって分割される。たとえば、さまざまな実施形態で、32ビットアドレス空間を使用することができる。この情況では、ハードウェアが、2レベル間接参照を有することが要求される場合がある。間接参照の第1レベルを、ページディレクトリと呼び、第2レベルを、ページテーブルと呼ぶ。コプロセッサが特定のコンテキストを実行しているときに、リソースリスト内の割り当てが必要とするそのコンテキストのページディレクトリおよびページテーブルだけが、メモリ内に存在する必要がある。
【0092】
本発明と共に複数レベルページテーブルを設けることの長所の1つが、ページの不連続の組を用いてページングを解決できることであることを諒解されたい。また、割り当てによって、システムメモリおよびローカルビデオメモリからのページを混合することができ、使用中のページディレクトリおよびページテーブルだけがメモリに存在する必要があり、ページディレクトリおよびページテーブルが、それぞれ1ページだけを必要とする(複数ページの連続的な割り当ては不要である)。しかし、これらの長所にもかかわらず、メモリへのアクセスが2つの間接参照を必要とするという短所が残っている。
【0093】
サーフェスレベルフォールト
コプロセッサコンテキストごとの仮想アドレス空間の追加によって、高度なスケジューリングモデルが、適度に良好に動作し、一般に、特にメモリ圧迫がほとんどまたはまったくないときに、大きいCPUオーバーヘッドを必要としない。ほとんどの場合に、DMAバッファをスケジューラにサブミットできるときに、そのバッファによって参照されるリソースが、既にメモリ内に存在し、したがって、DMAバッファは、ページングスレッドによるページングをまったく必要としない。しかし、スケジューリングに関して、タイムキーピング(time keeping)の精度を高めることによって、モデルをさらに改善することができる。
【0094】
本発明を実施する際に出会う問題の1つが、特定のDMAバッファの実行にどれだけの時間を要するかを前もって知ることが可能でない場合があることである。これは、準備される次のDMAバッファに関するスケジューラによる潜在的に悪い選択をもたらす可能性がある。現在のコンテキスト以上の優先順位の他のコンテキストがない場合、またはその優先順位の他のすべてのコンテキストが空である場合に、スケジューラは、現在のコンテキストから次のDMAバッファを選択することができる。そうでない場合には、スケジューラは、現在のコンテキスト以上の優先順位を有する次のコンテキストから次のDMAバッファを選択することができる。しかし、その選択が、正確である保証はない。次に高い優先順位のコンテキストからDMAバッファを選択するときに、スケジューラは、現在のコンテキストのDMAバッファが、1カンタムより長く実行されると仮定することができる。そのとおりでない場合には、スケジューラは、あまりにも早くそのハードウェアコンテキストから切り替える可能性がある。現在のDMAバッファが、1カンタム未満だけ実行される場合には、スケジューラは、現在のコンテキストから次のDMAバッファを選択するべきであった(これによってコプロセッサの使用効率が最大になるからである)。
【0095】
メモリ圧迫がほとんどまたはまったくないときに、一般に、次のDMAバッファの潜在的な候補の両方が、既にすべてのリソースをメモリ内に有する可能性があり、したがって、どちらのバッファもページングを必要としない可能性が高い。そのシナリオでは、スケジューラが、最初のDMAバッファのカンタムが終了するときに誤りを理解し、即座に考えを変え、コプロセッサに正しいDMAバッファを与えることができる。
【0096】
しかし、メモリ圧迫の下では、このモデルは安定性が下がる可能性がある。次のDMAバッファの「サイズ決定」が、滑らかな動作を保証する際の有利なステップになる可能性がある。メモリ圧迫の下で、前に説明したシナリオでは、おそらく、次のDMAバッファの2つの潜在的な候補の1つが、あるページングを必要とし、したがって、準備スレッドに送られる。その場合に、スケジューラが、最後に「考えを変え」、この2つのDMAバッファを入れ替えることが賢明である。しかし、そのような変更を行うことができ、そのような実践が、本発明の説明の範囲から出ないことに留意されたい。たとえば、次のDMAバッファの準備が完了し、他の潜在的なDMAバッファ候補がページングを必要としないシナリオでは、DMAバッファを交換することができる。これは、補助メモリマネージャによる共有可能な割り当てのある特別なサポートを暗示する可能性がある。
【0097】
上で説明した潜在的なタイムキーピングエラー自体は、それほど悪くはなく、後続カンタム中に、コンテキストに失われた処理時間を与えることによって対処することができる。また、ほとんどの場合に、DMAバッファに、複数のコプロセッサカンタムにわたる実行に十分なコマンドが含まれ、したがって、各コンテキストがそのすべてのカンタムを得ることができる。しかし、メモリ圧迫の下では、補助メモリマネージャが、各コンテキストの作業セットを減らすために、DMAバッファをより小さいバッファに分割することを強制される(上で説明したように)可能性がある。そのようなDMAバッファの分割によって、DMAバッファのサイズが減り、それに対応して、上で説明したカンタム化の問題が増える。
【0098】
メモリ圧迫の下で生じる可能性があるもう1つの問題は、潜在的に、DMAバッファによって実際に使用される、ページインされるより多くのメモリがあるので、このモデルによって人工的に余分の圧迫が引き起こされる可能性があることである。ページインされた余分のメモリのすべてが、潜在的に、次のカンタムの前に追い出され、もう一度ページインされる必要が生じる。これは、ページングアクティビティが既に高いときに、さらに増加したページングアクティビティにつながる可能性がある。基本モデルおよび高度なモデルでは、補助メモリマネージャが、適当な追出しポリシを選択することによって、ページングの増加の問題に対処することができる。たとえば、軽いメモリ圧迫の下で、各コンテキストは、その作業セット内に適度な量のメモリを有する可能性が高い。他のコンテキストからメモリを追い出す前に、補助メモリマネージャは、まず現在のコンテキストからメモリを追い出すことと、使用可能な作業セットにおさまるようにDMAバッファを分割することを試みる。特定のコンテキストのDMAバッファが、その最小サイズに分割されたならば、補助メモリマネージャは、別のコンテキストからメモリを追い出さざるを得なくなる可能性がある。
【0099】
この問題を解決するのに好ましい手法の1つが、コプロセッサが必要とするメモリのデマンドフォールト(demand faulting)を可能にすることである。この方法で、コプロセッサが必要とするメモリのサブセットだけがメモリに存在する必要があることを保証することができる。
【0100】
高度なモデルについて提案されるフォールトのレベルは、サーフェス粒度のレベルである。しかし、任意のレベルのフォールトが、本発明と共に使用するのに適当である可能性があることを理解されたい。また、ページテーブルハードウェアの場合に、ハードウェアは、割り当てが有効であるかどうかを判定するために、割り当ての最初のページの状態だけを調べることができることに留意されたい。というのは、補助メモリマネージャが、割り当て全体を同時にメモリに持ち込めるからである。
【0101】
さまざまな実施形態で、ハードウェアによって、下記のいずれかのときにページフォールトを生成することができる。
1)無効なリングバッファまたはDMAバッファを参照しているコンテキストへのコンテキスト切り替えが発生する。
2)プリミティブが描かれようとしており、必要なメモリリソースの一部が存在しない(たとえば、頂点シェーダコード、頂点バッファ、テクスチャ)。
【0102】
第2の情況で、ハードウェアが、すべての三角形をレンダリングする前に、現在のメモリリソースを再サンプリングする必要がある場合があることに留意されたい。補助メモリマネージャが、コプロセッサの動作中を含めて、任意の時に仮想アドレスまたはハンドルを無効化する可能性がある。ハードウェアが、現在使用しているメモリリソースのすべてについて照会できるようにする可能性があることも期待される。補助メモリマネージャは、その情報を使用して、特定の割り当てがハードウェアによって使用中であるときを判定することができる。補助メモリマネージャは、割り当てが、コプロセッサによって現在使用中のリソースのリストに現れる場合に、その仮想アドレスまたはハンドルを無効化した後に、コプロセッサがその割り当てにアクセスできないので、その割り当てを安全に追い出せると仮定する可能性がある。それを行う試みによって、ページフォールトが引き起こされる可能性がある。
【0103】
本発明に関連するサーフェスレベルフォールトの使用のさらなる説明を、サーフェスレベルフォールトモデルの以下のより詳細な説明によって提供する。以下のモデルは、ある実施形態の例であり、本発明の潜在的な使用または本明細書で提供されるスケジューリングモデルのコンテキストの外部の他の応用例に関するサーフェスレベルフォールトの概念の潜在的な使用に対する制限と解釈するべきではない。
【0104】
第1に、メモリリソースに関する割り当て方式は、本明細書のコプロセッサコンテキストごとの仮想アドレス空間の節で説明したものと同一とすることができる。詳細についてはその節を参照されたい。
【0105】
第2に、DMAバッファのレンダリングコマンド方式およびリソースリストも、本明細書のコプロセッサコンテキストごとの仮想アドレス空間の節で説明したものと同一とすることができる。このモデルでは、グラフィックハードウェアがサーフェルレベルフォールトをサポートする場合であっても、リソースリストが必要である。補助メモリマネージャ(本明細書では「VidMm」)は、リソースリストを使用して、メモリ割り当てに関する使用状況情報を獲得する。その使用状況情報を用いて、VidMmが、メモリ内に空間を作る必要があるときに、追出しの候補を決定することができる。
【0106】
サーフェスレベルフォールトの追加に関して、リソースリストに関するセキュリティの懸念事項はなく、したがって、ユーザモードでリソースリストを構築することができる。悪意のあるアプリケーションが、リソースリストに無効なデータを入れた場合に、発生し得る最悪の事態は、悪意のあるアプリケーションの性能が悪くなることである。VidMmは、追出しの候補に関する非論理的な選択を行う可能性があり、これによって、そのアプリケーションに関する余分なページングアクティビティがもたらされる。
【0107】
サーフェスのデマンドフォールトを用いるスケジューリングモデルは、多くの点で、サーフェスレベルフォールトを使用しないモデルと異なる可能性がある。一般に、レディリスト内のプロセスは、コプロセッサに直接にサブミットでき、準備フェーズが不要である。スケジューラは、ページフォールトの解決を必要とするコンテキストの、専用のリストおよびページングスレッドを維持することができる。ページング動作に使用される、VidMm固有のコプロセッサコンテキストがある。最後に、コンテキストにサブミットされるDMAバッファは、単一の作業アイテムを形成するように連結される。
【0108】
このモデルでは、準備フェーズを除去することができる。スケジューラは、あるコンテキストから別のコンテキストに直接に切り替えるようにコプロセッサに要求することができ、すべてのコンテキストがいつでも実行の準備ができていると仮定することができる。切り替え先のコンテキストの、一部のメモリリソースがメモリ内に存在しない場合には、ハードウェアがフォールトすることができ、コンテキストが、リスト(図15のインページリストなど)に追加され、したがって、ページングスレッドが、そのフォールトの解決について作業を開始することができる。
【0109】
このモデルに関してスケジューラによって維持される例示的なプロセスのリストを、図15に示す。図15を参照すると、フォールトが発生するときに、フォールトを引き起こしたコンテキストを、インページリストに追加することができる。その後、ページングスレッドによって、そのフォールトが解決される。ページングスレッドによって、最初に解決される、フォールトした最高の優先順位のコンテキストを選択することができる。周期的な優先順位ブーストを使用して、低い優先順位のコンテキストが、そのフォールトを解決されるのに十分に高い優先順位を最終的に得ることを保証することができる。フォールトが、インページワーカースレッドによって解決されている間に、スケジューラによって、コプロセッサでの実行の準備ができているコンテキストをスケジューリングすることができる。コプロセッサが働いている間に、インページワーカースレッドは、ドライバを呼び出して割り当てをアドレスにマッピングするかアンマップすることによって、ビデオメモリを操作することができる。
【0110】
コプロセッサによって現在使用されている割り当てが、無効化される可能性がある。コプロセッサがその割り当てに次にアクセスしようとする時に、フォールトが発生しなければならない。しかし、コプロセッサは、任意の時に即座にフォールトすることができないので(たとえば、一部のコプロセッサは、三角形の間で現在の割り当ての状態を再サンプリングするだけである)、コプロセッサが、無効化された後のある時に割り当てを使用することを必要とする可能性がある。
【0111】
それが起こらないようにするために、VidMmによって、次のコンテキスト切り替えまで、割り当てのメモリが、仮想アドレスまたはハンドルが無効化される場合であっても、有効のままになることを保証することができる。これは、ページングに起因するメモリ転送を、VidMm専用のコプロセッサコンテキストで行わせることによって達成することができる。メモリ転送が、別々のコンテキストで行われるので、メモリのコンテキストが変更される前にコンテキストが切り替えられることを確信することができる。システムメモリを参照する仮想アドレスまたはハンドルについて、追出し中のメモリ転送はない。その場合に、VidMmによって、コプロセッサコンテキストがVidMmの専用コンテキストに切り替えられるまで、システムメモリをピン止めすることによってシステムメモリが有効なままになることを保証することができる。
【0112】
VidMm専用コプロセッサコンテキストは、システムメモリとビデオメモリの間のメモリ転送を行うのにVidMmによって使用される通常のコプロセッサコンテキストである。VidMmコンテキストは、インページリスト内の最高優先順位のアイテムの優先順位をとる可変優先順位コンテキストである。すべてのページング動作を単一のコンテキストに直列化させることによって、VidMmの同期化モデルが単純になる。
【0113】
このモデルでのもう1つの興味深い相違は、特定のコンテキストについてサブミットされるDMAバッファのすべを連結して、単一のタスクを形成できる方法である。前のモデルでは、各DMAバッファによって、1つの作業アイテムが形成され、各コンテキストによって、これらの作業アイテムのリストが維持される。スケジューラは、必ずしもコンテキストをスケジューリングせず、コンテキストに関連する特定の作業アイテムをスケジューリングする(かつ、その準備を開始する)。作業アイテムが完了の機会を得る前に、スケジューラが、次の作業アイテムを選択しなければならない。各作業アイテムは、サブミットされる前に準備されなければならず、したがって、スケジューラは、次の作業アイテムをどれにしなければならないかを前もって知らなければならないが、これは常に可能ではない。
【0114】
サーフェスレベルフォールトを用いると、DMAバッファは準備の必要がない。このゆえに、スケジューラは、コンテキストを作業アイテムの集合とみなす必要がない。そうではなく、スケジューラは、実際にコンテキストをスケジューリングし、コンテキストは、コプロセッサの制御を得たならば、コプロセッサの制御を持ち続けることができる。いくつかの、例えば下記のイベントによって、プロセッサのコンテキスト制御を停止させることができる。
1)コプロセッサが、現在キューイングされているすべてのコマンドを完了する
2)コプロセッサが、無効なメモリアクセスによって引き起こされるページフォールトを生成する
3)スケジューラが、異なるコンテキストへの切り替えを要求する
4)コプロセッサが、DMAストリーム内の無効なコマンドに続いて無効動作割込みを生成する
【0115】
図16に、上記による、本発明のさまざまな実施形態を示す図が与えられている。図16を参照すると、左右に、第1のコンテキストの挿入から第2のコンテキストの挿入までの、同一のハードウェア環境での進行が示されている。左側では、スケジューラが、特定のDMAバッファをコプロセッサコンテキスト#1のリングに挿入するようにカーネルドライバに要求する。リングは、ドライバによって修正され、コプロセッサの末尾が更新されて、新しい値を参照するようになる。コプロセッサコンテキスト#1へのDMAバッファの挿入は、コプロセッサコンテキスト#1固有のロックの保護の下で行われる。したがって、他のスレッドは、他のコプロセッサコンテキストのリングにDMAバッファを挿入することができる。
【0116】
右側では、スケジューラが、コプロセッサコンテキスト#2のリングに特定のDMAバッファを挿入するようにカーネルモードドライバに要求する。しかし、このリングは既に満杯であり、したがって、スレッドBは、リングに空きができるまでブロックされる。スレッドBが待つという事実によって、スレッドAそれ自体のリングに新しいDMAバッファを挿入できなくなるのではないことに留意されたい。
【0117】
このモデルでは、各コンテキストが、実行されるDMAバッファの諸部分へのリダイレクトを含めることができるそれ自体のDMAリングを有する。サブミット時に、スケジューラは、サブミットされたDMAバッファをそのコンテキストのリングに追加することを試みることができる。リングが既に満杯である場合には、スケジューラは、もう1つのサブミットに十分なスペースがリングにできるまで待つことができる。この待機によって、サブミットされる特定のコンテキストへのさらなるサブミットだけがブロックされることに留意されたい。他のコンテキストへのサブミットは、ブロックされない。言い換えると、複数のスレッドが、それ自体のコンテキストに並列に作業アイテムを追加することができる。
【0118】
新しいDMAバッファを、実行中のコンテキストのキューに追加することができるので、コプロセッサは、コンテキストが空であることを報告する割込みを生成する前に、キューの末尾を再サンプリングすることができる。もちろん、コプロセッサがキューをサンプリングした直後にDMAバッファがキューに追加される可能性がある。しかし、割込み生成の直前のキューの末尾のサンプリングによって、これが発生する可能性が減り、スケジューリングの精度が高まる。スケジューラは、コンテキストが空であることを通知されたときに、実際にそうであるかどうかを知るために、ドライバに照会する。ドライバが、現在キューに入れられている、まだ処理されていないコマンドがあるかどうかを判定するために、保存されたコプロセッサコンテキストにアクセスすることができなければならない。図17に、このモデルを記述した擬似コードアルゴリズムを示す。
【0119】
後で詳細に説明するように、限定DMAバッファ対特権的DMAバッファという概念を導入して、システムセキュリティを危険にさらさずにユーザモードでDMAバッファを直接に構築できるようにすると同時に、カーネルモードドライバが特権的コマンドを含むDMAバファを構築できるようにする。
【0120】
このモデルによって表されるさまざまな実施形態を、本明細書の後の節で詳細に説明する限定メモリ対特権的メモリという概念と共に使用することができる。さしあたり、前に提示したメモリ仮想化モデルで、限定DMAバッファ対特権的DMAバッファによってアクセスできるメモリの間に区別がなく、すべての仮想メモリがアクセス可能なので、このモデルで問題が生じる可能性があることに留意されたい。これは、ページテーブルまたはリングバッファなどのメモリリソースを、コプロセッサ仮想アドレス空間を介して適当に可視にすることができないことを意味する。というのは、それによって、悪意のあるアプリケーションがページテーブルまたはリングバッファを上書きできるようになるからである。このゆえに、あるタイプのリソースについて物理アドレッシングをサポートし、他のタイプのリソースについて仮想アドレッシングをサポートするハードウェアを設計することができる。
【0121】
この問題に対する異なる手法が、特権的メモリという概念を追加することである。さまざまな実施形態で、特権的メモリに、特権的DMAバッファからのみアクセスでき、コプロセッサは、限定DMAバッファから特権的メモリ位置へのアクセスが試みられる場合に、ページフォールトを引き起こすことができる。その一方で、特権的DMAバッファからは、特権的メモリおよび非特権的メモリの両方に無差別にアクセスすることができる。特権的メモリをサポートするために、ハードウェアが、ハンドルごとに(ハンドルベース仮想化の場合に)またはページごとに(ページテーブルベースの仮想化の場合に)メモリが特権的であるかどうかを指定する機構を有しなければならない。
【0122】
特権的メモリをサポートするために、ページテーブルを有し、サーフェスレベルフォールトをサポートするコプロセッサは、もはや、メモリリソースのベースアドレスだけに基づいてフォールトすることができない。コプロセッサは、現在のリソースに含まれるすべてのページテーブルエントリを調べ、そのすべてが正しい保護ビットをセットされていることを確認しなければならない。メモリリソースの最初のページだけを検査することによって、潜在的に、悪意のあるアプリケーションが、限定DMAバッファで指定した限定メモリベースアドレスに続く特権的メモリにアクセスできるようになる。
【0123】
実行リスト
前に提示したデマンドフォールトモデルは、複数のイベントをシグナリングするために割込みを激しく使用する可能性がある。ページフォールトなど、これらのイベントの一部は、メモリ圧迫の下で非常に頻繁に発生する可能性がある。割込みが発生する時と、コプロセッサがCPUによって新しいタスクを与えられる時の間に、コプロセッサが長時間停止状態を生じる可能性がある。割込み待ち時間を隠蔽し、コプロセッサを動作状態に保つために、実行リストという概念が導入された。
【0124】
実行リストは、単に、CPUの介入なしにコプロセッサによって実行することができるコプロセッサコンテキストのリストである。コンテキストは、与えられた順序で、または本発明の実践に好都合であることがわかった任意の順序で実行することができる。コプロセッサは、たとえば下記など、本発明と共に実施できるさまざまな理由のいずれかについて、実行リスト内のあるコンテキストから次のコンテキストに切り替えることができる。
1)現在のコンテキストが空である、すなわち、行うべきことが残っていない。
2)現在のコンテキストが、ページフォールトを生成した。
3)現在のコンテキストが、一般保護フォールト(コプロセッサによってサポートされる場合に)を生成した。
4)コプロセッサが、新しい実行リストに切り替えることを要求された。
【0125】
さまざまな実施形態で、コプロセッサは、実行リスト内のあるアイテムから次のアイテムに切り替えるときに、CPUに割り込むが、停止せず、リスト内の次のアイテムにコンテキストを切り替えることができ、その実行を開始することができる。実行リストの先頭は、スケジューラが最初に実行を試みることができるコンテキストとすることができ、実行リストの他の要素は、部分的に、割込み待ち時間中にコプロセッサを動作状態に保つために置くことができる。CPUは、コプロセッサがリストの先頭から他に切り替えたことを知らせる割込みを受け取るや否や、新しい実行リストを構築し、コプロセッサに送ることができる。
【0126】
コプロセッサは、リストの先頭から切り替えるときに、生成した割込みがCPUに進む間に、実行リストの次のコンテキストの実行を開始することができる。CPUが生成する新しい実行リストの先頭は、コプロセッサが切り替えた先のコンテキストと異なる場合がある。その場合には、コプロセッサは、もう一度切り替える必要があり、そのコンテキストで有用な作業を行う時間がない場合がある。
【0127】
しかし、コンテキスト優先順位が、最後の実行リストが構築されてから変更されていないので、CPUによって構築される新しい実行リストの先頭のコンテキストを、前の実行リストの第2要素と同一にすることができる。その場合には、コプロセッサは、すでに正しいコンテキストの処理を意外に早く開始している。
【0128】
実行リストの概念を表す図を、図18に示す。実行リストが、本発明のさまざまな実施形態に含まれるときに、スケジューラの実行中コンテキストを、現在の実行リストによって置換することができる。保留中実行リストと称する第2の実行リストを導入して、実行リスト切り替えの同期化を単純にする。現在の実行リストは、ハードウェアが現在実行しているとスケジューラが仮定することができるコンテキストのリストであり、保留中実行リストは、スケジューラがある実行リストから別の実行リストにハードウェアを変更することを望むときに使用される過渡的な実行リストである。スケジューラは、新しい実行リストに切り替えることを望むときに、保留中実行リストを構築し、それに切り替えるようにコプロセッサに要求する。スケジューラが、コプロセッサが新しい実行リストの実行を開始したことの確認をコプロセッサから(割込みを介して)受け取ったならば、保留中実行リストが、新しい現在の実行リストになり、保留中実行リストを空にすることができる。
【0129】
保留中実行リストが空であるときに、ハードウェアは、現在の実行リストのコンテキストを実行しているか、アイドルである可能性がある。保留中実行リストが空でないときには、スケジューラは、遷移が行われたことの確認をコプロセッサから受け取るまで、ハードウェアが現在どの実行リストを実行しているかを知らない可能性がある。
【0130】
ある種のイベントは、スケジューラが実行リストの優先順位を付けなおすことを必要とする場合がある。たとえば、ページフォールトが解決され、高い優先順位のコプロセッサコンテキストの実行の準備ができる場合がある。そのようなイベントの同期化を単純にするために、スケジューラが従うことのできる一般的なルールは、前のイベントによってサブミットされた保留中実行リストがまだない場合に限って、新しい実行リスト(保留中実行リスト)をサブミットすることである。ある保留中リストの別の保留中リストへの置換の試みは、同期化が難しい。というのは、リストが、既にコプロセッサに与えられており、したがって、遷移がいつでも発生する可能性があり、スケジューラが、その事実の後でなければ通知されないからである。
【0131】
後者の場合に、実行リストの優先順位の付けなおしを、コンテキスト切り替えハンドラに委譲することができる。将来のある点で、保留中リストから実行中のリストへの遷移をシグナリングするためにハンドラを呼び出すことができ、その時点で、ハンドラが、優先順位が変更された場合に、新しい実行リストを生成して、ハードウェアに送ることができる。
【0132】
実行リスト切り替えの同期化。ある実行リストモデルでは、グラフィックスハードウェアが、コンテキストを切り替えるときに割込みを生成することができる。割込みの引渡および処理は、瞬間的ではないので、CPUが実際に割り込まれる前に複数の割込みが生成される可能性がある。同期化が正しく行われない場合に、スケジューラが混乱し、不正なスケジューリング判断を行う可能性がある。
【0133】
区別するようにスケジューラに指示することができる2つのクリティカルなイベントが、第1に、コプロセッサが実行リストの先頭から他に切り替えるときと、第2に、コプロセッサが保留中実行リストに切り替えるときである。このイベントを区別することは、各コンテキスト切り替えにおける単純な割込みからの情報だけでは困難になる可能性がある。この点をさらに示すために、次の例を検討されたい:コプロセッサが、現在、コンテキスト1−3−5−2からなる実行リストAを実行しており、スケジューラが、コンテキスト4−1−3−2からなる実行リストBに変更することを望む。下記の2つのシナリオが発生する可能性がある:
シナリオ#1
コプロセッサが、現在、実行リストA(1−3−5−2)を実行している。
コンテキスト4に関するコマンドがサブミットされるが、コンテキスト4は、アイドルであり、コンテキスト1より高い優先順位である。実行リストB(4−1−3−2)が生成され、スケジューラが、実行リストBをコプロセッサにサブミットする。
コンテキスト#1は、コプロセッサが、実行リストBからのコンテキスト#4に遷移するまで実行される。
コプロセッサが、遷移をシグナリングする割込みを生成する。
コプロセッサが、コンテキスト#4から#1に遷移し、その後、CPUが割り込まれる前に#3に遷移する。
CPUが、割り込まれ、コンテキスト切り替えハンドラが呼び出される。
ドライバが、現在のコプロセッサコンテキストをサンプリングするが、これは#3である。
【0134】
シナリオ#2
コプロセッサが、現在、実行リストA(1−3−5−2)を実行している。
コンテキスト4に関するコマンドがサブミットされるが、コンテキスト4は、アイドルであり、コンテキスト1より高い優先順位である。スケジューラが、実行リストBをコプロセッサにサブミットする。
スケジューラが、実行リストBを構築するのにビジーである間に、コプロセッサがコンテキスト#3に遷移する。
コプロセッサが、コンテキスト#3への遷移をシグナリングする割込みを生成する。
CPUが、割り込まれ、コンテキスト切り替えハンドラが呼び出される。
ドライバが現在のコプロセッサコンテキストをサンプリングするが、これは#3である。
【0135】
どちらの場合でも、コンテキスト切り替え割込みの時の現在実行されているコンテキストは、#3である。しかし、スケジューラは、追加情報がなければ、この2つのシナリオを区別できないことに留意されたい。第1のシナリオでは、コプロセッサが、実行リストBの先頭から切り替え、したがって、スケジューラは、実行リストCを生成し、それに切り替えるようにコプロセッサに要求する必要がある。しかし、第2のシナリオでは、第2の実行リストがまだ開始されておらず、したがって、スケジューラは待たなければならない。
【0136】
上の例から、コンテキスト切り替え割込みだけでは、スケジューリングモデルで実行リストを正しくサポートするのに十分でない場合があることが示される。このシナリオを区別するために、さらなる情報が必要である。次の節で、この問題に対処するいくつかの方法を、そのような問題に対処するのに有用にすることができるハードウェアサポートと共に詳細に説明する。
【0137】
2要素実行リスト。この同期化手法は、コプロセッサがある追加機能をサポートすることを必要とする。2要素実行リストの実施形態に関してサポートできる特徴の中に、下記がある。
1)2要素の実行リスト。
2)各コンテキスト切り替え(コンテキストXからXへのにせのコンテキスト切り替えを含む)に割込みを生成する能力。
3)VidMmが任意の時に現在実行されているコプロセッサコンテキストを照会する方法。
4)割込みの前に、進行中のコプロセッサコンテキストをメモリに保存すること。
5)スケジューラがコンテキスト切り替えの理由を判定できるようにするためにCPUによってコンテキストが可読になる方法でのコプロセッサコンテキストの保存。
【0138】
ハードウェアを使用して上の機能をサポートすることができるが、スケジューラが通常のコンテキスト切り替えと実行リスト切り替えを区別できるようにするのに、そのような特殊なハードウェアが必要ではないことに留意されたい。代わりに、スケジューラは、実行リストを構成するときに単純なルールの組を必ず守ることによって、この2つのイベントを区別することができる。特定のルールは、本発明のさまざまな実施形態について変化する可能性があるが、この機能をもたらす例示的なルールは、第1に、現在の実行リストの最初のコンテキストが、新しい保留中実行リストに現れることができないことと、第2に、現在の実行リストの第2のコンテキストが、新しい保留中実行リストの先頭でない場合に、新しい保留中実行リストにこれを含めてはならないことである。下に、この2つの例示的ルールに従うときに、スケジューラが、あるコンテキストから別のコンテキストへの遷移中に行う仮定の表を示す。下の表では、実行リストAが、コンテキスト1−2からなり、第2の実行リストBが、コンテキスト2−3からなり、第3の実行リストCが、コンテキスト3−4からなる。
【0139】
【表6】
【0140】
【表7】
【0141】
実行リストを実施するこの方法は、おそらく最も単純であり、必ずしもかなりの追加ハードウェアサポートを必要としない。しかし、上の表の実行リストが、サイズを制限され(2を超えるサイズの拡張は、実用的でなくなる可能性がある)、クリティカルでないいくつかの情報が、コンテキスト切り替え中に失われる可能性があることに留意されたい。たとえば、スケジューラが、必ずAからCへの遷移でコンテキスト#2が実行されたかどうかを知るとは限らない。それが実行され、ページフォールトを引き起こしたが、別のコンテキスト切り替えによって割込みを隠される可能性がある。その場合に、スケジューラは、コンテキスト#2がフォールトを生成したことを知らず、再スケジューリングする。
【0142】
スケジューリングイベントのコプロセッサトレース。実行リストは、スケジューリング情報のあるヒストリ情報がハードウェアによってスケジューラに供給されるときに、簡単にサイズNまで拡張することができる。単純な割込みの問題の1つが、複数の割込みが一緒に強制される可能性があることであり、何がおきて割込みが引き起こされたかを正確に判定できない可能性があることである。これは、本発明の方法と共に、ハードウェア機能によって対処することができる。より具体的には、コンテキスト切り替えヒストリを、スケジューラによって可読の指定されたシステムメモリ位置に書き込むことができるハードウェアを実施することによって対処することができる。本発明のこの態様を説明するために、下記のシナリオを検討されたい。
【0143】
1)スケジューラが、実行リストA(1−2−3−4−5)をスケジューリングする。
2)コンテキスト#1のタイムカンタムが満了し、スケジューラが、新しい実行リストB(2−3−4−5−1)を送る。
3)CPUでカンタム満了を処理している間に、コプロセッサが、コンテキスト#1が空になるのでコンテキスト#1について完了し、したがってコンテキスト#2に遷移する。コプロセッサは、このイベントについてコンテキスト切り替え割込みを生成した。
4)コプロセッサが、新しい実行リストに関する通知をCPUから受け取り、したがって、それに遷移した。コプロセッサが、このイベントに関するコンテキスト切り替え割込みを生成した。
5)新しい実行リストのコンテキスト#2のレンダリングコマンドを処理している間に、コプロセッサが、ページフォールトに出会い、したがって、コンテキスト#3に遷移した。コプロセッサが、このイベントに関するコンテキスト切り替え割込みを生成した。
6)コンテキスト#3が、ページフォールトを発生し、したがって、コプロセッサが、コンテキスト#4に切り替えた。コプロセッサが、このイベントに関するコンテキスト切り替え割込みを生成した。
7)CPUが、最終的にコンテキスト切り替えについて割り込まれる。最初の割込みが送出されて以来、4つのコンテキスト切り替えが実際に発生した。
【0144】
図19に、上のシナリオでのハードウェアヒストリ機構の動作を示す。そのようなヒストリ機構をサポートするために、下記のタスクを実行できるようにハードウェアを構成することができる。これらのタスクは、制限ではなく例として提供される。
【0145】
1)ヒストリバッファのベースアドレスを指定する。コプロセッサごとに単一のヒストリバッファを設けることができる。好ましい実施形態では、これを、PCIメモリまたはAGPメモリのいずれかのシステムメモリ位置とすることができる。これを、オペレーティングシステムによって4KB境界に整列することができる。PCI expressシステムについて、このバッファへのアクセスは、スヌープサイクルを用いて実施することができ、したがって、システムメモリバッファを、より効率的なCPU読取のためにキャッシュ可能にすることができることが好ましい。
【0146】
2)ヒストリバッファのサイズを指定する。ヒストリバッファは、実行リストのサイズの少なくとも2倍の長さとすることができる。これは、現在の実行リストおよび保留中実行リストの両方が、割込みが発生する前に完了する、ワーストケースシナリオを処理するのに十分なスペースがバッファ内にあることを保証するためである。
【0147】
3)コプロセッサ書込ポインタを指定するが、これはヒストリバッファに書き込まれた最後のイベントの直後のアドレスとすることができる。VidMmは、コプロセッサが稼動している時を含めて、いつでもこのポインタを照会できるものとすることができる。スケジューラが常にコヒーレントなデータを得ることを保証するために、ポインタが更新される前に、ヒストリバッファ内のデータをメモリに正しくフラッシュすることができる。
【0148】
さまざまな実施形態によって、ユーザモードで構築されるDMAバッファから不可視になるようにヒストリバッファを構成することができる。ヒストリバッファが、限定DMAバッファから可視の場合には、悪意のあるアプリケーションが、ヒストリバッファを上書きし、スケジューラを壊し、おそらくはシステムクラッシュまたはさらに悪い結果をもたらすことができる。このゆえに、これらの実施形態のヒストリバッファは、物理アドレスを介してハードウェアによって参照される、または特権的DMAバッファだけに可視の仮想アドレスを介して参照されるのいずれかとすることができる。これらの実施形態では、コプロセッサが、CPU介入なしでヒストリバッファの末尾でラップアラウンドすることを要求することができる。
【0149】
上で説明した実施形態による実行リストによって、コプロセッサが同一の理由で同一のコンテキストで複数回フォールトできるようするための必要のすべてが除去されるわけでないことに留意されたい。これの理由の1つが、スケジューラが、一般に、コプロセッサが現在の実行リストの実行でビジーである間に新しい実行リストを構築することである。スケジューラは、前の実行リストに既に存在するコンテキストを新しい実行リストに含める必要がある場合があるので、繰り返されるコンテキストの状態が、構築される実行リストに置かれた時と、実行リストがコプロセッサにサブミットされた時の間に変化する可能性があることがありえる。
【0150】
限定DMA対特権的DMA
高度なスケジューリングモデルでのメモリ保護の導入に伴って、コプロセッサに送られるDMAバッファが、主として、実行中のアプリケーションのプロセス内部のユーザモードドライバによって構築される可能性がある。これらのDMAバッファは、アプリケーションのプロセス内でマッピングされる可能性があり、ユーザモードドライバは、これらに直接に書き込むことができるが、カーネルドライバは、これを確認することができない。DMAバッファは、誤ってその仮想アドレスにアクセスするアプリケーションによって、または悪意のあるアプリケーションによって故意に、書き込まれる可能性がある。ドライバモデルがセキュアであることを可能にするために、すなわち、アプリケーションが、するべきではないリソースにアクセスできなくするために、ユーザモードで構築されるDMAバッファを、行うことが許可されるものに関して制限することができる。具体的に言うと、ユーザモードで構築されるDMAバッファは、下記の例示的な方法で制限された機能性を有することができる。
【0151】
1)仮想アドレスへの参照だけを含めることができ、物理アドレスへの参照はまったく(フェンスを含めて)含めることができない。
2)現在のディスプレイ(たとえば、CRT、随意アクセス制御(DAC)、Technical Document Management System(TDMS)、Television−Out Port(TV−OUT)、Inter−Integrated Circuit(I2C)バス)に影響する命令を含めることを許可されることができない。
3)アダプタ全般(たとえば位相ロックループ(PLL))に影響する命令を含めることができない。
4)限られた電源管理および/または構成スペースを有することができる。
5)コンテキスト切り替えを防ぐ命令を含めることを許可されることができない。
【0152】
ユーザモードで構築されるDMAバッファでプログラム可能なレジスタの正確な組は、ハードウェアによって変化する可能性が高い。しかし、ハードウェアにかかわらずに、レジスタが一般的な規則に従うことができる、すなわち、そのようなDMAバッファは、リソースおよびフェンスへの仮想アドレス参照を使用するレンダリング動作だけを許可しなければならない。強化されたセキュリティをもたらすために、そのようなDMAバッファに、アプリケーションがアクセスするべきではないメモリ、またはある潜在的に破滅的で回復不能な方法でハードウェアに影響することができるメモリをアプリケーションが使用することを許可しないことを要求することができる。
【0153】
ユーザモードで構築されるDMAバッファが、ある機能性にアクセスできなくするために、複数の手法をコプロセッサ内で実施することができる。これらの手法は、機能性の性質および機能性がアプリケーションのコプロセッサコンテキストストリームにキューイングされる必要があるかどうかに非常に依存する。ある種の特権的動作は、一般に、ユーザモードで構築されるDMAバッファ(たとえばアプリケーションレンダリング)およびカーネルモードで構築されるDMAバッファ(たとえばキューイングされたフリップ)の両方を含むコプロセッサコンテキストストリーム内でキューイングされることを必要とする。
【0154】
キューイングされる必要がない機能性。ほとんどの特権的機能性は、アプリケーションコプロセッサコンテキストストリームでキューイングされることを必要としない。下記などの機能性は、キューイングされることを必要としない。
1)CRTタイミングのプログラミング。
2)DACのルックアップテーブルの更新(DAC LUTのプログラミングが、特権的機能性である必要が絶対にないことに留意されたい。というのは、どのアプリケーションでも、望むならば、プライマリスクリーンにレンダリングすることができ、ルックアップテーブル(LUT)の再プログラミングによって、そうでなければアクセスできない情報へのアクセスをアプリケーションがユーザに与えられるようにはならないからである。
3)ディスプレイ出力のプログラミング(TDMS、TV−OUT、…)
4)子デバイス/モニタとの通信(I2C、…)
5)クロックのプログラミング(PLL)
6)コプロセッサの電源状態の変更
7)コプロセッサの構成(構成スペース、BIOS、…)
【0155】
この機能性は、通常は、アプリケーションレンダリングストリームと完全に独立のシステムイベント(たとえば、ブート、解像度変更、pnp検出、電源管理)の後に必要になる。したがって、この機能性は、特定のアプリケーションのコプロセッサコンテキストでキューイングされることを必要としない。この機能性は、特定のシステムイベントが発生しているときに、ユーザモードドライバからの介入を一切伴わずに、カーネルモードドライバ自体によって使用することができる。
【0156】
そのような機能性について、IHVは、メモリマップ式入出力(MMIO)だけを介して基礎になるレジスタのすべてをアクセス可能にすることを決定することができる。レジスタは、一般に、カーネル空間だけにマッピングされるので、アプリケーションまたはユーザモードドライバがそれにアクセスすることを不可能にすることができ、したがって、この機能性が有効に保護される。
【0157】
もう1つの手法は、コプロセッサコンテキストごとの特権レベルを実施することである。この手法では、コンテキストに、行えることを制限されるものと、そうでないものがある。そのシナリオでは、ユーザモードで構築されるアプリケーションのDMAバッファが、限定コンテキストにキューイングされる。その一方で、カーネルモードドライバは、特権的コンテキストを使用して、特権的機能性をサブミットすることができる。
【0158】
キューイングされることを必要とする機能性。ユーザモードで構築されるDMAバッファに挿入できるコマンドは限られているので、コプロセッサが限定DMAバッファ(前の条件を遵守するDMAバッファ)および特権的DMAバッファの両方をサポートすることを要求するように、高度なモデルを実施することができる。特権的DMAバッファは、コプロセッサコンテキストのレンダリングストリームに沿った特権的機能性のキューイングを可能にするために必要である。
【0159】
特権的DMAバッファには、非特権的DMAバッファに見られる命令のどれでも含めることができる。本発明のさまざまな好ましい実施形態によって、下記(後の節で詳細に説明する)を少なくとも可能にする特権的DMAバッファを実施することができる。
1)特権フェンスの挿入
2)フリップ命令の挿入
3)「コンテキスト切り替えなし」領域の挿入
【0160】
さらに、特権的DMAバッファによって、IHVが望むすべてのハードウェアレジスタをプログラムすることができ、必要な場合に仮想メモリおよび物理メモリの両方にアクセスすることができる。特権的DMAバッファは、ユーザモードで構成することができず、可視にすることもできない。信頼されるカーネルコンポーネントだけが、特権的DMAバッファにアクセスでき、これを構築することができる。
【0161】
次の節に、特権的DMAバッファを実施する可能な3つの方法を示すが、次の節は、本発明を実施できるさまざまな方法を制限せずに、特権的DMAバッファの実施という概念を説明することを意図されたものである。
【0162】
1.DMAバッファは、カーネルモードでのみ構築される
特殊なハードウェアサポートを必要としない特権的DMAバッファをサポートする方法の1つが、ハードウェアに送られる実際のDMAバッファをカーネルモードで構築することを要求することである。このシナリオでは、ユーザモードドライバが、DMAバッファによく似たコマンドバッファを構築し、カーネルモードドライバにサブミットする。カーネルモードドライバは、このコマンドバッファを確認し、カーネルモードでのみ可視のDMAバッファにコピーする。確認中に、カーネルモードドライバは、特権的命令が存在しないことを検証する。これは、基本モデルで要求される確認に似ているが、メモリが仮想化されるので、メモリアクセスに関する確認は不要である。
【0163】
2.リングへの直接の特権的コマンドの挿入
おそらく、特権的DMAチャネルをサポートする最も簡単なハードウェア手法は、特権的コマンドをコプロセッサコンテキストリングに直接に挿入することである。リング自体は、既に特権的チャネルであり、カーネルモードからのみアクセス可能である。これを、図20の図に示す。
【0164】
3.間接参照を介する特権の指定
コプロセッサ内で限定DMAバッファ対特権的DMAバッファをサポートする異なる手法を、図21に示す。これを参照して、開始アドレスおよび終了アドレスの両方をDWORDに整列できることに留意されたい。アドレスの未使用ビットは、フラグの指定に再利用することができる。開始アドレスの第1ビットによって、リダイレクトされるDMAバッファが特権的DMAバッファであることを指定することができる。セキュリティを強化するために、特権的DMAバッファによって、補助メモリ内の物理アドレスを参照することができる。限定DMAバッファによって、コプロセッサコンテキスト仮想アドレス空間内の仮想アドレスを参照することができる。
【0165】
この手法では、間接参照コマンドの1ビットを、リングバッファに挿入することができる。このビットによって、実行されるDMAバッファが特権的DMAバッファであるか否かが示される。これは、リングバッファ自体を、コプロセッサによって物理アドレスを使用して参照することができ、コプロセッサ仮想アドレス空間内で不可視にすることができることを意味する。プライマリリングバッファをコプロセッサ仮想アドレス空間内で可視にすることを許可することによって、悪意のあるアプリケーションが、プライマリリングバッファを上書きできるようになり、特権レベルでコマンドを実行できるようになり、これは、実質上、ほとんどのコンピューティング環境でのセキュリティ侵害と等しい。これに関して、特権的DMAバッファを、物理アドレスを介して参照し、限定DMAバッファのように仮想アドレスで可視でなくすることができる。
【0166】
DMA制御命令
スケジューラおよび補助メモリマネージャが、コプロセッサコンテキストの進行を追跡し、そのコンテキストのDMAストリーム内の命令のフローを制御するために、DMAストリーム内で下記の例示的命令をサポートするようにコプロセッサを構成することができる。
1)フェンス(限定および特権的の両方)
2)トラップ
3)コンテキスト切り替えの許可/禁止
【0167】
フェンス。フェンスは、DMAストリームに挿入することができる、あるデータ(たとえば64ビットのデータ)およびアドレスの両方を含む命令とすることができる。この命令が、コプロセッサによってストリームから読み取られるときに、コプロセッサが、フェンスに関連するデータを指定されたアドレスに書き込む。コプロセッサは、フェンスのデータをメモリに書き込む前に、フェンス命令に先立つプリミティブからのピクセルが、回収され、既にメモリに正しく書き込まれていることを保証しなければならない。これが、コプロセッサがパイプライン全体を停止させることを必要とすることを意味しないことに留意されたい。フェンス命令に続くプリミティブは、コプロセッサがフェンスの前の命令の最後のピクセルが回収されるのを待っている間に実行することができる。
【0168】
上の説明にあてはまるフェンスのすべてを、本発明と共に使用することができるが、特に2タイプのフェンスすなわち、通常のフェンスおよび特権的フェンスを本明細書でさらに説明する。
【0169】
通常のフェンスは、ユーザモードドライバによって作成されたDMAバッファに挿入できるフェンスである。DMAバッファの内容は、ユーザモードから来るので、信頼されない。したがって、そのようなDMAバッファ内のフェンスは、そのコプロセッサコンテキストのアドレス空間の仮想アドレスを参照することができるが、物理アドレスを参照することはできない。そのような仮想アドレスへのアクセスが、コプロセッサによってアクセスされる他の仮想アドレスと同一のメモリ確認機構によって束縛されることは言うまでもない。
【0170】
特権的フェンスは、カーネルモードで作成された(カーネルモードでのみ可視の)DMAバッファに挿入することだけができるフェンスである。そのようなフェンスは、システムのセキュリティを高めるために、メモリ内の物理アドレスを参照することができる。フェンスのターゲットアドレスが、コプロセッサコンテキストのアドレス空間内で可視である場合には、悪意のあるアプリケーションが、そのメモリ位置に対してグラフィック動作を実行でき、したがって、カーネルモードコードが受け取ることを期待する内容をオーバーライドすることができる。潜在的なセキュリティ問題に対するもう1つの解決策が、非特権的DMAバッファから仮想アドレスにアクセスできるかどうかを示す、PTE内の特権ビットを有することである。しかし、上の第1の手法は、早期のハードウェア生成についてより単純と思われる。
【0171】
特権的DMAバッファに、通常のフェンスと特権的フェンスの両方を含めることができることに留意されたい。しかし、特権的DMAバッファに通常のフェンスが含まれるときに、DMAバッファを生成するカーネルコンポーネントに、それが挿入したフェンスが絶対に可視にならないことがわかっている。
【0172】
IHVは、フラッシュを必要とする内部バッファの数を最小にするために、余分なタイプのフェンスをサポートすると決定することができる。下記のタイプのフェンスは、この目的のためにサポートすることができるフェンスの例である(すべてのタイプについて、特権的および非特権的の両方をサポートしなければならないことに留意されたい):
1.書込フェンス
書込フェンスは、前に説明したタイプのフェンスであり、唯一の必要なフェンスタイプである。書込フェンスによって、フェンス命令の前に処理されるすべてのメモリ書込が、グローバルに可視になる(すなわち、それらがキャッシュからフラッシュされ、メモリコントローラから肯定応答が受け取られている)ことが保証される。
【0173】
2.読取フェンス
読取フェンスは、書込フェンスに似た、より軽いタイプのフェンスである。読取フェンスによって、フェンスの前のレンダリング動作に関するメモリ読取のすべてが終了することが保証されるが、一部の書込が、まだ未解決である可能性がある。読取フェンスがサポートされる場合には、スケジューラは、これを使用して、非レンダターゲット割り当ての寿命を制御する。
【0174】
3.トップオブパイプ(top−of−pipe)フェンス
トップオブパイプフェンスは、非常に軽量のフェンスである。トップオブパイプフェンスのサポートは、任意選択である。トップオブパイプフェンスによって、DMAバッファ内でフェンス命令の前の最後のバイトが、コプロセッサによって読み取られた(必ずしも処理されていない)ことだけが保証される。コプロセッサは、フェンスが処理された後に(そのDMAバッファンの内容がもはや有効でなくなるので)、DMAバッファのうちでトップオブパイプフェンスに先立つ部分を再読み取りしない場合がある。サポートされる場合に、このタイプのフェンスは、DMAバッファの寿命を制御するのにスケジューラによって使用される。
【0175】
トラップ。トラップは、本発明のさまざまな実施形態で実施することができる。トラップは、コプロセッサによって処理されるときにCPU割込みを生成できる、DMAバッファに挿入された命令とすることができる。コプロセッサがCPUに割り込む前に、トラップ命令に先立つプリミティブからのすべてのピクセルが、回収され、メモリに正しく書き込まれていることを保証する(フェンス命令からのメモリ書込を含むことができる動作)ことが賢明である。これが、コプロセッサがパイプライン全体を停止させる必要があることを意味しないことに留意されたい。トラップ命令に続くプリミティブは、コプロセッサがトラップの前の命令の最後のピクセルが回収されるのを待っている間に実行することができる。
【0176】
トラップ命令は、特権的命令である必要はなく、ユーザモードドライバによって直接に構築されるものを含むすべてのDMAバッファに挿入することができる。
【0177】
コンテキスト切り替えの許可/禁止。サブトライアングル(sub−triangle)割込みをサポートするハードウェアについて、コンテキスト切り替えを許可または禁止する命令を設けることができる。コンテキスト切り替えが禁止されている間は、コプロセッサは、一般に、現在のコプロセッサコンテキストから切り替えてはならない。コプロセッサは、CPUによって新しい実行リストが提供される場合に現在の実行リストの情報を更新することを要求される場合があるが、コプロセッサは、コンテキスト切り替えが再度許可されるまで、新しい実行リストへのコンテキスト切り替えを延期することができる。OSは、コンテキスト切り替えが禁止されているときに下記のルールが残ることを保証することができる。
1)特権的DMAバッファだけが処理される。
2)コンテキスト切り替え命令がDMAストリームに存在しない。
3)DMAストリームの命令が使い果たされない。
4)ページフォールトが発生しない(ページレベルフォールトがサポートされる場合)。
【0178】
多くのコンピュータシステムで、コンテキスト切り替えの禁止および許可は、特権的DMAバッファ内にのみ存在することができる特権的命令である。これらの命令の使用のシナリオでは、割り込まれる可能性なしで、スケジューラがスクリーンに現れる動作(すなわちプレゼンテーションブリット)をスケジューリングできるようになる。そのような動作で割り込まれることは、容易に目につく時間期間にわたる画面上の可視のアーチファクトにつながる可能性がある。
【0179】
コプロセッサが、DMAバッファ内で不測のエラーに出会う場合に、コンテキスト切り替えが禁止されていても、このDMAバッファからコンテキストを切り替えることができることに留意されたい。カーネルモードで構築されるDMAバッファだけに、割込み不能部分を含めることができるので、不測のエラーは、ドライバのバグまたはハードウェアのバグの結果である。コプロセッサが、これらのシナリオでコンテキストを切り替えない場合には、ディスプレイウォッチドッグがハングを把握し、システムを回復するためにコプロセッサをリセットする。
【0180】
任意選択の制御命令。スケジューラは、上で説明した単純な制御命令を用いて高水準同期化プリミティブを構築することができるが、その結果を、さらに効率的にすることができる。多くのコンピュータシステムで、コプロセッサコンテキストは、同期化オブジェクトの所有権を得る前にCPUによって割り込まれる。同期化オブジェクトが高い頻度で取られ、解放される場合に、これが問題になる可能性がある。より効率的な同期化プリミティブを有するために、スケジューラは、コプロセサから特殊な命令を受け取ることができる。具体的に言うと、「ウェイト」命令および「シグナル」命令を適当な時に送出するようにコプロセッサを構成することができる。
【0181】
ウェイト命令は、指定されたカウンタの値を検査できることをコプロセッサに知らせるためにDMAストリームに挿入される。カウンタが非ゼロの場合には、コプロセッサは、カウンタを減分し、現在のコプロセッサコンテキストの実行を継続する。カウンタがゼロの場合には、コプロセッサは、現在のコプロセッサコンテキストの命令ポインタをウェイト命令の前にリセットし、実行リストの次のコンテキストに切り替える。コプロセッサコンテキストが、ウェイト命令で停止する必要があり、後に再スケジューリングされるときに、コプロセッサは、そのウェイト命令を再実行することができる。というのは、ウェイト条件がまだ満足されていない可能性があるからである。
【0182】
ウェイト命令は、1つのパラメータすなわち、比較/減分されるメモリ位置を指定する仮想アドレスを有することだけを必要とする。カウンタは、少なくとも32ビットとすることができ、任意の有効な仮想アドレスとすることができる。好ましい実施形態では、ウェイト命令を割込み不能とすることができる、すなわち、新しい実行リストがコプロセッサに与えられる場合に、コプロセッサは、ウェイト命令の前またはそれを実行した後のいずれかに新しい実行リストに切り替えることができる。ウェイト命令は、限定DMAバッファおよび特権的DMAバッファの両方に挿入することができる。
【0183】
シグナル命令は、カウンタの値を更新できることをコプロセッサに知らせるためにDMAストリームに挿入することができる。コプロセッサは、カウンタの値を1つ増分することができる。コプロセッサは、加算中の潜在的なオーバーフローを無視することができる。その代わりに、コプロセッサが、ソフトウェアバグを追跡するのを助けるために、ストリーム内のエラーとしてオーバーフローを報告することができる。
【0184】
シグナル命令は、1つのパラメータすなわち、更新されなければならないカウンタの仮想アドレスだけを有することを必要とする。カウンタサイズは、ウェイト命令のカウンタサイズと一致するようにすることができ、好ましい実施形態では、少なくとも32ビットである。シグナル命令は、限定DMAバッファおよび特権的DMAバッファの両方に挿入することができる。
【0185】
フリップ
全画面アプリケーションが、パイプライン内のバブルなしでシームレスに動作できるようにするために、コプロセッサによって、フリップ(すなわち、ディスプレイのベースアドレスの変更)をキューイングする命令を提供することができる。ディスプレイサーフェスは、一般に、物理モデルから連続的に割り当てられ、仮想アドレスではなく物理アドレスを使用してCRTCによって参照される。したがって、フリップ命令を使用して、CRTCを、表示される新しい物理アドレスにプログラムすることができる。これは、物理アドレスであって仮想アドレスではないので、不良アプリケーションが、潜在的に、補助メモリのうちで別のアプリケーションまたはユーザに属する部分(秘密が含まれる可能性がある)を表示するようにCRTCをプログラムすることができる。このため、フリップ命令を実施して、宛先が確認されてからカーネルモデルドライバによってのみDMAストリームに挿入される特権的命令であることを保証することによって、ほとんどのコンピュータシステムのセキュリティを保護することができる。
【0186】
フリップ機能と共に使用される本発明のさまざまな好ましい実施形態で、少なくとも2つのタイプのフリップ、すなわち、即時フリップおよびディスプレイリフレッシュと同期したフリップがサポートされる。コプロセッサは、即時フリップを処理するときに、可視のティアリング(tearing)が引き起こされる場合であっても、ディスプレイのベースアドレスを即座に更新することができる。コプロセッサは、同期式フリップを処理するときに、新しいベースアドレスをラッチすることができるが、次の垂直同期期間まで更新を延期する。垂直同期期間の間にコプロセッサによって複数の同期式フリップが処理される場合に、コプロセッサは、最新のフリップだけをラッチし、前のフリップを無視することができる。
【0187】
同期式フリップを処理するときに、コプロセッサがグラフィックスパイプラインを停止させないように、さまざまな実施形態を構成することができる。OSは、現在可視のサーフェスに描画するレンダリングコマンドがリングバッファにキューイングされないことを保証する。ここで、下でさらに説明する「最適化されたフリップ」の情況で、これらの要件なしで他の実施形態を構成できることに留意されたい。
【0188】
どのサーフェスが現在可視であるかを判定するために、ドライバは、まず、特定のキューイングされたフリップが行われたときを判定することができ、そのイベントについてスケジューラに通知する、すなわち、ディスプレイベースアドレスが変更された後にスケジューラに通知することができる。即時フリップについて、フリップが行われたときを判定するのは簡単である。というのは、DMAストリームからのフリップ命令の読取を、ディスプレイサーフェスの更新と同一のイベントとみなすことができるからである。DMAストリーム内でフリップ命令の後にフェンスおよび割込みを挿入して、特定のフリップが読み取られたことをスケジューラに通知することができる。
【0189】
同期式フリップの場合には、どのサーフェスが現在可視であるかの判定が、より困難である。コプロセッサは、まず、DMAストリームからフリップ命令を読み取るが、後に、次の垂直同期期間にディスプレイサーフェスを更新する。その時にコプロセッサを停止させる必要をなくすために、ディスプレイサーフェス変更が有効になるときをスケジューラに通知する機構を設けることができる。
【0190】
本発明と共に使用されるそのような通知の機構を設計する複数の方法がある。1つの潜在的に単純な手法を、図22に示す。図22に、現在のディスプレイサーフェスに関してコプロセッサに照会する方法を示す。図示の実施形態では、この機能を、MMIOレジスタによって提供されるものと考えることができる。図22のシステムは、最新の「ラッチ式ディスプレイサーフェス」ではなく、レジスタによって実際のディスプレイサーフェスが読み取られるときに、より高い信頼性につながる設計である。最新のラッチされたディスプレイサーフェスの照会は、コプロセッサが別のキューイングされたフリップを処理する、競争状態をもたらす可能性があり、これは画面のティアリングにつながる可能性がある。フリップ命令は、適当な技法を使用して生成することができる。本発明との互換性に関する唯一の一般的な要件は、実施される解像度によって、フリップが、有効になるまで肯定応答されないことを保証することである。
【0191】
フリップのキューイング。最大限の性能を実現するために、高度なスケジューリングモデルを修正して、モニタを所有するアプリケーションのレンダリングストリームにフリップ動作をキューイングすることができる。nバッファリングを行うときに、スケジューラは、n−1個までのフリップをDMAストリームにキューイングすることを許可でき、n番目のフリップが挿入されようとするときにブロックすることができる。
【0192】
これが意味するのは、ダブルバッファリングにおいて、スケジューラが、アプリケーションが1つのフリップをキューイングするのを許可することができ、コプロセッサが現在のフレームのレンダリングおよびそのフリップの処理/肯定応答を終了する間に次のフレームのDMAバッファの準備を継続させることができることである。これは、アプリケーションが、次のフレームのDMAバッファの準備を終了し、第2のフリップをサブミットする時まで、第1のフリップがコプロセッサによって肯定応答されるまでアプリケーションをブロックできることも意味する。
【0193】
即時フリップが、スケジューラによって使用されるときに、フリップをキューイングする機構は、上で説明したように働く。しかし、同期式フリップを使用するときには、スケジューラは、フリップn−1を超えてキューイングされるDMAバッファも特別に処理することができる。実際、フリップを超えるDMAバッファは、一般に、現在可視のサーフェスにレンダリングされる。ほとんどのシステムで、現在キューイングされているフリップの数がn−2以下になるまで、これらのDMAバッファを処理しないことが賢明である。
【0194】
この問題に対処する最も単純な手法は、n−1個ではなく、n−2個のフリップだけをキューイングできるようにすることである。しかし、この解決策は、ダブルバッファリングの場合に、フリップをキューイングできず、したがって、対応するフリップが処理されるまで、各フレームが完了した後にアプリケーションをブロックする必要があることも意味する。
【0195】
この設定での好ましい手法を、図23に示す。図からわかるように、n−1個のフリップのキューイングが、許可される。フリップn−1の後にキューイングされたDMAバッファが実行されないようにするために、スケジューラは、そのコプロセッサコンテキストについて仮想リングバッファにDMAバッファを累積することができる。スケジューラは、現在キューイングされているフリップの数がn−2に減るまで待って、これらのフリップをそのコプロセッサコンテキストの実際のリングにサブミットする。
【0196】
同時に複数のアプリケーションが動作しているときに、コプロセッサは、図23に示されているように停止する必要がない場合がある。コプロセッサは、一般に、特定のコプロセッサコンテキストからのDMAバッファの処理を停止するが、スケジューラは、実行される他のコプロセッサコンテキストをスケジューリングすることができ、効果的にコプロセッサをビジーに保つ。しかし、単一のアプリケーションが実行されているとき、たとえば、全画面ゲームをプレイしているときに、コプロセッサは、これらのインターバル中に停止する可能性がある。次の節で、サポートされる場合に停止時間を減らすためにスケジューラによって使用される機構を説明する。
【0197】
最適化されたフリップ。全画面アプリケーションについて最適化することを試みて、コプロセッサが停止するのに要する時間を最小限に減らすことが望まれる。図23を参照して、コプロセッサが、少なくとも2つの理由で停止する可能性があることを観察されたい:その理由は、第1に、フレームが完了したが、システムがフリップのためにvsyncを待っているため、第2に、フリップが完了したが、システムがCPUに通知するための割込みを待っているため、である。
【0198】
第1の理由に起因する停止を減らすために、より多くのバッファを、フリップのチェーンに追加することができる。たとえば、ダブルバッファからトリプルバッファに移ることによって、そのような停止が大幅に減る。しかし、これを行うことは、必ずしもドライバの制御下ではなく、不当なメモリ消費がもたらされる場合がある。
【0199】
第2の理由に起因する停止を減らすために、この停止の必要を完全に除去するためにコプロセッサ機構を追加することが可能である。コプロセッサは、前にキューイングされたフリップが処理されるまでコプロセッサを停止させるウェイトオンフリップ命令を提供することができる。そのような命令がサポートされるときに、スケジューラは、フリップをキューイングするために全画面アプリケーションについてその命令を使用することができ、CPUは、各フリップの後でDMAストリームを再開する必要がなくなる。
【0200】
高水準の同期化オブジェクト
前に定義した制御命令を使用して、スケジューラによって、クリティカルセクションおよびミューテクスなどの高水準の同期化オブジェクトを構築することができる。スケジューラは、待機の条件が満たされたならば、CPUによって明示的に再スケジューリングされるまで、選択されたDMAバッファを実行されないように保護することによって、そのような同期化プリミティブを実施することができる。オブジェクトの待機は、フェンスなど、スケジューラによって実施することができる。論理的にフェンスに続くDMAバッファを、スケジューラによってキューイングすることができるが、待機条件が満たされるまで、コプロセッサコンテキストのリングにサブミットすることはできない。オブジェクトを待つようになったならば、シグナリングされるまで、スケジューラによってコプロセッサコンテキストをその特定のオブジェクトのウェイトリストに移動することができる。コプロセッサコンテキストDMAストリームに、割込みコマンドが続くフェンスを挿入することによって、オブジェクトにシグナリングすることができる。そのような割込みを受け取るときに、スケジューラは、どのオブジェクトがシグナリングされているかを識別し、待っているコプロセッサコンテキストをレディキューに戻さなければならないかどうかを判定することができる。コプロセッサコンテキストをレディキューに戻すときに、スケジューラは、リングからしまわれたDMAバッファを挿入する。
【0201】
たとえば、アプリケーションが、生産者(プロデューサ)と消費者(コンシューマ)の間で共有されるサーフェスを有し、アプリケーションが、リソースへのアクセスを同期化し、その結果、コンシューマがレンダリング中に必ず有効な内容を使用するようにする必要がある、本発明の実施形態を検討されたい。このシナリオを同期化する1つの潜在的な方法を、図24に示す。
【0202】
図24に移ると、スケジューラ側で、同期化を、たとえば下記のカーネルサンクスを介して実施することができ、このカーネルサンクは、任意の組合せでまたは他のアクションと組み合わせて実施することができる。
1)CreateSynchronizationObject:同期化オブジェクトのカーネル追跡構造体を作成する。後続の待機/解放/削除呼出しで使用することができるオブジェクトへのハンドルをユーザモードに返す。
2)DeleteSynchronizationObject:前に作成されたオブジェクトを破棄する。
3)WaitOnSingleObject/WaitOnMultipleObject:現在のコプロセッサコンテキストのDMAストリームに同期化待機イベントを挿入する。待たれているオブジェクトへの参照と共にイベントをスケジューライベントヒストリに挿入する。
4)ReleaseObject/SignalObject:現在のコプロセッサコンテキストのDMAストリームに同期化シグナルイベントを挿入する(フェンス/割込み)。解放されるかシグナリングされるオブジェクトへの参照と共にイベントをスケジューライベントヒストリに挿入する。
【0203】
図24の例をミューテクスに適用すると、コプロセッサが、DMAストリーム内の同期化イベントを処理したならば、スケジューラは、下記のアクションを実行することができ、これらのアクションも、任意の組合せでまたは他のアクションと組み合わせて実施することができる。
1)待機時に:ミューテクスの状態を検査する。ミューテクスが現在とられていない場合には、ミューテクスをとり、コプロセッサスレッドをスケジューラのレディキューに戻す。ミューテクスがすでに取られている場合には、コプロセッサスレッドをそのミューテクスの待機キューに入れる。
2)シグナリング時に:他のコプロセッサスレッドがミューテクスを待っているかどうかを検査する。他のいくつかのスレッドが待っている場合には、リストの最初の待っているスレッドをとり、スケジューラのレディリストに戻す。待っているスレッドがない場合には、ミューテクスをとられていない状態に戻す。
【0204】
この機構を使用して、スケジューラが構築することができる。たとえば、スケジューラによって構築できる下記のタイプの同期化プリミティブを検討されたい。
ミューテクス:1時に1つのコプロセッサスレッドだけが、共有リソースへのアクセス権を有することができる
セマフォ:指定された数のコプロセッサスレッドが、同時に共有リソースへのアクセス権を有することができる。
通知イベント:複数のコプロセサスレッドが、別のコプロセッサスレッドからのシグナルを待つことができる。
【0205】
いくつかのシナリオで、アプリケーションを構成して、コプロセッサがレンダリング命令の処理を終えたときの通知を要求することができる。これをサポートするために、スケジューラは、ドライバが、それがサブミットしているDMAバッファに関する通知を要求できるようにすることができる。ドライバは、サブミット時にCPU同期化イベントを指定することができ、このイベントは、サブミットされたDMAバッファについてコプロセッサが終了した後にシグナリングすることができる。スケジューラは、所与のコプロセッサコンテキストのリングに所与のDMAバッファを挿入することができ、その後、リングにユーザモードコプロセッサイベント通知(フェンスとそれに続く割込み)を追加することができる。コプロセッサイベントがコプロセッサによって処理されるときに、スケジューラは、関連するCPU同期化イベントをシグナリングすることができる。
【0206】
スケジューライベントヒストリバッファ
スケジューラは、上で説明した同期化機構を複数の目的に使用することができる。割込みによってコプロセッサが停止しないので、CPUは、通知のサブセットだけを見る必要があり、したがって、一部の通知を、一緒に圧搾することができる。DMAバッファ内のすべての通知に正しく応答するために、スケジューラは、挿入されたイベントのヒストリを、これらのイベントを処理するのに必要なすべてのパラメータと共に維持することができる。
【0207】
イベントヒストリバッファは、単に、スケジューラ処理を必要とし、そのコンテキストのDMAストリームに挿入されたすべてのイベントを追跡するイベント情報構造のコプロセッサコンテキストごとの配列とすることができる。スケジューラフェンスが、スケジューラによってイベントを同期化するのに使用されるフェンスであることに留意されたい。コプロセッサコンテキストごとに1つのフェンスを設けることができ、セキュリティを保つために、フェンスを、特権的命令を介してのみ更新が許可されるようにすることができる。いずれの場合でも、そのようなイベントは、フェンス命令およびそれに続く割込み命令としてDMAストリームに挿入することができる。
【0208】
各フェンス割込み時に、スケジューラは、まず、現在のフェンスを判定し、次に、イベントヒストリバッファを調べて、どのイベントが発生したかを判定することができる。この判定は、関連するフェンスに基づいて行うことができる。スケジューラは、フェンス割込みの処理に進むことができる。図25に、イベントヒストリバッファのさまざまな実施形態を示す。
【0209】
任意の数のイベントをサポートすることができる。下の表に、現在サポートされているイベントの一部を示すが、この表は、潜在的にサポートされるイベントの数またはタイプを制限することを意図されたものではない。
【0210】
【表8】
【0211】
プログラマブルPCIアパーチャ
現在のコプロセッサは、PCI仕様によって許可される限度に非常に近いところまでPCIアパーチャを公開している。将来の世代のコプロセッサは、アパーチャを介して公開できるものより多くのオンボードの補助メモリを有する。したがって、将来に、すべての補助メモリが同時にPCIアパーチャを介して可視になると仮定することができなくなる。
【0212】
この制限を回避できる複数の方法がある。コプロセッサコンテキストごとの仮想アドレス空間をサポートする高度なスケジューリングモデルに好ましい方法は、補助メモリのどこにでも4KB粒度でリダイレクトできるPCIアパーチャを使用することである。これを図26に示す。
【0213】
図26に示された、PCIアパーチャページテーブルは、コプロセッサページテーブルと独立とすることができる。コプロセッサ自体があるコンテキストから別のコンテキストに切り替えつつある間に、複数のCPUプロセスが動作し、PCIアパーチャの一部にアクセスしている可能性がある。PCIアパーチャのページテーブルは、すべてのプロセッサコンテキストの間の共有リソースであり、補助メモリから割り当てられる。ドライバは、マップ/アンマップDDIを提供して、補助メモリマネージャVidMmが、動作中のアプリケーションの間でPCIアパーチャアドレス空間を管理できるようにすることができる。PCIアパーチャのページテーブルを、コプロセッサによって、物理アドレスを使用して参照することができる。
【0214】
PCIアパーチャが、アドレス空間をローカル補助メモリだけにリダイレクトするように構成される可能性があることに留意されたい。VidMmが、そのアパーチャを介するのではなく、必ずシステムメモリを直接にマッピングするので、アドレス空間をシステムメモリにリダイレクトする必要はない。
【0215】
ページレベルフォールト
前に説明したサーフェスレベルフォールトは、ほとんどの場合に良好に働くことができるが、改善できるシナリオがある。たとえば、サーフェスレベルフォールトを使用すると、非常に大きいデータセットを使用するあるアプリケーションが、同時にメモリ内にデータセット全体を置くことができず、したがって正しく機能しない場合がある。高度なモデルで実施できるこれに対する解決策が、ページレベルフォールト機構である。
【0216】
ページレベルフォールトを用いると、モデルは、前の節で説明したものと同様に働く。主要な相違は、ページフォールトがVidMmに報告され、VidMmによって処理される方法にある。サーフェスレベルフォールトでは、コプロセッサが、進行するために必要とするリソースのリスト全体を指定する必要がある(あるリソースのページングが別の必要なリソースを追い出すことを意味する無限ループを除去するために)場合があるが、ページレベルフォールトに対し、コプロセッサが仮想アドレスのリストを公開する必要がない。ページレベルフォールトでは、コプロセッサは、フォールトした仮想アドレスを報告するだけでよい。VidMmは、このアドレスがどの割り当ての一部であるかを見つけ、この特定のページだけが常駐にされる必要があるかどうか、またはあるプリフェッチが必要であるかどうかを判断することができる。複数のページが、単一ピクセルによって要求されるときには、複数のフォールトがその単一ピクセルに関して生成される可能性がある。また、そのピクセルによって要求されるページが、別のページがページインされるときに追い出される可能性がある。しかし、アプリケーションの作業セットが、1ピクセルに必要になる可能性があるページの最大個数より十分に大きい限り、ページフォールトを介するループの可能性は、非常に低い。
【0217】
最後に、本明細書に記載のさまざまな技法を、ハードウェアまたはソフトウェア、あるいは、適当な場合にこの両方の組合せに関して実施できることを理解されたい。したがって、本発明の方法および装置、あるいはそのある態様または部分が、フロッピ(R)ディスク、CD−ROM、ハードドライブ、または他のマシン可読記憶媒体などの有形の媒体で実施されるプログラムコード(すなわち命令)の形式をとることができ、プログラムコードが、コンピュータなどのマシンにロードされ、これによって実行されるときに、そのマシンが、本発明を実施する装置になる。プログラム可能コンピュータでのプログラムコード実行の場合に、コンピューティングデバイスに、一般に、プロセッサ、プロセッサによって読取可能な記憶媒体(揮発性および不揮発性のメモリおよび/または記憶要素を含む)、少なくとも1つの入力デバイス、および少なくとも1つの出力デバイスが含まれる。たとえばデータ処理API、再利用可能なコントロール、および類似物など、本発明のユーザインターフェース技法を実施または使用することができる1つまたは複数のプログラムは、コンピュータシステムと通信するための、高水準手続き型プログラミング言語または高水準オブジェクト指向プログラミング言語で実施されることが好ましい。しかし、望まれる場合に、プログラムをアセンブリ言語またはマシン語で実施することができる。どの場合でも、言語は、コンパイルされる言語または解釈されるものとすることができ、ハードウェア実施形態と組み合わされる。
【0218】
例示的実施形態では、独立型コンピュータシステムに関する本発明の使用に言及したが、本発明は、それに制限されるのではなく、ネットワーク環境または分散コンピューティング環境など、任意のコンピューティング環境に関して実施することができる。さらに、本発明は、複数の処理チップまたはデバイスの中またはこれにまたがって実施することができ、記憶は、同様に複数のデバイスにまたがって行うことができる。そのようなデバイスに、パーソナルコンピュータ、ネットワークサーバ、ハンドヘルドデバイス、スーパーコンピュータ、あるいは、自動車または航空機などの他のシステムに一体化されたコンピュータを含めることができる。
【0219】
したがって、本発明は、単一の実施形態に制限されるのではなく、請求項による幅および範囲において解釈されなければならない。
【技術分野】
【0001】
本発明は、コンピュータプロセッサに関し、具体的には、コプロセッサの処理をスケジューリングするハードウェアおよびソフトウェアに関する。
【背景技術】
【0002】
多くのコンピュータシステムに、現在、コプロセッサ、たとえばグラフィックス処理ユニット(GPU)が含まれる。コプロセッサは、マイクロプロセッサなどの中央処理装置(CPU)と共にシステムのマザーボード上にある場合があり、別々のグラフィックスカードにある場合がある。コプロセッサは、その処理タスクを実行する際に、しばしば、補助メモリ、たとえばビデオメモリにアクセスする。現在のコプロセッサは、しばしば、ゲームおよびコンピュータ支援設計(CAD)などのアプリケーションをサポート(支援)するために3次元グラフィックス計算を実行するように最適化される。現在のコンピュータシステムおよびコプロセッサは、単一のグラフィック集中型アプリケーションを実行するときに適当に動作するが、複数のグラフィック集中型アプリケーションを実行するときに、問題が生じる場合がある。
【0003】
これの理由の1つが、通常のコプロセッサが、作業負荷を効率的にスケジューリングする能力を有しないことである。現在のコプロセッサによって、通常は、協力的マルチタスキングが実施されるが、これは、現在コプロセッサを制御しているアプリケーションが、他のアプリケーションに制御を与えなければならないタイプのマルチタスキングである。アプリケーションは、制御を放棄できない場合に、効果的にコプロセッサを「独占する」ことができる。単一のグラフィック集中型プログラムを実行するときには、これは大きな問題ではなかったが、コプロセッサを独占するという問題は、複数のアプリケーションがコプロセッサの使用を試みるときに深刻になる。
【0004】
動作の間で処理を配分するという問題は、複数の動作の洗練されたスケジューリングが必要になるCPUに関して対処されてきたが、コプロセッサのスケジューリングは、有効に対処されなかった。これは、コプロセッサが、一般に、現在のシステムにおいて、計算的に重く時間がかかる動作をCPUからそらし、CPUに他の機能のためのより多くの処理時間を与えるためのリソースとみなされるからである。そのような計算的に重い動作は、しばしば、グラフィックス動作であり、これは、かなりの処理能力を必要とすることがわかっている。
【0005】
コプロセッサのためにタスクがスケジューリングされる場合に生じる問題の1つが、コプロセッサ「長時間停止状態(starvation)」の可能性である。長時間停止状態は、コプロセッサがビジーでなく、したがって、コンピュータシステムの処理リソースが効果的に使用されていないときに発生する。
【発明の概要】
【発明が解決しようとする課題】
【0006】
上記および他の理由から、コプロセッサ長時間停止状態を最小にすると同時に他のスケジューリング効率を可能にすることによってコプロセッサの性能を強化するシステムおよび方法が望ましい。
【課題を解決するための手段】
【0007】
本発明は、コプロセッサ「長時間停止状態」を最小にし、より高い効率および威力のためにコプロセッサでの処理を効果的にスケジューリングする、連繋してまたは個別に使用することができるさまざまな技法を提供する。これに関して、実行リストが、中央処理装置(「CPU」)によって提供され、ページフォールとまたはタスク完了などの切り替えイベントの発生時に、コプロセッサが、CPU介入を待たずに、あるタスクから次のタスクへ即座に切り替えられるようになる。実行リストに加え、「サーフェスフォールト」と称する方法によって、コプロセッサが、サーフェスの途中のかなりの処理リソースが費やされた後の場所ではなく、サーフェスのレンダリングなどの大きいタスクの初めにフォールトを発生できるようになる。さらに、DMA制御命令すなわち「フェンス」、「トラップ」、および「コンテキスト切り替え許可/禁止」が設けられ、これらを処理ストリームに挿入して、コプロセッサに、コプロセッサの効率および威力を強化するタスクを実行させることができる。これらの命令は、下で詳細に説明するように、高水準同期化オブジェクトの構築にも使用することができる。最後に、ディスプレイのベース参照をある位置から別の位置に切り替え、これによってディスプレイサーフェス全体を変更することができる「フリップ」技法を説明する。これらの技法を有益に使用することができる状況を、本発明の上記および他の態様のさらなる説明に加えて、下で示す。
【図面の簡単な説明】
【0008】
【図1】コプロセッサに関する処理をスケジューリングする従来技術の手法を示す概念図である。
【図2】本発明によるコプロセッサスケジューリングの改善を示す例示的な図である。
【図3】概念的に図2に示されたスケジューリングの改善をもたらすのに用いられるコンピューティングコンポーネントを示すより詳細な図である。
【図4(A)】図3のステップを機能シーケンスに組み合わせるさまざまな非制限的な可能な方法を示す擬似コードアルゴリズムを示す図である。
【図4(B)】図3のステップを機能シーケンスに組み合わせるさまざまな非制限的な可能な方法を示す擬似コードアルゴリズムを示す図である。
【図5】スケジューラが、提供される情報を使用して、本発明による直接メモリアクセス(DMA)バッファ内で使用されるメモリリソースのタイムラインを定義する方法を示す図である。
【図6】本発明による準備ワーカースレッドと補助メモリマネージャの間の動きを示すアルゴリズムを示す図である。
【図7】本発明による、ページングバッファを準備し、ページングバッファに関するCPU前処理を処理するワーカースレッドを示すページングバッファの準備を示す例示的な図である。
【図8】本発明による、ページングバッファ内のフェンスの処理を含む、ワーカースレッド内で行うことができるイベントのチェーンを表すアルゴリズムを示す図である。
【図9】コプロセッサコンテキストの仮想アドレス空間を提供でき、さまざまなコプロセッサコンテキストの間で物理メモリを管理してコプロセッサコンテキストがメモリの公平な分け前を得られるようにすることができる、カーネルモードの補助メモリマネージャ「VidMm」を示す図である。
【図10】本発明による基本的なスケジューリングモデルを示す図である。
【図11】本発明による高度なスケジューリングモデルを示す図である。
【図12(A)】高度なスケジューリングモデルを実施することができるアクションのシーケンスを例示的に示す図である。
【図12(B)】高度なスケジューリングモデルを実施することができるアクションのシーケンスを例示的に示す図である。
【図13】可変長フラットページテーブルと共に本発明の使用を示す図である。
【図14】マルチレベルページテーブルと共に本発明の使用を示す図である。
【図15】サーフェスレベルフォールトをサポートする高度なスケジューリングモデルと共にスケジューラによって維持される例示的処理を示す図である。
【図16】本発明と共にサーフェスレベルフォールトが実施されるときに同時に処理することができる、それぞれがそれ自体のDMAリングを有する複数のコンテキストを示す図である。
【図17(A)】図16の構成要素と共に本発明の動作を示す、有用であることを示すことができるさまざまな追加の特徴を含む擬似コードアルゴリズムを示す図である。
【図17(B)】図16の構成要素と共に本発明の動作を示す、有用であることを示すことができるさまざまな追加の特徴を含む擬似コードアルゴリズムを示す図である。
【図17(C)】図16の構成要素と共に本発明の動作を示す、有用であることを示すことができるさまざまな追加の特徴を含む擬似コードアルゴリズムを示す図である。
【図18】本発明による実行リストの使用を概念的に著す図である。
【図19】本発明に従って使用されるスケジューラによって読取可能な指定されたシステムメモリ位置にコンテキスト切り替えヒストリを書き込むことができるハードウェアの動作を示す図である。
【図20】特権的コマンドをコプロセッサコンテキストリングに直接に挿入することによって特権的DMAチャネルをサポートするハードウェア手法を示す図である。
【図21】間接参照コマンドのビットがリングバッファに挿入される、コプロセッサでの限定DMAバッファ対特権的DMAバッファのサポートの手法を示す図である。
【図22】現在のディスプレイサーフェスに関してコプロセッサに照会する方法を示す図である。
【図23】即時フリップが本発明と共に使用されるときのフリップのキューイングに好ましい手法を示す図である。
【図24】2つまたはそれ以上のプロセッサがレンダリング中に有効な内容を使用できることを保証するためにリソースへのアクセスを同期化する例示的な技法を示す図である。
【図25】イベントヒストリバッファのさまざまな実施形態を示す図である。
【図26】補助メモリ内のどこにでもリダイレクトできるPCIアパーチャを使用する、コプロセッサコンテキストごとの仮想アドレス空間をサポートする好ましい方法を示す図である。
【発明を実施するための形態】
【0009】
本発明によって達成される複数の改善を、図1および図2の比較を介して概念的に示すことができる。図1に、コプロセッサに関するタスクスケジューリングの従来技術の手法を示す。さまざまなアプリケーション、たとえばアプリケーション1、アプリケーション2、およびアプリケーション3からアクセスできるバッファが設けられる。アプリケーションは、コプロセッサに関するタスクをバッファにロードすることができ、これらのタスクを、前にサブミットされたタスクが完了した後に、コプロセッサによって処理することができる。図からわかるように、この手法では、コプロセッサの潜在的な「独占(hogging)」が未解決のままである。図1では、アプリケーション1(APP.1)が、コプロセッサを独占している。APP.1は、コプロセッサが8つのタスクを扱うことを要求するが、他の2つのアプリケーションは、組み合わせても3つのタスクだけの操作を要求している。複数のアプリケーションがコプロセッサを必要とする、これに似た状況では、図2に示されたものなどのシステムによって、改善された機能性を提供することができる。
【0010】
図2に、本発明によるシステムおよび方法を示すが、これによって、各アプリケーション、たとえばアプリケーション1、アプリケーション2、およびアプリケーション3が、それ自体のバッファすなわち、図2の「第1バッファ」を維持することができる。これらのバッファ(下では「コマンドバッファ」と称する)は、スケジューリングプロセスにサブミットされ、スケジューリングプロセスは、さまざまなタスクをコプロセッサに渡すときを決定することができる。図2に示すように、スケジューリングプロセスは、この例では、タスクを「第2バッファ」に挿入している。単純にするために、図2の「第2バッファ」を、単一のバッファとして図示する。しかし、実際には、図2の「第2バッファ」の機能を実行するために、複数のバッファが必要になる場合がある。図2の第2バッファによって、アプリケーション1がコプロセッサリソースを独占できないように、コプロセッサに渡されるタスクが分割されている。スケジューリングプロセスは、アプリケーション1のコプロセッサの第1タスクを許可し、次にアプリケーション2、次にアプリケーション3、次に再びアプリケーション1を許可している。
【0011】
図2に概念的に示されたシステムおよび方法の実施形態は、図2に示されたものより複雑であるが、本明細書で開示される改善は、一般に、図2に示された基本概念をサポートする方向に向けられる。本発明の実施形態のより詳細な説明に移るが、参照を簡単にするために、下記の用語定義を示す。
【0012】
コマンドバッファ − ユーザモードドライバによって構築されるバッファ。このバッファは、レンダリングアプリケーションのコンテキスト内で割り当てられる通常のページング可能メモリとすることができる。
【0013】
DMAバッファ − 「直接メモリアクセス」バッファ。カーネルモードドライバによって構築されるバッファ。このバッファは、コマンドバッファの概念に基づくものとすることができる。一般に、このバッファは、カーネルページング可能メモリから割り当てられ、カーネルだけに可視である。これに関して、ページをコプロセッサが読み取れるようになる前に、ページをロックし、アパーチャを介してマッピングすることができる。
【0014】
ページングバッファ − カーネルモードドライバによって構築されるバッファ。このバッファは、特定のDMAバッファに必要なメモリリソースのページイン、追出し、および移動に使用することができる。ページングバッファは、対応するDMAバッファの前に即座に実行されるように構成することができる。
【0015】
リングバッファ − これは、コプロセッサコンテキスト固有のバッファである。DMAバッファへの指示を、このバッファに挿入することができる。これに関して、コプロセッサは、そのようなリングバッファから、実行されるコマンドをフェッチすることができる。リングバッファには、一般に、DMAバッファからのコマンド読取を開始し、DMAバッファが完全に処理されたならばリングバッファに戻るようにコプロセッサに指示するリダイレクション命令が含まれる。
【0016】
補助メモリ − 一般に、コプロセッサによる使用専用であり、物理システムメモリの一部である必要がないメモリ。これは、たとえば、グラフィックスカードにあるローカルビデオメモリとすることができる。これは、システムメモリアパーチャを介してマッピングされたメモリなど、他のコプロセッサ可読メモリとすることもできる。このメモリは、通常は、統合型またはUMA式のグラフィックスデバイスには存在しない。このメモリは、GART様ページテーブルベースのアパーチャを介してアクセスされない。
【0017】
システムメモリアパーチャ − これは、物理システムメモリのサブセットである。これは、GART様ページテーブルベースのアパーチャを介してコプロセッサに可視とすることができる。CPUは、システムメモリアパーチャと独立に物理システムメモリにアクセス可能とすることができる。概念的に類似する例が、アパーチャを介してアクセスされる、Accelerated Graphics Port(「AGP」)メモリ、Peripheral Component Interconnect(「PCI」)Expressメモリ、またはUnified Memory Architecture(「UMA」)メモリである。
【0018】
本発明のさまざまな実施形態のより詳細な図を、図3に示す。図3は、概念的に図2に示された機能を提供するために組み合わせることができるさまざまなソフトウェアオブジェクトおよびハードウェアオブジェクトの概略図である。図3に、下で説明する一連のシーケンシャルステップが示されている。これらのステップは、本発明を明瞭に説明し、使用可能にするためにシーケンシャルに提示されるものであって、本発明の実践に必要なシーケンスを表すものと解釈するべきではない。順序は、当技術分野で既知のまたは将来に開発される実践に従って変更することができる。下の説明は、図3のシステムおよび方法の概要から始まり、図3のいくつかの態様のより詳細な説明に進む。
【0019】
図3のステップ1は、アプリケーションプログラムインターフェース(「API」)へのアプリケーション呼出しを表す。アプリケーションは、ユーザにとってのソフトウェアを構成するファイルの任意の組とすることができる。APIは、通常は、オペレーティングシステムカーネルと通信するのにアプリケーションによって使用される言語およびメッセージフォーマットであるが、データベース管理システム(DBMS)などの他の制御プログラムとの通信のフォーマットまたは通信プロトコルも指す。本発明と共に使用される例示的なAPIの1つが、MICROSOFT(登録商標)社によって開発されたDirect3D Runtime APIである。
【0020】
ステップ2は、APIからユーザモードドライバへの呼出しを表す。ユーザモードドライバは、一般に、ソフトウェアまたはハードウェアのいずれかとすることができる周辺サブルーチンへソフトウェアシステム(しばしばオペレーティングシステムである)をリンクすることができるプログラムルーチン(またはハードウェア)である。ここで、ユーザモードドライバは、ステップ1からの元の呼出しに対応するAPIパラメータを含めることができる、APIからの呼出しを受け取る。ステップ3は、ユーザモードドライバによって生成されるレンダリングコマンドの、コマンドバッファへの累積を表す。バッファは、中間リポジトリとしての使用のために予約されたメモリの領域である。データエリアおよびプロセッサまたはコプロセッサなどの2つの位置の間での処理のための転送を待っている間に、データを一時的にバッファに保持することができる。ユーザモードドライバによって生成されるコマンドバッファ内容の詳細は、下でさらに説明するように、ハードウェア固有DMAバッファへの変換を容易にするように選択することができる。また、コマンドバッファを定義する際に、「テクスチャ」または「頂点バッファ」などのメモリリソースへの直接メモリ参照を省略することが有用である場合がある。その代わりに、独立ハードウェアベンダ(「IHV」)が、任意選択としてハンドルを含むコマンドバッファを定義することができ、カーネルインターフェースによって、メモリリソースが作成される時にコマンドバッファへのメモリ参照を提供することができる。
【0021】
ステップ4は、コマンドバッファのフラッシュを表す。「フラッシュ」は、単純に、累積されたレンダリングコマンドについてコマンドバッファを空にすることを指す。レンダリングコマンドは、図3に示されたコプロセッサカーネルに渡すために、図示のようにAPIに送り返すことができる。フラッシュは、コマンドバッファが満杯になり、着信レンダリングコマンドの空きが必要であるため、即時処理を必要とする高優先順位レンダリングコマンドがコマンドバッファに存在するため、などを含むがこれに制限されない理由で行うことができる。
【0022】
ステップ5は、APIによる、コプロセッサカーネルへの累積されたコマンドバッファのフラッシュを表す。カーネルは、一般に、オペレーティングシステムの中核部分すなわち、任意選択としてメモリ、ファイル、および周辺デバイスを管理し、アプリケーションを起動でき、システムリソースを割り当てることができる部分として知られる。コプロセッサカーネルを、プライマリシステムカーネル、または別々のコプロセッサ固有のカーネル、あるいは、たとえば、MICROSOFT(登録商標)DirectX Kernel(「DXG」)などの特定のタイプのカーネルを含む、任意のタイプのカーネルとすることができることを諒解されたい。
【0023】
ステップ6は、コプロセッサカーネルへのコマンドバッファのサブミットを表す。コプロセッサカーネルは、コマンドバッファをカーネルモードドライバに向けることができる。カーネルモードドライバは、一般に、ユーザモードドライバに関して上で説明したドライバとすることができるが、カーネルモードドライバは、名前が示すように、カーネルモードで動作することができる。これに関して、カーネルモードドライバは、コマンドバッファをDMAバッファに変換する責任を負うことができる。IHVは、コマンドバッファの正しい確認およびカーネルモードで割り当てられたDMAバッファへの正しいコピーを確実にする適当な機構を提供することを検討することができる。DMAバッファは、最終的にコプロセッサ向けのコマンドの集合であり、したがって、コプロセッサおよびサポートするハードウェアと正しくインターフェースしなければならないという点で、ハードウェア固有とすることができる。
【0024】
図3を横切る、ユーザモードとカーネルモードを分離する水平線に留意されたい。この線によって示されるように、本発明は、システムのセキュリティのために実施される、コンピュータメモリ割り当ての従来のレイアウト内で動作することができる。ユーザモードは、非特権的メモリであり、アプリケーションによってアクセスできる。その一方で、カーネルモードは、特権的であり、アプリケーションによってアクセスできない。カーネルモードで割り当てられたDMAバッファは、理論的にはあらゆるメモリ空間にマッピングできるが、アプリケーションのプライベートプロセス空間へのマッピングが、セキュリティリスクにつながる可能性があることに留意されたい。これは、アプリケーションのプライベートプロセス空間内のスレッドによって参照される仮想アドレスの内容を、修正できるからである。言い換えると、DMAバッファの内容を、確認された時とハードウェアによって処理される時の間に修正することができる。
【0025】
ステップ7に示されているように、カーネルモードドライバによって、DMAバッファによって使用されるメモリリソースのリストを作ることもできる。これは、コマンドバッファの確認の一部として達成することができる。このリストには、たとえば、リストのさまざまなメモリリソースのカーネルハンドル、およびメモリリソースが参照されるバッファ位置を含めることができる。このリストに、リストされたメモリリソースの期待されるコンテキスト状態も含めることができる。これによって、現在のハードウェア状態(たとえば、「現在のレンダターゲット」、「現在のZバッファ」など)の一部であるメモリリソースを、DMAバッファの先頭に再プログラムされるリストの一部とすることができる。というのは、コプロセッサにサブミットされた最後のDMAバッファ以降に位置を変更された可能性があるからである。
【0026】
ステップ8は、メモリリソースリストと共に、DMAバッファをコプロセッサカーネルに送ることを表す。コプロセッサカーネルは、ステップ9に示されているようにコプロセッサスケジューラにDMAバッファをサブミットすることができ、ステップ10に示されているようにユーザモードに戻ることができる。
【0027】
コプロセッサスケジューラは、一般に、コプロセッサのタスク(コプロセッサに送られるさまざまなDMAバッファおよび他の作業で具体化される)のフローをスケジューリングする責任を負う。コプロセッサスケジューラの機能性は、潜在的に非常に広範囲であり、この説明には、コプロセッサスケジューラが実行できる多数の潜在的な機能が含まれる。コプロセッサスケジューラを、コプロセッサスケジューラまたは単にスケジューラのいずれかと呼称することができる。さまざまな実施形態で、図3に示されているように、スケジューラによって、DMAバッファをコプロセッサにサブミットする前に、1つまたは複数の機能を実行することができる。ステップ11aは、スケジューラの一機能が、処理の準備ができたDMAバッファのサブミットであることを動的に示す。
【0028】
ステップ11bは、準備済みDMAバッファのリストに追加されるか、次に実行されるとスケジューラが決定したDMAバッファの選択を表す。これに関して、スケジューラは、DMAバッファを準備スレッドに渡すことができる。準備スレッドは、本明細書で使用される用語として、一般に、正しいメモリリソースがDMAバッファの処理を引き受けるようにする機能を提供する。第1に、準備スレッドは、補助メモリマネージャプロセス(図示せず)を呼び出して、現在補助メモリにないすべての必要なメモリオブジェクト(グラフィックスに関しては「サーフェス」)をページングするのに十分な位置を判定する(これがステップ12である)。用語「補助メモリ」が、コプロセッサによる使用に割り当てられたメモリを指すことに留意されたい。GPUコプロセッサの場合に、補助メモリを、しばしば、「ビデオメモリ」と呼ぶ。
【0029】
DMAバッファによって要求されるメモリリソースの一部が、使用可能な補助メモリに同時にはおさまらない可能性がある。補助メモリマネージャが、様々な理由からこの点で補助メモリにすべてのサーフェスを持ち込めない可能性がある。これが発生する場合には、さらなる処理を行って、補助メモリにより多くの空きを設けるか、その代わりにまたは空きの作成と組み合わせて、DMAバッファを複数のフラグメントに分割することができる。この場合に、準備スレッドによって、ドライバ事前定義分割点を使用して、バッファを分割し、このより小さいDMAバッファが必要とするメモリリソースのサブセットを突き止めるのを試みることができる。
【0030】
DMAバッファに十分な補助メモリが突き止められたならば、準備スレッドによって、ステップ13に示されているように、カーネルモードドライバを呼び出すことができる。当業者が諒解するように、これは、ステップ6、7、および8に関して述べたカーネルモードドライバとするか、別々のカーネルモードドライバとすることができる。
【0031】
ステップ14には、カーネルモードドライバによって、処理を待っているDMAバッファのページングバッファを構築できることが示されている。カーネルモードドライバによって、準備スレッドからの処理コマンドに基づいてこのページングバッファを構築することができる。ページングバッファは、上で定義したように、メモリリソースのページングのためのバッファである。「ページング」は、マッピングハードウェアを使用してメモリのブロック(ページ)の物理アドレスを変更することを指す。ページングバッファは、一般的に言って、メモリリソースをそれに割り当てられた位置に移動するコプロセッサ命令を含むDMAバッファである。ページングバッファは、DMAバッファが必要とするメモリリソースを正しいメモリ位置に移す機能をサービスし、このメモリ位置から、必要なときにコプロセッサによってそのリソースにアクセスすることができる。ページングバッファが正しく生成された場合に、特定のコプロセッサタスクに関する必要なすべてのメモリリソース(すなわちDMAバッファ)の位置がわかる。
【0032】
ステップ15は、ページングバッファが生成されたことの準備スレッドへの通知を表す。ステップ16は、ページングバッファの準備ができたことのスケジューラへのシグナルを表す。スケジューラは、この時点で、次のDMAバッファの処理の準備ができていると仮定することができ、あるいは、処理のためにコプロセッサに送る前に、DMAバッファに対するさらなる準備動作を行うために進行することができる。たとえば、元のDMAバッファの作成以降にメモリ位置が変更されている可能性があるので、スケジューラは、この点でカーネルモードドライバをもう一度呼び出して、メモリリソースの実際の位置を用いてDMAバッファをパッチできるようにすることができる。最後に、スケジューラは、ページングバッファ(存在する場合に)およびDMAバッファの両方を、処理のためにコプロセッサ(および他の任意の補助ハードウェア)にサブミットすることができる。
【0033】
上で説明したステップ1から16は、ハードウェア、ソフトウェア、およびその組合せを介して実施することができる。これに関して、図4(A)および4(B)に、擬似アルゴリズムの形式で図3のステップを全般的に示す。図4(A)および4(B)は、本発明に関して実践することができる潜在的な擬似アルゴリズムステップの網羅的なリストではなく、図4(A)および4(B)のすべてのステップが本発明の実践に必要と解釈するべきではない。そうではなく、図4(A)および4(B)は、本発明の教示における暗示的なリストである。
【0034】
図3に関して提供した上の説明は、本発明のさまざまな実施形態の説明である。しかし、上で説明した本発明の実施形態に関して、複数の利益が発見された。この説明の残りは、さまざまな改善を可能にし、本発明の実践で生じる可能性がある困難を克服するためのものである。
【0035】
スケジューリングの考慮事項
前に定義した動作(上のステップ1から16を参照されたい)の一部またはすべてを、DMAバッファがハードウェアにサブミットされる前に行うことができる。しかし、これらの動作の一部は、DMAバッファがハードウェアにサブミットされるまで実行が困難である場合がある。たとえば、メモリリソースの位置は、DMAバッファがコプロセッサにサブミットされる直前まで、判定が困難である可能性がある。これは、補助メモリリソースが、コプロセッサで実行されるときに各DMAバッファと共に移動される可能性があるからである。
【0036】
上のステップ1から16に含まれる動作の一部は、時間がかかり、したがって、たとえばスケジューラが次に実行するタスクを選択した後など、割込み時に行うことができない場合がある。同様に、まさに時間がかかるので、コプロセッサが他のタスクで忙しい間は、中央処理装置(「CPU」)で実行することが有益である。これによって、コプロセッサ長時間停止状態(starvation)が最小限になる。コプロセッサ長時間停止状態は、単に、コプロセッサが処理機能を処理せずに費やされる時間を指す。この問題に応答して、スケジューラと共に「ワーカースレッド」を利用することが有益である可能性がある。ワーカースレッドによって、時間のかかるセットアップ作業の一部を処理するのに役立つ機能を実行することができる。ワーカースレッドは、本発明の他のプロセスに関する動作の例について図4(B)の擬似アルゴリズムに追加された。
【0037】
このスケジューリングの考慮事項に加え、図3のシステムで任意の所与の時に、動作中のDMAバッファ(すなわち、コプロセッサによって現在処理されつつあるDMAバッファ)、準備されつつあるDMAバッファ、および準備される準備ができているDMAバッファのリストが存在する可能性がある。スケジューラへのサブミットの際に、新しいDMAバッファを、レディキュー(ready queue)に挿入し、その優先順位に応じて適当に順序付けることができる。しかし、新しいDMAバッファが、スケジューラにサブミットされるときに、コプロセッサの次のタスクとして選択されたDMAバッファを先取りできない場合に、本発明のさまざまな実施形態によって、機能性を高めることができる。これの理由は、DMAバッファの準備に、補助メモリとの間でのメモリリソースのページングが伴う可能性があるからである。したがって、処理に関して選択された次のDMAバッファの先取りによって、補助メモリマネージャの永続状態の変化がもたらされる可能性がある。準備されるタスクが先取りされる可能性がある場合には、新たに選ばれたDMAバッファの準備に起因する、補助メモリマネージャの永続状態に対する変更を元に戻すことがもたらされる可能性がある。DMAバッファタスクの動作の途中での補助メモリに対する変更を元に戻すことは、普通ではない可能性があり、潜在的に頻繁なコプロセッサ長時間停止状態につながる可能性がある。
【0038】
DMAバッファの分割
コマンドバッファが、APIによってコプロセッサカーネルにサブミットされるときに、カーネルモードドライバは、ハードウェア固有のDMAバッファおよびそのDMAバッファを実行するのに必要なメモリリソースのリストを生成する役割を担うことができる。特定のDMAバッファフォーマットが、IHVによって定義される場合があるが、ソフトウェアプロバイダは、自身がカーネルモードドライバのリソースリストのフォーマットを定義する作業を知ることができる。
【0039】
メモリリソースリストによって、DMAバッファによって使用できる異なるメモリリソースのタイムライン(timeline)情報を提供することができる。スケジューラは、このメモリリソースリストを使用して、DMAバッファがコプロセッサ上で実行される前にすべての必要なメモリリソースをページインし、DMAバッファによって同時に大量のリソースが使用されるときなど、必要な場合にDMAバッファを分割することができる。
【0040】
DMAバッファが、スケジューラによって分割される場合に、カーネルモードドライバは、メモリリソースリスト内でタイムライン情報を供給することによって、これを容易にする。これは、ドライバに、DMAバッファ内の「オフセット」を指定させることによって行うことができる。オフセットは、そのオフセットでのメモリリソースの使用法を指定するメモリリソース識別子を挿入することによって、メモリリソースがプログラムされているときに送ることができる。メモリリソースは、DMAバッファ内に複数回現れることができるので、同一のメモリリソースが、メモリリソースリストに複数回現れる場合がある。DMAバッファ内のメモリリソースへの参照のそれぞれによって、1つのエントリがリソースリストに追加される。
【0041】
本来、ハンドル/オフセットリストは、DMAバッファを分割する必要があるメモリリソースに関する十分な情報をスケジューラに与えるのに十分でない可能性がある。DMAバッファで特定のメモリリソースが必要なときを正確に知るために、スケジューラが、メモリリソースが別のリソースによって置換されるときに関する情報を必要とする場合もある。たとえば、DMAバッファの先頭で第1テクスチャステージに使用される第1のテクスチャ、テクスチャAが、途中で第2のテクスチャ、テクスチャBによって置換され、その後、DMAバッファの最後でテクスチャAに戻される。スケジューラは、この追加情報を使用して、より少ないメモリリソースを使用する量でDMAバッファを分割することができる。しかし、上で説明したシナリオでは、テクスチャBも、第1テクスチャステージでプログラミングされる可能性があり、この場合には、テクスチャAと同時に使用されており、DMAバッファの別々のサブセットに分離するべきではない。
【0042】
上で説明した洗練された方法でDMAバッファを分割するのに必要な「微細な粒子(finer grain)」の時間情報を達成するために、スケジューラによって、DMAバッファ全体のメモリリソースの使用状況に関する情報を使用することができる。これは、一実施形態では、カーネルモードドライバによって、メモリリソースリスト内のエントリごとにリソース識別子を供給することによって達成することができる。リソース識別子は、単純に、特定のメモリリソースがどのように使用されるかを表す整数値である。たとえば、0の値によって、メモリリソースがレンダターゲットとして使用されることを示すことができ、1の値によって、リソースがZバッファとして使用されることを示すことができる。この情報を用いて、スケジューラは、テクスチャBによってテクスチャAが置換されるか(たとえば、両方が同一のリソース識別子を有する)、またはテクスチャBがテクスチャAと同時に使用される(たとえば、AおよびBが異なるリソース識別子を有する)かどうかを判定することができる。リソース識別子の実際の値およびその意味は、IHVが定義するか、ソフトウェアアーキテクチャで供給することができる。リソース識別子として使用される値が、0ベースになることを保証し、ドライバ初期化の時にそのドライバが使用する最大のリソース識別子の値をドライバが指定することが有用になる可能性がある。
【0043】
図5に、DMAバッファ内で使用されるメモリリソースのタイムラインを定義するために供給される情報をスケジューラがどのように使用できるかを示す。スケジューラは、タイムラインの使用に進んで、バッファ分割点を定義することができる。一般に、DMAバッファが、現在のメモリリソース(すなわち、前のDMAバッファの末尾で最新であったメモリリソース)の、「セットアップ」または識別プロセスを開始しなければならないことに留意することが重要である可能性がある。これの理由は、前のDMAバッファが実行されてから後に、メモリリソースが移動され、したがって、再プログラムが必要である場合があるからである。メモリリソースは、DMAバッファが処理のためにスケジューリングされる時までに、再プログラムされる必要がある場合がある。
【0044】
図5に示されたメモリリソースリストに、任意の数のフィールドを含めることができる。下の表に、有用なフィールドの非網羅的リストを示す。
【0045】
【表1】
【0046】
ページング
一般に、DMAバッファによって参照されるメモリリソースは、コプロセッサによる実行のためにDMAバッファがサブミットされる前に、メモリ内に持ち込まれる。参照されるメモリリソースをメモリ内に持ち込むことを、リソースのページングと称する。ページングに、上で説明した準備ワーカースレッドと、カーネルモードドライバなどのドライバの間の対話を含めることができる。準備ワーカースレッドと補助メモリマネージャの間の動きを示す擬似アルゴリズムについて、図6を参照されたい。
【0047】
ページングステップは、通常は、処理についてDMAバッファが選択され、特定のDMAバッファに関するリソースのリストが生成されているときに行われる。ページングは、メモリリソースを補助メモリに入れる方法と、補助メモリのどこにそれを置くかを決定するために行われる。
【0048】
ページング処理を、補助メモリマネージャによって処理することができる。補助メモリマネージャは、特定の割り当ての作成時にカーネルモードドライバによって任意選択として供給されるヒントを使用することができる。このヒントは、メモリリソースに関してメモリ内の適当な位置を見つけるために作成されたものである。
【0049】
メモリリソースのページングに関連する複数の問題がある。すべてのリソースを持ち込むのに使用可能な十分な空き補助メモリがない場合があり、その場合には、現在メモリ内にあるリソースを追い出すことができる。補助メモリ内の他のオブジェクトを追い出した後であっても、DMAバッファ用のメモリが不十分である場合がある。その場合には、DMAバッファを複数のより小さい部分に分割することができ、これによって、必要なメモリリソースが減る。
【0050】
ページング中に、補助メモリマネージャは、適当な位置にメモリリソースを置くのに使用することができるコマンドのリストを構築することができる。そのコマンドのリストは、たとえば下記の動作から構築することができる。
1)追出し:別のリソースのための空きを作るために、特定のメモリリソースを現在のセグメントからシステムメモリに移動する;
2)ページイン:特定のメモリリソースをシステムメモリから補助メモリ内の空き位置に持ち込む;
3)再配置:特定のメモリリソースをある補助メモリ位置から別の補助メモリ位置に移動する。
【0051】
補助メモリマネージャは、メモリ配置問題を解決するために、これらの動作のどれでも使用することを許可されることができる。この非網羅的なコマンドリストは、ページング動作中に補助メモリマネージャによって生成し、後にスケジューラによってページングバッファを生成するのに使用することができる。補助メモリマネージャは、再配置、追出し、またはページイン、あるいは他の方法で移動されるまたは他の方法で変更されるメモリリソースについてコマンドリスト内のエントリを生成することができる。これに関して、本発明のさまざまな実施形態によって、コマンドリスト内に下記のフィールドを設けることができる。
【0052】
【表2】
【0053】
ページングバッファ生成
上で説明したコマンドラインを使用して、スケジューラによってページングバッファを生成して、コマンドを実行することができる。本発明に関連して使用されるページングバッファのさまざまな実施形態は、図7に示されているように実施することができる。
【0054】
図7からわかるように、コマンドの中には、実行の前に前処理を必要とするものと、前処理なしで処理できるものがある。前処理は、ワーカースレッドを含む複数の方法で行うことができる。コマンドの前処理で、ページングバッファの一部が処理されるまで待つ必要がある場合があることに留意されたい。図7に示されたモデルでは、ワーカースレッドによって、ページングバッファを準備し、ページングバッファに関するCPU前処理を処理する。CPU前処理が、ページングバッファでの動作の前に必要なときには、ワーカースレッドによって、コプロセッサでのページングバッファに対する動作がブロックされる。その後、ワーカースレッドによって、ページングバッファを再始動する前にCPU要求がサブミットされて、動作が完了する。
【0055】
したがって、コマンドリスト内のコマンドごとに、下記のアクションが適当である可能性がある:
ページングバッファ生成時の前処理;
ページングバッファ内の同期ポイントでのCPU処理;
メモリリソースを移動する「Blit」コマンド;
ページングバッファが完了した後のCPU作業の後処理。
【0056】
可能なアクションの上のリストに関して、ページングバッファ自体に、CPUが作業を処理している間にコプロセッサに停止するように要求するコマンドを含めることができる。そのような、割込みを生成し、コプロセッサを停止させるコマンドを、本明細書では「ブロッキングフェンス」と称する。ページングバッファ内のどのコマンドにも、その前または後にブロッキングフェンスを置くことができる。割込みは望ましくないので、CPUがコプロセッサに割り込む回数は、ポスト動作フェンスをバッファの末尾に集めることによって減らされる。ポスト動作フェンス(または「ポストフェンス」)がバッファの末尾の前に必要である場合は、スケジューラによって検出され、ポストフェンスが実行済みであることを必要とするコマンドのプリ動作フェンス(または「プリフェンス」)にマージされる。
【0057】
補助メモリの一貫性を維持するために、ページングバッファの処理で外部割込みを許可しないことが有利になる場合がある。したがって、ページングバッファが実行を完了する前にカンタム(quantum)が満了する場合には、ページングバッファを、完了までコプロセッサの制御下に留まらせることができる。
【0058】
ページングバッファ内のフェンスの処理を含む、ワーカースレッド内で行うことができるイベントのチェーンを表す擬似アルゴリズムについて、図8を参照されたい。図8に関して、下の表に、コマンドリスト内に現れる可能性がある一般化されたコマンドと、前処理、ページングバッファ生成、および生成され得る終了フェンスに関するコマンドのタイプのありそうな分岐のリストを示す。下の表は、役に立つ例示としてのみ提供され、可能なコマンドのタイプまたはこれらのコマンドに関して発生し得るアクションの網羅的なリストであることを意図されたものではない。
【0059】
【表3】
【0060】
【表4】
【0061】
【表5】
【0062】
本明細書で提示するスケジューリングモデルが、コプロセッサをビジーに保つためにかなりの量の自明でないCPU処理を必要とする可能性があることに留意されたい。この作業は、少なくとも部分的に、現在存在するコプロセッサハードウェアの機能によって必要とされる。将来のグラフィックスハードウェアは、より強力なメモリ仮想化およびコプロセッサスケジューリングを有するように設計される可能性がある。これに関して、複数の長所に到達しており、これらの長所も本発明に関して開示される。ハードウェア機能のそれぞれについて、改善の動機および上で説明したスケジューリングモデルに対する影響を説明する。いくつかの改善は、特定の実施手法に基づいて提示される。これらの手法のすべてが必ずしも将来のモデルでサポートされるのではないが、特定の手法が実践される場合に、そのときに、改善を実施手法に適合させる基準を提供する方法で、さまざまな改善を本明細書で説明する。
【0063】
割込み可能なハードウェア
コプロセッサスケジューリングの信頼性を高めるために、コプロセッサによって、DMAバッファ全体より微細な粒度での割込みをサポートすることができる。たとえば、コプロセッサおよびサポートするハードウェアによって、三角形の処理の前または後だけではなく、三角形の処理の中での割込みをサポートすることができる。
【0064】
そのような割込み可能ハードウェアのさまざまな実施形態で、好ましい設計手法は、コプロセッサコンテキストの補助メモリへの自動的な保存および復元を介してコプロセッサの潜在的に完全な仮想化を提供することとすることができる。各コプロセッサコンテキストは、制限ではなく例として、プライベートアドレス空間、DMAバッファが累積されるプライベートリングバッファ、およびコプロセッサコンテキストが実行中でないときにハードウェアの状態が保存されるメモリのプライベート部分を有することができる。この設定でのコンテキスト切り替えをサポートするために、スケジューラによって、保存されたコンテキストの補助メモリ内の物理アドレスをメモリマップ式レジスタを介してコプロセッサに与えることができる。コプロセッサは、そのコプロセッサコンテキストをロードし、すべてのメモリリソースが有効であることを検証し、リングバッファに累積されたDMAバッファを実行し、必要なリソースに出会うときにそのリソースをフォールトにする。
【0065】
上記に関して、さらに、カーネルモードドライバによって、実行されていないコプロセサコンテキストの状態を照会することを可能にすることができる。これは、「実行リスト」イベントトレース(下で説明する)を使用することによるか、照会手段によって、保存されたコンテキストを検査することによって行うことができる。これに関して、ドライバによって、(1)コプロセッサがもっとも最近に特定のコンテキストから切り替えられた理由(たとえば、空、新しい実行リスト、ページフォールト)、(2)ハードウェアによって使用中のメモリリソースのリスト(サーフェスレベルフォールトがサポートされる場合)、(3)フォールトアドレス(ページレベルフォールトがサポートされる場合、および(4)特定のコンテキストを実行していたコプロセサクロックサイクル数などの有用な情報を判定することができる。
【0066】
さらに、カーネルモードドライバによって、現在実行されていないコンテキストのリングに、新しいDMAバッファを挿入できるようにすることができる。保存されたコンテキスト内で、リングの位置、そのコンテキストに保管されたページテーブルまたは他の物理メモリ参照を修正できることも可能である。そのような修正は、たとえば、メモリ内のリソースの移動に続いて必要になる可能性がある。
【0067】
コプロセッサコンテキストごとの仮想アドレス空間
上で説明した基本的なスケジューリングモデルの複雑さの一部は、コプロセッサコンテキストが共通のコプロセッサアドレス空間を共有している可能性があるという事実に起因する。このアドレス空間を仮想化することによって、よりスマートなシステムを提供することができる。アドレス空間の仮想化では、補助メモリマネージャによって、メモリを移動することができ、リソースを補助メモリから完全に追い出すことさえできる。これは、リソースに関する実際にコプロセッサから可視のアドレスを、その寿命の間に変更できることを意味する。したがって、ユーザモードで構築されるコマンドバッファは、コマンドバッファが実行のためにスケジューリングされるまでアドレスが未知である可能性があるので、そのアドレスによって割り当てを直接に参照することができない。
【0068】
たとえば、上で説明した基本スケジューリングモデルの下記の要素を、コプロセッサコンテキストごとのアドレス空間の使用を介して除去することができる。
1)ハンドルを実際のメモリ位置に置換することによるコマンドバッファのパッチ
2)メモリアクセスに関するコマンドバッファの確認
3)カーネルモードでのメモリリソースリストの構築
4)別々のコマンドバッファおよびDMAバッファの作成
5)割り込まれたDMAバッファのリソースの割込み前の位置への移動
【0069】
プロセッサコンテキストごとの仮想アドレス空間を提供する際に、特定のコプロセッサコンテキスト内での割り当てによって、そのコンテキストのアドレス空間内の独自のアドレスを得ることができる。このアドレスは、割り当ての寿命の間に変更する必要がない。したがって、コマンドバッファによって、このアドレスを直接に参照することができ、パッチは不要である。コマンドバッファを確認し、DMAバッファにコピーする必要もなくなる。DMAバッファでのメモリ参照は、コプロセッサの仮想アドレス空間内であり、そのアドレス空間が、実際にすべてのコプロセッサコンテキストについてプライベートなので、有効性に関してメモリ参照を確認する必要はなく、したがって、アプリケーションに可視でないDMAバッファ内のコマンドバッファの確認された内容を隠蔽する必要はない。割り当てまたは追い出された割り当てによって占められていないアドレス空間(ハンドルまたは実アドレス)は、ハードウェアによってダミーページにリダイレクトされるか、アクセスフォールトを引き起こすことができる。これによって、コンテキストが、アクセスすると思われないメモリにアクセスできないので、カーネルモードメモリのセキュリティが保たれる。
【0070】
コプロセッサコンテキストごとの仮想アドレス空間の長所の一部は、次の通りである。各割り当てが、割り当て時にコプロセッサに可視のアドレス(またはハンドル)を得る。コマンドバッファがなく、DMAバッファは、ユーザモードドライバに直接に可視であり、ユーザモードドライバによって書き込まれる。DMAバッファは、それが使用する割り当てのアドレス(またはハンドル)を直接に参照する。ページングに使用されるリソースリストは、ユーザモードドライバによって構築される。
【0071】
図3および対応する説明に示された本発明のさまざまな実施形態のモデルを想起されたい。このモデルを、割込み可能ハードウェアおよび/またはプロセッサコンテキストごとの仮想アドレス空間を使用してさらに改善することができる。これに関して、次の節で、本発明の追加の長所によってさらに改善されることを除いて図3の概念に似た概念を説明する。
【0072】
サーフェスの割り当ておよび割り当て解除
高度なモデルで、カーネルモードのビデオメモリマネージャ「VidMm」などの補助メモリマネージャによって、コプロセッサコンテキストに関する仮想アドレス空間を提供でき、さまざまなコプロセッサコンテキストの間で、これらがメモリの公平な分け前を得られるように物理メモリを管理することができる。基本モデルの割り当て方式に対するこの改善のさまざまな実施形態を、図9に示す。図9には、当業者に馴染みのある用語を使用して本発明の実施形態を示す。というのは、これが、当技術分野で認識された概念に対応するからである。たとえば、「VidMm」は、ビデオメモリマネージャであり、「サンク(Thunk)インターフェース」は、サンクインターフェースである。しかし、この用語は、本発明をより明瞭に説明するのに使用されるが、本発明を制限する意図の表明と解釈するべきではないことに留意されたい。したがって、「VidMm」は、任意の補助メモリに関するメモリマネージャとすることができ、「サンクインターフェース」は、任意の適当なインターフェースとすることができる。
【0073】
図9に関して、高度なモデルを用いると、DMAバッファをアプリケーションのアドレス空間に直接にマッピングできるようになり、これによって、任意選択として、DMAバッファをユーザモードドライバから直接にアクセス可能にすることができる。ユーザモードドライバは、アクセスする必要がある各メモリリソースの永久仮想アドレスまたはハンドルを使用して(したがってパッチが不要になる)レンダリングプリミティブをDMAバッファに直接にバッチ化する。ユーザモードドライバによって、DMAバッファによって使用されるメモリリソースのリストも構築され、したがって、補助メモリマネージャは、DMAバッファがスケジューリングされる前にこれらのリソースを補助メモリバッファに持ち込むことができる。悪意のあるアプリケーションがリソースリストを修正する場合に、リソースの正しい組が、正しくページインされなくなる。これによって必ずしもメモリ保護モデルが壊されないことに留意されたい。というのは、有効なメモリを参照していないアドレス空間の範囲が、ダミーメモリページを参照することまたはハードウェアにフォールトにすることのいずれかのために必要になる可能性があり、指定されたコプロセッサコンテキストの実行を停止させるからである。どちらの場合でも、壊れたリソースリストによって、コプロセッサコンテキストが別のコンテキストのメモリにアクセスできるようになることがもたらされることはない。
【0074】
高度なモデルでは、ユーザモードドライバが、DMAバッファをカーネルモードドライバにサブミットし、カーネルモードライバが、DMAバッファをスケジューラにサブミットする。メモリマネージャにリソースリスト内のリソースをページングするように要求した後に、スケジューラは、DMAバッファをそのままハードウェアに送る。
【0075】
高度なモデルでのスケジューリング
高度なモデルでのスケジューリングは、基本モデルでのスケジューリングに非常に似ている。DMAバッファがコプロセッサにサブミットされる前にDMAバッファを準備するワーカースレッドが依然としてある。しかし、高度なモデルでワーカースレッドによって達成できる作業は、ページング動作だけに制限される必要がある。
【0076】
基本モデルのスケジューリングおよび高度なモデルのスケジューリングの実施形態について、図10および図11を参照されたい。これから明らかにするように、高度なモデルは、2つのスケジューリングオプションを有する。デマンドフォールトなしでスケジューリングするときには、準備フェーズを実施することができる。しかし、高度なモードでデマンドフォールトを使用するときには、準備フェーズは不要である。
【0077】
さらに、図12(A)、12(B)に、高度なスケジューリングモデルを実施することができる擬似コードを示す流れ図を示す。
【0078】
高度なモデルでのページング
高度なモデルでのページングは、基本モデルのページングと異なる。高度なモデルでは、ページングされる割り当てのアドレスが、既に知られており、メモリマネージャは、単に、それを有効にする必要がある。リソースリスト内の割り当てを有効にするために、メモリマネージャは、空いている物理補助メモリの範囲を見つけ、ドライバに、ページテーブルまたはハンドルをその範囲にマッピングするように要求する必要がある。必要であれば、物理メモリの範囲が連続するページのセットになることを要求することができる。
【0079】
割り当てを有効にするのに使用可能な物理ビデオメモリが不十分な場合には、本明細書でVidMmと称する補助メモリマネージャは、追出しについて、現在有効な割り当てをマークすることができる。割り当てが追い出されるときに、そのコンテキストが、システムメモリ(まだシステムメモリ内になかったと仮定して)に転送され、その後、その仮想アドレスまたはハンドルが、無効にされる。
【0080】
仮想アドレス空間
当技術分野で既知または将来に開発される、仮想アドレス空間の提供に関する技法のいずれかを、本発明と共に使用することができる。そのようなアドレス空間を使用できる方法を示すために、共通の仮想アドレス空間技法を使用する2つの例を、本明細書で示す。コプロセッサの仮想アドレス空間を作成する複数の方法があり、当業者が本明細書の例から外挿できることを理解されたい。これに関して、可変長フラットページテーブルおよびマルチレベルページテーブルを使用する仮想アドレス空間を、本明細書で説明する。
【0081】
可変長フラットページテーブル。可変長フラットページテーブルと連合しての本発明の使用を、図13に示す。この方法では、コプロセッサのアドレス空間が、フラットページテーブルの使用を介して仮想化される。仮想アドレス空間を、事前定義のメモリ量、たとえば4KBのページに分割することができる。仮想アドレス空間内のページごとに、1つのページテーブルが設けられ、このページテーブルには、関連する物理メモリの物理アドレスおよび位置(たとえば、Accelerated Graphics Port(AGP)、Peripheral Component Interconnect(PCI)、またはビデオ)を指定するための識別子、たとえば64ビットエントリが含まれる。一実施形態では、コプロセッサによってサポートされるページサイズが、任意ではなく、コプロセッサページテーブルによってシステムメモリページを参照できるようにするために、4KBでなければならない。さらに、この実施形態では、コプロセッサページテーブルによって、同一のアドレス空間から、ローカルビデオメモリとシステムメモリの両方をアドレッシングできなければならない。コプロセッサは、単一のサーフェスに属するすべてのページを単一のタイプのメモリにマッピングすることを要求することができる。たとえば、コプロセッサは、特定のレンダターゲットに属するすべてのページを、ローカルビデオメモリにマッピングすることを要求することができる。しかし、サーフェスをさまざまな物理メモリタイプ(AGP、ローカルビデオなど)にマッピングするページテーブルエントリが、ページテーブルに存在することができる。
【0082】
PCIアダプタおよびAGPアダプタについて、各ページテーブルエントリの例示的実施形態に、32ビットが含まれ、4GB物理アドレス空間全体をコプロセッサに可視にすることができる。PCI−Expressタイプのアダプタを使用する実施形態について、コプロセッサは、64ビットアドレッシングサイクルをサポートすることができる。各ページテーブルエントリに、40ビット以上を含めて、それぞれテラバイト単位のメモリをアドレッシングすることができる。マザーボード上の40ビット以上の物理アドレス信号線を利用する64ビットシステムを実施する実施形態では、対応するビデオアダプタがこのアドレス空間全体をアドレッシングできない場合に、性能ペナルティを経験する場合がある。したがって、64ビットのフルサポートが推奨される。
【0083】
フラットページテーブル法は、ページディレクトリがなく巨大なページテーブルだけがあることを除いて、現在INTEL(登録商標)社の8086(x86)ファミリCPUで使用可能な仮想化機構に似ている。
【0084】
有効な割り当てに関連しない仮想アドレスを、ダミーページにリダイレクトして、悪意のあるDMAバッファが、コプロセッサに、アクセスするべきではないメモリを強制的にアクセスさせることを防ぐことができる。ハードウェアによって、エントリが有効であることを指定する有効ビットを、ページテーブルエントリのそれぞれで実施することができる。
【0085】
ページテーブルは、関連するコプロセッサコンテキストがコプロセッサ上で現在実行中でないときに、再配置可能とすることができる。コンテキストが実行中でないときに、VidMmによって、ページテーブルをシステムメモリに追い出すことができる。コンテキストが、再実行の準備ができたときに、ページテーブルをビデオメモリの、潜在的に異なる位置に戻すことができる。ドライバは、保存されたコプロセッサコンテキスト内のページテーブルの位置を更新することもできる。
【0086】
この実施形態で、すべてのメモリアクセスを、コプロセッサ仮想アドレスを介して行うことができる。しかし、これは、本発明がそのようなアクセスを必要とすることを意味するのではない。ある要素を、他の方法でアクセスすることができ、他の方法でアクセスされる場合により高い機能性を提供することができる。仮想アドレス方式から除外できるいくつかの項目の例が、下記である。
1)ページテーブル自体を、物理アドレスを介して参照することができる。
2)陰極線管(CRT)を、連続するメモリ範囲について物理アドレスにプログラムすることができる。
3)仮想印刷エンジン(VPE)によって、物理アドレスに直接にDMAを実行することができる。
4)オーバーレイは、物理アドレスから直接に読み取ることができる。
5)コプロセッサコンテキストを、物理アドレスを介して参照することができる。
6)プライマリリングバッファを、物理アドレスを介して参照することができる。
【0087】
コンテキスト切り替え中に、コプロセッサによって、復元されるコンテキストによって使用される仮想アドレスを再変換することができる。これによって、これらのアドレスがコンテキスト切り替えの前と同一の物理ページを参照するという潜在的に誤った仮定をコプロセッサにさせるのではなく、メモリリソースが正しいプレーンに配置されることが保証される。また、本発明のさまざまな実施形態に関して、単一のページテーブル内または複数のページテーブルにまたがる複数のエントリが、同一の物理ページを参照できるようにすることが有益であることにも留意されたい。
【0088】
さまざまな実施形態で、コプロセッサによって、ページテーブルの現在のサイズを与えるリミットレジスタ(limit register)を実施することができる。ページテーブルの末尾を超えるメモリ参照のすべてが、コプロセッサによって無効なアクセスとみなされ、それなりに処理される。ページテーブルは、2のべきで拡張可能であり、一実施形態で、少なくとも2GBのアドレス空間(2MBのページテーブル)をサポートすることができる。
【0089】
コプロセッサコンテキストに関連する仮想アドレス空間が断片化された場合に、API、たとえばMICROSOFT(登録商標)Direct3Dランタイムによって、ガーベジコレクションを実行して、アドレス空間および関連するページテーブルのサイズを減らすことができる。上位仮想アドレスでの割り当てが、削除され、低位アドレスに再割り当てされる。
【0090】
本発明と共に可変長フラットページテーブルを使用して仮想アドレス空間を実施することの長所および短所は、当業者に明白である。要約すると、フラットページテーブルを使用することの長所の1つが、物理メモリに対する1レベルの間接参照だけがあることである。もう1つの長所は、ページの不連続の組を用いてページングを解決できることである。しかし、短所もある。たとえば、コプロセッサが動作中であるときに、一般に、ページテーブル全体がメモリ内に存在する必要がある。また、ページテーブルによって、かなりの量のメモリが消費される可能性がある。ページテーブルは、一般にメモリ内のページの連続する組を必要とするので、配置に不便である可能性がある。
【0091】
マルチレベルページテーブル。マルチレベルページテーブルと共の本発明の使用を、図14に示す。マルチレベルページテーブルは、全般的に、可変長フラットページテーブルに類似するものとすることができるが、マルチレベルページテーブルでは、仮想アドレスのインデックス部分が、複数のテーブルにまたがって分割される。たとえば、さまざまな実施形態で、32ビットアドレス空間を使用することができる。この情況では、ハードウェアが、2レベル間接参照を有することが要求される場合がある。間接参照の第1レベルを、ページディレクトリと呼び、第2レベルを、ページテーブルと呼ぶ。コプロセッサが特定のコンテキストを実行しているときに、リソースリスト内の割り当てが必要とするそのコンテキストのページディレクトリおよびページテーブルだけが、メモリ内に存在する必要がある。
【0092】
本発明と共に複数レベルページテーブルを設けることの長所の1つが、ページの不連続の組を用いてページングを解決できることであることを諒解されたい。また、割り当てによって、システムメモリおよびローカルビデオメモリからのページを混合することができ、使用中のページディレクトリおよびページテーブルだけがメモリに存在する必要があり、ページディレクトリおよびページテーブルが、それぞれ1ページだけを必要とする(複数ページの連続的な割り当ては不要である)。しかし、これらの長所にもかかわらず、メモリへのアクセスが2つの間接参照を必要とするという短所が残っている。
【0093】
サーフェスレベルフォールト
コプロセッサコンテキストごとの仮想アドレス空間の追加によって、高度なスケジューリングモデルが、適度に良好に動作し、一般に、特にメモリ圧迫がほとんどまたはまったくないときに、大きいCPUオーバーヘッドを必要としない。ほとんどの場合に、DMAバッファをスケジューラにサブミットできるときに、そのバッファによって参照されるリソースが、既にメモリ内に存在し、したがって、DMAバッファは、ページングスレッドによるページングをまったく必要としない。しかし、スケジューリングに関して、タイムキーピング(time keeping)の精度を高めることによって、モデルをさらに改善することができる。
【0094】
本発明を実施する際に出会う問題の1つが、特定のDMAバッファの実行にどれだけの時間を要するかを前もって知ることが可能でない場合があることである。これは、準備される次のDMAバッファに関するスケジューラによる潜在的に悪い選択をもたらす可能性がある。現在のコンテキスト以上の優先順位の他のコンテキストがない場合、またはその優先順位の他のすべてのコンテキストが空である場合に、スケジューラは、現在のコンテキストから次のDMAバッファを選択することができる。そうでない場合には、スケジューラは、現在のコンテキスト以上の優先順位を有する次のコンテキストから次のDMAバッファを選択することができる。しかし、その選択が、正確である保証はない。次に高い優先順位のコンテキストからDMAバッファを選択するときに、スケジューラは、現在のコンテキストのDMAバッファが、1カンタムより長く実行されると仮定することができる。そのとおりでない場合には、スケジューラは、あまりにも早くそのハードウェアコンテキストから切り替える可能性がある。現在のDMAバッファが、1カンタム未満だけ実行される場合には、スケジューラは、現在のコンテキストから次のDMAバッファを選択するべきであった(これによってコプロセッサの使用効率が最大になるからである)。
【0095】
メモリ圧迫がほとんどまたはまったくないときに、一般に、次のDMAバッファの潜在的な候補の両方が、既にすべてのリソースをメモリ内に有する可能性があり、したがって、どちらのバッファもページングを必要としない可能性が高い。そのシナリオでは、スケジューラが、最初のDMAバッファのカンタムが終了するときに誤りを理解し、即座に考えを変え、コプロセッサに正しいDMAバッファを与えることができる。
【0096】
しかし、メモリ圧迫の下では、このモデルは安定性が下がる可能性がある。次のDMAバッファの「サイズ決定」が、滑らかな動作を保証する際の有利なステップになる可能性がある。メモリ圧迫の下で、前に説明したシナリオでは、おそらく、次のDMAバッファの2つの潜在的な候補の1つが、あるページングを必要とし、したがって、準備スレッドに送られる。その場合に、スケジューラが、最後に「考えを変え」、この2つのDMAバッファを入れ替えることが賢明である。しかし、そのような変更を行うことができ、そのような実践が、本発明の説明の範囲から出ないことに留意されたい。たとえば、次のDMAバッファの準備が完了し、他の潜在的なDMAバッファ候補がページングを必要としないシナリオでは、DMAバッファを交換することができる。これは、補助メモリマネージャによる共有可能な割り当てのある特別なサポートを暗示する可能性がある。
【0097】
上で説明した潜在的なタイムキーピングエラー自体は、それほど悪くはなく、後続カンタム中に、コンテキストに失われた処理時間を与えることによって対処することができる。また、ほとんどの場合に、DMAバッファに、複数のコプロセッサカンタムにわたる実行に十分なコマンドが含まれ、したがって、各コンテキストがそのすべてのカンタムを得ることができる。しかし、メモリ圧迫の下では、補助メモリマネージャが、各コンテキストの作業セットを減らすために、DMAバッファをより小さいバッファに分割することを強制される(上で説明したように)可能性がある。そのようなDMAバッファの分割によって、DMAバッファのサイズが減り、それに対応して、上で説明したカンタム化の問題が増える。
【0098】
メモリ圧迫の下で生じる可能性があるもう1つの問題は、潜在的に、DMAバッファによって実際に使用される、ページインされるより多くのメモリがあるので、このモデルによって人工的に余分の圧迫が引き起こされる可能性があることである。ページインされた余分のメモリのすべてが、潜在的に、次のカンタムの前に追い出され、もう一度ページインされる必要が生じる。これは、ページングアクティビティが既に高いときに、さらに増加したページングアクティビティにつながる可能性がある。基本モデルおよび高度なモデルでは、補助メモリマネージャが、適当な追出しポリシを選択することによって、ページングの増加の問題に対処することができる。たとえば、軽いメモリ圧迫の下で、各コンテキストは、その作業セット内に適度な量のメモリを有する可能性が高い。他のコンテキストからメモリを追い出す前に、補助メモリマネージャは、まず現在のコンテキストからメモリを追い出すことと、使用可能な作業セットにおさまるようにDMAバッファを分割することを試みる。特定のコンテキストのDMAバッファが、その最小サイズに分割されたならば、補助メモリマネージャは、別のコンテキストからメモリを追い出さざるを得なくなる可能性がある。
【0099】
この問題を解決するのに好ましい手法の1つが、コプロセッサが必要とするメモリのデマンドフォールト(demand faulting)を可能にすることである。この方法で、コプロセッサが必要とするメモリのサブセットだけがメモリに存在する必要があることを保証することができる。
【0100】
高度なモデルについて提案されるフォールトのレベルは、サーフェス粒度のレベルである。しかし、任意のレベルのフォールトが、本発明と共に使用するのに適当である可能性があることを理解されたい。また、ページテーブルハードウェアの場合に、ハードウェアは、割り当てが有効であるかどうかを判定するために、割り当ての最初のページの状態だけを調べることができることに留意されたい。というのは、補助メモリマネージャが、割り当て全体を同時にメモリに持ち込めるからである。
【0101】
さまざまな実施形態で、ハードウェアによって、下記のいずれかのときにページフォールトを生成することができる。
1)無効なリングバッファまたはDMAバッファを参照しているコンテキストへのコンテキスト切り替えが発生する。
2)プリミティブが描かれようとしており、必要なメモリリソースの一部が存在しない(たとえば、頂点シェーダコード、頂点バッファ、テクスチャ)。
【0102】
第2の情況で、ハードウェアが、すべての三角形をレンダリングする前に、現在のメモリリソースを再サンプリングする必要がある場合があることに留意されたい。補助メモリマネージャが、コプロセッサの動作中を含めて、任意の時に仮想アドレスまたはハンドルを無効化する可能性がある。ハードウェアが、現在使用しているメモリリソースのすべてについて照会できるようにする可能性があることも期待される。補助メモリマネージャは、その情報を使用して、特定の割り当てがハードウェアによって使用中であるときを判定することができる。補助メモリマネージャは、割り当てが、コプロセッサによって現在使用中のリソースのリストに現れる場合に、その仮想アドレスまたはハンドルを無効化した後に、コプロセッサがその割り当てにアクセスできないので、その割り当てを安全に追い出せると仮定する可能性がある。それを行う試みによって、ページフォールトが引き起こされる可能性がある。
【0103】
本発明に関連するサーフェスレベルフォールトの使用のさらなる説明を、サーフェスレベルフォールトモデルの以下のより詳細な説明によって提供する。以下のモデルは、ある実施形態の例であり、本発明の潜在的な使用または本明細書で提供されるスケジューリングモデルのコンテキストの外部の他の応用例に関するサーフェスレベルフォールトの概念の潜在的な使用に対する制限と解釈するべきではない。
【0104】
第1に、メモリリソースに関する割り当て方式は、本明細書のコプロセッサコンテキストごとの仮想アドレス空間の節で説明したものと同一とすることができる。詳細についてはその節を参照されたい。
【0105】
第2に、DMAバッファのレンダリングコマンド方式およびリソースリストも、本明細書のコプロセッサコンテキストごとの仮想アドレス空間の節で説明したものと同一とすることができる。このモデルでは、グラフィックハードウェアがサーフェルレベルフォールトをサポートする場合であっても、リソースリストが必要である。補助メモリマネージャ(本明細書では「VidMm」)は、リソースリストを使用して、メモリ割り当てに関する使用状況情報を獲得する。その使用状況情報を用いて、VidMmが、メモリ内に空間を作る必要があるときに、追出しの候補を決定することができる。
【0106】
サーフェスレベルフォールトの追加に関して、リソースリストに関するセキュリティの懸念事項はなく、したがって、ユーザモードでリソースリストを構築することができる。悪意のあるアプリケーションが、リソースリストに無効なデータを入れた場合に、発生し得る最悪の事態は、悪意のあるアプリケーションの性能が悪くなることである。VidMmは、追出しの候補に関する非論理的な選択を行う可能性があり、これによって、そのアプリケーションに関する余分なページングアクティビティがもたらされる。
【0107】
サーフェスのデマンドフォールトを用いるスケジューリングモデルは、多くの点で、サーフェスレベルフォールトを使用しないモデルと異なる可能性がある。一般に、レディリスト内のプロセスは、コプロセッサに直接にサブミットでき、準備フェーズが不要である。スケジューラは、ページフォールトの解決を必要とするコンテキストの、専用のリストおよびページングスレッドを維持することができる。ページング動作に使用される、VidMm固有のコプロセッサコンテキストがある。最後に、コンテキストにサブミットされるDMAバッファは、単一の作業アイテムを形成するように連結される。
【0108】
このモデルでは、準備フェーズを除去することができる。スケジューラは、あるコンテキストから別のコンテキストに直接に切り替えるようにコプロセッサに要求することができ、すべてのコンテキストがいつでも実行の準備ができていると仮定することができる。切り替え先のコンテキストの、一部のメモリリソースがメモリ内に存在しない場合には、ハードウェアがフォールトすることができ、コンテキストが、リスト(図15のインページリストなど)に追加され、したがって、ページングスレッドが、そのフォールトの解決について作業を開始することができる。
【0109】
このモデルに関してスケジューラによって維持される例示的なプロセスのリストを、図15に示す。図15を参照すると、フォールトが発生するときに、フォールトを引き起こしたコンテキストを、インページリストに追加することができる。その後、ページングスレッドによって、そのフォールトが解決される。ページングスレッドによって、最初に解決される、フォールトした最高の優先順位のコンテキストを選択することができる。周期的な優先順位ブーストを使用して、低い優先順位のコンテキストが、そのフォールトを解決されるのに十分に高い優先順位を最終的に得ることを保証することができる。フォールトが、インページワーカースレッドによって解決されている間に、スケジューラによって、コプロセッサでの実行の準備ができているコンテキストをスケジューリングすることができる。コプロセッサが働いている間に、インページワーカースレッドは、ドライバを呼び出して割り当てをアドレスにマッピングするかアンマップすることによって、ビデオメモリを操作することができる。
【0110】
コプロセッサによって現在使用されている割り当てが、無効化される可能性がある。コプロセッサがその割り当てに次にアクセスしようとする時に、フォールトが発生しなければならない。しかし、コプロセッサは、任意の時に即座にフォールトすることができないので(たとえば、一部のコプロセッサは、三角形の間で現在の割り当ての状態を再サンプリングするだけである)、コプロセッサが、無効化された後のある時に割り当てを使用することを必要とする可能性がある。
【0111】
それが起こらないようにするために、VidMmによって、次のコンテキスト切り替えまで、割り当てのメモリが、仮想アドレスまたはハンドルが無効化される場合であっても、有効のままになることを保証することができる。これは、ページングに起因するメモリ転送を、VidMm専用のコプロセッサコンテキストで行わせることによって達成することができる。メモリ転送が、別々のコンテキストで行われるので、メモリのコンテキストが変更される前にコンテキストが切り替えられることを確信することができる。システムメモリを参照する仮想アドレスまたはハンドルについて、追出し中のメモリ転送はない。その場合に、VidMmによって、コプロセッサコンテキストがVidMmの専用コンテキストに切り替えられるまで、システムメモリをピン止めすることによってシステムメモリが有効なままになることを保証することができる。
【0112】
VidMm専用コプロセッサコンテキストは、システムメモリとビデオメモリの間のメモリ転送を行うのにVidMmによって使用される通常のコプロセッサコンテキストである。VidMmコンテキストは、インページリスト内の最高優先順位のアイテムの優先順位をとる可変優先順位コンテキストである。すべてのページング動作を単一のコンテキストに直列化させることによって、VidMmの同期化モデルが単純になる。
【0113】
このモデルでのもう1つの興味深い相違は、特定のコンテキストについてサブミットされるDMAバッファのすべを連結して、単一のタスクを形成できる方法である。前のモデルでは、各DMAバッファによって、1つの作業アイテムが形成され、各コンテキストによって、これらの作業アイテムのリストが維持される。スケジューラは、必ずしもコンテキストをスケジューリングせず、コンテキストに関連する特定の作業アイテムをスケジューリングする(かつ、その準備を開始する)。作業アイテムが完了の機会を得る前に、スケジューラが、次の作業アイテムを選択しなければならない。各作業アイテムは、サブミットされる前に準備されなければならず、したがって、スケジューラは、次の作業アイテムをどれにしなければならないかを前もって知らなければならないが、これは常に可能ではない。
【0114】
サーフェスレベルフォールトを用いると、DMAバッファは準備の必要がない。このゆえに、スケジューラは、コンテキストを作業アイテムの集合とみなす必要がない。そうではなく、スケジューラは、実際にコンテキストをスケジューリングし、コンテキストは、コプロセッサの制御を得たならば、コプロセッサの制御を持ち続けることができる。いくつかの、例えば下記のイベントによって、プロセッサのコンテキスト制御を停止させることができる。
1)コプロセッサが、現在キューイングされているすべてのコマンドを完了する
2)コプロセッサが、無効なメモリアクセスによって引き起こされるページフォールトを生成する
3)スケジューラが、異なるコンテキストへの切り替えを要求する
4)コプロセッサが、DMAストリーム内の無効なコマンドに続いて無効動作割込みを生成する
【0115】
図16に、上記による、本発明のさまざまな実施形態を示す図が与えられている。図16を参照すると、左右に、第1のコンテキストの挿入から第2のコンテキストの挿入までの、同一のハードウェア環境での進行が示されている。左側では、スケジューラが、特定のDMAバッファをコプロセッサコンテキスト#1のリングに挿入するようにカーネルドライバに要求する。リングは、ドライバによって修正され、コプロセッサの末尾が更新されて、新しい値を参照するようになる。コプロセッサコンテキスト#1へのDMAバッファの挿入は、コプロセッサコンテキスト#1固有のロックの保護の下で行われる。したがって、他のスレッドは、他のコプロセッサコンテキストのリングにDMAバッファを挿入することができる。
【0116】
右側では、スケジューラが、コプロセッサコンテキスト#2のリングに特定のDMAバッファを挿入するようにカーネルモードドライバに要求する。しかし、このリングは既に満杯であり、したがって、スレッドBは、リングに空きができるまでブロックされる。スレッドBが待つという事実によって、スレッドAそれ自体のリングに新しいDMAバッファを挿入できなくなるのではないことに留意されたい。
【0117】
このモデルでは、各コンテキストが、実行されるDMAバッファの諸部分へのリダイレクトを含めることができるそれ自体のDMAリングを有する。サブミット時に、スケジューラは、サブミットされたDMAバッファをそのコンテキストのリングに追加することを試みることができる。リングが既に満杯である場合には、スケジューラは、もう1つのサブミットに十分なスペースがリングにできるまで待つことができる。この待機によって、サブミットされる特定のコンテキストへのさらなるサブミットだけがブロックされることに留意されたい。他のコンテキストへのサブミットは、ブロックされない。言い換えると、複数のスレッドが、それ自体のコンテキストに並列に作業アイテムを追加することができる。
【0118】
新しいDMAバッファを、実行中のコンテキストのキューに追加することができるので、コプロセッサは、コンテキストが空であることを報告する割込みを生成する前に、キューの末尾を再サンプリングすることができる。もちろん、コプロセッサがキューをサンプリングした直後にDMAバッファがキューに追加される可能性がある。しかし、割込み生成の直前のキューの末尾のサンプリングによって、これが発生する可能性が減り、スケジューリングの精度が高まる。スケジューラは、コンテキストが空であることを通知されたときに、実際にそうであるかどうかを知るために、ドライバに照会する。ドライバが、現在キューに入れられている、まだ処理されていないコマンドがあるかどうかを判定するために、保存されたコプロセッサコンテキストにアクセスすることができなければならない。図17に、このモデルを記述した擬似コードアルゴリズムを示す。
【0119】
後で詳細に説明するように、限定DMAバッファ対特権的DMAバッファという概念を導入して、システムセキュリティを危険にさらさずにユーザモードでDMAバッファを直接に構築できるようにすると同時に、カーネルモードドライバが特権的コマンドを含むDMAバファを構築できるようにする。
【0120】
このモデルによって表されるさまざまな実施形態を、本明細書の後の節で詳細に説明する限定メモリ対特権的メモリという概念と共に使用することができる。さしあたり、前に提示したメモリ仮想化モデルで、限定DMAバッファ対特権的DMAバッファによってアクセスできるメモリの間に区別がなく、すべての仮想メモリがアクセス可能なので、このモデルで問題が生じる可能性があることに留意されたい。これは、ページテーブルまたはリングバッファなどのメモリリソースを、コプロセッサ仮想アドレス空間を介して適当に可視にすることができないことを意味する。というのは、それによって、悪意のあるアプリケーションがページテーブルまたはリングバッファを上書きできるようになるからである。このゆえに、あるタイプのリソースについて物理アドレッシングをサポートし、他のタイプのリソースについて仮想アドレッシングをサポートするハードウェアを設計することができる。
【0121】
この問題に対する異なる手法が、特権的メモリという概念を追加することである。さまざまな実施形態で、特権的メモリに、特権的DMAバッファからのみアクセスでき、コプロセッサは、限定DMAバッファから特権的メモリ位置へのアクセスが試みられる場合に、ページフォールトを引き起こすことができる。その一方で、特権的DMAバッファからは、特権的メモリおよび非特権的メモリの両方に無差別にアクセスすることができる。特権的メモリをサポートするために、ハードウェアが、ハンドルごとに(ハンドルベース仮想化の場合に)またはページごとに(ページテーブルベースの仮想化の場合に)メモリが特権的であるかどうかを指定する機構を有しなければならない。
【0122】
特権的メモリをサポートするために、ページテーブルを有し、サーフェスレベルフォールトをサポートするコプロセッサは、もはや、メモリリソースのベースアドレスだけに基づいてフォールトすることができない。コプロセッサは、現在のリソースに含まれるすべてのページテーブルエントリを調べ、そのすべてが正しい保護ビットをセットされていることを確認しなければならない。メモリリソースの最初のページだけを検査することによって、潜在的に、悪意のあるアプリケーションが、限定DMAバッファで指定した限定メモリベースアドレスに続く特権的メモリにアクセスできるようになる。
【0123】
実行リスト
前に提示したデマンドフォールトモデルは、複数のイベントをシグナリングするために割込みを激しく使用する可能性がある。ページフォールトなど、これらのイベントの一部は、メモリ圧迫の下で非常に頻繁に発生する可能性がある。割込みが発生する時と、コプロセッサがCPUによって新しいタスクを与えられる時の間に、コプロセッサが長時間停止状態を生じる可能性がある。割込み待ち時間を隠蔽し、コプロセッサを動作状態に保つために、実行リストという概念が導入された。
【0124】
実行リストは、単に、CPUの介入なしにコプロセッサによって実行することができるコプロセッサコンテキストのリストである。コンテキストは、与えられた順序で、または本発明の実践に好都合であることがわかった任意の順序で実行することができる。コプロセッサは、たとえば下記など、本発明と共に実施できるさまざまな理由のいずれかについて、実行リスト内のあるコンテキストから次のコンテキストに切り替えることができる。
1)現在のコンテキストが空である、すなわち、行うべきことが残っていない。
2)現在のコンテキストが、ページフォールトを生成した。
3)現在のコンテキストが、一般保護フォールト(コプロセッサによってサポートされる場合に)を生成した。
4)コプロセッサが、新しい実行リストに切り替えることを要求された。
【0125】
さまざまな実施形態で、コプロセッサは、実行リスト内のあるアイテムから次のアイテムに切り替えるときに、CPUに割り込むが、停止せず、リスト内の次のアイテムにコンテキストを切り替えることができ、その実行を開始することができる。実行リストの先頭は、スケジューラが最初に実行を試みることができるコンテキストとすることができ、実行リストの他の要素は、部分的に、割込み待ち時間中にコプロセッサを動作状態に保つために置くことができる。CPUは、コプロセッサがリストの先頭から他に切り替えたことを知らせる割込みを受け取るや否や、新しい実行リストを構築し、コプロセッサに送ることができる。
【0126】
コプロセッサは、リストの先頭から切り替えるときに、生成した割込みがCPUに進む間に、実行リストの次のコンテキストの実行を開始することができる。CPUが生成する新しい実行リストの先頭は、コプロセッサが切り替えた先のコンテキストと異なる場合がある。その場合には、コプロセッサは、もう一度切り替える必要があり、そのコンテキストで有用な作業を行う時間がない場合がある。
【0127】
しかし、コンテキスト優先順位が、最後の実行リストが構築されてから変更されていないので、CPUによって構築される新しい実行リストの先頭のコンテキストを、前の実行リストの第2要素と同一にすることができる。その場合には、コプロセッサは、すでに正しいコンテキストの処理を意外に早く開始している。
【0128】
実行リストの概念を表す図を、図18に示す。実行リストが、本発明のさまざまな実施形態に含まれるときに、スケジューラの実行中コンテキストを、現在の実行リストによって置換することができる。保留中実行リストと称する第2の実行リストを導入して、実行リスト切り替えの同期化を単純にする。現在の実行リストは、ハードウェアが現在実行しているとスケジューラが仮定することができるコンテキストのリストであり、保留中実行リストは、スケジューラがある実行リストから別の実行リストにハードウェアを変更することを望むときに使用される過渡的な実行リストである。スケジューラは、新しい実行リストに切り替えることを望むときに、保留中実行リストを構築し、それに切り替えるようにコプロセッサに要求する。スケジューラが、コプロセッサが新しい実行リストの実行を開始したことの確認をコプロセッサから(割込みを介して)受け取ったならば、保留中実行リストが、新しい現在の実行リストになり、保留中実行リストを空にすることができる。
【0129】
保留中実行リストが空であるときに、ハードウェアは、現在の実行リストのコンテキストを実行しているか、アイドルである可能性がある。保留中実行リストが空でないときには、スケジューラは、遷移が行われたことの確認をコプロセッサから受け取るまで、ハードウェアが現在どの実行リストを実行しているかを知らない可能性がある。
【0130】
ある種のイベントは、スケジューラが実行リストの優先順位を付けなおすことを必要とする場合がある。たとえば、ページフォールトが解決され、高い優先順位のコプロセッサコンテキストの実行の準備ができる場合がある。そのようなイベントの同期化を単純にするために、スケジューラが従うことのできる一般的なルールは、前のイベントによってサブミットされた保留中実行リストがまだない場合に限って、新しい実行リスト(保留中実行リスト)をサブミットすることである。ある保留中リストの別の保留中リストへの置換の試みは、同期化が難しい。というのは、リストが、既にコプロセッサに与えられており、したがって、遷移がいつでも発生する可能性があり、スケジューラが、その事実の後でなければ通知されないからである。
【0131】
後者の場合に、実行リストの優先順位の付けなおしを、コンテキスト切り替えハンドラに委譲することができる。将来のある点で、保留中リストから実行中のリストへの遷移をシグナリングするためにハンドラを呼び出すことができ、その時点で、ハンドラが、優先順位が変更された場合に、新しい実行リストを生成して、ハードウェアに送ることができる。
【0132】
実行リスト切り替えの同期化。ある実行リストモデルでは、グラフィックスハードウェアが、コンテキストを切り替えるときに割込みを生成することができる。割込みの引渡および処理は、瞬間的ではないので、CPUが実際に割り込まれる前に複数の割込みが生成される可能性がある。同期化が正しく行われない場合に、スケジューラが混乱し、不正なスケジューリング判断を行う可能性がある。
【0133】
区別するようにスケジューラに指示することができる2つのクリティカルなイベントが、第1に、コプロセッサが実行リストの先頭から他に切り替えるときと、第2に、コプロセッサが保留中実行リストに切り替えるときである。このイベントを区別することは、各コンテキスト切り替えにおける単純な割込みからの情報だけでは困難になる可能性がある。この点をさらに示すために、次の例を検討されたい:コプロセッサが、現在、コンテキスト1−3−5−2からなる実行リストAを実行しており、スケジューラが、コンテキスト4−1−3−2からなる実行リストBに変更することを望む。下記の2つのシナリオが発生する可能性がある:
シナリオ#1
コプロセッサが、現在、実行リストA(1−3−5−2)を実行している。
コンテキスト4に関するコマンドがサブミットされるが、コンテキスト4は、アイドルであり、コンテキスト1より高い優先順位である。実行リストB(4−1−3−2)が生成され、スケジューラが、実行リストBをコプロセッサにサブミットする。
コンテキスト#1は、コプロセッサが、実行リストBからのコンテキスト#4に遷移するまで実行される。
コプロセッサが、遷移をシグナリングする割込みを生成する。
コプロセッサが、コンテキスト#4から#1に遷移し、その後、CPUが割り込まれる前に#3に遷移する。
CPUが、割り込まれ、コンテキスト切り替えハンドラが呼び出される。
ドライバが、現在のコプロセッサコンテキストをサンプリングするが、これは#3である。
【0134】
シナリオ#2
コプロセッサが、現在、実行リストA(1−3−5−2)を実行している。
コンテキスト4に関するコマンドがサブミットされるが、コンテキスト4は、アイドルであり、コンテキスト1より高い優先順位である。スケジューラが、実行リストBをコプロセッサにサブミットする。
スケジューラが、実行リストBを構築するのにビジーである間に、コプロセッサがコンテキスト#3に遷移する。
コプロセッサが、コンテキスト#3への遷移をシグナリングする割込みを生成する。
CPUが、割り込まれ、コンテキスト切り替えハンドラが呼び出される。
ドライバが現在のコプロセッサコンテキストをサンプリングするが、これは#3である。
【0135】
どちらの場合でも、コンテキスト切り替え割込みの時の現在実行されているコンテキストは、#3である。しかし、スケジューラは、追加情報がなければ、この2つのシナリオを区別できないことに留意されたい。第1のシナリオでは、コプロセッサが、実行リストBの先頭から切り替え、したがって、スケジューラは、実行リストCを生成し、それに切り替えるようにコプロセッサに要求する必要がある。しかし、第2のシナリオでは、第2の実行リストがまだ開始されておらず、したがって、スケジューラは待たなければならない。
【0136】
上の例から、コンテキスト切り替え割込みだけでは、スケジューリングモデルで実行リストを正しくサポートするのに十分でない場合があることが示される。このシナリオを区別するために、さらなる情報が必要である。次の節で、この問題に対処するいくつかの方法を、そのような問題に対処するのに有用にすることができるハードウェアサポートと共に詳細に説明する。
【0137】
2要素実行リスト。この同期化手法は、コプロセッサがある追加機能をサポートすることを必要とする。2要素実行リストの実施形態に関してサポートできる特徴の中に、下記がある。
1)2要素の実行リスト。
2)各コンテキスト切り替え(コンテキストXからXへのにせのコンテキスト切り替えを含む)に割込みを生成する能力。
3)VidMmが任意の時に現在実行されているコプロセッサコンテキストを照会する方法。
4)割込みの前に、進行中のコプロセッサコンテキストをメモリに保存すること。
5)スケジューラがコンテキスト切り替えの理由を判定できるようにするためにCPUによってコンテキストが可読になる方法でのコプロセッサコンテキストの保存。
【0138】
ハードウェアを使用して上の機能をサポートすることができるが、スケジューラが通常のコンテキスト切り替えと実行リスト切り替えを区別できるようにするのに、そのような特殊なハードウェアが必要ではないことに留意されたい。代わりに、スケジューラは、実行リストを構成するときに単純なルールの組を必ず守ることによって、この2つのイベントを区別することができる。特定のルールは、本発明のさまざまな実施形態について変化する可能性があるが、この機能をもたらす例示的なルールは、第1に、現在の実行リストの最初のコンテキストが、新しい保留中実行リストに現れることができないことと、第2に、現在の実行リストの第2のコンテキストが、新しい保留中実行リストの先頭でない場合に、新しい保留中実行リストにこれを含めてはならないことである。下に、この2つの例示的ルールに従うときに、スケジューラが、あるコンテキストから別のコンテキストへの遷移中に行う仮定の表を示す。下の表では、実行リストAが、コンテキスト1−2からなり、第2の実行リストBが、コンテキスト2−3からなり、第3の実行リストCが、コンテキスト3−4からなる。
【0139】
【表6】
【0140】
【表7】
【0141】
実行リストを実施するこの方法は、おそらく最も単純であり、必ずしもかなりの追加ハードウェアサポートを必要としない。しかし、上の表の実行リストが、サイズを制限され(2を超えるサイズの拡張は、実用的でなくなる可能性がある)、クリティカルでないいくつかの情報が、コンテキスト切り替え中に失われる可能性があることに留意されたい。たとえば、スケジューラが、必ずAからCへの遷移でコンテキスト#2が実行されたかどうかを知るとは限らない。それが実行され、ページフォールトを引き起こしたが、別のコンテキスト切り替えによって割込みを隠される可能性がある。その場合に、スケジューラは、コンテキスト#2がフォールトを生成したことを知らず、再スケジューリングする。
【0142】
スケジューリングイベントのコプロセッサトレース。実行リストは、スケジューリング情報のあるヒストリ情報がハードウェアによってスケジューラに供給されるときに、簡単にサイズNまで拡張することができる。単純な割込みの問題の1つが、複数の割込みが一緒に強制される可能性があることであり、何がおきて割込みが引き起こされたかを正確に判定できない可能性があることである。これは、本発明の方法と共に、ハードウェア機能によって対処することができる。より具体的には、コンテキスト切り替えヒストリを、スケジューラによって可読の指定されたシステムメモリ位置に書き込むことができるハードウェアを実施することによって対処することができる。本発明のこの態様を説明するために、下記のシナリオを検討されたい。
【0143】
1)スケジューラが、実行リストA(1−2−3−4−5)をスケジューリングする。
2)コンテキスト#1のタイムカンタムが満了し、スケジューラが、新しい実行リストB(2−3−4−5−1)を送る。
3)CPUでカンタム満了を処理している間に、コプロセッサが、コンテキスト#1が空になるのでコンテキスト#1について完了し、したがってコンテキスト#2に遷移する。コプロセッサは、このイベントについてコンテキスト切り替え割込みを生成した。
4)コプロセッサが、新しい実行リストに関する通知をCPUから受け取り、したがって、それに遷移した。コプロセッサが、このイベントに関するコンテキスト切り替え割込みを生成した。
5)新しい実行リストのコンテキスト#2のレンダリングコマンドを処理している間に、コプロセッサが、ページフォールトに出会い、したがって、コンテキスト#3に遷移した。コプロセッサが、このイベントに関するコンテキスト切り替え割込みを生成した。
6)コンテキスト#3が、ページフォールトを発生し、したがって、コプロセッサが、コンテキスト#4に切り替えた。コプロセッサが、このイベントに関するコンテキスト切り替え割込みを生成した。
7)CPUが、最終的にコンテキスト切り替えについて割り込まれる。最初の割込みが送出されて以来、4つのコンテキスト切り替えが実際に発生した。
【0144】
図19に、上のシナリオでのハードウェアヒストリ機構の動作を示す。そのようなヒストリ機構をサポートするために、下記のタスクを実行できるようにハードウェアを構成することができる。これらのタスクは、制限ではなく例として提供される。
【0145】
1)ヒストリバッファのベースアドレスを指定する。コプロセッサごとに単一のヒストリバッファを設けることができる。好ましい実施形態では、これを、PCIメモリまたはAGPメモリのいずれかのシステムメモリ位置とすることができる。これを、オペレーティングシステムによって4KB境界に整列することができる。PCI expressシステムについて、このバッファへのアクセスは、スヌープサイクルを用いて実施することができ、したがって、システムメモリバッファを、より効率的なCPU読取のためにキャッシュ可能にすることができることが好ましい。
【0146】
2)ヒストリバッファのサイズを指定する。ヒストリバッファは、実行リストのサイズの少なくとも2倍の長さとすることができる。これは、現在の実行リストおよび保留中実行リストの両方が、割込みが発生する前に完了する、ワーストケースシナリオを処理するのに十分なスペースがバッファ内にあることを保証するためである。
【0147】
3)コプロセッサ書込ポインタを指定するが、これはヒストリバッファに書き込まれた最後のイベントの直後のアドレスとすることができる。VidMmは、コプロセッサが稼動している時を含めて、いつでもこのポインタを照会できるものとすることができる。スケジューラが常にコヒーレントなデータを得ることを保証するために、ポインタが更新される前に、ヒストリバッファ内のデータをメモリに正しくフラッシュすることができる。
【0148】
さまざまな実施形態によって、ユーザモードで構築されるDMAバッファから不可視になるようにヒストリバッファを構成することができる。ヒストリバッファが、限定DMAバッファから可視の場合には、悪意のあるアプリケーションが、ヒストリバッファを上書きし、スケジューラを壊し、おそらくはシステムクラッシュまたはさらに悪い結果をもたらすことができる。このゆえに、これらの実施形態のヒストリバッファは、物理アドレスを介してハードウェアによって参照される、または特権的DMAバッファだけに可視の仮想アドレスを介して参照されるのいずれかとすることができる。これらの実施形態では、コプロセッサが、CPU介入なしでヒストリバッファの末尾でラップアラウンドすることを要求することができる。
【0149】
上で説明した実施形態による実行リストによって、コプロセッサが同一の理由で同一のコンテキストで複数回フォールトできるようするための必要のすべてが除去されるわけでないことに留意されたい。これの理由の1つが、スケジューラが、一般に、コプロセッサが現在の実行リストの実行でビジーである間に新しい実行リストを構築することである。スケジューラは、前の実行リストに既に存在するコンテキストを新しい実行リストに含める必要がある場合があるので、繰り返されるコンテキストの状態が、構築される実行リストに置かれた時と、実行リストがコプロセッサにサブミットされた時の間に変化する可能性があることがありえる。
【0150】
限定DMA対特権的DMA
高度なスケジューリングモデルでのメモリ保護の導入に伴って、コプロセッサに送られるDMAバッファが、主として、実行中のアプリケーションのプロセス内部のユーザモードドライバによって構築される可能性がある。これらのDMAバッファは、アプリケーションのプロセス内でマッピングされる可能性があり、ユーザモードドライバは、これらに直接に書き込むことができるが、カーネルドライバは、これを確認することができない。DMAバッファは、誤ってその仮想アドレスにアクセスするアプリケーションによって、または悪意のあるアプリケーションによって故意に、書き込まれる可能性がある。ドライバモデルがセキュアであることを可能にするために、すなわち、アプリケーションが、するべきではないリソースにアクセスできなくするために、ユーザモードで構築されるDMAバッファを、行うことが許可されるものに関して制限することができる。具体的に言うと、ユーザモードで構築されるDMAバッファは、下記の例示的な方法で制限された機能性を有することができる。
【0151】
1)仮想アドレスへの参照だけを含めることができ、物理アドレスへの参照はまったく(フェンスを含めて)含めることができない。
2)現在のディスプレイ(たとえば、CRT、随意アクセス制御(DAC)、Technical Document Management System(TDMS)、Television−Out Port(TV−OUT)、Inter−Integrated Circuit(I2C)バス)に影響する命令を含めることを許可されることができない。
3)アダプタ全般(たとえば位相ロックループ(PLL))に影響する命令を含めることができない。
4)限られた電源管理および/または構成スペースを有することができる。
5)コンテキスト切り替えを防ぐ命令を含めることを許可されることができない。
【0152】
ユーザモードで構築されるDMAバッファでプログラム可能なレジスタの正確な組は、ハードウェアによって変化する可能性が高い。しかし、ハードウェアにかかわらずに、レジスタが一般的な規則に従うことができる、すなわち、そのようなDMAバッファは、リソースおよびフェンスへの仮想アドレス参照を使用するレンダリング動作だけを許可しなければならない。強化されたセキュリティをもたらすために、そのようなDMAバッファに、アプリケーションがアクセスするべきではないメモリ、またはある潜在的に破滅的で回復不能な方法でハードウェアに影響することができるメモリをアプリケーションが使用することを許可しないことを要求することができる。
【0153】
ユーザモードで構築されるDMAバッファが、ある機能性にアクセスできなくするために、複数の手法をコプロセッサ内で実施することができる。これらの手法は、機能性の性質および機能性がアプリケーションのコプロセッサコンテキストストリームにキューイングされる必要があるかどうかに非常に依存する。ある種の特権的動作は、一般に、ユーザモードで構築されるDMAバッファ(たとえばアプリケーションレンダリング)およびカーネルモードで構築されるDMAバッファ(たとえばキューイングされたフリップ)の両方を含むコプロセッサコンテキストストリーム内でキューイングされることを必要とする。
【0154】
キューイングされる必要がない機能性。ほとんどの特権的機能性は、アプリケーションコプロセッサコンテキストストリームでキューイングされることを必要としない。下記などの機能性は、キューイングされることを必要としない。
1)CRTタイミングのプログラミング。
2)DACのルックアップテーブルの更新(DAC LUTのプログラミングが、特権的機能性である必要が絶対にないことに留意されたい。というのは、どのアプリケーションでも、望むならば、プライマリスクリーンにレンダリングすることができ、ルックアップテーブル(LUT)の再プログラミングによって、そうでなければアクセスできない情報へのアクセスをアプリケーションがユーザに与えられるようにはならないからである。
3)ディスプレイ出力のプログラミング(TDMS、TV−OUT、…)
4)子デバイス/モニタとの通信(I2C、…)
5)クロックのプログラミング(PLL)
6)コプロセッサの電源状態の変更
7)コプロセッサの構成(構成スペース、BIOS、…)
【0155】
この機能性は、通常は、アプリケーションレンダリングストリームと完全に独立のシステムイベント(たとえば、ブート、解像度変更、pnp検出、電源管理)の後に必要になる。したがって、この機能性は、特定のアプリケーションのコプロセッサコンテキストでキューイングされることを必要としない。この機能性は、特定のシステムイベントが発生しているときに、ユーザモードドライバからの介入を一切伴わずに、カーネルモードドライバ自体によって使用することができる。
【0156】
そのような機能性について、IHVは、メモリマップ式入出力(MMIO)だけを介して基礎になるレジスタのすべてをアクセス可能にすることを決定することができる。レジスタは、一般に、カーネル空間だけにマッピングされるので、アプリケーションまたはユーザモードドライバがそれにアクセスすることを不可能にすることができ、したがって、この機能性が有効に保護される。
【0157】
もう1つの手法は、コプロセッサコンテキストごとの特権レベルを実施することである。この手法では、コンテキストに、行えることを制限されるものと、そうでないものがある。そのシナリオでは、ユーザモードで構築されるアプリケーションのDMAバッファが、限定コンテキストにキューイングされる。その一方で、カーネルモードドライバは、特権的コンテキストを使用して、特権的機能性をサブミットすることができる。
【0158】
キューイングされることを必要とする機能性。ユーザモードで構築されるDMAバッファに挿入できるコマンドは限られているので、コプロセッサが限定DMAバッファ(前の条件を遵守するDMAバッファ)および特権的DMAバッファの両方をサポートすることを要求するように、高度なモデルを実施することができる。特権的DMAバッファは、コプロセッサコンテキストのレンダリングストリームに沿った特権的機能性のキューイングを可能にするために必要である。
【0159】
特権的DMAバッファには、非特権的DMAバッファに見られる命令のどれでも含めることができる。本発明のさまざまな好ましい実施形態によって、下記(後の節で詳細に説明する)を少なくとも可能にする特権的DMAバッファを実施することができる。
1)特権フェンスの挿入
2)フリップ命令の挿入
3)「コンテキスト切り替えなし」領域の挿入
【0160】
さらに、特権的DMAバッファによって、IHVが望むすべてのハードウェアレジスタをプログラムすることができ、必要な場合に仮想メモリおよび物理メモリの両方にアクセスすることができる。特権的DMAバッファは、ユーザモードで構成することができず、可視にすることもできない。信頼されるカーネルコンポーネントだけが、特権的DMAバッファにアクセスでき、これを構築することができる。
【0161】
次の節に、特権的DMAバッファを実施する可能な3つの方法を示すが、次の節は、本発明を実施できるさまざまな方法を制限せずに、特権的DMAバッファの実施という概念を説明することを意図されたものである。
【0162】
1.DMAバッファは、カーネルモードでのみ構築される
特殊なハードウェアサポートを必要としない特権的DMAバッファをサポートする方法の1つが、ハードウェアに送られる実際のDMAバッファをカーネルモードで構築することを要求することである。このシナリオでは、ユーザモードドライバが、DMAバッファによく似たコマンドバッファを構築し、カーネルモードドライバにサブミットする。カーネルモードドライバは、このコマンドバッファを確認し、カーネルモードでのみ可視のDMAバッファにコピーする。確認中に、カーネルモードドライバは、特権的命令が存在しないことを検証する。これは、基本モデルで要求される確認に似ているが、メモリが仮想化されるので、メモリアクセスに関する確認は不要である。
【0163】
2.リングへの直接の特権的コマンドの挿入
おそらく、特権的DMAチャネルをサポートする最も簡単なハードウェア手法は、特権的コマンドをコプロセッサコンテキストリングに直接に挿入することである。リング自体は、既に特権的チャネルであり、カーネルモードからのみアクセス可能である。これを、図20の図に示す。
【0164】
3.間接参照を介する特権の指定
コプロセッサ内で限定DMAバッファ対特権的DMAバッファをサポートする異なる手法を、図21に示す。これを参照して、開始アドレスおよび終了アドレスの両方をDWORDに整列できることに留意されたい。アドレスの未使用ビットは、フラグの指定に再利用することができる。開始アドレスの第1ビットによって、リダイレクトされるDMAバッファが特権的DMAバッファであることを指定することができる。セキュリティを強化するために、特権的DMAバッファによって、補助メモリ内の物理アドレスを参照することができる。限定DMAバッファによって、コプロセッサコンテキスト仮想アドレス空間内の仮想アドレスを参照することができる。
【0165】
この手法では、間接参照コマンドの1ビットを、リングバッファに挿入することができる。このビットによって、実行されるDMAバッファが特権的DMAバッファであるか否かが示される。これは、リングバッファ自体を、コプロセッサによって物理アドレスを使用して参照することができ、コプロセッサ仮想アドレス空間内で不可視にすることができることを意味する。プライマリリングバッファをコプロセッサ仮想アドレス空間内で可視にすることを許可することによって、悪意のあるアプリケーションが、プライマリリングバッファを上書きできるようになり、特権レベルでコマンドを実行できるようになり、これは、実質上、ほとんどのコンピューティング環境でのセキュリティ侵害と等しい。これに関して、特権的DMAバッファを、物理アドレスを介して参照し、限定DMAバッファのように仮想アドレスで可視でなくすることができる。
【0166】
DMA制御命令
スケジューラおよび補助メモリマネージャが、コプロセッサコンテキストの進行を追跡し、そのコンテキストのDMAストリーム内の命令のフローを制御するために、DMAストリーム内で下記の例示的命令をサポートするようにコプロセッサを構成することができる。
1)フェンス(限定および特権的の両方)
2)トラップ
3)コンテキスト切り替えの許可/禁止
【0167】
フェンス。フェンスは、DMAストリームに挿入することができる、あるデータ(たとえば64ビットのデータ)およびアドレスの両方を含む命令とすることができる。この命令が、コプロセッサによってストリームから読み取られるときに、コプロセッサが、フェンスに関連するデータを指定されたアドレスに書き込む。コプロセッサは、フェンスのデータをメモリに書き込む前に、フェンス命令に先立つプリミティブからのピクセルが、回収され、既にメモリに正しく書き込まれていることを保証しなければならない。これが、コプロセッサがパイプライン全体を停止させることを必要とすることを意味しないことに留意されたい。フェンス命令に続くプリミティブは、コプロセッサがフェンスの前の命令の最後のピクセルが回収されるのを待っている間に実行することができる。
【0168】
上の説明にあてはまるフェンスのすべてを、本発明と共に使用することができるが、特に2タイプのフェンスすなわち、通常のフェンスおよび特権的フェンスを本明細書でさらに説明する。
【0169】
通常のフェンスは、ユーザモードドライバによって作成されたDMAバッファに挿入できるフェンスである。DMAバッファの内容は、ユーザモードから来るので、信頼されない。したがって、そのようなDMAバッファ内のフェンスは、そのコプロセッサコンテキストのアドレス空間の仮想アドレスを参照することができるが、物理アドレスを参照することはできない。そのような仮想アドレスへのアクセスが、コプロセッサによってアクセスされる他の仮想アドレスと同一のメモリ確認機構によって束縛されることは言うまでもない。
【0170】
特権的フェンスは、カーネルモードで作成された(カーネルモードでのみ可視の)DMAバッファに挿入することだけができるフェンスである。そのようなフェンスは、システムのセキュリティを高めるために、メモリ内の物理アドレスを参照することができる。フェンスのターゲットアドレスが、コプロセッサコンテキストのアドレス空間内で可視である場合には、悪意のあるアプリケーションが、そのメモリ位置に対してグラフィック動作を実行でき、したがって、カーネルモードコードが受け取ることを期待する内容をオーバーライドすることができる。潜在的なセキュリティ問題に対するもう1つの解決策が、非特権的DMAバッファから仮想アドレスにアクセスできるかどうかを示す、PTE内の特権ビットを有することである。しかし、上の第1の手法は、早期のハードウェア生成についてより単純と思われる。
【0171】
特権的DMAバッファに、通常のフェンスと特権的フェンスの両方を含めることができることに留意されたい。しかし、特権的DMAバッファに通常のフェンスが含まれるときに、DMAバッファを生成するカーネルコンポーネントに、それが挿入したフェンスが絶対に可視にならないことがわかっている。
【0172】
IHVは、フラッシュを必要とする内部バッファの数を最小にするために、余分なタイプのフェンスをサポートすると決定することができる。下記のタイプのフェンスは、この目的のためにサポートすることができるフェンスの例である(すべてのタイプについて、特権的および非特権的の両方をサポートしなければならないことに留意されたい):
1.書込フェンス
書込フェンスは、前に説明したタイプのフェンスであり、唯一の必要なフェンスタイプである。書込フェンスによって、フェンス命令の前に処理されるすべてのメモリ書込が、グローバルに可視になる(すなわち、それらがキャッシュからフラッシュされ、メモリコントローラから肯定応答が受け取られている)ことが保証される。
【0173】
2.読取フェンス
読取フェンスは、書込フェンスに似た、より軽いタイプのフェンスである。読取フェンスによって、フェンスの前のレンダリング動作に関するメモリ読取のすべてが終了することが保証されるが、一部の書込が、まだ未解決である可能性がある。読取フェンスがサポートされる場合には、スケジューラは、これを使用して、非レンダターゲット割り当ての寿命を制御する。
【0174】
3.トップオブパイプ(top−of−pipe)フェンス
トップオブパイプフェンスは、非常に軽量のフェンスである。トップオブパイプフェンスのサポートは、任意選択である。トップオブパイプフェンスによって、DMAバッファ内でフェンス命令の前の最後のバイトが、コプロセッサによって読み取られた(必ずしも処理されていない)ことだけが保証される。コプロセッサは、フェンスが処理された後に(そのDMAバッファンの内容がもはや有効でなくなるので)、DMAバッファのうちでトップオブパイプフェンスに先立つ部分を再読み取りしない場合がある。サポートされる場合に、このタイプのフェンスは、DMAバッファの寿命を制御するのにスケジューラによって使用される。
【0175】
トラップ。トラップは、本発明のさまざまな実施形態で実施することができる。トラップは、コプロセッサによって処理されるときにCPU割込みを生成できる、DMAバッファに挿入された命令とすることができる。コプロセッサがCPUに割り込む前に、トラップ命令に先立つプリミティブからのすべてのピクセルが、回収され、メモリに正しく書き込まれていることを保証する(フェンス命令からのメモリ書込を含むことができる動作)ことが賢明である。これが、コプロセッサがパイプライン全体を停止させる必要があることを意味しないことに留意されたい。トラップ命令に続くプリミティブは、コプロセッサがトラップの前の命令の最後のピクセルが回収されるのを待っている間に実行することができる。
【0176】
トラップ命令は、特権的命令である必要はなく、ユーザモードドライバによって直接に構築されるものを含むすべてのDMAバッファに挿入することができる。
【0177】
コンテキスト切り替えの許可/禁止。サブトライアングル(sub−triangle)割込みをサポートするハードウェアについて、コンテキスト切り替えを許可または禁止する命令を設けることができる。コンテキスト切り替えが禁止されている間は、コプロセッサは、一般に、現在のコプロセッサコンテキストから切り替えてはならない。コプロセッサは、CPUによって新しい実行リストが提供される場合に現在の実行リストの情報を更新することを要求される場合があるが、コプロセッサは、コンテキスト切り替えが再度許可されるまで、新しい実行リストへのコンテキスト切り替えを延期することができる。OSは、コンテキスト切り替えが禁止されているときに下記のルールが残ることを保証することができる。
1)特権的DMAバッファだけが処理される。
2)コンテキスト切り替え命令がDMAストリームに存在しない。
3)DMAストリームの命令が使い果たされない。
4)ページフォールトが発生しない(ページレベルフォールトがサポートされる場合)。
【0178】
多くのコンピュータシステムで、コンテキスト切り替えの禁止および許可は、特権的DMAバッファ内にのみ存在することができる特権的命令である。これらの命令の使用のシナリオでは、割り込まれる可能性なしで、スケジューラがスクリーンに現れる動作(すなわちプレゼンテーションブリット)をスケジューリングできるようになる。そのような動作で割り込まれることは、容易に目につく時間期間にわたる画面上の可視のアーチファクトにつながる可能性がある。
【0179】
コプロセッサが、DMAバッファ内で不測のエラーに出会う場合に、コンテキスト切り替えが禁止されていても、このDMAバッファからコンテキストを切り替えることができることに留意されたい。カーネルモードで構築されるDMAバッファだけに、割込み不能部分を含めることができるので、不測のエラーは、ドライバのバグまたはハードウェアのバグの結果である。コプロセッサが、これらのシナリオでコンテキストを切り替えない場合には、ディスプレイウォッチドッグがハングを把握し、システムを回復するためにコプロセッサをリセットする。
【0180】
任意選択の制御命令。スケジューラは、上で説明した単純な制御命令を用いて高水準同期化プリミティブを構築することができるが、その結果を、さらに効率的にすることができる。多くのコンピュータシステムで、コプロセッサコンテキストは、同期化オブジェクトの所有権を得る前にCPUによって割り込まれる。同期化オブジェクトが高い頻度で取られ、解放される場合に、これが問題になる可能性がある。より効率的な同期化プリミティブを有するために、スケジューラは、コプロセサから特殊な命令を受け取ることができる。具体的に言うと、「ウェイト」命令および「シグナル」命令を適当な時に送出するようにコプロセッサを構成することができる。
【0181】
ウェイト命令は、指定されたカウンタの値を検査できることをコプロセッサに知らせるためにDMAストリームに挿入される。カウンタが非ゼロの場合には、コプロセッサは、カウンタを減分し、現在のコプロセッサコンテキストの実行を継続する。カウンタがゼロの場合には、コプロセッサは、現在のコプロセッサコンテキストの命令ポインタをウェイト命令の前にリセットし、実行リストの次のコンテキストに切り替える。コプロセッサコンテキストが、ウェイト命令で停止する必要があり、後に再スケジューリングされるときに、コプロセッサは、そのウェイト命令を再実行することができる。というのは、ウェイト条件がまだ満足されていない可能性があるからである。
【0182】
ウェイト命令は、1つのパラメータすなわち、比較/減分されるメモリ位置を指定する仮想アドレスを有することだけを必要とする。カウンタは、少なくとも32ビットとすることができ、任意の有効な仮想アドレスとすることができる。好ましい実施形態では、ウェイト命令を割込み不能とすることができる、すなわち、新しい実行リストがコプロセッサに与えられる場合に、コプロセッサは、ウェイト命令の前またはそれを実行した後のいずれかに新しい実行リストに切り替えることができる。ウェイト命令は、限定DMAバッファおよび特権的DMAバッファの両方に挿入することができる。
【0183】
シグナル命令は、カウンタの値を更新できることをコプロセッサに知らせるためにDMAストリームに挿入することができる。コプロセッサは、カウンタの値を1つ増分することができる。コプロセッサは、加算中の潜在的なオーバーフローを無視することができる。その代わりに、コプロセッサが、ソフトウェアバグを追跡するのを助けるために、ストリーム内のエラーとしてオーバーフローを報告することができる。
【0184】
シグナル命令は、1つのパラメータすなわち、更新されなければならないカウンタの仮想アドレスだけを有することを必要とする。カウンタサイズは、ウェイト命令のカウンタサイズと一致するようにすることができ、好ましい実施形態では、少なくとも32ビットである。シグナル命令は、限定DMAバッファおよび特権的DMAバッファの両方に挿入することができる。
【0185】
フリップ
全画面アプリケーションが、パイプライン内のバブルなしでシームレスに動作できるようにするために、コプロセッサによって、フリップ(すなわち、ディスプレイのベースアドレスの変更)をキューイングする命令を提供することができる。ディスプレイサーフェスは、一般に、物理モデルから連続的に割り当てられ、仮想アドレスではなく物理アドレスを使用してCRTCによって参照される。したがって、フリップ命令を使用して、CRTCを、表示される新しい物理アドレスにプログラムすることができる。これは、物理アドレスであって仮想アドレスではないので、不良アプリケーションが、潜在的に、補助メモリのうちで別のアプリケーションまたはユーザに属する部分(秘密が含まれる可能性がある)を表示するようにCRTCをプログラムすることができる。このため、フリップ命令を実施して、宛先が確認されてからカーネルモデルドライバによってのみDMAストリームに挿入される特権的命令であることを保証することによって、ほとんどのコンピュータシステムのセキュリティを保護することができる。
【0186】
フリップ機能と共に使用される本発明のさまざまな好ましい実施形態で、少なくとも2つのタイプのフリップ、すなわち、即時フリップおよびディスプレイリフレッシュと同期したフリップがサポートされる。コプロセッサは、即時フリップを処理するときに、可視のティアリング(tearing)が引き起こされる場合であっても、ディスプレイのベースアドレスを即座に更新することができる。コプロセッサは、同期式フリップを処理するときに、新しいベースアドレスをラッチすることができるが、次の垂直同期期間まで更新を延期する。垂直同期期間の間にコプロセッサによって複数の同期式フリップが処理される場合に、コプロセッサは、最新のフリップだけをラッチし、前のフリップを無視することができる。
【0187】
同期式フリップを処理するときに、コプロセッサがグラフィックスパイプラインを停止させないように、さまざまな実施形態を構成することができる。OSは、現在可視のサーフェスに描画するレンダリングコマンドがリングバッファにキューイングされないことを保証する。ここで、下でさらに説明する「最適化されたフリップ」の情況で、これらの要件なしで他の実施形態を構成できることに留意されたい。
【0188】
どのサーフェスが現在可視であるかを判定するために、ドライバは、まず、特定のキューイングされたフリップが行われたときを判定することができ、そのイベントについてスケジューラに通知する、すなわち、ディスプレイベースアドレスが変更された後にスケジューラに通知することができる。即時フリップについて、フリップが行われたときを判定するのは簡単である。というのは、DMAストリームからのフリップ命令の読取を、ディスプレイサーフェスの更新と同一のイベントとみなすことができるからである。DMAストリーム内でフリップ命令の後にフェンスおよび割込みを挿入して、特定のフリップが読み取られたことをスケジューラに通知することができる。
【0189】
同期式フリップの場合には、どのサーフェスが現在可視であるかの判定が、より困難である。コプロセッサは、まず、DMAストリームからフリップ命令を読み取るが、後に、次の垂直同期期間にディスプレイサーフェスを更新する。その時にコプロセッサを停止させる必要をなくすために、ディスプレイサーフェス変更が有効になるときをスケジューラに通知する機構を設けることができる。
【0190】
本発明と共に使用されるそのような通知の機構を設計する複数の方法がある。1つの潜在的に単純な手法を、図22に示す。図22に、現在のディスプレイサーフェスに関してコプロセッサに照会する方法を示す。図示の実施形態では、この機能を、MMIOレジスタによって提供されるものと考えることができる。図22のシステムは、最新の「ラッチ式ディスプレイサーフェス」ではなく、レジスタによって実際のディスプレイサーフェスが読み取られるときに、より高い信頼性につながる設計である。最新のラッチされたディスプレイサーフェスの照会は、コプロセッサが別のキューイングされたフリップを処理する、競争状態をもたらす可能性があり、これは画面のティアリングにつながる可能性がある。フリップ命令は、適当な技法を使用して生成することができる。本発明との互換性に関する唯一の一般的な要件は、実施される解像度によって、フリップが、有効になるまで肯定応答されないことを保証することである。
【0191】
フリップのキューイング。最大限の性能を実現するために、高度なスケジューリングモデルを修正して、モニタを所有するアプリケーションのレンダリングストリームにフリップ動作をキューイングすることができる。nバッファリングを行うときに、スケジューラは、n−1個までのフリップをDMAストリームにキューイングすることを許可でき、n番目のフリップが挿入されようとするときにブロックすることができる。
【0192】
これが意味するのは、ダブルバッファリングにおいて、スケジューラが、アプリケーションが1つのフリップをキューイングするのを許可することができ、コプロセッサが現在のフレームのレンダリングおよびそのフリップの処理/肯定応答を終了する間に次のフレームのDMAバッファの準備を継続させることができることである。これは、アプリケーションが、次のフレームのDMAバッファの準備を終了し、第2のフリップをサブミットする時まで、第1のフリップがコプロセッサによって肯定応答されるまでアプリケーションをブロックできることも意味する。
【0193】
即時フリップが、スケジューラによって使用されるときに、フリップをキューイングする機構は、上で説明したように働く。しかし、同期式フリップを使用するときには、スケジューラは、フリップn−1を超えてキューイングされるDMAバッファも特別に処理することができる。実際、フリップを超えるDMAバッファは、一般に、現在可視のサーフェスにレンダリングされる。ほとんどのシステムで、現在キューイングされているフリップの数がn−2以下になるまで、これらのDMAバッファを処理しないことが賢明である。
【0194】
この問題に対処する最も単純な手法は、n−1個ではなく、n−2個のフリップだけをキューイングできるようにすることである。しかし、この解決策は、ダブルバッファリングの場合に、フリップをキューイングできず、したがって、対応するフリップが処理されるまで、各フレームが完了した後にアプリケーションをブロックする必要があることも意味する。
【0195】
この設定での好ましい手法を、図23に示す。図からわかるように、n−1個のフリップのキューイングが、許可される。フリップn−1の後にキューイングされたDMAバッファが実行されないようにするために、スケジューラは、そのコプロセッサコンテキストについて仮想リングバッファにDMAバッファを累積することができる。スケジューラは、現在キューイングされているフリップの数がn−2に減るまで待って、これらのフリップをそのコプロセッサコンテキストの実際のリングにサブミットする。
【0196】
同時に複数のアプリケーションが動作しているときに、コプロセッサは、図23に示されているように停止する必要がない場合がある。コプロセッサは、一般に、特定のコプロセッサコンテキストからのDMAバッファの処理を停止するが、スケジューラは、実行される他のコプロセッサコンテキストをスケジューリングすることができ、効果的にコプロセッサをビジーに保つ。しかし、単一のアプリケーションが実行されているとき、たとえば、全画面ゲームをプレイしているときに、コプロセッサは、これらのインターバル中に停止する可能性がある。次の節で、サポートされる場合に停止時間を減らすためにスケジューラによって使用される機構を説明する。
【0197】
最適化されたフリップ。全画面アプリケーションについて最適化することを試みて、コプロセッサが停止するのに要する時間を最小限に減らすことが望まれる。図23を参照して、コプロセッサが、少なくとも2つの理由で停止する可能性があることを観察されたい:その理由は、第1に、フレームが完了したが、システムがフリップのためにvsyncを待っているため、第2に、フリップが完了したが、システムがCPUに通知するための割込みを待っているため、である。
【0198】
第1の理由に起因する停止を減らすために、より多くのバッファを、フリップのチェーンに追加することができる。たとえば、ダブルバッファからトリプルバッファに移ることによって、そのような停止が大幅に減る。しかし、これを行うことは、必ずしもドライバの制御下ではなく、不当なメモリ消費がもたらされる場合がある。
【0199】
第2の理由に起因する停止を減らすために、この停止の必要を完全に除去するためにコプロセッサ機構を追加することが可能である。コプロセッサは、前にキューイングされたフリップが処理されるまでコプロセッサを停止させるウェイトオンフリップ命令を提供することができる。そのような命令がサポートされるときに、スケジューラは、フリップをキューイングするために全画面アプリケーションについてその命令を使用することができ、CPUは、各フリップの後でDMAストリームを再開する必要がなくなる。
【0200】
高水準の同期化オブジェクト
前に定義した制御命令を使用して、スケジューラによって、クリティカルセクションおよびミューテクスなどの高水準の同期化オブジェクトを構築することができる。スケジューラは、待機の条件が満たされたならば、CPUによって明示的に再スケジューリングされるまで、選択されたDMAバッファを実行されないように保護することによって、そのような同期化プリミティブを実施することができる。オブジェクトの待機は、フェンスなど、スケジューラによって実施することができる。論理的にフェンスに続くDMAバッファを、スケジューラによってキューイングすることができるが、待機条件が満たされるまで、コプロセッサコンテキストのリングにサブミットすることはできない。オブジェクトを待つようになったならば、シグナリングされるまで、スケジューラによってコプロセッサコンテキストをその特定のオブジェクトのウェイトリストに移動することができる。コプロセッサコンテキストDMAストリームに、割込みコマンドが続くフェンスを挿入することによって、オブジェクトにシグナリングすることができる。そのような割込みを受け取るときに、スケジューラは、どのオブジェクトがシグナリングされているかを識別し、待っているコプロセッサコンテキストをレディキューに戻さなければならないかどうかを判定することができる。コプロセッサコンテキストをレディキューに戻すときに、スケジューラは、リングからしまわれたDMAバッファを挿入する。
【0201】
たとえば、アプリケーションが、生産者(プロデューサ)と消費者(コンシューマ)の間で共有されるサーフェスを有し、アプリケーションが、リソースへのアクセスを同期化し、その結果、コンシューマがレンダリング中に必ず有効な内容を使用するようにする必要がある、本発明の実施形態を検討されたい。このシナリオを同期化する1つの潜在的な方法を、図24に示す。
【0202】
図24に移ると、スケジューラ側で、同期化を、たとえば下記のカーネルサンクスを介して実施することができ、このカーネルサンクは、任意の組合せでまたは他のアクションと組み合わせて実施することができる。
1)CreateSynchronizationObject:同期化オブジェクトのカーネル追跡構造体を作成する。後続の待機/解放/削除呼出しで使用することができるオブジェクトへのハンドルをユーザモードに返す。
2)DeleteSynchronizationObject:前に作成されたオブジェクトを破棄する。
3)WaitOnSingleObject/WaitOnMultipleObject:現在のコプロセッサコンテキストのDMAストリームに同期化待機イベントを挿入する。待たれているオブジェクトへの参照と共にイベントをスケジューライベントヒストリに挿入する。
4)ReleaseObject/SignalObject:現在のコプロセッサコンテキストのDMAストリームに同期化シグナルイベントを挿入する(フェンス/割込み)。解放されるかシグナリングされるオブジェクトへの参照と共にイベントをスケジューライベントヒストリに挿入する。
【0203】
図24の例をミューテクスに適用すると、コプロセッサが、DMAストリーム内の同期化イベントを処理したならば、スケジューラは、下記のアクションを実行することができ、これらのアクションも、任意の組合せでまたは他のアクションと組み合わせて実施することができる。
1)待機時に:ミューテクスの状態を検査する。ミューテクスが現在とられていない場合には、ミューテクスをとり、コプロセッサスレッドをスケジューラのレディキューに戻す。ミューテクスがすでに取られている場合には、コプロセッサスレッドをそのミューテクスの待機キューに入れる。
2)シグナリング時に:他のコプロセッサスレッドがミューテクスを待っているかどうかを検査する。他のいくつかのスレッドが待っている場合には、リストの最初の待っているスレッドをとり、スケジューラのレディリストに戻す。待っているスレッドがない場合には、ミューテクスをとられていない状態に戻す。
【0204】
この機構を使用して、スケジューラが構築することができる。たとえば、スケジューラによって構築できる下記のタイプの同期化プリミティブを検討されたい。
ミューテクス:1時に1つのコプロセッサスレッドだけが、共有リソースへのアクセス権を有することができる
セマフォ:指定された数のコプロセッサスレッドが、同時に共有リソースへのアクセス権を有することができる。
通知イベント:複数のコプロセサスレッドが、別のコプロセッサスレッドからのシグナルを待つことができる。
【0205】
いくつかのシナリオで、アプリケーションを構成して、コプロセッサがレンダリング命令の処理を終えたときの通知を要求することができる。これをサポートするために、スケジューラは、ドライバが、それがサブミットしているDMAバッファに関する通知を要求できるようにすることができる。ドライバは、サブミット時にCPU同期化イベントを指定することができ、このイベントは、サブミットされたDMAバッファについてコプロセッサが終了した後にシグナリングすることができる。スケジューラは、所与のコプロセッサコンテキストのリングに所与のDMAバッファを挿入することができ、その後、リングにユーザモードコプロセッサイベント通知(フェンスとそれに続く割込み)を追加することができる。コプロセッサイベントがコプロセッサによって処理されるときに、スケジューラは、関連するCPU同期化イベントをシグナリングすることができる。
【0206】
スケジューライベントヒストリバッファ
スケジューラは、上で説明した同期化機構を複数の目的に使用することができる。割込みによってコプロセッサが停止しないので、CPUは、通知のサブセットだけを見る必要があり、したがって、一部の通知を、一緒に圧搾することができる。DMAバッファ内のすべての通知に正しく応答するために、スケジューラは、挿入されたイベントのヒストリを、これらのイベントを処理するのに必要なすべてのパラメータと共に維持することができる。
【0207】
イベントヒストリバッファは、単に、スケジューラ処理を必要とし、そのコンテキストのDMAストリームに挿入されたすべてのイベントを追跡するイベント情報構造のコプロセッサコンテキストごとの配列とすることができる。スケジューラフェンスが、スケジューラによってイベントを同期化するのに使用されるフェンスであることに留意されたい。コプロセッサコンテキストごとに1つのフェンスを設けることができ、セキュリティを保つために、フェンスを、特権的命令を介してのみ更新が許可されるようにすることができる。いずれの場合でも、そのようなイベントは、フェンス命令およびそれに続く割込み命令としてDMAストリームに挿入することができる。
【0208】
各フェンス割込み時に、スケジューラは、まず、現在のフェンスを判定し、次に、イベントヒストリバッファを調べて、どのイベントが発生したかを判定することができる。この判定は、関連するフェンスに基づいて行うことができる。スケジューラは、フェンス割込みの処理に進むことができる。図25に、イベントヒストリバッファのさまざまな実施形態を示す。
【0209】
任意の数のイベントをサポートすることができる。下の表に、現在サポートされているイベントの一部を示すが、この表は、潜在的にサポートされるイベントの数またはタイプを制限することを意図されたものではない。
【0210】
【表8】
【0211】
プログラマブルPCIアパーチャ
現在のコプロセッサは、PCI仕様によって許可される限度に非常に近いところまでPCIアパーチャを公開している。将来の世代のコプロセッサは、アパーチャを介して公開できるものより多くのオンボードの補助メモリを有する。したがって、将来に、すべての補助メモリが同時にPCIアパーチャを介して可視になると仮定することができなくなる。
【0212】
この制限を回避できる複数の方法がある。コプロセッサコンテキストごとの仮想アドレス空間をサポートする高度なスケジューリングモデルに好ましい方法は、補助メモリのどこにでも4KB粒度でリダイレクトできるPCIアパーチャを使用することである。これを図26に示す。
【0213】
図26に示された、PCIアパーチャページテーブルは、コプロセッサページテーブルと独立とすることができる。コプロセッサ自体があるコンテキストから別のコンテキストに切り替えつつある間に、複数のCPUプロセスが動作し、PCIアパーチャの一部にアクセスしている可能性がある。PCIアパーチャのページテーブルは、すべてのプロセッサコンテキストの間の共有リソースであり、補助メモリから割り当てられる。ドライバは、マップ/アンマップDDIを提供して、補助メモリマネージャVidMmが、動作中のアプリケーションの間でPCIアパーチャアドレス空間を管理できるようにすることができる。PCIアパーチャのページテーブルを、コプロセッサによって、物理アドレスを使用して参照することができる。
【0214】
PCIアパーチャが、アドレス空間をローカル補助メモリだけにリダイレクトするように構成される可能性があることに留意されたい。VidMmが、そのアパーチャを介するのではなく、必ずシステムメモリを直接にマッピングするので、アドレス空間をシステムメモリにリダイレクトする必要はない。
【0215】
ページレベルフォールト
前に説明したサーフェスレベルフォールトは、ほとんどの場合に良好に働くことができるが、改善できるシナリオがある。たとえば、サーフェスレベルフォールトを使用すると、非常に大きいデータセットを使用するあるアプリケーションが、同時にメモリ内にデータセット全体を置くことができず、したがって正しく機能しない場合がある。高度なモデルで実施できるこれに対する解決策が、ページレベルフォールト機構である。
【0216】
ページレベルフォールトを用いると、モデルは、前の節で説明したものと同様に働く。主要な相違は、ページフォールトがVidMmに報告され、VidMmによって処理される方法にある。サーフェスレベルフォールトでは、コプロセッサが、進行するために必要とするリソースのリスト全体を指定する必要がある(あるリソースのページングが別の必要なリソースを追い出すことを意味する無限ループを除去するために)場合があるが、ページレベルフォールトに対し、コプロセッサが仮想アドレスのリストを公開する必要がない。ページレベルフォールトでは、コプロセッサは、フォールトした仮想アドレスを報告するだけでよい。VidMmは、このアドレスがどの割り当ての一部であるかを見つけ、この特定のページだけが常駐にされる必要があるかどうか、またはあるプリフェッチが必要であるかどうかを判断することができる。複数のページが、単一ピクセルによって要求されるときには、複数のフォールトがその単一ピクセルに関して生成される可能性がある。また、そのピクセルによって要求されるページが、別のページがページインされるときに追い出される可能性がある。しかし、アプリケーションの作業セットが、1ピクセルに必要になる可能性があるページの最大個数より十分に大きい限り、ページフォールトを介するループの可能性は、非常に低い。
【0217】
最後に、本明細書に記載のさまざまな技法を、ハードウェアまたはソフトウェア、あるいは、適当な場合にこの両方の組合せに関して実施できることを理解されたい。したがって、本発明の方法および装置、あるいはそのある態様または部分が、フロッピ(R)ディスク、CD−ROM、ハードドライブ、または他のマシン可読記憶媒体などの有形の媒体で実施されるプログラムコード(すなわち命令)の形式をとることができ、プログラムコードが、コンピュータなどのマシンにロードされ、これによって実行されるときに、そのマシンが、本発明を実施する装置になる。プログラム可能コンピュータでのプログラムコード実行の場合に、コンピューティングデバイスに、一般に、プロセッサ、プロセッサによって読取可能な記憶媒体(揮発性および不揮発性のメモリおよび/または記憶要素を含む)、少なくとも1つの入力デバイス、および少なくとも1つの出力デバイスが含まれる。たとえばデータ処理API、再利用可能なコントロール、および類似物など、本発明のユーザインターフェース技法を実施または使用することができる1つまたは複数のプログラムは、コンピュータシステムと通信するための、高水準手続き型プログラミング言語または高水準オブジェクト指向プログラミング言語で実施されることが好ましい。しかし、望まれる場合に、プログラムをアセンブリ言語またはマシン語で実施することができる。どの場合でも、言語は、コンパイルされる言語または解釈されるものとすることができ、ハードウェア実施形態と組み合わされる。
【0218】
例示的実施形態では、独立型コンピュータシステムに関する本発明の使用に言及したが、本発明は、それに制限されるのではなく、ネットワーク環境または分散コンピューティング環境など、任意のコンピューティング環境に関して実施することができる。さらに、本発明は、複数の処理チップまたはデバイスの中またはこれにまたがって実施することができ、記憶は、同様に複数のデバイスにまたがって行うことができる。そのようなデバイスに、パーソナルコンピュータ、ネットワークサーバ、ハンドヘルドデバイス、スーパーコンピュータ、あるいは、自動車または航空機などの他のシステムに一体化されたコンピュータを含めることができる。
【0219】
したがって、本発明は、単一の実施形態に制限されるのではなく、請求項による幅および範囲において解釈されなければならない。
【特許請求の範囲】
【請求項1】
コプロセッサでの処理のためにタスクをスケジューリングする方法であって、
コプロセッサによる処理のためのタスクのリストを含む実行リストを生成するステップであって、前記実行リストは、中央処理装置(CPU)によって生成されるステップと、
スケジューラプロセスに前記実行リストを渡すステップであって、前記スケジューラプロセスは、コプロセッサによる処理のために前記実行リストのタスクを準備するステップと、
前記実行リストによって示される順序で前記コプロセッサによって前記タスクを処理するステップであって、前記タスクの1つを処理するときに切り替えイベントが発生する場合に、前記コプロセッサは、前記実行リストの次のタスクに即座に切り替えるステップと
を備えることを特徴とする方法。
【請求項2】
前記コプロセッサは、グラフィックス処理ユニット(GPU)であることを特徴とする請求項1に記載の方法。
【請求項3】
切り替えイベントが、前にサブミットされたタスクの処理の完了、タスクの処理でのページフォールト、タスクの処理での一般保護フォールト、および前記CPUによる新しい実行リストへの切り替えの要求の少なくとも1つを含むことを特徴とする請求項1に記載の方法。
【請求項4】
前記コプロセッサは前記実行リスト内のあるタスクから前記実行リスト内の次のタスクに切り替えるときに割込み信号を用いて前記CPUにシグナリングするステップをさらに含み、前記CPUは、前記割込み信号を受け取るときに前記コプロセッサのための新しい実行リストを構築することを特徴とする請求項1に記載の方法。
【請求項5】
前記スケジューラプロセスによって第2実行リストを生成するステップをさらに備え、前記スケジューラプロセスは、前記コプロセッサによって処理されるタスクの順序の変更を開始することができることを特徴とする請求項1に記載の方法。
【請求項6】
第1実行リストの第1タスクが前記第2実行リストに現れることを禁止するステップをさらに備えることを特徴とする請求項5に記載の方法。
【請求項7】
第1実行リストの第2タスクが、前記第2実行リストの最初のタスクでなければ、前記第2実行リストに現れることを禁止するステップをさらに備えることを特徴とする請求項5に記載の方法。
【請求項8】
前記スケジューラによって読み取り可能な指定されたシステムメモリ位置に、タスクからタスクへのコプロセッサ切り替えのヒストリに関する情報を保管するステップをさらに備えることを特徴とする請求項1に記載の方法。
【請求項9】
前記スケジューラによって読み取り可能な前記システムメモリ位置は、単一コプロセッサのみから使用可能なヒストリバッファであることを特徴とする請求項8に記載の方法。
【請求項10】
前記ヒストリバッファは、前記実行リストを保管するのに必要な情報の量の少なくとも2倍を保管するのに十分なメモリを含むことを特徴とする請求項8に記載の方法。
【請求項11】
前記コプロセッサが新しい情報を書き込むことができる前記ヒストリバッファ内の位置を示すコプロセッサ書込ポインタを指定するステップをさらに備えることを特徴とする請求項8に記載の方法。
【請求項12】
請求項1に記載の方法を実行するコンピュータ実行可能命令を備えることを特徴とするコンピュータ可読媒体。
【請求項13】
請求項1に記載の方法を実行する手段を備えることを特徴とするコンピューティングデバイス。
【請求項14】
コプロセッサで処理されるDMAストリーム内の命令のフローを制御する1組の命令であって、
データおよびアドレスの両方を含むフェンス命令であって、前記フェンス命令がDMAストリームからコプロセッサによって読み取られるときに、前記コプロセッサは前記アドレスに前記フェンス命令に関連する前記データを書き込むように、前記DMAストリームに挿入することができるフェンス命令と、
トラップ命令であって、前記コプロセッサが前記トラップ命令を読み取るときに、前記コプロセッサがCPU割込みを生成するように、DMAバッファ内に挿入することができるトラップ命令と、
コンテキスト切り替え許可/禁止命令であって、前記コンテキスト切り替え許可/禁止命令が前記コプロセッサにコンテキスト切り替えを許可するように指示するときに、前記コプロセッサは現在のコプロセッサコンテキストから切り替えることを許可し、または前記コンテキスト切り替え許可/禁止命令が前記コプロセッサにコンテキスト切り替えを禁止するように指示するときに、前記コプロセッサは現在のコプロセッサコンテキストから切り替えることを許可しないコンテキスト切り替え許可/禁止命令と
を含むことを特徴とする命令。
【請求項15】
請求項14に記載の命令をサポートするように構成されることを特徴とするグラフィックス処理ユニット(GPU)。
【請求項16】
前記フェンス命令は、コプロセッサによって前記DMAストリームから読み取られるときに、前記フェンス命令に先立つプリミティブからのあらゆるピクセルが回収され、メモリに正しく書き込まれたことをまず前記コプロセッサに確認させることを特徴とする請求項14に記載の命令。
【請求項17】
請求項16に記載の命令をサポートするように構成されたグラフィックス処理ユニット(GPU)であって、前記GPUは前記トラップ命令が回収される前に前記命令の最後のピクセルを待っている間に、前記GPUは、前記フェンス命令に続くプリミティブの処理を継続することを特徴とするグラフィックス処理ユニット。
【請求項18】
前記トラップ命令は、コプロセッサによって前記DMAストリームから読み取られるときに、前記トラップ命令に先立つプリミティブからのあらゆるピクセルが回収され、メモリに正しく書き込まれたことをまず前記コプロセッサに確認させることを特徴とする請求項14に記載の命令。
【請求項19】
請求項16に記載の命令をサポートするように構成されたグラフィックス処理ユニット(GPU)であって、前記GPUは、前記フェンス命令の前の命令の最後のピクセルが回収されるのを待っている間に、前記トラップ命令に続くプリミティブの処理を継続することを特徴とするグラフィックス処理ユニット。
【請求項20】
前記コンテキスト切り替え許可/禁止命令が前記コプロセッサにコンテキスト切り替えを許可するように指示するときに、特権的DMAバッファだけが前記コプロセッサによって処理されること、コプロセッサDMAストリーム内にコンテキスト切り替え命令が存在しないこと、コプロセッサDMAストリームが命令を使い果たさないこと、およびページフォルトが発生しないことの1つを確認するのに追加命令が使用されることを特徴とする請求項14に記載の命令。
【請求項21】
コプロセッサと共に使用されるスケジューラ機構であって、前記スケジューラ機構は、
フェンスを含むウェイト命令を生成するステップであって、フェンスは、DMAストリームに挿入されるデータおよびアドレスの両方を含む命令であり、前記アドレスがコプロセッサによって読み取られるときに、前記コプロセッサに、前記フェンスに関連する前記データを指定された位置に書き込ませるステップと、
CPUによってDMAバッファのセクションが再スケジュールされるまで前記DMAバッファのセクションを実行から保護するステップであって、前記CPUは、前記ウェイト命令が処理された後にDMAバッファのセクションを再スケジューリングするステップと
を備える方法を実行することによって高水準同期化オブジェクトを実施することを特徴とするスケジューラ機構。
【請求項22】
前記方法は、待機条件が満足されるまで、前記フェンスに論理的に続く1つまたは複数のDMAバッファのコプロセッサコンテキストのリングへのサブミットを抑制するステップをさらに備えることを特徴とする請求項21に記載の方法を実行するスケジューラ機構。
【請求項23】
前記方法は、オブジェクトがシグナリングされるまで、前記オブジェクトの待機リストにコプロセッサコンテキストを移動するステップをさらに備え、オブジェクトのシグナリングは、コプロセッサコンテキストDMAストリーム内のフェンスおよびそれに続く割込みコマンドを含むことを特徴とする請求項21に記載の方法を実行するスケジューラ機構。
【請求項24】
コプロセッサ可読メモリ位置に第1ディスプレイサーフェスに対応するデータを連続的に割当てるステップであって、第1ベースアドレスは、第1ディスプレイサーフェスに対応する前記データの位置を識別するためにディスプレイデバイスによって使用されるステップと、
コプロセッサ可読メモリ位置に第2ディスプレイサーフェスに対応するデータを連続的に割当てるステップと、
前記ディスプレイデバイスは代わりに第2ベースアドレスの位置を識別するように前記第1ベースアドレスを再割り当てするフリップ命令を生成するステップであって、前記第2ベースアドレスは、第2ディスプレイサーフェスに対応する前記データを参照し、前記フリップ命令は、コプロセッサによって生成されるステップと
を備える方法のステップを実行することによってアプリケーションに関するグラフィックスのシームレスディスプレイをサポートすることを特徴とするコプロセッサ。
【請求項25】
前記方法は、前記フリップ命令を処理するステップをさらに備え、前記フリップ命令は、前記第1ベースアドレスを即座に再割り当てすることを特徴とする請求項24に記載の方法を実行するコプロセッサ。
【請求項26】
前記方法は、前記フリップ命令を処理するステップをさらに備え、前記フリップ命令は、後続のディスプレイ同期期間の発生時に前記第1ベースアドレスを再割り当てすることを特徴とする請求項24に記載の方法を実行するコプロセッサ。
【請求項27】
請求項24に記載のステップを実行する命令を備えることを特徴とするコンピュータ可読媒体。
【請求項28】
前記コプロセッサはGPUであることを特徴とする請求項24に記載の方法を実行するコプロセッサ。
【請求項1】
コプロセッサでの処理のためにタスクをスケジューリングする方法であって、
コプロセッサによる処理のためのタスクのリストを含む実行リストを生成するステップであって、前記実行リストは、中央処理装置(CPU)によって生成されるステップと、
スケジューラプロセスに前記実行リストを渡すステップであって、前記スケジューラプロセスは、コプロセッサによる処理のために前記実行リストのタスクを準備するステップと、
前記実行リストによって示される順序で前記コプロセッサによって前記タスクを処理するステップであって、前記タスクの1つを処理するときに切り替えイベントが発生する場合に、前記コプロセッサは、前記実行リストの次のタスクに即座に切り替えるステップと
を備えることを特徴とする方法。
【請求項2】
前記コプロセッサは、グラフィックス処理ユニット(GPU)であることを特徴とする請求項1に記載の方法。
【請求項3】
切り替えイベントが、前にサブミットされたタスクの処理の完了、タスクの処理でのページフォールト、タスクの処理での一般保護フォールト、および前記CPUによる新しい実行リストへの切り替えの要求の少なくとも1つを含むことを特徴とする請求項1に記載の方法。
【請求項4】
前記コプロセッサは前記実行リスト内のあるタスクから前記実行リスト内の次のタスクに切り替えるときに割込み信号を用いて前記CPUにシグナリングするステップをさらに含み、前記CPUは、前記割込み信号を受け取るときに前記コプロセッサのための新しい実行リストを構築することを特徴とする請求項1に記載の方法。
【請求項5】
前記スケジューラプロセスによって第2実行リストを生成するステップをさらに備え、前記スケジューラプロセスは、前記コプロセッサによって処理されるタスクの順序の変更を開始することができることを特徴とする請求項1に記載の方法。
【請求項6】
第1実行リストの第1タスクが前記第2実行リストに現れることを禁止するステップをさらに備えることを特徴とする請求項5に記載の方法。
【請求項7】
第1実行リストの第2タスクが、前記第2実行リストの最初のタスクでなければ、前記第2実行リストに現れることを禁止するステップをさらに備えることを特徴とする請求項5に記載の方法。
【請求項8】
前記スケジューラによって読み取り可能な指定されたシステムメモリ位置に、タスクからタスクへのコプロセッサ切り替えのヒストリに関する情報を保管するステップをさらに備えることを特徴とする請求項1に記載の方法。
【請求項9】
前記スケジューラによって読み取り可能な前記システムメモリ位置は、単一コプロセッサのみから使用可能なヒストリバッファであることを特徴とする請求項8に記載の方法。
【請求項10】
前記ヒストリバッファは、前記実行リストを保管するのに必要な情報の量の少なくとも2倍を保管するのに十分なメモリを含むことを特徴とする請求項8に記載の方法。
【請求項11】
前記コプロセッサが新しい情報を書き込むことができる前記ヒストリバッファ内の位置を示すコプロセッサ書込ポインタを指定するステップをさらに備えることを特徴とする請求項8に記載の方法。
【請求項12】
請求項1に記載の方法を実行するコンピュータ実行可能命令を備えることを特徴とするコンピュータ可読媒体。
【請求項13】
請求項1に記載の方法を実行する手段を備えることを特徴とするコンピューティングデバイス。
【請求項14】
コプロセッサで処理されるDMAストリーム内の命令のフローを制御する1組の命令であって、
データおよびアドレスの両方を含むフェンス命令であって、前記フェンス命令がDMAストリームからコプロセッサによって読み取られるときに、前記コプロセッサは前記アドレスに前記フェンス命令に関連する前記データを書き込むように、前記DMAストリームに挿入することができるフェンス命令と、
トラップ命令であって、前記コプロセッサが前記トラップ命令を読み取るときに、前記コプロセッサがCPU割込みを生成するように、DMAバッファ内に挿入することができるトラップ命令と、
コンテキスト切り替え許可/禁止命令であって、前記コンテキスト切り替え許可/禁止命令が前記コプロセッサにコンテキスト切り替えを許可するように指示するときに、前記コプロセッサは現在のコプロセッサコンテキストから切り替えることを許可し、または前記コンテキスト切り替え許可/禁止命令が前記コプロセッサにコンテキスト切り替えを禁止するように指示するときに、前記コプロセッサは現在のコプロセッサコンテキストから切り替えることを許可しないコンテキスト切り替え許可/禁止命令と
を含むことを特徴とする命令。
【請求項15】
請求項14に記載の命令をサポートするように構成されることを特徴とするグラフィックス処理ユニット(GPU)。
【請求項16】
前記フェンス命令は、コプロセッサによって前記DMAストリームから読み取られるときに、前記フェンス命令に先立つプリミティブからのあらゆるピクセルが回収され、メモリに正しく書き込まれたことをまず前記コプロセッサに確認させることを特徴とする請求項14に記載の命令。
【請求項17】
請求項16に記載の命令をサポートするように構成されたグラフィックス処理ユニット(GPU)であって、前記GPUは前記トラップ命令が回収される前に前記命令の最後のピクセルを待っている間に、前記GPUは、前記フェンス命令に続くプリミティブの処理を継続することを特徴とするグラフィックス処理ユニット。
【請求項18】
前記トラップ命令は、コプロセッサによって前記DMAストリームから読み取られるときに、前記トラップ命令に先立つプリミティブからのあらゆるピクセルが回収され、メモリに正しく書き込まれたことをまず前記コプロセッサに確認させることを特徴とする請求項14に記載の命令。
【請求項19】
請求項16に記載の命令をサポートするように構成されたグラフィックス処理ユニット(GPU)であって、前記GPUは、前記フェンス命令の前の命令の最後のピクセルが回収されるのを待っている間に、前記トラップ命令に続くプリミティブの処理を継続することを特徴とするグラフィックス処理ユニット。
【請求項20】
前記コンテキスト切り替え許可/禁止命令が前記コプロセッサにコンテキスト切り替えを許可するように指示するときに、特権的DMAバッファだけが前記コプロセッサによって処理されること、コプロセッサDMAストリーム内にコンテキスト切り替え命令が存在しないこと、コプロセッサDMAストリームが命令を使い果たさないこと、およびページフォルトが発生しないことの1つを確認するのに追加命令が使用されることを特徴とする請求項14に記載の命令。
【請求項21】
コプロセッサと共に使用されるスケジューラ機構であって、前記スケジューラ機構は、
フェンスを含むウェイト命令を生成するステップであって、フェンスは、DMAストリームに挿入されるデータおよびアドレスの両方を含む命令であり、前記アドレスがコプロセッサによって読み取られるときに、前記コプロセッサに、前記フェンスに関連する前記データを指定された位置に書き込ませるステップと、
CPUによってDMAバッファのセクションが再スケジュールされるまで前記DMAバッファのセクションを実行から保護するステップであって、前記CPUは、前記ウェイト命令が処理された後にDMAバッファのセクションを再スケジューリングするステップと
を備える方法を実行することによって高水準同期化オブジェクトを実施することを特徴とするスケジューラ機構。
【請求項22】
前記方法は、待機条件が満足されるまで、前記フェンスに論理的に続く1つまたは複数のDMAバッファのコプロセッサコンテキストのリングへのサブミットを抑制するステップをさらに備えることを特徴とする請求項21に記載の方法を実行するスケジューラ機構。
【請求項23】
前記方法は、オブジェクトがシグナリングされるまで、前記オブジェクトの待機リストにコプロセッサコンテキストを移動するステップをさらに備え、オブジェクトのシグナリングは、コプロセッサコンテキストDMAストリーム内のフェンスおよびそれに続く割込みコマンドを含むことを特徴とする請求項21に記載の方法を実行するスケジューラ機構。
【請求項24】
コプロセッサ可読メモリ位置に第1ディスプレイサーフェスに対応するデータを連続的に割当てるステップであって、第1ベースアドレスは、第1ディスプレイサーフェスに対応する前記データの位置を識別するためにディスプレイデバイスによって使用されるステップと、
コプロセッサ可読メモリ位置に第2ディスプレイサーフェスに対応するデータを連続的に割当てるステップと、
前記ディスプレイデバイスは代わりに第2ベースアドレスの位置を識別するように前記第1ベースアドレスを再割り当てするフリップ命令を生成するステップであって、前記第2ベースアドレスは、第2ディスプレイサーフェスに対応する前記データを参照し、前記フリップ命令は、コプロセッサによって生成されるステップと
を備える方法のステップを実行することによってアプリケーションに関するグラフィックスのシームレスディスプレイをサポートすることを特徴とするコプロセッサ。
【請求項25】
前記方法は、前記フリップ命令を処理するステップをさらに備え、前記フリップ命令は、前記第1ベースアドレスを即座に再割り当てすることを特徴とする請求項24に記載の方法を実行するコプロセッサ。
【請求項26】
前記方法は、前記フリップ命令を処理するステップをさらに備え、前記フリップ命令は、後続のディスプレイ同期期間の発生時に前記第1ベースアドレスを再割り当てすることを特徴とする請求項24に記載の方法を実行するコプロセッサ。
【請求項27】
請求項24に記載のステップを実行する命令を備えることを特徴とするコンピュータ可読媒体。
【請求項28】
前記コプロセッサはGPUであることを特徴とする請求項24に記載の方法を実行するコプロセッサ。
【図1】
【図2】
【図4(A)】
【図4(B)】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12(A)】
【図12(B)】
【図16】
【図17(A)】
【図17(B)】
【図17(C)】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図25】
【図26】
【図3】
【図13】
【図14】
【図15】
【図24】
【図2】
【図4(A)】
【図4(B)】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12(A)】
【図12(B)】
【図16】
【図17(A)】
【図17(B)】
【図17(C)】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図25】
【図26】
【図3】
【図13】
【図14】
【図15】
【図24】
【公開番号】特開2010−20803(P2010−20803A)
【公開日】平成22年1月28日(2010.1.28)
【国際特許分類】
【出願番号】特願2009−245934(P2009−245934)
【出願日】平成21年10月26日(2009.10.26)
【分割の表示】特願2004−42173(P2004−42173)の分割
【原出願日】平成16年2月18日(2004.2.18)
【出願人】(500046438)マイクロソフト コーポレーション (3,165)
【Fターム(参考)】
【公開日】平成22年1月28日(2010.1.28)
【国際特許分類】
【出願日】平成21年10月26日(2009.10.26)
【分割の表示】特願2004−42173(P2004−42173)の分割
【原出願日】平成16年2月18日(2004.2.18)
【出願人】(500046438)マイクロソフト コーポレーション (3,165)
【Fターム(参考)】
[ Back to top ]