allow exact sync with shader subframes

[Tatsuya79]

It's working somewhat, a bit hit or miss but better than nothing with games with particular timings.

[Ophidon]

As the person who put that setting combination block in place, not sure I agree with this change. I would, for sure, if the alternative was actually 'nothing' as listed.

But there are 2 already existing ways to handle it. For basic 'casual' use there is increasing the maximum timing skew to allow resyncing from farther away.

And for someone who is really serious about syncing a game that is far enough that the timing skew would be a significant speed difference (like arcade MK running at 53Hz) and they insist on playing at the correct speed, while simultaneously also insisting on BFI/Sub-frames, there is an existing solution as well. You can create a custom resolution that is a multiple of the Hz for that game.

BFI/Sub-frames aren't tied to 50/60hz multiples in particular, that's just the most normal use case, they'll work correctly at exact multiples of any base sync rate.

Usually I'm all in for 'leave everything as an option, don't make decisions for the user they won't always agree with'. But in this instance, I think that:

1. Having existing solutions to the problem (and in the case of the second above solution works essentially perfectly compared to the change from this PR that admits it only works 'somewhat'), and

2. There will likely be an overwhelming percentage of users who won't understand, without a 10 page essay they'll never read, why enabling these 2 settings simultaneously could cause erratic flickering (or at least poor frame pacing for uses of sub-frames besides BFI) in a much wider scope of games and systems than those with unusual timings. Exact timings? Sounds great, hooray accuracy! BFI/Sub-frames allow for crt like motion clarity?! Also good! Hooray, 2 good things, gotta have both!

means that in this case it's best to leave the burden on the already high information users looking to solve this problem, to figure out to use either of the existing methods instead of opening this settings trap that will be easy to fall into for the lower infomation users, which for something fairly obscure and timing related like this will include nearly everyone.

[Tatsuya79]

I'm not dead set on anything, it's just that I tested several scenarios on my gsync screen and it works better with exact sync.
You can't create any custom resolution on every monitor and that's a bit involved.
I got good result with standard 60hz games, if people see a bit of flickering in particular scenarios they'll have to experiment.
It's always complicated honestly with strobing, I'd like to say I have a way to fix it with vrr completely but I don't.

[hizzlekizzle]

@Ophidon so it makes a lot of flickering on your end? Tatsuya said it was fine on his end. I guess we need more people to try it and report back.

[Ophidon]

Yeah I just retested my listed example of arcade MK and it's flickering pretty heavily this way.

I knew it should just based on understanding how vrr_runloop_enable works inside of runloop.c, and how the sub-frames are unaware of any attempted timing from there. But yeah, who knows what'd changed in the year since I put that block in place so I did just physically retest.

So essentially you get the start of each real frame trying to wait to time as accurately as it can to hit the game's requested sync rate, but then the follow up sub-frames are coming at a different pacing limited by nothing but the current display rate. So, uneven frame pacing, which equals flicker for BFI.

Trying to solve that so the sub-frames are aware of the attempted pacing is perhaps possible but it'd be very tricky as it's done all the way at the present point in the graphics drivers. And even then it'd only work properly for cases like MK where the timing multiple is below the max output rate of the screen, not above like it very well could be for SNES for example, which iirc actually requests something like 60.08Hz.