Better multi-core CPU Optimization for 2.5 maybe ?

[Worrazen]

I was recently thinking that indeed the newer GPU APIs may not be everything or a substantial amount in the overall equation, since DX11 was recently added I think it's too early to expect anything more in this area for some time.

 

 

So I'm open for waiting even longer into 2017 for the 2.0 merge, or rather 2.5 by then, if that would mean that some good performance, because that would make experiencing all the content that much better.

 

For a better CPU I would have to replace pretty much most of the PC. Won't need GPU since I get a new GPU next month. New Motherboard, 32GB of DDR4 RAM (16 not enouhg for me) an the new CPU would go over 700 Euros, and the PC is just not old enough nor I need the CPU horsepower so badly for anything else. The only update possible on this mobo is Ivy Bridge, but that's a practically inefficient as my Sandy Bridge just isn't far behind.

 

I got the new monitor and I'm on 1440p now, I just ran it last night for just a quick look nothing in deep, i'll see how the FPS behaves while still on the old GPU, and I'll see how much the new GPU improves things.

 

I'm not a real programmer but I follow tech, so this is all just my thinking from outside, I don't want to sound like I'm lecturing the developers but I think that I made a reassessment and to not whine about newer APIs and rather point out something that did not receve a recent update, I'm from my own experience aware that it's harder than it sounds here in changelogs, when you just read short statements, but I do want everyone to know that I acknowledge the hard work behind each of those lines of text there.

 

I'm fine if CPU optimization being a surprise only revealed just for 2.5 open beta.

 

Now I want to repeat, it's just a wish, but I don't know if making a new GPU API is harder or making the game multi-threaded on modern CPUs, I hope it's easier heh, so I hope I'm not asking for something even harder :(

 

I'm also looking into FPS drops caused by HDD texture re-loading, however that is on-hold unless someone else confirms otherwise or I do it when I get a new GPU with more than enough VRAM to eliminate the possible factor that's preventing this test to be valid.

 

I hope it's not one of those things where application engine CPU support won't go in the way of a GPU API, I'm not sure how that crosses or does not, but if it does it may kinda be impractical for them to do it separately, if it's more practical, time and cost efficient to just make it multi-threaded and a new GPU API implemented simultaneously then this won't come anytime soon.

 

Now if it were possible to just separate things more without having to modify the GPU API, the sound is already separated, and if it were possible to separate physics and the API-Calls,

 

So I imagine this kinda scenario:

 

• Core 0: Main (GUI, misc, exe)
  
• Core 1: Physics
  
• Core 2: API (DX11 DrawCalls)
  
• Core 3: Audio
  

Edited November 18, 2016 by Worrazen

[SkateZilla]

This has been discussed multiple times....

 

Search Function:

multithreading

multi-threading

[Worrazen]

I tried searching "CPU" and "optimization" found posts dating back to 2011 and 2013 only.

 

I guess i didn't thought of those.

[BitMaster]

Sooner or later this has to be addressed or Intel and AMD have to come up with a 5+ GHz CPU.

 

DX11 alone can't fix it and the tendency among games is MULTICORE, for a very simple reason.

 

Most games nowadays are focused on consoles, PS3/4 Xbox etc.., and those rely on multi-core medium-coreclock based chips. So, the majority of gaming will adopt to multicore, so will the hardware vendors tailor their devices accordingly. This, has been discussed on many forums as well.

 

When DCS makes the move ? Nobody knows.

 

DX11 will have to suffice, exploiting 2 cores for draw calls, 1 core for audio and 1 core for EVERYTHING else. Heck, it aint hard to see the problem rising with more and more functions, ground warfare, modules, more detailed maps, better MP with more sustained player numbers, it all points to "MORE LOAD" on the cpu.

 

Even DX12 wouldnt solve every concern we have for DCS core, it would only further improve D3D but wouldnt help to calculate the world itself other than maybe freeing some more cycles off that 1 core doing it all.

 

Wether it's been discussed before or not, the problem persists and many newcomers come to the same conclusion/question, why not use more cores ?

 

The answer from ED as carried over was iirc that it has been discussed among the devs and they see no benefit in going SMP or using more cores in general.

 

Well, it is up to imagination of the dev what code he will write, or not write, but saying it wont work right away was no satisfactory answer to me at least, as the problem still persists and despite saying NO to the SMP approach, no other solution to the 1-core-does-it-all has been brought up, and we all think it's only going south with time as things get added and expanded.

 

Just putting it down wont silence the newcomers having the same findings and asking the same questions as for example I did when I joined the DCS community.

 

We all agree, going multi-core in DCS would mean a major rewrite of the code resulting in a Upgrade price or such to pay for the work done.

[Worrazen]

I didn't know that there is a "not worth it" consensus ... interesting.

 

What if that was the assessment from some years ago when newer APIs weren't taken into account ?

 

What if a combination of a newer API and multi-threading on the engine side for CPU does the trick ?

 

For example Doom 2016 gets 40% more FPS just from DX11 to Vulkan, and being a recent game it's probably properly multi-core on the engine side. Ofcourse it's a different type of game, I'm not saying the % is transferrable.

[Worrazen]

We all agree, going multi-core in DCS would mean a major rewrite of the code resulting in a Upgrade price or such to pay for the work done.

 

Hmmm, yes I don't like to spend 700 Euro for ... 20 more FPS while I just bought a 600 euro monitor and a 250 euro GPU coming up ... , but I can donate 50 right now if they set up a CPU optimization fund, why don't you say so, take my money right now!

 

I'd do it on day 1 just so I can help break the ice and motivate others to join in.

 

I was already planning to buy A-10C so I can delay that for a bit, but it's not like funds would just redirect and be labeled differently, I will still get A-10C anyways.

 

This community isn't like ordinary teenager gamer dudes that come and go and jump from trends, I mean I'm not even that interested in other games, I don't even know why I'm using the word game right now I don't see it as some worthless entertainment, I don't compare DCS with other games .. now if something like this is set up, I'm sure the existing community would participate and, but ... so some folks may have aged a lot and aren't as active, still it would also bring out all those who are on hiatus or who are currently taking a break busy with other things and maybe they notice it and they may not even be active here and would still donate or something and then check back in 6 months.

 

I'm not even considering my self active, I come and go all the time, I have a 2 week run, then I'm gone for 2 months, it's just lifestyle, not really anything to do with the game why this pattern happens.

[Worrazen]

Well, something happened today, with the NTTR expansion pack, just wow :clap_2:

 

A major wish I had for a year ... fulfilled!

 

So speaking of funds, I put the money where my mouth is on that one showpost.php?p=2956742&postcount=9

 

But I'll probably have to dig to find those posts where ED said that CPU opt may not be that effective for the cost, cause I need to see details to wrap my head around it, not that I don't believe, I'm a technical person, I need to understand.

 

Now, they could have assessed that at the time correctly, but what about now when there's new GPU APIs, vulkan 1.0 is only out half a year, okay DX12 quite a bit longer, so if this is added to the test mix along with engine-CPU specific multi-threading, all that combined may shift the balance in favor of being a major performance boost, but I get it, the developers have to even learn the new APIs etc, so on the cost side I'd definitely, the newer APIs are meant to be harder on developers and less work for GPU driver, that's how lower lever hardware access is possible.

 

With "developers" i mean developers out there on the market, something tells me that high-profile engineers probably aren't employed there all the time right?

 

EDIT: I guess I was wrong there for a bit ...

Eagle Dynamic's staff is made up of 55 full-time employees, most of who have graduated in applied math and physics. Among them are five doctors of science. The staff includes experienced engineers, managers and artists who have worked in the military, software development and aerospace industries.

Edited November 19, 2016 by Worrazen

[shagrat]

Ah, again... :popcorn:

[Worrazen]

Well I apologize I didn't know it's been discussed that much.

 

But on another note, now I'm looking at my graphics settings, and again can't make a conclusion since I'm still a month away from a proper GPU, but I have to run things on quite low actually except textures and resolution to the max, and I get relatively stable 55 FPS.

 

I don't like to make conclusions because things keep changing all the time as I figure things out, in general, not just in this topic.

 

I will get back here when I get the GPU and log down the changes, while keeping the settings the same.

 

I'll also do some tests, but I know for a fact that FPS nosedives if I lower CPU frequency by 30 or 50% when I put to AFK power saving.

 

I forgot to put back to 100% once and had thought something must have broken in the game, it kinda loses half the FPS, now I'm not making any claims whether it has to do with draw calls or the simulation calculations.

 

I wasn't a DCS player before 1.5, so I don't have an idea how much DX11 improved things, barely a week of practical play time on 1.2 technically, 3 months in total but all that inactive time doesn't count, half that time I was just setting up the controls.

Edited November 20, 2016 by Worrazen

[shagrat]

CPU is definitely a factor for performance.

The "brilliant" concept of multicore/multithreading requires a code architecture AND tasks that support multicore/multithreading.

So, if (and that's a big if) the environment could be split into separate tasks that can run asynchronous, it would require a complete additional development team to start on "DCS 3.x" with "EDGE 2" with a complete new engine and code architecture.

Compared to the development and integration of "just" a new graphics engine (EDGE) that may take a considerable amount of time (a decade or two?).

 

By then, the typical software architecture (running stuff on individual PCs, the concept of Multicore etc.) is most likely obsolete already and most of us are likely having problems with their eyesight.

 

But the most critical question to a multicore support is, what tasks can be run asynchronous?

 

AI - would do inputs to aircraft based on actions/triggers from players aircraft/actions. So if the trigger press is asynchronous, it may fire a couple milliseconds too late, but in general a likely candidate.

 

AI damage model calculations - a definite yes, as it won't matter if a hit takes even seconds to show effects. Say motor failing a couple seconds after being hit, so calculation can happen asynchronous and results can be stored in memory and collected when convenient, seconds later.

 

Though it sounds easy, this means ripping all these code and its dependencies out of the current code. Fixing all issues arising while doing that and finally reintegrating the separated code into DCS again.

If we look at the current complexity and time required to just adopt a single old map and integrate it into the new graphics rendering engine and code architecture, I suspect a much more complex and time consuming endeavor like "make it multicore" is not exactly something this community would admire.

 

And that is just some AI stuff, anything else, from bullet trajectory, objects, systems modelling to environment like wind/airflow etc. needs to be synchronized and thus won't be a likely candidate for threading, anyway.

 

E.g. bullet trajectory needs to check collision with objects and ground mesh/environment to register hits.

LOS calculations require all object and ground collision data to be available etc.

[shagrat]

I wasn't a DCS player before 1.5, so I don't have an idea how much DX11 improved things, barely a week of practical play time, 3 months in total but all that inactive time doesn't cound, half that time I was just setting up the controls.

 

Actually, DX11 solved a lot, for me going from 15 to 30+ fps to 70 to 90+ fps on the old GPU! I still run my i7 2600k@4.2GHz and did before the new engine was introduced.

With the installation of the GTX 970 with GSync I could power a 4K monitor and get 40 to 60 (limited by GSync) with pretty high settings on 1.5.x

On 1920x1080 resolution it is constant 60fps (GSync limits to 60fps) a realistic guess is around 60-90fps at all times.

 

So 8 or better 16GB RAM an i5 or i7 CPU with 3.8GHz or better and a decent GPU should give you a good performance on high settings, with FullHD resolution.

 

Oculus Rift VR or 4K is a different story, current hardware can just so much as handle VR.

[BitMaster]

Shagrat, I have npw played from 2.66GHz to 5 GHz i7's and I tell you, DCS 2.x is GPU limited.

 

I can easily flood my 980GTX with an old 920 i7 on rather demanding settings on 1440p, I actually thought with this old CPU dont even try non-overclocked...you know what...WRONG...the GPU was filled the same way as with my golden Sandy close to or at 5 GHz.

 

1.5.x is didfferent, but not worth talking aboput anymore as it will be obsolete soon.

[Worrazen]

CPU is definitely a factor for performance.

The "brilliant" concept of multicore/multithreading requires a code architecture AND tasks that support multicore/multithreading.

So, if (and that's a big if) the environment could be split into separate tasks that can run asynchronous, it would require a complete additional development team to start on "DCS 3.x" with "EDGE 2" with a complete new engine and code architecture.

Compared to the development and integration of "just" a new graphics engine (EDGE) that may take a considerable amount of time (a decade or two?).

 

By then, the typical software architecture (running stuff on individual PCs, the concept of Multicore etc.) is most likely obsolete already and most of us are likely having problems with their eyesight.

 

But the most critical question to a multicore support is, what tasks can be run asynchronous?

 

AI - would do inputs to aircraft based on actions/triggers from players aircraft/actions. So if the trigger press is asynchronous, it may fire a couple milliseconds too late, but in general a likely candidate.

 

AI damage model calculations - a definite yes, as it won't matter if a hit takes even seconds to show effects. Say motor failing a couple seconds after being hit, so calculation can happen asynchronous and results can be stored in memory and collected when convenient, seconds later.

 

Though it sounds easy, this means ripping all these code and its dependencies out of the current code. Fixing all issues arising while doing that and finally reintegrating the separated code into DCS again.

If we look at the current complexity and time required to just adopt a single old map and integrate it into the new graphics rendering engine and code architecture, I suspect a much more complex and time consuming endeavor like "make it multicore" is not exactly something this community would admire.

 

And that is just some AI stuff, anything else, from bullet trajectory, objects, systems modelling to environment like wind/airflow etc. needs to be synchronized and thus won't be a likely candidate for threading, anyway.

 

E.g. bullet trajectory needs to check collision with objects and ground mesh/environment to register hits.

LOS calculations require all object and ground collision data to be available etc.

 

 

That is kind of an eye opener, I didn't knew there are big hurdles like these, and the fact that mutli-threading makes it all asyncrounous.

 

I didn't knew syncronisation is that important here in simulators, so the big problem is you can't sync these parts while they're multi-threaded ... so that's a limitation of the CPU hardware and won't be good on any kind of engine or only the limitation of the current engine?

 

 

I'm wondering on the side, with hyper-threading tech, if the OS sees 8 cores for example, but half of them are physical, is the game at least able to use the physical one as primary? Or is that all automatic under the hood?

But I don't know if it's really like that, they say with hyperthreading all the cores OS sees turn into logical cores and would perform equally, if that is really a thing or just a label I don't know. Maybe games do some kind of quick test to check if "core 0" is a real core, if we assume the first 4 numbers are physical.

 

TLDR; So the engine would have to be tottally redone just so those parts that need to be syncronized are working correctly when multi-threaded ?

--

 

I don't want to sound pushy but then what are the possibilities of implementing DX12 later on top of this existing engine, if from what I understand, DX11 change didn't need such a big rewrite on the core engine and CPU side? I agree it may not increase FPS in a normal situation, but it could make it more stable when there's more activity on screen and ofcourse smoke/fog/clouds/rain. This could enable longer trails of colored smoke, you'd be able to write stuff in the air hah. This could even open a campaign mission where you would have to search for the missing aircraft and when you would get to the last known position using various clues, the last one would be visual by following the smoke trail for some time.

 

Also there's one other thing that I think is making these opinions about what is GPU or CPU limited, I forgot to state that I do not recognize GPU API DrawCalls as a genuine CPU expense, that is a GPU expense while taxing the CPU. This DrawCall bottleneck factor has to be practically eliminated before an average end-user would more properly get an idea how much a game is CPU or GPU limited, without advanced tools and testing.

But I hope I can run some developer-grade Win diagnostic tools to see DCS behavior as it is now.

 

 

--

I have the lowest performing Sandy Bridge i7, a 3820, and I don't overclock usually because I want it reliable, I can't afford to suddenly lose a CPU and replace it.

Edited November 20, 2016 by Worrazen

[BitMaster]

Apps dont distinguish between HT-Cores and real cores, they are both used the same way.

 

 

All modern Games focus on console, regardless of what ED does, and those are multi-core.

 

The gaming world goes Multicore, no doubt, it already is going that way whenever they get the chance to rewrite code or have the stamina to make it happen inbetween releases.

 

ED is I guess too small with a too small number of paying customers to make this happen quick, be realistic, but I am also realistic in the sense of that hardware will follow the trend of multi-core multi-gpu, multi anything as silicon wont clock higher without expensive cooling, period.

 

If a development team follows those signs on the horizon or not, I dont know.

 

I am instead, very confident we wont see a standard 5GHz clock CPU off the shelf or any CPU breaking the 3k IPC out of the box. And 3k is ---ONE CORE--- why waste the other ones ???.

 

From my point of view, this gets a more and more momentum loaded topic.

The old way of saying no is inadequate now, to say no you have to present an alternative and not just say NO.

[NeilWillis]

Actually, ED don't have to justify any of their decisions to you or anyone else.

 

You are ignoring some very fundamental issues here - like resources available to implement all the work involved. It is all very well comparing ED to the massive resource rich software houses that churn out a new game platform on almost an annual basis. But given the extreme niche world in which ED operate, the resources are very definitely finite.

 

You also ignore the possibility that silicon as a medium for processor architecture may well be at the end of it's useful life, and next gen processors may be radically different rendering multi core utterly redundant.

 

So, yes multi core support would be one possible route forwards, but at what cost, and would it be superseded by something radical in the next few years anyway?

 

Bottom line - ED will make the decisions they have to make based on what resources are available, and they are definitely not answerable to the likes of us! The debate has been raised before, and the answer was an emphatic no. The answer now is still an emphatic no. the answer in the future will depend on any number of factors, which include future sales, future technology, and future demands. Right now, with the right rig, you can obtain good frame rates. You just have to invest in the right gear.

[BitMaster]

Neil,

 

I stressed already that you cannot compare ED with WoT dev team, they own a multi-level skyriser with dozens or hundreds of devs, same will somehow apply to DICE or such big names, we all agree on that.

 

My approach is that in the long run, MAYBE, if the opportunity arises, to make the shift.

 

Also maybe, if technic advances this might solve itself. Like MS got around fixing it's ancient FileSystem with the large presence of SSD's. MS loves SSD's, be sure :) just for not having to fix fragmentation anymore.

 

The right gear you say one needs, I agree, read my sig, my cooling system costs around 1k€ meanwhile, all together. Some buy a whole gaming PC for that. I just dont assume as I sell and service PC's as well, that all who show interest in DCS will shell out that much money to have the right gear whereas their gear might be plenty for most other games that make better use of the given hardware. It would just be that much easier if the load was distributed better on smaller CPU's so that those people could also enjoy DCS and not flood the forum with " I miss many fps..etc " topics.

 

Not everyone has fun pushing his system to the last MHz as I do and enjoy. I can spend 1 weekend only booting and resetting and fiddling with it, but most are not that kind and want solid reproducable performance out of the box. I say this as someone from the other side of tzhe counter, listening to those guys for years. Some dont even know drag&drop properly but are good gamers, that's how it looks in the broader spectrum. Most of my gaming pals are too much knoob to install an OS, install drivers, install a game properly, some few are up to the task, the majority of them walks in the dark when operating their PC's, very few exceptions.

 

Not all are PC geeks, most just wanna fire up the rig and ENJOY, with zero understanding what is up underneath the hood.

 

For those guys, not for us.

 

Bit

[Worrazen]

I agree that the whole power-saving idea is hurting some of the hardcore sectors out there, all these new CPUs and GPUs they are so neurotic about power efficiency.

 

With the new GPUs from AMD slide I saw a while back, you could see how the area of the chip die area is getting smaller as the nanometer process is getting smaller, this is so weird, why are they so neurotic about smaller size (less heat, less power) in a PC configuration, it kinda makes the whole industry protract and stagnate, why can't they take the die size those 40nm chips had and apply a 14nm process to it.

 

Just look at some of the old HD series they had 323 mm2 and now polaris RX has 232 mm2 - this really isn't helping moore's law at all, this is all for this green gimmick that marketing departments push for just so they appeal to consumers.

 

EDIT: In terms of GHz yes, the single core performance isn't increasing as much.

Edited November 20, 2016 by Worrazen

[NeilWillis]

Yes, agreed BitMaster. It's not an ideal situation. I'm not someone who can tweak stuff that easily either, and there are definite limits.

 

Trouble is, it'd be a huge undertaking to implement a new system, and even then, the gains may not be that big that the outlay would justify the benefits.

 

One thing we can all count on is that ED will try whatever they can to increase performance. Right now though, I can't see their approach changing in regard to multi-threading. Once we have 2.5 as a stable unified installation, who knows where they will be directing their efforts.

[BitMaster]

The smaller the die, the HARDER to cool that thing !

 

The newest 6th and 7th gen already own that problem, coupled with lousy quality in the TIM

cooling a 6th or 7th gen CPU is a challange. Delidding only helps that far as the smaller die still

consumes about same as before. Many articles stress that point of the alsmost too small die to cool adequate.

 

My own 6700k is in the mail, I will see how good it will oc and if i have to delid it, which I woukd certainly do if my TIM is of such bad quality that the cores differ in °C too much.

 

Not that I want to delid it, but Intel almost leaves you no other chance if you want to fix their inferior TIM appliance.

 

The trend is good for mobile devices, I am typing on one, no doubt. For overclockers it is not that welcome.

[BitMaster]

Yes, agreed BitMaster. It's not an ideal situation. I'm not someone who can tweak stuff that easily either, and there are definite limits.

 

Trouble is, it'd be a huge undertaking to implement a new system, and even then, the gains may not be that big that the outlay would justify the benefits.

 

One thing we can all count on is that ED will try whatever they can to increase performance. Right now though, I can't see their approach changing in regard to multi-threading. Once we have 2.5 as a stable unified installation, who knows where they will be directing their efforts.

 

Neil,

 

the ded. server module will be an eye opener. Let me phrase it this way.

 

Stripped off the GUI, down to the core needed, we will see if a "respectable" machine can power

a 64-player session without stuttering and such..and how much headroom there is.

 

The ded. server will be the meter, by nature.

[Worrazen]

One thing we can all count on is that ED will try whatever they can to increase performance. Right now though, I can't see their approach changing in regard to multi-threading. Once we have 2.5 as a stable unified installation, who knows where they will be directing their efforts.

 

For starters the HDD re-loading textures could be fixed, which is causing stuttering for me in some select areas especially in beginning of a mission - However don't take my word, I'm still pending if my findings are valid, the test I did was maxing out VRAM, so it may not be valid.

 

This could be alleviated while porting Caucus to T4, so I'm fine if this won't be fixed for 1.5.

 

There's also many obsolete files the game is trying to load from the HDD, those queries cost time and hopefully that would be fixed for 2.5

[shagrat]

Neil,

 

the ded. server module will be an eye opener. Let me phrase it this way.

 

Stripped off the GUI, down to the core needed, we will see if a "respectable" machine can power

a 64-player session without stuttering and such..and how much headroom there is.

 

The ded. server will be the meter, by nature.

And then people will understand the limits imposed by objects aka airplanes, ground forces, bullets and missile ballistics for each damn projectile/missile, object status tables, mesh reference for LOS calculations, and lots of other stuff, like the script engine, trigger evaluation and all AI, including damage calculations the single CPU core needs to handle in addition to the ASM, PFM/EFM wind, pressure and G-forces for your airframe...

 

As long as you simply fly around, in your aircraft with a couple static trucks on the airport, that doesn't require much CPU. A full scale ground war over multiple areas on a map is a totally different story, though.

 

When the bullet storm from the Mi-8 beta was slowing DCS to a hold in 1.2 was a pretty good indicator of what ballistic calculations can do to a CPU of not optimized.

 

I agree, the DX10/11 introduction in 1.5/2.0 freed a lot of resources from the CPU, but depending on mission size and complexity, DCS is still hitting CPU...

 

I simply need to compare performance between my PC and a friend if mine. His rig is the same, only his i7 2600k is still not OC due to the boards chipset.

So he runs stock 3.4 GHz with boost to 3.8GHz.

Same GTX970 amount of RAM. He runs 1920x1080 with let's say moderate settings to have similar performance to my rig at 4.2 GHz running with 4k.

 

So from where I stand and from what I hear from devs, CPU is still an important factor and newer maps, with more objects, collidable trees and more detailed terrain mesh will show how long the GPU can help with that.

 

Just my two cents.

Edited November 20, 2016 by shagrat

[shagrat]

For starters the HDD re-loading textures could be fixed, which is causing stuttering for me in some select areas especially in beginning of a mission - However don't take my word, I'm still pending if my findings are valid, the test I did was maxing out VRAM, so it may not be valid.

 

This could be alleviated while porting Caucus to T4, so I'm fine if this won't be fixed for 1.5.

 

There's also many obsolete files the game is trying to load from the HDD, those queries cost time and hopefully that would be fixed for 2.5

Load stutters is mostly due to spawning units, thus initially loading their object models and textures into the memory.

Some models have a very high object count and cause considerable stuttering when loading later in the mission.

[Worrazen]

And then people will understand the limits imposed by objects aka airplanes, ground forces, bullets and missile ballistics for each damn projectile/missile, object status tables, mesh reference for LOS calculations, and lots of other stuff, like the script engine, trigger evaluation and all AI, including damage calculations the single CPU core needs to handle in addition to the ASM, PFM/EFM wind, pressure and G-forces for your airframe...

 

Understood, even tho I can't know the details, I have a better idea of why this is a much bigger challenge, most people we don't expect that the whole engine would have to be rewritten for this to be properly done.

 

I heard that "currently" it's one core + audio on another. Is that still the case?

 

Can at least draw calls be separated to 1 or 2 cores without having to rewrite the whole engine, or do they have to be synced ? I heard someone mention something around that somewhere, if you answered that already I apologize.

 

 

 

Load stutters is mostly due to spawning units, thus initially loading their object models and textures into the memory.

Some models have a very high object count and cause considerable stuttering when loading later in the mission.

 

Well did you saw this

 

 

Skip to 11:30

 

It's loading some terrain and airport textures from .zips all the time. It's doing this every time I cycle through airfield camera.

 

The top source offenders:

mods/terrains/CaucasusBase/Scenes/new2/districts.dstr

mods/terrains/CaucasusBase/Scenes/new2/land.isa3

mods/terrains/CaucasusBase/Scenes/new2/High.scn3

mods/terrains/CaucasusBase/vfstextures/LandTexturesSpring.zip

 

There's more queries for other effect and misc files (PNGs) but those are only opened from HDD, not read from.

Still the game has to wait for the HDD seek to find and complete OpenFile operation.

 

It takes sometimes several seconds for the airfield camera to change to another airfield from button press, I would call this a significant delay.

Viewing the landscape around the airport is also laggy exactly on times I register reads from HDD, and so do FPS drops correspond.

The FPS drop in this case is not an ordinary type one, it's just a consequence, the whole game grinds to a halt making rotating the view very hard because.

 

It's also re-loading some misc texture files (usa flag.png etc) each time I cycle through aircraft F2 camera.

 

Now I'm not 100% sure that's why I didn't post any PMLs or analysis except that video, because I'd like to test this on a newer GPU later.

At first I thought the texture streaming wasn't as good but then I saw there's only a handful of textures inside those zips that are causing this, most of it get's loaded properly.

 

And there's no need to fix anything for 1.5, the team just need to make sure this is fixed for 2.5 while they're already working on the new converted Caucasus map and dealing with managing textures so this issue doesn't keep dragging on post 2.5.

 

I was never a fan of texture streaming, the idea of that technology is to be playable on , mainly for consoles, everyone has more than enough system RAM for the whole materials of the mission to be loaded, it only takes 3 GB, and I have 16GB total, which I already ... am sorry for 3 years later (forgot that term), I should have gone with 32GB.

Edited November 20, 2016 by Worrazen

[shagrat]

 

Well did you saw this

 

 

Skip to 11:30

 

It's loading some terrain and airport textures from .zips all the time. It's doing this every time I cycle through airfield camera.

 

The top source offenders:

mods/terrains/CaucasusBase/Scenes/new2/districts.dstr

mods/terrains/CaucasusBase/Scenes/new2/land.isa3

mods/terrains/CaucasusBase/Scenes/new2/High.scn3

mods/terrains/CaucasusBase/vfstextures/LandTexturesSpring.zip

 

There's more queries for other effect and misc files (PNGs) but those are only opened from HDD, not read from.

Still the game has to wait for the HDD seek to find and complete OpenFile operation.

 

It takes sometimes several seconds for the airfield camera to change to another airfield from button press, I would call this a significant delay.

Viewing the landscape around the airport is also laggy exactly on times I register reads from HDD, and so do FPS drops correspond.

The FPS drop in this case is not an ordinary type one, it's just a consequence, the whole game grinds to a halt making rotating the view very hard because.

 

It's also re-loading some misc texture files (usa flag.png etc) each time I cycle through aircraft F2 camera.

 

Yes, currently audio on separate core only.

When you cycle through external views, that is totally normal. Textures and objects need to be in RAM when you pass them to direct x for rendering.

Just have a look at the overall textures and .edm object models. That all together in uncompressed form would be the RAM requirement.

 

Now the new render engine (EDGE) supports dynamic loading. It is by design to preload terrain and objects around the player aircraft and drop textures, objects etc. when not needed for rendering.

The idea is to get optimum performance with the scene around the player when he moves over the scenario.

 

So, basically, when you jump between different areas the loading of textures and objects works as designed.

 

Keep in mind, DCS is focused on realistic simulation of combat aviation.

Fancy external views are nice and good for screenshots, but to jump hundreds of miles from one plane to another in real-time, well isn't the most important task...

 

Compared to the limitations of the old DCS before EDGE this is simply fantastic...