| Summary: | [llvmpipe] piglit fbo-cubemap regression | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Vinson Lee <vlee> |
| Component: | Other | Assignee: | mesa-dev |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | sroland |
| Version: | git | Keywords: | regression |
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
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.) |
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.
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