| Summary: | [bisected SNB]Mesa demos engine causes GPU hang | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | fangxun <xunx.fang> |
| Component: | Drivers/DRI/i965 | Assignee: | Dan McCabe <zen3d.linux> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | high | ||
| Version: | git | ||
| Hardware: | All | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | i915_error_state for engine | ||
If it's a regression, the bug report should include a bisect. (In reply to comment #1) > If it's a regression, the bug report should include a bisect. Bisect is not a must-to-have info from QA -- I'm not considering lacking of bisect info block bug owner's investigation unless this is only reproducible on QA machine. We can make the effort for bisect, but only when we have free time. Xun, I'm more eager to now if it impacts 7.11 branch? It impacts 7.11 branch. GPU hangs when running engine with mesa 7.11 branch on sandybridge. Bisect is blocked by mesa build failure. skipping the four commit, the last good commit is 5c742ea1ee0cea031cb99651155d0c7521f42b4e. the last bad commit is bb7ff01deb5c1eb813b90da6f40d987a67e2793b, so the first bad commit maybe any of the four skipped commit and bb7ff01deb5c1eb813b90da6f40d987a67e2793b. bb7ff01deb5c1eb813b90da6f40d987a67e2793b(bad) 588cebce2d5b6afd24b72603d744d390481310dd(skip) 04e3f1d3c29c68343e709d566b7fe13d617f8d13(skip) a82a43e8d99e1715dd11c9c091b5ab734079b6a6(skip) 855f56ca13c1003396a81da1a110357d624a2101(skip) 5c742ea1ee0cea031cb99651155d0c7521f42b4e(good) commit 3e5d36267d8c9536490c902f785137a7fa0637fc Author: Eric Anholt <eric@anholt.net> Date: Tue Jul 19 15:06:15 2011 -0700 i965: Apply a homebrew workaround for GPU hang in OGLC api-texcoord. The behavior of flushes in the hardware is a maze of twisty passages, and strangely the VS constants appear to be loaded during a pipeline flush instead of at the time of the packet emit according to the simulator. On moving the STATE_BASE_ADDRESS packet to where it really needed to live (in order for data loads by other packets to be correct), we sometimes no longer got a flush between those packets where we apparently needed it. This replicates the flushes implied by a STATE_BASE_ADDRESS update, fixing the GPU hangs in OGLC and the "engine" demo. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36821 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=39257 Tested-by: Keith Packard <keithp@keithp.com> (bzflag and etracer fixed) Acked-by: Kenneth Graunke <kenneth@whitecape.org> Verified with Mesa master 4c84acc86fce5eda0aabcb8aa362fd6b5e6a28f6 and 7.11 b305c956be3fa27467ecbc379de2352926a554d0. |
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 49140 [details] i915_error_state for engine System Environment: -------------------------- Arch: x86-64 Platform: Huronriver Libdrm: (master)2.4.26-1-g8d055890d90c3d92647e3d8b98d32630ef87c2c8 Mesa: (master)1cf06218e483c1e673e2f19df9116e60478edf30 Xserver: (master)xorg-server-1.10.99.901-106-g82f5521a6d91ebcd2a4400f6c221ad625edc99a1 Xf86_video_intel: (master)2.15.0-203-g212fa9868767637e8f430485eeb522c99e63fd16 Kernel: (drm-intel-next)99834ea446d5c0da3f6cfa355fe4670840d45f79 Bug detailed description: ------------------------- When run Mesa demos engine on huronriver, GPU will hang. It is regression. It works fine on pineview and ironlank. Reproduce steps: ---------------- 1. xinit & 2. ./engine