After processor technology improvements slowed with the gigahertz race in 2004, a new era in consumer computing emerged with the first multi-core processor to reach mainstream markets. Along with the doubling of processing cores came the promise of doubling the performance, but now, years later, we all know that’s still not the case for some of our favorite applications.

Utilizing the full capacity of multi-core processors requires multi-threaded applications, and developing properly threaded software is a different and more difficult task than traditional coding.

Game development is one area that has lagged behind in the progression of multi-threaded software. With a typical coding structure that involves basically one enormous while loop, games have epitomized single-threaded programs that fed off the pure speed of the processors involved in the gigahertz race.

Now that we are moving in the direction of "more cores" rather than "more clocks," game developers need to adjust their programming models and mindsets to take advantage of the hardware available to the PC and even console gaming communities.

As any modern coder knows threading can be difficult, but although initially constructing a many-threaded game engine requires a significant effort, the reward will no doubt be worthwhile and could span years into the future. (For more details, refer to "Designing a Parallel Game Engine" by Jeff Andrews on http://whatif.intel.com.)

As a manufacturer of multi-core processors, Intel obviously has an interest in promoting the proper techniques that will utilize the full horsepower of its processors. With this intent in mind, Intel developed Smoke, a dual-purpose framework and tech demo that emphasizes the advantages of multi-threaded gaming that is correctly implemented.

It also shows game developers how thread management, resource sharing, and workloads can be balanced to create a highly modularized and flexible gaming engine for both today’s and tomorrow’s CPUs.

What is Smoke?

Smoke is a model framework that maximizes the performance of the processor in a purely gaming environment. Built to take advantage of all available threads, it works equally efficiently on standard dual-core Intel Celeron processors as well as on new Intel Core i7 Processors with Intel Hyper-Threading Technology.

The Smoke video demonstration, shown at many trade shows and technology events, uses modern game-development technologies, including Havok for physics processing, FMOD for audio playback, Ogre 3D and DirectX 9 for graphics rendering, and more. As you would expect for an internally developed demo, the code shows the Smoke framework as a well-partitioned and configurable product.

Intel developed Smoke mainly as a teaching tool to demonstrate the ability to create a framework that can scale to any number of threads. Developers are encouraged to explore the technology by examining new threading techniques and learning about the interactions between various game engine systems that typically hold back a game’s potential threadability.

Intel’s goal through this and other efforts is to help prove that multi-threaded gaming can be done effectively and is an investment in time that is worth taking.

The Smoke Framework

The simplicity of Smoke’s framework design (see Figure 1) is obvious once it is broken down into its various pieces, and doing so clearly shows how the software enables hardware with N-threads to function efficiently.

Figure 1. Smoke framework.

The framework’s design is built around a Scheduler that manages system jobs and a Change Control Manager (CCM) that is responsible for minimizing the traditional drawback of threaded games: thread synchronization. The data structures share data between the various jobs and threads in the Smoke framework and are designed to support independent processing and system modularity with easy-to-develop interfaces.

The Scheduler is the logical component that manages the various system jobs that are determined by each individual system. Once each system implements the proper interface, that system is able to interact with the framework easily and efficiently.

Figure 2. The CCM is responsible for inter-system communications.

The CCM (see Figure 2) reduces the framework’s dependence on heavy thread synchronization operations. For example, if the physics API system changes an object that is also registered with other systems, instead of sending that change to them directly, the other systems are notified of the change at the end of the current frame, allowing them to continue processing the current frame independently.