Manta Interactive Ray Tracer Development Mailing List

Text archives Help


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


Chronological Thread 
  • From: "James Bigler" < >
  • To:
  • Subject: [Manta] Re: Re: Re: Re: Re: Idle/Redraw
  • Date: Tue, 10 Jun 2008 15:53:07 -0600
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=UQSKZJ4HWItdhhaDU0iqVbt4ykRb4pUaKG4pV70wZvRA1Vpyd59VqymRC+lHoj4JMQ GETZIIVHYLY5J+mjEzuzuPvxeH+XY+R7ClvNINL5bSgh+qhT8oKH8K1UZrzluvvkWr5R GMAReGhLqZJuEK59DFMufh5+mFV/KS+RKoEr4=
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