JP2003233508A

JP2003233508A - コンピューティングシステム中のコプロセッサの計算リソースを制御するための方法およびコンピューティング装置

Info

Publication number: JP2003233508A
Application number: JP2003000689A
Authority: JP
Inventors: Nicholas P Wilt; ピー．ウィルトニコラス; Sameer A Nene; エー．ネネサミール; Joseph S Bede Iii; エス．ベーダザサードジョーゼフ
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2002-01-04
Filing date: 2003-01-06
Publication date: 2003-08-22
Also published as: EP1326165A3; US7234144B2; CN101685391B; CA2415583A1; CN1549964A; US7631309B2; US20030140179A1; WO2003058431A1; HK1140564A1; EP1326165A2; CN101685391A; US20070136730A1

Abstract

(57)【要約】【課題】コンピューティングシステム中のグラフィッ
クスプロセッサなどのコプロセッサの計算リソースを管
理するためのシステムおよび方法を提供する。【解決手段】コマンドバッファが作成され初期化され
初期化状態２０１に入る。スレッドはコマンドバッファ
をサブミットする。コマンドバッファは待機状態２０３
に入り、待機基準を満たした後コマンドバッファはレデ
ィ状態２０４に入る。コマンドバッファを実行するもの
として選択した後、スタンバイ状態２０５に入る。シス
テムはコンテキストをコマンドバッファの要求するコン
テキストに切り換え、コマンドバッファをハードウェア
にサブミットする。コマンドバッファは実行されるまで
実行状態２０６のままである。コマンドバッファが実行
され終了状態２０７に入り、再初期化するのに利用可能
となり、初期化状態２０１で別のスレッドから利用可能
となる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、コンピューティン
グシステム中のコプロセッサの計算リソースを制御する
ための方法およびコンピューティング装置に関する。

【０００２】

【従来の技術】１９６０年代半ばの、最初のタイムシェ
アリングシステムに始まり、オペレーティングシステム
(OS)は、複数のアプリケーションが互いについての認識
を有さずにコンピュータの計算リソースを共用すること
を可能にする多数の方法を実装してきた。各アプリケー
ションに小さな「タイムスライス」を割り振り、「タイ
ムスライス」が満了したときに中断することにより、コ
ンピュータは、各アプリケーションがコンピュータ上で
単独で動作しているかのように各アプリケーションを呈
示することができる。例えば、２つのアプリケーション
は、１ミリ秒のタイムスライスを用いてシステム上で動
作することができる。このような場合、各アプリケーシ
ョンは、それぞれ毎秒５００タイムスライスを得て、コ
ンピュータ上で単独で動作している場合の速度の半分よ
りも幾分低速に動作する(２つの間でスワップするのに
必要なオーバーヘッドのため)。タイムスライスを長く
するとオーバーヘッドが減少するが、実行の細分性も粗
くなり、タイミングに敏感なアプリケーションに対して
システムが適さなくなる。

【０００３】対話して、中央演算処理装置(CPU)の計算
リソースを共用することを可能にするソフトウェアモデ
ルをアプリケーションに提供する仮想メモリ、プロセ
ス、およびスレッドなどの様々な抽象化の開発に、多大
の労力が注がれてきた。しかし、これらの抽象化は、グ
ラフィックスプロセッサ(GPU)ならびにホストマイクロ
プロセッサでの計算リソースの管理に適用できるように
はまだ向上していない。

【０００４】この点で、過去数年において、グラフィッ
クスプロセッサは著しく実用的になった。PCグラフィッ
クスチップ中のトランジスタの数は、Mooreの法則が示
唆するよりもずっと早く増加している。すなわち、グラ
フィックスチップ中のトランジスタの数は、１９９５年
の約２０００００トランジスタから２００１年には６０
００００００トランジスタまで増加した。このチップの
計算能力もトランジスタの数と共に増加した。すなわち
グラフィックスチップは、より多くのデータを処理でき
るだけでなく、データに対してより複雑な計算を適用す
ることもできる。その結果、今日では、コンピュータシ
ステム中のグラフィックスチップは、ホストマイクロプ
ロセッサの計算リソースを補う計算リソースとみなすこ
とができる。

【０００５】グラフィックスチップによって呈示される
ソフトウェアモデルは、ホストマイクロプロセッサによ
って呈示されるソフトウェアモデルとは幾分異なる。ど
ちらのモデルも、プロセッサが行っていることを正確に
記述する１組のデータであるコンテキストを含む。コン
テキストは、現在実行されているどんなオペレーション
の中間結果も含むデータレジスタ、またはプロセッサが
あるオペレーションを実行するときのプロセッサの挙動
を変更する制御レジスタを含むことができる。３２ビッ
トINTEL(登録商標)プロセッサ上では、EAXデータレジス
タがアキュムレータとして使用され、乗算の実行、関数
の返り値の保持などが行われる。浮動小数点制御語(FPC
W)は、浮動小数点命令が不正確な結果をどのように丸め
るか(単精度、倍精度、または拡張精度、正または負の
無限大に向けて、ゼロに向けて、あるいは最近隣に向け
てなど)を制御する制御レジスタである。しかし通例と
して、グラフィックスプロセッサは、汎用マイクロプロ
セッサよりも制御レジスタ中にずっと多くの状態を有す
る。グラフィックスプロセッサの高い性能は、そのパイ
プライン型の、柔軟で、しかも固定の関数アーキテクチ
ャに由来する。グラフィックスプロセッサで実行される
オペレーションをセットアップするには、多数の制御レ
ジスタ状態が必要である。例えば、１組の制御レジスタ
は、(a)現在入力として供給されている１つまたは複数
のテクスチャマップのベースアドレスおよび寸法、(b)
テクスチャ値と補間されるカラー値との間で実行される
ブレンドオペレーションであるテクスチャアドレッシン
グモードおよびフィルタリングモード、(c)フラグメン
トのアルファ値およびZ値に適用し、フラグメントをカ
ラーバッファに組み込むかどうかを判定するテスト、
(d)カラーフラグメントをカラーバッファに組み込むと
きに最終レンダリングステージで使用するアルファブレ
ンドオペレーションを含むことができる。グラフィック
スプロセッサはその処理を制御するイテレータ（iterat
or）などの多数のスクラッチレジスタを含むが、一般に
は、コンテキスト切換えを保存することが必要な細分性
に対してコンテキスト切換えは許可されないので、コン
テキストが切り換わる間にそれらのレジスタを保存する
必要はない。いずれにしても、コンテキスト切換え中に
そのようなレジスタを保存しなければならない場合であ
っても、一般にレジスタはソフトウェアアプリケーショ
ンから直接利用可能ではない。クライアントソフトウェ
アに対する揮発性レジスタ状態の不透明度は、グラフィ
ックスプロセッサによって呈示されるソフトウェアモデ
ルを、汎用マイクロプロセッサによって呈示されるソフ
トウェアモデルと比較したときの単なる１つの相違に過
ぎない。

【０００６】今日まで、グラフィックスプロセッサなど
のコプロセッサの計算リソースを管理する試みは、良く
てもその場しのぎのものであった。歴史的には、一度に
１つのアプリケーションしかアクティブではなかったの
で、この計算リソースを注意深く管理することについて
多くの要求があった。３Dアクセラレーションハードウ
ェアが当初３Dモデリングおよび３Dアニメーションなど
を加速するように設計された市販のワークステーション
アプリケーションの状況では、エンドユーザは、一般に
一度に１つのアプリケーションを操作する。複数のアプ
リケーションが所与の時間にアクティブであっても、エ
ンドユーザは、別のアプリケーションに切り換えるまで
に各アプリケーション上で著しい量の作業を実行するこ
とになり、アプリケーション間の切換えの細分性は、数
秒程度、あるいはそれよりずっと長い。ゲームアプリケ
ーションは、グラフィックスハードウェアアクセラレー
ションからかなりの利益を得るアプリケーションの第２
の組であり、やはり一般に一度に１つのアプリケーショ
ンが動作する。実際、WINDOWS(登録商標)中のDIRECTX
(登録商標)アプリケーションプログラミングインターフ
ェース(API)により、特にゲームアプリケーションがコ
ンピュータシステム、具体的にはグラフィックスチップ
中のハードウェアリソースへの排他的アクセスを得るこ
とが可能になる。

【０００７】グラフィックスチップがより実用的になる
につれ、グラフィックスチップからの著しい計算リソー
スを要求するアクティブなアプリケーションの数が増加
し、このアプリケーション間の切換えの細分性がより細
かくなることを予期することは妥当なことである。ある
領域では、この傾向は既に明らかとなっている。例え
ば、ハードウェアアクセラレーテッドモーション補償
(「mocomp」)およびIDCT（integer discrete cosine tr
ansform)などのビデオ復号化アクセラレーションが、２
００１年にほとんどのグラフィックスチップに追加され
た。ビデオ再生アプリケーションを立ち上げ、同時に他
のアプリケーションを実行することが可能であるので、
ビデオを再生し、グラフィックスプロセッサからの計算
リソースを要求する他の任意のアプリケーションを実行
することは、ビデオ再生と他のアプリケーションがどち
らも高品質なエンドユーザ体験を達成することを保証す
るために、それらのリソースの注意深い管理が必要とな
る。

【０００８】グラフィックスプロセッサの計算リソース
を求める要求を増大させる他の潜在的ソースには、複数
のアプリケーションの出力の合成や、GDI(グラフィカル
デベロッパインターフェース)またはGDI+などの２Dグラ
フィックスAPIによるハードウェアアクセラレーション
の利用率の向上が含まれる。手短に言えば、コンピュー
ティングシステム中のグラフィックスプロセッサの計算
リソースの効率的かつ効果的な管理の必要は、グラフィ
ックプロセッサ自体の能力、柔軟性、および速度の向
上、ならびにグラフィックスプロセッサの計算リソース
を同時に使用するアプリケーションの数の増加と共にの
み増大することになる。

【０００９】いくつかの文献に上述のような従来の技術
に関連した技術内容が開示されている（例えば、非特許
文献１〜４参照）。

【００１０】

【非特許文献１】Bankston,J他「Pipeline Processing
with Modula-2」J.Pascal AdaModula 2、１９８６年、
５（５）、ｐ．４６−５１

【００１１】

【非特許文献２】Naktsuka,Y他「A One Chip Super Gra
phics CPU with Direct Unified Memory Controller Su
itable for Car Car Information and Control Syste
m」Proceeding of the IEEE 2001 Custom Integrated C
ircuits Conference、２００１年、ｐ．４２１−４２３

【００１２】

【非特許文献３】Randall,M「Graphics IC Simplifies
Design, Boosts Performance」Computer Design、１９
８６年、２５（１１）、ｐ．７３−７７

【００１３】

【非特許文献４】Williams,T「Graphics Processor Boa
sts Virtual Memory」ComputerDesign、１９８６年、２
５（７）、ｐ．４３−４４

【００１４】

【発明が解決しようとする課題】上述のように、マルチ
タスク環境で複数のアプリケーションを効率的に実行す
ることを容易にするという点において、上記従来技術に
は未だ改善の余地があった。

【００１５】本発明は、このような課題に鑑みてなされ
たもので、その目的とするところは、計算リソースの効
率的な管理を可能とするコンピューティングシステム中
のコプロセッサの計算リソースを制御するための方法お
よびコンピューティング装置を提供することにある。

【００１６】

【課題を解決するための手段】上記に鑑みて、本発明
は、コンピューティングシステム中のグラフィックスプ
ロセッサなどのコプロセッサの計算リソースを管理する
ためのシステムおよび方法を提供する。このシステムお
よび方法により、コプロセッサの計算リソースの管理が
例示され、マルチタスク環境での複数のアプリケーショ
ンの効率的な実行が容易となる。複数の実行スレッドが
コマンドバッファを並列に構成することを可能にし、オ
ペレーティングシステムでスケジューリングおよびディ
スパッチするためにこのコマンドバッファをサブミット
（submit）し、かつコマンドバッファの完了を通知する
割込みを処理することにより、このシステムは、このシ
ステムで利用可能な複数のアプリケーションが計算リソ
ースを効率的に共有することを可能とする。

【００１７】様々な実施形態では、本発明は、ホストプ
ロセッサを有するホストコンピューティングシステム中
のコプロセッサの計算リソースを制御する方法を提供す
る。この方法は、ホストプロセッサによってコプロセッ
サにサブミットされるコマンドバッファでコンピューテ
ィングシステムの１つまたは複数のコプロセッサを制御
するステップと、コマンドバッファ中のコマンドに応答
してホストコンピューティングシステムにデータを送り
戻すステップと、ホストコンピューティングシステム中
に含まれるオブジェクトを管理することによってコマン
ドバッファの伝送をスケジューリングするステップとを
含み、コプロセッサの計算リソースは、ホストコンピュ
ーティングシステム上でインスタンス化された複数のア
プリケーションから同時に利用可能である。

【００１８】関係する実施形態および他の実施形態で
は、本発明は、コンピューティング装置と、ホストプロ
セッサを有するホストコンピューティングシステム中の
コプロセッサの計算リソースを制御するための複数のコ
ンピュータ実行可能モジュールが格納されたコンピュー
タ読み取り可能な記録媒体とを提供する。このコンピュ
ーティング装置およびコンピュータ実行可能モジュール
はそれぞれ、ホストプロセッサによってコプロセッサに
サブミットされるコマンドバッファでコンピューティン
グシステムのコプロセッサを制御し、かつコマンドバッ
ファの伝送をスケジューリングするための管理オブジェ
クトを含む。このコンピューティング装置およびコンピ
ュータ実行可能モジュールはまた、コマンドバッファ中
のコマンドに応答してホストコンピューティングシステ
ムにデータを送り戻すための手段をそれぞれ含み、それ
によってコプロセッサの計算リソースは、ホストコンピ
ューティングシステム上でインスタンス化された複数の
アプリケーションから同時に利用可能である。

【００１９】本発明の他の特徴および実施形態を以下で
説明する。

【００２０】添付の図面を参照しながら、グラフィック
スプロセッサの計算リソースを管理するためのシステム
および方法をさらに説明する。

【００２１】

【発明の実施の形態】以下、図面を参照して本発明の実
施形態を詳細に説明する。

【００２２】概説従来の技術で述べたように、グラフィックスプロセッサ
の計算リソースを求める要求を増大させる、多くの現時
点でのソースおよび潜在的ソースが存在する。これらの
ソースのうちの複数がほぼ同時にグラフィックスプロセ
ッサへのアクセスを要求するとき、グラフィックスプロ
セッサは、両方のソースに対して要求を十分に満たすよ
うに自由に機能できない可能性がある。したがって、本
発明は、グラフィックスプロセッサなどのコプロセッサ
装置の計算リソースが要求側アプリケーションに効率的
に配布されることを保証するために、複数のアプリケー
ションによるグラフィックス処理要求のスケジューリン
グおよびディスパッチを管理する様々な方式を提供す
る。したがって、本発明は、ホストコンピューティング
システム中のコプロセッサの計算リソースを制御するた
めの方法およびシステムを提供する。このコプロセッサ
は、ホストプロセッサによってサブミットされるコマン
ドバッファで制御され、コプロセッサへのコマンドバッ
ファの伝送のスケジューリングは、ホストコンピューテ
ィングシステムの、オペレーティングシステムなどのオ
ブジェクトによって実施され、コプロセッサの計算リソ
ースが複数のアプリケーションに対して同時に利用可能
となる。

【００２３】用語集以下は、以下の発明の詳細な説明で使用される様々な用
語を参照するための用語の簡潔なリストと、対応する定
義である。

【００２４】アクセラレーテッドグラフィックスポート
(AGP)は、ホストマイクロプロセッサからグラフィック
ス周辺機器へのデータの迅速な伝送を容易にするように
設計された高速バスである。

【００２５】コマンドバッファは、グラフィックスハー
ドウェアによる消費のために用意されたハードウェア特
有の描画コマンドのストリームである。例えば下記のト
ークンストリームについて定義を参照されたい。

【００２６】コンテキストは、プロセッサでコマンドを
実行するのに利用するハードウェア状態である。本明細
書では、スレッドコンテキストは、ホストマイクロプロ
セッサのハードウェア状態を指し、ハードウェアコンテ
キストは、グラフィックスハードウェアの状態を指す。
コンテキストは、(ホスト上の)命令または(グラフィッ
クスチップ上の)コマンドのストリームが実行できるよ
うになる前にロードされる。

【００２７】中央演算処理装置(CPU)はホストマイクロ
プロセッサを含む。

【００２８】デバイスドライバインターフェース(DDI)
は、ハードウェアドライバと対話するためにオペレーテ
ィングシステムが使用する標準化インターフェースであ
る。

【００２９】表示リストは、記録されたグラフィックス
ハードウェアに対する一連のコマンドであり、それによ
って、元の一連のコマンドが再び実行された場合に、コ
マンドをより効率的に、容易に「再生」することができ
るとされている。表示リストは、しばしばアプリケーシ
ョンに対して不透明である。すなわち表示リストは編集
することができない。表示リストはハードウェア特有の
形式に変換されているからである。

【００３０】ダイナミックリンクライブラリ(DLL)は、
複数のプロセスに同時にリンクすることができ、複数の
プロセスで同時に共用することができる実行可能コード
の単位である。この文書では、DLL中のコードはユーザ
モードで実行されると想定する。

【００３１】ダイレクトメモリアクセス(DMA)は、周辺
機器がホストアクセス可能メモリを直接読み書きするこ
とを可能にするハードウェア機能である。

【００３２】DPC（deferred procedure call)は、通常
は割込みに応答して実行されるが、割込みサービスルー
チン(下記のISRを参照)よりもわずかに低い優先順位で
動作する、WINDOWS(登録商標)などのオペレーティング
システムによって呼び出されるルーチンである。通例と
して、割込みサービスルーチンは、割込みに応答するの
に必要な他の作業を行うために、割込みを解決し、DPC
を待ち行列に入れるのに必要な最小限の処理を行うべき
である。

【００３３】グラフィックスプロセッサは、ビットブロ
ック転送(BLT)などのグラフィックス用の描画コマン
ド、ならびに三角形ラスタ化などの３Dグラフィックス
プリミティブ描画プロセスを加速するように設計された
ハードウェア周辺機器である。この点で、グラフィック
スプロセッサを、ホストマイクロプロセッサのより一般
的で扱いにくいリソースと対比することができる。

【００３４】ホストマイクロプロセッサは、オペレーテ
ィングシステム、および/またはオペレーティングシス
テム中で動作するアプリケーションを実行するプロセッ
サである。システム中のホストマイクロプロセッサは、
グラフィックスプロセッサ、またはシステム中の他の計
算リソースとは対照的である。

【００３５】割込みは、周辺装置がホストマイクロプロ
セッサの現プロセスからホストマイクロプロセッサをそ
らし、制御をメモリ中の特別な位置に移転することを可
能にするハードウェア機能である。オペレーティングシ
ステムはこの機構を使用して、割込みサービスルーチン
(ISR)として知られるドライバコードを呼び出し、割込
みに応答する。

【００３６】割込みサービスルーチン(ISR)は、ドライ
バによって制御されるハードウェアが割込みを信号で知
らせたときにオペレーティングシステムによって呼び出
される、通常はデバイスドライバ中の関数である。例え
ばDPCも参照されたい。

【００３７】Just-in-time(JIT)コンパイルは、ソース
コードからオブジェクトコードへの変換で余分のステッ
プを導入するコンパイルプロセスである。この点で、ソ
ースコードは、容易にコンパイル可能なハードウェア独
立の中間言語に変換され、この中間言語がクライアント
コンピュータに送られ、そこで中間言語は、クライアン
ト上で動作することができるオブジェクトコードに「ジ
ャストインタイムに」コンパイルされる。

【００３８】カーネルモードは、システムコードがハー
ドウェアリソースへの直接アクセスを有することを可能
にする特権プロセッサモードである。

【００３９】プロセスは、オペレーティングシステム内
の仕事の論理的分割である。WINDOWS(登録商標)では、
プロセスは、仮想アドレス空間、実行可能プログラム、
１つまたは複数の実行スレッド、ユーザのリソース割当
量の一部、およびオペレーティングシステムがプロセス
のスレッドに割り振ったシステムリソースを有する。

【００４０】リソースは、複数のスレッドへの非排他的
アクセス、または単一のスレッドへの排他的アクセスを
与えることができる同期プリミティブである。

【００４１】同期プリミティブは、クリティカルセクシ
ョン、mutex、セマフォー、またはイベントなどの共用
リソースへの複数のスレッドのアクセスを同期するのに
使用することができるオブジェクトである。

【００４２】スレッドは、プログラムカウンタ、ユーザ
モードスタック、カーネルモードスタック、および１組
のレジスタ値を有する実行可能エンティティである。

【００４３】トークンストリームは、１連の描画オペレ
ーションを記述するハードウェア独立なトークンのスト
リームである。トークンストリームは、ドライバなどの
ハードウェア特有のソフトウェアコンポーネントによっ
て、コマンドバッファまたは他の一連のハードウェアコ
マンドに変換することができる。

【００４４】ユーザモードは、コードがハードウェアリ
ソースに直接アクセスすることを許可されない、ホスト
マイクロプロセッサのモードである。

【００４５】例示的ネットワーク環境および分散環境コンピュータまたはその他のクライアント装置またはサ
ーバ装置は、コンピュータネットワークの一部として、
あるいは分散コンピューティング環境中に配置できるこ
とを当業者は理解できよう。この点で、本発明は、任意
の数のメモリ装置または記憶装置と、コプロセッサのリ
ソースに要求を行うことができる、任意の数の記憶装置
または記憶ボリュームにわたって生じる、任意の数のア
プリケーションおよびプロセスとを備える任意のコンピ
ュータシステムに関する。本発明は、リモートまたはロ
ーカルの記憶装置を有する、ネットワーク環境に配置さ
れたサーバコンピュータとクライアントコンピュータを
備える環境、すなわち分散コンピューティング環境に適
用することができる。本発明はまた、リモートまたはロ
ーカルのサービスと共に情報を生成、受信、および送信
するためのプログラミング言語機能、解釈能力および実
行能力を備えるスタンドアロンのコンピューティング装
置にも適用することができる。

【００４６】分散コンピューティングは、コンピューテ
ィング装置間およびコンピューティングシステム間の直
接の交換によりコンピュータリソースとサービスを共有
することを容易にする。このリソースとサービスには、
情報の交換、キャッシュ記憶、およびファイルのディス
ク記憶が含まれる。分散コンピューティングはネットワ
ーク接続性を利用して、クライアントがその全体の能力
を活用して企業全体に利益をもたらすことを可能にす
る。これに関して、様々な装置が、本発明の技法によっ
て管理されるコプロセッシングリソースに対して要求を
行うことができるアプリケーション、オブジェクト、ま
たはリソースを有することができる。

【００４７】図１Ａに、例示的なネットワーク環境また
は分散コンピューティング環境の略図を示す。この分散
コンピューティング環境は、コンピューティングオブジ
ェクト１０a、１０bなど、ならびにコンピューティング
オブジェクトまたはコンピューティング装置１１０a、
１１０b、１１０cなどを含む。これらのオブジェクト
は、プログラム、メソッド、データストア、プログラマ
ブルロジックなどを含むことができる。このオブジェク
トは、PDA、テレビジョン、MP３プレーヤ、パーソナル
コンピュータなど、同じ装置あるいは異なる装置の一部
を有することができる。各オブジェクトは、通信ネット
ワーク１４によって相互に通信することができる。この
ネットワーク自体は、図１Ａのシステムにサービスを提
供する他のコンピューティングオブジェクトとコンピュ
ーティング装置を含むことができる。本発明の一態様に
よれば、各オブジェクト１０ａ、１０ｂまたは１１０ａ
〜１１０ｅは、ホストシステムのコプロセッシングリソ
ースを要求する可能性のあるアプリケーションを含む可
能性がある。

【００４８】分散コンピューティングアーキテクチャで
は、従来はもっぱらクライアントとして使用されてきた
コンピュータが相互に直接通信し、ネットワークにとっ
て最も効果的な役割が何であるかを推定して、クライア
ントとサーバのどちらとしても機能することができる。
これによりサーバの負荷が軽減され、すべてのクライア
ントが他のクライアント上で利用可能なリソースにアク
セスすることが可能になり、その結果ネットワーク全体
の機能と効率が向上する。したがって、本発明によるコ
プロセッシングリソースの管理は、クライアントとサー
バの間で分散することができ、ネットワーク全体にとっ
て効率的な方式で専用のコプロセッシングを管理するよ
うに動作することができる。

【００４９】分散コンピューティングは、ビジネスが種
々の地理的境界を越えてサービスと機能をより効率的に
配信するための助けとすることができる。さらに分散コ
ンピューティングは、データが消費される地点のより近
くにデータを移動させることができ、ネットワークのキ
ャッシング機構として機能する。分散コンピューティン
グはまた、コンピューティングネットワークがインテリ
ジェントエージェントを使用して動的に協働することも
可能にする。エージェントはピアコンピュータ上に常駐
し、様々な種類の情報を通信する。エージェントは、他
のピアシステムの代わりにタスクを開始することもでき
る。例えば、インテリジェントエージェントを使用し
て、ネットワーク上のタスクを優先順位付けし、トラフ
ィックフローを変更し、ローカルにファイルを検索し、
あるいはウィルスなど異常な挙動を判定し、ネットワー
クに影響を及ぼす前にそれを阻止することができる。他
のすべての種類のサービスも同様に企図することができ
る。実際には、非常に専門化されたコプロセッシングリ
ソースは、物理的に１つまたは複数の場所に位置する可
能性があり、そのリソースの使用を要求するアプリケー
ションの管理は、そのようなシステムで非常に有用であ
る。

【００５０】さらに、１１０cなどのオブジェクトを別
のコンピューティング装置１０ａ、１０ｂまたは１１０
ａ、１１０ｂ等上でホストできることも理解されよう。
したがって、図の物理的環境では接続された装置をコン
ピュータとして示しているが、この図は単なる例であ
り、その代わりに、PDA、テレビジョン、MP３プレーヤ
など様々なデジタル装置や、インターフェース、COMオ
ブジェクトなどのソフトウェアオブジェクトを含む物理
的環境を図示または説明することもできる。

【００５１】分散コンピューティング環境をサポートす
るシステム、コンポーネント、およびネットワーク構成
には様々なものがある。例えば、ワイヤラインシステム
または無線システム、ローカルネットワークまたは広域
分散ネットワークによってコンピュータシステムを共に
接続することができる。現在ネットワークの多くはイン
ターネットに結合されているが、インターネットは広域
分散コンピューティングのためのインフラストラクチャ
を提供し、多くの異なるネットワークを包含する。

【００５２】ホームネットワーキング環境では、電力
線、データ(無線および有線の両方)、音声(例えば電
話)、およびエンターテイメントメディアなどの固有の
プロトコルをそれぞれサポートすることができる、少な
くとも４つの異なるネットワーク移送媒体が存在する。
光スイッチおよび電気器具などの大部分の家庭制御装置
は、接続性のために電力線を使用することができる。デ
ータサービスは、ブロードバンド(例えば、DSLまたはケ
ーブルモデム)として家庭に入ることができ、無線(例え
ばHomeRFまたは８０２.１１b)接続性または有線(例えば
Home PNA、Cat ５、さらには電力線)接続性を使用して
家庭内でアクセス可能である。音声トラフィックは、有
線(例えばCat ３)または無線(例えば携帯電話)として家
庭に入ることができ、Cat ３配線を使用して家庭内に配
布することができる。エンターテイメントメディアは、
衛星またはケーブルを介して家庭に入ることができ、通
常は同軸ケーブルを使用して家庭内に配布される。IEEE
１３９４およびDVIもメディア装置のクラスタ用のデジ
タル相互接続として登場しつつある。これらのネットワ
ーク環境のすべて、およびプロトコル標準として登場す
る可能性のある他の環境は、相互接続してイントラネッ
トを形成することができ、イントラネットはインターネ
ットによって外界に接続することができる。手短に言え
ば、データを格納および伝送するための様々な異なるデ
ータ源が存在し、したがってコンピューティング装置
は、グラフィックスチップによるデータの処理に付随す
る、アクセスまたは使用されるデータなどのデータを共
用する方法が必要となる。

【００５３】一般に、インターネットとは、コンピュー
タネットワーキングの分野では非常によく知られるTCP/
IPプロトコル一式を利用するネットワークとゲートウェ
イの集合を指す。TCP/IPは「伝送制御プロトコル/イン
ターネットプロトコル」の頭字語である。インターネッ
トは、ユーザがネットワークを通じて対話し、情報を共
有することを可能にするネットワーキングプロトコルを
実行するコンピュータによって相互接続された、地理的
に分散したリモートコンピュータネットワークからなる
システムとして説明することができる。この広範囲にわ
たる情報の共有のために、一般にインターネットなどの
リモートネットワークは、現在までの発展の結果、開発
者が専門化した動作やサービスを実施するためのソフト
ウェアアプリケーションを基本的に制約を受けずに設計
することができるオープンシステムとなっている。

【００５４】したがって、このネットワークインフラス
トラクチャにより、クライアント/サーバ、ピアツーピ
ア、あるいはハイブリッドアーキテクチャなど多くのネ
ットワークトポロジが可能になっている。「クライアン
ト」とは、それが関連していない別のクラスまたはグル
ープのサービスを使用するあるクラスまたはグループの
メンバである。したがって、コンピューティングの際、
クライアントは、別のプログラムによって提供されるサ
ービスを要求するプロセス、すなわち大まかに言うと１
組の命令またはタスクとなる。クライアントプロセス
は、他のプログラムあるいはサービス自体についての動
作上の詳細を一切「知る」必要なしに、要求したサービ
スを利用する。クライアント/サーバアーキテクチャ、
特にネットワーク化されたシステムでは、クライアント
は通常、例えばサーバなど別のコンピュータが提供する
共有ネットワークリソースにアクセスするコンピュータ
である。図１Ａの例では、コンピュータ１１０a、１１
０bなどをクライアントとみなすことができ、コンピュ
ータ１０a、１０bなどをサーバとみなすことができる
が、この場合はサーバ１０a、１０bなどがデータを維持
し、次いでそのデータをクライアントコンピュータ１１
０a、１１０bなどで複製する。

【００５５】サーバは通常、インターネットなどのリモ
ートネットワークを介してアクセスすることのできるリ
モートコンピュータシステムである。第１のコンピュー
タシステムでクライアントプロセスをアクティブにする
ことができ、第２のコンピュータシステムでサーバプロ
セスをアクティブにすることができ、通信媒体を通じて
相互に通信することにより、分散した機能が提供され、
複数のクライアントがサーバの情報収集機能を利用する
ことが可能となる。

【００５６】クライアントとサーバは、プロトコル層に
よって提供される機能を利用して相互に通信する。例え
ば、ハイパーテキスト転送プロトコル(HTTP)は、ワール
ドワイドウェブ(WWW)、あるいは簡単に「Web」と共に使
用される一般的なプロトコルである。通常、ユニバーサ
ルリソースロケータ(URL)あるいはインターネットプロ
トコル(IP)アドレスなどのコンピュータネットワークア
ドレスを使用して、サーバコンピュータまたはクライア
ントコンピュータを相互に識別する。ネットワークアド
レスは、ユニバーサルリソースロケータアドレスと呼ぶ
ことができる。例えば、通信は通信媒体を介して提供す
ることができる。具体的には、クライアントとサーバは
高容量通信用のTCP/IP接続を介して相互に結合すること
ができる。

【００５７】したがって、図１Ａは、本発明を用いるこ
とができる、サーバがネットワーク/バスを介してクラ
イアントコンピュータと通信する例示的ネットワーク環
境あるいは分散環境を示している。より詳細には、いく
つかのサーバ１０a、１０bなどが、通信ネットワーク/
バス１４を介して、携帯型コンピュータ、ハンドヘルド
コンピュータ、シンクライアント、ネットワーク電気器
具などの複数のクライアントあるいはリモートのコンピ
ューティング装置１１０a、１１０b、１１０c、１１０
d、１１０eなど、あるいはVCR、TV、オーブン、照明、
ヒーターなど本発明による他の装置と相互接続されてい
る。通信ネットワーク/バス１４はLAN、WAM、イントラ
ネット、インターネットなどでよい。したがって、コプ
ロセッサの計算リソースを管理することが望ましい任意
のコンピューティング装置に本発明を適用できることが
企図される。

【００５８】例えば通信ネットワーク/バス１４がイン
ターネットであるネットワーク環境では、例えばサーバ
１０ａ、１０ｂをウェブサーバとすることができ、クラ
イアント１１０a、１１０b、１１０c、１１０d、１１０
eなどはハイパーテキスト転送プロトコル(HTTP)などい
くつかの周知のプロトコルを介してこのサーバと通信す
る。サーバ１０ａ、１０ｂは、分散コンピューティング
環境の特色であるが、クライアントとして機能すること
もできる。通信は、必要に応じて有線でも無線でもよ
い。クライアント装置１１０a、１１０b、１１０c、１
１０d、１１０eは、通信ネットワーク/バス１４を介し
て通信してもしなくともよく、またそれに関連付けられ
た独立した通信を備えることができる。例えば、TVやVC
Rの場合は、その制御にネットワーク化された性質があ
ってもなくともよい。クライアントコンピュータ１１０
a、１１０b、１１０c、１１０d、１１０eとサーバコン
ピュータ１０ａ、１０ｂはそれぞれ、様々なアプリケー
ションプログラムモジュールあるいはオブジェクト１３
５ａ〜１３５ｅを備えることができ、また、ファイルを
それらにわたって格納し、あるいはファイルの一部をそ
れらにダウンロードまたは移動することが可能な様々な
タイプの記憶要素あるいはオブジェクトへの接続または
アクセスを備えることができる。コンピュータ１０a、
１０b、１１０a、１１０bなどはいずれも、グラフィッ
クスデータiを格納するデータベースまたはメモリ２０
などの、本発明によるデータベース２０または他の記憶
要素の保守および更新を担当することができる。したが
って本発明は、コンピュータネットワーク/バス１４に
アクセスしそれと対話することのできるクライアントコ
ンピュータ１１０a、１１０bと、クライアントコンピュ
ータ１１０a、１１０bなど、あるいはその他の装置、お
よびデータベース２０と対話することのできるサーバコ
ンピュータ１０a、１０bなどを有するコンピュータネッ
トワーク環境で利用することができる。

【００５９】例示的コンピューティング装置図１Ｂと以下の解説は、本発明を実施することが可能
な、適切なコンピューティング環境の簡潔で一般的な説
明を提供するものである。しかし、ハンドヘルド型、携
帯型、およびその他のコンピューティング装置と、すべ
ての種類のコンピューティングオブジェクトを本発明と
共に使用することが企図されることを理解されたい。以
下では汎用コンピュータについて記述するが、これは単
なる一例であり、本発明はネットワーク/バスの相互運
用性と対話を備えるシンクライアントで実施することも
できる。したがって、本発明は、非常に少数あるいは最
低限のクライアントリソースが関係するネットワークホ
ストサービスの環境、例えば電気器具内に配置されたオ
ブジェクトなどの、クライアント装置が単にネットワー
ク/バスへのインターフェースとして機能するネットワ
ーク環境で実施することができる。基本的には、データ
を格納することができ、またはデータを取り出すことの
できるどんな場所でも、本発明のコプロセッサリソース
の管理が動作するのに望ましい、あるいは適切な環境で
ある。

【００６０】必須ではないが、本発明は、装置やオブジ
ェクト向けのサービスの開発者が使用するために、オペ
レーティングシステムを介して実施することができ、か
つ/または計算リソースを管理する助けとなるアプリケ
ーションソフトウェア中に含めることができる。ソフト
ウェアは、クライアントワークステーション、サーバ、
あるいはその他の装置など１つまたは複数のコンピュー
タによって実行されるプログラムモジュールなどのコン
ピュータ実行可能命令の一般的な状況で説明することが
できる。一般に、プログラムモジュールには、特定のタ
スクを実行する、あるいは特定の抽象データタイプを実
装するルーチン、プログラム、オブジェクト、コンポー
ネント、データ構造などが含まれる。通常、プログラム
モジュールの機能は、各種実施形態で必要に応じて組み
合わせても分散させてもよい。さらに、本発明を他のコ
ンピュータシステム構成を用いて実施できることを当業
者は理解されよう。本発明に使用するのに適している可
能性のある他の周知のコンピューティングシステム、環
境、および/または構成には、限定はしないが、パーソ
ナルコンピュータ(PC)、現金自動預払機、サーバコンピ
ュータ、ハンドヘルド装置またはラップトップ装置、マ
ルチプロセッサシステム、マイクロプロセッサベースの
システム、プログラム可能な消費者向け電気器具、ネッ
トワークPC、電気器具、照明、環境制御要素、ミニコン
ピュータ、メインフレームコンピュータなどが含まれ
る。本発明は、通信ネットワーク/バスあるいはその他
のデータ伝送媒体を通じてリンクされたリモートのプロ
セッサでタスクを実行する分散コンピューティング環境
で実施することもできる。分散コンピューティング環境
では、プログラムモジュールはメモリ記憶装置を含むロ
ーカルとリモートの両方のコンピュータ記憶媒体に配置
することができ、クライアントノードがサーバノードと
して振舞うことができる。

【００６１】したがって、図１Ｂは本発明を実施するこ
とのできる適切なコンピューティングシステム環境１０
０の一例を示しているが、上記で明らかにしたようにコ
ンピューティングシステム環境１００は適切なコンピュ
ーティング環境の一例に過ぎず、本発明の使用または機
能の範囲について何らかの制限を示唆するものではな
い。また、コンピューティング環境１００は、例示的動
作環境１００に示す構成要素のいずれか１つあるいは組
合せに関して何らかの依存関係や要件を有するものとも
解釈すべきでない。

【００６２】図１Ｂを参照すると、本発明を実施する例
示的システムは、コンピュータ１１０の形態の汎用コン
ピューティング装置を含む。コンピュータ１１０の構成
要素には、限定はしないが、プロセッサ１２０、システ
ムメモリ１３０、およびシステムメモリを含む様々なシ
ステム構成要素をプロセッサ１２０に結合するシステム
バス１２１を含めることができる。システムバス１２１
は、様々なバスアーキテクチャのいずれかを使用する、
メモリバスあるいはメモリコントローラ、周辺バス、お
よびローカルバスを含むいくつかのタイプのバス構造の
いずれでもよい。例えばこのアーキテクチャには、限定
はしないが、ISA(Industry Standard Architecture)バ
ス、MCA(Micro Channel Architecture)バス、EISA(Enha
nced ISA)バス、VESA(Video Electronics Standards As
sociation)ローカルバス、およびPCI(Peripheral Compo
nent Interconnect)バス(メザニンバスとも称される)が
含まれる。

【００６３】通常、コンピュータ１１０は様々なコンピ
ュータ可読媒体を含む。コンピュータ可読媒体はコンピ
ュータ１１０がアクセスできる利用可能などんな媒体で
もよく、不揮発性媒体と揮発性媒体の両方、リムーバル
媒体とノンリムーバルノンリムーバル媒体の両方を含
む。例えば、限定はしないが、コンピュータ可読媒体に
はコンピュータ記憶媒体と通信媒体が含まれる。コンピ
ュータ記憶媒体には、コンピュータ可読命令、データ構
造、プログラムモジュール、あるいはその他のデータな
どの情報を格納するために任意の方法または技術で実装
された揮発性および不揮発性、リムーバルおよびノンリ
ムーバルノンリムーバルの媒体が含まれる。コンピュー
タ記憶媒体には、限定はしないが、RAM、ROM、EEPROM、
フラッシュメモリまたはその他のメモリ技術、CDROM、
デジタルバーサタイルディスク(DVD)、またはその他の
光ディスク記憶装置、磁気カセット、磁気テープ、磁気
ディスク記憶装置、またははその他の磁気記憶装置、あ
るいは所望の情報を格納するのに使用でき、コンピュー
タ１１０がアクセスが可能などんな媒体も含まれる。通
信媒体は通常、コンピュータ可読命令、データ構造、プ
ログラムモジュール、あるいはその他のデータを、搬送
波または他の移送機構などの変調データ信号で具体化
し、任意の情報配信媒体を含む。用語「変調データ信
号」とは、その特性集合のうち１つまたは複数を有する
信号、または情報を信号中に符号化するような方式で変
化する信号を意味する。例えば、限定はしないが、通信
媒体には、配線ネットワークあるいは直接配線接続など
の配線媒体と、音響、RF、赤外線、およびその他の無線
媒体などの無線媒体が含まれる。上記の媒体のいずれの
組合せもコンピュータ可読媒体の範囲に含めるべきであ
る。

【００６４】システムメモリ１３０は、読取り専用メモ
リ(ROM)１３１およびランダムアクセスメモリ(RAM)１３
２など、揮発性および/または不揮発性メモリの形態の
コンピュータ記憶媒体を含む。起動時などにコンピュー
タ１１０内の要素間で情報を転送する助けとなる基本ル
ーチンを含む基本入出力システム１３３(BIOS)は、通常
ROM１３１に格納される。RAM１３２は通常、プロセッサ
１２０から即座にアクセス可能であり、かつ/またはプ
ロセッサ１２０によって現在操作されているデータおよ
び/またはプログラムモジュールを含む。例えば、限定
はしないが、図１Ｂに、オペレーティングシステム１３
４、アプリケーションプログラム１３５、その他のプロ
グラムモジュール１３６、およびプログラムデータ１３
７を示す。

【００６５】コンピュータ１１０は、その他のリムーバ
ル/ノンリムーバルノンリムーバル、揮発性/不揮発性の
コンピュータ記憶媒体も含むことができる。単なる例に
過ぎないが、図１Ｂに、ノンリムーバルノンリムーバル
な不揮発性の磁気媒体を読み書きするハードディスクド
ライブ１４１、リムーバルな不揮発性の磁気ディスク１
５２を読み書きする磁気ディスクドライブ１５１、およ
びCDROMやその他の光学媒体などのリムーバルな不揮発
性の光ディスク１５６を読み書きする光ディスクドライ
ブ１５５を示す。この例示的動作環境で使用することが
可能なその他のリムーバル/ノンリムーバルノンリムー
バル、揮発性/不揮発性のコンピュータ記憶媒体には、
限定はしないが、磁気テープカセット、フラッシュメモ
リカード、デジタルバーサタイルディスク、デジタルビ
デオテープ、ソリッドステートRAM、固体ROMなどがあ
る。ハードディスクドライブ１４１は通常、インターフ
ェース１４０などノンリムーバルなメモリインタフェー
スを介してシステムバス１２１に接続し、磁気ディスク
ドライブ１５１および光ディスクドライブ１５５は通
常、インターフェース１５０などリムーバルなメモリイ
ンタフェースによってシステムバス１２１に接続する。

【００６６】上記で論じ、図１Ｂに示すドライブと、そ
れに関連するコンピュータ記憶媒体は、コンピュータ１
１０のコンピュータ可読命令、データ構造、プログラム
モジュール、およびその他のデータの記憶を実現する。
例えば図１Ｂでは、ハードディスクドライブ１４１を、
オペレーティングシステム１４４、アプリケーションプ
ログラム１４５、その他のプログラムモジュール１４
６、およびプログラムデータ１４７を格納するものとし
て図示している。これらの構成要素は、オペレーティン
グシステム１３４、アプリケーションプログラム１３
５、その他のプログラムモジュール１３６、およびプロ
グラムデータ１３７と同じものでも異なるものでもよい
ことに留意されたい。ここでは少なくともそれらが異な
る複製であることを表すために、オペレーティングシス
テム１４４、アプリケーションプログラム１４５、その
他のプログラムモジュール１４６、およびプログラムデ
ータ１４７に異なる参照符号をつけている。ユーザは、
キーボード１６２と、一般にマウス、トラックボール、
あるいはタッチパッドと呼ばれるポインティング装置１
６１などの入力装置を介してコンピュータ１１０にコマ
ンドと情報を入力することができる。その他の入力装置
(図示せず)には、マイクロフォン、ジョイスティック、
ゲームパッド、サテライトディッシュ、スキャナなどが
ある。上記およびその他の入力装置は、しばしばシステ
ムバス１２１に結合されたユーザ入力インターフェース
１６０を通じてプロセッサ１２０に接続されるが、パラ
レルポート、ゲームポート、あるいはユニバーサルシリ
アルバス(USB)など他のインターフェースおよびバス構
造によって接続することもできる。ノースブリッジなど
のグラフィックスインタフェース１８２もシステムバス
１２１に接続することができる。ノースブリッジは、CP
Uと通信し、あるいはプロセッサ１２０をホストし、AGP
通信を担当するチップセットである。１つまたは複数の
グラフィックスプロセッサ(GPU)１８４は、グラフィッ
クスインタフェース１８２と通信することができる。こ
れに関してGPU １８４は一般にレジスタ記憶域などのオ
ンチップメモリ記憶域を含み、ビデオメモリ１８６と通
信する。任意のコプロセッサに関連して、本発明をより
一般的に説明することができ、GPU １８４は一例に過ぎ
ない。モニタ１９１またはその他のタイプの表示装置も
ビデオインタフェース１９０などのインターフェースを
介してシステムバス１２１に接続され、ビデオインタフ
ェース１９０はビデオメモリ１８６と通信することがで
きる。コンピュータはモニタ１９１に加えてスピーカ１
９７やプリンタ１９６など他の周辺出力装置も含むこと
ができ、これらの装置は出力周辺インターフェース１９
５を介して接続することができる。

【００６７】コンピュータ１１０は、リモートコンピュ
ータ１８０など１つまたは複数のリモートコンピュータ
への論理接続を使用するネットワーク環境あるいは分散
環境で動作することができる。リモートコンピュータ１
８０は、パーソナルコンピュータ、サーバ、ルータ、ネ
ットワークPC、ピア装置、あるいはその他の共通ネット
ワークノードでよく、図１Ｂにはメモリ記憶装置１８１
しか示していないが、通常は上記でコンピュータ１１０
に関連して説明した要素のうちの多くあるいはすべてを
含む。図１Ｂに示す論理接続には、構内ネットワーク(L
AN)１７１と広域ネットワーク(WAN)１７３が含まれる
が、その他のネットワーク/バスも含むことができる。
このようなネットワーキング環境は、家庭、オフィス、
企業全体のコンピュータネットワーク、イントラネッ
ト、およびインターネットなどで一般的なものである。

【００６８】LANネットワーキング環境で使用すると
き、コンピュータ１１０はネットワークインタフェース
あるいはアダプタ１７０を通じてLAN１７１に接続す
る。WANネットワーキング環境で使用する場合、コンピ
ュータ１１０は通常インターネットなどのWAN１７３を
介して通信を確立するためのモデム１７２あるいはその
他の手段を含む。モデム１７２は内蔵でも外付けでもよ
く、ユーザ入力インターフェース１６０またはその他の
適切な機構を介してシステムバス１２１に接続すること
ができる。ネットワーク環境では、コンピュータ１１０
に関連して図示するプログラムモジュールまたはその一
部をリモートのメモリ記憶装置に格納してもよい。例え
ば、限定はしないが、図１Ｂではリモートアプリケーシ
ョンプログラム１８５がメモリ装置１８１上に常駐して
いる。図のネットワーク接続は例示的なものであり、コ
ンピュータ間に通信リンクを確立する他の手段を使用で
きることを理解されよう。

【００６９】例示的分散コンピューティングフレームワ
ークまたはアーキテクチャパーソナルコンピューティングとインターネットの収束
という観点から、様々な分散コンピューティングのフレ
ームワークが開発されてきた。個人やビジネスユーザに
も同様に、アプリケーションやコンピューティング装置
向けのシームレスな相互運用が可能でWebに対応したイ
ンターフェースが提供され、コンピューティングアクテ
ィビティはますますウェブブラウザ指向またはネットワ
ーク指向になりつつある。

【００７０】例えば、MICROSOFTの.Netプラットフォー
ムは、サーバと、ウェブベースのデータ記憶やダウンロ
ード可能なデバイスソフトウェアなどのビルディングブ
ロックサービスとを含む。大まかに言うと.Netプラット
フォームは次のような機能を提供する。(１)コンピュー
ティング装置の範囲全体を協働させ、それらすべての装
置でユーザ情報を自動的に更新し、同期する能力。(２)
HTMLではなくXMLを多く使用することで可能になる、よ
り高いウェブサイト間の対話機能。(３)例えば電子メー
ルや、Office.Netなどのソフトウェアなどの様々なアプ
リケーションを管理するための、製品およびサービスへ
のカスタマイズされたアクセスと、中央の開始点からユ
ーザへのその配信を特徴とするオンラインサービス。
(４)データ記憶の集中化。これにより情報へのアクセス
と、ユーザと装置間の情報の同期の効率と容易さが向上
する。(５)Eメール、ファックス、電話など様々な通信
媒体を統合する能力。(６)開発者は再使用可能なモジュ
ールを作成することができ、これにより生産性を増し、
プログラミングエラーの数を低減することができる。
(７)その他の多くのクロスプラットフォームの統合機
能。

【００７１】コンピューティング装置上に常駐するソフ
トウェアに関連して本明細書の例示的実施形態を説明す
るが、本発明の１つまたは複数の部分は、オペレーティ
ングシステムを介して、またはコプロセッサと要求側オ
ブジェクトとの間の「仲介」オブジェクトを介して実装
することもでき、その結果.NETの言語およびサービスの
すべてによってイメージ処理サービスを実施することが
でき、.NETの言語およびサービスのすべての中でサポー
トすることができ、または.NETの言語およびサービスの
すべてを介してアクセスすることができる。他の分散コ
ンピューティングフレームワークでも同様である。

【００７２】コンピューティングシステム中の計算リソ
ースの管理 I.グラフィックスプロセッサプログラミングまず、グラフィックスプロセッサを制御するための様々
な機構の簡単な説明とその兼ね合いを呈示する。本発明
の様々な実施形態をグラフィックスプロセッサの状況で
説明するが、本発明はホストプロセッサのオペレーショ
ンを補うコプロセッサに適用することができる。様々な
機構を呈示した後、本発明に従ってグラフィックスプロ
セッサを制御する方法を説明する。本発明の方法は、オ
ペレーティングシステムによるグラフィックプロセッサ
の計算リソースの管理が容易となるように実装される。

【００７３】表１に、グラフィックスハードウェアがコ
マンドを受け取る方式の一部を列挙する。

【００７４】

【表１】

【００７５】最初の方法であるポートI/OすなわちPIO
は、周辺機器から情報を要求するためのIN命令と、周辺
装置に情報を送るためのOUT命令を実行することを含
む。PIOは非常に非効率であり、一般にはシステム中の
所与のハードウェアの複数のインスタンスとは十分には
釣り合わない。その結果、INおよびOUT命令を実行する
ことができるのは、ハードウェアの直接操作が可能なマ
イクロプロセッサモードであるカーネルモードだけであ
る。ユーザモードスレッドがこのような命令に直面した
場合、システムは例外を生成する。ユーザモードスレッ
ドがハードウェアの制御を試みている場合、例外によ
り、通常はスレッドは実行を終了する。

【００７６】メモリマップI/Oは、特別なメモリ位置の
読み書きによってハードウェアを制御することを可能に
する。MMIOの１つの利点は、所与の１つのハードウェア
を制御するメモリ位置を変更することができる場合、ハ
ードウェアの複数のインスタンスが単一のシステム内に
常駐することができることである。いわゆる再配置可能
MMIOは、例えばPCに対する複数モニタサポートに関する
主要な機能であった。PIOと同様に、MMIOは一般に、カ
ーネルモードでカーネルモードアドレスを使用して実行
される。しかし一部のシステムは、ユーザモードに対す
るMMIOアドレスを公開し、それによってハードウェア
が、カーネルモードへの遷移を行わずに直接プログラム
される可能性がある。相互排他は依然として実施しなけ
ればならず、信用できない、またはバグの多い(buggy)
ユーザモードソフトウェアによる偽の書込みが、ハード
ウェアによる予測不能な挙動を引き起こす可能性があ
る。したがって、ほとんどのMMIO実装では、カーネルモ
ードを介してアクセスすべきメモリ位置が必要である
が、一部のMMIO実装では、ハードウェアへのユーザモー
ドアクセスが可能である。このような設計は、ハードウ
ェアがそのレジスタへの偽の書込みに対して堅牢でない
場合、予測不能な、破局的な障害の危険がある。

【００７７】一度にPIOまたはMMIOを実施することがで
きるのは１つのスレッドだけである。これらのオペレー
ションはハードウェアの状態に直接影響を及ぼすからで
ある。したがって、システムがPIOとMMIOのどちらもサ
ポートするとき、システムは、PIOおよび/またはMMIOを
使用してハードウェアに命令を送るコードパス間の相互
排他を実施する。すなわちどんなときでも、ハードウェ
アをプログラムするのは１つのスレッドだけとなること
が保証される。通常、このことは、スレッドがコードを
実行してPIOまたはMMIOを介してハードウェアをプログ
ラムする前に、クリティカルセクションまたはmutex(相
互排他オブジェクト)などのロックを待機しなければな
らないことを意味する。ロックを獲得し、解放すること
は、それに対する競合がない場合であっても時間がかか
る。競合がある場合、すなわち複数のスレッドが同時に
所与のロックを獲得しようと試みる場合、全性能は、多
くのスレッドがロックを獲得するために長時間待機しな
ければならない場合に低下する可能性がある。

【００７８】ダイレクトメモリアクセス(DMA)は、コン
ピュータシステム内でデータを移動する一般的な方法で
あり、ディスクドライブ、ネットワークアダプタ、なら
びにUSBおよびIEEE １３９４などの外部バスの制御だけ
でなく、グラフィックスプロセッサの制御における応用
が見出された。DMAは一般に、デジタルカメラまたはデ
ィスクコントローラなどの周辺装置の能力を参照し、ホ
ストプロセッサを直接使用せずにメモリに読み書きす
る。ホストは、あらかじめDMA転送をセットアップし、
例えばデジタルカメラが撮影しようとしている写真から
のイメージデータを書き込むべき場所のメモリ領域をペ
ージ固定し、そのメモリ位置をカメラに指定する。ペー
ジ固定は、仮想メモリマネージャに、当該のメモリ位置
をディスクに書き出すことを先行させる。これを行った
後、カメラは写真を撮影し、イメージデータをメモリに
書き込み、次いでDMA転送が完了したことをホストに通
知する。グラフィックスプロセッサ制御の状況では、グ
ラフィックスプロセッサに対する一連のコマンドは、メ
モリに書き込むことができ、次いでDMAオペレーション
を介してグラフィックスプロセッサに転送することがで
きる。

【００７９】DMAは、グラフィックスプロセッサコマン
ドをサブミットする他の方法に勝る多くの利点を有す
る。第１に、DMAにより、ホストプロセッサとグラフィ
ックスプロセッサによる並列実行が容易になる。CPUで
実施すべき、これらの「他のオペレーション」はしばし
ば、グラフィックスプロセッサ対にするコマンドをより
多く生成することを含むので、複数のDMAバッファを維
持してそれらを「ピンポン」し、グラフィックスプロセ
ッサが一方を読み取り、実行する間に、他方を書き込む
ことが一般的である。第２に、DMAにより、複数のアプ
リケーションがコマンドバッファをメモリに書き込み、
次いでその複数のアプリケーションの実行の準備ができ
たときに、コマンドバッファの内容をグラフィックスプ
ロセッサにサブミットすることが可能となる。グラフィ
ックスプロセッサが一度に実行できるのは１つのコマン
ドバッファだけであるが、異なるスレッドがコマンドバ
ッファを含む別個のメモリ領域に書込みことができるの
で、DMAにより、多くのコマンドバッファを同時に構築
することが容易になる。第３に、DMAにより、しばしば
システム中のバスリソースの使用がより効率的になる。
言い換えれば、DMAを介して達成可能な帯域幅は、しば
しばホストマイクロプロセッサの直接参加することによ
って達成可能な帯域幅よりも大きい。

【００８０】アクセラレーテッドグラフィックスポート
(AGP)は、システムメモリからグラフィックスプロセッ
サにデータを転送するために高帯域幅コンジットとして
働くように特に設計された特殊なバスである。この説明
では、AGPはDMAの特別な場合とみなすことができる。

【００８１】情報をハードウェアに送達し、情報をハー
ドウェアから受け取るための機構の他に、本発明者らの
背景の解説で行う別の重要な特質は、グラフィックスプ
ロセッサがあるタスクを完了し、またはグラフィックス
プロセッサにとって可視のあるイベントが発生したとい
う、ホストマイクロプロセッサの通知に集中する。タス
クの非限定的な例には、コマンドバッファの実行の完
了、または特定のコマンドの完了が含まれる。イベント
の非限定的な例は、ディスプレイ装置の垂直帰線、ビデ
オポートからのデジタル化ビデオのフィールドの完了、
またはディスプレイ装置中の特定の走査線のリトレーシ
ングが含まれる。

【００８２】ポーリングとして知られる１つの方法は、
ハードウェアを反復的にプローブして、イベントが発生
したか、またはタスクが完了したかを確認するものであ
る。ポーリングは、IN命令またはMMIO読取りでハードウ
ェアレジスタを読み取ること、またはホストがその後で
読み取ることができる特定のメモリ位置に答えを書き込
むよう要求するコマンドを送ることを必要とする。すべ
てのポーリング方法に共通する特徴は、タスクが完了す
るか、イベントが発生するまでチェックを反復的に実施
しなければならないことである。通例として、ポーリン
グはホストマイクロプロセッサ中の計算リソースを浪費
する。

【００８３】ホストマイクロプロセッサにタスクの完了
または外部イベントを通知する代替方法は割込みとして
知られている。割込みは、ホストマイクロプロセッサが
行っていることが何であってもそのことからホストマイ
クロプロセッサをそらせ、メモリ中の特別な位置に制御
を移転するハードウェア機構である。オペレーティング
システムはこの機構を使用して、割込みサービスルーチ
ンとして知られるドライバコードを呼び出し、割込みに
応答する。

【００８４】割込みはポーリングベースの機構に勝るい
くつかの利点を有する。例えば、セットアップし、割込
みに応答するコストは固定であるのに対して、ポーリン
グベースの機構のコストは、実施されるポーリングの数
に対してほぼ線形に増加する。その結果、割込みベース
の方式は、ポーリングベースの方式よりもバス帯域幅が
小さく、CPUサイクルが少ない。割込みはまた、イベン
トが発生するときと次のポーリングが実施されるときの
間の時間よりも割込み待ち時間が短い場合、より適時に
通知することができる。

【００８５】上記の背景を踏まえ、本発明は、グラフィ
ックスプロセッサ中の計算リソースを合理的に管理する
ことを可能にする１組の仮定を展開させる。本発明はま
た、システムがこのような管理の効果性および/または
信頼性を高めることを可能にする、あるハードウェア機
能を識別する。

【００８６】本発明に従って行われる第１の仮定は、主
にDMAベースの入力を使用することである。この第１の
仮定は、グラフィックスプロセッサに対するコマンドの
多くをDMA機構を介してサブミットすべきであるという
ことである。前述のように、DMAベースのコマンドバッ
ファのサブミットにより、ホストマイクロプロセッサ上
で動作する複数のアプリケーションによって生成された
複数のDMAバッファのグラフィックスプロセッサによる
最終的な消費が促進される。DMAコマンドストリームの
実行の開始などの低頻度のコマンドは、MMIOなどの方法
を介してハードウェアに送ることができる。しかし、イ
メージデータのロード、直線および三角形などの特徴を
描画するためのコマンド、およびハードウェア状態を変
更するためのコマンドなど、グラフィックスチップに対
する高頻度のコマンドの大部分はDMAを介して送るべき
である。

【００８７】行われる第２の仮定は、割込みベースの通
知が好ましいということである。したがって、本発明に
よれば、コマンドバッファの完了または一部完了、ホス
トプロセッサにとって可視であるメモリ中にデータを書
き込むためのDMAオペレーションの完了、ディスプレイ
装置の垂直帰線、あるいは特定のコマンドの完了など、
グラフィックスプロセッサによるイベントの通知の大部
分に対して割込みが使用される。したがってホストは、
ホストが認識する必要のあるイベントの割込み通知をセ
ットアップすることが期待され、その割込みに適時応答
することが期待される。

【００８８】これらの仮定を踏まえると、焦点をグラフ
ィックスプロセッサから広げることができ、以下のよう
な２つのプロセッサを備えるシステムを企図することが
できる。そのプロセッサとは、ホストCPUと、CPUからの
コマンドバッファの送出によって制御され、CPUにデー
タを戻すことができ、かつ様々なイベントが発生したと
きにそのイベントをCPUに通知することによって制御を
調整するコプロセッサである。この文書中の例では、
(生じ得る同期の問題と、この問題を効率的に解決する
ようにシステムをどのように設計することができるかを
説明するときのように)しばしばコプロセッサがグラフ
ィックスプロセッサであると仮定するが、それらの例は
単なる例に過ぎず、本発明の範囲をグラフィックスプロ
セッサに限定するものではない。

【００８９】グラフィックス処理システム中の計算リソ
ースに関する上記の仮定に沿って、コプロセッサ中の計
算リソースを効率的に共用する非限定的システムを以下
で説明する。

【００９０】図２に、グラフィックスプロセッサなどの
コプロセッサにコマンドを送るためにコマンドバッファ
がアプリケーションで使用されるときの、コマンドバッ
ファのライフサイクルを示す。コマンドバッファが作成
され、初期化されるとき、バッファは初期化状態２０１
に入る。次いでコマンドバッファは、グラフィックスプ
ロセッサにコマンドを発行しようとするスレッドが選択
し、書き込むために利用可能となる。スレッドがコマン
ドバッファを選択するとき、コマンドバッファ中のメモ
リが、(恐らくコマンドバッファ中のメモリをスレッド
のアドレス空間にマッピングすることによって)そのス
レッドから利用可能となる。当業者は理解できるであろ
うが、このマッピングの詳細は変化する可能性がある。
例えば、コマンドバッファメモリは、ユーザモード、カ
ーネルモード、あるいはその両方から可視にすることが
できる。加えて、受取側コマンドバッファに書き込まれ
る実行可能コードの性質に関して多数の選択肢がある。
この点に関して、図３Ａから３Ｅに、その選択肢のうち
のいくつか、すなわちコマンドバッファに書き込むため
のいくつかの異なるアーキテクチャを示す。

【００９１】図３Ａから３Ｅでは、アプリケーション
は、システムに関与するある特定のグラフィックアプリ
ケーションを実施するプロセス、またはプロセス中のス
レッドである。ランタイムは、アプリケーションが使用
するオペレーティングシステムで提供されるミドルウェ
アである。とりわけ、ランタイムは、アプリケーション
がアプリケーションプログラミングインターフェース(A
PI)を使用することに関する妥当性検査を行うこと、使
用が簡単な高レベルAPI呼出しを、ハードウェアコマン
ドに容易に変換可能な、より複雑な低レベル構成に変換
することなどをすることができる。

【００９２】ドライバは、ランタイムレベルコマンドを
ハードウェア固有のコマンドに変換する、ハードウェア
特有のコンポーネントである。図３Ａから３Ｅに示すド
ライバコンポーネントは、ランタイムレベルコマンドを
ハードウェア特有のコマンドに変換するドライバの一部
である。割込み処理およびコマンドバッファディスパッ
チなど、この変換以外のタスクを実施するドライバのあ
る部分は、恐らくカーネルモードで常駐することにな
り、図３Ａから３Ｅでは考慮していない。図３Ａから３
Ｅに示すオブジェクトコードのほとんどはユーザモード
で動作することができるが、以下で指摘するように、一
部はカーネルモードで動作することができる。コマンド
バッファは、あるDMA機構を介してハードウェアで直接
消費することができるコマンドを含む１つのメモリであ
る。図のうちのいくつかにはトークンストリームも示
す。トークンストリームは、ドライバによってハードウ
ェア特有のコマンドに変換することができるランタイム
レベルプリミティブの、ハードウェア独立なストリーム
である。

【００９３】最後に、図のうちの一部に、ハードウェア
独立な中間言語を、ホストマイクロプロセッサが実行す
るためのオブジェクトコードに変換することができるJI
T(Just-in-time)コンパイルコンポーネントを示す。隅
にOBJと記したボックスは、マイクロプロセッサが直接
実行することができるオブジェクトコードを含む。隅に
MSILと記したボックスは、マイクロプロセッサ上で実行
するためにＪＩＴによってコンパイルされる中間コード
を含む。アプリケーションおよびランタイムがどちらも
クライアント上で中間形式で利用可能である場合、JIT
は、図３Ｃから３Ｅのそれぞれ実行可能アプリケーショ
ン３２４、３３４、および３４５として示す、アプリケ
ーションを実施する統合された１つのオブジェクトコー
ドに、アプリケーションおよびランタイムを変換にする
ことができる。

【００９４】図３Ａは、それぞれの役割を実施して、ド
ライバ３０３がハードウェア特有のコマンドをコマンド
バッファ３０４に書き込むまで、低レベルオブジェクト
コードを呼び出す、アプリケーション３０１、ランタイ
ム３０２、およびドライバ３０３を示す。アプリケーシ
ョン３０１は実行可能プロセス、またはプロセス中のス
レッドでよく、ランタイム３０２およびドライバ３０３
は、それぞれDLL中に常駐することができる。図３Ａに
示すように、オブジェクトコードのすべてはユーザモー
ドに常駐することができる(しかし、ランタイム３０２
および/またはドライバ３０３の一部または全部はカー
ネルモードに常駐することができる)。実行を続行する
前にコマンドバッファ３０４をサブミットしなければな
らないとランタイム３０２が判定した場合、またはコマ
ンドバッファ３０４がスペースを欠いているとドライバ
３０３が判定した場合、続行するために、カーネルモー
ドへの遷移を要求してコマンドバッファ３０４をサブミ
ットし、別のコマンドバッファを取り出すことができ
る。

【００９５】図３Ｂは、ランタイム３１２がハードウェ
ア独立なコマンドのストリームをバッファ３１３に放出
し、次いでバッファ３１３をドライバ３１４で構文解析
し、コマンドバッファ３１５に書き込む変形形態を示
す。アプリケーション３１１は、ランタイム３１２と共
に低レベルオブジェクトコードを呼び出すように動作す
る。図３Ｂは、ランタイムがアプリケーション活動をDr
awPrimitive２(「DP２」)トークンに変換する、DIRECTX
(登録商標)ソフトウェアコンポーネントの現在のアーキ
テクチャを模倣したものである。DP２トークンストリー
ムをサブミットしたとき、カーネル遷移が行われ、ドラ
イバ３１４は、カーネルモードでDP２トークンストリー
ムをハードウェア特有のコマンドに変換する。図３Ｂで
は、ドライバ３１４がユーザモードにあるか、それとも
カーネルモードにあるかについての仮定は行っておら
ず、この点でドライバコンポーネント３１４は、ユーザ
モードならびにカーネルモードで常駐することができ
る。

【００９６】図３Ｃは、アプリケーション３２１および
ランタイム３２２が、JITコンパイラ３２３によって、
統合された１つのオブジェクトコードに合成される変形
形態を示す。次いで、得られる１つのオブジェクトコー
ド３２４はドライバ３２５と対話し、ハードウェア特有
のコマンドをコマンドバッファ３２６に書き込む。

【００９７】図３Ｄは、ハードウェア独立なトークンス
トリーム３３５がドライバ３３６の上のソフトウェア３
３４によって放出される、図３Ｂについて述べた状況の
JIT変形形態を示す。次いでドライバ３３６は、トーク
ンストリームを、コマンドバッファ３３７に対するハー
ドウェア特有のコマンドに変換する。図３Ｃと同様に、
アプリケーション３３１およびランタイム３３２は、JI
Tコンパイラ３３３によって、統合した１つのオブジェ
クトコード３３４に合成される。

【００９８】図３Ｅは、アプリケーション３４１、ラン
タイム３４２、およびドライバ３４３の一部が、すべて
中間言語形MSILでクライアント上で利用可能なシステム
を示す。JITコンパイラ３４４は、これらのコンポーネ
ントを、ホストマイクロプロセッサだけではなくコプロ
セッサハードウェア構成も考慮に入れて、特定のクライ
アントコンピュータ上で動作するように特に最適化され
た、統合された１つのオブジェクトコード３４５に合成
する。

【００９９】図２に示すコマンドバッファライフサイク
ルに戻ると、コマンドがコマンドバッファに書き込まれ
る方法の如何に関わらず、受取側コマンドバッファに書
き込むスレッドは、コマンドバッファが充填されたた
め、またはバッファに書き込まれた描画コマンドが直ち
に実行されるため、コマンドバッファにサブミットす
る。そのとき、コマンドバッファは待機状態２０３に入
り、コマンドバッファの内容は、コマンドバッファを実
行するために使用されるリソースのすべてが利用可能と
なるまで、ハードウェアにサブミットすることができな
い。待機が強制される可能性のある環境の例として、ア
プリケーションが表面に描画する場合、その描画は、表
面がテクスチャとして選択することができる前に完了し
なければならない。

【０１００】待機基準を満たした後、コマンドバッファ
はレディ状態２０４に入り、その状態で、スケジューラ
はコマンドバッファをコプロセッサにサブミットするこ
とに関してコマンドバッファを検討する。スケジューラ
は、どのコマンドバッファをハードウェアにサブミット
すべきかを決定する際に、多大な柔軟性を有する。スケ
ジューラは、コマンドバッファの優先順位、スレッドの
要求についての優先順位、システムのリアルタイム要件
などがある場合、それを考慮に入れることができる。コ
マンドバッファを次に実行するものとして選択した後、
コマンドバッファはスタンバイ状態２０５に入る。ある
システムでは、システム中でスタンバイ状態２０５にす
ることができるのは、コプロセッサ当り１つのコマンド
バッファだけである。

【０１０１】スタンバイ状態２０５のコマンドバッファ
をハードウェアにサブミットすることができるとき、シ
ステムは、コプロセッサコンテキストを、コマンドバッ
ファの要求するコンテキストに切り換え、次いでコマン
ドバッファをハードウェアにサブミットする。このオペ
レーションは、例えばコマンドバッファのベースアドレ
スおよびサイズを使用してDMAオペレーションを開始す
るために、ドライバからの何らかの介入を必要とする。
コマンドバッファは、コマンドバッファの実行があるイ
ベントに切り替わるか、またはコマンドバッファの内容
全体が読み取られ、実行されるまで、実行状態２０６の
ままである。

【０１０２】コマンドバッファ全体が実行された場合、
コマンドバッファは終了状態２０７に入り、その状態
で、コマンドバッファはシステムがシステムを再初期化
するのに利用可能となり、初期化状態２０１で別のスレ
ッドから利用可能となる。

【０１０３】コマンドバッファが切り替わる場合、切り
替えが行われたときにコマンドバッファの実行を再開す
ることができるように、ハードウェアがハードウェアコ
ンテキストを保存する能力を有することが想定される。
次いでコマンドバッファはレディ状態２０４中でリサク
ルすることができ、ハードウェアに再サブミットして、
停止した場所から再開することができる。プリエンプテ
ィブルコマンドバッファ実行に関する以下の説明で、こ
のことをより詳細に述べる。

【０１０４】コンテキスト切換えに関して、上述のシス
テムは、ハードウェアアクセラレーテッド（hardware-a
ccelerated）コンテキスト切換え、または少なくともド
ライバファシリテイティッド（driver-facilitated）コ
ンテキスト切換えに対処することができる。このコンテ
キスト切換えでは、ハードウェアコンテキストがドライ
バによって維持され、コンテキスト切換えをハードウェ
アでネイティブにサポートすることができる。コンテキ
ストは、例えばローカルビデオメモリまたは他の高速メ
モリ内にキャッシュすることができる。この場合、オペ
レーティングシステムは、ドライバが所与のコンテキス
トをハードウェアにロードすることを要求する。コンテ
キスト切換えおよびコマンドバッファディスパッチは、
性能上の理由で、単一のDDI(デバイスドライバインター
フェース)呼出しで指定することができる。

【０１０５】あるいは、オペレーティングシステムはハ
ードウェアコンテキストのカノニカル概念を維持するこ
とができ、所与のコンテキストに対応する状態にハード
ウェアを設定するコマンドバッファを構築することがで
きる。この場合、スタンバイ状態２０５から実行状態２
０６への遷移中にコンテキストをロードすることは、こ
のように構築したコマンドバッファをハードウェアにデ
ィスパッチすることを伴う。あるいは、コマンドバッフ
ァの先頭を任意選択のコンテキスト切換え用に予約する
こともできる。例えばハードウェアが既に適切なコンテ
キストを含んでいるために、コンテキスト切換えがオペ
レーティングシステムで不要とみなされる場合、オペレ
ーティングシステムは、コンテキスト切換えブロックの
すぐ上のコマンドを、コマンドバッファのベースアドレ
スとして指定することができる。オペレーティングシス
テムが別々のコマンドバッファ、コマンドバッファの先
頭、または他の機構を利用して実行の開始前にコンテキ
ストをハードウェアにロードするかに関わらず、ドライ
バの複雑さは軽減される。ドライバは、ハードウェアコ
ンテキストをロードしているか、それとも描画コマンド
を実行しているかを認識せず、ハードウェアにコマンド
バッファをディスパッチしていることだけを認識するこ
とになるからである。しかし、高速メモリを使用するコ
ンテキスト切換えに対するネイティブハードウェアサポ
ートはコマンドバッファベースのコンテキスト切換えに
勝る性能上の利点を有する可能性があるので、ドライバ
の複雑さは、潜在的な性能コストで軽減される。しか
し、このようなシステムは、既存のドライバに対する軽
量コンテキスト切換えの追加などの改変が行いやすくな
る。

【０１０６】軽量コンテキストに関して、ハードウェア
コンテキストは、アプリケーションのあるクラスには不
要である可能性のある多数の状態を含む。例えば、コプ
ロセッサがグラフィックスプロセッサである場合、現代
のグラフィックスチップの完全なマルチテクスチャリン
グ状態、バーテックスシェーディング状態、およびピク
セルシェーディング状態は、単純な２Dグラフィックス
アプリケーションに対しては不要である可能性がある。
このようなアプリケーションに対処するため、システム
は、コマンドバッファの実行開始前にハードウェアによ
り効率的にロードされる、１つまたは複数の軽量コンテ
キストタイプを定義することができる。加えて、システ
ムは、重量コンテキスト状態のどの部分が軽量コンテキ
ストのロードによって影響を受けなかったかを潜在的に
記憶し、既にハードウェア中に存在する状態を再ロード
することを回避するように後続のコンテキスト切換えを
最適化することができる。このような最適化は、ドライ
バレベルでのコンテキスト切換えシステムの正式なサポ
ートを必要とするシステムで、またはコマンドバッファ
または他の機構を使用して手動でハードウェアコンテキ
ストをロードしたシステムで実施することができる。

【０１０７】割込み処理に関しては、割込みは、コプロ
セッサハードウェアが実行中に、有用な作業のホストマ
イクロプロセッサの性能を促進するので、コプロセッサ
の計算リソースを効率的に管理するのに使用することが
できる。現在説明している実施形態で、システム内の割
込みに関するアプリケーションの一部と、各ケースで割
込み可能となる機能を詳述する。すべてのケースにおい
て、割込みは、オペレーティングシステムに、メモリに
書き込むことによって、またはイベントなどのスレッド
同期オブジェクトを信号で知らせることによって、割込
みを引き起こしたイベントをクライアントに通知する機
会を与える。

【０１０８】コマンドバッファ完了時の割込みでは、コ
マンドバッファが実行を終了したとき、システムは通知
を受け、したがってシステムは、別のコマンドバッファ
を選択してハードウェアにサブミットすることができ
る。コプロセッサが割込みを信号で知らせたときから、
別のコマンドバッファがサブミットされるまでコプロセ
ッサがアイドル状態であるか、それとも(以下で説明す
るように)コプロセッサが以前に待ち行列に入れられた
コマンドバッファの実行を開始するかに関わらず、シス
テムが別のバッファを選択してハードウェアにサブミッ
トする(または最終的にサブミットする)ことができるよ
うに、システムに通知しなければならない。コマンドバ
ッファが実行されたことを割込みが信号で知らせるの
で、システムは、コマンドバッファのために必要であっ
たリソースのすべてを解放し、そのリソースを必要とす
る保留のコマンドバッファを非ブロック化することがで
き、別のアプリケーションで使用するためにコマンドバ
ッファをリサイクルすることもできる。

【０１０９】コマンドバッファ中の信号割込みコマンド
では、先行するコマンドが実行を終了したときにハード
ウェアに割込みを信号で知らせるよう命令するコマンド
を書き込むことができる場合、システムは、１つのメモ
リへの書込みから、割込みコマンドに直面したときにイ
ベントまたは他のスレッド同期オブジェクトを設定する
ことにわたって、クライアントアプリケーションに細分
化されたアプリケーション制御の完了通知を提供するこ
とができる。

【０１１０】グラフィックスプロセッサに関するVSYNC
の発生時の割込みでは、VSYNC(ディスプレイ装置の垂直
帰線)発生時の割り込みは、システム中の様々な機能を
割込み可能にする。

【０１１１】システムが表示フレームを構成しており、
ページが反転した場合、VSYNC割込みは、表示フレーム
のバックバッファを構成する(すなわち次にVSYNCの準備
をする)必要を信号で知らせることになる。

【０１１２】システムは、VSYNC通知を使用して、将来
のフレームの呈示時間を推定することができ、この情報
をクライアントにとって利用可能にすることができる。
ビデオでは、これにより、呈示の時間に対応する補間お
よび/またはインターレース解除した出力フレームの合
成が可能となる。連続的時間領域によって制御される一
時的アニメーションでは、これにより、呈示に対応する
正確な時間にアニメーションをレンダリングすることが
可能となる。

【０１１３】システムはVSYNC通知を使用して、クライ
アントがクライアントのフレーム速度を表示リフレッシ
ュに減速することが可能となる。すなわち、表示が８５
Hzでリフレッシュしている場合、８５Hzでレンダリング
される。クライアントアプリケーションでは、呈示呼出
しは、同期させることができる(イベントが信号で知ら
されるまでスレッドをブロックし、VSYNCに関するイベ
ントを信号で知らせる)。より精巧なクライアントは、
具体的にイベントに対して待機することができ、それら
の描画の終了と、表示リフレッシュの待機との間の合間
に有用な作業を行うことができる。

【０１１４】表示リフレッシュが所与の走査線に達した
ときの割込みでは、表示リフレッシュが所与の走査線に
達したときに信号で知らされる割込みにより、時限式送
達を実装するシステムが、予想される呈示の時間を注意
深く制御することが可能となる。T=０を現在表示されて
いる第１の呈示時間とし、T=１を、反転され次のVSYNC
にエンドユーザが見ることになるバックバッファの呈示
時間とし、T２を、次にVSYNCに構成されることになるバ
ックバッファの呈示時間とし、T=３をその後の次のディ
スプレイフレームの呈示時間とする。クライアントが描
画するための呈示時間を要求するとき、時限式送達の実
装は、バックバッファに合成するために結果が必要とな
る前に、アプリケーションの描画が終了するための十分
な時間を確実にアプリケーションが有するように、T=３
を指定することができる。しかしディスプレイが最近に
なってリフレッシングを開始した場合、クライアントが
T=２を目標として描画するための時間が存在する可能性
があり、さらにはVSYNCが行われた後でも、バックバッ
ファ合成への参加を時間内に完了する可能性がある。デ
ィスプレイが所与の走査線をリフレッシュしたときを信
号で知らせる割込みにより、ディスプレイがまさにリフ
レッシングを終了しようとしているかどうかに応じて、
時限式送達サブシステムがクライアントに様々な呈示時
間を与えることが可能となる。例えば、システムは、デ
ィスプレイがリフレッシングを半分終了するまで、予想
される呈示時間としてT=２をクライアントに渡すことが
できる。次いでシステムは、予想される呈示時間として
T=３をクライアントに渡すことを開始することができ
る。この挙動変更を引き起こす走査線番号は、システム
負荷に従って調整することもできる。

【０１１５】プライマリに対するティアフリー(Tear-fr
ee)更新は、更新すべき領域がディスプレイ装置によっ
てリフレッシュされた直後に、この割込みを信号に設定
することによって実施することができる。割込みが信号
で知らされたとき、ディスプレイを更新するのに必要な
描画オペレーションを実施するようにグラフィックスプ
ロセッサに依頼することができ、更新が行われるときに
表示リフレッシュが再び更新領域に達する程、システム
がそのコマンドを実行するのに長い時間かかるのでない
限り、ティアは観察されないことになる。

【０１１６】同期に関しては、適切な同期を実施するた
めに、システムは、クライアントアプリケーションによ
って操作されるオブジェクト間の依存関係を追跡し、そ
の依存関係がコマンドバッファディスパッチ中に考慮さ
れる。図２の待機状態２０３は、コマンドバッファが依
存したオペレーションが完了するまで待機する機会を表
す。例えば、アプリケーションが表面をレンダリング
し、次いでその表面をテクスチャとして選択した場合、
別の描画に移ることができる前にそのレンダリングは完
了しなければならない。同様に、アプリケーションが表
面を描画し、次いでその表面をソース表面として使用し
てBltを要求する場合、その描画は、Bltを開始すること
ができる前に完了しなければならない。同期要件の別の
例はページ反転である。アプリケーションがオーバーレ
イ面を作成し、オーバーレイのバックバッファ中に描画
し、ページ反転を要求する場合、描画は、オーバーレイ
のフロントバッファ中への描画が終了するときにページ
反転またはレンダリングアーティファクトが観察される
前に完了しなければならない。

【０１１７】これらの同期要件のすべては、前述のよう
にコマンドバッファディスパッチをスケジュールするシ
ステム内で吸収することができる。アプリケーションが
コマンドをコマンドバッファ内に書き込むとき、システ
ムは、そのコマンドバッファが実行するためにどのリソ
ースを必要とするかを追跡することができる。あるリソ
ースは非排他的に獲得することができ(例えば、読み取
るパレットまたは表面、あるいはテクスチャマッピング
する表面)、他のリソースは、排他的に獲得しなければ
ならない(例えば書き込む表面、または３Dレンダリング
を実施する表面)。システムはスレッド同期プリミティ
ブを潜在的に活用して、コマンドバッファのこの同期を
実施することができる。例えば、任意の数のスレッドが
非排他的に獲得することができ、または単一スレッドが
排他的に獲得することができるスレッド同期プリミティ
ブがWINDOWS(登録商標)NTに存在する。コマンドバッフ
ァが、排他的アクセスが必要であるかどうかと共に、獲
得する必要のあるリソースの関連リストを有する場合、
コマンドバッファをディスパッチするスレッドは、コマ
ンドバッファに関連する同期オブジェクトを待機するこ
とによって、待機状態からレディ状態にコマンドバッフ
ァを遷移することができる。必要な同期オブジェクトの
すべてをスレッドが獲得した後、コマンドバッファをハ
ードウェアにサブミットすることができる。

【０１１８】システムは、リソースが利用可能となる前
に実行された、コマンドバッファ中の以前のコマンドに
依存するリソースが要求されるケースを検出しなければ
ならない。このことが生じたとき、スレッドはコマンド
バッファをサブミットし、別のコマンドバッファの構成
を開始しなければならない。第２コマンドバッファは単
にリソースを指定することができ、前述の同期機構はそ
の依存関係を吸収することになる。

【０１１９】コマンドバッファを待ち行列に入れること
に関しては、グラフィックスハードウェアが高性能であ
るために、コマンドバッファ完了と別のコマンドバッフ
ァのサブミットとの間の待ち時間を最小にすることが重
要である。そうでない場合、グラフィックスハードウェ
アは、別のコマンドバッファがサブミットされることを
待機して、貴重な時間を浪費する。この問題に対する１
つの可能な解決策は、現コマンドバッファが実行を終了
する前に、コンテキスト切換えおよびコマンドバッファ
ディスパッチを待ち行列に入れることである。次いで、
ハードウェアおよびドライバがこの機能をサポートする
ことを条件として、ハードウェアは、現コマンドバッフ
ァが完了したときに、別のコマンドバッファの実行を直
ちに開始することができる。するとシステムは、実行の
ために別のコマンドバッファを準備するための時間をよ
り多く有する。グラフィックスハードウェアは、別のコ
マンドバッファが待ち行列に入れられる前に新しいコマ
ンドバッファを完了する場合にだけアイドル状態になる
ことになる。

【０１２０】プリエンプティブルコマンドバッファ実行
に関しては、ここでは記載のシステムは、切り替えに対
するハードウェアサポートを提供する。様々なイベント
が、VSYNCなどの外部イベントからタイムクォンタム（t
ime quantum）のハードウェア実施にわたって、実行中
にコマンドバッファの切り替えを潜在的に引き起こす。
この機能を実施するためには、切り替わったコマンドバ
ッファの実行を中断したところから再開することができ
るように、ハードウェアおよびドライバにより、ハード
ウェアコンテキストを保存することが可能でなければな
らず、オペレーティングシステムがコマンドバッファを
図２で触れたレディ状態に戻すことができるように、オ
ペレーティングシステムは通知を受けなければならな
い。このような切り替えを実施する１つの理由は、(次
のVSYNCが行われるときに表示フレームの準備ができて
いることを保証するために)表示フレームがVSYNCの直後
に構成されることを保証するためである。タイムクォン
タムのハードウェア実施により、２ミリ秒などのある設
定期間に実行した後にコマンドバッファが切り替わる。
テクスチャマッピングされ、アルファブレンドされた大
きな三角形などの非常に負荷の高いコマンドをコマンド
バッファが含む場合、ハードウェアは、他のコマンドバ
ッファをサブミットすることを考慮することが可能とな
るように、この実行を切り替えなければならない可能性
がある。

【０１２１】コマンドバッファ不均一性に関しては、先
行する解説では一般に、コマンドバッファを均質なもの
として扱ったが、システムが、対応するハードウェアコ
ンテキストを有するアプリケーション特有のコマンドバ
ッファを提供できない理由はない。例えば、システム
で、コマンドバッファレベルで２D/３D描画とビデオ復
号化を別々に扱うこと、および所与のタイプのコマンド
バッファのディスパッチの前に、異なるハードウェアコ
ンテキストのロードを扱うことが望まれる可能性があ
る。

【０１２２】コマンドバッファを不均一なものとして扱
うアイデアは、軽量コンテキストのアイデアと良好な相
乗作用を有する。軽量コンテキストを操作するときに、
利用可能なコマンドのサブセットだけが利用可能である
からである。

【０１２３】コマンドバッファオーバーフローを検出す
るための保護ページに関しては、コマンドバッファに書
き込むユーザモードコードは、コマンドバッファ内に残
されたバイト数を追跡し、所与のコマンドを書き込むの
に必要なバイト数が利用可能なバイト数を超過したとき
に検出することができる。しかし、このバッファに書き
込むのに必要なコマンドに寄与する変数が多数であるた
め、このバイトカウントを手動で追跡することは煩わし
く、エラーの生じやすいプログラミングタスクとなる。
このタスクの複雑さを低減する１つの方法は、コマンド
バッファの終わりの直後に保護ページを割り振り、その
ページを書込み不能にすることである。次いでバッファ
をオーバーランするメモリ書込みが例外を引き起こす。
コマンドバッファに書き込むユーザモードコードは、構
造化例外処理ブロックで書込み命令を取り囲み、例外を
処理し、コマンドバッファがオーバーフローした場合に
エラーをランタイムに返すことができる。次いでユーザ
モードドライバに対するインターフェースは、バイトカ
ウントがランタイムとユーザモードドライバの間で渡さ
れる代替実装よりも単純で、効率的になる。

【０１２４】不正確なコマンドバッファ内容を扱うこと
に関しては、ユーザモードコードがコマンドバッファに
書き込むことを許可するシステムにおいて、不正な書込
みにより、コマンドバッファの内容がハードウェアにサ
ブミットされる前に、その内容が破壊される可能性があ
る。注意深く防御設計を行わない場合、このような破壊
により、システムがハングし、またはシステムの挙動が
不安定になる可能性がある。基礎となるハードウェア設
計に応じて、この不測の事態に対処するためにいくつか
の方法がある。

【０１２５】ハードウェアがコマンドバッファを読取
り、実行するときにコマンドバッファを妥当性検査する
能力を有する場合、無効コマンドに直面したとき、割込
み、またはコマンドバッファの時期尚早な終了を信号で
知らせることができる。システムはエラー戻り、例外、
および他の何らかの機構を用いて、このようなイベント
をクライアントプロセスに通知することができる。

【０１２６】あるいは、ハードウェアがコマンドバッフ
ァを実行するときにコマンドバッファを妥当性検査する
ことができない場合、ハードウェアがある時間フレーム
内に応答しなかった場合にシステムにハードウェアをリ
セットするオプションを与えることもできる。

【０１２７】単一のスレッドに対する装置の選択に関し
ては、システム中のスレッド同期の量を低減する１つの
方法は、スレッドに対して装置を選択することを可能に
し、スレッドが「現装置」の概念を有することを可能に
し、それによって装置とスレッドとの間に１対１対応が
存在するようにすることである。この手法の利点は、相
互排他を保証するためにクリティカルセクション、mute
x、または他の同期プリミティブを獲得しなくても、装
置の範囲内で相互排他が保証されることである。グロー
バルにアクセス可能な表面に対してあるオペレーション
を実行することなど、装置の範囲から逸脱するオペレー
ションは、依然として同期しなければならない。このよ
うなオペレーションであっても、表面などのグローバル
オブジェクトを装置にバインドすることを可能にするこ
とにより、スレッドにバインドされた装置の相互排他特
性を活用することができる。

【０１２８】スレッドに対して「現装置」の概念を実装
するシステムにより、アプリケーションが任意の装置に
アクセスすることが依然として可能である。このような
アクセスを可能にするソフトウェアインフラストラクチ
ャが行わなければならないのは単に、ある追加の性能コ
ストで、他のスレッドと分離し、他のスレッドと同期す
ることだけである。

【０１２９】トークンストリームと、ハードウェア独立
な描画コマンドの維持に関しては、あるアプリケーショ
ンでは、「トークンストリーム」と呼ばれるハードウェ
ア独立な１つのメモリ中のグラフィックスハードウェア
に対する一連のコマンドをキャッシュする能力を有する
ことにより、アプリケーションがバッファを構成するの
に必要な労力を償却することを可能にすることによって
より高い性能が得られる。例えば、回転を含んだ一連の
描画コマンドは、このようなバッファに書き込むことが
できる。次いでアプリケーションは、単にバッファ中の
値をいくらか変更し、トークンストリームに再サブミッ
トすることによって、異なる回転角でシーンを再描画す
ることができる。DIRECT３D(登録商標)実行バッファ
は、このアイデアの実装の良い例である。

【０１３０】本発明の状況では、トークンストリーム
は、アプリケーションとハードウェアの間の重要な中間
ステップとして働く。ある点では、描画コマンドは、ハ
ードウェアで実行するために、ハードウェア特有のコマ
ンドに変換しなければならない。しかし、アプリケーシ
ョンが描画呼出しを行うときに(いわゆる「即時モー
ド」)その変換をリアルタイムで実施することは、描画
を実施するための常に最も効率的な方法であるわけでは
ない。ハードウェア特有のバッファ(この文書では「コ
マンドバッファ」と呼ぶ)は、アプリケーションに対し
て本質的に不透明である。ハードウェア特有のコマンド
への変換の詳細により、アプリケーションがそのバッフ
ァを編集することが難しくなり、または不可能となるか
らである。したがって、トークンストリームは、システ
ムがGPUに対する一連のコマンドのハードウェア独立な
潜在的に編集可能な記述を実装する必要があるかどうか
に応じて、システムで実装することができ、または実装
することができない重要な中間データ構造として働く。

【０１３１】ディスプレイリストおよび保持されるハー
ドウェア依存描画コマンドに関しては、グラフィックス
ハードウェア産業では、アプリケーションに対して不透
明に一連の描画コマンドをキャッシュする慣例があり、
それによってその一連の描画コマンドをより効率的に再
度実行することができるとされている。このキャッシュ
された描画コマンドは、しばしば「表示リスト」と呼ば
れる。このアイデアは、シーン(剛性オブジェクトなど)
の静的要素を表示リストに「レンダリング」することが
でき、次いでシーンを描画するとき、アプリケーション
が、表示更新毎に描画呼出しを実行するのではなく、適
切な表示リストを起動するというものである。実際に
は、表示リストの実行特性は、実装毎に大幅に変化し、
そのことによってアプリケーションは、実行特性を使用
するかどうかを決定するために、基礎となる実装につい
ての煩わしい想定を行わなければならない。

【０１３２】この文書で説明するシステムは、DDIレベ
ルコマンドをハードウェア特有のコマンドに変換するユ
ーザモードドライバインターフェースを使用することに
よって、表示リスト機能を容易に公開することができ
る。表示リストの構築方法の詳細は変化する可能性があ
る。アプリケーションは、描画コマンドを実行する代わ
りに、描画コマンドを表示リスト内に記録させるモード
を設定することができ(OpenGLでは、このモードはglNew
Listを呼び出すことによって設定される)、またはアプ
リケーションがトークンストリームを構築し、次いでト
ークンストリームを表示リストに変換することを要求す
ることができる。いずれにしても、システムは、コマン
ドのDDI側をハードウェア特有のコマンドに変換し、そ
れを一時バッファに書き込むようにユーザモードドライ
バコンポーネントに依頼することになる(ハードウェア
特有のコマンドストリームの正確なサイズは、変換を実
施した後になるまでわからないからである)。記録が停
止したとき、またはトークンストリームが構文解析され
た後、システムは、適切なサイズのコマンドバッファを
割り振り、変換したハードウェアコマンドをその中にコ
ピーし、それによってハードウェアはコマンドバッファ
を容易に実行することができる。

【０１３３】基礎となるハードウェア実装について行っ
た想定により、本発明の状況で表示リストを実装するこ
とは、ハードウェア実装毎の実行特性がより一貫すると
いう利点を有する。言い換えれば、表示リストが１つの
ハードウェア実装に対する性能上の利点を与える場合、
表示リストはすべてのハードウェア実装にわたってより
高速となる可能性が高い。アプリケーション開発者が関
する限りでは、この整合性は非常に大きな利点である。
表示リストの使用はアプリケーション開発者にとって重
荷であり、アプリケーション開発者は、表示リストを利
用するのに必要な追加の投資が割に合う場合について決
断することができなければならないからである。

【０１３４】複数のコマンドバッファを実行するグラフ
ィックスハードウェアに関しては、複数のコマンドバッ
ファを同時に実行することができるグラフィックスハー
ドウェアをサポートするようにシステムを変更すること
ができる。例えば、グラフィックスハードウェアは、並
列に動作することができる複数の離散的グラフィックス
プロセッサを含むことができる。そのような一部のハー
ドウェアは並列処理を使用して、「走査線インターリー
ビング」を介してフィルレートを増加させるが、このよ
うなプロセッサによって別個のコマンドバッファを実行
することも可能である。このようなハードウェアアーキ
テクチャを提供することは、複数のコマンドバッファを
スタンバイ状態にすることを可能にする際の課題とな
り、複数のコマンドバッファを実行することをカーネル
モードスケジューラに保証させることにより、読取り専
用でアクセスすることを除いて(テクスチャマッピング
など)、同じリソースのいずれもアクセスされない。

【０１３５】視覚化リソースに関しては、本明細書で説
明するシステムは、ビデオメモリ表面、頂点、索引バッ
ファ、および他の限定されたハードウェアリソースなど
のリソースを視覚化することができる。「視覚化する」
という用語は、アプリケーションがシステム全体で利用
可能なリソースよりも多くのリソースを有するかのよう
に振舞うことができるアイデアを指す。例えば、「仮想
メモリ」により、システム内に物理的に存在するメモリ
よりも多くのメモリをアプリケーションが割り振ること
が可能となり、メモリが物理的に存在するという錯覚を
維持するために、オペレーティングシステムがローカル
な大容量記憶装置とメモリをスワップする。CPUは、オ
ペレーティングシステムがメモリ使用量を監視すること
を可能にする機能を有し、それによって現在必要ではな
い物理メモリをディスクに「ページアウト」し、必要な
メモリのための空間を作成することができる。

【０１３６】本発明の状況では、ビデオメモリなどのGP
Uリソースも同様に、所与のコマンドバッファの実行に
必要なリソースを追跡し、コマンドバッファがハードウ
ェアに発行されるときにそのリソースが利用可能となる
ことを保証することによって視覚化することができる。
ビデオメモリは、ビデオメモリ表面を「ページアウト」
するためにシステムメモリを扱うシステムを「大容量記
憶装置」として用いて、上記の仮想メモリと同様に管理
することができる。システムメモリ中に戻された表面を
必要とする実行のためにコマンドバッファが選択された
とき、オペレーティングシステムは、(恐らくビデオメ
モリ表面を解放することによって、またはビデオメモリ
からシステムメモリに他の表面を引き抜くことによって
空間を作成して)新しいビデオメモリ表面を割り振り、
システムメモリの内容をその表面にコピーしなければな
らないことになる。得られる表面は、元の位置とは異な
る位置になる可能性が高く、したがってオペレーティン
グシステムは、ビデオメモリ表面へのリファレンスを追
跡し、コマンドバッファをハードウェアにディスパッチ
する前にコマンドバッファ内にこのリファレンスを「用
意」しなければならないことになる。

【０１３７】図４に、上述の発明の例示的ユーザモード
のドライバDLLの実装を示す。図４では、アプリケーシ
ョン４０１、ランタイム４０２、およびドライバ４０３
の一部はユーザモードで動作して、描画コマンドをDMA
メモリ中のハードウェア特有のコマンドバッファに書き
込む。一般に、現在のPCシステムではこれらの書込みは
AGPメモリへの非一時的な書込みであり、この実装で図
示するように、アプリケーション４０１はEXEに存在
し、ランタイム４０２とユーザモードドライバ４０３は
動的にアプリケーション４０１にリンクされるDLLに存
在する。以下で説明するように、システムのユーザモー
ド部分のこの詳細は異なる可能性があり、具体的には、
アプリケーション４０１、アプリケーション４０１およ
びランタイム４０２、またはアプリケーション４０１、
ランタイム４０２、およびユーザモードドライバ４０３
が潜在的に管理コードとなる可能性がある。

【０１３８】ユーザモードドライバ４０３が不正に置き
換えられるのを防ぐために、システムは、ユーザモード
ドライバDLL４０３のロードについてはカーネルドライ
バ４０５に照会する(セキュリティの観点から見てカー
ネルコードは信頼されるため)。

【０１３９】コマンドバッファスケジューラ４０４
(「スケジューラ」)とカーネルドライバ４０５は、カー
ネルモードで協働してコマンドバッファをハードウェア
４０６にディスパッチする(スケジューラ４０４は、ど
のコマンドバッファをディスパッチすべきかを決定し、
カーネルドライバ４０５はスケジューラの要求時にコマ
ンドバッファをディスパッチすることをハードウェア４
０６に指令する)。このシステムでは、ドライバロジッ
クの大半はカーネルドライバ４０５ではなくユーザモー
ドドライバDLL ４０３に存在することを企図する。ユー
ザモードドライバは、DLLレベルの呼出しをハードウェ
ア特有のコマンドにマッピングする(この操作は、特に
頂点および/またはシェーダプログラムをコンパイルす
る際には複雑になり、エラーが発生しやすくなる可能性
がある)大量のコードを含むことができるのに対して、
カーネルドライバは比較的小さく単純であり、システム
の堅牢性が最大となる。

【０１４０】図５に、アプリケーションがAPI呼出しを
行ってグラフィックスオペレーションを実施している際
に発生するイベントの順序を具体的に示す。図５のブロ
ック図の構成要素は、陰影を付けて示してある。すなわ
ち、ユーザモード構成要素には陰影を付け、カーネルモ
ードの構成要素には陰影を付けず、ハードウェアには陰
影とハッチングを付けてある。図５では、コマンドバッ
ファをハードウェア構成要素としては具体的に図示して
いない。図５によれば、ユーザモードドライバ５２０
は、ハードウェア特有のコマンドを装置の現コマンドバ
ッファに書き込み、コマンドバッファスケジューラ(シ
ステムカーネルサポート５３０の一部)は、カーネルモ
ードドライバ５５０を介してコマンドバッファをハード
ウェア５６０にディスパッチし、終了したコマンドバッ
ファは、システムのアプリケーションが使用するために
リサイクルされる。潜在的には、システムカーネルサポ
ート５３０がリソースの共用を仲裁することで、複数の
アプリケーション５００が、利用可能なコマンドバッフ
ァのプールを共用できることに留意されたい。

【０１４１】アプリケーション５００が５０１で最初に
描画コンテキストを作成すると、システムカーネルサポ
ート５３０は、５３１で新しいコマンドバッファを作成
できるかどうかを確認する。可能である場合には５３２
で新しいコマンドバッファを作成して５３３で初期化
し、スレッドが５３４で初期化済みコマンドバッファを
取得した後、アプリケーション５００は描画呼出し５０
２を行うことができる。ステップ５３１でコマンドバッ
ファを作成することができない場合は、アプリケーショ
ン５００は５３４で初期化済みコマンドバッファが利用
できるようになるまで待機しなければならない。アプリ
ケーション５００がコマンドバッファを取得すると、ア
プリケーション５００、ランタイム５１０、およびユー
ザモードドライバ５２０は３つのコンポーネント間の典
型的な対話に入り、これによりハードウェア特有のコマ
ンドがコマンドバッファに書き込まれる。アプリケーシ
ョン５００による描画呼出し５０２は５１１でランタイ
ム５１０によって妥当性検査され、次いでチェック５１
２により現在のコマンドバッファのフラッシュが必要で
あるかどうかを判定する。必要でない場合は、５１３で
描画コマンドをより単純なカノニカルDDI呼出しに変換
し、ユーザモードドライバ５２０に渡す。ドライバはこ
のDDI呼出しをハードウェア特有のコマンドに変換し、
それをコマンドバッファに書き込むことを試みる。フラ
ッシュについてのチェック５２２でコマンドバッファに
空きがないと判定される場合は、コマンドを書き込み、
実行を継続する前に、コマンドバッファをシステムカー
ネルサポート５３０にサブミットして、システムカーネ
ルサポート５３０から新しいコマンドバッファを取得し
なければならない。ランタイム５１０またはユーザモー
ドドライバ５２０により、フラッシュが必要であると判
定される場合、ステップ５３５でコマンドバッファを待
ち行列に加える。このとき、システムカーネルは、５３
６で(一般には実行中のコマンドバッファがないために)
コマンドバッファを直ちにサブミットすることができる
かどうかを調べることができる。直ちにサブミットする
ことができない場合はコマンドバッファを待ち行列に入
れたままにし、５３４で新しいコマンドバッファを取得
しなければならない。適切な初期化済みコマンドバッフ
ァが使用できるようになるのを待ち、次いでそれを装置
に割り当てるこの機能ブロックは、アプリケーション５
００が描画を開始できるようになる前に必要な操作と同
一であることに留意されたい。

【０１４２】矢印にも陰影を付けてある。最も暗い矢印
は、アプリケーション５００が初期化されて描画コマン
ドを実行し、ランタイム５１０およびユーザモードドラ
イバ５２０がその描画コマンドをハードウェア特有のコ
マンドに変換し、それをコマンドバッファに書き込むと
きの「典型的な」スレッド実行をたどっている。フラッ
シュが必要であるとランタイム５１０またはユーザモー
ドドライバ５２０が判定した場合(すなわちコマンドバ
ッファをサブミットしなければならないと判定した場
合)、（ランタイム５１０、ユーザモードドライバ５２
０、システムカーネルサポート５３０に渡る）第１の白
抜きの矢印で示すスレッドの実行が続く。すなわち、コ
マンドバッファが待ち行列に加えられ、可能な場合にサ
ブミットされ、次いで新しいコマンドバッファが得ら
れ、したがって実行を続行することができる。

【０１４３】ハッチングを付けた矢印は、ステップ５３
５でコマンドバッファを待ち行列に加えた後にコマンド
バッファが取る「典型的」な経路をたどっている。コマ
ンドバッファを直ちにディスパッチすることができる場
合(チェック５３６)、コマンドバッファを５３７でレデ
ィ状態としてマークし、５４０でディスパッチするため
に選択する。そうでない場合、待機コマンドバッファ
は、現実行コマンドバッファが実行を終了するときに、
イベントの通常の過程でレディ状態としてマークしなけ
ればならない。

【０１４４】５４０でレディ状態のコマンドバッファを
ディスパッチするために選択するとき、システムカーネ
ルサポート５３０は、カーネルドライバ５５０に、ハー
ドウェアを適切なコンテキストにコンテキスト切換えを
させ（５５１）、コマンドバッファをハードウェアにデ
ィスパッチさせる（５５２）。次いでハードウェアは、
コマンドバッファが切り替わるか、またはコマンドバッ
ファが終了するまで、コマンドバッファを読み取り、実
行する（５６１）。コマンドバッファが５６３で普通に
完了した場合、ハードウェアは割込みを信号で知らせ、
割込みサービスルーチン５５３が実行される。このと
き、ISRは、ハードウェアコンテキストを保存しようと
する（５５４）可能性があるが、ハードウェアが同じコ
ンテキストに対して作用する連続する２つのコマンドバ
ッファを実行するように依頼される場合、ドライバは、
コンテキスト切換え５５１へこのオペレーションを延期
しようとする可能性がある。このステップ５５４の後、
カーネルシステムサポート５３０は、そのコマンドバッ
ファが必要とするリソースを解放することができ、関係
するクライアントにコマンドバッファが完了したことを
知らせるためのイベントなど、どんな通知機構も信号で
知らせることができる（５３８）。ステップ５３８の
後、カーネルシステムサポートは２つの異なるタスクを
有する。すなわち、カーネルシステムは、新たに利用可
能となったコマンドバッファを再初期化し、それを初期
化プールに加えなければならず（５３３）、かつ任意の
待ちコマンドバッファを非ブロック化し、それをレディ
待ち行列に移動しなければならない（５３９）。ステッ
プ５３９の後、別のコマンドバッファをディスパッチす
るために５４０で選択することができる。

【０１４５】（ハードウェア５６０、カーネルドライバ
５５０、システムカーネルサポート５３０に渡る）第２
の白抜きの矢印で示すように、切り替えの場合は、通常
のコマンドバッファ完了とわずかに異なるように処理さ
れる。切り替えたコマンドバッファは終了しなかったの
で、システムは、コマンドバッファの完了を通知(ステ
ップ５３８)してはならず、従属コマンドバッファを非
ブロック化(ステップ５３９)してもならない。その代わ
り、ドライバは、切り替えが行われたところから再始動
することができるように、部分的に実行したコマンドバ
ッファのコンテキストを保存し（５５４）、切り替えに
ついて認識する必要のある任意のクライアントに通知し
（５４１）、次のレディコマンドバッファをでディスパ
ッチするために選択する（５４０）。

【０１４６】切り替えを引き起こす可能性のある発生の
例には、VSYNCなどの外部イベント、または走査線など
の特定の位置に対する表示リフレッシュの到着、または
タイムクォンタムの満了が含まれる。加えて、タイムク
ォンタムの管理に関して、オペレーティングシステム
は、カーネルドライバ５５０を呼び出すことによってグ
ラフィックスプロセッサを切り替えるための機構を使用
することができる。これは、グラフィックスプロセッサ
をいつ切り替えるかを決定し、次いでハードウェア５６
０ではなく、システムカーネルサポート５３０にとどま
ることに関する複雑さおよび責任を除き、ハードウェア
で調停されたタイムクォンタムの満了と同等である。リ
フレッシュが(ティアフリー更新のために)ある走査線を
通過するときに一連のBltコマンドを実行することな
ど、そのようなイベントに対する応答をシステムが先に
セットアップしているとみなす。

【０１４７】上記で呈示したアイデアの多くは、図４お
よび５に関連して説明したシステムに適用できることに
留意されたい。例えば、上記により、システムカーネル
サポート５３０は、カーネルドライバ５５０にコンテキ
スト切換えコマンドバッファをディスパッチさせること
によって、潜在的にコンテキスト切換えタスク５５１を
引き継ぐことができる。別の例では、上記でより詳細に
説明したように、コンテキストタイプと、コマンドバッ
ファのタイプを潜在的に区別することによって、軽量コ
ンテキストをこのシステムでサポートすることができ
る。別の例では、実行コマンドバッファが終了すると同
時に、ハードウェアが先に選択したコマンドバッファの
実行を開始する、上記で呈示したアイデアを利用するた
めに、ステップ５４０(「レディコマンドバッファをデ
ィスパッチするために選択する」)をわずかに修正する
ことができる。さらに別の例では、ランタイム５１０お
よびユーザモードドライバ５２０がコマンドバッファオ
ーバーフロー５２２を検出するための効率的な方法は、
システムカーネルサポート５３０が書込み不能保護ペー
ジを各コマンドバッファの終わりに割り振り、構造化例
外処理を使用して、保護ページへの書込みが試みられた
ときを検出することである。最後に、無効コマンドバッ
ファに対してシステムを堅牢にするアイデアは、無効コ
マンドがハードウェアに割込みを生成させるときに例外
を信号で送ることによって、またはハードウェアが過度
に長期間応答しなくなった場合に、特別なカーネルドラ
イバ５５０のエントリポイントを介してハードウェアを
リセットすることによって容易にこのシステムに組み込
むことができる。

【０１４８】図６に、例示的ハードウェアの消費可能カ
ノニカルコマンドバッファのフォーマットを示す。図６
は、上述の本発明の特定の実装である。この実装は、コ
マンドがランタイム６０２(オペレーティングシステム
の一部)によってカノニカルコマンドバッファフォーマ
ットを使用するバッファに書き込まれることを除いて、
図４に関連して説明した実装と同様である。そのような
フォーマットについては、当業界で前例がある。その前
例は、例えばDIRECT３D(登録商標)で使用されている「D
rawPrimitive２」トークンストリームである。このフォ
ーマットがハードウェアによる直接消費に適している場
合、実行は、ユーザモードドライバDLL４０３中の変換
層を必要とする代わりに、ハードウェアがランタイム６
０２からの出力を直接消費することができることを除い
て、図４に関連して説明したのと同様に進行する。

【０１４９】図７に、中間(ハードウェア消費不能)カノ
ニカルコマンドバッファを示す。

【０１５０】図７は、ランタイム７０２が周知のフォー
マットでコマンドのバッファ７０３を生成し、次いでそ
のバッファをスケジューリングする、システムの別の変
形形態を示す。ディスパッチするために選択した後、カ
ーネルモードドライバ４０５は、全バッファを読み取
り、それをハードウェア特有のコマンドに変換しなけれ
ばならない。図７は、これらのコマンドがカーネルモー
ドドライバによってDMAメモリ７０７に書き込まれるこ
とを示す。しかし、このようなシステムでは、ハードウ
ェアを制御するどんな機構でも使用することができる。
図７のシステムは、DrawPrimitives２トークンストリー
ムがカーネルモードドライバ４０５に渡されるという点
で、DIRECT３D(登録商標)ドライバ構造での現況技術と
酷似している。主な差は、図７のシステムがコマンドバ
ッファのOS調停スケジューリングを企図しているのに対
して、DIRECT３D(登録商標)は現在のところ正式にはGPU
の時間をスケジューリングしないことである。

【０１５１】スレッド/GPUコンテキスト関係に関連し
て、CPU上でのスレッド実行の定義を当業者は理解でき
よう。すなわちスレッドが、複数のタスクを同時に動作
することを可能にするためにオペレーティングシステム
でコンテキスト切換えしなければならない揮発性CPUレ
ジスタと、他のCPU状態とをカプセル化する。十分に細
かい細分性でスレッドコンテキストをCPUの内外にスワ
ップし、それぞれがある期間(しばしば「スレッドクォ
ンタム」として知られている)に実行することを可能に
することにより、オペレーティングシステムは、スレッ
ドによって並列に実行される錯覚を実現することができ
る。

【０１５２】上述のシステムにより、CPUスレッドコン
テキストのGPU類似物が同様に実現される。しかし、GPU
コンテキストがCPUスレッドコンテキストと関連する場
合にいくつかの利点があり、それによって、そのスレッ
ドで実行中のCPUコードだけでGPUコンテキストを操作で
きることを理解されたい。CPUスレッドコンテキストが
有することができるのが、CPUスレッドコンテキストに
関連する１つのGPUコンテキスト(「現コンテキスト」)
だけとなる、CPUコンテキストとGPUコンテキストの間の
１対１対応については当業界で前例がある(OpenGL API
を参照)。このようなシステムでのGPUコンテキストの管
理は、当該のOpenGLアクセラレータのベンダから提供さ
れるモノリシックドライバによって、オペレーティング
システムをほとんどまたは全く使用せずに調整され、し
たがってOpenGLのコンテキスト中のスレッド/GPUコンテ
キスト関係から得られる利点は、ここで述べるシステム
中の関係とは著しく異なる。

【０１５３】効率の観点からは、GPUコンテキストと単
一のCPUスレッドとを関連付けることによる明白な利点
は、GPU状態を変更するのに、スレッド同期(例えばスピ
ンロック、クリティカルセクション、またはmutex)の必
要がないことである。そのスレッドは、GPUコンテキス
ト上で動作することができる唯一のスレッドであること
がわかっているからである。スレッド同期量を低減する
ことにより、性能上の利点が得られる。例えば、図５に
示す高頻度イベント(描画呼出し５０２、妥当性検査５
１１、フラッシュチェック５１２、DDIへの変換５１
３、DDIからハードウェアコマンドへの変換５２１、フ
ラッシュチェック５２２、およびコマンド書込み５２
３)中にスレッド同期プリミティブを獲得する必要はな
い。

【０１５４】以下の説明では、既存のスレッド同期プリ
ミティブを活用することを示す。現代のオペレーティン
グシステムが、スピンロック、クリティカルセクショ
ン、mutex、イベント、セマフォー、(多重スレッドによ
って共用アクセス用に獲得することができ、または単一
スレッドによって排他的アクセス用に獲得することがで
きる)リソースなど、多数のスレッド同期プリミティブ
を提供することを当業者は理解できよう。これらのスレ
ッド同期プリミティブにより、一般に、あるイベントが
発生するまで(外部イベント、リソースが利用可能とな
るなど)実行スレッドが実行を中断することが可能とな
る。スレッドがそのような同期プリミティブを待機して
いる場合、オペレーティングシステムは、スレッドが実
行を続行することができるように、プリミティブが「信
号で知らせを受ける」ときを検出する。上記で列挙した
様々な同期プリミティブのセマンティクスは良くドキュ
メント化される。例えば、共用リソースへのアクセスを
調整するのに使用する「mutex」プリミティブを説明す
る。「mutex」は、一度に１つのスレッドだけが獲得す
ることができ、別のスレッドがmutexを獲得することが
できる前に解放しなければならない。mutexを解放した
とき、複数のスレッドがmutexを待機している可能性が
あり、その場合、オペレーティングシステムはmutexを
単一のスレッドに与えて、そのスレッドがmutexを解放
するまでそのスレッドを非ブロック化しなければならな
い。GPUコンテキストをCPUスレッドに関連付ける利点
は、セマンティクスの詳細とスレッド同期プリミティブ
の実装(これらは当業者に良く理解されている)とは無関
係であり、したがってこの詳細をここで詳述しない。

【０１５５】ここでの基本的な観察は、GPUコンテキス
トがシステム中の１つのCPUスレッドと関連する場合、
そのスレッドをスレッド同期プリミティブを使用して中
断することにより、本質的に、CPUスレッドが非ブロッ
ク化されるまで、そのGPUコンテキストがアプリケーシ
ョンから利用不能となることである。GPUコンテキスト
のそのような要求を行うことができるのは中断されたス
レッドだけなので、スレッドが中断される限り、そのGP
Uコンテキストに描画オペレーションまたは他のオペレ
ーションを実施するよう依頼することはできない。基礎
となるシステムが適切な低レベル機能(例えば対応するG
PUへの保留描画コマンドのフラッシュ)を提供する場
合、アプリケーションはスレッド同期プリミティブを使
用して、描画を他のスレッドのオペレーションと調整す
ることができる。

【０１５６】より重要なことに、オペレーティングシス
テムが、スレッド中に選択されたGPUコンテキストを有
するスレッドを中断し、当該のスレッドが非ブロック化
されるまでそのGPUの動作を防止するための多数のアプ
リケーションが存在する。例えば、リソース管理の目的
で、GPUリソースのすべてを単一アプリケーションに渡
すことが必要であることがある(例えば、WINDOWS(登録
商標)では、フルスクリーンの排他的DirectX(登録商標)
ゲームはアプリケーションフォーカスを取得する)。オ
ペレーティングシステムは、GPUで描画しようとする他
のスレッドを中断することができ、したがってそのスレ
ッドは、描画するのに必要なリソースがそのスレッドか
ら利用不能である間に描画を試みることで、貴重な時間
を浪費することがない。

【０１５７】CPUコンテキスト切換えとGPUコンテキスト
切換えとを統合することに関しては、CPUコンテキスト
が有することができるのが１つの関連するGPUコンテキ
ストだけとなるように上述のGPUコンテキスト/CPUコン
テキストの関連が強化される場合、CPUとGPUとの間に密
接な関連が存在する、あるハードウェアアーキテクチャ
(統合グラフィックスアーキテクチャおよび/またはUMA
グラフィックスアーキテクチャ)に関して別の利点が潜
在的に得られる。この場合、オペレーティングシステム
のスレッドコンテキスト切換えコードは、CPUのコンテ
キストがロードされるのと同時に、関連するGPUコンテ
キストを任意選択でロードすることができる。この実装
の方策は、CPUコードが図５に示す外部メモリ内に常駐
するコマンドバッファにGPUコマンドを書き込むことが
必要でない可能性のある、あるシステムに対して特に有
利である。スレッドの現GPUコンテキストは、そのコン
テキストがCPU内にあるスレッドのコンテキストで実行
中のコードによって操作することができる可能性のある
唯一のコンテキストであるので、スレッドのGPUコンテ
キストに対応するハードウェアレジスタを、CPUコンテ
キストがロードされると同時にそのスレッドから利用可
能にすることにより、描画コマンドをGPUによる後の消
費のためにバッファに書き込むのとは対照的に、描画コ
マンドをGPUに即時ディスパッチすることが容易とな
る。例えば、x８６アーキテクチャでは、ハードウェア
レジスタをポートI/Oスペースにマッピングすることが
でき、それによってIN/OUT命令をGPUと通信するのに使
用することができ、あるいは、メモリマップ済みレジス
タに公開することができ、それによって特定のメモリ位
置への読み書きがGPUと通信することになる。このよう
な機能は、ハードウェアにサブミットされるコマンドの
厳格な妥当性検査によって実施しなければならず、した
がってバグの多いコードまたは悪意あるコードによって
開始された偽のオペレーションが、オペレーティングシ
ステムをクラッシュまたは破壊することはできない。次
いで図５のユーザモードドライバ５２０は、コマンドを
コマンドバッファに書き込むのではなく、これらのハー
ドウェア機能に関するオペレーションを現スレッドに公
開されたものとして単に実施する。

【０１５８】この方式により、図５で対処したスケジュ
ーリング問題および待機問題のほとんど、またはすべて
が、オペレーティングシステムのスレッドスケジューリ
ング機構に効果的に合併される。例えば、オペレーティ
ングシステムは、所与のリソースが利用可能となるまで
(例えば１つのメモリがページインされた後に利用可能
となるまで)実行することができないスレッドを中断す
るための機能を含む。この機能は増強しなければなら
ず、それによってこのスレッドの現GPUコンテキストに
対して必要なリソースを含む、実行を続行するのに必要
なリソースすべてが利用可能になるまで、現GPUコンテ
キストを有するスレッドが中断される。オペレーティン
グシステム中の仮想メモリ/ページング機能に関して
は、オペレーティングシステムと基礎となるハードウェ
ア機能との間の密接な協調が、そのようなシステムを実
施するのに必要となる。

【０１５９】このようなシステムの実装により、スレッ
ドコンテキスト切換えがより高価になるかもしれない
が、コンテキストが現在ロードされているCPUスレッド
にとってGPUコンテキストが現行ではない場合に、GPUを
コンテキスト切り換えしないことなどの最適化を実施す
るのが簡単である。

【０１６０】図４から７に関連して説明したシステム
で、管理コードを活用することができる。例えば、２０
０２年１月４日に出願された「管理ドライバアプリケー
ション」という名称の、同時係属出願の米国特許出願第
１０/０３９，０３５号に記載されているように、固有
のグラフィックス処理およびグラフィックスシステムの
方式で、中間言語形式でオブジェクトを管理するシステ
ムおよび方法が説明されている。図５のシステムは、具
体的には、アプリケーション５００、ランタイム５１
０、および/またはユーザモードドライバ５２０の部分
が中間言語形式で送達され、クライアント上でJITコン
パイルされる管理コードを活用することができる。この
３つのコンポーネントは、中間言語形式でクライアント
に別々に送達される。次いでJITコンパイラは、３つの
コンポーネントのすべての部分を含む、統合された１つ
のオブジェクトコードにそれらを合成する。このような
アーキテクチャの潜在的な利点は、より最適なオブジェ
クトコードが実行されることである。例えばクライアン
トコンピュータ上で利用可能なマイクロプロセッサに特
有の最適化などの利点とは無関係に、エントリポイント
へのアプリケーション５００の呼出しでの定数は、ラン
タイム５１０およびユーザモードドライバ５２０に伝播
することができ、潜在的には、同じ結果を達成するため
に何回か関数呼出し境界を横断する代わりに、いくつか
の一定の語をコマンドバッファに書き込むオブジェクト
コードが得られる。ユーザモードドライバ５２０はクラ
イアント上のグラフィックスハードウェアに特有である
ので、アプリケーション５００の中間言語形式は依然と
してハードウェア独立である。

【０１６１】最大の仮説的な性能改善が、３つのコンポ
ーネント(アプリケーション５００、ランタイム５１
０、およびユーザモードドライバ５２０)すべてに対す
る管理コードを生成することによって達成されるのに対
して、システムはアプリケーション５００およびランタ
イム５１０を管理させ、別々のユーザモードドライバ５
２０と対話することができ、さらには単にアプリケーシ
ョン５００を管理させ、別々のランタイム５１０および
ユーザモードドライバ５２０と対話することができる。
実際、このようなサブシステムは、ランタイム５１０お
よび/またはユーザモードドライバ５２０の中間言語形
式およびユーザモードDLL形式がどちらも利用可能であ
ることを条件として、安全に共存するように作成するこ
とができる。

【０１６２】図６および７のシステムはまた、既に多く
について説明したレイトバウンド（late-bound）管理コ
ードからも利点を得ることができる。ランタイム６０２
および７０２が管理される場合、JITは、実行時のパラ
メータ妥当性チェックなどの最適化を実施することがで
きる。図６のシステムでは、JITによって生成された、
統合された１つのオブジェクトコードは、ハードウェア
への最終的なサブミットのために、カノニカルコマンド
バッファデータをDMA可能メモリに書き込む。図７のシ
ステムでは、JITによって生成されたオブジェクトコー
ドは、カーネルモードドライバによる構文解析および変
換のために、中間バッファにデータを放出する。

【０１６３】ほとんどの部分では、この文書で述べたシ
ステムは、ハードウェアがDMA可能であることを想定し
ている。複数のクライアントアプリケーションがハード
ウェアにコマンドを送ろうとする可能性があり、DMA
は、それらのアプリケーションが互いの干渉または競合
を最小となるように並列に動作させるための直接的な方
法であるからである。本発明は、PIOまたはMMIOなどの
異なるモデルを使用してプログラムされる非DMAハード
ウェア上で動作するように再構築することができる。こ
のようなシステムを実装するには、ドライバのユーザモ
ード部分は、ハードウェアで直接消費することができる
ハードウェア特有のトークンストリームではなく、１組
のハードウェア独立なトークンをバッファに書き込むこ
とができる。スケジューラがコマンドバッファをカーネ
ルドライバにサブミットしたとき、カーネルドライバ
は、ハードウェア独立なトークンをハードウェア特有の
コマンドに変換し、それをハードウェアのネイティブ制
御機構を介して送る。このような実装に対処するため
に、システムは、ユーザモードドライバが書き込むため
の非DMAメモリの割振りを提供しなければならず、コマ
ンドバッファ完了を通知するための適切な機構を実装し
なければならない。非DMAメモリを割り振る問題に対処
するために、システムは、コマンドバッファメモリをそ
のユーザモード複製に割り振り、書き込むオプションを
カーネルドライバに与えることができる。コマンドバッ
ファの完了を通知する問題に対処するために、カーネル
ドライバに対するインターフェースは、コマンドバッフ
ァがハードウェアによって実行されたという返り値を介
して、スケジューラに通知するオプションを、ドライバ
に与えることができる。

【０１６４】上述のように、様々なコンピューティング
装置およびネットワークアーキテクチャに関連して本発
明の例示的実施形態を説明したが、基礎となる概念は、
コプロセッシングリソースを管理することが望ましいど
んなコンピューティング装置またはシステムにも適用す
ることができる。したがって、本発明による、コプロセ
ッサの計算リソースを管理する技術は、様々なアプリケ
ーションおよび装置に適用することができる。例えば、
本発明の管理技法は、装置上の別個のオブジェクトとし
て、別のオブジェクトの一部として、サーバからダウン
ロード可能なオブジェクトとして、装置またはオブジェ
クトとネットワーク間の「仲介役」として、分散オブジ
ェクトなどとして提供されるコンピューティング装置の
グラフィックシステムに適用することができる。本明細
書では、様々な選択肢の代表的なものとして例示的プロ
グラミング言語、名前、および例を選んだが、これらの
言語、名前、および例は限定的なものではない。

【０１６５】本明細書に記載した各種技術は、ハードウ
ェアまたはソフトウェア、あるいは適切な場合には両方
の組合せと共に実装することができる。したがって、本
発明の方法および装置、またはその特定の態様または部
分は、フロッピー（登録商標）ディスケット、CD-ROM、
ハードドライブ、あるいはその他の任意の機械可読記憶
媒体など有形の媒体で実施されるプログラムコード(す
なわち命令)の形をとることができ、この場合このプロ
グラムコードがコンピュータなどのマシンにロードさ
れ、実行されると、そのマシンは本発明を実施する装置
となる。プログラム可能なコンピュータでプログラムコ
ードを実行する場合、コンピューティング装置は一般
に、プロセッサ、プロセッサで可読な記憶媒体(揮発性
および不揮発性のメモリおよび/または記憶素子)、少な
くとも１つの入力装置、および少なくとも１つの出力装
置を含む。例えばデータ処理APIなどを使用することに
より、本発明の管理技法を利用することが可能な１つま
たは複数のプログラムは、高レベルの手続き型プログラ
ミング言語またはオブジェクト指向プログラミング言語
で実装してコンピュータシステムと通信することが好ま
しい。しかし、望ましい場合はアセンブリ言語や機械語
でプログラムを実装することができる。いずれの場合
も、言語はコンパイル型言語またはインタプリタ型言語
でよく、ハードウェア実装と組み合わせることができ
る。

【０１６６】本発明の方法および装置は、電気的な配線
またはケーブル、光ケーブル、あるいは他の任意の形態
の伝送などの、何らかの伝送媒体を介して伝送されるプ
ログラムコードの形で実施された通信を介して実施する
ことも可能であり、この場合は、プログラムコードが、
EPROM、ゲートアレイ、プログラマブルロジックデバイ
ス(PLD)、クライアントコンピュータ、ビデオレコーダ
などのマシンで受信され、ロードされ、実行されると、
上記の例示的実施形態で説明したリソース管理機能を有
する受信側のマシンが本発明を実施する装置になる。汎
用プロセッサで実装するとき、このプログラムコード
は、プロセッサと組み合わされ、本発明の機能を起動す
るように動作する固有の装置を提供する。さらに、本発
明に関連して使用する任意の記憶技術は常にハードウェ
アとソフトウェアの組合せでよい。

【０１６７】様々な図の好ましい実施形態と共に本発明
を説明したが、他の類似の実施形態を使用することがで
き、あるいは本発明から逸脱することなく本発明と同じ
機能を実施するために記載の実施形態に修正や追加を行
うことができることを理解されたい。例えば、本発明の
例示的なネットワーク環境は、ピアツーピアのネットワ
ーク環境などネットワーク環境の状況で説明している
が、本発明はこれに限定されず、本願に記載の方法は、
有線、無線を問わず、ゲームコンソール、ハンドヘルド
コンピュータ、ポータブルコンピュータなど任意のコン
ピューティング装置や環境に応用することができ、また
通信ネットワークを介して接続され、そのネットワーク
を介して接続された任意の数の上記のようなコンピュー
ティング装置に応用できることを当業者は理解されよ
う。さらに、特に無線ネットワーク装置の数が依然とし
て増加しているので、ハンドヘルド装置のオペレーティ
ングシステム、およびアプリケーション特有のオペレー
ティングシステムを含む様々なコンピュータプラットフ
ォームが企図されることを強調しておく。さらに、本発
明は、複数の処理チップまたはプロセッサ中に、あるい
は複数の処理チップおよびプロセッサにわたって実施す
ることができ、記憶装置も同様に複数の装置にわたって
実施することができる。したがって、本発明はどの単一
の実施形態にも限定されず、特許請求の範囲による広さ
と範囲において解釈すべきである。

【０１６８】

【発明の効果】以上説明したように本発明によれば、コ
ンピューティングシステム中のコプロセッサの計算リソ
ースの効率的な管理が可能となる。

【図面の簡単な説明】

【図１Ａ】本発明を実施することができる、様々なコン
ピューティング装置を有する例示的ネットワーク環境を
表すブロック図である。

【図１Ｂ】本発明を実施することができる、例示的な非
限定的コンピューティング装置を表すブロック図であ
る。

【図２】コプロセッサにコマンドを送るためにアプリケ
ーションがコマンドバッファを使用するときの、コマン
ドバッファの例示的ライフサイクルを示す図である。

【図３Ａ】ランタイムレベルコマンドをハードウェア特
有のコマンドに変換するドライバコンポーネントの例示
的実装を示す図である。

【図３Ｂ】ランタイムレベルコマンドをハードウェア特
有のコマンドに変換するドライバコンポーネントの例示
的実装を示す図である。

【図３Ｃ】ランタイムレベルコマンドをハードウェア特
有のコマンドに変換するドライバコンポーネントの例示
的実装を示す図である。

【図３Ｄ】ランタイムレベルコマンドをハードウェア特
有のコマンドに変換するドライバコンポーネントの例示
的実装を示す図である。

【図３Ｅ】ランタイムレベルコマンドをハードウェア特
有のコマンドに変換するドライバコンポーネントの例示
的実装を示す図である。

【図４】本発明の例示的ユーザモードのドライバDLLの
実装を示す図である。

【図５】アプリケーションがアプリケーションプログラ
ミングインターフェース呼出しを行って、グラフィック
スオペレーションを実施するときに発生するイベントの
例示的シーケンスを例として詳細に示す図である。

【図６】本発明の実施形態による例示的ハードウェアの
消費可能カノニカルコマンドバッファのフォーマットを
示す図である。

【図７】本発明の実施形態による例示的中間カノニカル
コマンドバッファのフォーマットを示す図である。

【符号の説明】

１０a、１０b サーバコンピュータ１４通信ネットワーク/バス２０データベース１００コンピューティングシステム環境１１０コンピュータ１１０a、１１０b、１１０c、１１０d、１１０e コン
ピューティング装置１２０プロセッサ１２１システムバス１３０システムメモリ１３１ ROM １３２ RAM １３３ BIOS １３４、１４４オペレーティングシステム１３５、１４５、１８５アプリケーションプログラム１３５ａ〜１３５ｅオブジェクト１３６、１４６他のプログラムモジュール１３７、１４７プログラムデータ１４０、１５０インターフェース１４１ハードディスクドライブ１５１磁気ディスクドライブ１５２磁気ディスク１５５光ディスクドライブ１５６光ディスク１６０ユーザ入力インターフェース１６１ポインティングデバイス１６２キーボード１７０アダプタ１７１ LAN １７２モデム１７３ WAN １８０リモートコンピュータ１８１メモリ記憶装置１８２グラフィックスインタフェース１８４ GPU １８６ビデオメモリ１９０ビデオインタフェース１９１モニタ１９５出力周辺インターフェース１９６プリンタ１９７スピーカ２０１初期化２０２受け取り２０３待機２０４レディ２０５スタンバイ２０６実行２０７終了３０１、３１１、３２１、３３１、３４１、４０１、５
００アプリケーション３０２、３１２、３２２、３３２、３４２、５１０、６
０２、７０２ランタイム３０３、３１４、３２４、３３６、３４３、４０３、４
０５ドライバ３０４、３１５、３２５、３３７、３４６コマンドバ
ッファ３０６、４０６ハードウェア３１３、３３５トークンストリーム３２３、３３４、３４５実行可能アプリケーション４０４コマンドバッッファスケジューラ４０５カーネルドライバ４１０ DMAメモリ５２０ユーザモードドライバ５３０システムカーネルサポート５５０カーネルドライバ５６０ハードウェア７０３バッファ７０７ DMAメモリ

───────────────────────────────────────────────────── フロントページの続き (72)発明者ニコラスピー．ウィルトアメリカ合衆国 98074 ワシントン州サマミッシュ 205 プレイスノースイースト 1920 (72)発明者サミールエー．ネネアメリカ合衆国 98052 ワシントン州レッドモンドノースイースト 46 コート 15816 (72)発明者ジョーゼフエス．ベーダザサードアメリカ合衆国 98103 ワシントン州シアトルデンスモアアベニューノース 3819 Ｆターム(参考） 5B013 DD03 5B045 AA01 GG08 HH04 5B098 AA10 GA05 GB13 GD02 GD14

Claims

【特許請求の範囲】

【請求項１】ホストプロセッサを有するホストコンピ
ューティングシステム中の少なくとも１つのコプロセッ
サの計算リソースを制御するための方法であって、前記ホストコンピューティングシステムのホストプロセ
ッサによって前記少なくとも１つのコプロセッサにサブ
ミットされたコマンドバッファで、前記コンピューティ
ングシステムの前記少なくとも１つのコプロセッサを制
御するステップと、前記コマンドバッファの少なくとも１つのコマンドバッ
ファ中のコマンドに応答して、前記少なくとも１つのコ
プロセッサによって前記ホストコンピューティングシス
テムにデータを戻して伝送するステップと、前記ホストコンピューティングシステム中に含まれる管
理オブジェクトによって前記コマンドバッファの前記伝
送をスケジューリングするステップとを備え、前記少なくとも１つのコプロセッサの前記計算リソース
は、前記ホストコンピューティングシステム上でインス
タンス化された複数のアプリケーションから同時に利用
可能であることを特徴とする方法。
【請求項２】前記スケジューリングは、前記ホストコ
ンピューティングシステム中に含まれるオペレーティン
グシステムによって、前記コマンドバッファの前記伝送
をスケジューリングすることを含むことを特徴とする請
求項１に記載の方法。
【請求項３】前記管理オブジェクトは、コプロセッサ
から、コマンドバッファが実行を終了したという通知を
受けることを特徴とする請求項１に記載の方法。
【請求項４】現コマンドバッファが終了したときにコ
プロセッサが実行を開始するための新しいコマンドバッ
ファを待ち行列に入れるステップをさらに含むことを特
徴とする請求項１に記載の方法。
【請求項５】コマンドバッファがサブミットされたと
きにコプロセッサコンテキスト切換えを指定するステッ
プをさらに含むことを特徴とする請求項１に記載の方
法。
【請求項６】前記管理オブジェクトにより、複数のタ
イプのコプロセッサコンテキストが可能となることを特
徴とする請求項１に記載の方法。
【請求項７】コプロセッサコンテキストをホストプロ
セッサスレッドコンテキストと関係付けるステップをさ
らに含むことを特徴とする請求項６に記載の方法。
【請求項８】前記管理オブジェクトにより、前記ホス
トプロセッサおよび前記コプロセッサに対するコンテキ
スト切換えコードを統合するステップをさらに含むこと
を特徴とする請求項７に記載の方法。
【請求項９】コマンドバッファが無効であることを、
コプロセッサによって前記管理オブジェクトに通知する
ステップをさらに含むことを特徴とする請求項１に記載
の方法。
【請求項１０】前記少なくとも１つのコプロセッサの
うちのコプロセッサが所定の期間応答しない場合に、前
記コプロセッサをリセットするステップをさらに含むこ
とを特徴とする請求項１に記載の方法。
【請求項１１】前記コマンドバッファの合成中に、ハ
ードウェア特有のドライバオブジェクトにより、前記管
理オブジェクトのアプリケーションプログラミングイン
ターフェースを介してコマンドバッファの命令をハード
ウェア特有の命令に変換するステップをさらに含むこと
を特徴とする請求項１に記載の方法。
【請求項１２】前記変換はユーザモードで動作するこ
とを特徴とする請求項１１に記載の方法。
【請求項１３】バッファオーバーフローを効率的に検
出することを容易にするために、保護ページを前記コマ
ンドバッファの終わりに割り振るステップをさらに含む
ことを特徴とする請求項１２に記載の方法。
【請求項１４】前記ユーザモードドライバ、および対
応するランタイムコンポーネントが中間言語形式で提供
され、前記ユーザモードドライバおよびランタイムコン
ポーネントを有するクライアント装置上でのjust in ti
me(JIT)コンパイルをさらに含むことを特徴とする請求
項１２に記載の方法。
【請求項１５】前記アプリケーションも中間言語形式
で提供され、前記JITコンパイルは、前記ユーザモード
ドライバおよびランタイムを有する前記クライアント装
置上での前記アプリケーションのJITコンパイルを含む
ことを特徴とする請求項１４に記載の方法。
【請求項１６】前記ドライバオブジェクトは、対応す
るカーネルモードドライバオブジェクトと協働し、前記
コマンドバッファをハードウェアにサブミットする前に
編集することを特徴とする請求項１２に記載の方法。
【請求項１７】前記少なくとも１つのコプロセッサ
は、少なくとも１つのグラフィックスプロセッサを含む
ことを特徴とする請求項１に記載の方法。
【請求項１８】外部イベントの発生時に、前記少なく
とも１つのコプロセッサによって切り替えるステップを
さらに含むことを特徴とする請求項１に記載の方法。
【請求項１９】前記外部イベントは、オペレーティン
グシステムが対応するカーネルモードドライバオブジェ
クトに呼出しを行って前記少なくとも１つのコプロセッ
サを切り替えることであることを特徴とする請求項１８
に記載の方法。
【請求項２０】前記ホストプロセッサは、処理時間の
スケジューリングを調整するために割込みを受けること
を特徴とする請求項１８に記載の方法。
【請求項２１】コマンドバッファの前記制御データス
トリームをコプロセッサにサブミットする前に編集する
間、前記管理オブジェクトによって、前記少なくとも１
つのコプロセッサの少なくとも１つのリソースを仮想化
するステップをさらに含むことを特徴とする請求項１に
記載の方法。
【請求項２２】前記少なくとも１つのコプロセッサの
前記管理オブジェクトによって仮想化された前記少なく
とも１つのリソースはメモリであることを特徴とする請
求項２１に記載の方法。
【請求項２３】前記管理オブジェクトはスレッド同期
プリミティブを使用して、コプロセッサコマンドバッフ
ァの構築、スケジューリング、およびサブミットを調整
することを特徴とする請求項１に記載の方法。
【請求項２４】請求項１の方法を実施するための複数
のコンピュータ実行可能命令を格納したことを特徴とす
るコンピュータ読み取り可能な記録媒体。
【請求項２５】請求項１の方法を実施するためのコン
ピュータ実行可能命令を搬送することを特徴とする変調
データ信号。
【請求項２６】請求項１の方法を実施する手段を備え
たことを特徴とするコンピューティング装置。
【請求項２７】ホストプロセッサを有するホストコン
ピューティングシステム中の少なくとも１つのコプロセ
ッサの計算リソースを制御するための複数のコンピュー
タ実行可能モジュールを格納した少なくとも１つのコン
ピュータ読み取り可能な記録媒体であって、前記コンピ
ュータ実行可能モジュールは、前記ホストコンピューティングシステムのホストプロセ
ッサによって前記少なくとも１つのコプロセッサにサブ
ミットされたコマンドバッファで、前記コンピューティ
ングシステムの前記少なくとも１つのコプロセッサを制
御し、かつ前記コマンドバッファの伝送をスケジューリ
ングするための管理オブジェクトと、前記コマンドバッファの少なくとも１つのコマンドバッ
ファ中のコマンドに応答して、前記少なくとも１つのコ
プロセッサによって前記ホストコンピューティングシス
テムにデータを戻して伝送する手段とを備え、それによって、前記少なくとも１つのコプロセッサの前
記計算リソースが、前記ホストコンピューティングシス
テム上でインスタンス化された複数のアプリケーション
から同時に利用可能であることを特徴とする少なくとも
１つのコンピュータ読み取り可能な記録媒体。
【請求項２８】前記管理オブジェクトは、前記ホスト
コンピューティングシステムの前記オペレーティングシ
ステム中に含まれることを特徴とする請求項２７に記載
の少なくとも１つのコンピュータ読み取り可能な記録媒
体。
【請求項２９】前記管理オブジェクトは、コプロセッ
サから、コマンドバッファが実行を終了したという通知
を受けることを特徴とする請求項２７に記載の少なくと
も１つのコンピュータ読み取り可能な記録媒体。
【請求項３０】前記管理オブジェクトは、現コマンド
バッファが終了したときにコプロセッサが実行を開始す
るための新しいコマンドバッファを待ち行列に入れるこ
とを特徴とする請求項２７に記載の少なくとも１つのコ
ンピュータ読み取り可能な記録媒体。
【請求項３１】前記管理オブジェクトは、コマンドバ
ッファがサブミットされたときにコプロセッサコンテキ
スト切換えを指定することを特徴とする請求項２７に記
載の少なくとも１つのコンピュータ読み取り可能な記録
媒体。
【請求項３２】前記管理オブジェクトにより、複数の
タイプのコプロセッサコンテキストが可能となることを
特徴とする請求項２７に記載の少なくとも１つのコンピ
ュータ読み取り可能な記録媒体。
【請求項３３】前記管理オブジェクトは、コプロセッ
サコンテキストをホストプロセッサスレッドコンテキス
トと関係付けることを特徴とする請求項３２に記載の少
なくとも１つのコンピュータ読み取り可能な記録媒体。
【請求項３４】前記管理オブジェクトは、前記ホスト
プロセッサおよび前記コプロセッサに対するコンテキス
ト切換えコードを統合することを特徴とする請求項３３
に記載の少なくとも１つのコンピュータ読み取り可能な
記録媒体。
【請求項３５】コプロセッサは、コマンドバッファが
無効であることを前記管理オブジェクトに通知する手段
を備えたことを特徴とする請求項２７に記載の少なくと
も１つのコンピュータ読み取り可能な記録媒体。
【請求項３６】前記管理オブジェクトは、前記少なく
とも１つのコプロセッサのうちのコプロセッサが所定の
期間応答しない場合に、前記コプロセッサをリセットす
ることを特徴とする請求項２７に記載の少なくとも１つ
のコンピュータ読み取り可能な記録媒体。
【請求項３７】前記管理オブジェクトにより、前記コ
マンドバッファの合成中に、ハードウェア特有のドライ
バオブジェクトによってコマンドバッファの命令をハー
ドウェア特有の命令に変換することが可能となることを
特徴とする請求項２７に記載の少なくとも１つのコンピ
ュータ読み取り可能な記録媒体。
【請求項３８】前記ドライバオブジェクトによる前記
変換はユーザモードで動作することを特徴とする請求項
３７に記載の少なくとも１つのコンピュータ読み取り可
能な記録媒体。
【請求項３９】前記管理オブジェクトは、バッファオ
ーバーフローを効率的に検出することを容易にするため
に、保護ページを前記コマンドバッファの終わりに割り
振ることを特徴とする請求項３８に記載の少なくとも１
つのコンピュータ読み取り可能な記録媒体。
【請求項４０】前記ユーザモードドライバ、および対
応するランタイムコンポーネントは中間言語形式で提供
され、前記ユーザモードドライバおよびランタイムコン
ポーネントは、just in time(JIT)コンパイルされるこ
とを特徴とする請求項３８に記載の少なくとも１つのコ
ンピュータ読み取り可能な記録媒体。
【請求項４１】前記アプリケーションも中間言語形式
で提供され、前記アプリケーション、前記ユーザモード
ドライバ、およびランタイムはJITコンパイルされるこ
とを特徴とする請求項４０に記載の少なくとも１つのコ
ンピュータ読み取り可能な記録媒体。
【請求項４２】前記ドライバオブジェクトは、対応す
るカーネルモードドライバオブジェクトと協働し、前記
コマンドバッファをハードウェアにサブミットする前に
編集することを特徴とする請求項３８に記載の少なくと
も１つのコンピュータ読み取り可能な記録媒体。
【請求項４３】前記少なくとも１つのコプロセッサ
は、少なくとも１つのグラフィックスプロセッサを含む
ことを特徴とする請求項２７に記載の少なくとも１つの
コンピュータ読み取り可能な記録媒体。
【請求項４４】前記管理オブジェクトは、外部イベン
トの発生時に、前記少なくとも１つのコプロセッサによ
って切り替わることを特徴とする請求項２７に記載の少
なくとも１つのコンピュータ読み取り可能な記録媒体。
【請求項４５】前記外部イベントは、オペレーティン
グシステムが対応するカーネルモードドライバオブジェ
クトに呼出しを行って前記少なくとも１つのコプロセッ
サを切り替えることであることを特徴とする請求項４４
に記載の少なくとも１つのコンピュータ読み取り可能な
記録媒体。
【請求項４６】前記ホストプロセッサは、処理時間の
スケジューリングを調整するために前記管理オブジェク
トによって割込みを受けることを特徴とする請求項２７
に記載の少なくとも１つのコンピュータ読み取り可能な
記録媒体。
【請求項４７】コマンドバッファの制御データストリ
ームをコプロセッサにサブミットする前に編集する間、
前記管理オブジェクトは、前記少なくとも１つのコプロ
セッサの少なくとも１つのリソースを仮想化することを
特徴とする請求項２７に記載の少なくとも１つのコンピ
ュータ読み取り可能な記録媒体。
【請求項４８】前記少なくとも１つのコプロセッサの
前記管理オブジェクトによって仮想化された前記少なく
とも１つのリソースはメモリであることを特徴とする請
求項４７に記載の少なくとも１つのコンピュータ読み取
り可能な記録媒体。
【請求項４９】前記管理オブジェクトはスレッド同期
プリミティブを使用して、コプロセッサコマンドバッフ
ァの構築、スケジューリング、およびサブミットを調整
することを特徴とする請求項２７に記載の少なくとも１
つのコンピュータ読み取り可能な記録媒体。
【請求項５０】請求項２７に記載の前記コンピュータ
読み取り可能な記録媒体の前記複数のコンピュータ実行
可能命令の実行の結果として出力されたコンピュータ実
行可能命令を搬送することを特徴とする変調データ信
号。
【請求項５１】請求項２７に記載の前記コンピュータ
読み取り可能な記録媒体の前記複数のコンピュータ実行
可能命令を実施する手段を備えたことを特徴とするコン
ピューティング装置。
【請求項５２】ホストプロセッサを有するホストコン
ピューティングシステム中の少なくとも１つのコプロセ
ッサの計算リソースを制御するためのコンピューティン
グ装置であって、前記ホストコンピューティングシステムのホストプロセ
ッサによって前記少なくとも１つのコプロセッサにサブ
ミットされたコマンドバッファで、前記コンピューティ
ングシステムの前記少なくとも１つのコプロセッサを制
御し、かつ前記コマンドバッファの伝送をスケジューリ
ングするための管理オブジェクトと、前記コマンドバッファの少なくとも１つのコマンドバッ
ファ中のコマンドに応答して、前記少なくとも１つのコ
プロセッサによって前記ホストコンピューティングシス
テムにデータを戻して伝送する手段とを備え、それによって、前記少なくとも１つのコプロセッサの前
記計算リソースが、前記ホストコンピューティングシス
テム上でインスタンス化された複数のアプリケーション
から同時に利用可能であることを特徴とするコンピュー
ティング装置。
【請求項５３】前記管理オブジェクトは、前記ホスト
コンピューティングシステムのオペレーティングシステ
ム中に含まれることを特徴とする請求項５２に記載のコ
ンピューティング装置。
【請求項５４】前記管理オブジェクトは、コプロセッ
サから、コマンドバッファが実行を終了したという通知
を受けることを特徴とする請求項５２に記載のコンピュ
ーティング装置。
【請求項５５】前記管理オブジェクトは、現コマンド
バッファが終了したときにコプロセッサが実行を開始す
るための新しいコマンドバッファを待ち行列に入れるこ
とを特徴とする請求項５２に記載のコンピューティング
装置。
【請求項５６】前記管理オブジェクトは、コマンドバ
ッファがサブミットされたときにコプロセッサコンテキ
スト切換えを指定することを特徴とする請求項５２に記
載のコンピューティング装置。
【請求項５７】前記管理オブジェクトにより、複数の
タイプのコプロセッサコンテキストが可能となることを
特徴とする請求項５２に記載のコンピューティング装
置。
【請求項５８】前記管理オブジェクトは、コプロセッ
サコンテキストをホストプロセッサスレッドコンテキス
トと関係付けることを特徴とする請求項５７に記載のコ
ンピューティング装置。
【請求項５９】前記管理オブジェクトは、前記ホスト
プロセッサおよび前記コプロセッサに対するコンテキス
ト切換えコードを統合することを特徴とする請求項５８
に記載のコンピューティング装置。
【請求項６０】コプロセッサは、コマンドバッファが
無効であることを前記管理オブジェクトに通知する手段
を備えたことを特徴とする請求項５２に記載のコンピュ
ーティング装置。
【請求項６１】前記管理オブジェクトは、前記少なく
とも１つのコプロセッサのうちのコプロセッサが所定の
期間応答しない場合に、前記コプロセッサをリセットす
ることを特徴とする請求項５２に記載のコンピューティ
ング装置。
【請求項６２】前記管理オブジェクトにより、前記コ
マンドバッファの合成中に、ハードウェア特有のドライ
バオブジェクトによってコマンドバッファの命令をハー
ドウェア特有の命令に変換することが可能となることを
特徴とする請求項５２に記載のコンピューティング装
置。
【請求項６３】前記ドライバオブジェクトによる前記
変換はユーザモードで動作することを特徴とする請求項
６２に記載のコンピューティング装置。
【請求項６４】前記管理オブジェクトは、バッファオ
ーバーフローを効率的に検出することを容易にするため
に、保護ページを前記コマンドバッファの終わりに割り
振ることを特徴とする請求項６３に記載のコンピューテ
ィング装置。
【請求項６５】前記ユーザモードドライバ、および対
応するランタイムコンポーネントは中間言語形式で提供
され、前記ユーザモードドライバおよびランタイムコン
ポーネントは、just in time(JIT)コンパイルされるこ
とを特徴とする請求項６３に記載のコンピューティング
装置。
【請求項６６】前記アプリケーションも中間言語形式
で提供され、前記アプリケーション、前記ユーザモード
ドライバ、およびランタイムはJITコンパイルされるこ
とを特徴とする請求項６５に記載のコンピューティング
装置。
【請求項６７】前記ドライバオブジェクトは、対応す
るカーネルモードドライバオブジェクトと協働し、前記
コマンドバッファをハードウェアにサブミットする前に
編集することを特徴とする請求項６３に記載のコンピュ
ーティング装置。
【請求項６８】前記少なくとも１つのコプロセッサ
は、少なくとも１つのグラフィックスプロセッサを含む
ことを特徴とする請求項５２に記載のコンピューティン
グ装置。
【請求項６９】前記管理オブジェクトが、外部イベン
トの発生時に、前記少なくとも１つのコプロセッサによ
って切り替わることを特徴とする請求項５２に記載のコ
ンピューティング装置。
【請求項７０】前記外部イベントは、オペレーティン
グシステムが対応するカーネルモードドライバオブジェ
クトに呼出しを行って前記少なくとも１つのコプロセッ
サを切り替えることであることを特徴とする請求項６９
に記載のコンピューティング装置。
【請求項７１】前記ホストプロセッサは、処理時間の
スケジューリングを調整するために前記管理オブジェク
トによって割込みを受けることを特徴とする請求項５２
に記載のコンピューティング装置。
【請求項７２】コマンドバッファの制御データストリ
ームをコプロセッサにサブミットする前に編集する間、
前記管理オブジェクトは、前記少なくとも１つのコプロ
セッサの少なくとも１つのリソースを仮想化することを
特徴とする請求項５２に記載のコンピューティング装
置。
【請求項７３】前記少なくとも１つのコプロセッサの
前記管理オブジェクトによって仮想化された前記少なく
とも１つのリソースはメモリであることを特徴とする請
求項７２に記載のコンピューティング装置。
【請求項７４】前記管理オブジェクトはスレッド同期
プリミティブを使用して、コプロセッサコマンドバッフ
ァの構築、スケジューリング、およびサブミットを調整
することを特徴とする請求項５２に記載のコンピューテ
ィング装置。