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