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

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

フレーム分析

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

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

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

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

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

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

    アプリにフレーム分析を使ってできることのデモについては、チャンネル 9 の「Visual Studio のグラフィックス フレーム分析」のビデオをご覧ください。

フレーム分析の使用

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

[フレーム分析] タブを選択します。

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

結果の解釈

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

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

  • 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標準偏差以上長い場合に付けられます。

この DrawIndexed 呼び出しにはホット バリアントとコールド バリアントがあります。

統計的な有意性

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

描画呼び出しバリアントの統計的関係

統計的な関連性を判断するために、フレーム分析にはスチューデントの t 検定が使用されています。

詳細テーブル

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

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

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

詳細テーブルといくつかの再生バリアント。

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

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

サポートされている場合、ハードウェア カウンターが表示されます。

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

注意

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

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

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

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

警告とエラー

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

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

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

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

再試行

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

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

ハードウェア サポート

タイムスタンプおよび occlusion query

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

注意

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

GPU カウンター

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

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

  • nVidia T40 (Tegra4)

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

注意

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

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

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

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

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

注意

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

Direct3D 10 以前

アプリケーションで Direct3D 10 API を呼び出すと、これらの API が認識され、他の Graphics Analyzer ツールで使用されていても、フレーム分析は API を認識せず、プロファイルしません。

注意

これは、機能レベルではなく、使用している Direct3D API 呼び出しに対してのみ適用されます。

WARP

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

バリアント

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

バリアント 説明
1x1 ビューポート サイズ すべてのレンダー ターゲットでビューポートのディメンションを 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 バリアント」を参照してください。
ポイント テクスチャ フィルタリング 該当するすべてのテクスチャ サンプルに対して、フィルタリング モードを DXD11_FILTER_MIN_MAG_MIP_POINT (point texture filtering) に設定します。

詳細については、「ポイント、バイリニア、トリリニア、およびアニソトロピック テクスチャ フィルタリング バリアント」を参照してください。
バイリニア テクスチャ フィルタリング 該当するすべてのテクスチャ サンプルに対して、フィルタリング モードを DXD11_FILTER_MIN_MAG_LINEAR_MIP_POINT (bilinear texture filtering) に設定します。

詳細については、「ポイント、バイリニア、トリリニア、およびアニソトロピック テクスチャ フィルタリング バリアント」を参照してください。
トリリニア テクスチャ フィルタリング 該当するすべてのテクスチャ サンプルに対して、フィルタリング モードを DXD11_FILTER_MIN_MAG_MIP_LINEAR (trilinear texture filtering) に設定します。

詳細については、「ポイント、バイリニア、トリリニア、およびアニソトロピック テクスチャ フィルタリング バリアント」を参照してください。
アニソトロピック テクスチャ フィルタリング 該当するすべてのテクスチャ サンプルに対して、フィルタリング モードを DXD11_FILTER_ANISOTROPIC に設定し、MaxAnisotropy16 (16x アニソトロピック テクスチャ フィルタリング) に設定します。

詳細については、「ポイント、バイリニア、トリリニア、およびアニソトロピック テクスチャ フィルタリング バリアント」を参照してください。
16bpp レンダリング ターゲット フォーマット すべてのレンダー ターゲットおよびバックバッファーに対して、ピクセル形式を DXGI_FORMAT_B5G6R5_UNORM (16bpp、565 形式) に設定します。

詳細については、「16bpp レンダリング ターゲット フォーマット バリアント」を参照してください。
ミップマップ生成 レンダー ターゲットではないすべてのテクスチャで MIP マップを有効にします。

詳細については、「ミップマップ生成バリアント」を参照してください。
ハーフ テクスチャ ディメンション レンダー ターゲットではないすべてのテクスチャで、テクスチャのディメンションを、各ディメンションの元のサイズの半分に減らします。 たとえば、256x128 のテクスチャは 128x64 テクセルになります。

詳細については、「ハーフ/クォーター テクスチャ ディメンション バリアント」を参照してください。
クォーター テクスチャ ディメンション レンダー ターゲットではないすべてのテクスチャで、テクスチャのディメンションを、各ディメンションの元のサイズの 4 分の 1 に減らします。 たとえば、256x128 のテクスチャは 64x32 テクセルになります。

詳細については、「ハーフ/クォーター テクスチャ ディメンション バリアント」を参照してください。
BC テクスチャ圧縮 B8G8R8X8、B8G8R8A8、または R8G8B8A8 ピクセル形式のバリアントを持つすべてのテクスチャで、ブロック圧縮を有効にします。 B8G8R8X8 形式のバリアントは BC1 を使用して圧縮されます。B8G8R8A8 および R8G8B8A8 形式のバリアントは BC3 を使用して圧縮されます。

詳細については、「BC テクスチャ圧縮バリアント」を参照してください。

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