<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hi Mai,</p>
<p>Less UI options is always better in my opinion. From what I read
online, not optimal tile sizes are still one of the biggest error
sources when it comes to performance. If we can hide this logic
from the user and do it automatically, we should definitely do it.
<br>
</p>
<p>Best regards,</p>
<p>Thomas<br>
</p>
<br>
<div class="moz-cite-prefix">Am 05.01.2017 um 11:20 schrieb Mai
Lavelle:<br>
</div>
<blockquote
cite="mid:CACXzUviayBiX+q_2tURjhW6iB5WgpBfgdk1o=wEC+wPFhDvKJg@mail.gmail.com"
type="cite">
<div dir="ltr">Hi everyone,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Any input, either on implementation or reasons for or against
doing this, would be much appreciated.<br>
<br>
Thanks,<br>
<br>
Mai<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Bf-cycles mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a>
<a class="moz-txt-link-freetext" href="https://lists.blender.org/mailman/listinfo/bf-cycles">https://lists.blender.org/mailman/listinfo/bf-cycles</a>
</pre>
</blockquote>
<br>
</body>
</html>