unchangedUntil skipped a write by the reading instruction itself for every shader, so an RDNA s_load that overwrites its own address pair was taken as a user-data pointer load where main refused it. The skip now applies only to PS4 (GCN) shaders, where it is needed; PS5 shaders take main's path.
The SOPK branch of the GCN decoder never set the literal for
s_setreg_imm32_b32, so the eight-byte instruction was re-encoded as one
word and its decode threw "literal operand word is out of the code span
bounds". The decoder now copies the literal for that opcode; the new
agc_gcn_decode test decodes the reported stream.
Co-authored-by: javierUDP <[email protected]>
Co-authored-by: Savvanis Spyros <[email protected]>
Each GCN instruction is re-encoded to its RDNA form and decoded by the
existing RDNA decoder, so the PS4 path shares the recompiler. Covers the
legacy VS stage (program at the VS slot, user SGPRs from s0, vertex and
instance index in v0-v3), fetch shaders linked as user-data calls, MIMG
(image_sample and friends), PS4 buffer descriptors (GCN DATA_FORMAT /
NUM_FORMAT, 44-bit base) and T# image descriptors (GCN tiling in word 7).
The GCN switch is keyed into the shader disk cache. PS5 behaviour is
unchanged: every PS4-only rule is gated on GcnGuestShaders().
A T# loaded as two s_load_dwordx4 halves from a pointer table, where the
second half's offset is formed per lane (v_lshl_add_u32 key, 5, 16) before
v_readfirstlane and the first half's after it (readfirstlane(key) << 5),
was refused: the second half's +16 sat inside ReadFirstLane(Select(exec,
..., old), exec), so TryMakeTableColumn saw a different base and a zero
addend. Compare such offsets in a first-lane normal form (lane value, mask,
shift, addend), peeling selects the mask implies as the SRT walker already
does.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
main 7ce3b1df3e took disk-cache format 43 (#8295) for its own layout, so this
branch's format moves to 44. The request serializer stays at 42: main
still writes 41.
A geometry program with VGT_GS_OUT_PRIM_TYPE 0 (point list) was refused
as an unsupported output assembly, halting Cocoon (PPSA08766) on boot
with "VGT_GS_OUT_PRIM_TYPE other than a triangle strip, or a line strip
from a geometry program, is unsupported".
Each primitive export of an NGG point-list geometry program outputs one
point whose vertex index is stored directly in PrimitivePointIndicesEXT,
so the mesh module now declares OutputPoints with PrimitivePointIndicesEXT
for it when outputPrimitiveSize is 1. The point primitive export extracts
the 9-bit vertex index from the packed primitive export word and stores
it to the output array. A subgroup gets up to maxVertices points, with
provoking vertex 0 and point raster primitive topology.
Tested with Cocoon (PPSA08766) which now progresses past pipeline
creation and initial frame draws into gameplay.
AI-assisted: yes. Written with AI assistance and reviewed by me.
The recompiler asked for DenormPreserve only for 16-bit and 64-bit floats,
so a device that flushes 32-bit denormals by default (RADV, MoltenVK) flushed
them whatever the guest's float mode said. target.float32DenormPreserve is set
from shaderDenormPreserveFloat32 when denormBehaviorIndependence allows a 32-bit
mode, is part of the cache key and of the request serialization (version 41),
and makes the module declare DenormPreserve 32 unless the 32-bit flush is
already taken in hardware. APS5_NO_HW_F32_PRESERVE=1 turns it off.
The startup probe that lets shaders use the device's f32 denormal flush
instead of the emulated one only ran on devices that declare
shaderDenormFlushToZeroFloat32 with independent denormal behavior.
MoltenVK declares neither flushing nor preserving f32 denormals, so every
shader kept the emulated flush on every f32 add, multiply, fma, min, max
and comparison.
On MoltenVK the probe now runs too. Since the device declares no
DenormFlushToZero capability there, a module compiled for the hardware
flush declares no DenormFlushToZero execution mode and relies on the
native behavior the probe measured; when any probe result differs from
the emulated flush, shaders keep the emulation as before. Devices that
declare the capability are unchanged.
A guest wave's lanes see each other's LDS writes without a barrier, so
the recompiler adds a subgroup-scope OpControlBarrier between an LDS
write and the next LDS access when the guest wave is one host subgroup
(WaveLdsScope). AMD's proprietary Windows driver 32.0.21042.62 (Vulkan
driver 2.0.353, "AMD proprietary shader compiler", Radeon 0x13c0)
compiles that barrier to s_barrier, as the pipeline's internal ISA
shows (26 s_barrier for the guest's 9 in a small LDS reduction). In a
workgroup of several waves, the waves that enter a branch holding LDS
accesses then execute extra s_barriers, which pair with the other
waves' barriers, and those waves read LDS before it is written. LLPC
compiles a subgroup-scope control barrier to a wave barrier instead.
PS5LM Plus (PPSA99581) answered with garbage on that driver: the first
compute dispatch of its first graph, an RMS norm with a 512-thread
wave32 LDS tree reduction, scaled every row except its first 32
elements by a partial sum, while NVIDIA matched a NumPy reference and
the inputs were identical.
On that driver the barrier is now a subgroup-scope OpMemoryBarrier,
which it compiles to no instruction. A 32-lane subgroup is one hardware
wave there, which runs its lanes in lockstep and issues its LDS
instructions in order; Vulkan does not guarantee that, so it is
recorded as debt. Other drivers keep the control barrier. The flag is
part of the shader cache key, and agc_shader_replay takes
--wave-lds-memory-barriers to replay a request the way that driver
compiles it.
agc_driver_lds_tree_reduction sums over eight wave32 waves the way the
guest does, with its last four steps inside one wave and no s_barrier
between them: before, thread 32 read 1936 instead of 32896 on the AMD
driver; it passes on AMD and NVIDIA now. agc_subgroup_barrier checks
the driver quirk and the emitted barriers on every runner. PS5LM Plus
now answers " Paris. It is the largest city in Europe ..." on the AMD
iGPU without flash attention, as on NVIDIA and the CPU.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
When the graph is built without the wave size and the return address
escapes under only one of wave32 and wave64, the graph records that size
and its error instead of throwing, and translation throws it only at
that size. A wave64 program that reads a compare mask written over a
call's link pair from a scalar instruction is now recompiled, while the
same program at wave32, where the high dword still holds the return
address, is refused.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The control-flow builder does not know the wave size (the front end is
shared across wave sizes), and with an unknown size it took a v_cndmask
mask to read two registers but a VOPC result to write only one. A wave64
compare that overwrote a call's link pair before a v_cndmask read it was
then rejected as a link register escaping the call/return model. The
check now runs once for wave32 and once for wave64 when the size is
unknown, so each read is matched with writes of the same width.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
A registered type-3 hull program holds the local and the hull part of a
tessellation draw in one binary, addressed through SPI_SHADER_PGM_LO_LS
(SH 0x148) with no SPI_SHADER_PGM_LO_HS: the local part runs on the lanes
below s3[7:0] and writes LDS, an s_barrier follows, and the hull part runs
on the lanes below s3[15:8] and may store the registers the local part
filled. The draw decode asked 0x148 for a type-5 local half, and
PPSA11386 (007 First Light) stopped in its level load with "registered
program refers to an incompatible shader binary type".
The draw decode now gives a registered type-3 program both the local and
the hull role and marks the tessellation configuration mergedHull. The
local stage only passes gl_VertexIndex and gl_InstanceIndex in a 16-byte
record. The hull stage runs the whole program, one invocation per output
control point: v2 and v5 come from the record of control point
min(gl_InvocationID, inputs - 1), v3 is the relative vertex id, and the
LDS becomes a per-control-point output array that a control point writes
in its own record and reads in any record of its patch after the barrier.
Registers live across the barrier stay in the invocation.
The hull stage of a merged program runs at one lane per invocation on
every device (HostSubgroupSize 1). Its lanes are gl_InvocationID, not host
subgroup invocations, so the s_cbranch_execz around the local part tests
the invocation's own lane. With the device's subgroup it took a subgroup
ballot, and lavapipe, whose subgroup stages lack the tessellation control
stage, rejected the draw ("subgroup capability 61 is unsupported for
shader stage 2").
The lowering refuses more input than output control points, LDS writes
outside the own record, reads outside the patch's records, barriers that
some invocations do not reach or that sit in a loop, reads or writes of
another lane's register, outputs beyond the device limits, and fetch
subroutines. Type 3 is prepared with its stage group like type 5 and
takes its float mode from RSRC1_HS. The hull user-data address (SH
0x102/0x103) is optional for a merged program: s[0:1] take it, unchecked,
when the draw sets it and are zero otherwise.
Both stages refer to one binary, so a draw lists each code and header
region once (AppendProgramMemory); a request's memory regions must not
overlap. An indirect draw's record words go into every program whose user
data holds the register, so the hull stage of a merged program reads
them too.
mergedHull is part of the recompile cache key, the draw decode comparison
and the request serialization (version 39).
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Get-fix