iR5900: Reset manual protection counters on emulation reset

[TheLastRar]

Description of Changes

Resets the manual protection counters on emulator reset

Rationale behind Changes

This counters are used to avoid excessive recompilation of blocks that share a page with data see;

pcsx2/pcsx2/x86/ix86-32/iR5900.cpp

Lines 2041 to 2049 in bf8693a

	// Tweakpoint! 3 is a 'magic' number representing the number of times a counted block
	// is re-protected before the recompiler gives up and sets it up as an uncounted (permanent)
	// manual block. Higher thresholds result in more recompilations for blocks that share code
	// and data on the same page. Side effects of a lower threshold: over extended gameplay
	// with several map changes, a game's overall performance could degrade.
	// (ideally, perhaps, manual_counter should be reset to 0 every few minutes?)
	if (!contains_thread_stack && manual_counter[inpage_ptr >> 12] <= 3)

For some currently unknown reason, the initial value of these counters has an observable impact on TAS playback (at least with Jak X)
As these arrays weren't previously cleared, the sequential playback of the same TAS file will playback differently.

Ideally, we would investigate why this has an effect on TAS playback (especially given that these values are not stored in savestates), but I believe these arrays should be reset regardless.

Suggested Testing Steps

This might impact the performance on the second game launched in a PCSX2 session (or a relaunch of the same game)

For TAS playback testing, the following steps is what I've been testing with
Enable Pause on Start and Disable MTVU
Start a game, start input recording (from boot), then unpause
The second tutorial in Jak X is sensitive to this issue
Once recorded, close and reopen the emulator to get a clean state

Start a game, select the recording to play, then unpause
At the end of the recording, stop it and shutdown emulation
Relaunch the game, reselect the recording and unpause
Observe if any differences occur in playback between the 1st and 2nd run.

[Ziemas]

Hmm, interesting.

I guess it makes sense that our JIT might be inherently non-deterministic, because the order in which blocks get recompiled can affect their shape. I'd guess not clearing the manual page tracking results in the page being cleared at a different time which means blocks might be recompiled in a different order.

For example, consider this.

label1:
    nop
    nop
label2:
    nop
    jr $ra

Possible order of operations 1:

• Jump to label1
  • Recompile a block spanning from label1 to the jr instruction.
• Jump to label2
  • Recompile a block spanning from label2 to the jr instruction.
• This results in two overlapping blocks.

Possible order of operations 2:

• Jump to label2
  • Recompile a block spanning from label2 to the jr instruction.
• Jump to label1
  • Recompile a block spanning from label1 to label2
  • Link to label2 block by directly jumping to it.
• This results in two non-overlapping linked blocks.

It's quite possible that this results in different timings or cycle tracking.

At least I think this is what could be going on, I'm not sure i fully understand the JIT.

[kage2051]

This still does not fix the non-determinism when savestates are used though. I guess the content in that array might need storing in savestates, unless there is something else in the JIT for the emulated EE CPU that isn't properly resetted either.

[Ziemas]

The JIT starts from a pretty clean state on savestate load, we don't save emitted code or the state of the block cache. So yeah, there are probably the same issues with savestates too.