gallivm: fix an issue with NaNs with seamless cube filtering
authorRoland Scheidegger <sroland@vmware.com>
Wed, 13 Dec 2017 02:33:21 +0000 (03:33 +0100)
committerRoland Scheidegger <sroland@vmware.com>
Thu, 14 Dec 2017 21:59:55 +0000 (22:59 +0100)
commita485ad0bcdcab865e14a54133a271198c86e41ab
treea5b33ec0f0c51ba2e9848b45b8e2ef52427e22c1
parent4b8c9ea46bd83d9a2c7fa3b4edc10fe8c6403e3e
gallivm: fix an issue with NaNs with seamless cube filtering

Cube texture wrapping is a bit special since the values (post face
projection) always are within [0,1], so we took advantage of that and
omitted some clamps.
However, we can still get NaNs (either because the coords already had NaNs,
or the face projection generated them), and in fact we didn't handle them
quite safely. I've seen -INT_MAX + 1 been propagated through as the final int
coord value, albeit I didn't observe a crash. (Not quite a coincidence, since
any stride mul with -INT_MAX or -INT_MAX+1 will turn up as a small positive
number - nevertheless, I'd rather not try my luck, I'm not entirely sure it
can't really turn up negative neither due to seamless coord swapping, plus
ifloor of a NaN is not guaranteed to return -INT_MAX by any standard. And
we kill off NaNs similarly with ordinary texture wrapping too.)
So kill off the NaNs by using the common max against zero method.

Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c