> RenderTime: 28171.4
いけてなさすぎる．
2015/07/25
XCodeのLLVM(clang)でOpenMPを使おう(解決)
こんにちは．@rootxです．
高速化って大切ですよね．
結果が出るまで待てない，AWSに余計なお金を払いたくない，などなど，進化した計算機といえどもCPU資源を使いきって高速に処理する需要はなくなることはありません．
CPU自体の進化も，クロックの高速化競争の集結を迎え，シングルスレッド性能は頭打ちになってきています．
この背景には，半導体プロセス微細化によるリーク電流や，数GHzを超えると電子の移動速度も際どくなる等が要因として挙げられていたと記憶しています．
＃ 消費電力あたりの性能，という指標は個人的には好きではありません…．
そのため，現在のCPUではマルチコア，ハイパースレッド等の技術によって，処理を複数同時に実行できることでCPU全体としての性能向上を維持しています．
プログラミング技術においてもその方向に進んでいて，いかに並列処理をするか，というのが現代的なプログラムの重要なポイントの1つとなっています．
様々な並列処理手法がありますが，C++で開発する際に，お手軽に並列化する方法の1つにOpenMPというライブラリがあります．
このOpenMPは，名前がちょっとOpenGLに似ていますが全然関係なくて，並列処理を簡易的に実装する
しかも最近のVisual Studio(VS2010以降？)では標準的に使えるようになっていて，
プロジェクト設定をちょいちょいと変えてあげるだけで有効になる，とってもとっても便利なライブラリで，特にレイトレのような並列化の容易なアプリケーションでは，たった1行追加するだけでバリバリ並列化できちゃう夢のような仕組みです．
しかし残念なことに，OSX上のXCodeで開発している場合は，VSほど簡単に有効にすることはできないようです．これはXcodeの標準コンパイラがLLVM clang3.5であり(MacOS 10.9.5 Xcode6.2時点)，ちゃんと対応されていないバージョンのためです．
そのうち標準対応されるのではないか，と想像していますが，現時点では望めません．
# 10.10の環境は未調査．今のところ，あのフォルダアイコンのださいOSをメイン環境として使う気がないため．
ということで，自前でスレッド処理するが，gccに切り替えて使うべきか，いっそのことWindowで開発するか，といった悩ましい問題が目の前に立ちはだかっているのです．
いろいろ探していましたが，OpenMPを有効化したclang-ompが配布されていたので導入す
これで完了．あとは #include <libiomp/omp.h>して，#pragma omp〜〜を使うだけ？．
どうやらXcodeは，C++のコンパイル時にCCに定義されたものを自動的に置換しているようです．その際に，末尾に++を追加するのではなく，clangをclang++に置換するようです．（途中のバージョンで仕様が変わったのかな…）
ということで，暫定的な対策ですが，clang-omp++の名前をclang++-ompにすることで，上手くそれを使ってくれるようにできました．
でわでわ．
高速化って大切ですよね．
結果が出るまで待てない，AWSに余計なお金を払いたくない，などなど，進化した計算機といえどもCPU資源を使いきって高速に処理する需要はなくなることはありません．
CPU自体の進化も，クロックの高速化競争の集結を迎え，シングルスレッド性能は頭打ちになってきています．
この背景には，半導体プロセス微細化によるリーク電流や，数GHzを超えると電子の移動速度も際どくなる等が要因として挙げられていたと記憶しています．
＃ 消費電力あたりの性能，という指標は個人的には好きではありません…．
そのため，現在のCPUではマルチコア，ハイパースレッド等の技術によって，処理を複数同時に実行できることでCPU全体としての性能向上を維持しています．
プログラミング技術においてもその方向に進んでいて，いかに並列処理をするか，というのが現代的なプログラムの重要なポイントの1つとなっています．
様々な並列処理手法がありますが，C++で開発する際に，お手軽に並列化する方法の1つにOpenMPというライブラリがあります．
このOpenMPは，名前がちょっとOpenGLに似ていますが全然関係なくて，並列処理を簡易的に実装する
しかも最近のVisual Studio(VS2010以降？)では標準的に使えるようになっていて，
プロジェクト設定をちょいちょいと変えてあげるだけで有効になる，とってもとっても便利なライブラリで，特にレイトレのような並列化の容易なアプリケーションでは，たった1行追加するだけでバリバリ並列化できちゃう夢のような仕組みです．
しかし残念なことに，OSX上のXCodeで開発している場合は，VSほど簡単に有効にすることはできないようです．これはXcodeの標準コンパイラがLLVM clang3.5であり(MacOS 10.9.5 Xcode6.2時点)，ちゃんと対応されていないバージョンのためです．
そのうち標準対応されるのではないか，と想像していますが，現時点では望めません．
# 10.10の環境は未調査．今のところ，あのフォルダアイコンのださいOSをメイン環境として使う気がないため．
ということで，自前でスレッド処理するが，gccに切り替えて使うべきか，いっそのことWindowで開発するか，といった悩ましい問題が目の前に立ちはだかっているのです．
いろいろ探していましたが，OpenMPを有効化したclang-ompが配布されていたので導入す
ここから本題です．
Xcodeで clang-omp の使い方
- homebrew でclang-ompをインストール: brew install clang-omp
- Xcodeプロジェクトを作成
- ビルドセッティング(Build Setting)で：
- 新しいユーザ定義設定 CC を次の値で作成：/usr/local/bin/clang-omp
- -fopenmpをOther C Flagsに追加
- /usr/local/includeをHeader Search Pathsに追加
- Enable Modules (C and Objective-C)をNoにセット
- ビルドフェーズ(Build Phases)で：
- /usr/local/lib/libiopm5.dylibをLink Binary With Librarianに追加
- （＊）/usr/local/binにhomebrewでインストールされたclang-omp++というエイリアスがあるので，clang++-ompに名前を変更
これで完了．あとは #include <libiomp/omp.h>して，#pragma omp〜〜を使うだけ？．
注意
なぜかビルドできませんでしたが，上記手順の5を追加することで上手く動くようになりました．どうやらXcodeは，C++のコンパイル時にCCに定義されたものを自動的に置換しているようです．その際に，末尾に++を追加するのではなく，clangをclang++に置換するようです．（途中のバージョンで仕様が変わったのかな…）
ということで，暫定的な対策ですが，clang-omp++の名前をclang++-ompにすることで，上手くそれを使ってくれるようにできました．
補足
glmがコンパイラを認識できずに次のエラーを出しましたので対応しました．
/usr/local/include/glm/detail/setup.hpp:287:2: error: "GLM_COMPILER undefined, your compiler may not be supported by GLM. Add #define GLM_COMPILER 0 to ignore this message."#error "GLM_COMPILER undefined, your compiler may not be supported by GLM. Add #define GLM_COMPILER 0 to ignore this message." ^1 error generated.Command /usr/local/bin/clang-omp failed with exit code 1
TODO
後日，効果を検証します．
なんかビルド時のエラーの出かたが変化した気がする…でわでわ．
遅いのでAABBを導入してちょっとだけ早くする
こんにちは．@rootxです．
簡単なレイトレができましたが，単純なシーンの割に遅いです．
先ほどの偽コーネルボックス(640x480)のレイキャストで約1.0秒もかかっています．
これは由々しき事態です！
というわけで，本筋としてはBVHなどの高速な衝突検出（O(log(n)）を使うべきですが，
とりあえずAABBを導入します．
AABBとは，Axis Aligned Bounding Boxの略で，要するに当たり判定用のBOXです．
ポイントはXYZ軸に沿っていることですね．そのため，斜め方向を向いている細長い物体だと，大きくなりすぎる問題もあります．
物体の向きに関係なく，任意方向の境界BOXであるOBB(Oriented Bounding Box)というものもありますが，OBB算出が面倒なのとシーンが複雑になった時の構築時間が増えてしまうので，今回は後々の拡張も考慮してAABBを採用します．
AABBの実装は簡単で，プリミティブの最小最大座標をx,y,zそれぞれ求めて上げればOKです．
現在，プリミティブとして用意しているのは，三角形と球なのでちょいちょいと求めてあげます．
メッシュ（モデル）毎にもAABB持たせてあげましょう．
メッシュを構成する全プリミティブのAABBをガッチャンコします．
MergeAABBみたいな関数を用意すると便利ですね．
次はAABBとレイとの衝突判定を実装します．
とりあえずこれを参考にします．
ゲームプログラミングのためのリアルタイム衝突判定
サンプルコードがここ（http://www.borndigital.co.jp/book/164.html） からダウンロードできるので買わなくてもいいけれど，一冊持っていると良いと思います．
ちなみに，この本は学生の時にお世話になりました．
その当時は日本語版がなくて，英語を読むのに苦労した覚えがあります……；
でわでわ．
簡単なレイトレができましたが，単純なシーンの割に遅いです．
先ほどの偽コーネルボックス(640x480)のレイキャストで約1.0秒もかかっています．
これは由々しき事態です！
というわけで，本筋としてはBVHなどの高速な衝突検出（O(log(n)）を使うべきですが，
とりあえずAABBを導入します．
AABBとは，Axis Aligned Bounding Boxの略で，要するに当たり判定用のBOXです．
ポイントはXYZ軸に沿っていることですね．そのため，斜め方向を向いている細長い物体だと，大きくなりすぎる問題もあります．
物体の向きに関係なく，任意方向の境界BOXであるOBB(Oriented Bounding Box)というものもありますが，OBB算出が面倒なのとシーンが複雑になった時の構築時間が増えてしまうので，今回は後々の拡張も考慮してAABBを採用します．
AABBの実装は簡単で，プリミティブの最小最大座標をx,y,zそれぞれ求めて上げればOKです．
現在，プリミティブとして用意しているのは，三角形と球なのでちょいちょいと求めてあげます．
メッシュ（モデル）毎にもAABB持たせてあげましょう．
メッシュを構成する全プリミティブのAABBをガッチャンコします．
MergeAABBみたいな関数を用意すると便利ですね．
次はAABBとレイとの衝突判定を実装します．
とりあえずこれを参考にします．
ゲームプログラミングのためのリアルタイム衝突判定
サンプルコードがここ（http://www.borndigital.co.jp/book/164.html） からダウンロードできるので買わなくてもいいけれど，一冊持っていると良いと思います．
ちなみに，この本は学生の時にお世話になりました．
その当時は日本語版がなくて，英語を読むのに苦労した覚えがあります……；
でわでわ．
単純なレイキャスティング
こんにちは．@rootxです．
とりあえず，単純なレイキャスティングを行うプログラムを書いてみました．
シーンがしょぼいのと，光源を設定していないので陰影も出てませんが；
でわでわ．
とりあえず，単純なレイキャスティングを行うプログラムを書いてみました．
シーンがしょぼいのと，光源を設定していないので陰影も出てませんが；
でわでわ．
使うライブラリ
こんにちは．@rootxです．
今回はレイトレ作るのに使いそうなライブラリを選んでみたよ．
あ，C++です．
普段ならフルスクラッチで書くこともあるけれど，今回はこのglmというライブラリを利用してみます．
特徴としては，ヘッダオンリライブラリで，GLSL風の機能が備わっていること．OpenGL系と
あんまり早くは無いはず．
画像出力（PNG）に使うつもり．
読込みもできるので，テクスチャロードもできるかな．
# でもglmの開発者の作っているgliも良さそうなんですよね．
基本的なフォーマット(collada, obj, stl, ply)でエクスポートもできるみたい．
とりあえずここまで．
他に使えそうなライブラリがあったら追加するよ．
今回はレイトレ作るのに使いそうなライブラリを選んでみたよ．
あ，C++です．
glm OpenGL Mathematics (http://glm.g-truc.net/)
ベクトルとかマトリクスとか，いつも出てくる子たちですね．普段ならフルスクラッチで書くこともあるけれど，今回はこのglmというライブラリを利用してみます．
特徴としては，ヘッダオンリライブラリで，GLSL風の機能が備わっていること．OpenGL系と
あんまり早くは無いはず．
stb single-file public domain libraries for C/C++ (https://github.com/nothings/stb)
いろんなファイルフォーマットに対応したヘッダオンリライブラリ．画像出力（PNG）に使うつもり．
読込みもできるので，テクスチャロードもできるかな．
# でもglmの開発者の作っているgliも良さそうなんですよね．
assimp : Open Asset Import Library (http://assimp.sourceforge.net/)
いろんなアセットを読込みたいときに使えるよ．基本的なフォーマット(collada, obj, stl, ply)でエクスポートもできるみたい．
とりあえずここまで．
他に使えそうなライブラリがあったら追加するよ．
でわでわ．
レイトレはじめます
こんにちは。@rootxです。
先日、ドワンゴがとっても興味深い人材募集を始めましたね。
新しい時代のエンジニアについて
http://info.dwango.co.jp/recruit/beyondtheweb/index.html
【新規事業】3DCGエンジニア(正社員)
具体的には次のような条件が示されてるよ。
> ＜必須条件＞
> • プログラマブルシェーダの実装経験者
> • SIGGRAPHなどで発表された論文を元に実装をしたことのある方
> • 3DCGの分野で何か研究したいテーマを持っている方
> ＜歓迎条件＞
> • SIGGRAPHなどにおけるCG関連論文の発表経験者
> • 物理ベースのオフラインレンダリングを研究開発できる人
> • リアルタイムへの自動リトポロジーアルゴリズムや光学エフェクトの研究開発ができる人
ドワンゴというと、やっぱりニコニコ動画のイメージが先行してるので、まさかこんなにガチな人材を求めるとは思っていなかった、というのが正直なところです。
3DCG関連でいうと、短期的には、WebGLやunityみたいなネットと相性の良いテクノロジを志向するかと考えていました。実際、ニコニ立体でそちら方面は手を出しているし。
そんなわけで、普段は興味分野と関係ないお仕事をしてるから、グッときちゃったね。
でも、全然実績がないから、どうしようかなと思ってたけど、折角なので今から実績を作れるか挑戦してみようと思います。
でわでわ。
登録:
投稿 (Atom)