Bug 24355 - [i965] Assertion `c->nr_refs < ((1024*3 + FRAG_ATTRIB_MAX + 3) * 4)' failed.
Summary: [i965] Assertion `c->nr_refs < ((1024*3 + FRAG_ATTRIB_MAX + 3) * 4)' failed.
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium critical
Assignee: Ian Romanick
QA Contact:
URL:
Whiteboard:
Keywords:
: 27302 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-10-06 12:50 UTC by Vinson Lee
Modified: 2012-10-09 21:34 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Vinson Lee 2009-10-06 12:50:16 UTC
System environment:
-- chipset: GM45
-- system architecture: i686
-- xserver-xorg-video-intel: 2:2.8.1-1ubuntu2
-- xserver-common: 2:1.6.3-1ubuntu7
-- mesa: 017fae04ec75818bb6ace3a0dcda67d29947a1bd (master)
-- libdrm2: 2.4.13-1ubuntu1
-- kernel version: 2.6.31-12-generic
-- Linux distribution: Ubuntu 9.10
-- Machine model: Dell Latitude E6400

Run piglit test fp-long-alu.


(gdb) bt
#0  0x00794422 in __kernel_vsyscall ()
#1  0x001fc4d1 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0x001ff932 in *__GI_abort () at abort.c:92
#3  0x001f5648 in *__GI___assert_fail (assertion=0x124b92c "c->nr_refs < ((1024*3 + FRAG_ATTRIB_MAX + 3) * 4)", file=0x124b88a "brw_wm_pass0.c", line=50, 
    function=0x124b9e6 "get_value") at assert.c:81
#4  0x010957cd in get_value (c=<value optimized out>, inst=<value optimized out>) at brw_wm_pass0.c:50
#5  pass0_set_dst (c=<value optimized out>, inst=<value optimized out>) at brw_wm_pass0.c:251
#6  translate_insn (c=<value optimized out>, inst=<value optimized out>) at brw_wm_pass0.c:338
#7  0x01095904 in brw_wm_pass0 (c=0xb7160008) at brw_wm_pass0.c:434
#8  0x0107b843 in brw_wm_non_glsl_emit (brw=0x9328a68) at brw_wm.c:101
#9  do_wm_prog (brw=0x9328a68) at brw_wm.c:179
#10 brw_prepare_wm_prog (brw=0x9328a68) at brw_wm.c:353
#11 0x010739c7 in brw_validate_state (brw=0x9328a68) at brw_state_upload.c:322
#12 0x010655ac in brw_try_draw_prims (ctx=0x9328a68, arrays=0x9366f2c, prim=0xbf806060, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3)
    at brw_draw.c:371
#13 brw_draw_prims (ctx=0x9328a68, arrays=0x9366f2c, prim=0xbf806060, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3) at brw_draw.c:454
#14 0x011335b9 in vbo_exec_DrawArrays (mode=7, start=0, count=4) at vbo/vbo_exec_array.c:523
#15 0x011282d2 in neutral_DrawArrays (mode=7, start=0, count=4) at main/vtxfmt_tmp.h:328
#16 0x00d5fc18 in glDrawArrays (mode=7, first=0, count=4) at ../../../src/mesa/glapi/glapitemp.h:1645
#17 0x0804aefc in piglit_draw_rect ()
#18 0x08049fb4 in test ()
#19 0x0804a240 in piglit_display ()
#20 0x0804b0db in display ()
#21 0x007d52a7 in processWindowWorkList (window=0x9315de0) at glut_event.c:1306
#22 0x007d62e9 in __glutProcessWindowWorkLists () at glut_event.c:1356
#23 glutMainLoop () at glut_event.c:1377
#24 0x0804b1b6 in main ()
(gdb) frame 4
#4  0x010957cd in get_value (c=<value optimized out>, inst=<value optimized out>) at brw_wm_pass0.c:50
50	   assert(c->nr_refs < BRW_WM_MAX_VREG);
(gdb) print c->nr_refs
$6 = 4294411397


src/mesa/drivers/dri/i965/brw_wm_pass0.c
    48  static struct brw_wm_value *get_value( struct brw_wm_compile *c)
    49  {
    50     assert(c->nr_refs < BRW_WM_MAX_VREG);
    51     return &c->vreg[c->nr_vreg++];
    52  }
Comment 1 Eric Anholt 2009-10-30 14:07:12 UTC
Partially fixed with:

commit cb132406ded760a622513cd1ab86bf83bb945671
Author: Eric Anholt <eric@anholt.net>
Date:   Fri Oct 30 13:28:44 2009 -0700

    i965: Add an index assert on get_fp_inst array like other compiler arrays.

But the program fails on swrast as well, once it's made to use PROGRAM_INSTRUCTIONS instead of NATIVE_PROGRAM_INSTRUCTIONS if NATIVE == 0.  I think Mesa should set NATIVE_FOO to FOO for swrast -- any objections?

The swrast problem boils down to a new assert I threw into the program parser:

Testing: alu_depth = 1541
fp-long-alu: program_parse.y:2479: initialize_symbol_from_const: Assertion `idx < (1 << 10)' failed.

This whole 10-bits-of-index thing seems to be a continuous source of errors.  Can we just make it 32 bits already?

Comment 2 Brian Paul 2009-10-30 18:06:49 UTC
OK, so all those literals like { 0.062500, 0.000000, 0.000000, 0.000000 } are getting saved with _mesa_add_parameter() until we have 1024 of them at which point we overflow the prog_src_register::Index field which is limited to [-1024,1023].

I think the solution to this particular problem is to use _mesa_add_unnamed_constant() in initialize_symbol_from_const().  That function looks for swizzled variations of vector constants and returns a swizzle mask.  But that would require adding a swizzle field to struct asm_symbol (and some code to handle it elsewhere).

Also, we should then check if the index returned by _mesa_add_unnamed_constant() exceeds state->limits->MaxParameters.

Ian?

In the mean time, I've got a patch that does additional checking of src/dst fields.
Comment 3 Brian Paul 2009-10-30 18:07:37 UTC
(In reply to comment #1)
> Partially fixed with:
> 
> commit cb132406ded760a622513cd1ab86bf83bb945671
> Author: Eric Anholt <eric@anholt.net>
> Date:   Fri Oct 30 13:28:44 2009 -0700
> 
>     i965: Add an index assert on get_fp_inst array like other compiler arrays.
> 
> But the program fails on swrast as well, once it's made to use
> PROGRAM_INSTRUCTIONS instead of NATIVE_PROGRAM_INSTRUCTIONS if NATIVE == 0.  I
> think Mesa should set NATIVE_FOO to FOO for swrast -- any objections?

Can you suggest a patch?  I don't have time to investigate this right now.
Comment 4 Eric Anholt 2010-03-25 17:34:32 UTC
*** Bug 27302 has been marked as a duplicate of this bug. ***
Comment 5 Eric Anholt 2012-10-09 21:34:38 UTC
commit 97615b2d8c7c3cea6fd3a43bcb1739a96e2046c4
Author: Eric Anholt <eric@anholt.net>
Date:   Mon Aug 27 14:35:01 2012 -0700

    i965: Replace brw_wm_* with dumping code into the fs_visitor.


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.