Measure gaming performance before you tweak: frame time, 1% low, latency
A repeatable method for Windows 11 26H2 gaming measurements, including passthrough-VM caveats and a ledger for every change.
- Build
- 26300.9711
- Edition
- Pro
- Architecture
- x64
- Support
- Test method
- Evidence
- E1Official documentation
- Verified
- 2026-10-27
- Page type
- Method
The short answer
Section titled “The short answer”Average FPS hides the problem. If a game “feels” bad while the counter says 120, look at frame time and 1% low, then change one variable at a time. A tweak without a before/after measurement is a guess.
What to capture
Section titled “What to capture”| Metric | Why it matters | Tool |
|---|---|---|
| Average FPS | Throughput, easy to over-read | CapFrameX / PresentMon |
| 1% low FPS | The stutter you actually feel | CapFrameX |
| P99 frame time | Worst frames, not the average | CapFrameX |
| DPC/ISR latency | Driver-level stalls | LatencyMon |
| Clocks, temps, power | Confirms the run was comparable | HWiNFO |
Procedure
Section titled “Procedure”Write down the Windows build (winver), GPU driver version, game version, resolution, refresh rate, VRR state, power plan and room temperature. A result without these is not comparable.
Expected: Same build, driver, game version, resolution, quality preset and power plan before and after.
Use a repeatable scene (built-in benchmark or a saved route). Discard the first cold run. Keep the raw CSV; the page shows the summary, not a screenshot of a number.
Expected: Five runs of the same 60-second scene; median and 1% low recorded.
Snapshot the VM or create a restore point first. If two things change, you cannot attribute the result.
Expected: Exactly one registry, service, driver or in-game setting differs.
Run the same five-pass sequence. If the delta is inside the noise band, publish it as “no measurable effect” rather than a win.
Expected: A delta larger than run-to-run noise, with the same scene and settings.
Tweak ledger (schema example)
Section titled “Tweak ledger (schema example)”Rows are filled only after a measured run. “Pending” is deliberate: no data, no percentage.
| Change | What it changes | Measured delta | Risk | Rollback |
|---|---|---|---|---|
| Memory integrity (HVCI) | Disables VBS/HVCI kernel integrity checks; reduces virtualization overhead | Pending (M-V) | R2System-levelStable | Windows Security → Device security → Core isolation → Memory integrity → On |
| Hardware-accelerated GPU scheduling | Moves GPU scheduling from the CPU to the GPU scheduler | Pending (M-V) | R1ReversibleStable | Settings → System → Display → Graphics → Change default graphics settings → Off |
| Core parking override | Keeps selected cores unparked; changes scheduler behavior | Pending (M-V) | R2System-levelExtreme Lab | Restore the exported power-plan GUID or `powercfg /restoredefaultschemes` |
Passthrough-VM caveats
Section titled “Passthrough-VM caveats”- Label it. A GPU-passthrough VM is
M-V. Absolute FPS is not a bare-metal number; use it for same-environment comparisons. - Anti-cheat can refuse. Some titles detect virtual machines. Keep a list; test blocked titles on bare metal or do not publish a result.
- Synthetic vs real: a built-in benchmark is repeatable but may not represent a real match. Say which one you used.
- No silent edits: if you change the VM CPU model, hugepages or pinning between runs, the comparison is invalid.
What not to claim
Section titled “What not to claim”-
“+30% FPS” from a single run.
-
A registry tweak that “reduces input lag” without a latency measurement.
-
A VM result presented as if it were a physical PC.
-
A tweak that permanently disables Defender, updates or a security boundary.
-
Memory integrity (HVCI): measured cost — check the security/performance trade-off before disabling it.