Why? While it might technically be legal, always generating an unfused mul+add when the user explicitly requested fma() seems harsh...
On Thu, Oct 5, 2017 at 9:32 PM, Marek Olšák <[email protected]> wrote: > FYI, if we switch radeonsi to NIR, we are going to disable fma > completely, exact or not. > > Marek > > On Wed, Oct 4, 2017 at 10:04 PM, Dave Airlie <[email protected]> wrote: >> From: Dave Airlie <[email protected]> >> >> As pointed out by Connor we still need to use fma if nir wants >> exact (precise) behaviour. >> >> Signed-off-by: Dave Airlie <[email protected]> >> --- >> src/amd/common/ac_nir_to_llvm.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/src/amd/common/ac_nir_to_llvm.c >> b/src/amd/common/ac_nir_to_llvm.c >> index 11ba487..38a2bbe 100644 >> --- a/src/amd/common/ac_nir_to_llvm.c >> +++ b/src/amd/common/ac_nir_to_llvm.c >> @@ -1707,7 +1707,7 @@ static void visit_alu(struct ac_nir_context *ctx, >> const nir_alu_instr *instr) >> result); >> break; >> case nir_op_ffma: >> - result = emit_intrin_3f_param(&ctx->ac, "llvm.fmuladd", >> + result = emit_intrin_3f_param(&ctx->ac, instr->exact ? >> "llvm.fma" : "llvm.fmuladd", >> ac_to_float_type(&ctx->ac, >> def_type), src[0], src[1], src[2]); >> break; >> case nir_op_ibitfield_extract: >> -- >> 2.9.5 >> >> _______________________________________________ >> mesa-dev mailing list >> [email protected] >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ > mesa-dev mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
