On 30.06.11 17:12, Jack Burton wrote:
> "Jack Burton"<nomail@nomail>  wrote:
>> I'm trying to understand the communication between the backend and frontend,
>> particularly when the backend requests blocks of data.
>
> I've made some progress on understanding the communication between the frontend
> and backend, but I still need some clarification (and some painkillers).

LOL, that is (mostly) my code you are looking at ... so I guess I can answer 
your questions ;-)

> I'm attempting to make a distributed version of POV-Ray 3.7 using Open MPI. Most
> of the issues are ensuring that the distributed POV-Ray instances (slaves) get
> the next rectangle/block/tile from a master. I've been trying to isolate exactly
> where to put in various Open MPI commands to send and receive data across nodes.
> I originally looked around the GetNextRectangle() and StartRender() methods, but
> I think I've stumbled onto a possible solution that'll fix distribution (but not
> the image combination, that can come later).

It really depends on what you want to distribute. The GetNextRectangle 
method needs to be fast (and the lists that someone added there will go 
again in a future version as they are a major slowdown, but they will stay 
in 3.7 for now). GetNextRectangle is not the best candidate for a slow 
distributed function, unless you want your instances to mostly idle.

This sitting idle can be solved in several ways: The instances' speed all 
depends on smart assignment of the next block early on. You can select a 
fixed randomised block pattern as simplest solution. Or you assign blocks in 
batches. Or, smarter yet, you start the current block and then immediately 
request the next block (from a different thread), effectively hiding the 
latency of finding the next block.

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.

Either way, be advised that there is some code in 3.7 RC that will also be 
in 3.7, but get cleaned up for 3.7.1 as currently the priority is not on 
easy to understand code, but on getting 3.7 released.

> Would be possible to globally share the various lists and mutexes from the
> master, and update them across a number of slaves that do the rendering, so when
> each slaves backend rendering thread requests data, they do so from an
> up-to-date list.

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.

	Thorsten

Post a reply to this message