アプリケーションのためにビデオフレームレンダリング特性の最適化を可能にする方法、システム、グラフィカルコンピュータインタフェース、および計算機可読媒体が開示される。前記方法は、ビデオフレームをレンダリングするステップと、前記ビデオフレームの前記レンダリングを表すプッシュバッファ設定をキャプチャするステップと、を有する。また、前記方法は、前記アプリケーションをバイパスすることにより前記プッシュバッファ設定のアスペクトを変更するステップと、前記変更されたアスペクトにより前記フレームを再レンダリングするステップと、も有する。更に、前記方法は、前記レンダリングを前記再レンダリングと比較するステップと、比較結果を提示するステップと、を有する。アプリケーションのコードを変更せずに、パフォーマンス、レンダリングおよび処理の効率に関して、可能な変更の、アプリケーションに対する寄与を評価するための機能を可能にするグラフィカルユーザインタフェースが提供される。

【発明の詳細な説明】
【背景技術】
【０００１】
現在、開発者は、骨の折れる工程によって、ゲームアプリケーションを最適化し、デバッグしなければならない。開発者はアプリケーションコードを変更してからこのアプリケーションコードを再実行しなければならず、この作業は、ゲームの開発工程に極めて長い時間を追加しかねない。
【０００２】
更に、現在の工程では、開発者は、アプリケーションにおける特定のレンダリングアスペクトの最適化調査にフォーカスすることはできない。
【０００３】
このため、開発者は、試行錯誤のデバッグ工程と最適化工程を余儀なくされている。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
これらの問題に鑑みて、開発者は、インテリジェントな最適化アルゴリズムと解析手法によって、迅速かつ効率的にグラフィックプロセッサの使用を最適化できることを求めている。また、開発者は、グラフィック関連のバグまたはパフォーマンスの非効率を効率的に特定し、解決するために必要な情報を求めている。
【課題を解決するための手段】
【０００５】
概して、本発明は、開発者が、アプリケーションのレンダリングアスペクトを効率的に最適化できるようにする方法および装置を提供することによって、これらのニーズを満たす。本発明は、方法、システム、計算機可読媒体または装置などの多くの方法で実施できる点を理解すべきである。以下に本発明のいくつかの発明の実施形態を記載する。
【０００６】
一実施形態では、アプリケーションの実行中に生成される複数フレームビデオシーケンスのフレームに対してパフォーマンス分析を実行するためのシステムが提供される。前記システムは、前記アプリケーションを実行するように構成されたハードウェアエンジンと、前記ハードウェアエンジンから、前記複数フレームビデオシーケンスの前記フレームをレンダリングするためのプッシュバッファデータを取得するように構成されたライブラリキャプチャモジュールと、を有する。更に、前記システムは、前記プッシュバッファデータの内容のインタラクティブな表示を提示するためのグラフィカルユーザインタフェースも有する。前記内容は、複数のコマンドと、前記複数のコマンドのそれぞれに関連するデータとを定義する。前記グラフィカルユーザインタフェースは、前記プッシュバッファの前記内容の変更を行うためのアクセスを可能にする。また、前記システムは、前記グラフィカルユーザインタフェースによって行われる変更により、前記プッシュバッファデータの再実行を可能する再生モジュールも有する。前記グラフィカルユーザインタフェースは、前記プッシュバッファに変更が行われた場合に、前記プッシュバッファの実行の差を定量化する複数のパフォーマンス分析測定を提供する。
【０００７】
本実施形態の一態様では、前記グラフィカルユーザインタフェースは、前記アプリケーションの変更を実行せずに、前記プッシュバッファデータに変更を行うために前記アクセスを可能にする。さらなる態様では、前記グラフィカルユーザインタフェースは、前記複数のパフォーマンス分析測定を表すための複数のメニューおよびウィンドウを提供し、前記複数メニューおよびウィンドウの特定のものを選択することにより、前記プッシュバッファデータの前記内容に対する変更が可能となり、前記結果を定量的に表示し、パフォーマンスのアスペクトを視覚的に表示する。
【０００８】
別の実施形態では、アプリケーションのためにビデオフレームのレンダリング特性を最適化するための方法が提供される。前記方法は、ビデオフレームをレンダリングするステップと、前記ビデオフレームの前記レンダリングを表すプッシュバッファ設定をキャプチャするステップと、を有する。また、前記方法は、前記アプリケーションをバイパスすることにより前記プッシュバッファ設定のアスペクトを変更するステップと、前記変更されたアスペクトにより前記フレームを再レンダリングするステップと、も有する。更に、前記方法は、前記レンダリングを前記再レンダリングと比較するステップと、比較結果を提示するステップと、を有する。
【０００９】
更に別の実施形態では、ビデオフレームレンダリングを最適化するためのグラフィカルユーザインタフェース（ＧＵＩ）が提供される。前記ＧＵＩは、プッシュバッファの内容を示す表示領域と、前記プッシュバッファの前記内容に従って前記ビデオフレームをレンダリングすることに対するグラフィカルな結果を示すパフォーマンス表示領域と、を有する。また、前記ＧＵＩは、プッシュバッファ内容変更領域も有する。
【００１０】
本発明の他の態様および利点は、例示のために本発明の原理を示す添付の図面と併せて、以下の詳細な説明を読めば明らかとなるであろう。
【００１１】
本発明とその更なる利点とは、添付の図面を参照して以下の記載を読めば、よりよく理解できるであろう。
【図面の簡単な説明】
【００１２】
【図１】本発明の一実施形態による、ゲームコンピューティングコンソールの各種ハードウェア要素およびソフトウェア要素のコンポーネントを定義する、グラフィックハードウェアエンジンを備えたゲームコンピューティングコンソールを示す概略説明図。
【図２】本発明の一実施形態による、ゲームコンピューティングコンソールが、ＧＣＭツールとグラフィックハードウェアエンジンとの両方の処理の実行に使用される代替の実施形態を示す概略説明図。
【図３】本発明の一実施形態による、ＧＣＭツールとインタフェースされているグラフィックエンジンのより詳細な図を示す概略説明図。
【図４】本発明の一実施形態による、ＧＣＭツールを使用して実行されうるオペレーションを定義するプロセスフローチャートを示す概略説明図。
【図５】本発明の一実施形態による、プッシュバッファを介してキャプチャされうる各種リソースを示す概略模式図である。
【図６】本発明の一実施形態による、ＧＣＭツールからキャプチャされた情報を提供するグラフィカルユーザインタフェース（ＧＵＩ）ウィンドウを示す概略模式図である。
【図７】図６のドロー／クリアウィンドウを更に定義するグラフィカルユーザインタフェースを示す概略模式図である。
【図８】図７のウィンドウの展開表示説明図である。
【図９】本発明の一実施形態による、ロウビューウィンドウ３０２およびその内容を示す概略模式図である。
【図１０】本発明の一実施形態による全ての警告およびエラーの概要を示す問題ウィンドウを示す概略説明図。
【図１１】本発明の一実施形態によるプッシュバッファ概要画面を示す概略説明図。
【図１２】本発明の一実施形態による、全ての状態コマンドのリストおよび状態コマンドごとの冗長の割合を有する詳細冗長ウィンドウを示す概略説明図。
【図１３Ａ】図６のレンダリング状態ウィンドウに関連する更に詳細な情報を有する概略模式図である。
【図１３Ｂ】図６のレンダリング状態ウィンドウに関連する更に詳細な情報を有する概略模式図である。
【図１４Ａ】本発明の一実施形態による、プッシュバッファによって使用されるテクスチャを示す概略説明図。
【図１４Ｂ】本発明の一実施形態による、プッシュバッファによって使用されるテクスチャを示す概略説明図。
【図１４Ｃ】本発明の一実施形態による、プッシュバッファによって使用されるテクスチャを示す概略説明図。
【図１４Ｄ】本発明の一実施形態による、プッシュバッファによって使用されるテクスチャを示す概略説明図。
【図１５】本発明の一実施形態による、テクスチャのメモリビューを提供するメモリダンプウィンドウを示す概略説明図。
【図１６】本発明の一実施形態による、プッシュバッファによって使用される頂点配列を示す概略説明図。
【図１７】本発明の一実施形態による、プッシュバッファによって使用されるインデックス配列を示す概略説明図。
【図１８】本発明の一実施形態による、フラグメントプログラムウィンドウを示す概略模式図である。
【図１９Ａ】本発明の一実施形態による、プッシュバッファで使用されている全てのプログラムの一覧を示し、解釈されたダンプを提供する頂点プログラムウィンドウを示す概略説明図。
【図１９Ｂ】本発明の一実施形態による頂点プログラム定数ウィンドウを示す概略説明図。
【図２０Ａ】本発明の一実施形態によるＧＰＵ内のレジスタの状態を詳細に示すＧＰＵレジスタウィンドウを示す概略説明図。
【図２０Ｂ】本発明の一実施形態によるＧＰＵ内のレジスタの状態を詳細に示すＧＰＵレジスタウィンドウを示す概略説明図。
【図２１Ａ】本発明の一実施形態による、レンダリングターゲットウィンドウを更に定義する説明図。
【図２１Ｂ】本発明の一実施形態による、レンダリングターゲットウィンドウを更に定義する説明図。
【図２１Ｃ】本発明の一実施形態による、レンダリングターゲットウィンドウを更に定義する説明図。
【図２１Ｄ】本発明の一実施形態による、レンダリングターゲットウィンドウを更に定義する説明図。
【図２１Ｅ】本発明の一実施形態による、レンダリングターゲットウィンドウを更に定義する説明図。
【図２１Ｆ】本発明の一実施形態による、レンダリングターゲットウィンドウを更に定義する説明図。
【図２１Ｇ】本発明の一実施形態による、レンダリングターゲットウィンドウを更に定義する説明図。
【図２１Ｈ】本発明の一実施形態による、レンダリングターゲットウィンドウを更に定義する説明図。
【図２１Ｉ】本発明の一実施形態による、レンダリングターゲットウィンドウを更に定義する説明図。
【図２１Ｊ】本発明の一実施形態による、レンダリングターゲットウィンドウを更に定義する説明図。
【図２１Ｋ】本発明の一実施形態による、レンダリングターゲットウィンドウを更に定義する説明図。
【図２２】本発明の一実施形態による、開発者がプロファイラのアスペクトを選択するメニューの概略模式図を示す概略説明図。
【図２３Ａ】本発明の一実施形態によるプロファイルの例示的なグラフィカル表示を示す概略説明図。
【図２３Ｂ】本発明の一実施形態によるプロファイルの例示的なグラフィカル表示を示す概略説明図。
【図２４Ａ】本発明の一実施形態による、分析に使用することができるパフォーマンスカウンタ用のグラフィカルユーザインタフェースを示す概略説明図。
【図２４Ｂ】本発明の一実施形態による、分析に使用することができるパフォーマンスカウンタ用のグラフィカルユーザインタフェースを示す概略説明図。
【図２５Ａ】本発明の一実施形態による、フレームのレンダリングを最適化するためのカリングプロセスを示す概略説明図。
【図２５Ｂ】本発明の一実施形態による、フレームのレンダリングを最適化するためのカリングプロセスを示す概略説明図。
【図２５Ｃ】本発明の一実施形態による、フレームのレンダリングを最適化するためのカリングプロセスを示す概略説明図。
【図２５Ｄ】本発明の一実施形態による、フレームのレンダリングを最適化するためのカリングプロセスを示す概略説明図。
【図２６Ａ】本発明の一実施形態による、各種「仮定」パフォーマンス最適化を適用した場合に、開発者が行う作業のシーケンスを示す概略説明図。
【図２６Ｂ】本発明の一実施形態による、各種「仮定」パフォーマンス最適化を適用した場合に、開発者が行う作業のシーケンスを示す概略説明図。
【図２６Ｃ】本発明の一実施形態による、各種「仮定」パフォーマンス最適化を適用した場合に、開発者が行う作業のシーケンスを示す概略説明図。
【図２６Ｄ】本発明の一実施形態による、各種「仮定」パフォーマンス最適化を適用した場合に、開発者が行う作業のシーケンスを示す概略説明図。
【図２６Ｅ】本発明の一実施形態による、各種「仮定」パフォーマンス最適化を適用した場合に、開発者が行う作業のシーケンスを示す概略説明図。
【図２６Ｆ】本発明の一実施形態による、各種「仮定」パフォーマンス最適化を適用した場合に、開発者が行う作業のシーケンスを示す概略説明図。
【図２６Ｇ】本発明の一実施形態による、各種「仮定」パフォーマンス最適化を適用した場合に、開発者が行う作業のシーケンスを示す概略説明図。
【図２６Ｈ】本発明の一実施形態による、各種「仮定」パフォーマンス最適化を適用した場合に、開発者が行う作業のシーケンスを示す概略説明図。
【図２６Ｉ】本発明の一実施形態による、各種「仮定」パフォーマンス最適化を適用した場合に、開発者が行う作業のシーケンスを示す概略説明図。
【図２６Ｊ】本発明の一実施形態による、各種「仮定」パフォーマンス最適化を適用した場合に、開発者が行う作業のシーケンスを示す概略説明図。
【図２６Ｋ】本発明の一実施形態による、各種「仮定」パフォーマンス最適化を適用した場合に、開発者が行う作業のシーケンスを示す概略説明図。
【図２６Ｌ】本発明の一実施形態による、各種「仮定」パフォーマンス最適化を適用した場合に、開発者が行う作業のシーケンスを示す概略説明図。
【図２６Ｍ】本発明の一実施形態による、各種「仮定」パフォーマンス最適化を適用した場合に、開発者が行う作業のシーケンスを示す概略説明図。
【図２６Ｎ】本発明の一実施形態による、各種「仮定」パフォーマンス最適化を適用した場合に、開発者が行う作業のシーケンスを示す概略説明図。
【図２６Ｏ】本発明の一実施形態による、各種「仮定」パフォーマンス最適化を適用した場合に、開発者が行う作業のシーケンスを示す概略説明図。
【図２７Ａ】本発明の一実施形態による、「試験例」とも呼ばれうるパフォーマンス最適化を示し、これは、レンダリング中のゲームまたはアプリケーションの最適な設定の推奨を提供するために、１つ以上の「仮定」またはパフォーマンス最適化を行いうる。
【図２７Ｂ】本発明の一実施形態による、「試験例」とも呼ばれうるパフォーマンス最適化を示し、これは、レンダリング中のゲームまたはアプリケーションの最適な設定の推奨を提供するために、１つ以上の「仮定」またはパフォーマンス最適化を行いうる。
【図２７Ｃ】本発明の一実施形態による、「試験例」とも呼ばれうるパフォーマンス最適化を示し、これは、レンダリング中のゲームまたはアプリケーションの最適な設定の推奨を提供するために、１つ以上の「仮定」またはパフォーマンス最適化を行いうる。
【図２７Ｄ】本発明の一実施形態による、「試験例」とも呼ばれうるパフォーマンス最適化を示し、これは、レンダリング中のゲームまたはアプリケーションの最適な設定の推奨を提供するために、１つ以上の「仮定」またはパフォーマンス最適化を行いうる。
【図２７Ｅ】本発明の一実施形態による、「試験例」とも呼ばれうるパフォーマンス最適化を示し、これは、レンダリング中のゲームまたはアプリケーションの最適な設定の推奨を提供するために、１つ以上の「仮定」またはパフォーマンス最適化を行いうる。
【図２８】グラフィックをレンダリングするために使用されうるハードウェア構成の例を提供するが、本発明は任意のタイプまたはブランドのアーキテクチャに限定されない。
【発明を実施するための形態】
【００１３】
フレームのレンダリングのためのグラフィックハードウェアによって生成されるプッシュバッファデータにアクセスできるようにするグラフィックコマンド管理（ＧＣＭ）ツールのための発明が開示される。ＧＣＭツールは、システム、方法として定義され、コンピュータ可読媒体に実施されうる。概して、ＧＣＭツールは、特定の１つ以上のフレームに対するプッシュバッファデータをキャプチャして、何らかの方法で変更し、再レンダリングのためのグラフィックハードウェアに再送信できるようにし、プッシュバッファデータを生成させたアプリケーションのコードを変更することなくパフォーマンスへの影響を決定する機能を備える。
【００１４】
以下の説明では、本発明を完全に理解できるように、具体的な詳細を数多く記載する。しかし、これらの詳細な内容の一部または全てを用いなくとも本発明を実施しうることは当業者にとって自明である。場合によっては、本発明を不必要にわかりにくくしないように、公知のプロセス操作については詳しく記載しない。
【００１５】
明確化のために、「プッシュバッファ」との用語は、コンピュータアーキテクチャで一般に使用されるバッファ構造を定義するものとし、「コマンドバッファ」とも呼ぶことができる。また、「フレーム」との用語は、アプリケーションの実行中にグラフィックハードウェアによって生成される複数フレームの動的ビデオシーケンスの複数のフレームの所定のフレーム（またはフレームの組）を指す。一例では、この複数のフレームは、ビデオゲームコンソールまたは標準的なパーソナルコンピュータによって提供されるものなど、ハードウェア上でのビデオゲームアプリケーションの実行中に生成されるフレームである。フレームフォーマットは、高解像度または低解像度を問わず、どのようなフォーマットをとってもよい。高解像度フレームでは、フレームコンテンツの解像度は、任意の数のフォーマットであってもよく、例えば、１０８０ｉ／ｐのＨＤＴＶフォーマットおよび他の高解像度ビデオ規格などであるが、これらに限定されない。本明細書に記載するアプリケーションはゲームタイプのアプリケーションに着目しているが、これらの技術は、プッシュバッファデータに応答してデータをレンダリングする、どのようなアプリケーションにも同様に適用できることを理解すべきである。
【００１６】
ＧＣＭツールは、アプリケーションの１つのフレーム中に使用される、あらゆるグラフィカルリソースをキャプチャすることが可能である。このツールは、キャプチャしたフレームに対してパフォーマンス分析を実行し、ゲームアプリケーションまたはゲームエンジン（例えば、ミドルウェア）に根本的な変更が行われた場合を模倣して、プッシュバッファおよび他のグラフィカルリソースを変更して、パフォーマンスを再測定することができる。概して、ＧＣＭツールは、ゲームアプリケーションまたはゲームエンジンのコードの面倒な変更を実際に行うことなく、ゲームアプリケーションまたはゲームエンジンにコード変更が行われたと仮定して、パフォーマンスがどの程度向上するか（または影響を受けるか）を定義することができる。例えば、ゲームアプリケーションおよび／またはゲームエンジンの変更の中には、技術者が変更に、数日、数週間あるいは数ヶ月要するものがあり、このような変更は、パフォーマンスの向上が得られるかどうかのテストを見込んでいる。
【００１７】
本発明の態様によれば、ＧＣＭツールは、アプリケーションまたはエンジンのコードを変更することなく、プッシュバッファデータに直接変更を行い、パフォーマンスの利得が得られるかを分析し、その後、アプリケーションおよび／またはエンジンに行うことができる推奨されるコードの変更を定義し、実際のアプリケーションの変更に時間と高価なリソースを消費する前に、予め決定され、検証されている予想される利得を事前に知ることができる。
【００１８】
以下の出願は、２つの部分、すなわち、（Ｉ）のシステム概要と、（ＩＩ）の機能的な画面の説明に分けられる。
Ｉ．ＧＣＭツール構造のシステム概要
【００１９】
図１は、ゲームコンピューティングコンソール１００の各種ハードウェア要素およびソフトウェア要素のコンポーネントを定義している、グラフィックハードウェアエンジン１０２を備えたゲームコンピューティングコンソール１００を示す。グラフィックハードウェアエンジン１０２は、プッシュバッファ１０４およびレンダリングフレーム１０６の処理を実行する（charged with processing）。説明の便宜上、複数のプッシュバッファ１０４が、アプリケーションの異なる部分が処理される（例えば、インタラクティブゲーム再生中）と時間の経過に伴ってレンダリングされる生成フレーム１０６と関連付けられて図示されている。また、ゲームコンピューティングコンソール１００と通信しているコンピュータワークステーション１０８も図示されている。
【００２０】
本発明の一実施形態では、コンピュータワークステーション１０８（例えば、パーソナルコンピュータ（ＰＣ））に、グラフィックコマンド管理（ＧＣＭ）ツール１１０（例えば、ユーティリティプログラム）が読み込まれており、ＧＣＭツール１１０は、特定のフレーム１０６をレンダリングするためにグラフィックハードウェアエンジン１０２によって処理されている特定のプッシュバッファ１０４にアクセスするように設計されている。説明したように、三次元（３Ｄ）レンダリングハードウェアはプッシュバッファ（またはコマンドバッファ）によって駆動され、プッシュバッファは、レンダリング状態を制御し、テクスチャ、頂点データなどのリソースの場所を指定するコマンドのシーケンスを格納している線形バッファである。ＧＣＭツール１１０はユーティリティとして機能し、３つの主要コンポーネント（例えば、図３に示すＧＵＩ１３０、ライブラリキャプチャモジュール１３２、および再生モジュール１３４）によって定義される。ＧＣＭツール１１０は、特定のプッシュバッファ１０４ａをキャプチャすると、プッシュバッファデータに変更を行い、次に、変更後のプッシュバッファによって生成されるフレームを再レンダリングさせるために、変更後のプッシュバッファデータをグラフィックハードウェアエンジン１０２に再送信することができる。
【００２１】
次に、ＧＣＭツール１１０は、グラフィックハードウェアエンジン１０２に再送信された、変更後のプッシュバッファデータによるパフォーマンスへの影響（向上または低下）を監視することが可能である。変更後のプッシュバッファデータのパフォーマンス特性に対するこの分析は、変更されるプッシュバッファデータを生成したアプリケーションを実際に修正したり、このアプリケーションを必要とせずに行うことができる。ＧＣＭツール１１０に関する更なる詳細は、図３を参照して下で説明する。
【００２２】
図２は、ゲームコンピューティングコンソール１１０が、ＧＣＭツール１１０とグラフィックハードウェアエンジン１０２との両方の処理の実行に使用される代替の実施形態を示す。この実施形態では、プッシュバッファデータに行う変更の修正、分析および検証を行うために、プッシュバッファデータ１０４にアクセスできるようにするために、ゲームコンピューティングコンソール１１０と通信する独立したコンピュータワークステーション１０８を備える必要はない。
【００２３】
図３は、本発明の一実施形態による、ＧＣＭツール１１０とインタフェースされているグラフィックエンジン１０２のより詳細な図を示す。アプリケーション１２０は、アプリケーション１２０に実装されているコードを処理するように構成されたグラフィックハードウェアエンジン１０２とインタフェースされて図示されている。アプリケーション１２０が、アプリケーションコードと、時にゲームエンジンと呼ばれる任意のミドルウェアまたはアプリケーションエンジンとの両方を含むことがあることを理解すべきである。アプリケーションおよびゲームエンジンを実装するコードは、合わせて「アプリケーション１２０」と呼ばれることもある。
【００２４】
アプリケーション１２０は、関数呼び出し１２２と一体化されており、関数呼び出し１２２は、グラフィックハードウェアエンジン１０２によるアプリケーション実行の特定の時点で、プッシュバッファデータのキャプチャをトリガするように設計されている。一実施形態では、関数呼び出し１２２は、グラフィックハードウェアエンジン１０２のプッシュバッファに生成され、その後、グラフィックコマンド管理（ＧＣＭ）ツール１１０のライブラリキャプチャモジュール１３２に転送されるコマンドリストを傍受することができるハートビート関数呼び出しとして定義されうる。
【００２５】
一実施形態では、関数呼び出し１２２は、通信ポートを開き、キャプチャされたコマンドリストをデータ配列の形で送信し、これをライブラリキャプチャモジュール１３２が受け取る。その際、キャプチャされたフレームの元のデータ配列が、ライブラリキャプチャモジュール１３２によって、オペレーション１５２で受信されオペレーション１５４で処理される。次に、関数呼び出しに応答してキャプチャされた現在のプッシュバッファの内容を示すために、処理した元のデータ配列がライブラリ１５６に記憶される。このため、グラフィックハードウェアエンジン１０２が、フレーム１０６ａのレンダリングに関連するパフォーマンス統計をプッシュバッファ１０４ａからＧＣＭツール１１０に転送および伝達している間に、ライブラリ（例えば、一種のデータベース）は、プッシュバッファの内容を保持する。
【００２６】
これらのパフォーマンス特性は、ＧＣＭツール１１０に関連する、再生モジュール１３４のパフォーマンスモニタ１６０に送信される。このため、再生モジュール１３４のパフォーマンスモジュール１６０は、パフォーマンス情報を、ＧＣＭツールグラフィカルユーザインタフェース（ＧＵＩ）１３０に伝達する。処理を最初から開始するため、ユーザは、ＧＣＭ ＧＵＩ１３０を使用して、コマンド（メニューまたはＧＵＩボタンから利用）を選択することができ、これにより、１３６においてプッシュバッファのキャプチャがトリガされ、特定のフレーム１０６ａが、プッシュバッファの内容に基づいて、パフォーマンスについて分析されうるように、関数呼び出しに、特定のプッシュバッファまたは複数のプッシュバッファをキャプチャさせる。
【００２７】
デバッグエンジニアが、キャプチャされた特定のプッシュバッファの構造および内容を迅速に見つけ特定することができ、かつ、理解することができるように、ＧＣＭ ＧＵＩ１３０では、ディスプレイ１３８が、プッシュバッファの内容を、表形式およびグラフィック形式で表示できるようにする。また、ＧＵＩ１３０は、キャプチャされたプッシュバッファ構造において、特定のデータの削除、挿入、修正および移動を可能にするためにプッシュバッファ１４０の内容を変更することもできる。プッシュバッファの内容を変更することによって可能となる特定のタイプの処理には、「Ｗｈａｔ−Ｉｆ」（仮定）処理１４２の処理が含まれてもよい。仮定処理については、後で更に詳細に説明する。
【００２８】
追加の処理には、キャプチャされたプッシュバッファの特定の内容（例えば、コマンドおよびデータ）に対して最適化が実行できるように試験的実行１４４が含まれてもよい。また、ＧＣＭ ＧＵＩ１３０には、パフォーマンスモニタ１６０によってＧＣＭ ＧＵＩ１３０に提供された特定のパフォーマンスパラメータの分析を可能にするパフォーマンス表示が含まれる。
【００２９】
パフォーマンス表示には、多くのメニュー、ウィンドウ、グラフ、チャート、および元の状態のプッシュバッファの内容と、ＧＣＭ ＧＵＩ１３０の１４０によって変更が実行されたあとのプッシュバッファの内容との比較を可能にする比較ツールが含まれる。これらのパフォーマンス表示およびインタフェースの例は、プッシュバッファの特定の内容を変更し、プッシュバッファデータの特定の変更によって得られるパフォーマンスの利得か、パフォーマンスへの悪影響を比較することによるプロファイルを実行するための機能を備えうる。このため、後からアプリケーションの変更を推奨できるように、プロファイリング１４８では、グラフィック形式および表形式で結果を表示させることができる。
【００３０】
新しい参照点に対して、プッシュバッファへの変更を保持することが望ましい場合、プッシュバッファの内容に行われうる追加の変化のための参照点として、プッシュバッファへの現在の変更を参照することができるように、パフォーマンス表示から、ユーザが、プッシュバッファデータをコミットすることができる。このため、コミットボタン１５０は、グラフィカルユーザインタフェース１３０のパフォーマンス表示を使用した、プログラマおよびデバッグ担当者のための選択肢となる。また、ＧＣＭツール１１０の一部として、ライブラリキャプチャモジュール１３２も図示されている。
【００３１】
上で説明したように、データがライブラリ１５６に記憶できるように、キャプチャされたフレームの元のデータ配列が１５２において受信され、次に１５４において処理される。ライブラリは、ＧＵＩ１３０がアクセスし、インデックス付け可能なように、プッシュバッファの構造およびデータを保持する。このため、ＧＵＩ１３０は、ライブラリの構造を知っており、ＧＵＩによって、メニュー、ウィンドウ、グラフ、チャートおよび比較が迅速に作成され、ユーザによる情報収集、比較および分析のために表示される。
【００３２】
ユーザが、ＧＵＩ１３０を使用して、プッシュバッファの内容を変更することによって変更を行いたい場合は、ＧＵＩ１３０は再生モジュール１３４と通信し、この結果、プッシュバッファの変更が、グラフィックハードウェアエンジン１０２に再送信され、新しいプッシュバッファ１０４ａ’が定義され、これによりフレーム１０６ａ’の更新後のレンダリングが行われる。また、更新後のプッシュバッファデータを用いたフレームの再レンダリング中に、グラフィックハードウェアエンジン１０２は、その更新されたプッシュバッファデータのレンダリングに関連するパフォーマンスデータを、パフォーマンスモニタ１６０に提供する。このため、パフォーマンスモニタ１６０はＧＵＩ１３０にこの情報を伝達し、ユーザがＧＵＩ１３０の１４６においてパフォーマンスの表示および分析を行うことができるようになる。
【００３３】
図４は、本発明の一実施形態による、ＧＣＭツール１１０を使用して実行されうるオペレーションを定義するプロセスフローチャート２００を示す。上で説明したように、グラフィックハードウェアエンジン１０２は、アプリケーション１２０のためにプッシュバッファデータを処理し、フレームをレンダリングするように設計されている。アプリケーション１２０は、アプリケーションコードに単に追加され、各フレームに関連付けられている関数呼び出し１２２を有する。この結果、レンダリングされた各フレームのプッシュバッファへのアクセスが可能となり、グラフィックハードウェアエンジン１０２によってレンダリングされるフレーム毎にキャプチャ行うことができる。
【００３４】
一実施形態では、ＧＣＭツールＧＵＩ１３０は、特定のプッシュバッファ（後で特定のフレームをレンダリングする）を選択するように、特定の時点で、プッシュバッファ（およびフレームのために使用されるリソース）のキャプチャをトリガさせるように設計されている。フレームの選択は、ＧＵＩ１３０により、ユーザの選択によって開始されうる。この例では、この特定のプッシュバッファはプッシュバッファ１０４ａであり、レンダリングされるフレームはフレーム１０６ａである。このため、アプリケーションに埋め込まれた関数呼び出しが、フレーム１０６ａに対するプッシュバッファ１０４ａの内容をキャプチャさせ、コピーとしてグラフィックコマンド管理ツール１１０に送信させる。この転送は、プッシュバッファの内容１０４ａのコピーをグラフィックコマンド管理ツール１１０に送信する矢印で示される。
【００３５】
オペレーション２０２において、プッシュバッファの内容がキャプチャされる。キャプチャされると、処理がオペレーション２０４に移動し、キャプチャされたプッシュバッファデータのパフォーマンス特性が分析され、オペレーション２０６において、この分析に基づき、キャプチャされたプッシュバッファの少なくとも１つのアスペクトが変更されうる。当然、さまざまなアスペクトの１つ以上が変更されてもよいが、例えば、１つのアスペクトのみが変更されると仮定する。その後、オペレーション２０８において、再レンダリングのために、アスペクトが変更されているプッシュバッファデータが、グラフィックハードウェアエンジン１０２に再送信される。
【００３６】
オペレーション２１０において、プッシュバッファ内のアスペクトが変更されて再レンダリングされたフレームに対してパフォーマンス特性が分析される。次に、方法はオペレーション２１２に移動し、プッシュバッファ内でアスペクトが変更されていない場合と比べ、変更後のアスペクトを使用したときに、フレームのレンダリングにおけるパフォーマンスへの影響（利得または悪影響）があるかどうかが判定される。上で説明したように、これらのパフォーマンス特性は、図３を参照して記載したＧＵＩ１３０の１４６における分析のために、多くのパフォーマンス表示を使用して分析することができる。
【００３７】
オペレーション２１４において、変更後のアスペクトを、プッシュバッファにコミットすべきかどうかが判定される。コミットした場合、基準として使用されるプッシュバッファが、変更をコミットしたプッシュバッファとなる。「はい」の場合、方法はオペレーション２１６に移動し、新しいプッシュバッファの内容が、プッシュバッファのアスペクトに追加の変更を行う際のパフォーマンスへの影響を比較する参照点となる。変更されたアスペクトをコミットしない場合、オペレーションはオペレーション２１８に移動し、プッシュバッファの別のアスペクトを変更するかどうかが判定される。
【００３８】
変更したい場合、方法はオペレーション２０６に戻り、分析が完了するまで処理を続けることができる。変更する別のアスペクトが存在せず、他が全て、テスト担当者の満足するように完了している場合、方法はオペレーション２２０に移動しうる。オペレーション２２０では、プッシュバッファデータを作成するアプリケーションコードに変更を行ない、アプリケーションを変更せずに行ったプッシュバッファデータの分析時に特定された予想されるパフォーマンスの利得を得るための、推奨の変更が生成されうる。その後、この情報は、後からアプリケーションコード１２０に組み込むために、アプリケーション開発者２４０に送ることができる。
【００３９】
本明細書において記載される実施形態に関して、ＧＣＭツール１１０は、プッシュバッファのローレベルフォーマットにアクセスする。この元の状態では、フォーマットは、例えばＵ−３２フォーマットのデータ配列として受信され、表示、変更を可能にするためにフォーマット化され、グラフィックハードウェアエンジン１０２に再送信するために元の状態に再びフォーマット化される。このため、ＧＣＭツール１１０を使用することで、外部レンダリングＡＰＩまたはドライバ層を用いずに、プッシュバッファを変更により書き換えることができる。プッシュバッファは、コマンドの削除、挿入または修正のために変更することができ、他のリソースも、同様に、移動、削除または修正することができる。変更後は、変更を行ったプッシュバッファおよびリソースが、グラフィックハードウェアに戻され、変更の影響を評価するために、パフォーマンス測定が行われうる。更に、試験例、またはより複雑なパフォーマンス分析を実行するために、変更とパフォーマンス測定が自動化されて繰り返されてもよい。
【００４０】
ＧＣＭツール１１０によって可能な機能により、いくつかの特徴的な利点が与えられる。利点の一例として、キャプチャされたアプリケーションのプッシュバッファを、元のアプリケーションから独立して操作できることが挙げられる。このため、ＧＣＭツール１１０は、結果をプロファイリングし、パフォーマンスの最適化を行うために、アプリケーションコードの変更とビルドを繰り返す手間（tedium）を省く。１つのレンダリング状態を変更するなどの単純なアプリケーションの変更でさえ、多くの場合、アプリケーションをリビルドするのに多大な繰返し作業時間を要する。
【００４１】
このような簡潔な置き換えに加えて、ＧＣＭツール１１０は、アプリケーション内のテストのために、多大なプログラミングの時間と複雑なデータの変更を要するパフォーマンス測定を簡略化するために、多くの非リアルタイム技術を適用することができる。第一に、キャプチャされたプッシュバッファに対し最適なパフォーマンス設定を決定するために、パラメータの組がとりうる全ての状態をテストするために、自動化された繰返しを適用することができるが、手動での繰返しは法外に時間がかかる。第二に、プッシュバッファおよびリソースを、比較的遅い力任せのアルゴリズムを使用して、または１つのフレームに対してのみ有効である（例えば、視点依存関係のため）最適化を使用して処理することができる。
【００４２】
これにより、開発者は、通常は、多大なプログラミング時間とソースデータの変更が必要となるアプリケーションの最適化から得られる潜在的なパフォーマンスゲインを迅速に決定できるようになり、最適化の作業を最も集中させるべき箇所を決定できるようになる。
【００４３】
更に、元のアプリケーションは、このような後のパフォーマンス試験例に関与しないため、元のソースコードまたはデータにアクセスすることなく、キャプチャされたデータを容易に転送および分析することができ、サポートプログラマが、開発チームによるアプリケーションの分析を容易に支援できるようにする。
【００４４】
別の実施形態では、関数呼び出しコードをアプリケーションに組み込むことを要求する代わりに、本発明の一態様は、（例えば、独立したハードウェアロジックとして）グラフィックハードウェアエンジン１０２とインタフェースするか、あるいはグラフィックグラフィックハードウェアエンジン１０２と一体化されたキャプチャトリガハードウェアロジックの組み込みを可能にする。このキャプチャトリガハードウェアロジックは、アプリケーション１２０に組み込まれた関数呼び出し１２２と同じように、あるいは同様に、プッシュバッファデータのキャプチャをさせるための命令を受け取ることができる。キャプチャトリガハードウェアロジックを提供することによって、ＧＣＭツール１１０は、グラフィックハードウェアエンジン１０２のロジック（または１０２とインタフェースするハードウェア）とインタフェースするだけで、プッシュバッファデータのキャプチャをトリガでき、このプッシュバッファデータは、ライブラリキャプチャモジュール１３２に送られる。キャプチャトリガハードウェアロジックを使用する利点は、プログラマがアプリケーションにコードを追加する必要がなく、このため、ＧＣＭツール１１０とのインタフェースが、アプリケーション１２０のプログラマにシームレスであり伝達され、またトランスパレントである点が挙げられる。しかし、組込み関数呼び出し１２２を使用する実施形態では、関数呼び出しを行うためのコードはごく最小限であり、わずかなプログラムのオーバーヘッドで、あるいはオーバーヘッドなしで、簡単に挿入することができる。
【００４５】
ＧＣＭツール１１０は、最小限の時間の投入で、いずれも最適化と呼ばれうる多くのパフォーマンス試験例または仮定の実行を、キャプチャされたプッシュバッファに対して実行できるようにする。試験例の一覧を表Ａに挙げるが、これらに限定されない。

表Ａ
−冗長コマンド−何らの有用な影響を与えないコマンドをプッシュバッファから除去することによって、ＧＣＭツールは、冗長コマンドの数を削減するコード変更が、パフォーマンスを向上させるかどうかを判定することができる。同様に、パラメータが最適化されていない一部のコマンド、または最適化されていないレンダリング状態の組み合わせが検出され、調整されて、パフォーマンスゲインを得るためにテストされうる。
−レンダリング状態の最適化−パフォーマンス、および得られる視覚的な影響について、キャプチャされたプッシュバッファの最適な設定を決定するために、パフォーマンスに関連する多くのレンダリング状態が変更されうる。これには、テクスチャフィルタリング、深度のカリング、および他の同様の状態が含まれる。
−リソース位置−ＧＣＭツールは、ビデオメモリとメインメモリ間でリソースを移動させることによって、これらの位置の調整によりパフォーマンスが向上するかを判定することができる。
−頂点配列構造−複数のストリームに分割される頂点データがインターリーブされ、パフォーマンスへの影響がテストされうる。
−未使用の頂点配列データ−未使用の属性を削除するために頂点配列を最適化することができる。
−定数頂点配列データ−定数の属性を検出するために頂点配列をスキャンし、最適化して、これを削除することができる。
−未使用の頂点プログラムの出力データ−未使用であるが、無効にされていない頂点プログラム出力が無効にされうる。
−メッシュの最適化−メッシュ頂点およびインデックスデータが、変換後の完全なキャッシュパフォーマンスのために最適化されるか、非インデックス形式からインデックス形式に変換されるか、リスタートインデックスを使用するために最適化されうる。
−三角形のトリミング−良好なアプリケーションカリングまたは良好なメッシュ構造のパフォーマンスへの影響を決定するために、オフスクリーン、背面、縮退またはゼロピクセルの三角形を、入力頂点配列およびインデックス配列から個別に削除することができる。
−深度ソーティング−アプリケーションのオブジェクトソーティングの最適化によりパフォーマンスが改善するかを判定するために、最適な深度カリングのために、全ての非アルファブレンディング描画呼び出しが再ソートされうる。
−深度のみのパス−ＧＣＭツールは、フラグメント処理を最小限に抑えるために、色バッファを別個にレンダリングする前に、最初にシーンのための深度バッファをレンダリングする共通の最適化テクニックを複製しうる。
−フラグメントプログラムレジスタカウントの最適化−ＧＣＭツールは、最適な値を決定するために、フラグメントプログラムごとに、取りうる全てのレジスタカウントのパフォーマンスを評価することができる。
−代替テクスチャ圧縮フォーマット−テクスチャ圧縮がパフォーマンスおよび視覚的外観に影響するかどうかを判定するために、テクスチャを代替フォーマットに変換する。
−テクスチャメモリのグループ化−ビデオメモリとメインメモリ間でのリソースの最適な分配を決定するために、描画呼び出しに基づくテクスチャの全ての可能な関連するメモリグループ化がテストされうる。
−頂点プログラムのグループ化−頂点プログラムのセットへの最適なグループ化を決定し、頂点プログラムセットコマンドを実行スロットの変更に変換するパフォーマンスの利得を分析する。
−ターゲットタイリングおよび深度カリングエリアのレンダリング−アプリケーション最適化の潜在的な利得を決定するために、色および深度バッファのタイリング、圧縮、ならびに深度カリングエリアパラメータが最適化されうる。
−頂点プログラムの最適化−頂点配列が最適にパックされるか、または、静的な分岐を有する１つのプログラムが、最適化された別個のプログラムに置換されるように、頂点プログラムが変更されうる。
ＩＩ．ＧＣＭツールの画面の機能的な定義
【００４６】
下記に記載する実施形態は、開発者がゲーム開発プロセス中に使用しうるツールまたはユーティリティに関して詳細に説明する。ＧＣＭツールによって可能となる機能を、開発者がツールとインタフェースするために使用することができる各種スクリーンショットを参照して、更に詳細に定義する。ＧＣＭツールはライブラリを備え、これがゲームおよびアプリケーションにリンクされる。ゲーム側からみると、開発者がＧＣＭツールライブラリをリンクすると、ＧＣＭの再生の初期化と、ｇｃｍＳｅｔＦｌｉｐまたは同様の関数の毎回の呼び出しの後のＧＣＭの再生の２つの呼び出しが発生する。この２つの呼び出しに関連するオーバーヘッドはゼロに近いため、これらの呼び出しは常に残すことができる。上で説明したように、開発者がｇｃｍＲｅｐｌａｙツールを使用したいときは常に、開発者はアプリケーションを起動して、キャプチャを選択する。アプリケーションでキャプチャを選択すると、レンダリング中の画像データのフレームに対するプッシュバッファの内容がキャプチャされる。「キャプチャ」とは、アプリケーションに送信されている、レンダリング中に使用される全リソースの内容を取得することを指す。これらのリソースには、テクスチャ、頂点配列、インデックステーブル、およびデータのフレームのレンダリングに必要な他のリソースが含まれる。一実施形態では、前のフレームのバッファが含まれてもよい。例えば、前のフレームバッファの内容が、何らかのブラーリング効果が適用されて含まれてもよい。グラフィック表示のレンダリング中にキャプチャされるデータおよび使用される全てのリソースが、１００メガバイトを容易に超えうる点に留意すべきである。
【００４７】
ゲームによっては、キャプチャプロセスが複雑になることがあることを当業者は認めるであろう。例えば、グラフィック処理装置がフレームをレンダリングしているときに、例えばＰＬＡＹＳＴＡＴＩＯＮ（登録商標）３ゲームコンソール用のＣＥＬＬプロセッサなどの別のプロセッサが、プッシュバッファを変更し、および新しいリソースを作成することがある。このため、本明細書に記載する実施形態は、画像データのフレームのレンダリング用のプッシュバッファの内容全体をキャプチャするため、グラフィック処理装置を単一ステップ実行する、いわゆるシングルステッピングによって、プッシュバッファをキャプチャする。ＧＰＵの単一ステップ実行とコマンドバッファの変更情報のキャプチャは、目立たないように、すなわちアプリケーションに透過的に実行される。単一ステップ実行は、プッシュバッファ内の命令を、この命令の直前にＧＰＵの実行を停止するために、自己命令へのジャンプで置換することによって行われる。次の命令を自己へのジャンプで逐次的に置換し、その後元の命令に戻すことによって、命令ごとに、ＧＰＵの実行を停止することができ、各命令によって使用される全リソースの現在の状態の収集が可能となる。グラフィック処理装置の単一ステップ実行により、フレームのレンダリング中に、プッシュバッファの内容が変更または上書きされるかどうかが無関係となる。本実施形態が、シミュレーションとは対照的にグラフィック処理装置を使用する点に留意すべきである。更に、キャプチャされるデータが、リアルタイムのＧＰＵパフォーマンス分析からのデータよりも、多くの詳細な分析を提供する。本明細書に記載の実施形態は、特定のゲームコンソールを指しているが、本実施形態は、画像をレンダリングするために使用される任意のゲームコンソールに適用できるため、これは例示に過ぎないという点に留意すべきである。
【００４８】
図５は、本発明の一実施形態による、プッシュバッファを介してキャプチャされうる各種リソースを示す概略模式図である。プッシュバッファ１０４は、頂点プログラムおよびフラグメントプログラム、レンダリングターゲット、頂点バッファおよびインデックスバッファ、テクスチャなどを表すデータを含む。これらのリソースが、それぞれＧＣＭツールによってキャプチャされ、開発者が、開発工程を最適化するために、データを後から操作できるようになる。上で説明したように、ゲームのレンダリングプロセスが非常に複雑な場合であっても、ここに記載の実施形態はデータをキャプチャすることができる。一実施形態では、グラフィック処理装置がフレームをレンダリングしているときに、別のプロセッサ（例えばＣＥＬＬプロセッサ）がプッシュバッファを変更し、新規リソースを作成しうる。
【００４９】
通常、ＣＥＬＬプロセッサは、グラフィック処理装置に同期して頂点配列またはインデックステーブルを作成している。このため、フレームの開始時に存在しない頂点配列はフレームの初期に作成され、ＧＰＵが、このフレームの後の部分でこの配列を使用できるようになる。更に、キャプチャプロセスは、フレームの経過中に上書きされうるデータをキャプチャ可能でなければならない。例えば、データがリングバッファに書き込まれる場合、フレームのレンダリングの過程で、後のキャラクタのデータにより、以前のキャラクタのデータが上書きされる。データの全てをキャプチャするため、本明細書に記載する実施形態は、適当なデータをキャプチャするためにグラフィック処理装置を単一ステップ実行する。
【００５０】
一実施形態では、プッシュバッファの内容が前のステップの内容と比較され、新しいデータがキャプチャされる。このため、一態様では、ＧＣＭツールは、リアルタイムで実行することができない機能に着目する。キャプチャされたデータによって数多くのことができる点を理解すべきである。一実施形態では、開発者が、データを閲覧し、分析することができる。また、データを、ハードディスクまたは他の記憶装置に保存し、調査のために別の開発者に送信することもできる。別の実施形態では、本明細書に記載されているように、開発者によってフレームが再生され、プロファイリングされる。
【００５１】
フレームを再生する際に、レンダリングの分析を実行する間に、フレームがＧＣＭツールにダウンロードされ、再レンダリングされうる。変更時のパフォーマンスを分析できるように、プッシュバッファおよびキャプチャされたリソースがさまざまな方法で変更されうる。下記に詳述する「仮定」機能によって、プッシュバッファの１つのアスペクトが変更されうる。更に、複数のアスペクトに対する最適な動作条件およびシーケンスの分析を提供するために、下で更に詳細に記載する「試験例」によって、プッシュバッファの複数のアスペクトが組織化された方法で変更されうる。
【００５２】
図６は、本発明の一実施形態による、ＧＣＭツールからキャプチャされた情報を提供するグラフィカルユーザインタフェース（ＧＵＩ）ウィンドウを示す概略模式図である。図６のグラフィカルユーザインタフェースは、レンダリング呼び出しを有するドロー／クリアウィンドウ３００、プッシュバッファの内容を示すロウビューウィンドウ３０２、レンダリングターゲットウィンドウ３０４、出力ウィンドウ３０６、プッシュバッファ概要ウィンドウ３０８およびレンダリング状態ウィンドウ３１２を有する。ＧＣＭツールによって提示される他の例示的なグラフィカルユーザインタフェースの詳細は、図７〜２５Ｄを参照して後で詳細に説明する。
【００５３】
上で説明したように、データのキャプチャは、ユーザがキャプチャボタンを選択／トリガするグラフィカルユーザインタフェースによって行われる。当然、レンダリングプロセスの全フレームを、ここに記載する実施形態によってキャプチャすることができる。しかし、１つおきのフレームまたはｎ（ｎは整数）おきのフレームをキャプチャすることができるように、キャプチャをカスタマイズすることもできる。
【００５４】
レンダリングされるフレームごと、または他の指定の頻度でアプリケーションに挿入される呼び出し関数が、ＧＰＵを単一ステップ実行することによって、プッシュバッファの内容のキャプチャをトリガし、図６のグラフィカルユーザインタフェースの生成を可能にするという点に留意すべきである。開発者は、デバッグ工程を容易にするために、呼び出し関数に任意にアノテーション（注釈）を追加して、レンダリング中のアプリケーションの特定のアスペクトを指定することができるという点に更に留意すべきである。図６は、一例示的な構成であり、必要に応じて変更することができる。例えば、ユーザが、図７〜２５Ｄに示すいずれかのＧＵＩを図６に組み込むことを望む場合には、これを行うことができる。
【００５５】
図７は、図６のドロー／クリアウィンドウを更に定義するグラフィカルユーザインタフェースを示す概略模式図である。ドロー／クリアウィンドウ３００は、全てのドローコンテキストの一覧を示しており、ドローコンテキストビューと呼ばれることもある。フレームのレンダリングのために、数千ものクリアオペレーションとドローオペレーションが存在しうるという点が理解されるべきである。ドロー／クリアウィンドウ３００によって、プッシュバッファを閲覧する主要な手段が提供される。ドロー／クリアウィンドウ３００にキャプチャされたドローコンテキストは、ドロー／クリアコマンドと、その関連するセットアップ空間を表しているという点を理解すべきである。ウィンドウ３００の特定のドローコンテキストを選択すると、ドローコンテキストウィンドウが、図８のドローコンテキストウィンドウ３００ａに示すように展開する。
【００５６】
特定のドローコンテキストをダブルクリックするか、ウィンドウ３００の左側の列にある展開ボタンをシングルクリックすることによって、図７のドローコンテキストウィンドウ３００を展開することができることを当業者は認めるであろう。ウィンドウ３００ａの展開された内容は、プッシュバッファを作成するために使用された個々のｌｉｂｇｃｍ呼び出しを示す。ここで、特定のフレームレンダリングプロセスについて、予想される呼び出しが存在するかどうかを開発者は閲覧することができる。
【００５７】
一実施形態では、セットされている深度関数などの各種ＧＰＵ状態と、これに続き、三角形をレンダリングするための実際のコマンドを閲覧することができる。このため、図８のウィンドウ３００ａ内で、ドローコンテキストが展開され、元のＧＣＭ ＡＰＩ呼び出しが表示される。更に、ソースレベル逆アセンブリには、パラメータ名および定数名を参照することができるアノテーション付引数が含まれる。更に、最適化プロセスを更に支援するために、ユーザ指定のプッシュバッファアノテーションも示されうる。一実施形態では、冗長な呼び出しをハイライトするために視覚的手法が使用されうる。これらの冗長な呼び出しは、図３００ａの表示のほかの部分とは異なる色でハイライトされてもよい。
【００５８】
同じ入力値で同じ関数が呼び出される冗長な呼び出しは、可能な限り回避しなければならない。ＧＰＵレジスタを冗長にセットすると、パフォーマンスに大きな悪影響を与えることがあることを当業者は認めるであろう。冗長なコマンドの削除またはハイライトを実装するために、関数がプッシュバッファをスキャンし、プッシュバッファによって値がセットされると、それぞれのレジスタの値が記録されうる。セットするレジスタ値が、レジスタの以前の値と変わらないコマンドがみつかると、そのコマンドがプッシュバッファから削除される。このため、同じ入力値で同じ関数が呼び出される冗長な呼び出しを探すために、ドローコマンド、クリア、頂点命令、頂点定数、フラグメントプログラム定数、および他のコマンドの設定が評価されうる。プッシュバッファにテキストコメントを挿入するためにｌｉｂｇｃｍ関数ｃｅｌｌＧｃｍＳｅｔＭａｒｋｅｒが使用されてもよく、これが、図８のウィンドウ３００ａに表示されている点に留意する必要がある。
【００５９】
図９は、本発明の一実施形態による、ロウビューウィンドウ３０２およびその内容を示す概略模式図である。プッシュバッファの解釈されたダンプが、ウィンドウ３０２に本質的に示されている。ＡＰＩ呼び出しによってセットされた正確なハードウェアレジスタ値が、ウィンドウ３０２に表示されている。ロウビューウィンドウ３０２は、プッシュバッファの完全な逆アセンブリ、レジスタシーケンスおよび定数のほか、任意のユーザ指定アノテーションを表示している。一実施形態では、キャプチャで何らかのエラーが見つかった場合には、ウィンドウ３０２でそのエラーが視覚的にハイライトされうる。図１０のウィンドウ３０６の問題ビューは、全ての警告およびエラーをまとめて表示している。
【００６０】
一実施形態では、開発者は、問題をクリックして問題のエントリの１つを選択することによって、問題のあるドローコンテキストおよびロウ逆アセンブリを閲覧することができる。本発明の一実施形態によるプッシュバッファ概要画面３０８が、図１１に示される。プッシュバッファ概要画面３０８は、各種コマンドによるプッシュバッファの占有割合を示す。各種コマンドには、テクスチャパラメータ、レンダリングターゲットパラメータ、頂点プログラムなどをセットするコマンドなどがある。図１１に示すように、頂点プログラム定数は、プッシュバッファの空間の大部分（すなわち４１４０８バイトまたは５５％）を占有している。更に、頂点プログラム定数内にかなり多くの冗長が存在する点を理解すべきである。図１１に示すように、冗長を取り除くことにより、頂点プログラム定数のサイズが２９９３２バイトのデータに削減できる。図１１のウィンドウ３０８の冗長詳細タブを選択すると、冗長詳細ウィンドウ３１０が表示される。
【００６１】
図１２の冗長詳細ウィンドウ３１０には、全ての状態コマンドと各状態コマンドの冗長の割合の一覧が含まれる。大きな冗長な状態があれば、それがハイライトされるか、何らかの形で視覚的に強調され、バッファの使用を最適化するために、冗長な状態を取り除かれなければならないことを開発者に示しうる。図１２に示すように、アルファテストイネーブルが２００回以上セットされ、時間の９９％が冗長である。冗長な呼び出しにより、各フレームのレンダリングに、余計な数ミリ秒を容易に要しうることを当業者は認めるであろう。このため、図１１，１２のプッシュバッファ概要は、プッシュバッファを分解し、内容を、例えばサイズごとに分類可能にする。
【００６２】
図１３Ａは、図６のレンダリング状態ウィンドウ３１２を更に示す概略模式図である。レンダリング状態ウィンドウ３１２は、現在選択されているドローコンテキストによって参照される全てのリソースを示す。レンダリング状態ウィンドウ３１２内に、このレンダリング呼び出しのためにセットされた頂点配列、フラグメントプログラム、テクスチャ、レンダリングターゲットなどが表示されている。特定のリソースは、前のドローコンテキストによってセットされている（例えば、５ドローコンテキスト前にフラグメントプログラムが特定されている）などにより、ドローに対するｌｉｂｇｃｍ呼び出しを調べるだけこの情報を取得することができないという点に留意すべきである。リソースを選択すると、更に詳しい詳細を提供する適当なリソースウィンドウが開発者に表示される。ウィンドウ３１２の一番下に示すように、多くのタブがあり、これらは以降の図によって更に詳しく説明するグラフィックインタフェースを定義する。
【００６３】
図１３Ｂは、本発明の一実施形態による、各呼び出しに対してセットされたＧＰＵ状態を示す、その他の状態ウィンドウ３１４を示す概略模式図である。例えば、ウィンドウ３１４では、色書き込みが有効にされ、アルファブレンドが無効にされている。図１４Ａは、本発明の一実施形態によるテクスチャウィンドウ３１６を示す。テクスチャウィンドウ３１６は、ウィンドウ３１６の左列のフレームに対するプッシュバッファによって現在使用されている全てのテクスチャをリストアップしている。各テクスチャに対して、圧縮フォーマット、次元、総ｍｉｐレベル、サイズなどのプロパティが示されている。
【００６４】
当然、テクスチャウィンドウ３１６に、ほかのテクスチャ状態属性が含まれてもよい。更に、ｍｉｐｓが正しく表示されることを保証するために、各テクスチャに対するそれぞれのｍｉｐレベルを個々に閲覧することができる。図１４Ｂでは、テクスチャウィンドウ３１６の低いｍｉｐレベルが示されている。図１４Ｃでは、ピクセルツールチップを使用して、開発者が、ノーマルマップなど、シェーディング計算のために使用される、ボックス３１７内のテクスチャのピクセル値をチェックできる。図１４Ｄはテクスチャウィンドウ３１６を示し、ドロップダウンリストに、このテクスチャを使用しているドローコンテキストが示される。
【００６５】
図１５のメモリダンプウィンドウ３１８はテクスチャのメモリビューを提供し、そのテクスチャを使用するシェーダのデバッグに役立つ。一実施形態では、テクスチャはＢＭＰファイルとしてエクスポートすることができ、テクスチャが、ＣＥＬＬプロセッサなどのプロセッサによってプロシージャにより生成された場合にデバッグに役立ちうる。図１６，１７は、それぞれ、ウィンドウ３２０とウィンドウ３２２を示す。図１６では、プッシュバッファによって使用される頂点配列が、ウィンドウ３２０に示されている。図１７では、プッシュバッファによって使用されるインデックス配列が、ウィンドウ３２２に示されている。
【００６６】
図１８は、本発明の一実施形態による、フラグメントプログラムウィンドウ３２４を示す概略模式図である。フラグメントプログラムウィンドウ３２４は、プッシュバッファで使用される全てのフラグメントプログラムの一覧を示し、現在のドローコンテキストによって使用されている断片シェーダプログラムの解釈されたダンプを提供する。頂点シェーダプログラムとは異なり、断片シェーダプログラムによって使用される定数がプログラム自体に埋め込まれるため、オブジェクトを描画する前に、通常は、定数がセットされる点を理解すべきである。すなわち、断片シェーダプログラムの埋め込み定数は、対象の特定のドローコンテキストに応じて変わる。フラグメントプログラムウィンドウ３２４は、現在のドローコンテキストに対する適当な定数を表示している。
【００６７】
図１９Ａは、本発明の一実施形態による、プッシュバッファで使用されている全てのプログラムの一覧を示し、解釈されたダンプを提供する頂点プログラムウィンドウ３２６を示す。頂点プログラムウィンドウ３２６は、二重発行されている命令、および依存関係のストールを有するコマンドも示す。一実施形態では、このようなストールが視覚的にハイライトされうる。頂点プログラムウィンドウ３２６は、現在のドローコンテキストによって使用される各頂点プログラムと、属性（例えば入力、出力、一時レジスタなど）をリストアップする。
【００６８】
図１９Ｂは、本発明の一実施形態による頂点プログラムコンテキストウィンドウ３２７を示す。頂点プログラムコンテキストウィンドウ３２７は、現在のドローコンテキストによって使用されている頂点定数を示している。定数は視覚的にハイライトされ、所定の色がその定数の特定の状態を示している。例えば、一実施形態では、定数が新たに変更されているか、前のフレームから継承されたか、冗長であるかを示すために、色分けされてもよく、これにより、最適化の可能性が開発者に示される。
【００６９】
図２０Ａ，図２０Ｂは、本発明の一実施形態によるＧＰＵ内のレジスタの状態を詳細に示すＧＰＵレジスタウィンドウを示す。図２０Ａは、現在選択されているドローコンテキストによって変更された全レジスタの一覧を示す簡潔モード表示を提供するウィンドウ３２８を示す。図２０Ｂは、全レジスタの一覧を示すウィンドウ３３０を示す。一実施形態では、表示が色分けされ、特定の色が、現在のドローコンテキストによって値がセットされていることを示しており、値の色が異なる場合には、その値は前のドローコンテキストによってセットされている。例えば、青い値は、値が現在のドローコンテキストによってセットされていることを示す一方、緑色は、値が前のドローコンテキストによってセットされていることを示す。
【００７０】
本発明の一実施形態によるレンダリングターゲットウィンドウ３０４が、図２１Ａ〜２１Ｋに更に示される。レンダリングターゲットウィンドウ３０４は、フレームで使用されている全レンダリングターゲットの一覧を示しており、現在選択されているドローコンテキストで実際に使用されるレンダリングターゲットがハイライトされている。例えば、図２１Ｂは、深度バッファレンダリングターゲットのビューを示す。基本的に、レンダリングターゲットウィンドウ３０４では、ツールの内部的な分析の結果を開発者が自由に閲覧できる。例えば、一実施形態では、オブジェクトがそのバッファにのみ書き込むため、シャドウマップがハイライトされうる。このため、さまざまな方法でキャプチャを調べることが可能であり、キャプチャを保存し、再検討のために他の人に送信することができる。ゲームコンソールでは、別の開発者に送信されたデータの再検討を必要としない点が理解されるべきである。しかし、ゲームコンソールがアプリケーションに接続されている場合、再キャプチャによって行うことができる追加の項目が提供されうる。例えば、開発者は、レンダリングターゲットウィンドウ３０４でリフレッシュボタンを選択することによって、現在の描画呼び出し後のレンダリングターゲットの状態を参照することができる。基本的に、開発者は、ドローコンテキストを選択し、次にリフレッシュを押すことによって、図２１Ｃ〜２１Ｈに示すように、レンダリングされる画像を１つずつ見ることができる。
【００７１】
この実施形態では、例えば、開発者は、最終的な画像に異常なピクセルを表示させている描画呼び出しを決定することができる。また、開発者は、レンダリングターゲットを、ハイライト、オーバードロー、ワイヤフレームなどの各種モードで表示させたいかどうかを選択することができる。開発者が画像上でカーソルを移動させると、図２１Ｊ〜２１Ｉに示すように、任意のピクセルの正確なＲＧＢとピクセル位置の値が表示され、開発者がピクセル固有のバグをトラッキングできる。上で説明したように、これらの画像は、後の検査のために、ＢＭＰファイルとして保存することができる。レンダリングターゲットウィンドウ３０４により、開発者は、レンダリングターゲットがテクスチャとして別名が付けられている場合、レンダリングターゲットが倍速レンダリングに設定されている場合、レンダリングターゲットが早期深度の最適化（early depth optimization：EDP）のために設定されている場合などに、ドローコンテキストがレンダリングターゲットに書き込む内容を決定することができる。
【００７２】
レンダリングターゲットのリフレッシュ中に、プッシュバッファが、ＧＣＭツールから転送され、現在選択されているドローコンテキストに送られる。このため、レンダリングプロセスは単一ステップ実行であり、時間を先行しても遡っても行うことができる。図２１Ｋは、レンダリングターゲットウィンドウのデータのエクスポートを可能にするインタフェースを示す。
【００７３】
開発者は、ＧＣＭツールによって、各リソースを調べるほかに、さまざまな形式のパフォーマンス分析を行うこともできる。一般に、開発者は、最初はＧＣＭツールによって提供されるサブユニット利用度機能を使用する。図２２は、本発明の一実施形態による、開発者がプロファイラアスペクトを選択するメニューの概略模式図を示す。プロファイラのアスペクト内のサブユニット利用度機能は、ボトルネックの原因となりうる各ドローコンテキストにおける主要サブユニットのそれぞれの平均利用度を与える。本発明の一実施形態によれば、このプロファイルは、図２３Ａのウィンドウ３３４または図２３Ｂのウィンドウ３３６に示すようにグラフでもよい。ウィンドウ３３４，３３６の棒グラフは色分けされており、最も頻繁に使用されているサブユニットを明確に示し、基本的に最適化の対象を順に並べてリストアップする。
【００７４】
例えば、図２３Ｂに示すように、特定のドローコンテキストに対して最も長いバーは、頂点プログラム処理エレメント利用度のものであり、開発者は、変換後のキャッシュをより適切に利用するために、頂点プログラムの最適化、またはインデックスの再並べ替えを検討する可能性がある。図２３Ａ，２３Ｂのサブユニット利用度プロファイルが、主要なＧＰＵサブユニットの現在の利用度を示していることが理解されるべきである。更に、サブユニット利用度は、ドローコンテキスト単位で計算され、各サブユニット利用度がヒストグラムで重ねて描画されてもよい。一実施形態では、サブユニット利用度プロファイルは、最適化の対象を順に並べてリストアップする。ウィンドウ３３４，３３６のそれぞれのグラフ内の幅は、対応するレンダリングアスペクトを実行するための所要時間に比例することを更に理解すべきである。
【００７５】
図２４Ａ，２４Ｂは、本発明の一実施形態による、分析に使用することができるパフォーマンスカウンタ用のグラフィカルユーザインタフェースを示す。パフォーマンスカウンタは、ＧＰＵの派生カウンタおよびハードウェアカウンタに関する詳細を提供する。図２４Ｂに示すように、生のカウンタデータが表形式で表示されてもよい。別の実施形態では、データがグラフィカルな形式で表示され、複数のカウンタがグラフに同時に表示されてもよい。ＧＣＭツールが、変換後のキャッシュヒット／ミス、有効フィルレートなど、これらのカウンタに基づく統計情報を提供することが理解されるべきである。
【００７６】
ゲームエンジンは、シーン内の全てのオブジェクトを監視し、視錐台内にありレンダリングすべきオブジェクトと、および視錐台の外にあり、スキップすべきオブジェクトを判定することを求められている。通常、これはバウンディングスフィアによって行われ、画面から完全に外れている多くのオブジェクトがバウンディングスフィアテストにパスするため、これは多少不正確な傾向がある。また、アニメーション化されたキャラクタは、視錐台に対してチェックするのが極めて困難である。全ての可能なポーズを含むのに十分大きなバウンディングスフィアを使用するなどのさまざまな非効率な選択肢や、各種ジョイントを中心とした複数のバウンディングスフィアを使用などの複雑な選択肢などが存在する。このため、開発者は、オブジェクトのカリングがどの程度効率的であるか、適切なオブジェクトのカリングからどの程度のパフォーマンスゲインが得られるかを問題にする。
【００７７】
本明細書に記載するＧＣＭツールは、ほかの機能のうち、オブジェクトのカリングを分析し、プッシュバッファ内のオブジェクトの完全な分析を提供すると共に、プッシュバッファからオフスクリーンのオブジェクトを削除して新しいプッシュバッファを作成することができる。新しいプッシュバッファが前のプッシュバッファと比較され、パフォーマンスゲインを定量化することができる。本明細書に記載するツールは、アプリケーション内でコードを１箇所も変更せずに、この分析を実行することが理解されるべきである。すなわち、プッシュバッファ特性がキャプチャされている間、アプリケーションが再生プロセス中はバイパスされるため、開発者は、アプリケーションコードを書き直す骨の折れる工程を行う必要がない。
【００７８】
図２５Ａ〜２５Ｄは、本発明の一実施形態による、フレームのレンダリングを最適化するためのカリングプロセスを示す。まず、図２５Ａに示すように、開発者は、条件付きのプロファイリングメニューを使用し、ドローコンテキストをトリムするために各ドローコンテキストを選択する。図２５Ｂで、トリミングプロセスの詳細が選択され、この特定の例では、開発者は、オフスクリーンをトリムする(図中のtrue)とともに、ａ）縮退（degenerate）、ｂ）ピクセルなし（no-pixel）、またはｃ）背面三角形(backface)に関してはトリムを行わない（図中のfalse）ことを選択する。
【００７９】
次に、開発者はプロファイルボタンを選択し、結果がＧＣＭツールによって処理される。ＧＣＭツールは、レンダリング呼び出しごとに、各三角形について三角形アセンブリユニットに渡される頂点位置を調べ、オンスクリーンの三角形を決定する。ツールがオンスクリーンのオブジェクトを特定すると、ツールはそのオブジェクトを含む新しいプッシュバッファを生成し、フレームのタイミング合わせを再度行う。一実施形態では、このプロセス全体にかかる時間は１〜２分などである。結果を図２５Ｄに示し、ウィンドウ３４０は、オフスクリーンのオブジェクトを含むプッシュバッファを有するフレームと、オンスクリーンのオブジェクトのみを含むプッシュバッファを有するフレームのレンダリングを比較したときに、３３％の向上が得られたことを概略的に示す。
【００８０】
このため、３３％の向上が可能であるという結果を見た開発者は、オブジェクトが視錐台に対してチェックされるように、変更を見るべきである。図２５Ａ〜２５Ｄに関して上で説明したテストは、「仮定」テストまたはプロファイリングとも呼ばれうる。すなわち、開発者は、私のカリングが完全だと「仮定」したらと自問しうる。ここで、カラー（culler）は、カリングを三角形ごとになど行う。別の実施形態では、冗長コマンドを特定する冗長コマンドの「仮定」もある。冗長コマンドの「仮定」は、全ての冗長コマンドを削除した新しいプッシュバッファを生成して、パフォーマンスの増加を測定する。
【００８１】
図２５Ｃを参照すると、プロファイルボタンを選択すると、変更されたプッシュバッファの変更を元のプッシュバッファにコミットせずに、プッシュバッファのプロファイルが比較されるという点に留意すべきである。別の実施形態として、コミットボタンを選択すると、変更後のプッシュバッファの変更が元のプッシュバッファにコミットされる。
【００８２】
図２６Ａ〜２６Ｃは、冗長コマンドの「仮定」を適用した場合に、開発者が行う作業のシーケンスを示す。図２６Ａに「仮定」ウィンドウ３４２が提供され、このウィンドウで開発者は冗長の「仮定」を選択する。図２６Ｂで、冗長「仮定」が選択され、図２６Ｃでプロファイルが比較される。図２６Ｄ〜図２６Ｏに図示されている、プロファイリングのほかの「仮定」選択肢が存在する。
【００８３】
また、図２７Ａ〜Ｅは、「試験例」とも呼ばれうるパフォーマンス最適化を示す。これは、レンダリング中のゲームまたはアプリケーションの最適な設定の推奨を提供するために、１つ以上の「仮定」またはパフォーマンス最適化を適用し、繰り返す。このような試験例について、実装手法と例示的な結果と共に、下記に更に詳細に説明する。パフォーマンス試験例のリストは例に過ぎず、限定するものではないことが理解されるべきである。すなわち、画像データのフレームのレンダリングを最適化するための情報を提供するどのようなパフォーマンス試験例が、本明細書に記載のツールに含まれてもよい。
【００８４】
図２６Ｄに示す１つの試験例では、深度カリングのパフォーマンスを最大化するために、オブジェクトが前面から背面にレンダリングされるように、シーンが再編成される。このソートは、アルファブレンドされた描画呼び出しの相対レンダリング順序を乱さない方法で行われる。最初は、描画呼び出しのグループが形成され、グループは、出力を変更せずに、ソートを変更することができる全ての描画呼び出しから成る。
【００８５】
一実施形態では、レンダリングターゲットの変更、ブレンディング状態の変更、クリア、フラグメントプログラムの変更、フラグメントプログラム定数のセット、頂点プログラムの変更、頂点プログラム定数のセット、または深度関数をまたがるグループ化は許容されない。他の軽微なレンダリング状態の変更は、描画呼び出しに関連していなければならず、ソート後に、必要に応じて、適切なレジスタセットを移動または生成しなければならない。各描画呼び出しの位置範囲が特定され、最も近いｚ範囲がソートする値として選択される。描画呼び出しは、各描画呼び出しの最も近いｚ範囲に従って各描画グループ内でソートされ、パフォーマンスが測定される。
【００８６】
オブジェクトのソートから得られるパフォーマンスゲインを示す結果が表示される。当業者は、オブジェクトソートでは、オブジェクトが表示される順序が重要となりうることを認めるであろう。前面から背面へのソートは、デプスリジェクトが早期に行われることから、パフォーマンスを向上させる。通常、ゲームはシャドウマップ、不透明な形状、半透明の形状に続いて、最後にブラーおよびブルームなどのフルスクリーン効果をレンダリングする。この実施形態では、ＧＣＭツールは、シャドウマップおよび不透明な形状のレンダリング呼び出しを距離でソートすると、パフォーマンスが改善するかどうかを判定することができる。
【００８７】
図２６Ｅに示す深度のみパスのパフォーマンス最適化は、各不透明なオブジェクトに対するレンダリング呼び出しのみに、深度（Ｚ）を挿入したときのパフォーマンスの影響を求める。これがパフォーマンスを向上させることもあれば、させないこともある点に注意すべきである。例えば、ボトルネックが、頂点属性の読出しまたは頂点シェーダプログラムである場合、Ｚパスを追加すると、パフォーマンスは実際に低下しうる。この最適化では、色バッファと深度バッファの両方に書き込むレンダリングターゲットごとに、シーンが２回レンダリングされる。まず、色書き込みを無効、深度書き込みを有効にして、シーンがレンダリングされる。次に、色書き込みを有効、深度書き込みを無効にして、シーンがレンダリングされる。パフォーマンスゲインが測定され、結果が視覚的に表示される。
【００８８】
図２６Ｆ〜Ｈに示す三角形トリムの最適化は、ピクセルユニットに三角形を渡す前に、三角形に対して各種のチェックを実行する。三角形が視錐台の外にある場合、三角形はカットされる。三角形の向きが正しくない(facing the wrong way）場合、三角形はカットされる。三角形の面積がゼロの場合、三角形はカットされるが、これはプログレッシブメッシュによってＬＯＤ（level of detail）を行う場合によく起こる。最後に、三角形が小さすぎてピクセルの中心を包含できない場合、三角形はカットされる。上で説明したように、ＧＣＭツールは、背面、オフスクリーン、縮退、およびピクセルなしの三角形に対するチェックを実行することができることが理解されるべきである。換言すれば、この種の相乗的プロセッサユニット（ＳＰＵ）システムが採用される場合、ツールによりパフォーマンスの向上が得られる。例示的な三角形トリムの選択肢を、下記に挙げる。
【００８９】
オフスクリーンの三角形のトリム
描画呼び出しごとに、オフスクリーンの三角形を見つけ、これらを頂点配列またはインデックス配列から削除し、パフォーマンスゲインを測定する。三角形の頂点がビューポート変換によって変換され、画面エリアと交差しない頂点、エッジまたはエリアの三角形がカリングされる。この表示には、各描画呼び出しに対して削除された三角形の数と、これらを削除することで得られるパフォーマンスゲインを示す。
【００９０】
背面三角形のトリム
背面カリングが有効の場合、描画呼び出しごとに、背面の三角形を見つけ、これらを頂点配列またはインデックス配列から削除し、パフォーマンスゲインを測定する。
(x1-x0)×(y2-y0)-(x2-x0)×(y1-y0)＜(-e)(|x1-x0|+|x2-x0|+|y1-y0|+|y2-y0|+2)
ここで、三角形＝((x0,y0),(x1,y1),(x2,y2))およびe=FLT_EPSILON （式１）
ビューポート変換によって三角形の頂点を変換した後に、式１が適用され、どの三角形が背面にあり、削除すべきであるかが決定される。次に、各背面の三角形を独立した描画呼び出しに分割し、深度比較、アルファテスティング、およびステンシル比較を無効にして再レンダリングして、ＧＰＵから書き込まれるピクセル数の報告を要求することによって、このテストが検証される。次に、背面にあると判定され、いずれのピクセルにも書き込まなかった三角形が削除される。結果を示すインタフェースが、各描画呼び出しに対して削除された三角形の数と、これらを削除することで得られるパフォーマンスゲインを示す。
【００９１】
縮退三角形のトリム
縮退している三角形が特定され、頂点配列またはインデックス配列から削除されて、パフォーマンスゲインが測定される。
(v0==v1)||(v0==v2)||(v1==v2)
ここでv0=(x0,y0)、v1=(x1,y1)、v2=(x2,y2)および三角形=(v0,v1,v2) 式２
ビューポート変換によって三角形の頂点を変換した後に、式２が適用され、どの三角形が縮退し、削除すべきであるかが決定される。結果を示すインタフェースが、各描画呼び出しに対して削除された三角形の数と、これらを削除することで得られるパフォーマンスゲインを示す。
【００９２】
ピクセルなし三角形のトリム
描画呼び出しごとに、どのピクセル中心にも該当しない三角形が特定され、頂点配列またはインデックス配列から削除されて、パフォーマンスゲインが測定される。各三角形は、これを独立した描画呼び出しに分割し、深度比較、ステンシル比較、およびアルファテスティングを無効にして再レンダリングして、ＧＰＵから書き込まれるピクセル数の報告を要求することによって検証される。次に、どのピクセルにも書き込まなかった任意の三角形が、インデックスまたは頂点配列から削除される。結果を示すインタフェースが、各描画呼び出しに対して削除された三角形の数と、これらを削除することで得られるパフォーマンスゲインを示す。
【００９３】
一実施形態では、「一時レジスタカウント」を操作することによって、ピクセルパイプの長さをオブジェクト単位で変更することができ、この値はｌｉｂｇｃｍ呼び出しのｃｅｌｌＧｃｍＳｅｔＲｅｇｉｓｔｅｒＣｏｕｎｔを使用してセットすることができる。一時レジスタカウントが高にセットされると、各ピクセルパイプのピクセル数が減る。これにより、パイプ間のピクセルの分布が改善されるため、小さなオブジェクトのパフォーマンスが向上しうる。また、テクスチャキャッシュを多用しうるフルスクリーン効果のパフォーマンスも向上しうる。図２６Ｋ〜Ｌに示すように、この「仮定」を使用することによって、開発者は、特定のレンダリング呼び出しについて、またはシーン全体について、一時レジスタカウント値の変更に伴うパフォーマンスの向上または低下を観察することができる。
【００９４】
別の実施形態では、三角形のフォーマットが変更されて、パフォーマンスへの影響が決定されうる。ＧＰＵ上で三角形を表示するための方法がさまざまに存在し、例えば、三角形、三角形ストリップ、インデックスド三角形、およびインデックスド三角形ストリップなどがある。一実施形態では、インデックスド三角形がパフォーマンスが最も高い。非インデックスド描画が使用されている場合、図２６Ｍに示すように、「非インデックスド描画をインデックスド描画に変換する」の最適化を使用すると、インデックスド三角形リストに変更することによって得られるパフォーマンスが示される。また、図２６Ｎ〜Ｏに、三角形リストを最適化するための「仮定」も示されている。得られる潜在的なパフォーマンスは、頂点キャッシュオプティマイザを使用することによって決定される。頂点キャッシュオプティマイザは、インデックスド三角形の理想に近い組を選択するツールであり、変換後のキャッシュミスを最小限に低減するだけではなく、ＧＰＵ上で三角形の組立てに使用される４つの頂点ミニキャッシュについても最適化する。更に別の最適化を下記に挙げる。
【００９５】
頂点属性配列コンテキストの位置
関数が、各頂点ストリームをメインメモリまたはビデオメモリに移動させ、それぞれのパフォーマンス測定を記録する。このため、メインメモリとビデオメモリ間で頂点ストリームを切り換えることによって実現されるパフォーマンスを示す詳細を、頂点ストリームを移動したコンテキストと共に作成することができる。
【００９６】
インターリーブされた頂点属性配列
この実施形態では、頂点配列ごとに、どの頂点配列が２回以上使用されているかを記録することによって、インスタンス生成されているか、あるいは一意であるかのカテゴリが割り当てられうる。次に、このリストが、どのインスタンス生成された頂点配列が共に使用されているかを記録することによってオブジェクトリストに分割される。この情報を使用して、各オブジェクトに対する頂点配列のカテゴリごとに、頂点配列がインターリーブされうる。描画呼び出ごとに、元の頂点配列の代わりにインターリーブされた頂点配列がセットされ、パフォーマンスの差が測定される。オブジェクトインスタンスごとに、属性をインターリーブすることによって得られるパフォーマンスゲインを表示することにより、結果が視覚的に表示されうる。
【００９７】
インターリーブされた頂点属性配列コンテキストの位置
この試験例の実装は、インターリーブされた頂点属性配列の試験例を使用し、その後、頂点属性配列コンテキストの試験例を使用するが、この両者については上に挙げている。ここでは、オブジェクトインスタンスごとに、パフォーマンスゲインと、頂点属性配列を移動したコンテキストが表示される。
【００９８】
未使用の有効な頂点属性配列の特定
別の例示的な試験例では、描画呼び出しごとに、頂点属性マスクを有効な頂点属性配列と比較することによって、未使用の有効な頂点属性配列が存在するかどうかが判定される。未使用の配列が無効にされ、このような頂点属性配列を無効にすることによるパフォーマンスゲインが測定される。結果のグラフィカルな表現には、未使用の有効な頂点属性配列ごとに、頂点属性配列が未使用だった頂点シェーダおよび描画呼び出しと、このような属性を適切に無効にすることで得られる全体的なパフォーマンスゲインの表示が含まれる。
【００９９】
近いうちに発明される完全メッシュオプティマイザを使用したメッシュの再最適化
この試験例では、オブジェクトのインスタンスごとに、頂点配列およびインデックス配列に対してメッシュオプティマイザが実行され、パフォーマンスゲインが取得される。オブジェクトインスタンスごとに、パフォーマンスゲインの表示のほか、変換前と変換後のキャッシュミスの差が提示されうる。
【０１００】
未使用のインターポレータの特定
この試験例では、頂点ごと、およびフラグメントプログラムの組み合わせごとに、頂点プログラムの出力マスクおよびフラグメントプログラム命令を調べることによって、未使用のインターポレータが特定される。未使用のインターポレータは、頂点プログラムの出力マスクを変更することによって無効にされる。次にパフォーマンスゲインが測定される。頂点プログラムおよびフラグメントプログラムの組み合わせごとの表示には、未使用のインターポレータと、未使用のインターポレータを無効にすることにより得られるパフォーマンスゲインが表示される。
【０１０１】
色バッファコンテキストの位置
色バッファごとに、色バッファが現在存在する位置とは反対の位置に色バッファを移動させ、パフォーマンスの差を測定する。一実施形態では、バッファの移動時に、タイル設定が保持される（圧縮を除く）。一意の色バッファごとに、色バッファを現在存在する位置とは逆のコンテキストに移動させることによるパフォーマンスの差が測定される。パフォーマンスが改善する場合、色バッファのコンテキストをそのコンテキストに変更する「仮定」が作成される。当然、重複するテクスチャまたは深度バッファコンテキストがあれば、同じコンテキストに再配置される。色バッファごとに、バッファの移動によるパフォーマンスの差が表示されうる。
【０１０２】
深度バッファコンテキストの位置
深度バッファごとに、現在存在するコンテキストとは逆のコンテキストに深度バッファを移動させ、パフォーマンスの差を測定する。バッファの移動時に、タイル設定が保持される（圧縮を除く）。個別の色バッファごとに、深度バッファを現在存在するコンテキストとは逆のコンテキストに移動させることによるパフォーマンスの差が測定される。パフォーマンスが改善する場合、深度バッファのコンテキストをそのコンテキストに変更する「仮定」が作成される。当然、重複するテクスチャまたは深度バッファコンテキストがあれば、同じコンテキストに再配置される。深度バッファごとに、バッファの移動によるパフォーマンスの差、バッファの移動先およびタイル設定（存在する場合）が表示されうる。
【０１０３】
フラグメントプログラムレジスタカウント
この試験例では、フラグメントプログラムごとに、とりうる可能なレジスタカウントが試行され、パフォーマンスが最大となる最小のレジスタカウントが特定される。フラグメントプログラムごとに、パフォーマンスゲインおよび使用されたレジスタカウントが表示されうる。
【０１０４】
ＤＸＴ１テクスチャ
この試験例では、可変アルファを有さない（常時オンまたは常時オフの）テクスチャごとにｄｘｔｌ圧縮を適用することができる。全ての関連するテクスチャフォーマットコマンドが更新され、パフォーマンスゲインが測定される。ＤＸＴ１は、バイナリアルファにしか対応していないことを当業者は認めるであろう。一実施形態では、常時オンまたはオフのアルファに対するユーザ定義可能なエラー許容度がセットされる。適用可能なテクスチャごとに、パフォーマンスゲイン、新しいテクスチャおよびシーンのスクリーンショットが提供されうる。一実施形態では、新しいテクスチャをエクスポートする機能が提供される。
【０１０５】
ＤＸＴ３／５テクスチャ
ＤＴＸ１非圧縮のテクスチャごとに、ＤＸＴ３／５によりテクスチャを圧縮し、全ての関連するテクスチャフォーマットコマンドを更新して、パフォーマンスゲインを測定する。適用可能なテクスチャごとに、パフォーマンスゲイン、新しいテクスチャおよびシーンのスクリーンショットが提供されうる。一実施形態では、新しいテクスチャをエクスポートする機能が提供される。
【０１０６】
未使用のクリアされたステンシルバッファの特定
この試験例では、ステンシルビットが有効に設定されたクリアコマンドごとに、プッシュバッファ内の深度／ステンシルバッファの存続期間に、ステンシルマスクおよびステンシル操作（ops）がチェックされる。バッファが一度も使用されていない場合、クリアコマンドからステンシルビットが削除され、パフォーマンスゲインが測定される。パフォーマンスゲインが、不要なステンシルビットを有するクリアコマンドと共に表示される。
【０１０７】
未使用のクリアされた深度バッファの特定
この試験例では、深度ビットが有効に設定されたクリアコマンドごとに、プッシュバッファ内の深度／ステンシルバッファの存続期間に、深度マスクおよび深度関数がチェックされる。バッファが一度も使用されていない場合、クリアコマンドから深度ビットが削除され、パフォーマンスゲインが測定される。パフォーマンスゲインと、不要な深度ビットを有するクリアコマンドが表示されうる。
【０１０８】
未使用のクリアされた色バッファの特定
この試験例では、色ビットが有効に設定されたクリアコマンドごとに、プッシュバッファ内の色バッファの存続期間に、色マスクおよびブレンド関数がチェックされる。バッファが一度も使用されていない場合、クリアコマンドから色ビットが削除され、パフォーマンスゲインが測定される。一実施形態では、パフォーマンスゲインと、不要な色ビットを有するクリアコマンドが表示される。
【０１０９】
アルファブレンドによるアルファテスト
この試験例では、ブレンド式が追加され、関数がｓｒｃ ａｌｐｈａアルファおよびｉｎｖ ｓｒｃアルファであるブレンド関数ごとに、設定の存続期間が決定され、０の参照によってアルファテストが大きくセットされる。パフォーマンスゲインが測定され、新しいアルファコマンドが追加された位置と共に表示される。
【０１１０】
テクスチャコンテキスト位置
テクスチャコンテキスト位置の試験例は、次のプロセスで行われる。
−ａ）全ての描画呼び出しにわたってこのテクスチャと共に使用される他の全てのテクスチャへのリンクを含む配列を有する各テクスチャが特定される。リンクを含まない（which does not）テクスチャごと、およびリンクを含まないテクスチャを使用する描画呼び出しごとに、描画呼び出しで使用される他のテクスチャに対するリンクが生成される。
−ｂ）テクスチャグループの生成−ここで、各テクスチャを、たどるための（to traverse）テクスチャリストに追加する。テクスチャリスト内のテクスチャごとに、新しいテクスチャグループを生成し、グループにこのテクスチャを追加し、このテクスチャにリンクされている全てのテクスチャを、テクスチャグループに再帰的に追加する。テクスチャがグループに追加されるたびに、たどるためのテクスチャリストからそのテクスチャを削除する。
−ｃ）テクスチャグループごとに、グループ内のテクスチャの数が６を越える場合、グループ内のテクスチャをメモリフットプリントが最大のものから最小のものの順にソートする。ビデオメモリ内のテクスチャメモリのカウントをｖとすると、これを０にセットする。メインメモリ内のテクスチャメモリのカウントをｍとすると、これを０にセットする。テクスチャが消費するメモリの量をｔとする。テクスチャグループ内のテクスチャごとに、ｍ＋ｔ＞ｖ×０．６の場合は、このテクスチャのビットをビデオメモリにセットしてｖ＋＝ｔとし、そうでない場合には、このテクスチャのビットをメインメモリにセットしてｍ＋＝ｔとする。
−ｄ）テクスチャグループごとに、グループ内のテクスチャの数が６以下の場合、テクスチャグループ内の全てのテクスチャコンテキストをビットで表現する。得られるビットストリームを、取りうる組み合わせごとに力任せにプロファイリングし、最もパフォーマンスの高い組み合わせを、選択するビットストリームとして選択する。
−ｅ）テクスチャごとに、テクスチャのコンテキストビットがその元の状態から変更されている場合、テクスチャのコンテキストをそのコンテキストに変更する「仮定」を作成する。
−テクスチャコンテキスト位置の試験例他の形態では、以下が行われてもよい。
−ｄ）の後に、ｃ）およびｄ）で計算されたように、テクスチャビットストリームをｓとする。ｂをビットストリームｓのフレーム時間とする。ｉを繰返しカウントとする。ｉがゼロではない間、ｉをデクリメントする。ｓを確率論的に（stochastically）５％変更する。変更されたビットストリームのフレーム時間をｎとする。ｎ＜ｂの場合、ｂをｎと等しい値に設定し、ｓを変更されたビットストリームと等しく設定する。
テクスチャごとに、テクスチャの移動によるパフォーマンスの差およびテクスチャの移動先のほか、全テクスチャの移動の全体的なパフォーマンスが提示されうる。
【０１１１】
タイルのパッキング
この試験例では、ピッチおよび圧縮タイプが一致するタイルごとに、タイルが１つのタイルに結合され、格納しているリソースを適宜移動させる。一実施形態では、前のタイルと新しいタイルのレイアウトが、各タイルの内容の一覧と共に表示される。
【０１１２】
未タイリングの色バッファのタイリング
ここでは、未使用のタイルが存在する場合に、タイリングされておらず、スウィズル(swizzle)されていない色バッファごとに、色バッファをタイリングし、パフォーマンスゲインを測定する。適用可能な色バッファごとに、タイリングから得られるパフォーマンスゲインとタイル設定が表示される。
【０１１３】
未タイリングの深度バッファのタイリング
ここでは、未使用のタイルが存在する場合に、タイリングされておらず、スウィズルされていない深度バッファごとに、深度バッファをタイリングし、パフォーマンスゲインを測定する。適用可能な深度バッファごとに、タイリングから得られるパフォーマンスゲインとタイル設定が表示される。
【０１１４】
未圧縮のタイリング済み色バッファの圧縮
この試験例では、ビデオメモリ内でタイリングされているが、未圧縮の色バッファごとに、色バッファを圧縮し、パフォーマンスゲインを測定する。一実施形態では、同じフォーマットのバッファを含むタイルのみが圧縮される。適用可能な色バッファごとに、パフォーマンスゲインとタイル設定を表示する。
【０１１５】
未圧縮のタイリング済み深度バッファの圧縮
この試験例では、ビデオメモリ内でタイリングされているが、未圧縮の深度バッファごとに、深度バッファを圧縮し、パフォーマンスゲインを測定する。一実施形態では、同じフォーマットのバッファを含むタイルのみが圧縮される。適用可能な深度バッファごとに、パフォーマンスゲインとタイル設定を表示する。
【０１１６】
未タイリングの色バッファのタイリングおよび圧縮
未タイリングであり、スウィズルされていない未使用の色バッファごとに、色バッファをタイリングし、色バッファに最適な圧縮設定を与える。適用可能な色バッファごとにパフォーマンスゲインを測定し、パフォーマンスゲインおよびタイル設定を表示する。
【０１１７】
未タイリングの深度バッファのタイリングおよび圧縮
未タイリングであり、スウィズルされていない未使用の深度バッファごとに、深度バッファをタイリングし、深度バッファに最適な圧縮設定を与える。適用可能な深度バッファごとにパフォーマンスゲインを測定し、パフォーマンスゲインおよびタイル設定を表示する。
【０１１８】
冗長なクリアの特定
この試験例では、クリアコマンドごとにバッファが既にクリアされているかどうかが判定される。バッファがクリアされている場合、クリアコマンドを削除し、パフォーマンスゲインを測定する。パフォーマンスゲインと二重のクリアコマンドが開発者／ユーザに表示されうる。
【０１１９】
完全にフィルの色バッファの特定
ここでは、色ビットが有効に設定されているクリアコマンドごとに、色バッファをチェックして、プッシュバッファ内の現在のレンダリングターゲットの存続期間の後に、全てのピクセルが書き込まれているかどうかを調べる。全てのピクセルが新しい色の値を有する場合、クリアコマンドから色ビットを削除して、パフォーマンスゲインを測定し、パフォーマンスゲインおよび不要な色ビットを有するクリアコマンドが表示されうる。
【０１２０】
ｐｐｕフラグメントプログラム定数のパッチング
この試験例では、異なる定数の組を有するフラグメントプログラムごと、および描画呼び出しごとに、プログラムのマイクロコードに定数が既にセットされた状態で、新しいフラグメントプログラムが作成される。定数の組がプッシュバッファから削除され、これらが、新しいフラグメントプログラムに対するセットされたフラグメントプログラムコマンドで置換される。得られる表示には、フラグメントプログラムごとのパフォーマンスゲイン、プログラム変更の数、およびバイト単位の新しい変更のサイズが含まれうる。
【０１２１】
完全な深度−カリング最適化制御設定
レンダリングターゲットごとに、深度カリング報告およびＣａｌｃｕｌａｔｅＤｅｐｔｈＣｕｌｌＦｅｅｄｂａｃｋ（）関数に記述されたアルゴリズムを使用して、最良の深度−カリング最適化制御設定が特定される。レンダリングターゲットごとに、最良の深度−カリング最適化設定および得られるパフォーマンスゲインが表示される。
【０１２２】
深度−カリングエリアの有効化
ここで、タイリング済みの深度バッファごとに、深度バッファに深度カリングエリアがセットされていない場合、深度カリングエリアがセットされ、パフォーマンスゲインが測定される。その後、深度カリングエリアを適切にセットすることによるパフォーマンスゲインを表示することができる。
【０１２３】
深度−カリングエリアの無効化
ここで、タイリング済みの深度バッファごとに、深度バッファに深度カリングエリアがセットされている場合、深度カリングエリアが無効にされ、深度カリングの効率を示すパフォーマンス損失が測定される。深度カリングを使用しないことによるフォーマンス損失が取得され、表示される。
【０１２４】
深度カリングの再生成
各レンダリングターゲットに関して、深度カリングが特に無効にされているか、または深度関数が方向を変更する場合、無効化後に大きなｑｕａｄをレンダリングすることによって、深度カリングメモリを再生成する。パフォーマンスゲインが測定され、レンダリングターゲットごとに、深度カリングエリアが無効化された場合、深度カリングメモリの再生成によるパフォーマンスゲインが表示される。
【０１２５】
完全なテクスチャミップマップセット
この試験例では、完全なミップマップセットを有さないテクスチャごとに、単純なボックスフィルタを使用して完全なミップマップセットを生成し、パフォーマンスの差を測定する。次に、完全なミップマップセットの生成によるパフォーマンスゲインを、表示に使用することができる。
【０１２６】
トリリニアフィルタリング
アニソトロピックフィルタリングを使用するテクスチャフィルタコマンドごとに、フィルタリングがトリリニアフィルタリングに変更され、パフォーマンスゲインが測定され、シーンのスクリーンショットと共に表示される。
【０１２７】
ブライリニアフィルタリングの最適化
トリリニアフィルタリングを使用しているテクスチャフィルタコマンドごとに、全ての可能なブライリニア最適化値をたどり、パフォーマンスゲインを測定する。適用可能なテクスチャごとに使用されるブライリニア最適化の値に対する相対パフォーマンスゲインを示すグラフ、およびシーンのスクリーンショットが生成され、表示されうる。
【０１２８】
バイリニアフィルタリング
トリリニアフィルタリングまたはアニソトロピックフィルタリングを使用しているテクスチャフィルタコマンドごとに、フィルタリングをバイリニアに変更し、パフォーマンスゲインを測定する。この試験例は、深度テクスチャに極めて有用である。この場合も、パフォーマンスゲインおよびシーンのスクリーンショットを、表示に使用することができる。
【０１２９】
点フィルタリング
この試験例では、テクスチャフィルタコマンドごとに、フィルタリングを点に変更し、パフォーマンスゲインを測定する。これは、深度テクスチャに極めて有用である。適用可能なテクスチャごとに、パフォーマンスゲインおよびシーンのスクリーンショットが表示されうる。
【０１３０】
静的または不変属性の特定
ここでは、描画呼び出し全体にわたって値が一定である各描画呼び出しの頂点配列を特定する。この頂点配列をセットする代わりに、ＳｅｔＶｅｒｔｅｘＡｔｔｒｉｂ４ｆを使用して属性配列の値をセットする。頂点配列全体が、全ての描画呼び出しにわたって同じ値の場合、その代わりに、頂点配列を削除し、その設定コマンドをＳｅｔＶｅｒｔｅｘＡｔｔｒｉｂ４ｆコマンドで置換する。静的属性が存在する各描画呼び出しの表示には、パフォーマンスゲインおよびＳｅｔＶｅｒｔｅｘＡｔｔｒｉｂ４ｆに渡された値が含まれる。頂点配列ごとに、頂点配列全体が静的な場合、コマンドを、ＳｅｔＶｅｒｔｅｘＡｔｔｒｉｂ４ｆコマンドで置換することの全体的なパフォーマンスゲインおよびＳｅｔＶｅｒｔｅｘＡｔｔｒｉｂ４ｆに渡された値を表示する。
【０１３１】
完全な頂点属性のパッキング
オブジェクトインスタンスごと、およびオブジェクトインスタンスがレンダリングされる頂点プログラムごとに、各属性について、２つの属性の要素の数の合計が４以下となる互換性のある属性を特定する。ストリームを１つの属性に結合し、頂点プログラムを適宜変更して、パフォーマンスゲインを測定する。
ａ）−相互に使用されている属性配列を特定する。一意の属性データ配列ごとに、その属性配列を使用する各描画呼び出しに対して、現在の属性配列から描画呼び出しで使用されている他の属性配列へのソフトリンクを行い、描画呼び出し内で現在の属性配列が使用された回数のカウントをインクリメントし、この描画呼び出しと共に他の各属性配列が使用された回数のカウントを保持する。次に、一意の属性配列ごとに、その属性配列からのソフトリンクごとに、リンクされている属性配列が現在の属性配列と共に使用された回数のカウントが、現在の属性配列が使用された回数と等しい場合には、その属性へのハードリンクを作成する。この時点の後は、ソフトリンクはもはや使用されない。
ｂ）−各頂点属性配列と共に使用される頂点プログラムを特定する。一意の頂点属性配列ごとに、頂点配列を使用する全描画呼び出しをたどり、各描画呼び出しで使用されるプログラムのそれぞれを、属性ごとの配列頂点プログラムリストに追加することによって、その属性配列と共に使用される頂点プログラムのリストを作成する。
ｃ）−頂点プログラムごと、およびその頂点プログラムの有効な入力属性ごとに、頂点プログラム命令をたどり、各入力属性の使用された要素を記述する各入力に対してマスクを生成する。得られる入力属性の使用された要素マスクを、各属性配列の使用された要素マスクと結合する。（使用された要素マスクは、記憶されている要素マスクと異なり、ｘ、ｘｙ、ｘｙｚまたはｘｙｗｚである点に留意されたい）
ｄ）−一意の属性配列ごと、および同じフォーマットのその属性配列のハードリンクごとに、リンクされている属性配列の使用された属性カウントに、現在の属性配列の使用された属性カウントを加えた値が４以下の場合、属性を１つの配列に結合し、現在の属性配列の頂点プログラムリスト内の頂点プログラムごとにプログラム命令をたどり、新しいレイアウトに従って、要素マスクおよび要素スウィズルのいずれかを更新する。変更が行われた間、ｄ）を繰り返す。
ｅ）−実装で実行される各オペレーションから、パフォーマンスゲインを測定して表示する。
【０１３２】
頂点プログラムセットの使用
この試験例では、プッシュバッファを分析して、複数回セットされている頂点プログラムと、これらの間の頂点プログラムセットが特定される。これらの頂点プログラムの全てを、全ての利用可能な命令スロットにパックすることができるかどうかが判定される。次に、全ての頂点プログラムを同時にセットするためにプッシュバッファが変更され、次の組のそれぞれを実行スロットの変更に変更する。各頂点プログラムがパックされ、得られるパフォーマンスゲインが示される。一実施形態では、新しい頂点プログラムセットを与えるためにエクスポート機能が提供される。
【０１３３】
テクスチャミップマップのバイアス
この試験例では、テクスチャフィルタコマンドごとに、ミップマップが０と１の間で０．１ずつバイアスされ、パフォーマンスゲインが測定される。例示的な一表示には、テクスチャフィルタコマンドごとに、使用されるミップマップバイアスに対する相対パフォーマンスゲインを示すグラフが含まれる。
【０１３４】
複数のレンダリングターゲット設定の再生の最適化
複数のレンダリングターゲットを有するレンダリングターゲットごとに、各レンダリングターゲットが、同じコンテキスト位置にあり、全く同一の同じタイリングおよび圧縮設定を有することを保証する。同一ではなく、未タイリングのバッファをタイリングするのに十分な未使用のタイルが存在する場合には、同一となるように属性を変更して、パフォーマンスゲインを測定する。この試験例はタイルパッキングに依存することが理解されるべきである。適用可能なレンダリングターゲットごとに、各バッファのパフォーマンスゲイン、タイリング設定および圧縮設定を示す。
【０１３５】
非インデックスド描画からインデックスド描画への変更
ここで、非インデックスド描画呼び出しごとに、インデックスバッファを生成し、これにメッシュオプティマイザを実行して、パフォーマンスゲインを測定する。表示の一例には、非インデックスド描画呼び出しをインデックスドに変更することによるパフォーマンスゲインの表示が含まれる。
【０１３６】
フラグメントプログラムのコンテキスト位置
フラグメントプログラムごとに、現在存在する位置とは反対の位置にフラグメントプログラムを移動させ、パフォーマンスの差を測定する。表示の一例には、プログラムの移動によるパフォーマンスの差と、プログラムの移動先が含まれる。
【０１３７】
頂点プログラム内の静的分岐の特定
定数に基づく分岐を含む頂点プログラムごとに、頂点プログラムの複数のコピーを、可能な制御パスごとに１つずつ作成する。定数を変更する代わりに、適切な新しい頂点プログラムをセットする。一実施形態では、命令を最適に順序付けるために、頂点プログラムが再スケジューリングされうる。適用可能な頂点プログラムごとに、新しい頂点プログラムのほか、パフォーマンスゲインと静的に分岐されている定数を表示する。また、新しい頂点プログラムをエクスポートする機能も提供する。
【０１３８】
メインメモリのレンダリングの転送
メインメモリ内に色バッファまたは深度バッファを有するレンダリングターゲットごとに、全てのバッファをビデオメモリに入れる。次に、レンダリング後に、プッシュバッファにコマンドを追加し、レンダリングの結果をメインメモリにブリット（blit）する。パフォーマンスゲインを測定し表示する。
【０１３９】
プリミティブリスタート
三角形ストリップを使用するインデックスド描画呼び出しごとに、インデックスバッファ内で、縮退三角形を表すパターン（ＡＢＣＤ＋ＤＥＥＦ＋ＥＦＧＨまたはＡＢＣ＋ＣＤＤＤＥ＋ＤＥＦまたはＡＢＣ＋ＣＣＤＤＥ＋ＤＥＦまたはＡＢＣ＋ＣＤＤＥＥ＋ＤＥＦ）を検出し、これをプリミティブリスタートインデックスに置換する。パフォーマンスゲインを測定し、変更した描画呼び出しごとに、プリミティブリスタートの使用によるパフォーマンスゲインを表示する。
【０１４０】
量子化
頂点配列ごとに、各入力の範囲を特定する。この範囲が、それが現在指定されているよりも小さな型で表現可能である場合、頂点配列をその小さな型に変換し、パフォーマンスゲインを測定する。小さな入力を大きな入力にリマップするために、頂点シェーダへの命令に定数を加算および乗算することが必要となりうる。入力をリマップするための式は、（Ａ×Ｂ）＋Ｃであり、Ａは、頂点プログラムに入力される値、Ｂはこの値を元の範囲に移す定数、Ｃは元の数が存在していた空間に値をオフセットする定数である。ツールの観点からみると、定数Ｂは、頂点配列内の最大値からこの配列内の最小値を減算することによって求めることができる。定数Ｃは、頂点配列内の最小値である。プログラムのユーザからの入力は、この量子化において許容される最小エラー許容度を定義する。表Ｂに、最小エラー許容度の範囲を示す。
【表１】


この試験例の表示には、頂点配列ごと、および変更されたその配列内の入力ごとに、新しいフォーマットおよび定数のほか、この変更によるパフォーマンスゲインが含まれうる。
【０１４１】
定数のフォールディング
定数のフォールディングは、定数式を事前に計算することによる、頂点／フラグメントプログラムの効率向上のための手法である。このような事前に計算された定数式は、ＰＰＵで計算され、次に、既存の頂点／フラグメントプログラム定数の追加または置換としてアップロードされる。例えば、式ｍｕｌ（Ｗｏｒｌｄ，ｍｕｌ（Ｖｉｅｗ，Ｐｒｏｊｅｃｔｉｏｎ））および式ｓｉｎ（ｔｉｍｅ）が、実行前に頂点／フラグメントプログラムの外でＰＰＵによって評価されうる。移動可能な頂点／フラグメントプログラムの演算は、均一なパラメータと関連する演算、すなわち、各頂点または断片について不変の演算である。定数のフォールディングにより、プログラム当たり命令数を削減でき、プログラムが使用する定数レジスタの数も削減することができる。
【０１４２】
一実施形態では、命令グラフが作成される。この命令グラフから、命令への全ての入力値が定数である命令が特定される。この命令から結果を計算し、この結果を定数として追加する。フォールディングできる定数がなくなるまで、このプロセスを繰り返す。全ての未使用の定数が削除される。表示には、頂点／フラグメントプログラムごとに、新しいプログラム命令と、擬似コードとしてプリシェーダが含まれうる。簡単なＣ関数に新しい頂点プログラムと共に、プレシェーダ自体を渡すために、エクスポート機能が提供されうる。
【０１４３】
完全頂点プログラム定数のパッキング
頂点プログラムごとに、全ての定数の使用済みの要素を特定する。定数ごとに、２つの定数の合計の要素の数が４以下となる別の定数を見つける。これらの定数を１つの定数に結合し、この変化を反映するためにプッシュバッファと頂点プログラムを変更して、パフォーマンスゲインを測定する。上で説明したように、複数の頂点プログラムにわたって使用されている定数に注意を払う必要がある。
ａ）−要素マスク配列の作成−頂点プログラムごとに、命令をたどり、使用済みの要素、明示的な定数のインデックスと共に使用されている任意の使用済みの定数をマークする（オフセットされている定数のインデクシングは無視）。この段階後に、各可能な定数の使用されている要素を表す、エントリ当たり４ビットのサイズが５４４の配列が定義される。
ｂ）−再利用可能リソースとしての頂点プログラム定数−頂点プログラム定数の組ごとに、各描画呼び出しについて定数が別の定数によって上書きされるまで、および描画呼び出しと共に使用される頂点プログラムごとに、以前に生成した使用済み要素マスク内で、定数の組が「使用済み」とマークされている場合、頂点プログラムおよび描画呼び出しをこの定数の組にリンクする。
ｃ）−相互に使用されている定数の特定−頂点プログラム定数の組ごと、およびリンクされている描画呼び出しごとに、その描画呼び出しへのリンクを有する他の全ての頂点プログラム定数の組をたどり、その頂点プログラム定数の組を現在の頂点プログラム定数の組にリンクする。
ｄ）−等しく同時に発生する（コインシデントな）定数の特定−頂点プログラム定数の組ごと、およびリンクされている頂点プログラム定数の組ごとに、現在の頂点プログラム定数の組のリンクされた頂点プログラムにリンクされていない、リンクされた頂点プログラム定数の組のリンクされた頂点プログラムごとに、現在の頂点プログラム定数の組からそのリンクを、リンクされた頂点プログラム定数の組に削除する。
ｅ）使用済み要素マスクの作成−頂点プログラム定数の組ごとに、デフォルトの使用済みマスクを、全ての要素が未使用に設定する。次に、リンクされている頂点プログラムごとに、使用済みの要素マスクを、その定数のための頂点プログラムのための使用済みの要素マスクと結合する。
ｆ）−定数の結合−各頂点プログラム定数の組ごと、およびリンクされている頂点プログラム定数の組ごとに、定数の組の使用済みの要素の数に、リンクされている定数の組の使用済みの要素の数を加えた値が４以下の場合、定数を結合し、リンクされている頂点プログラムごとに、命令をたどり、明示的な定数のインデックスを更新し、更新された定数をスウィズルおよびマスクする。変更が行われた間、ｆ）を繰り返す。
ｇ）−パフォーマンスの差を測定する。
表示には、頂点プログラムごとに、入力定数に対する変更と得られるパフォーマンスゲインが含まれる。エクスポート機能が提供される。
【０１４４】
頂点プログラム出力のパッキング
頂点プログラムごとに、全ての出力の使用済みの要素を特定する。出力ごとに、２つの出力の合計の要素の数が４以下となる別の出力を見つける。これらの出力を１つの出力に結合し、頂点プログラムと、任意の対応するフラグメントプログラムを適宜変更する。最後に、パフォーマンスゲインを測定する。
【０１４５】
表示には、各頂点、変更され、出力が結合されたフラグメントプログラムのほか、この変更からの得られるパフォーマンスゲインが含まれうる。エクスポート機能が提供される。
【０１４６】
線形テクスチャからスウィズルされたテクスチャへの変換
ＤＸＴ圧縮されていない線形テクスチャごとに、このテクスチャをスウィズルされたテクスチャに変換し、全ての関連するテクスチャフォーマットコマンドを更新する。パフォーマンスゲインを測定し、適用可能なテクスチャごとにテクスチャのスウィズルによるパフォーマンスの差を表示する。
【０１４７】
タイリング済みテクスチャからのスウィズルされたテクスチャ
ＤＸＴ圧縮されていないタイリング済みのテクスチャごとに、テクスチャをアンタイリングし、テクスチャデータをスウィズルする。全ての関連するテクスチャフォーマットコマンドを更新し、パフォーマンスゲインを測定して表示する。
【０１４８】
未使用の色チャネルの特定
テクスチャごと、およびこのテクスチャを使用するフラグメントプログラムごとに、テクスチャの使用されている色チャネルを特定する。使用されている色チャネルの数が、小さなテクスチャフォーマットで表されるテクスチャで表現可能な場合、テクスチャフォーマットを変更し、パフォーマンスゲインを測定する。適用可能なテクスチャごとに、パフォーマンスゲイン、前のテクスチャフォーマットと新しいテクスチャフォーマットの説明を表示する。
【０１４９】
フラグメントプログラム内での静的分岐の特定
定数に基づく分岐を含むフラグメントプログラムごと、および定数によるそのフラグメントプログラムの一意のインスタンスごとに、フラグメントプログラムの複数のコピーを、可能な制御パスごとに１つずつ作成する。定数を変更する代わりに、適切な新しいフラグメントプログラムをセットすると共に、任意の関連する定数の組をそのフラグメントプログラムにリダイレクトする。一実施形態では、命令を最適に順序付けるために、フラグメントプログラムが再スケジューリングされる。適用可能なフラグメントプログラムごとに、新しいフラグメントプログラムのほか、パフォーマンスゲインと静的に分岐されている定数を表示する。また、新しいフラグメントプログラムをエクスポートする機能も提供する。
【０１５０】
線形レンダリングターゲットからスウィズルされたレンダリングターゲットへの変換
表示レンダリングターゲットではなく、関連するテクスチャを有する線形のレンダリングターゲットごとに、レンダリングターゲットを幅と高さにおいて２のべき乗にする。レンダリングターゲットをスウィズルされたタイプに変更し、パフォーマンスゲインを測定して表示する。
【０１５１】
タイリング済みレンダリングターゲットからスウィズルされたレンダリングターゲットへの変換
表示レンダリングターゲットではなく、関連するテクスチャを有するタイリング済みのレンダリングターゲットごとに、レンダリングターゲットを幅と高さにおいて２のべき乗にする。レンダリングターゲットの色バッファおよび深度バッファをアンタイリングし、レンダリングターゲットをスウィズルされたタイプに変更し、パフォーマンスゲインを測定して表示する。
【０１５２】
例えば、図２８は、本発明の一実施形態によるセルプロセッサの一種１０００を示すが、これに限定されるものではない。この例では、セルプロセッサ１０００は、メインメモリ１００２、パワープロセッサエレメント（ＰＰＥ）１００４、および多くの相乗的プロセッサエレメント（ＳＰＥ）１００６を有する。この例では、セルプロセッサ１０００は１つのＰＰＥ１００４と８つのＳＰＥ１００６を備える。このような構成において、ＳＰＥ１００６のうちの７つは並列処理のために使用され、１つのプロセッサは、他の７つのプロセッサの１つが故障したときのバックアップとして予約されうる。別の実施形態では、セルプロセッサが、ＰＰＥの複数のグループ（ＰＰＥのグループ）と、ＳＰＥの複数のグループ（ＳＰＥのグループ）を有していてもよい。このような場合、ハードウェア資源が、グループ内のユニット間で共有されうる。しかし、ＳＰＥとＰＰＥは、ソフトウェアからみて、独立したエレメントでなければならない。このように、本発明の実施形態は、図に示す構成との使用に限定されない。
【０１５３】
メインメモリ１００２は、通常、汎用の不揮発性の記憶装置のほかに、システム構成、データ転送同期、メモリマップドＩ／ＯおよびＩ／Ｏサブシステムなどの機能に使用される特殊用途のハードウェアレジスタまたは配列も有する。本発明の実施形態では、信号処理プログラム１００３は、メインメモリ１００２に置かれうる。信号処理プログラム１００３は、ＰＰＥで実行されうる。プログラム１００３は、複数の信号１００９処理タスクに分割され、これらは、ＳＰＥおよび／またはＰＰＥで実行することができる。
【０１５４】
例えば、ＰＰＥ１００４は、関連するキャッシュＬ１およびＬ２を有する６４ビットＰｏｗｅｒＰＣプロセッサユニット（ＰＰＵ）であってもよい。ＰＰＥ１００４は、汎用の処理ユニットであり、システム管理資源（例えば、メモリ保護テーブルなど）にアクセスすることができる。ハードウェア資源は、ＰＰＥによって参照される実アドレス空間に明示的にマップされうる。このため、ＰＰＥは、任意の適切な実効アドレス値を用いて、これらの資源のいずれをも直接アドレス指定を行うことができる。ＰＰＥ１００４の主な機能は、セルプロセッサ１０００内のＳＰＥ１００６のタスクの管理と割り当てである。
【０１５５】
１つのＰＰＥしか図示されていないが、セルブロードバンドエンジンアーキテクチャ（ＣＢＥＡ）などのセルプロセッサの一部の実装では、セルプロセッサ１０００が、ＰＰＥのグループに編成された複数のＰＰＥを有していてもよく、このグループは２つ以上存在しうる。これらのＰＰＥのグループは、メインメモリ１００２へのアクセスを共有しうる。更に、セルプロセッサ１０００が、２つ以上のＳＰＥのグループを有していてもよい。ＳＰＥのグループも、メインメモリ１００２へのアクセスを共有しうる。このような構成は、本発明の範囲に含まれる。
【０１５６】
各ＳＰＥ１００６は、相乗的プロセッサユニット（ＳＰＵ）と自身のローカル記憶領域ＬＳを有する。ローカル記憶域ＬＳは、メモリ領域の、それぞれが特定のＳＰＵと関連付けられた１つ以上の別個の領域を有しうる。各ＳＰＵは、自身の関連するローカル記憶域ドメインにある命令（データロード操作とデータストア操作を含む）のみを実行するように構成されうる。このような構成では、ローカル記憶域ＬＳとシステム１０００の他の部分との間のデータ転送は、メモリフローコントローラ（ＭＦＣ）からダイレクトメモリアクセス（ＤＭＡ）コマンドを発行して、（個々のＳＰＥの）ローカル記憶域ドメインとの間でデータを転送することによって実行されうる。ＳＰＵは、演算ユニットとしては、システム管理機能を実行しないという点で、ＰＰＥ１００４ほどは複雑でない。ＳＰＵは、一般に、単一命令複数データ（ＳＩＭＤ）機能を有し、通常は、その割当タスクを実行するために、データを処理して、任意の要求されたデータ転送を開始する（ＰＰＥによって設定されたアクセスプロパティに制約される）。ＳＰＵの目的は、高密度の演算ユニットを必要とし、与えられた命令セットを効率的に使用することができるアプリケーションを可能にすることにある。ＰＰＥ１００４によって、システム内の多くの数のＳＰＥが管理されることにより、多様なアプリケーションにわたり、コスト効率の高い処理が可能となる。
【０１５７】
ＳＰＥ１００６のそれぞれは、メモリ保護およびアクセス許可の情報を保持および処理することができる関連するメモリ管理ユニット（ＭＭＵ）を有する、専用のメモリフローコントローラ（ＭＦＣ）を有しうる。ＭＦＣは、セルプロセッサの主記憶域とＳＰＥのローカル記憶域間でのデータの転送、保護および同期のための主要な方法を提供している。ＭＦＣコマンドは、実行すべき転送を規定している。データを転送するためのコマンドは、時として、ＭＦＣダイレクトメモリアクセス（ＤＭＡ）コマンド（またはＭＦＣ ＤＭＡコマンド）と呼ばれる。
【０１５８】
各ＭＦＣは、同時に複数のＤＭＡ転送に対応することができ、複数のＭＦＣコマンドを保持および処理することができる。各ＭＦＣ ＤＭＡデータ転送コマンド要求には、ローカル記憶域アドレス（ＬＳＡ）と実効アドレス（ＥＡ）が含まれうる。ローカル記憶域アドレスは、その関連するＳＰＥのローカル記憶領域のみを直接アドレス指定しうる。実効アドレスは、より一般的な用途を有することができ、例えば、実アドレス空間にエイリアスされている場合には、全てのＳＰＥローカル記憶領域を含む主記憶装置を参照することができる。
【０１５９】
ＳＰＥ１００６間、および／またはＳＰＥ１００６とＰＰＥ１００４間の通信を容易にするために、ＳＰＥ１００６とＰＰＥ１００４は、信号発生事象に結び付けられた信号通知レジスタを有しうる。ＰＰＥ１００４とＳＰＥ１００６は、ＰＰＥ１００４がＳＰＥ１００６にメッセージを伝達するルーターとして機能するスター型トポロジに結合されていてもよい。別の実施形態では、ＳＰＥ１００６とＰＰＥ１００４のそれぞれが、メールボックスと呼ばれる一方向の信号通知レジスタを有していてもよい。メールボックスは、オペレーティングシステム（ＯＳ）の同期をホストするために、ＳＰＥ１００６によって使用されうる。
【０１６０】
セルプロセッサ１０００は、入出力（Ｉ／Ｏ）機能１００８を備え、この機能によって、セルプロセッサ１０００は、他のモジュール、プロセッサまたは周辺機器とインタフェースしうる。一例では、Ｉ／Ｏ１００８は、グラフィックハードウェアエンジン１０２（図１）とインタフェースしうる。商業的に入手可能なプロセッサの例として、リアリティシンセサイザ（ＲＳＸ）が挙げられるが、ほかのプロセッサも可能である。
【０１６１】
更に、エレメント相互接続バス１０１０は、上に挙げた各種の構成要素を接続しうる。ＳＰＥとＰＰＥのそれぞれは、バスインタフェースユニットＢＩＵを介してバス１０１０にアクセスしうる。また、セルプロセッサ１０００は、通常はプロセッサ内にある、バス１０１０とメインメモリ１００２間のデータの流れを制御するメモリインタフェースコントローラ（ＭＩＣ）と、Ｉ／Ｏ１００８とバス１０１０間のデータの流れを制御するバスインターフェースコントローラ（ＢＩＣ）の２つのコントローラを有しうる。ＭＩＣ、ＢＩＣ、ＢＩＵおよびバス１０１０に対する要件は、実装によって大きく変わりうるが、当業者であれば、その機能とそれを実装するための回路について熟知しているであろう。
【０１６２】
セルプロセッサ１０００は、内部割込みコントローラ（ＩＩＣ）も有しうる。
ＩＩＣコンポーネントは、ＰＰＥに提示される割り込みの優先度を管理している。ＩＩＣによって、セルプロセッサ１０００は、メインシステムの割込みコントローラを使用することなく、他の構成要素からの割り込みを処理できるようになる。ＩＩＣは、２次レベルのコントローラであると考えることができる。メインシステムの割込みコントローラは、セルプロセッサの外で発生した割込みを処理しうる。
【０１６３】
本発明の実施形態では、上記の微小な遅延などの特定の計算は、ＰＰＥ１００４および／またはＳＰＥ１００６の１つ以上を使用して、並列で実行されうる。微小な遅延計算のそれぞれは１つ以上の別個のタスクとして実行され、これらは、異なるＳＰＥ１００６が利用可能になると、それが処理しうる。
【０１６４】
本発明は、ゲームコンソール、ゲームコンピュータまたはコンピューティングデバイス、携帯式デバイス、マイクロプロセッサシステム、マイクロプロセッサベースのプログラム可能な家庭用電気製品、ミニコンピュータ、メインフレームコンピュータなど、他のコンピュータシステムの構成によって実施されてもよい。また、本発明は、分散コンピューティング環境で実施されてもよく、このような環境では、ネットワークを介してリンクされる遠隔処理デバイスによってタスクが実行される。例えば、オンラインのゲームシステムおよびソフトウェアが使用されてもよい。
【０１６５】
上記の実施形態を考慮に入れて、本発明が、コンピュータシステムに記憶されたデータを使用する、各種のコンピュータ実装操作を使用してもよい点を理解すべきである。これらの操作は、物理量の物理的操作を必要とする。この物理量は通常、記憶、転送、結合、比較などの操作が可能な電気信号または磁気信号の形を取るが、必ずしもこれらに限定されない。更に、実行される操作は、生成、特定、決定または比較などと呼ばれることが多い。
【０１６６】
本発明の一部を構成している、本明細書に記載した操作はいずれも、有用な機械的操作である。本発明は、これらの操作を実行するデバイスまたは装置にも関する。この装置は、上記に記載したキャリアネットワークなどの所望の目的のために特別に作製されたものであっても、あるいは汎用コンピュータであり、そのコンピュータに記憶されているコンピュータプログラムによって選択的に作動もしくは構成されてもよい。特に、各種の汎用の機械を、本明細書の教示に従って記述したコンピュータプログラムと併用してもよく、あるいは所望の操作を実行するために特化した機械を作製するほうが利便性が高いこともある。
【０１６７】
本発明は、また、計算機可読メディア上の計算機可読コードとして実施されてもよい。計算機可読媒体は、コンピュータシステムによって後から読取ることができるデータを記憶できるデータ記憶装置であれば、どのようなものであってもよい。計算機可読媒体の例には、ハードディスク、ネットワーク接続記憶装置（ＮＡＳ）、リードオンリーメモリ、ランダムアクセスメモリ、ＦＬＡＳＨベースメモリ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ、磁気テープおよび他の光学式データ記憶装置および非光学式データ記憶装置などがある。また、計算機可読メディアは、計算機可読コードが分散式に記憶されて、実行されるように、ネットワークに結合されたコンピュータシステムを介して分散されてもよい。
【０１６８】
上記に、本発明を明確に理解できるように多少詳細に記載したが、添付の特許請求の範囲内で変更例または変形例を実施できることは明らかである。したがって、本実施形態は例示的なものであり、制限するものではなく、本発明は本明細書に記載されている詳細な事項に限定されず、添付の特許請求の範囲およびその均等物の範囲内で変更されてもよい。

【特許請求の範囲】
【請求項１】
アプリケーションの実行中に生成される複数フレームビデオシーケンスのフレームに対してパフォーマンス分析を実行するためのシステムであって、
（ｉ）前記アプリケーションを実行するように構成されたハードウェアエンジンと、
（ｉｉ）前記ハードウェアエンジンから、前記複数フレームビデオシーケンスの前記フレームに対するプッシュバッファデータを取得するように構成されたライブラリキャプチャモジュールと、
（ｉｉｉ）前記プッシュバッファデータの内容のインタラクティブな表示を提示するためのグラフィカルユーザインタフェースと、前記内容は、複数のコマンドと、前記複数のコマンドのそれぞれに関連するデータとを定義し、前記グラフィカルユーザインタフェースは、前記プッシュバッファの前記内容に変更を行うためにアクセスを可能にし、
（ｉｖ）前記グラフィカルユーザインタフェースによって行われる変更により、前記プッシュバッファデータの再実行を可能する再生モジュールと、を有し、
前記グラフィカルユーザインタフェースは、前記プッシュバッファに変更が行われた場合に、前記プッシュバッファの実行の差を定量化する複数のパフォーマンス分析測定を提供するシステム。
【請求項２】
前記グラフィカルユーザインタフェースは、前記アプリケーションの変更を実行せずに、前記プッシュバッファデータに変更を行うために前記アクセスを可能にする請求項１に記載のパフォーマンス分析を実行するためのシステム。
【請求項３】
前記プッシュバッファに対する変更と、変更による前記プッシュバッファの再実行とは、前記アプリケーションに対する変更が行われたと仮定した場合の前記アプリケーションのパフォーマンスをシミュレーションする請求項１に記載のパフォーマンス分析を実行するためのシステム。
【請求項４】
前記アプリケーションは、前記ライブラリキャプチャモジュールに転送されるプッシュバッファデータを収集させるためにトリガされうる関数呼び出しを有する請求項１に記載のパフォーマンス分析を実行するためのシステム。
【請求項５】
前記プッシュバッファデータは、前記転送からデータの配列で取得される請求項４に記載のパフォーマンス分析を実行するためのシステム。
【請求項６】
前記ライブラリキャプチャモジュールは、前記データの配列から取得されるプッシュバッファデータにより生成されたライブラリを生成する請求項５に記載のパフォーマンス分析を実行するためのシステム。
【請求項７】
前記プッシュバッファデータの内容の前記インタラクティブな表示を生成するために、前記ライブラリが前記グラフィカルユーザインタフェースによってアクセスされる請求項６に記載のパフォーマンス分析を実行するためのシステム。
【請求項８】
前記グラフィカルユーザインタフェースは、前記複数のパフォーマンス分析測定を表すための複数のメニューおよびウィンドウを提供し、前記複数メニューおよびウィンドウからの選択により、前記プッシュバッファデータの前記内容に対する変更が可能となる請求項７に記載のパフォーマンス分析を実行するためのシステム。
【請求項９】
前記プッシュバッファデータに対する仮定変更を更に有し、前記仮定変更は、前記プッシュバッファデータに対する変更の組を定義し、前記変更の組は、前記アプリケーションに対する変更を行ったと仮定するが、前記アプリケーションのコードは変更せずに前記アプリケーションのパフォーマンスをシミュレーションするように構成されている請求項３に記載のパフォーマンス分析を実行するためのシステム。
【請求項１０】
アプリケーションのためにビデオフレームのレンダリング特性を最適化するための方法であって、
ビデオフレームをレンダリングするステップと、
前記ビデオフレームの前記レンダリングを表すプッシュバッファ設定をキャプチャするステップと、
前記プッシュバッファ設定のアスペクトを変更し、前記変更は前記アプリケーションをバイパスするステップと、
前記変更されたアスペクトにより前記フレームを再レンダリングするステップと、
前記レンダリングを前記再レンダリングと比較するステップと、
比較結果を提示するステップと、を有する方法。
【請求項１１】
前記キャプチャするステップは、前記プッシュバッファ設定をコピーするために前記アプリケーションに埋め込まれた関数を呼び出すステップを有する請求項１０に記載の方法。
【請求項１２】
前記変更されるアスペクトは、冗長コマンド、レンダリング状態の最適化、リソース位置、頂点配列構造、未使用の頂点配列データ、定数頂点配列データ、未使用の頂点プログラムの出力データ、メッシュの最適化、三角形トリミング、深度ソーティング、深度のみのパス、フラグメントプログラムレジスタカウントの最適化、代替テクスチャ圧縮フォーマット、テクスチャメモリのグループ化、頂点プログラムのグループ化、レンダリングターゲットのタイリングおよび深度カリングエリア、ならびに頂点プログラムの最適化からなる群から選択される請求項１０に記載の方法。
【請求項１３】
前記方法は連続するフレームに実行される請求項１０に記載の方法。
【請求項１４】
前記方法はｎおきのフレームに実行される（ｎは２以上の整数）請求項１０に記載の方法。
【請求項１５】
前記変更するステップは、「仮定」変更部を選択するステップを有する請求項１０に記載の方法。
【請求項１６】
前記プッシュバッファの複数のアスペクトを変更するステップと、
各変更されたアスペクトのそれぞれの影響を分類するステップと、
前記複数のアスペクトの変更の全体的な影響を分類するステップと、を更に有する請求項１０に記載の方法。
【請求項１７】
前記複数のアスペクトの変更は前記アプリケーションのコードを変更せずに実行される請求項１６に記載の方法。
【請求項１８】
前記再レンダリングするステップは、前記変更されたアスペクトを前記プッシュバッファにコミットするステップを有する請求項１０に記載の方法。
【請求項１９】
前記比較するステップは、前記レンダリングおよび前記再レンダリングのためのレンダリング時間を計算するステップを有する請求項１０に記載の方法。
【請求項２０】
ビデオフレームレンダリングを最適化するためのグラフィカルユーザインタフェース（ＧＵＩ）であって、
プッシュバッファの内容を示す表示領域と、
前記プッシュバッファの前記内容に従ってビデオフレームをレンダリングすることに対するグラフィカルな結果を示すパフォーマンス表示領域と、
前記プッシュバッファの内容の変更を可能にするプッシュバッファ内容変更領域と、を有するＧＵＩ。
【請求項２１】
前記プッシュバッファの内容を示す前記表示領域は、ドローコンテキストに従って構成される請求項２０に記載のＧＵＩ。
【請求項２２】
前記プッシュバッファ変更領域は、変更前に、前記プッシュバッファの内容に対する、前記プッシュバッファの内容の前記変更のプロファイリングを可能にする請求項２０に記載のＧＵＩ。
【請求項２３】
前記ビデオフレームをレンダリングするためにドローコンテキストによって参照される各リソースを示すレンダリング状態ビューウィンドウを更に有する請求項２０に記載のＧＵＩ。
【請求項２４】
レンダリングターゲットプレビューモードウィンドウ、テクスチャウィンドウ、頂点配列ウィンドウ、インデックス配列ウィンドウ、頂点プログラムウィンドウ、フラグメントプログラムウィンドウ、およびＧＰＵレジスタウィンドウからなる群から選択される複数のサブウィンドウにアクセスするレンダリングターゲットウィンドウを更に有する請求項２０に記載のＧＵＩ。
【請求項２５】
前記パフォーマンス表示領域は、ドローコンテキストに対する前記ＧＰＵのサブユニットの利用度を重ねて表示する請求項２０に記載のＧＵＩ。
【請求項２６】
アプリケーションの実行中に生成される複数フレームビデオシーケンスのフレームに対してパフォーマンス分析を実行するためのシステムであって、
（ｉ）キャプチャトリガハードウェアロジックと通信し、前記アプリケーションを少なくとも部分的に実行するように構成されたハードウェアエンジンと、
（ｉｉ）前記キャプチャトリガハードウェアロジックによる処理に応答して、前記ハードウェアエンジンから、前記複数フレームビデオシーケンスの前記フレームに対するプッシュバッファデータを取得するように構成されたライブラリキャプチャモジュールと、
（ｉｉｉ）前記プッシュバッファデータの内容のインタラクティブな表示を提示するためのグラフィカルユーザインタフェースと、前記内容は、複数のコマンドと、前記複数のコマンドのそれぞれに関連するデータとを定義し、前記グラフィカルユーザインタフェースは、前記プッシュバッファの前記内容に変更を行うためにアクセスを可能にし、
（ｉｖ）前記グラフィカルユーザインタフェースによって行われる変更により、前記プッシュバッファデータの再実行を可能する再生モジュールと、を有し、
前記グラフィカルユーザインタフェースは、前記プッシュバッファに変更が行われた場合に、前記プッシュバッファの実行の差を定量化する複数のパフォーマンス分析測定を提供し、前記グラフィカルユーザインタフェースは、前記アプリケーションの変更を実行せずに、前記プッシュバッファデータに変更を行うために前記アクセスを可能にするシステム。
【請求項２７】
前記キャプチャトリガハードウェアロジックは、前記ハードウェアエンジンと一体化されているか、あるいは、独立したロジックとして前記ハードウェアエンジンとインタフェースされる請求項２６に記載のパフォーマンス分析を実行するためのシステム。
【請求項２８】
前記キャプチャトリガハードウェアロジックは、前記複数フレームビデオシーケンスの選択されたフレームの１つ以上に対する前記プッシュバッファの内容をキャプチャするように構成されている請求項２７に記載のパフォーマンス分析を実行するためのシステム。
【請求項２９】
前記プッシュバッファに対する変更と、変更による前記プッシュバッファの再実行とは、前記アプリケーションに対する変更が行われたと仮定した場合の前記アプリケーションのパフォーマンスをシミュレーションする請求項２６に記載のパフォーマンス分析を実行するためのシステム。

【図１】

【図２】

【図３】

【図４】

【図５】

【図６】

【図７】

【図８】

【図９】

【図１０】

【図１１】

【図１２】

【図１３Ａ】

【図１３Ｂ】

【図１４Ａ】

【図１４Ｂ】

【図１４Ｃ】

【図１４Ｄ】

【図１５】

【図１６】

【図１７】

【図１８】

【図１９Ａ】

【図１９Ｂ】

【図２０Ａ】

【図２０Ｂ】

【図２１Ａ】

【図２１Ｂ】

【図２１Ｃ】

【図２１Ｄ】

【図２１Ｅ】

【図２１Ｆ】

【図２１Ｇ】

【図２１Ｈ】

【図２１Ｉ】

【図２１Ｊ】

【図２１Ｋ】

【図２２】

【図２３Ａ】

【図２３Ｂ】

【図２４Ａ】

【図２４Ｂ】

【図２５Ａ】

【図２５Ｂ】

【図２５Ｃ】

【図２５Ｄ】

【図２６Ａ】

【図２６Ｂ】

【図２６Ｃ】

【図２６Ｄ】

【図２６Ｅ】

【図２６Ｆ】

【図２６Ｇ】

【図２６Ｈ】

【図２６Ｉ】

【図２６Ｊ】

【図２６Ｋ】

【図２６Ｌ】

【図２６Ｍ】

【図２６Ｎ】

【図２６Ｏ】

【図２７Ａ】

【図２７Ｂ】

【図２７Ｃ】

【図２７Ｄ】

【図２７Ｅ】

【図２８】

【公表番号】特表２０１０−５２０５５５（Ｐ２０１０−５２０５５５Ａ）
【公表日】平成２２年６月１０日（２０１０．６．１０）
【国際特許分類】
【出願番号】特願２００９−５５２７０２（Ｐ２００９−５５２７０２）
【出願日】平成２０年２月２８日（２００８．２．２８）
【国際出願番号】ＰＣＴ／ＵＳ２００８／００２７４４
【国際公開番号】ＷＯ２００８／１２７５１７
【国際公開日】平成２０年１０月２３日（２００８．１０．２３）
【出願人】（５００５５１０７９）ソニー・コンピュータ・エンタテインメント・アメリカ・インク (95)
【Ｆターム（参考）】