gallivm: Add no_rho_approx debug option
authorRoland Scheidegger <sroland@vmware.com>
Thu, 18 Apr 2013 15:04:01 +0000 (17:04 +0200)
committerRoland Scheidegger <sroland@vmware.com>
Thu, 18 Apr 2013 15:04:01 +0000 (17:04 +0200)
commit0d07f05ee87b5446bc3b85fc7be861c4801bb79e
tree7af20a74b5f3ee383976ede8c31f98679c71c7d9
parenta93013697747f09a414cd4674cb1ccc59c2d1d8b
gallivm: Add no_rho_approx debug option

This will calculate rho correctly as
sqrt(max((ds/dx)^2 + (dt/dx)^2 + (dr/dx)^2), (ds/dx)^2 + (dt/dx)^2 + (dr/dx)^2))
instead of max(|ds/dx|,|dt/dx|,|dr/dx|,|ds/dy|,|dt/dy,|dr/dy|)
(for 3 coords - 2 coords work analogous, for 1 coord there's no point doing
the exact version), for both implicit and explicit derivatives.
While such approximation seems to be allowed in OpenGL some APIs may be less
forgiving, and the error can be quite large (sqrt(2) for 2 coords, sqrt(3) for
3 coords so wrong by nearly one mip level in the latter case).
This also helps to single out "real" bugs from "expected" ones, so it is debug
only (though at least combined with no_brilinear I didn't really see much of a
performance difference but only tested with a debug build - at least with
implicit mipmaps the instruction count is almost exactly the same though the
instructions are more complex (1 sqrt and mul/adds instead of and/max mostly).
The code when the option isn't set stays exactly the same.

v2: rename no_rho_opt to no_rho_approx.

Reviewed-by: Brian Paul <brianp@vmware.com>
src/gallium/auxiliary/gallivm/lp_bld_debug.h
src/gallium/auxiliary/gallivm/lp_bld_init.c
src/gallium/auxiliary/gallivm/lp_bld_sample.c