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)
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/
*** Bug 90821 has been marked as a duplicate of this bug. ***
The patch Neil sent was committed to master last month.
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.