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 21:32:59 -0600
On Jun 13, 2005, at 8:54 PM, Abe Stephens wrote:

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.

I think that this is useful in some circumstances, but think of the OpenGL model - you feed it data and the image shows up on the screen. You are never given the image back.

In addition to the synchronization, one complication of passing the image

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.

The right way to integrate this with VizServer is to implement a custom component that compresses the images, possibly in parallel, and sends it over the vizserver connection. This could operate without any graphics hardware on the machine. Most CAD plugins could do the same if they absolutely needed to touch the image, but I suspect that (just like OpenGL), very few will.

One of the design goals of Manta is to allow a variety of underlying image formats, which would complicate moving images back through the client.

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.

Honestly, I think that a visibility query is probably beyond the point of diminishing returns. They are expensive, and still wouldn't be conclusive - what if the background was dynamic and you wanted to watch it?

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.

The synchronization model is a "busy-wait" barrier. Idling the CPUs was my concern.

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.

There may be some modes where you want to shut down the processors, and some where you do not.

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.

I agree that it is reasonable to achieve both. I think that most of my disagreements are on the right way to design an application, not on the right way to design Manta.

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.

Yes it can. However, I don't know that it should always be on for embedded mode. The embedded mode is just responsible for selecting a to-be-implemented "quiet the CPUs" idlemode.

Also the input could instruct manta to animate something in the system, and continuously refresh (essentially continuously producing input).

Yes, this is what I mean by a synchronous mode.

One way to implement this is in the current form is to do something like the benchmark mode to quit after one frame. Then keep calling beginRendering to render one frame at a time.

Steve




Archive powered by MHonArc 2.6.16.

Top of page