Game Development Reference
In-Depth Information
available cores. SetTime(
) will always be small relative to
Time(x). However, comparing the pipelined case becomes more complex. If the
latency is three frames, then the task scheduler will be able to fill all idle time with
tasks from the frames in flight. The running time of the task-based game is the
same as the thread-per-system game if the number of hardware threads is equal to
the number of systems. As the number of hardware threads increase, the task-based
game Time(Frame) continues to drop, while the thread-per-system Time(Frame)
remains constant. This property holds as long as the number of hardware threads
is less than the number of tasks in the tasksets. This is a good result, but we can
do better.
Let us assume that
x
)+WaitTimeToStart(
x
SetTime(A) + SetTime(B) + SetTime(C)
>
A)
+ WaitTimeToStart(B
WaitTimeToStart(B
,
,
C)
.
This is true if the tasksets have a significant amount of work to complete. If two
frames are always in flight on the CPU, then the drain-out time for frame
N
can
be filled with tasks from frame
N
+ 1 as follows, with a Latency = 2:
ExecTime(Frame) = SetTime(A) + SetTime(B) + SetTime(C)
.
Figure 17.9.
Three tasksets executing in the tasking system with one frame pipelined.
