10

There've been a few discussions about tile sizes for Cycles, but none that I can find about that of BI. Since it renders with the CPU, does it follow the same rule as cycles where smaller is better (to an extent of course)?

I'm sure it depends a lot on the content of the scene, so in what case are bigger tiles better than smaller ones, other than the general GPU/CPU rule.

Is it more important to stick to powers of 2 (32,64,128...) than it is to keep all tiles the same size?

The differences between render times are often very small, so perhaps a good test would be to render an animation (with a moving camera) and average the times.

I've created an addon that figures out the best size for Cycles and I'd like to extend this to BI as well, though I've not used the renderer for quite some time.

Greg Zaal
  • 10,856
  • 3
  • 47
  • 86
  • I think tiles are best render at perfect squares e.g 64x64. If the resolution does not fit nicely into one of those perfect squares then two of the sides (eg. top and bottom) should be shrunk/scaled as needed. –  Oct 03 '13 at 15:26
  • 1
    See also 4 Easy Ways to Speed Up Cycles, tip #3. I've had significant (30-40%) increases using those or similar values, though it varies from scene to scene, on a GTX 680. – wchargin Oct 09 '13 at 13:27
  • 1
    This concerns cycles only: Tile size can vary widely and has to be changed for optimal performance (if you change resolution or render device). So use the "Render: Auto Tile Size" Addon that comes with Blender. It sets size automatically and takes away the work and guessing. I don't know why this isn't switched on by default. – Markus Bawidamann Feb 17 '18 at 10:14
  • @nigratruo nice Addon indeed! – derHugo Jul 09 '18 at 08:33

6 Answers6

11

I would say it depends a lot on the scene and the hardware.

BI:

Some tests rendering the default cube scene at 960x540 pixels:

Tile size: 32x32 Render time: 00:01.02

Tile size: 64x64 Render time: 00:00.89

Tile size: 128x128 Render time: 00:00.86

Tile size: 256x256 Render time: 00:00.87

Tile size: 512x512 Render time: 00:01.27

A more complex scene at the same resolution seems to go faster with larger tile sizes:

Tile size: 32x32 Render time: 01:53.57

Tile size: 64x64 Render time: 01:46.15

Tile size: 128x128 Render time: 01:45.26

Tile size: 256x256 Render time: 01:43.22

Tile size: 512x512 Render time: 01:43.09

Using the same scene at 960x540, I roughly timed the amount of time it took to render one tile. (This estimate is very rough because the time changes dramatically between different tiles, I just timed one tile):

Tile size: 120x67 Render time: 02:23.89 (approx. 12 seconds per tile)

Tile size: 64x64 Render time: 02:33.31 (approx. 6 seconds per tile)

Tile size: 300x300 Render time: 02:24.60 (approx. 30 seconds per tile)

Tile size: 200x200 Render time: 01:49.57 (approx. 10 seconds per tile)

Tile size: 100x100 Render time: 01:42.43 (approx. 14 seconds per tile) (fastest)

The fastest time here has the same settings as the slowest setup for cycles:

At 500x500:

Tile size: 128x128 Render time: 00:41.53 (fastest)

Tile size: 100x100 Render time: 00:41.92

At 512x512:

Tile size: 100x100 Render time: 00:43.67

Tile size: 128x128 Render time: 00:47.84

Cycles:

Using Mike Pan's famous BMW benchmark scene at 960x540 with 10 samples:

Tile size: 64x64 Render time: 01:51.03

Tile size: 100x100 Render time: 02:02.03

Tile size: 128x128 Render time: 01:49.64

Tile size: 200x200 Render time: 02:00.39

Some tests to see how much varying sizes and using powers of two affect render time:

At 500x500 px:

Tile size: 100x100 Render time: 00:46.86

Tile size: 128x128 Render time: 00:53.42

At 512x512 px:

Tile size: 128x128 Render time: 00:50.54

Tile size: 100x100 Render time: 00:49.46

Conclusions:

To find a general rule for deciding optimal tile sizes for any kind of scene, one needs a lot more testing data with long renders etc. To really look at this in detail, I think some addon which would send tile settings and render times to a database would be necessary.
IMO, Setting the tile size to ~100x100 or ~200x200 and adjusting to fit evenly in the render dimensions is good enough.

However, from the tests I did above it does seem that maintaining a consistent tile size helps.
Power of two tile sizes seem to have no apparent effect.

gandalf3
  • 157,169
  • 58
  • 601
  • 1,133
  • Larger seems better on CPU, and that's probably 'cause GPUs got hundreds of units and CPUs only a few cores. Theoretically, 1 tile per CPU core (maybe +1 to ensure all computational power is used) give best render time, whereas a GPU should perform best with hundred(s?) of tiles. – CodeManX Oct 03 '13 at 14:56
  • 2
    Blender guru did a similar test. http://www.blenderguru.com/wp-content/uploads/2012/11/blender_tile_sizes_chart2.png –  Oct 03 '13 at 15:44
  • @CoDEmanX, sounds like a logical theory but in reality it's the opposite. A GPU (despite having hundreds of cores) only renders one tile at a time. Bigger tiles gives faster renders. For CPUs (many threads) smaller tiles are quicker. – Greg Zaal Oct 04 '13 at 15:47
  • @gandalf3 Could you expand on this answer since my updated question? Including GPU and Cycles results. – Greg Zaal Oct 04 '13 at 15:48
  • @GregZaal I don't have a cycles GPU (yet), but I'll update this – gandalf3 Oct 04 '13 at 19:51
  • I am not sure but I do not think there is one equation where you can plugin geo, textures, etc. and get the optimal tile size –  Oct 06 '13 at 11:54
  • Not exactly what I was hoping for, but better than the other answers. Here's your bounty. – Greg Zaal Oct 10 '13 at 17:37
  • I guess you need to take cache misses into account when tiles becomes large. – user877329 May 19 '15 at 13:27
  • @gandalf3 I wonder, what would happen if tile size is larger than resolution? Would be be set to the image resolution automatically during rendering? – Amir Mar 07 '18 at 23:44
  • In one case (100 vs 128 in 960x540 Cycles render) the power-of-two tile size reduces render time by 10%, and in another (500x500 render) it increases by 14%. While that isn't systematic, I would suggest it is at least an apparent effect. – SO_fix_the_vote_sorting_bug Apr 04 '18 at 22:14
  • @Amir Yes, that's what happens. – gandalf3 Apr 07 '18 at 20:14
9

Think of the number of tiles as the number of parallel tasks that the computer splits the rendering into.

  • If the tile size is too big (too few tiles), then the CPU/GPU gets starved because there are more available computing power that's not being used.

  • If the tile size is too small (too many tiles), then the overhead of switching tiles becomes a bottleneck. That's why 1x1 tile is not a good idea, even on a GPU with a gazillion cores.

  • The problem is CPU and GPU behave differently, a \$200 CPU might have 4 cores, but a \$200 GPU could have 100+ cores. So this is why optimal tile size for CPU and GPU are different.

In practice, I find that tile size of 100x100 to 200x200 works well in almost all cases. (I find no evidence that pow2 values perform better)

Scott Milner
  • 4,473
  • 1
  • 22
  • 41
Mike Pan
  • 11,990
  • 1
  • 37
  • 58
  • 1
    A Geforce 760 (a $250 USD card) has some one thousand 'cores'. Although I don't think that translates to 1000 logic cores because GPU cores work in some kind of thread blocks. The point is, GPU is still much more parallelized than a comparable CPU. – Mike Pan Oct 04 '13 at 22:50
  • 2
    For each tile, Blender internal will loop over all objects, and if the object bounding box overlaps the tile, all polygons or hairs in that object. – brecht Oct 07 '13 at 00:44
  • 2
    This is potentially slow on high poly scenes.

    That's the main difference with Cycles CPU rendering when it comes to performance, both Blender Internal and Cycles have some constant per tile overhead, but only Blender Internal has overhead that depends on scene complexity. So generally you have to be more careful in not making tiles too small with Blender Internal when it comes to CPU rendering.

     – brecht Oct 07 '13 at 00:50
1

I would add that all though the graphic card has more cores and can therefore manipulate more data at once than a CPU the limiting factor is the graphic cards memory. So the size of the tile should be less than the cards memory but as close to it as possible.

The computers bus is the limiting factor as the system Ram is generally slower than that of the graphic card.

There is no definitive size but a rule of thumb I use is about four times larger for GPU than CPU.

A final important thing is the tile size should be an equally divisible fraction of the overall rendered image, so all tiles are doing equal work. Having smaller tiles left over take the same time effectively and are wasteful.

Mark B Tomlinson
  • 999
  • 1
  • 8
  • 16
1

My experience with one of my scenes: A lot of lights, 1920x1080 CPU rendering (my 8 cores processor is faster than my GPU PNY Quadro K4000), Cycles, an animation without geometry changing, only a camera move, compositing.

  • Its simple: the smaller the faster. 16x16 is always faster for me. Render tiles from center or top to bottom is equal.

  • In a scene with an alpha area (a masked part for example), rendering tiles from top to bottom is faster.

Eddy Juillerat
  • 81
  • 8
  • Please remember that any GPU will give you very bad results with a 16x16 tile size, as CPU needs them small, GPU needs them big. Use Auto Tile Size Addon which does this automatically, you might get better render results like this. – Markus Bawidamann Feb 17 '18 at 10:17
0

I discovered that the fastest way to render may be to simply disable the preview, by using the "Keep UI" option for display parameter, or even to render using the command line.

In fact, when you render into the image editor, histograms and curves updates use some CPU, each time a tile is updated. It's more obvious when you render a big image (4096x4096) and try to show / hide the "tool shelf".

And if the same tile takes a long time to render, blender performs several times the color conversion from float point value layers to 24 bits RGB screen space (the color management), each time it's updated in the image editor.

Edgard Neuman
  • 1
  • 1
  • Welcome to the site :) While your answer contains some useful information for increasing render performance in general, it doesn't really the answer the question (namely, what is the most optimal tile size). – gandalf3 Jun 19 '14 at 07:08
  • indeed, but because I found this thread usefull during my performance quest, I thought I had to share my discovery. – Edgard Neuman Jun 20 '14 at 09:27
  • Indeed you're right, having the toolbar open significantly reduces render time (especially render rendering things from the VSE), but as the wizard says, it's not quite related to the question. Thanks for sharing though! – Greg Zaal Jun 20 '14 at 12:16
  • How do you switch off the render preview? I wish I could do that, I'm rendering 4K and it is slower than it should be and the CPU is maxed out during GPU rendering, which is very strange, I don't have anything that needs the CPU, no particle systems, no physics, just a static scene of one frame.Also, I don't see all tiles, most of them are hidden, the render preview is zoomed in and totally useless like this. I'm rendering VR with Stereo (two renders for one frame), maybe this is an issue. – Markus Bawidamann Feb 17 '18 at 10:44
0

I also did some testing and this are my results. I only did the test for the CPU. Default scene 1920x1080

60x60    00:05.02
63x63    00:04.89
64x64    00:04.60
65x65    00:04.71

100x100  00:02.60
127x127  00:01.99
128x128  00:01.96
129x129  00:01.97

255x255  00:01.36
256x256  00:01.33
257x257  00:01.33
300x300  00:01.21

500x500  00:01.19
511x511  00:01.13
512x512  00:01.00
512x513  00:01.01

1000x1000 00:01.32
500x400   00:00.93
  • 2
    Default scene isn't particularly useful, there's no real overhead of geometry. Also, is this for BI or Cycles? – Greg Zaal Oct 04 '13 at 12:00
  • 1
    This is BI. Do you have s scene you want me to test? –  Oct 04 '13 at 12:38
  • Anything and everything. The purpose of this question is to find what is quickest where and why, not for any scene in particular but for all scenes. This is a lot to ask, I know, hence the 250 bounty. – Greg Zaal Oct 04 '13 at 15:42