Multi-channel Software Synchronization-code design

I. Purpose of code design

For a summary of the multi-channel synchronization problem, see the article "multi-channel synchronization problem".

This article describes how to use software to implement code design in the synchronous era. It involves two layers: datalock and swaplock. Datalock is used to ensure that each rendering computer updates the same scenario data during each rendering cycle, so as to avoid inconsistency between the scenario content of each computer. Swaplock is used to ensure that frames are switched to the cache at the same moment in each rendering cycle of each rendering computer, so as to avoid non-consecutive images between computers. Winsgl can be used for framelock during Stereo Projection. For details, see the article "multi-channel synchronization problem".

The code design in this article follows the architecture of one synchronization node and multiple rendering nodes. Each node corresponds to a computer, and the synchronization node can be used to update scene data (such as computational dynamics). Each rendering node is connected to display devices such as monitors and projectors.

The Code designed for ease of use must meet the following requirements:

1. Call the registration function (such as registeruserdata (…) in the initialization phase of each node program (......)) Register the scenario data to be synchronized.

2. then, in each cycle of each node program, between the rendering end (such as OpenGL glfinish () and frame switching (such as OpenGL's glswapbuffer, when the synchronous function (Sync () is called, the returned value of this function is the scene data after synchronization. After the function is returned, frame switching is performed immediately to ensure synchronization of frame switching.

Ii. Code Design Ideas

1. The synchronization node establishes another thread outside the main thread (such as the dynamic simulation thread) for processing synchronization.

2. the synchronization node regularly sends scene data to all rendering nodes in the form of fast and unreliable broadcast in the established synchronization thread. The interval of sending is determined by the user who calls this code, for example, the dynamic simulation cycle is used as the timing standard.

When this data is sent, the synchronization node inserts the number of packages currently sent in the packet header, which is used for future synchronization judgment.

3. The rendering node establishes a receiving buffer, receives data sent by the synchronization node cyclically in a separate thread, and saves all received data in the buffer.

4. The rendering node must be synchronized before failover. The rendering node sends a synchronous request packet to the synchronization node. The packet contains the serial numbers of all data packets received by the node itself. These serial numbers are obtained from the buffer zone, and the rendering node is blocked, wait for the synchronization signal of the synchronization node.

5. after receiving the synchronous request signal from the first rendering node, the synchronization node stops sending scene data. It waits for receiving request signals from all rendering nodes. When all request signals arrive, the synchronization node compares the serial numbers in all request signal packets and extracts the last serial numbers shared by each node and puts them in the synchronization package to be sent. For example, the numbers in the first rendering node request package are 2057, 2058, 2060, and 2061, and the numbers in the second rendering node package are 2057, 2058, 2059, and 2060, in the third rendering node package, the numbers are 2058, 2059, 2060, and 2061. Then, the result is 2060.

6. After the synchronization node compares the result, it sends a synchronous signal packet reliably to all rendering nodes. The packet contains the synchronized scene data sequence number (such as 2060 ). After that, the synchronization node can continue to send scenario data.

7. After receiving the synchronous signal packet, each rendering node unblocks the packet, performs failover, and extracts the scene data from the local buffer zone according to the received synchronization sequence number (such as 2060.

8. The rendering node enters the next rendering cycle, in which the synchronization data obtained in 7 is used for rendering.

Iii. Code running result

This code is used on four PCs for multi-channel synchronization. One is used as the synchronization node, the other three are used as the rendering nodes to connect three projectors. The PC is configured as Intel core2 cpu1.86hz, 1.0g memory.

The results show that the rendering nodes REACH completely consistent and continuous screen display, and the resulting rates of the three channels are always consistent. The data test shows that the rendering nodes are waiting for synchronization to spend less than 4 ms.

Note: The 4 Ms time is only a rough data. The specific time is related to the machine performance and the complexity of the rendering program. Further measurement is required.