Hey,Thorsten.

Thanks for your reply!

> Or, of course, you limit OpenMPI to the frontend only and run independent
> backends. This may (or may not, depending on how smart you make the
> frontend) mean you can most effectively render animations. The benefit here
> is that you need next to no changes to the core code, and also you don't
> need to bother with the rather difficult o distribute features, like
> radiosity.

Yes, the idea is to modify the frontend only, but I need to understand
what/where the crucial data is that specifies which thread does what block. Open
MPI (as an API at least) isn't all that complex to use, it's just identifying
the correct place to make the changes! ;)

> I am not sure why you would want to globally share mutexes, and I am not
> sure what lists you are referring to specifically, so i cannot really give
> you an answer here.

I'm referring to the lists (e.g. blockBusyList) and mutexes (e.g.
nextBlockMutex) in view.h.

The idea of sharing the lists and mutexes is to record which blocks which have
been rendered and which blocks are being rendered, so all of the slaves in the
distributed setup can render the correct block and avoid duplication of blocks
and avoid unnecessary communication. The mutex (as I understand it) is to stop
the local threads accessing the lists at the same time, so this would be needed
for a distributed scenario, too; basically the lists need to be thread-safe
across multiple slaves.

During initialisation, I think each slave needs the parse the scene and have a
copy of the viewdata...but I'm still a little unclear on this. Anything you can
point to help me understand would be great.

This probably isn't the best design, but it probably is the fastest to code as I
need to wrap this up in the next month or so.

Post a reply to this message