The Stanford 3D Scanning Repository で一番ポリゴン数の多い Stanford Lucy を何気にOpenGL表示してみたり。 随分前にPOVのレンダリングを 試みたところ、メモリが足りなくてあえなく撃沈してました。 頂点数14027872、三角ポリゴン数28055742のモデルなので、 GPUメモリには乗り切らないとは思いますがどうなるか？
で、試してみたところ意外と大丈夫でした。恐るべし。 でもプロセスサイズは7.5GBくらいになってます(^^;
昼頃起床。
もそもそとコーディング。32bitと64bitのソースコードのユニバーサル対応
を行ってみたり。まぁ、基本的には64bit対応すれば32bitも包含されると
いう感じですが。
POVrayの3.7RC6が来ていたり。まだRCらしい。そういや3.6も64bit対応版が存在
しているのに今気づきました。でも、3.6はマルチプロセッサ対応ではありません
ので、64bit対応されただけでは少々残念な感じかも。
日付越え。
眠くて死亡。
日付越え前に帰着。
The Stanford 3D Scanning Repository
で一番ポリゴン数の多い Stanford Lucy を何気にOpenGL表示してみたり。
随分前にPOVのレンダリングを
試みたところ、メモリが足りなくてあえなく撃沈してました。
頂点数14027872、三角ポリゴン数28055742のモデルなので、
GPUメモリには乗り切らないとは思いますがどうなるか？
で、試してみたところ意外と大丈夫でした。恐るべし。
でもプロセスサイズは7.5GBくらいになってます(^^;
日付越え前に帰着。
もそもそとコーディング。
遅めに帰着。
マルチスレッドでGMP/MPFRが使えるようになったので、マンデルブロ集合描画
プログラムに使用するCPU数を指定できるようにしてみたり。
std.parallelismを使用したのですが、何故か defaultPoolThreads()の指定が
一度しか使えない感じにあれぇ？と思ったり。結局、parallelism.d内の
unittestのコードを参考にして解決。std.parallelismってまだドキュメントが
存在していないのが何故だろうという気も。手軽にループをマルチスレッド化
できてとても良いのに。
早くもなく遅くもなく。
先日作成した10000x10000の画像はマンデルブロ集合描画プログラムで作成した
のですが、32bitコンパイルだった為12000x12000とかにするとギリギリアウトで
メモリ不足になってました。で、64bitでもっと大きなサイズを(とは言っても
CreateDIBSection()の上限問題はクリアできてませんが)と64bit化してみたり。
ところが、なぜかSegfaultするバイナリが出来上がったり。GMPのグローバル変数
として mpf_precision という変数が用意されているのですが、どうやら
特に修飾せずに使っていたのがダメだった模様。sharedで修飾してグローバル
変数化すればひとまず通ったり。で、これがラッキーな所だったのですが、
GMP/MPFRを使用するとマルチスレッドでずっこけていたのがこの修正の影響か
ずっこけなくなりました。32bitの方でも同様の直し方でGMP/MPFRの
マルチスレッド動作がOKになったり。そういう事だったのか......
ただ、GMP/MPFRはチューニングが効き過ぎているせいか、8CPU並列で動作
させるとWindows全体がかなりもっさりな感じに(^^;
昼前起床。
OpenGLを使用した画像の表示。以前
よりgdcのアップデート追従の為にメンテしている手持ちのテストコードを64bit化して、
画像サイズがどこまでいけるか試してみたり。単純にテクスチャを巨大にするのでは
OpenGLで指定できる最大テクスチャサイズ上限に引っかかってしまうので256x256pixを単位
としたポリゴンをつなぎ合わせて巨大画像を表示するという感じです。
スナップショットの画像は10000x10000pixを表示してみた所です。
A4サイズで色々見た感じは以下。
┌─────┬──────┬────────┬──────────┐ │ dpi │pix 幅x高さ │ 使用GPUメモリ │10000x10000画素数比 │ ├─────┼──────┼────────┼──────────┤ │A4/ 350dpi│ 2894x 4093 │約100MB〜180MB │ 11.845142 % │ │A4/ 600dpi│ 4961x 7016 │約280MB〜330MB │ 34.806376 % │ │A4/1200dpi│ 9921x14031 │約850MB〜1GB以上│ 139.201551 % │ └─────┴──────┴────────┴──────────┘
起きたら夕方。寝すぎ。
そういえば、新PCのNVIDIAプロパティでは、温度を見る事ができません。
何か良いGPUのモニターツールは無いものかと探してみたところ、
GPU-Zなるソフトで色々見る事ができるらしいのを知ったり。
で、10,000,000三角ポリゴンのThaiStatueを自作の表示アプリでOpenGL表示し、
ぐりぐり動かしている時の負荷を表示してみたのが以下。
因みにGPU Loadが0%になっているのは、スナップショットを取る為に
ウインドのフォーカスを切り替えたから。OpenGL窓で動かしている間の
GPU Loadは90%前後くらいでした。
搭載しているGPUのメモリは1GBなので、ぎりぎりセーフでGPUメモリ
に乗っている感じみたい。
温度は徐々に上がってますが、今回のアプリ表示ではせいぜい62℃
くらいでサチるようです。旧PCのGPUでは何もしてなくても常に60℃くらいで、
手持ちアプリでOpenGL表示したところ72℃くらいになるという感じでした。
現在のGPUは表示負荷に応じて動的にクロック周波数を切り替えているようで、
テキストエディットしているくらいの負荷であれば、50MHzくらいまで
クロック周波数を下げ、温度も37℃と省電力動作を行っているようです。
ローディング後、少し何もしてない状況にしてから、いきなりぐりぐり動かすと、
最初に若干のつっかかりを感じるのですが、クロックを上げる期間がある
のに関連しているのかも知れません。
こういう感じで見ていると、HDゲームの表示負荷がいかに高いかをうかがい
知る事ができたように思います。
VMwareでx86_64のFedora17を動かす事ができたので、先日試したのと同じ
gdcをビルドしてみたところ、gnu/stubs-32.hが見つからないというコンパイルエラー。
Webで検索してみたところ、glibc-devel.i686をインストールすれば良さそう。
yumでインストールしてみたところ先に進んだり。ビルドの様子を見ていると
-m32付きでlibphobosのソースをコンパイルしてたり。その後-m32無しで
コンパイルしていた為、マルチビルドを行っている模様。で、ほどなくして
エラー無くビルド完了。make installして簡単なソースをコンパイルして
みた所では問題無し。また、-m32付きでもコンパイル＆実行できました。
マルチビルドも問題無いようです。MinGWの方に来ないかなぁ？
日付越え。
DMD2.059マージされたgdcをFedora17でビルド。gccのベースに
スナップショットの gcc-4.8-20120617 を使用してみたり。
パッチの作り方をミスっているのか、setupスクリプトでパッチが
あたらなかったり。それを手で直してビルドしてみたところ、
エラー無くビルドできたり。Fedoraだと手持ちコードで試せるのが
無くてしょんぼり。
「大神絶景版」。「大神」がPS3でHDリマスター。てか出るの遅いよ！
最近はHDリマスターされたゲームが色々出ていますが、
イマイチなリマスターも少なくないようです。折角出すのなら愛のある
リマスターを希望。
そういや、VMwareでx86_64版のFedora17 liveを起動できなかったのですが、
BIOS設定で intel-vtが有効になっていなかったのが理由でした。
BIOSメニューのどの階層にスイッチがあるのか判らなかったのですが、
まさかセキュリティメニューに入っているとは。で、x86_64のブートイメージ
を食わせてみたところ、ちゃんと起動しました。
日付越え。
DMD2.059マージされたgdcをFedora17でビルドしてみたり。ベースとなる
gccはgcc-4.7.1を使用してみたのですが、gdc本体のコンパイルでエラー。
一つは、
../../gcc-4.7.1/gcc/d/d-lang.cc: In function ‘void d_write_global_declarations()’: ../../gcc-4.7.1/gcc/d/d-lang.cc:712:32: error: ‘finalize_compilation_unit’ was not declared in this scope make[2]: *** [d/d-lang.glue.o] Error 1
../../gcc-4.7.1/gcc/d/d-objfile.cc: In static member function ‘static void ObjectFile::outputThunk(tree, tree, int)’: ../../gcc-4.7.1/gcc/d/d-objfile.cc:744:36: error: ‘symtab_node’ was not declared in this scope ../../gcc-4.7.1/gcc/d/d-objfile.cc:745:21: error: expected ‘)’ before ‘funcn’ ../../gcc-4.7.1/gcc/d/d-objfile.cc:745:26: error: ‘symtab_add_to_same_comdat_group’ was not declared in this scope ../../gcc-4.7.1/gcc/d/d-objfile.cc: At global scope: ../../gcc-4.7.1/gcc/d/d-objfile.cc:996:1: warning: unused parameter ‘name’ [-Wunused-parameter] ../../gcc-4.7.1/gcc/d/d-objfile.cc:1003:1: warning: unused parameter ‘s’ [-Wunused-parameter] make[2]: *** [d/d-objfile.glue.o] Error 1
早くもなく遅くもなく。
そういやOpenGLを使用した手持ちコードがいくつかあるのですが、
新PCで動かした時、ウインドを大きくしても60fpsを維持するものの、
なんかヌルヌル動いていない気がしたり。フレームレートが落ちる
感じだと判りやすいのですが、なんとなく突っかかっているよう
に見える気がするという、説明に困る感じ。
Sleep()による時間待ちでフレームレートを維持していたのを、
Sleep()待ちを削除して、wglSwapIntervalEXT()で垂直同期を取る
ようにしたら突っかかりが無くなったり。
でもイマイチよく判らない事がひとつ。
早くもなく遅くもなく。ずぶ濡れで帰着。
ちょろりコーディング。
日付越え。
ちょろりコーディング。
昼過ぎ起床。
gdc 64bit。なんとか自力ビルドに成功。libphobosのconfigure実行で
エラーしていたのは、インストールパスに予めライブラリを用意して
いなかったから。本当はクロス環境を作る要領でgccを2回ビルドしなくては
ならない所なのかも知れませんが、TDM-GCCに
付属されるライブラリ(venix1氏のTLS修正パッチ済み)をそのまま使う事にしました。
メインラインがDMD2.059マージされたので、そろそろgcc-4.7.0をベースに
MinGW向けにもビルドできるようになってくれないかなぁ？と期待したい所。
64bit環境のlibglutの件。こちら
のコンパイル済みライブラリを使用させていただきました。
リンクは glut64.dllを直接指定する感じで。
gdc 64bitで、WinAPIバインディングを使用したところ何故かlongへのキャストがエラー
すると言っていた件。関数の引数のキャストに怒られていると思っていたのですが、
戻り値のキャストに対して怒られていたというTANEのチョンボでした(^^;
とりあえず明示的なキャストを入れてはみたものの、例えば、
C言語では#defineを使ってSendMessage()の結果をラップするようなマクロ系関数
の場合、戻り値の型はLRESULTそのままになると思うのですが、WinAPIバインディングでは
LRESULTはint型と同じとみなして、「int」を直接書いてあったりするのが
少しマズいかもと思ったりも。
gdc64 bitでコンパイルした画像表示を行う手持ちコードで、巨大画像が開けない
件。どうやらCreateDIBSection()が失敗している模様。いかんせん25000x25000
ピクセルなので、ギリギリ2GBを越えるメモリサイズが必要ではあるものの、
10GB以上空きメモリがある状況ではメモリ不足が理由ではないような。
Webで検索すると
こちら(英語)で同じ質問をしてる人が居るようですが、2GBの制限があるのだろう
という回答以上の事は得られていないみたい。でもまぁ、ディスプレイ表示に必要な
分だけあれば基本的には良いハズで、2GBを越えるならばタイリングするなりの工夫を
自分でしろって所かも知れないなぁ。
やっとこメール環境を新PCに移行。Thunderbirdを使用しているのですが、
旧PCからのメッセージ移植は
「Application Data/Thunderbird/Profiles/*/Mail/*/Inbox」をコピーすれば
OKそう。普段どこに保存されているのか意識してないと困る感じがしなくも
ありませんが、それはそれとして。で、送信メッセージの折り返し設定が
オプションなどのダイアログから変更できなくなっていたり。
「オプション→詳細の一般タブ→設定エディタ」で mailnews.wraplengthを0にすればOKでした。
プリビューできない自動折り返し(出した後に読みづらい事が判る)なんて不便でしかた無い
と思うのですが、どういう思想でデフォルト設定値を決めているのだろう？
以前知ったSVG少女なるSVGで作成したアニメ。
IE9用という事で、IE8では表示すらできませんでしたが、FireFoxやChromeではどうにか
再生できてました。で、新PCでフルHDくらいまで広げて様子を見てみたり。
結果は、IE9ではコマ落ちもしないし特に問題無し。ですが、FireFoxも特に問題無しな気が。
Chromeはローディング途中で応答無しに
なってしまったのですが、しばらく待つと一応再生されてこちらも表示には問題
が無いように思ったり。すでにベンチマークとしては負荷が足りないものに
なっているのか？
64bitでOpenGLが使えそうな感じになったので、何気にハイポリのAsianDragonを
WavefrontOBJ形式にして読み込んでみたり。まぁ、激重い感じでかろうじて表示
できればラッキーくらいの感じに思っていたのですが、表示してみたところ、
あれあれ？？リアルタイムに動かせちゃいますよ？？そんな感じになってました(^^;
ThaiStatueの方もいけるんじゃね？と思ってそちらも試してみたのですが、こちらも
リアルタイムに動かせちゃう感じ。うーむ、恐るべし。てか、POV-Rayでレンダリング
するのに、カメラ位置をあーでもないこーでもないって直していたのがアホ臭くなって
しまいましたよ(^^;;; 因みに、頂点データ等を
ファイルからメモリに読み込んで、メモリからOpenGLのモデルリストに登録して
それを表示の度にglCallList()しているという感じ。一時的にメモリに保持している
のでAsianDragonの場合でプロセスサイズが1.5GB、ThaiStatusの場合で
プロセスサイズが 2.88GBになってます。64bitじゃないと無理な感じですね。
因みに、ThaiStatueの方は像の土台の裏側に「XYZ RGB」という署名(?)が堀り刻まれて
ました。
Wings3Dで読み込ませてみましたが、32bitアプリのためメモリ割り当てができずに
Abort。64bit対応して欲しくなったかも。あ、Blenderは64bit対応版があるっぽい。
昼過ぎ起床。
gdc 64bit。自力ビルドを試しているのですがイマイチうまくいかず。
MSYSとの関係がハチャメチャになっていたのを直す事にしたり。
結局、以下のような感じにしてみたり。
日付越え前に帰着。
Fedora17。Fedora16までは何もしなくてもsshでログインできていたような
気がするのですが、Fedora17ではサービスを自分でenableにしないと
ダメらしい。ついでにCygwinの pingが
「ping: socket: Operation not permitted」なるメッセージを出して
実行できなかったのにも目くらまされて何がダメなのかすぐに判らなかったり。
CygwinのpingはWindows7のファイアーウォールに引っかかっているから
というのが原因のようでしたが、設定を変えても解決せず。ノートンに
色々阻まれている模様。しかたないので、Win7に入っているpingを使用
する訳ですが、SJIS表示で文字化けまくり。うまくいかないもんです。
遅めに帰着。
何気にVMwareのインストールを試したり。前にダウンロードした3.0.1
をインストールしてみたところ、インストールはできたのですが
Fedora17のインストールイメージの実行が途中で停止。最新の4.0.4
を取得してみたり。。で、x86_64版のFedora17 liveを試してみたのですが、
これも立ち上がらず。i686版の liveだったら立ち上がったり。
うーむ、つまらん。
遅めに帰着。
gdc 64bit。先日のコンパイルは結局失敗。32bitの方は大丈夫そうです。
OpenGL 4.xを使用する為に、GLEWのコードを手作業で移植。試す所まで到達できず。
早くもなく遅くもなく。
gdc 64bit。WinAPIのバインディングで何故かlongへのキャストがエラーすると
いう現象を調べたり。どっかでこれに関連した話を見たような？と思い出し、
検索してみたところ、これ
と同じ話だと思われるのですが、直っているようにも取れる気が。
んー、やはり自分でコンパイルしてみるか。
make の-jオプションを付けると並列コンパイルが可能になるのですが、
makeの中でconfigure実行してる場合でもうまく動くのか？と思ったり。
gdcのビルドで試してみたのですがなんとなく大丈夫な模様。ただし、
コンソールに表示されるメッセージはまぜこぜになっているので訳が
判りませんが(^^;
遅めに帰着。
gdc 64bit。GetOpenFileName()でファイルダイアログが開かない原因を調べたり。
結論から言うと、OPENFILENAMEW構造体のサイズが変更されている為。
メンバー変数が追加されているのに加えて、メンバー変数が8byteアライメント
になっていました。メンバー変数の追加は良いとして、アライメントはどうやれば
調節できるんだっけ？と調べてみたところ、「align()」というキーワードを
使えば良いらしい。ひとまずそれで調節したところ構造体のサイズがC言語で調べた
ものと同じになったので良し。コンパイルして実行してみたところ、ファイルダイアログ
を開くことができました。
流石にこのレベルの変更があちこちに必要となると、詳しい人が本気で対応してくれないと
使い物にはならないだろうなぁ。
で、手持ちの画像表示コードでも 巨大画像が開けるハズと思い、GIMPで16384x16384の
PNGとJPGファイル作成して、読み込み＆表示。OKそうだったのですが、プロセスサイズが
せいぜい1GBにしかならなかったので、これだとつまらんと思い、25000x25000のPNGとJPG
ファイルを作成して、読み込みを行ったところSegfault。一応ファイルエクスプローラの
サムネイル表示やWindowsフォトビューアーでの表示はできているので、ファイルに
異常は無いハズ。
そういや、Windowsフォトビューアーで巨大画像を表示したときの、タスクマネージャー
によるプロセスサイズなどを観察していたのですが、それっぽいサイズのプロセスが
見当たらなくて不思議に思ったり。どうやらメモリ表示に「プライベートワーキングセット」
なるものと「ワーキングセット」なるものがあり、フォトビューアーは
「プライベートワーキングセット」の方は全然増えずに「ワーキングセット」の方で
4GBとか使っていたりするもよう。
両者の違いは
こういう事
らしい。色々見られて便利です。
昼前起床。
gdc 64bit。WindowsAPIバインディングをコンパイルエラーしないように
直してみたり。色々つっかかりながらなんとなくリンクまでできたものの、
実行してみたらものの見事にヘンテコな動作になってみたり。
つっかかりどころは以下のような感じ。
昼過ぎ起床。
昨日は夜更かしして久しぶりにTOP絵用にCGを描いてみたり。といってノープランで
描き始めたラクガギですが(^^;
Eテレ版の「日常」再放送。以前に録画で観たものですが、なんとなく観てしまう。
そして笑ってしまう。そんな感じ。
そういや時々観ている東京MXなのですが、電波状態が猛烈に悪い時は映像が全く
映りません。そういえば東京スカイツリーって開業したって言ってたような？
と思ったのですが、まだ電波塔として開業している訳ではないようです。
Webで検索してみたところ、ラジオ放送はスカイツリーから送信しているようですが、
TVの方はまだという感じみたい。因みに、東京MXは物理チャンネルが20chから16chに
変更されるらしい。なので、切り替わった時には再チューニングが必要かも。
gdcの64bit版を試してみたり。MSYSとの関係がよく分からなくて自力ビルドできない
ので、ひとまず出来合いのバイナリを試してみたり。で、簡単に以下のような
コードをコンパイル＆実行。
$ cat bigmemtest.d
import std.stdio;
import std.string;
import std.conv;
int main(string[] args)
{
if( args.length != 3 ){
writef("%s num1 num2\n",args[0]) ;
return(-1) ;
}
int NUM1 = std.conv.to!(int)(args[1])*1024*1024 ;
int NUM2 = std.conv.to!(int)(args[2]) ;
version( GNU ) writef("I am GNU\n" ) ;
version( Unix ) writef("I am Unix\n" ) ;
version( Windows ) writef("I am Windows\n") ;
version( MinGW ) writef("I am MinGW\n" ) ;
version( cygwin ) writef("I am cygwin\n" ) ;
version( Win32 ) writef("I am Win32\n" ) ;
version( Win64 ) writef("I am Win64\n" ) ;
version( Posix ) writef("I am Posix\n" ) ;
int[][] buf ;
for( int i=0 ; i<NUM2 ; i++ ){
buf.length = buf.length+1 ;
buf[i].length=NUM1 ;
buf[i][]=i ;
writef("buf[%d] alloc success.\n",i) ;
}
int error=0 ;
for( int i=0 ; i<NUM2 ; i++ ){
for( int j=0 ; j<NUM1 ; j++ ){
if( buf[i][j]!=i ){
writef("Compare Error i=%d j=%d\n",i,j) ;
error++ ;
break ;
}
}
}
if( error==0 ){
ulong d = cast(ulong)(NUM1)*cast(ulong)(NUM2)*cast(ulong)(int.sizeof) ;
writef("Memory alloc success 0x%08x%08x byte.\n", (d>>>32), (d&0xffffffff)) ;
}else{
writef("Memory alloc failed.\n") ;
}
return(0) ;
}
$ gdc -v
Using built-in specs.
COLLECT_GCC=C:\MinGW64\bin\gdc.exe
COLLECT_LTO_WRAPPER=c:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.1/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-4.6.1/configure --build=x86_64-w64-mingw32 --enable-targets=all --enable-languages=c,d --enable-libgomp --enable-lto --enable-libstdcxx-debug --enable-version-specific-runtime-libs --enable-fully-dynamic-string --with-gnu-ld --disable-werror --disable-nls --disable-win32-registry --prefix=/crossdev/MinGW64/ --with-local-prefix=/crossdev/MinGW64/ --with-pkgversion=tdm64-1 --with-bugurl=https://bitbucket.org/goshawk/gdc/issues --disable-bootstrap
Thread model: win32
gcc version 4.6.1 20110627 (gdc hg r:(), using dmd ) (tdm64-1)
$ gdc -O2 bigmemtest.d
$ ./a.exe 3 1024
I am GNU
I am Windows
I am MinGW
I am Win64
buf[0] alloc success.
buf[1] alloc success.
: 中略
buf[1023] alloc success.
Memory alloc success 0x0000000300000000 byte.
昼過ぎ起床。
The Stanford 3D Scanning Repository
から更なるハイポリモデルを探してレンダリングしてみたり。.ply形式で
AsianDragonの変換プログラムがすぐに使えそうな ThaiStatueを入手。
10000000三角形ポリゴンのモデルですが、AsianDragonの1.385倍くらいの
物量なので、ちょっと物足りない気がしたりも。自作のply→POV変換
プログラムがAsianDragon専用になっていたのを直すのに時間がかかったり
しながらどうにかレンダリングできる感じに。カメラの調節に手間取り
つつ以下のような感じで。
----------------------------------------------------------------------------
Parser Time
Parse Time: 0 hours 1 minutes 28 seconds (88.031 seconds)
using 1 thread(s) with 88.031 CPU-seconds total
Bounding Time: 0 hours 0 minutes 0 seconds (0.000 seconds)
using 1 thread(s) with 0.000 CPU-seconds total
----------------------------------------------------------------------------
Render Options
Quality: 9
Bounding boxes.......On Bounding threshold: 3
Antialiasing.........On (Method 1, Threshold 0.300, Depth 3, Jitter 1.00,
Gamma 2.50)
----------------------------------------------------------------------------
Render Statistics
Image Resolution 1080 x 1920
----------------------------------------------------------------------------
Pixels: 2249713 Samples: 610821 Smpls/Pxl: 0.27
Rays: 285539534 Saved: 0 Max Level: 2/5
----------------------------------------------------------------------------
Ray->Shape Intersection Tests Succeeded Percentage
----------------------------------------------------------------------------
Mesh 495631564 153007167 30.87
Bounding Box 55408648245 15076072467 27.21
----------------------------------------------------------------------------
Shadow Ray Tests: 128414750 Succeeded: 46314167
Shadow Cache Hits: 46314103
----------------------------------------------------------------------------
Radiosity samples calculated: 565358 (42.14 %)
discarded due to low quality: 33196
retained for re-use: 532162
Radiosity samples reused: 776315
Radiosity sample rays shot: 282679000
Radiosity octree nodes: 37055
Radiosity octree samples/node: 15.26
Radiosity blocks examined: 1768774939
Radiosity blocks passed test 0: 1768774939 (100.00 %)
Radiosity blocks passed test 1: 213910629 (12.09 %)
Radiosity blocks passed test 2: 133865633 (7.57 %)
Radiosity blocks passed test 3: 1421086 (0.08 %)
Radiosity blocks passed test 4: 1266805 (0.07 %)
Radiosity blocks passed test 5: 1195541 (0.07 %)
Radiosity blocks rejected: 1767579398 (99.93 %)
----------------------------------------------------------------------------
Radiosity Depth 0 calculated: 565358 (42.14 %)
Radiosity Depth 0 reused: 776315
Radiosity Depth 0 rays shot: 282679000
----------------------------------------------------------------------------
Radiosity (final) calculated: 542707 (41.14 %)
Radiosity (final) reused: 776311
Radiosity (final) rays shot: 271353500
----------------------------------------------------------------------------
Pass Depth 0 Total
----------------------------------------------------------------------------
1 30 30
2 119 119
3 464 464
4 1992 1992
5+ 20046 20046
Final 542707 542707
----------------------------------------------------------------------------
Total 565358 565358
Weight 0.600
----------------------------------------------------------------------------
Peak memory used: 1867735040 bytes
----------------------------------------------------------------------------
Render Time:
Photon Time: No photons
Radiosity Time: 0 hours 0 minutes 12 seconds (12.371 seconds)
using 8 thread(s) with 83.799 CPU-seconds total
Trace Time: 0 hours 5 minutes 39 seconds (339.161 seconds)
using 8 thread(s) with 2373.037 CPU-seconds total
----------------------------------------------------------------------------
CPU time used: kernel 4.54 seconds, user 2545.20 seconds, total 2549.74 seconds.
Elapsed time 441.79 seconds, CPU vs elapsed time ratio 5.77.
Render averaged 4693.61 PPS (813.26 PPS CPU time) over 2073600 pixels.
昼前起床。
ファイルコピー。そういや、昨日から新PCのHDDから妙な音がしている気が。
それと連動するかのように、昨日は一度画面がブラックアウトした為、
強制電源切断しました。また、夜の間にファイルコピーしていたのですが、朝静かに
なってると思ったらブラックアウトしてたり。二度目の強制電源切断。
うーむ、これがHP品質なんだろうか？と若干の心当たりになんとなく納得。
ファイルのコピーに時間がかかり過ぎ。気づくと数GB単位のディレクトリ
だったりするあたり、ネットワーク越しに100Mbpsを通すんじゃ細すぎる
なぁと思ったりも。PCtoPCはGbitじゃなきゃダメかも。とは言え、我が家の
Gbit機器は新PCとPS3だけなのですが(^^;
旧PCで試したAsianDragonのシーンファイルのレンダリングを試してみたり。
ファイルをどっかやってしまっててバックアップから探す所から始まったので
時間がかかってしまいました(^^; で、8CPUでレンダリングした結果は
以下の通り。
----------------------------------------------------------------------------
Parser Time
Parse Time: 0 hours 1 minutes 2 seconds (62.137 seconds)
using 1 thread(s) with 62.135 CPU-seconds total
Bounding Time: 0 hours 0 minutes 0 seconds (0.000 seconds)
using 1 thread(s) with 0.000 CPU-seconds total
----------------------------------------------------------------------------
Render Options
Quality: 9
Bounding boxes.......On Bounding threshold: 3
Antialiasing.........On (Method 1, Threshold 0.300, Depth 3, Jitter 1.00,
Gamma 2.50)
----------------------------------------------------------------------------
Render Statistics
Image Resolution 1024 x 768
----------------------------------------------------------------------------
Pixels: 835584 Samples: 566793 Smpls/Pxl: 0.68
Rays: 1402377 Saved: 0 Max Level: 1/5
----------------------------------------------------------------------------
Ray->Shape Intersection Tests Succeeded Percentage
----------------------------------------------------------------------------
Mesh 3038916 1086800 35.76
Bounding Box 238945767 68363935 28.61
----------------------------------------------------------------------------
Shadow Ray Tests: 950620 Succeeded: 191773
Shadow Cache Hits: 191757
----------------------------------------------------------------------------
Peak memory used: 1254969344 bytes
----------------------------------------------------------------------------
Render Time:
Photon Time: No photons
Radiosity Time: No radiosity
Trace Time: 0 hours 0 minutes 1 seconds (1.217 seconds)
using 8 thread(s) with 8.748 CPU-seconds total
----------------------------------------------------------------------------
CPU time used: kernel 2.00 seconds, user 70.01 seconds, total 72.01 seconds.
Elapsed time 64.77 seconds, CPU vs elapsed time ratio 1.11.
Render averaged 12142.48 PPS (10921.14 PPS CPU time) over 786432 pixels.
AM中に起床。
PCが届くまでの間もそもそと片付け。電源が足りなかったり建増し続けて
配線がゴチャゴチャになっているのを直したり。ひとまず受け入れ可能な
状態に。ふぅ。
昼頃PC到着。箱から取り出し。んー、なんかデカっ。そしていくつか失敗。
現在メインで使用しているPCのディスプレイはPC入力として2系統入力できる
のですが、両方ともDVIだと思っていたのが RGBとDVIの二系統だったり。
FedoraPC用のディスプレイが幸いにもDVI入力可能だったので、旧PCはそちら
につないで、新PCを現在のディスプレイに接続する事で落ち着いたり。
旧PCは1920x1200→1440x900になるので、当然の様にデスクトップアイコンの
配置がハチャメチャに。まぁ仕方なし。
説明書らしい説明書が特に無く、電源オンでなんとなく促されるままに設定
を進めて起動。さて、操作感がWindowsXPと全然違うので、要領が得られません。
リカバリディスクも無しというタイプなので、とりあえずリカバリディスクを
作成しながら、あれこれ触って少し要領を得てみたり。それにしても、
何かこれといったものをやっている訳でもないのに、メモリを2GBも使っている
のが納得いかない。
Cygwinを最小インストールして、作成されたhomeディレクトリの下にWinXPから
ファイルをコピー。最初共有ファイルを認識できなくて、
Web検索しながら進める感じに。ネット接続ができないと死ぬ所です(^^;
ひとまずMeadowといくつかのツールをインストールしてなんとなく使えるように
なってみたり。先日のキーレイアウト変更の件は
ChangeKey
なるフリーソフトで解決。管理者権限で実行するというのは、今後ちょくちょく
使わなくてはならない技になりそうな予感。
そんな訳でスペックを少し見られる感じになったかも。
CPUは i7-3770K(3.50GHz)でメモリは16GB。割高な分メモリが余計に載ってます。
グラフィックは外付けのNVIDIA GeForce GTX550Ti。内蔵GPUは封印されてる(?)模様。
OpenGL4.1.0なのでちょっと楽しみです。
で、色々試したり。X68k時代からレンダリングを試している、
「天空ギア」のPOV-Rayシーンファイル。
一つ前のPC(Pentium4(3.06GHz))では41秒でレンダリング完了した
ものです。計ってみたみたところ、1CPUでは11.14秒、8CPUでは2.469秒.......
ぇぇぇえ〜〜〜〜？！ そんな感じ。CPUの周波数は17.6%しか上がっていない
ので、1CPUで4倍くらい早いのはソフトのチューニングが含まれているかも知れません。
8CPUで4.51倍しか高速にならないのは、半分はHTなのでコア数分の4倍以上はなかなか
出ないという感じなのでしょうか。X68kで30時間かけてレンダリングしてたのにね....(遠い目)。
手持ちコードを動かしてみたり。でも色々ハマりまくってみたり。
AM中に起床。
突然思い立ちPCを新調することに。事前にめぼしは付けつつ、ヨドバシで現物確認＆調達。
今やデスクトップとなるとTVと一体になったものが主流のようで、これまで通りの
デスクトップPCとなると店頭ではあまり選択肢が無いという感じ。
SOTECっ子だったTANEですが、現在はONKYOブランドに吸収されちゃいました。
そのONKYOのも置かれていなかったのと、狙い目の実装を行ったマシンがそれしか
無かった事から、今回はHPのにしてみました。TANEには少しオーバースペックな感じ
なのですが、足りなかった場合に後からどうにかする方がコスト高になるという
経験則から大決定という事で。
16万円也とちょっと高い買い物でしたが、ポイント約4万円分を全額開放して
12万円でゲット。明日配送という事で詳しいスペックなどはまた後日。
帰ってからPC配置の為に掃除したり。
そういや、CAPSとCNTLキー、ESCと半角全角キーはそれぞれ配置が逆じゃないと
死にそうになるのですが、Windows7ではAltIMEの動作が微妙な感じらしい。
また、レジストリをいじるのも「なんかよくわからんがこうやれば良いらしい」的な
のしか出てこなくてちょっとだけ困りそう。で、調べている過程で知ったの
ですが、AltIMEの作者さんは故人となっているようです。
夜もいい時間にアニメ映画であるところの「REDLINE」のBDを観たり。
ストーリーらしいストーリーはあまり無くて、とにかくアクションを見て楽しむ
という感じ。レースなのに途中で訳のわからないクリーチャーが出てきたりと
ハチャメチャな感じでしたが、最後まで一気に見ちゃうという感じでした。
それにしても、絵がスゴく細かいです。これ、色を塗り分けるの大変だよなぁと思ったり。
AM中に起床。今日から一週間ほど連休。
ちょろり遠くの本屋に。
「バクマン(19)」。(18)ってついこの前出たばかりだと思ったのですがもう(19)？
もうあと少し続く感じかな？
WIN32APIでボタンに画像を貼る件。結局、色々つぶしがきかないという理由に
より、自作ボタンを機能強化するという方向に落ち着いたり。
元々は、ボタンの画像を外付けのファイルではなくリソースに含める練習でした。
ただし、BMPファイルではなくPNGファイルを
リソースに埋め込み、それをアルファ付きで展開してボタンに貼り付けると
いう事がやりたかったのです。
おおよそやりたい事はできたのですが、WinAPIだけだとアルファの扱いがイマイチ
だったのと、オーナードローは親ウインドにメッセージがいちいち飛ぶという
点も扱いづらいことから、自作ボタン強化でいいやという流れ(^^; うーむ。
AM中に起床。
WIN32APIでボタンに画像を貼る件。BS_BITMAPを使わないとするならば、
オーナードローかカスタムドローを使う事になる模様。オーナードローは
ボタンの概観も含めて全ての描画を自前で行う必要がある自前描画方式で、
カスタムドローはボタンの概観描画が終わった状態で追加で必要な部分を
自前で描画する方式の様です。スタイルを合わせるならば、後者のカスタム
ドローの方が良いのだろうと思って試すのですが、カスタムドローの
書き換え契機となるWM_NOTIFYがやってきません。どうやら、XPビジュアルスタイル
にしていないと WM_NOTIFYがそもそもやって来ないようで、XPビジュアルスタイルに
するとWM_NOTIFYがやってくるようになりました。
XPビジュアルスタイルより前でのボタンにはカスタムドローという概念が無い
かのような振る舞い(従ってWM_NOTIFYがやってこない)になってるような気も。
逆に、XPビジュアルスタイルではボタンにマウスカーソルが重なっただけでも
WM_NOTIFYがやってくるようでこれはこれで過剰な気も。
いずれにしてもカスタムドローはコーディング方法に前方互換が無いのが
少し困った感じかも。
昼過ぎ起床。
自転車がパンクしていたのを修理に持って行ったり。
WIN32APIでボタンにBS_BITMAPスタイルを使って画像を貼り付ける練習をしてました。
で、何気にXPビジュアルスタイルでの表示を見てみたところ、BS_BITMAPなボタンだけ
がクラシックな表示のままとなり、なんで？と思ったり。
Web検索してみたところ、なにやらそういうものらしいという事は判ったのですが、
んじゃどうすればXPビジュアルスタイルのボタンに絵を貼れるの？という話になると
イマイチ具体的な方法を見つける事ができなかったり。
日付け越え前に帰着。
ちょろりコーディング。
眠くて急速停止。
