Syoyo Fujita's Blog

raytracing monte carlo

Docker で aobench を動かす.

Qiita に書きました.

http://qiita.com/syoyo/items/de299359dc53795c2b66

Advertisements

SDE + gcc 4.9 で AVX512 命令を試す

2014 年に Knights Landing が市場に投入されて AVX512 命令も一般的に使えるようになりそうですね.

Intel SDE(シミュレータ) と AVX512 対応 gcc を使って一足先に AVX512 命令を試してみましょう.

http://software.intel.com/en-us/articles/intel-software-development-emulator

から

– SDE
– GCC
– binutils

を落としましょう. 以下のようなコードを用意します.

#include <immintrin.h>

#include <stdio.h>

void fa(__m512* c, __m512* a, __m512* b)
{
  (*c) = _mm512_add_ps(*a, *b);
}

int
main(
  int argc,
  char** argv)
{
  __m512 a, b, c;

  a = _mm512_set_ps(argc , argc+1, argc+2, argc+3, argc+4, argc+5, argc+6,
    argc+7, argc+8, argc+9, argc+10, argc+11, argc+12, argc+13,
    argc+14, argc+15);
  b = a;

  fa(&c, &a, &b);

  float ret[16];
  _mm512_storeu_ps(ret, c);

  int i;
  for (i = 0; i < 16; i++) {
    printf("c[%d] = %f\n", i, ret[i]);
  }

  return 0;
}

AVX512 対応 gcc と binutils でコンパイルを行います. AVX512 命令を有効にする場合は -mavx512f オプションを付けます.

$ x86_64-unknown-linux-gnu-gcc-4.9.0 -S -mavx512f main.c

zmm レジスタを使う vaddps 命令が出力されているのを確認します

vaddps  %zmm1, %zmm2, %zmm0{%k1}

AVX512 対応 binutils でアセンブルしてバイナリを作ります.

$ as -o main.o main.s

$ gcc main.o

SDE で実行します. -knl フラッグを付けます.

$ sde64 -knl — ./a.out

 ./a.out                                                                        
c[0] = 32.000000
c[1] = 30.000000
c[2] = 28.000000
c[3] = 26.000000
c[4] = 24.000000
c[5] = 22.000000
c[6] = 20.000000
c[7] = 18.000000
c[8] = 16.000000
c[9] = 14.000000
c[10] = 12.000000
c[11] = 10.000000
c[12] = 8.000000
c[13] = 6.000000
c[14] = 4.000000
c[15] = 2.000000

期待する結果が出ましたね!

Happy AVX512 coding!

aobench on ZeroVM

動かすアプリが決まっている場合に有益そうな, 次世代の(アプリケーション?)仮想化プラットフォーム ZeroVM で aobench を動かせるようにして, どこでもセキュアに aobench を実行する可能性を検討してみましょう.
(ZeroVM の中身はアプリを NativeClient でビルドして sandbox 実行するのがキモのようです)

http://zerovm.org/wiki/The_Cloud_Hypervisor

検証環境

– Ubuntu 12.04.3 LTS

インストール

Ubuntu 12.04 LTS 用にはプレビルトバイナリがあるのでこれを活用します.

http://zerovm.org/wiki/Download

を参考に ZeroVM 環境やコンパイラをインストールします.


$ sudo apt-get install zerovm-zmq
$ sudo apt-get install zerovm-cli
$ sudo apt-get install zerovm-zmq-dbg
$ sudo apt-get install zerovm-zmq-dev
$ sudo apt-get install gcc-4.4.3-zerovm

Makefile などを流用するためにサンプルコードを取得します.

$ git clone https://github.com/zerovm/zerovm-samples

hello サンプルを参考に aobench サンプルを作ります.

$ cd zerovm-samples
$ cp -Rf hello aobench

Makefile をいじり適当にファイル名を aobench に変えます. -lm を加えて数学ライブラリをリンクするようにします. cat $(NAME).stdout.log の行を削除しておきます.

aobench の C コードを https://code.google.com/p/aobench/ などから取得します. ファイルに画像を出力しているところを stdout に出力するように変えます.

ビルド and 実行を行います.

$ make
$ cat aobench.stdout.log > ao.ppm
$ eog ao.ppm

aobench.stdout.log に結果が書かれているので, これを変換して aobench 画像が出れば成功です.

aobench-zerovm

Happy ZeroVM hacking!

qemu + binfmt + chroot で AARCH64 環境を構築する.

2014 年から ARM 64bit(AARCH64) な環境が普及されるのが見込まれています.

qemu を利用してお手軽かついち早く Intel x86 環境で AARCH64 環境を作り体験してみましょう.

検証環境 : Ubuntu 12.04.3 LTS(64bit)

qemu と binfmt パッケージをインストールします.


$ sudo apt-get install binfmt-support qemu

https://wiki.debian.org/Arm64Qemu から debian unstable のプレビルト chroot 環境をダウンロードして展開します.


$ sudo mkdir /src/chroots/debian-unstable-arm64
$ sudo tar -zxvf debian-unstable-arm64.tar.gz -C /srv/chroots/

/usr/share/binfmts/qemu-arm64 ファイルを作り以下の記述を行います.


package qemu-user-static
interpreter /usr/bin/qemu-arm64
flags: OC
offset 0
magic \x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7
mask \xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff


$ sudo update-binfmts --import qemu-arm64

として取り込みます.


$ sudo chroot /srv/chroots/debian-unstable-arm64
# uname -m
aarch64

と chroot 環境にログインできて aarch64 と表示されれば成功です.

ホスト環境から直接 AARCH64 バイナリを実行する

ダイナミックリンクバイナリをうまく実行できるようにホスト環境でシンボリックリンクを張っておきます.


$ sudo ln -s /srv/chroots/debian-unstable-arm64/lib/aarch64-linux-gnu /lib/
$ sudo ln -s /src/chroots/debian-unstable-arm64/lib/ld-linux-aarch64.so.1 /lib/

ホスト環境でクロスコンパイラを使ってバイナリを作成, 実行します.


$ cat main.c
#include
int
main(int argc, char** argv)
{
printf("Hello AARCH64!\n");
exit(0);
}

$ aarch64-linux-gnu-gcc main.c
$ ./a.out
Hello AARCH64!

なんとも普通のホスト環境(x86)のバイナリとして ARM64 なバイナリが実行できました. 開発が捗りますね! Happy AARCH64 coding!

TODO

– ユーザの管理はどうするか?
– HOME の共有はどうするか?
– クロスコンパイラ前提なら共有ライブラリ以外の chroot 環境は必要ない?

参考文献

– QEMUのもうひとつの使い方: ユーザーモードエミュレーションとbinfmtとchrootの組み合わせ http://blog.kmckk.com/archives/2342452.html

– Arm64Qemu https://wiki.debian.org/Arm64Qemu

– AARCH64 cross compiler https://launchpad.net/linaro-toolchain-binaries/

C/C++ JIT shader on ARM

I’ve coded (World’s first) C/C++ JIT shader on ARM processor.

The JIT shader is connected with NEON-optimized interactive ray tracer, so you can edit shader and view its rendering result interactively.

You need MCJIT on ARM target, since old JIT engine is not supported on ARM processor.

rspreload

rspreload is a DLL replacement for socket() functions  taking a leverage of RDMA transport layer without any application modification.

rspreload is built on top of rsockets feature. See details here for rsockets:

https://www.openfabrics.org/ofa-documents/presentations/doc_download/495-rsockets.html

Recent advances of rspreload/rsocket finalIy enables  accelerating existing TCP/IP socket application such like iperf.

(At least it iperf with rspreload didn’t work a years ago).

$ LD_PRELOAD=/usr/local/lib/rsocket/librspreload.so iperf -c 172.24.0.8

————————————————————
Client connecting to 172.24.0.8, TCP port 5001
TCP window size: 128 KByte (default)
————————————————————
[ 3] local 172.24.0.16 port 51626 connected with 172.24.0.8 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 22.9 GBytes 19.7 Gbits/sec

It can achieve 19.7 Gbits/s in my IB QDR configuration.

This is 2/3 of theoretical peak 32 Gbits/s!  Simply super.

More details here:

https://github.com/syoyo/node.rdma/blob/master/measures/rsocket_preload_performance.txt

550D + Magic Lantern Dual ISO finally works!

550D + Magic Lantern Dual ISO finally comes!

http://www.magiclantern.fm/forum/index.php?topic=5582.msg69859#msg69859

Here’s my initial test.

 

Zoom-up of dual iso RAW image. You can see different exposure(ISO) for each alternate lines.

Zoom-up of original RAW image shoot with Dual ISO. You can see different exposure(ISO) for each alternate lines.

Dual ISO records RAW image with different exposure(ISO) for each alternate lines, so we need a processing after shooting(using cr2hdr tool given at Dual ISO page)

No Dual ISO image. You can see color noise in dark region.

Dual ISO

Processed Dual ISO image. You can see less color noise in dark region!

Cool!

I’ve confirmed Dual ISO also works well for RAW video. The problem is processing Dual ISO image with cr2hdr requires a lot of processing time.

I am considering GPGPU optimization for faster Dual ISO movie processing. Stay tuned 😉

 

I am investigating “DSLR as an illuminance meter”.

Dual ISO will definitely improve the accuracy of “DSLR as an illuminance meter”, which will be valuable for physically-accurate IBL and HDRI  footage used in CG/VFX.

8K realtime playback? its possible!

I’ve coded 8K RAW playback engine using OpenGL(GLSL).

Currently it uses RGB8 bit RAW encoding, but it can use LogLUV 24bit format for 8K HDR RAW playback with same bandwidth. Please go to video for more details.

Supercomputing Conference 2011

IMG_0354

SC とは

SC とは, 「スーパーコンピューティングカンファレンス」の略で, スパコンの学会です.

2011 年は「京」コンピュータがみごと Top500 で一位となり, 世間の注目となっていると思いますが, SC でも「京」関係のセッションがホットなトピックとなっていたように思います.

機会がありまして, 2011 年にこの SC に, 初めて参加してきました.

SC11 はシアトルで開催されました.

ここでは, グラフィックス野郎から見た SC11 の感想を記載していきます.

SC は毎年参加者が増え, 今では SIGGRAPH と同じかそれくらい大きい国際学会になっています.

SIGGRAPH は世界最大の国際学会と言われていますから,

SIGGRAPH と SC で国際学会の規模 1, 2 位を占めるわけですね.

SC は初めてということもあり, また知り合いがほとんど居ない事から SIGGRAPH などのグラフィックスの会議とはアウェー感がバリバリです…

グラフィックス系では可視化(ビジュアリゼーション)関連が多少 CG と関連がありつつも,

プレイヤー(論文発表者など)はアルゴンヌ国立研究所などの研究所だったり大学だったりと,

CG 系のような VFX スタジオやアニメーションスタジオ関連のプレイヤーとは全く違う分野になっていました.

(追記: 翌年の SC12 では GreenButton + Pixar によるクラウドレンダリングのセッションがありました)

もちろん, GPGPU などのグラフィックスチップの汎用計算は多く取り上げられていましたが,

スパコン野郎は主にそれを如何に計算やシミュレーションの高速化に使うか? というところに注目していて,

これもまた SIGGRAPH 関連のプレイヤーとは分野が異なっていました.

SIGGRAPH との違い

個人的に感じた, SIGGRAPH と違うところは大きく 4 点です.

1 つ目は, (昨今の) SIGGRAPH と違って企業や大学の展示がたくさんあります.

スペースとしても, セッションなどよりも展示スペースのほうが大きい感じです.

# かつての繁栄を極めたころの SIGGRAPH でも展示が大きかったと伝説に聞きます.

2 つ目は, 論文発表などの学術系のセッションでは, 休憩時間に飲み物やお菓子が無償で振る舞われていました.

また, 展示も初日は Opening Gala と言って, (無償の)アルコールやケータリングの食べ物を摂取しつつ展示を見て回るイベントがあったり, 夜には企業がスポンサーのパーティが開かれたりと, なんとも食には困らない学会です.

3 つ目は, 参加は皆 Ph.D Candidate だったり Ph.D ホルダークラスが標準レベルという感じで学のレベルが高いため,

皆さん英語が話せて当然, というレベルです.

SIGGRAPH のように英語が話せなくてもなんとか… というわけには行きません.

SC に参加するなら英語は出来て当然と考えておいたほうがいいでしょう.

4 つ目は, スパコンの学会というだけあってひたすら計算機環境の規模が大きい. 「計算機を数千ノード動かして計測しました」, 「CPU は全部で 1 万個使いました」. 「ストレージはペタバイトで…」 などなど.

なんともうらやましい環境で皆さん成果を出し合っています.

とはいえ, SC では発表スライドは背景を十分に説明していなかったり, 文字ばっかりだったりベンチマークの数値結果だけだったり,

「とりあえずいいハードウェアが手にはいったので Hadoop の性能を評価してみました」という内容の論文だったりと,

SIGGRAPH に比べると論文やプレゼンテーションのクオリティには残念と感じざるを得ないものもいくつかありました.

展示の勢力(?)が大きいため, SC では 企業や大学が, 毎日昼や夜に(食事無料の)パーティを開いています.

パーティへの参加状は水面下で取引されているようです.

SC 参加者から, 「毎夜企業主催のパーティがあるんだよ」とは聞かされていましたが,

私のような初参加者にはその存在が全く判りませんでした…

このあたりは参加経験を積んでコネを作っておくのが重要になるでしょうか 🙂

幸いにも, 私も KAUST(サウジアラビアの研究機関) のパーティ券をゲットできたので, KAUST のパーティに参加してきました

IMG_0361

パーティでは KAUST という研究機関のプレゼンテーションも含めつつも(サウジアラビアであるため, 石油が枯渇したあとのことをどうするか? いろいろ考えているようです), パーティには数百人が参加していて, 学会らしくなく皆飲食を楽しんでいてなんとも華やかな気分を味わうことができました.

まとめ

SC は展示の規模が大きい. SIGGRAPH も学会らしくないですが, 展示が大きかったり, 夜に企業がスポンサーのパーティがあったりと, SC は良い意味でより学会らしくない華やかなイベントと言えるでしょう.

SIGGRAPH のように, 何度か来たくなるような学会ですね.

おまけ

IMG_0362

Intel の展示ブースで aobench が動いていました.

Mandelbrot よりも有名なベンチマークになったと言えるかもしれませんね.

Camera RAW pipeline

I’ve implement my own Camera RAW decoder + debayer + color correction.

Image

(left: decoded and ACES RRT + sRGB ODT color graded RAW image. You can see filmic-look of image because of ACES RRT. right: mostly RAW value. You can see greenish image, this is correct as RAW value)

Recent custom firmware development(Magic Lantern) enables shooting 14bit DNG RAW video http://www.eoshd.com/content/10324/big-news-hands-on-with-continuous-raw-recording-on-canon-5d-mark-iii

So this will realise high-quality physical luminance video capture with mass-market DSLRs!

Physical capture of live world is very important for Live VFX and physically-based rendering as you know 😉

Unfortunately I haven’t 5D3, but have 550D. 550D also can capture 14bit DNG RAW, but limited to 0.5 ~ 1 fps shooting at this time(Magic Lantern team will improve this situation soon). Still, it is enough to test my own Camera RAW decoder implementation.

There are already good (open source) RAW decoder, called dcraw

Why I re-invented RAW decoder? The answer is for speed.

RAW decoding and (noise) filtering is very slow in general on CPU.

I am planning to accelerate RAW decoding(and filtering) on OpenGL compute shader utilizing GPU power.

I already got success to implement each component of RAW pipeline(decode, debayer, filter, ACES color grading, etc) into OpenGL compute shader.

So next phase is to implement all Camera RAW pipeline in OpenGL compute shader and performance tuning.

Stay tuned!

[References]