[Bf-committers] Re: Re: Thoughts on speeding up...

[Ted Schundler]

> Conceptually this would be similar to rendering an image in parts no?
> Only two or more parts rendering simultaneously?
> It would seem to me, however, that this would unfairly separate the work
> load. One part of the image could take *far* longer to render than
> another. Does one thread end up responsible for 90% of the heavy lifting
> while the other twiddles its thumbs?


Well, if you split into small enough chunks, (more than two), and feed
the next chunk to the next available processor, that problem is
reduced.

> Or is there some fundamental way
> the computation can be split up that would make this concept much more
> efficient i.e. one thread performing a specific set of tasks completely
> different from the purpose of the other. Say.. for example (and not a
> technically accurate example) one thread is responsible for doing
> shading calculus while another thread performs the math for raytracing?

Well, that is a standard a producer-consumer problem then. It's
certainly possible, and is an established model for multithreaded
design. (And has simple locking thus no neeed for rollbacks and other
such fun stuff.)

But it would also end up imbalanced if one stage takes more resources
than another, So you'd have to split it into several stages to
guarantee effectiveness instead of just two.

If you design things right, it's not difficult to implement an
effective multithreaded architecture. But it does takes careful
planning from the _beginning_. Adapting something to multithreading
when it isn't designed for it is no trivial task. (And globals all
over the place certainly don't help anything) It's probably more
effort than it's worth at the moment to make a fully mulithreaded
renderer. (Unless someone really wants to rewrite the renderer from
scratch.)

Those for those with multiprocessor systems, you can at least render
your animations on two CPUs at once via command line (or DrQueue
managing the command line stuff for you).