JPH05266201A - グラフィックス並列処理方法及びその装置 - Google Patents

Abstract

(57)【要約】 【目的】 複数の汎用プロセッサで、グラフィックスジ
オメトリ処理を並列に行ない、ジオメトリ処理を行うプ
ロセッサの数に依存せず、負荷の分散を行う。 【構成】 グラフィックスコマンドを作成するアプリケ
ーション（ＣＳ）が動作するプロセッサ（ＣＰＵ（Ｃ
Ｓ）：ＣＰＵ０〜３のいずれか）とグラフィックスのジ
オメトリ処理（ＧＳ）を行うプロセッサ（ＣＰＵ（Ｇ
Ｓ）：ＣＰＵ０〜３のいずれか）間のデータ転送を、デ
ィスパッチテーブル８の格納データに基づいて行う。Ｃ
ＰＵ（ＣＳ）は、グラフィックスコマンドをディスパッ
チャテーブル８にセットする。処理するデータがなくな
ったＣＰＵ（ＧＳ）はディスパッチテーブルを参照する
ことで、次のグラフィックスコマンドを処理することが
可能になり、プロセッサの数に依存せず、負荷の分散が
図れる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明はワークステーション等の
グラフィックスの描画処理のなかでとくに描画のための
幾何計算を処理するプロセッサを並列に動作させるグラ
フィックス並列処理装置に係り、特に、描画処理を高速
に行なうに好適なグラフィックス並列処理方法及びその
装置に関する。

【０００２】

【従来の技術】従来のグラフィックス処理を高速に実現
する方式は、グラフィックス専用ハードウェアを用い、
パイプラインや並列処理方式を実現するものが多かっ
た。また汎用ＣＰＵで並列に行なうグラフィックス処理
方式に関しては、次のようなものがある。

【０００３】第１の公知例として、The Titan Graphi
cs Supercomputer Architecture“IEEE COMPUTER S
eptember 1988”（ザ タイタン グラフィックス ス
ーパーコンピュータ アーキテクチャ “アイ イー
イー イー コンピュータセプテンバー １９８８”）
にその詳細が記述されている。この従来例では、並列化
コンパイラでグラフィックス処理を行うプログラミング
を並列化し、複数のプロセッサで実現している。確か
に、スクリーン上の１画素を算出するのに多くの計算量
を必要とするようなリアリズムを追及するグラフィック
ス処理では有効である。しかし、より一般的なＣＡＤや
オフィス用のグラフィックス処理では十分な効果が得ら
れていない。なぜなら、こういった分野のグラフィック
ス処理では処理内容が比較的少なく、並列化コンパイラ
で並列度を向上させるほど計算量が多くなく、各プロセ
ス間のオーバヘッドが大きくなり、こういった分野の描
画アプリケーションには向いていないためである。

【０００４】また、第２の公知例が、The Rendering
Architecture of the DN10000VS“Computer Graphi
cs, Vol24, Num4”（ザ レンダリング アーキテク
チャオブ ザ ディエヌ１００００ＶＳ“コンピュータ
グラフィックス ２４巻４号”）に記述されている。
この従来例では、描画コマンドをラウンドロビン方式に
よって１コマンド単位で複数の汎用ＣＰＵに分配し、て
その処理を行なっている。従って、各汎用ＣＰＵが処理
する順序が予め決められているので、その順序制御は簡
単であり、負荷の均一なグラフィックスコマンドが連続
するケースでは有効である。しかし、より一般的な各コ
マンドの負荷にばらつきがあるケースでは、負荷を分散
させる事が難しくなる。

【０００５】

【発明が解決しようとする課題】上記従来技術は、並列
処理の順序制御が簡単に行える利点があるが、各描画コ
マンドの処理時間は一般的には不均一であり、一部のプ
ロセッサの負荷だけが重たくなり全体の性能が低下する
虞がある。特に、並列処理用オペレーティングシステム
上で動作させるケースにおいては、どのプロセッサがど
のプロセスを処理するかを、並列処理用オペレーティン
グシステムが管理するため、ジオメトリ処理を行うプロ
セッサ数は時間とともに変化する。こういったケース
で、描画コマンドを分配するプロセッサは、絶えずジオ
メトリ処理を行うプロセッサの数を把握しておくことが
必要になり、その制御は複雑になる傾向にある。

【０００６】また、最近は汎用ＣＰＵの性能向上が著し
く、その計算能力にグラフィックス処理を行わせるとグ
ラフィックス性能の著しい向上が期待できる。しかし、
バスを介した転送を行う際にバスの速度が転送ネックに
なる傾向にある。

【０００７】本発明の第１の目的は、ジオメトリ処理を
行うプロセッサの数に依存せず、負荷の分散が達成でき
るグラフィックス並列処理方法及びその装置を提供する
ことにある。

【０００８】本発明の第２の目的は、汎用ＣＰＵとグラ
フィックスのレンダリング処理を行うＩ／Ｏ間とのデー
タ転送を高速にして、バランスのとれたグラフィックス
システムを提供することにある。

【０００９】

【課題を解決するための手段】上記第１の目的は、グラ
フィックスコマンドを作成するアプリケーション（Ｃ
Ｓ）が動作するプロセッサ、またはプロセス（ＣＰＵ
（ＣＳ））とグラフィックスのジオメトリ処理（ＧＳ）
を行うプロセッサ、またはプロセス（ＣＰＵ（ＧＳ））
間のデータ転送を、ディスパッチテーブルを介して行う
構成にし、ＣＰＵ（ＣＳ）はグラフィックスコマンドを
ディスパッチャテーブルにセットし、処理するデータが
なくなったＣＰＵ（ＧＳ）はディスパッチテーブルを参
照して、次のグラフィックスコマンドを処理し、ディス
パッチテーブルは、複数のプロセッサからのアクセスを
排他制御とすることで、達成される。

【００１０】上記第２の目的は、汎用ＣＰＵとグラフィ
ックスのレンダリング処理を行うＩ／Ｏ（レンダリング
プロセッサ部、ＲＰ部と記す）間のデータ転送量を減ら
すために、ＲＰ部のレジスタのアドレスにデータを転送
する方式とし、さらに、データ転送を連続してまとめて
行うバースト転送を利用するためＲＰのメモリマップを
１つのコマンドに対して必ず連続にするようにマッピン
グし、このときＲＰ部のレジスタを複数のアドレスにマ
ッピングし、ＲＰ部に、それらのアドレスをデコードし
て、本来のレジスタにセットするためのデコーダを設け
ることで、達成される。

【００１１】

【作用】ディスパッチテーブルを参照し、ＣＰＵ（Ｃ
Ｓ）はＣＰＵ（ＧＳ）の個数を意識せずグラフィックス
コマンドを次々に生成する。また、処理の終わったＣＰ
Ｕ（ＧＳ）が次に処理すべきグラフィックスコマンドを
自発的に選び実行する。それによって、負荷の分散が可
能となり、汎用マルチオペレーティングシステム上で動
作しても全体的な性能向上が実現できる。

【００１２】また、アドレスデコーダをＲＰ部に設ける
ことにより、ＲＰコマンドのデータ転送を連続したアド
レスで行うことが可能となるようにＲＰ部のレジスタを
マップをする。それによって、バースト転送を利用で
き、高速にデータ転送ができる。またバースト転送にお
いては、転送するバイト量が固定である場合、ＲＰコマ
ンドにおいては不要のデータを転送することが必要にな
る。こういったケースでも本デコーダによって不要デー
タと解釈することが可能となる。また、さほど高速性は
必要ないが多種のコマンドに対応するために、個々のＲ
Ｐレジスタに１つづつ設定することも可能となり、汎用
性に優れる。

【００１３】

【実施例】以下、本発明の一実施例を図１〜図１８を参
照して説明する。図１は、本発明の一実施例に係るグラ
フィックス並列処理装置のシステム構成図である。プロ
セッサバス１２には、４つのＣＰＵ０〜３と、メモリコ
ントローラ＆バスコントローラ５が接続されている。各
ＣＰＵ０〜３にはキャッシュメモリ（図示しない）が設
けられている。これらのＣＰＵ０〜３は、並列処理用オ
ペレーティングシステムで動作し、シンメトリックな構
成になっている。メモリコントローラ＆バスコントロー
ラ５は、プロサッセバス１２とシステムバス１３のコン
トロール、またメインメモリ７へのアクセスコントロー
ルを行う。ディスパッチテーブル８は、メインメモリ７
に設けられている。ＣＰＵ０〜３は、グラフィックスコ
マンドを生成するアプリケーションが動作するＣＰＵ
（ＣＳ）と、ジオメトリ処理を行うＣＰＵ（ＧＳ）に区
分される。勿論、どのプロセッサをＣＰＵ（ＣＳ）とし
て動作させどのプロセッサをＣＰＵ（ＧＳ）として動作
させるかの特定はせず、プロセスに割り付けることも可
能である。各ＣＰＵ間または各プロセス間のデータ競合
やコマンドの順序制御を、このディスパッチテーブル８
で実現する。

【００１４】システムバス１３には特に重要度の高いＩ
／Ｏが接続されており、ネットワークコントローラ、ハ
ードディスク、そしてグラフィックスのレンダリング部
（ＲＰ部）１４がある。ＲＰ部１４は、ＣＰＵからのデ
ータを受け取り、ＲＰ部全体を制御するレンダリングコ
ントローラ９と、レンダリング処理を実行してフレーム
メモリ１１に書き込むレンダリングプロセッサ１０と、
モニタの表示内容をビットマップ形式で保持するフレー
ムメモリ１１からなる。

【００１５】図２は、複数ＣＰＵの処理の時刻に伴う割
当の様子を模式的に示した例である。ここでは、プロセ
ス単位で並列用オペレーティングシステムがその処理を
スケジューリングするとしている。最初はグラフィック
スコマンドを生成するプロセス１がＣＰＵ０で動作し、
ＣＰＵ１〜３で夫々ジオメトリ処理を行なうプロセス１
０，１１，１２が動作している。

【００１６】次に、ＣＰＵ０でグラフィックスコマンド
を生成する別のプロセス２が動作し、そのジオメトリ処
理を行なうプロセス２０，２１がＣＰＵ１，２で動作す
る。プロセス１６はウインドウマネージャであり、ある
間隔でカーソル描画のプロセスが動作している。プロセ
ス３はグラフィックス処理を伴わない処理がＣＰＵ３で
動作している。次々に多種のプロセスが夫々のＣＰＵ０
〜３上で動作するが、複数のＣＰＵ０〜３では必ずしも
同期してプロセスが切り替わるわけではない。

【００１７】グラフィックス処理の概略を図３に示す。
まず第１の段階でグラフィックスコマンドを作成する。
実際にはアプリケーションが動作し、グラフィックスラ
イブラリをコールすることで実現する。第２の段階は、
ＣＰＵ（ＣＳ）とＣＰＵ（ＧＳ）間のインタフェースで
ある。コールされたグラフィックスライブラリの処理
は、上位ジオメトリ処理として、ＣＰＵ（ＧＳ）に処理
を依頼するグラフィックスコマンドの場合には、ディス
パッチテーブル８にセットする。またＣＰＵ（ＧＳ）に
処理を依頼しないグラフィックスコマンドはＣＰＵ（Ｃ
Ｓ）で処理を行う。ここまでの処理段階（グラフィック
スコマンド生成段階＋上位ジオメトリ処理段階）は、Ｃ
ＰＵ（ＣＳ）が行う。

【００１８】グラフィックス処理の第３の段階では、Ｃ
ＰＵ（ＧＳ）がディスパッチテーブル８から次に処理す
るグラフィックスコマンドを読んで、グラフィックスの
幾何変換，クリッピング，輝度計算等の処理をおこな
い、レンダリング部へのＲＰコマンドに変換して、ディ
スパッチテーブル８にセットし、さらにディスパッチテ
ーブル８に従って、順序を守りながらＲＰコマンドをレ
ンダリング部に送付する。下位ジオメトリ処理段階は、
ＣＰＵ（ＧＳ）が行う。

【００１９】グラフィックス処理の第４の段階では、画
素を書き込むアドレスと書き込む画素データを１画素づ
つ計算してフレームメモリに書き込む。このレンダリン
グ処理段階はＲＰ部１４で行う。なお、並列処理を行う
時のグラフィックスコマンドのまとまりの単位をディス
パッチユニットと呼ぶが、本実施例では１つのグラフィ
ックスコマンドを１ディスパッチユニットとしている。

【００２０】図４は、アプリケーションプログラムが使
用するグラフィックスコマンドの分類図である。図形の
描画を指示する描画コマンド、ＧＳの状態を設定する状
態変更属性コマンド、ＲＰ部１４の状態を指示するＲＰ
制御属性コマンド、ある個別のアプリケーションではな
くモニタ画面を管理しているウインドウマネージャが発
行するカーソルコマンド等に分類される。

【００２１】図５〜図９は、分類したグラフィックスコ
マンドの代表的なものについての処理手順を示すフロー
チャートである。図５はＴｒｉａｎｇｌｅｓｔｒｉｐコ
マンドの処理フローを示している。上位ジオメトリ処理
では、ディスパッチテーブルに、グラフィックスコマン
ドをセットする。下位ジオメトリ処理では、まずディス
パッチャテーブルからグラフィックスコマンドをリード
する。そしてリードしたデータに対し、アプリケーショ
ンが定義する座標系からモニタの座標系に座標変換し、
各頂点の輝度計算、クリッピングエリアに対するクリッ
ピング（これらの処理の詳細は”ＣｏｍｐｕｔｅｒＧｒ
ａｐｈｉｃｓＰｒｉｎｃｉｐｌｅｓ＆Ｐｒａｃｔｉｃ
ｅ”Ｆｏｌｅｙ他著ＡｄｄｉｓｏｎＷｅｓｌｅｙ社に詳
しく述べられている。）、そしてＲＰコマンドを作成し
て、ディスパッチテーブル８に設定する。ここで、座標
変換するための座標変換マトリクス，輝度計算を行うた
めの視点位置，光源の種類またクリッピングするための
クリッピングエリアは、メインメモリ７内のジオメトリ
処理用コンテキストテーブルにその現在の値が１セット
だけ保持されている。

【００２２】図６は、Ｐｏｌｙｌｉｎｅの処理フローを
示しており、図５の処理フローと同様の処理を行う。

【００２３】図７は、状態変更属性コマンドの処理フロ
ーを示している。この処理は、上位ジオメトリ処理段階
で処理される。まず、ジオメトリ処理用コンテキストの
現在の値と比較する。同じであれば、処理をおわって、
次の処理を行う。現在の値と異なっていれば、下位ジオ
メトリ処理を行うすべてのＣＰＵ（ＧＳ）が入力待ちの
状態になるのを確認して、ジオメトリ処理用コンテキス
トテーブルにセットする。

【００２４】図８は、ＲＰ制御属性コマンドの処理フロ
ーを示している。ここでもまず、現在の値と比較し、同
じであれば、処理を終わる。現在の値と異なっていれ
ば、下位ジオメトリ処理を行うすべてのＣＰＵ（ＧＳ）
が入力待ちの状態になるのを確認して、ジオメトリ処理
用コンテキストテーブルにセットする。さらにＲＰコマ
ンドを生成して、ＲＰに転送する。

【００２５】図９は、カーソルコマンドの処理フローを
示している。まずカーソルの位置がカーソル表示のイメ
ージデータを変更する位置か否かを判定し、変更の必要
がなければ、そのままＲＰコマンドをＲＰ部１４に送付
する。位置によりカーソルのイメージデータを変更する
必要があれば、ＲＰ部１４にカーソルイメージデータを
転送し、そしてカーソルの位置をＲＰに転送する。一般
にカーソルコマンドはモニタ画面を管理するウインドウ
マネージャが発行し、各アプリケーションの発行する描
画コマンドとの順序性とは無関係にＲＰコマンドをＲＰ
部１４に転送する。これは図２に示す様に、ある間隔で
動作するプロセス１６に相当する。

【００２６】図１０は、ＲＰに送付するＲＰコマンドの
分類図である。ＲＰ部１４の起動レジスタに直接セット
して起動を行う。ＲＰ部１４は起動レジスタにセットさ
れたコマンドに従って、すでに設定されている関連レジ
スタを参照しながら描画を行う。その関連レジスタは、
描画する図形の基準点やその図形の大きさを指定する描
画関連レジスタ、そのコマンドの属性を指示し、またフ
レームメモリへの書き込み制御を指定する描画制御関連
レジスタ、描画エリアを指定する描画エリア関連レジス
タ、そしてＲＰ部１４の内部状態を反映する状態レジス
タがある。第５図に示したＲＰコマンド作成処理とは、
必要なＲＰレジスタに設定する値と、起動レジスタにコ
マンドを設定するデータ（オペコード）を作成すること
である。

【００２７】図１１（ａ）は、ＣＰＵからみたメモリマ
ップを示している。ディスパッチテーブルはユーザ空間
にあり、ＲＰレジスタはＩ／Ｏ空間に定義されている。
図１１（ｂ）は、ＲＰレジスタのマッピングの一部を示
している。例えば、アドレス“７Ｆ００００００”にｘ
の値を、“７Ｆ０００００４”にｙの値を、以下同様に
“７Ｆ００００１４”までその意味する値をストアし、
“７Ｆ００００１８”にＴｒｉａｎｇｌｅｓｔｒｉｐ命
令を意味するオペコードをストアする。また、“７Ｆ０
０００２０”にｘの値、“７Ｆ００００２４”にｙの
値、そして“７Ｆ００００２８”にＰｏｌｙｌｉｎｅ命
令を意味するオペコードをストアする。このようにＲＰ
のレジスタに値を設定し、起動レジスタに設定すること
によりＲＰに起動をかけるのである。勿論、起動レジス
タにオペコードをストアするだけで、ＲＰは、そのオペ
コードに関連するレジスタを参照して実行する。尚、図
１２はＲＰのレジスタのマップである。

【００２８】図１３はディスパッチテーブル８の概略図
である。まず３種のテーブルポインタが、夫々ディスパ
ッチテーブルユニットを指示している。このディスパッ
チテーブルにアクセスするのは、ＣＰＵ（ＣＳ）がグラ
フィックスコマンドを設定するとき、ＣＰＵ（ＧＳ）が
グラフィックスコマンドを読み込むとき、ＣＰＵ（Ｇ
Ｓ）がＲＰコマンドをＲＰ部１４に転送するときであ
り、夫々のケースで各テーブルポインタをアクセスす
る。そして各テーブルポインタの指示するユニットの状
態フラグをチェックして、実行可能であれば処理を行
う。各ユニットには、夫々そのユニットの状態を示す５
つのフラグ（ユニット状態フラグ８０１〜８０５と呼
ぶ）と、ＧＳリードバッファ８１３と、ＧＳライトバッ
ファ８１１の各ユニットに対するデータの所在する先頭
アドレスを保持するＧＳリードバッファポインタ８０６
と、ＧＳライトバッファポインタ８０７がある。この１
つのユニットで管理する単位で並列処理を実行するので
ある。

【００２９】このユニット状態フラグ８０１〜８０５は
複数のＣＰＵからアクセスされるので、排他制御でアク
セスする構成とする。ＣＳライトフラグ８０１はＣＰＵ
（ＣＳ）が書き込み中であることを示し、他のＣＰＵは
この項目にはアクセスできない。ＣＳレディフラグ８０
２は、ＣＰＵ（ＣＳ）の書き込みが終了しＣＰＵ（Ｇ
Ｓ）のアクセスを待っていることを示す。このとき、Ｇ
Ｓリードバッファポインタ８０６は有効であり、グラフ
ィックスコマンドがセットしてある位置を指示してい
る。ＧＳリードフラグ８０３はＣＰＵ（ＧＳ）がグラフ
ィックス幾何変換を行いながらＧＳリードバッファ８１
３を読み込み中であることを示し、他のＣＰＵはこのユ
ニットにはアクセスできない。ＧＳレディフラグ８０４
はＣＰＵ（ＧＳ）のグラフィックス幾何変換が終了し、
ＧＳライトバッファ８１１にＲＰコマンドがセットして
してある状態を示す。このとき、ＧＳライトバッファリ
ードポインタ８０７は有効であり、ＲＰコマンドがセッ
トしている位置を示している。ＲＳリードフラグ８０５
はＣＰＵ（ＧＳ）がＧＳライトバッファ８１１のデータ
をＲＰ部１４に転送していることを示している。

【００３０】ところで、ＧＳライトバッファ８１１は各
ＣＰＵ（ＧＳ）の単位で独立にグラフィックス幾何処理
を行うため、各ＣＰＵ（ＧＳ）単位でＧＳライトバッフ
ァポインタ８１２とＧＳライトバッファ８１１を保持す
る。このＧＳライトバッファポインタ８１２はＣＰＵ
（ＧＳ）がＧＳライトバッファ８１１に書き込むときの
先頭アドレスを指示している。

【００３１】図５に示した上位ジオメトリ処理中の“デ
ィスパッチテーブルにセット”する手順の詳細を図１４
に示す。

【００３２】まず、ＣＳライトテーブルポインタ８１０
の指示するユニットとＣＳライトテーブルポインタ８１
０の指示する次のユニット状態フラグ８０１〜８０５の
２つを参照し、“０００００”ならばＣＳライトテーブ
ルポインタ８１０の指示するユニット状態フラグを“１
００００”にする。これは他のＣＰＵからもアクセスす
るので、排他制御でアクセスすることが必要である。
“０００００”でなければ“１１１１１”であるかを調
べ、“１１１１１”であればユニットの最下段であるの
でＣＳライトテーブルポインタ８１０を最上段のユニッ
トを指示するようにかきかえる。そうして“００００
０”になるまでポーリングでチェックする。

【００３３】そしてＧＳリードバッファポインタ８０６
の指示する領域からグラフィックスコマンドを設定す
る。そしてＧＳリードバッファ有効フラグ８１４をイン
クリメントする。次に、次のユニットのＧＳリードバッ
ファポインタ８０６に次のリードバッファの位置をセッ
トする。そしてユニット状態フラグ８０１〜８０５を
“１００００”から“０１０００”にセットする。最後
にＣＳライトテーブルポインタ８１０を更新する。

【００３４】ここで、ＧＳリードバッファ８１３にグラ
フィックスコマンドを設定中にＧＳリードバッファ８１
３の再下段を越えるケースが発生する虞がある。これを
避けるために、図１６に示すようにＧＳリードバッファ
８１３を２面（第１ＧＳリードバッファ８１３１と第２
ＧＳリードバッファ８１３２）持つ構成にする。各バッ
ファにはＧＳリードバッファ有効フラグ８１４１，８１
４２があり、このフラグはそのバッファに存在する有効
なデータセットの“数”を示しており、ゼロであれば有
効なデータはないことを示す。ＧＳリードバッファ有効
フラグ８１４１，８１４２は、ＣＰＵ（ＣＳ）がグラフ
ィックスコマンドを設定するときにインクリメントし、
ＣＰＵ（ＧＳ）がグラフィックスコマンドを読み終わっ
たときにディクリメントする。また、このＧＳリードバ
ッファ有効フラグ８１４１，８１４２は、複数のＣＰＵ
がアクセスするため排他制御で管理することが必要にな
る。

【００３５】図１５は、下位ジオメトリ処理のフローを
示している。まず、ＧＳリードテーブルポインタ８０９
の指示するユニット状態フラグ８０１〜８０５をチェッ
クして“０１０００”ならば“００１００”にする。そ
して、ＧＳリードテーブルポインタ８０９の更新すなわ
ち「＋１」する。ＧＳリードバッファポインタ８０６の
指示する領域からデータを読んで幾何変換，輝度計算や
クリッピング等の処理を行う。そしてＲＰコマンドをＧ
Ｓライトバッファポインタ８０７の指示する領域にセッ
トする。そしてユニット状態フラグ８０１〜８０５を
“００１００”から“０００１０”にセットする。

【００３６】次に、ＲＳリードテーブルポインタ８０８
の指示するユニット状態フラグ８０１〜８０５をチェッ
クして“０００１０”ならば“００００１”にする。Ｇ
Ｓライトバッファリードポインタ８０７の指示する領域
から１ユニット分のＲＰコマンドをＲＰ部１４に転送す
る。この転送は下記に示すように行なう。

【００３７】ＧＳライトバッファ８１１には、ＲＰコマ
ンドとしてのオペコードとそのオペランドが保持されて
いる。従って、そのオペコードに従って、図１１（ｂ）
に示すようにアドレスとそのデータにして、連続したア
ドレスにまとめてＲＰ部１４に送付する。

【００３８】１ユニット分の転送終了後ＲＳリードテー
ブルポインタ８０８の更新を行う。最後にユニット状態
フラグ８０１〜８０５を“００００１”から“００００
０”にセットする。

【００３９】今までは、汎用ＣＰＵで行う上位ジオメト
リ処理段階と下位ジオメトリ処理段階についての処理内
容を示してきた。

【００４０】図１７は、ＲＰ部１４のレンダリングコン
トローラ９のブロック図を示している。システムバス１
３に流れるアドレスに対し、その上位アドレスを上位ア
ドレスデコーダ９０１でデコードし、ＲＰ部１４への送
付か否かを判定する。下位アドレスデコーダ９０２で
は、必要なアドレスを判定しそのアドレスの下位を第１
１図に示すレジスタマップに変換したアドレスとそのデ
ータを第１ＦＩＦＯ９０６にセットする。またｎｏｐは
アドレスもデータも設定しない。例えば、 ００２０ ａ０ ００２４ ｂ０ ００２８ ｃ０ ００２ｃ ｄ０ は、下位アドレスデコーダ９０２で以下のように変換さ
れて、第１ＦＩＦＯ９０６にセットされる。

【００４１】 ００ ａ０ ０１ ｂ０ ＦＦ ｃ０ ００２Ｃのアドレスの意味はｎｏｐなので第１ＦＩＦＯ
９０６にはセットしない。ここでＦＩＦＯは２種類あ
る。第１ＦＩＦＯ９０６は、図１０に示している描画関
連レジスタ、描画制御関連レジスタ、そして描画エリア
関連レジスタへの設定時に使用される。従ってこれらの
レジスタへの設定順序は保証される。また、第２ＦＩＦ
Ｏ９０７はカーソル関連レジスタへの設定時に使用され
る。すなわち第２ＦＩＦＯ９０７は、描画順序を無視し
て高速にアクセスするコマンドに使用される。特にカー
ソル描画は任意のアプリケーションではなく、モニタ画
面を制御するウインドウマネージャの発行するコマンド
であるので他の種類のコマンドとの関係はない。勿論、
カーソル関連コマンドの順序性は、第２ＦＩＦＯ９０７
を利用することにより遵守できる。

【００４２】以上で、本発明に関する１実施例のシステ
ムの構成とその動作を説明した。図１８は、グラフィッ
クスコマンドの実例を示している。

【００４３】まず、Ｓｅｔｍａｔｒｉｘコマンドは、状
態変更属性コマンドであるので、図７に示したフローで
処理を行う。ＳｅｔｃｌｉｐａｒｅａコマンドはＲＰ制
御属性コマンドであるので、図８で示した処理フローで
処理される。同様に、Ｍｕｌｔｍａｔｒｉｘ，Ｓｅｔｌ
ｉｎｅｃｏｌｏｒコマンドは、夫々、図７，図８の処理
フローに従って処理される。ここまでは、ＣＰＵ（Ｃ
Ｓ）で実行され、並列処理の効果はない。

【００４４】Ｐｏｌｙｌｉｎｅコマンドは、描画命令で
あるので、図６の処理フローに従って処理する。以降４
つのＰｏｌｙｌｉｎｅコマンドが並列に処理されること
になる。次の、Ｓｅｔｌｉｎｅｃｏｌｏｒコマンドは、
図８の処理となり、カレント属性と比較した結果、異な
れば、ここでＣＰＵ（ＧＳ）との同期をとる必要があ
る。同じであれば、同期をとることなく、次のＰｏｌｙ
ｌｉｎｅコマンドの並列処理を行うことになる。次のＭ
ｕｌｔｍａｔｒｉｘコマンドは、必ず同期をとることが
必要になり、ＣＰＵ（ＧＳ）が待ち状態になったのを確
認してＣＰＵ（ＣＳ）がその処理を行う。Ｇｅｔｃｕｒ
ｒｅｎｔｍａｔｒｉｘも同様にＣＰＵ（ＧＳ）が待ち状
態になったのを確認してＣＰＵ（ＣＳ）がその処理を行
う。次のＴｒｉａｎｇｌｅｓｔｒｉｐコマンドは、図５
に示した処理フローで処理を行う。従って、４つのＴｒ
ｉａｎｇｌｅｓｔｒｉｐコマンドはＣＰＵ（ＧＳ）で並
列に処理される。Ｓｅｔｍａｔｒｉｘコマンドは、図７
の処理フローで処理される。カレントな値と異なれば同
期をとる必要があるが、同じであれば同期をとることな
く次のコマンドの処理を行う。次の３つのＴｒｉａｎｇ
ｌｅｓｔｒｉｐコマンドは並列に処理される。最後のＧ
ｅｔｉｍａｇｅコマンドは、ＲＰ問い合わせコマンドで
あるので、ＲＰがデータ入力待ちの状態になっているこ
とを確認してＲＰコマンドを送付することになる。

【００４５】ここでＲＰが入力待ちであることを確認す
るために、ＲＰコマンドに下記の制御用コマンド（アイ
ドル割り込み要求コマンド）を追加し、待ち時間に他の
プロセスを動作させることを可能にする。

【００４６】“アイドル要求コマンドがレンダリングプ
ロセッサに到達すると要求もとのＣＰＵに割り込みを帰
す”このコマンドは、図１７の、第１ＦＩＦＯ９０６に
セットされる。

【００４７】

【発明の効果】本発明は、次のような効果を奏する。

【００４８】（１）ディスパッチテーブルでＣＰＵ（Ｃ
Ｓ）とＣＰＵ（ＧＳ）のデータ転送を行うので、負荷の
分散が簡単にできる。また、複数のＣＰＵ（ＧＳ）の数
が時間と共に変動しても、効率の減少が少ない。

【００４９】（２）同期をとる必要な属性コマンドはカ
レントの値と比較して、必要なときだけ同期をとること
により、同期をとる回数が減少し、並列処理の効率が増
加する。実際のグラフィックスコマンドでは、ほとんど
が同じデータの属性コマンドを発行している。

【００５０】（３）ＲＰのレジスタを複数にマッピング
しているので、ＲＰへのデータ転送を連続したアドレス
にすることが可能となり、バースト転送といった高速転
送が可能になる。

【００５１】（４）バースト転送を実現するには、連続
し且つある決められたバイト数を転送することが必要に
なる。そこでレンダリングコントローラ内の下位アドレ
スデコーダにより、必要なコマンドのみをＦＩＦＯにセ
ットすることにより、ＦＩＦＯ段数を少なくでき、ハー
ドウエアの縮小化が実現できる。

【図面の簡単な説明】

【図１】本発明の一実施例に係るグラフィックス並列処
理装置の構成図である。

【図２】複数ＣＰＵの処理の割当例説明図である。

【図３】グラフィックス処理の概略説明図である。

【図４】グラフィックスコマンドの分類図である。

【図５】描画コマンドの処理フローである。

【図６】描画コマンドの処理フローである。

【図７】状態変更属性コマンドの処理フローである。

【図８】ＲＰ部制御属性コマンドの処理フローである。

【図９】カーソルコマンドの処理フローである。

【図１０】ＲＰのレジスタ分類図である。

【図１１】ＣＰＵからのメモリマップ構成図である。

【図１２】ＲＰのレジスタのアドレスマップ構成図であ
る。

【図１３】ディスパッチテーブルの概略図である。

【図１４】上位ジオメトリの処理フローである。

【図１５】下位ジオメトリの処理フローである。

【図１６】ＧＳリードバッファ構成図である。

【図１７】レンダリングコントローラ構成図である。

【図１８】グラフィックスコマンドの一例の説明図であ
る。

【符号の説明】

０，１，２，３…ＣＰＵ、５…メモリコントローラ＆バ
スコントローラ、７…メインメモリ、８…ディスパッチ
テーブル、１２…プロセッサバス、１３…システムバ
ス、１４…レンダリング部。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 福永 泰 茨城県日立市久慈町4026番地 株式会社日 立製作所日立研究所内 (72)発明者 桑名 利幸 茨城県日立市大みか町五丁目２番１号 株 式会社日立製作所大みか工場内

Claims (10)

【特許請求の範囲】
1. 【請求項１】 複数の汎用プロセッサと、各汎用プロセ
   ッサが他の汎用プロセッサと排他制御でアクセスするデ
   ィスパッチテーブルと、グラフィックス処理の中で１画
   素づつ画素を生成するレンダリング処理を行なうレンダ
   リングプロセッサ部とを備えるグラフィックス並列処理
   装置において、複数の汎用プロセッサをグラフィックス
   コマンドを生成するプロセッサ（ＣＳ）とグラフィック
   ス処理の中の幾何変換を行なう複数プロセッサ（ＧＳ）
   との２つのグループに分類し、プロセッサ（ＣＳ）とプ
   ロセッサ（ＧＳ）間のデータの転送およびプロセッサ
   （ＧＳ）とレンダリングプロセッサ間のデータの転送
   を、順序情報と状態情報を持ったディスパッチテーブル
   の格納データに基づいて行なうことを特徴とするグラフ
   ィックス並列処理方法。
2. 【請求項２】 請求項１において、プロセッサ（ＣＳ）
   とプロセッサ（ＧＳ）間のデータの転送では複数のプロ
   セッサ（ＧＳ）がディスパッチテーブルで必要データを
   探索し、プロセッサ（ＧＳ）とレンダリングプロセッサ
   間のデータの転送は複数のプロセッサ（ＧＳ）がディス
   パッチテーブルで必要データをレンダリングプロセッサ
   に転送することを特徴とするグラフィックス並列処理方
   法。
3. 【請求項３】 請求項１または請求項２において、幾何
   変換を行なうときのグラフィックス属性設定コマンド等
   の、プロセッサ（ＣＳ）とプロセッサ（ＧＳ）間のデー
   タの転送において順序制御が必要なグラフィックスコマ
   ンドは、プロセッサ（ＣＳ）がプロセッサ（ＧＳ）の処
   理の同期を取って処理を行なうことを特徴とするグラフ
   ィックス並列処理方法。
4. 【請求項４】 請求項１乃至請求項３のいずれかにおい
   て、グラフィックス属性設定コマンドが発行されたとき
   には、その属性値を現在値と比較し、異なった属性値の
   時のみ、そのコマンド処理を行なうことを特徴とするグ
   ラフィックス並列処理方法。
5. 【請求項５】 複数の汎用プロセッサと、各汎用プロセ
   ッサが他の汎用プロセッサと排他制御でアクセスするデ
   ィスパッチテーブルと、グラフィックス処理の中で１画
   素づつ画素を生成するレンダリング処理を行なうレンダ
   リングプロセッサ部とを備えるグラフィックス並列処理
   装置において、複数の汎用プロセッサをグラフィックス
   コマンドを生成するプロセッサ（ＣＳ）とグラフィック
   ス処理の中の幾何変換を行なう複数プロセッサ（ＧＳ）
   との２つのグループに分類する手段と、プロセッサ（Ｃ
   Ｓ）とプロセッサ（ＧＳ）間のデータの転送およびプロ
   セッサ（ＧＳ）とレンダリングプロセッサ間のデータの
   転送を順序情報と状態情報を持ったディスパッチテーブ
   ルの格納データに従って制御する手段とを備えることを
   特徴とするグラフィックス並列処理装置。
6. 【請求項６】 請求項５において、プロセッサ（ＣＳ）
   とプロセッサ（ＧＳ）間のデータの転送では複数のプロ
   セッサ（ＧＳ）がディスパッチテーブルで必要データを
   探索する手段と、プロセッサ（ＧＳ）とレンダリングプ
   ロセッサ間のデータの転送は複数のプロセッサ（ＧＳ）
   がディスパッチテーブルで必要データをレンダリングプ
   ロセッサに転送する手段を設けたことを特徴とするグラ
   フィックス並列処理装置。
7. 【請求項７】 請求項５または請求項６において、幾何
   変換を行なうときのグラフィックス属性設定コマンド等
   のプロセッサ（ＣＳ）とプロセッサ（ＧＳ）間のデータ
   の転送において順序制御が必要なグラフィックスコマン
   ドはプロセッサ（ＣＳ）がプロセッサ（ＧＳ）の処理の
   同期を取って処理を行なう手段を設けたことを特徴とす
   るグラフィックス並列処理装置。
8. 【請求項８】 請求項５乃至請求項７のいずれかにおい
   て、グラフィックス属性設定コマンドが発行されたとき
   にはその属性値を現在値と比較する手段と、異なった属
   性値の時のみそのコマンド処理を行なう手段を設けたこ
   とをことを特徴とするグラフィックス並列処理装置。
9. 【請求項９】 グラフィックス処理の中の幾何変換を行
   なう汎用プロセッサと、グラフィックス処理の中で１画
   素づつ画素を生成するレンダリング処理を行なうレンダ
   リングプロセッサ部と、レンダリングプロセッサのレジ
   スタを複数マッピングし更に不要なデータも同様にマッ
   ピングする手段と、汎用プロセッサからレンダリングプ
   ロセッサへバースト転送でデータを送る手段とを備える
   ことを特徴とするグラフィックスシステム。
10. 【請求項１０】 グラフィックス処理の中の幾何変換を
    行なう汎用プロセッサと、グラフィックス処理の中で１
    画素づつ画素を生成するレンダリング処理を行なうレン
    ダリングプロセッサ及びレンダリングコマンドを蓄えて
    おくＦＩＦＯからなるレンダリングプロセッサ部と、レ
    ンダリングプロセッサに到達すると要求元のプロセスに
    割込を返すアイドル要求コマンド発行手段と、レンダリ
    ングプロセッサの待ち時間に他のプロセスを実行する手
    段とを設けたことを特徴とするグラフィックスシステ
    ム。