Pretty sure this affects st/mesa. Not sure if it's a recent regression or not... this code did have some changes around it, but I don't think anything that would affect this. Looks like the first level is all 0's (invalid), and then when we set level 1 to something, we try to allocate a full mipmap. But of course the first image's dimensions are all wrong. I guess in that case we should just not combine it (and thus not even make it into guess_base_level_size)? Starting program: /home/ilia/src/deqp/modules/gles2/deqp-gles2 --deqp-visibility=hidden --deqp-case=dEQP-GLES2.functional.texture.completeness.cube.not_positive_level_0 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". dEQP Core git-cf4407563b4783b69214f3542728806468b200a6 (0xcf440756) starting.. target implementation = 'X11 EGL/GLX' Mesa: _mesa_make_current() Mesa: glGetError <-- GL_NO_ERROR Test case 'dEQP-GLES2.functional.texture.completeness.cube.not_positive_level_0'.. Mesa: glClear 0x4000 Mesa: glGenTextures 1 Mesa: glBindTexture GL_TEXTURE_CUBE_MAP 1 Mesa: glTexImage2D GL_TEXTURE_CUBE_MAP_NEGATIVE_X 0 GL_RGBA 0 0 1 0 GL_RGBA GL_UNSIGNED_BYTE 0x12fef68 Mesa: glTexImage2D GL_TEXTURE_CUBE_MAP_POSITIVE_X 0 GL_RGBA 0 0 1 0 GL_RGBA GL_UNSIGNED_BYTE 0x12fef68 Mesa: glTexImage2D GL_TEXTURE_CUBE_MAP_NEGATIVE_Y 0 GL_RGBA 0 0 1 0 GL_RGBA GL_UNSIGNED_BYTE 0x12fef68 Mesa: glTexImage2D GL_TEXTURE_CUBE_MAP_POSITIVE_Y 0 GL_RGBA 0 0 1 0 GL_RGBA GL_UNSIGNED_BYTE 0x12fef68 Mesa: glTexImage2D GL_TEXTURE_CUBE_MAP_NEGATIVE_Z 0 GL_RGBA 0 0 1 0 GL_RGBA GL_UNSIGNED_BYTE 0x12fef68 Mesa: glTexImage2D GL_TEXTURE_CUBE_MAP_POSITIVE_Z 0 GL_RGBA 0 0 1 0 GL_RGBA GL_UNSIGNED_BYTE 0x12fef68 Mesa: glTexImage2D GL_TEXTURE_CUBE_MAP_NEGATIVE_X 1 GL_RGBA 32 32 1 0 GL_RGBA GL_UNSIGNED_BYTE 0x1307148 state_tracker/st_cb_texture.c:336:guess_base_level_size: Assertion `width >= 1' failed. Program received signal SIGTRAP, Trace/breakpoint trap. 0x00007ffff20a8fda in _debug_assert_fail (expr=0x7ffff23b6125 "width >= 1", file=0x7ffff23b60f0 "state_tracker/st_cb_texture.c", line=336, function=0x7ffff23b6860 <__func__.44392> "guess_base_level_size") at util/u_debug.c:330 330 os_abort(); (gdb) bt #0 0x00007ffff20a8fda in _debug_assert_fail (expr=0x7ffff23b6125 "width >= 1", file=0x7ffff23b60f0 "state_tracker/st_cb_texture.c", line=336, function=0x7ffff23b6860 <__func__.44392> "guess_base_level_size") at util/u_debug.c:330 #1 0x00007ffff1e47f38 in guess_base_level_size (target=34067, width=0, height=0, depth=1, level=0, width0=0x7fffffffd238, height0=0x7fffffffd23c, depth0=0x7fffffffd240) at state_tracker/st_cb_texture.c:336 #2 0x00007ffff1e4824a in guess_and_alloc_texture (st=0x11f3690, stObj=0x133ca40, stImage=0x12f4410) at state_tracker/st_cb_texture.c:475 #3 0x00007ffff1e485a4 in st_AllocTextureImageBuffer (ctx=0x12a2bf0, texImage=0x12f4410) at state_tracker/st_cb_texture.c:582 #4 0x00007ffff1e4a940 in st_TexImage (ctx=0x12a2bf0, dims=2, texImage=0x12f4410, format=6408, type=5121, pixels=0x1307148, unpack=0x12bde60) at state_tracker/st_cb_texture.c:1577 #5 0x00007ffff1d8867b in teximage (ctx=0x12a2bf0, compressed=0 '\000', dims=2, target=34070, level=1, internalFormat=6408, width=32, height=32, depth=1, border=0, format=6408, type=5121, imageSize=0, pixels=0x1307148) at main/teximage.c:3019 #6 0x00007ffff1d88832 in _mesa_TexImage2D (target=34070, level=1, internalFormat=6408, width=32, height=32, border=0, format=6408, type=5121, pixels=0x1307148) at main/teximage.c:3058
FWIW, this test is not in dEQP's android "must-pass" list: https://android.googlesource.com/platform/external/deqp/+/master/android/cts/master/gles2-master.txt
Be that as it may, we shouldn't be asserting for reachable situations. I think another one that asserts is on that list, since I was running with the master list when I hit it (admittedly on a NV34 with force-enabled GLES 2). However with this test, the issue also happens with llvmpipe and nvc0. This is also something that happened in the past week or so. I was running with a (non-descript) older version, and it passed, but I just updated and it crashes. I guess there's a bisect in my future...
42624ea837e8f422f1cd04403af915bd7f218b8d is the first bad commit commit 42624ea837e8f422f1cd04403af915bd7f218b8d Author: Nicolai Hähnle <nicolai.haehnle@amd.com> Date: Mon Jun 6 23:15:10 2016 +0200 st/mesa: use base level size as "guess" when available When an applications specifies mip levels _before_ setting a mipmap texture filter, we will initially guess a single texture level. When the second level image is created, we try to allocate the full texture -- however, we get the base level size guess wrong if that size is odd. This leads to yet another re-allocation of the texture later during st_finalize_texture. Even worse, this re-allocation breaks a (reasonable) assumption made by st_generate_mipmaps, because the re-allocation in the finalization call will again allocate a single-level pipe texture (based on the non-mipmap texture filter!). As a result, mipmap generation fails in interesting ways. All of this can be avoided by just using the fact that we already know the size of the base level. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95529 Cc: 12.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Brian Paul <brianp@vmware.com>
I think the correct solution is just to guard this particular call to guess_and_alloc_texture accordingly. See https://patchwork.freedesktop.org/patch/95080/
Fixed in master commit 0ba053b34c29106817568996ac53b41029cf4e4c
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.