昔は描画速度をポリゴン数で測っていました。今は、違いますね。
その原因の1つは、測定条件の記述が現実の問題を離れたからでしょう。論理的な裏付けが必要なら測定条件にも限定が必要です。例えばこんな感じ。
- 単位時間以内に、描かれる重ならない3角形の数を数える。
- ポリゴンの形状は、頂点の2次元座標で与えらる。座標は、16bitの整数とする。(ポリゴン毎に96bitになる)
- 描画するときに、3x3のアフェイン変換する。行列式の係数は、16bit 固定小数点とする。
- 描画の際に画面サイズを考慮しない。
- ポリゴンの内側の色塗りは考えない。
これだとほぼ純粋に乗算器の個数に比例する。NVIDIAのデバイスの場合、たぶんFP32で50Tflops くらいでていそうで、FP32乗算一回で、int16乗算3回くらいできそう。すると、150T 乗算/sec.
上の条件で1つのポリゴンの頂点位置を計算する計算量を考えると、結局行列の大きさになって、9乗算/ポリゴン。現在のハードウエアのトレンドからすると、加算は考慮する必要はない。
すると、
150T / 9 = 16.6T polygon / sec.
個数が莫大だと、メモリ、PCIeバスの速度のために頭打ちになる。
ポリゴンが完全にパックされてバスを転送されるとすると、ポリゴン当たりのデータ量は、
3 x 2 x 16bit = 12 B/polygon
PCIeバスの速度が、32レーン、PCIe 3.0 だと、PCIeバスを通過できるポリゴンの数は、
32 x 16Gbit = 64GB/sec => 64GB/sec / 12B/polygon = 5Gpolygon / sec
残念。PCIeバスが遅いので、こんな単純な描画じゃデバイスの性能を生かしきれない。
しかも、この描画プロセスがバスを専有できることもないから、実際の描画量はもっと減る。
現実のゲームの描画では、始めの過程は大きく違う。たぶんこんな感じ?
- ポリゴンは3次元で座標は、FP32 or FP64.
- ポリゴンには、表面があって、表面に、入射光の周波数に合わせた透明度、反射係数のような属性がある。
- ポリゴンはお互いに重なるので、陰面処理が必要。
- 描画時には、グラデーション効果がある色塗りが必要で、アンチエイリアス処理も行う。
各ポリゴンの全部のデータがPCIeバスの流れるのではなく、キャッシュされたり、複数のポリゴンが、同じ表面の属性をもっていたり、複数ポリゴンの頂点が共有される。
しかも、全部のポリゴンが正確に再計算されるのではなく、少しくらいの計算ミスは許され、後方にあるポリゴンは始めから計算対象ではなかったりする。cudaなり、stream なり描画ライブラリの性能にも依存する。
という今のゲームの要求を考えると何がなんだかさっぱりわからないからでは?