Summary: | dEQP-GLES2.functional.texture.completeness.cube.not_positive_level_0: Assertion `width >= 1' failed. | ||
---|---|---|---|
Product: | Mesa | Reporter: | Ilia Mirkin <imirkin> |
Component: | Mesa core | Assignee: | 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
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.