mesa: 8cb9cce0400362e913ad89f4ae981b8baf86bb57 (master) $ ./bin/arb_shader_texture_lod-texgrad -auto Left: texture2D, Right: texture2DGradARB Probe color at (77,76) Left: 0.000000 0.980392 0.015686 0.000000 Right: 0.000000 0.949020 0.047059 0.000000 PIGLIT: {'result': 'fail' } 47d0613eb70b2cb5d8837fe8e12325532a7918f5 is the first bad commit commit 47d0613eb70b2cb5d8837fe8e12325532a7918f5 Author: Roland Scheidegger <sroland@vmware.com> Date: Sat Oct 5 03:26:47 2013 +0200 gallivm: handle explicit derivatives for cubemaps They need some special handling. Quite complicated. Additionally, use the same code for implicit derivatives too if no_rho_approx and no_quad_lod is set, because it seems while generally it should be ok to use per quad lod for implicit derivatives there's at least some test which insists that in case of cubemaps the shared lod value MUST come from a pixel inside the primitive (due to the derivatives becoming different if a different larger major axis is chosen). v2: based on Brian's feedback, clean up code a bit. And use sign bit of major axis instead of pre-select s/t/r sign for coord mirroring (which should be the same in the end, saves 2 ands). Also fix two bugs with select/mirror of derivatives, the minor axes need to use major axis sign as well (instead of major derivative axis sign), and don't mistakenly use absolute values of major derivative and inverse major values. Reviewed-by: Jose Fonseca <jfonseca@vmware.com> :040000 040000 87a36fd21fb08b5f4cdba877e5c2243eee0d73ba 36fbb692f6f3af2a56e437f8afbbf027683b7072 M src bisect run success
The test isn't really valid. Note that passing it before was just an "accident" as the test verifies that results using implicit and explicit gradients for cube maps are the same, and the driver _ignored_ the explicit gradients before, hence the result obviously was always the same. However, there is no requirement that the result is really the same for implicit and explicit gradients (in fact with d3d10 the api would require explicit gradients be treated per-pixel, whereas sharing of implicit gradients in a 2x2 quad is allowed). That said, if you set GALLIVM_DEBUG to include no_quad_rho and no_rho_approx env vars in a debug build the result should be the same currently for llvmpipe, and it looks like it isn't so I guess there is a bug somewhere. I'll look into that but even fixing it I would not expect the test to pass without these env vars.
mesa: fc25956badb8e1932cc19d8c97b4be16e92dfc65 (master 10.2.0-devel) The llvmpipe arb_shader_texture_lod-texgrad regression is still present.
mesa: 418da979053d4fec5b4913e0407c5c48eab601e5 (master 10.4.0-devel) The llvmpipe arb_shader_texture_lod-texgrad regression is still present.
With no_brilinear it goes a bit further. But it still fails: $ GALLIVM_DEBUG=no_quad_lod,no_rho_approx,no_brilinear ./bin/arb_shader_texture_lod-texgrad -auto Left: texture2D, Right: texture2DGradARB Probe color at (107,91) Left: 0.000000 0.258824 0.737255 0.000000 Right: 0.000000 0.235294 0.760784 0.000000 PIGLIT: {"result": "fail" } Anyway, this is not a proper regression, as Roland said, but just one case where two wrongs were making a right.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/229.
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.