Text archives Help

---

My silence on the topic below was a combination of agreement and too many deadlines/meetings :)

One thing that would help me greatly would be an sample application in the style you would like to see for an embedded Manta. I've thought a lot about one class of applications (a viewer-type app where the external code feeds Manta objects but the viewer runs autonomously) but your team has obviously thought about some other applications. What I envision is a part-code, part-pseudo code (doesn't even need to compile) that we could use to iterate both on the design and the driver.

The question is - do you have such an app, or would something like ideas (the SGI demo program) be a good prototype?

Steve

On Jun 15, 2005, at 10:03 AM, Rocky Rhodes wrote:

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.