Created attachment 112524 [details] /sys/class/drm/card0/error I'm getting: [ 3414.543423] [drm] stuck on render ring [ 3414.546805] [drm] GPU HANG: ecode 5:0:0x95defffc, in quakelive.exe [6044], reason: Ring hung, action: reset [ 3414.560063] drm/i915: Resetting chip after gpu hang [ 3420.567108] [drm] stuck on render ring [ 3420.570540] [drm] GPU HANG: ecode 5:0:0xf18efffc, in quakelive.exe [6044], reason: Ring hung, action: reset [ 3420.570652] [drm:i915_set_reset_status [i915]] *ERROR* gpu hanging too fast, banning! [ 3420.583838] drm/i915: Resetting chip after gpu hang This happens only with INTEL_USE_NIR=1. It seems that this is caused by some of the latest commits, NIR worked fine 3 days ago. /sys/class/drm/card0/error attached.
We'd need - INTEL_DEBUG=fs output - to know what generation of hardware you're using - what application you were using - a bisection would be great But I'm not even sure that we're ready to start taking bug reports on NIR.
Created attachment 112720 [details] NTEL_DEBUG=fs output
(In reply to Matt Turner from comment #1) > We'd need > > - INTEL_DEBUG=fs output > - to know what generation of hardware you're using > - what application you were using > - a bisection would be great > > But I'm not even sure that we're ready to start taking bug reports on NIR. - INTEL_DEBUG=fs output attached - Ironlake - quakelive on wine - seems to be this commit: a5ca86a9833d6fd57ee609d8d1e630dc66ebd371
(In reply to dimon from comment #3) > (In reply to Matt Turner from comment #1) > > We'd need > > > > - INTEL_DEBUG=fs output > > - to know what generation of hardware you're using > > - what application you were using > > - a bisection would be great > > > > But I'm not even sure that we're ready to start taking bug reports on NIR. > > - INTEL_DEBUG=fs output attached > - Ironlake > - quakelive on wine > - seems to be this commit: a5ca86a9833d6fd57ee609d8d1e630dc66ebd371 Which is "i965/nir: Enable SIMD16 support in the NIR FS backend." This probably means that we're generating a SIMD16 shader on ILK that is invalid on that hardware. Can you provide the output of 'INTEL_DEBUG=fs' with and without INTEL_USE_NIR? That should help narrow down which shader is incorrectly getting SIMD16.
Created attachment 112750 [details] INTEL_DEBUG=fs output without NIR
(In reply to dimon from comment #5) > Created attachment 112750 [details] > INTEL_DEBUG=fs output without NIR In the case it wasn't clear, I've already attached INTEL_DEBUG=fs output with NIR enabled.
(In reply to dimon from comment #3) > - Ironlake That's almost certainly the problem. We don't handle the different representation of boolean true, we don't split MAD instructions, and we don't split LRPs.
Should be all good now.
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.