Jit sparse continuation

[LotP1]

More up to date build of the JIT Sparse PR for continued development.
JIT Sparse Function Table was originally developed by riperiperi for the original Ryujinx project, and decreased the amount of layers in the Function Table structure, to decrease lookup times at the cost of slightly higher RAM usage.
This PR rebalances the JIT Sparse Function Table to be a bit more RAM intensive, but faster in workloads where the JIT Function Table is a bottleneck. Faster RAM will see a bigger impact and slower RAM (DDR3 and potentially slow DDR4) will se a slight performance decrease.
This PR also implements a base for a PPTC profile system that could allow for PPTC with ExeFS mods enabled in the future.
This PR also potentially fixes a strange issue where Avalonia would time out in some rare instances, e.g. when running ExeFS mods with TotK and a strange controller configuration.

[github-actions]

Download the artifacts for this pull request:

• ryujinx-Release-1.2.0+5f138e6-linux_arm64
• ryujinx-Release-1.2.0+5f138e6-linux_arm64-AppImage
• ryujinx-Release-1.2.0+5f138e6-linux_x64
• ryujinx-Release-1.2.0+5f138e6-linux_x64-AppImage
• ryujinx-Release-1.2.0+5f138e6-macos_universal
• ryujinx-Release-1.2.0+5f138e6-win_x64

GUI-less

• nogui-ryujinx-Release-1.2.0+5f138e6-linux_arm64
• nogui-ryujinx-Release-1.2.0+5f138e6-linux_x64
• nogui-ryujinx-Release-1.2.0+5f138e6-macos_universal
• nogui-ryujinx-Release-1.2.0+5f138e6-win_x64

Only for Developers

• ryujinx-Debug-1.2.0+5f138e6-linux_arm64
• ryujinx-Debug-1.2.0+5f138e6-linux_arm64-AppImage
• nogui-ryujinx-Debug-1.2.0+5f138e6-linux_arm64
• ryujinx-Debug-1.2.0+5f138e6-linux_x64
• ryujinx-Debug-1.2.0+5f138e6-linux_x64-AppImage
• ryujinx-Debug-1.2.0+5f138e6-macos_universal
• nogui-ryujinx-Debug-1.2.0+5f138e6-macos_universal
• nogui-ryujinx-Debug-1.2.0+5f138e6-linux_x64
• ryujinx-Debug-1.2.0+5f138e6-win_x64
• nogui-ryujinx-Debug-1.2.0+5f138e6-win_x64

[LotP1]

the 2 extra builds are up on the Discord server in the #testing-jitsparse channel.
the files were too big for github.

[LotP1]

pushed 2 new commits
you can now choose between GiantBlock (better for high end) and TinyBlock (better for low end) by using the LowPowerPPTC option in settings

Default (aka GiantBlock) is a bit weird to launch, it causes a bug we haven't fixed yet, but if you spam click the emulator window while it's starting the game it should successfully boot

[extherian]

I have been unable to boot the giant block version by any means, clicking the emulator window just causes it to lock up.

[LotP1]

updated locales and rebased for Canary 1.2.42

[LotP1]

Rebased for Canary 1.2.47

[LotP1]

Rebased for Canary 1.2.48

[Goodfeat]

is it possible to implement switching between the new and old jit compilation method?

[LotP1]

is it possible to implement switching between the new and old jit compilation method?

No.
I am aware that some games are currently having issues with the new JIT Sparse feature, like SSBU, and i am actively looking into fixing those issues at the moment in #319.

[Goodfeat]

No.

Very sad, I'll try to come up with something then. Unfortunately, despite the fact that this update subjectively makes games more stable, the update hits the performance for older systems.

[GreemDev]

No.

Very sad, I'll try to come up with something then. Unfortunately, despite the fact that this update subjectively makes games more stable, the update hits the performance for older systems.

Performance on older systems is not something we care about.

[LotP1]

No.

Very sad, I'll try to come up with something then. Unfortunately, despite the fact that this update subjectively makes games more stable, the update hits the performance for older systems.

Yeah we know that, but the goal of Ryujinx is to work the best out of the box so we'd rather not make a million options, and this should only affect DDR3 and very slow DDR4 systems which aren't that common anymore.
You can still run with the old JIT Function Table by using the Software setting for memory management, but idk if that would give you a performance boost.

[GreemDev]

You can still run with the old JIT Function Table by using the Software setting for memory management, but idk if that would give you a performance boost.

It wouldn't; Software memory mode is a massive performance hit.

[KeatonTheBot]

No.

Very sad, I'll try to come up with something then. Unfortunately, despite the fact that this update subjectively makes games more stable, the update hits the performance for older systems.

Performance on older systems is not something we care about.

@LotP1 @Goodfeat Primarily, no. Performance shouldn't be the focus of an accuracy-based emulator, but opportunities to increase performance shouldn't be frowned upon unless it sacrifices accuracy. IMO: Accuracy first, then performance improvements if possible. That's not always feasible, but they shouldn't be written off.