JP2662168B2

JP2662168B2 - グラフィックス・システム・レンダリング・コンテキスト・データを管理するシステム及び方法

Info

Publication number: JP2662168B2
Application number: JP5206701A
Authority: JP
Inventors: デイビッド・シー・タネンポーム; ポール・エム・シャネリー; ブルース・シー・ヘンペル
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1992-10-29
Filing date: 1993-08-20
Publication date: 1997-10-08
Anticipated expiration: 2012-10-08
Also published as: EP0595066A3; JPH07141202A; EP0595066A2; US5430841A

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明はコンピュータ・グラフィ
ックス・システム、詳しくは多数のコンテキストを必要
とするコンピュータ・グラフィックス・システムおいて
それらコンテキストを管理する方法及び装置に関するも
のである。

【０００２】更に詳しくいえば、本発明は1つ又は複数
のグラフィックス・コンテキストを中央ノードに蓄積
し、コンテキスト保管のためにそれを読み出し、コンテ
キスト復元のためにそれを書き戻すための方法及び装置
に関するものである。なお、前記中央ノードはコンテキ
スト復元情報の供給に必要なすべての動作を処理する。

【０００３】

【従来の技術】高品位の3次元グラフィックス・イメー
ジを発生させるために及びウィンドウ環境で2次元表示
のアプリケーション・プログラムを走らせるために、コ
ンピュータ・グラフィックス・ワークステーションが広
く使用されている。ウィンドウ環境は表示装置がいくつ
かのアプリケーションからの出力を単一の図形出力媒体
上に表示し得るようにするために使われる。典型的に
は、1つのアプリケーションの出力表示がウィンドウ環
境では1つ又は複数の2次元「ウィンドウズ」で与えられ
る。ウィンドウの特性及びパラメータを定義するために
各ウィンドウに1つの固有のコンテキストを関連付け可
能である。コンテキストとウィンドウとの間の1対1の対
応は必ずしも必要でないが、そのような対応が一般的で
ある。

【０００４】今やコンピュータ・グラフィックス・シス
テムは益々多数のコンテキストをサポートしようとして
いる。例えば、或るグラフィックス・システムは1つの
ウィンドウ内で開発中の機械部品の高品位レンダリング
を行うことがある。別のウィンドウでは、設計者が機械
部品の特性を変更したり、それに関する質問を行なった
りできる対話式処理があってもよい。また、或るウィン
ドウでは、クロックがあってもよく、他のウィンドウで
は、オフィス間のメール・アプリケーションが走ってい
てもよい。マルチウィンドウ・セッションの1つの例が
図1に示される。MITにより開発されたX−ウィンドウ・
システムは周知のウィンドウ・システムの1例である。

【０００５】本発明は複数コンテキストに関連したグラ
フィックス・データ、即ち複数のウィンドウをサポート
するグラフィックス・システムに関連したデータの管理
に関するものである。本明細書で使用される「コンテキ
スト」という用語はレンダリング・プロセス、即ち表示
可能なイメージを発生するプロセスを制御するためにグ
ラフィックス・システムにより使用されるデータを指
す。

【０００６】本発明を実施するようなコンピュータ・グ
ラフィックス・システムにおけるコンテキストは2つの
部分、即ちフロントエンド・ジオメトリ・プロセッサ・
サブシステムにより使用される第1部分とラスタリゼー
ション・サブシステムにより使用される第2部分とより
成る。

【０００７】通常の描画動作中フロントエンド・ジオメ
トリ・プロセッサ・サブシステムはグラフィック・オー
ダ即ち図形描画オーダを受け取り、そして現在の色、線
形状パターン、ウィンドウ・オフセット等を含む描画環
境の種々のアトリビュートを表わす情報をラスタリゼー
ション・サブシステムに送る。「現在のコンテキスト」
の状態は定義されたウィンドウにおける表示可能なオブ
ジェクトをレンダするために、ジオメトリ・サブシステ
ム及びラスタリゼーション・サブシステムが必要とする
すべての情報を含む。本発明はコンテキストの第2部分
即ちラスタリゼーションに特有の部分の管理を行う。

【０００８】複数のコンテキストをサポートし、それら
を素早くスイッチしなければならないグラフィックス・
システムでは、コンテキストがスワップされる時にいつ
も保管されそして復元されるべき大量のデータがある。
過去においては、その後の復元のために目下有効なコン
テキストの上記第2部分を保管することはせず、むしろ
それを廃棄し、そして新しいコンテキストはいずれも完
全な再生を必要とした。即ちそれはラスタリゼーション
・サブシステムのコマンドを生じさせるためにコンテキ
ストの再変換処理を必要とした。

【０００９】この従来方法の欠点はラスタリゼーション
・サブシステムにより使用されたコンテキストのすべて
のデータをパイプラインの先端で復元する必要があるこ
とであり、従って処理を必要とすることである。一般に
は、グラフィックス・サブシステムは多数の連結された
プロセッサを使ってプロセッサ・パイプラインを形成す
る。そのパイプラインの第1(先端の)プロセッサはタス
クを解釈して低レベルのプロセッサに与えることによっ
てそれら低レベルのプロセッサの仕事を管理することが
多い。一般に、ラスタリゼーション・プロセッサにより
使用されるデータはパイプラインの先端におけるデータ
とは異なるフォーマットであることが多いので、ラスタ
リゼーション・サブシステムによる使用のためにそのデ
ータを適当なフォーマットに変換するためには、大量の
パイプライン・プロセッサ時間を費やさなければならな
い。この時間中フロントエンド・サブシステムはそれ自
身の処理に関するコンテキストの部分を復元できない。
更に、グラフィックス・パイプラインの潜在時間に関連
した遅れはパイプラインによりコンテキストを復元する
時に惹起される。

【００１０】

【発明が解決しようとする課題】従って、本発明の目的
はコンピュータ・グラフィックス・システムにおいて複
数のグラフィックス・コンテキストに関連したデータを
管理するための方法及び装置を提供することにある。

【００１１】本発明のもう1つの目的はコンピュータ・
グラフィックス・システムにおける複数のグラフィック
ス・コンテキストに関連したデータがそのグラフィック
ス・システム内にある特別のコンテキスト保管RAMに保
管されるようなグラフィックス・システムにおいてその
データを管理するための方法及び装置を提供することに
ある。

【００１２】本発明の更にもう1つの目的はグラフィッ
クス・コンテキスト・データの選択的保管及び復元のた
めの手段を提供すると共に、コンピュータ・グラフィッ
クス・システムにおける複数のグラフィックス・コンテ
キストに関連したデータを管理するための方法及び装置
を提供することにある。

【００１３】本発明の更にもう1つの目的はグラフィッ
クス・コンテキストが複数のジオメトリ・エンジンのデ
ータ出力の結果であり且つグラフィックス・コンテキス
トが下流のラスタ・エンジンに対して自動的に再生され
るようなコンピュータ・グラフィックス・システムにお
いて複数のグラフィックス・コンテキストに関連したデ
ータを管理するための方法及び装置を提供することにあ
る。

【００１４】本発明はグラフィックス・システムの現在
の状態(コンテキストの上記第2部分)をこの情報がダイ
レクト・メモリ・アクセス(DMA)転送を介してメモリ領
域に直接に読み出されるようフロントエンド・ジオメト
リ・サブシステムによりラスタリゼーション・サブシス
テムにコマンドを送ることによってそれを形成時のまま
に保管するための手段を有する。

【００１５】コンテキスト・スイッチのとき、制御プロ
セッサはメモリ保管領域へのDMA転送のようにラスタ・
エンジンの現在の状態(保管されるべきコンテキスト)を
読み出すことができる。同時に、フロントエンド・ジオ
メトリ・サブシステムにおけるプロセッサはそれらの状
態をメモリ領域に保管する。ラスタ・エンジンの状態の
読み出しが終わったとき、1つの新しい状態(復元される
べきラスタ・コンテキスト)をラスタリゼーション・サ
ブシステムに直接送る。新しいコンテキスト・データは
レンダリング・パイプラインではなくDMAを介して送ら
れる。これと並行して、フロントエンド・プロセッサは
新しいジオメトリ・コンテキストをロードする。

【００１６】上述のように、コンテキスト・データがラ
スタリゼーション・サブシステムから読み出されまたそ
こに書き込まれるハード・コンテキスト・スイッチにつ
いて上に述べた。もう1つのコンテキスト管理動作が存
在し、それはソフト・コンテキスト・スイッチである。
これはコンテキスト・スワップ・アウト及びコンテキス
ト・スワップ・インの両方がラスタリゼーション・サブ
システムに存在するとき使用され、スワップを行うため
に必要なことはベース・レジスタにおける変更だけであ
る。ソフト・コンテキスト・スワップは実施例で詳しく
説明するように管理されるべきコンテキスト・データの
全量がラスタリゼーション・サブシステム内に保持可能
であるときに使用される。

【００１７】ラスタリゼーション・サブシステムから読
み出されるデータ及びそこに書き込まれるデータは同じ
フォーマットであり、従ってフロントエンド・ジオメト
リ・サブシステムによる処理は必要ない。好ましい実施
例では、ラスタリゼーション・サブシステムのためのコ
ンテキスト管理は制御プロセッサによりDMA動作が開始
されるためフロントエンド・ジオメトリ・サブシステム
による介入又は処理を必要としない。

【００１８】

【課題を解決するための手段】本発明は単一のDMA動作
でラスタリゼーション・サブシステムのコンテキスト全
体が読み出され(保管され)そして書き込まれる(他のコ
ンテキストが開始される)のを可能にする。従って、コ
ンテキスト・スワップは1対のDMA転送を開始させるため
に最小のCPU介入を必要とするだけである。更に、コマ
ンドOPコード・マップが設けられるので、コンテキスト
保管/復元に関連すると思われるコマンドだけを読み出
せばよい。各コンテキストに対して固有でないコマンド
及びラスタリゼーション・サブシステムの開始の時に1
回セットされるだけでよいコマンドはコンテキスト保管
/復元動作においてスキップ可能であり、それによって
コンテキストRAMスペース及びDMA処理時間を節約でき
る。

【００１９】コンテキスト保管RAMはラスタリゼーショ
ン・サブシステムにより使用されたコンテキストの一部
分ではないが1つのコンテキストにとって必要なデータ
を構成するデータも保持することができる。これはコン
テキスト保管RAMを「メールボックス」として利用する
機構を与えるものである。例えば、GLアプリケーション
・プログラム・インターフェイスは現ラスタ位置の概念
を定義する。このデータはラスタリゼーション・サブシ
ステムによって明示的には使用されないけれども、コン
テキストの一部分として保持される。その代わり、それ
はラスタリゼーション・サブシステムに送られたその後
の描画プリミティブを適切に位置づけるために、そして
アプリケーション・プログラムにより保持された現位置
に関する質問に答えるためにフロントエンド・ジオメト
リ・サブシステムによって使用される。

【００２０】更に、ラスタリゼーション・サブシステム
に蓄積されたコンテキストを読み出す能力は強力なデバ
ッギング及び診断援助を与える。問題点が見つかった
時、過去の受け取ったコマンドの流れを調べることによ
って状態を推論しようとすることなくラスタリゼーショ
ン・サブシステムの正確な現在の状態を読み出すことが
可能である。

【００２１】

【実施例】図面、特に図1を参照すると、グラフィック
ス・システムにおけるフロント・オブ・スクリーンで見
られるマルチウィンドウ・システムが示される。スクリ
ーン110は複数の同時に表示されたウィンドウ120、13
0、140及び150を含んでいる。これらウィンドウは種々
のデータを含み、コンピュータ・システムにおいて走っ
ている相異なるアプリケーションを表わし得るものであ
る。この例におけるウィンドウ120は複雑な3次元アプリ
ケーションを含み、ウィンドウ140はグラフィック・ア
プリケーションを含んでいる。ウィンドウ130には、テ
キスト・ダイアログがある。ウィンドウ150はクロック
を含む。スクリーン110は相対的なX及びY位置によりア
ドレスされる多数の画素に分けられる。好ましい実施例
では、このスクリーンは水平方向に1280個の画素及び垂
直方向に1024個の画素を含んでいる。各画素の色及び濃
度はグラフィックス・プロセッサにより制御される。

【００２２】本発明は複数のウィンドウに関連したラス
タリゼーション・サブシステム・コンテキストの管理に
関するものである。

【００２３】図2は本発明を使用し得るグラフィックス
・システムを概略的に示す。このシステムは単に例示の
ためのものであり、他のグラフィックス・システムも使
用可能である。ジオメトリ処理サブシステム220は幾何
学的な描画プリミティブを含む幾何学的データ及びX、
Y、Z座標系で表わされたデータ、ホスト・プロセッサ21
0から受け取った色データに応答し、それらデータに変
更を加える。ホスト・プロセッサ210はグラフィック・
アダプタにデータを供給し得る如何なるコンピュータ、
例えばRISCシステム/6000でもよい。

【００２４】ジオメトリ処理サブシステム220は頂点の
修正されたデータ・ストリームを作り、ラスタリゼーシ
ョン・サブシステム230に送る。ラスタリゼーション・
サブシステム230は頂点データ(位置、色及び他の属性)
に応答しレンダリングとして知られたプロセスで各画素
に対する値を発生する。例えば、2つの頂点は1本の線を
定義し、そしてラスタリゼーション・サブシステム230
はそれら頂点の間にある画素を発生(レンダ)する。この
プロセスは1つのグラフィックス・オーダを1つの表示可
能な画素イメージに変換する。ラスタリゼーション・サ
ブシステム230はそのレンダされた画素データをフレー
ム・バッファ240内に貯蔵する。フレーム・バッファ240
はスクリーン・コントローラ250に接続されており、そ
のコントローラ250はフレーム・バッファ240から走査出
力された画素データに応答する。スクリーン・コントロ
ーラ250にはCRTモニタ260が接続されている。

【００２５】この好ましい実施例には、フレーム・バッ
ファ、スクリーン・コントローラ、CRTモニタが存在す
るものとして示されているが、これは説明の便宜上示し
たものであって本発明の実施例にとって必要条件ではな
い。

【００２６】図3を参照すると、好ましい実施例に従っ
てコンピュータ・グラフィックス・システムを更に詳細
に表わしたものが示される。フロントエンド・ジオメト
リ・サブシステム220はインターフェース装置330を介し
てホスト・プロセッサ210に接続される。フロントエン
ド・ジオメトリ・サブシステム・プロセッサ340(それら
の内の1つ又は複数)はマルチプレクサ装置350によってB
LT装置360に接続される。マルチプレクサ装置350の機能
そのものは本発明に関連するものではない。必要なこと
はそれが1つ又は複数のプロセッサのデータを1つの共通
バス上にマージするための手段であるということであり
当業者には明らかであろう。

【００２７】図3の説明を続けると、本発明の好ましい
実施例によれば、BLT装置360はビット・ブロック転送コ
マンドの前処理を行うものであり、ラスタライザ370に
双方向接続される。ラスタライザ370は実施例によって
は1つ又は複数のラスタライザ装置より成るものでよ
い。ラスタライザ370はフレーム・バッファ240に双方向
接続される。フレーム・バッファ240は陰極線管(CRT)26
0のためのアナログ信号を発生するランダム・アクセス
・メモリのディジタル・アナログ変換器(RAM DAC)250
を駆動する。これら素子370、240、250、260の性質が本
発明に直接関連するものではないことそしてそれらの形
式的な変更が本明細書の精神及び範囲を限定するもので
ないことは当業者には明らかであろう。

【００２８】制御プロセッサ310はコンテキスト保管及
び復元のようなシステム・サービスを与えるための制御
機構として作用する。制御プロセッサ310はそのシステ
ムの残りのものとバス320を介して通信する。制御プロ
セッサ310は汎用のプロセッサであり、好ましい実施例
で割り当てられたタスクに対して独特の或いは特殊のも
のではない。制御プロセッサ310は1つのプロセッサ及び
いくつかのローカル・プロセッサ記憶装置より成る。制
御プロセッサ310及びジオメトリ・サブシステム220は物
理的に分離している必要はなく、そして1つ又は複数の
プロセッサによって実行されるものでよい。

【００２９】図4を参照すると、BLT装置360内に存在す
る本発明の好ましい実施例が示される。この図において
ボックス410、420、430はそれぞれランダムアクセス・
メモリであり、読み取り/書き込みアドレスが左から供
給され、書き込みデータが上から供給され、読み取りデ
ータが下から読み取られる。コマンドOPコード・マップ
430は外部に貯蔵されたデータが供給される初期化ポー
ト465を介して初期化可能である。コンテキスト保管RAM
420はマルチプレクサ441による選択に従って制御プロ
セッサ・バス320又はジオメトリ・サブシステム・バス4
40によってアドレスされる。制御プロセッサ・バス320
は後述のように、コンテキストがコンテキスト保管RAM
420に読み込まれ又はそこから読み出される時に使用さ
れる。ジオメトリ・サブシステム・バス440はコンテキ
ストの蓄積中使用される。

【００３０】ベース・レジスタ490は制御プロセッサ・
バス320を使って制御プロセッサによりロードされる。
このレジスタは3ポート付きの加算器475を介してコンテ
キスト保管RAM 420及びコンテキスト保管コマンド・マ
ップ410をインデックスするためのベース・アドレスを
供給する。デルタ・アドレス455はコンテキストの一部
分としてコンテキスト保管RAM 420に保管された多数の
データワード・コマンドのアドレシングを促すために加
算器475への入力として供給される。コンテキスト保管
コマンド・マップ410は初期化ポート465によって初期化
され、前述のように加算器475によってアドレスされ
る。コマンドOPコード・マップ430から加算器475にコマ
ンドOPコード・アドレスが供給される。

【００３１】コンテキスト保管コマンド・マップ410は
コンテキスト復元動作の時、コンテキスト保管RAM 420
に貯蔵されていたデータのうちの所与のものに対応する
コマンドOPコードを挿入するために使用される。例え
ば、コンテキスト復元動作の時、コンテキスト保管RAM
420におけるロケーションnがDMA動作によってロードさ
れる場合、このデータに対応するOPコードがコンテキス
ト保管コマンド・マップ410のロケーションnに保管され
る。コンテキスト復元動作中ロケーションnがDMAによっ
て更新される時、対応するコマンドがコンテキスト保管
コマンド・マップ410から読み出されてラスタ・データ
処理装置460に書き込まれ、そして下流のラスタライザ
に送られる。またコンテキスト保管RAM 420に書き込ま
れたデータはコンテキスト復元動作中ラスタ・データ処
理装置460に送られ、コンテキスト保管コマンド・マッ
プ410から送られたコマンドのためのデータを与える。

【００３２】コンテキスト保管コマンド・マップ410を
更に説明すると、それはBLT装置360が受け取ったコマン
ドOPコードとその後にラスタ・データ処理装置460に送
られそして下流のラスタライザに送られたOPコードとの
間のマッピングを行う。コンテキスト保管コマンド・マ
ップ410はOPコードが上流で再定義され且つそれらの対
応する下流の値にマッピングされ得るという融通性を与
える。更に、これはコンテキスト保管RAM 420に貯蔵さ
れるべきデータの総量を制限するためにも使用可能であ
る。更に、これは2つ又はそれ以上の機能に誤って同じO
Pコードが割当てられるというOPコード衝突を修正する
ための高価なハードウエア変更の必要を減らすものであ
る。

【００３３】ラスタ・データ処理装置460の性質は本発
明に関連するものではない。それはラスタ・グラフィッ
クス・システムにおける画素処理の一部分として必要と
考えられる任意の装置でよい。処理装置460に対する変
形は本明細書の精神には関係ないものである。

【００３４】好ましい実施例のコンテキスト保管コマン
ド・マップ410及びコンテキスト保管RAM 420はそれぞれ
256個のエントリを有し、コマンドOPコード・マップ430
は512個のエントリを有する。しかし、当業者には明ら
かのように、マップ430、410及びRAM 420の正確な大き
さは固定されたものではない。それらは所与のシステム
に対して任意の適当な大きさのものでよくそれらにおけ
る変更は本発明の範囲内であることは容易にわかる。

【００３５】本発明の好ましい実施例ではコマンドOPコ
ード・マップ430に対する望ましいパワー・アップ状態
が存在する。

【００３６】図5を参照すると、コンテキスト保管RAM 4
20の詳細が示される。コンテキスト保管RAM 420は論理
的にはn個の別々の領域410a、420a、・・・430aに分け
られる。コンテキストRAM 420のうちの任意の領域がベ
ース・レジスタ490によって選択(即ちインデックス)さ
れる。領域420aが、その構成データを明らかにするため
に拡大して示されている。領域420aは1組のコンテキス
ト・データ440a、450a、・・・460aの集合体である。コ
ンテキスト保管RAM 420における特定のエントリはベー
ス・レジスタ490の値にコマンドOPコード・マップ430に
より供給されたコンテキストRAMアドレスを加え、更に
デルタ・アドレス455を加えることによってアクセスさ
れる。そのデルタ・アドレスは所定のコマンドにある種
々のデータを選択するために使用される。例えば、好ま
しい実施例ではビット・ブロック転送を指定するコマン
ド(BITBLT)は多数のデータ・ワード、送信元X、送信元
Y、宛先X、宛先Y、幅、高さ等を含んでいる。このコマ
ンドに遭遇すると、そのコマンドがコンテキスト保管RA
M 420に保管されるべきものである場合、そのBITBLTコ
マンドに関連する各データに対してデルタ・アドレス45
5が1回ステップされ、コンテキスト保管RAM 420におけ
る適当なロケーションをアドレスする。

【００３７】図6を参照すると、本発明の好ましい実施
例に従ってBLT360におけるコンテキスト保管論理回路の
一部分の更に詳細な図が示される。コマンドOPコード・
マップ430における1つのエントリが示される。コマンド
OPコード・マップ430はフロントエンド・ジオメトリ・
サブシステムから受け取ったコマンド情報に応答する。
マップ430の各エントリは3つの個々のフィールドから成
る。その第1はコンテキスト・アドレス431であり、特定
のコンテキスト作成コマンドが保管されるべきコンテキ
スト保管RAM 420の領域をアドレスするために使用され
る。第2フィールドはブーリアン・フラッグの保管コン
テキスト432であり、その特定コマンドが保管されるべ
きものかどうかを表わす。このフラッグがセットされて
ない場合、第1フィールドは使用されず、コマンドはコ
ンテキスト保管RAM 420に保管されない。第3フィールド
は付加的パラメータ433であり、コマンドの処理に関連
し得る付加的データを表わす。好ましい実施例では、こ
の付加的パラメータ・フィールド433は多重データ・フ
ラッグ(図面には明確に示されてない)を含み、そのフラ
ッグはコマンドが複数のデータ・ワードを含むものであ
ること(例えば前述のBITBLTコマンド)を表わすようにセ
ットされる。このフラッグはデルタ・アドレス455の使
用をトリガするために使われる。第2フィールド432及び
第3フィールド433の別の実施例が考えられる。例えば、
ブーリアン・フラッグ432及び多重データ・フラッグ(フ
ィールド433の一部分)はBLT装置360に供給されたコマン
ド・データ・ストリームの一部分として供給されてもよ
い。

【００３８】コンテキスト・アドレス431、ベース・レ
ジスタ490、デルタ・アドレス455が加算器475によって
加算される。加算器475は任意の公知のものでよく、そ
の詳細な算法は本発明の要旨に関係ない。加算器475は
コンテキスト保管RAM 420にアドレス信号を与える。コ
ンテキスト保管RAM 420はブロック440にフロントエンド
・ジオメトリ・サブシステムから入力されたデータを又
は制御プロセッサ・バス320によって制御プロセッサ310
から入力されたデータを受け取る。コンテキスト保管RA
M 420の読み取りポートはコンテキスト保管動作のとき
使うための制御プロセッサ・バス320及びコンテキスト
復元動作のためのラスタ・データ処理装置460にマルチ
プレクサによって接続される。

【００３９】再びコマンドOPコード・マップ430を考察
すると、どのコマンドがコンテキスト保管RAM 420に保
管されるべきか、そしてコンテキスト保管RAM 420内の
どのロケーションにそれらが保管されるべきかを選択的
に制御する能力は従来技術を越えて改良される。なぜな
らば、コンテキストに関連したコマンドだけを保管すれ
ばよく、そして部分的なコンテキスト・スワップを容易
にするようそれら関連したコマンドだけを連続したロケ
ーションに保管可能であればよいためである。更に、相
異なるコマンドに関連したデータをコンテキスト保管RA
M 420内の同じロケーションに保管してもよい。例え
ば、相異なるタイプのBITBLTコマンドに関連した送信元
X及び送信元Yのパラメータをコンテキスト保管RAM 420
における同じロケーションに保管してもよい。これはコ
ンテキスト・スワップ中にDMAによって転送されるべき
データを少なくさせるという効果をもたらす。また関連
のコマンドを保管するだけで更に多くのコンテキストを
コンテキスト保管が必要となる前にコンテキスト保管RA
M 420内に保管可能である。

【００４０】図7及び図8を参照すると、上述の本発明に
よるコンテキスト保管及び復元動作のための論理的流れ
図が示される。そのプロセスはブロック610で始まり然
る後ブロック620に進み、コマンドOPコード・マップ430
を初期設定する。更に、ブロック630でフロントエンド
・ジオメトリ・サブシステムが全体的に見ればラスタリ
ゼーション・サブシステム・コンテキストを構成する複
数のコマンドを送る。

【００４１】ブロック640はコンテキスト・スイッチが
要求されていることの決定である。この時には、ブロッ
ク650が現コンテキストをラスタリゼーション・サブシ
ステムから読み取る。然る後、ブロック660は新しいコ
ンテキストを設定する。更に、ブロック670は下流のコ
マンドの自動的再生をトリガする。次に、ブロック680
はフロントエンド・サブシステムによるグラフィックス
・コマンドの転送を再開する。プロセスはブロック690
で終了する。

【００４２】図9及び図10を参照すると、コンテキスト
の蓄積を詳述した論理的流れ図が示される。このプロセ
スはブロック710で始まる。ブロック720はジオメトリ・
サブシステム・バス440を介したBLT装置360によるパイ
プライン・コマンドの受領を示す。ブロック730はコマ
ンドOPコード・マップ430におけるパイプライン・コマ
ンドのOPコードのルックアップを表わす。判断ブロック
740は受け取ったコマンドがコンテキスト保管RAM 420に
保管されるべきコマンドであるかどうかを決定する。そ
の決定はブーリアン・フラッグ保管コンテキスト432を
調べることによって行われる。それがセットされている
場合、プロセスはブロック750に進み、そのコマンドの
データをそれがコンテキストの一部分として蓄積される
ようコンテキスト保管RAM 420に書き込む。ブロック760
において、コマンド及びその関連データがラスタ・デー
タ処理装置及びラスタライザ370より成るそのシステム
の下流部分に送られる。

【００４３】続いて、ブロック770は次の作業項目を待
つ。各サイクルの後、BLTは作業を待つ。判断ブロック7
80は新しい作業があるかどうかを決定する。それが存在
しない場合、BLT装置はブロック770に戻ることによって
待ち続ける。別のパイプライン・コマンドを受け取った
場合、パス1が取られ、処理はブロック720に戻る。コン
テキスト・スワップの要求を受け取った場合、パス3が
取られ、ブロック790がコンテキスト保管動作(図11に示
される)を行う。プロセスはブロック793に続き、コンテ
キスト復元動作(図12に示される)を行う。プロセスはブ
ロック795で終了する。

【００４４】図11を参照すると、本発明によるコンテキ
スト保管動作を詳述した論理的流れ図が示される。この
プロセスはブロック810で始まり、ブロック830に続く。
ブロック830はBLT装置360からコンテキストを保管する
必要があるかどうかを決定する。

【００４５】本発明では、2つのタイプのコンテキスト
保管が考えられる。コンテキストをBLT装置360から読み
取りそして外部の記憶装置(例えばオフ・チップ)に保管
しなければならない時、ハード・コンテキスト保管が使
用される。これはコンテキスト保管RAM 420において利
用可能な内部記憶装置の容量よりも多くの管理すべきコ
ンテキストがある時に使用される。この決定はコンテキ
スト保管RAM 420及び保管されるべきコンテキストを構
成するコマンドの数に基づいて行われる。管理されつつ
あるコンテキストがコンテキスト保管RAM 420内にある
時、ソフト・コンテキスト・スワップが使用される。ハ
ード・コンテキスト・スワップ動作が必要な時、DMAを
使って保管されるべき領域を選択するために任意のアル
ゴリズムが使用可能である。例えば、最近最も使用され
てない(LRU)領域が選択可能である。ソフト・コンテキ
スト・スワップでは、コンテキスト保管RAM 420からDMA
転送されるメモリ・データはない。その代わり、ベース
・レジスタ490がコンテキスト保管RAM 420の新らしい領
域を指すように調節される。

【００４６】図11の判断ブロック830における決定がノ
ー(否定)である場合、プロセスはブロック840に進んで
ベース・レジスタを変更し、然る後ブロック870で終了
する。その決定がイエス(肯定)である場合、ブロック85
0で制御プロセッサ310にコンテキスト保管RAM 420の読
み取りを行わせる。この読み取りは本発明の好ましい実
施例ではDMA転送を介して行われるが、他の入出力方法
を使ってもよい。その後ブロック860において、制御プ
ロセッサはコンテキスト保管RAM 420から読み取られた
データを中断状態のコンテキストの中央リポジトリに送
る。好ましい実施例ではこの中央リポジトリは制御プロ
セッサ310が利用可能なローカル・メモリでよい。然る
後プロセスはブロック870で終わる。

【００４７】図12は本発明に従ってコンテキスト復元動
作を詳述する論理的流れ図である。プロセスはブロック
910で始まり、然る後復元されるべきコンテキストがコ
ンテキスト復元RAM 420内にあるかどうかを決定するブ
ロック920に進む。その決定がイエス(即ちソフト・テキ
ストが要求される)である場合、ブロック930はベース・
ポインタを調節し、それがBLT装置360内に存在するの
で、コンテキスト保管RAM 420の使用を要求する。復元
されるべきコンテキストの大きさは制御プロセッサ310
の記憶装置内に覚えておくか又はベース・レジスタ490
の拡張機構或いは他の記憶装置に保管することもでき
る。各コンテキストを別々の大きさに維持することは本
発明により与えられるコンテキスト管理装置の融通性を
改良するものである。

【００４８】ブロック920における決定がノー(即ちハー
ド・コンテキスト・スワップが要求される)である場
合、ブロック940で制御プロセッサ310にコンテキスト保
管RAM 420の書き込みを行わせる。この書き込みは本発
明の好ましい実施例ではDMA転送で行われる。然る後、
ブロック950はコマンドOPコード・マップ430により制御
されてコンテキスト保管RAM 420から下流のコンテキス
トを再生する。然る後プロセスはブロック960で終了す
る。

【００４９】

【発明の効果】コンピュータ・グラフィックス・システ
ムにおけるグラフィックス・コンテキストの効果的管理
が可能となる。

【図面の簡単な説明】

【図１】マルチ・ウィンドウ・システムの概略図であ
る。

【図２】本発明の好ましい実施例の概略図である。

【図３】図2のシステムの更に詳細な図である。

【図４】BLT装置の全体的機能を示す高レベルのブロッ
ク図である。

【図５】コンテキスト保管RAMの拡大図である。

【図６】BLT装置におけるコンテキスト保管・復元論理
回路の詳細図である。

【図７】本発明の好ましい実施例に従ってコンテキスト
保管・復元動作を行うための高レベルの論理的流れ図の
1部分である。

【図８】本発明の好ましい実施例に従ってコンテキスト
保管・復元動作を行うための高レベルの論理的流れ図の
残りの部分である。

【図９】コンテキストの蓄積を詳細に示す論理的流れ図
の1部分である。

【図１０】コンテキストの蓄積を詳細に示す論理的流れ
図の残りの部分である。

【図１１】コンテキストの保管を詳細に示す論理的流れ
図である。

【図１２】コンテキストの復元を詳細に示す論理的流れ
図である。

【符号の説明】

210・・・ホスト・プロセッサ 220・・・ジオメトリ処理サブシステム 230・・・ラスタリゼーション・サブシステム 240・・・フレーム・バッファ 250・・・コントローラ 260・・・CRTモニタ 310・・・制御プロセッサ 320・・・制御プロセッサ・バス 350・・・マルチプレクサ装置 360・・・BLT装置 370・・・ラスタライザ 410・・・コンテキスト保管コマンド・マップ 420・・・コンテキスト保管RAM 430・・・コマンドOPコード・マップ 460・・・ラスタ・データ処理装置 475・・・加算器 490・・・ベース・レジスタ

───────────────────────────────────────────────────── フロントページの続き (72)発明者ブルース・シー・ヘンペルアメリカ合衆国ニューヨーク州ディボリレイシ・ロード391 (56)参考文献特開昭62−298829（ＪＰ，Ａ) 特開昭58−166386（ＪＰ，Ａ) 特開平３−141435（ＪＰ，Ａ) 特開平４−237336（ＪＰ，Ａ)

Claims

(57)【特許請求の範囲】

【請求項１】制御プロセッサ及び表示可能な画素データ
を生成するためにラスタライザにより使用されるべきグ
ラフィックス・システム・レンダリング・コンテキスト
・データを複数のグラフィック・オーダを処理すること
によって作成するジオメトリ・プロセッサを有するグラ
フィックス・システムにおいて、前記グラフィックス・システム・レンダリング・コンテ
キスト・データを記憶するための第1データ記憶手段
と、グラフィックス・システム・レンダリング・コンテキス
ト・データ・スワップ要求を検出するための制御手段
と、前記第1データ記憶手段にある前記グラフィックス・シ
ステム・レンダリング・コンテキスト・データを第2記
憶手段に複写し、新しいグラフィックス・システム・レ
ンダリング・コンテキスト・データを前記第2データ記
憶手段から前記第1データ記憶手段にグラフィックス・
オーダを処理することなく複写するためのメモリ入出力
手段と、前記第1データ記憶手段により記憶されるべきグラフィ
ックス・システム・レンダリング・コンテキスト・デー
タのサブセットを選択するための選択手段と、を含み、前記第1データ記憶手段は該第1データ記憶手段内のレン
ダリング・コンテキスト・アイテム・アドレスを決める
アドレス指定手段、前記アドレス指定手段に応答して前
記グラフィックス・システム・レンダリング・コンテキ
スト・データを記憶するランダム・アクセス記憶手段及
び前記アドレス指定手段に応答してグラフィックス・コ
ンテキスト・オペレーション・コード・データを生成す
る記憶マップ手段を含むことを特徴とするグラフィック
ス・システム・レンダリング・コンテキスト・データを
管理するシステム。
【請求項２】オペレーション・コード記憶手段をさらに
含み、前記選択手段は前記オペレーション・コード記憶手段を
チェックしてグラフィックス・オーダを記憶することが
要求されているか否かを判定する手段及び前記オペレー
ション・コード記憶手段内のグラフィック・オーダのロ
ケーションに基づいて前記第1記憶手段に対するアドレ
スを生成するして前記アドレス指定手段に与える手段を
含むことを特徴とする請求1記載のグラフィックス・シ
ステム・レンダリング・コンテキスト・データを管理す
るシステム。
【請求項３】レンダリング・コンテキストの生成を含む
複数のグラフィックス・オーダを処理するための複数の
ジオメトリ・フロントエンド・プロセッサ、外部記憶手
段、内部記憶手段及び非グラフィックス・オーダを処理
するための制御プロセッサを有するグラフィックス・シ
ステムにおいてレンダリング・コンテキストを管理する
方法であって、作業片を受け取るステップと、前記作業片が現レンダリング・コンテキストから新しい
レンダリング・コンテキストへのコンテキスト・スイッ
チを要求しているかどうかをテストするステップと、コンテキスト・スイッチが要求されている場合、前記新
しいレンダリング・コンテキストが前記内部記憶手段に
あるかどうかを決定し、前記新しいコンテキストが前記
内部記憶手段にある場合、前記新しいコンテキストを参
照するようコンテキスト参照アドレスを変更するステッ
プと、コンテキスト・スイッチが要求されているが前記新しい
コンテキストが前記内部記憶手段にない場合、現レンダ
リング・コンテキストを前記外部記憶手段に書き込み且
つ前記外部記憶手段から前記内部記憶手段に前記新しい
レンダリング・コンテキストを読み込むステップと、前記作業片がグラフィックス・コマンドである場合、前
記グラフィックス・コマンドが前記グラフィックス・コ
ンテキスト内に保管されるべきかどうかをテストするス
テップと、前記グラフィックス・コマンドを前記内部記憶手段に保
管するためのインデックス・アドレスを作成するステッ
プと、前記グラフィックス・コマンドを前記インデックス・ア
ドレスに保管するステップと、を含むコンテキストを管理する方法。