Author: eilemann@gmail.com
State:
- Software swapbarrier implemented in 0.1
- Hardware swapbarrier (G-Sync) implemented in 0.9
- Multiple-windows-per-pipe software swapbarrier implemented in 0.9
Overview
The purpose of a swap barrier is to synchronize buffer swaps of multiple windows, potentially residing on different nodes.
Software Synchronization
The software swapbarrier uses a net::Barrier together with
a Window::finish to synchronize the buffer swaps without special
hardware support. The finish ensures that all GL commands for the window have
been executed prior to entering the barrier. When leaving the barrier, the
buffer swap is the next command and will be executed immediately.
Software swap synchronization can not guarantee frame-precise sync. The contributing displays are not frame-synchronized with each other, and furthermore a swap command might be executed on video frame later, because it just missed its turn due to timing issues.
The server creates one net::Barrier with the appropriate height
for all swap barriers with the same name.
Multiple windows on the same pipe can join the same software swap barrier. All windows will execute a finish, but the barrier will only be executed by the first window of each pipe. Since all windows have finished before swapBuffers, the first window will block in the barrier, and all subsequent windows will swap immediately afterwards since all commands have been finished already. Each window will flush at the end of a frame to ensure timely execution of the swap command.
Hardware Synchronization (NV_swap_group)
The WGL and GLX swap group extensions use a two-tiered strategy to provide hardware-based swap synchronization. On a single system, all windows join a swap group, which ensures that the buffer swaps happen synchronously. Between systems, swap groups join the same swap barrier for synchronization.
If a swap barrier defines a NV_group or NV_barrier,
the appropriate NV_swap_group extension (GLX or WGL) is used. Setting a
barrier number implies a valid group number.
If the extension is not supported by the driver of window system (AGL), a warning is printed and no barrier is joined.
File Format
compound
{
swapbarrier
{
name "barrier-name" // sync's compound's window swap buffers
NV_group OFF | ON (1) | unsigned
NV_barrier OFF | ON (1) | unsigned
}
}
API
class OSWindow
{
virtual bool joinNVSwapBarrier( const uint32_t group,
const uint32_t barrier ) { return false; }
};
Implementation
NV_swap_group synchronization
Implement GLXWindow, WGLWindow joinNVSwapBarrier. Check if extension is available, if not warn and return false. Do check for max barriers and groups. Barrier and group can be 0 to un-join.
Server sends swap group and barrier as part of the window's config init packet, which are saved on the eq::Window. The OSWindow implementation queries the values in configInit and configExit and calls joinNVSwapBarrier.
Compound::init sets eq::server::Window swap group and barrier. Check that there is only one per window, otherwise warn and overwrite values.
Ignore swap barriers with NV settings in software swapbarrier implementation.
Issues
Only one window per swap group, and therefore system, is supported for current nVidia hardware.