DCS VR Performance Optimization

[Ready]

7 minutes ago, ChariotOfFLAME said:

A long time ago, I switched to using a sabrent powered USB hub that lets you power each port individually and plugging all non-essential USB devices into that instead of the MOBO, then only turning on what I need when I need it.
 

I went from having tons of disconnects and big stutters to much more clear and clean with few to no disconnects in 1 purchase.

Yes I have a Sabrent powered hub too. Fantastic device. I think it is a 10 port or something like that and completely full, like the back of my pc, all full. Will definitely dig into what is connected where and see what I can reshuffle. 

[Ready]

HAGS ON, HAGS OFF

I sometimes see recommendations that I should disable HAGS. In my case before it brought me better VR performance when I kept it on. 

--

 

On some systems HAGS (“Hardware-Accelerated GPU Scheduling”) can boost VR smoothness.
Let’s look at why that happens, when it’s actually good, and when it’s masking another issue

---

What HAGS really does

Normally, the Windows GPU scheduler (WDDM) queues and manages all GPU workloads in system memory.
With HAGS = ON, those queues move into VRAM, and the GPU handles scheduling directly — reducing CPU overhead and latency.

In simple terms:

	Without HAGS	With HAGS
Who schedules GPU work	Windows kernel	The GPU itself
Latency	Slightly higher	Slightly lower
CPU load	Higher	Lower
Stability (drivers)	Very high	Depends on driver quality

---

Why it can improve VR performance for you

In VR (especially DCS + Varjo + OBS + SRS):

• You’re running multiple GPU clients: Varjo compositor, DCS render threads, NVENC encoder, desktop compositor, etc.

• HAGS can offload scheduling from the CPU → a few ms less latency in the render pipeline.

• That shows up as smoother frame-time graphs and fewer reprojection hitches.

So yes — if you’re seeing clearly better smoothness with HAGS ON, it’s likely a real benefit, not placebo.

---

When HAGS hides deeper problems

HAGS can also paper-over an underlying bottleneck or driver-hang condition:

• Some NVIDIA branches (R560–R570) have occasional NVENC or compositor stalls.
  HAGS may reduce how often they trigger watchdog.sys (GPU timeout), but it doesn’t fix the root cause.

• If your system is marginal on power or thermals, HAGS shortens the Windows TDR watchdog window → less time for recovery → sometimes more BSODs.

So it’s a balancing act:

• If HAGS ON = smoother VR and no stability loss → keep it.

• If you still see watchdog.sys or black-screen recoveries → leave HAGS OFF until driver 566.36 or later (those have better queue management).

---

Recommended approach for your system

1. After you install 566.36 cleanly (via DDU or clean install):

   • Test both HAGS ON and OFF.

   • Watch GPU frametime stability (Varjo Base performance graphs or CapFrameX).

2. If ON gives you:

   • Lower frametime variance,

   • No TDR or VR compositor hangs,
     → keep HAGS ON.

3. If you see occasional freezes or “watchdog” BSODs → turn it OFF; that’s the first indicator the driver branch isn’t coping well with your multi-app load.

---

TL;DR

• HAGS can genuinely help VR smoothness by reducing CPU scheduling delay.

• On older or unstable driver branches it can trigger or mask GPU timeouts.

• With a clean 566.36 install and good latency settings, HAGS ON is often the better choice for Varjo + DCS if it stays stable.

[Ready]

Frametime impact when hitting fps ceiling (and impact of FPS capping) 

In previous tests I never fully understood why my 1% and .02% lows decreased once I was hitting the max of my FPS in DCS. So I ran some tests with RTSS fps capping and got some more information. 

--

So it is expected behavior due to how frame limiting and GPU scheduling interact.

Let’s unpack why your 1% and 0.2% lows actually get worse when you hit the FPS cap (e.g. 90 Hz), and why they look smoother slightly below that (e.g. 86 fps).

---

The core reason: Hitting the FPS cap causes frame pacing stalls

When you set a hard FPS cap (90 fps, matching your headset refresh), the GPU occasionally finishes frames too early.
When that happens:

• The GPU has to wait for the next vsync / frame presentation slot.

• That wait = an idle stall → inconsistent frame timing.

• Those micro-pauses show up as spikes in frametime variance (bad 1% and 0.2% lows).

So even though the average FPS stays perfect (90), the frametime consistency drops — especially visible in the lowest percentile metrics.

---

Why going slightly under (e.g. 86 fps) feels smoother

When you run slightly below the cap:

• The GPU is continuously working, not waiting for the display to catch up.

• There are no forced waits or timing clashes with the vsync cycle.

• Frame delivery becomes more even, resulting in better 1% and 0.2% lows (lower frametime variance).

In VR, this smoother motion pacing is far more perceptually important than the last few frames per second.

---

In DCS VR specifically (Varjo, OpenXR, etc.)

DCS has:

• No frame-time prediction or pre-render smoothing (unlike modern engines).

• A heavy main thread and GPU dependency mismatch.

• A frame cap that interacts badly with OpenXR’s compositor timing when the GPU hits its ceiling.

So when the engine saturates the frame pipeline at exactly 90 fps:

• The compositor sometimes misses or delays a frame sync event,

• …causing periodic frame “jitter” that CapFrameX or FrameView reports as 1% low drops.

---

Analogy

Think of it like driving:
If your car is exactly touching the speed limiter, you’ll constantly “bounce” between acceleration and braking — jittery.
If you cruise just below the limiter, you maintain smooth, steady motion.

---

Best practice for DCS VR

Setting	Recommendation	Why
FPS cap	Use RTSS or OpenXR Toolkit to cap ~4–5 fps below headset refresh	Keeps GPU from hitting limiter stalls
Vsync	Off (let OpenXR or Varjo handle presentation timing)	Prevents driver-level stalls
Frame timing target	11.5 ms @ 86 fps for 90 Hz headset	Leaves headroom for compositor and CPU
GPU load target	~90–95% max	Avoid 100% GPU utilization to maintain consistent frame times

 

Why RTSS frame caps near the headset refresh (88–89 fps @ 90 Hz) can hurt

RTSS (and most external limiters) work by holding back frame submission in the GPU driver before it’s presented.
That’s fine for flat-screen gaming, but DCS + VR + OpenXR adds another layer:

1. OpenXR’s compositor needs a predictable cadence to reproject and time frames.

2. RTSS intercepts and delays frames after DCS but before OpenXR sees them.

3. At 88–89 fps, that delay can desynchronize the compositor timing by a few milliseconds.

4. Result: irregular frame presentation → frametime spikes (even though FPS looks “almost perfect”).

That’s why your 1%/0.2% lows drop sharply when using RTSS at 88–89 fps.

---

Why increasing DCS visual load instead is sometimes better

When you naturally run below 90 fps due to higher graphics load:

• DCS and OpenXR see a continuous, un-capped render cycle.

• No injected wait by RTSS → more natural pacing.

• The GPU runs close to full, but not stalling.

• Frame variance is lower — subjectively smoother, even if the average FPS is a bit lower.

This “organic under-load” behavior gives OpenXR and Varjo’s compositor cleaner, predictable frame intervals.

 

null

Edited November 8 by Ready

[Thomas Barrios]

Hi,

Found your thread here DCS VR Performance Optimization, thanks for sharing all this with the community!.

I have developed personal a suite of scripts for windows and DCS optimization, and automated DCS testing.

Solves that problem on having to manually setting what is known to be good, and manually "change setting --> test --> repeat" process.

https://github.com/thomas-barrios/DCS-Max/blob/master/README.md

Its a draft work, its not polished, and aims to help the community and DCS performance enthusiasts.

Let me know your thoughts on it.

Cheers

Wolf

 

 

 

 

[Ready]

7 hours ago, Thomas Barrios said:

Hi,

Found your thread here DCS VR Performance Optimization, thanks for sharing all this with the community!.

I have developed personal a suite of scripts for windows and DCS optimization, and automated DCS testing.

Solves that problem on having to manually setting what is known to be good, and manually "change setting --> test --> repeat" process.

https://github.com/thomas-barrios/DCS-Max/blob/master/README.md

Its a draft work, its not polished, and aims to help the community and DCS performance enthusiasts.

Let me know your thoughts on it.

Cheers

Wolf

Hey Wolf!

I have looked at some tools before that were doing scripted rig optimizations, but did not continue because I got no clarity on what was happening. I also overdid it a couple of times by blindly trusting stuff that landed me in big trouble. So I am now only testing one setting at a time and log every step of the way because trying out combinations sometimes also is confusing and then I have to roll back to find that one thing that made things better or worse.. I also see that in my rigs configuration some settings are different than popular items, they somehow work better for me. I see you have documented everything well and I like the automated testing. I am at around test #500, will post my recent testing results soon, so automated testing might have saved me some time  .

I will definitely take a good look. I don't know if I will run scripts, but for sure I will check if there are things in your approach that I did not try yet. 

Thanks for sharing all your work. 

Great!!

[Ready]

On 11/17/2025 at 5:46 PM, Thomas Barrios said:

Found your thread here DCS VR Performance Optimization, thanks for sharing all this with the community!. I have developed personal a suite of scripts for windows and DCS optimization, and automated DCS testing. https://github.com/thomas-barrios/DCS-Max/blob/master/README.md Let me know your thoughts on it.

Hi I went through the various items, see below my comments/questions regarding the various documents on your github.

Readme.md

• System Restore: it is not very stable for me and I have disabled it completely, also recommended by some.
• Backup: I am using Macrium Reflect for making daily backups, which works like a charm.
• O&O shutup: I turned off too much before. Will run through it again.
• Nvidia Profile Inspector: I used to change things with the profile inspector but nowadays mainly use NVCP. 

Scripting: It all looks very cool and handy, but I think I will stick to the way I am currently doing my tests. Burned my fingers before with scripts that did not fully work, no offense meant.

Performance testing: i am doing al lot of quick tests, just sitting on the ramp in a stock mission. I am using the A-10 on Marianas in the take-off mission and leave my headset on the desk. For quick tests I am not flying around with large scripts. I do that only after I have come to a configuration where I am pretty happy.

performance-guide.md

• I like the way you have created the layers table. I would make BIOS a separate layer. Add GPU and PSU to the items to optimize in the Rig layer. I am also using quite some mods and peripherals for DCS, would add them somewhere too. Maybe swith VR optimization (I have hardware VR items) and DCS optimization. Also in DCS there are some items you can optimize while in game that make a big impact, like trees and details.

Registry Optimizations

• I am curious but very cautious with adding keys to the registry. I am going to check the videos you referenced and will circle back later. 

Windows Services

• Somehow the following services were disabled before but enabled again automatically.  AppX Deployment Service, Asus Update Check, Power Service.

Scheduled Task Optimization

• I see a lot of scheduled tasks under Windows. There might be more there to disable. Things that just cause Windows to do stuff while gaming.
• I removed Dropbox Update scheduler 
• I disabled ProcessMemoryDiagnosticEvents

[Spartan111sqn]

On 11/17/2025 at 5:46 PM, Thomas Barrios said:

Hi,

Found your thread here DCS VR Performance Optimization, thanks for sharing all this with the community!.

I have developed personal a suite of scripts for windows and DCS optimization, and automated DCS testing.

Solves that problem on having to manually setting what is known to be good, and manually "change setting --> test --> repeat" process.

https://github.com/thomas-barrios/DCS-Max/blob/master/README.md

Its a draft work, its not polished, and aims to help the community and DCS performance enthusiasts.

Let me know your thoughts on it.

Cheers

Wolf

 

 

 

 

Nice, and thanks, but very complex to do it. Something more plug and play would be nice.

[Ready]

On 11/17/2025 at 5:46 PM, Thomas Barrios said:

Found your thread here DCS VR Performance Optimization, thanks for sharing all this with the community!. I have developed personal a suite of scripts for windows and DCS optimization, and automated DCS testing. https://github.com/thomas-barrios/DCS-Max/blob/master/README.md Let me know your thoughts on it.

Hi I went through the various items, see below my comments/questions regarding the various documents on your github.

Readme.md

• System Restore: it is not very stable for me and I have disabled it completely, also recommended by some.
• Backup: I am using Macrium Reflect for making daily backups, which works like a charm.
• O&O shutup: I turned off too much before. Will run through it again.
• Nvidia Profile Inspector: I used to change things with the profile inspector but nowadays mainly use NVCP. 

Scripting: It all looks very cool and handy, but I think I will stick to the way I am currently doing my tests. Burned my fingers before with scripts that did not fully work, no offense meant.

Performance testing: i am doing al lot of quick tests, just sitting on the ramp in a stock mission. I am using the A-10 on Marianas in the take-off mission and leave my headset on the desk. For quick tests I am not flying around with large scripts. I do that only after I have come to a configuration where I am pretty happy.

performance-guide.md

• I like the way you have created the layers table. I would make BIOS a separate layer. Add GPU and PSU to the items to optimize in the Rig layer. I am also using quite some mods and peripherals for DCS, would add them somewhere too. Maybe swith VR optimization (I have hardware VR items) and DCS optimization. Also in DCS there are some items you can optimize while in game that make a big impact, like trees and details.

Registry Optimizations

• I am curious but very cautious with adding keys to the registry. I am going to check the videos you referenced and will circle back later. 

Windows Services

• Somehow the following services were disabled before but enabled again automatically.  AppX Deployment Service, Asus Update Check, Power Service.

Scheduled Task Optimization

• I see a lot of scheduled tasks under Windows. There might be more there to disable. Things that just cause Windows to do stuff while gaming.
• I removed Dropbox Update scheduler 
• I disabled ProcessMemoryDiagnosticEvents

[Ready]

crop2fov - OpenXR Toolkit mod

I came across this nifty mod of OpenXR Toolkit by OhneSpeed that lets you crop the pixels that are not visible in the headset -> less to render for the GPU -> performance improvement without visual effects!

I ran it and was able to shave off 10% from the vertical and 5% from the horizontal. I am still tweaking and think I can further reduce a bit in the horizontal. I did not make a calculation of the actual gain, but every little bit helps! I am still using OpenXR Toolkit for visual tweaks, Turbo Mode and overlays. So now I use crop2fov next to Quad Views Foveated. 

https://drive.google.com/drive/folders/1lYT8i393Wnvp9L87ICHWdqkezZpujx2v

Some words of advice (Big thanks to Kelju for getting me started);

• Bring Back OpenXR Toolkit to default settings before installing. 
• Rename the original .dll and put the modded one in its place. 
• Restart the game.
• Open the toolkit as normal and go to the system tab.
• Select fov2crop as the resolution and start changing the percentages.
• Keep looking straight ahead with your eyes.
• Start reducing percentages and use peripheral vision to spot the black borders appearing around the sides of the headset.
  • up  = top side of vertical fov   for both eyes
  • down  = bottom side of vertical fov   for both eyes
  • left/left = left side of left eye, ie. far left of horizontal fov
  • left/right = right side of left eye,ie. stereo overlap for left eye
  • right/left = left side of right eye, ie. stereo overlap for right eye
• The borders are quicker to spot in the peripheral, so keep looking straight ahead with the eyes and quickly move the head back and forth, left and right, up and down.
• Once the black bars are visible, ease off a bit until they are no longer visible.
• Settle and notice the reduction in percentages in the menu. Restart the game for the final result to take effect.
• If using Quad Views while cropping you will see weird visual effects. Just ignore these, they will dissapear once you restarted the game. 

Edited Wednesday at 10:22 PM by Ready

[sleighzy]

58 minutes ago, Ready said:

crop2fov - OpenXR Toolkit mod

I came across this nifty mod of OpenXR Toolkit by OhneSpeed that lets you crop the pixels that are not visible in the headset -> less to render for the GPU -> performance improvement without visual effects!

I ran it and was able to shave off 10% from the vertical and 5% from the horizontal. I am still tweaking and think I can further reduce a bit in the horizontal. I did not make a calculation of the actual gain, but every little bit helps! I am still using OpenXR Toolkit for visual tweaks, Turbo Mode and overlays. So now I use crop2fov next to Quad Views Foveated. 

https://drive.google.com/drive/folders/1lYT8i393Wnvp9L87ICHWdqkezZpujx2v

Some words of advice (Big thanks to Kelju for getting me started);

• Bring Back OpenXR Toolkit to default settings before installing. 
• Rename the original .dll and put the modded one in its place. 
• Restart the game.
• Open the toolkit as normal and go to the system tab.
• Select fov2crop as the resolution and start changing the percentages.
• Keep looking straight ahead with your eyes.
• Start reducing percentages and use peripheral vision to spot the black borders appearing around the sides of the headset.
  • up  = top side of vertical fov   for both eyes
  • down  = bottom side of vertical fov   for both eyes
  • left/left = left side of left eye, ie. far left of horizontal fov
  • left/right = right side of left eye,ie. stereo overlap for left eye
  • right/left = left side of right eye, ie. stereo overlap for right eye
• The borders are quicker to spot in the peripheral, so keep looking straight ahead with the eyes and quickly move the head back and forth, left and right, up and down.
• Once the black bars are visible, ease off a bit until they are no longer visible.
• Settle and notice the reduction in percentages in the menu. Restart the game for the final result to take effect.
• If using Quad Views while cropping you will see weird visual effects. Just ignore these, they will dissapear once you restarted the game. 

 

Couple of follow-ups.

• PimaxPlay Quad Views is incompatible with OpenXR Toolkit so would need to switch to Quad-Views-Foveated if wanting to still use this.
• Ordering of OpenXR API layers is important. IIRC installing Quad Views after the toolkit figures things out, if your VR doesn't work properly then use the https://github.com/fredemmott/OpenXR-API-Layers-GUI tool to reorder the layers.

[Ready]

1 hour ago, sleighzy said:

Couple of follow-ups.

• PimaxPlay Quad Views is incompatible with OpenXR Toolkit so would need to switch to Quad-Views-Foveated if wanting to still use this.
• Ordering of OpenXR API layers is important. IIRC installing Quad Views after the toolkit figures things out, if your VR doesn't work properly then use the https://github.com/fredemmott/OpenXR-API-Layers-GUI tool to reorder the layers.

Thanks for the additions

[speed-of-heat]

9 hours ago, Ready said:

crop2fov - OpenXR Toolkit mod

I came across this nifty mod of OpenXR Toolkit by OhneSpeed that lets you crop the pixels that are not visible in the headset -> less to render for the GPU -> performance improvement without visual effects!

I ran it and was able to shave off 10% from the vertical and 5% from the horizontal. I am still tweaking and think I can further reduce a bit in the horizontal. I did not make a calculation of the actual gain, but every little bit helps! I am still using OpenXR Toolkit for visual tweaks, Turbo Mode and overlays. So now I use crop2fov next to Quad Views Foveated. 

https://drive.google.com/drive/folders/1lYT8i393Wnvp9L87ICHWdqkezZpujx2v

Some words of advice (Big thanks to Kelju for getting me started);

• Bring Back OpenXR Toolkit to default settings before installing. 
• Rename the original .dll and put the modded one in its place. 
• Restart the game.
• Open the toolkit as normal and go to the system tab.
• Select fov2crop as the resolution and start changing the percentages.
• Keep looking straight ahead with your eyes.
• Start reducing percentages and use peripheral vision to spot the black borders appearing around the sides of the headset.
  • up  = top side of vertical fov   for both eyes
  • down  = bottom side of vertical fov   for both eyes
  • left/left = left side of left eye, ie. far left of horizontal fov
  • left/right = right side of left eye,ie. stereo overlap for left eye
  • right/left = left side of right eye, ie. stereo overlap for right eye
• The borders are quicker to spot in the peripheral, so keep looking straight ahead with the eyes and quickly move the head back and forth, left and right, up and down.
• Once the black bars are visible, ease off a bit until they are no longer visible.
• Settle and notice the reduction in percentages in the menu. Restart the game for the final result to take effect.
• If using Quad Views while cropping you will see weird visual effects. Just ignore these, they will dissapear once you restarted the game. 

Does this work with Varjo Foveated?

[sleighzy]

2 hours ago, speed-of-heat said:

Does this work with Varjo Foveated?

If you’re referring to Mbucchia’s Varjo Foveated then as per the Wiki OpenXR Toolkit is not compatible with that. I believe the same is also true of Varjo Base with Quad Views enabled (same problem as the PimaxPlay one). OpenXR Toolkit requires it to receive 2 views and not 4. This is why it works with Quad-Views-Foveated as that converts the 4 views back into the stereo 2. This is also why the order of the API layers is important so that this process occurs before it reaches the OpenXR Toolkit.

….anyway, sorry, didn’t mean to sidetrack Ready’s awesome posts

Edited Thursday at 10:16 AM by sleighzy

[Ready]

58 minutes ago, sleighzy said:

If you’re referring to Mbucchia’s Varjo Foveated then as per the Wiki OpenXR Toolkit is not compatible with that. I believe the same is also true of Varjo Base with Quad Views enabled (same problem as the PimaxPlay one). OpenXR Toolkit requires it to receive 2 views and not 4. This is why it works with Quad-Views-Foveated as that converts the 4 views back into the stereo 2. This is also why the order of the API layers is important so that this process occurs before it reaches the OpenXR Toolkit.

….anyway, sorry, didn’t mean to sidetrack Ready’s awesome posts

 

 

No worries this is what I am running

Edited Thursday at 11:12 AM by Ready