[ ホーム ] [ 上へ ] [ パラメータ設定集 ] [ Gravity2ベンチマーク ]

PII/350とK6-2/300@3DNow!の3Dグラフィックにおける、物理計算量とフレームレートの関係を計測してみた。
本結果は速報であり、後日計測方法の詳細をアップする予定。

　横軸は物理演算量を示す（１フレーム内60,000演算を１とした値：0.1は10分の1の演算量であることを示す）
縦軸はフレームレート(FPS）を示す。

　K6-2およびK6-IIIの物理演算は3DNow!によるものである。

　プログラムはDirectX5.0を前提にしており、計測はDirectX6.1の環境で行っているが、ジオメトリ演算、2次元座標変換に3DNow!が利用されているかは不明（利用されていないと予想される）。

　また3D RAGE Proはx2だが、3D RAGE LT Proはx1モードでしか測定できなかった（しかし大きな問題ではないようである）。

　物理演算が軽くなるに従い、フレームレートが頭打ちになるが、3DNow!による物理演算負荷がジオメトリ演算等に比べ軽いためPentiumIIより早く頭打ちになっている。

　早く頭打ちになるｌこと自体は問題ないが、このことから言えるのは物理演算とジオメトリ演算の負荷比率が異なるということである。これはジオメトリ演算には3DNow!が利用されていないか、最適な形で利用されていないと考えて間違いないと思う。
　ジオメトリ演算関係がFPUにて行われていると考えると、頭打ちとなるフレームレートがK6-450≒PentiumII350であることも納得できる（これはほぼWinBench98/99のFPUMark値の比率に等しい）。

　参考のために軌道計算をK6-III/450のFPUで行ったものも計測してみた。
　やはり、予想通り物理計算の負荷が軽い場合のフレームレートは3DNow!のそれとほぼ一致している。
　これからもDirect3Dの演算はFPUで行われていると考えて間違いない。

　やはりDirectX5.0でなくDirectX6.0/6.1で書き直すか、DirectXお任せ（RetainedMode）のジオメトリ演算ではなく、直接3DハードにアクセスするImmediateModeで書く必要がありそうだ。

　前出のグラフはGravity2の背後に流れる星の数を1,500として測定したもので、1,500の星の位置計算がDirect3Dサイドで行われている。

　そこで、その位置計算が処理に及ぼす影響を測るために、星の数を１にして計測したフレームレートを参考資料として以下に示す。