[Bf-cycles] Bf-cycles Digest, Vol 69, Issue 4

James Crowther jamesharrycrowther at gmail.com
Thu Jan 5 12:15:50 CET 2017


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/4af2b9c6/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/25c23022/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
> ****************************************



More information about the Bf-cycles mailing list