Per review: scePadSetAngularVelocityDeadbandState now returns PAD_ERROR_INVALID_HANDLE for a
handle other than PAD_HANDLE, like the neighbouring setters. Enabling the dead band still throws,
because the angular-velocity reading path does not apply the filter (that would change input, not
UI, so it is not a silent stub); disabling it succeeds, which matches the unfiltered readings.
The test checks the disabled call, the bad handle, and no longer asserts the enabled path.
scePadSetAngularVelocityDeadbandState was the last throwing stub in libScePad. It toggles a
dead-band filter on the controller's angular-velocity (gyro) readings; the reading path does
not apply that optional filter, so the call succeeds and does nothing, as it does in shadPS4.
Extends the existing guest_pad test with the two enable/disable calls. It fails on main (the
stub throws) and passes with the change.
addrlib sizes a non-tail level with ShiftCeil; the layout used the image's
rounded-down extent, so volumes with a non-power-of-two width or height (33x20x12
in the new test) got a different layout.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
3D textures with more than one mip level were refused. Each slab of
blockDepth slices of a thick (SW_4KB_S / SW_64KB_S) volume now holds the
whole mip chain, smallest level first and level 0 last, as 2D chains are
laid out. A level's depth halves per level, so the texture loops skip the
slices a level does not have. Thin 3D (D/R 64KB_X) chains use the 2D mip
layout per depth slice. Thick mip tails still throw.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Decode VOP3b 0x177 and translate it next to v_mad_u64_u32: the high half of
the product comes from SMulHi, and the carry-out is the sign of the exact
sum (bit 64 of the sign-extended product plus the sign-extended addend), as
measured on RDNA2 hardware.
Co-Authored-By: Claude <noreply@anthropic.com>
Loads at fs:1 through fs:0x27 read tcb_dtv and tcb_thread on the FreeBSD layout, which the Windows thread control block does not model, so they returned zero. Accept only the TLS block, fs:0 and the stack guard at fs:0x28, and fail the relink for the rest.
OpFConvert leaves NaN payloads to the driver; NVIDIA returns its own.
v_cvt_f64_f32 now shifts the f32 payload left by 29 and v_cvt_f32_f64
keeps the top 23 payload bits, both quieted, as RDNA does (60/60 NaN
conversions measured on RDNA2). F64NanConversions covers both with the
hardware rows.
Co-Authored-By: Claude <noreply@anthropic.com>
The Vulkan precision table defines GLSL.std.450 Fma as "inherited from
OpFMul followed by OpFAdd", so a driver may round twice. RADV fuses it,
the lavapipe in CI (Mesa 25.2.8, LLVM 20) does not, and F64Arithmetic
failed there on the fma rounding-error row.
v_fma_f64 is now emulated with operations Vulkan requires to be
correctly rounded: the operands are scaled to exponent 0, the product is
split exactly (Dekker), added to the addend with TwoSum, the low parts
are summed with round-to-odd and one final round-to-nearest gives the
fused result (Boldo and Melquiond). The result is scaled back by two
exact powers of two. Inf/NaN, zero factors and subnormal inputs take the
mul + add path, an addend 2^60 larger than the product is returned as
is. Matches the hardware on all 13253 fma results captured for #446 and
an exact model on 300000 random inputs incl. ties.
NaN results of add, mul and fract are also chosen on the bits (first NaN
input quieted, otherwise the default NaN) since Vulkan does not specify
which NaN an operation returns.
Co-Authored-By: Claude <noreply@anthropic.com>
Decode and translate v_add/mul/fma/min/max/ldexp_f64, v_trunc/ceil/floor/
rndne/fract_f64, v_frexp_mant/exp_i32_f64 and the f64 <-> f32/i32/u32
conversions. f64 values stay as their raw bits (U64) in the IR and are
bitcast to double in SPIR-V, which needs the Float64 capability: the
device enables shaderFloat64 when it also preserves signed zero, inf and
NaN for 64-bit floats, and the shader declares SignedZeroInfNanPreserve 64.
Semantics measured on RDNA2 hardware (8209 inputs per op): literals are
the high dword, the 1/(2*pi) inline constant is the exact double,
omod is ignored, clamp maps NaN to +0, min/max quiet a
signaling NaN and drop a quiet one, NaN results are quiet, and the
integer conversions saturate with NaN -> 0. Truncation, rounding and
ldexp are done on the bits so they do not depend on the driver: lavapipe
returned wrong results for f64 RoundEven and Trunc, and GLSL Ldexp is
undefined past +-1024. Fma is NoContraction so RADV keeps it fused.
Co-Authored-By: Claude <noreply@anthropic.com>
Close releases the port and its host device; Input and Close on a port
that is capturing return BUSY. Format codes follow the PS5 SDK bindings
(SharpProspero) and KytyPS5: 1/2 S16 mono/stereo, 0x11/0x12 float.
Co-Authored-By: Claude <noreply@anthropic.com>
sceAudioInOpen validates the port and opens the default SDL recording
device in the requested format; sceAudioInInput returns one grain of
captured samples, padded with silence when the device falls behind and
keeping at most four grains of latency. Without a recording device a
port reports DEVICE_NONE in sceAudioInGetSilentState and delivers
silence at its sample rate.
Co-Authored-By: Claude <noreply@anthropic.com>
Decode VOP3 0x172, 0x173 and 0x175. Each op slides a 4-byte window over the
64-bit src0 and adds the byte SAD against src1 to the matching 16-bit
(pk_u16) or 32-bit (mqsad_u32) field of src2; the mqsad forms skip zero
reference bytes. Sums wrap per field, as measured on RDNA2 hardware.
Co-Authored-By: Claude <noreply@anthropic.com>
SHA256RNDS2/MSG1/MSG2 with a memory source made `--to-intel` fail the
whole relink. The stub now spills a scratch xmm, loads the operand into
it with MOVDQU (AMD does not fault on a misaligned SHA operand, so the
unaligned load keeps that behaviour) and runs the register-form
lowering. RSP-based operands get the spill depth added to their
displacement. RIP-relative operands still fail: the stub runs at a
different address.
Co-Authored-By: Claude <noreply@anthropic.com>
With uniform inputs every lane writes to the same target lane, so only
that lane receives the value; the two-lane wave64 path must not share it.
Co-Authored-By: Claude <noreply@anthropic.com>
ds_permute_b32 is the forward (scatter) counterpart of ds_bpermute_b32:
every active lane sends its data to lane ((addr + offset) >> 2) & 31 of
its wave. As measured on hardware, the highest sending lane wins, an
active lane nobody writes to gets 0 and inactive lanes neither send nor
receive. It lowers to one shuffle of the data, address and EXEC bit per
source lane, using the same wave base as ds_bpermute_b32.
Co-Authored-By: Claude <noreply@anthropic.com>