Bug 93257 - [SKL, bisected] ASTC dEQP tests segfault
Summary: [SKL, bisected] ASTC dEQP tests segfault
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Neil Roberts
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
: 90821 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-12-05 00:14 UTC by Nanley Chery
Modified: 2016-01-19 18:27 UTC (History)
4 users (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 Nanley Chery 2015-12-05 00:14:50 UTC
Test: dEQP-GLES3.functional.texture.compressed.astc.void_extent_ldr.5x4 
Expected result: Test fails due to comparison errors.
Actual result:   Test segfaults.

The segfaults seem to occur for all ASTC tests with block size dimensions >= 5x4.
More tests may be affected. This issue does not occur on Jenkins, but it does occur
locally on the given configuration:

HW: SKL
dEQP: https://github.com/chadversary/deqp chadv
      CMAKE_BUILD_TYPE Debug                                         
      DEQP_TARGET      drm
Mesa:
commit 0288f92e7b0ce5f0d821f2d0ddef522a23776ecb
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date:   Tue Oct 13 20:50:27 2015 -0700

    i965/gen9: Support fast clears for 32b float
    
    SKL supports the ability to do fast clears and resolves of 32b RGBA as both
    integer and floats. This patch only enables float color clears because we
    haven't yet enabled integer color clears, (HW support for that was added in
    BDW).
    
    v2: Remove LUMINANCE16F and INTENSITY16F special cases since they are now
    handled by Neil's patch to disable MSAA fast clears.
    
    Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
    Reviewed-by: Neil Roberts <neil@linux.intel.com>
    Reviewed-by: Chad Versace <chad.versace@intel.com>


Core dump info:
        Signal: 11 (SEGV)
  Command Line: ./modules/gles3/deqp-gles3 --deqp-case=dEQP-GLES3.functional.texture.compressed.astc.void_extent_ldr.5x4 --deqp-surface-type=fbo --deqp-log-images=disable --deqp-surface-width=64 --deqp-surface-height=64
   Stack trace:
   #0  0x00007fa3556059b9 dri2InvalidateDrawable (i965_dri.so)
   #1  0x00007fa3556222dc intel_viewport (i965_dri.so)
   #2  0x00007fa355372ace _mesa_set_viewport (i965_dri.so)
   #3  0x00007fa35547e7a8 _mesa_meta_end (i965_dri.so)
   #4  0x00007fa35562fa40 brw_meta_resolve_color (i965_dri.so)
   #5  0x00007fa355680bdd intel_miptree_resolve_color (i965_dri.so)
   #6  0x00007fa355685ee2 intel_readpixels_tiled_memcpy (i965_dri.so)
   #7  0x00007fa35568637b intelReadPixels (i965_dri.so)
   #8  0x00007fa355317716 _mesa_ReadnPixelsARB (i965_dri.so)
   #9  0x00007fa355317767 _mesa_ReadPixels (i965_dri.so)
   #10 0x00007fa358127640 shared_dispatch_stub_256 (libglapi.so.0)
   #11 0x00000000010343eb _ZN3glu10readPixelsERKNS_13RenderContextEiiRKN3tcu17PixelBufferAccessE (deqp-gles3)
   #12 0x0000000000c6772f _ZN4deqp5gles310Functional29ASTCDecompressionCaseInternal14ASTCRenderer2D6renderERN3tcu7SurfaceES6_RKN3glu9Texture2DERKNS4_13TextureFormatE (deqp-gles3)
   #13 0x0000000000c6839f _ZN4deqp5gles310Functional15ASTCBlockCase2D7iterateEv (deqp-gles3)
   #14 0x0000000000feab6b _ZN3tcu15TestCaseWrapper15iterateTestCaseEPNS_8TestCaseE (deqp-gles3)
   #15 0x0000000000aacb9f _ZN4deqp5gles315TestCaseWrapper15iterateTestCaseEPN3tcu8TestCaseE (deqp-gles3)
   #16 0x0000000000fec6cd _ZN3tcu12TestExecutor7iterateEv (deqp-gles3)
   #17 0x0000000000fc31e7 _ZN3tcu3App7iterateEv (deqp-gles3)
   #18 0x0000000000aa92d9 main (deqp-gles3)
   #19 0x00007fa3583a0610 __libc_start_main (libc.so.6)
   #20 0x0000000000aa90c9 _start (deqp-gles3)
Comment 1 Neil Roberts 2015-12-08 16:41:09 UTC
It looks like this is a bug with GL_KHR_surfaceless_context which deqp is using when the target is DRM. With this extension the read and draw surfaces can be NULL. When glViewport is called the i965 driver tries to invalidate these two surfaces so it crashes on the NULL pointer.

Ben's patch makes it hit this bug because glViewport is called when restoring the saved meta state after doing a fast clear. The saved meta state is using the window system draw buffer which in this case will be NULL.

I've made a patch for this here:

http://patchwork.freedesktop.org/patch/67357/

And a piglit test case here:

http://patchwork.freedesktop.org/patch/67356/
Comment 2 Nanley Chery 2015-12-09 19:20:34 UTC
*** Bug 90821 has been marked as a duplicate of this bug. ***
Comment 3 Nanley Chery 2016-01-19 18:27:48 UTC
The patch Neil sent was committed to master last month.


bug/show.html.tmpl processed on Mar 25, 2017 at 17:29:14.
(provided by the Example extension).