Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
January 18, 2020
arrowPress Releases

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

Nordic: Intel's Davies On Multi-Threading Strategies

Nordic: Intel's Davies On Multi-Threading Strategies

May 17, 2007 | By Staff, Katherine Schoback

May 17, 2007 | By Staff, Katherine Schoback
    Post A Comment
More: Console/PC

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.

Related Jobs

Disbelief — Chicago, Illinois, United States

Junior Programmer, Chicago
Disbelief — Cambridge, Massachusetts, United States

Senior Programmer, Cambridge, MA
Disbelief — Cambridge, Massachusetts, United States

Junior Programmer, Cambridge, MA
Everi Games
Everi Games — Austin, Texas, United States

Game Developer

Loading Comments

loader image