Bug 30173

Ran it inside gdb and got a stack trace:


#0  0x00007ffff5a46575 in raise () from /lib/libc.so.6
#1  0x00007ffff5a47d80 in abort () from /lib/libc.so.6
#2  0x00007ffff5a3f601 in __assert_fail () from /lib/libc.so.6
#3  0x00007fffea364e68 in brw_reg (file=<value optimized out>, nr=<value optimized out>, subnr=<value optimized out>, type=<value optimized out>, vstride=4160501600, width=4122268106, hstride=1, 
    swizzle=228, writemask=15) at brw_eu.h:174
#4  0x00007fffea3669b8 in brw_vec8_reg (c=0x7ffffffd1eb0) at brw_eu.h:226
#5  brw_vec8_grf (c=0x7ffffffd1eb0) at brw_eu.h:469
#6  brw_vs_alloc_regs (c=0x7ffffffd1eb0) at brw_vs_emit.c:310
#7  0x00007fffea368996 in brw_vs_emit (c=0x7ffffffd1eb0) at brw_vs_emit.c:1669
#8  0x00007fffea36468e in do_vs_prog (brw=0x7c4130, vp=<value optimized out>, key=0x7fffffffcb40) at brw_vs.c:85
#9  0x00007fffea36485e in brw_upload_vs_prog (brw=0x7c4130) at brw_vs.c:149
#10 0x00007fffea363856 in brw_validate_state (brw=0x7c4130) at brw_state_upload.c:396
#11 0x00007fffea3560f4 in brw_try_draw_prims (ctx=0x7c4130, arrays=<value optimized out>, prim=<value optimized out>, nr_prims=1, ib=<value optimized out>, index_bounds_valid=<value optimized out>, 
    min_index=0, max_index=7) at brw_draw.c:363
#12 brw_draw_prims (ctx=0x7c4130, arrays=<value optimized out>, prim=<value optimized out>, nr_prims=1, ib=<value optimized out>, index_bounds_valid=<value optimized out>, min_index=0, max_index=7)
    at brw_draw.c:448
#13 0x00007fffea439305 in vbo_exec_DrawArrays (mode=5, start=0, count=<value optimized out>) at vbo/vbo_exec_array.c:526
#14 0x00000000004479cb in WorldMap::RenderMap(Camera*, double, float) ()
#15 0x000000000046503b in UI_Map::RenderSceneToMap() ()
#16 0x00000000004653b9 in UI_Map::UI_Map(unsigned int) ()
#17 0x000000000047ef85 in UserControls::UserControls(char*, int, int, int, int, float) ()
#18 0x000000000044ba29 in ProcessEngineStateChanges() ()
#19 0x000000000044bc79 in MainLoopIteration() ()
#20 0x000000000040a977 in Platform_MainLoop(void (*)()) ()
#21 0x000000000044b68d in main ()

Created attachment 38725 [details]
dump of some shader state

I poked around with GDB a bit more and did:

(gdb) up 9
#9  0x00007fffea36485e in brw_upload_vs_prog (brw=0x7c4130) at brw_vs.c:149
149	      do_vs_prog(brw, vp, &key);


(gdb) call _mesa_print_program_parameters(&brw->intel.ctx, (struct gl_program *) brw->vertex_program )
(gdb) call _mesa_print_program((struct gl_program *) brw->vertex_program)
(gdb) call _mesa_print_program_parameters(&brw->intel.ctx, (struct gl_program *) brw->fragment_program )
(gdb) call _mesa_print_program((struct gl_program *) brw->fragment_program)

I have attached the results

Created attachment 38861 [details]
a bit of output from running with MESA_GLSL=dump

I ran with MESA_GLSL=dump and found the GLSL IR for the shader, I've attached the dump output (and since the MesaIR is slightly different, I included that too)

Is there still a problem here?  That assertion no longer exists in Mesa master, presumably since we now have register spilling.  Also, a fair amount of other compiler changes have occured since the original report, so hopefully we're generating better code as well.

If there's still an issue, INTEL_DEBUG=wm may be of interest as well (though the MESA_GLSL=dump output is very helpful - thanks!)

Note that the failure was in the VS, not the FS.  The problem is that there's this loop to be unrolled that doesn't get unrolled, which does array access, so Mesa IR can't figure out which variables can be copy propagated since there are no sizes to Mesa IR storage, and we run out of storage.

This would be fixed by a native VS backend, or by better unrolling (which may already be the case -- could you retest with Mesa master?).

(In reply to comment #5)
> Note that the failure was in the VS, not the FS.  The problem is that there's
> this loop to be unrolled that doesn't get unrolled, which does array access, so
> Mesa IR can't figure out which variables can be copy propagated since there are
> no sizes to Mesa IR storage, and we run out of storage.
> 
> This would be fixed by a native VS backend, or by better unrolling (which may
> already be the case -- could you retest with Mesa master?).

Still happens. It's not terribly supported since it only happens in an unsupported configuration for the game, but still it might affect someone else in a situation that's actually supposed to work.

The new VS backend is now available under INTEL_NEW_VS=1, and will be on by default shortly.  I think it's likely to fix the problem, though there's a chance that another assertion might happen which I plan on fixing tomorrow.

Looking at the code previously generated, this should be fixed now that the new VS is on by default.