Re: Synchronizing HW pipes

New Message Reply Date view Thread view Subject view Author view

Angus Dorbie (dorbie++at++bitch.reading.sgi.com)
Wed, 11 Oct 1995 17:17:35 +0100


On Oct 11, 5:13pm, Masanori Kakimoto wrote:
> Subject: Re: Synchronizing HW pipes
> Thank you for the quick response, Angus.
>
> On Oct 11, 7:09am, Angus Dorbie wrote:
> > Subject: Re: Synchronizing HW pipes
> > Try sharing PFCHAN_SWAPBUFFERS, you don't need a swapready on a single
> > host (PFCHAN_SWAPBUFFERS_HW), but you should genlock the pipes, setmon -g
>
> PFCHAN_SWAPBUFFERS should be shared by default among a channel group. Do
> we have to explicitly call pfChanShare to share PFCHAN_SWAPBUFFERS?

Yoy will if you call pfChanShare() with a non default mask, unless you
try:

pfChanShare(chan, pfGetChanShare(chan) | PFCHAN_FOO);

>
> By default, PFCHAN_VIEW is also shared. But the customer calls pfChanView
> for each channel instead of using pfChanViewOffsets and PFCHAN_VIEW
> advantage.
>
> > + wiring. Also try changing the pfPhase to a mode which works for a
> > synchronous swap.
>
> pfPhase(PFPHASE_LOCK) is called after pfConfig.

Try the other phase modes.

>
> > I also noticed you don't update the eye position or animation in the loop,
> > incase it isn't an omition you should do this in the applicaion, somewhere
> > in this loop and not in a callback in cull or draw.
>
> They do call pfChanView in the loop as I commented in the source code
> skeleton.
> > > while (running) {
> > > switch (eventHandling()) { /* pfChanView is called under this. */
>
> The view change is done before pfSync rather than between pfSync and pfFrame.
> This may cause a minor problem in the response to events. But I doubt
whether
> it affects the synchronization among pipes.
>
> I also pointed out to the customer that there might be some possibility that
a
> pfFrame intervenes between pfChanView(middle, ) and pfChanView(left or right,
)
> under some input condition. But they say that does not happen.
>
> The important point of the problem is below:
> > > When they, instead of multipipe, tried using single pipe and multichannel
> > > with MCO, they do NOT have the problem.

Well, it's in the same window and the same rendering process so it wouldn't
show a problem, this just says the problem isn't in the animation code.

> # Sorry for the tense inconsistency of the above sentense.
>
> --
> Masanori Kakimoto mailto:kaki++at++nsg.sgi.com
> East Asia Technology Center, Tokyo Office,
> c/o Nihon Silicon Graphics K.K.
> TEL:+81-3-5488-1852 FAX:+81-3-5420-2397 Voicemail:5-7465
>-- End of excerpt from Masanori Kakimoto

-- 
Angus Dorbie,
Silicon Graphics Ltd, UK
dorbie++at++reading.sgi.com

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:51:57 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.