VideoCommon: VI Skip

[Sam-Belliveau]

This hack uses the improved pacing branch to look at the amount of time ahead / behind of the timings the emulation is. If the emulation is more that 40ms behind the timings (length of the audio buffer) then it will skip sending an VI to the CPU in order to prevent the game from requesting to draw a new frame. While this is "hacky," it is the most compatible way to induce a frame skip when GPU limited and is very non invasive compared to the old frame skip.

Here is an image to help visualize the timings:

This image is old so the only thing incorrect is the size of the buffer, which is now the same as TimingVariance, which is 40ms.

Heres a video of an old version. The audio is full speed but the video is not: VIDEO

[JosJuice]

Could we automatically disable this when Core::WantsDeterminism returns true? Because as far as I can tell, there's no way this is going to work with netplay/TASing.

[JMC47]

Edit: MKWii TASers don't need determinism, ignore me.

[phire]

If you want to do some more experimentation:

Alternative idea one:

Instead of outright skipping the VI interrupt, compatibility might be higher if you simply switch to an uneven frame pacing. Instead of two 16ms frames, have one frame that's 31ms and the other which is 1ms. That way the total number of VI interrupts stays the same, but the short frame is (hopefully) short enough that it always triggers the game's built in frame limiter.

Alternative idea two:

Instead of moving VI interrupts, maybe it's smarter to move the final finished interrupt after the EFB to XFB copy until after the VI interrupt. Dolphin would still see the finished frame on-time (if the immediate present xfb option is enabled), but the game would think the GPU is busy and not start work on the next frame.

[dvessel]

Just a general indicator on the overhead with the recent changes comparing latest master vs lagbegone rebased to latest master.

The test simply runs F-Zero Sand Ocean intro as fast as possible at 1x resolution.

master 5.0-18221-f4f9439-f4f9439

11436 frames 4.852ms, v-blanks 4.684ms - metal pass 1
11436 frames 4.841ms, v-blanks 4.673ms - metal pass 2
11436 frames 4.842ms, v-blanks 4.674ms - metal pass 3
34308 frames 4.845ms, v-blanks 4.677ms complete

lagbegone 5.0-18226-2756110-f4f9439

11436 frames 4.834ms, v-blanks 4.665ms - metal pass 1
11436 frames 4.876ms, v-blanks 4.707ms - metal pass 2
11436 frames 4.882ms, v-blanks 4.712ms - metal pass 3
34308 frames 4.864ms, v-blanks 4.695ms complete

It previously had an overhead of about 0.4ms. It’s now a fraction of that.

options set in the terminal

[delroth]

🎉

[AdmiralCurtiss]

This change from 40ms to 100ms causes https://bugs.dolphin-emu.org/issues/13166 (in Dual Core mode).

Now... Dual Core is notorious for being weird, but why exactly was this changed here anyway?

[Sam-Belliveau]

having it at 40ms means that 40ms of lag causes slowdown, which stops vi skip from running at full speed if the fps is < 25. I didn't want to make the audio latency 40ms so i didn't increase the variance. i don't know why increasing this would cause it to hang as the throttler is independent of the emulated system, and any changes to the throttler should have no effect on the rest of the code.

[AdmiralCurtiss]

Remember that Dual Core leaks external state into the emulation. If the larger fallback allows the GPU thread to get further ahead or behind the CPU thread then that's observable by a game in Dual Core mode.

[Sam-Belliveau]

is the solution here really to lower the fallback? A higher fallback allows the emulator to run at full speed even during stutters which is a huge bonus.

[delroth]

Might make more sense to introduce some threshold of CPU/GPU desync for dual core specifically, maybe? Not sure how hard that would be...

…

On Sun, 12 Feb 2023, 11:04 Sam Belliveau, ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In Source/Core/Core/CoreTiming.cpp <#11367 (comment)> : > const DT max_fallback = - std::chrono::duration_cast<DT>(DT_ms(Config::Get(Config::MAIN_TIMING_VARIANCE))); + std::chrono::duration_cast<DT>(DT_ms(Config::Get(Config::MAIN_MAX_FALLBACK))); is the solution here really to lower the fallback? A higher fallback allows the emulator to run at full speed even during stutters which is a huge bonus. — Reply to this email directly, view it on GitHub <#11367 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABRQLVIRZ3AQBUYWF2NOETWXBAMVANCNFSM6AAAAAATHLNVMM> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[Anuskuss]

What do you guys think about making this the default? My PC is powerful enough where I don't need this but even I experience lag sometimes. AFAICT this is unlikely to have any negative side effects (unlike traditional frame skip) other than being incompatible with a few games. It might actually be the way it works on real hardware given the fact that some games choose to ignore the VBLANK altogether.

Edit: Also seems like the performance overlay used VPS rather than FPS to determine the speed% which in turn always shows 100% with this option enabled (as of the latest beta).

[cobalt2727]

That's mentioned in the progress report - it doesn't work in every case.

[Anuskuss]

That's mentioned in the progress report - it doesn't work in every case.

If it doesn't work does it cause harm? And if it does cause harm can't you just blacklist it? Unless it causes subtle issues then of course it should be considered a (speed) hack and default to off but to me it doesn't look like that's the case.

[OatmealDome]

I wouldn't be comfortable with making a hack like this enabled by default. If VBI Skip causes some game we haven't tested to break, and an newbie user tries to play it and finds that it doesn't work properly, that's a poor first experience with Dolphin. They shouldn't be expected to know to turn off a random checkbox buried in a settings menu.

So far (according to the progress report), games broken with VBI Skip tend to just freeze on a black screen or lag even worse than they already do.

[Anuskuss]

that's a poor first experience with Dolphin

I'd argue the opposite: Thousands of (Android) users running their favorite game only for it to lag and stutter is a worse experience (when I doesn't have to be). But I don't know, maybe keeping it off is the safer approach; I just don't see what issues it could cause.

I'd say defaulting it to on (between betas) may be enough to catch all misbehaving games.