In 64-bit mode REX.W takes precedence over the 0x66 operand-size prefix,
so the immediate of 81, C7, 69, 68, A9, the 05..3D accumulator forms and
the F7 TEST form stays imm32. The decoder only applied this to B8+r and
returned a length two bytes short for the others.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Add header-only support for end-to-end relinker tests: a minimal PS5
executable builder, a PT_LOAD mapper that applies segment permissions,
and a posix_spawn runner for the relinker binary. Every
core/relinker/tests/e2e/*.cpp becomes its own test, so new tests do not
touch CMake.
The first test relinks an executable with EXTRQ and INSERTQ sites using
--to-intel, maps the output and calls the patched code, which runs both
stubs from their Linux segment and returns through their branches.
Co-Authored-By: Claude <noreply@anthropic.com>
Storage images of a SINT format threw "storage image descriptor uses
an unsupported format"; only write-only 32_SINT was accepted.
The recompiler now writes 16_SINT, 8_8_SINT, 32_SINT, 16_16_SINT,
8_8_8_8_SINT, 32_32_SINT, 16_16_16_16_SINT and 32_32_32_32_SINT
storage images with the Uint numeric class. 8- and 16-bit components
are saturated (EmitFormatStoreComponent) and 32-bit ones stored
unchanged, as measured on RDNA2 (gfx1035); image_store_pck stores
32-bit components unchanged too. The driver binds these surfaces
through a cached view of the same-size UINT format.
8_SINT, 32_32_32_SINT, the packed SINT formats (11_11_10, 10_11_11,
2_10_10_10, 10_10_10_2), D16 stores, packed stores of 8- and 16-bit
components and atomics other than 32-bit ones on 32_SINT and 64-bit
ones on 32_32_SINT still throw. New test: agc_driver_image_store_sint,
with DST_SEL X,Y,0,1 on the two-channel formats, as with X,Y,Z,W the
hardware writes channel 1 from the W data slot (TechnicalDebt).
NVIDIA 610.62 cannot sample R8G8_SRGB, and lavapipe can sample neither
it nor R8_SRGB, so an 8_8 sRGB T# made an image the device does not
support: creating it crashes the NVIDIA driver and lavapipe loads zeros.
The device's format support is read once. An 8 or 8_8 sRGB texture the
device cannot sample is created and viewed as R8_UNORM or R8G8_UNORM,
and SpirvTarget::srgbDecodeFormats makes the materializer mark the
image, so image loads map every channel through a 256-entry table of
the sRGB EOTF rounded to nearest even at bf16 precision, which is what
RDNA2 (gfx1035) returns; both channels of 8_8 are sRGB, and DST_SEL 0
and 1 map to themselves. Samples and gathers of such an image throw,
and its bindless table entries are unmapped like converted formats.
APS5_SRGB_SHADER_DECODE=1 takes this path on every device. Shader disk
cache entries and keys carry the mark: cache format version 7.
DS opcodes 0x6e and 0x6f exchange two qwords at offset0 and offset1
scaled by 8 (st64: 512) and return both old values. Each address is
exchanged with its own 64-bit LDS exchange on the locked 64-bit path.
Equal offsets and a destination past v255 throw, as for the b32 forms;
64-bit GDS throws like the other 64-bit DS atomics.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Comparison sampling of a color texture threw on the _o, _b and _cl
forms and on a sampler LOD bias. The emulation fetches the texels
itself, so the 6-bit offsets of the address are added to the point or
bilinear texel indices, as on the hardware and in Vulkan. The emulation
runs only at level zero or on a single-level view, where an LOD bias or
clamp cannot select another level, so they are accepted with no effect.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
EmitImage listed all 27 image atomic opcodes by hand to reach
EmitAtomicOp, although it already looks up ImageOpcodeInfoOf for the
instruction. Route every opcode whose access is ImageAccess::Atomic to
EmitAtomicOp before the switch; the set of opcodes is unchanged.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017pTZqAyVSZy2FZmaqakPHZ
LookBackScan runs a 43-instruction decoupled look-back written for the
test: one aggregate per block, the block index from an atomic counter,
{flag, value} published with buffer_atomic_swap_x2 and read back with
glc buffer_load_dwordx2. Seven single look-backs and 50 scans of 4096
blocks are checked against a CPU prefix sum; without the recompiler
change the first whole scan fails (3 of 3 runs).
TechnicalDebt records that only glc, aligned, in-bounds dwordx2 loads
in programs with the 64-bit storage view are one atomic load: loads
without glc, and loads in programs without 64-bit buffer atomics, can
still tear against a concurrent swap_x2.
A glc buffer_load_dwordx2 is one 64-bit access on the GPU, so it never
sees half of a buffer_atomic_swap_x2. It was emitted as two dword loads,
which can: the first can read the flag from before the swap and the
second the value from after it.
GTA V gives its BVH nodes their record indices with a single-pass
decoupled look-back prefix sum. Each workgroup publishes a {flag, value}
pair for its block with buffer_atomic_swap_x2 and reads the previous 64
blocks' pairs with glc dwordx2 loads. A torn read counts earlier blocks
twice, two nodes then share records, the BVH is corrupt and the ray
tracing refit hangs. It only happens in scans of more than 64 blocks (the
largest BVHs) and depends on timing.
In a program that has the u64 storage-buffer view (it uses 64-bit buffer
atomics), a coherent raw two-dword buffer load that is 8-byte aligned and
in bounds is now read with one device-scope OpAtomicLoad on that view and
split with OpUConvert and a shift (not OpBitcast to a uvec2, which
crashes NVIDIA's shader compiler). All other loads keep the per-dword
path.
tests/execution/LookBackScan runs the game's scan kernel: the look-back
from given blocks, and 50 whole 125-block scans checked against a CPU
prefix sum. Without this change the first whole scan fails.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
A pixel or vertex shader with a 64-bit image atomic declares Int64Atomics,
Int64ImageEXT and SPV_EXT_shader_image_int64, which graphics shader
validation rejected ("SPIR-V requires unsupported device capability"),
so the draw was dropped. Compute dispatches are not validated this way.
The device records whether it enabled shaderImageInt64Atomics
(imageInt64Atomics in the device state and the graphics Context), and
ValidateShaders accepts the two capabilities and the extension when it
did.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
image_atomic_* with a two-dword data mask (four for cmpswap) is the
64-bit form of an integer image atomic. The decoder rejected it with
"invalid MIMG data mask". PPSA14632 (Unreal Engine) uses
image_atomic_umax this way in a compute shader during its first frames.
Swap, add, sub, signed and unsigned min/max, and, or, xor and cmpswap
now decode with 64-bit data and translate to new ImageAtomic*64 IR
opcodes. An image updated by them gets its own descriptor binding
range, declared as an R64ui image of 64-bit integers, and the module
uses Int64ImageEXT from SPV_EXT_shader_image_int64. The driver enables
shaderImageInt64Atomics when the device offers it and binds an
R64_UINT view of the 32_32 UINT, SINT or FLOAT surface. Without the
feature, recompiling such a shader throws.
64-bit inc, dec and the float atomics still throw, as does any other
access in the same shader to an image it updates with 64-bit atomics.
The new agc_driver_image_atomics64 test runs every operation on 32_32
UINT, SINT and FLOAT surfaces and checks the returned and stored values
against edge cases across the dword boundary.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
DrawRejection read 0x1c4 with read(), which throws when the register is
absent, against the function's rule that a missing register gives no
verdict there; it now reuses the value read with value() for the
DB_SHADER_CONTROL check. Tests pin the Z-export rules: formats 1, 2, 3
and 9 with Z_EXPORT_ENABLE accepted, format 0 rejected, the sample-mask
export accepted with 32_ABGR and rejected with 32_R, formats 4 to 8
rejected, and a missing 0x1c4 accepted.
StageOf, VertexInfo, PixelInfo and ShaderWorkgroupInput were defined
in the anonymous namespaces of up to three SPIR-V backend sources with
identical bodies; they are now declared next to FailEmit.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Oguzhan Ozdemir
Adrià
Adrià Franch
RomainROCH
Pouare514
Celegans12
Chad
Claude
Michon
Dean
alfalfa-star
LeandroLP23