地獄のレンダリング1.1：

• ブック1：概要
• ブック2：問題
• ブック3：ソリューション
• ブック4：結論

知識の欠如が美徳になることがあります。「Pff ...難しいですか？」と素直に言って、頭の問題に突入してください。 この記事を始めたのは、「うーん... Draw Callとは何ですか？」 「5分間」の研究の間に、私が満足する説明は見つかりませんでした。 私は時計をチェックしましたが、寝る前にまだ30分あったので...

Pff ...自分で書くのは難しいですか？

...そして始めたばかりです。 これは2か月前であり、それ以来、私は継続的に読み、書き、多くの質問をしてきました。



これは私がこれまでに行った中で最も複雑で低レベルの研究であり、プログラマーではない私にとっては、「はい、しかしこの特別な場合...」と「APIの実装に依存する...」からなる悪夢でした。 それは私の個人的な視覚化の地獄でしたが、私はそれを経験し、何かをもたらしました。4冊の本はそれぞれ、視覚化の一部をアーティストの観点から説明する試みです。 楽しんでいただければ幸いです。







今日、アーティストは熟知する必要があります。コンピューターの観点からすると、ゲームリソースは頂点とテクスチャデータのセットにすぎません。 この生データの「次世代」レベルの画像への変換は、主に中央処理装置（ CPU ）とグラフィックス処理装置（ GPU ）によって行われます。

1.すばやくアクセスできるようにデータをRAMにコピーします

まず、必要なすべてのデータがハードディスク（ HDD ）からランダムアクセスメモリ（ RAM ）にダウンロードされ、すばやくアクセスできます。 その後、必要なポリゴンメッシュとテクスチャがグラフィックカード（ VRAM ）のメモリにロードされます。 これは、グラフィックカードがVRAMへのアクセスを大幅に高速化し、ほとんどの場合RAMにアクセスできないためです。







視覚化側が機能する前に、CPU はポリゴンメッシュの表示方法を記述するグローバル値を設定します。 この値のセットはRender Stateと呼ばれます。

2.レンダリング状態の値を設定する

レンダリング状態は、ポリゴンメッシュのレンダリング方法のグローバルな定義です。 以下に関する情報が含まれています。

「頂点シェーダー、ピクセルシェーダー、テクスチャ、マテリアル、ライティング、透明度など。 [...]” [ リアルタイムレンダリング ：p。711]

CPUがレンダリングのためにGPUに渡す各ポリゴンメッシュがこれらの条件で表示されることが重要です！ 石、椅子、または剣を描くことができます。次のグリッドが表示されるまでレンダリング状態を変更しない限り、それらはすべて同じレンダリングオプション（マテリアルなど）を使用します。







準備が完了した後、CPUは最終的にGPUを使用して、何を描画するかを指示できます。 このコマンドはDraw Callとして知られています。

3.コールを引く

Draw Callは、 1つのポリゴンメッシュを表示するコマンドです。 それは中央処理装置に与えられます。 グラフィックプロセッサを受け取ります。 このコマンドは、表示されるポリゴンメッシュのみを示します。マテリアルに関する情報は含まれていません。これは、Render State設定で既に定義されているためです。 この時点で、ポリゴンメッシュはグラフィックカードメモリ（VRAM）にあります。







コマンドが発行されると、GPUはレンダリング状態パラメーター（マテリアル、テクスチャ、シェーダーなど）とすべての頂点データを取得し、この情報を魔法で画面上の美しい（できれば）ピクセルに変換します。 この変換プロセスはパイプラインと呼ばれます。

4.コンベヤー

前述したように、ゲームリソースは、ある意味では、頂点とテクスチャデータのセットにすぎません。 それらを見事な画像に変換するには、グラフィックマップの頂点から三角形を作成し、それらのイルミネーションを計算し、それらにテクスチャピクセルを表示する必要があります。 これらのアクションは状態と呼ばれます。 コンベヤーの状態。



読む資料によっては、ほぼすべてがGPUによって実行されることがわかります。 しかし、たとえば、三角形やフラグメントの作成はグラフィックカードの他の部分によって行われると言われることもあります。

コンベアのこの例は非常に単純化されており、一般的な考えを与えるものとしてのみ解釈されるべきです。 私はできる限りそれを描写しようとしましたが、プログラマーではないので、例が非常に単純になり、間違った方向に導く場合を理解するのに問題があります。 したがって、それを真剣に受け取らないでください。記事の最後で引用した他のすべてのすばらしい情報源を見てください。 または、アニメーション/説明を改善するために、私に手紙、ツイート、またはFacebookの投稿を自由に書いてください。 :)

GPUコアが1つの場合の例を次に示します。





視覚化は、数千の頂点に対して何かを計算したり、画面上に数百万のピクセルを描画するなど、膨大な数の小さなタスクを実行するだけです。 1秒あたり30フレームで少なくとも（良好）。



これらのことを同時に計算できることが重要であり、すべての頂点/ピクセルが次々に計算されるわけではありません。 古き良き時代には、プロセッサにはコアが1つしかなく、グラフィックアクセラレーションはありませんでした。一度に1つのことしかできませんでした。 ゲームは...レトロのように見えました。 最新のCPUには6〜8コアがあり、GPUには数千が含まれています（CPUコアほど複雑ではありませんが、膨大な数の頂点およびピクセルデータを通過させるのに最適です）。



データ（たとえば、頂点の束）がパイプラインステージに到達すると、ポイント/ピクセルの変換作業がいくつかのカーネル間で分割され、これらの小さな要素の大部分が並行して大きな画像に形成されます。







これで、GPUがすべてを並行して処理できることがわかりました。 しかし、CPUとGPU間の通信はどうでしょうか？ CPUは、GPUが処理を終了し、新しいコマンドを受信できるようになるのを待っていますか？

いや！

幸いなことにそうではありません！ その理由は、そのような通信が「ボトルネック」を形成し（たとえば、CPUが十分な速度でコマンドを配信できない場合）、並列操作が不可能になるためです。 ソリューションは、CPUを追加し、GPUを個別に読み取ることができるリストです！ このようなリストはコマンドバッファと呼ばれます。

5.コマンドバッファ

命令バッファにより、CPUとGPUは互いに独立して動作できます。 CPUが何かを表示したい場合、コマンドをキューに入れ、GPUに空きリソースがある場合、リストからコマンドを取得して実行します（ただし、リストはFIFOとして配置されているため、GPUはリストから最も古いコマンドのみを取得できます（最初に追加された）、それを実行します）。







ただし、チームは異なる場合があります。 1つの例はDraw Callで、もう1つはRender Stateの変更です。



これが最初の本の終わりです。 これで、ゲームリソースデータ、描画呼び出し、レンダリング状態、およびCPUとGPU間の相互作用に関する基本的な理解が得られました。



終わり