RADEON / DPM: GPU cannot properly up-clock

[Joshua C.]

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