[注 transl .:オリジナルの記事はゲームアーティスト向けのGPUパフォーマンスと呼ばれていますが、私には思えるように、ビデオプロセッサの一般的なアイデアを持ちたいすべての人に役立ちます。

チームのすべてのメンバーは、位置に関係なく、ゲームの速度に責任を負います。 3Dプログラマーには、ビデオプロセッサのパフォーマンスを制御する十分な機会があります。シェーダーを最適化し、速度のために画質を犠牲にし、より洗練されたレンダリングテクニックを使用できます。しかし、完全に制御できない側面があり、これらはゲームのグラフィックリソースです。

アーティストが、見栄えが良いだけでなく、レンダリングに効果的なリソースを作成することを願っています。 アーティストがビデオプロセッサの内部で何が起こっているかについてもう少し詳しく知ると、ゲームのフレームレートに大きな影響を与える可能性があります。 あなたがアーティストであり、描画呼び出し、詳細レベル（LOD）、MIPテクスチャなどの側面がパフォーマンスにとって重要である理由を理解したい場合は、この記事をお読みください。 グラフィックリソースがゲームのパフォーマンスに与える影響を考慮するには、ポリゴンメッシュが3Dエディターからゲーム画面に到達する方法を知る必要があります。 これは、ビデオプロセッサ、グラフィックカードを制御し、リアルタイム3Dレンダリングを担当するマイクロ回路の動作を理解する必要があることを意味します。 この知識を活用して、最も一般的なパフォーマンスの問題を調べ、それらが問題である理由を確認し、それらの対処方法を説明します。

始める前に、簡潔さと明快さのために、意図的に多くを単純化することを強調したいと思います。 多くの場合、私は一般化し、最も典型的なケースのみを説明するか、単にいくつかの概念を破棄します。 特に、簡単にするために、この記事で説明されているビデオプロセッサの理想的なバージョンは、前世代（DX9時代）と最もよく似ています。 ただし、パフォーマンスに関しては、以下のすべての理由は最新のPCハードウェアとコンソールに適用されます（ただし、すべてのモバイルビデオプロセッサに適用されるわけではありません）。 記事に書かれているすべてを理解すれば、より深く理解したい場合に、将来遭遇する変化や困難に対処するのがはるかに容易になります。

パート1：概観レンダリングパイプライン

画面にポリゴンメッシュを表示するには、処理とレンダリングのためにビデオプロセッサを通過する必要があります。 概念的には、このパスは非常に単純です。グリッドがロードされ、頂点が三角形にグループ化され、三角形がピクセルに変換され、各ピクセルに色が割り当てられ、最終的な画像の準備が整います。 各段階で何が起こるかを詳しく見てみましょう。

3Dエディター（Maya、Maxなど）からグリッドをエクスポートした後、ジオメトリは通常2つの部分でゲームエンジンにロードされます：頂点バッファー（頂点バッファー、VB）。それに関連付けられたプロパティ（位置、UV座標）を持つグリッド頂点のリストが含まれます、法線、色など）、およびインデックスバッファ（インデックスバッファ、IB）。これは、三角形で接続されたVBの頂点をリストします。

これらのジオメトリバッファとともに、グリッドには、さまざまな照明条件での外観と動作を決定するマテリアルも割り当てられます。 ビデオプロセッサの場合、このマテリアルは特別に記述されたシェーダーの形式を取ります -頂点の処理方法と最終ピクセルの色を決定するプログラム。 グリッドのマテリアルを選択するとき、さまざまなマテリアルパラメータを構成する必要があります（たとえば、ベースカラーの値、または異なるマップのテクスチャの選択：アルベド、ラフネス、法線マップなど）。 それらはすべて、入力としてシェーダープログラムに渡されます。

グリッドおよびマテリアルデータは、ビデオプロセッサパイプラインのさまざまな段階で処理され、最終ターゲットレンダー （ビデオプロセッサが記録する画像）のピクセルを作成します。 このターゲットレンダーは、後で後続のシェーダーのテクスチャとして使用したり、フレームの最終画像として画面に表示したりできます。

この記事の目的上、ビデオプロセッサパイプラインの重要な部分は、上から下の順になります。

• 入力アセンブリ ビデオプロセッサは、メモリから頂点バッファとインデックスバッファを読み取り、三角形を形成する頂点の接続方法を決定し、残りをパイプラインに渡します。
• 頂点シェーディング。 グリッドの各頂点に対して頂点シェーダーが実行され、一度に個別の頂点が処理されます。 その主なタスクは、頂点を変換し、その位置を取得し、カメラと表示領域の現在の設定を使用して画面上の位置を計算することです。
• ラスタライズ 頂点シェーダーが三角形の各頂点に対して実行され、ビデオプロセッサが画面上のどこに表示されるかを認識した後、三角形がラスタライズされ、個々のピクセルのセットに変換されます。 各頂点の値は、UV座標、頂点の色、法線などです。 -三角形のピクセルによって補間されます。 したがって、三角形の1つの頂点が黒で、他の頂点が白の場合、それらの中間でラスタライズされたピクセルは、頂点の補間された灰色を受け取ります。
• ピクセルシェーディング 次に、ラスタライズされたピクセルごとに、ピクセルシェーダーが実行されます（技術的にはこの段階ではピクセルではなく、「フラグメント」なので、ピクセルシェーダーはフラグメントシェーダーと呼ばれることもあります）。 このシェーダーは、マテリアルプロパティ、テクスチャ、光源、およびその他のパラメーターを組み合わせて特定の外観を得るために、プログラムされた方法でピクセルに色を与えます。 多くのピクセルがあり（1080pの解像度のターゲットレンダーには200万を超える）、各ピクセルは少なくとも1回シェーディングする必要があるため、通常、ビデオプロセッサーはピクセルシェーダーに多くの時間を費やします。
• 出力ターゲットレンダリング（ターゲット出力のレンダリング）。 最後に、ピクセルはターゲットレンダーに書き込まれますが、その前にピクセルが正しいことを確認するためにいくつかのチェックを通過します。 詳細テストでは、ターゲットレンダーに既に存在するピクセルよりも深いピクセルを破棄します。 ただし、ピクセルがすべてのチェック（深さ、アルファチャネル、ステンシルなど）に合格すると、メモリに保存されているターゲットレンダーに書き込まれます。

さらに多くのアクションがありますが、これが主なプロセスです：グリッド内の各頂点に対して、頂点シェーダーが実行され、各3頂点三角形がピクセルにラスタライズされ、ピクセルシェーダーがラスタライズされた各ピクセルに対して実行され、結果の色がターゲットレンダーに書き込まれます。

マテリアルのタイプを指定するシェーダープログラムは、 HLSLなどのシェーダープログラミング言語で記述されます。 これらのシェーダーは、通常のプログラムが中央プロセッサで実行されるのとほぼ同じ方法でビデオプロセッサで実行されます。データを受信し、データを変更するための一連の簡単な命令を実行し、結果を表示します。 ただし、CPUプログラムが任意のタイプのデータを処理できる場合、シェーダープログラムは頂点とピクセルを処理するように特別に設計されています。 これらのプログラムは、レンダリングされたオブジェクトに、プラスチック、金属、ベルベット、革などの目的の素材の外観を与えるために作成されています。

具体的な例を挙げましょう：マテリアルの色とテクスチャのLambertライティング計算（つまり、反射のない単純な散乱のみ）を実行する単純なピクセルシェーダーです。 これは最も単純なシェーダーの1つですが、理解する必要はありません。シェーダーの一般的な外観を確認してください。

float3 MaterialColor; Texture2D MaterialTexture; SamplerState TexSampler; float3 LightDirection; float3 LightColor; float4 MyPixelShader( float2 vUV : TEXCOORD0, float3 vNorm : NORMAL0 ) : SV_Target { float3 vertexNormal = normalize(vNorm); float3 lighting = LightColor * dot( vertexNormal, LightDirection ); float3 material = MaterialColor * MaterialTexture.Sample( TexSampler, vUV ).rgb; float3 color = material * lighting; float alpha = 1; return float4(color, alpha); } 

基本的な照明を計算するシンプルなピクセルシェーダー。 MaterialTextureやLightColorなどの入力データは中央処理装置によって転送され、vUVとvNormはラスタライズ中に三角形に沿って補間される頂点プロパティです。

生成されたシェーダー命令は次のとおりです。

 dp3 r0.x, v1.xyzx, v1.xyzx rsq r0.x, r0.x mul r0.xyz, r0.xxxx, v1.xyzx dp3 r0.x, r0.xyzx, cb0[1].xyzx mul r0.xyz, r0.xxxx, cb0[2].xyzx sample_indexable(texture2d)(float,float,float,float) r1.xyz, v0.xyxx, t0.xyzw, s0 mul r1.xyz, r1.xyzx, cb0[0].xyzx mul o0.xyz, r0.xyzx, r1.xyzx mov o0.w, l(1.000000) ret 

シェーダーコンパイラは、上記のプログラムを受け取り、ビデオプロセッサで実行されるそのような命令を生成します。 プログラムが長ければ長いほど、命令が多くなります。つまり、ビデオプロセッサの処理量が増えます。

渡すことに注意してください-シェーダーステップがどれだけ分離されているかを見ることができます-各シェーダーは個別の頂点またはピクセルで動作し、周囲の頂点/ピクセルについて何も知る必要はありません。 これは、ビデオプロセッサが膨大な量の独立した頂点とピクセルを並行して処理できるため、意図的に行われます。これが、ビデオプロセッサが中央プロセッサよりもはるかに高速にグラフィックスを処理する理由の1つです。

すぐにコンベアに戻って作業の速度が低下する理由を確認しますが、最初に一歩戻り、グリッドと素材がビデオプロセッサにどのように進入するかを確認する必要があります。 ここでは、最初のパフォーマンスの障壁であるドローコールも満たします。

CPUおよび描画呼び出し

ビデオプロセッサは単独では動作しません。コンピュータのメインプロセッサで実行されるゲームコードに依存します。CPUは、何をどのようにレンダリングするかを指示します。 中央処理装置とビデオ処理装置は、（通常）独立して並行して動作する別個のマイクロ回路です。 必要なフレームレート（通常は1秒あたり30フレーム）を取得するには、CPUとビデオプロセッサの両方が、妥当な時間内に1フレームを作成するすべての作業を行う必要があります（30fpsでは、フレームあたり33ミリ秒です）。



これを実現するために、フレームはパイプラインに配置されることがよくあります：CPUは作業のためにフレーム全体を取得し（AI、物理学、ユーザー入力、アニメーションなどを処理します）、フレームエンドでビデオプロセッサに命令を送信して、作業を開始できるようにします次のフレーム。 これにより、各プロセッサにジョブを実行するために完全な33ミリ秒が与えられますが、その代償として、フレーム長の遅延 （遅延）が追加されます。 これは非常に時間に敏感なゲーム、たとえば一人称シューティングゲームでは問題になる可能性があります-たとえば、Call of Dutyシリーズは60fpsの周波数で動作し、プレーヤーの入力とレンダリングの間の遅延を減らしますが、通常、プレーヤーは余分なフレームに気付きません。

33 msごとに、最終ターゲットレンダーがコピーされ、 VSyncの画面に表示されます。これは、表示する新しいフレームを検索する間隔です。 しかし、ビデオプロセッサがフレームを33ミリ秒以上レンダリングする必要がある場合、この機会のウィンドウをスキップし、モニターは表示する新しいフレームを取得しません。 これにより、画面のちらつきや一時停止が発生し、フレームレートが低下するため、回避する必要があります。 CPUの時間がかかりすぎる場合も同じ結果が得られます。これは、ビデオプロセッサが適切な時間内に作業を完了するのに十分な速さでコマンドを受信しないため、スキップの効果につながります。 つまり、安定したフレームレートは、中央プロセッサとビデオプロセッサの両方のプロセッサの良好なパフォーマンスに依存します。


ここでは、CPUによるレンダリングコマンドの作成に2番目のフレームに時間がかかりすぎたため、ビデオプロセッサは後でレンダリングを開始し、VSyncをスキップします。

グリッドを表示するために、CPUはdrawコールを作成します 。これは、ビデオプロセッサに何をどのように描画するかを指示するコマンドの単純なシーケンスです。 描画呼び出しをビデオプロセッサパイプラインに渡すプロセスでは、描画呼び出しで指定されたさまざまな構成可能な設定（主にマテリアルとグリッドパラメーターで定義）を使用して、グリッドのレンダリング方法を決定します。 ビデオプロセッサの状態（GPU状態）と呼ばれるこれらの設定は、レンダリングのすべての側面に影響を与え、オブジェクトをレンダリングするためにビデオプロセッサが知る必要があるすべてのもので構成されます。 私たちにとって最も重要なことは、ビデオプロセッサに現在の頂点/インデックスバッファー、現在の頂点/ピクセルシェーダープログラム、およびすべてのシェーダー入力（たとえば、上記のシェーダーコード例のMaterialTextureまたはLightColor ）が含まれていることです。

つまり、ビデオプロセッサの状態要素を変更するには（たとえば、テクスチャの交換やシェーダーの切り替えなど）、新しい描画呼び出しを作成する必要があります。 これらの描画呼び出しはビデオプロセッサにとって高価なので、これは重要です。 ビデオプロセッサの状態に必要な変更を設定し、描画呼び出しを作成するには時間がかかります。 ゲームエンジンが各描画呼び出しで実行する必要がある作業に加えて、追加のエラーチェックと中間結果の保存には依然としてコストがかかります。 グラフィックスドライバーによって追加されました。 これは中間コード層です。 ビデオプロセッサの製造元（NVIDIA、AMDなど）によって作成され、描画呼び出しを低レベルのハードウェア命令に変換します。 描画呼び出しが多すぎると、CPUに大きな負荷がかかり、深刻なパフォーマンスの問題が発生します。

この負荷のため、通常、フレームごとの描画呼び出しの許容数に上限を設定する必要があります。 ゲームプレイのテスト中にこの制限を超えた場合、オブジェクトの数を減らしたり、レンダリングの深さを減らしたりするための手順を実行する必要があります。 コンソール用のゲームでは、ドローコールの数は通常2000〜3000の間隔に制限されています（たとえば、Far Cry Primalの場合、フレームごとに2500を超えないようにしました）。 これは多数のように見えますが、特別なレンダリングテクニックも含まれています。たとえば、 カスケードシャドウは、フレーム内の描画呼び出しの数を簡単に2倍にすることができます。

前述のように、ビデオプロセッサの状態は、新しい描画呼び出しを作成することによってのみ変更できます。 これは、3Dエディターで単一のグリッドを作成したが、グリッドの半分では1つのテクスチャがアルベドマップに使用され、他の半分では他のテクスチャが使用される場合でも、グリッドは2つの個別の描画呼び出しとしてレンダリングされることを意味します。 グリッドが複数のマテリアルで構成されている場合も同様です。異なるシェーダーを使用する、つまり、複数の描画呼び出しを作成する必要があります。

実際には、状態変更の非常に頻繁なソース、つまり追加の描画呼び出しは、テクスチャマップの切り替えです。 通常、グリッド全体に同じマテリアルが使用されるため（したがって、同じシェーダー）、グリッドの異なる部分には異なるアルベド/法線/粗さマップのセットがあります。 数百または数千のオブジェクトがあるシーンでは、CPU時間のかなりの部分が各オブジェクトの複数の描画呼び出しの使用に費やされ、これはゲームのフレームレートに大きく影響します。

これを回避するために、次の解決策が適用されることがよくあります。グリッドで使用されるすべてのテクスチャマップが、しばしばアトラスと呼ばれる1つの大きなテクスチャに結合されます。 次に、グリッドのUV座標を調整して、アトラスの目的の部分を探すようにします。一方、グリッド全体（または複数のグリッド）を1回の描画呼び出しでレンダリングできます。 アトラスを作成する場合、低MIPレベルでは隣接するテクスチャがオーバーラップしないように注意する必要がありますが、これらの問題は速度を確保するこのアプローチの利点ほど深刻ではありません。


Unreal EngineのInfiltratorデモのテクスチャアトラス

多くのエンジンは、バッチ処理またはクラスタリングとも呼ばれるインスタンス化をサポートしています。 これは、1回の描画呼び出しを使用して、シェーダーと状態の点でほぼ同じで、違いが制限されている（通常はワールド内での位置と回転）複数のオブジェクトをレンダリングする機能です。 通常、エンジンは、クローニングを使用して複数の同一オブジェクトをレンダリングできる場合を理解するため、可能な場合は、別々のレンダリング呼び出しでレンダリングする必要がある複数の異なるオブジェクトではなく、シーン内で1つのオブジェクトを常に複数回使用するようにしてください。

描画呼び出しの回数を減らすもう1つの一般的な手法は、同じマテリアルを持つ複数の異なるオブジェクトを1つのグリッドに手動でマージすることです。 効果的かもしれませんが、過剰なプーリングは避ける必要があります。これは、ビデオプロセッサの作業量を増やすことでパフォーマンスを低下させる可能性があります。 描画呼び出しを作成する前でも、エンジンの可視性システムは、オブジェクトが画面上にあるかどうかを判断できます。 そうでない場合は、この初期段階で単純にスキップし、呼び出しとビデオプロセッサ時間の描画に費やすことなく、はるかに低コストです（この手法は可視性カリングとも呼ばれます）。 このメソッドは、通常、カメラの視点からオブジェクトを囲むボリュームの可視性をチェックし、他のオブジェクトによって可視性フィールドで完全にブロック（ オクルード ）されるかどうかをチェックすることで実装されます。

ただし、複数のグリッドが1つのオブジェクトに結合されると、個々の境界ボリュームは1つの大きなボリュームに結合されます。これは、各グリッドを収容するのに十分な大きさです。 これにより、可視性システムがボリュームの一部を見る可能性が高まります。つまり、グリッドのセット全体が表示されます。 これは、描画呼び出しが作成されることを意味します。したがって、画面上に少数の頂点しか表示されていない場合でも、オブジェクトの各頂点に対して頂点シェーダーを実行する必要があります。 これは、ほとんどの頂点が何らかの方法で最終画像に影響を与えないため、ビデオプロセッサの時間のほとんどを無駄にする可能性があります。これらの理由から、メッシュは、互いに近い小さなオブジェクトのグループに最も効果的です。とにかく1つの画面に表示されます。


RenderDocで作成されたXCOM 2からのショット。 ワイヤフレームビュー（下）では、灰色はビデオプロセッサに送信され、ゲームカメラの範囲外にあるすべての余分なジオメトリを示しています。

良い例として、ここ数年で私のお気に入りのゲームの1つであるXCOM 2のフレームを取り上げます。 エンジンによってビデオプロセッサに表示されるシーン全体がワイヤフレームで表示され、中央の黒い領域がゲームカメラから見えるジオメトリです。 すべての周囲のジオメトリ（グレー）は非表示であり、頂点シェーダーの実行後に切断されます。つまり、ビデオプロセッサの時間を浪費します。 特に、赤で強調表示されているジオメトリを見てください。 これらは、ほんの数回の描画呼び出しで接続およびレンダリングされたブッシュのグリッドです。 可視性システムは、少なくとも一部の茂みが画面上に表示されていると判断したため、すべての茂みがレンダリングされ、それらの頂点シェーダーが実行されます。その後、カットできる茂みが認識されます（ほとんどの茂みが判明します）。

正しく理解してください。XCOM2でそれを責めているわけではありません。この記事の執筆中によく遊んだだけです。 すべてのゲームにはこの問題があり、より正確な可視性チェックのためにビデオプロセッサが費やす時間、不可視のジオメトリをカットするコスト、および描画呼び出しのコストのバランスが常に取れていません。

ただし、呼び出しのレンダリングのコストになると、すべてが変わります。 上記のように、これらのコストの重要な理由は、変換およびエラーチェック中にドライバーによって作成される追加の負荷です。 これは非常に長い間問題でしたが、最新のグラフィックスAPI（たとえば、Direct3D 12やVulkan）では、不要な作業を避けるために構造が変更されました。 これにより、ゲームのレンダリングエンジンが複雑になりますが、レンダリングコールが安価になり、以前よりも多くのオブジェクトをレンダリングできるようになります。 一部のエンジン（最も有名なのはAssassin's Creedエンジンの最新バージョン）はまったく異なる方向に進み、最新のビデオプロセッサの機能を使用してレンダリングを制御し、レンダリングコールを効果的に取り除きます。

多数の描画呼び出しは、主にCPUパフォーマンスを低下させます。 また、グラフィックスパフォーマンスに関連するほとんどすべての問題は、ビデオプロセッサに関連しています。 ここで、「ボトルネック」が何であるか、それらがどこで発生し、どのように対処するかを調べます。

パート2：ビデオプロセッサの通常の「ボトルネック」

最適化の最初のステップは、既存の「ボトルネック」を探すことです。これにより、その効果を減らすか、完全に取り除くことができます。 「ボトルネック」とは、すべての作業を遅くするコンベヤーの部分を指します。 コストのかかる描画呼び出しが多すぎる上記の例では、ボトルネックはCPUでした。 ビデオプロセッサの動作を加速する最適化を実行しても、CPUの動作が遅すぎ、必要な時間内にフレームを作成する時間がないため、これはフレームレートに影響しません。


4つの描画呼び出しがパイプラインを通過し、それぞれが多数の三角形を含むグリッド全体をレンダリングします。 作業の一部が終了するとすぐに次のステージに転送できるため（たとえば、3つの頂点が頂点シェーダーによって処理された後、三角形をラスタライズのために転送できるため）、ステージは重ね合わせられます。

組立ラインは、ビデオプロセッサパイプラインの類推として使用できます。 各ステージがデータで終了するとすぐに、結果が次のステージに転送され、作業の次の部分の実行が開始されます。 理想的には、上の図に示すように、各ステージは常に仕事で忙しく、機器は完全かつ効率的に使用されます-頂点シェーダーは常に頂点を処理し、ラスタライザーは常にピクセルをラスタライズします。 しかし、ある段階が他の段階よりもはるかに長くかかる場合を想像してください。



ここでは、高価な頂点シェーダーは次のステージに十分な速度でデータを転送できないため、「ボトルネック」になります。 このような描画呼び出しがある場合、ピクセルシェーダーを高速化しても、描画呼び出し全体の全体的なレンダリング時間はそれほど変わりません。 速度を上げる唯一の方法は、頂点シェーダーで費やされる時間を減らすことです。 解決方法は、頂点シェーダーの段階で「マッシュ」の作成につながるという事実に依存します。

ある種の「ボトルネック」がほとんど常に存在することを忘れないでください-あるものを取り除くと、別のものが単にその代わりになります。 秘Theは、いつ対処できるのか、いつ我慢しなければならないのかを理解することです。これがレンダリングの価格だからです。 最適化中に、オプションの「ボトルネック」を取り除くよう努めています。 しかし、「ボトルネック」が何であるかをどのように判断するのでしょうか？

プロファイリング

ビデオプロセッサの時間が何に費やされているかを判断するには、プロファイリングツールが絶対に必要です。 それらのベストは、物事をスピードアップするために変更する必要があるものを指摘することさえできます。 さまざまな方法でそれを行います-「ボトルネック」のリストを明示的に表示するものもあれば、「実験」して結果を観察できるものもあります（たとえば、「すべてのテクスチャを小さくするとレンダリング時間がどのように変化するか」メモリ帯域幅またはキャッシュ使用量）。

残念なことに、ここではすべてがより複雑になります。これは、最高のプロファイリングツールの一部がコンソールでのみ利用可能であり、したがってNDAの対象となるためです。 XboxまたはPlaystation用のゲームを開発している場合は、グラフィックプログラマーに連絡してこれらのツールを提示してください。 プログラマーは、アーティストが生産性に影響を与えたいときが大好きで、質問に答えたり、ツールを効果的に使用する方法についての指示を書いたりすることもできます。


基本的なUnityエンジンビデオプロセッサープロファイラー

PCには、NVIDIAのNsight 、AMDのGPU PerfStudio 、 GPA Intelなどのビデオプロセッサのメーカーから入手できる、かなり優れた（ただしハードウェア固有の）プロファイリングツールがあります。 さらに、 RenderDocがあります。これは、PCでグラフィックをデバッグするための最適なツールですが、高度なプロファイリング機能はありません。 Microsoftは、D3D12アプリケーション専用の場合でも、WindowsですばらしいXbox PIXプロファイリングツールを起動しています。 会社がXboxバージョンと同じボトルネック分析ツールを作成することを想定している場合（そして、これは非常に多様な機器を考えると困難です）、これはPC開発者にとって優れたリソースになります。

これらのツールは、グラフィックの速度に関するすべての情報を提供できます。 また、フレームがエンジンでどのようにコンパイルされるかについて多くのヒントを提供し、デバッグを可能にします。

アーティストはグラフィックの速度に責任を負わなければならないため、彼らと一緒に作品をマスターすることが重要です。しかし、すべてを自分で完全に理解することを期待しないでください-優れたエンジンには、パフォーマンス分析用の独自のツールがあり、理想的には、グラフィックリソースがパフォーマンスフレームワークに適合するかどうかを判断できるメトリックと推奨事項を提供する必要があります。パフォーマンスにもっと影響を与えたいが、必要なツールが不足していると感じたら、プログラマーのチームに相談してください。そのようなツールはすでに存在している可能性が高く、存在しない場合は作成する必要があります！

ビデオプロセッサのしくみとボトルネックがわかったので、ようやく興味深いことができます。コンベアで発生する可能性がある最も一般的な「ボトルネック」を掘り下げましょう。これは、実際の生活で最も頻繁に発生し、それらがどのように表示され、何ができるかを学びましょう。

シェーダーの説明

ビデオプロセッサのほとんどの作業はシェーダーによって実行されるため、多くの場合、多くの「ボトルネック」の原因になります。シェーダー命令が「ボトルネック」と呼ばれる場合、それは単に頂点シェーダーまたはピクセルシェーダーの処理が多すぎることを意味し、パイプラインの残りの部分は完了するまで待機する必要があります。

多くの場合、頂点またはピクセルシェーダープログラムは複雑すぎて、多くの命令が含まれており、実行に多くの時間がかかります。または、頂点シェーダーでも十分に受け入れられますが、レンダリングされたグリッドに頂点が多すぎるため、頂点シェーダーの実行に時間がかかりすぎます。または、描画呼び出しは、画面の広い領域と多くのピクセルに影響し、ピクセルシェーダーでは多くの時間がかかります。

当然のことながら、シェーダー命令のボトルネックを最適化する最良の方法は、実行する命令を少なくすることです！ピクセルシェーダーの場合、これは、ピクセルごとに実行される命令の数を減らすために、より少ない特性を持つより単純なマテリアルを選択する必要があることを意味します。頂点シェーダーの場合、これは、処理する頂点の数を減らすためにグリッドを単純化する必要があり、LODも使用することを意味します（詳細レベル、詳細レベルは、オブジェクトが遠くにあり、画面上のスペースをほとんど占有しない場合に使用されるグリッドの単純化バージョンです）。

ただし、シェーダー命令の「輻輳」は、単に別の領域の問題を示している場合があります。過剰な再描画、LODシステムパフォーマンスの低下、その他の多くの問題により、ビデオプロセッサが必要以上に多くの作業を行う場合があります。これらの問題は、エンジン側とコンテンツ側の両方から発生する可能性があります。慎重なプロファイリング、注意深い研究、および経験は、何が起こっているかを知るのに役立ちます。

最も一般的なこのような問題の1つは、オーバードローです。。多くの描画呼び出しに影響するため、画面上の同じピクセルを数回シェーディングする必要があります。再描画は、ビデオプロセッサがレンダリングに費やすことができる全体の時間を短縮するため、問題です。画面の各ピクセルを2回シェーディングする必要がある場合、同じフレームレートを維持するために、ビデオプロセッサは各ピクセルで半分の時間しか使用できません。


再描画レンダリングモードのPIXゲームフレーム

たとえば、パーティクルや草などの半透明のオブジェクトをレンダリングする場合、再描画が避けられない場合があります。背景のオブジェクトは前景のオブジェクトを通して見えるため、両方をレンダリングする必要があります。ただし、不透明なオブジェクトの場合、レンダリングプロセスの最後にバッファに含まれるピクセルのみが処理される必要があるため、再描画は絶対に必要ありません。この場合、再描画された各ピクセルは、ビデオプロセッサ時間の余分な無駄です。

ビデオプロセッサは、不透明なオブジェクトの再描画を減らすための措置を講じています。初期深度テスト（ピクセルシェーダーの前に実行されます-記事の冒頭のパイプライン図を参照）は、ピクセルが別のオブジェクトの後ろに隠れていると判断した場合、ピクセルシェーディングをスキップします。これを行うために、彼はシェーディングされたピクセルをデプスバッファーと比較します。デプスバッファーは、ビデオプロセッサがフレーム全体の深度を格納するターゲットレンダーで、オブジェクトが互いに正しく重なり合うようにします。ただし、初期深度テストを有効にするには、別のオブジェクトを深度バッファに入れる必要があります。つまり、完全にレンダリングする必要があります。これは、オブジェクトがレンダリングされる順序が非常に重要であることを意味します。

理想的には、各シーンは前面から背面にレンダリングする必要があります（つまり、カメラに最も近いオブジェクトが最初にレンダリングされます）。これにより、前面のピクセルのみが不明瞭になり、残りは初期深度テストで破棄され、再描画が完全に排除されます。しかし、現実の世界では、これは常に機能するとは限りません。レンダリングプロセス中に、描画呼び出し内の三角形の順序を変更することは不可能だからです。複雑なグリッドは何度も重なり合う可能性があり、グリッドを組み合わせると、「間違った」順序でレンダリングされて再描画につながる多くの重なり合うオブジェクトが作成される可能性があります。これらの質問に対する単純な答えはありません。これは、グリッドをマージすることを決定する際に考慮すべき別の側面です。

初期の深度テストを支援するために、一部のゲームは部分的に実行します (depth prepass)。これは準備通路です。他のオブジェクト（大きな建物、地形、メインキャラクターなど）と効果的にオーバーラップできるいくつかの大きなオブジェクトは、深度バッファーにのみ出力する単純なシェーダーでレンダリングされます。ピクセルシェーダーのライティングとテクスチャリングの作業は実行されません。これにより、深度バッファが「改善」され、フルレンダリングパス中にスキップできるピクセルシェーダーの作業量が増加します。このアプローチの欠点は、重複するオブジェクトの二重レンダリング（最初は深さのみの通路で、次にメインの通路）が描画呼び出しの回数を増やすことに加えて、深さの通路をレンダリングする時間が保存時間よりも長くなる可能性が常にあることです初期深度テストの効果を高めます。詳細なプロファイリングによってのみ、このアプローチを特定のシーンで使用する価値があるかどうかを判断できます。


プロトタイプ2での爆発粒子の再描画の視覚化。 粒子が透明で、多くの場合強く重なり合っている場合、粒子をレンダリングする

際の再描画は特に重要です。エフェクトを作成するとき、パーティクルを使用するアーティストは常に再描画することを忘れないでください。厚い雲の効果は、多数の小さな重なり合う粒子を放出することで作成できますが、これにより、効果のレンダリングのコストが大幅に増加します。放出する大きなパーティクルは少なく、テクスチャとテクスチャアニメーションに依存して密度効果を伝える方が良いでしょう。この場合、FumeFXやHoudiniなどのソフトウェアは、通常、個々のパーティクルの動作のリアルタイムシミュレーションよりも、テクスチャアニメーションを介してはるかに興味深い効果を作成できるため、結果は視覚的に効果的です。

エンジンは、パーティクルを計算するためのビデオプロセッサの不要な作業を取り除くための手順を実行することもできます。結果として完全に透明であることが判明したレンダリングされた各ピクセルは時間の無駄です。そのため、パーティクルは通常、パーティクルトリミング用に最適化されています。パーティクルを2つの三角形でレンダリングする代わりに、使用されるテクスチャの空の領域を最小化するポリゴンが生成されます。


Unreal Engine 4

のパーティクルカットツール同じことは、植生などの他の部分的に透明なオブジェクトでも実行できます。実際、植生は頻繁に使用されるため、植生が任意のジオメトリを使用することはさらに重要です。これにより、大量の空のテクスチャスペースを取り除くことができます。アルファテスト（アルファテスト）。テクスチャのアルファチャネルを使用して、ピクセルをピクセルシェーダーステージでドロップする必要があるかどうかを判断し、ピクセルを透明にします。これは問題です。アルファテストには副作用があるため、深度の初期テキストが完全に無効になります（ビデオプロセッサがピクセルに関して行う仮定が無効になるため）。これにより、ピクセルシェーダーの不要な操作が非常に多くなります。さらに、植生には多くの再描画が含まれます（ツリーのすべての葉が互いに重なり合っていると考えてください）。注意しないと、レンダリング時にすぐに非常に高価になります。

再描画と効果が非常に似ているのは、オーバーシェーディングです。小さい三角形または細い三角形が原因です。ビデオプロセッサの時間の大部分を無駄にすることで、パフォーマンスを大きく損なう可能性があります。過度のシェーディングは、ピクセルをシェーディングするときにビデオプロセッサがピクセルを処理する方法の結果です：一度に1つではなく、「クワッド」。これらは、2x2の正方形に配置された4つのピクセルのブロックです。これは、装置がピクセル間でUVを比較してMIPテクスチャの適切なレベルを計算するなどのタスクに対処できるようにするためです。

つまり、三角形が1つのクワッドポイントにしか触れない場合（三角形が小さいか非常に薄いため）、ビデオプロセッサはクワッド全体を処理し、残りの3ピクセルを単純に破棄し、作業の75％を無駄にします。この無駄な時間は累積する可能性があり、ピクセルシェーダーの単一パスでライティングとシェーディングの計算を実行する直接（つまり、延期されない）レンダラーにとって特に敏感です。この負荷は、適切に構成されたLODを使用することで削減できます。頂点シェーダー処理の節約に加えて、平均して、三角形が各クワッドのほとんどをカバーするという事実により、不必要なシェーディングの量を大幅に削減します。


5x4クワッドの10x8ピクセルバッファー。 2つの三角形はクワッドを不適切に使用します-左の三角形は小さすぎ、右の三角形は薄すぎます。実際には12の緑ピクセルのみがシェーディングを必要としますが、三角形が接触する10の赤い四角形は完全にシェーディングする必要があります。一般に、ビデオプロセッサの作業の70％が無駄になります。

（追加情報：四角形の過度のシェーディングは、画面に重なるために2つの隣接する三角形の代わりに1つの大きな三角形を使用するフルスクリーンポストエフェクトをモニターに表示することがよくあります。2つの三角形を使用する場合、動作するため、ビデオプロセッサの時間をわずかに節約するために回避されます。）

過度のシェーディングに加えて、小さな三角形は別の問題を引き起こします。ビデオプロセッサは、特定の速度で三角形を処理およびラスタライズします。通常、同時に処理できるピクセル数と比較すると、この速度は比較的小さくなります。小さな三角形が多すぎると、ピクセルを十分に速く作成できないため、シェーダーが常に機能し、ビデオプロセッサのパフォーマンスの本当の敵である遅延とダウンタイムにつながります。

細長い三角形は、四角形の使用だけでなく、パフォーマンスに悪影響を及ぼします。ビデオプロセッサは、長いストライプではなく、正方形または長方形のブロックでピクセルをラスタライズします。正三角形と比較して、長く細い三角形は、ビデオプロセッサがピクセルにラスタライズするために多くの追加のオプションの作業を作成し、ラスタライズ段階で「ボトルネック」の外観につながる可能性があります。そのため、通常、ポリゴンの数がわずかに増えたとしても、グリッドを正三角形にテッセレーションすることが推奨されます。他のすべての場合と同様に、実験とプロファイリングにより、最適なバランスを実現できます。

メモリ帯域幅とテクスチャ

上記のビデオプロセッサパイプライン図に示すように、グリッドとテクスチャは、シェーダープロセッサから物理的に分離されたメモリに格納されます。つまり、ビデオプロセッサがデータの一部、たとえばピクセルシェーダーから要求されたテクスチャにアクセスする必要がある場合、計算する前にメモリから取得する必要があります。

メモリへのアクセスは、インターネットからファイルをダウンロードすることに似ています。インターネット接続の帯域幅、つまりデータを送信できる速度によっては、ファイルのダウンロードに時間がかかります。この帯域幅はすべてのダウンロードに共通です-1つのファイルを6MB /秒の速度でダウンロードできる場合、2つのファイルがそれぞれ3MB /秒の速度でダウンロードされます。

これはメモリへのアクセスにも当てはまります。ビデオプロセッサがインデックス/頂点バッファとテクスチャにアクセスするのに時間がかかり、速度はメモリ帯域幅によって制限されます。明らかに、速度はインターネット接続よりもはるかに高速です-理論的には、PS4ビデオプロセッサの帯域幅は176GB / sです-原理は同じままです。複数のテクスチャを参照するシェーダーは、必要なすべてのデータを時間通りに転送する必要があるため、帯域幅に大きく依存しています。

シェーダープログラムは、これらの制限を考慮してビデオプロセッサで実行されます。テクスチャにアクセスする必要があるシェーダーは、できるだけ早く転送を開始し、その後、無関係な別の作業（たとえば、照明の計算）を行い、開始時にテクスチャデータが既にメモリから受信されることを望んでいます。プログラムの必要な部分。転送が他の多くの転送によって遅くなったという事実、または他のすべての作業が終了したためにデータが時間どおりに受信されない場合（これは特に相互依存テクスチャの要求である可能性が高い）、実行が停止し、シェーダーはアイドル状態でデータを待機しています。これはメモリのボトルネックと呼ばれます。：シェーダーが停止し、メモリからデータが受信されるのを待たなければならない場合、シェーダーがどれだけ速く動作するかは関係ありません。最適化する唯一の方法は、占有メモリ帯域幅または転送データ量、あるいはその両方を同時に削減することです。

メモリ帯域幅は、ビデオプロセッサが同時に実行する中央処理装置または非同期コンピューティング作業と共有する必要さえあります。これは非常に貴重なリソースです。多くのデータが含まれているため、テクスチャ転送は通常、メモリ帯域幅の大部分を占めます。したがって、送信する必要があるテクスチャデータの量を減らすためのさまざまなメカニズムがあります。

最初で最も重要なのはキャッシュです。。これは、ビデオプロセッサが非常にすばやくアクセスできる高速メモリの小さな領域です。ビデオプロセッサが再び必要になった場合に備えて、最近受信したメモリを保存します。インターネット接続との類推を続けると、キャッシュは、将来の高速アクセスのためにダウンロードされたファイルが保存されるコンピューターのハードディスクです。

たとえば、テクスチャ内の個別のテクセルにメモリの一部にアクセスする場合、周囲のテクセルも同じメモリデータ転送でキャッシュにロードされます。次回ビデオプロセッサがこれらのテクセルの1つを検索するとき、メモリまでずっと移動する必要はなく、キャッシュからテクセルを非常にすばやく取得できます。実際、この手法は非常に頻繁に使用されます。テクセルが1ピクセルで画面に表示される場合、その隣のピクセルはテクスチャの同じテクセルまたは隣接するテクセルを表示する必要がある可能性が非常に高くなります。この場合、メモリから何も転送する必要はなく、帯域幅は使用されず、ビデオプロセッサはキャッシュされたデータにほぼ瞬時にアクセスできます。したがって、キャッシュはメモリ関連のボトルネックを取り除くために不可欠です。特に考慮した場合フィルタリング -バイリニア、トリリニア、および異方性フィルタリングでは、検索ごとにいくつかのピクセルが必要であり、帯域幅が追加でロードされます。高帯域幅の異方性フィルタリングは特に強力です。

ここで、非常に遠くにあり、画面上で数ピクセルしか占有しないオブジェクトに大きなテクスチャ（たとえば、2048x2048）を表示しようとすると、キャッシュで何が起こるかを想像してください。各ピクセルはテクスチャの完全に独立した部分から取得する必要があり、この場合のキャッシュは以前のアクセスから受け取ったものに近いテクセルのみを保存するため、完全に無効になります。テクスチャにアクセスする各操作は、キャッシュで結果を見つけようとしますが、失敗します（いわゆる「キャッシュミス」）。したがって、メモリからデータを取得する必要があります。つまり、2回無駄になります。データ。シェーダー全体の速度が遅くなる場合があります。また、他の（潜在的に有用な）データがキャッシュから削除される可能性があります。決して便利になることのない隣接テクセルのためのスペースを確保し、全体的なキャッシュ効率を低下させます。あらゆる点で、これは悪いニュースです。グラフィックの品質の問題は言うまでもありません。小さなカメラの動きは完全に異なるテクセルのサンプリングをもたらし、歪みとちらつきをもたらします。

そして、ここでMIPテクスチャリング（ミップマッピング）が役立ちます。。テクスチャを要求されると、ビデオプロセッサは各ピクセルで使用されているテクスチャの座標を分析し、テクスチャにアクセスする操作の座標間に大きなギャップがあるかどうかを判断できます。各テクセルの「キャッシュミス」の代わりに、目的の解像度に対応する小さなMIPテクスチャにアクセスします。これにより、キャッシュの効率が大幅に向上し、帯域幅の使用量と帯域幅に関連するボトルネックの可能性が減少します。 MIPテクスチャを小さくすると、メモリから転送するデータが少なくなり、帯域幅の負荷がさらに軽減されます。最後に、MIPテクスチャは事前にフィルタリングされているため、MIPテクスチャを使用すると、歪みとちらつきが大幅に減少します。したがって、MIPテクスチャリングはほぼ常に使用する必要があります。その利点は、占有メモリの量を増やす価値があります。


2つのクワッドのテクスチャ、他ははるかにありながら、カメラに近いとなっている1


2倍少ない、以前よりもそれぞれのMIP-テクスチャの適切なチェーンと同じテクスチャ

そして最後に-帯域幅とキャッシュの使用を減らすための重要な方法-この圧縮（圧縮）テクスチャ（さらに、より少ないテクスチャデータを保存することでメモリスペースを節約します）。 BC（以前はDXT圧縮として知られていたブロック圧縮）テクスチャを使用すると、品質がわずかに低下するだけで、元のサイズの4分の1または6分の1まで縮小できます。これにより、送信および処理されるデータが大幅に削減され、ほとんどのビデオプロセッサは圧縮されたテクスチャをキャッシュに保存します。これにより、他のテクスチャのデータを保存するスペースが増え、全体的なキャッシュ効率が向上します。

上記の情報はすべて、アーティストの観点からテクスチャを最適化する際に帯域幅の混雑を軽減または排除するためのいくつかの明白な手順につながっているはずです。テクスチャにMIPがあり、圧縮されていることを確認してください。 2xで十分な場合は「重い」異方性フィルタリング8xまたは16xを使用する必要はありません。また、トリリニア/バイリニアフィルタリングでさえも使用する必要はありません。特に画面に詳細が最大のMIPテクスチャが表示される場合は特に、テクスチャの解像度を下げてください。テクスチャへのアクセスを必要とする不必要なマテリアル関数を使用しないでください。そして、受信したすべてのデータが実際に使用されていることを確認します-実際に赤チャネルデータのみが必要な場合は、4つのRGBAテクスチャをサンプリングしないでください。これら4つのチャネルを1つのテクスチャに結合し、帯域幅負荷の75％を排除します。

テクスチャはメインですが、メモリ帯域幅の「ユーザー」だけではありません。グリッドデータ（インデックスおよび頂点バッファー）もメモリからロードする必要があります。ビデオプロセッサパイプラインの最初の図では、最終ターゲットレンダーの出力がメモリに書き込まれていることがわかります。これらの送信はすべて、通常1つの共通メモリ帯域幅を占有します。

通常のレンダリングでは、テクスチャデータと比較して、このデータ量は比較的少ないため、これらのコストは通常​​すべて目に見えませんが、常にそうであるとは限りません。通常の描画呼び出しとは異なり、シャドウパスの動作はまったく異なり、帯域幅を制限する可能性がはるかに高くなります。


GTA Vから撮影したシャドウマップ、フレームの優れた分析からの図Adriana Correger（元の記事）

これは、シャドウマップが光源から最も近いグリッドまでの距離を表す単なる深度バッファーであるため、シャドウのレンダリングに必要な作業のほとんどは、メモリからメモリにデータを転送することです：頂点バッファーの取得/インデックス、単純な計算を実行して位置を決定し、グリッドの深さをシャドウマップに書き込みます。ほとんどの場合、必要な深さ情報はすべてこれらの頂点から取得されるため、ピクセルシェーダーは実行されません。したがって、シャドウパスは必要な帯域幅に直接影響するため、頂点/三角形の数とシャドウマップの解像度に特に敏感です。

メモリ帯域幅に関して最後に言及するのは、Xboxという特別な場合です。 Xbox 360とXbox Oneの両方には、360 EDRAMとXB1 ESRAMと呼ばれるビデオプロセッサの近くに特別なメモリがあります。。これは比較的少量のメモリ（360では10 MB、XB1では32 MB）ですが、いくつかのターゲットレンダーを格納するのに十分な大きさであり、一般的に使用されるテクスチャがある場合があります。同時に、その帯域幅は標準システムメモリ（DRAM）の帯域幅よりもはるかに高くなっています。速度が重要であるだけでなく、この帯域幅には独自のチャネルがあります。つまり、DRAM伝送に接続されていません。これによりエンジンが複雑になりますが、効率的に使用すると、帯域幅が制限されている状況でより広い範囲が得られます。通常、アーティストはEDRAM / ESRAMに書き込まれる内容を制御できませんが、プロファイリングに関してはそれらに注意する必要があります。エンジンの実装機能の詳細については、3Dプログラマーから学ぶことができます。

その他多数...

おそらく既に理解しているように、ビデオプロセッサは洗練された機器です。データを転送するための思慮深い方法で、彼らは膨大な量のデータを処理し、毎秒何十億もの計算を実行することができます。一方、低品質のデータと非効率的な使用では、ほとんどクリープせず、ゲームのフレームレートに悲惨な影響を与えます。

このトピックについてはまだ議論して説明することがたくさんありますが、技術的なことを考えているアーティストにとっては、そのような説明は良い出発点になります。ビデオプロセッサのしくみを理解すると、見栄えがよくなるだけでなく、高速を提供するグラフィックを作成できます...高速はグラフィックをさらに改善し、ゲームをより美しくすることができます。

この記事から多くのことを学ぶことができますが、チームの3Dプログラマーは常にあなたと会い、深い説明を必要とするすべてについて話し合う準備ができていることを忘れないでください。

その他の技術記事

• 地獄レンダリング -サイモンTrumpler
• テクスチャフィルタリング：ミップマップ-Shawn Hargreaves
• ゲーム用グラフィックスジェム-Avalanche Studiosの調査結果 -Emil Persson
• 三角測量 -Emil Persson
• GPU上の小さな三角形はどれほど悪いのですか？-クリストフ・リッチョ
• ゲームアートトリック -サイモントランプラー
• パーティクルシステムのレンダリングの最適化 -Christer Ericson
  
• 実用的なテクスチャアトラス-Ivan -Assen Ivanov
  
• GPUの仕組み -David Luebke＆Greg Humphreys
  
• 低レベルグラフィックプログラミングのカジュアルな紹介 -Stephanie Hurlburt
  
• カウンティングクワッド -スティーブンヒル
  
• オーバードライブでオーバードロー -スティーブンヒル
  
• Life of a Triangle-NVIDIAの論理パイプライン -NVIDIA
  
• シェーダーコードからテラフロップまで：シェーダーコアの仕組み-Kayvon Fatahalian
  
• グラフィックパイプラインの旅（2011） -Fabian Giesen
  

注：この記事は元々、その作者Keith O'Conor によってfragmentbuffer.comで公開されました。キースの他のメモは、彼のTwitterアカウント（@keithoconor）で読むことができます。