Created attachment 127184 [details] Environment After commit fcb5106 (https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=fcb5106), rendering with the modesetting X.org driver on my haswell gt2 is completely messed up. This is reproducible with rendercheck's 'blend r8g8b8 window' test.
I tried to reproduce the bug on the parent commit, but it is in an even worse shape and hangs the machine entirely when starting plasma 5. The grandparent however works as expected.
[ 11672.499] (II) modesetting: Driver for Modesetting Kernel Drivers: kms ... =0 acer:~$ ./rendercheck/rendercheck -t blend -f a8r8g8b8 -d :0 rendercheck 1.5 Render extension version 0.11 Window format: r8g8b8 Ignoring server-supported format: a8 Ignoring server-supported format: a4 Found server-supported format: a8r8g8b8 Ignoring server-supported format: x8r8g8b8 Ignoring server-supported format: b8g8r8a8 Ignoring server-supported format: b8g8r8x8 Ignoring server-supported format: r8g8b8 Ignoring server-supported format: b8g8r8 Ignoring server-supported format: x3r4g4b4 Ignoring server-supported format: x3b4g4r4 Ignoring server-supported format: r5g5b5 Ignoring server-supported format: b5g5r5 Ignoring server-supported format: x4r4g4b4 Ignoring server-supported format: x4b4g4r4 Ignoring server-supported format: x1r5g5b5 Ignoring server-supported format: x1b5g5r5 Ignoring server-supported format: r5g6b5 Ignoring server-supported format: b5g6r5 Ignoring server-supported format: a4r4g4b4 Ignoring server-supported format: a4b4g4r4 Ignoring server-supported format: x8b8g8r8 Ignoring server-supported format: x2r10g10b10 Ignoring server-supported format: x2b10g10r10 Beginning blend test on a8r8g8b8 Beginning blend test on r8g8b8 window 2 tests passed of 2 total Successful Groups: blend ... Extended renderer info (GLX_MESA_query_renderer): Vendor: Intel Open Source Technology Center (0x8086) Device: Mesa DRI Intel(R) Haswell Mobile (0x416) Version: 12.1.0 Accelerated: yes Video memory: 1536MB Unified memory: yes Preferred profile: core (0x1) Max core profile version: 3.3 Max compat profile version: 3.0 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.1 OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile OpenGL core profile version string: 3.3 (Core Profile) Mesa 12.1.0-devel (git-eb6ddd1)
Try commit f9326be5f1d3ff2c689de8a1754bdafd03879b58 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Apr 28 09:56:45 2016 +0100 drm/i915: Rearrange switch_context to load the aliasing ppgtt on first use
(In reply to Chris Wilson from comment #3) > Try commit f9326be5f1d3ff2c689de8a1754bdafd03879b58 > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Thu Apr 28 09:56:45 2016 +0100 > > drm/i915: Rearrange switch_context to load the aliasing ppgtt on first > use Yes, it seems to fix the problem, at least with rendercheck. I will check visually when I arrive at the office. Thanks a lot for the quick answer!
(In reply to Martin Peres from comment #4) > (In reply to Chris Wilson from comment #3) > > Try commit f9326be5f1d3ff2c689de8a1754bdafd03879b58 > > Author: Chris Wilson <chris@chris-wilson.co.uk> > > Date: Thu Apr 28 09:56:45 2016 +0100 > > > > drm/i915: Rearrange switch_context to load the aliasing ppgtt on first > > use > > Yes, it seems to fix the problem, at least with rendercheck. I will check > visually when I arrive at the office. > > Thanks a lot for the quick answer! Verified visually. So, who gets to ping stable@ for linux4.7+? Should I do it?
(In reply to Martin Peres from comment #5) > (In reply to Martin Peres from comment #4) > > (In reply to Chris Wilson from comment #3) > > > Try commit f9326be5f1d3ff2c689de8a1754bdafd03879b58 > > > Author: Chris Wilson <chris@chris-wilson.co.uk> > > > Date: Thu Apr 28 09:56:45 2016 +0100 > > > > > > drm/i915: Rearrange switch_context to load the aliasing ppgtt on first > > > use > > > > Yes, it seems to fix the problem, at least with rendercheck. I will check > > visually when I arrive at the office. > > > > Thanks a lot for the quick answer! > > Verified visually. So, who gets to ping stable@ for linux4.7+? Should I do > it? See if it applies cleanly, and send the backport request to the stable team, with me and/or intel-gfx in Cc.
(In reply to Jani Nikula from comment #6) > (In reply to Martin Peres from comment #5) > > (In reply to Martin Peres from comment #4) > > > (In reply to Chris Wilson from comment #3) > > > > Try commit f9326be5f1d3ff2c689de8a1754bdafd03879b58 > > > > Author: Chris Wilson <chris@chris-wilson.co.uk> > > > > Date: Thu Apr 28 09:56:45 2016 +0100 > > > > > > > > drm/i915: Rearrange switch_context to load the aliasing ppgtt on first > > > > use > > > > > > Yes, it seems to fix the problem, at least with rendercheck. I will check > > > visually when I arrive at the office. > > > > > > Thanks a lot for the quick answer! > > > > Verified visually. So, who gets to ping stable@ for linux4.7+? Should I do > > it? > > See if it applies cleanly, and send the backport request to the stable team, > with me and/or intel-gfx in Cc. So, it is already shipped in 4.8, so it would be backported only to 4.7... The patch does not apply cleanly but it did not seem like too much trouble to make it apply. I could do this, but then what users would be impacted since Arch is moving to 4.8 about this week, and fedora/ubuntu will move to 4.8. What is the usual thing to do here? Marking as fixed because the patch is already in a released kernel.
(In reply to Martin Peres from comment #7) > The patch does not apply cleanly but it did not seem like too much trouble > to make it apply. I could do this, but then what users would be impacted > since Arch is moving to 4.8 about this week, and fedora/ubuntu will move to > 4.8. Most of the time, we don't care. v4.8 is out, that's what people should be using. > What is the usual thing to do here? Marking as fixed because the patch is > already in a released kernel. For tracking purposes, we mark the bugs fixed when the fix has landed in drm-intel.git. Backporting to stable is out of our hands.
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.