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.[Download Auto Tile Size Addon]
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.
Cool add-on! I found this article also very informative..and apparently a lot of this info comes right from Brecht: http://www.systemagnostic.com/faqs/adjusting-cycles-tile-sizes-for-increased-speed-and-reduced-vram/
One thing I found enlightening for cycles is that you want multiples of resolution, because if you say have a 10×10 render (resolution of the final image, just for easy math sake).
If say you have 3pixel x 3pixel tiles .. …then you get 9 square (3×3) tiles, and 3 rectangular (3×1) tiles…BUT in the background…the rectangular tiles are still square (3×3) and are actually rendering stuff outside the frame (or something along those lines) so you waste time rendering stuff that doesn’t end up in the final scene. So to get optimal tile size you want your resolution divided by an integer (the integer can be different in both directions). so for a 10×10 picture..you might want to use a factor of 2 ..and use 5×5 tiles etc.
Here’s the relevant paragraph….so maybe it’s not exactly that it’s rendering stuff outside of your frame..but it’s still doing SOMETHING weird.
“If you render tiles that are not a multiple of your full resolution, you are wasting time. See example above for a 1920×1080 render. This is due to the fact the Cycles need to render everything, and if you’re rendering a tile that is 90% empty, it still takes the same time to render as several of your CUDA cores will then be waiting for others to finish. This is even more true with multi-GPU setup, where all GPUs have to wait for the last to finish before moving on to the next frame/finish rendering”
V3. Working like a charm!
Download link seems incorrect. I assume it should be this:
Thanks for the tip – that page also contains old links though, here’s the latest: http://bit.ly/auto-tile-size (have updated all download links on this site now too)