Bug 96629 - dEQP-GLES2.functional.texture.completeness.cube.not_positive_level_0: Assertion `width >= 1' failed.
Summary: dEQP-GLES2.functional.texture.completeness.cube.not_positive_level_0: Asserti...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-06-22 05:44 UTC by Ilia Mirkin
Modified: 2016-07-01 15:57 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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


bug/show.html.tmpl processed on Mar 30, 2017 at 04:50:52.
(provided by the Example extension).