[Bf-cycles] A quick suggestion for tiled rendering

Matthew Heimlich matt.heimlich at gmail.com
Sun Jul 7 03:57:29 CEST 2013

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

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.

On Sat, Jul 6, 2013 at 7:44 PM, Brecht Van Lommel <
brechtvanlommel at pandora.be> wrote:

> 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
> >
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20130706/e1fe3085/attachment.htm 

More information about the Bf-cycles mailing list