17
$\begingroup$

The general wisdom is "for CPU use 32x32 tiles, for GPU use 128x128 or bigger, depending on your card". But why?

Why should a CPU need much smaller sizes than a GPU? I know this has something to do with CPUs doing multiple tiles at a time, but I still don't see how this effects tile size choice.

Why does tile size even effect render times at all? Isn't cycles tracing the same number of samples no matter what?

So how should I determine what tile size I should use?

I am looking for a technical answer as to how tile size effects performance and why different hardware should have radically different tile sizes.

$\endgroup$
  • 4
    $\begingroup$ There's an add-on that automatically calculates this for you. "Auto Tile Size" it is included in Blender's packaged add-ons. $\endgroup$ – zeffii Jan 6 '16 at 19:20
  • $\begingroup$ @zeffii Yea, I am aware of that, I even use it on my main workstation PC. However it seems to just do 32x32 for CPU and some multiple of the aspect ratio for GPU. I am looking for why tile size influences performance so I can figure it out myself. $\endgroup$ – PGmath Jan 6 '16 at 21:57
  • 2
    $\begingroup$ @Brecht added some comments here: blender.stackexchange.com/questions/3120/… $\endgroup$ – stacker Jan 6 '16 at 22:42
  • $\begingroup$ I heard the reverse of that advice somewhere. Use small tiles for GPU for maximum parallelization, and use bigger tiles for CPU to utilize the CPU cache which works best with long horizontal lines. $\endgroup$ – HalfKiloByte Jan 7 '16 at 0:06
  • $\begingroup$ @HalfKiloByte The GPU only traces one tile at a time; it traces individual rays in parallel. So small tiles end up giving it fewer rays to do at once. AFAIK the CPU traces one ray at a time (per core), but each core gets it's own tile. $\endgroup$ – gandalf3 Jan 7 '16 at 1:10
18
+100
$\begingroup$

The difference and why there are different optimal bucket sizes comes from the size and design of on chip cache/memory of cpu or gpu.

  • The gpu has a massive amount of cores. But they are dumb and cannot do much logic. They have a big data throughput though - so that's why is good to give them a big chunk of data. There will be a lot of parallelization done on that data and each core will do it's dumb thing over and over again till it's done. The parallelization happens internally in gpu, so in reality you would have to assign like 2x2 or 4x4 tile to each of those little cores, but you would have 3000 of those tiles. But since they share cache/vram, you assign a big tile to them. Therefore the more CUDA cores, the bigger tile. It's worth noting that Kepler, Maxwell or Pascall cuda cores are not equal, so it's best to test the ideal tile size between generations.

    When mixing different gpus (if you must), it's generally best to go with the tile size of the least powerfull one. Many commercial renderers divide the last tile into smaller ones, so the cores/gpus that are finished can still render. This does not happen yet with Cycles, so it might happen that the last tile can end up as a job for the slowest gpu, and if the tile is too big, the rest of gpus will wait too long for the next frame doing nothing.

  • The cpu has low amount of cores, but comparably to gpu's cores they are super-powerful. Each such core can operate on a bigger chunk of data, and since individual cores do not share cache, you have that many tiles as you have cores (actually threads). Each core has approx 4-16MB of cache and that reflects the optimal tile size.

$\endgroup$
3
$\begingroup$

One thing not mentioned that is important for efficiency on multi-core hyperthreaded machines is the time cost of "tile stragglers." My machine has 12 cores and will spawn 24 rendering threads which means 24 tiles at once (2x E5670 Xeon). As a frame nears completion, it will reach a point where there are fewer tiles left to render than you have cores/threads. So you end up with cores sitting idly by while the last few tiles finish rendering. If those tiles are large, that can be a long wait. But if they are small,the wait is shorter because smaller tiles render faster than larger tiles. Smaller tiles give a shorter possible window where other cores are forced to sit idle.

Of course, this is only one factor.

$\endgroup$
2
$\begingroup$

Tile size affects rendering times in a few ways.

First, shape:

  • Partial tiles. This is the most important. The below are important, but this should always come first. Make sure your tile size can fit into a grid of the output resolution, with no overshoot. That overshoot leads to half-tiles or partial tiles, which will really slow your computer down.
  • Non-square tiles. Blender usually has a harder time working with non-square tiles, probably because it takes more memory. Make sure your tiles are as square as possible.
  • Non-powers of 2 length tiles. This has a slight effect, but usually Blender likes its tiles, textures, etc. nice and even-numbered in size. Powers of 2 help as well.

Second, CPU vs GPU.

The CPU often works best with smaller tiles, like 16x16 or 32x32. The reason is that it can(and will) render multiple tiles at once, so smaller tiles are more conducive. However, the GPU works best with larger tiles. This is because it only renders one tile at a time, so larger sizes are better for it.

A method to determine tile size:

  • Find factors of the length and width
  • Make pairs of equal or near equal factors
  • Select the size based on what you are rendering on

An example:

I am rendering a 900x750 picture on GPU. Factor pairs are 10x10, 25x25, 50x50, 150x150, and some more. Since I am using GPU, I will go for a big size, e.g. 150x150. Using factors ensure tiles with no overshoot, while pairing them ensure square or near-square tiles. Finally, I can choose a tile size, in this case 150x150, and render.

Choosing the right tile size is necessary to cut down on rendering time, and even though it seems complicated, it will actually become easier over time. Greg Zaal's Auto Tile Size will do this automatically, but it seems to be broken for 2.77, sadly.

$\endgroup$
  • 2
    $\begingroup$ Have you reported a bug about the add-on being broken? Seems to work fine for me still. (I did not downvote btw, but it would help if you showed some proof of your theories). $\endgroup$ – Greg Zaal Apr 23 '16 at 15:29
1
$\begingroup$

There is much more than samples alone.

For example when you start rendering, the scene data is divided into a data tree structure. A simple example would be to divide the scene into a left and right structure. When a pixel is sampled on the left side of the screen the renderer only looks into the left part of the data tree. This improves rendering times a lot.

Now, depending on the method used, this tree can be shared or has to be build every time a tile renders. So you can imaging that a large tile only has to build this tree once. But it will also take a lot more memory.

All these factors influence the rendering speed of the tile.

Other factors are textures, modifiers, particle systems and so on.

So even when the sample count is the same for all tile sizes, the underlying data can influence rendering speed a lot.

$\endgroup$
-4
$\begingroup$

GPU - CPU Is not common, though in fact it has been listed that CPU is a slow render due to its state. GPU though is a common usage of rendering in blender. You should probably switch to the original renderer GPU. It has a faster performance of tile rendering and it is a more common usage of memory and physical use to GPU, Graphics Card and Memory usage.

CPU 1200x1200 tiles 00:03:54 Estimated Through Gloss and Rays
GPU 1200x1200 tiles 00:00:37 Estimated Through Gloss and Rays

Estimation will be faster by GPU. It will also depend on your computer's hardware and how good it is. GPU-CPU

For advanced help or more info, please go to... https://blender.stackexchange.com/questions or https://www.blenderguru.com :)

$\endgroup$
  • $\begingroup$ Sorry but I really don't understand what you are trying to say. How does this answer my question? I am asking why and how the size of tiles affects performance. And "For advanced help or more info, please go to... blender.stackexchange.com/questions"... like... that's where we are... ??? $\endgroup$ – PGmath Jan 12 '17 at 18:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.