(Split) A DCS performance discussion

[jctrnacty]

It would be great to have a graphics engine GPU limited and avionics and AI multicore CPU limited, this could save a lot of headaches to those who suffer with performance.

 

Simply , if you have fastest CPU and GPU, you can be sure it will work smoothly.

[shagrat]

Note: Both PS3 and XBOX360 are multicore systems ;)

Yep, usually utilizing two cores: one for world, one for AI

 

The problem are the compilers and game engines which need to be downwards compatible...I guess. :huh:

[ALDEGA]

Even really old CPU's support multi-threading ... ;)

 

I'm quite confident that we will see it in DCS at some point. Until then, I'm using the Windows 7 "core parking" feature to save some power :D

[EtherealN]

jctrnacty - this isn't quite as easy as it sounds though, since the graphics engine needs to be told what to draw, and this information needs to come from the simulation engine. So if the simulation engine starts to bog down because you just gave it 300 bullets to do ballistics calculations on at the same time as that vulcan is sending 300 of them back at you... Updates to the graphics engine will come less often, and the graphics engine slows down. Add to this a couple flights more and a raging tank battle and things will eventually slow down. Simple as that.

 

This is the point in that low FPS does not necessarily mean the graphics is the problem.

[shagrat]

This is not correct. Even Excel 2007 (which RTM'ed 5 years ago) uses multiple cores (as many as physically available) for certain calculations.

Correct, as I said calculations aka mathematic formulas... problem here it is not optimized for real time calculations with lots of different changing variables.

CAD programs and Video renderers make good use of multicores, but by design not in realtime. What you need for games.

 

At the moment you mostly assign a cpu / core to a specific task (e.g. AI, World frame etc.) which can be run separated.

 

If you have to split for example the AI task it is difficult to coordinate this on multiple cores, you need the results at a certain point in time...

[wess24m]

I agree about the cores, bf3 was a PC game ported to consoles though, the ps3 was a beast hardware wise when it came out but it only has something like 256 megs of ram 256 megs of Vram, Tried running linux on it back in the day and it was a dog.

 

Just read up on some topic's in the game performance forum gonna try them out tonight, judging by the system specs of people that are running all on high with added "eye candy" mods I shouldn't have any issues with my system. When every other software you throw at your system runs perfectly maxed out and then DCS has issues doesn't sound like a pc problem. thx for changing the thread BTW learning alot on this forum, dodging the flames.

[metalnwood]

This is not correct. Even Excel 2007 (which RTM'ed 5 years ago) uses multiple cores (as many as physically available) for certain calculations.

 

Spreadsheets are reasonably easy to multitask though. There can be many different tasks that are easy to split in to different jobs.

 

It's not so easy for other programs where a lot of processing is sequential and result 2 needs to follow at the conclusion of result 1. I think a number of games have already taken the low hanging fruit by putting the sound in to a different thread as these kinds of computations can happen in parallel fairly easily.

 

It would be a large effort to take something like dcs or any other similar project and make everything work on all cores. It's not just a matter of saying run this on a different thread. There has to be a lot of planning and coordination at the design stage to make sure it all works and you are processing in parallel all the thing that you are able to.

[ALDEGA]

if the simulation engine starts to bog down because you just gave it 300 bullets to do ballistics calculations on at the same time as that vulcan is sending 300 of them back at you... Updates to the graphics engine will come less often, and the graphics engine slows down. Add to this a couple flights more and a raging tank battle and things will eventually slow down. Simple as that.

 

This is the point in that low FPS does not necessarily mean the graphics is the problem.

If things are spread across multiple threads (cores) then the rendering code would not be waiting as long to start drawing as it does now. This would increase FPS.

 

Imagine a truck that needs to move 20 boxes of cargo from point A to point B.

Case X: one person loads the 20 boxes into the truck which takes a time of "20"

Case Y: four people load the 20 boxes into the truck, it now takes a time of "5"

 

The freight trip time is the same in both cases, but loading of the cargo was quicker, therefore the whole process is faster.

[ALDEGA]

It would be a large effort to take something like dcs or any other similar project and make everything work on all cores. It's not just a matter of saying run this on a different thread. There has to be a lot of planning and coordination at the design stage to make sure it all works and you are processing in parallel all the thing that you are able to.

I never stated that it's easy, especially with an existing project with a large code base. However, do you suggest ED ignore many-core and hope that single-core performance improves dramatically in the future? This is not likely to happen.

[EtherealN]

Far too simplistic, Aldega. See metalnwood's post.

 

The point is that until the simluation engine is done, the graphics engine has nothing to do, because it doesn't know where the things it's supposed to draw even are. What you can do, and what I'm pretty sure the wizards are looking at, is to split graphics to one thread and simulation to another, thus ensuring they don't have to share the resource. This will go some distance, but you'll eventually hit another road block once the core doing either thread gets saturated by it's workload. And doing this isn't exactly a copy-paste job either - both components needs to be pre-planned for this in how they are designed. Taking code made to run in one thread and chopping it up is an extremely dirty affair with tonnes of pitfalls.

 

My personal guess - and it is a guess - is that they'll do this when those engine components get swapped for new code, like was done with the sound engine in FC2.

[shagrat]

If things are spread across multiple threads (cores) then the rendering code would not be waiting as long to start drawing as it does now. This would increase FPS.

 

Imagine a truck that needs to move 20 boxes of cargo from point A to point B.

Case X: one person loads the 20 boxes into the truck which takes a time of "20"

Case Y: four people load the 20 boxes into the truck, it now takes a time of "5"

 

The freight trip time is the same in both cases, but loading of the cargo was quicker, therefore the whole process is faster.

Right, but how do you coordinate the four people, that they know what box to load on another one? E.g. heavy boxes first. This is the problem here. People do coordinate themselves utilizing grey matter aka brains. Computers are dumb, only do what you tell them...:smartass:

[metalnwood]

Imagine a truck that needs to move 20 boxes of cargo from point A to point B.

Case X: one person loads the 20 boxes into the truck which takes a time of "20"

Case Y: four people load the 20 boxes into the truck, it now takes a time of "5"

 

 

This is why back in the late 80's I liked programming in a language called prolog. It was easy to program with statements and predicates. Unfortunately it's a lot harder to do the same thing in the languages used in most simulators.

 

I know what you are saying, and it's valid but it's not always that simple and usually these tasks would be managed at a macro level rather than a micro level - until we are running 256 core processors maybe.

[ALDEGA]

Right, but how do you coordinate the four people, that they know what box to load on another one? E.g. heavy boxes first. This is the problem here. People do coordinate themselves utilizing grey matter aka brains. Computers are dumb, only do what you tell them...:smartass:

I gave a simplified example, as you know. There's no point in discussing programming patterns in detail here. Multi-threaded programming has many challenges but it is a required element for high performance applications in a many-core environment. As of yet it seems that CPU development is going in the direction of many-core, rather than more powerful individual cores. Parallellism is inevitable, albeit complex.

[ALDEGA]

... to split graphics to one thread and simulation to another ...

Actually, my simplified example discusses splitting up of a single task, for example AI, not splitting rendering and AI, that's another thing.

[metalnwood]

Actually, my simplified example discusses splitting up of a single task, for example AI, not splitting rendering and AI, that's another thing.

 

Yes, ideally you would do that but this is where we still need to manage things at a macro rather than a micro level. I.e., with only 4 cores common it would not make sense to have every piece of ai run in it's own thread, let alone every bullet.

 

There is a point where your (not you specifically) theoretically designed software - or as a lot of people would call it infinitely scalable software will just not work very well. Sure, when we have processors with hundreds of cores it may come in to it's own but until then you usually have to keep things a bit different.

 

Opportunities where you could thread things would be for a cbu going off and all ai in the blast radius have their damage modelled off another thread. That is more practical than each unit running individually.

 

You have to remember there are only 4 or so cores so you can't break stuff up too much or you just have more threads waiting for processing time.

 

Infact when you do that too much you loose performance, not gain it.

[Moa]

The hard part about multi-threaded programming is sharing the state. This means dealing with resources and memory. Who gets to write to what and in what order? Who gets to clean up? Making sure you avoid deadlocks (actually easy if you know how). Doing this in C++ (as LockOn/DCS is at the lower levels) is quite hard.

 

This is one of the reasons why languages like Java (and the descendant, C#) were invented and have largely supplanted C++ for new development work. They have direct language support for synchronization and have garbage-collected environments, which allows for multi-threaded resource use without killing yourself trying to get it right.

 

Aldega you are right. ED have made their single-thread core very efficient but they'll be struggling now since singe-core performance is not increasing as it used to (since the emphasis is now on many cores).

 

The time required to make DCS run in multiple threads would not be very long - what takes forever is getting it to run properly without deadlocking or leaking resources. Doing that requires proper design and planning. I wouldn't be surprised if ED are working on this behind the scenes, but it'll take a fair while to come to fruition before it is both multi-threaded and works correctly.

 

metalnwood: these days the per-thread context switching is so low (thanks to CPU hardware support) that programs can comfortably have hundreds if not thousands of threads and let the thread scheduler figure out what should run on what core when. The trick is to make sure that each thread does enough work that the overhead of the context switch becomes negligible compared to the benefit of the extra core. In the old days you are totally right, lots of threads were bad, but these days its ok if you don't have too many synchronization issues (which this problem doesn't have, each unit is nearly independent).

 

159th_Viper: actually you don't have to freeze rendering waiting for the CPU. Things like the skybox, clouds and sea can all be rendered before the foreground objects, and it is only the latter that is really dependent on the results of the current frame calculation (eg. you don't have to change the sky gradient every single frame, so can re-render with a guesstimate view transform).

Edited November 16, 2011 by Moa

[shagrat]

I gave a simplified example, as you know. There's no point in discussing programming patterns in detail here. Multi-threaded programming has many challenges but it is a required element for high performance applications in a many-core environment. As of yet it seems that CPU development is going in the direction of many-core, rather than more powerful individual cores. Parallellism is inevitable, albeit complex.

 

Sorry, didn't mean to be rude. I guess we both agree this is inevitable for future computing. The necessary performance can only be reached with sharing the workload, but even brand new game engines are not yet perfectly utilizing multicore environment.

The task for ED is to move a VERY complex and sophisticated game engine to a multicore environment, without provoking hundreds of bugs.

 

Unfortunately I think licensing the cry-engine or frostbite 2.0 from bf3 won't work with a flight model we need in DCS they are optimized for shooters and shiny effects :D

[ALDEGA]

Shagrat, I'm sorry if my post conveyed such a feeling.

 

I've been enjoying ED's products since Flanker 2 and hope to enjoy many more to come. I wasn't complaining about the AS IS situation, but talking about development in the future. I'm surprised to see so many "defensive" replies. Nobody is being criticized.

[Wichid]

Could the flight model calculations be offloaded to something else like the GPU or a physX chip hypothetically?

 

I realise not everyone has a powerful GPU or a PhysX chip but I was wondering if this was plausible.

[213]

graphics wise, the main performance killer is the vehicles themselves. you can test this hypothesis by creating a level with you and a few vehicles parked around you, then remove them and compare the performance difference. my fps dropped 20 points with tanks and apcs parked around me. -40 or so fps with f15es and a10s around me. normal operation with just buildings and environment my fps is around 80 without vsync. but i play with vsync on so i don't feel the impact as much.

 

at 200k poly per dcs standard vehicle, a scene with five 200k vehicles parked together so that lod0 is on, generates a million polygons.

 

it's an all too common an occurrence as well in this game when flying formation. however, to their credit, they have a robust lod switching system so it's not really 1mil all the time, but more like 400 to 600k polygons or so when flying formation, and a constant 800k in airbases with vehicles crammed together, but not counting the environment and buildings.

 

most games like battlefield/cod, and something closer to dcs spectrum, like arma 2, will use vehicles at around 10k-50k(arma 2 aircraft carrier) polygons at lod0, but they use normal maps to offset the quality difference, which if using the high poly baking method, can yield even better results than a plain 200k model. that is easily possible at dcs level for something like a 50k vehicle using normal maps baked from a 1mil poly sculpt.

 

i'd say dcs is running double to triple the amount of polygons than the average game. the performance achieved is commendable actually, but i think it's a shame that they couldn't optimize the models more and free up resources for other calculations. and i've noticed that my video card is way louder and hotter when running this game. so the excess electricity usage from all the extra work load could have been avoided as well.

[104th_Crunch]

Ouch, damn that is fugly! Party like it's 1999! lol

 

FSX - Zero Combat etc etc.

 

BMS.......

 

 

Well, that speaks for itself.

[B25Mitch]

I think the issue is that DCS uses too many resources for things which no-one cares about. Let's take a look at a simple scene, one which may be happening in several places at once in a typical battle:

 

 

Notice all the spent shell cases falling down? Let's take a closer look:

 

 

Each of those shells has 48 vertices, and even receives dynamic shadows!

 

 

The number of shells is enormous - and consider that each of these has not only ballistics calculations, but also dynamic shadows and 48 vertices!

 

 

And finally, we can see that every one of those spent shells is running collision detection with the ground. Even after falling hundreds of metres, the engine is still keeping track of them. After hitting the ground, the shells sit there for a minute or more before being removed.

 

Would anyone care if DCS used a simple sprite-based system(like in IL-2), without dynamic shading, collision detection or numerous polygons? I certainly wouldn't.

 

[nomdeplume]

Each of those shells has 48 vertices, and even receives dynamic shadows!

 

The number of shells is enormous - and consider that each of these has not only ballistics calculations, but also dynamic shadows and 48 vertices!

 

Vertices and shadows etc. only matter if they're being rendered, and they're only being rendered if you're actually looking at them. LOD also probably comes into play to make them much cheaper to render unless you're up close. So the graphics hit only comes into play if you're actually admiring their prettiness.

 

And finally, we can see that every one of those spent shells is running collision detection with the ground. Even after falling hundreds of metres, the engine is still keeping track of them. After hitting the ground, the shells sit there for a minute or more before being removed.

It's not really a major task to track an object until it hits the ground. I'd be surprised if these things even detected collisions with other shells, let alone other game world objects. If they were actually doing collision detection against every other game object then you'd probably see a performance hit, but IMO this is a pretty negligible bit of processing for the 99% case -- shots being fired while you're not looking in that direction or are too far away to see details. There's no AI and only be most basic "physics" calculations being applied.

 

Anyway, it's only a few hundred shells, and as noted before, most of the graphical models in DCS are very detailed: the engine is designed to render a lot of polygons. In most cases that you're close enough to see the shells in any kind of detail, you're going to have very few other objects in view (e.g. the example screenshots you posted), so you may as well give the engine something to render. :)

 

Would anyone care if DCS used a simple sprite-based system(like in IL-2), without dynamic shading, collision detection or numerous polygons? I certainly wouldn't.

People making cool videos would mind that the shells looked crap. People not making cool videos won't incur the 'cost' of rendering the shells up close, so what does it matter?

[B25Mitch]

I'm mainly concerned that the quality of the effect is disproportionate to its importance. In the second-last screenshot above, we see two types of objects:

 

1.) Shells (~5000 polygons)

2.) Terrain (~2 polygons)

 

On the CPU side of things:

 

If this is indeed a "negligible bit of processing", why do we not see many physics effects of this quality elsewhere in DCS?

 

What if, for example, this sort of mass-physics simulation was employed in weapon impacts and aircraft crashes?

 

If the game engine(and a computer of the recommended requirements) can handle calculating ballistics/collisions for both falling shells AND realistic explosions, then great.

 

But if I had to choose one, it would certainly be the latter - and I suspect the people making the 'cool videos' agree.

[ALDEGA]

I'm not sure but I believe the "self-shadows" are only applied to the "actively" viewed object. Even then, only within a certain distance. I don't think this is a performance hog. Modern videocards should be able to handle large numbers of vertices as well. One of the things that I found which affects performance noticeably are dynamic lights (flood lights, formation lights, position lights and taxi&landing lights). You can disable lights on your aircraft but not the AI, so when they start taking-off or come in landing ... ;) The AI sometimes turn on formation lights in the middle of the day ...