[Mesa-dev] [PATCH v2 9/9] nv50/ir/tgsi: split mad to mul+add

[Roland Scheidegger]

Am 13.06.2017 um 08:57 schrieb Karol Herbst:
> On Tue, Jun 13, 2017 at 2:17 AM, Roland Scheidegger <sroland at vmware.com> wrote:
>> I am actually also thinking this should be different.
>>
>> e.g. imho MAD means the operation can be either fused or unfused.
>> This is the "traditional" definition of MAD - opencl for instance will
>> follow this too, albeit this isn't mentioned in the gallium docs (it
>> probably should be).
>> (OpenCL says: "Whether or how the product of a * b is rounded and how
>> supernormal or subnormal intermediate products are handled is not
>> defined. mad is intended to be used where speed is preferred over
>> accuracy.")
>> I think doing something different here in gallium can only lead to
>> madness long term - glsl doesn't have mad in the first place, and as far
>> as I can tell d3d10 is ok with fused/unfused mad too (the docs stating
>> "Fused operations (such as mad, dp3) produce results that are no less
>> accurate than the worst possible serial ordering of evaluation of the
>> unfused expansion of the operation.")
>>
>> This means that mul+add cannot be fused anywhere to a mad if precise is
>> specified, and therefore you should never have to worry about doing a
>> fused or unfused mul/add in the driver with a mad - it's enough if you
>> just don't fuse mul+add in the driver itself (if you can't do unfused mad).
>>
>> Roland
>>
> 
> well there is a TGSI peephole doing this mul+add=>mad optimisation,
> because it isn't wrong, because mad != fma and mul+add==mad, but on
> Fermi+ Nvidia hardware there is no mad, only fma and because mad != fma,
> we need to split it up again.
> 
> So either TGSI doesn't merge it if the Instruction is flagged as precise (which
> it is in those tests mentioned) allthough it is correct, or we lower
> something in
> the driver, because the Instruction isn't supported by the hardware all along.

Yes, I think the TGSI peephole shouldn't merge mul+add to mad with
precise. You say this isn't wrong, but imho it clearly is, because noone
ever said MAD can't be a fused add - it is multiply + add, yes, but if
there's intermediate rounding or not isn't specified. FWIW gallivm code
also assumes this, and will use llvm.fmuladd for implementation (which
is exactly the same "mul+add" story as opencl mad, and will use fma on
cpus supporting it and separate mul+add otherwise, save some bugs in
older llvm versions apparently).
So we should just clarify that in the tgsi docs - mad is multiply + add,
with undefined intermediate rounding, it can be a fused mul+add or an
unfused one (technically it could also be something in-between I suppose
since the apis just specify the accuracy isn't worse than a unfused
multiply + add). Every driver gets to use what it can do fastest for it,
and because there's no specified intermediate rounding for it, precise
doesn't change anything there.

That's at least my opinion what TGSI_OPCODE_MAD should be (of course,
older gpus always used unfused mad, but this wasn't a requirement).

Roland


> Karol
> 
>>
>> Am 12.06.2017 um 20:19 schrieb Karol Herbst:
>>> fixes
>>> KHR-GL44.gpu_shader5.precise_qualifier
>>> KHR-GL45.gpu_shader5.precise_qualifier
>>>
>>> Signed-off-by: Karol Herbst <karolherbst at gmail.com>
>>> ---
>>>  src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 14 ++++++++++++++
>>>  1 file changed, 14 insertions(+)
>>>
>>> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
>>> index c633185893..cd45e82426 100644
>>> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
>>> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
>>> @@ -3184,6 +3184,20 @@ Converter::handleInstruction(const struct tgsi_full_instruction *insn)
>>>        break;
>>>     case TGSI_OPCODE_MAD:
>>>     case TGSI_OPCODE_UMAD:
>>> +      FOR_EACH_DST_ENABLED_CHANNEL(0, c, tgsi) {
>>> +         val0 = getSSA();
>>> +         src0 = fetchSrc(0, c);
>>> +         src1 = fetchSrc(1, c);
>>> +         src2 = fetchSrc(2, c);
>>> +         geni = mkOp2(OP_MUL, dstTy, val0, src0, src1);
>>> +         if (dstTy == TYPE_F32)
>>> +            geni->dnz = info->io.mul_zero_wins;
>>> +         geni->precise = insn->Instruction.Precise;
>>> +
>>> +         geni = mkOp2(OP_ADD, dstTy, dst0[c], val0, src2);
>>> +         geni->precise = insn->Instruction.Precise;
>>> +      }
>>> +      break;
>>>     case TGSI_OPCODE_SAD:
>>>     case TGSI_OPCODE_FMA:
>>>        FOR_EACH_DST_ENABLED_CHANNEL(0, c, tgsi) {
>>>
>>