reported Multithreading: Flipping between F10 and F1 Causing intense, and lasting screen-tearing in VR

[desolunatic]

9 minutes ago, Recluse said:

Ok Just installed it.  Are you recommending the setting as shown, or pointing it out as a potential issue not ALLOWING SYSMEM fallback from VRAM to SYSTEM Memory?

 

Set it to "Prefer No Sysmem Fallback" and check if DCS runs better. (Couz the default setting is different)

[Avii]

Booted up my pc, made the change in the nvidia control panel, started dcs.. checked the f10 map for the status of the server, jumped in an apache, waited for the textures etc to load, and it dropped down to 5fps..

DxDiag.txt

 

edit:

After a second "session" (restarting the game) I was able to fly with fairly stably, but after 15~20 minutes or so, frames started jittering between 15 and 25fps. When in external (F2) views, frames go back to normal, but in cockpit view (F1) it instantly drops back down to 15~25.

When looking at the stats in external view, the vram usage is around 5gb/6gb (less than max) and when in cockpit, it's always 7gb/6gb (more than max) when fps is unstable

 

 

Edited November 11, 2023 by Avii

[edmuss]

6 hours ago, desolunatic said:

People having this issue, can you check if setting in Nvidia Control Panel - CUDA Sysmem fallback policy set to "Prefer No Sysmem Fallback" helps?
 

 

Just updated to latest nvidia drivers, set this accordingly to prefer no sysmem fall back and booted mi24p Syria weapons range, straight load to cockpit 9.5gb usage of 10.5gb budget, smooth as you like, no overflow and no massive stutters!  It was slightly laggier to load into F10 map but once loaded it was all smooth, certainly before I couldn't fly with 9.5gb usage!

I've not tested it extensively but it initally seems to be a good workaround, excellent spot @desolunatic, go test it people

[Burt]

I do feel a gain in smoothness so I will agree

[niru27]

22 hours ago, desolunatic said:

People having this issue, can you check if setting in Nvidia Control Panel - CUDA Sysmem fallback policy set to "Prefer No Sysmem Fallback" helps?

No fps drops in map/exterior views in a couple of sessions so far. Will test over the next few days and update, since this happens to me randomly

[jnr4817]

22 hours ago, edmuss said:

Just updated to latest nvidia drivers, set this accordingly to prefer no sysmem fall back and booted mi24p Syria weapons range, straight load to cockpit 9.5gb usage of 10.5gb budget, smooth as you like, no overflow and no massive stutters!  It was slightly laggier to load into F10 map but once loaded it was all smooth, certainly before I couldn't fly with 9.5gb usage!

I've not tested it extensively but it initally seems to be a good workaround, excellent spot @desolunatic, go test it people

WHat exactly is this setting doing and how is it interacting with DCS?

[Avii]

13 hours ago, jnr4817 said:

WHat exactly is this setting doing and how is it interacting with DCS?

That'd be the setting mentioned in this post

Edit: I totally misread the question, my bad..

When putting the mouse over the option in question, Nvidia control panel shows a description listing the following:

 

Personally, I haven't noticed a difference with it on or off in MT. eventually it still over-allocates and kills all frames.

Edited November 13, 2023 by Avii

[edmuss]

11 hours ago, jnr4817 said:

WHat exactly is this setting doing and how is it interacting with DCS?

Truth be told, I don't exactly know, however initial tests were positive in my use case.

 

8 hours ago, Avii said:

That'd be the setting mentioned in this post

Personally, I haven't noticed a difference with it on or off in MT. eventually it still over-allocates and kills all frames.

DCS will still overallocate if your usage surpasses budget, logically with no sysmen fallback it may hard crash DCS.  What this did on my system was reduce the allocated budget by 800mb (11.3gb down to 10.5gb with fallback off) and allowed the VR compositor to continue working whilst using much larger percentages of the allocated budget.  Previously I would get the issue at >7gb usage with 11.3gb budget, in my brief testing I saw 9.5gb usage with 10.5gb budget without the massive stutter issue.  I have no doubt that if I went over 10.5gb usage it would be horrific

This does nothing to manage VRAM load, you have to do this yourself, I use Taz's optimised textures and that generally is sufficient with my 12gb GPU to keep things smooth.

As to why the VRAM budget changed, I'm not sure, I would hazard a guess that DCS will set the budget based upon the VRAM available to the GPU.  If with sysmem fallback enabled it may be that the GPU is telling DCS that it has access to the system RAM (indeed windows task manager states that I have 12gb dedicated VRAM with 26gb total available) and it sets it accordingly; perhaps with no sysmem fallback it's seeing a hard limit of 12gb so drops the allocation a little?

Edited November 13, 2023 by edmuss

[toilet2000]

7 hours ago, edmuss said:

Truth be told, I don't exactly know, however initial tests were positive in my use case.

 

DCS will still overallocate if your usage surpasses budget, logically with no sysmen fallback it may hard crash DCS.  What this did on my system was reduce the allocated budget by 800mb (11.3gb down to 10.5gb with fallback off) and allowed the VR compositor to continue working whilst using much larger percentages of the allocated budget.  Previously I would get the issue at >7gb usage with 11.3gb budget, in my brief testing I saw 9.5gb usage with 10.5gb budget without the massive stutter issue.  I have no doubt that if I went over 10.5gb usage it would be horrific

This does nothing to manage VRAM load, you have to do this yourself, I use Taz's optimised textures and that generally is sufficient with my 12gb GPU to keep things smooth.

As to why the VRAM budget changed, I'm not sure, I would hazard a guess that DCS will set the budget based upon the VRAM available to the GPU.  If with sysmem fallback enabled it may be that the GPU is telling DCS that it has access to the system RAM (indeed windows task manager states that I have 12gb dedicated VRAM with 26gb total available) and it sets it accordingly; perhaps with no sysmem fallback it's seeing a hard limit of 12gb so drops the allocation a little?

 

I would have to test it, but if this work, my guess would be that DCS asks DirectX for the available VRAM, which would return the total GPU VRAM if the driver implements system memory fallback is enabled, but the available VRAM (total VRAM minus current usage/reserved memory) if it is disabled, meaning DCS will never force a VRAM-host RAM swap of the VR runtime.

This is if it actually works, as this setting is labeled as "CUDA" and therefore I would assume this might apply to CUDA workloads only and perhaps not DirectX/OGL/Vulkan workloads. We often see the placebo effect in action when it comes to DCS and VR performance.

I'll check if I can find more info on that option and the possible DirectX calls DCS does to find the available VRAM.

[edmuss]

17 minutes ago, toilet2000 said:

I would have to test it, but if this work, my guess would be that DCS asks DirectX for the available VRAM, which would return the total GPU VRAM if the driver implements system memory fallback is enabled, but the available VRAM (total VRAM minus current usage/reserved memory) if it is disabled, meaning DCS will never force a VRAM-host RAM swap of the VR runtime.

This is if it actually works, as this setting is labeled as "CUDA" and therefore I would assume this might apply to CUDA workloads only and perhaps not DirectX/OGL/Vulkan workloads. We often see the placebo effect in action when it comes to DCS and VR performance.

I'll check if I can find more info on that option and the possible DirectX calls DCS does to find the available VRAM.

That was my nominal thinking on it.
The CUDA thing had me really sceptical about it at first, but I was pleasantly suprised with the quick initial test (note that I've not been able to test any further yet).  Perhaps the CUDA in this case is relating to the CUDA cores (as in the hardware cores of the GPU) rather than the API?

If indeed it does work and continues to work, it's still a sticking plaster and shouldn't need to be relied on

[toilet2000]

6 minutes ago, edmuss said:

That was my nominal thinking on it.
The CUDA thing had me really sceptical about it at first, but I was pleasantly suprised with the quick initial test (note that I've not been able to test any further yet).  Perhaps the CUDA in this case is relating to the CUDA cores (as in the hardware cores of the GPU) rather than the API?

If indeed it does work and continues to work, it's still a sticking plaster and shouldn't need to be relied on

Yeah, but some unofficial sources says it may apply to non-CUDA workloads also... So maybe?

My guess is that DCS perhaps uses the IDXGIAdapter3::QueryVideoMemoryInfo method or a similar way to get the DXGI_QUERY_VIDEO_MEMORY_INFO struct which contains the `AvailableForReservation` field that it could use to infer the amount of VRAM to reserve. See: https://learn.microsoft.com/en-us/windows/win32/api/dxgi1_4/ns-dxgi1_4-dxgi_query_video_memory_info

If `AvailableForReservation` changes according to the system memory fallback option, then it could really be that it isn't a placebo. I'll see if I can get a confirmation of that later today.

[edmuss]

Managed to do a little more testing last night with mixed results, the times that the VRAM budget stayed below 11GB (generally 10.5-10.7) it was all good, however it wasn't consistently keeping the budget reduced and did still occasionally push up to the 11.3GB which would then cause the overflow.  Forcing the cockpit texture reload (F10/alt tab till flushed/alt tab/F1) would drop the usage back to acceptable levels.

Take away is that it's inconsistent and isn't a reliable fix although it does appear to do something (likely not intentional, possibly placebo/situation dependant).  I still reckon reducing the budget to GPU VRAM less 1.5GB would be prime trial to solve the issue.

[user499302]

This issue only seems to be present in the multithreaded version and doesn't seem to affect me in Single threaded.   In multithread it happens every time, it may take 4-5 f10 presses but when it happens the FPS drops and is unrecoverable without restarting DCS.  Makes VR unplayable.

No issues with single threaded on steam.

 

 

 

[RealDCSpilot]

For me the issue seems to be completely gone now. Sadly i can't put my finger directly on it, to much parallel changes were going on in the latest weeks (switched from SteamVR to VDXR with Virtual Desktop). But my suspect #1 is the new Nvidia driver feature. I can now play for hours in huge multiplayer servers, switch modules and so on, no freezes - no stuttering.

[BenBenBeartrax]

Please consider the findings in this video as well: 

It investigates and speculates on the effects of multithreading, heavy parallel IO and the number of cores available.

[DrBob]

With new update dcs and driver its worse for me. Actually fallback to sys memory ncp option seems better. Flipping focus doesn't always work now. 

[Mr_sukebe]

Chaps,

Check your RAM (not VRAM).

Jabbers very good video did spot the VRAM use, but didn’t highlight the system RAM use.  Watch the video again and you’ll see that there’s a massive increase in RAM use just prior to the FPS drop.

My “guess” is the DCS-MT might be parallel processing the unpacking of texture files (or similar) and is doing this using system RAM.  With the additional cores being available, DCS is using more system RAM, to the point that windows ends up using swap files.

Jabbers suggestion is using CPU affinity to restrict the number of cores being used would therefore reduce that parallel increase in the use of RAM and is a brill idea.

If my guess is correct, does this mean that we should now be looking at our next PCs having 128GB or RAM.

Hopefully ED will write some clever code that will check the RAM of the PC that’s available and scale the CPU core numbers used on the fly.

 

[edmuss]

Jabbers issue isn't the one being discussed in this thread though, that issue is completely different to the VRAM overallocation.

edit: a couple of comparison screenshots, mi24p instant action weapon range on Syria. First is high textures, second is medium textures; both are utilising Taz's optimised textures. GPU has 12gb onboard.

Check the usage of ~8gb and the horrific graph spiking compared to the usage of ~6gb and the perfectly smooth graphs. Both are completely within the budget of 10-11gb set by DCS.

It's VRAM overallocation causing the runtime to fall over.

Edited November 20, 2023 by edmuss

[BIGNEWY]

Hi all, 

the team have reproduced and a report has been made internally, 

thank you