Bug 49603

Summary:	[regression] Fullscreen video no longer smooth with GPU in low power mode
Product:	Mesa	Reporter:	Sven Arvidsson <sa>
Component:	Drivers/Gallium/r600	Assignee:	Default DRI bug account <dri-devel>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	medium	CC:	simon.farnsworth
Version:	8.0
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Attachments:	Always spin first Different route to spinning in preference to in-kernel waits for short fences A program to stop the CPU entering low power states

Description Sven Arvidsson 2012-05-07 13:11:36 UTC

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

Comment 1 Michel Dänzer 2012-05-08 03:12:01 UTC

Created attachment 61210 [details] [review]
Always spin first

Does this patch help?

Comment 2 Simon Farnsworth 2012-05-08 03:43:29 UTC

Created attachment 61213 [details] [review]
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.

Comment 3 Sven Arvidsson 2012-05-08 10:56:45 UTC

Neither patch seems to help unfortunately. If anything, I'd say they both make the problem worse.

Comment 4 Alex Deucher 2012-05-08 19:24:48 UTC

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.

Comment 5 Simon Farnsworth 2012-05-09 02:30:15 UTC

Created attachment 61271 [details]
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.

Comment 6 Sven Arvidsson 2012-05-11 13:46:30 UTC

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.

Comment 7 Sven Arvidsson 2013-09-19 19:24:20 UTC

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.

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.