2013/6/27 Alex Deucher alexdeucher@gmail.com:
On Wed, Jun 26, 2013 at 4:57 PM, Joshua C. joshuacov@gmail.com wrote:
2013/6/26 Deucher, Alexander Alexander.Deucher@amd.com:
-----Original Message----- From: Joshua C. [mailto:joshuacov@gmail.com] Sent: Wednesday, June 26, 2013 1:52 PM To: dri-devel@lists.freedesktop.org Cc: Deucher, Alexander Subject: RADEON / DPM: GPU cannot properly up-clock
First of all thank you guys for pushing this out! Great work!
I tried the latest code in drm-next-3.11-wip (up to commit b3c1e0c3ba885db44 "drm/radeon: fix endian issues in atombios dpm code") in connection with the latest radeon_ucode (latest update on 2013-06-26). I also reintroduced the debugfs info so that I can better observe the gpu-settings. For this I put back the following patch:
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c b/drivers/gpu/drm/radeon/radeon_pm.c index 7ba5d6f..9367234 100644 --- a/drivers/gpu/drm/radeon/radeon_pm.c +++ b/drivers/gpu/drm/radeon/radeon_pm.c @@ -1066,6 +1066,11 @@ static int radeon_pm_init_dpm(struct radeon_device *rdev) ret = device_create_file(rdev->dev, &dev_attr_power_method); if (ret) DRM_ERROR("failed to create device file for power method\n");
if (radeon_debugfs_pm_init(rdev)) {DRM_ERROR("Failed to register debugfs file for PM!\n");}DRM_INFO("radeon: dpm initialized\n");-- 1.8.2.1
I removed that code for a reason when DPM is active. With DPM the hardware changes the power state dynamically internally so that old debugging information is completely irrelevant when DPM is active.
Alex
I see. Do you have any idea why I see those delays when playing a HD-movie? They do not appear when switching to dynpm. I use the latest llvm(3.4svn), libdrm(2.4.45), mesa(9.2.0 devel), xserver(1.14.99.0), xf86-video-ati(deve) - all fetched from git as of 2013-06-26.
What type of movie is it and what are you using to decode the movie? UVD? CPU?
Alex
Here is an example of the information from one of the films:
Stream 0 Type: Video Codec: H264 - MPEG-4 AVC (part 10) (avc1) Lang: English Res: 1280x544 Bitrate: 23.976215 Format: Planar 4:2:0 YVU Stream 1 Type: Audio Codec: DTS Audio (dts ) Lang: English Channels: 3F2R/LFE Freq: 48000 Hz Bitrate: 1536 kb/s
I recompiled the whole videostack (mesa, llvm, drm, xserver, xf86-video-ati, vdpau - all from git) against the patched kernel and can say that currently there are no visible regressions. The "slow motion" is almost gone. However I still see it in some frames but I'm not sure if this is a kernel-part-problem or just a mesa-problem.
However I observe the following:
Under windows: smooth play, temps in idle: 34-35C, cpu-usage: up to 5% on all cores on a 4-core cpu, temps when playing the film: up to 42C, cpu-usage: up to 5% on all 4 cores
Under linux (updated as described above): some discrepences (those happen pretty rarely, though), temps in idle: 34-36C, cpu-usage: up to 5%, temps when playing the film: no more than 37C, cpu-usage: one core is constantly spiking up to 40% the other 3 stay below 7%.
When looking through the dmesg I cannot see that dpm is changing the power state to "uvd". This makes me believe that I'm maybe using a cpu-decode rather then the dedicated uvd. The gpu-temps are also staying surpricingly low comapred to windows...
-- --joshua