System Environment: -------------------------- Arch: x86_64 Platform: Ivybridge Libdrm: (master)libdrm-2.4.40-3-g0980633afd9c7eecc0c75ef3bea4d3c6b7aa1898 Mesa: (master)4f91f8dd6057b73d05454fc626985183d00e5236 Xserver:(master)xorg-server-1.13.0-188-gb51a1bd2766e7dc975ca8f1cacc3f8bd0e1a68a3 Xf86_video_intel:(master)2.20.16 Cairo: (master)9d9aa04b60e24542b6b2a4c6bf87115db7736c2f Libva: (staging)b8d3cf092c9b07cfd909552a3c160b7db3b5a91d Libva_intel_driver:(staging)82a4a3915821dd2a302ca87d21dfcd945f2500af Kernel: (drm-intel-nightly) 70880564238362d96181fb54d0edf1a5bf5b24cc Bug detailed description: ------------------------- It segfaults on Ironlake,Sandybridge,Ivybridge,Haswell with mesa master branch.It works well on mesa 9.0 branch. max_values(advanced.fragmentProgram.GL_MAX_PROGRAM_LOCAL_PARAMETERS) also segfaults on ivybridge, and has same bisect commit. Bisect show: 456dbcc3377ee23dbeffa4da02a4d80a8519bb62 is the first bad commit. commit 456dbcc3377ee23dbeffa4da02a4d80a8519bb62 Author: Eric Anholt <eric@anholt.net> AuthorDate: Mon Dec 3 19:59:55 2012 -0800 Commit: Eric Anholt <eric@anholt.net> CommitDate: Fri Dec 14 15:17:59 2012 -0800 i965/fs: Before reg alloc, schedule instructions to reduce live ranges. This came from an idea by Ben Segovia. 16-wide pixel shaders are very important for latency hiding on i965, so we want to try really hard to get them. If scheduling an instruction makes some set of instructions available, those are probably the ones that make the instruction's result dead. By choosing those first, we'll have a tendency to reduce the amount of live data as opposed to creating more. Previously, we were sometimes getting this behavior out of the scheduler, which was what produced the scheduler's original performance wins on lightsmark. Unfortunately, that was mostly an accident of the lame instruction latency information that I had, which made it impossible to fix the actual scheduling for performance. Now that we've fixed the scheduling for setup for register allocation, we can safely update the latency parameters for the final schedule. In shader-db, we lose 37 16-wide shaders, but gain 90 new ones. 4 shaders that were spilling change how many registers spill, for a reduction of 70/3899 instructions. v2: Simplify the new loop. (gdb) bt #0 brw_wm_fs_emit (brw=0x2ed1d00, c=0x32b07a0, fp=0x32d3fa0, prog=0x0, final_assembly_size=0x7fffffffccac) at brw_fs.cpp:2609 #1 0x00007ffff6735c21 in do_wm_prog (brw=0x2ed1d00, prog=0x0, fp=0x32d3fa0, key=0x7fffffffccf0) at brw_wm.c:175 #2 0x00007ffff673643d in brw_upload_wm_prog (brw=0x2ed1d00) at brw_wm.c:489 #3 0x00007ffff6714d82 in brw_upload_state (brw=0x2ed1d00) at brw_state_upload.c:500 #4 0x00007ffff66d87c7 in brw_try_draw_prims (max_index=<optimized out>, min_index=<optimized out>, ib=0x2f23294, nr_prims=49146720, prim=0x2f2327c, arrays=<optimized out>, ctx=0x2ed1d00) at brw_draw.c:498 #5 brw_draw_prims (ctx=0x2ed1d00, prim=0x2f2327c, nr_prims=49146720, ib=0x2f23294, index_bounds_valid=<optimized out>, min_index=0, max_index=3, tfb_vertcount=0x0) at brw_draw.c:585 #6 0x00007ffff623a6f5 in vbo_exec_vtx_flush (exec=0x2f229e8, keepUnmapped=1 '\001') at ../../../src/mesa/vbo/vbo_exec_draw.c:400 #7 0x00007ffff622b9ac in vbo_exec_FlushVertices_internal (exec=0x2f229e8, unmap=<optimized out>) at ../../../src/mesa/vbo/vbo_exec_api.c:551 #8 0x00007ffff623817c in vbo_exec_FlushVertices (ctx=0x2ed1d00, flags=<optimized out>) at ../../../src/mesa/vbo/vbo_exec_api.c:1249 #9 0x00007ffff6187c30 in _mesa_set_enable (ctx=0x2ed1d00, cap=34820, state=0 '\000') at ../../../src/mesa/main/enable.c:886 #10 0x00000000007211f7 in oglConf::max_values::genericProgramEnvParametersTest(bool) () #11 0x0000000000722792 in MaxValuesExec(testParameters*) () #12 0x00000000016b0aa9 in callFunctionHandleExceptionsInner(long (*)(testParameters*), testParameters*, char*) () #13 0x00000000016b0bff in callFunctionHandleExceptions(long (*)(testParameters*), testParameters*) () #14 0x00000000016af891 in DriverExec(long (*)(testParameters*), testParameters*) () #15 0x00000000015e63b5 in Driver(std::vector<std::pair<std::string, std::string>, std::allocator<std::pair<std::string, std::string> > > const&, std::vector<driverRec*, std::allocator<driverRec*> > const&, std::vector<boost::shared_ptr<PrePostTestAction>, std::allocator<boost::shared_ptr<PrePostTestAction> > > const&, std::vector<boost::shared_ptr<PrePostTestcaseAction>, std::allocator<boost::shared_ptr<PrePostTestcaseAction> > > const&) () #16 0x00000000015e6e68 in (anonymous namespace)::MyMessagePump::idle() () #17 0x00000000015b7e70 in MessagePump::process_messages() () #18 0x00000000015e53dc in ExecutionManager::execute_schedules() () #19 0x00000000015851e7 in tkShellExecute(std::vector<std::pair<std::string, std::string>, std::allocator<std::pair<std::string, std::string> > > const&, std::vector<std::pair<std::string, std::string>, std::allocator<std::pair<std::string, std::string> > > const&) () #20 0x0000000000428265 in main () Visual Report: ID |ACCELERA|DB |REND_T |SURF_T |C_BUF_T |BUF_S |RED_S | 142| 1| 1| gl| wipbpx| rgba| 32| 8| GREEN_S |BLUE_S |ALPHA_S |DEPTH_S |STENC_S |ACCUM_S |SPL_BUF |SAMPLES | 8| 8| 8| 24| 8| 0| 0| 0| SRGB |TEX_RGB |TEX_RGBA|CAVEAT |SWAP |M_PBUF_W|M_PBUF_H|M_PBUF_P 0| 0| 0| none| undef| 0| 0| 0 Reproduce steps: ---------------- 1. start X 2. ./oglconform -z -suite all -v 2 -minFmt -test max_values \ advanced.fragmentProgram.GL_MAX_PROGRAM_ENV_PARAMETERS_ARB
Xun, can you check if it still exists with the latest master and 9.1 branch?
It still exists with the latest master and 9.1 branch.
Are you perhaps on a memory-limited machine without swap?
(In reply to comment #3) > Are you perhaps on a memory-limited machine without swap? Test machines have swap.
This test was assertion failing due to shader compile failure, and I guess it would have resulted in a segfault on a release build. Was this bug report done from a release build of Mesa? Patch on the mailing list.
commit da00782ed81776473270028cda262c913d737438 Author: Eric Anholt <eric@anholt.net> Date: Thu Jun 6 13:21:21 2013 -0700 ra: Fix register spilling.
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.