No 32bit version of lucille?

by syoyo

そういえば, prman を 1GB のメモリの 32bit linux マシンで動かし、armadillo シーンをレンダリングしてみました.

armadillo シーンは以下のリンクのやつです. 140 万ポリゴンほどのシーンをレイトレ AO でレンダリング.
http://lucille.atso-net.jp/blog/?p=780 )

…が、prman だとレンダリングできない!
(正確にはアホみたいにレンダリングがかかる. 1 時間くらいかかりそうなので途中でやめた)
しかし同じく 1GB メモリの 64bit linux だと 2 分くらいでレンダリングできました.

3Delight8.5 は同じ条件(1GB, 32bit)で 1 分くらいで出来ました. やるな 3Delight.
(上記リンクでの 3Delight 8.0 は 4 分くらいだったのですが、 8.5 でレイトレ周りがかなり高速化されています. まあまだ lucille(未最適化) が勝ってみますが)

たぶん 32bit だとメモリマネージがうまくできていなくてメモリのスワップがガンガン発生しているんでしょうね.
実際 prman のメモリ使用量の統計表示では 950 MB くらい消費していました.
こちらで適切に renderman.ini でメモリ量を指定できていないのかもというのもありますが.
(でもそれなりのソフトなら使用メモリ量はシステムプロパティとか見て自動調整してほしいところ)

まあレイトレ使っているからメモリ不足でレンダリングできないというのは実装側の怠慢みたいなもので、
レイトレだからと言っても、レンダラ側でうまく out-of-core 処理などを取り入れてメモリマネージメントすればいいわけです.
(実際、lucille はそうします)

とはいうものの、32bit で out-of-core なメモリマネージメント処理を 1 からソフト側で頑張って実装するよりも、
64bit でとりあえず CPU(の MMU) に任せてある程度 out-of-core 処理させるのが早いし、
レンダラ側も実装するコード量は少なくていいです.

もちろん、64bit だからレンダラ側でメモリマネージメントがいらないというわけではなく、
大規模シーンをきちんとレイトレでレンダリングするにはやはりレンダラ側である程度のメモリマネージメントは必要になります.

そんなわけで、そろそろレンダラの 32bit 対応は切り捨ててしまってもいいと思うんですよね.
レンダリングは 64bit に比べてどうしても遅くなるし、レンダラを書く側の負担も増える.

最近は 64bit 環境もそれなりに普及してきてアプリの対応もそれなりですし、
メールや web などの通常の PC 利用でもメモリ使用量はどんどん増えてきていて 4 GB の壁に突き当たる時期にきている.
映像制作などはガンガン計算資源使うので、言わずもがな.
クライアント PC は 32bit もあるかもしれませんが、
レンダーサーバーが  32bit ですというのは、今はあまりないんじゃないでしょうか.

というわけで、特にこれからのレンダラであれば、「64bit でしかうごきません!」というのもアリではないかと思います 🙂

# とはいえ、他ソフトの連携も考えると、まだまだ 32bit も必要ですかね.
# その場合はひっそりと「32bit にも対応しています」とする方向で 🙂

Advertisements