Bug 70359

Summary: [llvmpipe] piglit arb_shader_texture_lod-texgrad fails
Product: Mesa Reporter: Vinson Lee <vlee>
Component: Drivers/Gallium/llvmpipeAssignee: mesa-dev
Status: RESOLVED MOVED QA Contact:
Severity: normal    
Priority: medium CC: brianp, jfonseca, sroland
Version: gitKeywords: bisected, regression
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 79039    

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
    values.
    
    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.
Comment 5 GitLab Migration User 2019-09-18 18:31:26 UTC
-- 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.