[Mesa-dev] [Bug 64450] New: [llvmpipe] piglit cubemap npot regression

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64450

          Priority: medium
            Bug ID: 64450
          Keywords: regression
                CC: sroland at vmware.com
          Assignee: mesa-dev at lists.freedesktop.org
           Summary: [llvmpipe] piglit cubemap npot regression
          Severity: normal
    Classification: Unclassified
                OS: Linux (All)
          Reporter: vlee at freedesktop.org
          Hardware: x86-64 (AMD64)
            Status: NEW
           Version: git
         Component: Other
           Product: Mesa

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 at 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 at vmware.com>
    Reviewed-by: Jose Fonseca <jfonseca at vmware.com>

:040000 040000 fe3e4cb2ef614d118ef371d2d5a35d244f3aec50
70a6ded69d9b16112ed33ae41ec0b5bd5aa74d5c M    src
bisect run success

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130511/5ac9e745/attachment-0001.html>