JP2005514711A - ゾーン・レンダリングのための効率的なグラフィックス状態管理 - Google Patents

Abstract

本発明は、グラフィックイメージを生成するタイルベースのゾーン・レンダリングの方法によって使用されるハードウェア状態ビニング・ロジックによるグラフィック状態のトラッキングとグラフィック状態の管理のためのメカニズムを提供する。動的な状態変数の現在値のみがハードウェア中に維持される。動的な状態は、複数のプリミティブ間で変化する可能性が有ると考えられる状態変数を含むが、これに制限されない。動的な状態変数の設定は、サブグループへと細分化される。各状態グループは、トラッキング・ビットのビン毎のアレイに対応付けられる。状態変化に遭遇する場合は常に、関連する状態グループに対応するトラッキング・ビットが、全てのビンに対して設定される。ビンにプリミティブを配置するのに先立って、該ビンに対応するトラッキング・ビットが調べられ、設定済トラッキング・ビットに対応する現在の状態が、プリミティブの前にビンへと挿入される。その後、そのビンに関するトラッキング・ビットがクリアーされる。

Description

本発明は、広義にはグラフィック・システムに関し、より詳細には、グラフィック・レンダリング・システムに関する。

コンピュータグラフィック・システムは、２次元のビデオ表示装置・スクリーンにオブジェクトの図形表現を表示するために一般に使用される。現在のコンピュータグラフィック・システムは高度に詳細な描写を提供し、様々なアプリケーションにおいて使用される。典型的なコンピュータグラフィック・システムにおいて、表示画面上で表わされるオブジェクトはグラフィック・プリミティブへと分類される。プリミティブは、グラフィック表示装置の基本的な構成要素であり、点、線、ベクトル、および三角形や四角形のような多角形を備えていて良い。典型的には、表示画面上で表わされている１つ以上のオブジェクトの視界を表わすグラフィック・プリミティブをレンダリング即ち描写するために、ハードウェア／ソフトウェアスキームが実施される。

レンダリングされる三次元のオブジェクトのプリミティブは、プリミティブ・データに関してホストコンピュータによって定義される。例えば、プリミティブが三角形である場合、ホストコンピュータは、各頂点の赤、緑、青（ＲＧＢ）の色の値と同様に、頂点のＸ、ＹおよびＺ座標の点に関してプリミティブを定義して良い。その他の追加のプリミティブ・データが、特定のアプリケーションにおいて使用されても良い。

イメージ・レンダリングは、高級なオブジェクトベースの記述を、ある表示装置上の表示装置用のグラフィックイメージへと変換する事である。例えば、イメージ・レンダリングの動作は、三次元のオブジェクトまたはシーンの数学的モデルをビットマップ方式のイメージへと変換する際に生じる。イメージ・レンダリングの別の例として、ＨＴＭＬドキュメントをコンピュータ・モニタ上に表示されるイメージへの変換が挙げられる。典型的には、グラフィック・レンダリング・エンジンと称されるハードウェアデバイスはこれらの図形処理タスクを実行する。通常、グラフィック・レンダリング・エンジンは、グラフィック出力装置にその後出力されるバッファに或るシーンをレンダリングするが、幾つかのレンダリング・エンジンは、出力装置にこれらの２次元の出力を直接描く事が出来る。このグラフィック・レンダリング・エンジンは、プリミティブ・データを書き込み、各プリミティブ、および各画素のＲＧＢ色調の値を表す表示画面画素を計算する。

グラフィック・レンダリング・システム（あるいはサブシステム）は、本願明細書においては、アプリケーション・プログラムとグラフィック出力装置との間の全ての処理レベルについて言及している。グラフィック・エンジンは、ゾーン・レンダリングを含む１つ以上のレンダリング・モードを提供して良い。ゾーン・レンダリングは、レンダー・キャッシュを最適に用いる事によって、全体的な３Ｄレンダリングの性能を向上させる事を試み、その結果、画素の色調およびデプス・メモリ読書きボトルネックが低減される。ゾーン・レンダリングにおいて、スクリーンは多くのゾーンへと細分化され、各サブ・イメージをレンダリングするのに必要な命令を設定するプリミティブおよび状態の全部を保持するために使用されるゾーン毎の命令ビンが生成される。プリミティブがゾーンと交差する（または、交差する可能性がある）場合は常に、このプリミティブ命令が該ゾーンのためのビンに配置される。幾つかのプリミティブは、複数のゾーンと交差し得、その場合は、プリミティブ命令は、対応するビン中において複製される。このプロセスは、全シーンがビン中でソートされるまで継続される。プリミティブによって交差した各ゾーン用のビンを構築する第１パスに続いて、第２のゾーン毎のレンダリング・パスが実行される。具体的には、最終イメージを生成するために、全てのゾーンのためのビンがレンダリングされる。通常、各シーンは一度に１つのゾーンずつレンダリングされる。

ゾーン・レンダリングのようなタイル・レンダリング・アーキテクチャを実施するために、各像空間ゾーン（つまりビン）内において正確なグラフィックス・レンダリング状態変数を維持する事が非常に重要である、そのために、ビニング段階中にプリミティブが遭遇した時に存在したグラフィック状態によって各ビンのプリミティブを（レンダリング段階において）連続的にレンダリングする事が必要である。

プリミティブをこれらの適切なグラフィックス状態に関連させる１つの従来の方法として、遭遇した全てのグラフィックス状態のコピーを別々に維持し、プリミティブをレンダリングするために後に使用する特定の状態を識別する幾つかのタグ（つまりインデックス）と各プリミティブとを対応付ける。しかしながら、状態テーブルを個別に維持する事は複雑であり、（恐らくは各プリミティブ間における）状態の設定を完全にロードするには（メモリ・フットプリント、待ち時間および帯域幅に要する）コストが掛かるので、低コストかつ帯域幅が抑制された（例えば、統合された）グラフィックスシステムを実現する事は難しい。

従って、安価でかつより効率的なゾーン・レンダリング用グラフィック状態管理のための方法、装置、およびシステムが必要とされている。

本発明は、グラフィックイメージを生成するタイルベースのゾーン・レンダリング方法において使用するためのハードウェア状態ビニング・ロジックによってグラフィックス状態をトラッキング・管理するための経済的なメカニズムを提供する。本発明の実施形態において、動的な状態変数の現在値のみがハードウェア中に維持される。一実施形態において、動的な状態変数は、複数のプリミティブ間で変化すると考えられる変数を含むが、これに制限されるものでは無い。典型的な複数のシーンを通して一定または略一定である状態変数は通常は除外される。動的な状態変数のセットはサブグループへ細分される。各状態サブグループは、トラッキング・ビットのビン毎のアレイに対応付けられる。ビニング段階中に状態変化に遭遇する場合は常に、関連する状態グループに対応するトラッキング・ビットが、全てのビンに対して設定される。ビン中にプリミティブを配置するのに先立って、該ビンに対応するトラッキング・ビットが調べられ、設定済みトラッキング・ビットに対応する現在の状態が、プリミティブよりも前に該ビンに挿入される。その後、該ビンに対応するトラッキング・ビットがクリアーされる。

以下に詳述されるように、本発明は、ドライバ・ソフトウエア中の状態変化をトラッキングする必要性が無いという点においてゾーン・レンダリングのサポートを最適化し、従って、性能の向上とドライバの複雑さの低減につながる。任意の状態変数の変化をもたらす手段を提供する一方で動的な状態変数の（単一インスタンスの）オンチップ・ストレージのみをサポートし、ビットをトラッキングするためのオンチップでビン毎のストレージを例えば１つのビンに対して４ビットに削減することによって、ビニング状態管理のコストが最小化される。典型的な実施形態において、ビン毎のオンチップ・ストレージは４つのトラッキング・ビットのみに削減される。さらに、（ａ）サブグループ内の連続的な状態変化を縮小させることによって、（ｂ）要求されていないテクスチャー・ブレンド段階およびテクスチャー・マップ状態データの更新を省略する事によって、および（ｃ）状態サブグループ変化のために最適化された（および待ち時間の小さい）命令を提供することによって、状態変化帯域幅およびフットプリント用の要件が低減される。さらに、間接的に格納された状態配列および（または）キャッシュを管理するコストおよび複雑さが低減される。

この詳細な説明において、多数の特定の詳細が、本発明についての完全な理解を提供するために記載される。しかしながら、本発明がこれらの特定の詳細を用いる事無く実施され得る事が、当業者にとって理解されるであろう。また、公知の方法、手順、コンポーネントおよび回路は、本発明を不明瞭にしないような方法で詳細に記載される。

後述の詳細な説明の一部分は、コンピュータ内のデータ・ビット即ち二進信号に対する演算のアルゴリズムおよび記号による表示として記述される。これらのアルゴリズムの記述および描写は、或る当業者が他の当業者にこれらの作業の手順を伝達するために使用される手段である。１つのアルゴリズムが本願明細書に記載され、通常は、本アルゴリズムは所望の結果に結びつくステップの首尾一貫したシーケンスであると見做される。ステップは、物理量の物理的な操作を含んでいる。これらの量は、格納、転送、組合せ、比較、そして操作が可能である電気的または磁気的信号の形式を通常は採るが、これに制限されない。これらの信号をビット、値、要素、シンボル、文字、項、数または同種のものとして参照する事は、主に一般的慣習の理由のために簡便であり得ると知られている。しかしながら、これらおよび同様の語句は、適切な物理量に対応していて、これらの数量に適用される便利な標識に過ぎないということを理解するべきである。後述の議論から明らかなものとして以下特定に記載されない限り、本願明細書全体を通して、「処理」あるいは「計算」あるいは「決定」または同種の語句を用いた議論は、コンピューティング・システムのレジスタおよび（または）メモリ内の物理（電子）量で表されたデータを、他のコンピューティング・システムのメモリ、レジスタ、または他の情報格納・伝送または表示装置内の物理量として同様に示されるデータへと変換するコンピュータまたはコンピューティング・システムあるいは同様の電子計算デバイスの動作および処理の事を指す。

本発明の実施形態は、ハードウェアかソフトウェア、あるいは双方の組合せによって実施されて良い。しかしながら、本発明の実施形態は、少なくとも１つのプロセッサ、（揮発性および不揮発性メモリおよび（または）記憶素子を備える）データ記憶システム、少なくとも１つの入力装置および少なくとも１つの出力装置を備えるプログラマブル・システム上で実行されるコンピュータ・プログラムとして実施されて良い。本願明細書に記載された記述された機能を行ない、かつ出力情報を生成するために、プログラムコードが入力データに供給されて良い。出力情報が、公知の方法で１つ以上の出力装置に供給されて良い。このアプリケーションの目的のために、処理システムは、例えばデジタル・シグナル・プロセッサ（ＤＳＰ）、マイクロ・コントローラ、特定用途向けＩＣ（ＡＳＩＣ）あるいはマイクロプロセッサのようなプロセッサを備える任意のシステムを含んでいる。

プログラムは、処理システムと通信するために、高級プロシージャー型またはオブジェクト指向プログラミング言語で実施されて良い。もし望まれれば、プログラムは、アセンブリまたは機械語で実施されても良い。実際、本発明は任意の特定のプログラム言語の範囲に制限されていない。いずれの場合においても、言語はコンパイル言語であっても良いし、インタープリター言語であっても良い。

プログラムは、記憶媒体あるいはデバイスがここに記述された手順を行うために処理システムによって読み込まれる場合に、処理システムを構成し操作するために汎用または専用プログラマブル処理システムによって判読可能な記憶媒体あるいはデバイス（例えばハードディスク・ドライブ、フロッピーディスクドライブ、読み取り専用メモリ（ＲＯＭ）、ＣＤ−ＲＯＭデバイス、フラッシュ・メモリ・デバイス、ディジタル他用途ディスク（ＤＶＤ）あるいは他の記憶装置）上に格納されて良い。本発明の実施形態は、処理システムとともに使用されるように構成された機械可読記憶媒体として実施されると見做されて良く、記憶媒体は、本願明細書に記載される機能を実行する特定の方法で処理システムを作動させるように構成される。

このような種類の処理システムの一例が、図１に示される。システム１００の一例は、例えば本願明細書に記載された実施形態のような本発明における方法の処理を実行するために使用されてもよい。サンプル・システム１００は、インテル株式会社から入手可能なマイクロプロセッサに基づいた処理システムを示すが、他のシステム（他のマイクロプロセッサ、エンジニアリングワークステーション、セットトップ・ボックスおよびその他同種のものを備えるパーソナルコンピュータ（ＰＣ）を含む）が使用されても良い。一実施形態において、システム１００は、例えばマイクロソフト株式会社から入手可能なウィンドウズ（登録商標）オペレーティングシステムの或るバージョンを実行していて良いが、他のＯＳおよびＧＵＩが使用されても良い。

図１は、本発明の一実施形態におけるシステム１００のブロック線図である。コンピュータ・システム１００は、中央処理装置１０２と、グラフィック装置１０６を含むグラフィックおよびメモリ・コントローラ１０４と、メモリ１０８と、表示装置１１４とを備える。プロセッサ１０２はデータ信号を処理し、複雑命令セットコンピュータ（ＣＩＳＣ）マイクロプロセッサ、限定命令セット計算機（ＲＩＳＣ）マイクロプロセッサ、超長命令語（ＶＬＩＭ）マイクロプロセッサ、命令セットの組合せを実施するプロセスあるいはデジタル・シグナル・プロセッサのような他のプロセッサ・デバイスであって良い。プロセッサ１０２は、システム１００においてプロセッサ１０２と他のコンポーネントとの間のデータ信号を伝送する共通バス１１２に接続されて良い。図１は例示の目的のために描かれているに過ぎない。本発明は、離散的グラフィック装置を備える構成において使用されても良い。

プロセッサ１０２は、本願明細書に記載されるようなデータを操作するべくメモリ１０８あるいはグラフィックおよびメモリ・コントローラ１０４と通信するために、共通バス１１２上に信号を出力する。プロセッサ１０２は、メモリ１０８から得るソフトウェア命令に応じてこのような信号を出力する。メモリ１０８は、動的ランダムアクセス記憶装置（ＤＲＡＭ）デバイス、静的ランダムアクセス記憶装置（ＳＲＡＭ）デバイスあるいは他のメモリ素子であって良い。メモリ１０８は、プロセッサ１０２、グラフィック装置１０６あるいは他の或るデバイスによって実行され得るデータ信号によって表わされる命令および（または）データを格納して良い。命令および（または）データは、本発明の任意のおよび（または）全ての技術を実行するプログラムを備えて良い。メモリ１０８は、ソフトウェアおよび（または）データを更に含んで良い。必ずしも必要と言う訳では無いが、アクセスの局所性の利点によって、グラフィック装置１０６によるメモリーアクセスの速度を向上させるためにキャッシュメモリ１１０が使用されてもよい。

幾つかの実施形態において、グラフィック装置１０６は、イメージをレンダリングするために必要になったメモリ集約的なタスクの多くをプロセッサ１０２からオフロードして良い。グラフィック装置１０６は信号を処理し、例えば複雑命令セットコンピュータ（ＣＩＳＣ）マイクロプロセッサ、限定命令セット計算機（ＲＩＳＣ）マイクロプロセッサ、超長命令語（ＶＬＩＭ）マイクロプロセッサ、命令セットの組合せを実施するプロセスあるいはデジタル・シグナル・プロセッサのような他のプロセッサ・デバイスであって良い。グラフィック装置１０６は、レンダー・キャッシュ１１０および表示装置１１４を含むシステム１００におけるグラフィック装置１０６と他のコンポーネントとの間のデータ信号を伝送する共通バス１１２に接続されて良い。グラフィック装置１０６は、表示装置１１４の特定の画素に特定の属性（例えば色調）の書き込み等を行ない、表示装置１１４上に複雑なプリミティブを描くレンダリング・ハードウェアを備える。グラフィックコントローラ１０４によってレンダリングされて処理されたイメージを表示するために、グラフィックコントローラ１０４によってレンダリングされて処理されたイメージを表示するために、グラフィックおよびメモリ・コントローラ１０４は表示装置１１４と通信する。表示装置１１４はコンピュータ・モニタ、テレビジョンセット、平面パネルディスプレーあるいは他の適切な表示装置を含んで良い。

メモリ１０８は、表示のためにグラフィック・プリミティブのイメージを構築するために、１つ以上のレンダリング・プログラムを備え得るホスト・オペレーティング・システムを格納する。システム１００は、少なくともホスト・レンダリング・プログラムによってハンドリングされるグラフィック・プリミティブの或る一部分をレンダリングする性能を向上するために、カスタマイズされたハードウェア論理メカニズムあるいはコプロセッサを使用するグラフィック・アクセラレーターのようなグラフィック装置１０６を含んでいる。ホスト・オペレーティング・システム・プログラムおよびそのホスト・グラフィック適用業務プログラム・インターフェース（ＡＰＩ）は、ドライバ・プログラムによってグラフィック装置１０６を制御する。

図２および図３を参照して、ゾーン・レンダリング・システム１２０上で実施される様々なグラフィック・オブジェクトの実施形態１６０（例えばジオメトリープリミティブ（つまり三角形や線分）１６２）が示される。ゾーン・レンダリングにおいて、スクリーンは、通常は複数の長方形状のゾーン・アレイ１６４へ細分されるが、他の幾何学的な形状が代わりに使用されても良い。各ゾーン１６４は、１つのビンに対応付けられる。各ビン１２８は、不連続物理メモリページ内に格納された一連のコマンド・バッファ１３４を含んでいる。ビン１２８は、このように一続きの独立した物理ページとしてむしろ実施される。

プリミティブ１６２がゾーン１６４と交差する場合、対応するプリミティブ命令は、交差したゾーン１６４に対応したビン１２８に配置される。各サブイメージのレンダリング用に必要であり、かつ各プリミティブ１６２のスクリーンスペースの範囲とゾーン１６４のアレイとの比較によって生成されるプリミティブ命令および状態設定命令を保持するために、ゾーン毎の命令ビン１２８が用いられる。従って、プリミティブ１６２が受信される際に、どのゾーン１６４が各プリミティブ１６２と交差するかを決定し、ゾーン１６４のそれぞれに対応したビン１２８に対してプリミティブ命令を複製する。ゾーン１６４へプリミティブ１４２（またそれらの属性）を割り振る過程は、ビニング（ｂｉｎｎｉｎｇ）と称される。「ビン」１２８は、各ゾーンに対して使用される理論バッファの事であり、通常は、ビン１２８は一連の命令バッチ・バッファ１３４として実現される。ビニングは、どのプリミティブ１６２がどの特定のゾーン１６４に存在するかを決定するための必要な計算を実行し、これは専用ハードウェアおよび（または）ソフトウェアの実施例によって行う事が出来る。１つの典型的な実施例において、ドライバ１２２は、プリミティブ１６２が交差する各ゾーン１６４用のグラフィック・ビニング・エンジン１２６によって解析される１セットの命令を書き込む。

幾つかのプリミティブ１６２は、２つ以上のゾーン１６４と交差し得、プリミティブ命令は複数の交差ゾーン１６４に対応する複数のビン１２８において複製される。例えば、図３の中で描かれた稲妻は９つのゾーン１６４と交差する。全シーンがビン１２８中においてソートされるまで本プロセスは継続される。

一旦、プリミティブ１６２が格納され、コマンド構造が完了した後、第２パスは、一度に１ゾーン１６４のシーンをレンダリングするように為される。プリミティブ１６２によって交差した各ゾーン１６４のためにビンを構築する第１パスに続いて、ゾーン毎の第２のレンダリング・パスが実行される。具体的には、全てのゾーン１６４用のビン１２８が最終イメージを生成するためにレンダリングされる際に、一度につき１つのゾーン１６４のシーンがレンダリングされる。ゾーン１６４のレンダリングされる順番は重要では無い。次のゾーン１６４がレンダリングされる前に、特定のゾーン１６４内の画素に触れるプリミティブ１６２に対応するビン１２８が全てレンダリングされる。単一のプリミティブ１６２は多数のゾーン１６４と交差し得、これによって、多数の複製が必要とされ得る。その結果、複数のゾーン１６４と交差するプリミティブ１６２は複数回（つまり、交差するゾーン１６４の数だけ）レンダリングされる。

レンダリング性能は、レンダー・キャッシュ１１０と心合しているゾーン１６４へと分割されているプリミティブ１６２の結果として向上する。グラフィック装置１０６は、一度にスクリーン上の小さい部分（つまりゾーン１６４）のみで動作するので、レンダー・キャッシュ１１０の中に全ゾーン１６４のためのフレームバッファーコンテンツを保持する事が出来る。ゾーン１６４の寸法は、通常はレンダー・キャッシュ１１０のサイズおよび編成に合わせられた定値である。このメカニズムによって、レンダー・キャッシュ１１０は最適な利益――ゾーン１６４の空間干渉性を利用する事によるキャッシュデータの再利用の最大化――が提供される。ゾーン・レンダリング・モードの使用を通じて、一度に１ゾーン１６４の最終イメージを生成するために実行される必要のあるカラー・メモリ書込みが最少化され、カラー・メモリ読み込みおよびデプス・メモリ読み込み／書き出しが最小限にされるか回避する事が出来る。従って、レンダー・キャッシュ１１０を使用する事によってメモリ・トラフィックが著しく低減され、次のプリミティブへと継続する前に各プリミティブを完全に引き出す従来のレンダラーに関する性能を向上させる。

図２を参照して、典型的な実施例において、シーン入力リスト１２４と称されるグラフィック・プリミティブおよび状態設定命令ストリームは、最初にグラフィック・ビニング・エンジン１２６に対応するグラフィック・ビニング・エンジン・リング・バッファ１２５に入力される。シーン入力リスト１２４は、適用業務プログラム・インターフェースによって受信されるような単一で一時的な配列のシーン記述であって良い。グラフィック・ビニング・エンジン１２６は、ハードウエア・ビニング・エンジン（ＨＷＢ）１２６として通常は実施される。当業者は、ソフトウェアのビナー、またはソフトウェアおよびハードウェアのビナーが同様に使用され得る事を認識するであろう。グラフィック・ビニング・エンジン１２６はシーン入力リスト１２４を解析し、各プリミティブ１６２がどのゾーン１６４と交差するかを決定する。

前述されたように、ゾーン１６４はビン１２８と対応付けられている。グラフィック・ビニング・エンジン１２６は、各プリミティブ１６２のスクリーンスペース範囲をゾーン１６４のアレイと比較し、対応するビン１２８へ対応するプリミティブ・コマンドを複製する。図５を参照して詳述されるように、ビン１２８は、不連続物理メモリページ内に通常は格納される一連のコマンド・バッファ１３４として構成される。ビン・リストは、各ビン１３２を含むバッファ１３４のリストである。ページは、ＢＭＰ１４０に最初に割り振られる。ビン・ポインタ・リスト１３０はこのページのページ数によって初期化され、ビン・リスト１３２に書き込みポインタを格納する。

グラフィック・ビニング・エンジン１２６は、シーン入力リスト１２４に含まれる対応する状態設定命令を解析する事によって、現在のグラフィック状態を維持する。任意のビン１２８にプリミティブ・コマンドを配置するのに先立って、グラフィック・ビニング・エンジン１２６は、通常は任意の要求された状態を設定する命令によってビン１２８のプリミティブ・コマンドを優先する。

シーン入力リスト１２４が完全に解析された後、対応するビン（つまりビン０、ビン１、ビンｎ−１）は、シーンをレンダリングするためにグラフィック・レンダリング・エンジン１３６によって使用される準備が完了する。以下詳述されるように、グラフィック・ビニング・エンジン１２６に保留シーン・カウンタ１４８中のレジスタを１個分インクリメントさせるため、およびビニングされたシーンのレンダリングを開始させるために、これらの命令はシーン入力リスト１２４の終端部に含まれている。例えば、グラフィック・ビニング・エンジン１２６は、レンダリング命令を、パス１５６を経由して、グラフィック・レンダリング・エンジン１３６に対応するグラフィック・レンダリング・エンジン・リング・バッファ１５７に送信する。

図４は、現在の動的状態サブグループ１７２およびビンごとのトラッキング・ビット１７４の実施形態１７０のブロック線図を示す。動的状態を複数のサブグループ１７２へ細分化することによって、トラッキングのための一定のレベルの細分性を提供し、動的な状態変数に対して変化を与える。典型的な実施形態において、動的な状態変数のセットは、４つのサブグループ１７２へ細分される。本願明細書において示され議論される構成は４つのサブグループ１７２にとって有利であるが、本発明は、任意の数の様態によって構成される任意の数のサブグループ１７２で利用する事が出来ると言う事を当業者は認識するであろう。

複数のトラッキング・ビン１７４が各ビン１２８（例えばビン０、ビン１、ビン２、・・・ビンｎ）と対応付けられ、各ビン・ビットは特定の動的状態サブグループ１７２と対応付けられる。特定のビン１２８用のトラッキング・ビット１７４が「設定された」場合、これは、このサブグループ１７２（および、例えばビンｎといった特定のビン１２８）中の或る状態変数が、プリミティブ１６２が最後にビン１２８を出力してから変化したと言う事を示している。反対に、トラッキング・ビット１７４が「クリアーされた」場合、ビン１２８に対応した動的状態サブグループ１７２は、プリミティブ１６２が最後にビン１２８を出力してから変化していないと言う事を示している。典型的な実施例において、ビット毎の４ビット「トラッキング・ビット」ベクトル１７４は、４つの状態グループ１７２の変化をトラッキングするために用いられる。「テクスチャー・マップ」、「テクスチャー・ブレンド」、「基礎状態」および「スロー状態」サブグループのそれぞれが、通常５１２または１０２４個のビンを含む。５１２個のビンの場合、合計２Ｋビットとなる（つまり、４ビット・ベクトル／ビン×５１２ビン）。１０２４個のビンの場合で、合計４Ｋビットとなる（つまり、４ビット・ベクトル／ビン×１０２４ビン）。

初めに、動的な状態の完全なコンプリメントによって各ビン１２８を初期化するために、全てのトラッキング・ビット１７４が「設定」される。具体的には、ビン１２８にプリミティブ１６２を配置するのに先立って、ビン１２８に対応するトラッキング・ビット１７４が調べられ、設定されたトラッキング・ビット１７４に対応する現在の状態が、プリミティブ１６２の前にビン１２８に挿入される。その後、そのビン１２８用のトラッキング・ビット１７４がクリアーされる。典型的な実施形態において、状態ビット１７４のうちの多くは、それほど頻繁には変化しない。しかしながら、三角形の正確な状態がラスター化中に維持する事が出来るように、時間とともに変化したビット１７４のうちの任意のもの、またはその大半が識別され、ビン１２８に出力されなければならない。

具体的に、図４に示される状態グループ１７２は次のものを含んでいる。

（１）「基礎状態」サブグループ１７６――基礎状態トラッキング・ビット・アレイに関するこの状態変数は、頂点バッファ、頂点フォーマット、セットアップ、テクセル・ストリームおよび画素パイプライン状態変数を含むが、これらに制限されない。通常、これらの状態変数は、固定されたワードのシーケンスへ配列される。１つの特定の実施形態において、基礎状態変数に対する任意の変更のためには、要求されるビン１２８に対して全てのワードが出力される必要があるが、他の構成が同様に用いられ得るという事を当業者は認識するであろう。他の実施形態において、全てのビン１２８または「オープン」ビン１２８のより小さなサブセットのいずれかのための基礎状態変化の微細なトラッキングが実施されても良い。

（２）「テクスチャー・マップ」サブグループ１７８――テクスチャー・マップ状態トラッキング・ビット・アレイに関するこの状態変数は、ほとんどのテクスチャー・マップ・パラメタ、立方体マップ・フェース・イネーブルおよびテクスチャー・フィルタ・パラメタを含むが、これらに制限されない。この状態変数は、命令の一部としてグラフィックス・ビニング・エンジン１２６によって出力される。特定のビン１２８のためのテクスチャー・マップ状態トラッキング・ビットが設定されたと判った場合、グラフィックス・ビニング・エンジン１２６は現在のコンテクスト設定によって現在要求されているテクスチャー・マップに関するワードのみを出力する。どのテクセル・ストリームが入力として要求されているのかを確認しながら許可されたテクスチャー・ブレンド段階を調べ、続いて、どのテクスチャー・マップがこれらの要求されたテクセル・ストリームと対応しているかを調べる事によって、「現在用いられている」マップが決定される。

（３）「テクスチャー・ブレンド」サブグループ１８０――テクスチャー・ブレンド状態トラッキング・ビット・アレイに関するこの状態変数は、テクスチャー・マップ・ブレンド段階を制御するために用いられる状態変数を含むが、これに制限されない。典型的な実施例において、状態変数は、１〜４のテクスチャー・マップ・ブレンド段階ユニットの制御のために、グローバル制御およびテクスチャー・ブレンド・カラー、アルファ、制御段階パラメタを含んでいる。これらの状態変数は、命令の一部としてグラフィックス・ビニング・エンジン１２６によって出力される。特定のビン１２８のためのテクスチャー・ブレンド状態トラッキング・ビットが設定されたと判った場合、グラフィックス・ビニング・エンジン１２６は、「有効化されたテクスチャー・ブレンド段階の数」の現在の設定によって要求されるワードのみを出力する。

（４）「スロー状態」サブグループ１８２――スロー状態トラッキング・ビット・アレイに関するこの状態変数は、「スロー状態ポインタ」である。スロー状態ポインタは、基礎、テクスチャー・ブレンド、およびテクスチャー・マップ状態サブグループ１７６、１７８および１８０のような他の状態サブグループに含まれない全ての状態ポインタを間接的に制御する。典型的な実施形態において、では、低位の状態変化および（または）それほど頻繁に変化しない命令は、スロー状態バッファ１６６に配置される。また、これらのポインタは、命令１６７によってスロー状態バッファ１６６のみに引き渡される。

「スロー状態」グループは、残りのパイプライン化されていない（または少数の低周波数でパイプライン化された）状態変数を含んでいる。「スロー状態」状態変数に対する変更は、グラフィックス・ビニング・エンジン１２６に直接送信されない。むしろ、図２に示されるように、これらの変数の初期値＋デルタ状態変化を含むスロー状態バッファ１６６は、全ての「スロー」状態変数の現在の状態を定義するために十分である。これによって、スロー状態ポインタのみをグラフィックス・ビニング・エンジン１２６に送信すれば良い。スロー状態ポインタへの変更は必要に応じてビン１２８に配置され、スロー状態変数を更新するために、レンダリング中にスロー状態バッファ１６６の必要な読み取りを開始する。前の値とレンダリングされているページの終端との間に新しい値がある場合にのみ、グラフィックス・レンダリング・エンジン１３６は、スロー状態「ポインタ」の先回と今回との間のバッファ付き命令を実行する。そうで無い場合は、グラフィックス・レンダリング・エンジン１３６は、新しいスロー状態ポインタによって指定されたページの先頭から、新しいスロー状態ポインタによって指定されたＤｗｏｒｄまで（但し、該Ｄｗｏｒｄは含まない）の命令を実行する。これによって、全てのスロー状態変数が初期値へと設定され、そして、新しいスロー状態ポインタによって指定されたＤｗｏｒｄまで（但し、該Ｄｗｏｒｄは含まない）のデルタ状態変化が続いて適用される。

具体的に、シーン入力リスト１２４と称されるグラフィックスプリミティブおよび状態設定命令ストリームは、グラフィックス・ビニング・エンジン１２６に対応するグラフィックス・ビニング・エンジン・リング・バッファ１２５に先ず適用される。グラフィックス・ビニング・エンジン１２６はシーン入力リスト１２４を解析し、どのゾーン１６４が各個々プリミティブ１６２と交差するかを決定する。

グラフィックス・ビニング・エンジン１２６は、シーン入力リスト１２４に含まれる対応する状態設定命令の解析によって現在のグラフィックス状態を維持する。任意のビン１２８にプリミティブ・コマンドを配置するのに先立って、グラフィックス・ビニング・エンジン１２６は、状態設定命令１６７を備えたビン１２８中のプリミティブ・コマンドを実行する。

ビン０用のスロー状態トラッキング・ビット１８３が変化を示す場合、スロー状態「ポインタ」がビン１２８に出力される。その後、スロー状態トラッキング・ビット１８３がクリアーされる。スロー状態トラッキング・ビット１８３が変化を示さない場合、スロー状態ポインタはビン０に出力されない。

スロー状態バッファ１６６は、スロー状態変数のための初期値およびデルタ状態変化を格納する。これらのスロー状態バッファ１６６のうちの１つに対する単一のポインタは、全ての「スロー」状態変数の現在の状態を定義するのに十分である。スロー状態バッファ１６６は、状態メモリ１０８あるいは専用のメモリのいずれかに位置して良い。典型的な実施形態において、低位の状態変化および（または）頻繁に変更されない命令は、スロー状態バッファ１６６に配置される。また、ビナーポインタは命令１６７によってのみスロー状態バッファへ引き渡される。一旦全てのプリミティブとスロー状態ポインタを含む状態命令がビニングされると、シーンの１ゾーン１６４を一回でレンダリングするために第２パスが実行される。最終イメージを生成するためにビン１２８がレンダリングされ、各シーンにおいて、一度に１つのゾーン１６４がレンダリングされる。レンダリング中に、グラフィック・レンダリング・エンジン１３６は、スロー状態変数を更新するために、ビニングされたスロー状態ポインタに基づいてスロー状態バッファ１６６の必要な読み取りを開始する。グラフィックス・レンダリング・エンジン１３６は、前回のスロー状態「ポインタ」と新しいスロー状態「ポインタ」との間のバッファ付き命令を実行する。

図５は、ビン１２８中のプリミティブ１６２に対応するプリミティブ命令を配置するのに先立って任意の必要な状態変化を出力するための（ステップ１９２〜２０８）、およびデルタ状態変化を調べて状態およびビン毎のトラッキング・ビット１７４を更新するための（ステップ２１２〜２２２）実施形態１９０を示すフローチャートである。この最適化によって、不必要な状態の複製が最小限にされる。

具体的に、特定のビン１２８にプリミティブ命令を配置するのに先立って、グラフィックス・ビニング・エンジン１２６は、少なくともレンダリング段階においてプリミティブ１６２が正確にレンダリングされ得る点までは該特定のビン１２８の状態が一定である事を保証する。これは、ビン１２８へプリミティブ命令を出力するのに先立って、現在使用されていない状態を出力する必要は無いという事を意味する。例えば、無効化されたテクスチャー・ブレンド状態や使用されていないテクスチャー・マップ設定がビン１２８に出力される必要は無い。

プリミティブ１６２に遭遇する場合（ステップ１９２）、本発明は、どのゾーン１６４がプリミティブ１６２と交差するかを決定する（ステップ１９４）。交差したゾーン１６４に対応する各ビン１２８については（ステップ１９６）、各サブグループ・トラッキング・ビット１７４が調べられる（ステップ１９８）。特定のサブグループ用のトラッキング・ビット１７４が設定される場合（ステップ１９９）、この特定のサブグループ１７２の現在値がビン１２８に出力される（ステップ２００）。トラッキング・ビット１７４に対応する関連した状態サブグループ１７２が「使用済み」となる場合、トラッキング・ビット１７４は「設定された」と見做される。

例えば、先ず、基礎状態サブグループ１７６用のサブグループ・トラッキング・ビット１７７は、ビン０のために調べられて良い。その後、その特定のビン１２８用のサブグループ・トラッキング・ビット１７４がクリアーされる（ステップ２０２）。または、特定のサブグループのためのトラッキング・ビットが設定されない場合、特定のサブグループ１７２の現在値はビン１２８に出力されない（ステップ２０１）。

その後、ビン１２８用の次のサブグループ・トラッキング・ビット１７４が調べられる。また、ステップ１９８、２００および２０２が、ビン１２８中の各ビット１７４のために繰り返される（ステップ２０４）。例えば、ビン０のためのテクスチャー・マップ・サブグループ１７８用のトラッキング・ビット１７９が次に検査されて良い。

サブグループ１７２に対応する全てのトラッキング・ビット１７４が特定のビン１２８のために検査された後に、プリミティブ命令がビン１２８に出力される（ステップ２０６）。その後、プリミティブ１６２によって交差するゾーン１６４に対応する次のビン１２８のためのサブグループ１７２のトラッキング・ビット１７４が調べられる（ステップ２０８）。

例えば、図４を参照して、ビン０に対応する基礎状態トラッキング・ビット１７７が変化を示す場合、基礎状態サブグループ１７６の現在値はビン０に出力される。その後、基礎状態トラッキング・ビット１７７はクリアーされる。基礎状態トラッキング・ビット１７７が変化を示さない場合、値はビン０に出力されない。

その後、次のサブグループ１７２用のトラッキング・ビット１７４が調べられる。例えば、ビン０用のテクスチャー・マップ状態トラッキング・ビット１７９が変化を示す場合、テクスチャー・マップ状態１７８の現在値が出力される。その後、ビット１７９をトラッキングするテクスチャー・マップ状態がクリアーされる。ビット１７９をトラッキングするテクスチャー・マップ状態が変化を示さない場合、値はビン０に出力されない。

同様に、ビン０用のテクスチャー・ブレンド状態トラッキング・ビット１８１が変化を示す場合、テクスチャー・ブレンド状態１８０の現在値が出力される。その後、テクスチャー・ブレンド状態トラッキング・ビット１８１がクリアーされる。テクスチャー・マップ状態トラッキング・ビット１７９が変化を示さない場合、値はビン０に出力されない。

ビン０用のスロー状態トラッキング・ビット１８３が変化を示す場合、スロー状態ポインタがビン０に出力される。その後、スロー状態トラッキング・ビット１８３がクリアーされる。スロー状態トラッキング・ビット１８３が変化を示さない場合、スロー状態ポインタはビン０に出力されない。

トラッキング・ビット１７４は、このように古くなったリソースが使用される可能性を取り除く。例えば、（ａ）もし現在未使用のテクスチャー・マップに対する変更が行なわれる場合、（ｂ）プリミティブ１６２が引き出され（未使用の状態を出力しないでそれぞれのテクスチャー・マップ・トラッキング・ビット１７９をクリアーする）、（ｃ）テクスチャー・マップが「そのままの状態で」（つまりマップ自体への変化無しで）使用されるように状態変化がなされる。特殊扱いをしない限り、古くなったテクスチャー・マップは不正確に使用されるであろう。本発明において、テクスチャー・マップが（テクスチャー・マップ状態への状態変化の結果）「使用済み」となる場合にテクスチャー・マップ・トラッキング・ビット１７９が設定されるので、古くなったリソースが使用される可能性が取り除かれる。

状態設定グラフィックス命令の最適化されたバージョンは、動的状態変数サブグループ１７２のそれぞれを別々に更新するために使用される。これらの最適化命令がビン１２８に含まれる事によって、間接状態命令の読み込みの複雑さと待ち時間が大幅に減少し、これによって、コストの削減と性能の向上が同時に達成される。具体的に、図５はデルタ状態変化の調査と、状態およびビン毎のトラッキング・ビット１７４の更新を示す（ステップ２１２〜２２２）。グラフィックス・ビニング・エンジン１２６は、ビン１２８毎に、およびサブグループ１７２毎に状態の変化を維持・トラッキングする事によって、全てのビン１２８に対する全ての状態変化の不必要な配信を防ぐ。ビン１２８の状態は、ビン１２８に配置済みのプリミティブ命令に先立って優先的に更新される。ビニングされている複数のプリミティブ命令間の同じ状態サブグループ１７２内に生じる複数の変化は、ビン１２８への１つのサブグループの変化出力へと縮小される。

ステップ２１２〜２２２は、シーンのキャプチャー段階中に効率的に状態変化を管理するために格納された現在の動的な状態およびビン毎のトラッキング・ビット１７４を使用するために実施される。状態変化をビン１２８毎に、および状態グループ１７２毎にトラッキングする事によって、グラフィックス・ビニング・エンジン１２６は、プリミティブ１６２がビン１２８に最後に配置されて以来変更された該ビン用の状態サブグループ１７２のみを更新する。

初めに、状態変化に遭遇する場合（ステップ２１２）、対応する動的な状態サブグループ１７２が決定される（ステップ２１４）。その後、特定の状態変数の前回の値が決定される（ステップ２１６）。

状態の新しい値が状態の現在値と異なっている場合（ステップ２１８）、ビン１２８用の対応するサブグループ・トラッキング・ビット１７４が設定される（ステップ２２０）。その後、状態の新しい値によって現在の状態が更新される（ステップ２２２）。

スロー状態ポインタ：状態変化が「スロー状態ポインタ」を修正する場合、各ビン（ｉ）のスロー状態トラッキング・ビット（ｉ）が設定される。これらの状態変化は、影響を受けたサブグループのそれぞれの現在の状態に適用される。

基礎状態：例えば、状態変化が「基礎状態」を修正する場合、各ビン（ｉ）の基礎状態トラッキング・ビット（ｉ）が設定される。

テクスチャー・マップ：状態変化が、必要とされるテクスチャー・マップ（０…３）を設定させる場合、ビン（ｉ）のテクスチャー・マップ状態トラッキング・ビット（ｉ）が設定される。状態変化がテクスチャー・マップ（０…３）を修正する場合、各ビン（ｉ）のテクスチャー・マップ状態トラッキング・ビット（ｉ）が設定される。

テクスチャー・ブレンド：状態変化が必要な「カラー要因」を修正する場合、各ビン（ｉ）のテクスチャー・ブレンド状態トラッキング・ビット（ｉ）が設定される。有効化されたテクスチャー・ブレンド段階の数を状態変化が増加させる場合、各ビン（ｉ）のテクスチャー・ブレンド状態トラッキング・ビット（ｉ）が設定される。

図６は、どの特定のテクスチャー・マップまたはテクスチャー・ブレンド段階に対応した状態がビン１２８に出力される必要があるかを特に検出するための最適化の実施形態２３０を示すフローチャートである。具体的に、テクスチャー・マップまたはテクスチャー・ブレンド状態に対応するサブグループ・トラッキング・ビット１７４が設定されているという事が判った場合、特定のテクスチャー・マップまたはテクスチャー・ブレンド状態に関する状態情報のみがビン１２８に出力される。使用済みのテクスチャー・マップあるいはテクスチャー・ブレンド段階に関する情報のみがビン１２８に出力される。これにより、新たに必要とされる状態またはマップのみが交差するビンに出力される事を保障することによって、古いテクスチャー・ブレンドまたはテクスチャー・マップ状態が使用される事を防止する。（ａ）現在用いられているマップ／段階に関する状態に変更が為された場合、または、（ｂ）以前に未使用であったマップ／段階が、他の状態変数に対する変更によって「使用済み」となった場合、このサブグループ・トラッキング・ビット１７４が設定される。後者に関して、例えば、テクスチャー・ブレンドまたはテクスチャー・マップは、対応する状態変化（例えば基礎状態変化）の結果として「使用済み」となる。

各ビン１２８に関して、プリミティブ１６２が交差し（ステップ２３２）、テクスチャー・マップおよび（または）ビン１２８に対応するブレンド・サブグループ・トラッキング・ビット１７４が調べられる（ステップ２３４）。トラッキング・ビット１７４が設定される場合（ステップ２４０）、マップ／ステージが調べられる（ステップ２３８〜２４４）。テクスチャー・マップ／段階に変化が存在する場合（ステップ２４０）、テクスチャー・マップ／段階はビン１２８に出力される（ステップ２４２）。その後、次のテクスチャー・マップ／段階が調べられる（ステップ２４４）。例えば、テクスチャー・ブレンド状態トラッキング・ビット（ｉ）が設定される場合（ステップ２３６）、変更された特定のテクスチャー・ブレンド段階がビン１２８に出力される。具体的に、テクスチャー・ブレンド段階０が変更された場合、テクスチャー・ブレンド段階１が出力される。テクスチャー・ブレンド段階１が変更された場合、テクスチャー・ブレンド段階２が出力される。テクスチャー・ブレンド段階２が最終段階に達した場合、テクスチャー・ブレンド段階３が出力される（以下同様）。その後、テクスチャー・ブレンド状態トラッキング・ビットがクリアーされる（ステップ２４６）。

テクスチャー・マップ状態トラッキング・ビット（ｉ）が設定される場合（ステップ２３２）、変更された特定のテクスチャー・マップがビン１２８に出力される。具体的に、テクスチャー・マップ［０］が変更される場合、テクスチャー・マップ０が出力される。テクスチャー・マップ［１］が変更される場合、テクスチャー・マップ１が出力される。テクスチャー・マップ［２］が変更される場合、テクスチャー・マップ２が出力される。テクスチャー・マップ［３］が変更される場合、テクスチャー・マップ３は出力される（以下同様）。その後、テクスチャー・マップ状態トラッキング・ビットがクリアーされる（ステップ２４６）。

トラッキング・ビット１７４が変化を示さない場合、プリミティブ１６２が引き出され、ビン１２８に不必要な状態を出力する事無くそれぞれのテクスチャー・ブレンド段階またはテクスチャー・マップ／段階トラッキング・ビットがクリアーされる。

以上、特許法の必要条件に従って本発明を記載したが、当業者は、これらの特定の要求または条件を満たすために本発明に対して特定の改変および変更を実行する方法を理解する。この種の改変および変更は、添付の特許請求の範囲にて説明される本発明の範囲および精神から逸脱する事無く為され得るものである。

ゾーン・レンダリングにおける自動メモリ管理用グラフィック装置の実施形態を備えるコンピュータ・システムの実施形態のブロック線図である。 デルタ状態を含むシーン入力リストを処理するためのグラフィック・ビニング・エンジンと、グラフィック・レンダリング・エンジンおよびビンを備えるグラフィック装置の実施形態のブロック線図である。 ゾーンおよび幾何学的なプリミティブを含むゾーン・レンダラー・スクリーンの実施形態の例を示す。 動的状態サブグループおよびビン毎のトラッキング・ビットの実施形態を示すブロック線図である。 ビン中にプリミティブを配置するのに先立って必要な任意の状態変化を出力するプロセス、および、ゾーン・レンダリングのシーン・キャプチャ段階において効率的に状態変化を管理するために、格納された現在の動的状態とビン毎のトラッキング・ビット・ベクトルを使用するプロセスの実施形態を示すフローチャートである。 どのテクスチャー・マップおよびテクスチャー・ブレンド段階が必要であるかの検出を最適化するプロセスの実施形態を示すフローチャートである。

Claims (38)

1. プリミティブをレンダリングするための状態変数を管理する方法であって、
   前記プリミティブに関する命令および現在の状態の情報を格納する複数のメモリ領域を定義するステップと、
   前記プリミティブに関する状態変数を定義するステップと、
   状態変数を複数のサブグループにソートするステップと、
   前記複数のメモリ領域のそれぞれを複数のトラッキング・ビットに関連付けるステップと、
   前記プリミティブ命令が前記メモリ領域に前回出力されて以来の状態変数の変化に応じて前記トラッキング・ビットを設定するステップと、
   前記設定済みトラッキング・ビットに応じて、前記サブグループに関する現在の状態の情報を前記複数のメモリ領域のうちの一つに出力するステップと
   を備え、
   各トラッキング・ビットが、サブグループおよび前記複数のメモリ領域の１つに対応する、
   方法。
2. 前記現在の状態の情報が前記複数のメモリ領域の１つに出力された後に、前記トラッキング・ビットをクリアーするステップを更に備える、請求項１に記載の方法。
3. 状態変数を複数のサブグループにソートするステップが、
   基礎状態関数に関する状態変数をソートするステップを更に備える、
   請求項１に記載の方法。
4. 状態変数を複数のサブグループにソートするステップが、
   テクスチャー・マップ関数に関する状態変数をソートするステップを更に備える、
   請求項１に記載の方法。
5. 状態変数を複数のサブグループにソートするステップが、
   テクスチャー・ブレンド関数に関する状態変数をソートするステップを更に備える、
   請求項１に記載の方法。
6. 状態変数を複数のサブグループにソートするステップが、
   スロー状態関数に関する状態変数をソートするステップを更に備える、
   請求項１に記載の方法。
7. 前記プリミティブ命令が前記メモリ領域に前回出力されて以来の状態変数の変化に応じて前記トラッキング・ビットを設定するステップが、
   状態変化が生じたかどうかを決定するステップと、
   どのサブグループが前記状態変化に対応しているかを決定するステップと、
   状態変数の新しい値と前の値を決定するステップと、
   前記新しい値と前の値が異なる場合に、前記対応するサブグループ・トラッキング・ビットを設定するステップと
   を備える、請求項１に記載の方法。
8. 状態情報を格納する複数の付加メモリ領域を定義するステップと、
   前記複数の付加メモリ領域用のレファレンスを定義するステップと、
   前記複数の付加メモリ領域へ選択された状態グループ情報を格納するステップと
   を更に備える、請求項１に記載の方法。
9. 設定済み前記サブグループに応じて、前記サブグループに対応する現在の状態の情報を前記複数のメモリ領域のうちの一つに出力するステップが、
   前記トラッキング・ビットが設定される時、前記複数のメモリ領域のうちの１つへ前記サブグループに対応する前記レファレンスを出力するステップと、
   前記レファレンスに基づいて、レンダリング中に前記複数の付加メモリ領域のうちの１つに格納されたレファレンス情報を検索するステップと
   を更に備える、請求項８に記載の方法。
10. 前記付加メモリ領域へ選択された状態グループ情報を格納するステップが、
    スロー状態関数に対応付けられた状態変数を前記複数の付加メモリ領域へ格納するステップ
    を更に備える、請求項９に記載の方法。
11. 前記複数の付加メモリ領域用のレファレンスを定義するステップが、
    前記付加メモリ領域のスロー状態情報が格納される箇所へのポインタを定義するステップ
    を更に備える、請求項１０に記載の方法。
12. プリミティブを含むシーンをレンダリングする装置であって、
    プリミティブが交差する領域に対応する複数のビニング・メモリ領域と、
    プリミティブ命令が前記メモリ領域に前回出力されて以来に影響された状態変数のインジケータを格納するトラッキング・メモリ領域と、
    前記トラッキング・インジケータに応答し、状態変数の現在の状態の情報をビニングするビニング・エンジンと、
    前記メモリ領域に格納された前記現在の情報をレンダリングするレンダリング・エンジンと
    を備える、装置。
13. 前記現在の情報が、プリミティブ命令が前回前記メモリ領域に出力されて以来変更された状態変数を含む、請求項１２に記載の装置。
14. 前記現在の情報がレファレンスを含む、請求項１２に記載の装置。
15. 前記状態変数が、少なくとも１つの状態グループと対応している、請求項１３に記載の装置。
16. 前記少なくとも１つの状態グループが、基礎状態関数を含む、請求項１５に記載の装置。
17. 前記少なくとも１つの状態グループが、テクスチャー・マップ関数を含む、請求項１５に記載の装置。
18. 前記少なくとも１つの状態グループが、テクスチャー・ブレンド関数を含む、請求項１５に記載の装置。
19. 前記少なくとも１つの状態グループが、スロー状態関数を含む、請求項１５に記載の装置。
20. 前記トラッキング情報が、複数のトラッキング・ビットを含み、
    各トラッキング・ビットが、ビニング・メモリ領域およびサブグループと対応付けられる、
    請求項１２に記載の装置。
21. プリミティブ命令が前記メモリ領域に前回出力されて以来に影響された状態変数のインジケータを格納するトラッキング・メモリ領域が、
    プリミティブ命令が前記メモリ領域に前回出力されて以来に変更された状態変数のインジケータを格納するトラッキング・メモリ領域を更に備える、
    請求項１２に記載の装置。
22. プリミティブ命令が前記メモリ領域に前回出力されて以来に影響された状態変数のインジケータを格納するトラッキング・メモリ領域が、
    プリミティブ命令が前記メモリ領域に前回出力されて以来に使用された状態変数のインジケータを格納するトラッキング・メモリ領域を更に備える
    請求項１２に記載の装置。
23. 複数の付加メモリ領域を備える、請求項１４に記載の装置。
24. 前記複数の付加メモリ領域が、スロー状態状態変数を格納する、請求項２３に記載の装置。
25. 前記レファレンスが、前記付加メモリ領域へのポインタを備える、請求項２４に記載の装置。
26. 前記ビニング・エンジンが、前記トラッキング・インジケータに反応して、前記複数のビニング・メモリ領域のうちの１つの中のレファレンスをビニングする、請求項２５に記載の装置。
27. 前記レンダリング・エンジンが、前記複数の付加メモリ領域の少なくとも１つからスロー状態情報を検索するために前記レファレンスを利用する、請求項２６に記載の装置。
28. プリミティブをレンダリングする状態を管理するプロセッサによって実行可能な複数の機械可読命令を格納した機械可読媒体であって、前記機械可読命令が、
    前記プリミティブに関する命令および現在の状態の情報を格納する複数のメモリ領域を定義させる命令と、
    前記プリミティブに関する状態変数を定義させる命令と、
    状態変数を複数のサブグループにソートさせる命令と、
    前記複数のメモリ領域のそれぞれを複数のトラッキング・ビットに関連付けさせる命令と、
    前記プリミティブ命令が前記メモリ領域に前回出力されて以来の状態変数の変化に応じて前記トラッキング・ビットを設定させる命令と、
    前記設定済みトラッキング・ビットに応じて、前記サブグループに関する現在の状態の情報を前記複数のメモリ領域のうちの一つに出力させる命令と
    を備え、
    各トラッキング・ビットが、サブグループおよび前記複数のメモリ領域の１つに対応する、
    機械可読媒体。
29. 前記現在の状態の情報が前記複数のメモリ領域の１つに出力された後に、前記トラッキング・ビットをクリアーさせる命令を更に備える、請求項２８に記載の機械可読媒体。
30. 状態変数を複数のサブグループにソートさせる命令が、
    基礎状態関数に関する状態変数をソートさせる命令を更に備える、
    請求項２８に記載の機械可読媒体。
31. 状態変数を複数のサブグループにソートさせる命令が、
    テクスチャー・マップ関数に関する状態変数をソートさせる命令を更に備える、
    請求項２８に記載の機械可読媒体。
32. 状態変数を複数のサブグループにソートさせる命令が、
    テクスチャー・ブレンド関数に関する状態変数をソートさせる命令を更に備える、
    請求項２８に記載の機械可読媒体。
33. 状態変数を複数のサブグループにソートさせる命令が、
    スロー状態関数に関する状態変数をソートさせる命令を更に備える、
    請求項２８に記載の機械可読媒体。
34. 前記プリミティブ命令が前記メモリ領域に前回出力されて以来の状態変数の変化に応じて前記トラッキング・ビットを設定させる命令が、
    状態変化が生じたかどうかを決定させる命令と、
    どのサブグループが前記状態変化に対応しているかを決定させる命令と、
    状態変数の新しい値と前の値を決定させる命令と、
    前記新しい値と前の値が異なる場合に、前記対応するサブグループ・トラッキング・ビットを設定させる命令と
    を備える、請求項２８に記載の機械可読媒体。
35. 状態情報を格納する複数の付加メモリ領域を定義させる命令と、
    前記複数の付加メモリ領域用のレファレンスを定義させる命令と、
    前記複数の付加メモリ領域へ選択された状態グループ情報を格納させる命令と
    を更に備える、請求項２８に記載の機械可読媒体。
36. 設定済み前記サブグループに応じて、前記サブグループに対応する現在の状態の情報を前記複数のメモリ領域のうちの一つに出力させる命令が、
    前記トラッキング・ビットが設定される時、前記複数のメモリ領域のうちの１つへ前記サブグループに対応する前記レファレンスを出力させる命令と、
    前記レファレンスに基づいて、レンダリング中に前記複数の付加メモリ領域のうちの１つに格納されたレファレンス情報を検索させる命令と
    を更に備える、請求項３５に記載の機械可読媒体。
37. 前記付加メモリ領域へ選択された状態グループ情報を格納させる命令が、
    スロー状態関数に対応付けられた状態変数を前記複数の付加メモリ領域へ格納させる命令
    を更に備える、請求項３６に記載の機械可読媒体。
38. 前記複数の付加メモリ領域用のレファレンスを定義させる命令が、
    前記付加メモリ領域のスロー状態情報が格納される箇所へのポインタを定義させる命令
    を更に備える、請求項３７に記載の機械可読媒体。

Images