System Environment: -------------------------- Platform: Ironlake/Sandybridge/Ivybridge/Haswell/Baytrail Libdrm: (master)libdrm-2.4.52-3-g128e74cf6492025e63e035566bd6e2203e8da5e1 Mesa: (master)356aff3a5c08be055d6befff99a72f5551b3ac2d Xserver: (master)xorg-server-1.15.0-583-gda1660deeb9032ecca61f4bcdc9fc2eec2ada445 Xf86_video_intel:(master)2.99.909-17-g823382d28944a319c207f20ecef25ce1707a8021 Cairo: (master)4144307dbfbe7b297135d9ea4b080cae7e06b997 Libva: (staging)79ddde6bab54618046f136471c020c08ff4fde50 Libva_intel_driver:(staging)c25fe67b1f1e269dc8d0152ce883788ef9288aea Kernel: (drm-intel-nightly) 164a4cb4c1431a0689f85507868356fae24da638 Bug detailed description: ----------------------------- It fails on Ironlake/Sandybridge/Ivybridge/Haswell/Baytrail with mesa master branch. It doesn't happen on 10.0 branch. Bisect shows: 2bf4db1697a02cd58062e0ebac086fda72f29945 is the first bad commit commit 2bf4db1697a02cd58062e0ebac086fda72f29945 Author: Ian Romanick <ian.d.romanick@intel.com> AuthorDate: Fri Dec 13 13:40:48 2013 -0800 Commit: Ian Romanick <ian.d.romanick@intel.com> CommitDate: Sun Feb 2 16:49:09 2014 +0100 meta: Don't use fixed-function to decompress array textures Array textures can't be used with fixed-function, so don't. Instead, just drop the decompress request on the floor. This is no worse than what was done previously because generating the GL error (in _mesa_set_enable) broke everything anyway. A later patch will get GL_TEXTURE_2D_ARRAY targets working. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Brian Paul <brianp@vmware.com> output: Probe at level 0, x 64, y 32, z 0 = (0, 0, 0, 0), expected (255,255,255,255) Internal tex format GL_COMPRESSED_RGBA Probe at level 1, x 32, y 16, z 0 = (0, 0, 0, 0), expected (255,255,255,255) Internal tex format GL_COMPRESSED_RGBA Probe at level 2, x 16, y 8, z 0 = (0, 0, 0, 0), expected (255,255,255,255) Internal tex format GL_COMPRESSED_RGBA Probe at level 3, x 8, y 4, z 0 = (0, 0, 0, 0), expected (255,255,255,255) Internal tex format GL_COMPRESSED_RGBA Probe at level 4, x 4, y 2, z 0 = (0, 0, 0, 0), expected (255,255,255,255) Internal tex format GL_COMPRESSED_RGBA Probe at level 5, x 2, y 1, z 0 = (0, 0, 0, 0), expected (255,255,255,255) Internal tex format GL_COMPRESSED_RGBA Probe at level 6, x 1, y 0, z 0 = (0, 0, 0, 0), expected (255,255,255,255) Internal tex format GL_COMPRESSED_RGBA Probe at level 7, x 0, y 0, z 0 = (0, 0, 0, 0), expected (255,255,255,255) Internal tex format GL_COMPRESSED_RGBA Probe at level 0, x 64, y 32, z 0 = (0, 0, 0, 0), expected (255,255,255,255) Internal tex format GL_COMPRESSED_RGB Probe at level 1, x 32, y 16, z 0 = (0, 0, 0, 0), expected (255,255,255,255) Internal tex format GL_COMPRESSED_RGB Probe at level 2, x 16, y 8, z 0 = (0, 0, 0, 0), expected (255,255,255,255) Internal tex format GL_COMPRESSED_RGB Probe at level 3, x 8, y 4, z 0 = (0, 0, 0, 0), expected (255,255,255,255) Internal tex format GL_COMPRESSED_RGB Probe at level 4, x 4, y 2, z 0 = (0, 0, 0, 0), expected (255,255,255,255) Internal tex format GL_COMPRESSED_RGB Probe at level 5, x 2, y 1, z 0 = (0, 0, 0, 0), expected (255,255,255,255) Internal tex format GL_COMPRESSED_RGB Probe at level 6, x 1, y 0, z 0 = (0, 0, 0, 0), expected (255,255,255,255) Internal tex format GL_COMPRESSED_RGB Probe at level 7, x 0, y 0, z 0 = (0, 0, 0, 0), expected (255,255,255,255) Internal tex format GL_COMPRESSED_RGB PIGLIT: {'result': 'fail' } Reproduce steps: ---------------------------- 1. xinit 2. ./bin/ext_texture_array-gen-mipmap -fbo -auto
When I ran it, this test segfaulted. Getting wrong results is better than crashing, so... did you read the commit message?
Pardon, this wasn't the segfault case, but it wasn't working either. It is impossible that this test passed since commit 2a3d1e2e06ce.
Looking at the test, it's fairly terrible. It sets a texture to all white, generates mipmap levels, then checks the results. The problem is that it's possible to get all white as a result by luck. Previous to 2bf4db1697, the test was getting a GL error (as predicted) generated inside meta. The test needs some changes. Specifically, I think a more interesting texture needs to be used. Since this test involves texture compression and other things that make predicting the exact result difficult, the result of compressing the array texture should be compared with the result of compressing a regular GL_TEXTURE_2D. The updated test would create two textures, one GL_TEXTURE_2D_ARRAY and one GL_TEXTURE_2D. Send the same texture (perhaps the RGBW texture) to both with the same internalFormat. Call glGenerateMipmaps and glGetTexImage on both. Each should give the same results. At a minimum, the test should check that glGenerateMipmaps doesn't generate a GL error.
*** Bug 74471 has been marked as a duplicate of this bug. ***
*** Bug 74923 has been marked as a duplicate of this bug. ***
It passes on master branch commit eb65d4b84d4c514bfa9114a56a08513efabbe030 and 2a3d1e2e06ce74801ccbfd349558d44653b9692f. It also fails on mesa 10.1 branch.
Passes here, and I don't think we care about the 10.1 branch any more.
Verified.Works well on latest mesa master and 10.4 branch.
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.