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
Everything works fine, however I think that my gpu (ati 6670, see below) doesn't reclock properly (OR doesn't reclock at all). I observed the gpu-temps and compared those with the readings when using “profile” and “dynpm”. Usually (with dynpm) the temps stay low and jump up when I start glxgears or any HD-movie. With the latest dpm my temps and the gpu stay in the lowest profile all the time. It doesn't reclock even if I start any demanding work like HD-Movie. Dmesg shows this:
*** [ 1.307529] == power state 0 == [ 1.307530] ui class: none [ 1.307531] internal class: boot [ 1.307532] caps: [ 1.307533] uvd vclk: 0 dclk: 0 [ 1.307534] power level 0 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.307535] power level 1 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.307536] power level 2 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.307537] status: c r b [ 1.307538] == power state 1 == [ 1.307539] ui class: performance [ 1.307539] internal class: none [ 1.307540] caps: [ 1.307541] uvd vclk: 0 dclk: 0 [ 1.307542] power level 0 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.307543] power level 1 sclk: 40000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.307544] power level 2 sclk: 80000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.307544] status: [ 1.307545] == power state 2 == [ 1.307546] ui class: none [ 1.307546] internal class: uvd [ 1.307547] caps: video [ 1.307549] uvd vclk: 70000 dclk: 56000 [ 1.307549] power level 0 sclk: 80000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.307550] power level 1 sclk: 80000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.307551] power level 2 sclk: 80000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.307552] status: [ 1.311858] switching from power state: [ 1.311859] ui class: none [ 1.311860] internal class: boot [ 1.311860] caps: [ 1.311861] uvd vclk: 0 dclk: 0 [ 1.311862] power level 0 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.311863] power level 1 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.311864] power level 2 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.311865] status: c b [ 1.311866] switching to power state: [ 1.311866] ui class: performance [ 1.311867] internal class: none [ 1.311868] caps: [ 1.311869] uvd vclk: 0 dclk: 0 [ 1.311869] power level 0 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.311870] power level 1 sclk: 40000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.311871] power level 2 sclk: 80000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.311872] status: r
and later (other dmesg output is attached)
[ 1.360509] switching from power state: [ 1.360510] ui class: performance [ 1.360510] internal class: none [ 1.360511] caps: [ 1.360511] uvd vclk: 0 dclk: 0 [ 1.360512] power level 0 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.360512] power level 1 sclk: 40000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.360513] power level 2 sclk: 80000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.360513] status: c r [ 1.360514] switching to power state: [ 1.360514] ui class: performance [ 1.360515] internal class: none [ 1.360515] caps: [ 1.360515] uvd vclk: 0 dclk: 0 [ 1.360516] power level 0 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.360516] power level 1 sclk: 40000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.360517] power level 2 sclk: 80000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.360517] status: c r
*** The radeon_pm_info shows all the time:
[root@localhost ~]# cat /sys/kernel/debug/dri/0/radeon_pm_info default engine clock: 800000 kHz current engine clock: 99990 kHz default memory clock: 1000000 kHz current memory clock: 150000 kHz voltage: 1100 mV PCIE lanes: 16
When using the “dynpm” settings I could see the voltage dropping back to 900mV (as in performace, power level 0) but now it stays high all the time. When playing a HD-Moving I can see the film in a “slow-motion” which also confirms that the gpu doesn't reclock. Setting dynpm reclocks fine and the HD-movie plays smoothly.
My gpu is:
01:00.0 VGA compatible controller: ATI Technologies Inc Turks XT [AMD Radeon HD 6600 Series] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited Device e194 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 56 Region 0: Memory at c0000000 (64-bit, prefetchable) [size=256M] Region 2: Memory at fe620000 (64-bit, non-prefetchable) [size=128K] Region 4: I/O ports at e000 [size=256] Expansion ROM at fe600000 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- LnkCap: Port #0, Speed 5GT/s, Width x16, ASPM L0s L1, Latency L0 <64ns, L1 <1us ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, OBFF Not Supported DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1- EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest- Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: 00000000fee0f00c Data: 41d2 Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?> Capabilities: [150 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- Kernel driver in use: radeon
Can some take a look at this?
Thanks, joshua
-----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
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.
-- --joshua
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
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
2013/6/28 Joshua C. joshuacov@gmail.com:
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
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@lists.freedesktop.org
-
Alex Deucher -
Deucher, Alexander -
Joshua C.