System Environment: -------------------------- Platform: SKL Libdrm: (master)libdrm-2.4.59-8-gccbb9aa887f992359335ecf2d26919b04e14e63f Mesa: (master)345e8cc8496b4e6c56105c7396e80d85a37e122c Xserver: (master)xorg-server-1.17.0 Xf86_video_intel: (master)2.99.917-100-g5b033d638bbf2c0b841088ca75f9eb8de5852cb5 Libva: (master)f9741725839ea144e9a6a1827f74503ee39946c3 Libva_intel_driver: (master)9a20d6c34cb65e5b85dd16d6c8b3a215c5972b18 Kernel: (drm-intel-nightly)b4442ee4e150506cebeee72249efc566c5f14bbe Bug detailed description: --------------------------- many Ogles3conform cases core dumped on SKL.It always has this issue. output: dEQP Core GL-CTS-2.0 (0x0052484b) starting.. target implementation = 'X11' Test case 'ES3-CTS.shaders.uniform_block.single_basic_type.shared.lowp_mat3'.. *** Error in `./glcts': free(): invalid size: 0x0000000003d9f5f0 *** Aborted (core dumped) (gdb) bt #0 0x00007ffff5e64bb9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007ffff5e67fc8 in __GI_abort () at abort.c:89 #2 0x00007ffff5eac27d in __malloc_assert (assertion=assertion@entry=0x7ffff5fac8b8 "nclears >= 3", file=file@entry=0x7ffff5fac6c0 "malloc.c", line=line@entry=3266, function=function@entry=0x7ffff5fac9dd <__func__.11481> "__libc_calloc") at malloc.c:293 #3 0x00007ffff5eb1f92 in __libc_calloc (n=<optimized out>, elem_size=<optimized out>) at malloc.c:3266 #4 0x00007ffff430ab72 in ralloc_size (ctx=ctx@entry=0x20bfe78, size=size@entry=260) at ralloc.c:113 #5 0x00007ffff430abce in rzalloc_size (ctx=ctx@entry=0x20bfe78, size=size@entry=260) at ralloc.c:134 #6 0x00007ffff430ac9c in rzalloc_array_size (ctx=ctx@entry=0x20bfe78, size=size@entry=4, count=count@entry=65) at ralloc.c:196 #7 0x00007ffff430b8be in ra_alloc_interference_graph (regs=0x1625b08, count=65) at register_allocate.c:382 #8 0x00007ffff43db9f2 in fs_visitor::assign_regs (this=this@entry=0x7fffffffbe80, allow_spilling=allow_spilling@entry=false) at brw_fs_reg_allocate.cpp:548 #9 0x00007ffff43b747e in fs_visitor::allocate_registers (this=this@entry=0x7fffffffbe80) at brw_fs.cpp:3657 #10 0x00007ffff43b84ba in fs_visitor::run_fs (this=this@entry=0x7fffffffbe80) at brw_fs.cpp:3812 #11 0x00007ffff43b88c7 in brw_wm_fs_emit (brw=brw@entry=0x7ffff7fa1038, mem_ctx=mem_ctx@entry=0x23e9658, key=key@entry=0x7fffffffd150, prog_data=prog_data@entry=0x7fffffffcfb0, fp=fp@entry=0x2095f00, prog=prog@entry=0x20abf88, final_assembly_size=final_assembly_size@entry=0x7fffffffcfac) at brw_fs.cpp:3880 #12 0x00007ffff4431715 in do_wm_prog (brw=0x7ffff7fa1038, prog=0x20abf88, fp=0x2095f00, key=0x7fffffffd150) at brw_wm.c:212 #13 0x00007ffff43b7736 in brw_fs_precompile (ctx=0x7ffff7fa1038, shader_prog=0x20abf88, prog=0x2095f00) at brw_fs.cpp:3997 #14 0x00007ffff440d526 in brw_shader_precompile (sh_prog=0x20abf88, ctx=0x7ffff7fa1038) at brw_shader.cpp:65 #15 brw_link_shader (ctx=0x7ffff7fa1038, shProg=0x20abf88) at brw_shader.cpp:278 #16 0x00007ffff428abc6 in _mesa_glsl_link_shader (ctx=0x7ffff7fa1038, prog=0x20abf88) at program/ir_to_mesa.cpp:3035 #17 0x00007ffff41a9b6a in link_program (ctx=0x7ffff7fa1038, program=<optimized out>) at main/shaderapi.c:932 #18 0x0000000000eae87e in glu::Program::linkProgram(unsigned int, unsigned int, unsigned int, std::string&, unsigned long&) () #19 0x0000000000eadd84 in glu::Program::Program(glu::RenderContext const&, char const*, char const*) () #20 0x00000000007e0d32 in glcts::UniformBlockCase::iterate() () #21 0x0000000000f00a97 in tcu::TestCaseWrapper::iterateTestCase(tcu::TestCase*) () #22 0x00000000007da1a1 in glcts::TestCaseWrapper::iterateTestCase(tcu::TestCase*) () #23 0x0000000000f02190 in tcu::TestExecutor::iterate() () #24 0x0000000000ef5141 in tcu::App::iterate() () #25 0x0000000000541638 in main () ==Reproduce steps== ---------------------------- 1. xinit 2. ./glcts --deqp-case=ES3-CTS.shaders.uniform_block.single_basic_type.shared.lowp_mat3
Is this a regression? If so, is there a bisect?
Bisect shows: 0ac4c272755c75108a10a84ce33bf6a6234985d3 is the first bad commit commit 0ac4c272755c75108a10a84ce33bf6a6234985d3 Author: Kristian Høgsberg <krh@bitplanet.net> AuthorDate: Wed Dec 10 14:59:26 2014 -0800 Commit: Kristian Høgsberg <krh@bitplanet.net> CommitDate: Thu Jan 8 10:13:32 2015 -0800 i965/skl: Always use a header for SIMD4x2 sampler messages SKL+ overloads the SIMD4x2 SIMD mode to mean either SIMD8D or SIMD4x2 depending on bit 22 in the message header. If the bit is 0 or there is no header we get SIMD8D. We always wand SIMD4x2 in vec4 and for fs pull constants, so use a message header in those cases and set bit 22 there. Based on an initial patch from Ken. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
I may have already fixed this in master. Please test master (e93566a15c61c33faa2e694aa18d18e544e857ff)
Test on the latest mesa master branch(commit a2299bfbbd6ed96), It still exists. output: dEQP Core GL-CTS-2.0 (0x0052484b) starting.. target implementation = 'X11' Test case 'ES3-CTS.shaders.uniform_block.single_basic_type.shared.lowp_mat3'.. glcts: malloc.c:3266: __libc_calloc: Assertion `nclears >= 3' failed. Aborted (core dumped)
Created attachment 113543 [details] [review] Only reserve message header space once Please test
Created attachment 113682 [details] [review] Fix uniform pull constant payload size This is the patch for upstream. Ignore the previous.
I've pushed the patch to master now, can you please test?
run ./glcts --deqp-case=ES3-CTS.shaders.uniform_block.single_basic_type.shared.lowp_mat3 output: dEQP Core GL-CTS-2.0 (0x0052484b) starting.. target implementation = 'X11' Test case 'ES3-CTS.shaders.uniform_block.single_basic_type.shared.lowp_mat3'.. Vertex compile time = 11.887000 ms Fragment compile time = 5.257000 ms Link time = 14.381000 ms Pass (Pass) DONE! Test run totals: Passed: 1/1 (100.00%) Failed: 0/1 (0.00%) Not supported: 0/1 (0.00%) Warnings: 0/1 (0.00%)
Verified.Fixed.
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.