Bug 96629

Summary: dEQP-GLES2.functional.texture.completeness.cube.not_positive_level_0: Assertion `width >= 1' failed.
Product: Mesa Reporter: Ilia Mirkin <imirkin>
Component: Mesa coreAssignee: mesa-dev
Status: RESOLVED FIXED QA Contact: mesa-dev
Severity: normal    
Priority: medium CC: nhaehnle
Version: git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Ilia Mirkin 2016-06-22 05:44:48 UTC
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
Comment 1 Mark Janes 2016-06-22 16:36:21 UTC
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
Comment 2 Ilia Mirkin 2016-06-22 16:44:33 UTC
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...
Comment 3 Ilia Mirkin 2016-06-22 17:49:35 UTC
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>
Comment 4 Nicolai Hähnle 2016-06-24 14:41:30 UTC
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/
Comment 5 Nicolai Hähnle 2016-07-01 15:57:34 UTC
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.