[Bf-committers] The (un)official render daemon discussion

[Timothy Baldridge]

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).


Timothy

On Tue, Nov 18, 2008 at 11:19 AM, Lars Nilsson <chamaeleon at gmail.com> wrote:
> On Tue, Nov 18, 2008 at 12:03 PM, Kent Mein <mein at cs.umn.edu> wrote:
>> I think we need to think about this also from a picture vs animation
>> framepoint.  When doing an image you obviously want to do the stiching
>> but if doing an animation, it probably makes more sense to give each
>> node a frame and or a block of frames to work on instead.  The system
>> should be able to handle this.  (Or just go the frame route if you
>> want to keep things simple.)
>
> tSNet allowed for splitting still images into pieces and used full
> frames for animations. Seemed like the simplest way of allowing
> multiple machines to evenly split the amount of according to the power
> of each machine. Whenever a machine finished it was working on, it'd
> get another work unit. Over time faster machines do more image pieces
> or frames than slower machines, and not a whole lot of idle time,
> until the very last bits, when a slower machine might be responsible
> for the finishing the job.
>
> Another side-note, as far as trueSpace is concerned, there's a certain
> amount of up-front effort made by trueSpace before it starts to
> render, so making pieces too small could have a detrimental effect on
> overall speed, if too much time is being spent initializing stuff for
> rendering, rather than doing actual rendering on larger pieces.
> Whether the same holds true for Blender or not, I don't know, but if
> one imagine you need to create some intermediate file or whatever to
> feed a render engine for each request, based on a .blend file, the
> more times you have to do it, the slower it will be in direct relation
> to the time it takes to do this work. Built-in renderers would
> presumably have less of a overhead, while external renderers might be
> slightly worse in this respect. Hope this comment make sense.
>
> Lars Nilsson
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
Two wrights don't make a rong, they make an airplane. Or bicycles.