Bug 64450

mesa: 5471e3949cb6482f1a6dcb969332f2544a758e46 (master)

$ ./bin/cubemap npot -auto
Probe at (62,221)
  Expected: 1.000000 1.000000 1.000000
  Observed: 1.000000 1.000000 0.000000
Cube map failed at size 6x6, level 1 (3x3), face NEGATIVE_X, mipmapped
Probe at (172,221)
  Expected: 1.000000 0.000000 0.000000
  Observed: 1.000000 0.000000 1.000000
Cube map failed at size 6x6, level 1 (3x3), face NEGATIVE_Y, mipmapped
Probe at (282,221)
  Expected: 0.000000 0.000000 1.000000
  Observed: 0.000000 1.000000 1.000000
Cube map failed at size 6x6, level 1 (3x3), face NEGATIVE_Z, mipmapped
PIGLIT: {'result': 'fail' }

50cbcf0c4680bc13e63fe339ef79ed68b2f33c70 is the first bad commit
commit 50cbcf0c4680bc13e63fe339ef79ed68b2f33c70
Author: Roland Scheidegger <sroland@vmware.com>
Date:   Thu Apr 18 17:06:43 2013 +0200

    gallivm: change cubemaps / derivatives handling, take 55
    
    Turns out the previous "fix" for handling per-pixel face selection and
    derivatives didn't work out that well - the derivatives were wrong by
    quite a bit, in theory transformation of the derivatives into cube space
    should work, but would be _a lot_ more work than the "simplified" transform
    used.
    So, for explicit derivatives, I'm just giving up and go back to not honoring
    them.
    For implicit derivatives (and the fake explicit ones) however we try
    something a little different, we just calculate rho as we would for a 3d
    texture, that is after scaling the coords by the inverse major axis.
    This gives the same results as calculating the derivs after projection of
    the coords to the same face as long as all pixels hit the same face (and
    only without rho_no_opt, otherwise it should be a bit worse). And when
    not all pixels are hitting the same face, the results aren't so hot but
    not catastrophically bad (I believe not off by more than a factor of 2 without
    no_rho_approx and not more than sqrt(2) with no_rho_approx). I think this is
    better than just picking the wrong face but who knows...
    
    Reviewed-by: Brian Paul <brianp@vmware.com>
    Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

:040000 040000 fe3e4cb2ef614d118ef371d2d5a35d244f3aec50 70a6ded69d9b16112ed33ae41ec0b5bd5aa74d5c M	src
bisect run success