Syoyo Fujita's Blog

raytracing monte carlo

Month: April, 2005

gcc 4.0 で lucille のコンパイル不都合

Tiger では開発ツールをインストールすると標準で gcc 4.0 のコンパイラがインストールされます。

で、gcc 4.0 で lucille をコンパイルしてみたのですが、最適化が有効になっていると、
コンパイルは通るのですが、結果の画像が真っ白、という結果となりました。

colinux に gcc 4.0 をコンパイルしてインストールして、同じように lucille をコンパイルしても
同じ結果となりました。

いくつか手探りでまずそうなコードをあたってみたところ、ひとつ原因がみつかりました。

flipcode に載っていた、逆平方根を求めるコードです。

 

float fastrsqrt(float number) {
        long i;
        float x2, y;
        const float threehalfs = 1.5f;

        x2 = (number) * 0.5f;
        y  = (number);
        i  = *(long *)&y;
        i  = 0x5f3759df - (i << 1);
        y  = *(float *)&i;
        y  = y * (threehalfs - (x2 * y * y));

        return y;
}

-O2 などの最適化オプションをつけると、なぜか間違った値が出力されてしまいます。
-Wall をつけると、コンパイル時に

warning: dereferencing type-punned pointer will break strict-aliasing rules

という警告を出すので(これがどういう意味なのかよく理解できていませんが、
無理やり違う型同士を変換すると出るみたい…)、
これが原因でしょうか。

まあもともと私も意味があまりわからないようなトリッキーなコードですので、
いつコンパイルが通らなくなってもおかしくはないコードではあります。

あまり高速化を求めてへんてこりんなコードを書くよりは、
安全で素直なコードを使ったほうがのちのち問題なさそうですね。

ほかにも lucille には gcc 4.0 ではうまく通らない(そもそも C 言語の仕様から外れているコード?)
コードがあるでしょうから、しばらくは gcc 4.0 用にコードの見直しです。

ちなみに、上記のコードは、union を使って以下のように対処すれば動きました。

float fastrsqrt(float number) {
        long i;
        float x2, y;
        const float threehalfs = 1.5f;
        union {
                long l;
                float f;
        } data32;
        x2 = (number) * 0.5f;
        y  = (number);
        data32.f = y;
        //i  = *(long *)&y;
        i = data32.l;
        i  = 0x5f3759df - (i << 1);
        data32.l = i;
        //y  = *(float *)&i;
        y = data32.f;
        y  = y * (threehalfs - (x2 * y * y));

        return y;
}

GLSL supported on Tiger

Tiger にアップグレードしました。

残念ながら、Mobility Radeon 9600 用のハードウェアドライバでは GLSL はサポートされていなかったものの、
ソフトウェアドライバには GL_ARB_shading_language_100 の文字がッ!
(GeForce 系や、より上位の Radeon でもまだ GLSL はサポートされていないのかな?)

それに伴い、 OpenGL Shader Builder にも、
アセンブラによる ARB vertex/fragmen program に加えて、
利用するシェーダの選択肢に
OpenGL Shading Language が追加されています。

もちろん GLSL を使った場合、プレビューはソフトウェアドライバでないと
表示されませんが、インタラクティブに結果が出るので、
これは GLSL のシェーダを書く上で便利なソフトウェア
となるでしょう。

それにしても、GLSL の派生言語を利用した CoreImage は Mobility Radeon 9600 で
ハードウェアアクセラレートされて動くのに、OpenGL ドライバでは GLSL はまだ、
というのは、GLSL よりも CoreImage 用の言語のほうがハードウェアリソースへの
要求が少ないからなのでしょうかね。

○○○は○○○○読んでませんから!!!

いままで一冊でしたが、今日から雑誌を新たに読むことにしました。
水曜日は二冊定期購読です。

Lpics: a Hybrid Hardware-Accelerated Relighting Engine for Computer Cinematography

Pixar の前編 photon map 使用らしいと噂されている
新作映画 Cars で使われたであろうリライティングの手法に関する論文が 
SIGGRAPH 2005 に採択されています。

Lpics: a Hybrid Hardware-Accelerated Relighting Engine for
Computer Cinematography
F. Pellacini, K. Vidimce, A.
Lefohn, A. Mohr, M. Leone, J. Warren
SIGGRAPH 2005
http://www.graphics.cornell.edu/~fabio/publications.html

Pellacini 氏は、さらに自動シェーダ簡略化の論文も SIGGRAPH 2005 に通していますね。すごいなぁ。
(ていうか SIGGRAPH 2002 では三本の論文に名を連ねていたのか…)

論文はまだ公開されていませんが、web の画像をみると
2000 秒かかる処理が 0.1 秒でできるような手法らしい。
(2 万倍の高速化…)

プロダクションレベルのリライティング、リレンダリングの手法については、
OpenGL を使ったリライティングエンジンの提案が昔にありました。

A Fast Relighting Engine for Interactive Cinematic Lighting
Design

Reid Gershbein and Pat Hanrahan, SIGGRAPH 2000. 
http://graphics.stanford.edu/papers/fastlight/

Lpics はこれに間接照明 + 最近のプログラマブル GPU のエッセンスを加えて拡張した
手法になるのでしょうか。

PhotoRealistic RenderMan(prman) にはすでに Irma というリレンダラがあります。
将来の prman にはこの Lpics が組み込まれるようになるのかな。

SIGGRAPH 2005 論文全リスト?

Tim Rowley 先生のページで、本家よりも早く SIGGRAPH 2005 採択論文のリストが公開されたようです。

http://www.cs.brown.edu/~tor/sig2005.html

数えてみましたら、100 編近くありました(Proceedings ではなく、 Transaction on Graphics
のみ採録も含むのかな?)。

今年はレンダリング関連の論文が多く見られます。豊作ですね。
しかもタイトルからだけですが、おもしろそうなものがいっぱいです。

こんかい新規に追加されたもので、いくつか例を挙げると、

Wavelet Importance Sampling:
Efficiently Evaluating Products of Complex
Functions

Precomputed Local Radiance
Transfer for Real-Time Lighting Design
Compressing
and Companding High Dynamic Range Images With Multiscale Wavelet
Architectures
Multi-Level Ray Tracing
Algorithm

Local, Deformable Precomputed Radiance
Transfer (Peter Pike Sloan. ついに変形可能かつ局所的照明のあつかえる
PRT?)

Modeling and Rendering of
Quasi-Homogeneous Materials
Precomputed Shadow Fields for Dynamic Scenes
RPU: A Programmable Ray Processing
Unit for Realtime Ray Tracing(
Saarland
University
,
SaarCor の後継のレイトレチップ、うぉぉぉぉ、ついに一般家庭への RPU
の登場か!?)

Wavelet Noise(どんなノイズだ!?)
Light Diffusion in Multi-Layered
Translucent Materials (Henrik Wann Jensen.
多層のサブサーフェススキャタリングモデル?)

Performance Relighting
and Reflectance Transformation With Time-Multiplexed
Illumination(どっちかというとビジョン系?)Capturing and Rendering
Time-Varying Participating Media(Debevec,
時間変化する関与媒質のキャプチャとレンダリング)
User-Configurable Automatic
Shader Simplification(シェーダ簡略化、オフラインかオンラインかどっちだ?)
Far Voxels: A Multiresolution Framework for Interactive Rendering
of Huge Complex 3D Models on Commodity Graphics
Platforms 
Unbiased Energy Redistribution Path
Tracing(やべえッ、バイアスなしパストレ!!。もともとバイアスなしだけどね)
A Frequency Analysis of Light
Transport(純粋大域照明理論っぽい)
Fourier Slice
Photography
(Ren Ng. ライトフィールドから任意の DoF
を作り出すっぽい)

チョーシュゴーな空間充填曲線?

うーむ、いま考えているものがチョーシュゴーな空間充填曲線に成り得るかもしれません….

それゆえ、ヒルベルト曲線順ラスタライザよりもおもしろそうなものができるやも。

がんばって数学的にもきちんと証明をつけて、論文レベルにまで昇華させてみたいですね。

A Relational Debugging Engine for the Graphics Pipeline

A Relational Debugging Engine for the Graphics
Pipeline
to appear, SIGGRAPH 2005
http://duca.acm.jhu.edu/research.php

今年の SIGGRAPH 2005 採択論文。グラフィックスパイプライン(つまりは CG の描画、ひいては GPU)、

に対するデバッグ手法の提案です。なかなかあるようであまり提案のなかった分野です。

デバッグ手法には、クエリベース(SQL)のデータベース的な方法論を用いています。 

たとえば論文での例を挙げると、

SELECT normal:37 FROM SFrags
WHERE dot(normal:37, (0,0,1)) < 0

という操作で、フラグメントシェーダの 37 行目において、
法線とベクトル (0, 0, 1) との内積がゼロより小さいものを選択、ということができます。

lucille を開発するときも、”良い” デバッグのしかたにはいつも悩まされました。

CPU のデバッグとは違い、レンダリング処理は必ずしもシーケンシャルにコードの
実行が行われることはありません。
たとえばあるピクセルだけでさらなるレイトレの処理が
トリガーされたり、ある領域のピクセルで、ある法線方向だけ向いてる部分の情報を
調べたいなどという要求は常にあります。

本質的に GPU のデバッグは並列プログラムのデバッグということになるかと思います。

CPU における並列プログラムのデバッグ方法はそれなりに確立しつつあるようですが、
グラフィックスパイプラインのデバッグというのは、よくて頂点シェーダとフラグメントシェーダの
パフォーマンスや帯域程度しか調べられなかったのではないでしょうか。

グラフィックスパイプラインでは、ラスタライザには 3 頂点が渡され、これが 1 つの
ポリゴンの情報となり、ポリゴンがラスタライズされて膨大な数のフラグメント(ピクセル)
が生成されます。このようなデータの流れからして、すでに複雑な並列度を
持っており、通常の CPU における並列プログラムのデバッグ方法をそのまま適用するのが
難しいと思います。

Mac OS X では、OpenGL の関数にブレークポイントを仕掛けたり、実際に OpenGL の
関数にどの値が渡されたか(たとえば引数が変数になっている場合がこれに相当)、
などを調べることができますが、たとえばある位置 (x, y) の法線の値などを
調べたりはできません(そういうフラグメントシェーダを書くという手もある)。

本論文では、OpenGL の API にフックをかけて、
グラフィックスステートのストリームを取り出す仕組みになっています。
このため、ユーザから見ると、再コンパイルすることなくアプリケーションを
デバッグすることが可能になっています。

このような背景において、本論文のデバッグ手法の提案は、これからの
シェーダリッチな GPU の利用用途においてきわめて有益であると思います。
(問題はデバッグすべきデータのストリームが膨大になりそうなので、
それの対処をどうするかになるか、でしょうか)

 

Mac OS X Tiger

Mac OS X Tiger が発表され、 4 月 29 日に発売となります。

http://www.apple.com/jp/

GLSL on Mac OS X ?

ついに Mac OS X 上での OpenGL 2.0 + GLSL
のサポートかッ!?
すくなくとも Core Image では GLSL の派生言語が用いられますので、
GLSL が実装されている可能性が十分に考えられます。

これで安心して GLSL まで対応した OpenGL プログラムを
クロスプラットフォームで作成していけますね。

GPU を作る側になってわかったのですが、ホント DirectX の設計思想と仕様はアホです。
(Fahrenheit 以降 GL の設計思想を取り入れ、Shader Model 3.0 の機能を取り入れた今でも)

まあこういうと、ひいては DirectX の思想と設計に寄与した Jim Blinn 大先生の批判となって
しまうのかもしれないのですが、実際そう言わざるを得ないかもしれません…
重箱の隅をつつくようなことをするとぼろぼろと欠陥が….

だからといって OpenGL が良い、とは言いませんが、DirectX がアホすぎる以上、
このような観点からでも OpenGL or OpenGL|ES を使うことをお勧めします。
 

gcc 4.0

もうひとつの目玉は、自動ベクトル化に対応した gcc 4.0 です。
これで altivec 専用のコードを書くことなく、自動でコンパイラが
altivec に対応したコードを(もちろんコンパイラが対応できる範囲で)吐いてくれます。

ちなみに、profile based optimization もサポートされています。
この機能は、実際にコードを実行してホットスポットを探し出し、
その部分に最適化を施してもう一度コンパイルしなおすというものです。

レンダラではある部分に集中してコードの実行が行われることが多いので、
この最適化機能の恩恵に与れるのではないでしょうか

これは現在の Panther に付属の gcc 3.3 でもすでにサポートされていますが、
さらなる機能の改善が期待できます。
(gcc 3.3 で lucille のコンパイルで試したところ、1 %
程度の高速化にしかなりませんでした…)

 

Graphics Interface 2005 papers

SIGGRAPH 2005 の論文が公開されはじめていますが、
Graphics Interface 2005 でもおもしろそうな論文が採択されています。
abstract までしか読んでいませんが、少し紹介したいと思います。

A Computational Approach to Simulate
Subsurface Light Diffusion in Arbitrarily Shaped
Objects

Tom Haber, Tom Mertens, Philippe Bekaert, Frank Van Reeth, to
appear in Proceedings of Graphics Interface 2005
http://research.edm.luc.ac.be/~tmertens/

不均質な媒体(まだらに透過度が変わるなど)にも対応した、
サブサーフェススキャタリングのレンダリング手法です。
計算はオクツリーのような階層グリッドをベースとしているようです。
既存の手法にくらべても高速らしい。ただしオフライン向けです。

Reordering for Cache Conscious Photon
Mapping. Joshua Steinhurst, Greg Coombe, Anselmo
Lastra.  Graphics Interface 2005.
http://www.cs.unc.edu/~pxfl/argh/pubs/

最近はキャッシュネタに興味があるので、この論文も興味深そうです。
新しいキャッシュ機構をフォトンの kNN 探索に適用することで、
メモリアクセス(?)の帯域を最大 1/1000 にする手法らしいです。
レンダリングの高速化に寄与しそうです。

 

それにしても、最近は論文を読んで理解するチカラが低下している気がします。
一日一論文というペースを守らなかったのが原因でしょうか。
(これから夏くらいまではペースは守れそうです)

まあ一日一論文でも、あまり早く読むだけでは頭に残らないので、
本来であればじっくり読むべきなのでしょうが…
しかしグラフィックス関連の論文だけでも毎年 300 本以上が発表されていますので、
一日一本の速さで読んでも実は間に合わないのですよね…
昔に発表された論文もありますし… グラフィックスの歴史を 30 年としても 9000 編…

SBR 2005 開催

そろそろ SIGGRAPH 2005 採択論文が出始めてきましたので、
SBR 2005(SIGGRAPH ronBun implementation Race 2005, SIGGRAPH
論文実装レース)、
開催(正確にはセカンドステージ再開)です!

超極秘ルートからの情報によると、
今年はなんと早くも、去年の SBR 2004 出走者の中から
SIGGRAPH 2005 に論文が採択された人が出た模様(現在写真判定中)です。

http://lucille.atso-net.jp/sbr2005

 

とりあえずこちらにも現時点での採択論文(conditioally accepted 含む)のリストを載せます。

現時点では A Practical Analytic Single Scattering Model for Real Time
Rendering に注目しています。はやく PDF 公開されないかなー。An Approximate Image-Space
Approach for Interactive Refraction はある意味もっとも SIGGRAPH
っぽいと言えるかもしれません。
 
また日本人では、向井先生の論文が採択されています。空間統計学を応用したモーション補間法とのことです。

Sung-Eui Yoon, Peter Lindstrom, Valerio Pascucci, and Dinesh
Manocha,
“Cache Coherent Mesh Layouts”, To appear on ACM
SIGGRAPH (Transactions on Graphics) 2005
http://research.microsoft.com/~awilson/

Zordan, V. B., Chiu, B., Majkowska, A., Fast, M.,
Dynamic Response for Motion Capture
Animation
,
http://www.cs.ucr.edu/rgl/rglRes.html

Ju T., Schaefer S. and Warren J.
Mean Value Coordinates for Closed Triangular
Meshes

http://www.cs.rice.edu/~sschaefe/research/

Tomohiko Mukai, Shigeru Kuriyama
“Geostatistical Motion
Interpolation”

http://www.vcl.ics.tut.ac.jp/mukai

Bo Sun, Ravi Ramamoorthi, Srinivasa Narasimhan and Shree
Nayar
A Practical Analytic Single Scattering Model for Real Time
Rendering

http://www.cs.columbia.edu/~bosun/
http://www.cs.columbia.edu/~bosun/sig05.htm

Chris Wyman
An Approximate Image-Space Approach for Interactive
Refraction

http://www.cs.uiowa.edu/~cwyman/publications/

CMU からの 6 本の論文まとめて。
http://graphics.cs.cmu.edu/