[Bug 49603] New: [regression] Fullscreen video no longer smooth with GPU in low power mode
https://bugs.freedesktop.org/show_bug.cgi?id=49603
Bug #: 49603 Summary: [regression] Fullscreen video no longer smooth with GPU in low power mode Classification: Unclassified Product: Mesa Version: 8.0 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: sa@whiz.se
With Mesa 8.0 I can watch fullscreen videos using Totem (and other players that uses an OpenGL sink) with my GPU set to "low" power mode without problems. With 8.0.1 (and later) this is no longer possible. Every so often I get stalls and what looks like dropped frames. It's a blink and you'll miss it kind of thing, but over a longer period of time (such as watching a movie) it's quite noticeable and annoying.
Setting the card to "mid" or higher works around this, but as it's a passive card I would prefer to keep it running in low as much as possible.
Bisecting for this bug turns up the below commit, I have confirmed it by reverting this change.
(I'm not sure if adding the patch author to the cc list is considered good practice or not?)
System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: REDWOOD -- Model: XFX Radeon HD 5670 1GB -- Display connector: DVI -- xf86-video-ati: 6.14.4 -- xserver: 1.12.1 -- mesa: 8.0.2 -- drm: 2.4.33 -- kernel: 3.3.4
106ea10d1b246aba1a0f4e171fd7d21268f3960f is the first bad commit commit 106ea10d1b246aba1a0f4e171fd7d21268f3960f Author: Simon Farnsworth simon.farnsworth@onelan.co.uk Date: Tue Feb 14 12:06:20 2012 +0000
r600g: Use a fake reloc to sleep for fences
r300g is able to sleep until a fence completes rather than busywait because it creates a special buffer object and relocation that stays busy until the CS containing the fence is finished.
Copy the idea into r600g, and use it to sleep if the user asked for an infinite wait, falling back to busywaiting if the user provided a timeout.
Signed-off-by: Simon Farnsworth simon.farnsworth@onelan.co.uk Signed-off-by: Alex Deucher alexander.deucher@amd.com (cherry picked from commit 8cd03b933cf868ff867e2db4a0937005a02fd0e4)
Conflicts:
src/gallium/drivers/r600/r600_pipe.c
:040000 040000 390170e370f86ee323dce284906ed21693ed9d09 cccea412e6be4f3619422196231e02b375ab4772 M src
https://bugs.freedesktop.org/show_bug.cgi?id=49603
--- Comment #1 from Michel Dänzer michel@daenzer.net 2012-05-08 03:12:01 PDT --- Created attachment 61210 --> https://bugs.freedesktop.org/attachment.cgi?id=61210 Always spin first
Does this patch help?
https://bugs.freedesktop.org/show_bug.cgi?id=49603
--- Comment #2 from Simon Farnsworth simon.farnsworth@onelan.co.uk 2012-05-08 03:43:29 PDT --- Created attachment 61213 --> https://bugs.freedesktop.org/attachment.cgi?id=61213 Different route to spinning in preference to in-kernel waits for short fences
If Michel's patch helps, would you mind trying this patch instead? The difference is that Michel's patch doesn't have the early abort if the kernel says the GPU has completed the command batch we're waiting for, while this patch does. Both patches will cause Mesa to spin 256 times before it goes to sleep waiting for the GPU to have completed a command batch.
For background, I'm working with the Fusion E-350 chip; I'm thus CPU-limited. The goal of the original patch is twofold:
1) Don't spin on CPU when you're going to have to wait for a long time for the GPU to finish work - go to sleep waiting for the GPU to complete.
2) Don't keep spinning when the GPU has completed the command batch that includes the fence - it's not going to change state again, absent bugs, so we should cease spinning now.
If Michel's patch helps, and this patch does not, it indicates that there are problems with attempting to wait in the kernel. If neither patch helps, we have a deeper issue to diagnose.
https://bugs.freedesktop.org/show_bug.cgi?id=49603
--- Comment #3 from Sven Arvidsson sa@whiz.se 2012-05-08 10:56:45 PDT --- Neither patch seems to help unfortunately. If anything, I'd say they both make the problem worse.
https://bugs.freedesktop.org/show_bug.cgi?id=49603
--- Comment #4 from Alex Deucher agd5f@yahoo.com 2012-05-08 19:24:48 PDT --- Does forcing the CPU into the highest power state fix the issue? I suspect that the patch reduces CPU usage which in turn means the CPU power state stays lower longer.
https://bugs.freedesktop.org/show_bug.cgi?id=49603
--- Comment #5 from Simon Farnsworth simon.farnsworth@onelan.co.uk 2012-05-09 02:30:15 PDT --- Created attachment 61271 --> https://bugs.freedesktop.org/attachment.cgi?id=61271 A program to stop the CPU entering low power states
Trying a different route. Can you compile the attached program with "gcc -o stopsleep stopsleep.c" and leave it running while playing a video? It tells the kernel to avoid using deep sleep states when idling.
If it helps, we have a clue. If it doesn't, and video decode doesn't saturate all your CPU cores, can you try running "while true ; do true ; done" in a background shell and see if that helps?
The goal of both of these is to see if the problem is that we're now letting the CPU idle more than we used to, and finding that the resulting power save modes hurt.
https://bugs.freedesktop.org/show_bug.cgi?id=49603
--- Comment #6 from Sven Arvidsson sa@whiz.se 2012-05-11 13:46:30 PDT --- I have tried both stopsleep and the shell loop now, but sadly neither one gets rid of the problem.
I get the feeling that there's less stalls with them, but video playback isn't as smooth as it is with power profile mid (or the change reverted). I could be wrong about this though, it's hard to be sure with this kind of intermittent bug.
https://bugs.freedesktop.org/show_bug.cgi?id=49603
Sven Arvidsson sa@whiz.se changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #7 from Sven Arvidsson sa@whiz.se --- With Mesa 9.2 and other modern components fullscreen video is smooth in low power mode once again.
I guess this is less relevant anyhow what with UVD and dynamic power management also being available.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org