HPC 産業の未来とレイトレ

事業仕分けにより、次世代スパコン事業が予算削減されましたね. まあなんとなーく、私としても 1000 億もなんで必要? と思っていたので、しかるべき結果になったという感じでしょうか. とまあ現状の感想を述べても面白くないので、今後の HPC はこうなる!みたいな話でもしてみたいと思います. 結果だけまず言うと、HPC の未来は、リアルタイムレイトレがキラーアプリとなるでしょう. HPC の活用を広げていかなければならない HPC インサイダーで、HPC の未来を考えているひとと話す機会を最近得ることがあったのですが、 やはり彼らインサイダーも、 「N 体とかタンパク質解析とか、もちろんそれはそれで大切であるが、 やはり HPC を活用していくにはそれでは足りない。もっと皆のためになり役立つものをどんどんとやっていかなければならない. なので syoyo 君、HPC を使ったリアルタイムレイトレには期待している (最後の行は意訳)」 と言っておられました. 今回の予算削減は、このようなキラーアプリを提案できなかったことによる理由も多かったのではないでしょうか. HPC ハードのコモディティ化 CPU はもう x86 でコモディティ化しています. 最近は NVIDIA が HPC 路線へと経営の舵を大きく切り、Fermi によるパーソナル HPC チップを市場に投入しようとしており、 新規プレイヤーの参入により HPC の市場の商業化をさらに押し進めています. (もちろん、Intel Larrabee の存在もあります) いままで、 専用 CPU + 専用アクセラレータか、 汎用 CPUContinue reading “HPC 産業の未来とレイトレ”

What will happen if realtime raytracing runs on 1P flops computer?

ねんがんの 1P flops コンピュータを てにいれたぞ ひょんなことから? 1P(ペタ) flops 級の計算機環境を使わせていただけることになりました. ありがたいことです. 1P flops でリアルタイムレイトレ、リアルタイム G.I. をやったら、どれくらいすごい映像が作れるだろう? 1P flops で lucille のレンダリングをやったら、どれくらい高速にレンダリングできるだろう? いろいろ妄想は膨らみます… が、やるなら「こんなレイトレ、はじめて…」みたいな成果を出すことが期待されるので、プレッシャーも同時に感じます. # 今回も思いましたが、そろそろ本気で、今後の爆発的な(リアルタイム)レイトレ技術者の需要を # どう解決していくかというのを考えないと感じています. # レイトレ教育を行い、レイトレ雇用を生み出し、レイトレ報酬を支払い、レイトレ経済圏をどう確立していくか…. 難しい問題ですね.

Fermi has over 1T DP Flops?

http://www.nvidia.com/object/fermi_architecture.html – 1/2 speed double precision – IEEE754-2008 compliant – 1T DP flops or more? これも、「おお、ブラボー!」な感じですね. 特に NV のほうは ATI よりも HPC 用途を重視している感じがします. 倍精度が単精度の 1/2 で出来ますし. 正確な数字は出ていませんが、 Radeon と比較して推測する感じでは、1T DP flops くらいになるんじゃないかと思っています. オフラインレイトレも GPU(や LRB などのアクセラレータ)で高品質を保ったまま、 高速化させることも実務的に出来てきそうです. OpenCL などの GPU を叩く API や言語の標準化もすすんでいますしね. このような形のレンダラが本格的に出てくるなら、ソフトウェアの対応とハードが普及してくる 2010 年あたりでしょうか. ただ、Fermi の発表と同時に iray も発表していますが、 iray は、VRay RT などの他製品もそうですが、 全部プレビュー用な感じでしか使えなさそうなのが残念です.Continue reading “Fermi has over 1T DP Flops?”

Radeon HD 5870 has 544 DP GFlops

(via twitter) http://pc.watch.impress.co.jp/img/pcw/docs/317/309/html/kaigai12.jpg.html – double 精度で 544 Gflops(およそ  Core i7 の 10 倍) – IEEE754-2008 互換 Spec を見る限りでは、「おぉ、ブラボー!」 GPGPU による、lucille のようなオフラインレイトレレンダラのアクセラレーションに本格的に使えそうです. CPU での演算と比べて GPU で計算させても double 精度でも誤差が発生せず、 (double 精度でもきちんと IEEE754 互換であれば) かつ CPU の 10 倍ほどの(理論ピークでの比較ですが)浮動小数点パフォーマンスがあるわけですから、 オフラインレンダラのような精度が求められつつも高速化したいというアプリに向いていると思います. shared memory も GeForce より多いサイズを積んでいるようなので, たとえば CUDA ベースのレイトレカーネルも Radeon HD 5870 で問題なく動きそう. ただ、ATI はどちからというと既存グラフィックス性能重視、NV は汎用演算重視らしいので、 CUDA レイトレのように比較的分岐やランダムアクセスが多いカーネルは、 もしかしたら RadeonContinue reading “Radeon HD 5870 has 544 DP GFlops”

World’s first SIMD ray-triangle intersection with ARM/NEON

I’ve wrote possibly world’s first SIMD ray-triangle intersection code with ARM/NEON instruction. The code runs finely on iPod touch 3G(ARM Cortex) and iPhone 3GS. The performance on iPod touch 3G is around 348 cycles per isect4(). # of assembly instruction of isect4() is around 140, thus the CPI = 348/140 = 2.48, which is notContinue reading “World’s first SIMD ray-triangle intersection with ARM/NEON”

[Google groups] SIMD-cafe for SIMD lovers

なぜ SIMD が重要か プロセッサのクロック数は頭打ち… マルチコア化ではコアが増えるたびにコア間の通信がネックになる問題がある. 専用プロセッサを作るにも, 固定したアルゴリズム&量が出ないとビジネスにならないので, やはり CPU 的にソフトなプロセッサが求められる. 一方で、エコ時代であるので省電力が求められる. そんな HW の制約の中で、SW(アプリ)は富豪的プログラミングで HW の向上に頼るだけでは対応しきれなくなってきています. 特に認識処理、グラフィックス、データベース処理でパフォーマンスを出していくことが求められている. このような、現在のプロセッサ(半導体)の技術的壁やプロセッサデザインの収益モデル(ビジネスモデル)を考えると、 特に SIMD 演算器とその活用が重要になってきます. 実際, x86/AVX(wider SIMD), iPhone 3GS(ARM/NEON), Atom/SSE が登場してきています. アプリを SIMD 最適化する必要性は今後また重要になってくるでしょう. (SIMD 最適化の最初のブームは、 MMX/SSE/SSE2 の出てきた 2000 年頃でしょうか) しかし、どんなにコンパイラが賢くても、効率的な SIMD コードを自動で吐いてくれるのはまだまだ難しい. そこで、プログラマがいかにアルゴリズムを SIMD フレンドリーにするか、 SIMD 演算器をいかにまく使ってプログラムを最適化していくかが、 今また大きく求められている、そんな気がしています. また、ときどき SIMD 野郎と話すことがあるのですが、 結構みんな「ほかに SIMD のことを濃く話すことができるひとが居なくて…」 と言われることもあり, SIMD 野郎のための googleContinue reading “[Google groups] SIMD-cafe for SIMD lovers”

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”

RtInt and RtFloat have enough precision there days?

RenderMan の仕様では、整数データは RtInt, 浮動小数点データは RtFloat で表現され、これらはそれぞれ C 言語でいう int, float に対応しています. もちろん、RtInt, RtFloat は define されているものなので、 long, double に変えることもできなくは無いのですが、 RIB や DSO などの既存アプリなどとの互換性を考えると 一旦定義してある型を変えることは非常に困難です. で、int(32bit 整数), float(32bit 浮動小数点)ってそろそろ限界じゃね?ってお話. まず、RtInt を考えてみましょう. RtInt はたとえばポリゴンの定義において頂点インデックスの定義などに使われます. RtInt の場合、2^31 の頂点インデックス数が表現の限界になります. この数字により表現できるのは、およそ 700 万ポリゴンほどになります. 現在の CG 表現の複雑性を考えると、Polygons, PointsPolygons で表現できる 1 プリミティブのポリゴン数の限界が 700 万ポリゴンというのは、 そろそろまずいんじゃないか?と思います.もってあと 2, 3 年かな. まあ Polygon の定義を二回のコールに分けて対応とかできなくはないですが、 そのような処理をエクスポータなどに書くのは面倒くさいですよね.Continue reading “RtInt and RtFloat have enough precision there days?”

Good introduction and history on Numerical Computation with Guaranteed Accuracy

http://w2.gakkai-web.net/gakkai/ieice/vol6pdf/vol6_09.pdf  This is a must see material on numerical computation. The document describes a history of Prof. Oishi’s research on numerical computation with guaranteed accuracy. Prof. Oishi is well known researcher on Numerical Computation with Guaranteed Accuracy(GA is based on interval arithmetic and it includes error free computation, faithful computation, etc) Theory of GuaranttedContinue reading “Good introduction and history on Numerical Computation with Guaranteed Accuracy”

iPhone 3G = 4.8 GFlops?

genki さんと一緒に, iPhone や iPod touch に載っている ARM プロセッサの VFP(ベクトル浮動小数点ユニット) について調べていました. とりあえず現時点で理解したこと. VFP は一度に演算するベクトル長を指定できる. 浮動小数点ステータスレジスタの LEN ビットにベクトル長を書き込むことで、 FP 命令 (fmuls など)はそのベクトル長ぶんの演算を一度に行うという、ちょっと変態なアーキになっている. 通常の FPU としての利用だと、ベクトル長 = 1 ということ. ベクトル長は単精度だと最大 8 個、倍精度だと 4 個まで設定できる. ただし、ベクトル長ぶんのレジスタバンク(レジスタペア)を消費する. 単精度だと全部で 32 レジスタ(s0 ~ s31)、倍精度だと 16 レジスタ(d0 ~ d16)あるけど、 たとえばベクトル長 4 なら、各命令のオペランドは [s8, s11] などという風に 4 個レジスタを消費する. つまり、こんな感じの動作モデルになる. # ベクトル長  = 1 の場合: fmulsContinue reading “iPhone 3G = 4.8 GFlops?”