High-Performance Software Rasterization on GPUs (4)

読むだけ読んで満足してたらブログに書いてないの思い出した。。

（続き）

ソフトウェアパイプラインのためのハードウェア

• ビューポートのサイズは 2048x2048 が限界だった
  • CTA あたりのキューの数が少なかった
  • 32bit の演算精度を確保するために、サブピクセル解像度をハードウェアの半分の 4bit に抑えた
  • 高解像度化のために、64bit 演算のサポートとサブピクセル解像度の確保が必要

• 頂点属性の補間能力が比べて特に弱い
  • ハードウェアでは、フラグメント処理の前に補間処理専用の回路で計算してる
  • ソフトウェアだと頂点フェッチが遅い
  • 補間専用の回路を使いつつ、プリフェッチに力を入れるのはおもしろいかも

• シェーダはもっと速く出来る
  • 処理対象のフラグメントを減らす
    • discard-heavy なシェーダ使うなら fine rasterizer の改良で対応できる
    • 微小三角形を削るアイディアはすごくうまくいった

• ピクセルカバレッジの計算はだいぶ速くできた
  • ハードウェアと比べて命令数が 40% ぐらい少ない
    • ハードウェアのパイプラインに組み込めば全体で 3-7% ぐらい速くできそう
  • カバレッジマスクのビット検索はわりと簡単に最適化できる
    • カスタム命令を組めば 2-4% ぐらい速くできそう

• メモリアクセスはやっぱしんどい
  • shared memory 上でのアトミック演算が遅かった
    • キューの read/write 速度に効いてくる
    • producer-consumer モデル用のキューをハードウェア実装できたらすごい速くできそう
    • けどそれ超難しい

• ROP はいまのハードウェア実装でいいかも
  • ソフトウェアのと比べて 80% ぐらい速い
    • けど現状のブレンド関数のしょぼさを考えると、放置していい問題じゃない

以上。"Future Work" についてはここでは省略。

なんか、あれだ。ソフトウェア実装も案外すごいんだな。。細々と面倒な処理は当然多いけど、ソースコード自体も思ったよりシンプルだったし。それにしても 1px 未満の三角形を削るとか、そういうのはハードウェアでもやってるのかと思ってたんだけど、そうでもないのかな。そんな複雑なことできない？ いずれにせよそこでソフトウェアがそんなに使えるとは思ってなかったかも。
個人的には full programmable pipeline って一度やってみたいんだけど、まぁ、コンソールに落ちてくるのは何年後になることやらｗ こんど PRMan あたりさわってみようかな。