Text archives Help

---

Comments inlined below:

> -----Original Message-----
> From: Steven Parker [mailto:sparker@cs.utah.edu]
> Sent: Tuesday, June 14, 2005 9:50 PM
> To: Rocky Rhodes
> Cc: 'manta@sci.utah.edu'; 'Hansong Zhang'
> Subject: Re: [MANTA] Manta output
> 
> 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


My apologies.  I noticed this, but somehow forgot about it when replying.
Trying hard to muster up good arguments and all...  Although, I'm still not
clear how it works.  All of the threads, but one, return immediately from
the displayImage method call and continue on through the rendering loop.
Looking at RTRT.cc, though, don't they all join at the barrier1.wait call
before actually rendering the next frame, though?


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


Not sure what you mean by a ring-buffer of arbitrary length, especially with
your comment about overwriting the image.  Can you elaborate on this?


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

One philosophical point to make is that most applications will think of
themselves as being "the application" and manta as being "the renderer" or
some such thing.  So when thinking about providing an efficient manner of
incorporating an application into the nicely pipelined execution of manta's
rendering engine it will be helpful to provide a way for the application to
participate in the efficient pipelining without "just" becoming a manta
pipeline stage.  In many of our audio and video libraries, for example, we
have exposed ring-buffer interfaces to the application, allowing them to
continue the no-copy, efficient pipelining semantics we use in our drivers,
but still maintain the illusion of complete control.  ;^)


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


And I'll respond to your responses there.  ;^)



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


Agreed.  Needs some thought.  The general notion is that if complex images
are being rendered, compressed, transmitted, decompressed, and displayed
there are interesting tradeoffs to be made with respect to rendering
quality, frame rate, compression algorithm and ratio, progressive refinement
of both rendered and transmitted image quality, etc.  To allow an
application or system to intelligently make these tradeoffs we need some
kind of feedback mechanism.


> > 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!


The neighbors were late, so they weren't in the pool when I got home.  I did
have to eat a sandwich in front of them, though.  ;^)


> 
> Steve

---

• RE: [MANTA] Manta output, Rocky Rhodes, 06/14/2005
  • Re: [MANTA] Manta output, Steven Parker, 06/14/2005
  • <Possible follow-up(s)>
  • RE: [MANTA] Manta output, Rocky Rhodes, 06/15/2005
  • RE: [MANTA] Manta output, Rocky Rhodes, 06/15/2005
    • Re: [MANTA] Manta output, Steven G. Parker, 06/16/2005

---

Archive powered by MHonArc 2.6.16.