Is DCS VR somehow violating Steam VR API rules?

[RealDCSpilot]

Actually this issue is bugging me since years and over several generations of different VR HMDs i had. Only if i didn't had to use SteamVR (like Virtual Desktop over VDXR on a Pico 4 (later Ultra)) it wasn't occuring.
It's always the same behaviour, after a certain amount of time, i can't call up the Steam VR dashboard anymore without getting it to freeze or becoming extremely unstable or eventually crash. Strange thing is, DCS is still running fine in the background, so whenever i can manage to switch back to DCS, it's running fluid VR again as if nothing happened. The thing is, no other VR game shows this issue ever! Even the other big flight sim.
My suspect at the moment is only the excessive use of VRAM that DCS is infamous for. It might interfere heavily with SteamVR's own ressource management for dashboard functionalities (access to Windows desktop etc).

I would like to ask a pro like @mbucchia Can you shed some light on this?

Edited February 26 by RealDCSpilot

[mbucchia]

Hey,

I don't have a clear answer for you. You also say when "using SteamVR" or "violating SteamVR API" which is ambiguous since you could mean via OpenVR or OpenXR.

I haven't looked specifically at this problem, especially since TBH, I never use SteamVR and nearly all my solutions were dedicated to "skipping SteamVR"

That said, based on what you are describing, I believe you are likely correct:

On 2/25/2025 at 10:40 PM, RealDCSpilot said:

My suspect at the moment is only the excessive use of VRAM that DCS is infamous for. It might interfere heavily with SteamVR's own ressource management for dashboard functionalities (access to Windows desktop etc).

You are likely familiar with the concept of "swap file" which is a way to relieve your main RAM by temporarily moving resources to your storage drive. There is a similar concept for GPU memory (VRAM), called residency. Your GPU needs resources (textures, geometry, shaders...) to be in the VRAM in order to use them for rendering. But sometimes your GPU driver will move some resources out of VRAM and into your system RAM if the application is "over-committing" (which means using more memory than the allowable budget). Then when the GPU needs a resource that was "demoted" to system RAM, it will have to first make room for the resource (by demoting another resource) and then copy it back into the VRAM (aka "swapping", like your "swap file" for system RAM) . This process is slow. In some worst case scenarios, a resource might "bounce" back and forth between GPU and system RAM, and this creates an awful effect where your app is rendering like 1 FPS .

I've seen this exact issue with No Man's Sky on PCVR, where the frame time would jump to 100-140ms because some of the VR compositor resources would get demoted to system RAM. There is a solution to such problem, which is to mark the most critical resources as permanently resident in VRAM (explained on the page I linked), to avoid them being demoted. This was actually a mitigation I had implemented in SteamVR for WMR.

Note that as explained on the page I linked about residency, there is something called the application VRAM budget. That is the maximum that an application should ever use. This amount of budget is NOT your entire VRAM. There's something called system reservation, which is Windows protecting some of the VRAM for things like the desktop window manager, and your monitor's backbuffers. Many people asked me this question about OpenXR Toolkit, "why is your overlay saying I have 10GB of VRAM while my GPU has 12GB!?". The answer is those 2GB are the system reservation. If the application ever goes above the application VRAM budget and into the system reservation, bad things happen as described above.

Now the case of VR and memory management is actually quite complex. This is for a simple reason. When you develop an app that runs on flat screen, you don't have to worry about anything other than the system reservation. Your application has its GPU resources (textures etc) and loads them into VRAM, and the only additional overhead is what's called the DXGI swapchain, aka the surface that the application uses to present the rendered image to the monitor. That DXGI swapchain is allocated within the applications's memory budget, so it's easy to account for. When you develop an app for VR, there is a lot more happening. You do have those VR swapchains as well, and these also come out of the applications's VRAM budget, and they are much bigger (stereo and triple-buffered). But you also have the entire VR compositor resources as well. These typically live in other processes like whatever "Oculus Service" (Quest Link) or DWM (WMR) or VRServer (SteamVR). These are not part of the application's VRAM budget (since they are allocated out of nowhere by another application process). So it becomes much harder for an application to track these additional resources and to not over-commit the VRAM. An application will usually try to maximize its use of VRAM especially if you are using very high settings. This means some apps will try to reserve the entirely of the application's memory budget. They will usually do that when starting the game or loading a new level. For games that allow you to switch between flatscreen and VR on the fly (press of a button), this is also a very complex scenario. MSFS got it wrong for a very long time. Basically you have to "unreserve" sufficient memory back for the VR compositor. And again, as an application, you do not know how much VRAM the VR compositor needs...

Then you have SteamVR overlays coming in. These are the absolute nightmare for your game developer conscious about maximizing VRAM usage. These overlays can be loaded AFTER your game started and reserved memory. Or something the full extent of their resources is only allocated upon first use, or specific use (eg: which "menu" you select within your overlay). So if a game had reserved all the VRAM, you are now over-committing VRAM, and risking the back and forth copy of data between system RAM and VRAM.

Now you have a way of checking if this is what's happening, through the Task Manager. You'll see two numbers in your GPU performance pane. A "GPU Memory" and a "Shared GPU Memory". Assuming you are not on an integrated GPU (!), you will see "GPU Memory" as your VRAM, and "Shared GPU Memory" as your system RAM, which can be used when over-committing. In the ideal case, "Shared GPU Memory" should be 0, though in reality there is always a small residual. You want to get your baseline before starting your game. How much "Shared GPU Memory" is used? On my machine, it's always something like 0.1GB or 0.2GB. That's HEALTHY. Then run your game, hopefully "Shared GPU Memory" remains the same value. Then when you are hitting your overlay issue, take a look at "Shared GPU Memory" again. Is it higher than your baseline by a notable difference? For example, on my machine, I see it go above 0.3GB when overcommitting, and it's usually noticeable like 0.5GB or 1GB or more... That's over-committing, and that's what causes bad performance. 

There is no real solution for you to this problem. It's just poor programming, but technically, it's not anybody's fault. DCS shouldn't under-use VRAM just to allow overlays that maybe nobody will use. Your overlay needs resources, and it can't do anything to evict data from DCS. There is no good solution.

One thing your overlay developer could do, is temporarily boost the residency priority of its resources when the overlay is open. That will still cause a slow down when you first open the overlay, but at least the overlay should be more responsive. Now DCS in the background will probably appear less fluid, since now resources used by DCS will need to be copied back and forth between VRAM. Then the overlay must restore the lower residency priority when you close the overlay. I don't think many applications do that, the API for that is not known by many programmers, and also as noted in the API's documentation: "Changing the priorities of resources should be done carefully. The wrong eviction priorities could be a detriment to performance rather than an improvement.". It's a loaded gun that shouldn't be put into the wrong developer's hands :(

[RealDCSpilot]

@mbucchia Thanks for taking the time to answer. I will take a closer look at what is happening with shared memory over time. However, i really hope ED is getting it right with the switch to Vulkan and implements better memory management. It's unbelievable how bad DCS is in this regard in the year 2025.

[RealDCSpilot]

Alright, now i've seen it in action. It really is the Shared GPU Memory. Without DCS and/or SteamVR running it's about 0.1 GB usage. Having DCS running over SteamVR it's slightly increased at 0.2-0.3 GB. But eventually there comes a moment when all goes bonkers and this value goes up to 0.7 GB. Then it needs around 30 seconds or up to a minute to settle itself and everything might come back to normal. This really never happens with any other VR app or game or i never reached this point with another game than DCS. :(

[RealDCSpilot]

Okay, after some testing i may have found the antidote for this particular problem. As soon as DCS framerate is crashing down and SteamVR's performance graph only shows purple all over - do this: take off the HMD. As soon as the HMD's user presence sensor is triggered all will settle itself again. This seems to be by far the fastest method to get back in the game again. Sadly there is nothing to prevent this at all, it will happen sooner or later. But at least there is something that doesn't need the game or the whole system to be restarted. I hope the switch to Vulkan will lead to better memory management in DCS.

Edited March 18 by RealDCSpilot