Well when I started this blog, I would never have imagined it would turn into a code blog. I guess once I started doing shading and lighting more often at work, I lost interest in doing anything like that at home and turned to a new hobby.

Anyway, I fixed the issue with Blender Internal renderer getting stuck on tile sizes meant for Cycles, so BI now get’s it’s own tile size stored separately (defaulting at +-64). I also made sure no other renderer would get stuck using the same tile sizes by simply disabling it when the scene is not using BI or Cycles. And lastly a tiny UI tweak, hiding the target size behind a settings button since unless you really know what you’re doing you probably shouldn’t touch it anyway.

I also did a fair amount of testing to make sure my old assumptions were actually correct, and turns out they are:

I tested four very different scenes in Cycles using both GPU and CPU, with different resolutions and scene content.

As you can see, CPU likes small tiles and GPU likes bigger ones – whether or not the tiles are all the same size doesn’t seem to matter as much as I thought, although it does matter on the GPU if they are drastically different, such as very thin tiles on the edge, but that’s probably because the tile has a smaller area and not really anything to do with how square it is. Still, I stick with my original logic just to avoid these corner cases.

The story with Blender Internal is a little different. Here I only tested one scene at 1080p, either because I was too lazy to try some more, because others told me the best size already, or because the results of this one test were pretty conclusive. You choose. The point is that tile sizes in BI really don’t matter all that much. The main reason why the render gets slightly slower as the tile size decreases is because it has to look too see what’s inside that tile before rendering, and thus there’s a small overhead of render time for each tile, thus the more tiles there are the longer it takes.

Lastly, one of the reasons why the render takes longer in all three cases (Cycles GPU, CPU and BI) with large tiles is mostly because there are more tiles than there are threads available. For example 512×512 tiles in a 1024×1024 image means there’s only 4 cores of your CPU renderering, the rest are doing nothing at all. This might not matter too much with GPU rendering as you can see in the first two tests, since you only have 1 or 2 tiles rendering at once anyway.