Jump to content

Multi-Threading Discussion


Canada_Moose

Recommended Posts

4 hours ago, Tom Kazansky said:

Weil, I hope it makes the RTX 4090 the new bottleneck. And maybe the RTX 5090 too. 😉

Not until DX11 API Overhead is gone.

DCS Has 2 Huge Bottlenecks, the Core, and the Graphics Engine API.

Removing the Core Bottleneck will not fix the Graphics Engine API's CPU Overhead Problem.

It will however remove the Core Bottleneck when in Large Missions with A LOT of AI and Scripting.

  • Like 4
  • Thanks 1

Windows 10 Pro, Ryzen 2700X @ 4.6Ghz, 32GB DDR4-3200 GSkill (F4-3200C16D-16GTZR x2),

ASRock X470 Taichi Ultimate, XFX RX6800XT Merc 310 (RX-68XTALFD9)

3x ASUS VS248HP + Oculus HMD, Thrustmaster Warthog HOTAS + MFDs

Link to comment
Share on other sites

3 hours ago, SkateZilla said:

Not until DX11 API Overhead is gone.

DCS Has 2 Huge Bottlenecks, the Core, and the Graphics Engine API.

Removing the Core Bottleneck will not fix the Graphics Engine API's CPU Overhead Problem.

It will however remove the Core Bottleneck when in Large Missions with A LOT of AI and Scripting.

So if I'm reading it right and to put it simply.  It would be like flying a "free flight" mission performance-wise but in a complex AI laden campaign mission, or even multiplayer?

Link to comment
Share on other sites

9 hours ago, skins45 said:

So if I'm reading it right and to put it simply.  It would be like flying a "free flight" mission performance-wise but in a complex AI laden campaign mission, or even multiplayer?

As stated, there are 2 Main Bottlenecks in DCS, the Core, the Graphics API.

Core:
Being a primarily Serialized set of code running on often a single thread, gets bogged down in heavy missions with scripts, AI Routines, Physics etc etc etc., when the thread is saturated with commands and scripts, it causes delay in processing, which causes FPS drops, freezes, sync issues, and delay in sending commands to DX11 API due to the saturation of the Main DCS Thread.

Going MT Removes 1 Bottleneck, by allowing DCS to Run on multiple threads, thus not allowing the Render commands to DX11's API to get held up waiting in line for Simulation Scripts to be processed. Thus more stable FPS, and likely an increase due to the fact that DCS's render commands are no longer waiting in line behind a bunch of AI, Physics and Weather Scripts/Functions/Code

GFX API:
Being also a serialized API, with a large overhead in high object count scenes, the more 3D Objects in a scene the higher the CPU Overhead, the higher the overhead, the slower your GPU receives instructions, the lower the GPU Utilization and the lower the FPS.

Going to Vulkan removes that overhead, so Large object count scenes do not slow down the commands to the GPU and thus, Utilization and FPS remain Higher. going Vulkan also removes DX11's Hard Limit on resolution, MSAA Type, Single Channel Instruction paths, HDD->CPU->GPU Memory Access Overhead,and about 20-30 other things I wont get into due to the complexity of the things, and outside of programming a normal user honestly wouldnt understand any of it. But they all affect GPU Usage and throughput, which affects FPS.

 

 

Until they are both gone, your GPU will not run Full tilt.
however if you remove the ST Bottleneck, then the only bottleneck remaining is the GFX API, so if you plop your F-16 at FL30, over water, with no other objects in sight and remove any limiters, you'd get a glimpse of that. But as soon as Objects start to populate the scene and the CPU Overhead builds up, those FPS will do down like a rock.


Edited by SkateZilla
  • Like 4
  • Thanks 7

Windows 10 Pro, Ryzen 2700X @ 4.6Ghz, 32GB DDR4-3200 GSkill (F4-3200C16D-16GTZR x2),

ASRock X470 Taichi Ultimate, XFX RX6800XT Merc 310 (RX-68XTALFD9)

3x ASUS VS248HP + Oculus HMD, Thrustmaster Warthog HOTAS + MFDs

Link to comment
Share on other sites

Wow, incredibly interesting.  This is extremely useful information to be had since I'm spec'ing out a new build for VR at the moment.  Prioritization is my biggest hurdle at the moment so knowing that a 13th gen Intel CPU might do better over the next year or two rather than the enormous cost for a 4090 is huge for me.  Looks like a 3090ti is going to work just fine. 

@SkateZillaDo you believe MT and Vulkan would be completed concurrently or MT significantly sooner? (I realize this isn't something you could confirm for obvious reasons, but given your background, what would you do?)

Link to comment
Share on other sites

10 minutes ago, skins45 said:

Wow, incredibly interesting.  This is extremely useful information to be had since I'm spec'ing out a new build for VR at the moment.  Prioritization is my biggest hurdle at the moment so knowing that a 13th gen Intel CPU might do better over the next year or two rather than the enormous cost for a 4090 is huge for me.  Looks like a 3090ti is going to work just fine. 

@SkateZillaDo you believe MT and Vulkan would be completed concurrently or MT significantly sooner? (I realize this isn't something you could confirm for obvious reasons, but given your background, what would you do?)

Tom Cruise Hide GIF

  • Like 4

Windows 10 Pro, Ryzen 2700X @ 4.6Ghz, 32GB DDR4-3200 GSkill (F4-3200C16D-16GTZR x2),

ASRock X470 Taichi Ultimate, XFX RX6800XT Merc 310 (RX-68XTALFD9)

3x ASUS VS248HP + Oculus HMD, Thrustmaster Warthog HOTAS + MFDs

Link to comment
Share on other sites

If MT is in closed beta state thats fine, we already knew this for weeks. Let's wish it can come out to the light (to the OB) in really very short term. I'd be hugely disappointed not able to test MT in OB this year, more than a YEAR after their previous ETA for Vulkan to finish...

Of course testing the core could be unimaginably complex task, so this could take arbitrary long time but I really hope this won't take years (not even months) to finish now.

  • Like 1
  • PC: 10700K | Gigabyte Z490 | Palit 3090 GamingPro | 32GB | Win10
  • HMD: HP Reverb G2 | OpenXR @ 120% | OpenXR Toolkit: exposure, brightness, saturation | DCS 2.9: DLAA with Sharpening 0.5 (no upscaling)
  • Controllers: VKB Gunfighter MkIII base & 200 mm curved extension center mounted + TM F16 Grip / MCG Pro Grip | TM TFRP
Link to comment
Share on other sites

Quite a while ago the heads of ED talked about "New Rendergraph engine" ... so in the end it may be practially a whole new* engine with not just "multi-core optimizations" bolted on, but being built for multi-core AND Vulkan API in mind from scratch, I hope that's the case.

 


Edited by Worrazen
  • Like 1

Modules: A-10C I/II, F/A-18C, Mig-21Bis, M-2000C, AJS-37, Spitfire LF Mk. IX, P-47, FC3, SC, CA, WW2AP, CE2. Terrains: NTTR, Normandy, Persian Gulf, Syria

 

Link to comment
Share on other sites

2 hours ago, Worrazen said:

Quite a while ago the heads of ED talked about "New Rendergraph engine" ... so in the end it may be practially a whole new* engine with not just "multi-core optimizations" bolted on, but being built for multi-core AND Vulkan API in mind from scratch, I hope that's the case.

 

 

What I don’t know about MC and Vulkan API’s could fill libraries however, of the little that I do understand, both of these things can be integrated, albeit with massive amount of work, into the current game. If however, things go too far down the path of reinventing the wheel, we could end up, I would assume, not being able to use so much of the current functionality and mod capabilities. 
 

I’d be interested to know what those who do know something about this think…..


Edited by Willie Nelson

i7700k OC to 4.8GHz with Noctua NH-U14S (fan) with AORUS RTX2080ti 11GB Waterforce. 32GDDR, Warthog HOTAS and Saitek rudders. HP Reverb.

Link to comment
Share on other sites

  • 2 weeks later...
1 hour ago, Glide said:

Does DX12 make it easier to offload graphics API calls to cores?  Does it bring all the benefits of Vulkan without a major platform shift?

 

DX12 is not the golden ticket everyone thinks it is.

To Fully Utilize DX12_0 Features, the engine still has to be entirely re-written,
MS's Easy Conversion path, is simply a conversion to run on DX12 Libraries however the engine will still be DX11_1 mode, while using the DX12 Libraries and Limit to DX12 O/S's.

Vulkan handles CPU Threads as well as GPU Commands more efficiently than DX12, especially in larger scenes.

 

 

  • Like 5
  • Thanks 1

Windows 10 Pro, Ryzen 2700X @ 4.6Ghz, 32GB DDR4-3200 GSkill (F4-3200C16D-16GTZR x2),

ASRock X470 Taichi Ultimate, XFX RX6800XT Merc 310 (RX-68XTALFD9)

3x ASUS VS248HP + Oculus HMD, Thrustmaster Warthog HOTAS + MFDs

Link to comment
Share on other sites

Ultimately, there's no easy way to handle this, and there can never be. Optimizing things for serial execution on a single core is a very different thing than making the code run on multiple cores in parallel. It's two completely different paradigms. This applies to both CPU and GPU. 

  • Like 1
Link to comment
Share on other sites

If only the rendering pipeline gets totally separated then that alone would yield huge gains imho. As I imagine in a simulator there"re a lot of subsystems which can be separated for parallel running in multiple threads and "sparse" syncing data. If the rendering can run freely, independently of the simulation then at least the stutters should be eliminated. For VR the display should be refreshed at 90 fps which is crucial for the smooth movement, but anything else is much less important (at least for me).

Who cares if the flight model is updated "only" 20 times a second? Or if the calculation of a missile control system updated only 10 per seconds? Or all the instruments in the cockpit at lower interval? Personally I don't care if the sound of an impact is late by 0,1 s (of course the interaction sounds should be prompt).

When ED made the original graphic engine then no one wanted to render a stereo image for two eyes at 90 fps with a resolution of 3100x3000 pixels/eye (with the current graphical fidelity levels). Now the main focus should be (and I'm pretty sure it is) this: very high frame rate at extreme stereo resolutions. I'm sure they'll find the proper solutiuon for this enormous task.

  • Like 1
  • PC: 10700K | Gigabyte Z490 | Palit 3090 GamingPro | 32GB | Win10
  • HMD: HP Reverb G2 | OpenXR @ 120% | OpenXR Toolkit: exposure, brightness, saturation | DCS 2.9: DLAA with Sharpening 0.5 (no upscaling)
  • Controllers: VKB Gunfighter MkIII base & 200 mm curved extension center mounted + TM F16 Grip / MCG Pro Grip | TM TFRP
Link to comment
Share on other sites

23 minutes ago, St4rgun said:

When ED made the original graphic engine then no one wanted to render a stereo image for two eyes at 90 fps with a resolution of 3100x3000 pixels/eye (with the current graphical fidelity levels). Now the main focus should be (and I'm pretty sure it is) this: very high frame rate at extreme stereo resolutions. I'm sure they'll find the proper solutiuon for this enormous task.

When ED made it, it was not possible to render at such resolutions in real time, with consumer-grade hardware. Indeed, it was first written at a time when four cores was a lot, and it was perfectly acceptable to use just one of them. Quality of the visual effects was much lower as well. OTOH, machine performance was a lot lower, too, and many things that we can do now simply weren't a thing yet.

What you're proposing is exactly what is happening. It just takes a lot of time, because most of the original code can't really be reused. It is quite possible to run some things like physics and AI at rates not closely coupled to rendering framerate, I don't know if DCS already does that, though.

  • Like 2
Link to comment
Share on other sites

On 11/14/2022 at 11:54 AM, St4rgun said:

Who cares if the flight model is updated "only" 20 times a second? Or if the calculation of a missile control system updated only 10 per seconds? Or all the instruments in the cockpit at lower interval? Personally I don't care if the sound of an impact is late by 0,1 s (of course the interaction sounds should be prompt).

You have no idea what you are talking about. If you don't enforce a frame rate for the physics rendering, the differing quantisation errors add up over time and lead to completely different results. The graphics rendering doesn't necessarily need to run on a fixed fraction of that, but the physics engine very much needs to have a constant frame rate, otherwise it will start behaving very wonky.


Edited by sobek

Good, fast, cheap. Choose any two.

Come let's eat grandpa!

Use punctuation, save lives!

Link to comment
Share on other sites

1 hour ago, sobek said:

You have no idea what you are talking about. If you don't enforce a frame rate for the physics rendering, the differing quantisation errors add up over time and lead to completely different results. The graphics rendering doesn't necessarily need to run on a fixed fraction of that, but the physics engine very much needs to have a constant frame rate, otherwise it will start behaving very wonky.

 

"You have no idea what you are talking about." Sorry, what?

"If you don't enforce a frame rate for the physics rendering" who said anything like that? I said it can be lower (or much lower) than the refresh rate of graphics rendering.

As you said "the physics engine very much needs to have a constant frame rate" which is pretty much not the case if you closely bind it to the graphics rendering right now, because the framerate is all over the place without motion reprojection.

What I said that graphics rendering should have maximum priority especially for head movement in VR to have it nailed to 90 fps.

Everything else in the simulation can wait. The graphics cant.

  • PC: 10700K | Gigabyte Z490 | Palit 3090 GamingPro | 32GB | Win10
  • HMD: HP Reverb G2 | OpenXR @ 120% | OpenXR Toolkit: exposure, brightness, saturation | DCS 2.9: DLAA with Sharpening 0.5 (no upscaling)
  • Controllers: VKB Gunfighter MkIII base & 200 mm curved extension center mounted + TM F16 Grip / MCG Pro Grip | TM TFRP
Link to comment
Share on other sites

Some logic already runs once every few frames. Whether it applies to physics as a whole, I don't know, but it probably does. Steady framerate (in terms of frames per real time), is not needed for physics, right now basically when the sim bogs down, time slows down. However, it needs to be steady relative to graphics rendering. Close coupling, like we currently have, fulfills that.

Link to comment
Share on other sites

6 hours ago, St4rgun said:

"You have no idea what you are talking about." Sorry, what?

You heard me. If the physics engine ran at anything close to as low as what the graphics engine runs, the input lag alone would be horrible.

 

  

6 hours ago, St4rgun said:

Everything else in the simulation can wait. The graphics cant.

Again, you do not understand the consequences of what you propose here. This would break the simulation.


Edited by sobek

Good, fast, cheap. Choose any two.

Come let's eat grandpa!

Use punctuation, save lives!

Link to comment
Share on other sites

15 hours ago, St4rgun said:

"You have no idea what you are talking about." Sorry, what?

"If you don't enforce a frame rate for the physics rendering" who said anything like that? I said it can be lower (or much lower) than the refresh rate of graphics rendering.

As you said "the physics engine very much needs to have a constant frame rate" which is pretty much not the case if you closely bind it to the graphics rendering right now, because the framerate is all over the place without motion reprojection.

What I said that graphics rendering should have maximum priority especially for head movement in VR to have it nailed to 90 fps.

Everything else in the simulation can wait. The graphics cant.

So much gross mis-information and assumptions about programming in this post.

  • Like 2
  • Thanks 1

Windows 10 Pro, Ryzen 2700X @ 4.6Ghz, 32GB DDR4-3200 GSkill (F4-3200C16D-16GTZR x2),

ASRock X470 Taichi Ultimate, XFX RX6800XT Merc 310 (RX-68XTALFD9)

3x ASUS VS248HP + Oculus HMD, Thrustmaster Warthog HOTAS + MFDs

Link to comment
Share on other sites

15 hours ago, Dragon1-1 said:

Steady framerate (in terms of frames per real time), is not needed for physics, right now basically when the sim bogs down, time slows down.

I must be playing a different simulation then.

Good, fast, cheap. Choose any two.

Come let's eat grandpa!

Use punctuation, save lives!

Link to comment
Share on other sites

15 hours ago, sobek said:

You heard me. If the physics engine ran at anything close to as low as what the graphics engine runs, the input lag alone would be horrible.

??? OK, right then, I'm out.

  • PC: 10700K | Gigabyte Z490 | Palit 3090 GamingPro | 32GB | Win10
  • HMD: HP Reverb G2 | OpenXR @ 120% | OpenXR Toolkit: exposure, brightness, saturation | DCS 2.9: DLAA with Sharpening 0.5 (no upscaling)
  • Controllers: VKB Gunfighter MkIII base & 200 mm curved extension center mounted + TM F16 Grip / MCG Pro Grip | TM TFRP
Link to comment
Share on other sites

Anyhow it's not our responsibility to solve such problems, we are just making a discussion on this topic here. It would be very interesting to read some whitepaper about this game engine but this will not happen I suppose.

All we can do is wait for ED to finish the internal beta test for MC. By the way, @SkateZilla is it still classified that we are weeks, months or years away from the end of that test?

  • PC: 10700K | Gigabyte Z490 | Palit 3090 GamingPro | 32GB | Win10
  • HMD: HP Reverb G2 | OpenXR @ 120% | OpenXR Toolkit: exposure, brightness, saturation | DCS 2.9: DLAA with Sharpening 0.5 (no upscaling)
  • Controllers: VKB Gunfighter MkIII base & 200 mm curved extension center mounted + TM F16 Grip / MCG Pro Grip | TM TFRP
Link to comment
Share on other sites

  • 2 weeks later...

It was great news to have this update, was beginning to think after my article in PC Pilot in Sept 2021 it would never come to fruition!

Multi-threading / multi-core will be even more important when the Dynamic Campaign engine emerges ... that could well be a significant resource hog and it's own dedicated core could be pivotal to that smooth user experience.

Next year could be a long year - looking forward too to hearing more about Vulkan implementation etc...

 


Edited by C3PO

Now: Water-cooled Ryzen 5800X + 32GB DDR 4 3200 RAM + EVGA 3090 FTW3 Ultra 24 GB + Reverb G2 + Add-on PCI-e 3.1 card + 2x1TB Corsair M.2 4900/4200 + TM HOTAS Warthog + TM TPR Pendular Rudder  'Engaged Defensive' YouTube Channel

Modules: F/A-18C / AV-8B / F-16 / F-15E / F-4E (when it lands) / Persian Gulf / Syria / Nevada / Sinai / South Atlantic

Backup: Water-cooled i7 6700K @ 4.5GHz + 32GB DDR4 3200MHz + GTX 1080 8GB + 1TB M.2 1k drive & 250GB SSD drive 500MBps 4K 40" monitor + TrackIR 5

 

 

Link to comment
Share on other sites

  • Wags changed the title to Multi-Threading Discussion
  • 2 weeks later...

Because it was "announced" / mentioned frequently in the last weeks, I was expecting the multi core support in DCS in this update. I didn't see in the release notes, but also not in the "Coming after this update" section. Is it already included - I assume not? Any ideas, when we can expect it?

Even when I have read that we shouldn't expect that high performance boost - as an VR player, I appreciate any performance improvement I can get.

________________________ ________ ______ ___ __ _

Win10 64 Pro, i7-6800K 3.4Ghz, 32 GB (DDR4), Asus Aorus 1080 TI WF, TrackIR 5 / RIFT, Thrustmaster Warthog, Fanatec Pedals, 55" oled 4k TV, Modules:A10C, KA-50, Huey, AV-8B, FA-18, F-16, NTTR, Persian Gulf

_ __ ___ ____ _____ ______ _______ ____________



Link to comment
Share on other sites

It was announced recently for a later release in 2023, but not in 2022 or even this actual OB.

  • Like 3

DCS MT 2.9.3.51704
Modules: UH-1H - SA342 - KA-50 BS3 - MI-24P - MI-8MTV2 - AH-64D - UH-60L(Mod) - A-10CII - F-16C - F/A-18C - Combined Arms
 - Supercarrier - FC3 - NTTR - Normandy2.0 - Persian Gulf - Syria - SA - Sinai — Waiting for: OH-58D - BO105 - CH-47F - AH-1G(Mod) - OH-6(Mod) - Kola  - Australia - Afghanistan - Iraq

DCS-Client: 10900K, 64GB 3600, RTX3090, 500GB M2 NVMe(win10), 2TB M2 NVMe(DCS), VR VivePro2, PointCTRL, VaicomPro, Wacom Intuos S with VRK v2Beta

DCS-DServer: 11600KF, 32GB 3600, GTX1080, 1TB M2 NVMe(win10), 2TB M2 NVMe(DCSDServer)

Simpit: NLR Flightsim Pro, TM Warthog(40cm Ext., Dampers) + Throttle, Komodo Pedals with Dampers, VPC Rotorplus+CBkit+AH-64D Grip, NLR HF8, Buttkicker (3*MiniConcert), TotalControls AH64D MPD‘s, TM 2*MFD‘s, Streamdecks (1*32,3*15,1*6), VPC CP#1

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...