シェーダー

Unityのフレームデバッガーが機能していない場合のピクセルトラッピング



Pixel Trapping When Unitys Frame Debugger Is Not Working



バージョン5以降、Unityには新しいビジュアルフレームデバッグツールであるフレームデバッガが含まれています。このツールは、多くのグラフィックを解決するのに役立ちます 問題 、Zファイティング、GPUステータスが正常ではない、レンダリングキューエラー、混合操作エラー、過度の描画呼び出し、非効率など。ゲームビューの状態のリストよりも詳細な情報が提供され、GPUについて多くのことを学ぶことができます。レンダリングイベント/ステップと対話してチェックすることによるパイプライン。実際、すべての開発者はこのツールを理解する必要があります。

この記事では、Frame Debuggerの使用法について簡単に説明し、その欠点とそれを補うことができるその他のツールを指摘します。私はすべてをカバーするつもりはなく、コンテンツの一般的な概要だけをカバーします。



1.フレームデバッガーを使用する

[ウィンドウ]-> [フレームデバッガ]メニューを使用してメインウィンドウを開きます。同時に開くことをお勧めします フレームデバッガー と ゲームビュー （ゲームビュー）。これを行うには、ウィンドウレイアウトを調整する必要がある場合があります。グラフィック表示のデバッグに使用したインターフェイスは次のとおりです。





推奨されるレイアウト（[アセットストア]タブを除く）

推奨されるウィンドウレイアウト（[リソースストア]タブを除く）



頭痛や機嫌が悪くなるまで、ゲームをプレイします。フレームデバッガウィンドウで、[有効にする]をクリックして、最後にレンダリングされたフレームの詳細を取得します。

イベントと右側の詳細の2つの主要なセクションが含まれています。イベントは基本的にCPUからGPUに送信されるコマンドです。とても簡単です。結局のところ、実際に呼び出されるAPI関数はここには表示されませんが、プロセス全体がパッケージ化され、時系列で表示されます。それらのほとんどは、（不透明/透明な）ジオメトリをクリアして描画するコマンドですが、GUIレンダリング、シャドウ処理、グラフィック効果、コールバックの数などの詳細情報にも気付くことができます。

イベントを選択すると、詳細パネルでイベントに関する詳細情報を取得できます。含まれるもの：シェーダースコープとそのフラグ、レンダリング出力イベント、およびシェーダープロパティ情報。同時に、ゲームビューには、イベントの前にレンダリングされたオブジェクト（現在のイベントを含む）が表示されます。以下は例です



イベント例

2.フレームデバッガーが使用されるのはなぜですか？

フレームデバッガーは、いくつかの貴重な情報を提供してくれます。イベントが描画される順序（つまり、レンダリングキュー）は、レンダリングの正確さにとって重要です。ゲーム内の要素がラフを表示できない場合は、レンダリングキューに正しく配置されていないことがあります。 、特にカスタムシェーダー開発またはZ書き込み（深度バッファー書き込み）パラメーターの調整とテストを行う場合、レンダリングが時期尚早または遅延します。このツールは私にとって多くの問題を解決しました。フラグとレンダリング順序を設定するのを忘れたため、スカイボックスがシェーダー出力をカバーしていることがわかりました。

次に、相対的なものとして、ここで描画呼び出しへの呼び出しの数を表示し、頂点/インデックスの数によってシーンのレンダリングコストを間接的に測定することもできます。もちろん、シェーダーパスの数も役立ちますが、その複雑さはここには示されていません。そのため、基本的な常識が必要です。これらはすべて、シーンのパフォーマンスを向上させるのに役立ちます。その原因一部のグリッド描画が静的/動的バッチ処理の実行に失敗しました。私の場合、マテリアルアトラスを使用して、2つのイメージスプライトの2つの描画呼び出しが1つに結合されていることがわかります。

第三に、フレームデバッガーと対話することで、GPUのアーキテクチャに関する知識をすばやく学び、Unityレンダリング処理のフローを理解できます。キーボードを使用してさまざまな手順をジャンプし、シーンのレンダリングプロセスを表示できます。前の例では、シーンレンダリングは、3つのキャッシュ（色、z、ステンシル）のクリーンアップで始まり、不透明なジオメトリ（前から後ろ）、スカイボックス、透明なジオメトリ（後ろから）が続くことがわかります。前面に）。レンダリング。

最後に、シェーダープロパティにアクセスして、マテリアルとシェーダーに関する詳細情報、およびオブジェクトで使用されるデータ（マテリアルなど）への参照を取得できます。ほとんどの人はUnityを使ったことがありません 高度なビュー インスペクターで右上の段落アイコンをクリックして[デバッグ]を選択すると、これらにアクセスできます。

シェーダーのプロパティ

シェーダーのプロパティ


2.警告

クライアントで働いている間、フレームデバッガーの単純なインターフェイスによって引き起こされる問題にも遭遇しました。私はここにいます Unite2016ヨーロッパ 私はUnityの開発のいくつかについて話しました、そして彼らはそれについて知っていました、しかし彼らは彼らが将来それを拡張したいかどうかを言いませんでした。私の経験から、主な問題は次のとおりです。


  • イベント後のAPI呼び出しの基礎となる情報を取得できません。この場合、Unityはイベントをブラックボックスとして扱うため、特定の条件下で問題を改善することは困難です。
  • 各イベントでのGPUパイプラインの全体的な状態は利用できず、ジオメトリとマテリアルに関する情報のみが利用可能であり、頂点/ジオメトリ/フラグメントシェーダーやラスタライザーなどのさまざまな段階のデータが欠落しています。
  • シェーダーを実際にデバッグできません。出力色を変更してコードを視覚的にデバッグするか（印刷よりも罪を犯します）、GLSL-Debuggeクラスなどの外部ソフトウェアに依存します。
  • 結果のピクセルと、それらのピクセルを書き出す対応するイベントとの関連付けを確立することは困難です。どのイベントがピクセルに間違った情報を書き込んでいるかを確認するには、段階的に行う必要があります。多数のドローコール呼び出しがある場合、このプロセスは非常に時間がかかる可能性があります。
  • 各描画呼び出しの効率を測定する正確なインジケーターが不足しており、頂点/インデックスの数はレンダリング効率を特徴付ける最良の手段ではありません。より多くの頂点がより多くの帯域幅を必要としますが、ジオメトリまたはコストのかかる状態遷移パフォーマンスで複雑な頂点シェーダーを実行すると、パフォーマンスが低下する可能性があります。

それでも引き続き視聴する場合は、上記の問題の解決策を探している可能性があります。他の補完的なツールを使用するのはどうですか？

4. RenderDoc

いくつかのソフトウェアをテストした後、私は間違いなくすべての人にいくつかのモデルをお勧めできます。ツールボックスでの推奨される選択は、 RenderDoc ネットワーク攻撃者の古典的なアプローチを使用する、根本的な通話情報の問題を解決するためにCrytekによって開発された無料のツール：DX / GL / Vulkan通話で中間者（MITM）キャプチャアプリケーションとして仮想グラフィックスドライバーを作成し、詳細なデバッグ情報を提供します。良いニュースは、ツールがすでにUnityでのネイティブ統合をサポートしていることです。WindowsマシンにRenderDocをインストールし、Unityエディターを再起動するだけです。

このセクションの目的は、ツールの使用法の概要を説明し、興味を持ち始め、よりスムーズに使用し、電気への支出を減らすことです。

始めましょう。インストールがうまくいけば、右クリックしてメニューの[RenderDocの読み込み]を選択できるはずです。

数秒後、再生モードに入ります。レンダリングしたばかりのフレームに興味がある場合は、最大化再生ボタンの左側にある同じ頭の新しいアイコンをクリックします。

次に、新しく開いたRenderDocウィンドウに切り替え、自動的にキャプチャされたログをダブルクリックして分析を開始します。

RenderDocでキャプチャされたログ

レンドック ログをキャプチャする

うわー、これは情報の海です、私は溺れます。落ち着いて、すべてがうまくいくでしょう。今、あなたは何千ものウィンドウですべてのフレームデータを取得するでしょう、テーブルは心配しています、私は以下の本当に興味深い内容を説明し続けます。


4.1。イベントブラウザ+ API呼び出し。

4.1イベントブラウザ+ API呼び出し

このツールの利点は、各イベントの基礎となる情報を取得できることです。イベントブラウザは、UnityのFrameDebuggerの拡張機能のようなものです。また、時間のかかる（ミリ秒単位）およびその他のプロンプト情報も含まれているため、効率が大幅に向上します。 RenderDocには状況依存機能があります。つまり、イベントを選択すると、他のほとんどのウィンドウとリージョンにイベントにのみ関連する情報が表示され、その下のAPI呼び出しウィンドウにイベントを処理するためのイベントが一覧表示されます。呼び出された関数。

RenderDoc：イベントブラウザ+ APIcalls

これらの時間のかかるデータを取得するのは素晴らしいことです！それらは完全に正確ではないかもしれませんが、比較的正確です。つまり、時間のかかる作業によって、どの操作の描画呼び出しを最適化する必要があるかを推測できます。

4.2。パイプラインの状態。

パイプラインステータス

レンダリングパイプラインの動作モードについてよく疑問に思います。独創的な幾何学はどのようにしてその内部に入り、50インチの画面でピクセルに変換されますか？残念ながら、このツールでユーザーフレンドリーなアニメーションを取得して、その動作を示すことはできません。

しかし、それはいくつかあります 非常に良い無料ツール できる。ただし、いずれの場合でも、RenderDocを使用すると、入力アセンブラー、頂点/ボディ/ドメイン/ジオメトリ/フラグメント/計算シェーダー、ラスタライザー、出力コンバイナーなどのイベントで大量のパイプライン状態情報にアクセスできます。ゴキブリの判断を信じて、RenderDocはその名前に値します。

RenderDoc：ピクセルシェーダーのPipelinestate

RenderDoc：出力マージの例


RenderDoc：ラスタライザの状態


4.3。メッシュ出力

グリッド出力

RenderDocのもう1つの機能は、頂点シェーダーを介してイベントでレンダリングされたグリッドデータ（入力および出力位置、法線、テクスチャ座標、その他の情報）を取得できることです。実際、これを使用して、ゲームでレンダリングされている3Dプログラムまたはグリッドを取得して保存できますが、この記事ではそのケースについては説明しません。

4.4。テクスチャビューア

テクスチャビューア

これは私の料理で、イベントの入力テクスチャと出力テクスチャを視覚化します。画像処理に中間バッファリングを使用する場合、テクスチャまたは他の中間バッファリングデータへのレンダリングを含めることは非常に興味深い場合があり、テクスチャスペースも節約します。


RenderDoc：テクスチャビューア

4.5。ピクセルのデバッグ

ピクセルレベルのデバッグ

フレームバッファでは、正しくレンダリングされていない不良ピクセルが正しいピクセルをカバーすることは珍しくありません。ほとんどの開発者は、この種の悪夢に遭遇しました。シーンにドット抜けが残っているという不思議な感覚で、何かが起こったことに気づきます。理由はわかりませんが、急いでいません！私たちの推測を確認し、問題がどこにあるかを見つける方法...

はい、この問題を解決する方法は次のとおりです。ピクセルを選択するか、ヒットロイをクリックする（一連のイベントを取得してフレームバッファー内のそのピクセルに情報を書き込む）か、デバッグする（ピクセルシェーダーをデバッグする）。これらの問題をデバッグするには、実際の技術的な知識が必要です。知識をコンパイルし、分解されたバージョンのピクセルシェーダーについてある程度理解している必要があります。

RenderDoc：ピクセルの選択

RenderDoc ：ピクセル選択

RenderDoc：Pixelの歴史

RenderDoc： ピクセル履歴

RenderDoc：シェーダーデバッガー



5.例

例

一部の学生は、実際の作業におけるパフォーマンスアナライザの重要性を疑うでしょう。私はあなたにこれを言います：非常に必要です。機能のパフォーマンスへの影響が不明な場合は、パフォーマンスアナライザーを使用して、フレームデバッガーであるかどうかに関係なく、次のテストを実行します。必要に応じて、RenderDocやその他の同様のツールを使用すると作業に大きなメリットがあります。

例を見てみましょう。スクリプト内のマテリアルへのアクセスとレンダラーのshaderMaterialへのアクセスに違いがあることを誰もが知っているわけではありませんが、ほとんどの場合同じですが、これがパフォーマンスに影響を与えることを知っている人はごくわずかです。しかし、手元にツールがあるので、調べてみませんか？

テストシナリオには、スプライトが1つだけあります。同じ変換を繰り返し使用して10,000回インスタンス化すると、ほぼすべての視野を占めるため、描画する必要のない部分が多いことが想像できます。コードは次のとおりです。

void Start（）{

for（int i = 0 i

{{

varsprite = Instantiate（スプライト）

sprite.transform.parent =変換

varsharedMaterial = sprite.sharedMaterial

//スプライトごとにマテリアルコピーを作成するためのコメントを解除します。

// varmat = sprite.material

}

}

sharedMaterialへのアクセスはスムーズで、マテリアルは1つだけであり、マテリアルにアクセスするときにすべてのスプライトインスタンス間で共有されます。スプライトごとに個別のマテリアルを作成する必要があるため、Draw呼び出しをバッチ処理できず、renderDocを使用して分析を表示できます。 Render.TransparentGeometry関数の結果は次のとおりです。

RenerDocによって与えられた時間のオーバーヘッドはあまり信頼できないと思います。資料の読み方はまったく不正確なようです。この例のハードウェアループ呼び出しの実際の数はわかりません。 Unityのパフォーマンステスターも調べました。いずれの場合も、共有マテリアルは新しいマテリアルのインスタンス化と比較され、2番目の実装では、描画呼び出しをマージできないため、ドライブのオーバーヘッドと帯域幅のオーバーヘッドが高くなります。

実際のコストは、ドローコール自体の数ではなく、ドローコールの状態遷移です。 Material.SetColorを使用してスプライトごとに異なるランダムな色を設定した後、2つのFPSがドロップされていることに気付きました。この問題は最近リリースされたものを通過することができます 解決するVulkanAPI 。

6.結論

結論として

RenderDocは、Unityのフレームデバッガーの完璧なツールでも代替品でもありません。これは完全なツールです。これを簡単に使用して、必要な基礎となる情報を取得できます。使うのも楽しいですが、遠くに行くと。問題が複雑になるほど、GPUのハードウェアアーキテクチャを十分に理解する必要があります。

renderDocの使用は時間のかかる作業であることを認めなければならないので、覚えておいてください。ターゲットを絞った最適化を行う前に、パフォーマンステストを行ってください。 95％の場合、Unity独自のframedebuggerを使用してデバッグを完了することができますが、人生の5％をすぐに不幸にするためには、準備が必要です。

これらのツールをパフォーマンステスターと組み合わせます。現実の世界には常に些細な状況がいくつかあります。特にデバッグが不足しているプラ​​ットフォームで開発する場合、ボトルネックの原因がわかりません。

いつものように、フィードバックと質問をありがとう！


元のリンク：
http://www.gamasutra.com/blogs/R ... nough_RenderDoc.php