Text archives Help

---

Comments inlined below:

> -----Original Message-----
> From: owner-manta@sci.utah.edu [mailto:owner-manta@sci.utah.edu] On Behalf
> Of Steven Parker
> Sent: Tuesday, June 14, 2005 10:08 PM
> To: Hansong Zhang
> Cc: 'manta@sci.utah.edu'
> Subject: Re: [MANTA] Manta output
> 
> 
> On Jun 14, 2005, at 6:11 PM, Hansong Zhang wrote:
> 
> > 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.
> 
> This could be made to work (and I will do it).  However, I think that
> using this has some downsides:
>   - Downstream processing stages compete with Manta for resources (i.e.
> CPUs), and are outside the scope of the load-balancing mechanisms in
> Manta.  Perhaps on a 256 CPU machine you don't mind only using 254 for
> Manta, but on a smaller machine this is more of a problem.


Maybe extending the manta processing pipeline (within the scope of the manta
load-balancing schemes and resource management paradigms) and also allowing
the pipeline to extend beyond manta's borders by the sort of buffering we
propose is the right call.  For jobs running on large machines with CPUs to
dedicate to other tasks, a richer level of engagement with manta can be
supported, while everything can also be bundled within the manta processing
paradigm for other applications.


>   - Subsequent processing of the images always forces a cache invalidate.


Subsequent processing is subsequent processing, whether it takes place
within the scope of manta's processing pipeline or outside of it.  Is this
really the same as the load balancing argument?  A single processor/thread
can perform more of the processing for a piece of the image without mucking
up anyone else's cache if this processing remains in the manta processing
pipeline?


>   - Making Manta wait for a free buffer you are faced with two choices:
> busy wait (keeping the processors hot, which is scalable), or a context
> switch (less scalable, certainly higher latency).
> 


It seems there will always be some kind of flow control policy, either
explicit or implicit (the buffer gets overwritten if not consumed before it
is needed next time around).  Either busy-waiting or a kernel call/context
switch (or a combination of both) can be used for implementing the flow
control policy.  Making it explicit gives the application the opportunity to
assert some control over the rendering engine.  For example, if rendering an
animation loop the application can set up each frame to be rendered exactly
as desired.  I'm not sure how progressive refinement and frameless rendering
fits into the paradigm.  Probably you've thought more about this than I
have.


> I think I can make it work in Manta without requiring it, so perhaps we
> can have the flexibility to do it this way for what you want without
> forcing it to be that way.
> 


Cool!


> > I agree. Let's call it procedural, tight coupling. I believe we need
> > more flexibility than this.
> 
> Okay, makes sense.
> 
> 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.