DCS Newsletter discussion 2nd December 2022 - DCS 2.8 Multithreading | SATAL 2023

[PLUTON]

Hello Mr BIGNEWY,
I don't know if this question has already been asked but here goes
I put it,
When you say there will be an improvement in VR, (VR performance will also see a significant performance boost in large missions.) that means the change will only be felt in this condition! or even playing solo will the improvement be felt too?
Pardon my simplistic question but!!
Thank you for your work which makes us happy.

[Baldrick33]

1 hour ago, PLUTON said:

Hello Mr BIGNEWY,
I don't know if this question has already been asked but here goes
I put it,
When you say there will be an improvement in VR, (VR performance will also see a significant performance boost in large missions.) that means the change will only be felt in this condition! or even playing solo will the improvement be felt too?
Pardon my simplistic question but!!
Thank you for your work which makes us happy.

On my system (8600K @4.9Ghz, RTX2080Ti, 32Gb DDR4 3200) the instant action missions vary from being GPU limited to CPU limited depending on the mission, aircraft and map. So there isn't a simple answer.

For example the Apache seems to need more CPU, a furball mission in a WW2 aircraft quickly becomes CPU limited with the number of objects and some of the ground attack missions do the same.

So I believe there is plenty of scope for significant single player improvements as the load on the CPU gets shared across more cores.

[HoBGoBLiNzx3]

21 hours ago, NineLine said:

We really cant win, people demand news about stuff we give them news then they don't want news until its ready. There is no pleasing everyone, but we try.

We will not give out dates until its closer, so we didnt. We wanted to share progress news so we did. 

That is how life goes. However you do understand the confusion when post come out in late 2020 saying that multicore is in the "final stages of testing" and will hopefully be available Q3 2021. It's now Q4 2022 and we are getting a update about "If testing goes well"...

Haven't you been testing it for the last 2 years?

I'm genuinely curious and NOT trying to throw shade. Updating people on your work doesn't seem to be the issue as much as the updates being misleading... purposeful for not. 

Edited December 3, 2022 by HoBGoBLiNzx3

[Cab]

Personally I’d be happy if ED decided to release it as a temporary third branch: Stable, Open Beta, and Open Beta (multicore).

[Baldrick33]

26 minutes ago, Cab said:

Personally I’d be happy if ED decided to release it as a temporary third branch: Stable, Open Beta, and Open Beta (multicore).

I agree. The attachment of multiplayer to Open Beta makes a genuine “use at your own risk” beta version concept unlikely. I would fully support a third branch to accelerate testing feedback with a wider range of hardware and settings than a closed testing group can achieve.

[Weta43]

2 hours ago, Cab said:

Personally I’d be happy if ED decided to release it as a temporary third branch: Stable, Open Beta, and Open Beta (multicore).

But then you wouldn't be the one trying to keep track of bugs (& complaints) across 3 sections of forum (& code, which would be the bigger issue) instead of only 2 would you ?

Edited December 3, 2022 by Weta43

[Droning_On]

so should we all run out and buy 8 core CPU's or is 6 Cores sufficient ???   any guidance from ED testers please... im in desperate need to update my struggling 1600AF and a 5600x is a damn good price at the mo,  but might push the boat out to a 5700x or 5800x3d if the extra cores help DCS

[Cab]

1 hour ago, Weta43 said:

But then you wouldn't be the one trying to keep track of bugs (& complaints) across 3 sections of forum (& code, which would be the bigger issue) instead of only 2 would you ?

 

No

But keep in mind I didn't demand, or even ask for it. I just said it would make me happy.

Edited December 3, 2022 by Cab

[Nomatic]

Regarding the multicore & graphics engine update- this may seem arbitrary, but will you indicate when/if promotional videos are made using the new build? I know that may seem useless, but would be awesome to get 'eye's on', so to speak. Thanks!

 

edited: changed wording to sound less dumb

Edited December 4, 2022 by Nomatic

[Dragon1-1]

10 hours ago, Droning_On said:

so should we all run out and buy 8 core CPU's or is 6 Cores sufficient ???

You won't get much improvement past 4 unless you get faster single core performance as part of the package. Depending on how they split it, DCS will only use 2 or 3 cores for the foreseeable future, with proper scalability postponed to some unspecified time later.

[Mr_Burns]

Wow there are some real negative vibes on this thread. I want multi threading...here is the first iteration.....its only 2 threads....booooo

Slowly slowly catchy monkey.

[Gunfreak]

2 hours ago, Mr_Burns said:

Wow there are some real negative vibes on this thread. I want multi threading...here is the first iteration.....its only 2 threads....booooo

Slowly slowly catchy monkey.

Obligatory 

[TKu]

The path taken makes it makes totally sense. Better late than never.

Some people who complain probably don't have the right education to correctly assess what is being described. 

Keep up the good work Eagle and TFC.

[Gunfreak]

1 hour ago, TKu said:

The path taken makes it makes totally sense. Better late than never.

Some people who complain probably don't have the right education to correctly assess what is being described. 

Keep up the good work Eagle and TFC.

What ED is doing is probably something all of the "current flight sims" should. Because as far as I know, none of them utilise more than one core. Including the very big one with lots of Microsoft money. But except for that one, I don't think the others have the expertise/resources to do it.

[falcon_120]

so should we all run out and buy 8 core CPU's or is 6 Cores sufficient ???   any guidance from ED testers please... im in desperate need to update my struggling 1600AF and a 5600x is a damn good price at the mo,  but might push the boat out to a 5700x or 5800x3d if the extra cores help DCS

Even if multicore is great and the use of more cores improve performance, there will be times when single core performance will help, if I were you I would go 5800x3d, in the end is as good as you can go without changing the motherboard (latest AM4 upgrade for gaming).

Enviado desde mi ELE-L29 mediante Tapatalk

[_picon]

One thing to note is that the rendering today would actually be done on two threads (effectively), as the DirectX 11 driver would spin of a separate thread that will do the heavy lifting. Engine calls the DirectX 11 API calls on it's thread, and the driver will handle all API calls (in order) on a separate thread. 

It seems quite prudent to (as a first iteration) keep a single rendering thread that would still utilize DirectX 11, while spinning of more threads to handle other things. (yet prepare for more scaling). It would be quite interesting to hear if that is indeed what is the plan for the first release...

A naïve, single threaded, Vulkan (or Direct12) implementation will (almost) always behave even worse CPU usage wise even compared with DirectX 11, as the driver will not spin off a separate thread (normally) to split the work. This is all known, as one of the primary motivators for using Vulkan/DX12 in the first place is the ability to utilize multiple cores to do parallel recording of graphics commands.

[trevoC]

8 hours ago, Mr_Burns said:

Wow there are some real negative vibes on this thread. I want multi threading...here is the first iteration.....its only 2 threads....booooo

Slowly slowly catchy monkey.

I think you are misreading the temperature here.

Multi-threading is important for many VR users as we are currently limited by the CPU. What is disappointing for us is not being able to buy more modern hardware and get any realistic performance boost in VR. Multi-threading (allowing these processes to scale with hardware) will fix that and allow us to get better hardware to fix this. Although the upgrade from a 2080ti to 3090 did see gains, the 3090 is not maxed out but rather the CPU at this point.

The current graphics/logic split will not necessarily help the majority of the VR users who are CPU limited to gain much performance. It will be nice not dropping down to a slide show during the WWII campaigns when 50 bombers drop their loads, so that's nice and any improvement is welcome by all I believe, its just not multi-threading.

Splitting a loop into two loops and putting it on two different cores may look like multi-threading to some, but it is not.

Regardless of the performance gains by doing this first step (which don't get me wrong, is welcome. Not every time I express an opinion that is not "I love it' am I being negative towards ED or the community), regardless of these gains, we will immediately and quickly reach the same CPU limits until we are able to scale the largest bottleneck across multiple cores as needed and on demand, which is multi-threading.

Although there is the odd more negative than neutral comment here, I don't think the vibe is booooo. Its just a discussion. You have to expect some disappointment from VR users who are currently limited by the software instead of their hardware.

[SkateZilla]

A. Definition of Multi-
Combining Prefix | meaning more than one | So Logical + Rendering + Sound = 3 = Multi.  So despite the negative waves, it's Multi-Threaded.
 

I mean if people want to be negative about it, then they honestly have no knowledge of programming and allocated resources.
Here's the part those users don't understand, you simply CANNOT give everything it's own thread, the CPU would spend more time Syncing these threads, than anything else, and the performance would actually decline.

DCS as a Whole has 2 Main Bottle Necks: Sim-Calculations and DirectX11 API CPU Overhead, Which are very apparent in 2 Scenarios:
A. Large Scripted Missions with a lot of sim-calculations
B. Large Scenes w/ a lot of objects being rendered.

Splitting the DCS Process into Logical and Render Removes Bottleneck A. 
All the sim-calculations on One thread, and the Render instructions on another separates the Bottlenecking item into it's own thread.
Large Scripted Missions will not overload the thread with Sim-Calculations causing delay in render instructions, which will allow for better performance in larger scripted missions with a lot happening.

So if we break this down into something everyone can understand, ROADS / LANES.

We have right now 1 Lane.
DCS-CORE (SIM / RENDER), w/ RENDER Technically going to an Off-Ramp to DX11API's Thread/Road Leading to the GPU.
When You load a Large Scripted Mission, that 1 Lane Road becomes Saturated with DCS-SIM Traffic, and DCS-RENDER Traffic gets delayed getting to their Offramp to DX11's Thread/Road. Which causes delay in traffic reaching the GPU, which causes Low FPS.

Splitting the DCS-CORE into DCS-SIM CALCULATION and DCS-RENDER, Makes the Road 2 Lanes.
DCS-SIM CALCULATIONS and DCS-RENDER.
So Traffic for both DCS-Sim Calculation and DCS-Render flows smoother,
Even when DCS-Sim Calculation Traffic gets heavier, DCS-Render instructions will flow efficiently down the road to it's offramp to DX11API, and onto the GPU more efficiently.
Effectively Removing Traffic bottleneck A.

 

Now The Remaining Bottleneck is the DX11API Lane.
With DX11, there is Heavy Overhead on draw calls, so every object/shape, texture, effect, is a draw call, and with every draw call per cycle, the DX11API generates Processing time overhead, thus lowing the speed at which commands are processed by the CPU and Sent to the GPU, lowering Utilization and FPS/Performance.

This 1 Lane DX11API Road to the GPU, basically decreases it's speed limit as traffic increases, thus slowing down traffic flow to the GPU, Lowing GPU Utilization and FPS/Performance.

The next step is replacing the DX11 Graphics API w/ Vulkan, this effectively eliminates bottleneck B.

Moving to Vulkan Removes CPU Overhead with Draw Calls as well as DX11 API's Single Threaded Core and GPU Scheduling, and replaces it with a Multo-Threaded API that can process commands Asynchronously.

Large Scenes with hundreds of objects and thousands of draw calls per frame, will no longer get bottlenecked by the DX11 API Overhead, and performance will allow for better performance in scenes with large object counts.

Which Takes the 1 Lane Road of DX11API to the GPU and makes it a 4+ Lane Road of Vulkan.
Vulkan removes the Speed limit decreasing as traffic increases, as well as letting each lane move at it's optimal speed limit depending on traffic type.

Allowing DCS to Render Sim-Calculations in 1 Lane, Render Instructions in its own Lane, with the Render Traffic taking the Offramp to the Vulkan 4 Lane highway running at variable speed limits per lane.

So the Final Layout would be:
1 Lane for DCS-Sim Calculations
1 Lane for DCS-Render Instructions, w/ Offramp to Vulkan
4+ Lanes Variable Speed Limit for Vulkan to the GPU.

Considering the current Layout is:
1 Lane for DCS-CORE, w/ Offramp to DX11 API
1 Lane for DX11 API to GPU.

Seeing as DCS-Sound is its own lightly used thread, we can say DCS-SOUND uses the shoulder of the Road, lol.





 

Edited December 4, 2022 by SkateZilla

[Dragon1-1]

45 minutes ago, SkateZilla said:

Splitting the DCS Process into Logical and Render Removes Bottleneck A. 

It doesn't, and that's my problem with the current approach. I do not think only two threads will eliminate this bottleneck. Sure, taking the graphics out will help, but graphics can't run out of sync with the logic. The bottleneck will still be there, but wider. If the logic thread bogs down due to AI, mission scripting and FM all fighting for their share of the core, graphics will have to wait for it. Yeah, we'll have two lanes, but think of what happens if only one of them allows you to take a particularly popular exit (a situation I'm particularly familiar with due to my home city's planners being seemingly more concerned with getting fat off public money rather than actually making the place drivable).

Vulkan will no doubt improve the situation on the graphics front, particularly in VR (mostly because DX11's handling of VR is highly suboptimal), but parallelizing the simulation thread further is what is really needed. Bottleneck A will only really be gone if they give us multiple lanes for DCS-Sim, for example splitting FM calcs from AI brains (I think AI could be parallelized even further, since each unit mostly "thinks" on its own) and mission scripting.

[SkateZilla]

Keyword is "Main" Thread meaning likely secondary threads.

[Gunfreak]

3 hours ago, trevoC said:

I think you are misreading the temperature here.

Multi-threading is important for many VR users as we are currently limited by the CPU. What is disappointing for us is not being able to buy more modern hardware and get any realistic performance boost in VR. Multi-threading (allowing these processes to scale with hardware) will fix that and allow us to get better hardware to fix this. Although the upgrade from a 2080ti to 3090 did see gains, the 3090 is not maxed out but rather the CPU at this point.

The current graphics/logic split will not necessarily help the majority of the VR users who are CPU limited to gain much performance. It will be nice not dropping down to a slide show during the WWII campaigns when 50 bombers drop their loads, so that's nice and any improvement is welcome by all I believe, its just not multi-threading.

Splitting a loop into two loops and putting it on two different cores may look like multi-threading to some, but it is not.

Regardless of the performance gains by doing this first step (which don't get me wrong, is welcome. Not every time I express an opinion that is not "I love it' am I being negative towards ED or the community), regardless of these gains, we will immediately and quickly reach the same CPU limits until we are able to scale the largest bottleneck across multiple cores as needed and on demand, which is multi-threading.

Although there is the odd more negative than neutral comment here, I don't think the vibe is booooo. Its just a discussion. You have to expect some disappointment from VR users who are currently limited by the software instead of their hardware.

It will be nice possibly doing reflected's campaigns at full scale 

Even smaller missions are near unplayable. 

Tired the new Dieppe based missions (strange missions for ED to make given none of the planes are correct for that fight,  but that's a very different discussion)

As soon as I get overland, the bombs start falling and flak goes off. The FPS drops to love 20s at best.

[unltd]

Isn't DCS currently running essentially paralell processes now and each can be a bottleneck in certain cases?  So much depends on mission design.

1. Multiplayer server on one CPU

2. DCS sound on a cpu

3. DCS program on a CPU for logic

4. DCS graphics and maybe some physics on a GPU 

[trevoC]

12 hours ago, SkateZilla said:

A. Definition of Multi-
Combining Prefix | meaning more than one | So Logical + Rendering + Sound = 3 = Multi.  So despite the negative waves, it's Multi-Threaded.
 

I mean if people want to be negative about it, then they honestly have no knowledge of programming.

I agree with many of the items you have stated in your post skate, but unfortunately the definition of multi does not apply to multithreading which is actually one word.

Although I don't develop games (should say by trade as I have and do develop games for fun), I have been building multithreaded applications almost as long as I've been coding in general (over 30 years).

In this context, splitting logical pieces of codes (or their loops) into separate processes to run on separate processors is not multithreading. 

multithreading in the context of programming would be a single logical piece of code (the graphics loop as it was referred to for instance) being able to use multiple processors, allowing it to scale.

What DCS is doing now and looks like this announcement is mentioning is multiprocessing. Separate logical process executing on separate processors. Very different than multithreading because obviously you cannot scale any of these independent processes past 1 processor. The worst offending process will always be your bottleneck. Multithreading does not have this problem. A multithreaded process or application does not have the same type of bottlenecks. It does introduce a crap ton of problems and other issues, but I digress.

All of this is welcome, and noone is complaining from my end anyway, just discussing the difference and setting expectations.

As I have mentioned earlier in this thread, sending the draw calls direct to GPU (bypassing the CPU) with DX12 or vulcan will probably see more gains than multithreading anyhow.

That beings said, this was only an attempt to clear up the use of the word in this thread thus far.

8 hours ago, Gunfreak said:

It will be nice possibly doing reflected's campaigns at full scale 

Even smaller missions are near unplayable. 

Tired the new Dieppe based missions (strange missions for ED to make given none of the planes are correct for that fight,  but that's a very different discussion)

As soon as I get overland, the bombs start falling and flak goes off. The FPS drops to love 20s at best.

Reflected's campaign is the one I was thinking of.

It will probably be the first campaign I will re-visit (I paused it after I think mission 5 because of the slideshow I was getting).

So yes, this change will be welcome for this scenario. 

Edited December 5, 2022 by trevoC

[TKu]

Game development and multithreading will never be able to scale infinitely. We don't have a web server that is supposed to scale with only one number - the number id concurrent requests. The reality is much more complicated. It's more in the complexity of an operating system. You have to build the whole system instead of a dispatching module.

They wrote that they're going down a longer path now and that this will be built in multiple iterations. That's rhe way with a legacy codebase/architecture.

To my taste can not go fast enough. But some things just need time.

I'd like to see more like native linux server support with ipv6.

[trevoC]

7 hours ago, TKu said:

Game development and multithreading will never be able to scale infinitely.

Although I understand where you are coming from, I disagree.

Great progress is being made towards this end.

History suggests we will do incredible things and never need more than 640KB of RAM.

The future of Moore's law is in scalability, not single core speeds.

Industries will follow albeit slowly.