simonbbby measured DIM 2D image_store through 8x8 cube arrays on RDNA2
(gfx1036): 32_UINT and 32_FLOAT stores with BASE_ARRAY 0 and 6 write that
face and nothing else.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
A DIM 2D image_load through a cube T# already reads texel (x, y) of the
T#'s BASE_ARRAY face (#4139, measured on RDNA1). A DIM 2D image_store to
a cube T# had no matching runtime mode and threw "image descriptor is
incompatible with the static runtime image interface". Crimson Desert
writes a 16_16_16_16_FLOAT cube this way from a compute shader.
A mip-less image_store to an image the program only stores to now takes
the same face mode, writing texel (x, y) of the BASE_ARRAY face, the
face the measured load reads. Stores were not measured on hardware; the
debt entry says so. Formats that store through a conversion (SINT) keep
throwing.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The Rosetta conversion limits were measured on an M1 running macOS 15.3.1
and an M5 Max. A survey on an M5 running macOS 26.4 executes ANDN, RDRAND,
the rest of BMI1 and BMI2, LZCNT, PREFETCHW, CLFLUSHOPT, AVX, AVX2, FMA,
F16C and MOVBE while CPUID reports none of them, and raises an illegal
instruction for RDSEED, CLWB, RDPID, ADCX and ADOX.
`Path.write_text(newline=...)` and `zip(strict=True)` were added in
Python 3.10. macOS ships 3.9.6 as /usr/bin/python3, the interpreter CMake
finds when no newer one is installed, so `prepare_release_notes` raised
TypeError when the release workflow wrote its notes and the
`pr_overlap_tools`, `release_package` and `linux_fixed_base` tests failed
on a stock macOS host. Writing the encoded text keeps the newline
translation off on every host, and the dynamic tag counts are compared
before the pairs are walked.
Cult of the Lamb (PPSA06465, #2686) stops at start-up on the first one:
FAIL: unresolved ELF import pXJh3aVk8Ks from libSceContentDelete.prx
Both exports have been on main without an implementation (#2740); the
call itself has not been observed yet.
Orbital (cc408367, tools/ida/db_types.json:541-542) and SharpProspero
(5dfdb4b0, Interop/Content/ContentDelete.cs:25-42) agree on the
signatures: a 64-bit SceContentSearchContentId and a UTF-8 path. The
content library is empty on the host, since libSceContentExport exports
nothing into it, so no id or path can be found. SharpProspero gives only
NoPermission (0x809D5006) and no public source gives the not-found code,
so both calls throw with the id or path named once the null path and the
initialization are checked, like the "not in the host content library"
throws of #3724. sceContentDeleteById moves from
guest_content_unimplemented to the new guest_content_delete test.
NIDs pXJh3aVk8Ks and qC3QW+AltHs match tools/nid_names.py and the shadPS4
aerolib list.
Co-Authored-By: Claude Fable 5.1 <[email protected]>
(cherry picked from commit 928184824a4acdf36a58287034bff8154c861835)
The bundled PSNCore.prx of PPSA06888 calls sceNpTrophy2GetRewardIcon
with (context, handle, reward_id, buffer, size): once with a null buffer
to read the size, then with a buffer of that size. The function still
throws because the reward icon data is unknown.
Co-Authored-By: Claude Haiku 5.5 <[email protected]>
fopen_s returned ENOENT for every failed open, including an invalid mode, a directory opened for writing and the loop and long-name cases. C11 K.3.5.2.1 only asks for a nonzero value; Microsoft's CRT, which shares Dinkumware's library, returns errno. fopen_s now returns the errno fopen set.
PPSA28997 (IL2CPP) calls sceLibcBacktraceGetBufferSize and
sceLibcBacktraceSelf. On Linux the host call stack is captured with
backtrace and each frame is resolved to its module and offset with
dladdr, then written as a linked list of frame records. The record
layout is inferred and listed in TechnicalDebt. Windows throws.
v_pk_add/mul/fma/fmac/min/max_f16 threw in f16 denormal modes 0-2. On
RDNA2 (gfx1031) bit 6 clear flushes each denormal input lane to a zero
of its sign, and bit 7 clear flushes an add result below 2^-14 and a
mul or fma result whose exact value rounded to 11 significant bits
with an unbounded exponent is below 2^-14, as the scalar forms do;
min/max flush only their inputs. Packed f16 still throws for f16
rounding other than nearest even.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
On RDNA2 (gfx1031) f16/f64 denormal modes 0 and 2 flush the denominator
and numerator of v_div_fixup_f64 to a zero of the same sign and keep a
denormal quotient and result, as v_div_fixup_f32 does with the f32
field. The translation used them unflushed, so 0 / 2^-1074 gave 0
instead of the default NaN.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
v_fma_mix_f32 used its f16 sources unflushed in every mode. On RDNA2
(gfx1031) f16 denormal modes 0 and 2 flush each f16 source to a zero
of its sign, whatever the f32 denormal field, so
v_fma_mix_f32 0, 0, 0x0001 (all f16) is 0 there instead of 2^-24.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
v_fma_f16, v_fmac_f16, v_fmamk_f16 and v_fmaak_f16 ignored the
FLOAT_MODE f16 denormal field. On RDNA2 (gfx1031) at f16 round to
nearest even, bit 6 clear flushes every denormal input to a zero of its
sign, and bit 7 clear flushes the result when the exact product-sum
rounded to 11 significant bits with an unbounded exponent is below
2^-14, the rule v_mul_f16 already follows. The f16 FMA path now flushes
its inputs and its round-to-odd result in those modes; the magnitude
test is shared with float16Binary as flushTinyF16Value.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Both ignored the FLOAT_MODE f16 denormal field. On RDNA2 (gfx1031)
v_cvt_pkrtz_f16_f32 flushes each denormal half result to its signed zero
when bit 7 of FLOAT_MODE is clear, and v_pack_b32_f16 flushes each
denormal half input when bit 6 is clear. Modes that keep them and
shaders without a known float mode are translated as before.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
On RDNA2 (gfx1031) f16 denormal modes 0 and 2 flush the denominator and
numerator of v_div_fixup_f16 to a zero of the same sign and keep a
denormal quotient and result, as v_div_fixup_f32 does with the f32
field. The translation used them unflushed in every mode, so 0x0001 / 0
gave +infinity instead of the default NaN.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
