I’d like to follow up on an earlier blog posting in which I referenced a video on the Intel Software Network TV about some of the approaches that might help parallel game development.
In my previous posting I referenced Brad Werth’s comments on parallel programming problems in games, including how to make the best use of threads, the importance of identifying core topographies and the acute need for parallel programming in applications running on small factors.
Brad Werth is a senior software engineer in Intel’s Entertainment Technical Marketing Engineering group. His focus is on developing and optimising game features that take maximum advantage of the PC platform.
In case you didn’t get the chance to watch the video – and it is well worth tuning in to – Brad Werth also covered, in some detail, integrating middleware into gaming code.
It’s not uncommon for developers to create the game code and then use middleware to implement sub-systems such as artificial intelligence, physics, animations or even user-input.
However, fusing in-house code with technology that has essentially been bought presents some interesting design problems. Brad Werth says many games developers will start by parallelising a particle system and will then go back and look at how to get the sub-systems to cohabit.
But there are multiple issues with this. For example: you don’t want to create many more threads than you have logical cores, leading to oversubscription, the performance penalty that occurs when more threads are created than the hardware resources can handle.
Although it’s a problem for all parallel programs, oversubscription is particularly dangerous for games that compute each frame in a fixed time budget. If the game’s critical path takes longer than this time budget, then a frame could get dropped.
Brad refers to a paper and sample code that can help parallel programmers get the most from their middleware. It shows an architecture that is available for middleware developers to design middleware that will nicely slot into multithreaded games.
The aim is to ensure that the parallel work being done by the middleware can be processed on threads provided by the host so you are not creating a double set of threads.
Intel has a demonstration called Ticker Tape that uses this same design architecture. It can be dropped into existing parallelised hosts as a modular system. Ticker Tape has already been referenced in a previous blog posting and the demo shows how the technique can be used in games.
Essentially, Werth’s commentary can be summed by saying that games are composed of pieces, potentially with independent threading approaches, and those pieces should be designed to unify.
If you want to listen in and get straight to the point, the insight into middleware threading starts from about nine minutes in.
And if you’ve got any comments let’s hear them.