<div dir="ltr"><div>"So basic answer is that for CPU it could be done quite quickly, if the<br>
GPU is involved it gets messy."<br><br></div>Seems to be the prevailing case unfortunately. Hopefully a workaround can be found. If not, it wouldn't be the first feature to be CPU-only.<br><br><br><br></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Sat, Jul 6, 2013 at 7:44 PM, Brecht Van Lommel <span dir="ltr"><<a href="mailto:brechtvanlommel@pandora.be" target="_blank">brechtvanlommel@pandora.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It's certainly possible, just complicates things somewhat. At the<br>
moment the logic is quite simply but with more advanced pixel<br>
filtering or adaptive sampling having multiple threads cooperate on a<br>
single tile is trickier. We can worry about that later though.<br>
<br>
For CPU rendering it can be done in the CPU device by making tasks<br>
more granular than tiles. There is probably some nice balanced tasks<br>
size that doesn't add too much thread overhead based on number of<br>
pixels x samples. Not too hard and nicely localized.<br>
<br>
For multi-GPU or GPU+CPU rendering it needs to be at a higher level<br>
however because the tile buffer is not allocated in the same memory.<br>
I'm not sure exactly where that fits yet, it would complicate the code<br>
quite a bit. For tiles we're also constrained by OpenEXR buffer<br>
saving, which expects nice regular tiles, so if the tile is split it<br>
still needs to delivered as a single tile buffer.<br>
<br>
So basic answer is that for CPU it could be done quite quickly, if the<br>
GPU is involved it gets messy.<br>
<div class="HOEnZb"><div class="h5"><br>
On Sat, Jul 6, 2013 at 8:31 PM, Matthew Heimlich<br>
<<a href="mailto:matt.heimlich@gmail.com">matt.heimlich@gmail.com</a>> wrote:<br>
> Hey all,<br>
><br>
> First off, I'd like to say that I'm trilled to be part of the Cycles artist<br>
> module. I'm honored to have been chosen.<br>
><br>
> I've been pretty slammed this week, but I've been letting some ideas roll<br>
> around in my head for ways I'd like to contribute in the long run. In the<br>
> coming week I have a bit of downtime and I plan on working up some mockups<br>
> that I think would be beneficial to Cycles development.<br>
><br>
> For now the one idea I wanted to throw out is a method for alleviating the<br>
> dreaded "final bucket" syndrome. Anyone who has rendered a very complicated<br>
> scene on a tight deadline will know what I'm talking about. For those<br>
> unfamiliar, when rendering with buckets it is common for the render to reach<br>
> its final bucket and hit a bit of a standstill as all other processing<br>
> threads finish their jobs and remain idle. This means that for that final<br>
> bucket on a modern processor, you're only utilizing ~12.5% of your<br>
> processor. Over the course of an animation this time can add up to a<br>
> substantial amount of wasted CPU time.<br>
><br>
> My proposal is a method that detects the final tile and separates it into<br>
> tiles of its own equal to the user-defined maximum threads. This will allow<br>
> for maximum CPU usage throughout the entire render process. In the coming<br>
> week I hope to familiarize myself with the code base of Cycles itself (it's<br>
> been a long time coming, honestly) to be able to give more well-informed<br>
> explanations for things like this (and possibly even some of my own code<br>
> contributions), but as it stands now I'm not sure how easy/difficult it<br>
> would be to implement a system like this given the current design philosophy<br>
> of Cycles as a whole.<br>
><br>
> Brecht, is this feasible? After coming to grips with the code base (I may<br>
> poke you on IRC a few times if I run into GPU-related code I'm unfamiliar<br>
> with) this may even be something I could take a stab at myself. I'd love to<br>
> hear your input.<br>
><br>
> Thanks,<br>
><br>
> Matt Heimlich<br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> Bf-cycles mailing list<br>
> <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
> <a href="http://lists.blender.org/mailman/listinfo/bf-cycles" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
><br>
_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-cycles" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
</div></div></blockquote></div><br></div>