<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [BYT, HSW, SKL, BXT, KBL] GPU hangs with GfxBench 4.0 CarChase" href="https://bugs.freedesktop.org/show_bug.cgi?id=96743#c15">Comment # 15</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [BYT, HSW, SKL, BXT, KBL] GPU hangs with GfxBench 4.0 CarChase" href="https://bugs.freedesktop.org/show_bug.cgi?id=96743">bug 96743</a> from <a class="email" href="mailto:topi.pohjolainen@intel.com" title="Topi Pohjolainen <topi.pohjolainen@intel.com>"> Topi Pohjolainen</a> <pre>I still haven't reached the root cause but having tried various things I thought better listing down some possibly interesting bits: 1) Making clears a no-op gives me a hang in L3 cache reconfig (see gen7_l3_state.c::setup_l3_config()). Specifically in the register write: MI_LOAD_REGISTER_IMM. 2) Making the L3 cache reconfig a no-op in turn moves the hang into compute pipeline (carchase also renders some bits using GPGPU). There it hits the second flush issued by intel_fbo.c::brw_render_cache_set_check_flush(). 3) Here I started reading specs again and found a bit we are currently ignoring in few places. SKL PRM, Volume 7, Flush Types: Tex invalidate: Requires stall bit ([20] of DW) set for all GPGPU Workloads. I added logic considering the current renderer (brw->last_pipeline == BRW_COMPUTE_PIPELINE) and using additionally the CS stall bit for compute (for the L3 and render cache flush). 4) But all this simply gave me the hang again in brw_render_cache_set_check_flush() but now in 3D pipeline.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>