Manta Interactive Ray Tracer Development Mailing List

Text archives Help


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


Chronological Thread 
  • From: "Bo Huang" < >
  • To: < >
  • Subject: [Manta] RE: Re: Re: Re: Re: Re: Re: two frame lag?
  • Date: Fri, 30 Apr 2010 17:11:44 -0400
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>>


Archive powered by MHonArc 2.6.16.

Top of page