JP3886988B2 - データ生成タスクの並列実行システムおよび方法 - Google Patents

Description

本発明は、データ生成タスクの並列実行のためのシステムおよび方法に関し、より詳細な実装形態においては、３次元グラフィックス・アプリケーションにおけるジオメトリ関連データ生成タスクの並列に実行するためのシステムおよび方法に関する。

コンピュータ・グラフィックス・アプリケーションの設計者は、より興味深いレンダリングされたシーンをビューアー（viewer）に提供するために絶えず努力をしている。例えば、ゲーム開発者の多くは、レンダリングしたシーンの現実性を高めることを目指している。キャラクタや背景の写実的描写を提供するシーンは、プレーヤの興味を引きつけ、プレーヤがゲームにおいて実体験のように感じさせる可能性が高い。プレーヤの関心の高まりは、多くのプレーヤに供されるならば、ゲームの収益性も向上することになる。

レンダリングされたシーンの現実性を高めようと試みる場合、ゲーム開発者はいくつかの問題に直面する。通常、シーンの魅力を増すことは、シーンの複雑性を増すことに相当する。複雑性が増すと明らかに、シーンに関連するデータ量が著しく増加する。より具体的には、グラフィックス・アプリケーションは、シーン内のオブジェクト（例えばモデル）を多角形のメッシュを使用して表現する。この多角形は通常は三角形であり、（本明細書では概して「ジオメトリ・データ」と呼ぶ）いくつかの頂点を含む。通常、シーンの複雑性を増すことは、ジオメトリ・データ量の著しい増加に相当する。例えば、２つのキャラクタを対抗させる単純なゲームの場合について考察する。各キャラクタはモデルによって表現され、モデルは１組のジオメトリ・データからなる。ゲーム開発者が、キャラクタに関連するディテールの量を増加し、またはより多くのキャラクタをシーンに加えることによってゲームの現実性を高めることを望む場合、このシーンのレンダリングに必要なジオメトリ・データ量が著しく増加することが予想される。こうしたキャラクタの大群を示したシーンは、現在市場に出回っている多くのゲーム・プレイング・プラットフォームでレンダリングを実行可能にするには複雑すぎるとみなされるであろう。

Wolfgang F. Engel, Direct3D, 「ShaderX:Vertex and Pixel Shader Tips and Tricks」, 2002, Wordware Publishing, Inc. Dominic Mallinson, Inside Playstation 2: Architecture, Graphic Rendering, and Programming, accessible at http://www.bringyou.to/games/PS2.htm, accessed on February 2, 2004. Game Console Buying Guide, accessible at http://www.viewz.com/shoppingguide/consoleprint.htm, accessed on February 2, 2004.

より具体的には、上記の処理の制約は、通常のゲーム・プレイング・プラットフォーム環境でシーンをレンダリングする（例えば通常のゲームでは１６ミリ秒毎にシーン・フレームをレンダリングする）のに必要とされる短い時間で大量のゲーム関連ジオメトリ・データを生成し処理するという厳しい要求から生じる。これには、ゲーム関連データを生成し処理するための効率的なアルゴリズム、ならびにこのデータをゲーム・コンソール内で１つのモジュールから他のモジュールに転送する効率的な方法が必要である。より具体的には、グラフィックス処理の典型的なボトルネック（障壁）は、大量のデータをゲーム・コンソールの処理要素（例えばコンピュータ処理装置および／またはグラフィックス処理装置）とゲーム・コンソールのメモリ（例えばゲーム・コンソールのＲＡＭメモリ）との間で転送することである。

また、ゲーム開発者が、レンダリングしたシーンの複雑性、有効性（efficiency）、および／または現実性を高めるのを妨げる可能性がある（以下の論述で詳細に述べる）他の欠点がある。

したがって、当技術分野では、レンダリングしたシーンの複雑性を増すためのより効率的なシステムおよび技術を提供するための典型的なニーズが存在する。また、音声およびビデオ処理などの、他のデータ処理の分野において大量のデータを処理するためのより効率的なシステムおよび技術を提供する、当分野に類似するニーズが存在する。

例示の一実装形態によると、システム・メモリ、コンピュータ処理モジュール、データ処理モジュール、およびコンピュータ処理モジュールとデータ処理モジュールを相互接続する通信バスを有するシステムについて説明する。このコンピュータ処理モジュールは、タスクを実行するように構成されたホスト処理要素、およびタスク内のサブタスクを実行するように構成されたデータ生成処理要素を備える。データ生成処理要素は、入力データを受信するように構成された論理、および入力データを処理して出力データを生成するように構成された論理を含み、出力データ量は入力データ量よりも多く、入力データ量の出力データ量に対する比は圧縮解除（decompression）の比率を規定する。データ生成処理要素によって生成された出力データは、データ生成処理要素によって生成される前は、システム・メモリに収容されない。データ処理モジュールは、データ生成処理要素に結合されて出力データを受信するキャッシュ・メモリも備える。コンピュータ処理モジュール・インターフェースを使用して、出力データをそのキャッシュ・メモリから転送する。上記の「要素」は、１つまたは複数のコンピュータ処理装置で実装されるスレッドを指すことができる。

データ処理モジュールは、通信バスを介してコンピュータ処理モジュール・インターフェースを接続して出力データを受信するデータ処理モジュール・インターフェースを備える。データ処理モジュールは、キャッシュ・メモリからの出力データを受信し処理するためのデータ処理エンジンも備える。データ処理エンジンは、末尾ポインタを使用して、出力データを取り出したばかりのキャッシュ・メモリ内の位置を示す。

書込みストリーミング動作モードでは、コンピュータ処理モジュールは、ストリーミング書込みデータをデータ生成処理要素から受信するために、キャッシュ・メモリの一部を割り当てるように構成される。さらにこのモードで、システムは、出力データをシステム・メモリからではなくキャッシュ・メモリの割り当てられた一部からデータ処理モジュールに転送するように構成される。データ処理モジュールは、末尾ポインタをデータ生成処理要素のキャッシュ可能なアドレスに転送するように構成される。この末尾ポインタは、データ生成処理要素に、データ処理モジュールが出力データを取り出したばかりのキャッシュ・メモリ内の位置を通知する。

グラフィックス処理環境では、上記のシステムの使用により、グラフィックス・アプリケーションが効率的な並列処理方法を用いて大量のジオメトリ・データを生成することができる。このデータを実時間で生成することによって、（そうでなければこうしたデータを予め格納しておく必要がある）システム・メモリの必要メモリ（storage requirements）が低減される。さらに、（予め格納されたデータの取り出しとは対照的に）データの生成によって、システム・メモリへの頻繁なアクセスに関連付けられた有害な帯域幅制約が低減される。ストリーミング書込みデータをバッファリングするためのキャッシュ・メモリの割り当てられた一部の使用、および末尾ライト・バック・プロトコル（tail write-back protocol）の使用もシステム・メモリとの望ましくない相互作用を低減する。こうした改善によって、グラフィックス処理アプリケーションが、例えばゲーム環境で、実時間のレンダリングに十分な時間でより複雑なグラフィックスシーンを潜在的に提供することができるようになる。こうした改善は、また、並列処理方法の実装に使用される装置のコストも低減する。すなわち、こうした改善により、システム・メモリ、システム・バス、配信媒体、周辺バス、ネットワーク接続などの、記憶および帯域幅に関連するコストを減少することができる。

一実装形態では、具体的には１つまたは複数のデータ生成要素が、手続き型ジオメトリおよび／または高次の表面のテセレーション（tessellation）を実行するために使用することができる。（例えばＧＰＵモジュールとは対照的に）ＣＰＵモジュールでこうしたアルゴリズムを実行することによっていくつかの利点がもたらされる。例えば、一実装形態では、高次表面テセレーションのＣＰＵでの実装により、グラフィックス設計者に、より高次の表面テセレーション・アルゴリズムを選択／設計する際の柔軟性が与えられて、特定の処理環境のニーズを満たすことができるようになる。

関連する方法も本明細書に記載する。

本開示および図を通して、同じ番号を同様の構成要素および機能を示すために使用する。１００番代の番号は本来図１で見られる機能を指し、２００番代の番号は本来図２で見られる機能を指し、３００番代の番号は本来図３で見られる機能を指しており、以下同様である。

本開示は、データ生成タスクの並列実行のためのアーキテクチャおよび関連する技法に関する。こうしたデータ生成タスクは全般的に、第１組のデータを受信すること、次いでその第１組のデータに基づいて第２組のデータを生成することを伴う操作（operation）で、第２組のデータが第１組のデータよりも大量の情報を表す操作に関連する。第１組のデータと第２組のデータの比は、圧縮解除の比率を規定する。比較的高い圧縮解除比率を提供するアプリケーションは、背景技術の論述で定義したいくつかの問題に有効に対処することができる。例えば、比較的小さい１組の入力データから大量のデータを生成することができるアプリケーションでは、このデータを予め生成すること、システム・メモリに格納すること、およびその後こうしたデータを処理する時が来た場合にこのデータを取り出すこと、についての必要性を排除（または低減）する。したがって、こうしたアプリケーションは、システム・メモリとアプリケーションの処理モジュールとの間のデータの転送に関連付けられた有害な待ち時間および帯域幅の問題を回避することができる。さらに、こうしたアプリケーションは、限定されたリソースの場合が多く、特にゲーム・コンソールでは限定されたリソースとなるシステム・メモリに格納する必要がある情報の量を減らすこともできる。こうした改善により、ゲーム・コンソールの様々な構成要素に関連付けられたコストを低減することもできる。

グラフィカル・データに関するアプリケーション、音声データに関するアプリケーション、ビデオ・データに関するアプリケーションなどを含む、上記の設計戦略の多数のアプリケーションが想定される。ただし、説明を簡単にするため、以下の論述では、３次元コンピュータ・グラフィックスの分野、より具体的には３次元のゲーム関連のコンピュータ・グラフィックスの分野についての設計戦略のアプリケーションについて説明する。コンピュータ・グラフィックス・アプリケーションは、データ集中処理環境を表す。さらに、ゲーム・プレイング・コンソール環境では、かなり大量のデータを適時に処理する（例えばフレーム当たり１６ミリ秒でシーンをレンダリングするなどの）必要があり、またこのデータを、通常比較的限られたシステム・メモリ・リソースを有するアーキテクチャを使用して処理する必要がある。したがって、３次元ゲーム・アプリケーションは、上記の設計戦略の理想的なアプリケーションを表している。しかし、上述のように、本明細書で記載するアーキテクチャおよび技法は、こうした例示のアプリケーションに限定されるものではないと解釈されたい。

本開示は、以下の主なセクションを含む。セクションＡでは、上記の設計戦略を実装する例示のシステムを説明する。セクションＢでは、セクションＡで論じたシステムの例示の操作方法（manner of operation）を説明する。セクションＣでは、ゲーム・プレイング環境についてセクションＡおよびＢで説明したシステムおよび技法のアプリケーションについて説明する。

Ａ．例示のシステムアーキテクチャ
Ａ．１．システムの概要
図１は、レンダリングしたシーンで使用するより多くのジオメトリ・データを提供するシステム１００の概要を示す。システム１００は、パーソナル・コンピュータ（ＰＣ）、（Microsoft Corporation（Washington州、Redmond）によって製造されたＭｉｃｒｏｓｏｆｔのＸｂｏｘ（商標）ゲーミング・コンソールなど）ゲーミング・コンソール、または他の種類のプラットフォームなど、任意のプラットフォームに実装することができる。ジオメトリ・データとは、シーンをレンダリングするための３次元グラフィックス処理パイプラインで通常使用される情報を指す。通常のアプリケーションでは、データは、様々なキャラクタ、背景のオブジェクト、テクスチャなど、レンダリングされるシーンを構成する様々なオブジェクト（例えばモデル）を定義する、３次元グラフィックス処理パイプラインへの入力である。こうしたオブジェクトは、相互接続された多角形（ポリゴン）、通常は三角形、のメッシュとして表現される。各三角形は３つの頂点で構成される。この頂点は、頂点に関連する位置を識別する情報、ならびに頂点に関する他の情報（例えば色、テクスチャ座標、法線（normal）など）を収容する。例示の一実装形態では、単一の頂点に関連付けられた６４バイトの情報がある。（説明を簡単にするため、本明細書では主に技法および実装形態について上記で定義したようなジオメトリ・データの処理／生成に関連して説明する。ただし、この技法および実装形態は、任意の種類のデータの処理／生成に使用できることを留意されたい。）

例示の一実装形態では、システム１００は、フロント・サイド・バス１０６を介してグラフィックス処理装置モジュール１０４（以下、略して「ＧＰＵモジュール」１０４と呼ぶ）に接続されたコンピュータ処理装置モジュール１０２（以下、略して「ＣＰＵモジュール」１０２と呼ぶ）を備える。ＣＰＵモジュール１０２は、ＣＰＵ１（１０８）、ＣＰＵ２（１１０）、ＣＰＵｎ（１１２）（ここで、全般的に「ｎ」は収集したＣＰＵの最後のものを指す）など、任意の数のコンピュータ処理装置（ＣＰＵ）の収集を含む。こうした複数のＣＰＵ（１０８、１１０、…１１２）は、グラフィックスゲーム開発者によって指定された一連のプログラム命令に基づいてデータを処理する汎用コンピューティング・ユニットを提供する。ＧＰＵモジュール１０４は、受信データに関する低レベル３Ｄグラフィックス処理タスクを実行するグラフィックス・エンジン１１４を備える。

図１の２つの主なモジュール、例えばＣＰＵモジュール１０２およびＧＰＵモジュール１０４を以下にさらに詳細に説明する。

ＣＰＵモジュール１０２から始めると、ＣＰＵモジュール１０２は、様々な役割をその複数のＣＰＵ（１０８、１１０、…１１２）に割り当てる。例えば、ＣＰＵ１（１０８）は、ホスト処理装置として機能し、一方、ＣＰＵ２からＣＰＵｎ（１１０、…１１２）は、ジオメトリ処理装置として機能する。こうした役割に関連付けられたタスクは、様々なアプリケーション毎に異なる。通常のゲーミング・アプリケーションでは、ホストＣＰＵ１（１０８）は、プレーヤからの入力を受信し、シーンの管理を行い、アプリケーションによって示された物理現象をシミュレートするのに使用する計算を行い、ゲームによって提供される任意の人工知能を実行するなど、ゲームに関連付けられた高レベルのタスクを実行する。ＣＰＵ２からＣＰＵｎ（１１０、…１１２）は、ゲームに関連する、より細分化された（fine-grained）、処理を行う。一アプリケーションでは、こうした複数のＣＰＵ（１１０．．．１１２）は、シーン内の１つまたは複数のオブジェクトに関連するジオメトリ・データを生成する。例えば、以下に説明するように、こうしたプロセッサはそれぞれ手続き型ジオメトリを生成する論理を含むことができる。こうした論理は、実行すべきタスクを定義づける入力データを受信し、次いでこうしたタスクを実行して出力ジオメトリ・データ（例えば頂点の収集体（correction））を提供する。単に一例を挙げれば、ゲーム設計者は、木の個々の葉に関連付けられたジオメトリ・データを生成する手続き型論理を提供することができる。こうした手続き型論理は、個々の葉の位置、シーン内の任意にシミュレートされた風の方向などの、タスクに関連付けられた比較的限定された量の情報を受信する。この情報に基づいて、手続き型論理は、木の個々の葉を定義づける頂点を生成することができる。ジオメトリに関連するタスクを実行するＣＰＵを、ジオメトリ生成ＣＰＵと呼ぶ。

他のアプリケーションでは、ジオメトリ生成ＣＰＵ２からＣＰＵｎ（１１０、…１１２）は、高次の表面のテセレーションを行うことができる。高次の表面とは、三角形の単純なメッシュではなく、他のパラメトリック形式でオブジェクトを表すことを指す。しかし、大抵の３次元処理エンジンは、三角形などの、単純な多角形として表されたオブジェクトしか処理しない。テセレーションのプロセスでは、こうした高次表面を三角形など、より基本的な多角形に分割する。したがって、ジオメトリ生成ＣＰＵ２からＣＰＵｎ（１１０、…１１２）は、こうしたテセレーションを行うために、すなわち、高次表面を受信し、この表面をより基本的な形に分割するために使用することができる。例示の高次表面は、Ｂスプライン面、ベジェ面、ｎ−パッチなどを含む。

ジオメトリ生成ＣＰＵ２からＣＰＵｎ（１１０、…１１２）は、詳細レベル（level-of-detail：ＬＯＤ）処理と併せて、上述の手続き型ジオメトリおよび／または高次の表面テセレーションを提供することができる。ＬＯＤ処理では、シーン内のオブジェクトに関連付けられた複雑性のレベル（および、それによるジオメトリ・データ）は、ビューアーとシーン内の任意のオブジェクト（または任意のサブ・オブジェクト部分）との間の距離の関数として変化する。ＬＯＤ処理は、様々な圧縮比率を適用して様々な複雑性レベルを達成することができる。これは、より高い詳細レベルで、ビューアーに「近い」オブジェクトにより高レベルの圧縮解除を適用するという効果をもたらす。

上記で提供した例は、ジオメトリ・データ（例えば色、テクスチャ座標、法線（normals）など）の生成に関する。ただし、ＣＰＵ２からＣＰＵｎ（１００、…１１２）を使用して、ＧＰＵコマンドなど他の種類のデータを手続き型として生成することができる。

ｎ個のＣＰＵ（１０８、１１０、…１１２）を図１で示したが、上述のように、（例えば２つだけのＣＰＵの場合も含めて）任意の数のＣＰＵを備えることができる。さらに、追加のＣＰＵをホストに関連した機能の実行に充てることができる（すなわち２つ以上のＣＰＵをホスト関連の機能の実行に割り当てることができる。）。一実装形態では、ＣＰＵ（１０８、１１０、…１１２）はすべて同様に構成される。すなわち、ＣＰＵはすべて同一の命令セットを使用して動作するが、ゲーム開発者が提供したプログラムに基づいて異なる機能を実行する。例えば設計者は、ＣＰＵモジュール１０２の試験、およびゲーム開発者による後のＣＰＵモジュール１０２のプログラミングを容易にするためにＣＰＵモジュール１０２のＣＰＵがすべて同じ構成を持つように、ＣＰＵモジュール１０２を設計することを選ぶことができる。ただし他の実装形態では、１つまたは複数のホストＣＰＵを、ジオメトリ生成ＣＰＵとは異なるアーキテクチャおよび機能性を有するように設計することができる。

一適用例では、ＣＰＵ（１０８、１１０、…１１２）に静的に役割を割り当てるように、例えばＣＰＵにホストＣＰＵまたはジオメトリ生成ＣＰＵの役割を割り当てるように、システム１００を構成ことができる。他の適用例では、システム１００にこうした役割を、できればフレーム・ベース単位でフレーム毎に、または１つのフレーム内で（例えばイントラ−フレーム（intra-frame）ベースで）何回も動的に割り当てることができる。したがって、一適用例では、ＣＰＵ（１０８、１１０、…１１２）すべてにホスト関連のタスクを処理する役割を割り当てることができる。このことは、プログラマがジオメトリ生成ＣＰＵ２およびＣＰＵｎ（１１０、…１１２）によって提供される特別の機能を役立てることを望まない場合に適している。場合によっては、システム１００は、ジオメトリに関連する処理の役割をフレーム時間の一部でＣＰＵ（１０８、１１０、…１１２）すべてに割り当てることができる。また場合によっては、以下に論じるように、システムは１つまたは複数のＣＰＵモジュール１０２を備えることができる。この場合、システム１００は、（ジオメトリ処理など）同じ役割を１つのＣＰＵモジュール１０２内のＣＰＵすべてに割り当てることができる。このシナリオでは、ホスト処理の役割を割り当てたＣＰＵモジュール１０２をシステム・メモリ１３０に最も近接して配置することが有益であると考えられる。（なぜなら、環境によっては、ホストが、ジオメトリ処理機能よりもランダムアクセス読取りミスによって有害な衝撃を受ける可能性が高く、したがって、ジオメトリ処理機能よりも待ち時間を短縮する必要があるからである。）

各ＣＰＵは内部Ｌ１キャッシュを備える。例えば、ＣＰＵ１（１０８）は内部Ｌ１キャッシュ１１６を備え、ＣＰＵ２（１１０）は内部Ｌ１キャッシュ１１８を備え、ＣＰＵｎ（１１２）は内部Ｌ１キャッシュ１２０を備える。キャッシュとは、ＣＰＵに使用される可能性が高いデータを格納する、容易にアクセス可能な記憶空間（readily accessible storage space）を指す。Ｌ１キャッシュ（１１６、１１８、…１２０）は、図で示していないが、従来の方法で、命令関連の情報の格納に割り当てられる部分、データの格納に割り当てられる部分を含む。さらに、これも図で示していないが、各ＣＰＵ（１０８、１１０、…１１２）は、記憶レジスタの収集体（correction）を備える。記憶レジスタは、Ｌ１キャッシュ（１１６、１１８、…１２０）よりもさらに容易にアクセス可能な記憶場所を提供する。

ＣＰＵ（１０８、１１０、…１１２）は、それぞれバス・インターフェース・ユニット１２４、１２６、および１２８を介した複数のポートを通って共有Ｌ２キャッシュ１２２に結合される。その名が示すように、各ＣＰＵ（１０８、１１０、…１１２）は、Ｌ２キャッシュ１２２を共有する（例えば使用する）。図１で示したメモリの階層の説明を完全にすると、システム１００はシステム・メモリ１３０を備える。このシステム・メモリ１３０は、（一例では、キロバイトの範囲またはメガバイトの範囲などの記憶容量を有する）ランダム・アクセス・メモリ（ＲＡＭ）記憶装置を提供する１つまたは複数の記憶装置を備える。ＧＰＵモジュール１０４は、メモリ・コントローラ１３２を介してシステム・メモリ１３０と対話する。

Ｌ２キャッシュ１２２は、個々のＬ１キャッシュ（１１６、１１８、１２０）と同様に、ＣＰＵ（１０８、１１０、…１１２）およびＧＰＵモジュール１０４によって要求される可能性が高い情報を格納する。すなわち、これらのキャッシュ（１１６、１１８、１２０、１２２）は、システム１００の処理機能が、システム・メモリ１３０から読取りまたはそれに書き込む必要なくデータにアクセスできるようにする。システム・メモリ１３０からの読取りまたはそれへの書込みは、待ち時間の遅延をもたらす（例えば例示の一実装形態では、１００サイクルを超える遅延の可能性がある）ため、こうした操作を回避することは一般に望ましいことである。しかし、データがキャッシュ（１１６、１１８、１２０、１２２）の１つから得られない場合は、システム１００の処理機能は、システム・メモリ１３０内のこうしたデータにアクセスする。図４および５に関連してさらに詳細に説明するように、共有Ｌ２キャッシュ１２２は、ｎ−ウェイ・セット・アソシアティブ（n-way set associative）キャッシュとして実装することができる。物理的実装に関しては、一例では、Ｌ２キャッシュ１２２は、キロバイト範囲またはメガバイト範囲などの全メモリ容量を有するＲＡＭメモリの収集体を備えることができる。

ＣＰＵモジュール１０２は、さらに、クロスバー結合機構１３４（以下では略して単にクロスバー１３４と呼ぶ）を備える。このクロスバー１３４は、複数の入力ポートの任意の１つを複数の出力ポートの任意の１つに選択的に接続する切替機構を備える。クロスバー１３４の実装には、多重化機構を使用するなど、様々な方法がある。

クロスバー１３４は、Ｉ／Ｏインターフェース１３８を介したＩ／Ｏモジュール１３６など、いくつかのエンティティへの接続性を提供する。Ｉ／Ｏモジュール１３６は一般に、特定のアプリケーションに接続して、入力を受信し、かつ／または出力を提供する任意の機能を示す。ゲーム・アプリケーションでは、Ｉ／Ｏモジュール１３６は、Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ（ＵＳＢ）機構などを介した様々なコントローラを使用して、ゲーム・プレーヤからの入力を受信することができる。このＩ／Ｏモジュール１３６は、ネットワーク接続性（network connectivity）、音声システム結合なども提供することができる。

クロスバー１３４は、対称型多重処理（Symmetric Multiprocessing（ＳＭＰ））インターフェース１４２を介して他のＣＰＵ処理モジュール１４０へのオプションの接続性も提供する。対称型多重処理とは、複数のＣＰＵが同じメモリ・スペースおよびオペレーティング・システムを共有する構成（arrangement）を指す。このような機能が特定のアプリケーションに望ましいと判断された場合に、任意選択の他のＣＰＵモジュール１４０はその付加的な処理パワーをシステム１００に提供する。

クロスバー１３４は、また、ＧＰＵインターフェース１４４およびＣＰＵインターフェース１４６を介してＧＰＵモジュール１０４に接続性を提供する。フロント・サイド・バス１０６は、ＧＰＵインターフェース１４４とＣＰＵインターフェース１４６を結合する。バス１０６は、ジオメトリ生成ＣＰＵ２からＣＰＵｎ（１１０、…１１２）によって生成される大量データを処理するための十分な帯域幅、ならびにホスト帯域幅およびコヒーレンシ・トラフィック（coherency traffic）を有する必要がある。ＧＰＵモジュール１０４内の別のクロスバー１４８は、ＣＰＵ２からＣＰＵｎ（１１０、…１１２）から受信したジオメトリ・データ（ならびに他のデータ）をグラフィックス・エンジン１１４に向ける。グラフィックス・エンジン１１４は、多様なグラフィックス関連の操作を行うことができる。こうした操作は、（通常、頂点データを幾何学的に変換し、頂点データにライティング、例えばシェーディングを与える）頂点処理、背面の除去（backface culling）処理、クリッピング処理、三角形セットアップ処理、ラスタ化、ピクセル・ベースのシェーダ処理、フォグ処理、アルファ・テスト、深度テスト、ステンシル・テスト、アルファ・ブレンディング、ディザリングなどを含む、従来の３次元グラフィックス処理パイプラインに関連した様々なタスクを含むことができる。従来のグラフィックス・パイプライン処理の例示の概要は、文献（例えば、非特許文献１）に記載されている。例示の一実装形態では、ＣＰＵ（１０８、１１０、…１１２）は、ＧＰＵモジュール１０４によって提供される機能とはいくつかの点で異なる。例えば、ＣＰＵ（１０８、１１０、…１１２）は通常、ＧＰＵモジュール１０４よりも、はるかに多くの汎用ソフトウェア・プログラミングモデルを有し、単一のスレッド化アプリケーションではるかに良好に機能し、より多くの判断に基づいた分岐を可能にする。他の実装形態では、ＣＰＵ（１０８、１１０、…１１２）が提供する機能とＧＰＵモジュール１０４が提供する機能の差は少ないと言うことができる。

以下のセクションＢで論じるように、例示の一実装形態では、ＧＰＵモジュール１０４は、ダイレクト・メモリ・アクセス（ＤＭＡ）プロトコルを使用してメモリと対話する。例えば、システム１００は、ＤＭＡ機構を使用してコマンド・リスト取出し（fetch）を行う。このＤＭＡ機構は、データがどこから入手されたか「知らない」。データを正確な位置から取り出すのはクロスバーの機能であるためである。一実装形態では、システム１００は、フロント・サイド・バス１０６を介してデータを取り出すために、ＣＰＵモジュール１０２からの「読取り」を開始する特定のパケットを生成する。

コヒーレンシ・モジュール１５０は、ＣＰＵキャッシュ常駐データがメイン・メモリとコヒーレントのままであることを任意選択で保証する。コヒーレンシ・モジュール１５０は、システム１００によって提供されるデータ・ストリーミングに特に適合された機能も提供するが、こうした機能は、伝統的なキャッシュ・コヒーレンシとは１つまたは複数の点で異なる。コヒーレンシ・モジュール１５０の動作に関するさらなる詳細を以下にセクションＢで述べる。

例示の一実装形態では、ＣＰＵモジュール１０２は、ゲーム・プレイング・コンソールで第１のチップとして実装され、ＧＰＵモジュール１０４はゲーム・プレイング・コンソールで第２のチップとして実装される。追加のＣＰＵモジュール・チップを、関連するＧＰＵモジュール・チップと共に含むことができる。他の実装形態では、図１で示した機能を図１で示したものとは異なる方法で共にグループ化することができる。

Ａ．２．マルチ−スレッド化
図１では、各ＣＰＵ１０８、１１０、１１２の全体のそれぞれが、ホスト関連処理の単一スレッド、またはジオメトリ生成処理の単一スレッドに充てられている。しかし、図２は、ＣＰＵ（１０８、１１０、…１１２）内の処理リソースを複数のスレッド（例えば、２つ以上のスレッド）に割り当てる構成２００を示している。すなわち、ＣＰＵ１（１０８）は、ホスト関連処理に充てた複数のスレッド（２０２、２０４、…２０５）を含む。ＣＰＵ２（１１０）は、ジオメトリ関連処理に充てた複数のスレッド（２０６、２０８、…２０９）を含む。ＣＰＵｎ（１１２）は、ジオメトリ関連処理に充てた複数のスレッド（２１０、２１２、…２１３）を含む。他の実装形態では、単一のＣＰＵに関連付けられた役割をホスト関連の処理とジオメトリ関連の処理（または他の種類の処理）に分割することができる。例えば、ＣＰＵ１（１０８）のスレッド２０２をホスト関連の処理に充て、スレッド２０４をジオメトリ関連の処理に充てることができる。一実装形態では、細分化ハードウェア・スレッド化技法を使用してマルチスレッド化を実装することができる。

一般に当技術分野で周知のように、スレッドとは、処理装置によって実行されるタスクを指し、通常、一連のサブタスクを備え、このサブタスクはこうしたサブタスクのシーケンスを形成する特定の順序で実行される。２つのスレッドを収容する例示の処理装置は、２つのこうしたタスクの間でリソースを割り当てる。例えば、一例では、処理装置は、複数のサブタスクを含む第１のタスク（スレッド）を実行することができる。こうしたサブタスクの実行中に、データ・ハザードに遭遇した場合は、サブタスクの処理に遅れが生じる。例えば、データを即時にアクセス可能なキャッシュの位置から得ることができない場合、システムは、システム・メモリ１３０などあまり簡単にアクセスできないソースからデータを取り出さなければならない。この操作は、第１のスレッドの実行に数百サイクルの可能性がある遅延をもたらすことがある。こうした遅延は、第１のスレッドの実行における「バブル」を表現するものである。処理装置がこのバブル中にアイドル状態にならないように、処理装置は、処理装置のアイドル・リソースを使用して第２のスレッドのサブタスクを実行するように構成される。こうすると、処理装置は、そのリソースをより有効に使用し、また潜在的にシーンのレンダリングを促進する。

図２で示した構成２００では、各スレッドはそれ自体のＬ１キャッシュ（または１つのＬ１キャッシュのそれ自体の部分）を含む。例えば、各ＣＰＵが２つのスレッドを備える例示の場合では、構成２００は、Ｌ１キャッシュ２１４、２１６、２１８、２２０、２２２、および２２４を備える。他の実装形態では、ＣＰＵの各スレッドは共通のＬ１キャッシュを使用する。この構成は図２で示され、スレッド２０２、２０４などに単一のＬ１キャッシュ２２６を例示的に提供することで示している。

図では示していないが、ＧＰＵモジュール１０４も１つまたは複数のスレッドを使用して、割り当てられたタスクを実行することができる。

さらに、（例えば図５を参照する）以下の論述では、複数のＣＰＵを使用し、各ＣＰＵが複数のスレッドを含むことができる例を示す。ただし他の実装形態では、ＣＰＵモジュールは、複数のスレッドを有するＣＰＵを１つだけ使用することができる。この単一のＣＰＵのシナリオでは、ホストの役割を果たす１つまたは複数のスレッドを提供し、ジオメトリ・データを生成する役割を果たす１つまたは複数のスレッドを提供することができる。一般用語「処理要素」は、本明細書では広範な機能（connation）を有し、例えば、単一スレッド化ＣＰＵまたはマルチスレッド化ＣＰＵに実装されたスレッド、あるいは他の種類の処理機能を指すことができる。

Ａ．３．帯域幅の考察
図３は、ジオメトリ関連のタスクに充てたＣＰＵ２からＣＰＵｎ（１１０、…１１２）を使用したジオメトリ・データの生成、ならびに、これらのユニット（１１０、１１２）に供給されたデータ量に対して、これらのユニットが供給するジオメトリ・データ量を測定した結果の圧縮解除の比率を、示すものである。より具体的には、ＣＰＵ２（１１０）は、（詳細レベル（level-of-detail）の処理と共に）手続き型ジオメトリ論理または高次表面テセレーション論理など、データ生成論理３０２を含む。同様に、ＣＰＵｎ（１１２）は、（詳細レベルの処理と共に）手続き型ジオメトリ論理または高次表面テセレーション論理データ生成論理３０４を含む。論理３０２に与えられる入力データを比較的細い矢印３０６で示し、論理３０２によって生成される出力データを比較的太い矢印３０８で示す。これは、上記で強調した概念を示すものであって、すなわち、論理３０２は比較的少量のデータを受信し、それに反応して比較的大量のジオメトリ・データを生成することを示している。（細い矢印３０６で示した）入力データと（太い矢印３０８で示した）出力データの比を、論理３０２の圧縮解除比率と呼ぶ。こうした圧縮解除比率は一適用例では少なくとも１対１０、他の適用例では少なくとも１対１００、また別の適用例などでは少なくとも１対１０００、またはそれより大きくてもよい。例えば、少なくとも１対１００の圧縮解除が提供された場合は、入力データ量の出力データ量に対する比が少なくとも１／１００であることを示す。ＣＰＵｎ（１１２）は、矢印３１０で示した入力データを受信し、矢印３１２で示した出力データを提供する。ＣＰＵ２（１１０）についての論述は、ＣＰＵｎ（１１２）の機能にも当てはまる。ＣＰＵ２（１１０）からＣＰＵｎ（１１２）によって提供された出力データは、ＧＰＵ処理モジュール１０４に供給され、例えば、従来の３次元グラフィックス処理パイプラインでさらに処理される。（上記の論述は、システム１００の例示の利点を強調するために、比較的大きい圧縮解除比率に関連して構成されているが、例えば１対１０など比較的小さい圧縮解除比率も可能である。）

図１で提供したバスを、上記で論じた読取りの帯域幅（reading bandwidth）と書込みの帯域幅（writing bandwidth）の間の非対称性に対応するように適合させることができる。例示の一実装形態では、書込みの帯域幅を読取りの帯域幅の約２倍または３倍にすることによって、これを実装することができる。場合によっては、システム１００は、圧縮解除比率１対１００、または１対１００、あるいはそれ以上を実現することができる。ただし、こうした比較的大きい圧縮解除比率は、手続き型ジオメトリ生成に関与する書込み動作のストリーミング中、または他の（データの圧縮解除に関与する、または関与しない）高帯域幅の書込み動作中のシステム１００の動作を単に反映するだけである。したがって、それぞれ読取りと書込みの帯域幅の間にこうした大差がない場合は、読取りと書込みの帯域幅の間の比較的小さい比率（すなわち、約１対２、１対３などの比率）を提供して、他の処理モードに対応することができる（ただし、処理環境および他の考察によって、他の実装形態では、読取りの帯域幅に比べて比較的大きい書込みの帯域幅を提供することができる）。

例示する一実装形態の全体では、これらのＣＰＵは、特定のデータ処理環境の要件によって、秒当たり数千または数百万の頂点、または秒当たり別の量の頂点のジオメトリ・データの集合体ストリームを生成することができる。例示の一実装形態では、頂点当たり数バイト（例えば３２、６４、１２８など）の非圧縮データを使用するが、これはＣＰＵモジュール１０２からＧＰＵモジュール１０４へのＭＢ／ｓまたはＧＢ／ｓの帯域幅に相当する。しかし、これより小さい、または大きいレートを提供することもできる。

上述の高レベルの圧縮解除にはいくつかの利点がある。例えば、ゲーム・コンソールの場合は、高レベルの圧縮解除を提供することは、（例えば待ち時間の短縮によって）コンソールの性能を向上させ、コンソールのシステム・メモリ要件（system memory requirements）（および関連するコスト）を低減させる。ＣＰＵモジュール１０２に高レベルの圧縮解除をもたらすことによって、ゲーム・コンソールの他の構成要素、システム・バス、配布媒体（例えばＤＶＤ）、周辺バス、ネットワーク接続などの複雑性および関連コストを低減することもできる。例えば、ＣＰＵモジュール１０２に適用される圧縮解除により、ゲーム・コンソールの他の構成要素で従来使用される圧縮／圧縮解除方式の複雑性および関連コストを低減することができ、または場合によって、こうした伝統的圧縮方式をなくすこともできる。

Ａ．４．Ｌ２キャッシュ
図４および５は、図１で示したＬ２キャッシュ１２２の構成および動作に関する、さらなる詳細を提供するものである。例示の一実装形態では、図４から開始して、Ｌ２キャッシュ１２２は、ｎ−ウェイ・セット・アソシアティブ・キャッシュとして実装され、一実装形態では、ｎは１６以下でもよい（ただし、他の実装形態では１６セットよりも多いセット・アソシアティブ・キャッシュを使用することができる）。より具体的には、Ｌ２キャッシュ１２２は複数のセット（４０２、４０４、４０６、…４０８）を含む。各セットは、それに関連付けられた様々なフィールドを有する複数のキャッシュ・ラインを含む。第１のフィールド４１０は、特定のラインに提供された情報が有効か無効かを示す有効性ビット（validity bit）を提供する。第２のフィールド４１２は、アドレス・マッチングのために使用するタグ情報を提供する。第３のフィールド４１４はデータを提供する。従来の論理要素のグループは、アドレス４１６をＬ２キャッシュ１２２のエントリと突合せ、その位置に格納されたデータを出力する。すなわち、アドレス４１６の指標（インデックス）部分４１８を使用して、Ｌ２キャッシュ１２２内の特定のキャッシュ・ライン４２０を識別する。アドレス４１６のタグ部分４２２は、Ｌ２キャッシュ１２２のフィールド４１２に格納されたタグ情報と、指標部分４１８によって識別されたキャッシュ・ライン内のタグ部分４２２とを比較することによって、システム１００がＬ２キャッシュ１２２内のデータの特定部分を識別できるようにする。比較要素４２４、４２６、４２８、および４３０は、こうしたタグ比較機能を実行する。要素４３２、４３４、４３６、および４３８は、Ｌ２キャッシュ１２２内の一致した位置に格納されたデータを転送する。

図５は、図４で示した各セットを様々な処理スレッド（２０２〜２１３）に割り当てることができる方法を示す。これらの処理スレッド（２０２〜２１３）およびその構成の機能については図２を参照して論じたので、ここでは再び説明しないが、各ＣＰＵ（１０８、１１０、…１１２）は２つ以上のスレッドを使用することができることを指摘する。ただし、論述を簡単にするために、各ＣＰＵのスレッドのうち２つだけが提供された機能を以下に説明する。上述のように、例示の一実装形態では、Ｌ２キャッシュ１２２は（一例では１６以下などの）ｎ−ウェイ・セット・アソシアティブ・キャッシュとして実装される。したがって、図５は、ｎ個のセットのラベル付きセット１からセットｎを示す。

序論として、図１で示したシステム１００は、書込みデータ・ストリーミング・モードで動作することができ、ジオメトリ生成タスクに割り当てられたＣＰＵは大量のジオメトリ・データを生成する。ＣＰＵモジュール１０２は、この大量ジオメトリ・データをＣＰＵモジュール１０２からＧＰＵモジュール１０４にフロント・サイド・バス１０６を介して転送する。Ｌ２キャッシュ１２２は、ジオメトリ・データをＧＰＵモジュール１０４に転送する前にバッファリングすることによってこの動作モードを容易にする。より具体的には、書込みストリーミング動作モードで、システム１００は、１セットのＬ２キャッシュ１２２をロックし、このロックしたセットを使用してジオメトリ・データのＧＰＵモジュール１０４への転送を容易にする。図５は、こうしたロックされたセット５０２を示し、Ｌ２キャッシュの残りのセットはアンロック状態のままである（アンロック・セット５０４と呼ぶ）ことを示す。システム１００は、ホスト関連の役割に関連するスレッド２０２および２０４をアンロックされたセット５０４に割り当て、書込みストリーミングを実行する目的で、スレッド２０６〜２１２をロックされたセット５０２に割り当てる。換言すれば、スレッド２０２および２０４は、書込みストリーミング・データの生成には直接的役割を果たさず、したがってロックされたセット５０２と関連づけられていない。スレッド２０６〜２１２は、書込みストリーミング以外の様々な目的でアンロックされたセット５０４にアクセスすることもできる。例えば、例示の一実装形態では、スレッド２０６〜２１２は、アンロックされたセット５０４内のデータがデータに関連付けられた低帯域幅を有し、複数のスレッドによって再び読み出される可能性が高い場合は、そのデータへのアクセスが許可される。以下で説明するように、高帯域幅の動作時に、スレッド２０６〜２１２がアンロックされたセット５０４へアクセスすること可能にすることは、ホストスレッド２０２および２０４の性能を低下させる潜在的な負の効果をもたらし、したがって、禁止される。

様々な戦略を使用してロックされたセット５０２を提供することができる。例えば、キャッシュ・ラインは、通常、（読取りまたは書込み動作で）キャッシュ・ラインがどの程度最近アクセスされたかに関する判定など、様々な要因に基づいてキャッシュからキャスト・アウト（cast out）される。したがって、セット５０２は、ロックされたセット５０２内のエントリが常にごく最近アクセスしたＬ２キャッシュ１２２内のエントリであることを示すように、キャッシュ管理論理（図示せず）を構成することによってロックすることができる。これによって、こうしたエントリがリタイアする（例えば「キャスト・アウトされる」）のが阻止される。同じロッキング機能を果たす他の戦略もある。

複数の先入れ先出し（ＦＩＦＯ）バッファ５０６、５０８、５１０、および５１２は、ロックされたセット５０２内に生成される。この例の場合は、４つのバッファが示してあるが、これよりも少ない、または多い数のバッファを提供することができる。こうしたバッファ（５０６、５０８、５１０、５１２）は、それぞれ複数の記憶要素を含み、それぞれジオメトリ生成処理スレッド（２０６、２０８、２１０、２１２）からデータを受信し、こうしたデータがＧＰＵモジュール１０４によって取り出されるまでこのデータを格納する。すなわち、こうしたバッファ（５０６、５０８、５１０、５１２）は、スレッド（２０６、２０８、２１０、２１２）の書込み速度が通常ＧＰＵモジュール１０４の読取り速度と同期状態になく、したがってアクセスできるようになるまで処理スレッド（２０６、２０８、２１０、２１２）の出力を一時的に格納する機構が必要であることに対応するものである。より具体的には、各ＦＩＦＯ（５０６、５０８、５１０、および５１２）は、各ＦＩＦＯに関連付けられた末尾ポインタ（tail pointer）（図示せず）を含む。この末尾ポインタは、ＧＰＵモジュール１０４のフィールドからのデータを読取りがどの程度進行したかをＦＩＦＯに関連するスレッドに通知する。この情報により、スレッドは、新規のジオメトリ・データを受けるためにＦＩＦＯ内の記憶要素がどの程度解放されたかを判断することができるようになる。物理的実装に関して、一例では、ロックされたセット５０２はキロバイトの範囲の記憶容量を提供することができ、各ＦＩＦＯは、その容量の一部を提供するが、他の実装形態では、これよりも小さい、または大きいＦＩＦＯ記憶容量を提供することができる。

各ＦＩＦＯは、別個の開始位置および終了位置を有する。したがって、ＦＩＦＯに関連するＣＰＵは、ＦＩＦＯ内の格納位置を定期的に監視して、ＣＰＵがＦＩＦＯの末端部を越えてデータを格納しようとしないことを保証しなければならない。ＣＰＵがそれぞれのＦＩＦＯ内の最後の格納位置に格納する場合、ＣＰＵは次のデータをそのＦＩＦＯ内の最初の格納位置に、ラップ・アラウンドして（回り込んで）、格納しなければならない。このようにして、ＣＰＵはＦＩＦＯを循環バッファとして使用する。しかし、この技法の一欠点は、ＣＰＵがＦＩＦＯを介した進行を定期的に監視して、ＦＩＦＯの末端部をオーバーシュートしないことを保証しなければならないことである。この検査を行うことは、ストリーミング書込み動作の複雑性を増加させ、またストリーミング書込み動作に潜在的に遅延をもたらす可能性がある。この問題に対処する一技法は、アドレスの中間部を使用してＦＩＦＯ内にラップする（送り込む）ことである。例えば、スレッド２１２に関連するＦＩＦＯ５１２について考察する。ラップすることは、アドレス５１４のトップおよびボトムのビットを無視することによって、ＦＩＦＯ５１２内で実行される。アドレス５１４のトップおよびボトム・ビットは、（図５でｘで示したように）それぞれ「無視」ビット・フィールド５１６および５１８で示される。

Ｌ２キャッシュ１２２にロックされたセット５０２を提供する場合、ジオメトリ生成スレッド（２０６、２０８、２１０、２１２）の出力に関連付けられた書込みの高帯域幅が、Ｌ２キャッシュ１２２を「スラッシング（thrashing）」するのを防止することが望ましい。すなわち、ホスト関連のスレッド（２０２、２０４）は、従来のキャッシュに関連する目的でＬ２キャッシュ１２２の使用を、つまり、こうしたスレッド（２０２、２０４）によってアクセスされる可能性が最も高いデータを格納すること、を要求する。しかし、Ｌ２キャッシュ１２２内のセットをロックしない、キャッシュ・メモリに使用される置換え戦略を考慮すると、ジオメトリ生成スレッド（２０６、２０８、２１０、２１２）によって生成された大量のデータ書込みは、キャシュ１２２の外部にホストのデータを事実上キャストする（なぜならジオメトリ生成スレッドによって提供されたデータは、敏速に、ごく最近使用されたデータの位置を見込むからである）。これが生じると、ホスト関連の処理スレッド（２０２、２０４）は、システム・メモリ１３０など遠隔のメモリの中から、求められたデータにアクセスすることが必要になり、それによって処理の遅延が生じる。この有害な現象は上述の「スラッシング」に相当する。これが生じるのを防止するため、システム１００は、ホスト関連の処理スレッド（２０２、２０４）の要求をジオメトリ生成スレッド（２０６、２０８、２１０、２１２）から分離する。このロッキング対策により、上記のスラッシングが防止される。さらに、ロックされたセットを使用せずに、ジオメトリ生成スレッドによって提供されるデータの一部もそれ自体キャッシュの外部にキャストされ、ＧＰＵがそれを使用することが可能になる前にシステム・メモリにラウンド・トリップさせる。大量データが生成されれば、許容不可能な帯域幅が要求されるようになる。そのためまた、ＧＰＵモジュール１０４を待たせることによって全体の性能を低下させる遅延が生じることになる。

上記で述べたように、図１で示したシステム１００は、ＣＰＵ１０８、１１０、１１２に関連する役割を動的に割り当てることができる。同じように、Ｌ２キャッシュ１２２の構成を同様に動的に変更することができる。例えば、ゲーム開発者がジオメトリ生成ＣＰＵ２からＣＰＵｎ（１１０、１１２）によって提供される特別の機能の使用を望まない場合は、システム１００はキャッシュ１２２全体をホスト関連の機能に割り当てることができる。あるいは、システム１００は、２セット以上のＬ２キャッシュ１２２をストリーミング書込み動作に関与するジオメトリ関連のスレッドに割り当てることができる。

図６は、ＣＰＵ処理モジュール６０２の他の実装形態を示す。図６で示したＣＰＵ処理モジュール６０２は、ホスト関連のＣＰＵ１（１０８）にそれ自体の専用Ｌ２キャッシュ６０４が設けられており、Ｌ２キャッシュ１２２をジオメトリ生成ＣＰＵ（１１０、…１１２）と共有する必要がない点で、図１で示したＣＰＵ処理モジュール５０２と異なる。すなわち、図６の実装形態では、共有Ｌ２の１２２はＣＰＵ２からＣＰＵｎ（１１０、…１１２）だけに結合されている。図６で示したこの構成では、ホスト関連のＣＰＵ１０８はそれ自体のＬ２キャッシュ６０４を有しており、したがって他のＣＰＵ（１１０、１１２）がこの専用Ｌ２キャッシュ６０４をスラッシングする可能性がないため、Ｌ２キャッシュ１２２内のセットをロックする必要がない。

Ａ．５．命令セットの変更
図７および図８は、ＣＰＵ（１０８、１１０、…１１２）で使用される論理になされた改善に関する。すなわち、通常、ＣＰＵはプログラミング命令ストックの規定のセットを使用してプログラミングできるように設計されている。こうしたプログラミング命令は、ロードおよび格納操作、算術演算、分岐操作などの組合せに関する。図７および８は、グラフィックス・アプリケーションで使用されるＣＰＵアーキテクチャでよく見られる命令セットに対する２つの改善を示す。

まず、図７は、ジオメトリ・データをＣＰＵ（１０８、１１０、…１１２）から出力する前に圧縮するのに使用する論理７００を示す。上述のように、本開示で使用する用語、ジオメトリ・データとは主にシーンでレンダリングすべき表面を構成する三角形に関連する頂点情報を指す。論理７００は、（処理ブロック７０２で示すように）非圧縮ジオメトリ・データを受信するステップ、（処理ブロック７０４で示すように）このジオメトリ・データを圧縮するステップ、および（処理ブロック７０６で示すように）圧縮したジオメトリ・データを出力するステップを含む。ＣＰＵの命令セットうちの１つまたは複数の命令は、論理７００で示す一連の動作を開始させることができる。

一実装形態では、論理７００は、第１のＣＰＵレジスタ内に非圧縮ジオメトリ・データを受信するステップ、プログラムの命令によって指定されたように、このジオメトリ・データの圧縮を行うステップ、次いでこの圧縮ジオメトリ・データを他のＣＰＵレジスタにロードするステップを含む。他の実装形態では、圧縮操作を、ＣＰＵから情報を出力することができる任意の機能に組合せることができる。

圧縮自体に関しては、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｔｏｎから提供されるＭｉｃｒｏｓｏｆｔ（登録商標）ＤｉｒｅｃｔＸ（登録商標）９．（ｎ）で使用される圧縮技法など、多様な周知の戦略を使用して、ジオメトリ・データを圧縮することができる。より具体的には、頂点に関連付けられた様々なタイプの情報を様々な技法を使用して圧縮することができる。さらに、頂点に関連付けられた様々なタイプの情報は、異なる圧縮比を受け入れることができる。例えば、最初のタイプの情報は、２対１の圧縮比で圧縮され、他のタイプは４対１などの圧縮比で圧縮されてもよい。この意味で、論理７００で提供される圧縮は、可変可能な圧縮を指す（すなわち、頂点内の様々なタイプの情報に対して可変であることを指す）。さらに、圧縮は、アプリケーションの必要性に応じて同じタイプの情報に対して可変でもよい。例えば、ジオメトリ座標をあるメッシュに対しては８ビット値に圧縮し、配置の密度（fineness of placement）が重要であると判断される場合は、他のメッシュに対しては１６ビットまたは３２ビット値に圧縮することができる。

ＣＰＵ（１０８、１１０、…１１２）から出力されたジオメトリ・データの圧縮は、ＣＰＵモジュール１０２とＧＰＵモジュール１０４の間で転送されるジオメトリ・データの帯域幅を縮小することに役立つ。さらに、ジオメトリ・データの圧縮により、Ｌ２キャッシュ１２２のロックされたセット５０２のＦＩＦＯが、より多くのジオメトリ・データを格納できるようになる。

他の実装形態では、命令セットは、ＣＰＵで受信される情報を圧縮解除する論理も含む。この圧縮解除もやはり、データの様々な部分が様々な技法で圧縮解除され、様々な程度の圧縮解除を受ける可能性があるという点で可変であると考えられる。圧縮解除は、レジスタ間の操作で実装され、またはＣＰＵがデータを入力するために使用する任意の機能に統合することができる。後者の技法では、圧縮解除をＣＰＵの通常のロード・サイクルの一部として統合することができる。この圧縮解除機能にはいくつかの利点がある。まず、圧縮／圧縮解除機能を対称にして、ＣＰＵがメモリ階層の様々なレベル（例えば、メイン・メモリ、読取り専用内容媒体、またはＬ１／Ｌ２キャッシュ）に格納された圧縮データを読取りおよび書込みができるようにする。様々なゲーム機能はしばしば、かなり後に（例えば、長い時間がたって、そのデータがＣＰＵのキャッシュに残る可能性が非常に低くなってから）使用されるデータを生成する。このような場合、ＣＰＵによって生成されてＣＰＵの他のゲーム機能によって後に使用されるための圧縮データは、メイン・メモリの占有スペースがはるかに少なく、メモリへの書込みの帯域幅がより小さく、メモリからの読取りの帯域幅がより小さくてすむ。こうした占有スペースおよび帯域幅の改善のすべては、より多くのデータを格納する能力をもたらし、かつ／または、より多くのデータを有効な態様で提供することによって、より良好なゲームの機能性をもたらすことができるようになる。

図８は、理解しやすくユーザにやさしい方法でドット生成操作を提供する他の論理８００を示す。２つのグラフィックス関連ベクトルＶ_１（Ｘ_１、Ｙ_１、Ｚ_１、Ｗ_１）、およびＶ_２（Ｘ_２、Ｙ_２、Ｚ_２、Ｗ_２）の従来のドット・プロダクト積は以下のように形成される。ドット・プロダクト積＝Ｖ_１・Ｖ_２＝Ｘ_１Ｘ_２＋Ｙ_１Ｙ_２＋Ｚ_１Ｚ_２＋Ｗ_１Ｗ_２

より具体的には、最良の性能をもたらすために、多くの現在のＣＰＵの命令セットは、より理解しやすくユーザにやさしいＡｒｒａｙ ｏｆ Ｓｔｒｕｃｔｕｒｅ （ＡＯＳ）手法ではなく、Ｓｔｒｕｃｔｕｒｅ ｏｆ Ａｒｒａｙｓ（ＳＯＡ）手法を用いてドット積を実行することをユーザに要求する。後者の手法では、ドット生成の実行に使用されるオペランド・データをＣＰＵによって提供された適切なレジスタにロードする。次いで、このオペランド・データを、ＣＰＵによって使用されるＳＯＡ手法に対応する方法で「回転（rotating）」させて処理する。すなわち、１つのベクトルに他を乗算するには、このＳＯＡ技法では、１×４ベクトルを有効に横に回転して４×１ベクトルを提供する。これは、ベクトル・データを格納するために各レジスタのレーンを１つだけ使用するため、レジスタ容量を非効率的に使用することになる。さらに、（いわゆる「かきまぜ（swizzling）」操作で完了する）ベクトルを横に回転する操作は、ベクトル・データの有意義な変換を行っていない（すなわち、データに関して数学的操作を何も行っていない）という意味で「空の」実行サイクルを必要とする。プログラマが自分のデータをＡＯＳ形式で維持できるようにすることで、最適化への取組みが非常にやさしくなる。対照的に、ＳＯＡは普通のデータ構成設計、およびＡｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ（ＡＰＩ）パラメータの受け渡し（passing）に適合しない。さらに、ＳＯＡは一般に、プログラマのＳＩＭＤベクトル数学的（math）命令の使用を複雑にする。論理８００は、上記のＡＯＳ手法を用いてこうした欠点を克服するものである。（ただし、本システム１００で使用するＣＰＵは、ＳＯＡ手法を使用してもドット生成を行うことができるように構成されており、したがってユーザは、ＡＯＳ手法またはＳＯＡ手法を用いてドット生成を行う任意選択権が与えられる。）

より具体的には、論理８００は、（操作ブロック８０２で示したように）ドット生成の実行に使用されるオペランドを受信するステップ、（操作ブロック８０４で示したように）ＡＯＳ手法を用いてドット生成を行うステップ、次いで（操作ブロック８０６で示したように）ドット生成の結果を出力するステップを含む。

Ｂ．例示の操作方法
図９〜１１は、図１で示したシステム１００の例示の操作方法を示す。より具体的には、図９〜１１には、上述のジオメトリ・データ・ストリーミング機能に関連する操作の２つの態様（aspect）が示してある。図９は、ストリーミング動作に関連する読取り機能を示し、図１０および１１は、ストリーミング動作に関連する書込み機能を示すものである。これに関連して、「読取り」は情報を例示のジオメトリ生成ＣＰＵにロードすることを指す。ジオメトリ生成ＣＰＵは次いで、入力データに関する手続き型ジオメトリ（または他の処理）の実行を行って出力ジオメトリ・データを提供する。「書込み」は、こうしたデータをジオメトリ生成ＣＰＵからＧＰＵモジュールに転送することを指し、またそれに関連するキャッシュ管理の事柄すべてに関するものである。

読取りストリーミングおよび書込みストリーミングの動作（operations）を、図１で示したシステム１００全体の操作の概要と共に以下にさらに詳細に説明する。

Ｂ．１．読取りストリーミング
（読取りストリーミング動作を示す）図９から始め、手続き型ジオメトリ論理９０４（またはジオメトリ・データを生成する他の種類の処理論理）、レジスタ９０６、およびＬ１キャッシュ９０８を含む例示のＣＰＵ９０２を示す。Ｌ２キャッシュ９１０もこの図に示してある。読取りストリーム動作の目的は、入力情報を入力ソースから有効に受信することである。こうしたソースを図９で包括的にバス９１２として示す。バス９１２によって提供される情報は、（図１の）システム・メモリ１３０、ホストＣＰＵ、または他のソースに由来することができる。例えば、ゲーム環境で３次元シーンを生成する場合、入力情報は３次元グラフィックス処理パイプラインでレンダリングされるべきオブジェクトの位置、またはそのシーンの他の属性を表すことができる。

情報をＣＰＵ９０２にロードするために使用することができる様々な技法がある。パス９１４で示した一技法では、Ｌ１キャッシュ９０８は、ｎ−ウェイ・セット・アソシアティブ・キャッシュ（例えば４−ウェイまたはそれより多いセット・アソシアティブ・キャッシュ）として実装される。この技法では、情報はＬ２キャッシュ９１０をバイパスしてＬ１キャッシュ９０８のロックされたセット内に直接受信される。次いで、この情報をＬ１キャッシュ９０８からレジスタ９０６に転送することができる。パス９１６で示した他の技法では、情報はレジスタ９０６に直接転送される。パス９１８で示した他の技法では、情報は、Ｌ２キャッシュ９１０のロックされたセットに転送され、その後、レジスタ９０６に転送される。また他の技法（図示せず）では、セットをロックせずに、情報を２ウェイまたはそれより多いＬ１キャッシュ内にストリーミングすることができる。好ましい実装形態では、任意の技法を用いて、ＣＰＵ９０２は読取り情報を先取り（prefetch）する。すなわちＣＰＵ９０２は、使用の前にこの情報を要求する（つまり、ＣＰＵ９０２は、このデータの約１００あるいはそれ以上のサイクルなど、複数サイクルをデータの使用前に受信する。ただしこれよりも少ない先取りサイクルを使用することもできる）。先取りは、処理に望ましくない遅延をもたらす可能性があるデータ読取り機能停止の衝撃を低減することによって、ストリーミング動作を容易にする）。上述の技法は、特定の処理環境によって、様々な利点を提供することができる。例えば、Ｌ１キャッシュのセットのロッキングに関する技法は、そのＬ１キャッシュに関連付けられたＣＰＵだけに影響を与え、一方、共有Ｌ２キャッシュのロッキングはこのキャッシュに結合されたＣＰＵすべてに影響を与えることになる。

上述の方法でＬ１キャッシュ９０８またはＬ２キャッシュ９１０をバイパスすることは、ＣＰＵ９０２がＬ１キャッシュ９０８またはＬ２キャッシュ９１０からの入力情報を再び読み取る可能性が低いため、ＣＰＵ９０２の動作に負の影響を与えない。したがって、Ｌ１キャッシュ９０８およびＬ２キャッシュ９１０は、ＣＰＵ９０２に読み込む情報のコピーを格納する必要がない。換言すれば、ＣＰＵ９０２が入力情報を再び読み取る可能性が低いため、Ｌ１またはＬ２キャッシュは、最近受信した情報の簡単にアクセス可能なコピーを、後の読取りに備えて提供する従来の役割を担う必要がない。こうしたキャッシュをバイパスすることは、再使用される可能性が高い他のデータ（ストリーミング動作に関連していないデータなど）をキャッシュの外部にキャストさせてしまうことが回避されるため、このことは望ましいことである。すなわち、キャッシュのバイパスにより、ストリーミング動作がキャッシュをスラシングするのが防止される。

Ｂ．２．書込みストリーミング
図１０は、書込みストリーミング動作（operations）１０００を示す。この図は、手続き型ジオメトリ論理１００４（またはジオメトリ・データを生成する他の種類の処理論理）、レジスタ１００６、およびＬ１キャッシュ１００８を有する例示のＣＰＵ１００２を示す。ＣＰＵ１００２ならびにＧＰＵモジュール１０１４に割り当てられたＦＩＦＯ１０１２を含むＬ２キャッシュのロックされたセット１０１０が示してある。より具体的には、ＦＩＦＯ１０１２は、ＣＰＵ１００２によって転送されたジオメトリ・データを受信する。ＦＩＦＯ１０１２は、ＧＰＵモジュール１０１４が取り出すことができるジオメトリ・データの一時的レポジトリ（保管場所）としての働きもする。

データパス１０１６および１０１８は、書込みストリーミング動作で行われる動作を示す。ただし、こうした動作タスクが実行される前に、システム１００はＬ２キャッシュのセット１０１０（または潜在的に２つ以上のセット）をロッキングする予備ステップを実行する。ＦＩＦＯのセットアップには、ロックされたセット１０１０内のラインに有効かついわゆる「ダーティー」としてマークを付けることによって、キャッシュを適切にセットアップすることも含まれる。この操作には、タグおよびデータをロックされたセット内のキャッシュ・ラインに割り当てることも含まれる。この操作は、「ダーティー生成（create dirty）」手順と呼ばれ、システム・メモリ１３０への必須読取りアクセスを使用する読取りの割り当てを行わない。

Ｌ２キャッシュをロックし適切に開始させた後、書込みストリーミング動作は、ジオメトリ・データをＣＰＵ１００２からＬ２キャッシュのロックされたセット１０１０のＦＩＦＯ１０１２に（例えばＬ１キャッシュ１００８をバイパスして）直接転送することによって進行する。これは、ジオメトリ・データを受信するＦＩＦＯ１０１２内の格納位置に関連する適切なアドレス位置にジオメトリ・データを書き込むことによって行うことができる。この動作をデータパス１０１６で示す。Ｌ１キャッシュ１００８をバイパスすることによって、手続き型ジオメトリ論理１００４の高出力帯域幅がＬ１キャッシュ１００８をスラッシングするのが防止される。Ｌ１キャッシュ１００８をバイパスすることは、書込みストリーミング・データがＣＰＵ１００２によって再び読取られる可能性が低いため（したがって、このデータのコピーをＬ１キャッシュ１００８内に維持する必要がないため）、ＣＰＵ１００２の性能に負の影響を与えない。代替の一実装形態（図示せず）では、ｎ−ウェイ・セット・アソシアティブ・キャッシュを使用して、Ｌ１キャッシュ１００８を実装することができ、およびこうしたキャッシュで提供されるセットの１つをロックして書込みストリーミング動作がＬ１キャッシュ１００８をスラッシングするのを防止することができる。

ＦＩＦＯ１０１２が所定量のジオメトリ・データを格納した後、または情報の転送に関する他のいくつかの条件が満たされた後（例えば、ジオメトリを生成する所与のＡＰＩ呼び出しによって要求されたジオメトリがすべて完成されると）、システム１００はＧＰＵモジュール１０１４を起動（kick off）する。これは、ＧＰＵモジュール１０１４にＦＩＦＯ１０１２からの情報の取出しを促す。より具体的には、ＧＰＵモジュール１０１４はＤＭＡプロトコルを使用してＦＩＦＯ１０１２から情報を取り出すことができる。このＤＭＡプロトコルでは、ＧＰＵモジュール１０１４は、システム１００によってそれに提供されたアドレスに応じてＦＩＦＯ１０１２からデータのブロックを取り出す。ただし、従来のＤＭＡは、通常、システム・メモリとＩ／Ｏデバイスの間での情報の転送を調整する。この場合、一例では、システム・メモリ１３０とこうしたデータの転送を行うことを回避することが望ましい。この目的で、ＧＰＵモジュール１０１４のコヒーレンシ・モジュール（例えば、図１で示したコヒーレンシ・モジュール１５０）が、ＧＰＵモジュール１０１４にデータをシステム・メモリ１３０からではなく、Ｌ２キャッシュのロックされたセット１０１０から取り出すことを命令する。ＧＰＵモジュール１０１４が、（情報がＬ２キャッシュから「キャスト・アウト」されるようにして）Ｌ２キャッシュのロックされたセット１０１０のＦＩＦＯ１０１２から情報を読取った後、コヒーレンシ・モジュール１５０は、エントリが有効としてマーク付けされ、かつダーティーとしてマーク付けされたまま維持する。この方法では、ＣＰＵ１００２は、キャッシュ・ラインの所有権をシステム・メモリ１３０に渡たすことを許可せずに、この所有権を維持する。換言すれば、この動作は、キャッシュ・ラインの再割り当ての結果ではなく、ＦＩＦＯ１０１２は、ＣＰＵ１００２に割り当てられたままであり、ポインタがラップ・アラウンドしてＦＩＦＯ１０１２のトップを指定した場合に補充（refill）することができる。

図１０で示していないが、ＣＰＵはＬ１キャッシュ１００８およびＬ２キャッシュ１０１０の両方をバイパスして、システム・メモリ１３０に直接書込みストリーミングを行うことができる（これは「非一時的格納（non-temporal store）」動作と呼ばれる）。この動作は、任意選択でデータをより大きいブロックに収集し、次いでデータのこうしたブロックをバス１０６を介してシステム・メモリ１３０に送ることによって行うことができる。この動作は、ＣＰＵによって生成されたデータが（例えばＧＰＵモジュール１０１４によって）直ちに読取られないことが予測される場合に望ましい。この環境では、データがＬ１およびＬ２キャッシュ（１００８、１０１０）に転送された場合、このデータが読取られる前に結局キャッシュからキャスト・アウトされる可能性がかなり高い。さらに、場合によっては、こうしたデータをＬ１およびＬ２キャッシュ（１００８、１０１０）に格納することは、こうしたキャッシュをスラッシングすることになる。こうしたことを考察すれば、Ｌ１およびＬ２キャッシュ（１００８、１０１０）をバイパスして、データをシステム・メモリ１３０に直接ストリーミングすることが妥当である。一例では、ホストＣＰＵのグラフィックス・ドライバ（図示せず）は、この技法を用いて、（「プッシュ・バッファ（push buffer）」としても周知の）ＧＰＵコマンド・リストを生成し、このコマンド・リストをＧＰＵモジュール１０１４に転送することができる。この場合、システム・メモリ１３０に対する書込みストリーミングにより、キャッシュ（１００８、１０１０）のスラッシングを防止することができる。

最後に、上記の論述は、データ・ストリーミングを使用して圧縮解除論理（例えば手続き型ジオメトリまたは高次表面テセレーション）によって生成された大量データをＣＰＵモジュールからＧＰＵモジュールに転送することに重点を置いたものである。ただし、上記の技法を使用して、任意のデータ（すなわち、圧縮解除論理によって生成されたものではないデータ）をＣＰＵモジュールからＧＰＵモジュールに転送することもできる。

Ｂ．３．末尾ポインタの考察
図１０を参照すると、ＧＰＵモジュール１０１４がジオメトリ・データをＬ２キャッシュのロックされたセット１０１０のＦＩＦＯ１０１２から受信した場合、それによってＧＰＵモジュール１０１４は、ＣＰＵ１００２によるＦＩＦＯ１０１２への追加のジオメトリ・データの転送のためにメモリ・スペースを開放する。図１１は、ＧＰＵモジュール１０１４がＣＰＵ１００２にこうした開放スペースを通知する技法を示す。

より具体的には、図１１は、手続き型ジオメトリ論理１１０４（またはジオメトリ・データを生成する他の種類の処理論理）、レジスタ１１０６、およびＬ１キャッシュ１１０８を備えた例示のＣＰＵ１１０２を示す。Ｌ２キャッシュ１１１０ならびにＧＰＵモジュール１１１２もこの図で示す。さらに、図１１は、ＧＰＵモジュール１１１２が、ロックされたセット（図１１で示していない）内のＦＩＦＯに関連付けられた末尾ポインタ１１１４を格納していることも示す。より具体的には、末尾ポインタ１１１４は、ＧＰＵモジュール１０１０が読み取ったばかりのＦＩＦＯ内の格納位置を指し示す。

ＧＰＵモジュール１１１２は、この末尾ポインタをＬ２キャッシュ１１１０に転送することによって、末尾ポインタ１１１４の現在の値をＣＰＵ１１０２に定期的に通知する。図１１で、この動作をパス１１１６で示す。末尾ポインタをＬ２キャッシュ１１１０に格納することにより、Ｌ１キャッシュ１１０８内の対応する末尾ポインタの位置が無効としてマーク付けされる。Ｌ１の位置の無効化は、Ｌ１のデータを、Ｌ２の位置の同じ物理的アドレスに対して加えられた変更に対して、コヒーレントに保持するキャッシュ・コヒーレンシ機能を使用して行われる。その後のＣＰＵ１１０２による末尾ポインタの位置のロードは、例えばＬ２キャッシュ１１１０に格納された、ごく最新の末尾ポインタのバージョンを取り出すことによって応じられる。代替実装形態では、ＧＰＵモジュール１１１２は、読取り待ち時間を短縮する解決法が望まれる場合は、末尾ポインタをＣＰＵ１１０２またはＧＰＵ１１１２に関連付けられた他のいくつかのキャッシュ可能な記憶装置に直接転送することができる。これとは大きく異なり、ＧＰＵモジュール１１１２は、通常のＧＰＵの構成では、システム・メモリと対話するが、それには、Ｌ２キャッシュ１１１０内の末尾ポインタの位置が無効になった後に、再ロードするのにさらに長い待ち時間を要する。割り込みを使用してこのタスクを処理すると、待ち時間の点でさらに問題が生じることになる。

ＣＰＵ１１０２は、Ｌ１キャッシュ１１０８に格納された末尾ポインタを定期的にポーリングして、ＦＩＦＯ（図示せず）に手続き型ジオメトリ論理１１０４によって生成されたジオメトリ・データを受信する十分なスペースがあるか否かを決定する。ＣＰＵ１１０２に関連付けられたローカルメモリのポーリングは、システム・メモリ１３０のポーリングよりもはるかに効率的である。なぜなら、メイン・メモリのポーリングは内部ＣＰＵバス、ＣＰＵ／ＧＰＵバス、ＧＰＵバス、およびメイン・メモリの帯域幅を無駄に使用するからである。ポーリングはＬ１のキャッシュ可能な末尾ポインタの位置でなされるため、ポーリングの帯域幅はすべて、ＣＰＵ１１０２に対してローカルであり、システム内の他の場所の共有リソースを消費せず、システム・メモリに関与する他のポーリング戦略に関連付けられた待ち時間の問題を生じさせない。

Ｂ．４．システムの動作の概要
図１２は、図１で示したシステム１００によって行われる上述のストリーミング動作の概要を示す。図の左側は、ＣＰＵモジュール処理１２０２に関するものであり、すなわち、図１で示したＣＰＵモジュール１０２で行われる動作を示す。より具体的には、ブロック１２０４、１２０６、および１２０８は、ＣＰＵ１１０、ＣＰＵ１１２など、図１で示した個々のＣＰＵで行われる処理に関する。図の右側は、ＧＰＵモジュール処理１２１０に関するものであり、すなわち図１で示したＧＰＵモジュール１０４（かつＧＰＵモジュール１２１２として図１２に再掲した）で行われる動作に関する。ＣＰＵモジュール処理１２０２で行われる動作はＧＰＵモジュール処理１２１０で行われる動作と並列に行うことができる。さらに、（ブロック１２０４、１２０６、１２０８の）個々のＣＰＵで行われる動作は互いに並列に行うことができる。（ストリーミング動作の論述を簡単にするため、図１で示したホストＣＰＵ１０８など、任意のホストＣＰＵの役割を図１２では省略してあることを留意されたい。）

ＣＰＵで行われる例示の動作を、ジオメトリ処理ＣＰＵ１２０４を参照して説明する。こうした動作には、ＣＰＵ１２０４への情報の読取りを行うステップ１２１４が含まれる。この情報は、手続き型ジオメトリ操作（または高次表面テセレーション）を実行するためのＣＰＵ１２０４で使用される比較的少量のデータを構成要素とすることができる。例えば、木をレンダリングする上述の例では、受信情報は木の様々な部分の位置、ならびにレンダリングしたシーンで葉を動かす任意のシミュレートした風の方向および速度に関するデータを構成要素とすることができる。ステップ１２１６は、（圧縮した形で情報を受信した場合は）受信情報を圧縮解除することを行わせる。ステップ１２１８は、受信情報に基づいて手続き型ジオメトリ（または高次表面テセレーション）の実行を行わせる。ステップ１２１８は、１組の出力頂点の生成が行われる。木の例の場合では、頂点は、個々のそれぞれの葉のレンダリングに使用する三角形のメッシュを構成する。さらに、ステップ１２１８で行われる演算は、図８で説明したＡＯＳ手法を用いたドット・プロダクトの実行を含むことができる。ステップ１２２０は、出力頂点を圧縮することを行わせる。ステップ１２２２は、圧縮した頂点をＬ２キャッシュ１２２４のロックされたセットの、ＣＰＵ１２０４に割り当てられた、ＦＩＦＯに転送する。

図１２の右側にあるステップ１２２６で、ＧＰＵモジュール１２１２はＬ２キャッシュ１２２４に格納された頂点を読み取る。ステップ１２２８で、ＧＰＵモジュール１２１２は、ＧＰＵエンジン（例えば図１のエンジン１１４）での頂点処理のために頂点をディスパッチする。最後にステップ１２３０は、ＧＰＵモジュール１２１２が末尾ポインタに関する情報をＣＰＵモジュール１０２のＣＰＵに定期的に転送することを全般的に示す。ＧＰＵモジュール１２１２は、こうして受信した頂点を末尾ライトバック更新と並列に処理することができる。上述のように、この末尾ポインタは、ＧＰＵモジュール１２１２のＬ２キャッシュ１２２４に格納された情報の読取りがどの程度進行したかを示し、新規の頂点データで充填することができるＬ２キャッシュ１２２４内の使用可能な解放スペースを、ＣＰＵに通知する。

セクションＢでの上記の論述では、データをキャッシュ・メモリからＧＰＵモジュール１０４に転送する例示の技法を１つしか示していないが、他の技法を用いることもできる。例えば、上記の論述では、コヒーレンシ・モジュール１５０は、複製タグ格納方式（duplicate tag store scheme）を使用してストリーミング動作でデータの転送を調整する役割を担う。他の戦略では、システム１００は、Ｌ２キャッシュ１２２のロックされたセット５０２のＦＩＦＯ（５０６〜５１２）に別個のアドレス範囲を割り当てることができ、こうしたアドレスはシステム・メモリ１３０にマップされない。この手法では、システム１００は、情報がＬ２キャッシュ１２２のロックされたセット５０２に格納されたことを、複製タグ記憶装置を調査して決定する必要がない。したがってこの手法では、コヒーレンシ・モジュール１３０は、ストリーミング書込みＦＩＦＯ（５０６〜５１２）に格納されたデータ以外のデータすべてに関して、ＣＰＵモジュール１０２のキャッシュとシステム・メモリ１３０の間のコヒーレンシを維持するためだけに使用される。

Ｃ．ゲーム環境への例示の適用例
図１３は、上述の並列アーキテクチャおよび技法を実装するために使用することができる例示のゲーム・システム１３００を示す。このシステムは、ゲーム・コンソール１３０２、およびコントローラ１３０４（１）および１３０４（２）で示した４つまでのコントローラを備える。ゲーム・コンソール１３０２は、内部ハードディスクドライブおよび携帯用媒体ドライブ１３０６を装備している。この携帯用媒体ドライブ１３０６は、光記憶ディスク１３０８で示したような、様々な形態の携帯用記憶媒体をサポートする。適合する携帯用記憶媒体の例には、ＤＶＤ、ＣＤ−ＲＯＭ、ゲーム・ディスク、ゲーム・カートリッジなどが含まれる。

ゲーム・コンソール１３０２は、その前面に４つのスロット１３１０を有して、４つまでのコントローラを支持するが、スロットの数および構成は変更することができる。電源ボタン１３１２および排出ボタン１３１４もゲーム・コンソール１３０２の前面に位置する。電源ボタン１３１２は、ゲーム・コンソールへの電力の切替えをし、排出ボタン１３１４は携帯用媒体ドライブ１３０６のトレイを開閉して、記憶ディスク１３０８を挿入し、取り出すことができるようにする。

ゲーム・コンソール１３０２は、Ａ／Ｖインターフェース・ケーブル１３２０を介してテレビジョンまたは他のディスプレイ（図示せず）に接続される。電源ケーブル１３２２は、ゲーム・コンソールに電力を供給する。ゲーム・コンソール１３０２はさらに、ケーブルまたはモデム・コネクタ１３２４で示したように、内部または外部の追加のネットワーク能力を装備して、ローカル・エリア・ネットワーク（ＬＡＮ）またはインターネットなど、ネットワークにアクセスしやすくなっている。

各コントローラ１３０４は、有線または無線インターフェースを介してゲーム・コンソール１３０２に結合される。図で示した実装形態では、コントローラはＵＳＢ（Universal Serial Bus）コンパチブルであり、シリアル・ケーブル１３３０を介してゲーム・コンソール１３０２に接続される。コントローラ１３０４は、多様なユーザ対話機構の任意のものを装備することができる。図１３で示したように、各コントローラ１３０４は、２つの基本コントロール・レバー（thumbstick）１３３２（１）および１３３２（２）、方向性またはＤ−パッド１３３４、表面ボタン１３３６、および２つのトリガ１３３８を装備している。こうした機構は単に代表的なものであり、他の周知のゲーム機構を図１３で示したものに代え、または追加することができる。

メモリ・ユニット（ＭＵ）１３４０をコントローラ１３０４に挿入して追加の携帯用記憶装置を提供することができる。携帯用メモリ・ユニットは、ユーザがゲーム・パラメータを格納し、それを輸送して他のコンソールでプレイできるようにする。記載の実装形態では、各コントローラは、２つのメモリ・ユニット１３４０を収容するように構成されているが、他の実装形態では２つより多い、または少ないユニットを使用することができる。

図で示していないが、ゲーム・システム１３００は、図１で示したシステム１００に対応する処理アーキテクチャを含むことができる。こうしたシステム１００によって、高度の複雑性があり、それによって比較的高度の現実性のある実現可能なシーンを生成することができるようになる。これは、プレーヤのゲームに対する興味に加えて、実体験のように感じるゲーム環境を作り出す助けをする。

Ｄ．結論
データ生成タスクを並列に実行するアーキテクチャおよび関連方法を開示した。例示の一適用例では、このアーキテクチャおよび関連方法は、複雑で現実性のあるシーンをレンダリングする大量のジオメトリ・データを提供するものである。同時に、このアーキテクチャおよび関連方法は、システム・メモリのデータ転送動作の量を低減する方法も提供する。

本発明を、構成機能および／または方法のアクト（methodological acts）に特有の言語で記載したが、理解されるように、特許請求の範囲で定義した本発明は、記載の特定の特徴および活動に必ずしも限定されるものではない。むしろ、特定の特徴および活動は、特許請求の範囲に記載されている本発明の例示の実装形態として開示したものである。

複数のコンピュータ処理装置を備えた例示のシステムの概要を示す図である。 図１で示したコンピュータ処理装置におけるマルチスレッド化の例示の使用を示す図である。 有益な圧縮解除比率を達成するための、図１のコンピュータ処理装置での手続き型ジオメトリの効果を示す図である。 図１のシステムで使用されるｎ−ウェイ・セット・アソシアティブＬ２キャッシュの例示の構成を示す図である。 １組のｎ−ウェイ・セット・アソシアティブのキャッシュがロックされた、ストリーミング書込み動作モードのための、図４で示したＬ２キャッシュの例示の構成を示す図である。 図１で示したコンピュータ処理装置モジュールの例示の代替実装形態を示す図である。 図１で示したコンピュータ処理装置によって提供される、ジオメトリ・データを圧縮してジオメトリ処理装置モジュールに出力する例示の論理を示す図である。 図１で示したコンピュータ処理装置によって提供される、ドット生成操作を行う例示の論理を示す図である。 ストリーミング動作モードでコンピュータ処理装置に情報を読み取る例示の技法を示す図である。 ストリーミング書込み動作モードでコンピュータ処理装置からグラフィックス処理装置モジュールに情報を書き込む例示の技法を示す図である。 グラフィックス処理装置モジュールからコンピュータ処理装置モジュールに末尾ポインタを書き込む例示の技法を示す図である。 図１のシステムで行う例示の処理操作の概要を示す図である。 本明細書に記載のアーキテクチャおよび技法を実装することができるゲーム・コンソールおよび１つまたは複数のコントローラを有する例示のゲーム・システムを示す図である。

符号の説明

１００ システム
１０２ ＣＰＵモジュール
１０４ ＧＰＵモジュール
１０６ フロント・サイド・バス
１０８ ＣＰＵ１（例えばホスト）
１１０ ＣＰＵ２（例えばジオメトリ）
１１２ ＣＰＵｎ（例えばジオメトリ）
１１４ グラフィックス・エンジン
１１６、１１８，１２０ Ｌ１キャッシュ
１２４、１２６，１２８ バス・インタフェース・ユニット
１２２ 共有Ｌ２
１３０ メモリ
１３２ メモリ・コントローラ
１３４ クロスバー
１３６ Ｉ／Ｏモジュール
１３８ Ｉ／Ｏインターフェース
１４０ 追加の１つまたは複数のＣＰＵモジュール（任意選択）
１４２ 対称型多重処理（Symmetric Multiprocessing（ＳＭＰ））インターフェース
１４４ ＧＰＵインターフェース
１４６ ＣＰＵインターフェース
１４８ クロスバー
１５０ コヒーレンシ・モジュール
２００ ＣＰＵ内の処理リソースを複数のスレッドに割り当てる構成
２０２ スレッド１（例えばホスト）
２０４ スレッド２（例えばホスト）
２０５ 任意選択の追加のスレッド
２０６ スレッド１（例えばジオメトリ）
２０８ スレッド２（例えばジオメトリ）
２０９ 任意選択の追加のスレッド
２１０ スレッド１（例えばジオメトリ）
２１２ スレッド２（例えばジオメトリ）
２１３ 任意選択の追加のスレッド
２１４、２１６，２１８、２２０、２２２、２２４ Ｌ１キャッシュ
２２６ 両方のスレッド用の１つのＬ１
３０２ データ生成論理（例えば手続き型ジオメトリ）
３０４ データ生成論理（例えば手続き型ジオメトリ）
４１０ 有効性
４１２ タグ
４１４ データ
４１６ アドレス
４１８ 指標
４２０ 特定のキャッシュ・ライン
４２２ タグ
５０２ ロックされたセット
５０４ アンロック・セット
５０６、５０８、５１０、５１２ ＦＩＦＯバッファ
５１４ アドレス
５１６、５１８ 「無視」ビット・フィールド
６０２ ＣＰＵ処理モジュール
６０４ 専用Ｌ２キャッシュ
９０２ ＣＰＵ
９０４ 手続き型ジオメトリ論理
９０６ レジスタ
９０８ Ｌ１キャッシュ
９１０ Ｌ２キャシュ
９１２ バス
１０００ 書込みストリーミング動作
１００２ ＣＰＵ
１００４ 手続き型ジオメトリ論理
１００６ レジスタ
１００８ Ｌ１キャッシュ
１０１０ Ｌ２のロックされたセット
１０１２ ＦＩＦＯ
１０１４ ＧＰＵモジュール
１１０２ ＣＰＵ
１１０４ 手続き型ジオメトリ論理
１１０６ レジスタ
１１１０ Ｌ２キャッシュ
１１１２ ＧＰＵモジュール
１１１４ 末尾ポインタ
１３００ ゲーム・システム
１３０２ ゲーム・コンソール
１３０４ コントローラ
１３０６ 携帯用媒体ドライブ
１３０８ 光記憶ディスク
１３１０ スロット
１３１２ 電源ボタン
１３１４ 排出ボタン
１３２０ Ａ／Ｖインターフェース・ケーブル
１３２２ 電源ケーブル
１３２４ モデム・コネクタ
１３３０ シリアル・ケーブル
１３３２ コントロール・レバー
１３３４ Ｄ−パッド
１３３６ 表面ボタン
１３３８ トリガ釦

Claims (57)

1. （ａ）システム・メモリと、
   （ｂ）コンピュータ処理モジュールであって、
   （ｂ１）タスクを実行するように構成されたホスト処理要素、
   （ｂ２）前記タスク内のサブタスクを実行するように構成されたデータ生成処理要素であって、
   入力データを受信するように構成された論理、および、
   前記入力データを処理して出力データを生成するように構成された論理
   を含み、出力データ量は入力データ量よりも多く、前記入力データ量の前記出力データ量に対する比は圧縮解除の比率を規定し、
   前記データ生成処理要素によって生成された前記出力データは前記データ生成処理要素によって生成される前には前記システム・メモリに収容されないように構成されたデータ生成処理要素、
   （ｂ３）前記データ生成処理要素に結合され、前記出力データを受信するキャッシュ・メモリ、および、
   （ｂ４）前記出力データを前記キャッシュ・メモリから出力するコンピュータ処理モジュール・インターフェース
   を含むコンピュータ処理モジュールと、
   （ｃ）通信バスと、
   （ｄ）データ処理モジュールであって、
   前記通信バスを介して前記コンピュータ処理モジュール・インターフェースに結合されて前記出力データを受信するデータ処理モジュール・インターフェース、および、
   前記出力データを前記キャッシュ・メモリから受信し処理し、末尾ポインタを使用してデータを取り出したばかりの前記キャッシュ・メモリ内の位置を示すデータ処理エンジン
   を含むデータ処理モジュールと
   を備えたシステムであって、
   前記コンピュータ処理モジュールは、書込みストリーミング動作モード時に、前記データ生成処理要素からストリーミング書込み出力データを受信する目的で前記キャッシュ・メモリの一部を割り当てるように構成され、
   前記システムは、前記書込みストリーミング動作モード時に、出力データを、前記システム・メモリからではなく、前記割り当てられた前記キャッシュ・メモリの一部から前記データ処理モジュールに転送するように構成され、
   前記データ処理モジュールは、前記末尾ポインタを前記データ生成処理要素のキャッシュ可能なアドレスに転送し、前記末尾ポインタは、前記データ処理モジュールがデータを取り出したばかりの前記キャッシュ・メモリ内の前記位置を前記データ生成処理要素に通知するように構成される
   ことを特徴とするシステム。
2. 前記ホスト処理要素は、コンピュータ処理装置に実装されたスレッドを備え、前記データ生成処理要素は前記同じコンピュータ処理装置に実装された、または別のコンピュータ処理装置に実装されたスレッドを備えることを特徴とする請求項１に記載のシステム。
3. 複数のホスト処理要素をさらに備えることを特徴とする請求項１に記載のシステム
4. 前記複数のホスト処理要素は、それぞれ少なくとも１つのコンピュータ処理装置に実装された複数のスレッドを備えることを特徴とする請求項３に記載のシステム。
5. 複数のデータ生成処理要素をさらに備えることを特徴とする請求項１に記載のシステム。
6. 前記複数のデータ生成処理要素は、それぞれ少なくとも１つのコンピュータ処理装置に実装された複数のスレッドを備えることを特徴とする請求項５に記載のシステム。
7. 前記ホスト処理要素および前記データ生成処理要素は、それぞれ静的に割り当てられた機能を実行することを特徴とする請求項１に記載のシステム。
8. 前記ホスト処理要素および前記データ生成処理要素は、それぞれ動的に割り当てられた機能を実行することを特徴とする請求項１に記載のシステム。
9. 複数のデータ生成処理要素をさらに備え、前記複数のデータ生成処理要素はそれぞれ前記キャッシュ・メモリに結合されることを特徴とする請求項１に記載のシステム。
10. 前記データ生成処理要素はＬ１キャッシュを含み、前記コンピュータ処理モジュールの前記キャッシュ・メモリはＬ２キャッシュであることを特徴とする請求項１に記載のシステム。
11. 前記コンピュータ処理モジュールは、読取りストリーミング動作モード時に、前記データ生成処理要素の前記Ｌ１キャッシュに、前記Ｌ２キャッシュをバイパスして前記入力データを転送することによって、前記入力データを提供するように構成されることを特徴とする請求項１０に記載のシステム。
12. 前記コンピュータ処理モジュールは、前記書込みストリーミング動作モード時に、前記出力データを、前記Ｌ１キャッシュをバイパスして前記Ｌ２キャッシュに転送するように構成されることを特徴とする請求項１０に記載のシステム。
13. 前記キャッシュ・メモリは、ｎ−ウェイ・セット・アソシアティブ・キャッシュであり、前記部分は、前記ｎ−ウェイ・セット・アソシアティブ・キャッシュの少なくとも１つのセットをロックすることによって割り当てられることを特徴とする請求項１に記載のシステム。
14. 前記キャッシュ・メモリの前記割り当てられた部分は、前記データ生成処理要素を前記データ処理モジュールに結合する少なくとも１つのＦＩＦＯバッファを形成することを特徴とする請求項１に記載のシステム。
15. 前記システムは、アドレスの上部セクションおよび下部セクションを無視し、アドレスの中間セクションを使用して前記少なくとも１つのＦＩＦＯバッファ内にラップして、前記少なくとも１つのＦＩＦＯバッファを示すように構成されることを特徴とする請求項１４に記載のシステム。
16. 前記データ処理モジュールは、変更したダイレクト・メモリ・アクセス（ＤＭＡ）プロトコルを使用して、前記キャッシュ・メモリから受信した出力データを処理するように構成されることを特徴とする請求項１に記載のシステム。
17. 前記コンピュータ処理モジュールは、キャッシュ・ラインにアクセスした後、キャッシュ・ラインをダーティー状態に維持するように構成されることを特徴とする請求項１に記載のシステム。
18. 前記圧縮解除比率は少なくとも１対１０であることを特徴とする請求項１に記載のシステム。
19. 前記圧縮解除比率は少なくとも１対１００であることを特徴とする請求項１に記載のシステム。
20. 前記圧縮解除比率は少なくとも１対１０００であることを特徴とする請求項１に記載のシステム。
21. 前記データ生成処理要素は、少なくとも１つの判定基準に応じてその動作中に圧縮解除の比率を動的に変えるように構成されることを特徴とする請求項１に記載のシステム。
22. 前記少なくとも１つの判定基準はシーン内のオブジェクトに関連付けられたシーンの深度であることを特徴とする請求項２１に記載のシステム。
23. 前記入力データを処理する前記論理は、ドット生成命令を受信すると、ＡＯＳ計算技法を使用して、ドット生成操作を行うように構成された論理をさらに備えることを特徴とする請求項１に記載のシステム。
24. 前記入力データを処理する前記論理は、データを第１の情報内容量から第２の情報内容量に圧縮して前記出力データを提供する論理をさらに含み、前記第１の情報内容量は前記第２の情報内容量よりも多いことを特徴とする請求項１に記載のシステム。
25. 前記ホスト処理要素によって実行される前記タスクは、グラフィックス処理タスクに関連し、前記データ生成処理要素によって実行されるサブタスクはジオメトリ・データの前記生成に関連することを特徴とする請求項１に記載のシステム。
26. 前記ホスト処理要素によって実行される前記タスクは、３次元ゲーム・アプリケーションの高レベルの態様（aspect）に関連することを特徴とする請求項２５に記載のシステム。
27. 前記入力データを処理する前記論理は、前記入力データを前記出力データに変換するように構成された手続き型ジオメトリ論理を備え、前記出力データは１組の頂点を備えることを特徴とする請求項２５に記載のシステム。
28. 前記入力データを処理する前記論理は、高次表面で表された情報を１組の頂点を備える出力データに変換するように構成された高次表面テセレーション・エンジンを備えることを特徴とする請求項２５に記載のシステム。
29. （ａ）システム・メモリと、
    （ｂ）タスクを実行するように構成されたホスト処理要素と、
    （ｃ）前記タスク内のサブタスクを実行するように構成されたデータ生成処理要素であって、
    入力データを受信するように構成された論理、および
    前記入力データを処理して出力データを生成するように構成された論理
    を含み、出力データ量は入力データ量よりも多く、入力データ量の出力データ量に対する比は圧縮解除の比率を規定し、前記データ生成処理要素によって生成された前記出力データは前記データ生成処理要素によって生成される前にはシステム・メモリに収容されないように構成されたデータ生成処理要素と、
    （ｄ）前記データ生成処理要素によって生成された前記出力データをキャッシュ・メモリの割り当てられた部分に格納するキャッシュ・メモリと、
    （ｅ）通信バスと、
    （ｆ）前記通信バスを介して前記出力データを前記キャッシュ・メモリから取り出し、前記出力データを処理するように構成され、末尾ポインタを使用してデータを取り出したばかりの前記キャッシュ・メモリ内の位置を示すデータ処理エンジンと、
    （ｇ）末尾ポインタを提供して、前記通信バスを介して前記データ生成処理要素のキャッシュ可能なアドレスを更新するように構成された末尾ポインタ更新機構と
    を備えることを特徴とするシステム。
30. ホスト処理要素、データ生成要素、およびデータ処理エンジンを含み、前記ホスト処理要素および前記データ生成要素が通信バスを介して前記データ処理エンジンに結合されているシステムにおいてデータを処理する方法であって、
    （ａ）前記ホスト処理要素内で、タスクの一部としてサブタスクの実行を要求するタスクを実行すること、
    （ｂ）前記ホスト処理要素によって指令された場合に、前記データ生成処理要素内で前記サブタスクを実行することであって、入力データを受信すること、および前記入力データを処理して出力データを生成することを含むサブタスクを実行し、出力データ量は入力データ量よりも多く、前記入力データ量の前記出力データ量に対する比は圧縮解除の比率を規定し、前記データ生成処理要素によって生成された前記出力データは、前記データ生成処理要素によって生成される前にはシステム・メモリに収容されないようにサブタスクを実行すること、
    （ｃ）前記出力データをキャッシュ・メモリの割り当てられた部分でバッファリングすること、
    （ｄ）データ処理エンジンによって、前記出力データを、前記システム・メモリではなく前記キャッシュ・メモリから前記通信バスを介して取り出すこと、
    （ｅ）前記取り出した出力データを前記データ処理エンジンで処理し、前記データ処理エンジンは末尾ポインタを使用してデータを取り出したばかりの前記キャッシュ・メモリ内の位置を示すこと、および
    （ｆ）末尾ポインタを前記データ生成処理要素のキャッシュ可能なアドレスに転送し、前記末尾ポインタは、前記データ生成処理要素に、前記データ処理エンジンがデータを取り出したばかりの前記キャッシュ・メモリ内の位置を通知すること
    を備えることを特徴とする方法。
31. 前記ホスト処理要素は、コンピュータ処理装置に実装されたスレッドを備え、前記データ生成処理要素は前記同じコンピュータ処理装置に実装された、または別のコンピュータ処理装置に実装されたスレッドを備えることを特徴とする請求項３０に記載の方法。
32. 複数のホスト処理要素をさらに備えることを特徴とする請求項３０に記載の方法。
33. 前記複数のホスト処理要素は、それぞれ少なくとも１つのコンピュータ処理装置に実装された複数のスレッドを備えることを特徴とする請求項３２に記載の方法。
34. 複数のデータ生成処理要素をさらに備えることを特徴とする請求項３０に記載の方法。
35. 前記複数のデータ生成処理要素は、それぞれ少なくとも１つのコンピュータ処理装置に実装された複数のスレッドを備えることを特徴とする請求項３４に記載の方法。
36. 前記ホスト処理要素および前記データ生成処理要素は、それぞれ静的に割り当てられた機能を実行することを特徴とする請求項３０に記載の方法。
37. 前記ホスト処理要素および前記データ生成処理要素は、それぞれ動的に割り当てられた機能を実行することを特徴とする請求項３０に記載の方法。
38. 複数のデータ生成処理要素をさらに備え、当該複数のデータ生成処理要素はそれぞれ前記キャッシュ・メモリに結合されることを特徴とする請求項３０に記載の方法。
39. 前記データ生成処理要素はＬ１キャッシュを含み、前記キャッシュ・メモリはＬ２キャッシュであることを特徴とする請求項３０に記載の方法。
40. 前記データ生成処理要素は、読取りストリーミング動作モード時に、前記Ｌ２キャッシュをバイパスした、前記データ生成処理要素の前記Ｌ１キャッシュへの前記入力データの転送によって前記入力データを受信することを特徴とする請求項３９に記載の方法。
41. 前記データ生成ユニットは、書込みストリーミング動作モード時に、前記出力データを前記Ｌ２キャッシュに、前記Ｌ１キャッシュをバイパスして転送することによって前記出力データを提供することを特徴とする請求項３９に記載の方法。
42. 前記キャッシュ・メモリは、ｎ−ウェイ・セット・アソシアティブ・キャッシュであり、前記部分は、前記ｎ−ウェイ・セット・アソシアティブ・キャッシュの少なくとも１つのセットをロックすることによって割り当てられることを特徴とする請求項３０に記載の方法。
43. 前記キャッシュ・メモリの前記割り当てられた部分は、前記データ生成処理要素を前記データ処理エンジンに結合する少なくとも１つのＦＩＦＯバッファを形成することを特徴とする請求項３０に記載の方法。
44. アドレスの上部セクションおよび下部セクションを無視し、アドレスの中間セクションを使用して前記少なくとも１つのＦＩＦＯバッファ内にラップして、前記少なくとも１つのＦＩＦＯバッファを示すことをさらに備えることを特徴とする請求項４３に記載の方法。
45. 前記データ処理エンジンは、変更したダイレクト・メモリ・アクセス（ＤＭＡ）プロトコルを使用して、前記キャッシュ・メモリから受信した出力データを処理することを特徴とする請求項３０に記載の方法。
46. キャッシュ・ラインにアクセスした後、キャッシュ・ラインをダーティー状態に維持することをさらに備えることを特徴とする請求項３０に記載の方法。
47. 前記圧縮解除比率は少なくとも１対１０であることを特徴とする請求項３０に記載の方法。
48. 前記圧縮解除比率は少なくとも１対１００であることを特徴とする請求項３０に記載の方法。
49. 前記圧縮解除比率は少なくとも１対１０００であることを特徴とする請求項３０に記載の方法。
50. 前記サブタスクを前記実行することは、少なくとも１つの判定基準に応じて前記データ生成処理要素の動作中に圧縮解除の前記比率を動的に変えることを含むことを特徴とする請求項３０に記載の方法。
51. 前記少なくとも１つの判定基準はシーン内のオブジェクトに関連付けられたシーンの深度であることを特徴とする請求項５０に記載の方法。
52. 前記サブタスクを前記実行することは、ドット生成命令を受信すると、ＡＯＳ計算技法を使用して、ドット生成操作を行うことをさらに含むことを特徴とする請求項３０に記載の方法。
53. 前記サブタスクを前記実行することは、データを第１の情報内容量から第２の情報内容量に圧縮して前記出力データを提供することをさらに含み、前記第１の情報内容量は前記第２の情報内容量よりも多いことを特徴とする請求項３０に記載の方法。
54. 前記ホスト処理要素によって実行される前記タスクは、グラフィックス処理タスクに関連し、前記データ生成処理要素によって実行される前記サブタスクはジオメトリ・データの前記生成に関連することを特徴とする請求項３０に記載の方法。
55. 前記ホスト処理要素によって実行される前記タスクは、３次元ゲーム・アプリケーションの高レベルの態様（aspect）に関連することを特徴とする請求項５４に記載の方法。
56. 前記入力データを前記処理することは、手続き型ジオメトリを行って前記入力データを前記出力データに変換することを備え、前記出力データは１組の頂点を備えることを特徴とする請求項５４に記載の方法。
57. 前記入力データを前記処理することは、高次表面テセレーションを行って、高次表面で表された情報を１組の頂点を備える出力データに変換することを備えることを特徴とする請求項５４に記載の方法。
    

Images