[Bf-cycles] A quick suggestion for tiled rendering

Matthew Heimlich matt.heimlich at gmail.com
Sat Jul 6 20:31:25 CEST 2013


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20130706/75fb9fb3/attachment.htm 


More information about the Bf-cycles mailing list