This example clearly illustrates how rethinking parallelism can result in a decomposition that is better suited to scaling. This example also emphasizes building your own structures with Threading Building Blocks tailored to your particular specialty. You’ll find more information and downloads on the Web for the particular gaming framework used here. For the purposes of this book, we’ll focus on the key design decisions and show the code that uses the task scheduler directly.
Games, like many programs, have been threaded for the sake of convenience rather than performance. Specifically, games have often been threaded along function lines and nothing more. In order to fully utilize many cores, this example shows how to thread a game using a functional pipeline with domain decomposition. This example demonstrates several ways to reach the next level of scalability in game architecture. Most threading of games has traditionally focused on functional parallelism and data parallelism. The former is pretty straightforward: one thread for rendering, one thread for physics, and so forth. Data parallelism generally comes in waves with serial interludes, as shown in Figure 11-24.
In this example, we concern ourselves with rendering stars after determining positions based on physics. We go beyond data parallelism to discuss domain decomposition, which has the structure shown in Figure 11-25.
The principle performance advantage of this structure is that a group of stars each form a domain task that is treated as a large single task with several data parallel sections, instead of scheduling each region and then each star separately. The computations take advantage of knowing that several nearby stars are in the same domain to avoid most of the threading synchronization overhead. It has been shown in many supercomputer applications that this simple domain decomposition principle helps scalable performance considerably. This is especially true in games where some significant sections are serial and the need to produce many frames-per-second synchronization penalties are paid many times over.
By developing a simple example game architecture, you can keep the threading architecture design issues simple and clear enough to experiment with, and thus demonstrate the best threading methods for real games.
When you run the example, a window will appear that shows marble-like stars moving around in space under the force of gravity between each of the other stars and a black hole. Figure 11-26 shows a view of the game in progress. By setting the Count of object stars and the simulated computational Load in the fill-ins on the right, you can model the complexity of a simulated k-d tree data structure. At the top of the window, you can see various performance data, such as the frames per second (FPS), the operations performed in Serial mode, and the number of stars in each of the eight object domains: 15 15 09 12 11 11 14 13.