Manta Interactive Ray Tracer Development Mailing List

Text archives Help


Re: [MANTA] Manta output


Chronological Thread 
  • From: Steven Parker <sparker@cs.utah.edu>
  • To: Rocky Rhodes <rhodes@sgi.com>
  • Cc: "'manta@sci.utah.edu'" <manta@sci.utah.edu>, "'Hansong Zhang'" <hansong@sgi.com>
  • Subject: Re: [MANTA] Manta output
  • Date: Tue, 14 Jun 2005 22:49:51 -0600
On Jun 14, 2005, at 7:44 PM, Rocky Rhodes wrote:

I need to take off for the night, but I wanted to make a couple of quick
points before I left. Maybe I'll have time to compose a more well-reasoned
reply tomorrow morning.  (right...)

Sounds like my day(s)!

It seems like we're pretty close to agreement. Currently Manta implements a
callback scheme to indicate that a new frame is ready, as Steve says. One
problem we are having with the current implementation, however, is that it
depends on the Manta thread not just indicating that the frame is ready, but
also effectively drawing it to the display surface. This is problematic
with most of the GUI toolkits we've been playing with, as they are not
prepared to support asynchronous drawing to their display surfaces.

The way that we use this is to open a separate display connection and nest the window inside of the application window.

Also to be considered is the mechanism for flow control of the images passed
from Manta to the GUI. In the current GL display, the semantics of the GL
swapbuffers call enforce this flow control. i.e. when the manta rendering
thread makes the call to swap buffers it can then immediately get started
rendering the next frame. If it gets done before the graphics library is
done with the last buffer, swapbuffers will block the (very fast) rendering
threads until the previous buffer is ready to be used. In FileDisplay, the
rendering threads are blocked until the current image is written to disk.

I think we both agree that we don't want to block all rendering threads
while this downstream processing, like compression, file I/O, network
transmission, etc. is taking place. I'm sure Steve's pipelining thoughts
are directed at solving this.

For the record, even in the current design the rendering threads do not all block for the display - only the one that is performing the display or file write. That is what makes it scale. In rtrt, we used a dedicated thread to perform image updates, but in Manta that thread goes back to rendering once it is done with the display. This gives better performance on small processor count machines.

There is also already a ring-buffer of arbitrary length. However, the current design will overwrite the image whether you are done with it or not.

The pipeline improvements are aimed at allowing deeper/more flexible pipelines. I'll try to work in the throttled ring-buffer too.

If the semantics of the callback were just changed to exactly what Steve
says below, "the frame is ready" (and also some way of getting access to
it), then I think all our problems are solved. ;^) The application/GUI
thread can now do the rendering when notified by manta. The communication
between manta and the GUI thread can be implemented with the same sort of
class inheritance already in place. The GUI-specific code called by the
manta thread can now do something GUI-specific to communicate the existence
of a new image to the GUI thread.

Yes, this should work.

To handle the flow control and allow a copy-free implementation, we are
imagining a ring buffer kind of structure between the app and manta. The
application empties slots and manta fills them up. Another way of thinking
about this is that the app hands out credits to manta for empty image slots
that are then filled up. The app now also has a way of directly controlling
when images are rendered (only give a credit when all of the parameters are
set) or how much buffering there is between manta and the user.

I'll respond to Hansong's message on this idea. I think it could be implemented easily enough but it opens some resource management issues.

One other kinda random thought that I'll stick in here before I head out is
the notion of downstream modules being able to provide feedback to the
upstream modules. For instance, if the network is backing up it might make
sense to compress the images more, in which case there is no point in the
renderer spending extra time refining the images. In fact, maybe providing
a lower resolution image would actually save everyone processing time.

This could definitely use some thought. Perhaps the IdleMode functionality could be broadened into a director/flow-control manager. I'll stick it on my todo list...

Sorry this is rambling and incomplete, but I've got neighbors that are going
to be swimming in my pool before I am as it is now.  ;^)  Gotta go.

Hope you had fun!

Steve




Archive powered by MHonArc 2.6.16.

Top of page