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: Abe Stephens <abe@sci.utah.edu>
  • To: "'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:54:04 -0700
I've replied inline, important stuff is at the bottom:

Steven Parker wrote:

On Jun 13, 2005, at 4:36 PM, Abe Stephens wrote:

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.

Manta reacts to instructions from the user and produces images for the user. What happens after it produces those images is up to whatever invoked it.

In the manta.cc test program, one of the rendering threads invokes opengl calls and sends images to the graphics pipe--so in a way the gui never "touches" the image. Most of the time when manta is run on Altix computers, frames will need to be compressed and transmitted over a low speed network to the user's display. Currently we use vizserver for this, (so the gui doesn't touch the image, but vizserver sure does... ) but we can't run vizserver on the biggest computers because they don't have graphics bricks. Also, if manta will be embedded as a CAD plugin, it seems likely that some handling of the image between manta and the screen might occur.

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.

I'm not claiming it is trivial but this is a visibility query which a scene database could answer.

I claim that these synchronous models do not scale.

Manta already sync's up at barrier1.wait(...) Transactions are applied to system wide data structures. All I am suggesting is that we are more explicit about what the transactions might change--and how Manta responds to those changes.

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 that is a reasonable assumption, however, I would suggest that keeping the processors hot and the rest of the computer hot, and the network between the system and the viewing workstation hot, is unnecessary.

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.

Yes, I think we are beginning to agree. One basic difference is that I see manta as a single component in a larger application, and I think much of the framework views manta as the application. Perhaps it is reasonable for manta's architecture to address both perspectives.

Can we compromise with a statement like:

"In embedded mode, Manta will process a stream of input and produce an output stream asynchronously. Once the input is consumed, Manta will enter a state where it stops producing frames on its output stream and will wait until there is more work on its input stream."

This could be implemented with idle mode. Also the input could instruct manta to animate something in the system, and continuously refresh (essentially continuously producing input).

Abe





Archive powered by MHonArc 2.6.16.

Top of page