Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!motcid!stephens
From: stephens@motcid.UUCP (Kurt Stephens)
Newsgroups: comp.graphics
Subject: Re: Distributed Ray Tracing (should be Parallel RT)
Keywords: ray tracing, parallel
Message-ID: <6686@celery34.UUCP>
Date: 8 Mar 91 19:50:58 GMT
References: <6678@celery34.UUCP>
Distribution: comp
Organization: Motorola Inc., Cellular Infrastructure Div., Arlington Heights, IL
Lines: 71

stephens@motcid.UUCP (Kurt Stephens) writes:
>	Most implementations (I've seen or heard or) of distributed ray
>tracing, distribute the object database between multiple processors and

Ooops! I realized the improper terminology just after I sent the post...

>each processor computes a subset of the image.
>	Has any research been done on distributed ray tracers
>which each processor handles the ray-object intersections for
>subset of the database, while a master processor (or group of
>master processors) computes the image, by sending messages to the
>appropriate object processor, e.g. "intersect ray X with object Y"?
>	For the sake of discussion, what would be the
>advantages/disadvantages of "slicing" the database rather than the
>image?

>	Some Advantages:

>	1. Each object processor only needs a subset of the
> object database
>	2. Each object processor would only need the intersection
>routines, and not the entire ray tracer.
>	3. Because of #1 and #2, setup time in a massive scale
>multiprocessor would be reduced. 

>	Some Disadvantages:

>	1. Many object processors could be idle, waiting
>for signals to process an intersection.  In this case, "image slicing"
>might be more efficent.
>	2. The master processor could be a bottleneck.
>	3. Inter-processor message I/O could be a bottleneck.
>(millions of little Ethernet packets... ;^)

>	Any comments?

Nicholas Wilt (npw@eleazar.dartmouth.edu) writes:
NW:I have seen netters allude to two competing techniques of parallel ray
NW:tracing.  Both seem to be targeted for groups of networked machines.
NW:The scheme you propose requires machines to communicate during
NW:computation; this is very different from telling each Sun on a network
NW:"You do this part" and splicing together their results.  Your proposal
NW:is very feasible for massively parallel machines which have special
NW:hardware for interprocessor communication, but even a high-speed network
NW:may not have enough bandwidth to make your scheme feasible on a group
NW:of networked machines.

Jonathan Leech (uunet!mcnc.org!cs.unc.edu!leech) writes:
JL:    My idea was to split the database spatially using bounding volumes
JL:ala Kay (not surprising since he worked in the same lab at the time
JL::-), replicating the top levels of the bounding volume tree on each
JL:node.  Then the 'master processor' would just distribute blocks of
JL:rays; each node would be responsible for two tasks, intersecting
JL:primary rays against the global bounding volume tree and sending
JL:requests for intersections with leaves of that tree, and satisfying
JL:other node's requests for intersections with the leaf of the tree it
JL:contained.  Load balancing is accomplished by not sending blocks of
JL:primary rays to the nodes doing a lot of the second task.  As it turns
JL:out, I was scooped before I got very far - see _The Visual Computer_
JL:about 2 years ago - but their implementation indicates the technique
JL:does work.
JL:    I would avoid doing this on a network of workstations, which
JL:usually have enough memory.  This is more for MIMD machines like
JL:hypercubes.  You could use buffering strategies to cut down on
JL:traffic, but why bother.


-- 

Kurt A. Stephens		Foo::Foo(){return Foo();}
stephens@void.rtsg.mot.com	"When in doubt, recurse."