Bug 39714 - Slow and choppy 3D performace on evergreen after pm-suspend
Summary: Slow and choppy 3D performace on evergreen after pm-suspend
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r600 (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-01 05:12 UTC by boris64
Modified: 2019-09-18 18:58 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
dmesg including pm-suspend event (100.64 KB, text/plain)
2011-08-01 05:12 UTC, boris64
Details
Xorg.0.log (56.97 KB, text/x-log)
2011-08-01 05:12 UTC, boris64
Details
lspci -vvn (30.80 KB, text/plain)
2011-08-01 05:13 UTC, boris64
Details
mtrr-before-pm-suspend.txt (488 bytes, text/plain)
2011-08-31 12:53 UTC, boris64
Details
mtrr-after-pm-suspend.txt (488 bytes, text/plain)
2011-08-31 12:53 UTC, boris64
Details
pat_memtype_list-before-pm-suspend.txt (593 bytes, text/plain)
2011-08-31 12:54 UTC, boris64
Details
pat_memtype_list-after-pm-suspend.txt (593 bytes, text/plain)
2011-08-31 12:55 UTC, boris64
Details
radeon_gtt_mm-before-pm-suspend.txt (207.89 KB, text/plain)
2011-08-31 12:55 UTC, boris64
Details
radeon_gtt_mm-after-pm-suspend.txt (240.08 KB, text/plain)
2011-08-31 12:55 UTC, boris64
Details
radeon_vram_mm-before-pm-suspend.txt (42.30 KB, text/plain)
2011-08-31 12:56 UTC, boris64
Details
radeon_vram_mm-after-pm-suspend.txt (7.62 KB, text/plain)
2011-08-31 12:56 UTC, boris64
Details

Note You need to log in before you can comment on or make changes to this bug.
Description boris64 2011-08-01 05:12:16 UTC
Created attachment 49783 [details]
dmesg including pm-suspend event

I get very slow and choppy 3d performance after suspending my computer.
This is valid for glxgears (i-know-it's-not-a-benchmark), kwin and others.
After restarting the 3d application speed seems to be normal/ok again. 

Example:
[glxgears output]
17641 frames in 5.0 seconds = 3528.125 FPS
18396 frames in 5.0 seconds = 3679.087 FPS
22768 frames in 5.0 seconds = 4553.543 FPS
18280 frames in 5.0 seconds = 3655.863 FPS
16051 frames in 5.0 seconds = 3210.111 FPS
16030 frames in 5.0 seconds = 3205.946 FPS
18157 frames in 5.0 seconds = 3628.626 FPS
18182 frames in 5.0 seconds = 3636.259 FPS
...
(-> pm-msuspend here <-)
...
12270 frames in 19.1 seconds = 641.561 FPS
4518 frames in 5.0 seconds = 903.255 FPS
4721 frames in 5.0 seconds = 944.181 FPS
4750 frames in 5.0 seconds = 949.833 FPS
4724 frames in 5.0 seconds = 944.745 FPS
4759 frames in 5.0 seconds = 951.687 FPS
4535 frames in 5.0 seconds = 905.757 FPS
4557 frames in 5.0 seconds = 911.264 FPS
[/glxgears output]

Used drivers+software:
-xorg-server-1.10.3
-mesa(r600g)/ddx/libdrm from git (latest)
-kernel-3.0.0

If you need more infos/logs, please do not hesitate to ask.
Thank you in advance!
Comment 1 boris64 2011-08-01 05:12:55 UTC
Created attachment 49784 [details]
Xorg.0.log
Comment 2 boris64 2011-08-01 05:13:14 UTC
Created attachment 49785 [details]
lspci -vvn
Comment 3 Michel Dänzer 2011-08-10 07:51:01 UTC
Here's my theory on what's happening:

On suspend, all BOs located in VRAM are evicted to GTT using radeon_bo_evict_vram() -> ttm_bo_evict_mm(). There's no mechanism to explicitly try and move these back to VRAM after resume, so some of them probably stay in GTT indefinitely.

Not sure offhand how to address this...
Comment 4 Michel Dänzer 2011-08-31 06:43:22 UTC
(In reply to comment #3)
> Here's my theory on what's happening:

Another possibility might be that e.g. PAT / MTRR attributes aren't properly restored for some memory areas. Can you attach the following files from before/after suspend/resume:

/sys/kernel/debug/dri/0/radeon_*_mm
/sys/kernel/debug/x86/pat_memtype_list
/proc/mtrr
Comment 5 boris64 2011-08-31 12:53:28 UTC
Created attachment 50767 [details]
mtrr-before-pm-suspend.txt

Here we go.
Comment 6 boris64 2011-08-31 12:53:52 UTC
Created attachment 50768 [details]
mtrr-after-pm-suspend.txt
Comment 7 boris64 2011-08-31 12:54:54 UTC
Created attachment 50769 [details]
pat_memtype_list-before-pm-suspend.txt
Comment 8 boris64 2011-08-31 12:55:16 UTC
Created attachment 50770 [details]
pat_memtype_list-after-pm-suspend.txt
Comment 9 boris64 2011-08-31 12:55:39 UTC
Created attachment 50771 [details]
radeon_gtt_mm-before-pm-suspend.txt
Comment 10 boris64 2011-08-31 12:55:58 UTC
Created attachment 50772 [details]
radeon_gtt_mm-after-pm-suspend.txt
Comment 11 boris64 2011-08-31 12:56:17 UTC
Created attachment 50773 [details]
radeon_vram_mm-before-pm-suspend.txt
Comment 12 boris64 2011-08-31 12:56:48 UTC
Created attachment 50774 [details]
radeon_vram_mm-after-pm-suspend.txt
Comment 13 Michel Dänzer 2011-09-07 03:29:22 UTC
The MTRR/PAT info is the same before and after, but almost 60M worth of BOs moved from VRAM to GTT. So the first theory seems more likely.

That said, I'm not sure which buffer(s) could make such a difference for glxgears...
Comment 14 boris64 2011-09-25 08:34:51 UTC
Is there anything i could try out? I mean this affects
every 3d app including the kwin window manager.
Comment 15 GitLab Migration User 2019-09-18 18:58:43 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/399.


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.