crazy idea: distributed processing

[ShuRugal]

So, i just had a wild thought... What if we could leverage the resources of other computers to help with the processor loading in DCS games?

 

And i have an idea by which it may be practical to do this. According to the published information, the simulated functions on the player aircraft are an order of magnitude (at least) more demanding than the simulation performed on AI-controlled aircraft and vehicles, but the AI aircraft and vehicles are still simulated to a certain level of fidelity to provide realistic-appearing flight instead of having everything run around on rails.

 

Therefore, each AI-controlled vehicle or projectile that must be simulated takes a chunk of processing that could be used for calculating player-aircraft data or graphics information.

 

The idea i have in mind would be essentially the same thing as network play, only reversed: instead of player clients connecting to a server which co-ordinates the information, AI clients connect to the player's session to offload the simulation of non-human controlled moving objects. The data is then sent through the network simply as position/orientation/velocity information. All of the hard calculating relating to AI movers (damage models, health/status, AI decisionmaking, projectile trajectories, etc etc) would be performed by the AI 'client' machine, freeing up the player 'host' machine for the demanding player-aircraft and graphics-rendering work.

 

This would differ from traditional network-game sessions because in a traditional networked game, all of the calculations are performed host-side, and even player movements are confirmed by the host machine before being sent back to the clients. The reason this is necessary is that live people may be inclined to cheat by modifying the parameters of their client to give themselves an advantage. With my idea for having the AI calculations done by "clients" this would not be a problem, as the AI clients have no one operating them to commit a cheat, and all relevant parameters would simply be checked at the start of each session to insure they match those of the player "host".

 

Now, i suppose this could be mulliganed to an extent by creating a dedicated network server and connecting to it, but this excludes running through campaign missions. I also don't know how network play is handled in the DCS series: for this method to be a successful reduction of player-computer resources, all calculations not directly pertaining to the player-aircraft would have to be performed server-side, including (preferably) wingman AI.

 

 

So, is this something that might be feasible to implement down the road? Is it possible that network-play already works similar enough to this to not need to come up with a specialized project to do it?

[Kuky]

There are multi-core CPU's so no need to have more than 1 PC for this. All developers need to work on is multi-threading so no need to send info over network to other PC's.

[ShuRugal]

There are multi-core CPU's so no need to have more than 1 PC for this.

ah, clearly then you have some way of arbitrarily adding processor cores to a computer as needed? would you please share it with me?

[GGTharos]

It isn't an idea that no one has thought of before ... the problem is that a mobo with two processors and multiple cores is cheaper than two PC's typically.

[ShuRugal]

unless one happens to already own a second computer. One that is not as powerful as the one on which DCS is being played, but which could nevertheless provide an offloading of less-demanding calculations.

[KLR Rico]

Multi-threading first... then *maybe* this would be the next direction...

 

I play on dual CPU rig, so I'm hoping for some love either way.

[Kuky]

ah, clearly then you have some way of arbitrarily adding processor cores to a computer as needed? would you please share it with me?

 

Isn't it obvious... heaps easier to get new CPU with more cores (there are 6-core CPU's already) and if you want get dual CPU motherboard...rather than needing a whole new PC

[ShuRugal]

Isn't it obvious... heaps easier to get new CPU with more cores (there are 6-core CPU's already) and if you want get dual CPU motherboard...rather than needing a whole new PC

 

sure, if you have a desktop.

[Dusan56]

I can see ShuRugal's point. Perhaps all of us have in possession some older PC (still good but not enough for running KA-50). If some part of job can be distributed to the "secondary PC" that could pretty much result to higher fps on "primary".

[EtherealN]

Ran a few quick tests, as follows:

 

I create a mission with a lone A-10C that I fly, and then a variant of the mission that also has 11 groups of 4 F-16's flying on the other side of the map. (To ensure we're actually testing FM impacts and don't get hit by graphics.)

 

I initiate a "dry run" first to ensure assets are loaded appropriately to hopefully remove HDD-access artefacts from the data.

 

I then run a 60 second benchmark, each once with a low graphics setting and once with a high graphics setting. Setting details below:

 

                   "Low"            "High"
                   -----------------------
Textures             Low              High
Scenes               Low              High
Civ Traffic          Off              Off
Water                Low              Low
Visib Range          Low              High
Heat Blur            Off              On
Shadows              Low              High
Resolution           1768x992         1768x992
MSAA                 4x               4x
Display Res          512              512
HDR                  Off              Normal
Clutter              500m             500m
Trees                1500m            9000m
Tree Shadow          Off              On
Vsync                Off              Off
Fullscreen           Off              Off
Cockpit Shadows      Off              On
TSSAA                Off              On

 

Empty mission, Low setting:

Min: 129

Max: 135

Avg: 132.583

 

Populated mission, Low setting:

Min: 116

Max: 124

Avg: 121.217

 

Here we can see that the planes had a noticeable effect. Well, noticeable in the numbers, but not in real life, but we have established that the AI plane FM/AI does steal performance. No surpruse. Looks like just below 10% on that configuration.

 

Now, however, let's look at settings I'd actually use:

 

Empty mission, High setting:

Min: 64

Max: 67

Avg: 65.233

 

Populated mission, High setting:

Min: 64

Max: 69

Avg: 66.483

 

Getting better performance with the AI planes in the mission, but that's obviously some fluke; the difference is minimal and definitely within the margins of error for things like how fast I am with hitting autopilot and then initiating the frame tracking which can affect how heavily the terrain affects graphics performance. The conclusion to draw though is that moving AI plane FM's etcetera away from the computer and onto another computer over network will have negligible to zero impact in most user cases.

 

System in question as signature, but without the CPU overclock. Aero is active.

FPS_test_empty.miz

FPS_test_11x4_f16.miz

[Kuky]

If you add to that mission some artilery and they start shoting salvos of projectiles and maybe add few more AI aircraft and that will start showing impact on high settings.

 

Bottom line is everything in sim takes CPU cycles... increasing graphics quality, up to a point, if you have good CPU and Video card (basically system as a whole) you can get away with some units without seing performance impact (as shown by EtherealN). unless you go crazy with amount on units and things happeing in mission (scripts, triggers, AI movements, etc) you can play on high settings and be fine. With multithreading if you only split CPU work onto 2 cores you almost effectively double the number of things the sim can calculate and stay at same performance level on high settings... so with 4 core CPU's as todays average standard, why do you need to complicate things even more by coding the game to run accross multiple PC's? The market for such uses (where people would use some old PC to do this) is so small I don't see how any developer would consider it worth coding like that?

[EtherealN]

Agreed. Further multithreading advances will give the same benefits but more of them, and for all users. ED is working in that direction, but it's not a simple thing to achieve so it will take time.

[Pikey]

I also thought multiple PC's was a useful idea at first but then realised that it would shift the design of the application away from the market advances in technology.

 

But how about a twist on the OP's suggestion, for those with 2 or less graphics outputs (fairly standard) what about rendering some cockpit features off to a networked computer with a light game client? How much would our cockpit builder enthusiasts love that? Or even the normal person with that second computer lying around...(like *cough* me, when the missus takes the little on out I could get another three screens!)

 

Perhaps this has been discussed and i'm barking up the wrong tree (Quick reply turned long) but what are the development thoughts to considering a lightweight cockpit rendering client that accepts remote IP packets from a master and renders a customisable cockpit display?

 

The end gain i'm trying to envisage is that you could launch clients on separate PC's like your work laptop or your spare PC which could then render a customised piece of screen for example a piece of the cockpit, the MFD's as is previously done in dual screen right now or even a viewport. One PC could add perhaps 1 or two more screens. Multiple PC's and the sky is your limit.

 

The main processing would still be done on the master PC, however one of the standard limitations to the average gamer would be circumvented, that is of the amount of screens and power of the graphics card. It effectively allows the game to be scaled ridiculously. It also allows lesser specced computers to assist because the secondary specs of these clients should really be less than of the master server.

 

Now that would be some simulation!

[EtherealN]

Pikey, no need for a light game client. There are already freeware mods and applications for this, as well as both freeware and payware applications for the iPad which allows the iPad to act as instrument display (with both output and input, including MFCD's).

 

On the ones that are meant for computer use (that is, not the iPad version(s)), you then have the option of running the relevant display on either a second screen on your computer, or on a networked computer. Drawback of these is that it requires use of export functions, and for online play some servers disable export through Client Integrity Check as a means of combating cheats.

[Nobody96]

Putting some distributed computing into the game wouldn't do much good for the graphics section. But maybe you could use it to distribute the server load, meaning that some client handles this AI squadron and another that bunch of ships and the server is only left with the task of negotiating who is dead and who is not. It is not that hard as it sounds. I already implemented an peer to peer load balancing algorithm during my time at Fraunhofer. Implementing it into DCS is a whole other story and would mean that a lot of code needs to be rewritten and even worse, a lot has to be redesigned. Therefore I don't think it will happen because the benefits are pretty slim. Lets just hope that DCS is currently refactoring its codebase to merge the BS2, A-10, P-51 and FC3 products. After that, they will have time to refine the codebase, ad multicore support, a dedicated server and other new and cool stuff.

 

so long

Mathias

[EtherealN]

Not only are the benefits slim, there's also issues with making sure the environment is secure from cheaters, as well as ensuring smooth handovers of tasks when clients drop out or in - as well as making sure players are not negatively affected by one person having a dodgy connection and thereby causes a bunch of AI units to weird out.

 

Also, multicore support isn't really something you "add". (At least not in this case.) The sane way (economically) is to "add" engine components as separate threads when said component is replaced in it's entirety - like was done with the sound engine when it was replaced.

[Big Bad Mama]

Another idea of distributed processing is for the hardcore pit builders. Something like:

Computer 1 renders the front view,

computer 2 renders the left view,

computer 3 renders the right, and so on.

 

Of course this is only interesting for those of us how are willing to spent a lot of money for a few big tv monitors or projectors.

But with this feature you could build something like this:

http://http://www.youtube.com/watch?v=Vem9L0PbA8c

[Nobody96]

Not only are the benefits slim, there's also issues with making sure the environment is secure from cheaters, as well as ensuring smooth handovers of tasks when clients drop out or in - as well as making sure players are not negatively affected by one person having a dodgy connection and thereby causes a bunch of AI units to weird out.

 

You left out the really interesting ones, like network partitioning, syncing, timing and so on. There are some very interesting papers out there discussing all mentioned problems. Feel free to PM me if you are interested.

 

Also, multicore support isn't really something you "add". (At least not in this case.) The sane way (economically) is to "add" engine components as separate threads when said component is replaced in it's entirety - like was done with the sound engine when it was replaced.

 

Now you are trolling, but I will try again ;-)

Multithreading capabilities will hopefully be extended with the new terrain engine. Thats more precise than "added", even if, in respect to your sound engine example, "add" is also a correct terminus in my humble opinion.

 

so long

Mathias

[EtherealN]

I'd definitely be interested in those papers, though I'm not sure when I'll have time to read them in full. (I'm sadly quite busy nowadays and the forum is basically my venue for micropauses to make sure I don't go postal. :P )

 

As for "add" etcetera, it's basically the fact that we're not seeing something "added", but rather something is being replaced and the replacement part has a new feature associated with it. But yeah, it probably is pointless semantics. :)

[213]

this definitely isn't the right venue to discuss these kinds of things unless you want to get laughed off the stage.

 

people seem to think ed is some advanced computer technology research group.

[Pikey]

I found the 3rd party client for the instrumentation rendering but haven't specifically mentioned it since you didnt either Ethereal ;)

 

I'm interested in that and also taking on camera views...not sure there is a fundamental issue with extending from instrumentation to cameras wihtin the application design?

[sobek]

not sure there is a fundamental issue with extending from instrumentation to cameras

 

Well, there is a frikkin lot of more data to transmit for the rendering.

[cmeliak]

Windows solitaire will become x64 and multicore support sooner than this simulator .... i lost all my hope after all this years of waiting....

[sobek]

Windows solitaire will become x64 and multicore support sooner than this simulator

 

Step off the downers for a moment, son. ;)

 

DCS is still the only 'game' i know that actually has a working 64bit executable.

[EtherealN]

Well, to be fair: Crysis. :P

 

(But very few people notice since Steam and other channels auto-select the 32-bit version even if you have a 64-bit OS.)

 

If you were to modify that to "being 64-bit native" I might be with you though. :)

 

EDIT: And to be even more picky, there's no such thing really as "x64". There is x86 and then there's 64-bit extension of x86 - that is, x86-64. But that's my nerdy nitpicking for today. :P

Edited April 10, 2012 by EtherealN