Game Engine Architecture

(Ben Green) #1
329

able processing resources. (On the Xbox 360, N should probably be 3 or 6,
because the console has three cores with two hardware threads each. On a
PS3, N might range anywhere from 1 to 6, depending on how many SPUs are
available.) We then “fork” (i.e., create) N threads, requesting each one to work
on a diff erent group of pose pairs. The main thread can either continue doing
some useful but work that is independent of the animation blending task, or it
can go to sleep , waiting on a semaphore that will tell it when all of the worker
threads have completed their tasks. Finally, we “join” the individual resultant
joint poses into a cohesive whole—in this case, by calculating the fi nal global
pose of each of our fi ve skeletons. (The global pose calculation needs access
to the local poses of all the joints in each skeleton, so it doesn’t parallelize
well within a single skeleton. However, we could imagine forking again to
calculate the global pose, this time with each thread working on one or more
whole skeletons.)
You can fi nd sample code illustrating how to fork and join worker
threads using Win32 system calls at htt p://msdn.microsoft .com/en-us/library/
ms682516(VS.85).aspx.


7.6.4. One Thread per Subsystem


Yet another approach to multitasking is to assign particular engine subsys-
tems to run in separate threads. A master thread controls and synchronizes
the operations of these secondary subsystem threads and also continues to
handle the lion’s share of the game’s high-level logic (the main game loop ).
On a hardware platform with multiple physical CPUs or hardware threads,
this design allows these threaded engine subsystems to execute in parallel.
This design is well suited to any engine subsystem that performs a relative-
ly isolated function repeatedly, such as a rendering engine, physics simula-
tion, animation pipeline, or audio engine. The architecture is depicted in
Figure 7.7.
Threaded architectures are usually supported by some kind of thread
library on the target hardware system. On a personal computer running
Windows, the Win32 thread API is usually used. On a UNIX-based system,
a library like pthreads might be the best choice. On the PLAYSTATION 3, a
library known as SPURS permits workloads to be run on the six synergistic
processing units (SPUs). SPURS provides two primary ways to run code on
the SPUs—the task model and the job model. The task model can be used to
segregate engine subsystems into coarse-grained independent units of execu-
tion that act very much like threads. We’ll discuss the SPURS job model in the
next section.


7.6. Multiprocessor Game Loops

Free download pdf