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

Emil Velikov emil.l.velikov at gmail.com
Wed Nov 18 11:03:33 PST 2015


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 ?


Thanks
Emil


More information about the mesa-stable mailing list