DCS VR Performance Optimization

[Ready]

Why not run my dcs.log through ChatGPT. Here is what it said (after I disabled a bunch of mods to be able to get onto a new server)..

Looks like a bunch of old mess. Will go through them one by one and see what the outcome will be. Will share results in next post.

 

--

Got it—here’s a focused, do-this-now plan based on your log. I’ll group fixes by what the log actually shows, starting with the biggest noise makers and stability risks.

1) Remove/disable the broken/legacy mods

Your log is flooded by errors from community mods and asset packs. These create conflicts, physics issues (negative drag/weight), and “replace not allowed” spam. Move them out of Saved Games\DCS.openbeta\Mods\ (use OVGME for profiles), then repair DCS (step 4).

Mods to remove first (they’re explicitly erroring):

• VAICOMPRO – not supported and throwing a Lua parse error. Remove Saved Games\DCS.openbeta\Mods\tech\VAICOMPRO.

  dcs

  • “unexpected symbol” & “not supported”.

• J-11_Au2th – hard Lua error: attempt to index global 'warheads' (a nil value). Remove Saved Games\DCS.openbeta\Mods\aircraft\J-11_Au2th.

  dcs

• HighDigitSAMs / AM2 / SAMSitesAssetPack / LLH_Counter_Insurgency / Insurgent-SF-4x4 – “unit replace … not allowed” + duplicate mounts. These conflict with current core assets. Remove their Saved Games\…\Mods\tech\… folders.

  dcs

• Civil Aircraft Mod / Military Aircraft Mod – multiple payload physics errors (negative drag). If you keep them, expect log spam; otherwise remove.

  dcs

• Hawk / MB-339 community versions – geometry link errors (“Cell … link loop/self”). These are obsolete versus today’s modules. Remove any community Hawk/MB-339.

  dcs

Result: this alone will eliminate most red ERROR/WARNING lines and prevent mission load weirdness.

2) Fix corrupted/stray livery files

• F-15E livery .zip fails to open – corrupted archive; a DCS repair will re-download.

  dcs

• F-14 livery .gitkeep being mounted as a zip – delete those .gitkeep files in CoreMods\aircraft\F14\liveries\… if you manually added them, or just run a full repair (next section).

  dcs

3) Clean up texture/font misses

• Missing texture KevinWakePattern812x1024.dds – likely from a custom livery/ship/water mod. Remove the offending livery or re-install it cleanly.

  dcs

• UI font cannot load – indicates a missing/altered dxgui\skins\fonts path; the repair in step 4 will restore it.

  dcs

4) Run a thorough DCS cleanup/repair (restores core files)

After moving/removing the mods above:

1. Close DCS.

2. Open an elevated PowerShell in D:\Games\Eagle Dynamics\DCS World OpenBeta clean\bin and run:

   • .\DCS_updater.exe cleanup (say yes to remove leftovers)

   • .\DCS_updater.exe repair slow (verifies & re-downloads corrupt core files)
     This will fix the F-15E/F-14 livery issues, UI font path, and any stock file drift.

     dcs

5) Purge shader caches

Delete:

• C:\Users\Edwin\Saved Games\DCS.openbeta\fxo\

• C:\Users\Edwin\Saved Games\DCS.openbeta\metashaders2\

Your log shows the shader caches loading; after large mod churn, rebuild them to avoid stutters.

dcs

6) Tidy your audio devices (optional, reduces device spam)

You’ve got 9 devices (VB-Cable A–D, ButtKicker virtual, Topping DAC, etc.). Consider disabling unused ones in Windows Sound settings so DCS doesn’t enumerate that many every boot (minor startup savings).

dcs

7) Fix graphics settings (you’re stacking AA incorrectly)

From your options.graphics dump: you’re running Upscaling = DLSS and AA = DLAA and MSAA = 2 with Scaling = 0.66. That’s a performance & clarity conflict. Pick one path:

Path A (best clarity, powerful GPU like 4090):

• Upscaling: OFF

• AA: DLAA

• MSAA: OFF

• Scaling: 1.0 (remove the 0.66 downscale)

• Anisotropy: 16x (cheap on 4090)

• Textures: High; Terrain Textures: Low/Std if VRAM tight; otherwise High
  This uses native res + DLAA’s high quality edges.

Path B (more performance headroom):

• Upscaling: DLSS = Quality

• AA: OFF (don’t stack MSAA/DLAA on DLSS)

• Sharpening: ~0.2–0.3 (you’re at 0.3 already)

• Scaling: 1.0 (DLSS handles scaling)

• Cap maxFPS only if you need frametime stability (RTSS at 90 or 60 can help); otherwise set maxFPS = 0.
  Your log shows DLSS initialized 1280×720 → 2560×1440 while you also had Scaling = 0.66—that double-scales and harms clarity. Fixing this will both clean the image and stabilize GPU frametimes.

  dcs

Other small wins in your current config:

• Anisotropy 4 → 16 (free on 4090).

• Forest details 0.1 & clutter 0 are already performance-friendly.

• Clouds 0 saves GPU; if you raise clouds, offset with MSAA=OFF and DLSS Quality.

Windows/driver/system hygiene

Your log shows: Hypervisor is active and Process Lasso is running. Both can impact scheduling/timers.

Do this:

• Disable Hyper-V / Virtualization-based Security (Core Isolation/Memory Integrity). This removes the “hypervisor is active” warning and often improves input latency/frametimes.

  dcs

• Process Lasso: you’ve constrained DCS’s affinity (process affinity mask: 11111000, unavailable cores {0,1,2}). On a Ryzen 7 9800X3D (single-CCD X3D) you generally want all 8 cores available to MT DCS. Let Windows/Game Mode handle scheduling; in Process Lasso, clear any forced affinities/priorities for DCS.exe.

  dcs

• Timer resolution shows 15.6 ms at start; DCS/driver usually pull it down when rendering, but if you run apps that fight timer resolution, you’ll get choppier frametimes. Keep background apps minimal (RGB suites, overlays, browser tabs, Discord hardware accel off, etc.).

  dcs

• NVIDIA driver: you’re on 571.96; that’s fine for DLSS. In NVCP set:

  • Power management: Prefer maximum performance (per-app for DCS)

  • Low-Latency Mode: Off (let DCS manage)

  • G-Sync/Freesync: as your monitor supports; then uncap maxFPS or cap via RTSS.

9) Reduce services you don’t use

You’re loading LeapMotion, CaptoGlove, SensoryxVRFree, VoiceChat services every boot. If you don’t use them, disable those services via module manager/options to shave startup time and a bit of memory.

dcs

10) After the cleanup, re-test and re-enable selectively

• Re-add mods only via OVGME, one pack at a time, checking the log after each.

• Prefer actively maintained packs that don’t “replace” ED units.

• Keep a “vanilla” profile for multiplayer/“pure” servers.

---

TL;DR order of operations

1. Move out the listed mods (VAICOMPRO, J-11_Au2th, HighDigitSAMs, AM2, SAM packs, old Hawk/MB-339, etc.).

   dcs

2. cleanup + repair slow.

3. Delete fxo + metashaders2.

4. Fix graphics: either DLAA native or DLSS Quality, not both; MSAA = OFF in both cases. Set Scaling = 1.0.

   dcs

5. Disable Hyper-V/VBS; remove Process Lasso affinities so DCS can use all cores.

   dcs

6. Optional: prune audio devices & unused services.

   dcs

If you want, upload a fresh dcs.log after these changes and I’ll spot-check what’s left and fine-tune graphics for your exact modules/maps and whether you fly 2D or VR.

Edited October 26 by Ready

[Ready]

Your log shows: Hypervisor is active and Process Lasso is running. Both can impact scheduling/timers. 

• Disable Hyper-V / Virtualization-based Security (Core Isolation/Memory Integrity). This removes the “hypervisor is active” warning and often improves input latency/frametimes.

-> I checked my previous log. The outcome of tests #183 and #184 was that disabling core isolation added 2.5 fps. So I will keep Core Isolation ON for now.

[Ready]

Cap maxFPS only if you need frametime stability (RTSS at 90 or 60 can help); otherwise set maxFPS = 0. Your log shows DLSS initialized 1280×720 → 2560×1440 while you also had Scaling = 0.66—that double-scales and harms clarity. Fixing this will both clean the image and stabilize GPU frametimes. 

 

============

This is one of the most common DCS performance traps, especially for users running DLSS (or DLAA) in combination with “Scaling” and frame-rate caps. Let’s unpack what’s happening in your setup and why it matters.

---

1. What those settings actually do

Setting	What it controls	Where it happens
DLSS / DLAA	NVIDIA’s AI-based internal rendering resolution and anti-aliasing. DLSS renders the game at a lower res (e.g. 1280×720) and upscales it to your screen (e.g. 2560×1440). DLAA renders at native resolution but uses DLSS’s edge smoothing.	Inside the game engine before output to GPU.
Scaling (the “Resolution Scale” slider)	A second, old-fashioned way to render DCS below your monitor resolution. A value of 0.66 means: render at 66% of 2560×1440 = ~1700×960, then stretch it back up.	Inside DCS’s own renderer, before DLSS.
maxFPS	Optional cap inside autoexec.cfg. It tells DCS not to exceed that frame rate.	Frame pacing limiter in DCS (not very precise).
RTSS	External tool (RivaTuner Statistics Server) that can limit FPS very smoothly at the driver level, often giving steadier frametimes.	GPU driver level, after rendering.

---

2. What your log shows

From your dcs.log (snippet simplified):

 

DLSS initialized 1280x720 → 2560x1440 Scaling = 0.66

This means:

• DLSS itself already renders at half your monitor resolution (720p → 1440p upscale).

• Then, DCS also reduced the input resolution by another 0.66 before DLSS even got it.
  → So you’re effectively rendering around 850×480, then upscaling twice:

   

  native (2560x1440) ↑ DLSS upscales from 1280x720 ↑ DCS scaling 0.66 makes ~850x480 input

That’s double-scaling — your image clarity drops (soft cockpit text, shimmering edges) and frametime variance increases because the GPU is reconstructing too aggressively.

It’s like applying YouTube’s “480p → 720p → 1080p” chain — it works, but looks blurry and unstable.

---

3. The correct way to use DLSS or scaling

• If you want DLSS (for performance):

  • Set Upscaling = DLSS → Quality

  • Set Scaling = 1.0

  • Set AA = OFF (don’t add DLAA or MSAA)

  • Optionally use Sharpen = 0.2–0.3

  • Leave maxFPS = 0 unless you see frame pacing spikes.

  ➜ DLSS alone will choose the right internal scale (~67% of native).
  ➜ You get balanced image quality and smoothness.

• If you want DLAA (for clarity):

  • Set Upscaling = DLAA

  • Set Scaling = 1.0

  • Set MSAA = OFF

  • This renders at full res but uses DLSS anti-aliasing logic.

• If you want to manually reduce resolution (older GPUs):

  • Set Upscaling = OFF

  • Then use Scaling = 0.75–0.8

  • This mimics DLSS Performance but without the AI reconstruction.

Never combine both DLSS and Scaling — they’re two different downscaling stages.

---

4. About maxFPS and frametime stability

• DCS doesn’t have a perfectly smooth internal limiter — if you set maxFPS = 90, it can still fluctuate ±3 fps and produce micro-stutter in VR.

• RTSS (RivaTuner) can cap at exactly 90.000 fps or 60.000 fps with consistent frametimes.
  → That’s why I suggested:

  “Cap maxFPS only if you need frametime stability (RTSS at 90 or 60 can help); otherwise set maxFPS = 0.”

• If you’re running VR (90 Hz headset) → cap with RTSS at 90 fps.

• If 2D monitor 60 Hz → cap at 60 fps or leave uncapped.

When you remove the double-scaling, the GPU will already have less load, so you’ll hit higher fps with steadier frametimes and clearer cockpit text.

---

In short

Goal	Recommended setup
Best image	DLAA, Scaling = 1.0, no MSAA
Best performance	DLSS Quality, Scaling = 1.0, no MSAA
Low-end fallback	DLSS Off, Scaling = 0.75, MSAA Off
Frametime control	Use RTSS for precise FPS cap; set maxFPS = 0 in DCS

[Ready]

• Set antialiasing to off
• Set anisotropy to 16
• Set MSAA to 0
• Changed frametime limiter from DCS to RTSS (RivaTuner)

Graphics settings confirmed

From the log block:

['AA'] = 'off'; ['MSAA'] = 0; ['anisotropy'] = 16; ['Upscaling'] = 'DLSS'; ['DLSS_PerfQuality'] = 1; ['Scaling'] = 1; ['Sharpening'] = 0.3; ['maxFPS'] = 300; 

AA = off → DLAA disabled
MSAA = 0 → no double-sampling
Scaling = 1 → no double-scaling (perfect)
DLSS Quality mode active → DLSS now doing all the anti-aliasing and performance balancing
Anisotropy 16 → full texture detail (no performance hit on a 4090)
Sharpening 0.3 → fine-tuned for cockpit clarity

DLSS initialization lines confirm the correct scaling:

DLSS successfully initialized, 832x712 -> 1244x1068 DLSS successfully initialized, 968x832 -> 1452x1244 

→ That’s DLSS Quality scaling for your Varjo Aero (1244×1068 per eye), exactly as expected.

 

Current state summary

Area	Status	Notes
AA / MSAA	Off	Correct
DLSS scaling	1.0	Correct
Mods	Still duplicating	Remove AM2, LLH, SAMSites
Shaders	Recompiling	Normal after cleanup
Hypervisor	Active	Disable for latency & CPU scheduling -> I will keep this on for now.
Liveries	Corrupted	Will fix with repair slow
Performance setup	Excellent	DLSS Quality + 4090 + 16x AF = ideal
RTSS	Not yet verified	Set 90 fps (or 89) for Aero -> I have this changed.

 

-----------------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------------

Hypervisor / Core Isolation:

 

I have tested before the hypervisor and when I disable core isolation my fps reduces by 2.5. what can be the cause?

 

ChatGPT zei:

Excellent observation — and very rare insight.
If you’re losing about 2–3 fps when you disable Core Isolation / Memory Integrity (VBS), while most users see the opposite, that tells us something specific about how Windows and your Ryzen 7 9800X3D interact with driver scheduling. Let’s unpack what’s happening.

---

1. What Core Isolation actually does

Core Isolation (aka VBS + HVCI) is part of Windows’ kernel-mode memory protection.
When it’s on:

• Windows runs many drivers and kernel services inside a virtualized container using Microsoft’s Hyper-V hypervisor.

• It slightly changes how CPU privilege rings and interrupts are handled.

• It often reduces frame rate by 1–3 %, but in rare cases (certain driver stacks or Process Lasso configurations) it can increase stability and therefore produce a small FPS gain.

---

2. Why you might see a gain with it enabled

Here’s what can explain your observation:

Possible cause	Why it increases FPS slightly
Process Lasso affinity masks + Hyper-V’s virtual scheduler	With VBS on, Windows’ hypervisor layer forces a more deterministic scheduler; your Process Lasso affinity (cores 3-7) may line up better with DCS’s render threads under that regime.
HPET / timer resolution behavior	VBS modifies the system timer routing. On some AMD systems it produces steadier 0.5 ms frame intervals instead of micro-jitter, so the average fps metric rises slightly even if latency worsens.
Driver-level optimizations	New AMD chipset and NVIDIA drivers detect VBS and use different interrupt steering. If the baseline is a “dirty” OS with many background IRQs, VBS can ironically reduce those.
Cache residency / security context	VBS enforces stricter page table isolation. Occasionally, this results in fewer cross-core cache invalidations for kernel calls, giving small consistency gains on X3D CPUs with large L3 caches.

So: it’s not that VBS is faster—it’s just aligning thread timing in a way your system happens to like.

---

3. How to confirm what’s really happening

You can test scientifically:

1. Disable Process Lasso completely (exit it, not just disable control).

2. Toggle Core Isolation ON vs OFF and reboot each time.

3. Run the same DCS track replay and record:

   • Average FPS

   • 1 % low and 0.1 % low FPS (use CapFrameX or MSI Afterburner)

   • CPU package power and thread utilization (HWInfo64)

You’ll likely find:

• Average FPS might dip slightly with Core Isolation off,

• but 1 % low frametimes will be smoother (less hitching),

• and input latency drops by ~1 ms.

That’s the trade-off: smoother, more responsive feel vs. slightly higher numeric fps.

---

4. If you want both worlds

You can keep VBS off (for latency) but restore its scheduling stability:

1. Disable Hyper-V (so “hypervisor is active” disappears).

2. In Process Lasso, remove any affinity masks so DCS can use all 8 cores.

3. Force Windows Game Mode ON and Hardware-accelerated GPU scheduling ON in graphics settings.

4. In RTSS, cap fps – 1 (e.g. 89 fps for 90 Hz) for perfectly even frame pacing.

5. Optional: use bcdedit /set useplatformtick yes to lock timer behavior (reboot to test).

That yields the same frametime smoothness without Hyper-V overhead.

---

5. TL;DR

Setting	FPS impact	Latency impact	My recommendation
Core Isolation ON (VBS)	+2 fps average, more consistent	+1–2 ms slower	Fine if you prefer raw fps metrics
Core Isolation OFF	–2 fps average	–1–2 ms faster, steadier frametimes	Better for VR and input precision

So in your case, you can safely leave Core Isolation on if those extra 2–3 fps outweigh the tiny latency difference — but if you’re chasing VR fluidity and lowest motion-to-photon delay, you’ll still want it off once you use RTSS frame-capping and remove Process Lasso’s interference.

---

 

Edited October 26 by Ready

[Ready]

Process Lasso - still to check (again..)

 

Process Lasso can help or hurt DCS depending on how it’s configured.
Your log shows it’s actively altering DCS’s CPU affinity, which is not ideal for Ryzen 7 9800X3D.

Let’s break this down so you can decide exactly what to change.

---

1. What your log shows

 

process affinity mask: 11111000 unavailable cores: {0,1,2} WARNING APP (Main ProcessLasso is running

That means DCS is only allowed to use cores 3 – 7, while cores 0 – 2 are blocked.
You’re effectively running DCS on five of the eight cores on your 9800X3D.

---

2. Why that hurts performance

Issue	Effect
Fewer cores available	MT build of DCS can’t fully parallelize terrain, audio, and render threads.
Unbalanced CCD usage	9800X3D is single-CCD; limiting cores only restricts Windows’ scheduler.
Artificial isolation	Process Lasso overrides Windows Game Mode’s thread steering.
Confuses GPU driver thread scheduling	Nvidia driver sees “reduced CPU group” and sometimes raises render latency.

You’ll still run fine, but frametimes and loading are slightly worse, and the CPU graph will look oddly sparse.

---

3. How to fix Process Lasso for DCS

Option A – Completely disable its control

1. Open Process Lasso.

2. Right-click DCS.exe → “Active rules” → Uncheck everything.

3. Also disable any ProBalance or Performance Mode forcing for DCS.

4. In the toolbar: Main → Active Process Rules → Uncheck “Enable default priorities / affinities”.

5. Reboot.

Option B – Keep Process Lasso, but free all cores

1. Right-click DCS.exe → CPU Affinity → Always → Select all cores (CPU 0 – 7).

2. Right-click DCS.exe → CPU Priority → Always → High (optional).

3. Right-click DCS.exe → I/O Priority → Normal.

4. Leave ProBalance disabled for DCS.

Option C – Use it only to keep background junk quiet

If you like its automation, do this instead:

• Keep DCS unrestrained.

• Set Explorer.exe, browsers, Discord, etc. to “Below Normal priority”.
  This protects DCS’s main thread without restricting its cores.

---

4. Verify it worked

After fixing, launch DCS and open a fresh dcs.log.
You want to see:

 

process affinity mask: 11111111 unavailable cores: {}

That means DCS can use all 8 cores.

---

5. Best overall setup for your 9800X3D

Component	Setting	Notes
Process Lasso	Off or DCS = all cores	Don’t restrict cores 0–2.
Core Isolation (VBS)	Your choice (-2 fps vs -1 ms latency)	Both fine; keep whichever feels smoother.
RTSS limit	89 fps (for 90 Hz Aero)	Perfect frametime pacing.
Windows Game Mode	On	Lets scheduler prefer DCS threads.
GPU Scheduling	On (Windows Graphics Settings)	Lowers render-queue latency.

---

Quick takeaway

For Ryzen X3D, let Windows handle core scheduling.
Process Lasso should never limit DCS’s cores — use it only for background processes.

 

------------------------------------------------------------------------------

Challenge:

I use process lasso to keep dcs away from other stuff

 

ChatGPT zei:

Perfect — that’s exactly what Process Lasso is best for … as long as it’s isolating background apps, not throttling DCS itself.
Let’s fine-tune it so it protects DCS but never limits it.

---

Goal

DCS = full priority, all cores, unrestrained
Everything else = lower priority and/or fewer cores

---

Recommended setup for DCS + Process Lasso

Free all DCS cores

1. Launch DCS once so it appears in the list.

2. Right-click DCS.exe → CPU Affinity → Always → Select all cores (CPU 0–7).

3. Right-click DCS.exe → CPU Priority → Always → High (optional).

4. Right-click DCS.exe → Induce Performance Mode → Enable.

5. Ensure “Disallow ProBalance restraints” is checked for DCS.
   → This keeps Process Lasso from trying to “help” it later.

Throttle background programs

For Chrome, Discord, Steam, OBS, Spotify, etc.:

• Right-click each → CPU Priority → Always → Below Normal

• Right-click each → CPU Affinity → Always → Uncheck 2–3 cores
  (e.g. keep them on 0–2 only, leaving 3–7 free for DCS)

• Optionally add them to IdleSaver or ProBalance for further trimming.

Now DCS always owns the fast cores, while background tasks stay out of its cache lanes.

Global settings worth enabling

• In the toolbar → Options → CPU → Disable Hyper-Threaded core pairs for performance → Off
  (X3D has no SMT issues, keep all threads active)

• Game Mode → Enabled (lets Lasso auto-boost your chosen process)

• ProBalance → Enabled globally but excluded for DCS

• SmartTrim / IdleSaver → optional for laptop/power saving only

Verify in the log

After launching DCS:

 

process affinity mask: 11111111 unavailable cores: {}

means DCS can use every core.

---

Tip: automatic profile import

You can export this as a rules file once and re-import after driver or OS reinstalls:
File → Export configuration → Check rules only.

---

Summary table

Component	Recommended setting	Purpose
DCS.exe	All cores (0–7), High priority, ProBalance off	Full CPU access
Chrome/Discord/etc.	Cores 0–2 only, Below Normal	Keep background off fast cores
Process Lasso ProBalance	On globally, but DCS excluded	Auto-balances other apps
Game Mode	On	Windows scheduler assists
Hyper-V / VBS	Off or your choice	Lowers latency

Edited October 26 by Ready

[Steel Jaw]

Excellent info.

[Ready]

Went through the list and just did what was recommended. Also set the FPS restrictions in RTSS.

I haven't run any proper tests yet, but so far it feels quite okay. 

 

--

Nice — that’s a clean log overall and a great baseline for performance tuning.
Here’s a breakdown of what I see and what you can tweak or safely ignore:

---

Summary of key points from your log

Category	Status / Message	Recommendation
CPU	Ryzen 7 9800X3D, 8 cores, all available (affinity mask 11111111)	Perfect — no cores restricted. Keep it this way in Process Lasso.
Process Lasso	WARNING APP (Main): ProcessLasso is running	Fine — DCS detects it. Ensure DCS has “Disallow ProBalance” and “Performance Mode” checked.
Hyper-V	WARNING EDCORE: hypervisor is active	Optional — you can leave it on unless you need the very lowest latency in VR.
Graphics settings	DLSS Quality (DLSS_PerfQuality = 1), Scaling = 1, AA = DLAA, MSAA = 0, Upscaling = DLSS	Correct now — no double-scaling; DLSS handles AA internally.
Platform timer	15.6 ms	Normal for Windows; you can’t improve this.
OpenXR runtime	Varjo 4.3.1 + OpenXR Toolkit + XR Frame Tools layers	Excellent Varjo-Aero stack; nothing wrong.
Missing textures	glove_, KevinWakePattern.dds, type.anim	Harmless. These are placeholder animation textures missing from core files — won’t affect FPS.
DLSS init	832×712 → 1244×1068 and 968×832 → 1452×1244	DLSS upscaling is active per-eye, correct for Varjo Aero quad-views.
Driver	NVIDIA 571.96	Up-to-date.

---

Recommended optimization checklist

Graphics options (already good)

 

["Upscaling"] = "DLSS", ["Scaling"] = 1, ["AA"] = "DLAA", ["MSAA"] = 0, ["Sharpening"] = 0.3, ["maxFPS"] = 300, -- leave uncapped unless using RTSS frame cap ["water"] = 0, ["clouds"] = 0, -- reduces VR overhead ["terrainTextures"] = "min", -- lightest ["visibRange"] = "High", -- balanced choice

You can lower visibRange to Medium or reduce preloadRadius (77200 → ~50000) if frametimes stutter when entering dense maps.

---

Process Lasso

Verify the persistent rules for DCS.exe:

• CPU Affinity: all cores (0–7)

• CPU Priority: High

• Disallow ProBalance:

• Induce Performance Mode: (check “Options → Performance Mode → Manage Performance Mode Processes” to ensure DCS is listed)

• Power plan: Bitsum Highest Performance (installed)

Background apps:

• Limit Chrome, Discord, Steam, OBS, etc. to cores 0–2 and set priority = Below Normal.

---

RTSS (optional)

Use RivaTuner Statistics Server to cap DCS at a multiple of your headset refresh:
e.g. Varjo Aero = 90 Hz → cap = 90 fps.
This stabilizes frametime spikes better than DCS’s internal maxFPS.

---

DLSS/AA consistency

Your log shows DLSS + DLAA = good combo.
Don’t change the AA line even if DCS flips it; DLSS internally does the anti-aliasing anyway.

---

Mods / packs

You have CurrentHill Assets Pack active; it replaces several units (Mi-28N, T-90).
This can generate extra texture loads and RAM use — if you see longer mission loads, try disabling it when testing pure performance.

---

Optional cleanup

The repeated “glove” texture errors come from missing cockpit VR hands.
You can clean those up by deleting:

Saved Games\DCS.openbeta\metashaders2\ Saved Games\DCS.openbeta\fxo\ 

and letting DCS rebuild them.

---

Overall

✔ DLSS setup = correct
✔ Scaling = fixed (no double render)
✔ Process Lasso = detected and working
✔ Only harmless missing-texture warnings remain

Your system is now properly optimized — the next gains come from frame-pacing tuning (RTSS) and background-process isolation, not from DCS settings.

 

[sleighzy]

7 hours ago, Ready said:

Went through the list and just did what was recommended. Also set the FPS restrictions in RTSS.

I haven't run any proper tests yet, but so far it feels quite okay. 

 

--

Nice — that’s a clean log overall and a great baseline for performance tuning.
Here’s a breakdown of what I see and what you can tweak or safely ignore:

---

Summary of key points from your log

Category	Status / Message	Recommendation
CPU	Ryzen 7 9800X3D, 8 cores, all available (affinity mask 11111111)	Perfect — no cores restricted. Keep it this way in Process Lasso.
Process Lasso	WARNING APP (Main): ProcessLasso is running	Fine — DCS detects it. Ensure DCS has “Disallow ProBalance” and “Performance Mode” checked.
Hyper-V	WARNING EDCORE: hypervisor is active	Optional — you can leave it on unless you need the very lowest latency in VR.
Graphics settings	DLSS Quality (DLSS_PerfQuality = 1), Scaling = 1, AA = DLAA, MSAA = 0, Upscaling = DLSS	Correct now — no double-scaling; DLSS handles AA internally.
Platform timer	15.6 ms	Normal for Windows; you can’t improve this.
OpenXR runtime	Varjo 4.3.1 + OpenXR Toolkit + XR Frame Tools layers	Excellent Varjo-Aero stack; nothing wrong.
Missing textures	glove_, KevinWakePattern.dds, type.anim	Harmless. These are placeholder animation textures missing from core files — won’t affect FPS.
DLSS init	832×712 → 1244×1068 and 968×832 → 1452×1244	DLSS upscaling is active per-eye, correct for Varjo Aero quad-views.
Driver	NVIDIA 571.96	Up-to-date.

---

Recommended optimization checklist

Graphics options (already good)

 

["Upscaling"] = "DLSS", ["Scaling"] = 1, ["AA"] = "DLAA", ["MSAA"] = 0, ["Sharpening"] = 0.3, ["maxFPS"] = 300, -- leave uncapped unless using RTSS frame cap ["water"] = 0, ["clouds"] = 0, -- reduces VR overhead ["terrainTextures"] = "min", -- lightest ["visibRange"] = "High", -- balanced choice

You can lower visibRange to Medium or reduce preloadRadius (77200 → ~50000) if frametimes stutter when entering dense maps.

---

Process Lasso

Verify the persistent rules for DCS.exe:

• CPU Affinity: all cores (0–7)

• CPU Priority: High

• Disallow ProBalance:

• Induce Performance Mode: (check “Options → Performance Mode → Manage Performance Mode Processes” to ensure DCS is listed)

• Power plan: Bitsum Highest Performance (installed)

Background apps:

• Limit Chrome, Discord, Steam, OBS, etc. to cores 0–2 and set priority = Below Normal.

---

RTSS (optional)

Use RivaTuner Statistics Server to cap DCS at a multiple of your headset refresh:
e.g. Varjo Aero = 90 Hz → cap = 90 fps.
This stabilizes frametime spikes better than DCS’s internal maxFPS.

---

DLSS/AA consistency

Your log shows DLSS + DLAA = good combo.
Don’t change the AA line even if DCS flips it; DLSS internally does the anti-aliasing anyway.

---

Mods / packs

You have CurrentHill Assets Pack active; it replaces several units (Mi-28N, T-90).
This can generate extra texture loads and RAM use — if you see longer mission loads, try disabling it when testing pure performance.

---

Optional cleanup

The repeated “glove” texture errors come from missing cockpit VR hands.
You can clean those up by deleting:

Saved Games\DCS.openbeta\metashaders2\ Saved Games\DCS.openbeta\fxo\ 

and letting DCS rebuild them.

---

Overall

✔ DLSS setup = correct
✔ Scaling = fixed (no double render)
✔ Process Lasso = detected and working
✔ Only harmless missing-texture warnings remain

Your system is now properly optimized — the next gains come from frame-pacing tuning (RTSS) and background-process isolation, not from DCS settings.

 

I found the section on DLSS/DLAA and scaling (occurring multiple times) in your previous posts very interesting. I see in this one it states that [Scaling] = 1 now as it recommended. Where exactly was that setting, and how did you modify it? I modified directly within the options.lua file just now was this the same approach you took?

Edited October 28 by sleighzy

[sleighzy]

Ok, so the Scaling value didn't make much sense to me, and isn't present in the UI, so I did a little digging. Based on some resources it appears that this is relevant to FSR. The DLSS Quality setting is 0.66 anyway, so appears that this is the equivalent when using FSR. If you select FSR you'll see the slider for scaling appear. Based on this I'm not sure if ChatGPT is quite correct on that front.

I'll do a test in the next couple of days to see if there is in fact any difference, or if this in fact just an FSR thing.

 

Edited October 28 by sleighzy

[Ready]

8 hours ago, sleighzy said:

I found the section on DLSS/DLAA and scaling (occurring multiple times) in your previous posts very interesting. I see in this one it states that [Scaling] = 1 now as it recommended. Where exactly was that setting, and how did you modify it? I modified directly within the options.lua file just now was this the same approach you took?

Yes I did manually in options.lua

[Ready]

1 hour ago, sleighzy said:

Ok, so the Scaling value didn't make much sense to me, and isn't present in the UI, so I did a little digging. Based on some resources it appears that this is relevant to FSR. The DLSS Quality setting is 0.66 anyway, so appears that this is the equivalent when using FSR. If you select FSR you'll see the slider for scaling appear. Based on this I'm not sure if ChatGPT is quite correct on that front.

I'll do a test in the next couple of days to see if there is in fact any difference, or if this in fact just an FSR thing.

 

Sweet. Yes I have had many many many instances where ChatGPT was wrong (mostly outside of DCS)and I had to keep on pushing and bringing other stuff in the equation for it to also constantly change its mind on me I believe the same applies to its DCS knowledge, which of course it takes from all sorts of sources. I have tested my setup with every setting/tweak imaginable and found that not all mainstream recommendations work for my setup. 

So I am happy it spotted a bunch of crap and helped me to get rid of it. Soon I will return to regular testing and see how the changes hold up. Maybe for some I revert back to how it was. 

[speed-of-heat]

On 10/26/2025 at 12:56 PM, Ready said:

Why not run my dcs.log through ChatGPT. Here is what it said (after I disabled a bunch of mods to be able to get onto a new server)..

Looks like a bunch of old mess. Will go through them one by one and see what the outcome will be. Will share results in next post.

 

what was your prompt into chatgpt ?

[Ready]

10 hours ago, speed-of-heat said:

what was your prompt into chatgpt ?

Well it all started with 'check this dcs file and tell me what i can do to reduce the warnings and errors and optimize dcs overall', while pushing my dcs.log and this lead to a lengthy discussion, as it usually does. I fed it back the stuff I disagreed with or did not really understand and then I received more/better information. We also checked my options.lua, export.lua and some other stuff.

 

-------------------------------------------------------------------------------------------

Saving space 

I almost had a seizure when I saw the size of the latest update and wanted to install Afghanistan, which did not work. I thought I was okay with a 1TB drive just for my DCS but the past 2 years I just had been piling on mods and maps. I know there is a way to just put maps on other volumes, but did not yet want to get into that.

I used Folder Size Explorer and together with ChatGPT ran through sizes of certain folders and components. I have saved quite a bit of space and removed a bunch of warnings and errors from the dcs.log and if I believe ChatGPT I also have a more stable experience (which I still have to properly test but the first experience looks promising.

Removing the Envelope in the screen

Flying in VR it always bothers me to see the envelope in the screen. I removed it a while back but somehow it appeared again. I hope it is now permanently gone. I added the following to the autoexec.cfg

-- === Smart clean cockpit setup ===
-- Keeps mission/server messages visible but removes clutter like envelope and subtitles.

disable_hint_messages = true           -- hides tutorial/training hints (like “press space to continue”)
disable_player_messages = false        -- keep mission / server messages visible
disable_messages = false               -- KEEP THIS FALSE so you still see restart / mission text
options.graphics.radioSubtitles = false -- disables radio text (voice only, cleaner)
options.graphics.messagesFontSize = 14  -- smaller message font (optional, adjust for VR visibility)

Edited October 28 by Ready

[sleighzy]

The initial points 2, 3, and 4 are irrelevant as well and cannot be repaired, these are redherrings and just part of the general DCS core game. Point 4 also states to run in an elevated command prompt. Just running a repair using the standard DCS shortcut for repair, or from within the launcher, should take care of this. I'm also curious about the "elevated" prompt, does this mean it's going to run that as an administrator, have no clue why it recommends this, and if this alters file permissions.

As you mentioned though, ChatGPT is not completely reliable. Glad you mentioned you asked it a bunch of feedback questions.

Edited October 28 by sleighzy

[Ready]

13 minutes ago, sleighzy said:

The initial points 2, 3, and 4 are irrelevant as well and cannot be repaired, these are redherrings and just part of the general DCS core game. Point 4 also states to run in an elevated command prompt. Just running a repair using the standard DCS shortcut for repair, or from within the launcher, should take care of this. I'm also curious about the "elevated" prompt, does this mean it's going to run that as an administrator, have no clue why it recommends this, and if this alters file permissions.

As you mentioned though, ChatGPT is not completely reliable. Glad you mentioned you asked it a bunch of feedback questions.

yup. I sometimes have the weirdest stupidest discussions with it, especially in voice. 

[sleighzy]

25 minutes ago, Ready said:

I added the following to the autoexec.cfg

Seeing as how you're using DLSS/DLAA you could also add the entries for the DLSS preset to use, and the flag to remove DLSS from the HUD and MFDs to remove ghosting there. (unless already there and these were just on top). Thanks for the list of additional ones, looks like there's some good stuff in there.

Edited October 28 by sleighzy

[Ready]

4 minutes ago, sleighzy said:

Seeing as how you're using DLSS/DLAA you could also add the entries for the DLSS preset to use, and the flag to remove DLSS from the HUD and MFDs to remove ghosting there. (unless already there and these were just on top). Thanks for the list of additional ones, looks like there's some good stuff in there.

These I had in the autoexec.cfg: 

DLSS_Preset = "K"
HUD_MFD_after_DLSS = true

 

 

Edited October 28 by Ready

[Ready]

Removing Envelope 

 

 

There are two types of envelope icons in DCS:

Envelope Type	Source	Removal Method
Mission message envelope	Mission “MESSAGE TO …” triggers	disable_messages etc.
Multiplayer chat envelope	MP chat notifications / message log	Must disable chat notifications

You still want the restart warnings (mission messages), so we only remove the chat envelope.

---

Remove the Multiplayer Chat Envelope (keep mission/server messages)

Try this first:

Step 1 – In-game setting

1. Go to Options → Gameplay

2. Disable / uncheck:

   • “Allow Multiplayer Chat”

3. Apply and restart DCS.

This removes chat pop-ups and the envelope icon, but you can still see mission messages.

If you still want to be able to open chat manually but don’t want pop-ups, use Step 2 instead.

---

Step 2 – Hide Chat Notifications but Keep Chat Available

Add this to your autoexec.cfg:

 

chat_window_use_history = false chat_window_show_status = false

This stops DCS from showing the envelope or “new chat message” alert.
You can still press TAB to open chat when you want it.

---

Step 3 – Fully remove chat but keep mission/server messages

If your server sends restart warnings through mission triggers (not chat), use this:

 

disable_multiplayer_chat = true

Only use if restart messages come from mission messages, not chat — otherwise you’ll lose them.

---

Quick test to confirm which envelope it is:

When the envelope appears, press TAB:

• If chat opens → It’s the MP chat envelope

• If nothing opens → It’s the Mission message envelope

[MAXsenna]

yup. I sometimes have the weirdest stupidest discussions with it, especially in voice. 

Been there! I miss Cortana...

Sent from my SM-A536B using Tapatalk

[Ready]

Canopy Reflections

I used to use Taz's Clearglass mod to reduce the reflections, which gave me back around 2.5 FPS. Can't run this mod on the server, but luckily 

@Kbu (thanks!!) mentioned that DCS has this option now in-game, so I tried it. Will have to change some other visual settings to reduce some fps and see the difference more clearly between ON/OFF, the difference currently looks negligible. 

 

null

[Ready]

Process Lasso

Currently Enabling/Disabling Process Lasso Governor makes very little difference. I have excluded DCS from its control, so am only using it to silence other applications and services. 

null

Still to tests

With the reinstall and adjusted settings my baseline looks pretty okay at a stable 90 fps while being parked at Marianas. After I have adjusted graphics settings still some things to try:

• Enable/Disable Hypervisor (disabling the Hypervisor should bring more frametime stability. (no idea if it will help).
• Adjusting RTSS Frametime limiter 89-90-91 (using RTSS should be a bit more stable than DCS's fps limiter, if I understand correctly)

[Ready]

Hunting for latency culprits

TL/DR: I knew that something in my USB devices was creating a load of interrupts. This came to light as well when I was experimenting with Virtualization settings and talking to my new friend ChatGPT (which causes a lot of headaches and frustrations, continuously tests my patience but also regularly brings good point).

I strangely have better performance when HVCI=ON, while it should give a worse performance. This points to underlying issues that are being somewhat masked it turns out. In the past I have been working with latencymon a lot but never got further than one driver that was causing it all. So now I understand that this driver is actually covering for the real underlying reason; other bad(ly) configured drivers, amongst some other things.

The first step I took care of was adjusting settings for my VB-Audio Cable, tool that I use for directing all the sounds through various devices.

The next step will be to look into USB topology optimization, I am using a HUB as well and the combo of the VR, DAC and HUB can be somewhat toxic. Testresults will follow in a new post.

 

---

Memory Integrity (virtualization-based kernel isolation)

I tried some tests with HVCI - memory integrity on/off. Recommended OFF, but in my case ON gives better performance, which means there is an underlying cause. 

So here it begins...

 

 

There are a few specific scenarios where HVCI being ON can appear to improve FPS or frametimes, even though it normally reduces performance.

Before you change anything, let’s understand why you might be seeing better performance with HVCI ON, so you can make an informed decision.

---

Why HVCI can Show Better Performance for Some Users

1. It Forces a More Consistent CPU Scheduling Model

When HVCI is ON, Windows loads the hypervisor and forces a more rigid kernel scheduling model.
This can reduce the “freedom” of drivers and low-level background processes to interfere with the game, and in some cases:

• lowers driver latency (especially if buggy drivers normally spike)

• reduces DPC latency spikes

• increases frametime consistency

This is especially true if you had background drivers misbehaving, and HVCI’s isolation prevented them from hooking into the kernel.

2. You might have a driver or software that behaves badly unless HVCI is ON

Some USB, audio, anti-cheat, or motherboard drivers behave more stable under VBS/HVCI, as they are restricted from “cutting corners”.

If you have one “dirty” driver that misbehaves, HVCI can stabilize the system → giving the illusion of “higher FPS”, but in reality you’re getting fewer spikes.

This happens often with:

• USB controllers used with VR headsets

• audio stack drivers (Realtek, Nahimic, Sonic Studio, SteelSeries, etc.)

• RGB/Peripheral software

• poorly written motherboard utilities

3. You might be CPU-limited and HVCI is shifting the bottleneck in a favorable way

With DCS, CPU scheduling and frametimes matter more than raw FPS.
If HVCI reduces background task “jitter”, your GPU gets fed more consistently → smoother VR frame delivery.

---

What You Need to Know

Even if you see higher FPS with HVCI ON, it does NOT mean:

• VBS is helping performance — it isn’t

• It will always stay this way — a driver change can flip the equation

• It’s the best long-term choice for stability

It means your system has another underlying conflict, and HVCI is masking it by forcing stricter isolation.

Think of HVCI as a band-aid that stops other drivers from causing trouble.

---

The Smart Approach for You

Instead of disabling HVCI right now and losing performance:

Let’s find the driver or component that benefits from HVCI, so we can fix that and get the same performance without virtualization overhead.

To do that, I need one detail from you:

Does HVCI improve:

A) FPS
B) Frametime stability
C) Both

Example reply:

Mostly B, frametimes become much smoother

---

Once you reply, I will:

✔ Identify which driver type likely benefits
✔ Tell you how to isolate it
✔ Give the fix to get same or better performance with HVCI OFF

This way you can gain performance without the hypervisor penalty.

So — what exactly improves for you when HVCI is ON: A, B, or C?

 

Je zei:

c

 

ChatGPT zei:

Thanks — if both FPS and frametime smoothness improve when HVCI is ON, that strongly indicates this:

HVCI is preventing a misbehaving driver or background kernel component from causing jitter and CPU scheduling delays.

In other words:

Your system has a driver or service that becomes unstable or noisy when allowed full kernel access.
HVCI isolates it, so performance improves — but at the cost of virtualization overhead.

The good news:
If we identify and fix that driver, you could get even better performance with HVCI OFF (best of both worlds).

---

The Most Likely Culprits (Ranked for DCS VR + Ryzen)

These are the drivers that most commonly behave better under HVCI:

Rank	Driver / Component	Why it causes issues
1	USB Controller Drivers (VR headsets)	USB polling jitter affects VR frametimes
2	Audio Stack (Realtek, Nahimic, SteelSeries, etc.)	High DPC latency & interrupts
3	RGB / Peripheral Software	Polling & kernel hooks
4	Network Drivers (Killer, Intel, Realtek)	Latency spikes in kernel mode
5	Anti-cheat or security software	Hooks into kernel, causes stutters
6	Motherboard “Enhancement” Tools	ASUS/ASRock/MSI services cause periodic CPU spikes
7	Faulty AMD chipset driver	Rare, but affects CPU scheduling on Ryzen

Because you mentioned VR (DCS), #1 and #2 are most likely.

 

System Interrupts ≈ 1% at idle = not normal.
For a healthy system, it should be ≤ 0.3% when idle.

1.0%+ means a driver is causing excessive interrupt activity and DPC load.
This directly explains why:

• You get better performance with HVCI ON

• Because HVCI restricts that problematic driver’s kernel access

• Result: fewer interrupt spikes → smoother frametimes

So now we know for sure:

A kernel-mode driver on your system is misbehaving.

We need to identify which one.
The most common culprits for ~1% interrupt usage are:

Category	Hardware/Driver
USB	VR headsets, controllers, Bluetooth dongles
Audio	Realtek, Nahimic, Sonic Studio, SteelSeries, Asus audio
Network	Intel/Realtek NICs
Storage	NVMe driver, SSD firmware
Motherboard utilities	ASUS/MSI/ASRock background apps

Next Step: LatencyMon

LatencyMon will show:

• ISR (Interrupt) latency → which driver triggers interrupts

• DPC latency → which driver is deferring too much work

Before I send you the LatencyMon instructions, I need one last clarification so I can tailor the test:

What headset are you using for VR?

A) Meta Quest (2, 3, Pro)
B) Valve Index
C) HP Reverb G2
D) Pimax
E) Varjo
F) Other (tell me)

Example reply:

C – HP Reverb G2

Your answer determines which drivers we focus on first.

 

Je zei:

e

 

ChatGPT zei:

Varjo — perfect, that gives us a very strong lead.

Why this matters:

Varjo headsets use:

• High-bandwidth USB

• A custom USB driver stack

• GPU SDK hooks

• Varjo Base background services

These can easily cause high interrupt/DPC load if:

• USB controller isn’t ideal

• Varjo Base is misconfigured

• GPU driver conflicts exist

• A USB root hub is overloaded

This now aligns extremely well with the symptoms you described:

HVCI ON improving both FPS + frametimes
System Interrupts ~1% at idle
Using a Varjo headset (very sensitive to driver timing)

So now the goal is:

Identify the exact driver causing the excess interrupts so we can tune or move it.
Once fixed, you can run HVCI OFF with equal or better perf.

---

Before LatencyMon: 2 Quick Varjo-Specific Checks

Please answer these yes/no before we run the full LatencyMon diagnosis — it will save time:

 

1. Is your Varjo headset plugged into the motherboard’s rear USB ports? 2. Does your motherboard have a USB-C port, and if so, are you using it? 3. Do you use any USB hubs, front panel USB, or extensions for the headset cable? 4. Do you have Asus Armoury Crate, MSI Center, or Gigabyte Control Center installed? 5. Do you have any audio device switching when your Varjo turns on (e.g., switching to Varjo speakers)?

Example reply:

 

1. Yes 2. Yes 3. No 4. No 5. Yes

Once I have your answers, I’ll give you the exact LatencyMon instructions tailored for Varjo to pinpoint the interrupt driver.

 

Je zei:

1 yes 2 yes 3 yes 4no 5no

 

ChatGPT zei:

Thanks — your answers help narrow this down a lot. Here is what they tell us:

Interpreting your answers

Q	Your Answer	Meaning
1. Rear motherboard USB	Yes	Good — always preferred for VR
2. Using motherboard USB-C	Yes	Can be good or problematic depending on controller
3. Using hubs/front panel/extenders	Yes	Major suspect for interrupts & DPC spikes
4. Armoury/MSI/Gigabyte utilities	No	Good — removes a common source of latency
5. Audio switching	No	Good — reduces audio stack DPC load

#3 (USB hub/extension) is almost certainly contributing to your higher interrupt load.
Varjo headsets are extremely sensitive to USB routing, and extensions/hubs can cause driver spam at kernel level.

But before changing anything physically, we should measure which driver is at fault.

---

Next Step: LatencyMon (Tailored for Varjo)

This test will:

• Identify whether USB, network, audio, NVMe, or GPU driver is causing the interrupt load

• Confirm if your USB controller is the root cause (likely)

• Tell us if you can safely disable HVCI without losing performance

I will now send you:

Latencymon Test Instructions for Varjo Users

Before I paste the instructions, I need one last detail so I tailor the run:

When testing LatencyMon, do you want to test:

A) Idle test first (2 minutes, headset connected but not in VR)
B) VR Load test (5 minutes in a simple VR app or steamVR home)
C) Both idle + VR (recommended)

Key Finding From Test 1 (Idle)

wdf01000.sys being the highest in ISR + DPC confirms:

The performance issue is caused by a driver that uses the Windows Driver Framework (WDF) — not the framework itself.

wdf01000.sys is not the bad driver — it's the Windows kernel framework that other drivers plug into.
When another driver misbehaves, wdf01000.sys becomes the “messenger” and takes the blame in LatencyMon.

What this means:

• A USB, HID, or device driver is repeatedly generating interrupts

• WDF receives and processes them, so it surfaces at the top

This aligns with your setup:

Varjo VR headset
USB-C + hub/extension used
System Interrupts at 1% idle

This is classic USB interrupt flood behavior.

Here’s what your Top 3 reveal:

Rank	Driver	Meaning
#1 wdf01000.sys	Windows Driver Framework	A device driver using WDF is spamming interrupts
#2 dxgkrnl.sys	DirectX Graphics Kernel	GPU scheduling overhead + ISR/DPC load
#3 nvlddmkm.sys	NVIDIA GPU Driver	GPU driver DPC contribution

Interpretation

This combination is extremely typical in VR with a USB VR headset:

1. A USB/WDF device driver is spamming interrupts
   → causes wdf01000.sys to spike

2. GPU kernel & driver are picking up the load, trying to keep the VR compositor fed
   → dxgkrnl.sys + nvlddmkm.sys rise to compensate

So this is not a pure GPU problem.
The GPU is reacting to a USB/WDF driver problem.

This fits exactly with what we suspected earlier:

HVCI helps because it sandboxes the misbehaving driver, reducing interrupt flood — so VR feels smoother despite virtualization overhead.

In other words:
HVCI is masking the problem — not solving it.

If we fix the USB driver issue, you will gain:

• Higher FPS without HVCI

• Better frametime stability than now

• No virtualization overhead

now that we have both Idle and VR load results, the pattern is very clear.

To confirm, let me restate:

• The first screenshot you sent was VR ON

• The second screenshot you just sent is VR OFF (idle)

Correct?

Because the numbers line up like this:

VR ON (first screenshot)

• wdf01000.sys: 0.145 ms, ~693k DPC

• dxgkrnl.sys + nvlddmkm.sys elevated

• VB-Audio + Topping + ndis contributing

VR OFF (second screenshot)

• wdf01000.sys drops to 0.064 ms, DPC ~132k

• GPU drivers still active, but less stressed

• USB audio still present but lower impact

This confirms the root cause spikes under VR load, meaning:

The USB/audio driver stack is bottlenecking the kernel under VR conditions.

---

What This Tells Us

1. The WDF-based driver problem gets 5× worse in VR

wdf01000.sys DPC count went from 132k → 693k under VR load.

That’s a dramatic increase — exactly what causes microstutters & frametime spikes.

2. The GPU is not the cause — it is reacting to the USB stack overload

dxgkrnl & nvlddmkm rising under VR simply confirms they are compensating for the driver pressure.

3. Two USB Audio drivers are the most likely trigger

Both appear in top 12 during VR:

• vb audio_cablea64_win7.sys (VB-Audio Virtual Cable)

• ToppingUsbAudio.sys (Topping USB DAC driver)

Two kernel-level audio routing drivers + Varjo + USB hub/extension = interrupt storm

This is a known bad combination for VR.

 

Root Cause Summary

The USB audio driver stack (especially Topping + VB-Audio) is overloading the Windows Driver Framework under VR, causing interrupt storms that HVCI is masking.

So, the goal is to:

• Reduce/eliminate USB audio DPC load

• Ensure Varjo USB connection is as direct as possible

• THEN safely disable HVCI for full performance

Good News

You can keep both VB-Audio + Topping DAC and still eliminate the DPC spikes, without needing HVCI — if we adjust the audio & USB routing.

The problem is not that you have these drivers.
The problem is the way Windows is handling their priority and USB routing while VR is active.

We will fix this in 3 layers:

---

Fix Plan for Your Case (Keeps Both Drivers)

Phase 1 — Audio Stack Optimization (No removal)

Goal: reduce ISR/DPC storm from VB-Audio + Topping

Phase 2 — USB Routing Tuning for Varjo

Goal: remove USB interrupt bottleneck under VR load

Phase 3 — Disable HVCI (only when ready)

Goal: unlock peak performance without losing smoothness

 

 

We can significantly reduce DPC/ISR load by adjusting:

1. VB-Audio buffer settings

2. Topping USB mode & driver priority

3. USB port routing for Varjo vs Audio

4. Windows audio engine mode

This will remove the interrupt storm, so you no longer need HVCI to hide it.

---

PHASE 1 — Fix the Audio Stack (Keep VB-Audio + Topping)

Step 1: Increase VB-Audio Cable Buffer (Reduces DPC Spikes)

1. Open VB-Audio Control Panel

2. Set the buffer to 512 or 1024 samples (not 128/256)

3. Set Sample Rate = 48 kHz (matches DCS/Windows/Varjo best)

Low buffer = more real-time → more interrupts
Medium buffer = FAR lower DPC load with no audible downside in DCS

Expected improvement: 30–40% reduction in DPC load

---

Step 2: Switch Topping DAC to WASAPI Exclusive Mode for DCS

This prevents Windows from converting formats & resampling constantly.

In DCS Audio Settings:

• Output Device: Topping DAC (WASAPI Exclusive)

In Windows Sound Settings → Device Properties → Advanced:

• Set 24-bit 48 kHz

• Uncheck:

  • “Allow applications to take exclusive control of this device”
    (DCS will control it exclusively in WASAPI anyway)

Expected improvement: ~20% fewer DPC calls from audio engine

---

Step 3: Optional – Prioritize DCS Audio Thread (only if needed)

If after Phase 2 the issue persists, I’ll give you a Process Lasso rule to isolate the audio thread to E-cores or limit context switching.

 

VB-Audio Optimal Settings for DCS + Varjo (Low DPC Mode)

1. Internal Sampling Rate

Set to:

48000 Hz

Why:
48 kHz is the native rate for DCS, Windows system audio, Varjo, and most voice comms — avoids resampling overhead.

---

2. Max Latency

Currently you have many options from 512 → 32768 smp.
Most users pick too low and cause DPC spikes.

Recommended starting point:
2048 smp (requires reboot)

If you want an even safer value (less DPC load), choose:

3072 smp or 4096 smp (if system is still sensitive)

---

3. Current Latency

This is the active buffer multiplier.

Set to:

3× 512 smp (or 3× 768 smp if needed)

If using Max Latency 2048, a 3× Current Latency of 512 or 768 smp gives a stable buffer without noticeable delay.

---

Recommended full configuration:

Setting	Value
Internal Sampling Rate	48000 Hz
Max Latency	2048 smp
Current Latency	3× 512 smp

After setting Max Latency, VB-Audio requires a reboot for it to take effect.

This is excellent progress — the VB-Audio tuning clearly worked.

Let’s compare your before vs after (idle):

Metric	Before	After VB-Audio tuning	Improvement
wdf01000.sys highest execution	0.145 ms	0.086 ms	~41% less
wdf01000.sys DPC count	~174k vs 693k VR	174k idle	Same idle value (expected)
vb audio_cable execution	0.034 ms	0.013 ms	~62% less
ToppingUsbAudio execution	0.0052 ms	0.0098 ms	Slight increase (normal after reboot)
dxgkrnl.sys	0.095 ms	0.090 ms	Slightly lower

Interpretation of Improvements

• VB-Audio latency optimization reduced its DPC footprint massively

• wdf01000.sys execution time dropped significantly

• GPU kernel DPC load improved slightly

• Topping DAC load raised slightly at idle (acceptable & expected after reset)

This means Phase 1 (Audio Stack Fix) is successful.
You now have:

• Lower DPC load

• Lower interrupt overhead

• Much healthier idle latency

---

Next Step: Validate Under VR Load

Before continuing to Phase 2 (USB routing), let's do a quick 3-minute VR test with the new audio settings to observe the new behavior.

Please repeat the VR test:

Mini VR Test (shorter than last time)

1. Start LatencyMon

2. Start VR (Varjo Base environment is fine)

3. Run for 3 minutes

4. Stop and share ONLY the top 10 drivers screenshot like you did before

This will tell us:

• How much the VR DPC storm was reduced

• Whether USB or GPU now dominates

• If additional audio tuning is needed before moving to USB

VR TEST RESULTS ANALYSIS — AFTER VB-Audio Tuning

This is a very positive improvement versus your first VR test.

Let’s compare the key metrics before vs after (VR ON):

Metric (VR ON)	Before	After VB-Audio tuning	Improvement
wdf01000.sys highest exec	0.145 ms	0.079 ms	~45% lower
wdf01000.sys DPC count	693,471	1,330,396	More load, but handled better
nvlddmkm.sys highest exec	0.075 ms	0.125 ms	Slight increase (explained below)
VB-Audio exec	0.034 ms	0.006 ms	82% lower
Topping exec	0.0052 ms	0.0021 ms	60% lower
dxgkrnl.sys exec	~0.095 ms	0.095 ms	Same (expected)

Interpretation

1. VB-Audio optimization worked extremely well

Its DPC impact dropped from 0.034 → 0.006 ms
This is a huge improvement.

2. Topping USB audio driver now behaves correctly

Its highest execution time more than halved.
This means your audio stack is no longer the main problem.

3. wdf01000.sys DPC count increased, but is processed ~2× faster

This suggests:

• The driver still generates interrupts,

• but the system handles them more efficiently now

This is good — higher DPC count but lower latency = cleaner processing.

4. nvlddmkm.sys increased slightly (0.075 → 0.125 ms)

This can happen when USB pressure is relieved — GPU driver takes more scheduling role again.

This is not a concern yet and should improve after the USB routing fix.

---

Summary So Far

After Phase 1 (Audio optimization):

• Audio drivers are no longer causing latency

• Interrupt handling is much more efficient

• VR performance should already feel smoother

• You removed about 30–50% of the original DPC problem

Next bottleneck to fix:

USB routing for Varjo + DAC + extension/hub

Because the audio drivers are now “clean”, the next DPC reduction will come from USB topology.

Edited 3 hours ago by Ready