Game Development Reference
In-Depth Information
17
Optimizing a Task-Based
Game Engine
Yannis Minadakis
17.1 Introduction
Before 2005, the CPU-side of game code was single threaded. Optimizing for the
CPU meant improving algorithms and data layout and removing unnecessary code.
Sampling profilers and call graphs were the tools of choice to find bottlenecks.
Parallelism was reserved for the GPU. The graphics APIs restricted developers to
expressing their code in a form that could be parallelized by the hardware. The
developer focused on how much load was placed on either the CPU or GPU and
tried to load-balance to achieve the highest frame throughput.
With the arrival of the Xbox 360 and PlayStation3, developers were given up
to three CPU cores to work with. The PC platform was also quickly moving to
multiple CPU cores. Writing straightforward code that utilized the whole machine
was manageable. There were multiple systems in a game engine. The systems
were executed sequentially and could be run on separate threads as long as their
inputs and outputs were pipelined. I call this the thread-per-system paradigm. For
example, thread0 would submit frame(
N
), while thread1 animated frame(
N
+1)
and thread2 processed user input for frame(
+ 2). Frame latency increased, but
the game also ran faster and with richer content so the trade-off was reasonable.
Once the systems were broken out, the traditional CPU optimization opportunities
remained. Using mature profiling tools, the CPU's potential was there to be had
just as it was in the single-core days.
Fast-forward to 2010. Intel is shipping six core CPUs with twelve hardware
threads.
1
CPUs with eight hardware threads and on-chip integrated graphics are
now the mainstream CPU for both desktop and laptop. In a few years. these parts
N
1
A physical CPU core has at least one hardware thread. A hardware thread appears as a CPU
to the operating system and is also called a logical CPU. All hardware threads on one physical
core share the physical core's processing power.
231
