UE4でNSightを始める内容薄めの手引きになります。 簡単に触る部分だけで深い内容には触れておりません。 説明を砕きすぎて適切でない表現をしている部分もあるかも知れませんが資料最後の参考文献で補強して頂ければと思います。 　　 wcw:HP https://winter-crown-works.com/ contact: contact@winter-crown-works.com

1. アーティスト向け：NSightの手
引き
WinterCrownWORKS

2. 概要
NSightはNVIDIA製の非常に強力なProfiling Toolになります。
この資料ではアーティストが比較的簡単に負荷計測やデバッグを行うための手順をまと
めてみました。
これが最適な方法 という訳ではなく、UnrealEngineの機能や、RenderDocの機能、コ
ンソール用Profilerなどを用途に応じて使い分けるのがより良いProfilingに役立ちます。
今回はお手軽に見れる部分に注力して説明をしていきます。

3. NSightとは？
NVIDIA様のサイトより(翻訳)：
NVIDIA NSight Graphicsは、グラフィックアプリケーションのDebug、プロファイリング、
及び分析のためのStandaloneApplicationです。
DirectCompute,Direct3D(11,12),OpenGL,Vulkan,Occlus SDK、およびOpenVRで構
築されたアプリケーションをサポートします。

4. NSight使用前に

5. 概要
いくつかNSightの基本的な準備と、事前説明を行います。

6. NSightのダウンロード
NSightのDeveloperToolのダウンロードページからダウンロードします。
NVIDIA NSight Graphics
を選択してダウンロードし
ます。
出来るだけ最新のツー
ル、最新のドライバで見る
ようにしましょう。

7. NSightをインストールしたら
もう少し準備があります。
NVIDIAコントロールパネルを開いて下の
画像のように設定して作業が楽です。

8. NSightを起動する

9. 普段づかいならNSightのプロジェクトを作成
Projectを作成しておくことで、次回同じ設定でキャプチャ作業をする時に楽です。
今回はとりあえず作成しておきましょう。

10. Projectの場所を設定
プロジェクト名と、プロジェクトを生成するLocationを設定します。
作業に使うプロジェクトファイルが出来上がるので次
回同じ設定で作業したい場合は同じプロジェクトファ
イルを開くようにしましょう。

11. 接続用のダイアログが起動します。

12. 接続設定部分
起動する実行ファイルの指定
実行ファイルに渡す引数
起動時に接続するか否か

13. Profile設定
主に使うのはFrame ProfilerとGPU Trace

14. Profile説明
FrameProfiler:
1フレームを詳しく見る。
1DrawCallの詳細やかかる時間、ポリゴン数、リソースの中身や、1DrawCallが使用す
るハードウェアユニット等、より詳細な部分を調べる事に使える。
計測時間は実機より重めに出る傾向があるので、詳細を調べたい場合に使用。
TraceCapture:
1～15フレームの区間指定で各描画パス毎にかかる時間、描画パス毎の使われてい
るユニットの割合、などFrameProfilerより大きい単位の計測を行う。
TraceCapture同士の比較なども出来、1フレームのより実機に近いGPU timeで大ま
かに見るのに有効。

15. 注意点
今回資料を作るにあたってRTX2080tiを使用していておりました。
資料作成後に気づいたのですがRTX以前のGPUでは今回の資料より情報が取れない
という事が分かりました。
分かりやすい部分でClipperの値が見れない、GPU Traceが使えない などです。
とれる情報に添付画像と差異があった場合はGraphicBoradをご確認ください。

16. エディタに繋いで見る

17. 概要
まずはUE4エディタで繋ぐ方法です。
エディタに関してはFrameProfilerのみ説明致します。
＊手元の環境ではエディタ上でTraceCaptureが上手く繋がりませんでした
繋がる事もあるのですが、なかなか不安定。(パッケージは安定するのですが)
人によっては上手く繋がるかも知れませんが、手順もあまり変わらないので、
TraceCaptureをエディタで繋がる事かどうかは試してみてください。
もしかしたら繋がる方もいるかも知れません。
2020/11/23に2020.6.0が更新され手元では安定して繋がるようになってました。

18. Launch準備
UE4Editorの実行ファイルを指定
Engineフォルダにあります。（各々の Projectルールの場所に合わせてパスを指定してください。）
タイトルのuprojectを指定

19. Launch
Launch Frame ProfileでFrameProfileのモードで起動します。

20. 接続中
途中こんな事聞かれ
ますがとりあえずNo
でいいです。
接続中なので待
ちます

21. 起動
左上にFrameProfilerが接続
されている時に出てくる情報
が表示されております。

22. キャプチャの前に
キャプチャする瞬間にWindowのフォーカスが外れて低速なモードになってしまうため、
Editor Prefarence の Use less CPU when in Backgroundをuncheckします。
これによりエディタからフォーカスが外れても低速にならなくなります。
（エディタを開いたまま他の作業をする方は注意）

23. コンソールコマンドを忘れずに
起動してから一回ToggleDrawEventsしておかないと
描画パスにラベルが振られなくて不便です。
キャプチャして「ラベルないな」
と思ったら呼び出し忘れか、
呼び出し過ぎです。
Toggleなため現在有効か
どうか分からなくて大変不便です
ご注意ください。。

24. CTRL+Z
CTRL+Zでキャプチャするためのアイコンが右端に出てきます。
ボタンを押すとキャプチャ開始です。
(もしくはNSight側のCapture for Live Analysis)
解像度が変わると負荷が変わってし
まうため、フルスクリーンにしてか
らキャプチャしましょう。

25. CTRL+Z 追記
ちょうど資料を書き終えた翌々日2020/11/23日にNSightが2020.6.0が更新されました
2020.6.0からはCTRL+Zを押した
後左上の表記が切り替わり、右側
にアイコンは出てきません。
CTRL+Zを押した後はSpaceキー
でキャプチャが出来ます。

26. キャプチャ中
情報を収集中、このようなダイアログが出たらとりあえずキャンセルしてください。
情報を収集している間 NSight側では
以下のダイアログが出ています。

27. キャプチャが出来ました。

28. 正しくイベントが見れている状態
Defaultではイベントの実行順に並んで
います。
計測結果の見方や運用の仕方は
別途後半のセクションで説明していき
ます。

29. エディタに戻る場合
FrameCaptureはアプリ側がNSightに実行をフックされている状態になっており操作で
きません。
Resumeを押すと、エディタの操作に戻れます。
＊本来戻れるはずなのですが・・・
こちらの環境ではResume出来ずに100%
クラッシュ・・・・。
(尚、パッケージではちゃんと戻れる・・・)
他の人の環境では上手くいくかも知れない
ので試してみてください・・・。

30. まとめ
まずはEditorに繋いでProfileするところまで行きました。
見方などに関しては後半のセクションにてまとめて説明をしていきます。

31. パッケージ実行側に繋いでみる

32. 概要
パッケージングしてから繋ぐ方法になります。
エンジンを改造してない事を前提にするので、ここではDevelopmentパッケージで行い
ます。
＊こちらではTraceProfileが確実に取れるのでそちらに関しても説明していきます。

33. アプリケーションを指定してFrameProfile
Packagingした実行ファイルを指定
後はLaunche Frame Profilerで起動
できます。

34. 起動した後はエディタと同じ手順
・CTRL+Zでアイコン表示
・キャプチャボタンを押す
（もしくはNSight側の
Capture for Live Analysis）
＊-dx12を付けた場合は
toggleDrawEventは無くて
も大丈夫です。

35. アプリケーションを指定してGPU Trace
・パッケージの実行ファイル指定
・-dx12を引数につける。
GPUTraceがdx12じゃないといけない
ため
・GPU Traceを選択
・FrameCountを指定
1～15フレームまでの範囲で
キャプチャ指定できる。

36. キャプチャの流れ
1.ToggleDrawEvents
2.NSight側のGenerate GPU Trace Captureを押す
Tarceの場合はファイルが書き出されて、
いつでもキャプチャ結果を確認できる。
ダイアログがこの状態になったら Openし
ます。

37. GPU Traceの結果 各パスの時間が出ている

38. GpuTraceの書き出し場所
作成したプロジェクト以下に書き出されます。

39. GPU Trace

40. GPU Trace
このセクションではGPUTraceに関して、アーティストさん向けに簡単に説明を書かせて
頂きました。

41. 各描画パス
前のセクションでも軽く触れた通り、各描画パスの時間が見れます。
ここでまずは大まかに重たそうなポイントを絞り込みます。
それぞれの描画パスが、タイトルのターゲットPerformanceのバジェットに沿っているか
確認、沿っていなければその描画パスを見てみます。

42. 描画パスをダブルクリック
とりあえず目立つLightCompositionTasks PreLightingを選択してみます。
ダブルクリックする事で、そのパスにクローズアップ

43. ユニットの使用率が出ている
今回AmbientOcclususionを行ってる
パス。
Summary、Metricsに各ユニットの
使用率が入っている。
これを見て判断するための説明は切り
がないので割愛します。

44. 再キャプチャ準備
今回AmbientOcclusionを選択しており、負荷の要因がメモリアクセスコストが高い事が
分かりやすいため設定を変更し、AmbientOcclusionLevelを1に設定することで、テクス
チャアクセスを減らして再キャプチャしてみます。
＊各ユニットの関係から判断するための、簡略化した説明が無理でした・・・。

45. 再キャプチャ
速くなった。(もちろん設定的にクオリティとトレードオフしているが)

46. 比較
後述しますが、TraceCaptureで比較をとる事ができます。
AmbientOcclusionの実行時間が
短くなるとともに各ユニットの
効率が上がっている事が確認でき
ます。

47. 比較機能
GPU TraceにはTrace Compareという機能があり、2つの計測ファイルの差分をとる事
ができます。

48. TraceCompare
上下に並べた状態で、2ファイルの差分を見比べる事ができます。

49. BasePassをダブルクリック
BasePassにクローズアップされ、BasePass同士を比較するように見れます。

50. 注意点 不安定な同期待ち
特にPC環境では複雑に大量のタスクが動いているため、
同期待ちが妙に長い区間が不意に発生したり、
結果が揺れたり という事が起きえます。
何度かキャプチャして、安定している部分で
比較しましょう。
右の画像は同じ条件化で2回計測したものですが、
結構揺れています。

51. GPU Trace まとめ
各ハードウェアユニットの情報とか出ているのですが、アーティストさんが見る場合はこ
の辺のユニットは深追いしない方がよいです。
処理の内容によって、元々の実装をある程度把握してる人間がみないと確度のある判
断が出来ないためです。
大まかにパッケージ上での負荷を見たい場合に使用するのが良いかと思います。
TestBuildでも見る方法に関してはこちらの情報からタイトルのプログラマーに依頼して、
エンジンをいじって頂ければと思います。

52. Frame Profilerのよく使う部分

53. 概要
FrameProfilerはDrawCallのリソース確認、DrawCallの各種情報（インスタンス数、
1Instanceのインデックス数、投入ポリゴン数、出力ポリゴン数、出力ピクセル数・・・・）等
が見る事ができます。
このセクションでもアーティストさん向けに簡単な部分での使い方を説明させて頂きま
す。

54. 調査に関して
重要になるのが各パスの時間そのものではなく、全体からみてどの程度時間がかかっ
ているのか、どういう描画のされ方をしているのか？、このパスでは何ポリゴン投入され
ていて、実際にレンダリングされているポリゴンがどの程度、出力されたピクセルはどの
ぐらいなのか？
等の情報になると思います。
注意点：
詳しい計測にはFrameProfilerが良いのですが、計測負荷が高くかかった時間は平均
的に重めに出てきてしまいます。

55. まずは起動

56. そしてキャプチャ
ToggleDrawEventsを呼んで、CTRL+Zをしてキャプチャボタン（もしくはCapture
Analysis）

57. キャプチャ後
各ラベル、もしくはDrawCallからProfiling出来ます。
まず試しに[Frame]ラベルを選択
右クリックでProfile “Frame
を行ってみます。
GPU ms がGPU負荷の部分。
ただし計測負荷が乗った状態。

58. FrameをProfile
RangeProfilerのウインドウが出てくる

59. RangeProfile-アーティストに使って欲しい項目
閉じた状態のRangeInfo ：計測パスの全体の情報が入ってる
DrawCallCount : 計測パスで発生したDrawCall
API Primitives (Total / Avg) = 処理したポリゴン数 合計/DrawCall辺りの平均
Shaded Pixels = 処理したピクセル数 合計/DrawCall辺りの平均

60. RangeProfile-アーティストに使って欲しい項目
開いた状態のRangeInfo : 詳細
DrawCall Count = 計測パスのDrawCall数
InputPrimitve = DrawCallにセットアップされたポリゴン数
ClipPrimitiveIn = カリング処理に投入されたポリゴン数
ClipPrimitiveOut=カリング処理の結果、画面に出力され
たポリゴン数。

61. Pipeline Overview-アーティストに使って欲しい項目
開いた状態の場合、大雑把なユニットの割合が見れる。
よくあるのがフォリッジ置きすぎて頂点過多になるケースで、その場合BasePass時の
VSのグラフが非常に大きい面積になる。（通常のフルスクリーンで見ている想定）
VS=VertexShader
HS=HullShader
DS=DomainShader
GS=GeometryShader
PS=PixelShdader

62. Pipeline Overview:補足
アーティストさんが見る前提なので、TOP SOL等を見る、他のmetrixを見る等はあまり
想定しておりません。
「VSの割合が大きい時に頂点ネックな事が分かるならPSの割合が大きかった
PixelShdaerの負荷高いんじゃないの？」と思われると思いますが、実際PixelShaderは
基本的に大きい割合で出てきます。
しかし単純にだから問題とは限らないため割愛しています。

63. 補足：通常はPSの割合が大きい
頂点より、画面ピクセルの方が圧倒的に多く、1ピクセル毎の処理の方が多くの計算を
行うために、通常はPSの方が大きいのが当たり前となっております。
そのため単純にグラフでみてBasePass時にVSが半分以上等の大きい場合は頂点過
多の可能性が高い。
PrepassやShadowではPixelShaderを起動しないDrawCallが数多く混ざるケースもあ
るため、そういうケースではPSがほとんど動いていないこともある。
＊上記の事からPipeline OverViewを見る場合はBasePass限定にしておいた方が良
いと思います。

64. 単体のDrawCallも見れる
デフォルトだとDrawCall以外のAPIも大量に並ぶため、ConfigからDrawCall以外を
Hideしておくと見やすいです。
各描画パスを開くと
DrawIndexed～が見えるので右ク
リックしてProfileEventできます。
もしくは一番右側のGpu msで極端
に時間がかかっている DrawCallで
ないかを確認。

65. 1DrawCall
IndexCountPerInstance = 1インスタンスに使うIndex数。
IndexCountPerInstance /3の値で使用ポリゴン数
InstanceCount = 1DrawCall内のインスタンス数
Foliage等ではインスタンシングされているため、
ここの値が大きくなる。

66. 掴んだDrawCallがプレビューされる
WireFrameも見れる。

67. 掴んだDrawCallのリソースも見れる
セットアップされているだけで必ず使われてるとは限らない事に注意。
APIInspectorをFrameDebuggerから有効にしていると見れます。

68. 指定描画時間がかかってるものだけ見たい
1.Configureを押す
2.出てきたダイアログにHideしたいGPU msの閾値を指定
3.Hideされなかったものがリストアップ

69. 例：BasePassの解析例
例えば：
ClipPrimitiveInが大量なのにClipPrimitiveOutが少ない場合
DrawCallにされているのに、画面に入ってないポリゴンが多い という解釈ができる。
例えば：DrawCallCountが多い場合
大量にDrawCallが走っていると解釈できる。(大量に走っている という事は無駄な
drawCallが多く紛れ込んでいる恐れも・・・)

70. 例：重いパスを見つける
さっきと同じような画面で
すが、問題のある描画パ
スが実はいます。

71. キャプチャ結果から
なんとTranslucencyが7ms

72. Translucencyを開くと
Δ2、Instance 2642のDrawCallが！？
実はWireFrameが酷い事に

73. Profile結果も
ポリゴンは高々5284ポリゴンしか処理していない・・・が。
Shaded Fragments [Thread]からPixelShaderの処理は約1億3千万Pixel
1080pのPixel数が約207万Pixel 。
画面書き換え62回分!?

74. OMからRenderTargetを確認
OMを選択するとRenderTargetのリスト
が表示される。
リストから選択すると ResourceViewの
中身が見れる。
ほとんど透明なせいで中身への書き込
みが見えない。
つまり無駄な描画な事が分かる。

75. NSightのメリット
簡単に使う範囲でのNSightのメリット:
・パッケージしたものを解析できる。
・比較的多くの情報が取得できる。
Scene全体、もしくは描画パス毎でのDrawCallやポリゴン数、ピクセルの出力数等が
知れる。GPU Traceに至ってはGPU Timeの確度も高い。
各DrawCallの詳細も見れる。
・Clipperが見れる。(カリング具合)
・GPU Traceの結果を残しておけば比較も容易
・シミュレートして、実機画面でワイヤーフレームが見れる。

76. NSightのデメリット
比較的面倒。
簡単に表示のデバッグや流れを追う等の時はRenderDocの方が良い。
深く追う際には非常に専門知識が求められる。

77. 調査する時の運用
ゲームシーンが構築された結果、全体の把握が出来ていない場合に特に便利。
大した見た目でもないのに超ハイポリのものがいる場合や、FoliageなどでDrawCall自
体は少ないが大量のインスタンスをInstancingで処理する事で処理負荷が大きい場合
等、そういう場合の負荷を検知しやすい。
全体の情報もProfileFrameから数値で見れる要素が多く、全体把握しやすい。
途中参加のプロジェクトで、シーン全体をざらっと見る際に重宝してます。

78. Editor + stat gpuはかなり値が怪しい
環境によって実際の値から大きくかけ離れていたり、一部処理を包括した結果が出てい
たりと値の信用度的に怪しい。
実際カウンタ自体が明らかに大きく食い違う値を出す事があった。
環境によっては正しそうな値を出している事もあり、なかなか信頼性に問題があるが、
NSightはstatほどの不安定差は自分が観測している範囲ではない。
そのため割と普段づかいしています。

79. 使い分け
DebugのRenderDoc
解析のNSight
のような感じで運用できると良いのではないでしょうか。

80. まとめ
解析の流れは実際にはパターンが大量にあります。
あえて簡単な部分に絞ってまずは触って頂こうと思い今回のような簡単な部分だけに集
中させました。
より深く知りたい方は参考文献のリンク先へ飛んで調べて見てください。
今回紹介した所から軽く触り始めて頂くと、NSightを触るのが面白くなってくると思いま
す。

81. より深く調べたい方へ
・ RenderHellBook
・ The-Preak-Performance-Analysis-Method-for-Optimizing-any-gpu-workload
・ what-is-limiting-your-rendering-performance
・ life-triangle-nvidias-logical-pipeline
・GPU-DRIVEN RENDERING
・Mask Material only in Early Z-passの効果と仕組み
・NSightCompute
・NSightrUserGuide