Both ignored the FLOAT_MODE f16 denormal field. On RDNA2 (gfx1031)
v_cvt_pkrtz_f16_f32 flushes each denormal half result to its signed zero
when bit 7 of FLOAT_MODE is clear, and v_pack_b32_f16 flushes each
denormal half input when bit 6 is clear. Modes that keep them and
shaders without a known float mode are translated as before.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The f16 unary ops, v_frexp_mant_f16, v_frexp_exp_i16_f16, the norm
conversions and v_cvt_f32_f16 read denormal halves as they are and
rounded denormal results as they are, whatever the denormal field of
FLOAT_MODE says. On RDNA2 a clear bit 0 flushes a denormal half input
to its signed zero and a clear bit 1 flushes a denormal half result.
One shared rule now drives all of them, and v_ldexp_f16 uses it for its
input too.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
v_cvt_f32_i32 and v_cvt_f32_u32 used the host Convert which always
rounds to nearest even. When FLOAT_MODE bits 1:0 are directed, build
the f32 bits from the integer magnitude so discarded low bits follow
round toward +inf, -inf or zero, as measured on RDNA2 (gfx1036).
Co-Authored-By: Composer <noreply@cursor.com>
Directed FLOAT_MODE modes for v_cvt_f16_f32, v_cvt_f16_i16,
v_cvt_f16_u16 and v_ldexp_f16 were ignored, so results stayed
round-to-nearest-even. Hardware uses FLOAT_MODE bits 3:2 (round16);
the directed path runs only when f16 denormals are preserved.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
With FP16_OVFL=1 the hardware writes an f16 result that would round to
infinity as the largest finite value of that sign, unless a source
operand is infinite. v_div_fixup_f16 keeps the infinity it writes for a
zero denominator or an infinite numerator. Measured on RDNA2 (gfx1036)
at IEEE=0 and IEEE=1 with f16 denormals kept and flushed.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
With IEEE_MODE=1 the hardware quiets each signaling NaN half that
v_pack_b32_f16 packs, after neg and abs; with IEEE=0 it copies the bits.
The recompiler always copied them. Same rule as #1867, measured on
gfx1036 in both modes.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
v_cvt_pknorm_i16/u16_f32 rounded |x| * 32767 or 65535 to nearest even
with a 64-bit integer product, variable 64-bit shifts and a sticky bit.
In f32, p = |x| * scale is the f32 nearest to the exact product, so
roundEven(p) is the answer unless p is exactly k + 0.5, where the sign of
the exact error fma(|x|, scale, -p) decides. Lanes that select a
constant (NaN, |x| >= 1) multiply 0 instead.
v_cvt_pk_u8_f32 truncated with the saturating conversion and rounded the
fraction by hand; it is now roundEven(x) between the 0 and 255 clamps,
NaN giving 0, read without the f32 denormal flush.
New test agc_driver_f32_pack_rounding: 563,232 inputs around every
rounding tie, checked against the exact product in double.
The translation of v_cvt_i32/u32/flr_i32/rpi_i32_f32 and v_cvt_i16/u16_f16
already maps NaN to 0 and clamps the value into range before
ConvertS32F32/ConvertU32F32, and the backend truncated it again and
repeated the NaN and range selects on the result. Those IR ops have no
other producers, so the backend now emits one OpConvertFToS or
OpConvertFToU, and EmitF32ToU32 and EmitTruncF32Value, which had no
other users, are removed.
The translation drops its FPTrunc32, as the conversions round toward
zero, and the selects whose constant the conversion of the clamped value
already gives. v_cvt_i32_f32 and v_cvt_u32_f32 read their source without
the f32 denormal flush: a denormal truncates to 0 either way.
v_pack_b32_f16 applied neg/abs to bit 31 of the source dword instead of the
selected half. v_cvt_pknorm_{i16,u16}_f32 and v_ldexp_f32 used GLSL
PackSnorm2x16/PackUnorm2x16/Ldexp, which leave NaN, rounding ties and
denormals to the driver. Compute them on the bits as measured on RDNA2.
Co-Authored-By: Claude <noreply@anthropic.com>
writeF16 dropped the clamp bit, so VOP3/SDWA f16 results with clamp
(v_rcp_f16, v_fma_f16, v_cvt_f16_f32, v_add_f16_sdwa, ...) were not
saturated. Clamp now limits to [0, 1] with NaN and -0 going to +0.
The f16 sqrt/rsq/log and sin/cos paths applied omod, which the
hardware ignores on f16 results in the default float mode, and
v_cvt_pkrtz_f16_f32 applied clamp and omod to its inputs, which the
hardware ignores as well.
Co-Authored-By: Claude <noreply@anthropic.com>
