The test works by rendering a bunch of triangles rotated at different angles, once into a reference image and once into an MSAA buffer. The MSAA buffer is then resolved to make a test image and compared with the reference image. Any pixels that are fully lit or fully unlit in the reference image must also be fully lit or fully unlit in the test image. Any pixels that are partially lit must have the same value in both images with some margin of error.
The reference image is created by rendering the triangles to a buffer that is 16x the size in both axes and then scaling it back down with linear filtering. This should effectively make 256x super-sampling. As the triangles are just a solid white colour, super-sampling and multisampling are effectively the same. GL lights a pixel whenever the triangle contains the pixel's center. Therefore the super-sampling in the reference image is effectively equivalent to 256x multisampling with the samples laid out in a regular grid with positions like below:
0.03125,0.96875 0.09375,0.96875 ... 0.90625,0.96875 0.96875,0.96875 . . . . . . 0.03125,0.03125 0.09375,0.03125 ... 0.90625,0.03125 0.96875,0.03125
On Intel hardware, you have to pick the sampling positions but you can only position them at intervals of 1/16 starting from zero. The number is stored with 4 bits which means the largest value you can specify is 15/16 and as such you can't put a sample on the right edge of the pixel but you can put one on the left edge. I think this design is based on what D3D describes because it matches the ‘standard’ pattern described here.
As we need to position 16 samples and we don't want more than one sample in each column or row, this means we have to use the full range of possible values and we have to place samples on the left-hand zero edge and the top zero edge of the pixel. These two samples are outside of the grid used in the Piglit test so it's possible that the edge of the triangle will intersect one of the samples in the test image but not in the reference image.
I checked with GDB to find one of the pixels that is partially lit in the test image but totally unlit in the reference image. One example is the pixel at 207,20 which is shown in the diagram by the red lines.
I grabbed the geometry for the triangles using transform feedback and draw a zoomed-in version with Inkscape. This is shown in the bottom right of the diagram. The green square is the outline of this pixel, the blue cross-hairs are the points where the reference image would sample the pixel and the red ones are where my SKL should be sampling. You can see that the triangle doesn't cover any of the reference samples but it does cover the leftmost sample of the test image.
I'm surprised that the same problem doesn't happen on nvidia because I was expecting that maybe it would pick the same sample locations as specified for D3D. However maybe if it's faking the multisampling by supersampling it can pick better sample positions that don't touch the edges of the pixel like in the reference image so it passes.
One way to fix the test might be to shift the triangles in the reference image down and left by 1/32th of a pixel so that all of the possible sample positions in the test image would lie on top of a sample in the reference image. However this could break nvidia if its sample positions aren't aligned to a 1/16th of the pixel.
Another way I was thinking could be to generate the reference image entirely in software and actually check what percentage of each pixel is covered by the triangle using geometry so that it would be very accurate, but that could be a lot of work.