Bug 104496 - [GM45] asynchronous wait on fence i915:[global]:3268e timed out; critical performance loss minutes prior
Summary: [GM45] asynchronous wait on fence i915:[global]:3268e timed out; critical per...
Status: CLOSED WORKSFORME
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-04 19:58 UTC by Adric Blake
Modified: 2018-04-25 10:57 UTC (History)
1 user (show)

See Also:
i915 platform: GM45
i915 features: display/Other


Attachments
drm.debug=0x1f kernel log during critical performance loss (667.92 KB, application/x-bzip)
2018-01-04 19:58 UTC, Adric Blake
no flags Details
x11trace of minecraft (224.43 KB, application/gzip)
2018-01-05 01:02 UTC, Adric Blake
no flags Details
x11trace of marco (528.58 KB, application/gzip)
2018-01-05 01:05 UTC, Adric Blake
no flags Details

Description Adric Blake 2018-01-04 19:58:07 UTC
Created attachment 136555 [details]
drm.debug=0x1f kernel log during critical performance loss

Arch Linux x86_64

linux-drm-tip-git 4.15rc6+1282+g5f40895798ad+724923-1
xorg-server 1.19.6-2
mesa 17.3.1-2
libdrm 2.4.89-1
xf86-video-intel 1:2.99.917+804+g708255cb-2 (w/o debug)

Get the following warning in the kernel log: asynchronous wait on fence i915:[global]:3268e timed out

The actual issue is the alt-tabbing away from a fullscreen Minecraft window while it is actively rendering will cause critical performance issues. It'll minimize... but slowly and without redrawing everything. Sometimes the performance effect is delayed. After that, the desktop and any VT-switching is horrendously slow (on the order of several seconds to nearly a minute), forcing me to kill the minecraft program. Even after killing it, it takes a few seconds for the graphics to respond again. After switching to a linux console, performance is fine, having no extreme CPU or RAM usage.

The attachment has a drm.debug=0x1f kernel log. While it didn't seem to capture the warning in this attempt, the critical performance loss is still there. It starts at around 14:02 and lasts for about 8 minutes.
Comment 1 Chris Wilson 2018-01-04 20:30:16 UTC
What you want to do is x11trace minecraft as it appears to flood the system with swap requests (I guess) but not drawing anything itself. But I don't understand why it would be triggering redraws if it is not visible, and not updating.
Comment 2 Adric Blake 2018-01-05 01:02:57 UTC
Created attachment 136560 [details]
x11trace of minecraft

Sample incident. I didn't even minimize it this time; it seems to have done it on its own.

I used the x11trace from here:
https://github.com/yuq/xtrace
Comment 3 Adric Blake 2018-01-05 01:05:56 UTC
Created attachment 136561 [details]
x11trace of marco

x11trace, not x11perf. The name just stuck in my head. :/

marco is my window manager; I'm including it just in case the culprit is merely user software.
Comment 4 Jani Saarinen 2018-03-29 07:11:09 UTC
First of all. Sorry about spam.
This is mass update for our bugs. 

Sorry if you feel this annoying but with this trying to understand if bug still valid or not.
If bug investigation still in progress, please ignore this and I apologize!

If you think this is not anymore valid, please comment to the bug that can be closed.
If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Comment 5 Jani Saarinen 2018-04-25 10:57:04 UTC
Closing, please re-open is issue still exists.


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.