(57)【特許請求の範囲】
【請求項１】
複数のグラフイックス・プリミティブを含むグラフイックス・オブジェクトからフレームバッフア内に描写イメージを形成するためのグラフイックス・レンダリング方法であって、
ウィンドウを決定するステップと、
ウィンドウを少なくとも１つのタイルに分割するステップと、
タイルとグラフイックス・オブジェクトの第１オブジェクトが少なくとも部分的に交差するかどうかを決定するステップと、
タイルと第１オブジェクトが少なくとも部分的に交差する場合、第１オブジェクトにタグを割当てるステップと、
オブジェクトがグラフイックス・レンダリング・パイプライン中で処理される時、第１オブジェクトを１つ又は複数の可視性の基準でテストするステップと、この各オブジェクトをテストするステップはオブジェクト内のプリミティブのテストを含み
可視性の基準によるテストに対するタグ付きオブジェクトの応答を指示する状態ワード中にビットを設定するステップと、
どのオブジェクトが少なくとも部分的に可視であるかを決定するために状態ワードを読むステップと、
を含むグラフイックス・レンダリング方法。
【請求項２】
オブジェクトの境界体積を推定するためにグラフイックス・プリミティブを入力することを含むグラフイックス・オブジェクトを入力するステップと、
境界体積の可視性を決定するために状態ワードを読むステップと、
対応する境界体積が可視でないと決定された時にオブジェクトを廃棄するステップと、
メモリ中にグラフイックス・プリミティブを格納することにより複数のオブジェクトを蓄積し、
プリミティブをスタンプ部分に分割し、フレームバッフア内の最終結果に影響を与えないことが保証されたプリミティブの部分を除去し、及び可視スタンプ部分としてプリミティブの他の部分を識別するために、蓄積されたオブジェクトを処理するステップと、
状態ワードを読むステップを実行する前に複数のオブジェクトについて前記蓄積されたオブジェクトを処理するステップを実行し、そして状態ワードが複数の蓄積されたオブジェクトの各々の可視性を決定するために使用されるステップと、
をさらに含む請求項１に記載のグラフイックス・レンダリング方法。
【請求項３】
グラフイックス・プリミティブを各々が含んだ三次元オブジェクトの複数を処理することによりフレームバッフア内に描写イメージを形成するコンピュータ・グラフイックス・パイプラインのための状態モニタリング装置であって、
三次元オブジェクトがコンピュータ・グラフイックス・パイプラインにより処理される時に、三次元オブジェクトがレンダリングされるウィンドウを少なくとも１つに分割したタイルと少なくとも部分的に交差する場合、オブジェクト・タグを三次元オブジェクトと関連付ける論理と、
三次元オブジェクトがコンピュータ・グラフイックス・パイプラインにおいて処理される時に１つ又は複数の可視性基準により三次元オブジェクトをテストする論理と、
複数のビットを含む状態レジスタと、
オブジェクト・タグの１つに従い状態レジスタの１つのビットを選択する論理と、
対応する三次元オブジェクトの１つの可視性基準によるテストの応答に従い状態レジスタ中に選択されたビット値を設定する論理と、
ホストＣＰＵがどの三次元オブジェクトが少なくとも部分的に可視であるかを決定するため、ホストＣＰＵへ状態レジスタ内容を読み出して送信する論理と、
を含むコンピュータ・グラフイックス・パイプラインのための状態モニタリング装置。
【請求項４】
三次元オブジェクトの境界体積を表すグラフイックス・プリミティブを生成する論理と、
ホストＣＰＵがどの境界体積が少なくとも部分的に可視であるかを決定して少なくとも部分的に可視であると決定されないオブジェクトを以後の処理から破棄するため、状態レジスタの内容を読み出してホストＣＰＵへ送信する論理と、
をさらに含む請求項３に記載の状態モニタリング装置。
【請求項５】
複数の三次元オブジェクトを蓄積するメモリと、
プリミティブをスタンプ部分に分割し、フレームバッフア内の描写イメージに影響を与えないことが保証されたグラフイックス・プリミティブの部分をコンピュータ・グラフイックス・パイプラインから除去し、及びプリミティブの他の部分を可視スタンプ部分として識別する論理と、
三次元オブジェクトがコンピュータ・グラフイックス・パイプラインにより処理される時、複数のオブジェクト・タグを複数の三次元オブジェクトに一対一のベースで同時的に関連付けする論理と、
をさらに含み、そして状態レジスタが蓄積されたオブジェクトの各々の可視性を決定するために使用される請求項３に記載の状態モニタリング装置。
【請求項６】
フレームバッフア内に格納されたイメージの三次元（３Ｄ）グラフイックス描写、生成をするための計算システムであって、
ホスト・プロセッサと、
ホスト・プロセッサに接続されたシステム・メモリと、
ホスト・プロセッサに接続されたコンピュータ・グラフイックス・パイプライントとを含み、このコンピュータ・グラフイックス・パイプラインが、
三次元オブジェクトがコンピュータ・グラフイックス・パイプラインにより処理される時、三次元オブジェクトがレンダリングされるウィンドウを少なくとも１つに分割したタイルと少なくとも部分的に交差する場合、オブジェクト・タグを三次元オブジェクトに関連付ける論理と、
三次元オブジェクトがグラフイックス・レンダリング・パイプラインで処理される時、三次元オブジェクトを１つ又は複数の可視性基準によりテストする論理と、
ホスト・プロセッサにより読み取り可能な複数のビットを含む状態レジスタと、
オブジェクト・タグの１つに従い状態レジスタ中の１つのビットを選択する論理と、
可視性基準によるテストについての三次元オブジェクトの対応する１つの応答に従い、状態レジスタ中の選択されたビットの値を設定する論理と、
を含む計算システム。
【請求項７】
フレームバッフア内に格納されたイメージの三次元（３Ｄ）グラフイックス描写、生成をするための計算システムであって、
ホスト・プロセッサと、
ホスト・プロセッサに接続されたシステム・メモリと、
ホスト・プロセッサに接続されたコンピュータ・グラフイックス・パイプライントとを含み、このコンピュータ・グラフイックス・パイプラインが、
三次元オブジェクトがコンピュータ・グラフイックス・パイプラインにより処理される時、三次元オブジェクトがレンダリングされるウィンドウを少なくとも１つに分割したタイルと少なくとも部分的に交差する場合、オブジェクト・タグを三次元オブジェクトに関連付ける論理と、
三次元オブジェクトがグラフイックス・レンダリング・パイプラインで処理される時、三次元オブジェクトを１つ又は複数の可視性基準によりテストする論理と、
ホスト・プロセッサにより読み取り可能な複数のビットを含む状態レジスタと、
オブジェクト・タグの１つに従い状態レジスタ中の１つのビットを選択する論理と、
可視性基準によるテストについての三次元オブジェクトの対応する１つの応答に従い、状態レジスタ中の選択されたビットの値を設定する論理とを含み、
ホスト・プロセッサがプログラム・モジュールを実行して指定された態様で機能するためにイメージの描写を指示し、このプログラム・モジュールが、
１つの三次元オブジェクトの境界体積を定義する非描写可能グラフイックス・プリミティブにより表されるその１つの三次元オブジェクトを受け取るための命令と、
非描写可能グラフイックス・プリミティブを入力することによりコンピュータ・グラフイックス・パイプライン中に三次元オブジェクトのその１つを入力するための命令と、
非描写可能グラフイックス・プリミティブに対応するオブジェクトが隠れているかどうかを決定するために状態レジスタ内容を読み出すための命令と、
を含む計算システム。
【請求項８】
コンピュータ・グラフイックス・パイプラインがさらに、
各々が非描写可能プリミティブの対応する組により表された複数の三次元オブジェクトを蓄積するためのメモリと、
最終描写イメージに明らかに貢献しないプリミティブの部分を取り除くための陰面除去を実行する論理とを含み、陰面除去はイメージ領域中のグラフイックス・プリミティブに対してカラー・データが生成される前のイメージ領域について実行され、これによって、生成する必要のあるカラー・データ量を減少し、
プログラム・モジュールがさらに、
状態レジスタを読み出す前に複数の三次元オブジェクトを入力するための命令と、
状態レジスタを読出し、その非描写可能プリミティブが隠されていない三次元オブジェクトに対応した描写可能プリミティブをコンピュータ・グラフイックス・パイプラインへ入力し、これによって、その非描写可能プリミティブが隠れている三次元オブジェクトに対応した描写可能プリミティブの入力を回避するための命令と、
を含む請求項７に記載の計算システム。
【発明の詳細な説明】
【０００１】
（技術分野）
本発明は、コンピューティング・システム（computing system）に関し、一般的には３次元コンピュータ・グラフィックス（computer graphics）に関し、より特定的には、ディファード・シェーディング（deferred shading）及び向上した特性を実行する３次元グラフィックス・プロセッサ（graphics processor）のための構造及び方法に関する。
【０００２】
（背景技術）
２．１  ３次元コンピュータ・グラフィックス
コンピュータ・グラフィックスは、コンピュータで画像（ピクチャ）を生成する技術及び科学である。絵、すなわち画像の生成は、一般的にはレンダリング（rendering）と呼ばれる。一般的に、３次元（３Ｄ）コンピュータ・グラフィックスでは、あるシーン（scene）でのオブジェクト（object）の表面（又はボリューム）を表すジオメオトリ（geometry）は、フレーム・バッファ（frame buffer）に記憶されるピクセルに変換され、それから表示装置上に表示される。コンピュータ・モニタとして使用されるＣＲＴ等、リアルタイム（real-time）表示装置は、継続的に画像を繰り返して表示することによって、前記表示をリフレッシュする（refresh）。このリフレッシュは通常、列毎に起こり、各列はラスタ線（raster line）又はスキャン線（scan line）と呼ばれる。この明細書において、ラスタ線は下から上に、番号を付けられるが、上から下に表示される。
【０００３】
３Ｄアニメーション（3D animation）において、画像のシーケンスが表示され、３次元空間での動きの錯覚を与える。対話型３Ｄコンピュータ・グラフィックスは、ユーザに、自らのビュー・ポイント（view point）を変えさせ、又はリアルタイムでジオメトリを変更させることで、レンダリング・システムに、新しい画像をリアルタイムで稼動中に生成するよう要求する。
【０００４】
３Ｄコンピュータ・グラフィックスにおいて、各レンダリング可能オブジェクトは通常、自らのローカル・オブジェクト（local object）座標システムを有し、それゆえに、オブジェクト座標からピクセル表示座標に変換され（又は変形され）る必要がある。概念上、これは４段階処理：１）オブジェクト座標からワールド座標（world coordinate）への変換（サイズの拡大又は縮小に関するスケーリング（scaling）を含む）であり、それはシーン全体に関する座標システムである；２）前記シーンのビュー・ポイントに基づいた、ワールド座標からアイ座標（eye coordinate）への変換；３）アイ座標から透視的な変換されたアイ座標への変換であり、透視的スケーリング（さらなるオブジェクトは、より小さく現れる）が実行された場合；及び４）透視的な変換されたアイ座標から、スクリーン座標とも呼ばれるピクセル座標への変換である。スクリーン座標は、３次元空間における点であり、及び後述のとおり、スクリーン精度（すなわちピクセル）又はオブジェクト精度（高精度数で、通常フローティング・ポイントである）のいずれかでよい。これらの変換ステップは、変換が起こる前に、適切な変換マトリックスを予め計算することによって、一つ又は二つのステップに圧縮することができる。一度、ジオメトリがスクリーン座標になると、それは、フレーム・バッファに記憶される（すなわち「ラスタライズされた“rasterized”」）一組のピクセル色値に分解される。グロー・シェーディング（Gouraud shading）、フォン・シェーディング（Phong shading）及びテクスチャ・マッピング（texture mapping）を含むピクセル色値を生成するための多くの技術が使用される。
【０００５】
従来のレンダリング処理の要約は、「３次元コンピュータ・グラフィックスの基礎（Fundamentals of Three-dimensional Computer Graphics）」、ワット（Watt）著、第５章：レンダリング処理（The Rendering Process）、９７乃至１１３ページ、マサチューセッツ（Massachusetts）州、レディング（Reading）、アディソン−ウェスリー出版社（Addison-Wesley Publishing Company）、１９８９年発行、１９９１年増刷、ＩＳＢＮ０−２０１−１５４４２−０（以後、ワット参照と称する）に、見ることができる。
【０００６】
図１は、３次元オブジェクト、四面体を、その座標軸（Ｘobj，Ｙobj，Ｚobj）とともに示す。３次元オブジェクトは、（Ｘeye，Ｙeye，Ｚeye）に基づいて、ビュー・ポイントの座標システムで、変換され、基準化され、及び配置される。前記オブジェクトは、ビューイング・プレーン（viewing plane）へと投影され、それによって透視図に修正する。この点において、オブジェクトは、２次元になったように見える；しかしながら、前記オブジェクトのｚ座標は維持されるので、それらは後に隠れ面除去技術によって使用することができる。前記オブジェクトは最後に、Ｚscreenが、ページに垂直に交わる、（Ｘscreen，Ｙscreen，Ｚscreen）に基づいて、スクリーン座標に変換される。前記オブジェクト上の点は、表示スクリーン内のピクセルの位置（及びそれの小数部）によって記述される自らのｘ及びｙ座標と、及びビュー・ポイントから、基準化されたバージョンの距離にＺ座標を有する。
【０００７】
ジオメトリの多くの異なる部分が、同じピクセルに影響を与えうるので、シーン・ビューイング・ポイントに最も近い面を表すジオメトリが決定されなければならない。各ピクセルに関して、前記ピクセルの領域によって境界を成す前記ボリューム内の可視面は、ピクセル色値を決定する一方で、隠れ面は、前記ピクセルに影響を与えることができない。最も近い不透明面（ジオメトリの辺縁部が、ピクセル領域と交差する場合は、複数の面）よりも、ビュー・ポイントに近い非不透明面は、ピクセル色値に影響を与える一方で、すべての他の非不透明面は、廃棄される。この明細書において、「閉塞した（occluded）」という用語は、他の非不透明ジオメトリによって隠されたジオメトリを記述するために使用される。
【０００８】
可視面決定を実行するために、多くの技術が開発され、及びこれらの技術の調査は：「コンピュータ・グラフィックス：原理と実践（Computer Graphics : Principles and Practice）」、フォリー（Foley）、ヴァン・ダム（van Dam）、ファイナー（Feiner）、及びヒューズ（Hughes）著、第１５章：可視面決定（Visible-Surface Determination）、６４９乃至７２０ページ、第２版、マサチューセッツ州、レディング、アディソン−ウェスリー出版社、１９９０年、１９９１年訂正増刷、ＩＳＢＮ０−２０１−１２１１０−７（以後、フォリー参照（Foley Reference）と称する）を参照して、ここに採用されている。フォリー参照において、６５０ページで、「画像精度」及び「オブジェクト精度」という用語が定義される：「画像精度アルゴリズムは、通常、画像装置の解像度で実行され、及び各ピクセルにおける可視性を決定する。オブジェクト精度アルゴリズムは、各オブジェクトが定義される精度で実行され、及び各オブジェクトの可視性を決定する。」
レンダリング処理が進むにつれて、複数の面が、ピクセルによって境界を定められるボリュームと交差するので、ほとんどの従来技術のレンダラ（renderer）は、一定のスクリーン・ピクセルの色値を何回も計算しなければならない。ピクセルがレンダリングされる必要がある、平均的回数は、特定のシーンに関しては、シーンの深度計算複雑性（depth complexity）と呼ばれる。単純なシーンは、ほぼ１の深度計算複雑性を有する一方で、複雑なシーンは、１０又は２０の深度計算複雑性を有しうる。シーン・モデル（scene model）がより複雑になると、レンダラは、常に増加する深度計算複雑性を有するシーンを処理することを要求されるであろう。このように、ほとんどのレンダー（renders）に関して、シーンの深度計算複雑性は、浪費された処理の基準である。例えば、１０の深度計算複雑性を有するシーンに関して、計算の９０％は、隠れピクセルで浪費される。この浪費された計算は、単純なＺバッファ技術（後述される）を使用するハードウェア・レンダラには典型的であり、それはハードウェアに簡単に組み込むことができるので、一般的に選択される。Ｚバッファ技術よりも複雑な方法は、今まで、複雑すぎて、一般的には費用効果的な方法で構築することができなかった。本発明において示された前記方法及び装置の重要な特性は、ラスタライズされる前に、ジオメトリの隠れ部分を排除することによって、この浪費された計算を避ける一方で、費用効果的なハードウェアに組み込むのに十分に単純であることである。
【０００９】
表面上の一点（しばしば、ポリゴンのバーテックス）が、スクリーン座標に変換される時、前記点は、三つの座標：１）ピクセル単位のｘ座標（一般的に小数点を含む）；２）ピクセル単位のｙ座標（一般的に小数点を含む）；及び３）アイ座標、仮想スクリーンからの距離、又はビューイング・ポイントからの面の相対距離を維持する他の座標システムのいずれかにおける点のｚ座標を有する。本明細書において、正のｚ座標値は、ビューイング・ポイントからの「観察方向」に関して使用され、より小さい値は、ビューイング・ポイントにより近い位置を示す。
【００１０】
面が一組の平面ポリゴンによって近似される（approximated）時、各ポリゴンのバーテックスは、スクリーン座標に変換される。ポリゴンにおける又はその上にある点に関して（バーテックスは除く）、スクリーン座標は、通常は、エッジ・ウォーキング（edge walking）及びスパン補間（span interpolation）の処理によって、バーテックスの座標から補間される。このようにｚ座標値は、一般的に、ジオメトリがレンダリングされると、各ピクセル値（色値とともに）に含まれる。
２．２  包括的３Ｄグラフィックス・パイプライン（Generic 3D Graphics Pipeline）
多くのハードウェア・レンダラが開発されており、一例は、：「Ｌｅｏ：費用効果的３Ｄシェーデド・グラフィックスのためのシステム（Leo: A System for Cost Effective 3D Shaded Graphics）」ディアリング（Deering）及びネルソン（Nelson）著、ＳＩＧＧＲＡＰＨ９３会報の１０１乃至１０８ページ、１９９３年８月１−６日、コンピュータ・グラフィックス会報、年次会議シリーズ、ニューヨーク、ＡＣＭ  ＳＩＧＧＲＡＰＨ、１９９３年出版、ソフトカバーＩＳＢＮ０−２０１−５８８８９−７及びＣＤ−ＲＯＭ  ＩＳＢＮ０−２０１−５６９９７−３（以後、ディアリング参照と称する）を参照して、ここに採用されている。ディアリング参照は、それが「真に包括的であり（truly generic）、ほぼすべての商業用３Ｄグラフィックス・アクセレレータ（3D graphics accelerator）が、この要約に適合する最高レベルである」として述べている包括的３Ｄグラフィックス・パイプライン（すなわち、レンダラ、又はレンダリング・システム）のダイアグラム（diagram）を含み、このパイプライン・ダイアグラムは、図２に記載のとおり再現される。そのようなパイプライン・ダイアグラムは、レンダリングの処理を運ぶが、特定のハードウェアを記述しない。本明細書は、包括的３Ｄグラフィックス・パイプラインのステップのいくつかを共有する新しいグラフィックス・パイプラインを示す。包括的３Ｄグラフィックス・パイプラインにおける各ステップは、ここでは簡単に説明され、図３に記載の方法の流れのダイアグラムにおいても示される。ポリゴンの処理が、本明細書のすべてにおいて仮定されるが、３Ｄジオメトリを記述するための他の方法が、代わりになることもできる。説明を簡単にするために、記述された方法におけるポリゴンの種類として、三角形が使用される。
【００１１】
図２に記載のとおり、データ入力（ステップ２１２）後、包括的３Ｄグラフィックス・パイプラインのフローティング・ポイント集約的機能の中での第一のステップは、変換ステップ（ステップ２１４）であり、それは前述された。変換ステップは、方法の流れのダイアグラムの外側のループにおける第一のステップとして、図３にも記載されており、また、「次のポリゴンを得る（get next polygon）」も含む。第二のステップ、クリップ・テスト（clip test）は、少なくともビュー・ボリューム（view volume）に部分的に含まれるか見るために、前記ポリゴンを調べる（時に、錐台系の形状である）（ステップ２１６）。ポリゴンが、ビュー・ボリュームにない場合、それは放棄される；そうでなければ、処理が継続する。第三のステップは、面決定であり、ビューイング・ポイントから逸れた方を向いたポリゴンは放棄される（ステップ２１８）。一般的に、面決定は、閉じられたボリュームであるオブジェクトにのみ適用される。第四のステップは、ライティング計算（lighting computation）であり、一般的に、様々な種類の複数の光源での、グロー・シェーディング及び／又はテクスチャ・マッピングに関するセット・アップ（set up）を含むが、フォン・シェーディング又は多くの他の選択肢の一つに関して設定することもできる（ステップ２２２）。第５のステップ、クリッピング（clipping）が、ビュー・ボリュームの外側にあるポリゴンのあらゆる部分を削除するのは、前記部分は、ビューイング・プレーンの四角の領域内に突出しないからである（ステップ２２４）。一般的に、ポリゴン・クリッピングは、ポリゴンを、両方がビューイング・プレーンの領域内に突出する、二つのより小さいポリゴンに分割することによって、なされる。ポリゴン・クリッピングは、計算上大変高価である。第六のステップ、透視的分割は、オブジェクトの、ビューイング・プレーンへの突出に関して、透視的修正をする（ステップ２２６）。この点において、ポリゴンのバーテックスを表す点は、ステップ７、スクリーン空間変換ステップによって、ピクセル空間座標に変換される（ステップ２２８）。第八のステップ（ステップ２３０）、増分レンダリングに関するセット・アップは、様々な始点、終点、及びウェッジ・ウォーキング並びにスパン補間に必要な増分値を計算する（例えば、ｘ、ｙ、及びｚ座標；ＲＧＢ色；テクスチャ・マップ空間ｕ及びｖ座標；等）。
【００１２】
描画集約的機能の中で、エッジ・ウォーキング（ステップ２３２）は、以前に生成されたスパン（同じポリゴンにおいて）からの値を増大させることによって、表示装置の書くラスタ線に関する水平スパンを増大的に生成し、それによってポリゴンの反対のエッジに沿って、垂直に「ウォーキング」する。同様に、スパン補間（ステップ２３４）は、ビューイング・ポイントからのピクセルの距離を示すｚ座標値を含む、ピクセル値を生成するために、スパンに沿って水平に「ウォーキング」する。最後に、テスティング（Testing）及びブレンディング（Blending）とも称されるｚバッファされたブレンディング（ステップ２３６）は、最終のピクセル色値を生成する。前記ピクセル値は、色値も含み、それは単純なグロー・シェーディング（すなわち、バーテックス色値の補間）によって、又はテクスチャ・マッピング（おそらく、ともにブレンドされた複数のテクスチャ・マップを使用して）、フォン・シェーディング（すなわち、パー・フラグメント（per fragment）ライティング）、及び／又はバンプ・マッピング（bump mapping）（補間された面法線を摂動させる）等の、より計算上高価な技術によって、生成することができる。描画集約的機能が完了した後、二重バッファされたＭＵＸ出力ルックアップ・テーブル・オペレーション（double-buffered MUX output look-up table operation）が実行される（ステップ２３８）。この図において、丸い角を有するブロック（block）は、通常は機能又は処理オペレーションを表す一方で、尖った角の長方形は、通常は記憶されたデータ又はメモリを表す。
【００１３】
生成されたｚ座標値を、Ｚバッファに記憶された対応する値と比較することによって、ｚバッファされたブレンドは、（それが、前記ピクセルの場所に関して、以前に記憶された値よりも、ビューイング・ポイントに近い場合）それをフレーム・バッファに書き込むことによって、新しいピクセル値を維持するか、又は新しいピクセル値を放棄する（それがさらに遠い場合）。このステップにおいて、アンチエイリアシング（antialiasing）方法は、新しいピクセル色を、古いピクセル色とブレンドすることができる。ｚバッファされたブレンドは、通常は後述のとおり、パー・フラグメントのオペレーションのほとんどを含む。
【００１４】
包括的３Ｄグラフィックス・パイプラインは、二重バッファされたフレーム・バッファを含むので、二重バッファされたＭＵＸも含まれる。出力ルックアップ・テーブルは、色マップ値を変換するために含まれる。最後に、デジタル−アナログ変換によって、表示装置への入力のためのアナログ信号を作る。
【００１５】
包括的３Ｄグラフィック・パイプラインの主な欠点は、その描画集約的機能が、固定された数のポリゴンを与えられたピクセル・レベルで、決定的ではないことである。すなわち、固定された数のポリゴンを与えられると、平均的ポリゴンのサイズが増大するにつれて、より多くのピクセルレベルの計算が必要とされる。しかしながら、フローティング・ポイント集約的機能は、ポリゴンの数に比例し、及び平均的なポリゴンのサイズから独立している。それゆえに、フローティング・ポイント集約的機能と、描画集約的機能の間の計算力の量の均衡を保つのが難しいのは、この均衡が、平均的なポリゴンのサイズに依存するからである。
【００１６】
従来技術のＺバッファは、従来のランダム・アクセス・メモリ（Random Access Memory）（ＲＡＭ又はＤＲＡＭ）、ビデオ・ラム（ＶＲＡＭ）、又は特殊なＤＲＡＭに基づいている。特殊ＤＲＡＭの一例は、「ＦＢＲＡＭ：３Ｄグラフィックスに最適化された、新しい形式のメモリ（FBRAM:A new Form of Memory Optimized for 3D Graphics）」、ディアリング（Deering）、シュラップ（Schlapp）、及びラヴェル（Lavelle）著、ＳＩＧＧＲＡＰＨ９４会報、１６７乃至１７４ページ、１９９４年７月２４−２９日、コンピュータ・グラフィックス会報、年次会議シリーズ、ニューヨーク、ＡＣＭ  ＳＩＧＧＲＡＰＨ、１９９４年出版、ソフトカバーＩＳＢＮ０２０１６０７９５６に掲載されている。
２．３  パイプラン状態
ＯｐｅｎＧＬは、プログラマに、グラフィック画像を作るためにオブジェクト及びオペレーションを特定させる何百もの機能及びプロシージャを含むグラフィックス・ハードウェアへのソフトウェア・インターフェースである。前記オブジェクト及びオペレーションは、三次元オブジェクトの色画像を作るための適切な特性を含む。ＯｐｅｎＧＬ（バージョン１．２）のほとんどは、オブジェクトが、点、線、ポリゴン、又はビット・マップ（bitmap）であっても、前記グラフィックス・ハードウェアが、フレーム・バッファを含むことを仮定し、又は要求し、及び前記オペレーションが、前記オブジェクト上でのオペレーションでもよい。ＯｐｅｎＧＬの一般的な特徴（グラフィカル・インターフェースの単なる一例）は、マーク・シーガル（Mark Segal）及びカート・アクレイ（Kurt Akeley）編、「ＯｐｅｎＧＬ登録商標グラフィックス・システム：仕様書（バージョン１．２）」、バージョン１．２、１９９８年３月の参照で説明される；及びここには参照のために採用されている。ＯｐｅｎＧＬを参照しているが、本発明は、ＯｐｅｎＧＬと、又は他の標準あるいは非標準グラフィカル・インターフェースと互換性があり、又は一致している構造、プロシージャ、又は方法に限定されない。望ましくは、本発明の構造及び方法は、標準インターフェースの一つのために準備されたデータ・セットが、変更なく本発明の構造及び方法によって処理されてもよいように、ＯｐｅｎＧＬ又は他の標準グラフィカル・インターフェースと一致する方法で実行されてもよい。しかしながら、本発明の構造及び方法は、ＯｐｅｎＧＬによっては供給されないいくつかの特徴を供給し、及びそのような包括的な入力／出力が供給される時でも、前記実行は異なる方法で供給される。
【００１７】
「パイプライン状態（pipeline state）」というフレーズは、従来技術においては単一の定義を有しない。例えば、ＯｐｅｎＧＬ仕様書は、状態の項目に関して、グラフィックス・レンダリング・マシン又はパイプライン状態の種類並びに量を、及び前記状態情報を記憶するために必要とされるビット並びにバイトの数を説明する。ＯｐｅｎＧＬ定義では、パイプライン状態は、例えば、「非バーテックス」情報と同様に、それ自身がバーテックス法線である複数のバーテックス及び色を含むオブジェクト・バーテックス関連情報を含む傾向にある。
【００１８】
情報が、グラフィックス・レンダラに送られる時、少なくともいくつかのオブジェクト・ジオメトリ情報が、シーンを記述するために供給される。通常は、オブジェクト又は複数のオブジェクトは、バーテックス情報に関して特定され、オブジェクトはモデル化され、定義され、又はそうでなければ、点、線、又は一つ以上のバーテックスを有するポリゴン（オブジェクト・プリミティブ（object primitives））によって特定される。単純に見ると、バーテックスは、空間における場所（location）であり、例えば、ある参照起点と比較した三次元空間（ｘ、ｙ、ｚ）座標によって特定されてもよい。面法線、色、テクスチャ、透明性、及びバーテックスの特性に関する類似の情報等、他の情報が各バーテックスと関連する。この情報は、基本的に「パー・バーテックス（"per-vertex"）」情報である。残念なことに、パー・バーテックス情報に対する必要条件としての、入力情報とバーテックスとの間の１対１の関係は、必ずしも制限的ではない。例えば、色値は、特定のバーテックスに関するデータ・ストリームにおいて特定されてもよく、前記色が、連続するバーテックスに関して変更するまで、データ・ストリームにおいて再特定されない。色値が、明らかに各バーテックスに関する入力データ・ストリームに含まれていなくても、前記色値は、パー・バーテックス・データとして特徴づけられてもよい。
【００１９】
テクスチャ・マッピングは、パー・バーテックス情報又はパイプライン状態情報のいずれとしても考えられる情報又はデータの興味深い例を示す。各オブジェクトに関して、一つ以上のテクスチャ・マップが特定され、各テクスチャ・マップは、一つのテクスチャ座標又は複数のテクスチャ座標等、ある方法で識別される。テクスチャ座標で指しているテクスチャ・マップが、パイプライン状態の一部として考えられてもよい一方で、それがパー・バーテックス情報であることが主張されてもよい。
【００２０】
１対１ベースでの、ジオメトリ・オブジェクト・プリミティブに関連しない、ライティングの場所並びに強さ、素材設定、反射特性、及びレンダラが動作する他のすべての規則等、レンダラによって使用される他の情報は、より正確に、パイプライン状態と称されてもよい。パー・バーテックス・ベースでは、変化しない、又は変化してはならないものは、パイプライン状態だけであると考えられるかもしれないが、上述の理由から、これは完全に明確な定義ではない。例えば、レンダリングされるべき一定のオブジェクトに適用されるべき、特定の深度テスト（後述の説明を参照）を定義してもよく、例えば、深度テストは、ｚ値が、厳格に、いくつかのオブジェクトに関して「より大き（"greater-than"）」く、及び他のオブジェクトに関しては「より大きいか又は等し（"greater-than-or-equal-to"）」くなることを要求してもよい。時によって変わるこれらの特定の深度テストは、そのときのパイプライン状態であると考えられてもよい。
【００２１】
ＯｐｅｎＧＬにおいてレンダラ（パイプライン）状態として考えられるパラメータは、前記参照されたＯｐｅｎＧＬ仕様書（バージョン１．２、１９３乃至２１７ページ）の第６．２節において確認されている。
【００２２】
基本的に、レンダラによって使用されるデータ又は情報は２種類ある：（１）パー・バーテックス・データと考えられてもよいプリミティブ・データ、及び（２）それ以外のすべてであるパイプライン状態データ（又は単にパイプライン状態）である。この違いは、一定の情報項目を、パイプライン状態又は非パイプライン状態のいずれかとして扱うグラフィックス・レンダラを実行する方法があるので、特定の規則としてよりもガイドライン（guideline）として考えられるべきである。
２．４  パー・フラグメント・オペレーション（per-fragment operations）
包括的３Ｄグラフィックス・パイプラインにおいて、「ｚバッファされたブレンド」ステップは、実際には、多くのより小さい「パー・フラグメント」オペレーションのステップを取り入れる。
【００２３】
ＯｐｅｎＧＬ（オープン・グラフィックス・ライブラリ（Open Graphics Library）及びＤ３Ｄ等、アプリケーション・プログラム・インターフェース（ＡＰＩｓ（Application Program Interfaces））は、一組のパー・フラグメント・オペレーションを定義する（バージョン１．２ＯｐｅｎＧＬ仕様書の第４章を参照）。本発明の構造並びに方法と、従来の構造並びにプロシージャとの間の包括的な類似性及び相違が、簡単に理解できるように、例示的なＯｐｅｎＧＬパー・フラグメント・オペレーションを簡潔に検討する。
【００２４】
ＯｐｅｎＧＬの下で、フレーム・バッファは、一組のピクセルを、二次元アレイとして記憶する。フレーム・バッファに記憶された各ピクチャ・エレメント（picture-element）又はピクセルは、単純に一組のいくつかのビットである。ピクセルごとのビット数は、特定のＧＬ実行又はコンテクストによって変化してもよい。フレームバッファにおける各ピクセルからの対応するビットは、共にビットプレーン（bitplane）にグループ分けされる；各ビットプレーンは、各ピクセルからの単一のビットを含む。ビットプレーンは、色、深度、ステンシル（stencil）、及び蓄積バッファとして称されるいくつかの論理バッファにグループ分けされる。色バッファは順に、ＯｐｅｎＧＬ下で左前バッファ（front left buffer）、右前バッファ（front right buffer）、左後ろバッファ（back left buffer）、右後ろバッファ（back right buffer）及びいくつかの追加の補助バッファと称されるものを含む。前方バッファに記憶された値は、表示モニタに通常表示される値である一方で、後方バッファ及び補助バッファの内容は、不可視であり表示されない。立体的なコンテクストは、左前及び右前バッファの両方を表示する一方で、モノスコーピックな（monoscopic）コンテクストは、左前バッファのみを表示する。一般的に、色バッファは、同じ数のビットプレーンを有していなければならないが、コンテクストの特定の実行は、右バッファ、後方バッファ、又は補助バッファをまったく供給しなくてもよく、実行又はコンテクストは、追加的に、ステンシル、深度又は蓄積バッファを供給し又は供給しなくてもよい。
【００２５】
ＯｐｅｎＧＬの下で、色バッファは、符号のない整数の色インデックス又はＲ，Ｇ，Ｂ及び任意で符号のない整数値の数字“Ａ”のいずれかを含む；及び色バッファ、深度バッファ（供給される場合）、ステンシル・バッファ（供給される場合）、及び蓄積バッファ（供給される場合）の各々におけるビットプレーンの数は、固定され及びウィンドウ依存である。蓄積バッファが供給される場合、少なくともＲ，Ｇ及びＢ色コンポーネントごとのビット・プレーンを、色バッファと同じだけ有する。（Ｘw，Ｙw）のウィンドウ座標でのラステライゼーション（rasterization）によって作られたフラグメントは、多くのテスト、パラメータ及び条件に基づいて、その場所で、フレームバッファにおけるピクセルを変更する。順番に、フラグメント及びそれに関連するデータで始まり、フレームバッファへの最終出力ストリームで終わる、通常実行されるいくつかのテストの中で、特筆すべきは、実行される順番（及びＡＰＩの中でのいくつかのバリエーション（variation）を有する）である：１）ピクセル・オーナシップ・テスト；２）シザー（scissor）・テスト；３）アルファ（alpha）・テスト；４）色テスト；５）ステンシル・テスト；６）深度テスト；７）ブレンディング；８）ディザリング（dithering）；及び９）ロジコップ（logicop）である。ＯｐｅｎＧＬが、アルファ・テストとステンシル・テストとの間の明確な「色テスト」を供給しないことが、注目される。ＯｐｅｎＧＬ下でのパー・フラグメント・オペレーションは、すべての色計算の後に適用される。これらのテスト又はオペレーションの各々は、簡潔に後述される。
２．４．１  オーナシップ・テスト
ＯｐｅｎＧＬの下で、ピクセル・オーナシップ・テストは、フレームバッファにおける（Ｘw，Ｙw）という場所でのピクセルが、現在ＧＬコンテクストによって所有されているか決定する。所有されていない場合、ウィンドウ・システムは、入力フラグメントの運命を決定する。前記フラグメントが放棄され、又は引き続くパー・フラグメント・オペレーションのあるサブセットが、前記フラグメントに適用されることが、可能性のある結果である。このピクセル・オーナシップ・テストは、ウィンドウ・システムに、適切にＧＬの振舞いを制御させる。
【００２６】
表示スクリーンを有するコンピュータにおいて、一つ又はいくつかの処理が実行され、及び各処理は、表示スクリーン上にウィンドウを有することが仮定される。各処理に関して、関連するウィンドウは、前記処理が書き込み又はレンダリングしたいピクセルを定義する。二つ以上のウィンドウがある場合、一つの処理に関連するウィンドウは、他の処理に関連するウィンドウの前か、前記ウィンドウの後ろか、又は両方のウィンドウが完全に可視でもよい。全体の表示スクリーン又はデスクトップに関して、一つのフレーム・バッファしかないので、ピクセル・オーナシップ・テストは、どの処理、及び関連するウィンドウが、前記ピクセルの各々を所有するか決定することを伴う。特定の処理が、ピクセルを「所有」しない場合、フレーム・バッファに関連したピクセル・オーナシップ・テストに失敗し、及び前記ピクセルは捨てられる。典型的なパラダイム（paradigm）の下では、ピクセル・オーナシップ・テストは、各処理ごとに実行され、及びフレーム・バッファにおける一定のピクセルの場所に関しては、前記ピクセルは前記処理の一つに関してピクセル・オーナシップ・テストを通過し、及び他の処理に関してピクセル・オーナシップ・テストに失敗してもよいことが注目される。さらに、一般的には、特定のピクセルが、一つだけの処理に関して、オーナシップ・テストを通過することができるのは、たった一つ処理が、同時に特定のフレーム・バッファピクセルを所有することができるからである。
【００２７】
いくつかのレンダリング体系において、ピクセル・オーナシップ・テストは、特に関連しなくてもよい。例えば、シーンがオフスクリーン・バッファ（off-screen buffer）にレンダリングされている場合、及び引き続きデスクトップにブロック転送され又はブリットされ（"blitted"）る場合、ピクセル・オーナシップは、実際は関連さえしない。各処理が自動的に、又は必ず、ピクセル・オーナシップ・テストを通過するのは（それが実行される場合）、各処理は、そのオフスクリーン・バッファを有効に所有し、及び前記バッファの前には何もないからである。
【００２８】
特定の処理に関して、前記ピクセルが、前記処理によって所有されない場合、前記場所へピクセル値を書き込む必要はなく、及び前記ピクセルに関するすべての連続する処理は無視されてもよい。通常のワークステーションにおいて、スクリーン上の特定のピクセルに関連するすべてのデータは、ラステライゼーションの間に読み取られる。ｚバッファ、色値、古い色値、アルファ値、ステンシル・ビット、等と同様に、フレーム・バッファ・ピクセルを所有する処理のアイデンティティ（identity）に関する情報を含む、前記ピクセルを送るあらゆるポリゴンに関するすべての情報が読み取られる。一つの処理が前記ピクセルを所有する場合、他のダウンストリーム（downstream）処理が実行される（例えば、シザー・テスト、アルファ・テスト等）。他方で、前記処理がピクセルを所有せず、及び前記ピクセルに関するオーナシップ・テストに失敗する場合、前記処理は、前記ピクセルをさらに考慮する必要はなく、前記ピクセルは連続するテストへと省かれる。
２．４．２  シザー・テスト
ＯｐｅｎＧＬの下で、シザー・テストは、左下（左、下）座標、長方形の幅、及び長方形の高さに対応する四つの座標値によって定義される、シザー長方形の中に（Ｘw，Ｙw）があるか決定する。前記値は、「無効シザー（ｉｎｔｌｅｆｔ，ｉｎｔ  ｂｏｔｔｏｍ，ｓｉｚｅｉ  ｗｉｄｔｈ，ｓｉｚｅｉ  ｈｅｉｇｈｔ）」のプロシージャで、ＯｐｅｎＧＬの下、設定される。
0003657518.tif 000002
及び
0003657518.tif 000003
である場合、シザー・テストは通過する；そうでなければ、シザー・テストは失敗し、及びテストされる特定のフラグメントは放棄される。様々な初期状態が供給され、及びエラー条件が監視され、報告される。
【００２９】
単純に見ると、長方形は、オンスクリーン又はオフスクリーンのウィンドウでもよいウィンドウを定義する。前記ウィンドウは、ｘ−左、ｘ−右、ｙ−上部、及びｙ−低部座標によって定義される（それが前記点からの点及び高さ及び幅に関して表現されていても）。このシザー・ウィンドウは、スクリーンを割り当てられたシザー・ウィンドウに入るポリゴン・フラグメントからのピクセルだけが変化するという点で、有用である。ポリゴンがシザー・ウィンドウをまたぐ場合には、シザー・ウィンドウの中にあるピクセルのみが変化してもよい。
【００３０】
ＯｐｅｎＧＬマシンにおけるポリゴンが、パイプラインに下りる時、パイプラインは、前記ピクセルのｚ値及び色を決定するために計算する必要があるものすべてを計算する。一度、ｚ値及び色が決定されると、どの情報がフレーム・バッファに配置されるのか決定するために、前記情報が使用される（それによって、表示スクリーンに何が表示されるのかを決定する）。
【００３１】
ピクセル・オーナシップ・テストのように、シザー・テストは、出力を変更させるためのフレーム・バッファに実際に到達する前に、ピクセル及び／又はフラグメントを廃棄するための手段を供給する。
２．４．３  アルファ・テスト
色は、四つの値、赤（Ｒ）、緑（Ｇ）、青（Ｂ）、及びアルファ（Ａ）で定義される。ＲＧＢ値は、各原色からのコントリビューション（contribution）を定義し、及びアルファは、透明性に関連する。通常、色は３２ビット値であり、各コンポーネントに８ビットであるが、そのような表現は３２ビットに制限されない。アルファ・テストは、一定のピクセルのアルファ値を、アルファ参照値と比較する。例えば、前記比較が、グレーター・ザン・（greater-than）オペレーション、レス・ザン・（less-than）オペレーション等になるように、比較の種類が特定されてもよい。前記比較が、グレーター・ザン・オペレーションである場合、ピクセルのアルファ値は、アルファ・テストを通過するためには、参照よりも大きくなければならない。ゆえに、ピクセルのアルファ値が０．９であり、参照アルファは０．８であり、及び前記比較はグレーター・ザンである場合、前記ピクセルは、アルファ・テストを通過する。アルファ・テストを通過しないピクセルは、捨てられるか廃棄される。ＯｐｅｎＧＬ仕様書は、アルファ・テストがＯｐｅｎＧＬにおいて実行される方法を説明しており、ここではさらにそれを説明しない。
【００３２】
アルファ・テストは、パー・フラグメント・オペレーションであり、すべてのフラグメント色付け計算及びライティング並びにシェーディング・オペレーションが完了した後に、行われる。これらのパー・フラグメントオペレーションの各々は、従来のｚバッファ・ブレンディング・オペレーションの一部として考えられてもよい。
２．４．４  色テスト
色テストは、ピクセル・アルファ（Ａ）値と参照値との間のマグニチュード又は論理的比較を実行するよりも、Ｒ，Ｇ又はＢ色コンポーネントの一つ又はその組み合わせと参照値との間のマグニチュード又は論理的比較を実行する点を除き、上述のアルファ・テストと類似している。比較テストは、例えば、グレーター・ザン、レス・ザン、イコール・トゥ（equal-to）、グレーター・ザン・オア・イコール・トゥ（greater-than-or-equal-to）、「グレーター・ザンｃ1、レス・ザンｃ2」でもよく、ｃ1及びｃ2は、ソアな（sore）予め決められた参照値等である。例えば、ピクセルＲ値が、最小値と最大値の間にある場合のみ、色テストが通過されるように、参照最小Ｒ値、及び参照最大Ｒ値を特定してもよい。色テストは、例えば、青スクリーン機能を供給するために有用かもしれない。比較テストは、単一の色コンポーネント上で又は色コンポーネントの組み合わせ上で実行されてもよい。さらに、アルファ・テストに関して、各コンポーネントに一つの値があるが、色テストに関しては、各コンポーネントにつき有効な二つの値、最大値及び最小値がある。
２．４．５  ステンシル・テスト
ＯｐｅｎＧＬの下で、ステンシル・テストは、場所（Ｘw，Ｙw）におけるステンシル・バッファに記憶された値と、参照値との間の比較の結果に基づいて、フラグメントを条件付きで廃棄する。参照値が、ステンシル・バッファにおける、マスクされ、記憶された値より小さく、小さいか又は等しく、等しく、より大きいか又は等しく、より大きいか、又は等しくない場合にはいつも、ステンシル・テストが決して通過しないように、いくつかのステンシル比較機能が許可される。ＯｐｅｎＧＬの下では、ステンシル・テストが失敗する場合、入力フラグメントは廃棄される。参照値及び比較値は、複数のビット、通常は、２５６の異なる値が表示されるように８ビットを有することができる。オブジェクトが、フレーム・バッファにレンダリングされる時、ステンシル・ビットを有するタグ（tag）も、フレーム・バッファに書き込まれる。これらのステンシル・ビットは、パイプライン状態の一部である。実行するべきステンシル・テストの種類は、ジオメトリがレンダリングされる時に、特定することができる。
【００３３】
ステンシル・ビットは、様々なフィルタリング、マスキング、又はステンシリング・オペレーションを実行するために使用される。例えば、特定のフラグメントが、最後にフレーム・バッファにおける特定のピクセルに影響を与えてる場合、ステンシル・ビットは、ピクセル情報とともに、フレーム・バッファに書き込まれることができる。
２．４．６  深度バッファ・テスト
ＯｐｅｎＧＬの下で、深度バッファ・テストは、深度比較が失敗した場合、入力フラグメントを廃棄する。前記比較は、ＯｐｅｎＧＬシンボリック（symbolic）定数ＤＥＰＴＨ＿ＴＥＳＴを使用する包括的イネーブル（Enable）及びディスエーブル（Disable）コマンドによって、可能にされ又は不能にされる。深度テストが不能にされる時、深度比較及びそれに続く深度バッファ値への可能な更新が回避され、及びフラグメントは次のオペレーションに渡される。ステンシル・ビットも関与しており、テストが回避された場合でも変更される。ステンシル値は、深度バッファ・テストが通過した場合に変更される。深度テストが可能にされる場合、深度比較が起こり、深度バッファ及びステンシル値が引き続き変更されてもよい。深度テストがＯｐｅｎＧＬにおいて実行される方法は、ＯｐｅｎＧＬ仕様書の１４５ページにおいて、より詳細に説明されている。
【００３４】
深度比較が実行され、そこで可能な結果は以下のとおりである：深度バッファ・テストは、入力フラグメントのＺw値が、入力フラグメントの（ｘw，ｙw）座標によって与えられる場所において記憶された深度値より、小さいか、小さいか又は等しいか、等しいか、より大きいか、より大きいか又は等しいか、又は等しくない場合、常に、決して通過しない。深度バッファ・テストが失敗する場合、入力フラグメントは廃棄される。フラグメントの（ｘw，ｙw）座標におけるステンシル値は、深度バッファ・テストの失敗に対して現在有効である関数に従って、更新される。そうでなければ、フラグメントは、次のオペレーションへと続き、フラグメントの（ｘw，ｙw）の場所における深度バッファの値は、フラグメントのｚw値に設定される。この場合において、ステンシル値は、深度バッファ・テストの成功に関して現在有効である関数に従って、更新される。必要なＯｐｅｎＧＬ状態は、値が８の整数と、及び深度バッファリングが可能にされるのか不能にされるのかを示す単一のビットである。
２．４．７  ブレンディング（Blending）
ＯｐｅｎＧＬの下で、ブレンディングは、入力フラグメントのＲ，Ｇ，Ｂ及びＡ値を、入力フラグメント（ｘw，ｙw）の場所において、フレームバッファに記憶されたＲ，Ｇ，Ｂ，及びＡ値と結合させる。
【００３５】
このブレンディングは、通常は入力フラグメントのアルファ値（Ａ）及び、対応するフレーム・バッファに記憶されたピクセルのそれに依存する。次の検討において、Ｃｓは、入力フラグメントに関するソース色（source color）であり、Ｃｄは対応するフレームバッファの場所におけるデスティネーション色（destination color）であり、及びＣｃは、ＧＬ状態におけるコンスタント色（constant color）である。これらの色の個別のＲＧＢＡコンポーネントは、それぞれｓ、ｄ及びｃの添字によって表示される。
【００３６】
ブレンディングは、基本的には、フレームバッファにおける色及びフラグメントにおける色を取り、及びそれらを混ぜる。ブレンディングが達成される方法、すなわち特定のブレンディング関数は、ソースとデスティネーションの両方に関して、様々な代替から選択されてもよい。
【００３７】
ブレンディングは、ＯｐｅｎＧＬ仕様書の１４６乃至１４９ページに説明されており、ここに参照のために採用されている。様々なブレンド方程式が、ＯｐｅｎＧＬの下、利用可能である。例えば、ソース色（Ｃｓ）とソース付加要素４つ（Ｓ）の積を、デスティネーション色（Ｃｄ）とデスティネーション付加要素（Ｄ）４つの積に加えることによって、すなわちＣ＝ＣsＳ＋ＣdＤによって、ブレンド結果（Ｃ）が得られる、加法的タイプのブレンドが利用可能である。代替的に、ブレンド方程式は、減法（Ｃ＝ＣsＳ−ＣdＤ）、逆の減法（Ｃ＝ＣdＤ−ＣsＳ）、最小関数（Ｃ＝ｍｉｎ（Ｃs，Ｃd））、最大関数（Ｃ＝ｍａｘ（Ｃs，Ｃd））でもよい。ＯｐｅｎＧＬの下、ブレンディング方程式は、各色コンポーネント及びそれの対応する付加係数に関して、個別に評価される。４つのＲ，Ｇ，Ｂ，Ａコンポーネントの各々は、それぞれの付加要素を有する。
【００３８】
ブレンディング・テスト（又はブレンディング方程式）は、パイプライン状態の一部であり、及び潜在的にすべてのポリゴンに対して変化することができるが、より一般的には、作られたオブジェクト又はいくつかのポリゴンに対してのみ変化するであろう。
【００３９】
通常、ブレンディングが、ピクセル・オーナシップ・テスト及びステンシル・テスト等、他のテストが通過した場合のみ、実行されるのは、検討中のピクセル又はフラグメントが、出力に効果を有するであろう、又は有しうることが明白だからである。
２．４．８  ディザリング
ＯｐｅｎＧＬの下で、ディザリングは、二つの色値又はインデックスの間で選択する。ＲＧＢＡモードにおいて、バイナリ・ポイントの左に、ｍビットを有する固定点値としての色コンポーネントのいずれかの値を検討し、ｍはフレームバッファにおける前記コンポーネントに割り当てられたビットの数である；そのような各値をｃと称する。各ｃに関して、ディザリングは、ｃ１∈｛ｍａｘ｛０，［ｃ］−１，［ｃ］｝になるように、値ｃ１を選択する。この選択は、ピクセルのｘw及びｙw座標に依存してもよい。色インデックス・モードにおいて、同じ規則が適用され、ｃは単一の色インデックスである。ｃの値は、コンポーネント又はインデックスのいずれかに関して、フレームバッファにおいて表示可能な最大値よりも大きくてはならない。
【００４０】
多くのディザリング・アルゴリズムが可能であるが、あらゆるアルゴリズムによって生成されたディザリングされた値は、通常は、入力値及びフラグメントのｘ並びにｙウィンドウ座標にのみ依存しなければならない。ディザリングが不能にされる時、各色コンポーネントは、対応するフレームバッファ・コンポーネントにあるのと同じだけのビットを有する固定点値に切り捨てられ、色インデックスは、フレームバッファの色インデックス部分において表示可能な最も近い整数に四捨五入される。
【００４１】
ディザリングのＯｐｅｎＧＬ仕様は、ＯｐｅｎＧＬ仕様書、特に１４９乃至１５０ページにおいて、より完全に説明されており、それは参照のためにここに採用されている。
２．４．９  ロジコップ（Logicop）
ＯｐｅｎＧＬの下で、入力フラグメントの色又はインデックス値と、対応する場所におけるフレーム・バッファに記憶された色又はインデックス値との間に適用される、最終の論理的オペレーションがある。論理的オペレーションの結果は、フラグメントの（ｘ，ｙ）座標でのフレームバッファにおける値と入れ替わる。例えば、：ｃｌｅａｒ，ｓｅｔ，ａｎｄ，ｎｏｏｐ，ｘｏｒ，ｏｒ，ｎｏｒ，ｎａｎｄ，ｉｎｖｅｒｔ，ｃｏｐｙ，ｉｎｖｅｒｔｅｄ  ａｎｄ，ｅｑｕｉｖａｌｅｎｃｅ，ｒｅｖｅｒｓｅ  ｏｒ，ｒｅｖｅｒｓｅ  ａｎｄ，ｉｎｖｅｒｔｅｄ  ｃｏｐｙ，及びｉｎｖｅｒｔｅｄ  ｏｒを含む、様々な論理的オペレーションが、ソース（ｓ）とデスティネーション（ｄ）の間で実行されてもよい。ロジコップの議論及び対応するオペレーションは、ＯｐｅｎＧＬロジコップ実行の追加の詳細と同様に、ＯｐｅｎＧＬ仕様書の１５０乃至１５１ページにおいて説明されている。論理的オペレーションは、書き込みのために選択される各色インデックス・バッファに関して、又は書き込みのために選択される各色バッファの各赤、緑、青及びアルファ値に関して、独立して実行される。要求される状態は、論理的オペレーションを示す整数と、及び論理的オペレーションが可能にされたか又は不能にされたかを示す２ビットである。
２．５  アンチエイリアシング（Antialiasing）
本明細書において、ピクセルは、表示装置の最小の、個別に制御可能なエレメントのことである。しかし、画像は離散ピクセルへと量子化されるので、空間的なエイリアスが起こる。通常のエイリアスの人為的な結果は、直線又はエッジが、ピクセルの列を対角線に断つ時に起こる「階段（staircase）」効果である。
【００４２】
いくつかのレンダリング・システムは、ピクセルをサブピクセルに分割することによって、エイリアス効果を低減させ、各サブピクセルは、個別に色付けすることができる。画像が表示されるべき時は、各ピクセル内のすべてのサブピクセルに関する色は、前記ピクセルに関する平均的な色を形成するためにブレンドされる。ピクセルごとに１６までのサブピクセルを使用するレンダラは、「リアリティ・エンジン・グラフィックス（Reality Engine Graphics）」、アクリー（Akeley）、ＳＩＧＧＲＡＰＨ９３会報の１０９乃至１１６ページ、１９９３年８月１−６日、コンピュータ・グラフィックス会報、年次会議シリーズ、ニューヨーク、ＡＣＭ  ＳＩＧＧＲＡＰＨ、１９９３年出版、ソフトカバーＩＳＢＮ０−２０１−５８８８９−７及びＣＤ−ＲＯＭ  ＩＳＢＮ０−２０１−５６９９７−３に記載されている（以後、アクリー参照と称する）。
【００４３】
他の従来技術のアンチエイリアシング方法は、ブレンディングを実行するために使用されるＡバッファであり（この技術も、アクリー参照に含まれる）、及び「Ａバッファ、アンチエイリアスされた隠れ面方法（Antialiased Hidden Surface Method）」、Ｌ．カーペンタ（L.Carpenter）著、ＳＩＧＧＲＡＰＨ１９８４会議会報、１０３乃至１０８ページに記述されている（以後、カーペンタ参照と称する）。Ａバッファは、レンダリングされたポリゴンによって、ピクセルのパーセント・カバレージ（percent coverage）を追跡することによって、エイリアスを低減させるアンチエイリアシング技術である。この技術の主な欠点は、受け入れ可能なアンチエイリアスされたポリゴンを得るために、各ピクセルにおいて前から後ろへ（又は後ろから前へ）ポリゴンをソートする（sort）必要性である。
２．６  コンテント・アドレッサブル・メモリ（Content Addressable Memories）
ほとんどのコンテント・アドレッサブル・メモリ（ＣＡＭ）は、入力ベクトル（input vector）とＣＡＭに記憶されたデータ・ワード（data words）の各々との間で、ビット対ビットの同等性テストを実行する。この種類のＣＡＭは、すべてのワードにおける対応するビットが、同等性テストに影響を与えないようにするために、ビット位置のマスキング（masking）をしばしば供給する。多くのクロック・サイクルがタスク（task）をするよう要求されるので、同等性テストをするＣＡＭにおけるマグニチュードの比較を実行することは、非効率的である。ＣＡＭは、いくつかのコンピュータにおける仮想メモリ・システム内におけるトランスレーション・ルックアサイド・バッファ（translation look-aside buffer）において現在使用されている。ＣＡＭはまた、高速コンピュータ・ネットワークにおいてアドレスを適合するためにも使用される。
【００４４】
マグニチュード比較ＣＡＭ（Magnitude Comparison CAM）（ＭＣＣＡＭ）は、ここでは、記憶されたデータが数として扱われるＣＡＭとして定義され、及び演算マグニチュード比較（すなわち、レスザン、グレーター・ザン、レス・ザン・オア・イコール・トゥ、等）が、並行してデータ上で実行される。これは、記憶されたデータを厳格に、数としてではなく、ビット・ベクトルとして扱う通常のＣＡＭと反対である。ＭＣＣＡＭ特許は、ここに参照として含まれており、アメリカ合衆国特許第４，９９６，６６６号、ジェローム・Ｆ．ドュルック・ジュニア（Jerome F. Duluk Jr.）の「完全な並行マグニチュード比較ができるコンテント・アドレッサブル・メモリ・システム（Content-Addressable Memory System Capable of Fully Parallel Magnitude Comparisons）」、１９９１年２月２６日付与（以後、ドュルック特許と称する）である。特定的に参照されるドュルック特許の中の構造は、「ドュルック特許」という接頭語を含む（例えば、「ドュルック特許ＭＣＣＡＭビット・サーキット」）。
【００４５】
ＭＣＣＡＭの基本的な内部構造は、ワードに編成された一組のメモリ・ビットであり、各ワードは、記憶されたデータと入力データとの間の一つ以上の演算マグニチュード比較を実行することができる。通常は、ＭＣＣＡＭに関して、数のベクトルが、並行して一列のワードに適用される時、すべてのワードにおけるすべての演算比較は並行して起こる。そのような並行探索比較オペレーションは、記憶されたデータの「クエリ（query）」と称される。
【００４６】
ここに記載された発明は、クロック・サイクルごとにすべてのクエリの結果を出力し、及び追加の出力を形成するために、これらの出力クエリ結果ビットを論理的に「オアする（or）」能力を含む、様々な特性を加えることによって、ＭＣＣＡＭの機能を増補する。
（発明の開示）
本発明の特徴の概観−トップ・レベル・サマリ（Top Level Summary）
コンピュータ・グラフィックスは、コンピュータでピクチャ（picture）や画像を生成する技術及び科学である。このピクチャ生成は一般的にレンダリングと称される。例えば、３次元アニメーション（animation）における動きの外観は、画像のシーケンス（sequence）を表示することによって達成される。対話式３次元（３Ｄ）コンピュータ・グラフィックスは、ユーザに、自らのビューポイントを変え、又はリアルタイムでジオメトリを変えさせ、それによって、レンダリング・システムが、リアルタイムで稼動中の新しい画像を生成することを要求する。それゆえに、高品質の画像とともに、色におけるリアル・タイム・パフォーマンスは、次第に重要になっている。
【００４７】
本発明は、新しいグラフィックス・プロセッサ及び方法のためのものであり、専用サブシステム、サブプロセッサ、装置、アーキテクチャ（architecture）、及び対応するプロシージャを含む、多くのサブストラクチャを含む。本発明の実施形態は、ディファード・シェーディング、タイルド・フレーム・バッファ（tiled frame buffer）、及び複数段階隠れ面除去処理の一つ以上を、他の構造及び／又はプロシージャと同様に、含んでもよい。本明細書において、このグラフィックス・プロセッサは、以後ＤＳＧＰ（ディファード・シェーディング・グラフィックス・プロセッサ（Deferred Shading Graphics Processor））又はＤＳＧＰパイプラインと称されるが、パイプラインと称されることもある。
【００４８】
本発明は、ＤＳＧＰパイプラインの多くの実施形態を含む。本発明の実施形態は、フォン・シェーディング、サブピクセル・アンチエイリアシング、及びハードウェアにおけるテクスチャ並びにバンプ・マッピングを、高性能３Ｄグラフィックスに供給するよう設計されている。ＤＳＧＰパイプラインは、性能を犠牲にすることなく、これらの洗練された特性を供給する。
【００４９】
ＤＳＧＰパイプラインは、例えば、可能なインターフェースの選択肢の中でも、アドバンスド・グラフィックス・ポート（ＡＧＰ（Advanced Graphics Port））及び／又はＰＣＩバス・インターフェース（bus interface）に限定されないが、それらを含む、様々な可能なインターフェースを介して、コンピュータに接続することができる。ＶＧＡ及びビデオ出力も通常は含まれる。本発明の実施形態は、ＯｐｅｎＧＬ及びＤｉｒｅｃｔ３Ｄ  ＡＰＩの両方をサポートする。ＯｐｅｎＧＬグラフィックス・システム：仕様書（バージョン１．２）（The OpenGL Graphics System: A Specification (Version 1.2)）」、マーク・シーガル（Mark Segal）及びカート・アクリー（Kurt Akeley）著、ジョン・リーチ（Jon Leech）編、という題名のＯｐｅｎＧＬ仕様書が、参照のために含まれる。
【００５０】
ディファード・シェーディング・グラフィックス・パイプラインのいくつかの例示的な実施形態又はバージョンが、ここに記載されている。
３．１  ディファード・シェーディング・グラフィックス・パイプラインのバージョン
ディファード・シェーディング・グラフィックス・パイプラインのいくつかのバージョン又は実施形態が、ここに記載されており、及び特性の様々な組み合わせを有する実施形態が実行されてもよい。さらに、本発明の特性は、他の特性から独立して、実行されてもよい。上述の重要な特性のほとんどは、ＤＳＧＰパイプラインのすべてのバージョンに適用することができる。
３．１．１  タイル（tiles）、スタンプ（stamps）、サンプル（samples）、及びフラグメント（fragments）
３Ｄグラフィックス・プリミティブの各フレーム（シーン又はユーザ・フレームとも称される）は、表示スクリーン上で、３Ｄウィンドウへとレンダリングされる。ウィンドウは、ピクセルの四角形グリッド（rectangular grid）を含み、及び前記ウィンドウは、タイルに分割される（以後、タイルは、１６×１６ピクセルと仮定されるが、どのようなサイズでもよい）。タイルが使用されない場合、ウィンドウは、一つのタイルであると考えられる。各タイルはさらに、スタンプに分割される（以後、スタンプは２×２ピクセルであると仮定され、それによって１タイルにつき６４スタンプを生むが、スタンプは、一つのタイルの中でどのようなサイズでもよい）。各ピクセルは、一つ以上のサンプルを含み、各サンプルは、それ自身の色値及びｚ値を有する（以後、ピクセルは、４つのサンプルを含むと仮定されるが、どのような数が使用されてもよい）。フラグメントは、特定のピクセル内のプリミティブによって覆われたサンプルの集まりである。「フラグメント」という用語は、特定のプリミティブ及び特定のピクセル内の可視サンプルの集まりを記述するためにも使用される。
３．１．２  ディファード・シェーディング
通常のＺバッファ・レンダリングにおいて、レンダラは、各プリミティブの各ピクセルに関して、色値（ＲＧＢ又はＲＧＢＡ）及びｚ値を計算し、新しいピクセルのｚ値を、Ｚバッファにおける現在のｚ値と比較する。ｚ値比較が、新しいピクセルが、フレーム・バッファにおける現存するピクセルの「前に」あることを示す場合、新しいピクセルは、古いものを上書きする；そうでなければ、新しいピクセルは、捨てられる。
【００５１】
Ｚバッファ・レンダリングはよく作動し、また複雑なハードウェアを必要としない。しかしながら、シーンが多くの隠れ面を含む場合、それは通常、多くの浪費された処理努力という結果を生む。複雑なシーンでは、前記レンダラは、最終ピクチャにおいて可視であるピクセルの１０倍又は２０倍のピクセルに関する色値を計算してもよい。これは、―フォン・シェーディング又はテクスチャ・マッピング等―パー・ピクセル・オペレーションの計算コストが、１０倍又は２０倍にされることを意味する。１ピクセルあたりの面の数は、全体のフレームに平均化されており、前記フレームの深度計算複雑性とよばれる。従来のｚバッファード・レンダラにおいて、前記深度計算複雑性は、特定のフレームをレンダリングする時の、前記レンダラの非効率性の基準となる。
ディファード・シェーディングを実行するパイプラインにおいて、隠れ面除去（ＨＳＲ）は、あらゆるピクセル・カラリングが行われる前に完了される。ディファード・シェーディング・パイプラインの目的は、最終画像（すなわち、正確なＨＳＲ）に現れるプリミティブのみに関して、ピクセル色を生成することである。ディファード・シェーディングは、一般的に、ＨＳＲが開始することができる前に、プリミティブが蓄積されることを要求する。不透明なピリミティブだけを有するフレームに関して、前記ＨＳＲ処理は、すべてのピクセル内の各サンプルおいて、単一の可視プリミティブを決定する。一つのサンプルに対し、可視プリミティブが一度決定されると、前記サンプル場所におけるプリミティブの色が決定される。さらなる効率が、パー・サンプル色を計算するよりもむしろ、同じピクセル内の全てのサンプルに関して、単一のパー・ピクセル色を決定することによって達成されうる。
【００５２】
プリミティブの少なくともアルファ・ブレンディング（以前に参照されたＯｐｅｎＧＬ仕様書に定義されたとおり）を有するフレームに関して（通常、透明性による）、２つ以上のプリミティブによって色付けられるいくつかのサンプルがある。これは、前記ＨＳＲ処理が，サンプルごとの一組の可視プリミティブを決定しなければならないことを意味している。
【００５３】
ＯｐｅｎＧＬ等、いくつかのＡＰＩにおいて、前記ＨＳＲ処理は、プリミティブを廃棄できる他のオペレーション（すなわち、深度テスト以外のオペレーションによる）によって複雑にされうる。これらの他のオペレーションは、：ピクセル・オーナシップ・テスト、シザー・テスト、アルファ・テスト、色テスト、及びステンシル・テスト（本明細書の別のところで記載されたとおり）を含む。これらのオペレーションのいくつかは、その色に基づいてプリミティブを廃棄し（アルファ・テスト等）、それは、前記ＨＳＲ処理の後まで、ディファード・シェーディング・パイプラインにおいては決定されない（これは、アルファ値が、しばしば、テクスチャリング処理によって生成され、ピクセル・フラグメント・カラリングに含まれるからである）。例えば、通常は、より離れたプリミティブ（一般的により大きいｚ値で）を不明瞭にするプリミティブは、アルファ・テストによって廃棄されることができ、それにより、それが前記のより離れたプリミティブを不明瞭にしないようにする。アルファ・テストを考慮しないＨＳＲは、前記のより離れたプリミティブを誤って廃棄するかもしれない。それゆえに、ディファード・シェーディングとアルファ・テストとの間に（同様に、色テストとステンシル・テストとの間にも）矛盾があるかもしれない；すなわち、ピィクセル・カラリングは隠れ面除去の後まで延期されるが、隠れ面除去はピクセル色に依存することができる。この問題に対する簡単な解決方法は次のものを含む：１）アルファ・テスト、色テスト、及びステンシル・テスト等、ＡＰＩから非深度依存テストを取り除くことであるが、この潜在的な解決方法は、現存するプログラムが、前記ディファード・シェーディング・パイプライン上で、適切に実行すること妨げるかもしれない；及び２）必要とされる時のみ、前記ＨＳＲ処理に、ある色の生成をさせることであるが、この潜在的な解決方法は、データ・フローをかなり複雑にするであろう。それゆえ 、これらの選択のどちらも魅力がない。３番目の選択肢は、保存性（conservative）隠れ面除去（ＣＨＳＲ）と呼ばれ、本発明の構造及び方法によって供給される、重要な革新の一つである。ＣＨＳＲは本明細書の連続した節において詳細に記述されている。
【００５４】
多くのＡＰＩにおける他の複雑性は、前記深度テストを変える能力である。３Ｄレンダリングについての標準的な考え方は、可視のオブジェクトが不明瞭なオブジェクト（すなわち、より少ないｚ値で）よりも近いことを仮定し、及びこれは、レス・ザン深度テストによって達成される（すなわち、そのｚ値が他のジオメトリより少ないならば、オブジェクトは可視である）。しかしながら、ほとんどのＡＰＩは、グレーター・ザン、レス・ザン、グレーター・ザン・オア・イコール・トゥ、イコール、レス・ザン・オア・イコール・トゥ、レス・ザン、ノット・イコール、及び代数的、マグニチュード、並びに論理的関係等、他の深度テストをサポートする。これは、本質的に可視であるものに関する「規則を変える」。この複雑性は 、一つのＡＰＩが、フレーム内の深度テストを、アプリケーション・プログラムに変えさせることによって合成される。異なるジオメトリは、可視性に関して徹底的に異なる規則に従ってもよい。それゆえに、異なるレンダリング規則を有するプリミティブのタイム・オーダが、考慮されなければならない。例えば、図４に記載の実施形態において、３つのプリミティブが、それらの個別の深度テストとともに示されている。（ｚ次元のみが図に示されているので、これは一つのサンプルに対する事例と考えられてもよい。）それらがＡ，Ｂ，それからＣのオーダでレンダリングされる場合、プリミティブＢは最終の可視面であろう。しかしながら、前記プリミティブがＣ，ＢそれからＡのオーダでレンダリングされる場合、プリミティブＡが最終の可視面であろう。これは、ディファード・シェーディング・パイプラインがどのようにプリミティブのタイム・オーダリングを維持しなければならないか、及び正しいパイプライン状態（例えば深度テスト）が各プリミティブと関連されなければならないかを示している。
３．１．３  ディファード・シェーディング・グラフィック・パイプライン、第一の実施形態（バージョン１）
従来の３Ｄグラフィック・パイプラインは、図２に記載される。図４と相対的に、本発明の３Ｄディファード・シェーディング・グラフィック・パイプライン・バージョン１（以下、ＤＳＧＰｖ１と称する）の第一の実施形態を記載する。本発明パイプライン（図４）は、描画集約的機能２３１を、（１）パイプライン状態及び各プリミティブを記述しているプリミティブ・データを記憶するためのシーン・メモリ（scene memory）２５０であって、図においてはシーン・メモリと称される；（２）正確な隠れ面除去処理２５１；（３）フラグメント・カラリング処理２５２；及び（４）ブレンディング処理２５３に置き換えることにより、包括的な従来のパイプライン（図２）から得られたことがわかるであろう。
【００５５】
シーン・メモリ２５０は、それらの属性に沿って、一つのフレームに対する前記プリミティブ・データを記憶し、及び前記フレーム全体の、パイプライン状態の様々な設定を記憶する。プリミティブ・データはバーテックス座標、テクスチャ座標、バーテックス色、バーテックス法線、等（the  like）を含む。ＤＳＧＰｖ１において、プリミティブ・データは、増分レンダリングに関するセットアップによって生成されたデータを含み、それは空間、色、及びエッジ微分（edge derivatives）を含む。
【００５６】
フレームにおけるすべてのプリミティブが、フローティング・ポイント集約的機能２１３によって処理され、及びシーン・メモリ２５０に記憶された時、ＨＳＲ処理が始まる。前記シーン・メモリ２５０は、二重にバッファされ、それにより、フローティング・ポイント集約的機能が次のフレームで計算を実行する間、前記ＨＳＲ処理に、一つのフレーム上で計算をさせる。前記シーン・メモリはまた三重にもバッファされうる。前記シーン・メモリはまた、前記ＨＳＲ処理に関するスクラッチパッドでもあり、前記ＨＳＲ処理に関する中間結果を記憶し、すべてのプリミティブが前記シーン・メモリに記憶される前に、前記ＨＳＲ処理に始動させる。
【００５７】
前記シーン・メモリにおいて、あらゆるプリミティブは、前記プリミティブがパイプラインに入力された時に有効であったパイプライン状態情報に関連する。前記パイプライン状態と各プリミティブとを関連させる最も簡単な方法は、各プリミティブ内の全体のパイプライン状態を含むことである。しかしながら、パイプライン状態の多くは、ほとんどのプリミティブの間で（特に、プリミティブが同じオブジェクトにある時）変化しないので、これは、大量の冗長な情報を導入するであろう。前記シーン・メモリに情報を記憶するための好ましい方法は、個別のリストを保存することである：パイプライン状態設定に対して一つのリスト、及びプリミティブに対して一つのリストである。さらに、前記パイプライン状態情報は多数のサブリストに分割され、各サブリストへの追加は、サブリストの部分が変わる時のみに生じる。プリミティブを記憶するための好ましい方法は、前記プリミティブを再生するための接続情報とともに、一連のバーテックスを記憶することによって行われる。プリミティブを記憶するための、この好ましい方法は、さもなければ、ポリゴン・メッシュ（polygon mesh）及びライン・ストリップ（line strip）において生じるであろう冗長なバーテックスを取り除く。
【００５８】
隠れ面除去が行われるＤＳＧＰｖ１における唯一の場所であるので、ＤＳＧＰｖ１に関して記述された前記ＨＳＲ処理は、正確な隠れ面除去（ＥＨＳＲ）であることが求められる。正確な隠れ面除去（ＥＨＳＲ）処理２５１は、どのプリミティブが前記フレーム・バッファにおけるピクセルの最終の色に影響を与えるかを精密に決定する。この処理はパイプライン状態における変化を表しており、それは前記処理にさまざまな複雑性を導入する。これらの複雑化のほとんどは、上述のとおり、パー・フラグメント・オペレーション（オーナシップ・テスト、シザー・テスト、アルファ・テスト等）に起因する。正確な隠れ面除去が必要とされないように、後述のとおり、これらの複雑性は、革新的な保存性隠れ面除去（ＣＨＳＲ）処理によって解決される。
【００５９】
前記フラグメント・カラリング処理は、ピクセル内の各サンプル又は各グループのサンプルに関する色を生成する。これは：グロー・シェーディング、テクスチャ・マッピング、フォン・シェーディング、及びピクセル色を生成するための様々な他の技術を含みうる。この処理は、プリミティブのサブセクションに関する色を、効率良く生成できなければならないので、エッジド・ウォーク（edged walk）２３２及びスパン補間２３４とは異なる。すなわち、一つのプリミティブは、部分的に可視でもよく、それゆえに、色は、そのピクセルのいくつかのみに関して生成される必要があり、及びエッジ・ウォーク及びスパン補間は、全体のプリミティブが色付けされなければならないことを仮定している。さらに、前記ＨＳＲ処理は、一つのプリミティブの多数の可視サブセクションを生成してもよく、これらは他のプリミティブの可視サブセクションの間に、早めに点在してもよい。それゆえに、前記フラグメント・カラリング処理２５２は、プリミティブ・エッジ又はｘ軸もしくはｙ軸に沿って、増分計算をする必要無く、プリミティブ内の任意の場所で、色値を生成することができるであろう。
【００６０】
本発明の実施形態の前記ブレンディング処理２５３は、ピクセルごとに単一の色を生成するため、前記フラグメントの色を結合させる。従来のｚバッファド・ブレンド処理２３６に対して、このブレンディング処理２５３は、正確な隠れ面除去処理２５１が、どのプリミティブが各サンプルにおいて可視であるかをすでに決めているので、ｚバッファ・オペレーションを含まない。前記ブレンディンッグ処理２５３は、各サンプルに関して個別の色値を維持してもよく、又はサンプル色は、全体のピクセルに関する単一の色を作るためにブレンドされてもよい。個別の色値がサンプルごとに維持され、前記フレーム・バッファ２４０に個別に記憶される場合、最終のピクセルの色は、データが、デジタル−アナログ・コンバータ２４２へ送られると、スキャン・アウト処理の間、サンプル色から生成される。
３．１．４  ディファード・シェーディング・グラッフィック・パイプライン、第２の実施形態（バージョン２）
ＤＳＧＰｖ１に関して上述されたとおり、前記シーン・メモリ２５０は：（１）プリミティブ・データ；及び（２）パイプライン状態を記憶する。図５に記載の、ディファード・シェーディング・グラフィック・パイプライン２６０（バージョン２）（ＤＳＧＰｖ２）の第２の実施形態において、このシーン・メモリ２５０は二つの部分：空間メモリ２６１部分及びポリゴン・メモリ２６２部分に分割される。データの分割は、単なるプリミティブ・データとパイプライン状態データへの分割ではない。
【００６１】
ＤＳＧＰｖ２において、ＨＳＲに必要な前記パイプライン状態データの部分は、空間メモリ２６１に記憶される一方で、残りはポリゴン・メモリ２６２に記憶される。ＨＳＲに必要なパイプライン状態の例は（例えば、前記の ＯｐｅｎＧＬ仕様書に定義されているとおり）ＤｅｐｔｈＦｕｎｃ、ＤｅｐｔｈＭａｓｋ、ＳｔｅｎｃｉｌＥｎａｂｌｅ等を含む。ＨＳＲに必要でないパイプライン状態の例は：ＢｌｅｎｄＥｑｕａｔｉｏｎ、ＢｌｅｎｄＦｕｎｃ、点描パターン等を含む。特定のブレンディング機能の選択又は識別が（例えば、Ｒ＝ＲSＡS＋Ｒ0（１−ＡS）を選択すること）、ＨＳＲに関して必要とされない一方で、前記ＨＳＲ処理は、前記プリミティブが、ブレンディングを受けるかを表さなければならず、それは、前記プリミティブが、ジオメトリに優先して、完全に遮断することができないものとして扱われることを、一般的に意味している。同様に、前記ＨＳＲ処理は、前記プリミティブがシザー・テスト、アルファ・テスト、色テスト、ステンシル・テスト、及び他のパー・フラグメント・オペレーションを受けるかを表さなければならない。
プリミティブ・データもまた分割される。ＨＳＲに必要なプリミティブ・データの部分は空間メモリ２６１に記憶され、及び前記プリミティブ・データの残りはポリゴン・メモリ２６２に記憶される。ＨＳＲに必要なプリミティブ・データの部分は、バーテックスの場所及び空間微分（すなわち、エッジに関するδｚ／δｘ、δｚ／δｙ、ｄｘ／ｄｙ等）を含む。ＨＳＲに必要でないプリミティブ・データの部分は、バーテックス色、テクスチャ座標、色微分（color derivatives）等を含む。パー・フラグメント・ライティング（per-fragment lighting）が前記パイプラインにおいて実行される場合、全体のライティング方程式は、すべてのフラグメントに適用される。しかし、ディファード・シェーディング・パイプラインにおいて、可視のフラグメントのみが、ライティング計算を必要とする。この場合、前記ポリゴン・メモリもまた、バーテックス法線、バーテックス・アイ座標、バーテックス面接線、バーテックス従法線、これら全ての属性の空間微分、及び他のパー・プリミティブ・ライティング情報を含んでもよい。
【００６２】
前記ＨＳＲ処理の間、特に前記ＨＳＲがパー・タイル・ベースで行われる場合、プリミティブの空間属性は繰り返しアクセスされる。前記シーン・メモリ２５０を、空間メモリ２６１及びポリゴン・メモリ２６２に分割することは総メモリ帯域幅を低減させる効果を有する。
【００６３】
増分レンダリング２３０に関するセットアップからの出力は、前記空間データ分離処理２６３に入力され、それは、ＨＳＲに必要なすべてのデータを、空間メモリ２６１に記憶し、前記データの残りはポリゴン・メモリ２６２に記憶する。前記ＥＨＳＲ処理２６４は、プリミティブ空間データ（例えば、バーテックス・スクリーン座標、空間微分等）及びＨＳＲ（パー・フラグメント・テスティング・オペレーションのすべての制御ビットを含む）に必要なパイプライン状態の部分を受信する。
【００６４】
可視フラグメントが前記ＥＨＳＲ２６４から出力される時、データ適合処理２６５は、前記バーテックス状態及びパイプライン状態を可視フラグメントに適合させ、及びタイル情報はタイル・バッファ２６６に記憶される。前記パイプラインの余りは、ピクセルへ／からのサンプル変換２６７、読み取り及び前記フレーム・バッファヘの書き込み、二重バッファＭＵＸ出力ルックアップ、及び前記フレームに記憶されたデータの、実際のアナログ表示装置信号値へのデジタル−アナログ（Ｄ／Ａ）変換を含む、前記スキャン・アウト処理に、主に関連する。
３．１．５  ディファード・シェーディング・グラフィック・パイプライン、第３の実施形態（バージョン３）
図６に記載された、前記ディファード・シェーディング・グラフィクス・パイプライン（バージョン３）（ＤＳＧＰｖ３）の第３の実施形態において、前記シーン・メモリ２５０はさらに二つの部分（空間メモリ２６１及びポリゴン・メモリ２６２）に分割され、さらに増分レンダリング２３０に関するセットアップは、データ分離の後、及び正確な隠れ面除去の前に起こる空間セットアップによって置き換えられる。前記パイプラインの構造及び処理の残りは、第一の実施形態に関して前述されたものから変化していない。
３．１．６  ディファード・シェーディング・グラフィックス・パイプライン、第４の実施形態（バージョン４）
図７に記載の、前記ディファード・シェーディング・グラフィックス・パイプライン（バージョン４）（ＤＳＧＰｖ４）の第４の実施形態において、第３の実施形態（図６）の正確な隠れ面除去は、保存性隠れ面除去の構造及びプロシージャによって置き替えられ、及びダウンストリーム・ｚバッファード・ブレンド（down-stream z-buffered blend）は前記ブレンディング・プロシージャと入れ替わる。
３．１．７  ディファード・シェーディング・グラフィック・パイプライン、第５の実施形態（バージョン５）
図８に記載の、前記ディファード・シェーディング・グラフィックス・パイプライン（バージョン５）（ＤＳＧＰｖ５）の第５実施形態において、正確な隠れ面除去は第３の実施形態として使用されるが、タイリングが追加され、及びタイル・ソーティング・プロシージャ（tile sorting procedure）がデータ分割の後に追加され、及び前記読み取りは、空間セットアップの前に、タイルによる。さらに、最初の３つの実施形態のポリゴン・メモリは、状態メモリと置き換えられる。
３．１．８  ディファード・シェーディング・グラフィックス・パイプライン、第６の実施形態（バージョン６）
図９に記載の、ディファード・シェーディング・グラフィックス・パイプライン（バージョン６）（ＤＳＧＰｖ６）の第６の実施形態において、第５の実施形態（図８）に記載の正確な隠れ面除去は、保存性隠れ面除去に置き換えられ、及び第５の実施形態のダウンストリーム・ブレンディングは、ｚバッファード・ブレンデイング（テスティング及びブレンディング（Testing & Blending））に置き換えられる。いくつかの特徴を示すと、二つの部分を有するシーン・メモリ、プリミティブ・データ分割又は分離、空間セットアップ、タイリング及びパー・タイル処理、保存性隠れ面除去、及びｚバッファード・ブレンディング（テスティング及びブレンディング）を含む、本発明の構造及び方法により供給される有益な特徴のいくつかを採用するので、この第６の実施形態は好まれる。
３．１．９  他の可能な実施形態（バージョン）
本発明のグラフィックス・パイプラインのいくつかの例示的な実施形態が記載され、及び図４乃至９に関して記述され、ここで供給される説明の観点から、当業者は、本発明の構造とプロシージャが、本発明の他の実施形態を供給するために、異なる組み合わせ及び置換によって実行されてもよく、また本発明が、ここで明確に識別された特定の組み合わせに限定されないことを、容易に理解するであろう。
【００６５】
３．２  重要な革新の概観
前記パイプラインはプリミティブをレンダリングし、及び本発明は、１）三角形、２）線 、及び３）点を含む一組のレンダリング可能なプリミティブに関して記述されている。３つ以上のバーテックスを有するポリゴンは前記ジオメトリ・ブロックにおいて三角形に分割されるが、前記ＤＳＧＰパイプラインは、多角四辺形又はより多くの辺を有するポリゴンをレンダリングするため、簡単に変更され得る。それゆえに、前記パイプラインは、一度三角形に分割されると、あらゆるポリゴンをレンダリングすることができるので、本発明のレンダラは、効果的にあらゆるポリゴン・プリミティブをレンダリングする。
一定のプリミティブが影響を与えるかもしれない表示スクリーン上で３Ｄウィンドウのどの部分かを識別するため、前記パイプラインは、描画されている前記３Ｄウィンドウを、「タイル及びスタンプ」と呼ばれる一連のより小さな領域へ分割する。前記パイプラインは、ディファード・シェーディングを実行し、そこでは、ピクセル色は、隠れ面除去の後まで決定されない。マグニチュード比較コンテント・アドレッサブル・メモリ（ＭＣＣＡＭ）の使用は、前記パイプラインに、隠れジオメトリ・カリング（culling）を効果的に実行させる。
３．２．１  保存性ディファード・シェーディング
本発明によって供給される中心的な考え又は発明の概念の一つは、保存性隠れ面除去（ＣＨＳＲ）に関する。前記ＣＨＳＲは、タイム・オーダで各プリミティブを処理し、及びプリミティブが接触する各サンプルに関して、深度テスト及びアルファ・テスト等、様々なＡＰＩ状態変数に基づいて、保存性決定がなされる。前記ＣＨＳＲ処理の重要な特徴の一つは、アルファ・テスト、色テスト、及びステンシル・テスト等、ＡＰＩからの非深度依存テストが、前記ＤＳＧＰパイプラインによって実行され得るとしても、色計算は、隠れ面除去の間は、実行される必要がないことである。
【００６６】
前記ＣＨＳＲ処理は、サンプルごとの有限状態装置（finite state machine）（ＦＳＭ）とみなされ得る。以後、各パー・サンプルＦＳＭはサンプル有限状態装置（ＳＦＳＭ）と呼ばれる。各ＳＦＳＭは、（１）ｚ座標情報；（２）プリミティブ情報（前記サンプル又はピクセルにおけるプリミティブの色を生成するために必要とされるあらゆる情報）；及び（３）一つ以上のサンプル状態ビット（例えば、これらのビットは、ｚ値又は複数のｚ値が正確であること又は保存力があることを指定することができる）を含むパーサンプル・データを維持する。サンプルごとの複数のｚ値が容易に使用される一方で、サンプルごとの複数の組のプリミティブ情報は高価であろう。以後、前記ＳＦＳＭは、一つのプリミティブに関するプリミティブ情報を維持すると仮定される。次の節で記述されたとおり、前記ＳＦＳＭはまた透明性情報を維持してもよく、それは、ソートされた透明性に関して使用される。
３．２．２  ＣＨＳＲ及びアルファ・テスト
アルファ・テストを取り扱う前記ＣＨＳＲの例として、図１０乃至１４、特に図１１の図を検討する。このダイアグラム（diagram）は、特定のサンプルに関して、異なるＺ座標の場所において、６つのプリミティブのレンダリング（プリミティブＡ、Ｂ、Ｃ、Ｄ、Ｅ、及びＦ）を示しており、（「深度クリア」及びレス・ザン（less-than）に設定された「深度テスト」で始まる）次の順序でレンダリングされる：プリミティブＡ、Ｂ、及びＣ（「アルファ・テスト」は不能）；プリミティブＤ（「アルファ・テスト」は可能）；及びプリミティブ Ｅ及びＦ（「アルファ・テスト」は不能）。ＺA＞ＺC＞ＺB＞ＺE＞ＺD＞ＺFであり、プリミティブＡは、最大Ｚ座標距離であることが、前記図からわかる。また、アルファ・テストは、プリミティブＤに関して可能にされるが、他のプリミティブの各々に関しては、不能にされることも注目される。
【００６７】
前記ＣＨＳＲ処理は、サンプル有限状態装置（ＳＦＳＭ）であると考えられてもよいことが、ＣＨＳＲについての以前の記述から想起される。 アルファ・テストを伴う保存性隠れ面除去処理の下で、これら６つのプリミティブを、レンダリングするためのステップは以下のとおりである：
ステップ１：深度クリアは、各サンプル有限状態装置（ＳＦＳＭ）において、次のような結果をもたらす：１）ｚ値は最大値に初期化される；２）プリミティブ情報クリアされる；及び３）サンプル状態ビットは、前記ｚ値が正確であることを示すように設定される。
【００６８】
ステップ２：プリミティブＡが、ＳＦＳＭによって処理される時、前記プリミティブは維持され（すなわち、それは可視表面に関する現在の最適な推測である）、及びこれは、前記ＳＦＳＭに：１）近（near）ｚ値として前記ｚ値ＺAを；２）色プリミティブＡに必要なプリミティブ情報；及び３）前記ｚ値（ＺA）は正確なものとしてラベル付けされることを、記憶させる。
【００６９】
ステップ３：プリミティブＢが前記ＳＦＳＭによって処理される時、前記プリミティブは維持され（そのｚ値は、プリミティブＡのそれより小さい）、及びこれは、ＳＦＳＭに：1)「近」ｚ値としてのｚ値ＺB（ＺAは廃棄される）；２）色プリミティブＢに必要とされるプリミティブ情報（プリミティブＡの情報は廃棄される）；及び３）ｚ値（ＺB）は、正確なものとしてラベル付けされることを、記憶させる。
【００７０】
ステップ４：プリミティブＣが前記ＳＦＳＭによって処理される時、前記プリミティブは廃棄され（すなわち、それは可視表面、プリミティブＢに関する現在の最善の推測によって、不明瞭にされる）、及び前記ＳＦＳＭデータは変更されない。
【００７１】
ステップ５：プリミティブＤ（アルファ・テストを可能にさせる）は、前記ＳＦＳＭによって処理される時、前記プリミティブの可視性は、それがプリミティブＢにより近いので、及びそのアルファ値は、前記ＳＦＳＭが動作する時点で不明なので、決定されることができない。どのプリミティブが、最終的に可視（プリミティブＢ又はプリミティブＤのどちらか一方）となるかに関して、決定されることができないので、（その色を生成させるために）プリミティブＢは前記パイプラインに送られ、及びプリミティブＤは維持される。以後、これはプリミティブＢの「初期ディスパッチ（early dispatch）」と呼ばれる。プリミティブＤの処理が完了する時、前記ＳＦＳＭは：１）「近」ｚ値はＺDであり、及び「遠」ｚ値はＺBであること；２）色プリミティブＤに必要とされるプリミティブ情報（プリミティブＢの情報は、初期ディスパッチを受けた）、及び３）ｚ値は保存可能としてラベル付けされる（なぜなら、近、及び遠の両方が、維持されているので）ことを記憶する。この状態で、ＳＦＳＭは、ＺDより近い一つのジオメトリが、以前のジオメトリを不明瞭にすること、ＺBより遠いジオメトリは不明瞭にされること、及びＺDとＺBとの間のジオメトリは不確定になり、可視であると見なされなければならない（従って、保存的推定がなされる）ことを決定できる。ＳＦＳＭが保存状態にあり、それが有効なプリミティブ情報を含む時、前記ＳＦＳＭ方法は、記憶されたプリミティブ情報の深度値を、近深度値と見なす。
【００７２】
ステップ６：プリミティブＥ（アルファ・テストを不能にする）は、前記ＳＦＳＭに処理される時、前記プリミティブの可視性は、前記近及び遠ｚ値の間（すなわち、ＺDとＺBとの間）にあるので、決定されることができない。しかしながら、プリミティブＥは、結果的に、正しいタイム・オーダから外れて、前記Ｚバッファド・ブレンド（好ましい実施形態におけるピクセル・ブロックの部分として後述されている）に届くプリミティブ生むかもしれないので、この時点では前記パイプラインへ送られない。それゆえに、プリミティブＤは、タイム・オーダリングを保存するため、前記パイプラインヘ送られる。プリミティブＥの処理が完了した時、前記ＳＦＳＭは：１）前記「近」ｚ値はＺDであり、及び前記「遠」ｚ値はＺBであること（これらは変化しておらず、及びＺEは維持されていないことに注目）；２）色プリミティブＥ（プリミティブＤの情報は、初期ディスパッチを受けている）に必要とされるプリミティブ情報；及び３）前記ｚ値は、（近及び遠の両方が維持されているので）保存可能としてラベル付けされることを、記憶する。
【００７３】
ステップ７：プリミティブＦがＳＦＳＭによって処理される時、前記プリミティブは維持され（そのｚ値は、近ｚ値のそれより小さい）、及びこれは、前記ＳＦＳＭに：１）前記「近」ｚ値としての前記ｚ値、ＺF（ＺD及びＺBは廃棄される）；２）色プリミティブＦに必要とされるプリミティブ情報（プリミティブＥの情報は廃棄される）；及び３）前記ｚ値（ＺF）は正確なものとしてラベル付けされることを、記憶させる。
【００７４】
ステップ８：前記タイルに触れるすべてのジオメトリが処理された時（又は、タイルがない場合には、前記フレームにおけるすべてのジオメトリが処理された時）、あらゆる有効なプリミティブ情報が、前記パイプラインヘ送られる。この場合、プリミティブＦの情報が送られる。これはエンド・オブ・タイル（end-of-tile）（又はエンド・オブ・フレーム（end-of-frame））ディスパッチであり、初期ディスパッチではない。
【００７５】
この例示的なＣＨＳＲ処理を要約すると、プリミティブＡ乃至プリミティブＦが処理され、プリミティブＢ、Ｄ、及びＦが前記パイプラインに送られた。パイプラインＢ、Ｄ、及びＦの可視性を分解するために、（好ましい実施形態でのピクセル・ブロックにおける）ｚバッファド・ブレンドは、前記パイプラインの終わり近くに含まれる。この例では、前記色プリミティブＦだけが前記サンプルに使用される。
３．２．２．１  ＣＨＳＲ及びステンシル・テスト
前記ＣＨＳＲ処理の好ましい実施形態において、すべてのステンシル・オペレーションは、前記パイプラインの終わり近くで行われ（ｚバッファード・ブレンドにおいては、好ましい実施形態でのピクセル・ブロックと呼ばれる）、それゆえに、ステンシル値は、前記フレーム・バッファに維持されるので、それらは前記ＣＳＨＲ方法に対して有効ではない。前記ＣＨＳＲ処理における使用のため、前記フレーム・バッファから、前記ステンシル値が送信されることが可能である一方、これは、一般的に処理能力を下げる長い待ち時間パス（latency path）を必要とするであろう。ＯｐｅｎＧＬ等のＡＰＩにおいて、前記ステンシル・テストがアルファ・テストの後に実行され、及びアルファ・テストの結果は前記ＣＨＳＲ処理に知らされないので、ステンシル値は、ＣＨＳＲ処理内に正確に維持することができず、それは、前記ステンシル・テストヘの入力が正確にモデル化されないことを意味する。さらに、レンダラは多くのフレームに対してステンシル値を維持し（一般的に、各フレームの開始においてクリアされる深度値とは対照的に）、及びこれらのステンシル値は、前記フレーム・バッファに記憶される。このことすべてによって、前記ＣＨＳＲ処理は、ステンシル・オペレーションの処理への従来のアプローチを利用する。プリミティブが、前記フレーム・バッファにおけるステンシル値に影響を与えることができる場合、ステンシル・オペレーションは、前記深度テスト（ＯｐｅｎＧＬ仕様書を参照）の前に起こるので、前記プリミティブは常に前記パイプラインに送られる（以下、これは「ＣｕｌｌＦｌｕｓｈＯｖｅｒｌａｐ」と呼ばれ、及びカル・ブロックにおける信号ＣｕｌｌＦｌｕｓｈＯｖｅｒｌａｐの主張によって示される）。ＣｕｌｌＦｌｕｓｈＯｖｅｒｌａｐの条件は、前記ＳＦＳＭを、それの最も保存力のある状態に設定する。
【００７６】
もう一つの可能性として、前記ステンシル参照値（ＯｐｅｎＧＬ仕様書を参照）が変更され、及び前記ステンシル・テストが前記フレーム・バッファにおけるステンシル値に基づいでサンプル値を廃棄するように可能にされ、及び構成される場合、前記ＳＦＳＭにおけるすべての有効なプリミティブ情報が、前記パイプラインに送られ（以下、これは「ＣｕｌｌＦｌｕｓｈＡｌｌ」と呼ばれ、及びカル・ブロックにおけるＣｕｌｌＦｌｕｓｈＡｌｌの信号の主張よって示される）、及び前記ｚ値がそれらの最大値に設定される。前記ステンシル参照値を変更することは、前記ｚバッファード・ブレンド（又はピクセル・ブロック）における「可視性規則（visibility rule）」を有効に変えるので、この「フラッシング（flushing）」が必要とされる。
【００７７】
ステンシル・テスト（ＯｐｅｎＧＬ仕様書を参照）を扱う前記ＣＨＳＲ処理の一つの例として、図１２に記載の図を検討する。それには、４つの特定サンプル（対応するＳＦＳＭを有し、ＳＦＳＭ０乃至ＳＦＳＭ３にラベル付けされる）を網羅する２つのプリミティブ（プリミティブＡ及びＣ）、及び前記４つのサンプルのうちの２つを網羅する追加のプリミティブ（プリミティブＢ）を有する。前記３つのプリミティブは次の順序でレンダリングされる（深度クリアで始まり、及び深度テストはレス・ザン（less-than）に設定される）：プリミティブＡ（ステンシル・テストは不能）；プリミティブＢ（ステンシル・テストは可能、及びＳｔｅｎｃｉｌＯｐは「ＲＥＰＬＡＣＥ」に設定される。ＯｐｅｎＧＬ仕様書を参照）；及びプリミティブＣ（ステンシル・テストは不能）である。そのステップは以下のとおりである。
【００７８】
ステップ１：前記深度クリアは、この例における４つのＳＦＳＭの各々において、次のことを生じさせる：１）ｚ値が最大値に初期化される；２）プリミティブ情報はクリアされる；及び３）サンプル状態ビットは、前記ｚ値が正しいことを示すように設定される。  ステップ２：プリミティブＡが各ＳＦＳＭによって処理される時、前記プリミティブは維持され（すなわち、可視表面に関する最近の最善の推量になる）、これは前記４つのＳＦＳＭに：１）前記近ｚ値としての、それらの対応するｚ値（それぞれ、ＺA0，ＺA1，ＺA2，又はＺA3）；２）色プリミティブＡに必要なプリミティブ情報；及び３）各ＳＦＳＭにおける前記ｚ値は、正確なものとしてラベル付けされることを記憶させる。
【００７９】
ステップ３：プリミティブＢが前記ＳＦＳＭによって処理される時、サンプル１及び２のみが影響され、ＳＦＳＭ０及びＳＦＳＭ３は影響を受けないようにされ、及びＳＦＳＭ１及びＳＦＳＭ２は、次のように更新される：１）前記遠ｚ値は最大値に設定され、前記近ｚ値は最小値に設定される；２）プリミティブＡ及びＢに関するプリミティブ情報は、前記パイプラインに送られる；及び３）サンプル状態ビットは、前記ｚ値が保存可能であることを示すように設定される。
【００８０】
ステップ４：プリミティブＣが各ＳＦＳＭによって処理される時、前記プリミティブは維持されるが、前記ＳＦＳＭが、同じ方法ですべてのプリミティブを処理するとは限らない。ＳＦＳＭ０及びＳＦＳＭ３において、前記状態は次のように更新される：１）ＺC0及びＺC3は前記「近」ｚ値となる（ＺA0及びＺA3は廃棄される）；２）色プリミティブＣに必要なプリミティブ情報（プリミティブＡの情報は廃棄される）；及び３）ｚ値は正確なものとしてラベル付けされる。ＳＦＳＭ１及びＳＦＳＭ２において、前記状態は、次のように更新される：１）ＺC1及びＺC2は、前記「遠」ｚ値になる（前記近ｚ値は維持される）；２）色プリミティブＣに必要なプリミティブ情報；及び３）前記ｚ値は保存可能としてラベル付けされたままである。
このＣＨＳＲの実例を要約すると、プリミティブＡ乃至Ｃは、処理されており、すべてのプリミティブは前記パイプラインに送られたが、すべてのサンプルにおいてではない。前記可視性を分解するために、（前記好ましい実施形態におけるピクセル・ブロックにおける）ｚバッファード・ブレンドは前記パイプラインの終わり近くに含まれる。ＣｕｌｌＦｌｕｓｈＯｖｅｒｌａｐが、他のものに影響をうけさせない間に、選択されたサンプルをフラッシュ（flush）することを説明するために、この例において多くのサンプルが示された。
３．２．２．２．ＣＨＳＲ及びアルファ・ブレンディング
アルファ・ブレンディングは、２つのプリミティブの色を一色に結合させるために使用される。しかしながら、前記プリミティブは、ｚ値の更新に関する深度テストを受ける。
【００８１】
アルファ・ブレンディングを扱う前記ＣＨＳＲの一例として、図１３を検討する。それは特定のサンプルに関する４つのプリミティブ（プリミティブＡ、Ｂ、Ｃ、及びＤ）を有し、以下の順番でレンダリングされる（深度クリアで始まり、及び深度テストはレス・ザン（less-than）に設定される）：プリミティブＡ（アルファ・ブレンディングは不能）；プリミティブＢ及びＣ（アルファ・ブレンディングは可能）；及びプリミティブＤ（アルファ・ブレンディングは不能）である。そのステップは以下のとおりである：
ステップ１：前記深度クリアは、各ＣＨＳＲ  ＳＦＳＭにおいて、以下のものをもたらす：１）ｚ値は最大値に初期化される；２）プリミティブ情報はクリアされる；及び３）サンプル状態ビットは、ｚ値が正確であることを示すように設定される。
【００８２】
ステップ２：プリミティブＡが前記ＳＦＳＭによって処理される時、前記プリミティブは維持され（すなわち、それは可視表面に対する現在の最善の推測になる）、及びこれは前記ＳＦＳＭに、１）前記「近」ｚ値としての前記ｚ値ＺA、；２）色プリミティブＡに必要なプリミティブ情報；及び３）前記ｚ値は正確なものとしてラベル付けされる、ことを記憶させる。
【００８３】
ステップ３：プリミティブＢが前記ＳＦＳＭによって処理される時、前記プリミティブは維持され（そのＺ値はプリミティブＡのそれより小さいからである）、及びこれは前記ＳＦＳＭに：１）前記「近」ｚ値としての前記ｚ値ＺB（ＺAは廃棄される）；２）色プリミティブＢに必要とされるプリミティブ情報（プリミティブＡの情報はパイプラインに送られる）；及び３）前記ｚ値（ＺB）は正確なものとしてラベル付けされる、ことを記憶させる。レンダリング処理のこの時点で、プリミティブＢの色は、プリミティブＡとブレンドされなければならないので、プリミティブＡはパイプラインに送られる。これは、それらがパイプラインに送られるときに、プリミティブのタイム・オーダを保存する。
【００８４】
ステップ４：プリミティブＣが前記ＳＦＳＭによって処理される時、前記プリミティブは廃棄される（すなわち、前記可視表面、プリミティブＢに関する現在の最善の推測によって不明瞭にされる）、及び前記ＳＦＳＭデータは変更されない。プリミティブＢ及びＣが透明な面としてレンダリングされる必要がある場合、プリミティブＣは、プリミティブＢによって隠される。これは、プリミティブＢがレンダリングされている間、前記深度マスクを止めることによって達成される。透明性ブレンディングが正確であることに関して、前記面は、前から後ろ、又は後ろから前のどちらかの順番でブレンドされる
深度マスクが不能にされる場合（ＯｐｅｎＧＬの仕様書を参照）、深度バッファへの書き込み（すなわち、ｚ値をセーブすること）は実行されない；しかしながら、深度テストはまだ実行される。この例において、前記深度マスクがプリミティブＢに関して不能である場合、前記値ＺBは、前記ＳＦＳＭにセーブされない。続いて、プリミティブＣは、そのｚ値がＺAと比較されるので、可視であると考えられる。
【００８５】
本例、ＣＨＳＲ処理を要約すると、プリミティブＡ乃至Ｄは処理されており、すべてのプリミティブは前記パイプラインに送られるが、すべてのサンプルにおいてではない。前記可視性を分解するために、（好ましい実施形態におけるピクセル・ブロックにおける）ｚバッファード・ブレンドは、前記パイプラインの終わり近くに含まれる。ＣｕｌｌＦｌｕｓｈＯｖｅｒｌａｐが、他のものに影響を受けさせない間に、選択されたサンプルをフラッシュ（flush）することを説明するために、この例において、多くのサンプルが示された。
３．２．２．３  ＣＨＳＲ及びグレーター・ザン深度テスト
前記保存性隠れ面除去プロシージャの実行は、ＯｐｅｎＧＬ等、他の標準ＡＰＩとの互換性を有利に維持する。多くのＡＰＩにおける一つの複雑性は、深度テストを変更する能力であることが想起される。３Ｄレンダリングの標準的な考え方は、可視オブジェクトが不明瞭なオブジェクトより近いことを仮定しており、及びこれは“レス・ザン（less-than）”深度テストを選択することによって達成される（すなわち、そのｚ値が他のジオメトリ“より小さい”場合、オブジェクトは可視である）ことが想起される。しかしながら、ほとんどのＡＰＩは：グレーター・ザン、レス・ザン、グレーター・ザン・オア・イコール・トゥ、イコール、レス・ザン・オア・イコール・トゥ、レス・ザン、ノット・イコール等、代数的、大きさ、及び論理的関係等、他の深度テストをサポートし、それはフレーム内において変化してもよいことも想起される。これは、本来ダイナミックに可視のもの関する「規則を変更し」、結果として、異なるレンダリング規則を有するプリミティブのタイム・オーダが考慮されなければならない。
【００８６】
本発明の保存性隠れ面除去の場合において、異なる又は追加のプロシージャは、“グレーター・ザン”深度テストが使用される時に、他の標準ＡＰＩとの互換性を維持するため、後述の理由から有利に実行される。通常の当業者は、深度テストが、グレーター・ザン・オア・イコール・トゥ、又はそうでなければ、記述された例外を生むであろう他の機能的関係である場合、有利に使用されてもよいことも理解するであろう。
【００８７】
従来の非ディファード・シェーダ（non-deffered shader）によって、すべてのジオメトリ項目に関する一連の規則を実行し、及び最終のレンダリングされた結果を調べることが、さらに注目される。比較すると、本発明のディファード・シェーダの実施形態において、前記の従来のパラダイムは破壊される。本発明の構造及び方法は、すべてのジオメトリの内側のすべてのピクセルに関するすべての色を作成又は生成する必要なく、フレーム・バッファにおける最終値に実際に影響を与えるのは、どのジオメトリかを予想し又は予測する。原則として、前記ジオメトリの空間的位置が調べられ、特定のサンプルに関して、ｚバッファにおける最終の色に影響を与え、それからその色のみを生成する一つのジオメトリ項目に関して、決定がなされる。
３．２．２．４  前記ＣＨＳＲ処理に関するさらなる考察
サンプルは平行して処理され、及び一般的にスタンプ内のすべてのピクセルにおけるすべてのサンプルは、平行して処理される。従って、一つのスタンプがクロック・サイクルごとに処理されることができる場合（及び、スタンプごとに４つのピクセル、及びピクセルごとに４つのサンプルがある）、１６のサンプルがクロック・サイクルごとに処理される。一つの「スタンプ」が、ピクセルの数及び一度に処理されたサンプルを定義する。このパー・スタンプ処理が通常パイプラインを通され、（以前のプリミティブからの）同じスタンプが完成する前に（すなわち、壊れたスタンプ処理が扱われないかぎり）、再度スタンプが処理される必要がある場合、パイプライン・ストール（pipeline stalls）がインジェクトされる。
【００８８】
必要とされる初期ディスパッチがない場合、エンド・オブ・タイル・ディスパッチ（end−of−tile  dispatches）のみが必要とされる。これは、一つのタイルにおけるすべてのジオメトリが不透明で、及びステンシル・テスト又はオペレーションがなく、可視となりうるアルファ・テストされたプリミティブがない場合である。
【００８９】
各ＳＦＳＭにおけるプリミティブ情報は、すべてのプリミティブ情報が記憶されるメモリヘのポインタによって置き換えられる。好ましい実施形態において後述されるとおり、色ポインタは、ポリゴン・メモリにおけるプリミティブの情報を示すために使用される。
【００９０】
代替として、前記遠ｚ値のみが維持され（前記近ｚ値は維持されない）、それによって、データ記憶を低減させるが、前記サンプル状態ビットに、プリミティブＦの後に「保存」のままにするよう要求し、及びプリミティブＥが、プリミティブＦの前にあるか、後ろにあるかは不明であるため、プリミティブＥを前記パイプラインへ送信させる。
【００９１】
近ｚ値及び遠ｚ値の両方を維持することの代替として、前記遠ｚ値のみが維持され、それによって、データ記憶を低減させるが、サンプル状態ビットに、それらが「正確である」としてラベル付けされた時には、「保存」のままであることを要求し、かつ追加のサンプルに、前記パイプラインヘ送らせる。上述の第一のＣＨＳＲの例（アルファ・テストを含むもの）において、前記サンプル状態ビットは、プリミティブＦの後、“保存”のままであり、かつプリミティブＥは、前記近ｚ値の欠如のためにプリミティブＦの前にあるか、後ろにあるか不明であるので、プリミティブＥは前記パイプラインに送られる。
【００９２】
スタンプを処理することは、スタンプごとのベースで、簡単にＳＦＳＭに並行して動作させるよりも、大きな効率性を有する。スタンプはまた、パイプラインに伝送されるデータ・パケットの数を減らすためにも使用される。すなわち、スタンプ内の一つのサンプルが送られる時（初期ディスパッチ又はエンド・オブ・タイル・ディスパッチ）、同じスタンプ及び同じプリミティブ内の他のサンプルも送られる（そのようなジョイント・ディスパッチ（joint  dispatch）は、以下、可視スタンプ・ポーション（Visible Stamp Portion）又はＶＳＰと呼ばれる）。上述の第二のＣＨＳＲの例（ステンシル・テストを含むもの）において、４つのサンプルすべてが同じスタンプにある場合、サンプル１及び２の初期ディスパッチは、サンプル０及び３の初期ディスパッチを起こす。このことが、より多くのサンプルをパイプラインに送らせ、及び色計算の量を増加させているように見せる一方で、それは（一般的に）最終的な増加ではなく、むしろ色計算における最終的な減少を起こす。これは、ピクセル内における空間的コヒーレンス（すなわち、同じピクセル内のサンプルは、ともに可視であるか、又はともに隠されている傾向にある）、及びアルファ・テスト、色テスト、ステンシル・テスト、及び／又はアルファ・ブレンディングを有するポリゴンのエッジが、他の空間的にコヒーレントなスタンプを潜在的に分割する傾向によるものである。すなわち、計算ロードをそれほど増加させないときに、追加のサンプルをパイプラインに送ることは、送られる必要のあるＶＳＰの総数を減らすことによって、十分に相殺される。上述の第二のＣＨＳＲの例において、すべてのサンプルが同じスタンプの中にある場合、同じ数のＶＳＰが生成されるであろう。
【００９３】
アルファ・テストの場合、プリミティブに関するアルファ値が、バーテックスにおけるアルファ値からのみ（テクスチャリング等、他の場所からではない）生じる場合、簡単にされたアルファ・テストが全体のプリミティブに関して行われることができる。すなわち、バーテックス処理ブロック（後の節においてＧＥＯと呼ばれる）は、いつバーテックス・アルファ値の補間が、アルファ・テストを通過し、及び前記プリミティブに関しては、アルファ・テストを不能にすることを保証されるか、決定することができる。
【００９４】
フレームは深度クリアで始まらない場合、（ＳＦＳＭそれらの最も保存性のある状態に設定される（近ｚ値は最小であり、遠ｚ値は最大である）。
【００９５】
好ましい実施形態において、ＣＨＳＲ処理は、カル・ブロックにおいて実行される。
３．２．３  パイプライン状態情報を含む、タイルによるハードウェア・ソーティング
本発明の構造及び方法において、タイム・オーダが各タイル内に保存され、パイプライン状態情報のタイム・オーダの保存を含むことが注目される。クリアなパケットも使用される。本発明の実施形態において、ソーティングは、ハードウェアにおいて実行され、及びＲＡＭＢＵＳメモリは、有効に一つのバーテックスのデュアロクト記憶を可能にする。ソートされた透明性モードに関して、保証された不透明ジオメトリ（すなわち、より遠いジオメトリを不明瞭にすることで知られるジオメトリ）が、第一のパス（pass）におけるソート・メモリから読み取られる。次のパスにおいて、前記ジオメトリの残りは、各連続のパスにおいて一度読み取られる。好ましい実施形態において、タイル・ソーティング方法は、ソート・ブロックにおいて実行される。
【００９６】
すべてのバーテックス及び関連モード・パケット又は状態情報パケットは、タイム・オーダ線形リストとして記憶される。プリミティブによって接触される各タイルに関して、ポインタは、前記プリミティブを完成させる前記線形リストにおけるバーテックスに加えられる。例えば、三角形プリミティブは、３バーテックスによって定義され、及びポインタは、前記三角形プリミティブを完成させるために、前記線形リストにおける（第三の）バーテックスに加えられるであろう。第三のバーテックスよりも、第一のバーテックスを使用する他の体系は、代替的に実行されてもよい。
【００９７】
基本的に、ポインタは、プリミティブにおける他のバーテックスを見つけるための十分な情報とともに、前記プリミティブにおけるバーテックスの一つを指すために使用される。これらのプリミティブを読み取る時間には、プリミティブ全体が、バーテックス及びポインタから再構築されうる。各タイルは、バーテックスを指し、及び前記リストからの前記プリミティブの再生を可能にするポインタのリストである。このアプローチによって、すべてのプリミティブを記憶することが可能になり、一つのバーテックスを他のプリミティブを共有し、さらに各バーテックスを一度記憶するだけのものも可能になる。
【００９８】
本発明のプロシージャの一つの実施形態において、タイルごとに一つのリストが維持される。リストにはプリミティブを記憶しないが、代わりに、リストは、前記プリミティブへのポインタを記憶する。これらのポインタは、実際には前記プリミティブの一つを指し、及びそれは前記プリミティブにおけるバーテックスの一つへのポインタであり、及び前記ポインタは、同じプリミティブにおける他のバーテックスを探すために十分な情報も含む。このソーティング構造は、三つの記憶構造、データ記憶装置、タイル・ポインタ記憶装置、及びモード・ポインタ記憶装置を具備する構造を使用して、ハードウェアにおいて有効に実行される。一定のタイルに関しては、処理されている特定のタイルに接触するプリミティブのタイム・オーダ・シーケンスを再生するが、前記タイルに接触しないプリミティブを無視することが、目的である。以前に前記モードを引き出し、それらを個別に記憶したが、ここでは、前記モード・パケットを、正しい場所で、このプリミティブの流れに導入したい。さらに、前記モード・パケットは、前記プリミティブを処理するために必要であり、それは一つ以上のタイルをかぶせるので、単に、前記モード・パケットを一つのステージにおいて引き出し、それからそれを他のステージにおいて再導入するだけでは十分ではないことが注目される。それゆえに、前記モード・パケットは、適切な時に、関連するタイルのすべてと再度、関連付けされなければならない。
【００９９】
一つの単純なアプローチは、モード・パケットへのポインタを、すべてのタイル・リストに書き込むことであろう。このリストの連続した読み取りの間、モード・パケット・アドレスにアクセスし、及び適切なモード・データを読み取ることが簡単であろう。しかしながら、このアプローチは、すべての前記タイルへのポインタを書き込むことに関連するコストのために、不利である。本発明のプロシージャにおいて、各タイルの処理中、適切なタイル・ポインタ・リストからのエントリを読み取り、及び前記バーテックスに関するモード・データを読み取っており（フェッチしており）及びそれを送った場合、データ記憶装置からバーテックスを単に検索し、それをパイプラインに送信する；しかしながら、前記モード・データが、タイル・ポインタ・リストにおいて、検索された最終のバーテックスと、次のシーケンシャル・バーテックスとの間で変化していた場合でも、バーテックスが到着する時に、適切なモード・データが入手可能になるように、前記モード・データは、データ記憶装置からフェッチされ、次のバーテックスが送られる前に、パイプラインに送られる。前記モード・ポインタ・リストにおけるエントリは、どのバーテックスで前記モードが変化するかを識別することが注目される。一つの実施形態において、前記モード・ポインタにおけるエントリは、前記モード・データが関連する第一のバーテックスを記憶するが、しかしながら、前記モード・データが適用される最終バーテックスの記憶等、代替的なプロシージャが、不変の規則に従う限り、使用されうる。
３．２．４  ＤＳＧＰオペレーションの二つのモード
ＤＳＧＰは、二つの個別のモードで動作することができる：１）タイム・オーダ・モード（Time Order Mode）、及び２）ソーテッド・トランスペアレンシー・モード（Sorted Transparency Mode）である。タイム・オーダ・モードは上述されており、及び特定のタイル内に、同じ時制のシーケンスのプリミティブを保存するように設計される。ソーテッド・トランスペアレンシー・モードは、すぐ後述される。好ましい実施形態において、パイプライン・オペレーティング・モードの制御は、ソート・ブロックで実行される。
【０１００】
ソート・ブロックは、モード・エクストラクション装置（ＭＥＸ）とセットアップ（ＳＴＰ）装置との間のパイプラインに配置される。ソート・ブロックは、第一に、ディスプレイ・ウィンドウに散りばめられたジオメトリを取るために、及びそれをタイルにソートするために、動作する。ソート・ブロックはまた、ソート・メモリを管理し、それはあるモード情報とともに、ラステライズされる前に、シーン全体からすべてのジオメトリを記憶する。ソート・メモリは、バーテックス及びモードの二重バッファされたリストを具備する。一つのページは、シーンのジオメトリを集める（バーテックスごと及びモードごと）一方で、他のページは、そのジオメトリ（プリミティブごと及びモードごと）を、残りのパイプラインに送っている。
【０１０１】
ソート・メモリにおけるページが書き込まれている時、バーテックス及びモードは、それらがソート・ブロックによって受信されると、ソート・メモリへと順番に書き込まれる。ページが、ソート・メモリから読み取られる時、前記読み取りは、タイルごとのベースで行われ、及び前記読み取り処理は、二つのモード：（１）タイム・オーダ・モード、及び（２）ソーテッド・トランスペアレンシー・モードで動作する。
３．２．５  タイム・オーダード・モード（Time-Ordered Mode）
タイム・オーダード・モードにおいて、バーテックス及びモードのタイム・オーダは、各タイル内に保存され、一つのタイルは、水平及び垂直に区切られたディスプレイ・ウィンドウの一部である。保存されたタイム・オーダによって、一定のタイルに関して、バーテックス及びモードは、それらが書き込まれたのと同じオーダで、読み取られる。
３．２．６  ソーテッド・トランスペアレンシー・モード（Sorted Transparency Mode）
ソーテッド・トランスペアレンシー・モードにおいて、各タイルの読み取りは、複数のパスに分割され、第一のパスにおいて、保証された不透明ジオメトリは、ソート・ブロックから出力され、及び連続したパスでは、潜在的に透明なジオメトリは、ソート・ブロックから出力される。各ソーテッド・トランスペアレンシー・モードパス内で、タイム・オーダリングが保存され、及びモード・デート（mode date）は、その正しいタイム・オーダの場所に挿入される。ソーテッド・トランスペアレンシー・モードは、後ろから前へ、又は前から後ろへの順番で実行されてもよい。好ましい実施形態において、ソーテッド・トランスペアレンシー方法は、ソート・ブロック及びカル・ブロックによって、共同して実行される。
３．２．７  複数ステップの隠れ面除去
従来、隠れ面は、「正確な」隠れ面除去プロシージャか、又はｚバッファを使用して除去される。本発明の構造及び方法の一つの実施形態において、２ステップ・アプローチが実行され、（１）「保存性」隠れ面除去は、（２）ｚバッファ・ベースのプロシージャが続く。異なる実施形態において、３ステップ・アプローチ：（１）特定の空間的カル・プロシージャ、（２）保存性隠れ面除去、及び（３）ｚバッファが実行される。保存性隠れ面除去（conservative hidden surface removal）（ＣＨＳＲ）の様々な実施形態は、すでに本開示の他の部分で説明された。
３．２．８  パイプライン状態保存及びキャッシング
各バーテックスは、色ポインタを含み、及びバーテックスが受け取られると、前記色ポインタを含む前記バーテックスは、ソート・メモリ・データ記憶装置に記憶される。色ポインタは、バーテックス・データの色部分を含むポリゴン・メモリ・バーテックス記憶装置におけるある場所へのポインタである。素材ライティング・モード（Material-Lighting-Mode）（ＭＬＭ）ポインタ・セットは、ストリップ（strip）又は（fan）のいずれかのバーテックスのすべてに関連する。ＭＬＭは、後述のとおり、６の主なポインタに加え、２つの他のポインタを含む。前記６の主なポインタの各々は、ポリゴン・メモリ状態記憶装置へのアドレスを具備し、それはパイプラインにおいて変化した状態のすべて、例えば、テクスチャ、ピクセル、ライティング等における変化のすべての逐次記憶装置であり、将来のいつかに必要性が生じる時に、ＭＬＭポインタを探索し、及びポリゴン・メモリ状態記憶装置に戻り、及びその時存在した状態を見つけることによって、バーテックスと関連するＭＬＭポインタから、バーテックス（又は一つ以上のバーテックスから形成されるオブジェクト）をレンダリングするために必要とされる状態を再生することができる。
【０１０２】
モード・エクストラクション・ブロック（ＭＥＸ）は、時制的にオーダされた状態変化データを集め、前記状態をポリゴン・メモリに記憶し、及びそれがソート・メモリに渡すバーテックス・データへの適切なポインタを添付する、ジオメトリとソートとの間の論理的ブロックである。通常のＯｐｅｎＧＬパイプラインにおいて、及びソート・ブロックまでの本発明のパイプラインの実施形態において、ジオメトリ及び状態データは、それがパイプラインに送られた順番で処理される。素材タイプ、ライティング、テクスチャ、モード及び点描に関する状態変化は、それらに続くプリミティブに影響を与える。例えば、各新しいオブジェクトは、前記オブジェクトに関する素材パラメータを設定するために、状態変化によって先行されるであろう。
【０１０３】
本発明のパイプラインにおいて、他方では、フラグメントは、カル・ブロックの後に、タイル・オーダでパイプラインに送られる。モード・インジェクション・ブロックは、タイム・オーダの代わりに、空間的（タイル）オーダでデータを処理するパイプラインの部分における状態をどのように保存するのか、明らかにする。ジオメトリ・データに加えて、データ・エクストラクション・ブロックは、モード・データ（ｃｕｌｌ＿ｍｏｄｅ）のサブセットを、カルによる使用のために、パイプラインに送る。Ｃｕｌｌ＿ｍｏｄｅパケットは、ジオメトリ・ブロックで生成される。モード・エクストラクション・ブロックは、ジオメトリ・パケットにおける適切な色ポインタを挿入する。
【０１０４】
パイプライン状態は、以下のように、記憶装置を最小限にするために、いくつかのカテゴリ（category）に分けられる：（１）空間的パイプライン状態は、すべてのバーテックスを変えるソートに向けられたデータを含む；（２）Ｃｕｌｌ＿ｍｏｄｅ状態は、頻繁には変わらない（ソートを介して）カルに向けられたデータを含む；（３）色は、すべてのバーテックスを変えるポリゴン・メモリに向けられたデータを含む；（４）素材は、各オブジェクトに関して変化するデータを含む；（５）テクスチャＡは、テクスチャ０及び１に関するテクスチャ・ブロックに関する第一の組の状態を含む；（６）テクスチャＢは、テクスチャ２乃至７に関するテクスチャ・ブロックに関する第二の組の状態を含む；（７）モードは、ほどんと変化しないデータを含む；（８）ライトは、フォンに関するデータを含む；（９）点描は、ポリゴン点描パターンに関するデータを含む。素材、テクスチャ、モード、ライト、及び点描データは、集合的に（素材、ライト、及びモードに関する）ＭＬＭデータと称される。状態保存に関するＭＬＭポインタに特に関心が持たれる。
【０１０５】
状態変化情報は、プリミティブ（空間的及び色パケット）が現れるまで、ＭＥＸに蓄積される。その時、最後のプリミティブ以来、変化したＭＬＭデータは、ポリゴン・メモリに書き込まれる。色データも、ＭＬＭデータへの適切なポインタとともに、ポリゴン・メモリに書き込まれる。空間的データは、ポリゴン・メモリへのポインタ（色ポインタ）とともに、ソートに送られる。色及びＭＬＭデータは、すべてポリゴン・メモリに記憶される。これらのレコードに関する空間の割り当ては、性能を向上させるために、マイクロ・アーキテクチャ定義において最適化されうる。
【０１０６】
これらのレコードのすべては、ポインタを介してアクセスされる。ソート・メモリにおける各プリミティブ・エントリは、ポリゴン・メモリにおける対応する色エントリへの色ポインタを含む。色ポインタは、点、線又は三角形を構築し、及びＭＬＭポインタを配置することができるようにする色アドレス、色オフセット、及び色タイプを含む。色アドレスは、プリミティブにおける最終バーテックスを指す。バーテックスは、順番に記憶されるので、一つのプリミティブにおけるバーテックスは、三角形ファンの場合を除いて、隣接する。色オフセットは、色アドレスから、このバーテックス・リストに関する第一のデュアロクト（dualoct）に指し戻す。（点リスト、線ストリップ、三角形ストリップ、又は三角形ファンを、バーテックス・リストとして参照する。）この第一のデュアロクトは、バーテックス・リストにおける前記点、線、ストリップ、又はファンに関するＭＬＭデータへのポインタを含む。バーテックス・リストにおける、それに続くデュアロクトは、色データ・エントリを含む。三角形ファンに関して、三角形の三つのバーテックスは、色アドレス、（色アドレス−１）、及び（色アドレス−色オフセット＋１）にある。これは、ポインタがソート・メモリに記憶されたのとまったくの同じ方法ではないことが注目される。
【０１０７】
状態は、経時的変化をするエンティティであり、及びＭＥＸは、状態が、バーテックス又はバーテックスの組に関して再生されることができるように、状態における変化を蓄積する。ＭＩＪブロックは、ダウンストリームのバーテックスと状態を適合させることを担う。バーテックスがＭＥＸに入り、及び一定のインジケータ・ビット（indicator bits）が設定される時はいつも、パイプライン状態情報のサブセットがセーブされる必要がある。完全な状態は、状態への蓄積的な変化から生成されることができるので、変化した状態のみが記憶され、すべてが記憶されるのではない。素材、テクスチャＡ、テクスチャＢ、モード、ライト、及び点描に関する６のＭＬＭポインタは、個別の状態情報への最近の変化が記憶されるアドレス場所を識別する。これらの状態の一つにおける各変化は、メモリに記憶された、順番にオーダされた状態記憶装置リストの最後で、追加のエントリによって識別される。有効に、すべての状態変化が記憶され、及び時間におけるある点（又はバーテックスの受信）に対応する特定の状態が必要とされる時、前記状態は、前記ポインタから再構築される。
【０１０８】
セーブされるモードのこのパケットは、モード・パケットと称されるが、前記フレーズ（phrase）は、レンダリングの前に、ＭＩＪによって検索され又は再構築されるより大きなセットのモード・データと同様に、記憶されるモード・データ変化を参照するために使用される。
【０１０９】
特に、全体の状態は、比較的小さな色ポインタに維持される情報から再生されることができることが注目される。
【０１１０】
ポリゴン・メモリ・バーテックス記憶装置は、色部分のみを記憶する。ポリゴン・メモリは、隠れ面除去に必要とされないパイプライン状態の部分を記憶し、及び隠れ面除去には必要とされないバーテックス・データの部分（主に、色を作るために必要とされる項目）も記憶する。
３．２．９  テクセル再使用検出及びタイル・ベースド処理
本発明の構造及び方法は、テクスチャ・マップの複数の層（解像度）のトリリニア・マッピング（trilinear mapping）を有効に利用してもよい。
【０１１１】
テクスチャ・マップは、ＡＧＰインターフェースを使用して、ホスト・コンピュータのメモリからロードされた単一バッファされたメモリを通常具備してもよいテクスチャ・メモリに記憶される。例示的な実施形態において、単一のポリゴンは、４つまでのテクスチャを使用することができる。テクスチャは、ミップ・マップされる。すなわち、各テクスチャは、異なるレベルのディテール又は解像度で、一連のテクスチャ・マップを具備し、各マップは、アイ・ポイントからの一定の距離におけるテクスチャの外観を表してもよい。一定のピクセル・フラグメントに関するテクスチャ値を生成するために、テクスチャ・ブロックは、正しいレベルのディテールに近似するために、テクスチャ・マップからトリリニア補間を実行する。テクスチャ・ブロックは、異方向補間等、他の補間方法を代替的に実行することができる。
【０１１２】
テクスチャ・ブロックは、パー・フラグメント・ベースで、フォン・ブロックに、補間されたテクスチャ値を（通常は、ＲＧＢＡ色値として）供給する。バンプ・マップは、特殊なテクスチャ・マップを表す。色の代わりに、バンプ・マップの各テクセルは、高さフィールド勾配を含む。
【０１１３】
複数層は、ＭＩＰ層であり、及び補間は、ＭＩＰ層の中及び層の間である。第一の補間は、各層の中であり、二つの隣接する層の間を補間し、一方は要求されるよりも大きな解像度を有し、他方は、要求されるよりも小さな解像度を有するので、それは最適な解像度を生成するために、３次元で実行される。
【０１１４】
本発明のパイプラインは、前記構造及びオペレーションが従来のキャッシュと異なるので、テクスチャ・キャッシュ、実際にはテクスチャされた再使用レジスタを含むテクスチャ・メモリを含む。ホストはまた、テクスチャのための記憶装置を含み、それは通常大変大きくてもよいが、テクスチャをレンダリングするために、それは、テクスチャ・メモリとも称されるテクスチャ・キャッシュへとロードされなければならない。Ｓ及びＴは、各ＶＳＰに関連する。トリリニアＭＩＰマッピングを実行するために、必ず８のサンプルをブレンドするので、本発明の構造は、並行して動作する、一組の８のコンテント・アドレッサブル（メモリ）キャッシュを供給する。一つの実施形態において、前記キャッシュ識別子は、コンテント・アドレッサブル・タグの一つであり、それが、前記キャッシュのタグ部分と、及び前記キャッシュのデータ部分が、前記タグ又はインデックスから別個に配置されている理由である。従来、タグ及びデータは、前記タグのクエリが前記データを与えるように、共に配置される。本発明の構造及び方法において、前記タグ及びデータは分割され、及びインデックスは、パイプラインに送られる。
【０１１５】
前記データ及びタグは、異なるブロックに記憶され、及びコンテント・アドレッサブル・ルックアップは、アドレスのルックアップ又はクエリであり、及びそれ自身における前記アドレスに記憶された「データ」並びに異なるブロックに記憶される実際のデータを参照するインデックスでもある。前記インデックスによって参照されたデータが、決定されることができるように、前記インデックスは決定され、及びパイプラインに送られる。すなわち、前記タグは一つの場所にあり、前記テクスチャ・データは第二の場所にあり、及び前記インデックスは、前記二つの記憶装置構造の間にリンクを供給する。
【０１１６】
本発明の一つの実施形態において、テクセル再使用検出レジスタ（Texel Reuse Detection Register）（ＴＲＤＲ）は、複数の関連メモリを具備し、それは通常テクセル・インターポレータ（texel interpolator）と同じ集積回路上に配置される。好ましい実施形態において、テクセル再使用検出方法は、テクスチャ・ブロックにおいて実行される。
【０１１７】
従来の３Ｄグラフィックス・パイプラインにおいて、空間上のある方向のオブジェクトがレンダリングされる。前記オブジェクトは、その上にテクスチャ・マップを有し、及び多くの三角形プリミティブによって表示される。ソフトウェアで実行されるプロシージャは、特定のオブジェクト・テクスチャを、ＤＲＡＭにロードするように、ハードウェアに命令する。前記特定のオブジェクトに共通であり、同じテクスチャ・マップを有する三角形のすべては、前記装置に送り込まれ、及び特定のオブジェクトを表示するために必要な色付きピクセルのすべてを生成するために、テクスチャ補間が実行される。前記オブジェクトが色付けされた時、ＤＲＡＭにおけるテクスチャ・マップは、前記オブジェクトがレンダリングされたので、破壊されうる。（おそらく異なる方向又は場所にある）複数の同一のオブジェクト等、同じテクスチャ・マップを有する一つ以上のオブジェクトがある場合、そのタイプのオブジェクトのすべては、ＤＲＡＭにおけるテクスチャ・マップが廃棄される前に、望ましくはテクスチャされてもよい。異なるジオメトリが送り込まれてもよいが、同じテクスチャ・マップは、すべてに関して使用されることができ、それによって、ホスト・メモリからテクスチャ・マップを繰り返し検索し、それを一時的に一つ以上のパイプライン構造に配置する必要を排除する。
【０１１８】
より複雑な従来の体系において、一つ以上のテクスチャ・マップが検索され、及びメモリに記憶されてもよく、例えば、二つ又はいくつかのマップが、利用可能なメモリ、テクスチャ・マップのサイズ、複数のテクスチャ・マップを記憶しまたは維持する必要性、及び管理体系の複雑性によって、記憶されてもよい。これら従来のテクスチャ・マッピング体系、空間的オブジェクトのコヒーレンス（coherence）の各々は、第一の重要性を有する。少なくとも単一のオブジェクト全体に関して、及び通常は同じテクスチャ・マップを使用するオブジェクトのグループに関して、前記オブジェクトを形成する三角形のすべては、ともに処理される。フレーズ空間コヒーレンシー（coherency）は、前記オブジェクトからの三角形が空間で接続され、それゆえに空間的にコヒーレント（coherent）であるので、そのような体系に適用される。
【０１１９】
本発明のディファード・シェーダ構造及び方法において、このタイプの空間的オブジェクト・コヒーレンスからのかなりの利益に、必ずしも依存し又はそれを引き出さない。本発明のディファード・シェーダの実施形態は、代わりにタイル上で動作する。全体のタイルに対する空間的オブジェクト・コヒーレンスが、通常は存在しないように、一定のタイルは、オブジェクト全体、複数のオブジェクト、いくつかの全体のオブジェクト、又はいくつかのオブジェクトの部分を有する。
【０１２０】
本発明の構造及び方法は、ディファード・シェーダに向けられているので、従来の概念は完全に壊れる。タイルが、偶然に全体のオブジェクトを有する場合でも、通常は異なるバックグラウンドがあり、及び前記タイルが、ある程度の空間的コヒーレンシーをサポートする場合でも、本発明のカル・ブロック及びカル・プロシージャは、通常完全に混乱し及び空間的にインコヒーレント（incoherent）なオーダでＶＳＰを生成し及び送信する。その結果、パイプライン及びテクスチャ・ブロックは、有効に、リアルタイムで稼動中のテクスチャ・マップを変えることができ、及び受信されたオブジェクト・プリミティブ（例えば三角形）に要求されるテクスチャに応答する。たった今受信された特定のオブジェクト・プリミティブ（例えば単一の三角形）を処理するために、及び次の異なるオブジェクト・プリミティブが、異なるテクスチャ・マップを必要とする時に、前記テクスチャを廃棄するために、ホストからテクスチャ・マップを繰り返し検索するための要求は、控えめに言っても問題があり、迅速なオペレーションを妨害するであろう。
【０１２１】
本発明の構造及び方法において、かなり大きいメモリがカード上にサポートされる。一つの実施形態において、１２８メガバイトが供給されるが、それ以上又はそれ以下のメガバイトが供給されてもよい。例えば、ユーザの必要性、メモリのためのカード上で利用可能なリアル・エステート（real estate）、及び利用可能なメモリの密度によって、３４Ｍｂ、６４Ｍｂ、２５６Ｍｂ、５１２Ｍｂ、又はさらに多くが供給されてもよい。
【０１２２】
すべての可視フラグメントに関して８テクセルを読み取り、それらを使用し、及び次のフラグメントのための８テクセルが検索され及び記憶されることができるように、それらを廃棄するよりもむしろ、本発明の構造及び方法は、それらが再度必要とされる妥当な可能性がある時に、それらを記憶し及び再使用する。
【０１２３】
可視フラグメントが受信されるたびに、８テクセルを読み取り及び廃棄することは、実用的でない。それよりも、タイル空間を進む場合には、同じテクスチャ・マップが連続するピクセルに必要とされない一方で、同じテクスチャ・マップが、前記タイルのある領域においてクラスタにされた（clustered）いくつかのピクセルに必要とされ、ゆえに、第一の使用の後、いくつかの処理ステップのみを必要とするように、前記タイル内のピクセル・グリッド（通常は、長方形タイル・ピクセル・グリッドにおける連続した列に沿って処理される）が来るので、これらのテクセルを再使用することが望ましい。望ましくは、本発明は、繰り返し読み取られたテクセルを使用するので、それを必要とし、それを読み取り、及び特定のテクスチャ・マップを要求する一つのフラグメントを見た可能性が十分であり、同じタイルにいる間に、後のある時間帯に、可能性が十分であることを知っている時、同じテクスチャを必要とする同じオブジェクトからの、他のフラグメントに遭遇するであろう。それゆえに、このキャッシュにそれらのものをセーブし、それから稼動中に、必要とするものをキャッシュ（テクスチャ再使用レジスタ）から探索する。キャッシュ・ミス（cache miss）がある場合、例えば、フラグメント及びテクスチャ・マップが初めて遭遇した場合、前記テクスチャ・マップは検索され、及びキャッシュに記憶される。
【０１２４】
テクスチャ・マップ検索待ち時間は、他の問題ではあるが、ファースト・イン・ファースト・アウト（First-In-First-Out）（ＦＩＦＯ）データ構造の使用及び予見的又は予言的な検索プロシージャの使用を通して扱われる。ＦＩＦＯは大きく、ＣＡＭと関連して動作する。項目が必要とされる時、それがすでに記憶されたかについて決定がなされ、及びデジグネータ（designator）も、キャッシュ・ミスがある場合に、情報を検索し及びそれを記憶するために、比較的遅いメモリに出ることができるように、ＦＩＦＯに配置される。いずれの場合も、データがキャッシュにあり、又はそれがホスト・メモリから検索された場合、装置メモリに（また、新しく検索された場合には、キャッシュにも）配置される。
【０１２５】
効果的に、（実際の使用の前に）一度テクスチャへの必要性が識別されると、前記データは、必要とされる前に検索され及び再関連付けされることができるように、前記検索が処理を遅らせないように、一種の遅延（delay）として動作する。ＦＩＦＯ待ち行列は、常に予報し及び先を見るように、パイプラインにおけるスラック（slack）を供給し、及び取り上げる。ＦＩＦＯを調べることによって、読み取りが実行される時に、それが使用のために準備できているように、非キャッシュ・テクスチャが識別され、ホスト・メモリから検索され、キャッシュ及び特別な装置メモリに配置されることができる。
【０１２６】
予見的及び予言的な検索を供給するＦＩＦＯ及び他の構造が、パー・オブジェクト処理において通常使用される空間的オブジェクト・コヒーレンスが、我々のパー・タイル処理において失われる時に起こる問題を避ける意味で、供給される。本発明の構造及び方法は、オブジェクト内で、空間的コヒーレンスを利用することも注目され、一つのオブジェクトにおけるすべてのピクセルが、順番に処理される場合に、本発明は、一時的及び空間的コヒーレンスがあるという事実を利用する。
３．２．１０  パケット化データ転送プロトコル
本発明の構造及び方法は、ブロックからブロックへ、パケットで（データ及び制御等の）情報を有効に転送する。このパケット化された通信を、パケット化データ転送と称し、及び前記パケット化されたデータのフォーマット及び／又は内容を、パケット化データ転送プロトコル（packetized data transfer protocol）（ＰＤＴＰ）と称する。前記プロトコルは、ヘッダ部分とデータ部分を含む。
【０１２７】
ＰＤＴＰの一つの利点は、データのすべてが、ブロックからブロックへ、一つのバスを通して送ることができ、それによって異なるデータ・タイプのための個別のバスに対する必要性を軽減することである。ＰＤＴＰの他の利点は、情報をパケット化することが、オーダリングを維持することに関して支援することであり、それは、適切なレンダリングに重要なことである。レンダリングは、パイプライン状態等における変化に敏感であり、タイム・オーダ・シーケンス（time order sequence）を維持することは一般的に重要であり、例えば、ＭＩＪキャッシュに関しては、パイプラインを下るパケットの流れの管理は、特に重要であることが想起される。
【０１２８】
バスは、効果的な順番のリンクであり、パケットは、あるタイム・オーダで順番に到着するので、パケットの転送は、順番である。例えば、「フィル・パケット（fill packet）」がブロックで到着する場合、それは前記ブロックのＦＩＦＯに入り、及びＶＳＰが到着する場合は、それも前記ブロックのＦＩＦＯに入る。各プロセッサ・プロックは、その入力に到着するパケットを待ち、及びパケットが到着すると、どのアクションを取るべきか決定するために、パケット・ヘッダを見る。前記アクションは、前記パケットを前記出力に送ること（すなわち、他のアクション又は処理をすることなく、それを渡す）か、又はそれに関して何かをすることでもよい。パケット化データ構造及び前記パケット化データ構造のみ及びバス、ＦＩＦＯ又は他のバッファ又はレジスタ体系と関連した使用は、３Ｄグラフィックス・システムよりも広いアプリケーションを有し、及び複数の機能的又は処理ブロック又は装置が、相互接続され及び互いに通信する、あらゆるパイプライン構造に適用されてもよい。パケット化転送の使用は特に、シーケンシャル又はタイム・オーダの維持が重要である場合に有効である。
【０１２９】
ＰＤＴＰの一つの実施形態において、各パケットは、パケット識別子又はＩＤ及び他の情報を有する。多くの、様々な種類のパケットがあり、すべての異なるパケット・タイプは、標準長を有し、及びパケットの種類を識別するヘッダを含む。異なるパケットは、異なる形式及び様々な長さを有するが、各特定のパケット・タイプは、標準長を有する。
【０１３０】
効果的に、各ブロックは、入力においてＦＩＦＯを含み、及び前記パケットは、ＦＩＦＯを通過して流れ、関連する情報は、ブロックごとにＦＩＦＯに蓄積される。前記パケットは、前記ブロック機能に関連する情報が引き出されるように、他の又は前記ブロックのすべてを流れ続ける。
【０１３１】
本発明の構造及び方法の一つの実施形態において、ＦＩＦＯ内の記憶セル又はレジスタは、小さなパケットが、たった一つのＦＩＦＯを要求し、より大きいパケットは、多数のレジスタ、例えば２，３，５，１０，２０，５０又はそれ以上のレジスタを要求してもよいように、予め決められた幅を有する。可変パケット長及び単一のパケットが、いくつかのＦＩＦＯ記憶装置レジスタを消費するかもしれない可能性は、パケットの第一の部分がパケットの種類を識別し、及び直接又は間接的に、パケットの種類を知ることによって、パケットのサイズ及びそれが消費するＦＩＦＯエントリの数を識別するので、問題を提示しない。本発明の構造及び方法は、本明細書の他の節において説明される数多くのパケット・タイプを供給し及びサポートする。
３．２．１１  フラグメント・カラリング
フラグメント・カラリングは、２次元表示空間に関して実行され、及び例えば、三角形プリミティブの三つのバーテックスから、表示されたピクセルのサンプル化された座標への色の補間を伴う。基本的に、フラグメント・カラリングは、前記三つのバーテックスの間に空間的に配置された場所に関する色を決定するために、三つのフラグメント・バーテックスにおける色に、補間機能を適用することを伴う。通常、しかし任意に、補間を実行することに関して、透視的正確さ（perspective correctness）を考慮するであろう。補間係数は、透視的正確係数と同様にキャッシュされる。
３．２．１２  法線の補間
様々な折衷案が、面法線、特に３Ｄグラフックス環境における他の面法線の間に補間される面法線の計算と関連して、今までに受け入れられてきた。前記折衷案は通常、計算の簡単さ又は効率に対して正確性を引き換えにしてきた。理想的には、面法線は、角度的に補間され、前記補間が基づく面法線の角度における実際の角度差に基づく。実際に、そのような角度計算は、３Ｄグラフィックス・アプリケーションには適していない。
【０１３２】
それゆえに、より典型的には、面法線は、二つの入力法線の線形補間に基づいて補間される。質レンダリングを低く和らげるために、合成面法線の線形補間は、十分な正確性を供給してもよい；しかしながら、２次元補間の例を検討すると、一つのベクトル（面法線）が、例えば、他のベクトルだが、前記第一のベクトルへの比較可能な角度変更があるより大きなマグニチュードを有する時、その結果のベクトルは、前記二つのベクトルの間の比較可能な角度差に関わらず、より大きなマグニチュード・ベクトルによって、過剰に影響を受けるであろう。これは、異論を招くエラーを生じるかもしれず、例えば、ある面シェーディング又はライティング計算は、異常な結果を招き、及び出力シーンを損ねるかもしれない。
【０１３３】
これらの問題のいくつかは、線形補間が、正規化された組のベクトルで実行される場合でも、最小化される一方で、いくつかのＡＰＩは、例えば３座標補間、個別のｘ、ｙ及びｚ補間及び他の体系を含む、非正規化ベクトル及び様々な補間体系をサポートするので、これは常に実践的であるわけではない。
【０１３４】
本発明の構造及び方法において、前記マグニチュードは、方向又は角度からは別個に補間される。補間されたマグニチュードが計算され、それから同じサイズの方向ベクトルが計算される。別個に補間されたマグニチュード及び方向は、再結合され、前記方向は正規化される。
【０１３５】
理想的な角度補間は、最大の正確性を供給する一方で、しかしながら、前記補間は、球体の表面上の３点及び様々な大円計算に関与する。この種の数学的複雑性は、リアルタイムの迅速なパイプライン処理には適していない。単一ステップの線形補間は、ずっと簡単であるが、よりエラーに敏感である。これらのプロシージャの各々と比較して、本発明の面法線補間プロシージャは、従来の線形補間よりも大きな正確性を有し、及び従来の角度補間よりも低い計算複雑性を有する。
３．２．１３  空間的セットアップ
本発明の好ましい実施形態において、空間的セットアップは、セットアップ・ブロック（ＳＴＰ）で実行される。セットアップ（ＳＴＰ）・ブロックは、ソート（ＳＲＴ）・ブロックから一連のパケットを受け取る。これらのパケットは、レンダリングされるべきプリミティブに関する空間的情報を有する。ＳＴＰブロックの出力は、カル（ＣＵＬ）・ブロックに進む。ＳＲＴから受け取られるプリミティブは、三角形、線三角形、線、点線、及び点で埋められる。これらのプリミティブの各々は、エイリアス又はアンチ・エイリアス・モードでレンダリングされうる。ＳＲＴブロックは、プリミティブをタイル・オーダでＳＴＰ（及び他のパイプライン・ステージ・ダウンストリーム）に送る。各タイル内で、前記データはタイム・オーダ又はソートされた透明性オーダで編成される。ＣＵＬブロックは、タイル・オーダで（実際には、ＳＴＰがＳＲＴからプリミティブを受け取るオーダで）ＳＴＰブロックからデータを受け取り、及びレンダリングされた画像に決してコントリビュート（contribute）しないプリミティブの部分をカル・アウト（cull out）する。これは２つの段階で達成される。第一の段階で、その内容が一定の値よりも大きい長方形メモリ・アレイにおける前記エレメントの検出を可能にする。第二の段階は、サンプルごとの内容比較をすることによって、この探索を改良する。ＳＴＰブロックは、ＣＵＬブロックによる処理のために、入力プリミティブを準備する。ＳＴＰは、第一段階のカルのために前記タイルを交差するプリミティブの部分に関して、タイト（tight）な文字枠（bounding box）及び最小深度値Ｚｍｉｎを生成し、それは、Ｚｍｉｎよりも小さい深度値を含んでもよい文字枠におけるスタンプに印つけをする。Ｚカル段階は、これらの候補のスタンプを取り、それらがプリミティブの一部である場合には、前記スタンプにおけるサンプルに関する実際の深度値を計算する。この、より正確な深度値は、比較及びサンプルごとのベースでの可能な廃棄のために使用される。第一の段階のカルに関する文字枠及びＺｍｉｎに加えて、ＳＴＰは、深度勾配、線スロープ、及びＺカル段階に関するタイル・エッジとの深度及びプリミティブ交差点等、他の参照パラメータも計算する。ＣＵＬ装置は、他のパイプライン段階によって使用されるＶＳＰを生成する。
【０１３６】
本発明の好ましい実施形態において、空間的セットアップ・プロシージャは、セットアップ・ブロックで実行される。本発明の空間的セットアップ構造及び方法の重要な特徴は：（１）統一されたプリミティブのサポート及び生成、（２）プリミティブに関するタイル内のＺminを計算するためのプロシージャ、（３）タイル相対ｙ値及びスクリーン相対ｘ値の使用、及び（４）これもダウンストリーム・ハードウェアを単純化する従来のエッジ・ウォークに加えた、エッジ・ホップ（edge hop）の実行（実際には、カル・ブロックで実行される）を含む。
【０１３７】
統一されたプリミティブの注釈のもとで、長方形になるべき線プリミティブ及び退化した長方形になるべき三角形を検討し、各々は、数学的にそのように表示される。セットアップは、線セグメントを、４つのバーテックスを含む平行四辺形に変換する。一つの三角形は、三つのバーテックスを有する。セットアップは、一組の４点を有する各プリミティブを記述する。すべての値が、すべてのプリミティブに対して必要とされるわけではないことが注目される。三角形に関して、セットアップは、三角形の方向によって、上、下、及び左又は右の角を使用する。線セグメントは、平行四辺形として扱われるので、セットアップは、４点すべてを使用する。前記三角形のバーテックスが、本来のバーテックスと同じである一方で、セットアップは、前記線をクワド（quads）として表示するために、新しいバーテックスを生成する。プリミティブの統一された表示は、ウィンドウ座標における本来の組のバーテックスに割り当てられるプリミティブ記述子を使用する。さらに、どの記述子が有効かつ意義のある値を有するかを示すフラグがある。
【０１３８】
三角形に関して、ＶｔｘＹｍｉｎ、ＶｔｘＹｍａｘ、ＶｔｘＬｅｆｔＣ、ＶｔｘＲｉｇｈｔＣ、ＬｅｆｔＣｏｒｎｅｒ、ＲｉｇｈｔＣｏｒｎｅｒ記述子が、それらのｙ座標で三角形のバーテックスをソートすることによって得られる。線セグメントに関して、これらの記述子は、前記線クワド・バーテックスが生成される時に割り当てられる。ＶｔｘＹｍｉｎは、最小のｙ値を有するバーテックスである。ＶｔｘＹｍａｘは、最大のｙ値を有するバーテックスである。ＶｔｘＬｅｆｔＣは、三角形の場合における長いｙエッジ（バーテックスＶｔｘＹｍｉｎとＶｔｘＹｍａｘとを結合させることによって形成される三角形のエッジ）の左に、及び平行四辺形に関しては、バーテックスＶｔｘＹｍｉｎとＶｔｘＹｍａｘとを結合させることによって形成される対角線の左に位置するバーテックスである。前記三角形が、長いｙエッジも左エッジであるような場合、フラグＬｅｆｔＣｏｒｎｅｒは、ＶｔｘＬｅｆｔＣが無効であることを示すＦＡＬＳＥ（０）である。同様に、ＶｔｘＲｉｇｈｔＣは、三角形の場合では、長いｙエッジの右に、及び平行四辺形に関しては、バーテックスＶｔｘＹｍｉｎとＶｔｘＹｍａｘとを結合させることによって形成される対角線の右に位置するバーテックスである。三角形が、長いエッジも右エッジである場合、フラグＲｉｇｈｔＣｏｒｎｅｒは、ＶｔｘＲｉｇｈｔＣが無効であることを示すＦＡＬＳＥ（０）である。これらの記述子は、上及び下のタイル・エッジ上のプリミティブのクリッピングのために使用される。実際には、ＶｔｘＹｍｉｎ、ＶｔｘＹｍａｘ、ＶｔｘＬｅｆｔＣ、及びＶｔｘＲｉｇｈｔＣは、本来のプリミティブ・バーテックスへのインデックスであることが注目される。
【０１３９】
三角形に関しては、ＶｔｘＸｍｉｎ、ＶｔｘＸｍａｘ、ＶｔｘＴｏｐＣ、ＶｔｘＢｏｔＣ、ＴｏｐＣｏｒｎｅｒ、ＢｏｔｔｏｍＣｏｒｎｅｒ記述子は、それらのｘ座標によって三角形バーテックスをソートすることによって得られる。線セグメントに関しては、これらの記述子は、前記線クアド・バーテックスが生成される時に割り当てられる。ＶｔｘＸｍｉｎは、最小のｘ値を有するバーテックスである。ＶｔｘＸｍａｘは、最大ｘ値を有するバーテックスである。ＶｔｘＴｏｐＣは、三角形の場合では、長いｘエッジ（バーテックスＶｔｘＸｍｉｎとＶｔｘＸｍａｘとを結合させるエッジ）の上に、及び平行四辺形に関しては、バーテックスＶｔｘＸｍｉｎとＶｔｘＸｍａｘとを結合させることによって形成される対角線の上に位置するバーテックスである。前記三角形が、長いｘエッジもトップ・エッジである場合、フラグＴｏｐＣｏｒｎｅｒは、ＶｔｘＴｏｐＣが無効であることを示すＦＡＬＳＥ（０）である。同様に、ＶｔｘＢｏｔＣは、三角形の場合では、長いｘ軸の下、及び平行四辺形の場合には、バーテックスＶｔｘＸｍｉｎとＶｔｘＸｍａｘとを結合させることによって形成される対角線の下に位置するバーテックスである。三角形が、長いｘエッジもボトム・エッジである場合、フラグＢｏｔｔｏｍＣｏｒｎｅｒは、ＶｔｘＢｏｔＣが無効であることを示すＦＡＬＳＥ（０）である。これらの記述子は、左及び右のタイル・エッジ上のプリミティブをクリッピングするために使用される。実際には、ＶｔｘＸｍｉｎ、ＶｔｘＸｍａｘ、ＶｔｘＴｏｐＣ、及びＶｔｘＢｏｔＣが、本来のプリミティブ・バーテックスへのインデックスであることが注目される。さらに、４つのポリゴン・エッジのスロープ（δｘ／δｙ）及びスロープ（δｘｙδｘ）の逆元を使用する。
【０１４０】
これらの記述子のすべては、多角四辺形プリミティブに関する有効値を有するが、それらのすべてが、三角形に関して有効でなくてもよい。最初に、それは、三角形や多角四辺形のような単純なプリミティブを記述するための多くの記述子のように見える。しかしながら、後にわかるように、それらは、大変簡単に得ることができ、及びプリミティブをセットアップするための素晴らしい均一的な方法を供給する。
【０１４１】
線を長方形として扱うこと（又は長方形を線として解釈することと同様）は、空間及び幅において、二つのエンド・ポイントを特定することを伴う。三角形を長方形として扱うことは、４点を特定することを伴い、その一つ、通常一つの特定の実施形態におけるｙ左又はｘ右は、退化しており、特定されない。目的は、タイルの内側のＺｍｉｎを見つけることである。ｘ値は、ウィンドウ幅全体に及びうるのに対して、ｙ値は、タイルと相対的であるので、ビットは、ｙ値タイル相対座標を作ることによって、計算においてセーブされる。
３．２．１４  オブジェクト・タグ
３Ｄシーンの有向非輪状グラフ表示は通常、シーン・グラフにおける各ノードに、識別子を割り当てる。この識別子（オブジェクト・タグ）は、シーンにおけるオブジェクトの選択、可視性決定、衝突検出、及びレンダリングのための他の統計的パラメータの生成等、グラフィカル・オペレーションにおいて有用になりうる。レンダリングにおけるピクセル・パイプラインは、アルファ・テスト、色テスト、ステンシル・テスト、及び深度テスト等、多くのピクセル・テストを可能にする。アルファ及び色テストは、オブジェクトが、透明なピクセルを有するか決定し、及び前記値を廃棄することにおいて有用である。ステンシル・テストは、様々な特別な効果及びＣＳＧにおけるオブジェクト交差の決定に関して使用することができる。深度テストは通常、隠れ面除去に関して使用される。
【０１４２】
本明細書において、シーンにおけるオブジェクトをタグし、及びどのオブジェクトが、予め決められた可視性基準のセットを通過したかに関するフィードバック（feedback）を得る方法が説明される。
【０１４３】
二段階オブジェクト割り当て体系が利用される。オブジェクト識別子は、二つの部分、グループ（ｇ）及びメンバ・タグ（member tag）（ｔ）を含む。グループ“ｇ”は、４ビット識別子であり（しかし、より多くのビットが使用されうる）、シーン・グラフ・ブランチ（scene graph branch）、ノード・レベル（node level）、又はオブジェクトをグループ分けするために使用されてもよい他のパラメータをエンコードするために使用することができる。メンバ・タグ（ｔ）は、５ビット値である（ここでも、より多くのビットが使用されうる）。この体系において、各グループは、３２までのメンバを有することができる。３２ビット状態ワードが、各グループに関して使用される。この状態ワードのビットは、テスト基準を通過したメンバを示す。前記状態は：オブジェクト・グループ；オブジェクト・タグ；及びＴａｇＴｅｓｔＩＤ{ＤｅｐｔｈＴｅｓｔ、ＡｌｐｈａＴｅｓｔ、ＣｏｌｏｒＴｅｓｔ、ＳｔｅｎｃｉｌＴｅｓｔ}を含む。オブジェクト・タグは、パイプラインを下り、ｚバッファード・ブレンド（又は好ましい実施形態におけるピクセル・ブロック）で使用される。サンプルが可視である場合、オブジェクト・タグは、特定のＣＰＵ読み取り可能レジスタにおいて特定のビットを設定するために使用される。これによって、オブジェクトはパイプラインに送り込まれ、一度レンダリングが完了すると、ホストＣＰＵ（アプリケーション・プログラムを実行させるＣＰＵ又は複数のＣＰＵ）は、どのオブジェクトが、少なくとも部分的に可視であったかを決定することができる。
【０１４４】
代替例として、メンバ・タグ（ｔ）だけが、使用されることができ、一つのグループのみを意味する。
【０１４５】
オブジェクト・タグは、ピッキング（picking）、透明性決定、初期オブジェクト廃棄、及び衝突検出のために使用することができる。初期のオブジェクト廃棄に関して、オブジェクトは、レンダリング・パイプラインへのその境界ボリューム入力を有することによって、可視性に関してテストすることができ、及び上述のとおり「可視性」に関してテストすることができる。しかしながら、境界ボリュームが、フレーム・バッファにレンダリングされるのを阻止するために、色、深度及びステンシル・マスクはクリアされる（これらのマスク・ビットの説明に関するＯｐｅｎＧＬ仕様書を参照）。
３．２．１５  単一の可視性ビット
上述のオブジェクト・タグへの代替例として、単一のビットが、ホストＣＰＵへのフィードバックとして使用することができる。この方法において、「可視性」（すなわち、ピッキング、透明性決定、初期オブジェクト廃棄、衝突検出等）に関してテストされているオブジェクトは、それ自身のフレームにおいて隔離される。フレームにおいてすべてが可視である場合、前記単一の「可視性ビット」が設定され、そうでなければ、クリアされる。このビットは、ホストＣＰＵによって読み取り可能である。この方法の効果は、その単純性である。欠点は、テストされる必要がある各個別のオブジェクト（又は一組のオブジェクト）に関して、個別のフレームを使用する必要性であり、それによっておそらく「可視性」決定に待ち時間を導入する。
３．２．１６  スーパータイル・ホップ・シーケンス（Supertile Hop Sequence）
３Ｄ画像をレンダリングする時、しばしば「ホリゾン効果（horizon effect）」があり、画像（ピクチャ）の水平スワス（horizontal swath）は、画像の残りよりもより多くの複雑性を有する。一例は、前景における単純な草原及び上方に空を有する、遠くの都市のスカイライン（skyline）である。草原及び空は、ほとんどポリゴンを有しない（おそらく一つずつ）一方で、都市は、多くのポリゴンを有し、大きな深度計算複雑性を有する。そのようなホリゾン効果は、シーンを通して非水平スワスに沿っても起こりうる。タイルが、単純な、上から下へ、及び左から右への順番で処理される場合、複雑なタイルは、背中合わせで向かい合い、パイプライン内で可能なロード不均衡を生む。それゆえに、タイルからタイルへ移動する時、スクリーン周辺で無作為に「ホップする（hop）」方が良いであろう。しかしながら、これは、（隣接するタイルが順番に処理されないために）空間的コヒーレンシーの低減を生じ、パイプライン内のキャッシュの効率性を低減させ、及び性能を低下させる。空間的なシーケンシャル・タイル処理及び全体的な無作為パターンの妥協案として、タイルは「ＳｕｐｅｒＴｉｌｅｓ（スーパータイルズ）」へと編成され、各ＳｕｐｅｒＴｉｌｅは、多くの空間的に隣接するタイルであり、ＳｕｐｅｒＴｉｌｅｓの不作為のパターンが処理される。このように空間的コヒーレンシーは、ＳｕｐｅｒＴｉｌｅ内で保存され、ホリゾン効果は回避される。好ましい実施形態において、ＳｕｐｅｒＴｉｌｅホップ・シーケンス方法は、ソート・ブロックで実行される。
３．２．１７  スキャンアウト中の正規化
出力中の正規化（normalization）は、フレーム・バッファにおける値を決定するための、従来の処理ヒストリを考慮し、又はフレーム・バッファにおける値が決定される本発明のプロシージャであり、及びスクリーンにおける値の範囲は、前記値の範囲が表示されることができ及び所望のビューイング特性を供給することができる範囲に基準化され又は正規化される。線形及び非線形スケーリングが適用されてもよく、及びダイナミックな範囲が、いくつかの比較的明るい又は暗いピクセルによって過度に占められないように、クリッピングも許可されてもよく、前記ダイナミックな範囲は、デジタル−アナログ・コンバータ（digital-to-analog converter）の変換範囲に合致する。
【０１４６】
出力ピクセル値が生成される方法の知識は、このアプローチの効果に関してさらに大きな見識を与える。時に、出力ピクセル値が、強度又は明るさを表すのは、それらが最終的に、現実世界におけるシーンの明るさ又は強度をシミュレートし（simulate）又は表すための方法で表示されるからである。
【０１４７】
効果的に、ピクセル色は、それらが大変広いダイナミックな範囲に及ぶように、フローティング・ポイント数によって表される。適切であるが、ディスプレイに一度基準化された整数値は、後に再スケーリングを許可するために、出力強度が計算される、一定の方法で、十分な範囲を供給しないかもしれない。ＯｐｅｎＧＬを含む標準ＡＰＩの下では、光は、座標距離と同様に、フローティング・ポイント値として表される。それゆえに、従来の表示では、使用可能なディスプレイのダイナミックな範囲を廃棄し又は浪費して、シーンがすべて黒く（暗く）又はすべて白く（明るく）又は特定の明るさ範囲へと傾斜して出てくることは、比較的簡単である。
【０１４８】
本発明の正規化プロシージャの下で、計算は、フローティング・ポイント表示全体において好ましく維持され、及び最終シーンは、出力表示及びＤ／Ａコンバータ・ケイパビリティ（capability）と一致したピクセル強度値をもたらすために、スケーリング・ルーチンを使用して、マッピングされる。そのような、表示装置へのスケーリング又は正規化は、範囲の圧縮もしくは拡張、線形圧縮もしくは拡張、対数圧縮、指数もしくはパワー拡張、他の代数もしくは多項マッピング機能、又はこれらの組み合わせなしに、ある範囲の値の、異なる範囲の値へのオフセット（offset）又はシフト（shift）等のオペレーションに関与してもよい。代替的には、任意のマッピング転送機能を有するルックアップ・テーブルは、出力値強度変換を実行するために実行されてもよい。それがなされる時に画像（ピクチャ）を表示するために、バッファ・スワップする時に、対数的に（又は他に）スキャンアウト中にスケールする。
【０１４９】
望ましくは、前記変換は、一組の予め決められた規則の下で、自動的に実行される。例えば、正規化に基づいてピクセル・ヒストグラム（pixel histogram）を特定する規則が実行されてもよく、又はピクセルのガウス分散（Gaussian distribution）を特定する規則、又はある任意の強度クリッピングで、あるいはそれなしで、出力強度を線形にスケールする規則が実行されてもよい。ここに示された様々なマッピング機能は、コンピュータ・グラフィックス及びデジタル画像処理分野において公知である多くの入力／出力ピクセル強度変換の単なる例である。
【０１５０】
このアプローチは、ライティング、オブジェクトの色、等を特定するにあたり、いくらか大きな余地も許し、及び可視であった最終出力をレンダリングする。最終結果が、審美的に完璧でなかったとしても、それは最終マッピングをチューニングするための基礎を供給し、及び対話型調整が、好ましいが任意に、デバッギング（debugging）、ファイン・チューニング（fine-tuning）、又はセットアップ・オペレーション（set-up operation）として供給されてもよい。
３．２．１８  スタンプ・ベースｚ値記述
ＶＳＰが送られる時、それは単一のプリミティブに対応し、及びｚバッファード・ブレンド（すなわちピクセル・ブロック）は、ＶＳＰにおけるすべてのサンプルに関する個別のｚ値を必要とする。ＶＳＰ内のすべてのパー・サンプルｚ値を送ることに対する改良として（それは、かなりの帯域幅を取る）、前記ＶＳＰは、ｚ参照値及びｘ並びにｙに関してｚの部分的導関数（数学的には、プリミティブのｚ値に関する平面方程式）を含みうる。それから、この情報は、パー・サンプルｚ値を再構築するために、ｚバッファード・ブレンド（すなわちピクセル・ブロック）において使用され、それによって帯域幅を省く。ＣＨＳＲ処理のために計算されたｚ値が、ｚバッファード・ブレンド（すなわちピクセル・ブロック）におけるコンピュータと同じになるように、注意が払われなければならないのは、不一致がレンダリング・エラーを生じうるからである。
【０１５１】
好ましい実施形態において、スタンプ・ベースｚ値記述方法は、カル・ブロックにおいて実行され、及びパー・サンプルｚ値は、ピクセル・ブロックにおけるこの記述から生成される。
３．２．１９  フォン・ブロックにおけるオブジェクト・ベース・プロセッサ・リソース・アロケーション（Object-based Processor Resource Allocation）
フォン・ライティング・ブロックは、効果的に、複数のプロセッサ又は処理エレメントを含む。フラグメント色生成の間、多くの状態が必要とされ、共通オブジェクトからのフラグメントは、同じ状態を使用し、それゆえに、好ましくは、キャッシング要求を最小化する少なくとも効率的な理由から、同じオブジェクトからのフラグメントは、同じプロセッサによって処理される。
【０１５２】
本発明の構造及び方法において、同じオブジェクトから由来するすべてのフラグメントは、同じプロセッサに送信される（又は、同じ複数のプロセッサにロードするサーバがある場合）。これは、フォン・ブロックにおける状態キャッシングを低減させる。
【０１５３】
本発明の構造及び方法の好ましい実施形態は、パー・タイル処理を実行し、及び単一の時間は、複数のオブジェクトを含んでもよいことを想起させる。フォン・ブロック・キャッシュは、それゆえに、通常は一つ以上のオブジェクトに関する状態を記憶し、及び適切な状態を、共通オブジェクトからのフラグメントを扱っているプロセッサに送信する。特定のオブジェクトからのフラグメントに関する状態が、特定のプロセッサに送信されると、前記オブジェクトからのすべての他のフラグメントも、前記プロセッサに向けられるのが好ましい。
【０１５４】
これに関して、モード・インジェクション装置（Mode Injection Unit）（ＭＩＪ）は、オブジェクト又は素材を割り当て、及びＭＩＪは、すべてのダウン・ストリーム・ブロック（down stream blocks）にキャッシュを割り当てる。フォン装置は、どのオブジェクト・データが、どのフォン装置プロセッサにキャッシュされたかを追跡し、及び同じオブジェクトに属するすべてのフラグメントを、同じプロセッサに注ぎ込むよう試みる。これに関する唯一の任意の例外は、局所的不均衡がある場合に生じ、その場合、フラグメントは他のプロセッサに割り当てられるであろう。
【０１５５】
このオブジェクト・タグ・ベースのリソース割り当て（代替的には、前記記述のほかの部分において、素材・タグ・ベースのリソース割り当てを指す）は、フォン装置において、フラグメント・プロセッサ又はフラグメント・エンジンと相対して生じる。
３．２．２０  パイプライン状態としてのダイナミック・マイクロコード生成
フォン装置は、テクスチャ環境計算を実行し、及びオブジェクトからのフラグメントを処理するための特定の処理エレメントを選択することを担当する。上述のとおり、共通オブジェクトからのフラグメントを、同じフォン・プロセッサ又はエンジンに向けるための試みがなされる。適用されるべき特定のテクスチャ、面、色等のプロパティから独立して、多くの選択肢があり、その結果として処理環境における変化がある。ダイナミック・マイクロコード生成（dynamic microcode generation）は、テクスチャ環境及びライティングに関連して説明され、本発明の構造及びプロシージャは、他の種類のマイクロコード、マシン状態、及び処理に、通常、より幅広く適用されてもよい。
【０１５６】
本発明の構造及び方法において、三角形ストリップの処理が開始されるたびに、変更素材パラメータが生じ、又はテクスチャ環境に触れるほとんどの変更が生じ、フォン装置におけるマイクロコード・エンジンは、マイクロコードを生成し、及びこのマイクロコードは、パイプライン状態のコンポーネントとして扱われる。状態のマイクロコード・コンポーネントは、他のパイプライン状態と同様に、キャッシュされる属性である。通常、マシン状態として、特定的には３Ｄグラフィックス・プロセッサにおけるパイプライン状態として、この方法で生成されるマイクロコードの扱いが、実質的な効果である。
【０１５７】
例えば、フォン装置は、複数のプロセッサ又はフラグメント・エンジンを含む。（ここでは、フラグメント・エンジンという用語は、フラグメントのテクスチャ処理を担うフォン装置におけるコンポーネントを意味し、フラグメント・ブロックにおいて生じる補間とは異なる処理である。）マイクロコードは、フラグメント・エンジンに入ってくる、及び同じマイクロコード（状態）を必要とするあらゆる他のフラグメントが、必要な時にそれを有するように、フラグメント・エンジンにダウンロードされる。
【０１５８】
フォン・ブロックにおけるフラグメント・エンジンの各々の実施形態は、一般的に同じであるが、ダウンロード可能なマイクロコードの存在は、ある程度の専門化を与える。異なるマイクロコードは、どのようにＭＩＪキャッシング・メカニズムが動作するのかに依存する各々に、ダウンロードされてもよい。ダイナミックなマイクロコード生成は、テクスチャ環境及びライティングに供給される。
３．２．２１  可変スケール・バンプ・マップ（Variable Scale Bump Maps）
可変スケール・バンプ・マップを生成することは、二つの個別のプロシージャ：自動ベース生成及び自動勾配フィールド生成のうちの一つ又は両方に関与する。グレイ・スケール画像及びその強度空間におけるデリバティブ（derivative）を検討する。自動勾配フィールドは、グレイ・スケール強度と比較して、グレイ・スケール画像のデリバティブを取り、及び前記デリバティブを、バンプ・マップのためのバンプを生成するための面法線摂動として使用する。自動ベース生成は、計算、ポリゴン・メモリにおけるメモリ記憶、及び処理における入力帯域幅を省く。
【０１５９】
各三角形バーテックスに関して、ｓ、ｔ及び面法線が特定される。しかし、前記ｓ及びｔは、色付きではなく、テクスチャ・マップへの２次元面法線摂動であり、それゆえにテクスチャ・バンプ・マップである。前記ｓ及びｔは、使用可能なバンプ・マップを生成するために、面法線を摂動させるべき方向を特定するために使用される。前記ｓ、ｔは、摂動方向を特定することができる暗示された座標システム及び参照を与える。各ピクセルにおけるｓ、ｔ座標システムの使用は、面接線及びピクセル場所（location）における従法線を特定する必要をなくす。その結果、本発明の構造及び方法は、計算、メモリ記憶、及び入力帯域幅を省く。
３．２．２２  タイル・バッファ及びピクセル・バッファ
一組のパー・ピクセル・タイル・ステージング・バッファ（tile staging buffer）は、ＰｉｘｅｌＯｕｔとＢＫＥブロックとの間に存在する。これらのバッファの各々は、三つの状態ビットＥｍｐｔｙ、ＢｋｅＤｏｎｅＦｏｒＰｉｘ、及びそれと関連するＰｉｘｃＤｏｎｅＦｏｒＢｋｅを有する。これらのビットは、これらのバッファの使用のために、ＰｉｘｅｌＯｕｔとＢａｃｋｅｎｄとの間のハンドシェイク（handshake）を規制（又はシミュレート）する。バックエンド及びＰｉｘｅｌＯｕｔ装置の両方は、前記装置がそこから読み取り又はそこに書き込むステージング・バッファを示す現在のＩｎｐｕｔＢｕｆｆｅｒ及びＯｕｔｐｕｔＢｕｆｆｅｒポインタを維持する。
【０１６０】
ＰＩＸによるレンダリングするためのタイルを準備するために、ＢＫＥブロックは、次のＥｍｐｔｙバッファを取り、及びフレーム・バッファ・メモリからデータを読み込む（必要な場合には、ＲＧＢＡＣｌｅａｒＭａｓｋ、ＤｅｐｔｈＭａｓｋ、及びＳｔｅｎｃｉｌＭａｓｋによって決定されたとおり−一組のビット・プレーンがクリアされない場合、それは読み込まれる）。Ｂａｃｋｅｎｄがタイルにおける読み取りを伴ってなされた後、それはＢｋｅＤｏｎｅＦｏｒＰｉｘビットを設定する。ＰｉｘｅｌＯｕｔは、ＩｎｐｕｔＴｉｌｅのＢｋｅＤｏｎｅＦｏｒＰｉｘビットを見る。このビットが設定されない場合、ＰｉｘｅｌＯｕｔは停止し、そうでなければ、それはＢｋｅＤｏｎｅＦｏｒＰｉｘビット、及びピクセル・タイル・バッファにおける色、深度、及び／又はステンシル・ビット・プレーン（必要であれば）をクリアし、及びそれをサンプル・バッファに適切に転送する。
【０１６１】
出力時、ＰｉｘｅｌＯｕｔ装置は、レンダリングされたタイルにおけるサンプルを、ピクセル・タイル・バッファにおけるピクセルに分解する。バックエンド装置（ＢＫＥ）ブロックは、これらのバッファを、フレーム・バッファ・メモリに転送する。ピクセル・バッファは、ＰｉｘｅｌＯｕｔ装置によって順番にトラバース（traverse）される。ＰｉｘｅｌＯｕｔは、レンダリングされたサンプル・タイルを、それが由来する同じピクセル・バッファに放出する。前記ピクセル・タイル・バッファに出力された前記タイルが完了した後、ＰｉｘｅｌＯｕｔ装置は、ＰｉｘＤｏｎｅＦｏｒＢｋｅビットを設定する。ＢＫＥブロックは、ＰｉｘＤｏｎｅＦｏｒＢｋｅセットを有するピクセル・タイル・バッファを取ることができ、前記ビットをクリアし、及びそれをフレーム・バッファ・メモリに転送する。前記転送が完了した後、エンプティ（Empty）・ビットが、前記バッファ上で設定される。
３．２．２３  スキャンアウト中のウィンドウド・ピクセル・ズーミング（Windowed Pixel Zooming During Scanout）
バックエンド装置は、データの送信を担い、及び／又はＣＲＴあるいは他の表示装置に信号を送信し、及び前記デジタル情報を、前記ディスプレイを駆動するのに適したアナログ信号に変換するためのデジタル−アナログ（Ｄ／Ａ）コンバータを含む。前記バックエンドはまた、バイリニア・インターポレータ（bilinear interpolator）も含むので、前記フレーム・バッファからのピクセルは、それらがＣＲＴディスプレイに送信される時に、前記ピクセルの空間的スケールを変更するために、補間されうる。スキャンアウト中のピクセル・ズーミングは、稼動中に解像をスケールし又はズーム（イン又はアウト）するレンダリングを伴わない。一つの実施形態において、ピクセル・ズーミングは、ウィンドウごとに選択的に実行され、ウィンドウは、全体のデスクトップ又はディスプレイ領域の一部である。
３．２．２４  スキャンアウト中の仮想ブロック転送（ＶＢＬＴ）
従来の構造及び方法は、オン・スクリーン（on-screen）メモリ記憶装置及びオフ・スクリーン（off-screen）メモリ記憶装置を供給し、その各々は例えば、色バッファ、ｚバッファ、及びあるステンシルを有する。３Ｄレンダリング処理は、これらのオフ・スクリーン・バッファにレンダリングする。一つのスクリーン・メモリは、ディスプレイ上に示されるデータに対応する。オフ・スクリーン・メモリへの前記レンダリングが完了した時、オフ・スクリーン・メモリの内容は、ブロック転送（ＢＬＴ）と称されるものにおいて、オン・スクリーン・メモリにコピーされる。
【０１６２】
メモリ帯域幅を省き、及び本明細書の他の部分で説明された他の利益を理解するために、本発明の構造及び方法は、データを接合し、又は他の場所からデータを読み取ることによって、「仮想」ブロック転送又は仮想ＢＬＴを実行する。
３．２．２５  バーテックス・リストに関するトークン挿入（Token Insertion for Vertex Lists）
本明細書におけるトークンは、パイプラインに送り込まれ、次のエントリが何に対応するかを前記パイプラインに知らせる他の項目の間に介在した情報項目である。例えば、バーテックスのｘ、ｙ、ｚ座標が、パイプラインに送り込まれ、及びそれらが３２ビットの量である場合、前記トークンは、前記パイプラインに、次の数字がバーテックスｘ、ｙ、ｚ値であることを知らせるために挿入されるのは、識別のためのエントリそのものには、余分なビットがないからである。前記トークンは、パイプライン・ハードウェアに、送り込まれているデータをどのように解釈するかを知らせる。
（発明の最良の実施形態）
４．  システム・レベル概観
パイプラインは、ホスト・コンピュータのＩ／Ｏバスからデータを取り、それを処理し、及びそれをコンピュータのディスプレイに送信する。パイプラインは、１２のブロック、さらに三つのメモリ・ストア及びフレーム・バッファに分割される。図１５は、パイプライン１０００を通るデータの流れを示す。パイプラインを作るブロックは、後述される。
４．１  コマンド・フェッチ及びデコード（Command Fetch and Decode）（ＣＦＤ）
コマンド・フェッチ及びデコード（ＣＦＤ）２０００は、Ｉ／Ｏバスを通したホスト・コンピュータとの通信を扱う。それは、その入力を一連のパケットに変換し、それをジオメトリ・ブロックに渡す。入力ストリームのほとんどは、幾何学的データ―線、点、及びポリゴンを含む。これら幾何学的なオブジェクトの記述は、色、面法線、テクスチャ座標等を含みうる。入力ストリームはまた、ライティング、ブレンディング・モード、及びバッファ機能等のレンダリング情報も含む。
４．２  ジオメトリ（ＧＥＯ）
ジオメトリブロック３０００は、４つの主なタスク、すなわち：変換、すべてのポリゴンの、三角形への分解、クリッピング及びグロー・シェーディングに必要なパー・バーテックス・ライティング計算を扱う。
【０１６３】
第一に、ジオメトリ・ブロックは、入力グラフィックス・プリミティブを、統一座標空間（「ワールド空間」）に変換する。それは、プリミティブをビューイング・ボリューム、又は錘台にクリッピングする。ビューイング・ボリューム（左、右、上、下、前及び後ろ）を定義する６面に加えて、ＤＳＧＰパイプラインは、６のユーザ定義可能クリッピング面を供給する。クリッピング後、ジオメトリ・ブロックは、三つ以上のバーテックスを有するポリゴンを、処理を簡潔にするために、三角形の組に分割する。
【０１６４】
最後に、フレームにグロー・シェーディングがある場合、ジオメトリ・ブロックは、グラグメント・ブロックが、シェーディングを実行するために使用するバーテックス色を計算する。
４．３  モード・エクストラクション（ＭＥＸ）
モード・エクストラクション・ブロック４０００は、データ・ストリームを二つの部分、：１）バーテックス、及び２）他のすべてに分離する。バーテックスは、ソート・ブロックに送られる。「他のすべて」―ライト、色、テクスチャ座標等―は、ポリゴン・メモリと呼ばれる特別なバッファに記憶され、モード・インジェクション・ブロックによって検索することができる。ポリゴン・メモリは、二重バッファされるので、モード・インジェクション・ブロックは、ひとつのフレームに関してデータを読み取ることができるのに対して、モード・エクストラクション・ブロックは、次のフレームに関してデータを記憶している。ポリゴン・メモリに記憶されたモード・データは、３つの主なカテゴリ：パー・フレーム・データ（ライティング等）、パー・プリミティブ・データ（素材属性等）、及びパー・バーテックス・データ（色等）に分類される。モード・エクストラクション及びモード・インジェクション・ブロックはさらに、効率性を最適化するために、これらのカテゴリを分割する。
【０１６５】
各バーテックスに関して、モード・エクストラクション・ブロックは、バーテックス・データを含むパケットであるＳｏｒｔブロック、及びポリゴン・メモリへのポインタを送る。（前記ポインタは、色ポインタと称され、やや誤解を招きやすい。なぜならば、それは色以外のすべての種類の他の情報を検索するために使用されるからである。）前記パケットはまた、前記バーテックスが点か、線の端点か、又は三角形の角を表すのかを示すフィールドも含む。前記バーテックスは、厳格な時間順に送られ、それはそれらがパイプラインに送り込まれたのと同じ順番である。前記パケットはまた、現在のバーテックスが、一定のプリミティブにおける最後の一つを形成するのかを特定する（すなわちプリミティブを「完成させる」）。三角形ストリップ又はファン、及び線ストリップ又はループの場合、前記バーテックスは、隣接するプリミティブの間で共有される。この場合、前記パケットは、各プリミティブにおける他のバーテックスをどのように識別するかを示す。
４．４  ソート（ＳＲＴ）
ソート・ブロック６０００は、モード・エクストラクション・ブロックからバーテックスを受け取り、及びその結果の点、線及び三角形を、タイルでソートする。二重バッファされたソート・メモリ７０００において、それはグラフィック・プリミティブを表すバーテックスのリストと、及び一組のタイル・ポインタ・リスト―フレームにおける各タイルに一つのリストを維持する。それが、（三角形における第三のバーテックス等）プリミティブを完成させるバーテックスを受け取る時、どのタイルに前記プリミティブが触れるかを見るために調べる。プリミティブが触れる各タイルに関して、ソート・ブロックは、前記バーテックスへのポインタを、前記タイルのタイル・ポインタ・リストに加える。
【０１６６】
ソート・ブロックが、フレームにおけるすべてのジオメトリのソートを完了した時、それはデータをセットアップに送る。各ソート・ブロック出力パケットは、完全なプリミティブを表す。ソートは、その出力をタイルごとのオーダで送る：一定のタイルに触れるすべてのプリミティブ、それから、次のタイルに触れるすべてのプリミティブ、等である。これは、ソートが、それが触れる各タイルにつき一回、同じプリミティブを何回も送ることを意味することが注目される。
４．５  セットアップ（ＳＴＰ）
セットアップ・ブロック８０００は、線及び三角形に関する空間的微分を計算する。それは、１タイル分の価値を有するデータ、一度に１プリミティブを処理する。それが一つのプリミティブで完了される時、それは前記データをカル・ブロックに送る。セットアップ・ブロックはまた、点線を個別の線セグメントに分解し（各々は、長方形領域である）、及びタイル内における各プリミティブに関して最小ｚ値を計算する。セットアップからの各プリミティブ・パケット出力は、一つのプリミティブを表す：三角形、線セグメント又は点である。
４．６  カル（ＣＵＬ）
カル・ブロック９０００は、より複雑なブロックの一つであり、及び処理は２つのステップに分割される：マグニチュード比較コンテント・アドレッサブル・メモリ（ＭＣＣＡＭ）カル、及びサブピクセル・カルである。カル・ブロックは、１タイル分の価値を有するデータを一度に受け取る。ＭＣＣＡＭカルは、以前に処理されたジオメトリによって完全に隠されたプリミティブを廃棄する。サブピクセル・カルは、（一部又は全体が可視である）残りのプリミティブを取り、及び可視フラグメントを決定する。サブピクセル・カルは、可視スタンプ・ポーション（Visible Stamp Portion）（ＶＳＰ）と呼ばれる、１スタンプ分の価値を有するフラグメントを一度に出力する。図１６は、カル・ブロックが、部分的に不明瞭にされた三角形からどのようにフラグメントを生成するかの一例を示す。
【０１６７】
カル・ブロックによって生成される可視スタンプ・ポーションは、複数のプリミティブが前記スタンプに触れる場合であっても、たった一つのプリミティブからのフラグメントを含む。それゆえに、ダイアグラムにおいて、出力ＶＳＰは、灰色の三角形のみからのフラグメントを含む。白い三角形の先端によって形成されるフラグメントは、個別のＶＳＰで送られ、及び前記二つのＶＳＰの色は、ピクセル・ブロックにおいて、後に結合される。
【０１６８】
一つのＶＳＰにおける各ピクセルは、ピクセルのうち、どれだけが一定のフラグメントによって覆われるかを決定するために、多くのサンプルに分割される。ピクセル・ブロックは、前記ピクセルに関する最終の色を生成するために、フラグメントをブレンドする時、この情報を使用する。
４．７  モード・インジェクション（ＭＩＪ）
モード・インジェクション・ブロック１００００は、―色、素材属性等―モード情報を、ポリゴン・メモリ５０００から検索し、及びそれを要求のとおりに下に送る。帯域幅を省くために、個別のダウンストリーム・ブロックは、最近使用されたモード情報をキャッシュする。モード・インジェクション・ブロックは、どの情報がダウンストリームにキャッシュされるのかを追跡し、必要な情報のみを送る。
４．８  フラグメント（ＦＲＧ）
フラグメント・ブロック１１０００は、その主な仕事が補間であるため、やや誤解を招きやすい名前である。それは、グロー・シェーディングのための色値、フォン・シェーディングのための面法線及びテクスチャ・マッピングのためのテクスチャ座標を補間する。それはまた、バンプ・マップが使用される場合、バンプ・マッピング・アルゴリズムでの使用のために、面接線を補間する。
【０１６９】
フラグメント・ブロックは、重心係数を使用して、透視的な修正された補間を実行する。
４．９  テクスチャ（ＴＥＸ）
テクスチャ・ブロック１２０００は、テクスチャ・マップを、ピクセル・フラグメントに適用する。テクスチャ・マップは、テクスチャ・メモリ１３０００に記憶される。上述された他のメモリ記憶とは異なり、テクスチャ・メモリは単一にバッファされる。それは、ホスト・コンピュータのメモリから、ＡＧＰインターフェースを使用してロードされる。単一のポリゴンは、４つまでのテクスチャを使用することができる。
【０１７０】
テクスチャは、ミップ・マップ（mip-mapped）される。すなわち、各テクスチャは、様々なレベルのディテール（detail）において、一連のテクスチャ・マップを具備し、各マップは、アイ・ポイント（eye point）から一定の距離における、テクスチャの外観を表す。一定のピクセル・フラグメントに関するテクスチャ値を生成するために、テクスチャ・ブロックは、正しいレベルのディテールに近似するように、テクスチャ・マップからトリリニア補間（tri-linear interpolation）を実行する。テクスチャ・ブロックはまた、異方向補間等、他の補間方法も実行する。
【０１７１】
テクスチャ・ブロックは、補間されたテクスチャ値を（一般的にはＲＧＢＡ色値として）、パー・フラグメント・ベースでフォン・ブロックに供給する。バンプ・マップは、特別な種類のテクスチャ・マップを表す。色の代わりに、バンプ・マップの各テクセル（texel）は、高さフィールド勾配を含む。
４．１０  フォン（ＰＨＧ）
フォン・ブロック１４０００は、各ピクセル・フラグメントに関するフォン・シェーディングを実行する。それは、フラグメントの外観の色を決定するために、モード・インジェクション・ブロックによって供給される素材及びライティング情報、テクスチャ・ブロックからのテクスチャ色、及びフラグメント・ブロックによって生成される面法線を使用する。バンプ・マッピングが使用される場合、フォン・ブロックは、シェーディングの前に、フラグメントの面法線を摂動させるために、テクスチャ・ブロックからの補間された高さフィールド勾配を使用する。
４．１１  ピクセル（ＰＩＸ）
ピクセル・ブロック１５０００は、ＶＳＰを受け取り、各フラグメントは個別の色値を有する。ピクセル・ブロックは、ピクセル・オーナシップ・テスト、シザー・テスト、アルファ・テスト、ステンシル・オペレーション、深度テスト、ブレンディング、ディザリング及び論理オペレーションを、各ピクセルにおける各サンプル上で実行する（ＯｐｅｎＧＬ仕様書１．１、セクション４．１、「パー・フラグメント・オペレーション（Per-Fragment Operations）」、１０９ページ参照）。ピクセル・ブロックが、１タイル分の価値を有する処理されたピクセルを蓄積した時、それは、各ピクセル内のサンプルをブレンドし（それによって、ピクセルのアンチエイリアシングを実行する）、及び、フレームバッファに記憶されるべきそれらをバックエンドに送る。
【０１７２】
図１７は、ピクセル・ブロックがどのように１スタンプ分の価値を有するフラグメントを処理するかを説明する。この例において、ピクセル・ブロックは、灰色の三角形から一つ、及び白い三角形から一つ、二つのＶＳＰを受け取る。それは、最終ピクセルを生成するために、フラグメントとバックグラウンド（background）をブレンドする。それは、前記ピクセルのどれくらいをそれが覆うかに従って、―より正確には、それが覆うサンプルの数によって、各フラグメントに加重する。
【０１７３】
このブレンディングに加えて、ピクセル処理ブロックは、ステンシル・テスト、アルファ・ブレンディング、及びピクセルのアンチエイリアシングを実行する。それが、１タイル分の価値を有する、処理されたピクセルを蓄積する時、フレームバッファに記憶されるべきそれらを、バックエンドに送る。
４．１２  バックエンド（ＢＫＥ）
バックエンド１６０００は、１タイル分の価値を有するピクセルを、一度に、ピクセル・ブロックから受け取り、それらをフレームバッファ１７０００に記憶する。特定のフレームバッファ値は、フレームからフレームへと残存することができるので、バックエンドはまた、１タイル分の価値を有するピクセルを、ピクセルブロックに戻す。例えば、ステンシル・ビット値は、多くのフレームに対して一定でありうるが、すべてのフレームにおいて使用されうる。
【０１７４】
フレームバッファを制御することに加えて、バックエンドは、２Ｄ描画を実行し、及び処理されたフレームを出力装置に送る。それは、フレームバッファとコンピュータ・モニタ及びビデオ出力との間でインターフェースを供給する。
４．１３  パイプラインにおけるブロック間の通信
本発明の構造及び方法は、パイプラインの機能的ブロックの間の、パケット化された通信のために供給される。これらのパケットの性質は、セクション３におけるオペレーションのより早い説明と同様に、個別の機能的ブロック・セクションにおいて説明される。
５  システムブロックの詳細な説明
５．１バスインタフェースブロック（ＡＧＩ）
ＡＧＩブロックは、ホストメモリーまたはＣＰＵにデータを送受信するためにＡＧＰ及び/またはＰＣＩ規格に定められた全ての機能を提供する役割を担う。本ブロックは、ＡＧＰバスと残りのチップ間の非同期境界を完全に内包していなければならない。ＡＧＩブロックは、ＰＩＯによるコマンドの素早い転送を可能にするために、ＡＧＰ２．０内のオプションのFast Write機能を利用する。ＡＧＩブロックは、ＣＦＤ上のRead/Write Controller、DMAController、及びInterrupt Control レジスタに接続されている。
５．２  コマンド取り出し及び復号化ブロック（ＣＦＤ）
概要
ＣＦＤブロックは、ＡＧＰインタフェースと実際に絵を描くハードウェアとの間に位置するユニットである。多くの制御及びデータ転送ユニットがあるが、それらはほとんどまたは全く演算を行わない。ＣＦＤブロックの主な仕事は、他のブロックへのデータのルーティングである。２Ｄ、３Ｄ、バックエンド、及びRing用のコマンド及びテクスチャは、ＡＧＰバスを通り、フロントエンドによりそれらを使用するユニットにルーティングされる。ＣＦＤは、いくつかのコマンドを復号化及びアンパッキングし、ＡＧＰインタフェースを管理し、DMA転送に関与し、コンテキストスイッチの状態を保持する。本ＣＤＦは、ＤＳＧＰシステムの最も小さな、かつ最も重要な構成品の一つである。
【０１７５】
図１８は、ＣＤＦブロック２０００内の主な機能ユニットを示すパイプラインのブロック図である。ＤＳＧＰグラフィックスシステムのフロントエンドは、ＡＧＩブロック及びＣＦＤブロックの二つのサブユニットに分けられている。残りの部分は、ＣＦＤブロックのアーキテクチャの描写に関与する。ＡＧＩを参照するが、それらの参照は、ＡＧＩと関連のあるＣＦＤの文脈に含まれる。
サブブロックの説明
Read/Write Control
ＡＧＩがＡＧＰまたはＰＣＩの読み出し/書き込みトランザクションを完了すると、次にRead/Write Control 2014にデータを送る。書き込みの場合、本機能ユニットは、受信したアドレスを使用してレジスタまたはその物理アドレスに対応するキュー内にデータを多重化する（詳細はAddress Spaceを参照）。読み出しの場合、読み出しトランザクションを完了させるために、デコーダが適切なレジスタからＡＧＩブロックへとデータを多重化する。
【０１７６】
Read/Write Controlは、CFDアドレススペース内の全ての可視レジスタに対して読み出しまたは書き込みが可能であり、２Dまたは3D Command キュー 2022、2026に書き込みが可能であり、バックエンド・インプット・バス2036を通じて読み出し及び書き込みの転送が可能である。
【０１７７】
Read/Wrote Decoderが読み出し専用レジスタまたは存在しないレジスタに対して書き込みを受信した場合、アクセス違反割り込みのトリガー要求を行う割り込み発生器2016に対してメッセージを送信しなければならない。本デコーダの上記書き込みに対する責任は消滅するが、読み出し及び書き込みは継続して受け付けなければならない。
【０１７８】
Read/Write Decoderが書き込み専用レジスタまたは存在しないレジスタに対して読み出しを受信した場合、すぐにその読み出しトランザクションをキャンセルしなければならない。次に、本デコーダは、Interrupt Generatorにメッセージを送信してアクセス違反割り込みの生成を要求する。本デコーダの上記読み出しに対する責任は消滅するが、読み出し及び書き込みは継続して受け付けなければならない。
2D Command キュー
DSGPグラフィックスハードウェア用のコマンドは、種々の潜在機能を持っており、ホストからバーストモードで送られて来るため、AGIと２D間で数キロバイトのバッファリングが必要になる。本バッファは、３D用のコマンドバッファと比較して数分の一の大きさである。このサイズは、AGIを通じてのコマンド送信速度と２Dによる性能モードのコマンド実行の差を埋めるものでなければならない。
【０１７９】
本キューは、オーバーランを防止する目的でフロー制御される。２D高水位レジスタは、キューへの許容エントリ数がホストによってプログラミングされている。このエントリ数が満たされるか超過すると、２D高水位割り込みが発生する。ホストがこの割り込みを受け取ると、すぐに高水位割り込みを無効化し、低水位割り込みを有効化する。キューにおけるエントリ数が２D低水位マークレジスタ内のそれよりも少ない場合、低水位割り込みが発生する。高水位割り込みを受信してから低水位を受信するまでの間は、ドライバーはほぼ満杯のコマンドバッファへの書き込みを防止する役割を果たす。
3D コマンドキュー
AGI と3D Command Decode 2034間においても数キロバイトのバッファリングが必要になる。このサイズは、AGIを通じてのコマンド送信速度とGEOブロックによる性能モードのコマンド実行速度の差を埋めるものでなければならない。
【０１８０】
本キューは、オーバーランを防止する目的でフロー制御される。３D高水位レジスタは、キューへの許容エントリ数がホストによってプログラミングされている。このエントリ数が満たされるか超過すると、３D高水位割り込みが発生する。ホストがこの割り込みを受け取ると、すぐに高水位割り込みを無効化し、低水位割り込みを有効化する。キューにおけるエントリ数が３D低水位マークレジスタ内のそれよりも少ない場合、低水位割り込みが発生する。高水位割り込みを受信してから低水位割り込みを受信するまでの間は、ドライバーはほぼ満杯のコマンドバッファへの書き込みを防止する役割を果たす。
3D Command Decode
コマンドデコーダ２０３４は、3D Cmd キュー 2026 及び3D Response キュー 2028からのコマンドを読み込み、翻訳し、再フォーマットされたパケットとしてGEOブロックへの送信の役割を果たす。デコーダは、GEOブロックへのコマンド送信またはコマンドによる変化状態のシャドーイングに先立って「急速」コマンドに対するデータ変換を行う。3D Command Decodeは、フォーマット変換も可能でなければならない。入力データフォーマットは、APIが許容する全てのフォーマットを含む（一般的には、C言語及び他のプログラミング言語内で許容されたフォーマット）。3D Command Decodeからの出力フォーマットは、ハードウェアが処理可能なものに限られ、概ね浮動小数点または「カラー」フォーマットである。カラーデータフォーマットの正確なビット定義は、カラーがパイプラインの残りの部分を通じてどのように表現されるかにかかっている。
Command Decode は、 3D Command キューからのパワーアップ読み込み時に開始する。DMAコマンドが検出された場合、コマンドデコーダは、コマンド及びデータをDMAコントローラ２０１８に送信する。DMAコントローラは、３D応答キュー内に要求されたデータの転送を開始する。次に、3D Command Decoderは、応答キュー内のデータを正常コマンドストリームとして解釈しながら3D Response キュー からのDMAコマンド内に指定されたバイト数を読み出す。本デコーダがDMAコマンド内に指定されたバイト数の読み出しを終えると、正規のコマンドキューからの読み出しに戻る。3D Response キュー からの読み出しの間、全てのDMAコマンドは無効コマンドと想定される。
【０１８１】
本３Ｄコマンドデコーダは、無効コマンド検索の役割を果たす。あらゆる無効コマンドの実行結果は、Invalid Command Interruptの発生に繋がる（詳細は Interrupt Control参照）。
【０１８２】
3D Command Decode は、キュー内で頂点コマンドが検索された場合は、頂点パケットの送信に必要な最新状態ベクターも解釈し、保存する。本デコーダはまた、現在の「開始」(OpenGL規約参照)内の最後３つの完成された頂点及びそれらに伴う状態を、最後に送信されてきた「開始」と同様に記憶する。コンテキスト変換が起きた場合、3D Command Decodeは、ホストが後でコンテキストを再開することにより「パイプを再準備」できるようにこれらシャドーイングされた値を読み出せるようにする。
DMA コントローラ
CFD DMA コントローラ2018は、ＤＳＧＰカードへのまたは同カードからの全てのDMAトランザクションを開始及び維持する役割を負う。ＤＳＧＰは、常にあらゆるDMA転送のマスターであり、DMAコントローラをスレーブとして使用する必要はない。2D Engine および3D Command DecodeがDMA コントローラのマスターの座を競う。2ＤブロックのみがDMA書き込み開始が可能であるが、DMA書き込み及びDMA読み出しの双方がサポートされている。ＤＳＧＰは、常にDMAのマスターである。
【０１８３】
DMA転送は次のように開始される。開始場所の物理アドレスを伴うDMAコマンド及び転送バイト数が２Ｄまたは３Ｄコマンドキューに書き込まれる。本コマンドが3D Command Decoderまたは２Ｄユニットにより読み出されると、データを伴うDMA要求がDMA Controllerに送信される。２ＤによるDMA書き込みの場合、２ＤユニットがデータをWrite To Host キュー 2020に入れ始める。DMAコントローラが先行のDMAを終えると、DMA要求を承認してデータ転送を開始する。上記DMAがDMA書き込みである場合、コントローラは、Write To Host キューからＡＧＩを通じてシステムメモリへまたはBackend Input バスを通じてフレームバッファへデータを送信する。DMAがDMA読み出しである場合、コントローラは、ＡＧＩを通じてシステムメモリからまたはBackend Outputバス2038を通じてバックエンドから2D Responseキューまたは3D Responseキューへとデータを引き込む。コントローラが必要バイト数を転送し終えると、DMA要求を開放して要求を出したユニットがそのCommandキューから次のコマンドを読み出せるようにする。
【０１８４】
AGP Logic の性能を最大限引き出せるように、DMA コントローラは、転送残量が（Mximizing AGP Performance白書に勧告されているように） キャッシュ行よりも少なくなるまで非キャッシュ行整列された読み出し/書き込みを実行して（必要ならば）トランザクションを開始し、その後キャッシュ行転送を行う。
2D Responseキュー
2D Responseキューは、２Ｄブロックにより開始されたDMA読み出しからのデータの貯蔵部である。DMA要求が送信された後は、2D Engineは 2D Response キューからの読み出し動作を行い、2D Command キュー内のコマンド同様に読み出した内容を扱う。制約は、DMAコマンドが応答キューに来た場合に無効コマンドとして扱うことだけである。応答キューから現DMAコマンド内に指定されたバイト数を読み出した後は、2D Engineは2D Commandキューからのコマンド読み出しに戻る。
５．２．２．７  D Responseキュー
3D Responseキューは、3D Command Decodeにより開始されたDMA読み出しからのデータの貯蔵部である。DMA要求が送信された後は、Command Decodeは3D Responseキューからの読み出し動作を行い、3D Command キュー内のコマンド同様に読み出した内容を扱う。制約は、DMAコマンドが応答キューに来た場合に無効コマンドとして扱うことだけである。応答キューから現DMAコマンド内に指定されたバイト数を読み出した後は、3D Command Decodeは3D Command キューからのコマンド読み出しに戻る。
５．２．２．８  Write To Hostキュー
ホストへの書き込みキューは、２ＤがDMAを通じてホストに書き込むデータを含む。２Ｄは、システムメモリへのDMA転送を要求した後でホストキューをリングまたはBackendからのデータで満たす。この小さなバッファを持つことにより、DMAエンジンはデータを移動するＡＧＰの性能を最大限に引き出すことができる。
５．２．２．９  割り込みジェネレータ
ホストとＤＳＧＰボード間の通信の最も重要な部分は割り込みによって実行される。一般に割り込みは、まれに起こる現象、および通常の動作に対する例外を示すために使用される。ホストに対してレジスタの読み込みを許可し、生成する割り込みの原因となる割り込みの決定を許可する２つのCauseレジスタがボード上にある。Causeレジスタの内の一つは、リトレースのような専用割り込み用にリザーブされ、他はカーネルにより位置付けされる一般的割り込み用レジスタである。各レジスタ用に、ホストがレジスタにアクセスするために読み込む物理アドレスが２つある。最初のアドレスはポーリング用であり、Interrupt Cause レジスタ内のデータには影響しない。２つめのアドレスは割り込みのサービス用であり、読み込んだ割り込みを個別的にクリアする。次にホストは、オンの場合に読み込みが返却する割り込みの全てをサービスする役割を負う。各Interrupt Causeレジスタ用に、Cause内のビットが0 p 1変換をした場合に割り込みを発生させるか否かを決定するInterrupt Maskレジスタがある。
【０１８５】
ＤＳＧＰは６４個までの異なる割り込みの原因をサポートするが、その内の少数は固定であり、他の少数は一般的原因である。下表に各原因の簡潔な説明を示す。
５．２．２．９．１  リトレース
リトレース割り込みは、１秒間に約８５回から１２０回発生し、モニターの垂直空白期間内の所定のポイントにおいてBackendハードウェアにより立ち上がる。正確なタイミングは、Backend Input Bus上のレジスタの書き込み動作を通じてBackendユニット内へとプログラミングされる。
５．２．２．９．２  3D FIFO高水位
3D FIFO高水位割り込みは、パイプが性能モードで走行している場合はまれにしか起きないが、３Dパイプラインがより低い性能で走行している場合は頻繁に起こることがある。カーネルモードのドライバーは、3D Cmd Buffer内の許容エントリ数を示す3D High Water Entriesレジスタをプログラミングする。バッファ内にある以上のエントリがある場合は、高水位割り込みがトリガーされる。次にカーネルモードドライバーは、割り込みをフィールディングし、３Dバッファをオーバーフローさせないように書き込みを防止しなければならない。割り込みハンドラ内では、カーネルが高水位マークの下までパイプが一杯になっているかをチェックする。一杯になっていない場合には、カーネルは高水位割り込みを無効化し、低水位割り込みを有効化する。
５．２．２．９．３  3D FIFO低水位
3D FIFO低水位割り込みが有効化されると、3D FIFO内のエントリ数が 3D Low Water Entriesレジスタ内よりも少ない場合に割り込みが発生する。本割り込みは、3D FIFOが十分にクリアされているために安全であり、 プログラムによる3D FIFOへの再書き込みが可能であることをカーネルに信号にて知らせる。
【０１８６】
５．２．２．９．４  2D FIFO高水位
2D FIFOの監視をするという点を除いては、この割り込みは3D FIFO高水位割り込みと完全に一致している。2D FIFO高水位割り込みは、パイプが性能モードで走行している場合はまれにしか起きないが、２Dパイプラインがより低い性能で走行している場合は頻繁に起きることがある。カーネルモードドライバーは、2D Cmd Buffer内で許容されているエントリ数を示す 2D High Water Entriesレジスタをプログラミングする。バッファ内にここに示す以上のエントリがある場合は、高水位割り込みがトリガーされる。次にカーネルモードドライバーは、割り込みをフィールディングし、２Dバッファをオーバーフローさせないように書き込みを防止しなければならない。割り込みハンドラ内では、カーネルが高水位マークの下までパイプが一杯になっているかチェックする。一杯になっていない場合は、カーネルは高水位割り込みを無効化し、低水位割り込みを有効化する。
５．２．２．９．５  2D FIFO低水位
2D FIFO低水位割り込みが有効化されると、2D FIFO内のエントリ数が 2D Low Water Entriesレジスタ内のそれよりも少ない場合に割り込みが発生する。 本割り込みは、2D FIFOが十分にクリアされて安全であり、プログラムによる2D FIFOへの再書き込みが可能であることをカーネルに信号にて知らせる。
５．２．２．９．６  アクセス違反
存在しないレジスタに対して書き込みまたは読み出しが行われると本割り込みがトリガーされる。
５．２．２．９．７  Invalidコマンド
FIFO内にてゴミのコマンドが検索（可能ならば）された場合、またはユーザプログラムにより特権コマンドがFIFO内に書き込まれた場合にこの割り込みがトリガーされる。カーネルは本割り込みをフィールディングし、有害タスクを停止しなければならない。
５．２．２．９．８  テクスチャミス
本割り込みは、テクスチャユニットがテクスチャメモリにロードされていないテクスチャにアクセスを試みた場合に発生する。テクスチャユニットは、リングを通じてInterrupt Causeレジスタにテクスチャ書き込みを送信し、Texture Miss IDレジスタに対してリング書き込みと共に本書き込みを行う。カーネルは本割り込みをフィールディングし、どのテクスチャが失われているかを見極めるためにTexture Miss IDレジスタを読み出し、テクスチャDMAをセットアップしてテクスチャをダウンロード及びテクスチャTLBを更新し、その後本割り込みをクリアする。
【０１８７】
５．２．２．９．９  一般的割り込み
Interrupt Causeレジスタ内の他の割り込みは、一般的割り込みである。一般的割り込みは、その割り込み番号をオンにする割り込みジェネレータに対して完了時にメッセージを送信するコマンドを送信するソフトウェアによりトリガーされる。これら割り込みは、全て２Dまたは３Dパイプラインから来てBackendユニットの底部まで達する与えられたコマンドにより発生する。Backendは、専用線を通して Interrupt Cause レジスタ（同じチップ上に存在するために、リングの使用はオーバーキルとなる）に書き込みを送信する。
５．２    Geometry ブロック(GEO)
５．３．１  グラフィカルパイプラインポジション
GEOブロックは、グラフィカルパイプラインのフロントエンドにおける最初の演算ユニットである。本ブロックは、主に頂点座標及び法線の変形のような頂点ごとの動作に関係する。Frontend（例：AGI及びCFDブロック）は、Graphics Hardwareコマンドの取り出し及び復号化に関係する。Frontendは、必要な変形行列、マテリアル、ライトパラメータ、及び他のモード設定をGEOブロックの入力レジスタにロードする。GEOブロックは、変形された頂点座標、法線、生成された及び/または変形されたテクスチャ座標、及び頂点ごとのカラーをMode Extraction及びSortブロックに送信する。Mode Extractionは、「カラー」データ及びモードをPolygonメモリに保存する。Sortは、Tileによる頂点ごとの「空間」データを構成し、それをSortメモリに書き込む。
【０１８８】
５．３．２  動作モード
パイプラインは、その機能の、あるサブセットが使用されている場合のみ最大性能モードで動作する。このモードでは、GEOブロックは各プリミテフィブに対する全ての可能な動作のサブセットのみを遂行する。より多くの機能が有効な場合、一連のさらに低い性能モードを通じてパイプラインが動作する。Geometryエンジンは、非性能モード設定に対してより低い速度で原線を処理するために使用可能な演算要素を再使用する。下記の各節に各性能モードへの機能の配置を示す。
５．３．３  GEOブロックの機能概要
GEOブロックは、点、線、三角形、四辺形、および多角形などの形状寸法の原線を定義する頂点上で動作する。本ブロックは、座標変形及びGouraudシェーディング動作を各頂点あたりに行う。Primitive Assemblyフェーズ中においてのみ、本ブロックは頂点を線や三角形にグルーピングする（本ブロックは、プロセス中において四辺形や多角形を三角形のセットへと分解する）。本ブロックは、各原線に対して切り落とし及び表面タンジェントの生成を実行する。
【０１８９】
頂点座標変形
各頂点は、目標座標（Xo、Yo、Zo、Wo）のセットにより規定される。第４の座標を追加することにより、頂点を同次の座標で表すことが可能になる。同次システム内では、回転、拡大縮小、及び解釈を含む一連の変形を組み合わせてModel-View行列と呼ばれる単一の変形行列にすることができる。頂点目標座標は、４×４Model-View行列を掛けることにより頂点目視座標に変形することが可能である：
（Xe,Ye,Ze,We）T＝MMV＊（Xo,Yo,Zo,Wo）T
投影行列と呼ばれる他の行列が、クリップ座標を生じるために目視座標に適用される。標準デバイス座標を生じるために、透視画法分割がクリップ座標上で行われる。これらの座標をウィンドウ座標に変換するために、最終視点変形が適用される。
（Xc,Yc、Zc,Wc）T＝Mp*(Xe,Ye,Ze,We)T
（Xd,Yd,Zd)T＝（Xc,Yc,Zc,T/Wc）
(Xw，Yw，Zw)T=（Xd，Yd，Zd）T、（Sx，Sy，Sz）T+(Ox,Oy,Oz)T
フル性能モードでは、パイプラインは目視座標を保存する必要はない。従って、パイプラインは組み合わせ行列を使用して頂点目標座標をクリップ座標に変形する。
（Xc,Yc,Zc,Wc）T=MMVP*(Xo,Yo,Zo,Wo)T
図１９にDSGPによる頂点座標の変換をまとめる。
５．３．３．２  ノーマル、タンジェント、及びバイノーマル評価
空間座標に加えて、GEOブロックは、現ノーマル、現テクスチャ座標、及び各頂点に対する現カラーを持つことがある。ノーマルは、ライティング演算に影響する。現ノーマルは、３次元ベクトルである（Nxo,Nyo,Nzo）。テクスチャ座標によりテクスチャイメージの原線上の配置が決定される。
【０１９０】
GEOブロックは、目標座標内に表されるノーマルを受信する。本ブロックは、逆Model-View行列を使用してノーマルを目視座標に変形する。
（Nxe,Nye,Nze）T=MMVI*(Nxo,Nyo,Nzo)T
Mmvから取られた左端の３×３行列を逆転すると行列Mmviが形成される。GEOブロックは、ノーマルを変形し、その後それらをユニット長に再規格化する。
（Nxu,Nyu,Nzu）T=(Nxe,Nye、Nze)T*(1/SQRT(Nxe2+Nye2+Nze2))
突き当て配置の場合、ユーザが[表面]タンジェント及びバイノーマルの２つまでの追加的ベクトルを提供する場合がある。GEOブロックは、ノーマルを実行する時にこれらベクトルを変形し、再正規化する。これらベクトルがユーザによって供給されない場合は、本ブロックが生成することもできる。GEOブロックは、テクスチャ座標及び頂点目視座標を使用してタンジェント生成し、ノーマル及びタンジェントの交互積によりバイノーマルを生成する。
【０１９１】
GEOブロックは、突き当て配置に必要なタンジェント及びバイノーマルを半分の速度で生産する。
【０１９２】
図２０にDSGPによるノーマル、タンジェント、及びバイノーマルの変換をまとめる。図２１にGeometryブロック(GEO)の概要を示す。図２２は、本発明の構造の３チップ実施例内半導体チップ上の機能ブロック間の関係を示す概略図である。
５．３．３．３  頂点カラー
ライティングが無効化された場合、頂点カラーは現カラーにより決定される。ライティングが有効化された場合、GEOブロックは頂点ノーマル、ライティング及び素材パラメータを使用して頂点カラーを評価する。オプションとして、現カラーから素材カラーを派生させることも可能である。カラーは、R、G、B、及びAの４つの値または単一のカラーインデックス値として指定される。カラーは、GEOブロック内での使用に先立ってCFDにより浮動小数点番号に変換される。頂点ライティング評価の最後に、結果のカラーが、0.0から1.0の（これらの数値を含む）範囲を表す８ビット固定小数点へとクランプバックされる。
５．３．３．４  テクスチャ座標処理
テクスチャ座標は、ユーザによる提供に代わって、頂点座標またはノーマルを使用して生成することも可能である。オプションとして、変換行列をテクスチャ座標に適用することもできる。テクスチャ座標は、ｓ、ｔ、ｒ、及びｑという名の同次座標を使用して指定される。変換行列は、４×４行列である。性能のケースでは、結果のｑは１であり、ｒは無視され、ｓ及びｔはテクスチャマップへのアクセスに使用される。低下させた性能では、ｑが透視図スケーリング用にテクスチャ座標の分割に使用される。テクスチャ座標ｒは、３次元テクスチャ及び影に使用される。GEOブロック内では、８セットまでのテクスチャ座標がサポートされる。２つのテクスチャ座標が変換でき、半分の性能での変換が可能である。５つのテクスチャ座標がフル性能の３分の１にて取り扱える。最後に、８つのテクスチャ座標の全てが４分の１の性能で生成及び変換できる。
【０１９３】
クリッピング
GEOブロックは、頂点クリップ座標をクリップ平面により生成されたアウトコードと比較する。本ブロックは、これらアウトコードを使用して視点ボリュームの外にある原線をリジェクトする（例えば、原線内の全ての頂点が最上クリッピング平面の上にある場合、原線はリジェクトされる）。幾つかの原線は、たとえ完全に視点ボリュームの外にあったとしても、明らかにリジェクトすることはできない。アウトコードにより原線が完全に視点ボリュームの内側にあり、いかなるクリッピング平面にも交わっていないことを示している場合、この原線は受け付けられ、これ以上のクリッピング演算は必要なくなる。
【０１９４】
明らかに受け付けまたはリジェクトされない原線は、視点ボリュームに対してクリッピングされ、クリッピング平面と交わっているエッジをアウトコードが示しているクリッピング平面をユーザが定義する。原線の１つの頂点がクリッピングされると、GEOブロックは１つ以上の新しい頂点を生成しなければならない。GEOブロックは、これら新しい頂点に対して「カラー」データを書き入れをしない。これら頂点は、オリジナルの原線の頂点から「カラー」データを共用する。この処理は、最後のカラー頂点により指定された同じ三角形から生成されるクリッピングされた頂点に対して、Mode Extractで同じカラーポインタを割り付けることにより行われる。
【０１９５】
現頂点及び前回の頂点のウィンドウ座標を使用して多角形の表面方向が決定され、オプションとして裏面の選別も行う。
【０１９６】
ライティング
フルライティングモードでは、２つのライトに対してライティング動作が無限にローカルビューワー及びスポットライトなしで行われる。
【０１９７】
Gouraudシェ−ディングの場合、各頂点に対して２つのカラーセットが評価される。プライマリーカラーは、スポットライトにより減衰、強調されたカラーのAmbient、Emissive、及びDiffuseコンポーネントを含む。本カラーは、Red、Green、Blue、及びAlphaコンポーネント（RGBA）を持つ。全てのライト及び現素材設定はプライマリーカラーに資する。セカンダリーカラーは、頂点ライティングのSpecularコンポーネントに対応する。本カラーは、R、G、及びBコンポーネントを持つ。本カラーも距離により減衰され、スポットライト効果を包含する。個別のSpecularカラーモード設定がオンになっていない場合は、プライマリーカラーはSpecularコンポーネントも含み、セカンダリーカラーはクリアされる（R=0、G=0、B=0）。
【０１９８】
Fragmentブロックは、プライマリー及びセカンダリーカラーに個別にデータを挿入する。プライマリーカラーは、最終ピクセルカラー決定のための与えられたフラグメントに対するセカンダリーカラーの適用に先立ってテクスチャカラーと混合される。
【０１９９】
Phongシェ−ディングの場合、GEOブロックは何も余分な仕事をしない。DSGPパイプラインは、Phong及びGouraudシェ−ディングの双方を個別のライトのために同時にサポートする。この処理は、Gouraudを使用してライトの総数を大幅に増加させ、最大８つのPhongライトを使用するライティングの質も大幅に向上させる。Phongは、カラー素材用の「現」カラーとしてGEOブロックのプライマリー及びセカンダリーカラー出力を使用する。
５．４  Mode Extraction Block (MEX)
Mode Injection (MIJ)ブロックと連携したMode Extraction Block (MEX)は、グラフィックス状態に関連する情報を管理する役割を負う。従来のグラフィックスパイプライン内では、状態変化は増加傾向にある。すなわち、状態パラメータの値は変化するまで効果を保ち続ける。従って、アプリケーションは変化したパラメータを更新するだけでよい。さらに、描画はリニア的である。すなわち、原線は受信したオーダー中に描画される。点、線、三角形の細片、三角形の扇形、多角形、四角形及び四辺形の細片はグラフィック原線の例である。これにより、原線用の空間情報を受信するまでは状態変化は蓄積され、上記原線の描画中はこれら蓄積された状態は有効である。
【０２００】
DSGPパイプライン中では、隠れた表面が取り除かれるまで描画が続けられる。Geometry（GEO）ブロックは、正しい順序で原線を受信し、全ての頂点動作を行い(変形、頂点ライティング、クリッピング、及び原線組み立て)、パイプラインを通してデータを送信する。Sortブロックは、時間指定データを受信し、そのデータが接触するタイルにより貯蔵する。(各タイル内部のリストはタイムオーダーになっている。)CULブロックは、SRTブロックからタイル順にデータを受信し、描画された画像には絶対に寄与することのない原線のパーツを選別する。CULブロックは、VSPを生成する。VSPは、スタンプ上の多角形の可視部分に対応する。TEX及びPHGユニットは、VSPを受信し、それぞれフラグメントのテクスチャリング及びライティングの役割を負う。Pixelブロックなどの最後のブロックは、最終的な絵を生成するためにVSP及びフラグメントのカラーを消費する。
【０２０１】
原線は、多くのタイルに接触するため、従来の描画パイプラインと違い、フレーム描画の最中にしばしば問い合せられる（原線がタイルに接触するたびに）。パイプラインは、原線がパイプラインを入力した時に有効なグラフィックス状態を記憶し、SRTから下りてくるパイプラインステージの訪問を受けるたびに想起しなければならない。MEXは、GeometryとSortブロック間に位置し、暫定的に順序付けられた状態変化データを収集及び保存する論理ブロックであり、原線が描画された時に、その原線と正しい状態を対応付けるために原線頂点に適切なポインタを付け加える。Mode Injection（MIJ）ブロックは、必要に応じて、状態及び状態ポインタ（本書中ではMLMポインタと総称されている）を持つ必要な他の情報を検索する役割を負う。本ブロックは、適宜情報を再パッケージングする役割も負っている。再パッケージングは、例えば多角形メモリ内の頂点データが検索され、フラグメント用の三角形入力パケットにまとめられた時に発生する。
【０２０２】
我々は、最初に操作理論及びDSGP状態管理の背景にある一般原則について論じる。その後我々は、MEXブロック及びMEXブロックへのインタフェースについて論じる。我々は、種々の状態ポインタを伴うデータが如何にしてRDRAM内で編成されるかを説明する。我々は、MEXが必要とする再パッケージング及び処理の全てについて論じる。MEX入力及び出力パケットの計数及びメモリサイズ、帯域幅解析などの簡潔な論説が後に続く。
５．４．１  状態管理
グラフィックス状態は描画された原線の出現に影響する。DSGPパイプラインの個別のパーツはそれぞれ異なる状態情報を使用する。ここでは、我々はGEOブロックからのパイプラインステージの下流のみについて述べている。DSGPは、グラフィックス状態を、上記状態情報がどのように種々のパイプラインステージによって使用されるかに基づき、幾つかのカテゴリーへと分ける。状態の適切な分割は非常に重要である。この分割には、性能に対する影響（帯域幅やアクセスの制限により）、チップサイズに対する影響（より大きなキャッシュ及び/または論理の複雑化）及びピンカウントに対する影響がある。
５．４．１．１  モード抽出ブロック機能
MEXブロックは、下記の処理に対する役割を負う。
１．  Geometryからのデータパケットの受信。
２．  それらデータパケット上に必要な全ての処理の実行。
３．  パイプラインのシェ−ディング部分に必要な情報のPolygonメモリへのセーブ(後のMIJによる検索用)。
４．  Sortユニットに送信される原線に対して状態ポインタを付け加えることによりMIJをして同原線の状態を知らしめる。
５．  Sort、Setup、及びCullが必要とする情報のSortブロックへの送信。
６．  多角形及びソートメモリオーバーフローの扱い。
【０２０３】
図２３にMEXデータフローの他のViewを示す。
【０２０４】
Polygonメモリにセーブされた状態は、Fragment、Texture、Phong、及びPixelブロックなどのMIJからのブロックの下流で使用されるものである。この状態は、本書の他の個所に説明されているように分割される。
５．４．１．２  モードインジェクションブロック
MIJは下記の処理に対する役割を負う。
１．  BeginFrame、EndFrame、及びBeginTileなどの種々の制御パケットのFragment及びPixelユニットへのルーティング。
２．  CULブロックから受信した各VSPに対する状態付加。
３．  多角形メモリからからのパケットの検索。
４．  原線の構築。多角形メモリは頂点あたりのデータを保存する。VSPの原線の種別によって、MIJは、多角形メモリから必要な頂点（三角形用に３つ、線用に２つ、及びポイント原線用に１つ）を検索する。
５．  Color、TexA、TexB、Light、Material、PixelMode、及びStippleキャッシュの内容トラックの維持及び各キャッシュミスデータパケットに対する適切なキャッシュポインタの付加。
６．  フラグメント及びピクセルブロックに対するデータ送信。
７．  パイプライン内の処理中断。
【０２０５】
モードインジェクションは、このようにして状態検索及びVSP内の各フラグメント用の最終カラーの演算に必要な頂点あたりのデータに関与する。
５．４．１．３  グラフィックス状態分割
DSGPは、グラフィックス状態を複数のパーツに分割する。それらパーツの数をこれより７つと想定する。これらパーツは、各原線に対して保存される頂点あたりの情報の付加的な情報である。本節は、状態情報の概要を説明する。
５．４．１．３．１  Sort、Setup、及びCullが必要とする状態及び空間データ
本情報は、Sort、Setup、及びCullブロックが必要とする状態情報である。本情報はPolygonメモリにはセーブされない。本情報は、CullModesパケット、VertexModesパケット、及びSpatialパケットの３つのパケットとして受信される。これらパケットは、SRTブロックに対して予定され、Geometryユニットから送信されてくる。選別パケット内の情報には、CULブロックが必要とする目的線画バッファ及び制御ビットが含まれる。
【０２０６】
VertexModesパケットには、Sortブロックに送信される前回の各空間パケットにMEXにより付加されるホストコンピュータが生成するモード情報（例：ソフトウェア）が含まれる。VertexModesパケットには、線幅、点サイズ、線点描情報、及び深度テスト動作制御ビットが含まれる。
【０２０７】
Spatialパケットは、頂点のウィンドウ座標及び原線用の点描パターンなどの他のGeometryブロックにより生成された頂点あたりの情報を含む。Spatialパケットは、頂点のウィンドウ座標、多角形の曲がり、多角形の扇形及び細片内の頂点再使用、エッジフラグ、及び混合動作制御ビット（アルファテストおよびアルファ混合など）を含む。頂点モードはソフトウェアにより生成される。
【０２０８】
Geometryブロックは、ソフトウェアより選別モード及び頂点モードを受信する。本ブロックは、上記のように選別及び頂点モードをMEXに送信する。MEXは、頂点モードを空間パケットに付加することによりソート用の空間パケットを構築する。MEXブロックはまた、状態MLMポインタをSortブロック上に渡す前に本パケットに付加する。さらに、原線は同時に点と線にはなれないために、MEXブロックは線幅及び点幅パラメータを一つのパラメータに構成しなおす。本ブロックは、Sort原線タイプを使用して原線が点か線か多角形かを決定する。原線が点の場合、本ブロックはSortに点幅を送信し、他の場合は線幅を送信する。他のフィールドはそのままである。
５．４．１．３．２  テクスチャパラメータ
テクスチャリングには、特に複数のテクスチャが含まれる場合は、多数のパラメータがあるため、多数のテクスチャパケットを持つ方が有利である。これより、２つのテクスチャパケット（TexA及びTexBと呼ばれる）があるものとするが、これらは追加パケットに分割可能とする。テクスチャパラメータパケットは、テクセルの検索及びフィルタリングに必要な情報を含む。本書は、８つの使用可能なテクスチャが各頂点に割り付けられているものと仮定している。TexAパラメータパケットは、最初の２つのテクスチャ用のパラメータを含み、TexBパラメータパケットは、６つまでの追加テクスチャ用に同様の情報（テクスチャあたりの）を含む。この非対称パーティションが選択されるのは、ほとんどの場合、同時に活性なテクスチャは１つか２つだけだからである。まれなケースでは、２つより多いテクスチャが使用されることもある。本処理は、チップ上のテクスチャパラメータキャッシュのサイズを維持するのに役立つ。TexA及びTexBパケットは、Geometryユニットから受信する。テクスチャあたりの情報は、テクスチャID,テクスチャ次元数(例：１D、２D、３D)、テクスチャサイズ(例：幅、高さ、及び奥行き)、テクスチャボーダー情報、テクスチャフォーマット、テクスチャフィルター制御ビット、テクスチャラッピング制御ビット、テクスチャクランピング制御ビット、詳細制御ビットのレベル、及びテクスチャ比較動作制御ビットを含む。
【０２０９】
再び、TexAパケットは、これらエントリの内の１つか２つを含み、TexBパケットは、６つまでのエントリを持つことができる。TexA及びTexBパケットはソフトウェアにより生成され、GEOブロックを通じてMEXに送信される。MEXは、TexA及びTexBを２つの状態パーティションとして管理し、Polygonメモリにセーブする。各TexA及びTexB状態パーティションは、それ自体に付加されるポインタを持つ。Mode Injectionブロックは、後に必要となるこれらのパケットを検索する。Geometryブロックは、本情報を全く使用しない。
【０２１０】
テクスチャID、その（ｓ、ｔ、ｒ）座標、及びミップマップレベルが与えられると、Textureブロックは、テクセルの検索、必要に応じたテクセルデータのアンパッキング及びフィルタリングの役割を負う。Fragmentブロックは、テクスチャモード情報同様にテクスチャID、ｓ、ｔ、ｒ、及びミップレベルをTextureブロックに送信する。Fragmentからのｓ、ｔ、ｒ、及びミップレベルが浮動小数点値であることに注意する。各テクスチャ用には、TEXブロックがPHGに１つの３６ビットテクセル値を出力する。テクスチャブロックは、フラグメントとテクスチャカラーとを結合しない。これはPhongブロックにおいて行われる。テクスチャブロックは、テクスチャパラメータ及びテクスチャ座標を必要とする。テクスチャパラメータは、Textureブロック内の２つのテクスチャパラメータキャッシュから得られる。Fragmentブロックは、ミップレベル演算でテクスチャ幅及び高さパラメータを使用する。Fragmentは、TextureDimensionフィールドを使用してテクスチャ次元が有効か（０はテクスチャが無効であることを示す）及びTexCoordSetを使用して座標セットを付加可能かを決定する。
５．４．１．３．３．  ライティングパラメータ
状態の「ライティング」パーティションは、フォグパラメータなどのフラグメントのライティングに影響を与える大域状態同様にフラグメントライティングの演算に使用される複数のライト（これより、本書では最大８つのライトを想定する）を含む。ライトキャッシュパケットは、次のライトあたりの情報を含む。ライトタイプ、減衰定数、スポットライトパラメータ、ライト位置情報、及びライトカラー情報（周辺、拡散、及び反射カラーを含む）。ライトキャッシュパケットは、次の大域ライティング情報も含む、すなわち大域周辺ライティング、フォグパラメータ、及び使用ライト数である。
【０２１１】
ライトキャッシュエントリは約３００バイトである（大域ライトモードの８つの内の各ライトプラス１２０ビット用の約３００ビット）。LightCacheパケットは、ソフトウェアにより生成され、GEOブロックを通じてMEXに送信される。MEXは、LightCacheパケットを状態パーティションの一つとして管理し、必要ならばPolygonメモリにセーブする。LightCache状態パーティションはそれ自体に付加されるポインタを持っている。Mode Injectionブロックは、後に必要となるために、上記パケットを多角形メモリから検索する。Geometryブロックは本情報は全く使用しない。
【０２１２】
ライティング状態のキャッシングの代替法として、ライティング状態全体をキャッシングする代わりにライトごとのキャッシュエントリが使用できる。本処理により、ライトパラメータキャッシュミスがある場合にパイプラインを通じて送信されるデータの量を減らすことができる。このように、単一のライトを変更する場合に、応用プログラムがライティングパラメータの「軽量」スイッチングを提供する。しかしながら、本処理は、ライティング状態の管理をより複雑にすることになる。
５．４．１．３．４  フラグメント素材パラメータ
グラフィックス状態の素材パーティションは、フラグメントライティング演算に関連する全ての情報を含む。フラグメント素材状態は原線の頂点に付加されている素材状態とは異なることに注意する。フラグメント素材状態情報は、GEOブロック内で実行される頂点ライティング演算中には使用されない。本パケットは、テクスチャ有効化制御ビット（活性テクスチャの選択）、テクスチャ環境パラメータ、素材カラーパラメータ（放出、周辺、拡散、反射カラー、および輝度）、輝度カットオフ値、およびカラー素材パラメータを含む。
【０２１３】
８つのテクスチャが存在可能なので、各フラグメント用に８つまでのテクセルがTEXからPHGに受信可能である。テクセルは、素材状態パケット内のテクスチャエントリと同様の順序で受信される。
５．４．１．３．５  ピクセルモード
ピクセルモードは、PIXブロック内のフラグメントごとの動作に影響する。ソフトウェアはピクセルモードパケットを作成し、作成されたパケットはGEOを通じてMEXに送信される。MEXは、Polygonメモリに本パケットをセーブする。MIJは本パケットを検索し、PIXブロックに送信する。ピクセルモードは、フレームバッファ書き込みマスク（深度、カラー、及びステンシルマスク）、混合操作、深度関数、ステンシル関数、及びはさみ動作などの情報を含む。
【０２１４】
本パケット内の幾つかの情報は、SRT用に準備されたVertexModes内に含まれる情報と同様であることに注意する。ソフトウェアは、種々のモードパケット内で必要となる状態情報の二重化の役割を負う。
５．４．１．３．６  点描
点描パケットは、多角形点描パターンを指定する。点描パターンは、あまり頻繁には使用されず、使用される場合にも頻繁には変更されないため、分割してキャッシングした方が効率的である。本パケットは多数のバイトにより構成されている（３２×３２ビットパターンに必要なため、１２８バイトが普通である）ため、他のパラメータキャッシュに入れると、それに伴うパケットに大きな追加オーバーヘッドを加えることになる。
５．４．１．３．７  Fragument-Texture-Phongブロック用の頂点ごとのデータ
各VSPでは、Fragmentブロックが供給された頂点ごとのデータを改ざんし、Fragmentブロックからのブロック下流に必要な情報を生成する。改ざんされたパラメータは、VSPに付加された状態ポインタによっては、使用可能なパラメータの内の幾つかまたは全てで構成されることがある。パラメータ数の変動を考慮して、Polygonメモリに保存されているパケットサイズは、特定の頂点に対して使用されるパラメータの数及びタイプにより可変である。これらパラメータは、原線タイプ、多角形扇形及び細片構築のための頂点再使用、非クリッピング頂点ｘ、ｙ、及び１/ｗ値、頂点目視座標（Xeye、Yeye、Zeye）、逆透視項、頂点プライマリ及びセカンダリカラー、頂点ノーマルベクトル、タンジェントベクトル、バイノーマルベクトル、および8セットまでのテクスチャ座標を含む。ノーマル、タンジェント、及びバイノーマルベクトルは、それぞれ単一ベクトルまたはユニットベクトル（例：ベクトルの方向）及び対応する大きさとして表すことができる。
【０２１５】
非クリッピング頂点ｘ、ｙ、及び１/ｗ値は、改ざんされた原線パラメータ（カラー、ノーマル、テクスチャ座標など）が原線のオリジナルの頂点パラメータから生成できるために、原線が表示画面にクリッピングされている場合でも、特別に有用である。これにより、原線がクリッピングされていると、全ての原線を画面上にとどめておくために新たな頂点が作成される。本処理は通常、高価な動作セットであるこれらの新たな（表示画面端に沿った）頂点位置において頂点パラメータの改ざんを必要とする。これらクリッピングされ、生成された頂点におけるパラメータの改ざんは、Sortメモリにクリッピング値（例：ｘ、ｙ、及びｚ値）を保存し、Polygonメモリに非クリッピング頂点パラメータを保存することによって防ぐことができる。このようにして、Sortメモリ内の原線とPolygonメモリ内の原線間の対応が多数対１になる。本処理は、Polygonメモリ内の演算及び保存スペースの双方を節約する。
【０２１６】
ノーマル、タンジェント、及びバイノーマルベクトルを方向及び大きさに分けることは、方向に対する改ざんが大きさから離れて平易にできるようになる。大きさとは別の方向に対する改ざんは、特に大きな係数によりオリジナルのベクトル（例：頂点におけるベクトル）の大きさが変化する場合に、より正しい角度の改ざんを提供する。
【０２１７】
Geoブロックは、多角形メモリに保存する頂点ごとの情報を生成する。MIJブロックは、VSPを含む原線を再構築するのに必要なデータ及び頂点を多角形メモリから検索する役割を負う。
【０２１８】
三角形頂点テクスチャ座標は、テクスチャユニットではなく、フラグメントユニットに送信されることに注意する。テクスチャユニットは、各フラグメントに対して改ざんされ、透視図が修正されたテクスチャ座標をフラグメントブロックから受信する。
５．４．２  MEXブロックの機能詳細
５．４．２．１  MEXブロックの機能概要
MEXの完遂に必要なこと及びその方法を理解するために、図２４に示す例を考える。
【０２１９】
MEXはGEOから一連のパケットを順番に受信する。各原線の場合、MEXは最初に関連状態パケットを受信し、その後形状寸法パケットを受信する。（カラー頂点情報をソート頂点情報の前に受信する。）ソート頂点データは、クリッピングされたウィンドウ座標などの原線のソート及び選別に必要な情報で構成される。VtxModeパケットは、深度テストに関する情報等を含む。CullMode、VtxMode、及びソート頂点パケット内の情報がパイプラインのSort-Setup-Cullパートに送信される。「カラー」頂点データは、頂点目視座標、頂点ノーマル、テクスチャノーマル等の原線フラグメントのライティング及びテクスチャリングに必要な情報を含み、後で検索できるように多角形メモリにセーブされる。
【０２２０】
パイプラインのSort-Setup-Cullパートは、原線をVSPに変換する。これらVSPは次に、パイプラインのFragment-Texture-Phongパートによりテクスチャリング及びライティングされる。ほとんどの場合、これらVSPは、タイル上のVSPスキャンオーダーにあり、例えば異なる原線用のVSPがインタリーブされることがある。明確には、パイプラインのFragment-Texture-Phongパートは、特定のVSPがどの原線に所属しているか及びその原線が最初に導入されたときのグラフィックスの状態の双方を知る必要がある。MEXは、「カラーポインタ」を各Sort Vertex（後に本原線内の各VSP上に渡される）に付加する。MIJは、ポインタを復号化し、Polygonメモリから必要な情報を検索する。
【０２２１】
このように、MEXは最後の状態セーブ以後に起きた状態変化を蓄積する。状態変化は、頂点が来るとすぐに有効になる。MEXは、チップ上に状態ベクトルを保持する。本状態ベクトルは、図２５に示す通り１０個のパーティションを持つ。MEXは、状態ベクトルを保存するためにチップ上のメモリに１１７０バイト近くを必要とする。
【０２２２】
VertexModesは、MEX内のレジスタに保持され、パイプラインのSort-Setup-Cullパート上に渡される頂点に付加される。CullModesは、Mex2SrtCullModePkt同様にSortに送信される。MEXは、状態ベクトル内の各パーティション用にダーティビット及びポインタを（多角形メモリに）保持する。このように、選別モードは多角形メモリにセーブされず、それゆえポインタを必要としないために、１０個のダーティビットと９個のモードポインタがある。MEXがGeoブロックから状態パーティションに対応する入力パケットを受信するたびに、状態ベクトル内の上記パーティションを更新する。MEXは上記パーティションに対応するダーティビットも設定する。MEXがカラー頂点を受信すると、最後に状態がセーブされた時からその状態のいずれの部分が更新されているかを見るためにダーティビットを検査する。更新され、現原線のレンダリングに関連する状態パーティションは全て多角形メモリにセーブされ、そのポインタが更新される。それらパーティションのダーティビットもクリアされる。ダーティビットは、多角形メモリにセーブされた原線に対してのみクリアされることに注意する。TextureA、TextureB、及びMaterialのいずれが多角形メモリにセーブされるかは原線の「表面」およびダーティビットにかかっている。図２６に本理論の概要が図解されている。
【０２２３】
MEXは、適用可能なTextureA、TextureB、Material、Light、Stipple、及びPixelModeが最後にセーブされた場所へのポインタを含むMLMポインタと呼ばれる複合カラーポインタを構築する。本ポインタは、Sortブロック上に渡される頂点に付加される。
【０２２４】
Clearパケットも同様に渡されることに注目する。クリアパケットを受信すると、MEXはSendToPixelフラグを検査する。SendToPixelフラグが設定されると、MEXはPixelModesが汚れているかを確認する。ダーティPixelModeビットが設定されると、MEXは、PixModesを多角形メモリにセーブし、PixModePtrを更新し、ダーティPixModeビットをクリアし、新たなMLMポインタを作成し、本ポインタをクリアパケットに付加した後にSortブロック上に渡す。
５．４．２．２  入力パケット処理
Geometryブロックからの各入力パケット用のMode Extractionブロック内の処置を図に示す。本発明者らは、「メッシュ」という語を状態内の変化に続く点の連続を示すのに使用している。「メッシュ」は、上記のように点、線の細片、線の区分、または三角形のリストまたは扇形である。
多角形メモリ管理
多角形メモリは、二重八進数の直線行列として見られる。原線データは、メモリの山の最上部から満たされ、モードデータは最下部から満たされる。本メモリへの全ての書き込みは１４４ビットワード（または１つの二重八進数）である。図２４に示す例の場合、多角形メモリのレイアウトは図２７に幾分類似している。
【０２２５】
注意すべき点を下記に示す。
１．状態ベクトルのパーティションは、多角形メモリにゆっくりとセーブされる。我々は、必要としているものだけをセーブする。
２．状態ベクトルには省略時のリセットはない。全ての状態が適切に初期化されているかは、ドライバ／ソフトウェアの役割である。
３．メッシュ内の全ての頂点は同じサイズである。
４．カラーオフセットは８ビットであり、それゆえメッシュ内の最大頂点数は２５６である。
５．MEXは、原線を完成するために必要な現VertexPointer、VertexCount及び（最大で）２つの前回の頂点を保持する。MEXはmodePointerも保持する。
【０２２６】
VertexPointerは、多角形メモリ内の現頂点エントリに対するポインタである。VertexCountは、最後の状態変化から多角形メモリにセーブされた頂点の数である。VertexCountは、ColorOffsetに割り付けられる。VertexPointerはSort原線用のcolorPointerに割り付けられる。前回の頂点は、メモリオーバーフローの処理で使用される。MIJは、colorPointer、ColorOffset、及び頂点サイズ情報（Geoから受信したColorType内に暗号化されている）を使用して、多角形メモリからMLMポインタ及び原線頂点を検索する。
５．４．２．３．１  メモリ二重バッファリング及びオーバーフロー
Polygonメモリは、まれにオーバーフローすることがある。単一のユーザフレームが過度な情報を持つとPolygonメモリ及び/またはSortメモリがオーバーフローする。オーバーフロー点は、Polygonメモリのサイズ、フレーム内のマテリアル、モード、テクスチャ、及びライト変化の頻度、及び使用されている原線の特徴による。メモリが一杯になると、全ての原線がパイプへと洗い流され、これとは別にPolygonメモリバッファが一杯になるとユーザフレームが終わる。Sortメモリのオーバーフローは、同じオーバーフローメカニズムのトリガーとなることに注意する。PolygonメモリとSortメモリバッファは常に一致していなければならない。１つのメモリ内のオーバーフローに起因する他のメモリ内のスキッドはバックアウトされなければならない(または、回避する方が良い)。このようにして、MEX内では、オーバーフローに起因するフレーム破壊は、Sortからの信号またはMEX自身の中のメモリオーバーフローに起因するSortメモリのオーバーフローに繋がることがある。MEX内のSortメモリオーバーフロー信号はMEX多角形メモリ自身のオーバーフロー同様に処理される。
【０２２７】
多角形メモリのオーバーフローは非常に高くつくということに注意する。多角形メモリは、Sortメモリ同様に二重バッファとなっている。そのため、MIJがバッファから読み出しを実行している間にMEXが他のバッファへ書き込みを行う。この状況は、MEXがMIJによるフレーム処理の終了を待ってから次の（第三の）フレームに移らなければならないために、フレーム処理の遅延をもたらす。MEX及びSRTが的確に同期されていることに注意する。しかしながら、MIJがMEXによる処理済みのフレームの読み込みを開始できるようにするには、Cullはタイルのデータに相当する部分を処理済みでなければならない。このように、各フレームに対して上記遅延または中断が起きる可能性がある。メモリオーバーフローが起きれば、状況はさらに悪くなることがある。典型的なオーバーフローの状況下では、第一のフレームが多くのデータを持っており、第二のフレームはほんの少しのデータを持っている可能性がある。MEXが次のフレームの順次処理を開始できるようになるまでに要する時間は、MEXがフレーム全体に対して費やした時間＋CULタイル潜伏＋フレーム全体に対するMIJフレーム処理であり、MEXがフレーム全体に対して費やした時間＋MEXがオーバーフローフレームに対して費やした時間ではない。ここで要する時間は正常フレームに対して必要な時間のほぼ倍であることに注意する。このソフトウェアに対するコストを低下する唯一の手段は、シーンのサイズを見積もり、フレームを２つの等しい複合フレームに大別することである。これとは別に、ハードウェアは我々が必要としている場合のみオーバーフローを作成するようなポリシーを利用することもできる。
【０２２８】
Mode Extractionは、次のバッファ内のオーバーフローの原因となった三角形（及びその状態）を保存する必要がある。我々が頂点リストのどこにいるかにより、現バッファにすでに書き込まれている次のバッファに対して頂点の送信が必要な場合がある。本処理は、頂点を読み戻すまたはMEX内に２つほどの頂点を保持することにより可能である。線は前回の頂点を一つだけ必要とし、点は他の頂点とは一切ペアリングされないことに注意する。DoColorVertexコードがこの要件で考慮されている。オーバーフローも処理される。処理が終わると、MIJがMEXに信号を送信する。SetupおよびCullは、MEX及びSortが終了した後でなければタイル上の原線の処理が開始できないため、MIJはVSPの到着を待ち続けていることがある。
５．４．２．４  カラーポインタ生成
MEXは、「colorPointer」、「colorOffset」、及び「colorType」を、Sortに送信される全ての原線頂点に付加する。「colorPonter」は、Polygonメモリ内の頂点エントリをポイントする。本頂点エントリは、Sort原線が付加される三角形を完成する頂点（線または点）である。上記の例では（図２７参照）ソート頂点Va、Vb、V2は全て頂点３Vが△V1VaVb及び△V1V3V2を伴うD1V2V3Vを完了した時にカラーベクトルV3に応するカラーポインタを割り付けた。△V1V2V3のノーマル、カラー、及びテクスチャ座標などの頂点パラメータは、△V1VaVb及び△V1VbV2に対して生成されたVSP内のフラグメントのライティング及びテクスチャリングに使用される。
【０２２９】
「colorOffset」は、本原線に適用可能なMLMポインタの保存に使用される二重八進数に対するcolorPointerにおける頂点を分ける頂点の数である。再び上記の例に戻ると、Va、Vb、及びV2に伴うカラーオフセットは、st0及びcv３を分ける頂点の数、例えば３である。ColorOffsetは、Light、TexA、TexB、Material、PixMode、及び点描ポインタを検索するために復号化されるMLMポインタ（MLMPointer＝colorPointer―colorOffset*vertexSize-1）を検索したMIJを助ける。本処理はPolygonメモリ内のメッシュ内頂点数を２５６に制限することに注意する。（colorOffsetは、符号なし８ビット整数であり、それゆえ0から２５５の値を取る。ColorPointer上の最後の頂点を加えると、最大２５６頂点が得られる。）
「colorType」は、MIJに対し、いかにしてPolygonから完全な原線を検索するかを伝える。頂点は順番に保存されるため、三角形の扇形のケースをのぞいては、原線内の頂点は隣接している。点の場合、我々が必要なのは、colorPointerによってポイントされる頂点だけである。線の場合、我々が必要なのは、ColorPointerによってポイントされる頂点及びカラー頂点列内の前記頂点の前に位置する頂点である。三角形の細片の場合、我々が必要とするのは、colorPointer上の頂点及び２つの前回の頂点である。三角形の扇形の場合、我々が必要なのは、colorPointer上の頂点、その前に位置する頂点、及びMLMポインタの後の列の中の最初の頂点である。上記の例では、頂点V８に対してMIJが定義したソート原線は頂点V5、V7、及びV8を検索する必要がある。このように、三角形の扇形の場合は、三角形用の３つの頂点がColorPointer（ColorPointer-1）及び（ColorPointer-ColorOffset）上にある。
【０２３０】
図２８に「カラー」情報に使用されるビットを示す。
Color Typeフィールドは、入力パケットフィーダー内の「vertexType」及び頂点パケット長から構築される。本フィールドは、パケットのサイズ及びそれに属する原線のタイプを指定する。図２９にカラータイプフィールド用の値の一覧を示す。
【０２３１】
図３０に、点リスト、細片、三角形の細片、または三角形の扇形の最初の二重八進数内に保存されているMLMポインタパケットを示す。
５．４．２．５  状態の処理
概して、MEXは受信したパケットのほとんどの内容を知る必要はない。MEXが知る必要があるのは、それらパケットのタイプ及びサイズだけである。本規則には幾つかの例外がある。
【０２３２】
「カラー」頂点パケットの場合、MEXは現頂点により定義された原線に関する情報を知る必要がある。特に、MEXはそのタイプ(点、線、三角形の細片または扇形)及び三角形の場合は正面を向いているかを知る必要がある。本情報は、オーバーフローのケースにおいて原線の構築を可能にするためにチップ上に適切な頂点エントリをセーブする時に使用される。本情報は、Geometryブロックによりパケットヘッダーにしまわれる。
【０２３３】
MEXは、三角形の正面及び裏面用にMaterial及びTextureデータを蓄積する。Polygonメモリには、「FrontFace」ビットに基づいて状態の1セットのみが書き込まれる。三角形の細片または扇形内でも正面／裏面の向きは変わらないことに注意する。「FrontFace」は、正しいTextureA、TextureBパラメータ及び素材オブジェクトの原線に対する付加に使用される。メッシュが向きを途中で変更した場合、GEOは当該メッシュを複数のメッシュに分け、各メッシュが正面または裏面を向くようにする。
【０２３４】
CullModesの場合も同様に、原線のタイプによってはMEXはLineWidth及びPointWidth属性の内の一つを奪い去る。頂点が点を定義するとLineWidthが捨てられる。頂点が線を定義すると、PointWidthが捨てられる。MEXは、線または点の幅の内１つだけをSortユニットに渡す。
【０２３５】
「Clear」パケットの場合、MEXはSendToPixelフラグが設定されているかを検査する。フラグが設定されている場合、MEXは（必要ならば）PixelModeをセーブし、出力クリアパケットに付加する適切なColorPointerを作成する。
５．５  Sortブロック（SRT）
５．５．１  ＳＲＴブロックの機能概要
Sortブロックは、Mode Extraction（MEX）とSetup（STP）間のパイプライン中に位置する。Sortブロックの主な機能は、表示画面上に散在する形状寸法を取り、タイルにソートすることである。Sortブロックは、少量のモード情報と共にラスタ図形処理される前のシーン全体の形状寸法を保存するSortメモリを管理する。Sortメモリは、頂点及びモードの二重バッファリングされたリストである。１つのページは、パイプラインの残りの部分でシーンのジオメトリを収集する(原線ごと及びモードごとに)が、他のページは、そのジオメトリを送信する(原線ごと及びモードごとに)。
【０２３６】
「アーキテクチュアの概要」の章に記述されているように、ウィンドウ（画面上の表示領域）はタイルのセットへと縦横に分割され、Sortは各タイルに対してオーダーされたリストを保持する。Sortメモリのページが書き込み中の場合、頂点及びモードは、Sortブロックから受信されるごとに順にSortメモリに書き込まれる。Sortメモリのページ読み出しは、タイルごとに行われる。読み出しプロセスは次の２つのモードで動作する。１）Time Orderモード及び２）Sorted Transparencyモードである。Time Orderモードの場合、頂点及びモードのタイムオーダーは各タイル内に保存される。すなわち、与えられたタイルに対しては、頂点及びモードは書き込まれた時と同じ順序で読み出される。Sorted Transparencyモードでは、各タイルの読み出しは、複数のパスに分割される。最初のパスでは保証された不透明なジオメトリがSort Bloskから出力され、後続のパスにおいてはSortブロックから潜在的に透過なジオメトリが出力される。各パス内では、タイムオーダリングは保存され、モードデータはその正確なタイムオーダー場所に挿入される。
【０２３７】
Sortブロックへの入力時には、フレームの開始はMEX Output Begin Frame Packetの受信によって指定され、常にユーザフレームの開始に対応する(つまり、この時、新しい絵を描くためにアプリケーションがスタートする)。これらの開始フレームパケットは、Sort Memory Pagesがスワップされた時にSortからパイプラインを通ってSetupに送信される。フレームの終わりは、MEX Output End Frame Packetの受信により指定されるが、メモリオーバーフローが起きず、ソフトウェアがユーザフレームに分割を強制しなかった場合にはユーザフレームの終わりに対応するだけである。SortメモリまたはPolygonメモリが一杯になるとメモリオーバーフローが起きる。従って、Sortブロックに来るエンドフレームパケットには次の２種類がある。１）ユーザフレームの終わり、及び２）パイプライン内でユーザフレームを複数のフレームに分割する必要に起因するフレームの終わりである。ユーザフレームが複数フレームに分割された場合、パイプラインの後の半分（Setup及びbeyond）がタイルを複数回処理するように依頼される。各フレームは独立で、異なるコンテクストから入力可能なため、全てのパイプライン状態情報はSortメモリ（モードパケットとして）またはPolygonメモリにフレームごとに保存されなければならない。
【０２３８】
フレーム内では、Sortブロックは、点、線、及び三角形のSort原線を受信及び出力する。Sort原線三角形は、塗りつぶされた三角形または線モード三角形となる。しかしながら、原線は、点、線、塗りつぶされた三角形、及び三角形のエッジの線を含むCull原線に従って分類される。
【０２３９】
Sort原線及びCull原線の主な違いは、線モードの三角形のエッジは、別々の原線と想定されることである。Sortブロックが線モード原線を受信した場合、受信した原線は、そのエッジが触れているタイルに従って分類される。三角形のいずれのエッジ（LineFlag TRUEを持つ）も、三角形全体のそのエッジが接触するタイルへの分類の原因となるが、同じタイル内の複数のエッジを持つ三角形は、各タイルにつき１つのPointer Entryの原因となるだけである。本処理は、例えば、大きな線モードの三角形がそのエッジをタイルに触れさせることなく幾つかのタイルを囲んでいる場合、それらタイルの中で上記三角形に対するCull原線の読み出しは一切ないために、タイルあたりの原線の数を減少させる。Cull原線については、Setupブロック関係の文書にさらに詳細に記されているが、CullTypeパラメータは、基本的に追加ビットが線モード三角形の３つのエッジから選択されるSortPrimitiveTypeパラメータである。
【０２４０】
図３１に、６つのタイルと８つの原線だけを含み、Sortメモリページに保存されるデータの簡単な例を示す。本例に見られるように、各Sortメモリページは、次の２つに分割される。１）データ記憶、及び２）ポインタ記憶である。データ記憶はそのデータを受信順に保存し、次の２バイトの記憶エントリを保存する。１）頂点パケット、及び２）モードパケットである。図３１の例は、１３個の頂点パケットと3つのモードパケットを示す。ポインタ記憶は、次の2タイプのリストを含む。1)ポインタリスト：各タイルに一つずつ、及び２）モードポインタリストである。図３１中の例は、合計１８個のVertexポインタを含む６つのTileポインタリスト及び１つのClearポインタと３つのCullポインタを含むModeポインタリストである。Vertexパケット及びModeパケットのサイズは、常に単一のRambus Dualoctである。それゆえ、図３１に示すアドレスはDualoctアドレスである。
【０２４１】
Sortブロックに頂点が支給され、データ記憶に順に書き込まれると、各タイルにつきTileポインタリストが構築される。Tileポインタリスト内の各Vertexポインタは、対応するタイプの一部をカバーするCull原線を含むSort原線の最後のSort Memory Vertexパケットのデータ記憶内アドレス（例：ポインタ）を含む。例えば、図３１では、原線１１（例：Duatoctアドレス１１に書き込まれるSort Memory Vertexパケット）により完成される三角形が３つのタイルに触れ、この原線へのポインタが３つの接触されたタイル（タイル２、４、及び５）用のTileポインタリストに加えられる。
【０２４２】
アドレスに加えて、各Vertexポインタアドレスはオフセットも含んでいる。オフセットがゼロの場合、Sort原線タイプは点である。図３１の例は、Tile５内の４つ目のPointer Entryを形成する原線１６によって表される点である。オフセットが１の場合、原線タイプは線である。図３１の例に示す線は、原線１４及び原線１５によって形成され、Tile0中の最初のPointer Entry及びTile2中の４つ目のPointer Entryを形成する。これら２つのエントリ内では、アドレスフィールドは１５であり、線の中の最後の頂点をポイントする。線の場合、他の頂点が常に直前のアドレス上の頂点である。オフセットが複数の場合、Sort原線タイプは三角形であり、オフセットは三角形内の最初の頂点の位置を決定するのに使用される。例えば、図３１では、頂点１２が三角形の３つめの頂点である。2つ目の頂点が常に直前のアドレス−この例では頂点１１である。最初の頂点は、アドレスからオフセットを減算することによって見つけることができる。本例では、オフセットは4であり、最初の頂点は頂点８である(例：１２−４＝８)。それゆえ、Tile2、Tile３、Tile４、及びTile5にエントリを加えることによりPointer記憶に４つのVertexポインタが加えられる。これら4つのエントリは、それぞれアドレス＝１２及びオフセット＝４を持っている。
【０２４３】
アドレス及びオフセットに加えて、各VertexポインタはTransparentフラグビットも含んでいる。本ブール変数は、パイプラインがSorted Transparencyモードにある場合にのみ使用される。本モードがTRUEの場合は、原線は透過の可能性があるとして扱われ、FALSEの場合は、原線の不透明性が保証されていることを示す。本文脈中では、「不透明」とは、ウィンドウ中の同じ領域を占有するより遠くのジオメトリを完全に覆い隠す原線を示す。図３１の例では、頂点9から１１によって完成された三角形は、Vertexポインタ内の「T」で示される、TRUEに設定されたTransparentビットを持つ。これら３つの三角形は９つのタイルに接触するため、「T」インジケータを持つエントリは9つある。
【０２４４】
Sortブロックにモードパケットが支給され、順にデータ記憶に書き込まれるため、単一のModeポインタリストが構築される。Modeポインタリスト内の各エントリは、データ記憶内のモードパケットのアドレスである。それぞれ対応するモードパケットタイプを持つ次の２種類のポインタがある。１）Sort Memory Clearパケットを含むClearポインタ、及び２）Sort Memory Cullパケットを含むCullポインタである。
【０２４５】
Clearポインタ及びCullポインタの双方が、モードパケットのタイプを示すModePktTypeパラメータを含む。両ポインタが持つモードパケットを示すブール変数（SubFrameBreakOnClear及びSubFrameBreakOnCull）は、その点においてフレームのSubFramesへの分割の原因となる。ブール変数がTRUEで現SubFrameがすでに透過ジオメトリを含んでいる場合、そのモードパケットの直前でフレームが分割される。図３１の例では、１つのCullポインタが、そのCullポインタ内の「S」で示される、TRUEに設定されたSubFrameBreakOnCullビットを持つ。Clearポインタも、Pixelブロックでバッファクリア動作が行われるべきことを示す他のブール変数SendToPixelを持つ。
【０２４６】
Sortメモリページの読み出し中に、複数の頂点がSort原線へと組み立てられ、モードが全てのタイルの出力ストリームに注入されるため、Sortメモリアドレスは常に増加する。図３１の例では、Tile3が読み出された場合、出力パケットの順序（データ記憶アドレスとして指定される）は０、１、４、５、６、７、１２、及び１３である。Tile3に触れた原線(例：４、５、６、及び１２)だけが出力されるが、４つのモードパケットの全てが出力されることに注目する。一般的に、全てのモードパケットは全てのタイルの最中に送信されるが、幾つかのモードパケットは除去することができるかまたは目的ドローバッファに関連しないため、出力ストリームには供給されない。本処理については、後の節で詳細に論じる。
【０２４７】
原線パケット及びモードパケットに加えて、Sortメモリは、「Tweenパケット」と呼ばれ、ユーザフレーム間にあると考えられるデータパケットも持つ。特定的に、Tweenパケットは、ソフトウェアがユーザフレームを発行した後及びソフトウェアが開始ユーザフレームを発行する前にのみパイプラインに入力できる。アーキテクチャの観点からは、TweenパケットはSortメモリページの一部とは考えられていない。しかしながら、Sortメモリには他にデータを保存するスペースがないため、TweenパケットはSort WriteプロセスによりSortメモリページ内のデータ記憶の最初の部分に保存される。Tweenパケットは、先ず３Dフレームに同期する必要がある２Dコマンドのために使用される。例えば、ジオメトリがオフスクリーンバッファ（ｐバッファ）に収められると、ストレッチビット動作がデータをフレームバッファに転送する。本動作はフレーム間で行われなければならない。Tweenパケットは、全ての蓄積バッファ動作にも使用される。
【０２４８】
図３２にSortブロックの簡単なブロック図を示す。これまで論じられてきた機能に加えて、図３２が二重バッファリングされた状態レジスタを示す。これらレジスタは、書き込みまたは読み出し中のフレームのパラメータを収納する。パラメータには、水平方向のタイル数、垂直方向のタイル数、目的ドローバッファは二重バッファリングされているか、目的ドローバッファはステレオか、フレームはTime OrderモードまたはStored Transparencyモードにあるか、ピクセル内のサンプル位置選択、サンプル重み付け、及びSortメモリまたはPolygonメモリ内のオーバーフローがフレームの原因となったかが含まれる。
【０２４９】
アルゴリズムの観点からは、タイルは独立で、いかなる順序でも読み出し可能である。しかしながら、テクスチャの再使用を最大にするために、「スーパータイル」と呼ばれるタイルグループが順に読み出される。スーパータイルあたりのタイル数は選択可能でるが、我々は常にスーパータイルあたり２×２タイルの選択を期待する。シーンホライゾンの複雑さの影響により生じる負荷の不安定を最小化するには、スーパータイルは行ごとにも列ごとにも読み出さない。むしろ、スーパータイルは空間的にばらばら（擬似ランダム）に読み出す。正確な順序は重要ではないが、スーパータイルの順読み出しセットはウィンドウを横断する直線になってはならない。本擬似ランダム歩行のアルゴリズムは後述する。
【０２５０】
ステレオ３Dウィンドウの場合、左右のバッファは、それぞれ別のタイルのセットを持つ別々のバッファと考えられる。例えば、１０２４×７６８ウィンドウは６４×４８タイル（合計３０７２タイル）を持つが、ステレオウィンドウは２×６４×４８タイル（合計６１４４タイル）を持ち、各（ｘ、ｙ）個所に２つのタイルを持つ（左右に１つづつ）。
【０２５１】
アプリケーションが正面及び裏面バッファ双方に同じフレーム内の特定のタイルを収納した場合、そのタイルは２つのパスで処理される必要がある。最初に裏面バッファ用に、次に正面バッファ用に処理される。しかしながら、裏面バッファにのみ収められたジオメトリは正面バッファにのみ収められたジオメトリの深度テストの結果の変更（及びその逆）が可能なために、全てのジオメトリ(正面及び裏面の)は両パスの最中にパイプライン中を送信されなければならない。なお、同様の開始深度及びステンシル値が両パスに対して使用されなければならない。従って、与えられたタイルに対する裏面及び正面パスは連続して行われなければならない（例：間に他のタイルがあってはならない）ため、Back EndはフレームバッファからPixelブロック内の連続バッファへと深度及びステンシル値をロードすることができる。正面バッファ用のパスの初期ロード前に裏面バッファ用のパスが完成しそうな場合は、収納エラーが発生する可能性がある。Backendがこの処理を保証しなければならない。
【０２５２】
書き込みプロセス中では、原線の領域が実際にタイルの一部をカバーしている場合にはそれら原線を割り付ける処理のみを行うことが重要である。簡単なバウンディングボックスが使用されている間に、同ボックスが、特に対角線及び長く細い対角線三角形に対してSortメモリの帯域幅を無駄にすることがある。後の節において、Touched Tile Calculation用の簡潔なアルゴリズムを示す。
【０２５３】
Sortメモリページの約半分がポインタに使用される。従って、Sortメモリ内に必要なバイト数は、最大頂点数の約６４倍である(モードパケットはこの処理にはあまり資さない)。各頂点は１６バイト、ポインタは付加的１６バイトを必要とし、そして必要な２ページがある。
【０２５４】
Sortブロックは、各フレーム中の三角形の数などの幾つかの性能メータ関係の情報収集を続ける。「Sortブロックからの出力」の節の従属節「性能計測能力、ホストから読み出し可能」を参照。
５．５．２  Sortブロック機能詳細
Sortブロックは、平行動作の次の２つのプロセスを含む。１）Sort Writeプロセス、及び２）Sort Readプロセスである。Sort Writeプロセスは、書き込みが完了し、読み出しプロセスが休止している場合にSort Readプロセスを開始するので、２つのプロセスの「マスター」である。擬似コードは、全ての変数が「大域」であると想定する。原線が接触するタイルを決定するTouched Tile Calculationなどの他の機能詳細が本節に含まれる。
５．５．２．２  Sort Write Process
Sortメモリページの場合、Sort Write Processが頂点のシーケンスリスト及びデータ記憶内のモードパケットを作成する(図３１参照)。Sort Write Processは、タイルごとにTileポインタリスト及びフレームごとにModeポインタリストを作成する。
５．５．２．２  Sort Read Process
Sort Read Processは、厳格にタイルごとに出力パケットシーケンスを生成する。左右のタイルは個別に扱われる。
５．５．２．２．１  Sort Read Process外側制御ループ
Sort Read Processの外側制御ループには次の３つの機能コンポーネントが含まれる。１）TimeOrderMode;２）Sorted Transparency Mode OpaqueLoop();及び３）Sorted Transparency Mode TranspLoop()である。下記の節で各コンポーネントを説明する。
【０２５５】
最初のモードパケットが全てのタイル内に出力されるため、モードパケットのキャッシングは、FILOベースで行われなければならない。キャッシング機構は、少なくとも２つの先のモードパケットを見て、処理へのバブル注入からモードパケットを選択する（タイムオーダリングを決定するために）アドレス比較を防止する。
５．５．２．２．２  Time Order Packet Processing
本処理は、パイプラインがTime Orderモードにある時に実行される各Sort Memoryパケットタイプの処置に関わる。
５．５．２．２．３  Sorted Transparency Packet Processing、不透明ジオメトリ送信
本処理は、不透明ジオメトリ用の単一パスの最中にパイプラインがSorted Transparencyモードにある時に実行される各Sortメモリパケットタイプの処置に関わる。
５．５．２．２．４  Sorted Transparency Packet Processing、透過ジオメトリ送信
本処理は、透過ジオメトリ用の複数パスの最中にパイプラインがSorted Transparencyモードにある時に実行される各Sortメモリパケットタイプの処置に関わる。Sort Memory Clearパケットは、透過処理の間は常にスキップされている。
【０２５６】
５．５．２．２．５  Clearレジスタ機能
StencilModeは２ビットステンシルモードのウィンドウのセットを持っている場合、ソフトウェアは８ビットをまたいでStencilMask及びStencilValueの２つの最も有意でないビットを写し取る。ソフトウェアはまた、ClearDepthの値の送信中にOpenGL DepthMaskを考慮する。その理由としては、Backendがクリアの最中にDepthMaskをチェックしないからである。
５．５．２．２．６  Cullレジスタ機能
CullFlushAllRegだけが実際に「蓄積される」信号である。SoftSubFrameBreak及びOnlySoftSubFrameBreakはSort Read Processには使用されないが、デバッギングの目的でSort Memory Cullパケットに含まれている。
５．５．２．３  接触されたタイルの演算
我々は、三角形、ABC、及び中心が（ｘTile、ｙTile）であるタイルを与えられて、三角形がタイルに触れているかを決定したい（図３３）。アルゴリズムは、三角形内の各線が、平面を内部半平面と外部半平面の２つの半平面へと分割することによる。タイル全体がいずれかの線により定義された外部半平面に入っている場合、三角形はそのタイルには触れない。三角形がタイルに接触するには、３つの内部半平面全ての中に少なくともタイルの一部が含まれていなければならない。
【０２５７】
接触されたタイルの演算は線にも適用されるが、線の点描は接触された線の演算のために無視される。
【０２５８】
処理を開始するために、我々はベクトルを図３４に示すように三角形の線の一つから直角にタイルの中心に走るものとイメージする。
【０２５９】
本直角ベクトルの大きさｄを演算することにより、タイルの中心の線からの距離及びその中心が内部半平面にあるかまたは外部半平面にあるかを決定できる。ｄの負の値は、線によって定義される内部半平面にタイルの中心があることを示している。
【０２６０】
我々は次に、線がタイルと交差する閾値距離ｔを演算する。図３５A及び３５Bに示すように、距離はタイルの辺（φ）の一つに関係する線の角度の関数である。
【０２６１】
直角ベクトルｄが閾値距離ｔよりも大きい場合は、タイル全体が三角形の外側にある(図３６C)。ｄが０とｔの間にある場合は、線がタイルと交差し(図３６B)、ｄが負の値の場合は、タイルの中心は線によって定義された内部半平面の中にある(図３６A)。
【０２６２】
三角形内の各線に対して上記演算を実行することにより、我々は三角形がタイルに触れているかを決定することができる。
５．５．２．３．１  直角ベクトル
線ABの場合、（ｘ０、ｙ０）から（ｘ１、ｙ１）により、等式は下記のようになる。
【０２６３】
【数１】
0003657518.tif 000004
（ｘTile、ｙTile）を通り本線に直角な線の等式は下記の通りである。
【０２６４】
【数２】
0003657518.tif 000005
次に、我々はオリジナルの線の交点と直角を決定する。
【０２６５】
【数３】
0003657518.tif 000006
我々は、便宜的に上記等式を下記のように表す。
【０２６６】
【数４】
0003657518.tif 000007
次に、我々は（ｘ、ｙ）及び（ｘTile、ｙTile）を演算する。
５．５．２．３．２  閾値距離の決定
閾値距離を決定するために、我々は、図３７に示すようにタイルの辺の１つに関して線の角度を見る必要がある。
【０２６７】
【数５】
0003657518.tif 000008
５．５．２．３．３  全ての追加
与えられた線に基づいてタイルが三角形の外側にあるかを決定するために、我々は下記比較を行う。
【０２６８】
【数６】
0003657518.tif 000009
本比較のために、我々は角度を第一四分円に変形したので、実際のテストは下記のようになる。
【０２６９】
【数７】
0003657518.tif 000010
本テストが真である場合は、タイルは三角形の外側になる。我々は三角形内の他の線に対しても同様の比較を行う。
【０２７０】
【数８】
0003657518.tif 000011
ここで
【０２７１】
【数９】
0003657518.tif 000012
これら全てのテストが偽である場合、三角形はタイルに触れている。
【０２７２】
線の場合、演算は三角形の１つの辺に対するそれと似通ったものになるが、我々の関心事は線がタイルと交差しているかということだけである（すなわち、三角形の時のように「内側」か「外側」かで悩む必要はない）。従って、我々はｄの符号を無視し、その大きさだけを考慮する。我々は、線の幅も考慮に入れなければならない。これら２つの変更は我々に下記テストを与える。
【０２７３】
【数１０】
0003657518.tif 000013
本テストが偽の場合は、線はタイルに触れている。
【０２７４】
参考までに、Andreas Schillingの"A new simple and efficient antialiasing with subpixel masks"、Computer Graphics1991年７月号を参照。
５．５．２．４  SuperTileホップシーケンス
３D画像を収容する場合、絵を通した水平束が画像の残りの部分をはるかに上回る複雑さを持っている「水平線効果」がしばしば見られる。一例としては、単純な草原が手前にあり上に空がある遠くの市街の輪郭がある。草及び空は非常に少ない多角形を持っている（おのおの１つであることが多い）が、市街は多数の多角形及び非常に複雑な深度を持っている。このような水平線効果は、シーンを通した非水平束に伴って起こることもある。タイルが単純な上から下及び左から右の順で処理されると、複雑なタイルは、パイプライン内の負荷不安定をもたらす裏面から裏面の処理を受けることになる。従って、タイルからタイルに移るには、画面内をランダムに「ホップ」するのが良い。しかしながら、本処理は特別な干渉の減少に繋がり（なぜならば、隣接するタイルが順に処理されないからである）、パイプライン内のキャッシュの効率を下げ、性能を低下させる。空間の順タイル処理及び完全ランダムパターンの間の妥協として、タイルは「スーパータイル」に編成される。そこでは空間的に隣接する複数タイルがスーパータイルとなる。その後、スーパータイルのランダムパターンが処理される。このように、空間的干渉はスーパータイル内に保持され、水平線効果が防止される。
【０２７５】
３Dウィンドウはタイルに分割され、これらタイルは「スーパータイル」にグルーピングされる。スーパータイル内のタイル数は、MEX Output Begin Frameパケット内のパラメータSuperTileSizeで選択できる。タイルが処理されるシーケンス（「スーパータイルホップシーケンス」と呼ばれる）は、やはりMEX Output Begin Frameパケットに含まれるSuperTileStepにより制御される。
【０２７６】
図３８Aにスーパータイルホップシーケンスの簡単な例を示す。本例は、１８×１４配列の２５２個のタイルより成るウィンドウ６２０２を示す。SuperTileSizeは２×２タイルと想定される（しかしながら、１×１、１×２、２×１、２×２、２×３、３×２、３×３、３×４、４×３、または４×４を含みいかなるサイズでも良い）ので、９×７配列の６３スーパータイルがある。スーパータイルのリストは、直線リストに変換されていると想定されるが、この変換はスーパータイルの列単位の番号付けを左上部から始めることにより実行できる。下記変数を定義する。
N=ウィンドウ内のスーパータイル数
M=SuperTileStep
Tn＝処理されるｎ個目のスーパータイル
スーパータイル処理のシーケンスは下記の通り。
T０＝０
Tn＋１＝modN（Tn＋M）
図３８Aの例では、N＝６３及びM=13となっている。この結果は、図３８Bに描かれているようにT0＝０、T1＝１３、T2＝２６、T3＝３９、T4＝５２、T5＝２、T6＝１５、…のシーケンスとなる。MがNより少ない必要はない。
【０２７７】
本インタラクティブアルゴリズムは、N及びMが互いに素数である（すなわち、これらの数値の最大共通因子が１である）かぎり、全てのス−パータイルをヒットする。NもMも素数である必要はないが、Mが常に素数として選択される場合は、全てのスーパータイルがヒットされる。
【０２７８】
代替法としては、スーパータイル配列を必要以上に大きくしてウィンドウ全体をカバーするようにし、２a×２b＝２2aと想定されるので、スーパータイルの総数は２の整数乗に保証される。本処理は、単に上位ビットを捨てるだけで「modN」演算を可能にする。本アプローチに対するマイナス部分は、シーケンスに存在しないスーパータイルが含まれていることである。これら存在しないスーパータイルは検索及びスキップされなければならない。
５．５．２．５  線フラグ
線モードの三角形の場合、Sortブロックは、各線とは独立に、線が接触するタイルを決定する。しかしながら、同じ三角形からの複数の線がタイルに接触すると、１つのポインタのみがその三角形に対してTileポインタリストに付加される。なぜならば、SortブロックがSort原線（Cull原線ではない）を分類しているからである。
【０２７９】
線モードの三角形を受信すると(例：LineModeはTRUEであり、LineFlagsパラメータ内の１つ以上のビットがTRUE)、その三角形は、塗りつぶされた三角形としてではなく、１つ以上の線として描かれる。LineFlagsには三角形の各エッジを示す３つのビットがあり、対応するエッジを線として描くべきかを示している。これら３つのビットは次のものを表している。１）頂点０と1の間のエッジに対応するビット０（LSB）；２）頂点１と２の間のエッジに対応するビット1、及び３）頂点２と０の間のエッジに対応するビット２（MSB）である。LineFlagsパラメータは、頂点を決定し、多角形を完成するパイプラインの一部であり、クリッピングの役割を負っているために、GEOブロックに設定される。
【０２８０】
幾つかのエッジ線は描いてはならないため、３つのLineFlagsビットは独立にそれらビットに対応するエッジを制御する。例えば、OpenGL四辺形は、常に2つの三角形に分割されるが、線モードで描かれた場合は、四辺形内のエッジは描かれない。それゆえ、オリジナルの四辺形内のエッジに対応する各三角形内の２つのエッジは、それらのLineフラグセットをTRUEに設定し、他の三角形内のエッジ(四辺形内の共用エッジ)はLineフラグセットをFALSEに設定する。
５．５．２．６  三角形扇形の分割
各ポインタエントリ内のOffsetパラメータは、６３の最大オフセットを内包する６つのビットを持っている。三角形の扇形が６３以上のオフセットを必要とする場合、扇形はデータ記憶内の２つの頂点を写し取ることによって分割される。カラーメモリ内でも類似した現象が起き、Sort Block Inputパケットに残りのデータを付加するカラーメモリ内へのポインタはそのことを考慮しなければならない。
５．５．２．７  線幅考慮
OpenGL内では、幅がピクセル幅の数として、長さがエンドポイント間の距離として指定されるアンチアライアスド長方形として描かれる。また、これらの線は、点描され、長方形をそれぞれの長さに合わせた一連のアンチアライアスド四辺形へと分解し、各四辺形は通常の方法で色付けを指定されるか完璧な透過に指定される。点描された線は、仮想的な鎖線と考えられる。
【０２８１】
線の原線が(線または線モード三角形)がSortブロックに受信されると、線の幅が原線の隣接するタイルへの「こぼれ」の原因となる。
５．６  Setupブロック（STP）
Setup(STP)ブロックは、Sort(SRT)ブロックからパケットの流れを受信する。これらのパケットは、描画される原線に関する空間情報を持つ。STPブロックの出力は、Cull(CUL)ブロックに行く。SRTから受信した原線は、塗りつぶされた三角形、線三角形、線、点描された線、及び点である。各原線は、アライアスドまたはアンチアライアスドモードで描画することができる。SRTブロックは、タイル順にSTP（及び他のパイプラインステージ下流）に原線を送信する。各タイル内では、データはタイムオーダーまたは分類された透過の順で編成される。CULブロックは、タイル順で（実際には、STPがSRTから原線を受信する順に）STPブロックからデータを受信し、絶対に描画された画像に資することのない原線のパーツを選別する。本処理は２つのステージで完了する。最初のステージMCCAM Cullは、与えられた値よりも大きな内容を持つ長方形メモリ配列内のそれらのエレメントの検出を許容する。第2のステージは、サンプルごとの比較により本サーチ上でリファインする。STPブロックは、CULブロックによる処理用の入り原線を用意する。STPは、タイトバウンディングボックス及びMCCAM選別用のタイルを横切る原線の一部用の最小深度値Zminを生成する。MCCAM選別ステージは、Zminよりも小さい深度値を含む可能性のあるバウンディングボックス内のスタンプをマークする。Z選別ステージは、これらの候補スタンプを取り、それらが原線の一部である場合は、そのスタンプ内のサンプル用に実際の深度値を演算する。その後、この、より正確な深度値は、比較及び起こり得るサンプルごとの廃棄に使用される。MCCAM選別用のバウンディングボックス及びZminに加えて、STPは、Z選別ステージ用として、深度の傾き、ラインスロープ、及び深度や原線のタイルエッジに対する交差点などの他の参照パラメータを演算する。CULユニットは、他のパイプラインステージに使用されるVSPを生成する。
【０２８２】
コンテクストを設定するために、我々は簡潔に種々のSTP原線を説明する。
５．６．０．１  多角形
STPブロックに到着する多角形は、基本的に三角形である。それら三角形は、アライアスドまたはアンチアライアスドモードで描画される。図３９にDSGP三角形を示す。STPユニットは、アライアスドまたはアンチアライアスド三角形を同様に処理する。パイプラインユニット下流は、ピクセルの中央に全てのサンプルを位置付けることによってアライアスド三角形を描画する。アンチアライアスドのケースでは、サンプル位置は、制御パケットの１つと共に渡されるSampleLocSelパラメータにより決定される。サンプルは、三角形の形状寸法境界内で失敗した場合には三角形に属する。サンプルが三角のエッジの真上で失敗した場合は、取り込み規則を使用して本サンプルが三角形に属するかを決定する。
５．６．０．２  線
DSGPは、四辺形に変換することにより線を描画する。図４０に様々に方向付けられたアライアスドあるいはアンチアライアスド線を描くために生成された種々の四辺形を示す。線の幅は、最も近いサポートされた幅に丸められる。SORTステージに先立って幅の調整が成されなければならない。本調整はソフトウェアにより実行可能である。STPは入り線幅を変更しない。
【０２８３】
アライアスド及びアンチアライアスド線による四辺形の生成は別々の方法で行われることに注意する。アライアスド線のばあいも、四辺形の頂点は、線がｘメジャーかｙメジャーかによる。
５．６．０．３  点
DSGPは、アンチアライアスド点を円として描き、アライアスド点を四辺形として描く。円は、ユーザが指定した位置を中心として描かれる。円の直径は、ユーザにより指定され、最も近いサポートされた幅に丸められた幅である。アライアスド点を描く場合、ユーザにより指定された点の位置は、結果の幅が奇数が偶数かによりそれぞれ、ピクセルの中心にスナッピングされるかピクセルの角に丸められる。線の場合は、SORTブロックに先立ち、点サイズ及び位置の調整がパイプライン内で起きる。点の位置は変形に支配されるために、Geometryユニットが本処理を行うには適当な場所に思える。図４１に描画された点を示す。ユーザが指定した点は円によって示される。
５．６．１  Setupブロックの機能概要
本節では、我々は各原線に対して実行される処置のセットアップの概要を説明する。特定の処理の詳細を第３節に示す。
５．６．１．１  塗りつぶされた多角形
Setupは、CULユニットに対して処理用の塗りつぶされた多角形を用意する。STPは、三角形の３つの頂点に対してウィンドウ座標（ｘ、ｙ、ｚ）を受信する。STPは、多角形のオフセットの演算で使用する「係数」も受信する。アンチアライアスド状態は塗りつぶされた三角形セットアップがなされた手法は変更しないことに注意する。CUL及びPixelブロックは、全てのサンプルをピクセルの中央に向けて破壊させることによりアライアスド三角形のラスタ図形処理を行う。我々はまた、三角形の頂点がウィンドウ座標の有効な範囲内で崩壊すると想定する（例：三角形の座標がウィンドウの境界にクリッピングされている）。
【０２８４】
エッジ上の三角形は全て廃棄される。エッジ上の三角形がVSPを生成することは予想されていない。我々が三角形をSTP内で廃棄しなかった場合は、CUL内でこれら三角形のラスタ図形処理を伴うオーバーヘッドが発生する。さらに、まれな事象では、上記のような三角形がVSPを生成し、ピクセル照度は変則的になる。この事象は、エッジのスロープが同等なことが発見されたときに検出される。
【０２８５】
各塗りつぶされた多角形では、STPが下記処理を行う。
１．頂点に対し、上部、下部、左（または右）頂点を提供するよう命令する。また、中央の頂点がｙの中の長いエッジの左右どちらに行くかを示すleftCまたはrightCフラグを設定する。例：最大及び最小のｙ値を持つ頂点と接するエッジ。
２．  ｘ及びｙと共にｚの部分導関数（δz／δx、δz／δｙ）を演算する。
３．  可能な場合は多角形のオフセットを演算し、各頂点のｚ値にオフセットを加える。
４．  CULユニットの３つのエッジのスロープを演算する。エッジ上の三角形を廃棄する。
５．  タイル境界に三角形をクリップする。
６．  CULユニットに対する参照ｚ値（参照スタンプ用の）の演算同様にバウンディングボックス、上部エッジ交点、及びタイルと交差する三角形領域の最小ｚを演算する。
７．  原線にコードを割り付け、CULユニットに関連情報を送信する。
【０２８６】
以前説明したように、バウンディングボックス及びZminはMCCAM選別に使用される。上部エッジ交差、線スロープ、コーナー点、参照ｚ値、及びｚ傾きはCULブロックによるZ選別に使用される。
５．６．１．２  アンチアライアスド実線
CULユニットは、平行四辺形及び三角形に対して同様にラスタ画像処理をするスキャンコンバータを実行する。アンチアライアスド線セグメントは、図４２に示すように長方形へと変換される。
【０２８７】
線の各端の長方形の頂点は、線のエンドポイント同様に同じｚ値に割り付けられて定数ｚの線を線自体に対して直角にする。各線セグメントに対しては、STPは下記処理を実行する。
１．  ｘ及びｙ頂点の変位（ｘｈｗ、ｙｈｗ）を決定する。
２．  長方形の頂点を決定する。演算された頂点は、線がアライアスドかアンチアライアスドかによって変化する。
３．  CULユニットに対してマイナー及びメジャー軸のスロープを演算する。(マイナー名軸はメジャー軸に対して直角である。)
４．  頂点に対して上部、下部、左、及び右の頂点を提供するよう命令する。
５．  (δｚ/δｘ、δｚ/δｙ)と共に本長方形に対してｘ及びｙ部分導関数を演算する。
６．  タイル境界に長方形をクリップする。
７．  CULユニットに対する参照スタンプ用参照ｚ値同様に、バウンディングボックス、上部エッジ交差、及びタイルと交差する長方形領域の最小ｚを演算する。
８．  原線コードを割り付け、関連情報をCULユニットに送信する。
５．６．１．３  アライアスド実線
以前説明したように、アライアスド線のエンドポイントは、アンチアライアスド線のエンドポイントとは異なる方法で演算される。アンチアライアスド線の場合の長方形の代わりに、我々はアライアスド線に対して平行四辺形を演算する。平行四辺形の２つのエッジは、線の長さと並行であり、他の２つのエッジは、図４３に示すように垂直（ｘメジャー線に対して）または水平（ｙメジャー線に対して）である。
【０２８８】
OpenGLは、平行四辺形の頂点の演算により下記がもたらされることを要求する。
１．  両セグメントがｘメジャーまたはｙメジャーの場合、連続多線セグメントを描いている間にはギャップもオーバーストライクも生じない。
２．  OpenGLダイアモンド出口規則を使用してラスタ図形処理された総フラグメント数とDSGP法の間に最大１つの行（または列）不均衡がある。
４．  ｘ及びｙ方向の一つ以上のユニットによりラスタ図形処理されたフラグメントの座標が遷移する。
【０２８９】
しかしながら、本処理はCULによる平行四辺形及び三角形のラスタ図形処理に制約を設ける。CULはフラグメント包含規則を利用して２つの原線が共有するエッジの真上に位置するフラグメントが２つの原線の内の一つのみに含まれるようにする。(アンチアライアスド描画規則はフラグメントではなくサンプルに適用される。)Setupは、アライアスド幅広の線を描くために下記処理を実行する。
１．ｘ及びｙ頂点遷移（ｘｈｗ、ｙｈｗ）を決定する。
２．  線のスロープを見ることにより平行四辺形の頂点を決定する。線のエンドポイントは変更されない。
３．  CULユニットに対して、エッジに沿い、線の長さに並行なスロープを演算する。他の軸は水平または垂直である。
４．  頂点に対して上部、下部、左、及び右の頂点を提供するように命令する。
５．  ｘおよびｙと共に本長方形に対してｚの部分導関数（ｄｚ/ｄｘ、ｄｚ/ｄｙ）を演算する。
６．  タイル境界を持つ四辺形の交点を演算する。
７．  CULユニットに対する参照スタンプ用参照ｚ値同様に、バウンディングボックス、上部エッジ交差、及びタイルと交差する領域の最小ｚを演算する。
８．  適切な原線コードを割り付け、CULユニットに関連情報を送信する。ステップ２から８がアライアスド及びアンチアライアスド線に対して同様に利用できることに注意する。
５．６．１．４  点描線
点描に伴う状態は、１６ビット点描パターン、点描繰り返し係数ｒ、stplStarBit、及びstplRepeatStrtを含む。点描パターンは、モード中に描かれた細片、線ループ、及び多角形の各セグメントをまたいで連続されなければならない。stplStartBit及びstplRepeatStartは、このような連続をするために使用される必要な状態パラメータである。Setupは、各線セグメント用のstplStartBit及びstplRepeatStartに関する情報を得る。Geometoryユニットは、各線セグメントの開始においてstplStartBit及びstplRepeatStartオフセットを演算する役割を負う。線幅ｗも生成された線セグメントの出現を制御する。Setupは、描画パターン中に連続する１の列を四辺形に分解する。アンチアライアスド線の場合、四辺形は長方形である。これらの四辺形は、「nr」の長さと幅を持っている。ここで、ｎはその列の中の１の数である。これらは線の目に見える部分を表している（図４４）。
【０２９０】
非アンチアライアスド線の場合、四辺形は平行四辺形である。STPが1ビットの各走行に対して四辺形を生成するため、これら四辺形の内の幾つかはタイル境界の外にある。これら四辺形の不必要な処理を減らすために、我々は、完全にタイルの外側にある四辺形を立ち上がらせることによって点描セグメントをクリップする。線のスタートポイント（ｘ０、ｙ０）がタイルの外側にある場合は、我々は、スタートポイントに一番近いタイル境界に線をクリップする。クリップされた線のスタートポイントは、最初の線四辺形が完全に含まれるように生成される。本処理は、タイル境界をまたいで連続することを保証する。本処理は、クリッピングする四辺形のバンドをタイル周辺に置く処理と等価である。クリッピングされた点に対して、新たな線スタートポイントが、点描オフセットstplStartBitと同様に生成される。(我々は旧stplRepeatStartを保持する。)図４５に本処理を示す。
【０２９１】
この線は、ｘｈｗ及びｙｈｗにより置換されたｘ及びｙ方向のタイルのエッジにクリッピングされる。従って、点描された線は下記ステップを踏んで行われる。
１．  線がアライアスドまたはアンチアライアスドかによって頂点の置換を決定する。
２．  ガードバンドと共に線のヘッドをタイルにクリップして（tileXmin―xhw、tileYmin―yhw、tileXmax＋xhw、tileYmax＋yhw）クリッピングされた点がガードされたタイルの上または外に位置するようにする。クリッピングされたセグメントの長さの単位は点描されたビットである。新たなstplStartBitを得る。
３．  点描内の各1ビットの列は四辺形を構築してそれをパイプを通じて送信する。新たなスタートポイントがタイルガードバンドの外側に落ちた場合に本プロセスは続けられる。
５．６．１．５  線三角形
線モードで三角形を描く場合、STPユニットは、３つの三角形の頂点用のウィンドウ座標（ｘ、ｙ、ｚ）に加えてエッジフラグを受信する。本エッジフラグは、Setupユニットに描くべきエッジを伝える。Setupユニットは、多角形オフセットの演算に使用する「係数」も受信する。描くべきエッジは、多角形オフセットにより最初にオフセットされ、その後幅ｗ（線属性）のリボンとして描かれる。点描が可能な場合は、これらの線が点描される。図４６に線モード三角形のジオメトリを示す。
【０２９２】
STPは各線多角形に対して下記処理を行う。
１．  エッジ上の三角形を全て廃棄する。詳細は、塗りつぶされた三角形の節を参照。
２．  （δｚ/δｘ、δｚ/δｙ）と共にｘ及びｙ部分導関数を演算する。これらのｚ傾きは三角形用であり、三角形のｚオフセットを演算する上で必要になる。
３．  可能ならば多角形オフセットを演算し、３つの内の各頂点上のｚ値にオフセットを追加する。
４．  順にエッジを横断する。エッジが見える場合は、幅や点描などの属性を使用してそのエッジを描く。
５．  アンチアライアスド、アライアスド、及び幅などの線属性に基づいて線を描く。
６．  どのエッジが特定の原線コードによって表されているかにより、その原線コードを割り付け、CULに送信する。
５．６．１．６  アライアスド及びアンチアライアスド点
SetupはYtop,Xcenter,及びYoffsetを検出し、これらの値を点幅及び割り付け状態と共にCULに送信する。
５．６．２  Setupブロック機能詳細
前節までに概要を説明した種々の原線の処理は多くの共通点を持っている。本発明者らは、上記の共通点の強化のために原線の表現を統一した。
５．６．２．１  統一された原線表現
前述のように、Setupは線セグメントを４つの頂点から成る平行四辺形に変換する。三角形は３つの頂点を持つ。Setupは、４つの点のセットにより各原線を表す。全ての値が全ての原線に必要ではないことに注意する。三角形の場合、Setupは、三角形の動作により、上部、下部、及び左または右コーナーを使用する。線セグメントは平行四辺形として扱われるため、Setupは４つの点の全てを使用する。図４７−５１にどのようにしてSetupが三角形及び線を表現するかを示す。三角形の頂点がオリジナルの頂点と同じである間は、Setupは新たな頂点を生成して線を四辺形として表現することに注意するべきである。
【０２９３】
原線の統一された表現には、ウィンドウ座標内の頂点のオリジナルセットに割り付けられた原線ディスクリプタが使用される。なお、次のフラグは有効なかつ意味のある値を持つディスクリプタを示す。VtxYmin、VtxYmax、VtxLeftC、VtxRightC、LeftCorner、及びRightCornerである。
【０２９４】
三角形の場合、三角形の頂点をそれらのｙ座標で分類することによって上記ディスクリプタが得られる。線セグメントの場合、これらディスクリプタは、線四辺形頂点が生成される時に割り付けられる。VtxYminは、最小ｙ値を持つ頂点である。VtxYmaxは、最大ｙ値を持つ頂点である。VtxLeftCは、三角形のケースでは長いｙエッジの左側にある頂点であり（頂点VtxYmin及びVtxYmaxを組み合わせることにより形成される三角形のエッジ）、平行四辺形のケースでは頂点VtxYmin及びVtxYmaxを組み合わせることにより形成される四辺形の左側にある頂点である。三角形の長いｙエッジが左エッジでもある場合は、フラグLeftCornerはFALSE(0)であり、これはVtxLeftCが無効であることを示す。同様に、VtxRightCは、三角形のケースでは長いｙエッジの右側にある頂点であり、頂点VtsYmin及びVtxYmaxを組み合わせることにより形成される四辺形の右側にある頂点である。三角形の長いエッジが右側のエッジでもある場合は、フラグRightCornerはFALSE（０）であり、これはVtxRightCが無効であることを示す。これらディスクリプタは、タイルエッジの上部及び下部への原線の点描に使用される。実行中は、VtxYmin、VtxYmax、VtxLeftC、及びVtxRightCはオリジナルの原線頂点へのインデックスであることに注意する。
【０２９５】
付加的ディスクリプタとしては、VtxXmin、VtxXmax、VtxTopC、VtxBotC、TopCorner、及びBottomCornerがある。三角形の場合、これらのディスクリプタは、三角形の頂点をそれらのｘ座標で分類することにより得られる。線セグメントの場合、これらのディスクリプタは、線四辺形頂点が生成されると割り付けらる。VtxXminは最小ｘ値を持つ頂点である。VtxXmaxは最大x値を持つ頂点である。三角形の場合、VtxTopCは長いｘエッジ（VtxXmin及びVtxXmaxを組み合わせたエッジ）上にある頂点であり、平行四辺形の場合は、頂点VｔｘXmin及びVtxXmaxを組み合わせることによって形成される対角線上の頂点である。三角形の長いｘエッジが上部エッジでもある場合、フラグTopCornerはFALSE（０）であり、VtxTopCが無効であることを示す。同様に、三角形の場合、VtxBotCは、長いｘ軸の下にある頂点であり、平行四辺形の場合は、頂点VtxXmin及びVtxXmaxを組み合わせて形成される対角線の下にある頂点である。三角形の長いｘエッジが下部エッジでもある場合、フラグBottomCornerはFALSE(0)であり、VtxBotCが無効であることを示す。これらのディスクリプタは、左右のタイルエッジ上の原線をクリッピングするのに使用される。実行時には、VtxXmin、VtxXmax、VtxTopC、及びVtxBoCはオリジナルの原線頂点内へのインデックスであることに注意する。
【０２９６】
図４７に頂点の割り付けを図示する。なお、我々は{SIYmaxLeft,SIYmaxRight,SILeftYmin,SIRghtYmin}として表現される４つの多角形のエッジのスロープ（δｘ/δｙ）及び逆のスロープ{rSIXminTop,rSIXminBot,rSITopXmax,rSIBoXmax}を使用する。使用されているスロープ名前付け変換はSIStrEndである。SIはスロープを表し、Strtはエッジの最初の頂点識別子、Endは二つ目の頂点識別子である。従って、SIYmaxLeftは左エッジのスロープでありVtxYMax及びVtxLeftCを続ける。leftCが有効でない時、SIYmaxは長いエッジのスロープである。正面のｒの文字は、スロープが相反的であることことを示す。例えば、ｒは（δx／δｙ）ではなく（δy／δｘ）を表している。図４８にスロープ割り付けを図示する。
【０２９７】
これらディスクリプタの全てが平行四辺形の原線に対する有効な値を持っているが、三角形に対してはそれらの全部が有効とは限らない。始めは、三角形や平行四辺形などの簡単な原線を表すかなりの数のディスクリプタが存在するように見える。しかしながら、本発明者らが後述するように、それらディスクリプタは比較的簡単に入手でき、良好な統一的原線セットアップ法を提供する。
【０２９８】
STPによる種々の原線の処理中のステップの検査が下記の機能ユニットを生じる。
１．  三角形ディスクリプタ
２．  深度の傾き及びオフセット演算
３．  線を四辺形に変換するための頂点生成
４．  点描線処理
５．  タイルへの四辺形クリッピング
６．  Zmin,Zref,Bbox演算
７．  点プロセッサ
下記の各項で各ユニットのアーキテクチュアを詳述する。
５．６．２．２  三角形ディスクリプタ
三角形の場合、Setupは次の頂点のセットによりスタートする。（X0、Y0、Z0）、（X1,Y1,Z1）及び（X2,Y2,Z2）である。この３つは、それぞれｘにより分類された頂点にへのインデックスｊ０、ｊ１、ｊ２である(昇順)。
【０２９９】
インデックスｊ０、ｊ１、及びｊ２は、（ｄｘ/ｄｙ）導関数のセットの計算に使用される。インデックスｊ０、ｊ１、及びｊ２は、エッジに対する（ｄｙ/ｄｘ）の演算に使用される。
【０３００】
【数１１】
0003657518.tif 000014
我々は、同様のスロープの２つのエッジを持つ三角形のようなエッジ上の三角形は廃棄する。中央の頂点が左右どちらにあるかは、頂点ｖ[i2]及びｖ[i1]によって形成される線のスロープｄｘ２/ｄｙ及び頂点ｖ[i2]及びv[i0]により形成される線のｄｘ０/ｄｙの比較によって決定される。（ｄｘ２/ｄｙ＞ｄｘ０/ｄｙ）の場合、中央の頂点は長いエッジの右側に位置し、他の場合は、長いエッジの左側に位置する。演算された値は次に原線のディスクリプタに割り付けられる。ｘディスクリプタも同様に割り付けられる。このようにして、我々は三角形の処理に必要な頂点ディスクリプタを得る。
５．６．２．３  深度の傾き及びオフセット演算
深度の傾きは、ｘ及びｙ軸に沿ったｚの部分導関数である。我々は下記の式を使用する。
【０３０１】
【数１２】
0003657518.tif 000015
Ｓｅｔｕｐは、各頂点ｚ値用にＳｏｒｔユニットから２６ビット（ｓ２５）を受信する。部分導関数は、１．２４．１０の精度値として算出される。ｘ、ｙ座標は、ピクセルごとの（８×８）サブラスターグリッドに対応する制度を伴う14ビット整数である。部分導関数は、サブラスターグリッドのスケールで演算される。
【０３０２】
多角形のオフセットは下記により与えられる。
オフセット＝8×係数×Ｍａｘ（｜δＺ｜δＸ｜δＹ｜）＋（ｒ×ユニット）
「係数」はＳＲＴブロックから渡される。（ｒ＊ユニット）オフセット部分はＧＥＯ内でケアされる。我々は、ＳＴＰ内でのみ最初の項を演算する。傾きの度合いを説明するために８による乗算が行われる。深度値は24ビット整数として表される。オフセットは各頂点ｚ値に加えられる。算出されたオフセットは、ｚ値に加えられる前に24ビット（実際にはｓ２４）にクランプされる。
５．６．２．４  四辺形頂点生成
我々は、線セグメントを幅ｗの平行四辺形に変換する。我々は、一致するエンドポイントを持つ線などのエンド上の線を廃棄する。エンド上の線の非廃棄により、線に対して幅ゼロの四辺形が生成される。本四辺形の生成は不要なパケットのパイプを通じて送信を生じさせ、まれな場合には、VSPさえも発生し、異常なピクセルの照度をもたらす。オフセットのカップリング及びディスクリプタへの頂点の割り付けのプロセスは以前に示したが、非常に直覚的である。アーキテクチュア上のパイプラインスルーは、可能なピットフォールを監視することを要求する。線のエンドポイントが与えられ、下記のようにトリゴメトリックを算出する。
run=|(x1-x0)|:rise=|(y1-y0)|;
tan(a)=rise/run;
cos(a)=1/sqt(1+tan(a)*tan(a))：
sin(a)=tan(a)/sqt(1+tan(a)*tan(a));
我々は線の幅をｗと想定し、エンドポイントにおける水平及び垂直頂点の遷移は、図４２及び４３に示されるようにそれぞれｘｈｗ及びｙｈｗにより与えられると想定する。次に４つの四辺形の頂点が下記のように割り付けられる。
V[0]＝（ｘ０−ｘｈｗ、ｙ０＋ｙｈｗ）；V[1]（ｘ０＋ｘｈｗ、ｙ０−ｙｈｗ）；
V[2]＝（ｘ１−ｘｈｗ、ｙ１＋ｙｈｗ）；V[３]＝（ｘ１＋ｘｈｗ、ｙ１−ｙｈｗ）；
Xhw及びｙｈｗとそれに続く四辺形の演算は、線の方角及びそのアライアシング状態に基づいて行われる。図４９に線の方向に基づいた四辺形割り付けを示す。
【０３０３】
線が位置する四辺形は、（ｘ０、ｙ０）に対する（ｘ１、ｙ１）の相対位置を見ることによって決定される。ｘｈｗ、ｙｈｗ、及び四辺形用の原線ディスクリプタが決定される。本発明者らは、StrtClipX,StrtClipY、EndClipX,EndClipY,OpX,及びOpYのアサイメントもここに加えた。これら６つのパラメータは、点描線の処理中に使用される。StrtClipX,StrtClipY,OpX,及びOpYは、完全にタイルの外側にある全ての点描セグメントの初期除去中に使用される。OPSに伴うEndClipX,EndClipYは、いつ線がタイルを励起するかを決定するのに使用される。
【０３０４】
本処理は、さらなる処理のために、我々に四辺形用の頂点及び原線ディスクリプタを与える。
５．６．２．５  点描線処理
本規格中の他の場所に概要を示すように、点描線処理には２つのステージがある。最初にタイルに接触していない点描セグメントを取り除き、新たな開始点描ビットを計算する。次に、線を横切って点描内の１ビットの列に対応する線長を生成する。四辺形頂点生成が我々に半値幅の遷移を提供してくれたものと想定する。最初のステップは、ガードバンドによりエッジを遷移した後に線のタイル境界との交差点を探し出すことである。SRTブロックが我々に対してタイルに接触している線のみを送信することに注目する。従って、スロープなどに基づいた線の三重リジェクションをチェックする必要がある。StrtClipX,StrtClipY,OpX,及びOｐYは前節で入手されている。
【０３０５】
一旦交差点(xint,yint)が演算されると、与えられた開始点と交差点の間にわたる点描パターンビットの数を見つける。本stplStartは、ｎビットに加えられ、考慮のために必要な現点描を見つけるのに低位の4ビットが必要である。StplRepeatStartは、変更されないままである。線の開始点は、「ｎビット」点描パターンビットの収容に使用される線の長さにより遷移する。
【０３０６】
本発明者らは、よりタイトなクリッピングを行い、新たなstplRepeatStartを生成することもできたことに注意するべきである。本手順は、最良の場合は最大で追加四辺形の１処理をセーブするので、行われることはない。この利点がハードウェアコストを増加することはない。
【０３０７】
我々はここで、線セグメントを横切り、最初のビット用のstplRepeatStartにおいて開始する更なる繰り返し係数を用いてstplStartビットから点描パターン内の１ビットの各走行用の四辺形の生成を開始する。実施例について考える。StplStartが１４でstplRepeatが５でstplRepeatStartが４の場合、我々は、15番目のビット（例えば点描パターン内の最終ビット）に移る前に１４番目のビットをサンプルパターンで一回塗る。14番目及び１５番目のビットの双方が設定されたら、0番目の点描ビットは設定されず、四辺形線セグメントは６の長さを持つ。擬似コード内のXscale及びYscaleは、点描線の前処理中にサブルーチンDoStippleClip内で先に演算されたそれらと同じものである。
【０３０８】
一度得られた線セグメントエンドポイントは、実線として収容可能である。全ての四辺形に共通のパラメータが一度だけ演算されれば済むように、マイクロアーキテクチュアに最適化が導入される。深度の傾き、線スロープ、深度オフセット、及びｘｈｗ、ｙｈｗは全ての点描四辺形に共通であり、それゆえ一度だけ生成すれば良い。
５．６．２．６  タイル境界にクリッピングされた四辺形
最小ｚ及びCULブロック内でMCCAM選別に必要なバウンディングパラメータを得るために、我々は現タイル上の原線の交差を考慮する必要がある。我々の統一された原線表現において、我々はさらに一般化された四辺形を使用して三角形を表現する。我々は、原線クリップディスクリプタを使用してタイル上の原線の交差を表す。これらディスクリプタは、タイルの４つのエッジ及び交差が有効な値を作成したかを示す有効な添付フラグを持つ原線の交差点である。クリップディスクリプタのネーミングを図５０に示す。下記の各項に原線のタイルへのクリッピングに使用されるアルゴリズムの詳細を示す。
５．６．２．６．１  頂点クリップコードの演算
我々は先ず、各原線の頂点に対してクリップコードを演算する。クリップコードは、図５０に示すように頂点に割り付けられており、各頂点に対して下記のように得られる。
【０３０９】
【数１３】
0003657518.tif 000016
５．６．２．６．２  交差の演算
我々はクリップコードを使用してクリッッピングされる必要のあるエッジ及び目標境界を決定する。考慮されている原線は凸面である。各タイルエッジは半平面を定義し、それゆえ我々は各エッジにおいて２つまたは0個の交差するポイントを持つ。
【０３１０】
上部タイルエッジ上でのクリッピングは、上部タイルエッジ上の左右のクリップ頂点であるlLeft及びlRightを生じる。
【０３１１】
下部タイルエッジ上のクリッピングは、上部エッジ上のクリッピングと同様に実行される。下部エッジクリッピングはｂLeft及びｂRightすなわち、左下部及び右下部のクリップ頂点を生じる。
【０３１２】
左右エッジクリッピングは、ｘに分類された頂点を使用して左エッジに高及び低交差するポイントlLow及びlHighを、右エッジにrLow及びrHighを生じる。左エッジに対する手順は、下部エッジと同様であり、右エッジに対する手順は、上部エッジと同様であることに注意する。我々がスロープディスクリプタの代わりに逆スロープディスクリプタを使用していることにも注意する。
【０３１３】
左タイルエッジ上のクリッピングは、右タイルエッジと同様に行われる。左エッジクリッピングの出力は２点lLow及びlHighである。
【０３１４】
我々はここで、８点全て、つまりlLeft、lRight、ｂLeft、ｂRight、、lLow、lHigh、rLow、及びrHighを入手する。
５．６．２．６．３  交差ポイントの有効化
最初に交差ポイントを有効化してそれらが正しい範囲にあることを確認する。例えば、上部タイルエッジを持つ交差ポイントは、両方ともタイルの左側である可能性がある。この場合、交差ポイントは無効とマークされる。エッジを持つ交差が1つまたは両方のタイル上部コーナーを含む場合、有効な新しい交差ポイントが生成される。
【０３１５】
交差ポイントのいずれもが有効でない場合は、原線は廃棄される。ほとんどの場合、タイルの外側に位置する三角形はSRTブロックにより廃棄される。しかしながら、まれなケースでは、そこにおける頂点の１１．３へのスナッピングが幾つかの曲がりくねりの原因となる長く細い三角形のような完全にタイルの外にある三角形を我々が得ることもある。この場合、有効なフラグが我々に三角形を廃棄することを許可する。
５．６．２．６．４  ウィンドウの外側の四辺形頂点
ウィンドウのエッジにおけるタイル上の広い線により、一つ異常の算出された値がウィンドウ範囲の外側に位置することが可能である。Setupは、余分な座標範囲の2ビット（１つは負の値を許可し、１つは大きさの範囲を増加する）をキャリーすることにより上記の状態を処理することができる。CULブロック（ｘ座標に対して１４．２）に送信されるデータの範囲及び精度はウィンドウ範囲内の点を定義するに十分である。CULブロックがSetupから入手するデータは左右のコーナー・ポイントを含む。四辺形頂点がウィンドウ範囲の外側に落ち込むケースでは、Setupは下記値をCULに渡す。
・  tRightxがウィンドウ範囲の右側の場合は、右ウィンドウエッジへのクランプ
・  tLeftxがウィンドウ範囲左側の場合は、左ウィンドウエッジへのクランプ
・  v[VtxRightC].xがウィンドウ範囲の右側の場合、例えば右タイルエッジを右コーナーとして頂点rLowを送信する。
・  v[VtxLeftC].xがウィンドウ範囲の左側の場合は、左タイルエッジ上の下部クリップポイントなどのlLowを左コーナーとして送信する。
本処理は、図５１に図示されている。
【０３１６】
三角形がジオメトリによって有効なウィンドウ範囲にクリッピングされることに注意する。我々が配慮しなければならないのは、広い線に対して生成される四辺形だけである。Cullは、ラスタ画像処理中にスパン及び点を計算しているばあいに、エッジ歩行中の範囲外のx値の原因となるオーバーフローおよびアンダーフローを検出する必要がある。オーバーフローまたはアンダーフローが起きた場合、ｘ範囲はタイル範囲内でクランピングされなければならない。
【０３１７】
我々はここで、クリッピングされた点と有効なフラグを得た。我々はここで、zmin、バウンディングボックス、及び参照スタンプの演算へと進むことができる。
５．６．２．７  バウンディングボックス、最小Z及び参照スタンプ決定
バウンディングボックス、zMin、及び参照スタンプ値の演算のために、我々は原線のタイルとの交差を使用する。我々は、タイル内に位置する原線の一部に対して最小Z値を演算する。境界への原線のクリッピングは、Cullブロック内MCCM選別に対するZminのタイトな評価を得るために重要である。
５．６．２．７．１  バウンディングボックス演算
原線交差のバウンディングボックスはクリッピングされた頂点を検査することによって決定される。我々は最初にバウンディングボックスをタイル境界に初期化し、次にエッジクリップ点を検査することによりタイル内へと移動する。
【０３１８】
我々はここで、バウンディングボックスを得た。これらxmin,xmax,ymin,ymax pixel座標はスタンプ座標へと変換する必要がある。本処理は、先ず座標をタイル関連の値に変換し、次に３つの高位ビット（例：１ビットにより右シフト）を考慮することにより完了する。xmax（及び/またはymax）がタイルのエッジ上にある場合を除いてはこの処理は効果的である。その場合、我々はシフティング前にxmax（及び／またはymax）を１だけ増加させる。
５．６．２．７．２  最小Z演算
我々はここで、原線のタイルとの交差に対する最小ｚ値を演算した。我々は、８つの交差ポイント及び、クリッピング演算に含まれていない可能性があるために、頂点i1を考慮する必要がある。深度演算は高価な動作であり、それゆえ我々は実行すべき深度演算の回数の最小化を望んでいることに注意すべきである。ｘおよびｙ内の部分的な導関数の符号を検査することにより、我々は、原線が完全にタイルをカバーしている場合には、最小深度値に対応するタイルコーナーを検出することができる。一旦タイルコーナーを決定すると、我々が必要なのは、2つの最も近いクリッピングされた点における深度値を演算することだけである。頂点i1におけるｚ値に伴うこれら２つの値は、最小ｚ値を提供する。
【０３１９】
我々はここで、最小ｚ値及びそれを得たクリップ頂点を知った。Z値は、CULに送信される前に２４ビットにクランピングされる。我々はここで、参照スタンプ及び参照ｚ値を演算する。
５．６．２．７．３  参照スタンプ及び参照Z演算
原線の各頂点に対してZataiを渡す代わりに、Setupは原線内の特定の点におけるZ値を表現する単一のZ値を渡す。Setupは、最小ｚを持つ頂点を含む参照スタンプを選ぶ。我々は、頂点座標を整数値に切り上げ、対応するスタンプを検出することにより本処理を完了する。右のエッジ上の頂点の場合は、参照スタンプが演算される前に、ｘ座標は減じられる。Logicが参照スタンプを識別するために使用さる。
【０３２０】
参照スタンプは、チップ頂点のｘ及びｙ座標に増分値を加え、ｘ及びｙ値を最も近くにある偶数に切り上げて含まれているスタンプを検出することにより識別される。
【０３２１】
参照Z値ZrefTileは参照スタンプの中央で計算される。Setupは、タイル内の位置を指定する３ビット値のペアｘrefStamp及びｙRefStampにより参照スタンプを識別する。参照スタンプはスタンプ内のタイルのコーナーからのオフセットとして識別されることに注意するべきである。
【０３２２】
我々は、スクリーンスペース内のオフセットを得るために、８（スタンプ内のサブピクセルの数）で乗算を行わなければならない。
【０３２３】
【数１４】
0003657518.tif 000017
我々はここで、三角形及び平行四辺形の処理に必要な全てを得た。
５．６．２．８  点処理
点の場合は、下記を検出する（図５２参照）。
CY7（タイル座標内のタイルの上部エッジにクリップされる円の最上部の点）
CY8（タイル座標内のタイルの下部エッジにクリップされる円の最下部の点）
Yoffset(CYTとクリッピングされていない円の下部の間の距離)
X0（ウィンドウ座標内の中央のX座標）
点に対する必要な計算中では、我々は、０．０から１６．０の範囲を持つ関連ｙ値用の８ビットを使用することに注意する。本処理は５整数ビットを必要とする。ピクセルあたりの８サブレスターに対して３少数ビットが考慮される。
５．６．２．８．１  無限ｄｘ/ｄｙ
無限ｄｘ/ｄｙは、エッジが完全に水平であることを暗示している。水平エッジの場合は、２つのエンドポイントの内の一つがコーナー頂点（VtxLeftCまたはVtxRightC）になるはずである。座標がウィンドウ範囲にある原線では、Cullは無限スロープを利用しない。なぜならば、Cullのエッジ歩行アルゴリズムでは、左及び／または右コーナーの頂点の値から、Cullがすでにコーナーを回っており、水平エッジに沿って歩く必要は全くないということが分かる。
【０３２４】
不都合なことには、四辺形の頂点がウィンドウ範囲の外側に落ち込んだ場合は、我々は、特に非アンチアライアスド線の場合に、軽微な問題に遭遇する。右上部のコーナーがウィンドウ範囲の外側にある非アンチアライアスド線を考慮する。RightCは次にｒLowクリップポイントに移り、Cullのエッジ歩行は水平エッジのコーナーを曲がることは考えず、ｔRight（またはｔLeft）のスパンエンドポイントを計算する。
【０３２５】
この場合、Cullのエッジ歩行はスロープを必要とする。エッジ歩行の開始点はウィンドウの最も端にあるために、エッジ歩行が現在符号が付加されているスロープにより計算するXがオーバーフロー（またはアンダーフロー）の原因となり、Xは単にウィンドウエッジにクランプバックされる。従って、どのようなスロープの値を使用しているかは、それが正しい符号を持っている限り、実際には重要ではない。
【０３２６】
無限の値も、Setup自身によるスロープの利用の上では重要ではない。Setupは、スロープを使用してタイルエッジを含む原線のエッジの交差を計算する。交差の計算で使用する等式は、X=X0＋△Y*dx/dyである。この場合、無限のdx／dyが必要なゼロの△Yを含む。従って、ｄｘ/ｄｙの値は重要ではない。
【０３２７】
Setupは、内部的に浮動小数点フォーマットでスロープを計算する。無限結果が起きた場合には、浮動小数点ユニットが無限大フラグを出す。Setupは無限スロープを気にせず、Cullは無限スロープの大きさを気にしないが、符号は気にするため、我々は実際に無限大を表す必要はない。正しい符号を決定するわずらわしさを解消するために、Setupは無限スロープをCull上に渡す前に強制的にZEROに設定する。
５．７  Cullブロック（CUL）
５．７．１  CULブロックの機能概要
Cullユニットは次の処理を受け持つ。１）事前シェ−ディングをしている隠れた表面の除去、及び２）原線ジオメトリのエンティティー（三角形、線、及び点）を可視スタンプポーション（VSP）と呼ばれるスタンプベースのジオメトリエンティティーへの分解である。Cullユニットは、一般的に、隠れた表面の保存性選別を行う。Cullは、アルファテスト及びステンシルテストなどの一部「フラグメント動作」を扱わないため、隠れた表面を取り除くだけである。Cullブロックのサンプルzバッファは２つの深度値を持つことができるが、Cullブロックは各サンプルごとに原線の属性を保存するだけである。このように、サンプルが２つのジオメトリから混合する色を必要とする場合は、両混合ジオメトリを隠す後続のジオメトリが存在する可能性がある場合でもCullは最初の原線を（タイムオーダーを使用して）パイプラインに送り込む必要がある。
【０３２８】
Cullユニットは、Setup Output Primitiveパケットを受信する。受信するパケットの各々は、タイルごとに三角形、線、またはポイントを表す。Sortは、入りジオメトリエンティティーをタイルに貯蔵するユニットである。Setupは、隠れた表面の除去のためにより詳細なジオメトリに関する情報をCullに提供する目的で原線を前処理するユニットである。Setupは、全てのエッジ、タイルを持つ原線のバウンディングボックス、タイル内原線の最小深度値（一番前）及び他の関連データの前計算を行う。Sortに先立ち、Mode Extractionはすでにカラー、ライト、テクスチャ、及び関連モードデータを抽出している。Cullは、Cull及びPolygonメモリ内に保存されたカラー、ライト、及びテクスチャデータをポイントするColorポインタと呼ばれるポインタに関連するモードデータを取得するだけである。
【０３２９】
Cullユニットは一度に１つの可視スタンプポーション (VSP)をMode Injectionユニットに送信する。Mode Injectionは、VSPをそのカラー、ライト、及びテクスチャデータと再結合し、パイプライン内のFragment及び後続のステージに送信する。
【０３３０】
Cullユニットは２つの主な機能を実行する。一次機能は、フレームバッファの最終結果に影響を及ぼさないように保証されたジオメトリの除去である（例；保存ベースの隠れた表面の除去）。第二の機能は、スタンプポーション（SP）単位への原線の分解である。スタンプポーションは、原線の与えられたスタンプとの交差である。ポーションの量はサンプリングにより決定される。いずれのスタンプも、１６の事前に決定されたサンプルポイントを持つ（実際には、スタンプ内の各ピクセルは４つの事前に決定されたサンプルポイントを持つ）。次に、ポーションの「サイズ」が数字で与えられ、与えられたスタンプ内でサンプルポイントが原線にカバーされる。
【０３３１】
Cullは一度に１タイルの原線を処理する。しかしながら、現フレームの場合は、パイプラインは次の２つのモードのいずれかで動作する。１）Time Orderモード、または２）Stored Transparencyモードである。Time Orderモードでは、頂点及びモードのタイムオーダーは各タイルと共に保存され、タイルはデータを通じて単一のパス内で処理される。すなわち、与えられたタイルでは、頂点及びモードが書き込み時と同じ順序で読み出されるが、現タイルに影響を与えない場合にはスキップされる。Sorted Transparencyモードでは、各タイルの処理は複数のパスに分割される。最初のパスでは、保証された不透明ジオメトリが処理される（Sortブロックは本パスに対して非透過ジオメトリを送信するだけである）。後続のパスでは、潜在的に透過なジオメトリが処理される（Sortブロックは、各パスに対して全ての透過ジオメトリを繰り返し送信する）。各パス内では、タイムオーダリングが保存され、モードデータが本パスの正しいタイムオーダー箇所に挿入される。
【０３３２】
Time Orderモードでは、タイル内に「単純不透明ジオメトリ」(例：しザーステスト、アルファテスト、カラーテスト、ステンシルテスト、ブレンド、またはロジコプなし)しかない場合は、Cullは、Mode Injectionに対していずれのVSPをもディスパッチするまえに、タイル内の原線を処理する。なぜならば、Cullの隠れた正面の除去アルゴリズムは、各サンプルに対し、そのサンプルをカバーする原線（例：カラー）を明確に決定するためである。
【０３３３】
Time Orderモードでは、入力ジオメトリがタイル内で「単純不透明ジオメトリ」に限定されていない場合は、VSP（VSPの全セットまたは選択されたVSP）の配列ディスパッチが必要となる場合がある。しかしながら、別のタイルのVSPのディスパッチが可能になる前に与えられたタイルの全VSPは例外なくディスパッチされる。一般的に、1つ以上のジオメトリが、いずれかのサンプルに対して（ピクセル内の）最終タイル値に影響を与え得る場合は、早期のディスパッチが必要になる。
【０３３４】
Sorted Transparencyモードでは、各タイルは複数パス内で処理される（同タイル内に少なくとも幾つかのジオメトリがあるものと想定）。各パスにおいては、VSPの早期ディスパッチはない。
【０３３５】
入力パケットが原線パケットの場合、PrimTypeパラメータが原線タイプ(三角形、線、または点)を示す。すなわち、パケットは原線を平行四辺形として表し（スクリーンには合わせない）、三角形及び点として表すのは縮退の場合である。ここで、「統一された表現」は、「Setup Output Primitiveパケット」の節で詳細に述べられている。このパケットは、Mode Injectionが使用するカラーポインタを含む。このパケットは、その多くが各原線ごとに変化できる幾つかのモードビットも含む。次のものが「モードビット」と認識され、Z Cull状態マシーンに入力される。CullFlushCurrent、DoAlphaTest、DoABlend、DepthFunc、DepthTestEnabled、DepthTestMask、及びNoColorである。
【０３３６】
原線に加えて、Cullは次のパケットタイプを受信する。Setup Packet Clearパケット、Setup Output Cullパケット、Setup Output Begin Frameパケット、  Setup Output End Frameパケット、Setup Output Begin Tileパケット、及びSetup Output Tweenパケットである。これらパケットタイプの各々は、後続の節で詳細に述べられている。しかしながら、これらパケットは総体的に「モードパケット」として知られる（確実に惑わされ易い名前である）。
【０３３７】
Setup Output Clearパケットは、ある種のバッファクリアが行われることを示している。しかしながら、ユーザフレームの開始時の（そしてシザーステストを受けない）バッファクリアは、開始タイルパケットに含まれる。
【０３３８】
Setup Output Cullパケットは、モードビットのパケットである。本パケットは、次の処理用のビットを含む。１）MCCM Cull及びZ Cullプロセスの有効化／無効化、２）Cullブロックから全VSPを洗い流すビットCullFlushAll、及び３）３タイプの原線のアンチアライアシングを無効化するAliasPolys、AliasLines、及びAliasPointsである。
【０３３９】
Setup Output Begin Frameパケットは、Cullに対して新たなフレームが開始中であることを伝える。次のパケットはSort Output Begin Tileパケットである。Setup Output Begin Frameパケットは、パイプライン全体を通じて必要な全てのフレーム前情報を含む。
【０３４０】
Setup Output End Frameパケットはフレームが終わり、現タイルの入力が完了したことを示す。
【０３４１】
Setup Output Begin Tileパケットは、Cullに対して現タイルが終わり、処理されたデータがパイプラインに洗い流されることを伝える。同時に、本パケットは新たなタイルの原線の処理を始める。パイプラインがSorted Transparencyモードにあるためにタイルを繰り返さなければならない場合には、このタイルは他のSetup Output Begin Tileパケットを必要とする。従って、特定なタイルが不透明なパスと4つの透過パスを必要とする場合、合計５つの開始タイルパケットがSetupから送信される。本パケットは、ウィンドウ内のタイルの位置を指定する。
【０３４２】
Setup Output Tweenパケットは、実際にはタイル間であるフレーム間（‘tweenと略）で生起する。Culは、このパケットを空のボックスとして扱い、単にパイプライン内を送信する。このパケットは、１つのパラメータ、１４４ビットのTweenDataしか持たない。
【０３４３】
図５３にCullブロックの基本ブロック図を示す。
【０３４４】
原線を受信すると、Cullは、原線のバウンディングボックスを持つMCCA９００２に問い合わせて受信した原線を除去しようとする。MCCAMが原線が完全にタイル内に隠れていると伝えてきた場合は、原線は捨てられる。MCCAMが原線を完全に拒絶できない場合は、スタンプリスト生成する。リスト内の各スタンプは、目に見える可能性のある原線の一部を含むことがある。この潜在的に可視なスタンプのリストは、Cullのスタンプ選択ブロック９００８に送信される。スタンプ選択ブロックは、原線のジオメトリデータを使用して、実際に原線が接触するタイルの各スタンプの配列内のスタンプのセットを決定する。MCCAMが提供するスタンプリストとの組み合わせで、スタンプ選択ブロックは、一度に1つの潜在的に可視なスタンプ９００６をZ Cullブロック９０１２に向けてディスパッチする。各スタンプは１６×１６サブピクセルの格子に分割される。各水平格子線は、サブラスター線と呼ばれる。スタンプごとの各１６サンプル点は、２５６の予想されるサブピクセル位置の内の一つの中心で（アンチアライアスド原線に対して）落ち込む。各ピクセルは、その境界内に４サンプル点を持つ。原線に接触するスタンプの配列内のスタンプのセットの決定には、少なくとも１サンプル点を含む各サブラスター線内原線の最も左または右の位置の計算が関係する。我々は、これら最も左及び右の位置をXleftSubSi及びXrightSubSiと呼ぶ。これらは、それぞれサンプルｉに対するｘ最左サブラスター線及びｘ最右サブラスター線を表す。サンプルは０から１５に計数される。XleftSubSi及びXrighSubSiの決定は、特にエッジ歩行プロセスと呼ばれる。我々がエッジ（ｘ０、ｙ０）上の点を知っている場合は、ｙ１のｙ位置に対応するｘ１の値は下記により簡単に決定できる。
【０３４５】
【数１５】
0003657518.tif 000018
スタンプ番号に加えて、１６のXleftSubSi及びXrighSubSiのペアのセットもスタンプ選択ブロックからZ Cullに送信される。
【０３４６】
Z Cullユニットは一度に１つのスタンプ番号（またはStampID）を受信する。各スタンプ番号はMCCAMの決定により可視の可能性がある原線のポーションを含む。１６のXleftSubSi及びXrightSubSiのペアのセットは、我々に対して１６サンプル点の内のいずれが原線によってカバーされるかの選択を可能とする。サンプルｉのｘ座標値Xsampleiが下式を満足すると、サンプルｉはカバーされている。
【０３４７】
XleftSubSi×Xsamplei＜XrightSubSi
カバーされた各サンプルに対して、我々は、そのサンプル点において原線のｚ値を計算する。同時に、１６サンプル点全てに対する原ｚ値及びｚ状態がサンプルｚバッファから読み出される。各サンプル点は、「保存性」または「正確」のｚ状態を持つことができる。Cullが受信するモードビットと組み合わされたｚ状態は、サンプル有限状態マシンを駆動する。各サンプル点は、他のサンプルから独立したFSMを持つ。状態マシンは、原線のｚ値及びｚバッファのｚ値間でサンプルごとの比較を制御する。比較結果は、新たな原線が原線がカバーする各サンプル点において見えているか隠されているかを決定するのに使用される。原線が見えるサンプル点を持っている場合、可視サンプルパターンが新たなVSPカバレッジマスク内に作成される。サンプルのピクセルFSMも、ｚバッファがどのように同サンプルのために更新されるべきか、及び新たなVSPのサンプル点が早期にディスパッチされるべきであるかを決定する。なお、上記FSMは、間違いなくサンプルポイントであるいずれかの旧VSPが、破壊されるべきか、早期にディスパッチされるべきかを決定する。これらのサンプルごとの制御信号は、Z CullによるSendNew、KeepOld、及びSendOldとして生成され、スタンプオプションマスクユニット９０１４に送信される。ピクセルの制限状態用の状態テーブルはアーキテクチュアの規格に記されているため、ここでは繰り返さない。最大１６個のサンプルポイントのｚ値は、MCCAMを更新するのに使用される。
【０３４８】
分類された透過性はZ Cullの追加的発行を提示し、サンプルzバッファに対してZfar及びZnear値に関する議論をもたらす。Sorted Transparencyモードでは、我々は、透過な原線に対し、タイムオーダーのラスター画像処理の通常モードの代わりに一番前面にある不透明層に最も近い層から空間オーダーでラスター画像処理されることを望む。本処理は、タイル用の透過原線がCullユニットを数回通り抜けることを要求する。最初に、Sortユニットは不透明原線のみを送信する。ｚ値は前項で説明されているように更新される。我々は、タイプZtarの不透明原線に対してｚ値を呼び出す。パスの最後には、不透明VSPがディスパッチされる。二回目のSortは、タイル用の透過原線をCullに送信するだけである。最初には、ZバッファのZnearポーションは、考えられる最小の値にプリセットされる。Zfarの後ろにあるｚ値を持つサンプル点は隠されているが、Zfarの前、Znearの後ろのｚ値は不透明に近く、それゆえ現Znearのｚ値を置き換える。パスの最後では、我々は不透明層に一番近い層のｚ値を持つ。不透明な層に一番近いことを表すVSPがディスパッチされる。Znear及びZfarの役目は入れ替えられ、Z Cullは透過な原線の２番目のパスを受信する。本プロセスは、Z Cullが透過な原線の全ての可能な層がそれ自身により処理されたと確定するまでは続けられる。分類された透過モードのZ Cullもまたピクセル制限マシンにより制御される。
【０３４９】
スタンプポーションマスクブロックは、タイル内の各スタンプに対してVSPカバレッジマスクを持っている。スタンプが保有できるVSPの数は、１６までである。Z Cullから新たなVSPが来た場合は、VSPマスクは更新または早期ディスパッチが必要になる。スタンプポーションマスクブロックは、厳密にSendNew、KeepOld、及びSendOld制御信号によりマスク更新またはディスパッチを行う。新VSPが潜在的にスタンプ内の全旧VSPのカバレッジマスクの変更能力を持っているため、最大16個の旧VSPの更新が同時に起るはずである。スタンプポーションデータブロック９０１６は、カラーポインタも含むVSPに伴う他の情報を含んでいる。スタンプポーションデータメモリもタイルに含まれる全VSP用のデータを持つ必要がある。新VSPが作成されると、それに伴うデータがメモリに保存される必要がある。旧VSPがディスパッチされると、そのデータがメモリから検索される。
５．７．２  Cullブロック機能詳細
Cullブロックは次のサブユニットにより構成される。1)入力FIFO、２）MCCAM Cull、３)Sibrasterizer、４）行選択、５）Z Cull、６）MCCAM更新、7)新VSPキュー、８）Stamp Portionメモリマスク、9)Stamp Portionメモリスタンプポーションメモリデータ、１０）ディスパッチキュー、及び１１）ディスパッチロジックである。これらサブユニットを下記の各節で説明する。
【０３５０】
図５４にCullサブユニットのブロック図を示す。
５．７．２．１  入力FIFO
入力FIFOサブユニット９０５０は、Setupユニット８０００とインタフェースする。本サブユニットはSetupからデータパケットを受信し、各パケットをキュー内に収容する。必要なFIFOメモリ場所の数は、１６から３２の間であるが、ここでは我々は、深度を１６と仮定している。
５．７．２．２  MCCAM Cull
MCCAM Cullサブブロック９００２は、Spatial Addressableメモリ（MCCAM）を使用して原線のバウンディングボックス上で空間的問い合わせを行うことによりバウンディングボックス内の可視の可能性があるスタンプのセットを決定する。Z比較のために本サブブロックが使用する値は、ZminTileである。MCCAM Cullは、入力FIFOから１サイクルにつき１つの原線を処理する。FIFOが空でなく、取り除かれた最後の原線がMCCAM Cullで決定されたごとく完全に隠されているか、または最後の原線が現在Subrasterizer９５０５２により処理されている場合には、FIFOからの読み出し動作が実行される。すなわち、MCCAM CullはSubrasterizerの「ワーカヘッド」にはならない。むしろ、本サブユニットはSubrasterizerが処理する必要のある次の原線を得て、その後待ち状態に入るだけである。
５．７．２．３  スタンプ選択ロジック内Subrasterizer
サブラスタライザ９０５２は、エッジ歩行を実行するサブユニットである（実際の演算は、「歩行」の語が示唆するようにインタラクティブではない）。スタンプの各列はMCCAM Cullはスタンプの各列が潜在的に可視であることを示している。本サブユニットは、16個のサンプル点の各々に対してXleftSubi及びXrightSubiを同時に計算する。各XleftSubi及びXrightSubiのペアは、原線に接触される列内のスタンプのセットを指定する。Subrasterizerは、サンプル点が位置する各サブラスタ線に対してスタンプの列内で接触されるスタンプのセットを決定し、１つの接触されたスタンプのリスト内に接触された１６セットのスタンプを組み合わせる。Subrasterizerは、各スタンプの列のために要求をMCCAM Cullに渡し、可視スタンプリストを受信する。可視スタンプリストは、接触されたスタンプリストと組み合わされ、それによりスタンプ列内の最終潜在可視スタンプリストが決定される。各列に対しては、可視スタンプセットがStamp SelectionロジックのColumn Selectionポーションに送信される。Subrasterizerは、各サイクルごとに１つのスタンプの列を処理できる。原線が１つ以上のスタンプの列を含んでいると、Subrasterizerは、１サイクル異常を費やしてその原線を処理し、それゆえMCCAMに対して入力FIFOからの原線の除去を中断するように要求する必要がある。Subrasterizer自身は、Column Selectionユニットからの要求に従って中断することができる。
５．７．２．４  Stamp Selectionロジック内カラム選択
カラム選択サブユニット９０５４はZ Cullユニット９０１２に対して各クロックサイクル内で処理するスタンプを伝える。
５．７．２．５  Z Cull
Z Cullサブユニット９０１２は、サンプルｚバッファを含む。Subrasterizerが計算したXleftSubi及びXrightSubiに基づき、このサブユニットは原線にカバーされるスタンプ内のサンプルポイントのセットを決定する。このサブユニットは次に、それらのサンプルポイントにおいて原線のｚ値を計算し、結果のｚ値を上記スタンプ用のｚバッファ内に保存された対応するｚ値と比較する。この比較の結果、現Cullモードビット、及びサンプル状態マシンの状態に基づいてｚバッファが更新される。各サンプルに対して、Z Cull内の制限状態マシンが次のビットを生成する。OldSampleKeep、OldSampleSend、NewSampleMask、及びNewSampleSendである。NewSampleMaskビット（16個）のセットは新たなスタンプポーション（SP）カバレッジマスクを構成する。新SPがNewVSPキューにディスパッチされる。原線がスタンプ内で全く見えない事象（NewSampleMaskビットはFALSE）においては、NewVSPキューには何も送信されない。
５．７．２．６  MCCAM Update
MCCAM Updateサブユニット９０５６は、16個のサンプルポーションに対して最大16個の更新されたｚ値を決定し、MCCAMユニットに送信してMCCAMを更新する。
５．７．２．７  NewVSPキュー
Z Cullサブユニットは、クロックサイクルごとに各Stamp Portionに対して次の４つのビットセットを生成する。OldSampleKeep、OldSampleSend、NewSampleMask,及びNewSampleSendである。「理想的」な状況下では、SPM Mask&Validサブユニットは、各クロックサイクルで新Stamp Portionを保存する。しかしながら、VSPの早期ディスパッチが起きた場合は、SPM Mask&Validサブユニットは新Stamp Portion用に複数クロックを必要とする。本処理が起きると、NewVSPキュー９０５８は新スタンプポーションを保存し、Z Cullに中断せずに進むことを許容する。
【０３５１】
NewVSPキューは単純キューである。本キューは、早期ディスパッチのケースでのみ有用である。SPM Mask%Validユニットは、一度に１つのVSPしか扱えない。早期ディスパッチに１つ以上のVSPが関与しており、我々がNewVSPキューを持っていない場合、Z Cullユニットは動作を中断しなければならない。機能解析に基づき、我々はタイル内で接触されるスタンプを４５０持つことを期待する。深度の複雑さが２の場合、我々は各タイルに対してZ Cullから出てきた２２５のVSPを得ることを期待する。我々が見ることのできる手段は、平均でスタンプあたり約４VSPである。カバーする５０ピクセル領域をオンにしたブレンドを伴う三角形は、平均３タイル上で接触でき、タイル内で接触できるスタンプの数は８以下でなければならない。従って、我々はNewVSPキューの深度を３２とする。
５．７．２．８  SPM Mask&Valid
Stamp Portionメモリマスク及びValidサブユニットは、タイル用のVSPカバレッジマスクを含む。各VSPエントリは、そこに有効なVSPが保存されているかを示す有効ビットを必要とする。VSP用の有効ビットは他のメモリに保存されている。本サブユニットは、マイクロアーキテクチュアのブロック図に示すように二重バッファリングされている(例：２つのコピーがある)。活性状態ページは、現タイル用VSPを含み、一方ディスパッチ状態ページは最後のタイルのVSP（現在ディスパッチ中）を含む。新VSPがNewVSPキューからVSPが除去されると、活性状態SPM Mask&Validユニット９０６０は、そのマスクメモリにすでに存在するVSPに対してVSPMaskを更新し、新VSPをメモリの内容に加える。早期ディスパッチを必要とするカラー混合などの状況が発生した場合は、活性状態のSPM Mask&ValidはSPM Dataユニットを通じてVSPをディスパッチキューに向けてディスパッチする。マスク更新または早期ディスパッチの動作は、Z Cull内で生成されるOldSampleKeep、OldSampleSend、及びNewSampleSend制御信号が制御する。アクティブからディスパッチへの、またはその逆の状態遷移は、モードパケットが制御する。タイルのパケット信号送出の終わり（TRUEに設定されたCullFlushAllを伴うBegin Tile、End Frame、Buffer Clear、及びCull Packet）の受信は、タイルをアクティブ状態からディスパッチ状態への及び逆の切り替えの原因となる。ページインディスパッチ状態は、単純に各スタンプを通して循環し、全VSPをSPM Dataユニット９０６４へと送信する。本ユニットは受信したVSPをディスパッチキューへと進める。
５．７．２．９  SPMデータ
Stamp Portion Memory Dataサブユニット９０６４は、タイル内の各VSP用にZstamp、ｄｚ/ｄｘ、ｄｚ/ｄｙ、及びColorPointerを保存する。このユニットも二重バッファリングされている。SPM Mask&Validは、新VSP情報をSPM Dataへと送信し、それが新VSPを送信すべきかそのメモリにセーブすべきかを伝える。新VSPがセーブすべき場合は、SPM Mask&ValidはやはりSPM Dataに対して、１６の考えられるスポットの内のどの場所をVSPが占有すべきかを伝える。なお、早期ディスパッチの場合は、SPM Dataはやはり旧VSP及びそれに伴う早期ディスパッチを必要とするVSPMasksのリストを得る。SPM Dataブロックは先ずディスパッチする必要のある旧VSPがあるかをチェックする。そのようなVSPが一つでも発見できた場合は、本ブロックは単にそのメモリからVSPデータを読み出し、SPM Mask&ValidブロックからのVSPMaskと併合し、VSPをディスパッチキューに入れる。その後、このブロックは新VSPがやはり送信すべきかをチェックし、すべきであった場合は、本ブロックは新VSPデータをディスパッチキューに渡す。新VSPが送信すべきでない場合は、このブロックは新VSPデータをそのメモリに書き込む。
５．７．２．１０  ディスパッチキュー及びディスパッチロジック
このユニットは１エントリに相当するデータを２つのSPMディスパッチキューの内の１つからMode Injectユニットへと送信する。このユニットは、最初にディスパッチ状態SPMからディスパッチを試みる。Stamp PortionメモリがそのVSPを使い果たした後でのみ、本ユニットは活性状態SMPディスパッチキューからディスパッチを試みる
５．８  Mode Injecionブロック
５．８．１  始めに
Mode Injection(MIJ)ブロックは、Mode Extractionブロックとの結合により、グラフィックス状態及び関連情報を管理する。従来のグラフィックスパイプライン内では、状態変化は増加する。例：状態パラメータの値は、変更されるまでは有効である。従って、アプリケーションは変化したパラメータだけを更新すれば良い。さらに、描画は直線的である。例：原線は受信した順で描画される。点、線、三角形の細片、三角形の扇形、多角形、四辺形、及び四辺形の細片がグラフィックの原線である。このように、全ての状態変化は、原線に関する空間情報を受信するまではその原線の描画中有効である。
【０３５２】
本発明の一つの実施例中でAPEXパイプラインとして参照されているように、描画はタイルベースで行われる。Geometry(GEO)ブロックは原線を順に受信し、全ての頂点動作を行い、(変形、頂点ライティング、クリッピング、及び原線組み立て)、及びパイプラインを通してデータを送信する。Sortブロックは、タイムオーダーデータを受信し、同ブロックが接触するタイルにおいてそのデータを貯蔵する。(各タイル内では、リストはタイムオーダーとなっている。)CULブロックは、SRTブロックからタイル順にデータを受信し、接待に描画された画像に寄与することのない原線のパーツを選別する。CULブロックはVSPを生成する。VSPは、スタンプ上の多角形の可視ポーションに対応する。スタンプは画像の２×２ピクセル領域である。TEX及びPHGユニットは、VSPを受信し、それぞれフラグメントのテクスチャリング及びライティングする。Pixelブロックなどの最後のブロックは、VSP及びフラグメントのカラーを使用して最終的な絵を生成する。
【０３５３】
原線は多くのタイルに接触する可能性があり、それゆえ、従来の描画パイプラインと違って、フレームの描画中に何度も現れることがある（本原線が接触する各タイルにつき一回）。パイプラインは、原線がパイプラインを入力した時にグラフィックスの状態を有効に記憶し、SRTから下りてくるパイプラインステージの問い合わせを受けるたびに呼び出される必要がある。MEXは、暫定オーダー状態変更データを収集及びセーブするGeometryとSortブロック間のロジックブロックであり、適切なポインタを原線の頂点に付加して原線が描画される場合に、正しい状態に伴われる。
【０３５４】
Mode Injection(MIJ)ブロックは、状態ポインタ（MLMポインタ）が必要な時に状態などの関連情報の検索する。このブロックは、情報の適切な再パッケージングも行う。再パッケージングの例は、多角形メモリ内の頂点データが検索され、フラグメント用に原線（三角形、線、点）にバンドルされた場合に発生する。
【０３５５】
動作理論及びAPEX状態管理の背後にある一般原則はMEXブロックのアーキテクチュア規格中の論点となっている。多角形メモリ内の種々のデータパケットの構成もMEXブロック規格中で詳細に説明されている。我々は、本書の読者に対して先ずMEXブロックアーキテクチュア規格を通読することを推奨する。
【０３５６】
本明細書中で、我々は最初にMIJブロックの基本的要件を説明する。次に我々は、MIJブロックへの入力及び出力インタフェースについて論じる。機能詳細及びMIJブロックが使用するアルゴリズムの説明をその後に行う。最後に、我々は機能及びメモリ帯域幅要件を論じる。
５．８．２  MIJブロックの機能概要
前述したように、MIJはCULブロックからVSPパケットを受信する。各VSPパケットは、２×２ピクセルスタンプ上の原線の可視部分に対応する。CullブロックからMIJブロックに出力されるVSPは、原線によって順序付けられる必要はない。ほとんどの場合VSPは、例えば異なる原線に対するVSPがインタリーブされる可能性があるため、タイル上でVSPの走査順になっている。VSP内のフラグメントのライティング、テクスチャリング、及び構成のために、MIJブロックからのパイプラインステージの下流は原線の種類（例：点、線、三角形、線モード三角形）に関する、ウィンドウ及び目視座標などの原線のジオメトリ、ノーマル、カラー、原線の頂点におけるテクスチャ座標、及びPixModesなどの描画状態、TextureA、TextureB、Light、Material、及びStippleが原線に適用可能であか、といった情報を必要とする。この情報はMEXの多角形メモリにセーブされる。MEXは、ColorPointersもSortに送信される各原線に付加するが、このSortは、また原線のVSPの各々に渡される。MIJは本ポインタを復号化して多角形メモリから必要な情報を検索する。
【０３５７】
MIJはBeingFrameパケットをCULから受信した後でフレーム上での作業を開始する。フレーム用のVSP処理は、CULがフレーム内の最初のタイルの処理を終え、MIJが最初のタイル用VSPを受信すると開始される。
５．８．２．１  カラーポインタ復号化
カラーポインタは次の３つのパーツから成る。ColorAddress、ColorOffset、及びColorTypeである。（ColorPointer及びMLM_Pointerの詳細説明に関しては、モード抽出アーキテクチャ規格として参照される。）ColorAddresは、原線を完成するColorVertexをポイントする。ColorOffsetは、MLM_Pointerを含む二重八進数からColorAddressを切り離す頂点の数を提供する。ColorTypeは、原線のタイプ、各ColorVertexのサイズ、及びモード三角形用の有効なエッジに関する情報を含む。原線を作成するColorVerticesの長さは、２個、４個、６個、または９個の二重八進数である。MIJはColorPointerを復号化してMLM_Pointerを含む二重八進数及び全ての原線を作成性するColorVerticesのアドレスを得る。MLM_Pointerは、多角形メモリの６つの状態パケットの二重八進数アドレスを含む。
５．８．２．２  キャッシュ管理
５．８．２．２．１  問題概要
MIJブロックは、VSPがステージに到着する前にFragment、Texture、Phong、及びPixelブロックがVSP内フラグメントの処理に必要な全ての情報を持っているかを確認する。すなわち、原線のColorVerticesは、MLM_Pointer内のポインタにポイントされる６つの状態パケット同様に、それらを必要とするブロック内、VSPフラグメントが処理可能になる前に常駐していなければならない。MIJがMLM_Pointer、状態パケット、及びColorVerticesを各VSPに対して検索する場合は、MIJは各VSPに対してデータ１キロバイトの量になる。この量は、データ読み出しのための多角形メモリ帯域幅の１２５GB/秒に相当すし、FRG及びPIXブロックへのデータの書き出しに必要な量である。明確に、各VSPに対してデータを検索するのは不可能であり、何らかの形のキャッシングが必要になる。
【０３５８】
VSPと原線に何らかの結合があることを想定するのが合理的である。例えば、我々は同じ原線に対応する一連のVSPを得る可能性がある。我々はこの結合を使用して多角形メモリから読み出され、Fragment及びPixelブロックに転送されるデータの量を減少させる。原VSPが先行のVSPと同じ原線からディスパッチされた場合、我々がデータ検索を実行する必要は全くない。以前に指摘したように、VSPは原線順にMIJには到着しない。代わりに、それらはタイル上でVSP走査順になる。例えば、別々の原線に対する走査線を横切るVSPは、インタリーブされることがある。この理由により、現在及び前のVSPのみに基づいたキャッシングスキームは、帯域幅を約８０％カットする。他の計画はさらに優れた機能を提供する。例えば、タイルの、実際には四辺形タイルの、全面上の原線結合に有利なスキームなどを挙げることができる。明らかに、我々は、MIJ内のMLM_Pointer、各状態パーティション及びカラー原線に対してキャッシュを保つことによて上記スキームを実行することができる。各キャッシュのサイズは、それがタイル上に置かれる頻度によって決まる。このスキームが問題を解決できる、または多角形メモリからデータを検索している間は、我々はMIJからFragment及びPixelブロックへのデータが変化するたびにデータ転送を扱う必要がある。我々は、この問題を下記のように解決した。
５．８．２．２．２  キャッシュデータ及びタグの切り離し
MIJから検索されたデータは、他のブロックで使用される。従って、我々はキャッシュデータをこれらブロック内に保存する。Fragment、Texture、Phong、及びPixelブロックの各々がキャッシュのセットを持っている。これらキャッシュはそれらのキャッシュラインエントリに入る実際のデータを保持している。MIJはPolygonメモリからの各ユニットの関連データの検索及びユニットへの送信を行い、上述の４ユニット内のキャッシュの各々の現在の状態を知る必要がある。この処理は、各キャッシュに対してタグを保持し、MIJに対して全キャッシュの管理を容認することによって完了する。このように、キャッシュデータは、それを必要とするブロック内に常駐し、キャッシュタグはMIJ内に常駐する。
【０３５９】
MIJは７つのキャッシュを下流ストリームのために管理する。その内１つはFRG（ColorDataキャッシュ１００１６）用であり、TEX（TexA10018、TexB10020）、PHG（Light10024、Material10022）、及びPIX（PixMode1002６及びStipple１００２８）ブロック用に各２つづつである。これらキャッシュの各々に対して、タグがMIJにキャッシュされ、データが対応するブロックにキャッシュされる。MIJはまた、タグに従ってデータエントリのインデックスを維持する。これら７つのキャッシュに加えて、MIJは内部的に２つのキャッシュを効率のために維持する。その内１つはColorVertexキャッシュ１００１２であり、他はMLM_Pointerキャッシュ１００１４である。これらに対し、タグとデータの双方がMIJ内に常駐する。これら９つのタグキャッシュは、完全に結合可能であり、CAMｓを使用してChacheタグを調べる。これらキャッシュの一覧を図５５に示す。
【０３６０】
我々は、下記の各節でこれらキャッシュのキャッシングメカニズムを簡単に説明する。
５．８．２．２．３  修正FIFO入れ換えポリシー
MIJ内の全てのキャッシュに対して、我々は修正FIFOアルゴリズムを使用してキャッシュを入れ換える。本アルゴリズムでは、我々はキャッシュ内の各エントリのためにWashHitフラグをエントリタグと共に保持する。カウンタは、キャッシュ内で入れ換えられるべき現エントリを示すために使用される。
５．８．２．３  カラーキャッシング
「カラー」キャッシングは、カラー原線をキャッシュするために使用される。有効な処理機能のエクステントによって、多角形メモリ中のColorVertexの長さは２個、４個、６個、または９個の二重八進数となる。さらに、それぞれ点か、線か、または塗りつぶされた三角形かによって原線は１つ、２つ、または３つのColorVerticesを必要とする。他のキャッシュと違い、Color Cachingは、通常のキャッシュの調査及び入れ換えの問題に加えてデータサイズの問題に取り組まなければならない。
【０３６１】
たとえ多角形メモリ内の４分の１性能のカラー頂点が９個の二重八進数を占有していても、実際には我々は９個の二重八進数全部は必要としないことに注意するべきである。事実、４分の１性能ColorVertex内には１２００ビットがある。原線は３つまでのColorVerticesを持つことがある。我々は、ColorCashe内の各エントリが９００ビットの幅を持つと想定する。このように、フル性能の塗りつぶされた三角形は、１つのColorキャッシュエントリにフィットし、半分性能の塗りつぶされた三角形は、２つのColorキャッシュエントリにフィットする。我々は４つのColorキャッシュエントリを３分の１性能レート及び４分の１性能レートの三角形に割り付ける。たとえ３分の１性能レート三角形が３つのColorキャッシュエントリにフィットしても、我々はそれに４つのエントリを割り付けることに注意するべきである。この処理は、我々が３分の１レートの原線に対して３つのColorキャッシュエントリを使用した場合よりも、格段にキャッシュの保守を容易にする。我々は、部分的に無効化された原線を扱う必要はない。
【０３６２】
Fragmentブロック内のColorキャッシュは、２５６個のフル性能カラー原線を保持することができる。MIJ内TagRamはFragmentブロック内のカラーデータキャッシュと１対１に対応する。PEXパイプライン内では、ColorAddressはカラー原線を一意に識別することに注意するべきである。従って我々は、２４ビットのColorAddressをColorキャッシュ用タグとして使用する。
【０３６３】
カラーデータ取り出し依頼はColorDataFetchサブブロックに送信される。本ブロックはColorAddress及びカラータイプを使用して本原線に必要な頂点の数、各頂点のサイズ、及び取り出される各頂点のColorAddressを決定する。我々は「カラー」原線の実質的な数が細片または扇形の一部であることを期待する。ここでは、ColorVertex検索パターン内で結合を利用する機会がある。本処理は頂点キャッシング経由で行われる。CCIXは、Fragmentブロックに行くVSP内に組み込まれる。
５．８．２．３．１  他のキャッシング
本発明の構造は、Vertexキャッシング、MLM−Pointerキャッシング、Modeパケットキャッシング、Controlパケットキャッシング及びFragmentとPixel Output キュー Managementを提供する。
５．８．３  機能ユニット
Mode Injectionブロックは、CULブロックとCULの下流側のパイプラインの残りの部分の間に常駐する。MIJは、制御及びVSPパケットをCULブロックから受信する。出力側では、MIJは、FragmentおよびPixelブロックのインタフェースを行う。
【０３６４】
MIJは下記処理を実行する役割を負う。
１BeginFrame、EndFrame、及びBeginTileなどの制御パケットのFragment及びPixelユニットへのルーティング
１．先取りパケットのSORTからPixelへにルーティング
３．VSPに対応する原線の全ての頂点に対するColorPointerの決定
４．多角形メモリ内MLMPointerの位置決定及び検索
５．多角形メモリ内の種々の状態パケットの位置決定
６．検索の必要なパケットの決定
７．Color、TexA、TexB、Light,及びMaterialキャッシュ（Fragment、Texture、及びPhongブロック用）、PixModeto及びStippleキャッシュ（Pixelブロック用）の内容把握及び適切なキャッシュポインタの各キャッシュミスデータパケットへの付加
８．多角形メモリからの状態及びカラー頂点パケットの検索
９・原線の構築。Polygonメモリは頂点ごとのデータを保存する。VSPの原線タイプによっては、MIJは多角形メモリから必要な頂点（三角形用に３つ、線用に２つ、及び点原線ように１つ）を検索する。
１０．Fragment及びPixelブロックへのデータ送信
１１．パイプライン内の中断処理
１２・処理の終わりにおけるMEXへの信号送信
このように、Mode Injectionは、VSP内の各フラグメント用最終カラーの演算に必要な頂点ごとのデータ同様に状態の検索を扱う。
５．９  Fragmentブロック（FRG）
５．９．１  概要
Fragmentブロックは、Cull及びMode Injectionの後、Texture、Phong、及びBumpの前に位置する。このブロックは、４つまでのシェ−ディングの必要なフラグメントから成る可視スタンプポーション（VSP）を受信する。VSP内フラグメントは常に同じ原線に属する。従って、フラグメントは、全てのモード設定を含む頂点において定義された原線データを共有する。与えられたピクセルの４つのサンプルのうちの１つでも活性な場合は、サンプルマスクsMaskはVSPの活性サブピクセルサンプルを定義する。これは、フラグメントがピクセルに必要であり、フラグメントに基づいたデータの作成に原線用の頂点ベースのデータに書き込みが行われることを意味する。活性なサブピクセルサンプル位置が使用されてフラグメントの対応するｘ及びｙ座標が決定される。
【０３６５】
帯域幅をセーブするために、Fragmentブロックは、同じ原線に属する複数のVSPに再使用されるカラーデータをキャッシングする。ヒットの場合は、Mode Injectionは、キャッシュ内へとインデックスを含むVSPを送信する。キャッシュミスの場合は、Mode Injectionは、新たなエントリをポイントするColorキャッシュインデックスを持つVSPパケットの送信に先立って、新たなカラーデータを持つキャッシュからエントリを入れ換える。同様に、全てのモード、素材、テキスチャ情報、及びライト情報設定が使用されているブロックにキャッシングされる。各キャッシュ用のインデックスもVSPに含まれる。多角形に加えて、Fragmentブロックは幾つかのテクスチャ及びモード情報をキャッシングする。図５６がDSGPパイプラインの後半のモードデータのキャッシングを示す。
【０３６６】
Fragmentブロックの主な機能は、VSP内の全活性フラグメント用の頂点に提供される多角形情報の改ざんである。Fragmentブロックの出力ブロックにおいて、我々は、なおもフラグメントあたりの全ての改ざんされたデータを持つスタンプを所持する。Fragmentブロックは与えられたフラグメントを並行に改ざんでき、VSP内のフラグメントについては任意の順番で実行できる。フルに書き込まれたスタンプは、受信時と同様の順番でTexture、Phong、及びBumpブロックへと送られる。さらに、Fragmentブロックは、４つまでのテクスチャ用の詳細のレベル（LODまたはλ）値を生成し、Textureブロックに送信する。
【０３６７】
Fragmentブロックは、可変スタンプ処理時間及びColorキャッシュフィルの潜在性をスムーズにするために適切にサイズが決定されたFIFOをその入力に持つ。
【０３６８】
図５７にFragmentブロックのブロック図を示す。
【０３６９】
Fragmentブロックは、下記の６個のサブブロックに分割可能である。
１．キャッシュフィルサブブロック１１０５０
２．Colorキャッシュ１１０５２
３．Interpolation Coefficientsサブブロック１１０５４
４．Interpolationサブブロック１１０５６
５．Normalizationサブブロック１１０５８
６．LODサブブロック１１０６０
最初のブロックはColorキャッシュミスを扱う。新たな多角形データは、キャッシュ内旧データを入れ換える。ColorキャッシュインデックスCCIXは入れ換えるべきエントリをポイントする。このブロックは全ての多角形データを直接キャッシュに書き込むことはしない。このブロックは頂点座標、ｗ座標の逆比例及びオプションのテクスチャｑ座標を使用して重心係数を計算する。このブロックは、重心係数を、それらの計算に使用される情報ではなく、キャッシュに書き込む。
【０３７０】
第二のサブブロックはColorキャッシュを利用する。FragmentがVSPパケット（ヒット）を受信すると、頂点の多角形データ及びそれに伴う重心係数をアクセスするためにCCIXにポイントされるキャッシュエントリが読み出される。
【０３７１】
三番目のサブブロックは、VSPの最初のフラグメントに対して改ざん係数を用意する。係数は、次のフラグメントの係数の増分計算に利用できるように、簡単な等式のフォーマットで分子及び分母に表現される。分子及び分母双方が三角形のすべての領域で除されるため、簡略化される。また、重心係数には冗長性（分数の合計が全部に等しい）が組み込まれているため、分母が持つ心係数の３つのセットの内の２つを提供するだけで、追加収容及び帯域幅がセーブされる。非性能ケースでは、１以外のｑ値を持つテクスチャ係数が３つ以上の係数を持つ分母を使用して書き込まれる。
【０３７２】
スタンプごとに与えられたｘ及びｙ座標は、スタンプ内の左下部ピクセルに対応する。タイル内のスタンプの位置のみがこれらの座標により決定される。別のパケットが後続のスタンプが属するタイルの座標を提供する。ルックアップテーブルがsMask内の対応するビットと共に使用されて、出力確度におけるフラグメントｘ及びｙ座標の下位ビットを決定する。この活性サンプル位置における改ざん箇所の選択は、改ざん係数が１に等しいその合計により常に正の値であることを保証する。
【０３７３】
第４のサブブロックは、各カバーされてピクセルに対してカラー、ノーマル、テクスチャ座標、目視座標、及びBumpタンジェントを改ざんする。改ざん機構はその正確さに従って４つのグループに分けられる。第１のグループは、８ビットの固定小数点カラー分数を改ざんする。値の範囲は０から１であり、全てのビットが１に設定された値１のバイナリ表現である。第２のセットは１６ビット、固定小数点、ノーマル用ユニットベクトル、及び表面タンジェント方向を改ざんする。第３のセットは、１６ビットの対少数を持つ２４ビットの浮動小数点数を改ざんする。頂点目視座標、ノーマルの大きさ、及び表面タンジェントはこのカテゴリに含まれる。最後のグループは、やはり２４ビットのFP数であるテクスチャ座標を改ざんするが、異なる改ざん係数を持つこともある。全ての改ざん係数は、２４ビットFP値として生成されるが、８ビットまたは１６ビットの固定小数点値を改ざんする場合は、より少ないビットまたは固定小数点表現を使用することができる。
【０３７４】
第５のサブブロックは、ノーマル及び表面タンジェントを再正規化する。このプロセス中に得られた大きさは廃棄される。オリジナルの大きさは、Phong及びBumpブロックに送られる前に個別に改ざんが加えられる。
【０３７５】
テクスチャマップu、ｖ座標及び詳細のレベル（LOD）は、第６のサブブロック内で評価される。重心係数は、テクスチャLODの決定に使用される。２つのテクスチャ座標を持つ４つの異なるテクスチャがサポートされる。従って、ユニットは４つまでのLOD及び２４ビットFP値で表されるフラグメントごとのｓ、ｔ座標の２つのセットを提供することができる。
５．９．１．１  sMask及びpMask
図５８に、種々の原線によって形成されるピクセルフラグメントを持つVSPの例を示す。ｓＭａｓｋのコピーもシェ−ディングブロック（Fragment、Texture、Phog、及びBump）をバイパスしてPixelブロックに直接送信される。バイパスパケットもｚ値、Mode、及びPolygon Stipple Indicesを示し、VSPptrにポイントされる場所で、リオーダーバッファに書き込まれる。ｐMaskはFragmentブロック内で生成され、ｓMaskの代わりにTexture及びPhongへと送信される。実際のカバレッジはPixel内で評価される。
５．９．１．２  三角形に対する重心改ざん
Fragmentブロックは、透視図修正された重心改ざんにより値を改ざんする。この節においてプロセスを記述する。
【０３７６】
三角形の描画により生成された各フラグメントを伴うデータの場合、我々はこれらの値が、いかにして三角形内フラグメントに対して提供されたかを指定するところから始めた。我々は、三角形１１１７０に対して重心座標を定義した（図５９）。重心座標は、次の３つの数字のセットである。各々[０，１]の範囲にあるA0、A1、及びA2であり、A0＋A1+A2＝１である。これらの座標は、三角形または三角形の境界上でいずれかの点ｐを下記のように一意に指定する。
ｐ（ｘ、ｙ）＝A0（ｘ、ｙ）×V0＋A1（ｘ、ｙ）×V1＋A2（ｘ、ｙ）×V2
ここで、V0、V1、及びV2は三角形の頂点であり、A0、A1、およびA2は下式の通りである。
【０３７７】
【数１６】
0003657518.tif 000019
ここで、Area(i,j,k)頂点ｉ、ｊ、及びｋを持つ三角形のウィンドウ座標内の領域に与える。本領域を演算する一つの方法を下記に示す。
Area(V0,V1,V2)＝１/２（ｘW0,×ｙW1−ｘW1×ｙW0＋ｘW1×ｙW2−ｘW2×ｙW1＋ｘW2×ｙW0−ｘW0×ｙW2）
V0、V1、及びV2データをそれぞれｆ0、ｆ1、及びｆ2として与える。次に、三角形のラスタ画像処理により生じたウィンドウ座標ｘ及びｙを持つフラグ面tにおけるデータの値ｆ（ｘ、ｙ）な下記により与えられる。
【０３７８】
【数１７】
0003657518.tif 000020
ここで、Wc0、Wc1、Wc2はそれぞれV0、V1、およびV2のクリップｗ座標である。A0、A1、及びA2はデータが与えられるフラグメントの重心座標である。
a0=a1＝a2＝１
次の式で表されるテクスチャｓ及びｔ座標は例外である。
a0=q0、a1＝ｑ1、a2＝ｑ2
５．９．１．３  線に対する改ざん
線に沿ったフラグメントデータに対する書き込みの場合は、多少異なった公式が使用される。
【０３７９】
作成されたフラグメントセンターのウィンドウ座標をｐr＝（ｘ、ｙ）で与えるようにし、ｐ2＝（ｘ2、ｙ2）及びp1＝（ｘ1、ｙ1）を線のエンドポイント（頂点）とする。下記のようにtを設定し、ｐ1においてｔ＝０であり、ｐ2においてはｔ＝１である。
【０３８０】
【数１８】
0003657518.tif 000021
５．９．１．４  点に対する改ざん
原線が点の場合、改ざんは一切行われない。頂点２はデータを保持しているものとする。ｑがｓに等価でない場合は、ｓ、ｔ、及びｒ座標がｑによって分割される必要がある。
５．３．１．５  ベクトル改ざん
バンプマッピングの場合、ノーマル及び表面タンジェントは有向ユニットベクトルを伴う大きさを持つ場合がある。この場合、我々はスカラー大きさとは別にユニットベクトルコンポーネントを改ざんする。この処理は、明らかに大きさを持つｘ、ｙ、及びｚコンポーネントを改ざんするよりも、良い視覚的結果を与える。この事実は、方向と大きさが別々に使用されている場合は特に重要である。
【０３８１】
図６０に、異なる大きさのベクトル間の改ざんがいかにして不均等な角度の粒の結果をもたらすかを示す。これは、我々がノーマル及びタンジェントに対してこの方法で改ざんをしない理由である。
５．３．１．６  フラグメントｘ及びｙ座標
図６１に、いかにしてフラグメントｘ及びｙ座標を使用して改ざん係数が形成されるかを示す。タイルｘ及びｙ座標は、タイル処理フォームの開始時に最上位ビットとなる。サンプルマスク（sMask）が処理を必要とするフラグメントを見つけるのに使用される。ルックアップテーブルは、サブピクセル確度において最下位ビットを与える。我々は、サンプル場所の選択された２ビットを取り除くことができる場合にはULTのサイズを減少させることが可能となる。
５．９．２  等式
５．９．２．１．  キャッシュミス計算
最初の重心係数は、Fragmentユニット内のColorキャッシュミスの評価に必要である。三角形の場合は下式となる。
【０３８２】
【数１９】
0003657518.tif 000022
上記の等式内でｘW0,ｘW1,ｘW2は３つの三角形の頂点のx座標である。同様に、ｙW0,ｙW1、及びｙW2は三角形頂点の３つのy座標である。実際の重心係数の場合、全てのコンポーネントは三角形の領域によって分割されなければならない。我々のケースでは、やはり領域により分割された係数を持つ分母を形成する透視図修正のためにこの処理は必要ない。
【０３８３】
頂点座標ｘW1,ｘW2,及びｙW1,ｙW2を持つ線の場合は、下式が適用される。
【０３８４】
【数２０】
0003657518.tif 000023
我々はいま、下記のように透視図修正重心係数コンポーネントを形成した。
【０３８５】
【数２１】
0003657518.tif 000024
ここで、Wic0は、頂点０のクリップｗ座標の逆比例である（逆比例はGeometry内で実行される）。
【０３８６】
【数２２】
0003657518.tif 000025
分母コンポーネントは、個々の定数を分子に加えることによって形成される。
Dx=Cx0＋Cx1+Cx2;Dy=Cy1＋Cy1+Cy2；Dk=Ck0+Ck2
上記計算は、各三角形に対して一回だけ実行すれば良い。カラーメモリキャッシュが同じ三角形の次のVSPに対して係数をセーブするのに使用される。キャッシュミスが起きた場合は、係数は最評価が必要になる。
５．９．２．２  改ざん係数
次に、我々は座標を持つVSPの最初のピクセルに対して重心座標を用意する。
【０３８７】
【数２３】
0003657518.tif 000026
次に、ｘ方向の次のピクセルの場合は、下式を適用する。
【０３８８】
【数２４】
0003657518.tif 000027
または、ｙ方向の次のピクセルの場合は、下式を適用する。
【０３８９】
【数２５】
0003657518.tif 000028
非性能のケース（半分のレート）では、テクスチャ座標ｑn[m]が１に等しく、ｎが頂点番号（０から２）で、ｍはテクスチャ番号（０から３）の場合、改ざんテクスチャ座標用の追加分母が評価される。
【０３９０】
【数２６】
0003657518.tif 000029
（ｘ、ｙ）座標を持つ与えられたピクセル用の重心座標が評価される場合、我々はそれらを改ざんに使用する。線L0は必要ではないが、下記式内ではゼロであるものとする。
５．９．２．３  改ざん等式
フル性能モードでは、我々はテクスチャ座標の1セットを改ざんする。
【０３９１】
【数２７】
0003657518.tif 000030
カラーを放散及び反射する。
【０３９２】
【数２８】
0003657518.tif 000031
８ビットカラー値は、実際に０から１の、それらの数字を含む範囲の分数であることに注意する。変換により、失われた表現された数字は１−２−８である。１の値は、失われた表現の場所を取って設定された全てのビットで表現される。カラーインデックスがR、G、B、及びAの代わりに使用されている場合、８ビットインデックス値がカラーのDiffuse及びSpeculaｒコンポーネントのR値を入れ換える。
【０３９３】
表面はノーマルである。
【０３９４】
【数２９】
0003657518.tif 000032
ノーマルベクトルは、改ざんの後で再正規化されなければならない。
【０３９５】
【数３０】
0003657518.tif 000033
半分レート（蓄積）において、我々は必要な頂点目視座標を改ざんする。
【０３９６】
【数３１】
0003657518.tif 000034
半分レート（蓄積）において、我々は４つまでのテクスチャ座標を改ざんする。この処理は、単純等式または重心座標を使用して実行される。ｒテクスチャ座標も、関連するボリュームテクスチャ描画に対して改ざんが加えられるが、フルレートの３分の１においてである。
【０３９７】
【数３２】
0003657518.tif 000035
ユーザによって頂点ごとのバンプタンジェントとして部分分数が提供された場合は、我々はそれらを改ざんする必要がある。簡易化として、ハードウェアは常に表面タンジェントを半分のレートで改ざんする。
【０３９８】
【数３３】
0003657518.tif 000036
表面タンジェントもノーマルと同様に改ざんの後で正規化されなければならない。
【０３９９】
我々は、やはり重心係数を使用して、ウィンドウｘ及びｙ座標に関連してテクスチャ座標の部分導関数を評価する。
【０４００】
【数３４】
0003657518.tif 000037
ｑn[ｍ]が１に等しい事象では、Ｗi(ｘ、ｙ)がＷqi[ｍ]（ｘ、ｙ）と置き換わる。
【０４０１】
これは、改ざんされたｓ、ｔ、及びそれらの部分導関数の評価の代替法の優れた紹介である。
【０４０２】
【数３５】
0003657518.tif 000038
他の項も同様に評価される。カラーやノーマルのような全ての改ざんを必要とする値は、この単純等式で表現でき、三角形情報キャッシュにセーブして増分された評価アプローチにより演算要件を減少させることができる。
【０４０３】
我々は下記を定義する。
【０４０４】
【数３６】
0003657518.tif 000039
個々で、λは詳細のレベル（LOD）と呼ばれ、ｐはテクスチャ画像の拡大縮小をつかさどるスケール係数である。ｎ及びｍは、２次元テクスチャマップの幅及び高さである。ｕ及びｖの部分導関数はｓ及びｔの部分導関数を使用して得る。１次元テクスチャマップの場合、ｔ、ｖ、及び部分導関数δv／δｘ及びδｖ/δｙはゼロに設定される。線の場合、下記の公式が適用される。
△ｘ＝ｘ2−ｘ1；△ｙ＝ｙ2−ｙ1
DSGPパイプラインはそれぞれテクスチャ座標を２セット持つ４つまでのテクスチャをサポートする。特に、ｉ＝０．３の場合：
TEXTURE_１D[ｉ]＝＝１またはTEXTURE_2D[i]==1、この場合、我々はテクスチャ座標TEXTURE_COORD_SET_SOURCE[i]を使用してλを演算する。
【０４０５】
Fragmentブロックは、各活性テクスチャに対し、ｓ、ｔ、ｒ、及びλをTextureブロックに渡す。λは最終ＬＯＤでないことに注意するべきである。テクスチャブロックには、λに対する値を得るためにＬＯＤクランピングなどの追加規則が適用される。
５．９．３  メモリキャッシングスキーム
Fragmentは、３つのキャッシュを使用して必要な動作を実行する。一次キャッシュはカラーキャッシュである。本キャッシュは、原線（三角形、線、または点）のためにカラーデータを保持する。キャッシュミス決定及び入れ換えロジックは実際にはMode Injectブロックに位置する。Fragmentブロックは通常通り、付加されたカラーデータを保持するエントリをポイントするインデックスを持つ「ヒット」パケットを受信する。Mode Injectブロックがミスを検出すると、「フィル」パケットが最初に送信されて、新しいデータを使用するためにいずれかの[ヒット]パケットが送信される前にキャッシュ内エントリを新たしいデータと入れ換える。従って、Mode Injectによって送信されたパケットの順番を変更しないことは重要である。なぜならば、キャッシュ入れ換え及び使用ロジックは、入りパケットが順に処理されるものとしているからである。
【０４０６】
Fragmentブロックは、キャッシュが一杯になっている間、Colorキャッシュへの書き込みの前にデータの一部を変更する。この処理は、ミスタイム間に重心係数を準備するために実行される。頂点ウィンドウ座標である頂点におけるｃｌｉｐ−ｗ座標及び頂点におけるテクスチャｑの逆数が、Cx〔1:0〕、Cy〔1:0]、Dx、Dy、Dk重心係数に置き換えられる。同様に、Sx、Sy、Tx、及びTy値がキャッシュミスの間に他のデータと共に保存される。
【０４０７】
Colorキャッシュは、その時点で２５６エントリ、４セットの添付キャッシュ、に構成されている。Mode Inject及びFragument UnitのmicroArchitectureは、目的の性能を保持するためにその構成を変更する。フルレートにおいては、Colorキャッシュのミスは、処理されたVSPの平均の15％未満と思われる。
【０４０８】
半分のレートで求められるデータは、Colorキャッシュに２つの連続エントリとして保存される。このケースで提供されるインデックスは、常に偶数である。
【０４０９】
Fragmentブロックで使用されるテクスチャ情報には、２つのモードのキャッシュが使用される。これらのキャッシュは、同等に編成されたものであり、各々２テクスチャ分の情報を持っている。２つのテクスチャ座標TX01X及びTX11Xは、全「ヒット」パケット内に提供されてテクスチャ座標を最大4つのテクスチャに付加する。各テクスチャにつき、下記データがテクスチャモードキャッシュから読み出される。
【０４１０】
TEXTURE＿１D、TEXTURE_２D、TEXTURE_３Dは与えられたテクスチャの有効ビットである。
【０４１１】
TEXTURE_HIGH、TEXTURE_WIDTHはそれぞれu及びｖ計算内で使用されるｍ及びｎ値である。
【０４１２】
TEXTURE_COORD＿SET_SOURCEは与えられたテクスチャにくくられるテクスチャ座標を示す。
【０４１３】
テクスチャモードのキャッシュは、３２エントリ完全連結可能キャッシュである。テクスチャモードのキャッシュ０の想定されるミスレートは、VSPあたり0.2％未満である。
【０４１４】
なお、モードもModeキャッシュ中のFragmentにキャッシングされる。Modeキャッシュは完全連結可能な８エントリキャッシュとして構成される。想定されるミスレートはVSPあたり0.001％未満である（無視できる）。下記情報がModeキャッシュにキャッシングされる。
SHADE_MODEL（1ビット）
BUMP_NO_INTERPOLATE(1ビット)
SAMPLE_LOCATION_SELECT（３ビット）
５．９．４  可能な未来の思考
VSPの処理順序も変更が可能である。Pixelブロック前のリオーダーブロックがスタンプを最構築する。同じｘ及びｙ座標（別々の原線に属する）を共有するVSPは、到着した順でPixelに渡されなければならない。各VSPに伴うVSPptrは、リオーダーバッファ内のVSPの位置を示す。バッファはFIFOとして構成され、最も前に位置するシェ−ディングが完了したスタンプがPixelブロックへと向かう。
【０４１５】
VSP処理順序に関するもう一つの考慮は、種々のモードキャッシュである。モードインデックスは、「ヒット」パケットが「ミス」パケットを横切らないことを想定している。これは、「ミス」パケットが「ヒット」パケットのバリアーを形成することを表している。明らかに、Mode Injectionが提供した順序で下流側ブロックがパケットを見るため、プロセス順序は対応するモードキャッシュ情報を取り出した後で変更可能となっている。
５．１０  Textureブロック（TEX）
５．１０．１  概要
３Ｄグラフィックスでは、多角形が使用されてオブジェクトの形を定義する。テクスチャマッピングは、詳細画像を持つカラリング多角形により表面テクスチャをシミュレートするテクニックである。特徴として、単一のテクスチャマップは多くの多角形から成るオブジェクトをカバーする。テクスチャマップはRGBAカラー（Apex内で最大２K×２K）の長方形の配列である。ユーザは、Geometryブロック内で手動または自動で各頂点のテックチャマップ内に座標を供給する。これらの座標は、各フラグメント用に改ざんされ、テクスチャ値はテクスチャマップ及びフラグメントに割り付けられたカラーの中から調べられる。バンプマップ係数もlight_textureエクステンションを使用して同様に得られる。詳細はPhongブロックを参照されたい。
【０４１６】
オブジェクトは観察者から遠い場合は小さく現れるため、テクスチャパターンがテクスチャリング中のオブジェクトと同サイズで現れるようにテクスチャマップの縮尺を決めなければならない。無論、各フラグメントのテクスチャ画像の縮尺及びフィルタリングは高価な計画である。Mipmappingは、走行中に描画者に対して本作業の一部を避けることを許容する。ユーザは、引き続くより低いリソリューションにおいて一連のテクスチャ配列を提供する。各配列は、指定された詳細のレベル（LODまたはλ）を表す。Fragmentブロックは、観察者からの距離に基づいて各フラグメントに対する詳細のレベルの値を計算し、Textureブロックは二つの最も近いミップマップ配列の間を改ざんして同フラグメントに対するテクスチャ値を生成する。例えば、フラグメントがλ＝０．５を持っている場合、Textureブロックはλ＝０及びλ＝１を表す配列の間を改ざんする。
【０４１７】
Apexボードは、１秒あたり２５０Mのテクスチャリングされたフラグメントにおいて三線に囲まれたミップマッピングによる、テクスチャマッピングをサポートする。フラグメントあたり最大８つのテクスチャマップ及び８セットのテクスチャ座標が相対的に低い性能でサポートされる。Apexは、SGIエクステンションまたは高さ傾きフィールドを使用してバンプマップをテクスチャとして扱う。テクApexは３Dテクスチャマッピングを幾分低いレートで実行する。これは、テクセルキャッシュが、オプションのテクセル再使用がより少ないため、上記処理をより非効率的に実行するからである。
【０４１８】
我々は、Apex内で下記エクステンションをOpenGL1.1にサポートする。
・  マルチテクスチャ…フラグメントあたり最大８テクスチャマップ及び８セットのテクスチャ座標
・  ３Dテクスチャ…３Dテクスチャは二線にはさまれた混合動作をサポートする。３Dテクスチャに対する三線に囲まれたミップ−マッピングはソフトウェアで扱われる。
・  LODクランピング…テクスチャLODのサブセットのみをミップマッピングに使用するよう要求する。
・  エッジクランプ…クランピングされたテクスチャの正しい実行法
・  影…マルチパス影をサポートする簡単なエクステンション
・  バンプ及び深度テクスチャ（１２−１２−１２及び１６−１６）に対する符号付きデータタイプサポート
エッジクランピング、LODクランピング、及び３DテクスチャリングはOpenGL1.2の一部である。
【０４１９】
テクスチャブロックはテクセルをキャッシングしてローカル使用を得る。テクスチャマップは２×２ブロックのRGBAデータ（ブロックあたり１６バイト）テクスチャメモリに保存される。ただし、ノーマルベクトルはこの限りではなく、１８バイトブロック（６−６−６）に保存されることがある。
５．１０．１．１  仮想テクスチャ番号
ユーザは、テクスチャがOpenGLコールでユーザスペースから渡されると、テクスチャ番号を提供する。ユーザは１マップでテクスチャリングされる幾つかの三角形を送信でき、同じテクスチャ番号を付加されたテクスチャを、同じフレーム内で三角形以外のテクスチャに変更することができる。我々のパイプラインは、フレーム用のテクスチャデータの全セットがテクスチャブロックで利用可能なことを要求する。ソフトウェア内では、我々は仮想テクスチャ番号を各テクスチャマップに割り付ける。
テクスチャメモリ
テクスチャメモリはテクスチャブロックが現在使用しているテクスチャ配列を保存する。ソフトウェアは、テックスチャ配列をホストメモリからテクスチャメモリにコピーすることによってテクスチャメモリを管理する。ソフトウェアはテクスチャ配列アドレスのテーブルもテクスチャメモリ内に維持する。
５．１０．２．１  テクスチャアドレッシング
テクスチャブロックは、仮想テクスチャ番号及びLODによってテクスチャ配列を識別する。最も高いLOD用の配列は、単一レコードにまとめられる。（ある実施例内ではRODは７つで、各RODは２１キロバイトを含む。）テクスチャ配列ポインタテーブルは、テクスチャ配列ID(LODに付加された仮想テクスチャ番号)をテクスチャメモリ内のアドレスと組み合わせる。我々は数千のテクスチャ配列番号をサポートする必要があり、テクスチャ配列ポインタテーブルはテクスチャメモリに保存されなければならない。我々は、テクスチャ配列IDを１秒間に５００M回アドレスにマッピングする必要がある。幸運ながら、隣接したフラグメントはは通常同じテクスチャ配列を共用するため、我々は、テクスチャ配列ポインタ用に良いタイルレートをキャッシュと共に得る必要がある。（ある実施例では、テクスチャ配列キャッシュのサイズは１２８エントリだが、他のサイズも、大小を問わず利用できる。）図５２にテクスチャ配列アドレッシングの概要を示す。
【０４２０】
テクスチャブロックは、ダブルハッシングアルゴリズムを利用してメモリ内のポインタテーブルを検索する。ソフトウェアは、ハードウェアハッシングアルゴリズムを使用してテクスチャ配列ポインタテーブルを管理する。
５．１０．２．２  テクスチャメモリ割り当て
ソフトウェアは、テクスチャメモリの割り当てを扱う。テクスチャブロックがテクスチャメモリ内にないテクスチャ配列を必要とすると、割り込みをホストに送信する。ホストはメインメモリからテクスチャ配列をコピーし、上記のようにテクスチャ配列ポインタテーブルを更新する。ホストは、どのテクスチャ配列が新しいデータにより上書きされるかを制御する。
【０４２１】
ホストは、ゴミの収集などのためにテクスチャメモリを再アレンジする。ハードウェアは下記のメモリコピーをサポートする。
・  ホストからメモリ
・  メモリからホスト
・  メモリからメモリ
正しい振る舞いを保証するために、同期スキームが採用される。乱暴な力まかせのアプローチは、いずれのメモリコピー活動にも先立ってテクスチャブロックを洗い流してしまう。しかしながら、我々はテクスチャ配列ポインタテーブル１３１０６に基づいたより気軽な計画を大域的に取り入れることができる可能性がある。ソフトウェアは、幾つかのコマンドを使用してパイプラインを開始、停止、及び洗い流す処理を通じて同期を制御する。下記「ホストコマンド」を参照。
５．１０．２．３  テクスチャメモリの内容
テクスチャ配列は２×２テクセルブロックに分割される。配列内の各テクセルブロックは、RGBA、RGA、または４つのテクセル用の高さ傾きデータを含むレコードによりテクスチャメモリ内に表される。三線に囲まれミップ−マッピングによって与えられたフラグメントのテクスチャリングは、フラグメントが２×２ブロックに関連してどこに落ち込むかにより、これらブロックの２から８バイトのアクセスを必要とする。
５．１０．２．４  テクスチャメモリデータパス
テクスチャメモリとテクスチャブロック間の通常のパスに加えて、ホストメモリからテクスチャメモリへのパスがある。帯域幅は５００MB/ｓでなければならない。このこの「バックドアバス」パスは、フレームバッファを及びテクスチャメモリをホストに接続する。我々は、ソフトウェアの制御下でのテクスチャメモリのメモリかたメモリへのコピーもサポートする。
５．１０．２．５  テクスチャフォーマット
ハードウェア内では、我々はOpenGl内部フォーマットRGBA8、RGB１２（符号付き）及びLUMINANCE16_ALPHA16（符号付き）をサポートする。ソフトウェアは、RGB8などのこれらフォーマットの記憶のサブセットを使用する他のフォーマットをサポートする。バンプマップ係数などのテクスチャメモリの使用は、テクセルビットを他の方法で解釈する。テクスチャブロックの後で、全カラーが、コマンド、深度、及び高さフィールドのようなlight_texture量を除いて、８ビット量として扱われる。
【０４２２】
上記のフォーマットをサポートするには、我々は２セットの１６ビット値、３セットの１２ビット値、または４セットの８ビット値の直線改ざんを実行する必要がある。Textureブロックは、４セットの数学的ユニットを使用して計算する。内２つは１６ビット確度、１つが１２ビット確度、１つは８ビット確度である。
【０４２３】
１６及び１２ビット動作の全てが符号付きである。正規のカラーを符号付１２ビット数の扱いも８ビット符号なし異常を保存する。
５．１０．２．５．０．１  ビデオテクスチャ
幾つかのYUV（またはYIQ）フォーマットの１つの中にビデオフィードがある。我々はRGBへの変換を行い、２Dコアを使用してRGBを解釈し、Rambusマスクド書き込みを利用してテクセルを２×２ブロックへ収容することにより値をテクセルフォーマットへとパックする（スキャンラインオーダーの代わりに２×２ブロック）。本データはTextureメモリに保存され、正常テクスチャとして表示される。
５．１１  Phong及びBump Mappingブロック（PHB）
５．１１．１  アルゴリズム概要
Phongブロックは、テクスチャブロックからのテクスチャ情報を持つフラグメントブロックからのカラー、マテリアル、ジオメトリック、及びライティング情報を組み合わせてフラグメントのカラーを計算する。結果はカラードフラグメントであり、フレームバッファ内にすでに常駐しているいずれかのカラー情報と混合されるとPixelブロックへと送り出される。
【０４２４】
Phongはフレーム、ファイル、またはスクリーンスペースを気にしない。
５．１１．２  カラーインデックスモード
テクスチャ及びフラグメントライテフィング動作は、カラーインデックスモードには入らない。Phongブロックによって実行される唯一の計算は、フォグ計算である。この場合、入力フラグメントカラーのR値の仮数は、０から２５５まで変化する８ビットカラーインデックスとして解釈され、処理のために直接フォグブロックにルーティングされる。
５．１１．３  パイプライン位置
Phongブロックは、Textureの後、Pixelの前に位置している。本ブロックはテクスチャ及びフラグメント双方からパケットを受信する。フラグメントは、フラグメントごとのデータを、Mode Injectionから渡されるキャッシュフィルパケット同様に送信する。テクスチャは、テクセルデータのみを送信する。
【０４２５】
Phongによってもたらされる結果のみがPixelに送信され、Pixelが要求する他の全データは別のデータパス経由で来る。図６３にパイプライン内のPhongの位置及び隣接ブロックとの関係を示す。
【０４２６】
Phongブロックは次の２つの内部キャッシュを持つ。シーンライト及び大域描画モードのように頻繁には変化しない情報を保持する「ライト」キャッシュ、及び一般的にオブジェクトごとに変化する情報を保持する「素材」キャッシュである。
５．１１．４  Phong演算ブロック
Phong手順は、本切に要約される幾つかのサブコンポーネントにより成る。必要なデータの詳細に伴う擬似コード及び状態情報は本明細書中で後に記述する。図６４にPhongのブロック図を示し、実行される種々の演算を示す。
５．１１．４．１  テクスチャ演算
テクスチャ演算１４１１４はTextureブロックから来るテクセル及び素材キャッシュからのテクスチャモード情報を受け付ける。本機能は、テクスチャ環境計算を適用し、複数のテキスチャがあればそれらを併合する。本機能は、テクスチャの従来通りの使用のケースでは、結果をライト環境サブユニットに送り出し、テクスチャがカラーを除くPhong計算の幾つかのパラメータの変更時にテクスチャが解釈されるケースでは他のサブユニットに送り出される。
５．１１．４．２  素材演算
素材演算１４１２６はライティング演算用の素材値のソースを決定する。本機能は現素材モードビットを使用して、テクスチャ値またはGouraud計算内でディスパッチされる入り一次カラーを持つフラグメント素材の入れ換えを決定することがある。
５．１１．４．３  バンプ演算
バンプ演算１４１３０は、表面ノーマルを決定する。本機能は、単純にフラグメントにより改ざんされたノーマルを渡すか３×３マトリックス乗算が関わる計算内のテクセル値を使用することがある。
５．１１．４．４．  ライトテクスチャ演算
Light-Texture演算１４１３４はライトのコンポーネントのいずれがテクスチャ演算から送られてきたテクセルにより入れ換えられるべきかを決定する。
５．１１．４．５  フラグメントライティング演算
フラグメントライティング演算１４１３８は、GEOブロック内の頂点ごとのライティングに使用される等式に似た等式を使用して実際のライティング計算を本フラグメントに対して実行する。
５．１１．４．６  ライト環境演算
ライト環境演算１４１４２はフラグメントライティング演算の結果をTテクスチャブロックから送られてきたテクスチャカラーと混合する。
５．１１．４．７  フォグ演算
フォグ演算１４１４６は「フォグ」に適用結され、観察者の視線からフラグメントの距離のみによる演算を使用してフラグメントカラーを変更する。本機能は最終結果をPixelブロックに送り出す。
５．１２  Pixelブロック（PIX）
５．１２．１  Pixelブロックの概要
Pixelブロック（PIX）は、３Dパイプライン中のバックエンドのまえの最後のブロックである。本ブロックは、OpenGL及びDirect３Dのフラグメントごとの動作の役割を負う。これらの動作はアルファテスト、ステンシルテスト、深度テスト、ブレンド、振動、及びロジック動作を含む。ピクセルオーナーシップテストはウィンドウシステムの一部（OpenGL1.1規格の第４章参照）であり、バックエンド内で実行される。これら動作に加えて、Pixelはアンチアライアシングに対するサンプル蓄積を実行する。
【０４２７】
PIX前のパイプラインステージは、原線をVSPに変換する。VSPは、スタンプ上の多角形の可視ポーションに対応する。スタンプは、画像の２×２ピクセル領域である。SRTブロックは、各タイルに対する原線の収集の役割を負う。CULブロックはSRTブロックからタイル順にデータを受信し、絶対に描画された画像には資することのない原線のパーツを選別する。CULブロックはVSPを生成する。TEX及びPHGユニットもVSPを受信し、それぞれフラグメントのライティング及びテクスチャリングの役割を負う。
【０４２８】
PIXブロックはMode Injection（MIJ）及びPhong(PHG)ブロックから入力を受信する。VSP及びモードパケットはMIJから受信し、VSP用フラグメントカラーはPHGから受信する。PHGもVSPに対してフラグメントｚ値を供給することがある。オブジェクトがそれに適用される深度テクスチャを持っている場合に、上記処理が起きる。VSP用のフラグメントカラーは、VSPと同じ順番でPIXブロックに到着することに注意する。PIXブロックは、適用可能モード設定に従って各可視サンプル用データを処理する。PIXが現タイル用の全スタンプの処理を済ませると、PixelOut(PXO)ユニットに対して信号を送ってカラー、ｚ、及びタイル用ステンシルバッファの出力を促す。PixelOutユニットはピクセルサンプルを処理してカラー、ｚ、及びピクセル用のステンシル値を生成する。これらピクセル値は、バックエンド(BKE)ブロックに送信される。フレームバッファ用のRDRAMメモリコントローラはBKEブロック内にある。BKEブロックはPIXによるジオメトリ（VSP）の描画用の現タイルバッファを準備する。本処理は、既存のカラー、ｚ、及びステンシル値のフレームバッファからのローディングを含む。
図６５にPixel（PIX）ブロックのブロック図を示す。
【０４２９】
サンプルごとのｚ、ステンシル、及びカラーバッファは二重バッファリングされている。それゆえ、PixelOutが1つのタイルをバックエンドに送信していると、深度及び混合ユニットは２番目のタイルに書き込みを行っている場合がある。サンプルごとのカラー、ｚ、及びステンシルバッファは、1024サンプルなどのタイル1つ分のデータを保存するのに十分な大きさを持っている。ピクセルごとのｚ、ステンシル、及びカラーバッファは各タイルにも用意されている。これらのピクセルごとのバッファは、BKEブロックとのインタフェース用に中間記憶として使用される。
【０４３０】
PIXはMIJからバックエンド（BKE）ブロックに向かう幾つかのパケットを受信する。入力フィルタは、バックエンドプリフェッチキュー上のこれらパケットを適切に渡す。上記パケットは、受信した時の順番で上記キュー内で処理される。幾つかのパケットはPixelOutユニット内のキューへと送信される。前述のように、PIXブロックはMIJ及びPHGブロックから入力を受信する。これら２つの入力を取り扱うための２つの入力キューがある。MIJからのデータパケットはVSPキューに向かい、PHGからのフラグメントColor/depthパケットはColorキューに向かう。PIXブロックはBKEブロックに向かうパケットの幾つかも受信する。BKE及びPXOブロックは受信順でデータパケットを処理する。MIJはデータパケットを入力FIFOに入れる。入力バッファは、パケットヘッダーを検査し、BKEブロック向けのデータをBKEブロックに送信し、PIXが必要とするデータパケットをVSPキューに送信する。MIJから受信したパケットの大部分は、VSPキューに向けたものであり、幾つかはBKEブロックに向かうだけであり、幾つかはBKE及びPXOユニットに送信されてVSPキューにコピーされる。
【０４３１】
我々は、タイル動作の必要性とメカニズムを説明するのに多少脱線をする。典型的な描画シーケンスは、下記の動作を伴うことがある。
１．必要ならば、カラー、ｚ、及びステンシルバッファをそれらのクリア値に初期化する。
２．必要ならば、ビットバックグラウンド画像をバッファに収容する。
３．ジオメトリの描画
４．他のビット
５．幾つかのさらなるジオメトリの描画
５．終了及びフリップ
ステップ２内のビット動作はウィンドウ全体をカバーし、その後のそのバッファに対するクリア動作は必要ないことがある。ビットがウィンドウの一部をカバーしている場合、クリアが必要な場合がある。さらに、動作１及び２は次のように逆の順番で起きることがある。ウィンドウの一部のクリアに続いて、全部のウィンドウのビット(多分)がある場合がある。ウィンドウ全体をカバーし、鋏テスト、タイル整列、及びスケーリングを必要としないプレジオメトリビットはBKEブロックによってタイルバッファへの画像読み戻しとして進められ、パイプライン中でテクスチャリングされた原線として利用されることがある。同様に、Clear動作はは二種類に分けられる。ウィンドウ全体のClear動作は、PixelOutユニット内で進められ、ウィンドウの一部だけをカバーするClear動作は、PIXパイプライン内で進められる。PIX（及びPIXの一部であるPixelOut）及びBKE双方は、動作が呼び出された時に種々のバッファへの書き込みマスクを警戒する。実際に、BKEブロックは、書き込みマスクを使用してタイルバッファを読み戻す必要があるかを決定している。フレームの描画がPolygonまたはソートメモリのオーバーフローの原因になる場合は、やはりバッファの読み戻しが起きる可能性がある。パイプラインはユーザフレームをすく数の順フレームに分割する。このように、同じユーザフレームに対して、タイルがPIXボックス内で一回以上訪問することがある。一回目はタイルが見つかり、PIX(多分PixOutユニット)ブロックにより描画に先立つ「クリア値」を伴うチップ上のタイルバッファクリアが必要になることがある。後続のフレームでタイルを描画する場合は、ピクセルカラー、ｚ、及びステンシル値がフレームバッファメモリから読み戻される。ｚバッファがクリアされ、カラー及びテンシルバッファが事前描画された画像からタイル内にロードされると、他の非常に発生しがちなシナリオが起きることがある。このように、タイルの準備の一環として、２つのことが起きる。バックグラウンド画像は、フレームバッファメモリから有効化されてないビット平面にバックグラウンド画像が読み戻され、ビット平面（カラー、ｚ、及びステンシルマスクに対応）はクリアされる。PIXから上ってっくるパイプラインステージは、これらの機能的能力が「クリア」情報を送信するので、それらへの注意が必要である。
【０４３２】
PIXは入りサンプルのｚ値を既存のピクセルのそれらと比較して保存するサンプルを決定する。Pixelは、オーバーフローに起因するユーザフレームの分割を原因とするいずれのカラー染み出し加工物を最小化するために状態ビットも提供する。
５．１２．２  Pixelブロック内機能ユニット
Pixelブロック内の機能ユニットに関して、そのカラー、アルファ、及び点描値がフラグメントごとに生成され、それゆえ対応するテストの結果はフラグメント内の全サンプルに適用されることに注意する。シザーステストの場合も同様である。このブロックはフラグメントごと及びサンプルごとの演算に基づいて最適化の導入を促している。
【０４３３】
ピクセル及びステンシル動作間の相違及びサンプルステンシル動作は、ステンシル値がどのように検索され、タイルバッファに書き込まれるかの決断を妨げる。
５．１３  バックエンドブロック（BKE）
５．１３．１  機能概要
５．１３．１．１  用語
下記の項目は、本明細書の理解を助けるため、使用されるのに先立って下に定義されたものでる。このため、この節を飛ばし、必要な時に参照することもできる。
ピクセルオーナーシップ(PO BOX)は、スクリーン上に与えられたピクセルのうち、ウィンドウIDが属するピクセルを決定するサブユニットである。このメカニズムを使用して、スキャンアウトが上記ピクセルに付与されたオーバレイウィンドウがあるかを決定し、３Dタイル書き込みは、上記ピクセルへの書き込み許可をチェックする。
BKEバスは、BKEとGFD及びCFDとAGIを相互接続し、インタフェースする。このバスは、フレームバッファメモリ及びBKEレジスタに対する読み出し及び書き込み使用される。
フレームバッファは、BKEに制御され、２D及び３Dウィンドウに付与された全てのカラー及び深度値を保持する。このユニットは、リフレッシュレートでピクセルをスキャンアウトすることによりモニタに表示されるスクリーンバッファを含む。本ユニットはまた、スクリーンオーバレイ、ｐバッファ、ディスプレーリスト、頂点配列、及び蓄積バッファを寄せ付けない。スクリーンバッファ及び３Dのpバッファは二重バッファリングされている。
５．１３．１．２  主な機能
図６６にバックエンドそれにインタフェースするユニットとを示す。図に示すスクリーンのように、BKEが３Ｄタイルの読み出し及び書き込みでもっともPixelユニットとインタラクトし、２Dグラフィックエンジン18000（図１５に示す）とはビット動作の実効のためにインタラクトする。CFDユニットは、BKEバスを使用してフレームバッファからディスプレーリストを読み出す。AGIユニット１１０４はBKEレジスタ及びメモリがマッピングされたフレームバッファのデータの読み出し及び書き込みを行う。
【０４３４】
主なバックエンド機能を下記に示す。
・  ３Dタイルよみこみ
・  Pisel Ownershipを使用した３Dタイル書き込み
・  書き込み許可及びオーバーレイ検出用Pixel Ownership
・  Pixel Ownershipを使用したスキャンアウト
・  固定比率ズーム
・  ３Ｄ蓄積バッファ
・  フレームバッファ読み出し及び書き込み
・  winidマップへのカラーキー
・  VGA
・  RAMDAC
５．１３．２  ３Ｄタイル読み出し
BKEは、PIXからTile Beginコマンドをプリフェッチした。これらのパケットはSRTでディスパッチし、全３Dユニットをバイパスしてタイルバッファの内容を読み出すのに必要な潜在機能を提供する。３Ｄウィンドウの特徴はPIXから同じように早期に受信したBegin Frameコマンド群により初期化される。これらの特徴としては、カラー及び深度表面用のアドレス、平面（アルファ、ステンシル、A及びBバッファ）用の有効ビット、高さ及びストライド、カラーフォーマットなどを挙げることができる。
【０４３５】
ピクセルアドレスは、ウィンドウパラメータを使用して計算される。タイルジオメトリで優位に立つため、１６ピクセルが一回のメモリ読み出し要求で取り出せる。
【０４３６】
３Dタイル読み出しでは、ピクセルオーナーシップは参考にされない。ウィンドウがメインスクリーン内にある場合は、オーナーシップ（再上部のウィンドウ）は書き込みプロセス中に決定される。
【０４３７】
ピクセルは、縮小精度カラーに対しては２４ビットカラーに拡張されないが、32ビットピクセルワードにアンパックされる。
【０４３８】
Frequently Begin Tileコマンドは、クリア動作が適用されるためにタイル読み込みは必要ないことを示すことがある。タイルバッファは、まだ割り当てられており、タイル書き込みのピクセルオーナーシップが開始する。
５．１３．３  ３Ｄタイル書き込み
３Dタイル書き込みは３Dタイル読み出しが終わるとすぐに開始する。この潜在機能は、ピクセルオーナーシップ書き込み許可の決定に使用される。タイルスタートメモリアドレスは３Ｄ Tile Readプロセス中にすでに計算されている。書き込み許可は、Rambusメモリに基づいたフレームバッファに対して書き込みマスクとして使用される。カラーは、カラー深度パラメータに指定されているように、フレームバッファに書き込まれる前にパッキングされる。
５．１３．４  ピクセルオーナーシップ
ピクセルオーナーシップは共有スクリーンに対する書き込み許可の決定及びスキャンアウト読み出し用オーバーレイウィンドウを識別するのに使用される。
【０４３９】
ピクセルオーナーシップブロックは、8ビットウィンドウIDを持つピクセルウィンドウIDマップ同様に１６バウンディングボックスを含む。これらIDは６４個のウィンドウを記載するテーブルをポイントする。バウンディングボックス及びwinidマップメカニズムは同時使用を可能にする。制御ビットはどのメカニズムを最初に適用するかを決定する。
【０４４０】
ピクセルオーナーシップは、スクリーンｘ及びｙピクセル座標を使用する。各バウンディングボックスは、そのウィンドウに含まれる最大及び最小ピクセル座標を指定する。バウンディングボックスは、再上部のウィンドウが最後に有効化されたバウンディングボックスで指定されるように順序付けられている。バウンディングボックスは、長方形に形作られたウィンドウに対して簡単にセットアップできる。それらは最も３Ｄウィンドウを志向しているが、少数の２Ｄウィンドウが使用されていると、本メカニズムは、２Ｄウィンドウをクリッピングするためにも使用される。
【０４４１】
任意に形成されたより多くのウィンドウの場合、よりメモリに集中的なメカニズムが使用される。ピクセルあたりの８ビットウィンドウIDマップは与えられたスクリーンピクセルが属するウィンドウを識別するためにオプションで保守される。
【０４４２】
書き込みの場合、タイルのウィンドウIDがピクセルオーナーシップで入手したピクセルIDと同じならば、ピクセル書き込みが有効化される。スキャンアウトの場合、スクリーンからオーバーレイへの移行及び戻りはピクセルオーナーシップウィンドウIDと現スキャンアウトウィンドウIDの比較により検出される。
【０４４３】
ピクセルオーナーシッププロセスを進める場合、ピクセルごとのチェックは、しばしば１６ピクセルチェックにより回避される。整列された水平１６ピクセル細片の場合、全てが同じウィンドウIDを共有する場合、それは一回の動作で決定される。
５．１３．５  スキャンアウト
スキャンアウトはフレームバッファカラーを読み出し、データをディスプレー用RAMDACに送信する。スキャンアウトは、フレームバッファで、最も高い優先順位を持った動作である。スキャンアウトされるピクセルは、仮想ブリッツ、オーバーレイなどを行うために読み出しピクセルオーナーシップブロックを通る。比較的大きなキューが、オーバーレイの扱い及び水平ブランキング期間の優位性に関わるイレギュラーな潜在機能をスムーズにするのに使用される。
【０４４４】
パレット及びガンマ修正がRAMDACにより実行される。固定比率のズームアウト機能は、バックエンドによりスキャンアウトの間に実行される。
【０４４５】
スキャンアウトは、縮小３Ｄ機能を持つ1600×1200スクリーン用に１２０Hｚのリフレッシュレートを達成できなければならない。
【０４４６】
スキャンアウトは、ウィンドウあたり４つの違ったピクセルカラーフォーマットをサポートする。メインスクリーン上の全てのウィンドウが同じピクセルカラーフォーマットを共有する。サポートされたカラーフォーマットを下記に示す。
・  32ビットRGBA(8-8-8-8)
・  24ビットRGB(8-8-8)
・  16ビットRGB(5-6-5)
・  8ビットカラーインデックス
スキャンアウトはScanoutキュー（SOQ）に常に２４ビットを書き込む。カラー変換及びアンパッキングは一切行われない。下位ビットは８及び１６ビットカラーのためにクリアされる。追加２ビットはピクセルあたりのカラーフォーマットに使用される。
【０４４７】
インタレースされたスキャンアウトも特定のステレオ機器のためにサポートされる。
【０４４８】
リアルタイム３Ｄアプリケーションは、小さなウィンドウに絵を描き、小さな画像を大きなウィンドウにズームアップすることにより描画のスピードを上げることができる。二線に挟まれた改ざんを伴うこのズーミングは、ピクセルがスキャンアウトされた時に行われる。
【０４４９】
BKEは次の特定の固定比率スケーリングをサポートする。各方角で１６/ｎ、ｎ＝１・・１５である。サンプル点及び改ざん係数は、ズーム動作に先立って、ソフトウェアによりダウンロードされる。
【０４５０】
最大４つのウィンドウが、同じ固定比率（同じ係数）を使用してズームアウトされる。ピクセルがズーム機能出力から取り出す必要があるかを決定するためにスキャンアウトされたピクセルに対してズームバウンディングボックスが比較される。ズームロジックは、係数テーブルインデックスの順序付けるために継続して可能にすべき動作である。従って、スキャンアウトのウィンドウIDがズームボックスのウィンドウIDと整合しなかった場合、ズーム出力は無視される。
【０４５１】
ウィンドウズームボックスはオーバーラップしてはならない。
５．１３．６  ３D蓄積バッファ
BKEは64ビット（カラーあたり１６ビット）蓄積バッファをサポートする。蓄積コマンドは、フレーム間でtweenパケットとして受信される。それらのコマンドは、３Ｄタイルカラー、蓄積バッファカラー、及び即値を持つ多重及び追加機能を実行する。結果は、蓄積バッファまたは３Dタイルに書き込まれる。
【０４５２】
シザーステストが有効な場合、そのシザースボックス内のピクセルのみがAccum動作により更新される。それ以外の場合は、ウィンドウが更新される。
【０４５３】
ピクセルが３Ｄタイルに書き戻された場合は、振動及びカラーマスキングがシザーステストに加えて適用される。蓄積バッファは、カラーインデックスモードには使用されない。
５．１３．７  フレームバッファ読み出し及び書き込み
BKEは全ての内部サブユニット及び外部ユニットのために読み出し及び書き込みインタフェースを提供する。AGI、CFD、及びTDGはBKEバスを使用してフレームバッファ読み出し及び書き込み要求を作成する。BKE属性バスはそれらのユニットから要求を出す。
【０４５４】
内部サブユニットはMem Busを使用してフレームバッファにアクセスする。３Ｄタイル読み出し、３Ｄタイル書きこみ、蓄積バッファ読み出し及び書きこみ、ピクセルオーナーシップwinidマップ読み出し、スキャンアウト、スクリーン及びオーバーレイ読み出し、ズームウィンドウ読み出し、及びカラーキーwinidマップ書きこみなどは全てMem Busを使用してフレームバッファにアクセスしている。
【０４５５】
合計3.2Gbyte/sec大域幅能力を持つ２つのRambusメモリチャンネルがフレームバッファに対する性能要件を保持する。スキャンアウト及びズーム読み出しは、再優先される。
５．１３．８  カラーキーウィンドウマップ書きこみ
ウィンドウのカラーキー機能はBKEからウィンドウIDマップを通じて提供される。特別カラーキーを持ったウィンドウは、適切なウィンドウ(key_id_on)をポイントするように設定された対応するウィンドウIDマップを持つ。ウィンドウID key_id_onを伴う書きこみが行われた場合、カラーキーが付加されたピクセルだけが置き換えられる。
【０４５６】
BKEはソフトウェアがカラーキーのためのウィンドウIDマップを作成するために使用できる特別な機構を含む。カラーバッファ書き込みが特別なウィンドウ内で行われ、カラーが適当な範囲にある場合、ピクセルのためのwinidが書き込まれることがある。
５．１３．９  RAMDAC
RAMDACは、デジタルカラー値をアナログ信号に変換する。ソフトウェアのプログラマブルカラーパレットが８ビットインデックスを２４ビットRGB値に変換する。同じRAMが調査ベースのガンマ修正にも使用される。調査RAMは２５６×１０ビットSRAMで編成され、その内の一つはカラーの各コンポーネントのためのものである。
【０４５７】
RAMDACは３００Mhzまで動作でき、ピクセルブロックを生成できる。RAMDACは、VGAコアまたはスキャンアウトキューからピクセルを受け付ける。RAMDA777CはコアとしてSEIから得られる。本書はコアとのインタフェース及びその機能に対する基本的な要件を規定するだけである。
５．１３．１０  VGA
VGAこれはブートタイムの間だけWindowsNT下で走行するスクリーン互換アプリケーションに使用される。VGAコアはBKEバスとインタフェースし、フレームバッファ読み出し及び書き込み用Mem バス及びVGAモードのスキャンアウト用のRAMDACにてレジスタ読み出し及び書き込みを実行する。VGAユニットが無効化されると、そのスキャンアウトは無視される。
【０４５８】
VGAこれはAlpinシステムから得られる。本書はコアとのインタフェース及びその機能に関する基本的な要件を規定するだけである。
５．１３．１１  BKEバス
CFDの説明に記されているように、バックエンド入力バス及びバックエンド出力バスがあり、合わせてBKEバスと呼ばれる。
【０４５９】
BKEを通じて読み出し及び書き込みを行う外部クライアントユニットがAGIである。
【０４６０】
これらのユニットは要求／許容プロトコルを使用してBKEバスのオーナーシップを得る。クライアントが一旦このバスを許容すると、バスはBKEに読み出しまたは書き込みパケットを通知し、BKEから読み出しデータをサンプリングする。
【０４６１】
クライアントはBKEバスオーナーシップを、そのReq信号をアサートすることによって要求する。BKEは本要求と他の条件を仲裁する。要求を出したクライアントがオーナーシップを許可された場合、BKEはGnt信号をアサートする。メモリアクセスを済ませた後、現オーナーは自ら形Reqを取り除くことによってオーナーシップを手放すか、Ris（Release）信号をBKEから受け取るまでオーナーシップ（park）を保持する。クライアントは通常Ris信号を受け取った後で限られた時間内にオーナーシップを放棄しなければならない。例えば、クライアントは最後にデータが返ってきたらすぐにオーナーシップを手放さなければならない。
追加記事
本発明は多数の革新的な構造、方法、及び手順を提供する。構造は、デジタル回路を含む個別回路、コンピュータアーキテクチャ及びシステム、パイプラインアーキテクチャ及びプロセッサ接続性などいかなる形も取り得る。方法論的には、本発明は延長シェ−ディングに対する手順及び延長シェ−ディングを実行する作業者、実行しない作業者、及びデータ処理を行う作業者などに広く使用される、他の多数の革新的な手順を提供する。これらの普通の技術的に熟練した作業者は、多くの発明的な構造及び手順が３次元グラフィックプロセッサに関連して説明されているが、発明の多くが２次元処理を始めとしてデータ処理や操作にも広く適応性を持っていることに気づくであろう。例えば、革新性の多くは、汎用コンピュータ機器、システム、及びアーキテクチャの構造に導入可能である。幾つかの実施例がハードウェア利用を必要とするかまたはそこから利益を得ており、少なくとも、幾つかの革新技術はハードウェアまたはソフトウェア／ファームウェア利用及び組み合わせに適用可能である。
【０４６２】
上述した本発明の構造および方法により提供される革新的機構の内の幾つかの簡潔なリストを直下に示す。このリストは、代表的なものを例示するもの、制限するものではない。ここに示す個々の構造及び手順は様々に組み合わされるが、それぞれの組み合わせにつきリストアップしていないことに留意するべきである。さらに、このリストは、革新技術の適用に関して３次元グラフィックスプロセッサに焦点を当てているが、それらの革新技術は、本明細書中で説明され、図に示されている機構及び／または動作を持つ汎用コンピュータ機器にも容易に適用可能である。
【０４６３】
ここに記されている発明は、多数の発明を含む構造及び方法を含むが、次に示す構造及び手順に限定されるものではない。３次元グラフィックス延長シェ−ディングアーキテクチャ、従来型の隠れた表面の除去。タイルプリフェッチ、コンテクスト切り替え、より良いアンチアライアシングのためのＳＲＴによるマルチパス、サンプル場所の選択、セットアップ前の分類、Tweenパケット、パケットによるデータ転送、アルファテスト、ブレンド、点描線、その他、チップ分割、オブジェクトタグ（特に延長シェ−ディングアーキテクチャ）、カラー空間内のロガリズミック正規化（浮動小数点カラー）、バックエンドマイクロアーキテクチャ、スキャンアウト中のピクセルズーミング、スキャンアウト中仮想ブロック転送（BLT）、ピクセルオーナーシップ、ウィンドウID、ブロッキング及びノンブロッキング割り込み機構、キューイング機構、頂点リストに対するトークン挿入、隠れた表面の除去、タイル内容アドレッサブルｚバッファ、３ステージｚバッファプロセス、アルファテストへの対処及び延長シェ−ディング中のステンシル、Z Ref及びDz/dx及びｄｘ/ｄｙを持つスタンプの下流送信、Zバッファメモリとは別のスタンプポーションメモリ、分類された透過性アルゴリズム、サンプルごとの制限された状態マシン、SAM利用、フラグメントマイクロアーキテクチャ、GEOマイクロアーキテクチャ、パイプステージインタリービング、多角形クリッピングアルゴリズム、２次元ブロックマイクロアーキテクチャ、０から１インクルーシブマルチプライヤ（Mul-18p）、整数―浮動少数点−整数（ifi）整合ユニット、テイラーシリーズ利用、算術ブロック構築法、マルチチップ通信リンググラフィックス、延長シェイダー内モード対処、モードキャチング、MLMポインタ記憶、多角形メモリ内Sort Whole内クリップド多角形、Phong/bump割り当て、テクスチャ環境及びライティング用動的マイクロコード生成、延長シェ−ディングマイクロアーキテクチャ、フラグメントエンジンの素材タグベースのリソース、アーキテクチャ内のタンジェント空間ライティング法、種々のスケールバンプマップ、自動ベース生成、自動傾きフィールド生成、角度及び大きさの別々の処理による正規改ざん、延長シェーダにおけるポストタイルソーティングセットアップ操作、統一された原線記述、タイル相対Y値及びスクリーン相対ｘ値、ハードウェアタイルソーティング、十分な空間ルックアヘッド機構、接触タイル改ざん、テクスチャ再使用マッチングレジスタ（延長シェーダを含む）、ピクセルに拡張されたサンプル（テクスチャミス扱い）、タイルバッファ及びピクセルバッファ（テクスチャマイクロアーキテクチャ）、及びパケットを使用したプロセッサ内データ転送。
【０４６４】
本明細書で説明したすべての刊行物、特許、及び特許出願は、各刊行物及び特許出願を特に個々に参照したものと同様の範囲で、本願において参照として含めることができる。
【０４６５】
本発明の前に述べられた実施例の記載は、図示及び記述の目的で提供されたものである。上述の記載は、発明を本明細書中で明らかな形態に限定するものではなく、上述した教示の範囲内での多数の修正や変更が可能である。実施例は、本発明の原理を説明する目的で選択・記述されたものである。それらの実際的な適用にあたり、当業者であれば、本発明及び種々の実施例に基づいて特別な使用目的に適合させるべく、様々な修正を加えて有効利用が可能であろう。本発明の範囲は、本願に添付された請求項及びその均等範囲により規定される。
関連出願
本出願は、35 USC セクション 119(e)の米国仮出願、１９９８年８月２０日に出願された出願番号 No.60/097,336、題名“GRAPHICS PROSESSOR WITH DEFFERED SHADING”の下に利益を主張する。
【０４６６】
本出願は、USC セクション 120による１９９８年１２月１７日の米国特許出願、出願番号No.90,213,990、題名“ HOW TO DO TANGENT SPACE LIGHTING IN A DEFFERED SHADING ARCHITECTURE” (アトーニードケットNo.A-66397)の下にも利益を主張する。
【０４６７】
題名“ユニファイドプリミティブデスクリプタを使用する３−Ｄグラフィックスパイプラインにおけるセットアップ動作を実行するための装置および方法”（アトーニードケットNo. A-66382)の下にも利益を主張する。
【０４６８】
題名“ポスト−ファイルソーティングセットアップ”（アトーニードケットNo. A-66383)の下にも利益を主張する。
【０４６９】
題名“相対Ｙ−値のタイルおよび相対Ｘ−値のスクリーン”（アトーニードケットNo. A-66384)の下にも利益を主張する。
【０４７０】
題名“３次元グラフィックスパイプラインにおける空間ソーティングイメージデータシステム、装置および方法”（アトーニードケットNo. A-66380)の下にも利益を主張する。
【０４７１】
題名“３次元グラフィックスパイプラインにおけるソーティングされた対象次ジオメトリリのための保証された保守メモリ見積もりのためのシステム、装置および方法”（アトーニードケットNo. A-66381)の下にも利益を主張する。
【０４７２】
題名“３次元グラフィックスパイプラインにおける与えられた資源をバランシングさせるためのシステム、装置および方法”（アトーニードケットNo. A-66379)の下にも利益を主張する。
【０４７３】
題名“パイプライン状態を記憶およびリトリーブするグラフィックスプロセッサ”（アトーニードケットNo. A-66378)の下にも利益を主張する。
【０４７４】
題名“テクスチャを発生させるための方法および装置”（アトーニードケットNo. A-66398)の下にも利益を主張する。
【０４７５】
題名“３Ｄグラフィックスパイプラインにおけるジオメトリ操作のための装置および方法”（アトーニードケットNo. A-66373)の下にも利益を主張する。
【０４７６】
題名“３Ｄグラフィックスパイプラインにおけるフラグメント操作のための装置および方法”（アトーニードケットNo. A-66399)の下にも利益を主張する。
【０４７７】
題名“繰り返しシェーディンググラフィックスパイプラインプロセッサ”（アトーニードケットNo. A-66360)の下にも利益を主張する。
【０４７８】
題名“繰り返しシェーディングのグラフィックスプロセッサにおける保守しつつ隠された表面除去を実行するための方法および装置”（アトーニードケットNo. A-66386)の下にも利益を主張する。
【０４７９】
題名“向上した特徴を有する繰り返しシェーディンググラフィックスパイプラインプロセッサ”（アトーニードケットNo. A-66364)の下にも利益を主張する。
【０４８０】
これらのいくつかの構造及び方法に、ディファード・シェーディング・グラフィックス・パイプライン・プロセッサ及び処理方法の多くの実施形態が、それらに関連する構造及びプロシージャと同様に含まれる。以下の内容を含むが、それらに限定されない、多くの実施形態が示され及び記述される：
（１）（ａ）通信チャネルを介して、外部コンピュータからのデータ及び／又はコマンドの入力を伝え、及び前記入力を、一連のパケットに変換するコマンド・フェッチ及びデコード装置であって、前記パケットは、色、面法線、テクスチャ座標、レンダリング情報、ライティング、ブレンディング・モード、及びバッファ機能を含むグループから選択された情報項目を含む、前記コマンド・フェッチ及びデコード装置と；（ｂ）前記パケットを受信し、及び座標変換、すべてのポリゴンの、実三角形又は退化三角形への分解、ビューイング・ボリューム・クリッピング（viewing volume clipping）、及び任意で、グロー・シェーディングに必要とされる、バーテックスごとのライティング及び色計算を実行するジオメトリ装置と；（ｃ）モード抽出装置及び前記ポリゴン装置と関連したポリゴン・メモリであって、前記モード抽出装置は、前記ジオメトリ装置からデータ・ストリームを受信し、及び前記データ・ストリームを、ソート装置に送られるバーテックス・データと、記憶のために前記ポリゴン・メモリへと送られる非バーテックス・データとに分離する、前記装置と；（ｄ）ソート装置及び前記ソート装置と関連したソート・メモリであって、前記ソート装置は、前記モード抽出装置からバーテックスを受信し、及びその結果の点、線、及び三角形をタイルでソートし、及び前記ソートされたジオメトリを、タイルごとのオーダで、完全なプリミティブを表すソート・ブロック出力パケットの手段によって、セットアップ装置へと伝える、前記ソート装置及びソート・メモリと；  （ｅ）前記ソート・ブロック出力パケットを受信し、及び一度に一つのプリミティブ、タイルごとのベースで、線及び三角形に関して空間デリバティブを計算し、及び前記空間デリバティブを、パケットの形式でカル装置に送るセットアップ装置と；（ｆ）一度に、１タイル分のデータを受信し、及び大きさ比較内容アドレッサブル・メモリ（ＭＣＣＡＭ）カル・サブ装置及びサブピクセル・カル・サブ装置を有するカル装置であって、前記ＭＣＣＡＭカル・サブ装置は、以前に処理されたジオメトリによって完全に隠されるプリミティブを廃棄するように動作可能であり、及び前記サブピクセル・カル・サブ装置は、一部又は全体が可視である残りのプリミティブを処理し、及び前記残りのプリミティブの可視フラグメントを決定し、前記サブピクセル・カル・サブ装置は、一度に、１スタンプ分のフラグメントを出力する前記カル装置と；（ｇ）前記カル装置からの入力を受信し、及び前記ポリゴン・メモリから色及び素材プロパティを含むモード情報を検索し、及び前記モード情報を、フラグメント装置、テクスチャ装置、フォン装置、ピクセル装置、及びバックエンド装置の一つ以上に送るモード・インジェクション装置であって；前記フラグメント装置、前記テクスチャ装置、前記フォン装置、前記ピクセル装置、又は前記バックエンド装置の少なくともいくつかは、最近使用されたモード情報をキャッシュするためのモード・キャッシュを含み；すでにキャッシュされた情報を識別し、すでにキャッシュされた情報を送らず、それによって通信帯域幅を低減させる状態情報を維持する前記モード・インジェクション装置と；（ｈ）グロ��・シェーディングのための色値を補間し、フォン・シェーディングのための面法線及びテクスチャ・マッピングのためのテクスチャ座標を補間し、及びテクスチャを高さフィールド勾配として表すバンプ・マップが使用されている場合に、面接線を補間するためのフラグメント装置であって；重心係数を使用して、透視的修正補間を実行する前記フラグメント装置と；（ｉ）テクスチャ装置と、及び前記テクスチャ装置と関連するテクスチャ・メモリであって；前記テクスチャ装置は、前記テクスチャ・メモリに記憶されたテクスチャ・マップをピクセル・フラグメントに適用し；前記テクスチャ・マップはミップ・マップ（MIP-mapped）され、及び各マップが、アイ・ポイントから一定の距離にある前記テクスチャの外観を表す、異なるレベルのディテールで一連のテクスチャ・マップを具備し；前記テクスチャ装置は、正しいレベルのディテールに近似する一定のピクセル・フラグメントに関するテクスチャ値を作成するために、前記テクスチャ・マップからトリ・リニア補間を実行し；前記テクスチャ装置は、補間されたテクスチャ値を、フラグメントごとのベースで前記フォン装置に伝える、前記テクスチャ装置及びテクスチャ・メモリと；（ｊ）前記モード・インジェクション装置、前記テクスチャ装置からの前記テクスチャ色、及び前記フラグメントの外観の色を決定するために、前記フラグメント装置によって生成される前記面法線によって供給される素材及びライティング情報を使用して、各ピクセル・フラグメントに関してフォン・シェーディングを実行するためのフォン・ライティング装置であって；バンプ・マッピングが使用されている場合に、シェーディングの前に、前記フラグメントの面法線を摂動させるために、前記テクスチャ装置からの前記補間された高さフィールド勾配を任意で使用する前記フォン装置と；（ｋ）各フラグメントが個別の色値を有し、可視スタンプ・ポーション（Visible Stamp Portion）と称される、１スタンプ分のフラグメントを一度に受信し、及びピクセル・オーナシップ・テスト、シザー・テスト、アルファ・テスト、ステンシル・オペレーション、深度テスト、ブレンディング、ディザリング、及び各ピクセルにおける各サンプルでのロジック・オペレーションを実行し、及び１タイル分の仕上げられたピクセルを蓄積した後に、前記ピクセルをアンチ・エイリアスするために、各ピクセル内の前記サンプルをブレンドし、及び前記アンチ・エイリアスされたピクセルをバックエンド装置に伝えるピクセル装置と；及び（ｌ）前記ピクセル装置から、一度に１タイル分のピクセルを受信するために、前記ピクセル装置に接続され、及び前記ピクセルをフレーム・バッファに記憶する前記バックエンド装置とを具備するディファード・グラフィックス・パイプライン・プロセッサ。
【０４８１】
（２）レンダリングされた画像をグラフィックス・プリミティブから形成するためのグラフィックス・レンダリング・システムであって、前記レンダリングされた画像は、フレーム・バッファに記憶され：（Ａ）ホスト・プロセッサと；  （Ｂ）システム・メモリと；（Ｃ）ピクセルを記憶するフレーム・バッファと；  （Ｄ）（１）第一の直接メモリ・アクセス・コマンドと、及び２次元グラフィックス・オペレーションを実行するための第一のコマンドとを受信し及び記憶する２Ｄコマンド待ち行列メモリと；（２）第二の直接メモリ・アクセス・コマンドと、及び３次元グラフィックス・オペレーションを実行するための第二のコマンドとを受信し及び記憶する３Ｄコマンド待ち行列メモリであって、前記第二のコマンドは：前記グラフィックス・プリミティブのいくつかと；及びパイプライン状態の一部を具備する前記３Ｄコマンド待ち行列メモリと；（３）２次元グラフィックス・オペレーションを実行するための第三のコマンドを受信し及び記憶する２Ｄ応答待ち行列メモリと；（４）３次元グラフィックス・オペレーションを実行するための第四のコマンドを受信し及び記憶する３Ｄ応答待ち行列メモリであって、前記第四のコマンドは：前記グラフィックス・プリミティブのいくつかと；及び前記パイプライン状態の一部を具備する前記３Ｄ応答待ち行列メモリと；（５）前記２Ｄコマンド待ち行列メモリ及び前記３Ｄコマンド待ち行列メモリに接続された直接メモリ・アクセス・コントローラであって：（ａ）前記第三のコマンドを前記システム・メモリから読み取り、及び前記読み取られた第三のコマンドを、前記２Ｄ応答待ち行列へと書き込むことによって、前記記憶された第一の直接メモリ・アクセス・コマンドを受信し及び前記第一の直接メモリ・アクセス・コマンドを実行するロジックと；及び（ｂ）前記第四のコマンドを前記システム・メモリから読み取り、及び前記読み取られた第四のコマンドを前記３Ｄ応答待ち行列へと書き込むことによって、前記記憶された第二の直接メモリ・アクセス・コマンドを受信し及び前記第二の直接メモリ・アクセス・コマンドを実行するロジックとを具備する前記直接メモリ・アクセス・コントローラとを具備するコマンドを受信するための装置と：（Ｅ）（１）前記グラフィックス・プリミティブを変換するロジックと；（２）前記グラフィックス・プリミティブが、少なくとも部分的に、ビュー・ボリュームに含まれているか決定するために、前記グラフィックス・プリミティブをクリップ・テストするロジックと；（３）ビューイング・ポイントから逸れた方を向いている前記グラフィックス・プリミティブのいずれをも廃棄するために、面決定を実行するロジックとを具備するジオメトリ装置と：（Ｆ）（１）隠れ面除去に必要な前記パイプライン状態の部分と；（２）バーテックス場所を含む、隠れ面除去に必要な前記グラフィックス・プリミティブの部分とを具備するソート・メモリと：（Ｇ）（１）前記グラフィックス・プリミティブの属性とともに、フレームに関する前記グラフィックス・プリミティブと；及び（２）バーテックス色及びテクスチャ座標を含む、隠れ面除去に必要でない前記グラフィックス・プリミティブの部分とを記憶する状��メモリと：（Ｈ）（１）前記画像内におけるタイル領域に従って、前記グラフィックス・プリミティブをソートするロジックと；（２）タイルに従って、前記ソート・メモリから前記ソートされたグラフィックス・プリミティブを読み取るロジックとを具備するソート装置と；（Ｉ）前記ソートされたグラフィックス・プリミティブに関するデリバティブを計算するセットアップ装置と；（Ｊ）シーン・メモリに記憶された前記グラフィックス・プリミティブのどの部分が、前記フレーム・バッファにおける前記ピクセルの最終色に影響を与えるかを決定するために、隠れ面除去を実行するカル装置と；（Ｋ）前記各ピクセル内における各サンプル、又はサンプルのグループに関して、フラグメント色を生成するひとつ以上の計算装置であって、前記各ピクセルに関する色値の生成は、前記ピクセルに影響を与えると決定された前記グラフィックス・プリミティブの前記部分に関してのみ実行され：（１）前記グラフィックス・プリミティブに関連するデータを補間するための装置であって：（ａ）キャッシュ・フィル・ポリゴン色データ（cashe fill polygon color data）を記憶するメモリであって、前記色データは、バーテックス座標、ｗ座標、及びテクスチャ座標を具備する前記メモリと；（ｂ）前記バーテックス座標及び前記ｗ座標から前記グラフィックス・プリミティブの各々に関して、重心係数を計算するロジックと；（ｃ）複数の前記グラフィックス・プリミティブに対応する複数のデータ・キャッシュ・エントリを記憶するキャッシュ・メモリであって、前記キャッシュされたデータは、重心係数及びテクスチャ座標を具備する前記キャッシュ・メモリと；（ｄ）前記グラフィックス・プリミティブの一つのフラグメントを受信するレジスタであって、前記フラグメントは、フラグメント座標及びサンプル・マスクを具備し、前記サンプル・マスクは、前記フラグメントによって覆われる前記ピクセル内のサンプル場所を示す前記レジスタと；（ｅ）補間場所の低位ビットを決定するルックアップ・テーブルであって、前記ルックアップ・テーブルの入力は、前記サンプル・マスクを具備し、前記補間場所は、サブピクセル精度を有する前記ルックアップ・テーブルと；（ｆ）前記受信されたフラグメントに対応する前記記憶されたデータ・キャッシュ・エントリの一つを選択し及び読み取るロジックと；（ｇ）前記重心係数及び前記補間場所から補間係数を計算するロジックと；（ｈ）前記計算された補間係数を使用して、前記テクスチャ座標を補間し、前記補間場所においてテクスチャ座標を生成するロジックとを具備する前記装置と：（２）バーテックス面法線を補間するための装置であって：（ａ）前記バーテックス面法線の各々を、バーテックス大きさベクトル及びバーテックス方向ベクトルに分解するロジックと；（ｂ）複数の前記バーテックス大きさベクトル及び前記計算された補間係数から、補間された大きさベクトルを計算するロジックと；（ｃ）複数の前記バーテックス方向ベクトル及び前記計算された補間係数から、補間された方向ベクトルを計算するロジックと；及び（ｄ）補間された面法線を生成するために、前記補間された大きさベクトル及び前記補間された方向ベクトルを結合させるロジックとを具備する前記装置と：を具備する前記計算装置と  （Ｌ）（１）ピクセルごとの色値を生成するために、前記フラグメント色をブレンドするロジックと；及び（２）前記生成されたピクセルごとの色値を、前記フレーム・バッファに記憶するロジックとを具備するピクセル装置と、（Ｍ）（１）前記３次元オブジェクトが、前記グラフィックス・レンダリング・システムによって処理されると、オブジェクト・タグを、前記３次元オブジェクトと関連付けるロジックと；（２）前記３次元オブジェクトが、前記グラフィックス・レンダリング・システムにおいて処理されると、前記３次元オブジェクトを、一つ以上の可視性基準でテストするロジックと；（３）複数のビットを具備する状態レジスタと；（４）前記オブジェクト・タグの一つに従って、前記状態レジスタにおける前記ビットの一つを選択するロジックと；（５）前記可視性基準でのテストに合わせて、前記３次元オブジェクトの対応する一つの応答に従って、前記状態レジスタにおける前記選択されたビットの値を設定するロジックと；及び（６）前記ホスト・プロセッサへ、前記状態レジスタ内容を読み取り及び転送するロジックであって、前記ホスト・プロセッサは、前記３次元オブジェクトのいずれが、少なくとも部分的に可視であるかを決定する前記ロジックとを具備する状態モニタリング装置と（Ｎ）（１）ウィンドウ識別子マップを記憶する第一のメモリであって、前記ウィンドウ識別子マップは、前記フレーム・バッファにおける前記ピクセルの各々に関して、ウィンドウ識別子を具備する前記第一のメモリと（２）複数の文字枠記述を記憶する第二のメモリであって、前記文字枠記述の各々は、対応する文字枠及び文字枠ウィンドウ識別子の最大及び最小ピクセル座標を具備する前記第二のメモリと；（３）前記デジタル画像と関連する、プログラムに従って割り当てられた画像識別子を記憶するレジスタと；（４）前記デジタル画像から、画像ピクセルを選択するロジックと；（５）前記選択された画像ピクセル上で動作するピクセル・オーナシップ・ロジックであって：（ａ）プログラムに従って設定された制御ビットによって可能にされるウィンドウ識別子マップ・テスト・ロジックであって：（ｉ）前記選択された画像ピクセルに対応する前記第一のメモリから、前記ウィンドウ識別子を読み取るロジックと；（ii）前記割り当てられた画像識別子を、前記読み取られたウィンドウ識別子と比較するコンパリタ回路（comparitor circuit）と；及び（iii）前記割り当てられた画像識別子が、前記読み取られたウィンドウ識別子と適合しない場合、前記選択された画像ピクセルを廃棄するロジックと；を具備する前記ウィンドウ識別子マップ・テスト・ロジックと、（ｂ）プログラムに従って設定された制御ビットによって可能にされる文字枠テスト・ロジックであって：（ｉ）前記選択されたピクセルが、前記選択された第一の文字枠記述の前記最大及び最小ピクセル座標内に入るように、前記文字枠記述の第一の一つを選択するロジックと；（ii）前記割り当てられた画像識別子を、前記第一の文字枠記述の前記文字枠ウィンドウ識別子と比較するコンパリタ回路と；及び（iii）前記割り当てられた画像識別子が、前記第一の文字枠の前記文字枠ウィンドウ識別子と適合しない場合、前記選択された画像ピクセルを廃棄するロジックとを具備する前記文字枠テスト・ロジックと及び（ｃ）前記選択された画像ピクセルが廃棄されなかった場合に、前記選択された画像ピクセルを前記フレーム・バッファに書き込むロジックとを具備する前記ピクセル・オーナシップ・ロジックとを具備する、デジタル画像を前記フレーム・バッファに記憶するための装置と、（Ｏ）（１）前記ピクセル値が前記フレーム・バッファに記憶されると、前記レンダリングされた画像において、前記ピクセル値のヒストグラムを生成するロジックと；（２）前記デジタル−アナログ・コンバータに適合するように、前記ピクセル値の前記スケール及び動的な範囲を調整するために、前記ヒストグラムに基づいて、変換関数を計算するロジックと；（３）ラスタ線のオーダで、前記フレーム・バッファから前記ピクセル値を読み取るロジックと；（４）前記計算された変換関数に従って、前記読み取られたピクセル値を変換するロジックと；及び（５）前記変換されたピクセル値を、前記デジタル−アナログ・コンバータに入力するロジックとを具備するスキャンアウト装置と（Ｐ）（１）プログラムに従ってダウンロードされた補間係数を記憶するメモリと；（２）プログラムに従って選択された、複数の固定ズーム比の一つを記憶するレジスタと；（３）プログラムに従って選択された、コンピュータ・ディスプレイ内におけるズーム文字枠の場所を記憶するレジスタと；（４）プログラムに従って割り当てられた、前記ズーム文字枠と関連するウィンドウ識別子を記憶するレジスタと；（５）前記フレーム・バッファから第一のピクセル色を読み取るロジックと；（６）前記フレーム・バッファから複数の第二のピクセル色を読み取るロジックと；（７）前記複数の第二のピクセル色及び前記ダウンロードされた補間係数から、ズームされたピクセル色を計算するロジックと；（８）前記フレーム・バッファから、ピクセル・ウィンドウ識別子を読み取るロジックと；（９）前記ディスプレイ・ピクセルが、前記ズーム文字枠内にあり、及び前記ピクセル・ウィンドウ識別子が、前記ズーム文字枠に割り当てられた前記ウィンドウ識別子と等しい場合、前記計算されたズーム・ピクセル色を、前記デジタル−アナログ・コンバータに送るロジックと；（１０）前記ディスプレイ・ピクセルが、前記ズーム文字枠内になく、又は前記ピクセル・ウィンドウ識別子が、前記ズーム文字枠に割り当てられた前記ウィンドウ識別子と等しくない場合、前記読み取られた第一のピクセル色を、前記デジタル−アナログ・コンバータに送るロジックと；を具備するスキャンアウト装置とを具備する前記グラフィックス・レンダリング装置。
【０４８２】
（３）前記グラフィックス・オブジェクトから、フレーム・バッファにおいてレンダリングされた画像を形成するためのグラフィックス・レンダリング方法であって、前記グラフィックス・オブジェクトは複数のグラフィックス・プリミティブを具備し：タグを前記オブジェクトに割り当てるステップと；前記オブジェクトが前記グラフィックス・レンダリング・パイプラインにおいて処理されると、一つ以上の可視性基準で前記オブジェクトテストするステップであって、前記各オブジェクトの前記テストは、前記オブジェクト内における前記プリミティブの前記テストを含む前記ステップと；前記可視性基準に従った前記テストに合わせて、前記タグされたオブジェクトの応答を示す、状態ワードにおけるビットを設定するステップと；及び前記オブジェクトのいずれが、少なくとも部分的に可視であるかを決定するため、前記状態ワードを読み取るステップとを具備する前記方法。
（４）（３）に記載のグラフィックス・レンダリング方法であって：前記オブジェクトの文字枠ボリューム（bounding volume）に近似するように、前記グラフィックス・プリミティブの前記入力を含む、前記グラフィックス・オブジェクトの入力ステップと；前記文字枠ボリュームの可視性を決定するために、前記状態ワードを読み取るステップと；前記対応する文字枠ボリュームが、可視でないと決定される時に、前記オブジェクトを廃棄するステップと；をさらに具備する前記方法。
（５）（３）に記載のグラフィックス・レンダリング方法であって：前記グラフィックス・オブジェクトを受け取るステップと；前記グラフィックス・プリミティブをメモリに記憶することによって、複数の前記オブジェクトを蓄積するステップと；前記フレーム・バッファにおいて、最終結果に影響を与えないものと保証される前記プリミティブの部分を除去するために、前記蓄積されたオブジェクトを処理するステップと；及び前記状態ワードの読み取りステップを実行する前に、複数の前記オブジェクト上で、前記蓄積されたオブジェクトを処理するステップを実行するステップであって、前記状態ワードはそれから、前記複数の蓄積されたオブジェクトの各々の可視性を決定するために使用される前記ステップとをさらに具備する前記方法。
（６）フレーム・バッファにレンダリングされた画像を形成し、及び前記レンダリングされた画像をディスプレイに表示するためのグラフィックス・レンダリング方法であって：複数のグラフィックス・プリミティブを受け取るステップと；一列のピクセル値を生成するために、前記グラフィックス・プリミティブをレンダリングするステップと；前記フレーム・バッファにおいて前記ピクセル値を記憶するステップと；前記フレーム・バッファにおいて、前記ピクセル値のヒストグラムを生成するステップと；デジタル−アナログ・コンバータに適合するように、前記ピクセル値のスケール及び動的な範囲を調節するために、前記ヒストグラムに基づいて、変換関数を計算するステップと；ラスタ・スキャンアウト方法で、前記フレーム・バッファから、前記ピクセル値を読み取るステップと；前記計算された変換関数に従って、前記読み取られたピクセル値を変換するステップと；アナログ信号を生成するために、前記変換されたピクセル値を、前記デジタル−アナログ・コンバータに入力するステップと；及び前記アナログ信号を、前記ディスプレイに送るステップとを具備する前記グラフィックス・レンダリング方法。
（７）（６）に記載のグラフィックス・レンダリング方法であって、前記記憶ステップは、前記フレーム・バッファにおいて前記ピクセル値を示すために、浮動小数点値を記憶することを特徴とする、前記グラフィックス・レンダリング方法。
（８）（６）に記載のグラフィックス・レンダリング方法であって、前記変換方法は：その範囲の圧縮又は拡張、線形圧縮又は拡張、対数圧縮、指数又は電力拡張、他の代数又は多項式マッピング関数、及びそれらの組み合わせをすることなく、ある範囲の値を、異なる範囲の値にオフセット又はシフトすることを含むグループから選択されるオペレーションの一つ以上を伴うことを特徴とする前記グラフィックス・レンダリング方法。
【０４８３】
（９）フレーム・バッファに記憶された、レンダリングされた画像を形成するためのグラフィックス・レンダリング方法であって：グラフィックス・プリミティブを受け取るステップと；前記グラフィックス・プリミティブを変換するステップと；前記グラフィックス・プリミティブが少なくとも部分的に、ビュー・ボリュームに含まれるか決定するために、前記グラフィックス・プリミティブをクリップ・テストするステップと；ビューイング・ポイントから逸れた方を向いている前記グラフィックス・プリミティブのいずれをも廃棄するために面決定をするステップと；前記デリバティブの計算を含む、前記グラフィックス・プリミティブに関する増分レンダリングのためのセットアップを実行するステップと；シーン・メモリに：（１）前記グラフィックス・プリミティブの属性とともに、フレームに関する前記グラフィックス・プリミティブと；及び（２）前記フレーム全体の、パイプライン状態の様々な設定、を記憶するステップと；前記シーン・メモリに記憶された前記グラフィックス・プリミティブのどの部分が、前記フレーム・バッファにおけるピクセルの最終色に影響を与えるかを決定するために、隠れ面除去をするステップと；各フラグメントに関する色値を生成するためにフラグメント・カラリングをするステップであって、各フラグメントは、前記ピクセルの一つの中の一つのサンプル又はサンプルのグループを含み、前記フラグメントの各々に関する色値の生成は、前記フレーム・バッファにおけるピクセルの最終色に影響を与えると決定された前記グラフィックス・プリミティブの部分に関してのみ実行される前記ステップと；ピクセルごとに単一の色値を生成するために、前記フラグメント色をブレンドするステップと；及び前記生成されたピクセルごとの色値を、フレーム・バッファに記憶するステップとを具備する前記グラフィックス・レンダリング方法。
（１０）フレーム・バッファに記憶された、レンダリングされた画像を形成するためのグラフィックス・レンダリング方法であって：グラフィックス・プリミティブを受け取るステップと；前記グラフィックス・プリミティブを変換するステップと；前記グラフィックス・プリミティブが少なくとも部分的に、ビュー・ボリュームに含まれるか決定するために、前記グラフィックス・プリミティブをクリップ・テストするステップと；ビューイング・ポイントから逸れた方を向いている前記グラフィックス・プリミティブのいずれをも廃棄するために面決定をするステップと；前記デリバティブの計算を含む、前記グラフィックス・プリミティブに関する増分レンダリングのためのセットアップを実行するステップと；空間メモリに：（１）隠れ面除去に必要な前記パイプラインの部分と；及び（２）バーテックス場所及び空間デリバティブを含む、隠れ面除去に必要なグラフィックス・プリミティブの部分とを記憶するステップと；ポリゴン・メモリに：（１）隠れ面除去に必要ない前記パイプライン状態の部分と；及び（２）バーテックス色、テクスチャ座標、及び色デリバティブを含む、隠れ面除去に必要ない前記グラフィックス・プリミティブの部分と、を記憶するステップと；前記空間メモリに記憶された前記グラフィックス・プリミティブのどの部分が、前記フレーム・バッファにおけるピクセルの最終色に影響を与えるかを決定するために、隠れ面除去をするステップと；各フラグメントに関する色値を生成するために、フラグメント・カラリングをするステップであって、各フラグメントは、前記ピクセルの一つの中で、一つのサンプル又はサンプルのグループを具備し、前記フラグメントの各々に関する色値の生成は、前記フレーム・バッファにおけるピクセルの前記最終色に影響を与えると決定された前記グラフィックス・プリミティブの前記部分に関してのみ実行される前記ステップと；単一の色値をピクセルごとに生成するために、前記フラグメント色をブレンドするステップと；及び前記生成されたピクセルごとの色値を、前記フレーム・バッファに記憶するステップとを具備する前記グラフィックス・レンダリング方法。
【０４８４】
（１１）フレーム・バッファに記憶された、レンダリングされた画像を形成するためのグラフィックス・レンダリング方法であって：グラフィックス・プリミティブを受け取るステップと；前記グラフィックス・プリミティブを変換するステップと；前記グラフィックス・プリミティブが少なくとも部分的に、ビュー・ボリュームに含まれるか決定するために、前記グラフィックス・プリミティブをクリップ・テストするステップと；ビューイング・ポイントから逸れた方を向いている前記グラフィックス・プリミティブのいずれをも廃棄するために面決定をするステップと；前記画像内のタイル領域に従って、前記グラフィックス・プリミティブをソートするステップと；ソート・メモリに：（１）隠れ面除去に必要な前記パイプライン状態の部分と；及び（２）バーテックス場所を含む、隠れ面除去に必要な前記グラフィックス・プリミティブの部分と、を記憶するステップと；状態メモリに：（１）隠れ面除去に必要ない前記パイプライン状態の部分と；及び（２）バーテックス色及びテクスチャ座標を含む、隠れ面除去に必要ない前記グラフィックス・プリミティブの部分と、を記憶するステップと；タイルに従って、前記ソート・メモリから前記ソートされたグラフィックス・プリミティブを読み取るステップと；前記デリバティブの計算を含む、前記ソート・メモリから読み取られた、前記ソートされたグラフィックス・プリミティブ上で、増分レンダリングに関するセットアップを実行するステップと；前記ソートされたグラフィックス・プリミティブのどの部分が、前記フレーム・バッファにおけるピクセルの最終色に影響を与えるかを決定するために、隠れ面除去をするステップと；各フラグメントに関する色値を生成するために、フラグメント・カラリングをするステップであって、各フラグメントは、前記ピクセルの一つの中で、一つのサンプル又はサンプルのグループを具備し、前記フラグメントの各々に関する色値の生成は、前記フレーム・バッファにおけるピクセルの前記最終色に影響を与えると決定された前記グラフィックス・プリミティブの前記部分に関してのみ実行される前記ステップと；単一の色値をピクセルごとに生成するために、前記フラグメント色をブレンドするステップと；及び前記生成されたピクセルごとの色値を、前記フレーム・バッファに記憶するステップとを具備する前記グラフィックス・レンダリング方法。
（１２）コンピュータ・ディスプレイ上のウィンドウ内で、グラフィックス画像を表示するための方法であって：フレーム・バッファに画像を記憶するステップと；補間係数をダウンロードするステップと；複数の固定ズーム比の一つを選択するステップと；前記コンピュータ・ディスプレイ内にズーム文字枠を配置するステップと；前記ズーム文字枠に、ウィンドウ識別子を割り当てるステップと；前記コンピュータ・ディスプレイ内での表示ピクセルに関して、ピクセル・データをデジタル−アナログ・コンバータに送るステップであって、さらに：前記フレーム・バッファから第一のピクセル色を読み取るステップと；前記フレーム・バッファから、複数の第二のピクセル色を読み取るステップと；前記複数の第二のピクセル色及び前記ダウンロードされた補間係数から、ズームされたピクセル色を計算するステップと；前記フレーム・バッファから、ピクセル・ウィンドウ識別子を読み取るステップと；前記ディスプレイ・ピクセルが、前記ズーム文字枠内にあり、及び前記ピクセル・ウィンドウ識別子が、前記ズーム文字枠に割り当てられた前記ウィンドウ識別子に等しい場合、前記計算されたズーム・ピクセル色を、前記デジタル−アナログ・コンバータに送るステップと；及び前記ディスプレイ・ピクセルが、前記ズーム文字枠内になく、又は前記ピクセル・ウィンドウ識別子が、前記ズーム文字枠に割り当てられた前記ウィンドウ識別子と等しくない場合、前記読み取られた第一のピクセル色を、前記デジタル−アナログ・コンバータに送るステップとを具備する前記送信ステップとを具備する前記方法。
【０４８５】
（１３）デジタル画像をフレーム・バッファに記憶するための方法であって、前記フレーム・バッファは、一列のピクセルを具備し：ウィンドウ識別子マップを記憶するステップであって、前記ウィンドウ識別子マップは、前記フレーム・バッファにおける前記ピクセルの各々に関して、ウィンドウ識別子を具備する前記ステップと；複数の文字枠記述を記憶するステップであって、前記文字枠記述の各々は、前記対応する文字枠及び文字枠ウィンドウ識別子の最大及び最小ピクセル座標を具備する前記ステップと；画像識別子を前記デジタル画像に割り当てるステップと；画像ピクセルを前記デジタル画像から選択するステップと；前記選択された画像ピクセルをオーナシップ・テストするステップであって：ウィンドウ識別子マップ・テストが可能にされる場合は、前記ウィンドウ識別子マップ・テストが実行され：前記ウィンドウ識別子を、前記選択された画像ピクセルに対応する前記ウィンドウ識別子マップから読み取るステップと；前記割り当てられた画像識別子を、前記読み取られたウィンドウ識別子と比較するステップと；及び前記割り当てられた画像識別子が、前記読み取られたウィンドウ識別子と適合しない場合、前記選択されたピクセルは廃棄され、及び前記フレーム・バッファに書き込まれないステップを具備する前記前記ウィンドウ識別子マップ・テストと；及び文字枠テストが可能にされる場合には、前記文字枠テストが実行され：前記選択されたピクセルが、前記第一の文字枠記述の最大及び最小ピクセル座標内に入るように、前記文字枠記述の第一の一つを選択するステップと；前記割り当てられた画像識別子を、前記第一の文字枠記述の前記文字枠ウィンドウ識別子と比較するステップと；前記割り当てられた画像識別子が、前記第一の文字枠記述の前記文字枠ウィンドウ識別子に適合しない場合、前記選択されたピクセルが廃棄され、及び前記フレーム・バッファに書き込まれないステップとを具備する前記文字枠テストと；及び    前記選択された画像ピクセルが廃棄されなかった場合、前記選択された画像ピクセルを前記フレーム・バッファに書き込むステップとを具備する前記オーナシップ・テストをするステップとを具備する前記方法。
（１４）前記ウィンドウ識別子マップを前記フレーム・バッファに記憶するステップをさらに具備することを特徴とする、デジタル画像をフレーム・バッファに記憶するための、（１３）に記載の方法。
（１５）オーナシップ・テストの前記ステップが、複数のピクセル上で並行して実行されることを特徴とする、デジタル画像をフレーム・バッファに記憶するための、（１３）に記載の方法。
【０４８６】
（１６）コンピュータ・グラフィックス・プロセッサにおいてコマンドを受け取るための装置であって：第一の直接メモリ・アクセス・コマンド及び２次元グラフィックス・オペレーションを実行するための第一のコマンドを受け取り及び記憶する２Ｄコマンド待ち行列メモリと；第二の直接メモリ・アクセス・コマンドと、及び３次元グラフィックス・オペレーションを実行するための第二のコマンドを受け取り及び記憶する３Ｄコマンド待ち行列メモリと；２次元グラフィックス・オペレーションを実行するための第三のコマンドを受け取り及び記憶する２Ｄ応答待ち行列メモリと；３次元グラフィックス・オペレーションを実行するための第四のコマンドを受け取り及び記憶する３Ｄ応答待ち行列メモリと；前記２Ｄコマンド待ち行列メモリ及び前記３Ｄコマンド待ち行列メモリに接続された直接メモリ・アクセス・コントローラであって：（１）前記コンピュータ・グラフィックス・パイプラインの外部にあるメモリから、前記第三のコマンドを読み取り、及び前記読み取られた第三のコマンドを、前記２Ｄ応答待ち行列に書き込むことによって、前記記憶された第一の直接メモリ・アクセス・コマンドを受け取り及び前記第一の直接メモリ・アクセス・コマンドを実行する第一のロジックと；及び（２）前記コンピュータ・グラフィックス・パイプラインの外部にあるメモリから、前記第四のコマンドを読み取り、及び前記読み取られた第四のコマンドを、前記３Ｄ応答待ち行列に書き込むことによって、前記記憶された第二の直接メモリ・アクセス・コマンドを受け取り、及び前記第二の直接メモリ・アクセス・コマンドを実行する第二のロジックとを具備する前記直接メモリ・アクセス・コントローラとを具備する前記装置。
（１７）コンピュータ・グラフィックス・プロセッサにおいてコマンドを受け取るための、（１６）に記載の装置であって：前記２Ｄコマンド待ち行列メモリにおいて許可されるエントリの数を記憶するプログラム可能２Ｄ最高点レジスタと；及び前記２Ｄコマンド待ち行列メモリにおけるエントリの数が、前記２Ｄ最高点レジスタに記憶された数よりも大きい時、割り込みを生成するロジックとをさらに具備することを特徴とする、前記装置。
（１８）コンピュータ・グラフィックス・プロセッサにおいてコマンドを受け取るための、（１７）に記載の装置であって：前記２Ｄコマンド待ち行列への書き込みが許可される前に、前記２Ｄコマンド待ち行列メモリにおけるエントリの最大数を記憶するプログラム可能２Ｄ最低点レジスタと；及び前記２Ｄコマンド待ち行列メモリにおけるエントリの数が、前記２Ｄ最高点レジスタに記憶された数よりも小さい時、割り込みを生成するロジックとをさらに具備することを特徴とする、前記装置。
（１９）コンピュータ・グラフィックス・プロセッサにおいてコマンドを受け取るための、（１６）に記載の装置であって：前記３Ｄコマンド待ち行列メモリにおいて許可されるエントリの数を記憶するプログラム可能３Ｄ最高点レジスタと；前記３Ｄコマンド待ち行列メモリにおけるエントリの数が、前記３Ｄ最高点レジスタに記憶された数よりも大きい時、割り込みを生成するロジックと
をさらに具備することを特徴とする、前記装置。
（２０）コンピュータ・グラフィックス・プロセッサにおいてコマンドを受け取るための、（１９）に記載の装置であって：前記３Ｄコマンド待ち行列への書き込みが許可される前に、前記３Ｄコマンド待ち行列メモリにおけるエントリの最大数を記憶するプログラム可能３Ｄ最低点レジスタと；及び前記３Ｄコマンド待ち行列メモリにおけるエントリの数が、前記３Ｄ最高点レジスタに記憶された数よりも小さい時、割り込みを生成するロジックとをさらに具備する前記装置。
【０４８７】
（２１）コンピュータ・グラフィックス・プロセッサにおいてコマンドを受け取るための、（１６）に記載の装置であって：グラフィックス・データを記憶するフレーム・バッファと；ホスト待ち行列メモリと；第三の直接メモリ・アクセス・コマンドをさらに受け取り、及びさらに記憶する前記２Ｄコマンド待ち行列メモリと；前記フレーム・バッファ、前記ホスト待ち行列メモリ、及び前記２Ｄコマンド待ち行列メモリに接続された２Ｄグラフィックス装置であって：前記コンピュータ・グラフィックス・パイプラインの外部にあるメモリへの、前記フレーム・バッファからの、前記グラフィックス・データのいくつかの転送を特定する第一のコマンドを読み取るロジックと；及びグラフィックス・データを前記フレーム・バッファから読み取り、及び前記読み取られたグラフィックス・データを前記ホスト待ち行列に記憶するロジックであって、前記第一のロジックはさらに、前記ホスト待ち行列から前記グラフィックス・データを読み取り、及び前記コンピュータ・グラフィックス・パイプラインの外部にある前記メモリへ、前記ホスト待ち行列から読み取られた前記グラフィックス・データを書き込むことによって、前記第三の直接メモリ・アクセス・コマンドを実行するロジックとを具備する前記２Ｄグラフィックス装置と；をさらに具備する前記装置。
（２２）コンピュータ・グラフィックス・プロセッサにおいてコマンドを受け取るための、（１６）に記載の装置であって：第四の直接メモリ・アクセス・コマンドをさらに受け取り及びさらに記憶する前記２Ｄコマンド待ち行列メモリと；前記ホスト待ち行列から前記グラフィックス・データを読み取り、及び前記ホスト待ち行列から読み取られた前記グラフィックス・データを、前記３Ｄ応答待ち行列メモリを書き込むことによって、前記第四の直接メモリ・アクセス・コマンドを実行するロジックをさらに具備する前記第一のロジックと、をさらに具備する前記装置。
（２３）コンピュータ・グラフィックス・プロセッサにおいてコマンドを受け取るための、（１６）に記載の装置であって：前記３Ｄコマンド待ち行列メモリに接続された３Ｄコマンド・デコーダであって：前記３Ｄコマンド待ち行列メモリから第二のコマンドを読み取るロジックと；及び前記読み取られた第二のコマンド上で、データ・フォーマット変換を実行するロジックとを具備する前記３Ｄコマンド・デコーダをさらに具備する前記装置。
（２４）コンピュータ・グラフィックス・プロセッサにおいてコマンドを受け取るための、（１６）に記載の装置であって：前記３Ｄコマンド待ち行列メモリに接続された３Ｄコマンド・デコーダであって：前記３Ｄコマンド待ち行列メモリから、第二のコマンドを読み取るロジックと；及び無効な第二のコマンドを検出し、及び無効なコマンド割り込みを生成するロジックとを具備する前記３Ｄコマンド・デコーダとをさらに具備する前記装置。
（２５）コンピュータ・グラフィックス・パイプラインにおいて、グラフィックス・プリミティブと関連するデータを補間する方法であって：バーテックス座標、ｗ座標、及びテクスチャ座標を具備する色データを受け取るステップと；  前記グラフィックス・プリミティブの各々に関して重心係数を計算するステップと；複数の前記グラフィックス・プリミティブに対応する複数のデータ・キャッシュ・エントリを記憶するステップであって、前記キャッシュされたデータは、重心係数及びテクスチャ座標を具備する前記ステップと；フラグメント座標を具備するグラフィックス・プリミティブ・フラグメントを受け取るステップと；前記受け取られたグラフィックス・プリミティブ・フラグメントに対応する前記記憶されたデータ・キャッシュ・エントリの一つを選択し及び読み取るステップと；前記重心係数及び前記フラグメント座標から補間係数を計算するステップと；及び前記計算された補間係数を使用して、前記テクスチャ座標を補間するステップと；を具備する前記方法。
（２６）コンピュータ・グラフィックス・パイプラインにおいてテクスチャ座標を補間する方法であって：バーテックス座標、ｗ座標、及びテクスチャ座標を具備するグラフィックス・プリミティブを受け取るステップと；前記グラフィックス・プリミティブのフラグメントを受け取るステップであって、前記フラグメントは、サンプル・マスクを具備し、前記サンプル・マスクは、前記フラグメントによって覆われたピクセルの中のサンプル場所を示す前記ステップと；前記サンプル・マスクを、プログラム可能ルックアップ・テーブルに入力することによって、前記ピクセル内に補間座標を決定するステップであって、前記ルックアップ・テーブルの前記出力は、前記ピクセル内の前記補間座標であって、前記補間座標はサブ・ピクセル精度を有する前記ステップと；前記補間座標、前記バーテックス座標、及び前記ｗ座標を使用して、補間係数を計算するステップと；及び前記計算された補間係数を使用して、前記テクスチャ座標を補間し、前記補間座標においてテクスチャ座標を生成するステップとを具備する前記方法。
（２７）コンピュータ・グラフィックス・パイプラインにおいて面法線を補間する方法であって：バーテックス座標、ｗ座標、及びバーテックス面法線を具備するグラフィックス・プリミティブを受け取るステップと；前記グラフィックス・プリミティブのフラグメントを受け取るステップであって、前記フラグメントは、単一のピクセル内における前記グラフィックス・プリミティブの一部である前記ステップと；前記ピクセル内における補間座標を決定するステップと；前記補間座標、前記バーテックス座標、及び前記ｗ座標を使用して、補間係数を計算するステップと；前記バーテックス面法線の各々を、バーテックス大きさベクトル及びバーテックス方向ベクトルに分解するステップと；複数の前記バーテックス大きさベクトル及び前記計算された補間係数から、補間された大きさベクトルを計算するステップと；複数の前記バーテックス方向ベクトル及び前記計算された補間係数から、補間された方向ベクトルを計算するステップと；及び補間された面法線を生成するために、前記補間された大きさベクトル及び前記補間された方向ベクトルを結合させるステップとを具備する前記方法。
【０４８８】
（２８）コンピュータ・グラフィックス・パイプラインのための状態モニタリング装置であって、前記コンピュータ・グラフィックス・パイプラインは、複数の３次元オブジェクトを処理することによって、フレーム・バッファにレンダリングされた画像を形成し、前記３次元オブジェクトはそれぞれ、グラフィックス・プリミティブを具備し：前記３次元オブジェクトが前記コンピュータ・グラフィックス・パイプラインによって処理されると、オブジェクト・タグを前記３次元オブジェクトと関連付けるロジックと；前記３次元オブジェクトが、前記グラフィックス・レンダリング・パイプラインにおいて処理されると、前記３次元オブジェクトオブジェクトを一つ以上の可視性基準でテストするロジックと；複数のビットを具備する状態レジスタと；前記オブジェクト・タグの一つに従って、前記状態レジスタにおいて前記ビットの一つを選択するロジックと；前記可視性基準での前記テストに合わせて、前記３次元オブジェクトの前記対応する一つの応答に従って、前記状態レジスタにおいて前記選択されたビットの値を設定するロジックと；及びホストＣＰＵへの前記状態レジスタ内容を読み取り、及び転送するロジックであって、前記ＣＰＵは、前記３次元オブジェクトのいずれが、少なくとも部分的に可視であるかを決定する前記ロジックとを具備する前記状態モニタリング装置。
（２９）（２８）に記載の状態モニタリング装置であって：前記３次元オブジェクトの文字枠ボリュームを表すグラフィックス・プリミティブを生成するロジックと；及びホストＣＰＵへの前記状態レジスタ内容を読み取り、及び転送するロジックであって、前記ホストＣＰＵは、前記文字枠ボリュームのいずれが少なくとも部分的に可視であるかを決定し、及び少なくとも部分的に可視であると決定されないさらなる処理から、前記オブジェクトを廃棄する前記ロジックとをさらに具備する前記状態モニタリング装置。
（３０）（２８）に記載の状態モニタリング装置であって：複数の前記３次元オブジェクトを蓄積するメモリと；前記フレーム・バッファにおいて、前記コンピュータ・グラフィックス・パイプラインから、前記レンダリングされた画像に影響を与えないことを保証されている、前記グラフィックス・プリミティブの部分を除去するロジックと；及び前記３次元オブジェクトが、前記コンピュータ・グラフィックス・パイプラインによって処理されると、１つにつき１つのベースで、複数の前記オブジェクト・タグを、複数の前記３次元オブジェクトと自発的に関連させるロジックであって、前記状態レジスタはそれから、前記蓄積されたオブジェクトの各々の可視性を決定するために使用される前記ロジックとをさらに具備することを特徴とする、前記状態モニタリング装置。
【０４８９】
（３１）コンピュータ・グラフィックス・パイプラインのためのスキャンアウト装置であって、前記パイプラインは、ピクセル値のレンダリングされた画像を、フレーム・バッファに記憶し、及びデジタル−アナログ・コンバータを具備し：前記ピクセル値が、前記フレーム・バッファに記憶されると、前記レンダリングされた画像において前記ピクセル値のヒストグラムを生成するロジックと；前記ヒストグラムに基づいて、前記デジタル−アナログ・コンバータのスケール及び動的な範囲に実質的に適合するように、前記ピクセル値のスケール及び動的な範囲を調節するために、変換関数を計算するロジックと；ラスタ線のオーダで、前記フレーム・バッファから、前記ピクセル値を読み取るロジックと；前記計算された変換関数に従って、前記読み取られたピクセル値を変換するロジックと；及び前記変換されたピクセル値を、前記デジタル−アナログ・コンバータに入力するロジックとを具備する前記装置。
（３２）（３１）に記載のスキャンアウト装置であって、前記フレーム・バッファは、浮動小数点ピクセル値を記憶するためのメモリをさらに具備し；ヒストグラムを生成する前記ロジックは、入力浮動小数点ピクセル値として扱われる、浮動小数点計算ブロックをさらに具備し；及び前記計算された変換関数に従って、前記読み取られたピクセル値を変換する前記ロジックは、前記読み取られたピクセル値を変換する浮動小数点計算ブロックと、及び浮動小数点変換ピクセル値を、整数変換ピクセル値に変換するためのフォーマット変換ブロックとをさらに具備することを特徴とする、前記装置。
（３３）（３１）に記載のスキャンアウト装置であって、前記読み取られたピクセル値を変換する前記ロジックは：ある範囲の値を、その範囲の圧縮又は拡張、線形圧縮又は拡張、対数圧縮、指数又は電力拡張、他の代数又は多項式マッピング関数、又はそれらの組み合わせをすることなく、異なる範囲の値へのオフセット又はシフトを含むグループから選択されたオペレーションの一つ以上を実行するロジックを具備することを特徴とする、前記装置。
（３４）グラフィックス・プリミティブから、レンダリングされた画像を形成するためのグラフィックス・レンダリング装置であって、前記レンダリングされた画像はフレーム・バッファに記憶されており：（ａ）（１）前記グラフィックス・プリミティブを変換するロジックと；（２）前記グラフィックス・プリミティブが少なくとも部分的にビュー・ボリュームに含まれるか決定するために、前記グラフィックス・プリミティブをクリップ・テストするロジックと；（３）ビュー・ポイントから逸れた方を向いている前記グラフィックス・プリミティブのいずれをも廃棄するために、面決定を実行するロジックと；を具備するジオメトリ装置と；（ｂ）デリバティブを計算するセットアップ装置と；（ｃ）（１）前記グラフィックス・プリミティブの属性とともに、フレームに関する前記グラフィックス・プリミティブと；及び（２）前記フレーム全体の、パイプライン状態の様々な設定と；を記憶するシーン・メモリと（ｄ）前記シーン・メモリに記憶された前記グラフィックス・プリミティブのどの部分が、前記フレーム・バッファにおけるピクセルの最終色に影響を与えるのかを決定するために、隠れ面除去を実行するカル装置と；（ｅ）前記各ピクセル内において、各サンプル又はサンプルのグループに関してフラグメント色値を生成する一つ以上の計算装置であって、前記ピクセルの各々に関する色値の生成は、前記ピクセルに影響を与えると決定された前記グラフィックス・プリミティブの部分に関してのみ実行される、前記計算装置と；及び（ｆ）（１）ピクセルごとの色値を生成するために、前記フラグメント色をブレンドするロジックと；及び（２）前記生成されたピクセルごとの色値を、前記フレーム・バッファに記憶するロジックとを具備するピクセル装置とを具備する前記グラフィックス・レンダリング装置。
【０４９０】
（３５）グラフィックス・プリミティブからレンダリングされた画像を形成するためのグラフィックス・レンダリング装置であって、前記レンダリングされた画像はフレーム・バッファに記憶され：（ａ）（１）前記グラフィックス・プリミティブを変換するロジックと；（２）前記グラフィックス・プリミティブが少なくとも部分的にビュー・ボリュームに含まれるかを決定するために、前記グラフィックス・プリミティブをクリップ・テストするロジックと；（３）ビューイング・ポイントから逸れた方を向いている前記グラフィックス・プリミティブのいずれをも廃棄するために、面決定を実行するロジックと；を具備するジオメトリ装置と；（ｂ）デリバティブを計算するセットアップ装置であって、前記デリバティブは、空間デリバティブ及び色デリバティブを具備する前記セットアップ装置と；（ｃ）（１）隠れ面除去に必要なパイプラインの部分と；及び（２）バーテックス場所及び前記空間デリバティブを含む、隠れ面除去に必要な前記グラフィックス・プリミティブの部分と；を記憶する空間メモリと；  （ｄ）（１）隠れ面除去に必要ないパイプライン状態の部分と；及び（２）バーテックス色、テクスチャ座標、及び前記色デリバティブを含む、隠れ面除去に必要ない前記グラフィックス・プリミティブの部分とを記憶するポリゴン・メモリと；（ｅ）前記シーン・メモリに記憶されたグラフィックス・プリミティブのどの部分が、前記フレーム・バッファにおけるピクセルの最終色に影響を与えるかを決定するために、隠れ面除去を実行するカル装置と；（ｆ）前記各ピクセル内の各サンプル又はサンプルのグループに関して、フラグメント色値を生成する一つ以上の計算装置であって、前記ピクセルの各々に関する色値の生成は、前記ピクセルに影響を与えると決定されたグラフィックス・プリミティブの部分に関してのみ実行される、前記計算装置と；及び（ｇ）（１）ピクセルごとに色値を生成するために、前記フラグメント色をブレンドするロジックと；        （２）前記生成されたピクセルごとの色値を、前記フレーム・バッファに記憶するロジックと；を具備するピクセル装置とを具備する前記グラフィックス・レンダリング装置。
（３６）グラフィックス・プリミティブから、レンダリングされた画像を形成するためのグラフィックス・レンダリング装置であって、前記レンダリングされた画像はフレーム・バッファに記憶され：（ａ）（１）前記グラフィックス・プリミティブを変換するロジックと；（２）前記グラフィックス・プリミティブが、少なくとも部分的にビュー・ボリュームに含まれるかを決定するために、前記グラフィックス・プリミティブをクリップ・テストするロジックと；（３）前記ビューイング・ポイントから逸れた方を向いている前記グラフィックス・プリミティブのいずれをも廃棄するために、面決定を実行するロジックと；      を具備するジオメトリ装置と；（ｂ）（１）隠れ面除去に必要な前記パイプラインの部分と；及び（２）バーテックス場所を含む、隠れ面除去に必要な前記グラフィックス・プリミティブの部分と；を記憶するソート・メモリと；（ｃ）（１）前記グラフィックス・プリミティブの属性とともに、フレームに関する前記グラフィックス・プリミティブと；及び（２）バーテックス色及びテクスチャ座標を含む、隠れ面除去に必要ない前記グラフィックス・プリミティブの部分とを記憶する状態メモリと；（ｄ）（１）前記画像内のタイル領域に従って、前記グラフィックス・プリミティブをソートするロジックと；（２）タイルに従って、前記ソート・メモリから前記ソートされたグラフィックス・プリミティブを読み取るロジックとを具備するソート装置と；（ｅ）前記ソートされたグラフィックス・プリミティブに関してデリバティブを計算するセットアップ装置と；  （ｆ）前記シーン・メモリに記憶された前記グラフィックス・プリミティブのどの部分が、前記フレーム・バッファにおけるピクセルの最終色に影響を与えるかを決定するために、隠れ面除去を実行するカル装置と；（ｇ）前記各ピクセル内の各サンプル又はサンプルのグループに関して、フラグメント色値を生成する一つ以上の計算装置であって、前記ピクセルの各々に関する色値の生成は、前記ピクセルに影響を与えると決定された前記グラフィックス・プリミティブの部分に関してのみ実行される、前記計算装置と；及び（ｈ）（１）ピクセルごとの色値を生成するために、前記フラグメント色をブレンドするロジックと；及び（２）前記生成されたピクセルごとの色値を、前記フレーム・バッファに記憶するロジックとを具備するピクセル装置とを具備する前記グラフィックス・レンダリング装置。
【０４９１】
（３７）コンピュータ・グラフィックス・パイプラインのためのスキャンアウト装置であって、前記パイプラインは、ピクセル値のレンダリングされた画像を、フレーム・バッファに記憶し、前記コンピュータ・グラフィックス・パイプラインはコンピュータ・ディスプレイを具備し：プログラムに従ってダウンロードされた補間係数を記憶するメモリと；プログラムに従って選択された、複数のズーム比の一つを記憶するレジスタと；前記コンピュータ・ディスプレイ内におけるズーム文字枠の、プログラムに従って選択された場所を記憶するレジスタと；前記ズーム文字枠と関連する、プログラムに従って割り当てられたウィンドウ識別子を記憶するレジスタと；第一のピクセル色を前記フレーム・バッファから読み取るロジックと；複数の第二のピクセル色を前記フレーム・バッファから読み取るロジックと；前記複数の第二のピクセル色及び前記ダウンロードされた補間係数から、ズームされたピクセル色を計算するロジックと；ピクセル・ウィンドウ識別子を前記フレーム・バッファから読み取るロジックと；前記ディスプレイ・ピクセルが、前記ズーム文字枠内にあり、及び前記ピクセル・ウィンドウ識別子が前記ズーム文字枠に割り当てられた前記ウィンドウ識別子と等しい場合、前記計算されたズーム・ピクセル色を前記デジタル−アナログ・コンバータに送るロジックと；及び前記ディスプレイ・ピクセルが、前記ズーム文字枠内になく、又は前記ピクセル・ウィンドウ識別子が、前記ズーム文字枠に割り当てられた前記ウィンドウ識別子と等しくない場合、前記読み取られた第一のピクセル色を、前記デジタル−アナログ・コンバータに送るロジックとを具備する前記スキャンアウト装置。
（３８）デジタル画像をフレーム・バッファに記憶するための装置であって、前記フレーム・バッファは一列のピクセルを具備し：ウィンドウ識別子マップを記憶する第一のメモリであって、前記ウィンドウ識別子マップは、前記フレーム・バッファにおける各ピクセルに関するウィンドウ識別子を具備する前記メモリと；複数の文字枠記述を記憶する第二のメモリであって、前記文字枠記述の各々は、対応する文字枠の最大並びに最小ピクセル座標及び文字枠ウィンドウ識別子を具備する前記メモリと；前記デジタル画像と関連する、プログラムに従って割り当てられた画像識別子を記憶するレジスタと；前記デジタル画像から画像ピクセルを選択するロジックと；前記選択された画像ピクセル上で動作するピクセル・オーナシップ・ロジックであって：（１）プログラムに従って設定された制御ビットによって可能にされたウィンドウ識別子マップ・テスト・ロジックであって：（ａ）前記選択された画像ピクセルに対応する、前記ウィンドウ識別子を前記第一のメモリから読み取るロジックと；（ｂ）前記割り当てられた画像識別子を、前記読み取られたウィンドウ識別子と比較するコンパリタ回路と；及び（ｃ）前記割り当てられた画像識別子が、前記読み取られたウィンドウ識別子と適合しない場合、前記選択された画像ピクセルを廃棄するロジックと；を具備する前記ウィンドウ識別子マップ・テスト・ロジックと；及び（２）プログラムに従って設定された制御ビットによって可能にされた文字枠テスト・ロジックであって：（ａ）前記選択されたピクセルが、前記選択された第一の文字枠記述の最大及び最小ピクセル座標内になるように、前記文字枠の第一の一つを選択するロジックと；（ｂ）前記割り当てられた画像識別子を、前記第一の文字枠記述の前記文字枠ウィンドウ識別子と比較するコンパリタ回路と；及び（ｃ）前記割り当てられた画像識別子が、前記第一の文字枠の前記文字枠ウィンドウ識別子と適合しない場合、前記選択された画像ピクセルを廃棄するロジックとを具備する前記文字枠テスト・ロジックと；及び（３）前記選択された画像ピクセルが廃棄されなかった場合に、前記選択された画像ピクセルを、前記フレーム・バッファに書き込むロジックとを具備する前記ピクセル・オーナシップ・ロジックとを具備する前記装置。
【０４９２】
（３９）（３８）に記載の装置であって、前記第一のメモリは、フレーム・バッファと同じ物理メモリ・アレイにあることを特徴とする、前記装置。
（４０）（３８）に記載の装置であって、前記ピクセル・オーナシップ・ロジックは、複数の選択された画像ピクセルと並行して動作することを特徴とする、前記装置。
（４１）３Ｄグラフィックス・レンダリングのための計算システムであって：ホスト・プロセッサと：システム・メモリと；及びホスト・プロセッサに接続されたコンピュータ・グラフィックス・パイプラインとを具備し、；前記コンピュータ・グラフィックス・パイプラインは：（１）２次元グラフィックス・オペレーションを実行するための、第一の直接メモリ・アクセス・コマンドと、及び第一のコマンドを受信し及び記憶する２Ｄコマンド待ち行列メモリと；（２）３次元グラフィックス・オペレーションを実行するための、第二の直接メモリ・アクセス・コマンド及び第二のコマンドを受信し及び記憶する３Ｄコマンド待ち行列メモリと；（３）２次元グラフィックス・オペレーションを実行するための、第三のコマンドを受信し及び記憶する２Ｄ応答待ち行列メモリと；（４）３次元グラフィックス・オペレーションを実行するための、第四のコマンドを受信し及び記憶する３Ｄ応答待ち行列メモリと；及び（５）前記２Ｄコマンド待ち行列メモリ及び前記３Ｄコマンド待ち行列メモリに接続された直接メモリ・アクセス・コントローラであって：（ａ）前記第三のコマンドを、前記システム・メモリから読み取り、及び前記読み取られた第三のコマンドを、前記２Ｄ応答待ち行列に書き込むことによって、前記記憶された第一の直接メモリ・アクセス・コマンドを受信し、及び前記第一の直接メモリ・アクセス・コマンドを実行する第一のロジックと；及び（ｂ）前記第四のコマンドを、前記システム・メモリから読み取り、及び前記読み取られた第四のコマンドを、前記３Ｄ応答待ち行列に書き込むことによって、前記記憶された第二の直接メモリ・アクセス・コマンドを受信し、及び前記第二の直接メモリ・アクセス・コマンドを実行する第二のロジックとを具備する前記直接メモリ・アクセス・コントローラとを具備する前記計算システム。
（４２）（４１）に記載のシステムであって：前記２Ｄコマンド待ち行列メモリに許可されたエントリの数を記憶するプログラム可能２Ｄ最高点レジスタと；及び前記２Ｄコマンド待ち行列メモリにおけるエントリの数が、前記２Ｄ最高点レジスタに記憶された数よりも大きい時に、割り込みを生成するロジックとをさらに具備することを特徴とする、前記システム。
（４３）（４２）に記載のシステムであって：前記２Ｄコマンド待ち行列への書き込みが許可される前に、前記２Ｄコマンド待ち行列メモリにおけるエントリの最大数を記憶するプログラム可能２Ｄ最低点レジスタと；及び前記２Ｄコマンド待ち行列メモリにおけるエントリの数が、前記２Ｄ最高点レジスタに記憶された数よりも小さい時に、割り込みを生成するロジックとをさらに具備することを特徴とする、前記システム。
（４４）（４１）に記載のシステムであって：前記３Ｄコマンド待ち行列メモリに許可されたエントリの数を記憶するプログラム可能３Ｄ最高点レジスタと；及び前記３Ｄコマンド待ち行列メモリにおけるエントリの数が、前記３Ｄ最高点レジスタに記憶された数よりも大きい時、割り込みを生成するロジックとをさらに具備することを特徴とする、前記システム。
（４５）（４４）に記載のシステムであって：前記３Ｄコマンド待ち行列への書き込みが許可される前に、前記３Ｄコマンド待ち行列メモリにおけるエントリの最大数を記憶するプログラム可能３Ｄ最低点レジスタと；及び前記３Ｄコマンド待ち行列メモリにおけるエントリの数が、前記３Ｄ最高点レジスタに記憶された数よりも小さい時、割り込みを生成するロジックをさらに具備することを特徴とする、前記システム。
（４６）（４１）に記載のシステムであって：グラフィックス・データを記憶するフレーム・バッファと；ホスト待ち行列メモリと；第三の直接メモリ・アクセス・コマンドをさらに受信し及び記憶する前記２Ｄコマンド待ち行列メモリと；前記フレーム・バッファと、前記ホスト待ち行列メモリと、及び前記２Ｄコマンド待ち行列メモリとに接続され：前記フレーム・バッファから、前記コンピュータ・グラフィックス・パイプライン外部にある前記メモリへの前記グラフィックス・データのいくつかの転送を特定する、前記第一のコマンドを読み取るロジックと；及び前記フレーム・バッファからのグラフィックス・データを読み取り、並びに前記読み取られたグラフィックス・データを前記ホスト待ち行列に記憶するロジックとを具備する２Ｄグラフィックス装置であって；前記第一のロジックは、前記グラフィックス・データを前記ホスト待ち行列から読み取り、並びに前記ホスト待ち行列から読み取られた前記グラフィックス・データを、前記コンピュータ・グラフィックス・パイプラインの外部にある前記メモリに書き込むことによって、第三の直接メモリ・アクセス・コマンドを実行するロジックをさらに具備する前記２Ｄグラフィックス装置とをさらに具備することを特徴とする、前記システム。
【０４９３】
（４７）（４１）に記載のシステムであって：第四の直接メモリ・アクセス・コマンドをさらに受信し、及びさらに記憶する前記２Ｄコマンド待ち行列メモリと；及び前記グラフィックス・データを前記ホスト待ち行列から読み取り、及び前記ホスト待ち行列から読み取られた前記グラフィックス・データを、前記３Ｄ応答待ち行列メモリに書き込むことによって、前記第四の直接メモリ・アクセス・コマンドを実行するロジックをさらに具備する前記第一のロジックとをさらに具備することを特徴とする、前記システム。
（４８）（４１）に記載のシステムであって：前記３Ｄコマンド待ち行列メモリに接続され、：前記３Ｄコマンド待ち行列メモリから第二のコマンドを読み取るロジックと；及び前記読み取られた第二のコマンド上で、データ・フォーマット変換を実行するロジックとを具備する３Ｄコマンド・デコーダをさらに具備することを特徴とする、前記システム。
（４９）（４１）に記載のシステムであって：前記３Ｄコマンド待ち行列メモリに接続され：前記３Ｄコマンド待ち行列メモリから第二のコマンドを読み取るロジックと；及び無効な第二のコマンドを検出し、及び無効なコマンド割り込みを生成するロジックとを具備する３Ｄコマンド・デコーダをさらに具備することを特徴とする、前記システム。
（５０）コンピュータ・グラフィックス・パイプラインにおいて、グラフィックス・プリミティブと関連するデータを補間するための装置であって：バーテックス座標、ｗ座標、及びテクスチャ座標を具備する色データを記憶するメモリと；前記バーテックス座標及び前記ｗ座標からの前記グラフィックス・プリミティブの各々に関する重心係数を計算するロジックと；複数の前記グラフィックス・プリミティブに対応する複数のデータ・キャッシュ・エントリを記憶するキャッシュ・メモリであって、前記キャッシュされたデータは、重心係数及びテクスチャ座標を具備する前記キャッシュ・メモリと；受信されたグラフィックス・プリミティブ・フラグメントに対応する、前記記憶されたデータ・キャッシュ・エントリの一つを選択し及び読み取るロジックであって、前記グラフィックス・プリミティブ・フラグメントは、フラグメント座標を具備する前記ロジックと；前記重心係数及び前記フラグメント座標から補間係数を計算するロジックと；及び前記計算された補間係数を使用して、前記テクスチャ座標を補間するロジックとを具備する前記装置。
（５１）コンピュータ・グラフィックス・パイプラインにおいて、テクスチャ座標を補間するための装置であって：グラフィックス・プリミティブと関連するデータを記憶するメモリであって、前記記憶されたデータは、バーテックス座標、ｗ座標、及びテクスチャ座標を具備する前記メモリと；前記グラフィックス・プリミティブのフラグメントを受信するレジスタであって、前記フラグメントは、サンプル・マスクを具備し、前記サンプル・マスクは前記フラグメントによって覆われるピクセル内のサンプル場所を示す前記レジスタと；補間場所の低位ビットを決定するルックアップ・テーブルであって、前記ルックアップ・テーブルは、前記サンプル・マスクを具備し、前記補間場所は、サブ・ピクセル精度を有する前記ルックアップ・テーブルと；前記補間場所、前記バーテックス座標、及び前記ｗ座標を使用して、補間係数を計算するロジックと；及び前記計算された補間係数を使用して、前記テクスチャ座標を補間し、前記補間場所にテクスチャ座標を生成するロジックとを具備する前記装置。
【０４９４】
（５２）コンピュータ・グラフィックス・パイプラインにおいて、バーテックス面法線を補間するための装置であって：グラフィックス・プリミティブを記憶するメモリであって、前記グラフィックス・プリミティブは、バーテックス座標、ｗ座標、及びバーテックス面法線を具備する前記メモリと；前記グラフィックス・プリミティブのフラグメントを記憶するレジスタであって、前記フラグメントは単一のピクセル内の前記グラフィックス・プリミティブの一部である前記レジスタと；前記ピクセル内の補間座標を決定するロジックと；前記補間座標、前記バーテックス座標、及び前記ｗ座標を使用して、補間係数を計算するロジックと；前記バーテックス面法線の各々を、バーテックス大きさベクトル及びバーテックス方向ベクトルに分解するロジックと；補間された大きさベクトルを、複数の前記バーテックス大きさベクトル及び前記計算された補間係数から計算するロジックと；補間された方向ベクトルを、複数の前記バーテックス方向ベクトル及び前記計算された補間係数から計算するロジックと；及び補間された面法線を生成するために、前記補間された大きさベクトル及び前記補間された方向ベクトルを結合させるロジックとを具備する前記装置。
（５３）３次元（３Ｄ）グラフィックス・レンダリングのため、及びフレーム・バッファに記憶された画像を生成するための計算システムであって、前記システムは：ホスト・プロセッサと；前記ホスト・プロセッサに接続されたシステム・メモリと；及びホスト・プロセッサに接続されたコンピュータ・グラフィックス・パイプラインとを具備し、前記コンピュータ・グラフィックス・パイプラインは：３次元オブジェクトが、前記コンピュータ・グラフィックス・パイプラインによって処理されると、３次元オブジェクトにオブジェクト・タグを関連させるロジックと；前記３次元オブジェクトが、前記グラフィックス・レンダリング・パイプラインにおいて処理されると、一つ以上の可視性基準で、前記３次元オブジェクトをテストするロジックと；複数のビットを具備する状態レジスタであって、前記ホスト・プロセッサによって読み取られることができる前記状態レジスタと；前記オブジェクト・タグの一つに従って、前記状態レジスタにおいて前記ビットの一つを選択するロジックと；及び前記可視性基準でのテストに合わせて、前記３次元オブジェクトの対応する一つの応答に従って、前記状態レジスタにおける選択されたビットの値を設定するロジックとを具備する、前記計算システム。
（５４）（５３）に記載のシステムであって：画像のレンダリングを、特定された方法で機能するように導くプログラム・モジュールを実行する前記ホスト・プロセッサを具備し、前記プログラム・モジュールは：前記３次元オブジェクトの一つの文字枠ボリュームを定義する、非レンダリング可能グラフィックス・プリミティブによって表示される前記３次元オブジェクトの一つを受信し；前記非レンダリング可能グラフィックス・プリミティブを入力することによって、前記３次元オブジェクトの一つを、前記コンピュータ・グラフィックス・パイプラインに入力し；及び前記非レンダリング可能グラフィックス・プリミティブに対応するオブジェクトが隠されるか決定するために、状態レジスタ内容を読み取るための指示を含む、前記ホスト・プロセッサをさらに具備することを特徴とする、前記システム。
（５５）（５４）に記載のシステムであって、前記コンピュータ・グラフィックス・パイプラインはさらに：その各々が前記非レンダリング・プリミティブの対応する組によって表示される、複数の前記３次元オブジェクトを蓄積するメモリと；及び明確には最終的にレンダリングされた画像に寄与しない前記プリミティブの部分を切り取るために、隠れ面除去を実行するロジックであって、前記隠れ面除去は、色データが、前記画像の前記領域において、グラフィックス・プリミティブに関して生成される前に、前記画像の領域に関して実行され、それによって、生成される必要がある前記色データの量を低減させる前記ロジックとを具備し；及び前記プログラム・モジュールはさらに：前記状態レジスタを読み取る前に、複数の前記３次元オブジェクトを入力し；前記状態レジスタを読み取り、並びに前記コンピュータ・グラフィックス・パイプラインへ、その非レンダリング可能プリミティブは隠されない３次元オブジェクトに対応するレンダリング可能プリミティブを入力し、それによって、その非レンダリング可能プリミティブは隠されない、前記３次元オブジェクトに対応する前記レンダリング可能プリミティブを入力することを避けるための指示をさらに含むことを特徴とする、前記システム。
【０４９５】
【関連出願】
本出願は、１９９８年８月２０日提出、アメリカ特許仮出願第６０／０９７，３３６号、「ディファード・シェーディングを伴うグラフィックス・プロセッサ（GRAPHICS PROCESSOR WITH DEFFERED SHADING）」、の３５ＵＳＣセクション１１９（ｅ）の利益を主張し、その内容はここに参照のために採用されている。
本出願はまた、１９９８年１２月１７日提出、アメリカ特許出願第０９／２１３，９９０号、「ディファード・シェーディング・アーキテクチャにおける、接線空間ライティングの方法（HOW TO DO TANGENT SPACE LIGHTING IN A DEFFERED SHADING ARCHITECTURE）」、（代理人ドケット番号Ａ−６６３９７）；
年    月    日提出、特許出願第  号、「統一されたプリミティブ記述子を使用して、３Ｄグラフィックス・パイプラインにおいてセットアップ・オペレーションを実行するための装置及び方法（APPARATUS AND METHOD FOR REFORMING SETUP OPERATIONS IN A 3-D GRAPHICS PIPELINE USING UNIFIED PRIMITIVE DESCRIPTORS）」、（代理人ドケット番号Ａ−６６３８２）；
年    月    日提出、特許出願第  号、「ポスト・ファイル・ソーティング・セットアップ（POST-FILE SORTING SETUP）」、（代理人ドケット番号Ａ−６６３８３）；
年    月    日提出、特許出願第  号、「タイル相対Ｙ値及びスクリーン相対Ｘ値（TILE RELATIVE Y-VALUES AND SCREEN RELATIVE X-VALUES）」、（代理人ドケット番号Ａ−６６３８４）；
年    月    日提出、特許出願第  号、「３次元グラフィックス・パイプラインにおいて、画像データを空間的にソートするためのシステム、装置、及び方法（SYSTEM,APPARATUS AND METHOD FOR SPATIALLY SORTING IMAGE DATA IN A THREE-DIMENSIONAL GRAPHICS PIPELINE）」、（代理人ドケット番号Ａ−６６３８０）；
年    月    日提出、特許出願第  号、「３次元グラフィックス・パイプラインにおいて、オブジェクト・ジオメトリをソートするための、保証された保存性メモリ評価を生成するためのシステム、装置及び方法（SYSTEM, APPARATUS AND METHOD FOR GENERATING GUARANTEED CONSERVATIVE MEMORY ESTIMATE FOR SORTING OBJECT GEOMETRY IN A THREE-DIMENSIONAL GRAPHICS PIPELINE）」、（代理人ドケット番号Ａ−６６３８１）；
年    月    日提出、特許出願第  号、「３次元グラフィックス・パイプラインにおいて、レンダリング・リソースの均衡を取るためのシステム、装置及び方法（SYSTEM, APPARATUS AND METHOD FOR BALANCING RENDERING RESOURCES IN A THREE-DIMENSIONAL GRAPHICS PIPELINE）」、（代理人ドケット番号Ａ−６６３７９）；
【０４９６】
年    月    日提出、特許出願第  号、「パイプライン状態記憶及び検索を伴うグラフィックス・プロセッサ（GRAPHICS PROCESSOR WITH PIPELINE STATE STORAGE AND RETRIEVAL）」、（代理人ドケット番号Ａ−６６３７８）；
年    月    日提出、特許出願第  号、「テクスチャを生成するための方法及び装置（METHOD AND APPARATUS FOR GENERATING TEXTURE）」、（代理人ドケット番号Ａ−６６３９８）；
年    月    日提出、特許出願第  号、「３Ｄグラフィックス・パイプラインにおけるジオメトリ・オペレーションのための装置及び方法（APPARATUS AND METHOD FOR GEOMETRY OPERATIONS IN A 3D GRAPHICS PIPELINE）」、（代理人ドケット番号Ａ−６６３７３）；
年    月    日提出、特許出願第  号、「３Ｄグラフィックス・パイプラインにおけるフラグメント・オペレーションのための装置及び方法（APPARATUS AND METHOD FOR FRAGMENT OPERATIONS IN A 3D GRAPHICS PIPELINE）」、（代理人ドケット番号Ａ−６６３９９）；
年    月    日提出、特許出願第  号、「ディファード・シェーディング・グラフィックス・パイプライン・プロセッサ（DEFFERED SHADING GRAPHICS PIPELINE PROCESSOR）」、（代理人ドケット番号Ａ−６６３６０）；
年    月    日提出、特許出願第  号、「ディファード・シェーディングを伴うグラフィックス・プロセッサにおける保存性隠れ面除去を実行するための方法及び装置（METHOD AND APPARATUS FOR REFORMING CONSERVATIVE HIDDEN SURFACE REMOVAL IN A GRAPHICS PROCESSOR WITH DEFFERRED SHADING）」、（代理人ドケット番号Ａ−６６３８６）；及び
年    月    日提出、特許出願第  号、「向上した特性を有するディファード・シェーディング・グラフィックス・パイプライン・プロセッサ（DEFERRED SHADING GRAPHICS PIPELINE PROCESSOR HAVING ADVANCED FEATURES）」、（代理人ドケット番号Ａ−６６３６４）
の３５ＵＳＣセクション１２０の利益を主張する。
本明細書に記載されたすべての公告、特許、及び特許出願は、各個別の公告又は特許出願が、参照のために採用されるように特定的及び個別に示されているのと同じ範囲で、参照のために採用されている。
本発明の特定の実施形態の上述の記載は、例示及び説明の目的で示されてきた。それらは、完全なものではなく、また本発明を、開示された精密な形式に限定する目的ではなく、明らかに多くの変更及び変形が、上述の教示に照らして可能である。前記実施形態は、本発明及びその実践的応用の原則を最も良く説明し、それによって当業者が、検討される特定の使用に適した様々な変更とともに、本発明及び様々な実施形態を最も良く使用することができるようにするために、選択され及び説明された。本発明の範疇は、本書に添付された特許請求の範囲及びそれの同等物によって定義されるものである。
【図面の簡単な説明】
本発明のさらなる目的及び特徴は、図面を参照すると、以下の詳細な説明及び添付の特許請求の範囲から容易に明らかになるであろう。
【図１】  図１は、自らの座標軸、ビューイング・ポイントの座標システム、及びスクリーン座標を伴う、四面体を示す図である。
【図２】  図２は、３Ｄグラフィックス・パイプラインのための、従来の包括的レンダラを示す図である。
【図３】  図３は、本発明の３次元グラフィックス・パイプラインの実施形態を示す、特に他の機能的ブロックを伴うジオメトリ・エンジン３０００と、及びホスト上で実行するアプリケーション、及びホスト・メモリとの関係を示す図である。
【図４】  図４は、本発明の３次元ディファード・シェーディング・グラフィックス・パイプラインの第一の実施形態を示す図である。
【図５】  図５は、本発明の３次元ディファード・シェーディング・グラフィックス・パイプラインの第二の実施形態を示す図である。
【図６】  図６は、本発明の３次元ディファード・シェーディング・グラフィックス・パイプラインの第三の実施形態を示す図である。
【図７】  図７は、本発明の３次元ディファード・シェーディング・グラフィックス・パイプラインの第四の実施形態を示す図である。
【図８】  図８は、本発明の３次元ディファード・シェーディング・グラフィックス・パイプラインの第五の実施形態を示す図である。
【図９】  図９は、本発明の３次元ディファード・シェーディング・グラフィックス・パイプラインの第六の実施形態を示す図である。
【図１０】  図１０は、保存性隠れ面除去の実施形態の検討を示す図である。
【図１１】  図１１は、保存性隠れ面除去の実施形態におけるアルファ・テスト及び深度テストの検討を示す図である。
【図１２】  図１２は、保存性隠れ面除去の実施形態におけるステンシル・テストの検討を示す図である。
【図１３】  図１３は、保存性隠れ面除去の実施形態におけるアルファ・ブレンディングの検討を示す図である。
【図１４】  図１４は、保存性隠れ面除去の実施形態のさらなる検討を示す図である。
【図１５】  図１５は、パイプラインの実施形態の、ブロックを通過するデータの例示的な流れを示す図である。
【図１６】  図１６は、カル・ブロックのある実施形態が、部分的に不明瞭な三角形からフラグメントを作る方法を示す図である。
【図１７】  図１７は、ピクセル・ブロックのある実施形態が、１スタンプの価値を有するフラグメントを処理する方法を示す図である。
【図１８】  図１８は、フロント・エンド・コマンド・フェッチ及びデコード・ブロック（ＣＦＤ）２０００における主な機能的装置を示す、パイプラインの実施形態の例示的なブロック図を示す図である。
【図１９】  図１９は、ディファード・シェーディング・グラフィックス・プロセッサ（ＤＳＧＰ）の一つの実施形態が、バーテックス座標を変換する方法を強調する図である。
【図２０】  図２０は、ディファード・シェーディング・グラフィックス・プロセッサ（ＤＳＧＰ）の一つの実施形態が、法線、接線、及び従法線を変換する方法を強調する図である。
【図２１】  図２１は、ジオメトリ・ブロック（ＧＥＯ）の機能的ブロック図を示す図である。
【図２２】  図２２は、本発明の構造の３チップ実施形態における半導体チップ上の機能的ブロック間の関係を示す図である。
【図２３】  図２３は、モード・エクストラクション・ブロック（ＭＥＸ）の一つの実施形態における例示的なデータ・フローを示す図である。
【図２４】  図２４は、例示的なモード・エクストラクション・ブロックに送信されるパケットを示す図である。
【図２５】  図２５は、例示的なモード・エクストラクション・ブロックのオンチップ状態ベクトル・パーティショニングの実施形態を示す図である。
【図２６】  図２６は、ポリゴン・メモリへの情報をセーブするための処理の特徴を示す図である。
【図２７】  図２７は、ＭＥＸと相対したポリゴン・メモリに関する例示的な構成を示す図である。
【図２８】  図２８は、ＭＥＸブロックにおける色ポインタ生成と相対した色情報に関する例示的ビット構成を示す図である。
【図２９】  図２９は、ＭＥＸブロックにおける色タイプ・フィールドに関する例示的構成を示す図である。
【図３０】  図３０は、点リスト、線ストリップ、三角形ストリップ、又は三角形ファンのリストの第一のデュアロクトに記憶されたＭＬＭポインタ・パケットの内容を示す図である。
【図３１】  図３１は、データ記憶装置及びポインタ記憶装置に分割される方法を含む、データがソート・メモリ・ページに記憶される方法の例示的実施形態を示す。
【図３２】  図３２は、ソート・ブロックの例示的実施形態の単純化されたブロック図を示す。
【図３３】  図３３は、タイルＡＢＣ及び（ｘTile，ｙTile）に中心を有するタイルに関するタッチド・タイル計算プロシージャの特徴を示す図である。
【図３４】  図３４は、タッチド・タイル計算プロシージャの特徴を示す図である。
【図３５Ａ及び３５Ｂ】  図３５Ａ及び３５Ｂは、タッチド・タイル・プロシージャにおけるしきい値距離計算の特徴を示す図である。
【図３６Ａ】  図３６Ａは、垂直ベクトルとしきい値距離との間の特定の関係に関するタイルの位置と三角形の位置との間の第一の関係を示す図である。
【図３６Ｂ】  図３６Ｂは、垂直ベクトルとしきい値距離との間の特定の関係に関するタイルの位置と三角形の位置との間の第二の関係を示す図である。
【図３６Ｃ】  図３６Ｃは、垂直ベクトルとしきい値距離との間の特定の関係に関するタイルの位置と三角形の位置との間の第三の関係を示す図である。
【図３７】  図３７は、タイルの辺の一つに関連した、線の角度の間の関係を含むしきい値距離決定のエレメントを示す図である。
【図３８Ａ】  図３８Ａは、１８×１４アレイでの２５２タイルを有するウィンドウに関するＳｕｐｅｒＴｉｌｅホップ・プロシージャ・シーケンスの例示的な実施形態を示す図である。
【図３８Ｂ】  図３８Ｂは、図３８Ａに記載のＮ＝６３及びＭ＝１３のＳｕｐｅｒＴｉｌｅホップ・プロシージャに関する例示的シーケンスを示す図である。
【図３９】  図３９は、ＳＴＰブロックに到着し、及びエイリアス又はアンチ・エイリアス・モードでレンダリングされることができるＤＳＧＰ三角形を示す図である。
【図４０】  図４０は、線をクワド及び様々な方向のエイリアスされ及びアンチ・エイリアスされた線の描画のために生成された様々なクワドへと変換することによって、ＤＳＧＰが線をレンダリングする方法を示す図である。
【図４１】  図４１は、ユーザ特定点が、ジオメトリ装置におけるレンダリングされた点に調節される方法を示す図である。
【図４２】  図４２は、アンチ・エイリアスされた線セグメントが、平行四辺形及び三角形を統一的にラステライズするＣＵＬ装置スキャン・コンバータにおいて、三角形に変換される方法を示す図である。
【図４３】  図４３は、アンチ・エイリアスされた線の場合における長方形と比較して、エイリアスされた線のエンド・ポイントが、平行四辺形を使用して計算される方法を示す図である。
【図４４】  図４４は、長方形が、線の可視部分を表示する方法を示す図である。
【図４５】  図４５は、点描オフセットｓｔｐｌＳｔａｒｔＢｉｔと同様に、新しい線開始点が、クリップされた点に関して生成される方法を示す図である。
【図４６】  図４６は、線モード三角形のジオメトリを示す図である。
【図４７】  図４７は、セットアップが、バーテックス割り当てを含む、線及び三角形をどのように表示するかの特徴を示す図である。
【図４８】  図４８は、セットアップが、スロープ割り当てを含む、線及び三角形をどのように表示するかの特徴を示す図である。
【図４９】  図４９は、セットアップが、線の方向に基づいて四分円弧割り当てを含む、線及び三角形をどのように表示するかの特徴を示す図である。
【図５０】  図５０は、セットアップが、クリップ記述子のネーミング及びバーテックスへのクリップ・コードの割り当てを含む、線及び三角形をどのように表示するかを示す図である。
【図５１】  図５１は、セットアップが、特定の値をＣＵＬにどのように渡すかの特徴を含む、セットアップがどのように線及び三角形を表示するかの特徴を示す図である。
【図５２】  図５２は、点処理と関連したタイル座標の決定を示す図である。
【図５３】  図５３は、カル・ブロックの例示的実施形態の図である。
【図５４】  図５４は、カル・ブロック・サブユニットの例示的実施形態の図である。
【図５５】  図５５は、完全に結合的であり、キャッシュ・タグ・ルックアップに関してコンテント・アドレッサブル・メモリ（ＣＡＭｓ）を使用するタグ・キャッシュの例示的実施形態の図である。
【図５６】  図５６は、モード・データが流れ、及びＤＳＧＰパイプラインの部分にキャッシュされる方法を示す図である。
【図５７】  図５７は、フラグメント・ブロックの例示的実施形態の図である。
【図５８】  図５８は、様々なプリミティブによって形成されるピクセル・フラグメントを有するＶＳＰの例を示す図である。
【図５９】  図５９は、三角形に関して透視的修正重心補間を使用するフラグメント・ブロック補間の特徴を示す図である。
【図６０】  図６０は、不等マグニチュードのベクトル間の補間が、どのように一様でない角度粒状度（uneven angular granularity）を生み、及びなぜ本発明の構造及び方法が、このように法線と接線を補間しないのか、の例を示す。
【図６１】  図６１は、フラグメント・ブロックにおける補間係数を形成するために使用されるフラグメントｘ及びｙ座標が、どのように形成されるかを示す図である。
【図６２】  図６２は、テクスチャ・アレイ・アドレッシングの概観を示す図である。
【図６３】  図６３は、パイプラインにおけるフォン装置位置及び隣接するブロックへの関係を示す図である。
【図６４】  図６４は、いくつかのサブ・ユニットを具備するフォンのブロック図を示す図である。
【図６５】  図６５は、ＰＩＸブロックのブロック図を示す図である。
【図６６】  図６６は、バックエンド・ブロック（ＢＫＥ）及びそれに接する装置を示す図である。
【図６７】  図６７は、ＢＫＥを通したメモリ読み取り及び書き込みを実行する外部クライアント装置を示す図である。
【図１】
0003657518.tif 000040
【図２】
0003657518.tif 000041
【図３】
0003657518.tif 000042
【図４】
0003657518.tif 000043
【図５】
0003657518.tif 000044
【図６】
0003657518.tif 000045
【図７】
0003657518.tif 000046
【図８】
0003657518.tif 000047
【図９】
0003657518.tif 000048
【図１０】
0003657518.tif 000049
【図１１】
0003657518.tif 000050
【図１２】
0003657518.tif 000051
【図１３】
0003657518.tif 000052
【図１４】
0003657518.tif 000053
【図１５】
0003657518.tif 000054
【図１６】
0003657518.tif 000055
【図１７】
0003657518.tif 000056
【図１８】
0003657518.tif 000057
【図１９】
0003657518.tif 000058
【図２０】
0003657518.tif 000059
【図２１】
0003657518.tif 000060
【図２２】
0003657518.tif 000061
【図２３】
0003657518.tif 000062
【図２４】
0003657518.tif 000063
【図２５】
0003657518.tif 000064
【図２６】
0003657518.tif 000065
【図２７】
0003657518.tif 000066
【図２８】
0003657518.tif 000067
【図２９】
0003657518.tif 000068
【図３０】
0003657518.tif 000069
【図３１】
0003657518.tif 000070
【図３２】
0003657518.tif 000071
【図３３】
0003657518.tif 000072
【図３４】
0003657518.tif 000073
【図３５Ａ】
0003657518.tif 000074
【図３５Ｂ】
0003657518.tif 000075
【図３６Ａ】
0003657518.tif 000076
【図３６Ｂ】
0003657518.tif 000077
【図３６Ｃ】
0003657518.tif 000078
【図３７】
0003657518.tif 000079
【図３８Ａ】
0003657518.tif 000080
【図３８Ｂ】
0003657518.tif 000081
【図３９】
0003657518.tif 000082
【図４０】
0003657518.tif 000083
【図４１】
0003657518.tif 000084
【図４２】
0003657518.tif 000085
【図４３】
0003657518.tif 000086
【図４４】
0003657518.tif 000087
【図４５】
0003657518.tif 000088
【図４６】
0003657518.tif 000089
【図４７】
0003657518.tif 000090
【図４８】
0003657518.tif 000091
【図４９】
0003657518.tif 000092
【図５０】
0003657518.tif 000093
【図５１】
0003657518.tif 000094
【図５２】
0003657518.tif 000095
【図５３】
0003657518.tif 000096
【図５４】
0003657518.tif 000097
【図５５】
0003657518.tif 000098
【図５６】
0003657518.tif 000099
【図５７】
0003657518.tif 000100
【図５８】
0003657518.tif 000101
【図５９】
0003657518.tif 000102
【図６０】
0003657518.tif 000103
【図６１】
0003657518.tif 000104
【図６２】
0003657518.tif 000105
【図６３】
0003657518.tif 000106
【図６４】
0003657518.tif 000107
【図６５】
0003657518.tif 000108
【図６６】
0003657518.tif 000109
【図６７】
0003657518.tif 000110