[Bf-committers] The (un)official render daemon discussion
jesterking at letwory.net
Tue Nov 18 19:11:57 CET 2008
On Tue, Nov 18, 2008 at 7:57 PM, Timothy Baldridge <tbaldridge at gmail.com> wrote:
> The fun part will be is that now days, we have quad core systems. What
> we don't want to do is make these systems load 4 copies of blender.
> What should be done instead (in my view) is to tell these systems to
> use 4 CPUs then tell them to render 4 times the number of tiles.
> The initialization time in Blender is fairly fast. Shadow maps and the
> like take some time, but I haven't seen them take all that long.
> We could start with a simple 1 line mathematical scheduling algorithm
> and from there expand the intelligence of the function to take other
> factors into account (speed of the CPUs, number of jobs, etc).
As extra info I'd like to bring BURP (http://burp.boinc.dk) to your
attention. While it being a BOINC-based solution, it should be
possible to set up your own infrastructure that is seperate from the
official BOINC project. With this you have a ready made renderfarm
which can handle easily addition of new nodes or lose them and make
sure workunits are sent out in due time.
As already may be common knowlegde, I work now on a few scripts for
the ORE (Open Rendering Environment) project, which is based on BURP
(the lead developer is involved too). The BOINC/BURP code takes care
of generating workunits from a .blend. Yes, the system still has its
shortcomings when looking at the handling of .blends themselves, but
the rest of it, the network, queue management, etc. is neatly handled
by the BOINC platform.
Currently we're running some test sessions, but I'll make sure I keep
you all updated every now and then. At least, take a look at BURP
already, the ORE link I'll post when it is ready for Teh Public.
More information about the Bf-committers