https://bugs.freedesktop.org/show_bug.cgi?id=39714
Summary: Slow and choppy 3D performace on evergreen after pm-suspend Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: bugs.xorg@boris64.net
Created an attachment (id=49783) --> (https://bugs.freedesktop.org/attachment.cgi?id=49783) 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!
https://bugs.freedesktop.org/show_bug.cgi?id=39714
--- Comment #1 from boris64 bugs.xorg@boris64.net 2011-08-01 05:12:55 PDT --- Created an attachment (id=49784) --> (https://bugs.freedesktop.org/attachment.cgi?id=49784) Xorg.0.log
https://bugs.freedesktop.org/show_bug.cgi?id=39714
--- Comment #2 from boris64 bugs.xorg@boris64.net 2011-08-01 05:13:14 PDT --- Created an attachment (id=49785) --> (https://bugs.freedesktop.org/attachment.cgi?id=49785) lspci -vvn
https://bugs.freedesktop.org/show_bug.cgi?id=39714
--- Comment #3 from Michel Dänzer michel@daenzer.net 2011-08-10 07:51:01 PDT --- 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...
https://bugs.freedesktop.org/show_bug.cgi?id=39714
--- Comment #4 from Michel Dänzer michel@daenzer.net 2011-08-31 06:43:22 PDT --- (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
https://bugs.freedesktop.org/show_bug.cgi?id=39714
--- Comment #5 from boris64 bugs.xorg@boris64.net 2011-08-31 12:53:28 PDT --- Created an attachment (id=50767) --> (https://bugs.freedesktop.org/attachment.cgi?id=50767) mtrr-before-pm-suspend.txt
Here we go.
https://bugs.freedesktop.org/show_bug.cgi?id=39714
--- Comment #6 from boris64 bugs.xorg@boris64.net 2011-08-31 12:53:52 PDT --- Created an attachment (id=50768) --> (https://bugs.freedesktop.org/attachment.cgi?id=50768) mtrr-after-pm-suspend.txt
https://bugs.freedesktop.org/show_bug.cgi?id=39714
--- Comment #7 from boris64 bugs.xorg@boris64.net 2011-08-31 12:54:54 PDT --- Created an attachment (id=50769) --> (https://bugs.freedesktop.org/attachment.cgi?id=50769) pat_memtype_list-before-pm-suspend.txt
https://bugs.freedesktop.org/show_bug.cgi?id=39714
--- Comment #8 from boris64 bugs.xorg@boris64.net 2011-08-31 12:55:16 PDT --- Created an attachment (id=50770) --> (https://bugs.freedesktop.org/attachment.cgi?id=50770) pat_memtype_list-after-pm-suspend.txt
https://bugs.freedesktop.org/show_bug.cgi?id=39714
--- Comment #9 from boris64 bugs.xorg@boris64.net 2011-08-31 12:55:39 PDT --- Created an attachment (id=50771) --> (https://bugs.freedesktop.org/attachment.cgi?id=50771) radeon_gtt_mm-before-pm-suspend.txt
https://bugs.freedesktop.org/show_bug.cgi?id=39714
--- Comment #10 from boris64 bugs.xorg@boris64.net 2011-08-31 12:55:58 PDT --- Created an attachment (id=50772) --> (https://bugs.freedesktop.org/attachment.cgi?id=50772) radeon_gtt_mm-after-pm-suspend.txt
https://bugs.freedesktop.org/show_bug.cgi?id=39714
--- Comment #11 from boris64 bugs.xorg@boris64.net 2011-08-31 12:56:17 PDT --- Created an attachment (id=50773) --> (https://bugs.freedesktop.org/attachment.cgi?id=50773) radeon_vram_mm-before-pm-suspend.txt
https://bugs.freedesktop.org/show_bug.cgi?id=39714
--- Comment #12 from boris64 bugs.xorg@boris64.net 2011-08-31 12:56:48 PDT --- Created an attachment (id=50774) --> (https://bugs.freedesktop.org/attachment.cgi?id=50774) radeon_vram_mm-after-pm-suspend.txt
https://bugs.freedesktop.org/show_bug.cgi?id=39714
--- Comment #13 from Michel Dänzer michel@daenzer.net 2011-09-07 03:29:22 PDT --- 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...
https://bugs.freedesktop.org/show_bug.cgi?id=39714
--- Comment #14 from boris64 bugs.xorg@boris64.net 2011-09-25 08:34:51 PDT --- Is there anything i could try out? I mean this affects every 3d app including the kwin window manager.
https://bugs.freedesktop.org/show_bug.cgi?id=39714
GitLab Migration User gitlab-migration@fdo.invalid changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |MOVED
--- Comment #15 from GitLab Migration User gitlab-migration@fdo.invalid --- -- 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.
dri-devel@lists.freedesktop.org