Tiles による分割数と、GPU/CPU によるレンダリング時間の相関関係を調べたのでまとめます。
注意:
このテストは Blender v2.64 で行っております。
Blender v2.65 ではタイルの設定方法が分割数ではなく、サイズをピクセル指定するようになっております。
テスト環境
- PC
- CPU: Xeon E3-1235
- GPU: Quadro 2000
- OS: Windows7x64
- RAM: 16GB
- Image
- Resolution: 500x500
- Samples: 1000

この環境で、Tiles を 1x1 から 2x1, 2x2, 3x2, 3x3 と、X と Y それぞれ 1 ずつ増やしながらレンダリング時間を比較。
ただし、各条件でレンダリングは 1 度しかしていないので、多少の誤差はあると思います。
GPU レンダリング
Tiles (XxY) |
開始時 Tile |
RenderTime MM:SS |
比較 MM:SS |
1x1 |
1/1 |
09:02.56 |
基準 |
2x1 |
1/2 |
08:52.39 |
-00:10 |
2x2 |
1/4 |
08:47.44 |
-00:15 |
3x2 |
1/6 |
08:56.58 |
+00:06 |
3x3 |
1/9 |
09:12.26 |
+00:10 |
4x3 |
1/12 |
09:12.22 |
+00:10 |
4x4 |
1/16 |
09:29.69 |
+00:27 |
5x4 |
1/20 |
09:53.63 |
+00:51 |
5x5 |
1/25 |
10:32.43 |
+01:30 |
6x5 |
1/30 |
10:17.02 |
+01:15 |
6x6 |
1/36 |
10:54.92 |
+01:52 |
7x6 |
1/42 |
11:35.68 |
+02:33 |
7x7 |
1/49 |
12:13.68 |
+03:11 |
8x7 |
1/56 |
10:12.68 |
+01:10 |
8x8 |
1/64 |
10:45.92 |
+01:43 |
9x8 |
1/64 |
10:49.99 |
+01:47 |
9x9 |
1/64 |
10:45.81 |
+01:43 |
レンダリング時間に関して
分割を増やすことでレンダリング時間を短縮できたのは、今回のテスト環境では 2x1, 2x2 のみ。
それ以上は分割すればするほどレンダリング時間が長くなる傾向がある。
このことから、GPU レンダリングを行う場合は、メモリが許す限り分割数を抑えるのが望ましい。
これは、実行する PC の環境で異なると思われますので参考程度に。
同時にレンダリングするタイル数に関して
GPU レンダリングがの場合、タイルがいくつになっても 1 タイルずつしかレンダリングしない。
ただし、マルチ GPU の場合どうなるかは不明。GPU 毎にレンダリングしてくれそうな気はする。
タイル数が 64 で頭打ちになった件に関して
Resolution: X500 に対して、Tiles: X8 までは設定通り分割されたが、8 より増やしてもタイルは増えなかった。
このことから、1 つのタイルが、あるサイズよりも小さくならないように分割数を制御していると想定。
で、最低サイズを探ろうと、Tiles: 100x100 を指定して 10000 分割されなくなる Resolution を探ってみたところ、Resolution: 6337x6337 で 10000 分割されるが、6336x6336 では 9801 分割となったので、最低サイズは 63.37 と想定。
しかし、ピクセルに端数は無いので、一辺のサイズが 63 と 64 で計算されていると想定。
テストの Resolution 500 でも 8 で割ると 62.5 なので、62 と 63 で計算されていると想定。
このことから、タイルの一辺のサイズが約 63 以上になるように、Tiles 数を自動制御していると想定。
さらに、Tiles 2 で分割できる最低 Resolution を探ったところ、Resolution 64 までは 1/2 と分割が可能だったが、Resolution 63 で 1/1 となった。
この場合、タイルの一辺は 32 ということになり、先に想定した約 63 より大きく乖離した。
これらのことから、Resolution サイズによって、Tiles の最低サイズが変わってくるが、とにかく 1 つのタイルがあるサイズよりも小さくならないように分割数を制御していることは分かった。
CPU レンダリング
Tiles (XxY) |
開始時 Tile |
CPU 最大負荷 |
RenderTime MM:SS |
比較 MM:SS |
1x1 |
1/1 |
13% |
120:07:40.52 |
+101:24 |
2x1 |
2/2 |
26% |
60:05:56.43 |
+39:40 |
2x2 |
4/4 |
52% |
36:33.92 |
+10:18 |
3x2 |
6/6 |
77% |
29:57.43 |
+03:41 |
3x3 |
9/9 |
100% |
26:16.41 |
基準 |
4x3 |
9/12 |
100% |
29:25.65 |
+03:09 |
4x4 |
9/16 |
100% |
25:54.61 |
-00:22 |
5x4 |
9/20 |
100% |
28:09.03 |
+01:53 |
5x5 |
9/25 |
100% |
25:19.37 |
-00:57 |
6x5 |
9/30 |
100% |
25:36.93 |
-00:39 |
6x6 |
9/36 |
100% |
25:24.53 |
-00:52 |
7x6 |
9/42 |
100% |
25:10.41 |
-01:06 |
7x7 |
9/49 |
100% |
25:05.87 |
-01:11 |
8x7 |
9/56 |
100% |
25:04.76 |
-01:12 |
8x8 |
9/64 |
100% |
25:20.73 |
-00:56 |
9x8 |
9/64 |
100% |
25:26.41 |
-00:50 |
9x9 |
9/64 |
100% |
25:11.73 |
-01:05 |
レンダリング時間に関して
分割数が CPU のスレッド数を超えさえすれば、レンダリング時間にそれほど違いは出てこないことが分かった。
GPU によるレンダリングでは分割数が増えるとレンダリング時間も長くなる傾向があったが、CPU によるレンダリングでは分割数を上限まで増やしても時間は短縮される可能性が高まる。
CPU によるレンダリングの場合、分割数は最低でもスレッド数 +1 になるようにし、多ければ多くて構わない。
ただし、GPU によるレンダリングが可能なのであれば、分割数を抑えて GPU でレンダリングした方が速いことも分かった。
同時にレンダリングするタイル数に関して
CPU スレッド数が 8 の PC にてテストしたが、最大同時 9 タイルのレンダリングを行なっていた。(理由は不明。。。)
それ未満の分割数だと、すべてのスレッドが使われないため、レンダリング時間もその分延びることとなる。
CPU にてレンダリングする場合、最低でもスレッド数 +1? にはした方が良い。