| Summary: | [i965gm] GPU hang, stray GL_DEPTH_BUFFER clear | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Bryce Harrington <bryce> |
| Component: | Drivers/DRI/i965 | Assignee: | Ian Romanick <idr> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | high | CC: | bgamari |
| Version: | 8.0 | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
BootDmesg.txt
CurrentDmesg.txt i915_error_state.txt XorgLog.txt Screenshot from 2012-04-12 12:05:52.png Another crash dump Yet another dump i915_error_state from odd hang crash-20120419-1230 crash-20120419-1233 crash-20120419-1242 |
||
|
Description
Bryce Harrington
2012-04-17 10:20:49 UTC
Created attachment 60189 [details]
BootDmesg.txt
Created attachment 60190 [details]
CurrentDmesg.txt
Created attachment 60191 [details]
i915_error_state.txt
Created attachment 60192 [details]
XorgLog.txt
Created attachment 60193 [details]
Screenshot from 2012-04-12 12:05:52.png
The error-state looks ordinary and more importantly self-consistent. There are not the tell-tales of recent bugs, so I currently have no explanation for the hang. Can you please attach a few more error-states to see if a pattern forms? Created attachment 60321 [details]
Another crash dump
The panel was inactive although the machine was responsive over SSH.
In the second crash dump, mesa overwrote our batch performing a depth-clear. One more... Created attachment 60322 [details]
Yet another dump
(In reply to comment #9) > Created attachment 60322 [details] > Yet another dump This wasn't a hang, so I'm not going to use its vote as to whether there is an underlying UXA bug here... Created attachment 60323 [details]
i915_error_state from odd hang
This time I couldn't get the rest of the dump as cat BUGs in i915_batchbuffer_info. Nevertheless, here is i915_error_state.
Created attachment 60324 [details]
crash-20120419-1230
That time, the stray depth clear hit a Mesa batch buffer. With 3 clear errors, let's presume this is the first and foremost the stray clear that's causing the hangs. Created attachment 60325 [details]
crash-20120419-1233
Created attachment 60327 [details]
crash-20120419-1242
I can confirm that the problem appears to be gone with mesa master (dbf48e88) The 8.0 branch (6fe42b6) exhibits the problem. (In reply to comment #17) > The 8.0 branch (6fe42b6) exhibits the problem. To clarify the 8.0 branch (currently 49ed43b6) exhibits the issue as does 6fe42b6, the point where master diverged from 8.0. 8f5c172c does not exhibit the problem 952ca07 exhibits the problem. 7335cf1c exhibits the problem. 9be0f9 exhibits the issue. dbadd39 does not exhibit the problem. f00c97b does not exhibit the problem. 117a0e9 exhibits the problem. 308c6be exhibits the problem. fbe8543 does not exhibit the problem. e2dce7f does not exhibit the problem. Here is the first working commit: commit e2dce7f7ee3e7da9cbb0bb33307ecd79e824426d Author: Eric Anholt <eric@anholt.net> Date: Fri Feb 10 12:54:25 2012 -0800 intel: Fix rendering from textures after RenderTexture(). There's a serious trap for drivers: RenderTexture() does not indicate that the texture is currently bound to the draw buffer, despite FinishRenderTexture() signaling that the texture is just now being unbound from the draw buffer. We were acting as if RenderTexture() *was* the start of rendering and that we could make texturing incoherent with the current contents of the renderbuffer. This caused intel oglconform sRGB Mipmap.1D_textures to fail, because we got a call to TexImage() and thus RenderTexture() on a texture bound to a framebuffer that wasn't the draw buffer, so we skipped validating the new image into the texture object used for rendering. We can't (easily) make RenderTexture() indicate the start of drawing, because both our driver and gallium are using it as the moment to set up the renderbuffer wrapper used for things like MapRenderbuffer(). Instead, postpone the setup of the workaround render target miptree until update_renderbuffer time, so that we no longer need to skip validation of miptrees used as render targets. As a bonus, this should make GL_NV_texture_barrier possible. (This also fixes a regression in the gen4 small-mipmap rendering since 3b38b33c1648b07e75dc4d8340758171e109c598, which switched set_draw_offset from image->mt to irb->mt but didn't move the irb->mt replacement up before set_draw_offset). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44961 NOTE: This is a candidate for the 8.0 branch. Pushed the cherry pick. |
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.