Gamasutra: The Art & Business of Making Gamesspacer
Multithreaded Game Engine Architectures
arrowPress Releases
October 31, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Multithreaded Game Engine Architectures

September 6, 2006 Article Start Page 1 of 4 Next
 

Even though multicore processors have been available for the PC for well over a year, and the Xbox 360 has already sold millions, there is still a lack of knowledge regarding the development of game engines for multicore platforms. This article will attempt to provide a view to game engine parallelism on an architecture level.

As shown by Gabb and Lake[1], instead of looking at multithreading on the level of individual components, we can find better performance by looking for ways to add parallelism to the whole game loop. We will be looking at three different threading supported architecture models for the basic game loop, and comparing them with regards to qualities such as scalability, and expected performance.

There are two main ways to break down a program to concurrent parts: function parallelism, which divides the program to concurrent tasks, and data parallelism, which tries to find some set of data for which to perform the same tasks in parallel. Of the three compared models, two will be function parallel, and one data parallel.

Synchronous function parallel model

One way to include parallelism to a game loop is to find parallel tasks from an existing loop. To reduce the need for communication between parallel tasks, the tasks should preferably be truly independent of each other. An example of this could be doing a physics task while calculating an animation. Figure 1 shows a game loop parallelized using this technique.


Figure 1. A game loop parallelized using the synchronous function parallel model. The animation and the physics tasks can be executed in parallel.

Costa[2] presents a way to automate the scaling of this kind of an architecture. The idea is to divide the functionality to small tasks, build a graph of which tasks precede which task (such as the graph in Figure 1), then supply this task-dependency graph to a framework. The framework in turn will schedule the proper tasks to be run, minding the amount of available processor cores. The alternative to using such a framework is to rewrite parts of your code for each core amount you plan to support.


Article Start Page 1 of 4 Next

Related Jobs

Activision Publishing
Activision Publishing — Santa Monica, California, United States
[10.31.14]

Tools Programmer-Central Team
Amazon
Amazon — Seattle, Washington, United States
[10.30.14]

Sr. Software Development Engineer - Game Publishing
Intel
Intel — Folsom, California, United States
[10.30.14]

Senior Graphics Software Engineer
Pocket Gems
Pocket Gems — San Francisco, California, United States
[10.30.14]

Software Engineer - Mobile, Backend & Tools






Comments


eierkoek eierkoek
profile image
A lot of research had been done about a multithreaded render loop (separate render and update thread) on this website:
http://blog.slapware.eu/game-engine/programming/multithreaded-ren
derloop-part1/
and
http://blog.slapware.eu/game-engine/programming/multithreaded-ren
derloop-part2/

Especially in part 2 the side-effects of the multithreaded implementation are discussed. Naive multithreading leads to stuttering because of limited synchronization. The website shows how to use partial synchronization and motion extrapolation to counter this effect.


none
 
Comment: