RealNC wrote:Sparky wrote:If you can do that, why not just keep a framerate at exactly the refresh rate?
That's just normal vsync, with huge input lag.
Ultimately, you need a refresh rate synchronous framerate cap to get v-sync without latency, stutter or VRR, and that's what I was hoping for when all we had to go on was rumors.
I assumed that's how fast sync works.
I wish, but nope. All fast sync does differently is drop frames instead of restricting framerate with backpressure.
Games that offer their own FPS OSD (because an external one doesn't get the right info with fast sync) shows that the game engine produces frames at rates that are multiples of the refresh rate. CS:GO and Elite Dangerous have such in-game FPS indicators, and in both what I observe is they never render at anything else than 60/120/180/240/etc FPS (an external FPS indicator, like RTSS, show FPS values that don't match the in-game indicator.) So fast sync does seem to try and do exactly that, but still fails to produce stutter-free output. It works for 5-6 seconds, and then it poops out for 1 or 2 seconds. I just assume the driver doesn't get the timing right.
You're either dropping or gaining one frame every 5-6 seconds. (just like this, except it sounds like you have more frametime variance, so you'll make several jumps up and down at each big transition instead of just one(ignore the high frequency noise, that's caused by random click timing, not the game engine):
http://i.imgur.com/lwGn6t3.png)
To obtain the ideal solution, you need two signals from the GPU driver back into the game engine, one is a v_blank signal, and the other is a frame completion signal. From that you can keep track of how long it takes an individual frame to render, how consistent that time is, and how much time there is between the frame finishing rendering and actually getting displayed. This means you can make a precise tradeoff in latency vs confidence in rendering on time. Say a frame takes 3ms±1ms to render, if your refresh rate is 60hz, you would set your cap to get user input and start working on a frame about 12ms after the most recent v_blank, then wait until 12ms after the next v_blank. There isn't any reason to render extra frames, because you're just going to throw those away anyway. You get rid of the latency caused by buffering in the render chain by only ever allowing one frame into the render pipeline at a time(or two, if you need the extra buffering to deal with your frametime variance)
This would get you perfectly smooth animation with approx 7ms of full chain latency(excluding monitor, unless you're using a CRT).
Anyway, that's not what fast sync does, at least according to Nvidia:
https://www.youtube.com/watch?v=WpUX8ZNkn2U
If fast sync is operating as described in that video, the game engine should be able to run at any framerate, not just a multiple of your refresh rate, and you'll get judder proportional to 1/framerate.
If there is a separate framerate cap somewhere, that would explain your hitch every few seconds.