Present VFR duplicate frames on a tempo

[kcgen]

Potential fix for #2340

Adding @0mnicydle.

Here's VFR presenting duplicates at roughly 7 Hz in an otherwise static CLI:

(the periodic jumps are the CLI application doing a redraw pass every ~15 seconds or so).

[0mnicydle]

Thanks for taking a crack at this @kcgen, but after building this PR I'm seeing a minimum of almost 200fps at 1000Hz dos rate. Hoping for something that will result in single digit dupes per sec even at 1000Hz. Also an option to disable completely would be appreciated as any time the monitor spends drawing dupes represents a possible delay in showing the next real frame, depending on when it arrives. At very low dupe rates this probably wouldn't mean too much, but it would still be nice.

[kcgen]

Thanks for the checking @0mnicydle, and your numbers make sense with the (currently fixed) one-fifth tempo (versus DOS rate).

I'll make the tempo a factor of the DOS rate: so the faster the rate, the more drawn out the tempo gets.

[0mnicydle]

New commit is working much better, thanks @kcgen. Though can you please tell me if there's an easy modification I can make to the code to play around with higher rates like ~10-30fps? You're gonna think I'm crazy, but I can feel a little bit of a delay coming out of what would normally be 0fps situations, which are now ~5fps situations, and I'm speculating that it's a result of my gsync monitor transitioning in and out of its LFC mode at these low rates; it's not something I can notice with VRR disabled.

[0mnicydle]

So for commit 6d307e4 I'm getting about ~28fps in previously 0fps situations (at 1000Hz), and I am no longer getting that little delay I was talking about when launching back into higher frame rates. It seems a shame to make the minimum rate so high for everyone just because of VRR strangeness, and I imagine the threshold for avoiding issues will be different on different VRR displays, so I still think it would be nice if this dupe rate was user configurable...

But as far as how it's behaving right now for my use case, loving it! Working like a champ! The minor delay thing comes back at 70Hz dos rate because now the dupe rate is back to single digits, but I personally won't be using VFR for 70Hz anyway.

Whatever the reason, whether it's LFC related or something else, my monitor doesn't seem to appreciate single digit frame rates and would rather see 0fps, go figure...

[kcgen]

I'm getting about ~28fps in previously 0fps situations (at 1000Hz), and I am no longer getting that little delay

👍 ; thanks - I didn't have a chance to describe it before you tested it.

It seems a shame to make the minimum rate so high for everyone just because of VRR strangeness

The good news is the tempo scales with respect to the DOS rate.

In the current commit:

	constexpr auto min_dos_rate_hz    = 24.0;
	constexpr auto max_dos_rate_hz    = 1000.0;

	constexpr auto min_backfill_tempo = 4.0;
	constexpr auto max_backfill_tempo = 18.0;

At the lower bound, a (forced) DOS rate of 24 Hz will backfill every 4th call to the VFR presenter (but only after 'going dry'). At the other end, a (forced) DOS rate of 1000 Hz will backfill every 18th call.

For users without VRR displays and not overriding the DOS rate, the effective VFR dupe rate is around 10 Hz, which is reasonable given that's still ~100 ms to wait before filling in a (possibly) dropped frame.

Users with VRR displays and not overriding the DOS rate will be in CFR mode + vsync, so getting a steady ~59 to 70.2 FPS stream (plenty above even the worst monitors' 48 Hz LFC threshold).

If you want to experiment lowing the dupe rate, ratchet up the max_backfill_tempo value (say 20, 22, 25, etc) - Maybe you can go even lower! (although, 28 Hz is still no sweat if that's what's needed!).

[0mnicydle]

That all sounds very reasonable. Thanks for your efforts @kcgen!

[kcgen]

@0mnicydle - I think you're the only one who's figured out how to run a bunch of these FPS-style games at fluid millisecond-level update rates.

There are a ton of users out there with fast PCs and 120+ Hz monitors who aren't aware they can experience games like System Shock at butter-smooth tear-free rates.

Would you be interested in helping them with tips or a short guide? - perhaps start with your settings for the handful of games where there's a marked benefit. No pressure; just if you want! 🙂

[0mnicydle]

I was wondering if you'd be interested in writing up a short guide on this (perhaps start with listing your settings for the handful of games where there's a marked benefit) - but no pressure, just if you want to!

Sure, it's the least I could do after all. I just found the discord server, so I'll be in touch when I have something for you.

[johnnovak]

@0mnicydle I wanted to suggest writing such a guide myself but @kcgen beat me to it 😄 It seems you're the best person to do it with your experience in the subject and it would definitely benefit other people with VRR capable displays.

If you have even just a rough writeup, I can polish it up a little and create a new page for it on our wiki. Just send it to me on Discord 😄

[johnnovak]

For users without VRR displays and not overriding the DOS rate, the effective VFR dupe rate is around 10 Hz, which is reasonable given that's still ~100 ms to wait before filling in a (possibly) dropped frame.

So that's my use case @kcgen. If I understand this correctly, there will be screen updates at at least 100 ms intervals in text mode apps where I encountered the missing frame issue. That's good enough I think.

[kcgen]

If I understand this correctly, there will be screen updates at at least 100 ms intervals in text mode apps where I encountered the missing frame issue.

That's right.

[ThomasEricB]

There are a ton of users out there with fast PCs and 120+ Hz monitors who aren't aware they can experience games like System Shock at butter-smooth tear-free rates.

I have a 144 hz monitor and I love System Shock! @0mnicydle

[johnnovak]

Great improvement @kcgen 🎉

[kcgen]

Thanks for all the testing and feedback, @0mnicydle 🚀