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

[Karol Herbst]

On Tue, Jun 13, 2017 at 2:18 PM, Roland Scheidegger <sroland at vmware.com> wrote:
> 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
>

I think the best idea would be to specify that:
TGSI_OPCODE_MAD is unfused mu+add
TGSI_OPCODE_FMA is fused mul+add

Having TGSI_OPCODE_MAD being unfused and fused adds an ambiguity
without providing any advantages imho.

This way it's clear what both is. The backend can still decide that it can use
FMA to implement TGSI_OPCODE_MAD or that it can't use MAD and splits it
up, but then the backend decides and the choice is explicit and respects
limitations of the hardware, which Gallium/TGSI doesn't know about.

Or we remove TGSI_OPCODE_MAD and let the backends do the opts.

>
>> 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) {
>>>>
>>>
>