The PS5 references count save data differently from the PS4: SharpEmu
uses a 64 KiB block, and SharpEmu and KytyPS5 allow 48 to 16384 blocks
per save, which at 64 KiB a block is 3 MiB to 1 GiB, the PS4's byte
range. The module used the PS4 values, 32 KiB blocks and a 32768-block
maximum. At 64 KiB a block, sceSaveDataDirNameSearch and
sceSaveDataGetMountInfo therefore counted up to twice the blocks a
save's files use, and a save without a recorded size reported 32768
blocks, which is 2 GiB.
The search test now expects 64 KiB blocks and the 16384 maximum, and
the block accounting gets its own technical debt entry.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
v_mad_f32, v_mac_f32, v_madak_f32 and v_madmk_f32 exist only on gfx10.1,
so the RDNA2 oracle can't measure them. Measured on gfx1010 (RX 5700 XT)
in wave32 at IEEE 0 and 1, f32 denormal modes 0 to 3 and round modes 0
to 3, and in wave64, they round the product before the add, flush f32
sources, product (tiny after rounding with an unbounded exponent) and
result in every mode, and choose NaN results like the fma forms.
The behaviour stays left to the driver: translating it on every lane
cost about 15x main on the RX 5700 XT and 23x on an RTX 3070, and a
branch around the exact path still about 6x, so the lowering waits for
the SPIR-V float controls of #981.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A title can relocate a registered shader header, and the register, special and
semantic arrays it points at, into memory of its own and resolve the ABI with
that copy (Astro's Playroom, PPSA01325, #2914). SameHeader accepted such a copy
only while every pointer inside it stayed put, so a moved array left the
resolution throwing "refers to a replaced shader header".
Accept the copy when every array it names still holds the registered bytes: the
registered header then decodes what the copy describes, nothing is copied and
ShaderSnapshot stays immutable. A copy whose arrays differ or are unreadable
still throws.
Adds what testers reported in the Q&A thread and what our own runs
showed: confirming the GPU and the cache state, AC power and refresh
rate, the Windows exit code of an uncaught exception, Windows session
and scheduled-task start, Unity module placement and the MinGW DLLs,
a section on measuring performance, and the report fields.
Drops APS5_NO_MOUSE_CAPTURE, which main no longer has.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BywPXoZACVi8ALV4JKvuPZ
A report names the GPU as the log's `Selected GPU name=` line shows it, since AnyPS5 can fall back to llvmpipe without presentation support or pick another adapter on Windows (suggested by odntht on #6627).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BywPXoZACVi8ALV4JKvuPZ
Draft guide for running a title on AnyPS5: the build and conversion steps,
the environment variables to set for each run, what to read in the log and
the exit code, how to tell a stall from a crash, Windows-specific notes, and
what to include when reporting a result. Maintainers are asked what they need
from it in the Q&A discussion linked from the page.
Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BywPXoZACVi8ALV4JKvuPZ
An indirect draw drained queue 0's draw pipeline on entry and recorded every
record on the worker, so titles that draw mostly through DRAW_INDIRECT,
DRAW_INDEX_INDIRECT and DRAW_INDEX_INDIRECT_MULTI got no overlap between the
worker's capture of one draw and the committer's recording of the previous.
The draw now drains only when its records or its count overlap a write still
queued on the pipeline. Records drawn inline drain first, so they stay in
order, and the last drawn record is queued like a direct draw, carrying its
write ranges. APS5_NO_PIPELINED_INDIRECT=1 restores the drain on every
indirect draw.
agc_driver_pipelined_indirect_draw holds the committer with a blocking item and
checks that two indirect draws queue behind it and draw what a direct draw
does, and that a draw whose record a queued label writes waits for it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The saver thread took the snapshot lock with a blocking exclusive lock. Behind
a pipeline creation that runs for minutes (an NVIDIA compile of a 1.5M-word
compute pipeline), the queued writer made the shared_mutex hold every later
pipeline creation on every queue until the compile ended. The periodic save now
tries the lock and waits for the next interval when it is busy; SaveNow and the
teardown save still wait.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
