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]>
enabling it broke agc_driver_layered_volume_draw, agc_driver_layered_volume_vertex
and agc_driver_subvector_loop on an RX 6700 XT. With #7623 and #7828 on
main, those tests pass with the feature on, in either library-mode order.
This reverts 48b394d1e and keeps the record of #7623's empty-mask test in
the s_subvector_loop debt entry.
Co-Authored-By: Claude <[email protected]>
Debt entries name the titles they were measured on. Use the title ID, or "a retail title" where the sentence needs no identification. No technical content changes.
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]>
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]>
Capture evaluated every flattened scalar slot even when a clean scalar
branch skipped it, so an inaccessible direct user-data root refused the
draw. Record flat-slot uses on resource control-flow blocks and evaluate
only the reachable ones; keep refusing taken and unresolved paths.
Fixes#8272.
#7018 reads the low-half factors of v_mul_lo_u16 and v_pk_mul_lo_u16
as 24-bit fields because AMD's Windows driver stores the full 32-bit
product when it knows both factors fit in 16 bits. #7673's fold of
BitFieldUExtract(x, 0, n) into x removed those reads when the program
had masked the factors to 16 bits, so agc_driver_mul_lo_u16_high_half
failed again on that driver. The folder now keeps a field read that a
multiply uses.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
A domain program that picks one of its patch's control points from data
(Onimusha: Way of the Sword, PPSA27836, selects a corner with v_cmp and
v_cndmask before a buffer_load from the off-chip ring) was refused with
"the tessellation ring or LDS address is not affine in the control point
and relative patch". Computed indices were accepted only for hull LDS
reads.
- The address evaluator gives off-chip EvaluationInput reads the same
dynamic term as hull LDS reads, and a value read from the patch's own
ring or LDS no longer counts as depending on the relative patch index,
since the lowered read takes the patch implicitly.
- When the program also uses its relative patch index as data, the
index is replaced by the grouped patch instead of 0, which left a
computed read's address pointing into another patch. Such reads now
subtract their relative patch term, for hull and domain reads alike;
reads in programs that do not use the index as data keep their address.
- The computed offset must be a whole number of control points, and the
backend clamps the domain gl_in index to the last output control point
as it already does for hull reads.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The entry stated that image atomics on 32_SINT and 32_FLOAT act on the
raw dword with no measurement behind it. On gfx1100 the 13 integer image
atomics return and store the same raw-dword results on 32_UINT, 32_SINT
and 32_FLOAT, while 16_UINT and 8_8_8_8_UINT controls differ. gfx1100
has no float image atomics, so that part stays open.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
A ds_ordered_count with offset1 bit 4 set swaps the first active lane's value into the GDS counter instead of adding it. Emit it as one device-scope atomic exchange through the same path as the ordered add, and return the counter's previous value to every active lane.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
v_mad_f32, v_mac_f32, v_madak_f32 and v_madmk_f32 exist only on gfx10.1,
so the RDNA2 oracle can't measure them. Measured on gfx1010 (RX 5700 XT)
in wave32 at IEEE 0 and 1, f32 denormal modes 0 to 3 and round modes 0
to 3, and in wave64, they round the product before the add, flush f32
sources, product (tiny after rounding with an unbounded exponent) and
result in every mode, and choose NaN results like the fma forms.
The behaviour stays left to the driver: translating it on every lane
cost about 15x main on the RX 5700 XT and 23x on an RTX 3070, and a
branch around the exact path still about 6x, so the lowering waits for
the SPIR-V float controls of #981.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Get-fix