High-Performance Software Rasterization on GPUs (3)

（続き）

実験概要

• 環境
  • GPU: GTX480, RAM 1.5GB
  • CPU: Core i7, 2.80Hz, RAM 12GB
  • Windows 7, CUDA 3.2

• 比較対象
  • OpenGL で書いたパイプライン
  • FreePipe

• フォーマット
  • POSITION: FLOAT_32_32_32_32
  • COLOR: FLOAT_32_32_32_32
  • 頂点インデクス: UINT_32
  • カラーバッファ: FLOAT_8_8_8_8
  • デプスバッファ: FLOAT_32

• その他
  • 背面カリングあり
  • 1つのシーンにつき5箇所にカメラを置いて平均値を計測
  • 頂点シェーダの処理は計測しない
  • 単純なグーローシェーディング

実験結果

頂点数と解像度について

• ハードウェア(OpenGL)
  • フラグメント処理に比べると、頂点処理の計算量に影響されやすい
    • 頂点フェッチ、トライアングルセットアップ
  • 解像度にはあまり影響されない

• cudaraster
  • フラグメント処理に比べると、頂点処理の計算量に影響されにくい
  • 解像度に強く影響される
    • フィルレート

• FreePipe
  • いまいちロードバランスできてない
    • フラグメント処理を三角形単位で分散してる

描画モードと MSAA について

• ハードウェア(OpenGL)
  • MSAA のコストが超低い
  • カラー書き込み無しにしてもあまり変わらない

• cudaraster
  • MSAA のコストが超高い
    • DRAM 上のフレームバッファを毎回直接読んでる
  • カラー書き込み無しにするとだいぶ速くなる
    • 三角形の重心平面の計算、頂点属性の補間

cudaraster の各ステージついて

1024x768 固定
MSAA なし
アルファブレンドなし
デプステストあり

• 三角形の個数に影響うけすぎ
  • SAN MIGEL のトライアングルセットアップが重い
    • 他はだいたい Fine raster が一番重い
  • SAN MIGEL の三角形データがメモリ食い過ぎ
    • Bin raster 以降は三角形の ID(u32) しか持ってないからまだマシ

• カリングはバカにならない
  • 1px 未満の三角形を捨てるが予想以上にでかい

• いまいちスレッドを使いきれてない感がある
  • 三角形・フラグメント 32 個ごとにバッチ起動
  • Tri/tile と Frags/tile が 32 の倍数だと、100% 使い切れてることになる

（続く）