Created attachment 80258 [details] dmesg System Environment: -------------------------- Arch: x86_64 Platform: Haswell Libdrm: (master)libdrm-2.4.45-4-g8a88e349975a64676f143183e835e6d296f29627 Mesa: (master)c754f7a8fd53906acb9ef6ade715481a2c9f17de Xserver: (master)xorg-server-1.14.99.1-119-gc21344add2fc589df83b29be5831c36a372201bd Xf86_video_intel: (master)2.21.8-17-g66ad4d6f3c990bd40d816b4a22122bbf64786e4c Cairo: (master)41bef0fc385381b8c6b9091ec7ca2abe04cfc147 Libva: (staging)ef53340b19746589079d7ed5f9c67970fcc40401 Libva_intel_driver:(staging)9c698455fec340ced7dbf93cc5be004bb4a1eb22 Kernel: (drm-intel-nightly) 6d8ab2cbfc88b20db12b77a5fe1d77a7e8b4e89a Bug detailed description: ------------------------- It causes GPU hung on Haswell with mesa master branch. It doesn't happen on 9.1 branch. Bisect shows:c754f7a8fd53906acb9ef6ade715481a2c9f17de is the first bad commit commit c754f7a8fd53906acb9ef6ade715481a2c9f17de Author: Jordan Justen <jordan.l.justen@intel.com> AuthorDate: Fri Apr 19 01:13:31 2013 -0700 Commit: Jordan Justen <jordan.l.justen@intel.com> CommitDate: Sun Jun 2 20:39:38 2013 -0700 i965 gen7: use SURFACE_STATE fields to select render level/layer Rather than pointing the surface_state directly at a single sub-image of the texture for rendering, we now point the surface_state at the top level of the texture, and configure the surface_state as needed based on this. Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net> Reproduce steps: ---------------- 1. xinit 2. gnome-session 3. https://www.khronos.org/registry/webgl/conformance-suites/1.0.2/webgl-conformance-tests.html run conformance/textures/texture-size.html
Created attachment 80259 [details] i915_error_state
Reproduced on Ivy Bridge.
If you add an assert(irb->mt->first_level == 0) to gen7_update_renderbuffer_surface, does it ever get triggered? I think we may need to be adjusting some programming of levels in the != 0 case.
(playing the trick in title so this will be excluded from HSW specific bug query)
(In reply to comment #3) > If you add an assert(irb->mt->first_level == 0) to > gen7_update_renderbuffer_surface, does it ever get triggered? I think we > may need to be adjusting some programming of levels in the != 0 case. Thanks for the suggestion. This assert does appear to be triggered by the webgl test. But, the assert does not cause any regressions in piglit. Unfortunately, I don't know how to debug the webgl test to figure out what code path it is following. Anyone have some ideas of what to look for, or how to debug the webgl test? I'll keep working on it to see if I can discover anything else about the issue.
Well, you can "View Source" the page to get the source code for the test. Or check it out from Khronos SVN. It's in JavaScript, but quite readable. It's also apparently MIT licensed. Or, you can gdb firefox, just like anything else. Or you can apitrace firefox and then just replay it and use your normal tools.
(In reply to comment #6) > Or, you can gdb firefox, just like anything else. Thanks. gdb actually works for debugging this with firefox. Previously I tried debugging with chrome...
Should be resolved in adeda5af
Verified.Fixed.
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.