| Summary: | i965: NIR doesn't work on Gen < 6 | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | dimon |
| Component: | Drivers/DRI/i965 | Assignee: | Ian Romanick <idr> |
| Status: | RESOLVED FIXED | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | git | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
/sys/class/drm/card0/error
NTEL_DEBUG=fs output INTEL_DEBUG=fs output without NIR |
||
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.
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.