Bug 96911

Summary: webgl2 conformance2/textures/misc/tex-mipmap-levels.html crashes 12.1 Intel driver
Product: Mesa Reporter: Yang Gu <yang.gu>
Component: Drivers/DRI/i965Assignee: Kenneth Graunke <kenneth>
Status: RESOLVED FIXED QA Contact: Intel 3D Bugs Mailing List <intel-3d-bugs>
Severity: normal    
Priority: medium    
Version: git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Yang Gu 2016-07-13 07:11:41 UTC
Steps to reproduce:
1. Launch latest Chrome browser on Linux with GEN graphics with following options "--single-process --enable-unsafe-es3-apis https://www.khronos.org/registry/webgl/sdk/tests/conformance2/textures/misc/tex-mipmap-levels.html?webglVersion=2&quiet=0"

2. The driver would crash. (Without --single-process option, you may see "TEST COMPLETE". But actually the driver already crashes as if you refresh the page, you will see "WebGL hit a snag" notification).

Using debug version of driver, I saw below stack. The problem is intel_tex.c:216: intel_map_texture_image: Assertion `mt' failed.

#0  0x00007fffef696267 in __GI_raise (sig=sig@entry=6)
    at ../sysdeps/unix/sysv/linux/raise.c:55
#1  0x00007fffef697eca in __GI_abort () at abort.c:89
#2  0x00007fffef68f03d in __assert_fail_base (fmt=0x7fffef7f0fe8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7fffc8e4bb53 "mt", file=file@entry=0x7fffc8e5d301 "intel_tex.c", line=line@entry=216, function=function@entry=0x7fffc8e5d420 <__PRETTY_FUNCTION__.42517> "intel_map_texture_image")
    at assert.c:92
#3  0x00007fffef68f0f2 in __GI___assert_fail (assertion=assertion@entry=0x7fffc8e4bb53 "mt", file=file@entry=0x7fffc8e5d301 "intel_tex.c", line=line@entry=216, function=function@entry=0x7fffc8e5d420 <__PRETTY_FUNCTION__.42517> "intel_map_texture_image") at assert.c:101
#4  0x00007fffc8cd537b in intel_map_texture_image (ctx=<optimized out>, tex_image=<optimized out>, slice=<optimized out>, x=<optimized out>, y=<optimized out>, w=<optimized out>, h=0, mode=1, map=0x1191a5670da0, out_stride=0x7fffccec3f40)
    at intel_tex.c:216
#5  0x00007fffc8a07e92 in _mesa_generate_mipmap (srcImage=<optimized out>, maxLevel=13, texObj=0x1191a69a3480, target=3553, ctx=0x1191a6934030)
    at main/mipmap.c:1969
#6  0x00007fffc8a07e92 in _mesa_generate_mipmap (ctx=ctx@entry=0x1191a6934030, target=target@entry=3553, texObj=texObj@entry=0x1191a69a3480)
    at main/mipmap.c:2226
#7  0x00007fffc8b06236 in _mesa_meta_GenerateMipmap (ctx=0x1191a6934030, target=---Type <return> to continue, or q <return> to quit---
3553, texObj=0x1191a69a3480) at drivers/common/meta_generate_mipmap.c:171
#8  0x00007fffc89f3b4e in _mesa_generate_texture_mipmap (ctx=0x1191a6934030, texObj=0x1191a69a3480, target=3553, dsa=<optimized out>) at main/genmipmap.c:155
#9  0x00007ffff4fa7c86 in gpu::gles2::GLES2DecoderImpl::DoGenerateMipmap(unsigned int) ()
    at /workspace/project/chromium/src/out-gn-linux-x86_64/Release/./libgpu.so
#10 0x00007ffff4f85c4e in gpu::gles2::GLES2DecoderImpl::HandleGenerateMipmap(unsigned int, void const*) ()


Note: This is a regression in latest code, and I can't reproduce it with 11.2 driver.
Comment 1 Kenneth Graunke 2016-07-22 01:46:13 UTC
We don't have a GPU-based implementation of GenerateMipmaps for 3D textures, so we're falling back to the CPU-based one here.

I'm not yet sure why MapTextureImage is getting a NULL mt.  Looking into it...
Comment 2 Kenneth Graunke 2016-07-22 01:56:29 UTC
Oh, it isn't 3D that's the problem.

It seems to be calling glGenerateMipmaps on a 2D RGBA32F texture with width/height = 0.
Comment 3 Kenneth Graunke 2016-07-22 04:35:19 UTC
A basic bisect says this happened at:

commit b3c5df3ca4ca69006114565bf5d6d01c7b8b2934
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Thu Jul 7 11:50:44 2016 -0700

    mesa: Mark R*32F formats as filterable when an extension is present.

But there's got to be some other commit that caused 0-width/height textures to behave differently.
Comment 4 xinghua 2016-07-22 10:42:13 UTC
Hi, Kenneth, 
We reproduce this issue in below scene, crash happens in the second generateMipmap.
  tex = gl.createTexture();
  gl.bindTexture(gl.TEXTURE_2D, tex);
    gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA8, 8, 8, 0, gl.RGBA, gl.UNSIGNED_BYTE, new Uint8Array(8 * 8 * 4));
  gl.generateMipmap(gl.TEXTURE_2D);
  wtu.glErrorShouldBe(gl, gl.NO_ERROR, "generateMipmap should succeed");
  if (gl.getExtension('EXT_color_buffer_float') && gl.getExtension('OES_texture_float_linear')) {
    gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA32F, 0, 0, 0, gl.RGBA, gl.FLOAT, null);
    gl.generateMipmap(gl.TEXTURE_2D);
    wtu.glErrorShouldBe(gl, gl.NO_ERROR, "generateMipmap should succeed for zero-size texture");
  }
Comment 5 Kenneth Graunke 2016-07-22 18:05:42 UTC
Well, I'm not sure how it ever worked before, but it's easy enough to fix.  Patch on the mailing list:

http://mid.gmane.org/20160722180411.25464-1-kenneth@whitecape.org
Comment 6 Kenneth Graunke 2016-07-23 03:34:17 UTC
Fixed on Mesa master by:

commit f80bea2d8066d228e78a1744d036f69a0265116e
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Thu Jul 21 22:13:38 2016 -0700

    mesa: Don't call GenerateMipmap if Width or Height == 0.
    
    One of the WebGL 2.0 conformance tests is trying to call
    glGenerateMipmaps with a width and height of 0.  With the meta
    implementation, this generates a "framebuffer attachment incomplete"
    status, and falls back to the CPU path, calling MapTextureImage.
    
    Except that there's no actual texture to map, and we assert fail.
    
    There's no work to do in this case.  The test expects it to succeed,
    so just return early with no error and avoid hassling the driver.
    
    Cc: mesa-stable@lists.freedesktop.org
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96911
    Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
    Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Comment 7 Yang Gu 2016-07-23 05:38:15 UTC
Thank you very much for the fix, and I verified it works well. 
Currently we're using the latest stable release 12.0 to test WebGL 2.0. Is it possible to cherry pick this patch to 12.0 branch? As this is a crash case, and it will break all the rest tests, so it's critical. And it's the only crash case AFAIK, so I don't foresee other request like this.
Comment 8 Yang Gu 2016-07-23 05:44:29 UTC
Sorry, just hold the cherry pick a bit while, and let me sync with Google to see if they may apply patches locally.
Comment 9 Kenneth Graunke 2016-07-23 16:08:26 UTC
I've marked it for stable, so Emil (as the release maintainer) should pick it up for the next 12.0.x release.
Comment 10 Yang Gu 2016-07-23 16:13:17 UTC
Thanks a lot!

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.