[Bf-cycles] Proposal to remove tile size option
Chip Cunningham
cunningmason at gmail.com
Fri Jan 6 17:09:11 CET 2017
I believe the key concern is whether Mai's proposed change to tile size
selection would remove the ability to control the number of render threads
and/or remove certain performance options like tile render order or
progressive refine. If the change does not affect exposure of these "device
work load" settings to the user, then it sounds like an excellent proposal.
If the change does affect the exposure of these settings, it might be worth
considering the following:
The artist should have some measure of control over how Blender consumes
compute resources when rendering, especially when rendering on CPU.
Otherwise, some artists machines will become sluggish or even unusable until
the render completes.
Many artists multitask on their machines while waiting on renders to finish.
When rendering on GPU this isn't as much of a concern, but for those using
CPUs to render, it is nice to tell Blender 'use 3 of my 4 CPU threads' for
example, so as to leave one thread free for other tasks.
Many artists also do not have dedicated GPUs for rendering. A portion of
those that do will have AMD or Intel HD (especially on laptops) so they
likely rely on CPU for rendering anyway. Again, controlling the number of
render threads becomes useful.
Oh and I need to say here, you Blender devs absolutely rock! You have made
many an artist's dreams and visions become a reality with this excellent
piece of software.
Thank you for all that you do. :)
-Chip
-----Original Message-----
From: bf-cycles-bounces at blender.org [mailto:bf-cycles-bounces at blender.org]
On Behalf Of bf-cycles-request at blender.org
Sent: Friday, January 6, 2017 06:00
To: bf-cycles at blender.org
Subject: Bf-cycles Digest, Vol 69, Issue 5
Send Bf-cycles mailing list submissions to
bf-cycles at blender.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.blender.org/mailman/listinfo/bf-cycles
or, via email, send a message with subject or body 'help' to
bf-cycles-request at blender.org
You can reach the person managing the list at
bf-cycles-owner at blender.org
When replying, please edit your Subject line so it is more specific than
"Re: Contents of Bf-cycles digest..."
Today's Topics:
1. Re: Bf-cycles Digest, Vol 69, Issue 4 (James Crowther)
2. Re: Build Cycles CUDA binaries (Brecht Van Lommel)
3. Re: Proposal to remove tile size option (Brecht Van Lommel)
4. Turn on Object Scale Motion Blur for 2.79? (Gottfried Hofmann)
5. Re: A couple of questions... (Thomas Volkmann)
6. Re: Bf-cycles Digest, Vol 69, Issue 4 (Chip Cunningham)
7. Re: Proposal to remove tile size option (db4tech at yahoo.co.uk)
8. Re: Proposal to remove tile size option (Greg Zaal)
----------------------------------------------------------------------
Message: 1
Date: Thu, 5 Jan 2017 22:15:50 +1100
From: James Crowther <jamesharrycrowther at gmail.com>
Subject: Re: [Bf-cycles] Bf-cycles Digest, Vol 69, Issue 4
To: bf-cycles at blender.org
Message-ID: <F559BCDC-E435-4CDC-9A23-E6D81D632190 at gmail.com>
Content-Type: text/plain; charset=utf-8
Hey guys, Hang on a minute, I use this setting often and its very useful for
getting overall render times down. I think there should be some consultation
with artists before we remove this feature, I am not the only one who uses
it succesfully!
I?m not 100% familiar with what Mai?s proposal and how it will impact
performance. Of course if the proposed changes can optimise the tile size
without user intervention then this is a huge bonus and I?d be all for that.
But if that will not be the case I would like to put my hand up for keeping
the tile feature. I?ve seen real benefits to having it, despite the
potential for confusion. In any case, I am positive a simple tutorial on the
subject would clear up any ambiguity and allow other artists the ability to
get real benefits from it as well.
Thanks!
James
> On 5 Jan 2017, at 10:00 pm, bf-cycles-request at blender.org wrote:
>
> Send Bf-cycles mailing list submissions to
> bf-cycles at blender.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.blender.org/mailman/listinfo/bf-cycles
> or, via email, send a message with subject or body 'help' to
> bf-cycles-request at blender.org
>
> You can reach the person managing the list at
> bf-cycles-owner at blender.org
>
> 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 <mai.lavelle at gmail.com>
> Subject: [Bf-cycles] Proposal to remove tile size option
> To: Discussion list to assist Cycles render engine developers
> <bf-cycles at blender.org>
> Message-ID:
> <CACXzUviayBiX+q_2tURjhW6iB5WgpBfgdk1o=wEC+wPFhDvKJg at mail.gmail.com>
> 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:
> http://lists.blender.org/pipermail/bf-cycles/attachments/20170105/4af2
> b9c6/attachment.html
>
> ------------------------------
>
> Message: 2
> Date: Thu, 5 Jan 2017 11:32:22 +0100
> From: Thomas Dinges <blender at dingto.org>
> Subject: Re: [Bf-cycles] Proposal to remove tile size option
> To: Discussion list to assist Cycles render engine developers
> <bf-cycles at blender.org>
> Message-ID: <5d1a3e81-d778-c7e7-c1aa-0129a695b197 at dingto.org>
> 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:
>> 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
>> Bf-cycles at blender.org
>> https://lists.blender.org/mailman/listinfo/bf-cycles
>
> -------------- next part -------------- An HTML attachment was
> scrubbed...
> URL:
> http://lists.blender.org/pipermail/bf-cycles/attachments/20170105/25c2
> 3022/attachment-0001.htm
>
> ------------------------------
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles
>
>
> End of Bf-cycles Digest, Vol 69, Issue 4
> ****************************************
------------------------------
Message: 2
Date: Thu, 5 Jan 2017 12:18:47 +0100
From: Brecht Van Lommel <brechtvanlommel at pandora.be>
Subject: Re: [Bf-cycles] Build Cycles CUDA binaries
To: Discussion list to assist Cycles render engine developers
<bf-cycles at blender.org>
Message-ID:
<CAKFUgC398mzL05f87Wt1K+ZzJajp8xmajP_GCyzXT3Vm5XHg-w at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Difficult to say what the problem would be without seeing the configuration
that you used and what it says in the build log.
Mainly you need to ensure that WITH_CYCLES_CUDA_BINARIES is ON, that
CYCLES_CUDA_BINARIES_ARCH contains the architecture of your GPU (check
https://developer.nvidia.com/cuda-gpus for the compute capability number).
And then you should look at the CMake output to check that it properly
detected your CUDA installation.
On Tue, Jan 3, 2017 at 2:58 PM, Michal Valent <daddymxiii at gmail.com> wrote:
> Hi,
>
> I would like to build Cycles CUDA binaries according to
> https://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Windows/ms
> vc/CMake
> https://wiki.blender.org/index.php/Dev:Source/Render/Cycles/Building
>
> but after build in Visual Studio community 2013 I have
>
> 2.78.4 date 2016-12-29
> ...
> Blender User Preferences
> System
> Cycles Compute Device: None
>
> Cycles Render
> Render
> Device: CPU + GPU Compute ... UI element is grayed but can be switched
> between these two values
>
> GPU Compute not functioning.
>
> ---
>
> I put this question here
> https://blenderartists.org/forum/showthread.php?413187-Building-Blende
> r-in-VS2013-not-successful-with-CUDA
> and nobody answered to me.
>
> Please what am I doing wrong ?
>
> DaddyMX
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles
>
------------------------------
Message: 3
Date: Thu, 5 Jan 2017 12:19:09 +0100
From: Brecht Van Lommel <brechtvanlommel at pandora.be>
Subject: Re: [Bf-cycles] Proposal to remove tile size option
To: Discussion list to assist Cycles render engine developers
<bf-cycles at blender.org>
Message-ID:
<CAKFUgC1YETtV=mPra0sbp-yyXmLs6A22NK45DwvpQGiUBue=hQ at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
I think this is definitely the right direction to go in, we should try to
make it so the tile size has no significant influence on performance, and
let the device determine the appropriate number of pixels to render at a
time.
For GPUs that would be bigger tiles or multiple samples as you say, for the
CPU you might have multiple cores working on the same tile eventually as
well.
On Thu, Jan 5, 2017 at 11:32 AM, Thomas Dinges <blender at dingto.org> wrote:
> 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:
>
> 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
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles
>
>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles
>
------------------------------
Message: 4
Date: Thu, 5 Jan 2017 12:29:24 +0100
From: Gottfried Hofmann <gottfried at blenderdiplom.com>
Subject: [Bf-cycles] Turn on Object Scale Motion Blur for 2.79?
To: Discussion list to assist Cycles render engine developers
<bf-cycles at blender.org>
Message-ID: <6945730a-a24d-52fa-fe53-cbe08a07d0ba at blenderdiplom.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Hello Cycles Developers,
are there any plans to turn on motion blur for object scale in Blender 2.79?
(I just checked with latest build from buildbot and it is still turned off).
Motion blur for object would be really useful in motion graphics (where I
currently use shape keys instead).
Cheers,
Gottfried
--
Gottfried Hofmann
Blender Foundation Certified Trainer
www.BlenderDiplom.com
------------------------------
Message: 5
Date: Thu, 5 Jan 2017 14:08:10 +0100 (CET)
From: Thomas Volkmann <lists at thomasvolkmann.com>
Subject: Re: [Bf-cycles] A couple of questions...
To: Discussion list to assist Cycles render engine developers
<bf-cycles at blender.org>
Message-ID:
<1113705135.1483797.1483621690517.JavaMail.open-xchange at app02.ox.hosteurope.
de>
Content-Type: text/plain; charset="utf-8"
The project is finished, and I did a short making of just on the Blender
part:
https://blenderartists.org/forum/showthread.php?413442-Blender-VFX-on-Swedis
h-TV-Show
cheers,
Thomas
> Sergey Sharybin <sergey.vfx at gmail.com> hat am 16. Juni 2016 um 09:57
> geschrieben:
>
> Hi,
>
> Inlined answers.
>
> On Thu, Jun 16, 2016 at 9:09 AM, Thomas Volkmann
<lists at thomasvolkmann.com
> mailto:lists at thomasvolkmann.com > wrote:
> > > Hi,
> >
> > I'm using Blender on a shot for a bigger project right now, and while
I'm
> > enjoying it a lot (never had a single crash so far and its not a
lightweight
> > scene) there is some stuff that I either don't know how to do, might do
> > wrong or simply can't do because of the programs limitiations.
> > >
> Wow, you sure you use Blender? ;) It crashes so often based on reports in
our
> tracker :)
>
> It's also always interesting to know what Blender/Cycles is used for. Is
your
> projection mentionable/showable?
>
> > > So if you could please shed some light on a couple of
questions...
> > Here we go:
> > >
> Here are some answers for you :)
>
> > >
> > 1.: Custom AOVs (Passes)?
> > I need to create a couple of RGB masks. At the moment I create a new
> > renderlayer with an override rgb material (Obj-ID decides if R,G,B, or
> > black). Since I have a couple of objects, I end up with a lot of
> > renderlayers, which makes the rendering process longer. In Vray there is
the
> > multimatte-element channel that you can use for that and in Arnold you
can
> > freely setup your aovs (passes, channels, whatever it is called in
different
> > software). Is there something like this in cycles that I haven't noticed
> > yet, or is the workflow I'm using atm the one to go for atm?
> > >
> There is no such a thing in neither Blender in general nor in Cycles in
> particular. So for now your workflow seems as optimal as it could be in
> Blender.
>
> Not saying it's impossible to improve it by making passes more flexible
:)
>
> > > 2.: Custom Attributes
> > As I understand it, cycles can already access some predefined
attributes
> > on a per vertex level (?). But how about if I give custom attributes to
> > objects? E.g. if I give a customID property to my objects, could I use
that
> > in the rendertree instead of ObectInfo->ObjectID?
> > >
> That might be interesting extension of shader trees, but it's not
possible at
> this moment either. Currently Cycles know knothing about custom properties
and
> can't have any clue what to do with them.
>
> > > 3.: Nodes
> > I really could use some nodes like the "rescale" node that is
mentioned
> > in another thread on this list, because I'm running a custom OCIO
> > configuration and run into the fcurve issues that are mentioned here
> > https://github.com/sobotka/bassam-test (last point in "Help! grading is
> > tricky"). Also a random node with a seed input (e.g. ObjID) would be
> > awesome. Which brings me to the next point....
> > >
> Not sure you need rescale node, sounds more like making it so Cycles uses
> same working color space as rest of color pipeline. Lukas Stockner had a
patch
> for that.
>
> Can see why rescale node can be handy in other occasions. But thing is,
it
> can be achieved with 2 or 3 (depending on parameterization) math nodes,
which
> is kinda quite too simple to make a dedicated mode for this. I would say:
this
> is something what should be solved with node templates. We need those
> templates anyway, with ability to easily share/reuse them across projects.
>
> How random node is different from noise? Do you want different values to
be
> returned for same shading point at different samples?
>
> > > 4.: Beginners Guide to write cycles shaders/nodes
> > Is there some guide on writing and compiling cycles shaders (not osl)
and
> > custom nodes (maybe I could write the nodes in 4. myself?). Could
compiled
> > shaders and nodes be shared, or has a custom blender build to be used
for
> > that?
> > >
> There are some video tutorials form various folks around blender
community,
> AFAIR there was also some DVD training material from BI.
>
> Not sure what you mean by compiled shaders. You can't share SVM bytecode,
> that would even be quite useless. But you can share node setups in .blend
> file. The idea here is to have a "library" .blend file from which you link
or
> append a material tree or a node group. This is as much easy as it could
be in
> default blender (there are addons for online material collections and
such,
> which sounds more friendly but i didn't try them yet).
>
> But making it easier to share assets is definitely a direction we want to
> move, hopefully it'll happen sooner than later :)
>
> > > 5.: Logging
> > I think I already asked that a while ago, but is it possible to
reduce
> > cycles logging output? The log files on the renderfarm are huge, and I
> > porbably just would need some summary info.
> > >
> It's not possible to reduce logging and in fact, i'm tempting to think
> verbosity should be increased (for example, --debug-cycles used). Here are
> reasoning:
>
> - You don't really want any logging while everything works fine.
> - This means, renderfarm software can just delete full log file after
> job/task successfully rendered
> - Different render farms might want different summary, so it kind of more
> flexible if farm itself worries about summary info it want to manage (CPU
> temperature, phase of Moon, whatever).
> - Some really commonly requested summary (such as render time, memory
usage
> which was added recently AFAIR, camera , file, scene..) are saved to
render
> result's metadata. Advantage of that is that it then readable by Blender,
so
> you can drop rendered sequence to VSE, enable SHow Metadata, scrub
timeline
> and see timing info. Neato :)
> - But unfortunately, render farms might and does go crazy time to time:
black
> frames, missing textures, wrong animation, etc.. In order to troubleshoot
such
> issues current verbosity is not really enough (for Caminandes VR we were
using
> --debug-cycles command line argument to increase verbosity even more ;).
If
> you'll drop idea of having full render log it'll be much more impossible
to
> troubleshoot such issues.
>
> So not really convinced Blender should worry about renderfarm logs,
> renderfarm software itself should worry about that. For example, as
mentioned
> above, wipe logs once job/task is finished successfully.
>
> --
> With best regards, Sergey Sharybin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.blender.org/pipermail/bf-cycles/attachments/20170105/ad21883a/a
ttachment-0001.htm
------------------------------
Message: 6
Date: Thu, 5 Jan 2017 08:38:02 -0500
From: "Chip Cunningham" <cunningmason at gmail.com>
Subject: Re: [Bf-cycles] Bf-cycles Digest, Vol 69, Issue 4
To: <bf-cycles at blender.org>
Message-ID: <001e01d26758$f0192b50$d04b81f0$@gmail.com>
Content-Type: text/plain; charset="us-ascii"
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: bf-cycles-bounces at blender.org [mailto:bf-cycles-bounces at blender.org]
On Behalf Of bf-cycles-request at blender.org
Sent: Thursday, January 5, 2017 06:00
To: bf-cycles at blender.org
Subject: Bf-cycles Digest, Vol 69, Issue 4
Send Bf-cycles mailing list submissions to
bf-cycles at blender.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.blender.org/mailman/listinfo/bf-cycles
or, via email, send a message with subject or body 'help' to
bf-cycles-request at blender.org
You can reach the person managing the list at
bf-cycles-owner at blender.org
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 <mai.lavelle at gmail.com>
Subject: [Bf-cycles] Proposal to remove tile size option
To: Discussion list to assist Cycles render engine developers
<bf-cycles at blender.org>
Message-ID:
<CACXzUviayBiX+q_2tURjhW6iB5WgpBfgdk1o=wEC+wPFhDvKJg at mail.gmail.com>
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:
http://lists.blender.org/pipermail/bf-cycles/attachments/20170105/4af2b9c6/a
ttachment.html
------------------------------
Message: 2
Date: Thu, 5 Jan 2017 11:32:22 +0100
From: Thomas Dinges <blender at dingto.org>
Subject: Re: [Bf-cycles] Proposal to remove tile size option
To: Discussion list to assist Cycles render engine developers
<bf-cycles at blender.org>
Message-ID: <5d1a3e81-d778-c7e7-c1aa-0129a695b197 at dingto.org>
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:
> 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
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.blender.org/pipermail/bf-cycles/attachments/20170105/25c23022/a
ttachment-0001.htm
------------------------------
_______________________________________________
Bf-cycles mailing list
Bf-cycles at blender.org
https://lists.blender.org/mailman/listinfo/bf-cycles
End of Bf-cycles Digest, Vol 69, Issue 4
****************************************
------------------------------
Message: 7
Date: Thu, 5 Jan 2017 23:28:37 +0000
From: db4tech at yahoo.co.uk
Subject: Re: [Bf-cycles] Proposal to remove tile size option
To: Discussion list to assist Cycles render engine developers
<bf-cycles at blender.org>
Message-ID: <9252dce2-5876-ad6c-665a-209b296608e7 at yahoo.co.uk>
Content-Type: text/plain; charset="windows-1252"
Hi,
Another Greg Zaal 'Auto Tile Size' user here (thanks again Greg!).
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?
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?
Thanks,
David
PS: Fixed the Subject line (back to original topic of discussion).
On 05/01/17 13:38, Chip Cunningham wrote:
> 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: bf-cycles-bounces at blender.org [mailto:bf-cycles-bounces at blender.org]
> On Behalf Of bf-cycles-request at blender.org
> Sent: Thursday, January 5, 2017 06:00
> To: bf-cycles at blender.org
> Subject: Bf-cycles Digest, Vol 69, Issue 4
>
> Send Bf-cycles mailing list submissions to
> bf-cycles at blender.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.blender.org/mailman/listinfo/bf-cycles
> or, via email, send a message with subject or body 'help' to
> bf-cycles-request at blender.org
>
> You can reach the person managing the list at
> bf-cycles-owner at blender.org
>
> 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 <mai.lavelle at gmail.com>
> Subject: [Bf-cycles] Proposal to remove tile size option
> To: Discussion list to assist Cycles render engine developers
> <bf-cycles at blender.org>
> Message-ID:
> <CACXzUviayBiX+q_2tURjhW6iB5WgpBfgdk1o=wEC+wPFhDvKJg at mail.gmail.com>
> 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:
>
http://lists.blender.org/pipermail/bf-cycles/attachments/20170105/4af2b9c6/a
> ttachment.html
>
> ------------------------------
>
> Message: 2
> Date: Thu, 5 Jan 2017 11:32:22 +0100
> From: Thomas Dinges <blender at dingto.org>
> Subject: Re: [Bf-cycles] Proposal to remove tile size option
> To: Discussion list to assist Cycles render engine developers
> <bf-cycles at blender.org>
> Message-ID: <5d1a3e81-d778-c7e7-c1aa-0129a695b197 at dingto.org>
> 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:
>> 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
>> Bf-cycles at blender.org
>> https://lists.blender.org/mailman/listinfo/bf-cycles
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
>
http://lists.blender.org/pipermail/bf-cycles/attachments/20170105/25c23022/a
> ttachment-0001.htm
>
> ------------------------------
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles
>
>
> End of Bf-cycles Digest, Vol 69, Issue 4
> ****************************************
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.blender.org/pipermail/bf-cycles/attachments/20170105/3b611157/a
ttachment-0001.htm
------------------------------
Message: 8
Date: Fri, 06 Jan 2017 10:56:29 +0000
From: Greg Zaal <gregzzmail at gmail.com>
Subject: Re: [Bf-cycles] Proposal to remove tile size option
To: Discussion list to assist Cycles render engine developers
<bf-cycles at blender.org>
Message-ID:
<CAN5-zsP3HEF5N=3rgEgvr_nnPB4LcpXCwGx9NMOtLVczE3HcPw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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.
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 :)
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.
On Thu, 5 Jan 2017 at 13:19 Brecht Van Lommel <brechtvanlommel at pandora.be>
wrote:
I think this is definitely the right direction to go in, we should try
to make it so the tile size has no significant influence on
performance, and let the device determine the appropriate number of
pixels to render at a time.
For GPUs that would be bigger tiles or multiple samples as you say,
for the CPU you might have multiple cores working on the same tile
eventually as well.
On Thu, Jan 5, 2017 at 11:32 AM, Thomas Dinges <blender at dingto.org> wrote:
> 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:
>
> 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
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles
>
>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles
>
_______________________________________________
Bf-cycles mailing list
Bf-cycles at blender.org
https://lists.blender.org/mailman/listinfo/bf-cycles
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.blender.org/pipermail/bf-cycles/attachments/20170106/55fb229f/a
ttachment-0001.htm
------------------------------
_______________________________________________
Bf-cycles mailing list
Bf-cycles at blender.org
https://lists.blender.org/mailman/listinfo/bf-cycles
End of Bf-cycles Digest, Vol 69, Issue 5
****************************************
More information about the Bf-cycles
mailing list