From: Don Burns (don_burns++at++peru.engr.sgi.com)
Date: 01/14/2000 21:29:25
Well, since my name's been mentioned...
Synchronization of multiple views amongst loosely coupled systems is really a
real-time issue. The better the method the better the quality.
The demo mentioned was shown at IITSEC this year and employed the simplest
method. It was simply a one-way update of eyepoint, broadcast to anyone on the
network who cared to listen. The UDP packets (simply no need for TCP, too
slow, too much latency and unecessesary contention of the network bandwidth)
were sent at a constant rate, which is faster than the graphics was updating.
During the APP phase (single proc Performer on Linux), on each of the
recieving systems, the queue is emptied and the final value used for XYZ, HPR.
This provides a reasonable (should we say "good enough" in some cases) method
of synchornizing the eye point to within about a frame or two of each other.
For applications that don't use contiguous viewing channels that will be
displayed side by side, this can be fine. It would be stretch to call this
truly synchronized, however. If displayed side-by-side, the disparity of frame
synchronization is actually quite apparant.
The next form of synchronization is to use frame-lock. An external
synchronization source can be used to keep vertical retrace on multiple systems
in step. This is sometimes mistakenly referred to as genlock. (Genlock synchs
the entire signal - vertical and horizontal). This can be used in conjunction
with the network broadcasting method to attempt to keep all eyepoints
refreshing the screen at the same time. Some two-way traffic may be necessary
to insure that all channels have the same eyepoint for the current frame. This
depends also on the graphics hardware's capability to swap buffers on vertical
retrace.
It seems that some of the PC hardware has become caught up in chest thumping
about how fast they can run Quake, measure purely on a frames per second basis.
To exceed 60 hz, the block on vertical retrace is not used and thus the
graphics may sometimes swap buffers in the middle of a vertical retrace. This
can cause anomolies such as "tearing". Unless you can block on vertical
retrace, there is little frame-lock can do for you.
A swap ready signal can also be used in conjunction with either a genlock or
frame lock signal. This provides one more step for insuring that the same
frame is displayed on all channels at any given moment.
-don
PS. Not sure this all has a true bearing on the subject (clustering), but it
is interesting for visual simulation.
This archive was generated by hypermail 2b29 : Fri Jan 14 2000 - 21:29:41 PST