First, pardon me if the idea presented below has already been done to death.

 From what I've seen, current methods for distributing a render involve 
dicing up the scene and having the separate processors render different 
parts of the scene, but with each processor using the same render database.

I had the half-baked idea of dividing up the render task a different 
way, and that is to split up the rendered scene among the separate 
processors.  One processor decides which rays get traced, and it sends a 
ray-intersection request to each of the processsors.  Each one does the 
tests against a smaller set of the data, and reports the results to the 
controlling processor.  This controller then interprets the results as 
need be.

Pros:
   * Scenes can now be larger without stressing memory limits.
   * Ray-intersection tests take less time.

Cons:
   * Communication time between processors may present an unacceptable 
bottleneck.

Regards,
John

Post a reply to this message

I may well be wrong but I think the overhead for that would be immense - and 
there's no guarantee the workload would be close to even so you might end up 
with one processor idling, waiting for the other one - at least at the 
moment it can "just get on with it".

I know getting radiosity to work on SMP was a pain - not sure what impact 
(if any) your processing method would have on radiosity but I suspect it 
would pretty much put you back in the same boat - for that one pixel, it 
would need to know where (possibly) any object is. (Please take this as 
speculation not fact)

That said, there may well be a better way - I just don't think this is it. 
(But keep thinking!)

Regards,
Simon

"John VanSickle" <evi### [at] hotmailcom> wrote in message 
news:4671e326@news.povray.org...
> First, pardon me if the idea presented below has already been done to 
> death.
>
> From what I've seen, current methods for distributing a render involve 
> dicing up the scene and having the separate processors render different 
> parts of the scene, but with each processor using the same render 
> database.
>
> I had the half-baked idea of dividing up the render task a different way, 
> and that is to split up the rendered scene among the separate processors. 
> One processor decides which rays get traced, and it sends a 
> ray-intersection request to each of the processsors.  Each one does the 
> tests against a smaller set of the data, and reports the results to the 
> controlling processor.  This controller then interprets the results as 
> need be.
>
> Pros:
>   * Scenes can now be larger without stressing memory limits.
>   * Ray-intersection tests take less time.
>
> Cons:
>   * Communication time between processors may present an unacceptable 
> bottleneck.
>
> Regards,
> John

Post a reply to this message

John VanSickle <evi### [at] hotmailcom> wrote:
>    * Scenes can now be larger without stressing memory limits.

  How so? A large scene will take more memory, there's no way around that.
(POV-Ray 3.7 keeps the scene only once in memory regardless of how many
threads are being used, so that's not a problem.)

>    * Ray-intersection tests take less time.

  Actually I bet they will take in total more time than in the current
method. Communication of ray data between the threads could become an
issue. Cache flushings may become an issue.

-- 
                                                          - Warp

Post a reply to this message