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

[Austin Benesh]

It might not necessarily take an entire rewrite. True, global structs get
annoying, but they actually do help. What is needed is a file named
threadrender.c that contains BL_thread calls that call SDL_thread calls that
are called by BL_render calls. Do you get it? ;)

-- Austin
-----Original Message-----
From: bf-committers-bounces at projects.blender.org
[mailto:bf-committers-bounces at projects.blender.org] On Behalf Of Ted
Schundler
Sent: Thursday, March 24, 2005 7:48 PM
To: desoto at blender.spaceisbig.com; bf-blender developers
Subject: Re: [Bf-committers] Re: Re: Thoughts on speeding up...

> 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).
_______________________________________________
Bf-committers mailing list
Bf-committers at projects.blender.org
http://projects.blender.org/mailman/listinfo/bf-committers