2013/6/28 Joshua C. <joshuacov@xxxxxxxxx>: > 2013/6/27 Alex Deucher <alexdeucher@xxxxxxxxx>: >> On Wed, Jun 26, 2013 at 4:57 PM, Joshua C. <joshuacov@xxxxxxxxx> wrote: >>> 2013/6/26 Deucher, Alexander <Alexander.Deucher@xxxxxxx>: >>>> >>>> >>>>> -----Original Message----- >>>>> From: Joshua C. [mailto:joshuacov@xxxxxxxxx] >>>>> Sent: Wednesday, June 26, 2013 1:52 PM >>>>> To: dri-devel@xxxxxxxxxxxxxxxxxxxxx >>>>> 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 With the latest git 7982128c3d447df27db963af67bc6b8dc7efb1de "drm/radeon/dpm: add debugfs support for SI" from git://people.freedesktop.org/~agd5f/linux drm-next-3.11 everything works fine here (on TURKS). Under Linux I get the same temps as under windows. No more tearing when watching videos. The GPU re-clocks as desired... -- --joshua _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
