OpenCL version of AO bench

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 runContinue reading “OpenCL version of AO bench”

[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 punchesContinue reading “Statistics of Devastator”

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) VRay1.5SP2(eval), 1024×1024, 2×2 subsamples, VRayDirt. 200 secs. MR, 1024×1024, 2×2 subsamples, AO shader. 240 secs. VRayDirt, AO shader はそれぞれデフォルトのパラメータを利用しています. んー、3~4 分ですか、まあこんなものですかね. ただ、レンダリング時に両方のレンダラでディスクアクセスが発生しているので、 レンダリングそのものよりも、ディスクアクセスがネックになっている可能性があります. しかし、レンダリング速度よりもまず、3DS Max に Asian Dragon のデータを取り込むのが一番時間がかかったという… おまけContinue reading “Rendering performance: Asian dragon”

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% 以上と高いコードカバレッジを実現する. たとえばContinue reading “KLEE : Unassisted and Automatic Generation of High-Coverage Tests for Complex Systems Programs”

Ocelot : Binary translator for PTX.

(via gpupapers) 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 最適化などが行える. 気になる点 SPUContinue reading “Ocelot : Binary translator for PTX.”

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 もパストレのようなインコヒーレントレイの計算もアルゴリズムの改善で早くなっていて、 CoreContinue reading “VRay GPU”

HPG ‘09 photos

http://picasaweb.google.com/eric.haines/HPGAndSIGGRAPH2009 なにこれこんなにレンダラ野郎がいっぱいいるなんて!すごすぎて鼻血が出そう… くそー、やはり HPG に出席すべきだったか… しかし日本人がまったく映っていないのが、なんとも残念ですなぁ… # 単に撮影者が撮影していないだけかもしれませんが.