Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
Performance Scaling With Cores: Introducing The SMOKE Framework
View All     RSS
May 17, 2021
arrowPress Releases
May 17, 2021
Games Press
View All     RSS







If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

Performance Scaling With Cores: Introducing The SMOKE Framework


November 26, 2008 Article Start Previous Page 2 of 3 Next
 

Figure 3: SystemAI and SystemGraphic are subscribing to position changes from SystemPhysics.

Figure 3. SystemAI and SystemGraphic are subscribing to position changes from SystemPhysics.

The registration of objects between systems occurs during initialization of the framework using the interfaces developed in Smoke. When a system modifies its data it tells the CCM, and that information is passed on during the next frame refresh (see Figure 3). The CCM does not pass the data through to each subscribed system, but instead leaves it to the system itself to copy the data only if necessary for its present operation.

Figure 4: Interfaces make communication between systems easy.

 

Figure 4. Interfaces make communication between systems easy.

To maintain Smoke’s highly modular design, interfaces were developed between the various systems and the framework itself—a key feature. The framework’s job is to enable communication between the various systems (see Figure 4). For example, we might have a geometry interface for changing the positions of models or a behavior interface for changing AI states of specific objects. The Scheduler uses the task interface to schedule and invoke work with each system.

Running through a typical frame process in Smoke helps clarify this activity. Imagine a single frame in the engine being rendered, where the process starts with the framework’s systems subdividing the tasks for processing. The Scheduler invokes each system per frame allowing the system to naturally divide its own work into granular pieces that can be broken up into various jobs. Competent middleware is able to accomplish this quite easily, which minimizes the Scheduler’s necessary work.

Figure 5: Worker threads are assigned jobs from the pool of available processing work.

Figure 5. Worker threads are assigned jobs from the pool of available processing work.

Once all of these tasks have been created, they are collected into a single pool that all available worker threads can access. A properly designed framework allows for one worker thread per core, and this is where the power and scalability of the design really starts to play out.

Each job in the pool is then assigned to a thread (see Figure 5) based on the load of each particular thread and the framework’s estimation on how processor-intense each job is.

The one area that the Smoke developers admit is problematic is in this step: Properly balancing the load of jobs across each thread requires some kind of pre-determined knowledge about the work in each job. Obviously in a very lightweight framework, such as the one we are describing, that information is difficult to come by.

Cache coherency on the processor is another important issue to keep in mind when subdividing tasks. In the most optimal setup threads should work on blocks of data rather than random or interleaved data, allowing the processing core to access cache and memory resources in a more linear, and thus quicker, fashion.

Figure 7: Each of the worker threads has a change queue that is accessed by the CCM.

Figure 6. Each of the worker threads has a change queue that is accessed by the CCM.

During the processing of the current frame, the various worker threads and jobs post messages to the CCM (see Figure 6) indicating updates to the status of any registered objects.

Once the frame has been completed, the CCM sends those messages on to the appropriate systems that have subscribed to the updated objects before the next frame’s processing begins, allowing the updated data to propagate through the framework. And thus, the cycle repeats, and we have a fully threaded, independent-processing model for a game engine.


Article Start Previous Page 2 of 3 Next

Related Jobs

iD Tech
iD Tech — N/A, California, United States
[05.17.21]

Online STEAM Instructor/Mentor
HakJak Studios
HakJak Studios — Boise, Idaho, United States
[05.17.21]

Unity Generalist / Senior Developer
Sucker Punch Productions
Sucker Punch Productions — Bellevue, Washington, United States
[05.14.21]

Senior Tools and Engine Programmers
Sucker Punch Productions
Sucker Punch Productions — Bellevue, Washington, United States
[05.14.21]

Senior Graphics Programmer





Loading Comments

loader image