https://bugs.freedesktop.org/show_bug.cgi?id=64450
Priority: medium
Bug ID: 64450
Keywords: regression
CC: srol...@vmware.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: [llvmpipe] piglit cubemap npot regression
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: v...@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 <srol...@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 <bri...@vmware.com>
Reviewed-by: Jose Fonseca <jfons...@vmware.com>
:040000 040000 fe3e4cb2ef614d118ef371d2d5a35d244f3aec50
70a6ded69d9b16112ed33ae41ec0b5bd5aa74d5c M src
bisect run success
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
