Manta Interactive Ray Tracer Development Mailing List

Text archives Help


[Manta] Re: Re: Re: Re: Re: Re: Idle/Redraw


Chronological Thread 
  • From: Abe Stephens < >
  • To: MANTA < >
  • Subject: [Manta] Re: Re: Re: Re: Re: Re: Idle/Redraw
  • Date: Tue, 10 Jun 2008 17:37:22 -0600
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer:sender; b=Fx7GSAcPYwfKASqkyjS4a2n3hPM200H/9se6RMwKqKHr/z7Ft4PoSax+O8iXYlN6ZI cxepRz0QNkDYbofkwPg9w7amE2VafiOF64YKDxGf+wArcK7YriIHJ66/pbfIVnuos85q JHJ3M+az89xYYkXuM/ZRmsOkVv2JLwQl5M8Lk=
I just added table to the wiki describing the eight Manta callback types.

http://code.sci.utah.edu/Manta/index.php/Manta_architecture#Transactions_and_Other_Callbacks

Abe

On Jun 10, 2008, at 4:50 PM, Abe Stephens wrote:

It looks like (according to svn blame) the code that locks the callbackLock for reading was commented out by Steve in r0002 ;-). I'm not sure how this could be thread safe since the callback vector could be moved when something is added by an asynchronous thread. I guess this case is pretty rare- most callbacks are setup before the renderer is started and don't change, The transaction lock is still used when transactions are executed.

I'm working with a similar mechanism to what James described- synchronizing with another thread for image display-- if you are displaying Manta frames using something besides GLX you'll probably want to use something similar (this is how the python GUI works).

Abe

On Jun 10, 2008, at 3:53 PM, James Bigler wrote:

I would be careful blocking on a semephore within a callback.  When
you run callbacks, you lock the callback list with a mutex.  Any
thread that attempts to create a callback will block, and you could
get dead lock.

Look at the Engine/Display/SyncDisplay. This is a helper ImageDisplay
class that uses a semephore to notify an external thread that it is
ready to render a frame.  You may create a new one or a similar one
that blocks the pipeline until the an external source says go ahead
(block after rendering the frame). This also may be less ideal, since
you will get a one frame latency.

The deadline image traverser still consumes CPU, just not as much as
you constantly render the frame.

James

On Tue, Jun 10, 2008 at 2:26 PM, Abe Stephens < > wrote:

The design evolved this way because in many situations the image constantly
changing (animation is a function of time) and the ray tracer is the
performance bottleneck.
In these cases the ray tracing loop determines the application's refresh
rate--and the GUI operates asynchronously. GUI event loops vary in frequency
between about 5-40hz framed rendering attached to those loops tends to be
very non-uniform in time. Another reason, which only applies to very large
machines, is that there is overhead associated with starting up a large
number of threads--or switching from one memory intensive program to
another.
If your application is offline (like rendering movies), the data set isn't
time varying, or the ray tracer isn't the performance bottleneck, it might
make sense to start and stop the entire renderer. It's also possible to
cause the ray tracing threads to block on a semaphore and synchronize ray
tracing with a control loop operating at a different frequency.
I'd recommend the second approach in this case- it doesn't require modifying
the image traverser, or any of the manta internals-- just create a serial
animation callback that synchronizes with the outside thread each frame.
(There are primitives for doing so in Core/Thread/.) State updates sent to
Manta while it is idle will be committed before the next frame is rendered-
but all of the threads will be completely idle. Manta rendering could either
proceed in lock step (using barriers) or semaphores could be used to signal
that the renderer should pause or resume.
The third approach would be to embed the VTK update procedure inside the
Manta control loop using parallel animation callbacks. I haven't worked with
VTK in about five years so I don't know how great a task this would be. If
the VTK update is serial, or if there is a simple interface to embed it in
multiple threads, it would be easy.
Abe
On Jun 10, 2008, at 2:04 PM, Solomon Boulos wrote:

This isn't unreasonable at all. I added similar functionality to the
deadline image traverser a while back.

To do something like this, I'd suggest you make an image traverser based on
the tiled image traverser but augmented with behavior similar to the
DeadlineImageTraversers short circuit return when no work is needed. This
way manta is still responsive to state changes (the transactions still fire
etc) and its fairly easy to do.

Solomon

On Jun 10, 2008, at 12:27 PM, Li-Ta Lo 
< >
 wrote:


On Mon, 2008-06-09 at 14:24 -0600, Abe Stephens wrote:

Manta is designed to run at the maximum frame rate possible (like a

video game) it is never idle. If your application needs to do

something else during the rendering loop with the cores running manta

threads, perhaps that activity could be placed inside of a parallel

animation callback?


Why do you want to draw exactly the same thing over and over? Shouldn't

most GUI applications be event driven and redraw the scene only when it

is necessary?

It is possible to force synchronization between Manta threads and a

GUI (for example) by adding a serial animation callback that waits at

a barrier shared with the GUI thread. You'd need to use the

synchronization primitives in Core/Thread/. It seems likely that ray

tracing will be the bottleneck in most traditional graphics

applications- is this not the case in your situation?


I am not so sure what I am expecting. When integrating Manta with VTK,

I would like to make Manta drawing a scene only when the VTK pipeline

has (new) data/primitive ready. The VTK pipeline may have a very large

dataset or are very computational intensive and I want the raytracer

yield the processor to the pipeline.

Ollie





Archive powered by MHonArc 2.6.16.

Top of page