Re: Problem with frame managemnent in Performer

New Message Reply Date view Thread view Subject view Author view

John Rohlf (jrohlf++at++tubes)
Wed, 22 Nov 95 14:44:54 PST


>
> Our company is currently developing an application using a 3 pipe
> ONYX, using IRIX 5.3 and Performer 1.2. The 3 pipes have been
> genlocked together, both via software (using setmon) and hardware
> (cabling the sync, genlock and swapbuffer ports as described in the
> SGI manuals).
>
> During the process of testing the different frame rate controls
> (FREERUN, LIMIT, LOCK, FLOAT) using perfly, I have noticed that the
> draw process does not always start at the proper time when running
> LOCK mode. The draw process will start on a video refresh cycle, but
> not necessarily on a frame cycle. As the frame rate is reduced, the
> problem occurs more often. At 30 Hz, the problem shows up
> occasionally; at 10 Hz, the problem always occurs. Perfly is set up
> to use 3 pipes. The problem of the draw process starting at the
> wrong time may occur in any of the three pipes; there does not appear
> to be a consistent pattern. One pipe will always start properly;
> the other two will start at different refresh cycles. I have also
> informed Paradigm Simulation of this problem (we are using their Vega
> products), and they could re- create it on their equipment.
>
> Since the draw process does not start at the proper time, the frame
> synchronization does not always take place properly. Example: if
> the frame rate is set for 15 Hz, even though the draw process can run
> well within the frame, the frames will drop to 7.5 to 10 Hz. This
> apparently is because the draw process overruns the frame, because it
> started late.
>
> Because of this problem, I find it difficult to write a real-time
> application that will run at the proper frame rate. Has SGI seen
> this problem and if so, is there a fix to the problem ?

        You are encountering a bug in 1.2. The video clocks used
by performer are not synchronized on all 3 pipes so the APP
gets out of phase with 1 or more pipes. The solution is to wait
for soon-to-be-released 2.0 or rendezvous all your pipes
together and call pfInitVClock(0) in each pipe at the same time
to sync the clocks.


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:52:03 PDT

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