Advanced Question Threading question for martins

[agentgonzo]

I just read this thread: http://www.orbiter-forum.com/showthread.php?t=9908

With many current CPUs having more than one core, is it time to start thinking about multithreading in the orbiter core? At present, everything is done on one core and the graphics suffer if the MFDs do a lot of processing (I'm thinking of high MFD update rates and specifically AerobrakeMFD, IMFD and LTMFD but I'm sure there will be more) and the second/third/fourth cores just sit idle.

It shouldn't be too much effort to stick the MFD update calls on a different thread and make them draw to an off-screen buffer. That way, you can free-up the main thread and get better FPS by using the other cores.

Just a thought.

 

[martins]

Unfortunately it's not so easy. When I designed the new map MFD, I spent quite some time trying to allow it to update itself in a separate thread, because of the heavy load this MFD mode puts on the CPU. This failed, and eventually I figured out that the Windows GDI library is not threadsafe.

It may be possible to move all GDI drawing out onto a single thread, but this would require a significant amount of recoding, and I am not sure it's worth it. Better to try and get rid of GDI altogether and incorporate the MFD drawing into the render engine. As far as I know, Jarmo already has a Sketchpad implementation that provides at least a partial Sketchpad implementation using the renderer.

 

[agentgonzo]

OK, worth a thought. Thanks. I may take a look at aerobrakeMFD to see if it can easily be made multithreaded then. Conceptually it shoudn't be too hard.

 

[n72.75]

Multithreading might be good for vessel dynamics. In the same way that X-Plane 10 does it: assign a thread to each vessel.

 

[RisingFury]

Multithreading might be good for vessel dynamics. In the same way that X-Plane 10 does it: assign a thread to each vessel.

What happens with multiple vessels, then? I'm talking more than 10 active vessels run by autopilots...

 

[agentgonzo]

What happens with multiple vessels, then? I'm talking more than 10 active vessels run by autopilots...

Each vessel's dynamics runs in its own thread.

I don't see much benefit to vessels dynamics as the model in orbiter is relatively simple (compared with X-Plane) and you won't get much benefit at all with concurrency.

 

[dumbo2007]

What about a bunch of vessels in the same thread, so like if there are 10 vessels and the frame rate is high, then there is no need for extra threads. But suppose a new vessel is introduced (created by scenario editor) and the fps drops, then update it in a separate thread. Or have 5 vessels in 1 thread and 5 in another

 

[martins]

What about a bunch of vessels in the same thread, so like if there are 10 vessels and the frame rate is high, then there is no need for extra threads. But suppose a new vessel is introduced (created by scenario editor) and the fps drops, then update it in a separate thread. Or have 5 vessels in 1 thread and 5 in another

Dealing with vessels of different complexity would best be handled with a worker thread paradigm: You create a given number n of threads up front (e.g. equal to the number of cores), then hand the first n vessels out to be processed by those worker threads. Whenever a worker finishes its vessel update and returns, it gets the next vessel waiting in line. This is a fairly straightforward approach to load balancing.

The vessel code at the moment isn't quite in a state where this can be implemented, because there are cases where vessel states reference each other (e.g. for docking assemblies), so they can't be updated independently. Once I finish with the overhaul of the state vector update code, a multi-threaded approach may be easier to implement. However, it won't have much of an effect for scenarios that don't contain at least a few hundred vessels.

 

[dumbo2007]

Nice :thumbup:

However, it won't have much of an effect for scenarios that don't contain at least a few hundred vessels.

[daydream]
100 vessels flying around Brighton Beach on auto pilot and landing based on commands from the control tower , all the while avoiding bumping into each other
[/daydreams]

kind of stress-testing the auto pilots

Have you considered using OpenMP for paralleling some for-loops though ? It uses directives so very non-intrusive to other code. Of course if the loops do not have much dependencies between iterations then it works best, else there isn't much speedup.

 

[RisingFury]

However, it won't have much of an effect for scenarios that don't contain at least a few hundred vessels.

OBSP sure could use that... 20 combat units on each side + fired weapons quickly adds up to 100...

 

[dumbo2007]

The thing is since bases can't be programmed and vessels alone can have code, so in the future most complex functionality(like projectiles or the surface vehicles which I am beginning to model with the Bump plugin), will be based around the VESSEL class. So makes sense to allow their numbers to scale with the user's cores.

Actually I am looking forward to a 100 animated UMMUs

 

[jarmonik]

It may be possible to move all GDI drawing out onto a single thread, but this would require a significant amount of recoding, and I am not sure it's worth it. Better to try and get rid of GDI altogether and incorporate the MFD drawing into the render engine. As far as I know, Jarmo already has a Sketchpad implementation that provides at least a partial Sketchpad implementation using the renderer.

Rendering the MFD screens with a DirectX renderer doesn't help much with the multithreading since there is only one GPU and it can render only in one target at a time. Also the graphics part of most MFDs is pretty simple, getting the math running in an other thread would be more important at least with the LTMFD. It might be possible already but I don't know is the CelBody API a thread safe.

I suppose the D3D9Client could help with the map MFD problem by recording the polylines in a client specific format into a static vertex buffer but that would require some new features to be added into the sketchpad.

I have measured the execution times of the following MFDs:

OrbitMFD 180us
SurfaceMFD 600us
LTMFD 1'000us
MapMFD 12'600us

Since, the frame time for 60fps is 16'667us so it's obvious that map MFD will cause skipped frames.

 

[yagni01]

Alternately create shared memory where true External clients could host MFDs out-of-process (ala FSUIPC)? Sounds more complicated, but don't know if it is. . .

I like to run a minimum of 4 ExtMFDs on a second monitor, which kills the framerate. Seems like throwing the 'display mostly' MFDs 'off the bus' would let the core focus on the important bits.

 

[Cras]

Alternately create shared memory where true External clients could host MFDs out-of-process (ala FSUIPC)? Sounds more complicated, but don't know if it is. . .

I like to run a minimum of 4 ExtMFDs on a second monitor, which kills the framerate. Seems like throwing the 'display mostly' MFDs 'off the bus' would let the core focus on the important bits.

Now there is a good idea. FSUIPC like interface, can even throw MFDs onto a client PC, like a laptop, and have an array of information displayed on one machine, and leave the flying on the main Orbiter machine.

 

[yagni01]

Now there is a good idea. FSUIPC like interface, can even throw MFDs onto a client PC, like a laptop, and have an array of information displayed on one machine, and leave the flying on the main Orbiter machine.

Yea, opens up new possibilities, but don't know that it's a "cost effective" solution compared to "get[ting] rid of GDI" as martins mentioned as the MFDs primarily have to be renderable in the main view.

 

[Bibi Uncle]

What happens with multiple vessels, then? I'm talking more than 10 active vessels run by autopilots...

Multithreading means "dividing a process into multiple threads". You can do it on a single core unit. It is actively used, specialy by Windows. You can see it in the Task Manager. Usually, you have more threads than processes. Dividing a process into different threads create sychronous tasks (even if they are not really synchronous). A good example is input receiving. To avoid freezing, we create a multithreaded executables. When a big task is running, the input is still available. If there was no multithreading, the program would freeze during the big task.

However, the main purpose of multithreading is the parralel execution on multiprocessor machines. In those cases, Windows divides the threads in multiple cores. Windows XP can do it only if the applications asks for it. Vista and 7 divides the threads automaticaly, separating the applications on multiple cores.