(57)【要約】      （修正有）【課題】１つまたはそれ以上のディファード・シェーディング、タイルド・フレーム・バッファ、多ステージ陰面除去プロセシング、他の構造及び／又はプロシジャと共に含んでいる３次元グレフィックスプロセッサの構造と方法に関する。【解決手段】ピクセルの断片を抽出し（４０００）、ソーティングし（６０００）、及びレンダリングするグラフィックス・パイプライン・プロセッサ。当該プロセッサは、テクスチャ（１２０００）、及び種々の断片の操作（１１０００）の内の１つを利用する。【選択図】図１
2004272928.tif 000002
【特許請求の範囲】
【請求項１】
完成された描写イメージを形成するためのグラフイックス・レンダリング・システムであって、
（ｉ）接続されたメモリ及び少なくとも１つの入力／出力バスを有し、グラフイックス・プリミティブを含むグラフイックス・データを供給するホスト・コンピュータと、
（ｉｉ）入力／出力バスを介してホスト・コンピュータとの通信を処理し、そしてグラフイックス・データを一続きのパケットに変換するための１つ又は複数のフロントエンド・ブロックと、
（ｉｉｉ）最初がフロントエンド・ブロックに接続されてパイプライン中に順次に接続された複数の処理ブロックと、各処理ブロックは、（ａ）少なくとも１つのデータ入力；（ｂ）少なくとも１つのデータ出力；（ｃ）少なくとも１つのデータ入力におけるＦＩＦＯ；及び（ｄ）情報をパケットで処理ブロックから処理ブロックへ転送するためのパケット化データ転送プロトコルのための論理を含み、各パケットはヘッダー部分及びデータ部分を含み、このプロトコルは少なくともいくつかの転送される情報の順序を維持しながら処理ブロックから別の処理ブロックへ単一の通信チャンネル上に異なる形式及びさまざまな長さを持つ異なるパケットを順次に転送するために使用され、
（ｉｖ）フレームバッファと、
（ｖ）フレームバッファ及び前記処理ブロックの最後に接続されていて、フレームバッファの制御及び出力装置へ完成された描写イメージの送信を含む機能を持つバックエンド・ブロックと、
（ｖｉ）送信されたパケットが前記順次に接続された処理ブロックの全てよりも少なく通過するように前記バックエンド・ブロックを前記最初の処理ブロックに接続する通信経路と、
を含むグラフイックス・レンダリング・システム。
【請求項２】
複数の処理ブロックがさらに、
フロントエンド・ブロックに接続されて、頂点座標変換、頂点法線変換、及び頂点毎のライティングのための論理を有するジオメトリ・ブロックを含む請求項１に記載のグラフイックス・レンダリング・システム。
【請求項３】
ジオメトリ・ブロックがさらに、
フロントエンド・ブロックからジオメトリ・ブロックへ情報を転送するためのジオメトリ入力パケットの１つ又は複数のタイプを受信するための論理を有し、ジオメトリ入力パケットが転送する情報は変換行列と、材料パラメータと、光パラメータと、頂点データとを含む請求項２に記載のグラフイックス・レンダリング・システム。
【請求項４】
１つ又は複数のメモリ・ブロックを含み、１つ又は複数の処理ブロックに接続されていて、プリミティブ・データ及びパイプライン状態を含むパイプライン・データを記憶するために使用されるシーン・メモリをさらに含み、
シーン・メモリは少なくとも、
（１）陰面除去のために必要なプリミティブ・データの部分（１ａ）及び陰面除去のために必要なパイプライン状態の部分（１ｂ）を記憶するための空間メモリ・ブロックと、
（２）陰面除去のために必要でないプリミティブ・データの部分（２ａ）及び陰面除去のために必要でないパイプライン状態の部分（２ｂ）を記憶するための多角形メモリ・ブロックと、
を含む請求項１に記載のグラフイックス・レンダリング・システム。
【請求項５】
前記通信経路上に送信される前記パケットがプレフェッチ・パケットを含み、このプレフェッチ・パケットが前記通信経路上に送信されないその他のパケットよりも早く前記バックエンド・ブロックに到着する請求項１に記載のグラフイックス・レンダリング・システム。
【請求項６】
少なくとも１つの前記複数の処理ユニットが、第１タイプのパケットを前記処理ユニットの別の１つへ発送し、第２タイプのパケットを前記複数の処理ユニットの異なる１つへ発送するように構成されている請求項１に記載のグラフイックス・レンダリング・システム。
【請求項７】
前記少なくとも１つの前記複数の処理ユニットがタイルに従ってグラフイックス・プリミィテイブをソートするように構成されたユニットであり、前記処理ユニットの前記別の１つが記憶されたモード情報を検索するように構成されたユニットであり、前記複数の処理ユニットの前記異なる１つがグラフイックス・プリミィテイブをタイル順番で１つ又は他のユニットへ送るように構成されたユニットである請求項６に記載のグラフイックス・レンダリング・システム。
【請求項８】
前記少なくとも１つの前記複数の処理ユニットが記憶されたモード情報を検索するように構成されたユニットであり、前記処理ユニットの前記別の１つがカラー値を補間するように構成されたユニットであり、前記複数の処理ユニットの前記異なる１つがフラグメント毎の操作を実行するように構成されたユニットである請求項６に記載のグラフイックス・レンダリング・システム。
【請求項９】
前記少なくとも１つの前記複数の処理ユニットがカラー値を補間するように構成されたユニットであり、前記処理ユニットの前記別の１つがシェーデイングを実行するように構成されたユニットであり、前記複数の処理ユニットの前記異なる１つがテクスチャ・マップを適用するように構成されたユニットである請求項６に記載のグラフイックス・レンダリング・システム。
【請求項１０】
前記通信経路が、同じチップ上に位置する２つの処理ユニット間のインターフェイスを含み、前記インターフェイス上に送信されたパケットが同じチップ上の他の処理ユニットをバイパスする請求項１に記載のグラフイックス・レンダリング・システム。
【請求項１１】
前記複数の処理ブロックがタイルに従いグラフイックス・プリミティブをソートするように構成されたユニットと、タイル順番に従いグラフイックス・プリミティブを１つ又は複数の他のユニットへ送信するように構成されたユニットと、陰面除去を実行するように構成されたユニットと、記憶されたモード情報を検索するように構成されたユニットとを含み、
前記システムがさらに、
ソートするように構成された前記ユニットと送信するように構成された前記ユニットとの間の第１インターフェイスと、
送信するように構成された前記ユニットと陰面除去を実行するように構成された前記ユニットとの間の第２インターフェイスと、
陰面除去を実行するように構成された前記ユニットと記憶されたモード情報を検索するように構成された前記ユニットとの間の第３インターフェイスとを含み、
前記通信経路がソートするように構成された前記ユニットと記憶されたモード情報を検索するように構成された前記ユニットとの間の第４インターフェイスを含む請求項１に記載のグラフイックス・レンダリング・システム。
【請求項１２】
ソートするように構成された前記ユニットと、送信するように構成された前記ユニットと、陰面除去を実行するように構成された前記ユニットと、記憶されたモード情報を検索するように構成された前記ユニットとが第１半導体チップ上に設けられている請求項１１に記載のグラフイックス・レンダリング・システム。
【請求項１３】
前記複数の処理ユニットが、前記第１半導体チップを含む複数の半導体チップ上に設けられていて、前記システムがさらに、
前記複数のチップを接続するチップ間通信リングを含む請求項１２に記載のグラフイックス・レンダリング・システム。
【請求項１４】
完成した描写イメージを形成するためのグラフイックス・レンダリング方法であって、
（ｉ）グラフイックス・プリミティブを含むグラフイックス・データを受取り、
（ｉｉ）グラフイックス・データの少なくともいくつかを一続きのパケットへ変換し、
（ｉｉｉ）バックエンド・プロセスを含む複数のグラフイックス・プロセスを通じて一続きのパケットを処理し、複数のグラフイックス・プロセスはパイプラインに順次に接続されていて、変換されたグラフイックス・データを受取る最初のグラフイックス・プロセス及び完成した描写イメージを形成する最後のグラフイックス・プロセスを含み、各グラフイックス・プロセスは次のステップを含み、
（ａ）パケットを受取り、
（ｂ）情報をパケットでグラフイックス・プロセスからグラフイックス・プロセスへ転送するためのパケット化データ転送プロトコルに使用する新パケットを生成し、各パケットはヘッダー部分及びデータ部分を含み、このプロトコルは異なる形式及びさまざまな長さを持つ異なるパケットを順次に送信するために使用され、
（ｃ）転送される情報の少なくともいくつかの順番を維持しながら、１つのグラフイックス・プロセスから別のグラフイックス・プロセスへ単一通信チャンネルを介して新パケットを送信し、
（ｄ）プレフェッチ・パケットを生成し、
（ｅ）前記プレフェッチ・パケットを前記バックエンド・プロセスへ前記単一通信チャンネルよりも短い第２通信チャンネルを介して送信し、
（ｉｖ）フレームバッファ内に完成した描写イメージを格納し、
（ｖ）出力装置へ完成した描写イメージを送信する、
ことを特徴とするグラフイックス・レンダリング方法。
【請求項１５】
直接メモリアクセスを介して追加のグラフイックス・データの受け取りを促す命令を受け取り、
ジオメトリ入力パケットの少なくとも１つのタイプを受け取り、ジオメトリ入力パケットは変換行列、材料パラメータ、光パラメータ、及び頂点データを含む情報を転送し、
プリミティブ・デーダ及びパイプライン状態を含むパイプライン・データを１つ又は複数のメモリ内に格納し、
各ジオメトリ・プロセスがさらに頂点パケットの複数のタイプを受け取るステップを含み、頂点パケットの複数のタイプは異なる性能レベルで処理される長さが異なり、
格納ステップがさらに、三次元（３Ｄ）タイル読出しを実行することを含み、三次元（３Ｄ）タイル書込みの実行はピクセル所有を使用し、そして書込みのためにピクセル所有を実行することは検出の重ね合わせることを可能にする、
ステップをさらに含む請求項１４に記載のグラフイックス・レンダリング方法。
【請求項１６】
パイプライン・データを格納するステップがさらに、
（１）空間メモリ内に第１パイプライン・データを格納し、空間メモリ内に格納された第１パイプライン・データは、陰面除去に必要なプリミティブ・データの部分（１ａ）及び陰面除去に必要なパイプライン状態の部分（１ｂ）を含み、
（２）多角形メモリ内に第２パイプライン・データを格納し、多角形メモリ内に格納された第２パイプライン・データは、陰面除去に必要でないプリミティブ・データの部分（２ａ）及び陰面除去に必要でないパイプライン状態の部分（２ｂ）を含む、請求項１５に記載のグラフイックス・レンダリング方法。
【請求項１７】
複数のグラフイックス・プロセスがさらに、
頂点パケット及びモード・パケットを空間メモリ内に格納するステップを含むソート・プロセスを含む請求項１５に記載のグラフイックス・レンダリング方法。
【請求項１８】
プリミティブ・データ及びパイプライン状態を含むパイプライン・データを１つ又は複数のメモリ内に格納することをさらに含む請求項１４に記載のグラフイックス・レンダリング方法。
【請求項１９】
複数のグラフイックス・プロセスがさらに、
完成した描写イメージに貢献しないプリミティブの部分を選び出すための陰面除去プロセスを実行しそしてプリミティブの可視部分を生成するステップを含むカル・プロセスと、
生成されたプリミティブの可視部分に対して実行されるステップのフラグメント色付け及びフラグメント・ブレンデイングのステップを一緒に含んだ１つ又は複数のグラフイックス・プロセスと、
を含む請求項１８に記載のグラフイックス・レンダリング方法。
【請求項２０】
完成された描写イメージを格納するステップがさらに、ピクセルの矩形格子からなりタイルに分割されたウインドウとしてフレームバッファの部分をアクセスすることを含み、そして
複数のグラフイックス・プロセスの少なくともいくつかが完成された描写イメージを形成するためのプロセスをタイル毎に実行するステップを含む、請求項１８に記載のグラフイックス・レンダリング方法。
【請求項２１】
複数のグラフイックス・プロセスがさらに、
（１）グラフイック・プリミティブを代表する頂点のリストを維持するステップ；（２）各タイルに対して１つのタイル・ポインタ・リストのタイル・ポインタ・リストの組を維持するステップ；（３）フレーム内に全てのジオメトリを格納するステップ；（４）各々が完全なプレミティブを代表するプリミティブ・パケットを生成するステップを含んだソート・プロセスを含む請求項２０に記載のグラフイックス・レンダリング方法。
【請求項２２】
複数のグラフイックス・プロセスがさらに、
一時的順序の状態変化データを収集するステップ、及び
多角形メモリ内に一時的順序の状態変化を記憶するステップ、
を含むモード抽出プロセスを含んだ請求項２１に記載のグラフイックス・レンダリング方法。
【請求項２３】
モード抽出プロセスがさらに、
１つの組がプリミティブのフロント及びバック面の各々に対する材料及びテクスチャ・データの２つの組を蓄積するステップと、
多角形メモリ内に、各プリミティブに対してフラグ指示子に基づいて２つの組の１つのみを格納するステップと、
を含む請求項２２に記載のグラフイックス・レンダリング方法。
【請求項２４】
グラフイックス・データを受け取るステップと、
前記グラフイックス・データの少なくともいくつかを複数のパケットに変換するステップと、
モード抽出プロセスを実行するステップと、モード抽出プロセスは、
前記複数のパケットを、
（ｉ）空間パケット、開始フレーム・パケット、終了フレーム・パケット、及びクリア・パケットを含む空間情報、及び
（ｉｉ）カラー・パケット、テクスチャ・パケット、及び材料パケットを含んだシェーデイング情報に分離し、
前記空間情報をソーテイング・プロセスに送るステップと、
前記シェーデイング情報を多角形メモリ内に記憶するステップと、
を含むグラフイックス・レンダリング方法。
【請求項２５】
前記送るステップが、前記ソーテイング・プロセスが前記空間情報のみを受け取るように送ることを含む請求項２４に記載の方法。
【請求項２６】
前記送るステップが、前記ソーテイング・プロセスが前記シェーデイング情報を受け取らないように送ることを含む請求項２４に記載の方法。
【請求項２７】
前記ソーテイング・プロセスが、前記多角形メモリとは独立である請求項２４に記載の方法。
【請求項２８】
グラフイックス・レンダリング方法を実現するコンピュータ・システムと共に使用するためのコンピュータ・プログラムであって、コンピュータ・プログラムはその中に埋め込まれたコンピュータ・プログラム機構を含み、このコンピュータ・プログラム機構が、
複数のグラフイックス・プリミティブから最終グラフイックス・イメージのデジタル表現の描写、指定された態様で機能するために、最終グラフイックス・イメージをフレームバッファ内に格納することを指示するプログラム・モジュールを含み、このプログラム・モジュールは以下の（ｉ）〜（ｖ）に対する命令を含み、
（ｉ）グラフイックス・プリミティブを含むグラフイックス・データを受け取り、
（ｉｉ）グラフイックス・データの少なくともいくつかを一続きのパケットに変換し、
（ｉｉｉ）一続きのパケットを複数のグラフイックス・プロセスを通じて処理し、複数のグラフイックス・プロセスはパイプラインに順次に接続されていて、変換されたグラフイックス・データを受け取る最初のグラフイックス・プロセス及び完成した描写イメージを形成する最後のグラフイックス・プロセスを含み、そして各グラフイックス・プロセスは以下の（ａ）〜（ｅ）のステップを含み、
（ａ）パケットを受け取り、
（ｂ）情報をパケットでグラフイックス・プロセスからグラフイックス・プロセスへ転送するためのパケット化データ転送プロトコルに使用するための新パケットを生成し、このプロトコルはさまざまな長さ及び異なる形式を持つ異なるパケットを順次に送信するために使用され、
（ｃ）転送される情報の少なくともいくつかの順序を維持しながら、単一の通信チャンネルを介して１つのグラフイックス・プロセスから別のグラフイックス・プロセスへ新パケットを送信し、
（ｄ）プレフェッチ・パケットを生成し、
（ｅ）前記プレフェッチ・パケットを第２通信チャンネルを介して前記バックエンド・プロセスへ送信し、前記第２通信チャンネルは前記単一の通信チャンネルよりも短く、
（ｉｖ）完成した描写イメージをフレームバッファ内に格納し、
（ｖ）完成した描写イメージを出力装置へ送信する、
ことを含むコンピュータ・プログラム。
【請求項２９】
グラフイックス・プロセスがさらに、
（１）以下のステップ（ａ）及び（ｂ）を含むカル・プロセスを含み、
（ａ）完成した描写イメージに貢献しないプリミティブの部分を取り除く陰面除去を実行し、
（ｂ）プリミティブの可視部分を生成し、
（２）１つ又はグラフイックス・プロセスが一緒に以下のステップ（ａ）及び（ｂ）を含む、
（ａ）色付きフラグメントを作るために生成されたプリミティブの可視部分について実行されるフラグメントの色付け、
（ｂ）色付きフラグメントについて実行されるフラグメントの混ぜ合わせ、
ことを特徴とする請求項２８に記載のコンピュータ・プログラム。
【請求項３０】
グラフイックス・プロセスがさらに、
以下のステップ（ａ）〜（ｄ）を含むピクセル・プロセスを含む、
（ａ）各フラグメントが独立のカラー値を持った、プリミティブの可視部分を受け取り、
（ｂ）シザー・テスト、アルファ・テスト、ステンシル・テスト、デプス・テスト、及びブレンディングを含むフラグメント操作を各サンプルに対して実行し、
（ｃ）ピクセルをアンチアライアスするために各ピクセル内でサンプルを混ぜ合わせ、
（ｄ）完成された描写イメージを格納するステップに使用するためにアンチアライアスされたピクセルを出力する、
ことを特徴とする請求項２８に記載のコンピュータ・プログラム。
【発明の詳細な説明】
【発明の詳細な説明】
【０００１】    （発明の属する技術分野）
本発明は、一般的に言えばコンピューティング・システムに、厳密に言えば３次元コンピュータ・グラフィクスに、更に限定すれば、ディファード・シェーディング及びその他の強化された機能を実行する３次元グラフィクス・プロセッサのための構造と方法に関する。
【０００２】    （発明の背景）
本発明の背景は便宜上、グラフィカルな情報を処理し表現するための、特定の態様の一般的或いは従来型の方法及び構造に取り組む幾つかのセクションに分けられる。本説明全体を通して出てくる節の見出しは読む人の便宜のためだけに設けたものであり、本発明に関する情報及び本発明の背景は、明細書全体を通して提供されているものである。
３次元コンピュータ・グラフィクス
コンピュータ・グラフィクスは、ピクチャ、イメージ又はその他のグラフィカルな又は絵画的な情報をコンピュータで生成する技術及び科学である。一般的に３次元（３Ｄ）コンピュータ・グラフィクスでは、あるシーンにおけるオブジェクトのサーフェス（又はボリューム）を表すジオメトリはフレーム・バッファ内に記憶されるピクセル（ピクチャ・エレメント）に翻訳され、次にディスプレイ装置上に表示される。コンピュータ・モニタとして使われるＣＲＴのようなリアルタイム・ディスプレイ装置は、イメージを繰り返し連続的に表示することによりディスプレイ表示をリフレッシュしている。このリフレッシュは普通は行毎に行われ、各行はラスタ・ライン又はスキャン・ラインと呼ばれている。本文書では、ラスタ・ラインを概ね底部から頂部に数えるが、頂部から底部へと順にディスプレイ表示される。
【０００３】  ３Ｄアニメーションでは、連続したイメージが表示され、３次元空間で動きの幻影を作り出す。対話式３Ｄコンピュータ・グラフィクスを使えば、ユーザーはリアルタイムで自分の視点を変え、又はジオメトリを変え、レンダリング・システムにリアルタイムでオンザフライに新しいイメージを作らせることができる。
【０００４】  ３Ｄコンピュータ・グラフィクスでは、各レンダ可能オブジェクトは一般的に自分固有のローカル・オブジェクト座標系を有しているので、オブジェクト座標からピクセル表示オブジェクトに翻訳（又は変換）される必要がある。概念的には、これは４段階即ち、１）オブジェクト座標から、全シーン用の座標系であるワールド座標への（拡大又は縮小のためのスケール調整を含む）変換、２）そのシーンの視点に基づく、ワールド座標からアイ座標への変換、３）遠近スケール調整（遠くのオブジェクトが小さく見える）を行う、アイ座標から遠近法的に変換されたアイ座標への変換、４）遠近法的に変換されたアイ座標から、スクリーン座標とも呼ばれるピクセル座標への変換、の４段階プロセスである。スクリーン座標は、３次元空間内の点であり、後に述べるように、スクリーン精度（即ちピクセル）又はオブジェクト精度（高精度数、通常浮動小数点）の何れかにあってもよい。これらの変換段階は、どの変換を行う前でも適切な変換マトリクスを事前計算することにより、１つ又は２つの段階に圧縮することができる。ジオメトリがスクリーン座標系の中にできれば、ピクセルカラー値のセットに分解され（即ちラスタライズされ）フレームバッファ内に記憶される。ピクセルカラー値を生成するために、ガウロード・シェーディング、フォング・シェーディング、テクスチャマッピングを始め多くの技法が使われている。
【０００５】  先行技術によるレンダリングプロセスの概要は、ワット著「３次元コンピュータ・グラフィクスの基礎」の第５章レンダリング・プロセス９７−１１３頁（マサチューセッツ州リーディングのアディソン−ウェズリー出版社、１９８９年出版、１９９１年再版、ＩＳＢＮ０−２０１−１５４４２−０、以後、ワット文献と称す）にあり、参考文献としてここに援用する。
【０００６】  図１は３次元のオブジェクト、４面体をそれ自身の座標軸（Ｘｏｂｊ、Ｙｏｂｊ、Ｚｏｂｊ）で示している。３次元オブジェクトは、変換、スケール調整され、（Ｘｅｙｅ、Ｙｅｙｅ、Ｚｅｙｅ）に基づく視点座標系内に置かれる。オブジェクトは視認面上に投影され、それにより遠近調整される。この時点で、オブジェクトは２次元になったように見えるが、オブジェクトのｚ座標は保存されているので、後で陰面除去法に使うことができる。オブジェクトは最終的には（Ｘｓｃｒｅｅｎ、Ｙｓｃｒｅｅｎ、Ｚｓｃｒｅｅｎ）に基づくスクリーン座標に変換されるが、ここでＺｓｃｒｅｅｎは紙面に直角方向である。オブジェクト上の点は今、ピクセル位置（及びそのフラクション）により記述された自身のｘ、ｙ座標をディスプレイスクリーン内に有し、自身のｚ座標を視点からの距離のスケール調整バージョン内に有している。
【０００７】  ジオメトリの多くの異なる部分が同じピクセルに影響を及ぼし得るので、シーン視点に最も近い面を表すジオメトリを決めなければならない。従って、各ピクセル毎に、ピクセルのエリアにより境界付けられたボリューム内の可視面がピクセル・カラー値を決め、一方隠された面はピクセルに影響を及ぼさないようにされる。視点に最も近い不透明面（ジオメトリのエッジ（辺）がピクセルエリアと交差していれば、複数の面）よりも近くにある透明面はピクセルカラー値に影響を及ぼすが、一方、他の全ての透明面は捨てられる。本文書では「遮られた」という用語を、他の透明なジオメトリにより隠されたジオメトリを記述するのに用いる。
【０００８】  多くの技法が可視面決定を行うために開発されているが、それらの技法は、フォーリィ、ヴァン・ダム、ファイナー、ヒュー共著の「コンピュータ・グラフィクス：原理と実践」第１５章可視面決定、６７４−７２０頁（マサチューセッツ州リーディング、アディソン−ウェズリー出版社、第２版１９９０年出版、修正済み再版１９９１年、ＩＳＢＮ０−２０１−１２１００−７、以後フォーリィ文献と呼ぶ）に概括されており、参考文献としてここに援用する。フォーリィ文献では、６５０頁に「イメージ精度」及び「オブジェクト精度」という用語が「イメージ精度アルゴリズムは、通常、ディスプレイ装置の分解能で実行され、各ピクセルにおける視認性を決める」そして「オブジェクト精度アルゴリズムは、各オブジェクトが定義される精度で実行され、各オブジェクトの視認性を決める」と定義されている。
【０００９】  レンダリング・プロセスを進める際、大抵の先行技術によるレンダラーは、複数の面がピクセルによって境界付けられたボリュームと交差するので、所与のスクリーン・ピクセルのカラー値を、何度も計算しなければならない。ある特定のシーンに対して、ピクセルをレンダーしなければならない平均の回数を、そのシーンのデプス・コンプレキシティと呼ぶ。単純なシーンは単一に近いデプス・コンプレキシティを持っているが、複雑なシーンは１０又は２０のデプス・コンプレキシティを有することもある。シーンモデルが複雑になるほど、レンダラーは増加し続けるデプス・コンプレキシティのシーンを処理するよう要求されることになる。従って大部分のレンダラーにとって、シーンのデプス・コンプレキシティは、浪費された処理の尺度となる。例えば、１０のデプス・コンプレキシティを有するシーンでは、計算の９０％が隠されたピクセルに費やされる。この浪費される計算は、ハードウェア内に容易に構築できるという理由で一般的に選定される単純なＺバッファ技法（後に議論する）を使うハードウェア・レンダラーに典型的なことである。Ｚバッファ技法より複雑な方法は、今まで一般的に、費用対効果のよいやり方で構築するには複雑過ぎた。本発明が提供する方法及び装置の重要な特徴は、費用対効果の優れたハードウェアに構築できるほど簡単でありながら、ラスタライズされる前にジオメトリの隠された部分を削除することにより、この浪費される計算を省くことである。
【００１０】  面上の点（しばしば多角形の頂点）をスクリーン座標に変換する際、点は３つの座標即ち、１）ピクセル・ユニット（一般的にはフラクションを含む）内のｘ座標、２）ピクセル・ユニット（一般的にはフラクションを含む）内のｙ座標、及び３）アイ座標、バーチャル・スクリーンからの距離、又は視点からの面の相対距離を保存する何か他の座標系、の内何れかのｚ座標、を有する。本文書では、正のｚ座標値を視点から「見る方向」に使い、値が小さいほど視点近くの位置を示すように用いる。
【００１１】  面を平面多角形のセットで近似する場合、各多角形の頂点がスクリーン座標に変換される。多角形内又は（頂点以外の）多角形上の点に関し、スクリーン座標は、通常エッジ・ウォーキング及びスパン補間の処理により、頂点の座標から補間される。このように、ｚ座標値は、ジオメトリがレンダされる際、一般的には各ピクセル値に（カラー値と共に）含まれている。
総称３Ｄグラフィクス・パイプライン
多くのハードウェア・レンダーが開発されており、ここに参考文献として、ＳＩＧＧＲＡＰ９３会報１０１−１０８頁ディアリング、ネルソン共著の「レオ：費用対効果の優れた３Ｄシェーデッド・グラフィクスのためのシステム」を紹介し（１９９３年８月１−６、コンピュータ・グラフィクス会報、年次会議、ニューヨーク州ＡＣＭ  ＳＩＧＧＲＡＰＨ発行、１９９３年、ソフトカバーＩＳＢＮ０−２０１−５８８８９−７、ＣＤ−ＲＯＭ  ＩＳＢＮ０−２０１−５６９９７−３、以後ディアリング文献と称す）ここに援用する。ディアリング文献は、図２に再製して示す、総称的３Ｄグラフィクス・パイプライン（即ちレンダラー、又はレンダリング・システム）のダイアグラムを含んでいる。
【００１２】  図２から分かるように、データ入力（ステップ２１２）の後の、総称的３Ｄグラフィクス・パイプラインの浮動小数点示強関数内の最初のステップは、変換ステップ（ステップ２１４）である。変換ステップはフロー・ダイアグラムの外部ループの第１ステップでもあり、又「次の多角形入手」を含んでいる。第２ステップ、クリップテストは、多角形をチェックし、少なくとも部分的にはビュー・ボリューム（時には円錐台、角錐台の形状をしている）に含まれているかを調べる（ステップ２１６）。多角形がビュー・ボリューム内にない場合には捨てられ、そうでない場合には処理が続く。第３ステップは面決定であり、ここで視点と面していない多角形は捨てられる（ステップ２１８）。一般的には、面決定は、閉じたボリュームであるオブジェクトに対してだけ行われる。第４ステップ、ライティング計算は、普通は、種々の型式の多数の光源によるガウロードシェーディング及び／又はテクスチャ・マッピングに対するセットアップを含んでいるが、フォング・シェーディング又は他の多くの選択肢の１つに対するセットアップであってもよい（ステップ２２２）。第５ステップ、クリッピングは、ビュー・ボリュームの外側にある多角形のあらゆる部分を、その部分が視認面の長方形領域内に投影されないので削除する（ステップ２２４）。一般的に、多角形クリッピングは多角形を共に視認面のエリア内に突き出る２つの小さな多角形に分割することにより行われる。多角形クリッピングは計算的には費用が掛かる。第６ステップ、遠近法的分割は、オブジェクトの視認面上への投影に対し、遠近法的修正を行う（ステップ２２６）。この時点で、多角形の頂点を表す点は、ステップ７、スクリーン空間変換ステップ（ステップ２２８）により、ピクセル空間座標に変換される。第８ステップ（ステップ２３０）、インクレメンタル・レンダー用セットアップは、エッジ・ウォーキング及びスパン補間に必要な、種々の開始、終了、及びインクレメンタル値（例えば、ｘ、ｙ、ｚ座標、ＲＧＢカラー、テクスチャ・マップ空間ｕ−及びｖ−座標等）を計算する。
【００１３】  描画示強関数内で、エッジ・ウォーキング（ステップ２３２）は、（同じ多角形内の）先に生成されたスパンから値を漸増し、それにより多角形の相対するエッジに沿って垂直に「ウォーキング」することによって、ディスプレイ装置の各ラスター・ライン毎に逐次水平スパンを生成する。同様に、スパン補間（ステップ２３４）は、ピクセルの視点からの距離を示す２座標値を含め、ピクセル値を生成するためにスパンに沿って水平に「ウォーク」する。最後に、テスティング及びブレンディング（ステップ２３６）とも呼ばれるｚバッファド・ブレンディングが最終ピクセル・カラー値を生成する。ピクセル値はカラー値も含んでおり、これは単純なガウロード・シェーディング（即ち頂点カラー値の補間）又は（おそらく複数のテクスチャ・マップも一緒にブレンドして）テクスチャ・マッピング、フォング・シェーディング（即ちフラグメント毎ライティング）及び／又は（補間面法線を摂動させる）バンプ・マッピングのような計算的により費用の掛かる技法によって生成することもできる。描画示強関数が完了した後、ダブルバッファドＭＵＸアウトプット・ルックアップ・テーブル・オペレーションが実行される（ステップ２３８）。この図で、角の丸いブロックは、関数又はプロセスオペレーションを表し、角の尖った長方形は記憶されたデータ又はメモリを表す。
【００１４】  生成されたｚ座標値をＺバッファ内に記憶されている対応する値と比較することによって、ｚバッファド・ブレンドは、新しいピクセル値を（そのピクセル位置に対して先に記憶されていた値よりも視点に近ければ）フレーム・バッファに書き込んで保持するか、或いは（遠ければ）新しいピクセル値を捨てる。このステップで、アンチェイリアジング法は新しいピクセル・カラーを古いピクセル・カラーとブレンドすることができる。ｚバッファド・ブレンドは、一般的にフラグメント毎オペレーションの大部分を含んでおり、後に述べる。
【００１５】  総称的３Ｄグラフィクス・パイプラインはダブルバッファド・フレーム・バッファを含んでいるので、ダブルバッファドＭＵＸも含まれている。カラー・マップ値を変換するために、アウトプット・ルックアップテーブルが含まれている。最後に、ディスプレイ装置への入力のために、ディジタル・アナログ変換によってアナログ信号が作られる。
総称的３Ｄグラフィクス・パイプラインの主な欠点は、その描画示強関数が、決められた数の多角形を与えらた場合、ピクセル・レベルで決定論的ではないということである。即ち、決められた数の多角形を与えらた場合、平均多角形サイズが大きくなるほど、多くのピクセル・レベルの計算が必要になる。しかし、浮動小数点示強関数は多角形の数に比例し、平均多角形サイズとは無関係である。従って、浮動小数点示強関数と描画示強関数との間の計算パワーの量のバランスをとるのは、このバランスが平均多角形サイズに依存しているので難しい。
【００１６】  先行技術によるＺバッファは、従来型のランダムアクセスメモリ（ＲＡＭ又はＤＲＡＭ）、ビデオＲＡＭ（ＶＲＡＭ）又は特定目的ＤＲＡＭに基づいている。特定目的ＤＲＡＭの例は、ＳＩＧＧＲＡＰＨ９４会報１６７−１７４頁、ディアリング、シュラップ、ラベル共著の「ＦＢＲＡＭ：３Ｄグラフィクス用に最適化された新しい形態のメモリ」（１９９４年７月２４−２９、コンピュータ・グラフィクス会報、年次会議、ニューヨーク州ＡＣＭＳＩＧＧＲＡＰＨ発行、１９９４年ソフトカバーＩＳＢＮ０２０１６０７９５６）に述べられており、ここに参考文献として援用する。
パイプライン状態
オープンＧＬは、プログラマーがオブジェクト及びオペレーションを指定しグラフィカル・イメージを作り出せるようにする数百の関数及びプロシジャから構成されるグラフィクス・ハードウェアに対するソフトウェア・インタフェースである。オブジェクト及びオペレーションには、３次元オブジェクトのカラー・イメージを作るための適切な特性が含まれている。オープンＧＬ（バージョン１．２）の大部分は、たとえオブジェクトが点、線、多角形又はビット・マップであり、オペレーションがオブジェクト上のオペレーションであっても、グラフィクス・ハードウェアがフレーム・バッファを含んでいると仮定し、或いはそう要求している。オープンＧＬの一般的特徴（グラフィカル・インタフェースの単なる１例）は、マーク・シーガル及びカート・エイクレイ編集の「オープンＧＬグラフィクス・システム：仕様書（バージョン１．２）」（バージョン１．２、１９９８年５月）に述べられており、参考文献としてここに援用する。オープンＧＬを参考にしてはいるが、本発明は、オープンＧＬ又は他の標準的又は非標準的グラフィカル・インタフェースと調和し、密接に結びついた構造、プロシジャ又は方法に限定されるわけではない。望ましいのは、本発明の構造及び方法がオープンＧＬ又は他の標準的グラフィカル・インタフェースと調和するやり方で実行することができ、従って、標準的インタフェースの１つのために整えられたデータ・セットが、修正することなく本発明の構造及び方法で処理できることである。しかし、本発明の構造及び方法は、オープンＧＬが提供しない幾つかの特徴を提供しており、たとえそのような総称的入出力が提供された場合でも、違った方法で実行される。
【００１７】  「パイプライン状態」という用語は先行技術では単一の定義を持っていなかった。例えば、オープンＧＬの仕様書は、状態の項目及びその状態の情報を記憶するのに必要なビット及びバイトの数に関する、グラフィクス・レンダリング・マシンの型式及び量、又はパイプライン状態を述べている。オープンＧＬの定義では、パイフライン状態は、例えば「非頂点」情報に加え、頂点自身、頂点法線、カラーを初めとするオブジェクト頂点関連情報を含む傾向にある。
【００１８】  情報がグラフィクス・レンダラー内に送られる時には、少なくとも幾つかのオブジェクト・ジオメトリ情報が、シーンを記述するために供給される。通常、単数又は複数のオブジェクトが頂点情報に関して指定され、そこでオブジェクトはモデル化され、定義され、そうでなければ点、線又は１つ又はそれ以上の頂点から構成される多角形（オブジェクト・プリミティブ）によって指定される。一言で言えば、頂点は空間内の位置であり、例えば、ある基準点に対する３つの空間（ｘ、ｙ、ｚ）座標で指定することができる。各頂点に関しては、面法線、カラー、テクスチャ、透明度、頂点の特性に関する同様な情報のような他の情報もある。この情報は、基本的に「頂点毎」の情報である。まずいことに、入ってくる入力情報と頂点との間の１対１の関係を頂点毎情報に関する要件として強制するのは、不必要に制約的である。例えば、カラー値は特定の頂点に対するデータ・ストリーム内で指定され、後に続く頂点に対しカラーが変わるまではデータ・ストリーム内で再指定されることはない。カラー値が各頂点に対する入力データ・ストリーム内に明示的に含まれていない場合でも、カラー値はなお頂点毎データとして特性付けられる。
【００１９】  テクスチャ・マッピングは、頂点毎情報かパイプライン状態情報の何れかと考えることのできる情報又はデータの興味ある例を示す。各オブジェクト毎に、それぞれが単数又は複数のテクスチャ座標のようなあるやり方で特定されている１つ又はそれ以上のテクスチャ・マップが指定される。ある人は自分がテクスチャ座標で指しているテクスチャ・マップをパイプライン状態の一部と考えることができ、一方別の人はそれが頂点毎情報であると主張することもできる。
【００２０】  ジオメトリ・オブジェクト・プリミティブに１対１ベースでは関係しない、ライティングの位置及び輝度、材料セッティング、反射特性、及びレンダラーがオペレーションの際に準拠するその他全ての規則のようなレンダラーが使用する他の情報は、もっと正確にパイプライン情報であるということができる。頂点毎ベースでは変化しないか、しないであろう全てのものがパイプライン状態であると考えることもできるが、記述された理由からこれは全く不明確な定義ではない。例えば、ある人は、レンダされるべきあるオブジェクトに適用されるべきある特定のデプス・テストを、例えば、デプス・テストは、ｚ値が幾つかのオブジェクトに対しては厳密に「より大き」く、他のオブジェクトに対しては「同等又はより大き」いことを要求してもよいと、定義することができる。時によって変わるこれら特定のデプス・テストは、その時点のパイプライン状態であると考えることができる。オープンＧＬでレンダラー（パイプライン状態）であると考えられるパラメータは、先に挙げたオープンＧＬ仕様書（バージョン１．２、１９３−２１７頁）の第６．２節に挙げられている。
【００２１】  基本的に、レンダラーにが使用するデータ又は情報には２つの型式があり、それは、１）頂点毎データと考えられるプリミティブ・データと、２）それ以外のパイプライン状態データ（又は単にパイプライン状態）である。ある情報事項をパイプライン状態又は非パイプライン状態の何れかとして取り扱うグラフィクスレンダラーを実行するには複数の方法があるので、この区別は、特定の規則というよりガイドラインと考えるべきである。
フラグメント毎オペレーション
総称的３Ｄグラフィクス・パイプラインでは「ｚバッファド・ブレンド」段階は実際に多くの小さな「フラグメント毎」のオペレーション段階を含んでいる。オープンＧＬ（オープン・グラフィクス・ライブラリ）及びＤ３Ｄのようなアプリケーション・プログラム・インタフェース（ＡＰＩ）はフラグメント毎オペレーションのセットを定義（バージョン１．２オープンＧＬ仕様書第４章を参照）する。ここで幾つか代表的オープンＧＬフラグメント毎オペレーションを簡単にレビューし、本発明の構造及び方法と従来型の構造及びプロシジャのと間のあらゆる総称的類似性及び差異を容易に理解できるようにする。
【００２２】  オープンＧＬでは、フレーム・バッファはピクセルのセットを２次元アレイとして記憶する。フレーム・バッファ内に記憶されている各ピクチャ・エレメント又はピクセルは、単なる幾つかの数のビットのセットである。ピクセル毎のビットの数は、特定のＧＬのインプリメンテーション又はコンテクストにより変動する。
【００２３】  フレームバッファ内の各ピクセルからの対応するビットは、それぞれが各ピクセルからの単一のビットを含んでいる、１つのビット・プレーン内に一緒にグルーピングされる。ビット・プレーンは、カラー、デプス、ステンシル、累積バッファと呼ばれる幾つかのロジカル・バッファにグルーピングされる。そのカラーバッファは、オープンＧＬでは、前左バッファ、前右バッファ、後左バッファ、後右バッファ、及び幾つかの付加的補助バッファと呼ばれているものを含んでいる。前バッファに記憶されている値は、通常、ディスプレイ・モニタ上に表示されるが、後バッファ及び補助バッファの内容は見えず、表示されない。ステレオスコープ的コンテクストは前左及び前右バッファの両方を表示するが、モノスコープ的コンテクストは前左バッファのみを表示する。一般的に、カラー・バッファは同じ数のビット・プレーンを有していなければならないが、特定のコンテクストのインプリメンテーションは右バッファ、後バッファ又は補助バッファを全く提供せず、インプリメンテーション又はコンテクストは、ステンシル、デプス又は累積バッファを付加的に供給するか又は供給しない。
【００２４】  オープンＧＬでは、カラー・バッファは符号無し整数カラー・インデクスか、Ｒ、Ｇ、Ｂ及び随意的に符号無し整数値の数「Ａ」の何れかから成り、各カラーバッファのビット・プレーンの数、デプス・バッファ（もし有れば）、ステンシルバッファ（もし有れば）及び累積バッファ（もし有れば）が固定され、ウインドウ次第である。累積バッファが提供されている場合、累積バッファは少なくともカラーバッファが持っていると同じ数だけ、Ｒ、Ｇ、Ｂカラー要素毎にビット・プレーンを持っていなければならない。
【００２５】  ウインドウ座標（Ｘｗ、ｙｗ）を使ってラスタライズして作られたフラグメントは、テスト、パラメータ、条件の数に基づいて、ピクセルをフレーム・バッファ内でその位置で変更する。フラグメント及びその関係するデータから始めフレーム・バッファへの最終出力ストリームで終わる、通常連続的に実行される幾つかのテストの中で注目すべきなのは、実行される順序（ＡＰＩによっては多少変わる）で、１）ピクセル・オーナシップ・テスト、２）シザー・テスト、３）アルファ・テスト、４）カラー・テスト、５）ステンシル・テスト、６）デプス・テスト、７）ブレンディング、８）ディザリング、９）ロジコップである。オープンＧＬは、アルファ・テストとステンシル・テストとの間の明示的「カラー・テスト」には備えていないことに留意すべきである。オープンＧＬでのフラグメント毎オペレーションは、全カラー計算の後に行われる。
【００２６】    （発明の概要）
ある態様において、本発明は、ディファード・グラフィクス・パイプライン・プロセッサ用の構造と方法とを提供している。有益にも、パイプライン・プロセッサは、１つ又はそれ以上のコマンド・フェッチ及びデコード・ユニット、ジオメトリ・ユニット、モード抽出ユニット及び多角形メモリ、ソート・ユニット及びソート・メモリ、セットアップ・ユニット、カル・ユニット、モード注入ユニット、フラグメント・ユニット、テクスチャ・ユニット、フォング・ライティング・ユニット、ピクセル・ユニット、フレーム・バッファと結合したバックエンド・ユニットを含んでいる。これらのユニットはそれぞれ独立して他のプロセッシング・スキームと組み合わせて、及び／又は、グラフィカル又はイメージ・データ以外のデータを処理するのにも使われる。
【００２７】  別の態様において、本発明は、通信チャネル経由の外部コンピュータからのデータ及び／又はコマンドのインプットを伝達し、カラー、面法線、テクスチャ座標、レンダリング情報、ライティング、ブレンディング・モード、バッファ関数から成るグループから選択された情報項目を含む一連のパケットにインプットを変換する、コマンド・フェッチ及びデコード・ユニットを提供している。
【００２８】  又別の態様において、本発明は、パケットを受信し、座標変換、全ての多角形の実際の又は下位の三角形への分解、ボリューム・クリッピングの視認、そして随意的にガウロード・シェーディングに必要な頂点毎のライティング及びカラー計算を実行する、ジオメトリ・ユニット用の構造及び方法を提供している。
【００２９】  又別の態様において、本発明は、ジオメトリ・ユニットからデータ・ストリームを受信し、データ・ストリームをソート・ユニットに伝達される頂点データと記憶のために多角形記憶装置に送られる非頂点データとに分けるモード抽出ユニットと、多角形ユニットに関係する多角形メモリとのための構造及び方法を提供している。
【００３０】  又別の態様において、本発明は、モード抽出ユニットから頂点を受信して結果としてのポイント、ライン、三角形をタイルでソートし、ソート済みジオメトリをタイル毎の順に完全なプリミティブを表すソート・ブロック・アウトプット・パケットでセットアップ・ユニットに伝達するソート・ユニットと、ソートユニットに関係するソート・メモリのための構造及び方法を提供している。
【００３１】  又別の態様において、本発明は、ソート・ブロック・アウトプット・パケットを受信し、タイル毎ベースに１度に１プリミティブ、ライン及び三角形のために空間導関数を計算するセットアップ・ユニットのための構造及び方法を提供している。
【００３２】  又別の態様において、本発明は、１度に１タイル相当のデータを受信し、先に処理したジオメトリにより完全に隠されているプリミティブを捨てるように作動可能なマグニチュード・コンパリソン・コンテンツ・アドレス可能メモリ（ＭＣＣＡＭ）カル・サブユニットと、部分的に又は全体が見える残りのプリミティブを処理し、これらのこりのプリミティブの可視フラグメントを決め、１度に１スタンプ相当のフラグメントを出力するサブピクセル・カル・サブユニットとを有している、カル・ユニットのための構造及び方法を提供している。
【００３３】  又別の態様において本発明は、カル・ユニットからインプットを受信し、多角形メモリからのカラー及び材料特性を含むモード情報を検索し、モード情報を１つ又はそれ以上のフラグメント・ユニット、テクスチャ・ユニット、フォング・ユニット、ピクセル・ユニット、バックエンド・ユニットに伝達するモード注入ユニットのための構造及び方法を提供しており、その際、フラグメント・ユニット、テクスチャ・ユニット、フォング・ユニット、ピクセル・ユニット、又はバックエンド・ユニットの少なくとも幾つかは、最近使用されたモード情報のキャッシュのためのモード・キャッシュを含んでおり、モード注入ユニットは、既にキャッシュされた情報を識別して既にキャッシュされた情報は送らないようにする状態情報を維持し、それによって通信帯域幅を低減するようになっている。
【００３４】  又別の態様において、本発明は、ガウロード・シェーディングのためにカラー値を補間し、フォング・シェーディングのために面法線を補間し、テクスチャ・マッピングのためにテクスチャ座標を補間し、テクスチャを高さフィールド勾配として表すバンプ・マップが使われている場合は面正接を補間するための、共通重心係数を使用して遠近修正補間を行うフラグメント・ユニットのための構造及び方法を提供している。
【００３５】  又別の態様において、本発明はテクスチャ・ユニット及びテクスチャユニットに関係するテクスチャ・メモリのための構造及び方法を提供しており、その際、テクスチャ・ユニットはテクスチャ・メモリに記憶されているテクスチャ・マップをピクセル・フラグメントに適用し、テクスチャはＭＩＰマップされていて、異なる詳細度の一連のテクスチャ・マップを備えており、各マップは視点からの所与の距離のテクスチャの外観を表しており、テクスチャ・ユニットは、正しい詳細度を近似する所与のピクセル・フラグメントに対するテクスチャ値を作るためにテクスチャ・マップから三線形補間を実行し、テクスチャ・ユニットは、補間済みのテクスチャ値をフラグメント毎ベースにフォング・ユニットに伝達するようになっている。
【００３６】  又別の態様において、本発明は、フラグメントの見かけのカラーを決めるために、モード注入ユニットにより供給される材料及びライティング情報、テクスチャ・ユニットからのテクスチャ・カラー、フラグメント・ユニットにより生成される面法線を使って、各ピクセル・フラグメント毎にフォング・シェーディングを実行するための構造及び方法を提供しており、その際、フォング・ブロックは随意的に、バンプ・マッピングが使われている場合はシェーディング前にフラグメントの面法線を摂動させるためにテクスチャ・ユニットからの補間済み高さフィールド勾配を使うようになっている。
【００３７】  又別の態様において、本発明は、各フラグメントが独立したカラー値を有している可視スタンプ部分とも呼ばれているが、１度に１スタンプ相当のフラグメントを受信し、各ピクセル内の各サンプル上で、ピクセル所有権テスト、シザー・テスト、アルファ・テスト、ステンシル・オペレーション、デプス・テスト、ブレンディング、ディザリング、論理演算を実行し、１タイル相当の終了したピクセルを累算した後、ピクセルをアンチェイリアスするために各ピクセル内のサンプルをブレンドし、アンチェイリアスド・ピクセルをバックエンド・ユニットに伝達するピクセルユニットのための構造及び方法を提供している。
【００３８】  又別の態様において、本発明は、ピクセル・ユニットから１度に１タイル相当のピクセルを受信し、ピクセルをフレーム・バッファ内に記憶するための、ピクセル・ユニットに連結されたバックエンド・ユニットのための構造及び方法を提供している。
本発明の態様の概観−トップレベルの概要
コンピュータ・グラフィクスは、コンピュータでピクチャ又はイメージを生成する技術であり科学である。このピクチャ生成は、普通、レンダリングと呼ばれる。例えば３次元アニメーション内の動きは、連続したイメージを表示することによって作り出される。対話式３次元（３Ｄ）コンピュータ・グラフィクスを使えば、ユーザーは、リアルタイムで自分の視点を変え、或いはジオメトリを変えて、レンダリング・システムにリアルタイムで、オンザフライに新しいイメージを作るように要求することができる。従って、高品質な形象を備えたカラーにおけるリアルタイムな性能が益々重要になってきている。
【００３９】  本発明は、新しいグラフィクス・プロセッサと方法に向けられており、特化したサブシステム、サブプロセッサ、デバイス、アーキテクチャ、及び対応するプロシジャを含む数多くのサブ構造を包含している。本発明の実施例は、１つ又はそれ以上のディファード・シェーディング、タイルド・フレーム・バッファ、多ステージ陰面除去プロセッシングを、他の構造及び／又はプロシジャと共に含んでいる。本明細書では、グラフィクス・プロセッサを、以後（ディファード・シェーディング・グラフィクス・プロセッサに対する）ＤＳＧＰ、又はＤＳＧＰパイプライン、そして時にはパイプラインとも呼ぶ。
【００４０】  本発明は数多くのＤＳＧＰパイプラインの実施例を含んでいる。本発明の実施例は、ハードウェアに、フォング・シェーディング、サブピクセル・アンチェイリアジング、テクスチャ及びバンプ・マッピングを備えた、高性能３Ｄグラフィクスを提供するように設計されている。ＤＳＧＰパイプラインは、性能を損なうことなく、これらの洗練された特徴を提供する。
【００４１】  ＤＳＧＰパイプラインは、これに限定するわけではないが、可能なインタフェースの選択肢の中で、例えばアドバンスド・グラフィクス・ポート（ＡＧＰ）及び／又はＰＣＩバス・インタフェースを含む種々の可能なインタフェース経由でコンピュータに接続することができる。ＶＧＡ及びビデオ・アウトプットも概ね含まれる。本発明の実施例は、オープンＧＬ及びダイレクト３Ｄ・ＡＰＩを両方共サポートする。マーク・シーガル及びカート・エイクレイ著、ジョン・リーチ編集の「オープンＧＬグラフィクス・システム、仕様書バージョン１．２」と題するオープンＧＬ仕様書を参考文献としてここに援用する。
【００４２】  ディファード・シェーディング・グラフィクス・パイプラインの幾つかの代表的実施例又はバージョンを説明する。
ディファード・シェーディング・グラフィクス・パイプラインのバージョン
ディファード・シェーディング・グラフィクス・パイプラインの幾つかのバージョン又は実施例がここに説明され、種々の特徴の組み合わせを有する実施例が実行される。又、本発明の特徴は他の特徴から独立して実行することもできる。上記の重要な特徴の大部分はＤＳＧＰパイプラインの全てのバージョンに適用できる。
タイル、スタンプ、サンプル、フラグメント
３Ｄグラフィクス・プリミティブの（シーン又はユーザー・フレームとも呼ばれる）各フレームは、ディスプレイ・スクリーン上の３Ｄウィンドウにレンダーされる。ウィンドウは長方形のピクセルのグリッドから構成され、タイル（以後タイルは１６ｘ１６ピクセルと仮定するが、サイズは幾つでもよい）に分割される。タイルか使用されない場合、ウィンドウは１つのタイルと考えられる。各タイルは更にスタンプ（以後スタンプは２ｘ２ピクセルと仮定し、従って１タイル当たり６４ピクセルとなるが、スタンプはタイル内のどんなサイズでもよい）に分割される。各ピクセルは１つ又はそれ以上のサンプルを含んでおり、各サンプルはそれ自身のカラー値、及び２値（以後ピクセルは４つのサンプルを含むものと仮定するが、数は幾つでもよい）を有している。フラグメントは、特定のピクセル内のプリミティブによってカバーされたサンプルの集合である。用語「フラグメント」は特定のプリミティブ及び特定のピクセル内の可視サンプルの集合にも使われる。
ディファード・シェーディング
通常のＺバッファ・レンダリングでは、レンダラーは、各プリミティブの各ピクセル毎にカラー値（ＲＧＢ又はＲＧＢＡ）及びｚ値を計算し、次に、新しいピクセルのｚ値をＺバッファ内の現在のｚ値と比較する。ｚ値比較の結果、新しいピクセルがフレーム・バッファ内に現存するピクセルより「前」にあれば、新しいピクセルが古いものに上書きされ、そうでない場合は、新しいピクセルは捨てられる。
【００４３】  Ｚバッファ・レンダリングは、巧く機能し、複雑なハードウェアを何ら必要としない。しかし、シーンが多くの陰面を含んでいる場合、通常、大量の無駄な計算を行う結果となる。複雑なシーンでは、レンダラーは最終ピクチャ内に見えるピクセルの１０又は１２倍ものカラー値を計算することになる。これは、フォング・シェーディング又はテクスチャ・マッピングのような、何れのピクセル毎オペレーションの計算コストも１０又は１２倍となることを意味する。全フレームに亘って平均したピクセル当たりの面の数は、フレームのデプス・コンプレキシティと呼ばれる。通常のｚバッファド・レンダラーではデプス・コンプレキシティは、特定のフレームをレンダーする際のレンダラーの非効率の尺度である。
【００４４】  ディファード・シェーディングを行うパイプラインでは、全てのピクセル・カラリングを行う前に陰面除去（ＨＳＲ）が完了する。ディファード・シェーディング・パイプラインのオブジェクティブは、最終イメージに現れる（即ち、正確なＨＳＲ）プリミティブに対してのみピクセル・カラーを生成する。ディファード・シェーディングでは一般的に、ＨＳＲを始める前にプリミティブが累算される必要がある。不透明なプリミティブだけのフレームでは、ＨＳＲプロセスは、全ピクセル内の各サンプルに単一の可視プリミティブを決める。可視プリミティブがサンプルに対し決められると、次に、そのサンプル位置のプリミティブのカラーが決められる。サンプル毎カラーを計算するのではなく、同一ピクセル内の全サンプルに対する単一のピクセル毎カラーを決めることにより、更に効率が上がる。
【００４５】  少なくとも幾つかの、プリミティブの（前記オープンＧＬ仕様書で定義されている）アルファ・ブレンディングの有るフレームに対しては、２つ又はそれ以上のプリミティブで着色された幾つかのサンプルがある。これは、ＨＳＲプロセスがサンプル毎に可視プリミティブのセットを決めなければならないということを意味している。
【００４６】  オープンＧＬのような幾つかのＡＰＩでは、ＨＳＲプロセスは、プリミティブを捨てることのできる（デプス・テスト以外のオペレーションによる）他のオペレーションによって複雑化することがある。この他のオペレーションには（本明細書の別の場所に記載したように）ピクセル所有権テスト、シザー・テスト、アルファ・テスト、カラー・テスト、ステンシル・テストが含まれる。これらのオペレーションの幾つかは、プリミティブを（例えばアルファ・テストで）その色に基づいて捨てるが、これは、ディファード・シェーディング・パイプラインでは（アルファ値がしばしば、ピクセル・フラグメント・カラリングに含まれるテクスチャリング・プロセスで生成されるため）ＨＳＲプロセス後まで決められない。例えば、通常は（一般的にはｚ値の大きい）より遠いプリミティブを覆い隠すはずのプリミティブがアルファ・テストにより捨てられ、その結果、更に遠くにあるプリミティブを覆い隠さないようにしてしまうことがある。アルファ・テストを考慮しないＨＳＲプロセスは、更に遠くにあるプリミティブを間違って捨てることもあり得る。ディファード・シェーディングとアルファ・テスト（同様にカラー・テスト及びステンシル・テスト）との間には一貫性が無いので、ピクセル・カラリングが陰面除去後まで延期されるが、陰面除去はピクセル・カラーに依存していることもある。この問題の簡単な解には、１）アルファ・テスト、カラー・テスト、ステンシル・テスト等の非デプス依存テストをＡＰＩから削除する、−但し、この解では既存プログラムがディファード・シェーディング・パイプライン上で適切に実行されるのを妨げるかもしれない−、２）ＨＳＲプロセスに必要なときだけ幾つかのカラー生成を行わせる、−但し、この解はデータ・フローをかなり複雑化することになるであろう−、という２つの解が含まれる。従って、この２つの選択は共に魅力的ではない。保存性陰面除去法（ＣＨＳＲ）と呼ばれる第３の代案は、本発明の構造及び方法によって提供される重要な革新である。ＣＨＳＲは本明細書の次の節で詳細に説明する。
【００４７】  多くのＡＰＩでもう一つ複雑なのは、デプス・テストを変えるためのその能力である。３Ｄレンダリングについて考える標準的方法では、可視オブジェクトは覆い隠されたオブジェクトよりも近い（即ち、ｚ値がより小さい）と仮定し、これは「未満」デプス・テスト（即ち、ｚ値が他のジオメトリ「未満」であれば、そのオブジェクトは可視とする）を選択することにより行われる。しかし、大抵のＡＰＩは、超過、未満、以上、同等、以下、未満、非同等などの代数的、量的及び論理的関係のような他のデプス・テストをサポートしている。これが基本的に、可視であるものに対する「規則を変える」のである。この複雑性は、アプリケーション・プログラムがフレーム内のデプス・テストを変えることを、ＡＰＩが許していることにより生じる。異なるジオメトリが、視認性に対し劇的に異なる規則に曝されることになる。ここで、異なるレンダリング規則を有するプリミティブの時間順を考慮しなければならない。例えば、図４に示す例では、３つのプリミティブがそれぞれのデプス・テスト（図にはｚ寸法だけが示されており、これは１サンプルの場合と考えられる）と共に示されている。Ａ、Ｂ、Ｃの順にレンダーされる場合、プリミティブＢが最終可視面となる。しかし、Ｃ、Ｂ、Ａの順にレンダーされる場合は、プリミティブＡが最終可視面となる。これは、ディファード・シェーディング・パイプラインが、プリミティブの時間順をどのように保存しなければならないかを示しており、正しいパイプライン状態（例えばデプス・テスト）が各プリミティブに関係付けられねばならないことを示している。
ディファード・シェーディング・グラフィクス・パイプライン、第１実施例（バージョン１）
従来型３Ｄグラフィクス・パイプラインを図２に示す。本発明の３Ｄディファード・シェーディング・グラフィクス・パイプライン、バージョン１（以後、ＤＳＧＰｖ１）の第１実施例を図４に比して説明する。図を見れば、本発明のパイプライン（図４）が、総称的従来型パイプライン（図２）を元に、作図示強関数２３１を、１）図中でシーン・メモリと呼ばれている、各プリミティブを記述するパイプライン状態及びプリミティブ・データを記憶するためのシーン・メモリ２５０と、２）正確な陰面除去プロセス２５１と、３）フラグメント・カラリング・プロセス２５２と、４）ブレンディング・プロセス２５３に入れ替えることにより得られることが分かる。
【００４８】  シーン・メモリ２５０は、フレームに対するプリミティブ・データをその属性と共に記憶し、フレーム全体を通してのパイプライン状態の様々なセッティングも記憶する。プリミティブ・データには、頂点座標、テクスチャ座標、頂点カラー、頂点法線等が含まれる。ＤＳＧＰｖ１では、プリミティブ・データには、空間、カラー及びエッジ導関数を含む増分レンダー用のセットアップによって生成されるデータも含まれている。
【００４９】  フレーム内の全てのプリミティブが、浮動小数点示強関数２１３により処理されシーン・メモリ２５０内に記憶されると、ＨＳＲプロセスが始まる。シーン・メモリ２５０は二重バッファすることができ、それにより、浮動小数点示強関数が次のフレームで計算を実行している間に、ＨＳＲプロセスがフレーム上で計算を実行できるようになる。シーン・メモリも、三重バッファすることができる。シーン・メモリは、ＨＳＲプロセスに対する中間結果を記憶し、全てのプリミティブがシーン・メモリ内に記憶される前にＨＳＲプロセスが開始できるようにする、ＨＳＲプロセスのためのスクラッチパッドであってもよい。
【００５０】  シーン・メモリでは、各プリミティブが、プリミティブがパイプラインに入力されたときに有効であったパイプライン状態情報と関係付けられる。パイプライン状態を各プリミティブと関係付ける最も簡単な方法は、各プリミティブ内の全パイプライン状態を含んでいることである。しかしこれは、パイプライン状態の多くが（特にプリミティブが同一オブジェクト内にある場合）大部分のプリミティブの間では変わらないので、非常に大量の冗長情報を導入することになる。情報をシーン・メモリ内に記憶する好適な方法は、別々のリストを保持し、１つのリストはパイプライン状態セッティング用、１つのリストはプリミティブ用とすることである。更に、パイプライン状態情報を多数のサブリストに分割し、各サブリストへの追加は、サブリストの一部が変わったときのみに生じるようにすることができる。プリミティブを記憶する好適な方法は、一連の頂点を、プリミティブを再製するために接続情報と共に記憶することである。この好適な方法は、多角形メッシュ及びライン・ストリップの場合に生じうる重複する頂点を省く。
【００５１】  ＤＳＧＰｖ１に関して記述されたＨＳＲプロセスは、陰面除去が行われるのがＤＳＧＰｖ１内の場所だけであるため、正確な陰面除去（ＥＨＳＲ）であることが要求される。正確な陰面除去（ＥＨＳＲ）プロセス２５１は、どのプリミティブがフレーム・バッファ内のピクセルの最終的カラーに影響を及ぼすかを正確に決める。このプロセスは、プロセスに様々な複雑性を導入する、パイプライン状態内の変化の原因である。この複雑性の大部分は、先に述べたようにフラグメント毎オペレーション（所有権テスト、シザー・テスト、アルファ・テスト等）によって生じる。これらの複雑性は、後に述べる、革新的な保存性陰面除去（ＣＨＳＲ）プロセスによって解消できるので、正確な陰面除去は必要ない。
【００５２】  フラグメント・カラリング・プロセスはピクセル内の各サンプル又はサンプルのグループに対しカラーを生成する。これは、ガウロード・シェーディング、テクスチャ・マッピング、フォング・シェーディング、及びピクセル・カラーを生成するための様々な他の技法を含んでいてもよい。このプロセスは、プリミティブのサブセクション用のカラーを効率的に生成できなければならないので、エッジ・ウォーク２３２及びスパン補間２３４とは異なる。即ち、プリミティブは部分的に可視でもよく、従ってカラーはそのピクセルの幾つかだけに対して生成される必要があり、エッジ・ウォーク及びスパン補間は全プリミティブが着色されなければならないと仮定している。更に、ＨＳＲプロセスは多数のプリミティブの可視サブセクションを生成し、これらを他のプリミティブの可視サブセクションの間に遅れずにばらまくことができる。従って、フラグメント・カラリング・プロセス２５２は、プリミティブ・エッジ又はｘ軸又はｙ軸に沿って増分計算する必要無しに、プリミティブ内の任意の位置におけるカラー値を生成できなければならない。
【００５３】  本発明の実施例のブレンディング・プロセス２５３は、フラグメント・カラーを互いに組み合わせ、ピクセル毎に単一のカラーを生成する。従来型のｚバッファド・ブレンド・プロセスとは対照的に、このブレンディング・プロセス２５３は、各サンプルにおいてどのプリミティブが可視であるかを、正確な陰面除去プロセス２５１が既に決めているので、ｚバッファ・オペレーションを含んでいない。ブレンディング・プロセス２５３は、各サンプル毎に別々のカラー値を保持してもよいし、サンプル・カラーを互いにブレンドして全ピクセルに対し単一のカラーを作ってもよい。別々のカラー値をサンプル毎に保持してフレーム・バッファ２４０内に別々に記憶する場合には、データがディジタル／アナログ変換器２４２に送られるスキャンアウト・プロセスの間に最終ピクセル・カラーがサンプル・カラーから作られる。
ディファード・シェーディング・グラフィクス・パイプライン、第２実施例（バージョン２）
ＤＳＧＰｖ１について先に述べたように、シーン・メモリ２５０は、１）プリミティブ・データと、２）パイプライン状態とを記憶する。図５に示すディファード・シェーディング・グラィクス・パイプラインの第２実施例２６０（バージョン２、ＤＥＧＰｖ２）では、このシーン・メモリ２５０が２つの部分、空間メモリ２６１部と多角形メモリ２６２部に分割されている。データは、単純にプリミティブデータとパイプライン状態データに分割されるわけではない。
【００５４】  ＤＳＧＰｖ２では、ＨＳＲに必要なパイプライン状態データが空間メモリ２６１に記憶され、残りが多角形メモリ２６２に記憶される。ＨＳＲに必要なパイプライン状態の例としては（例えばオープンＧＬ仕様書で説明したように）ＤｅｐｔｈＦｕｎｃ、ＤｅｐｔｈＭａｓｋ、ＳｔｅｎｃｉｌＥｎａｂｌｅ等が挙げられる。ＨＳＲに必要でないパイプライン状態の例としては、ＢｌｅｎｄＥｑｕａｔｉｏｎ、ＢｌｅｎｄＦｕｎｃ、スティプル・パターン等が挙げられる。特定のブレンディング関数の選択又は特定（例えば、選択Ｒ＝ＲｓＡｓ＋Ｒ０（１−Ａｓ））はＨＳＲには必要ではないが、ＨＳＲプロセスは、プリミティブが、一般的にはプリミティブが前のジオメトリを完全に遮ることはできないものとして取り扱われることを意味する、ブレンディングを受けるのかを明らかにしなければならない。同様に、ＨＳＲプロセスは、プリミティブがシザー・テスト、アルファ・テスト、カラー・テスト、ステンシル・テスト、及び他のフラグメント毎のオペレーションを受けるか否かを明らかにしなければならない。
【００５５】  プリミティブのデータも分割される。プリミティブのデータのＨＳＲに必要な部分は空間メモリ２６１に記憶され、残りは多角形メモリ２６２に記憶される。プリミティブのデータのＨＳＲに必要な部分には、頂点位置と空間導関数（即ちエッジに対するδｚ／δｘ、δｚ／δｙ、δｘ／δｙ等）が含まれる。プリミティブのデータのＨＳＲには必要でない部分には、頂点カラー、テクスチャ座標、カラー導関数等が含まれる。フラグメント毎ライティングがパイプラインで実行される場合には、全てのライティング方程式が各フラグメントに適用されることになる。しかしディファード・シェーディング・パイプラインでは、可視フラグメントだけがライティング計算を必要とする。この場合、多角形メモリは、頂点法線、頂点視点座標、頂点面正接、頂点従法線、これら属性全ての空間導関数、及びその他のプリミティブ毎ライティング情報を含んでいてもよい。
【００５６】  ＨＳＲプロセスの間にプリミティブの空間属性は繰り返しアクセスされるが、特にＨＳＲプロセスがタイル毎ベースで行われる場合にはそうである。シーン・メモリ２５０を空間メモリ２６１及び多角形メモリ２６２に分割すると、合計メモリ帯域幅を低減できるという利点がでてくる。
【００５７】  増分レンダー２３０に対するセットアップからのアウトプットは、空間データ分離プロセス２６３に入力され、そこでＨＳＲに必要な全てのデータは空間メモリ２６１に記憶され、残りのデータは多角形メモリ２６２に記憶される。ＥＨＳＲプロセス２６４はプリミティブの空間データ（例えば、頂点スクリーン座標、空間導関数等）及び（フラグメント毎テスティング・オペレーションに対する全制御ビットを含む）ＨＳＲに必要なパイプライン状態の部分を受信する。
【００５８】  ＥＨＳＲ２６４から可視フラグメントが出力されると、データ・マッチング・プロセス２６５は、頂点状態及びパイプライン状態を可視フラグメントに突き合わせ、タイル情報がバッファ２６６に記憶される。パイプラインの残りは本質的には、サンプルからピクセルへ又はピクセルからサンプルへの変換２６７、フレーム・バッファへの書き込み及びフレーム・バッファからの読み取り、ダブル・バッファドＭＵＸアウトプット・ルックアップ、及びフレーム・バッファに記憶されていたデータの実際のアナログ・ディスプレイ・デバイス信号値へのディジタル／アナログ（Ｄ／Ａ）変換を含む、スキャンアウト・プロセスと関係している。
ディファード・シェーディング・グラフィクス・パイプライン、第３実施例（バージョン３）
図６に示すディファード・シェーディング・グラフィクス・パイプラインの第３実施例（バージョン３、ＤＳＧＰｖ３）では、シーン・メモリ２５０が２つの部分（空間メモリ２６１及び多角形メモリ２６２）に分割され、更に、増分レンダー２３０に対するセットアップが、データ分離の後で且つ正確な陰面除去の前に起こる空間セットアップに置き換えられる。パイプライン構造及びプロセスの残りは、第１実施例に関して説明したものと同じである。
ディファード・シェーディング・グラフィクス・パイプライン、第４実施例（バージョン４）
図７に示すディファード・シェーディング・グラフィクス・パイプラインの第４実施例（バージョン４、ＤＳＧＰｖ４）では、第３実施例（図６）の正確な陰面除去が保存性陰面除去構造及びプロシジャに置き換えられ、下流のブレンディング・プロシジャがｚ−バッファド・ブレンドに置き換えられている。
ディファード・シェーディング・グラフィクス・パイプライン、第５実施例（バージョン５）
図８に示すディファード・シェーディング・グラフィクス・パイプラインの第５実施例（バージョン５、ＤＳＧＰｖ５）では、第３実施例（図６）と同じく正確な陰面除去が使われているが、タイリングが追加され、データ分離の後にタイル・ソーティング・プロシジャが追加され、空間セットアップの前にリーディング・バイ・タイルが追加されている。更に、最初の３つの実施例の多角形メモリが状態メモリに置き換えられている。
ディファード・シェーディング・グラフィクス・パイプライン、第６実施例（バージョン６）
図９に示すディファード・シェーディング・グラフィクス・パイプラインの第６実施例（バージョン６、ＤＳＧＰｖ６）では、第５実施例（図８）の正確な陰面除去が保存性陰面除去に置き換えられ、下流の第５実施例のブレンディングがｚバッファド・ブレンディング（テスティング＆ブレンディング）に置き換えられている。第６実施例は、２部分シーン・メモリ、プリミティブのデータの分割又は分離、空間セットアップ、タイリング及びタイル毎プロセッシング、保存性陰面除去、ｚバッファド・ブレンディング（テスティング＆ブレンディング）を含む、本発明の構造及び方法が提供する有益な特徴の幾つかを折り込んでいるので、好適である。
他の可能な実施例（バージョン）
本発明のグラフィクス・パイプライン幾つかの代表的実施例を、図４−９に関係付けて説明してきたが、当業者であれば、ここに示した説明に照らして、本発明の構造及びプロシジャを異なる組み合わせ及び順序で実行して別の実施例を作れること、及び本発明がここに取り上げて示す特定の組み合わせには限定されないことを容易に理解できるであろう。
重要な革新の概観
パイプラインはプリミティブをレンダーし、本発明は、１）三角形、２）ライン、３）ポイントを含むレンダー可能なプリミティブのセットに関連して説明される。３つ以上の頂点を有する多角形はジオメトリ・ブロック内で三角形に分割されるが、ＤＳＧＰパイプラインは容易に修正して、もっと多くの辺を有する四辺形又は多角形をレンダーできるようにすることができる。従って、パイプラインはどのような多角形でも、それが三角形に分割されればレンダーすることができるので、本発明のレンダラーはどのような多角形プリミティブでも効率的にレンダーすることができる。
【００５９】  ディスプレイ・スクリーン上の３Ｄウィンドウのどの部分に所与のプリミティブが影響を与えるかを識別するために、パイプラインは作図されている３Ｄウィンドウを、タイル及びスタンプと呼ばれる一連の小さな領域に分割する。パイプラインはディファード・シェーディングを実行し、そこではピクセル・カラーは陰面除去後まで決められない。マグニチュード・コンパリソン・コンテンツ・アドレス可能メモリ（ＭＣＣＡＭ）を使えば、パイプラインは隠されたジオメトリの選別除去を効率よく行うことができる。
保存性ディファード・シェーディング
本発明の提供する中心的アイディア又は発明的コンセプトの１つは、保存性陰面除去（ＣＨＳＲ）に関係がある。ＣＨＳＲは各プリミティブを時間順に、そして、プリミティブがタッチする各サンプル毎に、デプス・テスト及びアルファ・テスト等で、種々のＡＰＩ状態変数に基づいて保存性の決定を行う。ＣＨＳＲプロセスの重要な特徴の１つは、アルファ・テスト、カラー・テスト、ステンシル・テストのようなＡＰＩからの非デプス依存テストがＤＳＧＰパイプラインで実行可能であっても、陰面除去の間は、カラー計算を行う必要がないことである。ＣＨＳＲプロセスは、サンプル毎の有限状態マシン（ＦＳＭ）と考えることができる。以後、各サンプル毎ＦＭＳをサンプル有限状態マシン（ＳＦＭＳ）と呼ぶ。各ＳＦＳＭは、１）ｚ軸情報、２）プリミティブの情報（そのサンプルまたはピクセルにおけるプリミティブのカラーを生成するのに必要なあらゆる情報）、３）１つ又はそれ以上のサンプル状態ビット（例えば、これらのビットは、正確であるとして、又は保存性として単数又は複数のｚ値を指示することができる）を含むサンプル毎データを保持している。サンプル毎に多数のｚ値を簡単に使用することはできるが、サンプル毎の多数のプリミティブの情報のセットは費用がかさむ。以後、ＳＦＳＭは１つのプリミティブに対しプリミティブの情報を保持するものと仮定する。ＳＦＳＭは、次節で述べる、ソート済み透明性に対して使用される透明性情報も保持する。
ＣＨＳＲ及びアルファ・テスト
アルファ・テストを扱うＣＨＳＲプロセスの例として、図１０−１４、特に図１１の線図を考えよう。この線図は、特定のサンプルに対する異なるｚ座標位置における６つのプリミティブ（プリミティブＡ、Ｂ、Ｃ、Ｄ，Ｅ、Ｆ）を（「デプス・クリア」及び未満にセットされた「デプス・テスト」から始めて）以下の順序、即ち、プリミティブＡ、Ｂ、Ｃ（アルファ・テスト使用禁止で）、プリミティブＤ（アルファ・テスト使用可能で）、プリミティブＥ、Ｆ（アルファ・テスト使用禁止で）の順でレンダーしたレンダリングを示している。この図から、ＺＡ＞ＺＢ＞ＺＣ＞ＺＤ＞ＺＥ＞ＺＦ、即ちプリミティブＡが最大のｚ座標位置にあることが分かる。又、我々は、アルファ・テストはプリミティブＤに対しては使用可能だが、他の各プリミティブには使用禁止であることも言及しておく。
【００６０】  ＣＨＳＲに関する先の説明を思い出せば、ＣＨＳＲプロセスはサンプル有限状態マシン（ＳＦＳＭ）と考えることができる。アルファ・テスト付きの保存性陰面除去プロセスの下でこれら６つのプリミティブをレンダリングするためのステップは以下の通りである。
【００６１】  ステップ１：デプス・クリアは各サンプル有限状態マシン（ＳＦＳＭ）で以下の結果を引き起こす、即ち、１）ｚ値が最大値に初期化され、２）プリミティブの情報がクリアされ、３）サンプル状態ビットはｚ値が正確であると表示するようにセットされる。
【００６２】  ステップ２：プリミティブＡがＳＦＳＭで処理されると、このプリミティブが保持（即ち、これが可視面に対する現在の最良の推測となる）され、その結果ＳＦＳＭは、１）ｚ値ｚＡを「近い」ｚ値として、２）プリミティブＡにカラー付けするプリミティブの情報が必要で、３）ｚ値（ｚＡ）は正確とラベル付けされる、と記憶することになる。
【００６３】  ステップ３：プリミティブＢがＳＦＳＭで処理されると、このプリミティブが（ｚ値がプリミティブＡのｚ値未満であるので）保持され、その結果、ＳＦＳＭは、１）ｚ値ｚＢ「近い」ｚ値（ｚＡは捨てられる）として、２）プリミティブＢにカラー付けするプリミティブの情報が必要（プリミティブＡに関する情報は捨てられる）で、３）ｚ値（ｚＢ）は正確とラベル付けされる、と記憶することになる。
【００６４】  ステップ４：プリミティブＣがＳＦＳＭで処理されると、このプリミティブは（可視面に対する現在の最良の推測であるプリミティブＢに覆われているので）捨てられ、ＳＦＳＭデータは変更されない。
【００６５】  ステップ５：プリミティブＤ（これにはアルファ・テストが使用可能である）がＳＦＳＭで処理されるとき、プリミティブＢより近く、且つＳＦＳＭ作動時にはそのアルファ値が未知なので、このプリミティブの視認性を決めることはできない。どちらのプリミティブ（プリミティブＢ又はプリミティブＤ）が最終的に見えるのか決めることができないので、プリミティブＢは（そのカラーを生成するため）パイプラインに送り出され、プリミティブＤが保持される。以後これをプリミティブＢの「早期ディスパッチ」と呼ぶ。プリミティブＤの処理が完了すると、ＳＦＳＭは、１）「近い」ｚ値はｚＤで、「遠い」ｚ値はｚＢであり、２）プリミティブＤにカラー付けするプリミティブの情報が必要（プリミティブＢの情報は早期ディスパッチ下にある）で、３）ｚ値は（近い、遠いの両方が保持されているので）中庸とラベル付けされる、と記憶する。この状態で、ＳＦＳＭは、ｚＤより近いジオメトリはこのジオメトリを覆い、ｚＢより遠いジオメトリは覆われ、ｚＤとｚＢの間のジオメトリは不確定で（中庸の仮定が行われるので）可視と仮定されねばならない、と決定することができる。ＳＦＳＭが中庸状態にあり、有効なプリミティブの情報を含んでいる場合、ＳＦＳＭ法は、記憶されたプリミティブの情報を近いデプス値と考える。
【００６６】  ステップ６：プリミティブＥ（これにはアルファ・テストが使用禁止である）がＳＦＳＭで処理されるとき、近いｚ値と遠いｚ値の間（ｚＤとｚＢの間）にあるので、このプリミティブの視認性を決めることはできない。しかし、プリミティブＥは、この時点でパイプラインに送り込めば、このプリミティブが正しい時間順を外れてｚバッファド・ブレンド（後に、好適な実施例中でピクセル・ブロックの１部として説明する）に至る恐れがあるので、パイプラインには送り込まれない。従って、プリミティブＤが、時間順を維持するためにパイプラインに送り込まれる。プリミティブＥの処理が完了すると、ＦＳＦＭは、１）「近い」ｚ値はｚＤで、「遠い」ｚ値はｚＢ（これは変更されず、ＺＥは保持されないことに注意）であり、２）プリミティブＥにカラー付けするプリミティブの情報が必要（プリミティブＤの情報は早期ディスパッチ下にある）で、３）ｚ値は（近い、遠いの両方が保持されているので）中庸とラベル付けされる、と記憶する。
【００６７】  ステップ７：プリミティブＦがＳＦＳＭで処理されると、このプリミティブが（ｚ値が近いｚ値未満なので）保持され、その結果ＳＦＳＭは、１）ｚ値ｚＦを「近い」ｚ値（ｚＤとｚＢは捨てられる）として、２）プリミティブＦにカラー付けするプリミティブの情報が必要（プリミティブＥに関する情報は捨てられる）で、３）ｚ値（ｚＦ）は正確とラベル付けされる、と記憶することになる。
【００６８】  ステップ８：タイルにタッチする全てのジオメトリを処理し終わる（又は、タイルがない場合には、フレーム内のジオメトリが全て処理される）と、あらゆる有効なプリミティブの情報がパイプラインに送り込まれる。この場合、プリミティブＦの情報が送られる。これはエンドオブタイル（又はエンドオブフレーム）ディスパッチであり、早期ディスパッチではない。
【００６９】  この代表的ＣＨＳＲプロセスを纏めると、プリミティブＡからＦまでが処理され、プリミティブＢ、Ｄ、Ｆがパイプラインに送り込まれた。Ｂ、Ｄ、Ｆの視認性を解明するために、ｚバッファド・ブレンド（好適な実施例の中のピクセル・ブロックにある）がパイプラインの終わり近くに含まれている。この例では、カラー・プリミティブＦだけがサンプルのために使用される。
ＣＨＳＲ及びステンシル・テスト
ＣＨＳＲプロセスの好適な実施例では、全てのステンシル・オペレーションがパイプラインの終わり近く（好適な実施例ではピクセル・ブロックと呼ばれる、ｚバッファド・ブレンド内）で行われ、従って、ステンシル値は、フレーム・バッファ内に保持されているため、ＣＨＳＲ法（好適な実施例のカル・ブロックで起こる）には利用できない。ステンシル値をＣＨＳＲプロセスで使用するためにフレーム・バッファから送ることはできるが、これは一般的には、性能を落とすことになる長い待ち時間パスを必要とする。オープンＧＬのようなＡＰＩではステンシル・テストはアルファ・テストの後に行われ、アルファ・テストの結果はＣＨＳＲプロセスには知らされず、これはステンシル・テストへのインプットが正確にモデル化できないことを意味するので、ステンシル値はＣＨＳＲプロセス内では正確に保持できない。更に、レンダラーは（普通は各フレームの開始時にクリアされるデプス値とは反対に）ステンシル値を多くのフレームに亘って保持し、これらのステンシル値はフレーム・バッファ内に記憶される。正にこのために、ＣＨＳＲプロセスは、ステンシル・オペレーションの取り扱いに保存性アプローチを利用する。プリミティブがフレーム・バッファ内のステンシル値に影響を及ぼすことができる場合、ステンシル・オペレーションはデプス・テストの前に起こる（オープンＧＬ仕様書参照）ので、プリミティブは常にパイプラインに送り込まれる（以後、これを「ＣｕｌｌＦｌｕｓｈＯｖｅｒｌａｐ」と呼び、カル・ブロック内の信号ＣｕｌｌＦｌｕｓｈＯｖｅｒｌａｐの主張によって表示される）。ＣｕｌｌＦｌｕｓｈＯｖｅｒｌａｐ状態はＳＦＳＭをその最も中庸な状態にセットする。
【００７０】  別の可能性としては、ステンシル基準値（オープンＧＬ仕様書参照）が変更され、ステンシル・テストが使用可能となり、フレーム・バッファ内のステンシル値に基づいてサンプル値を捨てるように構成される場合、ＳＦＳＭ内の全ての有効なプリミティブの情報がパイプラインに送り込まれ（以後、これを「ＣｕｌｌＦｌｕｓｈＡｌｌ」と呼び、カル・ブロック内の信号ＣｕｌｌＦｌｕｓｈＡｌｌによって表示される）ｚ値がその最大値にセットされる。ステンシル基準値を変えれば、ｚバッファド・ブレンド（又はピクセル・ブロック）の「視認性規則」を効率的に変えることになるので、この「フラッシング」は必要である。
【００７１】  ステンシル・テスト（オープンＧＬ仕様書参照）を取り扱うＣＨＳＲプロセスの例として、４つの特定のサンプル（対応するＳＦＳＭで、ＳＦＳＭ０からＳＦＳＭ３とラベル付けされる）をカバーする２つのプリミティブ（プリミティブＡ及びＣ）と、この４つのサンプルの内２つをカバーする追加のプリミティブ（プリミティブＢ）とを有する図１２の線図を考えよう。３つのプリミティブが（デプス・クリア及び未満にセットされたデプス・テストから始めて）以下の順序、即ち、プリミティブＡ（ステンシル・テスト使用可能）、プリミティブＢ（ステンシル・テスト使用可能、ＳｔｅｎｃｉｌＯｐは「ＲＥＰＬＡＣＥ」にセット、オープンＧＬ仕様書参照）、プリミティブＣ（ステンシル・テスト使用禁止）の順でレンダーされる。テストは以下のように行われる。
【００７２】  ステップ１：デプス・クリアは、この例の４つのＳＦＳＭの各々において、以下の結果を引き起こす。即ち、１）ｚ値が最大値に初期化され、２）プリミティブの情報がクリアされ、３）サンプル状態ビットはｚ値が正確であると表示するようにセットされる。
【００７３】  ステップ２：プリミティブＡが各ＳＦＳＭで処理されると、このプリミティブが保持（即ち、これが可視面に対する現在の最良の推測となる）され、その結果４つのＳＦＳＭは、１）その対応するｚ値（それぞれｚＡ０、ｚＡ１、ｚＡ２、ｚＡ３の何れか）を「近い」ｚ値として、２）プリミティブＡにカラー付けするプリミティブの情報が必要で、３）各ＳＦＳＭのｚ値は正確とラベル付けされる、と記憶することになる。
【００７４】  ステップ３：プリミティブＢがＳＦＳＭで処理されるときには、サンプル１及び２だけが影響を及ぼし、ＳＦＳＭ０及びＳＦＳＭ３には影響が無く、その結果ＳＦＳＭ１及びＳＦＳＭ２が以下のように更新される。即ち、１）遠いｚ値が最大値にセットされ、近いｚ値が最小値にセットされ、２）プリミティブＡ及びＢに対するプリミティブの情報がパイプラインに送り込まれ、３）サンプル状態ビットはｚ値が中庸であると表示するようにセットされる。
【００７５】  ステップ４：プリミティブＣが各ＳＦＳＭで処理されると、このプリミティブが保持されるが、ＳＦＳＭはプリミティブを全て同じ方法で扱うわけではない。ＳＦＳＭ０及びＳＦＳＭ３では、状態は、１）ｚＣ０及びｚＣ３は「近い」ｚ値となり（ｚＡ０及びｚＡ３は捨てられ）、２）プリミティブＣにカラー付けするプリミティブの情報が必要（プリミティブＡに関する情報は捨てられる）で、３）ｚ値は正確とラベル付けされる、と更新される。ＳＦＳＭ１及びＳＦＳＭ２では、状態は、１）ｚＣ１及びｚＣ２は「遠い」ｚ値となり（近いｚ値が保持され）、２）プリミティブＣにカラー付けするプリミティブの情報が必要で、３）ｚ値は中庸とラベル付けされたまま留まる、と更新される。
【００７６】  このＣＨＳＲプロセスの例を纏めると、プリミティブＡ及びＣが処理され、全てのプリミティブがパイプラインに送り込まれたが、全てのサンプルにおいてではない。視認性を解明するために、ｚバッファド・ブレンド（好適な実施例の中のピクセル・ブロックにある）がパイプラインの終わり近くに含まれている。ＣｕｌｌＦｌｕｓｈＯｖｅｒｌａｐが選択されたサンプルを、他には影響を与えずに「フラッシュ」するのを示すために、この例には多くのサンプルが示されている。
ＣＨＳＲ及びアルファ・ブレンディング
アルファ・ブレンディングは２つのプリミティブのカラーを組み合わせて１つのカラーにするのに使われる。しかし、プリミティブはなお、ｚ値の更新のためデプス・テストに掛けられる。
【００７７】  アルファ・ブレンディングを取り扱うＣＨＳＲプロセスの１例として、（デプス・クリア及び未満にセットされたデプス・テストから始めて）以下の順序、即ち、プリミティブＡ（アルファ・ブレンディング使用可能）、プリミティブＢ及びＣ（アルファ・ブレンディング使用禁止）、プリミティブＤ（アルファ・ブレンディング使用禁止）の順にレンダーされる、特定のサンプルに対する４つのプリミティブ（プリミティブＡ、Ｂ、Ｃ、Ｄ）を有する図１３を考えよう。
【００７８】  ステップ１：デプス・クリアは各ＣＨＳＲ  ＳＭＳＦに以下の結果を引き起こす。即ち、１）ｚ値が最大値に初期化され、２）プリミティブの情報がクリアされ、３）サンプル状態ビットはｚ値が正確と表示するようにセットされる。
【００７９】  ステップ２：プリミティブＡがＳＦＳＭで処理されると、このプリミティブが保持（即ち、これが可視面に対する現在の最良の推測となる）され、その結果ＳＦＳＭは、１）ｚ値ｚＡを「近い」ｚ値として、２）プリミティブＡにカラー付けするプリミティブの情報が必要で、３）ｚ値は正確とラベル付けされる、と記憶することになる。
【００８０】  ステップ３：プリミティブＢがＳＦＳＭで処理されると、このプリミティブが（ｚ値がプリミティブＡのｚ値未満であるので）保持され、その結果、ＳＦＳＭは、１）ｚ値ｚＢを「近い」ｚ値（ｚＡは捨てられる）として、２）プリミティブＢにカラー付けするプリミティブの情報が必要（プリミティブＡに関する情報は捨てられる）で、３）ｚ値（ｚＢ）は正確とラベル付けされる、と記憶することになる。レンダリングプロセスのこの時点で、プリミティブＢのカラーはプリミティブＡとブレンドされることになるので、プリミティブＡはパイプラインに送り込まれる。これは、プリミティブの、パイプラインに送り込まれる際の時間順序を維持することになる。
【００８１】  ステップ４：プリミティブＣがＳＦＳＭで処理されると、このプリミティブは（可視面に対する現在の最良の推測であるプリミティブＢに覆い隠されるので）捨てられ、ＳＦＳＭデータは変更されない。但し、プリミティブＢ及びＣが透明な面としてレンダーされる必要がある場合には、プリミティブＣはプリミティブＢに隠されるべきではない。その場合には、プリミティブＢがレンダーされている間にデプス・マスクがオフにされるが、透明ブレンディングは正しく、面はフロントツーバック又はバックツーフロントの何れかの順でブレンドされなければならない。
【００８２】  デプス・マスク（オープンＧＬ仕様書参照）が使用禁止の場合、デプス・バッファへの書き込み（即ちｚ値のセービング）は行われないが、デプス・テストは行われる。この例では、デプス・マスクがプリミティブＢに使用禁止の場合、ｚＢはＳＦＳＭにセーブされない。その結果、プリミティブＣは、そのｚ値がｚＡと比較されることになるので、可視であると見なされる。
【００８３】  このＣＨＳＲプロセスの例を纏めると、プリミティブＡからＤが処理され、全てのプリミティブがパイプラインに送り込まれたが、全てのサンプルにおいてではない。視認性を解明するために、ｚバッファド・ブレンド（好適な実施例の中のピクセル・ブロックにある）がパイプラインの終わり近くに含まれている。ＣｕｌｌＦｌｕｓｈＯｖｅｒｌａｐが選択されたサンプルを、他には影響を与えずに「フラッシュ」するのを示すために、この例には多くのサンプルが示されている。
ＣＨＳＲ及び超過デプス・テスト
保存性陰面除去プロシジャを実行すれば、有益にも、オープンＧＬのような他の標準的ＡＰＩとの互換性を維持できる。多くのＡＰＩの複雑性の１つは、そのデプス・テストを変更する能力であることを思い出そう。３Ｄレンダリングを考える標準的方法では、可視オブジェクトは覆い隠されたオブジェクトよりも近い（即ち、ｚ値が小さい）と想定されており、これは「未満」デプス・テスト（即ち、ｚ値が他のジオメトリ「未満」であればそのオブジェクトは可視）を選択して実行される。しかし、大抵のＡＰＩは、超過、未満、以上、同等、以下、未満、非同等などの代数的、量的及び論理的関係のような、フレーム内で変えることのできる、他のデプス・テストをサポートしていることも思い出そう。これが本質的に、何が可視であるかに関しダイナミックに「規則を変え」その結果、異なったレンダリング規則によるプリミティブの時間順を考慮しなければならなくなる。
【００８４】  本発明による保存性陰面除去の場合は有益にも「超過」デプス・テストが使われているときには他のＡＰＩとの互換性を維持するために、異なる又は追加のプロシジャが以下の理由のため実行される。当業者であれば、デプス・テストが、以上又は、そうでなければ記述された例外の結果となる他の関数関係である場合、類似の変更が有利に採用できることを理解できるであろう。
【００８５】  我々は更に、従来型の非ディファード・シェーダーでは、全てのジオメトリ項目に対し規則のシーケンスを実行し、次に最終レンダー結果を眺めてみることを知っている。比較すれば、本発明のディファード・シェーダーの実施例では従来型のパラダイムは破られている。本発明の構造及び方法は、ジオメトリの各ピース内の各ピクセルに対する全てのカラーを製作又は生成する必要無しに、フレーム・バッファ内の最終の値にどのジオメトリが実際に影響を及ぼすかを予想又は予報する。原則として、ジオメトリの空間位置を調べ、どんな特定のサンプルに対してもｚバッファ内の最終的カラーに影響を及ぼすジオメトリ項目を決定し、次にそのカラーだけが生成される。
ＣＨＳＲプロセスに対する追加の考察
サンプルは並行して処理され、概ね、スタンプ内の全てのピクセルの全てのサンプルが並行して処理される。クロック・サイクル毎に１つのスタンプを処理でき（且つ、スタンプ毎に４ピクセル、ピクセル毎に４サンプルが有る）場合、１６サンプルがクロック・サイクル毎に処理されることになる。この「スタンプ」は、１度に処理されるピクセル及びサンプルの数を規定する。このスタンプ毎プロセッシングは、一般的に、スタンプが（先のプリミティブからの）同じスタンプが完了する前に再度処理されねばならない場合（即ち、順序外のスタンプ・プロセッシングが行えない場合）には、パイプライン・ストールが注入され、パイプライン化される。
【００８６】  早期ディスパッチが必要でない場合、エンドオブタイル・ディスパッチだけが必要となる。これは、タイル内の全ジオメトリが不透明で、ステンシル・テスト又はオペレーションが無く、可視のアルファ・テスト済みのプリミティブもない場合である。
【００８７】  各ＳＦＳＭ内のプリミティブの情報は、全てのプリミティブの情報が記憶されているメモリ内へのポインタで置き換えることができる。好適な実施例で後に述べるように、多角形メモリ内のプリミティブの情報を指すために、カラー・ポインタが使われる。
【００８８】  代わりに、遠いｚ値だけを保持し（近いｚ値は保持せず）に、それによってデータ記憶装置を削減し、しかし、サンプル状態ビットにプリミティブＦ後に「中庸」に留まるよう要求し、プリミティブＥがプリミティブＦの前か後かが分かっていないのでプリミティブＥをパイプラインに送り込ませるようにすることもできる。
【００８９】  近いｚ値及び遠いｚ値の両方を保持する代わりに、遠いｚ値だけを保持し、それによってデータ記憶装置を削減し、しかし、サンプル状態ビットに、それが「正確」とラベル付けできるようになった後でも、「中庸」に留まるよう要求し、追加のサンプルをパイプラインにディスパッチさせるようにすることもできる。上記（アルファ・テストを含んでいる）最初のＣＨＳＲの例では、サンプル状態ビットはプリミティブＦの後「中庸」に留まり、近いｚ値の欠如の故にプリミティブＥがプリミティブＦの前か後かが分からないため、プリミティブＥがパイプラインに送り込まれることになっている。
【００９０】  スタンプを処理するのは、単にＳＦＳＭがスタンプ毎ベースで並行的に作動できるようにするのよりも遙かに効率的である。スタンプは、パイプラインに送り込まれるデータ・パケットの数を低減するのにも使われる。即ち、スタンプ内の１つのサンプルが（早期ディスパッチ又はエンドオブタイル・ディスパッチの何れかで）ディスパッチされるときには、同じスタンプ及び同じプリミティブ内の他のサンプルもディスパッチ（このようなジョイント・ディスパッチを以後、可視スタンプ部、又はＶＳＰと呼ぶ）される。上記（ステンシル・テストを含んでいる）第２のＣＨＳＲの例では、４つのサンプル全てが同じスタンプ内にある場合、サンプル１及び２の早期ディスパッチがサンプル０及び３の早期ディスパッチを引き起こすこととなる。これはより多くのサンプルをパイプラインに送り込み、カラー計算の量を増加させることになるように見えるが、これが（一般的には）カラー計算の正味の増加を引き起こすことはなく、むしろ低減する。これはピクセル内の空間コヒーレンス（即ち、同一ピクセル内のサンプルは共に可視であるか共に隠されているかの何れかである傾向にある）及び、アルファ・テスト、カラー・テスト、ステンシル・テスト、及び／又はアルファ・ブレンディングによる多角形のエッジに対する傾向が、そうでなければ空間的にコヒーレントなスタンプを分割する可能性があることによる。即ち、追加のサンプルを、それが計算負荷を容易に分かるほどには増やしていないときに、パイプラインに送り込むのは、送る必要のあるＶＳＰの合計数を低減することによる相殺以上である。上記第２のＣＨＳＲの例では、全てのサンプルが同一のスタンプ内にある場合、同じ数のＶＳＰが生成されることになる。
【００９１】  アルファ・テストの場合、プリミティブに対するアルファ値が（テクスチャリングのような他の場所からではなく）頂点におけるアルファ値からだけ生じるのであれば、全プリミティブに対し簡素化したアルファ・テストを行うことができる。即ち、頂点プロセッシング・ブロック（後の節でＧＥＯと呼ばれる）は、何時、頂点アルファ値の何れの補間でも、アルファ・テストを通るように保証されるか、そしてそのプリミティブに対しアルファ・テストが何時使用禁止になるかを決めることができる。これは、ＣＨＳＲが実行される前にアルファ値を決めることができなければ行えない。
【００９２】  フレームがデプス・クリアで始まらなければ、ＳＦＳＭはその最も中庸な値に（近いｚ値を最小値、遠いｚ値を最大に）セットされる。
【００９３】  好適な実施例では、ＣＨＳＲプロセスはカル・ブロックで実行される。
パイプライン状態情報を含む、タイルによるハードウェア・ソーティング
本発明の構造及び方法において、我々は、パイプライン状態情報の時間順序を保存することを含め、時間順序が各タイル内に保存されることに言及しておく。クリア・パケットも使用される。本発明の実施例では、ソーティングはハードウェアで実行され、ＲＡＭＢＵＳメモリが有利なことに１つの頂点のデュアルオクト記憶を許可している。ソート済み透明モジュールに対して、保証された不透明なジオメトリ（即ち、より遠くのジオメトリを覆い隠すことが知られているジオメトリ）が第１パスでソート・メモリから読み出される。次のパスで、ジオメトリの残りが各後続のパスで一度読み取られる。好適な実施例では、タイル・ソーティング法はソート・ブロックで実行される。
【００９４】  全ての頂点及び関連モード・パケット又は状態情報パケットが、時間順線形リストとして記憶される。プリミティブがタッチする各タイル毎に、ポインタが、プリミティブを完成するその線形リスト内の頂点に追加される。例えば、三角形プリミティブは３つの頂点で定義され、三角形プリミティブを完成するために、ポインタが線形リスト内の（３番目の）頂点に追加されることになる。第３頂点ではなく第１頂点を使用する他のスキームを代わりに実行してもよい。
【００９５】  要するに、ポインタは、プリミティブ内の頂点の１つを指すために、プリミティブ内の他の頂点を見つけだすのに適当な情報付きで用いられる。これらのプリミティブを読み出すときになると、完全なプリミティブを頂点及びポインタから再構築することができる。各タイルはポインタのリストであり、ポインタが頂点を指し、リストからプリミティブを再製できるようになっている。このアプローチを使えば、他のプリミティブと頂点を共有するプリミティブでも、全てのプリミティブが記憶できるが、但し各頂点を一度記憶するだけである。
【００９６】  本発明のプロシジャのある実施例ではタイル毎に１つのリストが保持される。我々はプリミティブをリスト内に記憶しないが、代わりにリストがプリミティブに対するポインタを記憶している。これらのポインタは実際にプリミティブの１つを指し、ポインタはプリミティブの頂点の１つに入っているが、同じプリミティブの他の頂点を見つけだすのに適当な情報も含んでいる。このソーティング構造は有利なことに、データ記憶装置、タイル・ポインタ記憶装置、モード・ポインタ記憶装置の３つの記憶装置構造を備えた構造を使って、ハードウェア内で実行される。所与のタイルに対し、目標は、処理されている特定のタイルにタッチしているプリミティブの時間順シーケンスを再製し、タイルにタッチしていないプリミティブは無視することである。我々は初期にモードを抽出し、それを別々に記憶しており、今我々はモード・パケットをこのプリミティブのストリームの適所に注入したいのである。我々は更に、モード・パケットはプリミティブを処理するのに必要であり、それは１タイルでは済まないので、単にモード・パケットをあるステージ手抽出し、次にそれを別のステージで注入するのでは十分でないことに言及しておく。従って、モード・パケットは適当な時間に全ての関連するタイルと再関連付けされねばならない。
【００９７】  １つの単純なアプローチは、モード・パケットに対するポインタを各タイル・リストに書き込むことである。後でこのリストを読む間に、モード・パケットのアドレスにアクセスし適切なモード・データを読み取るのは容易である。しかしこのアプローチは、ポインタを全てのタイルに書き込むのにコストが掛かるため不利である。本発明のプロシジャでは、各タイルを処理する間に、我々は適当なタイル・ポインタ・リストからエントリを読み取り、我々が既にその頂点に対するモード・データを読み取っ（フェッチし）て送っておれば、我々は単に頂点をデータ記憶装置で検索しそれをパイプラインに送り込むだけであるが、モード・データが検索された最後の頂点とタイル・ポインタ・リスト内の次に続く頂点との間で変えられている場合には、頂点が到着したときに適切なモード・データが利用できるように、モードデータがデータ記憶装置からフェッチされ、次の頂点が送られる前にパイプラインに送り込まれる。我々は、モード・ポインタ・リスト内のエントリが、どの頂点でモードが替わっているかを特定することを指摘しておく。ある実施例では、モード・ポインタ内のエントリは、モード・データが関係する最初の頂点を記憶するが、別の手順では、モード・データが適用される最後の頂点を記憶するようになっており、これは一貫した規則に従っている限りどちらでもよい。
ＤＳＧＰオペレーションの２つのモード
ＤＳＧＰは、１）時間順モード、２）ソート済み透明モード、の２つの異なるモードで作動できる。時間順モードは上に説明した通りで、どんな特定のタイル内にでも、プリミティブの同じ時間順序を保存するように設計されている。ソート済み透明モードは直ぐ後に説明する。好適な実施例では、パイプライン作動モードの制御はソート・ブロックで行われる。
【００９８】  ソート・ブロックは、パイプライン内のモード抽出ユニット（ＭＥＸ）とセットアップ（ＳＴＰ）ユニットの間に配置されている。ソート・ブロックは基本的に、ディスプレイ・ウィンドウの周りに分散されているジオメトリを捕らえて作動し、それをタイル内にソートする。ソート・ブロックはソート・メモリの管理も行うが、ソート・メモリは全シーンからの全てのジオメトリをそれがラスタライズされる前に、幾つかのモード情報と共に記憶する。ソート・メモリは、頂点及びモードのダブル・バッファド・リストを備えている。あるページはシーンのジオメトリを（頂点毎、又はモード毎に）集め、他のページはそのジオメトリを（プリミティブ毎、及びモード毎に）パイプラインの残りに送り込んでいる。
【００９９】  ソート・メモリ内のページに書き込む際には、頂点とモードが、ソート・ブロックに受信されたときに、ソート・メモリ内に順次書き込まれる。ページがソート・メモリから読み取られるときには、読みとりは、タイル毎ベースに行われ、読み取りプロセスは、１）時間順モード、２）ソート済み透明モードの２つのモードで作動する。
時間順モード
時間順モードでは、頂点とモードの時間順は各タイル内に保存され、そこではタイルは、水平及び垂直に境界画定されたディスプレイ・ウィンドウの一部である。時間順保存は、所与のタイルに関し、頂点及びモードが書き込まれたのと同じ順で読み取られることを意味する。
ソート済み透明モード
ソート済み透明モードでは、各タイルの読み取りは多くのパスに分割され、そこでは、最初のパスで保証済みの不透明なジオメトリがソート・ブロックから出力され、次のパスでは透明の可能性のあるジオメトリがソート・ブロックから出力される。各ソート済み透明モード・パス内では、時間順が保存され、モード・データがその正しい時間順位置に挿入される。ソート済み透明モードは、バックツーフロント、フロントツーバックの何れの順で実行してもよい。好適な実施例では、ソート済み透明法は、ソート・ブロック及びカル・ブロック共同で行われる。
多段階陰面除去
通常、陰面は「正確な」陰面除去プロシジャか、ｚバッファかの何れかを使って除去される。本発明の構造及び方法のある実施例では、２段階のアプローチ、即ち１）先ず「保存性」陰面除去を行い、２）次にｚバッファ・ベースのプロシジャが行われる。別の実施例では、３段階のアプローチ、即ち、１）特定の空間カル・プロシジャ、２）保存性陰面除去、３）ｚバッファ、が行われる。保存性陰面除去（ＣＨＳＲ）の様々な実施例は、既に本明細書の別のところで説明済みである。
パイプライン状態保存及びキャッシング
各頂点はカラーポインタを含んでおり、頂点が受信される度に、カラー・ポインタを含む頂点がソート・メモリ・データ記憶装置に記憶される。このカラー・ポインタは、頂点データのカラー部分を含む多角形メモリ頂点記憶装置内の位置に対するポインタである。材料ライティング・モード（ＭＬＭ）ポインタのセットが、ストリップ又はファン何れかの全ての頂点に関係付けられている。ＭＬＭは、以下に説明するように、６つの主要ポインタと２つのその他のポインタを含んでいる。６つの主要ポインタのそれぞれは、多角形メモリ状態記憶装置に対するアドレスを備えており、この記憶装置は、例えばテクスチャ、ピクセル、ライティング等における変更のようなパイプライン内で変更された全ての状態の順次記憶装置なので、将来必要が生じたら何時でも、ＭＬＭポインタを探索し、多角形メモリ状態記憶装置に戻り、そのときに存在していた状態を見つけだすことによって、頂点に関係するＭＬＭポインタから、頂点をレンダーするのに必要な状態を再製できるようになっている。
【０１００】  モード抽出ブロック（ＭＥＸ）は、ジオメトリと、時間順状態変更データを集め、状態を多角形メモリに記憶し、適切なポインタをソート・メモリに送られてきた頂点のデータに取り付けるソートとの間にある論理ブロックである。通常のオープンＧＬパイプラインでは、そして本発明のソート・ブロックまでのパイプラインの実施例では、ジオメトリ及び状態のデータは、パイプラインに送り込まれた順で処理される。材料タイプ、ライティング、テクスチャ、モード、スティップルに関する状態変更はそれに続くプリミティブに影響を及ぼす。例えば、新しいオブジェクトそれぞれに先立って、そのオブジェクトに関する材料パラメータをセットするため、状態変更が起こっている。
【０１０１】  一方、本発明のパイプラインでは、フラグメントがカル・ブロックの後タイル順でパイプラインに送り込まれる。モード注入ブロックは、時間順の代わりに空間（タイル）順でデータを処理するパイプラインの部分に如何に状態を保存するかを計算する。ジオメトリ・データに加えて、モード抽出ブロックはモード・データ（ｃｕｌｌ＿ｍｏｄｅ）のサブセットをカルが使うようにパイプラインに送り込む。モード抽出ブロックは、適切なカラー・ポインタをジオメトリ・パケットに挿入する。
【０１０２】  パイプライン状態は、記憶装置を最小化するため以下のように幾つかのカテゴリに細分化される。即ち、１）空間パイプライン状態は、全ての頂点を変更するソートに向けられたデータを含み、２）Ｃｕｌｌ＿ｍｏｄｅ状態は、まれにしか変わらないカルへ（ソート経由で）向けられたデータを含み、３）カラーは、全ての頂点を変更する多角形メモリに向けられたデータを含み、４）材料は、オブジェクト毎に変わるデータを含み、５）テクスチャＡは、テクスチャ０＆１用のテクスチャ・ブロックに対する状態の第１セットを含み、６）テクスチャＢはテクスチャ２から７用のテクスチャ・ブロックに対する状態の第２セットを含み、７）モードは、殆ど変わることのないデータを含み、８）ライトはフォング用のデータを含み、９）スティップルは多角形スティップル・パターン用のデータを含んでいる。材料、テクスチャ、モード、ライト、スティップルのデータは、集合的に（材料、ライト及びモード用）ＭＬＭデータと称される。我々は特に、状態保存用のＭＬＭポインタに関心がある。
【０１０３】  状態変更情報は、プリミティブ（空間及びカラー・パケット）が現れるまで、ＭＥＸに蓄積される。そのとき、最後のプリミティブ以降変更されたＭＬＭデータは全て多角形メモリに書き込まれる。カラー・データも、ＭＬＭに対する適切なポインタと共に、多角形メモリに書き込まれる。空間データは、多角形メモリへのポインタ（カラー・ポインタ）と共にソートに送られる。カラー及びＭＬＭデータは全て多角形メモリに記憶される。これらの記録に対する空間の割当は、性能を改善するため、マイクロアーキテクチャ定義で最適化される。
【０１０４】  これら記録の全てには、ポインタ経由でアクセスされる。ソート・メモリ内の各プリミティブのエントリは、多角形メモリ内の対応するカラー・エントリに対するカラーポインタを含んでいる。カラー・ポインタは、カラー・アドレスと、カラー・オフセットと、我々がポイント、ライン又は三角形を構築し、ＭＬＭポインタを配置できるようにするカラー・タイプとを含んでいる。カラー・アドレスはプリミティブ内の最終頂点を指す。頂点は順次、三角形ファンの場合を除いて、プリミティブ内の頂点が隣接するように記憶される。カラーオフセットは、カラー・アドレスから、この頂点リストに対する第１のデュアルオクトへ指し返す。（我々は、ポイント・リスト、ライン・ストリップ、三角形ストリップ、又は三角形ファンを頂点リストと呼ぶ）。この第１デュアルオクトは、頂点リスト内のポイント、ライン、ストリップ又はファンに対するＭＬＭデータへのポインタを含んでいる。頂点リスト内の次のデュアルオクトは、カラー・データ・エントリを含んでいる。三角形ファンに関し、三角形に対する３つの頂点はカラー・アドレス（カラー・アドレス−１）及び（カラー・アドレス−カラー・オフセット＋１）にある。但し、これはポインタがソート・メモリに記憶されるのと全く同じやり方ではない。
【０１０５】  状態は時間の変化するエンティティであり、ＭＥＸは状態内の変化を蓄積するので、状態はどのような頂点又は頂点のセットに対しても再製できる。ＭＩＪブロックには状態を頂点ダウン・ストリームと合わせる責任がある。頂点がＭＥＸに来て、あるインジケータ・ビットがセットされれば何時でも、パイプライン状態情報のサブセットがセーブされる必要がある。完全な状態は状態に対する累積変化から再製できるので、状態全部ではなく、変化した状態だけが記憶される。材料、テクスチャＡ、テクスチャＢ、モード、ライト、スティップルに対する６つのＭＬＭポインタは、各状態情報に関する最新の変化が記憶されているアドレス位置を特定する。これらの状態の１つにおける各変化は、メモリに記憶されている連続的に順序づけられた状態記憶リストの終わりで追加のエントリによって特定される。効果的にも、全ての状態変化が記憶され、時間内の点（又は頂点の受取）に対応する特定の状態が必要なときには、状態はポインタから再構築される。
【０１０６】  セーブされているこのモードのパケットは、モード・パケット呼ばれるが、このフレーズは、記憶されているモード・データの変化を指すのにも、そして、レンダリング前にＭＩＪによって検索又は再構築されるモード・データの大きいセットを指すのにも使われる。
【０１０７】  我々は特に、状態全体を、比較的小さなカラー・ポインタに保持されている情報から再製できることを述べておく。
【０１０８】  多角形メモリ頂点記憶装置は正にカラー部分を記憶する。多角形メモリは陰面除去には不必要なパイプライン状態の部分を記憶し、且つ陰面除去には不必要な頂点データの部分（特にカラーを作るのに必要な項目）も記憶する。
テクセル再使用検出及びタイル・ベースのプロセッシング
本発明の構造及び方法は、好都合にも、テクスチャ・マップの多重レイヤ（解像度）のトリリニア・マッピングを利用することができる。
【０１０９】  テクスチャ・マップは、一般的には、ＡＧＰインタフェースを使ってホスト・コンピュータのメモリからロードされるシングル・バッファド・メモリを備えているテクスチャ・メモリに記憶されている。代表的な実施例では、単一の多角形は４つのテクスチャまで使用できる。テクスチャはＭＩＰマップされる。即ち、各テクスチャは異なる詳細度又は解像度で一連のテクスチャ・マップを備えており、各マップは視点からの所与の距離におけるテクスチャの外観を表している。所与のピクセル・フラグメントに対するテクスチャ値を作り出すために、テクスチャ・ブロックは、正しい詳細度を近似するため、テクスチャマップからトリリニア補間を実行する。テクスチャ・ブロックは、代わりに、異方性補間のような他の補間法を実行することもできる。
【０１１０】  テクスチャ・ブロックは、フラグメント毎ベースで、フォング・ブロックに補間済みテクスチャ値を（通常はＲＧＢＡカラー値として）供給する。バンプ・マップは特別な種類のテクスチャ・マップを表す。カラーの代わりに、バンプ・マップの各テクセルは高さフィールド勾配を含んでいる。
【０１１１】  多重レイヤはＭＩＰレイヤであり、補間はＭＩＰレイヤの中及び間にある。第１補間は各層内にあり、１つのレイヤは要求されるものより上の解像度を名目上有し、もう１つのレイヤは要求よりも下の解像度を有している２つの隣接するレイヤの間で補間するので、最適な解像度を生成するために、補間が３次元的に行われる。
【０１１２】  本発明のパイプラインは、構造及びオペレーションが従来型のキャッシュとは異なるので、本当はテクスチャ済み再使用レジスタであるテクスチャ・キャッシュを含むテクスチャ・メモリを含んでいる。ホストは、テクスチャ用の記憶装置も含んでおり、これは通常非常に大きいが、テクスチャをレンダーするため、テクスチャ・メモリとも呼ばれるテクスチャ・キャッシュ内にロードされねばならない。Ｓ及びＴが各ＶＳＰと関係付けられる。トリリニアＭＩＰマッピングを実行するため、我々は必然的に８つのサンプルをブレンドするので、本発明の構造は並行して走る８つのコンテンツ・アドレス可能（メモリ）キャッシュのセットを提供する。ある実施例では、キャッシュ識別子はコンテンツ・アドレス可能タグの１つであり、これが、キャッシュのタグ部分とキャッシュのデータ部分とがタグ又はインデクスから分けて配置されている理由である。従来は、タグとデータが一緒に配置されているので、タグ上のキューがデータを与える。本発明の構造及び方法では、タグとデータとが分けられており、インデクスがパイプラインに送り込まれる。
【０１１３】  データとタグは異なるブロックに記憶されており、コンテンツ・アドレス可能ルックアップはアドレスのルックアップ又はキューであり、それ自身のアドレスに記憶されている「データ」及び、異なるブロックに記憶されている実際のデータを参照するインデクスでさえある。インデクスが決められ、パイプラインに送り込まれるので、インデクスにより参照されるデータを決めることができる。言い換えれば、タグは１つの位置にあり、テクスチャ・データは２番目の位置にあり、インデクスは２つの記憶構造の間のリンクを提供する。
【０１１４】  本発明のある実施例では、テクセル再使用検出レジスタ（ＴＲＤＲ）は、通常テクセル補間回路と同じ集積回路上に配置されている、多数の関連メモリを備えている。好適な実施例では、テクセル再使用検出法がテクスチャ・ブロックで実行される。
【０１１５】  従来型３Ｄグラフィクス・パイプラインでは、空間内のある方位のオブジェクトがレンダーされる。そのオブジェクトはその上にテクスチャ・マップを有しており、多くの三角形プリミティブで表されている。ソフトウェア内で実行されるプロシジャは、ハードウェアに、特定のオブジェクト・テクスチャをＤＲＡＭにロードするように命令する。次に、特定のオブジェクトに共通で、従って同じテクスチャ・マップを有する全ての三角形がユニットに供給され、テクスチャ補間が実行され、その特定のオブジェクトを表すのに必要な全てのカラー付きピクセルが生成される。オブジェクトのカラー付けが終わると、オブジェクトがレンダされているので、ＤＲＡＭ内のテクスチャ・マップは壊すことができる。複数の同じ（方位や位置は異なるかもしれない）オブジェクトのような、同じテクスチャ・マップを有する２つ以上のオブジェクトがある場合、ＤＲＡＭ内のテクスチャ・マップが捨てられる前に、そのタイプのオブジェクト全てがテクスチャされるのが望ましい。異なるジオメトリを供給しても、同じテクスチャ・マップを全部に使用し、ホスト・メモリからテクスチャ・マップを繰り返し検索する必要を省いて、それを一時的に１つ又はそれ以上のパイプライン構造に置くことができる。
【０１１６】  より洗練された従来型のスキームでは、２つ以上のテクスチャ・マップが検索されてメモリに記憶され、例えば２つ又は数個のマップが、利用可能なメモリ、テクスチャ・マップのサイズ、多数のテクスチャ・マップを記憶又は保持する必要性、管理スキームの洗練度に応じて記憶される。これらの従来型テクスチャ・マッピング・スキーム、空間オブジェクト・コヒーレンスそれぞれが先ず第１に重要である。少なくとも全ての単一オブジェクト、特に同じテクスチャ・マップを使用するオブジェクトのグループに関し、オブジェクトを構成する三角形全てが一緒に処理される。空間コヒーレンシーというフレーズは、三角形がオブジェクトを形成し、空間で連結され、従って空間的にコヒーレントであるので、そのようなスキームに適用されるのである。
【０１１７】  本発明のディファード・シェーダー構造及び方法では、我々は必ずしも、このタイプの空間オブジェクト・コヒーレンスからの目に見える利益に依存したり、或いはそれを引き出すわけではない。その代わり、本発明のディファード・シェーダーの実施例はタイル上で作動する。どのような所与のタイルでも完全なオブジェクト、複数のオブジェクト、幾つかの完全なオブジェクト、又は幾つかのオブジェクトの部分を有しているので、タイル全体を覆う空間オブジェクト・コヒーレンスは通常無い。
【０１１８】  本発明の構造及び方法はディファード・シェーダーに向けられているので、この従来型のコンセプトを完全に打破している。たとえタイルがたまたま完全なオブジェクトを有している場合でも、典型的に異なる背景があり、本発明のカル・ブロック及びカル・プロシジャは、通常、ＶＳＰを、たとえタイルがある程度の空間コヒーレンシーをサポートしていても、完全にごた混ぜにされ空間的にインコヒーレントな順で生成して送る。その結果、パイプライン及びテクスチャ・ブロックは、好都合にも、テクスチャ・マップを、オンザフライで、リアルタイムに、そして受信されたオブジェクト・プリミティブ（例えば、三角形）に要求されるテクスチャに応じて、変更することができる。ちょうど受信した特定のオブジェクト・プリミティブ（例えば、単一の三角形）を処理するために、ホストからテクスチャ・マップを繰り返し検索し、次の異なるオブジェクト・プリミティブが異なるテクスチャ・マップを必要とする際にはそのテクスチャを処理する要件はどのようなものでも、控えめに言っても問題含みで、高速オペレーションを妨害する恐れがある。
【０１１９】  本発明の構造及び方法では、サイズ決めできるメモリがカード上にサポートされている。ある実施例では、１２８メガバイトが準備されているが、もっと多くも少なくもすることができる。例えば、３４Ｍｂ、６４Ｍｂ、５１２Ｍｂ又はそれ以上でも、ユーザーの必要性、カード上でメモリーに利用できる地所、利用できるメモリの密度に応じて設けることができる。
【０１２０】  全ての可視フラグメントに対する８つのテクステルを読み、それらを使い、そしてそれらを放り投げて、次のフラグメントに対する８つのテクステルが検索し記憶できるようにするのではなく、本発明の構造及び方法は、それらを再度必要とすることになる合理的な機会がある場合には、それらを記憶し再使用する。
【０１２１】  可視フラグメントを受信する度に８つのテクステルを読み、投げ捨てるのは実用的ではない。むしろ、これらのテクセルを再使用するのが望ましく、それは、あなたがタイル空間の中を進んでいる場合、タイル内のピクセル・グリッド（通常、長方形のタイル・ピクセル・グリッド内の連続する行に沿って処理される）は、同じテクスチャ・マップは連続したピクセルに対して必要ではないが、タイルの領域内の群となったの幾つかのピクセルには必要であり、従って最初に使用された後は二三のプロセス・ステップだけしか必要にならないようになるからである。望ましいことに、本発明は、繰り返し読まれたテクステルを使用しているので、必要な場合にそれを読めば、特定のテクスチャ・マップを必要とするあるフラグメントに我々が１度出会うと、後で同じタイル内にいる期間に、同じテクスチャを必要とする同じオブジェクトからの別のフラグメントに遭遇する機会が出てくることが分かる。それ故、我々はこれらのものをこのキャッシュにセーブし、オンザフライで、我々が必要とするものをキャッシュ（テクスチャ再使用レジスタ）から検索する。キャッシュ・ミスがある場合、例えばフラグメントとテクスチャ・マップが最初に出会うとき、そのテクスチャ・マップは検索され、キャッシュに記憶されることになる。
【０１２２】  テクスチャ・マップ検索待ち時間は又別の関心事であるが、先入れ先出し（ＦＩＦＯ）データ構造及び予見又は予報検索プロシジャを使って取り扱われる。ＦＩＦＯは大きく、ＣＡＭと関係付けて作動する。項目が必要な場合、それが既に記憶されているか調べられ、レジスタもＦＩＦＯに置かれるので、キャッシュ・ミスがあれば、比較的低速のメモリに出て、情報を検索しそれを記憶することもできる。データがキャッシュ内にある場合、ホスト・メモリから検索される場合の何れの場合でも、データはユニット・メモリに（新しく検索された場合はキャッシュにも）置かれる。
【０１２３】  効果的なことに、ＦＩＦＯは、遅延のソートとして働くので、テクスチャに対する必要性が一度（その実際の使用の前に）特定されれば、必要となる前に、検索がプロセッシングをスロー・ダウンさせないように、データを検索し再関係付けすることができる。ＦＩＦＯキューはパイプラインにスラックを提供し、且つ短縮するので、常に予報、予見することになる。ＦＩＦＯを調べることにより、キャッシュされていないテクスチャを識別し、ホスト・メモリから検索し、キャッシュ内及び空間ユニット・メモリ内に置くことができるので、読み込みの際には何時でも利用できるようになる。
【０１２４】  ＦＩＦＯ及び、予見及び予報的検索を提供するその他の構造は、ある意味で、通常オブジェクト毎プロセッシングに使われる空間オブジェクト・コヒーレンスが我々のタイル毎プロセッシングで失われた際に作り出される問題を取り囲むように提供される。本発明の構造及び方法はオブジェクト内のあらゆる空間コヒーレンスを利用するので、１つのオブジェクト内の全ピクセルが順次行われる場合には、本発明は、時間的空間的コヒーレンスがあるという事実を利用しないことを述べておく。
パケット化されたデータ転送プロトコル
本発明の構造及び方法は、ブロックからブロックへとパケットで（データ及び制御のような）情報を巧く伝達する。我々は、このパケット化された通信をパケット化データ伝送と呼び、パケット化されたデータのフォーマット及び／又はコンテンツをパケット化データ伝送プロトコル（ＰＤＴＰ）と呼ぶ。このプロトコルはヘッダー部とデータ部を含んでいる。
【０１２５】  ＰＤＴＰの１つの利点は、データの全てを１つのバスでブロックからブロックに送ることができ、それによって、異なるデータ・タイプ用の別々のバスに関するあらゆる必要性を軽減できることである。ＰＤＴＰのもう１つの利点は、情報をパケット化すると順序を保持し易くなり、これは的確なレンダリングには重要なことである。レンダリングはパイプライン状態等の変化には敏感なので、時間順序を維持するのは一般的に重要で、例えばＭＩＪキャッシュでは、パケットのパイプラインへの送り込みのフローの管理が持に重要であることを思い出そう。
【０１２６】  バスは、パケットが順次的にある時間順で到着する順次的リンクで効果的なので、パケットの転送は順次的である。例えば「フィル・パケット」がブロックに到着すると、ブロックのＦＩＦＯに行き、ＶＳＰが到着するとこれもブロックのＦＩＦＯに行く。各プロセッサ・ブロックは、パケットがそのインプットに到着するのを待ち、パケットが到着すると、パケット・ヘッダを見て、必要なら、どの動作を取るか決める。その動作は（送るだけで何ら他の動作又は処理を行わない）パケットをアウトプットに送ることかもしれないし、パケットをどうにかすることかもしれない。パケット化されたデータ構造、パケット化されたデータ構造だけの、及びバス、ＦＩＦＯ或いは他のバッファ又はレジスタス・キームと組み合わせての使用は、３Ｄグラフィクス・システムより幅広いアプリケーションを有しており、複数の機能又はプロセッシング・ブロック又はユニットが相互連結され互いに通信する、あらゆるパイプライン構造に適用できる。パケット化伝送を使うのは、順次的又は時間順序が重要な場合は、特に有用である。
【０１２７】  ＰＤＴＰのある実施例では、各パケットはパケット識別子即ちＩＤ及び他の情報を有している。パケットには様々なタイプがあり、異なるパケット・タイプ毎に、標準長を有し、パケットのタイプを特定するヘッダを含んでいる。パケットタイプが違えば、様式と長さが異なるが、各特定のパケット・タイプは標準長を有している。
【０１２８】  好都合にも、各ブロックはインプットにＦＩＦＯを含んでおり、パケットはＦＩＦＯを通って流れ、そこで関係する情報がブロックによりＦＩＦＯに蓄積される。パケットは他の又は全てのブロックを通って流れ続けるので、そのブロックの機能に関係する情報を抽出することができる。
【０１２９】  本発明の構造及び方法のある実施例では、ＦＩＦＯ内の記憶装置セル又はレジスタは、小さなパケットはただ１つだけのＦＩＦＯレジスタを要求し、大きなパケットは、例えば２、３、５、１０、２０、５０又はそれ以上のレジスタのように多数のレジスタを要求するように、ある決められた幅を有している。可変パケット長、及び単一のパケットが数個のＦＩＦＯ記憶装置レジスタを消費するかもしれないという可能性は、パケットの最初の部分がパケットのタイプを特定し、直接又は間接に、パケット・タイプ、パケットのサイズ、パケットが消費するＦＩＦＯエントリの数が分かるので何ら問題を起こさない。本発明の構造及び方法は、本明細書の他の節で述べる数多くのパケット・タイプを提供し、サポートする。
フラグメント・カラリング
フラグメント・カラリングは、２次元ディスプレイ空間に対して実行され、例えば三角形プリミティブの３頂点からディスプレイされるピクセルのサンプル取りされた座標へのカラーの補間を包含している。基本的に、フラグメント・カラリングは、補間関数を３つのフラグメント頂点でカラーに適用し、空間的に３つの頂点の間に配置された位置に対しカラーを決めることを包含している。通常、しかし随意的に、補間を行う際には遠近法的補正を幾らか考慮しなければならない。補間係数は遠近補正係数としてキャッシュされる。
法線の補間
面法線、特に、３Ｄグラフィクス環境において、他の面法線の間に補間される面法線の計算に関し、従来から様々な妥協が受容されてきた。通常、妥協は、計算上の容易さ又は効率に対する精度のトレードオフである。理想的には、面法線は、補間の基準となる面法線の角度における実際の角度差に基づき角度的に補間されるべきである。実際にはそのような角度計算は３Ｄグラフィクス・アプリケーションにはうまく適していない。
【０１３０】  従って、通常、面法線は２つの入力法線の線形補間に基づいて補間される。低ないし中品質のレンダリングでは、複合面法線の線形補間は妥当な精度を提供するかもしれないが、２次元補間の例を考えると、１つのベクトル（面法線）が例えばもう一つのベクトルより大きいが、最初のベクトルと比較できるほどの角度変化を有している場合、合成ベクトルには、２つのベクトルの間の角度差が比較可能なほどであるにもかかわらず、大きい方のベクトルの影響が強く出過ぎる。その結果、例えば、ある面シェーディング又はライティング計算が異常な結果を引き起こし、出力シーンの品質を低下させるような、拒否すべきエラーを引き起こすかもしれない。
【０１３１】  線形補間が正規化されたベクトルのセット上で実行されたとしても、これらの問題の幾つかは最小化できるかもしれないが、幾つかのＡＰＩは非正規化ベクトルと、例えば３座標補間、独立したｘ、ｙ、ｚ補間及び他のスキームを含む様々な補間スキームとをサポートしているので、これが常に現実的なわけではない。
【０１３２】  本発明の構造及び方法では、大きさは、方向即ち角度とは別に補間される。補間された大きさが計算され、次に同じサイズの方向ベクトルが計算される。別々に補間された大きさと方向は次に組み合わせられ、方向が正規化される。
【０１３３】  理想的な角度補間は最高の品質を提供することにはなるが、この補間は曲面上の３点と種々の大円の計算を伴っている。この種の数学的複雑さはリアルタイム高速パイプライン・プロセッシングには適していない。単一ステップ線形補間はもっと単純ではあるが大きなエラーに陥りやすい。これら各プロシジャを比較して、本発明の面法線補間プロシジャは、従来型の線形補間よりも高い精度を有し、従来型の角度補間よりも計算上の複雑さは低い。
空間セットアップ
本発明の好適な実施例では、セットアップ・ブロック（ＳＴＰ）で空間セットアップが行われる。セットアップ・ブロック（ＳＴＰ）は、ソート（ＳＲＴ）ブロックからパケットの流れを受信する。このパケットはレンダーされるプリミティブに関する空間情報を有している。ＳＴＰブロックのアウトプットはカル（ＣＵＬ）ブロックに行く。ＳＲＴから受信されたプリミティブはフィルド三角形、ライン三角形、ライン、スティップルド・ライン、ポイント何れでもよい。これらプリミティブそれぞれは、エイリアスド又はアンチエイリアスド・モードでレンダーできる。ＳＲＴブロックはプリミティブをＳＴＰ（及び他の下流のパイプライン・ステージ）にタイル順に送る。各タイル内では、データが時間順又はソート済み透明度の順に編成されている。ＣＵＬブロックは、データをＳＴＰブロックからタイル順（実際にはＳＴＰがプリミティブをＳＲＴから受信した順）に受信し、レンダーされたイメージには決して寄与することのないプリミティブの部分を選別する。これは２つのステージで行われる。最初のステージではコンテンツが所与の値より大きな長方形メモリ・アレイ内のエレメントを検出できる。第２ステージは、サンプル毎にコンテンツ比較を行うことにより、この検索を精製する。ＳＴＰブロックは、入ってくるプリミティブをＣＵＬブロックでの処理に備えて準備する。ＳＴＰは、タイトな境界画定ボックスと、第１ステージの選別用のタイルと交差するプリミティブの部分に関する最小デプス値Ｚｍｉｎを作るが、この第１ステージは、Ｚｍｉｎより小さいデプス値を含むかもしれない境界画定ボックス内にスタンプをマークする。Ｚ選別ステージはこの候補スタンプを取り、それがプリミティブの部分である場合は、スタンプ内のサンプルに関する実際のデプス値を計算する。次にこのより正確なデプス値を使ってサンプル毎に比較し、可能であれば捨てる。第１ステージ選別用の境界画定ボックス及びＺｍｉｎに加え、ＳＴＰはデプス勾配、ライン傾斜、及び、デプス及びＺ選別ステージ用のタイル・エッジとのプリミティブの交差する点のような他の基準パラメータも計算する。ＣＵＬユニットは他のパイプライン・ステージで使用されるＶＳＰを作る。
【０１３４】  本発明の好適な実施例では、セットアップ・ブロックで空間セットアップ・プロシジャが実行される。本発明の空間セットアップ構造及び方法の重要な態様は、１）統合されたプリミティブのサポート及び生成、２）プリミティブに関するタイル内でのＺｍｉｎを計算するためのプロシジャ、３）タイル関係ｙ値及びスクリーン関係ｘ値の使用、４）これも又下流のハードウェアを簡素化する従来型のエッジ・ウォークに加えて、エッジ・ホップ（実際にはカル・ブロックで実行される）の実行、を含む。
【０１３５】  統合されたプリミティブの標題の下で、我々はライン・プリミティブを長方形と考え、三角形を退化した長方形と考え、各々数学的にそのように表現される。セットアップは、ライン・セグメントを４つの頂点から成る平行四辺形に変換する。三角形は３つの頂点を有している。セットアップは各プリミティブを４つのポイントのセットで記述する。但し、全ての値が全てのプリミティブに必要なわけではない。三角形に対してセットアップは、トップ、ボトム、及び三角形の方位によって左又は右何れかのコーナーを使用する。ライン・セグメントは平行四辺形として取り扱われるので、セットアップは４ポイント全てを使用する。但し三角形の頂点はオリジナルの頂点と同じだが、セットアップはラインを四辺形として表現するため新しい頂点を生成する。プリミティブの統合された表現は、ウィンドウ座標内の頂点のオリジナルのセットに割り当てられているプリミティブの記述子を使用する。加えて、どの記述子が有効で意味のある値を有しているかを表示するフラグがある。
【０１３６】  三角形に関しては、三角形頂点をそのｙ座標でソートすることによって、ＶｔｘＹｍｉｎ、ＶｔｘＹｍａｘ、ＶｔｘＬｅｆｔＣ、ＶｔｘＲｉｇｈｔＣ、ＬｅｆｔＣｏｒｎｅｒ、ＲｉｇｈｔＣｏｒｎｅｒ記述子が得られる。ライン・セグメントに関しては、これらの記述子は、ライン四辺形頂点が生成されたときに割り当てられる。ＶｔｘＹｍｉｎは最小ｙ値を持った頂点である。ＶｔｘＹｍａｘは最大ｙ値を持った頂点である。ＶｔｘＬｅｆｔＣは、三角形の場合、長いｙ辺（ＶｔｘＹｍｉｎとＶｔｘＹｍａｘの頂点を結んで形成される三角形の辺）の左の頂点であり、平行四辺形の場合は、ＶｔｘＹｍｉｎとＶｔｘＹｍａｘの頂点を結んで形成される対角線の左の頂点である。三角形で、長いｙ辺が左の辺でもある場合、フラグＬｅｆｔＣｏｒｎｅｒは、ＶｔｘＬｅｆｔＣが無効であることを示す偽（０）である。同様に、ＶｔｘＲｉｇｈｔＣは、三角形の場合、長いｙ辺の右の頂点であり、平行四辺形の場合は、ＶｔｘＹｍｉｎとＶｔｘＹｍａｘの頂点を結んで形成される対角線の右の頂点である。三角形で、長い辺が右の辺でもある場合、フラグＲｉｇｈｔＣｏｒｎｅｒは、ＶｔｘＲｉｇｈｔＣが無効であることを示す偽（０）である。これらの記述子は、トップ及びボトム・タイル・エッヂでプリミティブをクリッピングするのに使われる。但し、実際には、ＶｔｘＹｍｉｎ、ＶｔｘＹｍａｘ、ＶｔｘＬｅｆｔＣ、ＶｔｘＲｉｇｈｔＣはオリジナルのプリミティブ頂点へのインデクスである。
【０１３７】  三角形に関しては、三角形頂点をそのｘ座標でソートすることによって、ＶｔｘＸｍｉｎ、ＶｔｘＸｍａｘ、ＶｔｘＴｏｐＣ、ＶｔｘＢｏｔＣ、ＴｏｐＣｏｒｎｅｒ、ＢｏｔｔｏｍＣｏｒｎｅｒ記述子が得られる。ライン・セグメントに関しては、これらの記述子は、ライン四辺形頂点が生成されたときに割り当てられる。ＶｔｘＸｍｉｎは最小ｘ値を持った頂点である。ＶｔｘＸｍａｘは最大ｘ値を持った頂点である。ＶｔｘＴｏｐＣは、三角形の場合、長いｘ辺（ＶｔｘＸｍｉｎとＶｔｘＸｍａｘの頂点を結ぶ辺）の上方にあり、平行四辺形の場合は、ＶｔｘＸｍｉｎとＶｔｘＸｍａｘの頂点を結んで形成される対角線の上方にある。三角形で、長いｘ辺がトップの辺でもある場合、フラグＴｏｐＣｏｒｎｅｒは、ＶｔｘＴｏｐＣが無効であることを示す偽（０）である。同様に、ＶｔｘＢｏｔＣは、三角形の場合、長いｘ辺の下方にある頂点であり、平行四辺形の場合、ＶｔｘＸｍｉｎとＶｔｘＸｍａｘの頂点を結んで形成される対角線の下方にある。三角形で、長いｘ辺がボトムの辺でもある場合、フラグＢｏｔｔｏｍＣｏｒｎｅｒは、ＶｔｘＢｏｔＣが無効であることを示す偽（０）である。これらの記述子は左及び右タイル・エッヂでプリミティブをクリッピングするのに使われる。但し実際には、ＶｔｘＸｍｉｎ、ＶｔｘＸｍａｘ、ＶｔｘＴｏｐＣ、ＶｔｘＢｏｔＣはオリジナルのプリミティブ頂点へのインデクスである。加えて、我々は４つの多角形の辺の傾斜（δｘ／δｙ）及び傾斜の逆数（δｙ／δｘ）を使用する。
【０１３８】  これらの記述子全てが平行四辺形プリミティブに対しては有効値を有するが、全てが三角形の対して有効なわけではない。最初は、三角形及び四辺形のような単純なプリミティブを記述するのには記述子が多いように見える。しかし、後に分かるように、これら記述子は極めて簡単に入手でき、プリミティブをセットアップするのに正確で一様な方法を提供する。
【０１３９】  ラインを四辺形として取り扱う（又は長方形をラインとして対等に解釈する）ことは、空間及び幅の２つの端点を指定することを包含している。三角形を長方形として取り扱うのは４つの点を指定することを包含しているが、ある実施例では通常ｙレフト又はｙライトである点の１つは、下位にあり指定されない。目標はタイル内側のＺｍｉｎを見つけだすことである。ｘ値は全ウィンドウ幅に亘って動き得るが、ｙ値はタイルに関係しているので、ビットは、計算でｙ値タイル関係座標を作ることによりセーブされる。
オブジェクト・タグ
３Ｄシーンの有向非輪状グラフ表示は、通常、識別子をシーングラフ内の各ノードに割り当てる。この識別子（オブジェクト・タグ）は、シーン内のオブジェクトのピッキング、視認性決定、衝突検出、その他のレンダリング用統計的パラメータの生成のようなグラフィカル・オペレーションで有用である。レンダリングの際、ピクセル・パイプラインでは、アルファ・テスト、カラー・テスト、ステンシル・テスト、デプス・テストのような多くのテストが行える。アルファ及びカラー・テストは、オブジェクトが透明なピクセルを有しているかを調べ、それらの値を捨てるのに有用である。ステンシル・テストは、様々な特別の効果に使うことができ、ＣＳＧにおけるオブジェクト交差の決定に使うことができる。デプス・テストは通常、陰面除去に使われる。
【０１４０】  本明細書では、シーン内のオブジェクトにタグ付けし、どのオブジェクトが決められた視認性基準のセットを通ったかについてフィードバックを得る方法を説明する。
【０１４１】  ２レベル・オブジェクト割当スキームが利用される。オブジェクト識別子は、グループ（ｇ）とメンバー・タグ（ｔ）の２つの部分で構成されている。グループ「ｇ」は４ビット識別子（もっと多くのビットを使うこともできるが）で、シーン・グラフ・ブランチ、ノード・レベル、又は、オブジェクトをグルーピングするのに使うことのできる何らかの他のパラメータをエンコードするのに使うことができる。メンバー・タグ（ｔ）は５ビット値（これももっと多くのビットを使うこともできるが）である。このスキームでは、各グループは３２のメンバーまで有することができる。３２ビット状態ワードが各グループで使われる。この状態ワードのビットは、テスト基準を通ったメンバーを表示する。このように、状態は、オブジェクト・グループ、オブジェクト・タグ、タグテストＩＤ（デプス・テスト、アルファ・テスト、カラー・テスト、ステンシル・テスト）で構成されている。オブジェクト・タグはパイプラインに送り込まれ、ｚバッファド・ブレンド（又は好適な実施例におけるピクセル・ブロック）で使用される。サンプルが可視であれば、オブジェクト・タグは、特定のビットを特定のＣＰＵ読み取り可能レジスタにセットするのに使われる。これにより、オブジェクトをパイプライン内に供給できるようになり、一旦レンダリングが完了すると、ホストＣＰＵ（アプリケーション・プログラムを走らせている単一又は複数のＣＰＵ）はどのオブジェクトが少なくとも部分的には可視であるかを決めることができる。
【０１４２】  代わりに、１つのグループだけを暗示する、メンバー・タグ（ｔ）だけを使うこともできる。
【０１４３】  オブジェクト・タグは、ピッキング、透明性決定、早期オブジェクト廃棄、衝突検出に使うことができる。早期オブジェクト廃棄のために、オブジェクトは、その境界画定ボリュームをレンダリング・パイプラインに入力し、上記のように「視認性」をテストすることによって、視認性をテストすることができる。しかし、境域画定ボックスがフレーム・バッファにレンダーされるのを防ぐために、カラー、デプス及びステンシル・マスクはクリアされねばならない（これらのマスク・ビットの説明に関してはオープンＧＬ仕様書参照）。
【０１４４】  単一視認性ビット
上記オブジェクト・タグの代わりに、単一ビットをホストＣＰＵへのフィードバックとして使うことができる。この方法では「視認性」のために（即ち、ピッキング、透明性決定、早期オブジェクト廃棄、衝突検出等のために）テストされているオブジェクトは、それ自身のフレーム内で分離される。次に、フレーム内の何かが可視であれば、単一「視認性ビット」がセットされ、そうでなければクリアされる。このビットはホストＣＰＵが読み取り可能である。この方法の利点はその単純性にある。その不利な点は、テストする必要のある別々のオブジェクト（又はオブジェクトのセット）毎に個々のフレームを使う必要があり、それによって「視認性」決定に待ち時間を導入するかもしれないことである。
スーパータイル・ホップ・シーケンス
３Ｄイメージをレンダリングする際に、しばしば、ピクチャを通る水平方向のスワスがイメージの残りの部分よりかなりの複雑性を呈する「水平効果」がでてくる。この例は、単純な草原が前面にあり空が上にある、遠くの都市の空際線である。草と空は非常の僅かな多角形（それぞれ１つずつかもしれない）しか有していないのに、都市は多くの多角形と大きなデプスの複雑性を有している。このような水平効果は、シーンを通る非水平方向スワスに沿っても生じ得る。タイルが単純に上から下、そして左から右に処理される場合、複雑なタイルは背中合わせで出会うことになり、その結果パイプライン内に負荷不均衡が生じる恐れがでてくる。従って、タイルからタイルへと動く際は、スクリーンの周りをランダムに「ホップ」するのがよい。しかし、そうすると（隣接するタイルが順次処理されないので）空間コヒーレンシーが低下する結果となり、パイプライン内のキャッシュの効率を低下させ、性能が低下することになる。空間順次タイル・プロセッシングと全体的ランダム・パターンの妥協の結果として、タイルは「スパータイル」に編成され、但し、各スーパータイルは多数の空間的に隣接するタイルであり、次に、スーパータイルのランダム・パターンが処理される。このようにして、スーパータイル内では空間的コヒーレンシーが保持され、水平効果が排除される。好適な実施例では、スーパータイル・ホップ・シーケンス法が、ソート・ブロック内で実行される。
スキャンアウトの間の正規化
アウトプットの間の正規化は本発明のプロシジャであり、そこでは、フレーム・バッファ内の値を決定するために前の処理履歴が考慮されるか、或いはそうでなくフレーム・バッファ内の値が決められるかの何れかが行われ、スクリーン内の値の範囲が、値の範囲が表示でき、所望の視認特性を提供するようにスケーリング又は正規化される。線形及び非線型のスケーリングが適用され、クリッピングもできるので、ダイナミックな範囲が、小数の比較的明るい又は暗いピクセルにより過度に取り上げられることもなく、ダイナミックな範囲はディジタル／アナログ変換器の変換範囲に適合する。
【０１４５】  出力ピクセル値が生成される方法のある知識が、このアプローチの利点へのより大きな洞察力を提供する。時には、出力ピクセル値は、それが最終的には実世界におけるシーンの輝度又は明暗度をシミュレート又は表現するように表示されるので、明暗度又は輝度とも呼ばれる。
【０１４６】  好都合にも、ピクセル・カラーは浮動小数点で表現されるので、非常に広いダイナミック・レンジに亘ることができる。一度はディスプレイに対し適しているとスケーリングされた整数値が十分な範囲を提供しないこともあり、その場合には、出力明暗度が計算され後で再スケーリングされる。オープンＧＬを含め標準的ＡＰＩの下では、ライトは浮動小数点値として、座標距離として表現されることを指摘しておく。従って、従来型表現では、使用可能なディスプレイのダイナミック・レンジを投げ捨て又は浪費して、シーンが全くの黒（暗）又は全くの白（明）から出てくる、或いは特定の輝度範囲に向かって逸れるようにするのは比較的容易である。
【０１４７】  本発明の正規化プロシジャの下では、計算はずっと通して浮動小数点に望ましく維持され、最終的シーンは、出力ディスプレイ及びＤ／Ａ変換器の能力に合わせてピクセル明暗度値を導くため、あるスケーリング・ルーチンを使ってマッピングされる。このようなディスプレイ装置に対するスケーリング又は正規化は、範囲の圧縮又は拡張、線形な圧縮又は拡張、対数的圧縮又は拡張、指数的又は累乗的拡張、その他の算術的又は多項式的マッピング関数、又はこれらの組み合わせ無しに、値の範囲を異なる値の範囲にオフセット又はシフトするようなオペレーションを包含していてもよい。代わりに、任意のマッピング伝達関数を有するルックアップ・テーブルを、出力値明暗度変換を行うために実行してもよい。ピクチャを表示するためにスワップをバッファする時間であれば、スキャンアウトの間に対数的に（又は他の様式で）スケーリングする。
【０１４８】  望ましいのは、変換が決められたルールのセットの下で自動的に実行されることである。例えば、ピクセル・ヒストグラム・ベースの正規化を規定するルールが実行されてもよいし、ピクセルのガウス分布を規定するルール、ある随意の明暗度クリッピングを有する又は有しない出力明暗度を線形スケーリングするルールであってもよい。ここで提示する種々のマッピング関数は、コンピューター・グラフィクス及びディジタル・イメージ・プロセッシング技術で既知の多くの入出力ピクセル明暗度変換の単なる例に過ぎない。
【０１４９】  このアプローチを使えば、ライティング、オブジェクト・カラー等を規定する際にかなり大きな余裕が生まれ、なお可視であった最終アウトプットをレンダーすることができる。たとえ最終結果が美学的に完全ではなかったとしても、それは最終マッピングをチューニングするベースを提供するものであり、何らかの対話式調整が好ましいが、随意的にデバッギング、ファインチューニング、又はセットアップ・オペレーションとして提供されるのが望ましい。
スタンプ・ベースのｚ値記述
ＶＳＰがディスパッチされるときには、それは単一のプリミティブに対応しており、ｚバッファド・ブレンド（即ちピクセル・ブロック）は、ＶＳＰ内の各サンプル毎にｚ値を分ける必要がある。ＶＳＰ内の全てのサンプル毎ｚ値を送ることについての改善（これは帯域幅を考慮することになる）として、ＶＳＰがｚ基準値、及びｘ及びｙに関するｚの偏導関数（数学的には、プリミティブのｚ値に関する平面方程式）を含むようにすることができる。次に、この情報はｚバッファド・ブレンド（即ち、ピクセル・ブロック）で使用され、サンプル毎ｚ値が再構築され、それによって帯域幅がセーブされる。一貫性の欠如はレンダリング・エラーを引き起こすので、ＣＨＳＲプロセス用に計算されたｚ値がｚバッファド・ブレンド内で計算されたのと同じであるよう注意しなければならない。
【０１５０】  好適な実施例では、スタンプ・ベースのｚ値記述法は、カル・ブロックで行われ、サンプル毎ｚ値はこのピクセル・ブロック内の記述から生成される。
フォング・ブロック内のオブジェクト・ベースのプロセッサ・リソース割当
フォング・ライティング・ブロックは、好都合に、複数のプロセッサ又はプロセッシング・エレメントを含んでいる。フラグメント・カラー生成の間には、多くの状態が必要であり、共通のオブジェクトからのフラグメントは同じ状態を使うので、少なくとも効率の面からは、キャッシング要求を最小化するのが望ましく、同じオブジェクトからのフラグメントは、同じプロセッサで処理すべきである。
【０１５１】  本発明の構造及び方法では、同じオブジェクトに由来する全てのフラグメントは同じプロセッサ（又は、負荷が大きければ、同じ複数のプロセッサ）に送られる。これはフォング・ブロックの状態キャッシングを低減することになる。
【０１５２】  本発明の構造及び方法の好適な実施例はタイル毎プロセッシングを実行し、単一時間に多数のオブジェクトを含むことができることを思い出そう。従って、フォング・ブロック・キャッシュは、通常、２オブジェクト以上に対する状態を記憶し、適切な状態を、共通なオブジェクトからのフラグメントを取り扱っているプロセッサに送る。特定のオブジェクトからのフラグメント用の状態が特定のプロセッサに一旦送られると、そのオブジェクトからの他のフラグメントも全てそのプロセッサに向けられるのが望ましい。
【０１５３】  これに関連付けて、モード注入ユニット（ＭＩＪ）はオブジェクト又は材料を割当て、ＭＩＪはキャッシュを全ての下流のブロックに割り当てる。フォング・ユニットは、どのオブジェクト・データがどのフォング・ユニット・プロセッサにキャッシュされたかの航跡を保持しておいて、その同じオブジェクトに属する全てのフラグメントを同じプロセッサに注ぎ込むように試みる。これに対する唯一の随意的例外は、局部的不均衡があるときに生じ、その場合はフラグメントが別のプロセッサに割り当てられる。
【０１５４】  このオブジェクト・タグ・ベースのリソース割当（本明細書の別の部分では材料タグ・ベースのリソース割当とも呼ぶ）は、フォング・ユニット内でフラグメント・プロセッサ又はフラグメント・エンジンに関係して生じる。
パイプライン状態としてのダイナミック・マイクロコード生成
フォング・ユニットはテクスチャ環境計算の実行、及びオブジェクトからのフラグメントを処理するための特定のプロセッシング・エレメントの選択に責任を持っている。先に述べたように、共通のオブジェクトからのフラグメントは同じフォング・プロセッサ又はエンジンに向けるように試みられる。適用すべき特定のテクスチャ、面、カラーの特性等とは関係なく、多くの選択肢があり、その結果プロセッシングの環境が変化する。ここで、ダイナミック・マイクロコード生成をテクスチャ環境及びライティングと関連付けて説明するが、本発明の構造及びプロシジャは、他のタイプのマイクロコード、マシン状態及びプロセッシング全般にもっと広範囲に適用することができる。
【０１５５】  本発明の構造及び方法では、三角形ストリップの各時間プロセッシングが始まり、材料パラメータ変更が生じ、又はテクスチャ環境にタッチする殆ど全ての変化が生じ、フォング・ユニット内のマイクロコード・エンジンがマイクロコードを生成し、このマイクロコードがパイプライン状態の構成要素として取り扱われる。マイクロコードの状態の構成要素は、正に他のパイプライン状態のようにキャッシュされる属性である。このやり方で、一般的にはマシン状態として、特定すれば３Ｄグラフィクス・プロセッサ内のパイプライン状態として生成されたマイクロコードの取り扱いは、実質的に有用なものである。
【０１５６】  例えば、フォング・ユニットは多数のプロセッサ又はフラグメント・エンジンを含んでいる。（但し、ここで言うフラグメント・エンジンとは、フラグメントのテクスチャ・プロセッシングに責任を持つフォング・ユニットの中の構成要素であり、フラグメント・ブロック内で起こる補間とは別のプロセスである。）マイクロコードはフラグメント・エンジンにダウンロードされるので、フラグメント・エンジンに入って来て、同じマイクロコード（状態）を必要とする他のフラグメントは全て、必要なときにこれを使える。
【０１５７】  フォング・ブロック内のフラグメント・エンジンそれぞれの実施例は総称的には同じであるが、ダウンロード可能なマイクロコードの存在は、特殊化の程度を提供する。ＭＩＪキャッシング・メカニズムがどのように作動しているかによって、異なるマイクロコードをそれぞれにダウンロードすることができる。従ってダイナミック・マイクロコード生成はテクスチャ環境及びライティングに提供されるものである。
可変スケール・バンプ・マップ
可変スケール・バンプ・マップを生成することには、自動ベース生成と、自動勾配フィールド生成の２つのプロシジャの、どちらか又は双方が包含されている。グレイ・スケール・イメージと明暗度空間におけるその導関数とを考えてみよう。自動勾配フィールドは、グレイ・スケール明暗度に関し、グレイ・スケール・イメージの導関数をとり、その導関数を、バンプ・マップに対するバンプを生成するために面法線摂動として使う。自動ベース生成は、計算、多角形メモリ内のメモリ記憶装置、プロセス内のインプット帯域幅をセーブする。
【０１５８】  各三角形頂点に対して、ｓ、ｔ、面法線が規定される。しかし、ｓとｔはカラーではなく、テクスチャ・マップに対する２次元面法線摂動であり、従ってテクスチャ・バンプ・マップである。ｓとｔは、使用できるバンプ・マップを作るために面法線を摂動する方向を規定するのに使われる。ｓ、ｔは、我々が摂動方向を規定する元とすることのできる、暗示座標系及び基準を我々に与える。ｓ、ｔ座標系を各ピクセルで使えば、ピクセル位置における面正接及び従法線を規定する必要が全く無くなる。その結果、本発明の構造及び方法は、計算、メモリ記憶装置、インプット帯域幅をセーブすることになる。
【０１５９】  ピクセル毎タイル・ステージング・バッファのセットはＰｉｘｅｌＯｕｔとＢＫＥブロックの間に存在する。これらのバッファはそれぞれ、それに関係する３つの状態ビット、Ｅｍｐｔｙ、ＢｋｅＤｏｎｅＦｏｒＰｉｘ、ＰｉｘｃＤｏｎｅＦｏｒＢｋｅを有している。これらのビットは、これらのバッファ利用するために、ＰｉｘｅｌＯｕｔとＢａｃｋｅｎｄの間のハンドシェークを調整（又はシミュレート）する。バックエンド及びＰｉｘｅｌＯｕｔユニットは共に、ユニットが読み取り又は書き込みを行っているステージング・バッファを表示する、現在のＩｎｐｕｔＢｕｆｆｅｒ及びＯｕｔｐｕｔＢｕｆｆｅｒポインタを維持する。
【０１６０】  ＰＩＸによるレンダリングのためにタイルを準備するため、ＢＫＥブロックは次のＥｍｐｔｙバッファを取り、フレーム・バッファ・メモリからデータを読み込む（必要であれば、ＲＧＢＡＣｌｅａｒＭａｓｋ、ＤｅｐｔｈＭａｓｋ、ＳｔｅｎｃｉｌＭａｓｋにより決められているように、そしてビット平面のセットがクリアされていない場合には読み込まれる）。タイル内における読みとりによりＢａｃｋｅｄｄが行われた後、それはＢｋｅＤｏｎｅＦｏｒＰｉｘビットをセットする。ＰｉｘｅｌＯｕｔは、ＩｎｐｕｔＴｉｌｅのＢｋｅＤｏｎｅＦｏｒＰｉｘビットを見る。ビットがセットされていなければ、ＰｉｘｅｌＯｕｔはストールし、そうでなければＢｋｅＤｏｎｅＦｏｒＰｉｘビット、及び、ピクセル・タイル・バッファ内のカラー・デプス及び／又はステンシル・ビット平面（必要に応じ）をクリアし、それを適当にタイル・サンプル・バッファへと転送する。
【０１６１】  アウトプット時、ＰｉｘｅｌＯｕｔユニットは、レンダ済みタイル内のサンプルを、ピクセル・タイル・バッファ内のピクセルに分解する。バックエンド・ユニット（ＢＫＥ）ブロックはこれらのバッファをフレーム・バッファ・メモリに転送する。ＰｉｘｅｌバッファはＰｉｘｅｌＯｕｔユニットにより順に点検される。ＰｉｘｅｌＯｕｔは、レンダ済みサンプル・タイルをそれが来た同じピクセル・バッファに放射する。ピクセル・タイル・バッファへのタイル出力が済んだ後、ＰｉｘｅｌＯｕｔユニットはＰｉｘＤｏｎｅＦｏｒＢｋｅビットをセットする。次に、ＢＫＥブロックは、ＰｉｘＤｏｎｅＦｏｒＢｋｅセット付きのピクセル・タイル・バッファを取り、そのビットをクリアし、それをフレーム・バッファ・メモリに転送することができる。転送が済むと、Ｅｍｐｔｙビットはバッファ上にセットされる。
スキャンアウトの間のウィンドウド・ピクセル・ズーミング
Ｂａｃｋｅｎｄユニットはデータ及び／又は信号をＣＲＴ又は他のディスプレイ装置に送る責任を有しており、ディジタル情報を、そのディスプレイを駆動するのに適したアナログ信号に変換するためのディジタル／アナログ（Ｄ／Ａ）変換器を含んでいる。バックエンドは、双一次補間回路も含んでいるので、フレーム・バッファからのピクセルは、それがＣＲＴディスプレイに送られた際に、ピクセルの空間スケールを変えるために補間することができる。スキャンアウトの間のピクセル・ズーミングは、レンダリングすることを包含してはおらず、オンザフライで解像をスケール又はズーム（イン又はアウト）するだけである。ある実施例では、ピクセル・ズーミングはウィンドウ毎ベースで選択的に実行され、そこでは、ウィンドウは全デスクトップ又はディスプレイ領域の一部である。
スキャンアウトの間の仮想ブロック転送（ＶＢＬＴ）
従来型の構造及び方法は、オンスクリーン・メモリ記憶装置及びオフスクリーン・メモリ装置とを提供し、そのそれぞれが、例えば、カラー・バッファ、ｚバッファ、及びあるステンシルを有している。３Ｄレンダリングプロセスは、これらのオフスクリーン・バッファにレンダーする。１つのスクリーン・メモリが、ディスプレイ上に表示されるデータに対応する。オフスクリーン・メモリに対してレンダリングが済むと、オフスクリーン・メモリ内のコンテンツは、ブロック伝送（ＢＬＴ）と呼ばれるものの中のオンスクリーン・メモリにコピーされる。
【０１６２】  メモリ帯域幅をセーブし、本明細書の他の部分に記載されている利点を実現するために、本発明の構造及び方法は、交互の位置でデータを継ぐか又は交互の位置からデータを読み取るかすることにより「仮想」ブロック転送、即ち仮想ＢＬＴを実行する。
頂点リストに対するトークン挿入
このコンテクストでのトークンは、後に続くエントリが対応するものをパイプラインに告げる、パイプラインに供給される項目の間に差し挟まれる情報項目である。例えば、頂点のｘ、ｙ、ｚ座標がパイプラインに供給され、それらが３２ビット量である場合、トークンは、エントリそれ自身内に識別のための特別なビットがないので、後に続く数が頂点ｘ、ｙ、ｚ値であることを、パイプラインに知らせるために挿入される。トークンは、パイプライン・ハードウェアに、送られてきているデータをどのように解釈するかを告げる。
【０１６３】    （本発明の実施例の詳細な説明）
以下の説明は、読者の便利なように、そして、随意的要素を含め構成要素の理解を容易にし、且つ、本発明のパイプラインの構造及び方法を全体として理解し易くするために、幾つかの部分に分割されている。全体的ディファード・シェーディング・グラフィカル・プロセッサ又はグラフィクス・エンジンの実施例の説明から始め、次に、数々のインターブロック・インタフェース及び信号を説明するが、そこでは、本発明の少なくとも１つの実施例では、機能ブロックの間又は機能ブロック内で交信される少なくとも幾つかの信号が、好都合に、パケット化通信（パケット）を使用していることが分かる。インターブロック通信を説明した後、個々の機能ブロックの構造、オペレーション、方法を説明する。
Ｉ．ディファード・シェーディング・グラフィクス・プロセッサ（ＤＳＧＰ）１０００
本発明のディファード・シェーディング・グラフィクス・プロセッサ（ＤＳＧＰ）１０００を図Ａ３に示し、以下詳細に説明する。本発明の代替実施例を図Ａ４に示す。特に記載しない限り、以下の詳細な説明は図Ａ３及びＡ４を参照しながら行う。コンピュータ・グラフィクスは、ピクチャ又はイメージをコンピュータで生成する技術及び科学である。このピクチャ生成は、普通、レンダリングと呼ばれる。例えば３次元アニメーション内の動きは、連続したイメージを表示することによって作り出される。対話式３次元（３Ｄ）コンピュータ・グラフィクスを使えば、ユーザーは、リアルタイムで自分の視点を変え、或いはジオメトリを変えて、レンダリング・システムにリアルタイムで、オンザフライに新しいイメージを作るように要求することができる。従って、高品質な形象を備えたカラーにおけるリアルタイムな性能が益々重要になってきている。
【０１６４】  本発明は、新しいグラフィクス・プロセッサと方法に向けられており、特化したサブシステム、サブプロセッサ、デバイス、アーキテクチャ、及び対応するプロシジャを含む数多くのサブ構造を包含している。本発明の実施例は、１つ又はそれ以上のディファード・シェーディング、タイルド・フレーム・バッファ、多ステージ陰面除去プロセッシングを、他の構造及び／又はプロシジャと共に含んでいる。本明細書では、グラフィクス・プロセッサを、以後（ディファード・シェーディング・グラフィクス・プロセッサに対する）ＤＳＧＰ、又はＤＳＧＰパイプライン、そして時にはパイプラインとも呼ぶ。
【０１６５】  本発明は数多くのＤＳＧＰパイプラインの実施例を含んでいる。本発明の実施例は、ハードウェアに、フォング・シェーディング、サブピクセル・アンチエイリアジング、テクスチャ及びバンプ・マッピングを備えた、高性能３Ｄグラフィクスを提供するように設計されている。ＤＳＧＰパイプラインは、性能を損なうことなく、これらの洗練された特徴を提供する。
【０１６６】  ＤＳＧＰパイプラインは、これに限定するわけではないが、可能なインタフェースの選択肢の中で、例えばアドバンスド・グラフィクス・ポート（ＡＧＰ）及び／又はＰＣＩバス・インタフェースを含む種々の可能なインタフェース経由でコンピュータに接続することができる。ＶＧＡ及びビデオ・アウトプットも概ね含まれる。本発明の実施例は、オープンＧＬ及びダイレクト３Ｄ・ＡＰＩを両方共サポートする。マーク・シーガル及びカート・エイクレイ著、ジョン・リーチ編集の「オープンＧＬグラフィクス・システム、仕様書バージョン１．２」と題するオープンＧＬ仕様書を参考文献としてここに援用する。
【０１６７】  本発明の構造及び方法は、パイプラインの機能ブロック間のパケット化された交信を提供する。
【０１６８】  本仕様書で用いる「情報」という用語はデータ及び／又はコマンドを意味し、更に、プロトコル・ハンドシェーキング、ヘッダ、アドレス等の幾つか又は全ても含んでいる。情報は、単一ビット、複数のビット、バイト、複数のバイト、パケット、又は何らかの別の形態をとっていてもよい。データも、本アプリケーションでは、情報と同義に使用する。また「情報事項」というフレーズは、１つ又はそれ以上のビット、バイト、パケット、信号状態、アドレス等を指すのに使われる。説明している特定の構造及びプロシジャに関して区別するのが重要である場合にのみ、情報、データ、コマンドを区別して用いる。好都合に、本発明のプロセッサの実施例は、ホストに対し固有の物理アドレスを提供し、ブロック間のパケット化交信をサポートする。
ＩＩ．ディファード・シェーディング・グラフィクス・プロセッサ機能ブロック、及び、機能ブロック及び外部装置及びシステムとの交信及び対話
・ホスト・プロセッサ（ＨＯＳＴ）
本発明のグラフィクス・プロセッサのエレメント（但し、システムレベルを除く）ではなく、データ及びコマンドをシステム内のエレメントに供給するホストは、どのような汎用コンピュータ、ワークステーション、特化プロセッサでも、コマンド及びデータをディファード・シェーディング・グラフィクス・プロセッサに送ることができるものであればよい。ＡＧＰバスは、Ｈｏｓｔを、ＡＰＧバスと交信するＡＧＩに接続する。ＡＧＩは、当該技術ではよく知られており詳細な説明を省くＡＧＰプロトコルを実行する。
【０１６９】  ＣＦＤはＡＧＩと交信して、データをもっと取り扱えるときにはもっとデータを得るように告げ、時にはＣＦＤが、外に出て追加のコマンド及びデータをホストから得るようにそれを刺激するコマンド、即ち、追加のグラフィクス・ハードウェア・コマンド（ＧＨＣ）をフェッチするようにＡＧＩを刺激するコマンドを受信する。
・アドバンスド・グラフィクス・インタフェース（ＡＧＩ）
ＡＧＩブロックには、ホスト・メモリ又はＣＰＵとデータの送受信を行うために、ＡＧＰ及び／又はＰＣＩ仕様書により委任された全ての機能を実行する責任がある。このブロックは、ＡＧＰバスとチップの残りとの間の非同期境界を完全にカプセル化しなければならない。ＡＧＩブロックは、コマンドを高速転送できるようにするために、ＡＧＰ２．０仕様書の随意的高速書き込み能力を実行しなければならない。ＡＧＩブロックは、読み取り／書き込みコントローラ、ＤＭＡコントローラ、ＣＦＤ上の割り込み制御レジスタに接続される。
・コマンド・フェッチ及びデコード（ＣＦＤ）２０００
コマンド・フェッチ及びデコード（ＣＦＤ）２０００は、ＡＧＰバスとも称されるＡＧＩ入出力バスを通してのホスト・コンピュータとの交信を取り扱う。ＣＦＤは、ＡＧＰ／ＡＧＩインタフェースと実際にピクチャを描くハードウェアとの間のユニットであり、グラフィクス・ハードウェア・コマンド（ＧＨＣ）から成るインプットをアドバンスド・グラフィクス・インタフェース（ＡＧＩ）から受信し、このインプットを、普通は一連のパケットの形態をした他のデータのストリームに変換し、それを、ジオメトリ（ＧＥＯ）ブロック３０００、２次元グラフィクス・エンジン・ブロック（ＴＤＧ）１８０００、Ｂａｃｋｅｎｄ（ＢＫＥ）１６０００に送る。ある実施例では、ＡＧＩ、ＴＤＧ、ＧＥＯ、ＣＦＤそれぞれが共通の集積回路チップ上に共同配置されている。ディファード・シェーディング・グラフィクス・プロセッサ（ＤＳＧＰ）１０００（本明細書では「グラフィクス・パイプライン」又は単に「パイプライン」とも呼ぶ）は、必ずそうであるわけではないが、大部分はパケット通信ベースである。データのストリームはＡＧＩ経由でホストから受信され、このストリームは単純に、コマンド及び制御（アドレスを含む）及び、コマンド及び制御に関係するあらゆるデータを含むビットのストリームと考えることができる。このステージでは、これらのビットはパイプラインでカテゴライズされておらず、ＣＦＤが一義的に責任を持つタスクをパケット化してもいない。コマンド及びデータは、ＡＧＰバスを横切って来て、ＣＦＤによってそれらを消費するブロックに送られるる。ＣＦＤは又、受信したコマンドを幾らかデコード及びアンパックし、ＡＧＰインタフェースを管理し、ダイレクト・メモリ・アクセス（ＤＭＡ）転送に巻き込まれ、幾つかの状態をコンテクスト・スイッチのために保存する。ＣＦＤによって受信される（コマンド・トークンの形の）コンテクストスイッチは、パイプライン状態切替イベントを含み、簡単に言えば識別するので、パイプライン（又はその一部）は現在の（古い）状態を把握することができ、新しい状態情報を受信する準備ができている。ＣＦＤはコンテクス・スイッチ・コマンド・トークンを識別し消費する。
【０１７０】  インプット・ストリームの大部分はコマンドとデータを備えている。このデータは、ジオメトリカル・オブジェクト・データを含んでいる。これらのジオメトリカル・オブジェクトの記述は、カラー、面法線、テクスチャ座標、及び以下に詳しく説明する他の記述子を含んでいてもよい。インプット・ストリームは、ライティング、ブレンディング・モード、バッファ関数のようなレンダリング情報も含んでいる。２ＤＧに経路指定されるデータには、テクスチャ及びイメージデータが含まれていてもよい。
【０１７１】  この記述では、ある信号又はパケットがユニット内で生成され、他の信号又はパケットはユニットで消費（即ちユニットがパケットの最終宛先である）され、又他の信号又はパケットはユニット内を変更されずに単に通過し、一方又他のは何らかの方法で修正されることが分かるであろう。修正には例えば、フォーマットの変更、パケットの他のパケットへの分割、パケットの組み合わせ、パケットの再配置、又は、１つ又はそれ以上のパケットからの新しいパケットを形成するための関係情報の導出が含まれる。一般的に、この記述は、パケット又は信号生成器ブロック、及び信号又はパケット消費ブロックを識別し、簡単に言えば、生成ユニットから消費ユニットへブロックを単に通過し又は伝播するだけの信号又はパケットは記述しない。最後に、少なくとも本発明のある実施例においては、機能ブロックは複数のチップ（好適な実施例ではメモリ以外に３チップ）の間に分布されていることと、幾つかの信号又はパケット通信パスの後には、信号又はパケットをできるだけ早く、又は利用できるポート又はピン経由で、特定のチップ上に載せ又はチップから外そうと試みるパスが、例えそのパスがパイプラインを「線形」に通過していなくても、繋がっていることを理解できるであろう。これらは、説明した特定の実施例には有益な特定の構造的特徴を実現するものであるが、本発明を全体として特徴付け又は制限するものではない。例えば、単一チップ・アーキテクチャでは、代わりのパスが提供される。
【０１７２】  次に、表１に示す情報項目のリストに関し、インタフェースを越えて交信（送信及び／又は受信）される情報の点からＣＦＤ−ＴＤＧインタフェース２００１を説明する。ＣＦＤ−ＴＤＧインタフェース２００１は３２ビット（３１：０）コマンド・バスと６４ビット（６３：０）データ・バスとを含んでいる。（データ・バスは代わりに３２ビット・バスで、必要なときデータを伝達するのに順次書き込みオペレーションを使うようにしてもよい。）コマンド・バスは、ホストからＡＧＩに自動的に（又はＤＭＡ書き込みオペレーションを使って）書き込まれたコマンドを伝える。コマンドに関係するデータは、データ・バスを通って、遅れて書き込みオペレーションに入る。コマンドと（もし有れば）コマンドに関係するデータはそれぞれ「コマンド・バス」及び「データ・バス」として、時には「ヘッダ・バス」としてテーブル内で識別される。特定の信号又はパケットに関して特に示されない限り、コマンド、データ、ヘッダは、ブロック間をインプリメンテーション決定として、或いは、コマンド又はヘッダ情報を別々に到着させるか、又はパイプライン・ユニット内の別のサブブロックに向かわせるのが有益であるために、別々に伝えられる。これら詳細は、関係するアプリケーションの特定のパイプライン・ブロックの詳細な説明に述べられている。
【０１７３】  ＣＦＤはパケットをＧＥＯに送る。Ｖｅｒｔｅｘ＿１パケットは、頂点がＣＦＤに読み取られ、ＧＥＯが全性能頂点モードで作動しているときにＧＥＯに出力され、Ｖｅｒｔｅｘ＿２パケットは、ＧＥＯが１／２性能頂点モードで作動しているときに出力され、Ｖｅｒｔｅｘ＿３パケットは、ＧＥＯが１／３性能頂点モードで作動しているときに出力される。これらの性能モードは後でＧＥＯに関連し詳しく説明する。ＣＦＤのような主要機能ブロック内のアクション、プロセス又はステップに対する基準は、その主要ブロック全体か又はその主要ブロックの一部内の何れかにおいて、そのようなアクション、プロセス又はステップに対する基準である。伝播済みモードとは信号のブロックを通しての伝播を指す。消費済みモードとは受信ユニットにより消費される信号又はパケットを指す。ジオメトリ・モード・パケット（ＧＭＤ）は、モード変更コマンドがＣＦＤによって読まれると何時でも送られる。ジオメトリ材料パケット（ＭＡＴ）は、材料コマンドがＣＦＤによって検出されると何時でも送られる。ＶｉｅｗＰｏｒｔパケット（ＶＰ）は、ＶｉｅｗＰｏｒｔオフセットがＣＦＤによって検出されると何時でも送られる。バンプ・パケット（ＢＭＰ）及び材料パケット（ＭＴＸ）もＣＦＤによって送られる。ライト・カラー・パケット（ＬＩＴＣ）はライト・カラー・コマンドがＣＦＤにより読まれると何時でも送られる。ライト状態パケット（ＬＩＴＳ）はライト状態コマンドがＣＦＤにより読まれると何時でも送られる。
【０１７４】  ＣＦＤとＢＫＥの間にも通信パスがある。ＡＧＩからＣＦＤに到着するビットのストリームは、ＣＦＤによって処理されるか、又は処理されず、インプットと共に到着するアドレスに基づいて２ＤＧに向けられる。これは、ＣＦＤによる２ＤＧ境界信号又はパケットに対する取り扱いの量は最小であり、解釈もないことから、ＡＧＩと２ＤＧの間の殆ど直接の通信パス又はリンクと考えられる。
【０１７５】  もっと一般的には、本発明の少なくとも１つの実施例では、ホストは、ソース又は宛先アドレスに基づいて、パイプライン内の何れのユニットへも値を送ることができるし、何れのユニットからも値を検索することができる。更に、各パイプライン・ユニットは、ホストによって読み取り又は書き込み可能な、幾つかのレジスタ又はメモリ領域を有している。特に、ホストはＢＫＥからデータ又は値を検索することができる。バックエンド・バス（ＢＫＥバス）は、データをプッシュ又はプルできる２ＤＧにより広範囲に駆動することができる。レジスタの読み書きはマルチチップ通信ループ経由でも行える。
【０１７６】
【表１】
2004272928.tif 000003
・ジオメトリ（ＧＥＯ）３０００
ジオメトリ・ブロック（ＧＥＯ）３０００は、ＤＳＧＰの先端にある第１計算ユニットであり、入力を先ずＣＦＤからＣＦＤ−ＧＥＯインタフェース２００１経由で受信する。ＧＥＯは４つの主要なタスク、即ち、頂点座標と法線の変換、頂点の三角形、ライン及びポイントへのアッセンブリ、クリッピング、ガウロード・シェーディングに必要な頂点毎ライティング計算、を取り扱う。最初に、ジオメトリ・ブロックは入ってくるグラフィクス・プリミティブを一様な座標空間所謂「ワールド空間」に変換する。次に、プリミティブを視認ボリューム又は錐台にクリップする。視認ボリュームを定義する６つの平面（左、右、トップ、ボトム、前、後）に加え、ＤＳＧＰ１０００は、６つのユーザーが定義可能なクリッピング平面を提供する。クリッピングの後、ＧＥＯは４つ以上の頂点を有する多角形を三角形のセットに分解し、プロセッシングを簡単にする。最後に、何らかのガウロード・シェーディングがフレーム内にあれば、ＧＥＯはＦＲＧ１１０００がシェーディングを行うのに使う頂点カラーを計算する。
【０１７７】  ＤＳＧＰは、その作動特徴のある１つのサブセットたけが使用中である場合には、最大性能モードで作動できる。性能モード（Ｐモード）では、ＧＥＯは、各プリミティブ毎に全ての可能なオペレーションのサブセットだけを実施する。もっと随意的な特徴が選択的に実行可能で、その場合、パイプラインは、１／２性能モード（１／２Ｐモード）、１／３性能モード（１／３Ｐモード）、１／４性能モード（１／４Ｐモード）等のような一連の低性能モードを通って動く。ＧＥＯは、複数のＧＥＯ計算エレメントそれぞれが必要な計算に使用できるように編成されている。ＧＥＯは利用可能な計算エレメントを再使用して、プリミティブを非性能モード・セッティング用の低速で処理する。
【０１７８】  ＤＳＧＰの先端部（主にＡＧＩとＣＦＤ）は、グラフィクス・ハードウェア・コマンド（ＧＨＣ）のフェッチングとデコーディングとを取り扱い、ＧＥＯはＣＦＤから受信し、必要な変換マトリクス（ＭＴＸ）、材料及びライト・パラメータ（例えば、ジオメトリ材料パケット（ＭＡＴ）、バンプ・パケット（ＢＭＰ）、ライト・カラー・パケット（ＬＩＴＣ）、ライト状態パケット（ＬＩＴＳ））及び他のモード・セッティング（例えばジオメトリ・モード（ＧＭＤ）、ＶｉｅｗＰｏｒｔパケット（ＶＰ））をＧＥＯインプット・レジスタにロードする。
【０１７９】  アウトプットにおいて、ＧＥＯは変換済み頂点座標（例えば、空間パケット）、法線、生成及び／又は変換済みテクスチャ座標（例えば、テクスチャＡ、テクスチャＢパケット）及び頂点毎カラーを、生成済み又は伝播済み頂点（例えば、カラー・フル、カラー・ハーフ、カラー・サード、カラー他、空間）を含め、モード抽出ブロック（ＭＥＸ）４０００及びソート・ブロック（ＳＲＴ）６０００に送る。ＭＥＸは、カラーデータ（実際にはカラー以外も含んでいる）及びモードを多角形メモリ（ＰＭＥＭ）５０００に記憶する。ＳＲＴは、頂点毎「空間」データをタイルにより編成し、それをソート・メモリ（ＳＭＥＭ）７０００に書き込む。これらの信号の幾らかは固定長であるが、他は可変長であり、表２のＧＥＯ−ＭＥＸインタフェース３００１で識別される。
【０１８０】  ＧＥＯは、ジオメトリック・プリミティブであるポイント、ライン、三角形、四辺形、多角形を定義する頂点上で作動する。ＧＥＯは、頂点毎ベースで座標変換及びシェーディング・オペレーションを実行する。プリミティブ・アッセンブリ手続きフェーズの間にのみ、ＧＥＯは、頂点をラインと三角形にグループ分け（プロセスの中で、四辺形及び多角形を三角形のセットに分解）する。ＧＥＯは各プリミティブ毎にクリッピング及び面正接生成を行う。
【０１８１】  ＣＦＤからＧＥＯそしてＭＥＸへの伝播済みモードであると表示されている、開始フレーム、終了フレーム、クリア、カル・モード、空間モード、テクスチャＡ前／後、テクスチャＢ前／後、材料前／後、ライト、ピクセル・モード、及びスティップル・パケットに関して、これらのパケットは、ＣＦＤからＧＥＯそしてＭＥＸへ伝播される。空間パケット、開始フレーム、終了フレーム、クリア、カル・モードはＭＥＸからＳＲＴにも伝えられる。パケットを形成することになるビットはＡＧＰより到着し、ＣＦＤはそれを解釈してパケットに形成する。ＧＥＯはそれをＣＦＤから受信し、ＭＥＸに送る（伝播する）。ＭＥＸは、次の使用に備えてそれをメモリＰＭＥＭ５０００に記憶する。カラー・フル、カラー・ハーフ、カラー・サード及びカラー他は、オブジェクト又はプリミティブがどう見えるかを識別するが、これらは、受信されたＶｅｒｔｅｘ＿１、Ｖｅｒｔｅｘ＿２又はＶｅｒｔｅｘ＿３からＧＥＯによって生成される。空間パケットはプリミティブ又はオブジェクトの位置を識別する。表２は、ＭＥＸ−ＰＭＥＭ−ＭＩＪインタフェースで伝達される信号及びパケットを識別する。表３は、ＧＥＯ→ＭＥＸインタフェースで伝達される信号及びパケットを識別する。
【０１８２】
【表２】
2004272928.tif 000004
【表３】
2004272928.tif 000005
・モード抽出（ＭＥＸ）４０００及び多角形メモリ（ＰＭＥＭ）５０００
モード抽出ブロック４０００は、インプット情報ストリームをＧＥＯからパケットのシーケンスとして受信する。インプット情報ストリームは、既にＧＥＯ−ＭＥＸインタフェース３１００に関し表２に記載されているように、カラー・フル、カラー・ハーフ、カラー・サード、カラー他、空間、開始フレーム、終了フレーム、クリア、空間モード、カル・モード、テクスチャＡ前／後、テクスチャＢ前／後、材料前／後、ライト、ピクセル・モード、及びスティップルを含む、ＧＥＯからの幾つかの情報項目を含んでいる。カラー・フル、カラー・ハーフ、カラー・サード、カラー他のパケットはまとめてカラー頂点と称する。
【０１８３】  ＭＥＸはインプット・ストリームを１）空間情報、２）シェーディング情報、の２つの部分に分ける。空間情報は、空間パケット、開始フレーム、終了フレーム、クリア、カル・モード・パケットから成っており、ＳＲＴ６０００に送られる。シェーディング情報はライト（例えば、ライト・パケット）、カラー（例えばカラー・フル、カラー・ハーフ、カラー・サード、カラー他パケット）、テクスチャ・モード（例えば、テクスチャＡ前／後、テクスチャＢ前／後パケット）及び他の信号及びパケット（例えば、空間モード、材料前／後、ピクセル・モード及びスティップル・パケット）を含んでおり、多角形メモリ（ＰＭＥＭ）５０００と呼ばれる特別の空間バッファに記憶され、そこでは、モード注入（ＭＩＪ）ブロック１００００でこの情報を検索することができるようになっている。ＰＭＥＭはダブル・バッファされており、従って、ＭＥＸが次のフレームに対するデータを記憶しているのに対して、ＭＩＪは１つのフレームに対するデータを読むことができるようになっているのが望ましい。
【０１８４】  ＰＭＥＭに記憶されているモード・データ（例えば、ピクセル・モード、空間モード）は、概念的に、３つの主要カテゴリ、即ち（ライティングのような、そしてライト・パケットを含む）フレーム毎データ、（材料特性のような、そして材料前／後、スティップル、テクスチャＡ前／後、テクスチャＢ前／後パケットを含む）プリミティブ毎データ、及び（カラーのような、そしてカラー・フル、カラー・ハーフ、カラー・サード、カラー他パケットを含む）頂点毎データに置くことができる。事実、好適な実施例では、実際にはどんなモードのデータでも何時でも変化できるのだが、あるタイプのモード・データは頻繁に変化する（又は殆ど変化しない）という非常な類似性を有しているにもかかわらず、ＭＥＸはこれらのカテゴリの間に実際の区別を設けていない。
【０１８５】  ＭＥＸは、各空間パケットを受信する度に、ポインタのセットと共にＰＭＥＭ内に再パッケージする。このポインタのセットは、ＰＭＥＭからシェーディング情報を検索するのに使用される、カラー・アドレス、カラー・オフセット、カラー・タイプを含んでいる。空間パケットは又、頂点が、ポイント、ラインのエンドポイント、又は三角形のコーナーを表しているかを表示するフィールドを含んでいる。空間パケットは又、現在の頂点が所与のオブジェクト・プリミティブの最後の１つを形成している（即ち、プリミティブは「完了」している）かを規定する。三角形「ストリップ」又は「ファン」及びライン「ストリップ」又は「ループ」の場合、頂点は隣接するプリミティブの間で共有される。この場合、パケットは、各プリミティブ内の別の頂点を如何に識別するかを表示する。
【０１８６】  ＭＥＸはＭＩＪと結びついて、シェード済みグラフィクス状態情報の管理に責任を持っている。従来のグラフィクス・パイプラインでは、状態変化は通常、逐次的であり、状態パラメータの値は明示的に変えられるまで有効のまま留まる。従って、アプリケーションは変化したパラメータを更新するだけでよい。更に、プリミティブのレンダリングは通常、受信順である。ポイント、ライン、三角形ストリップ、三角形ファン、多角形、四辺形、四辺形ストリップは、グラフィカル・プリミティブの例である。このように、状態変化は、プリミティブに対する空間情報が受信されるまで蓄積され、これらの蓄積された状態は、そのプリミティブのレンダリングの間有効である。
【０１８７】  ＤＳＧＰでは、大部分のレンダリングが陰面除去の後まで延期される。視認性決定は何れの場合にも延期されない。ＧＥＯはプリミティブを順に受信し、全ての頂点オペレーション（変換、頂点ライティング、クリッピング、及びプリミティブ・アッセンブリ）を行い、データをパイプラインに送り込む。ＳＲＴは時間順のデータを受信し、それをそれがタッチするタイル毎に貯える。（各タイル内では、リストは時間順である。）カル（ＣＵＬ）ブロック９０００はＳＲＴからデータをタイル順に受信し、レンダーされたイメージには決して（保守的選別）寄与することのないプリミティブの部分を選別する。ＣＵＬは可視スタンプ部（ＶＳＰ）を生成し、そこでは、ＶＳＰは、ＣＵＬに関し詳しく説明したように、スタンプ上の多角形の可視部分に対応する。テクスチャ（ＴＥＸ）ブロック１２０００及びフォング・シェーディング（ＰＨＧ）ブロック１４０００はＶＳＰを受信し、それぞれ、フラグメントをテクスチャリング及びライティングする責任を持っている。ピクセル（ＰＩＸ）ブロック１５０００はＶＳＰ及びフラグメント・カラーを消費し、最終的ピクチャを生成する。
【０１８８】  プリミティブは多くのタイルにタッチすることがあるので、保存性のレンダリング・パイプラインとは違って、フレームをレンダリングする途中の間に、何度も（タッチするタイル毎に１回）訪問されることになる。パイプラインは（今パイプラインに入ってくるプリミティブに関する現在の状態と呼ばれるものではなく）プリミティブがパイプラインに入ってくるときのグラフィクス状態を実際に思い出し、ＳＲＴから下流のパイプライン・ステージが訪問してくるときには何時でもその状態を思い出さなければならない。ＭＥＸはＧＥＯとＳＲＴの間の論理ブロックであり、時間順状態変化データを集めてセーブし、プリミティブにそれがレンダーされるときの正しい状態を関係付けるため、プリミティブ頂点に適切なポインターを付ける。ＭＩＪは、必要なときに状態及び状態ポインタ（ここでは、ＭＬＭポインタ、又はＭＬＭＰと呼ぶ）付きのあらゆる他の情報を検索する責任がある。ＭＩＪは、情報を適切に再パッケージする責任もある。再パッケージの例は、ＰＭＥＭ内の頂点データが検索され、ＦＲＧのための三角形インプット・パケットに束ねられる際に生じる。
【０１８９】  グラフィクス・シェーディング状態はレンダーされたプリミティブの外観に影響を及ぼす。ＤＳＧＰパイプラインの異なる部分は異なる状態情報を使用する。ここで我々は、ＧＥＯから下流のパイプライン・ステージのみに着目する。ＤＳＧＰはグラフィクス状態を、状態情報が種々のパイプライン・ステージによってどのように使われるかに基づいて幾つかのカテゴリに分割する。状態を適切に分割するのが重要である。これは、性能（帯域幅とアクセスが制限されるようになることにより）、チップのサイズ（大きなキャッシュ及び／又は論理の複雑性）、及びチップ・ピン・カウントに影響を及ぼす。
【０１９０】  ＭＥＸブロックは以下の機能、即ちａ）データ・パケットをＧＥＯから受信する、ｂ）これらのデータ・パケットで必要なあらゆる再プロセッシングを実行する、ｃ）後でＭＩＪが探索するのに備え、ＰＭＥＭ内のパイプラインのシェーディング部分により必要とされる情報を適切にセーブする、ｄ）ＳＲＴに送られてきたプリミティブに状態ポインタを取り付けて、ＭＩＪがそのプリミティブに関係している状態を知ることができるようにする、ｅ）ＳＲＴ、セットアップ（ＳＴＰ）及びＣＵＬが必要とする情報を、中間状態として活動し、情報をパイプラインに伝播するＳＲＴに送る、ｆ）ＰＭＥＭ及びＳＭＥＭオーバーフローを取り扱う、に責任を持っている。ＰＭＥＭにセーブされた状態は分割され、ＭＩＪより下流の機能ブロック、例えば、ＦＲＧ、ＴＥＸ、ＰＨＧ、ＰＩＸにより使われる。この状態は、本明細書の別の場所で説明されているように分割される。
【０１９１】  パイプラインのＳＲＴ−ＳＴＰ−ＣＵＬ部分は、プリミティブをＶＳＰに変換する。これらのＶＳＰは、次に、パイプラインのＦＲＧ−ＴＥＸ−ＰＨＧ部分によりテクスチャされライトが当てられる。ＣＵＬがらＭＩＪへ出力されたＶＳＰは、必ずしもプリミティブ順ではない。多くの場合、それらはタイル上のＶＳＰスキャン順であり、即ち異なるプリミティブに対するＶＳＰが綴じ込まれる。パイプラインのＦＲＧ−ＴＥＸ−ＰＨＧ部分は、特定のＶＳＰがどのプリミティブに属しているかを知る必要がある。ＭＩＪはカラー・ポインタをデコードし、ＰＭＥＭから必要な情報を検索する。カラー・ポインタは、カラー・アドレス、カラー・オフセット、カラー・タイプの、３つの部分から成る。
【０１９２】  ＭＥＸはこのように、最後の状態セーブ以降に起こったあらゆる状態変化を蓄積し、状態ベクトルをチップ上に保持する。状態変化は頂点に出会うと直ぐに有効となる。ＭＥＸはカラー・ポインタ（又はカラー・アドレス）、カラー・オフセット及びカラー・タイプを、ＳＲＴに送られた全てのプリミティブ頂点に取り付ける。カラー・ポインタはＰＭＥＭ内の頂点エントリを指す。カラー・オフセットは、カラー・ポインタにおける頂点を、このプリミティブに適用可能なＭＬＭＰを記憶するのに使用されるデュアルオクトに分ける頂点の数である。
【０１９３】  カラー・タイプは、ＭＩＪに、完全なプリミティブをＰＭＥＭからどのように検索するかを告げる。頂点は順に記憶されているので、三角形ファンの場合を除いて、プリミティブ内の頂点は隣接している。ポイントに関しては、頂点がカラー・ポインタにより指されていさえすればよい。ラインに関しては、カラー・ポインタに指されている頂点と、その前の頂点が必要である。三角形ストリップに関しては、カラー・ポインタにおける頂点とその前の２つの頂点が必要である。三角形ファンに関しては、カラー・ポインタにおける頂点と、その前の頂点と、ＭＬＭＰ後の最初の頂点が必要である。
【０１９４】  ＭＥＸは、一般的に、受信するパケットの大部分のコンテンツを知る必要はない。そのタイプとサイズを知る必要があるだけである。この一般化には幾つかの例外があり、以下に説明する。
【０１９５】  カラー・フル、カラー・ハーフ、カラー・サード、カラー他のパケットを含むある種のパケットに関しては、ＭＥＸは、現在の頂点により定義されるプリミティブに関する情報を知る必要がある。特に、ＭＥＸは、ｃｏｌＰｒｉｍＴｙｐｅフィールドにより識別される、そのプリミティブのタイプ（ポイント、ライン、三角形ストリップ、又は三角形ファン）、そして三角形の場合にはそれがフロント・フェーシングであるかバック・フェーシングであるかを知る必要がある。この情報は、メモリ・オーバーフローの場合プリミティブを構築できるように、オンチップ記憶装置上に適切な頂点エントリをセーブするのに使われる。この情報は、ＧＥＯによりＭＥＸに送られるパケット・ヘッダ内にカプセル封入される。
【０１９６】  ＭＥＸは三角形の前面及び後面の両方に対し、材料及びテクスチャ・データを蓄積する。状態の１セットだけが、カラー・フル、カラー・ハーフ、カラー・サード、カラー他、テクスチャＡ、テクスチャＢ及び材料パケットに含まれているフロント・ビット又はフラグ・インジケータに基づいて、ＰＭＥＭに書き込まれる。但し、前／後方位は三角形ストリップ又は三角形ファン内で変わらない。フロント・ビットは、正しいテクスチャＡ、テクスチャＢパラメータ及び材料パラメータをプリミティブと関係付けるのに使われる。メッシュがメッシュ内のどこかで方位を変える場合、ＧＥＯは、新しい各メッシュが完全にフロント・フェーシングか又は完全にバック・フェーシングかの何れかとなるように、そのメッシュを２つ又はそれ以上のメッシュに分割する。
【０１９７】  同様に、空間モード・パケットに関しては、ＭＥＸは、プリミティブのタイプによって、空間モード・パケットのライン幅属性及びポイント幅属性の内１つを剥ぎ取ることができる必要がある。頂点がポイントを定義すれば、ライン幅が投げ捨てられ、頂点がラインを定義すれば、ポイント幅が投げ捨てられる。ＭＥＸはライン幅かポイント幅の一方だけを、ＳＲＴに、ＭＥＸ−ＳＲＴ空間パケット内のライン・ポイント幅の形で送る。
【０１９８】  クリア制御パケットの場合、ＭＥＸはＳｅｎｄＴｏＰｉｘｅｌフラグがセットされているかを調べる。このフラグがセットされていれば、ＭＥＸは（もし必要なら）ＰＭＥＭのＧＥＯからピクセル・モードのパケットで受信したピクセル・モードのデータをセーブし、適切なカラー・ポインタを作ってアウトプット・クリア・パケットに取り付け、必要なときにＭＩＪが検索できるようにする。表４はＭＥＸ−ＳＲＴインタフェースで伝達される信号及びパケットを識別する。
【０１９９】
【表４】
2004272928.tif 000006
・ソート（ＳＲＴ）６０００及びソート・メモリ（ＳＭＥＭ）７０００
ソート（ＳＲＴ）ブロック６０００は、ＭＥＸから、空間、カル・モード、終了フレーム、開始フレーム及びクリア・パケットを含む幾つかのパケットを受信する。ＭＥＸから受信した頂点に関して、ＳＲＴは結果としてのポイント、ライン、三角形をタイルでソートする。ＳＲＴは、グラフィクス・プリミティブを表す頂点のリスト及びタイル・ポインタ・リストのセットを、フレーム内の各タイル毎に１つのリスト、望ましくはダブル・バッファド・ソート・メモリ（ＳＭＥＭ）７０００に保持する。ＳＲＴはプリミティブが完了したと決定する。ＳＲＴは、プリミティブを完了する（三角形の第３頂点のような）頂点を受信すると、どのタイルにプリミティブがタッチするかをチェックする。プリミティブがタッチする各タイル毎に、ＳＲＴは頂点に対するポインタを、そのタイルのタイル・ポインタ・リストに追加する。ＳＲＴは、フレーム内の前ジオメトリをソートし終えると、プリミティブのデータ（プリミティブ・パケット）をＳＴＰに送る。各ＳＲＴアウトプット・パケット（プリミティブ・パケット）は、完全なプリミティブを表す。ＳＲＴはそのアウトプットを、１）タイル毎順に、最初に、所与のタイルにタッチする全てのプリミティブに、次に、次のタイルにタッチする全てのタイルに、そしてその後同様に、２）ソート済み透明モード順に、送る。これは、ＳＲＴが同じプリミティブを何度も、それがタッチする各タイル毎に一度送ることを意味する。ＳＲＴは又、ＳＴＰに、カル・モード、開始フレーム、終了フレーム、開始タイル及びクリア・パケットを送る。
【０２００】  ＳＲＴはパイプライン内のＭＥＸとＳＴＰの間に配置されている。ＳＲＴの基本的機能は、ジオメトリを取り込み、ジオメトリがカバーするタイルがどれであるかを決めることである。ＳＲＴは、少量のモード情報と共に、全シーンに対する全てのジオメトリを、それがラスタライズされる前に記憶するＳＭＥＭを管理する。ＳＭＥＭは、頂点及びモードのダブル・バッファドリストであるのが望ましい。あるＳＭＥＭページは、シーンのジオメトリを（頂点毎及びモード毎に）集め、一方他のＳＭＥＭページはそのジオメトリを（プリミティブ毎及びモード毎に）パイプラインの残りに送っている。ＳＲＴは、並列に作動する、ａ）ソート書き込みプロセス、ｂ）ソート読み取りプロセス、の２つのプロセスを含んでいる。ソート書き込みプロセスは２つの内の「マスター」プロセスであり、それは、書き込みが終了し読み取りプロセスが遊んでいるときに、ソート書き込みプロセスがソート読み取りプロセスを起動するからである。これは又好都合に、書き込みプロセスが、そうでなければＳＭＥＭバッファを一杯にする読み取りの数を制限するので、ＳＭＥＭを、一杯になりオーバーフローすることから守る。本発明のある実施例では、ＳＭＥＭはＳＲＴが配置されているチップとは別のチップ上に配置されているが、同一のチップ又は基板上に好都合に配置されていてもよい。この理由で、ＳＲＴとＳＭＥＭとの間の通信パスをここでは詳細に説明しないが、少なくともある実施例では、通信は同一機能ブロック（例えばソート・ブロック）内で行われるようになっている。ＳＲＴがＳＭＥＭと対話するやり方は関係するアプリケーションに記載してある。
【０２０１】  ＳＲＴ−ＭＩＪインタフェースが、プリフェッチ開始フレーム、プリフェッチ終了フレーム及びプリフェッチ開始タイルを伝播するために設けられている。事実、これらのパケットはＭＩＪ及びＰＩＸ経由でＢＫＥに向けられており、このＳＲＴ−ＭＩＪ−ＰＩＸ−ＢＫＥ通信パスは、ＭＩＪが、ＳＲＴの配置されているチップ上の最後のブロックを表している故に、使用される。プリフェッチ・パケットはパイプラインの周りを行くので、ＢＫＥは、同じパケットがパイプラインを通って伝播される場合よりも早く、予めフレーム・バッファからオペレーションを読み取ることができる。ＭＩＪは、ＢＫＥを含むチップに対する便利な通信チャネルを有しており、ＰＩＸは、パケットの最終的消費者であるＢＫＥと同じチップ上に配置されている。従って、パケットをＭＩＪに送ることは、アーキテクチャ設計の項目ではなく、実装詳細なのである。一方、異なる物理チップ上のブロックの間の通信をやり易くするために記述されている代わりのパスを使用するのは、この実施例に有益である。表５はＳＲＴ−ＭＩＪ−ＰＩＸ−ＢＫＥインタフェースで伝達される信号及びパケットを識別し、表６はＳＲＴ−ＳＴＰインタフェースで伝達される信号及びパケットを識別する。
【０２０２】
【表５】
2004272928.tif 000007
【表６】
2004272928.tif 000008
・セットアップ（ＳＴＰ）８０００
セットアップ（ＳＴＰ）ブロック８０００は、ＳＲＴからパケット（プリミティブ・パケット、カル・モード、開始フレーム、終了フレーム、開始タイル及びクリア・パケット）のストリームを受信する。これらのパケットはレンダーされるべきプリミティブについての空間情報を有している。プリミティブは、フィルド三角形、ライン三角形、ライン、分割済みライン、及びポイントで満たすことができる。これらのプリミティブは、それぞれ、エイリアスド又はアンチエイリアスド・モードでレンダーできる。ＳＴＰは、三角形及びライン・セグメントに対する統合されたプリミティブの記述、ポスト・タイル・ソーティング・セットアップ及び、タイル関連ｙ値及びスクリーン関連ｘ値を提供する。ＳＲＴは、プリミティブをＳＴＰ（及び他のパイプライン・ステージ下流）に、タイル順に送る。各タイル内で、データは「時間順」又は「ソート済み透明度順」の何れかで編成される。ＳＴＰは、１度に１タイル相当のデータ、１プリミティブを処理する。プリミティブについて行ったときには、データをプリミティブ・パケットの形でＣＵＬに送る。ＣＵＬは、データをＳＴＰからタイル順（実際にはＳＴＰがプリミティブをＳＲＴから受信したと同じ順）に受信し、レンダーされたイメージには決して寄与することのないプリミティブの部分を選別又は除去する。（レンダーされたイメージに寄与しないであろうことが確かに決定できない場合は、プリミティブの幾らかの部分が残される。）ＳＴＰは又、分割されたラインを別々のライン・セグメント（各々長方形領域）に分け、タイル内の各プリミティブに対する最小ｚ値を計算する。ＳＴＰから出力された各プリミティブ・パケットは１つのプリミティブ、即ち、三角形、ライン・セグメント又はポイントを表す。他のＳＴＰへのインプットには、カル・モード、開始フレーム、終了フレーム、開始タイル、及びクリアが含まれる。幾つかのパケットはＳＴＰで使われず、ＣＵＬに、単に伝播又は通過伝送される。
【０２０３】  ＳＴＰはＳＲＴから入ってくるプリミティブをＣＵＬで処理（選別）するのに備えている。ＣＵＬの選別オペレーションは２つのステージで行われる。ここでは選別について簡単に説明し、選別を予測してＳＴＰによって行われる予備プロセッシングが理解し易いようにする。最初のステージ、大きさ比較コンテンツ・アドレス可能メモリ・ベースの選別オペレーション（Ｍ−Ｃｕｌｌ）では、コンテンツが所与の値より大きい長方形メモリ・アレイ内のこれらのエレメントが検出できるようになる。本発明のある実施例では、大きさ比較コンテンツ・アドレス可能型のメモリが使用される。（これに限定するわけではないが、例として、１９９１年２月２６日認可の、ジェロームＦダルク・ジュニアによる「完全並行大きさ比較が可能なコンテンツ・アドレス可能メモリ・システム」と題する米国特許第４，９９６，６６６号は、特定の大きさ比較コンテンツ・アドレス可能型メモリに関する構造ついて説明しており、ここに参考文献として援用する。）
第２ステージ（Ｓ−Ｃｕｌｌ）では、サンプル毎にコンテンツ比較を行うことによって、この検索を精製する。ＳＴＰは、タイトな境界画定ボックスと、Ｍ−Ｃｕｌｌに対するタイルと交差するプリミティブの部分に関する最小デプス値Ｚｍｉｎを作る。Ｍ−Ｃｕｌｌステージは、Ｚｍｉｎより小さいデプス値を含むかもしれない境界画定ボックス内にスタンプをマークする。Ｓ−Ｃｕｌｌステージはこの候補スタンプを取り、それがプリミティブの一部である場合は、そのスタンプ内のサンプルに関する実際のデプス値を計算する。次にこのより正確なデプス値を使ってサンプル毎に比較し、可能であれば捨てる。Ｍ−Ｃｕｌｌ用の境界画定ボックス及びＺｍｉｎに加え、ＳＴＰは、デプス勾配、ライン傾斜、及び、デプス及びＳ−Ｃｕｌｌステージに対するタイル・エッジとのプリミティブの交差する点のような他の基準パラメータも計算する。ＣＵＬは他のパイプライン・ステージで使用されるＶＳＰを作る。
【０２０４】  従って、ＳＴＰには、ＳＲＴからプリミティブ・パケットの形で入ってくるプリミティブを受信し、これらのプリミティブを、カル・モード、開始フレーム、終了フレーム、開始タイル、及びクリア・パケットで受信される情報の助けを得て処理し、カル・モード、開始フレーム、終了フレーム、開始タイル、及びクリア・パケットと同じくプリミティブ（プリミティブ・パケット）を出力する責任がある。表７はＳＴＰ−ＣＵＬインタフェースで伝達される信号及びパケットを識別する。
【０２０５】
【表７】
2004272928.tif 000009
・カル（ＣＵＬ）９０００
カル（ＣＵＬ）ブロック９０００は２つの主要なハイレベル機能を実行する。第１の機能は、フレーム・バッファ内の最終結果に影響を及ぼさないと保証されているジオメトリを除去する（即ち、陰面除去の保存性形態）ことである。第２の機能は、プリミティブを、スタンプ部分が特定のスタンプとの特定のプリミティブの交差点であるようなスタンプ部分のユニットに分解することである。スタンプ部分の量はサンプリングによって決められる。ＣＵＬはＤＳＧＰ１０００内のより複雑なブロックの１つであり、ＣＵＬ内でのプロセッシングは、基本的には２つのステップ、即ち、大きさ比較コンテンツ・アドレス可能メモリ選別（Ｍ−Ｃｕｌｌ）及びサブピクセル選別（Ｓ−Ｃｕｌｌ）に分けられる。ＣＵＬは１度に１タイル相当のデータを受け取る。Ｍ−Ｃｕｌｌは、先に処理されたジオメトリに完全に隠されているプリミティブを捨てる。Ｓ−Ｃｕｌｌは、残りの（部分的に又は全体的に可視である）プリミティブを取り、可視フラグメントを決める。Ｓ−Ｃｕｌｌは、１度に、可視スタンプ部分（ＶＳＰ）と呼ばれるスタンプ・ベースのジオメトリ・エンティティである、１スタンプ相当のフラグメントを出力する。ある実施例では、スタンプはイメージの２ｘ２ピクセル領域である。但し、ＣＵＬで作られる可視スタンプ部分は、例え多数のプリミティブがそのスタンプにタッチしていても、単一のプリミティブだけからのフラグメントを含んでいる。多数のタッチしているＶＳＰからのカラーは後でピクセル（ＰＩＸ）ボックス内で組み合わせられる。ＶＳＰ内の各ピクセルは、どのくらい多くのピクセルが所与のフラグメントでカバーされているかを決めるため、多くのサンプルに分割される。ＰＩＸは、この情報を、フラグメントをブレンドしてピクセル用の最終のカラーを作る際に使用する。
【０２０６】  ＣＵＬは、ａ）陰面除去をプリシェーディングすること、ｂ）プリミティブ・ジオメトリ・エンティティ（三角形、ライン及びポイント）をスタンプ・ベースのジオメトリ・エンティティ（ＶＳＰ）に分割すること、に責任を持っている。一般的に、ＣＵＬは保存性選別、即ち陰面除去を実行する。ＣＵＬは、結果が時には正確な決定を行うように要求されるアルファ・テスト及びステンシル・テストのようなある種の「フラグメント・オペレーション」を取り扱うわけではないので、正確に陰面除去を行うのではなく、保存性陰面除去を行うことができるだけである。ＣＵＬのサンプルｚバッファは、２つのデプス値を保持することができるが、ＣＵＬは、サンプル当たり１つのプリミティブの属性を記憶できるだけである。このように、サンプルが２つのジオメトリからのカラーのブレンドを要求するときには何時でも、例え、ブレンドされる両ジオメトリを隠す後のジオメトリがあるかもしれない場合でも、ＣＵＬは第１プリミティブを（時間順を使って）パイプラインに送り込まなければならない。
【０２０７】  ＣＵＬは、それぞれがタイル毎ベースで、三角形、ライン又はポイントの何れかを記述する、ＳＴＰアウトプット・プリミティブ・パケットを受信する。ＳＲＴは、入ってくるジオメトリ・エンティティをタイルに貯えるユニットである。ＣＵＬが陰面除去を行えるように、ＳＴＰはプリミティブを事前処理し、より詳細なジオメトリ情報を提供することを思い出そう。ＳＴＰは、全てのエッジに関する傾斜値、タイル内のプリミティブの境界画定ボックス、タイル内のプリミティブの（最前）最小デプス値、及び他の関係データを事前計算し、このデータをパケットの形でＣＵＬに送る。ＳＲＴの前に、ＭＥＸは既にカラー、ライト、テクスチャ及び関係するモード・データの情報を抽出し、それを、後でＭＩＪが検索できるようにＰＭＥＭ内に置いており、ＣＵＬは、ＣＵＬに関係するモード・データと、ＰＭＥＭに記憶されているカラー、ライト及びテクスチャ・データを指すカラー・ポインタ（又はカラー・アドレス）だけを得ることを思い出そう。
【０２０８】  ＣＵＬは１度に１つのＶＳＰ（Ｖｓｐパケット）をＭＩＪに送り、ＭＩＪはＶＳＰを、ＰＭＥＭから検索された、そのカラー、ライト及びテクスチャデータと再結合し、ＶＳＰと、それに関係するカラー、ライト及びテクスチャ・データをパケットの形でＦＲＧ及びパイプライン内の後のステージに送る。関係付けられたカラーはＰＭＥＭに記憶される。ＣＵＬはＶｓｐｓをＭＩＪに出力するが、Ｖｓｐｓには多角形メモリ（ＰＭＥＭ）へのポインタが含まれているので、Ｖｓｐ用の関係付けられたカラー、ライト及びテクスチャ・データは、メモリから検索することができる。表８は、ＣＵＬ−ＭＩＪインタフェースで伝達される信号及びパケットを識別する。
【０２０９】
【表８】
2004272928.tif 000010
・モード注入（ＭＩＪ）１００００
モード注入（ＭＩＪ）ブロック１００００は、ＭＥＸと一緒になって、グラフィクス状態に関係する情報の管理に責任を持っている。ＭＩＪは、ＭＥＸにより以前にＰＭＥＭに記憶されていた、カラー、材料特性等のモード情報を検索し、それを、必要に応じて下流に送るためパイプラインに送り込む。帯域幅をセーブするため、個々の下流のブロックは最近使用したモード情報をキャッシュしているので、キャッシュ時には、モード情報を、ＭＩＪから、それを必要とする宛先へ送るのに帯域幅を使用する必要がない。ＭＩＪは、どの情報が下流のどのブロックでキャッシュされたかの航跡を保持しておいて、要求された情報がキャッシュされていない必要なときだけ、その情報を送る。
【０２１０】  ＭＩＪはＶＳＰパケットをＣＵＬブロックから受信する。各ＶＳＰパケットは２ｘ２ピクセル・スタンプ上のプリミティブの可視部分に相当する。カル・ブロックからＭＩＪブロックに出力されるＶＳＰは、必ずしもプリミティブ順ではない。大抵の場合、タイル上のＶＳＰスキャン順であり、即ち、異なるプリミティブに関するＶＳＰが差し挟まれることがある。ＶＳＰ内のフラグメントにライトを当て、テクスチャを施し、組み合わせるために、ＭＩＪブロックより下流のパイプラインのステージは、プリミティブのタイプ（即ちポイント、ライン、三角形、ライン・モード三角形）や、プリミティブの頂点におけるウィンドウ座標及び視点座標、法線、カラー及びテクスチャ座標のようなそのジオメトリ、及び、ピクセル・モード、テクスチャＡ、テクスチャＢ、ライト、材料、及びプリミティブに適用可能なスティップルのようなレンダリング状態、に関する情報を必要とする。この情報はＭＥＸにより、多角形メモリにセーブされている。
【０２１１】  ＭＥＸは又、カラー・ポインタ（カラー・アドレス、カラー・オフセット、カラータイプ）をＳＲＴに送られる各プリミティブに取り付け、今度はそれが、そのプリミティブの各ＶＳＰに送られる。ＭＩＪは、必要な情報を多角形メモリから検索するため、このポインタをデコードする。ＭＩＪは、ＣＵＬから開始フレーム・パケットを受信後、フレーム上で作業開始する。フレームに対するＶＳＰプロセッシングは、ＣＵＬがフレーム内の第１タイルで行われ、ＭＩＪがそのタイルのための最初のＶＳＰを受信したときに開始される。カラー・ポインタは、カラー・アドレス、カラー・オフセット、カラー・タイプの３っの部分から構成されている。カラー・アドレスは、プリミティブを完了するカラー頂点を指す。カラー・オフセットは、ＭＬＭ＿ポインタを含むデュアルオクトからカラー・アドレスを分ける頂点の数を提供する。ＭＬＭ＿ポインタ（材料ライト・モード・ポインタ）はＭＥＸにより定期的に生成されてＰＭＥＭに記憶され、特定のプリミティブに対して使用されるシェーディング・モードを見つけだすため、一連のポインタを提供する。カラー・タイプは、プリミティブのタイプ、各カラー頂点のサイズ、ライン・モード三角形に対する使用可能なエッジに関する情報を含んでいる。プリミティブを構成するカラー頂点は、２，４，６又は９デュアルオクト長である。ＭＩＪはカラー・ポインタをデコードして、ＭＬＭ＿ポインタを含むデュアルオクトのアドレス、及びプリミティブを構成する全てのカラー頂点を得る。ＭＬＭ＿ポインタ（ＭＬＭＰ）は、多角形メモリに６つの状態パケットのデュアルオクト・アドレスを含んでいる。
【０２１２】  ＭＩＪは以下のこと、即ちａ）開始フレーム、終了フレーム、開始タイルのような種々の制御パケットをＦＲＧ及びＰＩＸに送り、ｂ）プリフェッチ・パケットをＳＲＴからＰＴＸに送り、ｃ）ＶＳＰに対応するプリミティブの全ての頂点に対するカラー・ポインタを決定し、ｄ）ＰＭＥＭ内のＭＬＭＰの位置を決めてそれを検索し、ｅ）ＰＭＥＭ内の様々な状態パケットの位置を決め、ｆ）どのパケットを検索する必要があるかを決め、ｇ）状態をＣＵＬから受信した各ＶＳＰと関係付け、ｈ）状態パケット及びカラー頂点パケットをＰＭＥＭから検索し、ｉ）ＶＳＰのプリミティブ・タイプによって、ＭＩＪが、要求される頂点及び頂点毎データをＰＭＥＭから検索してプリミティブを構築し、ｊ）カラー、ＴｅｘＡ、ＴｅｘＢ、ライト、及び（ＦＲＧ、ＴＥＸ、ＰＨＧに対する）材料キャッシュ及びピクセル・モード及び（ＰＩＸに対する）スティップル・キャッシュのコンテンツの航跡を保持し、適切なキャッシュ・ポインタを各キャッシュ・ミス・データ・パケットに関係付け、ｋ）データをＦＲＧ及びＰＩＸに送る、ことに責任を持っている。
【０２１３】  ＭＩＪは更に、ｌ）例えばＰＭＥＭメモリ空間の不足によって起きるストールのようなストールをパイプライン内で処理し、ｍ）ＰＭＥＭ内に記憶されるデータの処置が済んだときにＭＥＸに信号を送って、メモリ空間を解放し新しく入ってくるデータ用に使えるようにすることにも責任を持っている。ＭＥＸはＰＭＥＭに書き込み、ＭＩＪはＰＭＥＭから読み取ることを思い出そう。メモリ状態及びＰＭＥＭの使用と利用可能性に関する制御情報のために、ＭＥＸとＭＩＪの間に通信パスが設けられている。ＭＩＪはこのように、ＶＳＰ内の各フラグメントに対する最終的カラーを計算するのに必要な頂点毎データと同じく、状態の検索を取り扱う。ＭＩＪは、状態と、必要なときには、状態ポインタ（ＭＬＭＰ）と関係付けられたあらゆる他の情報とを検索する責任がある。更に、情報を適切に再パッケージする責任もある。再パッケージは、例えば、ＰＭＥＭ内の頂点データが検索され、ＦＲＧ用のプリミティブ・インプット・パケットに束ねられる際に生じる。本発明の少なくとも１つの実施例では、ＭＩＪからＦＲＧへ伝達されるＶＳＰに含まれているデータは、ＭＩＪとＰＩＸの間で伝達されるＶＳＰ内のデータとは異なっている。ＦＲＧに伝達されたＶＳＰには、ライン（ＶｓｐＬｉｎ）、ポイント（ＶｓＰｎｔ）又は三角形（ＶｓｐＴｒｉ）のタイプを識別する、パイプラインの上流で追加される識別子も含まれている。開始タイルパケットはＭＩＪから、ＰＩＸ及びＦＲＧ双方に伝達される。表９は、ＭＩＪ−ＰＩＸインタフェースで伝達される信号及びパケットを識別し、表１０は、ＭＩＪ−ＦＲＧインタフェースで伝達される信号及びパケットを識別する。
【０２１４】
【表９】
2004272928.tif 000011
【表１０】
2004272928.tif 000012
・フラグメント（ＦＲＧ）１１０００
フラグメント（ＦＲＧ）ブロック１１０００は、基本的に補間に責任を持っている。これは、ガウロード・シェーディングのためにカラー値を補間し、フォング・シェーディングのために面法線を補間し、テクスチャ・マッピングのためにテクスチャ座標を補間する。これは更に、バンプ・マップが使用されている場合には、バンプ・マッピング・アルゴリズムで使用するため面正接を補間する。ＦＲＧは、少なくとも本発明の１つの実施例では、共通重心係数を使用して遠近修正補間を行う。
【０２１５】  ＦＲＧはＣＵＬ及びＭＩＪの後、ＴＥＸ及び（バンプ・マッピングが使用されている場合はＢＵＭＰを含む）ＰＨＧの前に配置されている。ある実施例では、ＦＲＧは、シェーディングが必要なフラグメントを４つまで含むＶＳＰを受信する。特定のＶＳＰ内のフラグメントは、常に同じプリミティブに属し、従ってフラグメントは、モード・セッティング全てを含み、頂点で定義されたプリミティブのデータを共有している。ＦＲＧの主要機能はＶＳＰ（Ｖｓｐパケット）の受取であり、ＶＳＰ内の全ての稼働中のフラグメントに対し頂点で提供される多角形情報の補間である。この補間タスクに関し、これは更に、他のブロックから受信したパケットを利用する。
【０２１６】  ＦＲＧのアウトプットにおいて、我々はなおＶＳＰを有している。ＶＳＰはフラグメントを含んでいる。ＦＲＧは所与のフラグメントの補間を並行して行うことができ、特定のＶＳＰ内のフラグメントは任意の順序で行うことができる。完全に補間されたＶＳＰはＦＲＧによりＴＥＸに送られ、ＦＲＧが受信したと同じ順序でＰＨＧに送られる。加えて、ＴＥＸに送られたデータの一部は、レベルオブディティル（ＬＯＤ又はλ）値を含んでいてもよい。ある実施例では、ＦＲＧは遠近修正共通重心補間を使って値を補間する。
【０２１７】  ＰＨＧは、フル及び非フル性能ＶＳＰ（Ｖｓｐ−ＦｕｌｌＰｅｒｆ、ＶｓｐＮｏｔ−ＦｕｌｌＰｅｒｆ）、テクスチャＢモード・キャッシュ・フィル・パケット（ＴｅｘＢＦｉｌｌ）、ライト・キャッシュ・フィル・パケット（ＬｔＦｉｌｌ）、材料キャッシュ・フィル・パケット（ＭｔＦｉｌｌ）及び開始タイルパケット（ＢｅｇｉｎＴｉｌｅ）をＦＲＧからヘッダ及びデータ・バスで受信する。ここで、フル性能及び非フル性能Ｖｓｐが伝達されることに留意されたい。パイプラインのあるレベルでは、４タイプ（例えば、フル、１／２、１／３、１／４性能）がサポートされ、これらがＰＭＥＭに書き込まれ、ＭＩＪに読み返される。しかしある実施例では、３タイプだけがＭＩＪからＦＲＧに伝達され、２タイプだけがＦＲＧからＰＨＢに伝達される。非フル性能は、ここでは１／２性能又はそれ以下を指す。これらの決定は、オンチップ通信及びオフチップ通信の利用可能な帯域幅と、他の実装関係因子に基づいて行われる。
【０２１８】  ある実施例では、ＦＲＧとＴＥＸが、４８ビット（４７：０）ヘッダ・バス、２４ビット（２３：０）Ｒデータ・インタフェース・バス、４８ビット（４７：０）ＳＴデータ・インタフェース・バス、２４ビット（２３：０）ＬＯＤデータ・インタフェース・バス等、幾つかのバスで連結される。ＶＳＰデータはＦＲＧからＴＥＸへこれら４つのバスそれぞれで伝達される。ＴｅｘＡフィル・パケット、ＴｅｘＢフィル・パケット及び開始タイル・パケットもＴＥＸにヘッダ・バスで伝達される。従来から多くのバスが使われているが、代わりに、好ましくはないが単一のバスを使ってもよい。表１１は、ＦＲＧ−ＰＨＧインタフェースで伝達される信号及びパケットを識別する。表１２はＦＲＧ−ＴＥＸインタフェースで伝達される信号及びパケットを識別する。
【０２１９】
【表１１】
2004272928.tif 000013
【表１２】
2004272928.tif 000014
・テクスチャ（ＴＥＸ）１２０００及びテクスチャ・メモリ（ＴＭＥＭ）１３０００
テクスチャ・ブロック１２０００は、テクスチャ・マップをピクセル・フラグメントに適用する。テクスチャ・マップはテクスチャ・メモリ（ＴＭＥＭ）１３０００に記憶される。ＴＭＥＭは、単にシングル・バッファされているだけでよい。これはホスト（ＨＯＳＴ）コンピュータのメモリからＡＧＰ／ＡＧＩインタフェースを使ってロードされる。単一の多角形は４つまでのテクスチャを使用できる。テクスチャは好都合にミップマップされており、即ち、各テクスチャは、複数の一連のテクスチャ・マップを異なる詳細度レベルで備えており、各テクスチャ・マップは所与の拡大又は縮小度におけるテクスチャの外観を表している。所与のピクセル・フラグメントに対するテクスチャ値を作るために、ＴＥＸはテクスチャ・マップからトリリニア補間（他の補間プロシジャを使ってもよいが）を行い、視認距離に対する正しい詳細度レベルを近似する。ＴＥＸは、異方性補間のような他の補間法も実行する。ＴＥＸは、補間済みテクスチャ値を（通常はＲＧＢＡカラー値として）Ｖｓｐパケットの形で、ＰＨＧにフラグメント毎ベースで供給する。バンプ・マップは特別の種類のテクスチャ・マップを表す。カラーの代わりに、バンプ・マップの各テクセルは高さフィールド勾配を含んでいる。
【０２２０】  多角形は、３Ｄグラフィクスで、オブジェクトの形を定義するために使用される。テクスチャ・マッピングは、詳細なイメージ又はパターンを有する多角形をカラリングすることにより表面のテクスチャをシミュレートするための技法である。通常、単一のテクスチャ・マップが、多くの多角形から構成されるオブジェクト全体をカバーする。テクスチャ・マップは、１つ又はそれ以上の名目上長方形のＲＧＢＡカラーのアレイから構成されている。本発明のある実施例では、これらの長方形アレイのサイズは、約２ｋＢｘ２ｋＢである。ユーザーは座標を、ＧＥＯで手動又は自動の何れかで、テクスチャ・マップに各頂点で供給する。これらの座標は各フラグメント毎に補間され、テクスチャ値はテクスチャ・マップ内で探索され、カラーがフラグメントに割り当てられる。
【０２２１】  オブジェクトは、観察者から遠い場合には小さく見えるので、テクスチャ・マップはスケール調整し、テクスチャ・パターンが、テクスチャされているオブジェクトに関し同じサイズに見えるようにしなければならない。各フラグメント毎にテクスチャ・イメージをスケーリングしフィルタリングするのは費用の掛かることである。ミップマッピングをすれば、レンダラーは、実行時にこの作業の幾らかを避けることができる。ユーザーは、それぞれが規定されたレベルの詳細度（ＬＯＤ又はλ）でテクスチャを表す、一連のテクスチャ・アレイを継続的に低い解像度で供給する。ＦＲＧが、観察者からの距離に基づいて、各フラグメント毎に詳細な値のレベルを計算し、ＴＥＸが、２つの最も近いミップマップ・アレイの間で補間してそのフラグメントに対するテクスチャ値を作ることを思い出そう。例えば、フラグメントがｌ＝０．５を有していれば、ＴＥＸはｌ＝０とｌ＝１を表す利用可能なアレイの間で補間する。ＴＥＸは、仮想テクスチャ数及びＬＯＤでテクスチャアレイを識別する。
【０２２２】  ＴＭＥＭとＴＥＸの間の正常なパスに加えて、ホスト（ＨＯＳＴ）メモリからＡＧＩ、ＣＦＤ、ＴＭＥＭへの２ＤＧ経由でＴＭＥＭへの、読み取り、書き込み両方のオペレーションに使えるパスがある。ＴＭＥＭは、ＴＥＸが現在使っているテクスチャ・アレイを記憶する。ソフトウェア又はファームウェア・プロシジャはＴＭＥＭを管理し、テクスチャ・アレイをホスト・メモリからＴＭＥＭにコピーする。これは又、テクスチャ・アレイ・アドレスのテーブルをＴＭＥＭに保持する。ＴＥＸは、ＶＳＰパケット内のフィルタ済みテクセルをＰＨＧに送り、ＰＨＧはそれらを解釈する。表１３は、ＴＥＸ−ＰＨＧインタフェースで伝達される信号及びパケットを識別する。
【０２２３】
【表１３】
2004272928.tif 000015
・フォング・シェーディング（ＰＨＧ又はＰＨＢ）１４０００
フォング（ＰＨＧ又はＰＨＢ）ブロック１４０００は、ＤＳＧＰ１０００内でＴＥＸの後、ＰＩＸの前に配置され、各ピクセル・フラグメント毎にフォング・シェーディングを実行する。フォング・シェーディングの総称的形態は当該技術では既知であり、従ってフォング・シェーディングの理論的基礎はここでは詳細には説明せず、関係するアプリケーションで説明する。ＰＨＧは、随意的にではあるが、バンプ・マッピング（ＢＵＭＰ）機能性及び構造を含んでいるのが好ましい。ＴＥＸはＶｓｐパケット内に含まれているテクセル・データだけを送り、ＰＨＧはＶｓｐパケットをＴＥＸから受信するが、ある実施例では、これが３６ビット（３５：０）テクセル・データ・インタフェース・バス経由で行われる。ＦＲＧは（ＶＳＰ内の）フラグメント毎データを、ＭＩＪ経由で送られてきたキャッシュ・フィル・パケットと同様に送る。ある実施例では、キャッシュ・フィル・パケットは、必要になるまでＰＨＧ内のＲＡＭに記憶されていることを述べておく。完全に補間されたスタンプは、ＦＲＧにより、ＦＲＧが受信したと同じ順序で、ＰＨＧに（同様にＴＥＸ及びＰＨＧ内のＢＵＭＰへ）送られる。ＰＨＧは、フル性能ＶＳＰ（Ｖｓｐ−ＦｕｌｌＰｅｒｆ）及び非フル性能ＶＳＰ（Ｖｓｐ−ＮｏｔＦｕｌｌＰｅｒｆ）パケットを、テクスチャＢモード・キャッシュ・フィル・パケット（ＴｅｘＢＦｉｌｌ）、ライト・キャッシュ・フィル・パケット（ＬｔＦｉｌｌ）、材料キャッシュ・フィル・パケット（ＭｔＦｉｌｌ）、開始タイル・パケット（ＢｅｇｉｎＴｉｌｅ）と同じく、ＦＲＧから、ヘッダ及びデータ・バスで受信することを思い出そう。ＭＩＪがカラー、ＴｅｘＡ、ＴｅｘＢ、ライト、及びＰＨＧ（同じくＦＲＧ及びＴＥＸ）用の材料キャッシュのコンテンツの航跡を保持し、適切なキャッシュ・ポインタを、各キャッシュ・ミス・データ・パケットに関連付けることも思い出そう。
【０２２４】  ＰＨＧは、ＭＩＪにより供給された材料及びライティング情報、ＴＥＸよりのテクスチャ・カラー、ＦＲＧにより生成された補間済みデータを使用して、フラグメントの外見上のカラーを决める。ＰＨＧは、ＦＲＧから受信したカラー、材料、ジオメトリ及びライティングに関する情報を、ＴＥＸから受信したテクスチャ情報と組み合わせて、フラグメントのカラーを計算する。結果としてカラー付きのフラグメントが得られ、これがＰＩＸに送られ、そこで、既にフレーム・バッファ（ＦＲＭ）内に存在していた何らかのカラー情報とブレンドされる。ＰＨＧは、基本的にジオメトリ・ベースであり、フレーム、タイル又はスクリーン空間のコンセプトには留意しない。
【０２２５】  ＰＨＧは、ライト・キャッシュ（ＭＩＪからのＬｔキャッシュ・フィル・パケット）、材料キャッシュ（ＭＩＪからの材料キャッシュ・フィル・パケット）及びテクスチャＢ（ＴｅｘＢ）キャッシュ、の３つの内部キャッシュを持っている。
【０２２６】  ＰＨＧにより作られた結果だけがＰＩＸに送られる。この結果は、フラグメントの特性を規定するパケット（カラー・パケット）と、フラグメントの特性を規定するパケット（Ｄｅｐｔｈ＿Ｃｏｌｏｒパケット）と、フラグメントの特性を規定するパケット（Ｓｔｅｎｃｉｌ＿Ｃｏｌｏｒパケット）と、フラグメントの特性を規定するパケット（Ｃｏｌｏｒｉｎｄｅｘパケット）と、フラグメントの特性を規定するパケット（Ｄｅｐｔｈ＿Ｃｏｌｏｒｉｎｄｅｘパケット）と、フラグメントの特性を規定するパケット（Ｓｔｅｎｃｉｌ＿Ｃｏｌｏｒｉｎｄｅｘパケット）を含んでいる。表１４はＰＨＧ−ＰＩＸインタフェースで伝達される信号及びパケットを識別する。
【０２２７】
【表１４】
2004272928.tif 000016
・ピクセル（ＰＩＸ）１５０００
ピクセル（ＰＩＸ）ブロック１５０００は、３Ｄパイプライン内のＢＫＥの前の最後のブロックであり、ＶＳＰを受信するが、そこでは各フラグメントは独立したカラー値を有している。ＰＩＸは、フラグメント毎グラフィクスＡＰＩ、及び、各ピクセル内の各サンプル上での、シザー・テスト、アルファ・テスト、ステンシル・オペレーション、デプス・テスト、ブレンディング、ディザリング、論理演算（例えば、オープンＧＬ仕様書１．１、第４．１節「フラグメント毎オペレーション」参照、但し、ここに参考文献として援用する）を含むその他のオペレーションに責任を持っている。ピクセル所有権テストはウィンドウ・システムの一部（例えば、オープンＧＬ１．１仕様書第４章参照、但し、ここに参考文献として援用する）であり、バックエンドで行われる。ＰＩＸは、１タイル相当の完成したピクセルを蓄積し終えると、サンプルを各ピクセルとブレンド（それによってピクセルのアンチェイリアシングを実行）し、それをバックエンド（ＢＫＥ）ブロック１６０００に送り、フレーム・バッファ（ＦＲＭ）１７０００に記憶させる。このブレンディングに加えて、ＰＩＸは、ピクセルのステンシル・テスティング、アルファ・ブレンディング、アンチエイリアシングを行う。ＰＩＸは、１タイル相当の完成したピクセルを蓄積すると、それをＢＫＥに送ってフレーム・バッファＦＲＭに記憶させる。これらのオペレーションに加えて、ピクセルは、アンチエイリアシングのためのサンプル蓄積を実行する。
【０２２８】  ＰＩＸの前のパイプライン・ステージはプリミティブをＶＳＰに変換する。ＳＲＴは各タイル毎にプリミティブを集める。ＣＵＬはデータをＳＲＴからタイル順に受信し、レンダーされたイメージには決して寄与することのないプリミティブの部分を選別又は除去する。ＣＵＬはＶＳＰを生成する。ＴＥＸ及びＰＨＧは又ＶＳＰを受信するが、それぞれフラグメントのテクスチャリングとライティングに責任を持っている。
【０２２９】  ＰＩＸは、ＭＩＪからＶＳＰ（Ｖｓｐパケット）及びモード・パケット（開始タイル・パケット、開始フレーム・パケット、終了フレーム・パケット、クリア・パケット、ピクセルモード・フィル・パケット、スティップル・フィル・パケット、プリフェッチ開始タイル・パケット、プリフェッチ終了フレーム・パケット及びプリフェッチ開始フレーム・パケット）を受信し、一方ＶＳＰに関するフラグメント・カラー（カラー・パケット、Ｄｅｐｔｈ＿Ｃｏｌｏｒパケット、Ｓｔｅｎｃｉｌ＿Ｃｏｌｏｒパケット、Ｃｏｌｏｒｉｎｄｅｘパケット、Ｄｅｐｔｈ＿Ｃｏｌｏｒｉｎｄｅｘパケット及びＳｔｅｎｃｉｌ＿Ｃｏｌｏｒｉｎｄｅｘパケット）をＰＨＧから受信する。ＰＨＧは又、ＶＳＰに対するフラグメント毎ｚ座標及びステンシル値を供給することができる。
【０２３０】  ＶＳＰに対するフラグメント・カラー（カラー・パケット、Ｄｅｐｔｈ＿Ｃｏｌｏｒパケット、Ｓｔｅｎｃｉｌ＿Ｃｏｌｏｒパケット、Ｃｏｌｏｒｉｎｄｅｘパケット、Ｄｅｐｔｈ＿Ｃｏｌｏｒｉｎｄｅｘパケット及びＳｔｅｎｃｉｌ＿Ｃｏｌｏｒｉｎｄｅｘパケット）は、ＰＩＸに、ＶＳＰが到着すると同じ順で到着する。ＰＩＸは、各可視サンプル用のデータを適用可能なモード・セッティングに従って処理する。ピクセルのアウトプット（ＰｉｘｅｌＯｕｔ）サブユニットはピクセル・サンプルを処理し、ピクセルに対するカラー値、ｚ値、ステンシル値を生成する。ＰＩＸは、現在のタイルに対する全てのスタンプを処理し終わると、ピクセルアウト・サブユニットに信号を送って、タイルに対するそれぞれの値を保持しているカラー・バッファ、ｚバッファ、ステンシル・バッファをＢＫＥに出力させる。
【０２３１】  ＢＫＥは、ＰＩＸによるジオメトリ（ＶＳＰ）のレンダリングに備え現在のタイル・バッファを準備する。これは、現存するカラー値、ｚ値、ステンシル値をフレーム・バッファからロードすることを包含していてもよい。ＢＫＥは、フレーム・バッファに対するＲＡＭ（ＲＤＲＡＭ）メモリ・コントローラを含んでいる。
【０２３２】  ＰＩＸは又、ＭＩＪからＢＫＥ行きの幾つかのパケットを受信する。インプット・フィルタはこれらのパケットを適切にＢＫＥプリフェッチ・キューに送り、パケットはそこで受信順に処理される。ＰＩＸを含め機能ブロックの幾つかは、パケット又は他の信号を選択的にユニットを通過させ、パケット又は他の信号をユニット内で使用するために選択的に「捕捉」する「インプット・フィルタ」を有していることに留意せねばならない。
【０２３３】  幾つかのパケットは又、ピクセル・アウトプット・サブユニットのキューに送られる。先にも述べたように、ＰＩＸはＭＩＪとＰＨＧからインプットを受信する。これら２つのインプットを取り扱うために、２つのインプット・キューがある。ＭＩＪからのデータ・パケットはＶＳＰキューに行き、ＰＨＧからのフラグメント・カラー・パケットとフラグメント・デプス・パケットはカラー・キューに行く。ＰＩＸは又、ＢＫＥ宛の幾つかのパケットを受信することができる。パケットの幾つかは又、ピクセル・アウトプット・サブユニットのインプット・キューにコピーされる。
【０２３４】  ＢＫＥ及びピクセル・アウトプット・サブユニットはパケットを受信順に処理する。ＭＩＪは、データ・パケットを、ＰＩＸインプット先入れ先出し（ＦＩＦＯ）バッファ・メモリに置く。ＰＩＸインプット・フィルタはパケット・ヘッダを調べ、ＢＫＥ宛のデータをＢＫＥに送り、ＰＩＸが必要とするデータ・パケットをＶＳＰキューに送る。ＭＩＪから受信するパケットの大部分はＶＳＰキュー宛であり、幾つかはＢＫＥだけに行き、幾つかはＢＫＥ及びＰＩＸのピクセル・アウトプット・サブユニットに送られると共に、ＶＳＰキューにコピーされる。
【０２３５】  ＰＩＸとＢＫＥの間の通信は、制御ライン及び複数のタイル・バッファ経由で行われ、ある実施例では、タイル・バッファは８つのＲＡＭを備えている。各タイル・バッファは１６ｘ１６バッファで、ＢＫＥが制御する。ＰＩＸはＢＫＥからのタイル・バッファを制御ライン経由で要求し、ＢＫＥは要求されたメモリをフレーム・バッファ（ＦＲＭ）から入手するか、或いはそれを利用できるときに直接割り当てる。するとＰＩＸは、タイル・バッファを何時片づけるかを制御ライン経由でＢＫＥに知らせる。
・バックエンド（ＢＫＥ）１６０００
バックエンド（ＢＫＥ）１６０００はピクセルをＰＩＸから受信し、それをフレーム・バッファ（ＦＲＭ）１７０００に記憶する。ＢＫＥとＰＩＸの間の通信は、上記のように、制御ライン及びタイル・バッファ経由で行われ、パケット化されない。ＢＫＥは又（随意ではあるが、望ましくは）１タイル相当のピクセルをＰＩＸに送り返すが、これは特定のフレーム・バッファ（ＦＲＭ）値がフレームからフレームへと残存することができ、それらを再計算するよりは再使用する方が効率的だからである。例えば、ステンシル・ビット値は多くのフレームで一定であり得、これら全てのフレームで使用できるからである。
【０２３６】  ＦＲＭを制御することに加え、ＢＫＥは２Ｄ描画を行い、完成したフレームを出力装置に送る。ＢＫＥはＦＲＭとディスプレイ（又はコンピュータ・モニタ）及びビデオ・アウトプットの間のインタフェースを提供する。
【０２３７】  ＢＫＥは主として、ＰＩＸと対話して３Ｄタイルを読み書きし、２Ｄグラフィクス・エンジン（ＴＤＧ）１８０００と対話してブリット・オペレーションを実行する。ＣＦＤは、ＢＫＥバスを使ってディスプレイ・リストをＦＲＭから読み取る。ＢＫＥバス（ＢＫＥインプット・バス及びＢＫＥアウトプット・バスを含む）は、ＢＫＥを２次元グラフィクス・エンジン（ＴＤＧ）１８００、ＣＦＤ及びＡＧＩとインタフェースする連絡路であり、ＦＲＭメモリ及びＢＫＥレジスタを読み書きするのに使われる。ＡＧＩは、ＢＫＥレジスタとメモリ・マップド・フレーム・バッファ・データを読み書きする。外部顧客ユニット（ＡＧＩ、ＣＦＤ、ＴＤＧ）はＢＫＥを通してメモリを読み書きする。ＢＫＥの主要機能はａ）３Ｄタイル読み取り、ｂ）ピクセル所有権を使っての３Ｄタイル書き込み、ｃ）書き込み可能及びオーバレイ検出のためのピクセル所有権、ｄ）ピクセル所有権を使ってのスキャンアウト、ｅ）固定比ズーム、ｆ）３Ｄ蓄積バッファ、ｇ）フレーム・バッファ読み書き、ｈ）ウィンドウＩＤ（ｗｉｎｉｄ）マップに対するカラー・キー、ｉ）ＶＧＡ、ｊ）ＲＡＭＤＡＣである。
【０２３８】  ３Ｄ）パイプラインのＢＫＥとの対話は、開始フレーム、開始タイル及び終了フレーム・パケットによって駆動される。これらのパケットのプリフェッチ・バージョンは直接ＳＲＴからＢＫＥに送られるので、タイルはＰＩＸ−ＢＫＥピクセル・バッファにプリフェッチすることができる。
【０２３９】  ＢＫＥは、ｐｉｘＢｕｓ及びプリフェッチ・キューを使ってＰＩＸとインタフェースを取る。ｐｉｘＢｕｓは各方向６４ビットバスで、ピクセル・バッファを読み書きするのに使われる。各々が単一のタイルに対し３２ビットのカラー又はデプス値を保持しているピクセルバッファが８個まである。ウィンドウが使用可能なカラー面とデプス面を両方有している場合、２つのバッファが割り当てられる。ＢＫＥは１度に単一のバッファを読み書きする。ＢＫＥは、最初にカラー・バッファを書き込み、次に必要であればデプス・バッファ値を書き込む。ＰＩＸは、開始フレーム及び開始タイル・パケットをプリフェッチ・キューから受信する。これらのパケットは３Ｄパイプライン・ユニットをバイパスし、タイル・バッファのプリフェッチを実行可能とする。パケットは、この目的で複写され、残りのユニットはこれを、他のＶＳＰ及びモード・パケットの順で受信する。開始フレーム及び開始タイル・パケットに加えて、ＢＫＥは、主にプログラム可能割り込みを送るのに使われるフレーム・パケットの最後を受信する。ピクセル所有権ユニット（ＰＯＢｏｘ）は全ての必要なピクセル所有権機能を実行する。これは、３Ｄタイル書き込みのための、ピクセル書き込みマスクを提供する。これは又、スキャンアウト上にオーバレイ（オフスクリーン）バッファがあるかどうかを決める。これは６４ウィンドウのパラメータを保持するウィンドウＩＤテーブルを含んでいる。１６の境界画定ボックス（ＢＢ）のセットと８ビットＷｉｎＩＤマップのピクセル毎メカニズムは、ピクセル所有権を決めるのに使用される。１度に１６ピクセルまでのピクセル所有権は、単一のオペレーションとして実行できる。２ＤＧ及びＡＧＩは、ｂｋｅＢｕｓを使ってレジスタの読み書きができる。これらのレジスタは通常３Ｄ独立レジスタである。３Ｄパイプと同期するレジスタの更新は、モード・オペレーションとして行われ、或いは開始又は終了パケットにセットされる。ＣＦＤは、ｂｋｅＢｕｓを使って、フレーム・バッファ常駐のコンパイル済みディスプレイ・リストと、差し込まれた頂点アレイを読み取る。ＣＦＤは、大きなリストを読み取る際には、１度に４デュアルオクト（６４バイト）の読み取り要求を発行する。ＴＤＧは２Ｄビルト用のフレーム・バッファを読み書きする。ソースと宛先は、ホスト・メモリ、フレーム・バッファ、テクスチャ・メモリ用の補助リング、ＧＥＯ及びＣＦＤ用のコンテクスト・スイッチ状態でもよい。
【０２４０】  ある実施例では、ＢｋｅＢｕｓは、僅かなハンドシェーキング信号付きの７２ビット・インプットと６４ビット・アウトプットのバスである。仲裁はＢＫＥによって行われる。１度に唯１つだけのユニットがバスを所有できる。バスは完全にパイプライン化されており、多くの要求は、オンザフライで、どんな所与のサイクルであってもよい。ＢＫＥを通してメモリの読み書きを行う外部顧客ユニットはＡＧＩ及びＴＤＧであり、ＣＦＤはフレーム・バッファから、ＡＧＩのｂｋｅＢｕｓインタフェース経由で読み取る。ＭｅｍＢｕｓはフレーム・バッファ・メモリにアクセスするのに使われる内部バスである。
【０２４１】  ＢＫＥは効率よくフレーム・バッファを所有又は制御し、フレーム・バッファにアクセス（読み書き）する必要のある何れの他のユニットもＢＫＥと通信しなければならない。ＰＩＸは、既に説明したように、制御信号とタイル・バッファ経由でＢＫＥと通信する。ＢＫＥは、従来型のメモリ通信手段経由でＦＲＭ（ＲＡＭＢＵＳ  ＲＤＲＡＭ）と通信する。２ＤＧブロックは、同じくＢＫＥと通信し、データをフレーム・バッファに押し込み、データをフレーム・バッファから引き出し、データを他の場所に伝達することができる。
・フレーム・バッファ（ＦＲＭ）１７００
フレーム・バッファ（ＦＲＭ）１７００は、２Ｄ及び３Ｄウィンドウに関係する全てのカラー及びデプス値を保持するＢＫＥにより制御されるメモリである。これは、リフレッシュ速度でピクセル・カラーをスキャンアウトすることによりモニタ上に表示されるスクリーン・バッファを含んでいる。これは又、オフスクリーン・オーバレイ、及び．ｂｕｆｆｅｒｓ（ｐバッファ）、ディスプレイ・リスト及び頂点アレイ、蓄積バッファも保持している。スクリーン・バッファ及び３Ｄｐバッファは、デュアル・バッファされていてもよい。ある実施例では、ＦＲＭは、ＲＡＭＢＵＳ  ＲＤランダム・アクセス・メモリを備えている。
・２次元グラフィクス（ＴＤＧ又は２ＤＧ）１８０００
２次元グラフィクス（ＴＤＧ又は２ＤＧ）ブロック１８０００は２次元グラフィクス・エンジンとも呼ばれ、２次元グラフィクス（２Ｄグラフィクス）プロセッシング・オペレーションに責任を持っている。ＴＤＧは本発明のパイプラインの随意的部分であり、２次元データを処理するための別のオペレーション・ユニットと考えることもできる。
【０２４２】  ＴＤＧは主に、バス・インタフェースＡＧＩユニット、フロントエンドＣＦＤユニット及びバックエンドＢＫＥユニットと対話する。最も望ましい場合（ＰＵＬＬ）には、全ての２Ｄ描画コマンドがＣＦＤユニット（ＡＧＰマスター又は高速書き込み）を通って渡される。低性能の場合（ＰＵＳＨ）には、コマンドはＡＧＩ（ＰＩＯモードの場合はＰＣＩスレーブ）からプログラムできる。読み取られたレジスタ又はメモリからの返却データはＡＧＩに送られる。一方、メモリを読み書きするために、ＴＤＧはメモリ要求パケットを（アドレス、データ及びバイト使用可能を含め）ＢＫＥに送り、或いはＢＫＥから読み取りメモリ返却データを受信する。補助リング・コマンドを処理するため、ＴＤＧはリング上の誰とでも対話する。
【０２４３】  最初にＢＫＥへのあるインプット・パケットを説明する。ＡＧＩからのインプットとして受信される２Ｄソース要求及びデータ返却パケットは、ＡＧＰメモリに対する２Ｄデータの引き込み／押し出しを取り扱うために使われる。ＡＧＩからのインプットとして受信されるＰＣＩパケットは、全てのスレーブ・モード・メモリ又はＩ／Ｏ読み書きアクセスを取り扱うために使われる。ＣＦＤからのインプットとして受信される２Ｄコマンド・パケットは、フォーマット済みコマンドを送るのに使われる。ＢＫＥからのインプットとして受信されるフレーム・バッファ書き込み要求認知及び読み取り返却データ・パケットは、早期フレーム・バッファ読み取り要求に応えて、ＢＫＥから返却されたＤＲＤＲＡＭデータを送るのに使われる。ＢＫＥからのインプットとして受信される補助リング・インプット・パケットは、ユニットからユニットへと一方向に動く。ＴＤＧはそれをＢＫＥから受信し、適切な行動をとり、このパケット又は新しいパケットを次のユニットＡＧＩに渡す。
【０２４４】  ＡＧＩに送られる２ＤＡＧＰデータ要求及びデータ・アウト・パケットは、ＡＧＰマスター読み書き要求をＡＧＩに送り、書き込み要求、ＡＧＩへのデータ・アウトプット・パケットを追跡するのに使われる。ＡＧＩに送られるＰＣＩ書き込み認知及び読み取り返却データ・パケットは、ＰＣＩメモリ又はＩ／Ｏ書き込みデータの受取の認知に使われ、ＰＣＩメモリ又はＩ／Ｏ読み取りデータの返却も取り扱う。ＡＧＩに送られる補助リング・アウトプット・パケットは、ユニットからユニットへと一方向に動き、ＴＤＧはそれをＢＫＥから受信し、適切な行動をとり、このパケット又は新しいパケットを次のユニットＡＧＩに渡す。ＣＦＤに送られる２Ｄコマンド認知パケットは、ＣＦＤからのコマンドの受取を認知するために使われる。ＢＫＥに送られるフレーム・バッファ読み書き要求及び読み取りデータ認知パケットは、フレーム・バッファ読み取り又は書き込みコマンドをＢＫＥに送る。読み取りに関し、アドレス及びバイト使用可能ラインが使われ、書き込みに関しては、コマンド・データ・ラインが意味がある。
【０２４５】  本発明のある特定の実施例では「３Ｄ内２Ｄ」インプリメンテーションのサポートが、ＢＫＥユニットからの（「トゥイーン」パケットと呼ばれる）パススルー２Ｄコマンドを使って、便利に設けられている。ＢＫＥからのインプットとして受信される２Ｄパススルー・コマンド（トゥイーン）パケットは、３Ｄパイプライン内にあるフォーマット済みの２Ｄ描画コマンド・パケットを送るのに使われる。ＢＫＥに送られる２Ｄコマンド・パススルー（トゥイーン）認知パケットはＢＫＥからのコマンド・データの受取の認知に使われる。
・ディスプレイ（ＤＩＳ）
ディスプレイ（ＤＩＳ）は、別のモニター又はディスプレイ装置と考えられ、特に、最終のディジタル・インプットからアナログ信号を生成するための信号調整回路がＢＫＥ／ＦＲＭに設けられているときにはそうである。
・マルチチップ・アーキテクチャ
ある実施例では、本発明の構造が３つの別々のチップ（チップ１、チップ２、チップ３）プラス追加のメモリ・チップのセットの上に配置されている。チップ１は、ＡＧＩ、ＣＦＤ、ＧＥＯ、ＰＩＸ、ＢＫＥを含んでいる。チップ２は、ＭＥＸ、ＳＲＴ、ＳＴＰ、ＣＵＬＬを含んでいる。チップ３は、ＦＲＧ、ＴＥＸ、ＰＨＧを含んでいる。ＰＭＥＭ、ＳＭＥＭ、ＴＭＥＭ、ＦＲＭは別々のチップ上に設けられている。チップ間通信リングが、各チップ上のユニットを連結して通信できるようにするために設けられている。本発明の別の実施例では、全ての機能ブロックが、メモリ（ＰＭＥＭ、ＳＭＥＭ、ＴＭＥＭ他）をも含む単一のチップ（共通半導体基板）上に設けられており、或いは、メモリが別々のチップ又はチップのセット上に設けられている場合もある。
ＩＩＩ．コマンド・フェッチ及びデコード機能ブロック（ＣＦＤ）の詳細な説明概要
ＣＦＤブロックは、ＡＧＰインタフェースとピクチャを実際に描くハードウェアとの間のユニットである。殆ど数学的ではないが、沢山の制御及びデータ移動ユニットがある。ＣＦＤブロックが行うことの大部分は、データを他のブロックへ送ることである。２Ｄ、３Ｄ、バックエンド及びリングへのコマンド及びテクスチャはＡＧＰバスを横切って来て、フロント・エンドによりそれらを消費するユニットへ送られる。ＣＦＤは、コマンドを幾らかデコード及びアンパックし、ＡＧＰインタフェースを管理し、ＤＭＡ転送に巻き込まれ、幾つかの状態をコンテクスト・スイッチのために保存する。これは最も魅力的ではないものの１つであるが、ＤＳＧＰシステムの最も基本的構成要素である。
【０２４６】  図１８は、ＣＦＤブロック２０００内の主要な機能ユニットを示すパイプラインのブロック線図である。ＤＳＧＰグラフィクス・システムのフロント・エンドは、ＡＧＩブロックとＣＦＤブロックの２つのサブユニットに分割されている。この節の残りは、ＣＦＤブロックのアーキテクチャを説明することに関係している。何度もＡＧＩに言及されるが、それはＣＦＤがＡＧＩに関係する要件のコンテクストにある。
サブブロックの説明
読み書き制御
ＡＧＩは、ＡＧＰ又はＰＣＩ読み書きトランザクションを済ませると、データを読み書き制御２０１４に移す。書き込みの場合、この機能ユニットはあるアドレスを使用するが、それはデータをその物理アドレスに対応するレジスタ又はキューに多重送信する（詳細はアドレス空間を参照）ために受信したアドレスである。読み取りの場合、デコーダは、読み取りトランザクションが完了できるように、データを適切なレジスタからＡＧＩブロックに多重送信する。
【０２４７】  読み書き制御は、ＣＦＤアドレス空間内の全ての可視レジスタに対し読み書きすることができ、２Ｄ及び３Ｄコマンド・キュー２０２２、２０２６に書き込むことができ、バックエンド・インプット・バス２０３６を横切って読み取り及び書き込みを転送することもできる。
【０２４８】  読み書きデコーダは、読み取り専用又は存在しないレジスタに対する書き込みを受信した場合は、アクセス違反割り込みをトリガするよう要求した割り込みジェネレータ２０１６にメッセージを送らなければならない。読み書きデコーダにはその書き込みに対しそれ以上の責任はないが、更に読み取り及び書き込みを受け付け続けなければならない。
【０２４９】  読み書きデコーダは、書き込み専用又は存在しないレジスタに対する読み取りを受信した場合は、読み取りトランザクションを丁重にキャンセルしなければならない。そして、割り込みジェネレータにメッセージを送り、アクセス違反割り込みを生成しないように要求しなければならない。読み書きデコーダにはその読み取りに対しそれ以上の責任はないが、更に読み取り及び書き込みを受け付け続けなければならない。
２Ｄコマンド・キュー
ＤＳＧＰグラフィクス・ハードウェアに対するコマンドは、可変待ち時間を有しており、ホストからバーストに渡されるので、ＡＧＩと２Ｄの間には数キロバイトのバッファリングが必要である。このバッファは３Ｄ用のコマンド・バッファの数分の１の大きさでよい。このサイズは、ＡＧＩを横切るコマンド送付速度と２Ｄによる性能モードのコマンド実行速度との間の不等を平滑化するように決められなければならない。
【０２５０】  このキューは、オーバランを防ぐためにフロー制御されている。２Ｄ高水位マーク・レジスタが存在し、これは、ホストにより数多くのエントリがキュー内に許されるようにプログラムされている。この多数のエントリが一杯になるか又はこれを越える事態が生じると、２Ｄ高水位割り込みが生成される。ホストはこの割り込みを得ると直ぐに、高水位割り込みを使用禁止とし、低水位割り込みを使用可能とする。キュー内に、２Ｄ低水位マーク・レジスタ内にあるよりも少数のエントリしかない場合、低水位割り込みが生成される。高水位割り込みが受信されてから低水位が受信されるまでの間、ドライバは、一杯に近いコマンド・バッファに対し書き込みが行われのを防ぐ責任がある。
３Ｄコマンド・キュー
ＡＧＩと３Ｄコマンド・デコード２０３４の間にも数キロバイトのバッファリングが必要である。このサイズは、ＡＧＩを横切るコマンド送付速度とＧＥＯブロックによる性能モードのコマンド実行速度との間の不等を平滑化するように決められなければならない。
【０２５１】  このキューは、オーバランを防ぐためにフロー制御されている。３Ｄ高水位マーク・レジスタが存在し、これは、ホストにより数多くのエントリがキュー内に許されるようにプログラムされている。この多数のエントリが一杯になるか又はこれを越える事態が生じると、３Ｄ高水位割り込みが生成される。ホストはこの割り込みを得ると直ぐに、高水位割り込みを使用禁止とし、低水位割り込みを使用可能とする。キュー内に、３Ｄ低水位マーク・レジスタ内にあるよりも少数のエントリしかない場合、低水位割り込みが生成される。高水位割り込みが受信されてから低水位が受信されるまでの間、ドライバは、一杯に近いコマンド・バッファに対し書き込みが行われのを防ぐ責任がある。
３Ｄコマンド・デコード
コマンド・デコード２０３４は、３ＤＣｍｄキュー２０２６及び３Ｄ応答キュー２０２８からのコマンドを読み取り、解釈し、それを再フォーマットされたパケットとしてＧＥＯブロックに送る責任を持っている。デコーダは「高速」コマンドを、それをＧＥＯブロックに供給するか又はそれが変える状態をシャドウする前に、データ変換する。３Ｄコマンド・デコードは、フォーマット変換ができなければならない。インプット・データ・フォーマットはＡＰＩにより許可される全てのもの（一般的には、Ｃ言語又は他のプログラミング言語により許可される全てのもの）を含んでいる。３Ｄコマンド・デコードからのアウトプット・フォーマットは、ハードウェアにより処理することのできるものに限られ、一般的に、浮動小数点か「カラー」フォーマットかの何れかである。カラー・データ・フォーマットの正確なビット定義は、カラーがパイプラインの残りを通してどのように表されるかによる。
【０２５２】  コマンド・デコードは、３Ｄコマンド・キューからのパワーアップ読み取りで開始する。ＤＭＡコマンドが検出されると、コマンド・デコーダはＤＭＡコントローラ２０１８にコマンドとデータを送る。ＤＭＡコントローラは、要求されたデータを３Ｄ応答キューに転送開始する。次に３Ｄコマンド・デコーダは、３Ｄ応答キュー内のデータを正常なコマンド・ストリームとして解釈して、３Ｄ応答キューからのＤＭＡコマンドに規定されているだけの数のバイトを読み込む。３Ｄコマンド・デコーダは、ＤＭＡコマンドに規定されているだけの数のバイトを読み込み終えると、通常のコマンド・キューからの読み込みに戻る。３Ｄ応答キューからの読み込みの間、全てのＤＭＡコマンドは無効コマンドと考えられる。
【０２５３】  この３Ｄコマンド・デコーダは、無効コマンドを検出する責任を持っている。無効コマンドはすべて、結果として無効コマンド割り込みの生成（詳細は割り込み制御参照）に終わらなければならない。
【０２５４】  ３Ｄコマンド・デコーダは又、頂点コマンドがキュー内で検出されたときに頂点パケットを送るために、要求される現在の状態ベクトルを解釈しセーブする。更に、現在の「開始」の内側の３つの完了した頂点（オープンＧＬ仕様書参照）とそれに関係する状態を、最後に出会った「開始」の種類と共に思い出す。コンテクストが切り替えられると、３Ｄコマンド・デコードは、これらのシャドウ済み値をホストが読み出せるようにするので、ホストは、コンテクストを後に再び開始する、「パイプを再び準備する」ことができる。
ＤＭＡコントローラ
ＣＦＤ  ＤＭＡコントローラ２０１８は、ＤＳＧＰカードに対する全てのＤＭＡトランザクションを開始し維持する責任がある。ＤＳＧＰは常にあらゆるＤＭＡ転送のマスターであり、ＤＭＡコントローラがスレーブである必要はない。２Ｄエンジンと３Ｄコマンド・デコーダは、ＤＭＡコントローラのマスターになろうと争う。２ＤブロックだけがＤＭＡ書き込みを開始できるが、ＤＭＡの書き込み及びＤＭＡの読み取りは共にサポートされる。ＤＳＧＰは常にＤＭＡのマスターである。
【０２５５】  ＤＭＡ転送は以下のように開始される。ＤＭＡコマンドは、開始位置の物理アドレス及び転送するバイトの数と共に、２Ｄ又は３Ｄコマンド・キューの何れかに書き込まれる。そのコマンドを３Ｄコマンド・デコーダ又は２Ｄユニットが読むと、ＤＭＡの要求はデータと共にＤＭＡコントローラに送られる。２ＤによるＤＭＡ書き込みの場合、２Ｄユニットは、データを、ホストへの書き込みキュー２０２０に置き始める。ＤＭＡコントローラは、前のＤＭＡを全て終えると、ＤＭＡの要求を認知して、データを転送し始める。ＤＭＡがＤＭＡ書き込みである場合、コントローラは、データを、ホストへの書き込みキューから、ＡＧＩ経由でシステム・メモリに移すか、或いは、バックエンド・インプット・バス経由でフレームバッファに移す。ＤＭＡがＤＭＡ読み取りである場合には、コントローラは、データを、システム・メモリからＡＧＩ経由で、或いは、バックエンドからバックエンド・アウトプット・バス２０３８経由での何れかで、２Ｄ応答キュー又は３Ｄ応答キューの何れかに引き込む。コントローラは、要求された数のバイトを転送し終わると、ＤＭＡの要求を解放して、要求しているユニットがコマンド・キューから次のコマンド読み取れるようにする。
【０２５６】  ＤＭＡコントローラは、読み書きに整列しているノンキャッシュ・ラインにトランザクションを開始させ（必要なら）その後、転送の残りがキャッシュ・ラインより短くなるまでキャッシュ・ライン転送を行うことによって（ＡＧＰ性能最大化ホワイト・ペーパーにより推奨されているように）ＡＧＰロジックの性能を最大化するよう努めなければならない。
２Ｄ応答キュー
２Ｄ応答キューは、２Ｄブロックによって始められたＤＭＡ読み取りからのデータの集積所である。ＤＭＡの要求が送られた後、２Ｄエンジンは、コンテンツを２Ｄコマンド・キュー内のコマンドと同じに扱いながら、２Ｄ応答キューから読み取る。唯一の拘束条件は、応答キュー内でＤＭＡコマンドと出会ったときには、それを無効コマンドとして取り扱わなければならないことである。現在のＤＭＡコマンドに規定してある数のバイトを応答キューから読み取った後、２Ｄエンジンは２Ｄコマンド・キューからのコマンドの読み取りに戻る。
３Ｄ応答キュー
３Ｄ応答キューは、３Ｄコマンド・デコードによって始められたＤＭＡ読み取りからのデータの集積所である。ＤＭＡの要求が送られた後、コマンド・デコードは、コンテンツを３Ｄコマンド・キュー内のコマンドと同じに扱いながら、３Ｄ応答キューから読み取る。唯一の拘束条件は、応答キュー内でＤＭＡコマンドと出会ったときには、それを無効コマンドとして取り扱わなければならないことである。現在のＤＭＡコマンドに規定してある数のバイトを応答キューから読み取った後、３Ｄコマンド・デコードは３Ｄコマンド・キューからのコマンドの読み取りに戻る。
ホスト・キューへの書き込み
ホスト・キューへの書き込みは、２ＤがＤＭＡを通してホストに書き込みたいデータを含んでいる。２Ｄは、システム・メモリ外に行くＤＭＡ転送を要求した後、ホスト・キューを、リング又はバックエンドから来たデータで満たす。この小さなバッファを持っているので、ＤＭＡエンジンは、データを動かすピークＡＰＧ性能を達成することができる。
割り込みジェネレータ
ホストとＤＳＧＰボードとの間の通信の重要な部分は、割り込みによって行われる。割り込みは、一般的に、滅多に起きないイベント及び通常のオペレーションにとっての例外を表示するのに使われる。ホストがレジスタを読んで、どの割り込みに割り込みを起こさせるかを決めることができるようにするボードには、２つの割り込み原因レジスタがある。原因レジスタの１つは、エントレースのような専用の割り込みのために確保され、もう１つは、カーネルによって割り当てられる総称的割り込みのためのものである。このそれぞれに関し、ホストがレジスタにアクセスするために読むことのできる２つの物理アドレスがある。第１のアドレスはポーリングのためのもので、割り込み原因レジスタ内のデータには影響を及ぼさない。第２のアドレスは割り込みサービスのためのもので、読み込まれると自動的に割り込みをクリアする。従ってホストは、オンになると読み込んで帰る全ての割り込みにサービスする責任がある。割り込み原因レジスタそれぞれに対し、原因内のそのビットが０ｐ１移行を作り出したときに割り込みが生成されたかを決める割り込みマスク・レジスタがある。
【０２５７】  ＤＳＧＰは割り込みに対する６４までの異なる原因をサポートするが、その幾つかは固定されており、又幾つかは総称的である。以下にリストするのはその簡単な説明である。
リトレース
リトレース割り込みは毎秒約８５−１２０回生じ、バックエンド・ハードウェアにより、モニタの垂直帰線消去期間内のある点で起こされる。正確なタイミングは、バックエンド・インプット・バスでのレジスタ書き込みを通してバックエンド・ユニット内にプログラムされる。
３ＤＦＩＦＯ高水位
３ＤＦＩＦＯ高水位割り込みは、パイプが性能モードでランしている時には滅多に生じないが、３Ｄパイプラインが低性能でランしているときにはしばしば起こる。カーネル・モード・ドライバは、３ＤＣｍｄバッファ内に許されるエントリの数を示す３Ｄ高水位エントリ・レジスタをプログラムする。バッファ内にこれより多いエントリがある場合には何時でも、高水位割り込みがトリガされる。するとカーネル・モード・ドライバは割り込みを巧く捌くように要求され、３Ｄバッファをオーバーフローさせる恐れのある書き込みが起こるのを防止する。割り込みハンドラでは、カーネルが、パイプが高水位マーク下のドレインに近いかどうかをチェックする。近くなければ、高水位割り込みを使用禁止とし、低水位割り込みを使用可能とする。
３ＤＦＩＦＯ低水位
３ＤＦＩＦＯ低水位割り込みが使用可能な場合、３ＤＦＩＦＯ内のエントリの数が３Ｄ低水位エントリ・レジスタ内の数より少なければ、割り込みが生成される。これは、３ＤＦＩＦＯがプログラムを再び３ＤＦＩＦＯに書き込めるほど十分に安全にクリアされたという信号をカーネルに送る。
【０２５８】２ＤＦＩＦＯ高水位
これは、２ＤＦＩＦＯをモニタすることを除いて、３ＤＦＩＦＯ高水位割り込みと正確に同じである。２ＤＦＩＦＯ高水位割り込みは、パイプが性能モードでランしている時には滅多に生じないが、２Ｄパイプラインが低性能でランしているときにはしばしば起こる。カーネル・モード・ドライバは、２ＤＣｍｄバッファ内に許されるエントリの数を示す２Ｄ高水位エントリ・レジスタをプログラムする。バッファ内にこれより多いエントリがある場合には何時でも、高水位割り込みがトリガされる。するとカーネル・モード・ドライバは割り込みを巧く捌くように要求され、２Ｄバッファをオーバーフローさせる恐れのある書き込みが起こるのを防止する。割り込みハンドラでは、カーネルが、パイプが高水位マーク下のドレインに近いかどうかをチェックする。近くなければ、高水位割り込みを使用禁止とし、低水位割り込みを使用可能とする。
２ＤＦＩＦＯ低水位
２ＤＦＩＦＯ低水位割り込みが使用可能な場合、２ＤＦＩＦＯ内のエントリの数が２Ｄ低水位エントリ・レジスタ内の数より少なければ、割り込みが生成される。これは、２ＤＦＩＦＯがプログラムを再び２ＤＦＩＦＯに書き込めるほど十分に安全にクリアされたという信号をカーネルに送る。
アクセス違反
存在しないレジスタに対する読み書きがある場合には何時でも、これがトリガされねばならない。
無効コマンド
不要コマンドがＦＩＦＯ内で検出された場合（可能であれば）又は特権コマンドがユーザー・プログラムによりＦＩＦＯに書き込まれた場合には何時でも、これがトリガされねばならない。カーネルはこの割り込みを巧く捌き、この違反タスクを除かなければならない。
テクスチャ・ミス
この割り込みは、テクスチャ・ユニットがテクスチャ・メモリにロードされていないテクスチャにアクセスしようとしたときに生成される。テクスチャ・ユニットはリングを横切って割り込み原因レジスタに書き込みを送り、この書き込みにテクスチャ・ミスＩＤレジスタへのリング書き込みの前文を付ける。カーネルはこの割り込みを巧く捌いて、テクスチャ・ミスＩＤレジスタを読み、どちらのテクスチャがミスしているのかを決め、テクスチャＤＭＡをセットアップしてテクスチャをダウンロードし、テクスチャＴＬＢを更新し、それから割り込みをクリアする。
総称的割り込み
割り込み原因レジスタ内の割り込みの残りは総称的なものである。総称的割り込みは、ソフトウェアが、それが済むとメッセージをその割り込み番号を生じさせた割り込みジェネレータに送ることになるコマンドを送ることによりトリガされる。これらの割り込みは全て、２Ｄ又は３Ｄパイプラインの何れかから来て、バックエンド・ユニットの底部に至る所与のコマンドによって生成される。バックエンドは書き込みを、専用線経由で割り込み原因レジスタに送る（これは同一チップ上にあるので、リングを使うのは過剰行為である）。
ＩＶ．モード抽出（ＭＥＸ）及びモード注入（ＭＩＪ）機能ブロックの詳細な説明
【０２５９】詳細な説明
本願に参考文献として援用する、ライサー社に譲渡された米国仮特許出願番号第６０／０９７，３３６号はこれまでになく新しいグラフィクス・プロセッサに関するものである。当該特許出願では、パイプライン状態データ（「モード」データとも称される）が、効率の高いパイプライン処理及びアーキテクチャを提供するために、抽出されその後注入されることについて説明している。当該特許出願は、ラスタライゼーション処理に先立ち陰面が除去され、それにより最終的にレンダされたイメージに影響しないと既に判断されているピクセルについてはコンピュータ処理的に高価なピクセル毎計算を実行しないということにして性能を著しく向上させている、これまでにない新しいグラフィクス・プロセッサについて説明している。
システム概観
従来型グラフィックス・パイプラインでは、状態変更はインクレメンタルであり、即ち、状態パラメータの値はそれが変更されるまでは有効であり、その変更は古い値がもはや必要でなくなったということからそれら古い値の上に単純に上書きするというだけのものである。更に、レンダリングは線形であり、即ちプリミティブは、各プリミティブが受信される時に有効なパイプライン状態を使用して、受信順に（最終的なピクセル・カラーへのラスタライゼーションを含めて）完全にレンダされる。ポイント、ライン、三角形、及び四辺形等はグラフィカル・プリミティブの例である。プリミティブは、最も一般的な例を挙げるなら、個別のポイント、独立したライン、独立した三角形、三角形ストリップ、三角形ファン、多角形、クオッド、独立したクオッド、又はクオッドストリップ、としてグラフィクス・パイプラインに入力できる。こうして、状態変更は、あるプリミティブに関する空間情報（即ち完成頂点）が受信されるまで累積され、それら累積された状態は当該プリミティブのレンダリング中有効である。
【０２６０】  従来型グラフィックス・パイプラインとは対照的に、本発明のパイプラインは陰面除去後までラスタライゼーションを延期（本システムはデファードシェーダと呼ばれることもある）する。それぞれがパイプライン状態の特定のセッティングに対応している多数のプリミティブがグラフィクス・パイプラインに送られてくるので、ラスタライゼーション・プロセスにより使用されるまで、パイプライン状態情報の多数のコピーが記憶されなければならない。本発明による革新は、パイプライン状態情報の多数のコピーを記憶、検索、管理するための能率的方法及び装置にある。本発明の重要な革新の一つは、図Ｂ３に示すように、パイプラインのデータ・フローを分割してその後併合するというものである。分離はデータ・フローにおいてＭＥＸステージにより行なわれ、これにより状態情報と空間情報をそれぞれに対応しているメモリに独立的に記憶できるようになる。併合はＭＩＪステージで実行され、それにより多角形の可視（即ち隠れていると保証されていない）部分が状態情報の必要部分だけを伴ってパイプラインに送り込まれるようになる。図Ｂ４の代わりの実施例では、タイルによるソートとタイルによる読み取りのための追加的ステージが加わっている。後で述べるが、状態情報と空間情報という単純分割が最適であるのではなくて、本発明の又他の実施例に関連してより最適化された分割を説明する。
【０２６１】  本発明の実施例についてこれより説明する。図Ｂ５を参照すると、ＧＥＯ（即ちジオメトリ）ブロックは、グラフィクス・パイプラインの先頭で最初の計算ユニットとなっている。ＧＥＯブロックは、順番にプリミティブを受信して、頂点オペレーション（例えば、変換、頂点ライティング、クリッピング、及びプリミティブ・アセンブリ）を実行し、データをパイプラインに流す。ＡＧＬ（即ち「アドバンスト・グラフィック・インターフェース」）及びＣＦＤ（即ち「コマンドフェッチ・アンド・デコード」）ブロックから成るフロント・エンドは、グラフィック・ハードウェア・コマンドのフェッチング（通常、ＰＩＯ、プログラムされた入力／出力、又はＤＭＡ即ちダイレクト・メモリ・アクセスによる）とデコーディングに従事する。フロント・エンドは、必要な変換マトリクス、材料及びライト・パラメータ、及び他のパイプライン状態セッティングを、ＧＥＯブロックの入力レジスタにロードする。ＧＥＯブロックは、変換された頂点座標、法線、生成された及び／又は通過したテクスチャ座標、頂点毎のカラー、材料セッティング、ライト位置及びパラメータ、及び他のシェーディング・パラメータ及び演算子のような多岐にわたるデータをパイプラインに送り込む。図Ｂ５は単なる１実施例であり、他の実施例も考えられるものと理解されたい。例えば、ＣＦＤとＧＥＯは、ソフトウェア・ドライバで行なわれるオペレーション、アプリケーション・プログラム、又はオペレーティング・システムに代えることもできる。
【０２６２】  ＭＥＸ（即ち「モード抽出」）ブロックはＧＥＯブロックとＳＲＴブロックの間にある。ＭＥＸブロックはパイプライン状態セッティングのセットをセーブし、それらを対応するプリミティブに関連付けることに責任を負う。モード注入（ＭＩＪ）ブロックはプリミティブに関連付けられた状態及び他の情報を必要な時に（以後、概括的にカラー・ポインタ及び材料、ライト及びモード（ＭＬＭ）ポインタと称することにする種々のポインタを介して）検索する責任を負う。ＭＩＪは又、当てはまる場合には、情報の再パッケージングにも責任を持つ。再パッケージングは、例えば、多角形メモリ中の頂点データが検索され、ＦＲＧブロック用に三角形入力パケットに束ねられる場合などに発生する。
【０２６３】  ＭＥＸブロックはＧＥＯブロックからデータを受信して、そのデータ・ストリームを２つの部分、即ち１）陰面除去に必要な頂点及びあらゆる情報（図Ｂ６のＶ１、Ｓ２ａ、及びＳ２ｂに示すような）を含む空間データと、２）他のすべての（図Ｂ６のＶ２及びＶ３に示すような）ものとに分ける。空間データはＳＲＴ（即ち「ソート」）ブロックに送られ、ここでその空間データをソート・メモリと呼ばれる特別なバッファに記憶する。上記「他のすべてのもの」即ち、ライト位置とパラメータ及び他のシェーディング・パラメータ及び演算子、カラー、テクスチャ座標等は、多角形メモリと呼ばれる別の特別なバッファに記憶され、そこでは、これらをＭＩＪ（即ち「モード注入」）ブロックにより検索することができる。ある実施例では、多角形メモリはマルチ・バッファされているので、ＭＩＪブロックが１つのフレームにつき読み出し作業を行なう一方で、その間ＭＥＸブロックは別のフレームにつきデータを記憶することができる。多角形メモリに記憶されたデータは、３つの主なカテゴリ、即ち１）フレーム毎データ（フレームの間に数回変更するのが一般的であるライティングのようなもの）、２）オブジェクト毎データ（シーン中の各オブジェクト毎に異なるのが一般的である材料特性のようなもの）及び３）頂点毎データ（フレーム中の各頂点毎に異なる値を有するのが一般的なカラー、面法線、テクスチャ座標のようなもの）に分けられる。所望されるなら、効率を上げるためにＭＥＸとＭＩＪブロックはこれらのカテゴリを更に分割する。メモリ使用を最小限にし、又は代わりにデータ伝送を最小限にすれば、アーキテクチャはより効率的になろう。選定されたカテゴリはこれらに影響を及ぼすことになる。
【０２６４】  各頂点毎に、ＭＥＸブロックはＳＲＴブロックに空間データを保有しているソート・パケットを送り、多角形メモリにポインタを送る。（ポインタはカラーポインタと呼ばれるが、カラーに加えて情報を検索するのに使用されるものなので、これは幾分誤解を招く呼び方である。）ソート・パケットは、頂点が、ポイントを表しているのか、ラインのエンド・ポイントを表すのか、又は三角形のコーナーを表しているのかを表示するフィールドも保有している。オープンＧＬ及びＤ３Ｄのような、順序依存型ＡＰＬ（アプリケーション・プログラム・インターフェース）に応ずるために、頂点は厳格な時間順序、つまりそれらがパイプラインに供給されたのと同じ順序で送信される。（ある順序依存型ＡＰＩに関しては、時系列を摂動させることもできる。）パケットは現在の頂点が所与のプリミティブの最後の頂点（即ち、「プリミティブ」を完成しようとしている）か否かも規定する。三角形ストリップ又はファン、及びライン・ストリップ又はループの場合には、頂点は隣接するプリミティブの間で共有される。この場合、パケットは各プリミティブ中の他の頂点をどうやって識別するかを表示する。
【０２６５】  ＳＲＴブロックはＭＥＸブロックから頂点を受信して、タイル（即ち、スクリーン内の領域）毎にポイント、ライン、及び三角形をソートする。マルチ・バッファド・ソートメモリでは、ＳＲＴブロックはグラフィック・プリミティブを表す頂点のリストと、フレーム中の各タイル毎に１リストのタイル・ポインタ・リストのセットを保持している。ＳＲＴは（三角形の三番目の頂点のような）プリミティブを完成させる頂点を受信すると、どのタイルにプリミティブがタッチしているのかをチェックする。あるプリミティブがタッチしている各タイル毎に、ＳＲＴブロックは頂点に対するポインタをそのタイルのタイル・ポインタ・リストに加える。ＳＲＴブロックはフレーム中の全ジオメトリをソートし終える（即ち、フレームが完成する）と、そのデータをＳＴＰ（即ち「セットアップ」）ブロックに送る。簡潔さを期すため、ＳＲＴブロックからの各プリミティブのアウトプットは、１つのアウトプット・パケットに納められているが、代わりに頂点毎に１パケットを送るようにもできる。ＳＲＴは、そのアウトプットをタイル毎順で、即ち、ある所与のタイルにタッチしているプリミティブ全て、次に、その次のタイルにタッチしているプリミティブ全てという具合に送信する。これは、プリミティブがタッチしているタイル毎に１度の割で、ＳＲＴが同じプリミティブを何度も送信する場合もありうるということを意味する点に留意されたい。
【０２６６】  ＭＩＪブロックは、要求されると、カラー、材料特性等のようなパイプライン状態情報を多角形メモリから検索して下流に流す。帯域幅をセーブするため、個々の下流ブロックは最近使用されたパイプライン状態情報をキャッシュする。ＭＩＪブロックは、下流に何の情報がキャッシュされたかの航跡を保持し、必要とされる情報だけを送信する。ＭＥＸブロックはＭＩＪブロックと共に、グラフィック状態関連情報の管理に責任を負う。
【０２６７】  ＳＲＴブロックは、時間順序に並んだデータを受信してそれをタイル毎に貯える。（各タイル内で、リストは時間順になっている。）ＣＵＬ（即ち選別）ブロックはＳＲＴブロックからタイル順にデータを受信し、陰面除去法を実行（即ち、最終的にレンダされるイメージに決して寄与することのないプリミティブの部分を「選別」除去）する。ＣＵＬブロックは最終イメージで可視の（又は見える可能性のある）プリミティブの部分を記述するパケットを出力する。ＦＲＧ（即ちフラグメント）ブロックは、プリミティブ頂点値の補間（例えば、三角形内のある位置に関する面法線ベクトルを三角形頂点に位置する３つの面法線値から生成する）を行なう。ＴＥＸ（即ち、テクスチャ）ブロック及びＰＨＢ（即ち、フォング及びバンプ）ブロックは可視の（又は見える可能性のある）プリミティブの部分を受信するが、それそれ、テクスチャ値を生成し最終的なフラグメント・カラー値を生成する責を負う。最後のブロック、ＰＩＸ（即ちピクセル）ブロックは、最終的なフラグメント・カラーを消費し最終的なピクチャを生成する。
【０２６８】  ある実施例では、ＣＵＬブロックはＶＳＰを生成するが、ＶＳＰ（可視スタンプ部）は「スタンプ」を複数の隣接するピクセルとして、スタンプ上の多角形の可視（又は見える可能性のある）部分に対応している。スタンプ構成の一例は、２×２ピクセル・サブアレイ内の４個の隣接するピクセルのブロックである。ある実施例では、スタンプは、ＣＵＬブロックが、パイプライン型手法で、陰面除去法をスタンプ上で毎クロックサイクル毎に１スタンプの割で処理可能なように構成されている。
【０２６９】  プリミティブは、多数のタイルにタッチしているかもしれないので、従来からのレンダリング・パイプラインとは異なり、フレームのレンダリング過程中に何度も訪ねられる。パイプラインは、プリミティブがパイプラインに入った時に有効であったグラフィック状態を憶えておいて、ＳＲＴより下流のパイプライン・ステージにより訪ねられる度にそれを思い出さねばならない。
【０２７０】  ＭＩＪから下流のブロック（即ち、ＦＲＧ、ＴＥＸ、ＰＨＢ、及びＰＩＸ）はそれぞれ、ＭＩＪにより管理される１つ又はそれ以上のデータ・キャッシュを有している。ＭＩＪは、これらデータ・キャッシュに対応する多数のタグＲＡＭを含んでおり、これらタグＲＡＭは一般的には完全に関連付けられたメモリ（即ちコンテンツ・アドレス可能記憶装置）として実現されている。タグＲＡＭは、下流にキャッシュされた各情報毎に、多角形メモリ中にアドレス（又は、アドレスビットの固有部分のような他の固有の識別子）を記憶する。ＶＳＰがＣＵＬからＭＩＪに出力されると、ＭＩＪブロックは、当該ＶＳＰ内のピクセルに対する最終的カラー値を生成するために必要な状態情報のアドレスを決め、次にこれらのアドレスをタグＲＡＭに供給し、それによりそのデータ・キャッシュにすでに在る状態情報を識別するので、排除のプロセスによって、どの状態情報が当該データ・キャッシュに欠けているかを判定する。欠けている状態情報は、多角形メモリから読み出され、対応するＶＳＰに先行してパイプラインに送り込まれ、データ・キャッシュに書き込まれる。ＶＳＰがＭＩＪから送られると、データ・キャッシュへのインデクス（即ち、キャッシュへのアドレス）が加えられ、下流のブロックが、自身のデータ・キャッシュ内にその状態情報を見つけ出せるようになる。ＶＳＰが下流ブロックに到達した時点で、必要な状態情報はそれが必要とされるときにはデータ・キャッシュに存在することが保証され、供給されたインデクスを使って見つけられる。従って、データ・キャッシュは常に「ヒット」である。
【０２７１】  図Ｂ６は、パイプラインのＧＥＯからＦＲＧまでの部分を示すもので、本発明のある実施例中の状態情報と頂点情報のフロー（開始フレーム・パケット、終了フレーム・パケット、クリア・パケットのような他の情報のフローは図示していない）を図示している。頂点情報は、システム・プロセッサ又はホスト・メモリ（図Ｂ５）からＣＦＤブロックにより受信される。ＣＦＤは頂点情報に関して必要な如何なるフォーマット変換をも入手して実行し、それをＧＥＯブロックに渡す。同様に、状態情報、これはアプリケーションソフトウェアにより生成されるのが一般的であるが、これもＣＦＤにより受信されＧＥＯに渡される。状態情報は大きく以下の３つのタイプに分けられる。
【０２７２】  Ｓ１．ＧＥＯにより消費される状態情報。この型の状態情報は、通常、変換マトリクスと、頂点ベースのライティング（例：ガウラード・シェーディング）にしか使用しないライティング及び材料情報を備えている。
Ｓ２．陰面除去（ＨＳＲ）に必要な状態情報であり、これは以下の２つのサブタイプから構成されている。
【０２７３】    Ｓ２ａ）頻繁に変化すると考えられ、従ってソートメモリに、通常は同じメモリパケット中に、頂点データと共に記憶されるもの。この実施例では、このタイプの状態情報は、通常、プリミティブ・タイプ、デプステストのタイプ（例：オープンＧＬ“ＤｅｐｔｈＦｕｎｃ”）、デプステスト使用可能ビット、デプス書き込みマスク・ビット、ライン・モード・インジケータ・ビット、ライン幅、ポイント幅、プリミティブ毎のライン・スティップル情報、頻繁に変化する陰面除去関数制御ビット、及び多角形オフセット使用可能ビットを備えている。
【０２７４】    Ｓ２ｂ）あまり変化せず、従ってソートメモリのカル・モード・パケットに記憶されるもの。この実施例では、このタイプの状態情報は、通常、シザー・テスト・セッティング、アンチェイリアジング使用可能ビット、プリミティブ毎ではないライン・スティップル情報、頻繁に変化しない陰面除去関数制御ビット、及び多角形オフセット情報を備えている。
【０２７５】  Ｓ３．多角形メモリに記憶されている（ピクセル・プロセッシング毎の）ラスタライゼーションに必要な状態情報。このタイプの状態は、通常、フレーム毎のデータとオブジェクト毎のデータを備え、パイプライン・モード選択（例：ソート済み透明モード選択）、多数のライト用のライティング・パラメータ・セッティング、材料特性及び他のシェーディング特性を含んでいる。ＭＥＸは、以降の使用に備えて、多角形メモリに状態情報Ｓ３を記憶する。
【０２７６】  状態情報Ｓ２ａとＳ２ｂとの間の典型的な区別はインプリメンテーションに左右され、何れの特定の状態パラメータであっても一方のサブタイプからもう一方のサブタイプに移ることがあり得ることに留意されたい。この区別は特定のアプリケーションに対してはそれに合わせて調整されることもある。
【０２７７】  図Ｂ６に示すように、ＧＥＯは頂点情報を処理して、その結果の頂点情報ＶをＭＥＸに渡す。結果の頂点情報Ｖは、ＧＥＯにより以下の２つのグループに分けられる。
【０２７８】  Ｖ１．スクリーン座標頂点位置を含む、陰面除去に必要な頂点毎のあらゆる情報。この情報はＳＲＴに送られ、そこで後の使用に備えて状態情報Ｓ２ａと組み合わせてソートメモリ中に記憶される。
【０２７９】  Ｖ２．陰面除去に必要でない頂点毎の状態情報であり、一般的には、テクスチャ座標、アイ座標の頂点位置、面法線、及び頂点カラーとシェーディング・パラメータが含まれる。この情報は後の使用に備えて多角形メモリに記憶される。
【０２８０】  パイプラインに送り込まれる他のパケットには、処理されてソートメモリ及び多角形メモリに記憶されるべきデータのブロックの開始を示す開始フレーム・パケット、データの当該ブロックの終りを示す終了フレーム・パケット、１つ又はそれ以上のバッファ・クリア・オペレーションが実行予定であることを示すクリア・パケットが含まれる。
【０２８１】  代わりの実施例を図Ｂ７に示しているが、ここではＳＴＰステップはＳＲＴステップの前に起きる。これは、図Ｂ６の実施例ではＳＴＰステップが同じプリミティブ上で多数回（それがソート・メモリから読み出される毎に１回）行なわれることになるので、総計算回数を減らす点で都合がよい。しかしながら、図Ｂ７の実施例は、より多くのデータがそこに記憶されることからより多量のソート・メモリが要求される点では不利である。
【０２８２】  図Ｂ８に示すある実施例では、ＭＥＸとＭＩＪは多角形メモリに対し共通のメモリ・インターフェースを共有するが、ＳＲＴはソート・メモリに対し専用のメモリ・インターフェースを有する。ある代替例として、図Ｂ９に示すように、ＭＥＸ、ＳＲＴ、及びＭＩＪは同じメモリ・インターフェースを共有することもできる。図Ｂ８及び図Ｂ９に示すＲＡＭは、一般的には、ＭＥＸ、ＳＲＴ、及びＭＩＪ機能を備えた集積回路に外付けされたダイナミック・メモリ（ＤＲＡＭ）であるが、しかしながら内蔵型ＤＲＡＭを使用することもできる。好適な実施例では、ＲＡＭＢＵＳ  ＤＲＡＭ（ＲＤＲＡＭ）が使用されるが、より特定すると、ダイレクトＲＡＭＢＵＳ  ＤＲＡＭ（ＤＲＤＲＡＭ）が使用される。
システム詳細−モード抽出（ＭＥＸ）ブロック
ＭＥＸブロックは以下のこと、即ち、１）ＧＥＯカラー・パケットを受信すること、２）それらデータ・パケットに関して必要とされるあらゆる再プロセッシングを実行すること、３）多角形メモリの（ＭＩＪによる後刻の検索に備えた）パイプラインのシェーディング部分により必要とされる情報を適切にセーブすること、４）ＭＩＪがプリミティブに関係付けられた状態を知ることができるように、状態ポインタをＳＲＴに送信されるプリミティブに取り付けること、５）ＳＲＴ、ＳＴＰ、及びＣＵＬが必要とする情報をＳＲＴブロックに送ること、及び６）多角形メモリとソート・メモリのオーバーフローに対応すること、に責任を負う。
【０２８３】  パイプラインのＳＲＴ−ＳＴＰ−ＣＵＬ部は、プリミティブのどの部分が隠される保証がないのかを判定して、これらの部分（以後これらの部分の各々をＶＳＰと称する）をパイプラインに送り込む。ＶＳＰは、さらに処理が必要な１つ又はそれ以上のピクセルから構成され、１つのＶＳＰ内のピクセルは同じプリミティブからのものである。これらＶＳＰ内のピクセル（又はサンプル）は、ここでパイプラインのＦＲＧ−ＴＥＸ−ＰＨＢ部によりシェードされる。（以後「シェード」とはピクセルに対しカラー及びデプス値を生成するために必要なあらゆるオペレーションを指すものとし、一般的にはテクスチャリングとライティングが含まれる。）ＣＵＬブロックからＭＩＪブロックへのＶＳＰアウトプットは必ずしもプリミティブ順に並んでいるわけではない。ＣＵＬがＶＳＰを空間順に出力する場合は、ＶＳＰはタイル上のスキャン順（即ち、タイル内の行を横切って出力されるので、異なるプリミティブに対するＶＳＰが差し込まれるかもしれない）になる。パイプラインのＦＲＧ−ＴＥＸ−ＰＨＢ部は、プリミティブが最初に導入されたときのグラフィックス状態の他にも、特定のＶＳＰがどのプリミティブに属しているかを知る必要がある。ＭＥＸは、頂点がＳＲＴに送信されると、カラーポインタを各頂点に関係付け、それにより頂点情報Ｖ１と対応する頂点情報Ｖ２の間にリンクを作り出す。カラーポインタは、パイプラインのＳＲＴ−ＳＴＰ−ＣＵＬ部を介しこれに沿って流され、ＶＳＰに含まれている。このリンケージにより、ＭＩＪは、多角形メモリから何れの特定のＶＳＰ内のピクセルをシェードするのにも必要な頂点情報Ｖ２を検索できるようになる。ＭＩＪは又、ＭＬＭポインタを介して、多角形メモリ中に、これもＶＳＰのシェーディングに必要なパイプライン状態情報Ｓ３を見つけ出し、この情報をパイプラインに送り込む。
【０２８４】  ＭＥＸは従って、最後の状態セーブ以降に起きたあらゆる状態変化を蓄積しておく必要がある。状態変化は、頂点又は汎用パイプライン内では（ソート・パケット内の）「ドロー」コマンドを指すコマンドに出会うと即有効となる。ＭＥＸはＭＥＸ状態ベクトルをオンチップ・メモリ又はレジスタに保持する。ある実施例では、ＭＥＸ状態ベクトルを記憶するため、ＭＥＸには１ｋバイトを超すオンチップ・メモリが必要である。これは、多数の頂点がパイプラインに送り込まれた場合には、各ベクトルのために膨大な量の情報が必要となるということである。従って、本発明の１っの態様によれば、状態データは区切られて多角形メモリに記憶され、そのある区分に対する特定のセッティングは一旦記憶され、それが関係する全ての頂点に対して必要とされる最少の回数だけ呼び出されるようにされる。
システム詳細−ＭＩＪ（モード注入）ブロック
モード注入ブロックはＣＵＬブロックと残りの下流の３Ｄパイプラインの間に在る。ＭＩＪは制御とＶＳＰパケットをＣＵＬブロックから受信する。出力側では、ＭＩＪはＦＲＧブロック及びＰＩＸブロックとインターフェースしている。
【０２８５】  ＭＩＪブロックは、以下のことに責任を負う。即ち、１）ＦＲＧ及びＰＩＸユニットに開始フレーム、終了フレーム及び開始タイルのような種々の制御パケットを送ること。２）ＳＲＴからＰＩＸへ、プリフェッチ・パケットを送ること。３）カラーポインタを使用してＶＳＰに対応するプリミティブの全頂点に関する頂点情報Ｖ２を見つけ出し（一般的にはアドレスを生成することに当たる）て、当該プリミティブに関係付けられたＭＬＭポインタを見つけ出すこと。４）ＭＬＭポインタを多角形メモリから読み出す必要があるかを判定して必要時にはそれらを読み取ること。５）状態キャッシュのコンテンツの航跡を保持すること。ある実施例では、これらの状態キャッシュは（ＦＲＧｔ、ＴＥＸ及びＰＨＢブロックに対する）カラー、ＴｅｘＡ、ＴｅｘＢ、ライト及び材料キャッシュ、（ＰＩＸブロックに対する）ピクセル・モード及びスティップル・キャッシュであり、適当なキャッシュ・ポインタを各キャッシュ・ミス・データ・パケットに関係付ける。６）キャッシュ・ミスがいつ起きたのかを判定することにより、どのパケット（頂点情報Ｖ２及び／又はパイプライン状態情報Ｓ２ｂ）を多角形メモリから検索する必要があるのかを判定し、当該パケットを検索すること。７）多角形メモリから検索されたパケットからキャッシュ・フィル・パケットを構築し、それをデータ・キャッシュまでパイプラインで送ること。（ある実施例では、データ・キャッシュはＦＲＧ、ＴＥＸ、ＰＨＢ、及びＰＩＸブロックにある。）８）データをフラグメント及びピクセル・ブロックに送ること。１０）パイプライン内のストールを処理すること。１１）フレームが完成したらＭＥＸに信号を送ること。１２）状態をＣＵＬブロックから受信した各ＶＳＰに関係付けること。
【０２８６】  ＭＩＪはこうして、ＶＳＰ内の各フラグメント毎に最終的なカラーを計算するのに必要な、頂点毎データ並びに状態の検索に対処する。状態全体は、比較的小型のカラー・ポインタに保持されてぃる情報から再製できる。
【０２８７】  ＭＩＪはＣＵＬブロックからＶＳＰパケットを受信する。ＣＵＬブロックからＭＩＪへのＶＳＰアウトプットは必ずしもプリミティブ順ではない。殆の場合、タイル上のＶＳＰスキャン順になっており、つまりは異なるプリミティブについてのＶＳＰが差し挟まれている可能性があるということである。ＶＳＰ内のフラグメントをライト、テクスチャ、及びコンポジットするために、ＭＩＪより下流のパイプラインステージには（ポイント、ライン、三角形、ライン・モード三角形のような）プリミティブのタイプについての情報、（プリミティブの頂点の、ウィンドウ及びアイ座標、法線、カラー、及びテクスチャ座標のような）頂点情報Ｖ２、及びプリミティブがＭＥＸから受信されたときにアクティブであった状態情報Ｓ３が必要である。状態情報Ｓ２はＭＩＪ下流には不要である。
【０２８８】  ＭＩＪは、ＣＵＬから開始フレーム・パケットを受信した後、フレーム上で作業を開始する。当該フレームに関するＶＳＰ処理は、ＣＵＬが当該フレームについての最初のＶＳＰを出力すると開始される。
ＭＥＸ状態ベクトル
状態情報Ｓ３に関して、ＭＥＸは関連する状態パケットを受信して、最も最近に受信した状態情報Ｓ３のコピーをＭＥＸ状態ベクトル内に保持する。ＭＥＸ状態ベクトルは複数の状態区分に分割される。図Ｂ１０は、ある実施例で使用されている区分けを示しているが、ここでは状態情報Ｓ３に対して９区分を使用している。図Ｂ１０は、ＭＥＸ状態ベクトル内の状態情報Ｓ３を更新するさまざまな状態パケットの名称を示している。これらのパケットには、プリミティブの表面のシェーディング特性及びオペレーションを記述しているＭａｔＦｒｏｎｔパケット、プリミティブの裏面のシェーディング特性及びオペレーションを記述しているＭａｔＢａｃｋパケット、プリミティブの表面の始めの２つのテクスチャの特性を記述しているＴｅｘＡＦｒｏｎｔパケット、プリミティブの裏面の始めの２つのテクスチャの特性とオペレーションを記述しているＴｅｘＡＢａｃｋパケット、プリミティブの表面の残りのテクスチャの特性及びオペレーションを記述しているＴｅｘＢＦｒｏｎｔパケット、プリミティブの裏面の残りのテクスチャの特性及びオペレーションを記述しているＴｅｘＢＢａｃｋパケット、ライトセッティングとオペレーションを記述しているＬｉｇｈｔパケット、フラグメント毎オペレーション・パラメータとＰＩＸブロックで行なわれたオペレーションを記述しているＰＩＸＭｏｄｅパケット、及びスティップル・パラメータ及びオペレーションを記述しているスティップル・パケットがある。ＭＥＸ状態ベクトル内のある区分が変更され、後の使用に備えてセーブする必要があるかもしれない場合は、Ｄ１からＤ９までのダーティ・フラグの内それに対応しているものが、ある実施例では、表明され、当該区分に変更が発生したことを示す。図Ｂ１０はダーティ・フラグを有するＭＥＸ状態ベクトル内の区分を示している。
【０２８９】  ＭＥＸ状態ベクトルのライト区分には、フラグメント・ライティング計算に使用される複数のライトに関する情報の他にも、フォグ・パラメータ及び他のシェーディング・パラメータのようなフラグメントのライティングに影響する包括的な状態、及びオペレーション等が入っている。ライト・パケットには、一般的には、以下のライト毎情報、即ち、ライト・タイプ、減衰定数、スポットライト・パラメータ、ライト位置情報、及び（周辺拡散及び反射カラーを含む）ライトカラー情報が含まれる。本実施例では、ライト・キャッシュ・パケットには、以下の包括的ライティング情報即ち、包括的な周辺ライティング、フォグ・パラメータ、及び使用中のライトの数も含まれている。
【０２９０】  ライト・パケットが８個のライトを記述している場合は、そのライト・パケットは約３００バイト（８個のライトはそれぞれに大凡３００ビット、加えてグローバル・ライト・モードの１２０ビット）である。ある実施例では、ライト・パケットはドライバ又はアプリケーション・ソフトウェアにより生成され、ＧＥＯブロックを介してＭＥＸに送られる。ＧＥＯブロックはこの情報をどれも使用しない。
【０２９１】  １つの大型ブロックのデータとしてライティング状態を記憶するのではなく、代わりにライト毎情報を記憶するので、各ライトは別々に管理できる。これにより、ライト・パラメータ・キャッシュミスがＭＩＪに起きた場合にも、パイプラインに送信するデータはより少なくて済むようになっている。こうして、アプリケーション・プログラムでは、１個のライトが変更されたときのライティング・パラメータの切替が「より軽量」になっている。
【０２９２】  状態情報Ｓ２に関しては、ＭＥＸは、状態情報Ｓ２ａに１区分と状態情報Ｓ２ｂに１区分の合わせて２区分を保持する。状態情報Ｓ２ａ（ＶｒｔｘＭｏｄｅパケットで受信）は常に全頂点と共にソート・メモリにセーブされるので、ダーティ・フラグは必要ない。状態情報Ｓ２ｂ（ＣｕｌｌＭｏｄｅパケットで受信）は変更され新しい頂点を受信したときのみソート・メモリにセーブされるので、ダーティ・フラグ（Ｄ１０）が必要である。ＣｕｌｌＭｏｄｅパケットとＶｒｔｘＭｏｄｅパケット内の情報は、パイプラインのソート−セットアップ−カル部に送られる。
【０２９３】  記述されたパケットは、ＭＥＸ状態ベクトルの対応する区分全体を更新する必要はなく、例えば、当該区分の単一のパラメータを更新するようにできる。これによりパケットはより小さくなるが、パケットはどのパラメータが更新中であるかを表示す必要がある。
【０２９４】  ＭＥＸが（頂点位置を規定している）頂点情報Ｖ１を含んでいるソート・パケットを受信するとき、その頂点に関係付けられた状態は最も新しく受信された状態（即ち、頂点情報Ｖ２の現在値及び状態情報Ｓ２ａ、Ｓ２ｂ、及びＳ３）のコピーである。（カラー・パケットの）頂点情報Ｖ２は、頂点情報Ｖ１（ソート・パケットで受信）の前に受信される。ソート・パケットは、頂点の（一般的にはウィンドウ域にクリップされる）ウィンドウ座標及びプリミティブ・タイプのような、プリミティブのソートとカルに必要とされる情報から構成されている。カラー・パケットは、プリミティブのライティング、テクスチャリング、及びシェーディングに必要な、頂点アイ座標、頂点法線、テクスチャ座標等のような頂点毎情報から成り、後で検索できるように多角形メモリにセーブされる。頂点毎情報の量は３Ｄオブジェクトの視覚的コンプレキシティにより様々である（例えばテクスチャ座標の数はまちまちであり、アイ座標頂点位置の必要性はローカル・ライトが使用されているのか又はローカル・ビューワが使用されているのかによって左右される）ので、ある実施例ではカラー・パケットの長さが変えられるようになっている。各頂点と共に記憶されているカラーポインタは、多角形メモリ中の対応するカラー・パケットの位置を表示する。頻繁に変更されるデータ及び演算子もあり、あまり頻繁に変更されないものもあるので、これらは別々の構造にセーブしてもよいし、或いは１つの構造にセーブしてもよい。
【０２９５】  ある実施例では、ＭＥＸには、状態ベクトルのデフォルト・リセットはない。状態が適切に初期化されていることを保証するのはドライバ／ソフトウェアの責任である。アドレシングを簡素化するために、メッシュ内の頂点は全て同じサイズである。
ダーティ・フラグ及びＭＬＭポインタ生成
ＭＥＸは、状態情報Ｓ３の各区分及び状態情報Ｓ２の幾つかの区分に対しダーティ・フラグと（多角形メモリへの）ポインタを保持する。こうして、図Ｂ１０の実施例では、カル・モードは多角形メモリにセーブされていないのでポインタが必要ないということから、１０のダーティ・フラグと９のモード・ポインタがある。ＭＥＸは、パイプライン状態を含むインプット・パケットを受信する度、ＭＥＸ状態ベクトルの対応する部分を更新する。更新された各状態区分毎に、ＭＥＸは当該区分に対応するダーティ・フラグもセットする。
【０２９６】  ＭＥＸは、ソート・パケット（即ち頂点情報Ｖ１）を受信すると、ダーティ・フラグを検査して、状態情報Ｓ３に最後のセーブ以後に更新された部分がないかどうかを調べる。更新（ダーティ・フラグがセットされていることにより示される）され、現在のプリミティブのレンダリングに関連（即ち補正面）する全ての状態区分は多角形メモリにセーブされ、それらのポインタが更新され、それらのダーティ・フラグがクリアされる。ＭＥＸ状態ベクトルの幾つかの部分はバック−フロント・ペア（例えばＭａｔＢａｃｋとＭａｔＦｒｏｎｔ）になっており、これは、セット内の多数の中でその２つの内の片方だけが特定のプリミティブに関連していることを意味している点に留意されたい。例えば、ＴｅｘＡＢａｃｋ及びＴｅｘＡＦｒｏｎｔの両方に対しダーティ・ビットがセットされており、ソート・パケットにより完了したプリミティブがフロント・フェーシングであると考えられる場合は、ＴｅｘＡＦｒｏｎｔが多角形メモリにセーブされ、ＦｒｏｎｔＴｅｘｔｕｒｅＡＰｔｒは多角形メモリに対して書き込まれた６個のＭＬＭポインタのセット内のＴｅｘｔｕｒｅＡＰｔｒポインタにコピーされ、ＴｅｘＡＦｒｏｎｔに対するダーティ・フラグはクリアされる。この例では、ＴｅｘＡＢａｃｋに対するダーティ・フラグは影響を受けずセットされたままである。選択プロセスを図Ｂ１０に「ｍｕｘ」（即ち、マルチプレクサ）演算子により概略的に示している。
【０２９７】  各ＭＬＭポインタは、多角形メモリに記憶されたＭＥＸ状態ベクトルのある区分の位置を指す。記憶された各区分が幾分小さめのメモリブロックの倍数分のサイズ（例えば、各区分が１６バイト・メモリ・ブロックの倍数）であれば、各ＭＬＭポインタは多角形メモリ内のブロック数であり、それにより各ＭＬＭポインタ内のビットをセーブする。例えば、多角形メモリの１ページが３２ＭＢ（即ち２２５バイト）で、各ブロックが１６バイトであるとすると、各ＭＬＭポインタは２１ビットである。多角形メモリとソートメモリへの全ポインタは、メモリ・ブロック・サイズを利用してアドレス・ビットをセーブすることができる。
【０２９８】  ある実施例では、多角形メモリはＲａｍｂｕｓメモリ、厳密には、ダイレクトＲａｍｂｕｓダイナミック・アクセスメモリ（ＤＲＤＲＡＭ）を使って実現されている。ＤＲＤＲＡＭにとって、最も簡単にアクセス可能なメモリ・ブロック・サイズは「デュアルオクト」であり、これは１６ｘ９ビット・バイト、つまり合計１４４ビットとなり、これは１８ｘ８ビット・バイトでもある。６個のＭＬＭポインタのセットを１４４ビット・デュアルオクト１個に記憶すると、各ＭＬＭポインタは２４ビットになるはずである。ＭＬＭポインタ１個に２４ビット値とすると、多角形メモリの１ページは２５６ＭＢになる。以下の例では、ＭＬＭポインタは２４ビット数であるものとする。
【０２９９】  状態情報Ｓ３は多数のプリミティブの間で共有できるので、ＭＬＭポインタが使用される。しかしながら、６個のＭＬＭポインタのセットを記憶するには約１６バイトが必要となり、これは、各頂点に非常に大きな記憶装置のオーバーヘッドが含まれることになる。従って、６個のＭＬＭポインタのセットが多数の頂点の間で共有されるが、これは、頂点が全く同じ状態情報Ｓ３を共有している（即ち、各頂点が６個のＭＬＭポインタの同じセットを有している）場合にだけそうなるのである。都合のよいことに、３Ｄアプリケーション・プログラムは、一般的に、同じ状態情報Ｓ３を持つ多くの頂点をレンダする。実際、ほとんどのＡＰＩは、状態情報Ｓ３が多角形メッシュ（又は、ライン・ストリップ、三角形ストリップ等）の全ての頂点にとって一定であることを要件としている。オープンＧＬ  ＡＰＩの場合には、状態情報Ｓ３は「ｇｌＢｅｇｉｎ」と「ｇｌＥｎｄ」ステートメントの間は不変でなくてはならない。
カラーポインタ生成
カラーポインタ機能の設計に当たっては多様なバリエーションが考えられるので、１つの実施例だけを説明する。図Ｂ１１は、６つの頂点からなる４つの三角形を持つ三角形ストリップの例を示している。図Ｂ１１の例では、ソート・メモリの６個の対応する頂点エントリが示されており、各エントリには各カラー・ポインタ内に４つのフィールド、即ちカラー・アドレス、カラー・オフセット、カラー・タイプ、及びカラー・サイズが含まれている。先に述べたように、カラーポインタは、多角形メモリ内に頂点情報Ｖ２を見つけるために使用され、カラーアドレス・フィールドは第１メモリブロック（本例ではメモリブロックは１６バイトである）を表示する。更に図Ｂ１１では、各ソート・メモリ・エントリのソート・プリミティブ・タイプ・パラメータも示しているが、このパラメータは、頂点がＳＲＴによりどのように連結されてプリミティブを作るかを記述するもので、可能な選択には、ｔｒｉ＿ｓｔｒｉｐ（三角形ストリップ）、ｔｒｉ＿ｆａｎ（三角形ファン）、ｌｉｎｅ＿ｌｏｏｐ、ｌｉｎｅ＿ｓｔｒｉｐ、ｐｏｉｎｔ等が含まれる。作動時、ソート・メモリ・エントリ内の多くのパラメータは、対応する頂点がプリミティブを完成するものでなければ必要とされない。図Ｂ１１では、これら不要なパラメータはＶ１０及びＶ１１にあり、未使用のパラメータは、ソート・プリミティブ・タイプ、状態情報Ｓ２ａ、及びカラーポインタ内の全パラメータである。図Ｂ１２は、図Ｂ１１の例の続きであり、多角形メモリ内のＭＬＭポインタを２セットと頂点情報Ｖ２を８セット示している。
【０３００】  多角形メモリ内の頂点情報Ｖ２のアドレスは、カラー・アドレスにメモリ・ブロック・サイズを掛けることにより見つけられる。一例として、図Ｂ１１及び図Ｂ１２に説明しているＶ１２を考察してみよう。そのカラー・アドレス、０×００１０４１に０×１０を掛けると０×００１０４１０が得られる。この計算されたアドレスが当該頂点についての頂点情報Ｖ２の最初のバイトの位置である。この頂点についての頂点情報Ｖ２内のデータの量はカラー・サイズ・パラメータにより示されるが、本例ではカラー・サイズは０×０２であるので、これは２メモリブロックが使用されていることを示し、合計で３２バイトということになる。カラー・オフセット及びカラー・サイズ・パラメータは、次の公式（但し、Ｂをメモリ・ブロックサイズとして）、
（ＭＬＭポインタのアドレス）＝（カラーアドレス＊Ｂ）−（カラーサイズ＊カラーオフセット＋１）＊Ｂ
によりＭＬＭポインタを見つけるのに使用される。カラー・タイプ・パラメータはプリミティブ（三角形、ライン、ポイント等）のタイプと、そのプリミティブが三角形メッシュ、ライン・ループ、ライン・ストリップ、ポイントのリスト等の一部であるのかを表示する。カラー・タイプは、プリミティブの全頂点についての頂点情報Ｖ３を発見するために必要である。
【０３０１】  ＶＳＰに含まれているカラー・ポインタは、対応するプリミティブを完成させる頂点のカラー・ポインタである。つまり、プリミティブの最後の頂点であり、三角形では３番目の頂点、ラインについては２番目である。
【０３０２】  先の論では、カラー・サイズ・パラメータは２進コード数として説明した。しかし、より最適化されたインプリメンテーションでは、このパラメータを、サイズのテーブルへの記述子又はインデクスとして有している。従って、ある実施例では、３ビットパラメータは多角形メモリ内のエントリの、例えば１から１４メモリ・ブロックまでの範囲で８通りのサイズを規定する。
【０３０３】  （ＭＥＸの）メッシュ中の頂点の最大数は、カラー・ポインタのカラー・オフセット・パラメータ中のビットの数により異なる。例えば、カラー・オフセットが８ビットであれば、メッシュ中の頂点の最大数は２５６である。アプリケーション・プログラムが、ＭＥＸが対応できる最大数より多くの頂点を持つメッシュを規定する場合はいつでも、ソフトウェア・ドライバが当該メッシュをより小さなメッシュに分割しなければならない。ある代わりの実施例では、ＭＥＸはこのメッシュの分割を自動的に行なうが、ほとんどのアプリケーション・プログラムは大型メッシュを使っていないので、一般的にはそのコンプレキシティは是認されてはいないことに留意されたい。
クリア・パケット及びクリア・オペレーション
上記のパケットに加え、クリア・パケットもパイプラインに送り込まれる。これらのパケットは、デプス値、カラー値、及び／又はステンシル値のある部分を特定の値のセットにセットするバッファ・クリア・オペレーションを規定する。ＣＵＬで使用される場合、クリア・パケットにはデプス・クリア値が含まれている。クリア・パケットは、それらが多角形メモリに記憶されているパイプライン状態情報に関係付けられていることから、ＭＥＸがバッファ・クリア・オペレーションを「プリミティブ」として取り扱うのと同様に処理されることに留意されたい。従って、ソート・メモリに記憶されたクリア・パケットには、カラー・ポインタが含まれ、従ってＭＬＭポインタのセットに関係付けられており、ダーティ・フラグがＭＥＸにセットされている場合、状態情報Ｓ３が多角形メモリに書き込まれる。
【０３０４】  クリア・パケットに対する効率が改善されたある実施例では、バッファ・クリアに必要な全ての必要な状態情報Ｓ３が、ＭＥＸ状態ベクトル内の単一区分（ある実施例では、これはＭＥＸ状態ベクトルのＰｉｘＭｏｄｅ区分である）内に完全に納められている。これにより、クリア・パケット内のカラー・ポインタは、単一のＭＬＭポインタ（ＰｉｘＭｏｄｅＰｔｒ）に取り替えることができるようになる。これは、今度は、ＰｉｘＭｏｄｅ区分に対するダーティ・フラグだけしか検査する必要がなく、当該区分だけが暫定的に多角形メモリに書き込まれることを意味する。他のダーティ・フラグはクリア・パケットの影響を受けない。
【０３０５】  別の実施例では、クリア・パケットは状況を利用するので、ＭＥＸ状態ベクトル内のデータは全く必要とされない。これは、クリア・パケットに含まれている「ＳｅｎｄＴｏＰｉｘｅｌ」と呼ばれる特別のビットを用いて実現される。このビットが表明されると、クリア・オペレーションは、特定のディスプレイ・スクリーン（即ちウィンドウ）に対する１つ又はそれ以上のバッファ（即ち、１つ又はそれ以上のデプス・バッファ、カラー・バッファ、及び／又はステンシル・バッファ）内の全ての値に均一的に影響を及ぼすと知られる。厳密には、このクリア・オペレーションはシザー・オペレーション又は何れのビット・マスキングにも影響されない。ＳｅｎｄＴｏＰｉｘｅｌが表明されたが、所与のタイルに関し何のジオメトリもまだパイプラインに送り込まれていないのであれば、クリア・オペレーションは開始タイル・パケットに組み込む（ＳＲＴから別のパケットとして送られない）ことができ、それにより通常ＢＫＥにより実行されるフレームバッファ読み出しオペレーションを回避することができる。
多角形メモリ管理
書き込み中の多角形メモリのページに関し、ＭＥＸは現在の書き込み位置に関してポインタを、頂点情報Ｖ２に対して１つ、状態情報Ｓ３に対して１つ、維持する。頂点ポインタは、多角形メモリ内の現在の頂点に対するポインタである。頂点カウントは、最後の状態変更以後多角形メモリ中にセーブされている頂点の数である。頂点カウントはカラー・オフセットに割当てられる。頂点ポインタはソート・プリミティブに対するカラー・ポインタに割当てられる。メモリ・オーバーフローに対処している間は以前の頂点が使用される。ＭＩＪはカラー・ポインタ、カラー・オフセット、及び（ＧＥＯから受信されカラー・タイプにエンコードされた）頂点サイズ情報を使用して、多角形メモリからＭＬＭポインタとプリミティブ頂点を検索する。
代わりの実施例
ある実施例では、ＣＵＬはＶＳＰを空間順ではなくてプリミティブ順で出力する。つまり、特定のプリミティブに対応する全てのＶＳＰが、別のプリミティブからのＶＳＰが出力される前に出力されるということである。しかしながら、ＣＵＬがデータをタイルずつに処理するのであれば、同じプリミティブからのＶＳＰは依然として他のプリミティブからのＶＳＰの割り込みを受ける。ＶＳＰをプリミティブ順に出力することは、ＭＩＪの下流にデータをキャッシュするのを助ける。
【０３０６】  ある代わりの実施例では、ＭＥＸ状態ベクトル全体が単一のメモリとして取り扱われ、ＭＥＸにより受信される状態パケットは、メモリ内のランダム位置を更新する。こうするとＭＥＸ状態ベクトルを更新するのには単一のタイプのパケットしか必要でなく、そのパケットはメモリ内へのアドレスとメモリに置くべきデータを含んでいる。この実施例のあるバージョンでは、データは幅が可変で、パケットはサイズパラメータを有している。
【０３０７】  さらに別の代わりの実施例では、ＰＨＢ及び／又はＴＥＸブロックはマイクロコード化プロセッサであり、ＭＥＸ状態ベクトルの１つ又はそれ以上の区分はマイクロコードを含んでいる。例えば、ある実施例では、ＴｅｘＡＦｒｏｎｔ、ＴｅｘＡＢａｃｋ、ＴｅｘＢＦｒｏｎｔ、及びＴｅｘＢＢａｃｋパケットがマイクロコードを含んでいる。こうして、本例では、３Ｄオブジェクトは、そのシェ−ディングがどのように行なわれるべきかを記述する自身のマイクロコードを有している。これにより、ユーザーコード化シェーダー同様により複雑なライティング・モデルに関するメカニズムを提供できる。ディファード・シェーダーにおいて、マイクロコードは、最終的ピクチャに影響するピクセル（又はサンプル）についてしか実行されない。
【０３０８】  本発明のある実施例では、パイプライン状態情報は、それが変更されたときにだけパイプラインに入力される。厳密には、アプリケーション・プログラムは、ＡＰＩ（アプリケーション・プログラム・インターフェース）コールを使って、パイプライン状態を実質的に同じ値に繰返しセットし、それにより（多角形メモリ使用の最小化を目指し）ドライバ・ソフトウェアがどの状態パラメータが変更になったのかを判断して、変更されたパラメータだけをパイプラインに送るようにすることを要求する。これにより、データを多角形メモリに記憶すべきかどうかを判定するに当たり単純なダーティ・フラグ・メカニズムが使用できるので、ハードウェアが簡素化される。こうして、ソフトウェア・ドライバが状態変更チェックを行なうとき、ソフトウェア・ドライバはその状態をホスト・メモリのシャドー・レジスタに保持する。ソフトウェア・ドライバは、新しい状態が直前の状態と同じであると検知したときには、ハードウェアに何れの状態情報をも送らず、ハードウェアは同じ状態情報を続けて使用する。反対に、ソフトウェア・ドライバが、状態情報に変更があったと検知したときは、新しい状態情報はホストのシャドー・レジスタ内へ記憶され、新しい状態情報がハードウェアに送られるので、ハードウェアはこの新しい状態情報下で動作する。
【０３０９】  代わりの実施例では、ＭＥＸは入ってくるパイプライン状態情報を受信して、それをＭＥＸ状態ベクトルの値と比較する。入ってくる値がＭＥＸ状態ベクトルの対応する値と異なる場合は、適当なダーティ・フラグがセットされる。異ならない入力値は破棄され、ダーティ・フラグに変更は起きない。この実施例では、（大抵コンパリタの形態をした）追加的なハードウェアが必要になるが、ドライバが比較を実行する必要はなくなることから、ドライバ・ソフトウェアに要求される仕事量は低減する。
【０３１０】  本発明の別の実施例では、ＭＥＸはあるタイプの状態変更につきチェックを行ない、その一方でソフトウェア・ドライバはある別のタイプのハードウェア状態変更につきチェックする。このハイブリッド・アプローチの好都合な点は、状態変更検出専用のハードウェアを最小限にして、一般的に発生するタイプの状態変更だけに使用することができ、それにより高速オペレーションを可能にしつつ、ハードウェアにより検出されないあらゆるタイプの状態変更はソフトウェア・ドライバが検出することから全てのタイプの状態変更が依然検出できるようになっている点である。この方法では、専用ハードウェアが簡素化され、大部分のタイプの状態変更に対し高速オペレーションが実現されるとともに、ソフトウェアのチェック動作が専用ハードウェアにより検出されない他のタイプの状態変更を判断するので、状態変更が見逃されるのは皆無となる。
【０３１１】  別の代わりの実施例では、ＭＥＸは、先ず多角形メモリに記憶されるべき更新された状態区分が前のオペレーションにより既に多角形メモリに存在しているかどうかを判定し、在れば、多角形メモリに記憶されている既に存在する状態区分を指すようポインタをセットする。この方法は先行してセーブされた状態のリストを保持しており、そのリストは連続してサーチされる（一般にはこれはゆっくり行なわれる）か、又は関連するキャッシュ（即ち、コンテンツ・アドレス可能メモリ）と並行して、追加のハードウェアに費用を掛けてサーチされる。これら費用は多角形メモリの膨大な量を節約することにより相殺できる。
【０３１２】  更に別の代わりの実施例では、アプリケーション・プログラムは、各状態にラベルを付けるという要件が課せられており、カラー頂点がラベル付けされた状態を参照するようにさせる。この実施例では、ラベル付けされた状態は多角形メモリ内へ、必要ベース又はプリフェッチ・オペレーションの形態の何れかでロードされるが、ここで多数のラベル付けされた状態は以後の使用に備えて多角形メモリにロードされる。これは多数のレンダリング・フレームに使用される状態ベクトルのためのメカニズムを提供し、それによりパイプラインに供給されるデータの量を減らす。
【０３１３】  本発明のある実施例では、パイプライン状態は、状態の特定の態様を定義するビット位置内に配置されているビットだけを含むのではなく、パイプライン内のプロセッサにより実行されるソフトウェア（以後マイクロコードと称する）をも含んでいる。これは、ＰＨＢブロックでは、それがライティング及びシェーディング・オペレーションを行なうので特に重要であり、こうしてディファード・シェーディングを行なう３Ｄグラフィクス・パイプライン内のプログラム可能シェーダーは本発明から多大な益を受ける。この益は、従来の３Ｄレンダラーでシェードされるようなピクセル（又はピクセル・フラグメント）の計算的に高価なシェーディングを（陰面除去処理又はＣＵＬブロックを介して）排除することから生まれる。全状態情報のように、このマイクロコードは適当なプロセッシング・ユニットに送られ、そこで最終的なピクチャに影響を与えるよう実行される。将来の使用を見込んで状態情報が多角形メモリ内にセーブされるそのとき、このマイクロコードも状態情報Ｓ３の一部としてセーブされる。ある実施例では、ソフトウェア・ドライブ・プログラムは、アプリケーション・プログラムから送られるパラメータに基づき（事前生成された複数個のコードをリンクすることを介して）このマイクロコードをオンザフライで生成する。ある単純な実施例では、ドライバ・ソフトウェアは、パラメータの考えられ得る全ての選択肢に対するマクロコードの事前にコンパイルされたバージョンを保持しており、状態情報が必要なとき、マイクロコードの当てはまるバージョン（又はそれに対するポインタ）をパイプライン内へ送り込むだけである。別の代わりの実施例では、アプリケーション・プログラムがマイクロコードを供給する。
【０３１４】  ある代替例では、もっと多くのポインタがＭＬＭポインタのセットに含まれている。これは、要求される多角形メモリの量を減らすことを目指して、ＭＥＸ状態ベクトルをより小さな区分にするために行なわれるものである。或いは、フロント・フェーシング・パラメータ及びバック・フェーシング・パラメータ両方の区分に対するポインタを提供し、それによりフロント・フェーシングからバック・フェーシングへの又はその逆のフリップの際にメッシュが壊れるのを回避するために行われる。
【０３１５】  ソート・メモリでは、頂点位置はウィンドウ（即ち表示スクリーン）にクリップされるか、又はクリップされないの何れかである。クリップされない場合は、高精度数（例えば浮動少数点）がソート・メモリに記憶される。クリップされる場合には、使用される精度はより低くても構わない（一般的には固定少数点で十分である）が、先行技術によるレンダラーでは、全ての頂点属性（面法線、テクスチャ座標等）もクリップされねばならず、これは計算的に高価なオペレーションである。本発明の革新の随意的部分としては、クリップされた頂点位置はソート・メモリに記憶されるが、クリップされない属性は多角形メモリに（クリップされない頂点位置と共に）記憶される。図Ｂ１３Ａは、６つの頂点から成る三角形ストリップが表示スクリーンにあるのを示しているが、これら頂点は、それらの属性と共に、多角形メモリに記憶される。図Ｂ１３Ｂは、ソート・メモリ内へと記憶されるクリップされた三角形を示している。例えば、三角形Ｖ３０−Ｖ３１−Ｖ３２は、２つの表示上の三角形Ｖ３０−ＶＡ−ＶＢとＶ３０−ＶＢ−Ｖ３２により表され、ここにＶＡとＶＢはクリッピング処理により作られた頂点である。ある実施例では、フロント・フェーシングはクリップ型属性でも非クリップ型属性でもよく、また「表示上の」頂点が正しく並んでいれば、「フェーシング」は計算できる。
【０３１６】  有用な代替例は、カラー・ポインタ中に２つのカラー・オフセット・パラメータを、１つはＭＬＭポインタを発見するために使用するもの、もう１つはメッシュ中に第１頂点を発見するのに使用するものとして提供する。これにより、連続した三角ファンがＭＬＭポインタの単一のセットを共有できるようになる。
【０３１７】  低費用代替例の場合には、本発明のＧＥＯ機能はホストプロセッサ上で行なわれ、その場合ＣＦＤ又はホストコンピュータは直接ＭＥＸへと供給する。
【０３１８】  高性能代替例では、多数のパイプラインが並行して走る。さもなければ、３Ｄデータベースの特定のタイプにとってボトルネックとなっているパイプラインの部分はさらに麻痺する。例えばある実施例では、２つのＣＵＬブロックが使用され、各々がスクリーンの異なる連続又は非連続領域上で働く。別の実施例では、次々に続くイメージは並行パイプライン上又はそれらの部分上でランできる。
【０３１９】  ある実施例では、レンダリングを実施していたホスト・プロセッサ上の各処理に対して又は各グラフィックス・コンテキストに対して１つずつの割で多数のＭＥＸユニットが提供される。その結果「ゼロ・オーバーヘッド」コンテキスト・スイッチが可能になる。
ＭＥＸオペレーションの例
ＭＥＸは何を実現する必要があるのか及びそれをどのように行なうのかを理解するために、図Ｂ１４、図Ｂ１５、及び図Ｂ１６に示す例を考察しよう。これらの図面は、ＧＥＯからＭＥＸへ送られる、時間順に１から５５まで通し番号をつけた、データの全体フレーム用のパケットのシーケンス例を、ソートメモリ（図Ｂ１５）及び多角形メモリ（図Ｂ１６）内の対応しているエントリと共に示している。簡略化を期すために、図Ｂ１５は、タイル・ポインタ・リストと、ＳＲＴもソートメモリへ書き込むモード・ポインタ・リストは示していない。又、ある好適な実施例では、頂点情報Ｖ２は、多角形メモリへ（多角形メモリのページ内で）最下位アドレスから始めて順番に上位アドレスに移動しながら書き込まれ、一方状態情報Ｓ３は多角形メモリに最上位アドレスから始めて順番に下位のアドレスに移動しながら書き込まれる。多角形メモリは、これらのアドレスが低すぎて追加データを書き込めなくなった時点で満杯となる。
【０３２０】  図Ｂ１４の実施例において、フレームは、フレームの開始時の区切りである開始フレーム・パケットで始まり、フレーム全体につき一定であって、ソース及び目標ウィンドウのＩＤ、フレーム・バッファ・ピクセル・フォーマット、ウィンドウ・オフセット、目標バッファ等を含むパラメータを供給する。次に、当該フレームは一般的に、ＭＥＸ状態ベクトルに影響を与え、ＭＥＸにセーブされ、対応するダーティ・フラグをセットするパケットを含むが、図中の例ではこれはパケット２からパケット１２に当たる。パケット１３はクリア・パケットであり、これは普通、各フレームの開始近くにアプリケーション・プログラムにより供給される。このクリア・パケットはカル・モード・データがソート・メモリに（アドレス０ｘ０００００００から開始して）書き込まれるようにさせ、ＰｉｘＭｏｄｅデータが多角形メモリに書き込まれるようにさせる（他のＭＥＸ状態ベクトル区分はダーティ・フラグがセットされているがクリア・パケットは他のダーティ・ビットによる影響を受けていない）。パケット１４及び１５はＭＥＸ状態ベクトルに影響を及ぼすが、既にダーティとしてラベルを付けられている値を上書きする。従って、パケット３及び５からの上書きされたデータは何れも当該フレームでは使用されずに捨てられる。これは、本発明がメモリにセーブされるデータの量をどのように最小化しようとする傾向にあるかの例である。
【０３２１】  カラー・パケットであるパケット１６は、頂点情報Ｖ２（法線、テクスチャ座標等）を含んでおり、頂点情報Ｖ１がＭＥＸに受信されるまでＭＥＸに保持される。インプリメンテーションにもよるが、パケット１６に等価のものが代わりに多数のパケットから構成できる。ソート・パケットであるパケット１７は、フレームＶ０の１番目の頂点についての頂点情報Ｖ１を保有している。ＭＥＸがソート・パケットを受信すると、ダーティ・フラグが検査され、ソート・パケットの当該頂点が必要とするＭＥＸ状態ベクトルの区分が、頂点情報Ｖ２と共に、多角形メモリに書き込まれる。この例では、パケット１７が受信された時点で、以下の区分、即ちＭａｔＦｒｏｎｔ、ＭａｔＢａｃｋ、ＴｅｘＡＦｒｏｎｔ、ＴｅｘＡＢａｃｋ、ＴｅｘＢＦｒｏｎｔ、ＴｅｘＢＢａｃｋ、ライト、及びスティップルにはダーティ・フラグがセットされる。しかし、この頂点は（ＧＥＯで決められた）フロント・フェーシング多角形の部分であるので、以下の区分、即ちＭａｔＦｒｏｎｔ、ＴｅｘＡＦｒｏｎｔ、ＴｅｘＢＦｒｏｎｔ、ライト、及びスティップルだけが、多角形メモリへ書き込まれることになる（図Ｂ１６ではアドレス０ｘＦＦＦＦＦ００から０ｘＦＦＦＦＦＦＦまでを占めている）。ＭａｔＢａｃｋ、ＴｅｘＡＢａｃｋ、及びＴｅｘＢＢａｃｋはセットされたままで、対応するデータはまだ多角形メモリに書き込まれない。パケット１８から２３まではカラー・パケット及びソート・パケットであり、これらが２つの三角形を有する三角形ストリップを完成させる。これらソート・パケット（パケット１９、２１、及び２３）について、ダーティ・フラグが調べられるが、関連するダーティ・フラグは何れもセットされておらず、これはそれらが何れの状態情報Ｓ３の多角形メモリへの書き込みをも引き起こさないということを意味している。
【０３２２】  パケット２４及び２５はＭａｔＦｒｏｎｔ及びＴｅｘＡＦｒｏｎｔパケットである。それらのデータはＭＥＸに記憶され、対応するダーティ・フラグがセットされる。パケット２６は頂点Ｖ４に対するカラー・パケットである。ＭＥＸがパケット２７を受信すると、ＭａｔＦｒｏｎｔ及びＴｅｘＡＦｒｏｎｔダーティ・フラグがセットされて、データを多角形メモリのアドレス０ｘＦＦＦＦＥＤ０から０ｘＦＦＦＦＥＦＦまでに書き込ませる。パケット２８から３１まではＶ５及びＶ６を記述しており、それにより三角形Ｖ４−Ｖ５−Ｖ６が完成する。
・・・・・・パケット３１は三角形Ｖ４−Ｖ５−Ｖ６に関する頂点情報Ｖ２を完成するカラー・パケットであるが、その三角形はクリッピング・プレーン（例：ディスプレイ・スクリーンのエッジ）によりクリップされる。ＧＥＯが頂点ＶＡとＶＢを生成し、これらはソート・パケット３４及び３５に送られる。ＳＲＴに関する限り、三角形Ｖ５−Ｖ６−Ｖ７は存在せず、つまり、当該三角形はＶ５−ＶＡ−ＶＢとＶ５−ＶＢ−Ｖ６から成る三角ファンに取って代わられるのである。同様にパケット３７から４１は、多角形メモリに対するＶ６−Ｖ７−Ｖ８を完成させ、ソート・メモリに対しＶ６−ＶＢ−ＶＣとＶ６−ＶＣ−Ｖ８の三角ファンを記述する。例えば（アドレス０ｘ０００００Ｂ０で開始する）ＶＢに対するソート・メモリ・エントリはｔｒｉ＿ｆａｎというソート・プリミティブ・タイプを有するが、カラー・ポインタのカラー・オフセット・パラメータはｔｒｉ＿ｓｔｒｉｐにセットされることに注意されたい。
【０３２３】  パケット４２から４６はＭＥＸ状態ベクトル内の値をセットし、パケット４７から５４は三角ファンを記述する。しかし、このファンの三角形はバック・フェーシングなので（バックフェース・カリングは使用禁止と想定する）、パケット４８の受信は、ダーティ・フラグがセットされていることから、ＭＥＸ状態ベクトルのＭａｔＢａｃｋ、ＴｅｘＡＢａｃｋ、及びＴｅｘＢＢａｃｋ区分の多角形メモリへの書き込みをトリガする（これら区分に対する値は早期にフレームに入力されているが、どのジオメトリもそれらを必要としなかった）。ライト区分もダーティ・フラグがセットされているので、多角形メモリに書き込まれ、カル・モードはソートメモリに書き込まれる。
【０３２４】  エンド・フレーム・パケット（パケット５５）はフレームの完了を指す。従って、ＳＲＴはソート・メモリのこのページを完了したものとしてマークすることができ、それによりＳＲＴブロック内の読み取り処理にそれを引き渡す。パケット４３及び４４内の情報は、どのジオメメトリもこの情報を必要としなかったので多角形メモリには書き込まれないことに留意されたい（これらのパケットはフロント・フェーシング・ジオメトリに関係しており、エンド・フレーム・パケットの前にはバック・フェーシング・ジオメトリしか入力されなかった）。
メモリ・マルチ・バファリング及びオーバーフロー
稀ではあっても、多角形メモリはオーバーフローすることもあり得る。多角形メモリ及び／又はソート・メモリは、単一のユーザー・フレームがあまりに多くの情報を保有する場合オーバーフローすることになる。オーバーフロー・ポイントは、多角形メモリのサイズ、状態情報Ｓ３の当該フレーム内での変更の頻度、状態がカプセル封入され表現される方法、及び使用されたプリミティブ特徴（これは頂点毎に必要とされる頂点情報Ｖ２の量を判定する）により異なる。メモリが満杯になると、全プリミティブはパイプにフラッシュされ、ユーザー・フレームは多角形メモリバッファでもう一度満たされて終了する（以後「フレーム・ブレーク」と称する）。ＳＲＴとＭＥＸが専用メモリを有するある実施例では、ソート・メモリ・オーバーフローは同じオーバーフロー・メカニズムをトリガする点に留意されたい。多角形メモリとソート・メモリ・バッファは矛盾なく保持されねばならない。一方のメモリのオーバーフローに起因するもう一方のメモリのスキッドは取り消されねば（又は、できれば回避されねば）ならない。このように、ＭＥＸでは、オーバーフローに起因するフレーム・ブレークは、ソート・メモリ・オーバーフローが発生したというＳＲＴからの信号により、又はＭＥＸ自身のメモリ・オーバーフローにより起きることになる。ＭＥＸのソートメモリ・オーバーフロー信号はＭＥＸ多角形メモリ自身のオーバーフローと同じやり方で対処される。
【０３２５】  多角形メモリ・オーバーフローはかなり費用がかかることに注目されたい。ある実施例では、多角形メモリは、ソートメモリ同様にダブル・バッファされている。従って、ＭＥＸは１つのバッファに書き込みをすることになるが、一方ではＭＩＪが別のバッファから読み取りをしている。この状況は、ＭＥＸが次の（３番目の）フレームに移れるようになる前に、ＭＩＪが当該フレームを終えるのを待たねばならないので、フレームの処理にディレイを生じさせる。ＭＥＸ及びＳＲＴは論理的に良好に同調する点に留意されたい。しかしながら、ＣＵＬは（一般的には）、ＭＥＸが処理したフレームの読み取りをＭＩＪが開始できる前に、１タイル相当のデータを処理しておく必要がある。このようなわけで、フレーム毎にディレイ又はストールが生じる可能性がある。メモリ・オーバーフローがあるとこの状況がより悪化する。典型的なオーバーフロー状況では、第１フレームは多量のデータを有するが第２フレームにはほとんどデータがないという状態になる可能性が高い。ＭＥＸがシーケンスの次のフレームの処理を開始できる前の経過時間は、（フレーム全体に対するＭＥＸ＋ＣＵＬタイル待ち時間＋フレーム全体に対するＭＩＪフレーム処理に要する時間）であって、（フレーム全体に対するＭＥＸ所要時間＋オーバーフローフレームに対するＭＥＸ所要時間）ではない。この経過時間は普通のフレームに対する時間の２倍近くであることに注目されたい。ある実施例では、この費用は、ソフトウェアにシーン・サイズの見積もりを入手させ、フレームを２つ又はそれ以上のほぼ等しい複合フレームにブレークさせることにより、オーバーフローを最小化又は回避することによって低減される。別の実施例では、一つ又はそれ以上のメモリを使い果たしたときオーバーフローが起きるというポリシーをハードウェアが実現する。
【０３２６】  ある代替実施例では、多角形メモリ及びソート・メモリは、各々がマルチ・バッファされ、２フレームより多くのフレームを扱えるようになっている。この実施例では、ＭＥＸは利用できる追加的バッファリングを有しているので、ＭＩＪがそのフレームを終えるのを待たずして、ＭＥＸは次（３番目の）フレームに移れる。
【０３２７】  様々な代わりの実施例では、多角形メモリとソート・メモリはマルチ・バッファされており、多角形メモリとソート・メモリのサイズは多数の比較的小型のメモリページからダイナミックに割り当てられる。これは、多数のメモリページを保有しているメモリサイズが与えられる場合、マルチ・タスキング・モード（即ち、多数の処理が単一のホストプロセッサまたはプロセッサのセット上で行なわれていること）で処理中の複数のウィンドウに対しメモリが割り当て易くなり、適当な量のメモリが各タスクに対して割り当てられる点で都合がよい。例えば、非常に単純なシーンでは、マルチ・タスクキング・モード内の別の処理によってより詳細にレンダされている複雑なシーンよりも、必要なメモリがはるかに少なくて済む。
【０３２８】  ＭＥＸはソート・メモリ及び多角形メモリの次のページにオーバーフローを引き起こした三角形（またはその状態）を記憶する必要がある。我々が頂点リストのどこにいるのかにもよるが、我々には現在のバッファに既に書き込まれてしまっている頂点を次のバッファに送る必要があるかもしれない。これは、それら頂点を読み返すことにより、または数個の頂点を保持することにより行なわれる。四辺形には３個の先行する頂点が必要であり、ラインは先行する頂点がたった１つでよいが、ポイントは他の頂点とは全く対にならないことに留意されたい。ＭＩＪは、ＭＩＪが多角形メモリのあるページを終了したらＭＥＸに信号を送信する。ＳＴＰ及びＣＵＬは、ＭＥＸとＳＲＴが終えた後にしかタイルについてのプリミティブ処理が開始できないので、ＭＩＪはＶＳＰが到着開始するのを待ってストールするかもしれない。
ＭＬＭポインタ及びモード・パケット・キャッシング
カラー・パケットのように、ＭＩＪは、ＭＬＭポインタのキャッシュも保持する。多角形メモリ中のＭＬＭポインタのアドレスはＭＬＭポインタを独特に識別するので、ＭＬＭポインタ・キャッシュではキャッシュ・エントリ用のタグとしても使用される。カラーポインタは、ＭＬＭポインタのアドレスを入手するためにデコードされる。
【０３２９】  ＭＩＪは、ＭＬＭポインタがキャッシュにあるかどうかチェックする。キャッシュ・ミスが検出されると、ＭＬＭポインタは多角形メモリから検索される。ヒットが検出されると、それはキャッシュから読み取られる。ＭＬＭポインタはここでデコードされて６つの状態パケット、つまり本実施例では、ライト、材料、テクスチャＡ、テクスチャＢ、ピクセル・モード、及びスティップルのアドレスが入手される。この各々に対し、ＭＩＪは多角形メモリから検索する必要のあるパケットを決める。有効なビットがセットされている各状態アドレスに対し、ＭＩＪは、その状態パケットの現在のアドレスに等しいタグが存在するかどうか、対応するキャッシュ・タグを調べる。ヒットが検出されると、対応するキャッシュ・インデクスが使用され、検出されない場合には、データは多角形メモリから検索され、キャッシュ・タグが更新される。データはＦＲＧ又はＰＸＬブロック何れか適切な方に、置き換えられるべきキャッシュ・インデクスと共にディスパッチされる。
ガードバンド・クリッピング
上記ＭＥＸオペレーションの例では、ソート・メモリへ記憶するためにプリミティブをクリップし、多角形メモリへ記憶するためにはそれら同じプリミティブの属性をクリップしない随意的な機構を含んでいると想定した。図Ｂ１７は、ディスプレイ・スクリーンの周りにクリッピング・ガードバンドを含んでいる代わりの方法を示している。この実施例では、以下のクリッピングルール、即ちａ）完全にクリッピング・ガードバンドの境界内にあるプリミティブは何れもクリップしない、ｂ）完全にディスプレイ・スクリーンの外にあるプリミティブは何れも捨てる、ｃ）他の全てのプリミティブをクリップする、というルールの１つが適用される。最後のルールのクリッピングは、ディスプレイ・スクリーン（好ましい選定）又はクリッピング・ガードバンドの何れかにより実施できるが、図Ｂ１７は前者を想定している。この実施例では、それはホストＣＰＵのような他のユニットでも実行可能である。どのルールを適用するかについての決定は、クリッピングと同じく、ＧＥＯによりなされる。
数例のパラメータ詳細
テクスチャＩＤ、その（ｓ，ｔ，ｒ，ｑ）座標、及びミップマップ・レベルが与えられた場合に、ＴＥＸブロックは、テクセルを検索し、必要なテクセル・データをアンパックしてフィルタする責任がある。ＦＲＧブロックは、テクスチャモード情報の他にも、テクスチャＩＤ、ｓ，ｔ，ｒ、Ｌ．Ｏ．Ｄ．レベルをＴＥＸに送る。ＦＲＧからのｓ，ｔ，ｒ（及びおそらくミップ・レベル）は浮動小数点値であることに注目されたい。各テクスチャ毎に、ＴＥＸは１テクセル値（例えばＲＧＢ、ＲＧＢＡ、垂直摂動、明暗度等）をＰＨＧに出力する。ＴＥＸはフラグメントとテクスチャ・カラーを組み合わせず、これはＰＨＢブロックで行われる。ＴＥＸはテクスチャ・パラメータとテクスチャ座標を必要とする。テクスチャ・パラメータは、ＴＥＸブロックの２つのテクスチャ・パラメータ・キャッシュから入手される。ＦＲＧはＬ．Ｏ．Ｄ．計算の際にテクスチャ幅及び高さパラメータを用いる。ＦＲＧはテクスチャ・ディメンジョン・フィールド（ＭＥＸ状態ベクトル中のパラメータ）を使用して、テクスチャ寸法を判定し、可能であるならＴｅｘＣｏｏｒＳｅｔ（ＭＥＸ状態ベクトル中のパラメータ）を使って座標セットをそれに関係付ける。
【０３３０】  同様に、カル・モードでは、ＭＥＸはプリミティブ・タイプ次第で、ライン幅属性及びポイント幅属性のうち１つを剥ぎ取ってもよい。頂点がポイントを定義している場合は、ライン幅が投げ捨てられ、頂点がラインを定義している場合はポイント幅が投げ捨てられる。ＭＥＸはライン幅とポイント幅のうちどちらか片方をＳＲＴに送り込む。
ＰＨＢブロックのプロセッサ割当
タイルが処理されるにつれ、通常は何れの所与タイル内にも多数の異なる３Ｄオブジェクトが見えてくる。ＰＨＢブロック・データ・キャッシュは、従って通常、１つより多くのオブジェクトに対応する状態情報及びマイクロコードを記憶する。しかし、ＰＨＢは多数のプロセッシング・ユニットから構成されているので、データ・キャッシュからの状態情報は必要なプロセッシング・ユニットに一時的にコピーされる。一旦、特定のオブジェクトからのフラグメントに関する状態情報が特定のプロセッサに送られると、そのオブジェクトからの他の全てのフラグメントもそのプロセッサに向けられることが望ましい。ＰＨＢは、どのオブジェクトの状態情報がブロック内のどのプロセッシング・ユニットにキャッシュされたかの航跡を保持し、同じオブジェクトに属する全フラグメントが同じプロセッサに送られるように試みる。随意的に、ＰＨＢユニットのプロセッサ又はエンジンの間に負荷の不均衡がある場合には例外が起きることもあり、その場合には、フラグメントは別のプロセッサに割当てられる。このオブジェクト・タグ・ベースのリソース割当はＰＨＢのフラグメント・プロセッサ又はフラグメント・エンジンに関連して起きる。
下流ブロックでのデータ・キャッシュ管理
ＭＩＪブロックは、ＶＳＰがそのステージに到着する前に、ＶＳＰ内のピクセル・フラグメントを処理するのに必要な全情報を、ＦＲＧ、ＴＥＸ、ＰＨＢ、及びＰＩＸブロックが確実に持っているようにする責任がある。換言すると、プリミティブの（即ち、その頂点全ての）頂点情報Ｖ２は、ＭＬＭポインタ中のポインタにより指される６つのＭＥＸ状態ベクトル区分と同じく、それら各々のブロックに在る必要があり、そうして始めてＶＳＰフラグメントが処理できる。ＭＩＪが、各ＶＳＰ毎に、ＭＬＭポインタ、状態パケット、及びカラー頂点を検索するつもりなら、ＶＳＰ毎にほぼ１ＫＢのデータ量になる。毎秒１２５Ｍ  ＶＳＰとすれば、データの読み取りに１２５ＧＢ／秒の多角形メモリ帯域幅と、データをパイプラインに送り込むのにも相当分が必要となる。各ＶＳＰ毎に全てのデータを検索するのは望ましくなく、何らかのキャッシングの形態が望まれる。
【０３３１】  ＶＳＰとプリミティブにあるコヒーレンスがあると考えるのは道理に適っており、我々は同じプリミティブに対応しているＶＳＰのシーケンスを入手しようとする。我々は、このコヒーレンスを使って、多角形メモリから読み出されてフラグメント及びピクセルブロックに転送されるデータの量を減らすことができる。現在のＶＳＰが前のＶＳＰと同じプリミティブから生じているのなら、我々はデータ検索をする必要がない。先に指摘したように、ＶＳＰはプリミティブ順にＭＩＪに到着するのではない。そうではなくて、タイル上でのＶＳＰスキャン順になっており、つまり、スキャンラインを横切る異なるプリミティブに対するＶＳＰが差し挟まれているかもしれないということである。この理由により、現在及び前のＶＳＰのみに基づくキャッシング・スキームは、帯域幅を大凡８０％しか削減しない。
【０３３２】  本発明によれば、タイル又はクオッド・タイルのような領域全体上のプリミティブ・コヒーレンスを利用する方法及び構造が教示されている。（タイルサイズを１６×１６とすると、５０ピクセル三角形は平均すると３個のタイルにタッチすることになる。同様に３２×３２のタイルの場合は、同じ三角形が１．７個のタイルにタッチすることになる。従って、当該領域上のプリミティブ・コヒーレンスを考えると帯域幅要件は著しく低減される。）これは、ＭＬＭポインタ、状態区分の各々、及びＭＩＪのカラー・プリミティブに対するキャッシュを保持することにより実現される。各キャッシュのサイズは、タイル上でそれらが起きる頻度により選定される。このスキームは多角形メモリからデータを検索する場合の問題を解決することはできるが、我々には依然としてデータが変更される都度データをＭＩＪからＦＲＧ及びＰＸＬブロックに転送することに対処する必要がある点に留意されたい。我々はこれを以下の方法で解決する。
キャッシュされたデータ及びタグのデカップリング
ＭＩＪにより検索されたデータは、他のブロックにより消費される。従って、我々はそれらのブロック内にキャッシュデータを記憶する。図Ｂ１８に示すように、ＦＲＧ、ＴＥＸ、ＰＨＢ、及びＰＩＸブロックは、キャッシュのセットを有しており、各々のサイズは、１タイル内のキャパシティ・ミスを回避するため、（又は、キャッシュが大きくできる場合は、例えば４タイルで１セットのようなタイルの１セット内のキャパシティ・ミスを回避するために）別々のエントリの予想数に基づき他とは切り離して決められる。これらのキャッシュは、それらのキャッシュ・ライン・エントリに入る実際のデータを保持する。ＭＩＪは、ユニット各々に対する関連データを多角形メモリから検索しそれをユニットに送る責任を持っているので、４つの前記ユニット内のキャッシュ各々の現在の状態を知る必要がある。これは、ＭＩＪ内のキャッシュの各々に対するタグを保持し、ＭＩＪにキャッシュ管理を全てさせることにより実現される。こうして、データはそれを必要とするブロックに在り、タグはキャッシュそれぞれに対するＭＩＪに在る。ＭＩＪがプロセッシング・ユニットそれぞれの状態を知っているという状況で、ＭＩＪがそれらユニットのうちの１つに送られるべきパケットを受信すると、ＭＩＪはプロセッシング・ユニットがその新しいパケットを処理するための必要な状態を持っているかどうかを判定する。持っていなければ、ＭＩＪは先ずそのプロセッシング・ユニットに必要な状態情報が入ったパケットを送り、続いて処理されるべきパケットを送る。このやり方だと、処理されるべきデータ・パケットを受信した際、どのプロセッシング・ユニット内にもキャッシュ・ミスが起きない。このモード注入オペレーションのフローチャートを図Ｂ１９に示す。
【０３３３】  ＭＩＪは多数のデータ・キャッシュ、即ちＦＲＧ（カラー・キャッシュ）に１つ、ＴＥＸ（ＴｅｘＡ、ＴｅｘＢ）、ＰＨＧ（ライト、材料、シェーディング）及びＰＩＸ（ＰｉｘＭｏｄｅ及びスティップル）の各ブロックに２つずつを管理する。これらキャッシュそれぞれに対し、タグはＭＩＪにキャッシュされ、データは対応するブロックにキャッシュされる。ＭＩＪはタグと共にデータエントリのインデクスも保持する。これら７つのキャッシュに加えて、ＭＩＪは効率のために更に２つのキャッシュを内部に保持しており、その１つはカラー・デュアルオクト・キャッシュでもう１つはＭＬＭポインタ・キャッシュであるが、これらに関しては、タグとデータの両方がＭＩＪに在る。この実施例では、これら９つのタグ・キャッシュ各々は完全に関係付けられており、キャッシュ・タグ・ルックアップにはＣＡＭを使用して単一クロックサイクル内にルックアップができるようになっている。
【０３３４】  ある実施例での、これらキャッシュを下表に掲載する。
2004272928.tif 000017
【０３３５】  ある実施例では、キャッシュ置換ポリシーは、ＭＩＪ内の全キャッシュにおいて先入れ先出し（ＦＩＦＯ）論理に基づいている。
ＦＲＧのカラー・キャッシング
「カラー」キャッシングは、カラー・パケットをキャッシュするのに使用される。使用可能な処理機構の範囲により、カラー・パケットは、多角形メモリ内では２、４、５、又は９デュアルオクト長である。更に、プリミティブは、それがポイント、ライン、又はフィルド三角形の何れであるかにより、それぞれ１つ、２つ又は３つのカラー頂点を必要とする。他のキャッシュとは異なり、カラー・キャッシングは、キャッシュ・ルックアップ及び置換という通常の問題に加えて、可変データサイズの問題に対処する必要がある。カラー・キャッシュはプリミティブに対するデータを保持するのであって、個々の頂点に対するデータを保持するのではない。
【０３３６】  ある実施例では、ＦＲＧブロックのカラー・キャッシュは１２８個のフル性能カラー・プリミティブを保持できる。ＭＩＪのＴａｇＲａｍはＦＲＧブロックのカラーデータ・キャッシュに１対１で対応する。カラー・アドレスはカラー・プリミティブを個別に識別する。ある実施例では、２４ビットカラー・アドレスがカラー・キャッシュ用のタグとして使用されている。
【０３３７】  カラー・キャッシングは、２段階プロセスとして実行される。ＶＳＰに出会うと、ＭＩＪは先ずカラー・プリミティブがカラー・キャッシュにあるかどうかを調べる。キャッシュ・ヒットが検出されれば、そのカラー・キャッシュ・インデクス（ＣＣＩＸ）は対応するキャッシュ・エントリのインデクスである。カラーキャッシュ・ミスが検出されれば、ＭＩＪは、カラー・アドレスとカラー・タイプを使って、カラー・プリミティブに対し検索されるべきデュアルオクトを決める。我々は、相当数の「カラー」プリミティブがストリップ又はファンの一部であると予想している。ここでカラー頂点検索パターンにコヒーレンスを活用する機会がある。これは「カラー・デュアルオクト」キャッシングを介して行なわれる。ＭＩＪは、カラー頂点データから最も新しく検索された３２個のデュアルオクトのキャッシュを保持する。各デュアルオクト毎に、ＭＩＪはカラー頂点データから最も新しく検索された３２個のデュアルオクトのキャッシュを保持している。各デュアルオクト毎に、ＭＩＪは、ＭＩＪブロックのカラー・デュアルオクト・キャッシュを調べて、データが既に存在するか否かを見る。ＲＤＲＡＭフェッチ・リクエストは、欠けたデュアルオクトについて生成される。各検索されたデュアルオクトはデュアルオクト・キャッシュを更新する。
【０３３８】  一旦カラー・プリミティブに対応する全データ（デュアルオクト）が入手されてしまうと、ＭＩＪはＦＩＦＯ又は別のロード・バランシング・アルゴリズムを使ってカラー・キャッシュ・インデクス（ＣＣＩＸ）を生成する。カラー・プリミティブ・データはパッケージ化されフラグメント・ブロックに送られるが、ＣＣＩＸはフラグメント・ブロックに出て行くＶＳＰに組み込まれている。
【０３３９】  ＭＩＪは、３種類のカラー・キャッシュ・フィル・パケットをＦＲＧブロックに送る。カラー・キャッシュ・フィル０パケットは、フル性能でレンダされたプリミティブに対応し、カラー・キャッシュに１キャッシュラインを要求する。カラー・キャッシュ・フィル１パケットは、ハーフ性能モードでレンダされたプリミティブに対応し、カラー・キャッシュ内の２キャッシュラインを満たす。カラー・キャッシュ・フィル・パケットの３番目のタイプは、他の様々なパフォーマンスモードに対応し、フラグメント・ブロック・カラー・キャッシュ内の４キャッシュラインを占める。４つのエントリを他の全ての性能モードに割当てると、我々が３分の１割のプリミティブに対して３つのカラー・キャッシュ・エントリを使おうとするよりも、キャッシュ保守がずっと簡単になる。
【０３４０】  本発明を数例の特定の実施例に関連付けて記述してきたが、この記述は本発明の説明を目的としており、本発明を限定するものと考えるべきではない。特許請求の範囲に定義されている本発明の精神及び範囲を逸脱することなく、様々な修正が当業者により加えられるであろう。
Ｖ．ソート機能ブロック（ＳＲＴ）の詳細な説明
本発明について、明暸さと理解を図るために図及び例により以下に詳細を説明する。本発明の教示に鑑みて、特許請求の範囲に定義する精神又は範囲から逸脱することなく、ある変更及び修正が本発明に加えられうることは当業者には自明であろう。我々は先ずトップレベル・システムのアーキテクチャについて説明する。節の見出しは便宜上設けているのであって、開示内容を限定するものと捉えられるべきではないが、本発明の様々な態様の全ては、見出しでそういうものとして具体的に分類された幾つかの節に分けて記述している。
概観
本発明は、オブジェクト／プリミティブを、それらが共通座標系に変換された後、即ちオブジェクト座標からアイ座標へ、そして次にスクリーン座標へと変換された後、グラフィクス・パイプラインの真ん中でソートする。これは、プリミティブが変換されてしまう前に、グラフィクス・パイプラインの始めに、プリミティブをソートするためにホスト・コンピュータ上でソフトウェア・アプリケーションを実行する必要性が排除できるので有用である。このやり方で、本発明ではグラフィクス・パイプラインの帯域幅要件を増やさない。
【０３４１】  加えて、本発明はパイプラインの終了前にイメージ・データを空間的にソートし、ウィンドウの可視部分を表しているイメージ・データだけをグラフィクス・パイプラインの次のプロセッシング・ステージへと送る一方で、ウィンドウの可視部分に寄与しないイメージ・データ又は架空のイメージ・データを捨てる。
【０３４２】  本発明は、グラフィクス・パイプラインの前のステージが、あるイメージ・データはメモリの記憶容量をオーバーフローすることなくメモリ内へフィットしないという表示を与えられるような、グラフィクス・パイプライン内の有限なメモリ・リソースを効率的に管理するためのコンピュータ構造及び方法を提供する。
【０３４３】  本発明は、次にレンダするリソースを横切るイメージ・データを統計的に均衡させる方法で、イメージ・データをグラフィクス・パイプラインの次のステージに送ることにより、３−Ｄグラフィクス・パイプラインの次のステージでのシーン・コンプレキシティと水平コンプレキシティという影響を克服するための構造及び方法を提供する。
【０３４４】  図Ｃ１は、イメージ・データをグラフィクス・パイプライン内で空間的にソートするためのシステム１００の１つの実施例を示しており、様々なソフトウェア及びハードウェア・エレメントが互いにどのように協力し合うかを描いている。本発明の目的に沿って、空間ソーティングとはイメージ・データを２−Ｄウィンドウの多数の領域に関しソートすることを指す。システム１００は、プログラムされた汎用コンピュータ１０１と３−Ｄグラフィクス・プロセッサ１１７を使用する。コンピュータ１０１は、概括的には設計は従来型であり、ａ）１つ又はそれ以上のデータ・プロセッシング・ユニット（ＣＰＵ）１０２、ｂ）大容量記憶装として、高速第１メモリ１０６ａ、キャッシュメモリ１０６ｂ、及び低速第２メモリ１０６ｃ、のようなメモリ１０６ａ、１０６ｂ、１０６ｃ、又はこれら３つのタイプのメモリの組み合わせ、ｃ）ディスプレイモニタ１０５ａ、キーボード１０５ｂ、及びポインティング・デバイス１０５ｃを含む随意的ユーザー・インターフェース１０５、ｄ）特化されたグラフィクス・ハードウェアにインターフェースを提供する、例えばアドバンスト・グラフィクス・ポート（ＡＧＰ）のようなグラフィクス・ポート１１４、ｅ）Ｉ／Ｏバス１１２を横断してグラフィクス・ポート１１４に連結され、高性能３−Ｄグラフィクス・プロセッシングを提供する３−Ｄグラフィクス・プロセッサ１１７、及びｆ）ＣＰＵ１０２、メモリ１０６、特化グラフィクス・ハードウェア１１４、３−Ｄグラフィスク・プロセッサ１１７、及び随意的なユーザー・インターフェース１０５を相互連結するための１つ又はそれ以上の通信バス１０４を備えている。
【０３４５】  Ｉ／Ｏバス１１２は、これに限定するわけではないが、アドバンスト・グラフィクス・ポート・バス、周辺コンポーネント・インタコネクト（ＰＣＩ）バス、工業用標準アーキテクチャ（ＩＳＡ）バス、拡張工業用標準アーキテクチャ（ＥＩＳＡ）バス、マイクロチャネル・アーキテクチャ、ＳＣＳＩバス等を含む、何れのタイプの周辺バスでもよい。ある好適な実施例では、Ｉ／Ｏバス１１２はアドバンスト・グラフィクス・ポート・プロである。
【０３４６】  本発明は、コンピュータ１０１のある実施例が、グラフィクス・ハードウェアＩ／Ｏをグラフィクス・プロセッサ１１７に向けて待ち行列に入れるために、グラフィクス・ポート１１４のもう一方側にコマンド・バッファ（図示せず）を有する場合も考慮している。
【０３４７】  メモリ１０６ａは、通常、オペレーティング・システム１０８及び１つ又はそれ以上のアプリケーション・プログラム１１０、又はそれぞれが通常ランタイムにメモリ１０６の別々のアドレス空間を占めるプロセスを含んでいる。オペレーティング・システム１０８は、通常、例えば、３−Ｄグラフィクスへアクセスするためのアプリケーション・プログラム・インターフェース（ＡＰＩ）をサポートすることを含めて、基本的なシステムサービスを提供する。ＡＰＩとは、グラフィクス・デバイス・インターフェース、ダイレクト・ドロー／ダイレクト３−Ｄ、及びオープンＧＬＲのようなものである。ダイレクト・ドロー／ダイレクト３−Ｄ、及びオープンＧＬＲは全てよく知られたＡＰＩであり、そのためここではこれ以上詳しくは論じない。アプリケーション・プログラム１１０は、例えばイメージをビューイング及びマニピュレーティングするためのユーザー・レベル・プログラムを含んでいてもよい。
【０３４８】  グラフィクス・パイプライン内のイメージ・データをソートするために、ラップトップの専用ゲーム・コンソール又は他のタイプのポータブル・コンピュータを本発明に接続することもできると理解されたい。更に、サーバに接続されたローカルエリア・ネットワーク上のワークステーションを、グラフィクス・パイプライン内のイメージ・データをソートするために、コンピュータ１０１の代わりに使うこともできる。従って、コンピュータ１０１の詳細な仕様が本発明と特別な関係にあるのではないことがはっきりしたはずである。パーソナル・コンピュータ１０１は、単に、３−Ｄグラフィクス・プロセッサ１１７に対するメッセージの送受信用の従来型インターフェースとして機能するだけである。
【０３４９】  図Ｃ２には、３−Ｄグラフィクス・プロセッサ１１７の代表的実施例を示しており、これは、コンピュータ１０１内の別のＰＣボードとして、コンピュータ１０１のマザーボード上に統合されたプロセッサとして、又は独立型プロセッサとして、Ｉ／Ｏバス１１２又は他の通信リンクを介してグラフィクス・ポート１１４に連結して設けることができる。
【０３５０】  空間的ソーティング・ステージ２１５は、以後しばしば「ソート１２５」とも称するが、このステージはグラフィクス・プロセッサ１１７の多数のプロセッシング・ステージのうちの１つのプロセッシング・ステージとして実行される。ソート２１５は内部バス２１１及び信号ライン２１２を介して他のプロセッシング・ステージ２１０に接続されている。ソート２１５は内部バス２１６及び信号ライン２１７を介して他のプロセッシング・ステージ２２０に接続されている。
【０３５１】  ソート２１５とグラフィクス・パイプライン２００の先行ステージとの間を内部バス２１１及び信号ライン２１２を介してそれぞれ送られたイメージ・データ及び信号については、空間的ソーティング２１５とモード抽出４１５の間のインターフェースに関連付けて後に詳しく説明する。ソート２１５とグラフィクス・パイプライン２００の次のステージとの間を内部バス２１６及び信号ライン２１７を介してそれぞれ送られたイメージデータ及び信号については、空間的ソーティング２１５とセットアップ５０５の間のインターフェースに関連付けて後に詳しく説明する。
【０３５２】  内部バス２１１及び内部バス２１６は、これに限定する訳ではないが、周辺コンポーネント・インタコネクト（ＰＣＩ）バス、工業用標準アーキテクチャ（ＩＳＡ）バス、拡張工業用標準アーキテクチャ（ＥＩＳＡ）バス、マイクロチャネル・アーキテクチャ、ＳＣＳＩバス等を含む何れのタイプの周辺バスであってもよい。
他のプロセッシング・ステージ２１０
本発明のある実施例では、他のプロセッシング・ステージ２１０（図Ｃ２を参照）は、例えば、ソート２１５に先行するステージがソート２１５に空間データを提供する限りにおいて、他の何れのグラフィクス・プロセッシング・ステージをも含むことができる。
【０３５３】  図Ｃ４には、コマンドフェッチ及びデコード４０５、ジオメトリ４１０、及びモード抽出４１５を含む、他のプロセッシング・ステージ２１０の好適な実施例の例を示している。これら他のプロセッシング・ステージ２１０のそれぞれにつきここで簡単に論議する。
【０３５４】  ＣｍｄＦｅｃｈ／Ｄｅｃｏｄｅ４０５即ち「ＣＦＤ４０５」は、グラフィクスポート１１４を介してホストコンピュータ１０１との通信を扱う。ＣＦＤ４０５は、ビットマップ・ブリット・ウィンドウ・オペレーションのような２−Ｄスクリーン・ベースのデータを、バックエンド４４０に直接送信する（図Ｃ４バックエンド４４０参照）が、それは、このタイプの２−Ｄデータは通常、他のプロセッシング・ステージ２１０又は他のプロセッシング・ステージ２４０中のその他のプロセッシング・ステージに関連して更に処理される必要がないからである。全ての３−Ｄオペレーションデータ（例えば、必要な変換マトリクス、材料及びライト・パラメータ、及び他のモード・セッティング）はＣＦＤ４０５によりジオメトリ４１０に送られる。
【０３５５】  ジオメトリ４１０は、ポイント、ライン・セグメント、三角形のような、以後しばしば「プリミティブ」と称する、フレーム・ジオメトリック・プリミティブを３−Ｄモデルで表示するのに関係する計算を行なう。これらの計算には変換、頂点ライティング、クリッピング及びプリミティブ・アッセンブリが含まれる。ジオメトリ４１０は、「正しく方位が定められた」ジオメトリ・プリミティブをモード抽出４１５に送る。
【０３５６】  モード抽出４１５（ＭＥＸ）はジオメトリ４１０からのインプット・データ・ストリームを２つの部分、即ち、１）フレームジオメトリ座標のような空間データ及び陰面除去に必要なあらゆる他の情報と、２）カラー、テクスチャ、及びライティング情報のような非空間データとに分ける。空間データはソート２１５に送られる。非空間データは多角形メモリ（図示せず）に記憶される。（モード注入５１５（図Ｃ５参照）は後刻、非空間データを検索し、それをグラフィクス・パイプライン２００に再び関係付ける。）
プロセッシング・ステージ２１０の詳細は、本発明の具現化には必要ではないので、他のプロセッシング・ステージ２１０についてはここではこれ以上詳しく論じない。
空間ソーティング２１５
ソート２１５のＩ／Ｏサブシステム・アーキテクチャは、２−Ｄウィンドウの限界を定義する多数の等しいサイズの領域のどれが、イメージ・データにより識別された多角形メモリによりタッチされているかにより、イメージ・データを空間的にソートするという必要性に合わせ設計されている。ソート２１５は更に、空間的にソートされたイメージ・データを、タイル順というやり方で、Ｉ／Ｏバス２１６を横断してグラフィクス・パイプライン２００又はパイプライン２００の次のステージへ効率よく送るための必要性に合わせて設計されている。
トップレベル・アーキテクチャ
図Ｃ３には、代表的構造と共にデータ記憶装置とデータフローの関係を例証するために、ソート２１５の好適な実施例の例を示している。上で論じた目標を達成するために、ソート２１５は、並行して作動するように設計された２つの基本的制御ユニット、即ち、書き込み制御３０５及び読み取り制御３１０を使う。基本的な着想は、書き込み制御３０５が、グラフィクス・パイプラインの前のページから受信したイメージ・データを空間的にソート・メモリ３１５内へとソートし、それに続き読み取り制御３１０に、ソートされた空間データをソート・メモリ３１５からグラフィクス・パイプラインの次のステージへ送るように通知するというものである。書き込み制御３０５と読み取り制御３１０の更に詳しい説明については、図Ｃ８、図Ｃ９，及び図Ｃ１８それぞれを参照されたい。
【０３５７】  本発明は、ウィンドウの可視部を表すイメージ・データだけをグラフィクス・パイプラインの後のステージに送り、一方でウィンドウの可視部に寄与しないイメージ・データ即ち架空のイメージ・データを捨てるための構造及び方法を提供することにより、現時点における最先端の技術水準の欠点を克服する。この実施例については、読み取り制御３１０及びシザー・ウィンドウに関連して後に詳しく説明する。
【０３５８】  本発明の更に別の好適な実施例では、書き込み制御３０５は、保証された保存性メモリ見積もりを実行して、グラフィクス・パイプライン２００内の前の処理からのイメージ・データをソートメモリ３１５内にソートするに当たり十分なソート・メモリ３１５が残っているかどうか、又は潜在的なソート・メモリ３１５バッファ・オーバーフロー状況が存在しているかどうかを判断する。保証された保存性メモリ見積もりは、図Ｃ１１及び図Ｃ１２に関連して後に詳しく論じる。
【０３５９】  本発明の更に別の好適な実施例では、読み取り制御３１０は、グラフィクス・パイプライン２００の次に続くステータスのレンダリング・リソースが効率良く使用されるように、即ち、パイプライン２００のあるステージがデータのオーバーロード状態になり、一方でパイプライン２００の別のステージがデータを切望しているようなことが起きないように、空間的にソートされたイメージ・データをバランスのとれたやり方でグラフィクス・パイプライン２００内の次のプロセスに（図Ｃ５参照）送る。代わってこの好適な実施例では、多数の後続ステージを通過するデータフローのバランスが保たれる確率が増える。このプロセスについては、その一例を図Ｃ１８に示しているタイル・ホップ・シーケンスに関連付けて後に更に詳しく吟味する。
空間ソーティング２１５とモード抽出４１５の間のインターフェース
パイプライン２００の先行ステージ、例えばモード抽出４１５からソート２１５へと送られる様々なパケットについてこれより説明する。各パケット・タイプ毎に、パケットの全パラメータのテーブルを示している。各パラメータ毎に、ビットの数が示されている。
【０３６０】  表１には、空間パケット１０００の例を示している。パイプライン２００の先行ステージからソート２１５へのインプットの大多数は、例えばソート・プリミティブへとグループ分けされる頂点のシーケンスを含んでいる空間パケットである。頂点は３−Ｄ空間にポイントを記述し、プリミティブのアッセンブリングのための追加情報を保有している。各空間パケット１０００は、１つのソートメモリ頂点パケットが、例えばバッファ０のようなソート・メモリ３１５バッファのインプット・バッファに対する書き込み制御３０５により、データ記憶装置に書き込まれるようにする。
【０３６１】  空間パケット１０００は、例えば、次のエレメント、即ち、トランスペアレント１０２０、ライン・フラグ１０３０、ウィンドウＸ１０４０、ウィンドウＹ１０５０、ウィンドウＺ１０６０、プリミティブ・タイプ１０７０、頂点再使用１０８０、及びライン・ポイント幅１０１０を含んでいる。これらエレメント各々については、書き込み制御３０５又は読み取り制御３１０の何れかでそれらが使用される際に詳しく論じる。
【０３６２】  ライン・ポイント幅エレメント１０１０は、プリミティブがライン又はポイントである場合にジオメトリ・プリミティブの幅を識別する。
【０３６３】  プリミティブ・タイプ１０７０は、頂点が三角形、ライン、ポイントを完成させるか、或いはプリミティブを完成させないのかを判定するために使用される。表７は、各プリミティブ・タイプそれぞれに充てられた値を掲載しており、各値７００５は暗示されるプリミティブ・タイプ７０１０と、各暗示されたプリミティブ・タイプそれぞれに関係付けられた頂点の数７０１５に対応している。プリミティブを完成しない頂点を示すためにスリー（３）という値７００５が使用される。この例は三角形の始めの２つの頂点であり、というのは３番目の頂点だけが三角形プリミティブを完成させるからである。３以外の頂点７００５は完成させる頂点を示している。プリミティブ・タイプ１０７０「０」はポイントに対して使用される。プリミティブ・タイプ「１」はラインに対して使用される。そしてプリミティブ・タイプ１０７０「２」は三角形に対して、たとえそれらがライン又はライン・モード三角形としてレンダされることになる場合でも使われる。
【０３６４】  表２には、開始フレーム・パケット２０００の例を示している。イメージ・データのユーザー・フレームの開始は、ソート２１５によるこのような開始フレーム・パケットを受信することにより指示される。ユーザー・フレームは１つの完成イメージを描くために必要なデータの全てであるが、一方アニメーションは多数の連続したイメージから成っている。開始フレーム・パケット２０００は、パイプライン２００の先行プロセッシング・ステージ、例えば抽出４１５により、パイプライン２００に、ソート２１５へと送り込まれる（図Ｃ４参照）。
【０３６５】  ＰｉｘｅｌＶｅｒｔ２００１及びＰｉｘｅｌＨｏｒｉｚ２００２は、２−Ｄウィンドウ又はユーザー・フレームのサイズを決めるため、書き込み制御３０５により使用される。本発明の好適な実施例では、スーパー・タイル・サイズ２００３及びスーパー・タイル・ステップ２００４エレメントは「スーパー・タイル・ホップ・シーケンス」と称される本発明の方法で、空間的にソートされたイメージ・データをグラフィクス・パイプライン２００の後続ステージ、例えばセットアップ４０５に出力するために、読み取り制御３１０により使用される。スーパー・タイル・ホップ・シーケンスは、図Ｃ１８及び読み取り制御３１０に関連付けて後に詳しく論じる。
【０３６６】  ソート透明モード・エレメント２００５は、読み取り制御３１０により使用されるが、この詳細は、読み取り制御３１０、並びに、空間的にソートされたイメージ・データがパイプライン２００の後続ステージ、例えばセットアップ５０５に出力される順番を決めるために使用されるアウトプット・モードに関連して、後に詳しく説明する。
【０３６７】  ソート２１５は、開始フレーム・パケット２０００をソート・メモリ３１５内へと記憶するのではなく、フレーム・データをフレーム状態バッファ３５０へセーブ（図Ｃ３参照）する。このようなフレーム・データは、例えば、スクリーン・サイズ（Ｘ、Ｙ）タイル・ホップ値（Ｍ）バッファ使用可能（前、後、左、及び右）及び透明モードを含んでいる。
【０３６８】  表３には、ａ）イメージ・データのユーザー・フレームの終了、ｂ）例えばコンピュータ１０１のメモリ１０６ａにおいて起動するアプリケーション・プログラムにより例示されるユーザー・フレームの強制終了、又はｃ）メモリ・オーバーフローに起因するイメージ・データのフレームを多数のフレームに分割する必要性により起きるイメージ・データのフレームの終了、のうちの何れかを指定するためのエンド・フレーム・パケット３０００の例を示している。
【０３６９】  ユーザー・フレームの強制終了がアプリケーション・プログラムにより送られた場合、エンド・フレーム・パケット３０００は、ソフト・エンド・フレーム３０１０エレメントを「１」にセットさせる。ユーザー・フレームの強制終了指示は、現在のイメージ・フレームが終了するように、例えばコンピュータ１０１（図Ｃ１参照）上で起動しているアプリケーションにより例示される単なる要求である。
【０３７０】  バッファ・オーバフロー発生３０１５は、フレーム・パケット３０００のこのような終了がメモリバッファ・オーバーフロー・イベントの結果として受信されていることを示すために、書き込み制御３０５により使用される。ソート・メモリ３１５のオーバーフローに関するこれ以上の情報については、書き込みメモリ３０５、図Ｃ８のステップ８４５を参照されたい。
【０３７１】  表４には、クリア・パケット４０００及びカル・モード・パケット４５００の例を示す。以後、クリア・パケット４０００及び／又はカル・モード・パケット４５００は、組み合わせて、又は別々にしばしば「モード・パケット」と呼ばれる。モード・パケットは通常、多数の頂点に影響する情報を保有する。モード・パケット４０００又は４５００をソート２１５が受信すると、各モード・パケットそれぞれがソートメモリ３１５内へと書き込まれることになる。
【０３７２】  フレームをレンダしている間に、グラフィクス・アプリケーションは、例えばカラー・バッファ、デプス・バッファ、及び／又はステンシル・バッファを含む１つ又はそれ以上のバッファをクリアすることができる。カラー・バッファ、デプス・バッファ、及びステンシル・バッファは知られているので、ここでは詳しく説明しない。アプリケーションは、通常、フレーム・レンダリング・プロセスの開始直後にだけバッファ・クリアを実行する。つまり、プリミティブがレンダされる前である。このようなバッファ・クリアは、クリア・パケット４０００（表４参照）をソート２１５が受信することにより指示される。クリア・パケット４０００はソート２１５により使用されずに、受信された時間順にソートメモリ３１５内へと累積され、読み取り制御３１０の間に出力される。
【０３７３】  ソート２１５は又、例えばモード抽出（図Ｃ４参照）のような、パイプライン２０００の先行ステージからカル・パケット４５００を受信する。シザー・ウィンドウは、２−Ｄウィンドウの長方形部分である。ソート・シザー使用可能４５０４が「１」にセットされている場合は、シザー・ウィンドウが２−Ｄウィンドウに関して使用可能であることを示している。シザー・ウィンドウ座標はカル・パケットの以下のエレメント、即ちソート・シザーＸｍｉｎ４５０５、ソート・シザーＸｍａｘ４５０６、ソート・シザーＹｍｉｎ４５０７、及びソート・シザーＹｍａｘ４５０８により与えられる。本発明のある実施例では、シザー・ウィンドウは書き込み制御３０５（図Ｃ８のステップ８５５参照）及び読み取り制御３１０（図Ｃ１７のステップ１７１５）の両方により使用される。
インターフェース信号
表１５には、ソート２１５とモード抽出４１５の間のインターフェース信号を示している。ソート２１５からモード抽出４１５へのインターフェースは内部データ・バス２１１を横切る単純なハンドシェーク機構である。モード抽出４１５は、ソート２１５が、送信可能信号、即ち、ソート２１５は別のインプット・パケットを受信する準備ができていることを示している、ｓｒｔＯＤ＿ｏｋ２Ｓｅｎｄ１５２０を送信するまで待つ。ソート２１５から信号送信に対するソート・オーケーを受信した後、モード抽出４１５は新しいパケットを内部インプット・バス２１１に置き、データ準備信号、ｍｅｘＯＢ＿ｄａｔａＲｅａｄｙ１５０５を介してデータ・オンが有効パケットであることを示す。
【０３７４】  データ準備信号の受信への応答において、モード抽出４１５により送信された最後のパケットがソート・メモリ３１５内へフィットしないようであれば、ソート２１５はモード抽出４１５にソートバッファ・オーバーフロー・パケット、ｓｒｔＯＤ＿ｓｒｔＯｖｅｒｆｌｏｗ１５２５を信号ライン２１２（図Ｃ２参照）で送り、モード抽出４１５からソート２１５への最後のパケットがソート・メモリ・オーバーフローを引き起こしかねないことを示す。ソート・バッファ・オーバーフローの受信により、モード抽出４１５に対して、モード抽出４１５はソート・メモリ３１５のバッファをスワップする必要があることが示される。スワッピングとは、単に、先に「読み取り」用に指定されたメモリに「書き込み」を向かわせるか、その逆かを意味する。ソート・メモリ３１５のバッファをスワッピングするプロセスについては、図Ｃ８のステップ８４５に示す書き込み制御３１５に関連して後に詳しく説明する。
【０３７５】  モード抽出４１５により送信された最後のデータ・パケットがソート・メモリ３１５内へフィットする見込みがあれば、ソート２１５は２つの信号をモード抽出４１５に送る。１つ目の信号、即ちメモリ内フィット見込み信号、即ちｓｒｔＯＤ＿ｌａｓｔＶｅｒｔｅｘＯＫ１５１５は、モード抽出４１５により送信された最後のパケットがソート・メモリ３１５内へフィットする見込みであることを示す。２つ目の信号、即ち送信に対するソートオーケー信号は、ソート２１５がモード抽出４１５から別のパケットを受信する準備ができていることを示す。
【０３７６】  上記信号の各々を表すために選択された特定の値は、本発明の具現化に必要ないものと理解されたい。各信号が別の信号との関係において、ソート２１５とモード抽出４１５により各信号がお互いに区別され得る、固有の値を有していることだけが重要なのである。
ソートメモリ構造及び編成
ソートメモリ３１５は、ＰＣＲＡＭのような、メモリのフィールド・アップグレーダブル・ブロックから成る。本発明のある実施例では、ソートメモリはシングル・バッファされており、書き込み制御３０５は、ソートメモリ３１５がオーバーフローするまで、又はソート２１５が例えばコンピュータ１０１（図Ｃ１参照）上で起動しているアプリケーションからメモリへの書き込みを停止する指示を受け取るまで、又は書き込み制御３０５がパイプライン２００の先行プロセッシング・ステージ（表３参照）からフレーム・パケット３０００の終了を受信するまで、イメージ・データをそのシングル・バッファ内へ空間的にソートする。メモリ・オーバーフローは、ソート・メモリ３１５又は例えば多角形メモリ（図示せず）のような別のメモリ（図示せず）の何れかが満杯になると起きる。
【０３７７】  このような状況では書き込み制御３０５は、信号ライン３１１を介して読み取り制御３１０に、読み取り制御３１０は空間的にソートされたイメージ・データをソート・メモリから読み取り開始できることを示す信号を送り、空間的にソートされたイメージ・データをＩ／Ｏバス２１６を介してグラフィクス・パイプライン２００の次のステージへと送信する。
【０３７８】  本発明のある好適な実施例では、ソートメモリ３１５は、書き込み制御３０５への書き込みアクセスと読み取り制御３１０への読み取りアクセスを同時に行なうために、第１バッファ即ちバッファ０と第２バッファ即ちバッファ１を含みダブル・バッファされている。この好適な実施例では、書き込み制御３０５及び読み取り制御３１０は信号ライン３１１経由で連絡しており、ソート・メモリ３１５、フレーム状態３５０、及びタイル・メモリ３６０内の様々なキューに記憶されている情報を使用して、それらの各実行ユニットが同期に、並行して、且つ独立的に作動できるようにする。
【０３７９】  ２つのバッファ０又は１のどちらかが、時により入力バッファ又は出力バッファとして作動することになっている。各バッファ０又は１は、ソート・メモリ３１５内に別々のアドレス・スペースを占める。任意のある時に書き込み制御３０５により書き込まれる特定のバッファ（この２つのバッファのうちの片方）が、入力バッファと見なされる。読み取り制御３１０によりデータが読み取られる特定のバッファ（２つのバッファのうちのもう一方）は出力バッファであると見なされる。
【０３８０】  この好適な実施例を説明するに当たり、以下の例、即ち書き込み制御３０５がソート・メモリ３１５の２つのバッファのうちの片方、例えばバッファ０へとイメージ・データを空間的にソートする場合を想定しよう。バッファ０が満杯である場合、又は書き込み制御３０５がグラフィクス・パイプライン２００の先行ステージからエンド・フレーム・パケット３０００（表３参照）を受信することに応じて、書き込み制御３０５はソート・メモリ３１５バッファ０をソート・メモリ３１５バッファ１とスワップして、読み取り制御３１０が空間的にソートされたイメージ・データをソート・メモリ３１５バッファ０からグラフィクス・パイプライン２００の次のステージへ読み出しを開始できるようにするとともに、並行して、書き込み制御３０５がグラフィスク・パイプライン２００の先行プロセッシング・ステージから受信された未ソートのイメージ・データを空のソート・メモリ３１５バッファ１へと継続して空間的にソートするようにする。
【０３８１】  ソート２１５は、三角形に対応するイメージデータを、それがパイプライン２００の先行データから変換され、選別され、クリップされた後、受信する。ソート２１５が受信する変換、選別、クリップ済みのイメージデータの詳細説明については、上記「他のプロセッシング・ステージ２１０」を参照されたい。
【０３８２】  イメージ・データを空間的にソートするため、ソート２１５はイメージ・データを規定のメモリ・アーキテクチャへ編成する。イメージ・データには、例えば多角形座標（頂点）、モード情報（表４参照、クリア・パケット４０００及びカル・パケット４５００）等が含まれる。本発明の好適な実施例では、メモリ・アーキテクチャには、例えば、各メモリ・バッファ、例えばバッファ０とバッファ１を横切ってミラー化された以下のデータ構造、即ち、ａ）データ記憶装置、例えばデータ記憶装置３２０、ｂ）タイル・ポインタ・リストのセット、例えばタイル・ポインタ・リスト３３０、ｃ）モード・ポインタ・リスト、例えばモード・ポインタ・リスト３４０、が含まれる。
【０３８３】  ソート２１５がパイプライン２００の先行ステージから受信するイメージ・データの各フレームに関し、ソート２１５は、３つのタイプのパケットをパケットが受信された順（以後この順番を「インタイム・オーダー」と呼ぶ）に、データ記憶装置３２０内へ記憶するが、これらパケットには、１）頂点毎情報だけを保有するソート・メモリ頂点パケット８０００（表８参照）、２）バッファ・クリアを起こすソート・メモリ・クリア・パケット４０００（表４参照）、３）シザー・ウィンドウ・ドロー・バッファ選択肢を保有するソート・メモリ・カル・パケット４５００（表４参照）が含まれる。
【０３８４】  これら３つのパケット・タイプは２つのカテゴリ、即ち、１）３−Ｄ空間にポイントを記述するための、頂点パケット・タイプ８０００を含む頂点パケット、２）ソート・メモリ・クリア・バッファ４０００パケット及びソート・メモリ・カル・パケット４５００を含むモード・パケット、に分けられる。これより、これら３っのパケット・タイプ並びに関連情報がソート２１５によりどのようにソートメモリ３１５へと記憶されるかについて論じる。
【０３８５】  表５に、頂点ポインタ５００５、クリア・モード・ポインタ５０１５、カル・モード・ポインタ５０２０、及びリンク・アドレス・パケット５０２５を含む、ソート２１５ポインタの例を示している。
【０３８６】  頂点ポインタ５００５は、頂点パケット８０００を指し、ソート２１５によりそれぞれのタイル・ポインタ・リスト（例えば図Ｃ３のタイル・ポインタ・リスト３３０参照）内へ、頂点パケット８０００が受信されデータ記憶装置（例えば図Ｃ３のデータ記憶装置３２０参照）へ記憶される際に、インタイム・オーダーで記憶される。パケット・アドレス・ポインタ５００６は、対応するタイルの部分をカバーするプリミティブの最後の頂点パケット８０００のデータ記憶装置内でのアドレスを指す。
【０３８７】  上記のように、最後の頂点はプリミティブを完成させる（以後、このような頂点を「完成頂点」と称する）。パケット・アドレス・ポインタ５００６は、オフセット５００７と組み合わせて、書き込み制御３０５と読み取り制御３１０によりある一定の状況においてプリミティブに関する他の座標（頂点）を決めるために使用される（このような状況については、書き込み制御３０５及び読み取り制御３１０に関連して後に詳細に説明する）。これより、プリミティブの座標を対応する頂点ポインタ５００５から求めるプロシジャを説明する。
【０３８８】  オフセット５００７を使って、もしあれば、特定のプリミティブの他の頂点の各々を識別する。オフセット５００７が「０」である場合、プリミティブはポイントである。オフセット５００７が「１」である場合、そのプリミティブはラインであり、そのラインのもう一方の頂点は常にパケット・アドレス・ポインタ５００６の直前のアドレスにある頂点である。オフセット５００７が２又はそれ以上である場合、そのプリミティブは三角形であって、（パケット・アドレス・ポインタ５００６が指す）対応する頂点パケット８０００は三角形の完成頂点の座標を保有し、第２頂点は常にパケット・アドレス・ポインタの直前アドレスにあり、第１頂点はパケット・アドレス・ポインタ５００６からオフセットを差し引くことにより求められる。
【０３８９】  透明フラグ５００８は、空間パケット１０００に包含されている透明エレメント１０２０の値に対応している。
【０３９０】  クリア・モード・パケット・ポインタ５０１５は、ソート２１５により、データ記憶装置３２０へ、受信されたときのインタイム・オーダーで記憶されているクリア・モード・パケットを指す。クリア・モード・パケット・ポインタ５０１５は、ソート２１５により、モード・ポインタ・リスト３４０へ、それらが受信されたときのインタイム・オーダーで記憶される。
ソート２１５により受信された各モード・パケットに対し、モード・ポインタ（表５０００参照。モード・パケットのタイプにより、クリア・モード・パケット・ポインタ５０１５かカル・モード・パケット・ポインタ５０２０の何れか）がモード・ポインタ・リストに加え（図Ｃ３参照）られる。これらのポインタ、即ち５０１５又は５０２０の何れかは又、モード・パケットが記憶されているアドレス、即ち５０１６又は５０２１の何れか、読み取り制御３１０に特定のモード・パケットタイプ（クリア４０００又はカル４５００）を告げるビット、即ち５０１７又は５０２２の何れか、及びモード・パケットがソートされた透明モード（詳細は読み取り制御３１０に関連して後に説明）にサブフレーム分割を起こし得るか否かの表示、即ち５０１８又は５０２３の何れかを保有している。
【０３９１】  書き込み制御３０５は、データ記憶装置３２０に記憶されている多角形情報に対するポインタを、それぞれの多角形、例えば三角形、ライン・セグメント、又はポイントが交わるタイルに従ってタイル・ポインタ・リスト３３０のセットへ記憶する。（三角形は、データ記憶装置３２０内の先の２つの頂点と共に、ポインタの目標である頂点により形成される。）これは、タイル毎のポインタのリンクされたリストを作り上げることにより実現され、それぞれのタイル・ポインタ・リスト３３０内の各ポインタは、対応するタイルの部分をカバーしているプリミティブにとっての最後の頂点パケットに対応している。
【０３９２】  イメージデータのメモリへの記憶を説明するため、図Ｃ３を参照するが、特にタイル・ポインタ・リスト３３０への記憶については、以下の例を想定する。三角形が４つのタイル、例えばタイル０  ３３１、タイル１  ３３２、タイル２  ３３３及びタイルＮ  ３３４にタッチしている場合、３番目の頂点、即ち三角形の最後の頂点に対する頂点ポインタ５００５が、それら４つのタッチされているタイルそれぞれに対応する各タイル・ポインタ・リスト３３０に加えられる。換言すると、三角形の最後の頂点を参照する頂点ポインタ５００５は以下のポインタ・リスト３３０、即ち、ａ）タイル０タイル・ポインタ・リスト３３１、ｂ）タイル１タイル・ポインタ・リスト３３２、ｃ）タイル２タイル・ポインタ・リスト３３３、ｄ）タイル３タイル・ポイントレス・ツー３３３、及びｅ）タイルＮタイル・ポインタ・リスト３３４の各々に加えられる。
【０３９３】  ライン・セグメントは同様に、ライン・セグメントが交わっているタイルに従って、タイル・ポインタ・リスト、例えばタイル・ポインタ・リスト３２０へとソートされる。ライン、ライン・モード三角形、及びポイントは関係付けられた幅を有すると理解される。これを説明するには、ポイントが４つのタイルの交点にある場合には４タイル全部にタッチするものと考える。
【０３９４】  さらに詳しい説明として図Ｃ１５を参照すると、ここでは、図Ｃ１６にそれぞれ示す８個のジオメトリ・プリミティブ、１６０５、１６１０、１６１５、１６２０、１６２５、１６３０、１６３５、及び１６４０に関連して、ソート・メモリ３１５バッファ、例えばバッファ０（図Ｃ３参照）へと編成される空間データ及びモードデータを示している。この例では、あるタイル・ポインタ・リスト、１５０１、１５０２、１５０３、１５０４、１５０５、又は１５０６が、図Ｃ１６に図示された２−Ｄウィンドウ内の各タイルＡ、Ｂ、Ｃ、Ｄ、Ｅ、及びＦそれぞれに対して構築されている。この例では、各データ記憶装置３２０エントリ１５０７−１５２３はアドレス、例えばアドレス１５４７、及びデータ標示のタイプ、例えばデータ標示のタイプ１５４８を含んでいる。第１イメージ・データ・パケット、即ち、書き込み制御３０５により受信されるモード・パケット（クリア・パケット４０００又はカル・パケット４５００の何れか）はアドレス０  １５４７に記憶される。
【０３９５】  各頂点ポインタ１５２５−１５４２は、各タイル・ポインタ・リスト１５０１−１５０６により表されるタイルの部分をカバーする対応するプリミティブに対しての完成頂点を保有している頂点パケット１５０９−１５１３、１５１５−１５１９、及び１５２１−１５２３（表８、頂点パケット８０００を参照）を参照する。
【０３９６】  本発明のある好適な実施例では、完成頂点を保有している頂点パケット８０００に対する頂点ポインタＸだけが書き込み制御３０５によりタイル・ポインタ・リストへと記憶される。
【０３９７】  更に図Ｃ１６を参照すると、頂点１４、１５を含むライン・セグメント１６０５はタイルＡ及びＣにタッチしており、頂点１５により完成する。従来の方法では、複合多角形、即ち２つ以上の頂点を有するものについては、パイプラインの最後の頂点が完成頂点であるはずと考えられた。しかしながら、本発明では、例えば、パイプラインの最初の頂点が完成頂点であるとする、他の順序も可能であると考えている。
【０３９８】  書き込み制御３０５は、それぞれパケット１５２２（完成頂点１５を保有している）を参照する第１ポインタ１５２５及び第１ポインタ１５３１（図Ｃ１５参照）を、それぞれタイルＡとタイルＣを表している対応するタイル・ポインタ・リスト１５０１及び１５０３へと書き込む。
【０３９９】  頂点２、３、及び４により識別される三角形１６１０は、タイルＢとＤにタッチしており、頂点４書き込み制御３０５が、（完成頂点４を保有している）パケット１５１１を参照する第１ポインタ１５２６と１５３２（図Ｃ１５参照）を、それぞれにタイルＢとＤを表している対応するタイル・ポインタ・リスト１５０２と１５０４に書き込むことにより完成する。
【０４００】  頂点３、４、及び５により識別される三角形１６１５は、タイルＢとＤにタッチしており、頂点５書き込み制御３０５が、（完成頂点５を保有している）パケット１５１２を参照する第１ポインタ１５２７と１５３３を、それぞれにタイルＢとＤを表している対応するタイル・ポインタ・リスト１５０２と１５０４に書き込むことにより完成する。
【０４０１】  頂点４、５及び６により識別される三角形１６２０は、タイルＤとＦにタッチしており、頂点６書き込み制御３０５が、（完成頂点６を保有している）パケット１５１３を参照する第１ポインタ１５３４と１５３９を、それぞれにタイルＤとＦを表している対応するタイル・ポインタ・リスト１５０４と１５０６に書き込むことにより完成する。
【０４０２】  頂点８、９及び１０により識別される三角形１６２５は、タイルＣとＥにタッチしており、頂点１０書き込み制御３０５が、（完成頂点１０を保有している）パケット１５１７を参照する第１ポインタ１５２８と１５３６を、それぞれにタイルＣとＥを表している対応するタイル・ポインタ・リスト１５０３と１５０５に書き込むことにより完成する。
【０４０３】  ポイント１６４０や三角形１６３０及び１６３５を含む２−Ｄウィンドウ２００内の残りのジオメトリ・プリミティブの各々は、ソートされたライン・セグメント１６０５と三角形１６１０、１６１５、１６２０、１６２５に関連して上に詳細に亘り説明したものと同じアルゴリズムに従ってソートされる。
【０４０４】  本発明のある実施例では、モード・パケット４０００及び／又は４５００、例えばパケット１５０７、１５０８、１５１４、及び１５２０、が書き込み制御３０５により受信されると、それらはインタイム・オーダーでデータ記憶装置のインプット・バッファへとソートされる。受信された各モード・パケット４０００及び／又は４５００に対し、対応するモード・ポインタ（モード・パケットのタイプにより、クリア・モード・パケット・ポインタ５０１５又はカル・モード・パケット・ポインタ５０２０）例えばポインタ１５４３、１５４４、１５４５、及び１５４６がモード・ポインタ・リスト１７０に書き込まれる。
【０４０５】  本発明の更に別の実施例では、ジオメトリ・プリミティブがライン・モード三角形である場合、それはその辺がタッチしているタイルに従ってソートされ、同じタイル上に多数の辺を有するライン・モード三角形は、タイル毎に１つのエントリしか起こさない。
フレーム状態
イメージ・データのフレームが、書き込み制御３０５によりソート・メモリ３１５内へと書き込まれ、続いて読み取り制御３１０によりソート・メモリ３１５から読み出されると、種々のフレーム状態情報の航跡を保持するために、フレーム状態情報はフレーム状態レジスタ３５０内の多数の異なるレベルに記憶され続ける。このような情報には、例えば、２−Ｄディスプレイ・ウィンドウを水平及び垂直に分割する多数の領域、及びフレーム・バッファのデータが「タイムオーダー（時間順）モード」なのか「ソート済み透明モード」なのかが含まれる（これらのモード両方については読み取り制御３１０と図Ｃ１７に関連して後に詳しく説明する）。
【０４０６】  本発明のある実施例では、フレーム状態レジスタ・バッファ３５０は、レジスタ３５１の単一のセットを備えている。しかしながら、本発明のある好適な実施例では、フレーム状態レジスタ３５０は、インプット・レジスタを１セット即ち３５１又は３５２の何れか、とアウトプット・レジスタを１セット即ち３５１又は３５２の何れかの、２セットのレジスタを備えている。２セットのレジスタの何れか、つまり３５１又は３５２は、時によりインプット・レジスタ又はアウトプット・レジスタとして動作する。その任意のある時に書き込み制御３０５により書き込まれている特定のレジスタ（２つのレジスタのうちの何れか）はインプット・レジスタであると見なされる。データが読み取り制御３１０により読み出されている特定のレジスタ（２つのレジスタのうちもう片方）はアウトプット・レジスタであると見なされる。
【０４０７】  ソートメモリ３１５バッファ０がバッファ１とスワップされるとき、フレーム状態レジスタ・バッファ３５１もフレーム状態３５２レジスタへコピーされる。
【０４０８】  これより、フレーム状態レジスタ３５０にフレーム状態情報を記憶するために使用される様々なレジスタへと書き込み制御により記憶された特定の情報について論じる。
【０４０９】  インプット・バッファ・フレーム状態レジスタ、つまりその時どちらがインプット・レジスタであるかにより決まる３５１又は３５２の何れかには、開始フレーム・パケット２０００からフレーム状態がロードされる。書き込み制御３０５が、信号を使って書き込みパイプラインのオペレーティング・モードを決め、セットする。このようなオペレーティング・モードには、例えば、インタイム・オーダー・オペレーティング・モード及びソート済み透明オペレーティング・モードが含まれるが、この両方のモードについては書き込み制御３１０に関連して後に詳しく説明する。
【０４１０】  インプット・バッファ・フレーム状態３５０レジスタ終了フレーム・レジスタ（図示せず）は、フレーム・パケット３０００の終りからロードされる。終了フレーム・レジスタに含まれるデータには、例えばソフト・オーバーフロー標示が含まれる。
【０４１１】  インプット・バッファ・フレーム状態３５０レジスタＦｒａｍｅＨａｓＣｌｅａｒｓレジスタ（図示せず）は、読み取り制御３１０による使用のために書き込み制御３０５によりセットされる。書き込み制御３０５は、アプリケーションに対するクリア・パケット４０００の受信に応えてこのレジスタをセットする。読み取り制御３１０及び図Ｃ１７に関連して後に詳細に説明するが、読み取り制御３１０は、クリア（例えば、ジオメトリに関係付けられたクリア・パケット）を有していないフレーム内のジオメトリを全く持っていないタイルを即刻捨てる。
【０４１２】  ＭａｘＭｅｍレジスタ（図示せず）は、ソート２１５の初期化の間に書き込み制御３０５によりロードされ、フレームの開始時にポインタ初期化に使われる。例えば、それは通常はソート・メモリ・バッファ３１５のサイズを初期化する。
タイルメモリ３６０
本発明のある好適な実施例では、ソート・メモリ３１５のあるデータ構造は、例えばタイル・ポインタ・リスト（例えば、図Ｃ３の、タイル０タイル・ポインタ・リスト３３１、タイル１タイル・ポインタ・リスト３３２、タイル２タイル・ポインタ・リスト３３３、及びタイルＮタイル・ポインタ・リスト３３４参照）及びモード・ポインタ・リスト（例えば、モード・ポインタ・リスト３４０）のような、リンクされたリスト・データ構造として実現されている。リンクされたリスト・データ構造及びリンクされたリストデータ構造のオペレーション（リンクされたリスト・データ構造からのエレメントの加減算）は知られているので、ここではこれ以上詳しく説明しない。
【０４１３】  通常、リンクされたリスト・データ構造にエレメントを加算すると、読み取り／修正書き込みオペレーションとなる。例えば、あるエレメントをリンクされたリストの終りに加えると、リンクされたリスト内の最後のエレメントの次のポインタが読み出され、新しく加えられたエレメントのアドレスに等しく修正されなければならない。単一の読み取り／修正書き込みの実行には、プロセッサ１１７（図Ｃ２参照）帯域幅が要る。１つの行に十分な読み取り／修正書き込みを行なおうとすると、膨大な量のプロセッサ１１７の帯域幅が消失することにもなりかねない。プリミティブをソート・メモリ３１５へとソートする一方で、書き込み制御３０５はエレメントをリンク・リスト、例えばタイル・ポインタ・リスト及びモード・ポインタ・リスト（図Ｃ３参照）に加える。プロセッサ帯域幅が他のグラフィクス・パイプライン２００オペレーション、例えばセットアップ５０５及びカル５１０（図Ｃ５参照）にも使用できるように、読み取り／修正書き込みオペレーションの数を最少化することが望ましい。必要なのは、読み取り／修正権の数を減少させそれによりプロセッサ帯域幅を増加させるための構造及び方法である。
【０４１４】  本発明のある好適な実施例は、書き込み制御３０５がエレメントをリンクされたリスト・データ構造に追加するために実行せねばならない読み取り／修正書き込みの数を減らす。図Ｃ３には、読み取り／修正書き込みの数を減らすために書き込み制御３０５と読み取り制御３１０により使用されるテイル・メモリ３６０を示している。表６では、テイル・メモリ３６０内のあるエントリ６０００の例をしてしており、それには、ａ）リンク・リスト・データ構造の開始であることを指すａｄｄｒヘッド６００５、ｂ）リンク済みリスト・データ構造の終りであることを指すａｄｄｒテイル６１０１、ｃ）リンク済みリスト・データ構造内のエントリの数を表示するｎｏ．エントリ１０１５か含まれている。
【０４１５】  本発明のある好適な実施例では、ソート・メモリ３１５内の各リンク済みリストデータ構造は、テイル・メモリ３６０内に関係付けられたエントリ６０００を有する。この好適な実施例は、あるエレメントをリンク済みリスト・データ構造に加えるためメモリを割り当てる都度、２つのメモリ位置を割り当てる。このとき、リンク・リスト・データ構造の現時の最後のエレメントにおける「次のエレメント」ポインタ（図示せず）が更新され、第１割当エレメントのメモリ位置のアドレスに等しくなる。次に、第１割当エレメントの「次のエレメント」ポインタ（図示せず）が更新されて、第２割当エレメントのメモリ位置に等しくなる。このやり方で、１つのエレメントをリンク・データ・リストに加えるために書き込み制御３０５が実行すべき読み出し／修正書き込みの数は「書き込み」へと低減される。
【０４１６】  書き込み制御３０５がイメージ・データをソート・メモリ３１５へ空間的にソートし終えると、読み取り制御３１０はテイル・メモリ３６０を使って、それらの中ヘソートされたフレームのジオメトリのどれも有していないタイルを識別する。このプロシジャは読み取り制御３１０及び図Ｃ１７に関連して後に詳しく説明する。
【０４１７】  ソート２１５のある実施例では、テイル・メモリ３６０は１つのバッファ、例えばバッファ３６１を備えている。本発明のある好適な実施例では、テイル・メモリ３６０には、１つのインプット・バッファ３６１と１つのアウトプット・バッファ３６２（以後インプット／アウトプットを「Ｉ／Ｏ」と呼ぶ）が含まれている。２つのバッファ３６１と３６２のうち何れかが時によりインプット又はアウトプット・バッファとして動作する。各バッファ３６１又は３６２はテイル・メモリ３６０内に別々のアドレスを占める。任意のその時に書き込み制御３０５により書き込まれている特定のバッファ（上記２つのバッファのうちの何れか）はインプット・バッファと見なされる。読み取り制御３１０により自身からデータが読み出されている特定のバッファ（上記２つのバッファのもう一方）はアウトプット・バッファと見なされる。書き込み制御３０５がソート・メモリ３１５をスワップするとき、バッファ３６１もバッファ３６２とスワップされる。ソートメモリ３１５のスワッピングについては、図Ｃ８の、書き込み制御３０５のステップ８４５に関連して後に詳しく説明する。
【０４１８】  本発明の更に別の実施例では、読み取り制御３１０が最終時にタイルに対応するジオメトリすべての読み取りを終えた後、ＡＤＤＲ  ＨＥＡＤ６００５は、その各リンク済みリストの開始アドレスに等しくセットされ、ＡＤＤＲ  ＴＡＩＬ６０１０はＡＤＤＲ  ＨＥＡＤ６００５に等しくセットされる（表６参照）。
書き込み制御３０５
本発明のある実施例では、書き込み制御３０５は、例えば、ａ）モード抽出４１５など、グラフィクス・パイプライン２００の先行ステージからイメージ・データをフェッチすること、ｂ）２−Ｄウィンドウ内の領域に関しイメージ・データをソートすること、ｃ）ソート・メモリ３１５内への空間ソートをやり易くする空間関係及び他の情報をソートすること、を含む多数のタスクを行なう。
【０４１９】  本発明のある好適な実施例では、書き込み制御は、上記タスクを実行する他にも、グラフィクス・パイプライン２００の先行ステージ、例えばモード抽出４１５に、ソートメモリ３１５バッファ内には、イメージ・データをソート・メモリ３１５へ空間的にソートするのに十分なメモリが残っているかどうかについての保証された保存性メモリ見積もりを提供する。この好適な実施例では、書き込み制御３０５は又、パイプライン２００の先行ステージと協力してソートメモリ３１５バッファの読み取り制御３１０とのスワップを順番付けすることにより、イメージ・データの新しいフレームと共にメモリ・オーバーフローも管理する。これら様々な実施例のそれぞれについてこれより詳しく説明する。
【０４２０】  書き込み制御３０５を説明するに際し、図Ｃ３の代表的構造と図Ｃ８の書き込み制御３０５の本発明のプロシジャの代表的実施例を参照されたい。ステップ８１０で、ソート２１５はテイル・メモリ３６０を初期化して、ソート・メモリ３１５内の各リンク済みリスト・データ構造毎にエントリ６０００（表６参照）を保有するように、Ａｄｄｒヘッド６００５はＡｄｄｒテイル６０１０に等しく、Ａｄｄｒテイル６０１０は各リンク済みリストデータ構造それぞれの開始のアドレスに等しく、エントリ６０１５の数はゼロにセットされるようにする。
【０４２１】  書き込み制御３０５プロシジャはステップ８１５へ留まり、そこで、パイプライン２００の先行ステージ、例えばモード抽出４１５からイメージ・データをフェッチする。イメージデータは、ユーザー・フレームの開始又は「ユーザー・フレーム」の終了の何れかをそれぞれ指定するパケット（開始フレーム・パケット２０００（表２参照）及び終了フレーム・パケット３０００（表３参照）を含むが、これらは以後まとめて「フレーム制御パケット」と呼ぶこともある）と、モード・パケット（クリア・パケット４０００及びカル・パケット４５００（表４参照）を含む）と、空間パケット６０００（表６参照）とを含んでいる。
【０４２２】  ステップ８２０では、書き込み制御３０５プロシジャは、開始フレーム・パケット２０００が受信された（ステップ８１５）かどうかを判定する。
【０４２３】  書き込み制御３０５が開始フレーム・パケット２０００を受信した（ステップ８１５）場合、それは、イメージ・データ・パケットの新フレームが次に続いていることを意味する。この観点から、フレーム状態パラメータはフレーム状態３５０のインプットＩ／Ｏバッファ、例えばバッファ３５１又はバッファ３５２内（図Ｃ３参照）へ記憶される。このようなフレーム・パラメータについては先に詳しく述べた。
【０４２４】  書き込み制御プロシジャ８００はステップ８２５に留まり、ここで、読み取り制御３１０が先に空間的にソートされたイメージ・データをグラフィクス・パイプライン２００の次のステージへと送るに際し使用中であるか否かを判定する。書き込み制御３０５及び読み取り制御３１０は、信号ライン３１１上に単純なハンドシェーク信号を送る（図Ｃ３参照）ことによりこれを行う。読み取り制御３１０が使用中であれば、書き込み制御プロシジャ８００は読み取り制御３１０が終了するまで待ち続けることになる。
【０４２５】  ステップ８３０で、読み取り制御３１０が使用されていなければ、書き込み制御プロシジャ８００は以下、即ち、ａ）ソートメモリ３１５のバッファ０と１、ｂ）フレーム状態レジスタ３５１と３５２、ｃ）テイルメモリ３６０のバッファ３６１と３６２、をスワップする。ステップ８３０が実行された後、読み取り制御３１０は、空間的にソートされたイメージ・データを、インプット・バッファであったが今はアウトプット・バッファであるものから読み出しを開始でき、一方で並行して、書き込み制御３０５は新しいイメージ・データをアウトプット・バッファであったが今はインプット・バッファであるものへと空間的にソートを開始することができる。（本発明のある実施例では、読み取り制御３１０は、使い終えたバッファのコンテンツをゼロアウトにする。）
本発明のある好適な実施例では、メモリはポインタ・アドレスをそれぞれに読み取りメモリ・バッファ及び書き込みメモリ・バッファに交換することによりスワップされる。例えば、ある実施例では、ａ）書き込み制御３０５は、読み取りメモリ・バッファ（例えば、バッファ１（図Ｃ３参照））を参照する第１ポインタを、書き込み制御３０５が最後にイメージ・データをその内へとソートしていた第１メモリ・バッファ（例えばバッファ０（図Ｃ３参照））の開始アドレスに等しくセットし、ｂ）書き込み制御３０５は、書き込みメモリ・バッファ（本例ではバッファ０）を参照する第２ポインタを、読み取り制御３１０が最後にソートされたイメージ・データをそこからパイプライン２００の次のステージへと読み出していた第２メモリ・バッファの開始アドレスに等しくセットする。
【０４２６】  ステップ８３５で、読み取り制御プロセス８００は、イメージ・データの別のパケットをパイプラインの先行プロセッシング・ステージ、例えばデータ抽出４１５から取り出す。（ステップ８２０に関連して先に述べたように、先行してフェッチされたイメージ・パケットが開始フレーム・パケット２０００ではない場合（ステップ８２０）には、書き込み制御プロシジャ８００はここステップ８３５に留まる。）
ステップ８４０では、パケットが、イメージ・データのフレームの終了を指定するための、フレーム・パケットの終了３０００（表３参照）であるか否かが判定される。このフレーム・パケットの終了３０００は、イメージ・データのフレームの自然終了（ソフト・エンド・フレーム３０１０）の結果として、フレームの強制終了の結果として、或いはイメージ・データのスプリット・フレームとして知られているメモリ・バッファ・オーバーフロー（バッファ・オーバーフロー発生３０１５）の結果として、送られたかもしれない。
【０４２７】  これと並行して、イメージ・フレームの終了がフレームのソフト終了又はフレームのユーザー終了でなかった場合、書き込み制御３０５プロシジャはステップ８６０へ留まり、パケットがユーザー・フレームの終了であるか否かが判定される。ユーザー・フレームの終了とは、アプリケーションがあるイメージを終えたことを意味する。ユーザー・フレームの終了は、オーバーフロー・フレームの場合、次のフレームはこのフレームと「合成」される（これはパイプライン２００の次のステージで実現される）必要があるので、フレームの「オーバーフロー」終了（又はフレームのソフト終了）とは異なる。この観点から、このユーザー・フレームにはもっと空間情報があるという理由で、書き込み制御３０５プロシジャはステップ８１５へ留まり、そこで別のイメージ・パケットがパイプライン２００の先行ステージからフェッチされる。
【０４２８】  ステップ８６５では、読み取りメモリ３１０が、すでに書き込み制御３０５により空間的にソートされたイメージ・データをグラフィクス・パイプライン２００の次のステージへ送信するに際し、使用中であるかどうかが判定される。読み取り制御３１０が使用中である場合、書き込み制御３０５プロシジャは、読み取り制御３１０が完了するまで待ち続けることになる。
【０４２９】  ステップ８７０で、読み取り制御３１０が使用中でない（空間的にソートされたイメージ・データを、アウトプット・ソート・メモリ３１５バッファからパイプライン２００の次のステージに送信していない）場合、読み取り制御３０５プロシジャは、例えば、以下のもの、即ち、ａ）ソートメモリ３１５のバッファ０と１、ｂ）フレーム状態レジスタ３５１と３５２、及びｃ）テイル・メモリ３６０のバッファ３６１と３６２を含めて、インプット・メモリ・バッファとアウトプット・メモリ・バッファ、及びインプット・データ・レジスタとアウトプット・データ・レジスタ、をスワップする。
【０４３０】  ステップ８３０を実行した後、読み取り制御３１０は、ａ）インプット・バッファであったが今はアウトプット・バッファであるものから空間的にソートされたイメージ・データの読み出しを開始し、ｂ）フレーム状態レジスタのインプット・セットであったが今はフレーム状態レジスタのアウトプット・セットであるものからイメージ・データの状態のアウトプット・フレームを決め、そしてｃ）インプット・テイル・メモリ・バッファであったが今はアウトプット・テイル・メモリ・バッファであるものからアウトプット・メモリ・バッファ・リンク済みリスト・データ構造を管理することができる。一方、並行して、書き込み制御３０５はステップ８１５に留まり、新しいイメージ・データを、アウトプット・ソート・メモリ３１５バッファであったが今はインプット・バッファであるものへ空間的にソートを開始できる。
【０４３１】  ステップ８４５（パイプライン２００の先のステージから受信されたイメージ・パケットがフレーム・パケットの終了３０００でなかった、ステップ８４０参照）で、書き込み制御３０５は保証された保存性メモリ見積もりプロシジャを使用して、パイプラインの先のステージから受信したイメージ・データ・パケットを、他の必要な情報（ステップ８３５）例えば頂点ポインタ５００５、又はモード・ポインタ５０１５又は５０２０と共に、記憶するのに十分なソート・メモリ３１５があるかどうか概算する。保証された保存性メモリ見積もりプロシジャ８４５は、図Ｃ１１に関連して後に詳しく説明する。このプロシジャ８４５を用いて、書き込み制御３０５は、ソート・メモリ３１５オーバーフローのせいでパイプライン２００をバックアップすることにより起きる例えばデータの損失のような問題を回避する。
【０４３２】  書き込み制御３０５がイメージ・データを空間的にソートするのに十分なメモリが無い（ステップ８４５）場合、ステップ８５０で、書き込み制御３０５はパイプライン２００の前のステージに信号ライン２１２（図Ｃ２及び図Ｃ３参照）を介して信号を送り、バッファ・オーバーフロー状況により書き込み制御３０５へのイメージ・データの送信を一時的に止める。書き込み制御３０５により使用されるバッファ・オーバーフロー信号の代表例（ｓｒｔＯＤ＿ｓｒｔＯｖｅｒｆｌｏｗ１５２５）については、先に、表１５、及びセクション・インターフェース信号及びソート２１５とモード抽出４１５の間のインターフェースに関連して詳しく述べている。
【０４３３】  パイプライン２００の前のステージは、現在のユーザー・フレームが、多数のフレームに分割されようとしていることを表す終了フレーム・パケット３０００（図Ｃ３参照）を使って、バッファ・オーバーフロー標示（ステップ８５０）に応答することができる。本発明のある実施例では、これはＢｕｆｆｅｒＯｖｅｒｆｏｗｅｄ３０１５を「１」にセットすることにより実現される。
【０４３４】  ソート２１５はこの標示に対して、ａ）ソートメモリ３１５Ｉ／Ｏバッファ、例えばバッファ０とバッファ１（図Ｃ３参照）と、ｂ）フレーム状態レジスタ、例えばフレーム状態レジスタ３６１とフレーム状態レジスタ３６２と、ｃ）テイル・メモリ・バッファ、例えばテイル・メモリ・バッファ３５１とテイル・メモリ・バッファ３５２と、をスワップすることにより応える。
【０４３５】  本発明の更に別の実施例では、ソート２１５は、シングル・バッファされており、エンド・オブ・フレームが、望ましくはソート・メモリ３１５が満杯になる（ステップ８４５）前にインプット・データ・ストリームに起きるようにさせるのは、例えばコンピュータ１０１（図Ｃ１参照）上で起動中のソフトウェア・アプリケーションの責任である。このような状況では、書き込み制御３０５は、ソフトウェア・アプリケーションから、ソート２１５が自身のインプット・バッファを空にしなければならないことを示すヒントを受信することに依存している。
【０４３６】  イメージ・データを空間的にソートするための十分なメモリがある（ステップ８４５）場合、書き込み制御は、図Ｃ９のステップ９０５に示すように、イメージ・データをソートするために以下のステップを実行する。図Ｃ９において、ステップ９０５で、パケットが空間パケット１０００（表８参照）であるか否かが判定され、そうでない場合、ステップ９１０で、パケットはモード・パケット（クリア・パケット４０００又はカル・パケット４５００の何れか。表４参照）に違いないので、そのモード・パケットがデータ記憶装置インプット・バッファ、例えばデータ記憶装置３２０へと記憶される。ステップ９１５で、データ記憶装置のモード・パケットの位置を参照するポインタがモード・ポインタ・リスト・インプット・バッファ、例えばモード・ポインタ・リスト３４０に記憶される。
【０４３７】  パケットが空間パケットだった（ステップ９０５）場合、ステップ９２０で、頂点パケット８０００（表８参照）が空間パケット１０００（表１参照）の情報から生成される。頂点パケット８０００の各エレメントの値は、空間パケット１０００内の同様のエレメントの値と相関している。ステップ９２５で、頂点パケット８０００は、データ記憶装置インプット・バッファ、例えばデータ記憶装置３２０に記憶される。
【０４３８】  ステップ９３０で、空間パケット１０００（ステップ９０５）が完成頂点（プリミティブの最後の頂点）を保有しているかどうかが判定される。空間パケット１０００が完成頂点を保有している（ステップ９３０）場合は、ステップ９３５で、帯域幅を最小限にするために、書き込み制御３０５は、２−Ｄウィンドウのどのタイルがプリミティブによりタッチされているかという、タイトであるが常に保守的な計算を、プリミティブを取り囲んでいる境界画定ボックスのディメンジョンを計算することにより行なう。この好適な実施例のステップ９３５の利点は、次のステップであるステップ９４０で明らかになる。境界画定ボックスについては図Ｃ１３に関連して後に詳細に説明する。
【０４３９】  ステップ９４０で、書き込み制御３０５は、タッチされているタイルの計算を行なって、プリミティブが実際に交わっている境界画定ボックス（ステップ９３５）により識別されるタイルを識別する。タッチされているタイルの計算に使用されるタイルの数を制限するために境界画定ボックスを使用することは、現行技術と比較して有益であり、タッチされているタイルの計算は２−Ｄウィンドウ中の各タイルにつき実行される。
【０４４０】  タッチされているタイルの計算の使用（境界画定ボックスの使用、ステップ９３５）に先立ちタイルの単純拒否及び／又は単純承諾を使用するという概念を考慮に入れなければ、タッチされているタイルの計算それ自体の概念は当技術では知られており、タッチされているタイルの計算の１つの特定セットが、完璧さを期して、且つ有効な開示を提供するための過多の警告を外れて補遺Ａに含まれている。これらの従来からのタッチされているタイルのプロシジャは、本発明の構造及び方法と共に使用することができる。
【０４４１】  ステップ９４５では、プリミティブが交わっている各タイル毎（ステップ９４０）に、データ記憶装置内に記憶されている頂点パケット８０００（ステップ９２５）を指している頂点ポインタ５００５（表５参照）が、プリミティブが交わっている各タイルに対応している各インプット・バッファタイル・ポインタ・リスト、例えばタイル・ポインタ・リスト・バッファ３３０及びタイル０タイル・ポインタ・リスト３３１、及びタイル１タイル・ポインタ・リスト３３２、に記憶される。パケット及びあらゆる関係付けられたポインタをソート・メモリ３１５へと記憶するために使用されるプロシジャのさらに詳しい説明は、ソート・メモリ構造と編成、及び図Ｃ１５に関連して先に行っている。
境界画定ボックス計算
本発明は高速タイル計算プロセッシング（ステップ９４０、図Ｃ９参照）を提供し、更に、パイプライン２００の先行プロセッシング・ステージに対するメモリ使用見積もり（メモリ使用見積もりについては保証された保存性メモリ見積もりプロシジャに関連して後に詳しく説明する）を提供するために、境界画定ボックスを使用する。これよりプリミティブを取り巻く境界画定ボックスを構築するプロシジャを説明するが、ここで境界画定ボックスは等寸法のタイルに分割された２−Ｄウィンドウの少なくとも１個のタイルを備えている。
【０４４２】  境界画定ボックスという着想を説明するに際し、図Ｃ１３を参照頂きたいが、そこには２−Ｄウィンドウ１３００を三角形１３０８に外接している境界画定ボックス１３０７と共に示している。この例では、２−Ｄウィンドウ１３００は水平方向及び垂直方向に６個のタイル、即ち１３０１、１３０２、１３０３、１３０４、１３０５、１３０６に分割されている。境界画定ボックス１３０７は、三角形１３０８がタッチしている可能性のある２−Ｄウィンドウ１３００のタイルのグループを求めるために、書き込み制御３０５が使用する（Ｘｍｉｎ，Ｙｍｉｎ）１３０９及び（Ｘｍａｘ，Ｙｍａｘ）１３１０を含むディメンジョンを有している。
【０４４３】  この例では、三角形１３０８はタイル１３０３、１３０４、１３０５、１３０６それぞれの上又は中に在るので、境界画定ボックス１３０７は、６個のタイル１３０１、１３０２、１３０３、１３０４、１３０５、１３０６のうち、４個のタイル１３０３、１３０４、１３０５、１３０６を含むか、又は「タッチ」している。本例に示すように、境界画定ボックス１３０７のディメンジョンにはジオメトリ・プリミティブ１３０８により「タッチされて」いないが、それでも境界画定ボックス１３０７の部分であるというタイル（本例ではタイル１３０４）が含まれることから、境界画定ボックス１３０７は、プリミティブ１３０８が交差するタイルの保存性見積もりを提供する。
【０４４４】  表５、特に頂点ポインタ５００５を参照しながら、これより、あるプリミティブの座標をそのプリミティブの対応している頂点ポインタ５００５から求め、次にそのプリミティブの座標から境界画定ボックス１３０７のディメンジョンを求めることについて説明する。プリミティブの座標をそのプリミティブの対応する頂点ポインタ５００５から求めるプロシジャに関しては、頂点ポインタ５００５及び表５に関連して先に説明している。
【０４４５】  プリミティブの座標（頂点）が求められたら、頂点の大きさを用いてそのプリミティブに外接している境界画定ボックスのディメンジョンを定める。これを実現するため、書き込み制御３０５はプリミティブの頂点の大きさを比較して境界画定ボックス１３０７の（ＸｍｉｎとＹｍｉｎ）１３０９及び（ＸｍａｘとＹｍａｘ）１３１０を識別する。
【０４４６】  境界画定ボックスの使用は、例えばそれはメモリ要件を過剰に見積もるが、プリミティブが実際にはどのタイルと交差しているかを計算する場合よりも計算が少なくて済むということを含み幾つかの理由により有益であるといえる。
【０４４７】  ライン、ライン・モード三角形、及びポイントは、プリミティブを隣接するタイルにタッチさせ、従って境界画定ボックス計算に影響を及ぼす、幅を有する。例えば、単一のポイントは４個ほど多くのタイルにタッチすることもある。本発明のある好適な実施例では、境界画定ボックス１３０７のディメンジョンを求める前に、ライン・ポイント幅（表１参照）により与えられるプリミティブの指定ライン幅の２分の１をプリミティブのディメンジョンに加算し、プリミティブがタッチしている可能性のあるタイルをより明確に概算できるようにしている。
保証された保存性メモリ見積もり
タイルの数に関する上限が分かっており、個々のポインタと頂点データを記憶するためにプリミティブがどれほどのメモリを必要とするかということも分かっているので、保証されたという語が使用される。これ以後、保証された保存性メモリ見積もりプロシジャ８４５は「ＧＣＥ８４５」と呼ぶことにする。
【０４４８】  イメージ・データがパイプライン２００の先のステージ、例えばモード抽出ステージ４１５から受信されると、ソート・メモリ３１５が書き込み制御３０５により割り当てられるので、ＧＣＥ８４５は望ましい。ソート・メモリ３１５は任意的であるがサイズが固定されているので、イメージ・データをソートしている間にソートメモリ３１５はオーバーフローを起こしかねないと考えられる。
【０４４９】  図Ｃ１４には、代表的メモリ見積もりデータ構造（ＭＥＤＳ）１４００のブロック・ダイヤグラムを示しており、これは、本発明のある実施例においてＧＣＥ８４５が見積もりプロシジャの際使用するデータ・エレメントを提供するものである。ＭＥＤＳは、ソートメモリ３１５又は他のメモリ（図示せず）に記憶できる。パケット・ポインタ・エレメント１４０５は第１挿入ポイントをメモリ内、即ち本例ではソートメモリ３１５内へと参照し、第１入力データエレメント、本例では頂点パケット８０００或いはモード抽出４１５からのモード・パケット４０００か４５００の何れかを記憶する。ポインタ・エレメント１４１０は、他の何れの入力データ・エレメントをも記憶するために、メモリへの第２挿入ポイントの航跡を保持するが、本例では前記他の何れの入力データ・エレメントとは、頂点パケット８０００又はモード・パケット４０００又は４５００に関係付けられている頂点ポインタ５００５又はモード・ポインタ５０１０である。
【０４５０】  最大タイル毎見積もりエレメント１４１５は「最悪ケース」に相当する値、即ち、２−Ｄウィンドウを占めるであろう最も大きなプリミティブを記憶するために必要なメモリ位置の最大数を表している。この最も大きいプリミティブは２−Ｄウィンドウのすべてのタイルにタッチするはずである。残存メモリエレメント１４２５は、書き込み制御３０５による使用に備えて残っているソート・メモリ３１５の実際の量を表している。
【０４５１】  本発明の更に別の実施例では、書き込み制御３０５はメモリ見積もりデータ構造１４００を使用して、ポインタ書き込みアドレスのような現在のメモリ状態情報に関する、３−Ｄグラフィクス・プロセッシング・アプリケーション・プロシジャのようなソフトウェア・アプリケーションからの問い合わせに応答するために、情報を提供する。
【０４５２】  図Ｃ１１に、ＧＣＥ８４５のある実施例を示す。ステップ１１００で、書き込み制御３０５による使用に備えて残っているソート・メモリ３１５の実際の量が計算される。これがどのように行われるかをこれより説明する。本発明のある実施例では、頂点ポインタ５００５のような、イメージデータに関係付けられている何れのポインタも、第１挿入ポイント又は第１アドレスでソート・メモリ内に挿入され、新しいポインタがソート・メモリ３１５に追加されるにつれそれは底部から上に成長する。更に、本実施例では、モード・パケット４０００又は４５００及び／又は頂点パケット８０００のような、イメージ・データに関係付けられたパケットは、第２挿入ポイント又は第２アドレスでソート・メモリ３１５内へと挿入されるが、これはパケットがソート・メモリ３１５に追加されるにつれて、頂部から底部へと減っていくが、逆も又成り立つ。
【０４５３】  第１アドレスと第２アドレスの大きさの違いにより、ソート・メモリ３１５はどれほどの量が残っているかが識別される。以後、この計算の結果を残存メモリ１４２５と呼ぶ。
【０４５４】  本例では、ステップ１１０５で、ＧＣＥ８４５はインプット・データ・パケットがモード・パケット４０００又は４５００であるかを判定し、そうであれば、ステップ１１０６で、ＧＣＥは、モード・パケット４０００又は４５００をデータ記憶装置のインプット・バッファ（図Ｃ３参照）へと記憶するために、そして関係付けられたモード・ポインタ（モード・パケットのタイプにより、クリア・モード・パケット・ポインタ５０１５又はカル・モード・パケットポインタ５０２０の何れか）をインプット・バッファ・モード・ポインタ・リスト内へと記憶するのに必要なソート・メモリ３１５の量を識別するが、この量のことを「必要メモリ」と呼ぶことにする。ある実施例では、必要メモリは、本例ではクリヤ・モード・パケット４０００又はカル・モード・パケット４５００であるパケットのバイトの数に、本例ではモード・ポインタ（図Ｃ５参照。モード・パケットのタイプにより、クリア・モード・パケット・ポインタ５０１５、又はカル・モード・パケット・ポインタ５０２０の何れか）である、関係付けられたポインタをソートメモリ３１５内へ記憶するために必要なバイトの数を加えた数に等しい。（パケット及びポインタのサイズは個々の表に載せている。頂点パケットについては表８を、モード・パケットについては表４を、そして各ポインタ・タイプについては表５を参照されたい。）
図Ｃ１１に戻るが、ステップ１１１０で、ＧＣＥ８４５は必要メモリを残存メモリ１４２５と比較して、必要メモリが残存メモリ１４２５よりも大きければ、ステップ３１５０でＧＣＥ８４５は、書き込み制御３０５が、例えばバッファ・オーバーフロー標示（先のインターフェース信号を参照）をグラフィクス・パイプラインの先行ステージ、例えばモード抽出４１５へ送ることができるように、メモリ不十分の標示、例えば「誤」のブール値を戻す。そうでない場合、ステップ１１２０で、ＧＣＥ８４５は、例えば「真」のブール値を戻すなどして、書き込み制御３０５のためにメモリは十分という標示をセットする。
【０４５５】  イメージ・データがモード・パケット４０００又は４５００でない（ステップ１１０５）場合、ＧＣＥ８４５は、図Ｃ１２に示すようにステップ１１４５に留まる。図Ｃ１２を参照すると、ステップ１１４５で、ＧＣＥ８４５は、イメージデータが完成頂点を保有する空間パケット８０００であるかどうかを判定する。空間パケットの説明については、表１を参照していただきたいが、そこには空間パケット１０００の例を載せている。
【０４５６】  空間パケット１０００が完成頂点を保有している（ステップ１１２５）場合、ステップ１１４５で、ＧＣＥ８４５は、先に詳しく述べたように最大メモリ位置１４２０の値を求める。ステップ１１５０で、残存メモリ１４２５が最大メモリ位置１４２０より大きいか又はそれに等しいと判定された場合、ＧＣＥ８３４は図Ｃ１１のＦに留まり、そこで、ステップ１１２０で、ＧＣＥ８４５は、書き込み制御３０５がイメージ・データ及びあらゆる関係付けられたポインタをソートメモリ３１５内へ記憶するために十分なメモリが確かに在るという標示をセットする。
【０４５７】  そうでない場合は、ステップ１１５５（図Ｃ１２）で、ＧＣＥ８４５は、ジオメトリ・プリミティブに外接する境界画定ボックスのディメンジョンを求めることにより、インプット・データ・パケット２０１の処理に必要とされるであろうソート・メモリ３１５の量の概算を行なう。境界画定ボックスについての詳細は境界画定ボックスの節に関連して先に説明している。
【０４５８】  ステップ１１５６で、ＧＣＥ８４５は、先に詳しく説明済みの最大タイル毎見積もり１４１５を求める。ステップ１１６０で、最大タイル毎見積もり１４１５に境界画定ボックス１３０７により識別されたタイルのグループを掛け、書き込み制御３０５がジオメトリ・プリミティブに関する空間データ及び関係付けられたポインタを記憶するための「必要メモリ」の見積もりを出す。本発明のある実施例では、必要メモリは、本例に関しては、頂点パケット８０００のバイトの数プラス対応する頂点ポインタ５００５の数に等しい。次にＧＣＥ８４５は、図Ｃ１１のＥに留まり、そこで、ステップ１１１０で、必要メモリが残存メモリ１４２５よりも少ないかこれに等しければ、ステップ１１２０で「メモリ十分」標示が呼び出しプロシジャ、例えば書き込み制御３０５プロシジャ（図８参照）に戻される。この標示は、書き込み制御３０５が空間データ及び関係付けられたポインタをソート・メモリ３１５に記憶するのに十分なメモリが確かにあることを示す。先に述べたように、この標示は「真」のブール値を戻すというほどに単純なものである。そうでない場合、ステップ１１１０で、必要メモリが残存メモリ１４２５より大きければ、ステップ１１１５で、このジオメトリ・プリミティブに対応する空間データ並びに関係付けられたポインタをソートしている間にソートメモリ３１５は恐らくオーバーフローするであろうということを示す標示がセットされる。
他のプロセッシング・ステージ
本発明のある実施例においては、他のプロセッシング・ステージ２４０（図Ｃ２参照）には、例えば、次の他のプロセッシング・ステージ２４０が２−Ｄウィンドウの領域に関連してソートしたイメージ・データを領域毎のベースで受信できる限り、何れの他のグラフィクス・プロセッシング・ステージであってもこれに含まれる。
【０４５９】  図Ｃ５には、セットアップ５０５、カル５１０、モード注入５１５、フラグメント５２０、テクスチャ５２５、フォング・ライティング５３０、ピクセル５３５、及びバックエンド５４０を含む、他のプロセッシング・ステージ２２０の好適な実施例の例を示している。他のプロセッシング・ステージ２４０中の個々のプロセッシング・ステージの詳細は、本発明を具現化する上で必要ない。しかしながら、完全を期するために、これらプロセッシング・ステージの各々につきこれより簡単に説明する。
【０４６０】  セットアップ５０５は、ソートされた空間データ並びにモードデータを、ソート２１５から領域毎ベースで受信する。セットアップ５０５は、１度に１領域１プリミティブで、ラインと三角形に関する空間導関数を計算する。
【０４６１】  カル５１０は、セットアップ５０５のようなグラフィクス・パイプラインの先のステージから領域順にデータを受信し、レンダされたイメージには決して寄与することのないプリミティブ又はプリミティブの一部を捨てる。カル５１０は、先に処理されたジオメトリにより隠されていない空間データを出力する。
【０４６２】  モード注入５１５は、モード情報（例えば、カラー、材料特性等）を他のメモリ２３５のような多角形メモリから検索し、それをフラグメント５２０のようなグラフィクス・パイプライン２００内の次のステージへ、必要に応じて送る。フラグメント５２０は、ガウラード・シェーディング用のカラー値、フォング・シェーディング用の面法線、テクスチャ・マッピング用のテクスチャ座標を翻訳して、（必要であれば）バンプ・マッピング・アルゴリズムで使用するため面正接を補間する。
【０４６３】  テクスチャ５２５は、テクスチャ・メモリに記憶されているテクスチャ・マップをピクセル・フラグメントに適用する。フォング５３０は、モード注入５２５により供給された材料及びライティング情報を使って、各ピクセル・フラグメント毎にフォング・シェーディングを実行する。ピクセル５３５は、可視面部及びフラグメント・カラーを受信して、最終的なピクチャを生成する。そして、バックエンド１３９は、１度に１タイル相当のデータをピクセル５３５から受信し、そのデータをフレーム・ディスプレイ・バッファ内に記憶する。
【０４６４】  本発明の好適な実施例では、ソート２１５はモード抽出４１５（図Ｃ３参照）とセットアップ５０５（図Ｃ５参照）の間に置かれている。
空間的ソーティング２１５とセットアップ４０５の間のインタフェース
表１３には、プリミティブ・パケット１３０００の例を示している。ソート２１５からパイプライン２００の次のステージへのアウトプットの大多数は、１、２、又は３つの頂点のセットを保有しているプリミティブ・パケット１３０００のシーケンスである。
【０４６５】  ソート２１５は又、パイプライン２００の次のステージへクリア・パケット４０００を送る。クリア・パケット４０００については、ソート２１５及びモード抽出４１５の間のインターフェースに関連付けて先に詳細に説明している。
【０４６６】  表１１には、出力カル・パケット１１０００の例を示している。読み取り制御３１０は、それがタイル内の最後の頂点パケット８０００又はクリア・パケット４０００の後でなければ、全てのカル・パケットを下流に送る。
【０４６７】  表９には、開始タイル・パケット９０００の例を示している。読み取り制御３１０は、ａ）多数のターゲット・ドロー・バッファ、例えば、ステレオ・フレーム・バッファにおける、前と後又は左と右等の故に、及び／又はｂ）パイプライン２００がソート済み透明モードで動作中にそれが透明ジオメトリを保有するかもしれないということから、特定のタイルに対応するイメージ・データに関連して多数のパスを作る。ソート済み透明モードについては読み取り制御３１０プロシジャに関連して後に詳しく説明する。
【０４６８】  ソート２１５は、あるアクティビティを有する２−Ｄウィンドウ内の全てのタイルに対しこのパケット・タイプを出力するが、これは、このパケット・タイプが、関係付けられたバッファ・クリア（表４のクリア・パケット４０００参照）又はレンダされたプリミティブの何れかを有する全ての２−Ｄウィンドウに対して出力されるということである。
【０４６９】  表１０では、特定のタイルに対応するイメージ・データ全部が送信されたことを表示するエンド・タイル・パケット１００００の例を示している。
インターフェース信号
表１８は、モード抽出４１５データ・アウト・バス２１１が有効なパケットであることを示す、ｓｒｔＯＤ＿ｗｒｉｔｅＤａｔａ信号１８０５を含む、インターフェース信号及びソート２１５とセットアップ４０５の間のパケットを示している。
【０４７０】  ＳｔｐＯＤ＿ｓｔａｌｌ信号１８１５は、セットアップ５０５のインプット・キューが満杯であること、及びソート２１５はセットアップ５０５への送信を停止せねばならないことを示している。信号ｓｔｐＯＤ＿ｔｒａｎｓＥｎｄ１８２０は、ソート２１５がソート済み透明モードで透明なサブタイルを再送信するのを停止せねばならないことを示している。セットアップ４０５は、パイプライン２００の下流ステージの選別ユニットが、それがタイル内の全ての透明なプリミティブを終了したと判定したので、信号を送信する。ソート済み透明モードは読み取り制御３１０に関連して後に詳しく説明する。
【０４７１】  直前に述べた信号の各々を表わすために選択された特定の値は本発明の具現化には必要でないと理解されたい。各信号は、ソート２１５又はセットアップ４０５により個々の信号がお互いに区別されるように、他の信号との関係においてこのような固有の値を有することだけが重要なのである。
読み取り制御３１０
この時点で、書き込み制御３０５は、空間データ及びモード・データの全フレーム又は分割フレームの何れかを処理済みであり、そのイメージ・データをタイル・ベースで頂点毎及びモード毎に、時間順に、ソート・メモリ３１５内に、空間的にソート済みである。これより、その空間的にソートされたイメージ・データをパイプライン２００の次のプロセスへ出力するためにソート２１５により使用される、読み取り制御３１０の多数の実施例について論議する。最初に、読み取り制御３１０は、シーンの効果と水平コンプレキシティをどのように均衡させて、パイプライン２００の次のステージを横切る負荷がより均等にバンランスがとれ、結果的にパイプライン２００のプロセッシングがより効率的になるようにするのかを論議する。このパイプライン２００の負荷バランスを論議する中で、例えば「スーパー・タイル・タイル編成」及び「スーパー・タイル・ホップ・シーケンス」の概念を始めとして、幾つかの新しい概念を紹介する。
【０４７２】  次に、読み取り制御３１０の好適な実施例がプリミティブパケット１３０００をソート・メモリ３１５内の空間的にソートされたイメージ・データからどのように作るかを説明する。その次に、空間的にソートされたイメージデータが、本発明の教示に従って、パイプライン２００に送り込まれることになる、例えばインタイム・オーダー・モード及びソート済み透明モードなど、多数の異なるモードについて論議する。最後に、イメージ・データをパイプライン２００の次のステージに送るために使用される読み取り制御３１０のある実施例を論議する。
グラフィクス・パイプライン負荷バランス
背景に関連して先に述べたように、先入れ先出し（ＦＩＦＯ）及び、行単位又は列単位ストラテジを使用して、グラフィクス・パイプラインの次のステージにイメージ・データを出力することにより重大な問題が生じる。イメージデータをこのようなやり方で出力するのは、イメージの異なる部分に亘るシーン・コンプレキシティ及び／又は水平コンプレキシティが、グラフィクス・パイプラインの次のステージに異なる負荷を与えるかもしれず、その結果恐らくパイプラインにボトルネックを生じ、イメージ・データのパイプライン・プロセッシングの効率悪化を招くということを、考慮にいれていないといえる。パイプライン２００の後続するレンダリング・リソース（例えば図Ｃ５参照）に亘るこれらシーン及び水平コンプレキシティ効果を均衡化することが望ましい。
【０４７３】  パイプライン２００に亘るレンダリング・リソースの均衡化という目標を実現するために、読み取り制御３１０の好適な実施例は、ａ）２−Ｄウィンドウのタイルを（どの書き込み制御３０５がイメージ・データを空間的にソートしたかに従って）スーパー・タイル・ベースのタイル編成へと編成し、ｂ）当該スーパータイルをパイプライン２００内の次のステージへ「スーパー・タイル・ホップ・シーケンス」と称される空間的スタガード・シーケンスで送る。このような負荷バランス取りには、パイプライン２００の後続のテクスチャ・ステージ、例えばテクスチャ５２５（図Ｃ５参照）がテクスチャ・キャッシュ再使用最適化度を使用できるようにさせるという付加的な利点もある。
スーパー・タイル
スーパー・タイルという着想を説明するため、図Ｃ１８に、スーパー・タイルの一例、厳密には４個のタイルから成る２×２スーパー・タイル１８０２を示している。スーパー・タイル１８０２は１個のタイルでも、何れの個数のタイルであってもよい。スーパー・タイルのアレイ１８０中の１スーパー・タイルの行１８０３内のスーパー・タイル１８０２の数は、スーパー・タイルの列８０６内のタイルの数と同じである必要はない。
【０４７４】  本発明のある実施例では、スーパー・タイル１８０２当たりのタイルの個数は選択可能であり、スーパー・タイル１８０２内のタイルの個数は、１×１、２×２、又は４×４の何れかのタイルのグループになるように選択される。スーパータイル１８０２内のタイルの数は、グラフィクス・デバイス・ドライバ又はアプリケーションの何れか、例えばコンピュータ１０１（図Ｃ１参照）上で起動中の３−Ｄグラフィクス・アプリケーションにより選択される。スーパータイル１８０２内のタイルの数は、ターゲット・アプリケーション・スペースの典型的な要求に合うように事前選定してもよい。
【０４７５】  ある好適な実施例では、スーパー・タイル内のタイルの数は２×２である。例えば、本発明では、スーパー・タイル中のタイルの数は、イメージのコンプレキシティが均衡化されるように選択されるものと考えている。特定のイメージ、又はターゲット・アプリケーション・スペース次第で、スーパー・タイルがあまりに多数のタイルを包含している場合は、それらはイメージの複雑領域に加え単純領域をも保有することになる。スーパー・タイルのサイズが十分なタイルを包含しないのであれば、タイルをレンダするためのセットアップ費用は、パイプライン２００の後続ステージにより償却される。このような償却には、例えばテクスチャ・マップ再使用及びピクセル・ブレンディング関連が含まれる。
スーパー・タイル・ホップ・シーケンス
本発明のある好適な実施例では、パイプライン２００の後続ステージに送られているタイルのサブシーケンスのコンプレキシティをよりよく均衡させるため、読み取り制御３１０はスーパー・タイル１８０１をソート・メモリ３１５から空間的スタガード・シーケンスで読み出すが、以後これを「スーパー・タイル・ホップ・シーケンス」又は「ＳＨＳ」と呼ぶ。換言すると、この実施例では、読み取り制御３１０は、イメージ・データをソート・メモリ３１５からパイプライン２００の後続ステージへと、説明したようにタイル順に行単位又は列単位ベースの何れかにより、スーパー・タイル１８０１がコンピュータのディスプレイ・ウィンドウを横切る直線に納まるようなやり方では送らないということである。シーン及び水平コンプレキシティが均衡化されるかぎり、空間的スタガード・シーケンスの厳密な順序は重要でない。
【０４７６】  図Ｃ１８において、スーパー・タイル・アレイ１８０１は、２×２タイルのスーパー・タイルの９行×７列のアレイである。本例では、スーパー・タイルのサイズは２×２タイルなので、スーパー・タイル・アレイ１８０１は６３個のスーパー・タイル、若しくは１８×１４アレイのタイル、即ち１６０５個のタイルが包含する。読み取り制御３１０はスーパー・タイル・アレイ１８０１を、タイルの２−Ｄウィンドウの角、例えばスーパー・タイル・マトリックス１８０１の左下又は左上から開始して行毎にスーパー・タイル１８０２を数えることにより、線形リスト１８０３へと変換する。ある好適な実施例では、計数はスーパー・タイルの２−Ｄウィンドウの左上から開始する。
【０４７７】  次に、読み取り制御３１０はスーパー・タイル・プロセッシングのシーケンスを以下のように定義する。
【０４７８】  Ｔ０＝０、
Ｔｎ＋１＝ｍｏｄＮ（Ｔｎ＋Ｍ）
「Ｍ」の要件は、ＭとＮが互いに素であるということだ。ＭはＮより小でなくともよい。本例では、例中のＮ即ち６３に対して互いに素であるので「Ｍ」は１３である。Ｎ＝ウィンドウ内のスーパー・タイルの数、とすると、Ｍ＝スーパータイル・ステップ、で、Ｔｎ＝処理されるべきｎ番目のスーパー・タイル、であり、ここに０≦ｎ≦Ｎ−１である。本例では、Ｎ＝６３（長さ及び幅）で、Ｍ＝１３である。この結果シーケンスは、タイル順１８０４で示すと、Ｔ０＝０、Ｔ１＝１３、Ｔ２＝２６、Ｔ３＝３９、Ｔ４＝５２、Ｔ５＝２、Ｔ６＝１５となり、これが求められたスーパー・タイル・ホップ・シーケンスである。
【０４７９】  このアルゴリズム即ち、スーパータイル・ホップ・シーケンスは、タイルの擬似ランダム・シーケンスを創造するが、シーン及び水平コンプレキシティはイメージ又は水平の焦点に向かう傾向にある。
【０４８０】  この反復型スーパー・タイル・ホップ・シーケンス・プロシジャは、ＮとＭが互いに素である（即ちそれらの最大公約数が１である）限り、２−Ｄウィンドウ内の全スーパー・タイル１８０２をヒットする。ＮとＭが共に素数である必要はないが、Ｍは常に素数であるように選択されるならば、全てのスーパー・タイルがヒットされる。ＮとＭの一方又は両方が素数でないなら、シーンのある部分はパイプライン２００の後続ステージによりレンダされることは決してない。例えば「Ｎ」が１０にセットされ「Ｍ」が１２にセットされた場合は、奇数のスーパー・タイルはレンダされない。
【０４８１】  ある好適な実施例では、スーパー・タイル・アレイは２−Ｄウィンドウ全体をカバーするのに必要とされるよりも大きく、２ａ×２ｂ＝２２ａ＋ｂと想定され、ここに「ａ」及び「ｂ」は正の整数であり、且つ「ａ」は「ｂ」に等しくてもよいので、こうしてスーパー・タイル・アレイ内のスーパー・タイルの総数が２の整数乗になることを保証している。スーパー・タイルの総数が２の整数乗になるということにより、数字が基数２で表される有限なハードウェア・アーキテクチャ内のモジュラス・オペレーションのインプリメンテーションが簡素になる。
【０４８２】  これは、高次のビットを捨てることにより「ｍｏｄＮ」計算を簡単に行なえるようにする。このアプローチを使うと、存在しない又は架空のスーパー・タイル１８０２はＳＨＳ内に含まれることになるが、本発明の好適な実施例では、タイル内にはフレーム・ジオメトリがないということから、それらは読み取り制御３１０の間に検出され、スキップされる。このような存在しない又は架空のスーパー・タイル１８０２を検出することは、シザー・ウィンドウのディメンジョンが２−Ｄウィンドウの実際のディメンジョンに等しいようなシザー・ウィンドウの使用を通して行なわれ得る。このような状況では、後に詳細に説明する読み取り制御３１０は、シザー・ウィンドウから完全に外れるそれらのタイル又はスーパー・タイルを出力しない。
【０４８３】  図Ｃ７には、データをソート・メモリ３１５から読み出すための代表的読み取り制御３１０回路を示している。読み取り制御３１０は以下の回路、即ち、ａ）タイルをスーパー・タイルへとグループ分けし、スーパー・タイルが、セットアップ５０５のような、グラフィクス・パイプライン内の次のステージへと送られる際のスーパー・タイル・ホップ・シーケンス順序を決めるためのジェネレータ回路７００、ｂ）２−Ｄウィンドウのモード・ポインタ・リストとテイル・ポインタ・リストをトラバースして読み取りキャッシュ７３０をタイル毎ベースでポピュレートするための、各タイルの空間データはタイムオーダーで記憶される、ポインタ・トラバース回路７１０、ｃ）アウトプット・プリミティブ・パケット１３０００（表１３）を形成し、空間及びモードデータをタイル単位でグラフィクス．パイプライン２００内の次のステージに送る前に、クリア・モード・パケット４０００（表４参照）を累計するためのジオメトリ・アッセンブリ回路７２０、を含むように構成される。これら回路７００、７１０、及び７２０の各機能性については図Ｃ１７に関連して後に詳しく説明する。
読み取り制御プロシジャ
作動時、読み取り制御３１０は、ａ）パイプライン２００の次のプロセッシング・ステージに送られるべき次のタイルを選択し、ｂ）選定されたタイルに対し現在のテイルメモリ３６０から最終的な頂点ポインタ５００５を読み出し、ｃ）そのタイルを捨てることができるか否かを判定するために最終的な頂点ポインタ５００５とモード・ポインタＸをテストする、但し、ｄ）タイルが捨てられない場合は、読み取り制御３１０は処理を進めて現在のタイル・ポインタ・リストをトラバースして、タイルにタッチしているプリミティブの頂点のアドレスを見つけ、ｅ）頂点データが必要であるとして読み出され、プリミティブはプリミティブ１３０００（表１３参照）パケットへとアッセンブリされ、パイプライン２００の次のプロセッシング・ステージへと引き渡される。本発明のある好適な実施例では、次のプロセッシング・ステージはセットアップ５０５（図Ｃ５参照）である。
【０４８４】  本発明のある実施例では、例えば、ユーザー又は例えばコンピュータ１０１（図Ｃ１参照）上で起動している３−Ｄグラフィクス・アプリケーションが要求する場合など、プリミティブがフロント・バッファ及びバック・バッファの双方にレンダされる場合には、タイルに対応するイメージ・データは、パイプライン２００の次のステージに再送される。
【０４８５】  本発明のある好適な実施例では、タイルに対応するイメージ・データは、例えばパイプライン２００がソート済み透明モードにあるとき等、ある状況下では、パイプライン２００の次のステージに再送される。ソート済み透明モードについては後に詳しく説明する。
【０４８６】  本発明の更に別の実施例では、読み取り制御３１０は２つの基本的な最適化を実行する。第１に、何れのプリミティブ又はクリア・パケット４０００も交差しないタイルはパイプライン２００の次のステージには送られない。第２に、現在の頂点のアドレスを現在のモード・パケットのアドレスと比較して、モード・パケットが出力ストリームへ併合されるべきかどうかを判定し、このやり方で、クリア・バッファ・イベントはジオメトリが圧縮可能であるなら圧縮される前に起きる。これは、パイプライン２００の後続ステージへのイメージデータの帯域幅を減少させるので有益である。
【０４８７】  本発明の更に別の実施例では、読み取り制御３１０は、書き込み制御３０５により書き込みを指定された、読み取り制御３１０が読み取りを開始するステップの直前にあるソートメモリ３１５内のバッファから空間的にソートされたイメージ・データの読み出しを開始する。
【０４８８】  図Ｃ１７を参照しながら、これより読み取り制御３１０の１例を説明する。ステップ１７０５で、２−Ｄウィンドウの空間域を表しているタイルのアレイは、スーパー・タイル１８０３のアレイにグループ分けされる。スーパー・タイル１８０２は先に図Ｃ１８に関連して詳しく述べている。ステップ１７１０で、スーパー・タイルをグラフィクス・パイプライン２００内の次のステージに送るためのスーパー・タイル・ホップ・シーケンス・オーダーが決められる。スーパー・タイル・ホップ・シーケンスは、図Ｃ１８に関連して先に詳しく述べている。
【０４８９】  ステップ１７１５で、読み取り制御３１０は、１）パケット（頂点パケットＸ及びモード・パケット４０００及び４５００）を、タイル毎ベースで、インタイム・オーダー方式でソートメモリ３１５から順序付けし、２）それらをキュー即ち読み取りキャッシュ７３０へと書き込む。
【０４９０】  パケットをアウトプット・ソート・メモリ・バッファ、例えばバッファ１（図Ｃ３参照）に順序付けるためには、以下の事柄を考慮に入れなければならない。シングルモード・パケット４０００又は４５００は、ある特定の１つのタイル内の多数のプリミティブの他にも、多数のタイルに影響しているかもしれない。ソート・メモリ３１５内の任意のバッファ、例えばバッファ０又はバッファ１（図Ｃ３参照）は、単一のモード・ポインタ・リスト、例えばモード・ポインタ・リスト３４０を保有している。モード・パケットＸは書き込み制御３０５によりソート・メモリ３１５へとタイル毎ベースではソートされず、インタイム・オーダーでインプット・データ記憶装置バッファ、例えばデータ記憶装置３２０（図Ｃ３参照）にソートされるたけである。このように、単一のモード・パケットＸがある特定の１つのタイル内の多数プリミティブの他にも、多数のタイルに影響を及ぼす可能性がある。読み取り制御３１０は、各特定のモード・パケットＸをそれが影響するタイルに対してマップし、読み取り制御３１０は、タイル毎プリミティブ毎に１回の割でタイル内のプリミティブに影響するモード・パケットを出力することに比べると、特定のタイル毎に１回だけ、特定のタイル内のプリミティブに影響するモード・パケットだけを出力することが望ましい。
【０４９１】  この目的を実現し、読み取りキャッシュ７３０をポピュレートする（ステップ１７１５）ため、読み取り制御３１０は（各インプット・バッファ・タイル・ポインタ・リスト内の）各頂点ポインタ５００５のアドレスを単一のインプット・バッファ・モード・ポインタ・リスト内の各モード・ポインタ４０００又は４５００のアドレスと比較する。（図Ｃ３を参照すると、インプット・バッファ・タイル・ポインタ・リストは、例えばタイル０タイル・ポインタ・リスト３３１、タイル１タイル・ポインタ・リスト３３２、タイル２タイル・ポインタ・リスト３３３、及びタイルＮタイル・ポインタ・リスト３３４ということになる。インプット・バッファ・モード・ポインタ・リストは、例えばモード・ポインタ・リスト３４０ということになろう。）モード・ポインタ４０００又は４５００のアドレスが頂点ポインタ５００５のアドレスよりも大きい場合、モード・ポインタ４０００又は４５００は頂点ポインタ５００５の前に来ている。頂点ポインタ５００５のアドレスがモード・ポインタ４０００又は４５００のアドレスよりも大きい場合、頂点ポインタ５００５がモード・ポインタ４０００又は４５００の前に来ている。どちらのポインタが先にソート・メモリ３１５に書き込まれたかによって、インプット・データ記憶装置バッファ（例えば、図Ｃ３のデータ記憶装置３２０参照）内のポインタ対応パケット、即ち頂点パケット５００５又はモード・パケット４０００又は４５００の何れが、後続のインプット・データ記憶装置バッファ内へと書き込まれてしまっていると判定されたパケットの前に、読み取り制御３１０からパイプライン２００の次のプロセッシング・ステージへと送られるべきであるかが示される。このプロシジャを使用すれば、タイルに影響する各モード・パケット４０００又は４５００は、それが影響するタイルに対し一度しか出力されない。
【０４９２】  この説明は，ポインタが書き込み制御３０５によりソート・メモリ３１５の底部からソート・メモリ３１５の頂部に向けてソート・メモリ３１５内に書き込まれることを想定したものであるが、ポインタが書き込み制御３０５により頂部から底部に向けて書き込まれる場合には上記説明の逆が適用される。
【０４９３】  本発明のある好適な実施例では、読み取りキャッシュ７３０にパケットを書き込むために、読み取り制御３１０は、プリミティブが空のタイルを送らないことにより、パイプライン２００の後続ステージに送られる無関係なデータの量を最小限にしようとする。これを実現するために、読み取り制御３１０は、アウトプット・テイル・メモリ３６０バッファ、即ち３６１又は３６２の何れか（図Ｃ２参照）を使って、プリミティブを保有していない２−Ｄウィンドウ内のそれらタイルを識別する。例えば、アウトプット・バッファ・タイル・ポインタ・リスト（図Ｃ６のＡＤＤＲ  ＨＥＡＤ６００５参照）のアドレスがテイル・メモリ３６０内の対応するテイル・アドレスＸ（表６のＡＤＤＲ  ＴＡＩＬ６０１０参照）のアドレスに等しければ、その特定のタイルは書き込み制御３０５によりその中にソートされる何れのプリミティブをも有していない（どのフレーム・ジオメトリも空である）。従って、読み取り制御３１０は、この特定のタイルに関する如何なるデータもパイプライン２００の後続ステージへ送らない。
【０４９４】  本発明の更に別の実施例では、読み取り制御３１０は、架空ファイルを送り出さないことにより、パイプライン２００の次のステージへ送られる無関係なデータの量を最小化しようとする。架空タイルとは、先に詳しく説明済の、タイルの数と２−Ｄウィンドウが２の累乗で増大されてしまうスーパー・タイルのタイル編成の間に、読み取り制御３１０により先行して作られたフレーム・ジオメトリが空であるタイルのことを言う。
【０４９５】  この目標を達成するために、読み取り制御３１０は２−Ｄウィンドウの実際の座標を有するシザー・ウィンドウを作る。表１４は、シザー・ウィンドウの座標を記憶するためのシザー・ウィンドウ・データ構造の例を示している。
【０４９６】  使用可能１４０５は、読み取り制御３１０はシザー・ウィンドウを使うべきか否かを指定する。使用可能１４０５が「１」にセットされていると、それは読み取り制御３１０がその中に規定されたシザー・ウィンドウを使わねばならないということを指示している。Ｘｍｉｎ１４１０、Ｘｍａｘ１４１５、Ｙｍｉｎ１４２０、Ｙｍａｘ１４２５を使用して、シザー・ウィンドウのディメンジョンを定義する最小座標及び最大座標を定める。本発明の好適な実施例では、シザー・ウィンドウ・データ構造１４０００は、例えば、ソート・メモリ３１５（図Ｃ３参照）又は他のメモリ（図示せず）に記憶される。
【０４９７】  本発明の更に別の好適な実施例では、読み取り制御３１０は、架空ファイルを送り出さないことにより、パイプライン２００の後続ステージに送られる無関係なデータの量を最小化しようとする。架空タイルとは、先に詳しく説明済の、タイルの数と２−Ｄウィンドウが２の累乗で増大されてしまうスーパー・タイルのタイル編成の間に、読み取り制御３１０により先行して作られたフレーム・ジオメトリが空であるタイルのことを言う。
【０４９８】  この目標を達成するために、読み取り制御３１０は２−Ｄウィンドウの実際の座標を有するシザー・ウィンドウを作る。表１４は、シザー・ウィンドウの座標を記憶するためのシザー・ウィンドウ・データ構造の例を示している。
【０４９９】  使用可能１４０５は、読み取り制御３１０はシザー・ウィンドウを使うべきか否かを指定する。使用可能１４０５が「１」にセットされていると、それは読み取り制御３１０がその中に規定されたシザー・ウィンドウを使わねばならないということを指示している。Ｘｍｉｎ１４１０、Ｘｍａｘ１４１５、Ｙｍｉｎ１４２０、Ｙｍａｘ１４２５を使用して、シザー・ウィンドウのディメンジョンを定義する最小座標及び最大座標を定める。本発明の好適な実施例では、シザー・ウィンドウ・データ構造１４０００は、例えば、ソート・メモリ３１５（図Ｃ３参照）又は他のメモリ（図示せず）に記憶される。
【０５００】  この好適な実施例では、読み取り制御３１０はこのシザー・ウィンドウの外側に全体が納まるタイルを全て捨てることになる。一部がシザー・ウィンドウの内側又は外側に位置するタイルは捨てられない。
【０５０１】  本発明の更に別の実施例においては、シザー・ウィンドウ・データ構造１４０００は、次のシザー・ウィンドウ・データ構造１４０００を指すためのリンク１４３０を含んでいる。この実施例では、読み取り制御１３１０はシザー・ウィンドウ・データ構造１４０００のシングル・リンクされたリストを使用して、多数のシザー・ウィンドウを規定する。リンクされたリスト・データ構造及び構造内のリンクされたリストのオペレーションは知られているので、ここでこれ以上詳しくは説明しない。
【０５０２】  これら多数のシザー・ウィンドウは、２−Ｄウィンドウを備えたどのタイルがレンダされる必要があり、どのタイルがレンダされる必要がないのかを見分け、それにより、ウィンドウの可視部分を表すイメージデータだけをグラフィクス・パイプラインのステージへ送り込むとともに、一方ではウィンドウの可視部分に寄与しないイメージ・データ又は架空のイメージ・データを捨てることができるようにするために、使用されると考えられる。
【０５０３】  読み取り制御３１０は、頂点ポインタ５００５に対応する頂点データが読み取りキャッシュ７０３に記憶されるべきであると判定すると、完全なジオメトリ・プリミティブをアッセンブリするのに必要なデータ記憶装置内のあらゆる頂点パケット５００５に対してポインタ参照を生成して、そのポインタ参照を読み取りキャッシュ７０３に記憶する。もしあれば、プリミティブの残りの頂点それぞれを頂点ポインタ５００５から識別するためのプロシジャについては、頂点ポインタ５００５及び表５に関連して先に詳しく述べている。
【０５０４】  このプロシジャの観点から、読み取り制御３１０は以下のルール、即ち、オフセット５００７があるポイントを表しているのであれば、プリミティブを記述するのに追加的な頂点は必要なく、読み取り制御３１０は単一の頂点ポインタ５００５のアドレスを読み取りキャッシュ７０３に書き込むだけである、というルールに従って、読み取りキャッシュ７０３へと記憶するためにポインタ参照を生成する。オフセット５００７がライン・セグメントを表しているのであれば、ライン・セグメントを記述するにはもう１つの頂点が必要で、読み取り制御３１０は先ず、頂点ポインタ５００５マイナス１のアドレスを有する頂点ポインタ５００５を読み取りキャッシュ７０３に書き込み、次に頂点ポインタ５００５のアドレスを読み取りキャッシュ７０３に書き込む。オフセット５００７が三角形を表しているのであれば、三角形を記述するには更に２つの頂点が必要となるり、読み取り制御３１０は以下のポインタ、即ち、１）オフセットの値を差し引いた頂点ポインタ５００５のアドレス、２）１を差し引いた頂点ポインタ５００５のアドレス、及び３）頂点ポインタ５００５のアドレス、をこの順序で読み取りキャッシュ７０３に書き込む。
【０５０５】  読み取り制御３１０が、各タイルそれぞれのイメージ・データを読み取りキャッシュ７０３にポピュレートするとき、そのタイル内の各プリミティブが読み取りキャッシュ７０３に読み込まれる順序は、読み取り制御３１０が「タイムオーダー（時間順）モード」又は「ソート済み透明モード」の何れで動作しているかに従って統制される。タイムオーダー・モード（本発明のある実施例に関してはデフォルト・モード）では、読み取り制御３１０は、そのデータが記憶される際に、各タイル内に、頂点及びモードを受信したときのタイム・オーダーを保存する。即ち所与のタイル毎に、頂点及びモードは、それらが書き込み制御３０５によりソート・メモリ３１５に書き込まれたのと同じ順序で、読み取りキャッシュ７０３に読み込まれる。
ソート済み透明モード
ソート済み透明モードでは、読み取り制御３１０は多数のパス内の各タイルのデータを読み取りキャッシュ７０３に読み取る。第１パスでは、読み取り制御３１０は「保証された不透明」なジオメトリを出力する。このコンテクストで、保証された不透明とは、ジオメトリ・プリミティブがウインドウの同じ区域を占めるより遠くのジオメトリを完全に覆い隠すという意味である。次のパスでは、読み取り制御３１０は潜在的に透明なジオメトリを出力する。潜在的に透明なジオメトリは、保証された不透明ではないあらゆるジオメトリのことである。先に論じたように、各パス内では、ジオメトリのタイムオーダリングは保存されており、（モード・パケットに含まれている）モード・データはそれらの正確なタイムオーダー位置に挿入される。
【０５０６】  本発明のある実施例では、各頂点ポインタ５００５は、透明エレメント５００８（表Ｘ参照）を含んでいる。透明エレメント５００８はシングルビットで、そこでは「０」はプリミティブが不透明であると保証されることを表し「１」は対応するプリミティブがおそらく透明であろうとして処置されることを表す。
【０５０７】  クリア・パケット４０００は、読み取り制御３１０がタイム・オーダー・モードで動作するか、又はソート済み透明モードで動作するかの表示、即ちソート透明モード４０１０（表４参照）を含んでいる。本発明のある実施例では、ソート透明モード４０１０が「１」にセットされていれば、読み取り制御３１０はタイム・オーダー・モードで動作することになる。この実施例では、ソート透明モード４０１０が「０」にセットされていれば、読み取り制御３１０はソート済み透明モードで動作することになる。
【０５０８】  図Ｃ１７において、ステップ１７２０で、読み取り制御３１０は読み取りキャッシュ７０３に記憶されている各頂点ポインタ５００５及び各モード・ポインタ（モード・パケットのタイプにより、クリア・モード・パケット・ポインタ５０１５かカル・モード・パケット・ポインタ５０２０の何れか）を使って、データ記憶装置内の各特定のポインタそれぞれが参照するパケットにアクセスする。
【０５０９】  ポインタを読み取りキャッシュ７０３から読み取るプロセスにおいて、読み取り制御３１０はそれが出会う各クリア・パケット４０００を累積する。クリア・モード・パケット４０００を累積するというプロセスは、それにより、パイプライン２００の後続ステージ、例えば図Ｃ５で識別されているそれらオペレーション・ステージに対するイメージ・データ帯域幅が削減されるので有益である。クリア・パケット４０００は、完成頂点を参照している頂点ポインタ５００５が読み取りキャッシュ７０３から読み取られるまで、或いは特定のクリア・パケット４０００が、例えば「１」にセットされ、特定のパケットが直ちに送信される必要があることを示す「センド・ナウ」フィールド（ＳｅｎｄＴｏＰｉｘｅ１４００８）を含むようになるまで、の何れかまで累積される。読み取り制御３１０はこれら２つの状況の何れか一方の状況に出会うと、読み取り制御３１０は何れの累積されたクリア・パケット４０００をもグラフィクス・パイプライン内の次のステージ、例えばセットアップ５０５へと送る。
【０５１０】  本発明のある実施例では、多数の隣接するソート・アウトプット・カル・パケット１１０００（表１１参照）は、カル・レジスタ（図示せず）により１つのソート・アウトプット・カル・パケットに圧縮される。本質的に、カル・レジスタは、各カル・フラッシュ・オール・ビット１１０１０を多数のアウトプット・カル・パケット１１０００から論理和をとり、他の全パラメータに対して最後のパケットを使用する。こうすると、パイプライン２００の次のステージ、例えばセットアップ５０５は、ジオメトリを含んでいないタイルに関連する次のステータス・プロセスに影響することなく、あるジオメトリについてはターン・オフできるようになるので有益である。
【０５１１】  表１３には、グラフィクス・パイプライン内の次のステージへ送るための、代表的なアウトプット・プリミティブ・パケットの例を示している。読み取りキャッシュ７０３から各頂点ポインタ５００５読み取る毎に、読み取り制御３１０はアウトプット・プリミティブ・パケット１３０００を生成する。これを実現するために、読み取り制御３１０は各プリミティブの頂点を累積することになるが、各頂点はデータ記憶装置内の対応する頂点パケット５００５に記憶され、それぞれのアウトプット・プリミティブ・パケット１３０００内へと記憶される。先に論じたように、完成頂点を含んでいる各頂点ポインタ５００５は、最後の頂点ポインタ５００５として読み取りキャッシュ７０３に書き込まれる。頂点ポインタ５００５からプリミティブの頂点の各々をアッセンブリするプロシジャについては、表５及び頂点ポインタ５００５に関連付けて先に詳しく説明している。
【０５１２】  ステップ１７２５で、読み取り制御３１０はパケットをセットアップ４０５のようなグラフィクス・パイプライン内の次のステージにタイル毎ベースで送る。各タイルのそれぞれのイメージ・データの出力開始時には、出力開始タイル・パケット９０００が、グラフィクス・パイプライン内の下流ブロックにより必要とされるタイル毎パラメータ全てを含んで出力される。表９では、所与のタイルの左下隅の２−Ｄウィンドウ内の（ピクセル内の）位置のような、タイル毎パラメータを含んでいる出力開始タイル・パケット９０００の例を示している。表９．５には、出力終了タイル・パケット９５００の例を示している。読み取り制御３１０は、グラフィクス・パイプライン内の次のステージに出力される全てのタイルを伴う以下のパケット、即ち、１）アウトプット・カル・モード・パケット１１０００、２）あらゆる累積されたクリア・パケット４０００、３）所与のタイルのアウトプット・プリミティブ・パケット１３０００の各々、及び４）アウトプット終了タイル・パケット９５００を含んでいる。
随意的改良及び代替実施例
ライン・モード・フラグ
各空間パケット１０００はライン・フラグ・エレメント１０３０を持っていることを思い出そう。このエレメント１０３０は、ライン・セグメントはすでにレンダされているか、従って再びレンダされる必要がないかどうかを表示する。これは、共通辺を有するライン・モード三角形をレンダする場合には特に重要である。
【０５１３】  図Ｃ１６は、６個の三角形Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆと、８個のジオメトリ・プリミティブ１６０５、１６１０、１６１５、１６２０、１６２５、１６３０、１６３５、１６４０を伴うウィンドウ１６００を示している。この例では、三角形ファンは三角形１６２５、１６３０、１６３５を含んでいる。頂点８、９、１０により識別される三角形１６２５は、頂点８と１０により識別されるライン・セグメントを、頂点８、１０、１１により識別される三角形１６３０と共有している。この代わりの実施例では、ライン・フラグ・エレメント１０３０がセットされていれば、このような共有ライン・セグメントは一度だけレンダされる。
ソートメモリ：トリプル・バッファド
たった２ページのソート・メモリ３１５で、読み取り制御３１０と書き込み制御３０５はロックステップに入りこの内の片方が実行される。例えば、書き込み制御３０５が、複雑なジオメトリを有する状態から密でないジオメトリを有する状態へと交互に変わるフレームに対するイメージ・データをソートしているときには、読み取り制御３１０と書き込み制御３０５は何れの回にも量が著しく異なるイメージ・データ上で動作することになる。ソート・メモリ３１５は、完全なフレーム相当のイメージ・データが処理され、ソート・メモリ３１５バッファ・オーバーフロー・エラーが起きる場合、又はアプリケーションによりフレーム標示の強制終了が送られた場合の何れかの場合にスワップされることを思い出して頂きたい。従って、プロセス、例えば、書き込み制御３０５又は読み取り制御３１０の何れか先に完了した方は、もう一方のプロセスが完了するまで待って始めてイメージ・データの次のフレームのプロセッシングを開始できる。
ソートメモリ：ダイナミック・メモリ管理
本発明の別の実施例では、ソート・メモリ３１５は少なくともトリプル・バッファされている。第１又はフロント・バッファはシーンのジオメトリを集めるためのものである。第２又はバック・バッファはソートされたジオメトリをグラフィクス・パイプラインに送り込むためのものである。第３又はオーバーフロー・バッファは、フロント・バッファがオーバーフローしたときにフレームのジオメトリを記憶するためのもの、又はバック・バッファが空になる作業を終えるまで空間的にソートされたイメージ・データの完全なシリーズを保持するためのものである。このようなインプリメンテーションは、読み取り及び書き込みプロセスの両方がお互いに対して独立して働くことを可能にする。例えば、入力側のフレーム・サイズ・ストールは、出力側から隔離されることになるが、書き込み制御がストールする唯一の理由は、メモリ又はデータの不足が起きた場合である。
【０５１４】  別の実施例では、ソート・メモリ３１５は、必要ベースでソート・メモリのページ割り当て及び割り当て解除に関し、ダイナミック・メモリ管理システムで管理されている。ダイナミック・メモリ管理システムは、全ての非専用ハードウェア・プラットフォームにおいて当技術では既知である。本発明は、専用３−Ｄプロセッサ、例えば３−Ｄプロセッサ１１７（図Ｃ１及びＣ２）上のプロセッシング・ステージ、例えばソート２１５で作動するダイナミック・メモリ・マネジャの使用を考慮している。
【０５１５】  本発明のある実施例では、ソート２１５は、メモリ・プール、例えばソート・メモリ３１５からのメモリ・ブロックを必要ベースで割り当てる。これを説明するため、以下の例、即ち、書き込み制御３０５はイメージ・データのフレームをソートするため第１メモリ・バッファを割り当てる場合を考察する。ａ）イメージ・フレームの終了の時、ｂ）例えばコンピュータ１０１（図Ｃ１）上で起動しているソフトウェア・アプリケーションからのフレームの強制終了標示を書き込み制御３０５が受信した時、ｃ）保証された保存性メモリ推定８４５（図Ｃ８参照）からメモリバッファ・オーバーフローが起こりそうだと標示があった時、の何れかの時に、書き込み制御３０５は読み取り制御３１０に、ソートされたイメージ・データを第１メモリ・バッファから読み出し開始するように信号を送る。
【０５１６】  この時点で、書き込み制御３０５は、イメージ・データのフレームをソートするため第２メモリ・バッファを割り当てる。上記イベントａ）ｂ）又はｃ）の何れが起きた場合、書き込み制御３０５は、読み取り制御３１０がソートされたイメージ・データのパイプライン２００の次のステージへの読み出しを完了したかどうかをチェックする。読み取り制御３１０が終えていなければ、書き込み制御３０５は、イメージ・データの次のフレームのソートを開始するために第３メモリ・バッファを割り当てる。書き込み制御３０５は追加して、読み取り制御３１０は、現在のバッファつまり第１メモリ・バッファでの作業が終わり次第、ソートされたイメージ・データの読み取りを開始するために第２メモリ・バッファを利用できる旨の信号を、読み取り制御３１０に送る。
【０５１７】  完了の際、読み取り制御３１０は第１メモリ・バッファを開放して、メモリ・リソースをメモリ・プールに戻す。更に、この時点で、読み取り制御３１０はソートされたイメージ・データを第２メモリ・バッファから読み取り開始する。このやり方で、書き込み制御３０５と読み取り制御３１０は互いから独立して作業することができる。入力側のフレーム・サイズストールは出力側から隔離されることになる。本例では３個のメモリ・バッファしか使用していないが、より多数のメモリ・バッファを使用することもできるように考えられている。
コンピュータ・プログラム・プロダクト
本発明は、コンピュータ読み取り可能記憶媒体に組み込まれたコンピュータ・プログラム・メカニズムを含む、コンピュータ・プログラム・プロダクトとして実現できる。例えば、コンピュータ・プログラム・プロダクトは、図Ｃ８及び図Ｃ９に示す書き込みプロセス及び読み取り制御プログラム・モジュールを包含するものである。これらのプログラム・モジュールはＣＤ−ＲＯＭ、磁気ディスク記憶装置プロダクト、又は他の何れのコンピュータ読み取り可能データ又はプログラム記憶装置プロダクトに記憶してもよい。コンピュータ・プログラム・プロダクト内のソフトウェア・モジュールは、インターネットを介して、或いは、搬送波上で（ソフトウェア・モジュールが組み込まれている）コンピュータ・データ信号を送信することにより、電子的に配送することもできる。
ＶＩ．セットアップ機能ブロック（ＳＴＰ）の詳細な説明
タイル化アーキテクチャは、イメージ・データ、厳密にはジオメトリ・プリミティブを、多数の等サイズの領域に分割された２−Ｄウィンドウ内の領域と関係付けるグラフィック・パイプライン・アーキテクチャである。タイル化アーキテクチャは、グラフィクス・パイプラインが、より小量のイメージ・データを効率的に演算できるようにしているので有益である。換言すれば、タイル化グラフィクス・パイプライン・アーキテクチャは、専門化された高性能のグラフィクス・ハードウェアをグラフィクス・パイプライン内で利用する機会を与える。
【０５１８】  タイル化アーキテクチャを有するグラフィクス・パイプラインは、２−Ｄウィンドウの領域に関してイメージ・データの中間パイプライン・ソーティングを行なわない。従来型のグラフィクス・パイプラインは通常、イメージ・データを、グラフィクス・パイプラインの始まりのソフトウェアにおいてイメージデータ変換が起きる前にソートするか、或いはグライフクス・パイプラインの最後にあるハードウェアにおいてイメージが２−Ｄグリッドのピクセルへとレンダされた後にソートするかの何れかである。
【０５１９】  グラフィクス・パイプラインの丁度始まりにイメージ・データをソートすることは、重大な問題を引き起こす。例えば、グラフィクス・パイプラインの丁度始まりにイメージ・データをソートすることは、通常、交わっているプリミティブをより小型のプリミティブへと分割することを含んでおり、その場合それらプリミティブは交わることで頂点の数がより多くなる。これら頂点の各々は適当な座標空間へと変換される必要がある。通常、これはグラフィクス・パイプラインの次のステージにより行なわれる。
【０５２０】  頂点変換は計算上集約的である。これら頂点は何れもが適当な座標空間に変換されたことがないので、これら各頂点はグラフィクス・パイプラインの後続の頂点変換ステージにより適当な座標空間へと変換される必要がある。座標空間は既知である。上に指摘したように、頂点変換は計算上集約的である。変換前にプリミティブを再分割することにより頂点の数が増加するので、既に速度の遅い頂点変換プロセスがより遅くなる。
【０５２１】  重大な問題は、グラフィクス・パイプラインの最後に（ハードウェアで）イメージ・データを空間的にソートすることによっても起きる。例えば、グラフィクス・パイプラインの最後にイメージ・データをソートする場合、通常このようなインブリメンテーションは「テクスチャ・マップ」を行い、表示されることのないイメージ・データをラスタライズするので、普通、イメージ・プロセッシングの速度が落ちる。これを説明するため、以下の例、即ちジオメトリの最初の１片が、空間的に、不透明ジオメトリである第２片の後ろに配置されている場合を考察する。この場合、ジオメトリの第１片は絶対に表示されることはない。
【０５２２】  例えば、プリミティブは別のプリミティブの後ろに完全に又は部分的に隠されるかもしないので、表示されるイメージ・フレーム中では見えないであろうプリミティブ又はプリミティブの一部を除去するのは、見えるであろうイメージ・データだけを処理することによりグラフィクス・パイプラインの最適化が図れる故に有益である。隠れたイメージ・データを除去するプロセスはカリング（選別除去）と呼ばれる。
【０５２３】  タイル化アーキテクチャを現に有するタイル化グラフィクスはカリング・オペレーションを行なわない。先に詳しく論じたように、イメージ・データはパイプラインの中間、即ちイメージ・データ座標変換が行われた後で且つイメージデータがテクスチャ・マップ及び／又はラスタライズされる前に、ソートすることが望ましいので、イメージ・データがテクスチャ・マップ及び／又はラスタライズされる前にイメージ・データから隠れたピクセルを除去することが望ましい。従って、さらに必要なのは、中間パイプライン・ソーティングだけでなく中間パイプライン・カリングも行なうタイル化グラフィクス・パイプライン・アーキテクチャである。
【０５２４】  タイル・ベースのグラフィクス・パイプライン・アーキテクチャでは、カリング・ユニットにタイル関連ベースで正確なイメージ・データ情報を提供することが望ましい。このようなイメージ・データ情報には、例えば、カリング・ユニットに、プリミティブのタイルの辺との交点を定義付ける頂点を提供することが含まれる。これを実行するため、イメージ・データはタイルにクリップされねばならない。この情報は、中間パイプライン・カリング・ユニットに送られねばならない。従って、中間パイプラインのカル・ユニットはこれまでになく新しく、その入力要件も独特なので、更に必要なのは、中間パイプライン・カリング・ユニットのためにイメージ・データ情報をセットアップするための、中間パイプライン・ホスト・ファイル・ソーティング・セットアップ・ユニットの構造及び方法である。
【０５２５】  タイル化グラフィクス・パイプライン・アーキテクチャの中間パイプライン・カリング・ユニットの論理は、可能な限り高性能且つ能率的なことが望ましい。カリング・ユニットの論理は、その論理演算における分岐の数を削減することにより高性能を目指して最適化することができる。例えば、従来のカリング・オペレーションは、通常、どのプリミティブの頂点がタイル内にあるかを求める論理又はアルゴリズム、以後これを頂点／タイル交差アルゴリズムと呼ぶが、このアルゴリズムを含んでいる。従来のカリング・オペレーションは、通常、これを行うに当たり、各プリミティブタイプにつき１アルゴリズムの割で、多数の異なる頂点／タイル交差アルゴリズムを実行する。
【０５２６】  タイル内にあるのはライン・セグメントか三角形の頂点かということを判定するためのアルゴリズムをたった１つしか持っていないカリング・ユニットは、プリミティブ・タイプ毎に１つで計２つのアルゴリズムを持っているカリング・ユニットに比較すると、論理演算における分岐がより少なくなるはずである。別の言い方をすれば、例えば、三角形又はラインがプリミティブ記述子の共通のセットを使って記述されるのであれば都合がよいと言える。そのようにして、カル・オペレーションは、１つのアルゴリズム／１セットの等式／１セットのハードウェアを共用して、三角形の頂点及びライン・セグメントがタイルにあるか否かを判定する。
【０５２７】  プリミティブ記述子の共通のセットを使えば、カリング・ユニットがサポートする必要があるこのような頂点／タイル交差アルゴリズムの数を削減することができる。プリミティブ記述子のこのような共通のセットは、グラフィクス・パイプラインの他のステージにも有益であろう。例えば、カリング・ユニットのための表示情報をセットアップするステージも、三角形及びラインの統合型プリミティブ記述子を使えば、プリミティブ最小デプス値及び他の情報を計算するため、同じアルゴリズム／同じセットの等式／同じセットのハードウェアを共用できるであろう。従って、必要なのは、アルゴリズム／等式のセット／ハードウェアのセットがグラフィクス・パイプラインのステージ内で共用できるような、異なるプリミティブ・タイプを記述するためのプリミティブ記述子の統合されたセットである。
【０５２８】  従来のタイル・ベースのグラフィクス・パイプライン・アーキテクチャでは、ジオメトリ・プリミティブ頂点、若しくはｘ−座標及びｙ−座標は、通常、スクリーン・ベースの値に記憶される。これは即ち、各頂点のｘ−座標及びｙ−座標は、通常、ある限定された数の少数部ビット（サブ・ピクセル・ビット）を持つ固定小数点数字として記憶されるということを意味する。大抵は、表記は、ある数の小数部ビットを持つ整数となるはずである。
【０５２９】  タイル・ベースのグラフィクス・パイプライン・アーキテクチャは可能な限り能率的に構成することが望ましいので、ｘ−座標及びｙ−座標をより少量のメモリに表現することは有益である。従って、必要なのは、メモリ要件が低減されるように、ｘ−座標とｙ−座標をタイルベールのグラフィクス・パイプライン・アーキテクチャ内に表現するための構造及び方法である。
発明の概要
これまで、グラフィクス・パイプライン・アーキテクチャは、グラフィクス・パイプラインの前か、グラフィクス・パイプラインの終りのハードウェアにおいてか、の何れかでイメージ・データをソートすることにより制限され、タイル・ベースのグラフィクス・パイプライン・アーキテクチャ・カル・ユニットも、カリング・オペレーションのためのパイプライン中間におけるポスト・タイル・ソーティング・セットアップ・ユニットもなく、頂点メモリ記憶量は大きかった。
【０５３０】  本発明は、タイル・ベースのグラフィクス・パイプライン・アーキテクチャにおいて、ａ）中間パイプライン・カル・ユニットにタイル関連イメージ・データ情報を供給する、中間パイプライン・ポスト・タイル・ソーティング・セットアップ・ユニット、ｂ）三角形とライン・セグメントを四辺形として表し、それにより中間パイプライン・カリング・ユニットのエッジ・ウォーキング論理アーキテクチャ要件を低減するための、統合されたプリミティブ記述子言語、ｃ）プリミティブの頂点のそれぞれをタイル関連ｙ値とスクリーン関連ｘ値に表現することによりプリミティブの頂点を正確且つ効率的に表現するのに必要とされるメモリの量を削減すること、に備えた構造及び方法を提供することにより、現時点での最新技術の限界を乗り越える。
５．好適実施例の詳細な説明
明解さと理解を促すために例証と事例を用いながら、これより本発明について詳しく説明する。時には、擬似コードの事例を提示して本発明のプロシジャを説明する。本説明に用いらる擬似コードは、基本的に、汎用コンピュータ言語協定を使うコンピュータ言語を使用している。本説明に用いらる擬似コードは、この説明での使途に限って発明されたものであり、当技術に長けたコンピュータ・プログラマーなら誰しもが容易に理解できるように設計されている。
【０５３１】  本発明の教示に鑑み、特許請求の範囲に述べる本発明の精神と範囲を逸脱することなく、ある一定の変更及び修正が本発明に加えられ得ることは、当業者には自明であろう。我々は先ず、トップレベル・システムの構成上の説明を行なう。節の見出しは便宜上設けているだけで、開示を限定するものと捉えられるべきではないが、本発明の全て多様な態様は、そういうものとして見出しに特定して明記された幾つかの節に分けて説明する。
【０５３２】  説明上、本発明の計算の数的精度は、グラフィクス・パイプラインの先行ステージ及び後続ステージの精度要件に基づいている。選択された数的精度は多数の要素に依存している。このような要素には、例えば、オペレーションの順序、オペレーションの数、スクリーン・サイズ、タイル・サイズ、バッファ・デプス、サブ・ピクセル精度、データの精度が含まれる。数的精度の問題はよく知られているので、ここではこれ上詳しい説明は避ける。
５．１システム概観
本発明の構造及び方法の重要な態様には、１）中間パイプライン・ポスト・タイル・ソーティング・セットアップ−これは中間パイプライン・ポスト・タイル・ソーティング・ユニットをサポートし更に中間パイプライン・カリング・ユニットをサポートするので有益である、２）ライン・セグメントと三角形を一様に表現するための統合されたプリミティブ表現−これは異なるタイプのプリミティブが、共通のアルゴリズムとグラフィクス・パイプラインの後続ステージのハードウェア・エレメントを共用できるようにするので有益である、３）タイル関連ｙ値とスクリーン関連ｘ値−これは空間データをタイル化アーキテクチャにとって効率的且つ実行可能な領域ベースで領域上に表現できるようにするので有益である、が含まれる。
【０５３３】  図Ｄ１は、統合されたプリミティブ記述子、ポスト・タイル・ソーティング・セットアップ、タイル関連ｘ値、及びスクリーン関連ｙ値を使って、３−Ｄグラフィクス・パイプラインにセットアップ・オペレーションを実行するためのシステム１００のある実施例を示している。厳密には、図Ｄ１はどのようにして様々なソフトウェア及びハードウェア・エレメントが互いに協力し合うかを示している。システム１００は、プログラムされた汎用コンピュータ１０１と３−Ｄグラフィクス・プロセッサ１１７を利用する。コンピュータ１０１は、概括的には設計は従来的であり、ａ）１つ又はそれ以上のデータ・プロセッシング・ユニット（ＣＰＵ）１０２、ｂ）大容量記憶装置としての、高速第１メモリ１０６、キャッシュメモリ１０６ｂ、低速第２メモリ１０６ｃのような、メモリ１０６ａ、１０６ｂ、１０６ｃ、又は前記３タイプのメモリの組み合わせ、ｃ）ディスプレイモニタ１０５ａ、キーボード１０５ｂ、ポインティング・デバイス１０５ｃを含む随意的ユーザー・インターフェース１０５、ｄ）特化されたグラフィクス・ハードウェアにインターフェースを提供する、例えば、アドバンスト・グラフィクス・ポート（ＡＧＰ）のようなグラフィクス・ポート１１４、ｅ）Ｉ／Ｏバス１１２を横断してグラフィクス・ポート１１４に連結され高性能３−Ｄグラフィクス・プロセッシングを提供する３−Ｄグラフィクス・プロセッサ１１７、ｆ）ＣＰＵ１０２、メモリ１０６、特化グラフィクス・ハードウェア１１４、３−Ｄグラフィスク・プロセッサ１１７、随意的ユーザー・インターフェース１０５を相互連結するための１つ又はそれ以上の通信バス１０４を備えている。
【０５３４】  Ｉ／Ｏバス１１２は、これに限定する訳ではないが、アドバンスト・グラフィクス・ポート・バス、周辺コンポーネント・インターコネクト（ＰＣＩ）バス、工業用標準アーキテクチャ（ＩＳＡ）バス、拡張工業用標準アーキテクチャ（ＥＩＳＡ）バス、マイクロチャネル・アーキテクチャ、ＳＣＳＩバス等を含む何れのタイプの周辺バスでもよい。ある好適な実施例では、Ｉ／Ｏバス１１２は、アドバンスト・グラフィクス・ポート・プロである。
【０５３５】  本発明は、コンピュータ１０１のある実施例が、グラフィクス・ハードウェアＩ／Ｏをグラフィクス・プロセッサ１１７に向けて待ち行列に入れるためにグラフィクス・ポート１１４のもう一方側にコマンド・バッファ（図示せず）を有する場合も考慮している。
【０５３６】  メモリ１０６ａは、通常、オペレーティング・システム１０８及び１つ又はそれ以上のアプリケーション・ブログラム１１０、又は、それぞれが普通はランタイムにメモリ１０６の別々のアドレス空間を占める、複数のプロセスを含んでいる。オペレーティング・システム１０８は、通常、例えば、グラフィクス・デバイス・インターフェース、ダイレクト・ドロー／ダイレクト３−Ｄ、及びオープンＧＬのような３−ＤグラフィクスＡＰＩにアクセスするための、アプリケーション・プログラム・インターフェース（ＡＰＩ）をサポートすることを含めて、基本的なシステム・サービスを提供する。ダイレクト・ドロー／ダイレクト３−Ｄ、及びオープンＧＬは全てよく知られたＡＰＩであり、そのためここではこれ以上詳しくは論じない。アプリケーション・プログラム１１０は、例えば、イメージをビューイング及びマニビュレーティングするためのユーザー・レベル・プログラムを含んでいてもよい。
【０５３７】  グラフィクス・パイプライン内のイメージ・データをソートするために、ラップトップ又は他のタイプのポータブル・コンピュータを本発明に接続することもできると理解されたい。更に、サーバに接続されたローカルエリア・ネットワーク上のワークステーションを、グラフィクス・パイプライン内のイメージ・データをソートするために、コンピュータ１０１の代わりに使うこともできる。従って、コンピュータ１０１の詳細な仕様が本発明と特別な関係にあるのではないことがはっきりしたはずである。パーソナル・コンピュータ１０１は、単に、３−Ｄグラフィクス・プロセッサ１１７に対するメッセージの送受信用の従来型インターフェースとして機能するだけである。
【０５３８】  図Ｄ２には、３−Ｄグラフィクス・プロセッサ１１７の代表的実施例を示しており、これは、コンピュータ１０１内の別のＰＣボードとして、コンピュータ１０１のマザーボード上に統合されたプロセッサとして、又は独立型プロセッサとして、Ｉ／Ｏバス１１２又は他の通信リンクを介してグラフィクス・ポート１１４に連結して設けることができる。
【０５３９】  セットアップ２１５は、グラフィクス・プロセッサ１１７の多数のプロセッシング・ステージの内の１つのプロセッシング・ステージとして実現される。（セットアップ２１５は、米国仮特許出願番号第６０／０９７，３３６号に説明してぃる「セットアップ・ステージ８０００」と相関している。）
セットアップ２１５は、内部バス２１１及び信号ライン２１２を介して他のプロセッシング・ステージ２１０に接続されている。セットアップ２１５は、内部バス２１６及び信号ライン２１７を介して他のプロセッシング・ステージ２２０に接続されている。
【０５４０】  内部バス２１１及び内部バス２１６は、これに限定するわけではないが、周辺コンポーネント・インターコネクト（ＰＣＩ）バス、工業用標準アーキテクチャ（ＩＳＡ）バス、拡張工業用標準アーキテクチャ（ＥＩＳＡ）バス、マイクロチャネル・アーキテクチャ、ＳＣＳＩバス等を含む、何れのタイプの周辺バスであってもよい。ある好適な実施例では、内部バス２１１は専用のオンチップ・バスである。
５．１．１他のプロセッシング・ステージ２１０
図Ｄ３には、コマンドフェッチ及びデコード３０５、ジオメトリ３１０、モード抽出３１５、ソート３２０を含む、他のプロセッシング・ステージ２１０の好適な実施例の例を示している。これら他のプロセッシング・ステージ２１０のそれぞれにつきここで簡単に論議する。
【０５４１】  ＣｍｄＦｅｃｈ／Ｄｅｃｏｄｅ３０５即ち「ＣＦＤ３０５」は、グラフィクスポート１１４を介してホストコンピュータ１０１との通信を扱う。ＣＦＤ３０５は、ビットマップ・プリット・ウィンドウ・オペレーションのような２−Ｄスクリーン・ベースのデータを、バックエンド４４０に直接送信する（図Ｄ４バックエンド４４０参照）が、それは、このタイプの２−Ｄデータは通常、他のプロセッシング・ステージ２１０又は他のプロセッシング・ステージ２４０中のその他のプロセッシング・ステージに関連して更に処理される必要がないからである。全ての３−Ｄオペレーション・データ（例えば、必要な変換マトリクス、材料及びライト・パラメータ、及び他のモード・セッティング）はＣＦＤ４０５によりジオメトリ４１０に送られる。
【０５４２】  ジオメトリ４１０は、ポイント、ライン・セグメント、三角形のような、以後しばしば「プリミティブ」と称する、フレーム・ジオメトリック・プリミティブを３−Ｄモデルで表示するのに関係する計算を行なう。これらの計算には変換、頂点ライティング、クリッピング及びプリミティブ・アッセンブリが含まれる。ジオメトリ４１０は、「正しく方位が定められた」ジオメトリ・プリミティブをモード抽出４１５に送る。
【０５４３】  モード抽出３１５は、ジオメトリ３１０からのインプット・データ・ストリームを２つの部分、即ち、１）フレーム・ジオメトリ座標のような空間データ及び陰面除去に必要なあらゆる他の情報と、２）カラー、テクスチャ、及びライティング情報のような非空間データに分ける。空間データは、ソート２１５に送られる。非空間データは多角形メモリ（図示せず）に記憶される。（モード注入４１５（図Ｄ５参照）とパイプライン２００）。
【０５４４】  ソート３２０は、２−Ｄウィンドウ内の多数の領域に関して頂点及びモード情報をソートする。ソート３２０は、空間的にソートされた頂点及びモード情報を領域毎ベースでセットアップ２１５に出力する。
【０５４５】  プロセッシング・ステージ２１０の詳細は、本発明の具現化には必要ではないので、他のプロセッシング・ステージ２１０についてはここではこれ以上詳しく論じない。
５．１．２他のプロセッシング・ステージ２４０
図Ｄ４には、カル４１０、モード注入４１５、フラグメント４２０、テクスチャ４２５、フォング・ライティング４３０、ピクセル４３５、バックエンド４４０を含む、他のプロセッシング・ステージ２２０の好適な実施例の例を示す。他のプロセッシング・ステージ２４０中の個々のプロセッシング・ステージの詳細は、本発明を具現化する上で必要だはない。しかしながら、完全を期すために、これらプロセッシング・ステージの各々につきこれより簡単に説明する。
【０５４６】  カル４１０は、セットアップ４０５のようなグラフィクス・パイプライン内の前のステージから領域毎順にデータを受信して、レンダされたイメージには決して寄与することのないプリミティブ又はプリミティブの一部を捨てる。カル４１０は、先に処理されたジオメトリにより隠されてぃない空間データを出力する。
【０５４７】  モード注入４１５は、モード情報（例えば、カラー、材料特性等）を他のメモリ２３５のような多角形メモリから検索し、それをフラグメント４２０のようなグラフィクス・パイプライン２００内の次のステージへ、必要に応じて送る。フラグメント４２０は、ガウラード・シェーディング用のカラー値、フォング・シェーディング用の面法線、テクスチャ・マッピング用のテクスチャ座標を翻訳して、（必要であれば）バンプ・マッピング・アルゴリズムで使用するため面正接を補間する。
【０５４８】  テクスチャ４２５は、テクスチャ・メモリに記憶されているテクスチャ・マップをピクセル・フラグメントに適用する。フォング４３０は、モード注入４２５により供給された材料及びライティング情報を使って、各ピクセル・フラグメント毎にフォング・シェーディングを実行する。ピクセル４３５は、可視面部及びフラグメント・カラーを受信して、最終的なピクチャを生成する。そして、バックエンド１３９は、１度に１タイル相当のデータをピクセル４３５から受信し、そのデータをフレーム・ディスプレイ・バッファ内に記憶する。
５．２セットアップ２１５概観
セットアップ２１５はパイプライン２００の前のプロセッシング・ステージからイメージ・データのストリームを受信する。本発明のある好適な実施例では、前のプロセッシング・ステージはソート３２０（図Ｄ３参照）である。これらのイメージ・データは、パイプライン２００によりレンダされるべきジオメトリック・プリミティブについての空間情報を含んでいる。ソート３２０から受信されるプリミティブは、フィルド三角形、ライン三角形、ライン、スティップルド・ライン、ポイントの何れかである。これらイメージ・データはモード情報も含んでいる。
【０５４９】  モード情報は、必ずしも何らかの特定のプリミティブに適用するのではなく、むしろ多数のブリミティブに適用する情報である。一例をあげるなら、例えばコンピュータ１０１（図Ｄ１参照）上で起動している３−Ｄグラフィクス・アプリケーションは、フレームのレンダリング中に、例えば、カラー・バッファ、デプス・バッファ、及び／又はステンシル・バッファを含む１つ又はそれ以上のバッファをクリアできる。カラー・バッファ、デプス・バッファ、ステンシル・バッファは知られているので、ここでは詳しく説明しない。アプリケーションは、通常、フレーム・レンダリング・プロセスの開始直後にだけバッファ・クリアを実行する。このようなバッファ・クリア・モード情報を示すために、パイプライン２００の前のステージはモード情報をパイプライン２００に送り込む。
【０５５０】  セットアップ２１５がソート３２０により送信されたプリミティブを受信するときまでには、プリミティブは、ソート３２０により、イメージ・フレーム毎の順に、２−Ｄウィンドウ内の多数の領域に対して空間的にソートされている。セットアップ２１５は、各プリミティブ及びあらゆる対応するモード情報を、ソート３２０から領域毎ベースで受信する。つまり、このセットアップ２１５は、２−Ｄウィンドウのフレームの各領域にタッチする全プリミティブをあらゆる対応するモード情報と共に、２−Ｄウィンドウの異なる各領域にタッチする全プリミティブを異なる各領域に対応するあらゆるモード情報と共に受信する前に、受信するということである。本発明のある好適な実施例では、２−Ｄウィンドウの各領域は長方形タイルである。
各領域内で、イメージデータは「タイム・オーダー（時間順）」又は「ソート済み透明度順」に編成される。タイム・オーダーでは、パイプライン２００の先行する全プロセッシング・ステージにより、各タイル内の頂点及びモードが受信されたときのタイム・オーダーが保存される。即ち、所与のタイルに関し、頂点及びモードは、ソート３２０がソート済み透明モードである場合を除いて、パイプライン２００の先行ステージから、それらが受信されたときの順序で読み出される。
【０５５１】  ソート済み透明モードでは、「保証された不透明」なプリミティブは、セットアップ２１５が潜在的に透明なジオメトリを受信する前に、セットアップ２１５により受信される。このコンテクストで、保証された不透明とは、プリミティブがウィンドウの同じ区域を占めるより遠くのプリミティブを完全に覆い隠すという意味である。潜在的に透明なジオメトリは、保証された不透明ではないあらゆるジオメトリのことである。
【０５５２】  セットアップ２１５は、カル４１０によるプロセッシングに備えて入ってくるイメージ・データを準備する。ＣＵＬ４１０は、パイプライン２００内の後続のプロセッシング・ステージにより使用される、可視スタンプ部、即ち「ＶＳＰ」を生成する。説明上、スタンプは２ピクセル×２ピクセルのディメンジョンの領域である。１ピクセルは４つのサンプル・ポイントを含んでいる。１タイルは１６スタンプ（８×８）である。カリング（選別除去）に先だってセットアップ２１５により行われる予備プロセッシングが理解し易いように、ここでカリングについて簡単に説明する。
【０５５３】  カル４１０は、セットアップ２１５から領域順（実際にセットアップ２１５がソート３２０からイメージ・データを受信する順）にイメージ・データを受信して、レンダされたイメージには決して寄与することのないプリミティブ及びプリミティブの部分を選別除去する。カル４１０は、これを２段階、即ちＭＣＣＡＭカル４１０ステージとＺカル４１０ステージで行なう。ＭＣＣＡＭカル４１０では、「コンテンツ」（デプス値）が所与の値よりも大きい、長方形の空間的にアドレス可能なメモリ・アレイ内のメモリ・エレメントを検出できる。空間的にアドレス可能なメモリは既知である。
【０５５４】  Ｚカル４１０は、ＭＣＣＡＭカル４１０により行なわれた作業を、サンプル毎のコンテンツ比較を行なうことにより精製する。サンプル毎のコンテント比較とは、見える可能性のある各スタンプ毎に、ｚ値（デプス値）がスタンプ内の各サンプルで計算されることを意味する。サンプル毎のコンテンツ比較では、プリミティブにカバーされている各サンプル・ポイントで使用中の値がＺ−バッファ・メモリと比較され、どのサンプル・ポイントが可視であるかを判定するので、第１段階により実行された作業が精製される。Ｚ−バッファ・メモリは、各サンプル・ポイント毎に最も近いデプス値を保持し、従って更新される。
【０５５５】  ＭＣＣＡＭによるプロセッシングに備えて入ってくるイメージ・データを準備するため、セットアップ２１５は、各プリミティブ毎に、ａ）タイルに交わるプリミティブの部分の周りにぴったり合った境界画定ボックスのディメンジョンを求め、ｂ）タイルに交わるプリミティブのその部分に対する最小デブス値「Ｚｍｉｎ」を計算する。これは、ＭＣＣＡＭカル４１０が、境界画定ボックスのディメンジョンと最小デプス値を使って、その境界画定ボックスのディメンジョン内にそれぞれに存在している多数の「スタンプ」のどれがＺｍｉｎより小さいデプス値を持っているのかを求めるので有用である。境界画定ボックスのディメンジョンを求めるプロシジャ、並びに最小デプス値を作るプロシジャについては後に詳しく説明する。
【０５５６】  説明を簡単にするために、境界画定ボックスのディメンジョン内に在るスタンプを以後「候補スタンプ」と呼ぶことにする。
【０５５７】  Ｚカル４１０は、これらの候補スタンプを採り、それらがプリミティブの一部であるなら、そのスタンプ内のサンプルに対する実際のデプス値を計算することにより、どのスタンプが可視であるかを判定するというプロセスを精製する。この正確な値がここで、サンプル毎ベースで、カル４１０のｚ−バッファ・メモリに記憶されているｚ−値と比較され、そのサンプルが可視であるか否かが判定される。サンプル毎ベースというのは、境界画定ボックス全体が一度に比較されるステップに対比して、各サンプルが個別的に比較されるという意味しかない。
【０５５８】  セットアップ２１５は又、デプス勾配、ライン傾斜、他の基準パラメータ及びプリミティブとタイル辺との交点を、カル４１０のために計算する。上記のように、最小デプス値及び境界画定ボックスはＭＣＣＡＭカル４１０により利用される。ｚｒｅｆ及びデプス勾配はＺカル４１０により使用される。ライン（辺）傾斜、交点、及びコーナー（頂部及び底部）は、エッジ・ウォーキングのためＺカル４１０により使用される。
【０５５９】  ライン及び三角形であるプリミティブに対して、セットアップ２１５は空間導関数を計算する。空間導関数はデプス値の偏導関数である。空間導関数は、Ｚ傾斜又はデプス勾配としても知られている。
５．２．１パイプラインの他のプロセッシング・ステージとのインターフェースＩ／Ｏ
セットアップ２１５は、パイプライン２００の先行ステージ、例えばソート３２０（図Ｄ３参照）及びパイプライン２００の後続ステージ、例えばカル４１０（図Ｄ４参照）とインターフェースしている。これよりソート３２０アウトプット・パケットについて論じる。
５．２．１．１ソート３２０セットアップ２１５インターフェース
表１には、イメージ・データのフレームの開始の境界を定める開始フレーム・パケット１０００を示している。開始フレーム・パケット１０００は、セットアップ２１５によりソート３２０から受信される。表２には、特定のタイル相当のイメージ・データの開始の境界を定める開始タイル・パケット２０００の例を示している。
【０５６０】  表４には、バッファ・クリア・イベントを表示するための、クリア・パケット４０００の例を示している。表５には、他のものの中にパケット・タイプ５０１０を示すための、カル・パケット５０００の例を示している。表６には、イメージ・データのフレームの終了をソート３２０により示すための、終了フレーム・パケット６０００の例を示している。表７には、プリミティブに関する情報を識別するための、プリミティブ・パケット７０００の例を示している。ソート３２０は各プリミティブ毎に、１プリミティブ・パケット７０００をセットアップ２１５に送る。
５．２．１．２セットアップ２１５カル４１０インターフェース
表８には、パイプライン２００の次のステージ、例えばカル４１０に、セットアップ２１５により定められたプリミティブの情報を示すための、セットアップ・アウトプット・プリミティブ・パケット８０００の例を示している。このような情報については以下に詳細に説明する。
５．２．２セットアップ・プリミティブ
本発明のコンテキストをセットするため、例えば多角形、ライン、及びポイントを含むセットアップ・プリミティブにつき簡単に説明する。
５．２．２．１多角形
セットアップ２１５に到着する多角形は、基本的には三角形であり、フィルド三角形又はライン・モード三角形の何れかである。フィルド三角形は３つの頂点として表される。一方ライン・モード三角形は、セットアップ２１５により３本の個別のライン・セグメントとして扱われる。セットアップ２１５は、ライン・モード三角形とフィルド三角形の双方に対し３つの三角形頂点を定義するウィンドウ座標（ｘ，ｙ，ｚ）を受信する。多角形のエイリアスド状態（エイリアスド又はアンチエイリアスドの何れか）により、フィルド多角形セットアップがセットアップ２１５により実行されるやり方が変更になることはない点に留意されたい。ライン・モード三角形については以下に詳細に説明する。
５．２．２．２ライン
セットアップ２１５は、ラインを四辺形又は「クワッド」に変換する。図Ｄ１５は、ライン・セグメントに関して生成された四辺形の例を示している。四辺形はエイリアスド・ラインとアンチエイリアスド・ラインにつき異なって生成されることに留意されたい。エイリアスド・ラインについては、四辺形の頂点もラインがｘメジャであるのかｙメジャであるのかにより異なる。セットアップ２１５は入ってくるライン幅を修正しない。（表６のプリミティブ・パケット６０００を参照。）四辺形生成は、四辺形生成機能ユニットに関連して後に詳しく説明する。
【０５６１】  本発明のある好適な実施例では、ライン幅はセットアップ２１５の前に決められる。例えば、それはコンピュータ１０１（図Ｄ１参照）上で起動している３−Ｄグラフィクス・プロセッシング・アプリケーション上で確定できる。
５．２．２．３ポイント
パイプライン２００は、アンチエイリアスド・ポイントを円として、そしてエイリアスド・ポイントを正方形としてレンダする。円と正方形は両方とも幅がある。本発明のある好適な実施例では、ポイントのサイズと位置の決定は、パイプライン２００の先行ステージ、例えばジオメトリ３１０で確定される。
５．３統合されたプリミティブ記述
統合されたプリミティブの標題の下で、我々はライン・プリミティブを長方形と考え、三角形を退化した長方形と考え、各々数学的にそのように表現される。換言すれば、セットアップ２１５は、各プリミティブを４頂点から成るセットで記述する。全プリミティブを記述するのに全頂点値が必要なわけではないことに留意されたい。ライン・セグメントは、平行四辺形として扱われるので、セットアップ２１５は全４頂点を使う。三角形を記述するには、セットアップ２１５は三角形の頂部頂点、底部頂点、及び三角形の方位により左角頂点又は右角頂点の何れかを使用する。
【０５６２】  例えば、図Ｄ５に戻るが、この図では、本発明の統合されたプリミティブ記述による頂点割り当ての例を示している。（図Ｄ５は、米国仮特許出願番号第６０／０９７，３３６号の図４７と関連している。）三角形５０５は、三角形５０５の頂部頂点（Ｘ−Ｔｏｐ５１０，Ｙ−Ｔｏｐ５１５）、底部値（Ｘ−Ｂｏｔｔｏｍ５２０，Ｙ−Ｂｏｔｔｏｍ５２５）及び右角頂点（Ｘ−Ｒｉｇｈｔｄｒｉｖｅ３０，Ｙ−Ｒｉｇｈｔ５３５）を使ってセットアップ２１５により記述される。三角形５４０は、三角形５４０の頂部頂点（Ｘ−Ｔｏｐ５４５，Ｙ−Ｔｏｐ５５０）、底部値（Ｘ−Ｂｏｔｔｏｍ５５５，Ｙ−Ｂｏｔｔｏｍ５６０）及び左角頂点（Ｘ−Ｌｅｆｔ５６５，Ｙ−Ｌｅｆｔ５７０）を使ってセットアップ２１５により記述される。
【０５６３】  開示の簡略化上、以下の名前付け規定、即ち、ａ）ＶＴは（Ｘ−ＴＯＰ，Ｙ−ＴＯＰ）を表す、ｂ）ＶＭは（Ｘ−ＭＩＤＤＬＥ，Ｙ−ＭＩＤＤＬＥ）を表し、ここにＸ−ＭＩＤＤＬＥは、三角形の方位により（詳細は先に論じている）Ｘ−ＲＩＧＨＴ又はＸ−ＬＥＦＴの何れかであり、Ｙ−ＭＩＤＤＬＥは、三角形の方位によりＹ−ＲＩＧＨＴ又はＹ−ＬＥＦＴの何れかであり、ｃ）ＶＢは（Ｘ−ＢＯＴＴＯＭ，Ｙ−ＢＯＴＴＯＭ）を表す、という規定を採用している。
【０５６４】  この規定を説明するため、三角形５０５の頂点がこの規定に対してマップされる。本例では、ＶＴは（Ｘ−ＴＯＰ５１０，Ｙ−ＴＯＰ５１５）を表し、ＶＭは（Ｘ−ＲＩＧＨＴ５３０，Ｙ−ＲＩＧＨＴ５３５、本例のＶｔｘＬｅｆｔＣは退化している）を表し、ＶＢは（Ｘ−ＢＯＴＴＯＭ５２０，Ｙ−ＢＯＴＴＯＭ５２５）を表す。
【０５６５】  ライン・セグメントは平行四辺形として扱われるので、セットアップ２１５は全４頂点を使用してライン・セグメントを記述する。三角形の頂点はその元の頂点と同じであるが、セットアップ２１５はライン・セグメントを平行四辺形として表現するために新しい頂点を生成することに留意されたい。
【０５６６】  プリミティブの統合された表現は、記述子を２セット使用して１つのプリミティブを表す。第１のセットは、各々がウィンドウ座標内の頂点の元のセットに割当てられている頂点記述子を含んでいる。頂点記述子には、ＶｔｘＹＭｉｎ、ＶｔｘＹＭａｘ、ＶｔｘＸＭｉｎ、及び、ＶｔｘＸＭａｘが含まれる。記述子の第２のセットは、どの頂点記述子が有効且つ意味のある値を有するかを示すためにセットアップ２１５が使用する、フラグ記述子又はコーナー・フラグである。フラグ記述子には、ＶｔｘＬｅｆｔＣ、ＶｔｘＲｉｇｈｔＣ、ＬｅｆｔＣｏｒｎｅｒ、ＲｉｇｈｔＣｏｒｎｅｒ、ＶｔｘＴｏｐＣ、ＶｔｘＢｏｔＣ、ＴｏｐＣｏｒｎｅｒ、及びＢｏｔｔｏｍＣｏｒｎｅｒが含まれる。図Ｄ２２は、コーナー・フラグを含め、統合されたプリミティブ記述子割当ての態様を示している。
【０５６７】  これら記述子の全ては四辺形プリミティブに対する有効値を有するが、それらすべてが三角形について有効なわけではない。本発明の教示により三角形を長方形として扱うことは、４つの頂点を特定することを含むが、その内の１つ（ある特定の実施例では、通常はｙ−ｌｅｆｔ又はｙ−ｒｉｇｈｔ）は退化しており特定されない。これを説明するため、図Ｄ５では、三角形５０５は左角頂点が退化して、定義されていない。三角形５４０に関しては、右角頂点が退化している。本発明の教示によるプリミティブ記述子を使って、三角形とライン・セグメントを長方形として記述すると、異なるプリミティブに関して演算するのに同じ（又は同様の）アルゴリズム／方程式／計算／ハードウェアが使用でき、効率的なインプリメンテーションができるので、セットアップ・プリミティブに対して良好且つ均一的な方法を提供することになる。これより、プリミティブ記述子とその使い方を説明する。
【０５６８】  これより、ＶｔｘＹＭｉｎ、ＶｔｘＹＭａｘ、ＶｔｘＬｅｆｔＣ、ＶｔｘＲｉｇｈｔＣ、ＬｅｆｔＣｏｒｎｅｒ、ＲｉｇｈｔＣｏｒｎｅｒ記述子がどのように入手されるかについて説明する。ライン・セグメントに対して、これら記述子はライン・クワッド頂点が生成されるときに割当てられる。しかしながら、三角形については、セットアップ２１５は三角形の頂点をそれらの座標によりソートする。ＶｔｘＹｍｉｎは最小ｙ値を有する頂点である。ＶｔｘＹｍａｘは最大ｙ値を有する頂点である。ＶｔｘＬｅｆｔＣは、三角形の場合には、頂点ＶｔｘＹｍｉｎとＶｔｘＹｍａｘを連結することにより形成される三角形の辺（以後「ｙ長辺」とも呼ぶ）の左にある頂点、そして平行四辺形の場合は頂点ＶｔｘＹｍｉｎとＶｔｘＹｍａｘをつなぐことにより形成される対角線の左にある頂点である。
【０５６９】  三角形が、ｙ長辺が左辺でもあるような三角形であれば、フラグＬｅｆｔＣｏｒｎｅｒはＶｔｘＬｅｆｔＣが退化しており定義されないことを示す偽（０）である。ＶｔｘＲｉｇｈｔＣは、三角形の場合にはｙ長辺の右にある頂点で、平行四辺形の場合にはＶｔｘＹｍｉｎとＶｔｘＹｍａｘをつないで形成された対角線の右にある頂点である。三角形が、長辺が右辺でもあるような三角形であれば、フラグＲｉｇｈｔＣｏｒｎｅｒは、ＶｔｘＲｉｇｈｔＣが退化しており定義されないことを示す偽（０）である。三角形は、２辺が必ず頂部頂点（ＶｔｘＹｍａｘ）を共有する。この２辺のうちで、エンド・ポイントが最も左にある方が左辺である。これと同様に、エンド・ポイントが最も右にある方が右辺である。
【０５７０】  実際には、ＶｔｘＹｍｉｎ、ＶｔｘＹｍａｘ、ＶｔｘＬｅｆｔＣ、ＶｔｘＲｉｇｈｔＣは元のプリミティブ頂点へのインデクスである。セットアップ２１５はＶｔｘＹｍｉｎ、ＶｔｘＹｍａｘ、ＶｔｘＬｅｆｔＣ、ＶｔｘＲｉｇｈｔＣ、ＬｅｆｔＣｏｒｎｅｒ、ＲｉｇｈｔＣｏｒｎｅｒを使って、プリミティブをタイルの頂辺及び底辺に対してクリップする。
【０５７１】  これより、ＶｔｘＸｍｉｎ、ＶｔｘＸｍａｘ、ＶｔｘＴｏｐＣ、ＶｔｘＢｏｔＣ、ＴｏｐＣｏｒｎｅｒ、ＢｏｔｔｏｍＣｏｒｎｅｒの記述子がどのように入手されるかについて説明する。ライン・セグメントの場合は、これらの記述子はライン・クワッド頂点が生成されるときに割当てられる。ＶｔｘＸｍｉｎは最小ｘ値を有する頂点である。ＶｔｘＸｍａｘは最大ｘ値を有する頂点である。ＶｔｘＴｏｐＣは、三角形の場合には、頂点ＶｔｘＸｍｉｎとＶｔｘＸＭａｘ（以後、この辺を「ｘ長辺」とも呼ぶこともある）をつないだ辺の上にある頂点、そして平行四辺形の場合は頂点ＶｔｘＸｍｉｎとＶｔｘＸｍａＸをつなぐことにより形成される対角線の上にある頂点である。
【０５７２】  三角形が、ｘ長辺が「頂辺」でもあるような三角形であれば、フラグＴｏｐＣｏｒｎｅｒはＶｔｘＴｏｐＣが定義されないことを示す偽（０）である。同様にＶｔｘＢｏｔＣは、三角形の場合には長いｘ軸の下にある頂点で、平行四辺形の場合にはＶｔｘＸｍｉｎとＶｔｘＸｍａｘをつないで形成される対角線の下にある頂点である。三角形は最大ｘ頂点（ＶｔｘＸｍａｘ）を共有している２辺を有する。これら２辺のうち一番上にある方が「頂辺」である。同様に、これら２辺のうち最も下にある方が「底辺」である。
【０５７３】  三角形が、ｘ長辺が「底辺」でもあるような三角形であれば、フラグＢｏｔｔｏｍＣｏｒｎｅｒはＶｔｘＢｏｔＣが定義されないことを示す偽（０）である。図Ｄ２３では、ｘ長辺、ｙ長辺、頂辺、底辺、右辺、及び、左辺のマッピングの態様を示している。
【０５７４】  実際には、ＶｔｘＸｍｉｎ、ＶｔｘＸｍａｘ、ＶｔｘＴｏｐＣ、及びＶｔｘＢｏｔＣは元の三角形プリミティブへのインデクスである。セットアップ２１５はＶｔｘＸｍｉｎ、ＶｔｘＸｍａｘ、ＶｔｘＴｏｐＣ、ＶｔｘＢｏｔＣ、ＴｏｐＣｏｒｎｅｒ、ＢｏｔｔｏｍＣｏｒｎｅｒを使って、プリミティブをタイルの左辺及び右辺に関してクリップする。クリッピングについては後に詳しく説明する。
【０５７５】  本発明の統合されたプリミティブ記述子の使用を説明するため、６を参照すると、ここには本発明の統合されたププリミティブ記述子の好適な実施例による、頂点記述子とフラグ記述子を使って記述された多数の三角形及びライン・セグメントが示されている。
５．４ハイレベル機能ユニット・アーキテクチャ
セットアップ２１５のＩ／Ｏサブシステム・アーキテクチャは、ソート３１５（図Ｄ３参照）から受信したプリミティブとモード情報を、カル４１０（図Ｄ４参照）によるプロセッシングにとって最適となるようなやり方で処理する必要に合わせて設計されている。このようなプリミティブには、フィルド三角形、ライン三角形、アンチエイリアスド・ソリッド・ライン、エイリアスド・ソリッド・ライン、スティップルド・ライン、エイリアスド及びアンチエイリアスド・ポイントが含まれる。
【０５７６】  このタスクを実現するに当たり、セットアップ２１５は、カル４１０に対する対応するタイルに関するプリミティブについての情報を準備するため多くのプロシジャを実行する。図Ｄ６に示すように、これらプロシジャを考察することにより、本発明の対応するプロシジャを実現する以下の機能ユニット、即ち、ａ）統合されたプリミティブ記述子を生成し、３辺のライン傾斜及び逆傾斜を計算し、三角形が左角又は右角を有するかを判定するための三角形プロセッサ２、ｂ）ラインの方位を判定し、ラインの傾斜と逆数を計算し、左及び右傾斜と逆傾斜とを識別し、エンド・オン・ラインを捨てるためのライン・プロセッサ２、ｃ）パイプライン２００の次の選別ステージが必要とする空間情報のセットを計算するためのポイント・プロセッサ２、ｄ）ラインの半値幅を計算するための三角法ユニット３、及び画質を改善するために規定の幅を増やすことによりアンチエイリアスド・ラインを処理するための三角形ユニット３、ｄ）ラインをライン周りにセンタリングされた四辺形へと変換し、エイリアスド・ポイントを適当な幅の正方形に変換するための、四辺形生成ユニット４、ｄ）プリミティブ（三角形又は四辺形）をタイルにクリップし、新しいクリップされた多角形の頂点を生成するための、クリッピング・ユニット５、ｅ）新しいクリップされた多角形を囲む最小のボックスを決めるための境界画定ボックス・ユニット６、ｆ）ライン又は三角形のデプス勾配（ｄｚ／ｄｘ及びｄｚ／ｄｙ）を計算するための、そして三角形の場合は更にデプス・オフセットを計算するための、デプス勾配及びデプス・オフセット・ユニット７、ｇ）最小Ｚ値を有する頂点を選択することにより最小デプス値を決めて、Ｚｍｉｎ位置に最も接近しているスタンプ中心を計算するための、Ｚｍｉｎ及びＺｒｅｆユニット８、が生じる。
【０５７７】  本発明の好適な実施例では、三角形プロセッサ・ユニット及びライン・プロセッサ・ユニットは同一のユニットである。
【０５７８】  本発明のある実施例では、インプット・バッファ１はキューと保持バッファを備えている。本発明のある好適な実施例では、キューは深さが大凡３２エントリで幅が大凡１４０バイトである。パイプライン２００内の次の処理、例えばソート３２０からのインプット・データ・パケットがより多くのビットを必要とする場合、キューの幅は２つのグループに分割されキュー内の２つのエントリを占めることになる。キューは、ソート３２０（図３参照）及びセットアップ２１５の間の異なるデータ速度の均衡をとるために使用される。本発明は、インプット・キュー１が容量に達した場合、ソート３２０とセットアップ２１５が協力することを考慮している。保持バッファは、三角形を取り囲む三角形プリミティブからライン・モード三角形用の可視辺へと読み取られた頂点情報を保持している。
【０５７９】  アウトプット・バッファ１０は、パイプライン２００の次のステージ例えばカル４１０へ渡すための、セットアップ２１５により処理されたイメージ・データを、待ち行列に入れるため、セットアップ２１５により使用される。
【０５８０】  図Ｄ６は、本発明のプロシジャを実現する機能ユニット間のデータ・フローも示している。
以下の副節では、これら機能ユニット各々のアーキテクチャについて詳しく説明する。
５．４．１三角形プリプロセッシング
三角形の場合は、セットアップは頂点のセット、即ち（ｘ０，ｙ０，ｚ０）、（ｘ１，ｙ１，ｚ１）及び（ｘ２，ｙ２，ｚ２）で始まる。セットアップ２１５は、フィルド三角形の頂点がウィンドウ座標の有効範囲内に納まる、つまり、三角形の座標はウィンドウの境界にクリップされているものと仮定する。このプロシジャは、パイプライン２００の先行プロセッシング・ステージ、例えばジオメトリ３１０（図Ｄ３参照）により実行できる。
【０５８１】  三角形プロセッサは、１）３つの頂点をｙ方向にソートして、最上の頂点（ＶｙｘＹｍａｘ）中間頂点（ＶｔｘＲｉｇｈｔＣ又はＶｔｘＬｅｆｔＣの何れか）及び最下の頂点（ＶｔｘＹｍｉｎ）を求め、２）三角形の３辺の傾斜及び逆傾斜を計算し、３）ｙソートされた三角形が左角（ＬｅｆｔＣｏｒｎｅｒ）又は右角（ＲｉｇｈｔＣｏｒｎｅｒ）を有するかを判定し、５）３つの頂点をｘ方向にソートして、最右頂点（ＶｔｘＸｍａｘ）、中間頂点、最左頂点（ＶｔｘＸｍｉｎ）を求め、６）ｘソートされたＴｏｐ（ＶｔｘＴｏｐＣ）、Ｂｏｔｔｏｍ（ＶｔｘＢｏｔＣ）又はＬｅｆｔに対応する傾斜を識別する。
５．４．１．１Ｙ軸に関するソート
本発明はフィルド三角形頂点をｙ方向に、例えば以下の３つの数式を用いてソートする。
【０５８２】
【数１】
2004272928.tif 000018
上記数式に関して、ａ）「Ｇｅ」はより大きい又は等しいを表し、ｂ）「｜」符号は論理和「ｏｒ」を表し、ｃ）「＆」符号は論理積「ａｎｄ」を表す。
【０５８３】  Ｙ１ＧｅＹ０、Ｙ２ＧｅＹ１、及びＹ０ＧｅＹ２はプール値である。
【０５８４】  タイム・オーダーに順序付けられた頂点は、Ｖ０、Ｖ１、及びＶ２であり、ここにＶ０は最も古い頂点でＶ２はノーズ頂点である。ポインタは、どのタイム・オーダー順の頂点が、頂部（ＶｙｘＹｍａｘ）、中間（ＶｔｘＬｅｆｔＣ又はＶｔｘＲｉｇｈｔＣ）及び底部（ＶｔｘＹｍｉｎ）を含むどのＹソートされた頂点に対応するかを識別するため、セットアップ２１５により使用される。例えば、
【０５８５】
【数２】
2004272928.tif 000019
ＹｓｏｒｔＴｏｐＳｒｃは、タイム・オーダーに順序付けられた頂点のうちどの頂点がＶｔｘＹｍａｘであるかを識別するための３ビット・エンコーディングを表す。ＹｓｏｒｔＭｉｄＳｒｃは、タイム・オーダーに順序付けられた頂点のうちどの頂点がＶｔｘＹｍｉｄであるかを識別するための３ビット・エンコーディングを表す。ＹｓｏｒｔＢｏｔＳｒｃは、タイム・オーダーに順序付けられた頂点のうちどの頂点がＶｔｘＹｍｉｎであるかを識別するための３ビット・エンコーディングを表す。
【０５８６】  次に、ｙソート順に対するタイム・オーダーに順序づけられたデータの宛先を識別するためのポインタが計算される。これは、これらのポインタが、ｙソート型からタイム・オーダー型へ、タイム・オーダー型からｙソート型へ等のように、情報をマップ・バック及びマップ・フォースするのに必要であるという理由で行なわれる。同様の数式を使用して、ｘソート順に対するタイム・オーダー順のデータの宛先を識別する。
【０５８７】
【数３】
2004272928.tif 000020
符号「！」は論理否定「ｎｏｔ」を表す。Ｙｓｏｒｔ０ｄｅｓｔは、Ｖ０がどのｙソートされた頂点に対応するかを識別するポインタを表す。Ｙｓｏｒｔ１ｄｅｓｔは、Ｖ１がどのｙソートされた頂点に対応するかを識別するポインタを表す。Ｙｓｏｒｔ２ｄｅｓｔは、Ｖ２がどのｙソートされた頂点に対応するかを識別するポインタを表す。
【０５８８】  参照されないソート済み頂点、即ちＶＴ＝（ＸＴ，ＹＴ，ＺＴ）、ＶＢ＝（ＸＢ，ＹＢ，ＺＢ）、及びＶＭ＝（ＸＭ，ＹＭ，ＺＭ）を呼び出すが、ここにＶＴはＹが最大で、ＶＢはＹが最小である。参照されないという語は、ポインタが保持されたままであることを強調するために使用されている。ＶＴはＶｔｘＹｍａｘ、ＶＢはＶｔｘＹｍｉｎ、そしてＶＭはＶｔｘＹｍｉｄである。
【０５８９】  逆傾斜（詳細は後に説明）は、Ｖ０、Ｖ１、及びＶ２が一部タイム・オーダー型頂点であることから、ｙソート順に対応するラベルに対してマップされる必要がある。Ｓ０１、Ｓ１２、及びＳ２０は、それぞれ、ａ）Ｖ０とＶ１、ｂ）Ｖ１とＶ２、ｃ）Ｖ２とＶ０、の間の辺の傾斜である。従って、ｙに関して頂点をソートした後、ＶＴとＶＭ、ＶＴとＶＢ、及びＶＭとＶＢの間の傾斜が得られる。この観点から、ポインタはしかるべく定められる。
【０５９０】  本発明のある好適な実施例は、逆傾斜を以下のラベル、即ち、ａ）ＹｓｏｒｔＳＴＭＳｒｃはＳＴＭ（ＶＴ及びＶＭ）がどのタイム・オーダー傾斜に対応しているかを表す、ｂ）ＹｓｏｒｔＳＴＢＳｒｃはＳＴＢ（ＶＴ及びＶＢ）がどのタイム・オーダー傾斜に対応しているかを表す、ｃ）ＹｓｏｒｔＳＭＢＳｒｃはＳＭＢ（ＶＭ及びＶＢ）がどのタイム・オーダー傾斜に対応しているかを表す、に対してマップする。
／／傾斜（タイム・オーダー型からｙソート型への）エンコーディングのソースを識別するためのポインタは３ビット、「ワン・ホット」｛Ｓ１２，Ｓ０１，Ｓ２０｝である。ワン・ホットとは、ワン・ビットだけが「ワン」になり得ることを意味する。
／／１，０，０はＳ１２を、０，１，０はＳ０１を、０，０，１はＳ２０を表す。
【０５９１】
【数４】
2004272928.tif 000021
インデクスは、どのビットが参照されているのかを指す。
【０５９２】  中間頂点が左にあるのか右にあるのかは、頂点ｖ［ｉ２］とｖ［ｉ１］により形成されるラインの傾斜ｄｘ２／ｄｙと、頂点ｖ［ｉ２］とｖ［ｉ０］により形成されるラインの傾斜ｄｘ０／ｄｙを比較することにより判定される。（ｄｘ２／ｄｙ＞ｄｘ０／ｄｙ）であれば、中間頂点は長辺の右にあり、そうでなければ長辺の左にある。計算された値はここでプリミティブ記述子に割り当てられる。ｘ記述子の割当ても同様である。こうして、三角形のプロセッシングに必要な辺傾斜と頂点記述子が入手される。
５．４．１．２傾斜決定
上行ｙオーダーでソートされたインデクスを使って、（ｄｘ／ｄｙ）導関数のセットが計算される。そして、上行ｘオーダーでソートされたインデクスを使って辺に対する（ｄｙ／ｄｘ）導関数が計算される。段階としては、１）タイム・オーダーで傾斜Ｓ０１、Ｓ１２、Ｓ２０を計算し、２）ｙソート傾斜ＳＴＭ、ＳＭＢ、ＳＴＢに対してマップし、３）ＳＬＥＦＴ、ＳＲＩＧＨＴ、ＳＢＯＴＴＯＭに対するマップ傾斜に対し傾斜比較を行う。
【０５９３】  傾斜は頂点に対しタイム・オーダーで計算される。つまり、（Ｘ０，Ｙ０）はセットアップ２１５により受信された最初の頂点、即ち「Ｖ０」を表し、（Ｘ１，Ｙ１）はセットアップ２１５により受信された２番目の頂点、即ち「Ｖ２」を表し、（Ｘ２，Ｙ２）はセットアップ２１５により受信された３番目の頂点、即ち「Ｖ３」を表すということである。
【０５９４】
【数５】
2004272928.tif 000022
パイプライン２００内の他のプロセッシング・ステージにおいては、クリッピング・ユニット（図Ｄ６参照）のインタセプト・ポイントを計算するために傾斜の逆数も必要とされる。この観点より、本発明のある好適な実施例では以下の数式を使って傾斜Ｓ０１、Ｓ１２、Ｓ２０の逆数を求める。
【０５９５】
【数６】
2004272928.tif 000023
図Ｄ７では、三角形傾斜割り当ての例を示している。左傾斜は「左辺」がより早期に定義されている場合で、ｄｙ／ｄｘの傾斜として定義される。右傾斜は、「左辺」がより早期に定義されている場合で、ｄｙ／ｄｘの傾斜として定義される。底傾斜は、ｙソートされた「底辺」がより早期に定義されている場合で、ｄｙ／ｄｘの傾斜として定義される。（ｘソートされた底辺もある。）
５．４．１．３Ｙソートされた左角又は右角を求める
参照されない逆傾斜ＳＮＴＭ（ＶＴとＶＭの間の逆傾斜）、ＳＮＴＢ（ＶＴとＶＢの間の逆傾斜）及びＳＮＭＢ（ＶＭとＶＢの間の逆傾斜）を呼び出す。これら参照されない逆傾斜は、それらがｙソートされた傾斜を表すので重要である。つまり、それらはｙソートされた頂点間の傾斜を識別するということである。
【０５９６】  図Ｄ８には、三角形及びライン・セグメントに関する、本発明のある実施例による傾斜割当ての更に別の例を示している。この詳細な説明を簡素化するため、これより傾斜名前付け規定を説明する。
【０５９７】  例えば、傾斜「ＳｌＳｔｒｔＥｎｄ」では「Ｓｌ」は傾斜「Ｓｔｒｔ」は辺の第１頂点識別子「Ｅｎｄ」は辺の第２頂点識別子を意味する。こうして、ＳｌＹｍａｘＬｅｆｔは、ＶｔｘＹＭａｘとＶｔｘＬｅｆｔＣを結ぶ左辺の傾斜を表している。ｌｅｆｔＣが有効でなければ、ＳｌＹｍａｘＬｅｆｔは長辺の傾斜である。前に付いている文字ｒは傾斜が逆数であることを示している。逆傾斜は（ｘ／ｙ）ではなく（ｙ／ｘ）である。
【０５９８】  従って、本実施例では、傾斜は｛ＳｌＹｍａｘＬｅｆｔ，ＳｌＹｍａｘＲｉｇｈｔ，ＳｌＬｅｆｔＹｍｉｎ，ＳｌＲｉｇｈｔＹｍｉｎ｝として表現され、傾斜の逆数（ｙ／ｘ）は｛ｒＳｌＸｍｉｎＴｏｐ，ｒＳｌＸｍｉｎＢｏｔ，ｒＳｌＴｏｐＸｍａｘ，ｒＳｌＢｏｔＸｍａｘ｝として表現される。
【０５９９】  本発明のある好適な実施例では、セットアップ２１５は三角形のＬｅｆｔＣ又はＲｉｇｈｔＣを求めるために逆傾斜を比較する。例えば、ＹｓｏｒｔＳＮＴＭがＹｓｏｒｔＳＮＴＢよりも大きいかこれに等しければ、三角形は左角即ち「ＬｅｆｔＣ」を有し、以下の割当て、即ち、ａ）ＬｅｆｔＣは真（１）にセットされ、ｂ）ＲｉｇｈｔＣは偽（０）にセットされ、ｃ）ＹｓｏｒｔＳＮＬＳｒｃはＹｓｏｒｔＳＮＴＭＳｒｃ（左傾斜に対するポインタを識別）にセットされ、ｄ）ＹｓｏｒｔＳＮＲＳｒｃはＹｓｏｒｔＳＮＴＢＳｒｃ（右傾斜に対するポインタを識別）にセットされ、ｅ）ＹｓｏｒｔＳＮＢＳｒｃはＹｓｏｒｔＳＮＭＢＳｒｃ（底傾斜に対するポインタを識別）にセットされるということが行なわれる。
【０６００】  しかし、ＹｓｏｒｔＳＮＴＭがＹｓｏｒｔＳＮＴＢよりも小さければ、三角形は右角、即ち「ＲｉｇｈｔＣ」を有するので、以下の割当て、即ち、ａ）ＬｅｆｔＣは偽（０）にセットされ、ｂ）ＲｉｇｈｔＣは真（１）にセットされ、ｃ）ＹｓｏｒｔＳＮＬＳｒｃはＹｓｏｒｔＳＮＴＢＳｒｃ（左傾斜に対するポインタを識別）にセットされ、ｄ）ＹｓｏｒｔＳＮＲＳｒｃはＹｓｏｒｔＳＮＴＭＳｒｃ（右傾斜に対するポインタを識別）にセットされ、ｅ）ＹｓｏｒｔＳＮＢＳｒｃはＹｓｏｒｔＳＮＭＢＳｒｃ（底傾斜に対するポインタを識別）にセットされるということが行なわれる。
５．４．１．４Ｘ軸に関し座標をソートする
クリッピング・ユニット５（図Ｄ６参照）に使用されるアルゴリズムは、ｘ方向に頂点がソートされた順を知る必要があるので、三角形の頂点を「ｙ」に関してソートするための計算は、三角形の頂点に関し「ｘ」に関しても繰り返される必要がある。三角形の頂点を「ｘ」に関してソートするためのプロシジャは、言うまでも無く、頂点が「ｙ」ではなく「ｘ」に関してソートされるということ以外、三角形の頂点を「ｙ」に関してソートするために上で使用されたプロシジャに似ている。しかしながら、使用可能な開示を提供するため、完全を期し、過多の警告を排する目的で、三角形の頂点を「ｘ」に関してソートするための数式を以下のとおり提供する。
【０６０１】  ソートの場合、例えば以下を含めて６通りの比較を行なう。
【０６０２】
【数７】
2004272928.tif 000024
これら比較の結果を使って、頂点のソートされた順序を求める。どのタイム・オーダーの頂点がどのＹソートの頂点に対応するかを識別するためにポインタを使用する。厳密には、ポインタを使って（タイム・オーダーの（Ｖ０、Ｖ１、Ｖ２）からＸソートの（「宛先」頂点ＶＬ、ＶＲ、ＶＭ）への）ソースを識別する。
【０６０３】
【数８】
2004272928.tif 000025
次にセットアップ２１５は各宛先（タイム・オーダー型対Ｘソート型）に対するポインタを識別する。
【０６０４】
【数９】
2004272928.tif 000026
参照されないソートされた頂点ＶＲ＝（ＸＲ，ＹＲ，ＺＲ）、ＶＬ＝（ＸＬ，ＹＬ，ＺＬ）及びＶＭ＝（ＸＭ，ＹＭ，ＺＭ）を呼び出すが、ここにＶＲはＸが最大で、ＶＬはＸが最小である。ＸソートされたデータはＹ又は２に関して利用できる順序づけられた情報を持っていないことに留意されたい。Ｘ、Ｙ、Ｚは座標であり「Ｒ」は「右」で「Ｌ」は「左」で「Ｍ」は「中間」であることも書き添える。コンテキストは重要であり、ｙソートされたＶＭはｘソートされたＶＭとは異なる。
【０６０５】  上記のように計算された傾斜は、どの傾斜がｘソートされたどの辺に対応しているのかを識別できるように、ｘソートされた順序に対応するラベルにマップされる必要がある。これを実現するには、本発明のある顕著な例では（タイム・オーダー型からｘ−ソート型まで）傾斜のソースを識別するためのポインタを求める。一例として、以下の数式を考察するが、
【０６０６】
【数１０】
2004272928.tif 000027
ここに、ＸｓｏｒｔＳＲＭＳｒｃはＶＲとＶＭの間のＳＲＭ傾斜に対するソース（Ｖ０、Ｖ１、及びＶ２）を表し、ＸｓｏｒｔＳＲＬＳｒｃはＳＲＬ傾斜に対するソースを表し、ＸｓｏｒｔＳＭＬＳｒｃはＳＭＬ傾斜に対するソースを表す。
【０６０７】  参照されない傾斜、ＸｓｏｒｔＳＲＭ（ＶＲとＶＭの間の傾斜）と、ＸｓｏｒｔＳＲＬ（ＶＲとＶＬの間の傾斜）と、ＸｓｏｒｔＳＭＬ（ＶＭとＶＬの間の傾斜）を呼び出す。
５．４．１．５Ｘソートされた頂部角又は底部角を求めて傾斜を識別する
セットアップ２１５は、傾斜を比較して、ｘソートされた三角形の底部角（ＢｏｔＣ又はＢｏｔｔｏｍＣｏｒｎｅｒ）又は頂部角（ＴｏｐＣ又はＴｏｐＣｏｒｎｅｒ）を求める。これを説明するため以下の例を考察するが、ＳＲＭはｘソートされたＶＲとＶＭの間の傾斜を表し、ＳＲＬはｘソートされたＶＲとＶＬの間の傾斜を表すものとする。ＳＲＭがＳＲＬより大きいか又はこれに等しければ、その三角形はＢｏｔＣを有し、以下の割当て即ち、ａ）ＢｏｔＣは真（１）にセットされ、ｂ）ＴｏｐＣは偽（０）にセットされ、ｃ）ＸｓｏｒｔＳＢＳｒｃはＸｓｏｒｔＳＲＭＳｒｃ（ｘソートされた底部傾斜を識別）にセットされ、ｄ）ＸｓｏｒｔＳＴＳｒｃはＸｓｏｒｔＳＲＬＳｒｃ（ｘソートされた頂部傾斜を識別）にセットされ、ｅ）ＸｓｏｒｔＳＬＳｒｃはＸｓｏｒｔＳＭＬＳｒｃ（ｘソートされた左傾斜を識別）にセットされる、ということが行なわれる。
【０６０８】  しかしながら、ＳＲＭがＳＲＬよりも小さければ、三角形は頂角（ＴｏｐＣ又はＴｏｐＣｏｒｎｅｒ）を有し、以下の割当て、即ち、ａ）ＢｏｔＣは偽にセットされ、ｂ）ＴｏｐＣは真にセットされ、ｃ）ＸｓｏｒｔＳＢＳｒｃはＸｓｏｒｔＳＲＬＳｒｃ（ｘソートされた底部傾斜を識別）にセットされ、ｄ）ＸｓｏｒｔＳＴＳｒｃはＸｓｏｒｔＳＲＭＳｒｃ（ｘソートされた頂部傾斜を識別）にセットされ、ｅ）ＸｓｏｒｔＳＬＳｒｃはＸｓｏｒｔＳＭＬＳｒｃ（ｘソートされた左傾斜を識別）にセットされる、ということが行なわれる。
【０６０９】  Ｖ０、Ｖ１、Ｖ２はタイム・オーダーで順序付けられた頂点である。Ｓ０１、Ｓ１２、Ｓ２０はタイム・オーダーで順序付けられた傾斜である。ｘソートされたＶＲ、ＶＬ、ＶＭは、ｘソートされた右、左、中間頂点である。ｘソートされたＳＲＬ、ＳＲＭ、ＳＬＭは、ｘソートされた頂点間の傾斜である。ｘソートされたＳＴ、ＳＢ、ＳＬは、ｘソートされた頂部、底部、左頂点である。「ソース」は、これらがデータに対するポインタであることを強調しているだけである。ＢｏｔＣは、真であれば底部角があるということを意味しており、ＴｏｐＣ及び頂角についても同じことが言える。
５．４．２ライン・セグメント・プロセッシング
ライン・プロセッシング・ユニット２（図Ｄ６参照）の目的は、１）ライン・セグメントの方位（ライン・セグメントの方位には、以下の事柄、即ち、ａ）ラインがＸメジャ又はＹメジャの何れであるのかの判定、ｂ）ライン・セグメントが右を指しているか左を指しているか（Ｘｃｎｔ）の判定、ｃ）ライン・セグメントが上を指しているか下を指しているか（Ｙｃｎｔ）の判定が含まれる）を求めることであり、これはＸｃｎｔとＹｃｎｔが、ステイップル・ライン・セグメントのプロセッシングにとって必要とされる、ラインの方向を表すので有益であり、更にもう１つの目的は、２）ラインの傾斜と逆傾斜を計算することであり、これは、カル４１０（図Ｄ４参照）にやはり送られる、指し示されたタイル交点を計算するために傾斜が使用されるので、有益であると言える。本発明のこのサブ・ユニットが、ライン・セグメントの方位を２−Ｄウィンドウの対応するタイルに関してどのように決めるかについてこれより説明する。
５．４．２．１ライン方位
図Ｄ９には、本発明のある実施例によるライン方位の形態の例を示している。これより、ライン・セグメントが右を指しているのか左を指しているのかを判定するために、セットアップ２１５が使用する代表的プロシジャを論じる。
【０６１０】  ＤＸ０１＝Ｘ１−Ｘ０である。
【０６１１】  ＤＸ０１がゼロより大きければ、セットアップ２１５はＸＣｎｔを「アップ」にセットするが、これはライン・セグメントが右を指していることを意味する。本発明のある好適な実施例では、アップは「１」で表現され、ダウンは「０」で表現される。そうではなくて、ＤＸ０１がゼロより小さいかこれに等しい場合、セットアップ２１５はＸＣｎｔをダウンにセットするが、これはつまりは、ライン・セグメントが下を指しているということである。ＤＸ０１はＸ１とＸ０の差である。
【０６１２】  ラインが上向きか下向きかを判定する。
【０６１３】        ＤＹ０１＝Ｙ１−Ｙ０
ＩＦＤＹ０１＞１ならば、
ＴｈｅｎＹｃｎｔ＝ｕｐ、即ちラインは上向きであり、
ＥｌｓｅＹｃｎｔ＝ｄｎ、即ちラインは下向きである。
／／大＝Ｘ又はＹ（ラインはＸメジャかＹメジャか？）
Ｉｆ｜ＤＸ０１｜＞｜ＤＹ０１｜
ＴｈｅｎＭａｊｏｒ＝Ｘ
ＥｌｓｅＭａｊｏｒ＝Ｙ
５．４．２．２ライン傾斜
ライン傾斜の計算は、クリッピング・ユニット５におけるタイル辺に対する交点の計算時に傾斜と逆傾斜の両方が使用されるので、有益である。以下の数式はライン傾斜を求めるためにセットアップ２１５が使用する。
【０６１４】
【数１１】
2004272928.tif 000028
図Ｄ１０は、ライン・セグメント傾斜の態様を示している。セットアップ２１５は、傾斜（Ｓ０１）の符号に従って、そしてラインがエイリアスドであるか否かに基づいて、ラインの傾斜にラベル付けする。非アンチエイリアスド・ラインについては、セットアップ２１５はラインの端の傾斜をゼロにセットする。（無限のｄｘ／ｄｙについては後に詳しく論じる。）
Ｓ０１が０より大きいか又はこれに等しければ、ａ）ラインの左辺の傾斜（ＳＬ）はＳ０１にセットされ、ｂ）左辺の逆傾斜（ＳＮＬ）はＳＮ０１にセットされ、ｃ）ラインがアンチエイリアスドであれば、セットアップ２１５は、ラインの右辺の傾斜（ＳＲ）を−ＳＮ０１にセットし、ラインの右辺の逆傾斜（ＳＮＲ）を−Ｓ０１にセットし、ｄ）ラインがアンチエイリアスドでなければ、ライン右辺の傾斜と右辺の逆傾斜はゼロ（無限ｄｘ／ｄｙ）にセットされ、ｅ）ＬｅｆｔＣｏｒｎｅｒ又はＬｅｆｔＣは真（１）にセットされ、ｆ）ＲｉｇｈｔＣｏｒｎｅｒ又はＲｉｇｈｔＣは真にセットされる。
【０６１５】  しかしながら、Ｓ０１が０より小さければ、ａ）ラインの右辺の傾斜（ＳＲ）はＳ０１にセットされ、ｂ）右辺の逆傾斜（ＳＮＲ）はＳＮ０１にセットされ、ｃ）ラインがアンチエイリアスドであれば、セットアップ２１５は、ラインの左辺の傾斜（ＳＬ）を−ＳＮ０１にセットし、ラインの左辺の逆傾斜（ＳＮＬ）を−Ｓ０１にセットし、ｄ）ラインがアンチエイリアスドでなければ、ライン左辺の傾斜とライン左辺の逆傾斜はゼロにセットされ、ｅ）ＬｅｆｔＣｏｒｎｅｒ又はＬｅｆｔＣは真（１）にセットされ、ｆ）ＲｉｇｈｔＣｏｒｎｅｒ又はＲｉｇｈｔＣは真にセットされる。
【０６１６】  データの共通性、即ち、ａ）ＳＲ／ＳＮＲ、ｂ）ＳＬ／ＳＮＲ、ｃ）ＳＢ／ＳＮＢ（三角形の場合のみ）、ｄ）ＬｅｆｔＣ／ＲｉｇｈｔＣ、及びｅ）その他に着目されたい。
【０６１７】  エンドオン・ライン、即ちエンドオンに見え、従って可視ではないライン、を捨てるために、セットアップ２１５は、（ｙ１−ｙ０＝０）及び（Ｘ１−Ｘ０＝０）であるか否かを判定し、そうであればそのラインは捨てられる。
５．４．２．３ライン・モード三角形
三角形をライン・モードで描く場合は、セットアップ２１５ユニットは、３つの三角形頂点に対するウィンドウ座標（ｘ，ｙ，ｚ）に加えてエッジ・フラグを受信する。表６には、エッジ・フラグを有するエッジ・フラグ（ＬｉｎｅＦｌａｇｓ）５を示している。これらのエッジ・フラグ５は、セットアップ２１５に、どの辺が描かれるべきかを教える。セットアップ２１５は、多角形オフセットの計算に使用される「因数」（表６の因数（ＡｐｐｌｙＯｆｆｓｅｔＦａｃｔｏｒ）４参照）も受信する。この因数は因数「ｆ」であり、プリミティブのデプス値をオフセットするのに使用される。全デプス値は、ｍａｘ［？Ｚｘ？，？Ｚｙ？］プラス因数に等しいオフセットと同じ量だけオフセットされることになるのは効率がよい。因数は、ユーザーにより与えられる。Ｚｘはｄｘ／ｄｚに等しい。Ｚｙはｄｙ／ｄｚに等しい。描かれることになる辺は、先ず多角形オフセットによりオフセットされ、次に幅ｗのリボン（ラインの属性）として描かれる。これらのラインは、スティップリングが使用可能であればスティップルされてもよい。
【０６１８】  各ライン多角形に対し、セットアップ２１５は、１）ｘ及びｙに沿って２の偏導関数を計算し（これらｚ勾配は三角形に当てはまるもので、三角形の場合はｚオフセットを計算するために必要である点に留意されたい。これら勾配は、ｉｆ＞ｆａｃｔｏｒ＝がゼロ、であれば計算される必要はない。）、２）多角形オフセット計算が使用可能であれば多角形オフセットを計算し、そのオフセットを３つの頂点それぞれの２値に加え、３）辺を順にトラバースする。辺が視認できる場合には、幅及びスティップルのようなラインの属性を使って辺を描き（セットアップ２１５は一度に三角形の１辺を処理する）、４）アンチエイリアスド又はエイリアスド、スティップル、幅等のようなラインの属性に基づいてラインを描き、５）それが三角形のどの辺を表現しているかによって、適当なプリミティブ・コードを長方形に割当て、それをＣＵＬに送る。この「プリミティブ・コード」はプリミティブ・タイプのエンコーディングであって、例えば０１は三角形、１０はライン、１１はポイントに匹敵する。
５．４．２．４スティップルド・ライン・プロセッシング
ライン・セグメントが与えられると、スティップルド・ライン・プロセッシングは「スティップル情報」とライン方位情報（５．２．５．２．１節のライン方位参照）を使用して、セットアップ２１５によって、現在のタイルの境界外にあるクワッドの不要なプロセッシングを減じる。厳密には、スティップル・プリプロセッシングはスティップルされたラインを多数の独立したライン・セグメントに分解する。スティップル情報には、例えば、スティップル・パターン（ＬｉｎｅＳｔｉｐｐｌｅＰａｔｔｅｒｎ）６（表６参照）、スティップル反復因数（ＬｉｎｅＳｔｉｐｐｌｅＲｅｐｅａｔＦａｃｔｏｒ）ｒ８、スティップル開始ビット（ＳｔａｒｔＬｉｎｅＳｔｉｐｐｌｅＢｉｔ１及びＳｔａｒｔＬｉｎｅＳｔｉｐｐｌｅＢｉｔ１）例えばスティップル開始ビット１２、及びスティップル反復開始（例えば、ＳｔａｒｔＳｔｉｐｐｌｅＲｅｐｅａｔＦａｃｔｏｒ０）２３（ｓｔｐｌＲｅｐｅａｔＳｔａｒｔ）が含まれる。
【０６１９】  パイプライン２００のある好適な実施例では、ジオメトリ３１５は、スティップル開始ビット１２の計算に責任を負っており、スティップル反復開始２３は各ライン・セグメントの開始時にオフセットする。ここでは、四辺形頂点生成ユニット４（図Ｄ６参照）は、半値幅変位を提供するものと仮定する。
【０６２０】  スティップルド・ライン・プリプロセッシングは、スティップルされたライン・セグメントを多数の独立したライン・セグメントに分解することになるが、ライン長はスティップル・パターンの１ビットのシーケンスに対応しており、第１ビットについては、ｓｔｐｌｒＳｔａｒｔビットで始まり、更に反復因数はＳｔｐｌＲｅｐｅａｔＳｔａｒｔで始まる。これを説明するため、以下の例を考察しよう。ｓｔｐｌＳｔａｒｔが１４であり、ｓｔｐｌＲｅｐｅａｔが５であり、ｓｔｐｌＲｅｐｅａｔＳｔａｒｔが４であれば、スティップル・パターンの１４番目のビットを一旦ペイントしてから、始めてスティップル・パターンの最後のビットである１５番目に移ることになる。ビット１４と１５の両方がセットされているが、０番目のビットがセットされていない場合は、クワッド・ライン・セグメントは６の長さを有することになる。
【０６２１】  本発明のある好適な実施例では、デプス勾配、ライン傾斜、デプス・オフセット、ｘ方向幅（ｘｈｗ）、ｙ方向幅（ｙｈｗ）は、ライン・セグメントであれば、全スティップル・クワッドに共通であるので、１回生成されるだけでよい。
【０６２２】  ライン・セグメントは、後に詳しく説明する（それぞれ５．２．５．Ｘ及び５．２．５．Ｘ節を参照）三角関数と四辺形生成ユニットにより、四辺形、即ち「クワッド」に変換される。アンチエイリアスド・ラインについては、クワッドは長方形である。非アンチエイリアスド・ラインについては、クワッドは平行四辺形である。
５．４．３ポイント・プロセッシング
図Ｄ１２には、求められるべき種々のデータを例示するために、タイル１５の部分に交差しているクリップされていない円５の例を示している。
【０６２３】  ＣＹＴ２０は、タイル座標において、タイル１５の頂辺によりクリップされている円５の一番上の点を表す。ＣＹＢ３０は、タイル座標において、タイル１５の底辺によりクリップされている円１０の一番下の点を表す。Ｙｏｆｆｓｅｔ２５はＣＹＴ２０と、ＣＹＢ３０、即ちクリップされていない円１０の底部の間の距離を表す。Ｘ０  ３５は、ウィンドウ座標における円１０の中心５の「ｘ」座標を表す。この情報は、どのサンプル・ポイントがポイントにより覆われるかを判定するために必要であり、カル４１０により使われる。
ポイントに関する必要情報は以下の計算で入手される。
【０６２４】
【数１２】
2004272928.tif 000029
５．４．４三角関数ユニット
先に論じたように、セットアップ２１５は、ライン三角形及びポイントを含め全てのラインを四辺形に変換する。これを実現するため、三角関数ユニットはｘ方向半値幅とｙ方向半値幅を各ライン及びポイント毎に計算する。（フィルド三角形用の四辺形生成は、三角形プロセッシングに関して上に詳細を述べている。）ポイント四辺形中のラインに対する頂点を生成するためのそのプロシジャについては、四辺形生成ユニット４（図Ｄ６参照）に関連して後に詳しく説明する。
【０６２５】  三角関数ユニットがプリミティブ半値幅を確定できるにはその前に、三角関数ユニットは先ず三角関数ｔａｎθ、ｃｏｓθ、ｓｉｎθを計算せねばならない。本発明のある好適な実施例では、セットアップ２１５は、三角関数ｃｏｓθとｓｉｎθを、先に詳しく説明したライン・プリプロセッシング機能ユニットにおいて計算されたラインの傾斜を使って求める。例えば、
【０６２６】
【数１３】
2004272928.tif 000030
本発明の更に別の実施例では、上記三角関数は、ルックアップ表と逐次代入法を使って、ｒｓｑｒｔ及び他の複雑な算術関数同様に計算される。Ｒｓｑｒｔとは逆平方根のことである。
【０６２７】  図Ｄ１３には、ラインの方位と結果としてのｃｏｓθ及びｓｉｎθの符号の関係を示している。図示するように、結果としてのｃｏｓθ及びｓｉｎθの符号はラインの方位により異なる。
【０６２８】  これより、セットアップ２１５が、どのようにして、上で求められたｃｏｓθ及びｓｉｎθを使ってプリミティブ「ｘ」方向半値幅（ＨＷＸ）とプリミティブ「ｙ」方向半値幅（ＨＷＹ）を計算するのかを説明する。各ラインに関し、ラインの半値幅はラインの中心から四辺形の辺となるべきものまでのｘ及びｙ方向のオフセット距離である。各ポイントに関し、半値幅はポイント幅の２分の１に等しい。これらの半値幅は大きさであり、つまり、ｘ方向半値幅及びｙ方向半値幅は常に正の値であるということを意味する。
【０６２９】  説明のためＤ１４に、アンチエイリアスド・ライン１４０５、非エイリアスドｘメジャ・ライン１４１０、非エイリアスドｙメジャ・ライン１４１５の３本のラインと、それら各々の関係付けられた四辺形１４２０、１４２５、１４３０を示している。各四辺形１４２０、１４２５、１４３０は、例えばＷ１４０８、Ｗ１４１３、Ｗ１４１８のような幅（Ｗ）を有する。本発明の好適な実施例では、この幅「Ｗ」はプリミティブ・パケット６０００（表６参照）に包まれている。（更に、図Ｄ１５には、ｘメジャ及びｘメジャ・エイリアスド・ラインをあるアンチエイリアスド・ラインに対比した例を示している。）
アンチエイリアスド・ラインの半値幅を求めるために、セットアップ２１５は以下の数式を使う。
【０６３０】
【数１４】
2004272928.tif 000031
ｘメジャ、非アンチエイリアスド・ラインの場合の半値幅を求めるため、セットアップ２１５は以下の数式を用いる。
【０６３１】
【数１５】
2004272928.tif 000032
ｙメジャ、非アンチエイリアスド・ラインの場合の半値幅を求めるため、セットアップ２１５は以下の数式を用いる。
【０６３２】
【数１６】
2004272928.tif 000033
ポイントの場合の半値幅を求めるため、セットアップ２１５は以下の数式を用いる。
【０６３３】
【数１７】
2004272928.tif 000034
５．４．５四辺形生成ユニット
四辺形生成機能ユニット４（図Ｄ６参照）は、１）ライン又はポイント周りにセンタリングされた四辺形を生成し、２）当該四辺形に対して、四辺形の頂部頂点、底部頂点、左頂点、右頂点に関して頂点のセットをソートする。四辺形に関して、四辺形生成機能ユニット４は、ａ）アンチエイリアスド・ラインを長方形に変換し、ｂ）非アンチエイリアスド・ラインを平行四辺形に変換し、ｃ）エイリアスド・ポイントを、そのポイント周りにセンタリングされた正方形に変換する。（フィルド三角形の場合は、頂点は素通りして、次の機能ユニット、例えばクリッピング機能ユニット５（図Ｄ６参照）へと送られる。）これより、四辺形生成機能ユニット４がプリミティブに合わせた四辺形を生成するために採るプロシジャの実施例について説明する。
【０６３４】  ライン・セグメントに関しては、四辺形の頂点は、ａ）ライン・セグメントの元の頂点（プリミティブの元の頂点はセットアップ２１５にプリミティブ・パケット６０００で送られ、表６、ＷｉｎｄｏｗＸ０  １９、ＷｉｎｄｏｗＹ０  ２０、ＷｉｎｄｏｗＺ０  ２１、ＷｉｎｄｏｗＸ１  １４、ＷｉｎｄｏｗＹ１  １５、ＷｉｎｄｏｗＺ１  １６、ＷｉｎｄｏｗＸ２  ９、ＷｉｎｄｏｗＹ２  １０及びＷｉｎｄｏｗＺ２  １１を参照）、ｂ）ライン・セグメントの方位（ライン方位は上記５．２．５．２．１節で求められ、詳細に説明されている）及びｃ）ライン・セグメントのｘ方向半値幅とｙ方向半値幅（半値幅は上記５．２．５．４節で計算され、詳しく説明されている）を考慮することにより生成される。厳密には、四辺形頂点は、ライン・セグメントの半値幅をライン・セグメントの元の頂点に対して加減することにより生成される。
【０６３５】  ライン・セグメントが右（Ｘｃｎｔ＞０）を指しており、上（Ｙｃｎｔ＞０）を指しているのであれば、セットアップ２１５は、以下の数式のセットを実行して、そのライン・セグメント上にセンタリングされている四辺形を定義する頂点のセットを求める。
【０６３６】
【数１８】
2004272928.tif 000035
ここに、ＱＶ０、ＶＱＶ１、ＶＱＶ１、ＱＶ２、及びＱＶ３は四辺形の頂点である。四辺形の頂点は、まだソートされていない状態であるが、数式は、ＹｃｎｔとＸｃｎｔの値に基づき容易にソートすることができるように選定された。
【０６３７】  これを説明するため図Ｄ１６には、本発明のある実施例による、四辺形への予めソートされた頂点割当ての態様を示している。厳密には、四辺形１６０５は、右及び上を指すライン・セグメントを描いており、この四辺形には頂点ＱＶ０１６０６、ＱＶ１  １６０７、ＱＶ２  １６０８、ＱＶ３  １６０９がある。
【０６３８】  ライン・セグメントが左（Ｘｃｎｔ＜０）を指し、且つ上を指しているのであれば、セットアップ２１５は以下の数式のセットを実行して、そのライン・セグメント上にセンタリングされている四辺形を定義する頂点のセットを求める。
【０６３９】
【数１９】
2004272928.tif 000036
これを例証するには、左及び上を指すライン・セグメントを描いており、頂点ＱＶ０  １６１１、ＱＶ１  １６１２、ＱＶ２  １６１３、ＱＶ３  １６１４を有する四辺形１６１０を考察されたい。
【０６４０】  ライン・セグメントが左（Ｘｃｎｔ＜０）を指し、且つ下（Ｙｃｎｔ＜０）を指しているのであれば、セットアップ２１５は以下の数式のセットを実行して、そのライン・セグメント上にセンタリングされている四辺形を定義する頂点のセットを求める。
【０６４１】
【数２０】
2004272928.tif 000037
これを例証するには、左及び下を指すライン・セグメントを描いており、頂点ＱＶ０  １６１６、ＱＶ１  １６１７、ＱＶ２  １６１８、ＱＶ３  １６１９を有する四辺形１６１５を考察されたい。
【０６４２】  ライン・セグメントが右を指し、且つ下を指しているのであれば、セットアップ２１５は以下の数式のセットを実行して、そのライン・セグメント上にセンタリングされている四辺形を定義する頂点のセットを求める。
【０６４３】
【数２１】
2004272928.tif 000038
これを例証するには、右及び下を指すライン・セグメントを描いており、頂点ＱＶ０  １６２１、ＱＶ１  １６２２、ＱＶ２  １６２３、ＱＶ３  １６２４を有する四辺形１６２０を考察されたい。
【０６４４】  本発明のある好適な実施例では、垂直ライン・セグメントは、ライン・セグメントが左且つ上を指しているかのごとく扱われる。水平ライン・セグメントは、それが右且つ上を指しているかのごとく扱われる。ポイントは特別なケースとして取り扱われ、つまり、ポイントは垂直ライン・セグメントであるかのごとく扱われる。
【０６４５】  各四辺形に対するこれらの頂点、ＱＸ０、ＱＸ１、ＱＸ２、ＱＸ３、ＱＹ０、ＱＹ１、ＱＹ２、ＱＹ３は、ここで、四辺形生成機能ユニット４により、頂部頂点（ＱＸＴ，ＱＹＴ，ＱＺＴ）、底部頂点（ＱＸＢ，ＱＹＢ，ＱＺＢ）、左頂点（ＱＸＬ，ＱＹＬ，ＱＺＬ）、右頂点（ＱＸＲ，ＱＹＲ，ＱＺＲ）に割当て直され、四辺形に適正な方位を与え、それらの頂点をソートし、最上、最下、最左、最右の頂点を識別できるようにするが、ここに各頂点の２座標はプリミティブの元のＺ座標である。
【０６４６】  この目的を達成するために、四辺形機能ユニットｘｘｘは、以下の論理を使用する。ライン・セグメントが上を指している場合は、頂部及び底部の頂点は以下の数式、即ち、ａ）頂点（ＱＸＴ，ＱＹＴ，ＱＺＴ）はそれぞれ（ＱＸ３，ＱＹ３，Ｚ１）にセットされ、ｂ）頂点（ＱＸＢ，ＱＹＢ，ＱＺＢ）はそれぞれ（ＱＸ０，ＱＹ０，Ｚ０）にセットされる、に従って割当てられる。ライン・セグメントが下を指している場合は、頂部及び底部の頂点は以下の数式、即ち、ａ）頂点（ＱＸＴ，ＱＹＴ，ＱＺＴ）はそれぞれ（ＱＸ０，ＱＹ０，Ｚ０）にセットされ、ｂ）頂点（ＱＸＢ，ＱＹＢ，ＱＺＢ）はそれぞれ（ＱＸ３，ＱＹ３，Ｚ１）にセットされる、により割当てられる。
【０６４７】  ライン・セグメントが右を指している場合、左及び右の頂点は以下の数式、即ち、ａ）頂点（ＱＸＬ，ＱＹＬ，ＱＺＬ）はそれぞれ（ＱＸ１，ＱＹ１，Ｚ０）にセットされ、ｂ）頂点（ＱＸＲ，ＱＹＲ，ＱＺＲ）はそれぞれ（ＱＸ２，ＱＹ２，Ｚ１）にセットされる、により割当てられる。最後に、ライン・セグメントが左を指している場合は、左及び右の頂点は以下の数式、即ち、ａ）頂点（ＱＸＬ，ＱＹＬ，ＱＺＬ）はそれぞれ（ＱＸ２，ＱＹ２，Ｚ１）にセットされ、ｂ）頂点（ＱＸＲ，ＱＹＲ，ＱＺＲ）はそれぞれ（ＱＸ１，ＱＹ１，Ｚ０）にセットされる、により割当てられる。
５．４．６クリッピング・ユニット
本発明の使途に限り、多角形をタイルにクリップするということは、多角形とタイル間の交差する区域を発見することであると定義づける。クリップ・ポイントはこの交差区域の頂点である。
【０６４８】  ある特定のタイルに交わるあるプリミティブの部分に外接するタイトな境界画定ボックス見つけ、それに引き続きプリミティブの最小デプス値（Ｚｍｉｎ）の確定を容易にするために、クリッピング・ユニット５（図Ｄ６参照）は、タイルの各辺毎に、１）タイル（各タイルは４辺を有する）からあるタイル辺を選択して、四辺形の辺のどれかが、或いは三角形の３辺のどれかがタイル辺に交わっているのかを判定し、ｂ）選択されたタイル辺に関してクリップ・コード（詳細は後に説明）をチェックし、ｃ）クワッドの辺又は三角形の辺と選択されたタイル辺との２つの交差点（もしあれば）を計算し、ｄ）計算された交点をタイル境界と比較して有効性を判定し、妥当であればクリップ・ポイントを更新する。
【０６４９】  「現在のタイル」とは、セットアップ２１５により、カル４１０のために現在セットアップ中であるタイルのことである。先に詳しく論じたように、パイプライン２００の先行ステージ、例えばソート３２０は、プリミティブによりタッチされている領域、若しくはウィンドウのタイル（ウィンドウは多数のタイルに分割されている）に関してフレーム内の各プリミティブをソートする。これらのプリミティブはタイル毎順にセットアップ２１５に送られた。クリッピング・ユニット５に関して、セットアップ２１５は、各辺が最終的には選択されるのである限り、任意のやり方で辺を選択することができるものと理解されたい。例えば、ある実施例では、クリッピング・ユニット５は先ずタイルの頂辺を選択し、次にタイルの右辺を選択し、次にタイルの底辺を選択し、最後にタイルの左辺を選択することができる。クリッピング・ユニット５の更に別の実施例では、タイルの辺は別の順で選択することもできる。
【０６５０】  ソート３２０（図Ｄ３参照）は、セットアップ２１５に、現在のタイルの左タイル辺に対するｘ座標と下右タイル辺に対するｙ座標を、プリミティブ・パケット６０００（図Ｄ６参照）を介して提供する。これらの値はタイルｘ及びタイルｙと各々にラベル付けされる。現在のタイルの各辺に対する座標位置を識別するために、クリッピング・ユニット５はタイルの左辺をタイルｘに等しくセットするが、これは、左タイル辺のｘ座標はタイルｘ＋０に等しいことを意味する。現在のタイルの右辺は、タイル左辺、プラス、タイルの幅に等しくセットされる。現在のタイルの底辺はタイルｙに等しくセットされるが、これはこのｙ座標がタイルｙ＋０に等しいということを意味する。最後に、タイルの頂辺は、タイル底辺、プラス、ピクセル内のタイルの高さに等しくセットされる。
【０６５１】  本発明のある好適な実施例では、タイルの幅及び高さは１６ピクセルである。しかしながら、本発明の別の実施例では、タイルのディメンジョンは都合のよい何れのサイズでも構わない。
５．４．６．１クリップ・コード
クリップ・コードは（もし、あれば）多角形のどの辺が、現在のタイルにタッチしているか判定する。（パイプライン２００の先行ステージは、各プリミティブそれぞれがタッチしている２−Ｄウィンドウのタイルに関して各プリミティブをソートしている。）本発明のある実施例では、クリップ・コードはブール値であり「０」は偽を「１」は真を表す。偽のクリップ・コード値は、プリミティブが、その特定のクリップ・コードが表現している現在のタイルの辺に関してクリップされる必要が無いことを示している。一方、真の値は、プリミティブが、その特定のクリップ・コードが表現している現在のタイルの辺に関してクリップされる必要が正にあることを示している。
【０６５２】  本発明のある実施例が、現在のタイルに関してプリミティブに対しどのようにクリップ・コードを求めるかを説明するため、クリップ・コード確定のためのプロシジャを示している以下のプロシジャを考察する。先に指摘したように、使用された擬似コードは、本質的には、汎用コンピュータ言語協定を使用しているコンピュータ言語である。ここに採用された擬似コードは、ここでの説明で使うためだけに単独に発明されたものであるが、当技術に長けたコンピュータ・プログラマであるなら誰しもが容易に理解できるように設計されている。
【０６５３】  本発明のある実施例では、クリップ・コードはプリミティブ頂点の各々につき以下のように入手される。Ｃ［ｉ］＝（（ｖ［ｉ］．ｙ＞ｔｉｌｅ＿ｙｍａｘ）＜＜３）‖（（ｖ［ｉ］．ｘ＜ｔｉｌｅ＿ｘｍｉｎ）＜＜２）‖（（ｖ［ｉ］．ｙ＜ｔｉｌｅ＿ｙｍｉｎ）＜＜１）‖（（ｖ［ｉ］．ｘ＞ｔｉｌｅ＿ｘｍａｘ））、ここに、プリミティブの各頂点に対して、ａ）Ｃ［ｉ］はクリップ・コードを表し、ｂ）ｖ［ｉ］．ｙはｙ頂点を表し、ｃ）ｔｉｌｅ＿ｙｍａｘは現在のタイルの最大ｙ座標を表し、ｄ）ｖ［ｉ］．ｘはプリミティブのｘ頂点を表し、ｅ）ｔｉｌｅ＿ｘｍｉｎは現在のタイルの最小ｘ座標を表し、ｆ）ｔｉｌｅ＿ｙｍｉｎは現在のタイルの最小ｙ座標を表し、ｇ）ｔｉｌｅ＿ｘｍａｘは現在のタイルの最大ｘ座標を表す。このやり方では、クリップ・コードに対応するブール値が生成される。
【０６５４】  本発明の更に別の実施例では、クリップ・コードは以下の数式のセットを使って入手され、１）クワッドの場合は以下のマッピングを使用し、ここに「Ｑ」は四辺形各座標を表し、ＴｉｌｅＲｈｔ、ＴｉｌｅＬｆｔ、ＴｉｌｅＴｏｐ、ＴｉｌｅＢｏｔは、それぞれにタイル右辺のｘ座標、タイル左辺のｘ座標、タイル頂辺のｙ座標、及びタイル底辺のｙ座標を表す。
【０６５５】
【数２２】
2004272928.tif 000039
（三角形に対するＣｌｐＦｌａｇ［３］は配慮しない。）表明されたＣｌｐＦｌａｇＬ［１］は、頂点１がタイルの左辺によりクリップされていることを意味する（頂点はクワッド生成ユニット４により既にソートされている。図Ｄ６参照）。表明されたＣｌｐＦｌａｇＲ［２］は、頂点２がタイルの右辺によりクリップされていることを意味する。ここで「クリップされた」とは頂点がタイルの外側にあることを意味する。
５．４．６．２クリッピング・ポイント
プリミティブが現在のタイルの境界と交差していることを決めるためにクリップ・コードを使った後、クリッピング・ユニット５は、考えられる９つのクリッピング・ポイントの値を求めることにより、プリミティブをタイルにクリップする。クリッピング・ポイントは、初期の多角形を現在のタイルの境界によってクリッピングすること（交差の区域を見つけだすこと）により形成される新しい多角形の頂点である。多角形がタイルの辺と交わる可能性のある場所が８箇所はっきりしているので、９個のクリッピング・ポイントが考えられる。三角形の場合に限り、ｙソートされたＶｔｘＭｉｄに等しい内部クリッピング・ポイントがある。これら９個の考えられるクリッピング・ポイントのうち、多くてその内の８個は何れの回にも有効であり得る。
【０６５６】  本明細書におけるクリッピング・ポイントの論議を簡潔にするため、以下の頭字語を用いて各クリッピング・ポイントを表す。即ち１）タイル頂辺のクリッピングは左（ＰＴＬ）及び右（ＰＴＲ）クリップ頂点を与え、ｂ）タイル底辺のクリッピングはタイル頂辺と同じに実行される。底辺クリッピングは、下左（ＰＢＬ）及び下右（ＰＢＲ）クリップ頂点を与え、ｃ）ｘ座標に関してソートされたクリッピング頂点は、左高／上（ＰＬＴ）及び左低／下（ＰＬＢ）頂点を与え、ｄ）ｙ座標に関してソートされたクリッピング頂点は、右高／上（ＰＲＴ）及び右低／下（ＰＲＢ）を与え、ｅ）タイルの内側にある頂点は内部クリッピング・ポイント（ＰＩ）に割当てられる。図Ｄ１７には、２つの多角形、即ち別々のタイル１５と２５に交差している長方形１０と三角形１０に対するクリッピング・ポイントを示している。
５．４．６．３クリッピング・ポイントの妥当性検査
クリッピング・ユニット５（図Ｄ６参照）は、ここで、計算されたクリッピング・ポイント各々の妥当性を検査し、各クリッピング・ポイントの座標が現在のタイルの座標空間内にあることを確かめる。例えば、タイル頂辺に交わる点が、両方ともタイルの左になるように配されることもあろう。この場合、交差点は無効とマークされる。
【０６５７】  本発明のある好適な実施例では、各クリップ・ポイントは、ｘ座標とｙ座標及び１ビット有効フラグを有する。フラグを「０」にセットすることは、ｘ座標とｙ座標は有効でないことを示す。辺との交差が、タイル辺の角の片方又は両方ともに（このような角については、上の節で詳しく説明した）交差に含まれているような場合には、新たに生成された交差点が有効となる。
【０６５８】  そのクリッピング・ポイントのどれもが有効でないと判明した場合は、プリミティブは捨てられる。
【０６５９】  本発明のある実施例による、クリッピング・ポイントを求めるためのアルゴリズム用の擬似コードを以下に示す。
【０６６０】    表記法備考：Ｐ＝（Ｘ，Ｙ）、例えば（ＸＴ，ＹＴ）；
ライン（Ｐ１，Ｐ０）はエンドポイントＰ１とＰ０により形成されたラインを意味する。
／／Ｘのクリップ・フラグをソート
【０６６１】
【数２３】
2004272928.tif 000040
ここに、クリップ・フラグ３：０のインデクスは頂点を表す。厳密には、０は下を表し、１は左を表し、２は右を表し、３は上を表す。例えば、ＣｌｉｐＦｌａｇＬ［２］は頂点２が左辺にクリップされるタイム・オーダーを指す。ＸｓｏｒｔＣｌｉｐＦｌａｇＬ［２］は最右の頂点を指す。
【０６６２】
【数２４】
2004272928.tif 000041
／／Ｘソートされたプリミティブを使って＃１クリップをＬｅｆｔＴｉｌｅ辺に送る
／／ＬｅｆｔＢｏｔｔｏｍに関し：クリッピング・フラグ、デリファレンス頂点及び傾斜をチェックする
【０６６３】
【数２５】
2004272928.tif 000042
／／ＬｅｆｔＢｏｔｔｏｍに関し：交差点、即ちクランプを計算し、妥当性をチェックする
【０６６４】
【数２６】
2004272928.tif 000043
／／ＬｅｆｔＴｏｐに関し：クリッピング・フラグ、デリファレンス頂点及び傾斜をチェックする
【０６６５】
【数２７】
2004272928.tif 000044
／／ＬｅｆｔＴｏｐに関し：交差点、即ちクランプを計算し、妥当性をチェックする
【０６６６】
【数２８】
2004272928.tif 000045
／／Ｘソートされたプリミティブを使って＃２クリップをＲｉｇｈｔＴｉｌｅ辺に送る
／／ＲｉｇｈｔＢｏｔに関し：クリッピング・フラグ、デリファレンス頂点及び傾斜をチェックする
【０６６７】
【数２９】
2004272928.tif 000046
／／ＲｉｇｈｔＢｏｔに関し：交差点、即ちクランプを計算し、妥当性をチェックする
【０６６８】
【数３０】
2004272928.tif 000047
／／ＲｉｇｈｔＴｏｐに関し：クリッピング・フラグ、デリファレンス頂点及び傾斜をチェックする
【０６６９】
【数３１】
2004272928.tif 000048
／／ＲｉｇｈｔＴｏｐに関し：交差点、即ちクランプを計算し、妥当性をチェックする
【０６７０】
【数３２】
2004272928.tif 000049
／／Ｙソートされたプリミティブを使って、＃３クリップをＢｏｔｔｏｍＴｉｌｅ辺に送る
／／ＢｏｔｔｏｍＬｅｆｔに関し：クリッピング・フラグ、デリファレンス頂点及び傾斜をチェックする
【０６７１】
【数３３】
2004272928.tif 000050
／／ＢｏｔｔｏｍＬｅｆｔに関し：交差点、即ちクランプを計算し、妥当性をチェックする
【０６７２】
【数３４】
2004272928.tif 000051
／／ＢｏｔＲｉｇｈｔにつき：クリッピング・フラグ、デリファレンス頂点及び傾斜をチェックする
【０６７３】
【数３５】
2004272928.tif 000052
／／ＢｏｔＲｉｇｈｔに関し：交差点、即ちクランプを計算し、妥当性をチェックする
【０６７４】
【数３６】
2004272928.tif 000053
／／Ｙソートされたプリミティブを使って、＃４クリップをＴｏｐＴｉｌｅ辺に送る
／／ＴｏｐＬｅｆｔに関し：クリッピング・フラグ、デリファレンス頂点及び傾斜をチェックする
【０６７５】
【数３７】
2004272928.tif 000054
／／ｔｏｐｌｅｆｔに関し：交差点、即ちクランプを計算し、妥当性をチェックする
【０６７６】
【数３８】
2004272928.tif 000055
／／ＴｏｐＲｉｇｈｔに関し：クリッピング・フラグ、デリファレンス頂点及び傾斜をチェックする
【０６７７】
【数３９】
2004272928.tif 000056
／／ＴｏｐＲｉｇｈｔに関し：交差点、即ちクランプを計算し、妥当性をチェックする
【０６７８】
【数４０】
2004272928.tif 000057
これまでに識別された８個のクリッピング・ポイントは、タイルの辺によりクリップされたポイントと、更にタイルの内側にある極頂点（即ち、最上、最下、最左、及び最右）を識別できる。タイルの内側にあって多角形の極点にはない頂点（即ち、ＶＭと呼ばれる頂点）を識別するにはもう１つクリッピング・ポイントが必要である。
／／内部頂点を識別
【０６７９】
【数４１】
2004272928.tif 000058
ＣＵＬが必要とするジオメトリック・データ
更に、カル・ユニットにより必要とされるジオメトリック・データの幾つかはここで求められる。
カルが必要とするジオメトリック・データは、即ち、
ＣｕｌｌＸＴＬとＣｕｌｌＸＴＲである。これらは、多角形の、タイルの頂辺のラインとのＸインタセプトである。これらは、ＰＴＬとＰＴＲはタイル境界内又は境界上になければならないが、ＣｕｌｌＸＴＬとＣｕｌｌＸＴＲはタイル境界の右又は左にあってもよいという点で、ＰＴＬ及びＰＴＲと違っている。ＹＴがタイルの頂辺より下方に存在しているのであれば、ＣｕｌｌＸＴＬ＝ＣｕｌｌＸＴＲ＝ＸＴである。
ＣｕｌｌＹＴＬＲ：ＣｕｌｌＸＴＬとＣｕｌｌＸＴＲに共用されているＹ座標（ＣｕｌｌＸＬ，ＣｕｌｌＹＬ）：ＰＬに等しい、但しＹＬが頂辺より上方にある場合を除く。その場合は、それは（ＣｕｌｌＸＴＬ，ＣｕｌｌＹＴＬＲ）に等しい。
（ＣｕｌｌＸＲ，ＣｕｌｌＹＲ）：ＰＲに等しい、但しＹＲが頂辺より上方にある場合を除く。その場合は、それは（ＣｕｌｌＸＴＲ，ＣｕｌｌＹＴＬＲ）に等しい。
／／ＣｕｌｌＸＴＬ及びＣｕｌｌＸＴＲ（ウィンドウ範囲にクランプされている）
【０６８０】
【数４２】
2004272928.tif 000059
５．４．６．４ウィンドウの外側の四辺形頂点
ウィンドウの辺でタイル上に幅広ラインがあれば、１つ又はそれ以上の計算された頂点がウィンドウ範囲の外側にある可能性がある。セットアップは、負値用に１ビット、大きさ範囲を増加させるのに１ビットの、合計２ビットの余分の座標範囲を持つことによりこれに対処する。ＣＵＬブロックに送られたデータの範囲と精度（ｘ座標に対し１４，２）は、ウィンドウ範囲の内側のポイントを定義するのに丁度十分である。ＣＵＬブロックがセットアップから入手するデータには、左及び右角のポイントが含まれている。クワッド頂点がウィンドウ範囲の外側になる場合、セットアップは以下の値、即ち、１）ｔＲｉｇｈｔ．ｘがウィンドウ範囲の右であれば、ウィンドウ右辺にクランプする、２）ｔＬｅｆｔ．ｘｔがウィンドウ範囲の左であれば、ウィンドウ左辺にクランプする、３）ｖ［ＶｔｘＲｉｇｈｔＣ］．ｘがウィンドウ範囲の右であれば、頂点ｒＬｏｗ（即ち、右角としてのタイルの右辺上の下クリップ・ポイント）を送る、４）ｖ［ＶｔｘＬｅｆｔＣ］．ｘがウィンドウ範囲の左であれば、頂点ｌＬｏｗ（即ち、左角としてのタイルの左辺上の下クリップ・ポイント）を送る、という値をＣＵＬに送る。これは、図Ｄ１８に図示されているが、そこではウィンドウの外側の四辺形頂点のプロセッシングの例を示している。（図Ｄ１８は、米国仮特許出願番号第６０／０９７，３３６号の図５１と相関がある。）図Ｄ２１は、クリップ・コード頂点割当ての態様を示している。
【０６８１】  三角形は、パイプライン２００の前のステージ、例えばジオメトリ３１０により、有効なウィンドウ範囲にクリップされることに留意されたい。セットアップ２１５は、現在のコンテクストにおいては、幅広ラインに対して生成されたクワッドにのみ関連している。カル４１０（図Ｄ４参照）は、エッジ・ウォーキング中にｘ値が範囲を外れることがあり得るので、ラスタライゼーション中にスパン・エンド・ポイントを計算するときに、オーバーフローとアンダーフローを検出する必要がある。オーバーフロー又はアンダーフローが起きると、ｘ範囲はタイル範囲内にクランプされねばならない。
【０６８２】  我々は、これで現在のタイルに関するプリミティブ交差点（クリッピング・ポイント）を求めたし、クリップ・コード又は有効フラグを求めてきた。これで我々は、境界画定ボックス、最小デプス値（Ｚｍｉｎ）及び基準スタンプの計算へと進むことができるが、これらについてはそれぞれに以下に詳しく説明する。
５．４．７境界画定ボックス
境界画定ボックスは、クリップされた多角形の周りに描くことのできる最小のボックスである。プリミティブ交差の境界画定ボックスは、クリップされた頂点（クリップされた頂点、若しくはクリッピング・ポイントについては先に詳しく説明している）を調べることにより求められる。これらのポイントを使って境界画定ボックスのディメンジョンを求める。
【０６８３】  境界画定ボックスのディメンジョンは、スタンプのＢＸＬ（最左の有効クリップ・ポイント）、ＢＸＲ（最右の有効クリップ・ポイント）、ＢＹＴ（最上の有効クリップ・ポイント）、ＢＹＢ（最下の有効クリップ・ポイント）により識別される。ここで、スタンプとは、我々がそれに対して境界画定ボックスを求めようとしている解である。
【０６８４】  最後に、セットアップ２１５は、最小Ｙ（クリップ多角形の最下のｙ座標）を識別する。この最小Ｙは、カル４１０が、そのエッジ・ウォーキング・アルゴリズムのために必要とする。
【０６８５】  プロシジャを解説するため、本発明のある実施例に従って、これより境界画定ボックスのこのようなディメンジョンを求めるための擬似コードについて説明する。クリップ・ポイントに対する有効フラグは、以下の通り、即ち、ＶａｌｉｄＣｌｉｐＬ（クリップ・ポイントＰＬＴとＰＬＢが有効であることが必要）、ＶａｌｉｄＣｌｉｐＲ、ＶａｌｉｄＣｌｉｐＴ、及びＶａｌｉｄＣｌｉｐＢであり、クリッピング・ユニット５（図Ｄ６参照）に関連して先に説明したクリップ・コードに対応している。「ＰＬＴ」は「ｐｏｉｎｔ  ｌｅｆｔ，ｔｏｐ」を指す。ＰＬＴと（ＣｌｉｐＸＬ，ＣｌｉｐｙＬＴ）は同じである。
【０６８６】
【数４３】
2004272928.tif 000060
／／サブ・ピクセルにより表される…８×８サブ・ピクセル＝１ピクセル、２×２ピクセル＝１スタンプ
ここで、現在のタイルに交わるプリミティブの部分に外接する境界画定ボックスに関するディメンジョンが求まる。これらｘｍｉｎ（ＢＸＬ）、ｘｍａｘ（ＢＸＲ）、ｙｍｉｎ（ＢＹＢ）、ｙｍａｘ（ＢＹＴ）ピクセル座標は、スタンプ座標に変換される必要がある。これは、先ず座標をタイル関連値に変換して、次に上位３ビットのみにつき考察する（即ち１ビットずつ右桁送り）ことにより実現される。これは、ｘｍａｘ（及び／又はｙｍａｘ）がタイルの辺にある場合には当てはまらない。その場合には、ｘｍａｘ（及び／又はｙｍａｘ）をシフト前に１ユニット減らす。
／／境界画定ボックスはスタンプで表される
【０６８７】
【数４４】
2004272928.tif 000061
５．４．８デプス勾配及びデプス・オフセット・ユニット
この機能ユニットの目的は、
デプス勾配Ｚｘ＝ｄｚ／ｄｘ及びＺｙ＝ｄｚ／ｄｙを計算すること、
Ｚｍｉｎ＆Ｚｒｅｆサブユニットに適用されるデプス・オフセットＯを計算すること、
三角形がｘメジャであるかｙメジャであるかを判定すること、
ＺｓｌｏｐｅＭｉｒ（メジャな辺に沿ったｚ勾配）を計算すること、
ＺｓｌｏｐｅＭｎｒ（短軸に沿ったｚ勾配）を求めること、
である。
【０６８８】  三角形の場合は、入力頂点はタイムオーダーに順序付けられた三角形頂点（Ｘ０，Ｙ０，Ｚ０）、（Ｘ１，Ｙ１，Ｚ１）、（Ｘ２，Ｙ２，Ｚ２）である。ラインの場合、入力頂点は、Ｑｕａｄ  Ｇｅｎにより生成されたクワッド頂点（ＱＸＢ，ＱＹＢ，ＺＢ）、（ＱＸＬ，ＱＹＬ，ＺＬ）、（ＱＸＲ，ＱＹＲ，ＺＲ）である。スティップル・ラインの場合、Ｚ部分が（元のラインに対し）一度だけ計算され、セーブされ、各スティップルド・ライン・セグメントに対して再使用される。ライン・モード三角形の場合には、このサブ・ユニットを通る最初のパスを利用してデプス・オフセットが計算され、これがセーブされて後続パスの三角形の各辺に適用される。デプス・オフセットは、フィルド三角形及びライン・モード三角形についてのみ計算され、デプス・オフセット計算が使用可能な場合にのみ計算される。
５．４．８．１デプス勾配
頂点は、デプス勾配を計算するため数式に挿入される前に先ずソートされる。三角形の場合、ソーティング情報は、先に詳しく説明した三角形プリプロセッシング・ユニットで入手される。（情報はポインタＹｓｏｒｔＴｏｐＳｒｃ、ＹｓｏｒｔＭｉｄＳｒｃ、ＹｓｏｒｔＢｏｔＳｒｃに含まれている。）クワッドの場合、頂点は、先に詳しく説明した四辺形生成ユニットにより既にソートされている。備考：頂点のソーティングは、頂点の入力順序付けを変えても結果が変わらないようにするため望ましい。
【０６８９】  これより、頂点をソートするための擬似コードについて説明する。
三角形の場合は、
【０６９０】
【数４５】
2004272928.tif 000062
である。
【０６９１】  上記表記法を説明するため、以下の例を考察するが、ここに、Ｘ’＝ｐｔｒ−＞ｍｕｘ（ｘ２，ｘ１，ｘ０）、つまり、ｐｔｒ＝＝００１であればＸ’＝ｘ０、ｐｔｒ＝＝０１０であればＸ’＝ｘ１、ｐｔｒ＝＝１００であればＸ’＝ｘ２である。
クワッドの場合は、
【０６９２】
【数４６】
2004272928.tif 000063
である。
【０６９３】  偏導関数は多角形に対するデプス勾配を表す。それらは以下の数式により与えられる。
【０６９４】
【数４７】
2004272928.tif 000064
５．４．８．２デプス・オフセット７（図Ｄ６参照）
三角形（ライン・モード三角形とフィルド三角形の両方）についてのデプス・オフセットはオープンＧＬ．により、Ｏ＝Ｍ＊ｆａｃｔｏｒ＋Ｒｅｓ＊ｕｎｉｔｓと定義されており、ここに、
Ｍ＝三角形のｍａｘ（．ＺＸ．，．ＺＹ．）、
Ｆａｃｔｏｒはユーザーにより与えられるパラメータ、
Ｒｅｓは定数であり、
Ｕｎｉｔｓはユーザーにより与えられるパラメータである。
【０６９５】  「Ｒｅｓ＊Ｕｎｉｔｓ」という項は、パイプライン２００の先行ステージ、例えばジオメトリＧｅｏｍｅｔｒｙ３１０により、全Ｚ値に既に加えられている。従ってセットアップ２１５のデプス・オフセット・コンポーネントは、
Ｏ＝Ｍ＊ｆａｃｔｏｒ＋８、Ｏを範囲（−２２４，＋２２４）内にクランプするとなる。
【０６９６】  ユニットを保守するために８を掛ける必要がある。デプス・オフセットは、後でＺｍｉｎとＺｒｅｆについて計算されるときにＺ値に加えられることになる。
ラインモード三角形の場合、デプス・オフセットは一旦計算されると、セーブされ、次の三角形の各辺に適用される。
５．４．８．２．１三角形に対しＸメジャを判定する
以下のユニット（ＺｒｅｆとＺｍｉｎサブ・ユニット）において、Ｚ値は「エッジ・ウォーキング」アルゴリズムを使って計算される。このアルゴリズムは三角形の方位に関連する情報を必要とするが、ここで求められる。
【０６９７】
【数４８】
2004272928.tif 000065
三角形の場合は、
Ｘｍａｊｏｒ＝．ＤｅｌｔａＸＲＬ．＞＝．ＤｅｌｔａＹＴＢ．
である。
【０６９８】  クワッドの場合は、
Ｘｍａｊｏｒ＝ＴＬＰサブ・ユニットでラインに対し求められたＸｍａｊｏｒの値
である。
【０６９９】  ｘメジャのラインはオープンＧＬ？仕様書に定義されている。セットアップ２１５で、ｘメジャのラインは早期に求められるが、概念上は、どこでも都合の良いところで求めらる。
５．４．８．２．２ＺｓｌｏｐｅＭｊｒ及びＺｓｌｏｐｅＭｎｒを計算する
（ＺｍｉｎとＺｒｅｆサブ・ユニット）は、ＺｓｌｏｐｅＭｊｒ（大きいほうの辺に沿ったＺ導関数）ＺｓｌｏｐｅＭｎｒ（短軸に沿ったＺ勾配）である。幾つかの定義として、ａ）Ｘメジャの三角形：三角形において、ｘディメンジョンにおいての方がｙディメンジョンにおいてよりも大きいか又はこれと等しい距離を張っていれば、Ｘメジャの三角形であり、そうでなければＹメジャの三角形である、ｂ）Ｘメジャのライン：ラインの軸において、ｘディメンジョンにおいての方がｙディメンジョンにおいてよりも、大きいか又はこれと等しい距離を張っていれば、Ｘメジャのラインであり、そうでなければＹメジャのラインである、ｃ）メジャ辺（長辺として知られている）が挙げられる。Ｘメジャの三角形に関しては、それは最左頂点と最右頂点をつないでいる辺である。Ｙメジャの三角形に関しては、それは最上頂点と最下頂点をつないでいる辺である。ラインに関しては、それはラインの軸である。メジャ辺を「長辺」と呼ぶことがしばしばあったとしても、これは必ずしも最も長い辺ではないことに留意されたい。それはｘ又はｙディメンジョンの何れかに沿って最も長い距離を張る辺であり、ｄ）短軸については：三角形又はラインがＸメジャである場合は、短軸はｙ軸である。三角形又はラインがＹメジャである場合、短軸はｘ軸ということになる。
ＺｓｌｏｐｅＭｊｒとＺｓｌｏｐｅＭｎｒを計算する場合、
【０７００】
【数４９】
2004272928.tif 000066
５．４．８．２．３大きなデプス勾配についての特別な場合
三角形が任意に大きな値のＤｚ／Ｄｘ及びＤｚ／Ｄｙを生成することがあり得る。値が大きすぎると２つの問題が生じることになる、即ち、
１．カルは、３５ｂより幅狭のＤｚ／Ｄｘ及びＤｚ／Ｄｙを取り扱うことが可能な固定小数点データパースを有する。これら３５ｂを使って、Ｔ２７．７（２７整数ビットと７小数部ビットの大きさを有する２の補数）と指定される値が特定される。従って、デプス勾配の大きさは２Λ２７未満でなければならない。
２．所与の（Ｘ，Ｙ）座標におけるＺの計算は、大きなエラーを受けることになる。デプス勾配が大きければ、Ｘ又はＹのエラーが小さくてもデプス勾配により拡大されることになる。デプス勾配が大きい場合には以下のことが実行される。ＧＲＭＡＸは最大許容デプス勾配に関する閾値である。
これは、補助リング（例えば、コンピュータ１０１（図Ｄ１参照）上で起動しているソフトウェアを介して求められセットされる）を介してセットされる。
【０７０１】
【数５０】
2004272928.tif 000067
５．４．８．２．４辺上三角形を捨てる
辺上三角形はデプス勾配ユニット７（図Ｄ６参照）で検出される。Ｄｚ／Ｄｘ又はＤｚ／Ｄｙが無限（オーバーフロー）であるときはいつでも三角形は無効とされる。しかしながら、辺上ライン・モード三角形は捨てられない。可視辺各々はレンダされることになる。このような三角形に対するデプス・オフセット（作動した場合）は、しかしながら、オーバーフローし、＋／−２Λ２４にクランプされる。
５．４．８．２．５無限ｄｘ／ｄｙ
無限ｄｘ／ｄｙは、辺が完全に水平であることを暗示している。水平辺の場合は、２つのエンド・ポイントのうちの片方が角頂点（ＶｔｘＬｅｆｔＣ又はＶｔｘＲｉｇｈｔＣ）にならねばならない。座標がウィンドウ範囲内に在るプリミティブに関しては、カル４１０（図Ｄ４参照）は無限傾斜を利用しない。これは、カル４１０のエッジ・ウォーキング・アルゴリズムを用いると、左及び／又は右角頂点のｙ値から、それが角になっており、水平辺に沿ってウォークする必要は全くないことを教えることが可能となるからである。
【０７０２】  この場合は、カル４１０のエッジ・ウォーキングは傾斜を必要とすることになる。エッジ・ウォーキングの開始点はウィンドウの正に辺にあるので、エッジ・ウォーキングが正しく符号付けされた傾斜で計算するＸは何れもオーバーフロー（又はアンダーフロー）を引き起こすことになり、Ｘはウィンドウ辺に戻されてクランプされるだけである。従って、正確な符号である限り、それが使用している傾斜の値が何であるかは実際のところ重要ではない。
【０７０３】  無限の値は、セットアップ２１５自身が傾斜を使用することに関しては関係ないといえる。セットアップは傾斜を使って、タイル辺によるプリミティブ辺のインタセプトを計算する。インタセプトの計算用の数式は、Ｘ＝Ｘ０＋＿Ｙ＊ｄｘ／ｄｙという式になる。この場合、無限のｄｘ／ｄｙは、必ずゼロの＿Ｙを暗示している。インプリメンテーションがゼロ足す任意数はゼロというものである場合は、ｄｘ／ｄｙはどうでもよいことになる。
【０７０４】  セットアップ２１５は、内部的に浮動小数点フォーマットで傾斜を計算する。浮動小数点ユニットは、無限結果が起きた場合に無限フラグを表明する。セットアップは無限傾斜に留意せず、カル４１０も無限傾斜の大きさについては留意せず、符号について留意するので、セットアップ２１５は無限を表現する必要は無い。正しい符号を求めるという手間を省くために、セットアップ２１５は、無限傾斜を、それがカル４１０に引き渡される前に、ＺＥＲＯにする。
５．４．９ＺｍｉｎとＺｒｅｆ
次に、プリミティブとタイルの交差点を表す最小ｚ値を計算する。このサブ・ユニットの目的は、ａ）最小Ｚ値となる可能性のある３つの候補位置を選択すること、ｂ）必要なら補正バイアスを適用して、これら３ポイントのＺを計算すること、ｃ）タイル内の多角形の最小Ｚ値を選択すること、ｄ）最小Ｚ値の位置に最も接近しているスタンプ中心を基準スタンプ位置として使用すること、ｆ）Ｚオフセット値を適用すること、である。
【０７０５】  クリッピング・サブ・ユニットにより、おそらく９つの有効なクリッピング・ポイントが求められると考えられる。最小Ｚ値はこれらのポイントのうちの１つということになる。デプス計算は費用のかかるオペレーションであるので、実行すべきデプス計算の数を最小限にすることが望ましいという点に留意されたい。Ｚ値がどれも予め計算されていない状態では、ＺＸ及びＺＹの符号（ｘ及びｙにおけるｚ偏導関数の符号）を調べることにより、９つの可能性のある位置を３つの可能性のあるＺｍｉｎ位置に減らすことが可能である。
【０７０６】  クリッピング・ポイント（Ｘｍｉｎ０，Ｙｍｉｎ０，Ｖｌｉｄ）、（Ｘｍｉｎ１，Ｙｍｉｎ１，Ｖｌｉｄ）、（Ｘｍｉｎ２，Ｙｍｉｎ２，Ｖｌｉｄ）は、Ｚｍｉｎの３つの候補位置とそれらの有効ビットである。これらの幾つかは無効である可能性もある。無効なクリッピング・ポイントを考察から外すことが望ましい。これを実現するため、セットアップ２１５は、プリミティブが完全にタイルをカバーしている場合には、最小デプス値に対応するであろうタイル角を見つける。セットアップ２１５は、一旦そのタイル角を見つけると、最も接近しているクリップド・ポイント２箇所のデプス値を計算するだけでよい。これら２つの値は、頂点ｉ１（Ｃｌｉｐ  Ｐｏｉｎｔ  Ｐｌ）の値と共に、３つの考えられる最小ｚ値を提供してくれる。可能性のあるクリップ・ポイントはＰＴＬ、ＰＴＲ、ＰＬＴ、ＰＬＢ、ＰＲＴ、ＰＲＢ、ＰＢＲ、ＰＢＬ、及びＰｌである（Ｐｌのデプス値は常にｙソートされた中間（ｙｓｏｒｔＭｉｄ）のデプス値である）。３つの可能性のあるデプス値候補を比較して、最小デプス値とその位置を求めねければならない。ここで最小ｚ値と、それから入手されるクリップ頂点が分かる。本発明のある好適な実施例では、Ｚ値はＣＵＬに送る前に２４ビットにクランプされる。
【０７０７】  上記のことを説明するに際し、最小デプス値候補であるクリッピング・ポイントを識別するための以下の擬似コードを参照されたい。
表記法備考：
【０７０８】
【数５１】
2004272928.tif 000068
図Ｄ９には、Ｚｍｉｎ候補の例を示している。
５．４．９．１Ｚ計算アルゴリズム
三角形上の任意点のＺ値を計算する際の直進的アプローチでは、以下の数式、即ち：Ｚｄｅｓｔ＝（Ｘｄｅｓｔ−Ｘ０）＊ＺＸ＋（Ｙｄｅｓｔ−Ｙ０）＊ＺＹ＋Ｚ０＋オフセット、を使用することになる。しかしながら、この数式はＡｐｅｘインプリメンテーションでは２つの問題、即ち１）数式は精度が限られた浮動小数点ユニットを使って書かれているので、数式には大きな消約が起こり正確さに欠けることになる、及び２）パイプライン２００の後続ステージ２４０、特にカル４１０は、２Λ２７よりも大きいＺｘ又はＺｙを扱えない、という問題を抱えることになる。上記数式はこれらの問題に立ち向かう安易な道を提供するのではない。
【０７０９】  概念上、上記数式に附随する問題は計算の経路が三角形の外側をウォーキングすることを含んでいるということである。２つの積項が大きくて、２Λ２４の範囲をはるかに外れた中間Ｚ値を生み出すかもしれない。最終的なＺ値は２Λ２４未満となろうが、ほとんど等しいが符号が逆の２つの非常に大きな数を減算して相対的に小さい数を入手することにより求められる。小数部のビットを制限していた浮動小数点を使うこのような計算は、大消約と呼ばれるプロセスにより正確さを失うことになるかもしれない。
【０７１０】  計算の経路が三角形内に留まるアルゴリズムは、２Λ２４の範囲内に留まるであろう中間Ｚ値を生成するので、大消約によるほどには深刻な問題を被らない。Ｙメジャの三角形の場合は、
【０７１１】
【数５２】
2004272928.tif 000069
となる。
【０７１２】  （１）の行は、長辺に沿って適当なＹ座標までウォークするにつれてのＺの変化を表す。（２）の行は、長辺から目的地のＸ座標までウォークするにつれての変化である。
Ｘメジャの三角形に関しても、数式は同様である。
【０７１３】
【数５３】
2004272928.tif 000070
値が大きいデプス勾配を扱う場合は、大きなデプス勾配の特別な場合に規定された値（先に詳しく述べた）が使用される。
５．４．９．２Ｚｍｉｎ候補に関しＺを計算する
Ｚｍｉｎの３候補位置は識別されている（先に詳しく述べた）。各Ｚｍｉｎ候補が有効か否かを示すために、フラグは運ばれる必要があることを思い出そう。
【０７１４】  計算：Ｙメジャの三角形の場合：
【０７１５】
【数５４】
2004272928.tif 000071
ｘｍｉｎ０又はｙｍｉｎ０がタイル辺に等しいのであれば、ｚｍｉｎ値に対する補正を適用する必要がある。精度が制限された算術ユニットが使用されているので（交差を計算しクリッピング・ポイントを求めている間に上で計算された）インタセプトの値は、誤差が＋／−１／１６ピクセル未満となる。ここで無限に正確なＺｍｉｎとなるであろうものよりも小さいＺｍｉｎが計算されることを保証するために、Ｚｍｉｎにバイアスを与えるが、それをここで計算する。
ｘｍｉｎ０がタイル辺上にあれば？ｄＺ／ｄＹ？／１６をｚｍｉｎ０から減じ、
ｙｍｉｎ０がタイル辺上にあれば？ｄＺ／ｄＸ？／１６をｚｍｉｎ１から減じ、
ｘｍｉｎ０とｙｍｉｎ０がタイル辺上にあれば、減算は行なわず、
ｘｍｉｎ０とｙｍｉｎ０が双方共にタイル辺上になければ、減算は行なわない。
【０７１６】  同じ数式を使ってＺｍｉｎ１及びＺｍｉｎ２を計算する。
５，４，９，３Ｚｍｉｎを求める
３つのＺｍｉｎ候補の最小有効値がタイルのＺｍｉｎである。その中心がＺｍｉｎの位置に最も接近しているスタンプが基準スタンプである。Ｚｍｉｎを選択するための擬似コードは以下の通りである。
【０７１７】
【数５５】
2004272928.tif 000072
Ｚｍｉｎ０、Ｚｍｉｎ１、Ｚｍｉｎ２それぞれに対応するｘ及びｙ座標は、Ｚｍｉｎを求めるプロセスと並行してソートされる。従って、Ｚｍｉｎが確定されると、対応するｘｍｉｎとｙｍｉｎも決まる。
５．４．１０基準スタンプとＺｒｅｆ
プリミティブの各頂点に関するＺ値を送る代わりに、セットアップは、プリミティブ内の特定のポイントにおけるＺ値を表している単一のＺ値を送る。セットアップは、最小ｚを持つ頂点を含んでいる基準スタンプを選定する。基準スタンプは、クリップ頂点のｘ及びｙ座標に増分値を加え、ｘ及びｙ値を最も近い偶数値に切り捨てることにより保有スタンプを見つけることにより、識別される。基準スタンプが計算される前に、右辺上の頂点に関しては、ｘ座標が減分され、頂辺上の頂点に関しては、ｙ座標が減分される。
基準スタンプを識別するために使用される論理
基準Ｚ値「Ｚｒｅｆ」は基準スタンプの中心で計算される。セットアップ２１５は、タイル内のその位置を特定する１対の３ビット値、即ちｘＲｅｆＳｔａｍｐ及びｙＲｅｆＳｔａｍｐで基準スタンプを識別する。基準スタンプは、スタンプのタイルの角からのスタンプ内のオフセットとして識別されることに留意されたい。スクリーン空間内のオフセットを入手するために、スタンプ内のサブ・ピクセルの数は乗算される。例えば：ｘ＝ｘタイル座標、掛ける、タイルの幅内のピクセル数、プラス、ｘｒｅｆｓｔａｍｐ、掛ける２である。これによりスクリーン空間内のピクセルのｘ座標が与えられる。
【０７１８】  基準スタンプはクリップされた多角形にタッチするはずである。これを確かにするために、Ｚｍｉｎの位置にもっとも近いスタンプの中心を選定して、基準スタンプとする。Ｚｍｉｎ選択とソーティングの際、最終的に選定された頂点座標の航跡を保持する。この点を（Ｘｍｉｎ，Ｙｍｉｎ）と呼ぶ。
【０７１９】  Ｚｍｉｎがｒｈｔタイル辺に位置するのであれば、Ｘｍｉｎ＝ｔｉｌｅＬｆｔ＋７スタンプ、をクランプする。
Ｚｍｉｎが上タイル辺上にあれば、
【０７２０】
【数５６】
2004272928.tif 000073
をクランプする。
ｚＭｉｎ計算に対するのと同じ数式を使ってＺｒｅｆを計算する。
【０７２１】  計算：Ｙメジャの三角形の場合は、
Ｚｒｅｆ＝＋（Ｙｒｅｆ−Ｙｔｏｐ）＊ＺｓｌｏｐｅＭｊｒ＋（Ｘｒｅｆ−（（Ｙｒｅｆ−Ｙｔｏｐ）＊ＤＸ／Ｄｙｌｏｎｇ＋Ｘｔｏｐ））＊ＺｓｌｏｐｅＭｎｒ
（但し、Ｚｔｏｐとオフセットはまだ加えられていない。）
Ｘメジャの三角形の場合は、
Ｚｒｅｆ＝＋（Ｘｒｅｆ−Ｘｒｉｇｈｔ）＊ＺｓｌｏｐｅＭｊｒ＋（Ｙｒｅｆ−（（Ｘｒｅｆ−Ｘｒｉｇｈｔ）＊ＤＸ／Ｄｙｌｏｎｇ＋Ｘｔｏｐ））＊ＺｓｌｏｐｅＭｎｒ
（但し、Ｚｒｉｇｈｔとオフセットはまだ加えられていない。）
５．４．１０．１デプス・オフセットを適用する
ここまでに計算されたＺｍｉｎとＺｒｅｆに、さらにＺコンポーネントを加える必要がある。
Ｘメジャの場合は、
【０７２２】
【数５７】
2004272928.tif 000074
となる。
５．４．１１ＣＵＬに送られたＸ及びＹ座標
セットアップは範囲が拡大した（ｓ１２．５ピクセル）クワッド頂点を計算する。クワッド頂点がウィンドウ範囲の外側になる場合は、セットアップは以下の値をＣＵＬに送る、即ち、
ＸＴｏｐＲがウィンドウの右範囲であれば、ウィンドウの右辺にクランプ。
ＸＴｏｐＬがウィンドウの左範囲であれば、ウィンドウの左辺にクランプ。
ＸｒｉｇｈｔＣがウィンドウの右範囲であれば、ＲｉｇｈｔＢｏｔ  Ｃｌｉｐ  Ｐｏｉｎｔを拾う。
ＸｌｅｆｔＣがウィンドウの左範囲であれば、ＬｅｆｔＢｏｔ  Ｃｌｉｐ  Ｐｏｉｎｔを拾う。
Ｙｂｏｔは常にＣｌｉｐ  ＰｏｉｎｔのｍｉｎＹである。
図Ｄ２０では、範囲を外れたクワッド頂点の例を示している。
５．４．１２無限ｄｘ／ｄｙ
無限ｄｘ／ｄｙは、辺が完全に水平であることを暗示している。座標がウィンドウ範囲内にあるプリミティブに関しては、カルは無限傾斜を利用しない。これは、カルのエッジ・ウォーキング・アルゴリズムを用いると、ＹｌｅｆｔＣ（又はＴｒｉｇｈｔＣ）パラメータから、それは角であると分かるので、水平辺に沿ってウォークする必要が全くないということを教えることができるからである。不都合にも、クワッド頂点がウィンドウ範囲を外れているときには、特に非アンチエイリアスド・ラインの場合には、ちょっとした問題が生じる。その上部右角がウィンドウ範囲を外れている非アンチエイリアスド・ラインの場合を考察しよう。ＲｉｇｈｔＣがＲｉｇｈｔＢｏｔ  Ｃｌｉｐ  Ｐｏｉｎｔ上へ移ると、カルのエッジ・ウォーキングは角が水平辺上にあると考えず、ＸｔｏｐＲから投影されたＸを計算しようとする。（図Ｄ４３上参照）。この場合、カルのエッジ・ウォーキングは傾斜を必要とする。プリミティブがウィンドウの正に辺にあるので、正しく符号が付けられた傾斜でエッジ・ウォーキングが計算するＸは、オーバーフロー（又はアンダーフロー）を起こし、Ｘはウィンドウ辺に戻されてクランプされるだけである。従って、正しい符号である限り、それが使う傾斜の値が何であろうと実際には重要でない。無限の値は、セットアップ２１５自身が傾斜を使用することに関しては関係ないといえる。セットアップは傾斜を使って、プリミティブ辺のタイル辺によるインタセプトを計算する。インタセプトの計算用の数式は、Ｘ＝Ｘ０＋ＤＹ＊ｄｘ／ｄｙという式になる。この場合、無限のｄｘ／ｄｙは、必ずゼロのＤＹを暗示している。従って、ｄｘ／ｄｙの値はどうでもよいことになる。セットアップは、内部的に浮動小数点フォーマットで傾斜を計算する。浮動小数点ユニットは、無限結果が起きた場合に無限フラグを表明する。セットアップは無限傾斜に留意せず、カル４１０も無限傾斜の大きさについては留意せず、符号について留意するので、我々は無限を表現する必要は全く無い。正しい符号を求めるという手間を省くために、セットアップは、無限傾斜を、それがカルに送られる前に、ＺＥＲＯにする。
【０７２３】
【表１５】
2004272928.tif 000075
【０７２４】
【表１６】
2004272928.tif 000076
【０７２５】
【表１７】
2004272928.tif 000077
【０７２６】
【表１８】
2004272928.tif 000078
【０７２７】
【表１９】
2004272928.tif 000079
【０７２８】
【表２０】
2004272928.tif 000080
【０７２９】
【表２１】
2004272928.tif 000081
【０７３０】
【表２２】
2004272928.tif 000082
【０７３１】ＶＩＩ．カル機能ブロック（ＣＵＬ）の詳細な説明
本発明の装置及び方法は、ディファード・シェーディング・グラフィクス・パイプライン（ＤＳＧＰ）での保存性陰面除去法（ＣＨＳＲ）を提供する。パイプラインはプリミティブをレンダーするものであり、本発明は、１）三角形、２）ライン、３）ポイントを含む一式のレンダー可能なプリミティブに関連して説明されている。４つ以上の頂点を有する多角形は、ジオメトリ・ブロック（以後説明する）で三角形に分割されるが、ＤＳＧＰパイプラインは、四辺形又はもっと辺の多い多角形をレンダーできるよう容易に修正することができる。従って、パイプラインはどんな多角形でも一旦三角形に分解するとレンダーできるので、本発明のレンダラーはどんな多角形プリミティブでも効果的にレンダーすることができる。本発明は、所与のプリミティブが、ディスプレイ・スクリーンに現れるのか又は影響を及ぼすのか否か、現れるとすればそのどの部分に現れ、影響を及ぼすのかを巧く考慮する。所与のプリミティブがディスプレイ・スクリーン上の３Ｄウィンドウのどの部分に影響を及ぼすのか識別するため、パイプラインは、描かれている３Ｄウィンドウをタイルやスタンプと呼ばれる連続した小さな領域に分割する。パイプラインはディファード・シェーディングを実行するが、そこではピクセル・カラーは、陰面除去が済むまで決定されない。マグニチュード・コンパリソン・コンテンツ・アドレス可能メモリ（ＭＣＣＡＭ）を用いると、パイプラインが、隠されたジオメトリを巧く効果的に選別除去できるようになる。
【０７３２】  本発明の保存性陰面除去プロシジャのインプリメンテーションは、プリミティブに対するダイナミックな規則変更（例えば、１シーンの間にデプス・テスト又はステンシル・テストを変更するような）のサポートを含め、オープンＧＬのような他の標準的なＡＰｌと互換性がある。本発明のディファード・シェーダーの実施例では、普通は非ディファード・シェーダーが全てのジオメトリ・アイテムに対する一連の規則を実行し、次にレンダーされた最終結果をチェックする従来型のレンダリング・パラダイムは崩される。本発明の構造及び方法は、ジオメトリの全てのピース内の全てのピクセルに対して全てのカラーを作成又は生成する必要無しに、フレーム・バッファ内の最終値に実際に影響を及ぼすジオメトリを予想又は予測する。基本的に、ジオメトリの空間位置が吟味され、あらゆる特定のサンプルに対して、ｚバッファ内の最終的なカラーに影響を及ぼすジオメトリ・アイテムが定められ、次にそのカラーだけが生成される。
【０７３３】  ある実施例では、ＣＨＳＲは各プリミティブを時間順に処理して、プリミティブがタッチする各サンプル毎に、ＣＨＳＲは、デプス・テスト及びアルファ・テストのような様々なアプリケーション・プログラム・インタフェース（ＡＰＩ）状態変数に基づいて保存性の決定を行う。ＣＨＳＲプロセスの利点の一つは、アルファ・テスト、カラー・テスト及びステンシル・テストのようなＡＰＩからの非デプス依存テストがＤＳＧＰパイプラインで行えるとしても、陰面除去の間にカラー計算をする必要がないことである。ＣＨＳＲプロセスは、サンプル毎の有限状態マシン（ＦＳＭ）であると考えることができる。各サンプル毎ＦＳＭは、以後サンプル有限状態マシンと呼ぶこととする。各サンプルＦＳＭは、１）ｚ座標情報、２）プリミティブ情報（そのサンプル又はピクセルでプリミティブのカラーを生成するのに必要なあらゆる情報、又はそのような情報へのポインタ）及び３）１つ又はそれ以上のサンプル状態ビット（例えば、これらのビットは正確か又は保存性であるように１つ又は複数のｚ値を指定することもできる）を含むサンプル毎のデータを保守する。サンプル毎に多数のｚ値を用いるのは簡単だがサンプル毎に多数のプリミティブ情報のセットというのは費用が嵩む。以後、サンプルＦＳＭは１つのプリミティブに関するプリミティブ情報を保守すると仮定する。更に各サンプルＦＳＭは、透明度情報を保守し、それはソート済み透明度に用いられる。
【０７３４】  ＤＳＰＧは、１）時間順モード、及び２）ソート済み透明モードの２つの明確に異なるモードで操作できる。時間順モードは、何れの特定のタイル内にも、同じプリミティブの時間順を保存するように設計されている。時間順モードでは、頂点及びモードの時間順は各タイル内に保存されるが、タイルは縦横に区画されたディスプレイ・ウィンドウの一部である。時間順が保存されるということは、所与のタイルに関し、頂点及びモードが、書き込まれたときと同じ順序で読み取られるということである。ソート済み透明モードでは、タイルからジオメトリを読み取るプロセスが多数のパスに分けられている。第１パスでは、不透明なジオメトリ（即ち、更に遠くのジオメトリを完全に隠すことができるジオメトリ）が処理され、次のパスで、透明かもしれないジオメトリが処理される。各ソート済み透明モードのパスでは、時間順が保存され、モード・データはその正しい時間順位置に挿入される。ソート済み透明モードは、ジオメトリをバックツーフロント順か又はフロントツーバック順の何れかで空間的にソートし、それによって可視で透明なオブジェクトが（時間順ではなく）空間順にブレンドされるメカニズムを提供し、レンダリングをより正確にすることができる。好適な実施例では、ソート済み透明度方法は、ソート・ブロックとカル・ブロックが組み合わされて実行される。
【０７３５】  本発明の構造及び方法は、様々な実施例で実現することができる。ある態様では、本発明は陰面除去を実行するための構造及び方法を提供しており、そこでは構造はコンピュータ・グラフィクス・パイプラインとして有用に実現され、又、本発明の陰面除去法は以下のステップ又はプロシジャを含んでいる。第１に、プリミティブのグループからオブジェクト・プリミティブ（現在のプリミティブ）が選択されるが、各プリミティブは複数のスタンプを備えている。次に、現在のプリミティブのスタンプはプリミティブのグループ内の先に評価済みのプリミティブから選択されたスタンプと比較され、第１スタンプは、スタンプ・セレクション・プロセスにより、更に随意的には性能的理由のためにＳＡＭにより、現在のスタンプ（ＣＳ）として現在のプリミティブから選択される。ＣＳは、第２スタンプ又は先に評価済みであるがまだ捨てられていないスタンプから選択されたＣＰＶＳと比較される。ＣＳとの比較に基づいて、第２スタンプの何れの部分も最終的なグラフィクス・ディスプレイ・イメージに影響を及ぼすことがないと判断される場合には、第２スタンプは捨てられる。ＣＳとの比較に基づいて、第２スタンプの全てではないが一部分は最終的なグラフィクス・ディスプレイ・イメージに影響を及ぼすことがないと判断される場合には、第２スタンプの最終的なイメージに影響しない部分が第２スタンプから削除される。第２スタンプとの比較に基づき、第２スタンプのどの部分も最終的なグラフィクス・ディスプレイ・イメージに影響しないと判断される場合、ＣＳは捨てられる。第２スタンプとの比較に基づいて、ＣＳの全てではないが一部分は最終的なグラフィクス・ディスプレイ・イメージに影響を及ぼすことがないと判断される場合には、ＣＳの最終的なイメージに影響しない部分がＣＳから削除される。ディスプレイ・スクリーン領域内の全プリミティブの中の全スタンプの評価が済んだとき、捨てられていないスタンプはピクセル又はサンプルを有しており、陰面除去を実行する際のこれらの第１ステップより下流のパイプラインの部分でカラー付けされる。ある実施例では、捨てられていないスタンプのセットは、サンプル毎に１スタンプと限定することができる。この実施例では、第２スタンプとＣＳが同一サンプルを含んでおり、どちらも捨てることができない場合、第２スタンプはディスパッチされ、ＣＳは捨てられないスタンプのリストに保持される。更にこの代替実施例では、第２スタンプ及びＣＳの視認性が後にコンピューター・グラフィックス・パイプラインで評価されるパラメータ次第である場合、第２スタンプ及びＣＳはディスパッチされる。ある代替実施例では、例えばＳＡＭによる第１スタンプの選択及びスタンプ選択は、現在のスタンプ（ＣＳ）が、第１スタンプ内のサンプルのデプス・テストと先に評価済みのスタンプのサンプルのデプス・テストとの関係テストに基づいているものとして処理し、本発明の装置の態様は多数のスタンプに同時に関係テストを実行する。
【０７３６】  陰面除去を実施するための本発明の構造及び方法の別の態様では、現在可視の可能性があるスタンプ（ＣＰＶＳ）のセットは、現在のデプス値（ＣＤＶ）のセットとは別に保守されるが、ここで本発明の陰面除去法は以下のステップ又はプロシジャを含んでいる。第１に、オブジェクト・プリミティブ（現在のプリミティブ）は、それぞれが複数のスタンプを備えているプリミティブのグループから選択される。次に現在のプリミティブからの第１スタンプが現在のスタンプ（ＣＳ）として選択される。次に現在可視の可能性があるスタンプ（ＣＰＶＳｓ）がＣＰＶＳのセットから、そのＣＰＶＳがＣＳと重複しないように選択される。選択されたＣＰＶＳ及びＣＳの両方と重複する各サンプルについて、ＣＳのデプス値がＣＤＶのセット内のデプス値と比較されるが、この比較オペレーションはパイプライン状態を考慮し、ＣＤＶを更新する。視認されないと判断された、選択されたＣＰＶＳ内のサンプルは、選択されたＣＰＶＳから削除される。選択されたＣＰＶＳ内の全サンプルが削除される場合は、選択されたＣＰＶＳがＣＰＶＳのセットから削除される。ＣＳ内の何れかのサンプルが可視であると判定された場合は、その可視サンプルだけを含むＣＳがＣＰＶＳのセットに加えられる。あるサンプルに関しＣＳと選択されたＣＰＶＳ両方が可視である場合は、少なくとも選択されたＣＰＶＳ内の可視サンプルがカラー計算のためにパイプラインに送り込まれる。ＣＳとＣＰＶＳの両方に含まれるサンプルの視認性が、後にコンピュータ・グラフィック・パイプラインでのパラメータ評価次第である場合は、少なくともこれらのサンプルはカラー計算のためにパイプラインに送り込まれる。本発明は、ＣＳに重なる全てのＣＰＶＳを並行して処理するための構造及び方法を提供する。更に、並行処理は、クロック・サイクル毎に１つの割合でＣＳを処理できるようにパイプライン化される。多数のＣＳを並行して処理することもできる。
【０７３７】  別の態様では、本発明は、ディファード・シェーダー・コンピュータ・グラフィックス・パイプライン用陰面除去システムのための構造及び方法を提供しており、このパイプラインは、現在のプリミティブと関連する可視の可能性があるサンプルの第１グループを識別するためのマグニチュード・コンパリソン・コンテンツ・アドレス可能メモリ（ＭＣＣＡＭ）カル・ユニットと、現在のプリミティブと関連する可視の可能性があるサンプルの第２グループを、第１グループ及びプリミティブのペリメータに基づいて識別するための、ＭＣＣＡＭカル・ユニットに連結されているスタンプ・セレクション・ユニットと、パイプライン状態を評価し、第２グループのデプス状態を記憶されているデプス状態値と比較することにより可視スタンプ部分を識別するための、スタンプ・セレクション・ユニットとＭＣＣＡＭカル・ユニットとに連結されているＺカル・ユニットと、Ｚカルユニットから受信した制御信号に基づいて可視スタンプ部分を記憶するための、Ｚカル・ユニットに連結されているスタンプ部メモリ・ユニットを含んでおり、このスタンプ部メモリ・ユニットは、後にコンピュータ・グラフィック・パイプライン内で評価されるパラメータ次第で、視認性を有するスタンプをデッィスパッチする。
【０７３８】  更に別の態様では、本発明はグラフィックス・イメージをレンダーする構造及び方法を提供しており、これには、レンダーされるべき複数のプリミティブを受信する段階と、サンプル位置を選択する段階と、選択されたサンプル位置で最も前の不透明なサンプルをレンダーし、最も前の不透明なサンプルのｚ値をＺｆａｒとして定義する段階と、選択されたサンプル位置で複数の第１サンプルのｚ値を比較する段階と、選択されたサンプル位置で、複数の第１サンプルの中でＺｆａｒ未満で、Ｚｆａｒに最も近いｚ値を有する第１サンプルをＺｎｅａｒと定義する段階と、その第１サンプルをレンダーする段階と、ＺｆａｒをＺｎｅａｒの値に設定する段階と、選択されたサンプル位置で複数の第２サンプルのｚ値を比較する段階と、選択されたサンプル位置で、複数の第２サンプルの中でＺｆａｒ未満で、Ｚｆａｒに最も近いｚ値を有する第２サンプルのｚ値をＺｎｅａｒとして定義する段階と、第２サンプルをレンダーするする段階とが含まれている。
実施例
カル・ブロック概観
図Ｅ１２は、カル・ブロック９０００のブロック線図を示す。カル・ブロックは、１）事前シェーディング陰面除去と、２）プリミティブ・ジオメトリ・エンティティ（三角形、ライン、ポイント）を可視スタンプ部（ＶＳＰ）と呼ばれるスタンプ・ベースのジオメトリ・エンティティに分解することに責任を負っている。カル・ブロックは、普通、陰面の保存性の選別除去を行う。保存性の陰面除去プロセスをやり易くするために、カル・ブロック９０００は、アルファ・テストやステンシル・テストのようなある種の「フラグメント・オペレーション」を扱わない。Ｚカル９０１２はサンプル毎に２つのデプス値を記憶することができるが、サンプル毎に１つのプリミティブの属性を記憶するだけである。従って、サンプルが２つのジオメトリからのカラーをブレンドするよう求める場合はいつでも、カル・ブロックは常に、例えその後にブレンドされた両ジオメトリを隠すジオメトリが存在していても、パイプラインに第１プリミティブを（時間順を使って）送り込む。
【０７３９】  カル・ブロックはセットアップ・ブロック８０００からパケット形式でインプットを受信する。カル・ブロックで受信されるパケットの１つのタイプは、モード・パケットである。モード・パケットは、新しいタイルの開始、新しいフレーム、フレームの終了を含むカル・ブロック制御情報を提供する。更にカル・ブロック９０００は、セットアップ・アウトプット・プリミティブ・パケットを受信する。各セットアップ・アウトプット・プリミティブ・パケットは、タイル毎ベースで、三角形、ライン、ポイントの何れかを記述する。セットアップ・アウトプット・プリミティブ・パケット内のデータ・フィールドは、プリミティブ・タイプ（三角形、ライン又はポイント）を示すためのビットを含んでいる。残りのジオメトリ・データ・フィールドの解釈はプリミティブのタイプ次第である。非ジオメトリ・データ・フィールドは、プリミティブ毎ベースで変更可能なカリング（選別除去）モードを制御するカラー・ポインタ及びモード・ビットを含んでいる。モード・パケットは、アルファ・テストが行われているか、Ｚバッファ書き込み可能か、カリングが保存性か又は正確であるか、デプス・テストが行われているか、ブレンディングが行われているか、プリミティブがアンチエイリアスドであるかどうかを示すモードビットと、その他の制御情報を含んでいる。
【０７４０】  ソート・ブロック６０００は、入ってくるジオメトリ・エンティティをタイルに繋ぐ。セットアップ・ブロック８０００は、カル・ブロックが陰面除去するための更に詳細なジオメトリに関する情報を提供するために、プリミティブを事前処理する。セットアップ・プロック８０００は、全ての辺に関する傾斜値、タイル内のプリミティブの境界画定ボックス、タイル内のプリミティブの最小値（最も前の）及び他の関連データを事前計算する。ソートの前に、モード抽出ブロック４０００が既にカラー、ライト、テクスチャ及び関連モードデータを抽出しており、カル・ブロックは、カル・ブロックと、多角形メモリ５０００に記憶されているカラー、ライト及びテクスチャを指す、カラー・ポインタと呼ばれるポインタとに関連するモード・データを獲得するだけである。
【０７４１】  カル・ブロックは二つの主要な機能を実行する。第１の機能は、フレーム・バッファ１７０００の最終結果に影響を与えないないことが保証されているジオメトリを除去する（即ち保存性形式の陰面除去）ことである。第２の機能は、プリミティブを可視スタンプ部（ＶＳＰ）のユニットに分解することである。スタンプ部は、プリミティブの所与のスタンプとの交点である。ＶＳＰは、スタンプ内のジオメトリ・エンティティの可視部である。ある実施例では、各スタンプは４個のピクセルを備えており、各ピクセルは４個の予め決められたサンプル・ポイントを有している。従って、各スタンプは１６の予め決められたサンプル・ポイントを有している。次にスタンプ部の「大きさ」が数字で示され、サンプル・ポイントセットが所与のスタンプ内のプリミティブによりカバーされる。
【０７４２】  カル・ブロックは、１度に１つのＶＳＰをモード注入ブロック１００００へ送る。モード注入ブロック１００００は、ＶＳＰをカラー、ライト、テクスチャ・データと再接続し、それをフラグメント１１０００とパイプライン内の後のステージへ送る。
【０７４３】  カル・ブロックは１度に１つのプリミティブを処理する。しかし、現在のフレームに関しては、パイプラインは１）時間順モードか、又は２）ソート済み透明モードのどちらかである。時間順モードでは、頂点及びモードの時間順が各タイルに保存され、タイルはデータを通して単一のパスで処理される。つまり、所与のタイルに関しては、頂点及びモードは、書き込まれたときと同じ順序で読み取られるが、現在のタイルに影響を及ぼさない場合にはスキップされる。ソート済み透明モードでは、各タイルのプロセッシングは複数のパスに分割されており、第１パスでは、保証された不透明ジオメトリが処理される（ソート・ブロックはこのパスに不透明なジオメトリだけを送信する）。次のパスで、透明な可能性もあるジオメトリが処理される（ソート・ブロックは各パスに全ての透明なジオメトリを送る）。各パスでは、時間順序が保存され、モード・データが正しい時間順位置に挿入される。
【０７４４】  時間順モードでは、タイル内には「シンプルで不透明なジオメトリ」しかない（即ち、シザー・テスト、アルファ・テスト、カラー・テスト、ステンシル・テスト、ブレンディング、ロジコップがない）場合、カル・ブロックは、何れかのＶＳＰをモード注入ブロックへディスパッチする前に、タイル内の全てのプリミティブを処理することになる。これは、カル・ブロック陰面除去法が、各サンプルに対してそのサンプルをカバーする（即ち、カラー付けする）単一のプリミティブを明確に決定することができるからである。「シンプルで不透明なジオメトリ」のケースは、通常、滅多にない特定のケースである。
【０７４５】  時間順モードでは、インプット・ジオメトリがタイル内の「シンプルで不透明なジオメトリ」に限定されない場合、ＶＳＰ（ＶＳＰの全体セット又は選択されたＶＳＰ）の早期ディスパッチを引き起こすことがある。しかし、所与のタイルの全てのＶＳＰは、何れかの異なるタイルのＶＳＰがディスパッチできる前に、例外なくディスパッチされる。一般的に、早期ディスパッチは、２つ以上のジオメトリが何れかのサンプルに対する（ピクセル・ブロック１５０００により決定される）最終タイル値に影響を及ぼす可能性がある場合に実施される。
【０７４６】  ソート済み透明モードでは、（タイル内には少なくとも幾つかの透明なジオメトリが存在するという前提で）各タイルは複数のパスで処理される。各パスにはＶＳＰの早期ディスパッチはない。
【０７４７】  インプット・パケットがセットアップ・アウトプット・プリミティブ・パケットである場合、ＰｒｉｍＴｙｐｅパラメータがプリミティブ・タイプ（三角形、ライン、ポイント）を示す。プリミティブの空間配置（導関数等を含む）は「統合的記述」を使って行われる。つまり、パケットはプリミティブを（スクリーンに整列していない）四辺形として記述し、三角形及びポイントは退化したケースである。この「統合的記述」は、１９９８年８月２０日付仮特許出願「ディファード・シェーディングを備えたグラフィックス・プロセッサ」に詳細に記載されており、参考文献としてここに援用する。パケットはモード注入に用いられるカラー・ポインタを含む。更にパケットは幾つかのモードビットを含んでおり、その多くはプリミティブ毎に変更することができる。ＣｕｌｌＦｌｕＳｈＯｖｅｒｌａｐ、ＤｏＡｌｐｈａＴｅＳｔ、ＤｕＡＢｌｅｎｄ、ＤｅｐｔｈＦｕｎｃ、ＤｅｐｔｈＴｅｓｔＥｎａｂｌｅｄ、ＤｅｐｔｈＴｅｓｔＭａＳｋ、ＮｏＣｏｌｏｒは「モード・ビット」と考えられており、Ｚカル９０１２内の状態マシンに入力される。
【０７４８】  セットアップ・アウトプット・プリミティブ・パケットに加えて、カル・ブロック９０００は以下のパケット・タイプ、即ち、セットアップ・アウトプット・クリア・パケット、セットアップ・アウトプット・カル・パケット、セットアップ・アウトプット開始フレーム・パケット、セットアップ・アウトプット終了フレーム・パケット、セットアップ・アウトプット開始タイル・パケット、セットアップ・アウトプット中間パケットを受信する。これらの各パケット・タイプについては、カル・ブロックの詳細な説明の節に詳しく記載されている。しかし、これらのパケットは纏めて「モードパケット」と呼ばれる。
【０７４９】  作動時には、カル・ブロック９０００がプリミティブを受信するとき、図Ｅ１２に示すように、カルは、プリミティブの境界画定ボックスを有するマグニチュード・コンパリソン・コンテンツ・アドレス可能メモリ（ＭＣＣＡＭ）カル９００２に問い合わせて、そのプリミティブの消去を試みる。ＭＣＣＡＭカル９００２が、プリミティブはタイル内に完全に隠されていることを表示すれば、そのプリミティブは消去される。ＭＣＣＡＭカル９００２がそのプリミティブを完全に排除できない場合、リスト中の各スタンプが可視であるかもしれないプリミティブの部分を含むようなスタンプのリストを生成することになる。この可視の可能性があるスタンプのリストは、カル・ブロック９０００のスタンプ選択ロジック９００８に送られる。スタンプ選択ロジック９００８は、プリミティブのジオメトリ・データを使って、タイルの各スタンプ行内の、実際にプリミティブがタッチしているスタンプのセットを決定する。スタンプ選択ロジック・ユニットは、ＭＣＣＡＭカル９００２により生成されるスタンプ・リストと組み合わされて、一度に１つの可視の可能性があるスタンプ９００６をＺカル・ブロック９０１２へディスパッチする。各スタンプは１６ｘ１６のサブピクセルのグリッドに分割される。各水平グリッド・ラインは、サブラスター・ラインと呼ばれる。スタンプ毎の１６個のサンプル・ポイント各々は（アンチエイリアスド・プリミティブに関して）可能性のある２５６個のサブピクセル位置の一つの中心に入ってくることになる。各ピクセルは、その境界内に４個のサンプル・ポイントを有しており、図Ｅ１３Ａではスタンプ９２１２として示されている。（図Ｅ１３Ｂと図Ｅ１３Ｃはスタンプ部がＺカル・プロセスに入力され、各々がＳＰＭに記憶される方法を示している。）ピクセル内のサンプル位置は、プログラム可能にできる。サンプル位置がプログラム可能であれば、多数のプロセッシング・パスを異なるサンプル位置で作成することができるので、ピクセル毎の有効なサンプルの数が増える。例えば、４個のパスは異なる４個のサンプル位置のセットを使って実行されるので、ピクセル毎の有効なサンプル数は１４個に増える。
【０７５０】  ディスプレイ・イメージはタイルに分割され、イメージを更に効果的にレンダーする。ディスプレイ・サイズの小片としてのタイルサイズは、グラフィック・パイプライン・ハードウェア・リソースに基づいて定義することができる。
【０７５１】  プリミティブがタッチするスタンプ行の中のスタンプのセットを決定するプロセスには、少なくとも１つのサンプル・ポイントを含む各サブラスター・ラインにおけるプリミティブの最左位置と最右位置とを計算することが含まれている。これらの最左及び最右のサブラスター・ラインの位置は、ＸｌｅｆｔＳｕｂＳｉ及びＸｒｉｇｈｔＳｕｂＳｉと表され、それぞれサンプルｉのｘ最左サブラスター・ライン及びサンプルｉのｘ最右サブラスター・ラインを表す。サンプルは０から１５まで番号が付けられている。ある辺上の１つのポイント（ｘ０、ｙ０）がわかっていれば、ｙ１のｙ位置に対応するｘ１の値は、以下の式により容易に決定できる。
【０７５２】
【数５８】
2004272928.tif 000083
スタンプ数に加えて、ＸｌｅｆｔＳｕｂＳｉとＸｒｉｇｈｔＳｕｂＳｉの１６の対のセットもスタンプ選択ロジック・ユニットによりＺカル９０１２へ送られる。
【０７５３】  Ｚカル・ユニット９０１２は一度に１個のスタンプ番号（又はスタンプＩＤ）を受信する。各スタンプ番号は、ＭＣＣＡＭカル９００２により可視であろうと判定されたプリミティブの部分を含んでいる。ＸｌｅｆｔＳｕｂＳｉとＸｒｉｇｈｔＳｕｂＳｉの１６の対のセットを使って、１６のサンプルポイントの内どれがプリミティブにカバーされているかが決定される。サンプルｉのｘ座標値Ｘｓａｍｐｌｅｉが
ＸｌｅｆｔＳｕｂＳｉ＝＜Ｘｓａｍｐｌｅｉ＜ＸｒｉｇｈｔＳｕｂＳｉ
を満たせば、サンプルｉはカバーされている。
【０７５４】  カバーされている各サンプルでは、プリミティブのｚ値はそのサンプル・ポイントで計算される。同時に、１６のサンプルポイント全ての現在のｚ値及びｚ状態がサンプルＺバッファ９０５５から読み取られる。
【０７５５】  各サンプル・ポイントは「保存性」又は「正確な」ｚ状態を有することができる。アルファ・テスト及び他のテストは、カル・ブロック９０００の後のパイプライン・ステージにより実行される。従って、例えば、デプス・テストに基づけばフレーム・バッファ内の最終的カラーに影響を及ぼすように見えるプリミティブが、実際には、デプス・テストが実行される前にアルファ・テストにより消去され、フレームバッファ内の最終的カラーに影響を及ぼさなくなることもある。このことを考慮して、カル・ブロック９０００は保存性のｚ値を用いる。保存性ｚ値は、そのポイントまでに処理されたジオメトリに基づいて、サンプルに関するｚ値のアウター・リミットを定義する。保存性ｚ値は、実際のｚ値がそのポイントか、又はより小さなｚ値か何れかにあることを意味する。従って、保存性ｚは、そのポイントが有し得る最大のｚ値である。デプス・テストが、超過するかで線引きする場合、保存性ｚ値は最小ｚ値である。反対に、デプス・テストが、未満かで線引きする場合、保存性ｚ値は最大ｚ値である。未満かのデプス・テストの場合のレンダーに関しては、プロセス内のその時点ではパスするかどうかがわからないので、所与のサンプル位置にあってｚ値が保存性ｚ値未満の何れのサンプルも、従って保存性パスである。
【０７５６】  正確なｚ値とは、ｚが表す面が面の実際のｚ値であるような値である。正確なｚを用いれば、ｚ値は、処理中のその時点で、可視であることがわかっている面を示し、その前のあらゆるものが可視であり、その後ろのものは全てよく見えないことが知られている。サンプルの状況は状態マシンで保守され、処理が続く間に、サンプルの状況は正確になったり保存性になったり切り替わることもある。ある実施例では、単一の保存性のｚ値が用いられている。別の実施例では、各サンプル位置に対して二つのｚ値、即ち、近いｚ値（Ｚｎｅａｒ）と遠いｚ値（Ｚｆａｒ）が保守されている。遠いｚ値は保存性ｚ値であり、近いｚ値は楽観的ｚ値である。二つのｚ値を用いると、サンプルは、保存性であるとラベル表示された後で再び正確であるように決めることができる。このことにより、正確なｚ値は保存性ｚ値よりも多くのジオメトリを消去するのに利用できるので、パイプラインの効率が向上する。例えば、アルファ・テストを受けるサンプルが受信されると、カル・ブロックでは、そのサンプルがアルファ・テストにより消去されるかどうかわからない。１個のｚ値しか記憶されていない実施例では、アルフ・テストを受けるサンプルの位置がデプス・テストを通る場合は、ｚ値は保存性の値でなければならない。アルファ・テストを受けるサンプルは、次に、パイプラインに送り込まれる。アルファ・テストが行われるサンプルは保持されないので、記憶されているサンプルのｚ値を後で正確に元に戻すことはできない。一方、２個のｚ値が記憶されるある実施例では、アルファ・テストを受けるサンプルは、その相対的な位置次第で、Ｚｆａｒ／Ｚｎｅａｒサンプルとして記憶することができる。従って、後に続くサンプルを、第２の記憶されているサンプル同様にアルファ・テストを受けるサンプルと比較することができる。カル・ブロックが、デプス・テストに基づいて、アルファ・テストを受けるサンプルの前の不透明なサンプルのような後続サンプルの１つが、アルファ・テストを受けるサンプルを見えなくすると決定すれば、その後続のサンプルは正確であるとラベル表示することができる。
【０７５７】  オープンＧＬでは、プリミティブはグループで処理される。プリミティブのグループの最初と最後は、それぞれ開始及び終了というコマンドで識別される。デプス・テストは、各プリミティブのグループに対し独立に定義されている。デプス・テストはパイプライン状態の１つの構成要素である。
【０７５８】  各サンプル・ポイントは他のサンプルとは独立した有限状態マシン（ＦＳＭ）を有している。カルに受信されたモード・ビットと結合した２状態が、サンプルＦＳＭを駆動する。サンプルＦＳＭは、サンプル毎ペースで、プリミティブのｚ値とＺカル９０１２のｚ値との間の比較を制御する。比較結果は、新しいプリミティブが可視であるか又はプリミティブがカバーする各サンプル・ポイントで隠されるかどうかを決定するのに用いられる。１６個のサンプルポイントの内の最大のｚ値は、ＭＣＣＡＭカル９００２を更新するのに用いられる。
【０７５９】  サンプルのＦＳＭは、Ｚカル９０１２内のサンプル２バッファがそのサンプルに関して如何に更新されるべきか、又新しいＶＳＰのサンプル・ポイントは早期ディスパッチされるべきかどうかについても決定する。更にサンプルＦＳＭは、同じサンプル・ポイントを含んでいる可能性のある何れかの古いＶＳＰが破壊されるべきか、あるいは早期ディスパッチされるべきかを決定する。Ｚカル９０１２は、サンプルが如何に処理されるべきかを記述する４個の制御ビットを各サンプル毎に生成し、それをスタンプ部マスク・ユニット９０１４へ送る。サンプル毎のこれらの制御ビットはＳｅｎｄＮｅｗ、ＫｅｅｐＯｌｄ、ＳｅｎｄＯｌｄ、ＮｅｗＶＳＰＭａｓｋである。プリミティブが可視のサンプル・ポイントを含んでいる場合、ＮｅｗＶＳＰＭａｓｋ制御ビットは、スタンプ部メモリ（ＳＰＭ）９０１８に新しいＶＳＰカバレッジ・マスクを生成させると表明される。残り３個の制御ビットは、ＳＰＭ９０１８がプリミティブに関してＶＳＰカバレッジ・マスクを如何に更新するのかを決定する。
【０７６０】  ソート済み透明モードでは、ジオメトリはサンプル毎ベースで空間的にソートされ、各サンプル内で、バックツーフロント順又はフロントツーバック順にレンダーされる。どちらの場合も、最も前の不透明なジオメトリの前にあると判定されたジオメトリだけが、パイプラインに送り込む必要があり、この決定はカル９０１２で行われる。
【０７６１】  バックツーフロント順のソート済み透明モードでは、時間順ラスタライゼーションの通常モードとは異なり、透明な各プリミティブは、最も前の不透明な層に最も近い層から始めて、空間順にラスタライズされる。Ｚｆａｒ及びＺｎｅａｒの２つのｚ値が、各サンプル位置に対して用いられる。ソート済み透明モードでは、透明なプリミティブはＺカル・ユニット９０１２を何回も通過する。図Ｅ９に示されているように、第１パスでは、ソートブロック６０００は不透明なプリミティブだけを送る。ｚ値は先に述べたように更新される。不透明プリミティブに対するｚ値は、Ｚｆａｒタイプであるとして参照される。パスの最後に、不透明ＶＳＰがディスパッチされる。二度目は、ソート・ブロック６０００はタイルに関して透明なプリミティブだけをカル・ブロック９０００に送る。最初に、サンプルＺバッファのＺｎｅａｒ部分は、有り得る最小ｚ値に予設定される。ｚ値がＺｆａｒより後ろのサンプル・ポイントは隠されているが、ｚ値がＺｆａｒの前で且つＺｎｅａｒより後ろのサンプル・ポイントは不透明層により近いので、現在のＺｎｅａｒのｚ値に置き換わる。このパスが、不透明層に最も近い層のｚ値を決定する。不透明層に最も近いことを示しているＶＳＰは、ディスパッチされる。するとＺｎｅａｒ及びＺｆａｒの役割が切り替えられ、Ｚカルは透明プリミティブの第２パスを受信する。このプロセスは、Ｚカルが透明プリミティブの可能性がある全ての層を処理したと判断するまで続く。ソート済み透明モードでも、Ｚカルは、サンプル有限状態マシンにより制御される。
【０７６２】  バックツーフロント順のソート済み透明モードでは、何れの特定タイルに関しても、透明パスの回数は可視透明面の数と等しい。それらのパスは以下のように行うことができる。即ち、
ａ）不透明パス（不透明パスは１つしかない）が次のことを行う、即ち、最も前の不透明ジオメトリが識別（Ｚｆａｒとラベル付け）されパイプラインへ送り込まれる。
【０７６３】  ｂ）第１透明パスが次のことを行う、即ち、１）パスの最初に、不透明パスからのＺｆａｒ値を保持してＺｎｅａｒ値を０に設定し、２）Ｚｎｅａｒ（パス開始時に０に初期設定される）とＺｆａｒとの間で最も遠い透明面を識別し、２）新しいＺｎｅａｒ値を決定し、３）パスの最後に、この最も遠い透明面をパイプラインに送り込む。
【０７６４】  ｃ）後続のパス（第２透明パスなど）が次のことを行う、即ち、１）パスの最初に、Ｚｆａｒ値を先のパスからのＺｎｅａｒ値に設定し、Ｚｎｅａｒ値を０に設定し、２）ＺｎｅａｒとＺｆａｒとの間の次に遠い透明面を識別し、３）新しいＺｎｅａｒ値を決定し、４）パスの最後に、この最も遠い透明面をパイプラインに送り込む。
【０７６５】  フロントツーバック順のソート済み透明モードでは、何れの特定タイルに関しても、透明パスの回数は予め選択された最大値に制限されており、例えサンプルの可視透明面の数がそれを上回っていても制限されている。それらのパスは以下のように行うことができる。即ち、
ａ）第１不透明パス（２つの不透明パスがあり、もう１つは最終不透明パス）で、最も前の不透明ジオメトリが識別（Ｚｆａｒとラベル付け）されるが、ｚ値だけはこのパス内で可変なので、このジオメトリはパイプラインへは送り込まれない。このＺｆａｒ値は可視透明層と隠された透明層との間の境界である。このパスは時間順モード・サンプルＦＳＭで行われる。
【０７６６】  ｂ）次のパス、即ち第１透明パスは、最も近い透明ジオメトリをレンダーし、更に可視透明面の数を各サンプル位置でカウントする。このパスは、１）パスの開始時にＺｎｅａｒ値を先のパスからのＺｆａｒ値に設定し、Ｚｆａｒを最大ｚ値に設定し、各サンプル内のＮｕｍＴｒａｎｓｐカウンタをゼロに初期設定し、２）全ての透明ジオメトリをテストし、ＺｎｅａｒとＺｆａｒ両方の前にあるジオメトリを見つけだすことにより最も前の透明面を識別し、３）ジオメトリが処理される際に、新しいＺｆａｒ値を决定するが、Ｚｎｅａｒ値を変更せず、４）Ｚｎｅａｒの前にあるジオメトリに出会ったときにＮｕｍＴｒａｎｓｐを増やすことにより可視透明面の数をカウントし、５）パスの最後に、この最も前の透明面をパイプラインに送り込む。注：概念的には、このパスは普通でないやり方で定義され、その理由は、最後には、ＺｆａｒはＺｎｅａｒより近くなるが、このことにより「Ｚｎｅａｒ値を先のパスから送られたＺｆａｒ値に設定し、Ｚｆａｒを最大ｚ値に設定する」という規則が全透明パスに対し真となるからである。これが紛らわしければ、ＺｎｅａｒとＺｆａｒの定義を取り替えることもできるが、そうなると第２透明パスの定義も変わってくる。
【０７６７】  ｃ）これに続く各透明パスは、順次、遠いジオメトリを決め、透明パスの最大数はＭａｘＴｒａｎｓｐＰａｓｓｅｓパラメータにより規定される。これらのパスはそれぞれ、１）パスの開始時に、Ｚｎｅａｒ値を先のパスからのＺｆａｒ値に設定し、Ｚｆａｒを最大ｚ値に設定し、各サンプル内のＮｕｍＴｒａｎｓｐカウンタは変更せず、２）全ての透明ジオメトリをテストし、ＺｎｅａｒとＺｆａｒとの間にある最も前のジオメトリを見つけ出すことにより、次に最も前にある透明面を識別するが、全ての可視透明層がこのサンプルに対し見つけ出されていれば（即ち、ＮｕｍＴｒａｎｓｐＰａｓｓ＞ＮｕｍＴｒａｎｓｐ）全ての透明ジオメトリを捨て、３）ジオメトリが処理される際に、新しいＺｆａｒ値を決定するが、Ｚｎｅａｒ値を変更せず、４）パスの最後に、この二番目に最も前にある透明面をパイプラインに送り込む。
【０７６８】  ｄ）最終不透明パスでは、最も前の不透明ジオメトリが再び識別されるが、今度はこのジオメトリがパイプラインに送り込まれる。このパスは、１）パスの開始時に、Ｚｆａｒを最大ｚ値に設定（Ｚｎｅａｒは使用されない）し、各サンプル内のＮｕｍＴｒａｎｓｐカウンタは変更せず、２）全ての透明ジオメトリをテストし、時間順モード・サンプルＦＳＭを使って最も前のジオメトリを識別し、３）ジオメトリが処理される際に、新しいＺｆａｒ値を決定するが、ＳｋｉｐＯｐａｑｕｅｌｆＭａｘＴｒａｎｓｐが真であり、且つ透明層の最大数が見つかって（即ち、ＭａｘＴｒａｎｓｐＰａｓｓ＝ＮｕｍＴｒａｎｓｐ）いれば、そのジオメトリを捨て、４）パスの最後に、この最も前の不透明面をパイプラインに送り込む。
【０７６９】  フロントツーバック順のソート済み透明モードでは、ＣＵＬの効率が高められる（即ち、パイプラインに送り込まれるフラグメントが少なくなる）が、特に透明面に関して可視デプス・コンプレキシティが多い場合には顕著である。更に、これは、ユーザーが、最も前の不透明面の前にあるものではなく、最も前のＮ個の透明面を認識することができるようになるので、イメージの質を高めることになる。
【０７７０】  スタンプ部メモリ・ブロック９０１８は、タイル内の各スタンプ毎にＶＳＰカバレッジ・マスクを含んでいる。１つのスタンプが所有できるＶＳＰの最大数は１６である。ＶＳＰマスクは、新しいＶＳＰがＺカル９０１２から入ってくるときに、更新されるか又は早期ディスパッチされなければならない。スタンプ部マスク・ユニットは、ＳｅｎｄＮｅｗ、ＫｅｅｐＯｌｄ、ＳｅｎｄＯｌｄの制御ビット次第で、マスク更新又はディスパッチを厳密に実行する。新しいＶＳＰは、スタンプ内の全ての古いＶＳＰのカバレッジ・マスクを修正する可能性もあるので、更新は、スタンプ内の最大１６個の古いＶＳＰに対し同時に行われなければならない。スタンプ部データ・ユニット９０１６は、カラー・ポインタに限定はしないがこれを含むＶＳＰに関係する他の情報を含んでいる。更に、スタンプ部データ・メモリは、タイル内に含まれる全てのＶＳＰに関するデータを保持する必要がある。新しいＶＳＰが作成されるときは必ず、その関連データがスタンプ部データ・メモリに記憶されなければならない。更に、古いＶＳＰがディスパッチされるときには必ず、そのデータがスタンプ部データ・メモリから検索されなければならない。
カル・ブロックの詳細な説明
図１４はカル・ブロック９０００の詳細なブロック線図を示す。カル・ブロック９０００は、インプットＦＩＦＯ９０５０、ＭＣＣＡＭカル９００２、サブラスタライザ９０５２、列選択９０５４、ＭＣＣＡＭ更新９０５９、サンプルＺバッファ９０５５、新しいＶＳＰキュー９０５８、スタンプ部メモリ・マスク９０６０及び９０６２、スタンプ部メモリ・データユニット９０６４及び９０６６、ディスパッチ・キュー９０６８及び９０７０、ディスパッチ・ロジック９０７２から構成されている。
モード及びデータ・パケット
カル構成要素のオペレーションは、カル・ブロックに受信されるパケットにより決定される。以下に、モードパケットについて説明する。
【０７７１】  セットアップ・アウトプット・クリア・パケットは、あるタイプのバッファ・クリアが実行されるべきことを示す。しかし、ユーザー・フレームの最初に行われる（且つ、シザー・テストを受けない）バッファ・クリアは、開始タイル・パケット内に含まれる。
【０７７２】  セットアップ・アウトプット・カル・パケットは、モード・ビットのパケットである。このパケットは、１）ＭＣＣＡＭカル及びＺカル・プロセスを使用可能／使用禁止にするためのビットと、２）カル・ブロックからの全てのＶＳＰのフラッシュを生じさせるビットであるＣｕｌｌＦｌｕｓｈＡｌｌと、３）３つのタイプのプリミティブのアンチエイリアシングを使用禁止にするビットであるＡｌｉａｓＰｏｌｙｓ、ＡｌｉａｓＬｉｎｅｓ、ＡｌｉａｓＰｏｉｎｔｓとを含んでいる。
【０７７３】  セットアップ・アウトプット開始フレーム・パケットは、新しいフレームが開始していることをカルに通知する。次のパケットはソート・アウトプット開始タイル・パケットであろう。セットアップ・アウトプット開始フレーム・パケットは、パイプラインを通して必要な全てのフレーム毎情報を含んでいる。
【０７７４】  セットアップ・アウトプット終了フレーム・パケットは、フレームが終了し、現在のタイルのインプットが完了したことを示す。
【０７７５】  セットアップ・アウトプット開始タイル・パケットは、カル・ブロックに、現在のタイルが終了し、処理されたデータがパイプラインへフラッシュ・ダウンされるべきであることを通知する。又同時に、カル・ブロックは新しいタイルのプリミティブの処理を開始すべきである。パイプラインがソート済み透明モードであるためにタイルが繰り返されるようなら、別のセットアップ・アウトプット開始タイル・パケットが必要である。従って、特定のタイルが１個の不透明パスと４個の透明パスを必要とする場合は、合計５個の開始タイル・パケットがセットアップ・ブロックから送られる。このパケットは、ウィンドウ内でのタイル位置を規定する。
【０７７６】  セットアップ・アウトプット中間パケットは、フレーム間（従って中間）で、つまりタイル間だけで発生する可能性がある。カルはこのパケットをブラック・ボックスとして処理し、それをパイプラインに送り込むだけである。このパケットは、１４４ビットのパラメータＴｗｅｅｎＤａｔａだけを有している。図Ｅ１５に示されているように、カル・ブロックは、モード・パケットに加えてセットアップ・アウトプット・プリミティブ・パケットも受信する。
【０７７７】  各セットアップ・アウトプット・プリミティブ・パケットは、タイル毎ベースで、三角形、ライン、ポイントの何れかについて記述する。厳密には、セットアップ・アウトプット・プリミティブ・パケット内のデータ・フィールドは、プリミティブ・タイプ（三角形、ライン又はポイント）を示すビットを含んでいる。残りのジオメトリ・データ・フィールドの翻訳はプリミティブ・タイプ次第である。
【０７７８】  インプット・パケットがセットアップ・アウトプット・プリミティブ・パケットである場合、ＰｒｉｍＴｙｐｅパラメータはプリミティブ・タイプ（三角形、ライン又はポイント）を示す。プリミティブの空間位置（導関数等を含む）は統合的記述を使って規定される。つまり、パケットはプリミティブを（スクリーンとは整列していない）四辺形として記述しており、プリミティブが四辺形か三角形かポイントであるかは問題ではなく、三角形及びポイントは四辺形の退化したケースとして処理される。パケットはカラー・ポインタを含んでおり、モード・インジェクション・ユニットで用いられる。パケットは幾つかのモード・ビットも含んでおり、その多くはプリミティブ・ベースでプリミティブ上の状態を変えることができる。以下の、ＣｕｌｌＦｌｕｓｈＯｖｅｒｌａｐ、ＤｏＡｌｐｈａＴｅｓｔ、ＤｏＡＢｌｅｎｄ、ＤｅｐｔｈＦｕｎｃ、ＤｅｐｔｈＴｅｓｔＥｎａｂｌｅｄ、ＤｅｐｔｈＴｅｓｔＭａｓｋｓ、ＮｏＣｏｌｏｒは「モードビット」であると見なされ、Ｚカル９０１２内の状態マシンへ入力される。
【０７７９】  カルの構成要素については、以下の節でより詳しく説明する。
インプットＦＩＦＯ
図Ｅ１６は、図Ｅ１４の詳細なブロック線図に示されているカル・ブロック９０００の構成要素を使った保存性陰面除去法のフローチャートを示す。インプットＦＩＦＯユニット９０５０は、セットアップブロック８０００とインターフェースを取っている。インプットＦＩＦＯ９０５０はセットアップからデータ・パケットを受信し、ステップ９１６０で、各パケットをキュー内に記憶する。必要なＦＩＦＯメモリ位置の数は、約１６から約３２の間であり、ある実施例では、デプスは１６と仮定されている。
ＭＣＣＡＭカル
ＭＣＣＡＭカル・ユニット９００２は、可視かもしれない境界画定ボックス内のスタンプのセットを決定するために、ＭＣＣＡＭアレイ９００３を用いてプリミティブの境界画定ボックス上で空間問い合わせを実行する。セットアップ・ブロック８０００は、各プリミティブ毎に境界画定ボックスを決定し、現在のタイルの内側のプリミティブの、ＺＭｉｎと称される最小ｚ値を決定する。図Ｅ１７Ａは、ＭＣＣＡＭ内のプリミティブ９２５４と境界画定ボックス９２５２とを含むサンプル・タイルを示している。ＭＣＣＡＭカル９００２は、ＺＭｉｎを用いてｚ比較を実行する。ＭＣＣＡＭカル９００２は、既に処理済みの全てのプリミティブのスタンプ毎の最大ｚ値を記憶する。次にＭＣＣＡＭカル９００２は、プリミティブに関するＺＭｉｎを全スタンプに関するＺＭａｘｅｓと並列に比較する。ＭＣＣＡＭカルは、この比較に基づいて、ａ）シンプルな境界画定ボックス内の全スタンプに基づいてプリミティブ全体が隠されているかどうか、又はｂ）その境界画定ボックス内で可視の可能性のあるのはどのスタンプかを決定（ステップ９１６４）する。図Ｅ１７Ｂはタイル内の各スタンプに対する最大ｚ値（ＺＭａｘ）を示す。図Ｅ１７Ｃは比較結果を示す。ステップ９１６６で、ＺＭｉｎ＝＜ＺＭａｘであるスタンプは１で示されている。これらは可視の可能性があるスタンプである。更にＭＣＣＡＭカルは、ステップ９１６８で、ＺＭｉｎ＝＜ＺＭａｘであるスタンプを有する各行を識別する。これらはスタンプ選択ロジック・ユニット９００８が処理しなければならない行である。スタンプ選択ロジック・ユニット９００８は、ゼロと識別された行をスキップする。
【０７８０】  ＭＣＣＡＭカルは、インプットＦＩＦＯ９０５０から送られてくるサイクル毎に１つのプリミティブを処理することができる。ＦＩＦＯが空でなく、且つ、除去された最後のプリミティブがＭＣＣＡＭカルにより決定された通り完全に隠されるか、又は最後のプリミティブがサブラスタライザ・ユニット９０５２により処理されているかの何れかであるときに、ＦＩＦＯからの読み取りオペレーションが発生し。言い換えれば、ＭＣＣＡＭカルは、サブラスタライザに「先行して作業」しない。むしろＭＣＣＡＭカルは、サブラスタライザが処理しなければならない次のプリミティブを手に入れるするだけで、後は待機する。
【０７８１】  ある代替実施例では、カル・ブロック９０００は、ＭＣＣＡＭカルユニット９００２を含んでいない。この実施例では、スタンプ選択ロジック・ユニット９００８が全ての行を処理する。
スタンプ選択ロジック内のサブラスタライザ
サブラスタライザ９０５２は、エッジウォーキング（実際に、計算は「ウォーキング」という用語が暗示する通り、反復型ではない）を行うユニットである。サブラスタライザは、各サイクル毎にＭＣＣＡＭカル９００２からパケットを手に入れる。カル・ブロックに受信されるパケットのタイプの１つは、図Ｅ１５に示される、セットアップ・アウトプット・プリミティブ・パケットである。セットアップ・アウトプット・プリミティブ・パケットは、行数と、各行内の潜在的な可視スタンプを示す、ＭＣＣＡＭカル９００２により生成された行マスクとを含んでいる。更にサブラスタライザ９０５２は、少なくとも１つのサンプルポイントを含む各サブラスタ・ライン内のプリミティブの最左位置及び最右位置、ＸｌｅｆｔＳｕｂＳｉ及びＸｒｉｇｈｔＳｕｂＳｉを計算するのに必要な頂点データ及び傾斜データを受信する。サブラスタライザ９０５２は、プリミティブが三角形かラインかポイントであるかを決定するために、セットアップ・アウトプット・プリミティブ・パケット内のプリミティブ・タイプ・フィールドをデコードし、この情報に基づいて、サブラスタライザ９０５２はプリミティブがアンチエイリアスドであるか否かを決定する。図Ｅ１８において、ＭＣＣＡＭカルが（行選択ビット９２７１を使って）可視の可能性があることを示しているスタンプの各行に対し、サプラスタライザ９０５２は、スタンプ毎に１６個のサンプルがある好適な実施例で、ステップ９１７０において、スタンプ内の各サンプル・ポイント毎にＸｌｅｆｔＳｕｂＳｉ及びＸｒｉｇｈｔＳｕｂＳｉを同時に計算する。ＸｌｅｆｔＳｕｂＳｉ及びＸｒｉｇｈｔＳｕｂＳｉの各対は、プリミティブがタッチする行内のスタンプセットを定義し、これはサンプル行マスクと呼ばれる。例えば、図Ｅ１９は、ＸｌｅｆｔＳｕｂＳｉとＸｒｉｇｈｔＳｕｂＳｉのセットを示している。
【０７８２】  図Ｅ１８において、プリミティブがタッチする、可視の可能性がある行内の各スタンプは、タイル９２７０に示されているように、対応するスタンプ・カバレッジ・ビット９２７２を「１」に設定することにより表示されている。サブラスタライザ９０５２は、プリミティブがタッチするスタンプのセットを手に入れるため、論理上、１６個の行マスクの論理和をとる。次にサブラスタライザ９０５２は、タイル９２７６に示されているように、タッチされているスタンプとスタンプ選択ビット９２７８との論理積をとり、ステップ９１７２で、タイル９２８０に示されている、タッチされているスタンプのリストを形成する。サブラスタライザは各スタンプ行に関して要求をＭＣＣＡＭカルへ送り、可視の可能性があるスタンプのリストをＭＣＣＡＭカルから受信する。可視スタンプ・リストは、ステップ９１７４で、スタンプ行内の最終的な可視の可能性があるスタンプのセットを決定するため、タッチされているスタンプのリストと組み合わせられる。各行毎に、可視スタンプ・セットが、スタンプ選択ロジック・ユニット９００８の列選択ブロック９０５４に送られる。サブラスタライザは、１サイクルに１行のスタンプを処理できる。プリミティブが２行以上のスタンプを含んでいる場合は、サブラスタライザはプリミティブを処理するために２サイクル以上をとるので、インプットＦＩＦＯからのプリミティブ除去をストールするようにＭＣＣＡＭに要求する。列選択ユニットに要求されれば、サブラスタライザ自体がストールすることもある。
【０７８３】  図Ｅ２０は、４個のピクセル９２９２、９２９３、９２９４、９２９５を含むスタンプ９２９１を示している。各ピクセルは８×８のサブラスター・グリッドに分割されている。図Ｅ２０のグリッドは、各サプラスター・ステップの中心点に配置されているグリッド・ラインを示している。ある実施例では、数字を円で囲んで表された（例▲１▼）図Ｅ２０のサンプル０−１５で示されているように、サンプルはユニット・グリッドの中心に配置されている。このように、サブラスター・ステップの半分だけグリッドを外す方法でサンプルを配置すると、サンプルに多角形の辺上で適用するという複雑な視認性規則を回避することができる。この実施例では、多角形はサブラスター・ライン又はピクセルの境界のエッジに向かうように定義できるが、サンプルはサブラスター・グリッドから離れた位置に限定される。別の実施例では、隣接するピクセル内の２つのサンプルが同じサブラスター上に配置されている。このことは、ＸｌｅｆｔＳｕｂＳｉ及びＸｒｉｇｈｔＳｕｂＳｉの数を２の因数で低減することにより、サンプル・プロセッシングを簡単にする。
スタンプ選択ロジック内の列選択
図Ｅ１４に示す列選択ユニット９０５４は、各クロック・サイクルで処理すべきスタンプをカルユニット９０１２に通知する。１つのスタンプ行が２つ以上の可視の可能性があるスタンプを含んでいる場合、列選択ユニットはサブラスタライザがストールすることを要求する。
Ｚカル
Ｚカル・ユニット９０１２は、図Ｅ１４に示すように、サンプルＺバッファ・ユニット９０５５及びＺカル・サンプル状態マシン９０５７を含んでいる。サンプルＺバッファ・ユニット９０５５は、各サンプル毎のｚ値を含む、タイル内の各サンプルに関する全てのデータと、全てのサンプルＦＳＭ状態ビットとを記憶する。Ｚカル・サンプル状態マシン９０５７が１サイクル毎に１スタンプを処理できるようにするために、Ｚカル・ユニット９０１２は、スタンプ内の１６個のサンプルポイント全てに対するｚ値に並行してアクセスし、更にそれらのサンプル・ポイントにおける新しいプリミティブのｚ値を並行して計算する。
【０７８４】  Ｚカル・ユニット９０１２は、サンプル・ポイントのｘ座標であるＸｓａｍｐｌｅをサブラスタライザで計算されたＸｌｅｆｔＳｕｂＳｉ及びＸｒｉｇｈｔＳｕｂＳｉと比較することにより、プリミティブが特定のサンプル・ポイントｉをカバーするかどうかを決定する。サンプルｉは、ステップ９１７８で、ＸｌｅｆｔＳｕｂＳｉ＝＜Ｘｓａｍｐｌｅ＜ＸｒｉｇｈｔＳｕｂＳｉである場合に限ってカバーされる。次にＺカル・ユニット９０１２は、ステップ９１８０で、それらのサンプル・ポイントでのプリミティブのｚ値を計算し、ステップ９１８２で、結果として得たｚ値を、そのスタンプに関してサンプル２バッファに記憶されている対応するｚ値と比較する。一般的に、サンプル・ポイントのｚ値がＺバッファ内のｚ値より小さければ、サンプル・ポイントは可視であると見なされる。しかし、ＡＰＩは、プログラマーが比較機能（＞、＞＝、＜、＝＜、常に、決して−ない）を指定できるようにする。更に２比較は、アルファ・テスト又はブレンディングが実施されるかどうか、パイプラインがソート済み透明モードであるかどうかの影響を受けるようにもできる。
【０７８５】  Ｚカル・サンプル状態マシン９０５７は、スタンプ内の各サンプル毎にサンプル毎のＦＳＭを含んでいる。各スタンプが１６個のサンプルで構成されているある実施例では、１６個のＺカル・サンプル状態マシン９０５７があり、それぞれが、ｚ値と、それが制御するＺバッファ内のサンプルに対するサンプル状態とを如何に更新するか、サンプル・ポイントと重なっている先に処理されたＶＳＰに何れのアクションを取るか、を並行して決定する。更に、ソート済み透明モードでは、Ｚカル・サンプル状態マシンは、別のパスに透明プリミティブを送るかどうかを決定する。
【０７８６】  サンプル・ポイントにおけるプリミティブのｚ値と、そのスタンプに関してサンプルＺバッファ内に記憶されている対応するｚ値とを比較した結果に基づき、現在のカルモード・ビットと、サンプル状態マシンであるサンプルＺバッファの状態が、ステップ９１８４で更新される。ステップ９１８４で、１６個のＺカル・サンプル状態マシンは各サンプル毎に、ＫｅｅｐＯｌｄ、ＳｅｎｄＯｌｄ、ＮｅｗＶＳＰＭａｓｋ、ＳｅｎｄＮｅＷの制御ビットを出力して、サンプルが如何に処理されるかを示す。ステップ９１８８で、ＮｅｗＶＳＰＭａｓｋビットのセット（１６個）は、新しいスタンプ部（ＳＰ）カバレッジ・マスクを構成する。新しいスタンプ部は、新しいＶＳＰキューへディスパッチされる。プリミティブがスタンプ内で全く可視でないイベント（全ＮｅｗＶＳＰＭａｓｋビットが偽）では、新しいＶＳＰキューへは何も送られない。２つ以上のサンプルが最終サンプル位置の最終値に影響を及ぼす可能性がある場合、ステップ９１９２で、サンプル位置に対するサンプルを含むスタンプ部は、早期ディスパッチされる。スタンプ内の１６個のサンプルの全制御ビットは、スタンプ部メモリ９０１８に並行して供給される。
【０７８７】  サンプルは、例えばスタンプ内の現在可視である全てのサンプルを備えているグループの一部として、ＶＳＰでパイプラインに送り込まれる。スタンプ内のあるサンプルが（早期ディスパッチ又はエンドオブタイル・ディスパッチの何れかで）ディスパッチされる場合、同じスタンプ及び同じプリミティブ内の別のサンプルもＶＳＰとしてディスパッチされる。これにより更にサンプルがパイプラインに送り込まれると、一般的にはカラー計算の量の正味が低減する。これは、ピクセル内の空間的コヒーレンス（即ち、同一ピクセル内のサンプルは、共に可視であるか又は共に可視でないか、という傾向にある）と、多角形のエッジが、アルファ・テスト、カラー・テスト、ステンシル・テスト及び／又はアルファ・ブレンディングによって、そうでなければ空間的にコヒーレントなスタンプを分割する可能性があるという傾向とによるものである。即ち、追加のサンプルを、それらがはっきり分かるほどには計算負荷を増やさないときに、パイプラインに送り込むのは、送る必要のあるＶＳＰの総数を減らしても埋め合わせできない。
【０７８８】  図２１Ａ−Ｄは、Ｚカル９０１２の実施例のオペレーション例を示している。図２１Ａで示されているように、プリミティブ９３１２は、タイル９３１０内の第１プリミティブである。従ってＺカル９０１２は、プリミティブがタッチする全てのｚ値を更新し、３５個のスタンプ部をスタンプ部メモリ９０１８に記憶する。図Ｅ２１Ｂでは、第２プリミティブ９３２２がタイル９３１０に加えられている。プリミティブ９３２２のｚ値はプリミティブ９３１２のｚ値よりも低い。Ｚカル９０１２は、プリミティブ９３２２がタッチする２７個のスタンプを処理する。図Ｅ２１Ｃは、プリミティブ９３２２が処理された後でスタンプ部メモリ９０１８に記憶される５４個のスタンプ部を示している。５４個のスタンプ部とは、プリミティブ９３１２及び９３２２がタッチするスタンプの合計から、プリミティブ９３１２から完全に除去される８個のスタンプ部を差し引いたものである。図Ｅ２１Ｄの領域９３３２は、除去された８個のスタンプ部を示しており、これは全て、プリミティブ９３１２がタッチするスタンプ部に、低いｚ値を有するプリミティブ９３２２もタッチしているスタンプ部である。
【０７８９】  ある実施例では、Ｚカル９０１２は、様々な状態ビットと共に、各サンプル毎に１つのｚ値とを保守する。別の実施例では、Ｚカル９０１２は各サンプル毎に２つのＺ値を保守し、第２のｚ値は、保存性陰面除去プロセスの効率を向上させる。Ｚカル９０１２はスタンプ部メモリ９０１８を制御するが、ｚ値及び状態ビットはスタンプ部とは関係付けられない。スタンプ部メモリ９０１８は、スタンプ毎に１６個のスタンプ部、タイル毎にすれば合計２５６個のスタンプ部を保守することができる。
【０７９０】  Ｚカル９０１２は、スタンプが如何に処理されるかを制御するスタンプ部メモリ９０１８へ４ビットの制御信号（ＳｅｎｄＮｅｗ、ＫｅｅｐＯｌｄ、ＳｅｎｄＯｌｄ、ＮｅｗＶＳＰＭａｓｋ）を出力する。ＫｅｅｐＯｌｄは、スタンプ部メモリ９０１８内の対応するサンプルが無効ではないことを示す。即ち、サンプルがスタンプ部メモリ９０１８内のスタンプ部の一部分である場合、そのサンプルは捨てられない。ＳｅｎｄＯｌｄは早期ディスパッチ・インジケータである。ＳｅｎｄＯｌｄビットに対応するサンプルがスタンプ部メモリ９０１８内のスタンプ部に属している場合、このスタンプ部はパイプラインへ送り込まれる。ＳｅｎｄＯｌｄは、ＫｅｅｐＯｌｄが表明された場合にだけ表明される。Ｚカル９０１２プロセスがこのサンプルが（プロセッシングのその時点では）可視であると判定し、スタンプ部メモリ９０１８が信号を受信するときに行うことになるが、新しいプリミティブのために新しいスタンプ部を作成する必要があると判定した場合に、ＮｅｗＶＳＰＭａｓｋが表明される。Ｚカル９０１２プロセスが、サンプルは（プロセッシングのその時点では）可視であり、パイプラインに送り込む必要があると判定した場合に、ＳｅｎｄＮｅｗが表明される。ＳｅｎｄＮｅｗは、新しいプリミティブ内のスタンプ部の早期ディスパッチを引き起こす。
【０７９１】  図Ｅ２２は、サンプルがＺカル９０１２により如何に処理されるかという例を示している。プリミティブ９３５２は、プリミティブ９３５４の前にタイル９３５０で処理される。プリミティブ９３５４は、プリミティブ９３５２よりも小さなｚ値を有しているのでプリミティブ９３５２の前にある。Ｚカル９０１２は、楕円形領域９３５６内の７個のサンプルについて、ＫｅｅｐＯｌｄ制御ビットを０に設定し、ＮｅｗＶＳＰＭａｓｋ制御ビットを１に設定する。
【０７９２】  図Ｅ２３Ａ−Ｄは、早期ディスパッチの例を示している。早期ディスパッチとは、タイル内の全ジオメトリが処理される前にパイプラインにジオメトリを送り込むことである。ソート済み透明モードでは、早期ディスパッチは使用しない。先ず、図Ｅ２３Ａに示されている単一のプリミティブ９３７２がタイル９３７０内で処理される。プリミティブ９３７０は３５個のスタンプにタッチしており、これらはスタンプ部メモリ９０１８に記憶される。次にｚ値が小さい第２プリミティブ９３８２が加えられ、モード・ビットＤｏＡＢｌｅｎｄが表明される。ＤｏＡＢｌｅｎｄモード・ビットは、重なり合っているスタンプ部からのカラーがブレンドされるべきであるということを示す。次にＺカル９０１２は、プリミティブ９３８２がタッチする２７個のスタンプを処理する。Ｚカル９０１２は、Ｎ個までのプリミティブからのサンプルが各スタンプに記憶できるように設計することができる。ある実施例では、唯１つのプリミティブからのサンプルが各スタンプ毎に記憶される。図Ｅ２３Ｃは、プリミティブ９３８２が処理された後の、スタンプ部メモリ９０１８内のスタンプ部を示す。図Ｅ２３Ｄは、スタンプ部のｚ値がプリミティブ９３８２からの小さいｚ値に置き換えられたので、プリミティブ９３７２から早期ディスパッチされる、領域９３７４がタッチしている２０個の可視スタンプ部を示している。
【０７９３】  図Ｅ２４は、早期ディスパッチ・プロセッシングのサンプル・レベルの例を示す。スタンプ９３９０は、共に図Ｅ２３Ｂに示されている、プリミティブ９３８２の一部とプリミティブ９３７２の一部とを含んでいる。領域９３９２内のサンプルは全て、プリミティブ９３７２よりｚ値が小さいプリミティブ９３８２がタッチしている。従って、Ｚカル９０１２は、これら７個のサンプルに制御信号ＳｅｎｄＯｌｄを出力する。ある実施例では、Ｚカル９０１２がスタンプ内のあるサンプルをパイプラインに送り込むことを決定すると、Ｚカル９０１２は、空間コヒーレンシーが保存できるように、そのスタンプ内の全サンプルをパイプラインに送り込む。更にこのことは、パイプラインに送り込まれるフラグメントの数を最小にする。別の実施例では、この方法はピクセル・レベルで適用され、Ｚカル９０１２がピクセル内の何れかのサンプルをパイプラインに送り込むべきであると判断すると、そのピクセル内の全サンプルがパイプラインに送り込まれる。
【０７９４】  シーン内のすべてが不透明な面であるカル・プロセスでは、全ての面が処理された後で、可視のスタンプ部だけがスタンプ部メモリ９０１８に残される。次に既知の可視スタンプ部がパイプラインに送り込まれる。しかし、早期ディスパッチが起こると、直ぐに早期ディスパッチ・スタンプ部がパイプラインに送り込まれる。
【０７９５】  各スタンプ毎に、Ｚｒｅｆと呼ばれる基準が生成される。ある実施例では、Ｚｒｅｆがスタンプの中心に配置される。Ｚｒｅｆ点における値∂ｚ／∂ｘ及び∂ｚ／∂ｙも計算される。これら３つの値はパイプラインで、ピクセル・ブロック１５０００へ送られる。ピクセル・ブロック１５０００は、最終２テストを実施する。ピクセル・ブロック１５０００は、最終２テストの中で、以下の式を使って、Ｚｒｅｆ値と値∂ｚ／∂ｘ及び∂ｚ／∂ｙ値を用い、各サンプル毎に、正確に等価なｚ値を再度計算する。
【０７９６】
【数５９】
2004272928.tif 000084
全スタンプ内の１６個のｚ値をパイプラインに送り込むよりも、ｚ値を計算する方が、使用する帯域幅を大幅に低減できる。更に、可視の可能性があるスタンプのｚ値だけが決定される。Ｚカル９０１２とピクセル・ブロック１５０００とが同一のｚ値を確実に用いるようにするために、Ｚカル９０１２は、ピクセル・ブロックが各スタンプ毎にｚ値を決め、何らの人工物も導入するのを避けるようにするのと同じ計算を実行する。計算効率を高めるために、少数のビットを使ってデルタｘ値及びデルタｙ値を表すことができるが、それは、距離がピクセルのほんの一部だからである。例えば、ある実施例では、２４ビットの導関数と４ビットのデルタ値が用いられる。
ＭＣＣＡＭ
図Ｅ１４に示すＭＣＣＡＭ更新ユニット９０５９は、各スタンプ内の１６個のサンプル・ポイントに対する１６個の更新されたｚ値の最大値を決定し、それをＭＣＣＡＭカル・ユニットへ送り、ＭＣＣＡＭアレイ９００３を更新する。
新しいＶＳＰキュー
各クロックサイクル毎に、Ｚカル・ユニット９０１２は、スタンプ部毎に４個の制御ビット（ＫｅｅｐＯｌｄ、ＳｅｎｄＯｌｄ、ＮｅｗＶＳＰＭａｓｋ、ＳｅｎｄＮｅｗ）を４セット生成する。このように、Ｚカル９０１２は、サイクル毎に１つのプリミティブにつき１つのスタンプを処理するが、処理される全スタンプが可視であるわけではなく、可視スタンプ部（ＶＳＰ）だけが新しいＶＳＰキュー９０５８に送られる。従って、新しいＶＳＰキュー９０５８への入力速度は変動する。「理想的な」状況の下では、ＳＰＭマスクと有効ユニット９０６０は、各クロックサイクル毎に新しいスタンプ部を１つ記憶することができる。しかしながら、ＳＰＭマスク及び有効ユニット９０６０は、ＶＳＰ早期ディスパッチが起これば、新しいスタンプ部に多くのクロックを必要とする。ＶＳＰが早期ディスパッチされると、新しいＶＳＰキュー９０５８は新しいスタンプ部を記憶し、Ｚカル９０１２がストールすることなく処理できるようにする。１つの新しいＶＳＰが１６個までの古いＶＳＰのディスパッチを引き起こす可能性があるので、新しいＶＳＰキューからの除去速度も変動する。
【０７９７】  ある実施例では、新しいＶＳＰキュー９０５８は早期ディスパッチと共にしか用いられない。ＳＰＭマスク及び有効ユニットは一度に１つのＶＳＰを扱う。早期ディスパッチが２つ以上のＶＳＰを含む場合、新しいＶＳＰキューは、スタンプ部をＺカル９０１２が使用可能であることを保証する。性能分析によると、一般的には、約４５０個のスタンプが、１個のタイル内でタッチされると予測される。シーンのデプス・コンプレキシティは、シーン内の１つのピクセルがレンダーされなければならない平均回数を表す。デプス・コンプレキシティが２であれば、２２５個のＶＳＰが、タイル毎にＺカル９０１２からアウトプットとして提供されると予測される。従って、平均してスタンプ毎に４個のＶＳＰが予測される。５０個のピクセル・エリアをカバーするようにブレンドされた三角形は、平均して３個のタイルをタッチすることができ、三角形が１個のタイル内でタッチするスタンプの数は８未満のはずである。従って、ある実施例では、新しいＶＳＰキューのデプスは３２になるように設定される。
【０７９８】  Ｚカルユニット９０１２とスタンプ部メモリ９０１８との間の新しいＶＳＰキュー９０５８を通るリンクは、一方向性である。フィードバック・ループを用いないようにすることにより、新しいＶＳＰキュー９０５８は、各サイクル内にサンプルを処理できる。
ＳＰＭマスク及び有効ユニット
アクティブなスタンプ部メモリ（ＳＰＭ）マスクと有効ユニット９０６０は、タイル用ＶＳＰカバレッジ・マスクを記憶する。各ＶＳＰエントリは、有効なＶＳＰがそこに記憶されているかどうかを示す、有効なビットを含んでいる。ＶＳＰに対する有効なビットは、別々のメモリに記憶される。スタンプ部メモリ（ＳＰＭ）マスク及び有効ユニット９０６０は、図Ｅ１４に示すようにダブル・バッファ（即ち、２つのコピー９０６０及び９０６２がある）されている。メモリ・マスク及び有効アクティブ状態ユニット９０６０は、現在のタイルに関するＶＳＰを含み、一方、メモリ・マスク及び有効ディスパッチ状態ユニット・ページ９０６２は、先のタイルからのＶＳＰ（現在ディスパッチされている）を含んでいる。新しいＶＳＰが新しいＶＳＰキューから除去される際に、アクティブ状態ＳＰＭマスク及び有効ユニット９０６０は、既にそのマスク・メモリ内に存在しているＶＳＰに関するＶＳＰマスクを更新し、新しいＶＳＰをメモリ・コンテンツに加える。早期ディスパッチを必要とするカラー・ブレンディング又は別の条件が発生すると、アクティブ状態ＳＰＭマスク及び有効ユニットは、ＶＳＰをアクティブＳＰＭデータユニット９０６４経由でディスパッチ・キューへディスパッチする。マスク更新又は早期ディスパッチで実行されるオペレーションは、Ｚカル９０１２で生成されるＫｅｅｐＯｌｄ、ＳｅｎｄＯｌｄ，ＳｅｎｄＮｅｗ、ＮｅｗＶＳＰＭａｓｋ制御ビットにより制御される。ソート済み透明モードでは、ＳｅｎｄＯｌｄとＳｅｎｄＮｅｗマスクビットは使われない。ＶＳＰカバレッジ・マスクは互いに排他的であるので、新しいＶＳＰが特定のカバレッジ・マスク・ビットをターン・オンした場合は、スタンプ内で先に処理された全てのＶＳＰに対応するビットはターン・オフされなければならない。
【０７９９】  アクティブからディスパッチへの状態移行及びその逆移行はモード・パケットにより制御される。タイルの終りを信号で伝えているパケット（開始タイル、終了フレーム、バッファ・クリア、又はＣｕｌｌＦｌｕｓｈＡｌｌが真にセットされているカル・パケット）を受信すると、アクティブ状態のスタンプ部メモリがディスパッチ状態へ切り替わったり、逆に切り替わったりする。ディスパッチ状態におけるページは、各スタンプを通って巡り、全てのＶＳＰをＳＰＭデータ・ユニットへ送り、次にＳＰＭデータ・ユニットはそれをディスパッチ・キューへ送る。代替実施例では、スタンプ部メモリ・マスク及び有効ユニット９０６０は、３つにバッファされている。
ＳＰＭデータ
アクティブなスタンプ部メモリ・データ・ユニット９０６４は、タイル内の全ＶＳＰに対するＺｓｔａｍｐ、ｄｚ／ｄｘ、ｄｚ／ｄｙ及びカラー・ポインタを記憶する。スタンプ部メモリ・データ・ユニットも、ダブルバッファされる。ＳＰＭマスク及び有効ユニット９０６０は、新しいＶＳＰ情報をＳＰＭデータ・ユニット９０６４へ送る。ＶＳＰ情報は、ＳＰＭデータユニット９０６４に、新しいＶＳＰを送るか又は新しいＶＳＰをそのメモリへセーブするかの何れかを命令する制御信号を含んでいる。新しいＶＳＰをセーブしなければならない場合、ＳＰＭマスク及び有効ユニットの制御信号は、１６個の可能性のあるスロットの中で新しいＶＳＰが占めるべき位置も決定する。更に、早期ディスパッチの場合には、ＳＰＭデータ・ユニットも、古いＶＳＰ位置のリストと、早期ディスパッチを必要とする関連ＶＳＰマスクとを入手する。ＳＰＭデータ・ユニットは、最初に、ディスパッチされなければならない古いＶＳＰがあるかどうかを見るためにチェックする。ＳＰＭデータ・ユニットは、何れかの古いＶＳＰを見つけたら、ＶＳＰデータをそのメモリから読み取り、ＶＳＰデータをＳＰＭマスク及び有効ユニットから送られたＶＳＰマスクと併合し、古いＶＳＰをディスパッチ・キューへ入れる。次に、ＳＰＭデータ・ユニットは、新しいＶＳＰも送るべきかどうかをチェックし、肯定の場合、新しいＶＳＰデータをディスパッチ・キュー９０６８へ送る。新しいＶＳＰを送るべきでない場合、ＳＰＭデータ・ユニットは新しいＶＳＰをそのメモリに書き込む。
ディスパッチ・キュー及びディスパッチ・ロジック
ディスパッチ・ロジック・ユニット９０７２は、一度に１エントリ相当のデータを、２つのＳＰＭディスパッチ・キュー９０６８及び９０７０の１つからモード注入ユニット１００００へ送る。ディスパッチ・ロジック・ユニット９０７２は、最初にディスパッチ状態ＳＰＭユニットからのディスパッチを要求する。ディスパッチ状態ＳＰＭユニットがそのＶＳＰを全て使い尽くした後で、ディスパッチ・ロジック・ユニット９０７２は、アクティブ状態ＳＰＭディスパッチ・キューからのディスパッチを要求する。
アルファ・テスト
アルファ・テストは、所与のピクセルのアルファ値をアルファ基準値と比較する。アルファ基準値は、ピクセルの透明値を示すのによく用いられる。比較のタイプは、例えば比較が、超過オペレーション、未満オペレーション、又は他の演算、代数、論理比較などであるように指定することができる。比較が超過オペレーションである場合は、アルファ・テストをパスするためにはピクセルのアルファ値は基準値よりも大きくなくてはならない。例えば、ピクセルのアルファ値が０・９なら、基準のアルファ値は０．８であり、比較は超過していることになるので、そのピクセルはアルファ・テストをパスする。アルファ・テストをパスしないピクセルは、捨てられる。
【０８００】  アルファ・テストはフラグメント毎のオペレーションであり、ある好適な実施例では、すべてのフラグメントのカラーリング計算、ライティング・オペレーション及びシェーディング・オペレーションが完了した後で、ピクセル・ブロックにより実行される。図Ｅ２５は、ＣＨＳＲ方法でアルファ・テストを用いてサンプルを処理する例を示している。この線図は、ある特定のサンプルに関して異なるｚ標位置にある６個のプリミティブ（Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ）のレンダリングを示しており、以下の順（「デプス・クリア」及び未満に設定されている「デプス・テスト」から開始して）即ち、プリミティブＡ、Ｂ、Ｃ（「アルファ・テスト」使用禁止）、プリミティブＤ（「アルファ・テスト」使用可能）、プリミティブＥ、Ｆ（「アルファ・テスト」使用禁止）の順でレンダーされる。図面から分かるように、ＺＡ＞ＺＣ＞ＺＢ＞ＺＥ＞ＺＤ＞ＺＦであり、２座標の距離はプリミティブＡが最大である。又、アルファ・テストはプリミティブＤでは使用可能であるが他の各プリミティブでは使用禁止となっている。
【０８０１】  アルファ・テストを備えた保存性陰面除去プロセスのもとで、これら６個のプリミティブをレンダーするためのステップを次に記載する。
【０８０２】  ステップ１：デプス・クリアによって、各サンプルの有限状態マシンが以下のようにセットされる。即ち、１）ｚ値は最大値に初期化され、２）プリミティブ情報がクリアされ、３）サンプル状態ビットは、Ｚ値が正確であることを示すように設定される。
【０８０３】  ステップ２：プリミティブＡがサンプルＦＳＭにより処理される時、プリミティブＡは保持（即ち、可視面に関してその時点での最良の推測となる）され、これにより、サンプルＦＳＭは、１）ｚ値ｚＡを「近い」ｚ値として記憶し、２）プリミティブＡをカラー付けするのに必要なプリミティブ情報を記憶し、３）ｚ値（ｚＡ）は正確であるとラベル付けされると記憶する。
【０８０４】  ステップ３：プリミティブＢがサンプルＦＳＭにより処理される時、プリミティブＢは保持（プリミティブＢのｚ値は、プリミティブＡのｚ値未満である）され、これにより、サンプルＦＳＭは、１）ｚ値ｚＢを「近い」ｚ値として記憶（ｚＡは捨てられる）し、２）プリミティブＢをカラー付けするのに必要なプリミティブ情報を記憶（プリミティブＡの情報は捨てられる）し、３）ｚ値（ｚＢ）は正確であるとラベル付けされると記憶する。
【０８０５】  ステップ４：プリミティブＣがサンプルＦＳＭにより処理される時、プリミティブは捨てられ（即ち、可視面に関して、その時点での最良の推測であるプリミティブＢに覆い隠される）、サンプルＦＳＭデータは変更されない。
【０８０６】  ステップ５：プリミティブＤ（アルファ・テスト使用可能）がサンプルＦＳＭにより処理される時、プリミティブＤはプリミティブＢよりも近く、且つプリミティブＤのアルファ値はサンプルＦＳＭが作動する時には知られていないので、プリミティブＤの視認性を判断することはできない。どのプリミティブ（プリミティブＢ又はプリミティブＤの何れか）が可視となるのか決定できないので、プリミティブＢは（プリミティブＢのカラーを作成させるため）パイプラインに早期ディスパッチされ、プリミティブＤは保持される。プリミティブＤのプロセッシングが完了すると、サンプルＦＳＭは、１）「近い」ｚ値はｚＤで「遠い」ｚ値はｚＢであると記憶し、２）プリミティブＤにカラー付けするのに必要なプリミティブ情報（プリミティブＢの情報は早期ディスパッチの下にある）を記憶し、３）ｚ値は（近いｚ値と遠いｚ値の両方が保守されているので）保存性とラベル付けされると記憶する。この状況では、サンプルＦＳＭは、ｚＤよりも近いジオメトリが先のジオメトリを隠し、ｚＢはり遠いジオメトリは隠され、ｚＤとｚＢの間のジオメトリは不確定なので可視であると見なさなければならない（ここで保存性の仮説が設定される）と決定することができる。サンプルＦＳＭが保存性状態であり、且つ有効なプリミティブ情報を含んでいる場合、サンプルＦＳＭ法は、記憶されているプリミティブ情報のデプス値を近いデプス値であると見なす。
【０８０７】  ステップ６：プリミティブＥ（アルファ・テスト使用禁止）がサンプルＦＳＭにより処理される時、プリミティブＥは近いｚ値と遠いｚ値との間（即ちｚＤとｚＢとの間）にあるので、プリミティブＥの視認性を判断することはできない。しかし、プリミティブＥはこの時点ではパイプラインには送り込まれず、それは送り込むと、プリミティブが正しくない時間順でＺバッファされたブレンド（好適な実施例におけるピクセル・ブロックの一部）に到着するからである。従って時間順序を維持するため、プリミティブＤがパイプラインに送り込まれる。プリミティブＥのプロセッシングが完了すると、サンプルＦＳＭは、１）「近い」ｚ値はｚＤで「遠い」ｚ値は値ｚＢである（これらは変更されず、ｚＥは保持されないことに注意）と記憶し、２）プリミティブＥにカラー付けするのに必要なプリミティブ情報（プリミティブＤの情報は、早期ディスパッチ下にある）を記憶し、３）ｚ値は（近いｚ値と遠いｚ値の両方が保守されているので）保存性であるとラベル付けされると記憶する。
【０８０８】  ステップ７：プリミティブＦがサンプルＦＳＭにより処理される時、プリミティブＦが保持（プリミティブＦのｚ値は「近い」ｚ値未満である）され、これによりサンプルＦＳＭは、１）ｚ値ｚＦを「近い」ｚ値として記憶（ｚＤ及びｚＢは捨てられる）し、２）プリミティブＦにカラー付けするのに必要なプリミティブ情報を記憶（プリミティブＥの情報は捨てられる）し、３）ｚ値（ｚＦ）は正確であるとラベル付けされると記憶する。
【０８０９】  ステップ８：タイルにタッチする全ジオメトリの処理が完了した（タイルが無い場合はフレーム内の全ジオメトリの処理が済んだ）時、全ての有効なプリミティブの情報がパイプラインに送り込まれる。このケースでは、プリミティブＦの情報が送られる。これはエンドオブタイル（又はエンドオブフレーム）ディスパッチであり、早期ディスパッチではない。
【０８１０】  つまり、アルファ・テストを含むこのＣＨＳＲプロセスの例では、プリミティブＡからＦまでが処理され、プリミティブＢ、Ｄ、Ｆがパイプラインに送り込まれる。ピクセルブロックは、Ｂ、Ｄ、Ｆの視認性を最終Ｚバッファ・ブレンディング・ステージで決定する。この例では、カラー・プリミティブＦだけがサンプルに用いられる。
ステンシル・テスト
オープンＧＬでは、ステンシル・テストは、（ｘｗ，ｙｗ）位置でステンシル・バッファ内に記憶されている値と基準値との比較結果に基づいて、暫定的にフラグメントを捨てる。複数のステンシル比較機能が使えるようになっており、即ち、ステンシル・テストをパスするかどうかは、ステンシル・バッファ内にマスクされ記憶されている値と比較して基準値が、未満か、以下か、等しいか、以上か、超過しているか、等しくないか、によって決まるように出来ている。オープンＧＬでは、ステンシルテストに合格しなければ、入ってくるフラグメントは捨てられる。基準値と比較値とは、２５６個の異なる値が表示できるように、複数のビット、通常は８ビットを有することができる。オブジェクトがフレーム・バッファ１７０００にレンダーされる時、ステンシル・ビットを有しているタグも、フレーム・バッファに書き込まれる。これらのステンシル・ビットはパイプライン状態の一部である。実行されるステンシル・テストのタイプは、ジオメトリがレンダーされるときに指定することができる。
【０８１１】  ステンシル・ビットは、例えばシャドウのような効果を生成するために、様々なフィルタリング、マスキング又はステンシリング・オペレーションを実行するのに用いられる。特定のフラグメントがフレーム・バッファ内の特定のピクセルに影響を及ぼすことになる場合は、ステンシル・ビットをピクセル情報と共にフレーム・バッファ内に書き込むことができる。
【０８１２】  ＣＨＳＲプロセスの好適な実施例では、全ステンシル・オペレーションが、好適な実施例のピクセル・ブロック内のパイプラインの終り近くで行われる。従って、ステンシル値はフレーム・バッファ内に記憶されるので、結果として、ステンシル値はカル・ブロック内で実行されるＣＨＳＲ法には利用できない。ステンシル値は、ＣＨＳＲプロセスで用いるためにフレーム・バッファから転送することはできるが、それには一般的に、性能を低下させることになる長い待ち時間経路が必要となる。オープンＧＬのようなＡＰＩでは、ステンシル・テストはアルファ・テストの後で実行されるので、アルファ・テストの結果はＣＨＳＲプロセスに知らされない。更に、レンダーは（デプス値が、通常、各フレームの開始時にクリアされるのと対照的に）通常、多くのフレームに亘ってステンシル値を保守する。従って、ＣＨＳＲプロセスは、ステンシル・オペレーションを扱うのに保存性のアプローチを使う。プリミティブがフレーム・バッファ内のステンシル値に影響を及ぼす可能性がある場合、プリミティブ内のＶＳＰは、図Ｅ１５に示されている制御ビットＣｕｌｌＦｌｕｓｈＯｖｅｒｌａｐを表明しているカル・ブロックにより、常にパイプラインに送り込まれる。ステンシル・オペレーションは、カル・ブロック９０００の後でパイプライン・ステージにより実行される（オープンＧＬ仕様書参照）ので、ステンシル値に影響を与える可能性があるプリミティブはパイプラインに送り込まれる。ＣｕｌｌＦｌｕｓｈＯｖｅｒｌａｐ条件は、サンプルＦＳＭを最も保存性のある状態に設定する。一般的に、ステンシル・テストはプリミティブのグループに対して定義される。カル・ブロック９０００が新しいステンシル・テストでプリミティブ内の最初のサンプルを処理する時、制御ソフトウェアはＣｕｌｌＦｌｕｓｈＡｌｌビットを対応するセットアップ・アウトプット・カル・パケットにセットする。ＣｕｌｌＦｌｕｓｈＡｌｌは、カル・ブロックからの全ＶＳＰがピクセル・ブロック１５０００へ送られるようにして、スタンプ部メモリ９０１８内のｚ値をクリアする。ステンシル基準値を変更するとｚバッファされたブレンド（又はピクセル・ブロック）内で「視認性規則」を効果的に変更させことになるので、この「フラッシング」は必要である。ピクセル・ブロック１５０００は、所与のサンプル位置において各サンプルのステンシル値を比較し、どのサンプルが最終的なフレーム・バッファ・カラーに影響を及ぼすかをステンシル・テストに基づいて決定する。例えば、あるサンプル位置に対応するサンプルの１つのグループにとって、ステンシル・ビットが１に等しければ、ステンシル・テストはレンダーである。次にピクセル・ブロック１５０００は、１に等しくないステンシル・ビット値を有するこのグループ内のサンプルに対する各サンプルを捨てる。
【０８１３】  ステンシル・テストを扱うＣＨＳＲプロセス（オープンＧＬ仕様書参照）の例として、４個の特定のサンプル（対応するサンプルＦＳＭをＳＦＳＭ０からＳＦＳＭ３とする）をカバーしている２個のプリミティブ（プリミティブＡ及びＣ）と、それら４個のサンプルの内の２個をカバーしている追加のプリミティブ（プリミティブＢ）とを有する図Ｅ２６の線図について考えてみよう。３個のプリミティブは（デプス・クリア及び未満にセットされたデプス・テストで始まる）以下の順、即ち、プリミティブＡ（ステンシル・テスト使用禁止）、プリミティブＢ（ステンシル・テスト使用可能で、ＳｔｅｎｃｉｌＯｐは「ＲＥＰＬＡＣＥ」に設定される、オープンＧＬ仕様書参照）、プリミティブＣ（ステンシル・テスト使用禁止）の順序でレンダーされる。ステップは次の通りである。
【０８１４】  ステップ１：デプス・クリアは、本例における４個のサンプルＦＳＭそれぞれにおいて、１）ｚ値が最大値に初期設定され、２）プリミティブ情報がクリアされ、３）サンプル状態ビットは、ｚ値が正確であると示すように設定されるようにする。
【０８１５】  ステップ２：プリミティブＡが各サンプルＦＳＭにより処理される時、プリミティブは保持（即ちそれが可視面に関する現時点での最良の推測となる）され、これにより、４個のサンプルＦＳＭは、１）対応するｚ値（それぞれｚＡ０、ｚＡ１、ｚＡ２、ｚＡ３の何れか）を「近い」ｚ値として記憶し、２）プリミティブＡをカラー付けするのに必要なプリミティブ情報を記憶し、３）各サンプルＦＳＭ内のｚ値が正確であるとラベル付けされると記憶する。
【０８１６】  ステップ３：プリミティブＢがサンプルＦＳＭにより処理される時、サンプル１及び２だけが影響を受け、ＳＦＳＭ０及びＳＦＳＭ３が影響を受けないようになり、ＳＦＳＭ１及びＳＦＳＭ２は、１）遠いｚ値が最大値に設定され、近いｚ値が最小値に設定され、２）プリミティブＡ及びＢに関するプリミティブ情報がパイプラインに送り込まれ、３）サンプル状態ビットは、ｚ値が保存性であることを示すように設定される、というように更新される。
【０８１７】  ステップ４：プリミティブＣが各サンプルＦＳＭにより処理される時、プリミティブは保持されるが、サンプルＦＳＭはプリミティブを全て同じ様に取り扱う訳ではない。ＳＦＳＭ０とＳＦＳＭ３では、状態は、１）ｚＣ０とｚＣ３が「近い」ｚ値となる（ｚＡ０及びｚＡ３は捨てられる）ように更新され、２）プリミティブ情報はプリミティブＣをカラー付けするのに必要なプリミティブ情報に更新（プリミティブＡの情報は捨てられる）され、３）ｚ値は正確であるとラベル付けされるように更新される。ＳＦＳＭ１とＳＦＳＭ２では、状態は、１）ｚＣ１とｚＣ２が「遠い」ｚ値となる（近いｚ値は保持される）ように更新され、２）プリミティブ情報はプリミティブＣをカラー付けするのに必要なプリミティブ情報に更新され、３）ｚ値は保存性であるとラベル付けされたまま残される。
【０８１８】  つまり、ステンシル・テストを含むこのＣＨＳＲプロセスの例では、プリミティブＡからＣまでが処理され、全てのプリミティブがパイプラインに送り込まれるが、全てのサンプルが送り込まれる訳ではない。ある好適な実施例では、ピクセル・ブロックは、未解決の視認性問題を処理するために最終的ｚバッファド・ブレンディング・オペレーションを実行する。ＣｕｌｌＦｌｕｓｈＯｖｅｒｌａｐは、選択されたサンプルを「フラッシュ」し他のサンプルは影響を受けないままとしておく、ということを説明するために、多数のサンプルが本例で示されている。
アルファ・ブレンディング
アルファ・ブレンディングは、２個のプリミティブのカラーを１つのカラーに組み合わせるのに用いられる。しかし、このプリミティブは、ｚ値の更新に関して更にデプス・テストを受ける。各サンプルからのカラー寄与量は、アルファ値と呼ばれるサンプルの透明度値次第である。ブレンドは、以下の式
Ｃ＝Ｃｓαｓ＋Ｃｄ（１−αｓ）
に従って実行され、ここに、Ｃは合成結果カラーであり、Ｃｓは入ってくるプリミティブ・サンプルに関するソース・カラーであり、αｓは入ってくるプリミティブ・サンプルのアルファ値であり、Ｃｄは対応するフレーム・バッファ位置での宛先カラーである。アルファ値はプリミティブの頂点で定められ、サンプルのアルファ値は頂点における値から補間される。
【０８１９】  アルファ・ブレンディングを扱うＣＨＳＲプロセスの例として、ある特定のサンプルに関し４個のプリミティブ（プリミティブＡ、Ｂ、Ｃ、Ｄ）を有し（デプス・クリア及び未満に設定されたデプス・テストから始めて開始）以下の順序、即ち、プリミティブＡ（アルファ・ブレンディング使用禁止）、プリミティブＢ及びＣ（アルファ・ブレンディング使用可能）、プリミティブＤ（アルファ・ブレンディング使用禁止）の順序でレンダーされる図Ｅ２７の線図について考えてみよう。ステップは次の通りである。
【０８２０】  ステップ１：デプス・クリアにより、各ＣＨＳＲサンプルＦＳＭでは、１）ｚ値が最大値に初期化され、２）プリミティブ情報がクリアされ、３）サンプル状態ビットは、ｚ値は正確であると示すように設定される。
【０８２１】  ステップ２：プリミティブＡがサンプルＦＳＭにより処理される時、このプリミティブが保持（即ち、可視面に関する現時点での最良の推測となる）され、これによりサンプルＦＳＭは、１）ｚ値ｚＡを「近い」ｚ値として記憶し、２）プリミティブＡをカラー付けするのに必要なプリミティブ情報を記憶し、３）ｚ値は正確であるとラベル付けされると記憶する。
【０８２２】  ステップ３：プリミティブＢがサンプルＦＳＭにより処理される時、このプリミティブが（プリミティブＢのＺ値はプリミティブＡのｚ値未満なので）保持され、これによりサンプルＦＳＭは、１）ｚ値ｚＢを「近い」ｚ値として記憶（ｚＡは捨てられる）し、２）プリミティブＢをカラー付けするのに必要なプリミティブ情報を記憶（プリミティブＡの情報はパイプラインに送り込まれる）し、３）ｚ値（ｚＢ）が正確であるとラベル付けられると記憶する。レンダリング・プロセスでのこの時点では、プリミティブＢのカラーはプリミティブＡのカラーとブレンドされることになるので、プリミティブＡがパイプラインに送り込まれる。このことにより、プリミティブがパイプラインに送り込まれるときのプリミティブの時間順序が保存される。
【０８２３】  ステップ４：プリミティブＣがサンプルＦＳＭにより処理される時、このプリミティブは（可視面に関するその時点での最良の推測であるプリミティブＢにより隠されるので）捨てられ、サンプルＦＳＭデータは変更されない。プリミティブＢ及びＣが透明な面としてレンダーされる必要がある場合は、プリミティブＣはプリミティブＢに隠されることにはならないということに注目されたい。このことは、プリミティブＢがレンダーされている間にデプス・マスクをターン・オフすることにより達成することができるが、透明度ブレンディングを正しく行うには、面を、フロントツーバックか又はバックツーフロントの何れかの順序でブレンドしなければならない。
【０８２４】  デプス・マスク（オープンＧＬ仕様書参照）が使用禁止である場合、デプス・バッファへの書き込み（即ち、ｚ値をセーブすること）は実行されないが、デプス・テストはなお実行される。本例では、デプス・マスクがプリミティブＢに関して使用禁止である場合、ＺＢ値はサンプルＦＳＭにセーブされない。従って、プリミティブＣのｚ値がＺＡ比較されるので、プリミティブＣは可視であると見なされることになる。
【０８２５】  つまり、アルファ・ブレンディングを含む本ＣＨＳＲプロセスの例では、プリミティブＡからＤまでが処理され、全てのプリミティブがパイプラインに送り込まれるが、全てのサンプルでそういう訳ではない。ある好適な実施例では、ピクセル・ブロックは、未解決の視認性問題を処理するために最終的ｚバッファド・ブレンディング・オペレーションを実行する。ＣｕｌｌＦｌｕｓｈＯｖｅｒｌａｐは、選択されたサンプルを、他のサンプルに影響を与えることなくディスパッチするということを説明するために、多数のサンプルが本例で示されている。
制御ビット
図Ｅ２８Ａは、ＤｏＡｌｐｈａＴｅｓｔ、ＤｏＡＢｌｅｎｄ、Ｔｒａｎｓｐａｒｅｎｔの３個の制御ビットを含む空間パケットの一部を示している。Ｔｒａｎｓｐａｒｅｎｔビットはジオメトリ・ブロック３０００により設定され、普通はソート済み透明モードで用いられるだけである。Ｔｒａｎｓｐａｒｅｎｔビットがリセットされると、対応するプリミティブは不透明なプリミティブに対するパスで処理されるだけである。Ｔｒａｎｓｐａｒｅｎｔビットがセットされると、対応するプリミティブは透明なプリミティブに対するパスで処理されるだけである。Ｔｒａｎｓｐａｒｅｎｔビットは、ジオメトリブロック３０００内で生成され、特定のプリミティブが不透明パス又は透明パス内に含まれているかどうかを判断するために、ソートブロック６０００により用いられるが、カル・ブロック９０００は、開始タイル・パケットを見ることによりパスのタイプを知るので、Ｔｒａｎｓｐａｒｅｎｔビットをカル・ブロック９０００へ送る必要はない。ＤｏＡｌｐｈａＴｅｓｔ制御ビットは、プリミティブ内のサンプル上でアルファ・テストが行われるかどうかを制御する。
【０８２６】  ＤｏＡｌｐｈａＴｅｓｔ制御ビットが１に設定されると、それは、カル・ブロック９０００から下流では、各フラグメント上でアルファ・テストが行われることを意味している。スタンプ内の全サンプルのアルファ値が所定値を越えると、例え、アプリケーションプログラムが、アルファ・テストを実行する必要があることを指示しても、カル・ブロック９０００から上流の機能ブロックは、アルファ・テストに合格しないサンプルはないと判断する。従って、ＤｏＡｌｐｈａＴｅｓｔはゼロに設定してもよく、そのゼロ値は、全サンプルがアルファ・テストにパスすると保証されているので、全サンプルがアルファ・テストを受けないかのようにサンプルを処理することができることをカル・ブロック９０００に示すことになる。１つのｚ値が記憶されている実施例では、アルファ・テストを受けているサンプルは、記憶されているサンプルを保存性にすることができることに留意されたい。従って、ＤｏＡｌｐｈａＴｅｓｔがゼロであれば、カルは更に多くのサンプルを正確であると識別し、更に多くのサンプルを消去することができる。ＤｏＡｌｐｈａＴｅｓｔ制御ビットの制御についての詳細な説明は、１９９８年、８月２０日付けの特許仮出願「ディファード・シェーディングを備えたグラフィクス・プロセッサ」に述べられており、参考文献としてここに援用する。
【０８２７】  ジオメトリ・ブロック３０００により生成されるＤｏＡＢｌｅｎｄ制御ビットは、プリミティブがブレンディングを受けるかどうかを示す。ブレンディングは２個のサンプルのカラー値を組み合わせる。
【０８２８】  ある実施例では、ジオメトリ・ブロック３０００が各頂点でアルファ値をチェックする。アルファ値が与えられ、フレーム・バッファ・カラー値が最終的カラーに影響を与えることがないようにＢｌｅｎｄＥｑｕａｔｉｏｎ及びＢｌｅｎｄＦｕｎｃパイプライン状態情報が定義されると、ブレンディングはＤｏＡＢｌｅｎｄ制御ビットを用いているプリミティブに関してターン・オフされる。ブレンディングが常にオンで、全プリミティブが透明なプリミティブとして扱われる場合、陰面除去プロセスは、ライティング及びシェーディングの前には、何れのジオメトリも除去しなくなることに留意されたい。
【０８２９】  未満であるかのデプス・テストのレンダーに対してブレンディングをターン・オフできるかどうかを決定するためにテクスチャ・データを評価するための方法について以下に述べる。未満であるかのデプス・テストのレンダーに関し、同じ位置に２個の不透明なプリミティブがある場合、前にあるプリミティブがレンダーされる。本発明は、超過であるかのデプス・テストのレンダーでも用いることができる。ブレンディングは、プリミティブが不透明であり、従ってそのプリミティブの後のジオメトリはどれもフレーム・バッファ内の対応する最終的カラーに寄与しない場合は、ターン・オフされる。プリミティブが不透明かどうかの判断が保留される場合は、最終的フレーム・バッファ・カラーが現在のプリミティブと、ｚ値が大きい別のプリミティブとのブレンドであるかどうかということに何らかの不確実性がある場合で、従ってそのプリミティブは透明プリミティブとして処理される。例えば、適切に定義付けされたテクスチャ環境が与えられており、プリミティブの全頂点のアルファ値が１に等しい場合、プリミティブは不透明として扱うことができるので、ブレンディングはそのプリミティブに関してターン・オフすることができる。従って、選別除去法を適用することができ、更に遠いジオメトリを消去することができる。
【０８３０】  あるプリミティブに関してブレンディングがターン・オフできるかどうかは、テクスチャ・タイプ、テクスチャ・データ、テクスチャ環境次第である。ある実施例では、テクスチャ・タイプが２つある。第１のテクスチャ・タイプはＲＧＢテクスチャである。ＲＧＢテクスチャでは、各テクセル（テクスチャ空間内のピクセルと等価）は、赤色要素値「Ｒ」と緑色要素値「Ｇ」と青色要素値「Ｂ」により定義される。この第１テクスチャ・タイプにはアルファ値はない。第２のテクスチャ・タイプは、アルファ値とＲ，Ｇ，Ｂ値とで各テクセルを記述する。テクスチャ・データはＲ，Ｇ，Ｂ及びアルファ要素の値で構成されている。テクスチャ環境は、関連テクスチャ・データ及びプリミティブの特性に基づいてピクセルの最終的カラーを如何に決めるかを定義する。例えば、テクスチャ環境は、ライティング方程式、及び各オペレーションが実行される時と同様に、使用される補間のタイプを定義することができる。
【０８３１】  図Ｅ２８Ｂは、ＤｏＡＢｌｅｎｄ制御ビットを設定するためにアルファ値が如何に評価されるかを示している。アルファ・モード・レジスタは、三角形プリミティブの３つの頂点各々に対するＴｒａｎｓｐａｒｅｎｔビットを記憶する。Ｔｒａｎｓｐａｒｅｎｔビットは、対応する頂点が、１と表示される透明か又は０と表示される不透明であるかを定める。３つの頂点全てが不透明である場合、ブレンディングがターン・オフされ、そうでなければブレンディングはそのままにされる。論理ブロックは、このブレンディング制御関数を作り出す。ＡｌｐｈａＡｌｌＯｎｅ制御信号が表明され、アルファ・モード・レジスタ内の３個の透明なビット全てが１に等しい場合には、論理ブロックはＤｏＡＢｌｅｎｄを０に設定し、ブレンディングをターン・オフする。アルファ値は、アルファ値０が頂点は不透明であることを示すように、反転することもできる。従って、このオペレーション・モードでは、ＡｌｐｈａＡｌｌＺｅｒｏ制御信号が表明され、３個の透明なビットすべてがゼロである場合は、論理ブロックはＤｏＡＢｌｅｎｄをゼロ（０）に設定し、ブレンディングをターン・オフする。
ソート済み透明モード
グラフィクス・パイプラインは、時間順モードかソート済み透明モードかのどちらかで作動する。ソート済み透明モードでは、タイルからジオメトリを読み取るプロセスが複数のパスに分割される。第１パスではソートブロックは保証済みの不透明なジオメトリを出力し、次のパスで、透明な可能性のあるジオメトリを出力する。各ソート済み透明モードパス内では時間順序は保存され、モード・データは正しい時間順位置に挿入される。ソート済み透明モードは、バックツーフロント順又はフロントツーバック順の何れかの順序で実行することができる。ある好適な実施例では、ソート済み透明法は、ソート・ブロック及びカル・ブロックと組み合わせて実行される。
【０８３２】  バックツーフロントのソート済み透明モードでは、ピクセル・カラーは、先ずサンプル位置で最も前にある不透明な面をレンダリングすることにより決定される。次のパスでは、不透明な面の前にある最も遠い透明な面がレンダーされる。次のパスでは、二番目に遠い透明な面がレンダーされ、このプロセスは、そのサンプル位置にある全てのサンプルがレンダーされるか、又はサンプルの最大所定数がそのサンプル位置にレンダーされるまで繰り返される。
【０８３３】  バックツーフロントのソート済み透明モード・レンダリング法について、次に更に詳細に述べる。この方法は、未満であるかのデプス・テストのレンダーと共に用いられる。図Ｅ２９において、ソート・ブロックは、第１パスで不透明なプリミティブを送る。カル・ブロック９０００は、不透明なプリミティブ・サンプルに対するｚ値をＭＣＣＡＭアレイ９００３内に記憶（図Ｅ１５、ステップ２９０１）する。ソート・ブロックは、第２パス及びそれ以後のパスで透明なプリミティブをカル・ブロックへ送る。ソート済み透明モードでは、ＭＣＣＡＭアレイ９００３及びサンプルＺバッファ９０５５は、それぞれの対応するサンプルに対しそれぞれ２つのｚ値（ＺｆａｒとＺｎｅａｒ）を記憶する。Ｚｆａｒ値は最も近い不透明なサンプルのｚ値である。Ｚｎｅａｒ値は、最も近いサンプルのｚ値であり、不透明層のｚ値よりも小さい。ある実施例では、Ｚｆａｒ値とＺｎｅａｒ値とを別々のユニットに記憶するように、２つのＭＣＣＡＭアレイ９００３と２つのサンプルＺバッファ９０５５を含んでいる。まず最も前にある不透明なサンプルのｚ値がＭＣＣＡＭアレイ９００３に記憶（ステップ２９０２）される。次に、最も前にある不透明なサンプルはパイプラインにディスパッチされてレンダー（ステップ２９０３）される。ある実施例では、全てのポインタ内のフラッグ・ビットが、対応するジオメトリは透明であるか不透明であるかを示す。各サンプルに対するＺｎｅａｒ値は、次のパスに備えてゼロにリセット（ステップ２９０４）される。各透明なパスの間に、現在のプリミティブ内の各サンプル・ポイントに対するｚ値は、そのサンプル・ポイントに対するＺｆａｒ値及びＺｎｅａｒ値の両方と比較される。ｚ値がＺｎｅａｒ値よりも大きくてＺｆａｒ値未満である場合、そのサンプルは不透明層により近いので、そのｚ値が現在のＺｎｅａｒ値に取って代わる。次に、新しいＺｎｅａｒ値に対応するサンプルはパイプラインにディスパッチされてレンダー（ステップ２９０７）され、そのような各サンプルに対するＺｆａｒ値は、Ｚｎｅａｒ値に設定（ステップ２９０８）される。このプロセスは次のパスで繰り返される。
【０８３４】  カル・ブロック９０００は、各サンプル・ポイントに関し、Ｚｆａｒの前に多くても１つのサンプルが存在する場合、タイルを処理し終えたかどうかを検出する。透明層のプロセッシングは、タイル内の何れかのサンプル・ポイントに対し２個以上のサンプルがＺｆａｒの前にある限り、終了されない。
【０８３５】  フロントツーバックのソート済み透明モードでは、透明なサンプルは順番にレンダーされ、最も前の透明なサンプルから始まり、その次に、次に遠い透明なサンプルと、それぞれ続くサイクルでレンダーされる。フロントツーバックのソート済み透明モードを用いる利点は、層の最大数が定められている場合、最も前の透明層がレンダーされ、それによってより正確な最終的表示イメージを提供できることである。
【０８３６】  ある実施例では、レンダーされる層の最大数は、アルファ値を累計することにより決定される。アルファ値はサンプル位置の透明度を表す。各サンプルがレンダーされるにつれ、そのサンプル位置での透明度は低下し、累積アルファ値は増加（アルファ値１が不透明であると定義されている場合）する。例えば、累計アルファ値が０．９を超え、そのサンプル位置ではサンプルがそれ以上レンダーされない場合、最大累計アルファ値は０．９と定義される。
【０８３７】  図Ｅ１５に示すように、全サンプルに対し、サンプルＺバッファ９０５５内には２つのカウンタがある。同じサンプル位置で異なるプリミティブからの２つのサンプルが同じｚ値を有している場合、その２つのサンプルは到着した時間順でレンダーされる。カウンタは、どのサンプルがレンダーされるべきかを時間順に基づいて決定するのに用いられる。第１カウンタは、現在のパス内で処理されるべきプリミティブを識別する。例えば、５個のプリミティブが、所与のサンプル位置にあってｚ値が同じサンプルをそれぞれ有している場合、第１パスで、第１カウンタは、このグループ内の第１プリミティブがレンダーされるべきことを示す数字１に設定される。第２パスでは、第２プリミティブをレンダーされるべきプリミティブであると識別するために、この第１カウンタは増やされる。
【０８３８】  第２カウンタはパス内で評価されているプリミティブのカウントを保守する。５個のプリミティブの例では、第３パスでは、第３プリミティブがレンダーされるべきサンプルを有する。第１パスの開始時には、第１カウンタは３に等しく、第２カウンタは１に等しい。第１カウンタ値は第２カウンタ値と比較され、カウンタ値が等しくないので、第１プリミティブからのサンプルは、レンダーされない。次に第２カウンタは増えるが、２つのカウンタはまだ等しくないので、第２プリミティブからのサンプルはレンダーされない。第３パスでは、第１カウンタ値と第２カウンタ値とは等しくなるので、第３プリミティブからのサンプルがレンダーされる。
特定の代表的実施例の特性
本発明のディファード・シェーディング・グラフィクス・プロセッサ（ＤＳＧＰ）の特定の実施例に焦点を当てることとする。ある態様（ＣＵＬＬ）では、本発明のＤＳＧＰは保存性陰面除去を実行するための構造及び方法を提供する。以下に多くの実施例を示し説明するが、実施例はこれに限定されるわけではない。
【０８３９】  （１）陰面除去をコンピュータ・グラフィクス・パイプラインで実行する方法において、各プリミティブが複数のスタンプを備えているプリミティブのグループから現在のプリミティブを選択する段階と、前記現在のプリミティブ内のスタンプを、前記プリミティブのグループ内の先に評価済みのプリミティブからのスタンプと比較する段階と、第１スタンプを、前記第１スタンプ内のサンプルのデプス状態と前記先に評価済みのスタンプのサンプルのデプス状態との関係に基づいて、現在可視の可能性があるスタンプ（ＣＰＶＳ）として選択する段階と、前記ＣＰＶＳを第２スタンプと比較する段階と、前記既に評価済みのスタンプに基づいて前記第２スタンプのどの部分も最終的グラフィクス・ディスプレイのイメージに影響を与えない場合、前記第２スタンプを捨てる段階と、前記第２スタンプが前記ＣＰＶＳを隠す場合、前記ＣＰＶＳを捨てて前記第２スタンプをＣＰＶＳにする段階と、前記第２スタンプと前記ＣＰＶＳが共に最終的グラフィクス・ディスプレイのイメージ内で少なくとも部分的には可視である場合、前記ＣＰＶＳをディスパッチして前記第２スタンプをＣＰＶＳにする段階と、前記第２スタンプと前記ＣＰＶＳの視認性が、コンピュータ・グラフィクス・パイプラインで後に評価されるパラメータ次第である場合、前記第２スタンプ及び前記ＣＰＶＳをディスパッチする段階とから成る方法。
【０８４０】  （２）前記ＣＰＶＳを第２スタンプと比較する前記段階が、前記ＣＰＶＳ内のサンプルのデプス状態を前記第２スタンプ内のサンプルのデプス状態と比較する段階と、パイプライン状態値を評価する段階とを更に備えていることを特徴とする（１）に記載の方法。
【０８４１】  （３）前記デプス状態はサンプル毎に１個のｚ値を備えており、前記ｚ値は、前記ｚ値が現在可視である面の実際のｚ値を表している場合は正確であると定義付けられ、前記ｚ値が最大ｚ値を表している場合は保存性であると定義付けられる状態ビットを含んでいることを特徴とする（１）に記載の方法。
【０８４２】  （４）前記第２スタンプが、デプス状態と関係なく、最終的グラフィクス・ディスプレイ・イメージを変更する可能性がある場合、前記第２スタンプ及び前記ＣＰＶＳをディスパッチする段階を更に備えていることを特徴とする（１）に記載の方法。
【０８４３】  （５）前記ディスパッチされたスタンプをカラーリングする段階と、前記カラーリング段階の後で、正確なＺバッファ・テストを前記ディスパッチされたスタンプで実行する段階とを更に備えていることを特徴とする（１）に記載の方法。
【０８４４】  （６）複数のサンプルのアルファ値を基準アルファ値と比較する段階と、前記複数のサンプルのアルファ値が全て基準値を超えている場合は、アルファ値に関係なく、前記第２スタンプ及び前記ＣＰＶＳをディスパッチする段階を実行する段階とを更に備えていることを特徴とする（１）に記載の方法。
【０８４５】  （７）前記現在のプリミティブ内の何れかのサンプルが最終的グラフィクス・ディスプレイ・イメージ内の最終的ピクセル・カラー値に影響を与えるかどうかを決定する段階と、前記現在のプリミティブ内の何れのサンプルも最終的グラフィクス・ディスプレイ・イメージ内の最終的ピクセル・カラー値に影響を与えない場合は、前記現在のプリミティブに対するブレンディングをターン・オフする段階とを更に備えていることを特徴とする（１）に記載の方法。
【０８４６】  （８）前記現在のプリミティブ内のスタンプを、先に評価済みのプリミティブからのスタンプと比較する前記段階が、前記現在のプリミティブの複数のスタンプ位置に関する最大ｚ値を決定する段階と、前記複数のスタンプ位置に関する最大ｚ値を前記現在のプリミティブの最小ｚ値と比較して対応するスタンプ選択ビットを設定する段階と、行内のスタンプ位置に関する最大ｚ値が前記現在のプリミティブの最小ｚ値を超えているようなスタンプの行を、プロセス行として識別する段階とを更に備えていることを特徴とする（１）に記載の方法。
【０８４７】  （９）前記現在のプリミティブの複数のスタンプ位置に関する最大ｚ値を決定する前記段階が、前記現在のプリミティブの境界画定ボックス内の各スタンプに関する最大ｚ値を決定する段階を更に備えていることを特徴とする（８）に記載の方法。
【０８４８】  （１０）前記現在のプリミティブ内のスタンプを、先に評価済みのプリミティブからのスタンプと比較する前記段階が、各プロセス行内の前記現在のプリミティブがタッチしている最左及び最右のスタンプを決定して、対応するスタンプ・プリミティブのカバレッジ・ビットを定義する段階と、最終的な可視の可能性があるスタンプ・セットを生成するために、前記スタンプ・プリミティブのカバレッジ・ビットをスタンプ選択ビットと組み合わせる段階とを更に備えていることを特徴とする（８）に記載の方法。
【０８４９】  （１１）前記現在のプリミティブ内のスタンプを、先に評価済みのプリミティブからのスタンプと比較する前記段階が、前記最終的な可視の可能性があるスタンプ・セット内のスタンプ内にサンプル・ポイントのセットを決める段階と、前記サンプル・ポイントのセット内の複数のサンプル・ポイントに対するｚ値を計算する段階と、計算されたｚ値を記憶されているｚ値と比較してサンプル制御信号を出力する段階とを更に備えていることを特徴とする（１０）に記載の方法。
【０８５０】  （１２）前記計算されたｚ値を記憶されているｚ値と比較する前記段階が、第１サンプルの第１デプス状態が第１サンプル位置における可視サンプルの最大デプス状態である場合、前記第１サンプル位置にある前記第１サンプルをＺｆａｒサンプルとして記憶する段階と、第２サンプルを前記第１サンプルと比較する段階と、前記第２サンプルが現在可視の可能性がある場合には、前記第２サンプルをＺｏｐｔサンプルとして記憶し、前記Ｚｆａｒサンプルが前記第２サンプルを隠す場合には、前記第２サンプルを捨てる段階とを更に備えていることを特徴とする（１０）に記載の方法。
【０８５１】  （１３）あるスタンプ内の１個のサンプルをパイプラインにディスパッチすることが決定された場合には、前記スタンプ内の全サンプルがパイプラインにディスパッチされることを特徴とする（１０）に記載の方法。
【０８５２】  （１４）あるピクセル内の１個のサンプルをパイプラインにディスパッチすることが決定された場合には、前記ピクセル内の全サンプルがパイプラインにディスパッチされることを特徴とする（１０）に記載の方法。
【０８５３】  （１５）サンプル・ポイントのセット内の複数のサンプル・ポイントに対するｚ値を計算する前記段階が、スタンプに対する基準ｚ値を作成する段階と、前記サンプル・ポイントのセット内の複数のサンプル・ポイントに対する偏導関数を計算する段階と、前記基準ｚ値及び前記偏導関数をパイプラインに送り込む段階と、前記基準ｚ値及び前記偏導関数に基づいて、サンプルに対するｚ値を計算する段階とを更に備えていることを特徴とする（１０）に記載の方法。
【０８５４】  （１６）基準ｚ値及び偏導関数を受信する段階と、前記基準ｚ値及び前記偏導関数に基づいてサンプルに対するｚ値を再計算する段階とを更に備えていることを特徴とする（１０）に記載の方法。
【０８５５】  （１７）前記ＣＰＶＳがステンシル値に影響を与える可能性がある場合には前記ＣＰＶＳをディスパッチする段階を更に備えていることを特徴とする（１０）に記載の方法。
【０８５６】  （１８）ステンシル・テストが変わる場合には現在可視の可能性があるスタンプ全てをディスパッチする段階を更に備えていることを特徴とする（１０）に記載の方法。
【０８５７】  （１９）複数のプリミティブからの現在のサンプルを記憶する段階と、第１サンプル位置にあるサンプルに対する計算されたｚ値を、複数のプリミティブからの、前記第１サンプル位置にあるサンプルの記憶されているｚ値と比較する段階とを更に備えていることを特徴とする（１０）に記載の方法。
【０８５８】  （２０）各スタンプが少なくとも１個のピクセルを備えており、スタンプ内の前記ピクセルは並行して処理されることを特徴とする（１０）に記載の方法。
【０８５９】  （２１）ディスプレイ・イメージの領域をタイルに分割する段階と、前記ディスプレイ・イメージを各タイルに独立してレンダーする段階とを更に備えていることを特徴とする（２０）に記載の方法。
【０８６０】  （２２）前記サンプル・ポイントはサブラスター・グリッド・ラインの間に配置されていることを特徴とする（１０）に記載の方法。
【０８６１】  （２３）各ピクセル内の前記サンプル・ポイントの位置はプログラム可能であることを特徴とする（２０）に記載の方法。
【０８６２】  （２４）複数のピクセル内のサンプル位置の第１セットをプログラムする段階と、前記サンプル位置の第１セットを用いて、スタンプの視認性を評価する段階と、複数のピクセル内のサンプル位置の第２セットをプログラムする段階と、前記サンプル位置の第２セットを用いてスタンプの視認性を評価する段階とを更に備えていることを特徴とする（２３）に記載の方法。
【０８６３】  （２５）最終的グラフィクス・ディスプレイ・イメージに影響を与えないと判定された個々のスタンプを消去する段階を更に備えていることを特徴とする（１０）に記載の方法。
【０８６４】  （２６）前記現在のプリミティブの頂点のアルファ値が、フレーム・バッファカラー値が前記現在のプリミティブ内のサンプルの最終的カラーに影響を与えることがないような値を有している場合には、ブレンディングをターン・オフする段階を更に備えていることを特徴とする（１０）に記載の方法。
【０８６５】  （２７）前記デプス状態は遠いｚ値及び近いｚ値を備えていることを特徴とする（１）に記載の方法。
【０８６６】  （２８）ディファード・シェーダー・コンピュータ・グラフィクス・パイプライン用の陰面除去システムにおいて、現在のプリミティブに関係付けられた可視の可能性があるサンプルの第１グループを識別するためのマグニチュード・コンパリソン・コンテンツ・アドレス可能メモリ・カル・ユニットと、前記マグニチュード・コンパリソン・コンテンツ・アドレス可能メモリ・カル・ユニットに連結されており、前記第１グループ及び前記プリミティブのペリメータに基づいて前記プリミティブに関係付けられた可視の可能性があるサンプルの第２グループを識別するためのスタンプ選択ユニットと、前記スタンプ選択ユニット及び前記マグニチュード・コンパリソン・コンテンツ・アドレス可能メモリ・カル・ユニットに連結されており、パイプライン状態を評価し、前記第２グループのデプス状態を記憶されているデプス状態値と比較することにより可視スタンプ部を識別するためのＺカルユニットと、前記Ｚカルユニットに連結されており、前記Ｚカルユニットから受信された制御信号に基づいて可視スタンプ部を記憶するためのスタンプ部メモリ・ユニットとを備えており、前記スタンプ部メモリ・ユニットは、後でコンピュータ・グラフィクス・パイプラインで評価されるパラメータ次第で変わる視認性を有するスタンプをディスパッチすることを特徴とする陰面除去システム。
【０８６７】  （２９）前記記憶されでいるデプス状態値が前記可視スタンプ部とは別に記憶されていることを特徴とする（２８）に記載の陰面除去システム。
【０８６８】  （３０）前記Ｚカルユニットが、デプス状態値及びパイプライン状態値を評価し、現在可視の可能性があるスタンプ（ＣＰＶＳ）を第１スタンプと比較することと、前記スタンプ部メモリは、前記Ｚカル・ユニットからの制御信号に基づいて、評価済みのスタンプに基づき前記第１スタンプの何れの部分も最終的グラフィクス・ディスプレイ・イメージに影響を与えない場合には前記第１スタンプを捨て、前記第１スタンプが前記ＣＰＶＳを隠す場合には前記ＣＰＶＳを捨てて前記第１スタンプをＣＰＶＳとし、前記第１スタンプと前記ＣＰＶＳが共に最終的グラフィクス・ディスプレイ・イメージ内で少なくとも部分的には可視である場合には前記ＣＰＶＳを捨てて前記第１スタンプをＣＰＶＳとし、前記第１スタンプ及び前記ＣＰＶＳの視認性が後でコンピュータ・グラフィクス・パイプライン内で評価されるパラメータ次第で変わる場合には前記第１スタンプ及び前記ＣＰＶＳを捨てることとを特徴とする（２８）に記載の陰面除去システム。
【０８６９】  （３１）前記ＭＣＣＡＭカル・ユニットが、前記現在のプリミティブの複数のスタンプ位置に対する最大ｚ値を決定し、前記複数のスタンプ位置に対する最大ｚ値を前記現在のプリミティブの最小ｚ値と比較して対応するスタンプ選択ビットを設定し、行内のスタンプ位置に対する最大ｚ値が前記現在のプリミティブの最小ｚ値を超えるようなスタンプの行をプロセス行として識別することを特徴とする（２８）に記載の陰面除去システム。
【０８７０】  （３２）前記スタンプ選択ユニットが、前記プロセス行それぞれの内の前記現在のプリミティブがタッチする最左及び最右スタンプを決定して対応するスタンプ・プリミティブ・カバレッジ・ビットを定め、最終的な可視の可能性があるスタンプ・セットを生成するために前記スタンプ・プリミティブ・カバレッジ・ビットを前記スタンプ選択ビットと組み合わせることを特徴とする（３１）に記載の陰面除去システム。
【０８７１】  （３３）前記Ｚカル・ユニットは、前記最終的な可視の可能性があるスタンプセットのスタンプ内のサンプル・ポイントのセットを決定し、前記サンプル・ポイントのセット内の複数のサンプル・ポイントに対するｚ値を計算し、計算されたｚ値を記憶されているｚ値と比較して制御信号を出力することを特徴とする（３２）に記載の陰面除去システム。
【０８７２】  （３４）前記Ｚカル・ユニットは、複数のＺカル・サンプル状態マシンを備えており、前記Ｚカル・サンプル状態マシンのそれぞれが、サンプルに対する制御信号を受信し、処理し、出力することを特徴とする（３３）に記載の陰面除去システム。
【０８７３】  （３５）コンピュータグラフィクス・イメージをレンダーする方法において、レンダーすべき複数のプリミティブを受信する段階と、サンプル位置を選択する段階と、前記選択されたサンプル位置における最も前の不透明なサンプルをレンダーし、前記最も前の不透明なサンプルのｚ値をＺｆａｒと定義する段階と、前記選択されたサンプル位置における第１の複数のサンプルの各ｚ値を比較する段階と、前記選択されたサンプル位置において、前記第１の複数のサンプルのＺｆａｒより小さく且つＺｆａｒに最も近いｚ値を有している第１サンプルをＺｎｅａｒであると定義する段階と、前記第１サンプルをレンダーする段階と、ＺｆａｒをＺｎｅａｒの値に設定する段階と、前記選択されたサンプル位置における第２の複数のサンプルの各ｚ値を比較する段階と、前記選択されたサンプル位置において、前記第２の複数のサンプルのＺｆａｒより小さく且つＺｆａｒに最も近いｚ値を有している第２サンプルのｚ値をＺｎｅａｒと定義する段階と、前記第２サンプルをレンダーする段階とを備えていることを特徴とする方法。
【０８７４】  （３６）前記選択されたサンプル位置における第３の複数のサンプルがＺｆａｒ未満の共通のｚ値を有しており、前記共通のｚ値が前記第１の複数のサンプルのＺｆａｒに最も近いｚ値である場合には、前記第３の複数のサンプルの内の最初の受信されたサンプルである第３のサンプルをレンダーする段階と、レンダーされるべきサンプルを識別するサンプル・レンダー番号を定義するために第１カウンターの値を増やす段階と、第４のサンプルを前記第３の複数のサンプルから選択する段階と、評価サンプル番号を定義する第２カウンターを増やす段階と、前記サンプル・レンダー番号と前記評価サンプル番号を比較する段階と、対応する前記評価サンプル番号が前記サンプルレンダー番号と等しい場合はサンプルをレンダーする段階とを更に備えていることを特徴とする（３５）に記載の方法。
ＶＩＩＩ．フラグメント機能ブロック（ＦＲＧ）の詳細な説明
概観
フラグメント・ブロックは、カル及びモード注入の後方で、且つテクスチャ、フォング、バンプの前方に位置している。フラグメント・ブロックは、シェードすべき４つまでのフラグメントから成る可視スタンプ部（ＶＳＰ）を受信する。ＶＳＰ内のフラグメントは常に同じプリミティブに属しているので、フラグメントは、全てのモード・セッティングを含む、頂点で定義されるプリミティブ・データを共有している。サンプル・マスク、即ちＳＭＡＳＫは、ＶＳＰのとのサブピクセル・サンプルがアクティブかを定義する。所与のピクセルに対する４つのサンプルの内１つ又はそれ以上がアクティブであればアクティブである。これはフラグメントがピクセルにとって必要であり、フラグメント・ベースのデータを作るためにプリミティブに関する頂点ベースのデータが補間されることを意味している。アクティブ・サブピクセル・サンプル位置は、フラグメントの対応するｘ及びｙ座標を定義するために使用される。
【０８７５】  帯域幅をセーブするために、フラグメント・ブロックはカラー・データをキャッシュして、同じプリミティブに属する多くのＶＰＳｓが再利用できるようにする。モード注入は、ＶＳＰを送る前に、カラー・キャッシュが必要なデータ含んでいるかどうか識別する。ヒットであれば、モード注入は、インデクスを含んでいるＶＳＰをキャッシュに送る。キャッシュ・ミスが起きると直ぐに、モード注入は、新しいエントリを指すカラー・キャッシュ・インデクスを備えたＶＳＰパケットを送る前に、キャッシュからのエントリを新しいカラー・データと入れ替える。同様に、全てのモード、材料、テクスチャ情報、ライト情報のセッティングは、それらが使用されるブロックにキャッシュされる。これらのキャッシュそれぞれに対するインデクスも、ＶＳＰパッケットに含まれている。多角形データに加え、フラグメント・ブロックは幾つかテクスチャ及びモード情報をキャッシュする。図５６はＤＳＧＰパイプラインの後半におけるモード・データのフローとキャッシュを示している。
【０８７６】  フラグメント・ブロックの主要機能は、ＶＳＰ中の全てのアクティブ・フラグメントに頂点で与えられる多角形情報の補間である。フラグメント・ブロックのアウトプットにおいては、我々はまだフラグメント毎の全ての補間データと共にスタンプを持っている。フラグメント・ブロックは所与のフラグメントの補間を並行して行うことができ、ＶＳＰ内のフラグメントは任意の順序で行うことができる。完全に補間された各スタンプは、テクスチャ、フォング、ダンプの各ブロックに、受信したと同じ順序で送信される。更に、フラグメント・ブロックは、４つまでのテクスチャに対するレベルオブディテイル（ＬＯＤまたはλ）値を生成し、それらをテクスチャ・ブロックに送る。
【０８７７】  フラグメント・ブロックは、そのインプットに、変動するスタンプの処理時間とカラー・キャッシュ・フィルの持ち時間を円滑にするため、適切なサイズのＦＩＦＯを有する。
図５７は、フラグメント・ブロックのブロック線図を示している。
【０８７８】  フラグメント・ブロックは以下の６つのサブブロックに分割できる。
１．キャッシュ・フィル・サブブロック１１０５０
２．カラー・キャッシュ１１０５２
３．補間係数サブブロック１１０５４
４．補間サブブロック１１０５６
５．正規化サブブロック１１０５８
６．ＬＯＤサブブロック１１０６０
１番目のブロックはカラー・キャッシュ・ミスを取り扱う。新しい多角形データはキャッシュ内の古いデータに置き換わる。カラー・キャッシュ・インデクスＣＣＩＸ、は置き換えられるべきエントリを指す。ブロックは、全ての多角形データを直接キャッシュに書き込むわけではない。ブロックは、頂点座標、ｗ座標の逆数、随意のテクスチャｑ座標を使用し、重心係数を計算する。ブロックは、重心関数を、それを計算するために使われれる情報の代わりに、キャッシュに書き込む。
【０８７９】  ２番目のサブブロックはカラー・キャッシュを実行する。フラグメントがＳＶＳＰパケット（ヒット）を受信すると、頂点における多角的データ及び関連重心係数にアクセスするため、ＣＣＸＩが指すキャッシュのエントリが読み込まれる。
【０８８０】  ３番目のサブブロックはＶＳＰの第１フラグメントに対する補間係数を準備する。この係数は、次のフラグメントの係数の増分計算をやり易くするため、分子と分母に対し平面方程式の形で表されている。三角形の合計面積は、分子と分母を共に除すので単純化できる。又、重心係数は冗長ビルト・イン（分数の和は全体と等しい）を有しているので、追加の記憶装置と帯域幅は、分母と共に３つの内２つの重心座標を提供するだけでセーブされる。非性能ケースとして、１ではなく９のテクスチャ座標が分母に更に３つ係数を使用して補間される。
【０８８１】  スタンプ毎に与えられるｘ及びｙ座標は、スタンプ内の左下方のピクセルに対応する。タイル内のスタンプの位置だけがこれらの座標により決定される。個々のパレットは、次のスタンプが属するタイルの座標を提供する。ルックアップ・テーブルは、サブピクセルの精度でフラグメントのｘ及びｙ座標の下方のビットを決めるために、ｓＭＡＳＫにおいて対応するビットと共に使用される。補間位置をアクティブ・サンプル位置に選定すれば、補間係数はその合計が１と等しく常に正になることが保証される。
【０８８２】  ４番目のサブブロックは、カラー、法線、テクスチャ座標、視点座標、バンプ正接を、カバーされたピクセル毎に補間する。補間回路は、それらの精度に応じて４つのグループに分けられる。第１のグループは、８ビットの固定小数点のカラー・フラクションを補間する。その値は０と１の間にあり、値１の２進法表記は全てのビットと共に１とセットされる。第２のセットは、法線及び面正接方向に対する１６ビットの固定小数点ユニット・ベクトルを補間する。第三のセットは１６ビットの仮数を有する２４ビットの浮動小数点を補間する。頂点の視点座標と、法線及び面正接の大きさはこのカテゴリに入る。最後のグループは、これも又２４ビットＦＰ数であるが異なる補間係数を有していてもよい、テクスチャ座標を補間する。全ての補間関数は２４ビットＦＰ値として生成されるが、８ビット又は１６ビットの固定小数点値を補間する場合は、より少ないビット又は固定小数点の表記を使用することもできる。
【０８８３】  ５番目のサブ・ブロックは、法線及び面正接を再正規化する。この過程で得られた大きさは捨てられる。元のの大きさが、フォング及びバンプ・ブロックに送られる前に別々に補間される。
【０８８４】  テクスチャ・マップｕ、ｖ座標及びレベルオブディテイル（ＬＯＤ）は６番目のサブブロックで評価される。重心係数はテクスチャＬＯＤの決定の際使用される。２つのテクスチャ座標に関係する４つまでの個々のテクスチャがサポートされる。従って、ユニットは、フラグメント毎に、２４ビットＦＰ値として表現される、４つまでのＬＯＤと２セットまでのｓ、ｔ座標を生成できる。
ｓＭＡＳＫ及びｐＭＡＳＫ
図５８は、様々なプリミティブにより形成されるピクセル・フラグメントを含むＶＳＰの例を示している。ｓＭＡＳＫのコピーも、シェーディング・ブロック（フラグメント、テクスチャ、フォング及びバンプ）をバイパスし、直接ピクセル・ブロックに送られる。バイパス・パケットは、ｚ値、モード、多角形スティップル・インデクスも含んでおり、リオーダ・バッファにおいてＶＳＰｐｔｒの指す位置で書き込まれる。ｐＭＡＳＫはフラグメント・ブロック内で生成され、ｓＭＡＳＫの代わりにテクスチャとフォングに送られる。実際のカバレッジはピクセル内で評価される。
三角形に対する重心補間
フラグメント・ブロックは、遠近法的に修正された重心補間を使って、値を補間する。この節では、このプロセスを説明する。
【０８８５】  三角形をラスタライジングすることにより作られる各フラグメントと関係するデータに関して、我々は、これらの値が三角形内のフラグメントのために如何に作られるかを規定することより始める。我々は、三角形１１１７０（図５９）の重心座標を定義する。重心座標は、Ａ０、Ａ１、Ａ２という、各々「０、１」の範囲内にある三つの数のセットであり、Ａ０＋Ａ１＋Ａ２＝１である。これらの座標は、三角形内、あるいは三角形の境界線上のあらゆる点ｐを、次のように特有の方法で規定し、
ｐ（ｘ、ｙ）＝Ａ０（ｘ、ｙ）ｘＶ０＋Ａ１（ｘ、ｙ）ｘＶ１＋Ａ２（ｘ、ｙ）ｘＶ２
ここに、Ｖ０、Ｖ１、Ｖ２  は三角形の頂点である。Ａ０、Ａ１、Ａ２は次のように表され、
【０８８６】
【数６０】
2004272928.tif 000085
ここに、Ａｒｅａ（ｉ，ｊ，ｋ）は、頂点ｉ、ｊ、ｋを有する三角形のウィンドウ座標内の面積を示す。この面積の計算方法の一つは以下の通りである。
【０８８７】
【数６１】
2004272928.tif 000086
Ｖ０、Ｖ１、Ｖ２におけるデータをそれぞれｆ０、ｆ１、ｆ２と表す。三角形をラスタライジングすることにより作られるウィンドウ座標ｘ及びｙをによる、フラグメントにおけるデータの値ｆ（ｘ，ｙ）は以下により与えられ、
【０８８８】
【数６２】
2004272928.tif 000087
ここに、Ｗｃ０、Ｗｃ１、Ｗｃ２はそれぞれＶ０、Ｖ１、Ｖ２  のクリップｗ座標である。Ａ０、Ａ１、Ａ２は、データが作られるフラグメントの重心座標である。
【０８８９】
【数６３】
2004272928.tif 000088
である。
線の補間
ラインに沿うフラグメント・データの補間には、わずかに異なる式の次が使用される。
作られたフラグメント・センターのウィンドウ座標をｐｒ＝（ｘ，ｙ）により与え、ｐ２＝（ｘ２，ｙ２）とｐ１＝（ｘ２，ｙ２）をラインのエンド・ポイント（頂点）とする。ｔを以下のようにセットし、ｐ１の時ｔ＝０で、ｐ２の時ｔ＝１とする。
【０８９０】
【数６４】
2004272928.tif 000089
ポイントの補間
プリミティブがポイントであれば、補間はなされない。頂点２はデータを保持していると仮定する。ｑが１に等しくないとき、ｓ、ｔ、ｒ座標はｑで除さなければならない。
ベクトル補間
バンプ・マッピングの場合、法線と面正接は、指向単位ベクトルに関係する大きさを有している。その場合、我々は単位ベクトル構成要素を、スカラーの大きさから分離して補間する。これは、大きさを含むｘ、ｙ、ｚ構成要素を補間するより、明かに良好な目に見える結果を与える。これは、方向と大きさが別々に用いられる場合には、特に重要である。
【０８９１】  図６０は、大きさの異なるベクトル間の補間が如何に不均一な角度細分性を生じるかを示しており、これが、我々がこのやり方で法線及び正接を補間しない理由である。
フラグメントｘ及びｙ座標
図６１は、補間係数を形成するのに使用されるフラグメントｘ及びｙ座標が如何に形成されるかを示す。タイル・プロセッシングの開始時にセットされるタイルｘ及びｙ座標は、最も重要なビットを形成する。サンプル・マスク（ｓＭＡＳＫ）は、どのフラグメントがプロセスされるべきかを見つけ出すために使用される。ルックアップ・テーブルは、サブピクセルの精度で、最も重要性の低い座標のビットを提供する。サンプル位置選択の２ビット無しでできれば、ＬＵＴのサイズを低減することができる。
方程式
キャッシュ・ミス計算
始めの重心係数は、カラー・キャッシュ・ミス時にフラグメント・ユニットで評価される必要がある。三角形では：
【０８９２】
【数６５】
2004272928.tif 000090
上の方程式で、ｘｗ０、ｘｗ１、ｘｗ２は、三つの三角形頂点のウィンドウｘ座標である。同様に、ｙｗ０、ｙｗ１、ｙｗ２は、三角形頂点の三つのｙ座標である。実際の重心係数では、全ての構成要素は三角形の面積により除する必要がある。遠近法的修正はこれも面積により除された係数を含む分母を形成するため、これは我々の場合、必要ない。
頂点座標ｘｗ１、ｘｗ２及びｙｗ１、ｙｗ２を有するラインでは、次のようになる。
【０８９３】
【数６６】
2004272928.tif 000091
ここに、ｗｉｃ０は頂点０のクリップｗ座標の（幾何学において逆数にされた）逆数である。
【０８９４】
【数６７】
2004272928.tif 000092
上記計算は三角形毎に１度だけ行う必要がある。カラー・メモリ・キャッシュは同じ三角形の次のＶＳＰ用の係数をセーブするため使用される。キャッシュ・ミス時は、係数が再評価される必要がある。
補間係数
次に、座標（ｘ，ｙ）を含むＶＳＰの最初のピクセルのために、重心座標を用意する：
【０８９５】
【数６８】
2004272928.tif 000093
非性能ケース（半速）として、テクスチャ座標がｑｎ［ｍ］が１に等しくない時、ｎが頂点数（０から２）でｍがテクスチャ数（０から３）とすれば、テクスチャ座標を補間するための追加の分母は次のように表される。
【０８９６】
【数６９】
2004272928.tif 000094
（ｘ，ｙ）座標を有する所与のピクセルに関する重心座標が求めれれる場合、我々はこれを補間するために使用する。ラインにとって、Ｌ０は必要ないが、次の式では０と仮定される。
補間方程式
フル性能モードでは、我々は１セットのテクスチャ座標を補間する。
【０８９７】
【数７０】
2004272928.tif 000095
８ビットカラー値は実際には０と１の間（０、１を含む）の分数あることに留意されたい。慣例により、ミッシングを表す数は１−２−８である。値１は、ミッシング表記の生じる全てのビット・セットにより表される。カラー・インデクスがＲ、Ｇ、Ｂ、Ａの代わりに使用される時、８ビット・インデクス値は、カラーの散乱及び反射要素のＲ値に置き替わる。
【０８９８】  そして面法線は、以下のようになる。
【０８９９】
【数７１】
2004272928.tif 000096
半速（累積的）では、４つまでテクスチャ座標を補間する。これは、平面方程式又は重心座標の何れかを使って行われる。ｒテクスチャ座標も、全速の３分の１ではあるが、ボリューム・テクスチャ・レンダリングのために補間される。
【０９００】
【数７２】
2004272928.tif 000097
その一部が頂点毎のバンプ正接としてユーザーにより提供された場合、それらを補間する必要がある。単純化のため、ハードウェアは常に半速で面正接を補間する。
【０９０１】
【数７３】
2004272928.tif 000098
面正接も、法線のように、補間後正規化されねばならない。
我々は又、ウィンドウｘ及びｙ座標に関して、テクスチャ座標ｓ及びｔの偏導関数を求めるため、重心係数を使用する。
【０９０２】
【数７４】
2004272928.tif 000099
ｑｎ［ｍ］が１に等しくない場合、Ｗｉ（ｘ，ｙ）はＷｑｉ［ｍ］（ｘ，ｙ）に置き換えられる。
これは、補間されたｓ、ｔとそれらの偏導関数を求める代わりの方法を巧く導入することになる。
【０９０３】
【数７５】
2004272928.tif 000100
同様に、他の項も求めることができる。カラーや法線のように補間する必要がある全ての値は、この平面方程式モードで表し、増分評価法による計算要件を削減するため、三角形情報キャッシュにセーブすることができる。
【０９０４】  以下のように定義する。
【０９０５】
【数７６】
2004272928.tif 000101
ここで、λはレベルオブディテイル（ＬＯＤ）と呼ばれ、ρはテクスチャ・イメージを拡大、または縮小するのを決定するスケール・ファクターと呼ばれる。ｎとｍは２次元テクスチャ・マップの幅と高さである。ｕとｖの偏導関数は、ｓとｔの一部を使用して得られる。１次元テクスチャ・マップでは、ｔ、ｖと偏導関数δｖ／δｘ、δｖ／δｙは０にセットされる。ラインでは、式は以下のようになる。
【０９０６】
【数７７】
2004272928.tif 000102
ＤＳＧＰパイプラインは、２セットのテクスチャ座標を有する４つまでのテクスチャをサポートする。特に、ｉ＝０．．３で、もし：
ＴＥＸＴＵＲＥ＿１Ｄ［ｉ］＝＝１  又は  ＴＥＸＴＵＲＥ＿２Ｄ［ｉ］＝＝１であれば、テクスチャ座標ＴＥＸＴＵＲＥ＿ＣＯＯＲＤ＿ＳＥＴ＿ＳＯＵＲＣＥ［ｉ］を使用してλを計算する。
【０９０７】  フラグメント・ブロックは、各アクティブ・テクスチャに対するｓ、ｔ、ｒ及びλをテクスチャ・ブロックへ送る。λは最終的ＬＤＯではないことに留意されたい。テクスチャ・ブロックは、λの最終的値を得るため、ＬＯＤクランピングのような追加のルールを適用する。
メモリ・キャッシング・スキーム
フラグメントは、必要なオペレーションを実行するため３つのキャッシュを使う。第１のキャッシュはカラー・キャッシュである。カラー・キャッシュは、プリミティブ（三角形、ライン、又はポイント）のためのカラー・データを保持している。キャッシュ・ミス決定及び置き換えの論理は、実際にモード注入ブロックに配置されている。フラグメント・ブロックは、通常、関連するカラー・データを保持しているエントリを指すインデクスを有する「ヒット」パケットを受信する。モード注入ブロックによりミスが検出されれば、新しいデータを使用するために何らかの「ヒット」パケットが送られる前に、新しいデータを有するキャッシュ内のエントリを入替えるために、先ず「フィル」パケットが送られる。従って、キャッシュの置き換え及び使用のロジックが入力パケットは順に処理されると仮定しているため、モード注入により送られるパケットの順序を変えないことが重要である。
【０９０８】  フラグメント・ブロックは、キャッシュ・フィルの間にカラー・キャッシュに書き込む前に、幾つかのデータを変更する。これは、ミス時間中に重心係数を凖備するために行われる。頂点ウィンドウ座標、頂点におけるクリップｗ座標の逆数、及び頂点におけるテクスチャｑ座標は、Ｃｘ［１：０］、Ｃｙ［１：０］、Ｃｋ［１：０］、Ｄｘ、Ｄｙ、Ｄｋ重心座標により使用され、置き換えられる。同様に、Ｓｘ、Ｓｙ、Ｔｘ、Ｔｙ値はキャッシュ・ミスの間に評価され、他のデータと共に記憶される。
【０９０９】  カラー・キャッシュは、一般的に、２５６のエントリ、４セットの関連キャッシュとして編成される。モード注入及びフラグメント・ユニットのマイクロアーキテクチャは、性能目標が保持される前提で、この編成を変えることもできる。これは、全速時には、カラー・キャッシュ・ミスが平均的に処理されたＶＳＰｓの１５％未満であると仮定する。
【０９１０】  半速時に必要なデータは、カラー・キャッシュ内に２つの連続したエントリとして記憶される。このケースで提供されるインデクスは、常に偶数である。
【０９１１】  フラグメント・ブロックにおいて使用されるテクスチャ情報では、２つのテクスチャ・モード・キャッシュが使用される。これらは、それぞれ２つのテクスチャに関する情報を保持する、全く同じに編成されたキャッシュである。２つのテクスチャ・インデクス、ＴＸ０１ＸとＴＸ１ＩＸは、テクスチャ座標を４つまでのテクスチャと関係付けるため、全ての「ヒット」パケットに設けられている。テクスチャ毎に、以下のデータがテクスチャ・モード・キャッシュから読み取られる。
【０９１２】  ＴＥＸＴＵＲＥ＿１Ｄ、ＴＥＸＴＵＲＥ＿２Ｄ、ＴＥＸＴＵＲＥ＿３Ｄは、所与のテクスチャにとり使用可能なビットである。
ＴＥＸＴＵＲＥ＿ＨＩＧＨ、ＴＥＸＴＵＲＥ＿ＷＩＤＴＨは、それぞれ、ｕ及びｖ計算に使用されるｍ及びｎ値を定義する。
ＴＥＸＴＵＲＥ＿ＣＯＯＲＤ＿ＳＥＴ＿ＳＯＵＲＣＥは、どのテクスチャ座標が所与のテクスチャと結びつけられているかを確定する。
【０９１３】  テクスチャ・モード・キャッシュは、３２エントリの完全に関係付けられたキャッシュとして編成される。テクスチャ・モード・キャッシュ０に対する想定ミス割合はＶＳＰ毎に０．２％以下である。
【０９１４】  更に、モードもまた、モード・キャッシュにおいてフラグメント内でキャッシュされる。モード・キャッシュは、完全に関係付けられた、８エントリ・キャッシュとして編成される。想定ミス割合は、ＶＳＰ毎に０．００１％（無視できる量）である。以下の情報はモード・キャッシュにおいてキャッシュされる。
【０９１５】  ＳＨＡＤＥ＿ＭＯＤＥＬ（１ビット）、
ＢＵＭＰ＿ＮＯ＿ＩＮＴＥＲＰＯＬＡＴＥ（１ビット）
ＳＡＭＰＬＥ＿ＬＯＣＡＴＩＯＮ＿ＳＥＬＥＣＴ（３ビット）
他の考察
ＶＳＰのプロセッシングの順序も変えることができる。ピクセル・ブロックの前のリオーダ・バッファは、スタンプを再アッセンブリする。同じｘ及びｙ座標（別々のプリミティブに属する）を共有するＶＳＰは、到着順にピクセルに提供されなければならない。ＶＳＰｐｔｒは、リオーダ・バッファ内のＶＳＰの位置を指示しながら、それぞれのＶＳＰに伴なう。バッファはＦＩＦＯとして編成され、そこでは、シェーディングが完了した最も前のスタンプがピクセル・ブロックに送られる。
【０９１６】  ＶＳＰのプロセッシング順序に対する別の考察は、多様なモード・キャッシュである。モード・インデクスは「ヒット」パケットが「ミス」パケットと重ならないと仮定している。これは「ミス」パケットが「ヒット」パケットに対しバリアを形成することを意味する。明かに、プロセス順序は、下流のブロックがモード注入により提供されたのと同じ順序でパケットを見ることを前提とすれば、対応するモード・キャッシュ情報をフェッチングした後、変えることができる。
ＩＸ．テクスチャ機能ブロック（ＴＥＸ）の詳細な説明
本発明は、新しいグラフィックスプロセッサ及び方法を目指し、専用サブシステム、サブプロセッサ、デバイス、アーキテクチャ、及び対応する手順を含む多くの基礎構造を包含する。本発明の実施の形態は、１つまたはそれ以上のデファードシェーディング、タイル化フレームバッファ、及び多段隠れ表面除去処理、並びに他の構造及び／または手順を含むことができる。本明細書においては、本発明のこのグラフィックスプロセッサをＤＳＧＰ（デファードシェーディンググラフィックスプロセッサ）と称し、また関連パイプラインを“ＤＳＧＰパイプライン”または単に“パイプライン”と呼ぶことにする。
【０９１７】  本発明は、ＤＳＧＰパイプラインの多くの実施の形態を含む。本発明の実施の形態は、フォング（Ｐｈｏｎｇ）シェーディング、サブピクセルエイリアス除去、及びハードウェア内のテクスチャ及びバンプマッピングを有する高性能３Ｄグラフィックスを提供するように設計されている。本ＤＳＧＰパイプラインは、性能を犠牲にすることなく、これらの精緻な特色を提供する。
【０９１８】  ＤＳＧＰパイプラインは、限定するものではないが、例えば、考え得るインタフェース選択の中から、高水準グラフィックスポート（ＡＧＰ）及び／またはＰＣＩバスインタフェースを含むいろいろな考え得るインタフェースを介して、コンピュータに接続することができる。一般的には、ＶＧＡ及びビデオ出力も含まれる。本発明の実施の形態は、ＯｐｅｎＧＬ及びダイレクト３Ｄアプリケーションプログラムインタフェース（ＡＰＩ）の両者を支援する。本明細書は、Ｊｏｎ  Ｌｅｅｃｈ編、Ｍａｒｋ  Ｓｅｇａｌ及びＫｕｒｔ  Ａｋｅｌｅｙ著“Ｔｈｅ  ＯｐｅｎＧＬ  Ｇｒａｐｈｉｃｓ  Ｓｙｓｔｅｍ：Ａ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ（Ｖｅｒｓｉｏｎ  １．２）”ＯｐｅｎＧＬ仕様を参照している。
【０９１９】  以下に、デファードシェーディンググラフィックスパイプラインの幾つかの例示実施の形態を説明するが、特色をいろいろに組合わせて実施の形態を実現することができる。更に、本発明の特色は、他の特色とは無関係に実現することができ、デファード手法でシェーディングを遂行するグラフィックスパイプライン内に排他的に使用する必要はない。
タイル、スタンプ、サンプル、及びフラグメント
３Ｄグラフィックスプリミティブの各フレーム（シーン、またはユーザフレームとも呼ばれる）は、ディスプレイスクリーン上の３Ｄウィンドウ内に描写（レンダー）される。パイプラインはプリミティブを描写し、以下に本発明を、１）三角形、２）線、及び３）点を含む１組の描写可能なプリミティブに関連して説明する。３つより多くの頂点を有する多角形はジオメトリブロックにおいて三角形に分割されるが、本ＤＳＧＰパイプラインは、より多くの辺を有する四辺形または多辺形を描写するように容易に変更することができる。従って、パイプラインはどのような多角形でも、それを一旦三角形に分割した後に描写することが可能であるから、本発明のレンダラーはどのような多角形プリミティブでも効果的に描写することができる。ウィンドウはピクセルの方形格子からなり、ウィンドウはタイル（以下に、タイルは１６×１６ピクセルであるものとするが、どのようなサイズであっても差し支えない）に分割される。もしタイルを使用しないのであれば、ウィンドウは１つのタイルであると見做される。各タイルは、更に、スタンプ（以下に、スタンプは２×２ピクセルであるものとするが、スタンプはタイル内のどのようなサイズであっても差し支えない）に分割される。各ピクセルは１つまたはそれ以上のサンプルを含んでおり、各サンプルはそれ自体のカラー値及びｚ値を有している（以下に、ピクセルは４つのサンプルを含むものとするが、どのような数を使用しても差し支えない）。フラグメントは、特定のピクセル内のプリミティブによってカバーされるサンプルの集まりである。この“フラグメント”という用語は、特定のプリミティブ、及び特定のピクセル内の可視サンプルの集まりを記述するためにも使用される。
デファードシェーディング
通常のＺバッファ描写においては、レンダラーは、各プリミティブの各ピクセル毎のカラー値（ＲＧＢまたはＲＧＢＡ）及びｚ値を計算し、次いで新しいピクセルのｚ値と、Ｚバッファ内のｚ値とを比較する。もしこのｚ値比較において、新しいピクセルがフレームバッファ内に既存するピクセル“の前に”あることが解ればこの新しいピクセルが古いピクセルに上書きされ、そうでない場合には新しいピクセルは破棄される。
【０９２０】  Ｚバッファ描写法は良好に動作し、精密なハードウェアは必要としない。しかしながら、もしシーンが多くの隠れ表面を含んでいれば、それは典型的には大量の処理努力を破棄してしまう。複雑なシーンでは、レンダラーは、最終ピクチャ内で見ることができる多くのピクセルの１０倍から２０倍ものカラー値を計算している。これは、フォングシェーディングまたはテクスチャマッピングのような、どのようなピクセル毎の操作も、その計算費用が１０乃至２０倍されることを意味している。フレーム全体について平均されたピクセル当たりの表面の数を、そのフレームの深さ複雑性と呼ぶ。普通のｚ緩衝されたレンダラーにおいては、深さ複雑性は特定のフレームを描写する時のレンダラーの非効率性の測度である。
【０９２１】  本発明によれば、デファードシェーディングを遂行するパイプラインの隠れ表面除去（ＨＳＲ）は、何れかのピクセルの着色が行われる前に完了する。デファードシェーディングパイプラインの目的は、最終イメージ（即ち、正確なＨＳＲ）内に現れるプリミティブだけのためのピクセルカラーを生成することである。一般にデファードシェーディングは、ＨＳＲを開始できるようになるまでプリミティブを累積する必要がある。１つの不透明なプリミティブだけを有するフレームの場合、ＨＳＲプロセスは全ピクセル内の各サンプルにおける単一の可視プリミティブを決定する。あるサンプルのための可視プリミティブが決定されると、そのサンプル位置におけるそのプリミティブのカラーが決定される。サンプル毎にカラーを計算するのではなく、同一のピクセル内の全てのサンプルのための単一のピクセル毎にカラーを決定することによって、付加的な効率を達成することができる。
【０９２２】  複数のプリミティブの少なくとも若干のアルファ混合（前述したＯｐｅｎＧＬ仕様に定義されている）を伴う（一般的には、透明性に起因する）フレームの場合には、２つまたはそれ以上のプリミティブによって着色される若干のサンプルが存在する。これは、ＨＳＲプロセスがサンプル当たり１組の可視プリミティブを決定しなければならないことを意味している。
【０９２３】  ＯｐｅｎＧＬのような若干のＡＰＩにおいては、ＨＳＲプロセスはプリミティブを破棄する可能性があるような他の操作によって（即ち、深さ試験以外の操作によって）複雑になり得る。これらの他の操作は、ピクセルオーナーシップ試験、シザー試験、アルファ試験、カラー試験、及びステンシル試験を含む（本明細書の別の箇所において説明する）。これらの操作の若干は、ＨＳＲプロセスの後までデファードシェーディングパイプライン内において決定されないそのカラー（アルファ試験のような）に基づいて、あるプリミティブを破棄する（これは、アルファ値がピクセルフラグメント着色内に含まれるテクスチャリングプロセスによって生成されることが多いからである）。例えば、通常はより遠い（一般的には、大きいｚ値の）プリミティブを隠蔽しているプリミティブがアルファ試験によって破棄され、それによってより遠いプリミティブを隠蔽しないようにすることができる。アルファ試験を考慮しないＨＳＲプロセスは、より遠くのプリミティブを誤って破棄しかねない。従って、デファードシェーディングとアルファ試験との（同様に、カラー試験及びステンシル試験との）間に矛盾が存在し得る（即ち、ピクセルの着色はＨＳＲの後まで後回しにされるのに、ＨＳＲはピクセルのカラーに依存させることができる）。この問題の簡単な解決法は、１）ＡＰＩから、アルファ試験、カラー試験、及びステンシル試験のような非深さ依存試験を排除すること（しかしながら、この潜在的解決法は、既存プログラムがデファードシェーディングパイプライン上で適切に実行されることを妨げかねない）、及び２）必要になった場合に限ってＨＳＲプロセスにカラーの生成を行わせること（しかしながら、この可能性のある解決法は、データの流れをかなり複雑にする）を含む。従って、これらの何れかの解決法を選択することは魅力的ではない。保存性（ｃｏｎｓｅｒｂａｔｉｖｅ）隠れ表面除去（ＣＨＳＲ）と称する第３の代替は、本発明の構造及び方法によって提供される重要な革新の１つである。ＣＨＳＲに関しては、本明細書の後節において説明する。
【０９２４】  多くのＡＰＳにおける別の複雑化の要因は、深さ試験を変化させる能力である。３Ｄ描写を考える標準的な手法では、可視オブジェクトは隠蔽されたオブジェクトよりも近くにある（即ち、より小さいｚ値）ものとし、これは“より小さい”深さ試験（即ち、あるオブジェクトは、もしそのｚ値が他のジオメトリ“より小さい”場合には可視であるとする）を選択することによって達成される。しかしながら、殆どのＡＰＩは、より大きい、より小さい、より大きいかまたは等しい、より小さいかまたは等しい、より小さい、等しくない、及び同じような代数的な大きさの、及び論理的な関係のような、他の探さ試験を支援する。これは本質的に、何が見えるのかについて“ルールを変更”する。この複雑化は、アプリケーションプログラムをあるフレーム内の深さ試験に変更することを可能にするＡＰＩによって倍加される。ジオメトリが異なれば、見え方のための規則を大幅に異ならせ得る。従って、異なる描写規則を有するプリミティブの時間順序を考慮に入れなければならない。もしプリミティブをＡ、Ｂ、Ｃの順序で描写するのであれば、プリミティブＣは最終可視表面であろう。しかしながら、もしプリミティブをＣ、Ｂ、Ａの順序で描写するのであれば、プリミティブＡが最終可視表面になる。これは、デファードシェーディングパイプラインがプリミティブの時間順序をどのように保存しなければならないのか、及び正しいパイプライン状態（例えば、深さ試験）を各プリミティブに関連させなければならないことを示している。
デファードシェーディンググラフィックスパイプライン
１９９８年８月２０日付暫定米国特許出願第６０／０９７，３３６号には、新規なデファードシェーディンググラフィックスパイプラインのいろいろな実施の形態が開示されている。本発明及びそのさまざまな実施の形態は、上記デファードシェーディンググラフィックスパイプラインのいろいろな実施の形態内のテクスチャブロックとして使用するのに、またはデファードシェーディングを使用しない他のグラフィックスパイプラインと共に使用するのに適している。便宜上、これらのグラフィックスパイプラインの詳細を重複して説明することは避けることにする。
テクスチャ
グラフィックスパイプラインのテクスチャブロックは、テクスチャマップをピクセルフラグメントに適用する。テクスチャマップは、典型的にはＡＧＰインタフェースを使用してホストコンピュータのメモリからロードされるテクスチャメモリ内に格納されている。一実施の形態においては単一の多角形は８つまでのテクスチャを使用することができるが、別の実施の形態では多角形当たりどのような所望数のテクスチャを使用することもできる。
【０９２５】  本発明の構造及び方法は、有利なことには、テクスチャマップの多重層の三線形（ｔｒｉｌｉｎｉａｒ）マッピング（分解）の使用を可能にする。テクスチャマップは、一般的には、ＡＧＰインタフェースを使用してホストコンピュータのメモリからロードされる単一の緩衝されたメモリからなることができるテクスチャメモリ内に格納される。例示実施の形態では、単一の多角形は８つまでのテクスチャを使用することができる。テクスチャは、ＭＩＰマップされる。即ち、各テクスチャは詳細レベルが異なる一連のテクスチャマップからなり、各マップは眼点から所与の距離におけるテクスチャの現れ方を表している。所与のピクセルフラグメントのためのテクスチャ値を発生させるために、テクスチャブロックはテクスチャマップから三線形補間を遂行して正しい詳細レベルを近似する。テクスチャブロックは、フラグメントブロックと共に、異方性補間のような他の補間方法を遂行する。
【０９２６】  テクスチャブロックは補間されたテクスチャ値（一般的には、ＲＧＢＡカラー値として）を、フラグメント毎の基準で、グラフィックスパイプラインシェーディングブロックへ供給する。バンプマップは、特別な種類のテクスチャマップを表す。バンプマップの各テクセルは、カラーの代わりに、高さフィールド勾配を含んでいる。多重層はＭＩＰ層であり、補間はこれらのＭＩＰ層内に、及びＭＩＰ層の間にある。第１の補間は各層内にあり、次いで２つの隣接する層（一方は名目的に、要求されるより高い分解能を有しており、他方は、要求されるより低い分解能を有している）間が補間されるので、それは最適分解能を生成するように三次元的に遂行される。
テクスチャパイプラインの詳細な説明
図Ｆ２は、本発明により構成されたテクスチャパイプラインの一実施の形態のブロック図である。テクスチャユニット１２００は、個々のフラグメントのためのテクスチャ座標を受け、テクスチャメモリ内に格納されている適切なテクスチャマップにアクセスし、そして各フラグメントのためのテクスチャ値を生成する。テクスチャ値は、下流の、例えばシェーディングブロックへ送られ、シェーディングブロックはそのテクスチャ値をライティングのような他の情報と組合わせてフラグメントのための最終カラー値を生成することができる。
【０９２７】  テクスチャセットアップ１２１１は、例えば前記米国暫定特許出願第６０／０９７，３３６号のフラグメントユニットからデータパケットを受ける。これらのデータパケットは、テクスチャマップのためのテクスチャＬＯＤデータ、及び描写されるイメージのための潜在的に可視のフラグメントデータを供給する。フラグメントデータは、各フラグメント毎の（ｓ，ｔ，ｒ）テクスチャ座標を含んでいる。図Ｆ３に示すように、（ｓ，ｔ）座標は正規化されたテクスチャ空間座標である。３Ｄテクスチャの場合、“ｒ”インデックスはテクスチャ深さを指示するために使用される。ｓ及びｔ座標は浮動小数点数である。テクスチャセットアップ１２１１はｓ及びｔ座標をｉ０、ｉ１、ｊ０、ｊ１（４つの双線形サンプル）、及びＬＯＤＡ／ＬＯＤＢ（三線形ｍｉｐマッピングのための隣接ＬＯＤ）に変換する。ＬＯＤＡ及びＬＯＤＢは４ビットの整数であり、例えばＬＯＤＡは実際のＬＯＤより大きい格納されたＬＯＤであり、ＬＯＤＢは実際のＬＯＤより小さい格納されたＬＯＤである。３Ｄテクスチャの場合、ｒ座標はｋ座標に変換される。三線形ｍｉｐマッピングの実施の形態においては、各フラグメントはそれに関連する８つのテクスチャ座標を有している。ｉ、ｊ、及びＬＯＤ／ｋ値は全て、Ｄｕａｌｏｃｔバンクマッピングユニット１２１２へ送られる。
【０９２８】  フラグメントユニットは、浮動小数点フォーマットでＳ，Ｔ，Ｒ座標を受ける。セットアップはこれらのＳ，Ｔ，Ｒ座標をＵ，Ｖ，Ｗ座標に変換する。これらのＵ，Ｖ，Ｗ座標は、テクスチャルックアップに先だって使用される固定小数点座標である。次いでテクスチャブロックがテクスチャルックアップを遂行し、正規化された空間内にマップされた整数座標であるｉ，ｊ，ｋ座標を供給する。即ちｕ＝ｉ×テクスチャ幅、ｖ＝ｊ×テクスチャ高さ、及びｗ＝ｋ×テクスチャ深さである。
テクスチャマップ
テクスチャマップは、メモリ競合を最小にし、スループットを最大にするための方法を使用してテクスチャメモリ１２１３及びテクセル先取りバッファ１２１６に割当てられる。Ｄｕａｌｏｃｔバンクマッピングユニット１２１２は、ｉ、ｊ、及びＬＯＤ／ｋ座標を、テクスチャメモリ１２１３及びテクセル先取りバッファ１２１６内へマップする。Ｄｕａｌｏｃｔバンクマッピングユニット１２１２は、テクセル先取りバッファ１２１６内に格納されるテクセルのためのタグをも生成する。これらのタグは、８つのタグバンク１２１６−０乃至１２１６−７内に格納される。これらのタグは、テクセルがテクセル先取りバッファ１２１６内に格納されているか否かと、バッファ内のテクセルの位置とを指示する。
【０９２９】  テクスチャメモリ管理ユニット（ＭＭＵ）１２１０は、テクスチャメモリ１２１３へのアクセスを制御する。テクスチャメモリ１２１３は、アクティブテクスチャマップを格納する。もしテクセルがテクセル先取りバッファ１２１６内に見出されなければ、テクスチャＭＭＵ１２１０はテクスチャメモリ１２１３からテクセルを要求する。もしテクセルが、テクスチャメモリ１２１３内に格納されていないテクスチャマップからであれば、図Ｆ２に示すように、そのテクスチャマップは別の資源から検索することができる。いろいろな実施の形態においては、テクスチャメモリは、フレームバッファ１２２１、ＡＧＰメモリ１２２２、仮想メモリ１２２３へのアクセスを有しており、仮想メモリ１２２３自体はディスク１２２４及びネットワーク１２２５へのアクセスを有している。以上のように、テクスチャキャッシュミスと、後刻パイプラインの下方においてそのテクセルが実際に必要とされる時点との間には時間が存在するから、パイプライン内でテクセルを必要とする時点に必要なテクセルが究極的に使用できないようなインスタンスを大幅に減少させるために、ミスの場合に受信されるテクスチャアドレスのためにいろいろな位置が利用可能である。
【０９３０】  所与のフラグメントのためのテクセルを検索した後に、テクスチャ補間器１２１８がテクセルカラー値を補間してそのフラグメントのためのカラー値を生成する。このカラー値はパケット内に挿入され、パイプラインを下方へ、例えばシェーディングブロックまで送られる。
【０９３１】  テクスチャアレイは２×２テクセルブロックに分割される。アレイ内の各テクセルブロックは、テクスチャメモリ内に表される。所与のフラグメントを三線形ｍｉｐマッピングでテクスチャリングするには、そのフラグメントが２×２ブロックの何処に向かうかに依存して、これらのブロックの２つ乃至８つへアクセスすることを必要とする。各フラグメント毎に三線形ｍｉｐマッピングする場合には、８つまでのテクセルをメモリから検索しなければならない。理想的には、８つの全てのテクセルを並列に検索する。図Ｆ４ａに示すように、８つの全てのテクセルを並列に供給するために、テクセル先取りバッファ１２１６は８つの独立的にアクセス可能なメモリバンク１２１６−０乃至１２１６−７からなる。同様に、図５に示すように、テクスチャメモリ１２１３は、チャンネル１２１３−０及び１２１２−１のような複数のチャンネルに編成された複数のテクスチャメモリデバイスを含んでいる。テクスチャ先取りバッファ１２１６から８つの全てのテクセルに並列にアクセスするために、各テクセルは分離した先取りバッファバンク内に格納しなければならない。
テクスチャタイルアドレス指定
メモリスループットを最大にするために、テクスチャマップ内のテクセルは、テクスチャタイルアドレスを使用して空間的にコヒーレントな形状に再マップされる。隣接するフラグメントを生成するのに要するテクセルは、描写されるオブジェクトの向き、及びシーン内のそのオブジェクトの深さ位置に依存する。例えば、視点に対してある大きいスキュー角度をなしているあるオブジェクト内のある表面の隣接フラグメントは、視点に対してほぼ直角な表面の隣接するフラグメントより、選択されたＬＯＤ内で更に遠く離れているテクセルを使用するであろう。しかしながら、典型的には、密接するフラグメントのグループと、それらのフラグメントのためのテクスチャを生成するのに使用されるテクセルとの間にはある空間的なコヒーレンスが存在する。従って、テクスチャマップ内のテクセルのためのテクスチャタイルアドレスは、テクスチャマップの空間的なコヒーレンスを最大にするように限定される。
【０９３２】  図Ｆ６ａは、テクスチャ“スーパーブロック”８００−０乃至８００−３を含むテクスチャマップ８００を含むテクスチャメモリ１２１３のための空間的にコヒーレントなテクセルマッピングを示している。一実施の形態では、テクスチャメモリ１２１３として、カリフォルニア州マウンテンビューのＲＡＭＢＵＳ  Ｃｏｒｐ．製ＲＡＭＢＵＳＴＭメモリを使用している。ＲＭＢＵＳメモリ内の最小アクセス可能データ構造は、１６バイトの“Ｄｕａｌｏｃｔ”である。各テクセルは、フォーマットＲＧＢＡ−８またはＬｕｍ／Ａｌｐｈａ  １６で３２ビットのカラーデータを含む。従って、各Ｄｕａｌｏｃｔ内に４つのテクセルを格納することができる。図Ｆ６ａ及び６ｂのＸ及びＹは、Ｄｕａｌｏｃｔラベルを有している。（Ｘ，Ｙ）座標は（ｉ，ｊ）座標に対応するが、（ｉ，ｊ）の最下位ビットは省かれている。図６Ｆａは、各Ｄｕａｌｏｃｔ内でテクセルがどのように再番号付けされるかを示している。テクセルは、各Ｄｕａｌｏｃｔの原点から開始して順次に番号付けされ、反時計方向順に順次に増加して行く。図Ｆ６ｃは、テクセル位置が、“渦巻きアドレス”部分を含む再構成されたアドレスへの線形アドレッス指定からどのようにして再マップされるかを示している。
【０９３３】  図Ｆ６ｂを参照する。セクタ８００−０−０は、１６  Ｄｕａｌｏｃｔのための渦巻きパターンマッピングを示している。各Ｄｕａｌｏｃｔ内の４ビットラベルは、ＤｕａｌｏｃｔをＲＡＭＢＵＳテクスチャメモリ１２１３及びテクセル先取りバッファ１２１６内に格納するためのアドレスを発生するのに使用されるＤｕａｌｏｃｔ番号を指示する。図Ｆ６ｂに示す各Ｄｕａｌｏｃｔは、図Ｆ６ａに示すように配列された４つのテクセルを含んでいる。Ｄｕａｌｏｃｔは、原点から開始して反時計方向に移るように４つのグループ内で順次に再番号付けされている。Ｄｕａｌｏｃｔのグループの再番号付けの後に、反時計方向に移って４つのＤｕａｌｏｃｔの次のグループが選択される。セクター内の４つの全てのグループが再番号付けされた後に、Ｄｕａｌｏｃｔブロックの周りを反時計方向に移って再番号付けパターンが次のセクター（即ち、セクター８００−０−１）について繰り返される。例えばセクタ８００−０−０内の１６Ｄｕａｌｏｃｔの後のＤｕａｌｏｃｔ番号は、セクター８００−０−１内へ続く。セクター８００−０−１はＤｕａｌｏｃｔ番号１６−３０を含み、これらはセクク８００−０−０と同一のパターンで番号付けされている。このパターンはセクター８００−０−２において、及びセクター８００−０−３において繰り返される。Ｄｕａｌｏｃｔブロック０（８００−０）は、４つのセクター８００−０−０乃至８００−０−３からなる。Ｄｕａｌｏｃｔブロック０のパターンは、Ｄｕａｌｏｃｔブロック１（８００−１）においてＤｕａｌｏｃｔ番号６４から開始して繰り返され、次いでＤｕａｌｏｃｔブロック２（８００−２）、及びＤｕａｌｏｃｔブロック３（８００−３）において繰り返される。一実施の形態においては、再帰的渦巻きパターンはテクスチャスーパーブロック０（８００）レベルにおいて停止する。
【０９３４】  代替として、図Ｆ６ａ及び６ｂに示す再帰的渦巻きパターンではなく、空間的にコヒーレントなパターンが代替実施の形態に使用されている。図Ｆ７は、１つのこのような代替パターンを使用してマップされたテクスチャマップのスーパーブロック９００を示している。スーパーブロック９００は、セクター０−１５を含んでいる。各セクター内のＤｕａｌｏｃｔ番号付けパターンは、図Ｆ８に示すテクスチャスーパーブロック０（８００）のパターンと同一のスーパーブロック９００パターンである。しかしながら、セクターレベルにおいて反時計方向渦巻きパターンを繰り返すのではなく、セクタレベルにおけるＤｕａｌｏｃｔ番号は図Ｆ７のセクタ番号０−１５によって示されているパターンに従って渦巻きサイズを６４×６４テクセルに制限している。
【０９３５】  図Ｆ８は、テクスチャマップ１０００のスーパーブロックレベルにおけるＤｕａｌｏｃｔ番号付けパターンを示している。若干の実施の形態においては、６４×６４を越えるテクセル再帰的渦巻きパターンは空間的な局所参照性（もしくは、ローカリティ）を傷つけることが解っているので、スーパーブロックレベルにおいてパターンは簡単な線形マッピングに変化している。渦巻きは本質的に方形動作であり、矩形であって非方形のテクスチャ、及び境界線情報を有するテクスチャの大きいサイズでは極めて良好に動作しないことを暗示している。本発明の若干の実施の形態において渦巻きを６４×６４に制限することは、管理可能なメモリの量を最小の割当てられたサイズに制限している。本発明によるこの渦巻きスキームは、ミス要求にサービスする時に取り出される４つのサンプルが先取りされたバッファの別個のメモリバンク内に存在するようになり、従ってバンク競合を回避する。更に、この渦巻きスキームは、先取りされたバッファへの爾後のヒットを最大にしてミスを典型的に分散させるので、メモリシステムが要求にサービスしている間にテクスチャユニットはヒッとされたデータを操作でき、従って立ち往生が最小になる。テクスチャスーパーブロック０（８００）の後のＤｕａｌｏｃｔの次のスーパーブロックは、テクスチャスーパーブロック０（８００）の直ぐ右に位置する。この線形パターンはスーパーブロックｎ／６４まで繰り返され、次いで、図示のようにスーパーブロックｎ／６４＋１から新しいスーパーブロックの行が開始される。
【０９３６】  図Ｆ８ａ、Ｆ８ｂ、及びＦ９に示されている空間的にコヒーレントなテクセルマッピングパターンは、あるフラグメントのためのテクスチャを生成するために使用される４つのテクセルが、分離したテクセル先取りバッファ１２１６バンク、または分離したテクスチャメモリ１２１３デバイスの何れかの中に格納される可能性を最大にするように設計されている。
メモリアドレッシング
図４ａを参照する。テクセル先取りバッファ１２１６は、８つの先取りバッファバンク１２１６−０乃至１２１６−７を含んでいる。図４ａは、図Ｆ６ｂ内の番号付けされたＤｕａｌｏｃｔが、どのように８つの先取りバッファバンク１２１６−０乃至１２１６−７内へマップされるかを示している。また、図には、メモリ競合を生ずることなしに、図Ｆ６ａに示されている特定のピクセル位置８９９のために取り出された４つのテクセルも示されている。図Ｆ４ａは、１つのＬＯＤのために格納されているテクセルを示している。三線形マッピングの場合、バンク１２１６−４乃至１２１６−７は第２のＬＯＤのためのテクセルを含む。
【０９３７】  図Ｆ５は、テクスチャメモリ１２１３の一実施の形態のブロック図である。テクスチャメモリ１２１３は、２つのチャンネル１２１３−０及び１２１３−１を有している。各チャンネルは、８つのデバイス１２１３−０−０乃至１２１３−０−７、及び１２１３−１−０乃至１２１３−１−７をそれぞれ含んでいる。各デバイスは独立したアドレスのセット、及び独立したＩ／Ｏデータラインを有していて、８つの各デバイスに独立的にアクセスできるようにしている。各デバイスは１６のバンクを含み、これは、この実施の形態では２５６のオープンページが存在し、明らかにメモリ競合の可能性を減少させていることを意味している。一実施の形態では、各チャンネルは６４Ｍバイトメモリである。
【０９３８】  テクスチャマップ内のテクセルを空間的にコヒーレントなフォーマットにマップするために、Ｄｕａｌｏｃｔバンクマッピングユニット１２１２は、各Ｄｕａｌｏｃｔ毎にテクスチャタイルアドレスを生成する。図Ｆ９は、本発明の一実施の形態によるテクスチャタイルアドレスデータ構造１１８０を示している。テクスチャフィールドＩＤ１１８１フィールドは、参照されているテクスチャを限定する１１ビットのフィールドである。２０４８までの異なるテクスチャを、単一のディスプレイ内に使用することができる。これらのテクスチャは、どのようなメモリ資源内にも格納することができる。次いで各フラグメントは、８つまでの異なるテクスチャを参照することができる。テクスチャ先取りバッファ１２１６内に存在していないテクスチャが参照されると、テクスチャＭＭＵ１２１０は外部メモリ資源からメモリをロードし、またもし必要ならば所要テクスチャ先取りバッファ１２１６空間の割当てを解除して新しいテクスチャをロードする。ＬＯＤフィールド１１８２は、選択されたテクスチャマップ内に使用されるＬＯＤを限定する４ビットのフィールドである。Ｕ、Ｖフィールド１１８３及び１１８４は、０から２０４７までの範囲を有するテクスチャ座標のための１１ビットのフィールドである。各Ｄｕａｌｏｃｔ毎のＵ、Ｖフィールドは、図Ｆ８ａ及びＦ８ｂに示すフォーマットのような空間的にコヒーレントなフォーマットを生成するように定義されている。３Ｄテクスチャの場合、テクスチャフィールドＩＤ１１８１の４つのＬＳＢは、ｋ座標から生成されたテクスチャ深さインデックスであるテクスチャＲ座標の４つのＭＳＢを含む。Ｄｕａｌｏｃｔバンクマッピングユニット１２１２は、パイプライン内に３Ｄテクスチャ操作があれば必ず４つのＲ座標ビットを供給する。次いで、２Ｄ及び１Ｄアドレスと同じように、３Ｄテクスチャタイルアドレスが不可欠的に処理される。
【０９３９】  テクスチャタイルアドレスはテクスチャＭＭＵ１２１０へ供給され、テクスチャＭＭＵ１２１０は対応するテクスチャメモリアドレスを生成する。テクスチャＭＭＵ１２１０は、テクスチャメモリ１２１３内に格納されているテクスチャメモリアドレスの表内へのテクスチャタイルアドレスの線形マッピングを使用してテクスチャタイルアドレスからテクスチャメモリアドレスへの変換を遂行する。この表はソフトウェアによって維持されている。図Ｆ１０は、ＲＡＭＢＵＳＴＭテクスチャメモリ１２１３のためのテクスチャメモリアドレスデータ構造を示している。テクスチャメモリアドレスデータ構造１２８０は、あるフラグメントのためのテクスチャを生成するのに必要なＤｕａｌｏｃｔが、図Ｆ５に示すように異なるテクスチャメモリページ内に格納される可能性を最大にするように設計されている。一実施の形態においては、デバイスフィールド１２８５は、テクスチャメモリアドレスデータ構造１２８０の最下位の３ビットからなる。デバイスフィールド１２８５は、Ｄｕａｌｏｃｔが格納されているテクスチャメモリデバイスを限定する。従って、マップされたテクスチャによって定義される各順次Ｄｕａｌｏｃｔは、異なるテクスチャメモリデバイス内に格納される。次の４つの低位ビットはバンクフィールド１２８４であり、次の１ビットはチャンネルフィールド１２８３であり、次の９ビットは行フィールド１２８２であり、そして次の６ビットは列フィールド１２８１である。
【０９４０】  テクスチャメモリアドレスデータ構造１２８０は、プログラム可能でもある。このようにすると、テクスチャメモリアドレスを異なるメモリ構成に適合させることも、またテクスチャデータへのアクセスを最適化するためにテクスチャメモリアドレスのビットフィールドの配置を変更することも可能になる。例えば、代替メモリ構成は、８つより多くのテクスチャメモリデバイスを有することができる。
【０９４１】  テクセルは、テクスチャメモリ１２１３からテクセル先取りバッファ１２１６内へロードされて高速アクセスを提供する。テクセルがテクセル先取りバッファ１２１６内へ移動すると、図Ｆ４ｂに示すように、対応するタグが８つの先取りバッファタグブロック１２２０−０乃至１２２０−７の１つ内に作成される。８つの各タグブロック１２２０−０乃至１２２０−７は、対応するメモリ待ち行列１２３０−０乃至１２３０−７を有している。タグが６４エントリであり、キャッシュＳＲＡＭが２５６エントリであることに注目されたい。このマッピングによって、図Ｆ４ａのテクセル先取りバッファ１２１６内に示すように、各先取りバッファタグエントリは４つの先取りバッファバンクにまたがる４つのテクセルの“線”をマップすることができる。このマッピングにより、各サイクルに４つのテクセルを４つの分離した先取りバッファバンクから検索することができ、従って最大データアクセス帯域幅が保証される。各タグブロックは、サイクル当たり１つまでのテクスチャタイルアドレスを受けることができる。テクスチャタイルアドレスは、４テクセルの特定Ｄｕａｌｏｃｔを指し示す。各タグブロックエントリは、テクセル先取りバッファ１２１６メモリ内のテクセルの１つのＤｕａｌｏｃｔ線を指し示す。到来するテクスチャタイルアドレスはタグブロックの内容について調べられ、テクセル先取りバッファ１２１６内に所望のＤｕａｌｏｃｔが格納されているか否かが决定される。
【０９４２】  図Ｆ４ａは、１つのＬＯＤのために格納されるテクセルを示している。三線形ｍｉｐマッピングの場合、バンク１２１６−４乃至１２１６−７は第２のＬＯＤのためのテクセルを含んでいる。テクスチャタイルアドレス内のテクスチャＩＤ１１８１ビット［２６］は、あるＬＯＤを、先取りバッファバンク０−３（１２１６−０乃至１２１６−３）へマップするのか、またはバンク４−７（１２１６−４乃至１２１６−７）へマップするのかを制御するために使用される。もしテクスチャＩＤ１１８１ビット［２６］＝０であれば、偶数ＬＯＤ（ＬＯＤ［２２］＝０）が先取りバッファバンク０−３内へマップされ、奇数ＬＯＤ（ＬＯＤ［２２］＝１）が先取りバッファバンク４−７内へマップされる。反対に、もしテクスチャＩＤ１１８１［２６］＝１であれば、奇数ＬＯＤが先取りバッファバンク０−３内へマップされ、偶数ＬＯＤが先取りバッファバンク４−７内へマップされる。このマッピングにより、各サイクル中に８つの全てのタグにアクセスできること、及びテクスチャ情報をキャッシュ内に均一に分布させることが保証される。またＤｕａｌｏｃｔバンクマッピングユニット１２１２は、テクスチャタイルアドレスを、図Ｆ４ｂに示す対応するタグブロック１２２０−０乃至１２２０−７へ送る時に、このＬＯＤマッピング規則に従う。
【０９４３】  あるフラグメントのためのテクスチャを生成するために、Ｄｕａｌｏｃｔバンクマッピングユニット１２１２は８つまでのＤｕａｌｏｃｔ要求を生成し、それらを適切な先取りバッファバンクへ送る。先取りバッファタグ１２２０−０乃至１２２０−７の一致が調べられる。もしヒットが存在すれば、その要求はメモリ待ち行列１２１９の適切なバンクへ送られる。メモリ要求がメモリ待ち行列を出ると、テクセル先取りバッファ１２１６へ線番号が送られてデータをルックアップさせる。もし所与のテクスチャタイルアドレス上にミスが存在すれば、ミス要求が、対応するタグブロックのためのミス待ち行列内へ配置される。ミスアドレスは究極的にミス待ち行列から読出され、テクスチャＭＭＵ１２１０へ送られる。次いでミス要求がサービスされ、データがテクスチャメモリ１２１３または別の外部メモリ資源から検索され、究極的には適切なテクセル先取りバッファバンク１２１６−０乃至１２１６−７へ供給される。
【０９４４】  メモリ待ち行列１２１９内の各線は、データの１つのフラグメントに対する特定のテクスチャ操作のための１つのメモリアクセスをレコードする。メモリ要求はメモリ待ち行列１２１９の最上部に受けられ、それらが最下部に達した時にテクセル先取りバッファ１２１６がそのデータのためにアクセスされる。ミスデータは、特定のミス要求が、対応するメモリ待ち行列１２３０−０乃至１２３０−７のボトムに到達した時に限ってテクセル先取りバッファ１２１６内へファイルされる。
【０９４５】  ８つの各メモリ待ち行列１２３０−０乃至１２３０−７は、ペンディング中の８つまでのミスアドレスを特定の先取りバッファバンク１２１６−０乃至１２１６−７のために保持する。もしメモリ待ち行列が空でなければ、それは少なくとも１つの有効アドレスを含んでいるものと見做すことができる。各クロックサイクル中に、先取りバッファコントローラ１２１８はメモリ待ち行列１２３０−０乃至１２３０−７を走査して有効エントリを探索する。ミスアドレスが見出されれば、それはテクスチャＭＭＵ１２１０へ送られる。
【０９４６】  図Ｆ９は、テクセル先取りバッファ１２１６のためのタグとして役立つテクスチャタイルアドレス構造である。このタグがテクセル先取りバッファミスを指示した時には、テクスチャメモリ１２１３のルックアップが必要である。仮想アドレス構造は、１１ビットのテクスチャＩＤ１１８１、４ビットのＬＯＤ１１８２、及び１１ビットのＵ及びＶアドレス１１８３及び１１８４を含んでいる。図Ｆ９のこの仮想アドレスは、タグメモリ１２１０−０乃至１２１２−７（図Ｆ２）内のタグエントリとして役立つ。ミスの場合には、テクスチャメモリ１２１３内のルックアップが必要である。
【０９４７】  図Ｆ１０は、例えばテクスチャメモリの専用部分内に格納されているポインタルックアップ変換タグブロック１１９０を示しており、１１ビットのテクスチャＩＤ及び４ビットのＬＯＤ番号（図Ｆ１０のポインタを探知するための１５ビットのインデックスを形成している）を使用してアドレスされる。ポインタは、一旦探知されると、所望のテクスチャ／ＬＯＤの開始が格納されているテクスチャメモリ内の基底アドレスを指し示す。次いでこの基底アドレスに、仮想アドレスのＵ及びＶ成分によって作成されるアドレスが追加され、Ｄｕａｌｏｃｔの仮想アドレスが作成される。このＤｕａｌｏｃｔの仮想アドレスは、図Ｆ１１のアドレス構造を使用してＲＡＭＢｕｓメモリの物理アドレスにマップされる。
【０９４８】  図Ｆ１２は、図Ｆ６ｃ、Ｆ９、Ｆ１０、及びＦ１２に関連して、アドレスを再構成するためのアドレス再構成及びプロセスを示す図である。図Ｆ１２に示すように、テクスチャタイルアドレス構造１１８０（図Ｆ９を参照して説明済み）は、テクセル先取りバッファ１２１６のためのタグとして役立つ。このタグがテクセル先取りバッファミスを指示した場合には、テクスチャメモリ１２１３のルックアップが必要である。変換バッファ１１９１は、１１ビットのテクスチャＩＤ及び４ビットのＬＯＤを使用して、ポインタルックアップ変換タグブロック１１９０（図Ｆ１０を参照して説明済み）への１５ビットのインデックスを形成する。渦巻きアドレスブロック１１９２は、テクスチャタイルアドレスデータ構造１１８０からのビットを再マップし、“渦巻きアドレス”１１９４（図Ｆ６ａ−６ｃを参照して説明済み）を形成する。加算器１１９３は、ポインタルックアップ変換タグブロック１１９０と“渦巻きアドレス”１１９４とを組合わせ、ＲＡＭＢｕｓメモリをアドレスするための物理アドレス１２８０を形成する（図Ｆ１１を参照して説明済み）。
再順序付けロジック
図Ｆ１３ａは、読出しミス制御回路２６００の一実施の形態を示すブロック図である。読出しミス制御回路２６００は、所望の情報がテクスチャ先取りバッファ１２１６内に含まれていないことをタグメカニズムが決定した時に、読出しミス要求を図２に示すミスロジックから受ける。読出しミス要求には４つの型が存在する。即ち、テクスチャルックアップ（ミス）、コピーテクスチャ、読出しテクスチャ、及びＡｕｘｒｉｎｇ読出しＤｕａｌｏｃｔ（メンテナンスユーティリティ機能）である。読出し制御回路２６００によって受けられた読出しミス要求は、順位付けブロック２６２０によって、例えば上記リスト順に順位が付けられる。順位付けブロック２６２０は、アクセスされるテクスチャメモリアドレス内に含まれるチャンネルビット（図Ｆ８）に基づいて、読出し要求を適切なチャンネルへ送る。これらのアドレスは、要求待ち行列２６２１−０及び２６２１−１へ送られる。これらの待ち行列は、一実施の形態では３２アドレス深さである。要求待ち行列２６２１−０及び２６２１−１内に格納されたアドレスは、再順序付け論理回路２６２３−０及び２６２３−１へそれぞれ印加され、再順序付け論理回路２６２３−０及び２６２３−１は、ＲＡＭＢｕｓメモリコントローラ２６４９にアクセスする。図Ｆ１３ｂを参照して以下に説明するように、テクスチャメモリにおけるメモリ競合を回避するために、再順序付け論理回路２６２３−０及び２６２３−１は要求待ち行列２６２１−０及び２６２１−１から受けたアドレスを再順序付けする。再順序付け論理回路２６２３−０及び２６２３−１は、ＲＡＭＢｕｓメモリコントローラ２６４９によってアクセスされるメモリアドレスを再順序付けするから、タグ待ち行列２６２２はチャンネル及びリクエスタ情報を追跡する。アクセスされたデータは適切順序（ｉｎ−ｏｒｄｅｒ）戻り待ち行列２６２４へ出力され、その結果は待ち行列２６０９及び２６１０によって指示される元の順序に基づいて適切なスロット内へ配置される。適切な順序で適切順序戻り待ち行列２６２４内に格納されたデータは、データ及びデータ有効信号としてそのリクエスタへ供給される。一実施の形態では、データはＤｕａｌｏｃｔに対応する１４４ビット幅で出力される。
【０９４９】  図Ｆ１３ｂは、再順序付けロジック２６２３−０（再順序付けロジック２６２３−１は同一である）を含む本発明の一実施の形態のブロック図であって、ＲＡＭＢｕｓコントローラ２６４９を示している。再順序付けロジック２６２３の目的は、到来するアドレス要求を監視し、ＲＡＭＢｕｓコントローラ２６４９内のメモリ競合を回避するようにこれらの要求を再順序付けすることである。バス２６０１上の要求として受けた各メモリアドレス毎に、競合検出ブロック２６０２は第１レベル再順序付け待ち行列２６０３内に含まれているアドレスに基づいてメモリ競合が発生する可能性があるか否かを決定する。もし否であれば、そのアドレスは制御ブロック２６０５へ直接送られ、第１レベル再順序付け待ち行列２６０３に追加されて爾後に受けれるアドレスの競合検査のために役立つ。一方、もし競合検出ブロック２６０２によって競合の可能性があると決定されれば、競合するアドレス要求は競合待ち行列２６０４へ送られる。一実施の形態では、競合するアドレス要求が同じ最近の時間フレーム内に受けられた他の要求から離れ過ぎて利用されるのを防ぐために、３２のアドレス要求が競合検出ブロック２６０２によって受けられ、制御ブロック２６０５へ送られるか（無競合）、または競合待ち行列２６０４内に配置され、その後に競合待ち行列２６０４内に格納されたアドレスは制御回路２６０５へ出力される。このようにすると、再順序付けされたアドレス要求は再順序付けアドレス待ち行列２６０６へ印加され、より少ない（０回であることが多い）競合でＲＡＭＢｕｓメモリコントローラ２６４９にアクセスする。これは、読出し要求を、どのような再順序付けもせずに元の順序でＲＡＭＢｕｓメモリコントローラ２６４９に直接印加する場合に発生する競合状況とは対照的である。
【０９５０】  適切順序タグ待ち行列２６０９及び不適切順序（ｏｕｔ−ｏｆ−ｏｒｄｅｒ）タグ待ち行列２６１０は、元のアドレス順序を保存するためにタグ情報を維持しているので、結果がルックアップされ、再順序付けロジック２６２３−０及び２６２３−１から出力される時には所望の（元の）順序が維持される。
【０９５１】  ＲＡＭＢｕｓメモリコントローラ２６４９から読出された情報は、読出しデータ待ち行列２６１１内に格納される。制御ブロック２６１２を通して、待ち行列２６１１からのデータは不適切順序待ち行列２６１３または適切順序待ち行列２６１４の何れかへ送られる。制御ブロック２６１５は、待ち行列２６１３及び２６１４からのデータを元の要求順序で再アセンブルし、それをブロック２６１４の適切なチャンネルボートへ順番に送る。制御ブロック２６２４は、ブロック２６２３−０及び２６２３−１からチャンネル特定データを受け、それを再結合して待機中のリクエスタへ戻して供給する。
【０９５２】  本発明のパイプラインはテクスチャメモリを含み、テクスチャメモリは先取りバッファを含んでいる。ホストもテクスチャのための記憶装置を含んでおり、それは典型的には極めて大きいが、テクスチャを描写するためにそれをテクスチャメモリ内へロードしなければならない。各ＶＳＰに関連しているのはＳ及びＴである。三線形ＭＩＰマッピングを遂行するためには必ず８つのサンプルを混合するので、本発明の構造は並列に走る一組８つの連想（内容参照可能な）（メモリ）キャッシュを提供する。一実施の形態では、キャッシュ識別子は連想タグの１つであり、それが、キャッシュのタグ部分及びキャッシュのデータ部分が別々に探知される理由である。慣習的にタグ及びデータは同時に探知されるので、タグによる問合わせによってデータが与えられる。本発明の構造及び方法においては、タグ及びデータは分割され、インデックスがパイプラインを下方へ送られる。
【０９５３】  データ及びタグは異なるブロック内に格納され、連想ルックアップはアドレスのルックアップまたは問合わせであり、またそれ自体内のアドレスに格納されている“データ”、異なるブロック内に格納されている実際のデータを参照するインデックスでさえもある。インデックスが決定され、インデックスによって参照されたデータを決定することができるようにパイプラインを下方へ送られる。換言すれば、タグは１つの位置であり、テクスチャデータは第２の位置にあり、インデックスは２つの記憶構造の間のリンクを構成している。
【０９５４】  本発明の一実施の形態においては、先取りバッファは、一般的にテクセル補間器と同一の集積回路上に配置されている複数の連想メモリからなる。好ましい実施の形態においては、テクスチャブロックにおいてテクセル再使用検出方法が遂行される。
【０９５５】  従来の３Ｄグラフィックスパイプラインにおいては、空間内のある向きのオブジェクトが描写される。オブジェクトは、それに関連するテクスチャマップを有しており、このテクスチャマップは多くの三角形プリミティブによって表される。ソフトウェアで実現する手順は、ハードウェアに命令して特定のオブジェクトテクスチャをテクスチャメモリ内へロードさせることである。次いで、特定のオブジェクトに共通の、従って同一のテクスチャマップを有する全ての三角形がユニット内へ送給され、テクスチャ補間が遂行されてその特定のオブジェクトを表すのに必要な着色されたピクセルの全てが生成される。そのオブジェクトが着色されてしまうと、ＤＲＡＭ内のテクスチャマップは破棄することができる（何故ならば、例えば再割当てアルゴリズムによってオブジェクトが描写されているからである）。もし、複数の同一のオブジェクト（多分、異なる向きまたは位置にある）のような、同一テクスチャマップを有する１つより多くのオブジェクトが存在すれば、ＤＲＡＭ内のテクスチャマップが破棄される前に、その型のオブジェクトの全てを望ましくテクスチャ化することができる。異なるジオメトリを送給することはできるが、同一のテクスチャマップを全てに対して使用すれば、ホストメモリからテクスチャマップを繰り返し検索し、それを１つまたはそれ以上のパイプライン構造内に一時的に配置する必要性を排除することができる。
【０９５６】  従来技術のより精緻なスキームでは、１つより多くのテクスチャマップを検索し、メモリ内に格納することができる。例えば、２つまたは幾つかのマップを、使用可能なメモリ、テクスチャマップのサイズ、複数のテクスチャマップを格納または保持する必要性、及び管理計画の精緻さに依存して格納できる。これらの従来の各テクスチャマッピングスキームは、空間的なオブジェクトコヒーレンスが特に重要である。少なくとも単一オブジェクト全体について、典型的には同一テクスチャマップを使用するオブジェクトのグループについて、そのオブジェクトを作っている全ての三角形は一緒に処理される。三角形はオブジェクトを形成し、空間において接続され、従って空間的にコヒーレントであるので、このスキームに空間的コヒーレンシーというフレーズを当てる。
【０９５７】  本発明の構造及び方法においては、大きさを決めることが可能なメモリがカード上に支持されている。一実施の形態には１２８メガバイトを設けてあるが、より多くの、またはより少ないメガバイトを設けることができる。例えば、ユーザの要望、メモリのために基板上で使用可能な実エステート、及び使用可能なメモリの密度に依存して、３２Ｍｂ、６４Ｍｂ、２５６Ｍｂ、５１２Ｍｂ、またはそれ以上を設けることができる。
【０９５８】  次のフラグメントのための８つのテクセルを検索し、格納することができるように、各可視フラグメント毎に８つのテクセルを読出し、それらを使用し、そしてそれらを破棄するのではなく、本発明の構造及び方法は、それらを再度必要とするような合理的な機会が存在する場合には、それらを再使用する。
【０９５９】  可視フラグメントを受信する度に８つのテクセルを読出し、破棄するのは実際的ではない。そうではなく、これらのテクセルを再使用するようにすることが望ましい。何故ならば、もし貴方がタイル空間内に沿って進んで行くものとすれば、そのタイル内の貴方のピクセル格子（典型的には、方形タイルピクセル格子内の順次の行に沿って処理される）が向こうから迫って来るので、順次ピクセルにとっては同じテクスチャマップは必要ではないが、そのタイルのある領域内にクラスタされている幾つかのピクセルにとっては同じテクスチャマップが必要であるかも知れず、従って、最初の使用の後の数プロセスステップだけにとっては必要であるかも知れないからである。本発明は何回も何回も読出されたテクセルを使用するので、１つのテクセルを必要としてそれを読出す場合に、特定のテクスチャマップを必要とする１つのフラグメントを１回でも見たことがあることが有利であること、そして同一タイル内にある間に同一オブジェクトからの同一テクスチャを必要とする別のフラグメントに遭遇するようなその後のある時間期間にわたって有利であることを知ることが望ましい。従ってこれらのものをこのキャッシュ内に保管し、次いでオンザフライ式でキャッシュ（テクスチャ再使用レジスタ）から必要とするものをルックアップする。もし、例えばフラグメント及びテクスチャマップに始めて遭遇した時にキャッシュミスが存在すれば、そのテクスチャマップが検索されキャッシュ内に格納される。
【０９６０】  テクスチャマップ検索待ち時間は別の関心事であるが、先入れ先出し（ＦＩＦＯ）データ構造、及びルックアヘッドまたは予測検索手順を使用することによって処理される。ＦＩＦＯは大きく、ＣＡＭと共同して動作する。あるアイテムが必要である場合、それが既に格納されているか否かについての決定が行われ、また指名子がＦＩＦＯ内に配置されるので、もしキャッシュミスが存在すれば、情報を検索し、それを格納するために比較的遅いメモリへ向かわせることは可能である。もしデータがキャッシュ内にあるか、またはそれがホストメモリから検索されるような何れの場合も、それはユニットメモリ内へ（及び、もし新たに検索されればキャッシュ内へも）配置される。
【０９６１】  ＦＩＦＯは実効的に一種の遅延として働くので、テクスチャに対する必要性が識別されれば（その実際の使用の前に）、検索によって典型的に処理がスローダウンしないように、データは、それを必要とする前に検索し、再結合することができる。ＦＩＦＯ待ち行列は、それが常に予測し、先読みするようにパイプライン内にスラックを与え、スラックを縮める。ＦＩＦＯを調べることによって、非キャッシュテクスチャを識別し、ホストメモリから検索し、キャッシュ及び特別なユニットメモリ内に配置することができるので、読出しが実行される時に容易に使用することが可能である。
【０９６２】  オブジェクト毎の処理に典型的に使用される空間的オブジェクトコヒーレンスが、我々のタイル毎の処理では失われる場合に発生する問題を解消するために、ルックアヘッド及び予測検索を提供するＦＩＦＯ及び他の構造が設けられている。本発明の構造及び方法は、あるオブジェクト内におけるどのような空間的コヒーレンスも使用できるようにするので、もし１つのオブジェクト内の全てのピクセルが順次に遂行されるのであれば、本発明は時間的及び空間的コヒーレンスが存在するという事実を利用することにも注目されたい。
【０９６３】  テクスチャブロックは、ローカルな再使用を行うためにテクセルをキャッシュする。テクスチャマップは、１８バイトのブロックで格納できる法線ベクトルの場合を除いて、ＲＧＢＡデータ（１６バイト／ブロック）の２×２ブロックでテクスチャメモリ内に格納される。
仮想テクスチャ番号
ユーザは、ＯｐｅｎＧＬ呼出しを有するテクスチャが、ユーザ空間から通過する時にテクスチャ番号を与える。ユーザは、１つのマップと共にテクスチャされる若干の三角形を送り、次いで同一テクスチャ番号に関連するテクスチャデータを同一フレーム内の他の三角形にテクスチャするために変化させることができる。本パイプラインは、あるフレームのためのテクスチャデータの全てのセットをテクスチャブロックが使用できるようにすることを要求する。ドライバは、各テクスチャマップに仮想テクスチャ番号を割当てる。
テクスチャメモリ
テクスチャメモリは、テクスチャブロックが現在使用中のテクスチャアレイを格納する。ソフトウェアがテクスチャメモリを管理し、テクスチャアレイをホストメモリからテクスチャメモリ内へコピーする。またソフトウェアは、テクスチャアレイアドレスの表をテクスチャメモリ内に維持する。
テクスチャアドレス指定
テクスチャブロックは、仮想テクスチャ番号及びＬＯＤによってテクスチャアレイを識別する。最高ＬＯＤのためのアレイは、単一レコード内へひとまとめにされる。テクスチャアレイポインタ表は、テクスチャアレイＩＤ（ＬＯＤと連結された仮想テクスチャ番号）とテクスチャメモリ内のアドレスとを結合させる。数千のテクスチャアレイポインタを支援する必要があるので、テクスチャアレイポインタ表をテクスチャメモリ内に格納しなければならない。ほぼ５００Ｍ回／秒で、テクスチャアレイＩＤをアドレスにマップする必要がある。幸いなことに、通常は隣接するフラグメントが同一のテクスチャアレイを共用しているので、テクスチャアレイポインタのためのキャッシュとの良好なヒット率が得られる。（一実施の形態では、テクスチャアレイキャッシュのサイズは１２８エントリであるが、より大きい、またはより小さい他のサイズを実現することもできる。）
テクスチャブロックは、メモリ内のポインタ表を探索するための直接マップアルゴリズムを実現する。ソフトウェアは、ハードウェアルックアップスキームを使用してテクスチャアレイポインタ表を管理し、表要素を格納させる。
テクスチャメモリ割当て
ソフトウェアは、テクスチャメモリの割当てを処理する。テクスチャブロックは、それがテクスチャメモリ内に既存していないテクスチャアレイを必要とする時に、ホストへ割込みを送る。ホストは、テクスチャアレイを主メモリフレームバッファからテクスチャメモリへコピーし、上述したようにテクスチャアレイポインタ表を更新する。ホストは、新しいデータによってどのテクスチャアレイが上書きされるのかを制御する。
【０９６４】  ホストは、ごみ集め等を行うためにテクスチャメモリを再配列する必要がある。ハードウェアは、（ａ）ホストからメモリへ、（ｂ）メモリからホストへ、及び（ｃ）メモリからメモリへのメモリコピーを支援する。
Ｘ．フォング機能ブロック（ＰＨＧ）の詳細な説明
従来のライティング／バンプマッピングアプローチ
説明中の本発明は、デファードシェーディングアーキテクチャにおける接線空間ライティングを遂行するためのシステム及び方法である。詳細な説明において記述するように、本発明の浮動小数点集中ライティング計算により実現されているデファードシェーディングアーキテクチャは、グラフィックスパイプラインから隠れ表面が除去された後に限って遂行される。これは、ｚ緩衝された混合操作（図Ｇ２、２３６）において隠れピクセルが除去される前に殆ど全ての表面のためのシェーディング計算（図Ｇ２、２２２）を遂行するような、図Ｇ２を参照して説明する従来のアプローチにおけるよりも、劇的に少ないライティング計算をもたらし得る。本発明の長所を示すために、以下に、バンプマッピングを含むライティング計算を遂行するための幾つかの従来のアプローチを説明する。説明するアプローチの１つは、Ｓｉｌｉｃｏｎ  Ｇｒａｐｈｉｃｓ  Ｉｎｔｅｒｎａｔｉｏｎａｌ（ＳＧＩ）から販売されている３Ｄグラフィックスハードウェアである。
【０９６５】  従来の３Ｄグラフィックスシステムにおけるライティング計算の理論的根拠及び実施は公知であり、以下の刊行物に余すところなく説明されているので参照されたい。（１）Ｐｈｏｎｇ，Ｂ．Ｔ．，Ｉｌｌｕｍｉｎａｔｉｏｎ  ｆｏｒ  Ｃｏｍｐｕｔｅｒ  Ｇｅｎｅｒａｔｅｄ  Ｐｉｃｔｕｒｅｓ，Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  ｏｆ  ｔｈｅ  ＡＣＭ  １８，６（Ｊｕｎｅ  １９７５），３１１−３１７（以下、フォング引例という）、（２）Ｂｌｉｎｎ，Ｊ．Ｆ．，Ｓｉｍｕｌａｔｉｏｎ  ｏｆ  Ｗｒｉｎｋｌｅｄ  Ｓｕｒｆａｃｅｓ，Ｉｎ  Ｃｏｍｐｕｔｅｒ  Ｇｒａｐｈｉｃｓ（ＳＩＧＧＲＡＰＨ  ’７８  Ｐｒｏｃｅｅｄｉｎｇｓ）（Ａｕｇ．１９７８），ｖｏｌ．１２，ｐｐ．２８６−２９２（以下、ブリン引例という）、（３）Ｗａｔｔ，Ａｌａｎ，３Ｄ  Ｃｏｍｐｕｔｅｒ  Ｇｒａｐｈｉｃｓ（２ｎｄ  ｅｄ．），ｐ．２５０（以下、ワット引例という）、（４）Ｐｅｅｒｃｙ，Ｍ．ｅｔ  ａｌ．，Ｅｆｆｉｃｉｅｎｔ  Ｂｕｎｐ  Ｍａｐｐｉｎｇ  Ｈａｒｄｗａｒｅ，Ｉｎ  Ｃｏｍｐｕｔｅｒ  Ｇｒａｐｈｉｃｓ（ＳＩＧＧＲＡＰＨ  ’９７  Ｐｒｏｃｅｅｄｉｎｇｓ）（Ｊｕｌｙ  １９９７），ｖｏｌ．８，ｐｐ．３０３−３０６（以下、ピアーシー引例という）。
【０９６６】  一般的に言えば、ライティング計算はある表面の各ピクセル毎に、その表面のカラー、向き、及び材料特性；表面照明の向き及び特性；及び照明された表面を観測する視点を考慮したＲＧＢＡカラー値を生成する。材料特性は、フォグ、放射カラー、反射特性（周囲、拡散、鏡面（ｓｐｅｃｕｌａｒ））、及びバンプ効果を含むことができる。照明特性は、１つまたはそれ以上の光について、カラー（グローバル周囲、光周囲、光拡散、光鏡面）及び減衰、スポットライト及び陰影効果を含むことができる。
【０９６７】  ３Ｄグラフィックスシステム内に実現できるグロー（Ｇｏｕｒａｕｄ）シェーディング及びフォングシェーディングを含む多くの異なるライティングモデルが存在している。グローシェーディングにおいては、ライティング計算は照明される表面の各頂点において行われ、得られたカラーは補間される。この技術は計算的には簡単であるが、マッハバンディングのような多くの望ましくないアーチファクトを発生する。殆どの実際的なライティング効果は、補間された、そして正規化された頂点法線に基づいて、ライティング計算を各ピクセルにおいて行うフォングシェーディングによって与えられる。典型的には、グラフィックスシステムは多くの異なるライティングモデルを支援する。しかしながら、本発明が目指しているのは、フォングシェーディング及びバンプマッピングを効率的に組合わせることであり、他のライティングモデルの詳細は省略する。
ライティング計算
図Ｇ３は、従来のアプローチ及び本発明の両方のライティング計算に使用される要素を示す図である。この図面は、バンプマッピング計算に使用される要素を示しておらず、これらは図Ｇ４に示されている。図Ｇ３に示されている要素を、以下に定義する。
ライティング計算の要素の定義
Ｖ    目座標（Ｖｘ，Ｖｙ，Ｖｚ）において照明されるフラグメントの位置。
2004272928.tif 000103
ＰＬ  目座標（ＰＬｘ，ＰＬｙ，ＰＬｚ）内の光源の位置。
ＰＬｉ  光が無限遠（０＝無限遠）に位置しているか否かを指示する。もし光が無
2004272928.tif 000104
ＰＥ  ビューワ（視点）の位置。目座標内においては、視点は（０，０，０）または（０，０，∞）の何れかにある。
2004272928.tif 000105
【数７８】
2004272928.tif 000106
である。
2004272928.tif 000107
【数７９】
2004272928.tif 000108
である。
【０９６８】
【数８０】
2004272928.tif 000109
【０９６９】  ライティング方程式
各ピクセルの“ライティングカラー”は、以下のライティング方程式（式（１））に従って計算される。
【０９７０】  ライティングカラー＝
放射カラー
＋グローバル周囲カラー
2004272928.tif 000110
【０９７１】  ライティング方程式用語
本アプリケーションの目的から、上記ライティング方程式（式（１））内に使用されている用語を以下のように定義する。これらの定義は、従来技術の用法と矛盾しない。
放射カラー：光を用いずに表面の自己照明材料特性によって表面に与えられるカラー。
周囲カラー：光周囲強度に起因して表面に与えられ、材料周囲反射特性によって基準化されたカラー。周囲カラーは、光の位置またはビューワには依存しない。２つの型の周囲光、即ちグローバル周囲シーン光、及び個々の光に関連する周囲光強度が与えられる。
拡散カラー：光の拡散強度に起因して表面に与えられ、材料の拡散反射特性及び表面の法線に対する光の方向によって基準化されたカラー。拡散光は全ての方向に反射するから、視点の位置は表面の拡散カラーに効果を及ぼさない。
鏡面カラー：光の鏡面強度に起因して表面に与えられ、材料の鏡面反射特性及び表面の法線に対する光の方向及び視点によって基準化されたカラー。材料の鏡面反射が消失（フェードオフ）して行く率は指数ファクターであり、材料の光沢のファクターとして指定される。
減衰：光源からのカラーの強度が、表面から光までの距離の関数として消失（フェードアウェイ）して行く量。光毎に３つのファクター、即ち一定の係数、一次係数、及び二次係数が指定される。
スポットライト：光の方向及びその照明の円錐を定義する光源毎のフィーチャ。スポットライトは、その円錐外に位置する表面には効果を及ぼさない。円錐内のスポットライトによる照明は、表面が円錐の中心からどれ程離れているかに依存し、スポットライト指数ファクターによって指定される。
【０９７２】  これらの各用語の意味及びずれを以下に説明する。
放射カラー
放射カラーは、将に材料の放射属性（Ｅｃｍ）である。即ち、
放射カラー＝Ｅｃｍ。
【０９７３】  周囲効果
材料の周囲属性Ａｃｍは、グローバルシーン周囲光Ａｃｓを基準化し、グローバル周囲効果を決定するために使用される。即ち、
グローバル周囲カラー＝Ａｃｍ・Ａｃｓｏ
【０９７４】  個々の光効果
個々の光は、それらに関連する周囲、拡散、及び鏡面属性を有している。これらの属性は、材料の周囲、拡散、及び鏡面属性によってそれぞれ影響を受ける。各光は、スポットライト属性及び減衰ファクターをも有しており、これらは以下のように表される。
【０９７５】  減衰
減衰ファクターは、光の位置から頂点の位置までの距離ｄＬに依存して、特定の光からのライティング効果を減少させるフラクションである。もし光の位置が無限遠にあれば（ＰＬｉ＝０）減衰ファクターは１であり、効果は無である。光毎に、３つの正のファクター（減衰値Ｋｃ、Ｋｌ、及びＫｑを決定する）が与えられる。これらはそれぞれ、一定、一次、及び二次効果である。光の距離を決定するためには、表面の目座標が必要であることに注目されたい。これらのファクターが与えられると、減衰は次のように表される。
【０９７６】  減衰＝１／（Ｋｃ＋Ｋｌ・ｄＬ＋Ｋｑ・ｄＬ２）
スポットライト
各光はスポットライトとして動作するように指定することができる。スポットライトの結果は、スポットライトが指し示す方向からの頂点の距離に基づいて、光が頂点上に有している効果を減少させることである。もし光がスポットライトでなければ効果は無であり、スポットライトファクタは１である。スポットライトを指定するために必要なパラメータは、スポットライトの位置ＰＬ、ＰＬ１、スポ
2004272928.tif 000111
ットライト「べき」指数ｓＥある。カットオフ角余弦の範囲は、０乃至１である。ｓｃが負の値をとることは、スポットライト効果が無であることを示している。もし頂点がスポットライトカットオフ角内に位置していれば、それは輝いており、そうでない場合には、それは輝いていない。頂点が輝く量は、スポットライトべき指数によって決定され、頂点が円錐の中心から遠去かる程輝きは少なくなる。スポットライト方向と、光から頂点までのベクトルとの間の角度の余弦ｓｄｖは、頂点が輝いているか否か、及び頂点がスポットライト円錐の中心からどれ程離れているかを決定するために使用される。
【０９７７】
【数８１】
2004272928.tif 000112
要約すれば、
ｓｃ＝−１の場合、            スポットライト効果＝１、
ｓｃ≠−１且つｓｃ＜ｓｄｖの場合、スポットライト効果＝０、
2004272928.tif 000113
ローカル周囲効果
ローカル光の周囲効果は、材料の周囲属性Ａｃｍによって基準化されたローカル周囲光Ａｃｌである。
周囲カラー＝Ａｃｌ・Ａｃｍｏ
拡散効果
拡散光効果は、表面の法線に対する光の位置によって決定きれる。それは、視点の位置に依存しない。それは、材料の拡散属性Ｄｃｍ、光の拡散属性Ｄｃｌ、光の位
2004272928.tif 000114
あれば（ＰＬｉ＝０）光位置ＰＬｉだけが使用され、頂点の目座標は必要ない。
【０９７８】  拡散効果は、拡散材料Ｄｃｍによって基準化された、そして最終的には光の方向と表面法線との間の角度の余弦ｐＮによって基準化された拡散光Ｄｃｌとして記述することができる。この余弦は０と１との間に制限される。もしこの余弦が負であれば、拡散効果は０である。
【０９７９】  ｐＮ≦０の場合、拡散カラー＝０、
ｐＮ＞０の場合、拡散カラー＝Ｄｃｌ・Ｄｃｍ・ｐＮ
ここに、
【０９８０】
【数８２】
2004272928.tif 000115
鏡面効果
鏡面光効果は、表面の法線に対する光の位置、及び視点の位置によって決定される。それは、材料の鏡面カラーＳｃｍ、材料の鏡面べき指数（光沢）Ｓｒｍ、光の
2004272928.tif 000116
【数８３】
2004272928.tif 000117
2004272928.tif 000118
置には無関係であり、光パラメータとして与えられる。
鏡面効果は、拡散材料Ｓｃｍによって基準化された、そして最終的には中点ベク
2004272928.tif 000119
光Ｓｃｌとして記述することができる。この余弦は、０と１との間に制限される。もしこの余弦が負であれば、鏡面効果は０である。
【０９８１】  ｈＮ≦０の場合、鏡面カラー＝０、
2004272928.tif 000120
ここに、
【０９８２】
【数８４】
2004272928.tif 000121
無限遠視点及び無限遠光効果
ＯｐｅｎＧＬにおいては、光の位置は、原点から無限遠の距離を有するが、その位置を指し示すベクトルを有するものとして定義することができる。この定義は、頂点から光までのベクトルを決定するのに必要な計算を簡易化するために使用される（光の位置を上記のように定義しない他のＡＰＩでは、この簡易化は行うことができない）。もし光が無限遠にあれば、このベクトルは頂点の位置には無関係であり、全ての頂点について一定であり、そして頂点の目座標を必要としない。この簡易化は、スポットライト、拡散カラー、及び鏡面カラーのために使用される。
【０９８３】  視点は、原点にあるものとして、またはｚ方向に無限遠にあるものとして定義される。これは、鏡面カラーのための計算を簡易化するために使用される。もしビューワが無限遠にあれば、頂点から視点までのベクトルは頂点の位置には無関係であり、全ての頂点について一定であり、そして頂点の目座標を必要としない
2004272928.tif 000122
計算ケース要約
以下の表（表１）は、光位置がローカルであるのかまたは無限遠であるのか、及びビューワが指定されているか否かに依存して、ライティングのために必要な計算を要約している。
【０９８４】
【表２３】
2004272928.tif 000123
バンプマッピング
高水準ライティングシステムにおいては、ライティング計算はバンプマッピング効果を考慮することができる。前記ブリン引例に記述されているように、バンプマッピングは、ある表面（その表面上に三次元テクスチャの効果が賦課／マップされる）の照明からもたらされる陰影及び強調表示（ハイライト）をシミュレートすることによって、より現実的なライティングを発生する。このようなテクスチャ化された表面の例は、バスケットボールの石目付き表面、またはゴルフボールのディンプル付き表面である。
【０９８５】  一般的に言えば、バンプマッピングを支援するライティングシステムにおいては、テクスチャマップ（例えば、石目付きバスケットボール表面）を使用してフラグメント・ライティング計算に使用される表面法線（Ｎ）を動揺（ｐｅｒｔｕｒｂ）させるために使用される（後述）。これは、従来のテクスチャマッピングでは得ることができない表面に対する三次元構造の視覚効果を与える。また、フラグメント毎にライティングが遂行されていることを想定している。バンプマッピングは、ＯｐｅｎＧＬ標準への拡張を必要とする。以下に、図Ｇ４を参照してバンプマッピングの理論的根拠を説明する。このアプローチは、殆どの一般的バンプマッピング方法、即ちＳＧＩアプローチ及び前記ブリンのアプローチの両方に共通である。
【０９８６】  図Ｇ４には、バンプマッピング計算に使用される若干の要素が示されている。図示したアプローチは、前記ブリン引例における深さに関連しており、以下に要約する。
【０９８７】  バンプマッピングの背景
2004272928.tif 000124
【数８５】
2004272928.tif 000125
法線ベクトルは、表面接線のクロス乗積として定義することができる。
Ｎ＝Ｖｓ×Ｖｔ
そこで、動揺した法線は、バンプされた点の表面接線のクロス乗積として定義することができる。
【０９８８】
【数８６】
2004272928.tif 000126
ｈｓ＝∂ｈ／∂ｓ及びｈｔ＝∂ｈ／∂ｔを高さ勾配と定義することにする。［２］式内へ代入すると、
【０９８９】
【数８７】
2004272928.tif 000127
が得られる。
基底ベクトル
【０９９０】
【数８８】
2004272928.tif 000128
高さ勾配及び基底ベクトルをどのように指定するかは、使用するモデルに依存する。
【０９９１】  基底ベクトル
基底ベクトルは、［５］を使用して計算することができる。
【０９９２】
【数８９】
2004272928.tif 000129
基底ベクトルのためのこの計算はブリンによって提唱されたものであり、表面接線、単位法線ベクトル、及びクロス乗積を必要とする。
図から、もし表面接線が直交していれば、基底は
【０９９３】
【数９０】
2004272928.tif 000130
によって近似することができる。
【０９９４】  高さ勾配
高さ勾配ｈｓ及びｈｔは、従来のアプローチによってフラグメント毎に与えられる。
【０９９５】  表面接線生成
2004272928.tif 000131
の表面接線を与えなければ、それらを生成する必要がある。三角形の頂点Ｖ１及びＶ２は、以下のようにＶ０に対して記述することができる。
【０９９６】
【数９１】
2004272928.tif 000132
である。
【０９９７】  上述した説明に従ってバンプマッピングを実現するための２つの異なる従来アプローチを、以下に図５Ａ、５Ｂ、６Ａ、及び６Ｂを参照して説明する。
【０９９８】  ＳＧＩバンプマッピング
図Ｇ５Ａに、Ｓｉｌｉｃｏｎ  Ｇｒａｐｈｉｃｓ（ＳＧＩ）によって提唱されたバンプマッピングアプローチを説明する機能流れ図を示す。この機能ブロックは、“動揺した法線計算”ＳＧＩ１０、“テクスチャマップ格納”ＳＧＩ１２、“ライティング計算遂行”ＳＧＩ１４、及び“目空間を接線空間に変換”ＳＧＩ１６を含む。このアプローチの典型的な実施の形態では、ステップＳＧＩ１０及びＳＧＩ１２はソフトウェア内で遂行され、ステップＳＧＩ１４及びＳＧＩ１６は３Ｄグラフィックスハードウェア内で遂行される。詳述すれば、ステップＳＧＩ１６は、フォングシェーディングを遂行するように最適化されている同一ハードウェアを使用して遂行される。ＳＧＩアプローチは、前記ピアシー引例に記述されている。
【０９９９】  ＳＧＩアプローチのキーとなる面は、全てのライティング及びバンプマッピング計算が接線空間内で遂行されることである。接線空間は、各表面／オブジェクト毎に、単位表面法線（Ｎ）及び２つの単位表面接線（Ｔ及びＢ）からなる正規直交ベクトルによって定義される空間である。基底ベクトルは、アプリケーションプログラムによって各頂点において明示的に定義することも、または各オブジェクトにローカルな参照フレームからグラフィックスプロセッサによって導出することもできる。しかしながら、接線空間が定義され、基底ベクトルの成分は目空間で与えられる。一次代数の標準定理によれば、座標系Ａ（例えば、目空間）から系Ｂ（例えば、接線空間）への変換に使用されるマトリックスは、系Ｂの基底ベクトルの座標から系Ａ内に形成することができる。従って、列が目空間座標内に表されている基底ベクトルＮ、Ｔ、及びＢからなるマトリックスＭを使用して、目空間ベクトルを対応する接線空間ベクトルへ変換することができる。以下に説明するように、この変換をＳＧＩパイプライン内で使用してライティング及びバンプマッピング計算を接線空間内で行うことができる。
図示したＳＧＩアプローチに使用される要素は、以下のものを含む。
【１０００】  ｕ        表面の面内の接線空間の１つの座標、
ｖ        表面の面内の接線空間の１つの座標、
Ｎ        照明されるフラグメントの各頂点における表面法線、
Ｐｕ      照明されるフラグメントの各頂点におけるｕ軸に沿う表面接線、
Ｐｖ      照明されるフラグメントの各頂点におけるｖ軸に沿う表面接線、
ｆｕ（ｕ，ｖ）  テクスチャマップの各点において計算された入力テクスチャマップのｕ軸に沿う偏導関数（注：ＯｐｅｎＧＬ標準によれば、入力テクスチャマップは、（ｕ，ｖ）空間内の高さフィールドを定義する値ｆ（ｕ，ｖ）の一次元、二次元、または三次元アレイである。ＳＧＩアプローチでは、この高さフィールドは、高さフィールドの各点毎に２つの方向（ｕ及びｖ）における勾配を与える偏導関数ｆｕ（ｕ，ｖ）、ｆｖ（ｕ，ｖ）の集まりに変換される。）
ｆｖ（ｕ，ｖ）テクスチャマップの各点において計算された入力テクスチャマップのｖ軸に沿う偏導関数（ｆｖ（ｕ，ｖ）の説明参照）
Ｌ        目空間内の光ベクトル
Ｈ        目空間内の半角ベクトル
ＬＴＳ    接線空間内の光ベクトル
ＨＴＳ    接線空間内の半角ベクトル
Ｔ        Ｐｕに沿う単位表面接線
Ｂ        Ｎ及びＴのクロス乗積として定義される単位表面従法線。
【１００１】  注：以上の説明ではピアシーの論文からの表記法を使用し、本明細書の他の部分（例えば、残余の背景及び詳細な説明）では類似のパラメータに対して異なる表記法を使用している。これら２つの系統間の対応を以下に示す。ピアシー表記法は“ＳＧＩ”とラベル付けされた列の下にリストされ、他の表記法は“レイサー”（Ｒａｙｃｅｒ）とラベル付けされた列の下にリストされている。
【１００２】ＳＧＩ          レイサー
Ｎ              Ｎ
Ｌ              Ｌ
Ｈ              Ｈ
ｕ              ｓ
ｖ              ｔ
∂ｈ／∂ｓ      ｆｕ（ｕ，ｖ）
∂ｈ／∂ｔ      ｆｖ（ｕ，ｖ）
Ｐｕ          Ｖｓ
Ｐｖ          Ｖｔ
Ｔ              Ｔ
Ｂ              Ｂ
ＳＧＩアプローチでは、一組の偏導関数ｆｕ（ｕ，ｖ）、ｆｖ（ｕ，ｖ）からなる入力テクスチャマップを、表面法線（Ｎ）及び接線（Ｐｕ、Ｐｖ）及び基底ベクトルＢ及びＴと組合わせて使用し、以下の方程式に従って高さフィールドの各点における接線空間（Ｎ’ＴＳ）内の動揺した法線を計算する。
【１００３】  Ｎ’ＴＳ＝（ａ，ｂ，ｃ）／（ａ２＋ｂ２＋ｃ２）１／２
但し、ａ＝−ｆｕ（Ｂ，Ｐｖ）、
ｂ＝−ｆｖ｜Ｐｕ｜−ｆｕ（Ｔ，Ｐｖ）、
ｃ＝｜Ｐｕ×Ｐｖ｜
係数ａ、ｂ、及びｃは、接線空間内の動揺した法線Ｎ’ＴＳの非正規化成分である（即ち、係数ｃは法線方向にあり、係数ａ及びｂはｕ及びｖ方向における法線に対する動揺を表している）。ステップ（ＳＧＩ１２）において、これらの係数はテクスチャマップＴＭＡＰとして格納され、これは適切なＡＰＩ（例えば、ＯｐｅｎＧＬ）によって指定されたフォーマットでＳＧＩ３Ｄハードウェアに供給される。
【１００４】  上述した一次代数定理を使用し、光ベクトル及び半角ベクトル（Ｌ、Ｈ）を、列が接線、従法線、及び法線（Ｔ、Ｂ、Ｎ）の目空間（即ち、ｘ、ｙ、及びｚ）座標からなるマトリックスＭを使用する接線空間に変換する（ＳＧＩ１６）。
【１００５】
【数９２】
2004272928.tif 000133
従って、ベクトルＬＴＳ及びＨＴＳは以下のように計算される。
【１００６】  ＬＴＳ＝Ｌ・Ｍ
ＨＴＳ＝Ｈ・Ｍ
得られた光及び半角ベクトルの接線空間バージョンは、入力法線Ｎ及びテクスチャマップＴＭＡＰと共に、フォングライティング及びバンプマッピングステップ（ＳＧＩ１４）へ出力される。フォングライティング及びバンプマッピングステップ（ＳＧＩ１４）においてグラフィックスハードウェアは、上述した接線空間ベクトルを使用して接線空間における全てのライティング計算を遂行する。詳述すれば、もしバンプマッピングが必要であれば、ＳＧＩシステムは動揺したベクトルＮ’ＴＳ（テクスチャマップＴＭＡＰ成分によって表される）をライティング計算に使用する。そうでなければ、ＳＧＩシステムは入力表面法線Ｎをライティング計算に使用する。ステップＳＧＩ１４は、特に、
１．照明が計算される各ピクセル毎にＮ’ＴＳ、ＬＴＳ、ＨＴＳ、及びＮＴＳベクトルを        補間し、
２．補間されたベクトルを正規化し、
３．照明計算を遂行する。
【１００７】  ＳＧＩアプローチの欠点は、計算される大量の必要情報を必要とすることである（例えば、最終グラフィックスイメージにおいては見ることができないピクセルに関連する頂点のために）。この情報は、
１．各表面の各頂点毎のＮ’ＴＳ、
２．各表面の各頂点毎のＬＴＳ、
３．各表面の各頂点毎のＨＴＳ
を含む。
【１００８】  ＳＧＩアプローチは、ＯｐｅｎＧＬ仕様への拡張を必要とする。即ち、新しいテクスチャマップ表現を支援するために、拡張が必要である。これらの拡張は、ＳＧＩ  ＯｐｅｎＧＬ  ｅｘｔｅｎｓｉｏｎ、ＳＧＩＸ＿ｆｒａｇｍｅｎｔ＿ｌｉｇｈｔｉｎｇ＿ｓｐａｃｅに定義されているので参照されたい。
【１００９】  図Ｇ５Ｂは、ピアシー引例において提唱されているＳＧＩバンプマッピング／フォングシェーディングアプローチの仮説的ハードウェアの実施の形態を示す。このシステムにおいては、表面法線Ｎ及び変換された光及び半角ベクトルＬＴＳ、ＨＴＳがブロックＳＧＩ１４の入力において補間されていることに注目されたい。ＬＴＳ及びＨＴＳ補間は、各アクティブ光毎に１回ずつ複数回行うことができる。スイッチＳは、バンプマッピングが遂行されている時の動揺した法線Ｎ’ＴＳを、またはバンプマッピングが遂行されていない時の動揺していない表面法線Ｎを選択するために使用される。得られた法線及び補間された光及び半角ベクトルは正規化され、結果の正規化されたベクトルは照明計算へ入力され、照明計算は対応するピクセル値を出力する。
【１０１０】  ＳＧＩバンプマッピングに伴う問題は、
１．Ｌ及びＨベクトルを接線空間へ変換する費用。これは、ライティング計算における光の数と共に増加する。
【１０１１】  ２．これは、殆どのグラフィックス処理（例えば、ライティング及びバンプマッピング）がフラグメント毎に遂行されるような３Ｄグラフィックスパイプラインだけに適している。フラグメントが並行処理されるような他の実施の形態では、バンプマッピング計算を遂行可能にするために格納するのに必要なデータの量は莫大になる。
【１０１２】  ３．光ハードウェアにおける補間。これは、時間のかかる演算であり、また全ての頂点情報が使用可能であることを必要とする（これは、デファードシェーディング環境においては不可能である）。
【１０１３】  ４．全ベクトル（例えば、ＬＴＳ、ＨＴＳ）の補間が近似誤差をもたらし、それが最終イメージ内に視覚アーチファクトをもたらす。
【１０１４】  “ブリン”バンプマッピング
図Ｇ６Ａは、ブリンバンプマッピングアプローチを示す機能的流れ図である。機能ブロックは、勾配生成Ｂ１０、“動揺した法線計算”Ｂ１２、及び“ライティング計算遂行”Ｂ１４を含んでいる。このアプローチの典型的な実施の形態においては、ステップＢ１０はソフトウェアで遂行され、ステップＢ１２及びＢ１４は専用バンプマッピングハードウェアで遂行される。ブリンアプローチは、ブリン及びピアシー引例に記述されている。
【１０１５】  図示したブリンのアプローチに使用される要素は、次のものを含む。
ｓ        バンプ空間格子の１つの座標、
ｔ        バンプ空間格子の１つの座標、
Ｎ        照明されるフラグメントの各頂点における表面法線、
ｖｓ      照明されるフラグメントの各頂点におけるｓに沿う表面接線、
ｖｔ      照明されるフラグメントの各頂点におけるｔ軸に沿う表面接線、
ｈｓ（ｓ，ｔ）高さフィールドの各点において計算されたバンプ高さフィールドのｓ軸に沿う偏導関数（注：ＯｐｅｎＧＬ標準によれば、入力テクスチャマップは、（ｓ，ｔ）空間内の高さフィールドを定義する値ｈ（ｓ，ｔ）の一次元、二次元、または三次元アレイである。ＡＰＩは、この高さフィールドは、高さフィールドの各点毎に２つの方向（ｓ及びｔ）における勾配を与える偏導関数ｈｓ（ｓ，ｔ）、ｈｔ（ｓ，ｔ）の集まりに変換する。）
ｈｔ（ｓ，ｔ）テクスチャマップの各点において計算されたバンプ高さフィールドのｔ軸に沿う偏導関数（ｈｓ（ｓ，ｔ）の説明参照）
Ｌ        目空間内の光ベクトル
Ｈ        目空間内の半角ベクトル
ｂｓ      バンプ勾配ｈｓを目空間へマップできるようにする基底ベクトル
ｂｔ      バンプ勾配ｈｔを目空間へマップできるようにする基底ベクトル
ブリンのアプローチは、ある表面に適用されるテクスチャが、高さフィールドｈ（ｓ，ｔ）によって初めに定義されることを仮定している。ブリンのアプローチはこの高さフィールドを直接使用せず、高さフィールドを表すテクスチャマップが、１組の勾配ｈｓ（ｓ，ｔ）及びｈｔ（ｓ，ｔ）としてＡＰＩによって与えられることを要求する（ＳＧＩ１０）。即ち、（ＳＧＩのアプローチにおけるように）動揺した法線Ｎ’を与えるのではなく、プリンのテクスチャマップは法線に対するオフセット／動揺を表す２つのスカラー値ｈｓ、ｈｔを与える。法線Ｎに適用されるオフセットに関しては、オフセットが与えられる参照フレームを（目空間内に）定義する２つの基底ベクトルｂｓ及びｂｔが必要である。これらのベクトルの２つの考え得る源は、
１）ユーザによるベクトルの供給、
２）目空間に対する頂点毎のテクスチャ座標の偏導関数を形成することによって、グラフィックスハードウェアによる自動生成。この定義の正当性はワットの引例内に見出すことができる。
である。
【１０１６】  ステップ（Ｂ１２）において、ブリンのバンプマッピングアプローチは、以下の方程式に従って法線ベクトルを動揺させる。
【１０１７】
【数９３】
2004272928.tif 000134
の導出に関してはワット引例を参照されたい。動揺した法線の計算は、
１．動揺した法線Ｎ’を計算するために使用される要素（−Ｖｔ×Ｎ、−Ｎ×Ｖｓ、Ｖｓ×Ｖｔ）の補間、
２．補間された要素を使用して、動揺した法線Ｎ’の計算、
を含む。
【１０１８】  動揺した法線Ｎ’が計算された後に、グラフィックスハードウェアはライティング計算を遂行する（Ｂ１４）。ステップＢ１４において遂行される機能は、
１．Ｌ及びＨベクトルの補間、
２．動揺した法線Ｎ’、及びＬ及びＨベクトルの正規化、
３．ライティング計算、
を含む。
【１０１９】  図Ｇ６Ｂに、ピアシー引例において提唱されているブリンのバンプマッピングアプローチの仮説的ハードウェアの実施の形態を示す。このシステムにおいて、計算しなければならない複数のベクトルクロス乗積、及び所要数の補間及び正規化に注目されたい。ブリンのアプローチでは、各ピクセルにおける（即ち、各照明計算毎に）基底ベクトルを導出するために特別の演算が必要である。更に、クロス乗積（Ｂｔ×Ｎ）、（Ｎ×Ｂｓ）、（Ｎｓ×Ｂｔ）に適用される３つの補間演算は、クロス乗積値の大きい考え得る範囲のために、広い浮動小数点演算（即ち、３２ビット演算）が必要である。
デファードシェーディングアーキテクチャにおける接線空間ライティングの概要
本発明は、グラフィックスプロセッサにおいてライティングを遂行するための構造及び方法を提供する。本発明は一つの面において、特に、デファードシェーディングアーキテクチャにおける接線空間ライティングを遂行するための構造及び方法を提供する。本発明の実施の形態は、可変スケールバンプマッピング、自動基底生成、自動勾配フィールド生成、角度及び大きさ計算を別々に行うことによる法線補間をも提供する。
【１０２０】  一実施の形態において、本発明はデファードグラフィックスパイプラインプロセッサ内で使用するバンプマッピング方法を提供し、本方法は、バンプ効果を計算する表面に関連するピクセルフラグメントを受け、そのフラグメントに関連する表面に対する接線空間を定義する表面接線、従法線、及び法線、そのピクセルフラグメントに関連する表面位置におけるバンプ効果によって生ずる表面接線及び従法線の方向の表面法線に対する動揺を表すテクスチャベクトルを受けるステップと、テクスチャベクトルの配向を考慮しながら接線空間から目空間への変換を定義する表面接線、従法線、及び法線から１組の基底ベクトルを計算するステップと、列が基底ベクトルからなる変換マトリックスによってテクスチャベクトルを乗算するようにマトリックス乗算を遂行することによって、バンプ効果を反映する動揺した目空間表面法線を計算するステップと、動揺した、目空間、表面法線である結果を求めるステップと、動揺した目空間表面法線を使用してピクセルフラグメントのためのライティング計算を遂行するステップと、ライティング計算に使用される光及び半角ベクトル（Ｌ及びＨ）を補間及び変換する必要性を無くして、バンプ効果を斟酌したピクセルフラグメントのための見掛けのカラーを求めるステップとを含んでいる。
【１０２１】  別の実施の形態においては、自動基底またはベクトル生成が提供される。コンピュータグラフィックスイメージをシェーディングするための可変スケールバンプマッピング方法は、バンプ効果をマップする表面に関連する多角形の頂点、ジオメトリベクトル（Ｖｓ、Ｖｔ、Ｎ）、及びテクスチャベクトル（Ｔｂ）を受けるス
2004272928.tif 000135
（ｍｂｓ、ｍｂｔ、ｍｂｎ）とに分離するステップと、大きさとテクスチャベクトルとを乗算してテクスチャ・大きさベクトル（ｍＴｂ’）を形成するステップと、ベクトルｓによってテクスチャ・大きさベクトルの成分を基準化し、基準化されたテクスチャ・大きさベクトル（ｍＴｂ”）を形成するステップと、基準化されたテクスチャ・大きさベクトルと単位基底ベクトルとを乗算してあるピクセル位置のための目空間における動揺した単位法線（Ｎ’）を求めるステップとを含み、それによって、ピクセルフラグメントバンプ効果を求めるためのライティング計算を遂行するためにそのピクセル位置における表面接線及び従法線を指定する必要性が排除される。
【１０２２】  別の実施の形態では、この方法は、大きさとテクスチャ・大きさベクトルとの乗算ステップは、固定小数点乗算ハードウェアの使用を可能にする変換マトリックスを発生するようにも定義されている。別の実施の形態では、この方法は、大きさとテクスチャ・大きさベクトルとの乗算ステップは、異なる接線空間座標系から目空間座標系への変換を定義する変換マトリックスを発生するようにも定義されている。更に別の変化では、この方法は、ブリン座標系を含む既知の座標系から、異なる接線空間座標系が選択されるように遂行される。
【１０２３】  別の実施の形態では、本発明は自動勾配フィールド生成を提供する。一実施の形態は、コンピュータグラフィックスイメージをシェーディングするための可変スケールバンプマッピング方法を提供し、この方法は、バンプ効果が計算されるグレースケールイメージを受けるステップと、そのグレースケールイメージに関連するピクセルフラグメントのためのグレースケール強度に対する導関数を求めるステップと、この導関数から目空間における動揺した単位法線を計算してピクセルフラグメントバンプ効果を求めるステップとを含んでいる。この方法は、オプションとして、この導関数から目空間における動揺した単位法線を計算するステップが、グレースケール強度の導関数を目空間座標系への変換を定義する変換マトリックスを形成するステップを含むことができる。
【１０２４】  本発明の別の実施の形態では、角度及び大きさ計算を別々に行うことによって法線補間を遂行する構造及び方法が提供される。この方法の１つの特定の実施の形態では、コンピュータグラフィックスイメージをシェーディングするためにバンプマッピングする方法は、バンプ効果を計算する表面に関連するピクセルフラグメント、大きさベクトル（ｍ）、及びバンプベクトル（Ｔｂ）、及び単位変換マトリックス（Ｍ）を受けるステップと、大きさベクトルとバンプベクトルとを乗算してテクスチャ・大きさベクトル（ｍＴｂ’）を形成するステップと、ベクトルｓによってテクスチャ・大きさベクトルの成分を基準化し、基準化されたテクスチャ・大きさベクトル（ｍＴｂ”）を形成するステップと、基準化されたテクスチャ・大きさベクトルと単位変換マトリックスとを乗算し、動揺した法線（Ｎ’）を求めるステップと、動揺した法線の成分を再基準化して再基準化されたベクトル（Ｎ”）を形成するステップと、再基準化されたベクトルを正規化してライティング計算を遂行するのに使用される単位動揺法線を発生し、ピクセルフラグメントバンプ効果を求めるステップとを含む。
【１０２５】  この方法の変形では、テクスチャ・大きさベクトルの成分を基準化するステップは、得られたマトリックスを固定小数点ベクトルとして表すことができるようにスカラーを選択するステップを含む。この方法の別の変形では、ベクトルｓはスカラー（ｓｓ、ｓｔ、ｓｎ）からなり、テクスチャ・大きさベクトルの成分を基準化するステップは、ｍＴｂ”＝（ｓｓ×ｍｂｓｈｓ、ｓｔ×ｍｂｔｈｔ、ｓｎ×ｍｎｋｎ）のようにテクスチャ・大きさベクトルとｓとを乗算するステップを含む。この方法の更に別の変形では、単位変換マトリックスも固定小数点値からなり、基準化されたテクスチャ・大きさベクトルと単位変換マトリックスとを乗算するステップは、固定小数点乗算ハードウェアを使用して乗算するステップを含む。この方法の更に別の変形では、動揺した法線の成分を再基準化するステップは、ベクトルｓの逆数（１／（ｓｓ、ｓｔ、ｓｎ））を乗算してそれらの値の間の正しい関係を確立するステップを含む。
【１０２６】  以下に、本発明の構造及び方法の他の面及び実施の形態を、添付図面を参照して説明する。
（実施の形態）
フォングブロックは、カラー、材料、ジオメトリック、及びフラグメントブロックからのライティング情報を、テクスチャブロックからのテクスチャ情報と組合せることによって、フラグメントのカラーを計算する。結果は着色されたフラグメントであり、これはピクセルブロックへ送られてフレームバッファ内に既に存在している何等かのカラー情報と混合される。
フォングは、フレーム、タイル、またはスクリーン空間の概念に関しては注意を払っていないことに注目されたい。
【１０２７】  本発明によれば、フォングブロックは、デファードシェーディング環境において接線空間ライティングを遂行するための多くの特色を実現している。これらの特色は、以下のものを含む。
・  接線空間内に表されるバンプマップを使用して目空間におけるバンプマッピングを遂行すること、
・  ライティング計算に使用される光及び半角ベクトル（Ｌ及びＨ）を補間及び変換する必要を無くして、接線空間バンプマップを支援すること、
・  マトリックス乗算を使用してバンプマッピングを遂行すること、
・  各基底ベクトルを単位ベクトルと大きさとに分離し、大きさを関連接線空間バンプマップ成分と組合わせることによって導出した基底ベクトルの固定小数点マトリックスを使用してバンプマッピングを遂行すること、
・  関連尺度係数によって各バンプマップ成分を基準化することによって導出した基底ベクトルの固定小数点マトリックス及び接線空間バンプマップ成分の固定小数点ベクトルを使用する固定小数点マトリックス乗算を使用してバンプマッピングを遂行すること、
・  バンプマッピング計算を遂行するためにフォングライティングマトリックスを使用すること、
・  ブリン、ＳＧＩ、及び３Ｄ  Ｓｔｕｄｉｏ  Ｍａｘを含むいろいろなＡＰＩフォーマットで提供される接線空間バンプマップとの互換性、
・  供給されるバンプマップのフォーマットに依存して基底ベクトルを異なって導出し、それによって同一マトリックス乗算をバンプマップのＡＰＩフォーマットには無関係にバンプマッピングを遂行するために使用できるようにしたこと、
・  偏導関数、法線、または基底ベクトルを補間することなく、ライティング及びバンプマッピングを遂行すること、
・  ブリンのバンプマッピングをハードウェアで実現したこと。
【１０２８】  フォングブロック１４０００の１の特色は、それが偏導関数または法線を補間しないことである。代わりに、これらの補間はフラグメントブロック１１０００において行われ、補間された結果が「フォング」へ渡される。「フラグメント」１１０００がこれらの補間を遂行する方法は上述したが、この方法の特色及びその長所を以下に要約する。
・  「フラグメント」は任意の大きさの偏導関数または法線は補間しない、
・  代わりに、頂点毎の偏導関数及び法線が単位ベクトル及び関連する大きさとして「フラグメント」に供給され、「フラグメント」は別々に補間する（三角形及び他の本発明のフラグメントブロックによって遂行される補間方法のための前記重心（バイセントリック）補間を参照されたい）、
・  「フラグメント」は補間された偏導関数及び法線単位ベクトルを正規化し、結果をフラグメント単位法線及び偏導関数として「フォング」へ渡す、
・  「フラグメント」は補間された大きさをフラグメント単位法線及び偏導関数に関連する大きさとして「フォング」へ渡す、
・  「フォング」は、補間された単位ベクトル及び関連する大きさを使用してバンプ及びライティング計算を遂行する。
【１０２９】  フォングブロック１４０００の別の特色は、ＬまたはＨベクトルを補間しないことである。代わりに、「フォングブ」はフラグメントブロック１１０００から単位光ベクトルＰ１及び単位フラグメントベクトルＶ（共に目空間座標内に定義されている）を受ける。「フォング」は、Ｐ１からＶを減算することによって補間することなく、光ベクトルＬを導出する。これにより、「フォング」は、光ベクトル及び既知の目ベクトルＥから半角ベクトルＨを導出することができる。
【１０３０】  従来技術と比較して、デファードシェーディングアーキテクチャ内で接線空間ライティングを遂行する本発明のシステムの長所は、以下のものを含む。
・  任意の大きさのベクトル（即ち、偏導関数、法線、Ｌ、Ｈ、Ｎ）を補間することによって、従来技術においては発生した表面パラメータ化による歪みが存在しないこと、
・  特にローカル光に関して、Ｌ及びＨベクトルを補間することによって、従来技術においては発生した三角形化（三角形のサイズ）による近似誤差が存在しないこと、
・  特に複数光に関して、Ｌ及びＨベクトルを目空間から接線空間へ変換するために、従来技術では必要とされていた計算を減少させたこと、
・  マトリックス乗算を、固定小数点マトリックスと固定小数点ベクトルとの乗算として計算し直す結果としてフォングハードウェアを簡易化したこと、
・  たとえバンプマップが接線空間内に定義されている場合でも、ライティング計算及びバンプマッピングの両者を目空間において遂行するようにフォングハードウェアを効率的に使用すること。
・  「フォング」においてベクトル補間を遂行する必要性を排除した結果としてフォングハードウェアが簡易化されていること。
【１０３１】  以下に、本発明のさまざまな特色を説明するが、先ず概要を説明し、次いで適切なより高レベルな詳細を説明することにする。
カラーインデックスモード
テクスチャ及びフラグメントライティング操作は、カラーインデックスモードで始まるのではない。このモードにおいてフォングブロックによって遂行される唯一の計算は、フォグ計算である。この場合、到来するフラグメントカラーのＲ値の仮数が、０から２５６まで変化する８ビットのカラーインデックスとして翻訳され、フォグブロックへ直接経路指定されて処理される。
パイプライン位置
図Ｇ３４は、パイプライン内の「フォング」の位置及び隣接ブロックとの関係を示すブロック図である。フォングブロック１４０００は、「テクスチャ」１２０００の後に、そして「ピクセル」１５０００の前に配置されている。フォングブロック１４０００は、「テクスチャ」及び「フラグメント」１１０００からデータを受ける。「フラグメント」は、フラグメント毎のデータ、並びにモード注入から通過するキャッシュ充填データを送る。「テクスチャ」はテクセルデータ２０００１ａだけを送る。図示のＤＳＧＰにおいては、「フラグメント」１１０００からのデータは、スタンプｘ、ｙ１４００１ａ、ＲＧＢＡ拡散データ１４００１ｂ、ＲＧＢＡスペクトルデータ１４００１ｃ、表面法線１４００１ｄ、バンプ基底ベクトル１４００１ｅ、目座標１４００１ｆ、光キャッシュインデックス１４００１ｇ、及び材料キャッシュインデックス１４００１ｈを含む。
【１０３２】  「フォング」が発生した結果１４００２だけが「ピクセル」１５０００へ送られ、「ピクセル」１５０００が必要とする他の全てのデータ１５００２は別のデータ経路から到来する。フォングブロックは２つの内部キャッシュ、即ちシーン光及びグローバル描写モードのようなそれ程屡々変化しない情報を保持する“光”キャッシュ１４１５４、及び一般にオブジェクト毎の基準で変化する情報を保持する“材料”キャッシュ１４１５０を有している。
フォング計算ブロック
フォング手順は、以下に要約する幾つかの副計算またはブロックからなっている。擬似コードは、所要データ及び状態情報の詳細と共に、後に説明する。図Ｇ３６は「フォング」のブロック図であって、いろいろなフォング計算を示している。
【１０３３】  テクスチャ計算
テクスチャ計算１４１１４は、テクスチャブロックから到来するテクセル１４１０２、及び材料キャッシュ１４１５０からのテクスチャモード情報１４１５１ａを受ける。この計算は、テクスチャ環境計算を適用し、もし存在すれば複数のテクスチャを併合する。結果は、テクスチャが普通に使用される場合には、光・環境サブユニット１４１４２へ、またはテクスチャが、カラー以外のフォング計算のパラメータを変更するものと解釈される場合には、「バンプ」１４１３０のような他のサブユニットへ転送される。
【１０３４】  材料計算／選択
「材料計算」１４１２６は、ライティング計算のための材料値の源を決定する。「材料計算」１４１２６への入力は、テクスチャブロック１４１１４からの材料テクスチャ値、「フラグメント」からのフラグメント材料値１４１０８、及びグロー計算において得られた主カラー１４１０６を含む。「材料計算」は材料キャッシュ１４１５０からの現材料モードビットを使用してフラグメント材料１４１２６を、テクスチャ値１４１１４と、または到来する主カラー１４１０６と置換することを決定することができる。
【１０３５】  バンプ計算
「バンプ計算」１４１３０は、ライティング計算に使用される表面法線を決定する。「バンプ」への入力は、「テクスチャ」１４１１４からのバンプテクスチャ情報１４１２２、「フラグメント」１１０００からの表面法線、接線、及び従法線１４１１０を含む。「バンプ計算」１４１３０は、「フラグメント」によって補間された法線を単に通過させるか、または３×３マトリックス乗算を含む計算にテクセル値を使用することができる。
【１０３６】  光・テクスチャ計算
「光・テクスチャ計算」１４１３４への入力は、「テクスチャ計算」１４１１４からの光テクスチャ情報１４１１８、及び「フラグメント」からのフラグメント光情報１４１１２を含む。「光・テクスチャ計算」１４１３４は、光１４１１２の成分の何れかをテクセル１４１１８によって置換すべきか否かを決定する。
【１０３７】  フラグメントライティング計算
「フラグメントライティング計算」１４１３８は、ＧＥＯブロックにおいて頂点毎のライティングのために使用するものと類似の方程式を使用して、このフラグメントのための実際のライティング計算を遂行する。この方程式に関しては、背景の節において詳細説明済みである。「フラグメントライティング」への入力は、「材料選択」１４１２６からの材料データ１４１２８、「バンプ」１４１３０からの表面法線、及び「光・テクスチャ」１４１３４からの光データ１４１３６を含む。
【１０３８】  光環境計算
「光環境計算」１４１４２は、フラグメントライティング計算の結果１４４１０と、テクスチャブロックから送られたテクスチャカラー１４１１８とを混合する。
【１０３９】  フォグ計算
「フォグ計算」１４１４６は“フォグ”を適用し、ビューワの目からフラグメントまでの距離だけに依存する計算を使用してフラグメントカラー１４１４４を変更する。「フォグ計算」１４１４６からの最終結果は、ピクセルブロックへ送られる。
【１０４０】  フォングハードウェアの詳細
先行節では、フォング計算を遂行するブロックと、サブブロックによって使用され、生成されるデータとに関して概述した。これらのブロックは、以上に概要を説明した、及び以後に詳細に説明する要求に合致するハードウェアまたはソフトウェアで実現することができる。同様に、データは、フォングＩ／Ｏ要求を満足することができるいろいろな実施の形態を使用して、フォングブロックと外部ユニット（即ち、「テクスチャ」、「フラグメント」、及び「ピクセル」）との間で、及びフォングブロックの間で転送することができる。これらの代替実施の形態は、全て本発明の範囲内にあり、フォングブロックをハードウェアで実現し、パケットを使用してデータをトップレベルユニット（即ち、「テクスチャ」、「フラグメント」、「フォング」、及び「ピクセル」）間で転送するような好ましい一実施の形態を以下に説明する。
【１０４１】  Ｉ／Ｏパケット
図Ｇ３５は、一実施の形態において、「フォング」１４０００、「フラグメント」１１０００、「テクスチャ」１２０００、及び「ピクセル」１５０００の間で交換されるパケットのブロック図である。これらのパケットは、
ハーフレートフラグメントパケット１１９０２、
フルレートフラグメントパケット１１９０４、
材料キャッシュミスパケット１１９０６
（ＭＩＪから、「フラグメント」によって中継）、
光キャッシュミスパケット１１９０８
（ＭＩＪから、「フラグメント」によって中継）、
テクスチャパケット、またはテクセル１２９０２、
ピクセル出力パケット１４９０２、
を含む。これらの各パケットについて以下に説明する。
【１０４２】  フラグメントからの入力パケット
フォングブロック１４０００は、フラグメントブロック１１０００から、キャッシュすることができないフラグメント毎に変化する情報を含むパケット１１９０２、１１９０４を受ける。一般的に、「フラグメント」１１０００からのパケットは、１つのフラグメント毎に、
・  そのフラグメントに関連するライティング及び材料に関係するキャッシュされた情報を指し示すポインタ、
・  １つまたはそれ以上のカラー値、
・  フラグメントジオメトリデータ（フラグメント法線、及びオプションとして接線及び従法線）、及び
・  オプションとして、ライティング方程式のための目座標
を含む。
【１０４３】  図示した実施の形態では、「フラグメント」１１０００からの情報は、フルレート及びハーフレートパケット１１９０４、１１９０２として供給される。各フルレートパケット１１９０４は、“フルパフォーマンスモード”においてフルＤＳＧＰサイクルレートで遂行することができる簡易化されたライティング計算を遂行するために、「フォング」によって使用されるフラグメント情報の縮小セットを含む。各ハーフレートパケット１１９０２は、ハーフサイクルレートにおいてフルライティング計算を遂行するために、「フォング」によって使用されるフラグメント情報のフルセットを含む。フル及びハーフレート情報のこの差は本発明の本質的な特色ではないが、ハーフサイクルレートにおいてフルライティング計算を遂行することが不可能な場合に、ハードウェア及びソフトウェアで実施するのに有用である。このような実施においては、この差がフォングユニットとフラグメントユニットとの間の通信のために必要な帯域幅を保存する。フル及びハーフレートフラグメントパケットの特定の実施の形態を以下に説明する。
フラグメントからのフルレートパケット
フルパフォーマンスモードにおいては、
・  ビューワの位置は、目座標系の定義に暗示されている方向を特徴とし、
・  光は無限遠にあり、
・  単一のテクスチャだけを使用することができ、
・  この単一のテクスチャがバンプマップではない、
ような“無限遠ビューワ”状態を想定する。
【１０４４】  この場合、フラグメント毎に変化する唯一のデータは、ジオメトリエンジンによって発生された表面法線方向及びグローカラーである。
【１０４５】  一実施の形態では、帯域幅及び入力待ち行列サイズを縮小するために、スタンプ毎の情報は可視スタンプ部分の全てのピクセルの間で共用される。これにより「フラグメント」１１０００は、ＶＳＰ毎に１つのフルレートパケット１１９０４だけを送ることができ、これはＶＳＰを構成する４つまでのフラグメントにも適用される。この場合「フォング」は、どれ程多くのフラグメントでスタンプが形成されているかを告げる必要はあるが、そのフラグメントのスクリーン空間座標を知る必要はない。
【１０４６】  フルパフォーマンスモードのこれらの面の故に、他のパラメータ以外にフルレートパケット１１９０４は、
・  全体としてスタンプに適用可能な情報、
・  情報がフルレートパケットで供給されるスタンプ内のフラグメントの数、
・  フルレートパケットによって記述されるフラグメントに適用可能な材料及び光キャッシュ１４００１ｇ、１４００１ｈ（図Ｇ３４）、
・  スタンプ内の各フラグメント毎の情報、
・  フラグメントの単位法線１４００１ｄ（図Ｇ３４）、及び
・  フラグメントの主及び副カラー、
を供給する。
【１０４７】  「フラグメント」からのフルレートパケット１１９０４の一実施の形態が表Ｐ１に示されている。この表は、パケット内の各データアイテム、アイテム名、ビット／アイテム、パケット内のアイテムの数、アイテムのために使用されるビット／パケット、アイテムのために使用されるバイト／パケット、共用ファクタ、及びアイテムのために使用されるバイト／フラグメントをリストしている。
【１０４８】  表Ｐ１内に示されているパラメータ／データアイテムのキーサブセットは、後述する“フォングパラメータの説明”の項で定義する。このフルレートパケットの実施の形態は単なる例示に過ぎず、本発明を限定する意図はない。
【１０４９】  表Ｐ１の下部に示されているのは、ＤＳＰＧが毎秒２５０．００Ｍフラグメントを処理するものとして、フルレートパケット（３，８１２．５０Ｍバイト／秒）を転送するために要する帯域幅の推定である。
フラグメントからのハーフレートパケット
ハーフレートにおいては、図示した「フォング」の実施の形態は、バンプマッピング及びローカルビューワ（即ち、可変目位置）操作を遂行することができる。フルレート操作との別の差は、これらの操作のためにフラグメントブロックによって供給される法線が、単位大きさのものである必要がないことである。
【１０５０】  これらの差の結果として、フルレートパケット１１９０４で供給される情報に加えて、ハーフレートパケット１１９０２は、スタンプ内の各フラグメント毎に、法線単位ベクトル及び関連する大きさ１４００１ｄ（図Ｇ３４）、表面接線単位ベクトル及び関連する大きさ（バンプ基底の一部１４００１ｅ、図Ｇ３４）、表面従法線単位ベクトル及び関連する大きさ（バンプ基底の一部１４００１ｅ、図Ｇ３４）、目座標１４００１ｆを供給する。
【１０５１】  上記フルレートの実施の形態のように、「フラグメント」１１０００は、ＶＳＰ毎に１つのハーフレートパケット１１９０２を送ることができ、これはＶＳＰを構成する４つまでのフラグメントにも適用される。
【１０５２】  「フラグメント」からのハーフレートパケットの一実施の形態を、表Ｐ２に示す。表Ｐ２内に示されているパラメータ／データアイテムのキーサブセットは、後述する“フォングパラメータの説明”の項で定義する。このハーフレートパケットの実施の形態は単なる例示に過ぎず、本発明を限定する意図はない。
【１０５３】  表Ｐ２の下部に示されているのは、ＤＳＰＧが毎秒２５０．００Ｍフラグメントを処理するものとして、ハーフレートパケット（５，７１８．７５Ｍバイト／秒）を転送するために要する帯域幅の推定である。
モード注入からの材料キャッシュミスパケット
フォングブロック１４０００は、照明計算のアクティブな主題になり得る１つまたはそれ以上のオブジェクトのための材料キャッシュ１４１５０を含んでいる（図３４、３５）。この情報は、一般にオブジェクト毎に変化するので、新しいオブジェクトのためにフォング／バンプ計算を遂行する時に、新しいオブジェクトの材料特性が材料キャッシュ１４１５０内に存在する見込みはない。
【１０５４】  図示した実施の形態では、「フラグメント」１１０００は、照明されるフラグメントに関連する特定の材料情報を識別する材料インデックス１４００１ｈ（図Ｇ３４）を供給する。一実施の形態では、この材料インデックスは、ハーフ及びフルレートフラグメントパケット１１９０２、１１９０４の一部として伝送される。材料インデックス１４００１ｈが材料キャッシュ１４１５０内の情報と一致しない場合には、「フォング」１４０００はキャッシュミスメッセージを発行して、「フラグメント」１１０００に「モード注入」１００００からキャッシュミスパケット１１９０６を戻させる。「フォング」１４０００は材料キャッシュミスパケット１１９０６を使用して、その新しいオブジェクトのためのデータを材料キャッシュ内に充填させる。
【１０５５】  一般的に、材料キャッシュミスパケット１１９０６内に供給される情報は、
・  独自の材料キャッシュインデックス１４００ｈ、
・  材料キャッシュミスパケットによって記述されているオブジェクトに関連する各テクセル毎の（どのようにそのテクセルを使用するかを記述している）テクスチャ情報であって、以下のものを含む、
・  テクセルフォーマット（テクセル情報をどのようにアンパックするか）、
・  テクセルモード及びサブモード（テクセル情報をどのように関連フラグメントに適用するか）、
・  フラグメント材料情報であって、以下のものを含む、
・  そのオブジェクトのための放射、周囲、拡散、鏡面、及び光沢特性、
・  カラーモード情報。
【１０５６】  材料キャッシュミスパケット１１９０６の一実施の形態のフォーマットが、表Ｐ３に示されている。記載されているデータアイテムのための情報は、“共用ファクタ”のヘッダーが欠けていることを除いて、表Ｐ１及びＰ２と同一である。表Ｐ３内に示されているパラメータ／データアイテムのキーサブセットは、後述する“フォングパラメータの説明”の項で定義する。この材料ミスパケットの実施の形態は単なる例示に過ぎず、本発明を限定する意図はない。
【１０５７】  表の下部に示されているのは、図示した材料パケットを転送するために要する帯域幅の推定である。２つの新しいオブジェクトのための材料データが各タイル内に必要であるものとすれば、毎秒のミスの数は、７５００タイル／フレーム×７５フレーム／秒×２ミス／タイル＝１．１２５百万ミス／秒になる。各材料キャッシュミスパケットが１０５．２５バイトであるものとすれば、材料キャッシュミスパケットを伝送するのに必要な合計帯域幅は、１１８．４１Ｍバイト／秒になる。
モード注入からの光キャッシュミスパケット
フォングブロック１４０００は、照明計算に使用される１つまたはそれ以上のオブジェクトのための光情報を保持する光キャッシュ１４１５４を含んでいる（図３４、３５）。この情報は、典型的にはフレーム当たり１回変化する。従って、材料キャッシュとは対照的に光キャッシュミスは起こり得ない。従って、光キャッシュミスのための帯域幅は無視すべきである。
【１０５８】  図示した実施の形態では、「フラグメント」１１０００は、照明されるフラグメントに関連する照明計算に使用される特定の光情報を識別する光インデックス１４００１ｇ（図Ｇ３４）を供給する。一実施の形態では、この光インデックスは、ハーフ及びフルレートフラグメントパケット１１９０２、１１９０４の一部として伝送される。光インデックス１４００１ｇが光キャッシュ１４１５４内の情報と一致しない場合には、「フォング」１４０００はメッセージを発行して、「フラグメント」１１０００に「モード注入」１００００から、光キャッシュ１４１５４内へ書込まれる光キャッシュミスパケット１１９０８を戻させる。
【１０５９】  一般的に、光キャッシュミスパケットは、
・  全ての光に共通な一般的なライティング環境に関する情報として、
・  グローバル周囲カラー、
・  光インデックス１４００１ｇ、
・  フォグモード、及び
・  フォグカラー、等、
・  各光毎の情報として、
・  光拡散カラー、
・  光周囲カラー、
・  光鏡面カラー、
・  減衰、
・  スポットライト方向、等
を含む。
【１０６０】  光キャッシュミスパケット１１９０８の一実施の形態のフォーマットが、表Ｐ４に示されている。記載されているデータアイテムのための情報は、“共用ファクタ”のヘッダーが欠けていることを除いて、表Ｐ１及びＰ２と同一である。表Ｐ４内に示されているパラメータ／データアイテムのキーサブセットは、後述する“フォングパラメータの説明”の項で定義する。この光ミスパケットの実施の形態は単なる例示に過ぎず、本発明を限定する意図はない。
テクスチャパケット
テクスチャブロック１２０００は、あるフラグメントに適用される各テクスチャ毎に１つのテクスチャパケット（または、テクセル）１２９０２（図３４に示すテクスチャデータ１２００１ａに対応）を放出する。テクスチャパケット１２９０２は、テクスチャを多くの考えら得る使用に適合させるために、いろいろなテクスチャ情報をさまざまなフォーマットで供給することができる。例えば、テクスチャパケットは、ＲＧＢＡカラー値、普通のテクスチャデータ、ブリンバンプマップデータ、またはＳＧＩバンプマップデータを供給することができる。異なる実施の形態では、あるフラグメントに適用できるテクスチャの数、またはテクスチャパケット及びその中に含まれているテクスチャ情報を使用して渡されるテクスチャ情報の型に制限はない。
【１０６１】  図示した実施の形態では、フォング処理は、フラグメントのための全てのテクスチャ１２９０２（０乃至８）が受信されるまでは進行しない。実際のテクセルだけが「テクスチャ」１２０００によって送られ、テクスチャの使用を記述する全ての情報は材料キャッシュ１４１５０内に保持される（何故ならば、この使用情報は、フラグメント毎の基準でではなく、オブジェクト毎の基準で変化するからである）。
【１０６２】  テクセル１２９０２の一実施の形態のフォーマットを、表Ｐ５に示す。この実施の形態では、全てのテクセル１２９０２は３６ビットからなる。これらの３６ビットは、図示した実施の形態におけるテクスチャの異なる用途に適合させるために、多くの異なるテクセルデータフォーマットに従って編成することができる。一実施の形態では、表Ｐ１１に示すように、１１の異なるテクセルデータフォーマットが存在している。特に、異なるテクセルデータフォーマットは、異なるテクセルデータ型（例えば、ＲＧＢＡまたはＲＧＢ）及び所与のデータ型のための異なるデータ範囲に関連させることができる。この実施の形態は単なる例示に過ぎず、本発明を限定する意図はない。
【１０６３】  一実施の形態においてテクセル１２９０２を伝送するのに要する帯域幅を、表Ｐ５に示してある。結果（１．１３Ｅ＋０９バイト／秒）は、各フラグメント毎に１つのテクセル１２９０２が送られ、２．５Ｅ＋０８フラグメントがＤＳＧＰ／秒で送られることを仮定している。
ピクセルへの出力パケット
あるスタンプのためのライティング／バンプマッピング操作が完了すると、フォングブロック１４０００はカラー出力パケット１４９０２（データ１４００２に対応、図Ｇ３４）を「ピクセル」１５０００へ送る。このカラー出力パケット１４９０２は、スタンプの各フラグメント毎に、最終フラグメントカラー、及び他のデータ経路を介して「ピクセル」へ到来する他のモードデータとカラーとを同期させることを可能にするＶＳＰポインタを含んでいる。
【１０６４】  「フォング」がスタンプに深さテクスチャを適用した時に、フォングブロック１４０００は、対応するＺ値、及び新しいＺ値を他のモードデータと同期させることを可能にするＶＳＰポインタを含む深さ出力パケット１４９０４を「ピクセル」１５０００へ送ることもできる。この場合、「ピクセル」１５０００は、その通常の２計算を中断し、全てのサブピクセルのために渡されたＺ値だけを使用しなければならない。
【１０６５】  出力パケット１４９０２及び１４９０４の実施の形態を、それぞれ表Ｐ６及びＰ７に示す。表Ｐ６及び７内に示されているパラメータ／データアイテムのキーサブセットは、後述する“フォングパラメータの説明”の項で定義する。これらの実施の形態のための帯域幅推定は、各表の右下に示されている。即ち、カラーパケット当たり４．６２５バイト、及び毎秒２．５Ｅフラグメントであるとすれば、カラーパケット１４９０２は、１．１６０９バイト／秒を必要とする。同様に、カラーパケット当たり３．６２５バイト、及び毎秒２．５Ｅ＋０８フラグメントであるとすれば、深さパケット１４９０４は、９．０６＋０．８バイト／秒が必要である。
【１０６６】  これらのカラー及び深さパケットの実施の形態は単なる例示に過ぎず、本発明を限定する意図はない。例えば、代替実施の形態では、深さ及びカラー情報は同一パケットで渡すことができる。
入力待ち行列
図Ｇ３５に示す実施の形態では、「フォング」１４０００は入力待ち行列１４１５８を含んでいる。入力待ち行列１４１５８は２つの区分、即ち「フラグメント」１１０００からのパケットを含む領域１４１６２と、「テクスチャ」１２０００からのパケットを含む領域１４１６６とを有している。入力待ち行列のフラグメント部分１４１６２は、現在では１５０クロック（１５０テクセル）と推定されるテクスチャ部分を通る待ち時間をカバーし、また別の５０クロックと推定されるフラグメント部分を通るデータ経路の異なる待ち時間を与えなければならない。一実施の形態では、「テクスチャ」１１０００が機能を停止してしまわないように、待ち行列のテクスチャ部分１４１６６は、フラグメント待ち行列１４１６２と同一サイズである。
【１０６７】  本発明のＤＳＧＰでは、特別な各テクスチャは、処理用に付加的なクロックサイクルを必要とする。その結果、待ち行列１４１６２、１４１６６内の最悪例ストレージサイズは、単一のテクスチャが使用されている場合である（何故ならば、この場合、テクセル当たり１つのフラグメントを、待ち行列のフラグメント部分１４１６２内に格納しなければならないからである）。更に、ハーフレートの場合には、フルレートの場合よりもかなり多くの情報がフラグメント毎に格納される。
【１０６８】  この全てを与えた時の、フルレート及びハーフレートの場合のための入力待ち行列の推定を表Ｐ８に示す。単一ＶＰＳの場合のテクスチャ入力待ち行列内の最大バイト数が、
（８テクセル／ピクセル）×（４ピクセル／スタンプ）×（５バイト／テクセル）＝１６０バイト
であることに注目されたい。
【１０６９】  キャッシュ
「フォング」は、２つの型のキャッシュ情報、即ち、グローバル描写モードを特徴付ける情報（“光”キャッシュ１４１５４）、及びオブジェクトを特徴付ける情報（“材料”キャッシュ１４１５０）を維持している。キャッシュミスパケット区分において説明したように、前者は典型的なアプリケーションの場合にはあるフレーム中に殆ど変化しないことが予測され、後者はオブジェクト毎の基準で変化することが予測される。
【１０７０】  予測されるキャッシュミス率に関する説明は、光及び材料キャッシュミスパケットの説明におけるパケット帯域幅推定を参照されたい。
【１０７１】  光キャッシュ
図示した実施の形態では、光キャッシュ１４１５４は、シーン内の全てのアクティブな光のためのライティング情報を格納するので、どのフラグメントにおいてもキャッシュミスは存在しない。一実施の形態では、「フォング」は８フラグメント光を許容し、付加的な光はジオメトリエンジン内だけで使用される。８つの各光毎に光キャッシュ１４１５４内に格納される情報を、表Ｐ９に示す。この実施の形態では、光キャッシュ１４１５４は、図Ｇ４Ｐを参照して説明した光キャッシュミスパケットと同一の情報を保持する。
【１０７２】  材料キャッシュ
材料キャッシュ１４１５０は、複数のオブジェクトのための材料データを格納することができる。一実施の形態では、材料キャッシュは、あるフラグメントの１つの面（前または後）だけのための情報を格納している。そのフラグメントのために格納されている前／後面フラグは、格納されている材料データがそのフラグメントの前面であるのか、または後面であるのかを指示する。「モード注入」（ＭＩＪ）は、キャッシュエントリがそのフラグメントの見ることができる面のための正しい値を含むことを保証する。各３２オブジェクト毎に材料キャッシュの一実施の形態内に格納されている情報が、表Ｐ１０に示されている。表Ｐ１０は、表Ｐ３を参照して説明した材料キャッシュミスパケットと同一の情報を含んでいる。
【１０７３】フォングブロックパラメータの説明
以下は、「フォング」１４０００によって使用されるパラメータの定義である。これらのパラメータは、上記パケット、待ち行列、及びキャッシュの説明に付随する表内に記載されており、以下のフォング操作の擬似コード記述内にも使用されている。
カラー材料可能化：材料値を、到来するグロー主カラーと置換可能にする。
カラー材料前／後フラグ：材料値と到来するグロー主カラーとの置換を、フラグメントの前面上で発生させるべきなのか、または後面上で発生させるべきであるのかを告げる。
カラー材料モード：どの材料値を到来するグロー主カラーと置換させるのかを告げる。
テクスチャからの深さ：Ｚ値、ｚバッファ内で使用されているものと同一の単位であると想定して、テクセルから取られ、深さ比較操作において使用されるｚ値と置換される。
距離カットオフ：ローカル光までの距離が大きすぎる場合、そのライティング計算は無視することができ、残余のライティング計算を回避することができる。ドライバによって計算されるこの値は、このカットオフのために使用される。
【１０７４】目ｘ，ｙ，ｚ：目座標内のフラグメントの位置。
フォグカラー：ＲＧＢＡモードにおいては、もしフォグが動作可能にされれば、フラグメントと混合されるＲＧＢ値（Ａは影響されない）。カラーインデックスモードにおいては、フォグ方程式のカラーインデックス形状で使用される２４ビットの浮動小数点。
フォグモード、フォグパラメータ１，フォグパラメータ２：フォグ計算を定義するパラメータ。もしフォグモードが一次であれば、パラメータ１は終わり／（終わり・開始）であり、パラメータ２は１／（終わり・開始）である。もしフォグが指数であれば、パラメータ１はフォグ密度であり、パラメータ２は使用されない。もしフォグが自乗指数であれば、パラメータ１は自乗フォグ密度であり、パラメータ２は使用されない。
フラグメント周囲、フラグメント放射、フラグメント拡散、フラグメント鏡面、
フラグメント光沢：ライティング方程式において使用される到来するフラグメントの材料特性。
フラグメント前／後フラグ：このフラグメントが三角形の前からであるのか、または後からであるのかを告げる。
フラグメント光可能化：フラグメント・ライティングメカニズムがアプリケーションによって現在動作可能にされているか否かを指示するブール値。
フラグメントカラー：ピクセルブロックへ送られるフォング計算、Ｒ、Ｇ、Ｂ、Ａの最終値。
グローバル周囲カラー：シーンに均一に適用される一定のカラー値。
ヘッダー：パケット型を指示する。バケットを解釈するのに必要な他の何等かの情報は専用フィールド内に含まれている。
Ｋｃ（一定減衰）、Ｋｌ（一次減衰）、Ｋｑ（二次減衰）：光計算における減衰項を定義するパラメータ。ＧＬ仕様を参照されたい。
【１０７５】光周囲カラー、光拡散カラー、光鏡面カラー：光計算において異なる項に使用される所与の光のためのカラー。ＧＬ仕様を参照されたい。
光キャッシュインデックス：光毎の、及びグローバルモードの情報を保持するキャッシュを指すインデックス。
ローカルビューワ可能化：ビューワ位置までの方向を、一定としてではなく、計算しなければならないか否かを指示するブール値。
材料キャッシュインデックス：オブジェクト毎の情報を保持するキャッシュを指すインデックス。
法線の大きさ：単位ベクトルの浮動小数点大きさ。
法線単位ベクトル：正規化されたベクトルの方向を表すために基準化された３つの固定小数点成分。
フラグメント数：フォングブロックが、このＶＳＰ内にどれ程多くのフラグメントを含んでいるかを告げる。到来するテクスチャとフラグメントとを相関可能にするために必要。
テクスチャ数：フォングブロックがフラグメント当たりどれ程多くのテクセルを含んでいることが予測されるかを告げる。
パケット長：上流からフラグメントブロックを通過するパケットのために、通過を容易にするために使用される。
ピクセルマスク：ＶＳＰ内の４つのピクセルのどれを着色させるのかを指示するマスク。
光沢カットオフ：ドライバによって計算される値であって、鏡面成分の指数化を回避できるようにする。
表面接線ｓ単位ベクトル、表面接線ｔ単位ベクトル、表面接線ｓ大きさ、表面接線ｔ大きさ：法線と共に、法線ベクトルを動揺させるために使用される座標系の基底を定義する２つのベクトル。
主及び副カラー：もし鏡面カラー分離が有効であれば、主カラーはグロー計算からの拡散成分であり、副カラーは鏡面成分である。有効でなければ、主カラーは拡散及び鏡面値の合計を含み、副カラーは０を含む。
テクスチャ適用モード：テクスチャをどのように、即ち普通のカラー、バンプ、テクスチャ・材料、または深さ・テクスチャの何れに解釈すべきかを告げる。
テクスチャ適用サブモード：付加的な詳細が必要である時にテクスチャ適用モードを修飾する。どの材料成分をテクスチャ値によって置換すべきか、どのバンプマッピングスキームが有効であるのか、及びどの光・テクスチャモードが使用されているのかを告げる。
テクスチャ環境モード：テクスチャを、どのように到来するカラー値と組合わせるのかを告げる。
テクスチャ前／後面フラグ：このテクスチャを多角形の前に適用するのか？、または後に適用するのか？
テクスチャＧＬベース内部フォーマット：テクスチャ環境方程式をどのように適用するのかを告げる。ＧＬベース・内部・フォーマット情報に対応。
テクスチャテクセルデータフォーマット：  ３６ビットテクセルからデータをどのようにアンパックしてテクスチャ環境へ入力するためのＲＧＢＡ値を形成するかを告げる。
Ｓｃ（スポットカットオフ）、Ｓｅ（スポット指数）：スポットライトジオメトリに起因する減衰を定義するパラメータ。ＧＬ仕様を参照されたい。
ＶＳＰポインタ：より多くのモード情報が格納されているピクセルブロックの入力バッファを指すインデックス。
【１０７６】  計算擬似コード
以下に、上述した各サブユニット内で遂行される計算を、制御の流れを示す擬似コードアプローチを使用して説明する。これらの擬似コードの説明に続いて、バンプサブユニットにおいて遂行される処理の付加的な詳細を説明する。
テクスチャ計算
ライティング計算への全ての入力はテクスチャ値によって変更することができるから、テクスチャ計算は他の全ての計算を“ゲート”する。もし、テクスチャが到来しないことをテクスチャサブユニットが見出せば、テクスチャサブユニットは他の計算サブユニットへ「ヌル」（ＮＵＬＬ）を送り、それらはテクスチャサブユニットからゴーアヘッドを受けるまで閉塞される。
【１０７７】  テクスチャ処理のこの説明は、我々の内部データ表現と、ＧＬによって定義されている“ベース内部フォーマット”パラメータとでは明らかに異なる。テクセルの処理は３つの操作、即ちアンパッキング、テクスチャ環境計算、及び結果経路指定に分割することができる。この処理は、材料キャッシュ１４１５０内に供給される以下のパラメータ（それらの許容値が、以下に列挙されている）によって制御される。
テクセルデータフォーマット：これは、３６ビットテクセルによって使用されるデータ表現であり、どのようにアンパックして２４ビット浮動ＲＧＢＡを形成すべきかを指定しているが、それをどのように処理するのかに関しては何も述べていない。
Ｇｌベース内部フォーマット：ＧＬ仕様では、この値はテクスチャ内の成分の数、及びテクセルを処理するために使用されるテクスチャ環境方程式の表内の行の両方を定義する。Ｇｌベース内部フォーマットの所与の値はテクセルデータフォーマットの若干の値を意味することだけはできるが、それにも拘わらずそれらは別々のパラメータである。
Ｇｌテクスチャ環境モード：これは、ＧＬ仕様から来たものであり、テクスチャ環境機能の表内の列を選択するために使用される。
テクスチャ適用モード：これは、テクスチャ環境の出力をどの機能ユニットへ宛てるのかを決定するレイサー定義された値である。
テクスチャ適用サブモード：これは、テクスチャ適用モードによって選択された機能ユニット内で、とのようにテクスチャが使用されるのかを正確に決定するレイサー定義された値である。
【１０７８】  図Ｇ４２は、「テクスチャ計算」１４１１４の処理の流れを示す高レベル流れ図である。「テクスチャ計算」１４１１４は、「テクセルアンパッキング」１４１６０、「テクスチャ環境計算」１４１６４、「テクスチャ経路指定」１４１７０、「再整列」１４１７４、及び他のサブユニット１４１７８を含む。これらのステップは、「テクスチャ環境計算」１４１４２及び他のサブユニット１４１７８（例えば、「材料選択」１４１２６、「バンプ」１４１３０、または「光テクスチャ」１４１３４）を含む他のフォングブロックと対話する。
【１０７９】  テクスチャデータフォーマット及びＧｌベース内部フォーマットに依存して、テクセルアンパッキング操作１４１６０は、３６ビットのテクセル１２９０２を２４ビットの浮動小数点ＲＧＢＡ値１４１６１にアンパックする。Ｇｌベース内部フォーマット及びＧｌテクスチャ環境モードに依存して、「テクスチャ環境計算」１４１４２は、入力カラー（ＲＧＢＡ値１４１６１）とテクスチャ経路指定ステップ１４１６６からの“現カラー”１４１７１とを混合する手法を指定する。テクスチャ適用モードの値に依存して、テクスチャ経路指定ステップ１４１７０は、到来するテクセルをどのフォング計算へ経路指定すべきかを決定する。詳述すれば、テクスチャ経路指定ステップ１４１６６は、カラーテクスチャをテクスチャ環境計算ステップ１４１６４へ直接渡し、非カラーテクスチャを再整列ステップ（１４１７４）へ渡す。再整列ステップ１４１７４はこのデータを再整列させ、再整列されたテクスチャデータの他のサブユニット１４１７８への経路指定を完成させる。例えば、再整列ステップ１４１７４は、バンプテクスチャをバンプサブユニットへ、材料テクスチャを材料計算ユニットへ、そして深さテクスチャを光・テクスチャユニット１４１３４へ渡す。
【１０８０】  以下に、一実施の形態において許容されるデータ範囲を、テクスチャ定義パラメータ（テクスチャデータフォーマット、Ｇｌベース内部フォーマット、テクスチャ適用モード、テクスチャ適用サブモード）について説明する。これらのデータ範囲は例示に過ぎず、本発明を限定する意図はない。
テクスチャ定義パラメータのための許容範囲
テクスチャデータフォーマット値
図示の実施の形態では、テクセル１２９０２（図Ｇ４２）は３６ビットワードであり、そのフォーマットは次のように定義されている。
ＴＤＦ＿ｎｖ＿ｎｄ＿ｄｐ
ここに、ｎｖ＝ワード内のデータ値の数、
ｎｄ＝ビットの数／値、
ｓ＝符号付き、または符号なし、
ｄｐ＝小数点の位置、
である。
【１０８１】  図示の実施の形態では、符号付きの値は、２の補数ではなく、符号・大きさフォーマットを有している。テクセルがアンパックされると、４つのＲＧＢＡ値が生成される。アンパッキング操作１４１６０において、テクセル１２９０２内に見出されない値は、以下の表（表Ｐ１１）（一実施の形態において使用されている１１の異なるテクセルデータフォーマットを掲載している）の“にアンパック”列によって示されているように０で埋められる。各フォーマットは、それが保持している値の数、値当たりのビットの数、各値のデータ範囲、及びアンパックした後に使用可能な情報を特徴としている。例えば、フォーマットＴＤＦ＿２＿１６＿ｕ＿０のテクセルを２つの値、即ちＲ（テクセルの最初の１６ビット）及びＡ（第２の１６ビット）にアンパックすることができる。これらのフォーマットは例示であり、どのような数のテクセルフォーマットにも適合できる本発明を限定する意図はないことに注目されたい。
注１）単一の値を含むテクセルの場合、もしＧｌベース内部フォーマットが“アルファ”であればアンパックされた値をＡ（アルファ）へ回路指定すべきであり、そうでなければＲへ経路指定される。
注２）Ｇｌテクスチャ環境モードが「置換」である場合には、ピクセルはテクセルによって定義されている真の深さ値を正確に必要とするから、２４ビットをそのまま通過させなければならない。
Ｇｌベース内部フォーマット値
図示した実施の形態は、６つの異なる型のカラーデータ、即ち、アルファ、輝度、輝度・アルファ、強度、ＲＧＢ、及びＲＧＢＡを支援する。これらの異なる各データ型には、独特なＧｌベース内部フォーマット値が割当てられ、テクスチャ環境表の独自の行に関連付けられる。
【１０８２】        値                            関連する行
Ａ（アルファ）            テクスチャ環境表の行０を使用
Ｌ（輝度）                テクスチャ環境表の行１を使用
ＬＡ（輝度・アルファ）    テクスチャ環境表の行２を使用
Ｉ（強度）                テクスチャ環境表の行３を使用
ＲＧＢ                    テクスチャ環境表の行４を使用
ＲＧＢＡ                  テクスチャ環境表の行５を使用
他の実施の形態は、より多くの、またはより少ないＧｌベース内部フォーマットを支援することができる。テクスチャ環境表を以下に示す。
Ｇｌテクスチャ環境モード値
テクスチャ環境計算ブロック１４１６４の図示実施の形態は、現、及び新カラー１４１７１、１４１６１上で５つの異なるカラー組合わせ操作、即ち現を新に置換、現を新で変調、転写、現と新とを混合、及び現と新とを加算を支援する。これらの異なる操作には、独特なＧｌテクスチャ環境モード値が割当てられ、テクスチャ環境表の独自の行に関連付けられる。
【１０８３】        値                            関連する行
置換                      テクスチャ環境表の列０を使用
変調                      テクスチャ環境表の列１を使用
転写                      テクスチャ環境表の列２を使用
混合                      テクスチャ環境表の列３を使用
加算                      テクスチャ環境表の列４を使用
他の実施の形態は、より多くの、または少ないＧｌベース内部フォーマットを支援することができる。テクスチャ環境表を以下に示す。
テクスチャ適用モード値
図示の実施の形態は、５つの型のテクスチャ、即ちカラー、バンプマップデータ、材料データ、光情報、及び探さ情報を支援する。テクスチャ適用モードは、入力テクセル１２９０２内のテクスチャ情報の型に従って、これらの値の１つにセットされる。テクスチャ経路指定モジュール１４１７０は、このパラメータ値に依存して情報を、アンパッキングモジュール１４１６０から適切なサブユニットへ経路指定する。異なるテクスチャ適用モード及び関連経路指定は以下の通りである。
【１０８４】  カラー    出力を使用してテクスチャ環境計算１４１６４への入力としてのフラグメントカラーを置換する。
バンプ    バンプサブユニット１４１３０へ経路指定し、フラグメントカラーをグロー主カラーにリセットする。
材料      材料サブユニット１４１２６へ経路指定し、フラグメントカラーをグロー主カラーにリセットする。
光        光サブユニット１４１３８へ経路指定し、フラグメントカラーをグロー主カラーにリセットする。
深さ      ピクセルブロックへ経路指定し、フラグメントカラーをグロー主カラーにリセットする。
テクスチャ適用サブモード値
テクスチャ適用サブモードの列挙した値はテクセルの特定のサブタイプを指示し、このテクセルの一般型はテクスチャ適用モードによって供給される。従って、テクスチャ適用サブモードパラメータの列挙した値のセットは、テクスチャ適用サブモードパラメータの値に依存する。以下に、これらの列挙した値を異なるテクセル型に関して説明する。
【１０８５】  テクスチャ適用モード＝バンプである時は、以下のサブモードが適用される。
ＳＧＩバンプ    法線ベクトルとして使用されるＲＧＢ値、
ブリンバンプ    法線ベクトルに対する動揺として使用されるＲＡ値。
テクスチャ適用モード＝材料である時は、後続するサブモードがどの材料成分を放出、周囲、拡散、鏡面、周囲・及び・拡散、光沢に置換するかを指定する。
テクスチャ適用モード＝光である時は、後続するサブモードが適用される。
周囲              光周囲値を置換、
拡散              光拡散値を置換、
鏡面              光鏡面値を置換、
減衰・ＳＧＩＸ    光減衰値を置換、
陰影・減衰        付加的な陰影・減衰値として使用。
以下の資料から付加的な背景情報を入手できるので参照されたい。
【１０８６】  ＧＬ  １．１  ｓｐｅｃ  Ｓｅｃｔｉｏｎ  ３．８
ＳＧＩＳ＿ｍｕｌｔｉｔｅｘｔｕｒｅ、
ＳＧＩＸ＿ｌｉｇｈｔ＿ｔｅｘｔｕｒｅ、
ＳＧＩＸ＿ｆｒａｇｍｅｎｔ＿ｌｉｇｈｔｉｎｇ、
ｓｅｐａｒａｔｅ＿ｓｐｅｃｕｌａｒ＿ｃｏｌｏｒ、
ＳＧＩＸ＿ｔｅｘｔｕｒｅ＿ａｄｄ＿ｅｎｖ。
これらの資料は、ＳＧＩバンプマッピングを支援するためには、ＯｐｅｎＧＬ仕様への拡張が必要であることを述べている。
テクスチャ計算擬似コード
以下は、一般的には、プログラマ及びエンジニアその他のコンピュータプログラミングの分野に精通する者に、特定的には、コンピュータグラフィックスプログラミング及びプロセッサ設計に公知のＣ言語規約を使用して書かれたテクスチャ処理の一実施の形態の擬似コード記述である。
【１０８７】
【数９４】
2004272928.tif 000136
以下の表は、上記擬似コードの説明において言及した複数の入力のための源及び説明である。
【１０８８】
2004272928.tif 000137
2004272928.tif 000138
テクスチャ環境方程式
テクスチャ環境方程式は、上記擬似コード内に定義されているように入力カラーを“現カラー”と混合する手法を指定する。この方程式は、さまざまなカラーデータ型（例えば、アルファ（Ａ）、輝度（Ｌ）、輝度・アルファ、強度（Ｉ）、ＲＧＢ（Ｃ）、ＲＧＢＡ、輝度等）を入力として使用して、広範囲の混合操作（例えば、置換、変調、転写、混合、加算等）を遂行するために使用することができる。考え得るいろいろな方程式が、本発明では二次元テクスチャ環境表（表Ｐ１２）内のセルとして効率的に表されている。この表の行は異なるカラーデータ型に対応し、列は異なるカラー混合操作に対応している。これらの方程式は、幾つかの添字（ｆ、ｔ、ｃ、ｂ）、並びにカラーデータの型の略語を使用している。添字“ｆ”は、現（フラグメント）カラーを表し、“ｔ”はテクスチャカラーを表し、“ｃ”はテクスチャ環境カラーを表し、そして“ｂ”は“バイアス”（ＧＬ拡張ＳＧＩＸ＿ｔｅｘｔｕｒｅ＿ａｄｄ＿ｅｎｖ．から導出されたテクスチャ値に対する一定のオフセット）を表している。またこれらの方程式には、値Ｓ０、Ｓ１、及びＳ２が使用されており、これらは符号＋／−１であってテクスチャの減算並びに加算を可能にするものである。輝度（Ｌ）及び強度（Ｉ）値は、実際にはテクセルの“Ｒ”成分から得られることに注目されたい。
材料計算
図Ｇ４１を参照する。「材料計算」１４１２６は、あるフラグメントの材料特性を、テクスチャ・材料値１４１２４として（即ち、テクセルとして）、またはフラグメント・カラー・材料値１４１０８として（即ち、フラグメントパケットの一部として）供給される新しい値で置換する。図示の実施の形態では、ＧＬ仕様へのＳＧＩ拡張と矛盾せずに、フラグメント・カラー・材料はテクスチャ・材料に優先する。もしテクスチャ・材料も、フラグメント・カラー・材料も供給されなければ、「材料計算」１４１２６は、そのフラグメントの材料キャッシュポインタによって識別される材料キャッシュエントリからの材料値を用いてそのフラグメントを表示する。「材料計算」１４１２６は、複数の副計算を含む。
【１０８９】  もしテクスチャ・材料値１４１２４が送られれば、第１の副計算は、フラグメントの前／後フラグと、テクスチャ・材料１２１２４の前／後面属性とを比較し、もし両者が一致すれば、テクスチャ適用サブモードパラメータ（放出、周囲、拡散、鏡面、または周囲・及び・拡散の何れか）によって識別される材料特性をテクスチャ・材料値で置換する。
【１０９０】  第２の副計算は、フラグメント・カラー・材料操作が可能化されているか否かを決定する。もし可能化されており、そしてフラグメントの前／後フラグと、テクスチャ・材料１２１２４の前／後面属性とが一致していれば、この副計算はテクスチャ適用サブモードによって識別される材料特性をグロー主カラーで置換する。以下の資料から付加的な背景情報を入手できるので参照されたい。
【１０９１】  ＧＬ  １．１  ｓｐｅｃ  Ｓｅｃｔｉｏｎ  ３．８
ＳＧＩＸ＿ｌｉｇｈｔ＿ｔｅｘｔｕｒｅ、
ＳＧＩＸ＿ｆｒａｇｍｅｎｔ＿ｌｉｇｈｔｉｎｇ。
これらの資料は、ＳＧＩバンプマッピングを支援するためには、ＯｐｅｎＧＬ仕様への拡張が必要であることを述べている。
【１０９２】  以下は、一般的には、プログラマ及びエンジニアその他のコンピュータプログラミングの分野に精通する者に、特定的には、コンピュータグラフィックスプログラミング及びプロセッサ設計に公知のＣ言語規約を使用して書かれたテクスチャ処理の一実施の形態の擬似コード記述である。
【１０９３】
【数９５】
2004272928.tif 000139
以下の表は、上記擬似コードの説明において言及した複数の入力のための源及び説明である。
【１０９４】      入力        源
材料                            材料キャッシュ
フラグメント前／後フラグ        入力パケット
テクスチャ適用サブモード        材料キャッシュ
テクスチャ適用モード            材料キャッシュ
テクスチャ前／後                材料キャッシュ
カラー材料可能化                材料キャッシュ
カラー材料前／後                材料キャッシュ
カラー材料モード                材料キャッシュ
グローカラー                    入力パケット
バンプ計算
図Ｇ４３は、バンプ計算の役割を果たす本発明のＤＳＧＰの成分のブロック図である。これらの成分は、テクスチャブロック１２０００のテクスチャマッピングユニット１２９００、フラグメントブロック１１０００のフラグメント補間ユニット１１９００、及びフォングブロックのバンプ及びフラグメントライティングユニット１４１１４、１４１３０、１４１３８を含んでいる。
【１０９５】  本明細書の他の節において説明したように、「テクスチャマッピング」１２９００は、「フラグメント補間」１１９００から、テクスチャリングに必要なフラグメントのオブジェクト空間座標（ｓ，ｔ）を受ける。オブジェクト空間座標（ｓ，ｔ）は「テクスチャ」１２０００へのテクスチャマップＴＭＡＰ入力の座標系（接線空間、またはオブジェクト空間という）に対応する。「テクスチャマッピング」１２９００は、座標（ｓ，ｔ）に関連するテクスチャを決定し、関連テクスチャ情報を１組のテクセル１２９０２としてフォングブロック１４０００へ渡す（一実施の形態では、スタンプ当たり８までのテクセル）。前述したように、「テクスチャ計算」１４１１４がテクセルをアンパックし、異なる型のテクスチャ情報（例えば、テクスチャ・バンプ、テクスチャ・光、テクスチャ・材料）を適切なフォングユニットへ送る。詳述すれば、「テクスチャ計算」１４１１４は、あるフラグメントのためのテクスチャ・バンプ（Ｔｂ）データ１４１２２をバンプユニット１４１３０へ渡す。バンプユニット１４１３０は、同一フラグメントのためのジオメトリ情報１４１１０（表面法線Ｎ及び接線Ｖｓ、Ｖｔ）を、「フラグメント補間」１１９００から受けている。この情報を使用して「バンプ」１４１３０は、バンプデータＴｂによる法線Ｎの動揺を反映する動揺した目空間法線Ｎ’ＥＳを計算する。バンプユニット１４１３０は、動揺した法線Ｎ’ＥＳを「フラグメント照明」１４１３８へ出力する。「フラグメント照明」１４１３８は、新しいＮ’ＥＳを、材料及びライティング情報１４１２８、１４１３６、導出した光（Ｌ）及び半角（Ｈ）ベクトル、及びフラグメント位置Ｖと共に使用して、そのフラグメントに対応する１つのピクセルのカラー１４１４８を計算する。ピクセルカラー１４１４８はピクセルブロック１５０００へ出力され、ピクセルブロック１５０００はそのカラーを同一ピクセルのための他のカラーと組合わせることができる。
【１０９６】  前述したように、バンプマップ情報は、いろいろなフォーマット（例えば、ＳＧＩ、ブリン）でテクスチャマップＴＭＡＰ内に指定することができる。ブリンフォーマットでは、ＴＭＡＰは、２つのバンプ勾配（ｈｓ（ｓ，ｔ）、ｈｔ（ｓ，ｔ））を使用してバンプマップの各点を指定する。「テクスチャマッピング」１２９００は、この情報をＲＧＢテクセルの２つの成分としてパッケージする。一実施の形態では、ＲＧＢテクセルはテクセルデータフォーマットＴＤＦ＿３＿１２＿ｓ＿０（テクセルフォーマットの定義のための表Ｐ１１参照）で供給される。フォングテクスチャ計算ユニット１４１１４は、バンプ情報を、成分が（ｈｓ（ｓ，ｔ），ｈｔ（ｓ，ｔ），１．０）（スカラー１．０は、勾配によって動揺された単位表面法線の長さに対応する）である接線空間テクスチャ・バンプ（Ｔｂ）ベクトル１４１２２として「バンプ」１４１３０へ渡す。
【１０９７】  ＳＧＩフォーマットでは、ＴＭＡＰは、バンプマップの各点において、動揺した表面法線Ｎ’ＴＳの接線空間成分（ｎ’ｘ，ｎ’ｙ，ｎ’ｚ）を指定する。「テクスチャマッピング」１２９００は、この情報をＲＧＢテクセルの３つの成分としてパッケージする。一実施の形態では、ＲＧＢテクセルはテクセルデータフォーマットＴＤＦ＿３＿１２＿ｓ＿０（テクセルフォーマットの定義のための表Ｐ１１参照）で供給される。フォングテクスチャ計算ユニット１４１１４は、バンプ情報を、成分が（ｎ’ｘ，ｎ’ｙ，ｎ’ｚ）である接線空間テクスチャ・バンプ（Ｔｂ）ベクトル１４１２２としてバンプユニット１４１３０へ渡す。
【１０９８】  「フラグメント照明」１４１３８は、目空間における全てのライティング計算を遂行するが、そのためにはバンプユニット１４１３０が、テクスチャ・バンプ（Ｔｂ）データ１４１２２を接線空間から目空間へ変換する必要がある。一実施の形態では、バンプユニットにおいて、列が目空間基底ベクトル（ｂｓ，ｂｔ，ｎ）であるマトリックスＭとバンプマップデータのベクトルＴｂとを乗算することによってこれを遂行する。接線空間から目空間への変換マトリックスを構成している目空間基底ベクトルの成分はバンプデータ１４１２２によって定義されており、従って乗算（Ｍ×Ｔｂ）によってブリンバンプマッピング方程式
Ｎ’ＥＳ＝Ｎ＋ｂＳｈＳ＋ｂｔｈｔ
（５１）
によって目空間内の動揺した法線Ｎ’が求まる。
【１０９９】  詳述すれば、テクスチャ・バンプデータ１４１２２がＳＧＩフォーマットである場合には、バンプユニット１４１３０は、ｂｓ＝−Ｖｓ及びｂｔ＝−Ｖｔを使用して基底ベクトルを計算する。テクスチャ・バンプ情報がブリンフォーマットである
2004272928.tif 000140
方向の単位ベクトルである）。これらの定義を使用するとマトリックス乗算（Ｍ×Ｔｂ）は、目空間内の適切な動揺した表面法線Ｎ’ＥＳを生成する。このマトリックス乗算は、ハードウェアででも、またはソフトウェアででも実現することができる。
【１１００】  このアプローチは、従来技術のバンプマッピングアプローチよりも遙かに効率的である。例えば、１つまたはそれ以上の各光毎に光及び半角ベクトル（Ｌ、Ｈ）を共に接線空間に変換するようなＳＧＩバンプマッピングとは対照的に、本発明は、光の数には無関係に、テクスチャ・バンプベクトルＴｂを目空間へ１回変換すればよい。更に、「フラグメント」１１０００が補間されたベクトルを供給するので、図示の実施の形態は、従来技術で行われているような、法線または表面接線を補間する必要がない。
【１１０１】  バンプユニット１４１３０の一実施の形態の高レベル流れ図を、図Ｇ４４に示す。この実施の形態では、バンプユニットは先ず、フラグメントジオメトリベクトル（Ｎ，Ｖｓ，Ｖｔ）から単位基底ベクトル及び関連する大きさを計算し（操作１４３００）、次いでこれらの単位基底ベクトル及び関連する大きさ、及び接線空間からの情報（テクスチャ・バンプベクトルＴｂ）を使用して目空間１４３０２内の動揺した単位法線ＮＥＳ’を計算する（操作１４３０２）。
【１１０２】  この実施の形態は、マトリックス乗算ハードウェアを部分的に使用して、マトリックス計算（Ｍ×Ｔｂ）を効率的に実現している。図示の実施の形態は、始めに、ブリンバンプマッピング方程式が
【１１０３】
【数９６】
2004272928.tif 000141
である。
【１１０４】  基本一次代数原理を適用すると、書き直されたバンプマッピング方程式は、ブリンバンプ方法については以下のマトリックス乗算として表すことができる。
【１１０５】
【数９７】
2004272928.tif 000142
として展開することができる。この表現において、
2004272928.tif 000143
とができ、それによってバンプユニット１４１３０内に少なくとも部分的に固定小数点乗算ハードウェアを使用することが可能になる。このようなハードウエアは、元の非正規化マトリックス乗算（Ｍ×Ｔｂ）を遂行する必要がある浮動小数点乗算ハードウェアよりも遙かに簡単である。しかしながら、浮動小数点ハードウェアは、その中で遂行されるどの計算も、上述した実施の形態の何れの中でも使用できることに注目されたい。
【１１０６】  同様に、ＳＧＩバンプ方法の場合、書き直されたバンプマッピング方程式は、以下のマトリックス乗算として表すことができる。
【１１０７】
【数９８】
2004272928.tif 000144
図Ｇ４４の実施の形態では、「フラグメント」１１０００は、単位ベクトル及び関連する大きさのグループとして表面法線Ｎ及び表面接線Ｖｓ、Ｖｔを供給することによって、バンプマッピングのこの実施を支援している。例えば、
2004272928.tif 000145
給される。
バンプユニット１４１３０は、大きさ、及び表面法線Ｎ及び表面接線Ｖｓ、Ｖｔからなる単位ベクトルから、フォングブロック１４０００へのテクセル入力の内
2004272928.tif 000146
情報がＳＧＩフォーマットである場合には、「バンプ」１４１３０は、
【数９９】
2004272928.tif 000147
を使用して単位ベクトル及び関連する大きさを導出する。
【１１０８】  テクセル・バンプ情報がブリンフォーマットである場合には、「バンプ」１４１３０は、
【１１０９】
【数１００】
2004272928.tif 000148
を使用して単位ベクトル及び関連する大きさを導出する。
【１１１０】  このようにして単位基底ベクトル及び関連する大きさが与えられると、得られたマトリックス乗算（Ｍ’×ｍＴｂ）は、フラグメントライティング計算に使用するための所望の目空間動揺表面法線Ｎ’ＥＳを発生する。この別の方法から開始して、マトリックスＭ’は、異なる正接空間座標系（即ち、ブリンまたはＳＧＩ）から共通目空間座標系への変換を定義する。
【１１１１】  上述した実施の形態の一バージョンでは、バンプハードウェア１４１３０は、マトリックスＭ’の各成分を固定小数点値として格納することができる。しかしながら、マトリックスＭ’によって乗算されるベクトル（ｍｂｓｈｓ，ｍｂｔｈｔ，ｍｎ）を固定小数点ベクトルとして表すことはできない。これは、たとえＴｂ成分（即ち、バンプ勾配ｈｓ、ｈｔまたはＳＧＩ動揺法線成分ｎ’ｘ，ｎ’ｙ，ｎ’ｚ）が固定小数点値であることができるとしても、大きさｍｂｓ、ｍｂｔ、ｍｎはどのようなサイズであることもできるので、ベクトル（ｍｂｓｈｓ，ｍｂｔｈｔ，ｎ）を浮動小数点表現にする必要がある。このベクトルは固定小数点ではないので、乗算（Ｍ’×ｍＴｂ）は固定小数点ハードウェアでは完全に遂行することはできない。以下に、この問題に対処するための実施の形態を、図Ｇ４５を参照して説明する。
【１１１２】  図Ｇ４５は、図Ｇ４４からの操作１４３０２を実現し、固定小数点ハードウェアだけを使用して動揺した法線Ｎ’ＥＳを計算する。この図では、テクスチャ・バンプベクトルは一般的に（ｈｓ，ｈｔ，ｋｎ）として表されており、ここに、ブリンバンプマッピングでは、ｈｓ及びｈｔはバンプ勾配であり、ｋｎ＝１．０であり、またＳＧＩバンプマッピングでは、（ｈｓ，ｈｔ，ｋｎ）は動揺した法線の成分（ｎ’ｘ，ｎ’ｙ，ｎ’ｚ）に等しい。この実施は、得られる基準化された値を基準化されたベクトルｍＴｂ’の固定小数点値として表すことができるように、ベクトルｍＴｂの各成分を基準化するアイディアに基づいている。これにより、固定小数点ハードウェアを使用してマトリックス乗算Ｍ’×ｍＴｂ’が完全に遂行され、異なる尺度係数に適合するように再基準化され、正規化された結果がベクトルｍＴｂのそれぞれの成分に適用される。「フラグメントライティング」１４１３８へ伝送される得られた動揺法線は、単位法線である。
【１１１３】  図Ｇ４５に示すように、大きさベクトルｍ＝（ｍｂｓ，ｍｂｔ，ｍｎ）１４３１０とバンプベクトルＴｂ＝（ｈｓ，ｈｔ，ｋｎ）とが乗算され、更新されたテクスチャ・大きさベクトルｍＴｂ’が形成される（１４３１２）。次いで、ｍＴｂ’の成分が、
ｍＴｂ”＝（ｓｓ×ｍｂｓｈｓ，ｓｔ×ｍｂｔｈｔ，ｓｎ×ｍｎｋｎ）
のように、スカラー（ｓｓ，ｓｔ，ｓｎ）のベクトルｓによって基準化される。スカラーｓは、得られるマトリックスｍＴｂ”を固定小数点ベクトルとして表すことができるように選択される。これらのスカラーは同一であることもできるが、若干の状況では、大きさｍの考え得る広い範囲を与えるように異なることが考えられる。
【１１１４】  基準化されたベクトルｍＴｂ”及び単位変換マトリックスＭ’（これも固定小数点値からなる）は、固定小数点乗算ハードウェアを使用して完全に乗算され、動揺法線Ｎ’を発生する（１４３１６）。動揺法線Ｎ’の成分は再基準化され（１４３１８）、それらの大きさの間の正しい関係が再確立される。
【１１１５】  Ｎ”＝Ｎ’×１／（ｓｓ，ｓｔ，ｓｎ）
次いで、再基準化されたベクトルＮ”が正規化され（１４３２０）、単位動揺法線
2004272928.tif 000149
【数１０１】
2004272928.tif 000150
これが、「フラグメントライティング」の出力である。代替として、動揺法線の大きさを、単位動揺法線と共に「フラグメントライティング」へ渡すことができる。
【１１１６】  上述した何れかの実施の形態におけるように、図Ｇ９Ｐを参照して説明したどの操作、ステップ、または計算も完全に浮動小数点ハードウェアで遂行することができる。
【１１１７】  以下は、一般的には、プログラマ及びエンジニアその他のコンピュータプログラミングの分野に精通する者に、特定的には、コンピュータグラフィックスプログラミング及びプロセッサ設計に公知のＣ言語規約を使用して書かれたバンプ計算処理の一実施の形態の擬似コード記述である。この記述は例示に過ぎず、本発明を制限する意図はない。
【１１１８】
【数１０２】
2004272928.tif 000151
以下の表は、上記擬似コードの説明において言及した複数の入力のための源及び説明である。
【１１１９】        入力          源
テクスチャ適用サブモード（プリン／ｓｇｉ）  材料キャッシュ
バンプテクセル                              入力パケット
法線単位                                    入力パケット
法線大きさ                                  入力パケット
接線、従法線ベクトル                        入力パケット
光・テクスチャ計算
図Ｇ４１を参照する。「光・テクスチャ計算」１４１３４は、フラグメントの光特性を、テクスチャ・光値１４１２０（即ち、テクセル）として供給される新しい値で置換する。もしテクスチャ・光値が供給されなければ、「光・テクスチャ計算」１４１３４は、そのフラグメントの光キャッシュポインタによって識別される光キャッシュエントリからの材料値を用いて、そのフラグメントを表示する。
【１１２０】  もしテクスチャ・光値１４１２０が送られれば、「テクスチャ・光計算」は、テクスチャ適用サブモードパラメータ（放出、周囲、拡散、鏡面、または周囲・及び・拡散の何れか）によって識別される光特性をテクスチャ・光値で置換する。得られた新しい光値１４１３６は、「フラグメントライティング計算」１４１３８へ送られる。
【１１２１】  以下の資料から付加的な背景情報を入手できるので参照されたい。
ＧＬ  １．１  ｓｐｅｃ  Ｓｅｃｔｉｏｎ  ３．８
ＳＧＩＸ＿ｌｉｇｈｔ＿ｔｅｘｔｕｒｅ、
これらの資料は、ＳＧＩバンプマッピングを支援するためには、ＯｐｅｎＧＬ仕様への拡張が必要であることを述べている。
以下は、一般的には、プログラマ及びエンジニアその他のコンピュータプログラミングの分野に精通する者に、特定的には、コンピュータグラフィックスプログラミング及びプロセッサ設計に公知のＣ言語規約を使用して書かれた光・テクスチャ計算の一実施の形態の擬似コード記述である。この記述は例示に過ぎず、本発明を制限する意図はない。
【１１２２】
【数１０３】
2004272928.tif 000152
以下の表は、上記擬似コードの説明において言及した複数の入力のための源である。
【１１２３】        入力          源
現在の光値                      光キャッシュ
テクスチャ適用モード            材料キャッシュ
テクスチャ適用サブモード        材料キャッシュ
光テクスチャ値                  入力パケット
フラグメント・光計算
フラグメント・光計算は、頂点毎のライティングを遂行するためにジオメトリブロックにおいて使用される方法と実質的に類似する手法で、背景において説明したライティング方程式を実現する。従来技術及びフラグメントライティング計算と共通の付加的な詳細は、本明細書の背景節を参照されたい。
【１１２４】  図Ｇ４１を参照する。「フラグメントライティング」１４１３８への入力は、「材料選択」１１４１２６からの選択された材料１４１２８、「バンプ」１４１３０からの動揺した法線（または、もしバンプマッピングが遂行されなければ、「フラグメント」１１０００から通過してきたフラグメントパケット内の法線）、及び「光・テクスチャ」１４１３４からの選択されたテクスチャ１４１３６を含んでいる。「フラグメントライティング」１４１３８は、この異種の情報をライティング方程式に従って組合わせ、ピクセルカラー１４１４０を生成する。これが、「光・環境計算」１４１４２への出力である。
【１１２５】  以下の資料から付加的な背景情報を入手できるので参照されたい。
ＧＬ  １．１  ｓｐｅｃ  Ｓｅｃｔｉｏｎ  ３．８
ＳＧＩＸ＿ｆｒａｇｍｅｎｔ＿ｌｉｇｈｔｉｎｇ
これらの資料は、ＳＧＩバンプマッピングを支援するためには、ＯｐｅｎＧＬ仕様への拡張が必要であることを述べている。
以下は、一般的には、プログラマ及びエンジニアその他のコンピュータプログラミングの分野に精通する者に、特定的には、コンピュータグラフィックスプログラミング及びプロセッサ設計に公知のＣ言語規約を使用して書かれたフラグメントライティング計算の一実施の形態の擬似コード記述である。この擬似コード例は、以下のライティング計算を実施するコード内に使用されるパラメータを定義するコメントから開始される。この記述は例示に過ぎず、本発明を制限する意図はない。
【１１２６】
【数１０４】
2004272928.tif 000153
【数１０５】
2004272928.tif 000154
【数１０６】
2004272928.tif 000155
以下の表は、上記擬似コードの説明において言及した複数の入力のための源及び説明である。
【１１２７】    入力                              源                説  明
フラグメントライティング可能化    光キャッシュ
フラグメントＸｅ、Ｙｅ、Ｚｅ      入力パケット          目空間座標
ローカルビューワ可能化            光キャッシュ
表面法線                          バンプ計算
グローバル光情報                  光キャッシュ          ビューワ位置等
光毎の情報                        光・テクスチャ計算
フラグメント材料情報              材料計算
光・環境計算
図Ｇ４１を参照する。「光・環境計算」１４１４２は、「フラグメントライティング」からのフラグメントカラー（Ｒｌ、Ｇｌ、Ｂｌ、Ａｌ）１４１４０と、「テクスチャ」１４１１４からのテクスチャ・カラー（Ｒｆ、Ｇｆ、Ｂｆ、Ａｆ）１４１１８とを受け、光・環境モードのセッティング（置換、変調、または加算の１つにセットすることができる）の現在値に従って、２つのカラーを混合する。
以下の資料から付加的な背景情報を入手できるので参照されたい。
ＧＬ  １．１  ｓｐｅｃ  Ｓｅｃｔｉｏｎ  ３．８
ＳＧＩＸ＿ｆｒａｇｍｅｎｔ＿ｌｉｇｈｔｉｎｇ
これらの資料は、ＳＧＩバンプマッピングを支援するためには、ＯｐｅｎＧＬ仕様への拡張が必要であることを述べている。
以下は、一般的には、プログラマ及びエンジニアその他のコンピュータプログラミングの分野に精通する者に、特定的には、コンピュータグラフィックスプログラミング及びプロセッサ設計に公知のＣ言語規約を使用して書かれた光・環境計算の一実施の形態の擬似コード記述である。この記述は例示に過ぎず、本発明を制限する意図はない。
【１１２８】
【数１０７】
2004272928.tif 000156
以下の表は、上記擬似コードの説明において言及した複数の入力のための源を示している。
【１１２９】        入力      源
光環境モード                  材料キャッシュ
テクスチャカラー              テクスチャ計算
フラグメントカラー            フラグメント光計算
置換Ｚ                        テクスチャ計算
フォグ計算
図Ｇ４１を参照する。「フォグ計算」１４１４６は、「光・環境計算」１４１４２から混合されたカラー１４１４４を受け、最終ピクセルカラー１４１４８をピクセルブロック１５０００へ出力する。フォグ計算は、光キャッシュ１４１５４からのフォグモード（ｆｏｇＭｏｄｅ）の現在値、及び関連フォグパラメータ１及び２（ｆｏｇＰａｒｍ１、ｆｏｇＰａｒｍ２）、及びフォグカラー（ｆｏｇＣｏｌｏｒ）を使用する。フォグ計算には目座標が必要であるが、それらはハーフレートフラグメントパケット１１９０２（図Ｇ４０）でしか供給されないから、フォグ計算はハーフレートモードにおいてだけ遂行できることに注目されたい。
【１１３０】  「フォグ計算」は、ビューワの目からフラグメントまでの距離、及びフォグモードだけに依存する計算を使用してフラグメントカラー１４１４４を変更する。特定の実施の形態では、フォグモードは、指数、自乗指数、及び線形を含む。この実施の形態では、「フォグ計算」１４１４６は、ビューワの目からフラグメントまでの距離の指数、自乗指数、または一次関数の何れかであるフォグファクタを決定する。前述したように（フォングブロックパラメータの説明参照）、フォグパラメータ１及び２は、フォグモードに依存して変化するフォグ計算の面を定義する。例えば、もしモードが指数であれば、パラメータ１はフォグ密度であり、パラメータ２は使用されない。もし自乗指数であれば、パラメータ１はフォグ密度の自乗であり、パラメータ２は使用されない。もし一次であれば、パラメータ１は終わり／（終わり・開始）であり、パラメータ２は１／（終わり・開始）である。
【１１３１】  「フォグ計算」１４１４６は、計算されたファクタを使用して、光キャッシュ１４１５４からのフォグカラーと「光環境」１４１４２からのカラー１４１４４とを混合する。
付加的な背景情報がＧＬ  １．１  ｓｐｅｃ  Ｓｅｃｔｉｏｎ  ３．９から入手できるので参照されたい。
以下は、一般的には、プログラマ及びエンジニアその他のコンピュータプログラミングの分野に精通する者に、特定的には、コンピュータグラフィックスプログラミング及びプロセッサ設計に公知のＣ言語規約を使用して書かれたフォグ計算１４１４６の一実施の形態の擬似コード記述である。先行擬似コード記述と同様に、この例は、明確にするためのコメント、ノート、及び実際の擬似コードを含んでいる。
【１１３２】
【数１０８】
2004272928.tif 000157
以下の表は、上記擬似コードの説明において言及した複数の入力のための源及び説明である。
【１１３３】        入力      源
フラグメントカラー              光環境計算
フォグモード                    光キャッシュ
フォグ開始、終わり、密度        光キャッシュ
フォグカラー                    光キャッシュ
カラーインデックスモード        光キャッシュ
例外
フラグメントライティングは、型“カラー”のパラメータが、指定された時に０−１．０の範囲にクランプされることが頂点ライティングとは異なる。これはオーバーフローシナリオを制限する。ライティング方程式を記述しているＧＬ仕様の２．１３節に記載されているように、内積（ドット積）は０にクランプしなければならない。オーバーフローは以下の場合に解析しなければならない。
指数化
全ての場合に、１．０より小さい（典型的には、正規化されたベクトルの内積）ある値をべき乗するので、指数化がオーバーフローをもたらすことはない。
表面法線ベクトルの再正規化
ベクトルを任意値、例えば（０，０，１）にセットせよ。このベクトルの０は異常ケースである。「フラグメント」は、入力のために正規化された値を供給し、「バンプ」において適用される変換は法線に対して直角な面内の回転、またはオフセットの何れかからなる。ユーザが基底ベクトルを無分別に（即ち、実際には愚かに）選択することによって、反転した法線、または０法線さえも作成する可能性がある。困ったことである。
フラグメントから目までのベクトルの再正規化
ベクトルを（０，０，１）にセットせよ。ビューイング円錐台から目位置が排除されるので、多分不可能である。上記の値は合理的なフェールセーフである。
フラグメントから光までのベクトルの再正規化
ベクトルを（０，０，０）にセットせよ。このケースは実際に発生する可能性はあるが、単一のフラグメントに制限されよう。直接隣接するフラグメントの場合、このベクトルは表面内にあり、従って法線を有するその内積は０になろう。このベクトルを（０，０，０）にセットすることは、このフラグメントにとって同じ結果を生じさせ、ライティングの不連続を回避する。
半角ベクトルの再正規化
ベクトルを（１，０，０）にセットせよ。このケースは、もし光ベクトルが目ベクトルに平行であれば発生する可能性がある。この場合、半角ベクトルは目ベクトルに対して直角な面内にあることだけが決定され、（１，０，０）は幾分かは良好である。
【１１３４】
【表２４】
2004272928.tif 000158
【１１３５】
【表２５】
2004272928.tif 000159
【１１３６】
【表２６】
2004272928.tif 000160
【１１３７】
【表２７】
2004272928.tif 000161
【１１３８】
【表２８】
2004272928.tif 000162
【１１３９】
【表２９】
2004272928.tif 000163
【１１４０】
【表３０】
2004272928.tif 000164
【１１４１】
【表３１】
2004272928.tif 000165
【１１４２】
【表３２】
2004272928.tif 000166
【１１４３】
【表３３】
2004272928.tif 000167
【１１４４】
【表３４】
2004272928.tif 000168
【１１４５】
【表３５】
2004272928.tif 000169
【１１４６】ＸＩ．バックエンド機能ブロック（ＢＫＥ）の詳細な説明
機能の概要
用語
以下の用語は、本説明を理解するのを容易にするために、説明の前に定義しておくものである。
【１１４７】  ピクセルオーナーシップ（ＰＯボックス）は、スクリーン上の所与のピクセルのために、それが属しているウィンドウＩＤを決定するサブユニットである。このメカニズムを使用して、スキャンアウトはそのピクセルに関連するオーバレイウィンドウが存在するか否かを決定し、３Ｄタイル書込みはそのピクセルのための書込み許可を調べる。
【１１４８】  ＢＫＥバスは、ＢＫＥをＴＤＧ、ＣＦＤ、及びＡＧＩにインタフェースする相互接続である。このバスは、フレームバッファメモリ及びＢＫＥレジスタを読出し、それらへ書込むために使用される。
【１１４９】  フレームバッファ（ＦＢ）は、ＢＫＥによって制御されるメモリであって、２Ｄ及び３Ｄウィンドウに関連する全てのカラー及び深さ値を保持する。これは、リフレッシュレートでピクセルカラーをスキャンアウトすることによってモニタ上に表示されるスクリーンバッファを含む。また、これは、オフスクリーンオーバレイ及びｐバッファをも保持し、リスト及び頂点アレイ、及び累積バッファを表示する。スクリーンバッファ及び３Ｄｐバッファは二重緩衝できる。
主機能
図６６は、バックエンドを、それへインタフェースするユニットと共に示す。図示のように、ＢＫＥは、主として、３Ｄタイルを読出し、書込むためにピクセルユニットと、及びＢｌｉｔ操作を遂行するために２Ｄグラフィックスエンジン１８０００（図１５）と対話する。ＣＦＤユニットは、フレームバッファからディスプレイリストを読出すためにＢＫＥバスを使用する。ＡＧＩユニット１１０４は、ＢＫＥレジスタ及びメモリマップされたフレームバッファデータを読出し、書込む。
【１１５０】  主バックエンド機能は、以下の通りである。
・  ３Ｄタイル読出し、
・  ピクセルオーナーシップを使用しての３Ｄタイル書込み、
・  書込みを可能にするためのピクセルオーナーシップ、及びオーバーレイ検出、
・  ピクセルオーナーシップを使用してのスキャンアウト、
・  固定比ズーム、
・  ３Ｄ累積バッファ、
・  フレームバッファ読出し及び書込み、
・  ｗｉｎｉｄマップへのカラーキー、
・  ＶＧＡ、
・  ＲＡＭＤＡＣ。
３Ｄタイル読出し
ＢＫＥは、先取りされたタイル開始コマンドをＰＩＸから受ける。これらのパケットはＳＲＴから発し、タイルバッファの内容を読出すのに必要な待ち時間を与えるために、全ての３Ｄユニットをバイパスする。同じようにＰＩＸから早めに受けられた開始フレームコマンドによって、３Ｄウィンドウ特色が初期化される。これらの特色は、カラー及び深さ表面のためのアドレス、面（アルファ、ステンシル、Ａ、及びＢバッファ）、ウィンドウ幅、高さ、及びストライド、カラーフォーマット等のための可能化ビットを含む。
【１１５１】  ピクセルアドレスは、ウィンドウパラメータを使用して計算される。タイルジオメトリの長所を利用し、単一のメモリ読出し要求を用いて１６ピクセルが取出される。
ピクセルオーナーシップは、３Ｄタイル読出しには関わらない。もしウィンドウが主スクリーン内にあれば、オーナーシップ（どのウィンドウが最上部にあるか）は書込みプロセス中に決定される。
ピクセルは、縮小された精密カラーの場合は２４ビットカラーへ拡張されないが、３２ビットピクセルワードにアンパックされる。深さ値は、もし必要ならば、分離したバッファ内へ読出される。
【１１５２】  開始タイルコマンドは、クリア動作が適用されることが多いので、タイル読出しを必要としないことを指示することができる。それでも、タイルバッファが割当てられ、タイル書込みのためのピクセルオーナーシップは始動する。
３Ｄタイル書込み
３Ｄタイル書込みは、３Ｄタイル読出しが終了すると直ちに始動する。この待ち時間は、ピクセルオーナーシップ書込み可能化を決定するために使用される。タイル始動メモリアドレスは、３Ｄタイル読出しプロセス中に既に計算されている。書込み可能化は、Ｒａｍｂｕｓメモリベースフレームバッファのための書込みマスクとして使用される。カラーは、フレームバッファ内へ書込まれる前に、カラー深さパラメータによって指定されているようにパックされる。
ピクセルオーナーシップ
ピクセルオーナーシップは、共用スクリーンへの書込み可能化を決定し、スキャンアウト読出しのためのオーバレイウィンドウを識別する。
【１１５３】  ピクセルオーナーシップブロックは、１６のバウンディングボックス（文字枠）、並びに８ビットウィンドウｉｄを有するピクセル毎のウィンドウｉｄマップを含んでいる。これらのウィンドウｉｄは、６４のウィンドウを記述する表を指し示す。バウンディングボックス及びｗｉｎｉｄマップメカニズムのための分離した可能化ビットは、同時使用を許容する。どのメカニズムを最初に適用するかを決定するために、制御ビットが使用される。
【１１５４】  ピクセルオーナーシップは、スクリーンｘ及びｙピクセル座標を使用する。各バウンディングボックスは、そのウィンドウ内に含まれる最大及び最小ピクセル座標を指定する。バウンディングボックスは、トップウィンドウが最後の可能化されたバウンディングボックスによって指定されるように順序付けられている。バウンディングボックスは、方形ウィンドウのセットアップを容易にする。これらは主として３Ｄウィンドウのために意図されているが、少数の２Ｄウィンドウが使用される場合には、このメカニズムを使用して２Ｄウィンドウをクリップすることもできる。
【１１５５】  任意の形状にされた多数のウィンドウの場合には、より多くのメモリ集中メカニズムが使用される。オプションとして、所与のスクリーンピクセルが属しているウィンドウを識別するために、ピクセル毎の８ビットウィンドウｉｄマップが維持されている。
書込みの場合、もしそのタイルのウィンドウｉｄがピクセルオーナーシップによって入手されたピクセルｉｄと一致すれば、ピクセル書込みが可能化される。スキャンアウトの場合、スクリーンからオーバレイへの移行及び戻りは、ピクセルオーナーシップウィンドウｉｄと現在のスキャンアウトウィンドウｉｄとを比較することによって検出される。
【１１５６】  ピクセルオーナーシッププロセスを加速させるために、１６ピクセルチェックを遂行することによってピクセル毎のチェックを回避することが多い。整列した水平１６ピクセルストリップの場合、全てが同じウィンドウｉｄを共用し、これは１動作で決定することができる。
スキャンアウト
スキャンアウトは、フレームバッファカラーを読出し、表示のためにデータをＲＡＭＤＡＣへ送る。スキャンアウトは、フレームバッファ上での最高順位動作である。スキャンアウトされるピクセルは、仮想Ｂｌｉｔ、オーバレイ等を行うために読出しピクセルオーナーシップブロックを通過する。オーバレイの処理に、及び水平消去期間の利用に含まれる不規則待ち時間を滑らかにするために、ＲＡＭＤＡＣへの入力として比較的大きい待ち行列が使用される。
【１１５７】  パレット及びガンマ補正は、ＲＡＭＤＡＣによって遂行される。固定比ズームアウト機能は、スキャンアウト中にバックエンドによって遂行される。
スキャンアウトは、１６００×１２００スクリーンの場合、縮小３Ｄパフォーマンスを用いて１２０Ｈｚリフレッシュレートを達成できなければならない。フル３Ｄパフォーマンスにおいては、最低でも７５Ｈｚのリフレッシュレートが必要である。主スクリーン上の全てのウィンドウは、同一のピクセルカラーフォーマットを共用する。支援されるカラーフォーマットは、
・  ３２ビットＲＧＢＡ（８−８−８−８）、
・  ２４ビットＲＧＢ（８−８−８）、
・  １６ビットＲＧＢ（５−６−５）、
・  ８ビットカラーインデックス、
である。
【１１５８】  スキャンアウトは、常に２４ビットをスキャンアウト待ち行列（ＳＯＱ）内へ書込む。８及び１６ビットカラーの場合は、下位ビットはクリアされる。ピクセル毎のカラーフォーマットを指示するために、付加的な２ビットが使用される。
若干のステレオデバイスの場合には、インタレースされたスキャンアウトも支援される。
実時間３Ｄアプリケーションは、小さいウィンドウを描き、小さいイメージを大きいウィンドウまでズーミングすることによって、描写をスピードアップする必要がある。双一次補間を用いるこのズーミングは、ピクセルがスキャンアウトされるかのように遂行される。
ＢＫＥは、各方向における基準化のための若干の固定比１６／ｎ（ｎ＝１・・・１５）を支援する。サンプル点及び補間係数は、ズーム動作の前にソフトウェアによってダウンロードされる。
【１１５９】  同一固定比（同一係数）を使用して、４つまでのウィンドウをズームアウトすることができる。スキャンアウトされたピクセルについてズームバウンディングボックスが比較され、それらのピクセルをズーム機能出力から取る必要があるか否かが決定される。ズームロジックは、係数表インデックスを順番付けることができるように連続的に動作する。従って、ズーム出力は、もしスキャンアウトのウィンドウｉｄがズームボックスのウィンドウｉｄと一致しなければ、無視される。
【１１６０】  ウィンドウズームボックスには、重畳は許されない。
３Ｄ累積バッファ
ＢＫＥは、６４ビット（１６ビット／カラー）累積バッファを支援する。累積コマンドは、フレーム間のトゥイーン（ｔｗｅｅｎ）パケットとして受けられる。これらは、３Ｄタイルカラー、累積バッファカラー、及び即値を用いる乗算及び加算機能を遂行する。結果は、累積バッファまたは３Ｄタイルの何れかへ書込まれる。
シザー試験が可能化されている場合には、現シザーボックス内のピクセルだけが累積動作によって更新される。それ以外の場合には、ウィンドウ内の全てのピクセルが更新される。
【１１６１】  ピクセルが３Ｄタイル内へ書き戻される場合には、シザー試験の他に、ディザリング及びカラーマスキングも適用される。累積バッファは、カラーインデックスモードのためには使用されない。
フレームバッファ読出し及び書込み
ＢＫＥは、全ての内部サブユニット及び外部ユニットのための読出し、及び書込みインタフェースを提供する。ＡＧＩ、ＣＦＤ、及びＴＤＧは、ＢＫＥバスを使用してフレームバッファ読出し及び書込み要求を行う。ＢＫＥは、これらのユニットからのバス要求を調停する。
【１１６２】  内部サブユニットは、フレームバッファへのアクセス、３Ｄタイル読出し、３Ｄタイル書込み、累積バッファ読出し及び書込み、ピクセルオーナーシップｗｉｎｉｄマップ読出し、スキャンアウトスクリーン及びオーバレイ読出し、ズームウィンドウ読出し、及びカラーキーｗｉｎｉｄマップ書込みのためにＭｅｍバスを使用する（これらは全て、フレームバッファにアクセスするためにＭｅｍバスを使用する）。
【１１６３】  フレームバッファに対するパフォーマンス要求を支援するために、合計３．２Ｇバイト／秒の帯域幅能力を有する２つのＲａｍｂｕｓメモリが使用されている。スキャンアウト及びズーム読出しは、最高順位を有している。
カラーキーウィンドウＩＤマップ書込み
ウィンドウのカラーキー機能は、ウィンドウｉｄマップを介してＢＫＥによって与えられる。特別なカラーキーを有するピクセルは、適切なウィンドウ（ｋｅｙ＿ｉｄ＿ｏｎ）を有するウィンドウを指し示すそれらの対応ウィンドウｉｄマップセットを有している。ウィンドウｉｄ  ｋｅｙ＿ｉｄ＿ｏｎ事件（ｈａｐｐｅｎｓ）を用いて書込む時に、カラーキー付けされたピクセルだけが置換される。
【１１６４】  ＢＫＥは、ソフトウェアが、カラーキーのためのウィンドウｉｄマップを作成するのに使用ことができる特別な特色を含んでいる。あるピクセルのためのｗｉｎｉｄは、カラーバッファ書込みが特別なウィンドウ内に発生し、カラーがある範囲内にある時に書込むことができる。
ＲＡＭＤＡＣ
ＲＡＭＤＡＣは、ディジタルカラー値をアナログ信号に変換するために使用される。ソフトウェアプログラム可能なカラーパレットは、８ビットカラーインデックスを２４ビットＲＧＢ値に変換する。また、同じＲＡＭがルックアップベースガンマ補正を遂行するためにも使用される。ルックアップＲＡＭは、カラーの各成分に１つずつ、合計３つの２５６×１０ビットＳＲＡＭとして編成されている。
【１１６５】  ＲＡＭＤＡＣは３００ＭＨｚまで動作することができ、ピクセルクロックを生成する。ＲＡＭＤＡＣは、ＶＧＡコアから、またはスキャンアウト待ち行列からピクセルを受入れる。ＲＡＭＤＡ７７７Ｃは、ＳＥＩからコアとして入手できる。本明細書では、コアとのインタフェース、及びその機能に対する基本的要求だけを記述する。
ＶＧＡ
ＶＧＡコアは、ブート時間の間だけ、ウィンドウズＮＴの下で走るフルスクリーン互換性アプリケーションによって使用される。ＶＧＡコアは、レジスタ読出し及び書込みのためにＢＫＥバスと、フレームバッファ読出し及び書込みのためにＭｅｍＢｕｓを、そしてＶＧＡモードにおけるスキャンアウトのためにＲＡＭＤＡＣをインタフェースする。ＶＧＡユニットが不能化された時は、そのスキャンアウトは無視される。
【１１６６】  ＶＧＡコアは、Ａｌｐｉｎ  Ｓｙｓｔｅｍｓから入手できる。本明細書は、コアとのインタフェース、及びその機能に対する基本的要求だけを記述する。
ＢＫＥバス
ＣＦＤ記述で説明したように、バックエンド入力バス及びバックエンド出力バスが存在しており、これらを一緒にしてＢＫＥバスと呼ぶ。
ＢＫＥを通してメモリ読出し及び書込みを遂行する外部クライアントユニットは、ＡＧＩ、ＣＦＤ、及びＴＤＧである。図６７を参照されたい。
これらのユニットは、ＢＫＥバスのオーナーシップを入手するために、要求／認可プロトコルに従う。バスを認可されたクライアントは、ＢＫＥへパケットの読出し及び書込みを掲示することができ、ＢＫＥから読出したデータをサンプルすることができる。
【１１６７】  クライアントはそのＲｅｑ信号を表明することによって、ＢＫＥバスオーナーシップを請求する。ＢＫＥは、他の状態に対してこの要求を調停する。要求中のクライアントにオーナーシップが認可されると、ＢＫＥはＧｎｔ信号を表明する。現在のオーナーは、そのメモリアクセスが終了した後にＲｅｑを取り下げることによってオーナーシップを自発的に解放するか、またはＢＫＥからＲｌｓ（解放）信号を受信するまでオーナーシップを保持（パーク）することができる。クライアントは、通常はＲｌｓ信号を受信してから制限された時間内にオーナーシップを放棄すべきである。例えば、クライアントは最早新しい読出し／書込み要求を掲示すべきではない。もしペンディングの読出しがあれば、クライアントは、最後の読出しデータが戻され次第オーナーシップを解放すべきである。
ＸＩＩ．ジオメトリ機能ブロック（ＧＥＯ）の詳細な説明
多くのハードウェアレンダラーが開発されている。例えば、Ｄｅｅｒｉｎｇ  ｅｔ  ａｌ．，”Ｌｅｏ：Ａ  Ｓｙｓｔｅｍ  ｆｏｒ  Ｃｏｓｔ  Ｅｆｆｅｃｔｉｖｅ  ３Ｄ  Ｓｈａｄｅｄ  Ｇｒａｐｈｉｃｓ，”ＳＩＧＧＲＡＰＨ９３  Ｐｒｏｃｅｅｄｉｎｇｓ，１−６  Ａｕｇｕｓｔ  １９９３，Ｃｏｍｐｕｔｅｒ  Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｅｄｉｎｇｓ，Ａｎｎｕａｌ  Ｃｏｎｆｅｒｅｎｃｅ  Ｓｅｒｉｅｓ（ＡＣＭ  ＳＩＧＧＲＡＰＨ，１９９３，Ｓｏｆｔ−ｃｏｖｅｒ  ＩＳＢＮ  ０−２０１−５８８８９−７  ａｎｄ  ＣＤ−ＲＯＭ  ＩＳＢＮ  ０−２０１−５６９９７−３）（以下に、“ディアリングら引例”という）の特に１０１乃至１０８ページを参照されたい。ディアリングら引例は、“ほぼ全ての市販３Ｄグラフィックスアクセラレータがこの概念に適合するので、真に汎用”であると記述されている汎用３Ｄグラフィックスパイプライン（即ち、レンダラー、または描写システム）の図面を含んでいる。このパイプライン図は、図Ｈ６に再現されている（この図の隅を丸めたブロックは、典型的に機能またはプロセス動作を表しており、一方鋭い隅を持った矩形は、典型的に格納されたデータまたはメモリを表している）。
【１１６８】  これらのパイプライン図は描写のプロセスは示しているが、如何なる特定のハードウェアも記述していない。本明細書は、汎用３Ｄグラフィックスパイプラインの若干のステップを共用する新しいグラフィックスパイプラインを記述する。以下に、汎用グラフィックスパイプラインにおける各ステップを要約して説明する。（本明細書では多角形の処理を想定しているが、３Ｄジオメトリを記述するための他の方法に置換することができる。）説明を簡易化するために、記述する方法では、多角形の型として三角形を使用する。
【１１６９】  図Ｈ６に示すように、データ入力（ステップ６１２）後の汎用３Ｄグラフィックスパイプラインの浮動小数点集中機能内の最初のステップは、上述した変換ステップ（ステップ６１４）である。変換ステップは、“次の多角形を入手”も含む。
【１１７０】  第２のステップであるクリップ試験は、ビューボリューム（ある場合には、円錐台形状にされている）内に多角形が少なくとも部分的に含まれているか否かを見るために、多角形を調べる（ステップ６１６）。もし多角形がビューボリューム内に無ければ、それは破棄される。もし存在すれば、処理が続行される。
【１１７１】  第３のステップは面決定であり、視点から遠去かるように向いている多角形は破棄される（ステップ６１８）。一般的に、面決定は、閉じたボリュームであるオブジェクトに対してのみ適用される。
【１１７２】  第４のステップはライティング計算であり、一般的に、いろいろな型の複数光源を用いるグローシェーディング及び／またはマッピングのためのセットアップを含むが、フォングシェーディング、または１つまたは多くの他の選択のためにセットアップすることもできる（ステップ６２２）。
【１１７３】  第５のクリッピングステップは、ビューボリュームの外側の多角形の部分を削除する。何故ならば、この部分は視面の方形領域内に射影されないからである（ステップ６２４）。慣習的に、新しい各プリミティブ毎に、カラーテクスチャ座標を含む座標を作成しなければならない。多角形クリッピングは、計算的に高価である。
【１１７４】  透視分割である第６のステップは、視面上へのオブジェクトの射影の透視補正を行う（ステップ６２６）。この点において、多角形の頂点を表す点が、第７のステップ、即ちスクリーン空間変換ステップ（ステップ６２８）によってピクセル空間座標に変換される。
【１１７５】  第８のステップ（ステップ６３２）である増分レンダーセットアップは、エッジウォーキング及びスパン補間のために必要ないろいろな開始、終わり、及び増分値（例えば、ｘ、ｙ、及びｚ座標、ＲＧＢカラー、テクスチャマップ空間、ｕ及びｖ座標等）を計算する。
【１１７６】  描写集中機能内では、エッジウォーキング（ステップ６３４）は、先行して生成されたスパン（同一多角形内）からの値をインクリメントさせることによってディスプレイデバイスの各ラスターライン毎に水平スパンを増分的に生成し、それにより多角形の両エッジに沿って垂直に“歩く”。同様に、スパン補間（ステップ６３６）は、視点からのピクセルの距離を指示するｚ座標値を含むピクセル値を生成するために、あるスパンに沿って水平に“歩く”。最後に、ｚ試験及び／またはアルファ混合（試験及び混合ともいう）（ステップ６３８）は、最終ピクセルカラー値を生成する。ピクセル値はカラー値をも含み、カラー値は簡単なグローシェーディング（即ち、頂点・カラー値の補間）によって、またはテクスチャマッピング（多分、一緒に混合された複数のテクスチャマップを使用する）、フォングシェーディング（即ち、フラグメント毎のライティング）、及び／またはバンプマッピング（補間された表面法線を動揺させる）のような計算的に高価な技術によって生成させることができる。
【１１７７】  描写集中機能が終了した後に、二重緩衝マルチプレクサ（ＭＵＸ）出力ルックアップ表操作が遂行される（ステップ６４４）。汎用３Ｄグラフィックスパイプラインは、二重緩衝フレームバッファを含んでおり、従って二重緩衝マルチプレクサも含まれている。カラー・マップ値を変換するために出力ルックアップ表が含まれている。
生成されたｚ座標値と、Ｚバッファ内に格納されている対応する値とを比較することによって、Ｚ試験は、新しいピクセル値をフレームバッファ内へ書込むことによってそれを保持するか（もし、それが先に格納されたそのピクセル位置のための値よりも視点に近ければ）、または新しいピクセル値を破棄する（もし、それが遠ければ）の何れかである。
このステップにおいて、エイリアス除去方法は、新しいピクセルカラーと古いピクセルカラーとを混合することができる。ｚ緩衝された混合は、一般的に、以下に説明するフラグメント毎の操作の殆どを含む。
最後に、ディジタル・アナログ変換によってディスプレイデバイスへの入力のためのアナログ信号が作られる。
今度は、本発明の特定の面を説明する。
【１１７８】  以下に、３Ｄグラフィックスイメージを描写するための装置及び方法を説明する。一実施の形態では、装置は、グラフィックスアプリケーションからコマンドを受けるためのポート、描写したイメージをディスプレイへ送るための出力、及びポートと出力とに結合され、変換を遂行するためのブロックを含むジオメトリ操作パイプラインを含んでいる。一実施の形態では、変換を遂行するためのブロックは、同延の論理及び第１の物理ステージ、並びに複数の論理ステージを含む第２の物理ステージを含んでいる。第２の物理ステージは、それらの実行をインタリーブする複数の論理ステージを含んでいる。
略語
以下は、説明に現れる略語、及びそれらの拡張された意味である。
【１１７９】  ＢＫＥ：バックエンドブロック８４Ｃ、
ＣＦＤ：コマンド取り出し及びデコードブロック８４１、
ＣＵＬ：選別（ｃｕｌｌ）ブロック８４６、
ＧＥＯ：ジオメトリブロック８４２、
ＭＥＸ：モード抽出ブロック８４３、
ＭＩＪ：モード注入ブロック８４７、
ＰＨＧ：フォングブロック８４Ａ、
ＰＩＸ：ピクセルブロック８４Ｂ、
ＰＸＯ：ピクセルアウトブロック２８０、
ＳＲＴ：分類ブロック８４４、
ＴＥＸ：テクスチャブロック８４９、
ＶＳＰ：可視スタンプ部分。
概要
描写システム
図Ｈ８は、三次元グラフィックスイメージを描写するためのシステム８００を示している。描写システム８００は、データ処理ユニット（ＣＰＵ）８１０、メモリ８２０、ユーザインタフェース８３０、グラフィックスプロセッサのような双対プロセッサ８４０、通信インタフェース８５０、及び通信バス８６０の各々を１つまたはそれ以上含んでいる。
【１１８０】  勿論、組込みシステムでは、組込みシステムの分野において公知のように、これらの成分の若干は省略される。分散型計算環境では、これらの成分の若干は、分散型計算の分野において公知のように、分離した物理マシン上にあることができる。
【１１８１】  メモリ８２０は、典型的には、高速揮発性ランダムアクセスメモリ（ＲＡＭ）、並びに読出し専用メモリ（ＲＯＭ）及び磁気ディスクドライブのような不揮発性メモリを含む。更に、メモリ８２０は、ソフトウェア８２１を含んでいる。ソフトウェア８２１は、オペレーティングシステム８２１２と通信するアプリケーションソフトウェア８２１１、及びＩ／Ｏサブシステム８２１３と通信するオペレーティングシステム８２１２の層にされている。Ｉ／Ｏサブシステム８２１３は、通信バス８６０によって、ユーザインタフェース８３０、双対プロセッサ８４０、及び通信インタフェース８５０と通信する。
ユーザインタフェース８３０は、ディスプレイモニタ８３１を含んでいる。
通信バス８６０は、ＣＰＵ８１０、メモリ８２０、ユーザインタフェース８３０、グラフィックスプロセッサ８４０、及び通信インタフェース８５０を通信的に相互接続する。
前述したように、米国特許第４，９９６，６６６号には、例えばグラフィックスユニットのメモリ部分を実現するために、本発明内に使用できるＳＡＭが記載されている。
双対プロセッサ８４０のアドレス空間は重畳させることができ、またメモリマッピングの分野においては公知のように、メモリ８２０のアドレス空間に接近させ、及び／または該アドレス空間から切り離すことができる。例えば、もしＣＰＵ８４０が所定のアドレスにおける加速されたグラフィックスポートへ書込み、グラフィックス双対プロセッサ８４０が同一の所定アドレスを読出すものとすれば、ＣＰＵ８１０はグラフィックスポートへ書込みつつあり、グラフィックスプロセッサ８４０はこのようなグラフィックスポートから読出しつつあると言うことができる。
【１１８２】  グラフィックスプロセッサ８４０は、グラフィックスパイプラインとして実現され、このパイプライン自体は多分１つまたはそれ以上のパイプラインを含む。図Ｈ３は、本発明を組み込んだ３Ｄグラフィックスパイプライン８４０内の成分及びデータの流れを示す高レベルブロック図である。３Ｄグラフィックスパイプライン８４０は、コマンド取り出し及びデコードブロック８４１、ジオメトリブロック８４２、モード抽出ブロック８４３、分類ブロック８４４、セットアップブロック８４５、選別ブロック８４６、モード注入ブロック８４７、フラグメントブロック８４８、テクスチャブロック８４９、フォングブロック８４Ａ、ピクセルブロック８４Ｂ、バックエンドブロック８４Ｃ、及び分類、多角形、テクスチャ、及びフレームバッファメモリ８４Ｄ、８４Ｅ、８４Ｆ、８４Ｇを含んでいる。メモリ８４Ｄ、８４Ｅ、８４Ｆ、８４Ｇは、メモリ８２０の一部であることができる。
【１１８３】  コマンド取り出し及びデコードブロック８４１は、グラフィックスポートを通してのホストコンピュータとの通信を処理する。このブロック８４１は、その入力を一連のパケットに変換してメモリブロック８４２へ渡す。殆どの入力ストリームは、ジオメトリカルデータ、即ち線、点、及び多角形を記述する頂点からなる。これらのジオメトリカルオブジェクトの記述は、カラー、表面法線、テクスチャ座標等々を含むことができる。入力ストリームは、ライティング、混合モード、及びバッファ機能のような描写機能をも含む。
【１１８４】  ジオメトリブロック８４２は、４つの主要タスク、即ち、変換、全ての多角形の三角形への分解、クリッピング、及びグローシェーディングのための頂点毎のライティング計算を処理する。ブロック８４２は、従法線及び接線を含むテクスチャ座標をも生成することが好ましい。
【１１８５】  ジオメトリブロック８４２は、到来するグラフィックスプリミティブを均一座標空間（“ワールド空間”）へ変換する。次いでブロック８４２は、プリミティブをビューイングボリューム（“円錐台”）にクリップする。ビューイングボリュームを定義する６つの面（左、右、上、下、前、及び後）に加えて、サブシステムは６つのユーザ定義可能なクリッピング面を提供する。好ましくは、頂点カラーはクリッピングの前に計算する。従ってジオメトリブロック８４２は、クリッピングの前に、３つより多くの頂点を有する多角形を複数組の三角形に分割し、処理を簡易化する。
最後に、もしフレーム内にグローシェーディングが存在すれば、ジオメトリブロック８４２は、フラグメントブロック８４８がシェーディングを遂行するために使用する頂点カラーを計算する。
モード抽出ブロック８４３は、データストリームを２つの部分、即ち頂点及びその他の全てに分離する。頂点は分類ブロック８４４へ送られる。その他の全て（光、カラー、テクスチャ座標等）は、モード注入ブロック８４７によって検索できる多角形メモリ８４Ｅ内の場所に格納される。多角形メモリ８４Ｅは二重緩衝されているので、モード注入ブロック８４７が１つのフレームのためのデータを読出している間に、モード抽出ブロック８４３は次のフレームのためのデータを格納することができる。
【１１８６】  多角形メモリ内に格納されているモードデータは３つの主要カテゴリ、即ち、フレーム毎のデータ（例えば、ライティング）、プリミティブ毎のデータ（例えば、材料特性）、及び頂点毎のデータ（例えば、カラー）に分けられる。モード抽出及びモード注入ブロック８４３、８４７は、効率を最適化するために、これらのカテゴリを更に分割する。
【１１８７】  各頂点毎に、モード抽出ブロック８４３は、頂点データ及び多角形メモリ８４Ｅを指し示すポインタ（“カラーポインタ”）を含むパケットを分類ブロック８４４へ送る。パケットは、頂点がある点（ある線の端点、またはある三角形の隅）を表しているか否かを指示するフィールドをも含んでいる。頂点は、それらがパイプライン内へ送給された順序と厳格に同一の時間順番順序で送られる。頂点データは、クリッピングによって作られた頂点をも含んでいる。パケットは、現頂点が所与のプリミティブ内の最後の頂点を形成しているか否か、即ち、それがプリミティブを完了させるか否かをも指定する。三角形ストリップ（“ファン”）及び線ストリップ（“ループ”）の場合には、頂点は隣接するプリミティブの間で共用される。この場合、パケットは、各プリミティブ内の他の頂点をどのように識別するのかも指示する。
【１１８８】  分類ブロック８４４は、モード抽出ブロック８４３から頂点を受け、得られた点、線、及び三角形をタイルによって分類する。（タイルは、後述するデータ構造である。）二重緩衝分類メモリ８４Ｄにおいては、分類ブロック８４４は、グラフィックスプリミティブを表す頂点の１つのリスト、及び１組のタイル指示子リスト（フレーム内の各タイル毎に１つのリスト）を維持している。あるプリミティブを完了させる頂点を受けると、分類ブロック８４４はどのタイルにプリミティブが接触しているかを調べる。プリミティブが接触している各タイル毎に、分類ブロックはその頂点を指し示すポインタをそのタイルのタイルポインタリストに追加する。
【１１８９】  あるフレーム内の全てのジオメトリの分類を終了すると、分類ブロック８４４はデータをセットアップブロック８４５へ送る。各分類ブロック出力パケットは完了プリミティブを表す。分類ブロック８４４はその出力をタイル・バイ・タイル順序で、即ち、所与のタイルに接触している全てのプリミティブ、次いで次のタイルに接触している全てのプリミティブ、等々で送る。従って、分類ブロック８４４は、同じプリミティブを多数回（それが接触している各タイル毎に１回）送ることができる。
セットアップブロック８４５は、線及び三角形のための空間導関数を計算する。ブロック８４５は、１つのタイルの価値データ、１つのプリミティブを一時に処理する。ブロック８４５は、完了すると選別ブロック８４６へデータを送る。
またセットアップブロック８４５は、スティップルされた線を分離したラインセグメント（各々が方形領域）に分割し、タイル内の各プリミティブ毎の最小ｚ値を計算する。
セットアップブロック８４５からの各パケット出力は、１つのプリミティブ、即ち、三角形、線分、または点を表す。
【１１９０】  選別ブロック８４６は、１つのタイルの価値データを一時に受け、その処理を２つのステップ、即ちＳＡＭ選別及びサブピクセル選別に分割する。ＳＡＭ選別は、先に処理済みのジオメトリに完全に隠されるプリミティブを破棄する。サブピクセル選別は、残余の（部分的に、または完全に見える）プリミティブを取り、可視フラグメントを決定する。サブピクセル選別は、複数のフラグメントの１つのスタンプの価値（以下に、“可視スタンプ部分”という）を一時に出力する。（スタンプは、後述するデータ構造である。）
図Ｈ９は、選別ブロック８４６が、部分的に隠蔽された三角形から、どのようにしてフラグメントを発生するかを示している。選別ブロック８４６によって発生された可視スタンプ部分は、たとえ複数のプリミティブがそのスタンプに接触しているとしても、単一のプリミティブだけからのフラグメントを含む。従って、図の出力ＶＳＰは、グレーの三角形だけからのフラグメントを含む。白い三角形のチップによって形成されたフラグメントは、別のＶＳＰ内に送られ、２つのＶＳＰのカラーは後刻ピクセルブロック８４Ｂにおいて組合わされる。
【１１９１】  ＶＳＰ内の各ピクセルは、所与のフラグメントがピクセルのどの程度を覆っているかを決定するために、複数のサンプルに分割される。ピクセルブロック８４Ｂは、それがフラグメントを混合してそのピクセルの最終カラーを発生する時にこの情報を使用する。
【１１９２】  モード注入ブロック８４７は、多角形メモリ８４Ｅからブロックモード情報（カラー、材料特性等）を検索し、それを要求に応じて下流へ渡す。帯域幅を節約するために、個々の下流ブロックは、最近使用されたモード情報をキャッシュする。モード注入ブロック８４７は、どの情報が下流でキャッシュされたかを追跡し、必要な情報だけを送る。
フラグメントブロック８４８の主作業は、補間である。ブロック８４８は、グローシェーディングのためのカラー、フォングシェーディングのための表面法線、及びテクスチャマッピングのためのテクスチャ座標を補間する。また、もしバンプマップが使用中であれば、バンプマッピングアルゴリズムに使用するための表面接線をも補間する。
フラグメントブロック８４８は、重心（ｂａｒｙｃｅｎｔｒｉｃ）係数を使用して透視補正された補間を遂行し、また好ましくは、テクスチャレベルの詳細操作をも取扱う。
テクスチャブロック８４９は、テクスチャマップをピクセルフラグメントに適用する。テクスチャマップは、テクスチャメモリ８４Ｆ内に格納されている。上述した他のメモリ記憶装置とは異なり、テクスチャメモリ８４Ｆは単一緩衝されている。このメモリは、グラフィックスポートインタフェースを使用してメモリ８２０からロードされる。
【１１９３】  テクスチャは、ｍｉｐマップされている。即ち、各テクスチャは、異なる詳細レベルの一連のテクスチャマップからなっており、各マップは眼点から所与の距離におけるテクスチャの見掛けを表している。所与のピクセルフラグメントのためのテクスチャ値を再生するために、テキストブロック８４９は、テクスチャマップから三線形補間を遂行して正しい詳細レベルを近似する。テクスチャブロック８４９は、異方性補間のような他の補間方法をも遂行する。
【１１９４】  テクスチャブロック８４９は、補間済みのテクスチャ値（一般的には、ＲＧＢＡカラー値として）をフラグメント毎の基準でフォングブロック８４Ａへ供給する。バンプマップは、特別な種類のテクスチャマップを表す。バンプマップ内の各テクセルは、カラーの代わりに、高さフィールド勾配または法線ベクトルを含む。
【１１９５】  フォングブロック８４Ａは、各ピクセル毎にフォングシェーディングを遂行する。このブロックは、モード注入ブロック８４７によって供給された材料及びライティング情報、テクスチャブロック８４９からのテクスチャカラー、及びフラグメントブロック８４８によって生成された表面法線を使用して、そのフラグメントの見掛けのカラーを決定する。もしバンプマッピングが使用されていれば、フォングブロック８４７は、シェーディングの前にテクスチャブロック８４９からの補間済みの高さフィールド勾配を使用してそのフラグメントの表面法線を動揺させる。
【１１９６】  ピクセルブロック８４Ｂは、各フラグメントが独立カラー値を有しているＶＳＰを受ける。ピクセルブロック８４Ｂは、各ピクセル内の各サンプルに対してシザー試験、アルファ試験、ステンシル操作、深さ試験、混合、ディザリング、及び論理演算を遂行する。ピクセルブロック８４Ｂは、終了した複数のピクセルのあるタイルの価値を累積すると、各ピクセル内のサンプルを混合し（それによって、ピクセルのエイリアス除去を遂行し）、バックエンド８４Ｃへ送ってフレームバッファ８４Ｇ内へ記憶させる。
【１１９７】  図Ｈ１０は、ピクセルブロック８４Ｂが、どのように複数のフラグメントのあるスタンプの価値を処理するかを示している。この例では、ピクセルブロックは２つのＶＳＰを、即ちグレーの三角形からの１つと、白い三角形からの１つを受ける。ピクセルブロック８４Ｂは、フラグメントと背景カラーとを混合して最終ピクセルを発生する。ブロック８４Ｂは、それがピクセルのどの程度を覆っているかに従って、より正確に言えば、それが覆っているサンプルの数によって各フラグメントに重み付けする。
【１１９８】  （ピクセル・オーナーシップ試験は、ウィンドウシステムの一部であり、バックエンド８４Ｃに残されている。）
バックエンドブロック８４Ｃは、ピクセルブロック８４Ｂから、複数のピクセルのあるタイルの価値を一時に受け、それらをフレームバッファ８４Ｇ内へ格納する。またバックエンド８４Ｃは、複数のピクセルのタイルの価値をピクセルブロック８４Ｂへ送り返す（何故ならば、特定のフレームバッファ値は、フレームからフレームへ生き残ることができるからである）。例えば、ステンシルビット値は、多くのフレームにわたって一定に留まることができるが、これらの全てのフレームにおいて使用することができる。
【１１９９】  フレームバッファ８４Ｇを制御することに加えて、バックエンドブロック８４Ｃは、ピクセル・オーナーシップ試験、２Ｄ描写を遂行し、仕上がったフレームを出力デバイスへ送る。ブロック８４Ｃは、フレームバッファ８４Ｇとモニタ８３１及びビデオ出力との間のインタフェースを提供する。
【１２００】  ジオメトリブロック
ジオメトリブロック８４２は、グラフィックスパイプライン８４０のフロントエンドにおける最初の計算ユニットである。エンジン８４２は、主として、頂点座標及び法線の変換のような頂点毎の操作を扱う。フロントエンドは、グラフィックスハードウェアコマンドの取り出し及びデコーディングを扱う。フロントエンドは、必要な変換マトリックス、材料及び光パラメータ、及び他のモードセッティングを、ジオメトリブロック８４２の入力レジスタ内へロードする。ジオメトリブロック８４２は、変換した頂点座標、法線、生成した及び／または変換したテクスチャ座標、及び頂点毎のカラーを、モード抽出及び分類ブロック８４３、８４４へ送る。モード抽出ブロック８４３は、“カラー”データ及びモードを多角形メモリ８４Ｅ内に格納する。分類ブロック８４４は、頂点毎の“空間”データをタイルによって編成し、それを分類メモリ８４Ｄ内へ書込む。
【１２０１】  図Ｈ２は、ジオメトリブロック８４２内の成分及びデータの流れを示すブロック図である。ブロック８４２は、変換ユニット２１０，ライティングユニット２２０、及びクリッピングユニット２３０を含んでいる。変換ユニット２１０は、コマンド取り出し及びデコードブロック８４１からデータを受け、ライティング及びクリッピングユニット２２０、２３０へ出力する。ライティングユニット２２０は、クリッピングユニット２３０へ出力する。クリッピングユニット２３０は、モード抽出及び分類ユニット８４３、８４４へ出力する。
【１２０２】  図Ｈ４は、ジオメトリブロック８４２内の成分及びデータの流れを示すブロック図である。ユニット２１０は、グローバルパケットコントローラ２１１と、２つの物理的ステージ、即ちパイプラインステージＡ２１２及びパイプラインステージＢＣ２１３とを含む。グローバルパケットコントローラ２１１は、コマンド取り出し及びデコードブロック８４１及び補助リング（図示してない）からデータを受ける。ユニット２１２は、パイプラインステージＡへ出力する。パイプラインステージＡ２１２は、パイプラインステージＢＣ２１３へ出力する。ステージＢＣ２１３はライティング及びクリッピングユニット２２０、２３０へ出力する。
【１２０３】  図Ｈ１３は、クリッピングサブユニット２３０のブロック図である。ユニット２３０は、同期待ち行列２３１、クリッピング及びフォーマッティングサブユニット２３２、２３３、及び出力待ち行列２３４を含んでいる。同期待ち行列２３１は、変換及びライティングユニット２１０、２２０から入力を受け、クリッピングサブユニット２３２へ出力する。クリッピングサブユニット２３２自体はフォーマットサブユニット２３３へ出力し、フォーマットサブユニット２３３自体は出力待ち行列２３４へ出力する。待ち行列２３４は、モード抽出ブロック８４３へ出力する。
図Ｈ１３は、クリッピングサブユニット２３０がそれらを実現するものとしてパイプラインステージＫ乃至Ｎの概要をも示している。クリッピングサブユニット２３０は、３つの論理的パイプラインステージＫ、Ｌ、及びＭを含んでいる。フォーマットサブユニット２３４は、１つの論理的パイプラインステージＮを含む。
出力待ち行列２３４は、パイプラインステージ境界上では働かない。そうではなく、出力待ち行列２３４は、有効データがその待ち行列内にあり、モード抽出ブロック８４３が作動可能（レディ）であれば、パケットを送出する。
【１２０４】  図Ｈ５は、グローバルパケットコントローラ２１１のブロック図である。コントローラ２１１は、ＣＦＤインタフェース状態マシン２１１１、補助リングコントロール２１１２、補助リング標準レジスタノード２１１３、補助リングインタフェースバッファ２１１４、バッファ２１１５、２１１６、２１１７、及びマルチプレクサ２１１８、２１１９、２１１Ａを含んでいる。
【１２０５】  ＣＦＤインタフェース状態マシン２１１１は、コマンド取り出し及びデコードユニット８４１からＣＦＤコマンド及びデータバスを介しての入力と、補助リングコントローラ２１１２からのリング要求信号２１１Ｂと、データレディからの信号２１１Ｃ（信号２１１Ｃは、ＣＦＤとＧＥＯとの間のハンドシェーク信号である）と、パイプラインステージＫからのテクスチャ待ち行列アドレス信号２１１Ｄとを受ける。状態マシン２１１１は、マルチプレクサ２１１８への制御入力としての書込みアドレス及び書込み可能化信号２１１Ｅ、２１１Ｆ、並びに肯定応答（アクノリッジ）及びパケット／パイプライン前進信号２１１Ｇ、２１１Ｈを生成する。
【１２０６】  補助リングコントローラ２１１２は、入力としてノード２１１３からのリング要求信号２１１Ｌと、パイプラインステージＰからのコントロール２１１Ｋを受けている。コントローラ２１１２は、４つの信号、即ちマルチプレクサ２１１８への入力としてのリングコマンド２１１Ｍと、バッファ２１１４への入力としての無名信号２１１Ｎと、マルチプレクサ２１１９への入力としてのアドレス／データバス２１１０と、状態マシン２１１１への入力としてのリング要求信号２１１Ｂとを生成する。
補助リング標準レジスタノード１１３は、入力としてコマンド取り出し及びデコードユニット８４１からの補助リングバスと、コントローラ２１１２からのアドレス／データバス２１１０とを受ける。ノード２１１３は、２つの信号、即ちコントローラ２１１２へのリング要求信号２１１Ｌと、モード抽出ブロック８４３への補助リングバスとを生成する。
【１２０７】  補助リングインタフェースバッファ２１１４は、入力としてマルチプレクサ２１１９の出力と、コントローラ２１１２からの無名信号２１１Ｎとを受け、マルチプレクサ２１１Ａへの無名入力２１１Ｐを生成する。
２入力マルチプレクサ２１１８は、入力としてコマンド取り出し及びデコードコマンドバスからのコマンドバスと、コントローラ２１１２からのリングコマンド信号２１１Ｍとを受ける。マルチプレクサ２１１８の出力は、パイプラインステージＡコマンドレジスタへ送られる。
２入力マルチプレクサ２１１９は、入力としてパイプラインステージＰからのデータバスと、アドレス／データバス２１１０とを受ける。マルチプレクサ２１１９の出力は、バッファ２１１４への入力である。
２入力マルチプレクサ２１１Ａは、入力として無名信号２１１Ｐと、コマンド取り出し及びデコードブロック８４１からのデータバスとを受ける。マルチプレクサ２１１Ａの出力は、パイプラインステージＡ頂点バッファ２１２１への入力である。
【１２０８】  図Ｈ１１及び図Ｈ１２は、パイプラインステージＡ２１２のブロック図である。ステージＡ２１２は、入力バッファ２１２１、マトリックスメモリ２１２５、並行数学機能ユニット２１２２、及び複数のマルチプレクサ２１２４を含む命令コントローラ２１２６及びデータ経路要素を含んでいる。図Ｈ１１は、ステージＡ２１２データ経路要素を示しており、図Ｈ１２は、命令コントローラ２１２６を示している。
【１２０９】  頂点バッファＡ２１２１は、入力としてグローバルパケットコントローラマルチプレクサ２１１Ａの出力を受け、マルチプレクサ２１２４ｂ及び２１２４ｄを通して４つのＳｅｒＭｏｄ＿Ｆ３２直列内積ジェネレータ２１２２への出力２１２７を生成する。
また頂点バッファＡ２１２１は出力２１２６を生成し、これらの出力はマルチプレクサ２１２４ｅ、遅延要素２１２７、及びマルチプレクサ２１２４ｃを通してバス２１２５を形成している。バス２１２５は、頂点バッファＢＣ２１２３及びマトリックスメモリ２１２５をフィードする。
マトリックスメモリ２１２５は、入力としてマルチプレクサ２１２４ｃの出力２１２５を受け、出力として並行直列内積ジェネレータ２１２２のためのＡ入力を生成する。
直列内積ジェネレータ２１２２は、それらのＡ入力としてマトリックスメモリ２１２５の出力を、またそれらのＢ入力としてマルチプレクサ２１２４ｄの出力を受けている。生成されたプロダクトは、マルチプレクサ２１２４ｃへの入力である。
【１２１０】  頂点バッファＢＣ２１２３は、入力としてマルチプレクサ２１２４ｃからの出力２１２５を受け、２つの出力、即ちマルチプレクサ２１２４ｂへの入力、及びステージＢクロスバーへの出力を生成する。
頂点バッファ２１２１、２１２３は二重緩衝され、２つのフルパフォーマンス頂点価値のデータを保持するように十分に大きい。
３入力マルチプレクサ２１２４ｂは、入力としてステージＢからの無名信号、頂点バッファＢＣ２１２３からの出力、及び頂点バッファＡ２１２１からの出力２１２７を受ける。マルチプレクサ２１２４ｂの出力は、関連しているマルチプレクサ２１２４ｄへの入力である。
４入力マルチプレクサ２１２４ｄは各々、入力として４つのマルチプレクサ２１２４ｂの４つの出力を受けている。マルチプレクサ２１２４ｄの出力は、関連している直列内積ジェネレータ２１２２のＢ入力である。
【１２１１】  ２入力マルチプレクサ２１２４ｅは各々、入力として関連しているマルチプレクサ２１２４ｂの出力と、頂点バッファＡ２１２１の出力２１２６とを受けている。マルチプレクサ２１２４ｅの出力は、関連している遅延要素２１２７の入力である。
遅延要素２１２７の入力は、関連マルチプレクサ２１２４ｅの出力であり、要素２１２７の出力は、関連マルチプレクサ２１２４ｃの入力である。
２入力マルチプレクサ２１２４ｃの入力は、関連する直列内積ジェネレータ２１２２のＲ出力、及び関連する遅延要素２１２７の出力である。
図Ｈ１２に示すように、命令コントローラ２１２６は、ジオメトリコマンドワード（ＧＣＷ）コントローラ１２１０、デコーダ１２２０、ジャンプテーブルメモリ１２３０、ジャンプテーブル１２４０、マイクロコード命令メモリ１２５０、テクスチャ状態マシン１２６０、ハードウェア命令メモリ１２７０、書込み可能化メモリ１２８０、フィールド併合ロジック１２９０、及びコマンドレジスタ１２Ａ０を含む。
【１２１２】  図Ｈ１６は、パイプラインステージＢＣ２１３を示している。ステージＢＣ２１３は、頂点バッファＢＣ２１２３、スクラッチパッドメモリ２１３２、数学機能ユニット２１３３、並びに遅延要素２１３４、マルチプレクサ２１３５、及びレジスタ２１３６を含んでいる。
【１２１３】  図Ｈ１５は、同期待ち行列２３１及びクリッピングサブユニット２３２のブロック図である。図Ｈ１５は、空間、テクスチャ、及びカラーデータのための分離した頂点データ同期待ち行列２３１ａ、２３１ｂ、及び２３１ｃをそれぞれ示している。
【１２１４】  図Ｈ１５は、クリッピングサブユニット２３２を構成しているプリミティブ形成ヘッダー待ち行列２３２１、２３２３、２３２４も示している。サブユニット２３２は、スクラッチパッドＧＰＲ２３２２、機能数学ユニット２３２５、遅延要素２３２６、マルチプレクサ２３２７、及びレジスタ２３２８をも含んでいる。空間、テクスチャ、及びカラー待ち行列２３１ａ−ｃは、プリミティブ、テクスチャ、及びカラー待ち行列２３２１、２３２３、２３２４をそれぞれフィードする。（空間待ち行列２３１は、マルチプレクサ２３２７ｈを通してプリミティブ待ち行列２３２１をフィードする。）
プリミティブ待ち行列２３２１はマルチプレクサ２３２７ｈから入力を受け、第１の出力からマルチプレクサ２３２７ａ、２３２７ｄ及び２３２７ｅへ出力し、第２の出力からマルチプレクサ２３２７ｃ及び２３２７ｅへ出力する。
テキスト待ち行列は、マルチプレクサ２３２７ａ及び２３２７ｆへ出力する。
【１２１５】  カラー待ち行列２３２４は、マルチプレクサ２３２７ａ及び２３２７ｃへ出力する。
機能数学ユニット２３２５はそのＡ入力にマルチプレクサ２３２７ｄからの入力を受け、そのＢ入力にマルチプレクサ２３２７ｅからの入力を受け、そのＣ入力にマルチプレクサ２３２７ｂからの入力を受けている。出力Ｕ１及び△はそれぞれ、マルチプレクサ２３２７ｄ及び２３２７ｅをフィードする。出力Ｒは、マルチプレクサ２３２７ｇ、２３２７ｄ、２３２７ｅ、及びレジスタ２３２８を介して（再度）マルチプレクサ２３２７ｂ及び２３２７ｄをフィードする。
遅延要素２３２６は、入力としてマルチプレクサ２３２７ｂの出力を受け、マルチプレクサ２３２７ｇへの出力を生成する。
４入力マルチプレクサ２３２７ａは、プリミティブ、テクスチャ、及びカラーの各待ち行列２３２１、２３２３、２３２４から入力を受ける。マルチプレクサ２３２７ａは、マルチプレクサ３２７ｂ及び２３２７ｅへ出力する。
【１２１６】  ４入力マルチプレクサ２３２７ｂは、プリミティブ待ち行列２３２１、スクラッチパッドＧＰＲ２３２２、マルチプレクサ２３２７ａ、及びホールドレジスタ２３２８を通して機能数学ユニット２３２５のＲ出力から入力を受ける。マルチプレクサ２３２７ｂは、数学ユニット２３２５（のＣ入力）及び遅延要素２３２６への出力を生成する。
【１２１７】  ２入力マルチプレクサ２３２７ｃは、プリミティブ待ち行列２３２１の第２の出力、及びカラー待ち行列２３２４の出力を入力として受ける。マルチプレクサ２３２７ｃは、直接、及びホールドレジスタ２３２８を通してマルチプレクサ２３２７ｆへ出力する。
【１２１８】  ５入力マルチプレクサ２３２７ｄは、入力として数学ユニット２３２５のＲ出力を直接及びホールダ２３２８を通して受け、また数学ユニット２３２５のＵｔ出力、スクラッチパッド２３２２の出力、及びプリミティブ待ち行列２３２１の第１の出力を受けている。マルチプレクサ２３２７ｄは数学ユニット２３２５のＡ入力への出力を生成する。
【１２１９】  ５入力マルチプレクサ２３２７ｅは、入力として数学ユニット２３２５のＲ出力を直接及びホールド２３２８を通して受け、また数学ユニット２３２５の△出力、マルチプレクサ２３２７ａの出力、及びプリミティブ待ち行列２３２１の第２の出力を受けている。マルチプレクサ２３２７ｅは数学ユニット２３２５のＢ入力への出力を生成する。
【１２２０】  ２入力マルチプレクサ２３２７ｆは、入力としてマルチプレクサ２３２７ｃの出力を直接、及びホールドレジスタ２３２８を通して受け、またテクスチャ待ち行列２３２３の出力を受けている。マルチプレクサ２３２７ｅは、クリッピングサブユニット２３２とフォーマットサブユニット２３３との間の頂点バッファ２３２９への出力を生成する。
【１２２１】  ２入力マルチプレクサ２３２７ｇは、入力として数学ユニット２３２５のＲ出力と、遅延要素２３２６の出力とを受けている。マルチプレクサ２３２７ｇは、ホールドレジスタ２３２８を通してマルチプレクサ２３２７ｈ及びスクラッチパッドＧＰＲへの出力を生成する。
【１２２２】  ２入力マルチプレクサ２３２７ｈは、入力としてマルチプレクサ２３２７ｇの出力（ホールドレジスタ２３２８を通して）、及び空間待ち行列２３１ａの出力を受ける。マルチプレクサ２３２７ｈの出力は、プリミティブ待ち行列２３２１をフィードする。
数学ユニット２３２５は、ｍａｔｈＦｕｎｃ  Ｆ−３２内積ジェネレータである。
【１２２３】  図Ｈ１７は、パイプラインステージＢＣ２１３のための命令コントローラ１８００のブロック図である。命令コントローラ１８００は、コマンドレジスタ１８１０、グローバルコマンドワードコントローラ１８２０、デコーダ１８３０、ジャンプテーブルメモリ１８４０、ハードウェアジャンプテーブル１８５０、マイクロコード命令メモリ１８６０、ハードウェア命令メモリ１８７０、フィールド併合ロジック１８８０、及び書込み可能化メモリ１８９０を含む。
【１２２４】  図Ｈ１４は、テクスチャ状態マシンのブロック図である。
プロトコル
ジオメトリブロック８４２は、全ての空間変換及び射影、頂点ライティング、テクスチャ座標生成及び変換、表面接線計算（変換及びクロス乗積）、線スティップル・パターンラッピング、プリミティブ形成、多角形クリッピング、及びＺオフセットを遂行する。更にジオメトリブロック８４２は、変換マトリックス及び頂点ライティング係数の全てを格納する。ブロック８４２は、幾つかのユニット、即ち変換ユニット２１０、ライティングユニット２２０、及びクリッピングユニット２３０を含んでいる。
【１２２５】  １千万三角形／秒のレートの場合、時間頂点データの約９０％が処理のために使用でき、また頂点が三角形ストリップの形状であるものとすれば、ジオメトリブロック８４２は、約１／２０サイクルのレートで頂点を処理する。パターン＃＿８４０設計は、このレートにおける平均サイズの三角形のためのものであるから、残余のパイプライン８４０のパフォーマンスはジオメトリサイズに従って変動する。ジオメトリブロック８４２は、この平均レートよりも若干良好な最大レートを選択することによってこれを補償する。実質的に、待ち時間制約は存在しない。
【１２２６】  従って、ジオメトリブロック８４２は、各ステージ間が二重または三重に緩衝された一連の２０サイクルパイプラインステージである。上流パイプラインステージはバッファの一方の側に書込み、一方下流パイプラインステージは、先にバッファの一方の側に書込まれたデータを他方の側から読出す。
【１２２７】  頂点データの他に、ジオメトリブロック８４２は、状態情報をも受けている。ジオメトリブロック８４２は、この状態情報を消費することも、またはそれをグラフィックスパイプライン８４０内のそれより後のブロックへ伝えることもできる。状態変化はパイプライン８４０内のそれより前のデータには影響を及ぼさないから、ジオメトリブロック８４２はこれらの状態を、あたかも頂点データであるかの如く処理する。即ち、ブロック８４２は、状態を順序正しく通過させる。
【１２２８】  またジオメトリブロック８４２は、それ自体とモード抽出ブロック８４３とを接続しているデータバスを制御する。３２ビット幅のバスを使用すると、１千万三角形／秒の目標に必要な帯域幅より若干良好な帯域幅が得られる（３３３ＭＨｚにおいて）。
・変換ユニット
変換ユニット２１０はオブジェクト座標（Ｘ０、Ｙ０、Ｚ０、Ｗ０）を目座標（Ｘｅ、Ｙｅ、Ｚｅ、Ｗｅ）に変換するか、またはそれらをクリップ座標（Ｘｃ、Ｙｃ、Ｚｃ、Ｗｃ）に直接変換する。また変換ユニットは、ウィンドウ座標Ｘｗ、Ｙｗ、Ｚｗを計算し、更にスティップル繰り返しパターン計算を実施する。変換ユニット２１０は、ユーザが供給したテクスチャ座標（Ｓ０、Ｔ０、Ｒ０、Ｑ０）を目座標（Ｓｅ、Ｔｅ、Ｒｅ、Ｑｅ）に変換するか、またはもしアプリケーションによって要求されていれば、空間データからそれらを生成する。実効的に、これは目内の空間データ（ＥＹＥ＿ＬＩＮＥＡＲ）またはオブジェクト空間（ＯＢＪＥＣＴ＿ＬＩＮＥＡＲ）を、オブジェクト空間内のテクスチャ座標に変換する。変換ユニット２１０は、第３の型のテクスチャ生成メカニズムを提供し、即ち、（例えば、ＯｐｅｎＧＬまたは他の方法を使用して反射マッピングに使用するための）球の表面を表すテクスチャに好ましくアクセスするテクスチャ座標を生成する。
【１２２９】  変換ユニット２１０は、法線ベクトルオブジェクト座標（Ｎｘ０、Ｎｙ０、Ｎｚ０）を目座標（Ｎｘｅ、Ｎｙｅ、Ｎｚｅ）に変換する。同じ変換を、従法線オブジェクト座標（Ｂｘ０、Ｂｙ０、Ｂｚ０）及び表面接線オブジェクト座標（Ｇｘ０、Ｇｙ０、Ｇｚ０）に適用してこれらのベクトル（Ｂｘ０、Ｂｙ０、Ｂｚ０、及びＧｘ０、Ｇｙ０、Ｇｚ０）を表す目座標を生成することができる。テクスチャ座標と同様に、従法線及び表面接線ベクトルは、空間データから生成することができる。更に、現在アクティブのバンプマッピングアルゴリズムに依存して、ベクトルクロス乗積計算のいろいろなオプションが可能である。法線、従法線、及び表面接線ベクトルを得る方法には無関係に、変換ユニット２１０は、目座標を、ライティングサブユニット及びフォングユニットにおいて使用される大きさ及び方向形状に変換する。
【１２３０】  ユーザが定義した、及びビューボリュームの両クリップ面のための単純拒絶／受入れ試験が各頂点上で遂行される。試験の結果は、クリッピングユニット２３０へ伝えられる。あるプリミティブの前面または後面の見え方を決定する面積計算もここで計算され、その結果はクリッピングユニット２３０へ伝えられる。
【１２３１】  ・頂点ライティングユニット
頂点ライティングユニット２２０は、２４頂点光のための頂点毎の計算を実施し、それらがこのユニットを去る前に全ての可能化された光を組合わせる。もしＳＩＮＧＬＥ−ＣＯＬＯＲモードがセットされていなければ、合計鏡面成分は残余の光成分と組合わされない。これにより、後方パイプラインの残余の光情報には無関係に鏡面成分を補間することができる。
【１２３２】  ライティングユニット２２０は、“カラー材料”状態及び置換え（頂点のみ）をも実施する。
【１２３３】  ・フォングクリッピング／プリミティブ形成ユニット
クリッピングユニット２３０は、ユーザが定義したクリップ面の複製コピーを有しており、一方補助ｍｇによってロードされるビューボリューム面（Ｗｃ）は頂点データと共に下方へ渡される。このユニット２３０は、各多角形を試験して、その形状がビューボリュームの完全に内側にあるのか、または完全に外側にあるのかを決定する。完全に内側でも、または完全に外側でもないプリミティブは、残余の形状が完全にボリュームの内側になるまでクリップされる。充填されたプリミティブの一部である頂点間のデータの補間はパイプラインの後方において行われるので、元の頂点情報は新しい頂点空間情報と共に保持される。クリッピングユニット２３０は、かなりなパフォーマンスコストで線プリミティブを補間する。この好ましい実施は、有利なことに、クリッピングプロセスにおいて作られた頂点において新しい空間データ及び新しいテクスチャ座標名、カラー等を作成する必要を回避する。
【１２３４】  ＯｐｅｎＧＬ仕様は、１０の別個の型のジオメトリックプリミティブ、即ち、点、線、線ストリップ、線ループ、三角形、三角形ストリップ、三角形ファン、四角形、四角形ストリップ、及び多角形を定義している。しかしながら、パイプライン８４０の設計は三角形を処理するようになっているので、クリッピングユニット２３０は、３つより多くの頂点を有する多角形をより小さい成分に分割する。更に、クリッピングユニット２３０は、例えば頂点フラット型シェーディングのようなシェーディングに関連するデータを変化させる操作を実施する。
【１２３５】  ジオメトリブロック８４２は、データを、３２ビット浮動小数点フォーマットで格納している。しかしながら、モード抽出ブロック８４３へのデータバスは、２４ビットに過ぎない。従って、クリッピングユニット２３０は、データがそのユニットを去る前に、データを変換し、クランプし、そしてバックする。モード抽出ブロック８４３へのバスは、このユニット２３０から直接去る。
・入力及び出力
ジオメトリブロック８４２は、コマンド取り出し及びデコードブロック８４１、補助リング、及びモード抽出ブロック８４３とインタフェースする。コマンド取り出し及びデコードブロック８４１は、ジオメトリブロック８４２への入力パケットの通常の源であり、ＭＥＸはジオメトリブロック８４２からの出力パケットのための通常のシンクである。補助リングは、通常はジオメトリの処理に関連しない（マイクロコードまたはジオメトリブロック８４２データ経路レジスタへのランダムアクセスのような）ハードウェアへの特別なアクセスを与える。
【１２３６】  ジオメトリブロック８４２への通常入力は、コマンド取り出し及びデコードブロック８４１からである。補助リングからの特別な入力は、マイクロコード命今及び文脈切換えのような非パイプライン化グラフィックス機能をダウンロードする。
【１２３７】  コマンド取り出し及びデコードブロック８４１へのインタフェースは、データバス、コマンドバス、及び幾つかの制御信号からなる。これらのバス及び信号は一緒になって、パケットをコマンド取り出し及びデコードブロック８４１からジオメトリブロック８４２へ移動させる。
【１２３８】  コマンド取り出し及びデコードブロック８４１は、ジオメトリブロック８４２のためのアップパケットデータを待ち行列に入れ、完全なパケット及びコマンドワードが存在する場合には、データレディフラグを掲げることによってそれを信号する。処理済みの頂点は、後述するように、全頂点を転送するために複数のパケット転送を必要とし得る。
【１２３９】  ジオメトリブロック８４２がデータバスからワードを読出すと、は１サイクルのための肯定応答信号を掲げる。（２４ワードの１つの完全パケットだけが転送されるので、肯定応答信号は１２クロックの間高である。）更に、ジオメトリブロック８４２は、パイプラインサイクル境界においてだけパケットを転送することを意図し、最小パイプラインサイクル長は１６マシンサイクルである。パケットは１２データバスワードＷ０−Ｗ１１、及び１コマンドバスワードからなっている。
【１２４０】  グローバルコマンドワードの第２及び第３の最上位ビット（ＭＢＳ）は、ジオメトリブロック８４２がどのようにパケットを処理するのかを決定する。これらのビットは、パススルー及び頂点フラグである。もしセットされれば（「真」であれば）、パススルーフラグは、そのパケットがモード抽出ブロック８４３を通過することを指示する。もしクリアされれば（「偽」であれば）、このフラグはジオメトリブロック８４２がそのパケットを処理／消費することを指示する。
もし頂点フラグがセットされていれば、そのパケットが頂点パケットであることを指示する。もしクリアされれば、フラグはそのパケットがモードパケットであることを指示する。
消費されるモードパケットのフォーマットを説明する。ビット３１は保留されている。ビット３０及び２９はパススルー及び頂点フラグである。ビット２８−２５は演算コードを形成し、一方ビット２４−０は即値データである。
【１２４１】  演算コードは、汎用モード、材料、ビューポートパラメータ、バンプ状態、光カラー、光状態、マトリックスパケット、及び保留を含む１０の値の何れかを有している。これらの各演算コードに対応するパケット及び即値データに関しては後述する。
補助リングＩ／Ｏは、リング読出し要求、リング書込み要求、及びマイクロコード書込みを含む消費モードパケット演算コードのサブセットを使用する。これらのパケットの場合、「即値」データは、各パイプラインステージにおける最悪例を考慮に入れて論理パイプラインステージ（４ビット）、物理メモリ（４ビット）、及びアドレス（１０ビット）のフィールドを有している。
汎用モードパケットは、ジオメトリブロック８４２が必要とするモードビットの残余を送給する。
材料パケットは、材料カラー及び状態パラメータを送給する。
ビューポートパケットは、ビューポートパラメータを含んでいる。
バンプパケットは、表面接線及びバンプマッピングに関連する全てのパラメータを送給する。
【１２４２】  光カラーパケットは、特定の光カラーパラメータを含んでいる。
光状態パケットは、光モデルパラメータを含んでいる。
マトリックスパケットは、マトリックスメモリのためのマトリシーズを送給する。このパケットは、全てのテクスチャパラメータ、ユーザクリップ面、及び全ての空間マトリックスのために使用される。
処理済み頂点パケットのフォーマットを説明する。ビット３１は保留されている。ビット３０及び２９はパススルー及び頂点フラグである。ビット２８−２７は頂点サイズを形成し、ビット６−３はプリミティブ型を形成し、ビット２−１は頂点シーケンスを形成し、ビット０はエッジフラグである。これらの各フィールドに関して以下に説明する。
【１２４３】  （処理済み頂点バケットのビット２６−７は、使用されない。）
頂点サイズは、どれ程多くのパケット交換によって頂点全体の点転送を完了させるか、即ち１回、２回、または３回であるかを指示する。頂点サイズが１にセットされている場合には、１つのパケットが、空間、法線、テクスチャ［０］、及びカラーを転送するフルパフォーマンス頂点パケットである。頂点サイズが１にセットされている場合には、２つの各パケットはハーフパフォーマンス頂点パケットである。第１のパケットは、フルパフォーマンス頂点パケットと同一である。第２のパケットは、テクスチャ［１］、従法線、及び接線を転送する。頂点サイズが３にセットされている場合には、３つの各パケットは第３パフォーマンス頂点パケットである。最初の２つのパケットはハーフパフォーマンスパケットと同一である。第３のパケットはテクスチャ［２−７］を転送する。（注：実際には、常に１つのパケットだけが転送される。複数の交換及び複数の転送がパケット毎に発生し得るが、１つのパケットだけが転送される。）
プリミティブ型は、頂点によって形成されるプリミティブの型、即ち点、線、線ストリップ、線ループ、三角形、三角形ストリップ、三角形ファン、四角形、四角形ストリップ、及び多角形を指定する４ビットのフィールドである。
【１２４４】  頂点シーケンスは、プリミティブ内の頂点のシーケンス、即ち、最初、中央、最後、または最初及び最後を指定する２ビットのフィールドである。「最初」はプリミティブ内の最初の頂点を指定し、「中央」は中央内の頂点を指定し、そして「最後」はプリミティブ内の最後の頂点を指定する。「最初及び最後」は、プリミティブ内の最初及び最後の両頂点である単一点を指定する。
エッジフラグは、もし多角形描写モードが「充填」であれば、多角形のエッジが境界エッジであることを指定する。もし多角形描写モードが「線」であれば、エッジが可視か否かを指定する。最後にもし多角形描写モードが「点」であれば、それは、その点が可視であることを指定する。
【１２４５】  ０  −  境界または可視、
１  −  非境界または不可視。
【１２４６】  サイズ１（フルパフォーマンス）頂点パケットは、１回の転送でサイズ１頂点を送給する。
サイズ２（ハーフパフォーマンス）頂点パケットは、２回の連続転送でサイズ２頂点を送給する。ジオメトリブロック８４２は、このパケット中に１回だけコマンドバスを読出す。変換ユニット２１０は、一旦ある頂点の処理を開始するとその処理を休止しないので、連続パイプラインサイクル上で２回のデータ転送が発生する。（コマンド取り出し及びデコードブロック８４１は、ブロックがこれを保証できるまで「データレディ」を表明しない。）
パケット内のパラメータの位置は、考え得るテクスチャ座標を除いて、固定されている。もし接線生成が可能化されていれば（ＴＡＮＧ＿ＧＥＮ＝１）、接線生成に使用するために指定されているテクスチャ（ＢＵＭＰ＿ＴＸＴ［２：０］）は、そのパケット内の位置をテクスチャ０と交換する。ＢＵＭＰ＿ＴＸＴは、サイズ２頂点の場合には、０または１にしかセットすることができない。
サイズ３（第３パフォーマンス）頂点パケットは、３回の連続転送でサイズ３頂点を送給する。サイズ２頂点パケットと同様に、ジオメトリブロック８４２は、このパケット中に１回だけコマンドバスを読出す。変換ユニット２１０は、一旦ある頂点の処理を開始するとその処理を休止しないので、連続パイプラインサイクル上で３回のデータ転送が発生する。（コマンド取り出し及びデコードブロック８４１は、ブロックがこれを保証できるまで「データレディ」を表明しない。）
パケット内のパラメータの位置は、考え得るテクスチャ座標を除いて、固定されている。もし接線生成が可能化されていれば（ＴＡＮＧ＿ＧＥＮ＝１）、接線生成に使用するために指定されているテクスチャ（ＢＵＭＰ＿ＴＸＴ［２：０］）は、そのパケット内の位置をテクスチャ０と交換する。ＢＵＭＰ＿ＴＸＴは、サイズ３頂点の場合には、０または７にしかセットすることができない。
【１２４７】  伝播モードパケットは、ジオメトリブロック８４２を通して変更されなかったデータの１６ワードまでを、モード抽出ブロック出力バスへ移動させる。コマンドヘッダーと、それに続くデータの長さワード（合計、長さ＋１ワード）がモード抽出ブロックバス上に配置される。
【１２４８】  伝播モードパケットのフォーマットを説明する。ビット３１は、保留されている。ビット３０及び２９は、パススルー及び頂点フラグである。ビット２０−１６は、長さフィールドを形成している。（ビット２８−２１及び１５−０は使用されない。）
長さは、パケットのデータ部分内に存在する（３２ビット）ワードの数を指定する５ビットのフィールドである。一実施の形態では、値の範囲は０から１６までである。
【１２４９】  伝播頂点パケットのフォーマットを説明する。ビット３１は、保留されている。ビット３０及び２９は、パススルー及び頂点フラグである。ビット２０−１６は、長さフィールドを形成している。（ビット２８−２１及び１５−０は使用されない。）
伝播頂点パケットは、ジオメトリブロック８４２が、合計長さワードのためのデータをモード抽出ブロック出力バス上に配置する際にコマンドワードを破棄することを除いて、伝播モードパケットと同じように動作する。
【１２５０】  ジオメトリパイプライン８４０は、始動、初期化、及び文脈切換え中にジオメトリブロック８４２を制御するための特別なパケットのためのインタフェースとして、補助リングを使用する。パケットは、消費モードコマンドワード（パススルー＝「偽」、頂点＝「偽」）を使用し、従ってコマンド取り出し及びデコードブロック８４１からの消費モードコマンドワードと同一のコマンドワード記述を共用する。ジオメトリブロック８４２内のリングコントローラは、それが変換サブユニット内の第１の物理パイプラインステージに入る前に、コマンド取り出し及びデコードブロック８４１データ及びコマンドバスへのアクセスを有しているので、ジオメトリブロック８４２の大部分はそのパケットの源の知識を有していない。コマンド取り出し及びデコードブロック８４１は優先権を有しているので、（良くも、悪くも）バスをオフにするようにリングをロックできる。
【１２５１】  ジオメトリブロック８４２からの通常出力は、モード抽出ブロック８４３へである。補助リングへの特別な出力は、文脈切換えのような非パイプライングラフィックス機能の遂行を援助する。
【１２５２】  モード抽出ブロック８４３へのインタフェースは、データバス及び２つの制御信号、例えばデータ有効を含む。データ有効パルスは、データの各有効ワードを伴う。インタフェースハードウェアは、モード抽出ブロック側上の待ち行列を制御する。ジオメトリブロック８４２は、その待ち行列がフルになる前に現パイプラインサイクルを終了させることができるようにするために、３２エントリが残っている時点で信号される。幾つかの付加的なエントリが、信号走行時間を補償する。
【１２５３】  モード抽出ブロック８４３は、待ち行列内の最初のエントリをヘッダーとして認識し、パケットの長さを決定するためにそれをデコードする。ブロック８４３は、この長さカウントを使用して次のヘッダーワードを認識する。
ジオメトリブロック８４２からのパケット出力には４つの型、即ち、カラー頂点、空間頂点、伝播モード、及び伝播頂点が存在する。これらの各パケットに関して以下に説明する。
カラー頂点及び空間頂点パケットは、処理した頂点入力パケットの結果であるローカルパケットである。伝播出力パケットは、伝播入力パケットと１対１で対応する。
カラー頂点パケットは、頂点の位置に関連する特性を含んでいる。後面選別によって除去されることも、ボリュームクリップ面によってクリップ（完全多角形の単純拒絶または複数面排除）されることもない各頂点は、単一頂点カラーパケットを発生する。このパケットのサイズは、入力頂点パケットのサイズ、及びそのパケットが受けられた時点における状態に依存する。
【１２５４】  空間頂点パケットは、単一頂点の空間座標及び関係を含んでいる。後面選別によって除去されることも、ボリュームクリップ面によってクリップ（完全多角形の単純拒絶または複数面排除）されることもない各入力頂点パケットは、正確な入力頂点座標に対応する空間頂点パケットを発生する。クリップ面が多角形または線と交差し、且つ多角形または線が完全に拒絶されていない時には、付加的な空間頂点が形成される。
【１２５５】  出力伝播モードパケットは、その対応する入力パケットと同一である。
出力伝播頂点パケットは、その対応する入力パケットのデータの全てを含むが、そのコマンドワードは剥ぎ取られている。ジオメトリブロック８４２は、入力コマンドワードを出力しない。それにも拘わらず、コマンドワードからの長さフィールドは、出力バス上に配置される有効ワードの数をセットする。従って、「長さ」＝伝播頂点パケットのためのデータワードである。
・ジオメトリブロック
ジオメトリブロック８４２は、パイプライン８４０内の残余のブロックの透視（パースペクティブ）からの完全ブロックとして機能する。しかしながら、内部的には、ブロック８４２は一連の独立ユニットとして機能する。
【１２５６】  変換ユニット２１０は、ジオメトリブロック８４２へのパケットの流入を調整する。球形テクスチャ及び表面接線計算の高い待ち時間要求を達成するために、ブロック８４２は、出力からのオペランドを、ページ交換境界を横切ってバイパスさせてその入力ヘ戻す。従って、一旦パケット（典型的には、頂点）が変換ユニット１２０を横切って開始されると、ユニットを横切る中間で休止することはない。パケットは、そのパケット全体のための空間が同期待ち行列２３１内に存在する場合には、論理パイプラインステージＡ２１２内へ前進する。
【１２５７】  ライティングユニット２２０も、機能ユニット出力から入力ヘ、ページ交換境界を横切ってバイパスする。これを容易にするために、ライティングユニット２２０には、その入力及び出力バッファに待ち行列が配置されている。これらの待ち行列は一緒に動作し、変換ユニット２１０がデータの準備を整えると、ライティングユニット２２０が常にそのデータを処理する準備を整えるようにする。
【１２５８】  入力待ち行列内の各レコードエントリは、出力待ち行列内に対応するレコードエントリを有している。従って、変換ユニット２１０が同期待ち行列内に余地を見出した時には、ライティングユニット２２０もデータを処理するための余地を有している。同期待ち行列内のパケットは、ライティングユニット２２０がカラーをその出力待ち行列内に書込んだ後に限って有効になる。出力待ち行列が書込まれると、コマンド同期待ち行列も書込まれる。
【１２５９】  クリッピングユニット２３０は、同期待ち行列内に有効パケットが存在するまで待機する。パケットが有効になると、クリッピングユニット２３０はパケットをプリミティブ形成待ち行列２３１内へ移動させる。ジオメトリブロック８４２の出力は簡単な二重バッファである。
【１２６０】  内部ユニット２１０、２２０、２３０は、物理パイプラインステージである。各物理パイプラインステージは、パイプラインステージ間隔でのみブロック８４２の残余と同期するそれ自体の独立制御メカニズムを有している。
【１２６１】  クリッピングユニット２３０は、ブロックｂ８４２の残余より遙かにそれを不規則に停止及び始動させる若干のかなり独特な制約を有している。
【１２６２】  システムがリセットされると、パイプラインは空になる。フル信号は全てクリアされ、ユニットコントローラ内のプログラム可能なパイプラインサイクルカウンタがカウントダウンし始める。カウンタが０を過ぎてデクレメントすると、前進パイプライン信号が生成され、全てのパイプラインステージコントローラへ分配される。カウンタは、プログラムされた値へリセットされる。
【１２６３】  もしジオメトリブロック８４２に対する有効要求がベンディングで存在すれば、パケットは、コマンド取り出し及びデコードブロック８４１、または補助リングの何れかからパイプラインの最上部へ入る。（補助リングコマンドユニットは優先権を有しており、コマンド取り出し及びデコードブロック、補助リングコマンド要求をロックアウトすることができる。）
次のパイプラインサイクル中に、ユニットコントローラはパケット要求を解析し、パイプラインステージによって処理するためにパケットを準備する。これは、補助リングから到来するデータのための多重パイプラインサイクルプロセスであることができる。（コマンド取り出し及びデコードブロック８４１は、ジオメトリブロック８４２のためにある準備をするので、これはブロック８４１からの要求には当てはまらない。）更に、コマンド取り出し及びデコードブロック８４１からの若干のパケットは、多重パイプラインサイクルパケットである。コマンド取り出し及びデコードブロック８４１は、ブロック８４１が完了パケットレディを送るまでは、これらのパケットを処理させるための要求をジオメトリブロック８４１へ送ることはない。
【１２６４】  パイプラインサイクルカウンタが再度ロールオーバーすると、前進パイプライン信号が分配され、ユニットコントローラはそのパイプラインフル入力を解析する。もし信号がクリアであれば、コントローラはパイプラインステージＡコマンドレジスタのホールド入力をリセットし、パケットを次のステージへ前進させる。ステージＡ２１２は、新しいパケットを検出して処理を始める。
【１２６５】  ステージＡ２１２は、パケットの型、及びそのステージ内にセットされている状態に依存して、パケットを処理するために１サイクルより多くのパイプラインサイクルを要求し得る。もし１サイクルより多くのパイプラインサイクルが必要であれば、パイプラインフル信号が掲げられる。もしパイプラインフル信号が掲げられれば、ユニットコントローラは、次のパケットをパイプの下方へ前進させることは許されない。パケットが現在のステージを完了したことをステージが検出すると、パイプラインフル信号はクリアされ、ユニットコントローラがステージＡのコマンドレジスタＡを前進させたのと全く同じように、ステージＡはステージＢのコマンドレジスタを前進させる。
【１２６６】  パイプラインが充填されると、各ステージ毎の決定遂行プロセスは、より複雑になり得る。各ステージは何れかの所与の頂点上で異なる組の操作を遂行するから、若干の組の操作は他の組の操作より長くなり得る。特に、個々のパイプラインステージ内により複雑な状態がセットされている場合には、これは真である。更に、パイプライン内の若干のパケットは、頂点よりはむしろ変化するモードであり得る。これは、個々のパイプラインステージにおいてさえ、先行頂点及び次の頂点を処理する手法を変更する可能性がある。
【１２６７】  ユニットコントローラは、ジオメトリパイプライン８４２へのデータの入力を調整する。コマンドは２つの源、即ち補助リング及びコマンド取り出し及びデコードブロック８４１から到来する。補助リングメモリ要求は例外によって転送され、通常操作中は発生しない。コントローラはコマンドをデコードし、コマンドワードを生成する。コマンドワードは、次のパイプラインステージ内にどのような開始命令があるかを決定するパケットに関する情報を含んでいる。更に、ユニットコントローラは、コマンド取り出し及びデコードブロック８４１とジオメトリブロック８４２との間のインタフェースをも管理する。
【１２６８】  補助リングコマンドは、いろいろなパイプラインステージへの命令メモリパケット（書込み）またはデータメモリ（読出し）パケットの何れかである。読出し機能は文脈切換え中にスティップルパターンを読出すが、読出しメカニズムは殆どのメモリ位置を読出すことができる十分汎用である。
コマンド取り出し及びデコードブロックコマンドは２つの型、即ち、伝播モード（伝播した、または消費した）、または頂点である。
各ステージ毎のパイプラインステージコントローラは全て、同一の基本的設計を変形したものである。コントローラは、ハードウェアバグ及び変化するアルゴリズムを補償するために、可能な限り多様性である。一実施の形態では、それらはプログラム可能なマイクロコードとして実現されている。実際に、コントローラ内の全ての状態は、ある手法でプログラム可能である。
パイプラインステージ制御は先行ステージ（ｉ−１）から開始され、新しいコマンドをコマンドレジスタ内に配置する。命令制御状態マシンは、前進パイプライン信号がパルスすると、このイベントを調べる。
【１２６９】  プログラム可能なマイクロコード命令メモリは、ジオメトリブロック８４２を駆動する。各物理ステージは、専用命令メモリを有している。各物理ステージは僅かに異なるデータ経路要素を有しているから、各物理ステージ毎の演算コードは僅かに異なっている。
・パイプステージＡ
論理パイプラインステージＡ２１２は、主として、頂点を４×４マトリックスを用いて変換する。従って、その命令セットは比較的小さい。ユニットによりユーティリティを付加するために、各マトリックス乗算演算を有する条件コードは、演算の結果をどのように使用するかを指定する。
【１２７０】  命令メモリ１２３０は、命令のページに分割される。各ページは、操作の“パイプラインサイクル”価値を含んでいる。コマンドレジスタ１２Ａ０は、ページ選択を駆動する。デコードロジックは、コマンド及び現モードを使用して、現状態のための適切なジャンプテーブルアドレスを選択する。
【１２７１】  ジャンプテーブルは、命令メモリアドレス及びページモードを含んでいる。（ページモードは、現パイプラインサイクルの場合だけ有効なモードである。）命令メモリアドレスは、現ページのための最初の有効命令を指し示す。全ての命令は、１サイクル内に発行される。従って、この初期アドレスは、パイプラインサイクルの持続時間中絶えずインクリメントされる。
前進パイプライン信号２１１Ｈは、現コマンドの状態を評価して、それが完了しているか否かを決定することをＧＣＷコントローラ１２１０に告げる。もしそれが完了していれば、コントローラ１２１０はコマンドレジスタ１２Ａ０からホールドを除去し、新しいコマンドをパイプラインステージに入力する。
コマンドレジスタ１２Ａ０は、ジオメトリコマンドワードを格納するためのホールドレジスタである。コマンドワードは、変更されてないコマンドバスデータ、及びＭＳＢとして付随する有効ビット（Ｖ）からなる。
【１２７２】  デコーダ１２２０は、コマンドワードの演算コードフィールド及び現モードを、ジャンプテーブルメモリ１２３０を参照するためのアドレスに変換する組合せ論理ブロックである。デコーダ１２２０は、テクスチャ状態マシン１２６０のためのテクスチャポインタ及びマトリックスポインタ、並びに書込み可能化メモリ１２８０のための新しいモード可能化フラグをも生成する。
残余の状態（テクスチャ状態マシン内ではない）も、命令コントローラ２１２６内にある。詳述すれば、ＴＡＮＧ＿ＧＥＮ及びＴＡＮＧ＿ＴＲＮＳもここに格納される。これらのレジスタはリセット時にクリアされ、バンプ状態パケットによってセットされる。
【１２７３】  ハードウェアジャンプテーブルは、プログラム可能なメモリが有効データを有する前の、リセット及び始動中に使用される。
書込み可能化メモリ１２８０は、マトリックスメモリ２１２５内に格納されている各マトリックスに関連する書込み可能化ビットを格納している。可能化ビットは、４機能ユニット２１２２のための各データ経路毎に存在している。オペランドＡアドレスビット［６：２］は、このメモリ１２８０への読出しアドレスを選択する。
マトリックス乗算及び移動命令は、書込み可能化メモリ１２８０にアクセスすることができる。書込み可能化ワードは、ワードを頂点バッファＢＣ２１２３へ書込むことと、符号ビットをジオメトリコマンドワードへ書込むことを可能にする。
【１２７４】  メモリは、ジオメトリコマンドワード内のマトリックスパケットによって充填される。パケットヘッダー（コマンド）は、書込みアドレス及び４つの可能化ビットを含んでいる。命令フィールド併合ロジック１２９０は、主として、データ経路成分を制御する信号を選択する組合せロジックである。ハードウェア命令メモリ１２７０は、ハードワイヤードまたはソフトウェア命令を選択する。ソフトウェア命令ワードを構成している若干のフィールドは多重化される。
テクスチャ状態マシンは、データ経路制御フィールドのモードを選択する。
ハードウェア命令メモリ１２５０は、マイクロコードメモリが初期化される前の始動時にデータ経路を制御する。
ジオメトリコマンドワードコントローラ１２１０は、ステージＡ２１２のシーケンシグを実施する。グローバルパケットコントローラ２１１からの前進パイプライン信号２１１Ｈは、出口コードの評価をトリガする。（出口コードは、ジャンプテーブルメモリ１２４０内でプログラム可能である。）
考え得る出口コードは、「真」、「偽」、「ＴＳＭ＿ＣＯＮＤＩＴＩＯＮＡＬ」である。ＴＳＭ＿ＣＯＮＤＩＴＩＯＮＡＬは、現命令ページが現パケットを完了したか否かをＴＳＭ完了信号が決定することを可能にする。もし条件が「真」であれば、次の前進パイプラインストローブがコマンドレジスタのホールドオンを解放し、新しいコマンドがパイプへ入る。
【１２７５】  持続時間カウンタは、頂点がステージ２１２内にある時間を追跡する。コマンドレジスタ１２Ａ０に新しいコマンドが書込まれるとカウンタはクリアされる。
テクスチャ状態マシン１２６０は要求を決定し、８つのテクスチャ及び２つのユーザが定義したクリップ面セットの各々の状態を追跡する。状態マシン１２６０は、頂点のサイズ及び現持続時間に基づいて、要求に順位付けする。頂点サイズは、現頂点のための最大テクスチャ数を制限する。現持続時間は、現パイプラインサイクルのための最大テクスチャ数を制限する。
状態マシン１２６０は、生成、クリッピングセット、変換の順序に順位付けする。もしテクスチャが生成されなければ、それらは頂点バッファＢＣへ移動される。移動操作は、各テクスチャに関連する４ビットの生成書込み可能化マスクの補数を使用する。これにより、全ての可能化されたテクスチャは頂点バッファＢＣへ伝播することができる。
マイクロコード化テクスチャ命令が発行されると、状態マシン１２６０は命令ワードを供給する。アドレスが使用されると、状態マシン１２６０はその操作を完了したものとしてマークし、次の要求へ移動する。
【１２７６】  好ましくはインタリーブされたパイプラインステージであるパイプラインステージは、例えば組合された単一ステージＢＣのように本発明内に使用されるが、他の形態を代わりに使用することもできる。
・スクラッチパッドメモリ
単一の論理パイプラインステージＢＣは、現頂点に関連するデータをスクラッチパッドメモリ２１３２内に一時的に格納するために使用される。論理ステージＢＣは、データ経路計算に使用される現モード情報、例えばビューポート変換パラメータ及びバンプスケールパラメータを、メモリ２１３２内に格納することもできる。最後に、論理ステージＢ及びＣは、目、テクスチャ、及びウィンドウ座標の先行の２つの頂点の値をメモリ２１３２内に格納する。
【１２７７】  現頂点データは、あたかも二重バッファ区分であるかのように動作することができる論理ステージＢＣ内へ分割することが好ましい。新しい頂点パケットがバッファポインタを切換えるので、ＢＣを単一のステージとして処理することができるように、ステージＢにおいて計算されたデータをステージＣにおいて使用することができる。
先行頂点データは、論理Ｍ１及びＭ２二重バッファ区分内へ分割される。またバッファポインタは、新しい頂点パケットがパイプラインを下方へ伝播すると切換わる。（これは、現ジオメトリ及び頂点順序に依存する“第１”及び“第２”の頂点表記法とは区別される。）
・頂点バッファＢＣ
頂点バッファＢＣ２１２３は、数学機能ユニット２１３３を通して頂点データをステージする。頂点バッファＢＣ２１２３は、ステージＡとＢＣとの間の三重バッファとして役立つ。この場合、ステージＡはバッファの書込み側（Ｗ）にアクセスし、ステージＢは読出しバッファの一方（Ｒ０）にアクセスし、そしてステージＣは第２の読出しバッファ（Ｒ１）にアクセスする。新しい頂点（ＳＮ＝１）がパイプラインを下方へ伝播すると、それはＷ、Ｒ０、Ｒ１の順序で付加的なバッファポインタを受ける。その所与の頂点は、第２の頂点またはモードパケットの何れかが後続するまで、各ポンタの所有（ポゼッション）を保持する。
・数学機能ユニット
このステージ内の数学機能ユニット２１２３は、ｍａｔｈＦｕｎｃ＿Ｆ３２である。２つの数学機能ユニットが存在し、各数学機能ユニットは各サイクルに独立命令を実行する。
【１２７８】  数学機能ユニット演算コードが、
2004272928.tif 000170
【１２７９】である場合、内積シーケンスは、単にＭＵＬ、ＡＣＣ、ＡＣＣである。逆シーケンスは、ＲＣＰ、ＲＣＰＭＵＬである。同様に、逆自乗平方根シーケンスはＲＳＱＴ、ＲＳＱＴＭＵＬである。
【１２８０】  データ変換も、デノーマル数も必要ではないから、両仮数のＭＳＢを１にすると暗示ビットがセットされる。仮数の出力ＭＳＢも無視することができる。オーバーフロー及びアンダーフロービットはエラーレジスタへ向かわせることが好ましい。
．命令制御
コントローラ１８００は、データ経路の制御を時分割している論理ステージＢＣによって使用される２つの命令を制御する。ある複製が必要であり得ることが理解されよう（例えば、コマンドワードレジスタ１８１０の場合、共通物理ステージ内に仮想パイプラインステージの共存を可能にするために）。
・コマンドレジスタ
簡単なホールドレジスタ１８１０が、ジオメトリコマンドワードを格納する。各々は、変更されないコマンドバスデータ、及び先行ステージによって作られた制御ビットからなる。
【１２８１】  ステージＢ及びＣは各々、コマンドレジスタのコピーを有している。ステージＢは、どのビューボリューム面が現ジオメトリによって切られたかを決定するために、比較ビットを追加する。
・デコーダ
デコーダ１８３０は、コマンドワードの演算コードフィールド及び現モードを、ジャンプテーブルメモリ１８４０を参照するためのアドレスに変換する組合せロジックである。書込み可能化レジスタ１８９０は、書込み可能化ポインタ、書込み可能化ビット、及びモード書込み可能化ストローブを格納する。
【１２８２】  デコーダ内の全ての成分は、時分割されている。
・ハードウェアジャンプテーブル
ハードウェアジャンプテーブル１８５０は、プログラム可能なメモリが有効データを有する前の、リセット及び始動中に使用される。
【１２８３】  ハードウェアジャンブテーブル内の全ての成分は、時分割されている。インタリーブされたステージに関係する複製は存在しない。
・書込み可能化レジスタ
書込み可能化レジスタ１８９０は、条件付き書込み命令のための書込み可能化ビットを格納する。
【１２８４】  各ステージは、それ自体の独自の可能化レジスタを有している。ジャンプテーブル１８５０は、何れかのパイプラインサイクル境界においてＢレジスタをＣレジスタへ渡すようにプログラムすることができる。
・フィールド併合ロジック
命令フィールド併合ロジック１８８０は、データ経路成分を制御する信号を選択する組合せブロックである。ハードウェア命令メモリ１８７０は、ハードワイヤードまたはソフトウェア命令を選択する。ソフトウェア命令ワードを構成している若干のフィールドは多重化されている。
【１２８５】  命令フィールド併合ロジック１８８０は、条件付き書込み命令のためのデータの選択を実施する。
・ハードウェア命令メモリ
ハードウェア命令メモリ１８７０は、マイクロコードメモリが初期化される前の始動時におけるデータ経路を制御する。
・クリッピングユニット
クリッピングユニット２３０は、ジオメトリブロック８４２のバックエンドである。クリッピングユニット２３２へ向かう頂点パケットは、変換及びライティングユニット２１０、２２０において計算されたそれらのデータの全てを有している。ライティングユニット２２０は頂点のカラーを計算し、一方変換ユニット２１０は残余のデータを供給する。ユニット２１０、２２０はデータを幾つかの同期待ち行列内に書込み、データはクリッピングユニット２３２へ入る際に同期させられる。
【１２８６】  クリッピングユニット２３０は、２つの機能部分、即ち、クリッピングサブユニット２３２、及びフォーマットサブユニット２３３に分割されている。クリッピングサブユニット２３２は、頂点を収集し、プリミティブを形成し、そして結果を出力する。フォーマットサブユニット２３３は、クリッピングサブユニット２３２からのデータを所望の形状に再フォーマットし、出力待ち行列２３４を通してパケットをモード抽出ブロック８４３へ送出する。
【１２８７】  クリッピングサブユニット２３２は、入力ジオメトリを、点、線、または三角形の何れかの型のプリミティブに分割し、得られたプリミティブを、ユーザが定義したクリップ面、及びビューボリューム面の両者に対してクリップし、クリップしたプリミティブをフォーマットサブユニット２３３へ送る。
【１２８８】  頂点パケットは、パイプラインステージＫ、Ｌ、及びＭ内のクリッピングサブユニットを通過する。ステージＫにおいては、プリミティブ形成待ち行列２３２１、２３２２、２３２４が頂点データを格納する。同時に、プリミティブ形成が発生する。もしプリミティブが形成されれば、ステージＫは新しいプリミティブをステージＬへ渡してクリッピングさせる。
ステージＬは、新しいプリミティブを「単純に受入れまたは拒絶」条件に関して調べる。クリッピングが必要な場合には、マイクロコードを実行して上述したようにクリッピングアルゴリズムを遂行する。
クリッピングアルゴリズムが完了した後に、ステージＬのための制御が、クリップされた結果をステージＭへ移動させる。
ステージＭは、クリップされたプリミティブ及び元のプリミティブを抽出し、それらをフォーマットサブユニット２３３へ送る。
【１２８９】  （ステージＬ及びＭへのヘッダー待ち行列の深さは、ヘッダー空間が欠如することによってクリッピングサブユニットがパイプライン内にバブルを挿入しないように選択されている。バブル挿入が発生し得る最悪シナリオは、単純に受入れたジオメトリを処理することである。）
クリッピングサブユニット２３２のデータ経路は、プリミティブのクリッピングに含まれる全ての計算を遂行する３２ビット浮動小数点数学ユニット２３２５を有している。
【１２９０】  ４つのメモリブロック（スクラッチパッドＧＰＲ２３２２、及びプリミティブ、テクスチャ、及びカラー待ち行列２３２１、２３２３、２３２４）。プリミティブ待ち行列メモリブロック２３２１及びスクラッチパッドＧＰＲ２３２２は、一時的なデータ及び新しい頂点データを格納することによってプリミティブクリッピングを支援する。テクスチャ及びカラー待ち行列メモリブロック２３２３、２３２４はプリミティブを形成し、待ち時間の変動を滑らかにするために頂点データを累積する。
【１２９１】  スクラッチパッドＧＰＲ２３２２のオーナーは常にステージＬである。３つのステージＫ、Ｌ、及びＭは、他の３つのメモリブロック２３１１、２３２３、２３２４の読出し及び書込みポートのオーナーシップを共用する。“オーナーシップ”は、ポートを“所有”するステージが全ての必要アドレス及び制御信号を発生することを意味する。
【１２９２】  詳述すれば、ステージＫ及びＬは、プリミティブ待ち行列２３２１の書込みポートのオーナーシップを共用する。ステージＫは、この書込みポートを使用して空間データをプリミティブ待ち行列２３２１内へ転送する。ステージＫは、ステージＬに比して低いオーナーシップ順位を有しているが、ステージＬ及びＫは互いに独立的に走るので、何れか１つのパイプラインステージ内のデータの転送を完了させるためには、ステージＬはステージＫのために十分な帯域幅を提供しなければならない。
【１２９３】  ステージＬとＭとの間には、２つの共用オーナーシップが存在する。ステージＭは、プリミティブ待ち行列２３２１の読出しポート１（第２の出力、即ち右側のポート）を支配するが、それはステージより低い順位を有している。ステージＭはこの第２のポートを使用して、クリップされたプリミティブの新しい頂点のデータを読出す。ステージＬは第２の出力ポートの使用を最小にするが、ステージＭが十分な帯域幅を有していないかも知れない潜在的なケースが存在する。ハードウェアフックは、このシナリオに対処する。
【１２９４】  ステージＬとＭとの間の第２の共用オーナーシップは、テクスチャ及びカラー待ち行列２３２３、２３２４の読出しポート上である。もしステージＬがこれら２つの待ち行列２３２３、２３２４の一方内のデータにアクセスする必要があれば、ステージＭはそのポートを使用しないようになっている。そうでなければ、ステージＬは、次のパイプラインステージ及び繰り返しを待機する。
【１２９５】  このスキームは、ステージＬにある欠陥を賦課する。しかしながら、ステージＬは補間だけのために一方のポートから読出し、補間パフォーマンスは受容できる程低い。
【１２９６】  以下に、本発明を完全に説明するが、当分野に精通していれば、特許請求の範囲から逸脱することなく、以下の説明に多くの変化及び変更を行うことが可能であることは理解されよう。
ＸＩＩＩ．ピクセル機能ブロック（ＰＩＸ）の詳細な説明
以下に、エイリアス除去を用いて、及び用いないで、３Ｄグラフィックスイメージを描写するための装置及び方法を説明する。一実施の形態では、本装置は、グラフィックスアプリケーションからのコマンドを受けるためのポート、描写したイメージをディスプレイへ送るための出力、ポート及び出力に結合されているフラグメント操作パイプラインを含み、パイプラインはピクセル毎の基準でフラグメントに対してフラグメント操作を遂行するためのステージ、及びサンプル毎の基準でフラグメントに対してフラグメント操作を遂行するためのステージを含んでいる。
【１２９７】  一実施の形態では、ピクセル毎の基準で遂行するステージは、シザー試験ステージ、スティップル試験ステージ、アルファ試験ステージ、またはカラー試験ステージの１つである。サンプル毎の基準で遂行するステージは、Ｚ試験ステージ、混合ステージ、またはディザリングステージの１つである。
【１２９８】  別の実施の形態では、本装置は、ステンシル試験をピクセル毎の基準で遂行するのか、またはサンプル毎の基準で遂行するのかをプログラム的に選択し、ステンシル試験を選択された基準で遂行する。
【１２９９】  別の実施の形態では、本装置は、サンプル毎のフラグメント操作に使用するためのサンプルとして、あるピクセルの１組のサブディビジョンをプログラム的に選択し、プログラム的に選択したサンプルを使用してサンプル毎のフラグメント操作を遂行する。
【１３００】  別の実施の形態では、本装置は、プリミティブベースエイリアス除去をプログラム的に可能にする。即ち、エイリアス除去は、プリミティブ毎の基準でターンオンまたはターンオフすることができる。
【１３０１】  別の実施の形態では、本装置は、ジオメトリを通る幾つかのパスをプログラム的に遂行する。本装置は、サンプル毎のフラグメント操作に使用するためのサンプルとしてあるピクセルの第１の組のサブディビジョンをプログラム的に選択し、プログラム的に選択したサンプルを使用してサンプル毎のフラグメント操作を遂行する。次いで本装置は、第２のサンプル毎のフラグメント操作に使用するためのサンプルとしてあるピクセルの異なる組のサブディビジョンをプログラム的に選択し、プログラム的に選択したサンプルを使用して第２のサンプル毎のフラグメント操作を遂行する。
【１３０２】  第２のパスから得られたカラー値は、第１のパスから得られたカラー値と共に累積される。ピクセル当たりのサンプルの数を効果的に増加させるために、幾つかのパスを遂行することができる。各パス毎のサンプル位置は異なっており、ピクセルカラー値は、先行パスの結果と共に累積される。
【１３０３】  本装置は、サンプル毎のフラグメント操作に使用するサンプルとして、あるピクセルの第１の組のサブディビジョンをプログラム的に選択し、この組内のサンプルに重みをプログラム的に割当て、フラグメントに対するサンプル毎のフラグメント操作を遂行する。本装置は、あるピクセル内の複数のサンプルのカラー値を組合せて、そのピクセル位置におけるフレームバッファ内に得られるカラーを求める方法をプログラム的に決定する。更に、本装置は、ピクセル内の全てのサンプルの深さ値から、その深さのピクセルに割当てられた深さ値をプログラム的に選択する。
本装置は、フレームバッファに対する読出し・変更・書込み操作を用いずに、カラー、深さ、及びステンシルバッファを部分的に、または完全にクリアする方法を含んでいる。
【１３０４】  本装置は、多角形に割当てられたピクセル毎の深さ値、並びにその多角形の頂点において指定されたものから補間された深さ値を斟酌する方法を含む。
【１３０５】  本装置は、ステンシル試験において多角形に割当てられたピクセル毎のステンシル値、並びにその多角形の指定されたステンシル参照値を斟酌する方法を含んでいる。
【１３０６】  本装置は、カラーバッファを更新することなく、シーン内の何れかのピクセルがスクリーン上で可視であるか否かを決定する方法を含む。
略語
以下は、説明に現れる略語、及びそれらの拡張された意味である。
【１３０７】  ＢＫＥ：バックエンドブロック８４Ｃ、
ＣＵＬ：選別ブロック８４６、
ＭＩＪ：モード注入ブロック８４７、
ＰＨＧ：フォングブロック８４Ａ、
ＰＸＯ：ピクセル出力ユニット２８０、
ＳＲＴ：分類ユニット８４４、
ＴＥＸ：テクスチャユニット８４９、
ＶＳＰ：可視スタンプ部分。
概要
・描写システム
図Ｊ８は、三次元グラフィックスイメージを描写するためのシステム８００を示している。描写システム８００は、データ処理ユニット（ＣＰＵ）８１０、メモリ８２０、ユーザインタフェース８３０、グラフィックスプロセッサのような双対プロセッサ８４０、通信インタフェース８５０、及び通信バス８６０の各々を１つまたはそれ以上含んでいる。
【１３０８】  勿論、組込みシステムでは、組込みシステムの分野において公知のように、これらの成分の若干は省略される。分散型計算環境では、これらの成分の若干は、分散型計算の分野において公知のように、分離した物理マシン上にあることができる。
【１３０９】  メモリ８２０は、典型的には、高速揮発性ランダムアクセスメモリ（ＲＡＭ）、並びに読出し専用メモリ（ＲＯＭ）及び磁気ディスクドライブのような不揮発性メモリを含む。更に、メモリ８２０は、ソフトウェア８２１を含んでいる。ソフトウェア８２１は、オペレーティングシステム８２１２と通信するアプリケーションソフトウェア８２１１、及びＩ／Ｏサブシステム８２１３と通信するオペレーティングシステム８２１２の層にされている。Ｉ／Ｏサブシステム８２１３は、通信バス８６０によって、ユーザインタフェース８３０、双対プロセッサ８４０、及び通信インタフェース８５０と通信する。
ユーザインタフェース８３０は、ディスプレイモニタ８３１を含んでいる。
通信バス８６０は、ＣＰＵ８１０、メモリ８２０、ユーザインタフェース８３０、グラフィックスプロセッサ８４０、及び通信インタフェース８５０を通信的に相互接続する。
メモリ８２０は、空間的にアドレス可能なメモリ（ＳＡＭ）を含むことができる。ＳＡＭは、ＳＡＭ内に格納されている空間的に格納されたデータを、メモリ内のそのアドレスによってではなく、その空間座標によって検索できるようにする。単一のＳＡＭ間合せ操作で、指定された空間ボリューム内の全てのデータを識別し、単一のクロックサイクル中に多数の数学的比較を遂行することができる。の米国特許第４，９９６，６６６号“”（１９  ）にＳＡＭの詳細が記載されているので参照されたい。
【１３１０】  双対プロセッサ８４０のアドレス空間は重畳させることができ、またメモリマッピングの分野においては公知のように、メモリ８２０のアドレス空間に接近させ、及び／または該アドレス空間から切り離すことができる。例えば、もしＣＰＵ８４０が所定のアドレスにおける加速されたグラフィックスポートへ書込み、グラフィックス双対プロセッサ８４０が同一の所定アドレスを読出すものとすれば、ＣＰＵ８１０はグラフィックスポートへ書込みつつあり、グラフィックスプロセッサ８４０はこのようなグラフィックスポートから読出しつつあると言うことができる。
【１３１１】  グラフィックスプロセッサ８４０は、グラフィックスパイプラインとして実現され、このパイプライン自体は多分１つまたはそれ以上のパイプラインを含む。図Ｊ３は、本発明を組み込んだ３Ｄグラフィックスパイプライン８４０内の成分及びデータの流れを示す高レベルブロック図である。３Ｄグラフィックスパイプライン８４０は、コマンド取り出し及びデコードブロック８４１、ジオメトリブロック８４２、モード抽出ブロック８４３、分類ブロック８４４、セットアップブロック８４８、選別ブロック８４６、モード注入ブロック８４７、フラグメントブロック８４８、テクスチャブロック８４９、フォングブロック８４Ａ、ピクセルブロック８４Ｂ、バックエンドブロック８４Ｃ、及び分類、多角形、テクスチャ、及びフレームバッファメモリ８４Ｄ、８４Ｅ、８４Ｆ、８４Ｇを含んでいる。メモリ８４Ｄ、８４Ｅ、８４Ｆ、８４Ｇは、メモリ８２０の一部であることができる。
【１３１２】  図７は、図Ｊ３のパイプラインの方法・流れ図である。図Ｊ１１及び１２は、本発明を組み込んだ３Ｄグラフィックスパイプラインの代替実施の形態である。
コマンド取り出し及びデコードブロック８４１は、グラフィックスポートを通してのホストコンピュータとの通信を処理する。このブロック８４１は、その入力を一連のパケットに変換してメモリブロック８４２へ渡す。殆どの入力ストリームは、ジオメトリカルデータ、即ち線、点、及び多角形からなる。これらのジオメトリカルオブジェクトの記述は、カラー、表面法線、テクスチャ座標等々を含むことができる。入力ストリームは、ライティング、混合モード、及びバッファ機能のような描写機能をも含む。
ジオメトリブロック８４２は、４つの主要タスク、即ち、変換、全ての多角形の三角形への分解、クリッピング、及びグローシェーディングのための頂点毎のライティング計算を処理する。
【１３１３】  ジオメトリブロック８４２は、到来するグラフィックスプリミティブを均一座標空間（“ワールド空間”）へ変換する。次いでブロック８４２は、プリミティブをビューイングボリューム（“円錐台”）にクリップする。ビューイングボリュームを定義する６つの面（左、右、上、下、前、及び後）に加えて、サブシステムは６つのユーザ定義可能なクリッピング面を提供する。クリッピングの後に、ジオメトリブロック８４２は、３つより多くの頂点を有する多角形を複数組の三角形に分割し、処理を簡易化する。
【１３１４】  最後に、もしフレーム内にグローシェーディングが存在すれば、ジオメトリブロック８４２は、フラグメントブロック８４８がシェーディングを遂行するために使用する頂点カラーを計算する。
モード抽出ブロック８４３は、データストリームを３つの部分、即ち頂点及びその他の全てに分解する。頂点は分類ブロック８４４へ送られる。その他の全て（光、カラー、テクスチャ座標等）は、モード注入ブロック８４７によって検索できる多角形メモリ８４Ｅ内の場所に格納される。多角形メモリ８４Ｅは二重緩衝されているので、モード注入ブロック８４７が１つのフレームのためのデータを読出している間に、モード抽出ブロック８４３は次のフレームのためのデータを格納することができる。
【１３１５】  多角形メモリ内に格納されているモードデータは３つの主要カテゴリ、即ち、フレーム毎のデータ（例えば、ライティング）、プリミティブ毎のデータ（例えば、材料特性）、及び頂点毎のデータ（例えば、からー）に分けられる。モード抽出及びモード注入ブロック８４３、８４７は、効率を最適化するために、これらのカテゴリを更に分割する。
【１３１６】  各頂点毎に、モード抽出ブロック８４３は、頂点データ及び多角形メモリ８４Ｅを指し示すポインタ（“カラーポインタ”）を含むパケットを分類ブロック８４４へ送る。パケットは、頂点がある点（ある線の端点、またはある三角形の隅）を表しているか否かを指示するフィールドをも含んでいる。頂点は、それらがパイプライン内へ送給された順序と厳格に同一の時間順番順序で送られる。パケットは、現在の頂点が所与のプリミティブ内の最後の頂点を形成しているか否か、即ち、それがプリミティブを完了させるか否かをも指定する。三角形ストリップ（“ファン”）及び線ストリップ（“ループ”）の場合には、頂点は隣接するプリミティブの間で共用される。この場合、パケットは、各プリミティブ内の他の頂点をどのように識別するかも指示する。
【１３１７】  分類ブロック８４４は、モード抽出ブロック８４３から頂点を受け、得られた点、線、及び三角形をタイルによって分類する。（タイルは、後述するデータ構造である。）二重緩衝分類メモリ８４Ｄにおいては、分類ブロック８４４は、グラフィックスプリミティブを表す頂点の１つのリスト、及び１組のタイル指示子リスト（フレーム内の各タイル毎に１つのリスト）を維持する。あるプリミティブを完了させる頂点を受けると、分類ブロック８４４はどのタイルにプリミティブが接触しているかを調べる。プリミティブが接触している各タイル毎に、分類ブロックはその頂点を指し示すポインタをそのタイルのタイルポインタリストに追加する。
【１３１８】  あるフレーム内の全てのジオメトリの分類を終了すると、分類ブロック８４４はデータをセットアップブロック８４５へ送る。各分類ブロック出力パケットは完了プリミティブを表す。分類ブロック８４４はその出力をタイル毎の順序で、即ち、所与のタイルに接触している全てのプリミティブ、次いで次のタイルに接触している全てのプリミティブ、等々で送る。従って、分類ブロック８４４は、同じプリミティブを多数回（それが接触している各タイル毎に１回）送ることができる。
セットアップブロック８４５は、線及び三角形のための空間導関数を計算する。ブロック８４５は、１つのタイルの価値データ、１つのプリミティブを一時に処理する。ブロック８４５は、完了すると選別ブロック８４６へデータを送る。
【１３１９】  またセットアップブロック８４５は、スティップルされた線を分離したラインセグメント（各々が方形領域）に分割し、タイル内の各プリミティブ毎の最小ｚ値を計算する。
【１３２０】  セットアップブロック８４５からの各パケット出力は、１つのプリミティブ、即ち三角形、線分、または点を表す。
選別ブロック８４６は、１つのタイルの価値データを一時に受け、その処理を２つのステップ、即ちＳＡＭ選別及びサブピクセル選別に分割する。ＳＡＭ選別は、先に処理済みのジオメトリに完全に隠されるプリミティブを破棄する。サブピクセル選別は、残余の（部分的に、または完全に見える）プリミティブを取り、可視フラグメントを決定する。サブピクセル選別は、複数のフラグメントの１つのスタンプの価値（以下に、“可視スタンプ部分”という）を一時に出力する。（スタンプは、後述するデータ構造である。）
図Ｊ９は、選別ブロック８４６が、部分的に隠蔽された三角形から、どのようにしてフラグメントを発生するかを示している。選別ブロック８４６によって発生された可視スタンプ部分は、たとえ複数のプリミティブがスタンプに接触しているとしても、単一のプリミティブだけからのフラグメントを含む。従って、図において、出力ＶＳＰは、グレーの三角形だけからのフラグメントを含む。白い三角形のチップによって形成されたフラグメントは、別のＶＳＰ内に送られ、２つのＶＳＰのカラーは後刻ピクセルブロック８４Ｂにおいて組合される。
【１３２１】  ＶＳＰ内の各ピクセルは、所与のフラグメントがピクセルのどの程度を覆っているかを決定するために、複数のサンプルに分割される。ピクセルブロック８４Ｂは、それがフラグメントを混合してそのピクセルの最終カラーを発生する時にこの情報を使用する。
【１３２２】  モード注入ブロック８４７は、多角形メモリ８４Ｅからブロックモード情報（カラー、材料特性等）を検索し、それを要求に応じて下流へ渡す。帯域幅を節約するために、個々の下流ブロックは、最近使用されたモード情報をキャッシュする。モード注入ブロック８４７は、どの情報が下流でキャッシュされたかを追跡し、必要な情報だけを送る。
【１３２３】  フラグメントブロック８４８の主作業は、補間である。ブロック８４８は、グローシェーディングのためのカラー、フォングシェーディングのための表面法線、及びテクスチャマッピングのためのテクスチャ座標を補間する。また、もしバンプマップが使用中であれば、バンプマッピングアルゴリズムに使用するための表面接線をも補間する。
フラグメントブロック８４８は、重心係数を使用して透視補正された補間を遂行する。
テクスチャブロック８４９は、テクスチャマップをピクセルフラグメントに適用する。テクスチャマップは、テクスチャメモリ８４Ｆ内に格納されている。上述した他のメモリ記憶装置とは異なって、テクスチャメモリ８４Ｆは単一緩衝されている。このメモリは、グラフィックスポートインタフェースを使用してメモリ８２０からロードされる。
【１３２４】  テクスチャは、ｍｉｐマップされている。即ち、各テクスチャは、異なる詳細レベルの一連のテクスチャマップからなっており、各マップは眼点から所与の距離におけるテクスチャの見掛けを表している。所与のピクセルフラグメントのためのテクスチャ値を再生するために、テキストブロック８４９は、テクスチャマップから三線形補間を遂行して正しい詳細レベルを近似する。テクスチャブロック８４９は、異方性補間のような他の補間をも遂行する。
テクスチャブロック８４９は、補間済みのテクスチャ値（一般的には、ＲＧＢＡカラー値として）をフラグメント毎にフォングブロック８４Ａへ供給する。バンプマップは、特別な種類のテクスチャマップを表す。カラーの代わりに、バンプマップ内の各テクセルは、高さフィールド勾配を含む。
フォングブロック８４Ａは、各ピクセル毎にフォングシェーディングを遂行する。このブロックは、モード注入ブロック８４７によって供給された材料及びライティング情報、テクスチャブロック８４９からのテクスチャカラー、及びフラグメントブロック８４８によって生成された表面法線を使用して、そのフラグメントの見掛けのカラーを決定する。もしバンプマッピングを使用中であれば、フォングブロック８４７は、シェーディングの前にテクスチャブロック８４９からの補間済みの高さフィールド勾配を使用してそのフラグメントの表面法線を動揺させる。
【１３２５】  ピクセルブロック８４Ｂは、各フラグメントが独立カラー値を有しているＶＳＰを受ける。ピクセルブロック８４Ｂは、各ピクセル内の各サンプルに対するシザー試験、アルファ試験、ステンシル操作、深さ試験、混合、ディザリング、及び論理演算を遂行する。ピクセルブロック８４Ｂは、終了した複数のピクセルのタイルの価値を累積すると、各ピクセル内のサンプルを混合し（それによって、ピクセルのエイリアス除去を遂行し）、バックエンド８４Ｃへ送ってフレームバッファ８４Ｇ内へ記憶させる。
【１３２６】  図Ｊ１０は、ピクセルブロック８４Ｂが、どのように複数のフラグメントのあるスタンプの価値を処理するかを示している。この例では、ピクセルブロックは２つのＶＳＰを、即ちグレーの三角形からの１つと、白い三角形からの１つを受ける。ピクセルブロック８４Ｂは、フラグメントと背景カラーとを混合して最終ピクセルを発生する。ブロック８４Ｂは、それがピクセルのどの程度を覆っているかに従って、より正確に言えば、それが覆っているサンプルの数によって各フラグメントに重み付けする。前述したように、これは簡単な例である。本装置は、遙かに複雑な混合を遂行する。
【１３２７】  （ピクセルオーナーシップ試験は、ウィンドウシステムの一部であり、バックエンド８４Ｃに残されている。）
バックエンドブロック８４Ｃは、ピクセルブロック８４Ｂから、複数のピクセルの１つのタイルの価値を一時に受け、それらをフレームバッファ８４Ｇ内へ格納する。またバックエンド８４Ｃは、複数のピクセルのあるタイルの価値をピクセルブロック８４Ｂへ送り返す（何故ならば、特定のフレームバッファ値は、フレームからフレームへ生き残ることができるからである）。例えば、ステンシルビット値は、多くのフレームにわたって一定に留まることができるが、これらを全てのフレームにおいて使用することができる。
【１３２８】  フレームバッファ８４Ｇを制御することに加えて、バックエンドブロック８４Ｃは、ピクセル・オーナーシップ試験、２Ｄ描写を遂行し、仕上がったフレームを出力デバイスへ送る。ブロック８４Ｃは、フレームバッファ８４Ｇとモニタ８３１及びビデオ出力との間のインタフェースを提供する。
【１３２９】  ・ピクセルブロック
ピクセルブロック８４Ｂは、３Ｄパイプライン８４０内のバックエンド８４Ｃの前の最後のブロックである。それは、フラグメント毎の操作遂行の責を負っている。更に、ピクセルブロック８４Ｂは、エイリアス除去のためにサンプル累積を遂行する。
【１３３０】  ピクセルブロック８４Ｂの前のパイプラインステージは、菣ꪃ菣蚃苣隃苣뚼볯낼臣覤迦馁苣芀裥麡菣궃菣꾂볯钼볯꾁胣蒐苣ꒂ菣躯臣鞃菣龃菣ꎂ菣銂迥蚛臣讂胣뢁裥隃菣莃苣颼볯隼臣膀裥麡菣궃菣꾂臣覂臣螃菣뾂苣뾂苣ꮃꃩꮁ迥醁胣辏蛥閁苣讂苣ꆃ菣뢂臣蒯룤鞁臣蒁菣ꪃ菣蚃苣隃臣ꢃ裥銂럦낱臣讂胣뢁裥隃菣莃苣颼볯隼臣뚼볯낼苣龔裦馁苣芀菣꾂苣膃菣誏臣閃苣뎃苣隃菣莃苣ꚃ菣莃菣颼볯馼胣颼볯ꆼ苣뚼볯낼苣鞏臣膀臣貂臣貂胣閃菣낂菣뎃菣꺁菣꾂苣膃菣ꪃ菣낂迥뎁菣ꒂ菣ꎂ菣낂臣겲苣ꂲ臣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯鎼볯醼胣㲑䐯噉‾뎛볯銼臣膀菣꾂苣ꮃ菣궃菣꾂볯钼볯薆臣邈裥誏臣螃菣뾂臣膵苣銂ꓧ馁菣궃菣꾂鯥ꞁ臣讂胣隃菣莃苣颼볯ꊼ臣膀볯ꦼ볯꾼볯醼볯膀藥鮊菣ꎂ菣뾂볯銼볯貼迥뎁뻥ꆁꇨ鞈볯鎼볯膀볯钼볯銂郥鎂臣蒁苣芀菣꾂苣ꮃ菣궃菣꾂볯钼볯꾁胣ꖅ諥鞃菣뮂菣떂볯馼볯膀苣ꎃ菣랂菣銼볯邼胣銼볯邼胣誏臣놷臣鲣雩ꚃ菣莃菣銼볯邼苣뒛臣ꮐ苣ꞁ臣讂胣뒛臣膀菣꾂苣ꮃ菣궃菣꾂볯钼볯꾁胣랂苣벃胣릂菣ꎂ菣鞃菣膀苣ꮃ菣ꆂ胣ꮂ菣벃胣誏臣릂菣뎃苣ꮃ볯몼臣蒐ꧨ鎨菣讃菣袃볯ꆼ볯膀볯ꊼ볯膀볯ꎼ볯膀볯꒼볯膀볯ꖼ볯膀룤뎁臣랷郥膀菣ꎂ苣ꪃ菣낂胣誏臣隫郧钼껧꺁郥ꚃ菣莃菣銼볯邼胣銼볯邼胣銼볯邼苣ꮐ苣鎼볯醃苣鞃菣ꒂ菣銼볯邼臣芁苣芀苣뎃菣ꮃ꿦꺁苣蚃菣랂菣誏臣骽菣莃菣ꆂ볯ꦼ볯膀苣뎃菣ꮃ꿦꺁苣ꦃ菣邃菣閃苣銼볯邼胣钃苣뮂菣몇諥ꚃ菣莃菣銼볯邼胣誏臣钃苣뮂菣躯臣뾂苣ꮃ菣莃菣ꆂ볯ꮼ볯节胣钃苣뮂菣隃菣莃苣颼볯ꊼ臣讧裦銂迦ꦊ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鎼볯醀⼼䥄㹖†鯥ꪼ볯ꮁ臣蒁臣膀藥鮊볯ꦼ볯꾼볯醼볯膽胣誏臣銼볯醼뷯꾁胣鶁苣麁苣膀菣ꦂ菣낂菣궃菣꾂볯钼볯誏臣ꊃ菣覃돦ꖅ菣궃菣꾂볯钼볯讁苣꺁藥鮊苣鞏臣讂胣ꖅ諥ꚼ볯ꚼ볯銼볯邼뷯꾁苣ꦃ菣薾臣財裥銼볯邼臣몇諥鞁胣ꖅ諥ꚼ볯ꚼ볯銼볯邼뷯꾁藥鮊菣ꎂ菣뾂볯銼볯뢁蟥鮊臣讂胣㲂牢ਾ†藥鮊菣ꎂ菣뾂臣膀菣꾂苣ꮃ蟥鮊菣讃菣袃볯颼볯膀菣莃苣ꢂ菣覃菣궃菣꾂볯钼볯膀迥뎁볯뎼볯薾臣財裥銼볯邼臣몇諥馁苣芀戼㹲 ꖅ諥鞃菣뮂菣떂볯馼볯꾁胣薾臣財裥銼볯邼胣銼볯邼臣覂藥鮊苣鞏臣膀苣蚃苣莃菣ꮃ迥뎁菣벃菣궂菣莃苣ꖃ볯隼볯膀볯鞼볯膀룤뎁臣놷臣鲣雩ꚃ菣莃菣銼볯邼迥뎁볯꒼菣ꒂ菣ꦃ苣뎃볯궼볯뢁蟥鮊臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鎼볯醀⼼䥄㹖†菣ꒂ菣ꦃ苣뎃볯궼볯꺁鳦鶈臣릂菣벃苣ꞁ臣���苣뚂菣ꚩ꣩ꚃ菣莃菣銼볯邼臣膀藥鮊菣궃苣莃苣銼볯邼臣覂藥鮊苣鞏臣膀苣蚃苣莃菣ꮃꧨ鎨菣讃菣袃볯ꊼ볯뢁蟥鮊臣讂胣ꚃ菣莃菣銼볯邼臣ꊂ菣閃苣ꚩ꣩ꚃ菣莃菣銼볯邼臣몇諥鞁胣ꚃ菣莃菣銼볯邼臣ꮂ菣벃ꧨ鎨菣讃菣袃臣몇諥鞁胣ꮂ菣벃ꧨ鎨菣讃菣袃臣릂菣뎃苣ꮃ볯骽ꧨ鎨菣讃菣袃볯ꖼ볯뢁蟥鮊臣膀菣讃菣袃볯ꖼ볯꾁럦袐볯螃苣뚂菣뎃苣ꚃ菣莃菣銼볯邼臣몇諥馁苣芀苣蚃菣랂菣込뷯ꚩ꣩ꚃ菣莃菣銼볯邼臣膀苣뎃菣ꮃ꿦꺁뷯誏臣릂菣뎃苣ꮃ菣莃菣ꆂ볯ꦼ볯ꢁ苣骀뿤鞁胣랷郥込菣ꎂ苣ꪃ菣낂菣讃菣袃볯ꚼ볯誏臣隫郧钼껧ꚃ菣莃菣銼볯邼臣놅臣떂菣鞃菣躯臣ꮂ菣벃菣莃菣ꆂ볯ꪼ볯ꢁ胩ꆿ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鎼볯醀⼼䥄㹖†菣ꒂ菣ꦃ苣뎃볯궼볯薆臣邈裥膀跥ꆁ胣랂苣벃胣릂菣ꎂ菣鞃菣膀苣ꮃ菣ꆂ胣ꮂ菣벃胣誏臣릂菣뎃苣ꮃ볯骽臣蒐ꧨ鎨菣讃菣袃볯ꆼ볯膀볯ꊼ볯膀볯ꎼ볯膀볯꒼볯膀볯ꖼ볯膀迥뎁럦袐胣螃苣뚂菣뎃苣膀迥뎁ꯨ蚐볦鞮臣蒐菣讃菣袃볯ꚼ볯膀볯Ꞽ볯膀볯ꢼ볯꾁藥ꚁ胣릂菣ꎂ菣鞃菣誏臣ꊃ菣覃苣ꎃ菣랂菣銼볯邼胣銼볯邼臣覂藥鮊苣鞏臣ꚁ臣讂胣릂菣뎃苣ꮃ볯銼ꧨ鎨菣讃菣袃볯ꖼ볯꾁胣놷臣鲣雩ꚃ菣莃菣銼볯邼臣覂苣ꖅ諥銂迥醁臣蒁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯鎼볯閼胣㲑䐯噉‾邃菣꾂苣뎃菣뒁臣醐臣ꎁ臣膀菣꾂苣ꮃ蟥鮊菣讃菣袃볯颼볯꾁胣떂菣鞃菣躯臣骽苣蚃菣랂菣誏臣ꮂ菣벃菣莃菣ꆂ볯ꦼ볯膀볯ꪼ볯膀룤뎁臣钃苣뮂菣躯臣邃菣閃苣銼볯邼臣骀뿤馁苣芀菣꾂苣ꮃ꿦꺁菣莃菣ꆂ볯ꮼ볯ꢁ菣莃苣ꢂ菣覃菣궃菣꾂볯钼볯ꢁ臣骀뿤鞁郥蚁胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鎼볯醀⼼䥄㹖†룤낿臣龁苣蚁臣膀菣꾂苣ꮃ菣궃菣꾂볯钼볯꾁菣ꦂ菣낂胣ꊃ菣覃돦ꖅ胣誏臣邃菣꾂苣뎃菣隃菣莃苣颼볯鞼胣颼볯ꆼ胣颼볯ꎼ臣骀뿤鞁臣蒁苣芀苣誂ꧨ鞁臣낿臣貂臣膀菣꾂苣ꮃ菣궃菣꾂볯钼볯꾁胣ꊃ菣覃돦ꖅ迥뎁菣ꦂ菣낂菣궃菣꾂볯钼볯膀볯钼볯讁苣ꖅ諥銂迥醁苣芀菣꾂苣ꮃ菣궃菣꾂볯钼볯꾁胣뚼볯낼迥뎁菣벃菣ꢳ藥隃菣莃苣颼볯鞼臣覂臣ꊃ菣覃菣벃苣銂迥醁胣뺁臣閃苣뎃苣隃菣莃苣颼볯ꆼ臣覂볯뎼볯꺁臣膂臣閃菣낂菣뎃菣ꮂ菣벃苣鞏臣ꚁ臣讂胣袼菣ꦂ菣낂菣궃菣꾂볯钼볯꾁胣뚼볯낼臣龁苣꺁菣ꦃ苣ꆃ菣袃꿦꺁럦閁胥膀臣龁臣릂菣뎃苣ꮃ胥銂뻤ꚵ臣讂臣ꢁ苣ꞁ臣讂胣覼볯뎼볯꺁臣膂臣閃菣낂菣뎃菣ꮂ菣벃臣膀볯뎼볯ꢁ郥肸臣蚠뫥ꞁ菣꾂苣ꮃ菣궃菣꾂볯钼볯ꮁ裥肝臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣���醼볯鎼볯醀⼼䥄㹖†菣꾂苣ꮃ菣궃菣꾂볯钼볯꾁胣궶賦鞁臣蒁苣ꊃ菣覃苣莃菣ꎂ菣낂臣鎾臣ꚁ郥꾏ꛨ떂菣鞃菣躯臣螃菣뾂苣ꚇ郧馁苣芀菣꾂苣ꮃ菣궃菣꾂볯钼볯貁迧ꢜ臣뾂苣ꮃ臣龁苣꺁藥ꚁ臣릂苣뎃菣꺁蟥蚐苣芵뫤馁苣ꢁ胣鶁苣꾁臣꺁苣ꒂ菣꺁臣膂臣鮊菣벃胣骽迥뎁苣蚃菣랂菣邃菣閃苣뢁蟥鮊臣讂苣ꮁ菣꾂苣ꮃ蟥鮊菣讃菣袃볯颼볯ꮁ뿤랏臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鎼볯醀⼼䥄㹖†菣꾂苣ꮃ蟥鮊菣讃菣袃볯颼볯꾁胣钃苣뮂菣떂菣鞃菣銂蟥蚐臣ꚁ菣꾂苣ꮃ臣龁苣꺁苣ꦃ菣膀볯誏臣릂菣뎃苣ꮃ胥銂铧邈臣讂胣鎁苣覂臣钃苣뮂菣ꒀ臣邃菣꾂苣뎃菣隃菣莃苣颼볯ꎼ臣膀苣貂胣隃菣莃苣颼볯ꎼ臣閃菣벃菣邃菣閃苣颼볯Ꞽ臣龁苣꺁菣ꊃ菣뎂菣袃菣벃菣銂鳦鞁臣蒁苣芀菣莃苣ꢂ菣覃菣궃菣꾂볯钼볯꾁胣钃苣뮂菣隃菣莃苣颼볯ꊼ臣袂苣뢂苣ꆃ菣ꪃ볯뚼볯낼볯꺁迦馆臣龁苣ꮁ迧뾂苣ꮃ菣莃菣ꆂ苣隺若馁苣芀臣貂臣膀菣것菣ꂃ菣莃菣ꆂ볯钼볯讁苣꺁韦颭苣ꦃ菣膀뷯ꎼ胣誏臣릂菣뎃苣ꮃ胥꺁菣벃菣ꎂ菣낂苣ꮐ臣鞾苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯鎼볯馼胣㲑䐯噉‾肸껥붖臣ꊽ藦ꞁ臣膀苣뎃菣莃菣떂菣鞃菣躯臣骽胣릂菣뎃苣ꮃ胣誏臣ꮂ菣벃菣莃菣ꆂ볯ꦼ볯膀볯ꪼ볯꾁뫤趇럧鶡臣貂臣蒁苣芀뻥ꎁ臣膀菣꾂苣ꮃ蟥鮊菣讃菣袃볯颼볯貁볯ꒁ臣뾂苣ꮃ苣邃菣꾂苣뎃菣隃菣莃苣颼볯ꎼ臣膀臣ꚁ臣讂雩ꮁ胣놷臣誏臣랷郥ꚃ菣莃菣銼볯邼胣銼볯邼臣견볯꺁苣ꒂ菣뢁鯦벾苣鎁臣貁臣趁苣芀苣뎃菣ꮃ꿦꺁苣ꦃ菣膀뷯誏臣릂菣뎃苣ꮃ菣莃菣ꆂ볯ꦼ볯膀볯ꪼ볯꾁胣醼臣꺁苣ꒂ菣꺁뻤ꒀ菣벃苣銂ꃦ趴臣讂苣蚁臣膍裥ꮁꓥ趁臣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯鎼볯邼胣㲑䐯噉‾蒐苣ꒂ菣躯臣膀볯蒵臣钃苣뮂菣躯臣骽胣릂菣뎃苣ꮃ胣誏臣ꮂ菣벃菣莃菣ꆂ볯ꮼ볯节귥ꢜ臣ꚁ臣讂胣鎁苣覂臣钃苣뮂菣躯臣邃菣閃苣銼볯邼臣膀菣莃苣ꢂ菣覃菣궃菣꾂볯钼볯銂苣뎃苣閃苣벃苣馁苣궸雩風蛦薣뷧ꞁ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯钼볯醀⼼䥄㹖†菣꾂苣ꮃ菣궃菣꾂볯钼볯꾁胣ꊃ菣覃돦ꖅ菣궃菣꾂볯钼볯讁苣邃菣꾂苣뎃菣隃菣莃苣颼볯ꎼꇨ趁臣ꖋ맥꺁菣놂菣袃苣节迥醁苣芀藥鮊菣ꎂ菣뾂볯銼볯꾁胣鎁苣覂臣醃苣莃菣銂菣莃苣ꢂ菣覃볯钼볯袼臣袅迥誂뻥ꆁꇨ鞈볯誸臣ꦁ裥ꮁ룦鞁胣邃菣꾂苣뎃菣颼볯ꎼ臣醃苣莃菣銂迥醁臣蚠뫥ꞁ蟥蚐臣讂胣ꖋ맥꺁菣놂菣袃臣膀菣꾂苣ꮃ蟥鮊菣讃菣袃볯颼볯袼蛥꺁藥鮊뻥ꆁꇨ鞈볯뢁苣膀苣貂苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯鎼볯銼胣㲑䐯���‾誸뿨鞁臣袂臣ꮁ胣钃苣뮂菣隃菣莃苣颼볯ꊼ臣膀菣벃菣ꢳ藥誏臣閃苣뎃苣隃菣莃苣颼볯鞼迥뎁볯钼볯讁苣ꖅ諥銂迥醁苣芀臣貂苣꺁볯ꒁ臣ꖅ諥銂触蚁臣膂臣膀볯ꒁ臣ꖅ諥薾臣財裥貁귥ꢜ臣ꚁ臣讂胣ꊃ菣覃돦ꖅ菣궃菣꾂볯钼볯讁苣꺁菣벃苣醃苣莃菣꾁볯뎼볯薾臣財裥銼볯邼臣醐臣蒁胣閃苣뎃苣隃菣莃苣颼볯ꆼ臣覂臣閃菣낂菣뎃菣ꮂ菣벃볯誏臣膀苣鞁迥붃賥閁苣ꚁ臣貂臣膀럦閁臣龁臣릂菣뎃苣ꮃ볯醃苣莃菣꾁苣ꦃ菣薾臣財裥銼볯邼臣醐臣蚁胣ꊃ菣覃돦ꖅ菣궃菣꾂볯钼볯꾁胣鎁苣覂臣螃菣뾂菣놂菣袃苣ꖅ諥ꚼ볯ꚼ볯銼볯邼蛥ꮁ藩꺽臣讂胣ꖅ諥閃苣ꮃ苣銼볯邼臣醃苣莃菣颃菣肃菣銂ꫨ릁胣邃菣꾂苣뎃菣隃菣莃苣颼볯ꎼꇨ趁臣螃菣뾂苣邃菣꾂苣뎃菣隃菣莃苣颼볯ꎼ臣膀苣膀臣龁菣꾂苣ꮃ菣궃菣꾂볯钼볯貁뿥膦臣馁苣螃菣뾂菣놂菣袃苣뚼볯낼뻥ꆁꇨ鞈볯钼볯뢁胩讂胣ꊃ菣覃돦ꖅ菣궃菣꾂볯钼볯讁苣鞏臣龁菣놂菣袃臣Ꞥ菩蚈臣膀볯뎼볯薾臣財裥銼볯邼ꇨ趁臣芁苣膀诨늹臣醃苣莃菣ꂁ臣貁菣莃苣ꢂ菣覃菣궃菣꾂볯钼볯뢁냥讁苣膀诨늹臣醃苣莃菣꾁볯뎼볯薾臣財裥銼볯邼蛥뢁苣钃菣閁苣膀臣鞁臣邃菣꾂苣뎃菣誏臣钃苣뮂菣몇諥ꚃ菣莃菣颼볯ꎼ胣銼볯邼臣膀苣貂苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯鎼볯鎼胣㲑䐯噉‾ꖻ룤ꮁ胣뾂苣ꮃ苣隺若馁苣薿ꛨꞀ迥뎁菣ꮂ菣몂菣꺁ꛦ膦苣겪飦馁苣芀藥讞髧ꪁ迦馆苣벃苣뎃苣꾁胣袼볯覼苣鞁뿥膦臣覂臣膀苣ꦃ菣膀뷯誏臣릂菣뎃苣ꮃ菣莃菣ꆂ볯ꪼ볯膀볯ꦼ볯銂臣貂苣꺁苣ꪃ苣ꒀ臣鶈鳦隌臣膀볯銼볯节臣薿ꛨꪁ苣낁胣醼臣뺁臣꾁ꓨ낕臣貃駦ꒂ菣벃苣銂볯ꒁ臣龁臣螤闦꺁菣莃菣ꆂ볯ꪼ볯膀볯ꦼ볯뢁뷯貽뷯鞁胣袼볯覼苣ꪂ菣袃菣銂迦馆臣膀볯钼볯趆뫥芽뷯钽臣膀볯閼볯ꖈ臣뢂苣ꆃ菣ꪃ苣辏蛥鞁胣袼볯覼껥蚺迥뎁菣ꪃ菣鞃臣趓뷤銂鳦馁苣鎁臣貁臣趁苣芀苣鞁뷯貽뷯趓뷤袼볯覼臣Ꚃ苣뎃菣Ꚃ藥鎽苣ꮂ菣벃臣貂臣膀臣꺁菣莃菣ꆂ臣龁苣꺁苣ꪃ苣ꪃ菣낂鏦鲽臣薿ꛨꪁ臣讁苣ꖟ苣ꪁ臣芀苣鞁뷯貽뷯貁苣ꎂ菣覃苣銂菩蚈髧ꮁ苣邃菣馁苣낁胣꾂菣ꊂ臣薿ꛨꞁ臣趂臣芀鯦ꮁ胣鶈鳦隌迥뎁뷯貽뷯袼볯覼鏦鲽臣蚀臣蚠뫥ꞁ駧龔臣讂臣ꢁ臣ꞁ臣讂胣뎍臣膀볯骤裥覼苣ꎂ菣覃苣ꢅ뷤ꮁ꿥馁苣芽뷯钽臣骶臣ꚁ胣Ꚃ苣뎃菣Ꚃ臣肸菩蚈臣꾂菣ꊂ菣뎃苣貁귥ꢜ臣讂臣ꢁ臣ꞁ臣讂胣Ꚃ苣뎃菣Ꚃ藥鎽苣ꮂ菣벃臣讂苣ꪂ菣袃菣趉臣芽뷯钽臣膀苣뚂菣ꚩ꣩銂뿥膦臣鞁臣蒁胣뒕裥誏臣몟���隌臣膀苣ꆃ菣뢂臣뾂苣ꮃ菣莃菣ꆂ蛥ꮁ菣벃菣邃菣꾂臣貂苣鮚臣膀菣莃苣ꢂ菣覃菣궃菣꾂볯钼볯ꮁ苣ꎁ臣芁ꇨ馁苣鎁臣貁臣趁苣芀苣ꪂ菣袃菣貾臣芽뷯钽迥뎁苣ꎂ菣覃苣꺁룤ꢃ苣ꮂ菣벃臣讂뷯貽뷯膀臣龁臣ꮐ臣貂苣몟뫦隌臣膀菣ꒂ菣ꦃ苣뎃蛥ꮁ菣꾂苣膃菣隌臣貂臣鞃菣龃菣ꎂ菣ꢁ臣ꚁ껥뺏臣貂苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯鎼볯钼胣㲑䐯噉‾貐꟦ꮁ胣꾂菣ꊂ鏦鲽臣銼꣧麡臣蚈觥閁苣讂胣뢂苣ꆃ菣ꪃ觥꺁藥Ꚃ苣뎃菣Ꚃ苣ꪃ苣趓뷤꾁菣꾂苣ꮃ蟥鮊菣讃菣袃볯颼볯薆臣芁ꇨ閁苣膀苣ꎂ菣覃苣꺁룤ꢃ臣醁苣ꮂ菣벃臣讂볯誏臣込臣龁臣膀臣讂苣ꪂ菣袃菣貁迦馆臣貂臣貾臣몙ꇨ閁苣讂볯꾂菣ꊂ鏦鲽臣钃苣뮂菣隃菣莃苣醃苣鞃菣ꒂ菣薆臣芁ꇨ閁苣讂胣钃苣뮂菣隃菣莃苣颼볯ꊼ볯钃苣뮂菣몇諥ꚃ菣莃菣銼볯邼볯誏臣邃菣꾂苣뎃菣隃菣莃苣颼볯ꎼ臣ꆸ胨꾁胣趓뷤貁釥몇臣貂臣芙苧ꮁ胣蒁苣蒁苣ꪁ菣莃菣ꆂ臣龁苣꺁鯦벾臣麃苣꾂苣ꖟ臣ꚁ臣讂胣龮髩ꮁ胣邃菣꾂苣뎃菣隃菣莃苣颼볯ꎼ臣뢛뻨뾁菣릂苣銂뷤ꢔ臣ꚁ胣뾂苣ꮃ菣莃菣ꆂ苣ꪃ菣覃菣莃苣馁苣薿ꛨ貁臣讂臣Ꚑ臣銂뇦骮臣讂胣뾂苣ꮃ菣莃菣ꆂ臣ꪃ菣覃菣莃苣꾁胣芁苣閃菣벃菣꺁迦馆臣骤꟨ꊽ菣ꊃ菣颼볯ꖼ臣龁臣蚈ꇩꆃ菣ꪃ볯钼볯ꮁ苣벃菣벃菣궃菣銂苣龁苣馁ꃥ袐臣节駧龔臣鞾苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯鎼볯閼胣㲑䐯噉‾ꖋ맥꺁觧ꖈ臣뒠郥ꮁ臣膀菣ꒂ菣ꦃ苣뎃臣ꚃ菣뚂菣것菣ꂃ苣銼臣뺁臣꾁臣貂믤誸臣蚠곦閃菣벃菣ꮁ裥늉臣讂臣ꢁ臣ꞁ臣讂胣鎁苣꾁雦袄裥鮏臣ꮁ뗨ꂛ臣ꚁ胣뺁臣꾁ꓥ銧뷥ꆃ菣ꪃ볯钼볯뺁臣꾁裥麡菣ꊃ菣颼볯꒼臣ꪂ菣邃菣閃菣벃臣략鯥鞁臣몙铧鞁뻥讂胣鎾臣ꚁ胣貐臣ꚃ菣뚂菣것菣ꂃ臣ꊖ臣ꚁ胣뾂苣ꮃ臣醼鯥袂苣骤臣钃苣뮂菣隃菣莃苣颼볯ꊼ蛥銂꣨貂苣鎁臣貁臣誂뻥讂胣뾂苣ꮃ臣몇볤蚁鳦鶈臣芙苧ꮁ胣钃苣뮂菣隃菣莃苣颼볯ꊼ볯肜苣芁苣鶁臣ꪁ臣꾁胣钃苣뮂菣몇諥ꚃ菣莃菣銼볯邼볯貁胣辏蛥趉臣膀胢꾂菣ꊂ胥鶀苣ꢔ臣ꚁ苣ꒂ菣邃菣閃苣銼볯邼胣銼볯邼苣꾂菣ꊂ臣讂뿥膦臣芁苣鞾苣芀裧貾臣閃菣벃菣궸臣뾂苣ꮃ苣辏蛥馁苣龁苣ꮁ胣钃苣뮂菣ꮂ菣벃胣骽迥뎁苣蚃菣랂菣ꒀ臣閃菣벃菣邃菣閃苣ꆃ菣ꪃ볯钼볯讁苣ꪃ菣覃菣莃苣閁苣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯钼볯醀⼼䥄㹖†裥꺁ꗦ膂臣芁苣鶁臣ꪁ苣誃菣ꪂ臣膀뷯邃菣閃苣銼볯邼臣꾂菣ꊂ臣貂胣ꮂ菣벃迥뎁苣蚃菣랂菣邃菣閃苣銼볯邼胣銼볯邼臣鞃菣辏蛥ꒂ菣벃苣讁苣뾂苣ꮃ蛥뢁���벃菣閁苣讂駦ꮁ駧龔臣讂胣뎍臣膀苣ꒂ菣隺若꺁룤ꢃ臣鞁臣膀볯ꒁ臣鎁臣貁駧龔臣讂胣貃駦ꒂ菣벃苣貁菣것菣ꂃ菣莃菣ꆂ菣ꊃ菣颼볯Ꞽ臣覂苣ꪃ苣꺁臣膂臣꾏菨隌臣貂臣蒁臣蒁菣莃菣ꆂ蛥뢁菣벃菣邃菣꾂臣貂胣鶁臣ꚁ迥붃賥閁苣龁菣莃菣ꆂ볯ꮂ菣벃胣鶁苣뎁苣蚃菣랂菣ꮁ꿥鲿볯貁苣ꪃ苣閁苣讂胣钃苣뮂菣隃菣莃苣颼볯ꊼ苣誂룤膵臣醃苣鞃菣ꒂ菣릂菣벃苣꾁苣ꪃ苣薃ꃥ銂胩讂단銂단ꎁ臣蒁苣鎁臣讁苣膀臣貂苣꺁ꧦ붃髧붃諥銂鿧ꎁ臣蒁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯鎼볯鞼胣㲑䐯噉‾钃苣뮂菣隃菣莃苣颼볯ꊼ臣膀裥ꖝ臣讂苣뎃菣ꮃ臣骽胥ꢁ胣ꊗ귥떂菣鞃菣꺁臣貂苣ꢁ苣钯볨鞁胣ꦁ臣떂菣鞃菣銂뿤膌臣讂臣銂뇦骮臣讂胣钃苣뮂菣隃菣莃苣颼볯ꊼ臣膀菣벃苣閃菣벃菣꺁裥늉臣袂臣ꚁ铧颁뻥讂ꛥ閽臣讂苣ꦃ菣랷裦ꊂ菣膃菣ꆂ苣袃苣节鳦辰臣馁苣붃諥銂苣躸臣讂胣㲂牢ਾ菣벃苣讧胩㲠牢ਾ†菣떂菣鞃菣膀菣꾂苣ꮃ胣릂苣뎃菣膀迥뎁苣ꒂ菣㲫牢ਾ†곧醼臣螃菣뾂꟦ꂀ臣떂菣鞃菣ꞁ臣讂胣뚼볯낼蛥꺁郥钃苣뮂菣꾁胣螤闦꺁苣뎃菣ꮃ臣蚈觥閁苣讂胣肉룤꺁菣꾂苣ꮃ苣躽韃뷯베귥ꮁ裥늉臣讂臣膀볯ꒁ臣떂菣鞃菣꾁뷯誼뷯떂菣螃苣鎃苣ꞃ菣꺁볯ꒁ臣뺯뿥馁苣芀鯥ꪼ볯꾁胣肸껥붖臣ꊽ藦ꮁ臣醁苣떂菣鞃菣ꢁ菣꾂苣ꮃ迥뎁苣뾂菣鞃臣꺁雩芿苣몤臣ꚁ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯钼볯醀⼼䥄㹖†뷯誏臣趽臣뢁諦膀룤뎁臣ꦁ苣讨ꓥ辁臣膀臣鞁臣ꦁ臣떂菣螃苣鎃苣ꞃ菣銂苣뎃菣ꮃ臣鞁臣뢁諦馁苣讁臣膀藥ꚁ迥뺯菣궃苣莃苣颼볯邼蛥ꮁ菣궃苣ꦃ菣꾏菨ꞁ臣讂胣鞁臣鞁臣貁苣膀ꃦ邭胣떂菣鞃菣ꮂ苣뎃菣膀迥뎁苣뎃菣ꮃ뷤꺽臣膀ꓥ隌臣貂苣뺁臣몛껥閁苣讂胣膜闧芙臣躽胣趽胣ꮂ苣뎃菣膀迥뎁뷤꺽臣ꪃ苣莃菣芙臣뮂菣袃臣貂苣芀鯥ꪼ볯꾁胣肸껥붖臣ꊽ藦ꮁ苣讂鳧ꖕ駦꺁苣뎃菣ꮃꃦ邭胣ꮂ苣뎃菣膀迥뎁뷤꺽苣몤臣ꚁ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯钼볯醀⼼䥄㹖†郥떂菣鞃菣꾁胣鶁臣떂菣鞃菣꺁苣ꦃ菣뺁臣꾁苣ꮃ菣ꆂ胥꺁뷤貂臣貁迦馆菣궃苣ꦃ菣ꮁ臣蒁臣覤賥鞁臣鎁臣銂賦몤臣讂菣벃菣ꎂ菣莃菣銂鳦鞁臣蒁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯鎼볯邼胣㲑䐯噉‾ꆬ臣螃菣뾂꟦ꂀ臣릂苣뎃菣ꞁ臣讂胣릂苣뎃菣꾁胣芁苣ꒂ菣벃苣薆臣誽韃뷯骤蟩钃苣뮂菣베귥ꞁ臣讂胣肸껥붖臣ꊽ藦ꞁ臣膀苣뾂菣鞃臣膀볯쎒銼菣꾂苣ꮃꃩ龟臣芁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯鎼볯醼胣㲑䐯噉‾ꆬ臣螃菣뾂꟦ꂀ臣뾂苣ꮃ臣芁苣芀苣ꒂ菣꾁胣芁苣ꒂ菣벃苣薆臣袽韃뷯骤蟩릂苣���菣颠鿥ꞁ臣讂胣肸껥붖臣ꊽ藦ꞁ臣膀苣ꒂ菣꾁胣芁苣ꒂ菣벃苣薆臣颼韃볯릂苣뎃菣颠鿥膀跥ꆁ볯隼韃볯隼菣꾂苣ꮃꃩ龟臣芁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯鎼볯銼胣㲑䐯噉‾ꆬ臣螃菣뾂꟦ꂀ臣醃苣莃菣ꞁ臣讂胣醃苣莃菣꾁胣薃ꃥ銂믨膀臣讂臣膂臣讧胩ꞁ臣讂胣蒐菣놂菣袃臣膀菣莃菣벃臣鶁苣ꮁ뛧辁菣놂菣袃菣벃苣ꢁ臣覂臣讂胣颃菣肃菣꾁胣醃苣莃菣貁郥鎂臣蒁苣螃菣뾂臣讞迥뎁菣ꦂ菣麃菣袃苣螌ꓧ馁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯鎼볯鎼胣㲑䐯噉‾ꖻ룤ꮁ胣ꆬ臣讀胣꺁菣놂菣袃黥膀跥ꆁ胣閃菣벃菣讖꟥袼볯薽뷯覽뷯뾼볯銽뷯趽뷯覼胣閃菣벃菣讖꟥袅迥誂볯낼뷯薽뷯薽뷯莽뷯뾼볯薽뷯覽뷯뾼볯銽뷯趽뷯覼胣뾂苣ꮃ雩讧볯ꊼ뷯螽뷯躽볯뒼뷯覽뷯薽볯膀苣ꒂ菣讖꟥袅迥誂볯낼뷯薽뷯薽뷯莽뷯뾼볯薽뷯覽뷯뾼볯覽뷯薽볯膀菣것菣ꂃ뗧辂苣誏臣閃菣벃菣芵苣誂藥随苣袼볯躽뷯뾼볯銽뷯趽뷯₅膽뷯蒽†볯銽뷯蚽뷯钽뷯袽볯ꖼ뷯蒽볯ꚼ뷯膽뷯薽볯膀苣ꪃ苣袼볯貽뷯膽뷯覼胣钃苣뮂菣ꊃ菣覃苣ꎃ菣랂菣薅ꇥ袼뷯覽뷯薽뷯銈뷯辽뷯薽†볯膽뷯袽뷯뾼볯覽뷯貽볯膀苣蚃苣莃菣ꮃ苣ꎃ菣랂菣薅ꇥ袼뷯钽뷯邽뷯貽뷯₅ꎼ뷯莽뷯薽볯ꚼ뷯貽뷯覼胣뚼볯낼胣ꮂ菣벃볯ꎼ뷯貽뷯銽볯膀迥뎁럦閁볯꒼뷯邽뷯袽볯꺁ꧨ내臣ꊖ臣ꚁꫨ躘臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯閼볯醀⼼䥄㹖†菣閃菣벃菣讖꟥誏臣閃菣벃菣讖꟥袅迥誂菣놂菣袃戼㹲 閃菣벃菣讖꟥誏臣閃菣벃菣讖꟥袅迥誂臣膀臣貂苣꺁菣莃菣벃臣낕臣讂臣醁臣膀郥肸臣薆껥ꞁ臣讂胣閃菣벃菣讖꟥醃苣莃菣꾁胣ꚃ菣뚂菣것菣ꂃ臣讧臣誂苣ꆿ迥鞁胣钃苣뮂菣隃菣莃苣颼볯ꊼ볯뚼볯낼뻥ꆁꇨ鞈볯钼볯覼臣躰臣貂苣芀菣것菣ꂃ雩讧藥随苣醃苣莃菣꾁胣芁苣閃菣벃菣꺁꟥뺁苣銂뿤랏臣膀菣莃苣ꢂ菣覃菣궃菣꾂볯钼볯袼菣莃苣ꢂ菣覃菣궃菣꾂藥鮊뻥ꆁꇨ鞈볯誏臣钃苣뮂菣몇諥隃菣莃苣袅迥誂뻥ꆁꇨ鞈臣몙胩閁苣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯閼볯醀⼼䥄㹖†臣꺁菣것菣ꂃ雩讧菣놂菣袃臣节胣뺯뿥馁苣閃菣벃菣芵苣誂菣놂菣袃臣颭鳥鞁臣蒁苣芀臣讁臣ꪁ臣覂胣螤闦꺁菣것菣ꂃ뗧辂苣醃苣莃菣貁胣貐룤ꚃ菣뚂菣것菣ꂃ臣뺯뿥鞁뻥讂胣鎁苣꾁胣设臣낁胣閃菣벃菣蚈觥貁苣벃菣벃菣궃菣銂軥ꂛ臣馁苣뒠郥ꮁ駧龔臣鞾苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯鎼볯隼胣㲑䐯噉‾ꢡ볯꾁胣閃菣벃菣讖꟥誏臣閃菣벃菣讖꟥袅迥誂菣놂菣袃臣肸껥붖臣ꊽ藦꺁菣ꦂ菣麃菣袃苣몤臣ꚁ臣讂胣鎁苣覂臣膀菣궃菣궂菣낂룤궖볯���뷯辽뷯讽뷯躽뷯뾼볯躽뷯薽뷯銽뷯邽뷯覼胣Ꚃ苣뎃菣Ꚃ볯ꪂ菣뮂菣袃볯랼뷯躽뷯辽뷯뾼볯뾼볯蚽뷯鎽뷯钽볯膀苣ꎂ菣覃苣림苣閃苣莃菣袼볯覽뷯蒽뷯鞽볯림볯꾼뷯蚽뷯薽뷯覼胣钃苣뮂菣閃苣벃菣莃菣袼볯覽뷯薽뷯뾼볯辽뷯趽뷯钽볯膀苣ꦃ菣邃菣閃苣ꆄ볯꺼뷯뾼볯辽뷯辽뷯뾼볯閽뷯蚽뷯銽볯膀볯邃菣閃苣ꆄ볯꺼뷯뾼볯뾼볯閽뷯蚽뷯銽볯膀뿤ꆮ룦뾁볯邃菣閃苣ꆄ볯꺼뷯뾼볯膽뷯薽뷯뾼볯뾼볯閽뷯蚽뷯銽볯膀苣蚃菣랂菣邃菣閃苣ꆄ볯꺼뷯뾼볯钽뷯躽뷯覽뷯뾼볯閽뷯蚽뷯銽볯膀뿤ꆮ룦뾁苣蚃菣랂菣邃菣閃苣ꆄ볯꺼뷯뾼볯膽뷯薽뷯뾼볯钽뷯躽뷯覽뷯뾼볯閽뷯蚽뷯銽볯膀苣ꦃ菣몇諥뢁諦袼볯辽뷯辽뷯뾼볯閽뷯邽뷯钽볯뎼뷯貽뷯莽뷯覽뷯躽볯膀苣ꦃ菣몇諥ꪂ菣邃菣閃菣벃臩麊볯ꎼ뷯貽뷯銽볯꾼뷯钽뷯閽뷯뾼볯隽뷯銽뷯貽뷯鞽볯뎼뷯貽뷯莽뷯覽뷯躽볯膀迥뎁黥뒛菣꾂苣ꮃ苣Ꚃ菣袃볯뚼뷯銽뷯覽뷯膽뷯뾼볯覽뷯薽뷯뾼볯辽뷯躽뷯覼菣ꎂ菣ꮃ菣銂郥鎂臣蒁苣芀臣貂苣꺁菣ꎂ菣ꮃ菣꺁ꧨ내苣ꖻ룤ꮁꫨ躘臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯閼볯醀⼼䥄㹖†苣閃菣Ꚃ苣ꊂ臣膀볯꒼菣ꒂ菣隃菣莃苣袼볯貽뷯莽뷯뾼볯꒼볯낼뷯邽뷯覼菣ꎂ菣ꮃ菣銂뷤ꢔ臣ꚁ菣莃苣ꢂ菣覃菣궃菣꾂볯钼볯ꮁ菣궃菣궂菣낂룤궖苣龔裦馁苣袂臣ꮁ釥꒻臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯閼볯醀⼼䥄㹖†볯覽뷯뎼뷯閽뷯莽뷯겼胣랼뷯躽볯辽뷯銽뷯薽볯膀볯覽뷯뒼뷯銽뷯薽뷯겼胣誏臣랼뷯躽볯膽뷯螽뷯钽볯閃苣벃菣覃臣膀臣趂臣趂臣邃菣閃苣꺁苣ꎂ菣覃苣ꦼ볯銂귨ꖈ臣讂胣邃菣꾂苣뎃菣颼볯ꎼ臣膀菣꾂苣ꮃ菣ꪂ菣誃菣랂菣鞃ꧨ鎨臣龁苣ꮁ臣貂苣銂뷤ꢔ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯閼볯醀⼼䥄㹖†苣ꎂ菣覃苣뢼苣閃苣莃菣誏臣Ꚃ苣뎃菣Ꚃ볯ꪂ菣뮂菣袃苣膀菣莃苣ꢂ菣覃볯钼볯꺁臣膂臣节臣ꞁ臣讂볯ꊼ볯뒼귧銂뷤꺽뇦膂臣讂臣膂臣覼胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯隼볯醀⼼䥄㹖†菣꾂苣ꮃ菣ꦂ菣麃菣袃菣ꎂ菣ꮃ菣꾁胣閃菣벃菣邃菣閃苣颼볯Ꞽ蛥ꮁꃦ趴臣貂臣蒁苣钃苣뮂菣꺁菣ꦂ菣麃菣袃苣螌껥馁苣芀菣꾂苣ꮃ菣궃菣꾂볯钼볯꾁胣鎁苣銂菣꾂苣ꮃ蟥鮊菣讃菣袃볯颼볯ꮁ臣醁苣閃苣벃菣莃菣覤迦꺁臣膂臣뾽铧馁苣芀룤龮雦꺁뷥讅臣膀볯ꒁ臣钃苣뮂菣閃苣벃菣莃菣膀跥ꆁ胣鎼볯鎃菣袃볯钃苣뮂菣ꆼ볯Ꞽ볯膀볯銼菣莃菣込菣꾂苣ꮃ볯Ꞽ볯ꆼ胣醼볯鎃菣袃볯钃苣뮂菣늼볯ꊼ볯閼볯隼볯閼胣誏臣颼菣莃菣込菣꾂苣ꮃ苣뎃菣莃苣릂믤趁苣ꦃ菣邃菣閃苣閃���벃菣莃菣銂铦뒏臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯隼볯醀⼼䥄㹖†볯銽뷯ꖼ뷯뒼뷯銽볯誏臣뎼뷯莽볯醽볯膽뷯늼菣ꎂ菣ꮃ菣꾁胣ꚷ迥뎁迥뾂菣늂菣袃菣莃菣ꆂ蛥꺁菨꾙臣鞁臣뎂菣벃臣貂苣邺苣ꎂ菣覃苣鎖臣ꊖ뿤銂賦몤臣讂胣邃菣꾂苣뎃菣颼볯ꎼ臣鎁苣覂苣뾽铧馁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯鎼볯銼胣㲑䐯噉‾ꮂ菣벃菣莃菣ꆂ蓧閃菣낂臣膀苣鞁苣莃菣閁苣貂臣膀苣ꦃ菣邃菣閃苣貁귥ꢜ臣ꪁ臣鎁臣膀뻥ꎁ臣ꮂ菣벃菣莃菣ꆂ鏦鲽볯랷郥膀菣ꎂ苣ꪃ菣낂胣誏臣隫郧钼껧覼迥뎁鯦낖臣開뷤趸菨ꮁ臣貂臣蒁苣鎁臣銂賦몤臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯隼볯醀⼼䥄㹖†뿤ꆮ룦뾁볯邃菣閃苣ꆄ菣ꦃ苣꾁胣节臣뮂菣袃臣貂苣낁胣閃菣벃菣邃菣閃苣颼볯Ꞽ臣꺁軦閁蟥鮊臣開뷤趸菨ꮁ臣貂苣芀菣꾂苣ꮃ菣궃菣꾂볯钼볯薆臣龔裦閁苣龁럦閁胥꾁胣鎁臣閃菣벃菣邃菣閃苣颼볯Ꞽ蛥ꮁ臣鎁臣Ꚃ苣뎃菣Ꚃ臣龁苣꺁럦閁菣莃菣ꆂ臣颭鳥鞁臣蒁臣ꞁ胣閃菣벃菣邃菣閃苣颼볯Ꞽ蛥ꮁ뿤ꆮ臣貂臣蒁胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯隼볯醀⼼䥄㹖†苣蚃菣랂菣邃菣閃苣ꆄ菣ꦃ苣꾁胣节臣뮂菣袃臣貂苣낁胣릂菣뎃苣ꮃ菣莃菣ꆂ臣颭鳥鞁臣蒁臣ꢁ胣鎾臣ꚁ藥ꚁ臣릂菣뎃苣ꮃ鏦鲽迥뎁鯦낖臣開뷤趸菨ꮁ臣貂苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯鎼볯閼胣㲑䐯噉‾鶿껧袸臣릂菣뎃苣ꮃ菣莃菣ꆂ蓧閃菣낂臣膀苣鞁苣莃菣閁苣貂臣膀菣것菣ꂃ菣莃菣ꆂ볯钼볯뢁臣릂菣뎃苣ꮃ蟥鮊臣開뷤趸菨ꮁ臣貂苣芀菣꾂苣ꮃ菣궃菣꾂볯钼볯薆臣龔裦閁苣龁苣蚃菣랂菣ꒀ臣膀臣꺁菣것菣ꂃ菣莃菣ꆂ볯钼볯薆臣꾁臣꺁苣ꎂ菣覃苣꺁臣膂臣릂菣뎃苣ꮃ菣莃菣ꆂ臣颭鳥鞁臣蒁臣ꞁ胣閃菣벃菣邃菣閃苣颼볯Ꞽ蛥ꮁ뿤ꆮ臣貂臣蒁胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯隼볯醀⼼䥄㹖†苣蚃菣랂菣ꊃ菣覃볯뎼뷯薽뷯莽뷯貽볯궼뷯蒽뷯覼菣ꦃ苣꾁胣节臣뮂菣袃臣貂苣낁胣릂菣뎃苣ꮃ鏦鲽臣膀苣뎃菣ꮃ꿦꺁鿥隺臣袼룤龮雦꺁뷥讅臣袂苣낁胣銼菣莃菣込苣뎃菣ꮃ臣覼꿥钃苣뮂菣躯臣몟뫦ꞁ볯肸껥붖臣ꊽ藦ꮁ苣貂臣膀볯鎃菣袃볯钃苣뮂菣ꞁ볯芁ꇨ閁苣讂臣ꢁ苣螌ꓧ馁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯鎼볯鞼胣㲑䐯噉‾钃苣뮂菣隃菣莃苣颼볯ꊼ臣膀럦閁胥銂苣뎃菣ꮃ꿦꺁鿥隺臣ꚇ郧馁苣貁胣鶁苣覂苣醼菣꾂苣ꮃ臣몇諥馁苣芀軦閁蟥鮊臩麊菣ꎂ菣ꮃ菣꾁胣钃苣뮂菣隃菣莃苣颼볯ꊼ臣膀臣꺁苣蚁臣鞁臣떂菣鞃菣躯臣놷臣ꒀ臣궸臣覂菣꾂苣ꮃ꿦꺁軦閁胥銂臩麊臣讂臣銂뇦骮臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯隼볯醀⼼䥄㹖†룤龮雦꺁뷥讅臣꾁胣���苣벃菣覃胥꾁胣貀鳦鶈胣膀胣肜뿨趀胣誏臣貀鳦ꂁ胣ꞁ臣讂胣貀鳦鶈胣꾁胣钃苣뮂菣躯臣놷臣ꒀ臣鞁臣膀苣뎃菣ꮃ闧랏볯袼跥ꆁ胣邼苣뎃菣莃苣릂믤趁苣Ꚃ菣蚃苣뎃苣릂苣벃菣薆臣肜裥꺁苣뎃菣ꮃ볯꺁軦閁胥銂臩麊臣讂臣ꢁ苣螌믤馁苣芀胣肜雦趀臣膀菣꾂苣ꮃ꿦꺁럦閁胥ꢁ臣ꚁ胣隦苧ꮁ鳦节뿨蒁苣뎃菣ꮃ臣ꊎ臣ꒀ苣뢁諦馁苣鎁臣銂賦꒻臣讂胣貐꟦ꮁ胣貀鳦ꂁ胣꾁胣钃苣뮂菣躯臣놷臣ꒀ臣鞁臣膀ꛨ릂臣肜苣ꂁ臣떂菣鞃菣꺁럦閁胥銂臩麊臣讂臣ꢁ苣螌믤馁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯鎼볯馼胣㲑䐯噉‾閃菣벃菣ꪂ菣邃菣閃菣벃臣몙铧鞁臣蒁ꃥ袐臣꾁胣ꮂ菣벃蟥鮊臩麊菣ꎂ菣ꮃ菣貁胣ꮂ菣벃蟥鮊臣龁苣ꮁ苣뎃菣ꮃ苣ꦃ菣銂菣꾂苣ꮃ蛥ꮁ뗧袐臣讂臣膂臣몟뫦銂뇦骮臣讂胣鞁臣鞁臣貁苣膀菣것菣ꂃ苣벃菣벃菣궃菣貁駧龔臣龁駦ꮁ臣膀苣ꦃ菣몇諥ꪂ菣邃菣閃菣벃臩麊볯ꎼ뷯貽뷯銽볯꾼뷯钽뷯閽뷯뾼볯隽뷯銽뷯貽뷯鞽볯뎼뷯貽뷯莽뷯覽뷯躽볯閃苣벃菣覃臣膀苣ꦃ菣몇諥꺁臣膂臣떂菣鞃菣ꮂ菣벃苣钃苣뮂菣薆臣蒵郥鮁苣龁苣꺁鿥隺苣몱껥馁苣芀룤龮雦꺁뷥讅臣꾁胣ꮂ菣벃蟥鮊臩麊迥뎁苣ꦃ菣몇諥ꪂ菣邃菣閃菣벃臩麊諧讅菣ꦃ菣벃苣꾁胣貀鳦鶈臣떂菣鞃菣趀볯ꚼ볯늼볯뒼볯뎼볯궼볯겼볯覼胣貀蟩뾁믤醁胣袼볯ꖼ볯Ꞽ볯뒼볯꒼볯膀胣肃菣蚃苣떂菣鞃菣趀볯꒼볯늼볯림볯뎼볯궼볯겼볯覼胣뺁臣꾁胣骤闦몱胣袼볯ꆼ볯꾼볯ꦼ볯림볯꺁胥銂鳦鞁臣蒁苣芀胣肜裥꺁苣뎃菣ꮃ胣꾁胣钃苣뮂菣躯臣ꮂ菣벃胥ꢁ臣ꚁ胣肜裥꺁苣뎃菣ꮃ臣ꮂ菣벃臣뢁諦銂賦꒻臣讂胣貀蟩뾁믤醁胣꾁胣钃苣뮂菣躯臣ꮂ菣벃胥ꢁ臣ꚁ胣钃苣뮂菣꺁苣뎃菣ꮃ苣ꦃ菣꺁諥趇맥螝臣뢁諦銂賦몤臣膀胣肃菣蚃苣떂菣鞃菣趀臣膀菣벃菣ꎂ苣뎃菣ꮃ臣뎹鷥ꮂ菣벃臣뢁諦銂賦誻臣膀臣鞁臣貀ꓥ낕뇦趀臣膀볯醼볯肃菣蚃苣떂菣鞃菣꺁ꃥ袐臣꾁苣뎃菣ꮃ臣邺苣ꦃ菣꺁맥螝臣膀臣龁臣袼볯覼鷩肃菣蚃苣떂菣鞃菣꺁ꃥ袐臣꾁苣뎃菣ꮃ臣邃菣閃苣ꮂ菣벃臣뎹鷥銂臩麊臣讂볯肃菣蚃苣떂菣鞃菣낂菣벃菣誏臣趁苣蒁臣떂菣鞃菣낂菣벃菣꺁뷤貂臣骤臣讁볯袂臣ꮁ賦꒻臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鞼볯醀⼼䥄㹖†黥뒛菣꾂苣ꮃ苣Ꚃ菣袃菣ꎂ菣ꮃ菣꾁胣Ꚃ苣뎃菣Ꚃ苣芞鯧ꮁ꣦螈苣钃苣뮂菣꺁闦銂賦骮臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鞼볯醀⼼䥄㹖†鳦鶈臣릂菣뎃苣ꮃ볯뎼뷯薽뷯莽뷯貽볯覽뷯鎽뷯覼菣ꎂ菣ꮃ菣꾁胣떂菣鞃菣릂菣뎃苣ꮃ胥銂胣ꦁ臣袂臣ꮁ菣���苣ꮃ臣릂菣뎃苣ꮃ胥ꮁꓥ鮏臣讂臣銂뇦骮臣讂胣节臣肜裥꺁苣蚃菣랂菣貁苣莃菣閁苣貂臣膀菣꾂苣ꮃ菣궃菣꾂臣膀菣꾂苣ꮃ꿦꺁苣蚃菣랂菣ꒀ臣鞁臣떂菣隃菣ꪕ迥邼볯뎍臣膀볯ꒂ菣螃菣꾂苣颻臣ꮂ苣뎃菣ꎂ菣낂苣궂菣麃蛥꺁鳦鶈臣떂菣鞃菣覼臣놷臣ꒀ苣鶁臣릂菣뎃苣ꮃ胥銂觥鎽臣讂胣뮂菣袃臣貂臣ꪁ臣貂臣膀ꓥ낕뇦ꮃ菣ꮃ苣뾽铧鞁臣膀臣꺁苣蚁臣钃苣뮂菣릂菣뎃苣ꮃ胥銂鯦낖臣膀觥鎽臣讂臣銂뇦骮臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鞼볯醀⼼䥄㹖†菣閃菣벃菣芵苣誂迥뎁菣것菣ꂃ뗧辂苣袅迥誂菣놂菣袃戼㹲 閃菣벃菣芵苣誂볯ꖼ뷯蒽볯ꚼ뷯膽뷯薽볯誏臣閃菣벃菣芵苣誂藥随苣袼볯銽뷯蚽뷯钽뷯袽볯ꖼ뷯蒽볯ꚼ뷯膽뷯薽볯꾁胣閃菣벃菣꺁뗧辂苣銂賦몤臣讂胣閃菣벃菣芵苣誂藥随苣醃苣莃菣꾁菣莃苣ꢂ菣覃藥随苣薾臣財裥뢁胩覂苣膀菣것菣ꂃ뗧辂苣醃苣莃菣꾁볯뎼볯薾臣財裥銼볯邼蛥ꮁ藩꺽臣貂苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯鎼볯鎼胣㲑䐯噉‾ꢡ볯꾁胣閃菣벃菣芵苣誂迥뎁菣것菣ꂃ뗧辂苣袅迥誂臣肸껥붖臣ꊽ藦ꮁ臣醁苣閃苣벃菣莃菣銂ꓧ鞁臣蒁苣芀볯뾋ꯨ膀볯ꒁ臣讞臣醃苣莃菣銂賥ꖈ臣讂臣膂臣膀菣놂菣袃菣莃菣벃胥꾁闧ꪁ苣芀볯鎁苣覂臣膀菣놂菣袃菣莃菣벃胣궸雦麛闦袼볯躽뷯薽뷯銽뷯邽뷯뾼볯閽뷯芽뷯銽볯膀苣閃菣ꢂ菣覃菣것菣ꂃ볯뎼뷯蚽뷯뾼볯躽뷯뾼볯銽뷯趽뷯覼胣邃菣閃苣ꪂ菣邃菣몙铧袼볯閽뷯蚽뷯銽볯꾼뷯薽뷯뾼볯莽뷯閽뷯銽뷯蒽볯閃苣벃菣覃苣ꮐ苣ꞁ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鞼볯醀⼼䥄㹖†룤궖鯥낕臣膀菣莃苣ꢂ菣覃볯钼볯ꮁ苣ꎁ臣뾽铧閁苣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鞼볯醀⼼䥄㹖†苣閃菣ꢂ菣覃菣것菣ꂃ迥뎁菣莃菣ꆂ苣벃菣벃駧龔菣ꎂ菣ꮃ菣꾁胣蒐胣겋ꯧ蒚臣ꚃ菣뚂菣것菣ꂃ臣螤闦閃菣벃菣뢁臣蚈觥銂賦몤臣讂胣붂菣袃苣Ꞃ苣꾁胣붂菣袃苣뎃菣閃菣벃菣銂ꇨ躘臣讂臣ꢁ臣袂臣ꚁ胣낖臣蒁菣벃苣閃菣벃菣銂雩讧臣鮁苣鎁臣ꪁ臣膀菣것菣ꂃ苣芵苣覂臣讂臣ꢁ臣ꞁ臣讂胣鎁臣릊黦꾁胣ꊃ菣覃諦몇菣讃菣袃볯钼볯貁菣ꊃ菣颼볯꒼胣颼볯ꖼ苣ꪂ菣邃菣閃菣벃臣鮁臣芙臣뮂菣袃臣貂苣邃菣閃苣ꪂ菣邃菣몙铧閃苣벃菣覃臣ꢅ臣貐臣ꞁ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鞼볯醀⼼䥄㹖†菣뾂苣ꮃ雩讧迥뎁苣ꒂ菣讖꟥袅迥誂菣놂菣袃戼㹲 뾂苣ꮃ雩讧볯ꊼ뷯螽뷯躽볯뒼뷯貽뷯覼迥뎁苣ꒂ菣讖꟥袅迥誂볯낼뷯薽뷯薽뷯莽뷯뾼볯薽뷯覽뷯뾼볯覽뷯薽볯醃苣莃菣꾁胣袅ꇨ뾂苣ꮃ볯节臣芁苣낁���꺁뗧辂苣ꢁ胣낖臣蒁苣ꒂ菣꺁꟥뺁苣ꢁ苣螌ꓧ馁苣芀臣讂苣ꒂ菣銂胩讂郥醃苣꾁胣뾂苣ꮃ雩讧菣놂菣袃臣讧臣讂胣蚈ꇩ隃菣莃苣颼볯钼臣膀臣讂苣꾂菣ꎂ菣蚃苣銂鳦馁苣Ꚃ苣뎃菣Ꚃ蛥꺁郥뾂苣ꮃ꿦ꮁ臣꺁菣놂菣袃黥銂蟥鮊臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鞼볯醀⼼䥄㹖†ꇨ閼臣膀룤龮雦꺁뷥讅臣誁臣讂苣ꒂ菣讖꟥誏臣뾂苣ꮃ雩讧藥随苣醃苣莃菣꺁菣ꦂ菣麃菣袃苣몤臣ꚁ臣讂胣袼该隫胣銼臣꺁黥꺁菣놂菣袃苣몌裥馁苣龁苣ꮁ胣醃苣莃菣颃菣肃菣ꒀ臣낕臣讂胣覼臣貂苣꾁胣閃菣벃菣薆臣肜裥꺁苣ꒂ菣袼볯覽뷯鎽뷯뾼볯覽뷯薽볯ꦼ뷯뾼볯銽뷯趽뷯覼胣뾂苣ꮃ賥螈苣릂볯ꊼ뷯薽뷯讽뷯辽뷯躽뷯뾼볯覽뷯薽볯膀苣벃菣벃苣ꒂ菣讖꟥袼볯薽뷯覽뷯뾼볯閽뷯薽뷯뒼뷯貽뷯覼胣뎏苣ꒂ菣袼볯覽뷯薽볯늼뷯螽뷯钽볯膀觥뾂苣ꮃ볯뒼뷯貽뷯뾼볯銽뷯躽뷯覼胣뾂苣ꮃ맧誂뿨鞁볯뒼뷯貽뷯뾼볯薽뷯薽뷯钽볯膀苣ꒂ菣讖꟥떂菣閃菣벃菣袼볯覽뷯薽볯ꊼ뷯螽뷯躽볯뎼뷯芽볯銽뷯趽뷯覼胣誏臣뾂苣ꮃ볯뎼鯦벾臣袼볯銽뷯钽뷯뾼볯覽뷯薽볯몼볯覼菣ꦃ苣膀룤뎁臣뾂苣ꮃ볯趽뷧袼볯覽뷯薽볯뢼볯겼뷯莽뷯钽뷯辽뷯覼迥뎁苣ꒂ菣림뷤꺽볯뒼뷯貽뷯뾼볯뾼볯辽뷯膽뷯覽뷯躽볯閃苣벃菣覃苣ꮐ苣ꞁ臣讂胣뾂苣ꮃ雩讧迥뎁苣ꒂ菣讖꟥袅迥誂菣놂菣袃臣膀苣ꦃ菣ꒀ苣ꪃ苣袼볯貽뷯膽뷯뾼볯辽뷯辽뷯뾼볯膽뷯閽뷯覼胣놷臣ꒀ苣ꪃ苣袼볯貽뷯膽뷯뾼볯薽뷯钽뷯뾼볯膽뷯閽뷯覼胣릂菣뎃苣ꮃ胥꾂菣ꊂ볯ꎼ뷯薽뷯銽볯뎼뷯薽뷯莽뷯貽볯뚼뷯貽뷯薽볯膀菣莃苣ꢂ菣覃苣ꦃ菣꾂菣ꊂ볯ꊼ뷯莽뷯薽뷯蒽볯ꎼ뷯薽뷯銽볯ꎼ뷯貽뷯銽볯膀菣莃苣ꢂ菣覃럦閁苣ꪃ苣袼볯膽뷯讽뷯躽뷯뾼볯貽뷯膽뷯뾼볯薽뷯钽뷯覼胣邃菣꾂苣뎃菣릂菣뎃苣ꮃ苣ꪃ苣袼볯膽뷯讽뷯躽뷯뾼볯貽뷯膽뷯뾼볯钽뷯躽뷯覽뷯覼胣誏臣閃菣벃菣ꪂ菣邃菣閃菣벃볯꾼뷯薽뷯蚽뷯辽뷯뾼볯銽뷯趽뷯覼菣ꎂ菣ꮃ菣銂苣ꮐ苣芀臣貂苣꺁菣ꎂ菣ꮃ菣銂믤许臣겪飦馁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯鎼볯颼胣㲑䐯噉‾閃菣벃菣薆臣肜裥꺁苣ꒂ菣閃菣낂臣膀裥麡菣궃菣꾂볯钼볯貁菣것菣ꂃ蛥꺁鳦鶈臣뾂苣ꮃ臣龁苣꺁菣벃苣銂胩誂臣ꒁ臣讂臣ꢁ苣螌ꓧ馁苣芀볯鎁臣芙苧ꮁ胣閃菣벃菣꺁臣膂臣醃菣ꦂ菣麃菣릂苣Ꚃ菣뾂苣鶈鳦隌臣讂臣ꢁ臣ꞁ臣讂胣覼苣鞁臣꺁苣ꒂ菣貁ꓥ낕鯥꺁菣릂苣覜臣ꚁ臣貂臣膀菣것菣ꂃ蛥꺁鳦鶈臣뾂苣ꮃ菣ꦃ苣꾁胣肜裥꺁菣릂룤ꂁ臣ꢡ飦閁苣讂胣㲂䐯噉ਾ䐼噉㰾���㹖胣醼볯鞼볯醀⼼䥄㹖†苣ꒂ菣몌裥誂苧꾁胣醃苣鞃菣ꒂ菣颼볯邼臣龁苣꺁賥螈苣릂菣ꮂ菣몂菣貁뷤開臣ꚁ臣讂臣ꢁ苣螌ꓧ馁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯鎼볯邼胣㲑䐯噉‾릂菣醃菣뾂苣ꮃ雩讧臣膀裥麡菣궃菣꾂볯钼볯貁苣벃菣벃苣ꒂ菣릖뷥薆臣肜裥꺁苣ꒂ菣꺁臣膂臣螃菣뾂苣膀苣ꒁ臣芁苣鎁臣銂賦몤臣讂胣袼臣꺁駦릂臣膀苣벃菣벃苣ꒂ菣ꮁ雩芿臣讂菣閃苣벃菣뎃苣ꮂ苣뎃苣銂裥龜賥馁苣鎁臣貁臣趁苣芀볯㲉牢ਾ†볯钃苣뮂菣隃菣莃苣颼볯ꊼ臣膀迥뾂苣ꮃ胣趉苣ꒂ菣膀苣ꒂ菣낹苣钿臣膀苣ꒂ菣讖꟥떂菣閃菣벃菣膀迥뎁苣ꒂ菣몼볯뢛뻨뾁菣ꦃ苣銂뷤ꢔ臣ꪁ臣芀볯㲉牢ਾ†苣ꒂ菣뢼뷤꺽迥뎁苣ꒂ菣림뷤꺽臣鶁苣麁苣膀苣ꎂ菣覃苣薆臣뾂苣ꮃ臣讖꟥颽迥뎁뷯趽뷧銂賦骮臣讂胣鎁苣覂臣醃菣ꆃ菣뾂臣膀苣ꒂ菣ꮂ苣뎃菣ꢁ臣ꚁ賦骮臣貂苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯鎼볯醼胣㲑䐯噉‾ꮂ菣벃胥꾂菣ꊂ胣놷臣ꒀ苣ꪃ苣膀迥뎁苣蚃菣랂菣ꒀ苣ꪃ苣꾁胣ꊖ胩馁苣꾂菣ꊂ鏦鲽臣鞏臣龁迦馆胣骽胣誏臣릂菣뎃苣ꮃ菣莃菣ꆂ菣꾂苣ꮃ苣뎃菣ꮃ臣ꒀ苣螌껥馁苣芀菣莃苣ꢂ菣覃苣ꦃ菣꾂菣ꊂ胣邃菣꾂苣뎃菣놷臣꾂菣ꊂ胣誏臣邃菣꾂苣뎃菣릂菣뎃苣ꮃ苣ꪃ苣閃菣낂臣膀菣莃苣ꢂ菣覃菣궃菣꾂볯钼볯貁雩ꎀ臣讂迦馆胣骽迥뎁볯뺁臣꾁苣蚃菣랂菣邃菣閃苣銂苣ꪃ苣馁苣讁郥讁苣螌ꓧ馁苣芀臣讂菣ꦃ苣貁胣龜胣ꞁ臣讂ꃥ袐臣꾁胣邃菣꾂苣뎃菣颼볯ꎼ臣閃菣벃菣邃菣閃苣颼볯Ꞽ臣覂雩ꎀ菦놠苣궪蟥閁臣蒁胣钃苣뮂菣隃菣莃苣颼볯ꊼ臣膀苣ꪃ苣趓뷤銂껥鮚臣芁ꇨ馁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯鎼볯銼胣㲑䐯噉‾邃菣꾂苣뎃菣ꮂ菣벃苣ꪃ苣꾁胣钃苣뮂菣몇諥ꚃ菣莃菣銼볯邼臣辏蛥邃菣閃苣銂苣ꪃ苣馁苣讁郥讁苣螌ꓧ馁苣芀苣鞁臣꺁菣ꦃ苣貁苣莃菣閁苣貂臣膀菣莃苣ꢂ菣覃볯钼볯꾁苣ꦃ菣邃菣閃苣ꒀ苣궪蟥閁臣蒁胣ꎻ苣誂臣膀菣꾂苣ꮃ蟥鮊菣讃菣袃볯颼볯貁苣ꦃ菣뾂苣ꮃ苣ꮂ菣벃胥꾂菣ꊂ臣꾂菣ꊂ臣讂胣趏꿥ꮁ胣节臣鎁臣閃菣낂臣뮂菣袃臣貂臣蒁臣醁苣낁胣邃菣꾂苣뎃菣隃菣莃苣颼볯ꎼ臣ꮂ菣벃菣莃菣ꆂ胥薆臣궪뻨肂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯颼볯醀⼼䥄㹖†菣莃苣ꢂ菣覃럦閁苣ꪃ苣閃苣벃菣覃臣膀菣꾂苣ꮃ蟥鮊菣讃菣袃볯颼볯貁뷯邃菣閃苣銂苣ꪃ苣馁苣讁郥讁苣螌ꓧ馁苣芀菣꾂苣ꮃ蟥鮊菣讃菣袃볯颼볯꾁胣钃苣뮂菣隃菣莃苣颼볯ꊼ臣閽苣讁臣뢂苣ꆃ菣ꪃ苣ꚇ郧馁苣趉臣膀苣ꒂ菣誸臣蒐菣꾂苣ꮃ苣뎃菣ꮃ苣놷臣ꒀ苣ꪃ苣ꮁ裥龜���馁苣芀苣鞁臣꺁菣莃菣貁苣莃菣閁苣ꪁ臣貂臣膀菣莃苣ꢂ菣覃菣궃菣꾂볯钼볯꾁菣것菣ꂃ菣莃菣ꆂ菣ꊃ菣讁苣骽胥銂ꫨ벾苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯鎼볯钼胣㲑䐯噉‾邃菣꾂苣뎃菣릂菣뎃苣ꮃ苣ꪃ苣閃苣벃菣覃臣膀菣꾂苣ꮃ蟥鮊菣讃菣袃볯颼볯貁苣蚃菣랂菣邃菣閃苣鎃菣袃苣꾂菣ꊂ臣讂臣ꢁ苣螌ꓧ馁苣芀菣莃苣ꢂ菣覃菣궃菣꾂볯钼볯꾁胣鎁臣閃菣낂臣뮂菣袃臣貂臣蒁苣뒠郥ꮁ胣閃菣벃菣邃菣閃苣ꆃ菣ꪃ臣覂苣蚃菣랂菣ꒀ苣궪뻨肂胣钃苣뮂菣몇諥ꚃ菣莃菣銼볯邼臣膀苣蚃菣랂菣钃苣뮂菣邃菣閃苣銂胣릂菣뎃苣ꮃ胥꾂菣ꊂ臣꾂菣ꊂ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯颼볯醀⼼䥄㹖†菣것菣ꂃ苣벃菣벃菣궃菣閃菣낂臣膀臣꺁苣ꒂ菣貁菣벃菣붊蟥隃菣莃苣颼볯鎼臣誁臣讂苣벃菣벃菣궃菣꺁뗧鲞臣芁苣꺁臣Ꚑ臣膀跥ꆁ胣뺏菣것菣ꂃ臣肜뻥꺁菣것菣ꂃ臣貐룤꺁菣벃苣閃菣벃菣꺁뛧骶臣芁苣꺁臣Ꚑ臣銂賦몤臣讂胣节臣鎁臣鎃菣袃臣뮂菣袃臣貂苣낁胣ꮂ菣벃蟥鮊苣벃菣벃菣궃菣뢁諦袼볯辽뷯辽뷯뾼볯閽뷯邽뷯钽볯꾼뷯薽뷯蚽뷯辽뷯뾼볯薽뷯薽뷯钽뷯辽뷯覼臣膀臣꺁苣蚁臣钃苣뮂菣ꮂ菣벃胥銂蟥鮊臣讂臣銂뇦骮臣讂胣节臣鎁臣鎃菣袃臣뮂菣袃臣貂臣醁苣낁胣ꮂ菣벃蟥鮊臩麊볯ꎼ뷯貽뷯銽볯꾼뷯钽뷯閽뷯뾼볯薽뷯薽뷯钽뷯辽뷯覼臣膀臣꺁苣蚁臣钃苣뮂菣ꮂ菣벃胥銂蟥鮊臣讂臣銂뇦骮臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯颼볯醀⼼䥄㹖†苣ꒂ菣讖꟥떂菣閃菣벃菣꾁胣뾂苣ꮃ蛥꺁菣벃苣銂ꓨ낕臣떂菣閃菣벃菣ꮁ裥늉臣讂臣膂臣뾽铧閁苣讂胣蒐苣隃菣것菣ꂃ蛥꺁菣벃苣꾁胣蚈ꇩ閁苣龁胩躘胦膀苣ꒂ菣ꊂ苣꒙軥膀臣龁臣隻臣骤蟩醃苣辏蛥趓뷤꺁臣膂臣膀菣ꒂ菣ꦃ苣뎃臣袂臣ꚁ맧誂뿨鞁蟥蚐臣讂臣ꢁ臣ꞁ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯颼볯醀⼼䥄㹖†菣꾂菣ꊂ菣놂菣袃戼㹲 꾂菣ꊂ菣놂菣袃臣膀菣꾂苣ꮃ菣궃菣꾂볯钼볯貁胣芁苣뾂苣ꮃ苣꾂菣ꊂ臣讂뿥膦臣芁苣鎁臣銂賦몤臣讂胣鎁臣醃苣莃菣꾁胣뚼볯낼뻥ꆁꇨ鞈볯钼볯뢁냥讁苣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯颼볯醀⼼䥄㹖†ꇨ钼臣膀룤龮雦꺁뷥讅臣誁臣讂苣ꪃ苣醃苣莃菣꺁菣ꦂ菣麃菣袃苣몤臣ꚁ臣讂胣ꢡ臣꾁胣颃菣肃菣袼볯薽뷯蒽뷯銽볯膀菣벃菣궂菣莃苣ꖃ苣뎃菣莃苣릂볯궼뷯蒽뷯뾼볯膽뷯袽뷯뾼볯躽뷯薽뷯覼胣ꮂ菣벃苣ꪃ苣袼볯貽뷯膽뷯뾼볯醼뷯膽뷯覼胣놷臣꾂菣ꊂ볯꒼뷯邽뷯袽볯ꎼ뷯薽뷯銽볯膀苣蚃菣랂菣꾂菣ꊂ볯뎼뷯薽뷯莽뷯貽볯ꎼ뷯薽뷯銽볯膀苣ꦃ菣ꒀ苣ꪃ���袼볯貽뷯膽뷯뾼볯辽뷯辽뷯뾼볯膽뷯閽뷯覼胣놷臣ꒀ苣ꪃ苣袼볯貽뷯膽뷯뾼볯薽뷯钽뷯뾼볯膽뷯閽뷯覼胣誏臣릂菣뎃苣ꮃ胥꾂菣ꊂ볯ꎼ뷯薽뷯銽볯뎼뷯薽뷯莽뷯貽볯뚼뷯貽뷯薽볯貁郥뺁苣ꚁ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯颼볯醀⼼䥄㹖†苣ꦃ菣꾂菣ꊂ臣膀菣꾂苣ꮃ菣궃菣꾂볯钼볯貁苣ꦃ菣邃菣閃苣銂苣ꪃ苣鞁胣ꢅ臣꺁胥銂胣Ꚃ苣뎃菣Ꚃ臣ꒂ菣螃菣꾂苣颻臣ꮂ菣벃菣벃菣ꮁ臣讂臣Ꚑ臣ꮁ뻤颭臣ꚁ胣ꮂ菣벃胥꾂菣ꊂ臣龁臣ꒂ菣螃菣꾂苣ꒀ苣ꪃ苣袼볯貽뷯膽뷯뾼볯躽뷯薽뷯뾼볯膽뷯閽뷯覼臣뮂菣袃臣讂臣Ꚑ臣銂賦몤臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯馼볯醀⼼䥄㹖†럦閁苣ꪃ苣誏臣릂菣뎃苣ꮃ苣ꪃ苣꾁胣钃苣뮂菣隃菣莃苣颼볯ꊼ臣놷臣誏臣込臣龁臣릂菣뎃苣ꮃ菣莃菣ꆂ苣꾂菣ꊂ臣膀胥銂胣鶁苣麁苣놷臣ꒀ苣ꪃ苣誏臣込臣龁臣릂菣뎃苣ꮃ胥꾂菣ꊂ臣뮂菣袃臣讂臣Ꚑ臣銂賦몤臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯馼볯醀⼼䥄㹖†菣钃苣뮂菣ꊃ菣覃苣ꎃ菣랂菣薅ꇥ醃苣莃菣㲈牢ਾ†菣꾂苣ꮃ菣벃菣궂菣莃苣ꖃ藥ꮡ菣놂菣袃臣膀苣隃苣Ꞃ苣袃꿦꺁鿥隺臣覤賥鞁뻥讂諧讅菦놠苣ꮐ苣ꞁ臣讂胣ꪂ菣뢂苣꾂菣ꊃ菣覃苣ꎃ菣랂菣薅ꇥ醃苣莃菣꺁藥ꚁ臣閃苣벃菣覃臣膀郥ꪂ菣뢂苣꾂菣ꮁ볤ꎁ臣蚮臣覤賥鞁臣蒁臣膀臣貂苣꺁뷤貂臣醼臣꾁迦馆臣貂苣ꪂ菣뢂苣꾂菣ꮁ뻤颭臣ꚁꓥ隌臣鞾苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯鎼볯銼胣㲑䐯噉‾ꢡ볯誏臣鞼臣膀룤龮雦꺁뷥讅臣誁臣讂菣꾂苣ꮃ菣벃菣궂菣莃苣ꖃ藥ꮡ菣놂菣袃臣閃苣벃菣莃菣誏臣薆껥銂ꓧ鞁臣蒁苣芀臣꺁菣놂菣袃臣膀菣莃菣벃볯ꢼ뷯膽뷯薽뷯覼胣ꊃ菣覃苣ꎃ菣랂菣ꒂ菣螃菣꾂苣袼볯辽뷯薽볯ꎼ뷯莽뷯薽볯ꦼ뷯蒽뷯颽볯膀苣뚂菣ꚩ꣩꾏菨袼볯莽뷯鎽뷯辽뷯뾼볯薽뷯钽볯ꖼ뷯膽뷯貽뷯蒽볯膀볯㲸畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯莽뷯鎽뷯辽뷯㲒猯扵뾼猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰궼뷯躽⼼畳㹢胣뢼猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰뎼뷯覽뷯鎽뷯銽⼼畳㹢볯㲿畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯膽뷯㲘猯扵膀볯㲹畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯莽뷯鎽뷯辽뷯㲒猯扵뾼猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰궼뷯躽⼼畳㹢胣림猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰뎼뷯覽뷯鎽뷯銽⼼畳㹢볯㲿畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯膽뷯㲘猯扵膀苣蚃苣莃菣ꮃꧨ鎨迥붃볯뎼뷯覽뷯邽뷯薽볯뒼뷯鎽뷯뾼볯躽뷯芽뷯薽뷯覼胣ꊂ菣閃苣龩菨袼볯閽뷯莽뷯覽뷯躽猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰ꆼ볯낼볯ꆼ⼼畳㹢볯膀迥ꞅ苣ꮃ菣ꆂ볯膽뷯邽뷯膽猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪���潧樮≰늼볯ꚼ볯늼볯꺼볯ꖼ⼼畳㹢볯膀苣ꮃ菣ꆂꧨ鎨迥붃볯ꆼ뷯邽뷯膽볯뒼뷯鎽뷯뾼볯躽뷯芽뷯薽뷯覼胣ꮂ菣벃ꧦ붃볯ꚼ뷯躽뷯钽뷯辽뷯㲎畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯꾼볯꾼볯㲲猯扵覼胣肜냥ꮂ菣벃볯莽뷯貽뷯銽猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰궼볯꺼⼼畳㹢볯膀鳦Ꞥ苣ꦃ菣袼뷯辽뷯辽뷯㲒畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯ꆼ볯㲸猯扵覼胣ꮂ菣벃ꧨ鎨迥붃볯ꎼ뷯貽뷯뾼볯薽뷯钽볯ꖼ뷯膽뷯貽뷯蒽볯膀迥ꞅ苣蚃菣랂菣袼뷯钽뷯躽뷯覽뷯㲌畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯ꖼ볯ꖼ볯ꖼ볯ꎼ볯㲥猯扵覼胣릂菣뎃苣ꮃꧦ붃볯ꚼ뷯躽뷯钽뷯辽뷯㲎畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯뒼볯꺼볯ꦼ볯㲬猯扵覼胣놷臣龩菨袼볯閽뷯莽뷯覽뷯躽猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰꒼볯낼볯ꢼ⼼畳㹢볯膀苣蚃菣랂菣麃苣꾂볯趽뷯鎽뷯㲋畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯뒼볯꺼볯ꦼ볯㲬猯扵覼胣릂菣뎃苣ꮃꧨ鎨룤袐ꃦ趓뷤袼볯钽뷯躽뷯覽뷯뾼볯薽뷯钽볯ꚼ뷯覽뷯閽뷯薽볯꾼뷯薽뷯膽뷯覽뷯躽볯膀苣蚃菣랂菣ꚩ꣩袐ꃦ뮃볯ꚩ꣩趸郥베鏦鲽볯뎼뷯薽뷯莽뷯貽볯뒼뷯鎽뷯뾼볯膽뷯鎽볯몼볯뒼뷯鎽뷯뾼볯膽뷯貽뷯銽뷯뾼볯邽뷯銽뷯钽뷯辽뷯覼胣릂菣뎃苣ꮃ迥뎁볯ꚩ꣩袐ꃦ趓뷤袼볯钽뷯躽뷯覽뷯뾼볯躽뷯뾼볯뾼볯薽뷯钽볯낼뷯鎽뷯뾼볯邽뷯銽뷯钽뷯辽뷯覼胣릂菣뎃苣ꮃꧨ鎨迥붃볯뎼뷯薽뷯莽뷯貽볯뒼뷯鎽뷯뾼볯躽뷯芽뷯薽뷯覼胣릂菣뎃苣ꮃ菣릂苣뢛뻨뾁볯鞽뷯覽뷯薽†뷯膽뷯讽猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰뎼볯ꖼ볯ꎼ볯겼⼼畳㹢볯膀볯ꚩ꣩꾏菨袼볯뾼볯薽뷯钽볯ꖼ뷯膽뷯貽뷯蒽볯膀볯뢛뻨뾁迥붃볯몼볯랼뷯覽뷯薽볯ꖼ뷯膽뷯貽뷯蒽볯膀苣蚃菣랂菣辏蛥袼볯銽뷯鞽볯钽뷯躽뷯覽뷯覼胣ꮂ菣벃菣릂苣뢛뻨뾁볯랼뷯覽뷯薽볯趽뷯鎽뷯㲋畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯꾼볯꾼볯㲲猯扵覼胣랷郥꾏菨袼볯貽뷯躽뷯覽뷯螽볯ꖼ뷯膽뷯貽뷯蒽볯膀럦袐苣ꦃ菣肸껥袼볯辽뷯鎽뷯膽뷯钽볯ꎼ뷯貽뷯銽猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰ꊼ볯ꖼ볯꒼⼼畳㹢볯膀뫦ꮂ菣벃菣ꆂ苣뾂볯뎼뷯閽뷯莽뷯뾼볯辽뷯辽뷯뾼볯膽뷯钽뷯銽볯膀ꇨ袅苣ꦃ菣閃苣꾂苣袼볯薽뷯钽뷯躽뷯钽뷯辽뷯뾼볯辽뷯辽뷯뾼볯膽뷯钽뷯銽볯膀뫦ꊂ菣閃苣閃苣꾂苣袼볯辽뷯銽뷯薽볯ꆼ뷯邽뷯膽볯ꚼ뷯莽뷯辽뷯覼胣財藥ꊂ菣閃苣閃苣꾂苣袼볯薽뷯钽뷯躽뷯钽뷯辽뷯뾼볯貽뷯袽뷯뾼볯膽뷯钽뷯銽볯膀苣ꦃ菣隫郧랷郥趓뷤袼볯辽뷯辽뷯뾼볯辽뷯覽뷯ꊼ뷯薽뷯蒽볯꾼뷯薽뷯膽뷯覽뷯躽볯膀苣ꮃ菣ꆂꯨ蚐럦袐鏦鲽���ꆼ뷯邽뷯膽볯겼뷯螽뷯莽볯貽뷯躽뷯뾼볯邽뷯銽뷯钽뷯辽뷯覼胣誏臣螃苣뚂菣뎃苣꾏菨袼볯覽뷯袽뷯銽뷯躽뷯뾼볯躽뷯芽뷯薽뷯覼菣ꎂ菣ꮃ菣銂郥肂胣鎁苣覂臣閃苣벃菣覃苣ꖻ룤ꮁꫨ躘臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯馼볯醀⼼䥄㹖†菣벃菣궂菣莃苣ꖃ苣뎃菣莃苣릂臣膀菣벃菣궂菣莃苣ꖃ볯鞼볯薆臣ꢂ菣袃菣꺁苣뎃菣莃苣릂苣螌ꓧ馁苣芀臣꺁菣놂菣袃臣薆껥꾁뷧鮏臣讂臣ꢁ臣芁苣芀戼㹲 랂苣벃ꧨ鎨迥붃胣릂菣ꎂ菣鞃菣ꚩ꣩꾏菨膀苣ꮃ菣ꆂꧨ鎨迥붃胣ꮂ菣벃ꧨ鎨迥붃胣릂菣뎃苣ꮃꧨ鎨迥붃胣誏臣몼ꧨ鎨迥붃臣膀臣貂臣貂苣뚂菣膀苣蚃苣莃菣ꮃ胣ꊂ菣閃苣膀苣ꦃ菣膀苣蚃菣랂菣膀迥뎁럦閁ꧨ鎨臣龁苣꺁菣ꦃ苣銂该鲽迥붃臣馁苣芀菣ꎂ苣ꪃ菣낂迥붃臣膀菣ꎂ苣ꪃ菣낂ꧦ붃苣開뷤꾏菨ꮁ臣讂胣㲂牢ਾ†볯㲸畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯莽뷯鎽뷯辽뷯㲒猯扵뾼猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰궼뷯躽⼼畳㹢胣뢼猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰뎼뷯覽뷯鎽뷯銽⼼畳㹢볯㲿畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯膽뷯㲘猯扵膀볯㲹畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯莽뷯鎽뷯辽뷯㲒猯扵뾼猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰궼뷯躽⼼畳㹢胣誏臣림猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰뎼뷯覽뷯鎽뷯銽⼼畳㹢볯㲿畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯膽뷯㲘猯扵꾁胣鶁苣麁苣랂苣벃ꧨ鎨臣릖뷥颠鿥꺁럥膀迥膀菣莃菣膀迥뎁菣袃菣ꢂ菣뢂苣螌껥馁苣芀戼㹲 ꊂ菣閃苣龩菨膀苣ꦃ菣龩菨膀苣蚃菣랂菣龩菨膀迥뎁럦閁ꧦ붃臣膀臣貂臣貂苣ꮃ菣ꆂ胣ꮂ菣벃胣릂菣뎃苣ꮃ胣誏臣놷臣ꚩ꣩꺁臣膂臣龩菨銂賦몤臣讂胣㲂牢ਾ†苣ꮃ菣ꆂ迥ꞅ臣膀苣ꮃ菣ꆂꧨ鎨臣뾽铧閁苣讂迥ꞅ苣ꮃ菣ꆂ胥ꞁ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯馼볯醀⼼䥄㹖†鳦辰苣ꦃ菣誏臣肜ꓥꮂ菣벃臣膀臣貂臣貂苣ꦃ菣궂菣꺁臣膂臣肜냥薌郥ꒀ迥뎁鳦Ꞥ賥ꮐ胥ꞁ臣讂胣㲂牢ਾ†迥ꞅ苣蚃菣랂菣꾁胣릂菣뎃苣ꮃꧨ鎨臣뾽铧閁苣讂迥ꞅ胥ꞁ臣讂胣㲂牢ਾ†苣蚃菣랂菣麃苣꾂臣膀ꧨ鎨觥ꮁ胣芏藧ꒀ迥뎁菣莃菣ꆂ苣뎃菣ꮃ苣蚃菣랂菣ꒀ苣隫郧趩臣讂臣膂臣릂菣뎃苣ꮃ菣릂苣ꞁ臣讂胣㲂牢ਾ†苣蚃菣랂菣ꚩ꣩趸郥베鏦鲽臣膀苣蚃菣랂菣ꚩ꣩貁ꓥ鞕臣龁駦ꮁ臩財臣貂苣開뷤銂賦몤臣讂胣貐꟦ꮁ胣릂菣뎃苣ꮃꧨ鎨郥베菣몼ꧨ鎨룤袐ꃦ趓뷤꾁胣릂菣뎃苣ꮃꧨ鎨臣꾁郥베臣龁臣膀럦閁ꧨ鎨臣꾁ꓥ鞕臣龁駦ꮁ臩財臣貂苣開뷤銂賦몤臣膀苣蚃菣랂菣誏臣몼ꧨ鎨郥베鏦鲽臣膀苣蚃菣랂菣誏臣놷臣꺁룤ꚩ꣩ꮁ郥베臣龁駦ꮁ臩財臣貂苣開뷤銂賦���臣讂胣㲂牢ਾ†苣蚃菣랂菣麃苣꾂鯦벾臣閃苣벃菣覃臣膀菣莃菣ꆂ蛥꺁鯦낖臣貂苣릂菣뎃苣ꮃ菣莃菣꺁臣膂臣릂菣뎃苣ꮃ菣릂苣ꞁ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯馼볯醀⼼䥄㹖†볯뢛뻨뾁迥붃臣膀럦閁菣莃菣ꆂ臣뢛뻨뾁迥뎁鯦낖臣꾏菨ꞁ臣讂臣Ꚑ臣銂賦몤臣讂菣벃菣ꒀ臣芁苣芀戼㹲 릂菣뎃苣ꮃ迦馆菣ꎂ菣ꮃ菣꾁胣钃苣뮂菣隃菣莃苣颼볯ꊼ臣膀苣蚃菣랂菣螃菣뾂臣鞁臣꺁菣ꦂ菣낂菣궃菣꾂볯钼볯讁苣꺁곧銼臣螃菣뾂胥銂룤궖臣鮁苣鎁臣銂賦몤臣讂胣㲂牢ਾ†苣ꦃ菣麃苣꾂鯦벾臣꾁胣辏蛥邃菣閃苣薆臣꾏菨隌臣貂苣鎃菣袃鷩꺁菣릂苣ꞁ臣讂胣ꮂ菣벃苣뎃菣莃苣릂菣벃菣ꞁ臣躽뷤颼菣莃菣貁苣뎃菣莃苣릂菣릂苣ꞁ臣讂胣㲂牢ਾ†럦袐迥붃臣膀럦袐臣꾏菨讁郥讁苣螌ꓧ馁苣芀苣鞁럦袐臣꾏菨ꮁ臣貂臣蒁苣낁胣隫郧钼껧꾁该鲽룤붃臣閁苣讂胣㲂牢ਾ†럦袐苣ꦃ菣肸껥꾁胣랷郥꺁臣膂臣肸껥꺁苣ꦃ菣ꞁ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯馼볯醀⼼䥄㹖†뫦ꮂ菣벃菣ꆂ苣뾂迥뎁ꇨ袅苣ꦃ菣閃苣꾂苣閃苣벃菣覃臣膀臣貂臣貂뫦躰蟥閁苣龁胣誏臣財藥躰蟥閁苣龁苣뎃菣ꮃ苣ꦃ菣꺁매낕臣芁苣芀뫦ꊂ菣閃苣閃苣꾂苣꾁胣ꊗ臣뾂苣ꮃ菣莃菣ꆂ蛥ꮁ臣讂苣뎃菣ꮃ苣ꮃ菣ꆂ胥꺁臣膂臣鞹闦ꞁ臣讂胣㲂牢ਾ†苣ꦃ菣隫郧랷郥趓뷤꾁苣ꦃ菣ꒀ臣龁苣꺁ꯨ蚐臣龁臣랷郥趓뷤銂賦몤臣膀苣ꮃ菣ꆂꯨ蚐럦袐鏦鲽臣ꊂ菣閃苣ꒀ臣龁苣꺁ꯨ蚐臣龁臣랷郥趓뷤銂賦몤臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯馼볯醀⼼䥄㹖†菣릂菣ꎂ菣鞃菣궂菣莃苣ꖃ藥ꮡ菣놂菣袃戼㹲 ꆬ臣螃菣뾂꟦ꂀ臣膀苣蚃苣莃菣ꮃ苣ꎃ菣랂菣薅ꇥ醃苣莃菣ꞁ臣讂胣㲂牢ਾ†ꇨ醼볯꾁胣肸껥붖臣ꊽ藦ꮁ苣讂苣蚃苣莃菣ꮃ苣ꎃ菣랂菣薅ꇥ醃苣莃菣꺁꟦ꂀ迥뎁蛥릮苣몤臣ꚁ臣讂胣醃苣莃菣꾁胣릂菣ꎂ菣鞃菣궂菣莃苣ꖃ苣뎃菣莃苣릂볯뎼뷯覽뷯邽뷯薽볯ꎼ뷯莽뷯薽볯ꦼ뷯蒽뷯颽볯膀迥뎁苣蚃苣莃菣ꮃ菣뾂菣뎃볯뎼뷯覽뷯邽뷯薽볯낼뷯钽뷯薽뷯躽볯閃苣벃菣覃苣ꮐ苣ꞁ臣讂胣릂菣ꎂ菣鞃菣궂菣莃苣ꖃ苣뎃菣莃苣릂菣ꎂ菣ꮃ菣꾁胣ꦁ臣릂菣ꎂ菣鞃菣궂菣莃苣ꖃ臣ꢂ菣袃菣銂뷧鮏臣讂臣讁苣螌ꓧ馁苣芀苣蚃苣莃菣ꮃ菣뾂菣뎃菣ꎂ菣ꮃ菣꾁胣릂菣ꎂ菣鞃菣醃苣벃菣銂뿤膌臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯馼볯醀⼼䥄㹖†††룤龮雦꺁뷥讅臣꾁胣릂菣ꎂ菣鞃菣궂菣莃苣ꖃ볯隼볯꾁볯ꒁ臣ꢂ菣袃菣銂鳦鞁臣誁苣膀뻥ꎁ臣릂菣ꎂ菣鞃菣궂菣莃苣ꖃ苣뎃菣莃苣릂臣鎃菣袃苣ꒂ苣꾁볯ꞁ臣讂胣袼볯邽뷯躽���겼臣꾁胣릂菣ꎂ菣鞃菣醃苣벃菣꺁苣ꒂ苣꾁볯邼볯钼菣莃菣ꮁ苣莃菣閁苣讂胣覼戼㹲 뮃볯뎼볯醃苣莃菣㲈牢ਾ†臣讂菣궃苣ꦃ菣薆臣蒐迥隦苣뾂菣鞃臣膀꿥鲿臣讂볯뎼볯醃苣莃菣銂鳦鞁臣蒁苣芀ꇨ鎼臣膀룤龮雦꺁뷥讅臣袂苣뚼볯낼菣놂菣袃臣閃苣벃菣莃菣銂ꓧ鞁臣蒁苣芀臣꺁菣ꦂ菣麃菣袃臣膀菣벃菣궂菣莃苣ꖃ苣뎃菣莃苣릂볯궼뷯蒽뷯뾼볯膽뷯袽뷯뾼볯躽뷯薽뷯覼胣릂菣ꎂ菣鞃菣궂菣莃苣ꖃ苣뎃菣莃苣릂볯뎼뷯覽뷯邽뷯薽볯ꎼ뷯莽뷯薽볯ꦼ뷯蒽뷯颽볯膀苣뾂菣鞃볯ꒂ菣螃菣꾂苣袼볯钽뷯趽뷯뾼볯뾼볯躽뷯薽뷯覼胣릂苣뎃菣림苣뎃菣莃苣릂볯뎼뷯膽뷯邽볯림볯ꦼ뷯蒽뷯颽볯膀苣뎃菣ꮃ苣邃菣莃苣麃苣꾂볯뎼뷯趽뷯貽뷯뾼볯辽뷯薽뷯膽뷯薽볯궼뷯鎽뷯覼胣芏藧몼볯몼猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰늼볯ꚼ볯늼볯꺼볯ꖼ⼼畳㹢볯膀볯骽볯颽胣꒼뷯꒼뷯膀迥뎁ꓥ趇苣뎃菣ꮃ臣袼볯鎽볯궼뷯貽뷯覽볯膽뷯邽뷯薽볯閃苣벃菣覃胣芏藧骽胥袼볯㲺畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯ꖼ볯ꖼ볯ꖼ볯ꎼ볯㲥猯扵覼胣誏臣銼臣꺁럦閁该超裢骽볯芈뷯膀裢骽볯芈뷯銂郥肂胣뚼볯낼臣膀ꓥ趇苣뎃菣ꮃ臣袼볯鎽볯궼뷯貽뷯覽볯膽뷯邽뷯薽볯閃菣낂苣节郥肂胣鎁苣覂臣閃苣벃菣覃苣ꖻ룤ꮁꫨ躘臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯馼볯醀⼼䥄㹖†볯뎼볯醃苣莃菣꾁胣뺏鳥ꊂ苣蚃苣隃臣芁苣ꊃ菣覃迥뎁苣蚃苣莃菣ꮃ苣ꎃ菣랂菣銼볯邼胣銼볯邼蛥꺁菣벃菣誏臣릂菣ꎂ菣鞃菣궂菣莃苣ꖃ苣뎃菣ꪃ臣龁苣꺁苣뎃菣莃苣릂胣뎍臣ꊃ菣覃苣ꎃ菣랂菣ꒂ菣螃菣꾂苣誏臣릂菣ꎂ菣鞃菣궂菣莃苣ꖃ苣뎃菣莃苣릂苣ꮐ苣芀볯閃苣뎃苣隃菣莃苣颼볯ꆼ臣膀볯뎼볯꺁臣膂臣ꮂ菣벃菣벃苣銂裥薀臣鮾뗧馁苣芀볯㲉牢ਾ†룤龮雦꺁뷥讅臣꾁胣릂菣ꎂ菣鞃菣궂菣莃苣ꖃ볯鞼볯꾁볯ꒁ臣ꢂ菣袃菣銂鳦鞁胣鎾臣ꚁ苣蚃苣莃菣ꮃ苣ꎃ菣랂菣ꒂ菣螃菣꾂苣閃苣벃菣覃臣鎃菣袃苣ꒂ苣꾁볯ꞁ臣讂胣ꊃ菣覃苣ꎃ菣랂菣銼볯邼臣醼볯꺁苣뎃菣ꪃ苣覜臣膀뻥ꎁ臣ꊃ菣覃苣ꎃ菣랂菣ꒂ菣螃菣꾂苣閃苣벃菣覃臣鎃菣袃苣ꒂ苣꾁볯ꞁ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯邼볯醀⼼䥄㹖†볯뎼볯醃苣莃菣꾁胣뒛臣膀苣뾂菣鞃볯ꒂ菣螃菣꾂苣膀苣뾂菣鞃볯ꒂ菣螃菣꾂苣膀迥뎁ꓥ趇苣뎃菣ꮃ臣ꒀ苣ꮐ苣ꞁ臣讂胣릂苣뎃菣뢼苣뎃菣莃苣릂臣뾂苣ꮃ蛥꺁뷯ꒂ菣螃菣꾂苣銂賦몤臣膀룤릖苣뾂菣鞃볯ꒂ菣螃菣꾂苣꾁苣ꒂ菣薆臣馽苣뎃菣莃苣릂苣螌ꓧ馁苣芀ꓥ趇苣뎃菣ꮃ臣閃菣낂臣膀迦���馆臣ꢂ苣ꪃ苣릂駩뮎臣膀鷩ꢂ苣ꪃ苣릂駩뮎臣銂賦몤臣讂胣鎁苣ꮁ苣誂胣鞃菣龃菣ꎂ菣馃菣릂苣ꒂ菣ꊂ苣꒙軥銂菣궃苣ꦃ菣蒚臣뚈뻥馁苣鎁臣貁臣趁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯醼胣㲑䐯噉‾肸껥붖臣ꊽ藦ꞁ臣膀볯钼臣릂苣뎃菣貁볯躽볯쎘颼苣뾂菣鞃볯뾂苣ꮃ苣讧裦鞁臣蒁苣芀뻥ꎁ臣膀苣뾂菣鞃볯ꒂ菣螃菣꾂苣誏臣릂苣뎃菣림苣뎃菣莃苣릂臣鎃菣袃苣ꒂ苣꾁볯ꞁ臣讂胣设臣낁胣醼볯쎖醼볯钃苣뮂菣뾂苣ꮃ胣誏臣銼韃볯钃苣뮂菣릂苣뎃菣ꞁ臣膀苣뾂菣鞃苣뎃菣莃苣릂臣邼臣覂볯뺁臣꺁꿧늛臣辂臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯邼볯醀⼼䥄㹖†볯뎼볯醃苣莃菣꾁胣뒛臣膀볯뎼볯꺁臣膂臣떂菣鞃菣ꮂ菣것菣뢂菣릂苣銂郥鎂臣蒁苣芀苣뾂菣鞃蛥꺁郥떂菣鞃菣꾁胣ꮂ菣것菣뢂菣릂苣薆臣뺯뿥馁苣鎃菣袃苣覜臣ꚁ臣讂胣ꢅ臣꺁迥隦苣뎃菣ꮃ臣膀苣뎃菣ꮃ苣邃菣莃苣麃苣꾂蛥ꮁ苣莃菣閁苣ꚁ臣讂臣貂苣꺁菣莃菣銂鳦鞁臣蒁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯鎼胣㲑䐯噉‾肸껥붖臣ꊽ藦ꞁ臣膀볯隼臣떂菣鞃菣貁볯ꒁ臣릂苣뎃菣銂꟦邈臣ꚁ臣誂胣鎾臣ꚁ胣떂菣鞃菣ꮂ菣것菣뢂菣릂苣꺁菣莃菣떂苣몂臣醼볯ꞁ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯邼볯醀⼼䥄㹖†臣讂苣뾂菣鞃蛥꺁藥ꚁ臣떂菣鞃菣꺁뷯ꒀ臣膀迥ꞅ볯ꒀ胣꒼뷯꒼뷯膀迥뎁볯骽볯馽臣ꊖ臣ꚁ꣨鞮臣貂苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯閼胣㲑䐯噉‾肸껥붖臣ꊽ藦ꞁ臣膀迥ꞅ볯ꒀ臣銼볯꺁闦낕臣鎼臣꺁냥낕菣莃菣袼뷯銼볯躼볯覼臣銂鳦馁苣ꚬ迥颻臣몛껥辰闦릂胥ꞁ臣誂胣꒼뷯꒼뷯誏臣꒼뷯꒼뷯꾁곧랏믤趁鯥骮냥낕苧袼뷯銼볯躼볯覼胥ꞁ臣讂胣鞾苣貂苣銼볯鎃菣袃볯떂菣鞃菣놷臣ꒀ臣ꢁ臣ꚁ胣鎁苣覂臣鎃菣袃닧ꚺ臣膍裥ꞁ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯邼볯醀⼼䥄㹖†ꓥ趇苣뎃菣ꮃ臣閃菣낂臣膀迦馆臣ꢂ苣ꪃ苣릂駩뮎臣貂苣꺁臣膀臣龁臣ꢂ苣ꪃ苣릂駩뮎臣貂臣蒁臣讁苣螌ꓧ馁苣芀臣꺁菣ꎂ菣ꮃ菣ꮁ苣誂胣鞃菣龃菣ꎂ菣馃菣릂苣ꒂ菣ꊂ苣꒙軥貁迥붃臣ꪁ苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯鞼胣㲑䐯噉‾芏藧몼胣꒼뷯꒼뷯膀迥뎁볯骽볯馽胥꾁胣뢁裥隃菣莃苣颼볯隼臣覂菣벃菣ꢳ藥隃菣莃苣颼볯鞼胣ꆸ臣貂苣芀菣벃菣ꢳ藥隃菣莃苣颼볯鞼臣膀臣貂苣銂룤릖臣钃苣뮂菣隃菣莃苣颼볯ꊼ臣膀苣芀菣ꦂ菣낂菣궃菣꾂볯钼볯讁苣낈鷧馁苣钃苣뮂菣놷臣醃苣莃菣꾁胣ꮂ菣벃뻥ꆁꇨ鞈볯鎼볯薆臣뢛뻨뺁苣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯邼볯醀⼼䥄㹖†菣ꮂ菣벃菣놂菣袃戼㹲 ꮂ菣벃菣놂菣袃臣膀臣讂苣뾂菣���鞃蛥꺁迥隦菣꾂苣ꮃ臣龁苣꺁苣ꦃ菣ꒀ볯뎍臣膀볯Ꞽ볯ꆼ胥覼苣躸臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯邼볯醀⼼䥄㹖†ꇨ颼臣膀룤龮雦꺁뷥讅臣袂苣ꮂ菣벃菣놂菣袃臣ꊽ諧誏臣薆껥銂ꓧ鞁臣蒁苣芀臣꺁菣놂菣袃臣膀菣莃菣벃볯ꢼ뷯膽뷯薽뷯覼迥뎁苣ꦃ菣袼볯辽뷯辽뷯覼菣ꎂ菣ꮃ菣銂郥肂胣肸껥붖臣ꊽ藦ꞁ臣膀苣ꦃ菣ꒀ臣膀뗨膀럧膀鷩膀迥뎁苣ꮃ菣ꆂ胥ꮁ鷥覭臣蚈闦閁苣龁볯銼菣莃菣銂鳦鞁臣蒁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯邼胣㲑䐯噉‾뮃럦閁볯릂菣뎃苣ꮃ菦놠戼㹲 놷臣醃苣莃菣꾁胣钃苣뮂菣躯臣놷臣膀臣龁臣릂菣뎃苣ꮃ菦놠苣뢼胩馁苣芀ꇨ馼臣膀룤龮雦꺁뷥讅臣袂苣놷臣醃苣莃菣꺁뷥뚊迥뎁蛥릮苣몤臣ꚁ臣讂胣鎁臣醃苣莃菣꾁胣颃菣肃菣袼볯薽뷯蒽뷯銽볯誏臣몼菣ꎂ菣ꮃ菣銂郥肂胣肸껥붖臣ꊽ藦ꞁ臣膀볯閃苣벃菣覃臣膀臩ꢔ迥붃臣钃苣뮂菣ꊃ菣覃蛥꺁苣蚃菣랂菣辏蛥閃菣낂臣뮂菣蚃苣뎃苣ꮁ뻤颭臣ꚁ胣閃菣낂菣뎃菣릂菣뎃苣ꮃ臣龁臣閃菣낂菣뎃菣놷臣ꢁ臣ꚁ꟨袇臣貂苣銼볯鎃菣袃胥ꞁ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯醼볯醀⼼䥄㹖†菣뚊藦醃菣ꆃ菣뾂戼㹲 钃苣뮂菣隃菣莃苣颼볯ꊼ臣膀臣꺁鏦鲽臣놽鿩銂迥벁臣螤闦꺁諧讅菣ꦃ菣벃苣銂뛧膌臣ꚁ臣讂胣ꢡ볯銼迥뎁볯鎼臣膀룤龮雦꺁뷥讅臣袂苣뚊藦醃菣ꆃ菣뾂苣ꪃ苣袃臣ꚁ臣讂胣鎁苣覂臣뚊藦醃菣ꆃ菣뾂臣膀臣貂苣꺁郥趐菣놂菣袃菣ꎂ菣ꮃ菣ꮁ꿥鲿臣ꚁ臣讂胣鶁苣ꮁ苣誂胣醃苣莃菣閃苣벃菣覃꣨낿臣뚊藦醃菣ꆃ菣뾂臣ꦁ铧閁苣膀꣨낿臣낹苣钿臣貁鳧ꖕ臣貂苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯銼胣㲑䐯噉‾设ꓥ꾁胣떂菣鞃菣趽뷧袼볯膽뷯邽뷯薽볯辽뷯膽뷯覽뷯躽뷯覼胣떂菣鞃菣趇臣袼볯膽뷯邽뷯薽볯薽뷯螽뷯钽뷯覼胣誏臣閃菣낂迥붃賥袼볯躽뷯芽뷯薽볯貽뷯螽뷯覼臣芁苣芀苣뎃菣ꮃ뷤꺽臣膀볯隼韃볯隼苣隃菣꾂苣ꮃꃦ邭룤꺁賦骮臣貂臣钃苣뮂菣薆臣떂菣鞃菣꺁뷤꺽臣芁苣芀苣뎃菣ꮃ蟩뾁臣膀臣貂苣꺁苣뎃菣ꮃ臣늉뷥ꚁ苣貂臣꾫闦趇臣ꞁ臣讂胣鎁苣覂臣趇臣꾁胣떂菣鞃菣ꮂ菣벃苣钃苣뮂菣ꮂ菣벃臣蚈꟨馁苣꺁臣뾽铧閁苣讂胣ꎻ鯦龮雦꺁뷥讅臣膀믤꺁蟥蚐臣貐鳦鞁臣뒛雦馁苣龁苣ꮁ胣붂菣袃苣Ꞃ苣뚈뻥꺁룤ꮁ臣貂苣꺁菣ꦃ菣벃苣銂菣ꒂ菣龃菣꾂臣뒛雦ꞁ臣讂苣蚁臣膀诨늹臣뚊藦醃苣莃菣袼菣것菣ꂃ雩讧臣龁臣뾂苣ꮃ雩讧菣놂菣袃臣袂臣ꪁ볯薆臣鎁苣覂臣閃苣벃菣覃苣ꮐ苣鎁臣貁臣趁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯鎼胣㲑䐯噉‾閃菣낂迥붃賥���꾁胣ꊂ菣閃苣ꚩ꣩꾏菨膀苣ꦃ菣ꚩ꣩꾏菨膀苣蚃菣랂菣ꚩ꣩꾏菨膀볯ꚩ꣩꾏菨膀苣뚂菣ꚩ꣩꾏菨膀苣蚃苣莃菣ꮃꧨ鎨迥붃胣랷郥꾏菨膀迥뎁菣ꎂ苣ꪃ菣낂迥붃菣벃菣ꒀ苣ꮐ苣ꞁ臣讂胣㲂牢ਾ菣궃菣뎂菣㲫牢ਾ†菣벃菣ꢳ藥誏臣閃苣뎃苣隃菣莃苣颼볯鞼胣颼볯ꆼ臣膀菣놂菣袃苣钃苣뮂菣隃菣莃苣颼볯ꊼ臣ꖅ諥薾臣財裥銼볯邼蛥뢁鯦벾苣鎁臣ꮁ苣ꎁ臣膀菣꾂苣ꮃ菣궃菣꾂볯钼볯뢁藥鮊苣膀苣芀菣꾂苣ꮃ菣궃菣꾂볯钼볯꾁胣邃菣꾂苣뎃菣隃菣莃苣颼볯ꎼ臣节胩ꆿ臣膀껥蚺臣龁菣꾂苣ꮃ苣閃菣벃菣邃菣閃苣颼볯Ꞽ臣膀苣膀臣龁菣것菣ꂃ菣莃菣ꆂ볯钼볯讁苣钃苣뮂菣銂菣벃菣邃菣꾂臣ꚁ裥ꖝ菣ꦃ苣ꆃ菣袃臣랷郥馁苣芀볯钃苣뮂菣隃菣莃苣颼볯ꊼ臣膀ꓨ낕臣钃苣뮂菣꺁볯ꒁ臣뾂苣ꮃ臣ꆾ胥銂룤芙臣膀苣膀迥醁苣芀볯㲉牢ਾ†菣꾂苣ꮃ菣궃菣꾂볯钼볯薆臣龩菨隃菣莃苣銂胣ꖻ룤ꮁꫨ躘臣讂胣ꮂ菣벃胣ꊂ菣閃苣膀迥뎁苣蚃苣莃菣ꮃ胥꾁菣ꦃ苣ꆃ菣袃꿦꺁菣벃苣ꞁ臣讂臣ꞁ胣뺯뿥馁苣ꚩ꣩꺁뗧鲞臣膀菣ꦃ苣ꆃ菣袃蛥꺁藥ꚁ臣떂菣鞃菣ꮁ臩ꢔ臣貂苣芀苣뚂菣ꚩ꣩ꮁ臣蒁臣节郥颁臣ꢁ臣肨臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯醼볯醀⼼䥄㹖†菣ꦃ苣ꆃ菣袃꿦꺁胣誏臣떂菣鞃菣躯臣袨껧ꮁ鿥ꖁ臣肸껥붖臣ꊽ藦꺁臣膂臣螃菣뾂臣膵苣꺁臣膂臣겓볤뎂菣覃臣芦ꛨ銂믤许臣몤臣芀臣꺁鏦벼苣벃菣꾁胣钃苣뮂菣隃菣莃苣颼볯ꊼ臣趓뷤꺁ꛦ膦苣躸臣讂胣鎁臣겓볤뎂菣覃臣膀苣隃菣꾂苣ꮃꃦ邭臣떂苣몂胣떂菣鞃菣꺁闦覭臣袂臣ꪁ觧骮臣뎃껥銂郥鎂臣蒁苣芀臣貂苣꺁胣誏臣隻臣몛껥醃菣ꆃ菣뾂臣膀껥붖臣鶾귥馁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯閼胣㲑䐯噉ਾ䐼噉邀闦醼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㄰ㄷ⼼㹡⼼䥄㹖㰊䥄㹖胣낕볯醼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㜱㰲愯㰾䐯噉ਾ䐼噉邀闦醼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㄰㌷⼼㹡⼼䥄㹖㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯醼볯醀⼼䥄㹖†菣ꖅ諥薾臣財裥誏臣閃苣ꮃ苣ꪃ菣낂戼㹲 ꊃ菣覃돦ꖅ迥뎁菣ꦂ菣낂菣궃菣꾂볯钼볯誏臣颼볯ꆼ臣膀藥鮊볯ꦼ볯꾼볯醼볯薆臣螃菣뾂菣놂菣袃苣超뷧馁苣芀菣ꦂ菣낂菣궃菣꾂볯钼볯讁苣꺁菣벃苣꾁胣閃菣낂菣뎃菣ꮂ菣벃뻥ꆁꇨ鞈볯鎼볯薆臣超뷧閁苣讂胣ꊃ菣覃돦ꖅ菣궃菣꾂볯钼볯讁苣鞏臣龁藥鮊菣놂菣袃臣ꊖ臣ꚁ臣膀藥鮊菣ꎂ菣뾂볯銼볯貁菣놂菣袃菣莃菣벃苣뾪臣膀臣꺁菣놂菣袃苣膀菣莃苣ꢂ菣覃菣궃菣꾂볯钼볯銂胩���臣鮁苣讁胣뚼볯낼뻥ꆁꇨ鞈볯钼볯薆臣超뷧馁苣讁胣钃苣뮂菣몇諥ꚃ菣莃菣銼볯邼臣膀苣讁胣뺁臣꾁臣貂苣鎼臣꺁臣讂뗧袐臣銂뇦骮臣讂胣节臣財藥薾臣財裥薆臣膍裥ꪁ뷤난臣ꪁ臣龁苣ꮁ菣놂菣袃볯邃菣꾂苣뎃菣隃菣莃苣颼볯ꎼ胣뚼볯낼뻥ꆁꇨ鞈볯钼볯膀苣ꦃ菣薾臣財裥銼볯邼胣뺁臣꾁菣꾂苣ꮃ蟥鮊藥鮊뻥ꆁꇨ鞈ꇨ趁볯銂胩讂臣ꢁ臣ꞁ臣ꪁ臣貂臣膀菣ꒂ菣ꦃ苣뎃臣龩菨鲁귦鞁뻥讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯醼볯醀⼼䥄㹖†裢龮雦꺁뷥讅臣꾁胣뚼볯낼뻥ꆁꇨ鞈볯钼볯誏臣ꮂ菣벃뻥ꆁꇨ鞈볯鎼볯꾁룤ꎀ臣몛껥떂苣몂菣뎂菣覃臣芁苣袼郥뚼볯낼뻥ꆁꇨ鞈볯钼볯꺁ꃥ袐臣醼볯颼菣莃菣꺁볯閼볯것苣벃菣膀郥ꮂ菣벃뻥ꆁꇨ鞈볯鎼볯꺁ꃥ袐臣鎼볯鎃菣袃臣醼볯颼菣뎂菣覃볯芀迥醁臣醃苣莃菣꾁闦낕臣것苣벃菣銂跥膂苣芀뻥ꆁꇨ鞈蛥꺁菣놂菣袃臣ꂍ苣讂菣뎂菣覃臣낕臣膀臣꺁黥膀뻥ꎁ臣鶁臣떂苣몂臣鶾귥馁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯颼胣㲑䐯噉‾钃苣뮂菣隃菣莃苣颼볯ꊼ臣膀郥薾臣財裥銼볯邼胣銼볯邼꿦꺁鯦벾臣鶃苣뎃苣誏臣궪蟥鞁菣ꒂ菣뾂苣궶賦鞁胣뢛뻨뾁菣ꒂ菣뾂臣袂臣ꚁ苣뎃菣莃苣릂臣貂臣것苣벃菣讁苣讖꟥鞁臣膀뻥ꆁꇨ鞈蛥뢁臣꺁뻥ꆁꇨ鞈ꇨ趁臣醃苣莃菣銂鯦벾苣芀菣꾂苣ꮃ菣궃菣꾂볯钼볯꾁胣醃苣莃菣貁跥膂苣것苣벃菣꺁闦ꮁ뻤颭臣ꚁ胣誏臣ꪾ鋧薾臣財裥銂胨꺅臣ꚁ胣뢛뻨뾁菣ꒂ菣뾂苣ꦁ裥ꮁ苣뎃苣ꪃ菣뎃菣閁臣讂胣节臣膀뻥ꆁꇨ鞈鯦벾臣鶃苣뎃苣銂苣뎃苣ꪃ菣뎃菣閁臣龁뻥ꮁ胣뢛뻨뾁菣ꒂ菣뾂臣袂臣ꚁ뿤膌臣貂臣蒁苣ꒀ臣궪蟥鞁菣ꒂ菣뾂臣袂臣ꚁ뿤膌臣貂臣蒁苣ꒀ臣貁귧鞁臣鎁臣銂菣꾂苣ꮃ菣궃菣꾂볯钼볯貁뇦骮臣貂臣膀菣궃菣꾂볯钼볯꾁뻥ꆁꇨ鞈臣뚊藦銂胢閃菣鶀臣뮂菣袃臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯醼볯醀⼼䥄㹖†菣궃菣꾂볯钼볯꾁胣궪蟥鞁菣ꒂ菣뾂臣袂臣ꚁ苣뎃菣莃苣릂臣貂臣것苣벃菣讁苣醃苣莃菣銂ꓦꊴ臣膀菣놂菣袃臣讞臣몟臣蒁臣膀迥뎁뻥낒뻥ꆁꇨ鞈苣莀藦鞁臣膀ꫨ몇臣鶃苣뎃苣銂臩螈臣ꒂ菣꾂菣ꆃ菣袃臣鮁苣芀苣鞁胣薾臣財裥궪蟥鞁菣ꒂ菣뾂苣ꒂ菣꾂菣ꆃ菣袃臣鮁臣貾臣膀ꫨ몇臣鶃苣뎃苣ꮁ苣ꎁ臣鶿賦閁苣ꚁ臣讂胥ꢁ鯦벾臣鶃苣뎃苣ꮁ苣ꎁ臣鶿賦閁苣ꚁ臣讂胥ꢁ臣覭臣蒁臣ꢁ苣钃苣뮂菣隃菣莃苣颼볯ꊼ臣뎆껥馁苣낁胣隃菣莃苣颼볯ꊼ臣ꖅ諥薾臣財裥꺁諧讅苣鲀ꧧ鶀臣뮂菣袃臣讂胣㲂牢ਾ†裧貾臣薾臣財裥뢁臣궪蟥鞁迥뎁鯦벾臣趓뷤貁胣閃���誏臣목諧讅菣莃菣銂臩螈臣ꪃ苣莃菣馁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯邼胣㲑䐯噉‾뮃藥鮊蟥蚐戼㹲 钃苣뮂菣隃菣莃苣ꖅ諥鞃菣뮂菣떂볯馼볯꾁胣뚼볯낼迥뎁苣ꦃ菣薾臣財裥銼볯邼迥뎁볯鎼볯讁苣醃苣莃菣銂迥醁苣芀藥鮊菣궃苣莃苣銼볯邼臣膀苣鞁뻥ꆁꇨ鞈臣목臣芁苣낁ꧦ붃臥ꊭ臣讂胣ꢅ臣꺁菣놂菣袃臣膀迥醁臣蚠뫥ꞁ蟥蚐臣貂苣芀볯뚼볯낼뻥ꆁꇨ鞈볯钼볯꾁볯뎼볯醃苣莃菣ꂁ臣銂뿤膌臣讂臣ꢁ臣ꪁ臣膀菣벃菣ꢳ藥隃菣莃苣颼볯鞼臣覂臣ꖅ諥醃苣莃菣膀뻤袁臣뾂苣ꮃ雩讧胣閃菣벃菣讖꟥膀迥뎁菣꾂苣ꮃ菣벃菣릂菣ꎂ菣鞃菣醃苣莃菣銂뿤膌臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯銼볯醀⼼䥄㹖†뻥ꆁꇨ鞈볯钼볯讁苣꺁볯뎼볯것苣벃菣銂蟥蚐臣讂觥ꮁ胣ꖅ諥鞃菣뮂菣떂볯馼볯꾁胣ꮂ菣벃뻥ꆁꇨ鞈볯鎼볯讁苣꺁볯뎼볯것苣벃菣ꮁ꿥鲿臣讂菣ꦃ苣ꆃ菣袃苣ꦃ菣袼迥뎁볯뺁臣꾁럦閁볯릂菣뎃苣ꮃ菣벃苣覼苣궪蟥馁臣ꢁ臣ꞁ臣讂臣Ꚑ臣銂ꫨ릁苣芀苣鞁뻥ꆁꇨ鞈볯鎼볯貁鳦ꂁ臣閃苣뎃苣隃菣莃苣颼볯鞼臣覂菣벃苣銂迥醁臣蒁臣醁苣낁胣뚼볯낼菣뎂菣覃臣龁苣꺁藥ꚁ臣ꮂ菣벃菣ꦃ苣ꆃ菣袃苣궪蟥馁臣ꢁ臣ꞁ臣讂苣蚁臣ꪁ苣뺁臣膀藥鮊菣궃苣莃苣꾁ꧦ붃臥ꊭ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯銼볯醀⼼䥄㹖†ꛨ花臣貂臣螃菣뾂苣閃苣뎃苣隃菣莃苣颼볯ꆼ臣覂迥醁苣ꢁ胣ꖅ諥鞃菣뮂菣떂볯馼볯꾁藥鮊뻥ꆁꇨ鞈볯钼볯薆臣것苣벃菣꺁蟥蚐苣蚠闧ꮁ雩讧臣讂胣蒐볯뎼볯것苣벃菣躯臣膀藥鮊菣궃苣莃苣銼볯邼臣薿ꛨꮁ뿥颁臣ꮂ菣벃迥뎁菣벃菣薃ꃥ銂ꓦꊴ臣膀臣貂苣钃苣뮂菣醃苣鞃菣ꒂ菣銼볯邼臣ꆸ臣芀苣鞁藥鮊菣궃苣莃苣銼볯邼臣钃苣뮂菣ꊃ菣覃臣龁臣릂菣ꎂ菣鞃菣궂菣莃苣ꖃ藥ꮡ菣놂菣袃臣궁臩馁苣낁胣ꖅ諥鞃菣뮂菣떂볯馼볯꾁菣놂菣袃臣놅臣鮾뗧閁苣龁苣ꎃ菣랂菣ꒂ菣螃菣꾂苣銂뷤ꢔ臣ꚁ胣鶁苣銂臩螈臣궂菣莃苣ꖃ苣뎃菣ꪃ蛥뢁苣钃菣馁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯鎼胣㲑䐯噉‾뮃苣뚂菣ꚩ꣩㲓牢ਾ†苣뚂菣ꚩ꣩ꚃ菣莃菣銼볯邼臣膀賦骮臣貂臣릖뷥颠鿥隤臣芁苣钃苣뮂菣閃菣낂菣뎃菣銂軦꒙臣讂苣뚂菣ꚩ꣩銂臩財臣讂胣랂苣벃雦ꊽ臣膀볯떂菣钃苣뮂菣ꞁ臣ꪁ臣覼菣꾂苣ꮃ裥ꎧ臣Ꚃ苣뎃菣Ꚃ뫥馨蛥ꮁ賦骮臣貂臣蒁苣芀苣뚂菣ꚩ꣩ꚃ菣莃菣銼볯邼臣膀藥鮊菣궃苣莃苣銼볯邼臣覂뻤ꚵ臣貂臣뾂苣ꮃ迥뎁苣뾂菣鞃뷤꺽苣뾽铧鞁臣膀臣讂菣ꦃ苣ꆃ菣袃臣랂苣벃苣ꎂ菣覃苣꺁ꓥ뒁臣芁苣讁郥讁苣몱껥馁苣芀臣꺁���뢂菣꾂臣겓볤뎂菣覃苣ꖻ룤ꮁꓧ馁胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯銼볯醀⼼䥄㹖㰊䥄㹖胣낕볯醼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㜱㰴愯㰾䐯噉ਾ臣鎁臣膀볯㲸畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯ꎼ볯뎼볯꾼볯㲲猯扵뾼猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰궼볯뢼⼼畳㹢胣뢼猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰뎼볯ꦼ볯뎼볯늼⼼畳㹢볯㲿畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯ꦼ볯㲮猯扵膀볯㲹畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯ꎼ볯뎼볯꾼볯㲲猯扵뾼猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰궼볯뢼⼼畳㹢胣誏臣림猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰뎼볯ꦼ볯뎼볯늼⼼畳㹢볯㲿畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯ꦼ볯㲮猯扵꾁胣覜諥钃苣뮂菣꺁臣膂臣肜ꓥ誏臣肜냥颽胥膀迥뎁鳦Ꞥ迥뎁鳦辰뷯ꒀ臣芁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯閼胣㲑䐯噉‾钃苣뮂菣隃菣莃苣颼볯ꊼ臣膀苣鞁鳦릊菣ꦃ苣ꆃ菣袃臣袼볯鎽볯뚼뷯貽뷯蒽볯ꚼ뷯膽뷯趽뷯躽뷯覼臣貀臥趀臣芁苣낁胣鶁臣閃菣낂菣뎃菣銂ꃧ蒣臣讂胣鶁臣ꞁ臣醁苣낁胣钃苣뮂菣隃菣莃苣颼볯ꊼ臣鶁臣閃菣낂菣뎃菣銂菣ꒂ菣ꦃ苣뎃臣ꆬ臣릂菣벃苣ꮁ룦馁胣뺁臣랂苣벃ꧨ鎨菣讃菣袃볯ꆼ볯꾁胣袼뷯㲘畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯ꦼ볯꒼볯랼⼼畳㹢볯馽猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰랼볯꺼볯꾼볯㲷猯扵覼苣ꎂ菣覃苣Ꞻ꣦銂苣蚃苣莃菣ꮃꧨ鎨菣讃菣袃볯ꊼ볯뢁胩讂胣㲂牢ਾ†臣꺁ꧨ鎨臣钃苣뮂菣躯臣몟뫦ꞁ臩財臣貂苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯隼胣㲑䐯噉‾뮃苣蚃苣莃菣ꮃꧨ鎨戼㹲 릂菣ꎂ菣鞃菣ꚩ꣩ꚃ菣莃菣銼볯邼臣膀苣鞁苣蚃苣莃菣ꮃꧨ鎨迥붃菣ꦃ苣貁苣莃菣閁苣ꚁ臣貂臣袼跥ꆁ胣貀鳧趀臣芁苣낁볯膀苣蚃苣莃菣ꮃꧨ鎨苣芁ꇨ馁苣芀臣蚁臣ꪁ臣貂臣膀菣讃菣袃볯ꊼ볯꾁菣ꦃ苣ꆃ菣袃苣醃苣鞃菣ꒂ菣꺁곦꺁苣蚃菣뢂臣ꆸ臣芀戼㹲 릂菣ꎂ菣鞃菣ꚩ꣩ꚃ菣莃菣銼볯邼臣ꖻ룤꺁菣뢂菣꾂苣뾽铧馁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯鞼胣㲑䐯噉ਾ䐼噉邀闦醼볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㄰㔷⼼㹡⼼䥄㹖 릂菣ꎂ菣鞃菣ꚩ꣩ꚃ菣莃菣꾁胣肉룤꺁菣꾂苣ꮃ臣龁苣꺁苣蚃苣莃菣ꮃ菣莃菣銂ꓦꊴ臣讂臣膂臣膀뫥馨볯릂菣ꎂ菣鞃菣뢼苣뎃菣莃苣릂볯릂菣ꎂ菣鞃菣림苣뎃菣莃苣릂볯銂뷤ꢔ臣讂胣节臣袼苣蚃苣莃菣ꮃ볯ꒂ菣螃菣꾂苣貼苣蚃苣莃菣ꮃ볯ꒂ菣螃菣꾂苣覼臣誁臣讂苣蚃苣莃菣ꮃ菣莃菣貁苣莃菣閁苣ꚁ臣ꪁ臣貂臣袼跥ꆁ胣貀臥趀臣芁苣낁볯膀苣蚃苣莃菣ꮃꧨ鎨臣趸郥베臣ꪁ苣膀菣꾂苣ꮃ菣궃菣꾂볯钼볯꾁臣꺁菣ꦃ苣ꆃ菣袃苣뒠ꏦ馁苣芀戼㹲���릂菣ꎂ菣鞃菣ꚩ꣩꾁菣ꦃ苣ꆃ菣袃꿦꺁鏦鲽臣芁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯颼胣㲑䐯噉‾뮃苣ꮃ菣ꆂꧨ鎨戼㹲 ꊂ菣閃苣ꚩ꣩ꚃ菣莃菣銼볯邼臣膀臣꺁苣ꮃ菣ꆂ胥ꮁ鿥ꖁ臣ꚁ胣낈鷦馁苣閃菣낂菣뎃菣銂뿤膌臣龁臣뒠ꏦ馁苣芀菣讃菣袃볯ꎼ볯꾁胣螌껥閁苣龁苣ꮃ菣ꆂꧨ鎨ꧦ붃볯ꊂ菣閃苣龩菨覼臣鎾臣ꚁ胣芏藧ꒀ胣芏藧ꊂ菣閃苣ꮁ꿥馁苣閃菣낂菣뎃菣꺁룤辀飦閁苣ꚩ꣩馁苣芀볯ꢡ볯醼臣膀룤龮雦꺁뷥讅臣袂苣ꊂ菣閃苣龩菨誏臣ꊖ胩馁苣钯볨꺁臣膂臣ꒀ苣몤臣ꚁ臣讂胣覼苣鞁菣ꦃ苣ꆃ菣袃臣趸郥베臣芁苣낁胣ꊂ菣閃苣ꚩ꣩ꚃ菣莃菣銼볯邼臣鶁苣銂ꃧ蒣臣讂胣节臣袐ꃦꞁ臣貂臣膀菣讃菣袃볯ꎼ볯꾁臣貂苣醃苣鞃菣ꒂ菣薆臣ꆬ臣릂菣벃苣뢁胩讂胣㲂牢ਾ†苣ꮃ菣ꆂꧨ鎨菣讃菣袃臣ꆬ臣궃苣莃苣銂뷤ꢔ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯銼볯醀⼼䥄㹖㰊䥄㹖胣낕볯醼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㜱㰶愯㰾䐯噉ਾ†苣ꮃ菣ꆂꧨ鎨臣膀苣鞁苣ꮃ菣ꆂꧨ鎨迥붃菣ꦃ苣貁苣莃菣閁苣ꚁ臣貂臣開뷤꾏菨ꮁ臣誂胣ꢅ臣꺁菣ꦃ苣ꆃ菣袃臣骀臩閁臣覂苣讂胣鎁臣ꚩ꣩꾁胣늼볯ꊼ볯ꮂ菣벃菣벃菣ꮁ臣蒁臣ꂁ臣ꦁ铧閁苣讂胣ꮂ菣벃苣뎃菣莃苣릂菣벃菣ꞁ臣膀臣貂臣邃苣醃苣閁苣讂胣㲂牢ਾ†苣ꮃ菣ꆂꧨ鎨臣閃菣낂菣뎃菣躯臣趓뷤ꞁ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鎼볯醀⼼䥄㹖†菣ꮂ菣벃ꧨ鎨戼㹲 ꊂ菣閃苣ꚩ꣩ꚃ菣莃菣誏臣鶁臣颍룤芏藧ꒀꧨ鎨臣꾁闧ꪁ苣膀苣ꦃ菣ꚩ꣩ꚃ菣莃菣銼볯邼臣膀苣벃鳦辰苣ꦃ菣袼뷯辽뷯辽뷯㲒畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯ꦼ볯㲮猯扵覼迥뎁鳦Ꞥ苣ꦃ菣袼뷯辽뷯辽뷯㲒畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯ꆼ볯㲸猯扵覼苣讻臣ꚁ菣ꦃ苣ꆃ菣袃臣늼볯ꊼ胥ꢁ胣ꮂ菣벃胥꺁꿧늛臣銂꿦莼臣讂胣袼苣ꦃ菣궂菣꾁胣肜냥誏臣肜ꓥꒀ苣薌郥馁苣芀볯节臣閃菣낂菣뎃菣貁苣ꦃ菣ꚩ꣩ꮁ룤袐ꃦꞁ臣貂臣膀菣讃菣袃볯꒼볯꾁臣貂苣뒠ꏦ馁苣芀臣蚁臣ꪁ臣貂臣膀菣讃菣袃볯꒼볯꾁臣貂苣醃苣鞃菣ꒂ菣薆臣ꆬ臣릂菣벃苣뢁胩讂胣㲂牢ਾ†苣ꦃ菣ꚩ꣩ꚃ菣莃菣꾁곦꺁菣뢂菣꾂苣뾽铧馁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯醼胣㲑䐯噉ਾ䐼噉邀闦醼볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㄰㜷⼼㹡⼼䥄㹖 ꢡ볯銼臣膀룤龮雦꺁뷥讅臣袂苣ꮂ菣벃ꧦ붃迥뎁雩ꎀ臣讂꿦莼苣몤臣ꚁ臣讂胣ꮂ菣벃ꧦ붃臣膀苣ꦃ菣궂菣薆臣肜냥誏臣肜ꓥꒀ苣薌郥閁臣讂臣ꢁ臣ꦁ裥ꮁꫨ躘臣貂苣袂臣ꮁ껥뺏臣貂苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯銼胣㲑䐯噉‾ꮂ菣���ꧨ鎨臣膀苣鞁苣ꦃ菣ꚩ꣩꾏菨閃菣낂臣뮂菣袃臣貂臣蒁臣醁苣낁胣邃苣醃苣閁苣讂胣㲂牢ਾ†苣ꦃ菣ꚩ꣩꾁胣늼볯ꊼ볯ꊃ菣覃臣誁臣ꚁ臣醁臩ꢔ臣貂苣芀苣ꦃ菣ꒂ菣螃菣꾂苣ꊃ菣覃臣꾁胣鶁苣꾁菣ꒂ菣릂臣貂苣芀苣ꦃ菣ꚩ꣩ꚃ菣莃菣銼볯邼臣膀苣ꦃ菣ꚩ꣩銂볯膀볯膀迥뎁볯꺁郥膃菣뎃菣ꮃ臣ꖈ胣ꮁ臩ꢔ臣讂胣ꢅ臣꺁菣ꎃ菣趃菣꺁ꧨ鎨뗧鲞臣隫郧趩臣貂苣芀跥ꆁ胣閃菣낂菣뎃菣꾁胣鶁苣貁菣ꎃ菣趃菣꺁볯ꒁ볯ꒁ臣袐ꃦ鞁臣芙臣邙臣ꚁ苣ꦃ菣ꚩ꣩ꮁ郥베臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鎼볯醀⼼䥄㹖†苣ꦃ菣ꚩ꣩꾁菣ꦃ苣ꆃ菣袃꿦꺁鏦鲽臣芁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯钼胣㲑䐯噉‾뮃苣蚃菣랂菣込볯ꚩ꣩㲓牢ਾ†苣ꮃ菣ꆂ迥뎁苣ꦃ菣ꚩ꣩꾁胣醃苣鞃菣ꒂ菣릂菣벃苣銂胩躁臣讂菣ꦃ苣ꆃ菣袃臣醁苣趓뷤馁苣貁胣릂菣뎃苣ꮃꧨ鎨臣떂菣鞃菣뺁臣꾁菣ꦃ苣ꆃ菣袃苣趓뷤馁苣릂菣뎃苣ꮃ菣莃菣ꆂ볯ꦼ볯銂뷤ꢔ臣讂胣릂菣뎃苣ꮃꧨ鎨菣讃菣袃볯ꖼ볯꾁胣芏藧릂菣뎃苣ꮃ胥袼뷯钽뷯躽뷯覽뷯㲌畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯薽뷯薽뷯薽뷯莽뷯㲅猯扵覼臣膀臣꺁뷤꺽臣誁臣讂苣蚃菣랂菣邃菣閃苣銼볯邼蛥꺁韦颭胥ꢁ苣钯볨馁苣芀菣讃菣袃볯ꖼ볯꾁胣릂菣뎃苣ꮃꧦ붃臣袂臣ꚁ賦骮臣貂臣钯볨銂釥몇臣趉臣膀迥ꞅ苣蚃菣랂菣ꒀ迥뎁苣蚃菣랂菣邃菣閃苣ꒀ臣ꆸ胨ꢁ胣릂菣뎃苣ꮃ菣릂苣袼뷯膽뷯讽猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰뎼볯ꖼ볯ꎼ볯겼⼼畳㹢볯ꢁ苣鎃菣袃꿦ꮁꯨ蚐ꧧ馁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯閼胣㲑䐯噉‾肸껥붖臣ꊽ藦ꞁ臣膀苣蚃菣랂菣龩菨뚊藦醃菣ꆃ菣뾂臣膀苣ꮃ菣ꆂꧦ붃迥뎁苣ꦃ菣龩菨꺁諧讅菣ꦃ菣벃苣ꢁ臣ꚸꇨ钯볨銂賦骮臣讂胣㲂牢ਾ†苣鞁苣蚃菣랂菣ꚩ꣩ꮁ룤袐ꃦꞁ臣貂臣떂菣鞃菣꾁ꃧ蒣臣貂胣베듧閁苣龁苣蚃菣랂菣ꒀ臣릂菣뎃苣ꮃꧨ鎨룤袐ꃦ趓뷤뚊藦醃菣ꆃ菣뾂臣鎾臣ꚁꓥ뒛臣貂苣芀戼㹲 节臣릂菣뎃苣ꮃꧨ鎨臣袐ꃦ馁苣낁胣떂菣鞃菣꾁軦閁ꧨ鎨苣鞏臣讂胣节臣놷臣ꚩ꣩ꮁ룤袐ꃦꞁ臣貂臣膀ꃦ趴臣貂臣릂菣뎃苣ꮃ胥꾁苣蚃菣랂菣ꚩ꣩袐ꃦ뮃볯ꚩ꣩趸郥베鏦鲽諧讅菣ꦃ菣벃苣ꮁ뻥ꎁ臣覤鯦閁苣讂胣㲂牢ਾ†苣鞁苣蚃菣랂菣誏臣놷臣꺁룤ꚩ꣩ꮁ郥베臣芁苣낁胣베듧閁苣龁苣蚃菣랂菣ꒀ臣릂菣뎃苣ꮃ迥뎁볯ꚩ꣩袐ꃦ趓뷤뚊藦醃菣ꆃ菣뾂臣鎾臣ꚁꓥ뒛臣貂苣芀戼㹲 ꢡ볯鎼臣膀룤龮雦꺁뷥讅臣袂苣릂菣뎃苣ꮃꧨ鎨룤袐ꃦ趓뷤膀苣蚃菣랂菣ꚩ꣩袐ꃦ뮃볯ꚩ꣩趸郥베鏦鲽胣誏臣릂菣뎃苣ꮃ迥뎁볯���ꚩ꣩袐ꃦ趓뷤뚊藦醃菣ꆃ菣뾂臣龁苣꺁胥膀迥뎁臣貂苣꺁雩ꎀ臣讂ꧦ붃苣몤臣ꚁ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鎼볯醀⼼䥄㹖†菣讃菣袃볯ꖼ볯꾁胣릂菣뎃苣ꮃ菣莃菣銂苣뎃菣ꮃ苣ꒂ菣邃菣閃苣薆臣뢛뻨肂觥ꮁ胣鶁苣覂苣뢛뻨뾁苣蚃菣랂菣麃苣꾂臣麃苣꾂臣讂胣钃苣뮂菣趓뷤ꢁ苣뎃菣ꮃ苣蚃菣랂菣趓뷤꺁룤ꪁ럥꾁胣ꦁ臣袂臣ꮁ苣蚃菣랂菣ꒀ苣뾂苣ꮃ菣莃菣ꆂ臣覂ꓦꊴ臣讂臣膀迥뎁苣ꒂ菣邃菣閃苣薆臣뢛뻨肂臣ꮁ臣讂胣릂菣뎃苣ꮃ菣릂苣뢛뻨뾁諧讅菣ꦃ菣벃苣貁苣蚃菣랂菣麃苣꾂臣낕臣讂苧꾁胣릂菣뎃苣ꮃ菣릂苣貁苣蚃菣랂菣ꚩ꣩ꮁ뷤ꢔ臣貂苣릂菣뎃苣ꮃ胥ꮁ뷥뾟臣讂臣ꮁ꿥鞁臣膀苣蚃菣랂菣麃苣꾂鯦벾臣貁鯦낖臣貂苣鎃菣袃鷩ꮁ뷥뾟臣讂臣ꢁ臣芁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯鞼胣㲑䐯噉‾誸뿨鞁臣芦ꛨ겓볤뎂菣覃臣醑臣ꚁ胣ꖻ룤꺁鏦벼苣벃菣꾁苣蚃菣랂菣ꚩ꣩ꚃ菣莃菣銼볯邼臣궃苣莃苣銂鯦ꮁ꣨낿臣ꚁ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鎼볯醀⼼䥄㹖㰊䥄㹖胣낕볯醼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㜱㰸愯㰾䐯噉ਾ䐼噉邀闦醼볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㄰㤷⼼㹡⼼䥄㹖㰊䥄㹖胣낕볯醼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㠱㰰愯㰾䐯噉ਾ†菣것菣ꂃ雩讧菣놂菣袃臣覂臣릂菣뎃苣ꮃ菣벃菣뚊藦醃菣ꆃ菣뾂臣膀苣蚃菣랂菣ꚩ꣩誏臣鶿껧貁菣꾂苣ꮃ꿦꺁鏦鲽臣꺁臣膀臣龁臣떂菣鞃菣躯臣趓뷤ꪁ臣讁苣螌껥鞁臣誁苣膀뻥ꎁ臣鎁苣覂臣趓뷤ꮁ郥뺁苣讂菣莃菣꺁闦銂賦骮臣ꚁ臣讂볯肸껥붖臣ꊽ藦ꞁ臣膀볯뺁臣꾁볯鎃菣袃볯芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯馼胣㲑䐯噉‾릂菣뎃苣ꮃ菣벃菣貁胣龜胣ꞁ臣讂駦ꮁ臣膀苣蚃菣랂菣趓뷤꾁菣꾂苣ꮃ꿦ꞁ臣讂臣膀럦閁ꧨ鎨臣떂菣鞃菣躯臣芁苣芀触躸臣钃苣뮂菣꺁ꃥ袐胣ꖋ맥꺁苣뎃菣ꮃ臣놷臣ꚩ꣩ꮁ郥베臣讂臣节鿧貂臣膀臣龁诨늹臣떂菣鞃菣꾁럦閁ꧨ鎨臣趸郥베臣芁苣讁苣ꖟ苣ꪁ臣芀臣貂苣꺁ꃥ袐胣閃菣벃菣讖꟥醃苣莃菣讁苣꺁鳦鶈臣릂菣뎃苣ꮃ볯뎼뷯薽뷯莽뷯貽볯覽뷯鎽뷯覼諧讅菣ꦃ菣벃苣꾁胣ꦁ臣릂菣뎃苣ꮃ鯦낖鏦鲽苣芁ꇨ馁苣꺁臣銂뇦骮臣讂胣节臣肜裥꺁苣蚃菣랂菣貁胣龜胣ꞁ臣貂臣膀菣꾂苣ꮃ蛥꺁鳦鶈臣떂菣鞃菣꺁럦閁ꧨ鎨뗧鲞臣膀苣蚃菣랂菣誏臣몼ꧨ鎨郥베鏦鲽胣뺁臣꾁苣蚃菣랂菣ꚩ꣩袐ꃦ뮃볯ꚩ꣩趸郥베鏦鲽臣ꦁ臣覂苣벑蟥馁臣讁苣몱껥馁苣芀菣꾂苣ꮃ菣궃菣꾂臣誁臣讂菣벃苣꺁뗦貂臣龁苣꺁ꛦ膦鏦벼苣벃菣꾁���릂菣뎃苣ꮃꧨ鎨鏦鲽臣놷臣ꚩ꣩趓뷤ꢁ臣鎖臣뢛뫤鲽铧銂ꛦ낿臣ꚁ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯钼볯醀⼼䥄㹖†苣蚃菣랂菣ꚩ꣩꾁胣릂菣뎃苣ꮃꧨ鎨迥붃菣ꦃ苣ꮁ苣ꎁ臣開뷤꾏菨ꮁ臣貂苣芀菣것菣ꂃ雩讧菣놂菣袃臣놅臣许雦뢁룦閁苣讂苣蚃菣랂菣邃菣閃苣ꆄ菣ꦃ苣꾁胣ꚩ꣩꺁賦開臣节뷥뾟苣躸臣讂胣ꢡ볯隼臣膀苣蚃菣랂菣ꚩ꣩꾏菨膀苣蚃菣랂菣邃菣閃苣ꆄ胣誏臣鶿껧袸臣릂菣뎃苣ꮃ菣莃菣ꆂ蓧閃菣낂臣뮂菣蚃苣뎃苣ꮁ鿥ꖁ臣龁苣蚃菣랂菣ꚩ꣩ꚃ菣莃菣銼볯邼臣開뷤銂ꓧ鞁臣蒁苣芀ꇨ醼볯ꮁꓧ馁苣蚁臣膀苣蚃菣랂菣邃菣閃苣ꆄ菣ꦃ苣꾁胣隻臣릂菣뎃苣ꮃ臣ꊖ뿤馁苣辏蛥뚊藦醃菣ꆃ菣뾂臣誸鯦趁臣讂胣㲂牢ਾ†苣蚃菣랂菣ꚩ꣩꾁菣ꦃ苣ꆃ菣袃꿦꺁鿥隺臣膀臣龁臣钃苣뮂菣躯臣몟뫦ꞁ臩財臣讂臣ꢁ臣ꞁ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯钼볯醀⼼䥄㹖†菣릂菣뎃苣ꮃ迦馆ꧦ붃戼㹲 ꖋ맥꺁鋧莢臣许臣꾁胣钃苣뮂菣隃菣莃苣颼볯ꊼ臣膀菣ꦂ菣낂菣궃菣꾂볯钼볯讁苣钃苣뮂菣躯臣릂菣뎃苣ꮃ胥銂迥醁苣鎁臣貁臣趁苣芀菣꾂苣ꮃ菣궃菣꾂볯钼볯꾁胣릂菣뎃苣ꮃ迥ꞅ胥鎽뷯薽뷯莽뷯貽猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰늼뷯蚽뷯銽뷯躽뷯薽⼼畳㹢臣麡볤꺁触閳臣鎁臣钃苣뮂菣躯臣릂菣뎃苣ꮃ胥銂蟥蚐臣讂胣节臣릂菣뎃苣ꮃ菣벃菣뚊藦醃菣ꆃ菣뾂臣떂菣鞃菣躯臣趓뷤銂賦骮臣ꚁ臣貂臣膀菣꾂苣ꮃ菣궃菣꾂菣讃菣袃볯钼볯꾁胣鶁臣閃菣낂菣뎃菣꺁藥ꚁ臣떂菣鞃菣ꮁ臣蒁臣閃苣뎃苣隃菣莃苣颼볯ꆼ臣覂臣릂菣뎃苣ꮃ胥銂뷤ꢔ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯钼볯醀⼼䥄㹖†뻤袁臣膀苣鞁苣鞃菣놂菣랂菣뎃볯銼볯醼臣릂菣뎃苣ꮃ菣莃菣ꆂ蛥뢁菣꾂苣ꮃ雦ꊽ苣뎂菣벃臣讂臣ꢁ苣膦뇦鞁胣떂菣鞃菣躯臣趓뷤貁볯鎃菣袃鏦鲽臣芁苣낁胣릂菣뎃苣ꮃ諧讅菣ꦃ菣벃苣꾁믤许臣袂臣ꮁ苣莃菣閁苣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯钼볯醀⼼䥄㹖†苣蚃菣랂菣辏蛥ₙ††††††††††††龜戼㹲 릂菣뎃苣ꮃꧨ鎨迥붃†††††††††††鳧㲟牢ਾ†苣蚃菣랂菣龩菨₽††††††††††††뢸臣㲫牢ਾ†苣蚃菣랂菣麃苣꾂††††††††††††볯颽뷯蚽戼㹲 릂菣뎃苣ꮃ菣릂苣뢛뻨뾁†††††††††볯颽뷯蚽戼㹲 릂菣뎃苣ꮃꧨ鎨룤袐ꃦ趓뷤ₜ†††††††꺽迦㲛牢ਾ†苣蚃菣랂菣ꚩ꣩袐ꃦ뮃볯ꚩ꣩趸郥베鏦鲽††뷧鮏戼㹲 릂菣뎃苣ꮃ迥뎁볯ꚩ꣩袐ꃦ趓뷤ₜ†††††꺽迦㲛牢ਾ†苣蚃菣랂菣邃菣閃苣ꆄ††††††††††臥㲽牢ਾ†뿤ꆮ룦뾁苣蚃菣랂菣邃菣閃苣ꆄ††††††臥㲽牢ਾ†苣���菣랂菣ꊃ菣覃††††††††††††鳧袼菣꾂苣ꮃ꿦꺁鏦鲽볯芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯钼胣㲑䐯噉‾뮃럦閁ꧨ鎨戼㹲 놷臣邃菣閃苣ꚩ꣩ꚃ菣莃菣銼볯邼臣膀苣뎃菣ꮃ臣骽胥ꢁ胣銼菣莃菣ꆂ볯ꦼ볯薆臣베듧閁苣ꚁ臣讂뷯ꒀ臣銂꿦莼臣膀苣鞁럦閁꿦莼臣놤闦馁苣낁臣꺁苣뎃菣ꮃ苣뒠ꏦ馁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯閼胣㲑䐯噉‾节臣놷臣ꚩ꣩ꮁ郥베臣膀볯뢛뻨뾁迥붃臣貀鳧趀臣芁苣낁胣놷臣ꚩ꣩ꚃ菣莃菣銼볯邼臣鶁臣떂菣鞃菣꺁뷤꺽臣邃菣閃苣ꮁ胣蒯鯥뮼볯貼볯㲒畳⁰浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢뷯㲚猯灵뾼猼灵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰뚼볯겼볯ꖼ⼼畳㹰볯㲿畳⁰浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯ꦼ볯㲴猯灵뾼猼灵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰ꎼ볯떼볯뒼⼼畳㹰볯醼볯ꮁ苣ꦃ菣鞃臣貂臣떂菣鞃菣몼胥銂觥鎽臣讂胣袼룤龮雦꺁뷥讅臣꾁胣몼胥꾁볯钼菣莃菣ꒀ臣芁苣膀뻥ꎁ臣몼볯뚼볯겼볯ꖼ볯ꊼ볯뒼볯ꎼ볯떼볯뒼臣銼볯ꮁ苣莃菣閁苣讂胣覼菣讃菣袃볯ꖼ볯꾁胣릂菣뎃苣ꮃ迥뎁볯ꚩ꣩袐ꃦ趓뷤뚊藦醃菣ꆃ菣뾂臣鎾臣ꚁ胣릂菣뎃苣ꮃ菣莃菣ꆂ胥銂鯦낖臣讂胣ꚃ菣莃菣銼볯邼臣膀苣뎃菣ꮃ苣랷郥ꚃ菣莃菣뢁룦馁胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯钼볯醀⼼䥄㹖†苣鞁럦閁ꧨ鎨臣趸郥베臣芁苣낁胣ꚃ菣莃菣銼볯邼臣鶁臣閃菣낂菣뎃菣銂ꃧ蒣臣膀苣蚃菣랂菣ꚩ꣩袐ꃦ뮃볯ꚩ꣩趸郥베鏦鲽諧讅菣ꦃ菣벃苣ꮁ뻥ꎁ臣鶁臣떂菣鞃菣꺁뷤꺽臣릂菣뎃苣ꮃ胥銂鯦낖臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯钼볯醀⼼䥄㹖†룤낿臣龁ꛦ膦鏦벼苣벃菣ꮁ釩뾁臣膀믤许臣겓볤뎂菣覃臣놷臣ꚩ꣩ꚃ菣莃菣銼볯邼臣궃苣莃苣膀迥뎁軦閁ꧨ鎨臣릂菣뎃苣ꮃ鏦鲽臣꺁雩꺁鯧銺뷤ꢔ苣뒛臣風뿨鞁臣蒁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯颼胣㲑䐯噉ਾ䐼噉邀闦醼볯馼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㄰ㄸ⼼㹡⼼䥄㹖 閼臣꺁諧讅菣ꦃ菣벃苣貁胣钃苣뮂菣隃菣莃苣颼볯ꊼ蛥꺁럦閁臣ꊖ뿤馁苣趓뷤ꮁ뷥뾟臣讂胣鎁苣覂臣몼ꧨ鎨迥붃胣몼ꧨ鎨鯦벾臣꾏菨膀볯邃菣閃苣ꆄ胣놷臣龩菨膀迥뎁뿤ꆮ룦뾁볯邃菣閃苣ꆄ臣芁苣芀菣꾂苣ꮃ菣벃菣궂菣莃苣ꖃ藥ꮡ菣놂菣袃臣膀럦閁ꧦ붃胣몼ꧨ鎨迥붃胣誏臣몼鯦벾臣꾏菨뚊藦醃菣ꆃ菣뾂臣뺏鳥ꒀ苣鮾뗧鞁胣肸雦閃菣벃菣讖꟥醃苣莃菣꾁胣몼菣莃菣ꆂ蓧誏臣鶿껧袸臣銼菣莃菣ꆂ蓧뚊藦醃菣ꆃ菣뾂臣뺏鳥ꒀ苣鮾뗧馁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯馼胣㲑䐯噉‾몼ꧨ鎨迥붃菣ꦃ苣꾁胣钯볨銂该鲽룤붃臣馁苣芀럦閁ꧨ鎨臣開뷤趸菨ꮁ臣貂苣ꢁ菣讃菣袃볯ꖼ볯꾁胣���臣钯볨膀迥뎁裧貾臣놷臣邃菣閃苣ꒀ臣뺯臣讂뷤覭臣꺁鯦낖苣邃苣醃苣鞁胣閃菣낂菣뎃菣銂곦꺁鏦鲽臣ꆸ臣芀臣讁臣ꪁ臣覂胣릂菣뎃苣ꮃ胥꾁臣龁臣节럦閁ꧨ鎨臣袐ꃦ鞁臣讁臣袂臣ꮁꓥ뒛臣貂苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯邼胣㲑䐯噉‾ꢡ볯钼臣膀볯ꒁ臣醃菣ꆃ菣뾂胣뎍臣몼ꧨ鎨迥붃胣몼鯦벾臣꾏菨膀볯邃菣閃苣ꆄ胣誏臣鶿껧袸臣몼菣莃菣ꆂ蓧꺁鯧銺뷤ꢔ苣뒛臣風뿨鞁臣蒁苣芀룤낿臣龁苣蚁臣膀럦閁菣莃菣ꆂ鏦鲽臣몼菣莃菣ꆂ蓧貁胣북胣ꞁ臣讂ꃥ袐臣邙臣ꚁ駧龔臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯閼볯醀⼼䥄㹖†럦閁ꧨ鎨臣膀苣뎃菣ꮃ꿦꺁鏦鲽臣芁苣芀苣ꒂ菣ꊂ苣覃菣벃菣袼ꓥ趇苣뎃菣ꮃ臣貁胣북胣覼臣꾁胣놷臣ꒀ臣閃菣낂菣뎃菣꺁룤莿臣誁臣ꚁ꣨鞮臣貂胣閃菣낂菣뎃菣薆臣蒐苣뎃菣ꮃ臣늉뷥ꚁ苣貂苣芀臩ꖈ菣궃菣꾂볯钼볯貁苣뎃菣ꮃ苣邃菣莃苣麃苣꾂苣ꦁ裥ꮁ铧邈臣讂臣ꞁ胣ꢂ苣ꪃ苣릂菣ꊃ菣覃臣꾁胣钃苣뮂菣궸뿥貁菣ꪃ菣蚃苣隃蛥ꮁ郥뺁苣讂臣Ꚑ臣ꮁ뻤颭臣ꚁ胣ꢅ臣꺁苣뎃菣ꮃ臣ꪂ菣뺁臣꾁苣閃臣閽苣讁臣芁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯銼胣㲑䐯噉‾뮃迥隦볯㲺牢ਾ†菣꾂苣ꮃ菣궃菣꾂볯钼볯꾁胣꾏ꛨ몼菣뢂苣뾂볯꺼볯ꞁ臣讂苣閃菣Ꚃ苣ꊂ苣꾂苣ꮃ迥붃臣것苣릂苣銼볯邼苣薆菩ꮁ뛧膌臣ꚁ臣讂胣隃菣莃苣颼볯ꊼ臣膀菣것菣ꂃ雩讧菣놂菣袃臣궁臩馁苣ꢁ臣꺁菣뢂苣뾂볯꺼볯銂苣ꪃ苣馁苣芀菣궃菣꾂볯钼볯꾁胣芁苣ꪂ菣뢂苣꾂菣꺁鳦鶈臣꾏ꛨ떂菣鞃菣ꮁ臩螁臣讂臣鶁臣ꒀ苣뮂菣袃臣膀ꫨ몇臣芙臣鶁苣銂苣ꪃ苣馁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯鎼胣㲑䐯噉‾뮃럦袐戼㹲 랷郥꾁胣떂菣鞃菣꺁볯膀볯膀볯膀迥뎁볯ꒀ臣膀菣것菣ꂃ菣莃菣ꆂ볯钼볯薆臣鶁臣떂菣鞃菣꺁뷤꺽臣베듧閁苣ꚁ臣讂볯膀볯膀볯膀迥뎁볯ꒀ臣銂꿦莼臣讂胣랷郥閁苣龁苣ꦃ菣꾁胣㲁牢ਾ†볯랷郥龩菨覼볯邺苣ꦃ菣閃苣꾂苣誼뫦ꮂ菣벃胣㲁牢ਾ††††††††††††ꇨ袅苣ꦃ菣閃苣꾂苣誼ꇨ袅苣ꦃ菣覼戼㹲ꢁ臣ꚁ꣨鞮臣貂苣芀臣鎁臣膀럦袐ꧦ붃臣銼臣꺁ꧧꮁ臣꺁鏦鲽苣ꦁ铧馁苣讁苣螌껥馁苣뚊藦醃菣ꆃ菣뾂臣芁苣膀뫦ꮂ菣벃菣ꆂ苣뾂迥뎁ꇨ袅苣ꦃ菣閃苣꾂苣꾁苣ꦃ菣랷郥趓뷤ꮁ뷥뾟臣讂諧讅菣ꦃ菣벃苣ꞁ臣讂胣袼苣뎃菣ꮃ臣鲀뫦鶀臣芁苣膀菣것菣ꂃ菣莃菣ꆂ臣鲀ꇨ袅胢ꞁ臣讂胣覼戼㹲 ꢡ볯颼臣膀럦袐ꧦ붃볯颽볯馽볯꺁臣膂臣肸껥붖臣ꊽ藦꺁胥銂룤袁苣芀ꧦ붃苣鞃苣ꞃ菣꾁胣ꂊ껧膀룦鞮胣蚀룦鞮胣肜냥膀迥뎁鳦Ꞥ苣ꮐ苣���⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯钼胣㲑䐯噉‾邺苣ꦃ菣閃苣꾂苣꾁苣뎃菣ꮃ苣ꦃ菣ꒀ매鞮臣龁苣꺁ꋨ鞹闦銂賦骮臣膀ꇨ袅苣ꦃ菣閃苣꾂苣꾁菣것菣ꂃ菣莃菣ꆂ苣ꦃ菣ꒀ매鞮臣龁苣꺁ꋨ鞹闦銂賦骮臣讂胣ꢡ볯鞼臣膀뫦ꮂ菣벃菣ꆂ苣뾂迥뎁ꇨ袅苣ꦃ菣閃苣꾂苣꺁臣膂臣肸껥붖臣ꊽ藦꺁胥銂룤袁苣芀볯ꢡ볯鞼蛥꺁럦鞭胢뎼胢誏臣鲀볯鶀臣膀胢邺胢誏臣鲀ꇨ袅胢꺁闧麪臣芁苣芀戼㹲㰊䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㠱㰲愯㰾䐯噉ਾ†苣ꦃ菣誏臣ꊂ菣閃苣邵黦꾁胣뮼볯貼볯㲒畳⁰浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯꾼볯꾼볯㲲猯灵뾼猼灵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰뚼볯겼볯ꖼ⼼畳㹰볯㲿畳⁰浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯ꦼ볯㲴猯灵뾼猼灵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰ꎼ볯떼볯뒼⼼畳㹰裢醼볯ꮁ苣ꦃ菣鞃臣貂苣芀룤龮雦꺁뷥讅臣꾁胣ꮂ菣벃迥뎁苣ꮃ菣ꆂ胥꾁볯鎃菣袃胥ꞁ臣誂胣鎾臣ꚁ볯꾼볯꾼볯뾼볯ꆼ볯떼볯뾼볯ꦼ볯뾼볯꾼볯꺼볯꾁볯ꮁ苣莃菣閁苣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯閼볯醀⼼䥄㹖†럦袐迥붃諧讅菣ꦃ菣벃苣꾁럦袐苣꾏菨ꮁ臣膀럦袐臣늼볯ꊼ볯ꮂ菣벃菣벃菣궸臣邙臣ꚁ该鲽迥붃臣ꪁ苣芀럦袐迥붃胥꾁胣钃苣뮂菣ꊃ菣覃菣놂菣袃臣覂裥ꖝ臣讂胣㲂牢ਾ†볯Ꞽ볯ꆼ菣릂苣뢛뻨뾁諧讅菣ꦃ菣벃苣꾁胣꒵胣醷胣銝胣誏臣ꊂ菣閃苣膃菣뎃菣ꮃ臣ꦁ臣鎃菣袃鷩銂鯦낖臣讂臣讁苣몱껥馁苣芀戼㹲 ꮂ菣벃菣莃菣ꆂ蓧誏臣鶿껧袸臣ꮂ菣벃菣莃菣ꆂ蓧뚊藦醃菣ꆃ菣뾂苣膀럦袐鏦鲽臣놽鿩馁苣芀臣貂苣꺁迧ꢜ胥꾁菣것菣ꂃ雩讧菣놂菣袃臣覂臣芁苣芀戼㹲 ꢡ볯閼臣膀菣ꒂ菣ꦃ苣뎃蛥꺁럦袐臣誏臣馁臣貂苣꺁諧讅菣ꦃ菣벃苣꺁諥鲞苣몤臣ꚁ臣讂胣㲂牢ਾ†苣ꮃ菣ꆂ胥꾁胣貐꟦ꮁ蟥蚐臣貂苣芀뫦ꊂ菣閃苣閃苣꾂苣膀ꇨ袅苣ꮃ菣ꆂ菣ꆂ苣뾂胣誏臣ꊂ菣閃苣龩菨뚊藦醃菣ꆃ菣뾂臣膀苣ꮃ菣ꆂ럦袐苣뚈뻥馁苣芀苣ꮃ菣ꆂꧦ붃臣ꮂ菣벃ꧦ붃臣貐꟦ꞁ臣誂胣肸껥붖臣ꊽ藦ꞁ臣膀郥肸臣뮂菣袃臣ꒀ苣随苣芀뫦ꊂ菣閃苣閃苣꾂苣꾁苣ꮃ菣ꆂ胥鞹껧꺁臣膂臣ꮢ매낕苣螌껥鞁胣肸雦財藥ꊂ菣閃苣閃苣꾂苣꾁菣것菣ꂃ菣莃菣ꆂ苣ꮃ菣ꆂ胥鞹껧꺁臣膂臣ꮢ매낕苣螌껥馁苣芀ꇨ醼볯꾁胣邺苣ꮃ菣ꆂ菣ꆂ苣뾂迥뎁ꇨ袅苣ꮃ菣ꆂ菣ꆂ苣뾂臣龁苣꺁룤龮雦꺁뷥讅臣誁臣讂胨袁뻥讂胥銂菣릂菣鞁臣蒁苣芀볯ꢡ볯馼蛥꺁럦鞭胢뎼胢誏臣鲀볯鶀臣膀胢邺胢誏臣鲀ꇨ袅胢꺁闧麪臣芁苣芀볯㲉牢ਾ†苣뎃菣ꮃ菣莃菣ꆂ苣ꦃ菣誏臣ꊂ菣閃苣꾁胣낖臣蒁胥ꞁ鯦낖臣貂苣芀臣꺁苣뎃菣���臣龁苣꺁菣벃菣ꎂ菣莃菣节苣莃菣閁苣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯閼볯醀⼼䥄㹖†菣ꒂ菣ꦃ苣뎃볯钼볯꾁胣閃菣낂菣뎃菣躯臣몟뫦ꞁ苣ꦃ菣誏臣ꊂ菣閃苣銂铧邈臣讂胣랷郥ꮁ雩鞁臣膀郥颁뫦ꮂ菣벃迥뎁苣ꮃ菣ꆂ臣膀菣ꦃ苣ꆃ菣袃蛥꺁藥ꚁ臣ꮂ菣벃臣貂臣떂菣鞃菣ꮁ臩ꢔ臣貂苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯鞼胣㲑䐯噉‾뮻蓦꺁駦릂臣誁臣ꚁ臣膀럦袐鏦鲽臣龁臣隫郧钼껧꺁뷤貂臣貁苣꾂菣ꎂ菣ꞁ臣讂臣膀藥ꮁ苣꾂菣ꎂ菣ꞁ臣讂臣ꢁ臣ꪁ臣芀臣龁胣꾼뷯薽뷯Ꞽ볯꾁胣隫郧钼껧誏臣랷郥銂藥ꮁ룤붃臣馁苣鎁臣꾁臣趁苣貁胣龮髩蒚臣릊黦꾁胣芁臣讁苣邺臣ꒀ臣財藥薆臣뢛뻨뺁苣龁臣ꢁ郥颁臣芁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯颼胣㲑䐯噉‾뮃菣ꎂ苣ꪃ菣낂戼㹲 醃苣鞃菣ꒂ菣颼볯邼臣膀볯ꒁ臣궼韃볯螃苣뚂菣袃菣莃苣릂볯꒵胣醷胣誏臣銝臣蒐裦蚈臣鶁苣麁苣뺯뿥馁苣꒵菣ꎂ苣膀럧螃苣뚂胣誏臣銝菣ꎂ苣覼苣讻臣ꚁ菣ꎂ苣ꪃ菣낂苣蒵臣벾苣ꞁ臣讂胣钃苣뮂菣Ꞻ꣦袼뷯㲘畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯ꦼ볯꒼볯랼⼼畳㹢볯馽猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰랼볯꺼볯꾼볯㲷猯扵覼臣躽뷯辽뷯㲇畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯㲒猯扵궼菣莃菣꾁胣蒐苣ꦃ菣邈裥螃苣뚂菣袃菣莃苣릂苣螌臣몤臣芀賦鞁ꓧ閁苣龁菣袃菣莃苣릂ꛨꂴ臣膀럦袐臣貂臣ꮂ菣벃胥ꮁ뿨ꂊ臣貂苣芀꣨鞮臣貂臣꒵胣醷胣誏臣銝胥꾁胣몇諥ꮁ臣醁苣肉鳦꺁菣莃菣낕臣螈苣ꢍ臣覂苣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯閼볯醀⼼䥄㹖†볯螃苣뚂菣뎃苣꾁胣ꊂ菣閃苣ꒀ苣覤鯦鞁臣蒁胣覼戼㹲 ꖻ룤꺁鏦벼苣벃菣꾁蟥蚐苣芦뿨鞁臣蒁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯邼胣㲑䐯噉ਾ䐼噉邀闦醼볯邼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㄰㌸⼼㹡⼼䥄㹖 螃苣뚂菣뎃苣꾏菨뚊藦醃菣ꆃ菣뾂臣膀럦袐臣貂臣ꮂ菣벃臣螃苣뚂菣뎃苣銂迥붃臣馁苣芀뻥ꎁ臣膀苣鞁럦袐臣開뷤趸菨ꮁ臣貂臣蒁苣낁胣螃苣뚂菣뎃苣节该鲽룤붃臣閁苣讂胣랷郥꾁苣ꦃ菣ꒂ菣螃菣꾂苣ꊃ菣覃臣誁臣ꚁ臣開뷤趸菨ꮁ臣貂苣꺁臣膀菣ꎂ苣ꪃ菣낂苣ꮂ菣벃苣뎃菣莃苣릂菣벃菣ꮁ臣蒁臣開뷤趸菨ꮁ臣貂苣芀ꇨ銼볯꾁胣螃苣뚂菣뎃苣꾏菨誏臣랷郥꾏菨閃菣낂臣릊黦銂ꓧ鞁臣蒁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯醼胣㲑䐯噉‾肸껥붖臣ꊽ藦꺁觧Ꞁ臣ꆬ臣骀苣ꞁ臣讂胣辏蛥醃苣鞃菣ꒂ菣颼볯邼臣膀郥ꮂ菣벃裦蚈꿦ꮁ볯鎃菣袃苣覜臣ꚁ臣讂胣몇諥钃苣뮂菣閃苣벃菣莃菣꾁胣钼菣莃菣込苣ꦃ菣邈裥讨뫥ꮁ냥ꪁ臣馁苣袂臣ꮁ菣ꎂ苣馁苣薿ꛨ���貁臣讂胣鎾臣ꚁ菣袃菣莃苣릂苣ꒂ苣궼臣钼臣ꪁ苣膀郥麃菣ꪃ菣꾂苣膦듧꾁蓧ꚬ迥꺁볯鎃菣袃闦낕臣芁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯銼胣㲑䐯噉‾蚮臣꺁ꃥ袐胣ꢅ臣꺁苣ꦃ菣邈裥ꮁ臩ꢔ臣讂臣꾁볯ꒁ臣螃苣뚂菣袃菣莃苣릂臣膍裥ꞁ臣讂胣鞁臣鞁臣貁苣膀볯Ꞽ볯颼볯颼臣覂볯Ꞽ볯閼볯閼菣ꦂ菣麃菣袃臣꺁ꓥ鮏臣袂臣ꪁ诨늹臣뒠郥ꮁ臣膀뗨膀럧膀迥뎁鷩膃菣뎃菣ꮃ臣龁苣ꮁ裥薀臣螃苣뚂菣袃菣莃苣릂臣鮜臣鞁臣讁苣ꖟ苣ꪁ臣芀臣꺁郧놔臣覂胣醃苣鞃菣ꒂ菣颼볯邼臣膀뗨膀럧膀迥뎁鷩邈裥꺁臣膂臣ꖈ胣꺁菣ꎂ苣麃菣ꪃ菣꾂苣銂뷤ꢔ臣ꚁ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯隼볯醀⼼䥄㹖†볯鎃菣袃苣ꦃ菣邈裥ꒀ苣钼菣莃菣込苣ꦃ菣邈裥뺁臣螃苣뚂臣讂臣꾁볯鎃菣袃ꛨꂴ臣膍裥ꞁ臣讂胣节臣꺛꣦钃苣뮂菣閃苣벃菣莃菣貁胣袂苣醰臣蒁菣莃菣込苣ꦃ菣膃菣뎃菣ꮃ苣覜臣ꚁ臣貂臣膀菣ꎂ苣膦듧꾁苣誂ꓥ辁臣鎃菣袃苣薿ꛨꢁ臣鞾苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯钼胣㲑䐯噉‾肸껥붖臣ꊽ藦ꞁ臣膀菣ꎂ苣麃菣ꪃ菣꾂苣꾁胣ꢅ臣꺁ꛨꂴ臣龁苣꺁鳧ꖕ駦ꒀ臣鞁臣邼苣ꢔ臣ꚁ菣궃苣ꦃ菣馁苣鎁臣貁臣趁苣芀볯鎁苣꾁胣螃苣뚂菣뎃苣銂该鲽룤붃臣馁苣芀볯鶁臣ꞁ胣鎁苣覂臣麃菣ꪃ菣꾂苣銂臩螈臣궃菣覃臣讂臣膂臣膀苣閃菣Ꚃ苣ꊂ볯銼볯醼苣뾽铧馁苣겲믤貁铧骁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯閼胣㲑䐯噉‾誸뿨鞁臣閃菣벃菣꾃菣꾂臣膀껦ꦁ臣ꊂ菣ꪃ苣벃苣ꞃ菣ꮁ臣ꎁ臣膍裥ꞁ臣趂臣芀戼㹲螃苣뚂菣뎃苣꾁胣閃菣낂菣뎃菣躯臣趓뷤ꞁ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯隼볯醀⼼䥄㹖†菣隫郧钼껧㲗牢ਾ†럦袐菣讃菣袃볯ꚼ볯ꢁ郥颧臣膀ꯨ蚐볦鞮菣讃菣袃볯ꢼ볯꾁胣낈鷦馁苣ꒀ迥뎁菣것菣ꂃ菣莃菣ꆂ볯钼볯薆臣베듧閁苣ꚁ臣讂胥ꮁ鿥ꖁ臣ꚁ胣낖臣蒁苣ꦃ菣ꒀ苣袨껧馁苣芀郥ꮂ菣벃裦蚈胥袼뗨膀럧膀鷩膀迥뎁苣ꮃ菣ꆂ볯躯臣隫郧钼껧꾁胣銺臣ꮁ诧讫髧ꞁ臣讂胣ꢡ볯醼臣膀룤龮雦꺁뷥讅臣誁臣ꚁ뷤ꢔ迥붃臣隫郧钼껧銂ꓧ馁胣袼ꇨ銼볯薆臣뮷귥鲀뷯鶀迥뎁胢蒽胢꾁胣鲀뫦鶀迥뎁胢財藥鶀臣ꖕꫨꞁ臣讂胣覼戼㹲 隫郧钼껧꾁胣节臣랷郥貁该鲽룤붃臣芁苣낁胣뎍臣节臣랷郥꾏菨貁胣북胣ꞁ臣貂臣膀该鲽迥붃臣ꪁ苣芀럦袐臣꾁闧ꪁ苣膀ꯨ蚐볦鞮臣ꮂ菣벃苣뎃菣莃苣릂菣벃菣誏臣늼볯ꊼ볯ꊃ菣覃臣벑蟥閁苣膀苣鞁ꯨ蚐볦鞮臣開뷤꾏菨ꞁ臣貂臣螃苣뚂菣뎃苣꾁臩ꢔ臣貂臣蒁胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯隼볯醀⼼䥄㹖†菣ꖅ諥誏臣몇諥㲛牢ਾ†菣꾂苣ꮃ���鮊菣讃菣袃볯颼볯꾁胣邃菣꾂苣뎃菣颼볯ꎼ臣袂臣ꚁ蟥鮊臣讂臣膂臣膀迥뎁菣꾂苣ꮃ菣궃菣꾂볯钼볯ꮁ苣ꎁ臣辏蛥馁苣龁苣ꮁ苣ꒂ菣銂뫦馂臣讂胣몇諥꺁臣膂臣뾂苣ꮃ苣隺若馁苣鮚臣膀菣꾂苣ꮃ蟥鮊菣讃菣袃볯颼볯꾁胣ꮂ菣벃胣놷臣膀迥뎁苣蚃菣랂菣ꒀ臣ꒁ臣ꚁ苣뎃菣ꮃ臣覂菣꾂苣ꮃ臣꺁裥ꎧ苣芁ꇨ鞁胣뺁臣薿ꛨꮁ뿥颁臣钃苣뮂菣閃苣벃菣莃菣覤迦銂臩財臣讂胣辏蛥꺁臣膂臣뾂苣ꮃ苣隺若馁苣誸臣膀菣꾂苣ꮃ蟥鮊菣讃菣袃볯颼볯꾁菣莃苣ꢂ菣覃菣궃菣꾂볯钼볯讁苣钃苣뮂菣ꮂ菣벃胣놷臣膀迥뎁苣蚃菣랂菣ꒀ苣ꖅ触鞁胣뾂苣ꮃ룤ꮁ苣ꪂ菣袃菣辏蛥銂雩讧臣讂觥ꮁ胣ꖅ諥钃苣뮂菣閃苣벃菣莃菣袼菣꾂苣ꮃ菣ꦂ菣麃菣袃諧讅菣ꦃ菣벃苣ꮁ苣ꎁ臣螌껥閁苣龁볯讁苣몇諥钃苣뮂菣閃苣벃菣莃菣袼룤龮雦꺁뷥讅臣꾁胣늼볯ꊼ볯颼볯颼볯覼臣꺁菣ꦂ菣麃菣袃ꓥ鮏苣財臣芀戼㹲 钃苣뮂菣몇諥ꚃ菣莃菣銼볯邼臣膀苣ꪃ苣节臩財臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯隼볯醀⼼䥄㹖†鯥ꪼ볯꾁胣钃苣뮂菣몇諥ꚃ菣莃菣銼볯邼臣隃菣莃苣뎛臣芁苣芀菣꾂苣ꮃ蟥鮊菣讃菣袃볯颼볯꾁胣릂菣뎃苣ꮃ蟥鮊胣놷臣몇諥膀迥뎁苣ꦃ菣몇諥ꚃ菣莃菣銼볯銼胣銼볯钼胣誏臣銼볯隼苣ꮐ臣膀臣貂苣꺁菣讃菣袃臣膀臣貂臣貂胣떂菣鞃菣릂菣뎃苣ꮃ胣놷臣膀迥뎁苣ꦃ菣邃菣閃苣銼볯醼胣銼볯銼胣誏臣銼볯邼臣覂藥鮊苣鞏臣ꚁ臣讂胣릂菣뎃苣ꮃ蟥鮊菣讃菣袃볯颼볯誏臣誏臣놷臣몇諥ꚃ菣莃菣銼볯钼臣놅臣膀菣꾂苣ꮃ꿦꺁苣ꒂ菣邃菣閃苣銼볯邼臣몇諥馁苣芀苣ꦃ菣ꚃ菣莃菣銼볯隼臣閃苣벃菣莃菣覤迦ꢙ볯颼볯뢁蟥鮊臣膀菣ꦂ菣麃菣袃ꓥ鮏駥銼볯鞼臣邃菣閃苣銼볯邼臣몇諥馁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯馼胣㲑䐯噉‾钃苣뮂菣몇諥ꚃ菣莃菣銼볯邼臣膀苣蚃菣랂菣꾂菣ꊂ胣놷臣꾂菣ꊂ胣誏臣ꮂ菣벃苣ꪃ苣ꚃ菣莃菣銼볯醼胣銼볯鎼胣誏臣銼볯閼苣节郥뾁胣鎁苣覂臣ꢅ臣뾂苣ꮃ菣莃菣ꆂ볯ꮼ볯讁苣ꖅ諥銂迥醁臣蒁苣芀苣ꪃ苣ꚃ菣莃菣꾁胣颍룤꾂菣莃苣閃菣莃苣ꖃ苣ꪃ苣銂껥뺏臣讂胣꾂菣ꊂ菣讃菣袃臣ꖅ諥ꚃ菣莃菣ꢁ臣鎖볯设臣낁胣릂菣뎃苣ꮃ苣ꪃ苣銼볯醼臣릂菣뎃苣ꮃ藥鮊菣讃菣袃볯颼볯ꢁ臣鎖볯꺁胩ꆿ臣膀菣뎃菣랂苣벃苣銂믤鞁臣財苣貂苣芀苣ꦃ菣꾂菣ꊂ菣讃菣袃볯颼볯꾁胣閃苣벃菣莃菣覤迦ꚃ菣莃菣銼볯ꆼ臣ꆿ迥馁苣芀菣ꦂ菣麃菣袃ꓥ鮏菣讃菣袃볯颼볯꾁胣ꮂ菣벃藥鮊菣讃菣袃볯颼볯뢁蟥鮊臣讂胣릂菣뎃���ꮃ藥鮊胣놷臣ꖅ諥膀迥뎁苣ꦃ菣ꖅ諥ꚃ菣莃菣銼볯颼胣銼볯馼胣誏臣銼볯ꊼ臣膀臣貂臣貂胣떂菣鞃菣릂菣뎃苣ꮃ胣놷臣膀迥뎁苣ꦃ菣邃菣閃苣銼볯醼胣銼볯銼胣誏臣銼볯邼臣몇諥馁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯邼胣㲑䐯噉‾릂菣뎃苣ꮃ蟥鮊胣놷臣몇諥膀迥뎁苣ꦃ菣몇諥隃菣莃苣銼볯銼胣銼볯钼胣誏臣銼볯隼臣鶁苣麁苣膀믤许臣겪飦馁苣袂臣ꮁ胣떂菣鞃菣ꒀ臣覂菣꾂苣ꮃ苣蚃菣랂菣膀럦閁胣誏臣ꮂ菣벃胥뢁ꓥ鮏臣讂胣릂菣뎃苣ꮃ藥鮊胣놷臣ꖅ諥膀迥뎁苣ꦃ菣ꖅ諥隃菣莃苣銼볯颼胣銼볯馼胣誏臣銼볯ꊼ臣膀菣꾂苣ꮃ臣覂苣뎃菣ꮃ胥뢁ꓥ鮏臣讂胣閃苣벃菣莃菣覤迦ꢙ볯颼볯誏臣銼볯ꆼ臣膀蟥鮊菣꾂苣ꮃ菣ꦂ菣麃菣袃볯肸껥붖臣ꊽ藦ꞁ臣膀볯Ꞽ볯ꆼ볯颼볯颼볯ꢁ藥鮊菣꾂苣ꮃ菣ꦂ菣麃菣袃볯肸껥붖臣ꊽ藦ꞁ臣膀菣꾂苣ꮃ菣ꦂ菣麃菣袃諧讅菣ꦃ菣벃苣ꮁ苣ꎁ臣螌껥閁苣龁볯ꢁ臣鎖苣覤迦馁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯醼胣㲑䐯噉‾뮃藥鮊戼㹲 醼뗧꺁菣꾂苣ꮃ꿦꺁苣ꒂ菣릂苣蚃菣뢂菣낂菣莃菣ꆂ볯ꮼ볯膽胣銼볯邼뷯膀볯ꮼ볯莽胣Ꚁ胣袼룤겈髧誏臣讀胣ꮁ臣銼볯邼뇎胣뺁臣膀鯩袐髧ꮁ臣銼볯邼臣蒁臣覼臣膀菣꾂苣ꮃ蟥鮊菣궃菣꾂볯颼볯ꢁ菣莃苣ꢂ菣覃菣궃菣꾂볯钼볯ꢁ臣鎖臣颭鳥鞁臣蒁苣芀臣貂苣꺁郥邃菣閃苣銼볯邼臣膀볯ꒁ臣ꊖ胩뚊藦鎃菣袃볯목胣邃菣꾂苣뎃菣貮뫤膀迥뎁菣꾂苣ꮃ껥蚺볯銂鳦鞁胣鎁苣覂臣鎃菣袃臣鎁苣覂臣邃菣閃苣銼볯邼苣뾽铧馁苣龁苣ꮁ胣钃苣뮂菣몇諥隃菣莃苣ꢁ菣莃苣ꢂ菣覃菣궃菣꾂볯钼볯ꢁ臣鎖臣较菣覃苣Ꞃ菣꾂苣뾪闦袼臣龁臣랂菣ꖃ菣벃菣覼臣讂胣邃菣꾂苣뎃菣誏臣钃苣뮂菣몇諥ꚃ菣莃菣颼볯ꎼ胣銼볯邼臣膀臣貂臣貂臣ꚃ菣莃菣貁臣貂苣讁苣궪蟥鞁胣鶁苣麁苣꺁菣讃菣袃臣鶁苣覂臣뢛뻨肂苣蚃菣뢂菣낂菣莃菣ꆂ볯ꮼ볯캐銂賦몤臣讂迧ꖅ諥誏臣몇諥邃菣閃苣鶃苣뎃苣銂뛧膌臣ꚁ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鞼볯醀⼼䥄㹖†菣꾂苣ꮃ菣궃菣꾂볯钼볯誏臣钃苣뮂菣몇諥ꚃ菣莃菣銼볯邼臣膀菣뎃菣랂苣벃苣鞃菣袃苣ꮃ苣뾽铧鞁臣뾂苣ꮃ蟥鮊苣讖꟥鞁胣貮뫤閁臣讂胣뾂苣ꮃ臣꺁迦馆臣貮뫤馁苣ꢁ胣钃苣뮂菣隃菣莃苣颼볯ꊼ臣膀苣ꒂ菣銂蟥鮊臣讂苣蚁臣钃苣뮂菣몇諥ꚃ菣莃菣銼볯邼臣ꆿ迥馁苣芀菣꾂苣ꮃ蟥鮊菣讃菣袃볯颼볯꾁胣ꮂ菣벃胣銼迥뎁苣蚃菣랂菣ꒀ苣钃苣뮂菣邃菣閃苣銼볯邼臣膀苣膀菣莃苣ꢂ菣覃볯钼볯ꮁ苣ꎁ臣閃菣벃菣邃菣閃苣颼볯���臣ꊻ胩閁臣讂胣閃菣벃菣邃菣閃苣颼볯Ꞽ臣蒐菣꾂苣ꮃ꿦꺁苣ꦃ菣ꒀ迥뎁뷯ꒀ苣베듧鞁胣肸雦钃苣뮂菣隃菣莃苣颼볯ꊼ臣蒐苣뎃菣ꮃ꿦꺁胥銂뛧膌臣讂胣袼菣것菣ꂃ菣莃菣ꆂ볯钼볯誏臣钃苣뮂菣隃菣莃苣颼볯ꊼ臣ꆸ胨꺁臣膂臣릂菣뎃苣ꮃ胥꾁郥肸臣베듧閁苣讂胣覼菣꾂苣ꮃ蟥鮊菣讃菣袃볯颼볯꾁胣ꦁ臣ꒀ苣閃菣벃菣邃菣閃苣颼볯Ꞽ蛥ꮁꃦ趴臣讂臣讁苣뢁諦馁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯鎼胣㲑䐯噉‾钃苣뮂菣隃菣莃苣颼볯ꊼ臣袂臣ꚁ迦馆臣讂臣膂臣뾂苣ꮃ苣隺若馁苣誸臣膀菣莃苣ꢂ菣覃菣궃菣꾂볯钼볯꾁胣릂菣莃菣醼볯邼볯ꮁ臣蒁臣ꆬ臣목菣莃菣ꆂ볯ꮼ볯캐銂迥誂볯鶁臣목菣莃菣銂苣ꪃ苣鞁볯膀苣蚃菣鞃볯醼볯邼臣誁臣ꚁ胣鶁臣邃菣꾂苣뎃菣ꮂ菣벃苣ꪃ苣膀菣莃苣ꢂ菣覃럦閁苣ꪃ苣膀迥뎁菣莃苣ꢂ菣覃苣蚃菣랂菣꾂菣ꊂ諧讅菣ꦃ菣벃苣袼苣ꒂ菣讖꟥醃苣莃菣ꮁ苣ꎁ臣뮂菣袃臣貂苣覼臣袂臣ꚁ뇦骮臣貂臣螃菣뾂苣膀뿥膦臣鲿臣ꚁ菣것菣ꂃ菣莃菣ꆂ菣ꊃ菣颼볯Ꞽ臣覂ꫨ벾苣芀菣莃苣ꢂ菣覃菣궃菣꾂볯钼볯貁苣ꒂ菣꺁ꫨ벾臣銂뗧蚺臣龁뻥ꮁ胣隃菣莃苣颼볯ꎼ臣膀苣蚃菣鞃볯醼볯閼臣誁臣ꚁ菣莃苣ꢂ菣覃껥蚺苣뮂菣袃臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鞼볯醀⼼䥄㹖†藥鮊菣ꎂ菣뾂볯銼볯꾁胣钃苣뮂菣몇諥ꚃ菣莃菣銼볯邼臣꺁룤ꎀ臣뎂菣뎃菣銂뷤ꢔ臣ꚁ胣뾂苣ꮃ뫦馂苣讖꟥馁苣芀臣꺁苣麃菣覃苣벃苣뎃苣꾁胣뢅黥蒚臣꾁胣뾂苣ꮃ雩讧胣뾂苣ꮃ雩讧胣뾂苣ꮃ雩讧胣Ꚁ臣芁苣芀郥뾂苣ꮃ雩讧臣膀곦꺁菣莃苣ꢂ菣覃껥蚺菣꾂苣ꮃ菣莃菣ꆂ苣讦蟥馁苣蚁臣钃苣뮂菣몇諥ꚃ菣莃菣銼볯邼臣ꆿ迥馁苣芀苣蚃菣鞃볯銼볯閼臣誁臣ꚁ胣钃苣뮂菣몇諥ꚃ菣莃菣銼볯邼臣ꖅ諥뾂苣ꮃ菣莃菣ꆂ볯ꮼ볯캐꺁菣莃苣ꢂ菣覃껥蚺菣莃菣銂ꫨ릁苣芀苣鞁苣蚃菣鞃볯銼볯邼臣誁臣ꚁ菣莃苣ꢂ菣覃껥蚺菣莃菣貁苣莃菣閁苣ꚁ臣ꪁ臣貂臣膀苣蚃菣鞃볯銼볯邼臣誁臣ꚁ菣꾂苣ꮃ蟥鮊菣讃菣袃볯颼볯꾁ꧦ붃臥ꊭ臣讂胣鶁臣ꞁ臣醁苣낁胣릂菣莃菣醼볯醼볯ꮁ臣蒁臣膀臣貂臣邃菣꾂苣뎃菣貮뫤鎃菣袃苣꾂菣ꊂ臣膀菣꾂苣ꮃ苣ꒂ菣邃菣閃苣銼볯邼뇎蛥꺁苣ꦃ菣膀럦閁胣誏臣込臣龁臣릂菣뎃苣ꮃ菣莃菣ꊝ苣袼뿥膦臣鲿臣ꚁ볯꾂菣ꊂ臣膀菣꾂苣ꮃ苣ꒂ菣邃菣閃苣銼볯邼뇎苣떂菣鞃菣邃菣閃苣銼볯醼胣銼볯銼胣誏臣銼볯邼臣ꦁ裥ꮁ믨膀臣讂胣貮뫤馁苣ꢁ胣钃苣뮂菣隃菣莃苣銼볯邼臣膀迦馆臣隺若貁闦ꎁ臣节臣ꢁ臣ꚁ���뎃菣ꮃ苣ꒂ菣邃菣閃苣銂菣벃苣馁苣袼菣꾂苣ꮃ껥蚺菣莃菣銂苣莃菣馁苣覼胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鞼볯醀⼼䥄㹖†菣뾂苣ꮃ蟥鮊戼㹲 몇諥馁苣芙臣膀菣꾂苣ꮃ蟥鮊菣讃菣袃볯颼볯꾁胣辏蛥閁苣讂苣ꒂ菣薆臣떂菣鞃菣銂菣꾂苣ꮃ苣ꒂ菣邃菣閃苣銼볯邼蛥꺁菣꾂苣ꮃ臣蚈꟨馁苣芀菣꾂苣ꮃ蟥鮊菣讃菣袃볯颼볯꾁胣钃苣뮂菣邃菣閃苣銼볯邼苣蚠闧ꮁ꣦螈苣膀迦馆臣貂苣떂菣鞃菣뾂苣ꮃ苣鶁苣貁迧貂臣뒠触ꢁ郥颁菣꾂苣ꮃ菣莃菣ꆂ볯ꮼ볯캐뢁铦몇臣讂胣钃苣뮂菣뾂苣ꮃ菣莃菣ꆂ볯ꮼ볯캐뢁臣뾂苣ꮃ蟥鮊臣貮뫤馁苣ꢁ胣钃苣뮂菣몇諥ꚃ菣莃菣銼볯邼臣钃苣뮂菣貮뫤鎃菣袃苣뮂菣袃臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鞼볯醀⼼䥄㹖†苣蚃菣鞃볯醼볯閼臣誁臣ꚁ胣钃苣뮂菣貮뫤鎃菣袃臣뮂菣袃臣貂臣蒁苣鎁臣貁뇦骮臣貂苣ꢁ胣邃菣꾂苣뎃菣隃菣莃苣颼볯ꎼ臣膀臣꺁迧ꖅ諥鶃苣뎃苣銂雩ꎀ臣讂菣꾂苣ꮃ苣ꒂ菣邃菣閃苣銼볯邼뇎臣뮂菣袃臣膀菣꾂苣ꮃ껥蚺菣莃菣銂苣ꪃ苣鞁볯릂菣莃菣醼볯鎼볯覼胣뾂苣ꮃ菣莃菣ꆂ볯ꮼ볯캐銂菣것菣ꂃ菣莃菣ꆂ菣ꊃ菣颼볯Ꞽ臣ꊻ胩馁苣芀믨膀臣貮뫤馁苣ꢁ胣릂菣莃菣醼볯鎼볯ꮁ臣蒁臣膀菣莃苣ꢂ菣覃菣궃菣꾂볯钼볯꾁菣莃菣ꆂ볯ꮼ볯캐誸臣목菣莃菣銂苣莃菣馁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯鞼胣㲑䐯噉‾뮃럦閁蟥鮊戼㹲 钃苣뮂菣몇諥ꚃ菣莃菣銼볯邼臣膀苣鞁꿥鲿臣讂菣것菣ꂃ雩讧菣놂菣袃臣鶿껧袸臣놷臣邃菣閃苣ꆄ諧讅菣ꦃ菣벃苣銂苣ꪃ苣鞁臣蒁苣낁胣놷臣ꒀ苣钃苣뮂菣邃菣閃苣銼볯邼뇎臣膀苣芀럦閁蟥鮊臩麊諧讅菣ꦃ菣벃苣꾁胣떂菣鞃菣꺁뷯ꒀ臣뢁諦銂뇦骮臣讂胣ꖻ룤꺁鏦벼苣벃菣꾁胣놷臣몇諥뢁諦뚊藦醃菣ꆃ菣뾂臣릊黦銂ꓧ鞁臣蒁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯颼胣㲑䐯噉ਾ䐼噉邀闦醼볯醼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㄰㐸⼼㹡⼼䥄㹖 뮃苣ꦃ菣몇諥㲛牢ਾ†菣꾂苣ꮃ菣궃菣꾂볯钼볯꾁胣节臣뺯뿥馁苣閃菣벃菣讖꟥醃苣莃菣貁뿤ꆮ룦뾁苣ꦃ菣邃菣閃苣ꆄ諧讅菣ꦃ菣벃苣銂苣ꪃ苣鞁臣蒁苣낁胣ꮂ菣벃胥銂菣꾂苣ꮃ菣莃菣ꆂ볯ꮼ볯캐뢁胩讂胣ꮂ菣벃胥몇諥꾁菣것菣ꂃ苣벃菣벃菣궃菣膀苣ꦃ菣몇諥뢁諦膀迥뎁苣ꦃ菣몇諥ꪂ菣邃菣閃菣벃臩麊諧讅菣ꦃ菣벃苣꺁苣莃菣ꎂ菣낂臣鶾귥馁苣芀믤许臣겓볤뎂菣覃臣膀蟥鮊臣꺁苣ꦃ菣꺁蟥蚐臣龁苣꺁菣뢂菣꾂苣芦뿨鞁臣蒁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯馼胣㲑䐯噉ਾ䐼噉邀闦醼볯銼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩���〰㄰㔸⼼㹡⼼䥄㹖 鎁臣袨껧閁苣龁苣ꦃ菣꾁胣钃苣뮂菣ꮁ觥鎽臣覂苣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯颼볯醀⼼䥄㹖†菣벃菣ꎂ苣뎃菣ꮃ臣袂臣ꪁ诨늹臣ꪂ菣랂菣뎃臣뒠郥膀苣ꦃ菣꾁菣릂雩ꞁ럦袐臣貂臣蒁臣ꢁ臣芁苣芀臣貂臣ꖋ맥꺁苣ꒂ菣ꊂ苣뎃苣ꊂ菣膃菣ꆂ苣袃苣节臣覂臣鞾苣貁胣骤꟨ꊽ臣龁臣蚈ꇩꆃ菣ꪃ臣ꪂ菣邃菣閃菣벃臣뒠郥ꮁ駧龔臣讂ꋥ銂軦馁苣骤꟨ꊽ苣莃苣ꮁ臣醁苣貃駦ꮂ菣벃臣ꮁ臣뾁蟥鞁臣肜苦ꊂ菣膃菣ꆂ苣袃苣늘臣芀뷤貂臣뒠郥节胣ꊂ菣ꪃ苣벃苣ꞃ菣颼볯醼볯꾁胣몇諥趉臣ꮂ菣벃苣뎃菣ꮃ臣蒵郥鮁臣龮돨蒚臣뚈뻥銂鳦鞁臣蒁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯醼胣㲑䐯噉‾ꂊ蟩뎹鷥꺁꣨鞮臣뾽铧閁苣讂苣뎃菣ꮃ蟩뾁臣膀菣궃苣ꦃ菣꾏菨ꞁ臣讂胣肸껥붖臣ꊽ藦ꞁ臣膀臣貂苣꾁볯鎃菣袃臣辇臣芁苣芀臣貂苣꺁볯鎃菣袃臣辇臣膀볯躼볯꺁闦袼跥ꆁ胣몛껥辰闦릂菣ꦂ菣麃菣袃臣꾁胣醼臣꺁闦낕菣莃菣ꢁ胣鶁苣ꮁ뛧辁볯ꒁ臣辰闦릂믤许臣鎃菣袃볯ꢁ臣ꚁꇨ閁苣讂胣鎁苣ꮁ苣誂胣蒐蟩뾁臣薆꣨銂볯躼볯讁苣銼볯邼苣誂菥讁臣醰臣蒁胥뺁臣꺁꿧늛臣馁苣鎁臣貁臣趁苣芀菣꾂苣ꮃ蛥꺁볯ꒁ臣떂菣鞃菣꺁蟩뾁苣螝룤ꮁ臣讂臣膂臣膀郥떂菣鞃菣躯臣螌껥閁苣龁蟩뾁苣鎼볯ꮁ臣릁臣ꞁ臣讂胣鎾臣ꚁ胣떂菣鞃菣꺁蟩뾁臣袨볯銼볯뺁臣ꮁ臣讂臣膀臣貂臣膀臣꺁껥붖臣ꊽ藦ꮁ뷤ꢔ臣貂苣몛껥辰闦릂菣ꦂ菣麃菣袃臣誁臣讂볯躼볯ꮁ귧鞁臣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯銼胣㲑䐯噉‾뮃苣蚃菣랂菣몇諥㲛牢ਾ†菣꾂苣ꮃ蟥鮊菣讃菣袃볯颼볯꾁胣节臣뺯뿥馁苣閃菣벃菣讖꟥醃苣莃菣薆臣鶿껧袸臣릂菣뎃苣ꮃ菣莃菣ꆂ蓧뚊藦醃菣ꆃ菣뾂苣뮂菣袃臣ꚁ臣ꪁ臣貂臣膀苣蚃菣랂菣ꒀ苣钃苣뮂菣邃菣閃苣銼볯邼臣膀苣芀苣蚃菣랂菣ꒀ臣膀볯ꒁ臣閃菣벃菣讁苣ꆬ臣閃菣벃菣뢁룦馁뿥膦臣芁苣鞾胣閃菣벃菣꾂菣ꊂ菣뎃苣趓뷤ꮁ뷤ꢔ臣貂苣芀臣꺁臣膂胣릂菣뎃苣ꮃ臣龁苣꺁苣뎃菣ꮃ菣馃菣뺲뫥銂뛧膌臣讂臣ꢁ臣薿ꛨꮁ臣誂뻥讂胣袼苣鞃菣놂菣랂菣뎃볯銼볯醼臣膀郥릂菣뎃苣ꮃ胥躯臣膀菣꾂苣ꮃ꿦꺁볯鎃菣袃胣뺁臣꾁苣뎃菣ꮃ꿦꺁볯鎃菣袃臣閽苣讁苣뾽铧馁苣袂臣ꮁ臩麊臣讂臣ꢁ臣ꞁ臣讂胣覼菣것菣ꂃ雩讧蛥꺁苣蚃菣랂菣ꊃ菣覃菣莃菣꾁胣릂菣뎃苣ꮃ臣钃苣뮂菣躯臣芁苣꺁臣膀臣龁臣떂菣鞃菣躯臣芁苣꺁臣銂뇦骮臣讂胣閽苣꺁ꃥ袐苣膀菣꾂苣ꮃ뷥龁苣꺁苣蚃菣랂菣薃ꃥ꺁苣뎃菣ꮃ菣馃菣뺲뫥鎃菣袃볯肸껥붖臣ꊽ藦���ꞁ臣膀볯覼臣膀蟥閁苣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯颼볯醀⼼䥄㹖†菣钃苣뮂菣閃苣벃菣莃菣覤迦㲛牢ਾ†菣꾂苣ꮃ菣ꦂ菣麃菣袃ꓥ鮏臣膀迦馆臣龁苣꺁苣ꒂ菣몇諥誏臣뾂苣ꮃ뫦馂臣ꆸ雦ꮁ臣蒁臣財苣貂苣芀菣꾂苣ꮃ苣ꦃ菣誏臣ꊂ菣閃苣邈裥銂臩螈臣辇臣醁럥뺁臣꾁迥랂菣袃臣鮁苣鎁臣ꮁ苣誂胣醃苣鞃菣ꒂ菣閃苣벃菣莃菣늼볯ꊼ볯颼볯颼볯貁胣뾂菣늂菣袃菣ꦂ菣麃菣袃볯鎁臣ꞁ臣膀볯늼볯ꊼ볯颼볯颼胣늼볯ꊼ볯隼볯膀迥뎁볯꺼볯ꖼ볯颼臣醼臣覼臣覤迦閁苣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯颼볯醀⼼䥄㹖㰊䥄㹖胣ꢡ볯隼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㄰㘸⼼㹡⼼䥄㹖㰊䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㠱㰷愯㰾䐯噉ਾ⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯閼胣㲑䐯噉ਾ䐼噉邀ꇨ鎼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㠱㰸愯㰾䐯噉ਾ䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㄰㤸⼼㹡⼼䥄㹖㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯颼볯醀⼼䥄㹖㰊䥄㹖胣ꢡ볯颼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㄰〹⼼㹡⼼䥄㹖㰊䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㤱㰱愯㰾䐯噉ਾ⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯鞼胣㲑䐯噉ਾ䐼噉邀ꇨ鎼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㤱㰲愯㰾䐯噉ਾ䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㄰㌹⼼㹡⼼䥄㹖㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯颼볯醀⼼䥄㹖㰊䥄㹖胣ꢡ볯邼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㄰㐹⼼㹡⼼䥄㹖㰊䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㤱㰵愯㰾䐯噉ਾ⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯馼胣㲑䐯噉ਾ䐼噉邀ꇨ钼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㤱㰶愯㰾䐯噉ਾ䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㄰㜹⼼㹡⼼䥄㹖㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯馼볯醀⼼䥄㹖㰊䥄㹖胣ꢡ볯銼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㄰㠹⼼㹡⼼䥄㹖㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯馼볯醀⼼䥄㹖㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯馼볯醀⼼䥄㹖㰊䥄㹖胣ꢡ볯鎼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㄰㤹⼼㹡⼼䥄㹖㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯馼볯醀⼼䥄㹖㰊䥄㹖胣ꢡ볯钼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰〰⼼㹡⼼䥄㹖㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯馼볯醀⼼䥄㹖㰊䥄㹖胣ꢡ볯閼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㄰⼼㹡⼼䥄㹖㰊䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰〲㰲愯㰾䐯噉ਾ⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯閼胣㲑䐯噉ਾ䐼噉邀ꇨ钼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰〲㰳愯㰾䐯噉ਾ⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯隼胣㲑䐯噉ਾ䐼噉邀ꇨ钼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰〲㰴愯㰾䐯噉ਾ䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㔰⼼㹡⼼䥄㹖㰊䐯���ਾ䐼噉㰾䥄㹖胣醼볯馼볯醀⼼䥄㹖㰊䥄㹖胣ꢡ볯颼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㘰⼼㹡⼼䥄㹖㰊䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰〲㰷愯㰾䐯噉ਾ⼼䥄㹖㰊䥄㹖䐼噉邀볯钼볯颼胣㲑䐯噉ਾ䐼噉邀ꇨ钼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰〲㰸愯㰾䐯噉ਾ䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㤰⼼㹡⼼䥄㹖㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯馼볯醀⼼䥄㹖㰊䥄㹖胣ꢡ볯邼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰〱⼼㹡⼼䥄㹖㰊䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰ㄲ㰱愯㰾䐯噉ਾ⼼䥄㹖㰊䥄㹖䐼噉邀볯閼볯邼胣㲑䐯噉ਾ䐼噉邀ꇨ閼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰ㄲ㰲愯㰾䐯噉ਾ䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㌱⼼㹡⼼䥄㹖㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯邼볯醀⼼䥄㹖㰊䥄㹖胣ꢡ볯銼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㐱⼼㹡⼼䥄㹖㰊䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰ㄲ㰵愯㰾䐯噉ਾ⼼䥄㹖㰊䥄㹖䐼噉邀볯閼볯銼胣㲑䐯噉ਾ䐼噉邀ꇨ閼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰ㄲ㰶愯㰾䐯噉ਾ⼼䥄㹖㰊䥄㹖䐼噉邀볯閼볯鎼胣㲑䐯噉ਾ䐼噉邀ꇨ閼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰ㄲ㰷愯㰾䐯噉ਾ⼼䥄㹖㰊䥄㹖䐼噉邀볯閼볯钼胣㲑䐯噉ਾ䐼噉邀ꇨ閼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰ㄲ㰸愯㰾䐯噉ਾ⼼䥄㹖㰊䥄㹖䐼噉邀볯閼볯閼胣㲑䐯噉ਾ䐼噉邀ꇨ閼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰ㄲ㰹愯㰾䐯噉ਾ䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰〲⼼㹡⼼䥄㹖㰊䐯噉ਾ䐼噉㰾䥄㹖胣醼볯邼볯醀⼼䥄㹖㰊䥄㹖胣ꢡ볯鞼胣㲑䐯噉ਾ䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰ㄲ⼼㹡⼼䥄㹖㰊䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㈲㰲愯㰾䐯噉ਾ⼼䥄㹖㰊䥄㹖䐼噉邀볯閼볯鞼胣㲑䐯噉ਾ䐼噉邀ꇨ閼볯醀⼼䥄㹖㰊䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㈲㰳愯㰾䐯噉ਾ⼼䥄㹖㰊䥄㹖䐼噉邀볯閼볯颼胣㲑䐯噉‾†뮃觧骮臣龮雦꺁뷥讅臣较苣ꦃ苣袃戼㹲 ꆬ臣膀鳦몙飦꺁菣閃苣벃菣랂苣벃菣ꎂ菣낂苣ꦃ菣ꎂ菣꾂苣鞃菣뮂菣떂볯꒼볯Ꞽ볯覼臣릉껥꺁껥붖臣ꊽ藦銂ꫨ躘臣讂胣醼臣꺁鷩袼臩ꖈ볯ꞁ臣膀鳦몙飦꺁볯뎼볯낼臣膀뿤颭胦ꂚ苣ꢡ鷩꒙軥銂臩財臣讂꟦ꂀ迥뎁雦閳苣邏뻤馁苣芀駩骮臣讂苣꺁臣꾁臣蒁臣膀믤许臣节臣銂郥肂ꓥ辁臣龮雦꺁뷥讅苣겪飦馁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯閼볯馼胣㲑䐯噉‾袼볯覼苣뎃菣ꖃ菣뾂苣ꦃ菣ꎂ菣꾂苣醃苣鞃菣ꒂ菣ꮁ臣蒁臣ꂚ苣ꢡ鷩꒙軥銂臩財臣讂雦閳胣겜雦閳臣膀郥薀臣螤闦꺁苣뾂菣鞃臣覂臣讂菣ꪃ菣蚃苣隃臣낂菣벃菣讁苣膀迧鞃菣龃菣ꎂ菣銂臩麊臣讂苣蚃菣鞃臣膀迧鞃菣龃菣ꎂ菣薆臣���苣뎃菣銂胣鞃菣龃菣ꎂ菣꺁苣ꮃ菣鞃蛥꺁藥ꮁꧨꆾ룦뾁臣鞃菣龃菣ꎂ菣讁苣꺁苣뾂菣鞃臣钯볨馁苣릂菣莃菣ꢁ胣견볯꺁苣뾂菣鞃蛥꺁苣뎃菣ꮃ臣놷臣뚊藦ꢁ胣袅臣閩뻤袸臣꺁苣뾂菣鞃臣떂菣鞃菣꺁럦閁諧讅臣꺁雩芿臣몟臣蒁臣膀곧醼臣릂苣뎃菣銂迧ꢜ臣鲽鳥蒚臣꾏ꛨ꺁苣뾂菣鞃볯ꎼ볯뚼볯覼臣鞁臣뢁諦馁苣릂菣莃菣ꢁ胣ꎼ볯뚼볯ꢁ곧銼臣릂苣뎃菣ꢁ苣钯볨馁苣릂菣莃菣ꢁ胣閩뻤鞁臣릂苣뎃菣ꮁ鿥ꖁ臣ꚁ곧銼臣릂苣뎃菣꺁룤ꢃ臣肜뗧낂菣閃苣莃苣릂菣ꎂ苣鞃菣ꒂ臣놽鿩銂迥벁臣ꪁ臣뒠郥ꮁ臣膀곧銼臣릂苣뎃菣銂ꃧ蒣臣讂苣蚃菣鞃臣膀곧銼臣릂苣뎃菣貁볯낼볯뎼苣ꂚ臣뒠郥ꮁ臣膀볯낼볯뎼苣뒠ꏦ鞁臣견볯꺁苣뾂菣鞃苣ꎼ볯뚼볯ꮁ臣讂苣蚃菣鞃臣膀곧銼臣릂苣뎃菣誏臣ꎼ볯뚼볯꺁룤薀臣醰臣辁臣节菩蚈髧ꮁ鳦芵苣ꦃ菣ꎂ菣꾂苣螃苣릂菣것苣ꒂ菣벃苣薆臣讦臣讂ꃥ袐臣꾁胣ꎼ볯뚼볯銂駧膀臣ꚁ곧銼臣릂苣뎃菣銂볯낼볯뎼臣馁苣릂菣莃菣ꢁ胣견볯꺁苣뾂菣鞃迥뎁볯낼볯뎼臣讦臣릖臣뎂菣钃菣벃苣낂菣閃苣莃苣릂菣ꒂ菣ꦃ苣뎃蛥꺁뻥릖臣閩뻤閁苣讂菣ꦃ菣벃苣ꮁ鿥ꖁ臣뒠郥ꮁ臣膀곧銼臣릂苣뎃菣誏臣ꎼ볯뚼볯銂駧膀臣讂苣蚃菣鞃臣銂郥鎂臣蒁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯閼볯邼胣㲑䐯噉‾袼볯覼볯낼볯뎼臣견볯꺁苣뾂菣鞃臣銂꿦莼臣讂苣蚃菣鞃臣膀볯낼볯뎼蛥꺁苣뎃菣ꮃ臣놷臣뚊藦ꢁ곧銼臣릂苣뎃菣薆臣떂菣鞃菣꺁럦閁諧讅臣銂꿦莼臣讂苣蚃菣鞃臣膀菣ꒂ菣ꦃ苣뎃諧讅胥銂ꧨꆾ臣讂苣蚃菣鞃臣銂鯦ꮁ郥肂볯醼볯ꮁ꣨覼臣릖돦芀볯鎼볯놷臣뚊藦꾁볯ꒁ臣骽胥込苣뎃菣ꮃ臣覂臣誂胣骽胥꾁胣骽胥貁迧ꢜꛨ袁臣蒁苣ꢡ鷩꺁껥鮚臣骽胥銂ꇨ馁ꃥ袐臣꾁귦몢臣芁苣ꢁ껥ꦾ臣貂胣뺁臣骽胥貁鳦Ꞥ뷯ꒀ苣ꢡ臣뒠郥ꮁ臣鶿귥Ꞁ臣芁苣ꢁ껥ꦾ臣貂苣뚊藦鎃菣袃苣ꮐ苣袼볯覼臣風볨꺁雦閳胣袼볯覼곧銼臣릂苣뎃菣貁胣놷臣뚊藦ꮁ臣ꆄ雩芿臣膀鳦芵苣ꦃ菣ꎂ菣꾂苣螃苣릂菣것苣ꒂ菣벃苣銂뷦ꢜ髧ꮁꓥ뒛臣讂ꃥ袐臣꾁胣견볯꺁苣뾂菣鞃迥뎁볯낼볯뎼苣뒠ꏦ馁苣릂菣莃菣銂鯦ꮁ郥肂볯醼볯ꮁ꣨覼臣릖돦芀볯閼볯몙胩閁苣讂苣뾂菣鞃苣肝觨馁苣릂菣莃菣ꢁ胣肝觨릂菣莃菣꺁뻥ꮁ駧膀臣貂苣릂苣뎃菣ꮁ꿥鞁臣ꎭꋧꪁ뷯邃菣閃苣ꚩ꣩銂臩財臣讂苣蚃菣鞃苣뒛臣ꮐ苣袼볯覼臣風볨꺁雦閳胣袼볯覼ꓨ낕臣떂菣鞃菣꺁苣ꮃ菣ꆂ胥ꢁ胣芏藧ꊂ菣閃苣ꒀ臣銂꿦莼臣讂苣蚃菣鞃臣膀ꓨ낕臣떂菣鞃菣꺁���ꮃ菣ꆂ胥貁藥ꚁ迥ꞅ胥袂苣Ꞥ臣蒁ꃥ袐臣꾁胣ꊂ菣閃苣ꒀ臣꾁蓧ꊖ뿤ꮁ胣견볯꺁苣뾂菣鞃迥뎁볯낼볯뎼苣몙胩馁苣릂菣莃菣銂鯦ꮁ郥肂볯醼볯ꮁ꣨覼臣릖돦芀볯鞼볯뺏菣ꪃ菣蚃苣隃蛥꺁뷤貂臣꺁苣뎃菣ꮃ臣肜뗧낂菣閃苣莃苣릂菣ꎂ苣鞃菣ꒂ苣ꆃ菣뢂蛥꺁鳦芵菣꾂苣ꮃ苣ꦃ菣ꒀ臣놽鿩銂迥벁臣鞾苣讁郥讁苣몱껥馁苣릂菣莃菣ꢁ胣뺏菣ꪃ菣蚃苣隃蛥꺁臣꺁苣뎃菣ꮃ苣肜뗧낂菣閃苣莃苣릂菣ꎂ苣鞃菣ꒂ苣ꆃ菣뢂蛥꺁鳦芵菣꾂苣ꮃ苣ꦃ菣ꒀ臣놽鿩銂迥벁臣ꪁ臣뒠郥ꮁ臣膀迧鞃菣龃菣ꎂ菣꺁臣膂臣랷郥銂苣벃菣ꪂ菣閁臣讂苣蚃菣鞃臣銂鯦ꮁ郥肂볯醼볯ꮁ꣨覼臣릖돦芀볯颼볯뺏菣ꪃ菣蚃苣隃蛥꺁苣뾂菣鞃臣袅臣閩뻤袸臣꺁菣ꪃ菣蚃苣隃臣覂臣릂苣뎃菣ꢁ苣钯볨馁苣릂菣莃菣꾁胣뺏菣ꪃ菣蚃苣隃臣螤闦꺁苣뾂菣鞃뷤꺽臣肜ꓥ骽胥銂뇦骮臣讂苣蚃菣鞃臣膀ꓨ낕臣릂苣뎃菣趽뷧꺁鳦Ꞥ뷯ꒀ臣뺏菣ꪃ菣蚃苣隃臣肜냥骽胥ꢁ苣钯볨鞁胣뺯뿥馁苣릂苣뎃菣뢁諦鎃菣袃苣뮂菣袃臣讂苣蚃菣鞃臣膀臣讂苣뾂菣鞃ꇨ薆臣릂苣뎃菣趽뷧꺁鳦Ꞥ뷯ꒀ臣뺏菣ꪃ菣蚃苣隃臣肜냥骽胥袂苣节ꓥ趁臣뒠郥ꮁ臣膀臣꺁苣뾂菣鞃臣財苣鞃菣뮂苣財臣鞁臣颭裥馁苣릂菣莃菣ꢁ苣뒛臣ꮐ苣讫뇦薠볯ꮁ꣨覼臣릖돦芀볯馼볯뺏菣ꪃ菣蚃苣隃臣螤闦꺁苣뾂菣鞃뷤꺽臣肜ꓥ骽胥銂뇦骮臣讂苣蚃菣鞃臣膀迧鞃菣龃菣ꎂ菣꺁菣Ꚃ菣螃苣뎃苣鲃菣꾂苣薆臣蒐苣뾂菣鞃꿦ꮁ鳦Ꞥ뷯ꒀ苣몱껥馁苣릂菣莃菣銂鯦ꮁ郥肂볯颼볯ꮁ꣨覼臣릖돦芀볯醼볯覼迧鞃菣龃菣ꎂ菣薆臣릂苣뎃菣ꢁ藥ꮁꧨꆾ룦뾁臣鞃菣龃菣ꎂ菣讁苣꺁苣뾂菣鞃臣銂꿦莼臣讂苣蚃菣鞃臣膀迧鞃菣龃菣ꎂ菣貁軦ꚧ臣ꚁ臣讂郥鞃菣뮂苣財蛥꺁鳦节럥誏臣肜苣뎏臣릂苣뎃菣銂뇦骮臣膀꿥鲿臣讂苣뾂菣鞃菣ꪃ菣蚃苣隃苣邃菣莃苣鎃菣袃苣骮뻧馁苣릂菣莃菣ꢁ胣릂苣뎃菣鞃菣龃菣ꎂ菣ꮂ菣것菣뢂菣莃菣ꢁ苣뾂菣鞃臩麊菣莃菣ꢁ苣蒵郥鮁臣肜뗧꺁뷦ꢜ髧ꮁ迥隦臣릂苣뎃菣뮂菣袃苣龔裦馁苣릂菣莃菣ꢁ苣뒛臣ꮐ苣袼볯覼臣風볨꺁雦閳胣袼볯醼볯뺏菣ꪃ菣蚃苣隃蛥꺁苣뾂菣鞃臣袅臣閩뻤袸臣꺁菣ꪃ菣蚃苣隃臣覂臣릂苣뎃菣ꢁ苣钯볨馁苣릂菣莃菣꾁胣肜뗧꺁뷦ꢜ髧ꮁ迥隦臣릂苣뎃菣뮂菣袃蛥꺁臣讂苣뾂菣鞃蛥ꮁ볯蒵臣떂菣鞃菣릂苣몱껥馁苣릂菣莃菣ꢁ胣袨껧閁苣龁뷯ꒀ臣베듧閁苣ꚁ臣讂뷯ꒀ臣銂꿦莼臣膀苣뎃菣ꮃ裥ꆾ뿤랏苣몇諥馁苣릂菣莃菣銂鯦ꮁ郥肂볯醼볯覼���風볨꺁雦閳胣袼볯銼볯袨껧閁苣龁뷯ꒀ臣베듧閁苣ꚁ臣讂뷯ꒀ臣銂꿦莼臣讂苣蚃菣鞃臣膀苣鞁곧醼臣떂菣鞃菣꺁곧醼臣놷臣뚊藦貁곧醼臣떂菣鞃菣趽뷧ꮁ臣醁苣꾏ꛨ떂菣鞃菣꺁鳦Ꞥ럦閁諧讅臣芁苣낁胣견볯꺁苣뎃菣ꮃ뷤꺽臣誁臣讂곧醼臣떂菣鞃菣銂臩몼苣뎃菣ꮃ臣鞁臣베듧馁苣릂菣莃菣ꢁ胣견볯꺁苣뎃菣ꮃ臣견볯꺁苣뎃菣ꮃ臣銂꿦莼臣讂苣蚃菣鞃臣膀苣鞁곧銼臣떂菣鞃菣貁迧ꢜ뷦ꢜ髧ꮁ迥隦臣芁苣낁胣견볯꺁苣뎃菣ꮃ苣肜臩몼苣뎃菣ꮃ臣鞁臣베듧馁苣릂菣莃菣ꢁ胣ꂁ볯떂菣鞃菣貁곧銼臣떂菣鞃菣銂髩馁ꃥ袐臣꾁胣견볯꺁苣뎃菣ꮃ苣뒠ꏦ馁苣릂菣莃菣ꢁ苣뒛臣ꮐ苣袼볯邼볯ꮁ꣨覼臣릖돦芀볯醼볯覼臣讂苣뾂菣鞃蛥꺁볯ꒁ臣떂菣鞃菣銂菣ꒂ菣ꦃ苣뎃臣许雦뢁駧膀臣릁臣ꞁ臣讂臣ꢁ臣몱껥閁苣龁ꃥ袐臣꾁胣鶁臣릂苣뎃菣薆臣ꢅ臣꺁苣뎃菣ꮃ苣醃苣鞃菣ꒂ菣꺁룤릖臣몙胩馁苣袼볯邼볯ꮁ꣨覼臣릖돦芀볯醼볯覼臣讂菣꾂苣ꮃ蛥꺁볯ꒁ臣떂菣鞃菣銂菣ꒂ菣ꦃ苣뎃臣许雦뢁駧膀臣릁臣ꞁ臣讂臣ꢁ臣몱껥閁苣龁ꃥ袐臣꾁胣鶁臣钃苣뮂菣薆臣ꢅ臣꺁苣뎃菣ꮃ苣醃苣鞃菣ꒂ菣꺁룤릖臣몙胩馁苣袼볯邼볯ꮁ꣨覼臣릖돦芀볯醼볯覼볯蒵臣떂菣鞃菣릂蛥꺁ꓨ낕臣떂菣鞃菣릂臣骽胥銂苣袨껧馁苣릂菣莃菣꾁胣芁苣릂苣뎃菣꺁迥ꞅ뷯ꒀ苣鲽裦馁苣릂菣莃菣ꢁ胣醼뗧꺁苣뎃菣ꮃ苧薆臣螤闦꺁苣뎃菣ꮃ苧꺁臥躰雩낕苣袨껧馁苣릂菣莃菣ꢁ胣芏藧骽胥誏臣辁냥ꊖ闦銂菣ꒂ菣ꦃ苣뎃臣许雦뢁胩讂苣蚃菣鞃臣膀迥ꞅ뷯ꒀ迥뎁臥躰雩낕臣몟臣蒁臣떂菣鞃菣꺁뷯ꒀ苣袨껧馁苣릂菣莃菣ꢁ苣뒛臣ꮐ苣袼볯邼볯ꮁ꣨覼臣릖돦芀볯醼볯覼迥ꞅ뷯ꒀ迥뎁臥躰雩낕苣鞏臣讂苣蚃菣鞃臣膀迥ꞅ뷯ꒀ迥뎁臥躰雩낕臣몟臣蒁臣떂菣鞃菣꺁뷯ꒀ苣趆臣蒵郥鮁苣릂菣莃菣ꢁ苣뒛臣ꮐ苣袼볯邼볯ꮁ꣨覼臣릖돦芀볯醼볯覼볯낼볯뎼臣릂菣뎃苣ꮃ胥ꮁ뷥뾟苣誏臣馁ꃥ袐臣꾁胣ꎼ볯뚼볯銂駧膀臣讂苣蚃菣鞃苣ꮐ苣袼볯邼볯ꮁ꣨覼臣릖돦芀苣蚃菣랂菣ꚩ꣩貁ꓥ隌臣龁ꃥ袐臣膀藥ꚁ臣뺏鳥꾁뷦ꢜ髧ꮁ迥隦臣릂苣뎃菣銂駧膀臣讂苣蚃菣鞃苣뒛臣ꮐ苣袼볯鎼볯ꮁ꣨覼臣릖돦芀볯醼볯覼ꓨ낕臣鞃菣龃菣ꎂ菣讁苣꺁苣뎃菣ꮃ苣貐駦ꮁꃦ趴臣讂苣蚃菣鞃臣膀곧醼臣떂菣鞃菣趽뷧ꮁ臣醁苣떂菣鞃菣꺁꣨鞮臣貂臣骽胥ꢁ胣螤闦꺁菣ꪃ菣蚃苣隃臣覂臣견볯꺁苣뎃菣ꮃ뷤꺽臣誁臣讂苣뎃菣ꮃ臣베듧閁苣ꚁ臣讂뷯ꒀ臣銂꿦莼臣讂苣蚃���鞃臣銂鯦ꮁ郥肂볯醼볯覼臣風볨꺁雦閳胣袼볯邼볯蒐苣뾂菣鞃臣醰臣辁臣节볯ꒁ臣钃苣뮂菣讁苣ꪁ苣膀臣讂苣뾂菣鞃蛥꺁菣꾂苣ꮃ臣ꚸꇨꚇ郧閁苣讂볯醼볯覼臣風볨꺁雦閳胣袼볯醼볯螃苣릂菣것苣ꒂ菣벃苣颠鿥銂苣ꒂ菣ꮁ裥늉臣讂苣蚃菣鞃臣膀郥뾂苣ꮃ蛥꺁菣ꎂ苣鞃菣ꒂ苣ꆃ菣뢂苣겋ꯧ蒚臣辏蛥馁苣릂菣莃菣ꢁ苣뒛臣ꮐ苣袼볯邼볯ꮁ꣨覼臣릖돦芀볯銼볯覼苣뎃菣ꮃ苧꾁胣떂菣ꦃ苣뾂ꃦ邭럧꺁雩꺁뷤꺽臣趽뷧鞁臣蒁苣袼볯邼볯ꮁ꣨覼臣릖돦芀볯銼볯覼郥钃苣뮂菣薆臣떂菣鞃菣릂臣鞃菣낂菣ꂃ迥붃臣芁苣袼볯邼볯ꮁ꣨覼臣릖돦芀볯銼볯覼곧醼臣蒵臣떂菣鞃菣趽뷧銂ꓨ낕臣钃苣뮂菣薆臣鞃菣낂菣ꂃ臣讂苣蚃菣鞃臣膀곧醼臣蒵臣떂菣鞃菣趽뷧銂뷤ꢔ臣ꚁ苣뾂菣鞃臣讦臣릖苣閩뻤馁苣릂菣莃菣ꢁ胣견볯꺁뗧꺁苣뎃菣ꮃ뷤꺽苣螤闦꺁菣꾂苣ꮃ蛥ꮁ菣궃苣ꦃ菣馁苣릂菣莃菣ꢁ胣견볯꺁뗧꺁苣뎃菣ꮃ뷤꺽苣뾽铧鞁臣릂苣뎃菣꺁ꛨ袁雦銂ꧨꆾ臣讂苣蚃菣鞃臣銂鯦ꮁ郥肂볯銼볯覼臣風볨꺁雦閳胣袼볯閼볯肜뗧낂菣閃苣莃苣릂菣ꎂ苣鞃菣ꒂ苣ꆃ菣뢂臣놽鿩銂迥벁臣ꪁ臣鎁臣貁뇦骮臣貂臣讀胣꺁苣뾂菣鞃苣銎駩馁苣릂菣莃菣銂鯦ꮁ郥肂볯醼볯覼臣風볨꺁雦閳胣袼볯隼볯閃菣벃菣邃菣閃苣ꮂ菣벃胥貁迧鞃菣龃菣ꎂ菣薆臣떂菣鞃菣꺁鳦芵苣ꦃ菣ꮁ뷥뾟苣誏臣閁臣蒁苣蚁臣ꒀ苣뺏菣ꪃ菣蚃苣隃臣芠苧꺁苣ꮃ菣ꆂ胥貁鳦鞁臣蒁苣뒠郥ꮁ臣膀럦袐苣뾂菣뎃苣閃臣鮁苣릂菣莃菣銂鯦ꮁ郥肂볯醼볯覼臣風볨꺁雦閳胣袼볯鞼볯놷臣뚊藦꾁胣ꂁ뷯ꒀ迥뎁뿨骽胥讁苣ꪁ苣袼볯覼臣風볨꺁雦閳胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯醼볯醀⼼䥄㹖†볯銼볯覼菣閃苣벃菣랂苣벃菣ꎂ菣낂苣뎃菣ꖃ菣뾂苣ꦃ菣ꎂ菣꾂苣醃苣鞃菣ꒂ菣꺁臣膂臣ꂚ苣ꢡ鷩꒙軥랂苣蚃菣ꞁ臣ꎁ臣膀迧鞃菣龃菣ꎂ菣ꮁ雩ꎀ臣讂곧醼臣낂菣벃菣꺁뷦ꢜ髧ꮁ迥隦臣떂菣鞃菣銂귨ꖈ臣讂臣膂臣Ꞥ臣閁꿦莼胩뎃菣ꊃ菣뢁裥ꚃ菣莃菣ꢁ胣Ꞥ臣閁꿦莼胩뎃菣ꊃ菣뢁裥ꚃ菣莃菣ꮁ뗧袐臣貂胣견볯꺁苣ꮃ菣鞃迥뎁臣꺁菣ꪃ菣蚃苣隃臣ꢑ룧ꮁ鿥ꖁ臣ꚁ臣꺁菣ꪃ菣蚃苣隃臣ꊖ胩馁苣견볯꺁苣ꮃ菣鞃臣鲽鳥蒚臣꾏ꛨ꺁苣뎃菣ꮃ苣颭裥馁苣馁苣龁苣꺁苣뾂菣鞃臩麊菣讃菣袃臣膀苣뾂菣鞃臩麊菣讃菣袃迥뎁ꓥ趁臣钯볨ꎀ菦ꆃ菣ꪃ臩ꖈ菣讃菣袃臣邵郥閁苣膀菣ꒂ菣ꦃ苣뎃諧讅苣閩뻤鞁룤ꒁ곧銼臣낂菣벃菣꺁軦閁諧讅臣베듧閁苣ꚁ臣讂럦閁諧讅胥ꢁ苣钯볨馁苣鎁臣���ꮁ苣ꎁ臣꾏ꛨ릂苣뎃菣ꢃ裥銂귨ꖈ臣讂臣膂臣몼臩ꖈ菣讃菣袃臣膀볯뢁裥ꚃ菣莃菣ꮁ뗧袐臣貂胣몼臩ꖈ菣讃菣袃臣覂迥醁臣뚈뻥ꆿ迥ꮁ鿥ꖁ臣ꚁ迥隦苣뾂菣鞃菩蚈苣베듧馁苣龁苣꺁苣뾂菣鞃菩蚈菣ꊃ菣ꚃ菣莃菣ꢁ苣馂臣膀苣뾂菣鞃菩蚈菣ꊃ菣ꚃ菣莃菣꾁胣뎂菣钃菣벃苣낂菣閃苣莃苣릂菣ꒂ菣ꦃ苣뎃臣貾雦ꮁ臣蒁臣閩뻤閁苣龁菣ꦃ菣벃苣ꮁ뻤颭臣ꚁ臣讂ꛨ袁雦銂鳦馁苣릂苣뎃菣銂駧膀臣讂苣蚁臣ꪁ臣ꚁ臣讂胣袼볯馼볯베듧閁苣ꚁ臣讂럦閁諧讅胥꾁胣꾏ꛨ릂苣뎃菣ꢃ裥讁苣蚈鯩鞁臣베듧閁苣ꚁ臣讂볯銼볯覼臣風볨꺁髩貂ꇨꊝ駩뮎苣릂菣ꂃ胣袼볯邼볯몼臩ꖈ菣讃菣袃臣膀럦閁諧讅迥뎁菣ꒂ菣ꦃ苣뎃諧讅胥銂ꧨꆾ臣膀迧ꢜ臣꾁뷦ꢜ髧ꮁ迥隦臣릂苣뎃菣袼볯낼볯뎼볯ꢁ곧醼臣릂苣뎃菣ꢁ苣钯볨鞁胣릂苣뎃菣ꢃ裥ꆃ菣ꪃ臣膀볯뢁裥ꚃ菣莃菣讁苣꺁裥ꆾ뿤랏臣몟臣蒁臣膀곧醼臣릂苣뎃菣꺁룤ꢃ臣閩뻤閁苣龁苣뾂菣鞃臣몟臣蒁臣肜뗧낂菣閃苣莃苣릂菣ꎂ苣鞃菣ꒂ苣ꆃ菣뢂臣놽鿩銂迥벁臣ꪁ臣뒠郥ꮁ臣견볯꺁苣뾂菣鞃苣뒠ꏦ鞁胣견볯꺁苣뾂菣鞃臣ꎼ볯뚼볯銂髩馁ꃥ袐臣꾁胣ꎼ볯뚼볯銂ꃧ蒣臣ꚁ곧醼臣릂苣뎃菣銂볯낼볯뎼臣鞁胣견볯꺁苣뾂菣鞃迥뎁볯낼볯뎼臣ꆸ胨貁냥ꪁ臣ꢁ苣ꢃ裥蒚臣肜뗧낂菣閃苣莃苣릂菣ꎂ苣鞃菣ꒂ苣ꆃ菣뢂蛥ꮁꛨ袁苣뒠郥ꮁ臣ꎼ볯뚼볯銂駧膀臣ꚁ곧醼臣릂苣뎃菣銂볯낼볯뎼臣馁苣릂菣莃菣ꢁ胣견볯꺁苣뾂菣鞃迥뎁볯낼볯뎼臣讦臣릖臣뎂菣钃菣벃苣낂菣閃苣莃苣릂菣ꒂ菣ꦃ苣뎃蛥꺁뻥릖臣閩뻤閁苣讂菣ꦃ菣벃苣ꮁ鿥ꖁ臣뒠郥ꮁ臣견볯꺁苣뾂菣鞃迥뎁볯낼볯뎼苣몙胩馁苣袂臣ꮁ臣ꎁ臣蒁苣袼볯颼볯ꮁ꣨覼臣ꂚ苣ꢡ鷩꒙軥랂苣蚃菣芀볯鎼볯覼볯ꎼ볯ꆼ볯뢁裥ꚃ菣莃菣꾁胣뺏菣ꪃ菣蚃苣隃臣螤闦꺁苣뾂菣鞃뷤꺽臣肜ꓥ骽胥銂뇦骮臣膀ꓨ낕臣릂苣뎃菣趽뷧꺁鳦Ꞥ뷯ꒀ臣뺏菣ꪃ菣蚃苣隃臣肜냥骽胥ꢁ苣钯볨鞁胣뺯뿥馁苣릂苣뎃菣뢁諦鎃菣袃苣뮂菣袃臣膀臣讂苣뾂菣鞃ꇨ薆臣릂苣뎃菣趽뷧꺁鳦Ꞥ뷯ꒀ臣뺏菣ꪃ菣蚃苣隃臣肜냥骽胥袂苣节ꓥ趁臣뒠郥ꮁ臣鶁臣릂苣뎃菣꺁ꇨ銂菣궃苣릂ꇨꢁ臣ꚁ귨ꖈ臣讂苣蚁臣ꪁ臣ꚁ臣讂볯銼볯覼臣風볨꺁髩貂ꇨꊝ駩뮎苣릂菣ꂃ胣袼볯銼볯릂苣뎃菣뢁諦ꚃ菣莃菣꾁胣뺏菣ꪃ菣蚃苣隃臣ꖎ꟨鞁臣蒁苣蒐菣궃苣릂ꇨ薆臣肜苣ꚷ迥뎁鳦节迥꺁苣뾂菣鞃苣몱껥鞁胣뺯뿥馁苣鞃菣龃菣ꎂ菣ꮂ菣것菣뢂菣莃菣銂껥ꦾ臣膀苣뾂菣鞃菣���ꪃ菣蚃苣隃苣邃菣莃苣鎃菣袃臣릂苣뎃菣뢁諦鎃菣袃臣銂뗧袐臣ꚁ鳦芵臣鲽鳥蒚臣꾏ꛨ꺁苣뾂菣鞃苣莃菣銂铧邈臣讂苣蚁臣ꪁ臣ꚁ臣讂볯鎼볯覼臣風볨꺁髩貂ꇨꊝ駩뮎苣릂菣ꂃ胣袼볯鎼볯몼臩ꖈ菣讃菣袃臣膀鳦芵臣鲽鳥蒚臣꾏ꛨ꺁苣뾂菣鞃苣莃菣薆臣芁苣릂苣뎃菣薆臣醼뗧꺁苣뎃菣ꮃ苧銂뇦骮臣膀볯蒵臣떂菣鞃菣릂蛥꺁ꓨ낕臣떂菣鞃菣릂臣骽胥銂꣨鞮臣膀꣨鞮臣貂臣骽胥ꢁꃦ趴臣貂臣蒁苣骽胥ꢁ苣钯볨鞁胣뚈뻥ꆿ迥銂蟥鮊臣讂苣蚁臣ꪁ臣ꚁ臣讂볯鎼볯覼臣風볨꺁髩貂ꇨꊝ駩뮎苣릂菣ꂃ胣袼볯钼볯몼臩ꖈ菣讃菣袃臣螤闦꺁볯뢁裥떂菣鞃菣뚊藦麃苣뎃苣馂臣膀郥몼臩ꖈ苣뎃菣ꮃ諧讅菣랂菣꾁苣뎃菣ꮃ臣龁苣꺁裥ꆾ뿤랏苣ꚸꇨꮁ迥醁胣ꚇ郧鞁胣鶁臣ꚁ蟥鮊臣讂苣蚁臣ꪁ臣ꚁ臣讂볯鎼볯覼臣風볨꺁髩貂ꇨꊝ駩뮎苣릂菣ꂃ胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯醼볯醀⼼䥄㹖†볯鎼볯覼苣뎃菣ꖃ菣뾂苣ꦃ菣ꎂ菣꾂苣ꒂ菣벃苣銂迦馆臣讂雦閳臣芁臣ꚁ胣辏蛥馁苣螤闦꺁菣ꪃ菣蚃苣隃苣鞏臣讂苣蚃菣鞃臣膀苣뎃菣ꮃ뷤꺽苣뢁諦馁苣릂菣莃菣ꢁ胣뢁諦閁苣龁苣뎃菣ꮃ뷤꺽臣誁臣讂鳦节觥릖臣趸胩躘臣떂菣鞃菣銂迦馆臣膀鳦节觥릖臣趸胩躘臣떂菣鞃菣꺁뷯ꒀ苣ꂁ볯ꢁ臣ꚁ껥ꦾ臣讂苣蚃菣鞃臣膀臩麊臣貂臣떂菣鞃菣趽뷧ꮁ臣醁苣견볯꺁ꓨ낕臣떂菣鞃菣꺁뷯ꒀ苣钯볨馁苣릂菣莃菣ꢁ胣뢁諦閁苣龁苣뎃菣ꮃ뷤꺽臣誁臣ꚁ胣ꂁ볯袂苣辰臣蒁뷯ꒀ苣覜臣膀곧醼臣螤闦꺁苣뎃菣ꮃ臣ꂁ볯ꮁ鳦节뿨蒁곧醼臣떂菣鞃菣銂뿨몼臣芁苣ꢁ껥ꦾ臣讂苣蚃菣鞃臣膀臩몼苣醿볯꺁胥ꮁ苣莃菣馁苣릂菣莃菣ꢁ胣뢁諦閁苣龁苣뎃菣ꮃ뷤꺽臣誁臣讂곧銼臣螤闦꺁苣뎃菣ꮃ臣骽胥銂꿦莼臣讂苣蚃菣鞃臣膀臩몼苣誂냥閁臣骽胥銂鳦鞁胣견볯꺁ꓨ낕臣떂菣鞃菣꺁臩몼臣肜苣醿臣뢁諦閁苣龁苣뎃菣ꮃ뷤꺽臣誁臣讂곧銼臣떂菣鞃菣銂뿨몼臣鞁臣骮뻧馁苣릂菣莃菣ꢁ胣견볯꺁苣뎃菣ꮃ苣辏蛥馁苣릂菣莃菣ꢁ苣ꮐ苣芀볯鎼볯覼臩麊臣貂臣떂菣鞃菣趽뷧ꮁ臣醁苣견볯꺁ꓨ낕臣떂菣鞃菣袼곧鎼臣떂菣鞃菣꾁胣견볯꺁ꓨ낕臣떂菣鞃菣꺁迥醁苣貂臣견볯꺁苣뎃菣ꮃ臣芁苣覼臣ꂁ볯袂苣辰臣蒁藥骀뷯ꒀ苣覜臣膀룤ꒁ藥骀뷯ꒀ臣견볯꺁ꓨ낕臣떂菣鞃菣꺁臩몼臣肜苣醿臣骽胥ꞁ臣讂ꃥ袐臣膀곧鎼臣떂菣鞃菣銂迦馆臣讂苣蚃菣鞃臣膀곧醼臣ꮂ苣뎃苣ꒀ苣ꒂ菣꾂菣ꆃ菣袃臣鮁臣떂菣鞃菣辏蛥ꪕ迥袼苣뎃菣ꮃ迦馆闧랏臣膀迦馆臣貂苣떂菣鞃菣���귨ꖈ臣讂볯銂껥ꦾ臣讂苣蚃菣鞃臣膀곧鎼臣螤闦꺁苣뎃菣ꮃ臣覂곧钼臣떂菣鞃菣銂臩麊臣讂苣蚃菣鞃臣膀곧銼臣ꮂ苣뎃苣ꒀ볯견볯꺁苣Ꚃ菣뾂臣膀ꧨꆾ苣뎃菣ꮃ闧랏苣骮뻧馁苣覼苣ꒂ菣꾂菣ꆃ菣袃臣鮁苣릂菣莃菣ꢁ胣떂菣鞃菣辏蛥ꪕ迥ꢁꧨꆾ苣뎃菣ꮃ闧랏臣銂꿦莼臣讂苣蚃菣鞃臣膀꿥鲿臣讂ꧨꆾ苣뎃菣ꮃ闧랏臣떂菣鞃菣辏蛥ꪕ迥ꮁ귧鞁臣뒠郥ꮁ臣떂菣鞃菣銂迦馆臣讂苣蚃菣鞃臣銂鯦ꮁ郥肂볯閼臣風볨꺁雦閳胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯醼볯醀⼼䥄㹖†裥꺁鷩袼裥麡볯ꮁ臣蒁臣膀鳦몙飦꺁볯뎼볯낼臣膀뿤颭胦ꂚ苣ꢡ鷩꒙軥銂臩財臣讂臣膂臣讧胩誏臣릖돦銂迦鮾臣讂胣邙껥馁苣节臣ꞁ臣ꪁ臣貁胣ꖻ룤꺁苣꺁苣ꮐ苣骤臣꺁껥붖臣ꊽ藦銂ꫨ躘臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯醼볯醀⼼䥄㹖†볯醼볯낂菣閃苣莃苣릂菣ꒂ菣ꦃ苣뎃蛥ꮁ臣蒁臣膀ꧧ鎖髧ꮁ臣覂臣龁ꃩꪕ臣ꒂ菣벃苣螃菣뾂苣ꆬ臣릂菣벃苣뢁胩讂臣膂臣릖돦ꞁ臣ꎁ臣膀苣ꆃ菣뢂菣벃苣꾁ꓨ낕臣목雩螃菣뾂苣ꮐ臣膀ꧧ鎖菣벃苣꺁郥목雩螃菣뾂菣꾁ꓨ낕臣뢂苣ꆃ菣ꪃ菣ꪃ菣蚃苣隃臣醰臣辁臣节볯ꒁ臣꺁ꃩ릂苣ꮐ臣膀郥뢂苣ꆃ菣ꪃ菣ꪃ菣蚃苣隃臣膀곧醼臣銼볯Ꚃ苣뎃菣Ꚃ苣蚈觥鞁臣蒁苣견볯꺁ꓨ낕臣颠鿥ꮁ꿥鞁臣낂菣閃苣莃苣릂菣ꒂ菣ꦃ苣뎃蛥꺁藥財苣蚃菣뢂臣袂臣ꚁꃦ趴臣貂臣誁苣膀鳦릖돦꾁胣궪蟥鞁裥ꆾ臣袂臣ꚁ胣뒰맥钃苣뮂菣薹迥뎁黥뒛菣꾂苣ꮃꯩ閁苣銼臣貀臣趁胣뺁臣螈苣誸臣ꚁ곧醼臣銼볯Ꚃ苣뎃菣Ꚃ볯견볯꺁볯꒼苣ꎂ菣覃苣꾁냦뎹菣꾂苣ꮃ맥ꮁ꿥鲿臣讂맥ꢁ胣芞鯧钃苣뮂菣颫臣ꮁ꿥鲿臣讂ꯩ閁苣覜臣ꚁ臣讂볯袂苣Ꞥ臣蒁곧銼臣銼볯Ꚃ苣뎃菣Ꚃ苣骮뻧馁苣릂菣莃菣ꢁ胣궪蟥鞁裥ꆾ臣袂臣ꚁ胣견볯꺁볯꒼苣ꎂ菣覃苣銂곧銼臣螤闦꺁ꃩ龟臣蚈觥馁苣袼郥颠鿥꾁곧銼臣Ꚃ苣뎃菣Ꚃ臣겋蟨꺁볯ꒁ臣颠鿥ꮁ꿥鲿臣膀郥견볯꺁ꓨ낕臣뾂苣ꮃ臣견볯꺁ꓨ낕臣颠鿥꺁냥ꪁ臣ꢁ苣醼臣꺁ꃩ龟臣袂臣ꚁ苣邃菣閁苣讂ꃩ龟苣ꮐ苣覼苣蚃菣鞃臣膀곧醼臣財臣膀볯꒼苣ꎂ菣覃苣꺁럥誸髩膀럥许髩膀迥誸髩膀臣龁臣뎏룤薚臣覂臣讂菣릂菣讁苣趽뷧骮苣閁苣龁ꃩ龟臣뺯뿥馁苣袂臣ꮁ胣螤闦꺁ꃩ龟臣蒐ꃩ龟臣財꿦ꮁ闧랏믤醁臣讂苣蚃菣鞃臣膀苣ꒂ菣ꚇ郧꺁菣뎃菣ꂃ苣벃苣뎃苣銂껥ꦾ臣讂苣蚃菣鞃臣膀苣ꒂ菣ꚇ郧꺁菣뎃菣ꂃ苣벃苣뎃苣ꮁ뻥ꎁ臣颠鿥躯臣膀곦꺁苣蚃菣뢂臣꺁苣ꆃ菣뢂菣벃苣銂菣ꊃ菣讁苣궪蟥馁苣蚃菣鞃臣銂郥肂胣㲂䐯噉ਾ䐼噉���䥄㹖胣醼볯醼볯醀⼼䥄㹖†볯銼볯뾂苣ꮃ蟥蚐臣ꦃ菣肃菣랂菣놂菣릂臣膀볯㲴畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯㲐猯扵鶼볯膀볯㲴畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢뷯讼볯㲑猯扵鶼뷯辽뷯㲄畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯㲮猯扵袼볯㲴畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢뷯㲎猯扵讼볯覼臣讂菣벃菣ꮁ뻥ꎁ臣骮뻧閁苣讂胣鎁臣ꮁ胣꺼볯견볯꺁ꓨ낕臣颠鿥薆臣颠鿥꺁闦膀볯鶼냦뎹菣꾂苣ꮃ맥쎅芞鯧钃苣뮂菣颫臣ꮁ雩鞁臣銺臣ꮁ듧꺁闦ꞁ臣誂胣궼臣颠鿥릂菣莃菣銂ꇨ鞁胣뒼猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰躽⼼畳㹢臣ꚇ郧閁苣讂곧銼臣螤闦꺁苣ꒂ菣꺁뷯ꪕ鯧꺁苣ꒂ菣ꞁ臣ꎁ臣膀볯ꚉ뷯ꚉ볯銈볯ꞁ臣讂苣蚁臣袼볯覼臣風볨꺁雦閳胣袼볯覼곧銼臣螤闦꺁苣ꒂ菣銂ꓨ낕臣릂菣醃菣뾂苣ꮃ臣蚈觥馁苣릂菣莃菣銂鯦ꮁ郥뾁胣蒐苣벃菣벃苣ꒂ菣꾁곧銼臣螤闦꺁苣ꒂ菣꺁꟦邈迥붃臣뾂苣ꮃ臣낕臣覂臣誂胣节臣讧裦꾏菨ꪁ苣ꒂ菣꺁闦貁볯袂苣Ꞥ臣醁苣낁胣겋蟨꺁볯ꒁ臣릂菣醃菣뾂苣ꮃ蛥꺁郥讧裦꾏菨ꪁ苣ꒂ菣꺁闦꾁곧銼臣螤闦꺁苣ꒂ菣薆臣莅臣趽뷧꺁郥讧裦꾏菨ꪁ苣ꒂ菣꺁闦ꮁ꿥馁苣겋蟨꺁볯ꒁ臣릂菣醃菣뾂苣ꮃ蛥꺁믤꺁郥뾂苣ꮃ臣ꎚ軦馁苣뾂苣ꮃ胣뺁臣꾁꿥銧럧뾂苣ꮃ臣芁苣袂臣ꪁ볯醼볯ꮁ꣨覼臣릖돦芀볯钼볯蚈觥릂菣莃菣ꮁ臣蒁臣膀꟦邈迥붃臣뾂苣ꮃ臣낕臣醼ꇨ쎌醼裥膀볯財韃볯鞈胣鎼ꇨ쎌鎼裥膀臣龁臣钼ꇨ쎌钼裥讁苣ꪁ苣낂菣벃菣讁苣뢁諦閁苣讂볯鎼볯ꮁ꣨覼臣릖돦芀⼼䥄㹖㰊䥄㹖䐼噉邀볯閼볯隼胣㲑䐯噉‾뒛臣ꖈ臣ꊝ볯蚃苣릂菣ꎃ볯ꮁ臣蒁臣膀鳦몙飦꺁볯뎼볯낼臣膀뿤颭胦ꂚ苣ꢡ鷩꒙軥銂臩財臣讂臣膂臣讧胩誏臣릖돦銂迦鮾臣讂胣邙껥馁苣节臣ꞁ臣ꪁ臣貁胣ꖻ룤꺁苣꺁苣ꮐ苣骤臣꺁껥붖臣ꊽ藦銂ꫨ躘臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯醼볯醀⼼䥄㹖†볯醼볯螃菣ꆂ菣覃苣ꦃ菣ꎂ菣꾂苣醃苣鞃菣ꒂ菣鞃菣뮂菣떂臣膀菣꾂苣膃菣ꚃ菣莃菣誏臣蚃苣릂菣ꎃ菣讃菣袃臣ꊖ胩馁苣蚃苣릂菣ꎃ菣ꊃ菣銂若袁胣蚃苣릂菣ꎃ菣讃菣袃臣蚃苣릂菣ꎃ菣ꊃ菣薆臣베듧閁苣ꚁ臣讂菣꾂苣膃菣麃菣鞃苣钃苣뮂菣閃菣낂菣뎃菣ꮁ臩ꢔ臣膀菣꾂苣膃菣꾁볯ꦼ볯麃菣鞃臣貂臣钸臣낕臣讂ꧨ내菣馃菣꺁룤ꎀ臣蚃苣릂菣ꎃ菣莃菣讁苣ꪁ苣膀郥麃菣鞃臣벜苧讁苣肉룤꺁럨ꊛ臣誁臣讂菣꾂苣膃菣꺁ꛨ鮎臣銂ꇨ鞁胣蚃苣릂菣ꎃ菣讃菣袃臣蚃苣릂菣ꎃ菣莃菣讁苣覸럧ꊽꏨ鎖苣芁ꇨ鞁胣肉룤꺁菣꾂苣ꮃ菣ꦃ苣ꆃ菣袃臣龁苣꺁귦몢臣뎩듧것菣ꮃ苣醿볤馁苣蚃苣릂菣ꎃ胥���銂駧龔臣膀菣꾂苣膃菣ꆃ菣ꪃ臣蚃苣릂菣ꎃ菣벃苣銂鳦鞁룤ꒁ菣ꊃ菣ꊂ苣뮂苣뚫郥銂룦醰臣鮁苣讉돦ꞁ苣꾂苣릂臣貂胣鎾臣ꚁ菣꾂苣膃菣ꚃ菣莃菣꺁苣ꮃ菣鞃菣袃苣릔雥馁苣袂臣ꮁ臣ꎁ臣蒁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯閼볯颼胣㲑䐯噉‾뒛臣ꖈ臣ꊝ볯ꊃ菣覃돦ꖅ迥뎁菣벃菣붊蟥覼臣誁臣ꚁ胣겜駧躘臣꒼볯Ꞽ볯꾁胣鶿귥Ꞁ髩貂ꇨꊝ駩뮎苣芁ꇨ馁苣龁苣꺁꟦ꂀ迥뎁雦閳苣邏뻤馁苣芀駩骮臣讂苣꺁臣꾁臣蒁臣膀믤许臣节臣銂郥肂ꓥ辁臣龮雦꺁뷥讅苣겪飦馁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯閼볯馼胣㲑䐯噉‾袼볯覼菣閃苣벃菣낂菣閃苣莃苣릂菣ꒂ菣ꦃ苣뎃菣궃苣莃苣꾁胣ꊃ菣覃諦몇菣讃菣袃迥뎁ꓥ銧뷥ꚃ菣莃菣ꮁ雩ꎀ臣讂ꓥ銧뷥ꆃ菣ꪃ苣馂臣膀菣벃菣붊蟥ꚃ菣莃菣꾁苣ꪂ菣袃菣ꚃ菣莃菣讁苣螃菣뾂苣袃菣벃菣銂迥醁臣螃菣뾂苣袃菣벃菣銂ꃩ릂菣벃苣ꢁ胣麝ꃩ릂菣벃苣袼ꃦ趴臣龁苣ꮁꓥ銧뷥ꆃ菣ꪃ臣膀苣貂苣覼臣ꮁ裥ꊛ臣膀菣벃菣ꢳ藥ꚃ菣莃菣꾁ꓥ銧뷥ꆃ菣ꪃ臣覂藥鮊苣鞏臣钸臣ꊃ菣覃菦놠苣醼臣뺁臣꾁臣貂믤誸臣隻臣ꚇ郧ꚃ菣莃菣뢁胩ꆿ臣膀菣벃菣ꢳ藥ꚃ菣莃菣꾁韦ꮁ苣ꎃ菣랂菣閁苣ꚁ臣讂菦놠苣颭裥馁苣뚊藦薃ꃥ銂뛧膌臣膀韦ꮁ苣ꎃ菣랂菣閁苣ꚁ臣讂菦놠苣膀苣骁胣鶁苣ꮁ苣ꎁ臣骀뿤꾸鿥薹苣鮸냥閁臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯銼볯醀⼼䥄㹖†鯦ꮁ裥꺁鷩袼菣ꦂ菣낂菣ꒂ菣ꎂ菣낂볯ꮁ臣蒁臣膀鳦몙飦꺁볯뎼볯낼臣膀뿤颭胦ꂚ苣ꢡ鷩꒙軥銂臩財臣讂臣膂臣讧胩誏臣릖돦銂迦鮾臣讂胣邙껥馁苣节臣ꞁ臣ꪁ臣貁胣ꖻ룤꺁苣꺁苣ꮐ苣骤臣꺁껥붖臣ꊽ藦銂ꫨ躘臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯銼볯醀⼼䥄㹖†볯醼볯螃菣ꆂ菣覃苣ꦃ菣ꎂ菣꾂苣醃苣鞃菣ꒂ菣鞃菣뮂菣떂臣誁臣ꚁ뷤ꢔ臣讂臣膂臣邃菣鞃菣莃菣뎃苣릖돦꾁胣邃菣鞃諥鲞苣袨껧馁苣ꢡ鷩ꮁ雩ꎀ臣讂菣꾂苣ꮃ菣ꦃ苣ꆃ菣袃臣膀菣ꦃ苣ꆃ菣袃臣ꊖ胩馁苣ꢡ鷩ꮁ꿥馁苣ꖎ럧목雩銂껥ꦾ臣讂ꇨꊝ軦骷胣鎾돦骷胣誏臣閳럧ꢁ胣钃苣뮂菣閃菣낂菣뎃菣ꮁ雩ꎀ臣讂ꇨꊝ뷤꺽臣誁臣ꚁꇨꊝ軦骷迥뎁뻥閳럧꺁雦醐臣誁臣讂菣뎃菣릊黦ꮁ苣ꎁ臣节臣覂臣貂臣ꢡ鷩閳럧꺁该몏苣ꢡ臣蚃苣릂菣ꎃ菣꾂菣ꮃ臣銂迥醁苣릂菣莃菣ꢁ胣ꢡ鷩ꖎ럧膀뻥閳럧膀迥뎁돦骷臣覂胣蚃苣릂菣ꎃ菣꾂菣ꮃ臣醐臣銂胨꺅臣ꚁ軦骷ꧧ鎖臣覂鯧목雩뢁臣覤迦銂껥ꦾ臣讂볯蒵臣몟뫥馃苣袃菣銂꣨鞮臣讂苣蚃菣鞃臣膀菣꾂苣膃菣馃苣袃菣ꮁ胣鞈臣몟뫥馃苣袃菣讁苣ꪁ苣覤迦麃菣ꪃ菣꾂苣���매鞮臣讂菣袃菣莃苣릂매鞮苣芁ꇨ馁苣鎁臣ꮁ苣ꎁ臣邃菣鞃諥鲞苣趏飦馁苣開迦鞁臣膀鯧목雩膀ꇨꊝ돦骷苣袨껧鞁胣開迦鞁臣膀鯧목雩膀ꇨꊝ돦骷臣芁苣邵黦銂뇦膂苣릂菣莃菣ꢁ胣開迦鞁臣膀鯧목雩膀ꇨꊝ돦骷苣뾽铧鞁臣钃苣뮂菣閃菣낂菣뎃菣꺁臣膂臣ꦃ苣蚃苣뎃苣袨껧銂臩財臣膀菣ꒂ菣ꎂ菣낂꣨鞮臣뾽铧閁苣讂藥誏臣認꟨馃苣袃菣袼볯誏臣ꢼ볯꺁ꏨ鎖迥뎁ꓥ鮏苣薿ꛨꢁ臣讂臣ꢁ臣辁胣邃菣鞃諥鲞苣龖藩鞁臣钃苣뮂菣閃菣낂菣뎃菣꺁臣膂臣讦軦醁臣ꮂ菣벃苣花苣讂苣蚃菣鞃臣銂郥鎂臣蒁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯閼볯銼胣㲑䐯噉‾袼볯覼苣뎃菣ꖃ菣뾂苣ꦃ菣ꎂ菣꾂苣ꒂ菣벃苣銂苣Ꞃ菣螃苣뎃苣馁苣龁苣꺁迥覤苣놂菣ꮃ菣뎃菣麃菣钃菣낂雦閳臣膀菣뎃菣릊黦銂菣莃菣馁苣芁苣ꢡ鷩ꮁ雩ꎀ臣讂ꓥ銧뷥꺁ꃩ릂臣龁苣꺁苣ꪂ菣袃菣馃苣袃菣袼볯㲶畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢뷯㲓猯扵膀볯㲶畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢뷯㲔猯扵膀볯覼迥뎁菣꾂苣膃菣馃苣袃菣袼볯芽볯銂迥醁苣릂菣莃菣ꢁ胣뢂苣ꆃ菣ꪃ菣꾂菣ꮃ苣颍뷤몟뫥馃苣袃菣㲫牢ਾ䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㐲⼼㹡⼼䥄㹖閁臣蚃苣릂菣ꎃ菣꾂菣ꮃ臣銂매鞮臣ꚁ菣꾂苣膃菣뮃ꓥ趁臣馃苣袃菣袼뷯뒼뷯馀볯銂뷥邈臣讂苣蚃菣鞃臣膀菣꾂菣ꮃ뷯ꮁ苣ꎁ臣蚃苣릂菣ꎃ菣Ꞥ臣閁菣꾂菣ꮃ臣邈裥銂鿥隺賥鞁胣몟뫦隌臣貂臣蚃苣릂菣ꎃ菣Ꞥ臣閁菣꾂菣ꮃ볯趽볯芽胢覼苣ꊽ裦馁苣릂菣莃菣ꢁ胣몟뫦隌臣貂臣蚃苣릂菣ꎃ菣Ꞥ臣閁菣꾂菣ꮃ臣颍뷤몟뫥馃苣袃菣ꢁ苣鞹껧鞁臣钃苣뮂菣趽뷧꺁臣膂臣꺛ꧧ鎖臣誁臣讂该몏臣龁跥趽돦骷볯꺼胢覼苣花苣讂苣蚃菣鞃臣銂郥뾁胣鶁苣ꮁ苣ꎁ臣钃苣뮂菣閃菣낂菣뎃菣邃菣鞃諥鲞苣花苣讂臣膂臣ꦃ苣蚃苣뎃苣袨껧銂臩財臣讂髩꺁菣꾂苣ꮃ뷤꺽臣誁臣讂ꇨꊝ軦骷迥뎁뻥閳럧꺁賦骮臣薿ꛨꞀ苣銎駩馁苣芀볯鎼볯Ꞥ臣閁臣蚃苣릂菣ꎃ菣Ꞥ臣閁菣꾂菣ꮃ苣鞹껧馁苣릂菣莃菣꾁胣몛껥辰闦릂매鞮菣벃菣Ꚃ苣ꊂ苣뾽铧馁苣鎁臣銂迥붃臣馁苣覤迦麃菣ꪃ菣꾂苣銂駧龔臣鮁苣袂臣ꮁ臣ꎁ臣蒁苣袼볯覼臣風볨꺁雦閳胣袼볯覼ꓥ趁臣ꢁ菣꾂苣膃菣뮃ꓥ趁臣馃苣袃菣銂매鞮臣讂苣蚃菣鞃臣膀闧ꪁ苣ꖎ럧목雩Ꞻ꣦뮳臣覂鯧목雩Ꞻ꣦뮳臣꺁ꓥ鮏苣骮뻧馁苣覤迦麃菣ꪃ菣꾂苣銂駧龔臣鮁苣袂臣ꮁ臣ꎁ臣蒁苣袼볯覼臣風볨꺁雦閳胣袼볯覼闧ꪁ苣ꖎ럧목雩Ꞻ꣦뮳臣膀菣ꪃ菣膀볯Ꞽ볯膀臣龁臣隻臣ꎅ뿧蒚臣Ꞻ꣦뮳臣覂臣讂苣���ꮃ菣鞃臣覂臩麊臣貂苣袂臣ꮁ臣ꎁ臣蒁苣袼볯覼臣風볨꺁雦閳胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯銼볯醀⼼䥄㹖†볯隼볯뎂菣钃菣벃苣낂菣閃苣莃苣릂苣ꆃ菣뢂苣랂苣벃菣ꎂ菣낂臣讂臣膂臣꾏ꓥ릂苣벃菣邃菣鞃菣莃菣뎃苣릖돦꾁胣邃菣鞃諥鲞苣袨껧馁苣낂菣벃苣놂菣ꮃ苣鞏臣讂苣蚃菣鞃臣膀苣것菣릂苣벃菣ꒂ菣벃苣ꮁ雩ꎀ臣讂菣꾂苣ꮃ菣ꦃ苣ꆃ菣袃臣龁苣꺁苣것菣릂苣벃菣랼뫥ꮁ꿥馁苣躰雩낕苣花苣讂苣蚃菣鞃臣膀냥ꊖ闦讁苣꺛ꧧ鎖蛥꺁该몏臣龁跥趽돦骷苣袨껧鞁胣钃苣뮂菣閃菣낂菣뎃菣邃菣鞃諥鲞苣花苣讂苣蚃菣鞃臣銂郥肂胣袼볯覼냥ꊖ闦讁苣꺛ꧧ鎖蛥꺁该몏臣龁跥趽돦骷苣袨껧馁苣릂菣莃菣꾁胣낂菣벃苣놂菣ꮃ볥ꚺ臣躰雩낕臣覂鯧목雩Ꞻ꣦뮳臣꺁ꓥ鮏苣骮뻧馁苣覤迦麃菣ꪃ菣꾂苣銂뷥邈臣讂苣蚃菣鞃苣ꮐ苣袼볯覼臣風볨꺁雦閳胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯銼볯醀⼼䥄㹖†볯颼볯뎂菣钃菣벃苣낂菣閃苣莃苣릂苣ꆃ菣뢂苣랂苣벃菣ꎂ菣낂臣讂臣膂臣邃菣鞃菣莃菣뎃苣馁苣龁苣꺁雦閳臣膀菣뎃菣릊黦銂꣨鞮臣讂ꇨꊝ臣ꊖ胩馁苣钃苣뮂菣閃菣낂菣뎃菣꺁臣膂臣膀ꓥ趁臣馃苣袃菣袼뷯覼迥뎁菣뎃菣馃苣袃菣袼볯芽볯誏臣颍뷤覤迦麃菣ꪃ菣꾂苣袼볯覼苣鞏臣讂苣蚃菣鞃臣膀ꓥ趁臣馃苣袃菣ꢁ菣뎃菣馃苣袃菣ꢁ苣鞹껧鞁臣蚃苣릂菣ꎃ菣Ꞥ臣閁菣꾂菣ꮃ볯趽볯芽胢覼苣ꊽ裦馁苣릂菣莃菣ꢁ胣馃苣袃菣鎽臣袂臣ꚁ菣꾂苣膃菣뮃ꓥ趁臣馃苣袃菣꺁裦蚈苣몟뫦隌臣膀鿥隺賥閁苣龁菣꾂苣膃菣뮃ꓥ趁臣馃苣袃菣袼뷯뒼뷯鶀볯銂뷥邈臣讂苣蚃菣鞃臣膀鿥隺賥閁苣龁菣꾂苣膃菣뮃ꓥ趁臣馃苣袃菣ꢁ跥趽ꓥ鮏菣袃菣莃苣릂臣銂매鞮臣膀该몏臣龁跥趽돦骷볯꺼胢覼苣花苣讂苣蚃菣鞃臣膀该몏臣龁돦骷臣邈裥銂蛥몟뫦隌臣膀蛥몟뫦隌臣貂臣馃苣袃菣袼볯鶀볯銂뷥邈臣讂苣蚃菣鞃臣膀蛥몟뫦隌臣貂臣馃苣袃菣銂귦辦賥鞁胣ꦃ苣蚃苣뎃苣袨껧銂臩財臣讂臣ꮁ뷤ꢔ臣貂苣颍뷤開迦閳럧銂뇦膂苣릂菣莃菣ꢁ苣ꮐ苣芀볯馼볯蚃苣릂菣ꎃ菣Ꞥ臣閁菣꾂菣ꮃ臣邈裥銂鿥隺賥馁苣릂菣莃菣꾁胣鞾苣貂苣麃菣ꪃ菣꾂苣銂鯥骮냥낕苧馃苣袃菣ꢁ臣ꚁꇨ馁臣ꢁ臣ꞁ臣讂苣蚁臣膀苣놂菣ꦃ苣뢁諦馁苣릂菣莃菣銂郥肂볯颼볯ꮁ꣨覼臣릖돦芀볯醼볯覼菣꾂菣ꮃ臣邈裥꾁苣ꮂ菣벃볯鎽猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰芽⼼畳㹢胣鎽猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰芽⼼畳㹢胣鎽猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰躽⼼畳㹢볯讁苣ꪁ苣膀菣꾂苣膃菣뮃���趁臣馃苣袃菣꺁裦蚈苣몟뫦隌臣讂苣蚃菣鞃臣膀뷯讁苣ꪁ苣蚃苣릂菣ꎃ菣Ꞥ臣閁菣꾂菣ꮃ苣膀뷯뒼뷯鶀볯袼뷯㲓畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢뷯㲓猯扵쌾趽猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰芽뷯㲓猯扵袽猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰鎽⼼畳㹢胣鎽猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰钽⼼畳㹢韃뷯㲍畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢뷯钽⼼畳㹢뷯㲈畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢뷯㲔猯扵膀뷯㲓畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢뷯㲎猯扵쌾趽猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰躽⼼畳㹢뷯㲋畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢뷯㲎猯扵覼臣袂臣ꮁ매鞮臣讂苣蚃菣鞃臣覂臣讂볯颼볯ꮁ꣨覼臣릖돦芀볯醼볯覼跥趽ꓥ鮏菣袃菣莃苣릂臣몛껥辰闦릂胥銂鯦ꮁ郥뾁胣颍뷤覤迦麃菣ꪃ菣꾂苣꾁鯥骮냥낕苧ꒀ苣뒛臣ꮐ臣膀鿥隺賥閁苣龁菣꾂苣膃菣뮃ꓥ趁臣馃苣袃菣ꢁ跥趽ꓥ鮏菣袃菣莃苣릂臣銂매鞮臣讂苣蚃菣鞃臣膀鯥骮냥낕苧鞹껧较菣覃苣Ꞃ苣銂뷤ꢔ臣ꚁ매鞮臣讂苣蚃菣鞃苣ꮐ苣袼볯覼臣風볨꺁雦閳胣袼볯銼볯開迦鞁臣閳럧꺁裦蚈苣趆鿥隺賥馁苣릂菣莃菣꾁胣馃苣袃菣鎽臣蚀闦袼볯込볯鎽猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰芽⼼畳㹢胣鎽猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰芽⼼畳㹢胣鎽猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰躽⼼畳㹢볯覼苣鞹껧鞁臣鶁苣覂臣ꒀ臣鎖臣ꎭ臣蒁雩芿苣趆ꋧ讫臣讂苣蚃菣鞃苣ꮐ苣袼볯覼臣風볨꺁雦閳胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯銼볯醀⼼䥄㹖†볯醼볯覼苣ꦃ菣ꎂ菣꾂苣薃ꃥ銂迦馆臣讂臣膂臣릖돦꾁胣螃菣ꆂ菣覃苣Ꞃ菣螃苣뎃苣ꊂ菣궂菣꾂菣ꎃ蛥ꞁ軦骷ꧧ鎖菣ꒂ菣ꎂ菣낂苣芁ꇨ馁苣릂菣莃菣銂郥肂胣袼볯钼볯낂菣閃苣莃苣릂菦놠苣辏蛥馁苣릖돦꾁胣꾏ꓥ릂苣벃菣邃菣鞃菣莃菣뎃苣銂臩財臣讂苣蚃菣鞃苣ꮐ苣芀볯醼볯覼苣ꦃ菣ꎂ菣꾂苣薃ꃥ銂迦馆臣讂雦閳臣膀蟨開鿥閺铧邈苣芁ꇨ馁苣릂菣莃菣銂郥肂胣袼볯隼볯낂菣閃苣莃苣릂菦놠苣辏蛥馁苣릖돦꾁胣ꪇ该뺋藩閃苣벃菣覃铧邈苣芁ꇨ馁苣릂菣莃菣銂郥肂胣袼볯鞼볯낂菣閃苣莃苣릂菦놠苣辏蛥馁苣릖돦꾁胣銧뫥誏臣Ꞥ臣閁꣨鞮苣겋ꯧ蒚臣財臣鎁臣ꮁ苣ꎁ臣閳럧鲣雩銂臩財臣讂苣蚃菣鞃苣ꮐ苣芀볯醼볯覼苣ꦃ菣ꎂ菣꾂苣辏蛥ꢂ菣뢂菣꾁胣ꖎ럧목雩ꦃ苣蚃苣뎃苣袨껧ꚃ菣莃菣銂若袁臣蒁苣芀볯醼볯覼苣ꦃ菣ꎂ菣꾂苣辏蛥ꢂ菣뢂菣꾁胣ꖎ럧목雩ꦃ苣蚃苣뎃苣袨껧ꚃ菣莃菣銂若袁臣蒁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯閼볯隼胣㲑䐯噉‾뒛臣ꖈ臣ꊝ볯낼볯뢼볯ꮁ臣蒁臣膀鳦몙飦꺁볯뎼볯낼臣膀뿤颭胦ꂚ苣ꢡ鷩꒙軥銂臩財臣讂臣���臣讧胩誏臣릖돦銂迦鮾臣讂胣邙껥馁苣节臣ꞁ臣ꪁ臣貁胣ꖻ룤꺁苣꺁苣ꮐ苣骤臣꺁껥붖臣ꊽ藦銂ꫨ躘臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯銼볯醀⼼䥄㹖†볯醼볯낂菣閃苣莃苣릂苣ꆃ菣뢂苣辏蛥馁苣龁苣꺁雦閳臣膀臣讂菣ꦃ苣ꆃ菣袃臣뺯臣ꚁ菣꾂苣ꮃ꿦꺁鿥隺臣閃菣낂菣뎃菣趓뷤銂臩財臣讂苣蚃菣鞃臣膀臣꺁菣ꦃ苣ꆃ菣袃臣뺯臣ꚁ苣뎃菣ꮃ꿦꺁鿥隺臣閃菣낂菣뎃菣趓뷤銂臩財臣讂苣蚃菣鞃臣銂郥肂胣袼볯覼菣꾂苣ꮃ꿦꺁鿥隺臣芁ꇨ馁苣릂菣莃菣꾁胣랂苣벃ꧨ鎨胣릂菣ꎂ菣鞃菣ꚩ꣩膀苣ꮃ菣ꆂꧨ鎨胣ꮂ菣벃ꧨ鎨臣閃菣낂菣뎃菣趓뷤꺁볯ꒁ苣钃苣뮂菣躯臣몟뫦ꞁ臩財臣讂臣ꢁ苣ꮐ苣袼볯覼臣風볨꺁雦閳胣袼볯覼苣뎃菣ꮃ꿦꺁鿥隺臣芁ꇨ馁苣릂菣莃菣꾁胣몼ꧨ鎨胣랷郥膀菣ꎂ苣ꪃ菣낂臣閃菣낂菣뎃菣趓뷤꺁볯ꒁ苣떂菣鞃菣躯臣몟뫦ꞁ臩財臣讂臣ꢁ苣ꮐ苣袼볯覼臣風볨꺁雦閳胣袼볯覼苣蚃菣랂菣ꚩ꣩銂菣꾂苣ꮃ꿦꺁鿥隺臣芁ꇨ馁苣꺁臣膀臣龁臣떂菣鞃菣躯臣몟뫦ꞁ臩財臣讂臣讁苣鞃菣낂菣ꂃ髧ꮁ臩麊臣讂苣蚃菣鞃苣뒛臣ꮐ臣膀臣貂苣꺁苣蚃菣鞃臣鎖臣膀苣蚃菣랂菣ꚩ꣩銂臩麊臣貂臣몟뫦ꞁ臩財臣讂苣蚃菣鞃苣芁ꇨ馁苣袼볯覼臣風볨꺁雦閳胣袼볯覼苣뎃菣ꮃ꿦꺁鿥隺臣芁ꇨ馁苣릂菣莃菣꾁胣떂菣鞃菣躯臣몟뫦ꞁ菣ꦃ苣ꆃ菣袃鏦鲽臣뾽铧馁苣龁苣꺁苣뎃菣ꮃ臣鞁臣芁苣钃苣뮂菣꺁볯蒵臣떂菣螃苣鎃苣ꞃ菣銂菣궃苣ꦃ菣蒚臣뢁諦馁苣릂菣莃菣銂郥뾁胣ꆬ臣ꞁ苣뎃菣ꮃ꿦꺁鿥隺臣견볯꺁菣ꦃ苣ꆃ菣袃鏦鲽臣뾽铧馁苣龁苣꺁苣뎃菣ꮃ臣鞁臣芁苣钃苣뮂菣꺁闧ꪁ苣蒵臣떂菣螃苣鎃苣ꞃ菣銂菣궃苣ꦃ菣蒚臣뢁諦馁苣릂菣莃菣ꢁ胣ꆬ臣ꞁ菣궃苣ꦃ菣蒚臣뢁諦閁苣龁苣뎃菣ꮃ苣뾽铧鞁臣膀菣ꦃ苣ꆃ菣袃臣뺯臣讂곧銼臣閃菣낂菣뎃菣趓뷤銂苣뎃菣ꮃ꿦꺁鿥隺臣芁ꇨ馁苣릂菣莃菣ꢁ苣뒛臣ꮐ苣袼볯覼臣風볨꺁雦閳胣袼볯覼苣뎃菣ꮃ꿦꺁鿥隺臣芁ꇨ馁苣릂菣莃菣꾁胣떂菣鞃菣躯臣몟뫦ꞁ菣ꦃ苣ꆃ菣袃鏦鲽臣뾽铧馁苣龁苣꺁苣뎃菣ꮃ臣鞁臣芁苣钃苣뮂菣꺁볯蒵臣떂菣螃苣鎃苣ꞃ菣銂菣궃苣ꦃ菣蒚臣뢁諦馁苣릂菣莃菣銂郥뾁胣蒵蛥꺁볯ꒁ臣떂菣鞃菣ꮁ闧ꪁ苣趇臣銂菣궃苣ꦃ菣蒚臣늉뷥ꚁ苣릂菣莃菣ꢁ胣鞃菣낂菣ꂃ髧ꮁ臩麊臣貂臣誏臣낕臣ꎁ臣趇臣颻臣閁苣龁苣뎃菣ꮃ苣뾽铧鞁臣膀菣ꦃ苣ꆃ菣袃臣뺯臣讂菣ꦃ苣ꆃ菣袃鏦鲽苣떂菣鞃菣躯臣몟뫦ꞁ臩財臣讂苣蚃菣鞃臣銂郥肂볯醼볯ꮁ꣨覼���릖돦芀⼼䥄㹖㰊䥄㹖䐼噉邀볯閼볯颼胣㲑䐯噉‾袼볯覼苣ꦃ菣ꎂ菣꾂苣ꒂ菣벃苣銂迦馆臣讂臣膂臣릖돦꾁胣芁苣閃菣낂菣뎃菣ꮁ꿥鞁臣랂苣벃ꧨ鎨胣릂菣ꎂ菣鞃菣ꚩ꣩膀苣ꮃ菣ꆂꧨ鎨胣ꮂ菣벃ꧨ鎨臣閃菣낂菣뎃菣趓뷤꺁볯ꒁ苣钃苣뮂菣躯臣몟뫦ꞁ臩財臣讂苣蚃菣鞃臣膀苣蚃菣랂菣ꚩ꣩銂菣꾂苣ꮃ꿦꺁鿥隺臣芁ꇨ馁苣꺁臣膀臣龁臣떂菣鞃菣躯臣몟뫦ꞁ臩財臣讂臣讁苣鞃菣낂菣ꂃ髧ꮁ臩麊臣讂苣蚃菣鞃臣膀苣蚃菣랂菣ꚩ꣩銂臩麊臣貂臣몟뫦ꞁ臩財臣讂苣蚃菣鞃臣膀苣뎃菣ꮃ꿦꺁鿥隺臣閃菣낂菣뎃菣趓뷤ꮁ뷤ꢔ臣讂臣膂臣떂菣鞃菣ꢁ臣ꚁ臣讂菣꾂苣ꮃ臣醼뗧꺁苣隃菣ꎂ菣뢂菣뎃苣鞃菣낂菣ꂃ髧ꮁ臩麊臣讂苣蚃菣鞃臣膀뗧薆臣銼臣꺁苣뎃菣ꮃ臣낕臣讂蟩뾁苣鞃菣낂菣ꂃ髧ꮁ觥鎽臣讂苣蚃菣鞃臣膀菣궃苣ꦃ菣蒚臣뢁諦閁苣龁迥뎁闧ꪁ臣ꚁ蟩뾁믤醁臣貂臣떂菣鞃菣銂뷤ꢔ臣ꚁ胣몼ꧨ鎨胣랷郥膀菣ꎂ苣ꪃ菣낂臣閃菣낂菣뎃菣趓뷤꺁볯ꒁ苣떂菣鞃菣躯臣몟뫦ꞁ臩財臣讂苣蚃菣鞃臣膀苣뎃菣ꮃ꿦꺁鿥隺臣견볯꺁菣ꦃ苣ꆃ菣袃鏦鲽臣뾽铧馁苣龁苣꺁苣뎃菣ꮃ臣鞁臣芁苣钃苣뮂菣꺁闧ꪁ苣蒵臣떂菣螃苣鎃苣ꞃ菣銂菣궃苣ꦃ菣蒚臣뢁諦馁苣릂菣莃菣ꢁ胣鞃菣낂菣ꂃ髧ꮁ臩麊臣貂臣떂菣鞃菣銂뷤ꢔ臣ꚁ胣閃菣낂菣뎃菣ꮁ꿥馁苣견볯꺁菣ꦃ苣ꆃ菣袃鏦鲽苣떂菣鞃菣躯臣몟뫦ꞁ臩財臣讂苣蚃菣鞃苣ꮐ苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯閼볯馼胣㲑䐯噉‾袼볯覼苣ꦃ菣ꎂ菣꾂苣ꒂ菣벃苣銂迦馆臣讂臣膂臣릖돦꾁胣릂菣뎃苣ꮃꧨ鎨苣钃苣뮂菣躯臣몟뫦ꞁ臩財臣讂臣讁胣뺁臣꾁苣뎃菣ꮃ꿦꺁鿥隺臣芁ꇨ馁苣꺁臣銂菣궃苣ꦃ菣蒚臣뢁諦鞁胣릂菣뎃苣ꮃꧨ鎨苣뢁諦閁苣龁鿥隺臣芁ꇨ馁苣릂菣莃菣銂郥肂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鎼볯醀⼼䥄㹖†볯馼볯螃菣뾂苣베듧馁苣龁苣꺁苣뎃菣ꖃ菣뾂迥궪ꫥ鎽臣芁臣ꚁ胣銪뷤薆臣超뷧閁苣ꚁ臣讂苣뎃菣ꖃ菣뾂菣궃苣ꦃ菣꾁胣閃菣낂菣뎃菣ꮁ꿥鞁臣閃菣낂菣뎃菣趓뷤銂菣꾂苣ꮃ꿦꺁鿥隺臣芁ꇨ鞁胣閃菣낂菣뎃菣ꮁ꿥馁苣閃菣낂菣뎃菣趓뷤銂苣뎃菣ꮃ꿦꺁鿥隺臣芁ꇨ馁苣鎁臣ꮁ苣ꎁ臣膀苣ꦃ菣ꎂ菣꾂苣辏蛥랂苣蚃菣ꮁ苣ꆃ菣뢂苣辏蛥閁臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鎼볯醀⼼䥄㹖†볯醼볯覼菣벃苣銂ꃦ趴臣讂臣膂臣뎂菣钃菣벃苣꾏ꫨ銪뷤ꞁ臣ꎁ臣膀ꫥ鎽蛥ꮁ藩꺽臣貂臣蒁苣뎂菣钃菣벃苣鞃菣낂菣ꂃ臣膀臣讂菣ꦃ苣ꆃ菣袃臣뺯臣ꚁ胣랂苣벃ꧨ鎨胣릂菣ꎂ菣鞃菣ꚩ꣩膀苣ꮃ菣ꆂꧨ鎨胣���ꮂ菣벃ꧨ鎨臣閃菣낂菣뎃菣趓뷤꺁볯ꒁ苣钃苣뮂菣躯臣몟뫦ꞁ臩財臣膀苣蚃菣랂菣ꚩ꣩銂菣꾂苣ꮃ꿦꺁鿥隺臣芁ꇨ馁苣꺁臣膀臣龁臣떂菣鞃菣躯臣몟뫦ꞁ臩財臣讂臣讁苣鞃菣낂菣ꂃ髧ꮁ臩麊臣ꚁ苣蚃菣랂菣ꚩ꣩銂臩麊臣貂臣몟뫦ꞁ臩財臣膀苣뎃菣ꮃ꿦꺁鿥隺臣閃菣낂菣뎃菣趓뷤ꮁ뷤ꢔ臣讂臣膂臣떂菣鞃菣ꢁ臣ꚁ臣讂菣꾂苣ꮃ臣醼뗧꺁苣隃菣ꎂ菣뢂菣뎃苣鞃菣낂菣ꂃ髧ꮁ臩麊臣膀菣궃苣ꦃ菣蒚臣뢁諦閁苣龁苣뎃菣ꮃ苣뾽铧鞁臣몼ꧨ鎨胣랷郥膀菣ꎂ苣ꪃ菣낂臣閃菣낂菣뎃菣趓뷤꺁볯ꒁ苣떂菣鞃菣躯臣몟뫦ꞁ臩財臣膀苣뎃菣ꮃ꿦꺁鿥隺臣견볯꺁菣ꦃ苣ꆃ菣袃鏦鲽臣뾽铧馁苣龁苣꺁苣뎃菣ꮃ臣鞁臣芁苣钃苣뮂菣꺁闧ꪁ苣蒵臣떂菣螃苣鎃苣ꞃ菣銂菣궃苣ꦃ菣蒚臣뢁諦鞁胣鶁臣ꚁ菣궃苣ꦃ菣蒚臣뢁諦閁苣龁苣뎃菣ꮃ苣뾽铧鞁臣閃菣낂菣뎃菣ꮁ꿥馁苣견볯꺁菣ꦃ苣ꆃ菣袃鏦鲽苣떂菣鞃菣躯臣몟뫦ꞁ臩財臣讂臣ꢁ臣袂臣ꚁ胣낂菣閃苣莃苣릂迦馆苣릂菣ꂃ臣ꒂ菣벃苣銂迦馆臣鮁苣袂臣ꮁ臣ꎁ臣蒁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯閼볯銼胣㲑䐯噉‾袼볯醼볯螃菣뾂苣베듧馁苣龁苣꺁苣뎃菣ꖃ菣뾂迥궪ꫥ鎽臣芁臣ꚁ胣銪뷤薆臣超뷧閁苣ꚁ臣讂苣뎃菣ꖃ菣뾂菣궃苣ꦃ菣꾁胣릂菣뎃苣ꮃꧨ鎨苣钃苣뮂菣躯臣몟뫦ꞁ臩財臣讂臣讁胣뺁臣꾁苣뎃菣ꮃ꿦꺁鿥隺臣芁ꇨ馁苣꺁臣銂菣궃苣ꦃ菣蒚臣뢁諦鞁臣릂菣뎃苣ꮃꧨ鎨苣뢁諦閁苣龁鿥隺臣芁ꇨ馁苣袂臣ꮁ臣ꎁ臣蒁苣芀볯醼볯覼苣ꦃ菣ꎂ菣꾂苣ꒂ菣벃苣銂迦馆臣讂苣릂菣ꂃ臣芁臣ꚁ胣낂菣閃苣莃苣릂苣鞃菣놂菣랂菣뎃臣覂臣뎂菣뎃菣銂迥醁苣龁苣꺁菣벃菣ꢁ胣辏蛥閁苣讂苣ꆃ菣뢂苣螃苣릂菣것苣뢁胩讂臣膂臣몇諥ꢁ胣鶃菣袃迥뎁蟥鮊臣邵郥閁苣ꚁ臣讂菣ꦃ苣ꆃ菣袃鏦鲽菣ꒂ菣ꦃ苣뎃臣銂若袁胣閃菣낂菣뎃菣趓뷤醃苣鞃菣ꒂ菣꾁胣芁苣閃菣낂菣뎃菣ꮁ꿥鞁臣閃菣낂菣뎃菣趓뷤銂菣꾂苣ꮃ꿦꺁鿥隺臣芁ꇨ馁苣龁苣꺁苣蚃菣뢂臣膀臣꺁菣ꦃ苣ꆃ菣袃臣뺯臣ꚁ菣ꦃ苣ꆃ菣袃鏦鲽苣떂菣鞃菣躯臣몟뫦ꞁ臩財臣讂臣膂臣릂菣벃苣ꢁ苣ꮐ苣ꞁ臣讂胣袼볯鎼볯钃苣뮂菣躯臣몟뫦ꞁ臩財臣讂臣膂臣릂菣벃苣꾁胣랂苣벃ꧨ鎨苣蚃菣뢂胣릂菣ꎂ菣鞃菣ꚩ꣩릂菣벃苣膀苣ꮃ菣ꆂꧨ鎨苣蚃菣뢂胣ꮂ菣벃ꧨ鎨苣蚃菣뢂臣醼臣銂郥鎂臣蒁苣袼볯銼볯ꮁ꣨覼臣薣뷧芀菣꾂苣ꮃ꿦꺁鿥隺臣芁ꇨ馁苣龁苣꺁苣蚃菣뢂臣膀볯ꚩ꣩릂菣벃苣膀럦袐苣蚃菣뢂胣螃苣뚂菣뎃苣릂菣���苣꺁볯ꒁ苣ꮐ苣ꞁ臣讂볯醼볯覼臣風볨꺁ꏨ꺽胣袼볯閼볯낂菣閃苣莃苣릂苣ꆃ菣뢂苣辏蛥馁苣龁苣꺁苣릂菣ꂃ臣膀苣ꦃ菣ꎂ菣꾂苣ꊂ菣ꪃ苣벃苣ꞃ菣讁苣꺁苣麃菣覃苣鞏臣讂臣膂臣鶃菣袃臣膀迦馆臣貂苣ꒂ菣벃苣銂菣ꎂ苣鞃菣ꒂ臣膀苣龁苣꺁蟥鮊臣膀볯醼臣風볨꺁ꫥ鎽臣膀菣벃菣膀蟥鮊胣誏臣銪뷤ꮁ뗧袐臣貂胣銪뷤薆臣뎂菣钃菣벃苣鞃菣낂菣ꂃ苣龮ꇨ馁苣龁苣꺁볯낼볯ꢁ苣馂臣ꚁ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鎼볯醀⼼䥄㹖†鯦ꮁ裥꺁鷩袼苣ꪂ菣袃菣覼臣誁臣ꚁ胣겜駧躘臣꒼볯Ꞽ볯꾁胣鶿귥Ꞁ髩貂ꇨꊝ駩뮎苣芁ꇨ馁苣龁苣꺁꟦ꂀ迥뎁雦閳苣邏뻤馁苣芀駩骮臣讂苣꺁臣꾁臣蒁臣膀믤许臣节臣銂郥肂ꓥ辁臣龮雦꺁뷥讅苣겪飦馁苣芀볯醼볯鎼볯낂菣閃苣莃苣릂菣ꒂ菣ꦃ苣뎃蛥ꮁ臣蒁臣뢂苣ꆃ菣ꪃ鏦鲽苣芁ꇨ馁苣龁苣꺁ꏨ꺽臣膀郥뚻臣隫郧誏臣ꦉ郧릂菣벃苣銂郥肂ꓥ鮏菣讃菣袃臣膀ꓨ낕臣隫郧릂菣벃苣銂郥肂觧蚐苣蚃菣뢂臣膀ꓥ鮏菣讃菣袃臣覂藥鮊苣鞏臣讂菣ꒂ菣ꎂ菣낂菣讃菣袃臣膀ꓥ鮏迥뎁菣ꒂ菣ꎂ菣낂菣讃菣袃臣覂藥鮊苣鞏臣讂苣ꪃ菣钃菣낂菣讃菣袃臣銂若袁臣蒁苣芀볯銼볯ꦉ郧릂菣벃苣꾁胣龮ꇨ銂苣뎃苣ꪃ菣隃臣讂ꓨ낕臣隫郧릂菣벃苣銂若袁臣蒁苣芀戼㹲뮃믤ꂊꫨ躘戼㹲 겜駧躘臣膀ꓥ辁臣ꦝ雦蒚臣讧胩膀雦閳胣誏臣讉ꃩ銂迦鮾臣讂胣讧胩꾁胣螃苣뢂苣ꮃ迥뎁鯥꾷苣ꮐ苣讀胣꺁鯥꾷胣뎂菣钃菣벃苣ꊂ菣궂菣꾂菣ꎃ迥뎁苣릂菣ꂃ胣醃苣鞃菣ꒂ菣ꊂ菣궂菣꾂菣ꎃ胣誏臣鞃菣뮂菣떂軦骶苣ꮐ苣骤臣꺁뷥뚊苣随苣芀雦閳ꯨ蒚臣꾁胣겜駧躘臣膀菣閃苣벃菣랂苣벃菣ꎂ菣낂胣誏臣螃菣ꆂ菣覃苣Ꞃ菣肃菣ꢁ藥ꮁ뷤ꢔ臣讂臣膂臣膀룤뎁臣膀룤겈髧ꮁ胣麝菣閃苣벃菣랂苣벃菣誏臣螃菣뾂菣궃苣莃苣뢁臣ꦁ铧Ꞁ苣覜臣讂믤꺁ꓥ辁臣ꦝ雦蒚臣讉ꃩ銂迦鮾臣讂胣鎽裥躇臣뺲胩鞁臣蒁苣낁胣骤臣꺁駧躘髧讧胩誏臣讉ꃩ銂룤ꆬ藥낂菣閃苣ꮂ菣鞃菣뮂菣떂臣ꊖ臣ꚁꫨ躘臣龁臣ꢁ胣骤臣꺁鷩낖胦꾁뫤ꆬ藥ꚇ郧ꮁ苣躘苣讁臣ꦁ铧ꞁ臣讂臣ꢁ胣鶁臣ꚁ룤겈髧ꮁ臣螃菣뾂蟥蚐迥뎁鏦鲽臣ꮐ臣貂臣蒁苣鎁臣貁郧ꎧ臣貂苣蚁胣设臣낁胣躱铧袨껧螃菣ꒂ苣膀苣릂菣ꂃ胣誏臣ꊂ菣궂菣꾂菣ꎃ臣ꊖ臣ꚁꓥ辁臣ꦝ雦Ꞁ苣龮迧馁苣鎁臣貁臣趁苣芀诨늹臣龮雦꺁뷥讅臣膀菣벃菣Ꚃ苣ꊂ臣꺁껥붖苣薿ꛨꢁ臣讂臣膀臣龁臣鶁苣讁苣꺁裥誛苣鞾苣鎁臣貁臣趁苣貁胣醰臣辁臣节诨늹臣ꦝ雦Ꞁ臣较菣覃苣Ꞃ苣뺁���꾁苣閃菣Ꚃ苣ꊂ볯閃苣벃菣Ꚃ苣ꊂ臣閽苣讁臣꺁껥붖胣誏臣鶁苣覂臣蒵郥辂臣ꮁ臩ꢔ迥붃臣芁苣鎁臣节郧ꎧ臣릁臣ꞁ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鎼볯醀⼼䥄㹖†룤낿臣龁駧躘髧ꪁ꟦ꂀ迥뎁雦閳臣袂臣ꚁ迦鮾臣貂苣ꦝ雦蒚觧늉臣ꖋ맥銂胣ꖻ룤ꮁꛨ蒴菣릂菣ꢁ臣ꚁ裥馌臣讂胣鎁臣ꪃ苣袃臣设ꓧꮁ臩躁臣膀駩骮臣鞁臣ꎧ蟩馁臣趁臣꾁臣蒁胣鞈賦馁苣讀胣꺁꟦ꂀ迥뎁触蚠臣蒁苣蒁苣ꪁ触閳臣蒵郥鮁苣鎁臣貁臣趁胣鎁苣覂臣蒵郥鮁臣讀胣ꮁ菣릂菣閁苣ꚁ臣ꪁ臣鎁臣ꮁ觧ꮁ돦꺛臣貂臣蒁胣뒛臣鎁臣ꪃ苣袃臣膀臣貂苣꺁鷩낖臣ꦁ铧銂룤ꆬ藥낂菣閃苣莃苣릂菣궃苣莃苣ꮁ鯩궸臣ꚁ臣讂臣膀臣貂苣꺁鷩낖臣膀鳦躘듧뢛臣誁臣ꚁꫨ躘臣膀럦颻鯥ꊝ臣몤臣龁꟦ꂀ迥뎁볯뺁臣꾁鏦鲽苣覜臣讂뇦ꢔ꣨鞮菣랂菣ꮁ껥鎘臣ꦁ铧馁苣鎁臣貁臣趁苣芀⼼䥄㹖㰊䥄㹖䐼噉邀볯閼볯閼胣㲑䐯噉‾겪飦鞁臣겜駧躘臣膀믤许臣骤臣꺁駧躘髧讧胩誏臣릖돦銂迦鮾臣讂臣膀臣貂苣꺁꟦ꂀ迥뎁触蚠臣邙껥閁苣讂苣꺁臣꾁臣蒁胣覸곦莅苣ꦃ菣ꎂ菣꾂苣螃菣ꆂ菣覃苣Ꞃ菣肃苣벃苣蚃苣膃菣鮼뿤颭胦ꂚ苣ꢡ鷩꒙軥鮼苣ꒂ菣袅迥誂볯螖蓨螈迦袁볯袂苣꾉ꗥꪁ苣ꒂ菣ꊂ苣꒙軥꺁臣膂臣뎼볯뒼臣袂苣麃菣膃菣릂볯떂菣鞃菣趽뷧꺁臩麊볯뮂菣袃苣莃菣趉臣蚈ꇩ鮼菣ꖂ苣벃菣醃苣莃菣鮼菣놂菣袃賥螃菣뾂믨膀볯ꊂ菣閃苣ꚩ꣩膀럦袐胣릂菣ꎂ菣鞃菣ꦃ苣뎃귧鮼菣莃菣蚈觥鮼苣隃苣Ꞃ苣袃苣낂볯릉臣螃菣ꆂ菣覃苣Ꞃ菣螃苣뎃苣ꊂ菣궂菣꾂菣ꎃ臣誁臣讂볯鮼苣ꦃ菣목雩ꮁ臣醁苣뺯闦ꎭꛨ隌볯꺵该辰闦릂苣ꦃ菣覼볯邃菣꾂苣뎃菣麃苣꾂菣ꊂ菣궂菣꾂菣ꎃ볯릂苣ꎃ菣ꊂ苣袃룤꺁菣꾂苣ꮃ苣벃菣뎃苣鮼苣궂菣뎃苣Ꚃ菣芙臣꺻菦隃菣莃苣ꊻ胩袼볯겼볯覼볯钃苣뮂菣ꪂ菣誃菣랂菣鞃볯Ꚃ苣뎃菣Ꚃ볯꒼볯隃菣莃苣뎃苣誏臣麝菣궃菣궂菣낂룤궖菣ꮂ菣몂菣鮼뻥ꆁꇨ鞈菣ꮂ菣몂菣鮼ꃩ릂菣릂菣꺁臣膂臣袃菣꾂菣뾌藥鮼髩貂ꇨꊝ駩뮎볯뾂苣ꮃ賥ꎀ菦몼菣莃菣ꆂ볯鎼苣蚃菣뢂볯邃菣閃苣鞃菣뮂苣鮼菣閃苣벃菣랂苣벃菣ꮁ臣醁苣ꊂ菣閃苣ꚩ꣩誏臣릂菣뎃苣ꮃ臣놉臣膀苣뾂菣鞃臣膀迥ꞅ볯誏臣꒼뷯込뷯颽迥뎁볯颽볯蒽뷯ꢁ藥ꮁ룤膵臣꺁胩誂볯몼菣莃菣ꆂ臣覂裥ꊛ臣龁苣뾂菣鞃菩蚈菣ꊃ菣鮼裥麡臣貂臣辀飦Ꞁ苣ꮃ苣ꪃ苣ꂃ볯떂菣鞃菣鎽臣誂臣覜駩뚊藦麃苣뎃볯뎼볯궼껥뺏볯閃菣낂菣뎃菣麃苣꾂菣ꊂ菣궂菣꾂菣ꎃ볯Ꞽ볯꾼菣ꒂ苣궃苣벃苣蚃苣膃菣���菣ꒂ菣릂菣벃苣ꒂ菣뾂菣벃菣뎃苣鮼ꓥ銧뷥꾂菣莃菣뎃苣ꊂ菣뒂菣몂菣鮼뫤ꆬ藥隃菣莃苣麃苣꾂菣ꊂ菣궂菣꾂菣ꎃ볯邼臣覂볯뺁臣꺁매낕볯궼뷯貽裢醼볯邽볯鮼闦낕菣꺵该辰闦릂菣뒕闦袼볯蚽뷯覼菣莃菣ꚃ菣莃菣鮼菣벃菣벃듧낕껥뺏볯낕귥隃菣莃苣讧裦릖돦鮼菣ꮃ菣膃菣鞃胩ꆿ菣뎃苣낂菣閃苣莃苣릂볯螃菣ꆂ菣覃苣Ꞃ菣肃臣誁臣ꚁ菣벃菣銂臣꺁苣蚁臣놉臣讁볯ꊃ菣覃苣ꎃ菣膃菣낂볯궼볯궼菣ꒂ菣뾂苣袃菣벃苣鮼ꓥ銧뷥ꆃ菣ꪃ蛥꺁裥麡藥鎽蛥꺁苣ꪃ菣鞃臣貂臣骤꟨ꊽ볯閃苣뎃苣込菣뎃菣麃苣꾂菣ꊂ菣궂菣꾂菣ꎃ볯閃菣낂菣뎃菣ꢂ菣뢂菣꺁鷦首菣뾂苣馃菣릂돨邺觥鎽臣鮼菣꾂苣膃菣낒ꋥ誏臣ꦃ苣蚃苣뎃苣꺁臣膂臣肃苣誃菣莃苣麃苣꾂菣뎂菣覃铧邈볯螃菣ꆂ菣覃苣Ꞃ菣螃苣뎃苣ꊂ菣궂菣꾂菣ꎃ臣誁臣ꚁ軦骷ꧧ鎖菣ꒂ菣ꎂ菣낂苣ꦁ臣袂臣ꮁꇨ蚁臣鮼迥覤苣놂菣ꮃ菣뎃菣麃菣鞃볯ꪇ该몟뫥龔裦鮼꟨ꚺ迥뎁ꓥ趁臣銂裥薀臣財臣鎁臣ꮁ苣讂蟨開该超菣ꎂ菣ꮃ菣龔裦閳럧鲣雩鮼菣閃苣벃菣랂苣벃菣ꮁ臣醁苣鶃苣袃苣ꒂ菣蚈ꇩ뮂菣袃苣莃菣趓뷤鮼뗧肸臣龁菣ꪃ菣蚃苣隃꣨낿볯뾂苣ꮃ菣뢛꿥림胥誏臣릂苣ꪃ菣뎃鯧뺯볯ꒀ볯较菣覃苣Ꞃ苣뾂苣ꮃ裥麡볯膍裥ꪁꧧ鎖菣莃苣ꊂ菣莃菣ꆃ苣讃苣ꂃ볯ꖎ꟨鞁臣뾂苣ꮃ껥뺏볯蚃苣릂菣ꎃ蛥뾽铧麃菣膃菣낂菣뢂苣뾂볯螃菣ꆂ菣覃苣Ꞃ菣肃苣ꮐ苣覼볯钃苣뮂菣뢁详떼臣龁苣뎃菣ꮃ볯蚃苣릂菣ꎃ菣릂菣뎃菣ꪃ菣낂볯鮼苣ꒂ菣邃菣閃苣誏臣钃苣뮂菣邃菣閃苣袼菣꾂苣膃菣麃苣꾂菣ꊂ菣궂菣꾂菣ꎃ볯鮼迥뎁菣궃苣莃苣薆臣醃苣莃菣隌臣ꊻ胩芀⼼䥄㹖㰊䥄㹖䐼噉邀볯閼볯隼胣㲑䐯噉‾겜飦내鯦ꮁ꣨覼臣龁藥ꚁ臣誈ꇨꦉ胣릉꣨膀迥뎁觧놨蟥颡臣膀臣龁臣节郥讀胣꺁裥財觧뺁臣꾁觧놨蟥颡臣芏藧ꢁ臣ꚁ軦誂藥貂苣貂苣鎁臣銂觧骮髧ꮁ胣誏臣讀胣ꮁ賦몤臣ꚁ臣讂臣꺁苣蚁臣讨뫥뺁臣膀迥ꞅ臣鞁臣ꆎ苣ꖅ苣ꚁ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣醼볯鎼볯醀⼼䥄㹖†믤誸臣膀鯥몤迥뎁ꫨ躘臣꺛髧꺁臣膂臣겜駧躘臣릉껥꺁껥붖臣ꊽ藦銂ꫨ躘臣龁胣鎁苣覂臣膀鳦몙飦銂ꫨ躘臣龁닧蚯臣ꊽ諧ꮁ駩骮臣讂臣ꢁ苣辄鯥馁苣节臣ꞁ臣ꪁ臣膀믤誸臣馕ꓧ讁苣躘苣讁臣骤臣꺁ꓥ뒛迥뎁ꓥ隌臣꾏菨ꞁ臣讂胣겪飦鞁臣龮雦꺁뷥讅臣膀鳦몙飦꺁軥蚐迥뎁臣꺁껥鮚髧ꪁ뿥ꢔ苣겪飦馁苣龁苣ꮁ臩麊臣貂臣节臣ꞁ臣誂胣鎽裥躇臣뺲胩鞁臣蒁苣낁胣겜駧躘苣肜觨ꮁ뷤ꢔ臣讂臣ꢁ胣誏臣膼鯥馁苣릉껥���꺁铧钀臣ꦁ臣讂苣蚁臣蒁苣蒁苣ꪁꓥ뒛苣覜臣讂臣뺁臣뺁臣龮雦꺁뷥讅臣꾏菨ꞁ臣讂臣ꢁ臣蚐꟨閁苣袂臣芀鳦몙飦꺁꿧늛臣膀觧놨ꯨ花臣蒯鯥ꮁ苣ꎁ臣邙껥閁苣讂臣ꢁ苣辄鯥馁苣节臣ꞁ臣讂胣㲂䐯噉ਾ䐼噉㰾䥄㹖胣뎛鷩꺁냧颍臣겪飦醀⼼䥄㹖㰊䥄㹖胣뎛볯醀†鯥ꊝ뷤銂胣鶁苣ꪇ뫨꺁뫥馨믨膀ꛨ릂뫥馨돧膀苣꾂菣벃菣Ꞻ꣦ꢁ藥ꮁꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醀†볯꒼苣ꦃ菣ꎂ苣릂菣醃苣鞃菣ꒂ菣ꢔ臣膀뻥ꖝ黥辷꟧蒚菣뎃菣ꦃ菣銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醀†鳦몙飦꺁볯ꆬ藥낂菣閃苣꾂苣뮃菣ꒂ菣ꦃ苣뎃臣龮雦设胣릉臣膀苣ꪂ菣袃菣뮃苣뎃苣뎃볯邼볯邼臣隻臣龩菨隃菣莃苣ꚸ臣ꮁ菣릂菣誏臣鮃苣袃菣ꆃ菣ꪃ룤ꞁ껥財臣貂苣ꊂ菣ꪃ苣벃苣ꞃ菣ꢁ臣ꊖ뿤銂ꓧ馁胣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥钼胣ₑ겜駧躘臣螃苣閃苣벃菣뮃苣Ꞃ菣螃苣뎃苣뮃苣ꦃ菣ꎂ苣릂菣醃苣鞃菣ꒂ菣꺁곧醼껥붖뻤銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醀†鳦몙飦꺁菣ꎂ菣ꆂ菣覃菣랂苣벃菣ꎂ菣낂菣낂菣閃苣꾂苣뮃菣ꒂ菣ꦃ苣뎃臣견볯龮雦设苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥隼胣ₑ겜駧躘臣螃苣閃苣벃菣뮃苣Ꞃ菣螃苣뎃苣뮃苣ꦃ菣ꎂ苣릂菣醃苣鞃菣ꒂ菣꺁곧鎼껥붖뻤銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醀†鳦몙飦꺁菣ꎂ菣ꆂ菣覃菣랂苣벃菣ꎂ菣낂菣낂菣閃苣꾂苣뮃菣ꒂ菣ꦃ苣뎃臣견볯龮雦设苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥颼胣ₑ겜駧躘臣螃苣閃苣벃菣뮃苣Ꞃ菣螃苣뎃苣뮃苣ꦃ菣ꎂ苣릂菣醃苣鞃菣ꒂ菣꺁곧閼껥붖뻤銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醀†鳦몙飦꺁菣ꎂ菣ꆂ菣覃菣랂苣벃菣ꎂ菣낂菣낂菣閃苣꾂苣뮃菣ꒂ菣ꦃ苣뎃臣견볯龮雦设苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯醀†뿤颭胦낙鷩꒙軥꺁껥붖뻤銂胨龯臣讂臣膂臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯醀†뿤颭胦낙鷩袶軥꺁껥붖뻤ꮁ臣醁苣ꊂ菣閃苣뮃菣릂菣誏臣螃菣릂菣蚃苣袃苣莀꿥馁苣龁苣꺁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼胣ₑ鶿귥Ꞁ駩ꊝ駩뮎臣龮雦设臣誁臣讂苣蚃菣랂菣뮃菣릂菣銂胨龯臣讂臣膂臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯醀†뿤颭胦낙鷩꒙軥꺁껥붖뻤ꮁ臣醁苣ꊂ菣閃苣뮃菣것菣螃苣뎃苣銂胨龯臣讂臣膂臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯醀†뿤颭胦낙鷩꒙軥꺁껥붖뻤銂鯦ꮁ胨龯臣讂臣膂臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯醀†菣ꒂ菣ꦃ苣뎃臣龮雦设臣膀菣궃菣꾂苣骀苣螃菣뾂臣ꎻꇨ蒚菣궃菣銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛���隼胣ₑꮂ菣뮃菣궃菣꾂臣龮雦设臣膀菩蚈髧ꮁ髩閁苣ꚁ臣讂룤銧뷥讁苣閃菣낂菣뎃菣銂뷤讂苣誂雦銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鞼胣ₑ钃苣뮂菣뮃菣궃菣꾂臣龮雦设臣醼苣뾂菣鞃鯧鎽臣閃菣낂菣뎃菣銂蟥蚐臣讂苣誂雦銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯颼胣ₑ袅ꯧꢃ臣뎂菣뎃菣뮃菣Ꞃ菣膃迥뎁菣뎂菣覃菣隃菣莃苣袼볯ꚼ볯覼볯邼볯邼蛥꺁룤膦臣龩菨ꚃ菣莃菣銂ꓧ馁菣ꒂ菣ꦃ苣뎃臣龮雦设臣ꎻꇨ蒚菣궃菣꾂럧뎛苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥醼볯醀†菣ꎂ菣ꆂ菣覃菣랂苣벃菣ꎂ菣낂菣낂菣閃苣꾂苣뮃菣궃苣莃苣袼볯뎼볯낼볯꺁臣讂껥붖뻤貁ꃩ릂뫥馨苣覤迦馁苣鶁臣蒂苣릖臣Ꚅ苧銂뷥ꚁ臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥銼볯醀†菣ꎂ菣ꆂ菣覃菣랂苣벃菣ꎂ菣낂菣낂菣閃苣꾂苣뮃菣궃苣莃苣袼볯뎼볯낼볯꺁臣讂껥붖뻤貁胣閳럧膀귦ꖎ胣鎾돦骷苣覤迦馁苣鶁臣蒂苣릖臣Ꚅ苧銂뷥ꚁ臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥銼볯醀†苣ꪂ菣袃菣뮃菣궃菣꾂볯Ꞽ볯꾼볯꺁ꧦ붃菣궃菣꾂럧뎛苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥銼볯醀†駧躘髧讧胩꺁볯膃菣鞃껥붖뻤ꮁ臣醁苣認냥鎽菣莃菣誸臣龩菨隃菣莃苣鎖臣ꊖ뿤銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼胣ₑꊃ菣覃諦몇菣궃菣꾂볯궼볯ꊼ볯꺁臣讂껥붖뻤ꮁ臣醁苣ꎻꇨ蒚菣벃苣뮃菣궃菣銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯钼胣ₑꎻꇨ蒚菣벃菣붊蟥隃菣莃苣ꮁ胩覂苣讂菣놂菣袃苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥銼볯醀†믤ꢡ髧ꊃ菣覃諦몇菣궃菣꾂臣醼菣莃菣뚊藦馃苣袃菣몌裥꺁臣讂껥붖뻤銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯隼胣ₑ薃ꃥ銂ꓥ銧뷥ꆃ菣ꪃ臣뮂菣隃臣讂臣膂臣鞃菣뮂苣꺁藦颧苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥銼볯醀†볯ꖼ볯ꮁ雩馁苣骤꟨ꊽ菣ꊃ菣ꮁ꿥馁苣ꎻꇨ蒚꟦邈苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥銼볯醀†볯ꖼ볯隃菣莃苣ꮁ臣醁苣ꮂ菣벃菣鶃苣뎃苣뮃苣Ꞃ菣것菣랂菣뎃臣ꊖ臣讂苣ꦃ菣薃ꃥꮁ꿥馁苣ꎻꇨ蒚菣莃菣讧裦銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼胣ₑ궼볯뢼菣궃菣꾂臣誁臣讂苣ꦃ菣뮃苣ꒂ菣뮃菣ꎂ菣ꮃ菣ꮁ꿥馁苣ꎻꇨ蒚꟦邈苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥鎼볯醀†菣ꒂ菣袃菣ꪃ苣袃胣ꦃ苣뎃菣릂菣ꪃ菣鞃胣覸꟨ꊽ苣袃菣莃菣膀迥꾁룤銧뷥閃苣뎃臣ꪃ苣袃臣견볯螃菣ꊂ菣ꪂ苣袃蛥ꮁ꣨뚆臣貂臣궼볯궼菣ꒂ菣뾂菣醃苣莃菣꺁蛥릮苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥鎼볯醀†苣벃菣뮃菣ꊃ菣뮃菣벃苣ꮁ菣벃苣���꣨뚆臣貂苣蒂苣릖臣ꎻꇨ蒚껥붖뻤銂胣鶁苣貁菣벃苣風蛦薣뷧ꢁ菣ꒂ菣뾂꣨뚆ꏨ꺽臣蚈觥閁苣讂苣誂雦銂郥膂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥鎼볯醀†苣벃菣뮃菣궃菣꾂臣ꎻꇨ蒚껥붖뻤꺁胣颍듧隌臣龁菣궃菣꾂럧뎛苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼胣ₑ뾂苣ꮃ볯ꊼ볯誏臣袼뷯㲘畳⁢浸湬㩳灪∽瑨灴⼺眯睷樮潰朮⹯灪㸢볯覽뷯薽⼼畳㹢볯馽猼扵砠汭獮樺㵰栢瑴㩰⼯睷⹷灪⹯潧樮≰뒼뷯貽뷯㲅猯扵覼臣뮂菣뾂菣뎃苣閁苣龁苣ꒂ菣ꮁ雩馁苣뾂菣膃臣貂臣蒁苣뾂苣ꮃ臣袨껧꺁菣궃苣뢂菣꺁藦颧苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥鎼볯醀†苣莃菣閁苣ꚁ臣讂苣ꒂ菣꺁꣨鞮臣鞃菣랂苣ꎃ臣讅꟦銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯閼볯醀†苣莃菣閁苣ꚁ臣讂苣ꒂ菣꺁꣨鞮臣鞃菣랂苣ꎃ臣誁臣讂雩鶷鯩袨껧꺁藦颧苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥鎼볯ꊼ胣ₑ뾂菣膃臣貂臣蒁苣뾂苣ꮃ臣袨껧꺁菣궃苣뢂菣ꮁ臣醁苣뺖럨ꊛ꣨鞮臣讅꟦銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯隼볯醀†黥骷菣꾂菣ꮃ臣뺖럨ꊛ臣꺁雩꺁觧骮臣ꊖ뿤ꮁ꿥馁苣뾂苣ꮃ臣覸꟨ꊽ臣趽뷧꺁雩꺁곧醼雩芿苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥鎼볯ꊼ胣ₑ芞럧馃苣袃菣ꢁ雩鶷鯩ꢁ臣鎖臣릉껥꺁雩芿臣뺯臣讂苣ꒂ菣ꢁ룤銧뷥꺁뷤꺽臣鎖臣견볯ꊖ뿤銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯隼볯醀†黥骷菣꾂菣ꮃ臣뺖럨ꊛ臣꺁雩꺁觧骮臣ꊖ뿤ꮁ꿥馁苣뾂苣ꮃ臣覸꟨ꊽ臣趽뷧꺁雩꺁곧鎼雩芿苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥鎼볯醀†苣ꒂ菣꺁뻨꺁볯ꒁ臣뺯臣讂菣ꒂ菣꺁꟨ꚺ臣ꊖ뿤銂郥肂雩鶷鯩몱껥꺁苣것菣뎃菣銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯颼볯醀†볯颼뷯醼볯ꊂ菣ꒂ蛥ꮁ볯閼볯꺁苣ꒂ菣銂鳦馁苣Ꚃ苣뎃菣Ꚃ臣ꊖ臣讂苣벃菣벃菣뾂苣ꮃ菣鮃菣鞃菣鞃菣랂苣ꎃ菣랂菣놂菣릂臣ꎻꇨ蒚껥붖뻤銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯颼볯醀†鯥鎼볯ꆼ臣꺼볯隼볯膀볯鶼볯鎼臣뒠郥꺁苣벃菣벃菣뾂苣ꮃ菣鮃菣鞃菣鞃菣랂苣ꎃ臣ꊖ臣讂믤ꢡ髧랂菣놂菣릂苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥鎼볯醀†볯뒼볯隃菣莃苣ꮁ裥肝臣膀苣ꒂ菣ꊂ苣覃迥꾁苣뎃菣ꢂ苣ꪃ苣릂菣뮃菣벃菣ꞁ菣뎃菣벃臣趁苣꒼볯Ꞽ볯覸꟨ꊽ苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥钼볯醀†볯뎼볯낼臣ꦃ苣뎃苣膀苣꾃菣覃迥뎁꟦薀臣릖뷤꺁苣ꒂ菣ꊂ苣覃迥뎁苣뎃菣ꢂ苣ꪃ苣릂菣뮃菣ꒂ菣꺁迦馆臣龁苣ꮁ铧邈臣貂臣颧胣ꪁ苣꾃菣覃臣覤迦馁苣鎁臣ꮁ苣ꎁ臣것菣肃菣馁苣鶁臣蒂苣릖苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥钼볯醀†菣벃苣���賦骮苧貁苣ꪂ菣袃菣ꚃ菣莃菣薆臣것菣肃菣閁苣龁苧ꮁ苣뢂菣릂菣閁苣讂臣꺁苣誂雦銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼胣ₑꊂ菣膃苣ꒂ菣ꊂ苣覃菣ꦃ苣뎃菣뮂苣ꆃ菣袃臣膀맥財鯥몾뷥誏臣覸꟨ꊽ苣肸꟦ꮁ菣릂苣ꦃ苣몂臣讂볯떼볯ꚃ菣莃菣뮃苣궂菣뎃菣뎂菣邃菣뾂蛥ꞁ胣랕雦ꊽ臣覤迦閁苣讂臣꺁苣誂雦銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼胣ₑꢂ苣ꪃ苣릂菣뮃菣ꒂ菣꺁ꯧ릂臣膀맥財鯥몾뷥銂뷤ꎁ臣膀苣뎃菣ꢂ苣ꪃ苣릂菣뮃菣ꒂ菣꺁ꃥ袐臣랕雦ꊽ臣钯볨鞁臣袨껧閁苣讂臣꺁苣誂雦銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯钼胣ₑ랕雦ꊽ臣ꦃ苣뎃臣꾏ꛨꢃ苣ꢡ臣鶁臣蒂苣릖苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥钼볯醀†雦鞁臣ꦃ苣뎃꟥릂迥뎁苣蚃苣莃菣ꮃ菣ꪂ菣뮂菣袃볯钽뷯貽볯钽뷯銽뷯ꊼ뷯钽臣꾂菣莃菣覃菣鶃苣뎃菣ꮁ꿥鞁臣龔裦閁苣讂臣꺁苣誂雦銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯隼胣ₑꦃ苣뎃菣벃菣覸꟨ꊽ臣뢂苣ꆃ菣ꪃ苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥钼볯醀†苣莃菣ꊂ菣鞃臣膀ꃩ릂觥誂뷥ꚁ苣ꮐ苣膀菣ꒂ菣誏臣覸꟨ꊽ苣芦뷤ꮁꇨ馁臣꺁藦颧苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥钼볯醀†苣莃菣ꊂ菣鞃臣膀该超觥誂뷥ꚁ苣ꮐ苣膀菣ꒂ菣誏臣覸꟨ꊽ苣芦뷤ꮁꇨ馁臣꺁藦颧苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥钼볯醀†苣莃菣ꊂ菣鞃臣膀菣ꒂ菣꺁雦趽臣몟臣辁뇨邙觥誂뷥ꚁ苣ꮐ苣膀菣ꒂ菣誏臣覸꟨ꊽ苣芦뷤ꮁꇨ馁臣꺁藦颧苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥閼볯醀†苣莃菣ꊂ菣鞃臣膀苣ꪃ菣鞃꣨낿귥꺁釥趐迥뎁苣ꪃ菣鞃苣벃菣꺁郥芠苧뢁臣늉苣鎽臣銂郥膂胣ꦃ苣뎃迥뎁룤銧뷥銂ꛥ閽臣ꢡ臣讁苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥閼볯醀†苣莃菣ꊂ菣鞃臣릉껥꺁胥銂볯떼볯뢁ꛥ閽臣膀苣讁臣讅꟦銂郥膂胣뎼뷯钽뷯邽臣ꦃ苣뎃迥뎁룤銧뷥銂ꛥ閽臣ꢡ臣讁臣讅꟦銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼胣ₑ鶃苣뎃菣ꚇ郧ꢁ뗧뾁郥辂臣龁苣ꒂ菣Ꞻ꣦꺁뇦骮苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥閼볯醀†苣ꮃ菣隃菣莃苣꺁믤ꢡ髧龮雦设臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥閼볯醀†苣ꮃ菣隃菣莃苣뮃苣隃菣讃菣袃臣ꎻꇨ蒚껥붖뻤꺁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯閼胣ₑ궂菣莃苣ꖃ菣뾂苣뮃菣莃苣ꊂ菣鞃铧꺁苣뎃菣뎃菣뮃苣覃菣랂菣ꮃ菣ꆃ菣ꪃ볯ꎼ볯궼볯ꢁ껥ꢅ臣邵郥鞁臣貂苣뾽臣膀苣낂菣궂菣莃苣ꖃ臣ꎻꇨ蒚껥붖뻤꺁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯隼胣ₑ趽뷯薽菣벃苣貁뗦貂胣꒼볯Ꞽ볯醃苣鞃菣���菣꺁菩蚈臣궂菣莃苣ꖃ臣貂苣鶁臣蒂苣릖苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥閼볯醀†菣ꦃ苣ꆃ菣袃菣隃菣莃苣꺁믤ꢡ髧龮雦设臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥閼볯醀†꟦薀臣鞃菣龃菣ꎂ菣ꞁ뷥邈臣貂臣钃苣뮂菣뮃菣ꦃ苣ꆃ菣袃苣馂臣龁볯뎼볯꺁뻤銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼胣ₑ覸꟨ꊽ铧꺁臩醿뿤ꎭ藥骀蟩莿ꏨ鎖苣뾽臣龁菣ꦃ苣ꆃ菣袃菣隃菣莃苣鲣雩꺁藦颧苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥隼볯醀†ꓥ趁臣꺁闧ꪁ苣馃苣袃菣鎖臣鲣雩貁ꛥ閽臣趸鷥肸臣銧뫥내裥Ꞁ苣龔臣膀鳦몙飦꺁꟦ꂀ迥뎁雦閳臣閽闦鎁臣蒂苣릖臣閳럧誏臣ꎭ軦銂ꏨ鎖臣ꪁ臣讁臣设苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼胣ₑ閃菣낂菣뎃菣뮃菣궃菣꾂蛥ꞁꏨ鎖뿤낕苣ꊽ裦馁苣龁苣ꮁ뷤ꢔ臣貂苣閃菣낂菣뎃菣꺁뷯誏臣馽뫥馨臣芦뷤ꮁ뷥邈臣貂苣讁苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥隼볯醀†菣꾂苣膃菣뮃苣것苣뮃苣覃菣莃苣뎃苣꺁ꛦ膦苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥隼볯醀†菣ꦂ菣낂菣讃菣袃臣醃苣鞃菣ꒂ菣薆臣趽뷧誏臣ꎚ軦馁苣隃菣莃苣ꢁ臣ꊖ뿤銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯钼胣ₑ뺹臣讁臣떂菣ꚃ菣莃菣讁苣ꪁ苣閃苣뎃苣꺁菣궃菣꾂럧뎛苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥隼볯醀†볯ꦼ볯隃菣莃苣꺁菣궃菣꾂럧뎛苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥隼볯醀†볯膽뷯讽볯躽뷯隃菣莃苣袼볯ꮼ볯覼迥뎁臣貂臣ꒂ菣뾂菣Ꞃ菣릂臣讂菣讃菣袃苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥隼볯醀†볯ꮼ볯銂胩鞁臣ꆃ菣ꪃ臣궪臣随苣뢛臣벾臣銂ꇨ蚁ꓥꢃꇩꊮ菣讃菣袃苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꆼ볯醀†볯ꆬ藥ꪂ菣뢂苣꾂菣膀鯥ꊝ뷤銂胣鶁苣ꪇ뫨꺁뫥馨믨ꢁ藥ꮁꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼胣ₑꎻꇨ蒚臣辷꟧蒚볯꒼苣ꦃ菣ꎂ苣릂菣醃苣鞃菣ꒂ菣袏臣것菣肃菣銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼胣ₑ겜駧躘臣螃苣閃苣벃菣뮃苣Ꞃ菣螃苣뎃苣뮃苣ꦃ菣ꎂ苣릂菣鞃菣뮂菣떂볯꒼볯Ꞽ볯覼臣ꎻꇨ蒚껥붖뻤銂ꓧ馁鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꆼ볯醀†鳦몙飦꺁菣ꎂ菣ꆂ菣覃菣랂苣벃菣ꎂ菣낂菣낂菣閃苣꾂苣뮃菣궃苣莃苣袼볯뎼볯낼볯꺁裥꺁믤ꢡ髧龮雦设苣몤臣뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼胣ₑ鮛鷩鎽苣膀臣貂蟨ꮺ臣Ꞻ꣦뢻胣隦苧Ꞻ꣦뮳胣릂苣ꪃ菣뎃뫥馨臣놅臣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꊼ볯醀†믤ꢡ髧ꪁ藥財諦鎡臣袂苣鎼볯것菣肃菣뎃苣뮃菣ꒂ菣ꦃ苣뎃蛥꺁菣궃苣莃苣뎃苣뮃菣릂苣몤臣骷鯥ꞁ臣讂胣㲂䐯���ਾ䐼噉邀鯥ꊼ볯醀†菣벃苣醃苣銂볯ꒁ臣ꚸ裥醃苣ꮁ裥늉臣讂볯ꖼ볯떮髩ꢁ胣ꚸ裥醃苣銂볯ꒁ臣醃苣ꮁ뷤袐臣뒛臣궼볯ꪼ껦躚臣銂若袁臣膀鳦몙飦꺁볯꒼菣ꎂ菣ꆂ菣覃菣랂苣벃菣ꎂ菣낂菣낂菣閃苣꾂苣뮃菣ꒂ菣ꦃ苣뎃臣芁苣龮雦设臣誁臣讂菣궃苣莃苣뎃苣뮃菣릂苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꊼ볯醀†볯ꖼ볯떮髩膀볯ꦼ볯떮髩膀迥뎁苣ꒂ菣뮃苣벃菣ꎂ菣낂껦躚苣节若袁臣膀鳦몙飦꺁볯꒼菣ꎂ菣ꆂ菣覃菣랂苣벃菣ꎂ菣낂菣낂菣閃苣꾂苣뮃菣ꒂ菣ꦃ苣뎃臣ꖈ臣龮雦设臣誁臣讂菣궃苣莃苣뎃苣뮃菣릂苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꊼ볯醀†菣릂菣뮃菣궃苣莃苣誸臣龮ꇨ閁苣讂苣鞃菣놂菣랂菣뎃菣궃苣ꦃ菣ꞁ꟥뺁苣膀菣궃菣꾂雩꺁菦놠臣閃菣벃苣몤臣膀鳦몙飦꺁볯꒼菣ꎂ菣ꆂ菣覃菣랂苣벃菣ꎂ菣낂菣낂菣閃苣꾂苣뮃菣ꒂ菣ꦃ苣뎃臣芁苣龮雦设苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꊼ볯ꆼ胣ₑ鮃苣袃菣鞃菣뮂菣떂룤ꞁ껥財臣貂苣ꊂ菣ꪃ苣벃苣ꞃ菣鞃菣낂菣ꂃ臣讧臣讂胣隃菣莃苣鎖臣薃ꃥ꺁菣궃菣銂ꓧ馁胣겜駧躘臣鎼볯螃苣閃苣벃菣뮃苣Ꞃ菣螃苣뎃苣뮃苣ꦃ菣ꎂ苣릂菣醃苣鞃菣ꒂ菣꺁裥꺁껥붖뻤ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꊼ볯醀†鳦몙飦꺁菣ꒂ菣ꦃ苣뎃臣龮雦设臣肸菩꺁菣궃菣꾂苣骀苣ꎻꇨ蒚臣螃菣뾂臣閃菣벃苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꊼ볯醀†볯늼볯龩菨꺁觥ꮁ铧颁苣뎼볯낼ꧦ붃苣馂臣龁胣겜駧躘臣醃苣鞃菣ꒂ菣꺁껥붖뻤꺁룤ꢃ臣隃菣莃苣銂胩讂裥꺁믤ꢡ髧ꪁ菣벃苣꺁菣궃菣銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯颼胣ₑ궼볯뢼胣궼볯ꪼ胣뎼볯뒼臣뾽铧馁苣늼볯궼苣뎃苣閃苣벃苣꺁믤ꢡ髧讧裦銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼胣ₑ궼볯뢼胣궼볯ꪼ胣뎼볯뒼臣뾽铧馁苣놅铧늼볯궼苣뎃苣閃苣벃苣꺁裥꺁믤ꢡ髧讧裦銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†菦놠苣骤꟨ꊽ菣ꊃ菣誏臣붂菣袃菣ꊃ菣ꮁ苣벃菣馁苣龁苣꺁菣궃苣릂臣讅꟦銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†믤ꢡ髧ꪁ볯ꒁ臣覸꟨ꊽ臣覸꟨ꊽ菣莃苣ꖃ迥뎁꿥鲿臣讂볯ꒁ臣붂菣袃菣ꊃ菣꺁苣뎃菣ꪃ苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꊼ볯銼胣ₑ芠苧薃ꃥ뚼볯銂ꓥ銧뷥ꆃ菣ꪃ蛥ꮁ꣨뚆臣讂믤ꢡ髧릖돦銂胣뎛볯醼볯ꮁꓧ馁뻤꺁볯ꒁ臣芠苧ꮁ꿥鲿臣讂볯ꒁ臣ꢂ菣袃菣銂郥膂臣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꊼ볯鎼볯醀†苣ꪃ菣鞃臣貂臣覸꟨ꊽ臣릔觨閁苣龁菣궃苣莃苣뎃苣ꢔ臣閃苣뎃臣覤臣覂苣讂���겜駧躘臣芁苣讅꟦銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯ꊼ胣ₑ꾂菣莃菣閁苣龁룤銧뷥貁铦꾉臣貂臣鞃菣뮂菣랂菣낂铧꺁菣ꆂ菣ꮁꓥ袁苣貂苣膀鳦몙飦꺁臣讂藦颧苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꊼ볯钼胣ₑꎻꇨ蒚臣궼볯뢼菣궃菣꾂臣膀苣貂苣醃苣莃菣꺁뻤銂胣꾂菣莃菣閁苣龁ꓥ銧뷥ꮁ雩芿臣讂菣벃菣뮃菣벃苣銂郥膂臣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꊼ볯閼胣ₑ뎛볯醼볯ꮁꓧ馁菣놂菣袃臣设臣뺯뿥馁苣붂菣袃菣ꊃ菣薆臣ꢂ菣袃菣꺁뻤銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†鯥ꊼ볯钼臣몤臣醃苣莃菣꺁뻤ꮁ꿥鲿臣讂ꓥ銧뷥ꆃ菣ꪃ蛥꺁苣뎃菣ꪃ臣设苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꊼ볯鞼胣ₑ螃苣릂菣것苣뮃苣꾂菣벃菣ꢑ苣꺁苣ꪃ菣钃菣낂菣겂菣覃菣뎃菣꺁뻤銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†鳦몙飦꺁苣ꎃ菣랂菣낂諦閳臣芁苣龮雦设臣ꪂ菣것菣랂菣뎃苣몤臣閃菣벃菣ꎃ菣袃臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†볯뎼볯낼菣ꒂ菣ꦃ苣뎃臣芁苣ꢃ裥ꞁ菣벃菣螃菣뾂臣膵苣궂菣莃苣ꖃ臣貂苣鶁臣蒂苣릖苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꎼ볯醀†鳦몙飦꺁臣讂껥붖뻤ꮁ苣讂胣뾂苣ꮃ菣馃菣릂臣낂菣閃苣꾂苣뮃苣벃苣蚃苣膃菣ꞁ苣ꆃ菣뢂菣벃苣銂苣벃菣ꎂ菣낂臣讂臣膂臣랂苣蚃菣꺁菣궃菣꾂럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼胣ₑ겜駧躘臣芁苣龮雦设臣袂苣膀볯꒼苣ꦃ菣ꎂ苣릂菣鞃菣뮂菣떂臣隃菣莃苣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꎼ볯醀†苣벃菣隃菣莃苣뮃苣벃苣蚃苣膃菣꺁臣讂껥붖뻤銂ꓧ馁菣궃菣꾂럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯钼胣ₑ겜駧躘臣낂菣閃苣꾂苣뮃菣ꒂ菣ꦃ苣뎃臣芁苣龮雦设臣袂苣膀믤꺁菣궃苣莃苣뎃苣뮃苣蚃菣뢂볯醼볯꺁뻤銂ꓧ馁菣궃菣꾂럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯閼胣ₑ겜駧躘臣낂菣閃苣꾂苣뮃菣ꒂ菣ꦃ苣뎃臣芁苣龮雦设臣袂苣膀믤꺁菣궃苣莃苣뎃苣뮃苣蚃菣뢂볯銼볯꺁뻤銂ꓧ馁菣궃菣꾂럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鞼胣ₑ겜駧躘臣芁苣龮雦设臣袂苣膀ꫨ뾁迥誂裥ꆾ볯醼볯꺁菣궃菣꾂럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯颼胣ₑ겜駧躘臣芁苣龮雦设臣袂苣膀鯦趁뻨뾁裥ꆾ볯邼볯鞃菣랂苣ꎃ臣讅꟦銂ꓧ馁菣궃菣膃菣벃菣ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꎼ볯醀†鳦몙飦꺁臣讂껥붖뻤ꮁ苣讂胣뢛臣벾臣뚈뻥鎼볯閼菣궃苣뢂菣꺁藦颧苣몤臣閃菣벃菣ꎃ菣袃臣芁苣膀觧ꮁ鯥馼臣膀苣ꆃ菣뢂菣벃苣風蛦떮髩颼볯閼臣讅꟦銂ꓧ馁菣궃菣膃菣벃菣ꞁ臣讂胣㲂䐯噉ਾ䐼���邀鯥ꎼ볯醼胣ₑ겜駧躘臣芁苣龮雦设臣袂苣膀뿤벨臣貂臣鶿귥Ꞁ菣ꊃ菣讦ꧧ节苣鞃菣랂苣ꎃ臣讅꟦銂ꓧ馁菣궃菣膃菣벃菣ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꎼ볯銼胣ₑ겜駧躘臣芁苣龮雦设臣袂苣膀뿤벨臣貂臣鶿귥Ꞁ菣ꊃ菣讦ꧧ节苣鞃菣랂苣ꎃ臣讅꟦銂ꓧ馁菣궃菣膃菣벃菣ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꎼ볯鎼胣ₑ骤闦꺁苣ꒂ菣ꮁ裥늉臣貂胣莢闧뮔껥鲃菣꾂苣ꮁ迥誂鯥뺁苣龁룤銧뷥銂迦辁胣銼볯Ꚃ苣뎃菣Ꚃ臣讅꟦銂ꓧ馁菣궃菣꾂럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†鳦몙飦꺁臣讂껥붖뻤ꮁ苣讂胣鶿꣨閁苣龁뿤颭胦ꆃ菣ꪃꛨ趩苣誂菣벃苣讧胩꺁藦颧苣몤臣隃菣莃苣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꎼ볯閼胣ₑ겜駧躘臣芁苣龮雦设臣袂苣膀苣벃菣뮃菣궃菣꾂臣鞃菣랂苣ꎃ臣袂苣붂菣袃菣ꆃ菣ꪃ蛥ꮁ苣벃菣閁苣龁ꓥ낕臣뢂苣ꆃ菣ꪃ菣鞃菣龃菣ꎂ菣꺁藦颧苣몤臣隃菣莃苣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꎼ볯隼胣ₑ겜駧躘臣馕ꓧ꺁臣讂껥붖뻤ꮁ苣讂胣骤闦꺁苣ꒂ菣ꮁ苣誂裥늉臣貂胣骤闦꺁苣ꪂ菣袃菣뮃菣ꪃ菣蚃苣隃苣ꮐ苣ꞁ臣讂볯꒼苣ꎂ菣覃苣꺁藦颧苣몤臣隃菣莃苣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꎼ볯鞼胣ₑ겜駧躘臣芁苣龮雦设臣袂苣膀ꫨ뾁迥誂裥ꆾ볯醼볯鞃菣랂苣ꎃ臣讅꟦銂ꓧ馁菣궃菣膃菣벃菣ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꎼ볯颼胣ₑ겜駧躘臣芁苣龮雦设臣袂苣膀苣ꒂ菣ꊖ胩螃菣뾂苣낂菣閃苣꾂苣뮃菣ꒂ菣ꦃ苣뎃臣ꆬ臣릂菣벃苣颃胩讂臣膂臣릂菣醃菣뮃苣ꒂ菣뮃菣莃菣뮃苣벃苣뎃苣꺁藦颧苣몤臣膀苣벃菣벃菣뾂苣ꮃ臣讅꟦銂ꓧ馁臣膂臣隃菣莃苣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥꒼볯醀†뗧袐臣貂臣鞃菣龃菣ꎂ菣ꪁ꣨낿귥膀菣릂菣뮃苣ꒂ菣뮃苣벃菣ꎂ菣낂菣뮂菣袃苣莃菣膀苣ꒂ菣ꊖ胩馽胥膀苣꾂菣벃菣ꊖ胩颽胥銂뷤蒁胣鎼볯낂菣閃苣꾂苣뮃菣ꒂ菣ꦃ苣뎃臣뮂菣袃苣莃菣뮃苣骃菣벃苣ꞃ菣銂껥財臣讂臣膂臣膀鳦몙飦꺁臣讂껥붖뻤ꮁ苣讂苣릂菣ꂃ臣讅꟦銂ꓧ馁菣궃菣꾂럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼胣ₑ놵郥閁苣龁菣ꪃ菣蚃苣隃臣風뿨邭胣鶃苣袃菣뾂苣ꮃ菣붂菣蚃苣뎃苣뮃苣莃菣ꊂ菣鞃胣뾂苣ꮃ雩ꎀ뷯ꒀ胣릂苣ꪃ菣뎃雩ꎀ뷯ꒀ苣뾽臣膀볯꒼苣ꦃ菣ꎂ苣릂菣醃苣鞃菣ꒂ菣ꞁ苣莃菣ꊂ菣鞃菣ꪂ菣것菣랂菣뎃苣龮ꇨ馁苣龁苣꺁胣겜駧躘臣芁苣龮雦设臣袂苣낂菣閃苣꾂苣뮃菣궃苣莃苣꺁藦颧苣몤臣隃菣莃苣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥꒼볯醀†鳦몙飦꺁ꗥꦁ臣龮雦设臣袂苣膀苣ꦃ菣ꎂ苣릂菣醃苣閃菣ꒂ菣銼볯邼臣���隻臣鞃菣뮂苣뎃苣릂菣벃苣銼볯邼苣몤臣隃菣莃苣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥꒼볯醀†鳦몙飦꺁ꗥꦁ臣龮雦设臣袂苣膀苣ꦃ菣ꎂ苣릂菣醃苣鞃菣ꒂ菣銼볯邼臣隻臣鞃菣뮂苣뎃苣릂菣벃苣銼볯邼苣몤臣隃菣莃苣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥꒼볯醀†鳦몙飦꺁臣讂껥붖뻤ꮁ苣讂胣骤꟨ꊽ苣겜駧躘臣風뿨讧雦ꮁ苣誂꣨낿臣讂臣膂臣肸꟦ꞁ菣ꪃ菣蚃苣隃臣風뿨ꮁ苣讂胣芠苧늉뷥銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥꒼볯醀†鳦몙飦꺁臣讂껥붖뻤ꮁ苣讂胣뮂菣袃苣莃菣銼볯閼볯꺁胣겜駧躘臣ꆃ苣覃菣뢂苣龮ꇨ馁苣龩菨ꚃ菣莃菣꺁菣궃菣꾂럧뎛苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯鞼胣ₑ겜駧躘臣芁苣龮雦设臣袂苣膀룤銧뷥뺋藩늉뷥꺁뷤ꢔ苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯颼胣ₑ겜駧躘臣芁苣龮雦设臣袂苣膀룤銧뷥誏臣ꦃ苣뎃菣뮂苣ꆃ菣袃臣뺯臣讂该超觥鎽苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼胣ₑ겜駧躘臣芁苣龮雦设臣袂苣膀菣ꒂ菣뮃苣낂菣뎃菣릖뷤꺁藦颧苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†鳦몙飦꺁臣讂껥붖뻤ꮁ苣讂胣ꦃ苣뎃菣뮂苣ꆃ菣袃该超臣讅꟦銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥꒼볯醼胣ₑ겜駧躘臣芁苣龮雦设臣袂苣膀菣ꒂ菣뮃苣낂菣뎃菣뺋藩꺁藦颧苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†鳦몙飦꺁臣讂껥붖뻤ꮁ苣讂胣鶃苣뎃菣뮃菣궃苣莃苣뎃苣꺁藦颧苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†菣ꒂ菣뮃苣낂菣뎃菣릖뷤ꮁ꿥馁苣覸꟨ꊖ闦꺁雩芿苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†鳦몙飦꺁껥붖뻤ꮁ苣讂胣ꦃ苣뎃苣낂菣뎃菣鮛뻨ꊽ铧邈臣讅꟦銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥꒼볯閼胣ₑ겜駧躘臣芁苣龮雦设臣袂苣膀苣ꒂ菣ꊂ苣覃迥뎁苣뎃菣ꢂ苣ꪃ苣릂菣뮃菣ꒂ菣ꮁ雩馁苣颽菣뢂菣벃迥뎁뷯ꆃ苣ꎃ菣뮃菣ꒂ菣릖뷤꺁뻤銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥꒼볯隼胣ₑ鮛뻨ꊽ臣뺯臣讂뫤趉苣벃菣閁苣龁ꃩ릂觥鎽苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†菣ꪃ菣蚃苣隃臣뾂苣ꮃ臣꺁뫤꺷臣ꊖ臣讂菣ꪃ菣蚃苣隃臣꾂菣莃菣뎃苣뮃菣ꒂ菣袃苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†鳦몙飦꺁臣讂껥붖뻤ꮁ苣讂胣銼볯Ꚃ苣뎃菣Ꚃ臣隤臥ꮁ臣讂鯥몾뷥芠苧꺁菣궃苣莃苣뎃苣꺁藦颧苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†鳦몙飦꺁껥붖뻤ꮁ苣讂胣覸꟨ꊽ臣肜냥螃菣릂胥芠苧馀ꏨ꺁뻤銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥꒼볯邼胣ₑ銼볯Ꚃ苣뎃菣Ꚃ臣蒯鯥꺁ꓥ뒁臣芁苣芠苧銂鳦馁苣鮛뻨ꊽ臣设苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀†鳦몙飦꺁껥붖뻤ꮁ苣讂胣꾂菣莃菣뮃苣벃菣芠苧늉뷥꺁藦颧苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀†���몙飦꺁臣讂껥붖뻤ꮁ苣讂胣뎂菣誃菣뮃菣ꦃ苣銂郥肂胣놵郥閁苣龁菣ꪃ菣蚃苣隃臣風뿨邭臣늉뷥꺁藦颧苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀†뗧袐臣貂臣鞃菣龃菣ꎂ菣ꢡ迧誏臣芠苧風뿨邭臣銧菣ꦃ苣銂ꓧ馁鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꖼ볯醀†鯥ꊝ뷤銂胣鶁苣ꪇ뫨꺁뫥馨믨膀ꛨ릂뫥馨돧膀苣꾂菣벃菣Ꞻ꣦ꢁ藥ꮁꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼胣ₑ鎼볯낂菣閃苣꾂苣뮃菣ꒂ菣ꦃ苣뎃铧꺁뻥ꖝ黥꺁럧낧髧것菣肃菣銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼胣ₑ겜駧躘臣鎼곦莅菣ꎂ菣ꆂ菣覃菣랂苣벃菣ꎂ菣낂菣낂菣閃苣꾂苣뮃菣ꒂ菣ꦃ苣뎃臣견볯龮雦设苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꖼ볯醀†鳦몙飦꺁볯ꆬ藥螃苣閃苣벃菣뮃苣Ꞃ菣螃苣뎃苣뮃苣ꦃ菣ꎂ苣릂菣醃苣鞃菣ꒂ菣꺁곧銼껥붖뻤銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯閼胣ₑ겜駧躘臣鎼곦莅菣ꎂ菣ꆂ菣覃菣랂苣벃菣ꎂ菣낂菣낂菣閃苣꾂苣뮃菣ꒂ菣ꦃ苣뎃臣견볯龮雦设苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꖼ볯醀†鳦몙飦꺁볯ꆬ藥螃苣閃苣벃菣뮃苣Ꞃ菣螃苣뎃苣뮃苣ꦃ菣ꎂ苣릂菣醃苣鞃菣ꒂ菣꺁곧钼껥붖뻤銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鞼胣ₑ겜駧躘臣鎼곦莅菣ꎂ菣ꆂ菣覃菣랂苣벃菣ꎂ菣낂菣낂菣閃苣꾂苣뮃菣ꒂ菣ꦃ苣뎃臣견볯龮雦设苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꖼ볯醀†鳦몙飦꺁볯ꆬ藥螃苣閃苣벃菣뮃苣Ꞃ菣螃苣뎃苣뮃苣ꦃ菣ꎂ苣릂菣醃苣鞃菣ꒂ菣꺁곧隼껥붖뻤銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼胣ₑ醃苣鞃菣ꒂ菣꺁껥붖뻤꺁菣궃菣꾂雩銂胩讂믤ꢡ髧螃菣뾂臣閃菣벃苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꖼ볯邼胣ₑ隃菣莃苣鎖苣骀苣薃ꃥ銂郥膂胣겜駧躘臣鎼곦莅苣ꦃ菣ꎂ苣릂菣醃苣鞃菣ꒂ菣꺁껥붖뻤銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†苣ꮃ菣궃菣꾂臣龮雦设臣膀菩蚈髧ꮁ髩閁苣龁룤銧뷥讁苣閃菣낂菣뎃菣銂铧邈臣讂臣꺁苣誂雦銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†鳦몙飦꺁臣讂껥붖뻤ꮁ苣讂苣ꮃ菣隃菣莃苣꺁菣궃菣꾂럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯ꆼ胣ₑ겜駧躘臣龮雦设臣誁臣讂苣ꒂ菣膀菣꾂苣ꮃ胣릂苣뎃菣ꢃ裥꺁雩꺁雩芿苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯ꊼ胣ₑ겜駧躘臣龮雦设臣誁臣讂苣ꒂ菣膀菣꾂苣ꮃ胣릂苣뎃菣ꢃ裥꺁雩꺁雩芿苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯ꎼ胣ₑ겜駧躘臣龮雦设臣誁臣讂苣ꒂ菣膀菣꾂苣ꮃ胣릂苣뎃菣ꢃ裥꺁雩꺁雩芿苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†鳦몙飦꺁臣讂껥���붖뻤ꮁ苣讂胣ꮂ菣뮃菣궃菣꾂臣뎩듧ꪁ菣궃菣꾂럧뎛苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†鳦몙飦꺁臣讂껥붖뻤ꮁ苣讂胣뮂菣袃苣莃菣뮃苣Ꚃ菣鞃菣袃菣鞃菣龃菣ꎂ菣뮃菣놂菣袃苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†鳦몙飦꺁臣讂껥붖뻤ꮁ苣讂胣鶿귥Ꞁ駩ꊝ駩뮎돦꺁菣궃菣膃菣벃菣銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥ꖼ볯鞼볯醀†菣ꪃ菣蚃苣隃迥뎁ꋥ貕铧骮菣莃苣릂苣ꮐ苣떂菣鞃菣뮃苣ꒂ菣銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥ꖼ볯鞼볯醀†苣ꒂ菣薆臣蒐苣뾂菣鞃꿦꺁鳦Ꞥ뷯ꒀ볯몼볯膽뷯覼苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯ꎼ胣ₑ鞃菣龃菣ꎂ菣ꮁ꿥馁苣몼볯覽뷯ꢁ郥릂苣뎃菣ꮁ꿥馁苣몼볯膽뷯薽뷯ꢁ臣鎖臣骽胥钯볨꺁뗧鲞苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†鳦몙飦꺁臣讂껥붖뻤ꮁ苣讂胣鶿귥Ꞁ駩ꊝ駩뮎돦꺁苣뾂菣鞃臩麊菣궃苣릂臣设苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†냥ꪁ臣ꢁ苣醼臣꺁苣뎃菣ꮃ菣ꒂ菣袃苣ꮐ苣蒐苣隃菣릂苣벃菣ꦃ苣뎃臣誁臣讂菣ꪃ菣蚃苣隃臣肜럥誏臣肜迥趽뷧꺁苣莃菣銂ꓧ馁뻤銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥ꖼ볯邼胣ₑ钼臣꺁菣꾂苣ꮃ苣ꮐ苣릂苣뎃菣銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥ꖼ볯醼볯醀†볯ꮂ菣뮃菣讃菣袃臣ꪂ菣것菣랂菣뎃臣设苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯ꊼ胣ₑ몼苣ꮃ菣ꚃ菣莃菣꺁苣骃菣벃苣ꞃ菣꺁뻤銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥ꖼ볯醼볯醀†볯ꮂ菣뮃菣讃菣袃臣ꪂ菣것菣랂菣뎃臣设苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯꒼胣ₑ몼苣ꮃ菣ꚃ菣莃菣꺁苣骃菣벃苣ꞃ菣꺁뻤銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥ꖼ볯銼胣ₑ몼苣ꮃ菣ꚃ菣莃菣ꮁ苣ꎁ臣떂菣鞃菣貁ꛥ閽臣ꚇ郧閁苣讂臣꺁뻤銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥ꖼ볯鎼볯醀†韦龜菣ꎂ苣醃菣膃臣设苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯ꊼ胣ₑꦗ鳦螃苣릂菣莃菣꺁뻤銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥ꖼ볯鎼볯醀†韦龜菣ꎂ苣醃菣膃臣设苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯꒼胣ₑꦗ鳦螃苣릂菣莃菣꺁뻤銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥ꖼ볯钼胣ₑꦗ鳦螃苣릂菣莃菣뮃菣궃苣莃苣뎃苣꺁苣뎃菣ꮃ菣것菣ꮃ臣设苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀†鳦몙飦꺁臣讂껥붖뻤ꮁ苣讂胣ꎼ볯뎼볯閳臣袂苣ꊂ菣閃苣뮃菣릂菣ꮁ苣讂菣궃苣莃苣뎃苣뮃苣뎃菣ꮃ臣设苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀†볯ꢼ볯늼臣龮雦设臣뺯臣讂菣뎃菣ꪃ菣낂菣ꪂ菣것菣랂菣뎃臣ꊖ臣讂苣蚃菣랂菣뮃菣릂菣ꎂ菣낂臣讅꟦銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥ꖼ볯鞼胣ₑꎼ볯뎼볯꺁껥붖뻤ꮁ꿥馁苣것菣肃菣뎃苣ꪂ菣것菣랂菣뎃臣ꊖ臣讂苣ꮃ菣ꆂ菣隃菣뎃菣ꎂ菣낂臣讅꟦銂ꓧ馁胣���䐯噉ਾ䐼噉邀鯥ꖼ볯颼볯醀†볯辽볯貽뷯袽뷯뒼뷯鎽뷯膀볯辽볯ꊼ뷯薽뷯蒽胣뒼뷯膽뷯鎽뷯膽뷯薽뷯钽臣鎼臣꺁裥ꆾ菣莃菣銂郥肂ꧧ鎖菣놂菣袃臣肸菩銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥銼볯ꊼ胣ₑ꒼뷯ꆼ볯貽뷯躽뷯뚈뻥鎃菣袃苣궨껥馁苣龁苣ꮁ苣ꮃ菣ꆂ胥貁ꛥ閽臣鞁臣花苣覂苣讂臣銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥ꖼ볯馼胣ₑ겜駧躘臣芁苣龮雦设臣袂苣膀苣벃菣袸臣辀飦ꊃ菣覃볯ꢼ볯늼돦꺁菣궃菣膃菣벃菣銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥ꚼ볯醀†볯ꆬ藥ꪂ菣뢂苣꾂菣誏臣鶁臣螃苣릂菣것苣뮃苣꾂菣벃菣誸臣ꒂ菣벃苣銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥ꚼ볯醀†鳦몙飦ꮁ苣ꎁ臣讧꿧閁苣龁菣꾂苣膃菣뮃菣ꒂ菣ꦃ苣뎃臣芁苣龮雦设臣隃菣莃苣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꚼ볯醀†苣ꦃ菣ꎂ菣꾂菣ꒂ菣벃苣ꮁ雩馁苣Ꞻ꣦뮳雩꺁雩芿苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀†鳦몙飦꺁闦몤臣袂臣ꚁ꟦覯臣貂臣蚃苣뮂菣뮃菣것菣Ꞃ菣膃菣邃菣閃苣꺁臣讂껥붖뻤銂ꓧ馁菣궃菣꾂럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀†鯥ꚼ볯ꆼ臣蚃苣뮂菣뮃菣것菣Ꞃ菣膃菣邃菣閃苣ꮁ雩馁苣蚃苣릂菣ꎃ菣邃菣閃苣뮃苣낂菣隃菣莃苣誏臣ꆃ菣ꪃ菣궂菣벃苣몤臣隃菣莃苣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꚼ볯醀†郥薀臣螤闦꺁菣꾂苣膃菣뮃菣ꊃ菣뮃菣邃苣릂苣ꮐ苣ꞁ臣讂ꓨ낕臣膃菣趃菣薆臣ꢷ裦閁苣龁菣꾂苣膃菣ꆃ菣ꪃ苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꚼ볯ꆼ胣ₑ겜駧躘臣芁苣龮雦设臣袂苣膀菣꾂苣膃菣뮃菣ꊃ菣ꮁ꿥馁苣목雩蒚臣뎂菣벃菣뎃菣ꪁ菣꾂苣ꮃ菣麃菣钃菣낂苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯隼볯醀†鳦몙飦꺁臣讂껥붖뻤ꮁ苣讂胣蚃苣릂菣ꎃ菣ꆃ菣ꪃ臣뺯臣讂ꧧ鎖髧ꮁ苣銃菣것菣袃臣蚃苣뮂菣뮃菣莃菣뎃苣銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥ꚼ볯ꎼ胣ₑ겜駧躘臣芁苣龮雦设臣뾽铧閁苣讂苣覃菣릂菣麃菣钃菣낂苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯鞼胣ₑ겜駧躘臣芁苣龮雦设苣뾽臣ꚁ菣莃菣閁苣讂菣꾂苣膃菣뮃菣莃菣꺁苣벃菣벃菣隃菣莃苣銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥ꚼ볯醀†鳦몙飦꺁臣讂껥붖뻤ꮁ苣讂胣蒐苣꾂苣벃蛥꺁菣ꖃ苣ꮃ苣꾂菣뮃菣뎃菣ꪃ菣낂菣醃苣벃菣銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥ꚼ볯醀†鳦몙飦꺁臣讂껥붖뻤ꮁ苣讂胣蚃苣뮂菣뮃菣것菣Ꞃ菣膃菣邃菣閃苣ꮁ꿥鞁苣낂臣鞁臣趃臣蚃苣릂菣ꎃ菣뾂苣ꮃ菣ꊂ菣것苣讧胩ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꚼ볯邼胣ₑ겜駧躘臣芁苣龮雦设臣袂苣膀触鮜臣蚃苣릂菣ꎃ볯겼볯꒼臣讖꟥꺁臣膂臣蚃苣릂菣ꎃ菣ꆃ菣ꪃ蛥꺁菣벃苣뮃苣覃菣릂臣뺯臣讂菣ꒂ���뾂臣鞁臣뾽苣貂苣鶃苣뎃苣뮃菣莃苣ꊂ菣鞃ꓥ鮏苣낂菣隃菣莃苣ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꚼ볯醼胣ₑ蚃苣릂菣ꎃ菣ꆃ菣ꪃ菣ꊂ菣것苣꺁菣ꎂ苣ꮂ菣麃菣钃菣낂臣芁苣龮雦设臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†鯥ꚼ볯ꎼ胣馼胣醼볯膀볯醼臣ꊖ臣讂胣ꊂ菣것苣趆꟦邈迥뎁菣궃苣릂苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꚼ볯鎼볯醀†鳦몙飦ꮁ苣讂胣趆ꃩ辺臣醁苣릂菣ꂃ臣芁苣龮雦设苣몤臣隃菣莃苣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꚼ볯鎼볯醀†鳦몙飦ꮁ苣讂胣趆ꃩ辺臣醁苣릂菣ꂃ臣芁苣龮雦设苣몤臣隃菣莃苣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥Ꞽ볯醀†鯥ꊝ뷤銂胣鶁苣ꪇ뫨꺁뫥馨믨膀ꛨ릂뫥馨돧膀苣꾂菣벃菣Ꞻ꣦ꢁ藥ꮁꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼胣ₑ鎼볯낂菣閃苣꾂苣醃苣鞃菣ꒂ菣ꢔ臣膀뻥ꖝ黥辷꟧蒚菣뎃菣ꦃ菣銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼胣ₑ鎼볯낂菣閃苣꾂苣뮃苣릂菣ꂃ蛥ꞁ껥財臣貂苣ꦃ苣蚃苣뎃苣袨껧꺁苣것菣뎃菣銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯钼胣ₑ鎼볯낂菣閃苣꾂苣뮃苣릂菣ꂃ蛥ꞁ껥財臣貂苣邃菣鞃菣麃菣钃菣낂꣨鞮臣ꢂ菣ꆃ菣袃苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥Ꞽ볯ꆼ胣ₑ뎼볯ꦼ菣뎃菣뮃菣莃菣뎃苣銂껥財臣讂볯꒼苣ꦃ菣ꎂ苣릂菣醃苣鞃菣ꒂ菣꺁菩蚈臣龩菨閃菣벃럧뎛苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥Ꞽ볯ꊼ胣ₑ랂菣뎂菣뮃苣ꦃ菣ꎂ苣릂菣뎂菣钃菣벃苣뮃苣릂菣ꂃ苣龮ꇨ馁苣鎼볯낂菣閃苣꾂苣뮃菣ꒂ菣ꦃ苣뎃臣ꢃ裥꺁ꧦ붃菣궃菣꾂럧뎛苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥Ꞽ볯ꆼ胣ₑ貀菣ꪃ菣趀菣뎃菣뮃菣莃菣뎃苣銂껥財臣讂럧낧髧鎼볯낂菣閃苣꾂苣뮃菣ꒂ菣ꦃ苣뎃臣龩菨閃菣벃럧뎛苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥Ꞽ볯ꊼ胣ₑ隃菣뎃菣邃菣鞃菣麃菣钃菣낂苣龮ꇨ馁苣鎼볯낂菣閃苣꾂苣뮃菣ꒂ菣ꦃ苣뎃臣ꢃ裥꺁ꧦ붃菣궃菣꾂럧뎛苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥Ꞽ볯醀†鳦몙飦꺁볯ꆬ藥낂菣閃苣꾂苣뮃菣ꒂ菣ꦃ苣뎃臣芁苣龮雦设苣膀觧ꮁ胣뢂苣ꆃ菣ꪃ菣ꢂ菣뢂菣鎼볯邼볯ꢁ胣隻臣龩菨隃菣莃苣膀迥뎁菣릂菣誏臣鮃苣袃菣ꆃ菣ꪃ룤ꞁ껥財臣貂苣ꊂ菣ꪃ苣벃苣ꞃ菣ꢁ臣ꊖ뿤銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯颼胣ₑ겜駧躘臣膀볯ꆬ藥螃苣閃苣벃菣뮃苣Ꞃ菣螃苣뎃苣뮃苣ꦃ菣ꎂ苣릂菣醃苣鞃菣ꒂ菣袼볯뎼볯낼볯꺁곧醼껥붖뻤銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼胣ₑ袅ꯧꢃ臣뎂菣뎃菣뮃菣Ꞃ菣膃迥뎁菣뎂菣覃菣隃菣莃苣袼볯ꚼ볯覼볯邼볯邼蛥꺁���膦ꧦ붃菣讃菣袃苣몤臣膀菣ꒂ菣ꦃ苣뎃臣芁苣龮雦设臣ꎻꇨ蒚臣隃菣莃苣骷鯥銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†볯뎼볯낼볯邼볯邼臣芁苣龮雦设苣骀苣螃菣뾂臣閃菣벃苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†菩蚈髧ꮁ髩閁苣龁룤銧뷥讁苣膀苣ꮃ菣궃菣꾂臣芦뷤ꮁ臣ꚁ菣ꦃ苣ꆃ菣袃苣龔裦馁苣讁臣设苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†菣꾂苣ꮃ菣隃菣莃苣貁볯릂苣뎃菣뢛뷥꺁菣ꦃ苣ꆃ菣袃苣芦뷤ꮁ蟥蚐臣讂臣銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥Ꞽ볯鎼胣ₑ螃苣閃苣벃菣뮃苣Ꞃ菣螃苣뎃苣뮃苣ꦃ菣ꎂ苣릂菣鞃菣뮂菣떂볯꒼볯Ꞽ볯覼臣芁苣龮雦设臣芠苧Ꞻ꣦銂ꓥ鮏臣讂臣꺁苣誂雦ꮁ蓧릂苣鎽臣龁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†菣ꎂ菣ꆂ菣覃菣랂苣벃菣ꎂ菣낂菣낂菣閃苣꾂苣뮃菣궃苣莃苣袼볯뎼볯낼볯꺁臣讂껥붖뻤貁胣閳럧膀귦ꖎ胣鎾돦骷苣覤迦馁苣鶁臣蒂苣릖臣Ꚅ苧銂뷥ꚁ臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥Ꞽ볯閼胣ₑ뢂苣ꆃ菣ꪃ菣隃菣莃苣袼볯ꖼ볯覼臣龩菨隃菣莃苣骷鯥銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†鳦몙飦꺁꟦ꂀ臣鎼菣莃菣龮雦设臣誁臣讂跥躰뷤膃菣鞃룤꺁ꧦ붃菣궃菣꾂雩꺁雩芿苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥Ꞽ볯鞼胣ₑꊃ菣覃諦몇菣궃菣꾂볯궼볯뢼볯꺁臣讂껥붖뻤ꮁ臣醁苣ꎻꇨ蒚菣벃苣閃菣벃臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥Ꞽ볯颼胣ₑꎻꇨ蒚菣벃菣붊蟥隃菣莃苣ꮁ胩覂苣讂菣놂菣袃苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥Ꞽ볯馼胣ₑꎻꇨ蒚菣벃菣붊蟥隃菣莃苣꺁볯膃菣鞃諧讅菣꾂菣ꮃ賥蚈臣芁苣龮雦设苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥Ꞽ볯邼胣ₑ薃ꃥ銂ꓥ銧뷥ꆃ菣ꪃ臣뮂菣隃臣讂臣膂臣鞃菣뮂苣꺁藦颧苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥Ꞽ볯醼胣ₑ뎼볯낼菣궃菣꾂臣낈鷧鞁胣ꢂ苣ꪃ苣릂菣袏臣ꊂ菣膃苣ꒂ菣ꊂ苣覃菣ꊃ菣覃臣것菣肃菣ꞁ臣讂볯뎼볯낼룤銧뷥銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀†볯뎼볯낼臣ꦃ苣뎃苣膀苣꾃菣覃迥뎁꟦薀臣릖뷤꺁苣ꒂ菣ꊂ苣覃迥뎁苣뎃菣ꢂ苣ꪃ苣릂菣뮃菣ꒂ菣꺁迦뮔臣龁苣ꮁ铧邈臣貂臣꾂菣莃菣ꮁꓥ鮏臣讂臣ꢁ臣袂臣ꚁ菣뎃菣벃臣讂臣꺁苣誂雦銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀†菣벃苣벃賦骮苧貁苣ꪂ菣袃菣ꚃ菣莃菣薆臣것菣肃菣閁苣龁苧ꮁ苣뢂菣릂菣閁苣讂臣꺁苣誂雦銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀†苣뎃菣Ꞃ苣ꪃ苣릂菣뮃菣ꒂ菣뮃苣낂菣뎃菣貁胣뎹ꇨ鮛뻨ꊽ迥뎁룤銧뷥銂룤颧臣ꦃ苣뾂���ꒂ苣馁苣ꎼ볯겼菣讃菣袃菣릂苣ꎃ菣뮃苣뎃菣벃苣薆臣膀闩릖뷥ꮁꓥ鮏臣貂苣鶁臣蒂苣릖苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥Ꞽ볯閼胣ₑꢂ苣ꪃ苣릂菣뮃菣ꒂ菣꺁ꯧ릂臣膀맥財鯥몾뷥銂뷤ꎁ臣膀苣뎃菣ꢂ苣ꪃ苣릂菣뮃菣ꒂ菣꺁ꃥ袐臣랕雦ꊽ臣钯볨鞁臣袨껧閁苣讂臣꺁苣誂雦銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀†苣莃菣ꊂ菣鞃臣膀ꃩ릂觥誂뷥ꚁ苣ꮐ苣膀菣ꒂ菣誏臣覸꟨ꊽ苣芦뷤ꮁꇨ馁臣꺁藦颧苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥Ꞽ볯鞼胣ₑ뮂菣袃苣莃菣貁胣뺋藩늉苣鎽臣銂郥膂胣ꦃ苣뎃迥뎁룤銧뷥銂ꛥ閽臣ꢡ臣讁臣讅꟦銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼볯醀†苣莃菣ꊂ菣鞃臣膀菣ꒂ菣꺁雦趽臣몟臣辁뇨邙觥誂뷥ꚁ苣ꮐ苣膀菣ꒂ菣誏臣覸꟨ꊽ苣芦뷤ꮁꇨ馁臣꺁藦颧苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥Ꞽ볯馼胣ₑ뮂菣袃苣莃菣貁胣꾂菣莃菣風뿨邭臣붑郥誏臣꾂菣莃菣뮃苣벃菣꺁郥芠苧뢁臣늉苣鎽臣銂郥膂胣ꦃ苣뎃迥뎁룤銧뷥銂ꛥ閽臣ꢡ臣讁苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥Ꞽ볯邼胣ₑ뮂菣袃苣莃菣貁觧骮臣ꒀ苣ꎼ볯겼臣芦뷤ꮁ胩讂臣꺁藦颧苣ꮐ苣膀苣莃菣ꊂ菣鞃臣ꦃ苣뎃迥뎁룤銧뷥銂ꛥ閽臣ꢡ臣讁臣讅꟦銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀†苣ꎃ菣랂菣뮃苣낂菣ꮃ菣꾂苣莃菣ꢔ臣뎂菣蚃菣蒃菣ꊂ菣것苣隃菣뮃菣ꊃ菣袼볯ꆼ볯覼臣貮藥ꮁ뗧袐臣鎁苣銂뷤蚁胣뾂苣뮃苣ꎃ菣랂菣꺁믤ꢡ髧龮雦设臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥Ꞽ볯銼胣ₑ趽뷯薽菣벃苣貁뗦貂胣꒼볯Ꞽ볯醃苣鞃菣ꒂ菣꺁菩蚈臣궂菣莃苣ꖃ臣貂苣鶁臣蒂苣릖苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥Ꞽ볯鎼胣ₑ閃菣낂菣뎃菣뮃菣궃菣꾂臣ꎻꇨ蒚껥붖뻤꺁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀†꟦薀臣鞃菣龃菣ꎂ菣ꞁ뷥邈臣貂臣钃苣뮂菣뮃菣ꦃ苣ꆃ菣袃苣馂臣龁볯뎼볯꺁뻤銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀†룤銧뷥ꢔ臣ꂁ뿨꺿귦놅胩趇뿥鲣雩銂뷤ꎁ臣閃菣낂菣뎃菣뮃菣궃菣꾂ꏨ鎖臣讅꟦銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀†ꓥ趁臣꺁闧ꪁ苣馃苣袃菣鎖臣鲣雩貁ꛥ閽臣趸鷥肸臣銧뫥내裥Ꞁ苣龔臣膀鳦몙飦꺁꟦ꂀ迥뎁雦閳臣閽闦鎁臣蒂苣릖臣閳럧誏臣ꎭ軦銂ꏨ鎖臣ꪁ臣讁臣设苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀†菣ꦃ苣ꆃ菣袃菣隃菣莃苣薆臣鲣雩芿闦銂뷥邈臣讂臣膂臣뾽铧閁苣讂菣ꦃ苣ꆃ菣袃臣颽迥뎁뷯Ꞻ꣦貁ꛥ閽臣ꊽ裦閁苣讂臣銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼볯醀†菣꾂苣膃菣���뮃苣것苣뮃苣覃菣莃苣뎃苣꺁ꛦ膦苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥Ꞽ볯馼胣ₑ閃苣뎃苣ꚃ菣莃菣꺁菣ꒂ菣ꦃ苣뎃蛥꺁뷤꺽迥뎁髩ꖎ臣讂菣궃菣꾂臣꺁雩芿苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥Ꞽ볯邼胣ₑ閃菣낂菣뎃菣醼볯邼볯邼胣蚃苣릂菣ꎃ볯銼볯邼볯讁苣閃苣뎃苣醼볯邼볯邼臣膀臣鞁臣閃苣뎃苣讁苣钃苣뮂菣醼볯邼볯邼臣꺁菦놠菣놂菣袃臣閃菣벃苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥Ꞽ볯醼胣ₑ뺹臣讁臣떂菣ꚃ菣莃菣讁苣ꪁ苣閃苣뎃苣꺁菣궃菣꾂럧뎛苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥Ꞽ볯銼胣ₑ뎛볯钼볯꺁菣꾂苣膃菣袨껧隃菣莃苣醼볯醼볯钼臣袂苣龮ꇨ閁苣讂菣궃苣莃苣뎃苣꺁ꧦ붃菣궃菣骷鯥銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀†菣ꦂ菣낂菣궃菣꾂볯钼볯邼볯ꞁ껥財臣貂苣袨껧銂볥뾪臣讂胣邃菣鞃迥뎁菣ꒂ菣ꎂ菣낂諥鲞臣袨껧ꢁ꿥ꖎ臣ꊖ苣讂鳦몙飦꺁볯뎼볯낼臣ꢃ裥銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀†鯥Ꞽ볯鎼臣邃菣鞃菣ꚃ菣莃菣醼볯醼볯邼臣芁苣龮雦设臣袂苣龮ꇨ閁苣讂菣뎃菣袨껧꺁ꧦ붃髧閃菣벃苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥Ꞽ볯閼胣ₑ몛껥辰闦릂볦鞮苣뾽臣ꚁ껥財臣趁苣邃菣鞃菣ꚃ菣莃菣醼볯醼볯邼臣芁苣龮雦设蛥ꞁ胣芑该閁苣龁鷩閳럧銂꣨鞮臣讂臣ꮁ뷤辂苣讂雦閳臣龩菨蒚菣궃菣銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀†볯ꦼ볯隃菣莃苣꺁菣궃菣꾂럧뎛苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥Ꞽ볯鞼胣ₑꊼ뷯莽뷯ꖼ뷯蒽菣궃菣꾂볯ꊼ볯ꖼ볯誏臣鶁苣ꮁ苣뎃苣閃苣벃苣馁苣ꚃ菣莃菣銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯钼볯醀†볯ꮼ볯銂胩鞁臣ꆃ菣ꪃ臣궪臣随苣뢛臣벾臣銂ꇨ蚁ꓥꢃꇩꊮ菣讃菣袃苣몤臣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꢼ볯醀†꟦薀臣Ꞻ꣦뢻臣誁臣讂胣鎼곦莅苣隃苣Ꞃ苣袃胣钼鷩鎽苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯銼胣ₑ뢂苣ꆃ菣ꪃ菣隃菣莃苣薆臣讧裦膦듧ꢁ菣벃苣뮃菣궃菣銂ꓧ馁럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯鎼胣ₑ겜駧躘苣颊苣벾苣龁볯꒼苣ꦃ菣ꎂ苣릂菣醃苣鞃菣ꒂ菣薆臣讧裦膦듧ꢁ菣벃苣뮃菣궃菣銂ꓧ馁菣ꒂ菣馃菣뮃菣궃菣꾂럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯钼胣ₑ覤迦ꚃ菣莃菣꺁菣궃菣꾂럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯閼胣ₑ낂菣벃菣ꮃ菣醃苣莃菣뮃苣뎃菣궃菣ꦃ臣隃菣莃苣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꢼ볯醀†菣ꎂ苣ꪃ菣낂믤꺁럧낧髧鎼볯낂菣閃苣꾂苣뮃菣ꒂ菣ꦃ苣뎃苣螤ꏨ鞁臣节臣ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꢼ볯醀†볯꒼苣ꦃ菣���苣릂菣醃苣鞃菣ꒂ菣꺁ꗥꦁ臣ꒂ菣鞃菣ꆃ菣蚃菣랂菣뎃臣릖돦銈菣궃菣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꢼ볯醀†볯ꆬ藥낂菣閃苣꾂苣뮃苣ꆃ菣뢂苣것菣肃菣뎃苣馁苣龁苣꺁苣릂菣ꂃ苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼胣ₑꮂ菣隃菣莃苣貁胣ꢃ裥蒚臣ꂚ臣貂臣覸꟨ꊽ臣覂ꛥ閽臣鞁臣閃菣낂菣뎃菣銂铧邈臣讂臣꺁뻤銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥ꢼ볯邼胣ₑ钃苣뮂菣뮃菣궃菣꾂臣醼苣뾂菣鞃鯧鎽臣閃菣낂菣뎃菣銂ꛥ閽臣ꚇ郧馁苣讁苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†菣벃苣醃苣뮃苣것菣뎃菣銂ꓧ馁菣ꒂ菣ꦃ苣뎃菣릂菣벃苣꺁菣궃菣꾂럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†釥꒻苣뎃菣궃菣ꦃ苣몤臣醃苣鞃菣ꒂ菣뮃苣蚃菣뢂臣隃菣莃苣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꢼ볯鎼胣ₑ꾂菣莃菣뎃苣뮃苣隃菣讃菣袃臣隃菣莃苣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꢼ볯钼胣ₑ蚃苣릂菣ꎃ諧讅菣랂菣꺁菣궃菣꾂럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†郥龜苣ꖃ菣誏臣꾂菣莃菣뎃苣뮃苣隃菣讃菣袃臣隃菣莃苣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꢼ볯隼胣ₑ醃苣鞃菣ꒂ菣릂菣벃苣ꊼ볯銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥ꢼ볯鞼胣ₑ醃苣鞃菣ꒂ菣릂菣벃苣ꊼ볯ꮁ꿥馁苣붑믤뎂菣袃菣벃菣꺁菣궃菣꾂럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼胣ₑ颧胣ꪁ뫥馨믨ꮁ臣醁苣膀볯ꆬ藥ꪂ菣뢂苣꾂菣膀볯ꊝ뷤銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥ꪼ볯醀†菣꾂苣ꮃ菣隃菣莃苣薆臣讧裦膦듧ꢁ菣벃苣閃菣벃苣몤臣隃菣莃苣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꪼ볯醀†鳦몙飦銂諦誂뻨鎂臣鎼볯낂菣閃苣꾂苣뮃菣ꒂ菣ꦃ苣뎃蛥꺁꟦邈ꛨꂴ臣螃菣뾂菣閃菣벃苣몤臣较苣것菣ꮃ菣궃菣꾂럧뎛臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯钼胣ₑ겜駧躘臣芁苣龮雦设臣袂苣膀苣뎃菣ꮃ臣钃苣뮂菣誏臣릂苣뎃菣ꮁ꿥馁苣ꊖ뿤膀룤뎁臣螃菣ꦂ菣袃菣떂菣鞃菣꺁苣ꪃ菣覃胣ꮂ苣뎃菣誏臣趽뷧銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥ꪼ볯醀†菣꾂苣ꮃ苣Ꚃ菣뮃菣讃菣袃臣隃菣莃苣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꪼ볯醀†菣ꎂ苣ꪃ菣낂믤꺁럧낧髧鎼볯낂菣閃苣꾂苣뮃菣ꒂ菣ꦃ苣뎃苣螤ꏨ鞁臣节臣ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꪼ볯醀†鯥ꪼ볯꺁菣ꒂ菣ꦃ苣뎃臣릖돦銈菣궃菣骷鯥ꞁ臣讂胣㲂䐯噉ਾ䐼噉邀鯥ꪼ볯醀†볯ꆬ藥낂菣閃苣꾂苣뮃苣ꆃ菣뢂苣것菣肃菣뎃苣馁苣龁苣꺁苣릂菣ꂃ苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯馼胣ₑꮂ菣隃菣莃苣貁胣ꢃ裥蒚臣ꂚ臣貂臣覸꟨ꊽ臣覂ꛥ閽臣鞁臣閃菣낂菣뎃菣銂铧邈臣讂臣꺁뻤銂ꓧ馁胣㲂䐯噉ਾ䐼噉邀鯥ꪼ볯邼胣ₑ钃苣뮂菣뮃菣궃菣꾂臣醼苣뾂���鞃鯧鎽臣閃菣낂菣뎃菣銂ꛥ閽臣ꚇ郧馁苣讁苣몤臣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†鳦몙飦銂諦誂뻨鎂臣鎼볯낂菣閃苣꾂苣뮃菣ꒂ菣ꦃ苣뎃臣ꖈ臣龮雦设臣芁苣芀⼼䥄㹖㰊䥄㹖胣뎛볯醼볯醀†鳦몙飦銂諦誂뻨鎂臣鎼볯낂菣閃苣꾂苣뮃菣ꒂ菣ꦃ苣뎃臣ꖈ臣龮雦设臣芁苣芀⼼䥄㹖㰊䐯噉ਾ䐼噉㰾䥄㹖胣뎛볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㈲㰵愯㰾䐯噉ਾ††††䐼噉邀鯥銼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㘲⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㈲㰷愯㰾䐯噉ਾ††††䐼噉邀鯥钼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㠲⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㈲㰹愯㰾䐯噉ਾ††††䐼噉邀鯥隼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰〳⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㌲㰱愯㰾䐯噉ਾ††††䐼噉邀鯥颼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㈳⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㌲㰳愯㰾䐯噉ਾ††††䐼噉邀鯥醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㌲㰴愯㰾䐯噉ਾ††††䐼噉邀鯥醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㌲㰵愯㰾䐯噉ਾ††††䐼噉邀鯥醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㌲㰶愯㰾䐯噉ਾ††††䐼噉邀鯥醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㌲㰷愯㰾䐯噉ਾ††††䐼噉邀鯥醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㌲㰸愯㰾䐯噉ਾ††††䐼噉邀鯥醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㌲㰹愯㰾䐯噉ਾ††††䐼噉邀鯥醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㐲㰰愯㰾䐯噉ਾ††††䐼噉邀鯥醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㐲㰱愯㰾䐯噉ਾ††††䐼噉邀鯥醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㐲㰲愯㰾䐯噉ਾ††††䐼噉邀鯥醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㐲㰳愯㰾䐯噉ਾ††††䐼噉邀鯥銼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㐲㰴愯㰾䐯噉ਾ††††䐼噉邀鯥銼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㐲㰵愯㰾䐯噉ਾ††††䐼噉邀鯥銼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰���㰶愯㰾䐯噉ਾ††††䐼噉邀鯥銼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㐲㰷愯㰾䐯噉ਾ††††䐼噉邀鯥銼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㐲㰸愯㰾䐯噉ਾ††††䐼噉邀鯥銼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㐲㰹愯㰾䐯噉ਾ††††䐼噉邀鯥銼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㔲㰰愯㰾䐯噉ਾ††††䐼噉邀鯥銼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㔲㰱愯㰾䐯噉ਾ††††䐼噉邀鯥銼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㔲㰲愯㰾䐯噉ਾ††††䐼噉邀鯥銼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㔲㰳愯㰾䐯噉ਾ††††䐼噉邀鯥鎼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㔲㰴愯㰾䐯噉ਾ††††䐼噉邀鯥鎼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㔲㰵愯㰾䐯噉ਾ††††䐼噉邀鯥鎼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㔲㰶愯㰾䐯噉ਾ††††䐼噉邀鯥鎼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㔲㰷愯㰾䐯噉ਾ††††䐼噉邀鯥鎼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㔲㰸愯㰾䐯噉ਾ††††䐼噉邀鯥鎼볯ꆼ胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㤵⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯閼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㘲㰰愯㰾䐯噉ਾ††††䐼噉邀鯥鎼볯ꆼ胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰ㄶ⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯隼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㘲㰲愯㰾䐯噉ਾ††††䐼噉邀鯥鎼볯ꎼ胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㌶⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯鞼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㐶⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯颼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㘲㰵愯㰾䐯噉ਾ††††䐼噉邀鯥鎼볯ꊼ胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㘶⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯馼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㜶⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯邼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㠶⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㤶⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯銼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰〷⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯鎼胣㲑䐯噉ਾ††††††䐼噉㰾⁡���晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰ㄷ⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯钼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㈷⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯閼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㌷⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯隼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㐷⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯鞼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㔷⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯颼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㘷⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯馼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㜷⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯邼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㠷⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㤷⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯銼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰〸⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯鎼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰ㄸ⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯钼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㈸⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯閼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㌸⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯隼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㐸⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯鞼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㔸⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯颼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㘸⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯馼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㜸⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯邼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㠸⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㤸⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯銼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰〹⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯鎼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰ㄹ⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯钼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㈹⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯閼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㌹⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯隼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㐹⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯鞼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㔹⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼胣㲑䐯噉ਾ���†††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㘹⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯銼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㜹⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯鎼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㠹⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯钼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㈰㤹⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰〰⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯銼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㄰⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯鎼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㈰⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯钼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㌰⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯閼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㐰⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯閼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰〳㰵愯㰾䐯噉ਾ††††䐼噉邀鯥ꊼ볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰〳㰶愯㰾䐯噉ਾ††††䐼噉邀鯥ꊼ볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰〳㰷愯㰾䐯噉ਾ††††䐼噉邀鯥ꊼ볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰〳㰸愯㰾䐯噉ਾ††††䐼噉邀鯥ꊼ볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰〳㰹愯㰾䐯噉ਾ††††䐼噉邀鯥ꊼ볯邼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰〱⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰ㄳ㰱愯㰾䐯噉ਾ††††䐼噉邀鯥ꊼ볯銼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㈱⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯ꆼ胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㌱⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯ꊼ胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㐱⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰ㄳ㰵愯㰾䐯噉ਾ††††䐼噉邀鯥ꊼ볯閼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㘱⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰ㄳ㰷愯㰾䐯噉ਾ††††䐼噉邀鯥ꊼ볯鞼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㠱⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰ㄳ㰹愯㰾䐯噉ਾ††††䐼噉邀鯥ꊼ볯馼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲���㠲琮晩ꃂ〰㌰〲⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰ㄲ⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯銼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㈲⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯鎼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㌲⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯钼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㐲⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯閼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㔲⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯鞼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㘲⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯颼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㜲⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯馼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㠲⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㈳㰹愯㰾䐯噉ਾ††††䐼噉邀鯥ꎼ볯銼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰〳⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㌳㰱愯㰾䐯噉ਾ††††䐼噉邀鯥ꎼ볯钼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㈳⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㌳㰳愯㰾䐯噉ਾ††††䐼噉邀鯥ꎼ볯隼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㐳⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㌳㰵愯㰾䐯噉ਾ††††䐼噉邀鯥ꎼ볯颼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㘳⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㜳⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯銼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㠳⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯鎼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㤳⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯钼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰〴⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯閼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰ㄴ⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯隼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㈴⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯鞼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㌴⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯颼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㐴⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯馼胣㲑䐯噉ਾ††���†††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㔴⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㐳㰶愯㰾䐯噉ਾ††††䐼噉邀鯥꒼볯醼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㜴⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㐳㰸愯㰾䐯噉ਾ††††䐼噉邀鯥꒼볯鎼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㤴⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㔳㰰愯㰾䐯噉ਾ††††䐼噉邀鯥꒼볯閼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰ㄵ⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㔳㰲愯㰾䐯噉ਾ††††䐼噉邀鯥꒼볯鞼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㌵⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㔳㰴愯㰾䐯噉ਾ††††䐼噉邀鯥꒼볯馼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㔵⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯銼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㔳㰶愯㰾䐯噉ਾ††††䐼噉邀鯥꒼볯醼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㜵⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯銼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㔳㰸愯㰾䐯噉ਾ††††䐼噉邀鯥꒼볯鎼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㤵⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰〶⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯銼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰ㄶ⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯鎼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㈶⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯钼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㌶⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯閼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㐶⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯隼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㔶⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯鞼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㘶⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯颼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㜶⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯馼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㠶⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷���⸸楴쉦゠〰㘳㰹愯㰾䐯噉ਾ††††䐼噉邀鯥ꖼ볯醼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰〷⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㜳㰱愯㰾䐯噉ਾ††††䐼噉邀鯥ꖼ볯鎼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㜳㰲愯㰾䐯噉ਾ††††䐼噉邀鯥ꖼ볯鎼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㜳㰳愯㰾䐯噉ਾ††††䐼噉邀鯥ꖼ볯鎼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㜳㰴愯㰾䐯噉ਾ††††䐼噉邀鯥ꖼ볯钼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㔷⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㜳㰶愯㰾䐯噉ਾ††††䐼噉邀鯥ꖼ볯隼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㜷⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯ꆼ胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㠷⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯ꊼ胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㤷⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯ꎼ胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰〸⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㠳㰱愯㰾䐯噉ਾ††††䐼噉邀鯥ꖼ볯馼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㈸⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯銼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㠳㰳愯㰾䐯噉ਾ††††䐼噉邀鯥ꖼ볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㠳㰴愯㰾䐯噉ਾ††††䐼噉邀鯥ꖼ볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㠳㰵愯㰾䐯噉ਾ††††䐼噉邀鯥ꖼ볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㠳㰶愯㰾䐯噉ਾ††††䐼噉邀鯥ꖼ볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㠳㰷愯㰾䐯噉ਾ††††䐼噉邀鯥ꖼ볯銼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㠸⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯銼볯ꆼ胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㤸⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯銼볯ꊼ胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰〹⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯銼볯ꎼ胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰ㄹ⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯銼볯꒼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㈹⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯銼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦���〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㤳㰳愯㰾䐯噉ਾ††††䐼噉邀鯥ꖼ볯閼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㐹⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯銼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㤳㰵愯㰾䐯噉ਾ††††䐼噉邀鯥ꖼ볯鞼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㘹⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯銼볯ꆼ胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㜹⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯銼볯ꊼ胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㌰㠹⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯銼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㤳㰹愯㰾䐯噉ਾ††††䐼噉邀鯥ꚼ볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰〴㰰愯㰾䐯噉ਾ††††䐼噉邀鯥ꚼ볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰〴㰱愯㰾䐯噉ਾ††††䐼噉邀鯥ꚼ볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰〴㰲愯㰾䐯噉ਾ††††䐼噉邀鯥ꚼ볯ꆼ胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㌰⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯钼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰〴㰴愯㰾䐯噉ਾ††††䐼噉邀鯥ꚼ볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰〴㰵愯㰾䐯噉ਾ††††䐼噉邀鯥ꚼ볯ꆼ胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㘰⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯隼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰〴㰷愯㰾䐯噉ਾ††††䐼噉邀鯥ꚼ볯ꎼ胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㠰⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯鞼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㤰⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯颼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰〱⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯馼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰ㄱ⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰ㄴ㰲愯㰾䐯噉ਾ††††䐼噉邀鯥ꚼ볯醼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㌱⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰ㄴ㰴愯㰾䐯噉ਾ††††䐼噉邀鯥ꚼ볯鎼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰ㄴ㰵愯㰾䐯噉ਾ††††䐼噉邀鯥ꚼ볯鎼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰ㄴ㰶愯㰾䐯噉ਾ††††䐼噉邀鯥Ꞽ볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴���゠〰ㄴ㰷愯㰾䐯噉ਾ††††䐼噉邀鯥Ꞽ볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰ㄴ㰸愯㰾䐯噉ਾ††††䐼噉邀鯥Ꞽ볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰ㄴ㰹愯㰾䐯噉ਾ††††䐼噉邀鯥Ꞽ볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㈴㰰愯㰾䐯噉ਾ††††䐼噉邀鯥Ꞽ볯ꆼ胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰ㄲ⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯閼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㈴㰲愯㰾䐯噉ਾ††††䐼噉邀鯥Ꞽ볯ꆼ胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㌲⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯隼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㈴㰴愯㰾䐯噉ਾ††††䐼噉邀鯥Ꞽ볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㈴㰵愯㰾䐯噉ਾ††††䐼噉邀鯥Ꞽ볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㈴㰶愯㰾䐯噉ਾ††††䐼噉邀鯥Ꞽ볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㈴㰷愯㰾䐯噉ਾ††††䐼噉邀鯥Ꞽ볯邼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㠲⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㈴㰹愯㰾䐯噉ਾ††††䐼噉邀鯥Ꞽ볯銼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰〳⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㌴㰱愯㰾䐯噉ਾ††††䐼噉邀鯥Ꞽ볯钼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㈳⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㌴㰳愯㰾䐯噉ਾ††††䐼噉邀鯥Ꞽ볯隼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㐳⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㌴㰵愯㰾䐯噉ਾ††††䐼噉邀鯥Ꞽ볯颼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㘳⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㌴㰷愯㰾䐯噉ਾ††††䐼噉邀鯥Ꞽ볯邼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㠳⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯銼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㌴㰹愯㰾䐯噉ਾ††††䐼噉邀鯥Ꞽ볯銼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰〴⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯銼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㐴㰱愯㰾䐯噉ਾ††††䐼噉邀���Ꞽ볯钼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㈴⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯銼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㐴㰳愯㰾䐯噉ਾ††††䐼噉邀鯥Ꞽ볯隼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㐴⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯銼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㐴㰵愯㰾䐯噉ਾ††††䐼噉邀鯥Ꞽ볯颼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㘴⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯銼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㐴㰷愯㰾䐯噉ਾ††††䐼噉邀鯥Ꞽ볯邼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㠴⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯鎼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㐴㰹愯㰾䐯噉ਾ††††䐼噉邀鯥Ꞽ볯銼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰〵⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯鎼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㔴㰱愯㰾䐯噉ਾ††††䐼噉邀鯥Ꞽ볯钼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㈵⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯鎼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㔴㰳愯㰾䐯噉ਾ††††䐼噉邀鯥Ꞽ볯隼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㐵⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯鎼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㔴㰵愯㰾䐯噉ਾ††††䐼噉邀鯥Ꞽ볯颼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㘵⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯鎼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㔴㰷愯㰾䐯噉ਾ††††䐼噉邀鯥Ꞽ볯邼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㠵⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯钼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㔴㰹愯㰾䐯噉ਾ††††䐼噉邀鯥Ꞽ볯銼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰〶⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯钼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㘴㰱愯㰾䐯噉ਾ††††䐼噉邀鯥Ꞽ볯钼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㈶⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯钼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㘴㰳愯㰾䐯噉ਾ††††䐼噉邀鯥Ꞽ볯隼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㐶⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯钼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㘴㰵愯㰾䐯噉ਾ††††䐼噉邀鯥Ꞽ볯颼胣㲑䐯���ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㘶⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㜶⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯銼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㠶⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯鎼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㤶⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯钼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰〷⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯閼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰ㄷ⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯隼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㈷⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯鞼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㌷⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯颼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㐷⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯馼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㔷⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㜴㰶愯㰾䐯噉ਾ††††䐼噉邀鯥ꢼ볯醼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㜷⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㜴㰸愯㰾䐯噉ਾ††††䐼噉邀鯥ꢼ볯鎼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㤷⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㠴㰰愯㰾䐯噉ਾ††††䐼噉邀鯥ꢼ볯閼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰ㄸ⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㠴㰲愯㰾䐯噉ਾ††††䐼噉邀鯥ꢼ볯鞼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㌸⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㐸⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯銼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㔸⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯鎼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㘸⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯钼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㜸⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯閼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㠸⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯隼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㤸⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯鞼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰���⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯颼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰ㄹ⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯馼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㈹⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㤴㰳愯㰾䐯噉ਾ††††䐼噉邀鯥ꪼ볯醼胣㲑䐯噉ਾ††††††䐼噉㰾⁡牨晥∽〲㐰㜲㤲㠲琮晩㸢〲㐰㜲㤲㠲琮晩ꃂ〰㐰㐹⼼㹡⼼䥄㹖 †††㰠䥄㹖胣뎛볯醼볯醀⼼䥄㹖 †††††㰠䥄㹖愼栠敲㵦㈢〰㈴㈷㈹⸸楴≦㈾〰㈴㈷㈹⸸楴쉦゠〰㤴㰵愯㰾䐯噉ਾ††††⼼䥄㹖㰊戯摯㹹㰊栯浴㹬