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.

  • $\begingroup$ 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. $\endgroup$
    – user320
    Commented Oct 3, 2013 at 15:26
  • 1
    $\begingroup$ 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. $\endgroup$
    – wchargin
    Commented Oct 9, 2013 at 13:27
  • 1
    $\begingroup$ 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. $\endgroup$ Commented Feb 17, 2018 at 10:14
  • $\begingroup$ @nigratruo nice Addon indeed! $\endgroup$
    – derHugo
    Commented Jul 9, 2018 at 8:33

6 Answers 6


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


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


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


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.

  • $\begingroup$ 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. $\endgroup$
    – CodeManX
    Commented Oct 3, 2013 at 14:56
  • 2
    $\begingroup$ Blender guru did a similar test. blenderguru.com/wp-content/uploads/2012/11/… $\endgroup$
    – user320
    Commented Oct 3, 2013 at 15:44
  • $\begingroup$ @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. $\endgroup$
    – Greg Zaal
    Commented Oct 4, 2013 at 15:47
  • $\begingroup$ @gandalf3 Could you expand on this answer since my updated question? Including GPU and Cycles results. $\endgroup$
    – Greg Zaal
    Commented Oct 4, 2013 at 15:48
  • $\begingroup$ @GregZaal I don't have a cycles GPU (yet), but I'll update this $\endgroup$
    – gandalf3
    Commented Oct 4, 2013 at 19:51

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)

  • 1
    $\begingroup$ 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. $\endgroup$
    – Mike Pan
    Commented Oct 4, 2013 at 22:50
  • 2
    $\begingroup$ 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. $\endgroup$
    – brecht
    Commented Oct 7, 2013 at 0:44
  • 2
    $\begingroup$ 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. $\endgroup$
    – brecht
    Commented Oct 7, 2013 at 0:50

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.


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.

  • $\begingroup$ 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. $\endgroup$ Commented Feb 17, 2018 at 10:17

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
    $\begingroup$ Default scene isn't particularly useful, there's no real overhead of geometry. Also, is this for BI or Cycles? $\endgroup$
    – Greg Zaal
    Commented Oct 4, 2013 at 12:00
  • 1
    $\begingroup$ This is BI. Do you have s scene you want me to test? $\endgroup$
    – user320
    Commented Oct 4, 2013 at 12:38
  • $\begingroup$ 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. $\endgroup$
    – Greg Zaal
    Commented Oct 4, 2013 at 15:42

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.

  • $\begingroup$ 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). $\endgroup$
    – gandalf3
    Commented Jun 19, 2014 at 7:08
  • $\begingroup$ indeed, but because I found this thread usefull during my performance quest, I thought I had to share my discovery. $\endgroup$ Commented Jun 20, 2014 at 9:27
  • $\begingroup$ 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! $\endgroup$
    – Greg Zaal
    Commented Jun 20, 2014 at 12:16
  • $\begingroup$ 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. $\endgroup$ Commented Feb 17, 2018 at 10:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .