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.
This tests also fail in HSW-U with the following configuration :
mesa-11.1.0-devel (git 6f39546)
Author: Matt Roper <email@example.com>
Date: Wed Oct 21 15:05:45 2015 -0700
As per today, using latest Mesa version (18.1-branchpoint-478-gf71714022b2), these are the failing tests:
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.
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.
(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:
(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:
It would be great if someone with access to:
Could shed some light O:)
For the sake of completeness, these are also failing:
FYI I've created a vk-gl-cts issue to get shed some light into this.