Manta Interactive Ray Tracer Development Mailing List

Text archives Help


Re: [MANTA] Re: Asynchronous i/o in manta and conventional gui's


Chronological Thread 
  • From: Steven Parker <sparker@cs.utah.edu>
  • To: Abe Stephens <abe@sci.utah.edu>
  • Cc: "'manta@sci.utah.edu'" <manta@sci.utah.edu>
  • Subject: Re: [MANTA] Re: Asynchronous i/o in manta and conventional gui's
  • Date: Mon, 13 Jun 2005 19:58:41 -0600
On Jun 13, 2005, at 4:36 PM, Abe Stephens wrote:

[This thread started on a subset of the manta list, but it might be interesting to a wider audience.]

Maybe my disconnect here is that manta really has its own control loop which is separate from the gui toolkit's. The question is, how does the gui toolkit (or whatever is reading the frames) know how often to load a new frame from where ever the renderer leaves it?

It seems like what we really want is for the readiness of a new image to be treated as a message event type inside of the gui framework, just as a keystroke would be. I doubt this functionality is available inside glut, does anyone know if it is available in other toolkits?

The question is whether you want the GUI framework to even touch the image. I claim that the answer is "no", in most situations.

Steven G. Parker wrote:

I think one side effect of the implementation is that manta's rendering loop iterates continuously. This is fine for benchmarking but we will certainly not want to continuously render the same image over and over for most applications.


For animating scenes, you do want it to update continuously. Also, if you stop the rendering there can be noticable latency in waking the threads back up when you want to start again. Nevertheless, there is a way in Manta - called an IdleMode. The idea is that you can register a component to do something when nothing is changing, like putting the workers to sleep. This capability needs a little more work but I think it is the right way to do it.

Would we ever want to render the exact same image twice in a row? Eventually the animation would end--or at least not need to be displayed.

True - and the idlemode would be triggered to do something else - perhaps re-render the frame with a higher quality, perhaps

Imagine a mechanical part that spins continuously, even though the animation could go on forever, if it is moved out of view of the camera, there is no longer a reason to keep refreshing the image.

This is harder - you don't always know that the changes are visible, only that changes are made.

In a shared environment, after I stop moving my camera, all of the processor time should be devoted to rendering frames for your camera.

A shared environment is definitely a challenge. A shared environment may also need to accommodate different instances of Manta. In this case, I think that a fine-grained load-sharing system should be developed that assigns resources in a similar way to a traditional batch scheduler, but is dynamic. This model is compatible with the idlemode functionality in Manta.


Do we have an explicit model for control in Manta? If not, I would propose that manta work through a queue of transactions. These might alter the state of one channel pipeline or some global variable. The most basic assumption we can make is that transactions in the global queue, require all pipes to refresh, and transactions in the local queue only require a specific pipe to refresh. After all of the global and local queues are idle, the engine can stop rendering and wait for more input.

I claim that these synchronous models do not scale. Keeping the processors "hot" is the lowest latency mechanism. The IdleMode allows you to (among other things) release resources during periods of inactivity.

I think that the IdleMode can do what you describe above. It would just need a slight tweak to distinguish per-pipe changes from global changes.

Steve




Archive powered by MHonArc 2.6.16.

Top of page