I've read a lot about this but most of what I've found is anecdotal or personal experience. My question is more about architecture.

The optimal tile size for GPU's is universally stated to be 256x256. But all GPU's are different. They have different interfaces, # of cores, memory, etc. Why is 256x256 the universal constant? If it's the memory interface, there are cards with 128-bit and 384-bit interfaces. Would their optimal size be 128x128 and 384x384?

I've found that for my GTX-970 (256-bit), if I keep the multiplied tile size as close to 65536 (256x256) as possible, I always get the fastest render times. But that number doesn't correspond to the number of cores (1664) or the amount of memory (4GB) on my card.

Ultimately, how is the optimal tile size determined for a specific GPU, architecturally speaking?

  • $\begingroup$ There is a addon bundled by default called Auto Tile Size that calculates this automatically. Never used it myself, not sure how it works, but assuming it was well built, and the math is correct, then perhaps investigating it's code will shed some light on the matter. $\endgroup$ May 10, 2017 at 18:17
  • $\begingroup$ A good idea... I looked at it briefly and it looks like it's taking an optimal "power of 2" as the standard (attempting to keep CPU or GPU at 100%) and then dividing the tiles based on the resolution of the rendered frame in order to keep the tile size as close to the optimal power of 2 as possible (i.e. no "stragglers"). It still doesn't explain the architecture of GPU, though. $\endgroup$
    – bertmoog
    May 10, 2017 at 18:41

1 Answer 1


The infamous answer to this question is:

It depends

The 256 x 256 recommendation that is given many times is a very good starting point. In general it will lead to decent render times and sufficcient image update cycles while you're waiting for the render to complete. But as with any renderer, tuning this setting can indeed lead to speed-ups, depending on

  • the final render pixel size
  • the complexity of the scene
  • the tracing engine used
  • the GPU you're running the render on
  • how many pixels are irrelevant (because they don't sample anything, as there are no objects hit by the rays)
  • likely many more factors

The most important one is the final render pixel size. If you render super high res, having a smaller number of tiles to be computed in total can speed up the rendering. At a resolution of 1280 x 720, you won't see much of a difference. At 8.000 x 6.000 you very likely will. When rendering on our TitanX rigs, we tend to go to 512 x 512, sometimes 1.024 x 1.024 tiles with such resolutions to cut render time. Less complex scenes also tend to support bigger tiles better, but again, no general rule here.

The GPU merely matters in terms of what generation it is (Fermi, Maxwell, Pascal, etc), the number of cores, and the amount of memory present. Maxwell GPUs can to my knowledge benefit from bigger tiles, with the others I have no personal experience.

The tracing engine I only mention because of a "feature" in Windows: TDR Delay. If you Google that, you'll find heated discussions plus a Microsoft support page on how to set it. Basically, when you render, a work package is sent to your GPU (the tile), and the system waits for the results to come back from the GPU (the resulting sampled image at a certain number of samples). If Windows does not hear back from the GPU after 2 seconds (the TDR delay), it restarts the graphics driver - and kills the rendering while at it. Especially when using Branched Path Tracing, the answer time for the GPU increases by A LOT. That causes renders to fail. Reducing the tile size is one fix to this, setting a higher TDR delay value another.

Auto Tile size

An Add-on called "Auto Tile Size" is bundled with Blender, which makes setting the tile size more convenient. When enabling it, you'll however notice that it actually doesn't set the render tile size to 256 x 256. Istead, it tries to choose values which are close to this, but round them up or down, so that the image is split up into tiles of all equal size. See this example:


The Render Dimensions are set to 1280 x 720 pixels, the tile size is set to 256 x 240. Why? Because that gives the GPU 5 x 3 = 15 tiles of equal size to process. If you keep the tile size at 256 x 256, the last row of tiles will have a height of 208 pixels, as 720 cannot be divided evenly by 256. This is potentially, but not necessarily, inefficient.

  • $\begingroup$ Nice answer. I have encountered that TDR Delay problem while using Branched Path Tracing myself, had look up how to increase it, otherwise I was unable render. Also worth mentioning that the larger the tile size the longer the response time, so if you plan on using the computer for something else while rendering, larger tile sizes will make it "slower". $\endgroup$ May 10, 2017 at 19:12
  • $\begingroup$ Nice answer and very informative, thank you. However, none of it addresses my question (though you began hinting at generational differences). Why is it that my video card (or other cards) performs better rendering 65536 pixel tiles than any other value? What about the physical card and hardware determines that? In other words why is that number more efficient than any other? Is it the memory interface? $\endgroup$
    – bertmoog
    May 10, 2017 at 20:44
  • 1
    $\begingroup$ @DuarteFarrajotaRamos True, if you are rendering on the main GPU (which also displays the viewport), you'll experience lags. If you have dedicated GPUs for rendering and don't use the main card at all, the interface remains butter smooth :) And I guess many imagers have run through the TDR hell with us, that's one 'feature' I loathe about Windows... $\endgroup$
    – aliasguru
    May 15, 2017 at 13:57
  • 1
    $\begingroup$ @bertmoog I'm not sure if the question can be answered that precisely. If I'm not mistaken, even the core Blender devs have found out about 256 as the best starting point simply by trial and error. $\endgroup$
    – aliasguru
    May 15, 2017 at 13:59
  • $\begingroup$ Yep, my bling guess is that GPU architecture+graphics driver code+Operating System+All other software and external factors from a complex and intricate enough combination to make it non trivial to point out exactly what makes one combination better than other. $\endgroup$ May 15, 2017 at 17:29

You must log in to answer this question.

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