Syoyo Fujita's Blog

raytracing monte carlo

Category: misc

[Recent news&events]

There’s no news&events

AMD OpenCL beta4 doesn’t run on PC with non-ATI GPU.

ATI StreamSDK 2.0 beta4 がリリースされ、OpenCL が GPU 対応したのですが、
残念なことに今回から OpenCL カーネルを CPU で動かす場合でも ATI のドライバが必要になるらしく、
ATI の GPU が載っていない PC では、CPU 版の OpenCL カーネルを動かすことができなくなりました.
(Vista64 で確認)

OpenCL 対応アプリはビルドできるのですが、実行時に aticalcl.dll という、
ATI のドライバに由来している感じの DLL が無いというエラーが出てしまうようになります.

Note PC のように、GPU を交換できない、でも CPU でとりあえず走らせたいという状況では、ちょっとこれは致命的ですね.
まあ「AMD の」OpenCL ドライバなので、実行環境は AMD 縛りという強制が入ってもいいのですが、
以前の beta ではフツーに CPU モードで動いたので、ちょっと残念です.

py3dsmax

3DS Max には、残念ながら現時点(2010)では python が使えません.
なんとか python で 3DS Max オペレーションの生産性を向上できないかと探したところ,
blur が 3ds max 上に python 環境をのせるための Python プラグイン拡張 py3dsmax を見つけました.

http://code.google.com/p/blur-dev/

オープンソースプロジェクトらしいですが、ここにはコンパイル済みバイナリしかありません.

が、この blur-dev の python プラグインをインストールしてみたのですが、残念ながら max10(x64) では動きません.
どうも mscvp80.dll が見つからないのが原因のようです.

mscvp80.dll(VS2005 のランタイム) は、配布が制限されている dll で、入手するには 「VS2005SP1 再分布モジュール」 をインストールすることなのですが、なんと vista64 環境では VS2005SP1 再分布モジュールはインストーラがうまく動かないのでインストール不可というシロモノ.

-> というわけで、とりあえず msvcp80.dll 依存なくせと blur-dev の issue に登録しておきました.

また、chiyama さんから、blurbeta というサイトを教えてもらいました.

http://www.blur.com/blurbeta.html

この offsite tools installer を使うと、上記 blur-dev のバイナリの元になっているであろうソースが入手でき、 c:\blur に展開されます.
が、こちらはコードが VS2005 + max9 + python25 用らしいので、これもまた max10 + python26 環境ではうまくコンパイルできない.

というわけで、Vista64 + Max10(x64) で動く Py3dsmax は実質無いという状況です.

… ちょっくら blur にでも最新のソース公開してくれませんか、と問い合わせてみますかね.

PyQt4 in Maya2010(x64 windows) requires 64bit version of PyQt4.

maya_pyqt_integration_thumb.JPG

I can successfully use custom PyQt4 in Maya2010(x64 windows).
Unfortunatelly, PyQt4.6 binary provided by Riverbank’s URL

http://www.riverbankcomputing.co.uk/software/pyqt/download

Doesn’t work in my environment(Maya2010 x64 on Vista64).
Thus I’ve rebuild x64 version of Qt4.5 and PyQt4.6 from source with procedures described in the following blog entry.


http://eoyilmaz.blogspot.com/2009/09/how-to-compile-pyqt4-for-windows-x64.html

[Ja]

PyQt4 を Maya2010(x64 Vista64) で使おうとして、Riverbank のサイトにある PyQt4.6 バイナリを Maya の Python にインストールしたのですが、

「 ‘utf8’ codec can’t decode …」

とエラーで出てうまくいきませんでした.
そこで maya plugin 神の協力のもと、
Qt4.5 と PyQt4.6 をソースからビルドして明示的に x64 版をビルドしたところ、
うまく Maya2010(x64) で動くようになりました.

Maya2010(x64) だと, Python は 2.6 かつ 64bit 版が使われているので、Qt や PyQt も 64bit 版を使わないとうまくうごかないらしいようです.
しかし Qt の Windows 上でのコンパイルはめんどくさかったです.

そんなわけで, コンパイルを省略したい方は, 上記 blog エントリで紹介されている 64bit 版 PyQt4 binary

http://code.google.com/p/pyqt4-win64-binaries/

が, うまく設定を行えば使えるかもしれません. 未確認ですが.

AMD OpenCL on windows too slow…?

cltestsc.JPG

I’ve wrote a simple OpenCL test program which simply fills pixels and display it through OpenGL.
When I run it on ATI Stream SDK 2.0 beta on Windows,
I got terribly slow performance: around 8 secs per frame!
(On SnowLeopard OpenCL(CPU version) it runs around 0.0001 secs per frame)

What’s wrong? Because AMD version is a beta version?
I’d like to discuss this problem but I don’t know where is the good place to ask…

FYI, Here’s OpenCL kernel used in the test program.


__kernel
void
main(
   __global uint *out,
   uint col) // not used.
{
   int x = get_global_id(0);
   int y = get_global_id(1);

   out[x+y*get_global_size(0)] = (uint)(x | (y << 8) | (255 << 16) |
(255<<24));
}

[Ja]

単純に 256×256 画像のピクセルをフィルするだけの OpenCL プログラムを書いてみたのですが、
ATI StreamSDK 2.0 beta(Windows, CPU 利用)の OpenCL 実装だと、8 秒近くもかかってとてつもなく遅い!
(SnowLeopard だと 0.0001 秒なのに…)

追記

Visual Studio 2008 を使っているのですが、デバッグ -> デバッグ開始だととても遅くなる模様(Release ビルドでも).
デバッグ -> デバッグなしで実行だとそれなりの速度でうごきました.
んー、なにか変な実行時デバッグチェックが、OpenCL ドライバかどうか分かりませんが、入っているのですかね.
ちなみに「デバッグなしで実行」でも、0.05 secs くらいかかりました.
(SnowLeopard の 0.0001 秒に比べるとまだ遅い)

[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 万ポリゴンですからね.
その代わり, テクスチャの枚数とサイズはそれなりに量がある感じです.

[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 のついでに参加もできるようにアレンジしてみました.

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 が問題になる.

まー、もちろんプログラマの腕次第である程度 IO のトランザクションは解決できるのですが、
その場合アルゴリズムから変わるので API にも影響があります.
API が CPU/RPU/GPU でワークロードの割り振りをうまくコントロールできるようなアーキティクチャであればいいんですけど,
GL ベースっていう時点でなんかダメそうな気がしています…

# 要は PhysX と同じですね. IO がネックになるというのは.
# またもしビジネスモデルも PhysX と同じだとしたら、 API だけオープンででっち上げて普及させ、テキトーにハードつくって、
# しばらくしてどこか大手に買収してもらうというイグジットプランだったりして.

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

(URL がへんな文字列を含んでいるので、ブラウザによっては表示が崩れています. ご了承ください)

久しぶりの開催となりますが、OOOO やります
(OOOO = オフラインレンダラ野郎のためのオフラインレンダリングについて議論するオフライン会)

2009 年 8 月 28 日(金)
OOOO 第六回 : 09 年レンダリング論文レビュー

今回は、都合により平日金曜日の開催となります.
SIGGRAPH 帰国組が参加できるようでしたら、SIGGRAPH レポートなどもしてもらう予定でいます
(残念ながら私は参加しません)