Text archives Help

---

I will attempt to implement it through callbacks and let you know how it goes. However your solution sounds perfectly valid and the only drawback is whatever speed benefit gained by having one thread display while others render. I would imagine the display process is fairly negligible.
Carson


On Apr 30, 2010, at 3:11 PM, Bo Huang wrote:

When I looked at it long ago, I remember eventually realizing Manta is triple-buffered, either by default or I somehow turned it on among the numerous options available. You may want to choose the right buffer to be pulled out.

Moreover, there are some 'if first frame' special cases in the render display loop (I think it's called InternalRenderLoop()?). I very much wanted to remove them, but never figured out how.

-----Original Message-----
From: David E DeMarle 
[mailto:
Sent: Fri 4/30/2010 4:34 PM
To: 

Subject: [Manta] Re: Re: Re: Re: Re: Re: two frame lag?

Thanks!

Normally manta does:
callbacks(f) display(f-1) render(f) //where worker threads skip display(f-1)
So after vtkManta issued callbacks to set up frame f, it had to ask
manta to render twice to get pixels for frame f out.

When the new flag is on, manta does:
callbacks(f) render(f) display(f)

I couldn't figure out how to do it via callbacks as you suggested
before, and I wasn't able to figure out another option, but that
certainly doesn't mean there isn't one.

I suspect there is some good way to overlap the VTK and Manta thread
work as Manta wants, but I don't anticipate getting to that for some
time.

David E DeMarle
Kitware, Inc.
R&D Engineer
28 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-371-3971 x109



On Fri, Apr 30, 2010 at 3:55 PM, Carson Brownlee < > wrote:

Hi David sorry for getting back to you so late,
I believe that will be fine, adding one if statement shouldn't kill
performance.
I believe the intention was to have a modular pluggable pipeline but
that it was never implemented so you're right that changes to RTRT would
have to be made.

could you explain what your code does? if I understand it correctly you
essentially added a second call to display the image which means it
renders twice?  Or am I way off?

however could this have fit into the old code by waiting for an update
through a transaction instead of a custom image display?  The problem
you were having was that you were adding transactions in the image
display, then it would render, then update those transactions, then
render and then finally display correct? Is there something preventing
you from putting a lock in a transaction itself and then unlocking it
when you want to submit scene updates much as you do now? That way you
could run the scene updates as soon as you unlock the transaction and
not have to wait for an extra render cycle.  I'm not sure since I
haven't done this myself but was thinking of trying this out.
Carson

On Tue, 2010-04-27 at 18:45 -0400, David E DeMarle wrote:

So I'm getting back to this now.

I could not think of a way to get the image I ask for out of manta's
two stage pipeline without calling render twice. The caption here and
in the paper imply that Manta's two stage pipeline is configurable,

   http://mantawiki.sci.utah.edu/manta/index.php/Manta_architecture

but I couldn't figure out how to reconfigure it other than by changing RTRT.cc.

Attached is my proposed change. It doesn't speed up vtkManta by two as
I hoped (likely because the render threads are idle while Display is
happening) but it does speed it up significantly. I don't think it
will appreciably slow anything else down either.

MantaBenchmark -threads 8 -triangles 1000000 -fuzziness 0.0 - noChanges
prechange rendering rate = 52.6fps
postchange rendering rate = 70.1fps

Let me know if you've got a better alternative, or I will check mine
in later this week.

thanks,

David E DeMarle
Kitware, Inc.
R&D Engineer
28 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-371-3971 x109

The information contained in this e-mail and any accompanying attachments may contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. The company accepts no liability for any damage caused by any virus transmitted by this email or any attachments.
<winmail.dat>

---

• [Manta] Re: RE: Re: Re: Re: Re: Re: Re: two frame lag?, Carson Brownlee, 05/01/2010

---

Archive powered by MHonArc 2.6.16.