[Bf-cycles] Proposal to remove tile size option

[Mai Lavelle]

Hi everyone,

I'd like to propose the removal of the tile size setting. This setting can
be hard for artists to set correctly, as how it affects performance is not
always clear. While working with the split kernel I've found that in some
situations there is no good choice, the user simply can't know all the
factors in play, and will likely end up setting the tile size to something
ridiculously large to compensate. There's also the situation of switching
devices or machines, the size chosen for a file on one system when opened
on another may no longer be the best choice.

Being such an important factor in performance, along with the difficulty of
setting it properly, I think that tile size should be chosen automatically
by the render engine. Or rather, I think device work load should not be a
user level setting.

Implementation should be mostly straight forward. Idea is to decouple tile
size from work load by using a fixed tile size such as 32x32 (or maybe
provide a limited set of options) for all renders and have the path tracing
logic acquire and render at once a number of tiles to saturate the device.
This way artists don't need to worry about setting a good tile size, each
device type will know how much work it needs and request that much work
from the tile manager without user intervention.

Changes to path tracing code should be pretty simple, mainly need to pass
an array of sample ranges and their corresponding buffers to the kernel.
For final renders the device could request multiple tile samples from the
same tile to render at once. For preview one sample from multiple tiles
would be rendered.

The main problem I can see at the moment is the save buffers option, which
expects the user set tile size to match exactly what tile size the render
engine updates buffers with. A possible solution is to have the save buffer
option query the render engine for which tile size it uses.

Any input, either on implementation or reasons for or against doing this,
would be much appreciated.

Thanks,

Mai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20170105/4af2b9c6/attachment.htm