AMD OpenCL(x86) v.s. MUDA

Recently, AMD released OpenCL drivers which runs on x86 CPU. I think it’d be better idea to measure performance of Black-Scholes compuation on AMD’s OpenCL(x86) and MUDA(SSE x86). Both was run on 1.86 GHz Core2 Linux 32bit. AMD’s OpenCL(x86) Option samples Time taken(sec) Options / sec 10240000 4.497 2.27707e+06 AMD’s OpenCL results in 2.3 MContinue reading “AMD OpenCL(x86) v.s. MUDA”

Brazil RT

(via private communication) Caustic Graphics に買収された SplutterFish の Brazil が Vray RT のようにリアルタイムになりました. http://caustic.com/gallery_images.php おお! DOF なティーポットが 5 fps でレンダリング出来んの!? マジで! と思って以下のプレゼンビデオを見たら… http://area.autodesk.com/inhouse/videos/siggraph_2009_autodesk_design_visualization_part3 … 単なるプログレッシブレンダリングじゃねーか! プログレッシブで 5fp というこですか!? しかもこれくらいなら今の CPU でも実現できるし… とはいえ、現状はこれが FPGA ベースのチップで動いているもので、製品版では 10 倍になるなら、 まあプレビュー用にはちょっとはアリかなぁと思っています. レイトレチップの可能性 さて、このようなレイトレを専用チップで行うソリューション、 一見レイトレがすっげー速くなりそうですごそーに見えて、実は非常にクリティカルな問題を含んでいます. それは、IO がボトルネックになるということ. このボードはレイトレだけをアクセラレートするらしいので、動作としては、 レイトレをチップで行いその結果を CPU に持ってきてシェーディング、GPU に結果を転送して表示するということになります. ここで、特に複雑なシェーディングをしようとすると、レイトレチップと CPU とのデータの移動が増えてそこがネックになり、複雑なシェーディングが困難になると思われます. また、大規模シーンやディスプレイスメントなどをかけるときも、レイトレチップ側のメモリにシーンが入りきらないときにどうするか?. Out-of-core で処理してもいいが、そこでやはり IO が問題になる. まー、もちろんプログラマの腕次第である程度Continue reading “Brazil RT”

approximate double precision division using SSE2

SSE 命令には rcppd なる、double の逆数を近似で求める命令はありません(少なくとも SSE4 までには). float の場合には rcpps 命令が存在し、これは 1.0 / a の近似を高速に求めることができます. なぜ rcppd が無いのか? rcp では、内部では除算テーブルを引くだけの実装になっているようです. そして、実際のところ、逆数を求めるにはそれほど大きなテーブルが必要無いことが知られています. (詳細は「ディジタル数値演算回路の実用設計」あたりを参照してください) なのできっと、double 用にテーブルを用意するよりも、 「一旦 double を float に変換してから rcp を呼び、その結果をまた float から double に変換すればいいんじゃね?」 という考えなのかもしれません. 実際 rcppd2ps, rcpps などで検索したら、上記を行うなんともビンゴなコードが! http://yoffy.dyndns.org/trac/yofcpp/changeset/518/trunk/yoffy/simd_type/sse2_double2.hpp Newton 法込みで、44bits ほどの精度だそう. というわけで、これをベースにして、divpd と cvt/rcpps + Newton 法の比較をとってみました. ベンチマークソースコードはこちら. http://gist.github.com/163957 Core2(Merom) 2.16GHz の結果では以下のようになりました. Macintosh-3:Continue reading “approximate double precision division using SSE2”

[RSL] specular() is implementation-dependent

RSL の specular() が、実装依存であることが分かりました. RI spec に載っている specular() の式と、prman などで使われている specular() の内部実装の式がなんと異なる! Advanced RenderMan にもそんな注意文がかかれていました. さすが RenderMan, 見事なダブルスタンダード?ですね. aqsis のソースを見ると、RI spec の式で、1.0 / roughness のところを 1.0 / (roughness / 8) とすると prman の式と近くなるようです. lucille はそのようなレガシー(?)なあやふやさまで再現する気はないので, specular() は RI Spec 通りにして、prman のふるまいをエミュレートするのは別関数化したいなぁと思っています. ま、一番いいのは specular() は使わずに、独自できちっと反射モデルや BRDF 式をシェーダ内でコーディングすることですかね.

LLL(Lucille Light transport Language) idea proposal

レンダラ神から、以下のように啓示をうけました. SYOYO君には、言語的に不完全なrenderManのSLや、OSLなどではなく、言語的に奇麗で 完成された物を期待してます。そのついでにrenderMan SLやOSLもサポートしてますってくらい が良いかと。 うぉおおおおおおおおお おおおおおおおおおおお おおおおおおおおおおお おおおおおおおおおおお! さすがレンダラ神!なんでもお見透しである! 言語的に奇麗で完成されたシェーダ言語がやはりこれから求められている! そして OSL や MetaSL がそのようなものになるとは言えないだろう! そこで、言語的に美しく完成された次世代シェーダ言語、 Lucille Light transport Language(LLL)の提唱ですね!分かります! LLL とは? とはいえ、まだそれほど LLL についての具体的な案はありません. 漠然とこんな感じかなぁと思っています. – Composable(ノードベース GUI との親和性が高いように) – 関数型的な言語仕様 – Python 的な良さを入れてみたり(インデントが重要とか) – サンプリングとシェーディングを切り分ける — サンプリングもシェーダに入っていると、bidirectional sampling とかが非常にやりずらい. サンプリングの手続きは別で記述できるようにしたらいいのではないか? ここらへん、いろいろなシェーダ野郎と議論して定義していきたいなぁと思って思います. とはいえ、世界でみてもこんな話題ができるシェーダ野郎(言語設計とコンパイラが書けるシェーダ野郎)は一握りなのですけどね 🙂 彼らをいかに引き込めるかがカギとなるんじゃないかなぁと思っています.

OOOO 第六回 : 09 年レンダリング論文レビュー

(URL がへんな文字列を含んでいるので、ブラウザによっては表示が崩れています. ご了承ください) 久しぶりの開催となりますが、OOOO やります (OOOO = オフラインレンダラ野郎のためのオフラインレンダリングについて議論するオフライン会) 2009 年 8 月 28 日(金) OOOO 第六回 : 09 年レンダリング論文レビュー 今回は、都合により平日金曜日の開催となります. SIGGRAPH 帰国組が参加できるようでしたら、SIGGRAPH レポートなどもしてもらう予定でいます (残念ながら私は参加しません)