Bug 96518 - [llvmpipe] piglit linestipple regression
Summary: [llvmpipe] piglit linestipple regression
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/llvmpipe (show other bugs)
Version: 13.0
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords: bisected, regression
Depends on:
Blocks: 98471
  Show dependency treegraph
 
Reported: 2016-06-14 00:09 UTC by Vinson Lee
Modified: 2019-09-18 18:32 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vinson Lee 2016-06-14 00:09:32 UTC
mesa: 4825264f75c83576f251290547f121f066b46a70 (master 12.1.0-devel)

$ ./bin/linestipple -auto
Testing Baseline:
PIGLIT: {"subtest": {"Baseline" : "pass"}}
Testing Restarting lines within a single Begin-End block:
PIGLIT: {"subtest": {"Restarting lines within a single Begin-End block" : "pass"}}
Testing Line strip:
Probe color at (34,20)
  Expected: 0.000000 0.000000 0.000000
  Observed: 1.000000 1.000000 0.000000
PIGLIT: {"subtest": {"Line strip" : "fail"}}
Testing Line loop:
PIGLIT: {"subtest": {"Line loop" : "pass"}}
Testing Factor 2x:
PIGLIT: {"subtest": {"Factor 2x" : "pass"}}
Testing Factor 3x:
PIGLIT: {"subtest": {"Factor 3x" : "pass"}}
PIGLIT: {"result": "fail" }


320d1191c61a0a82444605c12e5c4b2ee0b241eb is the first bad commit
commit 320d1191c61a0a82444605c12e5c4b2ee0b241eb
Author: Jose Fonseca <jfonseca@vmware.com>
Date:   Mon Apr 4 00:05:33 2016 +0100

    gallivm: Use llvm.fmuladd.*.
    
    Reviewed-by: Roland Scheidegger <sroland@vmware.com>

:040000 040000 31dca10c80a2741d596cb6d81cd6015e1312dc2e e24948d177adab4b2fc35cd186d8dbffec3f3a0d M	src
bisect run success
Comment 1 Roland Scheidegger 2016-06-14 02:26:15 UTC
I suppose I missed that when I did a piglit run...
This is fairly interesting, it seems to be due to inaccurate float math.
The stipple code gets for position x0,x1 10.5, 34.5 leading to a length 24.
However, with the MADs used for vertex transform replaced by fmas, I get position 10.500002, 34.500000 instead. Hence length 23.999998. And subsequently patterns getting different (I think it makes no difference on the first segment, but the second due to the stipple->counter += length line).

Not sure though why the results would be seemingly less accurate with fma. (And not sure there shouldn't be some different behavior wrt rounding in the line stipple code?)
Comment 2 Jose Fonseca 2016-06-23 13:49:25 UTC
Althought generally FMA is more precise, it's possible that it give less precise results.  Especially when dealing with things like whole integers, it's quite possible that the lower precision of a non-fused MAD ends up "snapping" things to the right values.  Whereas FMA preserves any intermediate rounding error in the final result.


From my POV, the issue is either:

- llvmpipe/draw stipple implementation needs better rounding (eg.g, RoundToNearest as opposed to Truncate)

- the linestipple piglit test needs to be updated to not rely on precise rounding of the stipple.


Either way I doubt the solution is to avoid FMA.
Comment 3 GitLab Migration User 2019-09-18 18:32:37 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/241.


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.