2013/6/27 Alex Deucher <alexdeucher at gmail.com>: > On Wed, Jun 26, 2013 at 4:57 PM, Joshua C. <joshuacov at gmail.com> wrote: >> 2013/6/26 Deucher, Alexander <Alexander.Deucher at amd.com>: >>> >>> >>>> -----Original Message----- >>>> From: Joshua C. [mailto:joshuacov at gmail.com] >>>> Sent: Wednesday, June 26, 2013 1:52 PM >>>> To: dri-devel at 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
