Question 1

Why does sceKernelOpen / open() crash with 'invalid access mode' exception or create a file with O_CREAT|O_EXCL|O_DIRECTORY flags?

Accepted Answer

This is fixed in PR #6857 (commit 0b6486704) — update to a build that includes it. Previously, passing access mode 3 (`(flags & O_ACCMODE) == O_ACCMODE`) to `open`, `_open`, `openat` or `sceKernelOpen` threw an uncaught `std::invalid_argument` from `MapFlags` and killed the process, and `O_CREAT | O_EXCL | O_DIRECTORY` incorrectly created a regular file (on Windows via `CREATE_NEW`) instead of being rejected. After the fix, both invalid flag combinations are rejected with `EINVAL` before any path lookup, matching FreeBSD 11.4 behavior: `sceKernelOpen` returns SCE error `0x80020016`, and the POSIX entry points return -1 with `errno` 22. Nothing is created on a rejected open. Application-side workaround if you cannot update: never pass access mode 3 (use only `O_RDONLY` 0, `O_WRONLY` 1, `O_RDWR` 2) and do not combine `O_CREAT | O_EXCL` with `O_DIRECTORY`.

Question 2

How to fix 'error while loading shared libraries: libcohtml.Prospero.prx: cannot open shared object file' when launching a PS5 game converted with AnyPS5?

Accepted Answer

This error means a game-bundled module (.prx) was not converted by the relinker along with the executable. Do NOT copy the .prx into the `libs/` folder — that directory is only for AnyPS5's own libraries, and doing so causes 'invalid ELF header' (raw SELF) or 'ELF file OS ABI invalid' (unwrapped but still PS5 ELF) errors.

Fix:
1. Unwrap every `.prx` the game ships using `tools/unwrap_self.py`.
2. Re-run the relinker with `--module-dir` pointing to the folder containing the game's .prx files. The relinker auto-detects modules only in `sce_module/`, `sce_modules/`, or `prx/` next to the input executable; if the .prx sits in the game root, pass it explicitly:
   `relinker --to-intel source/input.elf app.elf --module-dir .`
3. Launch `./app.elf` again — the converted module will now be found.

Question 3

How to fix 'multisampled DCC target reuse requires watched guest memory' error in AnyPS5 AGC (agc_driver_msaa_dcc_clear_4)?

Accepted Answer

This error appears when a 4x MSAA DCC refill resolve loses write-watch on its color range because an aligned grouped host import spans both the resolve destination and the live native color source. It was introduced by PR #6457 (commit 524259954) and reproduces on Windows (e.g., RTX 5080), while 2x/8x pass.

Fix: Apply PR #8169. When write watching is active, an aligned grouped import now requires the full block to remain watched; otherwise it falls back to importing only the requested range. The PR includes a Windows regression test as a separate commit.

Diagnostic workaround (test-only, not for production): call `AgcDriver::Graphics::SetHostImportWindow(BlockBytes)` with `BlockBytes=0x10000` at the start of `DccRefillTests` so adjacent allocations are not grouped into one import. This makes the 4x case pass but is only an isolation control.

To reproduce/verify: `cmake --build build --target libs relinker agc_driver_alpha_to_coverage_tests` then `ctest --test-dir build -V -j1 --timeout 30 --no-tests=error -R '^agc_driver_msaa_dcc_clear_4$'` in three fresh serial processes with `ANYPS5_REQUIRE_VULKAN=1`.

Question 4

Why does agc_driver_mul_lo_u16_high_half fail on AMD's Windows driver (RX 6700 XT) and how to fix it?

Accepted Answer

This is an AMD Windows driver compiler bug exposed by the constant-folding change in #7673, not a folder bug. When both `v_mul_lo_u16` factors are already masked to 16 bits (`OpBitwiseAnd x, 0xffff`), #7673 folds away the redundant `OpBitFieldUExtract(x, 0, 24)`. AMD's compiler then treats the product of two known 16-bit values as 16-bit and drops the `& 0xffff` on the result, so the GPU stores the full 32-bit product (e.g. 0xfffe0001 instead of 0x00000001). Workaround: revert #7673 with `git revert -m 1 1b0ff1e15`, which restores the `OpBitFieldUExtract` factor form and passes 3/3. Permanent fix (landed in #8280, this issue is a duplicate of #8266): keep the 24-bit factor extract in `vMulLoU16` and `vPkMulLoU16` out of #7673's `BitFieldUExtract` fold, since that pre-fold form matches what the hardware does and compiles correctly on the AMD Windows driver. Note that rewriting the low half as `BitFieldUExtract(product, 0, 16)` or a u16 truncation does not help, because the constant folder turns both back into the same `& 0xffff`.

Question 5

How to fix 'undefined symbol: __aps5_get_pending_module_args_nid_no_patch' error when running AnyPS5 converted output?

Accepted Answer

This happens because the online converter's deployed relinker is newer than the v0.1.1 libraries it bundles: the relinker emits guest modules importing `__aps5_get_pending_module_args_nid_no_patch` and `__aps5_set_module_init_result_nid_no_patch`, but v0.1.1's `libkernel.prx` doesn't export them. Workarounds: 1) Replace the bundled `libs/` folder with PRX libraries built from the project's main branch (the symbols are defined there in `core/libs/prx/libkernel/Module/src/Module.cpp`). 2) Verify the fix with `nm -D --defined-only libs/libkernel.prx | grep aps5` — the symbols should now be listed. 3) Always launch with `LD_LIBRARY_PATH=libs ./eboot.bin.elf`, since v0.1.1 libraries have empty RUNPATH and transitive dependencies (e.g. `libSceMouse.prx: cannot open shared object file`) otherwise fail to resolve. Windows libraries from the same pinned release are affected too.

AnyPS5

Core Features

What It Can't Do

Use Cases

Tags

Getting Started

Similar Projects