Bug 58384

Summary: [i965 Bisected]Oglc max_values(advanced.fragmentProgram.GL_MAX_PROGRAM_ENV_PARAMETERS_ARB) segfault
Product: Mesa Reporter: lu hua <huax.lu>
Component: Drivers/DRI/i965Assignee: Eric Anholt <eric>
Status: VERIFIED FIXED QA Contact:
Severity: major    
Priority: high CC: idr, xunx.fang
Version: unspecified   
Hardware: All   
OS: Linux (All)   
i915 platform: i915 features:

Description lu hua 2012-12-17 03:13:53 UTC
System Environment:
Arch:           x86_64
Platform:       Ivybridge
Libdrm:		(master)libdrm-2.4.40-3-g0980633afd9c7eecc0c75ef3bea4d3c6b7aa1898
Mesa:		(master)4f91f8dd6057b73d05454fc626985183d00e5236
Cairo:		(master)9d9aa04b60e24542b6b2a4c6bf87115db7736c2f
Libva:		(staging)b8d3cf092c9b07cfd909552a3c160b7db3b5a91d
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|

       8|       8|       8|      24|       8|       0|       0|       0|

       0|       0|       0|    none|   undef|       0|       0|       0

Reproduce steps:
1. start X
2. ./oglconform -z -suite all -v 2 -minFmt -test max_values \
Comment 1 Gordon Jin 2013-02-18 04:42:58 UTC
Xun, can you check if it still exists with the latest master and 9.1 branch?
Comment 2 fangxun 2013-02-21 07:41:36 UTC
It still exists with the latest master and 9.1 branch.
Comment 3 Eric Anholt 2013-02-22 19:55:30 UTC
Are you perhaps on a memory-limited machine without swap?
Comment 4 lu hua 2013-02-26 07:42:14 UTC
(In reply to comment #3)
> Are you perhaps on a memory-limited machine without swap?

Test machines have swap.
Comment 5 Eric Anholt 2013-06-08 00:41:17 UTC
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.
Comment 6 Eric Anholt 2013-06-26 08:30:15 UTC
commit da00782ed81776473270028cda262c913d737438
Author: Eric Anholt <eric@anholt.net>
Date:   Thu Jun 6 13:21:21 2013 -0700

    ra: Fix register spilling.
Comment 7 lu hua 2013-07-08 07:30:38 UTC

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.