Discussion in 'Videocards - NVIDIA GeForce Drivers Section' started by Exostenza, Apr 3, 2018.
thanks Wagnard, keep up the good work!
hi and thank you for great tools.
i heard that processes ignore timer resolution in windows 10 20h2 and above too. i downloaded Wtools v188.8.131.52, but it seems you disabled this feature for windows 10.
It's a Windows 11 feature, I cannot add this to windows 10 as windows 10 API doesn't have this.
I will necro this a little for adding my current experience will all of this and also talk about a new feature for ISLC.
First, I can tell since playing Diablo 4, I was able to see that the issue with standby list is still present (tested on Windows 11 with 16GB) and that ISLC is able to prevent a lot of theses stutters.
Second, I just recently released ISLC 184.108.40.206 with a new option specifically for Windows 11 that can make the timer resolution work like before Windows 10 v2004 release.
This option will work only on Windows 11 and you will have to reboot after enabling it.
In really simple terms, presently with older ISLC or similar applications, when you requested 1ms or 0.5ms, other application where not affected by it even if ISLC or other app reported 1ms or 0.5 timer resolution.
Why ? Because since Windows 10 v2004, Microsoft changed things related to the timer and is now working by process instead of global. (this article give quite a good explanation)
Now with the new option I added (a simple registry key), it work like before. If you set 0.5ms it will be 0.5ms globally.
Sorry for necro, but i gotta say this. Microsoft comes up with such strange and sudden changes in Windows that feels that with each new version, they experiment with the users. This timer resolution change sucks so much, so unexpected, i can't say for sure, but this can't be good for the performance of some games if they request a timer of 1,0 ms but Windows won't allow it, even if a program sets the timer, such as "TimerTool" reporting, but is not actually being used by all apps now or they use it in a different way. Is this correct? Why the hell would MS do this? This doesn't even make sense nor looks like a good change, in fact, i firmly believe now this is why some games behave horribly on Windows 10 20H2, meanwhile others run really well.
Case and point, Shadow Warrior 2 is a disaster, stutters all over the place for no reason and frametime is messed up on 20H2, whereas i remember on 1803 and 1809, it was super smooth, perfect frametime and no stutter. However, some games do seem to run differently or somewhat better on 20H2, but others are affected in a terrible manner.
Is there way to fix or change this on Windows 10 2004 and upwards or am i forced to use something like 1809 or 1909 or go all the way to Windows 11, since the issue can now be edited in that version of Windows? Holy crap, thank you Microsoft.
EDIT: Ok, i found something, so maybe is not necessarily bad; all games set the timer to 0,5, no matter which one, even emulators, Windows does it on its own, i never checked the Timer while any game is active, this is actually really good. The timer goes back to its normal behavior once you close the game or app, so this is Windows doing, i imagine it detects any sort of "demanding" app that uses Vulkan, DX11 or DX12, then sets the Timer to 0,5. This didn't happen on any previous version of Windows, so this is something introduce since Windows 10 2004 i suppose. So far, this seem so to be a good change and even if it's possible to toggle it on Windows 11, so far i don't see why it should be done. Older games set the timer to 1,0 or 0,9996 ms, if i close the game or app, the Timer goes back to the usual 15 ms. I do set it at 1,0 with TimerTool all of the time, i like to keep it that way, even if apparently that reporting could be wrong now? If it's wrong, then why as soon as i open a game, it changes, even without forcing any timer resolution?
This pretty much confirms this is indeed a per-app behavior, but from what i just checked, it benefits games as it tightens the Timer. This also could explain why some games behave differently on 20H2 compared to previous versions of Windows, some much better and others slightly worse. I gotta check more games, even older ones and see if Windows sets the Timer correctly for them too.
I think the answer was already there in the post you quoted:
I take that means that if a game requests 0.5ms then the game gets 0.5ms, just like before. It's just that requesting 0.5ms with some other software (including things like EA Origin, etc, not just the older versions of this tool) then games which do not request high resolution on their own won't automatically get high resolution (because it's no longer a global thing).
nothing to do with the virtualised timer, its an engine flaw, the stuttering total predates the swapover to the virtual timer (2016), it mainly affects the central hub and is linked to high framerate.
some mitigations would be.
set vsync type to Fast.
use a framecap
Yeah, i was suspicious this wasn't really Windows doing, it's way too strange and too specific, quite a shame. I am not gonna install Windows 10 1809 or earlier so just this game runs well, i mean, i like it a lot, but is not worth it. What about compatibility mode or some registry fix? Another game that behaves differently is MGSV: TPP, without RivaTuner fps limiter, the game has crazy frametimes and microstutters, also FSO with v-sync that used to give perfect framepacing on 1803 or 1809, now it's changed and does not work anymore, using FSO in the game now actually brings a lot of issues that weren't present before. But then again, on 1809, other games had lots of issues as well, so i't sorta a trade off.
*Sigh* looks like i'll have to do a dual boot to this all of this properly...
You don`t have to guess how timer resolution was requested - just launch the game and then execute "powercfg /energy" in command prompt (https://learn.microsoft.com/en-us/w...s/powercfg-command-line-options#option_energy) and then see the report for timer resolution requests.
It reports that TimerTool globally requested an inferior timer to the one of the platform. (I am roughly translating here since my O.S is in another language). It did show the game being executed, but didn't say the game requested a lower timer. So i guess despite what's being said, TimerTool does force a constant timer in Windows of 1,0 no matter what? Even if, apparently, it has been changed?
That breaks the very essence of the original G-Sync idea: "maintaining completely tear-free presentation with completely no unnecessary lag".
The only way to achieve that is VRR+VSync+CAP (unfortunately the CAP might not be maintainable through all APIs, hence the V3 CAP was born [and auto-applied when possible -> but it's sadly not always possible...]).
VRR+FastSync can still produce the same kind of "jitter" at times as FastSync-only presentation. -> This was never recommended by nVidia (as much as I know). This is not "smooth", it's potentially jittery.
Too bad game developers rarely realize this and they don't offer a CAP in +-/1 increments (but something like +/-10 at best).
I guess the presentation would be smooth and minimum-lag if all developers implemented Reflex (which does all the "heavy lifting" in the background while also maintaining an "nVidia FoR RuLeZ RoReVeZ attitude). -> I think Microsoft should implement a generic version of Reflex as soon as possible (if possible). As soon as 23H2, not "when it's ready" (no, yesterday, seriously yesterday!).
Energy report shows apps (and drivers probably) which requested timer resolution, it does not show whether request is global or not (as I take it).
AFAIK, its the game / program / driver that request a timer resolution, windows does not give a timer value randomly. Most games on my end usually ask for 1ms timer, Diablo 4 seems to ask for 0.5 (Windows 11).
My personal thought for the new timer behavior is probably a way to save energy for laptop etc.
On win 10 2004 + when setting manually 0.5ms and people thinking they were getting les input lag, etc.. it was probably placebo effect. With the option "GlobalTimerResolutionRequests" you now enable the old behavior to enable it for everything. There is much more chances that this really affect input lag, frametime etc.
Purge Memory Cache Service by mbk1969.
Useful. Thank you.
Is this useful for someone who has a good PC from 2023 running latest win 11?
If you have issues then yes, you can try. The thing is not about performance, it is about solving one certain issue.
the standby cache issue has been fixed since 1803
Nope, it was fixed in graphics drivers at a later point.
It had nothing to do with graphics drivers, and everything to do with zero-filling the memory reclaimed from the standby cache when it should have been overwritten directly.