Text archives Help

---

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

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.

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.

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.

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.

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.

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.  

        Rocky


> -----Original Message-----
> From: owner-manta@sci.utah.edu [mailto:owner-manta@sci.utah.edu] On Behalf
> Of Hansong Zhang
> Sent: Tuesday, June 14, 2005 5:11 PM
> To: 'manta@sci.utah.edu'
> Subject: Re: [MANTA] Manta output
> 
> Steven G. Parker wrote:
> 
> > ... The difficulty is that  Manta is pipelined, so rendering a frame
> > and waiting for the result  is not an appropriate model.  The power of
> > it is that these  operations occur in parallel, so for example you
> > could have a  parallel compression of the image stream for handing to
> > vizserver.
> 
> Waiting is certainly not the right model. But I think this situation is
> no more complex than  other situations in which you don't want to wait,
> for example hardware occlusion query. So, standard ways of handling this
> should work, like cycled buffers with ready/consumed flags or a FIFO.
> 
> >> I believe that when other apps like Catia connects to Manta's
> >> output, it would want to do so at the buffers level (i.e. data
> >> protocols, not class inheritance).
> >
> > class inheritance isn't the right word for it.  The question is how
> > does the external application know that a buffer is ready.  There are
> > two options:
> > 1. The app says "render this frame", and waits for the result.
> > or
> > 2. Manta makes a callback when the new frame is ready.
> 
> What about a third option: Manta exports a buffer with a ready flag, and
> the downstream module checks the ready flag if/whenever it wants. If
> Manta's ready to output again and finds that a buffer has not been
> consumed by downstream, it uses another buffer/flag set (effectivelfy
> forming a FIFO of buffers). When downstream fininshes using a buffer, it
> sets the consumed flag on the buffer so that Manta can reuse it.
> 
> Such coupling is more flexible than a callback. If the downstream is a
> separate process, the FIFO can still be done in the shared memory. If
> the downstream is on the different machine, the FIFO can be easily
> translated into a wire protocol.
> 
> > So I don't think of this as class inheritance.  The fact that
> > inheritance is used is merely to provide the callback, but a C API
> > could be made to work with this.
> 
> I agree. Let's call it procedural, tight coupling. I believe we need
> more flexibility than this.
> 
> Hansong

---

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