gallivm: fix rsqrt failures
authorRoland Scheidegger <sroland@vmware.com>
Fri, 21 Sep 2012 15:03:48 +0000 (17:03 +0200)
committerJosé Fonseca <jfonseca@vmware.com>
Fri, 12 Oct 2012 17:51:18 +0000 (18:51 +0100)
commitd366520e8553f4a16151ee946d6e8136cab3de5e
treec2f1df1a2710f2c1e4157a40a9a9623d85912bfa
parent2a4105cbc067dcd38057a877d606e9493e9ed53a
gallivm: fix rsqrt failures

lp_build_rsqrt initially did not do any newton-raphson step. This meant that
precision was only ~11 bits, but this handled both input 0.0 and +infinity
correctly. It did not however handle input 1.0 accurately, and denormals
always generated infinity result.
Doing a newton-raphson step increased precision significantly (but notably
input 1.0 still doesn't give output 1.0), however this fails for inputs
0.0 and infinity (both result in NaNs).
Try to fix this up by using cmp/select but since this is all quite fishy
(and still doesn't handle denormals) disable for now. Note that even with
workarounds it should still have been faster since the fallback uses sqrt/div
(which both use the usually unpipelined and slow divider hw).
Also add some more test values to lp_test_arit and test lp_build_rcp() too while
there.

v2: based on José's feedback, avoid hacky infinity definition which doesn't
work with msvc (unfortunately using INFINITY won't cut it neither on non-c99
compilers) in lp_build_rsqrt, and while here fix up the input infinity case
too (it's disabled anyway). Only test infinity input case if we have c99,
and use float cast for calculating reference rsqrt value so we really get
what we expect.

Reviewed-by: José Fonseca <jfonseca@vmware.com>
src/gallium/auxiliary/gallivm/lp_bld_arit.c
src/gallium/drivers/llvmpipe/lp_test_arit.c