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

[Recluse]

2 hours ago, edmuss said:

Does the same thing, not everyone delves into the depths of the menus though!

Should be 8Gb on a 3070

This is also a good observation, the overflow doesn't happen when usage approaches 100%, I have seen it happen at 7GB but also been flying perfectly smoothly at 9gb....

It isn't just a VRAM capacity thing, something else is playing it's part to cause the problems.

Yep.. 8 GB.. slip of the keyboard... EDIT: Actually, the reason for that "slip" was Open XR Toolkit shows me at 100% VRAM usage at 6 GB.... so no wonder I had that in my head.  Er...any idea why it is not seeing all 8?  Some setting I am missing, or is OXRTK capped at 6 GB for reporting?  I wondered why sometimes I do see 104% usage..

 

Edit Apparently 2 GB of VRAM are reserved for the SYSTEM and not available to applications, so for all intents and purposes I only have 6 GB for DCS

 

Edited October 26, 2023 by Recluse

[krostar]

Issue is still present for me, in MT solo and MT multiplayer.

Running the latest Nvidia drivers & Windows updates.

Edited October 27, 2023 by krostar

[niru27]

@BIGNEWY @desolunatic In 2d, the the problem is triggered in the exact opposite way: I made a macro that sends Alt+Tab whenever is switch to/fro any external view. The moment I get Alt-Tab'd to another application, that's when my GPU goes to 100% and fps drops. As soon as I return to F1, fps returns to normal.

Only difference is I'm on Low preset and MSI Afterburner shows my VRAM in 2k range, so my graph doesn't exceed the max VRAM.

Bignewy, should I open a separate thread and post a video there, or wait until the VR issue is investigated as that might offer some insight to this problem?

 

Edit: forgot to add screenshot

Does anyone know what PRESENT indicates in the graph?

Edited October 27, 2023 by niru27

[Adrian858]

I've been having this problem for a while now too, although lessened with 2.9 and tweaking my settings a bit. The latest culprit appears to be the F-15E at random, occasionally the Apache, F-14 when attempting to land on the boat, and when flames appear (destroyed buildings), with VRAM significantly spiking requiring an Alt-Tab to calm it down. Otherwise 2.9 has been running extremely smooth for me.

Edited October 27, 2023 by Adrian858

[desolunatic]

3 hours ago, niru27 said:

@BIGNEWY @desolunatic In 2d, the the problem is triggered in the exact opposite way: I made a macro that sends Alt+Tab whenever is switch to/fro any external view. The moment I get Alt-Tab'd to another application, that's when my GPU goes to 100% and fps drops. As soon as I return to F1, fps returns to normal.

Only difference is I'm on Low preset and MSI Afterburner shows my VRAM in 2k range, so my graph doesn't exceed the max VRAM.

Bignewy, should I open a separate thread and post a video there, or wait until the VR issue is investigated as that might offer some insight to this problem?

 

Edit: forgot to add screenshot

 

Does anyone know what PRESENT indicates in the graph?

 

But am I understanding correctly that you are also getting FPS drops in F10 view during normal play?

[niru27]

18 hours ago, desolunatic said:

But am I understanding correctly that you are also getting FPS drops in F10 view during normal play?

That's right.
F1 view = normal 60+ fps
I press F10 = fps drops to <20, sometimes <10
I press F1 =  normal 60+ fps, as though nothing happened at all.

Happens even with Low preset + 1280x720 resolution, and my VRAM no where close to 8 or 6 GB whichever is the usable limit

Edited October 28, 2023 by niru27

[Recluse]

I will add another observation, though it may be a different issue altogether:

(VR, Quest2, AirLink RTX3070 Core i7 10700K 32 GB RAM) 

 

Recently (after 2.9, but I cannot say for sure it didn't happen previously, but now it is more repeatable) everything is fine, flying around with 40-50 fps (Multiplayer, reasonably complex mission)  and then after about 70-90 min of flying,  my frames will drop to 10-12 in cockpit view and no amount of ALT TAB seems to fix it.  My VRAM is sitting at about 50% usage. When I go into the F10 map, I see FPS go back up to ~39-40 but switching back to F1, they are back to 10-12. Only way to fix seems to be complete exit from DCS and restart (usually I restart the Quest 2 as well for good measure).

(Seems independent of aircraft flown)

 

Edited October 28, 2023 by Recluse

[Wizard1393]

Still having this issue also. Can't use the F10 map anymore, it always lowers FPS to ~20 and will not return to normal after going back to F1 view. Have to restart DCS to resolve the issue.

Edited October 29, 2023 by Wizard1393

[edmuss]

I have been doing more testing on this, not specifically to combat the F10 map performance tanking (although that may be linked) but to try to investigate what's causing the performance to tank in the first place.

The issue is definitely VRAM related, but I don't believe that it's due to a specific lack of VRAM capacity, more the overallocation of VRAM.

During testing I have seen performance regularly tank with the frametimes spiking all over the place, this is with around 7GB of VRAM used (according to the DCS metrics and corroborated with MSI afterburner), however DCS metrics are stating a budget of 11.3GB (using a 12GB 3080ti) and MSI is showing a total usage of 12.1GB.  The VRAM is being paged to system RAM despite the fact that only 60% of it is being used.

Going back around 18 months when the use of openxr in DCS was becoming more widespread via open composite, I had discovered a similar issue occuring that was causing performance to tank if reprojection was enabled. This was investigated by @mbucchia who identified that it was an overallocation of VRAM that was preventing the runtime from being able to function correctly.  At the time he was able to make an alteration to the WMR openxr that marked the compositor memory as locked and this completely fixed the issue 100%.  However this workaround is not really the correct way of doing things, it should be DCS not overallocating VRAM rather than each VR vendor making changes to their runtimes to accommodate.

I don't know if current WMR users are having any issues with this VRAM overflow bug (for want of a better name) or not, 24GB cards are not going to be affected so it needs to be tested on specific hardware.

@BIGNEWY could you please pass this information forwards to the necessary team and see if the allocation of VRAM could be reduced in order to allow the VR runtimes to run the compositors correctly?

[DrBob]

15 hours ago, edmuss said:

I have been doing more testing on this, not specifically to combat the F10 map performance tanking (although that may be linked) but to try to investigate what's causing the performance to tank in the first place.

The issue is definitely VRAM related, but I don't believe that it's due to a specific lack of VRAM capacity, more the overallocation of VRAM.

During testing I have seen performance regularly tank with the frametimes spiking all over the place, this is with around 7GB of VRAM used (according to the DCS metrics and corroborated with MSI afterburner), however DCS metrics are stating a budget of 11.3GB (using a 12GB 3080ti) and MSI is showing a total usage of 12.1GB.  The VRAM is being paged to system RAM despite the fact that only 60% of it is being used.

Going back around 18 months when the use of openxr in DCS was becoming more widespread via open composite, I had discovered a similar issue occuring that was causing performance to tank if reprojection was enabled. This was investigated by @mbucchia who identified that it was an overallocation of VRAM that was preventing the runtime from being able to function correctly.  At the time he was able to make an alteration to the WMR openxr that marked the compositor memory as locked and this completely fixed the issue 100%.  However this workaround is not really the correct way of doing things, it should be DCS not overallocating VRAM rather than each VR vendor making changes to their runtimes to accommodate.

I don't know if current WMR users are having any issues with this VRAM overflow bug (for want of a better name) or not, 24GB cards are not going to be affected so it needs to be tested on specific hardware.

@BIGNEWY could you please pass this information forwards to the necessary team and see if the allocation of VRAM could be reduced in order to allow the VR runtimes to run the compositors correctly?

Thx fo the insights all.

So would changing the paging file settings to default on windows side help?

I have a q3(q2 before with same issue). Can I change anything on wmr?

Sometimes for me, I go straight and level, take off the headset for a min or so and that solves it.

Its a real bugger this issue!

[edmuss]

Just now, DrBob said:

Thx fo the insights all.

So would changing the paging file settings to default on windows side help?

I have a q3(q2 before with same issue). Can I change anything on wmr?

Sometimes for me, I go straight and level, take off the headset for a min or so and that solves it.

Its a real bugger this issue!

Unfortunately no, this is nothing to do with windows page file, this is the GPU being forced to use the comparatively slow system RAM (and the data transfer limitations of where it is in the system) instead of the very fast VRAM that's onboard of the GPU.
Having more VRAM will mask the issue so all of the 16GB+ GPUs I think will struggle to see the problem.

You're not using WMR with the quest as it's the occulus runtime; can only hope that a resolution to the problem is actioned by ED, all being well there should be a fix in the works but it's been an issue for the last 2-3 years at least!

[Special K]

Guys, as I commented below that video already, what you are doing here is black magic.

You are misusing the Windows scheduler to "magically solve" an issue that DCS has, namely not freeing used memory properly. Whenever you unfocus an application (ALT+TAB), you tell Windows that it is not the #1 priority application anymore. Now the Windows memory management will mark all your nice memory pages that you have used a second ago as candidates for swapping. As DCS is the main user of your RAM and VRAM at that time and Windows is eager to free some of that up, it is very happy about your move. It's doing what you ask it to do - freeing up memory, in this case either for the application that you swapped to (youtube, notepad++, your file explorer, whatnot, something that was used before you started DCS) or your DWM. It now loads that into memory.

Now you switch back to DCS. What happens? Well, it depends. If you have lots of RAM, in first place nothing. It will mark the memory pages from your DWM, Notepad, whatnot as disposable. Whenever you now need RAM for DCS, you'll get it much easier. Until the point where you need that stuff again, that you just swapped out earlier. Doing it with a lot of RAM might not even get you to the point that you see what you are doing. It's the same "black magic" trick that someone put out about a year ago where he said, giving the DCS process less memory solves issues. You just give DCS less memory to play with.

On the other hand, if you **don't** have enough RAM, you're doing something really really bad to your system. The amount of swapping with DCS is already ridiculously high and you force your system to do even more of it. This will result in lots of swapping, even more wearing of your disks, etc.

Don't get me wrong, I appreciate the ideas you guys develop to get rid of long standing issues and I fully second that we need a better memory management INSIDE of DCS. But this is not the right way of doing it. There is no magic key that frees up memory inside of DCS. This magic key only asks Windows to move it out of sight for a while.

[edmuss]

2 hours ago, Special K said:

Don't get me wrong, I appreciate the ideas you guys develop to get rid of long standing issues and I fully second that we need a better memory management INSIDE of DCS. But this is not the right way of doing it. There is no magic key that frees up memory inside of DCS. This magic key only asks Windows to move it out of sight for a while.

100% agreed, it's only a temporary sticking plaster to mask the issue; the memory usage is the memory usage.  However in VR there is a specific scenario that makes it uplayable and as I mentioned a few posts back is identical to the VRAM allocation preventing the compositor from operating correctly.

What I experienced last night whilst doing some testing with other settings: -

Mi24p Syria weapons range instant action.
Load to cockpit and VRAM usage jumps immediately to 9.5GB and I'm suffering from the overflow issues described in this thread (spikes in CPU/GPU frametimes graphs and FPS all over the place, zero smooth head movement).
F10 to map, VRAM usage remains at 9.5GB.
Alt tab for a few seconds and VRAM flushes down to 2.5GB, alt tab back in.
F1 to cockpit, VRAM usage jumps up to 5GB.
Perfectly smooth FPS and frametime lines, perfectly smooth head movement and able to fly normally.

Yes the issue is exacerbated by low VRAM, I only have 12GB, but if usage within DCS stays below 7GB generally I don't suffer the problems outlined in this thread.

Please can it be tested with a reduced budget?  My budget is set at 11.3GB only leaving 700MB till overflow, if I'm only using 5-6GB VRAM then I'm more than happy for the budget to be set at 10GB for example.  I can't tell you the actual amount required above the DCS budget to allow the VR compositor to run unfortunately but a series of trials/testing should be able to nail it down pretty quickly

Edited November 10, 2023 by edmuss

[Special K]

vor 32 Minuten schrieb edmuss:

100% agreed, it's only a temporary sticking plaster to mask the issue; the memory usage is the memory usage.  However in VR there is a specific scenario that makes it uplayable and as I mentioned a few posts back is identical to the VRAM allocation preventing the compositor from operating correctly.

What I experienced last night whilst doing some testing with other settings: -

Mi24p Syria weapons range instant action.
Load to cockpit and VRAM usage jumps immediately to 9.5GB and I'm suffering from the overflow issues described in this thread (spikes in CPU/GPU frametimes graphs and FPS all over the place, zero smooth head movement).
F10 to map, VRAM usage remains at 9.5GB.
Alt tab for a few seconds and VRAM flushes down to 2.5GB, alt tab back in.
F1 to cockpit, VRAM usage jumps up to 5GB.
Perfectly smooth FPS and frametime lines, perfectly smooth head movement and able to fly normally.

Yes the issue is exacerbated by low VRAM, I only have 12GB, but if usage within DCS stays below 7GB generally I don't suffer the problems outlined in this thread.

Please can it be tested with a reduced budget?  My budget is set at 11.3GB only leaving 700MB till overflow, if I'm only using 5-6GB VRAM then I'm more than happy for the budget to be set at 10GB for example.  I can't tell you the actual amount required above the DCS budget to allow the VR compositor to run unfortunately but a series of trials/testing should be able to nail it down pretty quickly

 

Happy to focus on experiences and stuff that eats up memory and work on that. I am also happy to report these kind of things and bring it to the right place.

Can't guarantee for any fix / implementation though. Some things sound easy but are in fact not, some might be but will be killed by priorities. But I am happy to support that fight as I fully agree that it is a disadvantage for DCS itself. People want to play and not everyone has a beast of a machine at home.

[edmuss]

Happy to try to help out with specific testing if required

Fully appreciate that it will not be as easy to implement as it is to type, if this can be looked at though I reckon that it will potentially solve one of the longest running issues in DCS VR - it's been in existence for at least 3 years to the best of my knowledge.

Can anyone replicate this issue with WMR in 2.9?  I suspect that the fix instigated by mbucchia that locked the compositor VRAM will also negate the problems experienced here; if that's the case then it's a very quick and easy elimination.

edit: @Special K a few people have tested this in WMR without suffering from the performance tanking but still running at 75-90% of VRAM budget. This just reinforces my theory about the overallocation of VRAM as the WMR openxr runtime has had a portion of the VRAM locked exclusively for the VR compositor.

Edited November 10, 2023 by edmuss

[Dogmanbird]

I have a couple of PC's with almost identical hardware except for the video cards. Just wanted to share that when I'm switching between f1 & f10 views (This applies to multithreaded mode - single player or on a multiplayer server);

- rtx3080 and Reverb G2 switches instantly/smoothly with no hiccups at all. When using the quest 3 / pro it will often stutter when returning to f1 view, but will generally recover / return to normal performance  1 to 10 seconds later.

- With rtx 4090 and Reverb G2 it switches instantly/smoothly with no hiccups at all.  With Quest 3 / pro, there can be a 1/2 to 2 second pause when returning to f1 view, and then the game returns to normal performance. There is no perceivable fps drop, just a pause. The pause is usually longest the first time I switch f1/f10 after starting a flight.

 

[Nealius]

With my Quest 2 and 3060 I had this happen once when flying at night, however during the day I have no real hiccups or tearing, just an overexposed image for about a minute until the lighting settles down to normal.

[seven10]

16 hours ago, edmuss said:

Can anyone replicate this issue with WMR in 2.9?  I suspect that the fix instigated by mbucchia that locked the compositor VRAM will also negate the problems experienced here; if that's the case then it's a very quick and easy elimination.

edit: @Special K a few people have tested this in WMR without suffering from the performance tanking but still running at 75-90% of VRAM budget. This just reinforces my theory about the overallocation of VRAM as the WMR openxr runtime has had a portion of the VRAM locked exclusively for the VR compositor.

 

Hmm now that you mention that, I never saw this issue with my G2 and WMR while using openxr and the openxr toolkit. It has only been since switching over to the Quest Pro that this issue has cropped up for me as well even though my GPU has 16GB of VRAM. Once I'm back I can test 2.9 on my old setup since my brother has it.

[edmuss]

6 hours ago, Nealius said:

With my Quest 2 and 3060 I had this happen once when flying at night, however during the day I have no real hiccups or tearing, just an overexposed image for about a minute until the lighting settles down to normal.

You may not utilising enough of your VRAM budget to push it into overflow, you need to look at the usage/budget values in the expanded performance metrics. Increase your settings until you're consistently using 75-90% of the budget and then see if it happens. Because of the narrow bandwidth of the 3060 this will likely mean that FPS will have dropped a fair amount.

[Nealius]

3 hours ago, edmuss said:

You may not utilising enough of your VRAM budget to push it into overflow, you need to look at the usage/budget values in the expanded performance metrics. Increase your settings until you're consistently using 75-90% of the budget and then see if it happens. Because of the narrow bandwidth of the 3060 this will likely mean that FPS will have dropped a fair amount.

In my experience on both the 3060 and 2070 VRAM overlow doesn't affect FPS on the Quest 2, but it does cause a white bar to appear in the display and start artifacting.

[Avii]

I'm using the HTC Vive (1st gen) with an RTX 3070 and the frame drops from F10 back to F1 on MT happen a lot.

[desolunatic]

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

Edited November 11, 2023 by desolunatic

[edmuss]

I'll give it a go later and see if it makes any difference

[Recluse]

Interesting. I don't have that setting

 

nullI have to say, however, that I haven't had this issue since turning off MSAA pre-2.9 Still do get occasional FPS drops and VRAM overflows but doesn't seem as correlated to F10 map as it once was. 

[edmuss]

MSAA takes up VRAM, by turning it off you may have moved yourself slightly further below the threshold for overflow.

The F10 map isn't the root cause of the stuttering, it's just that sometimes switching to the F10 map appears to perhaps create a memory hole which causes the overflow.

From my further testing I've correlated it to VRAM overallocation