Text archives Help

---

see the pipeline here:
http://mantawiki.sci.utah.edu/manta/index.php/Manta_architecture

I think that is correct if you are forcing a sequential behavior between
m20 and m30 by syncing on image display.  You are correct there is a 1
stage rendering lag (2 renders until display) with your implementation
but a 2 frame display lag (3 calls to image display to display desired
image) so I take back what I said before.

What about syncing during transactions instead of image Display?  Manta
already syncs on transactions and has single threaded callbacks.  This
way you can add the current scene in that transaction when it is awoken
and then proceed to render.

Carson


10 waitOnFrameReady()        REM now the manta threads should be
"stopped" because thread 0 is,
>                 ...                                             REM
>                 process changes in vtk state by issuing transactions
>                 to let manta threads know about it.
>                 60 displayDone()                     REM release the
>                 manta threads, I expect callbacks to be received now
>                 70 waitOnFrameReady()         REM this frame doesn't
>                 show the changes yet
>                 80 displayDone()                     REM let manta
>                 render the frame that has the changes
>                 90 waitOnFrameReady()         REM now the image I get
>                 has the changes in it 



On Fri, 2010-02-05 at 11:35 -0500, David E DeMarle wrote:
> Thanks Carson, but I am not sure I understand what you are saying
> about working in between swap buffer calls. A sample transaction
> follows this diatribe:
> 
> ---------------------------------------------------------------------------------------------------------------
> My understanding is that manta operates as follows:
> m10 GOSUB callbacks
> m20 display last rendered image
> m30 ray trace next image
> m40 GOTO m10
> 
> So when the vtk thread is between 10 and 60, manta is stuck at m20.
> Say manta has frame A ready.
> 
> Line 60 lets manta continue to m30 and it produces frame B. Manta then
> loops and does the callbacks asked for between 10 and 60 in line m10.
> Manta then gets stuck at m20 again, but frame B won't show any of
> them.
> 
> In line line 70 VTK gets frame B, which is useless, so it lets manta
> continue on to ray trace the first frame that has the changes and then
> gets them.
> 
> What am I missing?
> 
>  -
> 
> The paper says the pipeline is configurable, are there any examples of
> how to configure it to run:
> m10 GOSUB CALLBACKS
> m20 RAY TRACE
> m30 display just rendered frame
> m40 GOTO m10
> 
>  -
> 
> Alternatively are there calls I can make to tell manta to abort the
> rest of the current render and more importantly skip the next frame
> display sync?
> 
>  -
> 
> Alternatively, am I just doing something stupid?
> 
> ------------------------------------------------------------------------------------------------------------------
> The transactions are like this one:
> (hypothetically called at line 30)
> //----------------------------------------------------------------------------
> void vtkMantaRenderer::SetBackground(double r, double g, double b)
> {
>   if ((this->Background[0] != r)||
>       (this->Background[1] != g)||
>       (this->Background[2] != b))
>   {
>   this->Superclass::SetBackground(r,g,b);
>   this->MantaEngine->addTransaction
>     ( "set background",
>       Manta::Callback::create(this,
> &vtkMantaRenderer::InternalSetBackground));
>   }; 
> }
> 
> And the manta thread responds by executing this:
> (hypothetically at some time after line 60 and before 70.
> //----------------------------------------------------------------------------
> void vtkMantaRenderer::InternalSetBackground()
> {
>   double *color = this->GetBackground();
>   Manta::ConstantBackground * background = new
> Manta::ConstantBackground(
>     Manta::Color(  Manta::RGBColor( color[0], color[1],
> color[2] )  )  );
> 
>   delete this->MantaScene->getBackground();
>   this->MantaScene->setBackground( background );
> }
> 
> 
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 28 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-371-3971 x109
> 
> 
> On Thu, Feb 4, 2010 at 5:19 PM, Carson Brownlee 
> < >
> wrote:
>         I'm using something similar but only have a one frame lag I
>         believe since I render between swap buffer calls, which works
>         fine when the user is rotating.  transactions fire before
>         rendering, so if your syncing threads in 10 after a rendering
>         is finished and releasing them at 60 then they should be
>         completed before 70, something must obviously be wrong with
>         the additional sync.  What do your transactions look like?
>         
>         Another thing you could try is just launch
>         beginRendering(true) and then put some code in a custom
>         implementation of RTRT to set workers wanted to 0 after one
>         frame is rendered.  This has the overhead of launching threads
>         and won't render between your calls 90 and 10 but eliminates
>         what looks like 3 render calls below.
>         Carson
>         
>         
>         
>         
>         On Feb 4, 2010, at 1:05 PM, David E DeMarle wrote:
>         
>                 I think I am missing something important.
>                 
>                 In vtkManta, the VTK thread sends transaction requests
>                 to the manta threads and uses
>                 SyncDisplay::waitOnFrameReady to wait for them to take
>                 effect before it shows the pixels to the user. My
>                 problem is that there is a two frame lag.
>                 
>                 This is how works now, written from the vtk thread's
>                 perspective (in BASIC)
>                 
>                 10 waitOnFrameReady()        REM now the manta threads
>                 should be "stopped" because thread 0 is,
>                 ...                                             REM
>                 process changes in vtk state by issuing transactions
>                 to let manta threads know about it.
>                 60 displayDone()                     REM release the
>                 manta threads, I expect callbacks to be received now
>                 70 waitOnFrameReady()         REM this frame doesn't
>                 show the changes yet
>                 80 displayDone()                     REM let manta
>                 render the frame that has the changes
>                 90 waitOnFrameReady()         REM now the image I get
>                 has the changes in it
>                 
>                 The effect is to halve the framerate, since I always
>                 have to ask manta to render twice to see what I ask it
>                 to draw.
>                 
>                 Is there some good way to obviate the need for lines
>                 80 and 90?
>                 
>                 David E DeMarle
>                 Kitware, Inc.
>                 R&D Engineer
>                 28 Corporate Drive
>                 Clifton Park, NY 12065-8662
>                 Phone: 518-371-3971 x109
>         
>         
> 

---

• [Manta] two frame lag?, David E DeMarle, 02/04/2010
  • [Manta] Re: two frame lag?, Roni Choudhury, 02/04/2010
  • [Manta] Re: two frame lag?, Carson Brownlee, 02/04/2010
    • [Manta] Re: Re: two frame lag?, David E DeMarle, 02/05/2010
      • [Manta] Re: Re: Re: two frame lag?, Carson Brownlee, 02/05/2010

---

Archive powered by MHonArc 2.6.16.