<div dir="ltr"><div dir="ltr" class="gmail_msg">Just to throw my voice in as a user: This sounds good to me. Many users don't know about the drastic performance changes that come from adjusting the tile size, so when rendering with GPU they leave it as 64x64 which is rather suboptimal.<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Apart from obvious performance changes with GPU rendering, manually adjustable tile sizes also allows the user to avoid getting stuck rendering a particularly difficult tile at the end with only one CPU thread (or one of multiple GPUs), with the other threads already finished their tiles and now doing nothing - in this case they could make the tiles smaller so that all threads can work on the problem area. If the proposed solution includes allowing multiple threads to render different sample sets in the same tile, that sounds like a perfect solution :)</div><div class="gmail_msg"><br></div><div class="gmail_msg">To address James's concern - the tile size option is only useful because we have to set it manually. If it were calculated automatically or didn't have such an impact on performance, you wouldn't need it.</div></div><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Thu, 5 Jan 2017 at 13:19 Brecht Van Lommel <<a href="mailto:brechtvanlommel@pandora.be" class="gmail_msg" target="_blank">brechtvanlommel@pandora.be</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think this is definitely the right direction to go in, we should try<br class="gmail_msg">
to make it so the tile size has no significant influence on<br class="gmail_msg">
performance, and let the device determine the appropriate number of<br class="gmail_msg">
pixels to render at a time.<br class="gmail_msg">
<br class="gmail_msg">
For GPUs that would be bigger tiles or multiple samples as you say,<br class="gmail_msg">
for the CPU you might have multiple cores working on the same tile<br class="gmail_msg">
eventually as well.<br class="gmail_msg">
<br class="gmail_msg">
On Thu, Jan 5, 2017 at 11:32 AM, Thomas Dinges <<a href="mailto:blender@dingto.org" class="gmail_msg" target="_blank">blender@dingto.org</a>> wrote:<br class="gmail_msg">
> Hi Mai,<br class="gmail_msg">
><br class="gmail_msg">
> Less UI options is always better in my opinion. From what I read online, not<br class="gmail_msg">
> optimal tile sizes are still one of the biggest error sources when it comes<br class="gmail_msg">
> to performance. If we can hide this logic from the user and do it<br class="gmail_msg">
> automatically, we should definitely do it.<br class="gmail_msg">
><br class="gmail_msg">
> Best regards,<br class="gmail_msg">
><br class="gmail_msg">
> Thomas<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> Am 05.01.2017 um 11:20 schrieb Mai Lavelle:<br class="gmail_msg">
><br class="gmail_msg">
> Hi everyone,<br class="gmail_msg">
><br class="gmail_msg">
> I'd like to propose the removal of the tile size setting. This setting can<br class="gmail_msg">
> be hard for artists to set correctly, as how it affects performance is not<br class="gmail_msg">
> always clear. While working with the split kernel I've found that in some<br class="gmail_msg">
> situations there is no good choice, the user simply can't know all the<br class="gmail_msg">
> factors in play, and will likely end up setting the tile size to something<br class="gmail_msg">
> ridiculously large to compensate. There's also the situation of switching<br class="gmail_msg">
> devices or machines, the size chosen for a file on one system when opened on<br class="gmail_msg">
> another may no longer be the best choice.<br class="gmail_msg">
><br class="gmail_msg">
> Being such an important factor in performance, along with the difficulty of<br class="gmail_msg">
> setting it properly, I think that tile size should be chosen automatically<br class="gmail_msg">
> by the render engine. Or rather, I think device work load should not be a<br class="gmail_msg">
> user level setting.<br class="gmail_msg">
><br class="gmail_msg">
> Implementation should be mostly straight forward. Idea is to decouple tile<br class="gmail_msg">
> size from work load by using a fixed tile size such as 32x32 (or maybe<br class="gmail_msg">
> provide a limited set of options) for all renders and have the path tracing<br class="gmail_msg">
> logic acquire and render at once a number of tiles to saturate the device.<br class="gmail_msg">
> This way artists don't need to worry about setting a good tile size, each<br class="gmail_msg">
> device type will know how much work it needs and request that much work from<br class="gmail_msg">
> the tile manager without user intervention.<br class="gmail_msg">
><br class="gmail_msg">
> Changes to path tracing code should be pretty simple, mainly need to pass an<br class="gmail_msg">
> array of sample ranges and their corresponding buffers to the kernel. For<br class="gmail_msg">
> final renders the device could request multiple tile samples from the same<br class="gmail_msg">
> tile to render at once. For preview one sample from multiple tiles would be<br class="gmail_msg">
> rendered.<br class="gmail_msg">
><br class="gmail_msg">
> The main problem I can see at the moment is the save buffers option, which<br class="gmail_msg">
> expects the user set tile size to match exactly what tile size the render<br class="gmail_msg">
> engine updates buffers with. A possible solution is to have the save buffer<br class="gmail_msg">
> option query the render engine for which tile size it uses.<br class="gmail_msg">
><br class="gmail_msg">
> Any input, either on implementation or reasons for or against doing this,<br class="gmail_msg">
> would be much appreciated.<br class="gmail_msg">
><br class="gmail_msg">
> Thanks,<br class="gmail_msg">
><br class="gmail_msg">
> Mai<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> Bf-cycles mailing list<br class="gmail_msg">
> <a href="mailto:Bf-cycles@blender.org" class="gmail_msg" target="_blank">Bf-cycles@blender.org</a><br class="gmail_msg">
> <a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.blender.org/mailman/listinfo/bf-cycles</a><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> Bf-cycles mailing list<br class="gmail_msg">
> <a href="mailto:Bf-cycles@blender.org" class="gmail_msg" target="_blank">Bf-cycles@blender.org</a><br class="gmail_msg">
> <a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.blender.org/mailman/listinfo/bf-cycles</a><br class="gmail_msg">
><br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
Bf-cycles mailing list<br class="gmail_msg">
<a href="mailto:Bf-cycles@blender.org" class="gmail_msg" target="_blank">Bf-cycles@blender.org</a><br class="gmail_msg">
<a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.blender.org/mailman/listinfo/bf-cycles</a><br class="gmail_msg">
</blockquote></div></div>