Bug 92609

It's not a swizzle, the test writes red as the background color, and then if things succeed green is written. Red just means it's failed.

I have nothing useful to report.

All layers > 0 are failing. The test attempts to create a texture view with a 2d surface from a source texture 2d array. It writes red to all layers, then sets a green pixel in layer n, and finally creates a texture view of layer n. It checks if the texture view has the green pixel. I tried to change the test to not use a texture view to verify the write to the source texture 2d array is working but failed to make that pass. I am not sure if there is a bug in the test modification, or that the 2d array writes or sampling is failing - which is causing the test to fail. I need to dig more here.

I've compared a batch dump to a dump from SKL (which works according to Mark), and the only substantive I can find is qpitch. That's interesting because qpitch might impact such a test. Random qpitch hacking hasn't helped yet.

Here is a patch to simplify the test
diff --git a/tests/spec/arb_texture_view/sampling-2d-array-as-2d-layer.c b/tests/spec/arb_texture_view/sampling-2d-array-as-2d-layer.c
index 8189044..95f3c64 100644
--- a/tests/spec/arb_texture_view/sampling-2d-array-as-2d-layer.c
+++ b/tests/spec/arb_texture_view/sampling-2d-array-as-2d-layer.c
@@ -51,7 +51,8 @@ typedef struct Params {
 /* test a few size combinations that tend to require particular alignment
    requirements by the hardware */
 static const Params testparams[] = {
-       { 8, 1, 1, "1x1" },
+       { 2, 1, 1, "1x1" },
+#if 0
        { 3, 2, 1, "2x1" },
        { 3, 8, 1, "8x1" },
        { 1, 16, 1, "16x1" },
@@ -60,6 +61,7 @@ static const Params testparams[] = {
        { 2, 64, 64, "64x64" },
        { 4, 128, 64, "128x64" },
        { 3, 35, 67, "35x67" }
+#endif
 };

Modified the test to blit out the source framebuffer and it looks fine:
http://lists.freedesktop.org/archives/piglit/2015-October/017740.html

Correction. Layer > 0 works fine. It's the second textureSize call which returns a 0x0 texture.

"second textureSize" with the modified test means the second draw call because the source texture is 1x1

It appears the shader being run on the second draw isn't happening at all.

I put in pipeline stats and noticed that the clipper is indeed clipping things it isn't supposed to, so the fragment shader isn't even being invoked.

Clipper difference is due to fast clears. nevermind.

Disabling fast clears on gen8 does make the results of my shader look correct, the sampling still fails, but size and offset are correctly written to the first pixel when the test is modified.

Heh. I'm back to my original conclusion that layer > 0 fails. At least using the following shader:
        fsCode =
                 "#version 130\n"
                 "uniform sampler2D texview;\n"
                 "void main()\n"
                 "{\n"
                 "   vec4 color = texture(texview, vec2(0.0))\n;"
                 "   gl_FragColor = vec4(color.xyz, 1.0);\n"
                 "}\n";

Created attachment 119288 [details] [review]
simplify the test case

This patch reduces the test case to a single failing sampling operation.

Created attachment 119289 [details] [review]
somplify the test case

I don't think this is actually a bug fix, the previous code was correct by accident. Easier to read though.

Fix is on the list:
http://lists.freedesktop.org/archives/mesa-dev/2015-November/098973.html

patch fixed the test and was merged.