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>
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.
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.