Multithreaded renderer

From DoomWiki.org

A multithreaded renderer allows to split the work of rendering the image to several different threads, which on multi-core processors can result in greatly increased performances and enable the software renderer to be scaled up to higher resolutions.

One of the main weaknesses of the Doom engine's software renderer on modern hardware is that it was designed to run on single-core processors, which coupled with the fact that CPU power is nowadays increased through the addition of more and more cores rather than by enhancing each core's processing power, can lead to even mid-to-high range PCs struggling to render modern maps at a stable 60 fps at high resolutions. Furthermore, as a software renderer the Doom engine is entirely CPU-bound, a result of Doom and Doom II's development taking place long before the first 3D accelerator chipsets for the PC, such as 3dfx Voodoo, VideoLogic PowerVR, and Rendition Vérité, started appearing on the market in 1996; this means the CPU cannot offload large parts of the rendering process to the GPU, further increasing the necessity for high clock speeds to render complex scenes.

A first step to overcome this limitation can be to split off the various tasks (game logic, music playback, sound rendering, video rendering) into separate threads. However, it can only go so far. The main factors on performances are game logic (when there are a lot of active mobjs) and video rendering, especially at modern high resolutions for complex detailed scenes such as in Planisphere 2 or The Given. Game logic cannot be properly parallelized without breaking predictability and potentially causing mutex locks due to interactions between the thinkers; the rendering engine, on the other hand, can.

Typically the parallelizing is done by splitting the screen horizontally, giving each thread an area of the screen to render from top to bottom. The rendering slices do not have to have the same size, as the complexity of the scene is not usually uniformly distributed. To balance the load across the threads, the size of each slice should adapt in real time to the scene.

A drawback of parallelizing the rendering is that it can create occasional glitches in the rendering of sprites when they lie across a boundary between two worker threads, as one thread may render the sprite while the other does not, creating a cut that would not happen with rendering on a single thread.

Source ports with multithreaded renderers[edit]