Jit64 / JitArm64: Optimized idle skipping detection.

[degasus]

This patch tries to detect idle loops instead of hardcoding them. Half of the patch is from @delroth.

But it lacks MMIO detection: We must not assume that a load has no side effect on hitting MMIO.

[JMC47]

Xenoblade Chronicles sees a huge boost in performance (up to 2x as fast in lighter scenes)

Fire Emblem Radiant Dawn is 6% slower, Luigi's Mansion appears to be a bit slower in lightweight scenes as well (down from 1600 fps in the main menu to 1200 FPS on my computer, rough estimate.)

[delroth]

<3<3<3 seeing my idle skipping experiment be resurrected. Thanks!

[JMC47]

Fire Emblem: Radiant Dawn is still a bit slower in this Pull Request, ~180 to 168 vs master (was 160 before the recent change) in the Wii Remote Strap Screen and carries a similar framerate loss throughout the FMVs/menus.

Bully: Scholarship Edition runs 22 fps instead of 20 on the Wii Remote screen but is ~1% slower in-game, probably within margin of error.

Xenoblade is really fast though.

[Miksel12]

Has anyone tested the performance after the commit from 9 aug? If the overall performance is better, I think it would be a worthwhile change.

[degasus]

It is a huge speedup for ~3 games. It is very worth it, I was just to lazy to finish it.

[Miksel12]

Is there in the current state still performance regressions for certain games?

[weihuoya]

yes, Fire Emblem Radiant Dawn is 6% slower.
but speedup many game.

[Narugakuruga]

Slow down Monster Hunter Tri from around 400 fps to around 390 fps in menu.

[zlice]

Need For Speed: Hot Pursuit 2 still lags with this PR and #7630 - but with master as of Apr 16 2019 (5c5e6df) just removing the OPCD 32 (LWZ) skip makes it run fine.

Both this and 7630 allow RE0 to use the manhole opener in the train

[JMC47]

What do you mean still lags with this PR? Is there some kind of bug causing it to lag? Or is it just slower?

[JosJuice]

When on dual core, disabling idle skipping or just SyncOnSkipIdle increases the performance in Need for Speed: Hot Pursuit 2 (and sometimes also causes severe FPS/VPS desyncs, from the little I tested). Disabling idle skipping on single core just decreases the performance with no other apparent effect, as expected. So I don't think there's any bug with that game and idle skipping.

[JMC47]

Ah, yeah, it runs completely unsynced and has a chance of crashing. Which is what I wrote in the progress report.

[zlice]

Single core and SyncOnSkipIdle = False, NFS:HS2 is still is unplayable.

The main point I was making - is with master just removing the LWZ chunk in Jit_LoadStore.cpp allows it to run completely fine for me.

This PR removes that chunk, but it still runs like crap.

JMC47 - I'd be interested to know if the same is true for Xenoblade Chronicles. And if Fire Emblem RD has any hit.

[JosJuice]

Single core and SyncOnSkipIdle = False, NFS:HS2 is still is unplayable.

Yes, SyncOnSkipIdle has no effect on single core. If you want the fast but unstable behavior, you need to use dual core with SyncOnSkipIdle = False. This is not a bug and will not be addressed by this PR.

[degasus]

@zlice This is the expected behavior on NFS. This is a variable FPS game, so you need SyncGPU. IdleSkipping is just a bad hack around it.

[zlice]

git 5c5e6df
!OPCD32Skip && dualCore == NFS_SUCCESS

git 5c5e6df
git merge #7287
!OPCD32Skip && extraCode && dualCore == NFS_SUCKS

I don't know how else to put this. "I've tried every combo" ? "Will someone else verify" ? What am I saying that is not coming across?

[JosJuice]

Your description of how this PR behaves is correct – the disagreement is that we don't think that behavior is a problem.

This PR does two things: It removes the old idle skipping code (which your comment calls "OPCD32Skip"), and adds new idle skipping code in new places (which your comment calls "extraCode"). In order to not have any idle skipping, neither of those two must be present. But there is no good reason to remove idle skipping entirely, because you can get the effect that you want by disabling SyncOnSkipIdle instead.

Please stop commenting about Need for Speed: Hot Pursuit 2. It's derailing the discussion of this PR.

[zlice]

OK, I /think/ I know where everyone is coming from with SyncOnSkipIdle and IdleSkip relation.

I believe the slow down may be caused from WriteExceptionExit(). MerryMage said it "does not flush 'anything' " (not entirely sure what that means).

Not sure if that's too far off from this PR, or helpful, or just the way that function is.

Can test WriteExceptionExit() calls later if it helps.

[JosJuice]

I believe the slow down may be caused from WriteExceptionExit(). MerryMage said it "does not flush 'anything' " (not entirely sure what that means).

The problem with WriteExceptionExit that MerryMage explained is what leads to freezes in Resident Evil 0 and CSI: Hard Evidence in master, but it does not affect the performance in any meaningful way.

[merryhime]

In principle, looks good to me.

Need to perhaps consider what happens when debugging though.

[JosJuice]

With the recent changes to the PR, CSI: Hard Evidence works with cached interpreter (in addition to this PR making it work with Jit64 and JitArm64 earlier). However, it seems like regular interpreter freezes during one of the prerendered videos, like before this PR. (It also takes something like 20 minutes to just get to the start of the prerendered videos, compared to 25 seconds when running with JIT at full speed...)

[degasus]

@MerryMage I think the debug helpers are not needed here. Idle is called when the idle loop is fully executed, so both stepping and breakpoints prevent the idle logic here.

[merryhime]

@degasus Fine with me.