Bug 92609 - [BDW, BSW] piglit sampling-2d-array-as-2d-layer fails
Summary: [BDW, BSW] piglit sampling-2d-array-as-2d-layer fails
Status: CLOSED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Ben Widawsky
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-22 18:01 UTC by Mark Janes
Modified: 2015-12-08 21:28 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
simplify the test case (3.20 KB, patch)
2015-10-29 23:25 UTC, Ben Widawsky
Details | Splinter Review
somplify the test case (3.16 KB, patch)
2015-10-30 00:53 UTC, Ben Widawsky
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Janes 2015-10-22 18:01:25 UTC
Piglit 91c537f8190e109fd0fb14d63fed997eff102669 introduced a new test, which passes on all Intel hardware everywhere except BDW and BSW.

This failure pattern probably indicates a platform-specific bug.

output:
bin/arb_texture_view-sampling-2d-array-as-2d-layer -auto -fbo

Probe color at (0,0)
  Expected: 0.000000 1.000000 0.000000 1.000000
  Observed: 1.000000 0.000000 0.000000 1.000000
layer 1 failed
Probe color at (0,0)
  Expected: 0.000000 1.000000 0.000000 1.000000
  Observed: 1.000000 0.000000 0.000000 1.000000
layer 2 failed
<Red/Green swizzle failure pattern persists for the rest of the layer checks>
Comment 1 Ben Widawsky 2015-10-23 21:59:06 UTC
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.
Comment 2 Ben Widawsky 2015-10-27 00:11:56 UTC
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
 };
Comment 3 Ben Widawsky 2015-10-28 17:57:24 UTC
Modified the test to blit out the source framebuffer and it looks fine:
http://lists.freedesktop.org/archives/piglit/2015-October/017740.html
Comment 4 Ben Widawsky 2015-10-28 22:12:56 UTC
Correction. Layer > 0 works fine. It's the second textureSize call which returns a 0x0 texture.
Comment 5 Ben Widawsky 2015-10-28 22:27:43 UTC
"second textureSize" with the modified test means the second draw call because the source texture is 1x1
Comment 6 Ben Widawsky 2015-10-29 00:07:07 UTC
It appears the shader being run on the second draw isn't happening at all.
Comment 7 Ben Widawsky 2015-10-29 16:33:01 UTC
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.
Comment 8 Ben Widawsky 2015-10-29 17:57:45 UTC
Clipper difference is due to fast clears. nevermind.
Comment 9 Ben Widawsky 2015-10-29 18:07:10 UTC
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.
Comment 10 Ben Widawsky 2015-10-29 20:33:15 UTC
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";
Comment 11 Ben Widawsky 2015-10-29 23:25:04 UTC
Created attachment 119288 [details] [review]
simplify the test case

This patch reduces the test case to a single failing sampling operation.
Comment 12 Ben Widawsky 2015-10-30 00:53:10 UTC
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.
Comment 13 Ben Widawsky 2015-11-03 18:10:12 UTC
Fix is on the list:
http://lists.freedesktop.org/archives/mesa-dev/2015-November/098973.html
Comment 14 Mark Janes 2015-12-08 21:28:23 UTC
patch fixed the test and was merged.


bug/show.html.tmpl processed on Jan 22, 2017 at 22:26:36.
(provided by the Example extension).