Manta Interactive Ray Tracer Development Mailing List

Text archives Help


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


Chronological Thread 
  • From: Abe Stephens < >
  • To:
  • Cc: " " < >
  • Subject: [Manta] Re: Re: Re: Re: Idle/Redraw
  • Date: Tue, 10 Jun 2008 14:26:52 -0600
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:mime-version:subject :date:references:x-mailer; b=EJzot63pfHW1q+cpuZQHUt+rVIvO8aPxiqx8TdKGm5J6WwpFgqOm9KD5g4zj6vE+dB 7uh1IXJQFF6bWxVdw05kNU5l3kBRrxa4GRV4ZnLv7ZkNYbCrOkPaf+QcW0yyGZ4Zs/KK /o28EyCU5KEL1Ntzcq67ugfsy4xCKupZDLiUk=

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