Bug 64170

Summary: [llvmpipe] piglit fbo-cubemap regression
Product: Mesa Reporter: Vinson Lee <vlee>
Component: OtherAssignee: mesa-dev
Status: RESOLVED WONTFIX QA Contact:
Severity: normal    
Priority: medium CC: sroland
Version: gitKeywords: regression
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description Vinson Lee 2013-05-03 01:34:41 UTC
mesa: 573d8813fdbb116f4500d2044c56d80aab73ab7f (master)

$ ./bin/fbo-cubemap  -auto
Probe at (8,51)
  Expected: 1.000000 1.000000 0.000000
  Observed: 0.000000 0.000000 1.000000
Probe at (74,51)
  Expected: 1.000000 1.000000 1.000000
  Observed: 1.000000 1.000000 0.000000
Probe at (140,51)
  Expected: 0.000000 1.000000 0.000000
  Observed: 1.000000 1.000000 1.000000
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
Comment 1 Roland Scheidegger 2013-05-03 15:42:32 UTC
This is due to inaccuracies calculating rho (it goes away with no_rho_approx set).

Examining this, the problem is at the mip level it's failing, there are 8x8 texels and 8x8 pixels, but the mapping to screen-aligned quad is such that at the pixel it's failing there's only one pixel in the quad visible. And the mapping to texel coords is done in such a way that this is in fact a texel right at the corner of the cube map - the test is written in a way to use the same face for all visible pixels, but I'm near certain the other 3 invisible pixels map to different 2 faces. And the derivatives are not quite calculated correctly in such a case (I believe this test really hits very close to worst case, which is factor 2, hence one miplevel, which is exactly what the result shows).
(Note that no_rho_opt does not fix the systematic error calculating derivatives if the pixels don't lie on the same face, but the max error will drop to sqrt(2) which is enough to make it pass.)
Comment 2 Roland Scheidegger 2013-05-11 10:48:30 UTC
*** Bug 64450 has been marked as a duplicate of this bug. ***

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.