<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000099">
    <font face="Helvetica, Arial, sans-serif">Hi,<br>
      <br>
      Another Greg Zaal 'Auto Tile Size' user here (thanks again Greg!).<br>
      <br>
      Until an improved, or automatic remaining tiles subdivision with
      thread redistribution algorithm is implemented, is there reason
      not to ship Blender with Zaal's add-on enabled by default?<br>
      <br>
      To simplify Blender's GUI, the 'Auto Tile Size', or other
      solution, plus threads setting, could possibly be hidden behind an
      advanced settings check box, this caters for everyone from
      beginner to advanced?<br>
      <br>
      Thanks,<br>
      David<br>
      <br>
      PS: Fixed the Subject line (back to original topic of discussion).<br>
    </font><br>
    <div class="moz-cite-prefix">On 05/01/17 13:38, Chip Cunningham
      wrote:<br>
    </div>
    <blockquote cite="mid:001e01d26758$f0192b50$d04b81f0$@gmail.com"
      type="cite">
      <pre wrap="">Hi,

Average everyday blender user here.  Does the auto-tile size plugin by Greg
Zaal not auto-set tile sizes properly?  Just curious because I've been using
it to help choose appropriate tile sizes for the render device and the scene
size.  It seems to work pretty well, but I am not a coder. :)

Also, the comment that "device work load should not be a user setting" is a
bit misleading.  Tile size choice, if that can be handled under the hood,
should be handled automatically.  However, other "work load" settings like
selecting the number of render threads to use, saving buffers, start
resolution for viewport, etc. are helpful to the artist.  I always set the
number of render threads so as to leave a free core for multitasking on my
machine (I render on CPU).

My two cents. :)

-Chip

-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:bf-cycles-bounces@blender.org">bf-cycles-bounces@blender.org</a> [<a class="moz-txt-link-freetext" href="mailto:bf-cycles-bounces@blender.org">mailto:bf-cycles-bounces@blender.org</a>]
On Behalf Of <a class="moz-txt-link-abbreviated" href="mailto:bf-cycles-request@blender.org">bf-cycles-request@blender.org</a>
Sent: Thursday, January 5, 2017 06:00
To: <a class="moz-txt-link-abbreviated" href="mailto:bf-cycles@blender.org">bf-cycles@blender.org</a>
Subject: Bf-cycles Digest, Vol 69, Issue 4

Send Bf-cycles mailing list submissions to
        <a class="moz-txt-link-abbreviated" href="mailto:bf-cycles@blender.org">bf-cycles@blender.org</a>

To subscribe or unsubscribe via the World Wide Web, visit
        <a class="moz-txt-link-freetext" href="https://lists.blender.org/mailman/listinfo/bf-cycles">https://lists.blender.org/mailman/listinfo/bf-cycles</a>
or, via email, send a message with subject or body 'help' to
        <a class="moz-txt-link-abbreviated" href="mailto:bf-cycles-request@blender.org">bf-cycles-request@blender.org</a>

You can reach the person managing the list at
        <a class="moz-txt-link-abbreviated" href="mailto:bf-cycles-owner@blender.org">bf-cycles-owner@blender.org</a>

When replying, please edit your Subject line so it is more specific than
"Re: Contents of Bf-cycles digest..."


Today's Topics:

   1. Proposal to remove tile size option (Mai Lavelle)
   2. Re: Proposal to remove tile size option (Thomas Dinges)


----------------------------------------------------------------------

Message: 1
Date: Thu, 5 Jan 2017 05:20:22 -0500
From: Mai Lavelle <a class="moz-txt-link-rfc2396E" href="mailto:mai.lavelle@gmail.com">&lt;mai.lavelle@gmail.com&gt;</a>
Subject: [Bf-cycles] Proposal to remove tile size option
To: Discussion list to assist Cycles render engine developers
        <a class="moz-txt-link-rfc2396E" href="mailto:bf-cycles@blender.org">&lt;bf-cycles@blender.org&gt;</a>
Message-ID:
        <a class="moz-txt-link-rfc2396E" href="mailto:CACXzUviayBiX+q_2tURjhW6iB5WgpBfgdk1o=wEC+wPFhDvKJg@mail.gmail.com">&lt;CACXzUviayBiX+q_2tURjhW6iB5WgpBfgdk1o=wEC+wPFhDvKJg@mail.gmail.com&gt;</a>
Content-Type: text/plain; charset="utf-8"

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:
<a class="moz-txt-link-freetext" href="http://lists.blender.org/pipermail/bf-cycles/attachments/20170105/4af2b9c6/a">http://lists.blender.org/pipermail/bf-cycles/attachments/20170105/4af2b9c6/a</a>
ttachment.html 

------------------------------

Message: 2
Date: Thu, 5 Jan 2017 11:32:22 +0100
From: Thomas Dinges <a class="moz-txt-link-rfc2396E" href="mailto:blender@dingto.org">&lt;blender@dingto.org&gt;</a>
Subject: Re: [Bf-cycles] Proposal to remove tile size option
To: Discussion list to assist Cycles render engine developers
        <a class="moz-txt-link-rfc2396E" href="mailto:bf-cycles@blender.org">&lt;bf-cycles@blender.org&gt;</a>
Message-ID: <a class="moz-txt-link-rfc2396E" href="mailto:5d1a3e81-d778-c7e7-c1aa-0129a695b197@dingto.org">&lt;5d1a3e81-d778-c7e7-c1aa-0129a695b197@dingto.org&gt;</a>
Content-Type: text/plain; charset="windows-1252"

Hi Mai,

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.

Best regards,

Thomas


Am 05.01.2017 um 11:20 schrieb Mai Lavelle:
</pre>
      <blockquote type="cite">
        <pre wrap="">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


_______________________________________________
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>
      <pre wrap="">
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<a class="moz-txt-link-freetext" href="http://lists.blender.org/pipermail/bf-cycles/attachments/20170105/25c23022/a">http://lists.blender.org/pipermail/bf-cycles/attachments/20170105/25c23022/a</a>
ttachment-0001.htm 

------------------------------

_______________________________________________
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>


End of Bf-cycles Digest, Vol 69, Issue 4
****************************************

_______________________________________________
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>