A Distributed Architecture for Simulation Environments Based on Game Engine Systems - Visual Computing: Scientific Visualization and Imaging Systems - page 54

Fig. 2.13 The automatic update task class and messages

One of the main features of the proposed architecture is scheduling a task to run
on another processor (CPU core to GPU or GPU to CPU core or CPU core to other
CPU core) during its execution. In these cases, the task state is pushed to the task's
own stack (and later restored) regardless of the processor type. For example, in
time t1 the GPU processes a physics task and in time t 2 this task is scheduled to the
CPU. When the task starts to run again (now in the CPU), the Task Manager
reloads the task state from the tasks stack and signals it that the processor type has
changed. The task priority is changed to a value of zero, which means that the task
is placed on the front of the task queue. This measure is a way to guarantee that the
task will keep on running. Also the Automatic Update Task can perform load
balancing according to the usage rate of processors.

2.3.2 Configuration Script

The configuration script is used in order to configure how the automatic update
task will execute the heuristic.
This script defines four variables:

• INITFRAMES: used in order to set how many frames are used by the heuristic
to do the initial tests. These initial tests are used so the user may want the
heuristic to make the initial tests differently from the normal test;
• DISCARDFRAME: used in order to discard the first DISCARDFRAME frame
results, because the main thread can be loading images or models and this can
affect the tests;
• LOOPFRAMES: it is used to setup how frequently the heuristic will be exe-
cuted. If this value is set to -1 the heuristic will be executed only once;
• USEHARDWARE: a variable to determinate which modes will be used for the
automatic update tasks;