[SOLVED] MultiThread

[dave.lannan]

In the documentation under the topic "Execution Sequence" for the Unigine SDK there are these lines:

 

Multi-Threaded Main Loop

 

In the multi-threaded mode, where two or more CPUs exist, the execution pipeline is implemented differently at some points. They are as follows.

 

In the update stage, the world script uses all available threads to update visible nodes, instead of updating them one by one. By that, Unigine analyzes node dependences, so these operations are fully thread-safe. The number of threads to be used is controlled via world_threaded.

In the rendering stage, multi-threaded physics and pathfinding are run in their separate threads before anything else. They will perform their tasks on all available threads in parallel to rendering. The number of threads to used in controlled via physics_threaded and pathfind_threaded respectively.

The swap stage in this scenario includes waiting for all additional threads to finish their tasks. After that, physics and pathfinding threads are synchronized and calculations are applied to the world.

 

Now. How do you enable "MultiThreaded" mode. We have tried many combinations and we could not get the use of more than a single CPU. Could there please be an explanation of exactly how this is done and how it works.

 

Cheers,

Dave

 

<edit repasted so the words were more readable>

[manguste]

Simply via the console commands: world_threaded 1, physics_threaded 1 or 2 and pathfind_threaded 1.

[dave.lannan]

Im sorry we have previously tested these commands (and a number of others). And we cannot get more than a single core/cpu to ever be used.

"In the multi-threaded mode, where two or more CPUs exist, the execution pipeline is implemented differently at some points."

There seems to be no use of multiple processing units at all. This is fine, if this is the case, but the documents seem to allude to multi-cpu or multi-core support?

Any help of getting full (or even partial use) of our multi-core/ multi-cpu systems would be welcomed.

 

<edit>

I am wondering - our test scene we just loaded up a rediculous amount of particle emitters (26 emitters @ 1000 with lifetime 20.0) to load up one of the cores. This does happen, but using the above commands there seems to be no effect.

 

Cheers,

Dave

[manguste]

Reproduced the demo you've described and multi-threading is in effect. Try to enable the profiler and you'll see the Update time becomes smaller once you set world_threaded to 1 (check the green line), because the work to update emitters is paralleled between the cores. (BTW, you can use samples/stress/particles_* demos for stress-testing). Threaded physics can be tested on physics/cloth_08 or cloth_01.

[ulf.schroeter]

As far as I understand the code in World::update_multiple() all nodes of a node hierarchy requiring update will be assigned to the same update-thread in a top-down manner (root node first, followed recursively by all its child nodes).

 

If this is true than - for example - logical grouping all particle systems under a single dummy node would cause their update to be handled just by a single thread. On the other hand defining all particle systems as standalone root nodes should cause a more or less even distribution on multiple threads.

 

Might be worse to test these two different setups for profiling.

[manguste]

Yes, particle systems that have one root are updated together (the same goes for WorldTransformBone, etc.). It allows for safe data exchange between a parent and a child. For example, a child never gets outdated data on its parent, while the parent has already been updated in another thread.

[ulf.schroeter]

Yes, this makes perfectly sense and also completely avoids otherwise required node thread synchronization locks etc. While beeing efficent it has to be kept in mind when defining world node hierachy structure.

 

Therefore I think it would be very useful to add some notes on this fact to world management/multi-threading documentation so world node hierachy structure can be optimized for multi-threaded update during level design.

 

Also some best-practice hints/example structures for efficent update workload distribution to multiple threads would be very helpful because without these it will be difficult for users to figure out proper structuring.

[manguste]

Actually, it seems there's nothing else to mind for multi-threading. Just keep 'heavy' nodes (like particle systems) and nodes with physical bodies that require intensive calculations (cloths, ropes) under different parents or as root nodes. NodeReferences are always handled as a root regardless of their place in node hierarchy, which means multi-threading without any headaches for sure.

 

I've added these comments on Multi-threaded Update of Nodes into World Management article.

[ulf.schroeter]

Yep, very good, these guidelines are simple enough.