The driver copies a submission's packets when it is submitted, but
SET_SH_REG_INDIRECT, SET_UCONFIG_REG_INDIRECT and SET_CONTEXT_REG_INDIRECT
read their (offset, value) lists from guest memory only when the queue
worker reaches the packet. A title that reuses its per-frame memory once
it expects the GPU to be done with it can rewrite a list in between, and
the worker then throws on the data it finds there ("extended register
semantics are not implemented (offset dword 0x3a888889)").
The lists are now read with the packets, after validation, in Submit and
for a rewind tail, and the worker writes the registers from that copy.
Pm4::Execute keeps reading the list itself for direct callers.
PPSA21402 (Balatro) keeps three frame slots and does not wait for the GPU
before reusing one: its slot labels start at 0xffffffff and the GPU only
ever writes 0xffffffff to them, so the poll before a slot is reused never
blocks. When the worker falls more than two frames behind, the title
writes per-draw constants over a SET_CONTEXT_REG_INDIRECT list the worker
has not read yet.
The console's PFP reads the list when it reaches the packet; the
difference is recorded in TechnicalDebt.md.
Both return -1/EINVAL: FreeBSD kern_mprotect (sys/vm/vm_mmap.c) maps only
PROTECTION_FAILURE, RESOURCE_SHORTAGE and OUT_OF_BOUNDS to their own errno, so
KERN_INVALID_ADDRESS falls to EINVAL.
Co-Authored-By: Claude <[email protected]>
mprotect changes the protection of guest memory through the same path
as sceKernelMprotect and reports failures through errno: EINVAL for a
null or overflowing range or a range the allocation tracker rejects,
ENOMEM when allocation fails. A zero length succeeds.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The VA_ARGS parameter list and VarArgsAbi.hpp (RegSaveArea, FillRegSaveArea,
BuildVaList and the Xmm alias in SimdTypes.hpp) were only used by the four
Linux exports that now take their arguments with va_start.
guest_formatting_tests was built on Linux but registered with ctest on
Windows only, so the Linux printf and scanf exports had no coverage: on main
the test fails there at its first vsnprintf check and then crashes in
snprintf with eight integers.
It is registered on every platform now. The %ls checks stay Windows-only,
as glibc reads %ls as 32-bit wchar_t; that gap is recorded in TechnicalDebt.
The Linux vprintf, vsprintf, vsnprintf, vsprintf_s, vfprintf, vasprintf and
vsscanf handed the guest's va_list to the host function, which advanced the
guest's gp_offset, fp_offset and overflow_arg_area. A caller that formats
the same list twice, first to size the output and then to write it, got its
second call's arguments from past the end.
The Windows path reads its arguments from a copy (LibcDetail::FormatArguments)
and guest_formatting checks that vsnprintf leaves the list unchanged. Linux
now does the same with va_copy.
On Linux these four exports took the guest's registers as named parameters
and rebuilt a va_list from them. The register save area held only the
argument registers after the fixed ones, followed by zeros, with gp_offset 0,
so va_arg read the zeros for the remaining integer slots before moving to the
overflow area. overflow_arg_area was the seventh integer parameter, which is
the value of the first stack argument, not its address.
snprintf(buffer, size, "%d %d %d %d", 1, 2, 3, 4) produced "1 2 3 0",
"%s/%s/%s/%s" with four strings produced "a/b/c/(null)", and eight integers
dereferenced the value 4 and crashed. sprintf and sscanf lost their fifth
and sixth arguments, libc_printf its sixth.
They are now variadic functions that use va_start, like printf, sprintf_s,
snprintf_s and printf_s on Linux already do.
Recognize the exact typed pattern-fill kernel and route aligned, nonaliased uniform ranges through existing fill/coherence handling. Preserve control and descriptor bounds, partial dispatch counts, queued labels, and shader fallback for other cases.
Semantics checked on Radeon RX 6600: native RDNA wave32/wave64 typed R32_UINT loads/stores, execution masks, and descriptor bounds (16 cases). Real PM4 tests cover HLE and shader paths, imports and copies, indirect/partial dispatch and GPU-to-label ordering under Vulkan validation. Graphics and PM4 tests pass; Skyrim Helgen save visually checked. 64 MiB copied-buffer fill median reduced from 67.5 ms to 3.8 ms.
Written with AI assistance.
A color target with both DCC and CB_COLOR_INFO.FAST_CLEAR keeps its fast
clear in the DCC keys and fills its CMASK with 0xF (expanded), as radv
does (radv_get_cmask_fast_clear_value) and as PPSA21567 does
(CB_COLOR_INFO 0x10042730, reported on #419). Such targets now decode;
their clear is materialized by the existing DCC path. A DCC target's
CMASK that is not all expanded throws.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Draws into a color target with CB_COLOR_INFO FAST_CLEAR (bit 13) were
rejected. The CMASK keeps one nibble per 8x8 tile: 0 means the tile is
fast-cleared and reads as CB_COLOR_CLEAR_WORD, 0xF means expanded (the
texels hold the color). The texture units and display scanout do not read
it, so a title runs a fast-clear eliminate pass before sampling or
flipping such a target.
DecodeColorBuffer now takes the CMASK address (CB_COLOR0_CMASK and
CB_COLOR0_CMASK_BASE_EXT) and the bytes one nibble per 8x8 tile spans.
Before a draw renders into the target, and in a fast-clear eliminate
pass, a CMASK whose nibbles are all 0 is materialized: the target is
filled with the clear texel (FillClear on its resident image, else
guest memory on the CPU) and the CMASK bytes are stored as expanded,
through the same GPU-ordered store as the DCC "uncompressed" keys
(0xFF either way). The result equals the draw followed by the eliminate
pass. An all-expanded CMASK changes nothing; a mixed one throws, as do
fast clears of DCC, mipmapped, 3D and array targets.
PPSA14632 (LEGO Horizon Adventures) fast-clears its two 3840x2160
display buffers through CMASK, so its final composite draw was dropped
on every frame and only black was presented.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
sceAppContentAppParamGetInt numbers the SKU flag 0 and
USER_DEFINED_PARAM_1..4 as 1..4 (fpPS4 ps4_libsceappcontent). Id 1
returned the SKU flag and 2..5 returned zero. UFC 6 (PPSA23566) checks
that param 1 is its title number, userDefinedParam1 in param.json, and
crashes otherwise. Absent params read as zero.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Read the module layout from the PE image that holds the address. A
relinked image reports its .elf sections as segments and the
eh_frame_hdr recorded in .ehmeta; any other image reports its sections
with memory access and its .ehfram section. The eh_frame_hdr and
eh_frame helpers are shared with the Linux path, and the guest module
info test now also runs on Windows.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
CI configures without ANYPS5_ENABLE_SPIRV_TOOLS, so the shader recompiler never validates or
optimizes the SPIR-V it emits - Recompiler.cpp guards the ValidateAndOptimizeSpirv call on that
macro - and the shader tests lose the blocks that exercise it:
- ShaderMemory.cpp guards five blocks on the macro, including three expectFailure cases that are
the only coverage for rejecting invalid SPIR-V and for rejecting an unsupported Vulkan or SPIR-V
target.
- SpirvOptimizer.cpp includes the SPIRV-Tools headers, so the file is not built at all.
- README.md gives the Spirv-Tools validation as how the recompiler is known to produce valid
SPIR-V, and no job exercises it.
Add the flag to CONFIGURE. Verified with the CI command and the CI device (lavapipe, subgroup 8,
ANYPS5_REQUIRE_VULKAN=1, GALLIUM_OVERRIDE_CPU_CAPS=avx): the full suite passes 371/371 with the
flag on, with the same 20 skips, and agc_shader_memory passes.
SPIRV-Tools is a submodule built from source, so this adds build time to the job. I have not
measured how much; if it is too much, the flag can go on one job instead of the shared CONFIGURE.
A 16-bit PCM block whose num_samples exceed its data starts a stream, and waveform blocks with flag 0x2 append more data to it. The voice outputs silence while it has played all appended data and CONTINUE is set, and ends at num_samples or when CONTINUE is cleared.