とうとう来たかCS4

Adobeが、CS4で、どうやらCUDAに対応したようだ。

うかうかしてられんなー。

nVIDIAのKhanh氏来社

CUDAエンジニアのnVIDIAのKhanh氏が来社した。
メモリ関係の高速化は、やはり色々と難しいようだ。
なんとしても対応したいなぁ。 > CUDA

速度が出ない

CUDAのコアレスアクセスが理解出来たので、再びBoxFilterに挑戦しているのだが、これが速度が出ない。
単純コピーなら20GB/S出るのに、単純な平均化フィルターでは、3GB/Sくらいに落ちてしまう。
もちろん、平均化に限ってしまえば、遥かに高速には出来るアルゴリズムはあるのだが、メモリをアクセスした際のパフォーマンスが知りたいので、ベタにやっている。
そこで、読み込み元をテクスチャにすると、かなり高速になる。
境界処理もしてくれるし、やはりテクスチャを使うのが正しいようだ。
しかし、元の画像をテクスチャにして、水平方向の処理をした結果に、今度は縦方向の処理をするわけだが、後者はテクスチャが使えない。
なので、前者に比べて、かなり速度が落ちてしまう。
そこで、水平方向の結果が出たら、一旦ホストに処理を戻して、その結果をテクスチャとして転送して登録、垂直方向の処理をする、という事を実験してみた。
そしたら、速くなりましたよ。
ベタでテクスチャ使わないと、3GB/Sくらいだけど、両方テクスチャにすると、5.5GB/Sくらい出る。
途中、結果をテクスチャとして転送している分のオーバヘッドは、ほとんど誤差のレベル。
VRAM同士の複写なら、70GB/Sくらい出ているので、問題にならないのだ。

TMPGEnc 4.0 XPressもCUDAに対応した(一部だけど)みたいだし、やっぱり対応したいな〜。

CUDA コアレスアクセス

ようやく、CUDAのcoalesced accessというのが理解出来た。
単純なメモリコピーで、8GB/S程度しか出ていなかったのが、今日、20GB/Sまで向上した。

キモは、

連続したメモリに各スレッドが同時にアクセスする

という事。

今までは、画像のフィルターを、ラインに分割して、1ラインを1スレッドにやらせていた。
これだと、全てのスレッドが、担当するラインのピクセルを読み込みに行く。
つまり、非連続なメモリをアクセスするので、読み込みの指令数分だけのアクセスが生じる。
この例で分かりやすく言えば、スレッド数分だけのアクセスが生じるわけだ。

これを、各スレッドが各ピクセルを処理させる様にする。
これがcoalescだ。
スレッド0番は、Pixel0を、スレッド1番は、Pixel1を...と、順番に並べてアクセスさせる。
次のループでは、スレッド数分先を読み込みに行く。
簡単に言えば、ライン単位ではなく、連続するピクセル単位で分割するという事。
こうすると、例えば最初の8つのスレッドの塊は、0〜7ピクセルを読み込む事になるのだが、その複数のメモリ読み込み指令は、メモリが隣接しているので、どうやら1回のDRAMへのアクセスに統合されるらしい。
GPUのデータバス幅は、384bitとかあるので、一度のアクセスでそれくらいを持ってこれる。
そして、その一度に持ってきたデータを、それぞれのスレッドに渡す様になっている、らしいのだ。
これによって、ライン毎に分割してたのに比べ、メモリへのアクセス回数が、バス幅分の1に減る。
キャッシュのないこの様なGPUでは、この様に最適化するらしい。
ちなみに、このスレッドの塊を、Warpと呼んでいる。

何故、Warpとかを意識しなきゃいけないかとか、SoA(Structure of Arrays)を使えとか、やっと意味が分かった。
てか、最初からそういう風に説明してくれれば、こんなに理解に時間はかからんかったのになぁと思う次第。

BoxFilterその後

CUDAでのBoxFilterを相変わらずやっている。
メモリの速度は、cudaMemcpyで、DeviceToDevice(VRAM間)の転送なら、90GB/Sという速度が出ているのだが、これを各SMでパラで転送しても、全然この速度に及ばない。
組み込み型uint4を使って、単純なメモリコピーをして、8GB/Sくらい。
約1/10だ。
この速度をベースに、画処理をやらせて、計算とメモリアクセスを並列にこなし、メモリアクセスのレイテンシを隠蔽しても、これ以上のレートは出ないわけだから、ここを何とか高速化したい。
というわけで、NxNの単純な平均化フィルタで色々やっているのだが、メモリ書き出しのレイテンシが結構馬鹿にならないようだ。
そして、これがよく理解出来ていないのがだが、メモリアクセスがCoalescedになっていないと、とんでも無く速度が落ちるらしい。

Coalescedってよく分からんのだが、要するにメモリアクセスの方法みたいな事かな。
例えば、この様な平均化フィルタなら、縦横それぞれで分割処理出来る。
1pixelにNxNをやっていたら、FilterのRadiusが大きくなるにしたがって、指数関数的に時間がかかってしまうが、縦横それぞれに分割して二度行う様にすれば、それは単なる直線的な比例で収まる。

普通に処理するなら、横方向の処理をやって、縦方向の処理をやって終わりだ。

ところが、ここで、最初に横方向に平均化をしてやったら、その結果を転置(90度回転)して書き出し、更に次の縦の処理で、先のデータが転置になっているので、やっぱり横方向の処理をする事で、両方の処理が行えた事になる。
そして、その結果を、また転置で格納する。
これで転置→転置で元に戻るわけだ。

こんな事して意味あるのかよーと思うけど、これがCoalescedの為の重要なプロセスなのだ。
つまり、メモリアクセスの仕方を変える。
転置にする事で、連続したデータが非連続なアドレスへのアクセスに置き換わる。
どうやらここでレイテンシを隠蔽出来るらしいのだ。
実際、この様に転置に格納する事で、速度が上がった。

なので、まだまだCUDAの高速化は、奥が深そうだ。

動画作ってみた

今日、物体を動かしてみたので、せっかくなので、動画を作ってみました〜。
動かせない人も、雰囲気だけを味わって頂ければと思います。

前の動画より、よくキャプチャ出来た。
30fps以上出ているけど、キャプチャは30fpsにした方がええんじゃな。

物体を動かしてみた

画像処理の方は、テクスチャを用いて、劇的に速度を向上させる事が出来た。
今日は、ちょっとレイトレの方で、物体を動かしてみようと思ったのだが、結構大変だった。
というのも、物体のデータは、定数メモリ(ConstantMemory)に予め静的に用意してあったので、それを動的にいじるとなると、使うメモリを変更しなくてはならない。
それで、グローバルメモリは遅いので、ブロック毎に持っている16KBの共有メモリを使う事にした。
ところが、コーディングは良いのだが、真っ黒けになってしまって、しばらく悩んだ。
原因は、コピー元のデータに、__constant__ 属性がついていたこと。
これがつくとHost側ではデータ参照出来ないのね...。
などなどやって、物体を動かすついでに、少し大きくして数を増やしました。
物体の動きは、本当は力学とかシミュレーションすると面白いのだろうけど、そこまでの余裕は無かったです。

↓いつもの通りの構成で、exeがパックされています。

CUDAのレイトレで物体を動かしてみたExe

ドライバなどの要件は、こちらを参照して下さい。

沢山人がいらしているけど、あんまり動作報告がないって事は、実はうまく動いてなかったりして

CUDAで汎用画像処理

レイトレは、まぁCUDAの性能がどれくらいなのかを知りたかったという事でやってみたもので、実は、プロダクトにする予定は全くないのです。
なので、本来の目的の、画像処理を行うプログラムを書き始めた。
とりあえず、高速化とか考えずにベタでBoxFilterを作ってぼかしてみたが、あんま速くないですね〜。

サンプルについていたBoxFilterを見たら、テクスチャをうまく使っている様。
テクスチャ関係を調べてみたら、境界処理を勝手にやってくれるという事と、アドレッシングによっては、簡単な補間(おそらく一次補間)をやってくれるんだそうで、これは思いっきり便利かもしれない〜。

しかし、この日本語みたいな変な文章、相変わらず意味不明だｗ

CPUにSSE2を使ってみた

今までアップしていたのは、CPUの処理をnVIDIAのコンパイラ(ベースはgcc)でコンパイルしていた。
MSのコンパイラではどうよ、という事で、VisualStudio2005向けに書き直してコンパイル。
ついでに、浮動小数点の精度を「高速」に設定して、「SSE2を使う」にしてみた。

結果、ちょっとレンダリングされる内容が異なるのだが、速度だけを比較すると、1.8FPS前後から2.5FPSくらいまで、約1.4倍高速になった。

でもCUDAとは、まだ数十倍の開きがあるなぁ...。

試してみたい方はこちら↓

CPUでSSE2を用いてレイトレEXE

DirectX9は必須だけど、それ以外は多分何も要らないと思います。

EXE修正

ほとんどの人が動かないというコメを頂いたので、exeを修正して、アップしなおしました。

必要な要件とかは、こちらを参照して下さい。

exeは、そちらからでも、ここのでも同じものです。

CUDAによるレイトレーシングデモ

うまく動かない方へ

まず、d3dx9_37.dllがねぇぞって言われる方。

こちらからダウンロードできます。

開発環境には、DirectX9のSDKがインスコされているので、問題なく動いてたんだけど、自宅では動かなかった。
でも、Vistaって、DirectX10だよねぇ...。
DirectX9の上位コンパチじゃないのかよ。
MSのサイトじゃないのが気になりますが、僕は、そこからダウンロードして、まぁ大丈夫でした。


つぎに、「サイドバイサイドの構成が〜」云々と言われて動かない方。
VS2005のSP1再配布パッケージなるものが必要らしいです。
VS2008がインスコされているのに動かないってどうよ？

こちらのページから誘導されてみてください。

うまく動いたら、コメント下さいませ〜。

追伸(exe公開)

DirectX9のSpriteを使って、ロゴ出しているのだけれど、それがDirectX9のSDKが入ってないと動かないみたい

なので、別処理で表示させるようにしました。
一応、お仕事の一環なので。

それでは、こちらからどーぞ。

CUDAによるレイトレーシングデモ

精度の問題解決(exe公開)

悩んでいた精度の問題は、クリアになった。
というか、元々の参考にしていたソースにバグがあった。
Bio_100%のtinyan氏に指摘してもらった点と類似するバグで、プログラムの対称性から気が付いた。
有難う、tinyan

さてさて、OpenMPの方を用いたノイズが出るバグも修正し、どちらもとても綺麗にレンダリング出来る様になりました。

ざっくり速度を比較すると、

Core2Duo(3GHz)×2 = 最大 1.89FPS
CUDA(GTX 280) = 最大52.48FPS

27.7倍高速

という結果になりました。
ちなみに、Core2Quadの2.5GHzくらいのでもやってみたけど、3FPSくらいが限界だった。

さてさて、皆さんにもこの感動を味わって頂きたく、exeを公開しちゃいます。

実行には、
GeForceの8000番台以降のGPUカードが必要で、
WindowsXP/Vistaのどちらか。
そして、nVIDIAのCUDA用のドライバをインストールする必要があります。

CUDAのドライバは、こちらからダウンロードできます。

ドライバは、開発にβ2を使っていますので、そちらを落として下さい。
再起動が必要になります。

そしたら、こちらに置いてあるアーカイブを落として解凍して下さい。

CUDAによるレイトレーシングデモ

RayTraceCPU.exe ... CPUによるレンダリング
RayTraceCUDA.exe .. GPUによるレンダリング

CPUの方は、搭載されているCPUの数で、分散処理します。

動いたら、是非、コメント下さいませ〜。

やはり精度の問題か

どこが問題か分からないので、全部、doubleにしてやってみたよ。
そしたら、綺麗にレンダリングされるわ。
まぁ当然か。
基本となる視線ベクトルだけ、floatにしたら、それだけでもダメだった
doubleの演算器は、GT200になって追加されたけど、それじゃ、過去のGeForceシリーズではノイズが乗っちゃうし。
大体、20FPS割っちゃうから、doubleはダメだなぁ。

どうするか？

CPU処理をOpenMP化

DirectXによる描画時のCPU側の処理を、OpenMP化してみた。
Core2Duoで、実際に二つのスレッドで、別々に求めるように。
これで、FPSは2.0となり、単一CPUの倍の性能が出た。

ただ、何かがおかしいらしく、画面上にノイズが出ている。


別にforをパラレルにしているだけで、お互いに影響する変数とかは無いはずなんだけどなぁ。

それにしても、CUDAは、平均で30FPSは出るわけだから、15倍くらいはCPUより速いと言う事か。

バグが取れない..

CPUでの描画もDirectXに対応したレイトレプログラム。
しかし、精度落ちで発生していると思われた、球にノイズが乗る現象が、CPUでも再現してしまった。
プログラムの変更箇所をVSSで表示したが、計算自体は何も変えていない。
なので、一度、完全に取りさらったOpenGLでの描画コードを戻して、OpenGL/DirectX,CPU/GPUの組み合わせを全て選べるように書き直した。

OpenGLで描画させると、大丈夫です。
DirectXで描画させると、ノイズが出ます。

それならDirectの方に問題があるんじゃ？
と思いますね、フツー。
でも、計算自体は全く同じ関数で行われています。
描画時に乗る様な種類のノイズじゃないし。
う〜〜ん。
何がおかしんだろう〜

ちなみに、OpenGL+CPUのちゃんと行く組み合わせでも、ball()関数内のdoubleをfloatに落とすと、GPUと同じ様いノイズが出ます。
なので、てっきり精度落ちの問題だと思っていたのだが...。

というわけで、ソース公開します。

CUDAによるリアルタイムレイトレーシングその２

見にくくて、すみません
ソースの最初の方、
_CPU_ という定義を有効にするとCPUで、そうでない場合GPUで、
_OPENGL_ という定義を有効にするとOpenGLで、そうでない場合DirectXで、
それぞれ計算＆描画します。
DirectXの場合は、アニメーションします。

#誰かバグ取ってくれないかな〜

CPUもDirectXに対応した

nVIDIAさんの方から、CPUと比較して、どのくらい速くなったか、体感出来るデモみたいなもの作れませんか〜と言われたので、CPUでもアニメーションするようにしてみた。

結果は、なんと、1FPS

Core2だから、並列にやれば、2FPSくらいまでは伸ばせるか...。
CUDAはやはり桁違いに速いな。

動画を作ってみた

CUDAによるリアルタイムレイトレーシングのレンダリング結果を、キャプチャソフトでキャプチャして、動画にエンコードしたもの。
エンコードに試用版を使っている所が悲しい(だって会社だもん)

動画をアップするのは初めてだけど、出来るのかな？

キャプチャソフトでは、100FPSに指定してキャプチャしたんだけど、その速度ではキャプチャされてない
それをしかも720x480のMPEG2にしちゃうのだから、まぁ無理も無い。

実物はもっと遥かに綺麗で滑らかなんですが。

To the CUDA retrieval(English)

To the CUDA retrieval users




The source of the ray tracing program for CUDA is what it gets from here, and I for CUDA modified it.

The source code is put on a past diary of this blog of me if it is an easy demonstration that uses OpenGL, and it is possible to download it below.

Source code of ray tracing by CUDA

My ray tracer is in real time possible, and the performance that exceeds 50FPS is recorded in GTX280 now.
Please leave the comment for this blog of the hope of the exe file.

noridon(NEW/Bio_100%)

続・CUDAによるリアルタイムレイトレーシング

今日は、色々と高速化を試す。

試す。

試す。

そして、何が奏功したか分からないけど、

50FPS突破!

もう、レイトレって次元じゃない...。

同僚の8600GTでも、25FPSくらいは出てた。
自宅の8400GSでも、12FPSは出てた。

exeを欲しいという方がいらっしゃいましたら、是非、コメントお願いします。
DirectX9以上、GeForceの8000番台をお持ちで、cudaのドライバ(2.0β)がインストールされていれば動きますので、声を掛けてくださいませ。
#cudaのドライバは、nVIDIAのHPから落とせます。