Bug 89649 - dEQP-GLES3: line color interpolation does not have enough precision
Summary: dEQP-GLES3: line color interpolation does not have enough precision
Status: NEW
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Ian Romanick
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 102590
  Show dependency treegraph
 
Reported: 2015-03-18 08:19 UTC by Iago Toral
Modified: 2019-08-08 14:20 UTC (History)
7 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 Iago Toral 2015-03-18 08:19:55 UTC
Affected tests:

dEQP-GLES3.functional.rasterization.interpolation.basic.lines
dEQP-GLES3.functional.rasterization.interpolation.basic.line_strip
dEQP-GLES3.functional.rasterization.interpolation.basic.lines_wide
dEQP-GLES3.functional.rasterization.interpolation.basic.line_strip_wide
dEQP-GLES3.functional.rasterization.interpolation.basic.line_loop_wide
dEQP-GLES3.functional.rasterization.interpolation.projected.lines
dEQP-GLES3.functional.rasterization.interpolation.projected.line_loop
dEQP-GLES3.functional.rasterization.interpolation.projected.lines_wide
dEQP-GLES3.functional.rasterization.interpolation.projected.line_strip_wide
dEQP-GLES3.functional.rasterization.interpolation.projected.line_loop_wide
dEQP-GLES3.functional.rasterization.fbo.texture_2d.interpolation.lines
dEQP-GLES3.functional.rasterization.fbo.texture_2d.interpolation.lines_wide
dEQP-GLES3.functional.rasterization.fbo.rbo_singlesample.interpolation.lines
dEQP-GLES3.functional.rasterization.fbo.rbo_singlesample.interpolation.lines_wide

The problem with these are small differences in the interpolated color computed for certain pixels across lines. dEQP computes a range of acceptable color values for each pixel and them compares that with the actual rendering result (as provided by glReadPixels). In many cases (at least for lines that are just 1px wide), the difference is off by just one unit in just one component of a pixel. For wide lines it seems that more pixels are affected but the differences are so small that they seem invisible to the naked eye in any case.

Attribute interpolation is done in hardware. The FS receives barycentric coordinates and deltas, computed by hardware in the payload and then, as far as I can see, computing interpolated values amounts to a PLN instruction passing these values as parameters. If this is not producing correct results I would guess that it is an issue in the precision used by the hardware to do these computations (be it the PLN, the values delivered in the FS payload or both), and software can't do much about it. I have also reviewed the state configurations for various hardware units that are involved in interpolation and rasterization calculations and they all seem okay to me.

So, my conclusion is that it is not clear to me if dEQP's expectations are 100% accurate, but even if they are I am not sure that the driver can do much about this since all the aspects of interpolation seem to be on the side of the hardware.
Comment 1 Humberto Israel Perez Rodriguez 2015-10-23 17:51:09 UTC
This tests also fail in HSW-U with the following configuration :

==Test Environment==
--------------------------------------------------
xorg-server-1.17.2
libdrm-2.4.65
xf86-video-intel-2.99.917
mesa-11.1.0-devel (git 6f39546)
libva-1.6.1
intel-driver-1.6.1
cairo-1.14.2


kernel: 4.3.0-rc5-drm-intel-nightly+
commit ce4630de6e6ba63c0477e753510f6294fac9d30c
Author: Matt Roper <matthew.d.roper@intel.com>
Date:   Wed Oct 21 15:05:45 2015 -0700
Comment 2 Juan A. Suarez 2018-05-17 10:14:49 UTC
As per today, using latest Mesa version (18.1-branchpoint-478-gf71714022b2), these are the failing tests:

dEQP-GLES3.functional.rasterization.interpolation.basic.lines_wide
dEQP-GLES3.functional.rasterization.interpolation.basic.line_strip_wide
dEQP-GLES3.functional.rasterization.interpolation.basic.line_loop_wide
dEQP-GLES3.functional.rasterization.interpolation.projected.lines_wide
dEQP-GLES3.functional.rasterization.interpolation.projected.line_strip_wide
dEQP-GLES3.functional.rasterization.interpolation.projected.line_loop_wide
dEQP-GLES3.functional.rasterization.fbo.texture_2d.interpolation.lines_wide
dEQP-GLES3.functional.rasterization.fbo.rbo_singlesample.interpolation.lines_wide
Comment 3 Juan A. Suarez 2018-05-17 10:26:43 UTC
Let me add I've tried to reproduce the other issues that now works fine (like dEQP-GLES3.functional.rasterization.interpolation.basic.lines) using mesa commit 6f39546, but it worked fine.

I guess the dEQP testsuite fixed them.
Comment 4 Juan A. Suarez 2018-05-17 10:28:52 UTC
Another point to add here is that the tests that still fail, were removed from mustpass in Android, and included in gles3-hw-issues.txt file. Can't know exactly the reasons, as the bug it references is private.
Comment 5 Andrés Gómez García 2018-11-21 22:39:46 UTC
(In reply to Juan A. Suarez from comment #4)
> Another point to add here is that the tests that still fail, were removed
> from mustpass in Android, and included in gles3-hw-issues.txt file. Can't
> know exactly the reasons, as the bug it references is private.

These are the 2 commits that did this:

https://github.com/KhronosGroup/VK-GL-CTS/commit/bd58796db4526ba76686d537a9f13b3202bd600c
https://github.com/KhronosGroup/VK-GL-CTS/commit/8e77955a66e73dafccedd6284b4482eaf9e69e8a
Comment 6 Andrés Gómez García 2019-04-18 19:35:15 UTC
(In reply to Andrés Gómez García from comment #5)
> (In reply to Juan A. Suarez from comment #4)
> > Another point to add here is that the tests that still fail, were removed
> > from mustpass in Android, and included in gles3-hw-issues.txt file. Can't
> > know exactly the reasons, as the bug it references is private.
> 
> These are the 2 commits that did this:
> 
> https://github.com/KhronosGroup/VK-GL-CTS/commit/
> bd58796db4526ba76686d537a9f13b3202bd600c
> https://github.com/KhronosGroup/VK-GL-CTS/commit/
> 8e77955a66e73dafccedd6284b4482eaf9e69e8a

It would be great if someone with access to:
https://issuetracker.google.com/issues/21804494

Could shed some light O:)
Comment 7 Andrés Gómez García 2019-04-18 19:38:38 UTC
For the sake of completeness, these are also failing:

dEQP-GLES2.functional.rasterization.interpolation.basic.lines_wide	
dEQP-GLES2.functional.rasterization.interpolation.basic.line_strip_wide	
dEQP-GLES2.functional.rasterization.interpolation.basic.line_loop_wide	
dEQP-GLES2.functional.rasterization.interpolation.projected.lines_wide
dEQP-GLES2.functional.rasterization.interpolation.projected.line_strip_wide	
dEQP-GLES2.functional.rasterization.interpolation.projected.line_loop_wide
Comment 8 Tapani Pälli 2019-04-23 06:22:38 UTC
FYI I've created a vk-gl-cts issue to get shed some light into this.
Comment 9 Jason Ekstrand 2019-07-29 17:37:32 UTC
If the commentary on the Khronos and Google issues (which aren't public) is to be believed, Intel HW is providing barycentrics to the shader which are interpolated diagonally as if the line is drawn as a rectangle rather than simply replicating the barycentrics from the original line vertically or horizontally.  If this is really the case, then ouch; we're going to have to do some "fun" in the shader.

One option would be to use derivatives of barycentrics to figure out the slope of the line and, from there, figure out if we're supposed to be horizontal or vertical.  However, I'm a bit concerned about the stability of those calculations for 45-degree lines and I'm not sure how we would figure out from there how to correct to get back to the pixel we're vertically or horizontally associated with.

Another (rather horrible) option would be to somehow push both ends of the line into the fragment shader (probably via a geometry shader?  Yuck!) and use gl_FragCoord to figure out our own barycentrics.
Comment 10 Jason Ekstrand 2019-07-29 18:01:50 UTC
Playing around with the line HW in Vulkan a bit, this definitely appears to be what the HW is doing.  *sigh*
Comment 11 Jason Ekstrand 2019-07-29 19:04:51 UTC
Unfortunately, the HW doesn't give us a perpendicular barycentric coordinate so we have no idea where we are in the line other than gl_FragCoord.xy.  The best solution I've been able to come up with so far is to add an extra vec4 varying out of the last geometry stage into the fragment shader which duplicates gl_Position.  Then we can use that to find the slope of the line to determine major/minor axis and, using gl_FragCoord.xy, manually calculate the point vertical or horizontal and compute our own barycentrics.  Of course, we'll have to have different math for perspective correct vs. not etc.  Oh, fun!


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.