JP2004348169A - グラフィック・システムにおけるサンプル密度および／またはいくつかのレンダリング・パスの動的な調整 - Google Patents
グラフィック・システムにおけるサンプル密度および／またはいくつかのレンダリング・パスの動的な調整 Download PDFInfo
- Publication number
- JP2004348169A JP2004348169A JP2003066615A JP2003066615A JP2004348169A JP 2004348169 A JP2004348169 A JP 2004348169A JP 2003066615 A JP2003066615 A JP 2003066615A JP 2003066615 A JP2003066615 A JP 2003066615A JP 2004348169 A JP2004348169 A JP 2004348169A
- Authority
- JP
- Japan
- Prior art keywords
- sample
- buffer
- graphics system
- frame buffer
- samples
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T15/00—3D [Three Dimensional] image rendering
- G06T15/005—General purpose rendering architectures
Landscapes
- Engineering & Computer Science (AREA)
- Computer Graphics (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Image Generation (AREA)
- Controls And Circuits For Display Device (AREA)
- Image Input (AREA)
- Testing, Inspecting, Measuring Of Stereoscopic Televisions And Televisions (AREA)
Abstract
【課題】ウィンドウイング環境でより効果的に動作できるグラフィカル・コンピューティング・システムと対応する方法を提供すること。
【解決手段】本システムは、ハードウェア・アクセラレータ（ＨＡ）とフレーム・バッファ（ＦＢ）を含む。ＦＢは、サンプル記憶域とダブル・バッファされた表示領域を含む。ＨＡは、（ａ）プリミティブのストリームをサンプルにレンダリングし、（ｂ）サンプルをサンプル記憶域に格納し、（ｃ）ピクセルを生成するためにプログラム可能サンプル密度に基づいてサンプル記憶域からサンプルを読み取ってフィルタリングし、（ｄ）表示領域の第１のバッファにピクセルを格納する。ハードウェア・アクセラレータは、第１のバッファの制御を出力プロセスに渡す前にアニメーションのフレームをレンダリングするために、１つまたは複数の対応するプリミティブのストリーム上で（ａ）、（ｂ）、（ｃ）、（ｄ）を１回または複数回実行する。さらに、ホスト・コンピュータは、ウィンドウ・サイズの変化に応答してＨＡの達成可能最大サンプル密度ＤＭＡＸを算出し、それに応じてＨＡを更新する。
【選択図】 図１Ａ
【解決手段】本システムは、ハードウェア・アクセラレータ（ＨＡ）とフレーム・バッファ（ＦＢ）を含む。ＦＢは、サンプル記憶域とダブル・バッファされた表示領域を含む。ＨＡは、（ａ）プリミティブのストリームをサンプルにレンダリングし、（ｂ）サンプルをサンプル記憶域に格納し、（ｃ）ピクセルを生成するためにプログラム可能サンプル密度に基づいてサンプル記憶域からサンプルを読み取ってフィルタリングし、（ｄ）表示領域の第１のバッファにピクセルを格納する。ハードウェア・アクセラレータは、第１のバッファの制御を出力プロセスに渡す前にアニメーションのフレームをレンダリングするために、１つまたは複数の対応するプリミティブのストリーム上で（ａ）、（ｂ）、（ｃ）、（ｄ）を１回または複数回実行する。さらに、ホスト・コンピュータは、ウィンドウ・サイズの変化に応答してＨＡの達成可能最大サンプル密度ＤＭＡＸを算出し、それに応じてＨＡを更新する。
【選択図】 図１Ａ
Description
【０００１】
【発明の属する技術分野】
本発明は、一般にコンピュータ・グラフィックスの分野に関し、より詳細には、最適なスーパーサンプル密度を達成するためにサンプル記憶域を動的に再割当てするように構成された、かつ／またはターゲットとなるイメージ品質を達成するためにいくつかのレンダリング・パスを動的に調整するように構成された、グラフィカル・コンピューティング・システムに関する。
【０００２】
【従来の技術】
グラフィカル・コンピューティング・システムはスーパーサンプリングを実施することが可能であり、すなわちピクセル解像度よりも高いサンプルを生成することが可能であり、ピクセルを生成するためにサンプルをフィルタリングすることが可能である。最終的なイメージ品質は、サンプル密度（すなわち、単位ピクセル領域あたりで生成されるサンプル数）にある程度依存する。さらに、グラフィカル・コンピューティング・システムは、ユーザが画面上のウィンドウをサイズ変更できるウィンドウイング環境で動作するように構成可能である。ただし、多くのグラフィカル・コンピューティング・システムは、サンプル密度またはレンダリング・パスの数をウィンドウ・サイズの変化に応答して調整できる方法で構成されていない。
【０００３】
【発明が解決しようとする課題】
ウィンドウイング環境でより効果的に動作できるグラフィカル・コンピューティング・システムおよび対応する方法の必要性がある。具体的に言えば、ウィンドウ・サイズの変化に応答してサンプル密度および／またはレンダリング・パスの数を動的に調整できるグラフィカル・コンピューティング・システムおよび対応する制御方法の必要性である。
【０００４】
【課題を解決するための手段】
様々な実施態様では、グラフィックス・システムがフレーム・バッファおよびハードウェア・アクセラレータを含む。フレーム・バッファは、サンプル・バッファおよびダブル・バッファされた表示域を含むことができる。ハードウェア・アクセラレータを、フレーム・バッファに結合され、さらに（ａ）プリミティブを受け取り、（ｂ）動的に調整可能なサンプル密度値に基づいてプリミティブ用のサンプルを生成し、（ｃ）サンプルをサンプル・バッファに書き込み、（ｄ）サンプル・バッファからサンプルを読み出し、（ｅ）ピクセルを生成するためにサンプルをフィルタリングし、（ｆ）ピクセルをダブル・バッファされた表示域のバック・バッファに格納するように構成することができる。ホスト・コンピュータは、１つまたは複数のウィンドウ・サイズ・パラメータの変更を指定するユーザ入力に応答して、フレーム・バッファ内でサンプル・バッファを再割り振りするために、（たとえば、格納済みのプログラム命令を使用して）グラフィックス・システムのプログラム可能レジスタを動的に更新するように構成されている。
【０００５】
一実施態様では、グラフィックス・アクセラレータを制御するための方法を以下のようにすることができる。（グラフィックス・アクセラレータは、プログラム可能サンプル密度に基づいてフレーム・バッファの使用可能スペースにサンプルをレンダリングし、サンプル・バッファからフレーム・バッファのダブル・バッファされた表示域へのサンプルをフィルタリングするように構成される。）本方法には、
（ａ）ウィンドウの幅および高さを決める入力を受け取ること、
（ｂ）ウィンドウの幅およびサンプル密度推定値に基づいてウィンドウを水平にカバーするメモリ割振りページの第１の数を計算すること、
（ｃ）ウィンドウの高さおよびサンプル密度推定値に基づいてウィンドウを垂直にカバーするメモリ割振りページの第２の数を計算すること、
（ｄ）第１の数と第２の数を掛け合わせて、メモリ割振りページの第３の数を決定すること、
（ｅ）（ｂ）、（ｃ）、および（ｄ）を１回または複数回実行して、メモリ割振りページの第３の数がフレーム・バッファの使用可能スペースに納まる条件によって決まるサンプル密度推定値を最大化すること、
（ｆ）最大化されたサンプル密度推定値を使用して、グラフィックス・アクセラレータのサンプル密度を再プログラミングすることが含まれる。この方法により、ウィンドウ・サイズの減少（増加）に応答してサンプル密度を増加（減少）させることができる。したがって、ウィンドウ・サイズが小さくなるほどピクセルあたりのイメージ品質が向上する。
【０００６】
他の実施態様では、グラフィックス・システムがハードウェア・アクセラレータおよびフレーム・バッファを含むことができる。フレーム・バッファは、サンプル記憶域およびダブル・バッファされた表示ピクセル領域を含む。ハードウェア・アクセラレータは、（ａ）サンプルを生成するためにプリミティブのストリームをレンダリングし、（ｂ）サンプルをフレーム・バッファのサンプル記憶域に格納し、（ｃ）サンプル記憶域からサンプルを読み取り、（ｄ）ピクセルを生成するためにサンプルをフィルタリングし、（ｅ）フレーム・バッファの表示ピクセル領域の第１のバッファにピクセルを格納するように動作可能である。さらにハードウェア・アクセラレータは、第１のバッファの制御をビデオ出力プロセッサに渡す前にアニメーションのフレームを完了させるために、１つまたは複数の対応するプリミティブのストリームに（ａ）、（ｂ）、（ｃ）、（ｄ）、および（ｅ）を１回または複数回実行するように動作可能でもある。
【０００７】
他の実施態様では、グラフィックス・システムによって生成されるイメージの品質を維持するための方法を以下のようにすることができる。（グラフィックス・システムは、プログラム可能サンプル密度に基づいてフレーム・バッファの使用可能スペースにサンプルをレンダリングし、サンプル・バッファからフレーム・バッファのダブル・バッファされた表示域へのサンプルをフィルタリングするように構成することができる。）本方法には、
（ａ）新しいウィンドウ・サイズを決める入力の受取りに応答して、アニメーション・フレーム用のグラフィックス・システムのパスの第１の数に対応する実現可能なサンプル密度を計算すること、
（ｂ）ユーザ指定サンプル密度よりも大きいかまたはこれに等しい実現可能なサンプル密度に対応する第１の数の値を決定するために、（ａ）を１回または複数回実行すること、
（ｃ）この値に等しいグラフィックス・システムのパスの第１の数を設定するために、グラフィックス・システムの１つまたは複数のプログラム可能レジスタに書き込むことが含まれる。
【０００８】
こうした方法は、システム・バスまたはコンピュータ・ネットワークを介してグラフィックス・アクセラレータに結合されたホスト・コンピュータで実行することができる。
【０００９】
他の実施態様では、グラフィックス・システムによって生成されるイメージの品質を維持する方法であって、本方法は、
（ａ）調整済みウィンドウのウィンドウ幅および高さを決める入力を受け取ること、
（ｂ）グラフィックス・システムによって達成可能なサンプル密度のセットから、サンプル密度値を選択すること、
（ｄ）正の整数値Ｎを選択すること、
（ｃ）ウィンドウ幅を選択されたサンプル密度に対応するページ幅で割った第１の上限を計算すること、
（ｄ）ウィンドウ高さを整数値Ｎで割って第１の結果を決定すること、
（ｅ）第１の結果を選択されたサンプル密度に対応するページ高さで割って第２の上限を計算すること、
（ｆ）第１の上限と第２の上限を掛け合わせてパスあたりのページ推定値を決定すること、
（ｇ）パスあたりのページ推定値がフレーム・バッファの使用可能スペースよりも大きい場合は、整数値Ｎを増やして（ｃ）、（ｄ）、（ｅ）、および（ｆ）を繰り返すこと、
（ｈ）アニメーション・フレームのＮパス・レンダリング用のグラフィックス・システムに構成されるように、グラフィックス・システムの１つまたは複数のプログラム可能レジスタに書き込むことが含まれる。
【００１０】
以下の詳細な説明は、添付の図面と共に考察すると、本発明をより良く理解することができる。本発明は、様々な修正態様および代替形式による影響を受けやすいものであり、その特定の実施態様が例示的なものとして図面に示されており、本明細書で詳細に説明される。ただし、図面およびその詳細な説明は、本発明を開示された特定の形式に限定することを意図するものではなく、その逆に、添付の特許請求の範囲で定義された本発明の精神および範囲に当てはまるすべての修正態様、等価態様、および代替態様をカバーすることを意図するものであることを理解されたい。見出しは編成のためだけのものであり、説明または特許請求の範囲を限定または解釈するために使用することを意味するものではないことに留意されたい。さらに「できる、場合がある」という語は、本出願全体を通じて、強制的な意味（すなわち、しなければならない）ではなく、許容的な意味（すなわち、可能性がある、可能である）で使用されている。「含む」という語およびその派生語は、「含むが、それに限定されるものではない」ことを意味する。「接続される」という語は「直接的または間接的に接続される」ことを意味し、「結合される」という語は「直接的または間接的に結合される」ことを意味する。
【００１１】
【発明の実施の形態】
一実施形態では、図１Ａで提案されるように、グラフィックス・レンダリング・システムは、メディア・プロセッサ１４、ハードウェア・アクセラレータ（ＨＡ）１８、フレーム・バッファ２２、およびビデオ出力プロセッサ２４を含むことができる。グラフィックス・レンダリング・システムは、ホスト・インターフェース、共用メモリ１１（たとえばＤＲＤＲＡＭ）、テクスチャ・メモリ２０（たとえばＳＤＲＡＭデバイスのアレイ）、ブートＰＲＯＭ ３０、およびＲＧＢＤＡＣ ２６、およびビデオ・エンコーダ２８も含むことができる。
【００１２】
ＲＡＭは、ランダム・アクセス・メモリの頭字語である。
ＳＲＡＭは、スタティック・ランダム・アクセス・メモリの頭字語である。
ＤＲＡＭは、ダイナミック・ランダム・アクセス・メモリの頭字語である。
ＳＤＲＡＭは、同期式ダイナミック・ランダム・アクセス・メモリの頭字語である。
ＲＤＲＡＭは、Ｒａｍｂｕｓ ＤＲＡＭの頭字語である。
ＤＲＤＲＡＭは、ダイレクトＲａｍｂｕｓ ＤＲＡＭの頭字語である。
ＰＲＯＭは、プログラム可能読み取り専用メモリの頭字語である。
ＤＡＣは、デジタル・アナログ変換器の頭字語である。
ＲＧＢは、赤、緑、青の頭字語である。
【００１３】
メディア・プロセッサ１４は、多角形、線、および点などのプリミティブを定義するグラフィックス・データのストリームを外部システム（たとえばホストプロセッサ）から受け取り、このグラフィックス・データ・ストリームに対していくつかの処理動作を実行することができる。事前に処理されたグラフィックス・データをハードウェア・アクセラレータに転送することができる。ハードウェア・アクセラレータは、グラフィックス・プリミティブ用のサンプルを生成し、そのサンプルをフレーム・バッファ内で割り振られたサンプル・バッファに格納することができる。ハードウェア・アクセラレータは、サンプル・バッファからサンプルを読み取り、サンプルをフィルタリングしてピクセルを生成し、さらにフレーム・バッファ内で割り振られたダブル・バッファされた表示バッファにそのピクセルを格納する。ピクセルの単一フレームが、サンプル・レンダリング・プロセスおよびサンプル・フィルタリング・プロセスの複数のパスで構成されることに留意されたい。ビデオ出力プロセッサは、表示バッファからピクセルを読み取り、表示デバイスへの出力用にビデオ出力信号（またはデジタル・ビデオ・ストリーム）を生成することができる。
【００１４】
一実施形態では、グラフィックス・レンダリング・システムには、（フレーム・バッファ・メモリ内で割り振られた）サイズの限定されたサンプル・バッファを効率的に使用することを目標としたいくつかの機能がある。
【００１５】
１．０ システム・アーキテクチャ
図１Ａは、グラフィックス・レンダリング・システムの一実施形態に関する基板レベルの構成図である。
【００１６】
メディア・プロセッサ１４は、受け取ったグラフィックス・データに対して、変換および書き込み動作ならびに他の汎用処理動作を実行することができる。メディア・プロセッサは、グラフィックス・プリプロセッサ１５０およびＲＰＵメガヘルツで動作する２つの処理ユニット（ＰＵ）を含むことができる。図１Ｄは、メディア・プロセッサの一実施形態に関する構成図である。
【００１７】
メディア・プロセッサ１４は、複数のバス・インターフェースを使用することができる。一実施形態では、メディア・プロセッサは北インターフェース１１（たとえば拡張ＵＰＡ６４Ｓインターフェース）、ダイレクトＲＡＭＢＵＳインターフェース１５４、および南インターフェース１６０を含む。外部プロセッサ（たとえばホストプロセッサ）は、グラフィックス・レンダリング・システムを制御するために北インターフェースを使用することができる。ダイレクトＲＡＭＢＵＳインターフェースは、１つまたは複数のＤＲＡＭメモリをサポートすることができる。南インターフェースはＵＰＡ６４Ｓバスの拡張変形であってよく、メディア・プロセッサがハードウェア・アクセラレータを制御できるようにするものである。
【００１８】
一実施形態では、共用メモリ１６が２つまたはそれ以上のＤＲＤＲＡＭチップを含むことができる。共用メモリ１６は、プログラム命令（たとえばマイクロコード）および一時データを格納するために使用することができる。共用メモリは、グラフィックス・レンダリング・システムとホスト・システムとの間の通信用のバッファを格納するため、およびコンテキスト・スイッチング用のコンテキスト情報を格納するために使用することもできる。共用メモリは、表示リスト・メモリとして使用することもできる。
【００１９】
ハードウェア・アクセラレータ１８は、２Ｄおよび３Ｄラスタ化、２Ｄおよび３Ｄテクスチャ化、ピクセル転送、イメージング・オペレーション、ならびにフラグメント処理を実行することができる。図１Ｂは、ハードウェア・アクセラレータ１８の一実施形態に関する構成図である。図１Ｃは、ハードウェア・アクセラレータ１８の一実施形態のより詳細な構成図である。以下に、図１Ｃで使用される頭字語の凡例を示す。
ＶＰ＝頂点プロセッサ
ＰＳＵ＝プリセットアップ・ユニット
ＳＵ＝セットアップ・ユニット
ＥＷ＝エッジ・ウォーカ
ＳＷ＝スパン・ウォーカ
ＳＧ＝サンプル生成器
ＳＥ＝サンプル評価器
ＴＥ＝テクスチャ環境
ＦＰ＝フラグメント・パイプライン
ＦＢＡ＝フレーム・バッファ・アドレス・ユニット
ＦＢＩ＝フレーム・バッファ・インターフェース
ＦＢ＝フレーム・バッファ
ＴＡ＝テクスチャ・アドレス・ユニット
ＴＲＢ＝テクスチャ・バッファ読取りバッファ
ＴＦ＝テクスチャ・フィルタ
ＦＲＢ＝フレーム・バッファ読取りバッファ
ＳＦ＝サンプル・フィルタ
ＰＸＭ＝ピクセル転送マルチプレクサ
ＰＸ＝ピクセル転送ユニット
ＴＢＭ＝テクスチャ・バッファ・マルチプレクサ
ＴＢＩ＝テクスチャ・バッファ・インターフェース
【００２０】
ハードウェア・アクセラレータ１８は、複数のインターフェースを有することができる。たとえば一実施形態では、ハードウェア・アクセラレータは、
（ａ）ハードウェア・アクセラレータがメディア・プロセッサからコマンドおよび／またはデータを受け取るときに介する、第１のインターフェース１６１（たとえば拡張ＵＰＡ６４Ｓインターフェース）と、
（ｂ）ハードウェア・アクセラレータがデバイス・ブートＰＲＯＭをアドレス指定し、ビデオ出力プロセッサを制御するときに介する、第２のインターフェース１７６と、
（ｃ）ハードウェア・アクセラレータがテクスチャ・バッファ２０の読取りおよび書込みの際に介する、第３のインターフェース１８７（たとえばエイトウェイ・インターリーブ・テクセル・バス用）と、
（ｄ）ハードウェア・アクセラレータがフレーム・バッファ２２の読取りおよび書込みの際に介する、第４のインターフェース３００（たとえばフォーウェイ・インターリーブ・ピクセル・バス）とを含む、４つのインターフェースを有することができる。
【００２１】
テクスチャ・バッファ・メモリ２０は、ＳＤＲＡＭ（すなわち同期式ダイナミック・ランダム・アクセス・メモリ）のアレイを含むことができる。たとえば一実施形態では、テクスチャ・バッファは８つのＳＤＲＡＭを有する。テクスチャ・バッファは、テクスチャ・マップ、イメージ処理バッファ、およびアキュムレーション・バッファを格納するために使用することができる。ハードウェア・アクセラレータ１８は、ＮＴＭＡビット・セットのテクスチャ・バッファ・データをＳＤＲＡＭクロック速度で読み取るかまたは書き込むことができる。たとえば、ＮＴＭＡは１２８ビットに等しくてよい。ただし、ＮＴＭＡの他の様々な値が可能であり、企図される。一実施形態では、２×２のテクスチャ・フットプリントの任意アドレス指定を可能にするために、ＳＤＲＡＭの各ペアが独立して行および列のアドレス指定が可能である。さらに、各ペア内で２つのＳＤＲＡＭが独立した列アドレスを受け取ることができる。
【００２２】
フレーム・バッファ２２は、ＤＲＡＭメモリ・デバイス（ＤＭＤ）のアレイを含むことができる。アレイは、ＮＤＲＡＭのＤＲＡＭメモリ・デバイスを含むことができる。ＤＲＡＭメモリ・デバイスの第１のサブセットはハードウェア・アクセラレータによってアクセス可能であり、ＤＲＡＭメモリ・デバイスの第２のサブセットは、ハードウェア・アクセラレータとビデオ出力プロセッサ２４の両方によってアクセス可能である。たとえば一実施形態では、ＮＤＲＡＭは１６に等しくてよく、各サブセットは８つのＤＲＡＭメモリ・デバイスを含むことができる。さらに１６のＤＲＡＭメモリ・デバイスを、図１Ａで提案されるように、４つのランクに編成することができる。
【００２３】
ハードウェア・アクセラレータ１８は、フレーム・バッファ・インターフェース３００を含むことができる。フレーム・バッファ・インターフェースは、ＤＲＡＭメモリ・デバイスから入出力するデータの流れを制御する、アドレス信号および制御信号をアサートする。フレーム・バッファ・インターフェースを、ビデオ出力プロセッサ２４によってアサートされたフレーム・バッファ・データ（すなわちフレーム・バッファに格納されたデータ）に対する要求を処理するように構成することができる。
【００２４】
フレーム・バッファ２２の記憶容量ＣＦＢは、任意の様々な値を取ることができる。一実施形態では、フレーム・バッファは７２メガバイトを格納することができる。フレーム・バッファは最高５２０万のデータ・アイテムの容量を持つことができる。データ・アイテムはピクセルまたはサンプルを表す。フレーム・バッファ内の記憶域の各ピクセルは、
６０ビットのカラー情報（すなわち３０ビットのダブル・バッファされたＲＧＢ）と、
８ビットのアルファと、
８ビットのオーバレイと、
１０ビットのウィンドウＩＤと、
２６ビットのｚ深さと、
４ビットのステンシルとを含む、１１６プレーンを有することができる。
【００２５】
一実施形態では、ハードウェア・アクセラレータ１８は、単一のフレーム・バッファ・クロックで４ピクセルまたは８サンプルまでを書き込むことが可能であり、２つのフレーム・バッファ・クロックの４つのピクセルまたはサンプルを読み取ることが可能である。
【００２６】
フレーム・バッファ２２のＤＲＡＭメモリ・デバイス（ＤＭＤ）は、シリアル出力ポートを有することができる。一実施形態では、８つのＤＲＡＭメモリ・デバイスの第１のサブセットは、ビデオ出力プロセッサに結合されたシリアル出力ポートを有することが可能であり、それを表示可能ピクセル・バッファ、オフスクリーン・ピクセル・バッファ、またはマルチサンプル・バッファを格納するのに使用することができる。ＤＲＡＭメモリ・デバイスの第２のサブセットはビデオ出力プロセッサへの接続を有することができないため、オフスクリーン・ピクセル・バッファまたはマルチサンプル・バッファを格納するのに使用することができる。その結果、一実施形態では、フレーム・バッファが最高２６０万ピクセルを表示可能であり、サンプル・バッファは、最高５２０万サンプルから表示されたピクセル数を引いた数まで格納する。マルチサンプルおよびスーパーサンプルという語は、本明細書では同義語として使用される。
【００２７】
ビデオ出力プロセッサ２４は、ＤＲＡＭメモリ・デバイスの第１のサブセットから出力されたビデオ・データをバッファリングおよび処理することができる。ビデオ出力プロセッサは、ＤＲＡＭメモリ・デバイスからのビデオ・データをバースト単位で読み取ることができる。バーストは、Ｎｂｕｒｓｔピクセル長さであってよい。バースト時には、２ビデオ・クロックごとにＮｃｃピクセルを転送することができる。たとえば一実施形態では、Ｎｂｕｒｓｔが１６０に等しく、Ｎｃｃが８に等しくてよい。ＮｂｕｒｓｔおよびＮｃｃには、様々な値が割当て可能であることに留意されたい。ビデオ出力プロセッサは、ガンマ補正、疑似カラーのカラー・マップ、およびカーソル生成を実行するようにも構成可能である。ビデオ出力プロセッサは、２つのビデオ出力ストリームを提供する２つ（またはそれ以上）の独立したラスタ・タイミング生成器を含むことができる。たとえば、ビデオ出力ストリームのうち１つをＲＧＢ ＤＡＣ ２６に提供し、ビデオ出力ストリームのうち１つをビデオ・エンコーダ２８に提供することができる。
【００２８】
ＲＧＢ ＤＡＣ ２６は、最高Ｒｄｏｔメガヘルツのドット・レートで、高解像度ＲＧＢアナログ・ビデオ出力を提供することができる。たとえば一実施形態では、Ｒｄｏｔは２７０メガヘルツに等しくてよい。
【００２９】
ビデオ・エンコーダ２８は、符号化されたＮＴＳＣまたはＰＡＬビデオ出力を、Ｓビデオまたは合成ビデオのテレビジョン・モニタまたはレコーディング・デバイスに提供することができる。ＮＴＳＣとは、米国国内でのテレビジョンおよびビデオの規格を定義する責務を負ったグループ、Ｎａｔｉｏｎａｌ Ｔｅｌｅｖｉｔｉｏｎ Ｓｔａｎｄａｒｄｓ Ｃｏｍｍｉｔｔｅｅ（米国テレビジョン方式審議委員会）の略語である。ＰＡＬとは、Ｐｈａｓｅ Ａｌｔｅｒｎａｔｉｎｇ Ｌｉｎｅ（位相反転ライン）の略語である。
【００３０】
ブートＰＲＯＭ ３０は、システム初期化およびフレーム・バッファ制御コードを含むことができる。
【００３１】
図２は、一実施形態に従ったグラフィックス・レンダリング・システムを示す高水準構成図である。この構成図には、いくつかの主要な処理ブロック（四角で囲む）、主要なメモリ、テーブルおよびデータ・バッファ（丸で囲む）、ならびに経路（矢印）が含まれる。
【００３２】
上方の四角で囲まれた領域から点線で囲まれたサブ領域を除いたものが、メディア・プロセッサ１４に対応する。中央の四角で囲まれた領域から点線で囲まれた２つのサブ領域を除いたものが、ハードウェア・アクセラレータ１８に対応する。下方の四角で囲まれた領域が、ビデオ出力プロセッサ２４に対応する。
【００３３】
上方領域の点線で囲まれたサブ領域は共用メモリ１６に対応する。中央領域の点線で囲まれた２つのサブ領域はそれぞれテクスチャ・バッファ２０およびフレーム・バッファ２２に対応する。
【００３４】
システム・バス１０４（たとえばＵＰＡ６４Ｓバス）は、ホストプロセッサ（またはホスト・システム）をメディア・プロセッサ１４のホスト・インターフェース１１に結合する。（システム・バスは本明細書ではホスト・バスとも称される。）制御装置１６０は、メディア・プロセッサ１４およびハードウェア・アクセラレータ１８を結合する。バス３２はハードウェア・アクセラレータをデバイスＰＲＯＭ ３０およびビデオ出力プロセッサ２４に結合する。バス３２は、本明細書ではＨｖｂｕｓとも称される。
【００３５】
グラフィックス・レンダリング・システムは、フレーム・バッファ、テクスチャ・バッファ、共用メモリ、およびデバイスＰＲＯＭ ３０などのいくつかのメモリを含むことができる。
【００３６】
グラフィックス・レンダリング・システムは、グラフィックスをフレーム・バッファ２２に加速描画し、その後フレーム・バッファのコンテンツを１つまたは複数のビデオ出力ストリームで表示することが可能ないくつかの機能を有する。一実施形態では、フレーム・バッファ・メモリを使用して、最高５２０万のデータ・アイテム（データ・アイテムはサンプルまたはピクセルのいずれかであってよい）を格納するために使用することが可能であり、最高２６０万のピクセルを表示することが可能であって、残りのデータ・アイテムをオフスクリーン・ピクセルまたはサンプル・バッファに使用することが可能である。
【００３７】
デバイスＰＲＯＭは、メディア・プロセッサ用のブートストラップ・コードを含むことができる。デバイスＰＲＯＭは、システムＯｐｅｎＢｏｏｔ ＦＣＯＤＥ（デバイスの識別および初期化、コンソール端末エミュレータ）を含むこともできる。
【００３８】
メディア・プロセッサ１４における処理ブロック
図１Ｄおよび２は、メディア・プロセッサ１４の例示的実施形態を提供するものである。メディア・プロセッサ１４はホスト・インターフェース１１を含む。ホスト・インターフェース１１は北ＵＰＡインターフェース（ＮＵＰＡ）であってよい。ホスト・インターフェースは、ホストとグラフィックス・レンダリング・システムとの間のトランザクションを処理するスレーブである。ホスト・インターフェースは、状態および制御レジスタ、割込み論理、ならびにデータおよびアドレス・バッファを含むことができる。アドレス・デコーダは、状態および制御レジスタ、グラフィックス待ち行列ＧＱ、共用メモリ、またはダイレクト経路ブリッジに向けてデータを送ることができる。
【００３９】
ホストは、グラフィックス・レンダリング・システムによる処理のためにコマンドを待ち行列に入れるグラフィックス待ち行列に、「ストリーム」コマンドを書き込むことができる。ホストは、グラフィックス待ち行列のオーバフローを防ぐために、フロントエンドの状態レジスタで自由なワード・カウントをポーリングすることができる。
【００４０】
ストリーム・コマンドは、それぞれがヘッダ・ワードとそれに続く１つまたは複数のデータ・ワードからなる一連のコマンド文字列を含むことができる。グラフィックス・プリプロセッサ（ＧＰＰ）は、ＧＱから文字列を引き出してそれらを解釈する。文字列タイプに応じて、ＧＰＰは以下の様々な方法で出力をルーティングすることができる。
（１）ＨＡ（ハードウェア・アクセラレータ）レジスタ書き込み（２Ｄ頂点を含む）を他の処理なしにハードウェア・アクセラレータ１８に渡すことができる。
（２）ＧＰＰ制御レジスタ書き込みが、ＧＰＰそれ自体によって吸収される。
（３）メディア・プロセッサのマイクロコード・ルーチンへの属性および命令をバッファリングし、プロセッサ・ユニットＰＵ０およびＰＵ１に渡すことができる。プロセッサ・ユニットはこれらを消費し、ハードウェア・アクセラレータ１８に渡すことができる。
（４）３Ｄ頂点構成要素をフォーマット変換し、頂点アセンブリ・バッファで完全な頂点にアセンブルすることができる。頂点に頂点構成要素がない場合、この値を以前の頂点から引き継ぐことができる。頂点のグループをバッファリングし、次の使用可能なプロセッサ・ユニットにディスパッチすることができる。頂点の変換およびライティングの後、プロセッサ・ユニットのマイクロコード・ルーチンが処理済みの３Ｄ頂点をハードウェア・アクセラレータ１８に送信する。
（５）圧縮された文字列が、属性、頂点、メッシュ・バッファ・オペレーション、およびＧＰＰ制御書込みに圧縮解除される。メッシュ・バッファ・オペレーションはＧＰＰメッシュ・バッファにシャドウイングされ、ハードウェア・アクセラレータに渡され、その他は上記のように処理される。
【００４１】
ＧＰＰは「ハード・タグ」モードで動作することができる。このモードでは、ＧＰＰは各頂点または属性に関してハードウェア・アクセラレータ１８に、処理ユニットに送信する旨の命令タグを送信することができる。すなわち、ハードウェア・アクセラレータは、プロセッサをバイパスしたＨＡレジスタ書込みおよびメッシュ・バッファ・オペレーションと共に、プロセッサ・ユニットから着信する処理済みの属性および頂点を集めて、それらすべてを正しいストリームの順序で配置しなおすことができる。（ＨＡレジスタ書込みは、ハードウェア・アクセラレータ内のレジスタをターゲットとするレジスタ書込みである。）
【００４２】
ある特殊なケースでは、すべてのトランザクションをプロセッサ・ユニットを介してルーティングすることが望ましい場合がある。したがってＧＰＰは、こうした特殊なケースをサポートするために「ソフト・タグ」を有することができる。
【００４３】
メディア・プロセッサ１４は、ＮＰＵ処理ユニットを含むことができる。例示された実施形態では、メディア・プロセッサが２つの処理ユニットＰＵ０およびＰＵ１（すなわちＮＰＵ＝２）を含む。処理ユニットは、本明細書ではＭＰＵとも称される。プロセッサ・ユニット（ＰＵ）で実行するマイクロコード・ルーチンは、以下の機能を含むがこれらに限定されることのない、いくつかの機能を実行する。
（ａ）頂点バッチを変換およびライティングする、高度に最適化された１頂点あたりの処理ルーチン。一実施形態では、１つのバッチが２つまたは４つの頂点を含んでよい。
（ｂ）頂点処理パイプライン・マイクロコード状態、および／またはハードウェア・アクセラレータ（ＨＡ）描画パイプライン（すなわちＨＡにおける描画パイプライン）のハードウェア状態を定義および更新する、属性処理ルーチン。
（ｃ）最適化された頂点処理ルーチンによって、またはＨＡハードウェア・パイプによって直接サポートされていない特殊なケースでは、マイクロコードは独自のプリミティブ・アセンブリ、ラスタ化、および／またはテクスチャリングを実行することができる。
（ｄ）システムは、初期化、トラップ処理、ホスト・ドライバ通信、コンテキスト・スイッチング、およびメモリ割振り用のマイクロコードを処理する。
【００４４】
制御装置１６０（たとえば南ＵＰＡインターフェース）は、メディア・プロセッサをハードウェア・アクセラレータ１８内の様々なブロックのマスタとすることができる。ＧＰＰおよびＰＵは、ハードウェア・アクセラレータの頂点コレクションおよびプリミティブ・アセンブリ・ブロックに書き込むことができる。ＰＵは、ＰＵダイレクト経路を使用して、フレーム・バッファ・ピクセル、テクスチャ・バッファ・テクセル、ならびに（ＤＰユーザ、プリミティブ・アセンブリ、クリップ・トラップ処理、構成およびコンテキスト・スイッチ・レジスタを含む）ハードウェア・アクセラレータおよびビデオ出力プロセッサ内の様々なレジスタに、読取りおよび書込みすることもできる。
【００４５】
一実施形態では、ダイレクト経路ブリッジは、ホスト・バスを、ＦＢピクセル、ＴＢテクセル、ならびに（ＤＰユーザ、プリミティブ・アセンブリ、クリップ・トラップ処理、構成およびコンテキスト・スイッチ・レジスタを含む）ハードウェア・アクセラレータおよびＨＶｂｕｓ内の様々なレジスタに読取りおよび書込みをするためのＳＵＰＡマスタとすることができる、ＮＵＰＡからＳＵＰＡへのバス・ブリッジである。ダイレクト経路ブリッジは、本明細書ではバス・インターフェース・ユニット（ＢＩＵ）１５４とも称される。
【００４６】
ＦＢはフレーム・バッファの頭字語である。
ＴＢはテクスチャ・バッファの頭字語である。
ＵＰＡはユニバーサル・ポート・アーキテクチャの頭字語である。
ＮＵＰＡは北ＵＰＡの頭字語である。
ＳＵＰＡは南ＵＰＡの頭字語である。
【００４７】
ユニバーサル・ポート・アーキテクチャ（ＵＰＡ）はバス仕様である。マスタおよびスレーブをサポートするＣＰＵ用の１２８ビットＵＰＡポート（「ＵＰＡ１２８」）、マスタおよびスレーブをサポートするＩ／Ｏチップ用の６４ビット・ポート（「ＵＰＡ６４Ｍ」）、さらにスレーブ専用デバイス用の６４ビット・ポート（「ＵＰＡ６４Ｓ」）がある。
【００４８】
ハードウェア・アクセラレータの処理ブロック
一実施形態では、図１Ｂ、１Ｃ、および２で様々に例示されたように、ハードウェア・アクセラレータ１８は以下の処理ブロックを含む。
【００４９】
スレーブ・インターフェース：スレーブ・インターフェース（たとえば南ＵＰＡインターフェース）は、メディア・プロセッサ内のＳＵＰＡマスタに応答する。スレーブ・インターフェースは、状態および制御レジスタ、割込み論理、ピクセル先行読取り論理、データおよびアドレス・バッファを含むことができる。スレーブ・インターフェースは、メディア・プロセッサからトランザクションを受け取る。各トランザクションにはアドレスおよび何らかのデータが含まれる。スレーブ・インターフェース内のアドレス・デコーダは、トランザクションを送信しなければならない場所を決定するために、（たとえばルックアップ・テーブルを使用して）アドレスをデコードする。たとえば、アドレス・デコーダはデータを、様々なＨＡレジスタ、頂点プロセッサ（ＶＰ）、ダイレクト経路、レンダリング／加速経路、またはビデオ出力プロセッサのうちいずれかにルーティングすることができる。スレーブ・インターフェースは、本明細書ではＵＢＩ（ＵＰＡバス・インターフェース）とも称される。
【００５０】
頂点プロセッサ（ＶＰ）：頂点コレクションおよびプリミティブ・アセンブリは、頂点プロセッサ内で実行される。頂点プロセッサは命令タグ、ＨＡレジスタ書込み、属性書込み、および処理済みの３Ｄ頂点構成要素を収集する。
【００５１】
３Ｄ頂点は、後で再使用するためにメッシュ・バッファに入れておくことができる。タグ・ストリームの順序に基づいて、新しい頂点および再使用される頂点は、プリミティブ・アセンブリ・ブロックによって３Ｄプリミティブにアセンブルされ、その後クリップ・テストされる。クリップ・テストに合格したプリミティブは、ラスタ化パイプに向けて発信される。クリップ・テストに不合格のプリミティブはトスされる。曖昧な場合は、メディア・プロセッサのマイクロコードによって処理されるクリップ・トラップを生じさせる。
【００５２】
一実施形態では、２Ｄ頂点がＨＡレジスタ書込みとして着信し、どんなメッシュ・バッファまたはクリッピング・サポートもなしに、プリミティブ・アセンブリが単純化される。
【００５３】
ラスタ化パイプ（ＲＰ）：ラスタ化パイプは発信されたプリミティブ（線、多角形など）を受け入れ、それらをピクセル・フラグメントに圧縮解除する。フラグメントの位置、カラー、アルファ、および深さがサンプル生成器に送信される。フラグメント・テクスチャ座標がテクスチャ・アドレス・ブロックに送信される。
【００５４】
サンプル生成器（ＳＧ）：３Ｄプリミティブの確率的にサンプリングされたラスタ化が実行可能である場合、ＳＧはどのサンプル位置がプリミティブの内側にあるかを決定し、各内部サンプル位置でカラー、アルファ、および深さを補間して、その結果をテクスチャ環境ユニット（ＴＥ）に送信する。
【００５５】
３Ｄの線または点のフィルタリング（たとえばガウス・フィルタリング）が実行可能である場合、ＳＧはその線または点の有効領域内部にある各ピクセルでのフィルタ重みを決定し、その後アルファとそのフィルタ重みとを掛け合わせ、ピクセル・フラグメントのカラー、アルファ、深さ、および位置をテクスチャ環境ユニットに送信する。
【００５６】
サンプリングおよびガウス・フィルタリングが実行不能である場合、またはプリミティブが２Ｄである場合、ＳＧは、ラスタ化されたピクセル・フラグメントのカラー、アルファ、深さ、および位置を、修正せずにテクスチャ環境ユニットに渡すことができる。
【００５７】
テクスチャ・アドレス・ユニット（ＴＡ）：テクスチャリングが実行可能である場合、ラスタ化パイプはフラグメント・テクスチャ座標をＴＡに送信する。ＴＡは、テクセル・サンプル・アドレス、ならびに指定されたフィルタ・フットプリント内のテクセル・サンプルを検索およびフィルタリングするために必要な詳細かつブレンドされた要素のレベルを決定する。ＴＡは、必要な各テクセル・サンプルに関して、テクスチャ・バッファ（ＴＢ）への読取り要求を生成する。「サンプル」という語は、グラフィックス・プリミティブの内部にある各サンプル位置でサンプル生成器ＳＧによって算出されたデータ値のセット（たとえばｒｇｂａｚ）を示す際にも使用されることに留意されたい。コンテキストが、どの用法を意味しているかを判定する。
【００５８】
テクスチャ・ファイル（ＴＦ）：ＴＦは、ＴＡからのブレンド要素と共にテクセル・サンプル・データをＴＢから受け取り、フィルタリング済みのテクセルを生成するために、テクセル・サンプルをブレンドする。
【００５９】
ピクセル転送ユニット（ＰＸ）：テクスチャリング中に、ＴＦ出力がＰＸに送信され、ここで、フィルタリング済みテクセルのカラーおよびアルファ値に関して検索機能を実行することができる。さらにＰＸは、ダイレクト経路およびコピー・オペレーション中にも使用される。
【００６０】
テクスチャ環境ユニット（ＴＥ）：テクスチャリング中に、ＴＥは、ＰＸ出力（テクスチャのカラー／アルファ）とＳＧ出力（フラグメントのカラー／アルファ）とをマージして、テクスチャ済みフラグメントを取得する。テクスチャリングが実行不能である場合、ＴＥはＲＰ／ＳＧフラグメントのカラー、アルファ、深さを通過させる。
【００６１】
テクスチャ・パイプ（ＴＰ）：ＴＡ、ＴＢ、ＴＦ、ＰＸ、ＴＥクラスタは、本明細書ではテクスチャ・パイプと称される。
【００６２】
レンダリング・パイプ：ＶＰ、ＲＰ、ＳＧ、およびＴＥによって定義されるユニットのクラスが、レンダリング・パイプと呼ばれる。
【００６３】
ストリーム経路：ストリーム経路はＧＱおよびＧＰＰから始まり、ＰＵの中または周囲を通過し、ＶＰおよびＲＰを通過して、テクスチャをＴＰへ、ピクセルをＳＧへと分岐させ、それらをＴＥで再結合させることができる。ＴＥの結果は、ストリーム／ダイレクト結合パイプ同期ポイントへ送られる。
【００６４】
ストリーム／ダイレクト結合：ストリームおよびダイレクト経路は、メディア・プロセッサ１４のホスト・インターフェースで分岐する（すなわち、ストリームはＧＱへ進み、ダイレクトはダイレクト経路ブリッジへ進む）。ストリーム／ダイレクト結合ポイントは、ストリームおよびダイレクト経路が再結合する場所であり、共用経路が始まる場所である。
【００６５】
共用経路：フレーム・バッファへのフラグメント・パイプおよび書込みは、ストリームおよびダイレクト経路によって共用される。任意の所与の時点に、ストリームまたはダイレクト経路のうちの１つが共用経路を所有することができる。
【００６６】
フラグメント・パイプ（ＦＰ）：ＦＰは、
定数の置き換え、
領域のパターン化、
アドレス、カラー、およびアルファのクリッピング、
ウィンドウＩＤ（ＷＩＤ）、ステンシル、および深さのテスト、
プレーン・グループの実行可能化およびビット・プレーンのマスク、
フォグ、ブレンド、およびラスタ・オペレーションなどの、
１フラグメントあたりの書込みオペレーションを実施する。
【００６７】
一実施形態では、ＦＰは、一部はハードウェア・アクセラレータ１８に、一部はフレーム・バッファ２２にある。
【００６８】
コピー／フィルタリング・オペレーション：ストリーム・コマンドには、ラスタ化パイプがＴＢとＦＢとの間またはその中でデータを移動させるメモリ・アドレス生成器となる、以下のような様々なコピー／フィルタリング・オペレーションが含まれる。
【００６９】
（Ａ）ブロック・コピー・オペレーションは、任意選択のピクセル転送（ＰＸ）オペレーション（たとえばスケール、バイアス、カラー・マトリクス、検索、ヒストグラム、最小／最大）を使用して、ＴＢとＦＢとの間またはその中でピクセルまたはテクセルを移動させる。
【００７０】
（Ｂ）イメージ・フィルタリング・オペレーションは、テクスチャ・フィルタ（ＴＦ）を使用して、ＴＢピクセル・データ（すなわち、テクスチャ・バッファに格納されたピクセル・データ）での畳み込みを実行する。畳み込みの結果に対してオプションのＰＸオペレーション（前述）を実行し、ＴＢまたはＦＢに送信することができる。
【００７１】
（Ｃ）レンダリング・パイプは、確率的にサンプリングされたシーンを、ＦＢのオフスクリーン・サンプル・バッファにレンダリングすることができる。シーンがレンダリングされた後、確率的サンプル・フィルタ（ＳＳＦ）を使用して、ＦＢサンプル・バッファからのサンプルで畳み込みを実行し、ＦＢの表示領域にエイリアス除去されたシーンを作成することができる。ＳＳＦ出力は、ＰＸによって補正されたガンマであってよい。
【００７２】
（Ｄ）アキュムレーション・バッファ・オペレーションは、ＴＢの領域をアキュムレーション・バッファとして使用し、ＯｐｅｎＧＬ負荷、累算、乗算、加算、および復帰オペレーション、ならびにボリューム・レンダリングに対する高度に精密なスライス・ブレンド・オペレーションをサポートする。ＴＢ内の連続したメモリ領域を、アキュムレーション・バッファ（たとえばＲＧＢ１６バッファ）として割り振ることができる。
【００７３】
ダイレクト・ピクセル／テクセル書込み経路：ダイレクト書込み経路はホスト・インターフェースおよびダイレクト経路ブリッジから始まり、制御装置（ＳＵＰＡ）へと向かう。書込みアドレスおよびデータは、ＰＸ入力セレクタ（本明細書ではピクセル転送マルチプレクサとも称される）を介してＰＸユニットへ送信され、書込みデータ上でピクセル転送（ＰＸ）オペレーションを実行するために割り当てることができる。ＰＸの結果はストリーム／ダイレクト結合ポイントに送信され、その後（共用経路フラグメント・パイプを介して）ＴＢまたはＦＢのいずれかに送信される。
【００７４】
ダイレクト・ピクセル／テクセル読取り経路：ダイレクト読取り経路はホスト・インターフェースおよびダイレクト経路ブリッジから始まり、制御装置へと向かう。読取りアドレスはＰＸを通過してストリーム／ダイレクト結合ポイントに渡され、その後ＴＢまたはＦＢに渡される。メモリ読取りデータはＰＸ入力セレクタを介してＰＸユニットに戻り、結果が（制御装置１６０およびホスト・インターフェース１１を介して）ホストに戻される前に、読取りデータに対してピクセル転送（ＰＸ）オペレーションを実行するために割り当てることができる。
【００７５】
ビデオ出力プロセッサ２４内にあるかまたはこれに関する処理ブロック
ＨＶＢｕｓインターフェース（ＨＢＩ）：ＨＢＩは、ＳＵＰＡバスが（およびＭＰＵまたはホスト・コンピュータの拡張により）、デバイスＰＲＯＭの読取り、ならびにビデオ出力プロセッサ（ＶＯＰ）のレジスタおよびテーブルの間接的な読取り／書込みを実行できるようにするものである。
【００７６】
ウィンドウ・ルックアップ・テーブル（ＷＬＵＴ）：ＷＬＵＴは、各ウィンドウの視覚表示属性を定義するものであって、ウィンドウＩＤプレーンによって索引付けされる。ＷＬＵＴエントリは、
ＲＧＢ対索引付けカラー、
索引付けカラー・ソース（Ｒ、Ｇ、Ｂ、オーバレイ）、
カラー・ルックアップ・テーブル数、ガンマ補正、またはバイパス、
オーバレイなし、不透明オーバレイ、または透明オーバレイ
などの視覚表示属性を指定することができる。
【００７７】
ＷＬＵＴは物理的に分離し、一部はハードウェア・アクセラレータ１８に、一部はフレーム・バッファ２２に、一部はビデオ出力プロセッサ２４に常駐することができる。フレーム・バッファにはオーバレイ論理もあり、これが１次プレーンまたはオーバレイ・プレーンが表示されるかどうかを決定する。
【００７８】
カラー・フックアップ・テーブル（ＣＬＵＴ）：一実施形態では、擬似カラーまたはダイレクト・カラー・マップを格納するために、１つのＣＬＵＴについて２５６のトリプル・エントリを備えた４つのＣＬＵＴが使用可能である。真のカラー・ウィンドウの場合、代わりに単一のガンマＬＵＴ（ＧＬＵＴ）（１０２４のトリプル・エントリ）を使用することができる。ＧＬＵＴをバイパスすることも可能である。
【００７９】
追加のビデオ出力機能は、ハードウェア・カーソルおよびデュアル・ビデオ・タイミング生成器を含むことが可能であり、これによって１次および２次ビデオ出力ストリームへのタイミングおよびデータ要求を生成することができる。
【００８０】
ビデオ・デジタル・アナログ変換器（ＤＡＣ）またはエンコーダ：１次ビデオ出力ストリームは、ビデオＤＡＣ（たとえば、赤、緑、および青それぞれに１０ビットを受け取るビデオＤＡＣ）をアナログ・コンピュータ・ディスプレイに対して駆動させることができる。２次ビデオ・ストリームは、
（１）オンボードＴＶエンコーダをＳビデオＴＶモニタまたはレコーディング・デバイスに対して駆動させるか、または
（２）機能拡張コネクタを駆動させることができる。可能なドーター・カード・オプションには、
第２のアナログ・コンピュータ・ディスプレイ、
デジタル・フラット・パネル・リンク、または
シリアル・デジタル・ビデオ出力リンクが含まれる。
【００８１】
２．０ マルチサンプリングのレンダリング後のフィルタリング
一実施形態では、グラフィックス・レンダリング・システムは、フル・シーンのレンダリング完了までのサンプル・フィルタリングとは異なる。
【００８２】
グラフィックス・レンダリング・システムは、表示バッファ・スワップ直前までのサンプル・フィルタリングとは異なる場合がある。シーン全体がアニメーション速度（シーンの複雑さによって異なる）でフィルタリングされる。
【００８３】
グラフィックス・レンダリング・システムは、
（ａ）シーンを（ＦＢ内に割り振られた）サンプル・バッファにレンダリングするステップと、
（ｂ）シーンをサンプル・バッファから（同様にＦＢ内に割り振られた）バック表示バッファへ、アニメーション速度でフィルタリングし、、
（ｃ）フロントおよびバック表示バッファを（アニメーション速度で）スワップし、
（ｄ）各表示リフレッシュについて、表示バッファ内のピクセルを（アニメーション速度よりも速い場合の多いビデオ速度で）表示することの、一連のステップを実行する。
【００８４】
２．１ フレーム・バッファ（ＦＢ）割振り
２．１．１ ＦＢビット・プレーンの用法
フレーム・バッファ２２の一実施形態では、各ピクセル（またはサンプル）は１１６ビット・プレーンのデータを有することができる。図３は、１１６ビット・プレーンを編成する１つの方法を示す図である。図４は、ピクセル（またはサンプル）を構成する様々なフィールドを記載した表である。
【００８５】
サンプル・バッファにレンダリングする場合、ハードウェア・アクセラレータ１８はＲ、Ｇ、Ｂ、ＡをバッファＡに書き込み、さらにＳおよびＺも書き込むことができる。ＳおよびＺは、最終シーンでどのサンプルが見えるかを決定する、ステンシルおよび隠面消去オペレーションに必要となる。最終シーンでＲＧＢカラー値に影響を与える可能性のある合成および透過性のために、アルファ（Ａ）を使用することができる。
【００８６】
フィルタリングの際、ハードウェア・アクセラレータ１８は、サンプル・バッファからＲ、Ｇ、Ｂを読み取り、フィルタリング結果を（ＰＸユニットおよびフラグメント・パイプを介して）表示バッファ（バッファＡまたはバッファＢのいずれか、ダブル・バッファされたレンダリング中に現在「バック」バッファである方）のＲ、Ｇ、Ｂプレーンに書き込むことができる。ウィンドウ・システムは、Ｗおよびオーバレイ・プレーンをフィルタリング・プロセスとは別に維持することが可能であり、Ｗｐ面はＲＧＢの真のカラー表示を発生させるように設定可能である。
【００８７】
表示の際、Ｗｐ面は「フロント」表示バッファから、ＲＧＢの真のカラー表示を選択することができる。
【００８８】
２．１．２ ＦＢメモリ割振り
以下の考察では、フレーム・バッファ２２が、４つのランクに編成された１６のＤＲＡＭメモリ・デバイスを有すると想定される。ただし、フレーム・バッファ内のＤＲＡＭメモリ・デバイスの数は様々ないずれの値を取ってもよく、同様に、フレーム・バッファ内のランク数も様々ないずれの値を取ってもよいことに留意されたい。
【００８９】
単一のＤＲＡＭメモリ・デバイスは、６４０×５１２のデータ・アイテム用の記憶域を含むことができる。（データ・アイテムは、図３で提案されたように１１６ビットを有することができる。）したがって、フレーム・バッファは、最高１６×６４０×５１２＝５１２０Ｋのデータ・アイテムを格納することができる。各データ・アイテムがピクセルまたはサンプルを表すことができる。一実施形態では、ＤＲＡＭメモリ・デバイスの半分がビデオ出力プロセッサに結合され、ＤＲＡＭメモリ・デバイスの残りの半分はそのように結合されない。これらの実施形態では、フレーム・バッファは、最高２５６０Ｋの表示ピクセル（すなわちオンスクリーン・メモリ・ピクセル）を格納することができる。
【００９０】
フレーム・バッファ・メモリを割り振るための基本単位が「ページ」と呼ばれる。一実施形態では、１ページに５１２０のデータ・アイテムを含むことができる。したがって、フレーム・バッファ・ページ容量は、５１２０Ｋ／５１２０＝１０２４ページに等しくすることができる。最初の５１２ページが表示可能である。
【００９１】
グラフィックス・レンダリング・システムは、最高Ｎｄｒの表示可能領域をサポートすることが可能であり、Ｎｄｒは正の整数である。一実施形態では、グラフィックス・レンダリング・システムは、最高２つの表示可能領域および無制限数のオフスクリーン領域をサポートすることができる。
【００９２】
たとえば、コンソールが第１の表示可能領域であってよい。第１の表示可能領域は、図５で提案されるように、ＦＢメモリのページ０から開始されるように割り振ることができる。したがって、第１の表示可能領域にＤ１ページが割り振られた場合、第１の表示可能領域はページ０からＤ１−１までを占有することになる。
【００９３】
第２の表示可能領域がある場合、コンソールのすぐ上に割り振ることができる。例では、第２の表示可能領域にＤ２ページが割り振られた場合、第２の表示可能領域はページＤ１からＤ１＋Ｄ２−１までを占有することが可能であり、ここでＤ１＋Ｄ２＜＝５１２ページである。記号「＜＝」は「より少ないかまたは等しい」ことを示す。
【００９４】
スーパーサンプリングが要求された場合、オフスクリーン・スーパーサンプリング領域はＦＢメモリの頂部（ページ１０２３より下方から）に割り振ることができる。例では、Ｓ１ページが割り振られる場合、オフスクリーン・スーパーサンプリング領域は１０２４−Ｓ１から１０２３までを占有することが可能であり、ここでＳ１＋Ｄ１＋Ｄ２＜＝１０２４である。
【００９５】
追加のオフスクリーン・メモリが割り振られた場合、第１のスーパーサンプリング領域よりも下まで及ぶ可能性がある。
【００９６】
所与のフレーム・バッファ記憶モード（ＦＢ＿＊＿ＭＯＤＥレジスタによって設定）では、各割振りページが、固定されたピクセル高さと幅を有する。図６の表は、グラフィックス・レンダリング・システムの一実施形態に従った、様々なＦＢ＿ＭＯＤＥオプションでのページ・サイズを列挙したものである。サンプル密度が２のべき乗でない場合、２のべき乗でない数は２のべき乗で割り切れないため、割振りページの幅掛ける高さは５１２０データ・アイテムのページ容量よりも少なくなる。
【００９７】
フレーム・バッファ領域は四角形の領域である。領域の幅は割振りページ幅の整数倍に対応する。領域の高さは割振りページ高さの整数倍に対応する。端数サイズの領域（領域幅がページ幅の整数倍でないか、または領域高さがページ高さの整数倍でない）が所望の場合、次に大きな整数倍幅および整数倍高さを割り振ることができる。
ｗｉｄｔｈＰａｇｅｓ＝ｒｏｕｎｄｕｐ（ｗｉｄｔｈＰｉｘｅｌｓ／ｐａｇｅＷｉｄｔｈ）
ｈｅｉｇｈｔＰａｇｅｓ＝ｒｏｕｎｄｕｐ（ｈｅｉｇｈｔＰｉｘｅｌｓ／ｐａｇｅＨｅｉｇｈｔ）
割り振られる合計領域（ページ単位）は、単純に領域の幅と高さの積である（どちらも整数ページに切り上げられる）。
ａｒｅａＰａｇｅｓ＝ｗｉｄｔｈＰａｇｅｓ＊ｈｅｉｇｈｔＰａｇｅｓ
たとえば、１１５２×９００の非立体表示用のＦＢメモリ領域を割り振るためには、ｐａｇｅＷｉｄｔｈが３２０でありｐｅｇｅＨｅｉｇｈｔが１６であることに留意されたい。以下の計算式は、１１５２×９００の表示領域が、２２８ページを有するフレーム・バッファ領域でカバーできることを示すものである。
ｗｉｄｔｈＰａｇｅｓ＝４ ｐａｇｅｓ ｗｉｄｅ＝ｒｏｕｎｄｕｐ（１１５２／３２０）
ｈｅｉｇｈｔＰａｇｅｓ＝５７ ｐａｇｅｓ ｈｉｇｈ＝ｒｏｕｎｄｕｐ（９００／１６）
ａｒｅａＰａｇｅｓ＝２２８ ｐａｇｅｓ＝４＊５７
グラフィックス・ウィンドウが７００×７００ピクセルを有するものと想定すると、オフスクリーン・スーパーサンプル・バッファはサンプル密度４でウィンドウに割り振られることになる（すなわち単位ピクセル領域あたり４つのサンプルが生成される）。サンプル密度４の場合、ｐａｇｅＷｉｄｔｈは８０でありｐａｇｅＨｅｉｇｈｔは１６である。以下の計算式は、スーパーサンプル・バッファに３９６ページのフレーム・バッファが割り振られることを示すものである。
ｗｉｄｇｈＰａｇｅｓ＝９ ｐａｇｅｓ ｗｉｄｅ＝ｒｏｕｎｄｕｐ（７００／８０）
ｈｅｉｇｈｔＰａｇｅｓ＝４４ ｐａｇｅｓ ｈｉｇｈ＝ｒｏｕｎｄｕｐ（７００／１６）
ａｒｅａＰａｇｅｓ＝３９６ ｐａｇｅｓ＝９＊４４
ライブラリ機能は、所望のピクセル単位の高さと幅と共にＦＢ＿ＭＯＤＥを指定してＦＢ領域を割り振るために、メモリ割振り要求をアサートすることができる。ソフトウェア・ドライバは上記の計算を実行し、所望の領域を所望のＦＢ＿ＭＯＤＥで格納するのに必要なページ数を割り振ることが可能であり、失敗／成功状態とＦＢ＿ＢＡＳＥ（最初に割り振られたページ）およびＦＢ＿ＳＴＲＩＤＥ（割り振られた領域のページ単位の幅）とを戻す。ドライバは、その後の要求時に使用するために、割り振られた領域の独自の記録も維持することができる。
【００９８】
まだ割り振られずに残っているメモリの量の照会、ならびに、指定のモード、高さ、および幅が要求された場合にはどれだけの量のメモリが割り振られることになるのかを確認するための他の照会を実行するライブラリ機能も可能である。
【００９９】
Ｗｄ×Ｈｄピクセルを有する表示のための（ダブル・バッファされた）ピクセル表示バッファが割り振られるものと想定する。この表示をサポートするために、ドライバは以下の式によって整数のＦＢメモリ・ページを割り振ることが可能であり、
ｃｅｉｌｉｎｇ（Ｗｄ／ｐａｇｅＷｉｄｔｈ）＊ｃｅｉｌｉｎｇ（Ｈｄ／ｐａｇｅＨｅｉｇｈｔ）
上式で、ｐａｇｅＷｉｄｔｈおよびｐａｇｅＨｅｉｇｈｔはそれぞれＦＢメモリ・ページの幅および高さである。ｐａｇｅＷｉｄｔｈおよびｐａｇｅＨｅｉｇｈｔの値は、ＦＢメモリ割振りモードに応じて変化する。モードは、割り振られるバッファが表示バッファとして働くものであるか、またはオフスクリーン・バッファとして働くものであるかを示すことができる。さらにモードは、表示バッファが立体用に構成されるものであるか、非立体用に構成されるものであるか、あるいはオフスクリーン・バッファがピクセル用に使用されるものであるか、サンプル用に使用されるものであるかも示すことができる。後者の場合、モードはサンプル密度、すなわちピクセルあたりのサンプル数を示すことができる。
【０１００】
ウィンドウ・システムでは、グラフィックス・レンダリング・システムは全画面サイズよりも小さいウィンドウにレンダリングすることができる。ウィンドウがＷｗ×Ｈｗピクセル・サイズを有すると想定すると、サンプル・フィルタ（ＳＦ）はＷｆ×Ｈｆピクセルのフットプリントを有し、サンプル密度はＤＳである。この場合ドライバは、ウィンドウに対応するオフスクリーン・サンプル・バッファに関して、以下の式で与えられる整数のＦＢメモリ・ページを割り振ることができる。
Ｃｅｉｌｉｎｇ｛（Ｗｗ＋Ｗｆ）／ｐａｇｅＷｉｄｔｈ｝＊Ｃｅｉｌｉｎｇ｛（Ｈｗ＋Ｈｆ）／ｐａｇｅＨｅｉｇｈｔ｝
【０１０１】
オフスクリーン・サンプル・バッファが、サンプル・フィルタ・フットプリントの「スカート」を収容するためのＷｗ×Ｈｗウィンドウを囲む境界線を含むことに留意されたい。フットプリントを備えた拡大されていないボックス・フィルタが厳密に表示されるピクセルであるという特殊なケースでは、Ｗｆ×Ｈｆはゼロであり（ピクセル外部からの寄与がないため）、特別な境界線割振りは不要である。
【０１０２】
有限のＦＢ容量は、表示バッファとサンプル・バッファで共用される。したがって最大サンプル密度はほぼ以下に等しく、
Ｆｌｏｏｒ｛データ・アイテム単位のＦＢサイズ−ピクセル単位の表示サイズ）÷（ピクセル単位のウィンドウ・サイズ）｝
ここでＦｌｏｏｒ｛ｘ｝は整数下限関数である。これは、解像度の低い表示および／またはサイズの小さいウィンドウが、固定サイズのサンプル・バッファ内でより高いサンプル密度をサポートできることを暗に示している。
【０１０３】
例：
単一ヘッドの１２８０×１０２４非立体表示の場合、表示バッファは（ｃｅｉｌ（１２８０／３２０）＊ｃｅｉｌ（１０２４／１６））＝２５６ページのＦＢメモリを使用する。これで、（１０２４−２５６）＝７６８ページが、１ページあたり５１２０サンプルでサンプル・バッファ用に残される。
１０００×１０００ピクセル・ウィンドウは（ｃｅｉｌ（１０００／８０）＊ｃｅｉｌ（１０００／２０）６５０ページであり、７６８ページよりも少ないため、サンプル密度３をサポートすることができる。
７２０×６７０ピクセル・ウィンドウはｃｅｉｌ（７２０／４０）＊ｃｅｉｌ（６７０／１６）＝７５６ページであり、７６８ページよりも少ないため、サンプル密度８をサポートすることができる。
【０１０４】
単一ヘッドの９６０×６８０立体表示の場合、表示バッファは（ｃｅｉｌ（９６０／３２０）＊ｃｅｉｌ（６８０／８））＝２５５ページのＦＢメモリを使用する。これで（１０２４−２５５）＝７６９ページがサンプル・バッファ用に残される。したがって、第１の例と同じサイズのウィンドウをサポートすることができる。
【０１０５】
単一ヘッドの６４０×４８０立体ＶＧＡ表示の場合、表示バッファは（ｃｅｉｌ（６４０／３２０）＊ｃｅｉｌ（４８０／８））＝１２０ページのＦＢメモリを使用する。これで（１０２４−１２０）＝９０４ページがサンプル・バッファ用に残される。ｃｅｉｌ（６００／４０）＊ｃｅｉｌ（４８０／８）＝９００ページであり、９０４ページよりも少ないため、ほぼ全画面のウィンドウ（６００×４８０）はサンプル密度１６をサポートする。
【０１０６】
２．２ レンダリングおよびフィルタリング段階
マルチサンプリングを使用してシーン・フレームをレンダリングするために、グラフィックス・レンダリング・システムは一連のステップを実行する。この一連のステップは、シーン・アニメーション中、何回も繰り返される。以下の記述は、ウィンドウ・サイズ（フィルタ・フットプリントを加える）のサンプル・レンダリング・バッファおよびスクリーン・サイズのピクセル表示バッファがＦＢメモリで事前に割り振られていると想定したものである。
【０１０７】
２．２．１ サンプル・レンダリング・バッファのクリア
レンダリングの前に、（ウィンドウ・サイズの）サンプル・バッファにあるサンプルは、深さを無限にしてステンシル・プレーンをリセットした背景ＲＧＢカラーへと「クリア」される。高速フィル機能は、このステップを加速させるものである。一実施形態では、高速フィル機能はおよそ５３億サンプル／秒で動作可能である。
【０１０８】
図７は、この流れを表す図である。ラスタ化パイプはウィンドウ領域のサンプル・ブロック・アドレスを生成し、フラグメント・パイプはＦＢメモリ内にサンプル・ブロックを充てんする。クリア・オペレーションでアクティブでない経路は点線で示されている。
【０１０９】
２．２．２ サンプル・バッファへのマルチサンプルのレンダリング
次に、図８および９に示されるように、シーンを定義する頂点（および属性）データが、３−Ｄストリーム・レンダリング経路を介し、ＦＢで割り振られたサンプル・バッファをターゲットとして送信され、マルチサンプリングされたレンダリングを実行可能にする。
【０１１０】
メディア・プロセッサ１４（すなわちグラフィックス・プリプロセッサおよびプロセッサ・ユニット）は、シーン内の各頂点において、変換、ライティング、およびクリップ・コード生成機能を実行することができる。これらの機能は、ＯｐｅｎＧＬ標準または何らかの他の標準に準拠した方法で実行することができる。
【０１１１】
頂点は、ＯｐｅｎＧＬ標準によってプリミティブ（典型的には三角形）にアセンブルすることができる。クリップ・テストおよびフェース−カリング・テストに合格したプリミティブがラスタ化される。この作業は、頂点プロセッサおよびラスタ化パイプラインによって実行することができる。（ラスタ化パイプラインＲＰには、図１Ｃで提案されるように、プリセットアップ・ユニットＰＳＵ、セットアップ・ユニットＳＵ、エッジ・ウォーカＥＷ、およびスパン・ウォーカＳＷユニットが含まれることを想起されたい。）
【０１１２】
ラスタ化パイプラインＲＰは、位置（ｘ，ｙ）、テクスチャ座標（ｓ，ｔ，ｒ）、ならびに深さ（ｚ）およびカラー（ｒ，ｇ，ｂ，ａ）の値で、ピクセルを生成する。
【０１１３】
テクスチャ処理経路には、テクスチャ・アドレス・ユニット（ＴＡ）およびテクスチャ・フィルタ（ＴＦ）ユニットが含まれる。テクスチャ処理経路は、単一のテクスチャ座標ベクトル（ｓ，ｔ，ｒ）に基づいて、最高のテクセル・サンプル（たとえばＮｔｍｓ＝８）をテクスチャ・メモリ２０から読み取り、（ｓ，ｔ，ｒ）での１ピクセルあたりのテクスチャ・カラーを決定するために、これらのテクセル・サンプルをフィルタリングする。一部の実施では、テクスチャ処理経路は複数のテクスチャ座標を受け入れ、１ピクセルについて複数のテクスチャ結果（「マルチテクスチャ」）を生成することができる。
【０１１４】
サンプル生成器ＳＧは、各サンプルのサブピクセル位置をピクセル単位で決定し、どのサンプルがプリミティブ内部にあるかを決定する。サンプル評価器ＳＥは、サンプル・マスクおよび（ｒ，ｇ，ｂ，ａ，ｚ）に対するサンプルあたりの値を生成する。
【０１１５】
サンプル処理パイプラインおよびテクスチャ処理パイプラインは非同期的に動作し、一般に様々なピクセルあたりのデータ量を生成する。これには、パイプラインを他のパイプラインより多少前または後のいずれかに実行できるようにする待ち行列が含まれる。
【０１１６】
各ピクセルについて、テクスチャ環境ユニットＴＥは、テクスチャ・パイプラインからの（ピクセルあたりの）テクスチャ・カラーを、そのピクセルから生成されたすべてのサンプルに適用する。最終的にテクスチャ化されたピクセル・カラーは、ＯｐｅｎＧＬテクスチャ環境関数を使用して、またはマルチテクスチャの場合には、ＯｐｅｎＧＬマルチテクスチャ拡張を使用して適用することができる。したがってテクスチャ環境は、各ピクセルから複数のテクスチャ化されたサンプルを生成する（フラグメント・サンプルとも呼ばれる）。
【０１１７】
フレーム・バッファを形成するそれぞれのＤＲＡＭメモリ・デバイスが、本明細書ではメモリ組込み型ピクセル・プロセッサと称される、１つまたは複数のピクセル・プロセッサを含むことができる。Ｍｉｔｓｕｂｉｓｈｉの製造する３ＤＲＡＭメモリ・デバイスは、こうしたメモリ組込み型ピクセル・プロセッサを備えるものである。
【０１１８】
フラグメント（テクスチャ化されたサンプル）はフラグメント・パイプおよびメモリ組込み型ピクセル・プロセッサによって処理され、フレーム・バッファ・メモリ内の事前に割り振られたサンプル・バッファ領域に書き込まれる。メモリ組込み型ピクセル・プロセッサは、標準のＯｐｅｎＧＬフラグメント処理動作（たとえばブレンド、ステンシル、Ｚバッファリングなど）を適用することができる。
【０１１９】
一般に、同じシーン・フレーム内で、複数のプリミティブが同じサンプル位置にサンプル値を与えることができる。こうしたサンプル（すなわち非透過サンプル）の多くについて、Ｚバッファリング・オペレーションは、「勝った」プリミティブ（通常は視聴者に最も近いもの）からサンプル値を選択することになる。この隠面消去プロセスにより、シーン内で以前にレンダリングされたサンプルの一部を、シーン内で後にレンダリングされたサンプルに置き換えることができる。「深さの複雑性」という語は、各サンプルを更新するための試行のシーンあたりの平均回数を表すために使用される。目の位置から見ると多くのオブジェクトが相互に前後に散乱したシーンは、深さの複雑性が高いことになる。
【０１２０】
２．２．３ バック表示バッファへのサンプル・バッファのフィルタリング
それぞれのフレーム時に、シーンがサンプル・バッファに完全にレンダリングされると、各サンプルについて最終的に「勝った値」が残る。この時点で、ピクセル転送ユニットＰＸおよびフラグメント・パイプラインＦＰを介してフレーム・バッファ２２内のピクセル表示バッファ領域にルーティングされ、スパン・ウォーカ・ユニットＳＷ内のピクセル・コピー・アドレス生成ハードウェアおよびピクセル・コピー・データ経路を再使用する、フィルタリング済みピクセルのアレイを取得するために、サンプル・フィルタＳＦがサンプル・バッファからのサンプルに適用される。
【０１２１】
コピー、フィルタリング、および累算オペレーションは、ストリーム・コマンドの特別なグループであり、ラスタ化パイプＲＰは、ＴＢとＦＢの間、またはこれら内部でのデータの転送を含むメモリ・アドレス生成器となる。コピー経路は図１０で強調されている。オペレーションは、ＦＰ、ＰＸ、コピー、フィルタリング、または累算属性をセットアップするための一連のＢＲＳレジスタ書込み、ならびにそれに続くコピー領域「頂点」（ソースおよび宛先の左上隅、共通の高さと幅）を定義するＶＰへのＢＲＳ書込みによってセットアップすることができる。一実施形態では、コピー領域幅が最後に書き込まれ、コピー・オペレーションをトリガする。ラスタ化パイプはアドレス生成器となり、領域全体のピクセル／テクセル・データの転送を誘導する。コピーが完了すると、ＲＰは通常の処理に戻ることができる。
【０１２２】
図１１は、コピー・フィルタリング、および累算オペレーションに関するデータの流れを示す図である。この図では、図面を簡略化するために、アドレス生成器が２つの別々のボックスとして示される。２つのボックスが識別される。テクスチャ・バッファ２０およびフレーム・バッファ２２も同様に、図面を簡略化するために２重になっている。イメージ・フィルタという語は、テクスチャ・フィルタＴＦのもう１つの名前である。
【０１２３】
コピーおよびサンプル・フィルタ・オペレーション
ブロック・コピー・オペレーションは、ピクセル／テクセルの四角形の領域を、ソース・バッファ内のソース領域から宛先バッファ内の宛先領域に移動するものである。簡単なブロック・コピー・オペレーションには、以下の４種類がある。
・フレーム・バッファからフレーム・バッファへ
・フレーム・バッファからテクスチャ・バッファへ
・テクスチャ・バッファからテクスチャ・バッファへ
・テクスチャ・バッファからフレーム・バッファへ
【０１２４】
図１２は、ピクセル・コピー用のアドレス生成（すなわち、ＦＢからＦＢへのブロック・コピー・オペレーション）を示す図である。ソースは、ストリーム経路ＲＤ＿ＰＤＴレジスタがＰＤ＿ＰＤＴ＿ＰＩＸに設定されている場合はフレーム・バッファ内にあり、ＲＤ＿ＰＤＴ＿ＴＥＸの場合はテクスチャ・バッファ内にある。宛先は、ストリーム経路ＷＲ＿ＰＤＴレジスタがＷＲ＿ＰＤＴ＿ＰＩＸに設定されている場合はフレーム・バッファ内にあり、ＷＲ＿ＰＤＴ＿ＴＥＸの場合はテクスチャ・バッファ内にある。ピクセル転送ブロック機能は、どんなブロック・コピー・オペレーション時にも使用できる。
【０１２５】
ブロック・コピー・アドレッシング。ソース領域および宛先領域の左上隅は、ＣＯＰＹ＿｛Ｘ，Ｙ｝レジスタおよびＲＥＣＴ＿｛Ｘ，Ｙ｝レジスタによって定義される。ＲＥＣＴ＿｛Ｈ，Ｗ｝は、ソース領域および宛先領域の（共通の）サイズを定義する。これらすべての値には位置合わせの制約がなく、領域は１つのピクセルの解像度を使用して位置決めおよびサイズ変更することができる。ソース領域および宛先領域は、それぞれ割り振られたソースおよび宛先のメモリ・バッファ内に位置する。ソースまたは宛先がフレーム・バッファの場合、メモリ・バッファの起点はＦＢ＿｛ＲＤ，ＷＲ｝＿ＢＡＳＥである。
【０１２６】
一実施形態では、ホスト・ルーチンが、各アニメーション・フレームをレンダリングするためのマルチパス・プロシージャ内の各パスについて、宛先領域を再プログラミングすることができる。
【０１２７】
スーパーサンプル・フィルタ（ＳＳＦ）。フレーム・バッファのスーパーサンプル・バッファ領域にレンダリングされた確率的にサンプリングされたシーンをフィルタリングするために、特別なフィルタが提供される。このオペレーションは、オフスクリーンのスーパーサンプリングされたレンダリング・ソースからオンスクリーンのピクセル表示宛先までのフィルタを使用する、特殊な「フレーム・バッファ間コピー」である。
【０１２８】
図１３〜１５は、サンプル・フィルタリングのためのアドレス生成およびフットプリントを示す図である。
【０１２９】
スーパーサンプル・フィルタ・アドレッシング。ソース領域および宛先領域は、ＣＯＰＹ＿｛Ｘ，Ｙ｝、ＲＥＣＴ＿｛Ｘ，Ｙ｝、およびＲＥＣＴ＿｛Ｈ，Ｗ｝によって再度定義される。ソースはフレーム・バッファのスーパーサンプリングされた領域にあり、宛先はフレーム・バッファのピクセル領域に常駐する。
【０１３０】
単一のソース・ポイントの代わりに、フィルタ「カーネル」領域（たとえば一実施形態では、ソース空間で、各宛先アドレスに対応するソース・アドレスを中心とし、半径が最高２ピクセルのディスク形領域）が読み取られる。ソース・アドレスがソース領域のエッジ上またはその直近にある場合、カーネルの一部がソース領域の外に出る可能性がある（図１３のサンプル「ｓ」を参照）。ソース領域の外に出るカーネルの一部のソースは、ＳＳＦ＿ＭＯＤＥ＿ＢＯＲＤＥＲによって決定される。
【０１３１】
スーパーサンプル・フィルタ・プログラミング・モデル。スーパーサンプル・フィルタリングには、宛先スペース内のピクセルに対応する、ソース・スペース（ビン・スペースとも呼ばれる）内の位置を中心とした、フィルタ・サポート領域内に収まるすべてのサンプルのカラー（ｒｇｂａ）の重み付けされた合計を算出することが含まれる。（ソース・スペース内のピクセルもビンと称されることに留意されたい。）
【０１３２】
それぞれの出力ピクセルについて、ハードウェアはソース・スペース内のカーネル中心（すなわちフィルタ・サポートの中心）を算出する。ただし、第１（または左最上部）のカーネル中心の位置は、ソフトウェアによってＲＥＣＴ＿｛Ｘ，Ｙ｝に設定される。オプションで、ＳＳＦ＿ＭＯＤＥ＿ＯＦＦＳＥＴ＿ＥＮＡＢＬＥ（「スーパーサンプル・フィルタ・モード・オフセット実行可能レジスタ」）を使用して、（０．５，０．５）だけオフセットすることができる。カーネル中心用のその後の座標は、ハードウェア・アクセラレータにより、ＳＳＦ＿ＳＴＥＰ＿ＳＩＺＥレジスタ（「スーパーサンプル・フィルタ・ステップ・サイズ・レジスタ」）を使用して増分で算出される。これは、ＸおよびＹの両方向に沿ったｓｔｅｐ＿ｓｉｚｅであってよい。
【０１３３】
拡大比率。宛先領域は、ソース領域に等しいかまたはこれより大きくてよい。宛先幅対ソース幅の比率が、拡大比率と呼ばれる。これは、ＳＳＦ＿ＳＴＥＰ＿ＳＩＺＥの値を選択することによって、間接的に指定することが可能であり、その結果、拡大比率は１．０／ＳＳＦ＿ＳＴＥＰ＿ＳＩＺＥとなる。
【０１３４】
フィルタ・タイプ。一実施形態では、スーパーサンプル・フィルタが使用するフィルタ機能は、ボックス・フィルタまたは円形フィルタのいずれかであってよい。この選択は、ＳＳＦ＿ＭＯＤＥレジスタで指定される。フィルタの半径は、本明細書ではＳＳＦ＿ＦＩＬＴＥＲ＿ＲＡＤＩＵＳと称されるレジスタで指定することができる。
【０１３５】
ボックス・フィルタ。ボックス・フィルタは正方形のフィルタである。長さ寸法がフィルタ半径、ＳＳＦ＿ＦＩＬＴＥＲ＿ＲＡＤＩＵＳの２倍である。各サンプルに、同じ（最大）重さが与えられる。このフィルタは、カーネルによってカバーされるサンプル・ポイントのカラーの平均を取る。
【０１３６】
図１４は、ボックス・フィルタの場合の、ＳＳＦ読取り「フットプリント」（すなわち、サンプルを１つのフィルタリング済みピクセルに与えるビンのセット）の概念を紹介する図である。図には２つの例が示されており、それぞれ半径が０．５である。
・オフセットが（０．５，０．５）でステップ・サイズが１．０（拡大なし）であれば、第１のピクセルについて（オフセットにより）、ならびに他のすべてのピクセルについて（ステップ・サイズにより）、ソース・スペースでのフットプリントは１×１である。これが図１４の左側に図示されている。
・ただし、拡大比率が１．０より大きいか、またはオフセットが（０．５，０．５）でない場合、図１４の右側に示されるように、フットプリントは一般に２×２となる。右側の場合は、左側の場合よりもゆっくりと実行される。
【０１３７】
円形フィルタ。名前からわかるように、このフィルタのカーネルはソース・スペースにおいて円形である。それぞれ半径が２．０の２つの例が、図１５に示されている。左の例は、現在のカーネル中心がビンの左隅にある場合に対応する。これは、オフセットが（０．０，０．０）であり、拡大比率が１．０である場合に対応する。
【０１３８】
図１５の右側の例は、現在のカーネル中心がビンの左隅にない場合に対応する。これは、たとえ初期オフセットが（０．０，０．０）であっても、拡大比率が１．０でない場合に対応する。カーネル・サークル（すなわちディスク）内にあるすべてのサンプルが、重み付け合計に寄与する。タイル（たとえば２×２タイルのビン）内のサンプルの位置は、本明細書ではＳＳＦ＿ＪＩＴＴＥＲ ＴＡＢＬＥと称されるスーパーサンプル・ジッタ・テーブルで指定される。これらのジッタ値は、最終サンプル位置に到達するために、必要であれば置き換えることができる（詳細は本項の最後で説明）。各サンプル位置でのフィルタ重みは、そのカーネル中心からの半径距離に依存する。
【０１３９】
フィルタ重みは、半径距離ｒの関数を表すものである。一実施形態では、フィルタ重みは１２８個の値のテーブルで提供され、それぞれの重みは範囲（−１．０，１．０）であり、フォーマットｓ．１０である。テーブルは（ｎｒ）２で索引付けすることができる。これは、アクセス速度が速く、ゲート・カウントが少ない、ハードウェア・フレンドリに設計される。ここでｎｒは単に正規化された半径距離、ｒ／Ｒであり、ｒはカーネル半径である。
・サンプル密度、すなわちビンあたりのサンプル数。
・置換え制御。実行可能であれば、ソース・スペース・タイル内のサンプル（１タイルは２×２平方ビン）が置き換えられ、その結果１２８×１２８ビン境界でのみ複製されるように発生し、その他の場合にはサンプルは２×２ビンごとに複製される。
・一時エイリアス除去用の置換えコード（範囲［０，７］）。これにより、各フレームで最高８つの異なるパターンを可能にするために、置換えコードに応じて各フレームで様々なタイルの置換えが可能になる。
使用される実際のサンプルは、ＳＳＦ＿ＳＡＭＰＬＥ＿ＭＡＳＫで選択することができる。
【０１４０】
コピー・オペレーションの詳細な説明
コピー・オペレーションは、ＦＢまたはＴＢのいずれかからＦＢまたはＴＢのいずれかへ、四角形のピクセル・アレイを移動する。これには、２つの２−Ｄアドレス（すなわちソースおよび宛先）が含まれる。ソフトウェアは、ソースと宛先の四角形をプリクリップする。
ソース・データは、以下のいずれかであってよい。
・フレーム・バッファ・メモリ（ＦＢ）からのピクセル
・オンスクリーン（可視）フレーム・バッファからのピクセル
・オフスクリーン・ピクセル・バッファからのピクセル
・フレーム・バッファ・メモリ（ＦＢ）からのサンプル
・オフスクリーン・スーパーサンプル・バッファからのサンプル
・テクスチャ・バッファ・メモリ（ＴＢ）からのピクセルまたはテクセル
・テクスチャ・マップからのテクセル
・イメージ・バッファからのピクセル
データは、以下のいずれかにコピーすることができる。
・ピクセルをフレーム・バッファ・メモリ（ＦＢ）へ
・ピクセルをオンスクリーン（可視）フレーム・バッファへ
・ピクセルをオフスクリーン・ピクセル・バッファへ
・ピクセルをテクスチャ・バッファ・メモリ（ＴＢ）へ
・ピクセルをテクスチャ・マップへ
・ピクセルをイメージ・バッファへ
【０１４１】
以下の考察で使用されるいくつかの頭字語の凡例を示す。
ＦＷＱ＝フレーム・バッファ書込み待ち行列
ＦＲＱ＝フレーム・バッファ読取り待ち行列
ＴＷＱ＝テクスチャ・バッファ書込み待ち行列
ＴＲＱ＝テクスチャ・バッファ読取り待ち行列
ＴＲＢ＝テクスチャ・バッファ読取りバッファ
【０１４２】
スパン・ウォーカ・ユニット（ＳＷ）は２つのアドレスを生成する。ＳＷユニットはＴＢアドレスをＴＡブロックに送信し、これがＴＢＭおよびＴＢＩ（テクスチャ・バッファ・インターフェース）に供給する。ＳＷは、ＳＧ、ＳＥ、ＦＤＰを介してＦＢアドレスをＴＥに送信し、これがＦＰおよびＦＢＩに供給する。ソース・アドレスは、ＦＢまたはＴＢ読取り待ち時間をカバーする十分な先取りを可能にするために、宛先アドレスの前（たとえば一実施形態では約４０〜６０クロック前）に生成することができる。
【０１４３】
ソース・データは、ＦＲＢブロックまたはＴＲＢブロックからＰＸＭに読み取られ、ピクセル転送ユニット（ＰＸ）に供給される。ＰＸユニットは、データの再フォーマット、スケーリング、バイアス、および／または検索（すなわちテーブル・ルックアップの実行）を実行することができる。ＰＸ結果データは、ＴＥまたはＴＢＭ（それぞれＦＢまたはＴＢのコピー宛先の場合）に送信される。ＴＥまたはＴＢＭは、（ＳＷ読取りアドレスによって指定された）ＰＸ読取りデータがＳＷ書取りアドレスと一致する、「結合」ポイントである。書込みアドレスが（ＳＷまたはＴＡから）着信する前に書込みデータが（ＰＸから）着信するか、またはその逆の場合、ＴＥ／ＴＢＭは、ＰＸまたはＳＷのいずれか前の方を、後のユニットの準備が整うまでストールすることになる。以下のようないくつかの特殊なケースがある。
【０１４４】
・同じバッファ間でのコピー（ＴＢからＴＢ、またはＦＢからＦＢ）により、ソース領域と宛先領域が重なり合うがある。したがってアドレス・スキャン・パターンは、コピーが発生する前にソースが重なり合うのを防ぐために、昇順および降順の両方でのオペレーションが可能である。
【０１４５】
・フレーム・バッファ（ＦＢ）２２が宛先である場合、フラグメント処理はフレーム・バッファへの途中で実行することができる。
【０１４６】
・一部の実施形態では、フレーム・バッファがソースの場合、ソース領域が読み出されたときの状態にクリアされるように要求することができる。これは、コピー・オペレーションと並行して、読み出されたときの状態のソース領域に対して高速フィル・オペレーションを効率的に実行する。
【０１４７】
・一実施形態では、異なるバッファ間（ＴＢからＦＢ、またはＦＢからＴＢ）でのコピーが、ＧＣＫあたり１ピクセルで発生可能であり、パイプライン化される。ＳＷはｘ，ｙフィールド（フル・タイルの場合）を介してＦＢアドレスを指定することが可能であり、ＴＡユニットからのｕ，ｖ出力を介してＴＢアドレスを指定する。
【０１４８】
・同じバッファ間（ＴＢからＴＢ、またはＦＢからＦＢ）でのコピーの場合、ＴＢおよびＦＢがそれぞれ単一のアドレス・バスを有することから、ＳＷは、書込みのバーストと交互に読取りのバーストを生成する。バースト・サイズは、ＦＢおよびＴＢ読取りパイプラインの待ち時間（一実施形態では、およそ３０〜４０ＧＣＫと推定される）によって決定することが可能であり、（パイプ・ステージにＦＷＱ／ＦＲＱまたはＴＷＱ／ＴＲＱ深さを加えた）ＦＢおよびＴＢパイプライン深さの有効小数であってよい。バーストが大きいほど、メモリ・データ・バス方向を転換させるオーバヘッドを減らし、メモリ・リフレッシュ・バブルを隠して待ち時間を制御するのを助ける。ただし、バースト・サイズがメモリ読取りパイプラインの深さを超えた場合に、デッドロックが発生する可能性がある。
【０１４９】
・一実施形態では、８、１６、または３２ビット・ピクセル・フォーマットの畳み込みおよびコピーは、１つの「ＴＢをＴＢにコピー」コマンドまたは１つの「ＴＢをＦＢにコピー」コマンドで、最高４つの構成要素（Ｒ、Ｇ、Ｂ、Ａ）をサポートすることができる。
【０１５０】
・より大きなピクセル・フォーマットの畳み込みおよびコピーには、複数のコピーが必要になる場合がある。たとえば、６４ビット・ピクセル・フォーマットの構成要素は、２つの別々のコピー・コマンドで転送することができる。
【０１５１】
・イメージ変換は、コピー・オペレーションの代わりに、イメージを四角形（補間済みＲＥＣＴＡＮＧＬＥコマンド）またはＴＲＩＡＮＧＬＥストリップにテクスチャ・マッピングすることによって達成可能である。ハードウェア・アクセラレータ１８は、ＴＢからＦＢへのイメージ変換をサポートすることができる。
【０１５２】
・立体モードに関するＦＢからＦＢへのコピーは、片目のみ（左または右）のコピー、または両目のコピーという、２つの特色で実行することができる。
【０１５３】
・ピクセルあたりの選択サンプルが１つのループでコピーされる場合、スーパーサンプル・モードでコピーする。
【０１５４】
コピー・フォーマットおよび宛先
コピーのソース、宛先、およびフォーマットは、ＲＰ＿｛ＲＤ，ＷＲ，ＲＷ｝＿ＰＤＴレジスタおよびＲＰ＿｛ＲＤ，ＷＲ，ＲＷ｝＿ＴＩＦレジスタで定義される。ＲＰ＿ＲＤ＿ＰＤＴレジスタの＿ＴＥＸフィールドはコピーされるデータのソースを定義し、ＲＰ＿ＷＲ＿ＰＤＴレジスタの＿ＴＥＸフィールドは宛先を定義する。
・ＳＷは、レジスタによって指定されたソースおよび宛先を使用して、ソースおよび宛先のアドレスを適切に送る。
・ＰＸは、レジスタによって指定されたソースおよび宛先を使用して、受信したデータを適切に送る。
【０１５５】
コピー・メカニズムは、コピー・データ経路のパイプライン段階およびデータ待ち行列（およそ１００のサンプルまたはピクセルについて）でのデータ記憶要素を利用するように編成される。コピー・データ経路には、ＦＲＢ、ＴＥ、ＰＸ、ＦＰ、ＦＷＱ、ＦＢＩが含まれる。
ＦＲＢ：フレーム・バッファ読取りバッファは、ＦＢメモリから読取られるデータ用のバッファである。
ＦＷＱ：フレーム・バッファ書込み待ち行列は、ＦＢメモリ要求（アドレスおよびデータの書込み、またはアドレスの読取り）の待ち行列である。
ＦＢＡ：フレーム・バッファ・アドレッシング・ユニットは、Ｘ，Ｙアドレスをメモリ・ページおよびピクセル／サンプル・アドレスにマッピングする。
ＦＢＩ：フレーム・バッファ・インターフェースはＦＢメモリ制御装置であり、ＤＭＤキャッシュ（たとえば３ＤＲＡＭキャッシュ）、グローバル・バス、およびＤＲＡＭページ制御を含む。
【０１５６】
多くの実施形態では、フィルタ中央アドレスを備えたコピー読取りオペレーション・コードのバッチを、ＴＥ「結合」ポイント（コピー読取りオペレーション・コードおよびアドレスの結果として生じるフィルタリング済み読取りデータが、コピー書込みオペレーション・コードおよびアドレスとペアになる）でデッドロックすることなく、できる限り多く発行し、その後、（フィルタリング済みピクセル・データを、ＦＢの表示領域に書き込むようにＦＰ方向に下方送信する）表示ピクセル・アドレスを備えたコピー書込み要求の合致バッチの発行に切り替えるものであって、このプロセスはすべてのサンプルがフィルタリングされるまで繰り返される。
【０１５７】
図１６は、ソース・アドレス、宛先アドレス、データ、ならびに結合アドレスおよびデータ流れが強調された、ＦＢからＦＢのコピー・オペレーションを示す図である。
【０１５８】
図１７は、スーパーサンプル読取りパス（スーパーサンプル・バッファからフレーム・バッファ）でのオペレーション・コード流れを示す図である。
【０１５９】
図１８は、サンプル・フィルタリングおよびバック表示バッファへのコピーのステップを要約した図である。
・スパン・ウォーカＳＷは、読取りサンプル、フィルタ・サンプル、および書込みピクセルの要求およびアドレスを生成する。読取りおよびフィルタリング要求の各バーストの後には、書込み要求のバーストが続く。
・ＴＥユニットは、読取りサンプルおよびフィルタ・サンプル要求を、フラグメント・パイプを通じてＦＢメモリ２２のサンプル・バッファに渡す。
・ＦＲＢは、フィルタ・フットプリントが単一のピクセルよりも大きいときに、前の円形フィルタ・オペレーションから重なり合うサンプルを再使用できるようにするための、サンプル読取りバッファを含む。
・サンプル・フィルタは、サンプルの畳み込みによって、フィルタリング済みピクセルを生成する。ＲＧＢ結果は、構成要素あたり最高１２ビットまで可能である。
【０１６０】
ピクセルを生成するためのサンプルのフィルタリングに関する詳細については、参照により全文が本明細書に組み込まれた、２００１年１０月３日付け出願のＢｕｒｋ等による「Ｐｒｏｇｒａｍｍａｂｌｅ Ｓａｍｐｌｅ Ｆｉｌｔｅｒｉｎｇ ｆｏｒ Ｉｍａｇｅ Ｒｅｎｄｅｒｉｎｇ」という名称の米国特許出願第０９／９７００７７号を参照されたい。
・ピクセル転送ユニットＰＸは、フィルタリング済みピクセル・データを処理し、ガンマ補正を適用する。
・ＰＸピクセル・データは、ＳＷ書込みアドレスおよびオペレーション・コードとペアにされ、フラグメント・パイプラインを介して、ダブル・バッファされたＦＢメモリの「バック」表示バッファ領域まで送信される。
【０１６１】
２．２．４ バックおよびフロント表示バッファのスワップ
フィルタリング・オペレーションが完了し、フィルタリング済みフレーム・シーンが「バック」表示バッファに入ると、「フロント」と「バック」のバッファ割当てを交換するために「表示バッファのスワップ」オペレーションが実行され、その結果、新しいフレームが可視となり、プロセスが繰り返されるときに次のフィルタリング・フレームを受け取るために、古いフレームの表示バッファが使用可能になる。
【０１６２】
バッファ・スワップ・オペレーションは、新しいＷＩＤ（ウィンドウＩＤ）エントリをウィンドウ・ルックアップ・テーブル（ＷＬＵＴ）に記入することによって実施できる。
【０１６３】
図１９は、表示ステップを要約した図である。ビデオ出力プロセッサ２４（たとえばＸチップ）は、表示バッファのフロント・セグメントからピクセルを読み取り、そのピクセルをＲＧＢ ＤＡＣ（またはビデオ・エンコーダ）に送信する。ＲＧＢ ＤＡＣは、ピクセル・ストリームをアナログ・ビデオ信号に変換し、これが表示用のビデオ出力ポートに提供される。
【０１６４】
２．３ 変形形態
以上、サンプル・レンダリング・プロセス、サンプル・フィルタリング・プロセス、およびピクセル表示プロセスの基本的流れについて述べてきたが、次に、このテーマに関するいくつかの変形形態について論じる。
【０１６５】
２．３．１ フィルタリング済みピクセルの高精度ガンマ補正
以下の考察では、フレーム・バッファのサンプル・バッファが、サンプルあたりカラー構成要素あたり、Ｎｂｐｃ＝１０ビットまで格納することができると想定される。ただし、記載された原理は、パラメータＮｂｐｃの任意の正の整数値への一般化を認めるものである。
【０１６６】
図９に示されたレンダリング・ステップ中に、サンプル値は、ＦＢサンプル・バッファに格納できる構成要素あたり１０ビットよりもより多くのビット精度で知られる。オプションの「ディザリング」ユニットが、サンプル生成器ＳＧに含まれる。「ディザリング」オプションが実行可能であれば、Ｒ、Ｇ、およびＢのサンプル値を、サンプルのアドレスのサブピクセル部分（ＸおよびＹの小数部分）に基づき、１つのＬＳＢ（２−１０）によってディザリングすることができる。サンプル値の小数部には、１つのＬＳＢにＲ、Ｇ、またはＢが加えられることになる。ディザリング機能は、１ＬＳＢずつ増分されるピクセル・サンプル値の小数部を、最低位サンプル値ビットに比例させるものである。
【０１６７】
「サンプル・バッファのフィルタリング／コピー結果を表示バッファへ送る」ステップ（図１８）では、畳み込みオペレーションが「平均」効果を有する。ボックス・フィルタの場合、フィルタは等しく重み付けされたサンプル値の平均を精密に送ることができる。レンダリング・ステップによってサンプルの小数が１ＬＳＢずつ増えた結果、平均は、その小数掛ける１ＬＳＢずつ増えることになり、失われた情報が「回復」される。同じ引数がより複雑なフィルタに対してほぼ真となる。最終的な効果は、サンプル密度をそれぞれ倍にするためにおよそ１ビットを「回復」（または格納された１０ビット精度へ追加）することである。サンプル密度４またはそれ以上の場合、２ビットが回復可能であるため、サンプル・フィルタは、それぞれのカラー構成要素について１２の有効ビットをＰＸユニットに送信することができる。より一般的に言えば、回復可能ビット数はサンプル密度の２を底とする対数として変化する。
【０１６８】
ＰＸユニットには、Ｒ、Ｇ、およびＢに関する「１２ビット・イン：１０ビット・アウト」ルックアップ・テーブルが含まれる。これらは、（線形シェード付きサンプル値とモニタ／人間の眼の機構の非線形特性との相違を補正するための）ガンマ補正機能と共にロードすることができる。多くの従来技術のシステムでは、フレーム・バッファ内に構成要素あたり８ビットしか格納せず、ガンマ補正機能の非線形性により、濃いシェード付き領域ではさらに精度が失われ、これらのシステムでは濃いシェード付き領域が「マッハ・バンド」の量子化を受ける。本明細書に記載されたディザリング・メカニズムによって特別な２ビット入力が回復することで、より多くのフレーム・バッファ・メモリおよびより広いフレーム・バッファ・メモリ・バスにかかる追加のコストなしに、ほとんどのシステムで送ることができるよりも滑らかなイメージのシェーディングが生成される。
【０１６９】
ディザリング済みサンプルから精度を回復させるための平均化に関する詳細については、参照によりその全文が本明細書に組み込まれた、２００１年１月１１日付け出願のＤｅｅｒｉｎｇ等による「Ｒｅｃｏｖｅｒｉｎｇ Ａｄｄｅｄ Ｐｒｅｃｉｓｉｏｎ ｆｒｏｍ Ｌ−Ｂｉｔ Ｓａｍｐｌｅｓ ｂｙ Ｄｉｔｈｅｒｉｎｇ ｔｈｅ Ｓａｍｐｌｅｓ Ｐｒｉｏｒ ｔｏ ａｎ Ａｖｅｒａｇｉｎｇ Ｃｏｍｐｕｔａｔｉｏｎ」という名称の米国特許出願第０９／７６０５１２号を参照されたい。
【０１７０】
２．３．２ 立体ビジョン
立体ビジョン・システムは、１つは左目の視点から見たビュー、１つは右目の視点から見たビューという、シーンの２つのビューをレンダリングおよび表示する。これは、１回目は左目のパースペクティブ変換マトリクスを使用し、次に再度右目のパースペクティブ変換マトリクスを使用することで、同じシーン・ジオメトリを２回レンダリングすることによって達成される。２つのレンダリングは２つの異なる表示バッファに格納される。格納された２つのレンダリングは、２つのビデオ・チャネルによってそれぞれ表示することができる（たとえば「ゴーグル」ヘッド取付け型ディスプレイの場合）。オプションで、格納された２つのレンダリングを同じディスプレイ上に交互に表示することができる（たとえば、位相のずれた左目と右目の液晶「シャッタ」をディスプレイの更新と同期させる、立体眼鏡を使用して見る場合）。
【０１７１】
２つの表示バッファに関する要件により必要な表示メモリは増えるが、サンプル・バッファがスワッピングの前にフィルタリングされて表示バッファにコピーされる場合、サンプル・バッファ要件は増えない。これは、ビデオ・リフレッシュ時にフィルタリングし、それぞれの目に１つずつ、合計２つのサンプル・バッファを必要とするシステムの場合はあてはまらない。
【０１７２】
したがって本明細書で説明する「フィルタリングおよびコピー」の方法は、サンプル・バッファのメモリ要件を倍増させるような出費なしに、立体ビジョンをサポートするものである。
【０１７３】
２．３．３ フィルタリング時クリア
基本的なフレーム処理ループには、以下の形式がある。
【０１７４】
ループあたりの合計時間は、次のようになる。
ｃｌｅａｒ＿ｔｉｍｅ＋ｒｅｎｄｅｒ＿ｔｉｍｅ＋ｆｉｌｔｅｒ＿ｃｏｐｙ＿ｔｉｍｅ＋ｓｗａｐ＿ｔｉｍｅ
【０１７５】
サンプル・フィルタリングと並行したサンプル・バッファ・クリア・オペレーションの実行方法に関する教示については、参照によりその全文が本明細書に組み込まれた、Ｌａｖｅｌｌｅ等による「Ｐａｒａｌｌｅｌ Ｒｅａｄ ｗｉｔｈＳｏｕｒｃｅ−Ｃｌｅａｒ Ｏｐｅｒａｔｉｏｎ」という名称の２００２年１月３１日付け出願の米国特許出願第１０／０６６３９７号を参照されたい。
【０１７６】
ＦＢＩに注入された読取り／クリア／書込み機能（上記の出願に記載）を使用して、サンプル・バッファのフィルタリングとサンプル・バッファのクリアを組み合わせることにより、フレーム処理ループを高速化することができる。サンプル・バッファは、サンプルがサンプル・フィルタに読み込まれた直後にクリアされる。読取り／クリア／書込み機能を使用すると、フレーム処理ループは以下のようになる。
【０１７７】
これによりクリア時間をフィルタ時間と並行させるため、ループあたりの合計時間は次のようになる。
ｒｅｎｄｅｒ＿ｔｉｍｅ＋ｍａｘ（ｆｉｌｔｅｒ＿ｃｏｐｙ＿ｔｉｍｅ，ｃｌｅａｒ＿ｔｉｍｅ）＋ｓｗａｐ＿ｔｉｍｅ
【０１７８】
たいていのフィルタでは、クリア時間がフィルタ時間よりも短いため、クリア時間が「なし」になる。したがって、上式は以下のように簡略化できる。
ｒｅｎｄｅｒ＿ｔｉｍｅ＋ｆｉｌｔｅｒ＿ｃｏｐｙ＿ｔｉｍｅ＋ｓｗａｐ＿ｔｉｍｅ
【０１７９】
２．４ レンダリング性能パラメータ
様々な方法の性能を理解するには、何らかの主要な性能パラメータを定義することが役立つ。図２０は、レンダリング性能パラメータを要約した図である。以下の考察は、一実施形態に関して典型的な値を与えるものである。ただし、他の実施形態に様々な他の値も当てはめることができる。
【０１８０】
・頂点速度Ｒｖは、ホスト・プログラム・ホスト・インターフェース１１（たとえばＮＵＰＡバス）、メディア・プロセッサの変換／ライト／クリップ・マイクロコード、メディア・プロセッサ１４とハードウェア・アクセラレータ１８との間のインターフェース（たとえばＳＵＰＡバス）のうち最も遅いものによって制限される。頂点速度は、頂点タイプおよびライト（光）の数に応じて変化し、マイクロコードによって制限することができる。典型的なＲｖ値は３３Ｍ頂点／秒である。
【０１８１】
・分離された三角形は、１つの三角形に３つの頂点を有する。大きな三角形メッシュの場合、三角形あたりの頂点数は、０．５頂点／三角形の限界値に向かって減少する。長い三角形ストリップの場合、限界値は１頂点／三角形である。短い三角形ストリップの場合、頂点／三角形は１から３の間である。この考察では、長い三角形ストリップが想定される。
【０１８２】
・プリミティブ速度Ｒｐも、ラスタ化パイプラインＲＰによって制限することができる。典型的なＲｐ値は、３３Ｍ三角形／秒である。
【０１８３】
・ラスタライザのピクセル・シェーディング速度Ｒｚは、エッジ・ウォーカＥＷおよびスパン・ウォーカＳＷによって制限することができる。典型的なＲｚ値は６６６Ｍピクセル／秒である。
【０１８４】
・サンプル生成速度Ｒｓは、サンプル生成器ＳＧユニットおよびサンプル評価器ＳＥユニットによって制限することができる。典型的なＲｓ値は、「バディ（ｂｕｄｄｙ）」モードであると想定した場合に１３３３Ｍサンプル／秒であり、「バディ」モードなしの場合は６６６Ｍサンプル／秒である。
【０１８５】
・テクスチャ処理速度Ｒｔは主にテクスチャ・メモリ帯域幅およびテクスチャ・フィルタ・タイプ選択によって制限される。典型的なＲｔ値は、バイリニア・フィルタおよび１層テクスチャの場合に、１６６Ｍテクスチャ化ピクセル／秒である。より複雑なフィルタおよび／またはより多いテクスチャ層は、かなり低速になる可能性がある。
【０１８６】
・テクスチャ化サンプル（フラグメント）書込み速度Ｒｗは、フラグメント・パイプラインＦＰ（本明細書ではフラグメントプロセッサとも称される）、ＦＢインターフェース、およびＦＢメモリによって制限することができる。設計により、ＲｗはＲｓと同じ（「バディ」モードで１３３３Ｍサンプル／秒）になる。
【０１８７】
前述のように長い三角形ストリップを想定すると、三角形あたりの頂点数は１に近づき、その結果、三角形速度に関する頂点限界値およびラスタ化セットアップ制限値は、ほぼ以下に等しくなる。
Ｒｔｒｉ＝ｍｉｎ（Ｒｖ／１，Ｒｐ）＝３３Ｍｔｒｉ／ｓｅｃ
【０１８８】
サンプル・フィル速度は、サンプル生成器ＳＧ、テクスチャ処理ピクセル速度×サンプル密度、ラスタライザ・ピクセル速度×サンプル密度、およびフラグメント書込み速度のうち、最も遅いものによって制限することができる。ただし、ＲｗはＲｓと同じであり、ＲｚはＲｔよりはるかに大きいため、
Ｒｓｆｉｌｌ＝ｍｉｎ（Ｒｓ，Ｄ＊Ｒｔ，Ｄ＊Ｒｚ，Ｒｗ）＝ｍｉｎ（Ｒｓ，Ｄ＊Ｒｔ）
であって、Ｒｓ＝１３３３Ｍサンプル／秒（「バディ」モードであると想定）およびＲｔ＝１６６Ｍテクスチャ化ピクセル／秒（バイリニア・フィルタおよび１層のテクスチャであると想定）を付加すると、サンプル密度（Ｄ）が最高８の場合、サンプル・フィル速度は以下のようにテクスチャ速度制限される。
Ｒｓｆｉｌｌ＝ｍｉｎ（Ｒｓ，Ｄ＊Ｒｔ）＝ｍｉｎ（１３３３，１６６Ｄ）Ｍｓａｍｐ／ｓｅｃ
【０１８９】
シーン内のＰ個の三角形（残りのデータベースがホストによってビュー・フラスタム・カリングされたと想定する）、Ａｗウィンドウ領域、Ｃ深さ複雑性、およびＤサンプル密度を備えたフレームをレンダリングするための時間は、
ｒｅｎｄｅｒ＿ｔｉｍｅ＝ｍａｘ（ｔｒｉ＿ｔｉｍｅ，ｆｉｌｌ＿ｔｉｍｅ）
であり、上式では
ｔｒｉ＿ｔｉｍｅ＝Ｐ／Ｒｐ
ｆｉｌｌ＿ｔｉｍｅ＝（Ａｗ ＊Ｃ＊Ｄ）／ｍｉｎ（Ｒｓ，Ｄ＊Ｒｔ）
である。
【０１９０】
Ａｗウィンドウ領域およびＤサンプル密度を備えたフレームをレンダリングする前に、サンプル・バッファをクリアするための時間は、以下のようになる。
ｃｌｅａｒ＿ｔｉｍｅ＝Ｄ＊Ａｗ／Ｒｃ＝０．１８８ＤＡｗｎｓｅｃ
【０１９１】
２．５ フィルタリング性能パラメータ
図２１は、フィルタリング性能パラメータを示す図である。
【０１９２】
・サンプル読取り速度Ｒｒは、ＦＢインターフェースおよびＦＢメモリによって制限することができる。典型的なＲｒの値は、３３３Ｍサンプル／秒である。
【０１９３】
・サンプル・フィルタ・ピクセル速度Ｒｆは、サンプル読取りバッファ内のフィルタ・フットプリント、サンプル密度、およびキャッシング量によって制限することができる。
【０１９４】
・ピクセル結果に精密に一致するフットプリントを備えた、単純な拡大していないボックス・フィルタの場合、フィルタ速度は、読取りサンプル速度Ｒｒをサンプル密度Ｄで割った値に制限することができる。
【０１９５】
・拡大されたボックスおよび円形フィルタの場合、畳み込み計算に関係するサンプルの数は、フットプリント半径の２乗と共に増加し、読み取られるサンプル数は半径に比例して増加する。半径が増加すると畳み込み計算が障害となる可能性があり、より複雑なフィルタの場合、フィルタ速度は２分の１またはそれ以上に低下する可能性がある。この性能に関する考察は、高速ボックス・フィルタの場合に限定される。
【０１９６】
・フラグメント書込み速度Ｒｗは、フィルタ／コピー速度を低下させる、結果を表示バッファに書き込むための時間を設定する。ピクセルを書き込む場合、この速度は６６６Ｍピクセル／秒であってよい。
【０１９７】
拡大されていないボックス・フィルタの場合に、結果をフィルタリングおよびコピーするための合計時間は、
ｆｉｌｔｅｒ＿ｔｉｍｅ＝（Ａｗ ＊Ｄ／Ｒｒ）＋（Ａｗ／Ｒｗ）
ｆｉｌｔｅｒ＿ｔｉｍｅ＝（３Ｄ＋１．５）Ａｗｎｓｅｃ
となり、これは、サンプル密度が高くなると３ＤＡｗに近づく。
【０１９８】
３．０ ウィンドウ・サイズあたりのサンプル・バッファ（ＳＢ）の動的割振り
ＦＢメモリ内のサンプル・バッファのサイズは、ウィンドウ・サイズの変化に応答して動的に調整することができる。
【０１９９】
・Ｗｄ×Ｈｄピクセルの表示の場合、ＦＢには、少なくともＷｄ×Ｈｄ（典型的にはこれよりわずかに多い）の（ダブル・バッファされた）ピクセル表示バッファ・メモリが必要である（すなわち、ピクセル単位のほぼ表示サイズ）。
【０２００】
・ウィンドウ・システムでは、全画面サイズよりも小さいウィンドウにレンダリングすることが多い。ＷＷ×ＨＷピクセルのウィンドウでは、ＦＢには、少なくともＤＳ×ＷＷ×ＨＷ（典型的にはこれよりわずかに多い）の（単一バッファ付き）サンプル・バッファ・メモリが必要である（すなわちほぼウィンドウ・サイズ×サンプル密度）。
【０２０１】
・ＦＢメモリの容量が有限（一実施形態では５２０万サンプル／ピクセルのメモリ）であり、ＦＢメモリは表示バッファとサンプル・バッファとで共用されるため、最大サンプル密度は、ほぼ以下の整数下限である。
｛（ピクセル／サンプル単位のＦＢサイズ−ピクセル単位の表示サイズ）÷（ピクセル単位のウィンドウ・サイズ）｝
【０２０２】
・これは、解像度の低い表示および／またはサイズの小さいウィンドウでも、固定サイズのフレーム・バッファで高いサンプル密度をサポートできることを意味する。
【０２０３】
したがって、ホスト・コンピュータ上で実行中のソフトウェアは、現在のウィンドウ・サイズを監視し、固定サイズのフレーム・バッファを最大限に活用するようにサンプル密度を自動的に調整することができる。ユーザが小さなウィンドウ・サイズを選択する（またはそのサイズに変更する）と、グラフィックス・レンダリング・システムの適切なハードウェア・レジスタのセットに書き込むことによって、ホスト・ソフトウェアはサンプル密度を高く調整することが可能であり、またその逆も可能である。
【０２０４】
ハードウェア・アクセラレータ１８は、ピクセル領域あたりで生成されるサンプル数を制御する、１つまたは複数のサンプル密度レジスタを有することができる。サンプル生成器ＳＧは、サンプル密度フィールドを備えた制御レジスタを有することができる。サンプル密度フィールドは、ピクセル領域あたりで生成されるサンプル・ポジションの数を決定する。フレーム・バッファ・アドレッシング・ユニット（ＦＢＡ）は、フラグメント・アドレスをメモリ・ページおよびデータ・アイテムアドレスにマッピングする責務を負っており、マッピングがサンプル密度に依存するため、サンプル密度レジスタを有することができる。サンプル・フィルタはサンプル密度レジスタを有することができるため、そのフィルタリング・オペレーションのためにピクセル領域あたり適切な数のサンプルを取り込むことができる。サンプル密度レジスタは、動的に調整可能である。
【０２０５】
ホスト・ソフトウェアは、サンプル密度を変更するために、ハードウェア・アクセラレータ内の１つまたは複数のサンプル密度レジスタに書き込むことができる。一実施形態では、ホスト・ソフトウェアはすべてのサンプル密度レジスタに同じ値を書き込む。
【０２０６】
ウィンドウのサイズは全画面よりも小さい場合が多い。したがって、ユーザがより大きなウィンドウを選択すると、よりピクセルの多い解像度が得られるため、イメージ品質を上げることができる。
【０２０７】
それとは逆に、ユーザがウィンドウを小さくすると、動的割振りメカニズムはピクセルあたりのサンプル数を多くして、イメージ品質を維持する。
【０２０８】
本明細書で使用される「マルチサンプル」という語は、「スーパーサンプル」と同じ意味である。
【０２０９】
２．１．３項の例で示されるように、（サンプル・バッファを画面全体に対応するように設定しようとするのではなく）サンプル・バッファ・サイズをウィンドウ・サイズに合わせて調整すると、サンプル密度を大幅に増加させることができる。１２８０×１０２４表示の場合、ほぼ全画面のウィンドウは１パスで２サンプル／ピクセルをサポートすることが可能であり、１０００×１０００ウィンドウは３サンプル／ピクセル、７２０×６７０は８サンプル／ピクセルがサポート可能であって、かなり品質が良い。
【０２１０】
サンプル密度を最高にするためにサンプル・バッファ・メモリを動的に割り振るこのメカニズムは、以下の項で述べるメカニズム、すなわち、高いサンプル密度および／または立体ビジョンのための複数のパスと組み合わせることができる。動的メモリ割振りと複数パス・レンダリングの組合せにより、ユーザは、目標とする品質レベル（たとえば所望のサンプル密度）を指定することが可能であり、システムは、現在のウィンドウ・サイズを考慮して、その目標とする品質レベルを達成するのに必要なフレームあたり最小数の（または最小数に近い）パスを実行する。あるいは、ユーザは最低性能目標（たとえば最大フレーム・レンダリング時間）を指定することが可能であり、システムは、最低性能ターゲットよりも上の性能を維持しながら（たとえば、最大フレーム・レンダリング時間内でフレームをレンダリングしながら）、可能な最高サンプル密度を送る。
【０２１１】
４．０ 立体ビジョンのためのサンプル・バッファの再使用
立体ビジョン（２．３．２項に記載）の一般的な一方法は、１回目は左目のパースペクティブ変換マトリクスを使用し、次に再度右目のパースペクティブ変換マトリクスを使用することで、同じシーン・ジオメトリを２回レンダリングすることによって達成される。２つのレンダリングは２つの異なる表示バッファに格納され、同じディスプレイ上に交互に表示することができる（たとえば、位相のずれた左目と右目の液晶「シャッタ」をディスプレイの更新と同期させる、立体眼鏡を使用して見る場合）。
【０２１２】
表示バッファが２つあると、より多くのフレーム・バッファ・メモリを消費する。ただし、本明細書に記載された「フィルタリング後コピー」方法（すなわちサンプルをオフスクリーン・サンプル・バッファにレンダリングし、サンプル・バッファからバック・ピクセル表示バッファにフィルタリングし、その後表示バッファ切替えを実行する方法）は、サンプル・バッファ要件を増やすことがない。したがって、サンプル・バッファ・メモリを倍増させるような出費なしに、立体ビジョンをサポートすることができる。
【０２１３】
図２２は、立体表示のためのサンプル・バッファの再使用を示す図である。
【０２１４】
ホスト・ドライバ・ルーチンは、ＦＢメモリ内で左および右の表示バッファを割り振った後に、残りのＦＢメモリを単一の再使用可能サンプル・バッファとして割り振ることができる。ソフトウェア・アプリケーション（ホスト・コンピュータ上で実行中）は、以下のレンダリング・ループを実施することができる。
この方法により、固定のサンプル・バッファ・サイズについてサンプル密度が２倍になる。
【０２１５】
５．０ 増加したサンプル密度のためのＳＢの再使用
サンプル・バッファ容量は、表示バッファ要件を差し引いた後で残ったフレーム・バッファ・メモリを決して超えることはない。所与のサイズのウィンドウでは、１つのレンダリング・パスでサポートできる最大のサンプル密度を限度としている。
【０２１６】
しかし、本明細書に記載された「フィルタリング後コピー」方法を使用すれば、グラフィックス・アプリケーションがサンプル・バッファを再使用して、サンプル・バッファ・メモリ・サイズを増やすことなく、より高いサンプル密度を達成することができる。グラフィックス・アプリケーションは、グラフィックス・レンダリング・システムを使用して、（単一パスでシーン全体がレンダリングされるよりも）高いサンプル密度で、パスあたり１領域、複数パスのシーン内で複数の領域をレンダリングし、表示バッファをスワッピングする前にリア表示バッファでシーン全体を構築することができる。
【０２１７】
この方法により、より多くのレンダリング・パスを高いサンプル密度と交換することができる。この方法は、（ｓｃｒｅｅｎ＿ｒｅｓｏｌｕｔｉｏｎ）ダブル・バッファされたメモリに、以下のサイズのサンプル・バッファ・メモリを加えたものを使用する。
（ｓａｍｐｌｅ＿ｄｅｎｓｉｔｙ＊ｗｉｎｄｏｗ＿ｓｉｚｅ／ｎｕｍｂｅｒ＿ｏｆ＿ｐａｓｓｅｓ）
【０２１８】
５．１ アルゴリズム
図２３は、高いサンプル密度を達成するための固定サイズのサンプル・バッファの再使用を示す図である。
【０２１９】
ＦＢメモリで表示バッファを割り振った後、ホスト・ソフトウェア（たとえばホスト・ドライバ・ルーチン）は、残ったＦＢメモリを単一の再使用可能サンプル・バッファとして割り振ることができる。ホスト・ソフトウェアは、バック表示バッファをＮ個の隣接する領域に分割することが可能であり、ここでＮはシーン・フレームあたりに実行されるパスの数である。したがってＮは、１より大きいかまたは等しい整数である。表示メモリ割振りページの形状（その一実施形態が、図６の表に例示されている）により、表示バック・バッファをほぼ同じサイズのＮ個の領域に分割することが有利である。次にグラフィックス・アプリケーションは、以下のレンダリング・ループを実行することができる。
サンプル・バッファへのレンダリングは所望のサンプル密度で実行され、これはパスが１つしか使用されない場合に可能な密度のＮ倍まで可能である。
【０２２０】
２．１．２項に示されるように、ドライバ・ソフトウェアは、整数のＦＢメモリ・ページ・サイズに切り上げるため、およびサンプル・フィルタ（一定のモードの）は領域からはみ出すフットプリント（またはサポート領域）を有することができる（たとえば領域のエッジ上またはエッジ付近のピクセルを計算する場合）ため、領域サイズ（すなわち、サンプル密度×ウィンドウ幅×ウィンドウ高さ）よりも１ビット大きいサンプル・バッファを割り振ることが可能である。単純な拡大されていないボックス・フィルタ（単一ピクセルの領域をカバーする）の場合、特別な境界線は不要である。
【０２２１】
５．２ サンプル密度の例
・単一ヘッドの１２８０×１０２４の非立体表示の場合、表示バッファは（ｃｅｉｌｉｎｇ（１２８０／３２０）＊ｃｅｉｌｉｎｇ（１０２４／１６））＝２５６ページのＦＢメモリを使用する。これで（１０２４−２５６）＝７６８ページがサンプル・バッファ用に残される。
（ｃｅｉｌｉｎｇ（９６０／８０）＊ｃｅｉｌｉｎｇ（９００／１６））＝６８４ページであり、７６８ページよりも少ないため、単一のパスは、サンプル密度４で９６０×９００ピクセルのウィンドウをサポートすることができる。
（ｃｅｉｌ（９６０／４０）＊ｃｅｉｌ（４５０／１６））＝６９６ページであり、７６８ページよりも少ないため、２つのパスは、サンプル密度８で９６０×９００ピクセルのウィンドウをサポートすることができる。
（ｃｅｉｌ（９６０／４０）＊ｃｅｉｌ（２２５／８））＝６９６ページであり、７６８ページよりも少ないため、４つのパスは、サンプル密度１６で９６０×９００ピクセルのウィンドウをサポートすることができる。
【０２２２】
・単一ヘッドの９６０×６８０の立体表示の場合、表示バッファは（ｃｅｉｌ（９６０／３２０）＊ｃｅｉｌ（６８０／８））＝２５５ページのＦＢメモリを使用する。これで（１０２４−２５５）＝７６９ページがサンプル・バッファ用に残される。
（ｃｅｉｌ（９６０／８０）＊ｃｅｉｌ（６８０／１２））＝６８４ページであり、７６９ページよりも少ないため、単一のパスは、サンプル密度５で９６０×６８０の全画面表示をサポートすることができる。
（ｃｅｉｌ（９６０／４０）＊ｃｅｉｌ（３４０／１２））＝６９６ページであり、７６９ページよりも少ないため、２つのパスは、サンプル密度１０で９６０×６８０の全画面表示をサポートすることができる。
（ｃｅｉｌ（９６０／４０）＊ｃｅｉｌ（２２７／８））＝６９６ページであり、７６９ページよりも少ないため、３つのパスは、サンプル密度１６で９６０×６８０の全画面表示をサポートすることができる。
【０２２３】
５．３ 性能分析
ホスト・アプリケーションは、所与の各パスで使用される領域と一致するようにビュー・フラスタムを設定することができる。したがって、シーンの中で表示バッファ内の現在の領域に投影されない部分は、クリッピングされることになる。この方法を使用すると、領域サイズが小さくなるにつれて、各パスのレンダリングおよびフィルタリング時間が少なくなる。高いサンプル密度でシーン全体（Ｎ個の領域すべて）をラスタ化およびフィルタリングするための合計時間が、より多くのメモリを備えたより高価なシステムで高いサンプル密度での単一パスにかかる時間に近づけることができることに留意されたい。
【０２２４】
バッファ・クリア時間。ウィンドウ領域ＡＷおよびサンプル密度Ｄのフレームをレンダリングする前に、サンプル・バッファをクリアするための時間は、（少なくとも一部の実施形態では）以下の式で概算することができる。
ｃｌｅａｒ＿ｔｉｍｅ＝Ｄ＊ＡＷ／ＲＣ＝０．１８８ＤＡＷｎｓｅｃ
【０２２５】
グラフィックス・アプリケーションが、それぞれ領域ＡＷ／Ｎ、サンプル密度Ｎ＊Ｄで、Ｎ個のパスをＮ個の対応する領域に流入させると、合計クリア時間（Ｎ個のパスについて）は、サンプル密度比率（ＮＤ／Ｄ）に比例して以下のように増加する。
ｃｌｅａｒ＿ｔｉｍｅ＝Ｎ＊Ｄ＊ＡＷ／ＲＣ＝０．１８８ＮＤＡＷｎｓｅｃ
【０２２６】
フィルタリング／コピー時間。２．５項から、拡大されていないボックス・フィルタについての結果をフィルタリングおよびコピーするための合計時間は、以下の通りであることを想起されたい。
ｆｉｌｔｅｒ＿ｔｉｍｅ＝（ＡＷ ＊Ｄ／Ｒｒ）＋（ＡＷ／ＲＷ）
ｆｉｌｔｅｒ＿ｔｉｍｅ＝（３Ｄ＋１．５）ＡＷｎｓｅｃ
【０２２７】
グラフィックス・アプリケーションが、それぞれ領域ＡＷ／Ｎ、サンプル密度Ｎ＊Ｄで、Ｎ個のパスをＮ個の対応する領域に流入させると、合計フィルタリング／コピー時間（Ｎ個のパスについて）は、サンプル密度比率（ＮＤ／Ｄ）に比例して以下のように増加し、
ｆｉｌｔｅｒ＿ｔｉｍｅ＝Ｎ＊（３ＮＤ＋１．５）（ＡＷ／Ｎ）ｎｓｅｃ
ｆｉｌｔｅｒ＿ｔｉｍｅ＝（３ＮＤ＋１．５）Ａｎｓｅｃ
これで、高いサンプル密度および複数のパスの場合、３ＮＤＡＷに近づく。
【０２２８】
サンプル・フィル時間。２．４項から、
Ｒｓｆｉｌｌ＝ｍｉｎ（Ｒｓ，Ｄ＊Ｒｔ）＝ｍｉｎ（１３３３，１６６Ｄ）Ｍｓａｍｐ／ｓｅｃ
であることを想起されたい。したがって、単一のバイリニア・テクスチャの場合、Ｄ＜８であれば、システムはテクスチャ速度を以下のように制限することが可能であり、
Ｒｓｆｉｌｌ（Ｄ＜８）＝１６６ＤＭｓａｍｐ／ｓｅｃ
さらにＤ＞＝８であれば、システムはサンプル速度を以下のように制限することが可能である。
Ｒｓｆｉｌｌ（Ｄ＞＝８）＝１３３３Ｍｓａｍｐ／ｓｅｃ
【０２２９】
より複雑なテクスチャリングの場合、Ｄのしきい値がさらに高くなることさえある。Ｄ＜８の場合、１つのパス、サンプル密度Ｄで、ピクセルをウィンドウ・サイズＡＷにフィルするための時間は、以下のようになる。
ｆｉｌｌ＿ｔｉｍｅ＝（ＡＷ ＊Ｃ＊Ｄ）／１６６＊Ｄ＝（ＡＷ ＊Ｃ）／１６６ｍｉｃｒｏｓｅｃ
【０２３０】
あるいは、グラフィックス・アプリケーションが、それぞれ領域ＡＷ／Ｎ、サンプル密度Ｎ＊Ｄで、Ｎ個のパスをＮ個の対応する領域に流入させると、（ＮＤは依然として８より小さいかまたは等しいと想定する）合計フィル時間（Ｎ個のパスについて）は増加しない。
ｆｉｌｌ＿ｔｉｍｅ＝Ｎ＊（（ＡＷ／Ｎ）＊Ｃ／１６６＝（ＡＷ ＊Ｃ）／１６６ｍｉｃｒｏｓｅｃ
【０２３１】
したがって、単一のバイリニア・テクスチャリングの場合、複数のパスはフィル時間を増やさずにサンプル密度を８まで上げることができる。より複雑なテクスチャリングの場合、フィル時間を増やさずにサンプル密度をより高くすることさえ可能である。
【０２３２】
三角形ラスタ化セットアップ時間。ホストのビュー・フラスタム・カリングおよびハードウェアのクリッピングが行われた後に（言い換えれば、シーン内の三角形がウィンドウ内部にある）、Ｐ個の三角形を備え、ウィンドウ領域ＡＷ、深さ複雑性Ｃ、およびサンプル密度Ｄで、フレームのラスタ化を設定するための時間は、以下のようになることを想起されたい。
ｔｒｉ＿ｔｉｍｅ＝Ｐ／ＲＰ＝３Ｐｎｓｅｃ
【０２３３】
シーンがＮ個の領域に区分されている場合、各領域には、ウィンドウＡＷ内で見えるＰ／Ｎのプリミティブより平均して少し多く収まることになる（すなわち、領域の境界線をまたがるプリミティブは部分的に両方の領域にあることになる）。したがって、Ｎ個の領域をレンダリングするための合計時間は、大幅には増加しない（少なくともＰが大きくＮが小さい場合）。
ｔｒｉ＿ｔｉｍｅ＝Ｎ＊３（（Ｐ／Ｎ）＝３Ｐｎｓｅｃ
【０２３４】
頂点処理時間。
ホストが、ハードウェア処理と全面的に重なる「完全な」ビュー・フラスタム・カリングを実行した場合、シーンがＮ個の領域に区分されていれば、Ｖ／Ｎより少し多い頂点が各領域に収まることになる（領域の境界線をまたがるプリミティブは部分的に両方の領域にあることになる）。Ｎ個の領域で頂点を変換およびライティングするための合計時間は、大幅には増加しない（Ｖが大きくＮが小さい場合）。
（ｌｏｗｅｒ ｂｏｕｎｄ）ｖｔｘ＿ｔｉｍｅ＝Ｎ＊３（Ｖ／Ｎ）＝３Ｖｎｓｅｃ
【０２３５】
ビュー・フラスタム・カリングが完全でない（またはまったくない）場合、頂点処理の負荷はＮ倍ずつ増加する可能性がある。
（ｕｐｐｅｒ ｂｏｕｎｄ）ｖｔｘ＿ｔｉｍｅ＝Ｎ＊３Ｐ＝３ＰＮｎｓｅｃ
【０２３６】
フレーム時間。まとめると、合計アニメーション・フレーム時間は以下のようになる。
ｆｒａｍｅ＿ｔｉｍｅ＝ｃｌｅａｒ＿ｔｉｍｅ＋ｒｅｎｄｅｒ＿ｔｉｍｅ＋ｆｉｌｔｅｒ＿ｔｉｍｅ＋ｓｗａｐ＿ｔｉｍｅ
【０２３７】
アニメーション・フレーム速度は、アニメーション・フレーム時間に単純に反比例する。
【０２３８】
グラフィックス・レンダリング・システムは、ダブル・バッファされたバッファ・スワップを実行するために、ウィンドウ・ルックアップ・テーブルを介して間接的な処置を使用することができる。したがって、ｓｗａｐ＿ｔｉｍｅはわずかである（テーブル・エントリを更新するための時間のみ）。２重バッファ・スワップが（よりスムースなアニメーションのために）意図的に表示帰線と同期される場合、単にｓｗａｐ＿ｔｉｍｅは、合計ｆｒａｍｅ＿ｔｉｍｅを表示フレーム時間の整数倍となるように量子化する効果を有する。この場合、次の頂点帰線を待つために費やす時間は、合計アニメーション・フレーム時間を増やすことなく、他の３回での穏やかな増加をマスクすることができる。
【０２３９】
本明細書でさまざまな処理速度に引用された例示的な値は、限定的なものではない。これらの処理速度は、実施形態によって様々な範囲の値を達成することができる。
【０２４０】
要約
サンプル・メモリを追加せずにサンプル密度を上げるために、Ｎ個のパスが使用される場合、
・サンプル・バッファのクリアおよびフィルタリング時間は、サンプル密度に比例して増加する（より多くのメモリが使用される場合と同様）。
・しきい値（この例ではサンプル密度８であり、図２０に示されるように、相対的な性能と、サンプルおよびテクスチャの処理経路を並行して機能させることによって設定される）を下回る場合、サンプル・フィル時間は増加しない。
・三角形ラスタ化時間は、大幅には増加しない（領域の境界上にある数個の三角形は２回処理される）。
・頂点処理時間は、Ｎ倍を超えない程度ずつ増加するが、グラフィックスプロセッサの前の効率的なビュー・フラスタム・カリングに伴うわずかな増加に近づくことができる。
【０２４１】
これは、フィル速度が制限されている（一般的なケース）シーンの場合、メモリを追加することなく、また性能を著しく損なうことなく、サンプル密度を上げることができることを意味する。
【０２４２】
頂点速度が制限されている場合、性能の低下はＮ分の１ほどにはならず、ビュー・フラスタム・カリングによって減らすことができる。
【０２４３】
たとえ大幅な性能の低下が発生しても、この方法は、性能と引き換えにより高いサンプル密度（すなわちよりよい品質）を得ることができる。サンプル密度は、コストまたは技術的に制限されていても、メモリの制限値を超えて増やすことが可能である。
【０２４４】
６．０ 立体ビジョンおよびサンプル密度の増加
グラフィックス・アプリケーションは、「立体ビジョンのためのサンプル・バッファの再使用」（４．０項）と「増加したサンプル密度のためのサンプル・バッファの再使用」（５．０項）の両方を活用するように、グラフィックス・レンダリング・システムを構成することができる。
【０２４５】
図２４は、より高いサンプル密度を達成するためのサンプル・バッファの再使用を示す図である。
【０２４６】
さらに、３．０項（すなわち「ウィンドウ・サイズあたりのＳＢの動的割振り」）で述べたように、グラフィックス・アプリケーションは、どちらかまたは両方の技術（すなわち立体ビジョンのためのＳＢの再使用および／または増加したサンプル密度のためのＳＢの再使用）を、現在のウィンドウ・サイズおよびユーザ基本設定（目標サンプル密度または目標フレーム速度）に基づいた動的割振りと組み合わせるように構成することができる。
【図面の簡単な説明】
【図１Ａ】グラフィックス・レンダリング・システムの一実施形態を示す図である。
【図１Ｂ】グラフィックス・レンダリング・システム内のハードウェア・アクセラレータの一実施形態を示す図である。
【図１Ｃ】グラフィックス・レンダリング・システム内のハードウェア・アクセラレータの他の実施形態を示す図である。
【図１Ｄ】グラフィックス・レンダリング・システム内のメディア・プロセッサの一実施形態を示す図である。
【図２】グラフィックス・レンダリング・システムの他の実施形態を示す図である。
【図３】フレーム・バッファ・データ・ユニット（たとえばピクセルまたはサンプル）内のビット・プレーンの割振りに関する例示的な実施形態を示す図である。
【図４】フレーム・バッファ・データ・ユニット（たとえばピクセルまたはサンプル）内のビット・プレーンの割振りに関する例示的な実施形態を示す図である。
【図５】フレーム・バッファ中の表示バッファおよびスーパーサンプル・バッファの割振りの一例を示す図である。
【図６】様々なフレーム・バッファ・モードでのメモリ割振りページ・サイズ（ピクセル単位）の一実施形態を示す図である。
【図７】サンプル・バッファの領域をクリアするための高速フィル機能の一実施形態を示す図である。
【図８】マルチサンプル（すなわちスーパーサンプル）をサンプル・バッファにレンダリングするためのプロセスの一実施形態を示す図である。
【図９】グラフィックス・レンダリング・パイプラインの一実施形態におけるサンプル処理およびテクスチャ処理リソースの並行処理を示す図である。
【図１０】コピー・オペレーションのセットで使用されるコピー経路を示す図である。
【図１１】コピー、フィルタリング、および累算のオペレーション・セットに関するデータ流れを示す図である。
【図１２】ピクセル・コピー・オペレーション（すなわち、フレーム・バッファからフレーム・バッファへのブロック・コピー・オペレーション）のためのアドレス生成を示す図である。
【図１３】サンプル・フィルタリング・オペレーションのためのアドレス生成を示す図である。
【図１４】１×１平方のサポート領域を有するフィルタを使用したサンプル・フィルタリングのための例示的なフットプリントを示す図である。
【図１５】半径Ｒ＝２のディスク形サポート領域を有するフィルタを使用したサンプル・フィルタリングのための例示的なフットプリントを示す図である。
【図１６】ソース・アドレス、宛先アドレス、データ、およびアドレスとデータの結合流れを強調した、フレーム・バッファからフレーム・バッファへのコピー・オペレーションの一実施形態を示す図である。
【図１７】スーパーサンプル読取りパスでのオペレーション・コードの流れを示す図である。
【図１８】一実施形態での、結果ピクセルをバック表示バッファへサンプル・フィルタリングおよびコピーするステップを示す要約図である。
【図１９】一実施形態での、表示バッファの前半分からのデータを表示するステップを示す図である。
【図２０】サンプル・バッファへのサンプルのレンダリングに関する、レンダリング性能パラメータのセットを示す図である。
【図２１】サンプル・バッファからのサンプルのフィルタリングに関する、フィルタリング性能パラメータのセットを示す図である。
【図２２】一実施形態での、立体表示のためのサンプル・バッファの再使用を示す図である。
【図２３】他の実施形態での、より高いサンプル密度を達成するための固定サイズのサンプル・バッファの再使用を示す図である。
【図２４】立体実施形態での、より高いサンプル密度を達成するためのマルチパス・レンダリングを示す図である。
【符号の説明】
１４ メディア・プロセッサ
１６ 共用メモリ（ＤＲＤＲＡＭ）
１８ ハードウェア・アクセラレータ
２０ テクスチャ・バッファ
２２ フレーム・バッファ
２４ ビデオ出力プロセッサ
２６ ＲＧＢ ＤＡＣ
２８ ビデオ・エンコーダ
３０ ブートＰＲＯＭ
１０４ ホスト・バス
【発明の属する技術分野】
本発明は、一般にコンピュータ・グラフィックスの分野に関し、より詳細には、最適なスーパーサンプル密度を達成するためにサンプル記憶域を動的に再割当てするように構成された、かつ／またはターゲットとなるイメージ品質を達成するためにいくつかのレンダリング・パスを動的に調整するように構成された、グラフィカル・コンピューティング・システムに関する。
【０００２】
【従来の技術】
グラフィカル・コンピューティング・システムはスーパーサンプリングを実施することが可能であり、すなわちピクセル解像度よりも高いサンプルを生成することが可能であり、ピクセルを生成するためにサンプルをフィルタリングすることが可能である。最終的なイメージ品質は、サンプル密度（すなわち、単位ピクセル領域あたりで生成されるサンプル数）にある程度依存する。さらに、グラフィカル・コンピューティング・システムは、ユーザが画面上のウィンドウをサイズ変更できるウィンドウイング環境で動作するように構成可能である。ただし、多くのグラフィカル・コンピューティング・システムは、サンプル密度またはレンダリング・パスの数をウィンドウ・サイズの変化に応答して調整できる方法で構成されていない。
【０００３】
【発明が解決しようとする課題】
ウィンドウイング環境でより効果的に動作できるグラフィカル・コンピューティング・システムおよび対応する方法の必要性がある。具体的に言えば、ウィンドウ・サイズの変化に応答してサンプル密度および／またはレンダリング・パスの数を動的に調整できるグラフィカル・コンピューティング・システムおよび対応する制御方法の必要性である。
【０００４】
【課題を解決するための手段】
様々な実施態様では、グラフィックス・システムがフレーム・バッファおよびハードウェア・アクセラレータを含む。フレーム・バッファは、サンプル・バッファおよびダブル・バッファされた表示域を含むことができる。ハードウェア・アクセラレータを、フレーム・バッファに結合され、さらに（ａ）プリミティブを受け取り、（ｂ）動的に調整可能なサンプル密度値に基づいてプリミティブ用のサンプルを生成し、（ｃ）サンプルをサンプル・バッファに書き込み、（ｄ）サンプル・バッファからサンプルを読み出し、（ｅ）ピクセルを生成するためにサンプルをフィルタリングし、（ｆ）ピクセルをダブル・バッファされた表示域のバック・バッファに格納するように構成することができる。ホスト・コンピュータは、１つまたは複数のウィンドウ・サイズ・パラメータの変更を指定するユーザ入力に応答して、フレーム・バッファ内でサンプル・バッファを再割り振りするために、（たとえば、格納済みのプログラム命令を使用して）グラフィックス・システムのプログラム可能レジスタを動的に更新するように構成されている。
【０００５】
一実施態様では、グラフィックス・アクセラレータを制御するための方法を以下のようにすることができる。（グラフィックス・アクセラレータは、プログラム可能サンプル密度に基づいてフレーム・バッファの使用可能スペースにサンプルをレンダリングし、サンプル・バッファからフレーム・バッファのダブル・バッファされた表示域へのサンプルをフィルタリングするように構成される。）本方法には、
（ａ）ウィンドウの幅および高さを決める入力を受け取ること、
（ｂ）ウィンドウの幅およびサンプル密度推定値に基づいてウィンドウを水平にカバーするメモリ割振りページの第１の数を計算すること、
（ｃ）ウィンドウの高さおよびサンプル密度推定値に基づいてウィンドウを垂直にカバーするメモリ割振りページの第２の数を計算すること、
（ｄ）第１の数と第２の数を掛け合わせて、メモリ割振りページの第３の数を決定すること、
（ｅ）（ｂ）、（ｃ）、および（ｄ）を１回または複数回実行して、メモリ割振りページの第３の数がフレーム・バッファの使用可能スペースに納まる条件によって決まるサンプル密度推定値を最大化すること、
（ｆ）最大化されたサンプル密度推定値を使用して、グラフィックス・アクセラレータのサンプル密度を再プログラミングすることが含まれる。この方法により、ウィンドウ・サイズの減少（増加）に応答してサンプル密度を増加（減少）させることができる。したがって、ウィンドウ・サイズが小さくなるほどピクセルあたりのイメージ品質が向上する。
【０００６】
他の実施態様では、グラフィックス・システムがハードウェア・アクセラレータおよびフレーム・バッファを含むことができる。フレーム・バッファは、サンプル記憶域およびダブル・バッファされた表示ピクセル領域を含む。ハードウェア・アクセラレータは、（ａ）サンプルを生成するためにプリミティブのストリームをレンダリングし、（ｂ）サンプルをフレーム・バッファのサンプル記憶域に格納し、（ｃ）サンプル記憶域からサンプルを読み取り、（ｄ）ピクセルを生成するためにサンプルをフィルタリングし、（ｅ）フレーム・バッファの表示ピクセル領域の第１のバッファにピクセルを格納するように動作可能である。さらにハードウェア・アクセラレータは、第１のバッファの制御をビデオ出力プロセッサに渡す前にアニメーションのフレームを完了させるために、１つまたは複数の対応するプリミティブのストリームに（ａ）、（ｂ）、（ｃ）、（ｄ）、および（ｅ）を１回または複数回実行するように動作可能でもある。
【０００７】
他の実施態様では、グラフィックス・システムによって生成されるイメージの品質を維持するための方法を以下のようにすることができる。（グラフィックス・システムは、プログラム可能サンプル密度に基づいてフレーム・バッファの使用可能スペースにサンプルをレンダリングし、サンプル・バッファからフレーム・バッファのダブル・バッファされた表示域へのサンプルをフィルタリングするように構成することができる。）本方法には、
（ａ）新しいウィンドウ・サイズを決める入力の受取りに応答して、アニメーション・フレーム用のグラフィックス・システムのパスの第１の数に対応する実現可能なサンプル密度を計算すること、
（ｂ）ユーザ指定サンプル密度よりも大きいかまたはこれに等しい実現可能なサンプル密度に対応する第１の数の値を決定するために、（ａ）を１回または複数回実行すること、
（ｃ）この値に等しいグラフィックス・システムのパスの第１の数を設定するために、グラフィックス・システムの１つまたは複数のプログラム可能レジスタに書き込むことが含まれる。
【０００８】
こうした方法は、システム・バスまたはコンピュータ・ネットワークを介してグラフィックス・アクセラレータに結合されたホスト・コンピュータで実行することができる。
【０００９】
他の実施態様では、グラフィックス・システムによって生成されるイメージの品質を維持する方法であって、本方法は、
（ａ）調整済みウィンドウのウィンドウ幅および高さを決める入力を受け取ること、
（ｂ）グラフィックス・システムによって達成可能なサンプル密度のセットから、サンプル密度値を選択すること、
（ｄ）正の整数値Ｎを選択すること、
（ｃ）ウィンドウ幅を選択されたサンプル密度に対応するページ幅で割った第１の上限を計算すること、
（ｄ）ウィンドウ高さを整数値Ｎで割って第１の結果を決定すること、
（ｅ）第１の結果を選択されたサンプル密度に対応するページ高さで割って第２の上限を計算すること、
（ｆ）第１の上限と第２の上限を掛け合わせてパスあたりのページ推定値を決定すること、
（ｇ）パスあたりのページ推定値がフレーム・バッファの使用可能スペースよりも大きい場合は、整数値Ｎを増やして（ｃ）、（ｄ）、（ｅ）、および（ｆ）を繰り返すこと、
（ｈ）アニメーション・フレームのＮパス・レンダリング用のグラフィックス・システムに構成されるように、グラフィックス・システムの１つまたは複数のプログラム可能レジスタに書き込むことが含まれる。
【００１０】
以下の詳細な説明は、添付の図面と共に考察すると、本発明をより良く理解することができる。本発明は、様々な修正態様および代替形式による影響を受けやすいものであり、その特定の実施態様が例示的なものとして図面に示されており、本明細書で詳細に説明される。ただし、図面およびその詳細な説明は、本発明を開示された特定の形式に限定することを意図するものではなく、その逆に、添付の特許請求の範囲で定義された本発明の精神および範囲に当てはまるすべての修正態様、等価態様、および代替態様をカバーすることを意図するものであることを理解されたい。見出しは編成のためだけのものであり、説明または特許請求の範囲を限定または解釈するために使用することを意味するものではないことに留意されたい。さらに「できる、場合がある」という語は、本出願全体を通じて、強制的な意味（すなわち、しなければならない）ではなく、許容的な意味（すなわち、可能性がある、可能である）で使用されている。「含む」という語およびその派生語は、「含むが、それに限定されるものではない」ことを意味する。「接続される」という語は「直接的または間接的に接続される」ことを意味し、「結合される」という語は「直接的または間接的に結合される」ことを意味する。
【００１１】
【発明の実施の形態】
一実施形態では、図１Ａで提案されるように、グラフィックス・レンダリング・システムは、メディア・プロセッサ１４、ハードウェア・アクセラレータ（ＨＡ）１８、フレーム・バッファ２２、およびビデオ出力プロセッサ２４を含むことができる。グラフィックス・レンダリング・システムは、ホスト・インターフェース、共用メモリ１１（たとえばＤＲＤＲＡＭ）、テクスチャ・メモリ２０（たとえばＳＤＲＡＭデバイスのアレイ）、ブートＰＲＯＭ ３０、およびＲＧＢＤＡＣ ２６、およびビデオ・エンコーダ２８も含むことができる。
【００１２】
ＲＡＭは、ランダム・アクセス・メモリの頭字語である。
ＳＲＡＭは、スタティック・ランダム・アクセス・メモリの頭字語である。
ＤＲＡＭは、ダイナミック・ランダム・アクセス・メモリの頭字語である。
ＳＤＲＡＭは、同期式ダイナミック・ランダム・アクセス・メモリの頭字語である。
ＲＤＲＡＭは、Ｒａｍｂｕｓ ＤＲＡＭの頭字語である。
ＤＲＤＲＡＭは、ダイレクトＲａｍｂｕｓ ＤＲＡＭの頭字語である。
ＰＲＯＭは、プログラム可能読み取り専用メモリの頭字語である。
ＤＡＣは、デジタル・アナログ変換器の頭字語である。
ＲＧＢは、赤、緑、青の頭字語である。
【００１３】
メディア・プロセッサ１４は、多角形、線、および点などのプリミティブを定義するグラフィックス・データのストリームを外部システム（たとえばホストプロセッサ）から受け取り、このグラフィックス・データ・ストリームに対していくつかの処理動作を実行することができる。事前に処理されたグラフィックス・データをハードウェア・アクセラレータに転送することができる。ハードウェア・アクセラレータは、グラフィックス・プリミティブ用のサンプルを生成し、そのサンプルをフレーム・バッファ内で割り振られたサンプル・バッファに格納することができる。ハードウェア・アクセラレータは、サンプル・バッファからサンプルを読み取り、サンプルをフィルタリングしてピクセルを生成し、さらにフレーム・バッファ内で割り振られたダブル・バッファされた表示バッファにそのピクセルを格納する。ピクセルの単一フレームが、サンプル・レンダリング・プロセスおよびサンプル・フィルタリング・プロセスの複数のパスで構成されることに留意されたい。ビデオ出力プロセッサは、表示バッファからピクセルを読み取り、表示デバイスへの出力用にビデオ出力信号（またはデジタル・ビデオ・ストリーム）を生成することができる。
【００１４】
一実施形態では、グラフィックス・レンダリング・システムには、（フレーム・バッファ・メモリ内で割り振られた）サイズの限定されたサンプル・バッファを効率的に使用することを目標としたいくつかの機能がある。
【００１５】
１．０ システム・アーキテクチャ
図１Ａは、グラフィックス・レンダリング・システムの一実施形態に関する基板レベルの構成図である。
【００１６】
メディア・プロセッサ１４は、受け取ったグラフィックス・データに対して、変換および書き込み動作ならびに他の汎用処理動作を実行することができる。メディア・プロセッサは、グラフィックス・プリプロセッサ１５０およびＲＰＵメガヘルツで動作する２つの処理ユニット（ＰＵ）を含むことができる。図１Ｄは、メディア・プロセッサの一実施形態に関する構成図である。
【００１７】
メディア・プロセッサ１４は、複数のバス・インターフェースを使用することができる。一実施形態では、メディア・プロセッサは北インターフェース１１（たとえば拡張ＵＰＡ６４Ｓインターフェース）、ダイレクトＲＡＭＢＵＳインターフェース１５４、および南インターフェース１６０を含む。外部プロセッサ（たとえばホストプロセッサ）は、グラフィックス・レンダリング・システムを制御するために北インターフェースを使用することができる。ダイレクトＲＡＭＢＵＳインターフェースは、１つまたは複数のＤＲＡＭメモリをサポートすることができる。南インターフェースはＵＰＡ６４Ｓバスの拡張変形であってよく、メディア・プロセッサがハードウェア・アクセラレータを制御できるようにするものである。
【００１８】
一実施形態では、共用メモリ１６が２つまたはそれ以上のＤＲＤＲＡＭチップを含むことができる。共用メモリ１６は、プログラム命令（たとえばマイクロコード）および一時データを格納するために使用することができる。共用メモリは、グラフィックス・レンダリング・システムとホスト・システムとの間の通信用のバッファを格納するため、およびコンテキスト・スイッチング用のコンテキスト情報を格納するために使用することもできる。共用メモリは、表示リスト・メモリとして使用することもできる。
【００１９】
ハードウェア・アクセラレータ１８は、２Ｄおよび３Ｄラスタ化、２Ｄおよび３Ｄテクスチャ化、ピクセル転送、イメージング・オペレーション、ならびにフラグメント処理を実行することができる。図１Ｂは、ハードウェア・アクセラレータ１８の一実施形態に関する構成図である。図１Ｃは、ハードウェア・アクセラレータ１８の一実施形態のより詳細な構成図である。以下に、図１Ｃで使用される頭字語の凡例を示す。
ＶＰ＝頂点プロセッサ
ＰＳＵ＝プリセットアップ・ユニット
ＳＵ＝セットアップ・ユニット
ＥＷ＝エッジ・ウォーカ
ＳＷ＝スパン・ウォーカ
ＳＧ＝サンプル生成器
ＳＥ＝サンプル評価器
ＴＥ＝テクスチャ環境
ＦＰ＝フラグメント・パイプライン
ＦＢＡ＝フレーム・バッファ・アドレス・ユニット
ＦＢＩ＝フレーム・バッファ・インターフェース
ＦＢ＝フレーム・バッファ
ＴＡ＝テクスチャ・アドレス・ユニット
ＴＲＢ＝テクスチャ・バッファ読取りバッファ
ＴＦ＝テクスチャ・フィルタ
ＦＲＢ＝フレーム・バッファ読取りバッファ
ＳＦ＝サンプル・フィルタ
ＰＸＭ＝ピクセル転送マルチプレクサ
ＰＸ＝ピクセル転送ユニット
ＴＢＭ＝テクスチャ・バッファ・マルチプレクサ
ＴＢＩ＝テクスチャ・バッファ・インターフェース
【００２０】
ハードウェア・アクセラレータ１８は、複数のインターフェースを有することができる。たとえば一実施形態では、ハードウェア・アクセラレータは、
（ａ）ハードウェア・アクセラレータがメディア・プロセッサからコマンドおよび／またはデータを受け取るときに介する、第１のインターフェース１６１（たとえば拡張ＵＰＡ６４Ｓインターフェース）と、
（ｂ）ハードウェア・アクセラレータがデバイス・ブートＰＲＯＭをアドレス指定し、ビデオ出力プロセッサを制御するときに介する、第２のインターフェース１７６と、
（ｃ）ハードウェア・アクセラレータがテクスチャ・バッファ２０の読取りおよび書込みの際に介する、第３のインターフェース１８７（たとえばエイトウェイ・インターリーブ・テクセル・バス用）と、
（ｄ）ハードウェア・アクセラレータがフレーム・バッファ２２の読取りおよび書込みの際に介する、第４のインターフェース３００（たとえばフォーウェイ・インターリーブ・ピクセル・バス）とを含む、４つのインターフェースを有することができる。
【００２１】
テクスチャ・バッファ・メモリ２０は、ＳＤＲＡＭ（すなわち同期式ダイナミック・ランダム・アクセス・メモリ）のアレイを含むことができる。たとえば一実施形態では、テクスチャ・バッファは８つのＳＤＲＡＭを有する。テクスチャ・バッファは、テクスチャ・マップ、イメージ処理バッファ、およびアキュムレーション・バッファを格納するために使用することができる。ハードウェア・アクセラレータ１８は、ＮＴＭＡビット・セットのテクスチャ・バッファ・データをＳＤＲＡＭクロック速度で読み取るかまたは書き込むことができる。たとえば、ＮＴＭＡは１２８ビットに等しくてよい。ただし、ＮＴＭＡの他の様々な値が可能であり、企図される。一実施形態では、２×２のテクスチャ・フットプリントの任意アドレス指定を可能にするために、ＳＤＲＡＭの各ペアが独立して行および列のアドレス指定が可能である。さらに、各ペア内で２つのＳＤＲＡＭが独立した列アドレスを受け取ることができる。
【００２２】
フレーム・バッファ２２は、ＤＲＡＭメモリ・デバイス（ＤＭＤ）のアレイを含むことができる。アレイは、ＮＤＲＡＭのＤＲＡＭメモリ・デバイスを含むことができる。ＤＲＡＭメモリ・デバイスの第１のサブセットはハードウェア・アクセラレータによってアクセス可能であり、ＤＲＡＭメモリ・デバイスの第２のサブセットは、ハードウェア・アクセラレータとビデオ出力プロセッサ２４の両方によってアクセス可能である。たとえば一実施形態では、ＮＤＲＡＭは１６に等しくてよく、各サブセットは８つのＤＲＡＭメモリ・デバイスを含むことができる。さらに１６のＤＲＡＭメモリ・デバイスを、図１Ａで提案されるように、４つのランクに編成することができる。
【００２３】
ハードウェア・アクセラレータ１８は、フレーム・バッファ・インターフェース３００を含むことができる。フレーム・バッファ・インターフェースは、ＤＲＡＭメモリ・デバイスから入出力するデータの流れを制御する、アドレス信号および制御信号をアサートする。フレーム・バッファ・インターフェースを、ビデオ出力プロセッサ２４によってアサートされたフレーム・バッファ・データ（すなわちフレーム・バッファに格納されたデータ）に対する要求を処理するように構成することができる。
【００２４】
フレーム・バッファ２２の記憶容量ＣＦＢは、任意の様々な値を取ることができる。一実施形態では、フレーム・バッファは７２メガバイトを格納することができる。フレーム・バッファは最高５２０万のデータ・アイテムの容量を持つことができる。データ・アイテムはピクセルまたはサンプルを表す。フレーム・バッファ内の記憶域の各ピクセルは、
６０ビットのカラー情報（すなわち３０ビットのダブル・バッファされたＲＧＢ）と、
８ビットのアルファと、
８ビットのオーバレイと、
１０ビットのウィンドウＩＤと、
２６ビットのｚ深さと、
４ビットのステンシルとを含む、１１６プレーンを有することができる。
【００２５】
一実施形態では、ハードウェア・アクセラレータ１８は、単一のフレーム・バッファ・クロックで４ピクセルまたは８サンプルまでを書き込むことが可能であり、２つのフレーム・バッファ・クロックの４つのピクセルまたはサンプルを読み取ることが可能である。
【００２６】
フレーム・バッファ２２のＤＲＡＭメモリ・デバイス（ＤＭＤ）は、シリアル出力ポートを有することができる。一実施形態では、８つのＤＲＡＭメモリ・デバイスの第１のサブセットは、ビデオ出力プロセッサに結合されたシリアル出力ポートを有することが可能であり、それを表示可能ピクセル・バッファ、オフスクリーン・ピクセル・バッファ、またはマルチサンプル・バッファを格納するのに使用することができる。ＤＲＡＭメモリ・デバイスの第２のサブセットはビデオ出力プロセッサへの接続を有することができないため、オフスクリーン・ピクセル・バッファまたはマルチサンプル・バッファを格納するのに使用することができる。その結果、一実施形態では、フレーム・バッファが最高２６０万ピクセルを表示可能であり、サンプル・バッファは、最高５２０万サンプルから表示されたピクセル数を引いた数まで格納する。マルチサンプルおよびスーパーサンプルという語は、本明細書では同義語として使用される。
【００２７】
ビデオ出力プロセッサ２４は、ＤＲＡＭメモリ・デバイスの第１のサブセットから出力されたビデオ・データをバッファリングおよび処理することができる。ビデオ出力プロセッサは、ＤＲＡＭメモリ・デバイスからのビデオ・データをバースト単位で読み取ることができる。バーストは、Ｎｂｕｒｓｔピクセル長さであってよい。バースト時には、２ビデオ・クロックごとにＮｃｃピクセルを転送することができる。たとえば一実施形態では、Ｎｂｕｒｓｔが１６０に等しく、Ｎｃｃが８に等しくてよい。ＮｂｕｒｓｔおよびＮｃｃには、様々な値が割当て可能であることに留意されたい。ビデオ出力プロセッサは、ガンマ補正、疑似カラーのカラー・マップ、およびカーソル生成を実行するようにも構成可能である。ビデオ出力プロセッサは、２つのビデオ出力ストリームを提供する２つ（またはそれ以上）の独立したラスタ・タイミング生成器を含むことができる。たとえば、ビデオ出力ストリームのうち１つをＲＧＢ ＤＡＣ ２６に提供し、ビデオ出力ストリームのうち１つをビデオ・エンコーダ２８に提供することができる。
【００２８】
ＲＧＢ ＤＡＣ ２６は、最高Ｒｄｏｔメガヘルツのドット・レートで、高解像度ＲＧＢアナログ・ビデオ出力を提供することができる。たとえば一実施形態では、Ｒｄｏｔは２７０メガヘルツに等しくてよい。
【００２９】
ビデオ・エンコーダ２８は、符号化されたＮＴＳＣまたはＰＡＬビデオ出力を、Ｓビデオまたは合成ビデオのテレビジョン・モニタまたはレコーディング・デバイスに提供することができる。ＮＴＳＣとは、米国国内でのテレビジョンおよびビデオの規格を定義する責務を負ったグループ、Ｎａｔｉｏｎａｌ Ｔｅｌｅｖｉｔｉｏｎ Ｓｔａｎｄａｒｄｓ Ｃｏｍｍｉｔｔｅｅ（米国テレビジョン方式審議委員会）の略語である。ＰＡＬとは、Ｐｈａｓｅ Ａｌｔｅｒｎａｔｉｎｇ Ｌｉｎｅ（位相反転ライン）の略語である。
【００３０】
ブートＰＲＯＭ ３０は、システム初期化およびフレーム・バッファ制御コードを含むことができる。
【００３１】
図２は、一実施形態に従ったグラフィックス・レンダリング・システムを示す高水準構成図である。この構成図には、いくつかの主要な処理ブロック（四角で囲む）、主要なメモリ、テーブルおよびデータ・バッファ（丸で囲む）、ならびに経路（矢印）が含まれる。
【００３２】
上方の四角で囲まれた領域から点線で囲まれたサブ領域を除いたものが、メディア・プロセッサ１４に対応する。中央の四角で囲まれた領域から点線で囲まれた２つのサブ領域を除いたものが、ハードウェア・アクセラレータ１８に対応する。下方の四角で囲まれた領域が、ビデオ出力プロセッサ２４に対応する。
【００３３】
上方領域の点線で囲まれたサブ領域は共用メモリ１６に対応する。中央領域の点線で囲まれた２つのサブ領域はそれぞれテクスチャ・バッファ２０およびフレーム・バッファ２２に対応する。
【００３４】
システム・バス１０４（たとえばＵＰＡ６４Ｓバス）は、ホストプロセッサ（またはホスト・システム）をメディア・プロセッサ１４のホスト・インターフェース１１に結合する。（システム・バスは本明細書ではホスト・バスとも称される。）制御装置１６０は、メディア・プロセッサ１４およびハードウェア・アクセラレータ１８を結合する。バス３２はハードウェア・アクセラレータをデバイスＰＲＯＭ ３０およびビデオ出力プロセッサ２４に結合する。バス３２は、本明細書ではＨｖｂｕｓとも称される。
【００３５】
グラフィックス・レンダリング・システムは、フレーム・バッファ、テクスチャ・バッファ、共用メモリ、およびデバイスＰＲＯＭ ３０などのいくつかのメモリを含むことができる。
【００３６】
グラフィックス・レンダリング・システムは、グラフィックスをフレーム・バッファ２２に加速描画し、その後フレーム・バッファのコンテンツを１つまたは複数のビデオ出力ストリームで表示することが可能ないくつかの機能を有する。一実施形態では、フレーム・バッファ・メモリを使用して、最高５２０万のデータ・アイテム（データ・アイテムはサンプルまたはピクセルのいずれかであってよい）を格納するために使用することが可能であり、最高２６０万のピクセルを表示することが可能であって、残りのデータ・アイテムをオフスクリーン・ピクセルまたはサンプル・バッファに使用することが可能である。
【００３７】
デバイスＰＲＯＭは、メディア・プロセッサ用のブートストラップ・コードを含むことができる。デバイスＰＲＯＭは、システムＯｐｅｎＢｏｏｔ ＦＣＯＤＥ（デバイスの識別および初期化、コンソール端末エミュレータ）を含むこともできる。
【００３８】
メディア・プロセッサ１４における処理ブロック
図１Ｄおよび２は、メディア・プロセッサ１４の例示的実施形態を提供するものである。メディア・プロセッサ１４はホスト・インターフェース１１を含む。ホスト・インターフェース１１は北ＵＰＡインターフェース（ＮＵＰＡ）であってよい。ホスト・インターフェースは、ホストとグラフィックス・レンダリング・システムとの間のトランザクションを処理するスレーブである。ホスト・インターフェースは、状態および制御レジスタ、割込み論理、ならびにデータおよびアドレス・バッファを含むことができる。アドレス・デコーダは、状態および制御レジスタ、グラフィックス待ち行列ＧＱ、共用メモリ、またはダイレクト経路ブリッジに向けてデータを送ることができる。
【００３９】
ホストは、グラフィックス・レンダリング・システムによる処理のためにコマンドを待ち行列に入れるグラフィックス待ち行列に、「ストリーム」コマンドを書き込むことができる。ホストは、グラフィックス待ち行列のオーバフローを防ぐために、フロントエンドの状態レジスタで自由なワード・カウントをポーリングすることができる。
【００４０】
ストリーム・コマンドは、それぞれがヘッダ・ワードとそれに続く１つまたは複数のデータ・ワードからなる一連のコマンド文字列を含むことができる。グラフィックス・プリプロセッサ（ＧＰＰ）は、ＧＱから文字列を引き出してそれらを解釈する。文字列タイプに応じて、ＧＰＰは以下の様々な方法で出力をルーティングすることができる。
（１）ＨＡ（ハードウェア・アクセラレータ）レジスタ書き込み（２Ｄ頂点を含む）を他の処理なしにハードウェア・アクセラレータ１８に渡すことができる。
（２）ＧＰＰ制御レジスタ書き込みが、ＧＰＰそれ自体によって吸収される。
（３）メディア・プロセッサのマイクロコード・ルーチンへの属性および命令をバッファリングし、プロセッサ・ユニットＰＵ０およびＰＵ１に渡すことができる。プロセッサ・ユニットはこれらを消費し、ハードウェア・アクセラレータ１８に渡すことができる。
（４）３Ｄ頂点構成要素をフォーマット変換し、頂点アセンブリ・バッファで完全な頂点にアセンブルすることができる。頂点に頂点構成要素がない場合、この値を以前の頂点から引き継ぐことができる。頂点のグループをバッファリングし、次の使用可能なプロセッサ・ユニットにディスパッチすることができる。頂点の変換およびライティングの後、プロセッサ・ユニットのマイクロコード・ルーチンが処理済みの３Ｄ頂点をハードウェア・アクセラレータ１８に送信する。
（５）圧縮された文字列が、属性、頂点、メッシュ・バッファ・オペレーション、およびＧＰＰ制御書込みに圧縮解除される。メッシュ・バッファ・オペレーションはＧＰＰメッシュ・バッファにシャドウイングされ、ハードウェア・アクセラレータに渡され、その他は上記のように処理される。
【００４１】
ＧＰＰは「ハード・タグ」モードで動作することができる。このモードでは、ＧＰＰは各頂点または属性に関してハードウェア・アクセラレータ１８に、処理ユニットに送信する旨の命令タグを送信することができる。すなわち、ハードウェア・アクセラレータは、プロセッサをバイパスしたＨＡレジスタ書込みおよびメッシュ・バッファ・オペレーションと共に、プロセッサ・ユニットから着信する処理済みの属性および頂点を集めて、それらすべてを正しいストリームの順序で配置しなおすことができる。（ＨＡレジスタ書込みは、ハードウェア・アクセラレータ内のレジスタをターゲットとするレジスタ書込みである。）
【００４２】
ある特殊なケースでは、すべてのトランザクションをプロセッサ・ユニットを介してルーティングすることが望ましい場合がある。したがってＧＰＰは、こうした特殊なケースをサポートするために「ソフト・タグ」を有することができる。
【００４３】
メディア・プロセッサ１４は、ＮＰＵ処理ユニットを含むことができる。例示された実施形態では、メディア・プロセッサが２つの処理ユニットＰＵ０およびＰＵ１（すなわちＮＰＵ＝２）を含む。処理ユニットは、本明細書ではＭＰＵとも称される。プロセッサ・ユニット（ＰＵ）で実行するマイクロコード・ルーチンは、以下の機能を含むがこれらに限定されることのない、いくつかの機能を実行する。
（ａ）頂点バッチを変換およびライティングする、高度に最適化された１頂点あたりの処理ルーチン。一実施形態では、１つのバッチが２つまたは４つの頂点を含んでよい。
（ｂ）頂点処理パイプライン・マイクロコード状態、および／またはハードウェア・アクセラレータ（ＨＡ）描画パイプライン（すなわちＨＡにおける描画パイプライン）のハードウェア状態を定義および更新する、属性処理ルーチン。
（ｃ）最適化された頂点処理ルーチンによって、またはＨＡハードウェア・パイプによって直接サポートされていない特殊なケースでは、マイクロコードは独自のプリミティブ・アセンブリ、ラスタ化、および／またはテクスチャリングを実行することができる。
（ｄ）システムは、初期化、トラップ処理、ホスト・ドライバ通信、コンテキスト・スイッチング、およびメモリ割振り用のマイクロコードを処理する。
【００４４】
制御装置１６０（たとえば南ＵＰＡインターフェース）は、メディア・プロセッサをハードウェア・アクセラレータ１８内の様々なブロックのマスタとすることができる。ＧＰＰおよびＰＵは、ハードウェア・アクセラレータの頂点コレクションおよびプリミティブ・アセンブリ・ブロックに書き込むことができる。ＰＵは、ＰＵダイレクト経路を使用して、フレーム・バッファ・ピクセル、テクスチャ・バッファ・テクセル、ならびに（ＤＰユーザ、プリミティブ・アセンブリ、クリップ・トラップ処理、構成およびコンテキスト・スイッチ・レジスタを含む）ハードウェア・アクセラレータおよびビデオ出力プロセッサ内の様々なレジスタに、読取りおよび書込みすることもできる。
【００４５】
一実施形態では、ダイレクト経路ブリッジは、ホスト・バスを、ＦＢピクセル、ＴＢテクセル、ならびに（ＤＰユーザ、プリミティブ・アセンブリ、クリップ・トラップ処理、構成およびコンテキスト・スイッチ・レジスタを含む）ハードウェア・アクセラレータおよびＨＶｂｕｓ内の様々なレジスタに読取りおよび書込みをするためのＳＵＰＡマスタとすることができる、ＮＵＰＡからＳＵＰＡへのバス・ブリッジである。ダイレクト経路ブリッジは、本明細書ではバス・インターフェース・ユニット（ＢＩＵ）１５４とも称される。
【００４６】
ＦＢはフレーム・バッファの頭字語である。
ＴＢはテクスチャ・バッファの頭字語である。
ＵＰＡはユニバーサル・ポート・アーキテクチャの頭字語である。
ＮＵＰＡは北ＵＰＡの頭字語である。
ＳＵＰＡは南ＵＰＡの頭字語である。
【００４７】
ユニバーサル・ポート・アーキテクチャ（ＵＰＡ）はバス仕様である。マスタおよびスレーブをサポートするＣＰＵ用の１２８ビットＵＰＡポート（「ＵＰＡ１２８」）、マスタおよびスレーブをサポートするＩ／Ｏチップ用の６４ビット・ポート（「ＵＰＡ６４Ｍ」）、さらにスレーブ専用デバイス用の６４ビット・ポート（「ＵＰＡ６４Ｓ」）がある。
【００４８】
ハードウェア・アクセラレータの処理ブロック
一実施形態では、図１Ｂ、１Ｃ、および２で様々に例示されたように、ハードウェア・アクセラレータ１８は以下の処理ブロックを含む。
【００４９】
スレーブ・インターフェース：スレーブ・インターフェース（たとえば南ＵＰＡインターフェース）は、メディア・プロセッサ内のＳＵＰＡマスタに応答する。スレーブ・インターフェースは、状態および制御レジスタ、割込み論理、ピクセル先行読取り論理、データおよびアドレス・バッファを含むことができる。スレーブ・インターフェースは、メディア・プロセッサからトランザクションを受け取る。各トランザクションにはアドレスおよび何らかのデータが含まれる。スレーブ・インターフェース内のアドレス・デコーダは、トランザクションを送信しなければならない場所を決定するために、（たとえばルックアップ・テーブルを使用して）アドレスをデコードする。たとえば、アドレス・デコーダはデータを、様々なＨＡレジスタ、頂点プロセッサ（ＶＰ）、ダイレクト経路、レンダリング／加速経路、またはビデオ出力プロセッサのうちいずれかにルーティングすることができる。スレーブ・インターフェースは、本明細書ではＵＢＩ（ＵＰＡバス・インターフェース）とも称される。
【００５０】
頂点プロセッサ（ＶＰ）：頂点コレクションおよびプリミティブ・アセンブリは、頂点プロセッサ内で実行される。頂点プロセッサは命令タグ、ＨＡレジスタ書込み、属性書込み、および処理済みの３Ｄ頂点構成要素を収集する。
【００５１】
３Ｄ頂点は、後で再使用するためにメッシュ・バッファに入れておくことができる。タグ・ストリームの順序に基づいて、新しい頂点および再使用される頂点は、プリミティブ・アセンブリ・ブロックによって３Ｄプリミティブにアセンブルされ、その後クリップ・テストされる。クリップ・テストに合格したプリミティブは、ラスタ化パイプに向けて発信される。クリップ・テストに不合格のプリミティブはトスされる。曖昧な場合は、メディア・プロセッサのマイクロコードによって処理されるクリップ・トラップを生じさせる。
【００５２】
一実施形態では、２Ｄ頂点がＨＡレジスタ書込みとして着信し、どんなメッシュ・バッファまたはクリッピング・サポートもなしに、プリミティブ・アセンブリが単純化される。
【００５３】
ラスタ化パイプ（ＲＰ）：ラスタ化パイプは発信されたプリミティブ（線、多角形など）を受け入れ、それらをピクセル・フラグメントに圧縮解除する。フラグメントの位置、カラー、アルファ、および深さがサンプル生成器に送信される。フラグメント・テクスチャ座標がテクスチャ・アドレス・ブロックに送信される。
【００５４】
サンプル生成器（ＳＧ）：３Ｄプリミティブの確率的にサンプリングされたラスタ化が実行可能である場合、ＳＧはどのサンプル位置がプリミティブの内側にあるかを決定し、各内部サンプル位置でカラー、アルファ、および深さを補間して、その結果をテクスチャ環境ユニット（ＴＥ）に送信する。
【００５５】
３Ｄの線または点のフィルタリング（たとえばガウス・フィルタリング）が実行可能である場合、ＳＧはその線または点の有効領域内部にある各ピクセルでのフィルタ重みを決定し、その後アルファとそのフィルタ重みとを掛け合わせ、ピクセル・フラグメントのカラー、アルファ、深さ、および位置をテクスチャ環境ユニットに送信する。
【００５６】
サンプリングおよびガウス・フィルタリングが実行不能である場合、またはプリミティブが２Ｄである場合、ＳＧは、ラスタ化されたピクセル・フラグメントのカラー、アルファ、深さ、および位置を、修正せずにテクスチャ環境ユニットに渡すことができる。
【００５７】
テクスチャ・アドレス・ユニット（ＴＡ）：テクスチャリングが実行可能である場合、ラスタ化パイプはフラグメント・テクスチャ座標をＴＡに送信する。ＴＡは、テクセル・サンプル・アドレス、ならびに指定されたフィルタ・フットプリント内のテクセル・サンプルを検索およびフィルタリングするために必要な詳細かつブレンドされた要素のレベルを決定する。ＴＡは、必要な各テクセル・サンプルに関して、テクスチャ・バッファ（ＴＢ）への読取り要求を生成する。「サンプル」という語は、グラフィックス・プリミティブの内部にある各サンプル位置でサンプル生成器ＳＧによって算出されたデータ値のセット（たとえばｒｇｂａｚ）を示す際にも使用されることに留意されたい。コンテキストが、どの用法を意味しているかを判定する。
【００５８】
テクスチャ・ファイル（ＴＦ）：ＴＦは、ＴＡからのブレンド要素と共にテクセル・サンプル・データをＴＢから受け取り、フィルタリング済みのテクセルを生成するために、テクセル・サンプルをブレンドする。
【００５９】
ピクセル転送ユニット（ＰＸ）：テクスチャリング中に、ＴＦ出力がＰＸに送信され、ここで、フィルタリング済みテクセルのカラーおよびアルファ値に関して検索機能を実行することができる。さらにＰＸは、ダイレクト経路およびコピー・オペレーション中にも使用される。
【００６０】
テクスチャ環境ユニット（ＴＥ）：テクスチャリング中に、ＴＥは、ＰＸ出力（テクスチャのカラー／アルファ）とＳＧ出力（フラグメントのカラー／アルファ）とをマージして、テクスチャ済みフラグメントを取得する。テクスチャリングが実行不能である場合、ＴＥはＲＰ／ＳＧフラグメントのカラー、アルファ、深さを通過させる。
【００６１】
テクスチャ・パイプ（ＴＰ）：ＴＡ、ＴＢ、ＴＦ、ＰＸ、ＴＥクラスタは、本明細書ではテクスチャ・パイプと称される。
【００６２】
レンダリング・パイプ：ＶＰ、ＲＰ、ＳＧ、およびＴＥによって定義されるユニットのクラスが、レンダリング・パイプと呼ばれる。
【００６３】
ストリーム経路：ストリーム経路はＧＱおよびＧＰＰから始まり、ＰＵの中または周囲を通過し、ＶＰおよびＲＰを通過して、テクスチャをＴＰへ、ピクセルをＳＧへと分岐させ、それらをＴＥで再結合させることができる。ＴＥの結果は、ストリーム／ダイレクト結合パイプ同期ポイントへ送られる。
【００６４】
ストリーム／ダイレクト結合：ストリームおよびダイレクト経路は、メディア・プロセッサ１４のホスト・インターフェースで分岐する（すなわち、ストリームはＧＱへ進み、ダイレクトはダイレクト経路ブリッジへ進む）。ストリーム／ダイレクト結合ポイントは、ストリームおよびダイレクト経路が再結合する場所であり、共用経路が始まる場所である。
【００６５】
共用経路：フレーム・バッファへのフラグメント・パイプおよび書込みは、ストリームおよびダイレクト経路によって共用される。任意の所与の時点に、ストリームまたはダイレクト経路のうちの１つが共用経路を所有することができる。
【００６６】
フラグメント・パイプ（ＦＰ）：ＦＰは、
定数の置き換え、
領域のパターン化、
アドレス、カラー、およびアルファのクリッピング、
ウィンドウＩＤ（ＷＩＤ）、ステンシル、および深さのテスト、
プレーン・グループの実行可能化およびビット・プレーンのマスク、
フォグ、ブレンド、およびラスタ・オペレーションなどの、
１フラグメントあたりの書込みオペレーションを実施する。
【００６７】
一実施形態では、ＦＰは、一部はハードウェア・アクセラレータ１８に、一部はフレーム・バッファ２２にある。
【００６８】
コピー／フィルタリング・オペレーション：ストリーム・コマンドには、ラスタ化パイプがＴＢとＦＢとの間またはその中でデータを移動させるメモリ・アドレス生成器となる、以下のような様々なコピー／フィルタリング・オペレーションが含まれる。
【００６９】
（Ａ）ブロック・コピー・オペレーションは、任意選択のピクセル転送（ＰＸ）オペレーション（たとえばスケール、バイアス、カラー・マトリクス、検索、ヒストグラム、最小／最大）を使用して、ＴＢとＦＢとの間またはその中でピクセルまたはテクセルを移動させる。
【００７０】
（Ｂ）イメージ・フィルタリング・オペレーションは、テクスチャ・フィルタ（ＴＦ）を使用して、ＴＢピクセル・データ（すなわち、テクスチャ・バッファに格納されたピクセル・データ）での畳み込みを実行する。畳み込みの結果に対してオプションのＰＸオペレーション（前述）を実行し、ＴＢまたはＦＢに送信することができる。
【００７１】
（Ｃ）レンダリング・パイプは、確率的にサンプリングされたシーンを、ＦＢのオフスクリーン・サンプル・バッファにレンダリングすることができる。シーンがレンダリングされた後、確率的サンプル・フィルタ（ＳＳＦ）を使用して、ＦＢサンプル・バッファからのサンプルで畳み込みを実行し、ＦＢの表示領域にエイリアス除去されたシーンを作成することができる。ＳＳＦ出力は、ＰＸによって補正されたガンマであってよい。
【００７２】
（Ｄ）アキュムレーション・バッファ・オペレーションは、ＴＢの領域をアキュムレーション・バッファとして使用し、ＯｐｅｎＧＬ負荷、累算、乗算、加算、および復帰オペレーション、ならびにボリューム・レンダリングに対する高度に精密なスライス・ブレンド・オペレーションをサポートする。ＴＢ内の連続したメモリ領域を、アキュムレーション・バッファ（たとえばＲＧＢ１６バッファ）として割り振ることができる。
【００７３】
ダイレクト・ピクセル／テクセル書込み経路：ダイレクト書込み経路はホスト・インターフェースおよびダイレクト経路ブリッジから始まり、制御装置（ＳＵＰＡ）へと向かう。書込みアドレスおよびデータは、ＰＸ入力セレクタ（本明細書ではピクセル転送マルチプレクサとも称される）を介してＰＸユニットへ送信され、書込みデータ上でピクセル転送（ＰＸ）オペレーションを実行するために割り当てることができる。ＰＸの結果はストリーム／ダイレクト結合ポイントに送信され、その後（共用経路フラグメント・パイプを介して）ＴＢまたはＦＢのいずれかに送信される。
【００７４】
ダイレクト・ピクセル／テクセル読取り経路：ダイレクト読取り経路はホスト・インターフェースおよびダイレクト経路ブリッジから始まり、制御装置へと向かう。読取りアドレスはＰＸを通過してストリーム／ダイレクト結合ポイントに渡され、その後ＴＢまたはＦＢに渡される。メモリ読取りデータはＰＸ入力セレクタを介してＰＸユニットに戻り、結果が（制御装置１６０およびホスト・インターフェース１１を介して）ホストに戻される前に、読取りデータに対してピクセル転送（ＰＸ）オペレーションを実行するために割り当てることができる。
【００７５】
ビデオ出力プロセッサ２４内にあるかまたはこれに関する処理ブロック
ＨＶＢｕｓインターフェース（ＨＢＩ）：ＨＢＩは、ＳＵＰＡバスが（およびＭＰＵまたはホスト・コンピュータの拡張により）、デバイスＰＲＯＭの読取り、ならびにビデオ出力プロセッサ（ＶＯＰ）のレジスタおよびテーブルの間接的な読取り／書込みを実行できるようにするものである。
【００７６】
ウィンドウ・ルックアップ・テーブル（ＷＬＵＴ）：ＷＬＵＴは、各ウィンドウの視覚表示属性を定義するものであって、ウィンドウＩＤプレーンによって索引付けされる。ＷＬＵＴエントリは、
ＲＧＢ対索引付けカラー、
索引付けカラー・ソース（Ｒ、Ｇ、Ｂ、オーバレイ）、
カラー・ルックアップ・テーブル数、ガンマ補正、またはバイパス、
オーバレイなし、不透明オーバレイ、または透明オーバレイ
などの視覚表示属性を指定することができる。
【００７７】
ＷＬＵＴは物理的に分離し、一部はハードウェア・アクセラレータ１８に、一部はフレーム・バッファ２２に、一部はビデオ出力プロセッサ２４に常駐することができる。フレーム・バッファにはオーバレイ論理もあり、これが１次プレーンまたはオーバレイ・プレーンが表示されるかどうかを決定する。
【００７８】
カラー・フックアップ・テーブル（ＣＬＵＴ）：一実施形態では、擬似カラーまたはダイレクト・カラー・マップを格納するために、１つのＣＬＵＴについて２５６のトリプル・エントリを備えた４つのＣＬＵＴが使用可能である。真のカラー・ウィンドウの場合、代わりに単一のガンマＬＵＴ（ＧＬＵＴ）（１０２４のトリプル・エントリ）を使用することができる。ＧＬＵＴをバイパスすることも可能である。
【００７９】
追加のビデオ出力機能は、ハードウェア・カーソルおよびデュアル・ビデオ・タイミング生成器を含むことが可能であり、これによって１次および２次ビデオ出力ストリームへのタイミングおよびデータ要求を生成することができる。
【００８０】
ビデオ・デジタル・アナログ変換器（ＤＡＣ）またはエンコーダ：１次ビデオ出力ストリームは、ビデオＤＡＣ（たとえば、赤、緑、および青それぞれに１０ビットを受け取るビデオＤＡＣ）をアナログ・コンピュータ・ディスプレイに対して駆動させることができる。２次ビデオ・ストリームは、
（１）オンボードＴＶエンコーダをＳビデオＴＶモニタまたはレコーディング・デバイスに対して駆動させるか、または
（２）機能拡張コネクタを駆動させることができる。可能なドーター・カード・オプションには、
第２のアナログ・コンピュータ・ディスプレイ、
デジタル・フラット・パネル・リンク、または
シリアル・デジタル・ビデオ出力リンクが含まれる。
【００８１】
２．０ マルチサンプリングのレンダリング後のフィルタリング
一実施形態では、グラフィックス・レンダリング・システムは、フル・シーンのレンダリング完了までのサンプル・フィルタリングとは異なる。
【００８２】
グラフィックス・レンダリング・システムは、表示バッファ・スワップ直前までのサンプル・フィルタリングとは異なる場合がある。シーン全体がアニメーション速度（シーンの複雑さによって異なる）でフィルタリングされる。
【００８３】
グラフィックス・レンダリング・システムは、
（ａ）シーンを（ＦＢ内に割り振られた）サンプル・バッファにレンダリングするステップと、
（ｂ）シーンをサンプル・バッファから（同様にＦＢ内に割り振られた）バック表示バッファへ、アニメーション速度でフィルタリングし、、
（ｃ）フロントおよびバック表示バッファを（アニメーション速度で）スワップし、
（ｄ）各表示リフレッシュについて、表示バッファ内のピクセルを（アニメーション速度よりも速い場合の多いビデオ速度で）表示することの、一連のステップを実行する。
【００８４】
２．１ フレーム・バッファ（ＦＢ）割振り
２．１．１ ＦＢビット・プレーンの用法
フレーム・バッファ２２の一実施形態では、各ピクセル（またはサンプル）は１１６ビット・プレーンのデータを有することができる。図３は、１１６ビット・プレーンを編成する１つの方法を示す図である。図４は、ピクセル（またはサンプル）を構成する様々なフィールドを記載した表である。
【００８５】
サンプル・バッファにレンダリングする場合、ハードウェア・アクセラレータ１８はＲ、Ｇ、Ｂ、ＡをバッファＡに書き込み、さらにＳおよびＺも書き込むことができる。ＳおよびＺは、最終シーンでどのサンプルが見えるかを決定する、ステンシルおよび隠面消去オペレーションに必要となる。最終シーンでＲＧＢカラー値に影響を与える可能性のある合成および透過性のために、アルファ（Ａ）を使用することができる。
【００８６】
フィルタリングの際、ハードウェア・アクセラレータ１８は、サンプル・バッファからＲ、Ｇ、Ｂを読み取り、フィルタリング結果を（ＰＸユニットおよびフラグメント・パイプを介して）表示バッファ（バッファＡまたはバッファＢのいずれか、ダブル・バッファされたレンダリング中に現在「バック」バッファである方）のＲ、Ｇ、Ｂプレーンに書き込むことができる。ウィンドウ・システムは、Ｗおよびオーバレイ・プレーンをフィルタリング・プロセスとは別に維持することが可能であり、Ｗｐ面はＲＧＢの真のカラー表示を発生させるように設定可能である。
【００８７】
表示の際、Ｗｐ面は「フロント」表示バッファから、ＲＧＢの真のカラー表示を選択することができる。
【００８８】
２．１．２ ＦＢメモリ割振り
以下の考察では、フレーム・バッファ２２が、４つのランクに編成された１６のＤＲＡＭメモリ・デバイスを有すると想定される。ただし、フレーム・バッファ内のＤＲＡＭメモリ・デバイスの数は様々ないずれの値を取ってもよく、同様に、フレーム・バッファ内のランク数も様々ないずれの値を取ってもよいことに留意されたい。
【００８９】
単一のＤＲＡＭメモリ・デバイスは、６４０×５１２のデータ・アイテム用の記憶域を含むことができる。（データ・アイテムは、図３で提案されたように１１６ビットを有することができる。）したがって、フレーム・バッファは、最高１６×６４０×５１２＝５１２０Ｋのデータ・アイテムを格納することができる。各データ・アイテムがピクセルまたはサンプルを表すことができる。一実施形態では、ＤＲＡＭメモリ・デバイスの半分がビデオ出力プロセッサに結合され、ＤＲＡＭメモリ・デバイスの残りの半分はそのように結合されない。これらの実施形態では、フレーム・バッファは、最高２５６０Ｋの表示ピクセル（すなわちオンスクリーン・メモリ・ピクセル）を格納することができる。
【００９０】
フレーム・バッファ・メモリを割り振るための基本単位が「ページ」と呼ばれる。一実施形態では、１ページに５１２０のデータ・アイテムを含むことができる。したがって、フレーム・バッファ・ページ容量は、５１２０Ｋ／５１２０＝１０２４ページに等しくすることができる。最初の５１２ページが表示可能である。
【００９１】
グラフィックス・レンダリング・システムは、最高Ｎｄｒの表示可能領域をサポートすることが可能であり、Ｎｄｒは正の整数である。一実施形態では、グラフィックス・レンダリング・システムは、最高２つの表示可能領域および無制限数のオフスクリーン領域をサポートすることができる。
【００９２】
たとえば、コンソールが第１の表示可能領域であってよい。第１の表示可能領域は、図５で提案されるように、ＦＢメモリのページ０から開始されるように割り振ることができる。したがって、第１の表示可能領域にＤ１ページが割り振られた場合、第１の表示可能領域はページ０からＤ１−１までを占有することになる。
【００９３】
第２の表示可能領域がある場合、コンソールのすぐ上に割り振ることができる。例では、第２の表示可能領域にＤ２ページが割り振られた場合、第２の表示可能領域はページＤ１からＤ１＋Ｄ２−１までを占有することが可能であり、ここでＤ１＋Ｄ２＜＝５１２ページである。記号「＜＝」は「より少ないかまたは等しい」ことを示す。
【００９４】
スーパーサンプリングが要求された場合、オフスクリーン・スーパーサンプリング領域はＦＢメモリの頂部（ページ１０２３より下方から）に割り振ることができる。例では、Ｓ１ページが割り振られる場合、オフスクリーン・スーパーサンプリング領域は１０２４−Ｓ１から１０２３までを占有することが可能であり、ここでＳ１＋Ｄ１＋Ｄ２＜＝１０２４である。
【００９５】
追加のオフスクリーン・メモリが割り振られた場合、第１のスーパーサンプリング領域よりも下まで及ぶ可能性がある。
【００９６】
所与のフレーム・バッファ記憶モード（ＦＢ＿＊＿ＭＯＤＥレジスタによって設定）では、各割振りページが、固定されたピクセル高さと幅を有する。図６の表は、グラフィックス・レンダリング・システムの一実施形態に従った、様々なＦＢ＿ＭＯＤＥオプションでのページ・サイズを列挙したものである。サンプル密度が２のべき乗でない場合、２のべき乗でない数は２のべき乗で割り切れないため、割振りページの幅掛ける高さは５１２０データ・アイテムのページ容量よりも少なくなる。
【００９７】
フレーム・バッファ領域は四角形の領域である。領域の幅は割振りページ幅の整数倍に対応する。領域の高さは割振りページ高さの整数倍に対応する。端数サイズの領域（領域幅がページ幅の整数倍でないか、または領域高さがページ高さの整数倍でない）が所望の場合、次に大きな整数倍幅および整数倍高さを割り振ることができる。
ｗｉｄｔｈＰａｇｅｓ＝ｒｏｕｎｄｕｐ（ｗｉｄｔｈＰｉｘｅｌｓ／ｐａｇｅＷｉｄｔｈ）
ｈｅｉｇｈｔＰａｇｅｓ＝ｒｏｕｎｄｕｐ（ｈｅｉｇｈｔＰｉｘｅｌｓ／ｐａｇｅＨｅｉｇｈｔ）
割り振られる合計領域（ページ単位）は、単純に領域の幅と高さの積である（どちらも整数ページに切り上げられる）。
ａｒｅａＰａｇｅｓ＝ｗｉｄｔｈＰａｇｅｓ＊ｈｅｉｇｈｔＰａｇｅｓ
たとえば、１１５２×９００の非立体表示用のＦＢメモリ領域を割り振るためには、ｐａｇｅＷｉｄｔｈが３２０でありｐｅｇｅＨｅｉｇｈｔが１６であることに留意されたい。以下の計算式は、１１５２×９００の表示領域が、２２８ページを有するフレーム・バッファ領域でカバーできることを示すものである。
ｗｉｄｔｈＰａｇｅｓ＝４ ｐａｇｅｓ ｗｉｄｅ＝ｒｏｕｎｄｕｐ（１１５２／３２０）
ｈｅｉｇｈｔＰａｇｅｓ＝５７ ｐａｇｅｓ ｈｉｇｈ＝ｒｏｕｎｄｕｐ（９００／１６）
ａｒｅａＰａｇｅｓ＝２２８ ｐａｇｅｓ＝４＊５７
グラフィックス・ウィンドウが７００×７００ピクセルを有するものと想定すると、オフスクリーン・スーパーサンプル・バッファはサンプル密度４でウィンドウに割り振られることになる（すなわち単位ピクセル領域あたり４つのサンプルが生成される）。サンプル密度４の場合、ｐａｇｅＷｉｄｔｈは８０でありｐａｇｅＨｅｉｇｈｔは１６である。以下の計算式は、スーパーサンプル・バッファに３９６ページのフレーム・バッファが割り振られることを示すものである。
ｗｉｄｇｈＰａｇｅｓ＝９ ｐａｇｅｓ ｗｉｄｅ＝ｒｏｕｎｄｕｐ（７００／８０）
ｈｅｉｇｈｔＰａｇｅｓ＝４４ ｐａｇｅｓ ｈｉｇｈ＝ｒｏｕｎｄｕｐ（７００／１６）
ａｒｅａＰａｇｅｓ＝３９６ ｐａｇｅｓ＝９＊４４
ライブラリ機能は、所望のピクセル単位の高さと幅と共にＦＢ＿ＭＯＤＥを指定してＦＢ領域を割り振るために、メモリ割振り要求をアサートすることができる。ソフトウェア・ドライバは上記の計算を実行し、所望の領域を所望のＦＢ＿ＭＯＤＥで格納するのに必要なページ数を割り振ることが可能であり、失敗／成功状態とＦＢ＿ＢＡＳＥ（最初に割り振られたページ）およびＦＢ＿ＳＴＲＩＤＥ（割り振られた領域のページ単位の幅）とを戻す。ドライバは、その後の要求時に使用するために、割り振られた領域の独自の記録も維持することができる。
【００９８】
まだ割り振られずに残っているメモリの量の照会、ならびに、指定のモード、高さ、および幅が要求された場合にはどれだけの量のメモリが割り振られることになるのかを確認するための他の照会を実行するライブラリ機能も可能である。
【００９９】
Ｗｄ×Ｈｄピクセルを有する表示のための（ダブル・バッファされた）ピクセル表示バッファが割り振られるものと想定する。この表示をサポートするために、ドライバは以下の式によって整数のＦＢメモリ・ページを割り振ることが可能であり、
ｃｅｉｌｉｎｇ（Ｗｄ／ｐａｇｅＷｉｄｔｈ）＊ｃｅｉｌｉｎｇ（Ｈｄ／ｐａｇｅＨｅｉｇｈｔ）
上式で、ｐａｇｅＷｉｄｔｈおよびｐａｇｅＨｅｉｇｈｔはそれぞれＦＢメモリ・ページの幅および高さである。ｐａｇｅＷｉｄｔｈおよびｐａｇｅＨｅｉｇｈｔの値は、ＦＢメモリ割振りモードに応じて変化する。モードは、割り振られるバッファが表示バッファとして働くものであるか、またはオフスクリーン・バッファとして働くものであるかを示すことができる。さらにモードは、表示バッファが立体用に構成されるものであるか、非立体用に構成されるものであるか、あるいはオフスクリーン・バッファがピクセル用に使用されるものであるか、サンプル用に使用されるものであるかも示すことができる。後者の場合、モードはサンプル密度、すなわちピクセルあたりのサンプル数を示すことができる。
【０１００】
ウィンドウ・システムでは、グラフィックス・レンダリング・システムは全画面サイズよりも小さいウィンドウにレンダリングすることができる。ウィンドウがＷｗ×Ｈｗピクセル・サイズを有すると想定すると、サンプル・フィルタ（ＳＦ）はＷｆ×Ｈｆピクセルのフットプリントを有し、サンプル密度はＤＳである。この場合ドライバは、ウィンドウに対応するオフスクリーン・サンプル・バッファに関して、以下の式で与えられる整数のＦＢメモリ・ページを割り振ることができる。
Ｃｅｉｌｉｎｇ｛（Ｗｗ＋Ｗｆ）／ｐａｇｅＷｉｄｔｈ｝＊Ｃｅｉｌｉｎｇ｛（Ｈｗ＋Ｈｆ）／ｐａｇｅＨｅｉｇｈｔ｝
【０１０１】
オフスクリーン・サンプル・バッファが、サンプル・フィルタ・フットプリントの「スカート」を収容するためのＷｗ×Ｈｗウィンドウを囲む境界線を含むことに留意されたい。フットプリントを備えた拡大されていないボックス・フィルタが厳密に表示されるピクセルであるという特殊なケースでは、Ｗｆ×Ｈｆはゼロであり（ピクセル外部からの寄与がないため）、特別な境界線割振りは不要である。
【０１０２】
有限のＦＢ容量は、表示バッファとサンプル・バッファで共用される。したがって最大サンプル密度はほぼ以下に等しく、
Ｆｌｏｏｒ｛データ・アイテム単位のＦＢサイズ−ピクセル単位の表示サイズ）÷（ピクセル単位のウィンドウ・サイズ）｝
ここでＦｌｏｏｒ｛ｘ｝は整数下限関数である。これは、解像度の低い表示および／またはサイズの小さいウィンドウが、固定サイズのサンプル・バッファ内でより高いサンプル密度をサポートできることを暗に示している。
【０１０３】
例：
単一ヘッドの１２８０×１０２４非立体表示の場合、表示バッファは（ｃｅｉｌ（１２８０／３２０）＊ｃｅｉｌ（１０２４／１６））＝２５６ページのＦＢメモリを使用する。これで、（１０２４−２５６）＝７６８ページが、１ページあたり５１２０サンプルでサンプル・バッファ用に残される。
１０００×１０００ピクセル・ウィンドウは（ｃｅｉｌ（１０００／８０）＊ｃｅｉｌ（１０００／２０）６５０ページであり、７６８ページよりも少ないため、サンプル密度３をサポートすることができる。
７２０×６７０ピクセル・ウィンドウはｃｅｉｌ（７２０／４０）＊ｃｅｉｌ（６７０／１６）＝７５６ページであり、７６８ページよりも少ないため、サンプル密度８をサポートすることができる。
【０１０４】
単一ヘッドの９６０×６８０立体表示の場合、表示バッファは（ｃｅｉｌ（９６０／３２０）＊ｃｅｉｌ（６８０／８））＝２５５ページのＦＢメモリを使用する。これで（１０２４−２５５）＝７６９ページがサンプル・バッファ用に残される。したがって、第１の例と同じサイズのウィンドウをサポートすることができる。
【０１０５】
単一ヘッドの６４０×４８０立体ＶＧＡ表示の場合、表示バッファは（ｃｅｉｌ（６４０／３２０）＊ｃｅｉｌ（４８０／８））＝１２０ページのＦＢメモリを使用する。これで（１０２４−１２０）＝９０４ページがサンプル・バッファ用に残される。ｃｅｉｌ（６００／４０）＊ｃｅｉｌ（４８０／８）＝９００ページであり、９０４ページよりも少ないため、ほぼ全画面のウィンドウ（６００×４８０）はサンプル密度１６をサポートする。
【０１０６】
２．２ レンダリングおよびフィルタリング段階
マルチサンプリングを使用してシーン・フレームをレンダリングするために、グラフィックス・レンダリング・システムは一連のステップを実行する。この一連のステップは、シーン・アニメーション中、何回も繰り返される。以下の記述は、ウィンドウ・サイズ（フィルタ・フットプリントを加える）のサンプル・レンダリング・バッファおよびスクリーン・サイズのピクセル表示バッファがＦＢメモリで事前に割り振られていると想定したものである。
【０１０７】
２．２．１ サンプル・レンダリング・バッファのクリア
レンダリングの前に、（ウィンドウ・サイズの）サンプル・バッファにあるサンプルは、深さを無限にしてステンシル・プレーンをリセットした背景ＲＧＢカラーへと「クリア」される。高速フィル機能は、このステップを加速させるものである。一実施形態では、高速フィル機能はおよそ５３億サンプル／秒で動作可能である。
【０１０８】
図７は、この流れを表す図である。ラスタ化パイプはウィンドウ領域のサンプル・ブロック・アドレスを生成し、フラグメント・パイプはＦＢメモリ内にサンプル・ブロックを充てんする。クリア・オペレーションでアクティブでない経路は点線で示されている。
【０１０９】
２．２．２ サンプル・バッファへのマルチサンプルのレンダリング
次に、図８および９に示されるように、シーンを定義する頂点（および属性）データが、３−Ｄストリーム・レンダリング経路を介し、ＦＢで割り振られたサンプル・バッファをターゲットとして送信され、マルチサンプリングされたレンダリングを実行可能にする。
【０１１０】
メディア・プロセッサ１４（すなわちグラフィックス・プリプロセッサおよびプロセッサ・ユニット）は、シーン内の各頂点において、変換、ライティング、およびクリップ・コード生成機能を実行することができる。これらの機能は、ＯｐｅｎＧＬ標準または何らかの他の標準に準拠した方法で実行することができる。
【０１１１】
頂点は、ＯｐｅｎＧＬ標準によってプリミティブ（典型的には三角形）にアセンブルすることができる。クリップ・テストおよびフェース−カリング・テストに合格したプリミティブがラスタ化される。この作業は、頂点プロセッサおよびラスタ化パイプラインによって実行することができる。（ラスタ化パイプラインＲＰには、図１Ｃで提案されるように、プリセットアップ・ユニットＰＳＵ、セットアップ・ユニットＳＵ、エッジ・ウォーカＥＷ、およびスパン・ウォーカＳＷユニットが含まれることを想起されたい。）
【０１１２】
ラスタ化パイプラインＲＰは、位置（ｘ，ｙ）、テクスチャ座標（ｓ，ｔ，ｒ）、ならびに深さ（ｚ）およびカラー（ｒ，ｇ，ｂ，ａ）の値で、ピクセルを生成する。
【０１１３】
テクスチャ処理経路には、テクスチャ・アドレス・ユニット（ＴＡ）およびテクスチャ・フィルタ（ＴＦ）ユニットが含まれる。テクスチャ処理経路は、単一のテクスチャ座標ベクトル（ｓ，ｔ，ｒ）に基づいて、最高のテクセル・サンプル（たとえばＮｔｍｓ＝８）をテクスチャ・メモリ２０から読み取り、（ｓ，ｔ，ｒ）での１ピクセルあたりのテクスチャ・カラーを決定するために、これらのテクセル・サンプルをフィルタリングする。一部の実施では、テクスチャ処理経路は複数のテクスチャ座標を受け入れ、１ピクセルについて複数のテクスチャ結果（「マルチテクスチャ」）を生成することができる。
【０１１４】
サンプル生成器ＳＧは、各サンプルのサブピクセル位置をピクセル単位で決定し、どのサンプルがプリミティブ内部にあるかを決定する。サンプル評価器ＳＥは、サンプル・マスクおよび（ｒ，ｇ，ｂ，ａ，ｚ）に対するサンプルあたりの値を生成する。
【０１１５】
サンプル処理パイプラインおよびテクスチャ処理パイプラインは非同期的に動作し、一般に様々なピクセルあたりのデータ量を生成する。これには、パイプラインを他のパイプラインより多少前または後のいずれかに実行できるようにする待ち行列が含まれる。
【０１１６】
各ピクセルについて、テクスチャ環境ユニットＴＥは、テクスチャ・パイプラインからの（ピクセルあたりの）テクスチャ・カラーを、そのピクセルから生成されたすべてのサンプルに適用する。最終的にテクスチャ化されたピクセル・カラーは、ＯｐｅｎＧＬテクスチャ環境関数を使用して、またはマルチテクスチャの場合には、ＯｐｅｎＧＬマルチテクスチャ拡張を使用して適用することができる。したがってテクスチャ環境は、各ピクセルから複数のテクスチャ化されたサンプルを生成する（フラグメント・サンプルとも呼ばれる）。
【０１１７】
フレーム・バッファを形成するそれぞれのＤＲＡＭメモリ・デバイスが、本明細書ではメモリ組込み型ピクセル・プロセッサと称される、１つまたは複数のピクセル・プロセッサを含むことができる。Ｍｉｔｓｕｂｉｓｈｉの製造する３ＤＲＡＭメモリ・デバイスは、こうしたメモリ組込み型ピクセル・プロセッサを備えるものである。
【０１１８】
フラグメント（テクスチャ化されたサンプル）はフラグメント・パイプおよびメモリ組込み型ピクセル・プロセッサによって処理され、フレーム・バッファ・メモリ内の事前に割り振られたサンプル・バッファ領域に書き込まれる。メモリ組込み型ピクセル・プロセッサは、標準のＯｐｅｎＧＬフラグメント処理動作（たとえばブレンド、ステンシル、Ｚバッファリングなど）を適用することができる。
【０１１９】
一般に、同じシーン・フレーム内で、複数のプリミティブが同じサンプル位置にサンプル値を与えることができる。こうしたサンプル（すなわち非透過サンプル）の多くについて、Ｚバッファリング・オペレーションは、「勝った」プリミティブ（通常は視聴者に最も近いもの）からサンプル値を選択することになる。この隠面消去プロセスにより、シーン内で以前にレンダリングされたサンプルの一部を、シーン内で後にレンダリングされたサンプルに置き換えることができる。「深さの複雑性」という語は、各サンプルを更新するための試行のシーンあたりの平均回数を表すために使用される。目の位置から見ると多くのオブジェクトが相互に前後に散乱したシーンは、深さの複雑性が高いことになる。
【０１２０】
２．２．３ バック表示バッファへのサンプル・バッファのフィルタリング
それぞれのフレーム時に、シーンがサンプル・バッファに完全にレンダリングされると、各サンプルについて最終的に「勝った値」が残る。この時点で、ピクセル転送ユニットＰＸおよびフラグメント・パイプラインＦＰを介してフレーム・バッファ２２内のピクセル表示バッファ領域にルーティングされ、スパン・ウォーカ・ユニットＳＷ内のピクセル・コピー・アドレス生成ハードウェアおよびピクセル・コピー・データ経路を再使用する、フィルタリング済みピクセルのアレイを取得するために、サンプル・フィルタＳＦがサンプル・バッファからのサンプルに適用される。
【０１２１】
コピー、フィルタリング、および累算オペレーションは、ストリーム・コマンドの特別なグループであり、ラスタ化パイプＲＰは、ＴＢとＦＢの間、またはこれら内部でのデータの転送を含むメモリ・アドレス生成器となる。コピー経路は図１０で強調されている。オペレーションは、ＦＰ、ＰＸ、コピー、フィルタリング、または累算属性をセットアップするための一連のＢＲＳレジスタ書込み、ならびにそれに続くコピー領域「頂点」（ソースおよび宛先の左上隅、共通の高さと幅）を定義するＶＰへのＢＲＳ書込みによってセットアップすることができる。一実施形態では、コピー領域幅が最後に書き込まれ、コピー・オペレーションをトリガする。ラスタ化パイプはアドレス生成器となり、領域全体のピクセル／テクセル・データの転送を誘導する。コピーが完了すると、ＲＰは通常の処理に戻ることができる。
【０１２２】
図１１は、コピー・フィルタリング、および累算オペレーションに関するデータの流れを示す図である。この図では、図面を簡略化するために、アドレス生成器が２つの別々のボックスとして示される。２つのボックスが識別される。テクスチャ・バッファ２０およびフレーム・バッファ２２も同様に、図面を簡略化するために２重になっている。イメージ・フィルタという語は、テクスチャ・フィルタＴＦのもう１つの名前である。
【０１２３】
コピーおよびサンプル・フィルタ・オペレーション
ブロック・コピー・オペレーションは、ピクセル／テクセルの四角形の領域を、ソース・バッファ内のソース領域から宛先バッファ内の宛先領域に移動するものである。簡単なブロック・コピー・オペレーションには、以下の４種類がある。
・フレーム・バッファからフレーム・バッファへ
・フレーム・バッファからテクスチャ・バッファへ
・テクスチャ・バッファからテクスチャ・バッファへ
・テクスチャ・バッファからフレーム・バッファへ
【０１２４】
図１２は、ピクセル・コピー用のアドレス生成（すなわち、ＦＢからＦＢへのブロック・コピー・オペレーション）を示す図である。ソースは、ストリーム経路ＲＤ＿ＰＤＴレジスタがＰＤ＿ＰＤＴ＿ＰＩＸに設定されている場合はフレーム・バッファ内にあり、ＲＤ＿ＰＤＴ＿ＴＥＸの場合はテクスチャ・バッファ内にある。宛先は、ストリーム経路ＷＲ＿ＰＤＴレジスタがＷＲ＿ＰＤＴ＿ＰＩＸに設定されている場合はフレーム・バッファ内にあり、ＷＲ＿ＰＤＴ＿ＴＥＸの場合はテクスチャ・バッファ内にある。ピクセル転送ブロック機能は、どんなブロック・コピー・オペレーション時にも使用できる。
【０１２５】
ブロック・コピー・アドレッシング。ソース領域および宛先領域の左上隅は、ＣＯＰＹ＿｛Ｘ，Ｙ｝レジスタおよびＲＥＣＴ＿｛Ｘ，Ｙ｝レジスタによって定義される。ＲＥＣＴ＿｛Ｈ，Ｗ｝は、ソース領域および宛先領域の（共通の）サイズを定義する。これらすべての値には位置合わせの制約がなく、領域は１つのピクセルの解像度を使用して位置決めおよびサイズ変更することができる。ソース領域および宛先領域は、それぞれ割り振られたソースおよび宛先のメモリ・バッファ内に位置する。ソースまたは宛先がフレーム・バッファの場合、メモリ・バッファの起点はＦＢ＿｛ＲＤ，ＷＲ｝＿ＢＡＳＥである。
【０１２６】
一実施形態では、ホスト・ルーチンが、各アニメーション・フレームをレンダリングするためのマルチパス・プロシージャ内の各パスについて、宛先領域を再プログラミングすることができる。
【０１２７】
スーパーサンプル・フィルタ（ＳＳＦ）。フレーム・バッファのスーパーサンプル・バッファ領域にレンダリングされた確率的にサンプリングされたシーンをフィルタリングするために、特別なフィルタが提供される。このオペレーションは、オフスクリーンのスーパーサンプリングされたレンダリング・ソースからオンスクリーンのピクセル表示宛先までのフィルタを使用する、特殊な「フレーム・バッファ間コピー」である。
【０１２８】
図１３〜１５は、サンプル・フィルタリングのためのアドレス生成およびフットプリントを示す図である。
【０１２９】
スーパーサンプル・フィルタ・アドレッシング。ソース領域および宛先領域は、ＣＯＰＹ＿｛Ｘ，Ｙ｝、ＲＥＣＴ＿｛Ｘ，Ｙ｝、およびＲＥＣＴ＿｛Ｈ，Ｗ｝によって再度定義される。ソースはフレーム・バッファのスーパーサンプリングされた領域にあり、宛先はフレーム・バッファのピクセル領域に常駐する。
【０１３０】
単一のソース・ポイントの代わりに、フィルタ「カーネル」領域（たとえば一実施形態では、ソース空間で、各宛先アドレスに対応するソース・アドレスを中心とし、半径が最高２ピクセルのディスク形領域）が読み取られる。ソース・アドレスがソース領域のエッジ上またはその直近にある場合、カーネルの一部がソース領域の外に出る可能性がある（図１３のサンプル「ｓ」を参照）。ソース領域の外に出るカーネルの一部のソースは、ＳＳＦ＿ＭＯＤＥ＿ＢＯＲＤＥＲによって決定される。
【０１３１】
スーパーサンプル・フィルタ・プログラミング・モデル。スーパーサンプル・フィルタリングには、宛先スペース内のピクセルに対応する、ソース・スペース（ビン・スペースとも呼ばれる）内の位置を中心とした、フィルタ・サポート領域内に収まるすべてのサンプルのカラー（ｒｇｂａ）の重み付けされた合計を算出することが含まれる。（ソース・スペース内のピクセルもビンと称されることに留意されたい。）
【０１３２】
それぞれの出力ピクセルについて、ハードウェアはソース・スペース内のカーネル中心（すなわちフィルタ・サポートの中心）を算出する。ただし、第１（または左最上部）のカーネル中心の位置は、ソフトウェアによってＲＥＣＴ＿｛Ｘ，Ｙ｝に設定される。オプションで、ＳＳＦ＿ＭＯＤＥ＿ＯＦＦＳＥＴ＿ＥＮＡＢＬＥ（「スーパーサンプル・フィルタ・モード・オフセット実行可能レジスタ」）を使用して、（０．５，０．５）だけオフセットすることができる。カーネル中心用のその後の座標は、ハードウェア・アクセラレータにより、ＳＳＦ＿ＳＴＥＰ＿ＳＩＺＥレジスタ（「スーパーサンプル・フィルタ・ステップ・サイズ・レジスタ」）を使用して増分で算出される。これは、ＸおよびＹの両方向に沿ったｓｔｅｐ＿ｓｉｚｅであってよい。
【０１３３】
拡大比率。宛先領域は、ソース領域に等しいかまたはこれより大きくてよい。宛先幅対ソース幅の比率が、拡大比率と呼ばれる。これは、ＳＳＦ＿ＳＴＥＰ＿ＳＩＺＥの値を選択することによって、間接的に指定することが可能であり、その結果、拡大比率は１．０／ＳＳＦ＿ＳＴＥＰ＿ＳＩＺＥとなる。
【０１３４】
フィルタ・タイプ。一実施形態では、スーパーサンプル・フィルタが使用するフィルタ機能は、ボックス・フィルタまたは円形フィルタのいずれかであってよい。この選択は、ＳＳＦ＿ＭＯＤＥレジスタで指定される。フィルタの半径は、本明細書ではＳＳＦ＿ＦＩＬＴＥＲ＿ＲＡＤＩＵＳと称されるレジスタで指定することができる。
【０１３５】
ボックス・フィルタ。ボックス・フィルタは正方形のフィルタである。長さ寸法がフィルタ半径、ＳＳＦ＿ＦＩＬＴＥＲ＿ＲＡＤＩＵＳの２倍である。各サンプルに、同じ（最大）重さが与えられる。このフィルタは、カーネルによってカバーされるサンプル・ポイントのカラーの平均を取る。
【０１３６】
図１４は、ボックス・フィルタの場合の、ＳＳＦ読取り「フットプリント」（すなわち、サンプルを１つのフィルタリング済みピクセルに与えるビンのセット）の概念を紹介する図である。図には２つの例が示されており、それぞれ半径が０．５である。
・オフセットが（０．５，０．５）でステップ・サイズが１．０（拡大なし）であれば、第１のピクセルについて（オフセットにより）、ならびに他のすべてのピクセルについて（ステップ・サイズにより）、ソース・スペースでのフットプリントは１×１である。これが図１４の左側に図示されている。
・ただし、拡大比率が１．０より大きいか、またはオフセットが（０．５，０．５）でない場合、図１４の右側に示されるように、フットプリントは一般に２×２となる。右側の場合は、左側の場合よりもゆっくりと実行される。
【０１３７】
円形フィルタ。名前からわかるように、このフィルタのカーネルはソース・スペースにおいて円形である。それぞれ半径が２．０の２つの例が、図１５に示されている。左の例は、現在のカーネル中心がビンの左隅にある場合に対応する。これは、オフセットが（０．０，０．０）であり、拡大比率が１．０である場合に対応する。
【０１３８】
図１５の右側の例は、現在のカーネル中心がビンの左隅にない場合に対応する。これは、たとえ初期オフセットが（０．０，０．０）であっても、拡大比率が１．０でない場合に対応する。カーネル・サークル（すなわちディスク）内にあるすべてのサンプルが、重み付け合計に寄与する。タイル（たとえば２×２タイルのビン）内のサンプルの位置は、本明細書ではＳＳＦ＿ＪＩＴＴＥＲ ＴＡＢＬＥと称されるスーパーサンプル・ジッタ・テーブルで指定される。これらのジッタ値は、最終サンプル位置に到達するために、必要であれば置き換えることができる（詳細は本項の最後で説明）。各サンプル位置でのフィルタ重みは、そのカーネル中心からの半径距離に依存する。
【０１３９】
フィルタ重みは、半径距離ｒの関数を表すものである。一実施形態では、フィルタ重みは１２８個の値のテーブルで提供され、それぞれの重みは範囲（−１．０，１．０）であり、フォーマットｓ．１０である。テーブルは（ｎｒ）２で索引付けすることができる。これは、アクセス速度が速く、ゲート・カウントが少ない、ハードウェア・フレンドリに設計される。ここでｎｒは単に正規化された半径距離、ｒ／Ｒであり、ｒはカーネル半径である。
・サンプル密度、すなわちビンあたりのサンプル数。
・置換え制御。実行可能であれば、ソース・スペース・タイル内のサンプル（１タイルは２×２平方ビン）が置き換えられ、その結果１２８×１２８ビン境界でのみ複製されるように発生し、その他の場合にはサンプルは２×２ビンごとに複製される。
・一時エイリアス除去用の置換えコード（範囲［０，７］）。これにより、各フレームで最高８つの異なるパターンを可能にするために、置換えコードに応じて各フレームで様々なタイルの置換えが可能になる。
使用される実際のサンプルは、ＳＳＦ＿ＳＡＭＰＬＥ＿ＭＡＳＫで選択することができる。
【０１４０】
コピー・オペレーションの詳細な説明
コピー・オペレーションは、ＦＢまたはＴＢのいずれかからＦＢまたはＴＢのいずれかへ、四角形のピクセル・アレイを移動する。これには、２つの２−Ｄアドレス（すなわちソースおよび宛先）が含まれる。ソフトウェアは、ソースと宛先の四角形をプリクリップする。
ソース・データは、以下のいずれかであってよい。
・フレーム・バッファ・メモリ（ＦＢ）からのピクセル
・オンスクリーン（可視）フレーム・バッファからのピクセル
・オフスクリーン・ピクセル・バッファからのピクセル
・フレーム・バッファ・メモリ（ＦＢ）からのサンプル
・オフスクリーン・スーパーサンプル・バッファからのサンプル
・テクスチャ・バッファ・メモリ（ＴＢ）からのピクセルまたはテクセル
・テクスチャ・マップからのテクセル
・イメージ・バッファからのピクセル
データは、以下のいずれかにコピーすることができる。
・ピクセルをフレーム・バッファ・メモリ（ＦＢ）へ
・ピクセルをオンスクリーン（可視）フレーム・バッファへ
・ピクセルをオフスクリーン・ピクセル・バッファへ
・ピクセルをテクスチャ・バッファ・メモリ（ＴＢ）へ
・ピクセルをテクスチャ・マップへ
・ピクセルをイメージ・バッファへ
【０１４１】
以下の考察で使用されるいくつかの頭字語の凡例を示す。
ＦＷＱ＝フレーム・バッファ書込み待ち行列
ＦＲＱ＝フレーム・バッファ読取り待ち行列
ＴＷＱ＝テクスチャ・バッファ書込み待ち行列
ＴＲＱ＝テクスチャ・バッファ読取り待ち行列
ＴＲＢ＝テクスチャ・バッファ読取りバッファ
【０１４２】
スパン・ウォーカ・ユニット（ＳＷ）は２つのアドレスを生成する。ＳＷユニットはＴＢアドレスをＴＡブロックに送信し、これがＴＢＭおよびＴＢＩ（テクスチャ・バッファ・インターフェース）に供給する。ＳＷは、ＳＧ、ＳＥ、ＦＤＰを介してＦＢアドレスをＴＥに送信し、これがＦＰおよびＦＢＩに供給する。ソース・アドレスは、ＦＢまたはＴＢ読取り待ち時間をカバーする十分な先取りを可能にするために、宛先アドレスの前（たとえば一実施形態では約４０〜６０クロック前）に生成することができる。
【０１４３】
ソース・データは、ＦＲＢブロックまたはＴＲＢブロックからＰＸＭに読み取られ、ピクセル転送ユニット（ＰＸ）に供給される。ＰＸユニットは、データの再フォーマット、スケーリング、バイアス、および／または検索（すなわちテーブル・ルックアップの実行）を実行することができる。ＰＸ結果データは、ＴＥまたはＴＢＭ（それぞれＦＢまたはＴＢのコピー宛先の場合）に送信される。ＴＥまたはＴＢＭは、（ＳＷ読取りアドレスによって指定された）ＰＸ読取りデータがＳＷ書取りアドレスと一致する、「結合」ポイントである。書込みアドレスが（ＳＷまたはＴＡから）着信する前に書込みデータが（ＰＸから）着信するか、またはその逆の場合、ＴＥ／ＴＢＭは、ＰＸまたはＳＷのいずれか前の方を、後のユニットの準備が整うまでストールすることになる。以下のようないくつかの特殊なケースがある。
【０１４４】
・同じバッファ間でのコピー（ＴＢからＴＢ、またはＦＢからＦＢ）により、ソース領域と宛先領域が重なり合うがある。したがってアドレス・スキャン・パターンは、コピーが発生する前にソースが重なり合うのを防ぐために、昇順および降順の両方でのオペレーションが可能である。
【０１４５】
・フレーム・バッファ（ＦＢ）２２が宛先である場合、フラグメント処理はフレーム・バッファへの途中で実行することができる。
【０１４６】
・一部の実施形態では、フレーム・バッファがソースの場合、ソース領域が読み出されたときの状態にクリアされるように要求することができる。これは、コピー・オペレーションと並行して、読み出されたときの状態のソース領域に対して高速フィル・オペレーションを効率的に実行する。
【０１４７】
・一実施形態では、異なるバッファ間（ＴＢからＦＢ、またはＦＢからＴＢ）でのコピーが、ＧＣＫあたり１ピクセルで発生可能であり、パイプライン化される。ＳＷはｘ，ｙフィールド（フル・タイルの場合）を介してＦＢアドレスを指定することが可能であり、ＴＡユニットからのｕ，ｖ出力を介してＴＢアドレスを指定する。
【０１４８】
・同じバッファ間（ＴＢからＴＢ、またはＦＢからＦＢ）でのコピーの場合、ＴＢおよびＦＢがそれぞれ単一のアドレス・バスを有することから、ＳＷは、書込みのバーストと交互に読取りのバーストを生成する。バースト・サイズは、ＦＢおよびＴＢ読取りパイプラインの待ち時間（一実施形態では、およそ３０〜４０ＧＣＫと推定される）によって決定することが可能であり、（パイプ・ステージにＦＷＱ／ＦＲＱまたはＴＷＱ／ＴＲＱ深さを加えた）ＦＢおよびＴＢパイプライン深さの有効小数であってよい。バーストが大きいほど、メモリ・データ・バス方向を転換させるオーバヘッドを減らし、メモリ・リフレッシュ・バブルを隠して待ち時間を制御するのを助ける。ただし、バースト・サイズがメモリ読取りパイプラインの深さを超えた場合に、デッドロックが発生する可能性がある。
【０１４９】
・一実施形態では、８、１６、または３２ビット・ピクセル・フォーマットの畳み込みおよびコピーは、１つの「ＴＢをＴＢにコピー」コマンドまたは１つの「ＴＢをＦＢにコピー」コマンドで、最高４つの構成要素（Ｒ、Ｇ、Ｂ、Ａ）をサポートすることができる。
【０１５０】
・より大きなピクセル・フォーマットの畳み込みおよびコピーには、複数のコピーが必要になる場合がある。たとえば、６４ビット・ピクセル・フォーマットの構成要素は、２つの別々のコピー・コマンドで転送することができる。
【０１５１】
・イメージ変換は、コピー・オペレーションの代わりに、イメージを四角形（補間済みＲＥＣＴＡＮＧＬＥコマンド）またはＴＲＩＡＮＧＬＥストリップにテクスチャ・マッピングすることによって達成可能である。ハードウェア・アクセラレータ１８は、ＴＢからＦＢへのイメージ変換をサポートすることができる。
【０１５２】
・立体モードに関するＦＢからＦＢへのコピーは、片目のみ（左または右）のコピー、または両目のコピーという、２つの特色で実行することができる。
【０１５３】
・ピクセルあたりの選択サンプルが１つのループでコピーされる場合、スーパーサンプル・モードでコピーする。
【０１５４】
コピー・フォーマットおよび宛先
コピーのソース、宛先、およびフォーマットは、ＲＰ＿｛ＲＤ，ＷＲ，ＲＷ｝＿ＰＤＴレジスタおよびＲＰ＿｛ＲＤ，ＷＲ，ＲＷ｝＿ＴＩＦレジスタで定義される。ＲＰ＿ＲＤ＿ＰＤＴレジスタの＿ＴＥＸフィールドはコピーされるデータのソースを定義し、ＲＰ＿ＷＲ＿ＰＤＴレジスタの＿ＴＥＸフィールドは宛先を定義する。
・ＳＷは、レジスタによって指定されたソースおよび宛先を使用して、ソースおよび宛先のアドレスを適切に送る。
・ＰＸは、レジスタによって指定されたソースおよび宛先を使用して、受信したデータを適切に送る。
【０１５５】
コピー・メカニズムは、コピー・データ経路のパイプライン段階およびデータ待ち行列（およそ１００のサンプルまたはピクセルについて）でのデータ記憶要素を利用するように編成される。コピー・データ経路には、ＦＲＢ、ＴＥ、ＰＸ、ＦＰ、ＦＷＱ、ＦＢＩが含まれる。
ＦＲＢ：フレーム・バッファ読取りバッファは、ＦＢメモリから読取られるデータ用のバッファである。
ＦＷＱ：フレーム・バッファ書込み待ち行列は、ＦＢメモリ要求（アドレスおよびデータの書込み、またはアドレスの読取り）の待ち行列である。
ＦＢＡ：フレーム・バッファ・アドレッシング・ユニットは、Ｘ，Ｙアドレスをメモリ・ページおよびピクセル／サンプル・アドレスにマッピングする。
ＦＢＩ：フレーム・バッファ・インターフェースはＦＢメモリ制御装置であり、ＤＭＤキャッシュ（たとえば３ＤＲＡＭキャッシュ）、グローバル・バス、およびＤＲＡＭページ制御を含む。
【０１５６】
多くの実施形態では、フィルタ中央アドレスを備えたコピー読取りオペレーション・コードのバッチを、ＴＥ「結合」ポイント（コピー読取りオペレーション・コードおよびアドレスの結果として生じるフィルタリング済み読取りデータが、コピー書込みオペレーション・コードおよびアドレスとペアになる）でデッドロックすることなく、できる限り多く発行し、その後、（フィルタリング済みピクセル・データを、ＦＢの表示領域に書き込むようにＦＰ方向に下方送信する）表示ピクセル・アドレスを備えたコピー書込み要求の合致バッチの発行に切り替えるものであって、このプロセスはすべてのサンプルがフィルタリングされるまで繰り返される。
【０１５７】
図１６は、ソース・アドレス、宛先アドレス、データ、ならびに結合アドレスおよびデータ流れが強調された、ＦＢからＦＢのコピー・オペレーションを示す図である。
【０１５８】
図１７は、スーパーサンプル読取りパス（スーパーサンプル・バッファからフレーム・バッファ）でのオペレーション・コード流れを示す図である。
【０１５９】
図１８は、サンプル・フィルタリングおよびバック表示バッファへのコピーのステップを要約した図である。
・スパン・ウォーカＳＷは、読取りサンプル、フィルタ・サンプル、および書込みピクセルの要求およびアドレスを生成する。読取りおよびフィルタリング要求の各バーストの後には、書込み要求のバーストが続く。
・ＴＥユニットは、読取りサンプルおよびフィルタ・サンプル要求を、フラグメント・パイプを通じてＦＢメモリ２２のサンプル・バッファに渡す。
・ＦＲＢは、フィルタ・フットプリントが単一のピクセルよりも大きいときに、前の円形フィルタ・オペレーションから重なり合うサンプルを再使用できるようにするための、サンプル読取りバッファを含む。
・サンプル・フィルタは、サンプルの畳み込みによって、フィルタリング済みピクセルを生成する。ＲＧＢ結果は、構成要素あたり最高１２ビットまで可能である。
【０１６０】
ピクセルを生成するためのサンプルのフィルタリングに関する詳細については、参照により全文が本明細書に組み込まれた、２００１年１０月３日付け出願のＢｕｒｋ等による「Ｐｒｏｇｒａｍｍａｂｌｅ Ｓａｍｐｌｅ Ｆｉｌｔｅｒｉｎｇ ｆｏｒ Ｉｍａｇｅ Ｒｅｎｄｅｒｉｎｇ」という名称の米国特許出願第０９／９７００７７号を参照されたい。
・ピクセル転送ユニットＰＸは、フィルタリング済みピクセル・データを処理し、ガンマ補正を適用する。
・ＰＸピクセル・データは、ＳＷ書込みアドレスおよびオペレーション・コードとペアにされ、フラグメント・パイプラインを介して、ダブル・バッファされたＦＢメモリの「バック」表示バッファ領域まで送信される。
【０１６１】
２．２．４ バックおよびフロント表示バッファのスワップ
フィルタリング・オペレーションが完了し、フィルタリング済みフレーム・シーンが「バック」表示バッファに入ると、「フロント」と「バック」のバッファ割当てを交換するために「表示バッファのスワップ」オペレーションが実行され、その結果、新しいフレームが可視となり、プロセスが繰り返されるときに次のフィルタリング・フレームを受け取るために、古いフレームの表示バッファが使用可能になる。
【０１６２】
バッファ・スワップ・オペレーションは、新しいＷＩＤ（ウィンドウＩＤ）エントリをウィンドウ・ルックアップ・テーブル（ＷＬＵＴ）に記入することによって実施できる。
【０１６３】
図１９は、表示ステップを要約した図である。ビデオ出力プロセッサ２４（たとえばＸチップ）は、表示バッファのフロント・セグメントからピクセルを読み取り、そのピクセルをＲＧＢ ＤＡＣ（またはビデオ・エンコーダ）に送信する。ＲＧＢ ＤＡＣは、ピクセル・ストリームをアナログ・ビデオ信号に変換し、これが表示用のビデオ出力ポートに提供される。
【０１６４】
２．３ 変形形態
以上、サンプル・レンダリング・プロセス、サンプル・フィルタリング・プロセス、およびピクセル表示プロセスの基本的流れについて述べてきたが、次に、このテーマに関するいくつかの変形形態について論じる。
【０１６５】
２．３．１ フィルタリング済みピクセルの高精度ガンマ補正
以下の考察では、フレーム・バッファのサンプル・バッファが、サンプルあたりカラー構成要素あたり、Ｎｂｐｃ＝１０ビットまで格納することができると想定される。ただし、記載された原理は、パラメータＮｂｐｃの任意の正の整数値への一般化を認めるものである。
【０１６６】
図９に示されたレンダリング・ステップ中に、サンプル値は、ＦＢサンプル・バッファに格納できる構成要素あたり１０ビットよりもより多くのビット精度で知られる。オプションの「ディザリング」ユニットが、サンプル生成器ＳＧに含まれる。「ディザリング」オプションが実行可能であれば、Ｒ、Ｇ、およびＢのサンプル値を、サンプルのアドレスのサブピクセル部分（ＸおよびＹの小数部分）に基づき、１つのＬＳＢ（２−１０）によってディザリングすることができる。サンプル値の小数部には、１つのＬＳＢにＲ、Ｇ、またはＢが加えられることになる。ディザリング機能は、１ＬＳＢずつ増分されるピクセル・サンプル値の小数部を、最低位サンプル値ビットに比例させるものである。
【０１６７】
「サンプル・バッファのフィルタリング／コピー結果を表示バッファへ送る」ステップ（図１８）では、畳み込みオペレーションが「平均」効果を有する。ボックス・フィルタの場合、フィルタは等しく重み付けされたサンプル値の平均を精密に送ることができる。レンダリング・ステップによってサンプルの小数が１ＬＳＢずつ増えた結果、平均は、その小数掛ける１ＬＳＢずつ増えることになり、失われた情報が「回復」される。同じ引数がより複雑なフィルタに対してほぼ真となる。最終的な効果は、サンプル密度をそれぞれ倍にするためにおよそ１ビットを「回復」（または格納された１０ビット精度へ追加）することである。サンプル密度４またはそれ以上の場合、２ビットが回復可能であるため、サンプル・フィルタは、それぞれのカラー構成要素について１２の有効ビットをＰＸユニットに送信することができる。より一般的に言えば、回復可能ビット数はサンプル密度の２を底とする対数として変化する。
【０１６８】
ＰＸユニットには、Ｒ、Ｇ、およびＢに関する「１２ビット・イン：１０ビット・アウト」ルックアップ・テーブルが含まれる。これらは、（線形シェード付きサンプル値とモニタ／人間の眼の機構の非線形特性との相違を補正するための）ガンマ補正機能と共にロードすることができる。多くの従来技術のシステムでは、フレーム・バッファ内に構成要素あたり８ビットしか格納せず、ガンマ補正機能の非線形性により、濃いシェード付き領域ではさらに精度が失われ、これらのシステムでは濃いシェード付き領域が「マッハ・バンド」の量子化を受ける。本明細書に記載されたディザリング・メカニズムによって特別な２ビット入力が回復することで、より多くのフレーム・バッファ・メモリおよびより広いフレーム・バッファ・メモリ・バスにかかる追加のコストなしに、ほとんどのシステムで送ることができるよりも滑らかなイメージのシェーディングが生成される。
【０１６９】
ディザリング済みサンプルから精度を回復させるための平均化に関する詳細については、参照によりその全文が本明細書に組み込まれた、２００１年１月１１日付け出願のＤｅｅｒｉｎｇ等による「Ｒｅｃｏｖｅｒｉｎｇ Ａｄｄｅｄ Ｐｒｅｃｉｓｉｏｎ ｆｒｏｍ Ｌ−Ｂｉｔ Ｓａｍｐｌｅｓ ｂｙ Ｄｉｔｈｅｒｉｎｇ ｔｈｅ Ｓａｍｐｌｅｓ Ｐｒｉｏｒ ｔｏ ａｎ Ａｖｅｒａｇｉｎｇ Ｃｏｍｐｕｔａｔｉｏｎ」という名称の米国特許出願第０９／７６０５１２号を参照されたい。
【０１７０】
２．３．２ 立体ビジョン
立体ビジョン・システムは、１つは左目の視点から見たビュー、１つは右目の視点から見たビューという、シーンの２つのビューをレンダリングおよび表示する。これは、１回目は左目のパースペクティブ変換マトリクスを使用し、次に再度右目のパースペクティブ変換マトリクスを使用することで、同じシーン・ジオメトリを２回レンダリングすることによって達成される。２つのレンダリングは２つの異なる表示バッファに格納される。格納された２つのレンダリングは、２つのビデオ・チャネルによってそれぞれ表示することができる（たとえば「ゴーグル」ヘッド取付け型ディスプレイの場合）。オプションで、格納された２つのレンダリングを同じディスプレイ上に交互に表示することができる（たとえば、位相のずれた左目と右目の液晶「シャッタ」をディスプレイの更新と同期させる、立体眼鏡を使用して見る場合）。
【０１７１】
２つの表示バッファに関する要件により必要な表示メモリは増えるが、サンプル・バッファがスワッピングの前にフィルタリングされて表示バッファにコピーされる場合、サンプル・バッファ要件は増えない。これは、ビデオ・リフレッシュ時にフィルタリングし、それぞれの目に１つずつ、合計２つのサンプル・バッファを必要とするシステムの場合はあてはまらない。
【０１７２】
したがって本明細書で説明する「フィルタリングおよびコピー」の方法は、サンプル・バッファのメモリ要件を倍増させるような出費なしに、立体ビジョンをサポートするものである。
【０１７３】
２．３．３ フィルタリング時クリア
基本的なフレーム処理ループには、以下の形式がある。
ループあたりの合計時間は、次のようになる。
ｃｌｅａｒ＿ｔｉｍｅ＋ｒｅｎｄｅｒ＿ｔｉｍｅ＋ｆｉｌｔｅｒ＿ｃｏｐｙ＿ｔｉｍｅ＋ｓｗａｐ＿ｔｉｍｅ
【０１７５】
サンプル・フィルタリングと並行したサンプル・バッファ・クリア・オペレーションの実行方法に関する教示については、参照によりその全文が本明細書に組み込まれた、Ｌａｖｅｌｌｅ等による「Ｐａｒａｌｌｅｌ Ｒｅａｄ ｗｉｔｈＳｏｕｒｃｅ−Ｃｌｅａｒ Ｏｐｅｒａｔｉｏｎ」という名称の２００２年１月３１日付け出願の米国特許出願第１０／０６６３９７号を参照されたい。
【０１７６】
ＦＢＩに注入された読取り／クリア／書込み機能（上記の出願に記載）を使用して、サンプル・バッファのフィルタリングとサンプル・バッファのクリアを組み合わせることにより、フレーム処理ループを高速化することができる。サンプル・バッファは、サンプルがサンプル・フィルタに読み込まれた直後にクリアされる。読取り／クリア／書込み機能を使用すると、フレーム処理ループは以下のようになる。
これによりクリア時間をフィルタ時間と並行させるため、ループあたりの合計時間は次のようになる。
ｒｅｎｄｅｒ＿ｔｉｍｅ＋ｍａｘ（ｆｉｌｔｅｒ＿ｃｏｐｙ＿ｔｉｍｅ，ｃｌｅａｒ＿ｔｉｍｅ）＋ｓｗａｐ＿ｔｉｍｅ
【０１７８】
たいていのフィルタでは、クリア時間がフィルタ時間よりも短いため、クリア時間が「なし」になる。したがって、上式は以下のように簡略化できる。
ｒｅｎｄｅｒ＿ｔｉｍｅ＋ｆｉｌｔｅｒ＿ｃｏｐｙ＿ｔｉｍｅ＋ｓｗａｐ＿ｔｉｍｅ
【０１７９】
２．４ レンダリング性能パラメータ
様々な方法の性能を理解するには、何らかの主要な性能パラメータを定義することが役立つ。図２０は、レンダリング性能パラメータを要約した図である。以下の考察は、一実施形態に関して典型的な値を与えるものである。ただし、他の実施形態に様々な他の値も当てはめることができる。
【０１８０】
・頂点速度Ｒｖは、ホスト・プログラム・ホスト・インターフェース１１（たとえばＮＵＰＡバス）、メディア・プロセッサの変換／ライト／クリップ・マイクロコード、メディア・プロセッサ１４とハードウェア・アクセラレータ１８との間のインターフェース（たとえばＳＵＰＡバス）のうち最も遅いものによって制限される。頂点速度は、頂点タイプおよびライト（光）の数に応じて変化し、マイクロコードによって制限することができる。典型的なＲｖ値は３３Ｍ頂点／秒である。
【０１８１】
・分離された三角形は、１つの三角形に３つの頂点を有する。大きな三角形メッシュの場合、三角形あたりの頂点数は、０．５頂点／三角形の限界値に向かって減少する。長い三角形ストリップの場合、限界値は１頂点／三角形である。短い三角形ストリップの場合、頂点／三角形は１から３の間である。この考察では、長い三角形ストリップが想定される。
【０１８２】
・プリミティブ速度Ｒｐも、ラスタ化パイプラインＲＰによって制限することができる。典型的なＲｐ値は、３３Ｍ三角形／秒である。
【０１８３】
・ラスタライザのピクセル・シェーディング速度Ｒｚは、エッジ・ウォーカＥＷおよびスパン・ウォーカＳＷによって制限することができる。典型的なＲｚ値は６６６Ｍピクセル／秒である。
【０１８４】
・サンプル生成速度Ｒｓは、サンプル生成器ＳＧユニットおよびサンプル評価器ＳＥユニットによって制限することができる。典型的なＲｓ値は、「バディ（ｂｕｄｄｙ）」モードであると想定した場合に１３３３Ｍサンプル／秒であり、「バディ」モードなしの場合は６６６Ｍサンプル／秒である。
【０１８５】
・テクスチャ処理速度Ｒｔは主にテクスチャ・メモリ帯域幅およびテクスチャ・フィルタ・タイプ選択によって制限される。典型的なＲｔ値は、バイリニア・フィルタおよび１層テクスチャの場合に、１６６Ｍテクスチャ化ピクセル／秒である。より複雑なフィルタおよび／またはより多いテクスチャ層は、かなり低速になる可能性がある。
【０１８６】
・テクスチャ化サンプル（フラグメント）書込み速度Ｒｗは、フラグメント・パイプラインＦＰ（本明細書ではフラグメントプロセッサとも称される）、ＦＢインターフェース、およびＦＢメモリによって制限することができる。設計により、ＲｗはＲｓと同じ（「バディ」モードで１３３３Ｍサンプル／秒）になる。
【０１８７】
前述のように長い三角形ストリップを想定すると、三角形あたりの頂点数は１に近づき、その結果、三角形速度に関する頂点限界値およびラスタ化セットアップ制限値は、ほぼ以下に等しくなる。
Ｒｔｒｉ＝ｍｉｎ（Ｒｖ／１，Ｒｐ）＝３３Ｍｔｒｉ／ｓｅｃ
【０１８８】
サンプル・フィル速度は、サンプル生成器ＳＧ、テクスチャ処理ピクセル速度×サンプル密度、ラスタライザ・ピクセル速度×サンプル密度、およびフラグメント書込み速度のうち、最も遅いものによって制限することができる。ただし、ＲｗはＲｓと同じであり、ＲｚはＲｔよりはるかに大きいため、
Ｒｓｆｉｌｌ＝ｍｉｎ（Ｒｓ，Ｄ＊Ｒｔ，Ｄ＊Ｒｚ，Ｒｗ）＝ｍｉｎ（Ｒｓ，Ｄ＊Ｒｔ）
であって、Ｒｓ＝１３３３Ｍサンプル／秒（「バディ」モードであると想定）およびＲｔ＝１６６Ｍテクスチャ化ピクセル／秒（バイリニア・フィルタおよび１層のテクスチャであると想定）を付加すると、サンプル密度（Ｄ）が最高８の場合、サンプル・フィル速度は以下のようにテクスチャ速度制限される。
Ｒｓｆｉｌｌ＝ｍｉｎ（Ｒｓ，Ｄ＊Ｒｔ）＝ｍｉｎ（１３３３，１６６Ｄ）Ｍｓａｍｐ／ｓｅｃ
【０１８９】
シーン内のＰ個の三角形（残りのデータベースがホストによってビュー・フラスタム・カリングされたと想定する）、Ａｗウィンドウ領域、Ｃ深さ複雑性、およびＤサンプル密度を備えたフレームをレンダリングするための時間は、
ｒｅｎｄｅｒ＿ｔｉｍｅ＝ｍａｘ（ｔｒｉ＿ｔｉｍｅ，ｆｉｌｌ＿ｔｉｍｅ）
であり、上式では
ｔｒｉ＿ｔｉｍｅ＝Ｐ／Ｒｐ
ｆｉｌｌ＿ｔｉｍｅ＝（Ａｗ ＊Ｃ＊Ｄ）／ｍｉｎ（Ｒｓ，Ｄ＊Ｒｔ）
である。
【０１９０】
Ａｗウィンドウ領域およびＤサンプル密度を備えたフレームをレンダリングする前に、サンプル・バッファをクリアするための時間は、以下のようになる。
ｃｌｅａｒ＿ｔｉｍｅ＝Ｄ＊Ａｗ／Ｒｃ＝０．１８８ＤＡｗｎｓｅｃ
【０１９１】
２．５ フィルタリング性能パラメータ
図２１は、フィルタリング性能パラメータを示す図である。
【０１９２】
・サンプル読取り速度Ｒｒは、ＦＢインターフェースおよびＦＢメモリによって制限することができる。典型的なＲｒの値は、３３３Ｍサンプル／秒である。
【０１９３】
・サンプル・フィルタ・ピクセル速度Ｒｆは、サンプル読取りバッファ内のフィルタ・フットプリント、サンプル密度、およびキャッシング量によって制限することができる。
【０１９４】
・ピクセル結果に精密に一致するフットプリントを備えた、単純な拡大していないボックス・フィルタの場合、フィルタ速度は、読取りサンプル速度Ｒｒをサンプル密度Ｄで割った値に制限することができる。
【０１９５】
・拡大されたボックスおよび円形フィルタの場合、畳み込み計算に関係するサンプルの数は、フットプリント半径の２乗と共に増加し、読み取られるサンプル数は半径に比例して増加する。半径が増加すると畳み込み計算が障害となる可能性があり、より複雑なフィルタの場合、フィルタ速度は２分の１またはそれ以上に低下する可能性がある。この性能に関する考察は、高速ボックス・フィルタの場合に限定される。
【０１９６】
・フラグメント書込み速度Ｒｗは、フィルタ／コピー速度を低下させる、結果を表示バッファに書き込むための時間を設定する。ピクセルを書き込む場合、この速度は６６６Ｍピクセル／秒であってよい。
【０１９７】
拡大されていないボックス・フィルタの場合に、結果をフィルタリングおよびコピーするための合計時間は、
ｆｉｌｔｅｒ＿ｔｉｍｅ＝（Ａｗ ＊Ｄ／Ｒｒ）＋（Ａｗ／Ｒｗ）
ｆｉｌｔｅｒ＿ｔｉｍｅ＝（３Ｄ＋１．５）Ａｗｎｓｅｃ
となり、これは、サンプル密度が高くなると３ＤＡｗに近づく。
【０１９８】
３．０ ウィンドウ・サイズあたりのサンプル・バッファ（ＳＢ）の動的割振り
ＦＢメモリ内のサンプル・バッファのサイズは、ウィンドウ・サイズの変化に応答して動的に調整することができる。
【０１９９】
・Ｗｄ×Ｈｄピクセルの表示の場合、ＦＢには、少なくともＷｄ×Ｈｄ（典型的にはこれよりわずかに多い）の（ダブル・バッファされた）ピクセル表示バッファ・メモリが必要である（すなわち、ピクセル単位のほぼ表示サイズ）。
【０２００】
・ウィンドウ・システムでは、全画面サイズよりも小さいウィンドウにレンダリングすることが多い。ＷＷ×ＨＷピクセルのウィンドウでは、ＦＢには、少なくともＤＳ×ＷＷ×ＨＷ（典型的にはこれよりわずかに多い）の（単一バッファ付き）サンプル・バッファ・メモリが必要である（すなわちほぼウィンドウ・サイズ×サンプル密度）。
【０２０１】
・ＦＢメモリの容量が有限（一実施形態では５２０万サンプル／ピクセルのメモリ）であり、ＦＢメモリは表示バッファとサンプル・バッファとで共用されるため、最大サンプル密度は、ほぼ以下の整数下限である。
｛（ピクセル／サンプル単位のＦＢサイズ−ピクセル単位の表示サイズ）÷（ピクセル単位のウィンドウ・サイズ）｝
【０２０２】
・これは、解像度の低い表示および／またはサイズの小さいウィンドウでも、固定サイズのフレーム・バッファで高いサンプル密度をサポートできることを意味する。
【０２０３】
したがって、ホスト・コンピュータ上で実行中のソフトウェアは、現在のウィンドウ・サイズを監視し、固定サイズのフレーム・バッファを最大限に活用するようにサンプル密度を自動的に調整することができる。ユーザが小さなウィンドウ・サイズを選択する（またはそのサイズに変更する）と、グラフィックス・レンダリング・システムの適切なハードウェア・レジスタのセットに書き込むことによって、ホスト・ソフトウェアはサンプル密度を高く調整することが可能であり、またその逆も可能である。
【０２０４】
ハードウェア・アクセラレータ１８は、ピクセル領域あたりで生成されるサンプル数を制御する、１つまたは複数のサンプル密度レジスタを有することができる。サンプル生成器ＳＧは、サンプル密度フィールドを備えた制御レジスタを有することができる。サンプル密度フィールドは、ピクセル領域あたりで生成されるサンプル・ポジションの数を決定する。フレーム・バッファ・アドレッシング・ユニット（ＦＢＡ）は、フラグメント・アドレスをメモリ・ページおよびデータ・アイテムアドレスにマッピングする責務を負っており、マッピングがサンプル密度に依存するため、サンプル密度レジスタを有することができる。サンプル・フィルタはサンプル密度レジスタを有することができるため、そのフィルタリング・オペレーションのためにピクセル領域あたり適切な数のサンプルを取り込むことができる。サンプル密度レジスタは、動的に調整可能である。
【０２０５】
ホスト・ソフトウェアは、サンプル密度を変更するために、ハードウェア・アクセラレータ内の１つまたは複数のサンプル密度レジスタに書き込むことができる。一実施形態では、ホスト・ソフトウェアはすべてのサンプル密度レジスタに同じ値を書き込む。
【０２０６】
ウィンドウのサイズは全画面よりも小さい場合が多い。したがって、ユーザがより大きなウィンドウを選択すると、よりピクセルの多い解像度が得られるため、イメージ品質を上げることができる。
【０２０７】
それとは逆に、ユーザがウィンドウを小さくすると、動的割振りメカニズムはピクセルあたりのサンプル数を多くして、イメージ品質を維持する。
【０２０８】
本明細書で使用される「マルチサンプル」という語は、「スーパーサンプル」と同じ意味である。
【０２０９】
２．１．３項の例で示されるように、（サンプル・バッファを画面全体に対応するように設定しようとするのではなく）サンプル・バッファ・サイズをウィンドウ・サイズに合わせて調整すると、サンプル密度を大幅に増加させることができる。１２８０×１０２４表示の場合、ほぼ全画面のウィンドウは１パスで２サンプル／ピクセルをサポートすることが可能であり、１０００×１０００ウィンドウは３サンプル／ピクセル、７２０×６７０は８サンプル／ピクセルがサポート可能であって、かなり品質が良い。
【０２１０】
サンプル密度を最高にするためにサンプル・バッファ・メモリを動的に割り振るこのメカニズムは、以下の項で述べるメカニズム、すなわち、高いサンプル密度および／または立体ビジョンのための複数のパスと組み合わせることができる。動的メモリ割振りと複数パス・レンダリングの組合せにより、ユーザは、目標とする品質レベル（たとえば所望のサンプル密度）を指定することが可能であり、システムは、現在のウィンドウ・サイズを考慮して、その目標とする品質レベルを達成するのに必要なフレームあたり最小数の（または最小数に近い）パスを実行する。あるいは、ユーザは最低性能目標（たとえば最大フレーム・レンダリング時間）を指定することが可能であり、システムは、最低性能ターゲットよりも上の性能を維持しながら（たとえば、最大フレーム・レンダリング時間内でフレームをレンダリングしながら）、可能な最高サンプル密度を送る。
【０２１１】
４．０ 立体ビジョンのためのサンプル・バッファの再使用
立体ビジョン（２．３．２項に記載）の一般的な一方法は、１回目は左目のパースペクティブ変換マトリクスを使用し、次に再度右目のパースペクティブ変換マトリクスを使用することで、同じシーン・ジオメトリを２回レンダリングすることによって達成される。２つのレンダリングは２つの異なる表示バッファに格納され、同じディスプレイ上に交互に表示することができる（たとえば、位相のずれた左目と右目の液晶「シャッタ」をディスプレイの更新と同期させる、立体眼鏡を使用して見る場合）。
【０２１２】
表示バッファが２つあると、より多くのフレーム・バッファ・メモリを消費する。ただし、本明細書に記載された「フィルタリング後コピー」方法（すなわちサンプルをオフスクリーン・サンプル・バッファにレンダリングし、サンプル・バッファからバック・ピクセル表示バッファにフィルタリングし、その後表示バッファ切替えを実行する方法）は、サンプル・バッファ要件を増やすことがない。したがって、サンプル・バッファ・メモリを倍増させるような出費なしに、立体ビジョンをサポートすることができる。
【０２１３】
図２２は、立体表示のためのサンプル・バッファの再使用を示す図である。
【０２１４】
ホスト・ドライバ・ルーチンは、ＦＢメモリ内で左および右の表示バッファを割り振った後に、残りのＦＢメモリを単一の再使用可能サンプル・バッファとして割り振ることができる。ソフトウェア・アプリケーション（ホスト・コンピュータ上で実行中）は、以下のレンダリング・ループを実施することができる。
【０２１５】
５．０ 増加したサンプル密度のためのＳＢの再使用
サンプル・バッファ容量は、表示バッファ要件を差し引いた後で残ったフレーム・バッファ・メモリを決して超えることはない。所与のサイズのウィンドウでは、１つのレンダリング・パスでサポートできる最大のサンプル密度を限度としている。
【０２１６】
しかし、本明細書に記載された「フィルタリング後コピー」方法を使用すれば、グラフィックス・アプリケーションがサンプル・バッファを再使用して、サンプル・バッファ・メモリ・サイズを増やすことなく、より高いサンプル密度を達成することができる。グラフィックス・アプリケーションは、グラフィックス・レンダリング・システムを使用して、（単一パスでシーン全体がレンダリングされるよりも）高いサンプル密度で、パスあたり１領域、複数パスのシーン内で複数の領域をレンダリングし、表示バッファをスワッピングする前にリア表示バッファでシーン全体を構築することができる。
【０２１７】
この方法により、より多くのレンダリング・パスを高いサンプル密度と交換することができる。この方法は、（ｓｃｒｅｅｎ＿ｒｅｓｏｌｕｔｉｏｎ）ダブル・バッファされたメモリに、以下のサイズのサンプル・バッファ・メモリを加えたものを使用する。
（ｓａｍｐｌｅ＿ｄｅｎｓｉｔｙ＊ｗｉｎｄｏｗ＿ｓｉｚｅ／ｎｕｍｂｅｒ＿ｏｆ＿ｐａｓｓｅｓ）
【０２１８】
５．１ アルゴリズム
図２３は、高いサンプル密度を達成するための固定サイズのサンプル・バッファの再使用を示す図である。
【０２１９】
ＦＢメモリで表示バッファを割り振った後、ホスト・ソフトウェア（たとえばホスト・ドライバ・ルーチン）は、残ったＦＢメモリを単一の再使用可能サンプル・バッファとして割り振ることができる。ホスト・ソフトウェアは、バック表示バッファをＮ個の隣接する領域に分割することが可能であり、ここでＮはシーン・フレームあたりに実行されるパスの数である。したがってＮは、１より大きいかまたは等しい整数である。表示メモリ割振りページの形状（その一実施形態が、図６の表に例示されている）により、表示バック・バッファをほぼ同じサイズのＮ個の領域に分割することが有利である。次にグラフィックス・アプリケーションは、以下のレンダリング・ループを実行することができる。
【０２２０】
２．１．２項に示されるように、ドライバ・ソフトウェアは、整数のＦＢメモリ・ページ・サイズに切り上げるため、およびサンプル・フィルタ（一定のモードの）は領域からはみ出すフットプリント（またはサポート領域）を有することができる（たとえば領域のエッジ上またはエッジ付近のピクセルを計算する場合）ため、領域サイズ（すなわち、サンプル密度×ウィンドウ幅×ウィンドウ高さ）よりも１ビット大きいサンプル・バッファを割り振ることが可能である。単純な拡大されていないボックス・フィルタ（単一ピクセルの領域をカバーする）の場合、特別な境界線は不要である。
【０２２１】
５．２ サンプル密度の例
・単一ヘッドの１２８０×１０２４の非立体表示の場合、表示バッファは（ｃｅｉｌｉｎｇ（１２８０／３２０）＊ｃｅｉｌｉｎｇ（１０２４／１６））＝２５６ページのＦＢメモリを使用する。これで（１０２４−２５６）＝７６８ページがサンプル・バッファ用に残される。
（ｃｅｉｌｉｎｇ（９６０／８０）＊ｃｅｉｌｉｎｇ（９００／１６））＝６８４ページであり、７６８ページよりも少ないため、単一のパスは、サンプル密度４で９６０×９００ピクセルのウィンドウをサポートすることができる。
（ｃｅｉｌ（９６０／４０）＊ｃｅｉｌ（４５０／１６））＝６９６ページであり、７６８ページよりも少ないため、２つのパスは、サンプル密度８で９６０×９００ピクセルのウィンドウをサポートすることができる。
（ｃｅｉｌ（９６０／４０）＊ｃｅｉｌ（２２５／８））＝６９６ページであり、７６８ページよりも少ないため、４つのパスは、サンプル密度１６で９６０×９００ピクセルのウィンドウをサポートすることができる。
【０２２２】
・単一ヘッドの９６０×６８０の立体表示の場合、表示バッファは（ｃｅｉｌ（９６０／３２０）＊ｃｅｉｌ（６８０／８））＝２５５ページのＦＢメモリを使用する。これで（１０２４−２５５）＝７６９ページがサンプル・バッファ用に残される。
（ｃｅｉｌ（９６０／８０）＊ｃｅｉｌ（６８０／１２））＝６８４ページであり、７６９ページよりも少ないため、単一のパスは、サンプル密度５で９６０×６８０の全画面表示をサポートすることができる。
（ｃｅｉｌ（９６０／４０）＊ｃｅｉｌ（３４０／１２））＝６９６ページであり、７６９ページよりも少ないため、２つのパスは、サンプル密度１０で９６０×６８０の全画面表示をサポートすることができる。
（ｃｅｉｌ（９６０／４０）＊ｃｅｉｌ（２２７／８））＝６９６ページであり、７６９ページよりも少ないため、３つのパスは、サンプル密度１６で９６０×６８０の全画面表示をサポートすることができる。
【０２２３】
５．３ 性能分析
ホスト・アプリケーションは、所与の各パスで使用される領域と一致するようにビュー・フラスタムを設定することができる。したがって、シーンの中で表示バッファ内の現在の領域に投影されない部分は、クリッピングされることになる。この方法を使用すると、領域サイズが小さくなるにつれて、各パスのレンダリングおよびフィルタリング時間が少なくなる。高いサンプル密度でシーン全体（Ｎ個の領域すべて）をラスタ化およびフィルタリングするための合計時間が、より多くのメモリを備えたより高価なシステムで高いサンプル密度での単一パスにかかる時間に近づけることができることに留意されたい。
【０２２４】
バッファ・クリア時間。ウィンドウ領域ＡＷおよびサンプル密度Ｄのフレームをレンダリングする前に、サンプル・バッファをクリアするための時間は、（少なくとも一部の実施形態では）以下の式で概算することができる。
ｃｌｅａｒ＿ｔｉｍｅ＝Ｄ＊ＡＷ／ＲＣ＝０．１８８ＤＡＷｎｓｅｃ
【０２２５】
グラフィックス・アプリケーションが、それぞれ領域ＡＷ／Ｎ、サンプル密度Ｎ＊Ｄで、Ｎ個のパスをＮ個の対応する領域に流入させると、合計クリア時間（Ｎ個のパスについて）は、サンプル密度比率（ＮＤ／Ｄ）に比例して以下のように増加する。
ｃｌｅａｒ＿ｔｉｍｅ＝Ｎ＊Ｄ＊ＡＷ／ＲＣ＝０．１８８ＮＤＡＷｎｓｅｃ
【０２２６】
フィルタリング／コピー時間。２．５項から、拡大されていないボックス・フィルタについての結果をフィルタリングおよびコピーするための合計時間は、以下の通りであることを想起されたい。
ｆｉｌｔｅｒ＿ｔｉｍｅ＝（ＡＷ ＊Ｄ／Ｒｒ）＋（ＡＷ／ＲＷ）
ｆｉｌｔｅｒ＿ｔｉｍｅ＝（３Ｄ＋１．５）ＡＷｎｓｅｃ
【０２２７】
グラフィックス・アプリケーションが、それぞれ領域ＡＷ／Ｎ、サンプル密度Ｎ＊Ｄで、Ｎ個のパスをＮ個の対応する領域に流入させると、合計フィルタリング／コピー時間（Ｎ個のパスについて）は、サンプル密度比率（ＮＤ／Ｄ）に比例して以下のように増加し、
ｆｉｌｔｅｒ＿ｔｉｍｅ＝Ｎ＊（３ＮＤ＋１．５）（ＡＷ／Ｎ）ｎｓｅｃ
ｆｉｌｔｅｒ＿ｔｉｍｅ＝（３ＮＤ＋１．５）Ａｎｓｅｃ
これで、高いサンプル密度および複数のパスの場合、３ＮＤＡＷに近づく。
【０２２８】
サンプル・フィル時間。２．４項から、
Ｒｓｆｉｌｌ＝ｍｉｎ（Ｒｓ，Ｄ＊Ｒｔ）＝ｍｉｎ（１３３３，１６６Ｄ）Ｍｓａｍｐ／ｓｅｃ
であることを想起されたい。したがって、単一のバイリニア・テクスチャの場合、Ｄ＜８であれば、システムはテクスチャ速度を以下のように制限することが可能であり、
Ｒｓｆｉｌｌ（Ｄ＜８）＝１６６ＤＭｓａｍｐ／ｓｅｃ
さらにＤ＞＝８であれば、システムはサンプル速度を以下のように制限することが可能である。
Ｒｓｆｉｌｌ（Ｄ＞＝８）＝１３３３Ｍｓａｍｐ／ｓｅｃ
【０２２９】
より複雑なテクスチャリングの場合、Ｄのしきい値がさらに高くなることさえある。Ｄ＜８の場合、１つのパス、サンプル密度Ｄで、ピクセルをウィンドウ・サイズＡＷにフィルするための時間は、以下のようになる。
ｆｉｌｌ＿ｔｉｍｅ＝（ＡＷ ＊Ｃ＊Ｄ）／１６６＊Ｄ＝（ＡＷ ＊Ｃ）／１６６ｍｉｃｒｏｓｅｃ
【０２３０】
あるいは、グラフィックス・アプリケーションが、それぞれ領域ＡＷ／Ｎ、サンプル密度Ｎ＊Ｄで、Ｎ個のパスをＮ個の対応する領域に流入させると、（ＮＤは依然として８より小さいかまたは等しいと想定する）合計フィル時間（Ｎ個のパスについて）は増加しない。
ｆｉｌｌ＿ｔｉｍｅ＝Ｎ＊（（ＡＷ／Ｎ）＊Ｃ／１６６＝（ＡＷ ＊Ｃ）／１６６ｍｉｃｒｏｓｅｃ
【０２３１】
したがって、単一のバイリニア・テクスチャリングの場合、複数のパスはフィル時間を増やさずにサンプル密度を８まで上げることができる。より複雑なテクスチャリングの場合、フィル時間を増やさずにサンプル密度をより高くすることさえ可能である。
【０２３２】
三角形ラスタ化セットアップ時間。ホストのビュー・フラスタム・カリングおよびハードウェアのクリッピングが行われた後に（言い換えれば、シーン内の三角形がウィンドウ内部にある）、Ｐ個の三角形を備え、ウィンドウ領域ＡＷ、深さ複雑性Ｃ、およびサンプル密度Ｄで、フレームのラスタ化を設定するための時間は、以下のようになることを想起されたい。
ｔｒｉ＿ｔｉｍｅ＝Ｐ／ＲＰ＝３Ｐｎｓｅｃ
【０２３３】
シーンがＮ個の領域に区分されている場合、各領域には、ウィンドウＡＷ内で見えるＰ／Ｎのプリミティブより平均して少し多く収まることになる（すなわち、領域の境界線をまたがるプリミティブは部分的に両方の領域にあることになる）。したがって、Ｎ個の領域をレンダリングするための合計時間は、大幅には増加しない（少なくともＰが大きくＮが小さい場合）。
ｔｒｉ＿ｔｉｍｅ＝Ｎ＊３（（Ｐ／Ｎ）＝３Ｐｎｓｅｃ
【０２３４】
頂点処理時間。
ホストが、ハードウェア処理と全面的に重なる「完全な」ビュー・フラスタム・カリングを実行した場合、シーンがＮ個の領域に区分されていれば、Ｖ／Ｎより少し多い頂点が各領域に収まることになる（領域の境界線をまたがるプリミティブは部分的に両方の領域にあることになる）。Ｎ個の領域で頂点を変換およびライティングするための合計時間は、大幅には増加しない（Ｖが大きくＮが小さい場合）。
（ｌｏｗｅｒ ｂｏｕｎｄ）ｖｔｘ＿ｔｉｍｅ＝Ｎ＊３（Ｖ／Ｎ）＝３Ｖｎｓｅｃ
【０２３５】
ビュー・フラスタム・カリングが完全でない（またはまったくない）場合、頂点処理の負荷はＮ倍ずつ増加する可能性がある。
（ｕｐｐｅｒ ｂｏｕｎｄ）ｖｔｘ＿ｔｉｍｅ＝Ｎ＊３Ｐ＝３ＰＮｎｓｅｃ
【０２３６】
フレーム時間。まとめると、合計アニメーション・フレーム時間は以下のようになる。
ｆｒａｍｅ＿ｔｉｍｅ＝ｃｌｅａｒ＿ｔｉｍｅ＋ｒｅｎｄｅｒ＿ｔｉｍｅ＋ｆｉｌｔｅｒ＿ｔｉｍｅ＋ｓｗａｐ＿ｔｉｍｅ
【０２３７】
アニメーション・フレーム速度は、アニメーション・フレーム時間に単純に反比例する。
【０２３８】
グラフィックス・レンダリング・システムは、ダブル・バッファされたバッファ・スワップを実行するために、ウィンドウ・ルックアップ・テーブルを介して間接的な処置を使用することができる。したがって、ｓｗａｐ＿ｔｉｍｅはわずかである（テーブル・エントリを更新するための時間のみ）。２重バッファ・スワップが（よりスムースなアニメーションのために）意図的に表示帰線と同期される場合、単にｓｗａｐ＿ｔｉｍｅは、合計ｆｒａｍｅ＿ｔｉｍｅを表示フレーム時間の整数倍となるように量子化する効果を有する。この場合、次の頂点帰線を待つために費やす時間は、合計アニメーション・フレーム時間を増やすことなく、他の３回での穏やかな増加をマスクすることができる。
【０２３９】
本明細書でさまざまな処理速度に引用された例示的な値は、限定的なものではない。これらの処理速度は、実施形態によって様々な範囲の値を達成することができる。
【０２４０】
要約
サンプル・メモリを追加せずにサンプル密度を上げるために、Ｎ個のパスが使用される場合、
・サンプル・バッファのクリアおよびフィルタリング時間は、サンプル密度に比例して増加する（より多くのメモリが使用される場合と同様）。
・しきい値（この例ではサンプル密度８であり、図２０に示されるように、相対的な性能と、サンプルおよびテクスチャの処理経路を並行して機能させることによって設定される）を下回る場合、サンプル・フィル時間は増加しない。
・三角形ラスタ化時間は、大幅には増加しない（領域の境界上にある数個の三角形は２回処理される）。
・頂点処理時間は、Ｎ倍を超えない程度ずつ増加するが、グラフィックスプロセッサの前の効率的なビュー・フラスタム・カリングに伴うわずかな増加に近づくことができる。
【０２４１】
これは、フィル速度が制限されている（一般的なケース）シーンの場合、メモリを追加することなく、また性能を著しく損なうことなく、サンプル密度を上げることができることを意味する。
【０２４２】
頂点速度が制限されている場合、性能の低下はＮ分の１ほどにはならず、ビュー・フラスタム・カリングによって減らすことができる。
【０２４３】
たとえ大幅な性能の低下が発生しても、この方法は、性能と引き換えにより高いサンプル密度（すなわちよりよい品質）を得ることができる。サンプル密度は、コストまたは技術的に制限されていても、メモリの制限値を超えて増やすことが可能である。
【０２４４】
６．０ 立体ビジョンおよびサンプル密度の増加
グラフィックス・アプリケーションは、「立体ビジョンのためのサンプル・バッファの再使用」（４．０項）と「増加したサンプル密度のためのサンプル・バッファの再使用」（５．０項）の両方を活用するように、グラフィックス・レンダリング・システムを構成することができる。
【０２４５】
図２４は、より高いサンプル密度を達成するためのサンプル・バッファの再使用を示す図である。
さらに、３．０項（すなわち「ウィンドウ・サイズあたりのＳＢの動的割振り」）で述べたように、グラフィックス・アプリケーションは、どちらかまたは両方の技術（すなわち立体ビジョンのためのＳＢの再使用および／または増加したサンプル密度のためのＳＢの再使用）を、現在のウィンドウ・サイズおよびユーザ基本設定（目標サンプル密度または目標フレーム速度）に基づいた動的割振りと組み合わせるように構成することができる。
【図面の簡単な説明】
【図１Ａ】グラフィックス・レンダリング・システムの一実施形態を示す図である。
【図１Ｂ】グラフィックス・レンダリング・システム内のハードウェア・アクセラレータの一実施形態を示す図である。
【図１Ｃ】グラフィックス・レンダリング・システム内のハードウェア・アクセラレータの他の実施形態を示す図である。
【図１Ｄ】グラフィックス・レンダリング・システム内のメディア・プロセッサの一実施形態を示す図である。
【図２】グラフィックス・レンダリング・システムの他の実施形態を示す図である。
【図３】フレーム・バッファ・データ・ユニット（たとえばピクセルまたはサンプル）内のビット・プレーンの割振りに関する例示的な実施形態を示す図である。
【図４】フレーム・バッファ・データ・ユニット（たとえばピクセルまたはサンプル）内のビット・プレーンの割振りに関する例示的な実施形態を示す図である。
【図５】フレーム・バッファ中の表示バッファおよびスーパーサンプル・バッファの割振りの一例を示す図である。
【図６】様々なフレーム・バッファ・モードでのメモリ割振りページ・サイズ（ピクセル単位）の一実施形態を示す図である。
【図７】サンプル・バッファの領域をクリアするための高速フィル機能の一実施形態を示す図である。
【図８】マルチサンプル（すなわちスーパーサンプル）をサンプル・バッファにレンダリングするためのプロセスの一実施形態を示す図である。
【図９】グラフィックス・レンダリング・パイプラインの一実施形態におけるサンプル処理およびテクスチャ処理リソースの並行処理を示す図である。
【図１０】コピー・オペレーションのセットで使用されるコピー経路を示す図である。
【図１１】コピー、フィルタリング、および累算のオペレーション・セットに関するデータ流れを示す図である。
【図１２】ピクセル・コピー・オペレーション（すなわち、フレーム・バッファからフレーム・バッファへのブロック・コピー・オペレーション）のためのアドレス生成を示す図である。
【図１３】サンプル・フィルタリング・オペレーションのためのアドレス生成を示す図である。
【図１４】１×１平方のサポート領域を有するフィルタを使用したサンプル・フィルタリングのための例示的なフットプリントを示す図である。
【図１５】半径Ｒ＝２のディスク形サポート領域を有するフィルタを使用したサンプル・フィルタリングのための例示的なフットプリントを示す図である。
【図１６】ソース・アドレス、宛先アドレス、データ、およびアドレスとデータの結合流れを強調した、フレーム・バッファからフレーム・バッファへのコピー・オペレーションの一実施形態を示す図である。
【図１７】スーパーサンプル読取りパスでのオペレーション・コードの流れを示す図である。
【図１８】一実施形態での、結果ピクセルをバック表示バッファへサンプル・フィルタリングおよびコピーするステップを示す要約図である。
【図１９】一実施形態での、表示バッファの前半分からのデータを表示するステップを示す図である。
【図２０】サンプル・バッファへのサンプルのレンダリングに関する、レンダリング性能パラメータのセットを示す図である。
【図２１】サンプル・バッファからのサンプルのフィルタリングに関する、フィルタリング性能パラメータのセットを示す図である。
【図２２】一実施形態での、立体表示のためのサンプル・バッファの再使用を示す図である。
【図２３】他の実施形態での、より高いサンプル密度を達成するための固定サイズのサンプル・バッファの再使用を示す図である。
【図２４】立体実施形態での、より高いサンプル密度を達成するためのマルチパス・レンダリングを示す図である。
【符号の説明】
１４ メディア・プロセッサ
１６ 共用メモリ（ＤＲＤＲＡＭ）
１８ ハードウェア・アクセラレータ
２０ テクスチャ・バッファ
２２ フレーム・バッファ
２４ ビデオ出力プロセッサ
２６ ＲＧＢ ＤＡＣ
２８ ビデオ・エンコーダ
３０ ブートＰＲＯＭ
１０４ ホスト・バス
Claims (45)
- サンプル・バッファおよびダブル・バッファされた表示域を含むフレーム・バッファと、
フレーム・バッファに結合され、さらに（ａ）プリミティブを受け取り、（ｂ）動的に調整可能なサンプル密度値に基づいてプリミティブ用のサンプルを生成し、（ｃ）サンプルをサンプル・バッファに書き込み、（ｄ）サンプル・バッファからサンプルを読み出し、（ｅ）ピクセルを生成するためにサンプルをフィルタリングし、（ｆ）ピクセルをダブル・バッファされた表示域のバック・バッファに格納するように構成されたハードウェア・アクセラレータと
を含むグラフィックス・システム。 - ハードウェア・アクセラレータが、フラグメント座標をフレーム・バッファのメモリ・アドレスにマッピングするように構成されたフレーム・バッファ・アドレス・ユニットを含み、フレーム・バッファ・アドレス・ユニットが、フラグメント・アドレスとメモリ・アドレスとの間のマッピングを制御する動的にプログラム可能なレジスタを含む請求項１に記載のグラフィックス・システム。
- ホスト・コンピュータ上で実行中のプログラムが、１つまたは複数のウィンドウ・サイズ・パラメータの変更を指定するユーザ入力に応答して、フレーム・バッファ内でサンプル・バッファを再割り振りするために、プログラム可能レジスタを動的に更新するように構成される請求項２に記載のグラフィックス・システム。
- プログラムが、最大のサンプル密度を達成するようにサンプル・バッファを再割振りする請求項３に記載のグラフィックス・システム
- フレーム・バッファ・メモリ内のメモリ・デバイスが並列の読取りバスおよび書込みバスを有し、ハードウェア・アクセラレータがサンプル・バッファ内のソース・ブロック上でのクリア・オペレーションと平行して（ｄ）を実行するように構成される請求項１に記載のグラフィックス・システム。
- プログラム可能サンプル密度に基づいてフレーム・バッファの使用可能スペースにサンプルをレンダリングし、サンプル・バッファからフレーム・バッファのダブル・バッファされた表示域へのサンプルをフィルタリングするように構成されたグラフィックス・アクセラレータを制御するための方法であって、
（ａ）ウィンドウの幅および高さを決める入力を受け取ること、
（ｂ）ウィンドウの幅およびサンプル密度推定値に基づいてウィンドウを水平にカバーするメモリ割振りページの第１の数を計算すること、
（ｃ）ウィンドウの高さおよびサンプル密度推定値に基づいてウィンドウを垂直にカバーするメモリ割振りページの第２の数を計算すること、
（ｄ）第１の数と第２の数を掛け合わせて、メモリ割振りページの第３の数を決定すること、
（ｅ）（ｂ）、（ｃ）、および（ｄ）を１回または複数回実行して、メモリ割振りページの第３の数がフレーム・バッファの使用可能スペースに納まる条件によって決まるサンプル密度推定値を最大化すること、
（ｆ）最大化されたサンプル密度推定値を使用して、グラフィックス・アクセラレータのサンプル密度を再プログラミングすること
を含む方法。 - フレーム・バッファの使用可能スペースが、ダブル・バッファされた表示域によって占有されていないフレーム・バッファ内のスペースである請求項６に記載の方法。
- ハードウェア・アクセラレータと、
ハードウェア・アクセラレータに結合され、サンプル・バッファおよびダブル・バッファされた表示域を含むフレーム・バッファを含むグラフィックス・システムとを含み、
ハードウェア・アクセラレータが、（ａ）プリミティブを受け取り、（ｂ）動的に調整可能なプログラム可能サンプル密度値に基づいてプリミティブ用のサンプルを生成し、（ｃ）サンプルをサンプル・バッファに書き込み、（ｄ）サンプル・バッファからサンプルを読み出し、（ｅ）ピクセルを生成するためにサンプルをフィルタリングし、（ｆ）ピクセルをダブル・バッファされた表示域のバック・バッファに格納するように構成されたグラフィックス・システム。 - ダブル・バッファされた表示域のフロント・バッファからピクセルを読み取るように構成されたビデオ出力プロセッサをさらに含み、ハードウェア・アクセラレータおよびビデオ出力プロセッサが、ホスト・コンピュータからのスワップ・コマンドに応答して、ダブル・バッファされた表示域のフロント・バッファおよびバック・バッファのバッファ・スワップを実行するように構成された請求項８に記載のグラフィックス・システム。
- フレーム・バッファが複数のランダム・アクセス・メモリ（ＲＡＭ）デバイスを含み、ビデオ出力プロセッサがＲＡＭデバイスのサブセットに結合され、ＲＡＭデバイスのサブセット内でフレーム・バッファのダブル・バッファされた表示域が割り振られる請求項９に記載のグラフィックス・システム。
- ハードウェア・アクセラレータが前記複数のＲＡＭデバイスそれぞれに結合され、サンプル・バッファのサイズおよびサンプル・バッファのページ境界線がプログラム可能である請求項１０に記載のグラフィックス・システム。
- 前記複数のＲＡＭデバイスがダイナミック・ランダム・アクセス・メモリである請求項１０に記載のグラフィックス・システム。
- 格納されたマイクロコードを実行するように構成された１つまたは複数の処理ユニットをさらに含み、１つまたは複数の処理ユニットが、格納されたマイクロコードの実行に応答して、前記プリミティブの頂点で変換および書き込み動作を実行するように構成された請求項８に記載のグラフィックス・システム。
- ハードウェア・アクセラレータが、フレーム・バッファ内のサンプル・バッファの位置およびサイズを決定するプログラム可能レジスタのセットを含む請求項８に記載のグラフィックス・システム。
- （ａ）調整済みウィンドウの幅および高さを決める入力を受け取ること、
（ｂ）調整済みウィンドウの幅およびサンプル密度推定値に基づいて調整済みウィンドウを水平にカバーするメモリ割振りページの第１の数を計算すること、
（ｃ）調整済みウィンドウの高さおよびサンプル密度推定値に基づいて調整済みウィンドウを垂直にカバーするメモリ割振りページの第２の数を計算すること、
（ｄ）第１の数と第２の数を掛け合わせて、メモリ割振りページの第３の数を決定すること、
（ｅ）（ｂ）、（ｃ）、および（ｄ）を１回または複数回実行して、グラフィックス・アクセラレータによって達成可能なサンプル密度のセット内で、メモリ割振りページの第３の数が使用可能ページ・スペースの量より少ないかまたは等しいという条件によって決まる、サンプル密度推定値を最大化すること、
（ｆ）最大化されたサンプル密度をグラフィックス・アクセラレータに書き込むことを含む方法。 - 使用可能ページ・スペース量が、フレーム・バッファのページ容量と、フレーム・バッファのダブル・バッファされた表示域のページ使用量との差である請求項１５に記載の方法。
- 第１の数および第２の数の最大値をグラフィックス・アクセラレータに書き込むことをさらに含む請求項１５に記載の方法。
- 第３の数の最大値をグラフィックス・アクセラレータに書き込むことをさらに含む請求項１５に記載の方法。
- ユーザがオンスクリーン・ウィンドウを調整するごとに、（ａ）、（ｂ）、（ｃ）、（ｄ）、および（ｅ）を反復することをさらに含む請求項１５に記載の方法。
- グラフィックス・アクセラレータが、
最大化されたサンプル密度に基づいてサンプルをサンプル記憶域にレンダリングすることと、
表示可能ピクセルを生成するためにサンプル記憶域からサンプルをフィルタリングし、表示可能ピクセルをフレーム・バッファのダブル・バッファされた表示域に格納することをさらに含む請求項１５に記載の方法。 - 使用可能ページ・スペース量が、フレーム・バッファの容量とダブル・バッファされた表示域のサイズとの差に等しい請求項２０に記載の方法。
- ダブル・バッファされた表示域から表示可能ピクセルを読み取ることおよび表示することをさらに含む請求項２０に記載の方法。
- メモリ割振りページが、サンプル密度推定値に依存したピクセル単位のページ幅およびページ高さを有する請求項１５に記載の方法。
- ホスト・バスを介してグラフィックス・アクセラレータに結合されたホスト・コンピュータによって（ａ）から（ｅ）が実行される請求項１５に記載の方法。
- プログラム可能サンプル密度に基づいてフレーム・バッファの使用可能スペースにサンプルをレンダリングし、サンプル・バッファからフレーム・バッファのダブル・バッファされた表示域へのサンプルをフィルタリングするように構成されたグラフィックス・システムによって生成されたイメージの品質を維持するための方法であって、
（ａ）新しいウィンドウ・サイズを決める入力の受取りに応答して、アニメーション・フレームのグラフィックス・システムの第１のパスの数に対応する実現可能サンプル密度を算出すること、
（ｂ）ユーザ指定のサンプル密度より大きいかまたは等しい実現可能サンプル密度に対応する第１の数の値を決定するために、前記計算を１回または複数回実行すること、
（ｃ）前記値に等しいグラフィックス・システムの第１のパスの数を設定するために、グラフィックス・システムの１つまたは複数のプログラム可能レジスタに書き込むことを含む方法。 - （ｂ）の後に、実現可能サンプル密度の最終値に等しくプログラムサンプル密度を設定するために、グラフィックス・システムの１つまたは複数の追加のレジスタに書き込むことをさらに含む請求項２５に記載の方法。
- 前記書込みが、ユーザ指定のサンプル密度が前のウィンドウ・サイズよりも大きい新しいウィンドウ・サイズで維持できるように、第１の数を増やすものである請求項２５に記載の方法。
- （ａ）、（ｂ）、および（ｃ）がグラフィックス・システムに結合されたコンピュータによって実行される請求項２５に記載の方法。
- ハードウェア・アクセラレータと、
サンプル記憶域およびダブル・バッファされた表示ピクセル領域を含むフレーム・バッファとを含むグラフィックス・システムであって、
ハードウェア・アクセラレータが、
（ａ）プリミティブのストリームをサンプルにレンダリングし、
（ｂ）サンプルをフレーム・バッファのサンプル記憶域に格納し、
（ｃ）サンプル記憶域からサンプルを読み取り、
（ｄ）ピクセルを生成するためにサンプルをフィルタリングし、
（ｅ）フレーム・バッファの表示ピクセル領域の第１のバッファにピクセルを格納するように動作可能であり、
ハードウェア・アクセラレータが、第１のバッファの制御をビデオ出力プロセッサに渡す前にアニメーションのフレームを完了させるために、Ｎ個の対応するプリミティブのストリーム上で（ａ）、（ｂ）、（ｃ）、（ｄ）、および（ｅ）をＮ回実行するように動作可能であって、Ｎが正の整数である、グラフィックス・システム。 - ハードウェア・アクセラレータに結合されたホスト・コンピュータをさらに含み、ホスト・コンピュータが、プログラム命令の実行に応答して、アニメーションの各フレームについて（ａ）、（ｂ）、（ｃ）、（ｄ）、および（ｅ）のＮ回の反復を制御するように構成された請求項２９に記載のグラフィックス・システム。
- Ｎ＝２であり、プログラム命令が立体ビデオ・アプリケーションを含み、立体ビデオ・アプリケーションが、アニメーションの各フレームについて第１回は第１のバッファの右目部分をターゲットとし、第２回は第１のバッファの左目部分をターゲットとして、（ａ）、（ｂ）、（ｃ）、（ｄ）、および（ｅ）を実行するようにハードウェア・アクセラレータに命令する請求項３０に記載のグラフィックス・システム。
- Ｎ＝２Ｋであり、プログラム命令が立体ビデオ・アプリケーションを含み、立体ビデオ・アプリケーションが、アニメーションの各フレームについて、Ｋ回の第１のセットは第１のバッファの左目部分に対応するＫをターゲットとし、Ｋ回の追加セットは第１のバッファの右目部分に対応するＫをターゲットとして、（ａ）、（ｂ）、（ｃ）、（ｄ）、および（ｅ）を実行するようにハードウェア・アクセラレータに命令するものであって、Ｋは正の整数である請求項３０に記載のグラフィックス・システム。
- ホスト・コンピュータが、（ａ）、（ｂ）、（ｃ）、（ｄ）、および（ｅ）の各反復についてビュー・フラスタム・カリングを実行するように構成され、ビュー・フラスタム・カリングが、（ａ）、（ｂ）、（ｃ）、（ｄ）、および（ｅ）の各反復で書き込まれた第１のバッファの領域に対応する請求項３０に記載のグラフィックス・システム。
- ハードウェア・アクセラレータが、動的に調整可能なプログラム可能サンプル密度でプリミティブのストリームをサンプルにレンダリングするように構成され、ホスト・コンピュータが、ユーザのウィンドウ調整に応答して最大の達成可能サンプル密度を維持するために、ハードウェア・アクセラレータのプログラム可能サンプル密度を動的に再プログラミングするように構成された請求項３０に記載のグラフィックス・システム。
- ハードウェア・アクセラレータが、動的に調整可能なサンプル密度でプリミティブのストリームをサンプルにレンダリングするように構成され、ホスト・コンピュータが、目標とするアニメーション・フレーム速度を維持するために、ハードウェア・アクセラレータのサンプル密度を動的に調整するように構成された請求項３０に記載のグラフィックス・システム。
- ハードウェア・アクセラレータが、動的に調整可能なサンプル密度でプリミティブのストリームをサンプルにレンダリングするように構成され、ホスト・コンピュータが、目標とするアニメーション・フレーム速度を維持するためにＮを調整するように構成された請求項３０に記載のグラフィックス・システム。
- ハードウェア・アクセラレータが、動的に調整可能なプログラム可能サンプル密度でプリミティブのストリームをサンプルにレンダリングするように構成された請求項２９に記載のグラフィックス・システム。
- ホスト・コンピュータが、ウィンドウ・サイズの変化に応答してユーザ定義のサンプル密度値を維持するために、Ｎを動的に調整するように構成された請求項２９に記載のグラフィックス・システム。
- （ａ）、（ｂ）、（ｃ）、（ｄ）、および（ｅ）の各反復で第１のバッファの対応する部分に書き込む請求項２９に記載のグラフィックス・システム。
- ハードウェア・アクセラレータが、ホストプロセッサからのパラメータの受取りに応答して、サンプル・バッファのページ境界線を動的に再割振りするように構成された請求項２９に記載のグラフィックス・システム。
- ビデオプロセッサが、表示ピクセル域からピクセルを読み取り、ピクセルをデジタル・アナログ変換器に転送するように構成された請求項２９に記載のグラフィックス・システム。
- プログラム可能サンプル密度に基づいてフレーム・バッファの使用可能スペースにサンプルをレンダリングし、サンプル・バッファからフレーム・バッファのダブル・バッファされた表示域へのサンプルをフィルタリングするように構成されたグラフィックス・システムによって生成されたイメージの品質を維持するための方法であって、
（ａ）調整済みウィンドウのウィンドウ幅および高さを決める入力を受け取ること、
（ｂ）グラフィックス・システムによって達成可能なサンプル密度のセットから、サンプル密度値を選択すること、
（ｄ）正の整数値Ｎを選択すること、
（ｃ）ウィンドウ幅を選択されたサンプル密度に対応するページ幅で割った第１の上限を計算すること、
（ｄ）ウィンドウ高さを整数値Ｎで割って第１の結果を決定すること、
（ｅ）第１の結果を選択されたサンプル密度に対応するページ高さで割って第２の上限を計算すること、
（ｆ）第１の上限と第２の上限を掛け合わせてパスあたりのページ推定値を決定すること、
（ｇ）パスあたりのページ推定値がフレーム・バッファの使用可能スペースよりも大きい場合は、整数値Ｎを増やして（ｃ）、（ｄ）、（ｅ）、および（ｆ）を繰り返すこと、
（ｈ）アニメーション・フレームのＮパス・レンダリング用のグラフィックス・システムに合わせて構成されるように、グラフィックス・システムの１つまたは複数のプログラム可能レジスタに書き込むことを含む方法。 - フレーム・バッファの使用可能スペースが、ダブル・バッファされた表示域に割り振られていないフレーム・バッファのスペースである請求項４２に記載の方法。
- （ａ）サンプルを生成するためにグラフィックス・プリミティブをレンダリングし、サンプルをフレーム・バッファのサンプル記憶域に格納すること、
（ｂ）ピクセルを生成するためにサンプルをフィルタリングし、フレーム・バッファの表示可能領域の第１のバッファ・セグメントにピクセルを格納すること、
（ｃ）第１のバッファ・セグメントの対応する２つ以上の部分をターゲットとして、（ａ）および（ｂ）を２回以上実行すること、
（ｄ）第１のバッファ・セグメントの制御を出力プロセッサに渡すために、バッファ・スワップ・オペレーションを実行することを含む方法。 - （ｄ）の後、格納したピクセルを第１のセグメントからデジタル・アナログ変換装置へ転送することをさらに含む請求項４４に記載の方法。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US36359602P | 2002-03-12 | 2002-03-12 | |
| US10/383,165 US6999087B2 (en) | 2002-03-12 | 2003-03-06 | Dynamically adjusting sample density in a graphics system |
| US10/383,234 US6975322B2 (en) | 2002-03-12 | 2003-03-06 | Dynamically adjusting a number of rendering passes in a graphics system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004348169A true JP2004348169A (ja) | 2004-12-09 |
Family
ID=29554220
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003066615A Pending JP2004348169A (ja) | 2002-03-12 | 2003-03-12 | グラフィック・システムにおけるサンプル密度および／またはいくつかのレンダリング・パスの動的な調整 |
Country Status (3)
| Country | Link |
|---|---|
| EP (1) | EP1345168B1 (ja) |
| JP (1) | JP2004348169A (ja) |
| DE (1) | DE60317001D1 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008524720A (ja) * | 2004-12-20 | 2008-07-10 | エヌヴィディア コーポレイション | プログラム可能なハードウェアを用いたリアルタイムディスプレイの後処理 |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20130009964A1 (en) * | 2010-07-14 | 2013-01-10 | Dale Paas | Methods and apparatus to perform animation smoothing |
| US8780118B2 (en) * | 2011-06-13 | 2014-07-15 | Samsung Electronics Co., Ltd. | Techniques for synchronizing hardware accelerated graphics rendering and surface composition |
| KR102554419B1 (ko) * | 2017-12-26 | 2023-07-11 | 삼성전자주식회사 | 프리페칭된 그래픽스 데이터를 이용하여 타일 기반 렌더링을 수행하는 방법 및 장치 |
| CN111597886B (zh) * | 2020-04-07 | 2023-11-07 | 广州安凯微电子股份有限公司 | 一种用于指纹图像处理的硬件加速器、系统及加速方法 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2532267B1 (fr) * | 1982-08-31 | 1988-05-27 | Lely Nv C Van Der | Tracteur comportant une pluralite de roues motrices |
| US6424343B1 (en) * | 1998-02-17 | 2002-07-23 | Sun Microsystems, Inc. | Graphics system with programmable real-time sample filtering |
| US6496187B1 (en) * | 1998-02-17 | 2002-12-17 | Sun Microsystems, Inc. | Graphics system configured to perform parallel sample to pixel calculation |
| US7106322B2 (en) * | 2000-01-11 | 2006-09-12 | Sun Microsystems, Inc. | Dynamically adjusting a sample-to-pixel filter to compensate for the effects of negative lobes |
-
2003
- 2003-03-12 DE DE60317001T patent/DE60317001D1/de not_active Expired - Lifetime
- 2003-03-12 EP EP20030251516 patent/EP1345168B1/en not_active Expired - Lifetime
- 2003-03-12 JP JP2003066615A patent/JP2004348169A/ja active Pending
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008524720A (ja) * | 2004-12-20 | 2008-07-10 | エヌヴィディア コーポレイション | プログラム可能なハードウェアを用いたリアルタイムディスプレイの後処理 |
Also Published As
| Publication number | Publication date |
|---|---|
| EP1345168A2 (en) | 2003-09-17 |
| DE60317001D1 (de) | 2007-12-06 |
| EP1345168B1 (en) | 2007-10-24 |
| EP1345168A3 (en) | 2005-01-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6999087B2 (en) | Dynamically adjusting sample density in a graphics system | |
| US6975322B2 (en) | Dynamically adjusting a number of rendering passes in a graphics system | |
| US6816161B2 (en) | Vertex assembly buffer and primitive launch buffer | |
| US5701444A (en) | Three-dimensional graphics subsystem with enhanced support for graphical user interface | |
| US5990904A (en) | Method and system for merging pixel fragments in a graphics rendering system | |
| US5808617A (en) | Method and system for depth complexity reduction in a graphics rendering system | |
| US5790134A (en) | Hardware architecture for image generation and manipulation | |
| US6587112B1 (en) | Window copy-swap using multi-buffer hardware support | |
| US5949428A (en) | Method and apparatus for resolving pixel data in a graphics rendering system | |
| US5274760A (en) | Extendable multiple image-buffer for graphics systems | |
| US6924808B2 (en) | Area pattern processing of pixels | |
| US5835096A (en) | Rendering system using 3D texture-processing hardware for accelerated 2D rendering | |
| US5815166A (en) | Graphics subsystem with slaveable rasterizer | |
| US5798770A (en) | Graphics rendering system with reconfigurable pipeline sequence | |
| US5727192A (en) | Serial rendering system with auto-synchronization on frame blanking | |
| US5764243A (en) | Rendering architecture with selectable processing of multi-pixel spans | |
| US5886701A (en) | Graphics rendering device and method for operating same | |
| US6704026B2 (en) | Graphics fragment merging for improving pixel write bandwidth | |
| US6812928B2 (en) | Performance texture mapping by combining requests for image data | |
| US8681154B1 (en) | Adaptive rendering of indistinct objects | |
| US6975317B2 (en) | Method for reduction of possible renderable graphics primitive shapes for rasterization | |
| US6859209B2 (en) | Graphics data accumulation for improved multi-layer texture performance | |
| US5732248A (en) | Multistep vector generation for multiple frame buffer controllers | |
| US6867778B2 (en) | End point value correction when traversing an edge using a quantized slope value | |
| US6963342B2 (en) | Arbitration scheme for efficient parallel processing |