Syoyo Fujita's Blog

raytracing monte carlo

Month: August, 2009

OpenCL version of AO bench

aocl_cpu.png

kioku ported aobench into OpenCL on SnowLeopard(CPU version and GPU version)
I believe this is the first practical OpenCL application in the world 😉

http://kioku.sys-k.net/archives/2009/08/opencl_ao_bench.html

GPU version runs about 3x faster.
You may feel its not so fast, but remember that GPU version uses 9400M mobile GPU.
If you have desktop GPU, it may run much faster than CPU.

Okay, Aobench was ported to OpenCL.
Next will be smallpt or smallppm. Any challengers?

BTW, kioku find many (possible) bugs related to OpenCL driver and OpenCL compiler during the port of aobench into OpenCL. We’d like to share this information but we don’t now where is the good place to report it…

[Ja]

kioku さんが、AO bench を OpenCL に移植してくださいました. 仕事が早い.
実践的な OpenCL アプリとしては、世界発ではないでしょうか 😉

GPU 版は CPU の 3 倍程度ですが、これは GPU が 9400M とモバイルな GPU だからでしょうね.
GTX280 とかだともっと早くなると思います.

kioku さんの記事を読むかぎりでは、OpenCL ドライバやコンパイラはまだまだバグバグっぽいです.

kioku さんは、aobench の次のステップとして、 smallpt や smallppm の OpenCL 移植や、OpenCL で 4k demo に取り組んでいるそうです. 
(他に誰かチャレンジャーはいませんか!)

[Reminder] OOO 6th

OOO 第六回、明日 8/28(金) 17:00 となっています.

http://groups.google.co.jp/group/oooo_renderist/web/oooo–09

私のほうは、モーションブラー論文を解説しようと思いましたが、
分けあってレイトレの高速化に関しての論文(+実装)を取り上げることにします。

Statistics of Devastator

http://www.cgw.com/Publications/CGW/2009/Volume-32-Issue-7-July-2009-/Weighty-Matters.aspx

TF2 に登場した Devastator (砂漠で砂を吸い込むロボ)の統計がありました.

Devastator
Number of geometric pieces: 52,632
Total number of polygons: 11,716,127
Total length of all pieces: 73,090 feet or 13.84 miles
Gigabytes of textures: 32
Total textures: 6467
Devastator is as tall as a10-story building.
Laid out end to end, Devastator’s parts would be almost14 miles long.
When Devastator punches the pyramid, its hand is traveling at 390 miles per hour.

ポリゴン数の合計は 1,200 万ポリゴンですか.
Devastator は ILM 史上最も複雑なジオメトリとなったらしいですが、
それを考えると以外と少ない感じがしますね.
Asian Dragon が 720 万、Thai Statuette が 1,000 万ポリゴンですからね.
その代わり, テクスチャの枚数とサイズはそれなりに量がある感じです.

Rendering performance: Asian dragon

レンダラの速度の検証目的で、Asian dragon(720 万ポリゴン) を VRay と MR でレンダリングしてみました。

Max 2010 64bit, VRay 1.5SP3 の環境があるのですが、諸般の事情によりひとまずは
Max 2009 64bit, VRay 1.5SP2(Eval)での結果です.

machine: Vista64, 4GB mem, Core2 P9400(2.4GHz)

asiandragon1024_vray_240sec_thumb.png

VRay1.5SP2(eval), 1024×1024, 2×2 subsamples, VRayDirt.
200 secs.

asiandragon1024_mr_200sec_thumb.png

MR, 1024×1024, 2×2 subsamples, AO shader.
240 secs.

VRayDirt, AO shader はそれぞれデフォルトのパラメータを利用しています.

んー、3~4 分ですか、まあこんなものですかね.
ただ、レンダリング時に両方のレンダラでディスクアクセスが発生しているので、
レンダリングそのものよりも、ディスクアクセスがネックになっている可能性があります.

しかし、レンダリング速度よりもまず、3DS Max に Asian Dragon のデータを取り込むのが一番時間がかかったという…

おまけ

prman_cant_render.png
(PRMan can’t render Asian Dragon with AO shader because of memory shortage)

ついでに、 Asian dragon のデータを RIB に変換し、prman 14.3 で AO shader
(レイトレをオン)にしてレンダリング速度を測ろうとしましたが、
64bit linux, 6GB mem マシンでは、メモリを食いつぶしてレンダリングできませんでした.
(正確にはメモリ使用量が 100% に近くなりディスクスワップが多発して、4 時間くらいかけないと終わりそうにないのでやめた)

んー、prman, レイトレだとメモリ使いすぎだと思います。

ptlined() function signature differs from RI spec and RI impl.

RI spec と RenderMan 実装系では、ptlined() の引数が違います.

RI spec 3.2.


float ptlined ( point q, p1, p2 )

RMan implementations.


float ptlined(point p1, point p2, point q)

ついでに RI spec だと rotate() の返り値の型も違うんですよね.
きちんと仕様の方は、修正しておいてもらいたいところ.

[Raytracing BOF] G.I. Game Graphics | The rise of raytracing(2009)

Whitted の再帰的レイトレーシングの発案からちょうど 30 å¹´…
いま、レイトレーシングはリアルタイムで処理できるようになりつつあります.

表現が頭打ちになりつつあるラスタライズグラフィックスを置き換える新しい方法論として、
レイトレが(まだひっそりと?)注目されており、
レイトレがゲームグラフィックスやリアルタイムグラフィックスのあり方にパラダイムシフトをいままさに与えんとしています.

そこで、ちょうどゲーム開発者向けカンファレンスである CEDEC の期間に、
レイトレイノベーターの集まりを開くことにしました.

まあ世の中、レイトレ野郎はまだそんなに多くないと思うので、
(多いと先行者利益も薄まってしまいますしね 😉 )
10 数人規模で濃ゆく開催を予定しています.

詳細、および参加管理は以下をご参照ください.

G.I. Game Graphics | The rise of raytracing(2009)
9/3(木) 開催
http://atnd.org/events/1322

「これからのゲームグラフィックはレイトレだ!」
「え?リアルタイム REYES? 無い無い、あり得ない」
「レイトレエンジン開発で先行者利益ゲットだぜ!」

と思わんレイトレ野郎は、参加すると楽しめるのではないかと思います.

裏 CEDEC の二次会(分会?)相当として開催しますので、
裏 CEDEC のついでに参加もできるようにアレンジしてみました.

KLEE : Unassisted and Automatic Generation of High-Coverage Tests for Complex Systems Programs

KLEE は LLVM を使ったシンボリック実行ツール.

http://klee.llvm.org/

シンボリック実行とは?

シンボリック実行(Symbolic execution)とは、論文によれば以下のようなシステムだそう.

Instead of running code on manually- or randomly-constructed input,
they run it on symbolic input initially allowed to be “anything.”
They substitute program inputs with symbolic values and replace
corresponding concrete program operations with ones that manipulate symbolic values.

このシステムの使い道として論文が述べているのは主に二つ.
カバレッジツールと、自動バグ発見ツールである.

カバレッジツール

シンボリック実行を行うことにより、KLEE が自動生成するテストデータでは 90% 以上と高いコードカバレッジを実現する.
たとえば Coreutils に対するカバレッジテストでは、KLEE はわずか 89 時間をかけることで、
15 年以上手動で積み上げられてきたテストスイートを上回るカバレッジを達成している.

自動バグ発見ツール

KLEE はバグ発見ツールとしても利用でき、Coreutils に 15 年潜んできた致命的なバグを発見できたという.

まとめ

KLEE およびシンボリック実行アルゴリズム、なかなかよさそうですね.
レンダラの検証にも使えないかなと思います.
たとえばシーンファイルのパーサに適用とか.

ただ、ちゃんとレンダラアプリの内部までのカバレッジをあげるには、coreutils のようなある意味テキスト操作系の
アプリとはまた違った戦略が必要になりますので、KLEE そのままの適用では難しいでしょうね.
そこらへん、新しくロジックを提案できないかなぁと思います.

Ocelot : Binary translator for PTX.

(via gpupapers)

ocelotfigure.png

http://code.google.com/p/gpuocelot/

http://code.google.com/p/gpuocelot/wiki/References

(papers)

CUDA で使われている PTX(中間言語表現)の、バイナリトランスレータ.
名前は Ocelot.

PTX の時点で、プログラムは並列性を生かしたものになっているので、
要は PTX コードを変換するツールを書けば,
高級言語(CUDA)の段階からうまーく並列化されたコードが書けていろんなプラットフォームで動かせるぜ、という発想らしい。

PTX へのバイナリトランスレータを作ることで、

– PTX のスレッド階層はメニーコアにもマップ可能
– 変換のテクニックは、メモリレイテンシの隠蔽にも使うことができる。
– GPU データ構造を効率的にエミュレートしたり似たようなプロセッサにマップできる

なことを示している。
例として、PTX -> SPE(Cell) アセンブラへのバイナリトランスレータを作り、
うまくいったということを示している.

Binary Translator であることの利点

Ocelot は PTX のバイナリトランスレータでり、既存の MCUDA などの CUDA を CPU で動かすなどの手法と比べて以下の 2 点の利点があると述べている.

– スレッドの階層レベルをランタイム時に動的に割り当てることができる.
– 実行時情報を利用して、hot path 最適化などが行える.

気になる点

SPU に変換したときのパフォーマンスが書かれていないですね。
sin とか同期プリミティブなどの PTX(GPU) 専用の命令が SPU には無いので,
これを SPU ではエミュレートする必要があり命令長がそれなりに増えそう.
これがどれだけパフォーマンスに影響を与えるか気になります.

また、浮動小数点の演算精度が PTX(NV) と SPU では微妙に異なるので、
完全一致な結果を得られることができません。
ゲーム用などならいいかもしれませんが、
精度を求められる用途だとどうかなーという気がします。

gpuocelet

Ocelot は open source で公開されており、
LLVM IR をサポートするなど論文では取り上げてないものも含まれている.
将来的には、PTX から x86/LLVM/LRB/OpenCL などへのバイナリ変換ツールを目指しているようだ。

まとめ

中間言語に PTX を使っちゃう手法、なかなかいいんじゃないかと思います。
ユーザとしては CUDA プログラムをするか、CUDA コードを吐く DSL コンパイラを作ることで、いろいろなプロセッサで動く並列コードが書けるようになるわけですし。
CPU に出すことで、デバッグも楽になるんじゃないかな.

また、PTX -> OpenCL という方法も取れるわけで、既存のアプリの OpenCL 化にも使えそうです.
このとき、単にトランスレートするのではなく、動的実行してプロファイリングを取り、ターゲットプロセッサに最適な OpenCL コードを吐いたりとかできそう.
(OpenCL は中間言語の規定がないので、このような動的最適化をするのが難しい)

VRay GPU

VRay も GPU で RT ですか…

http://www.cgarchitect.com/news/SIGGRAPH-2009-CHAOS-GROUP-GPU.shtml

基本的には VRay RT(パストレ)を GPU に移植しただけっぽいです.
VRay RT(CPU 8cores)に比べて 20x くらいは出ているらしい.

GPU だと、コロッセアムシーンは、640×480 pixels, 2 k paths, 5 traces / fps で 5 fps くらいのパフォーマンスが出ているようですね.
これは M rays(Mega rays)にすればおよそ 50~60 M rays / sec と推測されます.

http://www.tml.tkk.fi/~timo/publications/aila2009hpg_paper.pdf

を見るかぎり、現状のハイエンド GPU で 60 M rays / sec は十分達成可能なのでありえる数値だと言えます.

まあ CPU もパストレのようなインコヒーレントレイの計算もアルゴリズムの改善で早くなっていて、
Core i7 で 1 core あたり 4 Mrays(1 レイ 1,000 サイクルほど)で求められるようになっています.

http://www.eng.uwaterloo.ca/~jtsakok/mbvhrs.pdf

この数値を当てはめると、4*8 = 32 MRays /sec と、GPU での 60 M rays /sec に比べて 1/2 くらいとなるので、
VRay RT(CPU 版)の実装が効率的ではないのかもしれません.

いずれにせよ、Vray GPU も、Brazil RT と同じように、レイトレは高速化されたとしても、シェーディングはどうするかという問題があります.
GPU で行なうということで、テクスチャマッピングやプログラマブルシェーダを使えますのでそれなりのことができるでしょうが、
任意のシェーダを動かすことは難しいでしょう.
今回のデモも比較的シェーディングが簡単な、envmap(skylight) IBL + parallel light 的なシェーディングとライティングしかしていないようです.
プロダクションレンダラの高速化(VRay 自体のアクセラレーション)に使うというよりは、
とりあえずはリアルタイムでのプレビズ用途でしょうかね(Vray RT も, VRay GPU もそのような目的だと思いますが)

HPG ‘09 photos

http://picasaweb.google.com/eric.haines/HPGAndSIGGRAPH2009

なにこれこんなにレンダラ野郎がいっぱいいるなんて!すごすぎて鼻血が出そう…
くそー、やはり HPG に出席すべきだったか…

しかし日本人がまったく映っていないのが、なんとも残念ですなぁ…
# 単に撮影者が撮影していないだけかもしれませんが.