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 <mar...@gmail.com> 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 <airl...@gmail.com> wrote: >> From: Dave Airlie <airl...@redhat.com> >> >> As pointed out by Connor we still need to use fma if nir wants >> exact (precise) behaviour. >> >> Signed-off-by: Dave Airlie <airl...@redhat.com> >> --- >> 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 >> mesa-dev@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
