グラフィックス フレーム分析

Visual Studio のグラフィックス診断でグラフィックス フレーム分析を使用して、Direct3D ゲームまたはアプリケーションのレンダリング パフォーマンスを分析し、最適化することができます。

注意

Visual Studio 2013 Update 3 以降、グラフィックス診断ツールのウィンドウは、独立した Visual Studio シェルのコピー内でホストされます。グラフィックス分析と呼ばれるこのカスタマイズされたシェルでは、不要なメニューとオプションは表示されなくなりますが、その点を除けば、以前と同じフレーム分析とワークフローが提供されます。この変更の詳細については、「グラフィックス診断の概要」を参照してください。

フレーム分析

フレーム分析では、診断の目的でグラフィックス ログ ファイルにキャプチャされている情報と同じものを使用しますが、レンダリング パフォーマンスを要約するために、代わりにこれを使用します。 パフォーマンス情報は、キャプチャ中にはログに記録されませんが、フレーム分析のときに後で生成されます。これはフレームが再生されたときに、イベントのタイミングをはかり、統計を収集することによって生成されます。 このアプローチでは、キャプチャ中にパフォーマンス情報を記録する方法に比べて次のメリットがあります。

• フレーム分析は、同じフレームを複数回再生することにより平均的な結果を得られるため、パフォーマンス サマリーを統計的に信頼できる。

• フレーム分析は、情報がキャプチャされた以外のハードウェア構成およびデバイスのパフォーマンス情報を生成できる。

• フレーム分析は、以前にキャプチャした情報から新しいパフォーマンス サマリーを生成できる (例: GPU ドライバーが最適化された、または追加のデバッグ機能を公開した場合など)。

これらのメリットの他にも、フレーム分析を使用して、再生時にフレームをレンダリングする方法を変更し、これらの変更がアプリのレンダリング パフォーマンスにどのような影響を与えるかについて情報を提示することができます。 この情報を使用すると、最適化の方法として考えられるすべての選択肢を実装し、それらをキャプチャして結果を比較したりせずに、方法を決定することができます。

フレーム分析は主にレンダリング パフォーマンスを向上させることを意図していますが、同様に、特定のパフォーマンス ターゲットに対して表示品質を向上させる、または GPU の電力消費を低下させるうえでも有用です。

Channel 9 のビデオ「Visual Studio Graphics Frame Analysis (Visual Studio のグラフィックス フレーム分析)」で、アプリでのフレーム分析の使用方法に関するデモを視聴できます。

フレーム分析の使用

フレーム分析を使用する前に、グラフィックス診断を使用した場合と同様に、アプリケーションから実行するグラフィックス情報をキャプチャする必要があります。 次に、グラフィックス ログのドキュメント (.vsglog) のウィンドウで、[フレーム分析] タブを選択します。

分析が完了すると、結果が表示されます。 [フレーム分析] タブの上部には、タイムラインとサマリー テーブルが表示されます。 下部には、詳細テーブルが表示されます。 再生中にエラーまたは警告が生成された場合は、タイムラインの上に概要が示されます。そこからリンクに従って、エラーおよび警告の詳細を見ることができます。

結果の解釈

各バリアントの結果を解釈することで、アプリケーションのレンダリング パフォーマンスおよび動作についての有用な情報を推測できます。 レンダリング バリアントの詳細については、このドキュメントの後述の「Variants」を参照してください。

次の結果は、バリアントがレンダリング パフォーマンスにどのように影響しているかを直接示しています。

• Bilinear Texture Filtering バリアントがパフォーマンスの向上を示している場合は、アプリケーションでバイリニア テクスチャ フィルタリングを使用すると、同様のパフォーマンスの向上が得られます。

• 1x1 Viewport バリアントがパフォーマンスの向上を示している場合は、アプリケーションでレンダー ターゲットのサイズを小さくすると、レンダリング パフォーマンスが改善されます。

• BC Texture Compression バリアントがパフォーマンスの向上を示している場合は、アプリケーションで BC テクスチャ圧縮を使用すると、同様のパフォーマンス向上が得られます。

• 2xMSAA バリアントのパフォーマンスが 0xMSAA バリアントとほぼ同じである場合は、アプリケーション内の 2xMSAA で、パフォーマンスを低下させずにレンダリング品質を向上させることができます。

次の結果は、アプリケーションのパフォーマンスについて、より難解で微妙な内容を示している可能性があります。

• 1x1 Viewport バリアントでパフォーマンスが著しく向上している場合、アプリケーションは、使用できるよりも多くのフィルレートを使用している可能性があります。 このバリアントでパフォーマンスが向上していない場合、アプリケーションで処理している頂点の数が多すぎることが考えられます。

• 16bpp Render Target Format バリアントでパフォーマンスが著しく向上している場合、アプリケーションで使用しているメモリ帯域幅が多すぎる可能性があります。

• Half/Quarter Texture Dimensions バリアントでパフォーマンスが著しく向上している場合、テクスチャで占有しているメモリが多すぎる、使用している帯域幅が多すぎる、またはテクスチャ キャッシュの使用効率が悪いことが考えられます。 このバリアントでパフォーマンスが向上していない場合は、パフォーマンスを低下させずに、より大きく細かいテクスチャを使用することができます。

ハードウェア カウンターが使用できる場合は、それらを使用して、アプリケーションのレンダリング パフォーマンスが向上しない原因について詳細な情報を収集できます。 機能レベル 9.2 以降のすべてのデバイスでは、深さの occlusion query (pixels occluded カウンター) とタイムスタンプがサポートされます。 ドライバーの中に GPU メーカーがハードウェア カウンターを実装し、それらを公開しているかどうかによって、他のハードウェア カウンターを使用できる場合があります。 これらのカウンターを使用してサマリー テーブルに示された結果の正確な原因を確認できます。たとえば、深さのテストによってオクルージョンされたピクセルの割合を調べて、描画の大きさが問題かどうかを判断できます。

タイムラインおよびサマリー テーブル

既定では、タイムラインおよびサマリー テーブルが表示され、他のセクションは折りたたまれています。

タイムライン

タイムラインは、相互に関連した描画 - 呼び出しのタイミングの概要を示しています。 描画時間が長い場合には、長いバーが対応しているため、これを使用してフレーム内で最も負荷がかかっている描画呼び出しをすぐに見つけることができます。 キャプチャされたフレームに含まれている描画呼び出しの数が非常に多い場合は、複数の描画呼び出しが 1 つのバーにまとめられ、その長さは描画呼び出しの合計になっています。

バーにポインターを置くと、バーがどの描画 - 呼び出しイベントに対応しているのかわかります。 バーを選択すると、イベント リストが対象のイベントと同期されます。

テーブル

タイムラインの下にある数のテーブルは、アプリケーションの既定のレンダリングについて、各描画呼び出しのレンダリング バリアントの相対パフォーマンスを示しています。 各列は別のレンダリング バリアントを示しており、各行は、一番左の列で確認される別の描画呼び出しを表しています。ここからリンクに従って、[グラフィックス イベント一覧] ウィンドウへナビゲートできます。

サマリー テーブルの左から 2 番目の列は、アプリケーションのベースライン レンダリング時間を示しています。これは、アプリケーションの既定のレンダリングで描画呼び出しを完了するまでにかかる時間です。 残りの列は、各レンダリング バリアントの相対パフォーマンスをベースラインのパーセンテージとして示しているため、パフォーマンスが改善されているかどうか一目でわかります。 パーセンテージが 100 を超えている場合はベースラインよりも長い時間がかかっている、つまりパフォーマンスが低下したことを示しています。パーセンテージが 100 未満の場合は時間がかかっていない、つまりパフォーマンスが向上したことを示しています。

ベースラインの絶対的なタイミングと、レンダリング バリアントの相対的なタイミングの両方の値は、複数回 (既定で 5 回) 実行した場合の実際の平均値です。 この平均化により、タイミング データは信頼性があり、一貫したものになります。 テーブルの各セルにポインターを置くと、描画呼び出しおよびレンダリング バリアントの結果が生成されたときに観察されたタイミングの最小、最大、平均、および中央値を調べることができます。 ベースラインのタイミングも表示されます。

"ホット" 描画呼び出し

全体のレンダリング時間で大きな割合を占めている、または回避できた理由により著しく遅くなっている描画呼び出しを目立たせるために、このような "ホット" な描画呼び出しが含まれている行には赤い影が付けられます。この影は、ベースラインのタイミングが、フレーム内のすべての描画呼び出しの平均のベースライン タイミングよりも、1標準偏差以上長い場合に付けられます。

統計的な有意性

最も高い関連性を持つレンダリング バリエーションを目立たせるために、フレーム分析は、各レンダリング バリアントの統計的な有意性を決定し、重要なものを太字で示します。 パフォーマンスが向上しているものは緑で、パフォーマンスが低下しているものは赤で示されます。 統計的に重要な意味を持たない結果は、通常の書体で示されます。

統計的な関連性を決定するために、フレーム分析は Student's t-test を使用します。

詳細テーブル

詳細テーブルはサマリー テーブルの下にあり、最初の状態では折りたたまれています。 詳細テーブルの内容は、再生コンピューター.のハードウェア プラットフォームによって異なります。 サポートされているハードウェア プラットフォームの詳細については、「Hardware Support」を参照してください。

ハードウェア カウンターをサポートしていないプラットフォーム

ほとんどのプラットフォームは、ハードウェア GPU カウンター (Intel、AMD、nVidia から現在提供されているすべての GPU) を完全にサポートしているわけではありません。 収集するハードウェア カウンターがない場合は、詳細テーブルのみが表示され、すべてのバリアントのタイミングの絶対値の平均が示されます。

ハードウェア カウンターをサポートしているプラットフォーム

ハードウェア GPU カウンターをサポートしているプラットフォーム (nVidia T40 SOC やすべての Qualcomm SOC など) については、各バリアントに 1 つずつ、いくつかの詳細テーブルが表示されます。 使用できるすべてのハードウェア カウンターは各レンダリング バリアントに対して収集され、その詳細テーブルに表示されます。

ハードウェア カウンターの情報は、各描画呼び出しについて特定のハードウェアプラットフォーム動作の詳細なビューを提供します。この情報は、パフォーマンスのボトルネックとなる原因を正確に特定するうえで有用です。

注意

さまざまなハードウェア プラットフォームがさまざまなカウンターをサポートしているため、標準はありません。カウンター、およびカウンターが表す内容は、それぞれの GPU メーカーによってのみ決定されます。

マーカー リージョンとイベント

フレーム分析は、ユーザー定義のイベント マーカーおよびイベント グループをサポートします。 これらはサマリー テーブルと詳細テーブルに表示されます。

ID3DUserDefinedAnnotation API または API のレガシー D3DPERF_ ファミリーのいずれかを使用して、マーカーおよびグループを作成します。 D3DPERF_ API ファミリーを使用すると、各マーカーおよびグループをフレーム分析が表示する色に割り当てることができます。この場合、イベント マーカーまたはイベント グループの開始/終了マーカーおよびその内容が含まれている行に、色つきのバンドとして表示されます。 この機能により、重要なレンダリング イベントまたはイベントのグループをすばやく特定できます。

警告とエラー

フレーム分析の終了時に警告またはエラーが示されることがあります。タイムラインの上には概要が示され、[フレーム分析] タブの下部に詳細が表示されます。

通常、警告とエラーは情報提供のみを目的としており、特別な操作は必要ありません。

警告は一般的に、ハードウェアがサポートされてないが対処はできている、ハードウェア カウンターが収集できない、または (代替手段が逆にマイナスの影響を与えている場合など) 特定のパフォーマンス データが信頼できない可能性があることを示しています。

エラーは一般的に、フレーム分析の実装にバグがある、ドライバーにバグがある、ハードウェアがサポートされていなくて対処できない、または再生でサポートされていないものをアプリケーションで試行していることを示しています。

再試行

フレーム分析中に GPU の電源状態が推移した場合、GPU のクロック速度が変わって相対的なタイミングの結果が無効になっているため、影響を受ける分析パスを再試行する必要があります。

フレーム分析は、再試行を 10 回に制限しています。 プラットフォームに積極的な電源管理またはクロックゲーティングの機能がある場合、これらの機能が再試行の制限を超えたために、フレーム分析が失敗してエラーをレポートする原因となることがあります。 この問題は、プラットフォームの電源管理をリセットすること、およびプラットフォームで可能な場合はクロック速度の調整を少し遅くすることによって、改善できます。

ハードウェア サポート

タイムスタンプおよび occlusion querｙ

タイムスタンプは、フレーム分析をサポートしているすべてのプラットフォームでサポートされています。 (Pixels Occluded カウンターで必要な) 深さの occlusion query は、機能レベル 9.2 以降をサポートしているプラットフォームでサポートされます。

注意

タイムスタンプはフレーム分析をサポートするすべてのプラットフォームでサポートされていますが、タイムスタンプの正確さと一貫性はプラットフォームによって異なります。

GPU カウンター

GPU ハードウェア カウンターのサポートはハードウェアに依存しています。

現在 Intel、AMD、または nVidia で提供されているコンピューター用 GPU で、GPU ハードウェア カウンターを確実にサポートしているものがないため、フレーム分析はこれらの GPU からカウンターを収集しません。 ただし、フレーム分析は、以下のものを確実にサポートしている GPU からハードウェア カウンターを収集します。

• Qualcomm SOC (Windows Phone をサポートしているものすべて)

• nVidia T40 (Tegra4).

フレーム分析をサポートしているプラットフォームで、GPU ハードウェア カウンターを収集するものは他にありません。

注意

GPU ハードウェア カウンターはハードウェア リソースであるため、各レンダリング バリアントのハードウェア カウンター一式は、複数の方法で収集できます。そのため、GPU カウンターの収集順序は指定されていません。

Windows phone

タイムスタンプ、occlusion query、および GPU ハードウェア カウンターは、Windows Phone 8.1 を標準装備している Windows Phone のハンドセットでのみサポートされています。 フレーム分析では、グラフィックス ログ ファイルを再生するためにこれらのものが必要です。 Windows Phone 8 を標準装備していた Windows Phone ハンドセットは、Windows Phone 8.1 へ更新してもフレーム分析はサポートしません。

サポートされていないシナリオ

フレーム分析を使用する方法には、サポートされていない、または推奨されていないものがあります。

WARP

フレーム分析は、実際のハードウェアでレンダリング パフォーマンスをプロファイルおよび改善する目的で使用されます。 (Windows Phone エミュレーターは WARP 上で稼動するため) WARP デバイス上でフレーム分析を実行することは回避できませんが、通常、これは意味のあることではありません。ハイエンド CPU で WARP を実行すると、最も機能の低い最新の GPU よりも処理速度が遅く、WARP パフォーマンスは実行している CPU によって大幅に変わるためです。

低レベル デバイスでの高機能レベル キャプチャの再生

グラフィックス診断で、再生コンピューターがサポートしているよりも高い機能レベルを使用しているグラフィックス ログ ファイルを再生する場合は、自動的に WARP へ低下します。 フレーム分析では、明示的には WARP へ低下せずにエラーが生成されます。WARP は Direct3D アプリケーションの正確さを調べるには有用ですが、パフォーマンスを調べるには向いていません。

注意

機能レベルの問題に留意しておくことは重要ですが、異なるハードウェア構成およびデバイス上でもグラフィックス ログ ファイルをキャプチャおよび再生できます。たとえば、Windows Phone でグラフィックス情報をキャプチャし、デスクトップ コンピューターでそれを再生できます。その逆の処理もサポートされています。いずれの場合でも、ログ ファイルに API が含まれていない限り、または再生コンピューターでサポートされていない機能レベルを使用していない限り、グラフィックス ログを再生することができます。

Direct3D 10 以前

フレーム分析は、Direct3D 11 API に対してのみサポートされています。 アプリケーションで Direct3D 10 API を呼び出すと、これらの API が認識され、グラフィックス診断で使用されていても、フレーム分析は API を認識せず、プロファイルしません。 アプリケーションで Direct3D11 と Direct3D 10 API の両方を使用している場合、Direct3D 11 の呼び出しのみがプロファイルされます。

注意

これは、機能レベルではなく、使用している Direct3D API 呼び出しに対してのみ適用されます。Direct3D 11、Direct3D 11.1、または Direct3D 11.2 API を使用している場合は、任意の機能レベルを使用してもフレーム分析は機能します。

バリアント

再生中に、フレームがレンダリングされる方法に対してフレーム分析が加える変更のことをバリアントといいます。 フレーム分析が調査するバリアントは、レンダリング パフォーマンスまたはアプリケーションの表示品質を改善しようとして行った、一般的で比較的簡単な変更に対応します。たとえば、テクスチャのサイズを小さくする、テクスチャの圧縮を使用する、違う種類のアンチエイリアス処理を有効にする、などの変更です。 バリアントは、通常のレンダリング コンテキストおよびアプリケーションのパラメーターを上書きします。 次に概要を示します。

バリアント	説明
1x1 Viewport Size	すべてのレンダー ターゲットでビューポートのディメンションを 1x1 ピクセルに減らします。 詳細については、「1x1 ビューポイント サイズ バリアント」を参照してください。
0x MSAA	すべてのレンダー ターゲット上で multi-sample anti-aliasing (MSAA) を無効にします。 詳細については、「0x/2x/4x MSAA バリアント」を参照してください。
2x MSAA	すべてのレンダー ターゲット上で 2x multi-sample anti-aliasing (MSAA) を有効にします。 詳細については、「0x/2x/4x MSAA バリアント」を参照してください。
4x MSAA	すべてのレンダー ターゲット上で 4x multi-sample anti-aliasing (MSAA) を有効にします。 詳細については、「0x/2x/4x MSAA バリアント」を参照してください。
Point Texture Filtering	該当するすべてのテクスチャ サンプルに対して、フィルタリング モードを DXD11_FILTER_MIN_MAG_MIP_POINT (point texture filtering) に設定します。 詳細については、「ポイント、バイリニア、トリリニア、およびアニソトロピック テクスチャ フィルタリング バリアント」を参照してください。
Bilinear Texture Filtering	該当するすべてのテクスチャ サンプルに対して、フィルタリング モードを DXD11_FILTER_MIN_MAG_LINEAR_MIP_POINT (bilinear texture filtering) に設定します。 詳細については、「ポイント、バイリニア、トリリニア、およびアニソトロピック テクスチャ フィルタリング バリアント」を参照してください。
Trilinear Texture Filtering	該当するすべてのテクスチャ サンプルに対して、フィルタリング モードを DXD11_FILTER_MIN_MAG_MIP_LINEAR (trilinear texture filtering) に設定します。 詳細については、「ポイント、バイリニア、トリリニア、およびアニソトロピック テクスチャ フィルタリング バリアント」を参照してください。
Anisotropic Texture Filtering	該当するすべてのテクスチャ サンプルに対して、フィルタリング モードを DXD11_FILTER_ANISOTROPIC に設定し、MaxAnisotropy を 16 (16x anisotropic texture filtering) に設定します。 詳細については、「ポイント、バイリニア、トリリニア、およびアニソトロピック テクスチャ フィルタリング バリアント」を参照してください。
16bpp Render Target Format	すべてのレンダー ターゲットおよびバックバッファーに対して、ピクセル形式を DXGI_FORMAT_B5G6R5_UNORM (16bpp、565 形式) に設定します。 詳細については、「16bpp レンダリング ターゲット フォーマット バリアント」を参照してください。
Mip-map Generation	レンダー ターゲットではないすべてのテクスチャで MIP マップを有効にします。 詳細については、「ミップマップ生成バリアント」を参照してください。
Half Texture Dimensions	レンダー ターゲットではないすべてのテクスチャで、テクスチャのディメンションを、各ディメンションの元のサイズの半分に減らします。 たとえば、256x128 のテクスチャは 128x64 テクセルになります。 詳細については、「ハーフ/クォーター テクスチャ ディメンション バリアント」を参照してください。
Quarter Texture Dimensions	レンダー ターゲットではないすべてのテクスチャで、テクスチャのディメンションを、各ディメンションの元のサイズの 4 分の 1 に減らします。 たとえば、256x128 のテクスチャは 64x32 テクセルになります。 詳細については、「ハーフ/クォーター テクスチャ ディメンション バリアント」を参照してください。
BC Texture Compression	B8G8R8X8、B8G8R8A8、または R8G8B8A8 ピクセル形式のバリアントを持つすべてのテクスチャで、ブロック圧縮を有効にします。 B8G8R8X8 形式のバリアントは BC1 を使用して圧縮されます。B8G8R8A8 および R8G8B8A8 形式のバリアントは BC3 を使用して圧縮されます。 詳細については、「BC テクスチャ圧縮バリアント」を参照してください。

ほとんどのバリアントの結果は、「テクスチャ サイズを半分にすると 25 % 高速になる」、「2x MSAA を有効にしても 2% しか遅くならない」のように規範的なものです。 その他のバリアントでは、より詳しい解釈が必要な場合もあります。たとえば、ビューポートのディメンションを 1x1 に変更したバリアントでパフォーマンスが著しく向上した場合、フィルレートが低いことによりレンダリングがボトルネックになっていた可能性を表します。また、パフォーマンスに目立った変化がない場合は、頂点の処理によりレンダリングがボトルネックになっていた可能性を表します。