最新のハードウェアがリアルタイムを維持しながらシーン内のポリゴンをいくつ到達でき、そこに到達する方法は？

かなり基本的な、ある意味では質問ですが、私も含めて多くの人が答えを本当に知りません。GPUメーカーは非常に高い数値を引用することが多く、さまざまなゲームエンジンがサポートすると主張するポリゴン数のばらつきは、多くの場合、数桁に及び、依然として多くの変数に大きく依存しています。

これは広く、かなり自由回答の質問であることを承知しており、お詫び申し上げます。それでも、ここで貴重な質問になると思いました。

私は、リアルタイムがインタラクティブ以上のすべてであることは一般に受け入れられていると思います。インタラクティブとは、「入力に応答するが、アニメーションがギザギザに見えるという点で滑らかではない」と定義されています。
したがって、リアルタイムは、表現する必要のある動きの速度に依存します。シネマは24 FPSでプロジェクトを行い、多くの場合、十分にリアルタイムです。

次に、マシンが処理できるポリゴンの数は、自分で確認することで簡単に確認できます。単純なテストとFPSカウンターとして小さなVBOパッチを作成するだけで、多くのDirectXまたはOpenGLサンプルがこのベンチマークに最適なテストベッドを提供します。

リアルタイムで約100万のポリゴンを表示できるハイエンドのグラフィックスカードがあるかどうかを確認します。ただし、おっしゃったように、実際のシーンデータはポリゴン数とは関係のない多くのパフォーマンスを消費するため、エンジンはサポートをそれほど簡単には要求しません。

あなたが持っている：

• フィルレート
  • テクスチャーサンプリング
  • ROP出力
• 呼び出しを描画
• レンダリングターゲットスイッチ
• バッファの更新（均一またはその他）
• オーバードロー
• シェーダーの複雑さ
• パイプラインの複雑さ（使用されるフィードバック？反復的なジオメトリシェーディング？オクルージョン？）
• CPUとの同期ポイント（ピクセルリードバック？）
• ポリゴンの豊富さ

特定のグラフィックカードの弱点と長所に応じて、これらの点のいずれかがボトルネックになります。確かに「あれ、それだ」とは言えない。

編集：

私はそれを付け加えたかったのですが、特定のカードのGFlopsスペック図を使用して、それをポリゴンの押し込み能力に線形にマッピングすることはできません。ここで詳しく説明されているように、ポリゴンの処理はグラフィックスパイプラインの順次ボトルネックを通過する必要があるため、https： //fgiesen.wordpress.com/2011/07/03/a-trip-through-the-graphics -pipeline-2011-part-3 /
TLDR：頂点は、プリミティブアセンブリの前に小さなキャッシュに収まる必要があります。プリミティブアセンブリは、ネイティブで順次的なものです（頂点バッファーの順序が重要です）。

GeForce 7800（9年前？）を今年の980と比較すると、1秒間に実行できる操作数は1000倍に増加しているようです。しかし、ポリゴンを1000倍速くプッシュすることはできないでしょう（この単純なメトリックでは、1秒あたり約2,000億になります）。

EDIT2：

「エンジンを最適化するために何ができるか」という質問に答えるには、「状態の切り替えやその他のオーバーヘッドであまり効率を失わないようにする」のように。
それはエンジン自体と同じくらい古い問題です。そして、歴史が進むにつれて、ますます複雑になっています。

実際、実際の状況では、典型的なシーンデータには、多くのマテリアル、多くのテクスチャ、多くの異なるシェーダー、多くのレンダーターゲットとパス、および多くの頂点バッファーなどが含まれます。私が使用した1つのエンジンは、パケットの概念で機能しました。

1つのパケットは、1回の描画呼び出しでレンダリングできるものです。
次の識別子が含まれています。

• 頂点バッファー
• インデックスバッファ
• カメラ（パスとレンダーターゲットを提供）
• マテリアルID（シェーダー、テクスチャ、UBOを提供）
• 目までの距離
• 見える

したがって、各フレームの最初のステップは、可視性、パス、マテリアル、ジオメトリ、最後に距離を優先する演算子を使用したソート関数を使用して、パケットリストでクイックソートを実行することです。

近いオブジェクトを描画することは、初期のZカリングを最大化するために優先されます。
パスは固定ステップであるため、それらを尊重するしかありません。
マテリアルは、レンダーターゲットの後に状態を切り替えるのに最も費用がかかるものです。

異なるマテリアルIDの中間であっても、ヒューリスティック基準を使用してサブオーダーを作成し、シェーダーの変更（マテリアルの状態切り替え操作内で最も高価）の数を減らし、次にテクスチャバインディングの変更を減らすことができます。

このすべての順序付けの後、必要と思われる場合は、メガテクスチャリング、仮想テクスチャリング、および属性のないレンダリング（link）を適用できます。

エンジンAPIについても、クライアントが必要とする状態設定コマンドの発行を延期することはよくあります。クライアントが「カメラの設定0」を要求した場合、この要求を保存するのが最善であり、後でクライアントが「カメラ1を設定」を呼び出したが、その間に他のコマンドがない場合、エンジンは最初のコマンドの無用を検出して削除できます。 。これは冗長性の排除であり、「完全に保持された」パラダイムを使用することで可能になります。ネイティブAPIの単なるラッパーであり、クライアントコードの順序どおりにコマンドを発行する「即時」パラダイムとは反対です。（例：virtrev）

そして最後に、最新のハードウェアを使用すると、（開発に）非常に費用がかかりますが、非常にやりがいのあるステップとして、APIをmetal / mantle / vulkan / DX12スタイルに切り替えて、レンダリングコマンドを手動で準備する必要があります。

レンダリングコマンドを準備するエンジンは、各フレームで上書きされる「コマンドリスト」を保持するバッファを作成します。

通常、フレームの「予算」という概念があり、ゲームには余裕があります。すべてを16ミリ秒で行う必要があるため、GPU時間を「lightpreパスの場合は2 ms」、「マテリアルパスの場合は4 ms」、「間接照明の場合は6 ms」、「後処理の場合は4 ms」と明確に分割します。