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 22:44:10 -0700


Steven Parker wrote:

On Jun 13, 2005, at 8:54 PM, Abe Stephens wrote:

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.

I think most opengl programs render some data, and then call swap buffers (on their own context), which synchronizes the client and gpu before continuing with the program. The rendering model we are talking about is different, its asynchronous.

The solution here is that manta needs its own "rendering context" to interact with the output device. This context would be passed to manta by the driving application.

This is essentially what happens in the current code--I just didn't realize it until now--although there aren't any other contexts associated with other threads in the application--and the only other part of the "application" is the X11 input loop.

The context is a low level entity and allows the ImageDisplay to talk directly to the graphics driver or network compression engine, no gui is involved.

(On the topic of vizserver.)

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

I agree that that is probably the best way to integrate with vizserver. Although compressing the images and sending them to some remote client I think is the only type of functionality that we need. The other components of vizserver (host window manager, which doesn't support copy & paste, and x11 stuff) are probably unnecessary.

Besides I'd rather have manta produce a stream of images which we can view on a mac client, or a windows client or any other computer we can write a client for. We could do things like change the lossy compression ratio used depending on system and network performance etc..

(Back to the continuous refresh discussion.)

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.

Eventually some graphics driver is going to reformat all of your data anyways. I don't think its especially important if the code that does this is in a Manta ImageDisplay implementation or if it was written down the hall by the driver team. We're also talking about embedding here- just because manta supported a 384 bit RGB pixel doesn't mean that the driving application will use it.

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?

Let's say we have a portal acceleration structure for our model of a large ship. If I am on the flight deck and something in the engine room turns (maybe 50GB of triangles between me and the movement), why should I have to refresh my image? There is a lot of overhead associated with rendering a new frame and sending it to the client that we can avoid if we can quickly decide the frame doesn't have to be rendered. This is especially true if the animation is never visible.

Although if I can view the model at 30fps, including network--that visibility check had better be very fast.

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'm not as concerned about the processors, I just don't want to send unnecessary frames across the network, ever.

"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.

I'm not sold on the idea that there should be any indication that manta would produce frames forever after you start it.

Perhaps it would be better to say that since the output is completely asynchronous, frames might be generated by some global event after the input stream is consumed--but there is always some event or state change associated with a new frame, somewhere in the system.


Abe




Archive powered by MHonArc 2.6.16.

Top of page