Nonthreaded Rendering

Author: eilemann@gmail.com
State:

• Implemented in 0.3 beta
• Adapted in 0.4 to reflect changes from per-node thread synchronization

Overview

In order to provide an easier porting path for existing software, this feature adds the capability to update certain windows from the main application thread, i.e., they are nonthreaded. This allows applications with an existing main GUI loop and OpenGL drawables to have them updated by Equalizer, while using additional resources for scalable rendering or as auxilary views. Updating windows from the main thread avoids thread-safety issues with the windowing system and widget library.

Using nonthreaded channels as a source for scalable rendering is not a supported use case, i.e., a nonthreaded channel should not produce any output frames. A nonthreaded channel can contribute to the rendering of its own view, as this does not create any dependency for other channels.

Nonthreaded execution on render client processes happens in the main thread, similar to the execution on the application process.

Implementation

The server will send the rendering commands for nonthreaded pipes exactly as it does send them to threaded pipes. The receiver thread will queue them on the node's command queue, exactly in the same way as for threaded pipe commands. The queued commands will be checked and executed from the config frame functions, which are called by the application thread.

Config::finishFrame will execute all rendering tasks until the local synchronization is released and the frame current-latency is finished.

Reasoning

The main decision is where and when (latency-wise) the rendering commands are executed. The (not yet implemented) cull queue/frame data API will send the data between startFrame and finishFrame. Therefore, the draw tasks have to be executed from finishFrame, otherwise they would deadlock on data when executed from startFrame.

The tasks are executed in the same order as on threaded pipes to keep the order of execution consistent. This means that input frames on non-threaded channels block the application thread, which typically inhibits a latency greater than one, since no new startFrame can be issued.

Non-threaded execution is less important than in Equalizer v0.3, since a new per-node frame synchronization has been introduced.

Implications

Using a swapbarrier or output frame on nonthreaded channels will block the associated threaded channels until the latency has been reached. This partially disables the performance benefits of latency. Note that executing the render tasks early would disable latency by prohibiting the start of a new frame.

API

No changes.

File Format

  global
  {
      EQ_PIPE_IATTR_HINT_THREAD   off | on
  }

  pipe
  {
      attributes
      {
          hint_thread   off | on
      }
  }

Open Issues

Multiple nonthreaded pipes with different window systems on the same node are not supported.

Revisit introduction of window threads.