From my experience it is really easy to tell when the setup is not working as intended.
1) Boot up the computer
2) Go into CS2 DM
3) Fast flicking of the mouse (can also bind lookleft/right to a button and just observe how the monitor presents the frames)
[everything is tuned for lowest input lag with uncapped FPS - frame pacing etc is not taken into account]
Will easily see and feel the state of the situation
- Broken = flickery image (still looks perfect when doing different UFO Tests)
- Perfect = smoother/snappier transition between frames
It's like the responsiveness of the monitor suddenly has gotten worse since last boot - Like what is rendered is slightly behind what is supposed to be there.
- A setup with vsync+gsync+NvidiaReflex will hide the visual hint that something is obviously wrong, but you will still play like a bot
- Using in game cap set below refresh rate will also hide the visual hint.
When playing in this state, every aim dual is completely lotto with spray, eye-to-hand coordination, and movement being "off".
Simple step to verify you can indeed see and feel small visual changes → change the following parameter:
- Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile\Tasks\Games
- Set "GPU Priority" to "1"
On every setup I've had over the years, this simple change will drastically change the visual representation on the monitor.
- Use the bind for lookleft/right and record with your phone.
- When turning corners, what is around the corner "renders" faster.
- I do not recommend using "GPU Priority" = "1" permanently as the game and render thread seems to get out of sync. This is just meant to show that it is in fact easy to notice the difference in milli-second visual changes. Swap between the values "1" and "8" on "GPU Priority".
Fun-fact: CS does not use the "Games" key in MMCSS -> See documentation from user "Timecard" -> But it obviously still affects cs
I can somewhat relate it to people saying games feel amazing after first boot of a fresh Windows installation, but everything immediately breaks on the second boot. I've got a "hunch" that this is related to added/mutated variables that are used in link-training with the monitor during boot. By playing around with CRU and/or other graphics related settings, you can "break the broken" setup and feel the correct response already at the desktop. At the next boot everything will be back to a broken setup. But it is not necessarily easy to replicate by doing the same steps every time after boot, which has me puzzled.
- The same flip model is equal in both scenarios (perfect vs broken)
- I've not been able to locate any differences in available config
- Might be some parameters in the GPU driver - When we find what is changed, I believe we will also find a solution.
So... skipping all debugging steps, I strongly believe the issue is created when the driver builds the display head configuration:
On the very first boot after driver install, the driver doesn’t yet have:
- Stable power telemetry
- Established display timing history
- Learned clock ramp behavior
- Finalized display engine policy tables
So it may initially run with a different scanout timing policy before switching to its steady-state behavior.
After a reboot, once initialization completes, it switches to a "Steady-state" throughput-optimized scanout model
- This model slightly increases the buffer window between: Frame finished rendering → Frame latched for scanout
From what I understand we’re talking fractions of a millisecond of phase shift, but that is exactly what the flick test (at high Hz & framerates) is sensitive to.
So our problem seems to be located:
After:
Game → Present → Flip Model → Frame ready
And before or possibly at:
Scanout → Cable → Monitor
And there is no "knob" to manually tune the guard-band/latch window. It’s like reboot roulette, but at the driver’s display engine level. The solution seems to be in a sacred ritual that forces the "good" link-training state consistently... and I've tried so many things over years...
My anecdotal and sacred rituals have ended up in a setup where I most of the time avoid this "larger scanout safety window".
- Primary monitor connected to iGPU with a low Hz
- Secondary monitor (gaming monitor) connected to the GPU
EDIT: After doing this, you should reboot
My guess is that the iGPU ends up owning the "master display timing clock" which in turn forces a conservative scanout latch policy. The NVIDIA GPU gets pushed into a different internal policy branch where the latch window can be tighter, acting as a dedicated fullscreen scanout device. The frames are now latched closer to scanout, even though the measured input lag barely changes.
I have no scientific approach to the issue, just simple testing combined with trial and error, and of course a strong confidence in my ability to perceive a perfect vs broken setup, ref the flick test with switching the value of the MMCSS GPU Priority.
- Why this is not an issue for every user out there is unknown to me - I'm guessing HW combo, but:
-- This "phase shift" is mostly noticeable at higher frame- and refresh rates
-- Easily masked with frame cap
So might as well be that many are affected, just not knowing about it.
Try it out and report back
