Bug 70359 - [llvmpipe] piglit arb_shader_texture_lod-texgrad fails
Summary: [llvmpipe] piglit arb_shader_texture_lod-texgrad fails
Status: NEW
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/llvmpipe (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact:
Keywords: bisected, regression
Depends on:
Blocks: 79039
  Show dependency treegraph
Reported: 2013-10-11 01:45 UTC by Vinson Lee
Modified: 2018-04-13 09:56 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Note You need to log in before you can comment on or make changes to this bug.
Description Vinson Lee 2013-10-11 01:45:06 UTC
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
    Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

:040000 040000 87a36fd21fb08b5f4cdba877e5c2243eee0d73ba 36fbb692f6f3af2a56e437f8afbbf027683b7072 M	src
bisect run success
Comment 1 Roland Scheidegger 2013-10-11 02:02:28 UTC
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.
Comment 2 Vinson Lee 2014-03-02 03:36:15 UTC
mesa: fc25956badb8e1932cc19d8c97b4be16e92dfc65 (master 10.2.0-devel)

The llvmpipe arb_shader_texture_lod-texgrad regression is still present.
Comment 3 Vinson Lee 2014-09-15 16:48:51 UTC
mesa: 418da979053d4fec5b4913e0407c5c48eab601e5 (master 10.4.0-devel)

The llvmpipe arb_shader_texture_lod-texgrad regression is still present.
Comment 4 Jose Fonseca 2014-11-11 17:28:05 UTC
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.

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.