SPU: SPURS oriented thread waiting

[elad335]

Optimizations:

• cellRtc functions were called non-stop by the PPU thread which use sys_memory_get_page_attribute internally.
  The writer lock in sys_memory_get_page_attribute was causing SPUs to wait unjustly.
• Fast path without locking VM has been added to sys_rsx_context_iomap.
• Exclude spu_thread::reservation_check address receptacle from writer_lock detection and waiting.
• Fix spu_thread::reservation_check(hash) overload for main and stack memory.
• Add fast path without checking allocation for spu_thread::reservation_check when the address is on the same page as GETLLAR's effective address.

Fixes #14724

[elad335]

Added "SPURS oriented thread waiting" which is gonna replace "Preferred SPU Threads" setting and be active by default.

[elad335]

Special settings tweaked from default:

Clocks Scale: 800%
Vblank Frequency: 480Hz
Frame Limit: Off
Preferred SPU Threads: Auto (as default)

PR:

Master

[digant73]

performance are regressed on some games such as KZ3

PR:

MASTER:

[kd-11]

I don't see the benefit of the double check under lock especially since we expect frame-to-frame the mappings wont actually change. Why not just lock and check once? I feel that would be faster here.

[kd-11]

I've pointed it out before, but get_system_time is unreasonably heavy. Prefer TSC unless real-world precise values are required.

A general note - the spu_info logic (test_and_update_atomic_op_info) in general is quite heavy-handed with all the atomic ops and may eat into performance. The biggest issue I see is that there is no fast-path through this calling sequence (and the corresponding one below). Yes, spurs itself is going to be almost always running task groups but we also observe that in most games the parallel misses themselves aren't too bad with modern processors, though I agree we need something more sophisticated than the quick hack that was the preferred threads option.
This is all theory of course, we'll just have to see if it ends up worth the overhead with the big hitters like RDR, TLOU or killzone titles.

[kd-11]

I think we can abuse vector ops for this sequence and gain implicit atomicity.
Have the spu info as an object of arrays instead of array of objects.
Then you can just load all of them at once and (ab)use vector ops on the vector to figure out how much overlap there is.

On x86 at least, vector ops are atomic as long as they are naturally aligned too so we basically get that for free.

[MsDarkLow]

i9-13900K | RTX 3080
Ratchet & Clank Tools of Destruction - Improved a little bit. 88.3 -> 92.5
God of War 3 - Very small Regression. 62.4 -> 61.0
Sonic Unleashed - Tremendously reduced performance. From a stable 42.4 to very unstable 32.4

Ratchet & Clank

God of War 3

Sonic Unleahsed