Manta Interactive Ray Tracer Development Mailing List

Text archives Help


Re: [MANTA] MANTA : Questions about how the parallel pipeline works


Chronological Thread 
  • From: "Steven G. Parker" <sparker@cs.utah.edu>
  • To: Shreekanth Pavar <shreekanth.pavar@ucl.ac.uk>
  • Cc: MANTA <manta@sci.utah.edu>
  • Subject: Re: [MANTA] MANTA : Questions about how the parallel pipeline works
  • Date: Thu, 22 Mar 2007 15:38:57 -0600

On Mar 22, 2007, at 3:33 PM, Shreekanth Pavar wrote:

Here follows a summary of my understanding of how the parallel pipeline works in
Manta:

The Manta main function spawns a manager thread (known as thread 0) which As
in-turn creates as many 'worker' threads as the user specifies (via the command
line or the user interface). Upon creation, each thread (including thread 0)
enters an internal endering loop, from which it asynchronsouly calls the
Rendering Stack.

Context objects are used to move data between Manta components. A RenderContext
is created by each thread to store all the information required for rendering,
including the scene data and the rendering stack components. The populated
RenderContext is then passed into the rendering stack.

A 'Barrier'  synchronization primitive is used to implement thread
synchronization within the rendering loop. This uses a 'wait' method, which
causes individual threads to stop executing until all remaining threads in the
same 'Thread Group' arrive at the barrier point.

As Manta is an interactive ray tracer it's possible for the user to interact
with the image by animating it (rotating, translating and zooming in/out). The
user can also interactively increase/decrease the number of rendering threads.
A special user interface (GUI) thread is automatically created on start-up to
manage these 'Transactions' which are implemented as Callbacks.

Transactions and other Callbacks are queued and only invoked during thread
synchronization at the pipeline barrier (when it safe to update the rendered
state).

Could you confirm if the above is correct ?

Correct.

I have 2 questions about the workings of the above pipeline:

(1) Where exactly does worker::run get called ? I assume it is called by each
'worker' thread upon creation, as it contains the call to
internalRenderingLoop, but I was unable to find any calls to it in the code.

It gets called by the thread library when the thread is started - sort of like main() in a single-threaded program.

(2) In the paper:

Design for Parallel Interactive Ray Tracing Systems
Bigler, J.; Stephens, A.; Parker, S.G.
IEEE Symposium on Interactive Ray Tracing 2006, Vol, Iss., Sept. 2006, p.187-196

Figure 2 shows "parallel animation" being performed by ALL threads prior to
rendering, which I think corresponds to line 524 in RTRT:internalRenderinLoop:

   doParallelAnimationCallbacks(changed, proc, workersAnimAndImage)

I'm unsure why line 523 is needed:

    doSerialAnimationCallbacks(changed, proc, workersAnimAndImage);

These functions handle 'one-shot' callbacks (which are mentioned in the
comments) but I'm unclear what these are and how they differ from normal
callbacks.

The parallel animation callback will get called by all of the threads. The serial animation callback will get called just by one of them. For updating simple state, the serial animation callback is preferred (you do not want multiple threads updating simple data).

One shot callbacks are different. They get called exactly once at some point in the future. The callbacks above are executed every single frame. For example, the -bench flag sets up a one shot callback to occur after 100 frames have been rendered.

Steve






Archive powered by MHonArc 2.6.16.

Top of page