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 07:09:12 +0100


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
+ wiring. Also try changing the pfPhase to a mode which works for a
synchronous swap.

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.

Hope this helps,

Angus.

On Oct 11, 2:29pm, Masanori Kakimoto wrote:
> Subject: Synchronizing HW pipes
> A customer has a problem in synchronizing three hardware pipes in an RE2.
>
> They use a pfMultipipe(3) call and three calls of pfNewChan, each of which
> is for each pipe. They have three physical displays, each of them assigned
> to each channel, or pipe. The channel for the middle display is the master.
> The other two channels are pfAttachChan'ed.
>
> The problem is that the attached channels, i.e. left and right displays,
> seem to be constantly delayed by 1 frame compared to the master channel.
> This is true even when the master channel renders most of the polygons and
> the attached channels render much less.
>
> The delay is even more outstanding when the frame rate is reduced by
> changing the parameter for pfFrameRate. The delay is easily noticed by
> moving the camera position vertically and watching the crosspoint of a
> redered horizontal line and a physical boundary of the displays.
>
> When they, instead of multipipe, tried using single pipe and multichannel
> with MCO, they do NOT have the problem.
>
> The skeleton of the main loop in the source looks like the following.
>
> while (running) {
> switch (eventHandling()) { /* pfChanView is called under this. */
> case END_EVENT:
> running = 0;
> break;
> case NEED_ISECT_EVENT:
> if (Needed) {
> isectProcessing(Scene); /* pfSegsIsectNode is called inside */
> }
> continue;
> default:
> break;
> }
> if (running) {
> pfSync();
> pfFrame();
> }
> }
>
> They tried GangDraw using PFCHAN_SWAPBUFFERS_HW and proper wire connections
> and terminations but had the same result.
>
> They also tried CPU locking, which made no difference.
>
> Their Onyx has 8 CPU's each of which should be assigned for Unix, APP, (CULL
> and DRAW)*3 just respectively by their call
> pfMultiprocess(PFMP_APP_CULL_DRAW).
>
> Does anybody have any suggestions? Thanks in advance.
>
> --
> 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.