[Bf-cycles] A quick suggestion for tiled rendering
shadowrom at me.com
Sat Jul 6 23:10:20 CEST 2013
I was thinking about this too recently. I wonder if it would be possible to parallelize the CPU bucket rendering to utilize all available threads on one bucket (like it is done on a GPU) instead of rendering multiple buckets.
This would avoid the "last bucket" waiting.
Am 06.07.2013 um 20:31 schrieb Matthew Heimlich <matt.heimlich at gmail.com>:
> 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.
> Matt Heimlich
> Bf-cycles mailing list
> Bf-cycles at blender.org
More information about the Bf-cycles