(57)【要約】【課題】複数のグラフィックス・プロセスのコンテキスト管理のために、データ処理システムにおける方法および装置を提供すること。【解決手段】複数のグラフィックス・プロセス内の第１グラフィックス・プロセスからグラフィックス・アダプタにグラフィックス・データを送る要求が受け取られる。グラフィックス・アダプタが第１グラフィックス・プロセスからのグラフィックス・データを処理するために、現在のコンテキストの完全な変更が必要であるかどうかに関する判定を行う。現在のコンテキストの一部だけが変更を必要とする場合には、変更される部分を保管する。その後、グラフィックス・プロセスに関するコンテキスト情報を検索し、メモリに格納されたコンテキストの組を使用して、必要な現在のコンテキスト情報に配置する。【選択図】図６
2004505355.tif 000002
【特許請求の範囲】
【請求項１】
データ処理システムにおいて、複数のグラフィックス・プロセスからのデータを処理する方法であって、
グラフィックス・データをグラフィックス・アダプタに送るためにグラフィックス・プロセスからの要求の受け取りに応答して、前記複数のグラフィックス・プロセスからの前記グラフィックス・プロセスに関する前記グラフィックス・データを処理するために、前記グラフィックス・アダプタ内の現在のコンテキストの完全な変更が必要であるかどうかを判定するステップと、
前記現在のコンテキストの完全な変更の必要がない場合に、メモリに格納されたコンテキストの組からの前記グラフィックス・アダプタ内の関連するコンテキストを使用して前記現在のコンテキストの一部を変更するステップとを含み、
前記関連するコンテキストが前記グラフィックス・プロセスに関連する、
方法。
【請求項２】
前記コンテキストがテクスチャ・マッピングおよびカラー・ルックアップを含む、請求項１に記載の方法。
【請求項３】
前記現在のコンテキストが２次元グラフィックス環境に関する、請求項１または２に記載の方法。
【請求項４】
前記現在のコンテキストが３次元グラフィックス環境に関する、請求項１または２に記載の方法。
【請求項５】
前記メモリがバッファである、請求項１に記載の方法。
【請求項６】
前記バッファがコンテキストの組を格納する、請求項５に記載の方法。
【請求項７】
前記コンテキストの組がグラフィックス・プロセスの組によってアクセス可能である、請求項１ないし６のいずれか一項に記載の方法。
【請求項８】
前記関連するコンテキストを復元する前に、前記現在のコンテキストを保管することをさらに含む、請求項１ないし７のいずれか一項に記載の方法。
【請求項９】
前記現在のコンテキストが、前記複数のグラフィックス・プロセス内のもう１つのグラフィックス・プロセスに関連する、請求項１ないし８のいずれか一項に記載の方法。
【請求項１０】
データ処理システムにおいて、複数のグラフィックス・プロセスに関するコンテキスト管理のための方法であって、
前記複数のグラフィックス・プロセス内の第１グラフィックス・プロセスからグラフィックス・アダプタにグラフィックス・データを送る要求を受け取るステップと、
前記グラフィックス・アダプタが前記第１グラフィックス・プロセスからの前記グラフィックス・データを処理して識別された量を形成するために、現在のコンテキストのすべてより少ない変更が必要であるかどうかを判定するステップと、
メモリに格納されるコンテキストの組を使用して、前記現在のコンテキストの前記識別された量をもう１つのコンテキストに変更するステップとを含み、
前記現在のコンテキストのすべてより少ない部分が変更される、
方法。
【請求項１１】
現在のコンテキストのすべてより少ない変更が、前記グラフィックス・アダプタが前記第１グラフィックス・プロセスからの前記グラフィックス・データを処理するのに不十分であると判定された場合に、前記現在のコンテキストのすべてを変更するステップをさらに含む、請求項１０に記載の方法。
【請求項１２】
前記グラフィックス・データを前記グラフィックス・アダプタに送るステップをさらに含む、請求項１１に記載の方法。
【請求項１３】
前記変更するステップが、
前記コンテキストの組を使用して、前記現在のコンテキストを前記もう１つのコンテキストに置換するステップを含む、請求項１１または１２に記載の方法。
【請求項１４】
前記変更するステップが、
前記もう１つのコンテキストを形成するために、前記現在のコンテキストの一部を前記コンテキストの組からのコンテキスト情報に置換するステップを含む、請求項１１ないし１３のいずれか一項に記載の方法。
【請求項１５】
前記複数のグラフィックス・プロセス内のグラフィックス・プロセスが、前記グラフィックス・プロセスに関連するコンテキストにコンテキスト情報を書き込む、請求項１０ないし１４のいずれか一項に記載の方法。
【請求項１６】
複数のグラフィックス・プロセスからのデータを処理するデータ処理システムであって、
グラフィックス・データをグラフィックス・アダプタに送るためにグラフィックス・プロセスからの要求の受取りに応答して、前記複数のグラフィックス・プロセスからの前記グラフィックス・プロセスに関する前記グラフィックス・データを処理するために、前記グラフィックス・アダプタ内の現在のコンテキストの完全な変更が必要であるかどうかを判定する判定手段と、
前記現在のコンテキストの完全な変更の必要がない場合に、メモリに格納されたコンテキストの組からの前記グラフィックス・アダプタ内の関連するコンテキストを使用して前記現在のコンテキストの一部を変更する変更手段を含み、
前記関連するコンテキストが前記グラフィックス・プロセスに関連する、
データ処理システム。
【請求項１７】
前記関連するコンテキストを復元する前に、前記現在のコンテキストを保管する保管手段をさらに含む、請求項１６に記載のデータ処理システム。
【請求項１８】
前記現在のコンテキストが、前記複数のグラフィックス・プロセス内のもう１つのグラフィックス・プロセスに関連する、請求項１６に記載のデータ処理システム。
【請求項１９】
複数のグラフィックス・プロセスに関するコンテキスト管理のデータ処理システムであって、
前記複数のグラフィックス・プロセス内の第１グラフィックス・プロセスからグラフィックス・アダプタにグラフィックス・データを送る要求を受け取る受取り手段と、
前記グラフィックス・アダプタが前記第１グラフィックス・プロセスからの前記グラフィックス・データを処理して識別された量を形成するために、現在のコンテキストのすべてより少ない変更が必要であるかどうかを判定する判定手段と、
メモリに格納されるコンテキストの組を使用して、前記現在のコンテキストの前記識別された量をもう１つのコンテキストに変更する変更手段を含み、
前記現在のコンテキストのすべてより少ない変更がなされる、
データ処理システム。
【請求項２０】
現在のコンテキストのすべてより少ない変更が、前記グラフィックス・アダプタが前記第１グラフィックス・プロセスからの前記グラフィックス・データを処理するのに不十分であると判定された場合に、前記現在のコンテキストのすべてを変更する変更手段をさらに含む、請求項１９に記載のデータ処理システム。
【請求項２１】
前記グラフィックス・データを前記グラフィックス・アダプタに送る送出手段をさらに含む、請求項１９に記載のデータ処理システム。
【請求項２２】
前記変更する変更手段が、
前記コンテキストの組を使用して、前記現在のコンテキストを前記もう１つのコンテキストに置換する置換手段を含む、請求項１９に記載のデータ処理システム。
【請求項２３】
前記変更する変更手段が、
前記もう１つのコンテキストを形成するために、前記現在のコンテキストの一部を前記コンテキストの組からのコンテキスト情報に置換する置換手段を含む、請求項１９に記載のデータ処理システム。
【請求項２４】
複数のグラフィックス・プロセスからのデータを処理するためにデータ処理システムで使用される、機械可読媒体に記録されたプログラム・コードを含むコンピュータ・プログラムであって、
前記コンピュータ・プログラムはコンピュータに実行させる
グラフィックス・データをグラフィックス・アダプタに送るためにグラフィックス・プロセスからの要求の受取りに応答して、前記複数のグラフィックス・プロセスからの前記グラフィックス・プロセスに関する前記グラフィックス・データを処理するために、前記グラフィックス・アダプタ内の現在のコンテキストの完全な変更が必要であるかどうかを判定する第１命令と、
前記現在のコンテキストの完全な変更の必要がない場合に、メモリに格納されたコンテキストの組からの前記グラフィックス・アダプタ内の関連するコンテキストを使用して前記現在のコンテキストの一部を変更する第２命令とを含み、
前記関連するコンテキストが前記グラフィックス・プロセスに関連する、
コンピュータ・プログラム。
【請求項２５】
複数のグラフィックス・プロセスに関するコンテキスト管理のためにデータ処理システムで使用される、機械可読媒体に記録されたプログラム・コードを含むコンピュータ・プログラムであって、
前記コンピュータ・プログラムはコンピュータに実行させる
前記複数のグラフィックス・プロセス内の第１グラフィックス・プロセスから、グラフィックス・アダプタにグラフィックス・データを送る要求を受け取る第１命令と、
前記グラフィックス・アダプタが前記第１グラフィックス・プロセスからの前記グラフィックス・データを処理して識別された量を形成するために、現在のコンテキストのすべてより少ない変更が必要であるかどうかを判定する第２命令と、
メモリに格納されるコンテキストの組を使用して、前記現在のコンテキストの前記識別された量をもう１つのコンテキストに変更する第３命令とを含み、
前記現在のコンテキストのすべてより少ない部分が変更される、
コンピュータ・プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、全般的には改良されたデータ処理システムに関し、詳細には、グラフィックス・データを処理する方法および装置に関する。
【０００２】
【従来の技術】
パーソナル・コンピュータおよびワーク・ステーションなどのデータ処理システムは、コンピュータ援用設計（ＣＡＤ）アプリケーション、ＣＡＭアプリケーション、およびコンピュータ支援ソフトウェア・エンジニアリング（ＣＡＳＥ）ツールを実行するために一般に使用されている。エンジニア、科学者、技師、および他の人が、これらのアプリケーションを毎日使用する。これらのアプリケーションは、有限要素法分析などの複雑な計算を用いて、構造内の応力をモデル化する。他のアプリケーションには、化学モデリング・アプリケーションまたは分子モデリング・アプリケーションが含まれる。ＣＡＤ／ＣＡＭ／ＣＡＳＥアプリケーションは普通、ユーザに伝えられる情報に関してグラフィックス集中型である。データ処理システム・ユーザは、デスクトップ・パブリッシング・アプリケーションなどの他のグラフィックス集中型アプリケーションを使用する場合がある。一般に、これらのアプリケーションのユーザは、データ処理システムが非常に高速のグラフィックス情報を提供可能であることを要求し、必要とする。
【０００３】
ビデオ・ディスプレイ端末でのグラフィカル表示を実現するグラフィックス・データ・ストリームの処理は、高速応答する表示を提供するために、非常に高速のグラフィックス・システムを必要とする。このタイプのグラフィックス・システムでは、プリミティブが、処理および表示のために受け取られる。プリミティブは、たとえば点、線、円弧、円錐、または球面などのイメージを作成するための構成単位として使用されるグラフィックス要素である。プリミティブは、１つまたは複数の頂点のグループによって定義される。属性を使用して、プリミティブを表示する方法を定義する。属性には、たとえば、線の種類、色、および表面テクスチャが含まれる。頂点は、点、辺の端点、または、２つの辺が交わるポリゴンの角を定義する。データも頂点に関連し、このデータには、位置座標、色、法線、テクスチャ座標などの情報が含まれる。コマンドが、グラフィックス・システムに送られて、プリミティブおよび他のデータを表示のために処理する方法が定義される。
【０００４】
グラフィックス・データ、特に３次元アプリケーションのグラフィックス・データを処理する際に大量のデータおよび計算が必要とされるため、これらの計算の多くは中央処理装置からグラフィックス・アダプタにオフロードされてきた。これらのグラフィックス・システムでは、グラフィックス・アダプタ内に配置されたグラフィックス・パイプラインが、このグラフィックス・データの処理に使用される。パイプラインを用いると、グラフィックス・データ処理が、処理要素のステージに分割され、その中で、データの処理を別々の処理要素によって順次実行することができる。
【０００５】
マルチタスキング・グラフィックス環境では、複数のプロセスが、同一のグラフィックス・アダプタを共用することがしばしばである。各グラフィックス・プロセスが、グラフィックス・データをグラフィックス・アダプタに送るために、各プロセスが、レンダリング・コンテキストを必要とする。このレンダリング・コンテキストは、グラフィックス・データが特定のグラフィックス・プロセスから表示のためにグラフィックス・アダプタに送られる前に、コンテキスト切替ハンドラによって、グラフィックス・アダプタ上で復元される。コンテキスト切替ハンドラは、グラフィックス・プロセスに関するコンテキスト保管機能およびコンテキスト復元機能を実行し、その結果、各グラフィックス・プロセスが、グラフィックス・アダプタにアクセスできるようにする。異なるグラフィックス・プロセスのコンテキストは、大きく異なる場合がある。たとえば、３次元グラフィックス環境は、２次元グラフィックス環境と比較してかなり大きい。現在、コンテキスト・サイズは、すべてのグラフィックス・プロセスについて同一にセットされる。各プロセスのコンテキスト全体の切替が、グラフィックス・データを表示する処理を低速にする。さらに、この機構は、アダプタ内のメモリを浪費し、異なるプロセスに関するコンテキストの切替を低速にする。
【０００６】
【発明が解決しようとする課題】
本発明は、データ処理システムにおいて、複数のグラフィック・プロセスに関するコンテキスト管理のための方法および装置を提供する。
【０００７】
【課題を解決するための手段】
複数のグラフィックス・プロセス内の第１グラフィックス・プロセスからグラフィックス・アダプタにグラフィックス・データを送る要求が受け取られる。グラフィックス・アダプタが第１グラフィックス・プロセスからのグラフィックス・データを処理するのに、現在のコンテキストの完全な変更が必要であるかどうかに関する判定を行う。現在のコンテキストの一部だけが変更を必要とする場合には、変更される部分を保管する。その後、グラフィックス・プロセスに関するコンテキスト情報を検索し、メモリに格納されたコンテキストの組を使用して、必要な現在のコンテキスト情報に配置する。
【０００８】
第１の態様では、本発明は、データ処理システムにおいて、複数のグラフィックス・プロセスからのデータを処理する方法であって、グラフィックス・データをグラフィックス・アダプタに送るためにグラフィックス・プロセスからの要求の受取りに応答して、前記複数のグラフィックス・プロセスからの前記グラフィックス・プロセスに関する前記グラフィックス・データを処理するために、前記グラフィックス・アダプタ内の現在のコンテキストの完全な変更が必要であるかどうかを判定すること、前記現在のコンテキストの完全な変更の必要がない場合に、メモリに格納されたコンテキストの組からの前記グラフィックス・アダプタ内の関連するコンテキストを使用して前記現在のコンテキストの一部を変更することを含み、前記関連するコンテキストが前記グラフィックス・プロセスに関連する、方法を提供する。
【０００９】
第２の態様では、本発明は、データ処理システムにおいて、複数のグラフィックス・プロセスに関するコンテキスト管理のための方法であって、前記複数のグラフィックス・プロセス内の第１グラフィックス・プロセスから、グラフィックス・アダプタにグラフィックス・データを送る要求を受け取ること、前記グラフィックス・アダプタが前記第１グラフィックス・プロセスからの前記グラフィックス・データを処理して識別された量を形成するために、現在のコンテキストのすべてより少ない変更が必要であるかどうかを判定すること、メモリに格納されるコンテキストの組を使用して、前記現在のコンテキストの前記識別された量をもう１つのコンテキストに変更することを含み、前記現在のコンテキストのすべてより少ない変更がなされる、方法を提供する。
【００１０】
第３の態様では、本発明は、複数のグラフィックス・プロセスからのデータを処理するデータ処理システムであって、グラフィックス・データをグラフィックス・アダプタに送るためにグラフィックス・プロセスからの要求の受取りに応答して、前記複数のグラフィックス・プロセスからの前記グラフィックス・プロセスに関する前記グラフィックス・データを処理するために、前記グラフィックス・アダプタ内の現在のコンテキストの完全な変更が必要であるかどうかを判定する判定手段と、前記現在のコンテキストの完全な変更の必要がない場合に、メモリに格納されたコンテキストの組からの前記グラフィックス・アダプタ内の関連するコンテキストを使用して前記現在のコンテキストの一部を変更する変更手段を含み、前記関連するコンテキストが前記グラフィックス・プロセスに関連する、データ処理システムを提供する。
【００１１】
第４の態様では、本発明は、複数のグラフィックス・プロセスに関するコンテキスト管理のデータ処理システムであって、前記複数のグラフィックス・プロセス内の第１グラフィックス・プロセスから、グラフィックス・アダプタにグラフィックス・データを送る要求を受け取る受取り手段と、前記グラフィックス・アダプタが前記第１グラフィックス・プロセスからの前記グラフィックス・データを処理して識別された量を形成するために、現在のコンテキストのすべてより少ない変更が必要であるかどうかを判定する判定手段と、メモリに格納されるコンテキストの組を使用して、前記現在のコンテキストの前記識別された量をもう１つのコンテキストに変更する変更手段とを含み、前記現在のコンテキストのすべてより少ない変更がなされる、データ処理システムを提供する。
【００１２】
第５の態様では、本発明は、複数のグラフィックス・プロセスからのデータを処理するためにデータ処理システムで使用される、機械可読媒体内のコンピュータ・プログラム製品であって、グラフィックス・データをグラフィックス・アダプタに送るためにグラフィックス・プロセスからの要求の受取りに応答して、前記複数のグラフィックス・プロセスからの前記グラフィックス・プロセスに関する前記グラフィックス・データを処理するために、前記グラフィックス・アダプタ内の現在のコンテキストの完全な変更が必要であるかどうかを判定する第１命令と、前記現在のコンテキストの完全な変更の必要がない場合に、メモリに格納されたコンテキストの組からの前記グラフィックス・アダプタ内の関連するコンテキストを使用して前記現在のコンテキストの一部を変更する第２命令とを含み、前記関連するコンテキストが前記グラフィックス・プロセスに関連する、コンピュータ・プログラム製品を提供する。
【００１３】
第６の態様では、本発明は、複数のグラフィックス・プロセスに関するコンテキスト管理のためにデータ処理システムで使用される、機械可読媒体内のコンピュータ・プログラム製品であって、前記複数のグラフィックス・プロセス内の第１グラフィックス・プロセスから、グラフィックス・アダプタにグラフィックス・データを送る要求を受け取る第１命令と、前記グラフィックス・アダプタが前記第１グラフィックス・プロセスからの前記グラフィックス・データを処理して識別された量を形成するために、現在のコンテキストのすべてより少ない変更が必要であるかどうかを判定する第２命令と、メモリに格納されるコンテキストの組を使用して、前記現在のコンテキストの前記識別された量をもう１つのコンテキストに変更する第３命令とを含み、前記現在のコンテキストのすべてより少ない変更がなされる、コンピュータ・プログラム製品を提供する。
【００１４】
本発明によるコンピュータ・プログラムを、計算機可読記録媒体に記録されたプログラム・コードを含むプログラム製品として使用可能にすることができる。
【００１５】
例として添付図面に関して、本発明の好ましい実施形態をこれから詳細に説明する。
【００１６】
【発明の実施の形態】
ここで図面、具体的には図１を参照すると、本発明の好ましい実施形態に従って本発明を実施することができるデータ処理システムを絵で表したものが示されている。コンピュータ１００が示されており、このコンピュータ１００には、システム・ユニット１１０、ビデオ・ディスプレイ端末１０２、キーボード１０４、フロッピ・ドライブおよび他のタイプのパーマネント・ストレージ・メディアおよび取外し可能ストレージ・メディアを含めることができるストレージ・デバイス１０８、およびマウス１０６が含まれる。たとえば、ジョイスティック、タッチパッド、タッチ・スクリーン、トラックボール、マイクロフォン、および類似物などの追加の入力装置を、コンピュータ１００に含めることができる。コンピュータ１００は、米国ＩＢＭ社の製品である、ＩＢＭ ＲＳ／６０００コンピュータまたはＩｎｔｅｌｌｉＳｔａｔｉｏｎコンピュータなどの、適当なコンピュータを使用して実施することができる。図の表現では、コンピュータが示されているが、本発明の他の実施形態を、ネットワーク・コンピュータなどの他のタイプのデータ処理システムで実施することができる。コンピュータ１００には、コンピュータ１００内で動作する、コンピュータ可読媒体に常駐するシステム・ソフトウェアによって実施することができる、グラフィカル・ユーザ・インターフェースも含まれることが好ましい。
【００１７】
図２を参照すると、本発明を実施することができるデータ処理システムのブロック図が示されている。データ処理システム２００は、図１のコンピュータ１００など、本発明の処理を実施するコードまたは命令を配置することができるコンピュータの例である。データ処理システム２００では、ＰＣＩローカル・バス・アーキテクチャが使用される。図示の例では、ＰＣＩバスが使用されるが、ＡＧＰおよびＩＳＡなどの他のバス・アーキテクチャを使用することができる。プロセッサ２０２および主記憶２０４が、ＰＣＩブリッジ２０８を介してＰＣＩローカル・バス２０６に接続される。ＰＣＩブリッジ２０８には、プロセッサ２０２用の統合されたメモリ・コントローラおよびキャッシュ・メモリも含めることができる。ＰＣＩローカル・バス２０６への追加の接続を、直接構成要素相互接続（ｄｉｒｅｃｔ ｃｏｍｐｏｎｅｎｔ ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）またはアドイン・ボードを介して行うことができる。図示の例では、ＬＡＮアダプタ２１０、ＳＣＳＩホスト・バス・アダプタ２１２、および拡張バス・インターフェース２１４が、直接構成要素接続によってＰＣＩローカル・バス２０６に接続される。対照的に、オーディオ・アダプタ２１６およびグラフィックス・アダプタ２１８は、拡張スロットに挿入されるアドイン・ボードによってＰＣＩローカル・バス２０６に接続される。拡張バス・インターフェース２１４は、キーボードおよびマウス・アダプタ２２０、モデム２２２、および追加メモリ２２４の接続を提供する。ＳＣＳＩホスト・バス・アダプタ２１２は、ハード・ディスク・ドライブ２２６、テープ・ドライブ２２８、およびＣＤ−ＲＯＭドライブ２３０の接続を提供する。通常のＰＣＩローカル・バス実施形態では、３つまたは４つのＰＣＩ拡張スロットまたはアドイン・コネクタがサポートされる。
【００１８】
オペレーティング・システムが、プロセッサ２０２上で稼動し、図２のデータ処理システム２００内のさまざまな構成要素を調整し、制御を提供するのに使用される。オペレーティング・システムは、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ社が市販するＷｉｎｄｏｗｓ（Ｒ）２０００などの商業的に入手可能なオペレーティング・システムとすることができる。Ｊａｖａ（Ｒ）などのオブジェクト指向プログラミング・システムが、オペレーティング・システムと共に稼動することができ、データ処理システム２００上で実行されるＪａｖａ（Ｒ）プログラムまたはＪａｖａ（Ｒ）アプリケーションからオペレーティング・システムへの呼出しを提供する。「Ｊａｖａ（Ｒ）」は、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．社の商標である。オペレーティング・システム、オブジェクト指向オペレーティング・システム、およびアプリケーションまたはプログラムの命令は、ハード・ディスク・ドライブ２２６などのストレージ・デバイスに配置され、プロセッサ２０２による実行のために主記憶２０４にロードされることができる。具体的に言うと、本発明は、グラフィックス・アダプタ２１８などのグラフィックス・アダプタにグラフィックス・データを送る異なるプロセスのコンテキストを動的に切り替える機構を提供する。この長所は、グラフィックス・アダプタ２１８を共用する異なるプロセスのコンテキストを格納するためのメモリの割振りの使用を介して提供される。
【００１９】
当業者は、図２のハードウェアを、実施形態に応じて変更できることを諒解するであろう。フラッシュＲＯＭ（または同等の不揮発性メモリ）または光ディスク・ドライブおよび類似物などの他の内部ハードウェアまたは周辺装置を、図２に示されたハードウェアに追加して、またはその代わりに使用することができる。また、本発明の処理は、マルチプロセッサ・データ処理システムに適用することができる。
【００２０】
たとえば、データ処理システム２００は、任意選択としてネットワーク・コンピュータとして構成される場合に、任意選択の包含を示す図２の破線２３２によって示されるように、ＳＣＳＩホスト・バス・アダプタ２１２、ハード・ディスク・ドライブ２２６、テープ・ドライブ２２８、およびＣＤ−ＲＯＭドライブ２３０を含まないものとすることができる。その場合には、コンピュータ（正しくはクライアント・コンピュータと呼ばれる）に、ＬＡＮアダプタ２１０、モデム２２２、または類似物など、あるタイプのネットワーク通信インターフェースが含まれなければならない。もう１つの例として、データ処理システム２００は、データ処理システムにあるタイプのネットワーク通信インターフェースが含まれるかどうかに無関係に、あるタイプのネットワーク通信インターフェースに頼らずにブート可能になるように構成された独立型システムとすることができる。もう１つの例として、データ処理システム２００を、オペレーティング・システム・ファイルまたはユーザ生成データあるいはその両方の格納用の不揮発性メモリを提供するためにＲＯＭまたはフラッシュＲＯＭあるいはその両方を用いて構成される携帯情報端末（ＰＤＡ）とすることができる。
【００２１】
図２に示された例および上述した例は、アーキテクチャ的制限を暗示することを意図されてはいない。たとえば、データ処理システム２００を、ＰＤＡの形態をとるほかに、ノートブック・コンピュータまたはハンド・ヘルド・コンピュータとすることもできる。データ処理システム２００を、キオスクまたはウェブ機器とすることもできる。
【００２２】
本発明の処理は、たとえば主記憶２０４、追加メモリ２２４、あるいは１つまたは複数のハード・ディスク・ドライブ２２６、テープ・ドライブ２２８、およびＣＤ−ＲＯＭドライブ２３０などのメモリに配置することができるコンピュータに実施される命令を使用して、プロセッサ２０２によって実行される。
【００２３】
本発明は、複数のグラフィックス・プロセスが同一のグラフィックス・アダプタを共用する、マルチタスキング・グラフィックス環境での機構を提供する。たとえば図２の主記憶２０４などのデータ処理システム内のメモリの一部が、コンテキスト切替に使用するために割り振られる。これらの例では、メモリ割振りが、固定バッファの形である。固定バッファとは、ディスク空間が最近使用されていない情報に関する拡張メモリとして使用される仮想記憶コンピュータ・システムの場合などのように、ディスクにスワップ・アウトされないバッファである。固定バッファまたは他の固定メモリを使用することによって、デバイス・ドライバが、情報をディスク・ドライブからスワップ・インする必要なしに、メモリ内で情報にすばやくアクセスできるようになる。
【００２４】
グラフィックス・プロセスは、この固定バッファにアクセスして、ある事前定義の機能またはアクションが必要であるかどうかを指定することができる。これらの機能には、たとえば、テクスチャ・マッピングおよびカラー・ルックアップが含まれる。他の機能には、たとえば、デプス・バッファ・テスティングに関する情報、ハードウェア・ライティング、テクスチャ・マッピングの変形であるバンプマッピング、およびアンチエイリアス動作が含まれる。
【００２５】
コンテキスト切替が発生する時に、コンテキスト切替機構が、固定バッファを読み取って、全コンテキスト切替が必要であるか、部分コンテキスト切替が必要であるかを判断する。コンテキストは、１つの時点で指定される情報またはパラメータである。この情報は、コマンドの時点で動作を実行するために再び述べるか再指定しなくてもよいが、コマンドの動作に必ず影響する。たとえば、あるプログラムを、色がコンテキストである場合に、緑の色を使用して線の組を描画するのに使用することができる。第２のプログラムを、赤の色を使用して線の第２の組を描画するのに使用することができる。第１のプログラムが稼動する時に、色に緑がセットされる。プログラム１が線の描画を終了する前に割込みが発生し、プログラム２が稼動を開始する。プログラム２は、色に赤をセットし、線の描画を開始する。第２の割込みが発生し、プログラム１が実行を再開する。この時に、色には赤がセットされている。プログラム１は、線を描画するたびに色をリセットすることはしない。その結果、この場合には線の色であるコンテキストが、プログラム１に関して緑にリセットされない場合に、線が誤った色で描画される。この例では、デバイス・ドライバを使用して、コンテキストを緑に復元する。この形で、プログラムが、コンテキスト情報を追跡する必要がなくなる。
【００２６】
この情報は、グラフィックス・アダプタ内のメモリを割り振るのに使用する必要があるグラフィックス・コンテキストのサイズを判断するのに使用されることもできる。コンテキストとみなされる他の情報には、たとえば、照明またはクリッピングがイネーブルされているかどうか、プリミティブが線描されるか塗り潰されるか、現在の線の点刻パターン、および現在のテクスチャ・ブレンディング関数が含まれる。
【００２７】
図３すなわち、本発明の好ましい実施形態による、動的コンテキスト切替に使用される構成要素を示すブロック図に移る。この例では、アプリケーション３００、３０２、および３０４が、マルチタスキング・グラフィックス環境内にあり、図２のグラフィックス・アダプタ２１８などの単一のグラフィックス・アダプタを共用する。図からわかるように、各アプリケーションに、表示用のグラフィックス・データを生成するグラフィックス・プロセスが含まれる。もちろん、特定のアプリケーションに依存して、１つのアプリケーションが複数のグラフィックス・プロセスを含むことができる。これらのアプリケーションは、オペレーティング・システム３０８内のデバイス・ドライバ３０６にグラフィックス・データを送る。デバイス・ドライバは、グラフィックス・アダプタ２１８などの周辺装置をオペレーティング・システムにリンクするプログラムまたはルーチンである。特定のデバイス・ドライバが、アプリケーション３００、３０２、および３０４からの要求およびデータなどの要求およびデータを受け取り、これらの要求を、周辺装置によって認識される特定のコマンド言語およびフォーマットに変換する。
【００２８】
この例では、アプリケーション３００、３０２、および３０４が、バッファ３１０にアクセスして、コンテキスト情報を書き込み、変更することができる。コンテキスト情報は、この例では ｃｏｍ＿ｒｅｃｏｒｄ ３１２の形をとる。これらのアプリケーションの１つが、グラフィックス・アダプタでの表示のためにデバイス・ドライバ３０６にグラフィックス・データを送る時に、デバイス・ドライバ３０６は、バッファ３１０内の ｃｏｍ＿ｒｅｃｏｒｄ ３１２を見て、コンテキスト切替が必要であるかどうかを調べる。コンテキスト切替が必要な場合には、デバイス・ドライバ３０６は、部分的コンテキスト切替と全コンテキスト切替のどちらが必要であるかを判断することもできる。この判定に基づいて、デバイス・ドライバ３０６は、グラフィックス・アダプタ内のコンテキストを選択的に切り替える。コンテキストの切替の一部として、デバイス・ドライバ３０６は、グラフィックス・アダプタ内のメモリの、コンテキストに関する割振りを動的に変更するために、グラフィックス・コンテキストのサイズを変更することもできる。この形で、特定のコンテキストについてより少ないメモリが必要である時に、より多くのメモリが、他の使用のためにグラフィックス・アダプタ内で使用可能にされる。デバイス・ドライバは、グラフィックス・アダプタなど、ハードウェアのそれぞれについて存在する。デバイス・ドライバは、潜在的なコンテキスト情報を意識し、通常は、すべてのコンテキスト情報を保管する。特定のコンテキストに必要なメモリの量は、デバイスドライバから、またはグラフィックス・アダプタのためにデバイス・ドライバによって保管された情報から得ることができる。
【００２９】
これらの例では、フラグをセットして、コンテキストのうちでアクティブに使用される１つまたは複数の部分を識別する。デバイス・ドライバは、そのフラグを使用して、保管する必要があるコンテキストと保管する必要がないコンテキストを識別する。
【００３０】
図４を参照すると、本発明の好ましい実施形態による１つの ｃｏｍ＿ｒｅｃｏｒｄ を示す図が示されている。 ｃｏｍ＿ｒｅｃｏｒｄ ４００は、特定のプロセスについてどのコンテキスト情報が使用されているかを識別するために使用される。 ｃｏｍ＿ｒｅｃｏｒｄ ４００を使用することによって、本発明の機構は、新しいプロセスが処理のためにグラフィックス・データを送っている時に、全コンテキスト切替が必要であるかどうかを判定できるようになる。
【００３１】
この例の ｃｏｍ＿ｒｅｃｏｒｄ ４００には、 ｃｏｍ＿ｒｅｃｏｒｄ ４００に関連するプロセスについてテクスチャ機能およびルックアップ機能がセットされていることの識別が含まれる。この例では、各プロセスに ｃｏｍ＿ｒｅｃｏｒｄ が関連する。 ｃｏｍ＿ｒｅｃｏｒｄ ４００は、コンテキスト情報の数行の例である。これらの行は、特定のプロセスによって現在使用されているコンテキストを識別するインジケータまたはフラグである。コンテキストには、通常は、コンテキストを識別する数百個の要素が含まれる。コンテキストを作成する際に、プロセスは、コンテキストを開始する時にそのコンテキストを作成する。グラフィックス・プロセスは、ＡＰＩ呼出しを行って、１つまたは複数のグラフィックス・コンテキストを作成する。特定のコンテキストをアクティブにする時に、グラフィックス・プロセスは、ＡＰＩ呼出しを使用して、特定のコンテキストをウィンドウに関連付ける。この形で、グラフィックス・プロセス、コンテキスト、およびウィンドウの間に関係が存在する。コンテキストは、デバイス・ドライバによって供給される一意の識別子を介して識別される。この一意の識別子は、コンテキストを作成するのに使用されるＡＰＩ呼出しを介してアプリケーションに与えられる。この一意の識別子は、 ｃｏｍ＿ｒｅｃｏｒｄ ４００に格納される。この形で、デバイス・ドライバが、各コンテキストの一意の識別子と、アクティブに使用されるコンテキストの部分に関するＡＰＩによって供給される情報との間の一意の対を有する。
【００３２】
ＡＰＩによって、共用メモリ内で ｃｏｍ＿ｒｅｃｏｒｄ ４００が作成され、デバイス・ドライバに、 ｃｏｍ＿ｒｅｃｏｒｄ ４００が共用メモリのどこに配置されたかが、デバイス・ドライバへの正確に１回の呼出しを介して伝えられる。その後、デバイス・ドライバは、共用メモリを調べて、コンテキスト切替に関する判断を行う。この情報が変更される場合には、アプリケーションが、共用メモリを更新する。たとえば、アプリケーションが開始され、アプリケーションが共用メモリを初期化して、 ｕｓｉｎｇ＿ｔｅｘｔｕｒｅ が偽であり、 ｕｓｉｎｇ＿ｌｏｏｋｕｐ が偽であるようにする。次に、アプリケーションはデバイス・ドライバを呼び出して、共用メモリがどこにあるかとその共用メモリが使用の準備ができていることを伝える。その後、デバイス・ドライバが、コンテキスト切替を行う。デバイス・ドライバは、コンテキストを保管する時に、 ｕｓｉｎｇ＿ｔｅｘｔｕｒｅ が偽であったことを知り、したがって、デバイス・ドライバはテクスチャ情報を保管しない。デバイス・ドライバは ｕｓｉｎｇ＿ｌｏｏｋｕｐ が偽であることを知り、したがって、ルックアップ情報を保管しない。デバイス・ドライバがこのプロセスをアクティブ・モードに切り替える時には、デバイス・ドライバは ｕｓｉｎｇ＿ｔｅｘｔｕｒｅ が偽であることを知り、したがって、デバイス・ドライバはテクスチャ情報を復元しない。デバイス・ドライバは ｕｓｉｎｇ＿ｌｏｏｋｕｐ が偽であったことを知り、したがって、デバイス・ドライバは、ルックアップ・テーブル情報を復元しない。アプリケーションが、テクスチャ・ルックアップの使用を開始する。アプリケーションは、共用メモリの「ｕｓｉｎｇ＿ｌｏｏｋｕｐ」と呼ばれる部分に真を書き込む。デバイス・ドライバが、このコンテキストをオフに切り替える。デバイス・ドライバは共用メモリの ｃｏｍ＿ｒｅｃｏｒｄ を調べ、 ｕｓｉｎｇ＿ｔｅｘｔｕｒｅ が偽であることを知り、したがって、テクスチャ情報を保管しない。デバイス・ドライバは ｕｓｉｎｇ＿ｌｏｏｋｕｐ が真であることを知り、したがって、デバイス・ドライバはルックアップ情報を保管する。その後、デバイス・ドライバがこのコンテキストをオンに切り替える。デバイス・ドライバは共用メモリの ｃｏｍ＿ｒｅｃｏｒｄ を調べ、 ｕｓｉｎｇ＿ｔｅｘｔｕｒｅ が偽であることを知り、したがって、デバイス・ドライバはテクスチャ情報を復元しない。デバイス・ドライバは、 ｕｓｉｎｇ＿ｌｏｏｋｕｐ が真であることを知り、したがって、デバイス・ドライバはルックアップ情報を復元する。
【００３３】
図５を参照すると、本発明の好ましい実施形態によるコンテキストの確立の流れ図が示されている。図５に示された処理は、図３のアプリケーション３００、３０２、または３０４などのアプリケーションによって使用される処理の例である。
【００３４】
この処理は、レコードの作成によって開始される（ステップ５００）。この例では、レコードが、図４の ｃｏｍ＿ｒｅｃｏｒｄ ４００などの ｃｏｍ＿ｒｅｃｏｒｄ の形をとる。もちろん、レコードは、テーブル内の項目またはデータベース内のレコードなど、さまざまな形をとることができる。事前定義の機能が、レコードにセットされる（ステップ５０２）。図示の例では、これらの機能に、テクスチャ機能およびルックアップ機能が含まれる。ベース・コンテキストをセット・アップする際に、デバイス・ドライバはコンテキストを作成する呼出しを受け取り、デフォルト値またはデフォルト機能を使用してベース・コンテキストをセット・アップする。たとえば、デフォルトの線の色を、ベース・コンテキストに設けることができる。コンテキストとウィンドウの間のペアリングが行われる時に、幅、高さ、およびウィンドウ・タイプなどの追加情報がコンテキストに追加される。この情報は、特定のプロセスに関連するコンテキスト・レコードに追加される。
【００３５】
その後、グラフィックス動作がグラフィックス・アプリケーションまたはグラフィックス・プロセスによって実行され（ステップ５４０）、その後、処理が終了する。グラフィックス・アプリケーションまたはグラフィックス・プロセスは、デバイス・ドライバによって作成されたコンテキストをアプリケーションが要求するたびに一意のレコードを作成する。この情報は、コンテキストが破棄されるか、プロセスが終了するまで存在する。
【００３６】
図６に移ると、本発明の好ましい実施形態によるコンテキスト切替の流れ図が示されている。図６に示された処理は、図３のデバイス・ドライバ３０６などのデバイス・ドライバ内で実施することができる。もちろん、この処理を、実施形態に応じてほかのところで実施することができる。たとえば、この処理を、グラフィックス・カーネル内で実施することができる。
【００３７】
イベントのシーケンスは、グラフィックス・データをグラフィックス・アダプタに送る、プロセスからの要求を受け取ることによって開始される（ステップ６００）。現在のコンテキストが、その要求を行うプロセスについて正しいかどうかに関する判定を行う（ステップ６０２）。現在のコンテキストが正しくない場合には、プロセスに関連するレコードを識別する（ステップ６０４）。この例では、レコードが、固定バッファ内に配置された ｃｏｍ＿ｒｅｃｏｒｄ である。
【００３８】
次に、全コンテキスト切替が必要であるかどうかに関する判定を行う（ステップ６０６）。全コンテキスト切替が必要である場合には、現在のコンテキストを保管し（ステップ６０８）、プロセスに必要なコンテキストを復元するか、使用に適当な位置に配置する（ステップ６１０）。要求内のグラフィックス・データまたはコマンドあるいはその両方をアダプタに送り（ステップ６１２）、その後、フローが終了する。
【００３９】
ステップ６０６をもう一度参照すると、全コンテキスト切替が必要でない場合には、現在のコンテキストを保管する（ステップ６１４）。ステップ６１４では、現在のコンテキストのうちで変更される部分だけが保管される。その後、プロセスについて識別されたコンテキストの部分を復元し（ステップ６１６）、その後、フローは、上で説明したステップ６１２に進む。言い換えると、変更される必要があるコンテキスト情報が、検索され、現在のコンテキストに配置されて、現在のコンテキストが修正される。ステップ６０２に戻ると、グラフィックス・アダプタ内の現在のコンテキストが、要求を送るプロセスに関して正しい場合には、フローは、上で説明したステップ６１２に進む。
【００４０】
図７に進むと、本発明の好ましい実施形態によるコンテキスト情報を保管する処理の流れ図が示されている。この処理はコンテキスト切替中に使用され、図３のデバイス・ドライバ３０６などのデバイス・ドライバ内で実施される。
【００４１】
この処理は、プロセスのコンテキストに関連するレコードにベース・コンテキスト情報を保管することによって開始される（ステップ７００）。テクスチャがコンテキスト内でセットされたかどうかに関する判定を行う（ステップ７０２）。テクスチャがセットされた場合には、テクスチャ情報をレコードに保管する（ステップ７０４）。次に、ルックアップ機能がコンテキスト内でセットされたかどうかに関する判定を行う（ステップ７０６）。ルックアップがセットされた場合にはルックアップ情報を保管し（ステップ７０８）、その後、処理が終了する。これらの機能のどちらもセットされていない場合には、処理は、ベース・コンテキスト情報だけを保管して終了する。この例では、２タイプのコンテキスト機能だけが例示のために示される。可能な異なるタイプのコンテキストに応じて、これらのコンテキストのすべてがレコードに保管される。
【００４２】
図８を参照すると、本発明の好ましい実施形態による、プロセスのコンテキストの復元の流れ図が示されている。この処理は、ベース・コンテキストを復元することによって開始される（ステップ８００）。ベース・コンテキストは、プロセスに関連するレコード内の情報を使用して、グラフィックス・アダプタ内で復元される。ベース・コンテキストには、グラフィックス・プロセスのコンテキストをセット・アップするためにデバイス・ドライバが呼び出された時にデバイス・ドライバによって行われたデフォルト設定が含まれる。テクスチャ機能がレコード内でセットされているかどうかに関する判定を行う（ステップ８０２）。テクスチャ機能がセットされている場合には、レコード内の情報を使用して、この機能のテクスチャ情報をグラフィックス・アダプタ内で復元する（ステップ８０４）。
【００４３】
次に、ルックアップ機能がレコード内でセットされているかどうかに関する判定を行う（ステップ８０６）。ルックアップ機能がセットされている場合には、レコードを使用してグラフィックス・アダプタ内でルックアップ情報を復元し（ステップ８０８）、その後、処理が終了する。ステップ８０２で、テクスチャ機能がセットされていない場合には、処理は上で説明したステップ８０６に進む。ステップ８０８で、ルックアップ機能がセットされていない場合には、処理が終了する。この図には、ベース・コンテキスト情報のほかに２つの特定の機能に関するコンテキスト情報の復元だけが示されているが、本発明の機能は、レコード内で指定されるすべての機能についてコンテキストを復元する。
【００４４】
図７および図８に示されたステップは、全コンテキストならびに部分コンテキストの保管および復元の両方に適用可能である。選択されたコンテキストに関連する ｃｏｍ＿ｒｅｃｏｒｄ で、コンテキストの要素のすべてが使用されないことが示される場合には、部分保管が行われる。たとえば、図４の例で ｕｓｉｎｇ＿ｔｅｘｔｕｒｅ および ｕｓｉｎｇ＿ｌｏｏｋｕｐ の両方がセットされない場合には、部分コンテキスト保管が行われる。同様に、コンテキスト情報の復元に関して、コンテキストの一部が使用されない場合に、全コンテキスト復元動作が必要でない場合がある。この機構は、図７および８のステップ７０２、７０６、８０２、および８０６に反映されている。
【００４５】
ある量のスペースがコンテキスト変更に必要な時に、新しいスペースを割り振るためにコンテキストのサイズを変更することもできる。
【００４６】
したがって、本発明は、複数のグラフィックス・プロセスが同一のグラフィックス・アダプタを共用することを可能にする、グラフィックス環境で使用される機構を提供する。この機構は、グラフィックス・アダプタ内で使用されるメモリの量をグラフィックス・プロセスの特定のコンテキストに基づいてリセットすることができるコンテキスト切替を可能にする。さらに、部分コンテキスト切替が必要な場合に、必要な情報だけがグラフィックス・アダプタ内に復元される。全コンテキスト変更ではなく部分コンテキスト変更が行われる場合によって、性能向上が実現される。保管し復元する必要がある情報が減るため、時間が節約される。
【００４７】
本発明を完全に機能するデータ処理システムのコンテキストに関して説明してきたが、本発明の処理を、命令のコンピュータ可読媒体およびさまざまな形態で配布することができること、本発明が配布の実行に実際に使用される信号担持媒体の特定のタイプに無関係に同等に適用されることを当業者が諒解するであろうことに留意することは重要である。コンピュータ可読媒体の例には、フロッピ・ディスク、ハード・ディスク・ドライブ、ＲＡＭ、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭなどの記録可能型媒体と、ディジタル通信リンク、アナログ通信リンク、有線通信リンク、または、たとえばラジオ周波数および光波伝送などの伝送形態を使用する無線通信リンクなどの伝送型媒体が含まれる。コンピュータ可読媒体は、特定のデータ処理システムでの実際の使用のためにデコードされるコード化されたフォーマットの形をとることができる。
【図面の簡単な説明】
【図１】
本発明の好ましい実施形態に従って本発明を実施することができるデータ処理システムの絵図である。
【図２】
本発明を実施することができるデータ処理システムのブロック図である。
【図３】
本発明の好ましい実施形態による、動的コンテキスト切替に使用される構成要素を示すブロック図である。
【図４】
本発明の好ましい実施形態による ｃｏｍ＿ｒｅｃｏｒｄ を示す図である。
【図５】
本発明の好ましい実施形態によるコンテキストの確立の流れ図である。
【図６】
本発明の好ましい実施形態によるコンテキスト切替の処理の流れ図である。
【図７】
本発明の好ましい実施形態によるコンテキスト情報保管の流れ図である。
【図８】
本発明の好ましい実施形態による、プロセスのコンテキストの復元の流れ図である。
【図１】
2004505355.tif 000003
【図２】
2004505355.tif 000004
【図３】
2004505355.tif 000005
【図４】
2004505355.tif 000006
【図５】
2004505355.tif 000007
【図６】
2004505355.tif 000008
【図７】
2004505355.tif 000009
【図８】
2004505355.tif 000010
【国際公開パンフレット】
2004505355.tif 000011
2004505355.tif 000012
2004505355.tif 000013
2004505355.tif 000014
2004505355.tif 000015
2004505355.tif 000016
2004505355.tif 000017
2004505355.tif 000018
2004505355.tif 000019
2004505355.tif 000020
2004505355.tif 000021
2004505355.tif 000022
2004505355.tif 000023
2004505355.tif 000024
2004505355.tif 000025
2004505355.tif 000026
2004505355.tif 000027
2004505355.tif 000028
2004505355.tif 000029
2004505355.tif 000030
2004505355.tif 000031
2004505355.tif 000032
2004505355.tif 000033
2004505355.tif 000034
【国際公開パンフレット（コレクトバージョン）】
2004505355.tif 000035
2004505355.tif 000036
【国際調査報告】
2004505355.tif 000037
2004505355.tif 000038