[Bf-cycles] A quick suggestion for tiled rendering

[Brecht Van Lommel]

It's certainly possible, just complicates things somewhat. At the
moment the logic is quite simply but with more advanced pixel
filtering or adaptive sampling having multiple threads cooperate on a
single tile is trickier. We can worry about that later though.

For CPU rendering it can be done in the CPU device by making tasks
more granular than tiles. There is probably some nice balanced tasks
size that doesn't add too much thread overhead based on number of
pixels x samples. Not too hard and nicely localized.

For multi-GPU or GPU+CPU rendering it needs to be at a higher level
however because the tile buffer is not allocated in the same memory.
I'm not sure exactly where that fits yet, it would complicate the code
quite a bit. For tiles we're also constrained by OpenEXR buffer
saving, which expects nice regular tiles, so if the tile is split it
still needs to delivered as a single tile buffer.

So basic answer is that for CPU it could be done quite quickly, if the
GPU is involved it gets messy.

On Sat, Jul 6, 2013 at 8:31 PM, Matthew Heimlich
<matt.heimlich at gmail.com> wrote:
> Hey all,
>
> First off, I'd like to say that I'm trilled to be part of the Cycles artist
> module. I'm honored to have been chosen.
>
> I've been pretty slammed this week, but I've been letting some ideas roll
> around in my head for ways I'd like to contribute in the long run. In the
> coming week I have a bit of downtime and I plan on working up some mockups
> that I think would be beneficial to Cycles development.
>
> For now the one idea I wanted to throw out is a method for alleviating the
> dreaded "final bucket" syndrome. Anyone who has rendered a very complicated
> scene on a tight deadline will know what I'm talking about. For those
> unfamiliar, when rendering with buckets it is common for the render to reach
> its final bucket and hit a bit of a standstill as all other processing
> threads finish their jobs and remain idle. This means that for that final
> bucket on a modern processor, you're only utilizing ~12.5% of your
> processor. Over the course of an animation this time can add up to a
> substantial amount of wasted CPU time.
>
> My proposal is a method that detects the final tile and separates it into
> tiles of its own equal to the user-defined maximum threads. This will allow
> for maximum CPU usage throughout the entire render process. In the coming
> week I hope to familiarize myself with the code base of Cycles itself (it's
> been a long time coming, honestly) to be able to give more well-informed
> explanations for things like this (and possibly even some of my own code
> contributions), but as it stands now I'm not sure how easy/difficult it
> would be to implement a system like this given the current design philosophy
> of Cycles as a whole.
>
> Brecht, is this feasible? After coming to grips with the code base (I may
> poke you on IRC a few times if I run into GPU-related code I'm unfamiliar
> with) this may even be something I could take a stab at myself. I'd love to
> hear your input.
>
> Thanks,
>
> Matt Heimlich
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>