[Mesa-dev] [Mesa-stable] [PATCH] nir: fix typo in idiv lowering, causing large-udiv-udiv failures

[Ilia Mirkin]

On Wed, Nov 18, 2015 at 2:03 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> Hi Ilia,
>
> On 11 November 2015 at 00:28, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> On Tue, Nov 10, 2015 at 7:24 PM, Connor Abbott <cwabbott0 at gmail.com> wrote:
>>> On Tue, Nov 10, 2015 at 7:02 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>>> On Tue, Nov 10, 2015 at 6:44 PM, Eric Anholt <eric at anholt.net> wrote:
>>>>> Ilia Mirkin <imirkin at alum.mit.edu> writes:
>>>>>
>>>>>> In nv50, and in the python script that Rob circulated, we do:
>>>>>>
>>>>>>    bld.mkCmp(OP_SET, CC_GE, TYPE_U32, (s = bld.getSSA()), TYPE_U32, m, b);
>>>>>>
>>>>>> Do the same in the nir div lowering pass. This fixes the large-udiv-udiv
>>>>>> piglit tests on freedreno.
>>>>>
>>>>> I assume you meant *-op-div-large-uint-uint.shader_test.
>>>>
>>>> Yes.
>>>>
>>>>>
>>>>> vc4 doesn't have uge yet, but I've got a patch to add it and it does
>>>>> fix one subtest.  What this lowering pass is actually doing has never
>>>>> really made sense to me, but it works, so:
>>>>>
>>>>> Acked-by: Eric Anholt <eric at anholt.net>
>>>>
>>>> It's a magical sequence of non-sensical operations which appear to
>>>> produce the proper result with high probability... what's so confusing
>>>> about that? :)
>>>>
>>>> More seriously, I think there are Newton-Raphson overtones in what
>>>> it's doing, but I never fully traced it down. It kind of loses me
>>>> after subtracting 2 from the integer representation of the float bits.
>>>> _______________________________________________
>>>> mesa-dev mailing list
>>>> mesa-dev at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>>
>>> Where did you get it from? Is there a paper somewhere explaining it? I
>>> sort of have a morbid curiosity, perhaps because I got sucked into
>>> implementing division/sqrt/rsq for doubles.
>>
>> I made the old freedreno impl based on nv50's div lowering code.
>> There's similarly weird code for r600, but I don't know if the r600 or
>> nv50 code came first, or where they came from. FWIW the nvc0 div logic
>> is quite different (implemented as a function call, which does rather
>> different things... I think). I also don't know where that came from.
>>
> Just checking that this hasn't fallen through the cracks. Afaics the
> only 'issue' with going forward is that no one has reviewed the patch
> yet, is that right ?

Nope. Rob's going to push it out along with a bunch of freedreno stuff "soon".

  -ilia