In his Practical Multi-Threading for Game Performance lecture, Intel application engineer Leigh Davies stressed the growing importance of properly threading, highlighting specific considerations and strategies and case studies for games such as
Crysis.
To start, Davies highlighted a number of considerations for multithreading in games: Is framerate the most important performance indicator? Is input latency a dealbreaker?
Is it "fair," in a gameplay sense, for clients to run at different speeds? Is it more important to have high framerate or smooth framerate? How well will the threaded app scale on 'n' cores? Finally, he noted the considerations of concurrency (
Amdahl's Law) and bottlenecks.
He then noted a number of threading strategies, such as data forking, in which developers distribute CPU-intensive tasks over multiple threads, gather calculation results and then synchronize. Another strategy is the pipeline - thread game processes separately, such as rendering and game logic, and sync after each frame, which, notably, adds latency.
Next is the consumer approach - thread game processes separately but asynchronously, free up threads when the process is done, and set all game processes at same frame rate. Finally there's the work crew - thread game processes separately and asynchronously, but at varying frame rates, which in the end is difficult to schedule.
Most threaded games, said Davies, use a combination of these methods.
Graphics drivers can get on a dedicated thread, he said, but avoid calls returning GPU state information, something that's less of a constraint under DX10, limiting system memory vertex buffers, locking using D3Dlock_discard or D3Dlock_nooverwrite.
It's also important to group resources once per frame, said Davies, adding that driver queries are OK, as they're asynchronous.
Davies then gave some examples of how current games are threading, such as
Crysis, which is threading graphics drivers through a GPU, a proprietary physics system, a particle engine, and the game's audio.
Ghost Recon 2, he said, is threading its rendering through GPU, and its physics through an Ageia PhysX card.
For Massive Entertainment's
World In Conflict, the studio created an internal benchmarking application using game assets, said Davies, using it for marketing demos, comparing hardware performance across multiple configurations, and compatibility testing.
It's important in doing this, though, that the game system and the benchmarking application have roughly the same system load balance as the final game.
Finally, said Davies, developers need to understand how Windows dynamically assigns threads. Be careful, he warned, when manually setting thread affinity, as Windows may also assign a non-game process, such as a virus check, to that core and slow the game down.
