## Summary
- fall back from database-applied `SPU Decoder: Recompiler (ASMJIT)` to
`Recompiler (LLVM)` on ARM64 builds during boot
- log the fallback in `fixup_settings()` instead of letting SPU
initialization fail later
## Problem
`Need for Speed: Most Wanted [BLES01659]` receives `SPU Decoder:
Recompiler (ASMJIT)` from the config database. On ARM64 builds that
decoder is unsupported, which caused RPCS3 to abort during SPU
initialization with `Unsupported spu decoder` while the UI remained on
the loading screen.
## Validation
- built RPCS3 locally on macOS Apple Silicon
- booted `BLES01659` through the database config path with the custom
per-game override temporarily removed
- verified the log now shows the ARM64 fallback warning and `SPU
Decoder: Recompiler (LLVM)` instead of the previous fatal error
- observed the title proceed past the old boot blocker into active RSX
program compilation
---------
Co-authored-by: Elad <18193363+elad335@users.noreply.github.com>
I observed under macOS (although the bug seems platform agnostic to me)
that when restarting a game, then subsequently quitting it, I'd get
stuck in a 'restart loop' where the game would restart upon completely
shutting down, and this would repeat every time I tried to close the
game until I gave up & force quit RPCS3. Seems like for whatever reason,
the use of std::move didn't actually guarantee that after_kill_callback
got nuked if at all, so all I've done is take a hammer to the fucker and
manually set it to nullptr after being called.
Co-authored-by: Elad <18193363+elad335@users.noreply.github.com>
Address review feedback on #18701 (cc @elad335): combine the SPU
worker fix from #18701, the SPRX Loader fix from #18703, and three
additional similar W^X leaks discovered while auditing the codebase
for the same pattern. Use Allman-style braces to match RPCS3 coding
style.
Background:
On AArch64 Apple Silicon, MAP_JIT pages enforce W^X per-thread.
pthread_jit_write_protect_np(false) enables write mode and
pthread_jit_write_protect_np(true) restores execute mode. When code
takes an early return or throws between these calls, the thread is
left in write mode, which can cause segfaults on subsequent code
fetches or inconsistent state at thread teardown.
Fixes applied (all gated on __APPLE__):
1. Emu/Cell/SPUCommonRecompiler.cpp - SPU cache worker thread
Add RAII guard so execute mode is restored on worker exit.
2. Emu/System.cpp - SPRX Loader thread
Enter write mode (was missing entirely) so ppu_initialize() and
ppu_precompile() can write to MAP_JIT pages, and pair with an
RAII guard. Reproducer: Red Dead Redemption (BLUS30418) crashes
~12s into boot at 0x300010000 without this fix.
3. Emu/Cell/SPULLVMRecompiler.cpp - SPU LLVM compile path
The compile function enters write mode, then has an early
"return nullptr" path on rebuild_ubertrampoline failure that
skipped the explicit restore. Add RAII guard so execute mode
is restored on every exit path. The existing explicit restore
before the cache-flush asm directives is preserved.
4. Emu/Cell/PPUThread.cpp - PPU LLVM worker thread (operator())
Worker entered write mode but never restored it on operator()
return. Add RAII guard.
5. Emu/Cell/PPUThread.cpp - ppu_initialize() main path
This scope alternates write/execute mode and contains an early
"return compiled_new" at the empty-jits check plus a final
return that both leak write mode. Add RAII guard so execute
mode is always restored on exit. Intermediate explicit
transitions for the symbol-resolver invocation are preserved.
No behavioral change on x86_64 or non-Apple ARM64 (all changes are
inside #ifdef __APPLE__ / #if defined(__APPLE__)).
Supersedes #18703.
Follow up of #18345 to add support (currently only on `Windows`; see
notes below) for playing a PS3 disc game directly from a Blu-Ray Disc
Drive.
### HOW IT WORKS:
- The BD drive can be added as any other game so from `VFS games` or
from `Add Games` menu. In case it is selected from `VFS games`, any
attempt to write files is discarded, e.g. file `Disc Games Can Be Put
Here For Automatic Detection.txt`
- It scans the default redump keys folder `<rpcs3>/data/redump` (it
currently needs to be manually created due it is not yet provided by
rpcs3 installation) to find a matching decryption key
### NOTES:
- Support is currently provided on `Windows` where I can fully test it.
I cannot test under other OS. However, the additions needed for the
other OS are limited only on `fs::file.h/cpp`. In particular inside the
following new functions:
- `bool is_optical_raw_device(const std::string& path);`
- `bool get_optical_raw_device(const std::string& path, std::string*
raw_device = nullptr);`
- Icons etc. are always refreshed (ISO cache cannot be used due `mtime`
on raw device is not available and any cache check would always fail)
- Code in `ISO.h/cpp` needed some rework to properly manage a read on a
raw device (alignment on offset, size and memory is mandatory). The BD
drive needs to be detected as a file, not as a folder
### MINOR FIXES:
- Fixed wrong specifier used in logging on `ISO.h/cpp`
We need to initialize the emu callbacks before creating the main window.
Otherwise CallFromMainThread segs since call_from_main_thread is null.
The same goes for the CallFromMainThread connect in gui_application.
If we create the connection too late, we will simply never wake up the
caller and therefore softlock eventually.
- Some games will load into a different executable from EBOOT.BIN, and
attempting to restore those games from savestate causes the game to
crash immediately.
- This commit repurposes the disc_info field in a savestate generated
from an ISO game to store the running game executable at the time of the
save state.
- Due to GetCallbacks().resolve_path behaviour being reverted in a prior
commit, resolved_path will not have the path to the game executable.
This causes issues when setting argv[0] to the game executable path and
apparently breaks some games which may rely on this value.
- After undoing the changes to do with resolve_path, loading game
updates was broken. This required the condition to be changed to check
for launching_from_disc_archive.
- When attempting to load an update for an ISO game,
inherited_ps3_game_path needs to be set otherwise launching the updated
game will fail.
- An additional check was added to ensure that the inherited vitual game
directory isn't saved as the game path in games.yml.
- Fixed attempting to load an updated ISO game by launching its updated
executable, which can happen when loading a savestate for a game with
updates, the emulator would crash before.
- Unload ISO file when Load() fails, otherwise ISO loading might be
stuck in a broken state.
Antonino Di Guardo