Summary: | [r600g] GPU lockup when playing WoW with HD6450 with htile enabled | ||
---|---|---|---|
Product: | Mesa | Reporter: | Chris Rankin <rankincj> |
Component: | Drivers/Gallium/r600 | Assignee: | Default DRI bug account <dri-devel> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | major | ||
Priority: | medium | CC: | niels_ole |
Version: | git | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
dmesg output, showing lockup and failed reset.
Xorg.0.log file from the failed session. dmesg output showing GPU lockup |
Description
Chris Rankin
2013-03-03 17:06:46 UTC
Created attachment 75853 [details]
Xorg.0.log file from the failed session.
I have successfully played WoW using this exact same version of Mesa and a stock x86_64 3.8.1 kernel with my RV790. WTF? According to glxinfo, it's not using r600g at all...?!?! $ LIBGL_DEBUG=verbose LD_LIBRARY_PATH=/usr/local/lib64 glxinfo name of display: :1 libGL: screen 0 does not appear to be DRI2 capable libGL: OpenDriver: trying /usr/local/lib64/dri/swrast_dri.so libGL error: dlopen /usr/local/lib64/dri/swrast_dri.so failed (/usr/local/lib64/dri/swrast_dri.so: cannot open shared object file: No such file or directory) libGL error: unable to load driver: swrast_dri.so libGL error: failed to load driver: swrast display: :1 screen: 0 direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose) OpenGL vendor string: VMware, Inc. OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x301) OpenGL version string: 1.4 (2.1 Mesa 9.0.1) It can't find swrast_dri.so because I didn't compile it, but r600g_dri.so is definitely there! Fedora's gnome-shell process has suspiciously switched to swrast_dri.so too. I have no idea what has just happened. After a reboot, the new glxinfo reports: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD CAICOS OpenGL version string: 3.0 Mesa 9.2-devel (git-0b6e72f) OpenGL shading language version string: 1.30 I am guessing that it switched to swrast_dri after it failed to recover from the GPU lockup correctly. Can you bisect mesa? (In reply to comment #5) > Can you bisect mesa? I'm not sure that makes sense. The crashes started after Fedora upgraded its 3.7.9 kernel to one based on 3.8.1, and so I have no idea if there's even a "good" commit in Mesa to start bisecting from. (In reply to comment #6) > (In reply to comment #5) > > Can you bisect mesa? > > I'm not sure that makes sense. The crashes started after Fedora upgraded its > 3.7.9 kernel to one based on 3.8.1, and so I have no idea if there's even a > "good" commit in Mesa to start bisecting from. I'm guessing the kernel update enabled some additional feature in mesa (htile or async/cp dma support). Does disabling htile support help? Set env var R600_HYPERZ=0 (In reply to comment #7) > Does disabling htile support help? Set env var R600_HYPERZ=0 Yes, this prevents the GPU from locking up. *** Bug 62577 has been marked as a duplicate of this bug. *** Please check if below patch fix the issue: http://people.freedesktop.org/~glisse/0001-r600g-force-full-cache-for-hyperz.patch Created attachment 78735 [details]
dmesg output showing GPU lockup
No, it doesn't appear to. I compiled this version of Mesa after recompiling libdrm-2.4.44-2.fc19.src.rpm for F18:
OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.0 (git-3bba787)
OpenGL core profile shading language version string: 1.40
OpenGL core profile context flags: (none)
This version of Mesa is a lot more promising! OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD CAICOS OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.0 (git-8c347d4) OpenGL core profile shading language version string: 1.40 OpenGL core profile context flags: (none) No lock-ups so far! Closing |
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.