JP2009543195A - グラフィックスパイプラインステートの高速再構成 - Google Patents

Abstract

【解決手段】
グラフィックスパイプラインにおいて、シェーダに関連付けられる特定のスロットにリソースを結合するための技法及び技術を提供する。各シェーダによって利用されているリソース間のリソース依存関係が決定され得、これらのリソース依存関係に基づいてコモンリソース／スロット関連付けが、計算され得る。コモンリソース／スロット関連付けそれぞれは、特定のスロットの１つに関連付けられる特定のリソース１つを指定する。
【選択図】図６

Description

３次元（３−Ｄ）グラフィックスを画面上にレンダリングし、表示することは、通常、多くの演算及び計算を伴う。単純なグラフィックスシステムにおいては、そのような計算は、いくつかのレベルの協調的又は共有のプロセスに従って中央処理ユニット（ＣＰＵ）及びグラフィックスプロセッシングユニット（ＧＰＵ）によって発生する。例示的なシナリオにおいては、命令が処理され、いくつかの初期計算がＣＰＵにおいて発生した後、レンダリングされるオブジェクトを定義するコーディネートポイント又はバーテックス（頂点：vertex）のセットが、グラフィックスパイプラインにおけるＧＰＵによる更なる処理のためにビデオメモリにストアされる。グラフィックスプログラマが、有効なグラフィックスＡＰＩセットを介しグラフィックスアプリケーションを開発するとき、プログラマは、一般にアルゴリズムエレメントセットによって操作されるバーテックスセットを指し示す。このデータは、グラフィックスパイプラインに送信され、各バーテックスは、グラフィックスパイプライン中の固定のＧＰＵサブユニットセットを介しストリーミングされる。これらのサブユニットの１つは、テッセレータ（tesselator）と呼ばれ、表示されるオブジェクトの表面を効率的にカバーするように設計された所定のアルゴリズムに従って、グラフィックスデータを単純なポリゴンに分解する。その後、時としてシェーダ又は「シェーダプログラム」として参照される１つ以上のプログラム可能なシェーダユニットは、データに作用し得、グラフィックスデータに対して特化された操作を実行し得る。シェーダは、例えばバーテックスシェーダ（単数又は複数）、ジオメトリシェーダ（単数又は複数）及びピクセルシェーダ（単数又は複数）を含み得る。

単一のシェーダは、異なる組み合わせのシェーダ定数を受信でき、提供される特定の組み合わせのシェーダ定数に従って、シェーダによって生成される出力が異なる。これらのシェーダ定数は、例えばピクセルがどのように結合されるか、データがどのように読み込まれ読み出されるか、テクスチャの場合は、そのテクスチャからどのような値が抽出されるかを指定し得る。シェーディングプロセスは、計算に集中する複雑な処理である。これらの特定のシェーダが、グラフィックスパイプラインにおいて作動するとき、各ステージにおいて発生する動作による日常的なボトルネックがある。

「ステート」は、シェーダプログラムによって解釈されるリソースを参照している。どのような実例においても、グラフィックスパイプラインは、（レンダリングステート、シェーダ（複数）、シェーダ可変定数（複数）、リソース／メモリ結合（複数）などの）大量の動的ステートを含む。ステートの異なる組み合わせが、様々な構成要素のシミュレート及び視覚効果を可能にする。

このステートの一つの要素は、シェーダプログラムを実行する前にＧＰＵに結合される必要があるシェーダ定数セットである。どのような実例においても、グラフィックスパイプラインを実装するために使用されるハードウェアは、１つだけの構成において存在し得るために、ステート（例えばシェーダ定数）を設定し、ＧＰＵにコマンドを発行することに消費される時間を低減することが望まれる。

シェーダの中にはシェーダ定数の分類又は集合を保持する（定数レジスタと対照的なものとして）定数バッファを利用するものもある。シェーダ定数の集合が分類されるために、定数バッファは、シェーダ定数をＧＰＵにより高速に設定可能にし得る。これらの進歩にも関わらず、余分な評価及びデバイスステート変更を回避するために、ステートを効率的に管理することが望まれる。例えばＧＰＵにステートをより効率的に設定するために、異なるシェーダにおいて使用される定数バッファ（又は他のリソース）を効率的に設定する技法を提供することが望まれる。

複数のリソースを含む依存ツリーを再構成するための技法を提供する。依存ツリーは、異なるシェーダリソース間の関係又は依存関係の経過を保持する。特定のリソースそれぞれは、依存ツリーにおける親オブジェクトのスロットに結合される。これらの技法に従って依存ツリー内の依存関係それぞれが走査され、依存ツリーの異なる再構成（シェーダの再配置又は再構築）それぞれに関連するコストが算出される。依存ツリーの再構成それぞれは、一定のリソース（ＣＢ（複数））が結合されている特定のスロットを変更する。依存ツリーの特定の再構成は次に、より上位レベルのステート間を遷移するために、デバイス再構成の数を低減又は最小化するように選択できる。言い換えれば、現在ロードされたシェーダ間の移行／切り換えのために再結合される必要があるスロット数を最小化する依存ツリーの特定の再構成が次に、選択され得る。一実装においては、これらの技法は、オフラインコンテンツの生成及び保存のために実行され得、（例えばシェーダのセットが事前に知られている場合、シェーダが分析され、依存関係が再配置され、次に、シェーダがディスクに戻って保存される）。代替の実装においては、本方法は、（例えばシェーダのセットが事前に知られていない場合）アプリケーションの実行時／ロード時に動的に実行される。

「発明を実施するための最良の形態」に更に後述される概念から選択を簡易化された形式で紹介するためにこの概要を提供する。この概要が、請求項記載対象の重要な特徴又は本質的な特徴を特定することを意図せず、請求項記載対象の範囲を決定する際に使用されることも意図しない。

更に添付図面を参照し、グラフィックスパイプライン性能の最適化における使用のためのシステム及び方法を説明する。
以下の詳細説明は、実際には単に例示的であって、本発明又はアプリケーション及び本発明の用途を限定する意図はない。本明細書において、語句「例示的」は、「例、実例又は図示として提供すること」を意味する。本明細書に「例示的である」として記述された任意の実装は、他の実装に比較して必ずしも好ましいか又は有利であると理解される必要はない。後述する実装のすべては、当業者が本発明を作成又は使用可能にするために提供される例示的な実装であって、請求項によって定義される発明の範囲を限定する意図はない。更に、以前の背景、簡潔な概要又は以下の詳細な説明において提示された任意の表現又は暗示された理論によって拘束される意図は全くない。
用語
本明細書において、用語「シェーダ」は、一般にシェーディングを実行するＧＰＵのハードウェアサブユニットを参照するか又はシェーディングを実行するためのシェーダ（ハードウェア）によって使用されるメモリ例えばレジスタ記憶装置に次にロードされる、ＧＰＵにダウンロードされる命令セット又はトークンを参照するために使用され得る。用語「シェーダ」は、動作する双方を一緒に参照することもできる。また用語「サブユニット」が用語「シェーダ」に関連しても使用され、用語「シェーダ」は、シェーディングに関連するプロセスを実行するＧＰＵのサブユニットについて参照するように解釈されたい。用語「シェーダプログラム」は、一般にグラフィックスパイプラインに存在し実行するプログラム又はプロセスを参照し得、画面上の最終的な画像の表面特性又は３次元画面環境におけるオブジェクトの決定／定義を支援するために使用される。「シェーダ」は、それらの特定のタスクを実行するために毎秒何十億の計算を実行可能である。

本明細書において、用語「リソース」は、シェーダプログラムによって使用される入力を参照し、例えばシェーダプログラムによって使用されるテクスチャ、サンプラー、定数バッファ又は他の任意のリソースも包含し得る。

本明細書において、用語「シェーダ定数」は、シェーダプログラムが、使用される特定のシェーダ定数に基づいて異なる結果の生成を可能にするシェーダプログラムに与えられる異なるパラメタ又は変数を参照し得る。シェーダプログラムは、シェーダ定数それぞれのための様々な異なる値を受信し得る。シェーダ可変定数（constant variables）は、そのシェーダ呼び出しの間、値を変更しない。
概要
実行時のシェーダ定数の使用パターンを追跡し、次にシェーダ定数の使用形態に関連するデータの使用パターンを生成するための技法を提供する。この使用パターンのデータは次に、一定の経験則を所与として最大性能のために、データを効率的に割り付けるための最適化アルゴリズムに与えられ得る。考慮される要因は、例えば値のクライアント更新周期、一定のシェーダによる用法、結果バッファのサイズ及び数を含む。
例示的ネットワーク分散環境
当業者は、本発明が任意の計算機又は他のクライアント又はサーバ装置と接続し実装され得、計算機ネットワークの一部として又は分散計算環境において、使用され得ることを理解されよう。この点において、本発明は、様々なメモリ又は記憶装置を有する計算機システム又は環境と、様々な記憶ユニット又はボリュームに渡って発生する様々なアプリケーション及びプロセスと、に関連し本発明による任意のグラフィックスパイプラインの非限定的な実装のためのプロセスに関連し使用され得る。本発明は、リモート又はローカル記憶装置を有するネットワーク環境又は分散計算環境において配備されるサーバ計算機及びクライアント計算機を用いた環境に適用できる。また本発明は、プログラム言語機能性、インタプリタ及びリモート又はローカルサービスと接続して情報を生成し、受信し、送信するための実行能力を有する単独で動作する計算装置に適用され得る。ゲーム環境においては、グラフィックスパイプラインは、特にネットワーク化された又は分散化された計算環境において作動する計算装置に関連し、従って本発明によるグラフィックスパイプライン技法は、それらの環境において多くの効力を適用できる。

分散計算は、計算装置及びシステム間の交換によって、計算機リソース及びサービス共有を提供する。これらのリソース及びサービスは、情報の交換、キャッシュ記憶装置及びファイル用のディスク記憶装置を含む。分散計算は、ネットワークの接続性を利用し、クライアントが、企業全体のためになるクライアントの集合的な力を活用可能にする。この点においては、様々な装置は、本発明のグラフィックスパイプラインプロセスに関係していると見なされ得るアプリケーション、オブジェクト又はリソースを有し得る。

図１は、例示的なネットワーク化された又は分散された計算環境の概念図を提供する。分散計算環境は、計算オブジェクト（１０ａ）、（１０ｂ）その他及び計算オブジェクト又は装置（１１０ａ）、（１１０ｂ）、（１１０ｃ）その他を含む。これらのオブジェクトは、プログラム、方法、データストア、プログラム可能なロジックなどを含み得る。オブジェクトは、ＰＤＡ、音声／映像装置、ＭＰ３プレーヤ、パーソナル計算機その他などの同一か又は異なる装置の一部を含み得る。各オブジェクトは、通信ネットワーク（１４）を介し別のオブジェクトと通信できる。このネットワークは、図２Ａのシステムにサービスを提供する他の計算オブジェクト及び計算装置を含み得、複数の相互接続ネットワークを表し得る。本発明の特徴に従ってオブジェクト（１０ａ）（１０ｂ）その他又は（１１０ａ）、（１１０ｂ）、（１１０ｃ）その他それぞれが、本発明によるグラフィックスパイプラインプロセスの使用をリクエストするためのＡＰＩ、他のオブジェクト、ソフトウェア、ファームウェア及び／又はハードウェアを利用し得るアプリケーションを含み得る。

また（１１０ｃ）などのオブジェクトが、別の計算装置（１０ａ）、（１０ｂ）その他又は（１１０ａ）、（１１０ｂ）その他においてホスティングされ得ることも十分理解され得る。こうして表現された物理的な環境は、計算機などの接続装置を示し得るが、そのような図は単に例示的であって、物理的環境は、ＰＤＡ、テレビ、ＭＰ３プレーヤその他のような様々なデジタル装置、インタフェース、ＣＯＭオブジェクトやその他のようなソフトウェアを含み代替として描かれるか又は説明され得る。

分散計算環境を支援する様々なシステム、コンポーネント及びネットワーク構成が存在する。計算システムは、例えば有線又は無線システムによって、ローカルネットワーク又は広域分散ネットワークによって１つに接続され得る。現在、ネットワークの多くは、広域分散計算のための構造基盤を提供し、多くの異なるネットワークを包含するインターネットと結合される。構造基盤のいくつかは、本発明によるグラフィックスパイプラインに付随される例示的通信のために使用され得る。

家庭のネットワーク環境においては、電力線、データ（無線及び有線双方）、音声（例えば電話）及び娯楽メディアのようなそれぞれ固有のプロトコルを支援し得る少なくとも４つの異種ネットワーク輸送媒体がある。電灯スイッチ及び器具など、家庭の制御装置のほとんどは、接続性のために電力線を使用し得る。データサービスは、ブロードバンド（例えばＤＳＬ又はケーブルモデムのいずれか）として家庭に入力し得、無線（例えばＨｏｍｅＲＦ又は８０２．１１Ｂ）又は有線接続性（例えばホームＰＮＡ、Ｃａｔ５、イーサネット、電力線でさえ）いずれかを使用し家庭内でアクセスし得る。音声トラフィックは、有線（例えばＣａｔ３）又は無線（例えば携帯電話）として家庭に入力可能であって、Ｃａｔ３配線を使用し家庭内で配布できる。娯楽メディア又は他のグラフィックスデータは、衛星又はケーブルを介し家庭に入力可能であって、通常同軸ケーブルを使用し家庭内で配信される。またＩＥＥＥ１３９４及びＤＶＩは、媒体装置クラスター用デジタル相互接続である。プロトコル標準として出現し得るこれらのネットワーク環境及び他のすべては相互接続されて、イントラネットなどのネットワークを形成し、インターネットを介し外部の世界に接続され得る。要約すると、様々な異種のソースは、データの記憶と伝送のために存在し、その結果として先に進めると、計算装置は、本発明によるグラフィックスパイプラインを利用するプログラムオブジェクトへのデータアクセス又は利用されるインシデントなどの、データを共有する方法を必要とする。

インターネットは、一般に当技術分野における計算機のネットワーク化で周知のＴＣＰ／ＩＰのプロトコルスイートを利用するネットワーク及びゲートウェイの集合を参照している。ＴＣＰ／ＩＰは、「Transmission Control Protocol/Internet Protocol」に対する頭文字語である。インターネットは、ユーザがネットワーク（複数又は単数）を通して対話し、情報を共有するネットワークプロトコルを実行する計算機によって相互接続される地理的に分散したリモート計算機ネットワークのシステムとして記述され得る。そのような広範囲の情報共有のために、インターネットなどのリモートネットワークは、今までのところは一般に、開発者が本質的には制限しないで特化した作業又はサービスを実行するためのソフトウェアアプリケーションを設計できるオープンシステムに発展してきた。

従ってネットワーク基盤は、クライアント／サーバ、ピアツーピア又はハイブリッド構造などのネットワークトポロジーのホストを可能にする。「クライアント」は、関係付けられない別のクラス又はグループのサービスを利用するクラス又はグループのメンバーである。従って計算においては、クライアントは、別のプログラムによって提供されるサービスをリクエストするプロセス、すなわち概略、命令又はタスクセットであり得る。クライアントプロセスは、他のプログラム又はサービス自体に関する任意の動作の詳細を「知る」必要なく、リクエストされたサービスを利用する。クライアント／サーバアーキテクチャ、特にネットワーク化されたシステムにおいては、クライアントは通常、別の計算機、例えばサーバによって提供される共有ネットワークリソースにアクセスする計算機である。図１の例においては、計算機（１１０ａ）、（１１０ｂ）その他は、クライアントとして考えられ得、計算機（１０ａ）、（１０ｂ）その他は、サーバとして考えられ得、任意の計算機は、状況に従ってクライアント、サーバ又は双方と考えられ得るが、サーバ（１０ａ）、（１０ｂ）その他は、次にクライアント計算機（１１０ａ）、（１１０ｂ）その他において複製されるデータを維持する。これらの計算装置のいくつかは、データ処理し得又は本発明におけるグラフィックスパイプラインの実装に特定のグラフィックスプログラミング技術に関係していると見なし得るサービス又はタスクをリクエストできる。

サーバは通常、インターネットなどのリモート又はローカルネットワークにおいてアクセス可能なリモート計算機システムである。クライアントプロセスは、第１の計算機システムにおいて動作中であり得、サーバプロセスは、第２の計算機システムにおいて動作中であり得、通信媒体上で相互通信し、こうして分散機能性を提供し、複数のクライアントがサーバの情報収集能力を利用可能にする。グラフィックスパイプラインのグラフィックスプログラミング技術によって利用される任意のソフトウェアオブジェクトは、複数の計算装置又はオブジェクトに渡って分散され得る。

クライアント（単数又は複数）及びサーバ（単数又は複数）は、プロトコルレイヤ（単数又は複数）で提供される機能性を利用し相互通信する。例えば、ハイパーテキスト転送プロトコル（ＨＴＴＰ）は、ＷＷＷ（ＷＷＷ）又は「ウェブ」に関連し使用される一般的なプロトコルである。インターネットプロトコル（ＩＰ）アドレスなどの計算機ネットワークアドレス又はユニバーサルリソースロケータ（ＵＲＬ）などの他の参照は通常、サーバ又はクライアント計算機を相互に識別するために使用され得る。ネットワークアドレスは、ＵＲＬアドレスとして参照され得る。通信が、通信媒体を通して提供され得、例えばクライアント（単数又は複数）及びサーバ（単数又は複数）は、大容量通信用のＴＣＰ／ＩＰ接続（単数又は複数）を介し相互接続され得る。

このように図１は、本発明が使用され得る、ネットワーク／バスを介してクライアント計算機と通信するサーバを用いた例示的なネットワーク化又は分散化した環境を示す。更に詳細には、複数のサーバ（１０ａ）、（１０ｂ）その他は、ＬＡＮ、ＷＡＮ、イントラネット、インターネットであり得る通信ネットワーク／バス（１４）を介し、携帯用計算機、ハンドヘルドコンピュータ、シンクライアント、ネットワーク化された電化製品、ＶＣＲ、テレビ、オーブン、電灯、ヒーターやその他のような複数のクライアント又はリモート計算装置（１１０ａ）、（１１０ｂ）、（１１０ｃ）、（１１０ｄ）、（１１０ｅ）その他を有すると本発明により相互接続される。従って本発明は、本発明のグラフィックスパイプラインを使用するグラフィックスインタフェースを実施することが望まれる任意の計算装置に関連して適用できると想定される。

通信ネットワーク／バス（１４）がインターネットであるネットワーク環境においては、例えばサーバ（１０ａ）、（１０ｂ）その他は、クライアント（１１０ａ）、（１１０ｂ）、（１１０ｃ）、（１１０ｄ）、（１１０ｅ）その他が、ＨＴＴＰなど知られている複数のプロトコルを介し通信するウェブサーバであり得る。またサーバ（１０ａ）、（１０ｂ）その他は、クライアント（１１０ａ）、（１１０ｂ）、（１１０ｃ）、（１１０ｄ）、（１１０ｅ）その他としての役目をし得、分散計算環境の特徴であり得る。通信は、適切な有線又は無線であり得る。クライアント装置（１１０ａ）、（１１０ｂ）、（１１０ｃ）、（１１０ｄ）、（１１０ｅ）その他は、通信ネットワーク／バス（１４）を介し通信し得るか又は通信し得ず、それらに関連し独立した通信を有し得る。例えばテレビ又はＶＣＲの場合、そのコントロールに対してネットワーク化され得るか又はされ得ない。クライアント計算機（１１０ａ）、（１１０ｂ）、（１１０ｃ）、（１１０ｄ）、（１１０ｅ）その他及びサーバ計算機（１０ａ）、（１０ｂ）その他それぞれは、様々なアプリケーションプログラムモジュール又はオブジェクト（１３５）と、ファイル又はデータストリームがストアされ得る又はファイルの一部（単数又は複数）又はデータストリームがダウンロード、送信又は移動され得る様々なタイプの記憶エレメント又はオブジェクトに対する接続又はアクセスと、を備え得る。１つ以上の任意の計算機（１０ａ）、（１０ｂ）、（１１０ａ）、（１１０ｂ）その他は、本発明に従って処理されるデータをストアするためのデータベース又はメモリ（２０）などのデータベース（２０）又は他の記憶エレメントを維持し、更新し得る。このように本発明は、計算機ネットワーク／バス（１４）にアクセスし、対話し得るクライアント計算機（１１０ａ）、（１１０ｂ）その他と、クライアント計算機（１１０ａ）、（１１０ｂ）その他及びデータベース（２０）及び他の装置その他と対話し得るサーバ計算機（１０ａ）、（１０ｂ）その他と、を有する計算機ネットワーク環境において利用される。
例示的計算装置
図２及び以下の論述は、本発明に関連し実施され得る適切な計算環境の簡潔な概説を提供することを意図する。しかしながら、ハンドヘルド、携帯用及び他の計算装置及びすべての種類の計算オブジェクトが、すなわちそのＧＰＵが計算環境どこでも存在する所において、本発明に関連した使用に対して想定されることを理解されたい。汎用計算機が以下に説明されるが、これは一例に過ぎず、本発明は、ネットワーク／バス相互運用性及び相互作用を有するシンクライアントを用いて実施され得る。このように本発明は、微小又は最小のクライアントリソースが関係していると見なされるネットワークに接続されたホストのサービス環境において実施され得、例えばそこではクライアント装置は、電化製品に置かれるオブジェクトのような単にネットワーク／バスにインタフェースとしての役目を果たす。本質的にデータがストアされ得るか又はデータがそこからリトリーブ又は別の計算機に送信され得る場所は、本発明に従ったグラフィックス最適化技法の操作のために望まれる又は適する環境である。

本発明は、必要ではないが装置又はオブジェクトに対するサービスの開発者による使用のためにオペレーティングシステムを介し実施され得、及び／又は本発明のグラフィックスパイプラインに対するグラフィックスプログラミング技術に関連して作動する、アプリケーションソフト内に含まれる。ソフトウェアは、クライアントワークステーション、サーバ又は他の装置などの１つ以上の計算機によって実行されるプログラムモジュールなどの計算機実行可能命令の一般的な文脈で記載され得る。一般にプログラムモジュールは、特定のタスクを実行するか、又は特定の抽象データ型を実現するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。プログラムモジュールの機能性は通常、様々な実施形態において所望によって結合又は分散され得る。当業者は更に、本発明が、他の計算機システムの構成及びプロトコルを用いて実施され得ることを理解されよう。本発明を用いて使用するのに適し得る他の周知の計算システム、環境及び／又は構成はパーソナルコンピュータ（ＰＣ）、現金自動預入支払機、サーバ計算機、携帯用又はラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースシステム、プログラマブル家電、ネットワークＰＣ、電化製品、電灯、環境制御エレメント、ミニコンピュータ、メインフレームコンピュータ又はその他を含むが、これらに限定されない。本発明は、通信ネットワーク／バス又は他のデータ伝送媒体を介し接続されるリモート処理装置によるタスクが実行される分散計算環境においてもまた実施され得る。分散計算環境においては、プログラムモジュールは、メモリ記憶装置を含むローカル及びリモート双方の計算機記憶媒体に配置され得、クライアントノードは、サーバノードとして順に実行し得る。

このように図２は、本発明が実施され得る適応する計算システム環境（１００）の一例を示すが、前述において明らかにしたように計算システム環境（１００）は、適応する計算環境の一例に過ぎず、本請求項の使用又は機能性の範囲に関しいかなる制限を提示することも意図しない。計算環境（１００）は、例示的な動作環境（１００）において示されるコンポーネントの任意の１つ又は組み合わせに関していかなる依存関係も要求も有しないものとして解釈されるべきである。

本発明を実施するための例示的なシステムは、図２を参照して計算機（１１０）形式の汎用計算装置を含む。計算機（１１０）のコンポーネントは、処理ユニット（１２０）、システムメモリ（１３０）及びシステムメモリを含む多様なシステムコンポーネントを処理ユニット（１２０）に接続するシステムバス（１２１）を含むが、これに限定されない。システムバス（１２１）は、メモリバス又はメモリコントローラを含むいくつかの任意のタイプのバス構造、周辺機器用バス及び様々なバスアーキテクチャのうちいくつかを使用するローカルバスであり得る。制限ではなく例として、そのようなアーキテクチャは、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオ機器に関する標準化団体（ＶＥＳＡ）ローカルバス及び（メザニンバスとしても知られる）周辺機器相互接続（ＰＣＩ）バスを含む。

計算機（１１０）は、一般に様々な計算機可読媒体を含む。計算機可読媒体は、計算機（１１０）によってアクセスされ得る使用可能な任意の媒体であり得、揮発性及び不揮発性双方の媒体及び取り外し可能及び取り外し不可能な双方の媒体を含む。制限ではなく例として、計算機可読媒体は、計算機記憶媒体及び通信媒体を含む。計算機記憶媒体は、計算機可読命令、データ構造、プログラムモジュール又は他のデータなどの情報の記憶に関する任意の方法又は技術にて実装される揮発性及び不揮発性双方の取り外し可能及び取り外し不可能な媒体を含む。計算機記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ又は他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）又は他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置又は他の磁気記憶装置又は所望の情報をストアするために使用され得、計算機（１１０）によってアクセスされ得る他の任意の媒体を含むが、これらに限定されない。通信媒体は一般に、搬送波又は別の移送機構などの変調データ信号で計算機可読命令、データ構造、プログラムモジュール又は他のデータを具現化したものであって、任意の情報伝達媒体を含む。用語「変調データ信号」は、１つ以上の特徴の組を有する信号又は信号中の情報を符号化する方法によって変更された信号を意味する。通信媒体は、制限ではなく例として、有線ネットワーク又は直接有線接続のようなワイヤード媒体並びに音響、無線（ＲＦ）、赤外線及び他の無線媒体のようなワイヤレス媒体を含む。前述の任意の組み合わせもまた、計算機可読媒体の範囲内に含む必要がある。

システムメモリ（１３０）は、読み出し専用メモリ（ＲＯＭ）（１３１）及びランダムアクセスメモリ（ＲＡＭ）（１３２）などの揮発性及び／又は不揮発性メモリ形式の計算機記憶媒体を含む。基本入出力システム（ＢＩＯＳ）（１３３）は、通常、起動の間などに計算機（１１０）のエレメント間の情報送信を支援する基本ルーチンを含んでいて、ＲＯＭ（１３１）にストアされる。ＲＡＭ（１３２）は通常、処理ユニット（１２０）によって直接アクセス可能な及び／又は現在作動されているデータ及び／又はプログラムモジュールを含む。制限ではなく例として、図２は、オペレーティングシステム（１３４）、アプリケーションプログラム（１３５）、他のプログラムモジュール（１３６）及びプログラムデータ（１３７）を示す。

また計算機（１１０）は、別の取り外し可能／取り外し不可能、揮発性／不揮発性の計算機記憶媒体も含み得る。例に過ぎないが、図２は、取り外し不可能、不揮発性磁気媒体から読み出すか又は書き込むハードディスクドライブ（１４１）、取り外し可能、不揮発性磁気ディスク（１５２）から読み出すか又は書き込む磁気ディスクドライブ（１５１）、ＣＤ−ＲＯＭ又は他の光媒体などの取り外し可能、不揮発性光ディスク（１５６）から読み出すか又は書き込む光ディスクドライブ（１５５）を示す。例示的な動作環境において使用され得る別の取り外し可能／取り外し不可能、揮発性／不揮発性計算機記憶媒体は、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、半導体ＲＡＭ、半導体ＲＯＭ等を含むが、これに限定しない。ハードディスクドライブ（１４１）は通常、インタフェース（１４０）などの取り外し不可能メモリインタフェースを介し、システムバス（１２１）と接続され、磁気ディスクドライブ（１５１）及び光ディスクドライブ（１５５）は通常、インタフェース（１５０）などの取り外し可能メモリインタフェースによってシステムバス（１２１）と接続される。

前述の図２に例示されるドライブ及びそれらに関連する計算機記憶媒体は、計算機（１１０）に計算機可読命令、データ構造、プログラムモジュール及び他のデータの記憶装置を提供する。図２においては、例えばハードディスクドライブ（１４１）は、オペレーティングシステム（１４４）、アプリケーションプログラム（１４５）、他のプログラムモジュール（１４６）及びプログラムデータ（１４７）をストアするように示される。これらのコンポーネントは、オペレーティングシステム（１３４）、アプリケーションプログラム（１３５）、他のプログラムモジュール（１３６）及びプログラムデータ（１３７）と同等か又は異なるいずれかであり得ることに留意されたい。オペレーティングシステム（１４４）、アプリケーションプログラム（１４５）、他のプログラムモジュール（１４６）及びプログラムデータ（１４７）が、異なる複製物であることを最小限示すために、本明細書においては所与の異なる番号を付与する。ユーザは、キーボード（１６２）などの入力装置及びマウス、トラックボール又はタッチパッドとして一般に呼ばれるポインティング装置（１６１）を介し、計算機（１１０）にコマンド及び情報を入力できる。（示されない）別の入力装置は、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナ又はその他を含み得る。多くの場合、これら及び他の入力装置は、システムバス（１２１）に接続されるユーザ入力インタフェース（１６０）を介し処理ユニット（１２０）と接続されるが、パラレルポート、ゲームポート又はユニバーサルシリアルバス（ＵＳＢ）のような別のインタフェース及びバス構造によっても接続され得る。またノースブリッジなどのグラフィックスインタフェース（１８２）が、システムバス（１２１）に接続され得る。ノースブリッジは、ＣＰＵ又はホスト処理装置（１２０）と通信し、アクセラレイティッドグラフィックスポート（ＡＧＰ）通信用の責務を担うチップセットである。１つ以上のグラフィックスプロセッシングユニット（ＧＰＵ）（１８４）は、グラフィックスインタフェース（１８２）と通信し得る。その際、ＧＰＵ（複数）（１８４）は一般に、レジスタ記憶装置などのオンチップメモリ記憶装置を含み、ＧＰＵ（複数）（１８４）は、ビデオメモリ（１８６）と通信し、そこにおいては本発明のアプリケーション変数が影響を与え得る。ＧＰＵ（複数）（１８４）は、コプロセッサの一例に過ぎないが、しかし、このように様々なコプロセッシング装置は、計算機（１１０）に含まれ得、ピクセル及びバーテックスシェーダのような様々な手続き的なシェーダを含み得る。モニタ（１９１）又は別のタイプの表示装置もまた、ビデオメモリ（１８６）と次に通信するビデオインタフェース（１９０）などのインタフェースを介しシステムバス（１２１）に接続される。モニタ（１９１）に加えて計算機は、出力周辺インタフェース（１９５）介し接続され得るスピーカ（複数）（１９７）及びプリンタ（１９６）などの他の周辺出力装置もまた含み得る。

計算機（１１０）は、リモート計算機（１８０）などの１つ以上のリモート計算機との論理的な接続を使用するネットワーク化又は分散化環境において作動し得る。リモートコンピュータ（１８０）は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置又は一般的な他のネットワークノードであり得、図２にはメモリ記憶装置（１８１）だけが例示されているが、通常、前述の計算機（１１０）に関連するエレメントの多数又はすべてを含む。図２に示される論理的な接続は、ローカルエリアネットワーク（ＬＡＮ）（１７１）及び広域ネットワーク（ＷＡＮ）（１７３）を含むが、別のネットワーク（複数）／バス（複数）もまた含み得る。そのようなネットワーク環境は、家庭、オフィス、企業全体の計算機ネットワーク、イントラネット及びインターネットにおいて一般的である。

計算機（１１０）は、ＬＡＮネットワーク環境において使用されるとき、ネットワークインターフェース又はアダプタ（１７０）を介しＬＡＮ（１７１）に接続される。計算機（１１０）は通常、ＷＡＮネットワーク環境において使用されるとき、インターネットなどのＷＡＮ（１７３）において通信を確立するためのモデム（１７２）又は別の手段を含む。内蔵又は外付けであり得るモデム（１７２）は、ユーザ入力インタフェース（１６０）又は適切な別の装置を介し、システムバス（１２１）に接続され得る。ネットワーク化環境においては、計算機（１１０）又はその一部に関連し表示されるプログラムモジュールは、リモートのメモリ記憶装置にストアされ得る。図２は、制限ではなく例として、メモリ装置（１８１）に常駐するようなリモートアプリケーションプログラム（１８５）を示す。示されたネットワーク接続は、例示的であって、計算機の間の通信リンクを確立する他の手段が使用され得ることが十分理解されよう。
例示的分散計算フレームワーク又はアーキテクチャ
様々な分散計算フレームワークが、個人的な計算及びインターネットの集合の観点から開発されている。個人及びビジネスユーザは、一様にアプリケーション及び計算装置用の相互利用可能なウェブ対応できるインタフェースをシームレスに提供され、計算活動をますますウェブブラウザ又はネットワーク指向にする
例えば、マイクロソフト（登録商標）に管理されたコードプラットフォーム、すなわちドットネット（．ＮＥＴ）は、ウェブを基本とするデータ記憶装置及びダウンロード可能なデバイスソフトウェアなどのサーバ、ビルディングブロックサービスを含む。一般的に述べると、ドットネットのプラットフォームは、（１）計算装置の全体に渡って共に実行させ、それらすべてに対しユーザ情報を自動的に更新させ同期させる能力、（２）ＨＴＭＬよりむしろＸＭＬをより広範囲に使用することによって可能とされるウェブページに対し増大する対話能力、（３）例えば電子メールなどの様々なアプリケーション又はOffice NETのようなソフトウェア管理のための中心となる開始点からユーザにカスタマイズされた製品及びサービスのアクセス及び配布を特徴とするオンラインサービス、（４）情報へのアクセス効率及び容易さの他にユーザと装置との間の情報同期もまた増大させる中央データ記憶領域、（５）電子メール、ファックス及び電話などの様々な通信媒体統合化能力、（６）開発者に対する再利用モジュール生成能力及びそれによって生産性を増加しプログラミングエラー数を低減させる能力、（７）多くの他のクロスプラットフォーム及び言語統合機能など、を提供する。

本明細書においてはいくつかの例示的な実施形態が、計算装置上にあるソフトウェアに関連し説明されているが、本発明の１つ以上の部分はまた、オペレーティングシステム、アプリケーションプログラミングインタフェース（ＡＰＩ）又は「middle man（仲介人）」オブジェクト、コントロールオブジェクト、ハードウェア、ファームウェア、中間言語の命令又はオブジェクトなどを介し実装され得、本方法は、他の分散計算フレームワークにおいても同様に含まれ得、支援され得、又はドットネットコードなどの管理コードによって使用可能な言語及びサービスすべてを介しアクセスされ得る。
例示的３次元グラフィックスシステムコンポーネント
図３は、グラフィックスプロセッシングユニット（ＧＰＵ）（３８４’）を含むビデオカードなどのグラフィックスサブユニットを含む例示的なグラフィックスシステム（３００）及び関連付けられるグラフィックスパイプライン（３８４’−１）用の例示的なハードウェア構成を示す。例示的な３次元グラフィックスシステム（３００）は特に、中央処理ユニット（ＣＰＵ）（３２０）と、（時として「レンダリングパイプライン」として呼ばれる）グラフィックスパイプライン（３８４’−１）を含む（時としてビジュアルプロセッシングユニット（ＶＰＵ）と呼ばれる）グラフィックスプロセッシングユニット（ＧＰＵ）（３８４’）を含むグラフィックスカードと、を含み得る。ＧＰＵ（３８４’）は、例えばＡＧＰ又はＰＣＩ高速バスを介し、ＣＰＵ（３２０）及びメインＲＡＭと、接続され得る。

ＣＰＵ（３２０）は一般に、シングルチップ、いくつか（例えば１つ以上）のスレッドを同時に処理又は実行可能な同時マルチスレッディング（ＳＭＴ）プロセッサのようなマルチコア（例えばプロセッサ）を実行するマルチコアプロセッサなどの任意のプロセッサであり得る。本明細書において、用語「スレッド」は、個々の命令列を参照している。同時マルチスレッディングそれ自体は、単一のプロセッサが同時に数個のスレッドを処理するための能力を参照している。ＣＰＵ（３２０）の各コアは、プロセッサの命令セットの拡張機能として単一命令複数データストリーム（ＳＩＭＤ）ユニットを有し得る。拡張機能は、特別にコード化されたとき、これらの命令セットをうまく利用するために、整数及び浮動小数点的に集中するアプリケーションを高速化するために役立つ特殊命令アプリケーションを含み得る。３次元グラフィックスをレンダリングする際に関与する計算は、数学的な集中をし得、むしろＣＰＵ（３２０）に重い負担をかけ得る。ＧＰＵ（３８４’）は、ＣＰＵ（３２０）への負担を軽減するために、計算機がより効率的な実行を支援するように提供され得る。

グラフィックスがラスター表示装置（例えば計算機モニタ（１９１））に出力される前に、それらのグラフィックスを生成するために使用される情報が、ＧＰＵ（３８４’）及びそのグラフィックスパイプライン（３８４’−１）を介し通過する。ＧＰＵ（３８４’）は、毎秒何十億の幾何学的図形計算を実行するためのハードウェアにおいて、グラフィックスパイプライン（３８４’−１）を実施する。

ＧＰＵ（３８４’）は、グラフィックスを操作し表示する点で非常に効率的であって、高度な並列構造は、様々な複雑なアルゴリズムに関して、典型的なＣＰＵよりも効果的にする。ＧＰＵ（３８４’）は、ホストＣＰＵ（３２０）を用いて画面に直接描画するよりもそれらをはるかに速く実行することを可能にする方法によって、いくつかのグラフィックスプリミティブ動作を実施する。ＣＰＵ（３２０）からこの負荷を軽減することは、計算機のＣＰＵ（３２０）が、グラフィックスデータを処理することを困難とする動作が必要ない（例えば他の仕事のために使用され得るサイクルを解放する）ことを意味する。グラフィックス機能の大部分をＧＰＵ（３８４’）にさせることによって、ＣＰＵは、ましてなおさら、没入する実時間グラフィックス環境を達成するための計算を実行できる。ＧＰＵ（３８４’）は、ラスター表示装置（例えば計算機モニタ）上にグラフィックス要素（例えばそれらに適用されるテクスチャ及びシェーディングを有するポリゴン）表示を加速する。ＧＰＵ（３８４’）は、最終的にモニタ（１９１）上にピクセルとしてその情報を表示するために、未加工の幾何学的図形データを処理する。グラフィックスパイプライン（３８４’−１）は、３次元シーン表示を受信し、いくつかの処理ステージを介する表示を実行することによって、その表示を効率的に処理し、モニタ（１９１）に２次元ラスター画像として３次元シーンをレンダリングする。

ＧＰＵ（３８４’）は、実時間の２次元及び３次元グラフィックスを処理するように構成される１つ以上の単独で動作するマイクロプロセッサとして実装され得る。ＧＰＵ（３８４’）は、２次元及び／又は３次元計算機グラフィックスを処理し、その後、２次元又は３次元画像をレンダリングするための（マザーボードから）分離されたグラフィックスカード上に置かれ得る。ＧＰＵ（３８４’）は、グラフィックスカード上の高性能ＶＲＡＭに直接にアクセスし得る。代替としてＧＰＵ（３８４’）は、ＰＣマザーボード上のチップの１つにそれを統合化することによって実装され得、ＧＰＵ（３８４’）は、フレームのレンダリングの際に支援するためのフレームバッファ及びＣＰＵとして、メインメモリを使用できる。ＧＰＵ（３８４’）は、例えばパーソナルコンピュータ又はゲームコンソール用の専用グラフィックス／映像レンダリング装置として使用され得る。

３次元グラフィックスレンダリングにおいては、グラフィックスパイプライン（３８４’−１）は、ＧＰＵ（３８４’）が３次元画像データ（例えばバーテックス、テクスチャ及び他のデータ）をあるアプリケーションから２次元画面上に表示する実画像に変換するために実行する様々なステージ処理（例えばステップ列）を参照している。バーテックス単位で提供されるプロパティは、例えばｘ−ｙ−ｚ座標、ＲＧＢ値、透光性、テクスチャ、反射率及び他の特性を含み得る。

グラフィックスパイプライン（３８４’−１）における異なるステージは、最終的にレンダリングされる画像を生成するためのエンドポイント（バーテックス）又はジオメトリックプリミティブのコントロールポイントにおける特性として、最初に提供される情報を処理する。本明細書において、用語「プリミティブ」は、単一の３次元実体を形成するバーテックス集合を参照し得る。最も単純なプリミティブは、３次元座標システムにおける点の集合であって、それはポイントリストと呼ばれる。３次元グラフィックスにおける典型的なプリミティブは、ライン及び三角形である。他のタイプのプリミティブは、例えばライン、ラインリスト、ラインストリップ、三角形、三角形リスト、三角形ストリップ及び三角形ファンを含み得る。多くの場合、３次元プリミティブはポリゴンである。ポリゴンは、少なくとも３つのバーテックスによって輪郭を描画された閉じた３次元図である。最も簡単なポリゴンは三角形である。三角形における３つのバーテックスすべてが、同一平面上にあることを保証されているため、三角形がほとんどのポリゴンを構成するために使用され得る。三角形は、大きくて複雑なポリゴン及びメッシュを形成するために使用され得る。

グラフィックスパイプライン（３８４’−１）内では、すべてのステージは、並列実行している。グラフィックスパイプライン（３８４’−１）の再構成によって、異なる視覚効果が達成され得る。例えばグラフィックスパイプラインは、（例えば三角形リスト）を表示するために幾何学的図形を受信し、その後、その上で必要な座標変換（例えば回転、変換など）を実行し、表示する幾何学的図形のための色を計算し、次に、表示される幾何学的図形をレンダリングし得る。
パイプラインステージ
グラフィックスパイプライン（３８４’−１）は一般に、以下論理的なステージであるインプットアセンブラ（ＩＡ）、バーテックスシェーダ（３８４’−１ａ_１）及び（３８４’−１ａ_２）、関連付けられたストリーム出力（３８４’−２）有するジオメトリシェーダ（３８４’−１ａ_３）、ラスタライザー（３８４’−１ｃ）、ピクセルシェーダ（３８４’−１ａ_４）及びアウトプットマージャ（ＯＭ）を含み得る。グラフィックスパイプライン（３８４’−４）は、リソースの使用を最適化し、グラフィックスパイプライン（３８４’−１）における作業負荷の平衡をとり、ＩＥＥＥ準拠の整数又は浮動小数点値を用いて計算される情報にアクセス可能とし、更なるプログラム可能性を提供するように構成され得る。

グラフィックスパイプライン（３８４’−１）の例示的で非限定的な実施形態は、いくつかのユニットを含む動的構成が可能なコモンシェーダコア（単数又は複数）又は様々な構成において構成され得るプロセッシングコア（３８４’−１ａ）を使用する。コモンシェーダコアは、（異なるシェーダに対する）同一のハードウェアユニットが、シェーダの再構成による負荷平衡をとることを提供するか、又は、それが必要とされないとき、パイプラインの一部として無効にし、こうして動作を維持するステージのためのリソースをフリーにするように簡易化された最適化を可能にする。

これらのプロセッシングコア（３８４’−１ａ）は、実行されている特定の用途に従った様々なパターンでメモリに読み込まれ、メモリから書き出され得る。その構成に従ってユニット（３８４’−１ａ）それぞれは、バーテックスシェーダステージ、ジオメトリシェーダステージ及び／又はピクセルシェーダステージを実行するために使用され得る。これによって、コモンシェーダコアが、パイプライン（３８４’−１）のリクエストされたタスクのための最適な方法でピクセルシェーダ、ジオメトリシェーダ及びバーテックスシェーダを割り当てることをグラフィックスパイプライン（３８４’−１）の異なるステージ（又は機能ブロック）にオンデマンドでスケジューリングされることが可能になる。動作中のステージのためにリソースを解放し「再特化」され得ることによって、任意のステージが、動的に有効又は無効に構成又は再構成され得る。グラフィックスチップの基本的なリソースそれ自体は、グラフィックスチップに求められるタスクのために最適化され得る。

図３に示される特定のグラフィックスパイプライン（３８４’−１）の構成は、複数の共有されたプログラム可能なコア又はコモンコアエレメント（３８４’−１ａ）、バーテックスシェーダ（３８４’−１ａ_１）及び（３８４’−１ａ_２）及び関連付けられるストリーム出力（３８４’−２）を有するジオメトリシェーダ（３８４’−１ａ_３）及びピクセルシェーダ（３８４’−１ａ_４）を含む。これらの異なる機能的ステージは、個別の専用プロセッサとしての役目をして並列に作動する。特定の実装による図３に示される追加的又はより少数のパイプラインステージがあり得る。更に、一定のバーテックス及びプリミティブデータ処理の間、表示されるいくつかのパイプラインステージだけが、出力が計算機モニタ上に表示される前にそのデータを実際に処理できる。
インプットアセンブラ（ＩＡ）
グラフィックスパイプライン（３８４’−１）は、アプリケーションから着信するプリミティブデータ及びバーテックスデータを受信し、計算機モニタ又は画面上に出力を表示する前に、様々なパイプラインステージを介しそれを渡す。インプットアセンブラ（ＩＡ）は、ソースの幾何学的図形データをバーテックスメモリ及びインデックスメモリバッファから取り出すことによって、三角形、ライン又はポイントなどのバーテックスデータをグラフィックスパイプライン（３８４’−１）へ導く。

「非インデックス」又は「インデックス」レンダリングは、メモリのバーテックスデータをフェッチするためのアドレスを生成し、その後バーテックス及びプリミティブにその結果をアセンブルするために使用され得る。

「非インデックス」レンダリングは、バーテックスデータを含むバーテックスバッファ（単数又は複数）の逐次的なトラバースを参照していて、バッファ結合それぞれにおける開始オフセットで開始する。（図３に表示されない）バーテックスメモリバッファは、アプリケーションから未変換のモデルバーテックスを受信し得、バーテックスデータとしてそれらをストアし得る。バッファは、個々の入力スロットそれぞれに結合される。バッファすべてに渡ったデータ割り付けは、各エントリーが、入力スロット、構造オフセット、データタイプ及び（パイプラインにおける第１の動作中のシェーダのための）目標レジスタを用いた「要素」を定義している入力宣言によって指定されている。バーテックスメモリバッファは、任意のバーテックスタイプを含み得る。バーテックスデータは、各バッファから「アレイ構造」形式でアクセスされ、複数のバッファから着信し得る。所与のバーテックス列は、バッファからフェッチされたデータから構成される。様々なプリミティブトポロジーは、バーテックスデータ列にプリミティブ列を表示可能にするために使用できる。例的トポロジーは、例えばポイントリスト、ラインリスト、三角形リスト、三角形ストリップである。

「インデックス」レンダリングは、スカラ整数のインデックスリストを含む単一バッファの逐次的なトラバースを参照していて、バッファへの開始オフセットで開始する。またグラフィックスパイプラインの（３８４’−１）によって処理されるデータは、インデックスを割り当てられ得る。（図３に表示されない）インデックスメモリバッファは、アプリケーションからポイント、ライン、三角形及びポリゴンを含む未加工のジオメトリプリミティブインデックスデータを受信する。これらのジオメトリプリミティブは、インデックスメモリバッファを用いてバーテックスデータにおいて参照され得る。各インデックスは、バーテックスデータを含むバッファ（単数又は複数）からデータをフェッチする場所を示す。インデックスメモリバッファは、インデックスデータ又はインデックス（複数）を含んでいて、バーテックスメモリバッファへの整数オフセットであって、現在のデータ入力ストリームセットからインデックスプリミティブを描画する技法を使用し、プリミティブをレンダリングするために使用される。インデックスバッファは、インデックス（複数）を含むためにインデックスバッファは、対応するバーテックスバッファなしに使用され得ない。インデックス化は、いくつかの状況において有用であり得る。（例えばインデックスは、処理のための映像メモリの一部をどこでいつリトリーブ（及び／又は書く）するかを意味する）インデックス値は、例えばデータを処理している間、例えば映像メモリアドレッシングの仕組みの一部として使用され得る。従ってシェーダにダウンロードされるプログラムは、映像メモリのリトリーブ又は書き込みが、グラフィックスデータに関連付けられたインデックス値をプログラムで使用し、グラフィックスデータを処理する間もまた使用できる。
バーテックスシェーダステージ
インプットアセンブラ（ＩＡ）は、第１のコモンコア（３８４’−１ａ_１）にデータを送信する。この実施形態においては、第１のコモンコア（３８４’−１ａ_１）は、バーテックスシェーダステージとして構成される。バーテックスシェーダステージは、ホストからプログラムを介しアルゴリズム変換用に指定される（グラフィックスパイプラインの映像メモリから）バーテックスストリームを操作又は処理する。特に、バーテックスシェーダは、一定の変数及びバーテックス属性などの様々な入力を受信できる。一定の変数は、シェーダ呼び出しそれぞれのための定数値である。対照的にバーテックス属性は、バーテックス位置などのバーテックス毎の（特別な場合の変数値）データである。

バーテックスシェーダは一般に、単一の入力バーテックスに影響し、単一の出力バーテックスを生成し、そこでは、「バーテックス」は、通常、ｘ、ｙ及びｚ座標を使用し、位置によって定義される３次元空間の交差ポイントを参照している。バーテックスシェーダステージは、幾何学的図形バーテックスが画面に映し出される前に、幾何学的図形バーテックスそれぞれがショートプログラムによって処理され得ることが可能になる。例えばバーテックスシェーダステージは、ベクトル空間変換及び他の線形化計算を計算する技法を定義することによって、３次元空間のオブジェクトの位置を操作できる。例えばバーテックスシェーダステージは、位置、色及びテクスチャ座標計算を個別のバーテックスへ適用可能であって、変換、スキニング及び明るさなどの操作を実行できる。バーテックスシェーダの機能例の中には、一般にテクスチャ座標変換など、後のピクセルシェーダのための線形化属性を計算する任意のメッシュ変形及びバーテックス置換を含むものもある。
テッセレータステージ
データはその後、データに対するテセレーションを実行するテッセレータ（３８４’−１ｂ）に送信され得る。テセレーションステップは、（破線の長方形で示されるように）任意であって、実用的な実装の中には全く発生しないものもあることを当業者には十分に理解されよう。テッセレーションは、一般に１つのタイプ又は数タイプの適合する平面図形によるギャップ又はオーバラップをせずに区分けされる幾何学的図形領域のカバリングに関連する処理を参照している。テッセレータ（３８４’−１ｂ）に続いて、パイプラインに別のコモンコアが存在し、データに対するポストテセレーションのバーテックスシェーディングを実行するために使用され得る。この実施形態においては、テッセレータステップは任意である。
ジオメトリシェーダステージ
第２のコモンコアは、ジオメトリシェーダ（３８４’−１ａ_３）として構成される第３のコモンコアの後に続く。ジオメトリシェーダ（３８４’−１ａ_３）は、プログラミングプリミティブの他に新しい幾何学的図形の生成もまた可能にする。ジオメトリシェーダ（３８４’−１ａ_３）は、バーテックス（複数）／ポイント（複数）、ライン（複数）（２つのバーテックスセット）及び三角形（複数）（３つのラインセット）を含む異なるタイプの「プリミティブ」入力に影響し、入力されるプリミティブに基づいてパイプライン内部に新しい幾何学的図形を生成し得る。ジオメトリシェーダの入力は、完全プリミティブ用バーテックス（ライン用の２つのバーテックス、三角形用の３つのバーテックス又はポイント用の単一バーテックス）及びエッジ隣接プリミティブ用バーテックス（ライン用の更なる２つのバーテックス、三角形用の更なる３つのバーテックス）データである。ジオメトリシェーダの（３８４’−１ａ_３）は、例えば１つのプリミティブを受信し得、０、１又は複数のプリミティブのいずれかを出力できる。ジオメトリシェーダ（３８４’−１ａ_３）は、選択された単一のトポロジーを形成する複数バーテックスを出力できる。出力例の中には、三角形ストリップのようなトポロジー、ラインストリップ又はポイントリストを含む。エミットされたプリミティブの数は、任意のジオメトリシェーダ（３８４’−１ａ_３）呼び出しの内部で変更できる。

ジオメトリシェーダ（３８４’−１ａ_３）は、１つのプリミティブを取り得、隣接バーテックスなどの任意の隣接プリミティブを処理する複数のプリミティブを出力し得る。言い換えると、ジオメトリシェーダ（３８４’−１ａ_３）は、それ自体だけによるものではなく、更なるいくつかのバーテックス近くの文脈においては、プリミティブ全体に対する操作もまた可能にする。ポリラインにおける一ラインセグメントは、例えばそのセグメントの前後のバーテックスを読み込む能力を用いて処理され得る。この能力の一アプリケーション（例えば隣接バーテックスプリミティブ処理）は、ジオメトリシェーダ（３８４’−１ａ_３）が、現在の計算に３次元幾何学的図形空間の隣接ポイントに関する情報を勘案する能力である。

ジオメトリシェーダ（３８４’−１ａ_３）において実装され得るアルゴリズムは、ポイントスプライト又はワイドラインテセレーション、ファー／フィン生成、シャドウボリューム生成、複数テクスチャ立方体表面に対する単一パスレンダリングを含み得、ピクセルシェーダが、カスタム属性の挿入を実行可能にするプリミティブデータとしての重心座標を設定する。

シェーダは、ポイントスプライトテセレーションを実行するために、単一のバーテックスを受け取り、４つのバーテックス又は四辺形の全領域を表す２つの出力三角形を生成し、ワイドラインテセレーションを実行する間、シェーダは、ワイドライン化を示す四辺形用に２つのラインバーテックスを受信し、４つのバーテックスを生成する。ジオメトリシェーダは更に、ラインエンドポイントにおいてマイタを実行するために隣接ラインバーテックスを利用できる。

ジオメトリシェーダは、ファー又はフィンを生成するためにもまた使用され得、これはファー又はフィンの生成に限定されないが、単一位相の第３の方向に追加される任意の追加バーテックスを包囲する。例はヘア、スケール、グラスなどを含んでいて、そこでは、幾何学的図形を記述するプリミティブは、ジオメトリシェーダに入力され、ジオメトリシェーダは、形状を任意に補完するために、幾何学的図形を育てる。こうして、例えばジオメトリシェーダへの入力三角形に基づくファーを用いて、ジオメトリシェーダは、各バーテックスにおいてヘアを表すいくつかのバーテックスを追加し得る。有利なこととして、ジオメトリシェーダへの三角形ストリームは、バーテックスの隣接情報を含むため、バーテックスに隣接の幾何学的図形の近接及び特性（色、深さなど）は、処理の間、勘案され得る。別のジオメトリシェーダの例示的で非限定的な使用は、シャドウボリューム生成を含んでいて、押出すか否か決定するために、隣接情報が使用される。アプリケーションは更に、フィン又はファーのようないくつかの幾何学的図形を生成し、それからシャドウボリュームを押出すことを所望し得る。そのような場合、ジオメトリシェーダのマルチパス機能性が、データストリームの出力能力を使用し採用され、ストリーム出力の使用を介しそれを逆に循環する。

この例示的で非限定的な実施形態においては、ジオメトリシェーダ（３８４’−１ａ_３）からの出力は、レンダリングのためにラスタライザー（３８４’−１ｃ）及び／又はストリーム出力（ＳＯ）（３８４’−２）を介するバッファのいずれかに進む。ストリーム出力（ＳＯ）（３８４’−２）を「起動」することは、グラフィックスパイプライン（３８４’−１）のラスター化機能を停止せずに、開発者によるプログラムに従った権限を提供することによって、グラフィックスパイプライン（３８４’−１）能力を増幅するに過ぎない。
ストリーム出力
ストリーム出力（ＳＯ）（３８４’−２）は、ラスタライザー（３８４’−１ｃ）に流し続けるデータとして起動及び停止可能なグラフィックスパイプライン（３８４’−１）の「蛇口」のような役目をする。ストリーム出力（ＳＯ）（３８４’−２）は、データがラスター化のためのフレームバッファに達する前に、グラフィックスパイプライン（３８４’−１）内部のどこにおいてもタップされ得る。

ストリーム出力（ＳＯ）（３８４’−２）が停止しているときは、ストリーム出力（ＳＯ）（３８４’−２）は、パイプライン上にいかなるエフェクトも有しない。言い換えれば、ストリーム出力（ＳＯ）は任意であって、アプリケーションは、パイプラインがストリーム出力バッファにデータ読み込みをせずに単にデータを送信終了可能にする。ストリーム出力バッファは更に、ストリームデータをストアするために使用され得るメモリタイプの一例である。異なるタイプのメモリが、マイクロプロセッサにおけるキャッシュメモリのような機能性のために使用され得る時があり得る。

起動されたとき、データがパイプライン内部にあって、データが別の位置に提供する間、ストリーム出力（ＳＯ）（３８４’−２）は、プログラマがパイプラインに向かって「タップ」可能にする。

ストリーム出力（ＳＯ）（３８４’−２）は、例えばパイプラインにおける他の場所で再使用するために１つ以上の出力バッファにプリミティブをストリーミング可能であって、パイプライン内部で再帰的なプログラムアルゴリズムのアプリケーションを利用可能にする。ストリーム出力（ＳＯ）（３８４’−２）を介し送出されたデータは、バッファ（単数又は複数）に連結され得る。次にバッファ（単数又は複数）におけるデータは、その後続くパス上のグラフィックスパイプライン（３８４’−１）の入力に再循環され得る。ストリーム出力（ＳＯ）（３８４’−２）において受信されたデータは、例えばホスト又は他の操作によってリトリーブするためのバッファ又はメモリに記述され得る。

代替として、ストリーム出力（ＳＯ）（３８４’−２）において受信されたデータは、再帰的又は循環機能性を実行するために、インプットアセンブラ（ＩＡ）、バーテックスシェーダ（３８４’−１ａ_１）及び（３８４−１ａ_２）、ジオメトリシェーダ（３８４’−１ａ_３）又はピクセルシェーダ（３８４’ −１ａ_４）などのパイプライン内部の別の実体に再循環され得る（例えばフィードバック又はフィードフォワードされる）。ストリーム出力（ＳＯ）（３８４’−２）は、データが、（例えばプログラマは、（同一アルゴリズムを介しデータを再帰的に再循環する）データに再帰的な操作を実行するＧＰＵにプログラムをダウンロードし得るか、又はそうでなければ前もって固定した回数分繰り返し得る）グラフィックスパイプライン（３８４’−１）の他の一部にデータをプログラムで再循環可能にできる。ストリーム出力（ＳＯ）（３８４’−２）は、例えばシェーダ自体にデータを再循環するために使用され得、それによってマルチパス操作が、所与のデータに対し実行され得ることを可能にする。これは、グラフィックスデータに対しプログラムに従った再帰的及び循環アルゴリズムを可能にする。データを再循環する別の方法は、パイプラインを介しそれを再送信することであって、インプットアセンブラ（ＩＡ）にデータを再入力することである。

必要な場合、更に同一データがラスタライザーに進むが、情報がストリーミングされ得、こうしてデータに影響する再帰的なアルゴリズム要素に基づいた変換を実行するときにデータのレンダリングを減速させず又は画像表示を可能にする。
ラスタライザー
グラフィックスパイプライン（３８４’−１）の次のコンポーネントは、ラスタライザー（３８４’−１ｃ）である。ラスタライザー（３８４’−１ｃ）は、必ずしもグラフィックスパイプライン（３８４’−１）においてステージではないが、むしろ様々なパイプライン（３８４’−１）のステージ間のインタフェースである。ラスタライザー（３８４’−１ｃ）は、入力位置がクリップ空間において提供されると見なし、クリッピング、透視図分割、ビューポート又はシサーズ選択、プリミティブセットアップ及びピクセルシェーダ（３８４’−１ａ_４）の呼び出し方法の決定を含む重要な固定の機能操作セットを実行する。これらの機能の多くは、ソフトウェア開発者によって調整され得る。
ピクセルシェーダステージ
以下のラスタライザーは、４番目のコモンコア（３８４’−１ａ_４）であって、それは１つのピクセルを受け取り、ある位置でピクセルを出力するピクセルシェーダとして機能する。ピクセルシェーダは、各ピクセル単位で入力として例えば画像テクスチャ（又はテクスチャデータ）を含み得るショートプログラムによって処理されることを可能にする。ピクセルシェーダは、開発者がピクセルレベルで明るさ、色又は表面を変更することによって、色、テクスチャ又は形状でさえも操作可能にする。ピクセルシェーダは、各ピクセルの明るさ、色及び表面を変更するために使用され得る。これは、これらのピクセルから構築された３次元オブジェクトの色、テクスチャ及び形状すべてに対し順に影響する。

ピクセルシェーダ（３８４’−１ａ_４）に有効な入力データは、パースペクティブコレクションのあるなしに関わらず、１要素あたりを基本として補間されるように選択されるか又は定数のプリミティブ単位として処理され得るバーテックス属性を含む。ピクセルシェーダ（３８４’４４）によって生成される出力は、（現在のピクセル位置に対して１つ以上の４ベクトルピクセルが捨てられる場合、）色のない出力データであり得る。ピクセルシェーダが可能な一部のエフェクトリストは、１ピクセルあたりの明るさ、ポン（Ｐｈｏｎｇ）−スタイルシェーディングを使用するピクセルの明るさ、ＤＯＴ３エフェクト及び手続き型テクスチャを含む。
アウトプットマージャ
アウトプットマージャ（ＯＭ）においては、論理グラフィックスパイプライン（３８４’−１）の最終ステップ、他のピクセル処理機能が、最終的なピクセルをレンダリングするために実行され得る。これらの機能は、例えば出力リソース（レンダリング対象）の結合、シザーズ検査を用いたピクセルの色の値の変更、深さバイアスを介する視覚化決定及び／又はステンシルバッファ技法又はアルファブレンド又はフォグなどの機能の適用、シャドウイング、バンプマッピング、環境マッピング、アンチエイリアシング、対象（単数又は複数）をレンダリングするための書き出し又はブレンドを含み得、多くのリソースタイプ及びマルチエレメントテクスチャの１つであり得る。これらの機能をデータに対して実行後、データは、最後に更に処理されて最終的にはモニタ（１９１）上に表示される。
パイプラインにおけるシェーダ用コモンシェーダコア
図４は、コモンシェーダコア（３８４’−１ａ）のハードウェア及びソフトウェアコンポーネントの例示的で非限定的な実施形態を表すブロック図である。コモンシェーダコア（３８４’−１ａ）は、例えば図３に以前示されたバーテックスシェーダ（３８４’−１ａ_１）及び（３８４’−１ａ_２）、ジオメトリシェーダ（３８４’−１ａ_３）又はピクセルシェーダ（３８４’−１ａ_４）のいずれかを実施するために使用され得る。

コモンシェーダコア（３８４’−１ａ）は、インプットアセンブラ（ＩＡ）ユニット、グラフィックスパイプライン（３８４’−１）の任意の場所又は場合によっては特化した入力ソースからいずれかから、前のあり得るステージ入力データを受信する。

入力データは、その後、入力レジスタ（単数又は複数）（４０９）に一時的にストアされ得る。例えば入力レジスタ（単数又は複数）（４０９）は、動的インデックスアレイであり得る。ジオメトリシェーダの場合においては、入力レジスタ（単数又は複数）は、例えば [バーテックス][要素] ペアの入力を配置する２次元（２Ｄ）のアレイであり得る、
入力データは、その後、シェーダコード（４１０）に送信される。シェーダコード（４１０）は、フロー制御機構、ベクトル浮動小数点及び整数演算を処理する演算論理ユニット（ＡＬＵ）、メモリフェッチ又はサンプル操作及びシェーダ機能又は入力データに対して実行される特定の変換を指定するプログラムを提供する。またシェーダコード（４１０）は、サンプラー（４１３）、テクスチャ（４１４）及び定数バッファ（４１５）からの情報などの他のいくつかの入力又はリソースを受信し得る。シェーダコード（４１０）は、一時レジスタ（複数）（４１１）及びサブルーチンリターンアドレススタック（４１２）を用いた双方向通信もまた有する。

シェーダコード（４１０）は、テクスチャのサンプリング方法を定義するサンプラー（４１３）からサンプルを受信する。しかし、またメモリは、フィルタリングせずに読み込まれ得、サンプラーが、あらゆる実施形態において必要とは限らない。サンプラーオブジェクトが静的に作成されるため、（サンプラーオブジェクトは、それらの定義を維持していて、変更されないので）パイプライン変更を追跡又は一気に消去する必要はなく、ハードウェアは、一連のパイプラインにおける複数サンプラーの参照を維持可能にする。

シェーダコード（４１０）は、テクスチャ（４１４）からテクスチャ情報を受信する。テクスチャ（４１４）は、テクスチャのサンプリングを提供するためにシェーダコードを用いて動作する。

ＣＰＵは、特定のシェーダプログラムを再構成するために使用され得るシェーダ定数を生成する。シェーダコード（４１０）は、定数バッファ（４１５）からシェーダ定数を受信する。定数バッファ（４１５）は、ＧＰＵ上のメモリにおいて一定の変数（又は「シェーダ定数」）を統合又は分類するために提供される。言い換えると、定数入力値をストアするための定数レジスタアレイ（ｃ０．．．ｃＮ）を使用する代わりに定数バッファ（４１５）が、数値のシェーダ定数値を１つに分類するために使用され得る。定数バッファは、テクスチャ（４１４）よりも少ない待ち時間アクセス及び頻繁な更新のために最適化される。定数バッファ（４１５）は、開発者が同時に特定の定数グループすべてを設定可能し得る。定数は、開発者が所望する任意の特定の順に配置され得る。定数バッファのシェーダ定数を分類することは、一定の性能利点をもたらし得る。例えば２つのシェーダ定数は、通常同時に一緒に変更され使用され（例えば各シナリオにおいて同一のステートを有する）場合、それらのシェーダ定数は、特定の定数バッファに投入され得る。

特定のシェーダプログラムは、特定のスロットに結合されるいくつかの定数バッファを必要とし得る。一実装においては、グラフィックスパイプラインの各ステージに対し、動作中であり得る定数バッファ用の１５のスロットが存在する。シェーダコードにおいては、cb#レジスタは、「スロット」#における定数バッファのためのプレースホルダである。定数バッファは、シェーダ命令オペランドとしてcb#[index]を使用し、シェーダにおいてアクセスされ、ここでは「index」は、非インデックス（r#）又は３２ビット符号なし整数、３２ビット符号なし即値整数定数又はその２つを１つに加えられた組み合わせを含む静的インデックス（x#）のいずれかであり得る（例えば「mov r0, cb3[x3[0].x+6]」 は、x3[0].xが１を含むと仮定し、スロット３に割り当てられた定数バッファからエレメント７をr0へ移動する）。異なるハードウェアが、依然として可能な限り最も良い性能を実現することを可能にする一方、アプリケーションは、どのようなパターン及び数が望まれても定数を読むシェーダコードを記述できる。

一時レジスタ（４１１）は、一時的な記憶領域としての役目をする。例示的で非限定的な実施形態においては、一時レジスタ（４１１）は、一時記憶領域の限界まで必要とされる任意のサイズ及び数のいくつかの「非インデックス」又は「インデックス」アレイを保持し得る。

非限定で例示的なこの特定の実施形態においては、サブルーチンリターンスタック（４１２）は固定長である。更にスタックは、シェーダの直接アクセスから隠されていて、リターンアドレスだけを透過的にストアする。それは再帰的アルゴリズムの定義もまた可能にする。

コードがシェーダコード（４１０）を介し通過した後、データは、出力レジスタ（５２０）に進む。例示的で非限定的なこの実施形態においては、出力レジスタ（５２０）は、４つのベクトル出力の動的「インデックス」アレイからなる。更に、ステージの中には、追加的で特化された出力を有し得るものもある。

コモンシェーダコア（３８４’−１ａ）ステージが、グラフィックスパイプライン（３８４’−１）において実施されるに従って出力データは、その後、次のシェーダステージに存在する場合、出力ストリーム（ＳＯ）としてメモリ又は他の位置又はアウトプットマージャ（ＯＭ）又はレンダリングステージに出力され得る。

リストされたデータ構造は、１次元アレイから２次元アレイ又はリストへ変更できる。データ構造すべては、その大きさに従ってＧＰＵ能力を蓄えながら変化し得る。ＧＰＵ内部では、記憶領域の限界及び固定された大きさへの変更が、情報に対する動的割当て及び圧縮アルゴリズムアプリケーションによる空間保存のために発生し得る。サンプラー及び定数バッファは、テクスチャのように反応し得るが、リソースが変わるにつれてこれらのコンポーネントの定義は、変更され得る。テクスチャが再定義される場合、サンプラー及び定数バッファ双方が変化し得、テクスチャ機能に全く限定されない。すべてのデータ構造は更に、速度及びユーティリティ目的のための新しい最適化アルゴリズムを実施し得る。本明細書に記載された様々な実施形態は、コモンコアを使用するグラフィックスパイプラインの例に過ぎず、バーテックスシェーダ、ピクセルシェーダ及びジオメトリシェーダの機能性を提供するために動的に構成され得る。

前述のように、異なるステートの組み合わせが、様々な視覚効果を可能にする。パイプラインにおけるステート管理システムは、デバイスステートを追跡し、デバイスステートを複雑な相互依存関係を有する複数のエレメントで構成される上位レベルの「エフェクト」に抽象化する。エフェクトは、一連の「技法」として定義され、技法は「パス」に従っており、パスは、ステートオブジェクト及びシェーダに従っており、ステートオブジェクト及びシェーダは、定数バッファ及びテクスチャに従う。エフェクトは、パイプラインにおける（結合ポイントとも呼ばれる）特定の入力スロットに結合される入力として、特定のテクスチャを用いた特定の定数セット上で実行するための一定のシェーダプログラムを必要とする。ステート管理システムは、異なる様々なタイプのシェーダリソース間の関係又は依存関係の経過を保持するための「依存ツリー」を利用し得る。特定のリソース（例えば定数バッファ、テクスチャ、サンプラー）それぞれは、依存ツリーにおける親オブジェクトのスロットに結合される。この文脈においては、「スロット」は、特定のシェーダに対する依存ツリーのスロットを参照している。各シェーダは、異なる依存関係を有していて、従って独立したスロットを有するツリーに分離する。

図５Ａは、１つのエフェクトファイル（５３０）に対応する依存ツリーの例示的で非限定的なブロック図を示す。図５Ａは、エフェクト（５３０）及びパス（５２０）におけるエフェクト（５３０）の依存関係、ステートオブジェクト（５０６）、シェーダ（５１０）、テクスチャ（５１４）及び定数バッファ（５１５）の概念を示す。定数バッファ（５１５）は、いくつかのシェーダ定数（５０２）、（５０４）を受信する。ワールドビュープロジェクション行列（５０２）は、ワールド空間から画面空間に変換するために使用されるマトリクス内に４つの定数を定義するシェーダ定数である。これは１つのオブジェクト毎に実行される。このように５０個のオブジェクトが画面に存在する場合、そのマトリクスは、１シーン毎に５０回設定され得る。Ｖｌｉｇｈｔ（５０４）は、光が来る方向を指定する光ベクトルである。Ｖｌｉｇｈｔ（５０４）は、例えば太陽の方向を指定するために使用され得、全フレームに対し定数であり得る。シェーダ（５１０）は、それに関連付けられるいくつかのリソースを有する。この特定の例においては、リソースは、定数バッファ（５１５）及びテクスチャ０（５１４）を含み得る。これらのリソースは、シェーダ（５１０）によって「消費」される。図５Ａに示されないが、シェーダＡ（５１０）に加えて、並列に動作する他のいくつかのシェーダプログラム（例えばシェーダＢ、シェーダＣ、シェーダＤなど）がある。これらのシェーダプログラムそれぞれは、同様の依存関係セットを有する。パス（５２０）は、これらの異なるシェーダ及びステートＡ（５０６）の出力を含む。エフェクトファイル（５３０）は、パス（５２０）を含む。

再び図４を参照し、またコモンシェーダコア（３８４’−１ａ）は、（表示されない）いくつかの入力スロットもまた有する。シェーダ（３８４’−１ａ）によって使用されるリソース（個々の定数、定数バッファ、テクスチャ及びサンプラーなど）は、シェーダ（３８４’−１ａ）の特定の入力スロットに結合され得る。特定の一実装においては、シェーダは、例えばそれに関連付けられる１２８個の入力リソーススロット、それに関連付けられる１６個の異なる定数バッファスロット及びそれに関連付けられる１６個のサンプラースロットを有し得る。例えば特定のシェーダは、１６個の異なる定数バッファ、１６個の異なるテクスチャ及び１６個の異なるサンプラーでスロットが一杯になり得る。特定のリソースが、各シェーダの特定のスロットに割り当て又は結合される順序は、必ずしも特定のパターンに従うとは限らず、コンパイラによって決定され得る。シェーダプログラムは、これらの特定のリソースそれぞれに関する異なるものを処理する。例えばシェーダプログラムは、入力定数バッファ２、別の入力サンプラー０及び別の入力テクスチャ５などを受理し、これらの入力に従って次に特定の出力を生成し得る。

図５Ｂは、例示的で非限定的なグラフィックスパイプラインのいくつかの異なるシェーダプログラム（５８４’aA−Ｎ）にいくつかの定数バッファ（５１５Ａ〜５１５Ｅ）割り当てることを示す例示的で非限定的なブロック図である。シェーダプログラム（５８４’−１ａ−Ｎ）それぞれは、異なる入力スロットにおいて異なる順序で割り当てられたいくつかの定数バッファ（ＣＢ１ ５１５Ａ...ＣＢ５ ５１５Ｅ）を有する。例えばシェーダ（５８４’−１ａＡ）は、スロット１にＣＢ１を、スロット２にＣＢ２を、スロット３にＣＢ３を、スロット４にＣＢ４を、スロット５にＣＢ５を配置し得、シェーダ（５８４’−１ａ）は、スロット１にＣＢ２を、スロット２にＣＢ１をスロット３にＣＢ４を、スロット４にＣＢ５を、スロット５にＣＢ３を配置し得、シェーダ（５８４’−１ａＣ）は、スロット１にＣＢ５を、スロット２にＣＢ２を、スロット３にＣＢ１を、スロット４にＣＢ３を、スロット５にＣＢ４を配置し得、シェーダ（５８４−１ａＮ）は、スロット１にＣＢ３を、スロット２にＣＢ２を、スロット３にＣＢ５を、スロット４にＣＢ４を、ＣＢ１にスロット５を配置し得る。

図の簡潔化のために、図５Ｂにおいて提供される例は、特定のシェーダ（５８４’−１ａＡ〜Ｎ）それぞれと関係する４（４つ）のシェーダプログラム（５８４’−１ａＡ〜Ｎ）及び５（５つ）の可能な定数バッファ（ＣＢ１ ５１５Ａ．．．ＣＢ５ ５１５Ｅ）を示す。しかし、実用的なパイプライン大部分の実装においては、パイプラインに多くのシェーダが存在し得、特定のシェーダ（５８４’−１ａＡ〜Ｎ）それぞれが、図５に通常、示されるより多くの定数バッファを有することを十分に理解されよう。特定のアプリケーションの複雑性に従って、例えば何百もの異なるシェーダがあり得、アプリケーション開発者は、実質的には無制限数の定数バッファを指定し得る。実用的な一実装においては、これらの最大１６の定数バッファが所与の時間にシェーダそれぞれの異なるスロットで結合され得る。重要なことには、特定の定数バッファの順序は、シェーダ（５８４’−１ａ）それぞれにおいて、必ずしも特定のスロットに割り当て又は結合される特定のパターンに従う必要はなく、コンパイラによって決定され得る。

２つのシェーダプログラムが相互に独立してコンパイルされるとき、特定のスロットに結合されるリソースの順序は、異なり得る。例えばシェーダ（５８４’−１ａＡ）が実行されるとき、定数バッファ（ＣＢ１〜ＣＢ５）は、シェーダ（５８４’−１ａＡ）をレンダリングするために、スロット（１〜５）に設定される。しかし、シェーダ（５８４’−１ａＢ）が実行されるとき、同一の定数バッファ（ＣＢ１〜ＣＢ５）は、シェーダ（５８４’−１ａＢ）を実行するために異なるスロットに結合又は再割り当てられ得る。例えばシェーダ（５８４’−１ａＡ）が実行するとき、ＣＢ１はスロット１に結合され、ＣＢ２はスロット２に結合され、ＣＢ３はスロット３に結合され、ＣＢ４はスロット４に結合され、ＣＢ５はスロット５に結合されるが、次のシェーダ（５８４’−１ａＢ）が実行するとき、同一の５つの定数バッファもまた再び使用され得るが、今度は異なるスロット（例えばスロット１にはＣＢ２、スロット２にはＣＢ１、スロット３にはＣＢ４、スロット４にはＣＢ５、スロット５にはＣＢ３）において再び使用され得る。そのような場合、定数バッファは、実行しているシェーダ（５８４’−１ａＡ）とシェーダ（５８４’−１）ａＢ）と間の遷移の間、１つのスロットから結合が解除され、新しいスロットに再結合される必要がある。同一の５つの定数バッファそれ自体は、異なる順序で再結合される必要がある。ビデオカードなどをセットアップするドライバーが呼び出される必要があるので、毎回結合が再調整される必要がある度に、性能コストが存在する。シェーダ間のこの「disagreement（不調和）」を緩和するための自動的な仕組みは存在せず、従ってシェーダ間の遷移が発生するとき、不要なパイプライン再構成をもたらし、結合サイクルが浪費される。

シェーダ間の切り換え時、グラフィックスカードにおいて必要とされる再構成数を低減及び／又は最小化（例えばスロットを再結合する際、通常、発生するステート変更を低減及び／又は最小化）することが望まれる。例えば異なるスロットに特定のリソースを再び割り当てる必要性を回避又は低減するための方法を提供することが望まれる。同一スロットにリソースを一貫し配置することによって、より少ない結合サイクルが浪費され及び／又は結合サイクルが節約される。

スロット／リソース結合最適化技法
シェーダ間の切り換え時、グラフィックスカードにおいて必要とされる結合の再構成数を低減／最小化する（例えばスロット再結合の際、通常発生するステート変更を低減及び／又は最小化する）ために、一定のスロットにリソース（例えば定数バッファ、テクスチャ及びサンプラー）を最適に結合するための技法を提供する。これらの技法によってシェーダプログラムそれぞれの間の一般的な依存関係が決定され得、この決定に基づいて特定のスロットが特定のリソースに結合され得る。依存ツリーは、異なるシェーダリソース間の関係又は依存関係の経過を保持する。特定のリソースそれぞれは、依存ツリーにおける親オブジェクトのスロットに結合される。開示されたこれらの技法は、依存関係走査及び依存ツリー再構成を含んでいて、シェーダがリソース結合される所において、それらの期待値を変更し得る。その結果、現在ロードされたシェーダ間を遷移するために再結合される必要があるスロット数が低減及び／又は最小化され得る。

これらの技法の一実施形態に従って依存ツリー内の依存関係それぞれが走査され、関連付けのコストは、依存ツリーの異なる再構成（シェーダの再配置又は再構築）それぞれに対して計算され得る。依存ツリーの再構成それぞれは、結合されている一定のリソースの特定スロットを変更する。依存ツリーの特定の再構成は、これらのコストを使用し、その後、より上位レベルのステート間を遷移するために装置の再構成数を低減又は最小化するものが選択され得る。言い換えると、現在ロードされたシェーダ間を遷移／切り替えるために再結合される必要があるスロット数を最小化する依存ツリーの特定の再構成が、次に選択され得る。一実装においては、これらの技法は、オフラインコンテンツの生成及び記憶領域のために実行され得る（例えば設定されるシェーダが前もって知られている場合、シェーダは分析され、依存関係が再配置され、次にシェーダはディスクに逆に保存される）。代替の実装においては、本方法は（例えば設定されるシェーダが前もって知られていない場合）、アプリケーションの実行時／ロード時、動的に実行され得る。

それに応じて特定のシェーダプログラムが、一定のリソースを同一の順序で期待するために変更される。これによって、例えば定数バッファが特定のスロットに関連付けられる方法の最適化する効果がある。これは、異なるシェーダ間を切り換えるときに発生する再構成数を低減することによって、実行させる必要がある仕事量を減らす。

図６は、グラフィックスパイプラインにおいてシェーダに関連付けられる特定のスロットにリソースを最適に結合するための例示的で非限定的な流れ図（６００）を示す。特定のアプリケーション実行の間、シェーダは、シェーダの特定のスロットに結合されるために、一定数のリソース（例えば定数バッファ、テクスチャ及びサンプラーなど）を要求し得る。

ステップ（６１０）においては、各シェーダによって利用されているリソース間のリソースの依存関係が決定され得る。一実施形態においては、ステップ（６１０）は、２つのサブステップ（６１５）、（６２０）を含み得る。サブステップ（６１５）においては、各シェーダに対する特定のリソース／スロット割り振りが決定され得る。各シェーダに対する特定のリソース／スロット割り振りは、どのリソースが各シェーダの特定のスロットそれぞれにおいて使用されるかを指定する。サブステップ（６２０）においては、特定のリソース／スロット割り振りに基づいて、各シェーダによって利用されているリソース間の（例えば異なる／コモン）リソースの依存関係が決定され得る。

ステップ（６３０）においては、リソース依存関係に基づいて、コモンリソース／スロット関連付けが計算され得る。コモンリソース／スロット関連付けそれぞれは、シェーダ間切り換え時、リソース再構成の複数の遷移／ステート変更／数が低減／最小化するように、特定のスロットの１つに関連付けられる特定のリソースの１つを指定する。ステップ（６４０）において、各スロットに結合されるリソースはその後、シェーダそれぞれにおいてコモンリソース／スロット関連付けに従って再構成され得る。この点においては、各シェーダは、同一のコモンリソース／スロット関連付けを有し、各シェーダにおいて、特定の同一のリソースは、特定の同一のスロットの１つに関連付けられる。ステップ（６５０）においては、特定のリソースそれぞれは、コモンリソース／スロット関連付けによって指定される特定のスロットに結合され得る。

図７は、コモンリソース／スロット関連付けを計算するための例示的で非限定的な流れ図（６３０）を示す。ステップ（７１０）においては、第１のスロットに結合される特定のリソースの１つが決定され得る。第１のスロットに結合されるリソースを決定した後、ステップ（７２０）において、第１のスロットに結合されるこのリソースが、プール又はリスト又は利用可能リソースから除外され得る。ステップ（７３０）においては、プロセスは、各シェーダに対して結合されるスロットが満たされたか決定し得る。残りの結合されるスロット（例えば結合されるリソースをまだ有していないスロット）が存在する場合、ステップ（７４０）においては、残りのリソースの１つが、第２のスロットに結合することを決定され得る。ステップ（７２０）〜（７４０）は、所定のスロット数まで繰り返されて、結合されるスロットの大部分又はスロットすべては、それと関連付けられる特定のリソースを有する。一実施形態においては、特定のコストの測定基準が満たされるまで本アルゴリズムは、適用され得る。例えばコスト測定基準は、本アルゴリズムがシェーダ間の例えばリソース変更又は相違点の６０パーセントよりも少数になるとき、停止することがあり得る。一旦、結合されたスロットすべてがリソース／スロット結合を有すると、その後、プロセスは、図６のステップ（６４０）に続く。

図８は、特定のリソース／スロット結合を決定するための例示的で非限定的な流れ図（７１０）／（７４０）を示す。ステップ（８１０）においては、第１のスロットに結合される第１のリソースを決定するために、第１のスロットに依存ツリー内の各リソースを結合するためのコストが、各シェーダによって利用されているリソース間の依存関係に基づいて計算され得る。ステップ（８２０）においては、最小コストを有する特定のリソースの１つが、第１のスロットに結合するために選択され得、ステップ（８３０）においては、この（最小コストを有するものとして選択される）リソースが、第１のリソースとして指定され得る。ステップ（８１０〜８３０）が、図７のステップ（７４０）中に組み込まれているので、ステップ（８１０〜８３０）が、結合されるスロットそれぞれが特定のリソース／スロット結合を有するまで繰り返されることを十分に理解されよう。

図９は、第１のスロットに各リソースを結合するためのコストを計算するための例示的で非限定的な流れ図（８１０）を示す。
ステップ（９１０）においては、特定のリソースの１つが第１のスロットに結合される場合、各シェーダをレンダリングするために要求されるステート変更数が決定され得る。この決定は、シェーダプログラムそれぞれによって利用されているリソース間のリソース依存関係を使用することによって実行され得る。ステップ（９２０）においては、特定のリソースの１つが第１のスロットに結合される場合、各シェーダをレンダリングするために要求されるｗａｓｔｅｄ（浪費）スロット数が決定され得る。前述のようにこの決定は、シェーダプログラムそれぞれによって利用されているリソース間のリソース依存関係を使用することによって実行され得る。ステップ（９３０）においては、ステート変更数及び浪費スロット数を使用し、第１のコストが計算され得る。この第１のコストは、第１のスロットに特定のリソースの１つを結合することに関連するコストである。

この計算（例えば第１のスロットにリソースそれぞれの１つを結合することに関連するコスト）は、各リソースに対して繰り返され得る。ステップ（９４０）においては、第１のスロットにリソースそれぞれを結合するためのコストが計算された場合、それが決定され得る。そうでなければ、その後プロセスは、リソースリスト又は依存ツリー内の次の特定のリソースの１つが選択されるステップ（９５０）に進む。その後、ステップ（９１０〜９３０）は、次のリソース（例えば第１のスロットに次のリソースを結合することに関連するコスト）に対して繰り返され得る。ステップ（９４０）においては、第１のスロットにリソースそれぞれを結合するための計算されたコストが決定されるまで、プロセス（８１０）が繰り返される。この時点でプロセスは、終了するか又はステップ（８２０）に戻る。ステップ（９１０〜９５０）が図８のステップ（８１０）に組み込まれているので、ステップ（９１０〜９５０）が、結合されるスロットそれぞれに各リソースを結合するためのコストが決定されるまで繰り返されることを十分に理解されよう。

このように図５Ｂに示される例においては、前述の技法は、シェーダ（５８４’−１ａＢ）に使用される定数バッファのレイアウトを再配置するために使用され得る。例えば、依存関係すべてが走査され、最適の定数バッファ割り付けがシェーダ（５８４’−１ａＡ）に示されるものであることが決定された場合、シェーダ（５８４’−１ａＢ）においては、それぞれＣＢ２及びＣＢ３がスロット２及び３に結合されるように再配置され、一方、ＣＢ１がスロット１に再配置され得、ＣＢ４及びＣＢ５がスロット４及び５に再配置され得る。シェーダ（５８４’−１ａＡ）と（５８４’−１ａＢ）との間の切り替えの間、この方法は、シェーダ（５８４’−１ａＡ）に示されるスロットにＣＢすべての初期結合を超えたいかなる追加作業も要求しない。同様の再配置もまた、シェーダ（５８４’−１ａＣ）及びシェーダ（５８４’−１ａＮ）において起こり得る。現在ロードされたシェーダ間の切り換えのために、再結合される必要があるスロット数それ自体が最小化される。

本発明の方法を実装する複数の方法、アプリケーション及びサービスが、強化されたグラフィックスパイプライン発明のシステム及び方法を使用可能にするような、例えば適切なＡＰＩ、ツールキット、ドライバーコード、オペレーティングシステム、コントロール、単独動作又はダウンロード可能なソフトウェアオブジェクトなどが存在する。本発明は、ＡＰＩ（又は他のソフトウェアオブジェクト）の見地からの他に、本発明によるコモンコア、ジオメトリシェーダ又はストリーム出力技法を含む前述の任意の技法の受信するソフトウェア又はハードウェアオブジェクトもまた本発明の使用を想定する。このように本明細書に記載された発明の様々な実装は、ハードウェア全体、ハードウェアの一部及びソフトウェアの一部の他に、ソフトウェアにもまた存在する特徴を有し得る。

前述のように様々な計算装置及びネットワークアーキテクチャに関連し本発明の例示的な実施形態を説明してきたが、基本的な概念が、強化されたグラフィックスパイプラインを用いてＧＰＵを使うことが望まれる任意の計算装置又はシステムに適用され得る。例えば、本発明のアルゴリズム（単数又は複数）及びハードウェア実装は、計算装置のオペレーティングシステムに適用され得、装置上の個別のオブジェクトとして、別のオブジェクトの一部として、再利用可能なコントロールとして、サーバからダウンロード可能オブジェクトとして、装置又はオブジェクトとネットワークとの間の「仲介人」として、分散オブジェクトとして、メモリ中のハードウェアとして、前述の任意の組み合わせその他として提供される。例示的なプログラミング言語、名称及び例が様々な選択肢の代表として本明細書において選択されているが、これらの言語、名称及び例が限定されることを意図しない。当業者は、本発明の様々な実施形態によって達成される同一の、同様の又は同等の機能性を実現するオブジェクトコード及び用語体系を提供する多くの方法が存在することを理解されよう。

言及したように、本明細書に記載の様々な技法は、ハードウェア又はソフトウェア又は適切な所においては双方の組み合わせと関連して実装され得る。このように本発明の方法及び装置又は一定の特徴又はその一部は、プログラムコード（すなわち命令）の実体のある媒体に具現化されたフロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ、ハードドライブ又は他の任意の機械可読記憶媒体などの形式を取り得、そのプログラムコードが計算機などのマシンによってロードされ実行されるとき、そのマシンが本発明を実施するための装置になる。プログラム可能な計算機上でプログラムコードを実行する場合には、計算装置は一般に、プロセッサ、そのプロセッサによって読み出し可能な（揮発性及び不揮発性メモリ及び／又は記憶装置エレメントを含む）記憶媒体、少なくとも１つの入力装置及び少なくとも１つの出力装置を含む。強化された本発明のグラフィックスパイプライン技法を例えばデータ処理ＡＰＩ、再利用可能コントロール又はその他の使用を介し実施又は利用できる１つ以上のプログラムが、計算機システムと通信するための高水準手続き型又はオブジェクト指向プログラミング言語で望ましくは実装される。しかし、所望であれば、プログラム（単数又は複数）は、アセンブリ言語又は機械語で実装され得る。どのような場合においても、言語は、コンパイルされ得るか又はインタプリタ言語であり得、ハードウェアの実装に結合され得る。

また本発明の方法及び装置は、電気配線又はケーブル上、光ファイバを介するようないくつかの伝送媒体を通して送信されるプログラムコード形式で具現化される通信を介するか又は他の任意形式の伝送を介し実施され得、そのプログラムコードは、ＥＰＲＯＭ、ゲートアレイ、プログラム可能な論理回路（ＰＬＤ）、クライアント計算機その他のようなマシンによって受信され、ロードされ、実行され、そのマシンは、本発明を実施するための装置になる。汎用プロセッサ上で実装されるとき、プログラムコードは、本発明の機能性を呼び出すために作動する固有の装置を提供するプロセッサと結合する。本発明に関連して使用される任意の記憶装置技術は更に、不変的なハードウェアとソフトウェアとの組み合わせであり得る。

本発明が様々な図の好ましい実施例に関連し説明されたが、他の同様な実施形態が使用又は修正され得、追加のものは、それらから逸脱せずに本発明の同一の機能を実行するための記載の実施形態として説明され得ることを理解されよう。例えば本発明の例示的なネットワーク化された環境は、ピアツーピアネットワーク環境のようなネットワーク環境の文脈で記載されているが、当業者は、本発明がそれに限定されないこと、本願に記載されているような方法が、ゲームコンソール、ハンドヘルド計算機、携帯用計算機その他のような任意の計算装置又は有線か無線かに関わらない環境に対して適用可能であって、通信ネットワークを介し接続されたそのような様々な計算装置に適用され得、ネットワークを横断して対話することを認識されよう。更に、ハンドヘルドデバイスオペレーティングシステム及び他のアプリケーションスペシフィックオペレーティングシステムを含む様々な計算機プラットフォームは特に、無線ネットワーク化された装置の数が増殖し続けているとして想定される。

例示的な実施形態は、グラフィックスパイプラインの文脈で本発明を利用することを参照するが、本発明はそれに限定されず、むしろ第２の処理ユニットを提供するように実施され得る。例えばＣＰＵを使用し別の機能を実行する間、プログラマが、画面に表示のレンダリング及び計算数学処理を所望する場合、処理ユニットは、グラフィックス表示が最終的な出力に含まれるか否かに関係なく最大限に利用される必要があり得る。それでも更に本発明は、複数のプロセッシングチップ又は装置内部又はそれらを横断して実装され得、記憶装置は、複数の装置を横断して同様に作用され得る。従って本発明は、任意の単一の実施形態に制限される必要はないがむしろ添付の請求に従った大きさ及び範囲に解釈されるべきである。

本発明が実施され得る様々な計算装置を有する例示的なネットワーク環境を表すブロック図である。 本発明が実施され得る例示的で非限定的な計算装置を表すブロック図である。 グラフィックスプロセッシングユニット（ＧＰＵ）と、関連する例示的なグラフィックスパイプライン用ハードウェア構成を含むグラフィックスサブユニットと、を含む例示的なグラフィックスシステムを示す。 コモンシェーダコアのハードウェア及びソフトウェアコンポーネントの例示的で非限定的な実施形態を表すブロック図である。 依存ツリーの例示的で非限定的なブロック図を示す。 例示的で非限定的なグラフィックスパイプラインにおけるいくつかの異なるシェーダプログラムにいくつかの定数バッファの配分を示す例示的で非限定的なブロック図である。 グラフィックスパイプラインにおけるシェーダに関連する特定のスロットにリソースを最適に結合するための例示的で非限定的な流れ図を示す。 コモンリソース／スロット関連付けを計算するための例示的で非限定的な流れ図を示す。 リソース／スロット結合を決定するための例示的で非限定的な流れ図を示す。 第１のスロットに各リソースを結合するためのコストを計算するための例示的で非限定的な流れ図を示す。

Claims (20)

1. グラフィックスパイプライン（３８４’−１）において、シェーダ（５８４’−１）に関連付けられる特定のスロットにリソースを結合するための方法（６００）であって、
   各シェーダによって利用されているリソース間のリソース（４１３〜４１５）依存関係を決定するステップ（６２０）と、
   コモンリソース／スロット関連付けを前記リソース（４１３〜４１５）依存関係に基づいて計算するステップ（６３０）であって、コモンリソース／スロットそれぞれの関連付けが、前記特定のスロットの１つに関連付けられるべき前記特定のリソース（４１３〜４１５）の１つを指定するものと、を含む方法。
2. 各シェーダによって利用されているリソース間のリソース依存関係を決定するステップが、
   各シェーダに対する特定のリソース／スロット割り振りを各シェーダにおいて決定するステップであって、各シェーダに対する前記特定のリソース／スロット割り振りが、各リソースの特定のスロットそれぞれにおいて、どのリソースが使用されるかを指定するものと、
   各シェーダによって利用されているリソース間のリソース依存関係を前記特定のリソース／スロット割り振りに基づいて決定するステップと、を含む請求項１記載の方法。
3. コモンリソース／スロット関連付けを計算するステップが、
   コモンリソース／スロット関連付けを前記リソースの依存関係に基づいて計算するステップであって、コモンリソース／スロット関連付けそれぞれが、シェーダ間の切り換え時、リソース再構成コストが低減されるように、前記特定のスロットの１つに関連付けられる前記特定のリソースの１つを指定するもの、を含むことを特徴とする請求項２記載の方法。
4. 更に、
   前記コモンリソース／スロット関連付けに従って、各スロットに結合される前記リソースを前記シェーダそれぞれにおいて再構成するステップを含む請求項３記載の方法。
5. コモンリソース／スロット関連付けを計算するステップが、
   （ａ）第１のスロットに結合される前記リソースのうち特定の１つを決定するステップと、
   （ｂ）第２のスロットに結合される前記残りのリソースのうち特定の１つを決定するステップと、
   所定数の前記スロットがそれと関連付けられる前記リソースの１つを有するまで残りのスロットそれぞれに対し、ステップ（ｂ）を繰り返すステップと、を含むことを特徴とする請求項３記載の方法。
6. 第１のスロットに結合される第１のリソースを決定するステップが、
   各シェーダによって利用されているリソース間の前記リソース依存関係に基づいて、前記第１のスロットに各リソースを結合するためのコストを計算するステップと、
   最小コストを有する特定のリソースの１つを選択するステップと、
   前記第１のリソースとして、前記最小コストを有するものとして選択されるリソースを指定するステップと、を含むことを特徴とする請求項５記載の方法。
7. 第２のスロットに結合される第２のリソースを決定するステップが、
   前記第２のスロットに前記残りのリソースそれぞれを結合するためのコストを計算するステップと、
   最小コストを有する前記残りのリソースを選択するステップと、
   前記第２のリソースとして、前記最小コストを有するものとして選択される前記残りのリソースを指定するステップと、を含むことを特徴とする請求項６記載の方法。
8. 前記第１のスロットに各リソースを結合するためのコストを計算するステップが、
   （ａ）前記特定のリソースの１つが、前記第１のスロットに結合される場合、各シェーダプログラムによって利用されているリソース間の前記リソース依存関係に基づいて、各シェーダをレンダリングするために要求されるステート変更の数を決定するステップと、
   （ｂ）前記特定のリソースの１つが、前記第１のスロットに結合される場合、各シェーダプログラムによって利用されているリソース間の前記リソース依存関係に基づいて、要求される浪費スロットの数を決定するステップと、
   （ｃ）前記ステート変更数及び前記浪費スロット数に基づいて、前記第１のスロットに前記特定のリソースの１つを結合することに関連する第１のコストを計算するステップと、
   前記第１のスロットに前記リソースそれぞれを結合するためのコストが計算されるまで、ステップ（ａ）から（ｃ）を繰り返すステップと、を含むことを特徴とする請求項６記載の方法。
9. 更に、
   コモンリソース／スロット関連付けによって指定された前記特定のスロットに前記特定のリソースそれぞれを結合するステップを含む請求項１記載の方法。
10. 各シェーダが、同一の前記コモンリソース／スロット関連付けを有していて、各シェーダにおいて前記特定の同一リソースが、前記特定の同一スロットの１つに関連付けられることを特徴とする請求項１記載の方法。
11. 前記リソースが、定数バッファを含むことを特徴とする請求項１記載の方法。
12. 前記リソースが、定数バッファ、少なくとも１つのテクスチャ及びサンプラーを含むことを特徴とする請求項１記載の方法。
13. 請求項１記載の方法を実行するための計算機実行可能命令を含む計算機可読媒体。
14. 請求項１のステップを実行するための計算機実行可能モジュールを含むグラフィックスアプリケーションプログラミングインタフェース。
15. 請求項１記載の方法を実行するためにグラフィックスプロセッシングユニットに命令するためのアプリケーションプログラミングインタフェース。
16. 複数のリソースを含む依存ツリーを再構成する方法であって、特定のリソースそれぞれが、前記依存ツリーの親オブジェクトのスロットに結合されることを特徴とするものが、
    前記依存ツリーの前記リソース依存関係それぞれを走査するステップと、
    前記依存ツリーの複数の異なるリソース構成それぞれに関連付けられるコストを計算するステップと、
    異なるシェーダ間の切り換え時、デバイス再構成数を最小化する前記依存ツリーの特定のリソース再構成を選択するステップと、を含むことを特徴とする方法。
17. 前記依存ツリーのリソース再構成それぞれが、一定のリソースが結合されている特定のスロットを変更することを特徴とする請求項１６記載の方法。
18. 異なるシェーダ間の切り換えのために、再結合される必要があるスロット数を最小化する前記依存ツリーの特定のリソース再構成を選択するステップを含むことを特徴とする請求項１６記載の方法。
19. 前記方法がオフラインコンテンツ生成のために実行され、更に、前記依存ツリーの特定のリソース再構成をストアするステップを含むことを特徴とする請求項１６記載の方法。
20. 前記方法がアプリケーション実行時／ロード時に動的に実行されることを特徴とする請求項１６記載の方法。

Images