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

According to Monkkonen [ 12 ], this model scales well because it can allocate as
many processing cores as they are available. Performance is limited by the amount
of data processing that can run in parallel. An important issue is how to syn-
chronize communication of objects running in different threads. The author states
that the biggest drawback of this model is the need to having components designed
with data parallelism in mind.
GPGPU stands for General Purpose GPU Computing. The focus on GPGPU
Computing has been increasing since graphics hardware had become program-
mable. It is a massively parallel architecture with more powerful processing than
the CPUs. GPU Computing has been theme of research on diverse areas like:
image analysis [ 16 ], linear algebra [ 17 ], chemistry [ 18 ], physics simulation [ 19 ],
and crowd simulation [ 20 ]. There are some works that discuss using GPU with
game loops [ 2 - 6 ]. These works concentrate using the GPU mostly for the physics
calculations, and they extend one of the game loops presented previously, i.e.,
multithread uncoupled model by adding a GPU stage. Figure 2.8 illustrates the
Single Coupled Model with a GPGPU stage, Fig. 2.9 presents Multithread Model
with a GPGPU uncoupled for the main loop, and Fig. 2.10 depicts the Multithread
Uncoupled with GPGPU.
Joselli et al. [ 6 ] present an architecture for loops that is able to implement any
simulation or game loop model and distribute tasks between the CPU and the
GPU. We also describe a framework for loops that are able to detect the available
hardware in many computers and automatically distribute tasks among the various
CPU cores and also to the GPU, as Fig. 2.11 illustrates.
2.3 A Dynamic Distributed Framework Architecture
The described architecture provides a management layer that is able to analyze
dynamically the hardware performance and adjust the amount of tasks to be
processed by the resources, computers, CPUs, and GPUs. In order to make a
correct task distribution, it is necessary to run an algorithm for the estimation. The
architecture applies a scripting approach because the loop can be used in many
different kinds of simulations, and for each of them it uses a different algorithm
and a subset of its parameters.
The core of the proposed architecture corresponds to the Task Manager and the
Hardware Check class. The Task Manager schedules tasks in threads and changes
which processor handles them whenever it is necessary. The Hardware Check
detects the available hardware configuration capabilities.
Additionally, with this architecture one can implement any loop model previ-
ously presented in this work. Also the heuristics presented in [ 4 ] can be adapted for
this framework. An earlier version of this architecture was first presented in [ 6 ]
and it is based on the concept of tasks. A task corresponds to some work that the
application should execute, for instance: reading player input, rendering, and
updating application objects.