On NVIDIA's proprietary driver, function arrays that live in local memory
and are read under a data-dependent branch return wrong values in
subgroups 1-3 of a mesh workgroup; subgroup 0 is correct. A wave64
geometry program whose relative addressing keeps its VGPRs in the vector
window therefore loses register writes in every wave but the first. In
the clipping geometry program of Sony's PS5 PSP emulator (PPSA07550) the
empty waves never cleared their candidate primitive slots and wrote
degenerate triangles over wave 0's, so the 3D menu drew spikes.
On that driver a mesh program's window now lives in a device-local
storage buffer of 256 workgroup slots of 65536 dwords, claimed through a
per-slot lock and released after the final barrier. The pool is created
before the first draw that uses it records anything, and its header is
zeroed in a batch of its own that is submitted and waited for; the pool
is published only after that wait, and a failure releases it. Direct
register accesses keep one function variable per register; a direct
store also writes the buffer when a buffer read can see it, relative
reads load the buffer, relative writes store only to it, and a direct
read that may follow a relative write loads the buffer and refreshes the
variable. A buffer entry is zeroed only when a buffer read can see it
before a write. APS5_NO_MESH_WINDOW_BUFFER=1 keeps the arrays.
On a one-lane wave (vertex and local programs without vertex subgroups,
merged hull programs), a wave64 f32 max half-wave scan threw at its
v_permlanex16_b32. When the scan's lane 31 and 63 reads only elect,
through v_cmpx_eq_f32 against each lane's own key, the lanes that
buffer_atomic_umax or smax that maximum at a wave-uniform address with an
unused result, each invocation now takes its own key: every active lane
writes it, and memory ends with the wave's maximum because the keys are
proven non-negative and not NaN. The permutation, whose value then
reaches no other result, keeps its own value.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The MinGW std::filesystem::last_write_time reads and sets file times
through the UCRT stat and utime calls, which convert through local time
using TZ. With a TZ other than the Windows zone, including the one libc
applies from the guest environment, times shifted by the difference:
under TZ=IST-5:30 on an Eastern host a temporary written that second
was 9.5 hours old, so housekeeping deleted it, and a TZ west of the host
set the active cache stamp hours in the past. Housekeeping now reads
times with GetFileAttributesExW, refreshes the stamp with SetFileTime
and compares in system_clock. The housekeeping test runs its child
with a TZ 12 hours from the host zone.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
A read at a negative offset from a pointer the walker loaded from guest
memory (a null pointer behind a guarded branch, offset -4) wrapped below
zero in AddSignedAddress, and the walk threw "cannot evaluate" instead of
recording the read as inaccessible. Uncharted: The Lost Legacy threw it
while loading its first level. The read is now recorded as an SRT poison
at its address wrapped to 48 bits, like any other unreadable address, so
the binding faults only if the shader takes that path.
verifyGuardedNullPointers gains the case for both branch outcomes; it
throws the title's error without the change.
AI-assisted: yes
The 32-bit OpUMulExtended form of #10337 raises the GPU time per frame on MoltenVK by 50 to 90 percent in God of War Sons of Sparta and Planet of Lana. Its extended BufferDescriptorRuntime fixture stays: the 64-bit check makes the same bounds decision.
A buffer V# whose TYPE is not 0 threw "buffer descriptor uses an
unsupported type" for every access. Measured on a PS5 (CFI-1115B,
firmware 12.20): through a V# with TYPE 2 or 3 and FORMAT 0 or a valid
format, buffer_store_dword and buffer_store_format_x write nothing and
don't fault, so a buffer a shader only stores to through one is bound as
a null V#. Loads and atomics through those V#s leave the destination VGPR
unchanged, which a null V# can't reproduce, so they still throw. Through
a TYPE 0, FORMAT 0 V#, vector loads return 0 and stores are dropped, and
those buffers are bound as a null V# too. TYPE 1 faults the GPU for every
access measured and keeps throwing.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
This reverts merge 7fc0ae6008. On NVIDIA, where helper lanes take part in ballots, clearing helper bits from every pixel ballot breaks derivatives along triangle edges (bright lines and specks on a cloud surface in PPSA21564). See the report on #11199.
v_fma_f32, v_fmac_f32, v_fmamk_f32 and v_fmaak_f32 threw "f32 denormal
mode 2 is not implemented" whenever FLOAT_MODE flushed f32 denormal
inputs but kept denormal results.
On RDNA2 (gfx1036) at round to nearest even, mode 2 flushes the inputs
and rounds the fused result once with gradual underflow, which the host's
Fma gives under DenormPreserve 32. The translation now matches all 5,596
measured triples for the four forms at IEEE 0 and 1. Mode 1 keeps
throwing: there the hardware flushes a result that is tiny after rounding
with an unbounded exponent even when the addend is nonzero.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
All four threw "f32 denormal mode N is not implemented" whenever
FLOAT_MODE kept only one side of the f32 denormals.
On RDNA2 (gfx1036), in every f32 round mode and at IEEE 0 and 1, mode 2
gives the results of mode 0 and mode 1 those of mode 3 with a denormal
result flushed, which only v_fract_f32 of a positive denormal produces.
The translation now matches all 118 measured inputs in modes 1 and 2.
Mode 1 of the three that run host float operations on a kept denormal
needs DenormPreserve 32, as v_min_f32 does.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Both threw "f32 denormal mode N is not implemented" whenever FLOAT_MODE
kept only one side of the f32 denormals, so any LLVM-compiled f32
division in such a shader failed to translate.
On RDNA2 (gfx1036) at round to nearest even, v_div_fixup_f32 follows bit
0 of the field, and v_div_scale_f32 flushes its inputs in mode 2 as in
mode 0 and in mode 1 keeps them and flushes a denormal result, with the
VCC of mode 3. The translation now matches all 2,304 measured rows in
modes 1 and 2 at IEEE 0 and 1. Directed rounding still throws, as an
underflowing v_div_fixup_f32 result rounds to the smallest denormal there.
Division and F32DenormalFlush no longer require modes 1 and 2 to be
refused; Division checks v_div_scale_f32 in them against its measured
vectors instead.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
BuildRectListShaders sized the per-vertex tessellation interface from the
position and the exported parameters only. The generated control and evaluation
shaders also carry the vertex shader's ClipDistance array (up to eight scalars)
as input and output builtins, so for a vertex shader that writes clip distances
the interface was up to eight components larger than the checked size and could
exceed maxTessellationControlPerVertexInputComponents and its siblings. The
sibling barycentric geometry shader already counts them.
The clip distance count is now read before the check, and both the parameter
capacity and the component total include it, so parameters are trimmed to what
fits and an interface that cannot fit is rejected.
A wave64 program held as 32 invocations x 2 lanes decided s_cbranch_execz,
s_cbranch_vccz and s_cbranch_scc0 by balloting the per-lane "zero"
condition and requiring all 64 bits set. OpGroupNonUniformBallot sets the
bit of an inactive invocation to 0 (SPIR-V specification,
OpGroupNonUniformBallot: "The bit is set to one if the corresponding
invocation is active and the Predicate for that invocation evaluated to
true; otherwise, it is set to zero"), and an invocation that returned
from the entry point is no longer active. When one invocation stopped,
e.g. after a BDA fault, the zero branch was never taken for the others:
a loop leaving through s_cbranch_execz never ended.
The RDNA2 ISA branches when the whole register is zero ("if (EXEC == 0)",
"if (VCC == 0)", "if (SCC == 0)", SOPP S_CBRANCH_EXECZ / VCCZ / SCC0), so
the branch now asks whether any active invocation still has a lane with
the bit set, as the wave32 path does: not any(own lane set || other
lane set). Inactive invocations then count as lanes with the bit clear.
The non-zero kinds keep any(own || other).
The execution test runs a wave64 program in which lane 0 faults and
stops its invocation, then takes each zero and non-zero branch; before
this change the other lanes fell through all three zero branches.
AI-assisted: yes
SPIRV-Cross emits the lock's acquire compare-exchange and release
exchange as relaxed Metal atomics, so the plain LDS loads and stores of
a locked 64-bit update were not ordered against the lock and contended
ds_add_u64 lost updates on an Apple M5 Pro. On MoltenVK the driver now sets
SpirvTarget::ldsLockFences, and the lock brackets its critical section
with workgroup-scope acquire and release OpMemoryBarriers, which become
threadgroup atomic_thread_fence with no execution barrier.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Adrià