From: Lee Marden (Lee_Marden++at++res.raytheon.com)
Date: 04/05/2001 05:32:54
Allan,
Thank you soooo much, that makes a lot of sense. Now if you don't
mind, where do I start to fix this? I thought my genlock was ok. I
have the MCO option on each of the three pipes. I believe I've enabled
the MCOs for genlock, with the following script:
set DISPLAY=:0.0
/usr/gfx/setmon -x -S -p 0 2++at++1025x768_60
set DISPLAY=:0.1
/usr/gfx/setmon -g -x -S -p 1 2++at++1025x768_60
set DISPLAY=:0.2
/usr/gfx/setmon -g -x -S -p 2 2++at++1025x768_60
/usr/gfx/stopgfx; /usr/gfx/startgfx &
Does this look correct? I have no way of knowing if this has worked
because the version of /usr/gfx/gfxinfo doesn't give me any details
regarding the genlock status. (I'm running IRIX 6.2)
Assuming that the above is correct, how should the hardware be cabled?
Currently, the intent was to drive the Break Out Box (BOB) for MCO#0
from the output of pipe#0 syncout, then daisy chain the signal to the
other MCOs.
syncout(pipe#0) -> genlock in(MCO BOB#0)
genlock loop(MCO#0) -> genlock in(MCO#1)
genlock loop(MCO#1) -> genlock in(MCO#2)
genlock loop(MCO#2) terminated
I say this was our intent, because there were problems with this.
Unfortunately I wasn't directly involved at the time, but because this
didn't work correctly, the SGI technician cabled it up this way:
No connections from the back of the rack to the BOB MCOs!
No connections to genlock in(MCO#0) or genlock loop(MCO#0)!
Channel#0 H-Sync(MCO#0) -> genlock in(MCO#1)
genlock loop(MCO#1) -> genlock in(MCO#2)
genlock loop(MCO#2) terminated
Basically no genlock signal for pipe#0 MCO#0, then use MCO#0 H-Sync
signal to genlock the other two MCOs. They said that this would work.
Can you confirm that this is a correct setup?
Other Questions:
1) If the genlock signal is working correctly on the MCO Break Out
Boxes, do I need to make any genlock connections on the back of the
rack?
2) How does Performer know that the genlock is not correct, and the
pipes are out of phase? Is there a Performer call that I can make to
tell me this information? Can I write a little Performer program that
just checks for the status of genlock?
3) Does any of this in any way have anything to do with Gangdraw, and
cabling up the swap ready ports on the three pipes?
BTW, I've had two opened SGI support calls on this, and in both cases
they given me a little bit of information, then told me to use this
email list for additional support. I really could use your help.
Thanks,
Lee
Allan Schaffer wrote:
>
> On Apr 2, 10:49am, Lee Marden wrote:
> > I'm having graphics stress related issues with my application on this
> > 3 pipe (6 channel) system. My understanding is that if the
> > pipes/channels are not synchronized correctly, then delays can be
> > introduced in the rendering process. Since both perfly and my app issue
> > this "No Genlock" warning, I thought that maybe my throughput issues
> > might be related.
>
> Let me expand a bit on the details:
>
> Item 1) The PFCHAN_SWAPBUFFERS token for pfChanShare() (specified by
> default) will cause all channels to swap buffers at the same time,
> even when the channels are on multiple pfPipes.
>
> Item 2) Performer will wait for the 'last' pfPipe to finish rendering
> & swap before beginning the next frame.
>
> Item 3) The next frame will start in phase with pipe 0.
>
> So, imagine if the pipes are out of phase with each other: say pipe
> 1 is 3ms "behind" pipe 0. At a certain point each frame Pipe 0 will
> finish its swap and be ready to start a new frame, but Performer will
> still be waiting 3ms for pipe 1 to finish also. Performer will then
> wait for pipe 0 to get to the _next_ frame boundary before starting
> the next frame. That's correct behavior, but you'll be dropping
> frames.
>
> So the long & short of it, it's important to genlock (or otherwise
> phase-synchronize) the graphics pipes when running in a multi-pipe
> config. That's why those urgent-looking warnings appear..
>
> Allan
>
> --
> Allan Schaffer allan++at++sgi.com
> Silicon Graphics http://reality.sgi.com/allan
>
> ------------------------------------------------------------------------
> Name: att1.eml
> att1.eml Type: Outlook Express Mail Message (message/rfc822)
> Encoding: base64
-- ------------------------------------------------------------------------ Lee Marden Raytheon Company Principal Software Engineer Northeast C3I Systems Advanced Modeling & Simulation 50 Apple Hill Dr. (T3MJ21) Technology Section Tewksbury, MA 01876 Phone: (978) 858-9487 Fax: (978) 858-4336 Email:lee_marden++at++raytheon.com Intranet: http://amasts.msd.ray.com/~lms ------------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Thu Apr 05 2001 - 05:33:44 PDT