With Mesa master (80771e4) glb2.7 does not start but instead says: GLBenchmark: brw_fs_live_variables.cpp:141: void brw::fs_live_variables::setup_def_use(): Assertion `ip == block->start_ip' failed. Bisected to: ------------------- 8< ------------------------------------ commit 20a849b4aa63c7fce96b04de674a4c70f054ed9c Author: Matt Turner <mattst88@gmail.com> Date: Sat Jul 12 21:18:39 2014 -0700 i965: Use basic-block aware insertion/removal functions. To avoid invalidating and recreating the control flow graph. Also stop invalidating the CFG in places we didn't add or remove an instruction. cfg calculations: 202951 -> 80307 (-60.43%) Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Forgot to mention that this was on SNB desktop, on IVB laptop it seems to work fine. On SNB we end up like this (where ip is 5 and block->start_ip is 7) : --- 8< --- #3 0x00000033e982ea02 in __GI___assert_fail (assertion=0x7ffff74b4d69 "ip == block->start_ip", file=0x7ffff74b4d36 "brw_fs_live_variables.cpp", line=143, function=0x7ffff74b4e40 <brw::fs_live_variables::setup_def_use()::__PRETTY_FUNCTION__> "void brw::fs_live_variables::setup_def_use()") at assert.c:101 #4 0x00007ffff73bbac3 in brw::fs_live_variables::setup_def_use (this=this@entry=0xafca20) at brw_fs_live_variables.cpp:143 #5 0x00007ffff73bbeed in brw::fs_live_variables::fs_live_variables (this=0xafca20, v=<optimized out>, cfg=0xad9a60) at brw_fs_live_variables.cpp:284 #6 0x00007ffff73bc045 in fs_visitor::calculate_live_intervals (this=this@entry=0x7fffffffc6a0) at brw_fs_live_variables.cpp:328 #7 0x00007ffff73ad5b4 in fs_visitor::opt_cse (this=this@entry=0x7fffffffc6a0) at brw_fs_cse.cpp:317
WebGL Aquarium in Chrome on Ironlake also hits this assertion. GLBenchmark 2.7 on Ironlake segfaults, and appears to be accessing basic-block related data.
I think this is fixed by one of the commits today since 3e248e04. Please confirm.
I've tested, the bug still exists on Mesa head (dc0bd79)
(In reply to comment #4) > I've tested, the bug still exists on Mesa head (dc0bd79) This run was against wrong Mesa though :/ After some more morning coffee I can see that the bug is fixed, thanks!
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.