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.
Accept COMP_SWAP STD_REV and ALT_REV on 16_16_16_16 color targets and
map them onto RGBA16 with the same export component mappings used for
8_8_8_8. ALT on 16_16_16_16 is still refused.
Adrià