Orbiter on 48 cores

[dumbo2007]

I wonder if it would it be possible to run Orbiter on one of these some day :

http://hothardware.com/News/Holy-Me...ding-Out-Samples-of-Experimental-48Core-Chip/

Imagine 47 copies of orbiter_ng running in parallel simulating different star systems and "1 core to merge them all" ...running the opengl graphics client.

The accuracy with which star systems can be simulated both inside and outside would be amazing. I believe that the graphics clients being developed today should be made with this in mind i.e. be able to connect to multiple orbiter simulations and simulate the maths for the interstellar part by itself.

 

[RisingFury]

There's a pretty low chance of this actually getting released commercialy. I remember a few years ago, Intel announced a 120 GHz processor, with plans to build 20 GHz commercial ones.

 

[dumbo2007]

Yeah I know...but my point was that multiple cores like i7 and i5 already out there and these are only going to get more popular in the future. So an approach should be taken with the graphics clients, to harness these capabilities

 

[Artlav]

Right now, a 48 core node from AMD cost about $40000, most of that is for RAM.
And, there is no chance in hell of Windows running on that kind of thing.
So, what exactly can such an overkill platform do with current or 2010 Orbiter, neither of which actively use more than one core?

Star systems simulation is easy, it's analytically propagated.
One can simulate a motion of a galaxy sector, but the time scales are incompatible with space flight sim.
Graphics won't benefit much from it either, since one modern GPU have about as much computing power, and in better shape to suit graphics.

We're not there yet.

 

[dumbo2007]

Well yeah realistically 48 cores is too much for Orbiter.

But if we look at lower specs such as with quad cores - I was wondering if the graphics client can be coded to connect to a different orbiter_ng instance, at runtime when the user makes a selection for a different star system. The target system could be running on different core and simulating a different system and if the client allows a smooth switch then there is no need to shut down and restart orbiter.

Can you explain a bit about the analytically propagated thing ? Or point me to some info about it ?

 

[Artlav]

I was wondering if the graphics client can be coded to connect to a different orbiter_ng instance, at runtime when the user makes a selection for a different star system. The target system could be running on different core and simulating a different system and if the client allows a smooth switch then there is no need to shut down and restart orbiter.

Interesting, but you don't need many cores for that. Orbiter's physics core is quite a low-load application, many processes can be run simultaneously on a regular PC.
Besides, need to shut down and restart to change systems is a design point of Orbiter, not lack of computing power - i believe you heard about Spaceway?

Can you explain a bit about the analytically propagated thing ? Or point me to some info about it ?

Sure,
http://en.wikipedia.org/wiki/Kepler's_laws_of_planetary_motion
http://en.wikipedia.org/wiki/Secular_variations_of_the_planetary_orbits

Compare that's complexity to stars in a galaxy, for example:
http://en.wikipedia.org/wiki/N-body_problem

 

[dumbo2007]

Ah thanks!!

Yes I heard about Spaceway. Hope it supports Orbiter's API someday.....am following it closely

The n-body problem can be efficiently parallelized using particle systems - we did it in a high performance computing lab. Basically we distribute stars which are close by to the same PE to reduce communication and this is dynamic as they move about. 1 PE acts as the controller.
So cores should help in galaxy simulations.

 

[Hielor]

And, there is no chance in hell of Windows running on that kind of thing.

Er, what?

Windows 7 (and Windows Server 2008 R2) support up to 256 cores.

 

[Artlav]

Er, what?
Windows 7 (and Windows Server 2008 R2) support up to 256 cores.

Sure, but i never seen anyone actually running high-performance system on Windows, so one would likely have to own it to run Orbiter.
Have you?

 

[Hielor]

Sure, but i never seen anyone actually running high-performance system on Windows, so one would likely have to own it to run Orbiter.
Have you?

Computers running Windows Server often have a very high number of cores.

Not the sort of thing that someone would be running Orbiter on, though.

 

[dumbo2007]

Well it should become more mainstream as the parallel programming paradigms become more popular. Parallelizing parts of Orbiter right away can be useful for supporting more UMMU's for example - or more vessels in general. I think the current single threaded implementation supports at the max 10 or 20. When the Universal Autopilots is released it will be possible to have lots of vessels flying about. Then we will have low frame rates(at least I will with my dual core )...and starting them as separate threads creates problems during rendering I think - no access to rendering thread ?

I am ready to run Orbiter on Slackware with everything stripped off except the bare essentials just to get more vessels, but then Orbiter should use the other core efficiently.

Hey Artlav, you do Orulex computations is a separate thread right ? Did you have any problems rendering stuff from it ?

 

[Hielor]

Well it should become more mainstream as the parallel programming paradigms become more popular. Parallelizing parts of Orbiter right away can be useful for supporting more UMMU's for example - or more vessels in general. I think the current single threaded implementation supports at the max 10 or 20.

Um...what?

The vast majority of time spent each frame is *not* in vessel code. Assigning individual threads to every UMMU would be a total waste of resources.

I've also had upwards of 300 "vessels" in a single Orbiter session without much noticeable slowdown...

 

[Nerull]

I think the current single threaded implementation supports at the max 10 or 20.

Why? I just created one with 35 with no noticeable slowdown.

Far more of the computers time is spent rendering than doing physics calculations.

 

[dumbo2007]

Oh ok......I was testing by repeatedly spawning vessels through code and it seemed as though the fps began to suffer after about 20. So which processor did you get 300 on ? I am on a Dual Core T4200 with Intel GMA 4500M gfx and I guess rendering was the bottle neck. But I ll keep a proper count and try once more.

Ray Tracing can be significantly enhanced thus improving the quality of graphics if multiple cores are available and the same algorithms can be used for providing better collision detection:
http://www.pcper.com/article.php?aid=506&type=expert&pid=2

 

[Artlav]

Oh ok......I was testing by repeatedly spawning vessels through code and it seemed as though the fps began to suffer after about 20.

I once did a self-replicating vessel, Orbiter grinded to a halt at about 2000-4000 copies of the simple-meshed thing, so the physics core is quite efficient.

Ray Tracing can be significantly enhanced thus improving the quality of graphics if multiple cores are available and the same algorithms can be used for providing better collision detection:

Sure, ray tracing can be fun and work well on multiple threads. But, you need a lot of them to get into real-time band - even 8 cores gives 2 FPS on a rather simple scene. GPU's parallel cores are perfect for the job, but their resources are quite limited, ironically, stuffing a mesh into one can be a challenge.

you do Orulex computations is a separate thread right ? Did you have any problems rendering stuff from it ?
...
So does this allow you to access the main Orbiter thread( functions in the API I mean) ?

Orulex does it's computations in a separate thread, and the main thread keeps the mesh looking like what the other one computed. There could be quite a lot of computing threads.
The art of parallel programming is synchronization, ray tracing is an explicitly parallel task, meaning there are little sync involved, but mesh LOD'ing and generation is not that easy.

 

[dumbo2007]

ok and is the Orulex mesh a separate Vessel class or were you able to directly render into the DirectX screen.

That brings me to another question, if I wanted to implement something like Orbiter Shipyard, then is it possible to draw lines or arrows into the projection of Orbiter on screen by using the DirectX API ? Say I want to allow an user to rotate a mesh group around and so I want some rotation arrows at the center of rotation like you get in 3DS Max or Maya. Is it possible to do it while the game is running ? Or do I have to make my own interface using SDL+OpenGL+UI Library for such a thing.

Since Orbiter already provides the entire infrastructure, I thought I might as well use it. Though I am not sure how to get mouse input in 3D in Orbiter.