Blur Busters Forums

Hello,

Here's a new ultra-precise TestUFO refresh rate test:



Wait up to 30 seconds for the decimal digits to settle.

In single-monitor mode, with GPU acceleration (chrome://gpu), it works in Chrome up to ~480Hz, FireFox/Opera up to ~240Hz, and latest version of IE/Edge up to ~105Hz.

Link: testufo.com/refreshrate

Useful for low-latency VSYNC ON: If you don't have a VRR monitor -- and you hate VSYNC OFF due to tearing -- then you can eliminate 75% of VSYNC ON input lag. Set your frame rate cap (using RTSS) to around ~0.01fps (margin will be game-dependant) below the number you see above. Only RTSS has frame-capping accurate enough for ultra-low-latency VSYNC ON. The frame rate capping removes lag via reducing framebuffer backpressure.

Yey! Finally our own refresh rate detector

Some issues I can see (Chrome on Windows 10): it doesn't work when I click the full-screen button, and it takes a long time to detect the refresh rate compared to vsynctester.com.

Chief Blur Buster wrote:Set your frame rate cap (fps_max, RTSS, NVInspector, etc) to around ~0.01fps below the number you see above.

NVInspector will not work for that:

1. It doesn't allow decimals.
2. Even if it did, it rounds up the limit value to match the refresh.
3. Even if it didn't do 1 and 2, any input lag reduction gained through backpressure elimination is lost due to the input lag added by nvidia's limiter.

It's completely useless for low latency vsync

In-game limiters also won't work. The source engine's fps_max limiter is certainly not accurate enough (it's far away from 0.01FPS accuracy.) Maybe the Unreal Engine limiter is, but no one has tested. (But I doubt it has 0.01FPS accuracy. I'm not aware of any timer API, at least on Windows, that has this kind of granularity.)

RTSS is pretty much your only bet. It has microsecond precision (well, in theory, is has CPU cycle accuracy, since it kills cycles through a busy-wait loop, but other things in the OS will interfere.)

RealNC wrote:Some issues I can see (Chrome on Windows 10): it doesn't work when I click the full-screen button, and it takes a long time to detect the refresh rate compared to vsynctester.com.

Really? It works on my system. What happens when you click the full-screen button?

It intentionally calculates for at least 5 seconds before displaying the refresh rate, to prevent confusing users with bouncing numbers. How long is it taking to display a refresh rate on your system?

RealNC wrote:NVInspector will not work for that:

Thanks for the info. I've edited my post to mention that.

RealNC wrote:In-game limiters also won't work.

In theory, it could. But the game programmer would have to work for it. Modern Multimedia Timers (WINMM.DLL), with some general programming guidelines, can be sufficiently accurate enough (at least in average interval between events, not necessarily exact event timings) -- that if in-game limiters used things this way, and made sure average intervals between timers were precise (even if intervals jitter a little, even +/- 1ms), then the slight jitter won't build up to meaningful framebuffer backpressure.

Busyloops can be useful to compensate for timer jitter. If the average interval of recurring WINMM.DLL timers are always accurate despite jitter, then you could eliminate that necessity by verifying that the average interval is ultra-precise. Alternatively, given a targeted ultra-precise frame rate cap, one could also combine scheduled timers (a one-off WINMM.DLL timer calculated to the microsecond, then subtract about ~0.5ms) then using a small busyloop at the beginning of the timer event to erase the jitter. For general programming guideline, the big important thing is that average interval is extremely, extremely precise. Generally, game developers do not focus for such timer precision. So, yes, we have to rely on RTSS instead for such precision.

Also, it is simultaneously possible to create an ultra-precise refresh-rate-following frame rate cap. In theory, RTSS could automatically scan for the current maximum refresh rate and/or attempt to detect framebuffer backpressure, and adaptively adjust its cap (at the millihertz league). Maybe this is a feature RTSS should add!

This is exactly what I needed!
These variable refresh rates have been an enigma to me for long, and this will surely help me get a better understanding of the underlying mechanics. I am especially intrigued by toggling between 59hz and 60hz, which as expected, yield ~59.94 FPS and ~60 FPS respectively.
How does divergence affect movie playback? Is the smallest deviation bound to stutter or skip a frame?

Depends on the media player. A good player will change the video FPS to match the refresh and resample the audio to stay in sync.