v_mov_b32 accepted SDWA destination selectors for the words only; a byte
destination (dst_sel BYTE_0..3) threw 'VOP1 SDWA destination selector is not
supported'. The write itself already handles bytes and every dst_unused mode
(TranslationContext::writeRawU32). GTA V aborted during boot on such a move
(dst_sel BYTE_0, dst_unused UNUSED_PRESERVE) in one of its eboot compute
shaders. The error now names the selector, opcode and pc. The SDWA destination
execution test covers BYTE_0 and BYTE_2 with UNUSED_PRESERVE and BYTE_1 with
UNUSED_PAD.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Two diagrams in docs/dev/ARCHITECTURE.md: how the relinker and the NID-patched system libraries produce a native program, and the graphics path from command buffers through the shader recompiler to Vulkan. README only gains a link.
Co-Authored-By: Claude <[email protected]>
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) <[email protected]>
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) <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
The descriptors of one surface share its storage image through the
surface key, which includes the level count. A view past MAX_MIP
counts the extra levels, so its storage image was a second image of
the same memory, and the two flushed and re-uploaded each other every
frame (PPSA21564 writes level 6 of each 1920x1080 bloom chain after
building levels 1 to 5 through MAX_MIP 5 views).
A surface once viewed past its allocated levels now keeps a single
image holding the extended chain, and its other descriptors look that
image up; the allocated-level image it replaces is evicted with its
results stored. The extra levels lie in the allocation (the decode
proved that), so levels 0 to MAX_MIP keep their layout and the views
of them read the same texels.
PPSA21564 ends each of its two 1920x1080 RGBA16F bloom downsample
chains (MAX_MIP 5) with a compute pass that stores level 6 through a
view of levels 6..6, every frame from the PS logo on. The descriptor
decode threw for such a view.
GFX10 uses MAX_MIP only to place the levels: a level's address comes
from the levels below it, and a level in the mip tail is a fixed slot of
the tail block counted from the first tail level. A level past MAX_MIP
is addressed the same way, so when the chain extended to the view's last
level keeps every allocated level, the tail and the surface size
unchanged, the view reaches that slot inside the surface's allocation.
addrlib (GFX10, Navi10 with 16 pipes) computes the same 0x1640000-byte
layout for 6, 7, 9 and 11 levels of this surface, with level 6 in the
tail at (0, 32). The view then decodes with the extended chain over the
same guest bytes. Views whose extra levels would move the allocated
ones, such as linear chains or chains without a tail, still throw.
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 <[email protected]>
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 <[email protected]>
Any other field or value throws. The existing s_setreg_b32 no-op is
recorded under Functional technical debt instead of silent stubs.
Co-Authored-By: Claude <[email protected]>
s_cmovk_i32 writes the sign-extended 16-bit immediate when SCC is set.
s_version is a no-op marker. s_setreg_imm32_b32 takes its value from a
literal dword and is ignored like s_setreg_b32; both are now listed as
silent stubs in TechnicalDebt.
Co-Authored-By: Claude <[email protected]>
sceAudioPropagationSourceRender takes the system, an array of RenderInfo
descriptors and their count: PPSA21564 and PPSA21567 pass one RenderInfo
{0x010107d6, 0x30} per call, with the source handle at +0x10, its output
buffer at +0x18, the buffer size in bytes at +0x20 and the word 2 at
+0x28, once per audio grain for each propagated source.
Without acoustic propagation a source contributes nothing, so each
output buffer is zeroed for its size. Every RenderInfo is checked first
(descriptor, a live source of this system, a non-empty output), and a
count of 0 or a format word other than 2 throws, as neither has been
observed.
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
The first draw into a target whose DCC keys hold the register clear code
materializes the clear. The GPU clear of the resident image refuses while a
recorded write to the keys is still pending, so whenever the title's own key
fill had not run yet the clear went the CPU way: the clear texels stored
into guest memory (16 MiB for PPSA21564's normal G-buffer) and the image
uploaded again. With the occlusion dumps no longer draining the device, the
fill is usually still pending at that draw, and that was every frame of
PPSA21564's level.
The draw now waits for the recorded writes of the key range alone, checks
the keys again, and clears on the GPU when they still hold the register
code, as it did when the fill had already landed.
Dean