The other source of the multiply will be interpreted as a uint32_t in an
XOR instruction. Any source modifiers with either not be interpreted at
all or will be misinterpreted due to the differing types.
If the other operand of the multiplication has a source modifier, just
emit an extra move to resolve the source modifiers.
The negation source modifier problem is difficult to reproduce due to an
algebraic optimization that changes (-a*b) to -(a*b). However, changes
in MR !1359 push the negations back down.
On Gen7+ it might be possible to do slightly better for an abs() source
modifier by using BFI2 as a glorified copysign().
On Gen8+ it might be possible to do slightly better for a neg() source
modifier by emitting (~a ^ b).
There were no shader-db changes on any Intel platform, so I think we can
deal with that problem when it arises.
See also piglit!224.
Fixes: 06d2c116415 ("intel/fs: Add a scale factor to emit_fsign")
Reviewed-by: Matt Turner <mattst88@gmail.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3780>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3780>
}
op[0] = offset(op[0], bld, fsign_instr->src[0].swizzle[channel]);
+
+ /* Resolve any source modifiers. We could do slightly better on Gen8+
+ * if the only source modifier is negation, but *shrug*.
+ */
+ if (op[1].negate || op[1].abs) {
+ fs_reg tmp = bld.vgrf(op[1].type);
+
+ bld.MOV(tmp, op[1]);
+ op[1] = tmp;
+ }
} else {
assert(!instr->dest.saturate);
}