Game Development Reference
In-Depth Information
will be the majority of the PC install base. With eight threads, there simply are not
enough systems to move into threads. Either we leave a lot of CPU performance
onthetable,orwemovetoatask-basedarchitecture.
This chapter will demonstrate how to move from a thread-per-system approach
to a fully scalable task-based system. We will see how to decompose different game
engine systems into tasks. We will learn how to eciently schedule work across the
machine and how to use new performance tools to visualize tasks as they run on
the CPU. Using a simple example animating a skinned model we will implement
a task-based animation and rendering system and we will use the Intel Graphics
Performance Analyzer (GPA) to review our work.
17.2 From Threads to Tasks
Programming threads directly made a lot of sense when an entire system was sep-
arable. The inputs and outputs were straightforward and could be synchronized to
the main thread via a semaphore. Adding queues allowed for pipelining of multiple
frames to increase throughput. The scheduling of all this work was simple, and
each game created a custom implementation.
Figure17.1
showsapipelined,threadedarchitectureontheCPU.Thedarkgrey
state boxes represent a frame moving from user input through scene submission to
the GPU. Time moves from left to right. The main thread created one worker
thread for each system, in this case the animation and physics systems. The main
thread processed user input for frame
+ 1 and would push work into the input
queue of the animation and physics systems. The work is pipelined so that the
main thread can submit rendering calls from frame
N
N
while the worker threads
Figure 17.1.
Example thread-per-system game engine.
