<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - GPU lockups in Left 4 Dead 2" href="https://bugs.freedesktop.org/show_bug.cgi?id=90378#c2">Comment # 2</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - GPU lockups in Left 4 Dead 2" href="https://bugs.freedesktop.org/show_bug.cgi?id=90378">bug 90378</a> from <a class="email" href="mailto:daniel@constexpr.org" title="Daniel Scharrer <daniel@constexpr.org>"> Daniel Scharrer</a> <pre>Created <a href="attachment.cgi?id=115951" name="attach_115951" title="patch to revert LLVM r233366 (fixes lockups)">attachment 115951</a> <a href="attachment.cgi?id=115951&action=edit" title="patch to revert LLVM r233366 (fixes lockups)">[details]</a> <a href='page.cgi?id=splinter.html&bug=90378&attachment=115951'>[review]</a> patch to revert LLVM r233366 (fixes lockups) This seems to be a regression in llvm: Mesa git + LLVM svn is bad Mesa 10.5.5 + LLVM svn is bad Mesa git + LLVM 3.6.0 is good (no lockups, no glitches) With Mesa git, the lockups in the L4D2 apitrace linked above bisect to LLVM r233366: commit 9217916725713c00f17cb64123e8dffdae843eb7 Author: Andrew Trick <<a href="mailto:atrick@apple.com">atrick@apple.com</a>> Date: Fri Mar 27 06:10:13 2015 +0000 Complete the MachineScheduler fix made way back in r210390. "Fix the MachineScheduler's logic for updating ready times for in-order. Now the scheduler updates a node's ready time as soon as it is scheduled, before releasing dependent nodes." This fix was only made in one variant of the ScheduleDAGMI driver. Francois de Ferriere reported the issue in the other bit of code where it was also needed. I never got around to coming up with a test case, but it's an obvious fix that shouldn't be delayed any longer. I'll try to refactor this code a little better. I did verify performance on a wide variety of targets and saw no negative impact with this fix. git-svn-id: <a href="https://llvm.org/svn/llvm-project/llvm/trunk@233366">https://llvm.org/svn/llvm-project/llvm/trunk@233366</a> 91177308-0d34-0410-b5e6-96231b3b80d8 I had to revert b8797a7 and a99a16a in Mesa for it to build against that LLVM revision. Besides the arch-specific test files, r233366 only moves one line of code around. Reverting that on current LLVM (see attached patch) also fixes the lockups. As with <a class="bz_bug_link bz_status_NEW " title="NEW - [radeon][tahiti xt] IA_MULTI_VGT_PARAM programming seems broken" href="show_bug.cgi?id=90510">bug #90510</a>, R600_DEBUG=switch_on_eop gets rid of the glitches, and also prevents the crashes as well. Not sure if that means it could be a bug in Mesa or if that just hides the LLVM bug. While bisecting for the lockup, I noticed the glitches were also introduced in LLVM after 3.6.0, but not by the same revision - f74b5c6 (r231401) has no lockups but does have glitches. I'll bisect that for <a class="bz_bug_link bz_status_NEW " title="NEW - [radeonsi][regression,bisected] Depth test/buffer issues in Portal" href="show_bug.cgi?id=88561">bug #88561</a> as the glitches in the latest Talos apitrace there also seem to come from that commit range. (The GPU faults - <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - Packet0 not allowed and GPU fault detected errors with Serious Engine games" href="show_bug.cgi?id=87278">bug #87278</a> - seem to have yet another cause, being present even with LLVM 3.6.0.) NB: I also noticed that with compositing enabled in KWin, the system is not able to recover from the GPU lockups (and eventually does not even respond to SSH or SysRq). With compositing disabled the GPU is almost always reset successfully and the game / glretrace can continue as if nothing happened.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>