330 7. The Game Loop and Real-Time Simulation
7.6.5. Jobs
One problem with the multithreaded approach is that each thread represents
a relatively coarse-grained chunk of work (e.g., all animation tasks are in one
thread, all collision and physics tasks in another). This can place restrictions
on how the various processors in the system can be utilized. If one of the
subsystem threads has not completed its work, the progress of other threads,
including that of the main game loop, may be blocked.
Another way to take advantage of parallel hardware architecture is to
divide up the work that is done by the game engine into multiple small, rela-
tively independent jobs. A job is best thought of as a pairing between a chunk
of data and a bit of code that operates on that data. When a job is ready to be
run, it is placed on a queue, to be picked up and worked on by the next avail-
able processing unit. This approach is supported on the PLAYSTATION 3 via
the SPURS job model. The main game loop runs on the PPU, and the six SPUs
are used as job processors. Each job’s code and data are sent to an SPU’s local
store via a DMA transfer. The SPU processes the job, and then it DMAs its
results back to main RAM.Figure 7.7. One thread per major engine subsystem.